=== jjohansen is now known as jj-afk
[07:37] <dsto> Hello, would you mind to help me moving this bug to the correct package? meta-package "wireless backports generic" depends on a kernel level matching package which is currently missing in the repo. Bug 445931, thanks, dsto
[07:37] <ubot2> Launchpad bug 445931 in linux (Ubuntu) "linux-backports-modules-karmic not installable, dependency problem (affects: 3) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/445931
[09:14] <apw> dsto, moved
[09:14] <dsto> apw: thx
[09:17] <apw> dsto this bug is a karmic bug, yet your symtoms are maverick
[09:18] <apw> dsto, are you sure this bug still exists?  the archive is showing a consistent set versions wise
[09:18] <apw> dsto, though the versions are -24 not -23 in the archive right now
[09:19] <dsto> apw: I've seen it this morning, will try on another machine. sec
[09:19] <apw>      linux | 2.6.35-24.42 | maverick-updates | source
[09:19] <apw> linux-backports-modules-2.6.35 | 2.6.35-24.15 | maverick-updates | source
[09:20] <apw> both are 35-24, so if you have -23 your kernel would be out of date
[09:20] <apw> i am supprised that there wouldn't be a -23 of both currently though as they should be held for --security
[09:22] <apw> linux-backports-modules-2.6.35 | 2.6.35-23.13 | maverick-security | source
[09:22] <apw> so that should be in the pool and available.  hrm
[09:26] <apw> dsto, it is possible the packages were promoted t
[09:26] <apw> this morning to -updates and the publisher published half of the updates, if the rare cases that occurs it normally only persists for an hour
[09:27] <apw> so it may be resolved now
[09:31] <dsto> apw: I confirm, it's gone at 2.6.35-24 level. 
[09:32] <apw> dsto, great, thanks
[09:32] <apw> i'll clean up that bug
[09:32] <dsto> fine, thank you 
[09:33] <apw> dsto, yeah its an issue with the way the publisher works, if a package is promoted at exactly the wrong moment an inconsistent package set can be published for an hour, which is confusing
[09:34] <dsto> the good part: I did not open a new bug and we were able to clean an old one ;-)
[09:34] <apw> dsto, indeed :)
[09:35] <dsto> pleasure having worked with you, take care, have a nice day. 
[09:35] <apw> you too
[09:46] <apw> cjwatson, ok confirmed ... adding that memset turns grub into a hard reboot on both warm and _cold_ reboots
[09:46] <apw> cjwatson, so i assume that that buffer is the issue
[09:47]  * apw goes restest with the memset in but the buffer at 0x09...
[10:22] <cjwatson> apw: so I think that may well just mean that we got past one bug only to hit another
[10:22] <cjwatson> apw: and probably means that my valgrind test wasn't extensive enough
[10:22] <cjwatson> though odd for it to break cold reboots
[10:23] <apw> cjwatson, i suspect that for it to break cold it is not something valgrind can see, i suspect there is something we care about in the area
[10:24] <apw> cjwatson, normally we only damage a small section of it, the memset is splatting a far larger chunk and the symtoms are catestrophic, breaking grub itself
[10:24] <cjwatson> rebooting at run-time usually means a unhandled trap - something that would ordinarily a segfault would be sufficient
[10:24] <cjwatson> anyway, let me beat on it for a bit relative to the upstream code and I'll see what I can come up with
[10:24] <cjwatson> if it's breaking cold reboots now then that should be accessible with kvm
[10:25] <apw> cjwatson, sounds good, i have other issues to poke sadly
=== lifeless_ is now known as lifeless
[10:43] <Keybuk> I'm noticing a pattern here
[10:43]  * apw is all ears
[10:43] <Keybuk> brcm80211 works on days with a 'u' in them
[10:44] <Keybuk> wl works on the other days
[10:44] <apw> nice, a solution for every day :)
[10:44] <Keybuk> except for the weekend, brcm80211 works all weekend
[10:44] <Keybuk> (I actually expect it's something to do with the WiFi router)
[10:45] <Keybuk> wl's failure mode on some is never to lock to a channel, despite being associated, and bounce between 2.4Ghz g, n and 5Ghz a & n
[10:45] <Keybuk> brcm80211 works on those, but it's failure mode on the routers that wl seems to work fine on is ... to kernel panic
[10:46] <apw> Keybuk, the joy of having two drivers
[10:46] <apw> at least they are concentrating resource on the open one
[10:47] <Keybuk> yeah
[10:47] <Keybuk> the best plan at the moment seems to be to have brcm80211 blacklisted and use wl
[10:47] <Keybuk> but then manually switch if wl isn't working
[10:47] <Keybuk> because at least then you switch when the wireless is poo
[10:48] <Keybuk> rather than reboot after a kernel panic and switch in a hurry
[10:52] <apw> Keybuk, did you need to do anything special to get brcm80211 working in general, firmware etc ?
[10:52] <Keybuk> I just grabbed the source from git
[10:52] <Keybuk> fiddled with the Makefile to make it build against the maverick kernel
[10:52] <Keybuk> and grabbed the firmware out of git
[10:52] <apw> Keybuk, ahh on maverick
[10:52] <apw> ok as the driver is built by the looks of it in natty
[10:52] <Keybuk> yeah, I'm staying on maverick this cycle
[10:53] <Keybuk> the firmware for it was in the "linux-firmware" git repo
[10:53] <apw> cool
[10:53] <Keybuk> actually checking my history
[10:53] <Keybuk> I was git clone'ing that
[10:53] <Keybuk> but since I was on wl at the time, in the end I cheated
[10:53] <Keybuk> and installed the brcm80211-firmware package from Debian
[11:00] <apw> heh ... got it to blammo in about 10s ... sweet
[11:09] <apw> Keybuk, heh enabling the brcm driver seems to stop my lappy booting
[11:10] <Keybuk> heh
[11:11] <Keybuk> like I said, the failure mode of that driver is a kernel panic
[11:11] <Keybuk> (or hang)
[11:31] <apw> cirtainly not ready for prime time in natty 
=== diwic is now known as diwic_afk
=== diwic_afk is now known as diwic
=== yofel_ is now known as yofel
[12:46] <czr> hughhalf, thanks for the ftdi-regression kick btw
=== jussi01 is now known as jussi
[13:02] <Keybuk> hmm, here's an interesting gmail test
[13:02] <Keybuk> if I tag all of LKML with one label
[13:02] <Keybuk> and I tag certain people with another
[13:02] <maco> they get two tags
[13:02] <Keybuk> if those people post to LKML, does the entire thread they post in end up under the other label
[13:02] <Keybuk> or just their posts?
[13:03] <maco> in imap or in gmail interface?
[13:03] <Keybuk> gmail interface
[13:03] <maco> entire thread
[13:03] <Keybuk> win
[13:19] <apw> yeah its all thread based as far as i know, 'conversations' sorry
=== jepler- is now known as jepler
=== doko__ is now known as doko
=== BenC__ is now known as BenC
[15:20] <cjwatson> apw: you're right, grub_memset doesn't act the way I thought
[15:20] <cjwatson> apw: http://paste.ubuntu.com/546286/ is no longer in a reboot loop for me - can you see if it fixes your problem?
[15:20] <cjwatson> (more or less the same as before, just with 'for (i = 0; i < n; i++) chosen[i] = -1;'
[15:20] <cjwatson> )
[15:22] <tgardner> cjwatson, apw is out for a bit. he should be back in an hour or so.
[15:22] <cjwatson> no rush
[16:13] <apw> cjwatson, will do
[16:13] <cjwatson> ta
[16:14] <apw> cjwatson, how funny we are back to the one combination i didn't test
[16:15] <cjwatson> heh, and the one I asked you not to test earlier
[16:15] <cjwatson> oh well
[16:15] <apw> cjwatson, shit happens every day, can't worry about such things that is for sure
[16:18] <apw> cjwatson, reality is if my machine compiled this thing faster i would have tested it, so i blame h/w
=== jj-afk is now known as jjohansen
[16:45] <apw> cjwatson, preliminary result is positive ... need to 100% confirm i have the right kernel bits but looking _good_
[16:45] <cjwatson> whee
[16:45] <apw> cjwatson, what _does_ grub_memset actually do as it doesn't set memory?
[16:45] <cjwatson> I got an ack from upstream for the previous version as well, so I don't think I need to get a separate ack for this one
[16:45] <cjwatson> it *does* set memory, it's a standalone memset
[16:46] <cjwatson> obviously there's some subtle typecasting mistake I missed, but I'm not really interested :)
[16:46] <apw> so really the question is why does it blow its brains out with memset and not with the loop
[16:46] <apw> fair enough indeed
[16:46] <cjwatson> this code is clearer anyway, as you observed earlier
[16:47] <apw> yeah it would need to be well large to make any significant difference we might care about
[16:49] <cjwatson> apw: shall I reassign bug 686705 to grub2 + me, then?
[16:49] <ubot2> Launchpad bug 686705 in linux (Ubuntu Natty) (and 1 other project) "System hangs at GRUB loading screen every warm boot since 2.6.37-3.11 seemingly due to nx-emu patch (affects: 1) (heat: 10)" [High,Confirmed] https://launchpad.net/bugs/686705
[16:50] <apw> cjwatson, ok stock kernel reboots just fine with that fixed grub
[16:50] <apw> so 'Tested-by: Andy Whitcroft <apw@canonical.com>'
[16:50] <apw> Sarvatt, about ?
[16:51] <Sarvatt> apw: yeah
[16:51] <Sarvatt> apw: http://paste.ubuntu.com/546286/ ?
[16:51] <cjwatson> committed upstream
[16:51] <apw> Sarvatt, i have some binaries for that if you could test
[16:52] <Sarvatt> sure thing! save me a year long compile :)
[16:52] <apw> cjwatson, yes all yours on the bug
[16:52] <cjwatson> Sarvatt: wuss
[16:52]  * Sarvatt digs out that machine
[16:52] <apw> http://people.canonical.com/~apw/misc/grub/ ... -pc and -common for i386 in there ... work on my box :)
[16:53] <apw> Sarvatt, yeah she isn't a quick build, about 15 mins here
[16:53] <Sarvatt> oh nice, it apparently hangs after a few days powered off too :)
[16:53] <cjwatson> you can always edit debian/control before building and comment out all the binary stanzas except grub-common and grub-pc; that speeds it up a fair bit
[16:53] <apw> Sarvatt, hrm!
[16:53] <cjwatson> random memory contents I suppose
[16:54] <cjwatson> not a huge surprised
[16:54] <cjwatson> *surprise
[16:54] <apw> cjwatson, normally the bios clears it doesn't it?
[16:54] <apw> you'd hope anyhow
[16:54] <cjwatson> I wouldn't like to rely on that
[16:54] <apw> but yeah it is odd it works reliably the first time if anything ... and perhaps it doesn't :)
[16:54] <cjwatson> wouldn't it take ages anyway?
[16:54] <apw> cjwatson, well it does on large machines yes
[16:54] <cjwatson> in bios terms
[16:55] <apw> though they have to as its all ECCd so has to be cleared to be used
[16:55] <apw> so perhaps not any more with small machines
[16:55]  * apw reboots that machine for the 4th time
[16:56] <apw> sucessfully!
[17:00] <rsalveti> apw: seems we're still missing a meta update for omap 4, the new kernel is there already but it's not being pulled by default
[17:02] <Sarvatt> apw: dingding we have a winner! :)
[17:02] <Sarvatt> 3 reboots fine so far
[17:02] <tgardner> rsalveti, which release?
[17:02] <apw> Sarvatt, thank $deity for that
[17:03] <apw> cjwatson, ^^ i think we have it nailed
[17:03] <rsalveti> tgardner: latest is linux-image-2.6.35-1101-omap4, and meta is 2.6.35.1100.1
[17:03] <tgardner> rsalveti, then you mean natty
[17:03] <apw> tgardner, natty
[17:03] <rsalveti> tgardner: oh, sure
[17:03] <cjwatson> apw: hooray
[17:03] <cjwatson> merging down the line through Debian experimental now
[17:03] <apw> cjwatson, we were lucky to find that one
[17:04] <tgardner> rsalveti, ok, gimme a bit
[17:04] <apw> tgardner, thanks
[17:04] <cjwatson> yeah
[17:04] <apw> cjwatson, i think i mostly noticied it cause they had also mucked up the size bit
[17:05]  * apw happily closes that one on his todo list
[17:05] <rsalveti> tgardner: sure, thanks
[17:05] <Sarvatt> apw, cjwatson: thanks a ton \o/
[17:06] <cjwatson> reassigned to me then
[17:06] <apw> kees, ^^-- seems that the 'NX issue' is indeed a grub bug and now fixed
=== jjohansen is now known as jj-afk
[17:06] <apw> cjwatson, well i learned a lot about grub2 (that i'd rather not have known) and had practice with quilt patches in debian, so overall worthwhile
[17:11] <tgardner> rsalveti, uploaded linux-meta-ti-omap4_2.6.35.1101.2
[17:12] <rsalveti> tgardner: great, thanks a lot!
[17:15]  * apw invokes marjo
[17:32] <cjwatson> sigh, "attempt to move .org backwards" only happens with gcc-4.4 not gcc-4.5, that explains why I didn't see it when working upstream
[17:33] <cjwatson> evidently gcc-4.5 generates slightly smaller code
[17:34] <kees> apw, cjwatson: \o/ so glad you guys found that. *whew* nice work. :)
[17:35] <apw> kees, i did think that i was going mad indeed
[17:35] <apw> cjwatson, that explains things
[17:35] <apw> -#define GRUB_KERNEL_I386_PC_RAW_SIZE		0xc90
[17:35] <apw> +//#define GRUB_KERNEL_I386_PC_RAW_SIZE		0xc90
[17:35] <apw> +#define GRUB_KERNEL_I386_PC_RAW_SIZE		0xca8
[17:35] <apw>  
[17:35] <apw> -#define GRUB_KERNEL_I386_PC_NO_REED_SOLOMON_PART 0x6f8
[17:35] <apw> +//#define GRUB_KERNEL_I386_PC_NO_REED_SOLOMON_PART 0x6f8
[17:35] <apw> +#define GRUB_KERNEL_I386_PC_NO_REED_SOLOMON_PART 0x710
[17:36] <apw> cjwatson, ^^ i used that on mine
[17:36] <kees> apw: I bet! I spent a few hours comparing the NX patches between maverick and natty trying to see any differences early on. :P
[17:36] <cjwatson> the growth is 20 bytes so I think I'll make it 0x70c
[17:36] <cjwatson> just to parallel that exactly
[17:36] <apw> cjwatson, sensible
[17:36] <apw> you do need to move both i think
[17:37] <cjwatson> yes, you're right
[17:37] <cjwatson> hm, wonder if it needs to be eight-byte-aligned
[17:38] <cjwatson> doesn't look like it, I think four-byte-aligned will do
[17:38] <apw> cjwatson, i'd be supprised if its not 4 or cache aligned ... ie 8 sounds unexpected
[17:38] <cjwatson> the code uses .p2align 2 in various places which is 4 bytes
[17:42] <cjwatson> ok, fixed that upstream too
[18:49] <apw> cjwatson, round and round :)
[19:17]  * tgardner --> lunch
[20:36] <tgardner> apw, I see 2.6.37-rc7 is out.
[20:37] <apw> tgardner, excellent will suck that up now, as i was about to do an upload
[20:37] <tgardner> apw, looks like it wasn't more then an hour orso ago
[20:37] <apw> tgardner, can't have been indeed as i updated about 2 hours ago to see myself
[20:38] <apw> tgardner, perfect timing, this means i can get the cciss bug uploading
[20:38] <apw> and unblock cert
[20:39] <tgardner> apw, I don't think its mirrored yet. I'm not getting the -rc7 tag
[20:39] <apw> tgardner, i get mine from master.k.o and it is there :)
[20:39] <tgardner> cool
[20:39] <apw>    b0c3844..90a8a73  master     -> linus/master
[20:39] <apw>  * [new tag]         v2.6.37-rc7 -> v2.6.37-rc7
[21:18] <tgardner> apw, do you know anything about the ALSA c-o-t-d builds?
[21:27] <apw> tgardner, hmmm, no not really i think they are bjf's fun arn't they
[21:28] <tgardner> apw, well, he's got the right perms on his zinc repo, so I was able to push an ABI bumper commit.
[21:28] <tgardner> hopefully the automated scripts will pick it up
[21:29] <apw> tgardner, ahh i see ... they run on tang i think
[21:30] <tgardner> apw, do you suppose he pulls from his zinc repo?
[21:30] <apw> tgardner, may i suggest you add the subject to the rally agenda, so he can document/transfer the knowledge
[21:31] <tgardner> apw, what a good idea :)
[21:31] <apw> tgardner, ok not tang then as he only makes the isos there
[21:32] <tgardner> apw, dang, linux-meta_2.6.35.24.29_source.changes rejected again. wtf?
[21:32] <apw> bubble
[21:33] <hughhalf> czr (belatedly - you're welcome)
[21:33] <tgardner> apw, I think I've lost interest for the day. see you in my AM
=== jk-- is now known as jk-