[12:17] <rtg_> kylem: I have 3 that all load i2c_ec, but nonoe of them oops.
[12:17] <mjg59> On the vast majority of machines, i2c_ec will never bind
[12:17] <mjg59> So loading it is uninteresting
[12:21] <maks_> BenC we can easily write a blacklist dir in /dev/.initramfs
[12:22] <maks_> some m-i-t would need to pick that up
[12:28] <BenC> is i2c_ec autoloaded somehow?
[12:28] <rtg_> Yep.
[12:28] <rtg_> Well, maybe. I'm not sure.
[12:28] <rtg_> I think its a result of sms
[12:30] <rtg_> sms --> sbs
[01:08] <mjg59_> rtg_: Uh. http://git.kernel.org/?p=linux/kernel/git/bcollins/ubuntu-feisty.git;a=commitdiff;h=82580efcd0224a29a9bef1b4ce53f7a4d4611b09 is really, really not a good idea.
[01:09] <mjg59_> Oh, wait, hang on.
[01:09] <mjg59_> Sorry, I see what you were doing there.
[01:11] <maks_> BenC qemu test complain about not beeing able to write to ${rootmnt}/etc/modprobe.d/initramfs as ro mounted
[01:12] <maks_> can post the patch if you want
[01:12] <BenC> maks_: Ah, right, it's mounted ro until after the init scripts run fsck and such
[01:13] <BenC> so maybe there should be a dangling symlink for /etc/modprobe.d/initramfs-blacklist -> /some/tmpfs/initramfs-blacklist
[01:13] <BenC> initramfs could create /some/tmpfs/initramfs-blacklist
[01:14] <mjg59_> BenC: It looks astonishingly likely that db2f0f088a056c4ccf9054747169802db2f9ae9a is what broke the i2c_ec stuff
[01:14] <mjg59_> Any idea what dragged that in?
[01:15] <maks_> BenC currently we like to write usplash stuff into /dev/.initramfs so there could be the modprobe.d blacklist there
[01:15] <BenC> mjg59_: right, rtg found that out too...that got dragged in either by devres stuff, or to fix some other bug, but I can't recall which now
[01:16] <BenC> I should really edit cherry-picks as to why they got picked, especially ones like that
[01:16] <mjg59_> Well, just lose that line 
[01:17] <BenC> we are still seeing a bug with HPA patch, even reverted back to original ABI breaking code
[01:17] <BenC> reverting it just covered up the ata_dev_same_device() failure
[01:17] <mjg59_> BenC: Well, that's not the fix that he committed
[01:18] <pkl_> BenC: is there a reason why c25cfc3ad3cb8cac3474febfe66cff8ee0bfba18a was applied reverting the tifm driver from 0.8 to 0.7?
[01:18] <BenC> mjg59_: I'll look at that in a second...if it works with the i2c change reverted, I can maybe get it in
[01:18] <BenC> I need to get HPA working
[01:18] <mjg59_> BenC: I can't guarantee that it works, and I recommend not reverting the entire thing
[01:18] <BenC> [   67.208231]  ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = -1342616656
[01:19] <mjg59_> Just change that one line
[01:19] <mjg59_> It certainly can't make anything worse
[01:19] <BenC> mjg59_: which line?
[01:19] <mjg59_> +       smbus->adapter.dev.parent = &device->dev;
[01:19] <mjg59_> Delete it
[01:19] <BenC> for i2c_ec?
[01:19] <mjg59_> Yes
[01:19] <BenC> Ok
[01:19] <mjg59_> You can't legally do that with the acpi in 2.6.20
[01:20] <BenC> mjg59_: back to HPA, there seems to be some 64-bit issue with the lba to sectors code
[01:20] <BenC> I can see it on my xeon now
[01:20] <BenC> I need to check the values in that function
[01:21] <mjg59_> Ok
[01:21] <mjg59_> I'm unlikely to have a 64-bit install done in time to help you
[01:23] <BenC> mjg59_: be around for general poking if I find anything?
[01:24] <BenC> now that I can reproduce it, I can at least find out where it's coming from, but if I get any ata questions, I'm at a loss for quick answers
[01:29] <mjg59_> Yup
[01:36] <BenC>         printk("%02x %02x %02x %02x %02x %02x: %016llx \n",
[01:36] <BenC>                tf->hob_lbah, tf->hob_lbam, tf->hob_lbal,
[01:36] <BenC>                tf->lbah, tf->lbam, tf->lbal, sectors);
[01:37] <BenC> [   67.124009]  f9 4b af f9 4b af: ffffffffaff94baf 
[01:37] <BenC> prints that
[01:37] <BenC> that can't be right
[01:37] <BenC> this is what gets printed for another drive
[01:37] <BenC> [   67.112044]  00 00 00 f9 4b af: 0000000000f94baf 
[01:37] <BenC> the f94baf looks awful familiar :/
[01:46] <BenC> the first read is from ata_read_native_max_address_ext()
[01:46] <BenC> the second is from the return value of ata_set_native_max_address_ext()
[01:47] <BenC> I think I see the problem with this
[02:15] <cjwatson> BenC: what's the status? I see scrollback ...
[02:30] <BenC> cjwatson: things are working, I just have a slight problem of 64-bit ness it seems
[02:31] <BenC> cjwatson: it's a problem I can reproduce so just a matter of figuring out the thinko that is hiding in here somewhere
[02:32] <cjwatson> ok, I'm going to doze here,
[02:32] <cjwatson> if you phone my landline it stands some chance of waking me up
[02:32] <BenC> cjwatson: Ok, elmo said he'd be around to process an upload, unless you prefer I contact you
[02:34] <cjwatson> use me as a first resort and elmo as a backup, please
[02:44] <BenC> cjwatson: will do
[04:07] <jml> t.
[04:07] <jml> (sorry, ultra-tappy touchpad)
[06:19] <defendguin> hey how do i mount the mmc device?
[06:35] <defendguin> now my mmc card wont work in -12 and it used to and my camera doesn't connect as a mass storage device
[06:38] <Mithrandir> defendguin: please try the absolute latest kernel, it should fix it.
[06:38] <defendguin> Mithrandir: what is the latest? -14?
[06:38] <defendguin> or did they release something else with the mmc fix?
[06:40] <fabbione> defendguin: yes. about 8 hours ago and should be in the archive.ubuntu.com as we speak
[06:40] <fabbione> probably the mirrors didn't catch it up yet
[06:40] <Mithrandir> 2.6.20.14.12
[06:40] <defendguin> ahh i see it in update
[06:40] <defendguin> 2.6.20-14.23
[06:41] <defendguin> i hope that fixes the issue with the camera too
[06:50] <defendguin> doesn't look like it is working
[06:51] <defendguin> how can i tell that im in .23?   it just says generic
[06:51] <Mithrandir> make sure uname -a says 2.6.20-14-generic
[06:52] <defendguin> Linux houston 2.6.20-14-generic #2 SMP Thu Apr 12 22:53:19 UTC 2007 i686 GNU/Linux
[06:52] <Mithrandir> and neither your camera (which I presume is mass-storage) nor your mmc reader works correctly?
[06:53] <defendguin> correct
[06:55] <defendguin> it is most probably mass storage but i can't guarantee that
[06:57] <defendguin> i wish i had gotten a chance to test this fix out a few days ago
[06:58] <Mithrandir> I think it's too late to fix this now, we might be able to do it in a post-release update
[07:02] <defendguin> Mithrandir: i really need to mount this disk
[07:03] <defendguin> i used to remember my fstab stuff but its been so long since i needed to 
[07:08] <defendguin> what sucks is that it used to work in -12 but now that doesn't even work
[07:12] <cjwatson> BenC: this isn't sounding good. What's up?
[07:21] <Mithrandir> what breaks if we just blacklist that i2c-ec driver?
[07:23] <Mithrandir> hm, the smart battery module breaks then..
[07:27] <Mithrandir> ugh, it's 1:30 for Ben, a bit on the late side to call him.
[07:45] <fabbione> i don't think he will mind too much if you call him
[07:45] <fabbione> probably the wife will mind more
[08:09] <Mithrandir> I've sent him an SMS and will send him an email too, hopefully he'll see either if he's up
[12:07] <mc44> the new kernel seems to be broken for me
[12:07] <mc44> should I file a bug?
[12:07] <Mithrandir> no
[12:08] <Mithrandir> there are about five hundred zillion dupes filed already
[12:08] <mc44> haha
[12:08] <mc44> ok sorry
[01:38] <Mithrandir> the SD/MMC reader on my x40 seems to work again, at least.
[01:53] <Keybuk> I've yet to find a use for the SD/MMC reader
[01:54] <Keybuk> since every single device I own has a different profile card
[01:54] <Mithrandir> I wish I had a CF reader instead.  SD is one of the few I actually don't have.
[01:55] <zdzichuBG> so I must be lucky. card reader in my z61t is compatibile with my sistet's Minolta camera
[01:55] <Keybuk> the 770 takes a little card that's half the size of the cards the N800 takes
[01:55] <Mithrandir> zdzichuBG: my camera uses CF cards, since it's a tad more expensive than the cheap ones you can get.
[01:56] <Mithrandir> at least I don't know of any prosumer DSLRs which use !CF.
[01:56] <Keybuk> successive sony phones have left me with a small pile of Memory Stick Duo, Memory Stick Pro Duo and now Scandisk M2 cards
[01:56] <Keybuk> none of which fit in any other device
[01:56] <Mithrandir> yes, I have MS Pro Duo as well, for my old camera.
[01:57] <Mithrandir> it's easier just to chuck a 250-thousand-different-kinds-of-cards reader in the bag and use that
[01:57] <Keybuk> I just use bluetooth
[01:57] <Keybuk> or USB
[03:01] <JanC> Mithrandir: 1000-in-1 usb card readers are cheap  :)
[03:01] <Mithrandir> they cost about 2.5 cents, so yes.
[03:05] <JanC> I don't understand why they don't just cram one of these in laptops instead of all those things that need special drivers
[03:06] <JanC> would probably be easier to support for manufacturers too
[03:35] <mjg59_> Keybuk: The ones in the N70 (RSMMC) are electrically compatible with MMC and SD
[03:35] <mjg59_> There's a little adapter that clips on
[03:36] <Keybuk> N70?
[03:36] <Keybuk> don't have one of those
[03:36] <Keybuk> I have a 770 and N800
[03:36] <mjg59_> 770, rather
[03:36] <Keybuk> the ones in the N800 are bigger versions of the ones in the 770, right?
[03:39] <mjg59_> The N800 comes with SD, not MMC
[03:39] <mjg59_> SD readers can read MMC, but not vice-versa
[03:44] <BenC> zul: ping
[03:44] <zul> BenC: pong
[03:44] <zul> whats up
[03:44] <BenC> zul: are you able to do anything with openvz? I sort of need to give Malc a heads up on what may or may not happen
[03:45] <zul> yeah I have x86 kind of working kind of broken on amd64
[03:45] <zul> I keep timing out when Im trying to upload it with dput
[03:45] <BenC> IMO, just apply the patches and getting it building if you can
[03:45] <BenC> let them worry about whether it works or not
[03:45] <zul> sure..
[03:46] <BenC> zul: could you reply to the email they sent?
[03:46] <zul> sure
[03:47] <BenC> zul: great thanks. I know you got a lot of other things going on more important, I'm just trying to follow up and make sure the communication doesn't go stale
[03:47] <zul> not a problem, thanks
[03:48] <zul> done
[03:49] <zul> Ill try to upload the kernel to the archive again
[03:50] <zul> and get the userland stuff uploaded at lunch
[04:19] <Keybuk> mjg59_: all I remember is that I tried to put the 770 card into my laptop
[04:19] <Keybuk> and couldn't get it out for weeks
[04:21] <mjg59_> Yes. You need the clip-on adapter.
[04:22] <kylem> wtf, could not resolve us.archive.ubuntu.com
[04:24] <Keybuk> I don't think I got an adapter
[04:24] <Keybuk> the M2 thing in the W880i is damned nifty though
[04:24] <Keybuk> it's 1GB and smaller than a thumb-nail
[04:28] <mjg59_> Keybuk: The 770 ships with the card in an adapter
[04:28] <mjg59_> You have to unclip it before you can put it in the machine
[04:28] <Keybuk> oh
[04:28] <Keybuk> wonder where I put that then
[04:29] <Keybuk> probably threw it away :)
[04:37] <gnomefreak> Keybuk: thank you for the n-m fix it worked great :)
[04:41] <EtienneG> hey guys ... I'm getting 403 Forbidden when trying to install linux-image-2.6.20-14-generic 
[04:42] <EtienneG> before I look for someone to bug, am I th eonly one that noticed this ?
[04:42] <stgraber> EtienneG: this kernel is buggy, so the access is currently blocked
[04:43] <EtienneG> ha, ok then
[04:43] <stgraber> EtienneG: some people have crash with it another one is being built at the moment
[04:43] <EtienneG> thanks for the info, I'll be waiting for the next upload
[05:06] <zul> BenC: ping bu
[05:06] <zul> er... openvz-kernel-2.6.20_2.6.20-1_source.changes is NEW 
[05:51] <BenC> mjg59, kylem: We need to figure out the correct fix for this
[05:51] <mjg59> Yes.
[05:51] <BenC> I'm leaning toward just not doing hpa if the driver is sata_nv...if it's even possible to do that check
[05:52] <mjg59> Not trivially.
[05:52] <mjg59> What other code paths are there that execute ata_exec_internal?
[05:53] <mjg59> Ah, hang on. Alan at one point suggested doing the resizing after the drive/controller timing had been set up.
[05:53] <mjg59> Can you move the call to...
[05:53] <mjg59> (Let me find this)
[05:53] <BenC> let me check...
[05:54] <BenC> we should do this for ATAPI, right?
[05:54] <mjg59> Ok, after the call to ata_set_mode() in ata_eh_recover()
[05:54] <mjg59> No, ATAPI isn't a problem
[05:54] <kylem> no.
[05:55] <mjg59> Or, rather, I don't think ATAPI devices can implement HPAs
[05:55] <kylem> doing HPA on ATAPI devices is illegal.
[05:55] <BenC> they should report no hpa support though right?
[05:55] <kylem> it won't claim ata_id_hpa_enabled
[05:55] <kylem> right
[05:55] <BenC> right
[05:55] <kylem> - Mandatory when the Host Protected Area feature set and the 48-bit Address feature set are
[05:55] <kylem>   implemented.
[05:55] <kylem> - Use prohibited when the Removable Media feature set is implemented.
[05:55] <kylem> - Use prohibited when PACKET Command feature set is implemented.
[05:55] <mjg59> kylem: Can you give that a go?
[05:56] <BenC> let me try mjg59's suggestion
[05:56] <mjg59> There's two codepaths where ata_set_mode() gets called, depending on whether the eh code is in use or not
[05:56] <mjg59> It may need adding to both
[05:57] <mjg59> Actually, yeah, it needs adding to both (if it works)
[05:57] <mjg59> But I guess we'll find out
[05:57] <kylem> mjg59, i've moved it somewhere myself trying.
[05:57] <BenC> mjg59: maybe put it in ata_set_mode?
[05:57] <mjg59> BenC: Could do, but no real need
[05:58] <mjg59> It's trivial to add to both
[05:58] <kylem> trying.
[06:00] <BenC> recompiling
[06:00] <kylem> worked.
[06:00] <kylem> mjg59, didn't fail that time.
[06:01] <kylem> ah. didn't fail because it didn't execute, fun.
[06:02] <kylem> ohhhh. hmm. maybe because hpa_id_enabled wasn't true there.
[06:02] <mjg59> kylem: Where did you add it?
[06:02] <kylem> mjg59, after ata_set_mode in bus_probe.
[06:03] <mjg59> kylem: That won't be executed if there's an error handler
[06:03] <mjg59> Put it in ata_eh_recover()
[06:03] <BenC> I've put it in both places, rebooting
[06:05] <BenC> boots
[06:05] <kylem> i still think we should add an avoid_all_hpa_code flag.
[06:05] <mjg59> Does it execute?
[06:05] <BenC> but I want to put a printk back in there to make sure it is getting called
[06:05] <BenC> kylem: I changed the ignore_hpa=0 to actually do that
[06:05] <kylem> at least that way, we don't brownpaperbag the pressed cds completley and utterly.
[06:06] <kylem> ok.
[06:06] <mjg59> I can sort of understand sata_nv getting upset if you're executing ata commands before actually making sure the disk and controller timings agree
[06:09] <BenC> it's not getting called
[06:09] <BenC> let me post my diff
[06:11] <BenC> people.ubuntu.com/~bcollins/libata.diff
[06:12] <BenC> I'm thinking about moving the checks for (ata_ignore_hpa && ata_id_hpa_enabled(dev->id) to the top of ata_hpa_resize to clean things up a bit
[06:13] <mjg59> Would also work
[06:13] <kylem> ok.
[06:13] <mjg59> BenC: It's not obvious why it's not getting called. You rebuilt the initramfs as well, right?
[06:13] <kylem> i have an idea.
[06:13] <kylem> we buy everyone scsi disks.
[06:13] <kylem> and pretend ATA doesn't exist. :)
[06:13] <BenC> yes
[06:18] <kylem> ergh.
[06:19] <kylem> ok.
[06:19] <kylem> i think ata_dev_revalidate is the right place to put it.
[06:19] <kylem> since it's called from both the _eh and bus_probe paths.
[06:20] <mjg59> After set_mode?
[06:21] <cjwatson> BenC: (is that another ABI bump, BTW?)
[06:21] <BenC> ok, it's getting called now
[06:21] <BenC> cjwatson: No
[06:21] <cjwatson> ok, just checkin'
[06:21] <cjwatson> I'm not going to say no if that's what it takes
[06:22] <mjg59> BenC: Getting called and breaking?
[06:22] <BenC> mjg59: I need to check that it is actually going down the code path
[06:23] <mjg59> Ok
[06:23] <BenC> but the function got called
[06:25] <notts> sorry to jump in, but there a major bug with the new updated kernel this morning
[06:26] <notts> got error message: error loading os"
[06:26] <mjg59> notts: Yes, it's broken for various people
[06:26] <mjg59> It's being worked on
[06:28] <kylem> hey hey.
[06:28] <kylem> garzik to the rescue.
[06:28] <notts> major thanks, any word on when
[06:30] <mjg59> When it works
[06:32] <kylem> WOOOOOO
[06:32] <kylem> I WIN
[06:32] <rpereira> hi everybody.
[06:33] <BenC> mjg59: neither of my drives says they support hpa when ata_resize_hpa() is called
[06:33] <kylem> BenC, boot with sata_nv.adma=0
[06:33] <BenC> kylem: with old patch?
[06:33] <kylem> ata4.00: ata_hpa_resize 1: sectors = 390721968, hpa_sectors = 390721968
[06:33] <mjg59> BenC: Hm. Odd.
[06:33] <kylem> BenC, yeah
[06:34] <kylem> want my defconfig'd kernel instead of rebuilding?
[06:34] <mjg59> kylem: Figures.
[06:34] <kylem> yes.
[06:34] <kylem> fuck nvidia.
[06:34] <kylem> right in the skull.
[06:34] <BenC> it doesn't take me long to rebuild libata.ko
[06:34] <kylem> ok.
[06:34] <BenC> kylem: so should we disable adma by default?
[06:34] <kylem> i think so.
[06:34] <mjg59> Fine. Dropping adma just costs us ncq
[06:34] <mjg59> But it's clearly broken in some respect
[06:35] <BenC> kylem: can you do a patch for that, and I'll include a patch so that ignore_hpa steers clear of all hpa code?
[06:36] <BenC> email it to me and I'll test it and prepare a -15.25
[06:36] <kylem> 1sec, trying to figure out if we can shortcircuit adma mode so we can leave it on.
[06:36] <BenC> kylem: just default the module param to 0 :)
[06:36] <BenC> if people want it they can enable it manually
[06:36] <kylem> NCQ is fairly hit or miss too.
[06:37] <BenC> do you think making module parm adma=0 by default is enough?
[06:37] <kylem> yes.
[06:37] <BenC> if that's all that's needed I can do that locally
[06:37] <kylem> ok.
[06:38] <kylem> it's static int adma_enabled
[06:38] <BenC> ok, I'll rebuild a kernel and see if danielk is still around to test
[06:38] <cjwatson> any idea when sata_nv.adma was turned on?
[06:38] <kylem> cjwatson, recently.
[06:38] <cjwatson> nod
[06:39] <kylem> commit 382a6652e91b34d5480cfc0ed840c196650493d4
[06:39] <kylem> Author: Robert Hancock <hancockr@shaw.ca>
[06:39] <kylem> Date:   Mon Feb 5 16:26:02 2007 -0800
[06:39] <kylem>     sata_nv: use ADMA for NODATA commands
[06:39] <kylem> turning it off wholesale is fine for now. i'll look into a real fix when we have some idle cycles.
[06:39] <cjwatson> hmm, git-blame says 2006-10-27
[06:39] <cjwatson> oh, it's only one bit of adma?
[06:40] <kylem> yeah.
[06:40] <kylem> basically instead of transitioning from adma mode to normal mode, they decided to submit NODATA with ADMA.
[06:41] <cjwatson> git log drivers/ata/sata_nv.c doesn't show the commit above?
[06:41] <cjwatson> (just trying to find it)
[06:41] <kylem> probably came in one of our imports
[06:41] <BenC> it was a chunk patch to sync with libata
[06:41] <cjwatson> $ git diff-tree -p 382a6652e91b34d5480cfc0ed840c196650493d4
[06:41] <cjwatson> fatal: bad object 382a6652e91b34d5480cfc0ed840c196650493d4
[06:41] <cjwatson> ah
[06:41] <BenC> cjwatson: git-diff-tree -p --pretty SHA
[06:41] <kylem> cjwatson, git show
[06:41] <BenC> cjwatson: ah, you don't have upstream in there
[06:42] <BenC> should we just revert that one patch?
[06:42] <cjwatson> ah, I have a different tree for that
[06:42] <kylem> BenC, testing.
[06:42] <BenC> if we can leave adma on for default transactions we can avoid the "my driver performance sucks" crew
[06:42] <kylem> yup.
[06:42] <kylem> reverts cleanly, testing now.
[06:43] <cjwatson> it does say it fixed some timeouts ...
[06:43] <kylem> boots.
[06:43] <cjwatson> oh, no, maybe not
[06:43] <kylem> yeah, the language is murky.
[06:44] <BenC> cjwatson: it fixes some previously fixed ones in a different way
[06:44] <BenC> from the sound of it
[06:44] <mjg59> Well, worst case is that we revert back to edgy levels of support for that hardware
[06:44] <cjwatson> mm
[06:44] <cjwatson> can we bonnie++ the resulting system or something? :)
[06:44] <mjg59> BenC: The i2c_ec patch went in, right?
[06:45] <kylem> NCQ isn't always a win.
[06:45] <BenC> kylem: so reverting that patch with current code works?
[06:45] <cjwatson> bit concerned that just booting might be a weak test there
[06:45] <BenC> mjg59: yes
[06:45] <mjg59> Excellent, thanks
[06:45] <cjwatson> (I don't care about performance, more that it doesn't fall over under load)
[06:45] <kylem> BenC, yes in my testing tree (which is .21-rc6) building ubuntu images now
[06:45] <cjwatson> mjg59: anything else you know about?
[06:45] <cjwatson> of the release-critical ohmygod kind
[06:45] <mjg59> Nothing from me
[06:46] <cjwatson> I thought it might be worth an explicit check :)
[06:46] <cjwatson> thanks
[06:46] <mjg59> Yeah, I forgot about that one because it got downgraded to medium for some reason
[06:47] <mjg59> Basic problem was just that something we'd ended up pulling in expected the ACPI device semantics from 2.6.21
[06:47] <cjwatson> it was critical when I first saw it
[06:47] <mjg59> I bumped it back up yesterday
[06:47] <cjwatson> kylem: can you arrange for as many people on the team as possible who use sata_nv to try this out?
[06:48] <kylem> cjwatson, just ping them in #c?
[06:48] <kylem> or check the hw db?
[06:50] <cjwatson> #c, #distro, distro-team@
[06:50] <kylem> yup.
[06:51] <BenC> I'll have kernels built with this in about 30 minutes
[06:51] <BenC> i386 and amd64
[06:52] <kylem> ok
[06:55] <kylem> BenC, this should be a suitably large hammer for now. I'm going to try and snoop the taskfile and unset ADMA for these commands and submit the patch upstream when i get a bit of free time.
[06:55] <BenC> kylem: ok
[06:56] <BenC> kylem, mjg59: thanks for the time...maybe we get a suitable kernel for release
[06:56] <kylem> heh
[06:57] <BenC> at least -15.24 is almost done building to free up the buildd's
[06:58] <BenC> builds started
[06:59] <cjwatson> let me know when it's ready (by whatever means necessary) and I'll contact Tollef if he isn't around
[06:59] <cjwatson> so we can make sure it builds on palmer again
[07:08] <BenC> is palmer the faster machine?
[07:10] <kylem> BenC, patch hitting your mailbox.
[07:10] <kylem> alternate fix, reverting that commit is fine too though.
[07:11] <BenC> I've already got the revert in here and building/preparing :)
[07:11] <kylem> beauty.
[07:12] <kylem> i fired the fix upstream since it was so simple to filter.
[07:12] <BenC> kylem: your fix will filter into gutsy, so for feisty we'll stick with edgy type performance
[07:14] <kylem> BenC, worst case scenario is we fix it right in -updates, with this, everyone should be able to at least boot.
[07:16] <cjwatson> sounds like the right decision
[07:17] <kylem> with ben's ignore_hpa patch, if this crops up in another controller we aren't able to test on, we should can at least tell them to disable it to get it installed.
[07:17] <kylem> but from a cursory glance, i don't think it will be.
[07:31] <lfittl> kvm, seems broken (kvm-api-9 dependency can't be fulfilled), any time when this will be fixed?
[07:33] <cjwatson> somebody oughta fix that, I agree; is it just a rebuild?
[07:39] <cjwatson> * refs/heads/Ubuntu-2.6.20-12.20: fast forward to branch 'Ubuntu-2.6.20-12.20' of git+ssh://rookery/srv/kernel-team/private/ubuntu-feisty old..new: 3ffd70d..3ffd70d
[07:39] <cjwatson> error: Ref refs/heads/Ubuntu-2.6.20-12.20 is at 3ffd70ddba9d846eefd2d201404ad4c8a99d2899 but expected d02602542ef5ceb2af1765a179a9af6224136afe
[07:39] <cjwatson> does anyone know what I'm supposed to do about that?
[07:47] <rtg_> cjwatson: I just edited .git/refs/heads/Ubuntu-2.6.20-12.20 and made it d02602542ef5ceb2af1765a179a9af6224136afe. It was happy after that.
[07:48] <cjwatson> huh :-)
[07:49] <cjwatson> nope, two git pulls later and it's unhappy again
[07:54] <rtg_> cjwatson: Yeah, it does it to me too. Serious git training is something I'm going to extract from Ben and Kyle at UDS so I can understand some of these bizarre problems.
[07:55] <kylem> we could do a git bootcamp at uds if you wish? i could make slides
[07:55] <rtg_> Man, I would hug you for that, but it might wig you out :)
[07:56] <kylem> haha.
[07:56] <cjwatson> bootcamp> I'd like that, if I have any time
[07:56] <kylem> i suspect a few other people in the company would like it too
[07:56] <kylem> i'd like someone to give me a bzr boot-to-the-head heh
[07:56] <kylem> cjwatson, are any of our bzr team coming?
[07:57] <cjwatson> not sure, but plenty of distro are very capable with bz
[07:57] <cjwatson> r
[08:14] <zul> bug or annoy?
[08:56] <PhinnFort> where can I find a list/download the patches that are applied against the ubuntu kernel?
[08:57] <PhinnFort> i'm especially interested in the usplash patch
[09:08] <PhinnFort> :S
[09:15] <cjwatson> that's one of the things the "u" stands for, yes :-)
[09:19] <PhinnFort> :D
[09:19] <PhinnFort> that means I won't have to worry about ck stepping on other patches' toes
[10:10] <nott2> have they up loaded the new fix for kernel 2.6.20-14 ?
[10:25] <cjwatson> 21:10 <cjwatson> -15.24 is in the archive and built everywhere
[10:25] <cjwatson> 21:11 <cjwatson> except possibly ia64, and if not that's on its way
[10:25] <cjwatson> 21:11 <cjwatson> -15.24 should work for everyone except people using sata_nv
[10:25] <cjwatson> 21:11 <cjwatson> for sata_nv, -15.25 has been uploaded
[10:25] <cjwatson> 21:11 <cjwatson> but it has not yet built
[10:25] <cjwatson> 21:11 <cjwatson> (in progress, hamsters running as fast as they can)
[10:25] <cjwatson> 21:12 <cjwatson> so sata_nv users should stay on -13 until -15.25 is available, and everyone else should use -15.24
[10:25] <cjwatson> 21:12 <cjwatson> and REPORT REGRESSIONS ASAP
[10:25] <cjwatson> nott2: ^--
[11:12] <nott2> cjwatson: so the new kernel is uploaded ?
[11:13] <nott2> got a error "403" from the website when trying to update about hour ago....
[11:17] <nott2> just try to get a update, nothing YET....