[12:17] <BenC> if so, isn't it "fixed" by not disabling the wireless?
[12:18] <cassidy> BenC: yes it is
[12:18] <cassidy> but i like my wireless ;)
[12:18] <BenC> I don't get it, I thought the bug only occureed when wireless was disabled on boot
[12:19] <bronson> cassidy: so don't disable it...?
[12:20] <kylem> BenC, we can take this patch, it looks sane.
[12:20] <cassidy> it's strange in fact. I had this bug booting Herd 1 CD. Try to disable it and still have the problem. But retry after and then work
[12:20] <kylem> http://bughost.org/bugzilla/attachment.cgi?id=956
[12:20] <BenC> "I have been booting daily with wireless switch on two weeks and the problem has not occured. Today I booted with the Wireless switched off and had soft lockup on CPU0"
[12:20] <BenC> kylem: My main question was why Intel hasn't taken it
[12:21] <BenC> could be because they are moving on to that new driver
[12:21] <BenC> kylem: But yeah, for edgy it looks sane
[12:21] <kylem> i don't think ketrenos has done much recently.
[12:21] <kylem> the problem with this softlockup stuff is noone ever seems to post their dumps, so we have no idea if it's the same bug...
[12:22] <kylem> BenC, the bug is in ipw3945 1.1.3
[12:22] <kylem> er
[12:22] <kylem> the bug fix
[12:22] <BenC> is there a 1.1.3?!
[12:23] <BenC> there wasn't when I checked just YESTERDAY
[12:23] <BenC> kylem: Does it have better fixes for the INIT_WORK crud?
[12:23] <kylem> was released today
[12:24] <kylem> INIT_WORK() is still muckered in it.
[12:24] <BenC> we can probably do a diff between 1.1.2 and 1.1.3 and apply it
[12:24] <kylem> they all take priv though, so the fix when they do take it is going to be the same as what you or i did
[12:25] <kylem> hm, i'll do it, shouldn't be too much pain.
[12:42] <BenC> kylem: I think ipw3945 was one of the ones where there was more to it than that
[12:42] <BenC> I have to check
[12:43] <BenC> some of them were using work and delayed work interchangeably, which is totally broken now
[12:43] <BenC> yep, it is
[12:43] <kylem> eh, i was just going to pull out your diffs and reapply on top of 1.1.3
[12:43] <kylem> <- lazy... ;)
[12:43] <BenC> probably easier to get 1.1.2 and 1.1.3 and diff them, and apply to ours
[12:47] <BenC> kylem: Looks like either way is going to be a pain
[01:01] <kylem> it's not big a deal
[01:18] <zul> BenC: i like the new kernelpatches page and the gratitious use of xen as an example ;)
[01:18] <BenC> zul: You noticed that, huh? :)
[01:18] <zul> yeah..
[01:19] <zul> you should rename it whyihatexen
[02:40] <kylem> BenC, you weren't kidding.
[02:52] <BenC> kylem: have fun :)
[03:00] <kylem> heh. i'm amazed this built for you.
[03:00] <kylem> ipw3945 was still missing some delayed stuff.
[03:00] <kylem> but would still work b/c struct work_struct is the first member of the delayed_work struct.
[03:01] <BenC> There's actually a bit of stuff in ubuntu/ that still needs delayed work help
[03:02] <BenC> mostly some of the many (I hate them) ieee80211 stacks
[03:03] <kylem> yeah.
[03:03] <kylem> i'm fixing those up now.
[03:03] <kylem> i hate david howells. :)
[03:23] <kylem> ugh.
[04:07] <zul> night folks
[05:58] <kylem> jesus. that took way longer than i'd expected.
[06:16] <kylem> BenC, fixes for wireless/ and updated ipw1.1.3 pushed out to my ubuntu-2.6 kernel.org tree.
[06:16] <BenC> kylem: Thanks
[06:23] <BenC> kylem: pulled and pushed, and compile tested
[06:23] <BenC> looks good
[06:24] <kylem> btw, in your rt2x00 i'm not sure about the nested container_of
[06:25] <kylem> i think it might need to be: container_of( &container_of( ... ), ...)
[06:26] <BenC> the container_of returns a pointer, so it should be ok
[06:26] <BenC> plus it doesn't give a warning either :)
[06:26] <kylem> ah, ok
[06:27] <BenC> kylem: I'm doing some build/boot testing tomorrow...if things look ok, I might do an upload, but without lrm and linux-meta
[06:28] <kylem> alrighty.
[06:32] <BenC> 2.6.20 scares me
[06:33] <kylem> churn churn churn :)
[06:33] <BenC> between the workqueue changes, paravirt, and now a brand new HID layer, I'm frightened
[06:33] <kylem> so feisty is totally vetoed from being LTS, k? :)
[06:34] <BenC> definitely
[06:46] <zul> paravirt shouldnt matter if you dont enable it
[06:46] <zul> ..couldnt sleep
[06:48] <BenC> it's not enabled, but I doubt that it's a noop code wise even disabled
[06:49] <zul> true
[09:22] <bronson> Anyone in today?  Is there an easy way to create a new ABI?
[09:23] <bronson> I'm getting the "ABI has changed!" message and I'd just like to tell it, THIS is the new ABI...
[09:23] <bronson> Can't find any docs on how to do that though.
[09:24] <kylem> increase the major version # in debian/changelog
[09:24] <kylem> ie the xx part of 2.6.17-xx.yy
[09:26] <bronson> ah, good.  Thanks kylem.
[09:28] <bronson> I hope I'm getting close to having a good kernel.  What's the best way to show it to you guys to see if it could become a part of Ubuntu proper?
[09:28] <bronson> (not as a patch, as a set of kernels that live beside the main kernels)
[09:34] <bronson> Just publish my git tree?
[09:36] <kylem> probably easiest for you, yes
[09:46] <bluefoxicy> how do I rebuild 2.6.19-7-generic from source... I can't find the right debian/Config stuff
[09:46] <bluefoxicy> oh.. downloaded the source wrong
[09:48] <bluefoxicy> ls
[10:07] <bronson> Seems a little silly to publish hundreds of megabytes of git archive so you can pull a few K of patches but so be it.  :)
[10:07] <kylem> just extract the patches and post them then :)
[10:08] <bronson> what would be the easiest for you?
[10:08] <kylem> git format-patch -k ${commit before you changed anything}
[10:08] <kylem> i'm happy either way, it's ben you need to make happy :)
[10:09] <bronson> good point.  :)  I'll ask again on Monday.
[10:18] <BenC> bronson: Post patches using format-patch to kernel-team@l.u.c
[10:18] <BenC> that's easy
[10:18] <bronson> BenC: the linux-vserver patch is huge though...
[10:18] <bronson> My changes are like a few hundred bytes of patch...  upstream though is, ah, invasive.  
[10:19] <bronson> I think it'll be ~200K...  think that's OK?
[10:25] <bronson> Why am I even asking...?  I'll post both the patch and the git tree and let the reader decide.
[10:25] <bronson> Duh.  Time for me to get outside.
[10:36] <bronson> WARNING: sound/oss/cs4232.o - Section mismatch: reference to .init.text: from .text between 'cs4232_pnp_probe' (at offset 0x7c) and 'unload_cs4232'
[10:36] <bronson> I can ignore all these warnings, yes?
[10:36] <kylem> yeah.
[10:36] <bronson> thank goodness.  :)
[11:46] <BenC> bronson: Are you posting it to be included in our tree?
[11:46] <bronson> No way.
[11:47] <bronson> Just hoping, perhaps, to include it with Feisty.
[11:47] <bronson> But first I'm doing the easier task of getting it solid in Edgy.
[11:48] <bronson> So, I'm very interested in your input.
[11:49] <bronson> I mean, compile separate packages in a separate tree that would be included in Feisty's Universe or Multiverse.