[14:14] <ppisati> reboot
[15:42]  * ogasawara back in 20
[15:43] <diwic> bjf, latest update for c-o-t-d 2.6.38 seems to have been 2011-05-05 
[15:43] <bjf> diwic, that was the first and only, was waiting feedback
[15:44] <diwic> bjf, aha 
[15:44] <bjf> diwic, i can fire off another if desired
[15:45] <diwic> bjf, if it's simple, please do
[15:45] <bjf> diwic, will do
[15:53] <diwic> bjf, meanwhile I installed the package and it seems to work fine, so I think you're good to go for enabling daily builds for Natty as well
[15:53] <bjf> diwic, just uploaded a new one, thanks for the feedback, will start doing them automatically
[15:55] <diwic> bjf, thanks!
[15:57] <bjf> diwic, added, if you see any issues with it now, don't hesitate to mention it/them
[16:38] <JFo> bjf, how would I add that kernel call to my collection?
[16:38] <JFo> I tried by the URL, but no joy
[16:38] <JFo> and I am too stupid just now to figure it out :)
[16:38] <bjf> um, one sec
[16:40] <hggdh> bjf, sconklin: I do not see any pending karmic kernel to be tested. Am I missing something?
[16:41] <bjf> hggdh, looks like someone went ahead and promoted the karmic kernel to updates
[16:41] <bjf> skaet, ^
[16:41] <skaet> bjf, hggdh,  looks like we have a process failure then.
[16:41] <skaet> :P
[16:42] <hggdh> well, we can still go ahead and validate it, just in case
[16:42] <skaet> hggdh,  please do so.
[16:42] <bjf> JFo, did you get some notice about that calendar? i just added you to the share list
[16:42] <skaet> I'll take this up with pitti and see if we can figure out what happened.
[16:43] <hggdh> k
[16:43]  * JFo looks
[16:43] <JFo> bjf, looks like it just showed up in my main calendar now. Thank you :)
[16:44] <bjf> JFo, np
[16:44] <skaet> hggdh,  please let me know if there's any problems with it, soonest.   
[16:45]  * apw pops out to get a replacement hdmi cable
[16:50] <bjf> ogasawara, we going to do a status meeting this week ?
[16:51] <ogasawara> bjf: yep, that's the plan
[16:52] <bjf> ogasawara, always good to have a plan, do we have a list of blueprints we are going to be tracking ?
[16:52] <ogasawara> bjf: https://wiki.ubuntu.com/KernelTeam/Specs
[16:53] <bjf> ogasawara, we're going to want all of them on the agenda or you want me to pick the ones I think are relevant?
[16:54] <ogasawara> bjf: I'd only pick out the relevant ones.
[16:54] <bjf> ogasawara, ack
[17:06] <bjf> ogasawara, i've updated the meeting agenda, most of the blueprints are for you, let me know if there are others you think should be added
[17:06] <ogasawara> bjf: ack
[17:10] <ogasawara> bjf: I'm gonna move the one work item from the misc blueprint to the server-reqs blueprint and then we can just drop the misc blueprint from the agenda
[17:12] <bjf> ogasawara, wfm
[17:43]  * apw notes that plugging and unplugging hdmi outputs on intel leads to crashes :/
[17:46] <jjohansen> apw: is that with the latest intel driver?
[17:56] <apw> jjohansen, with whatever is latest in natty
[17:56] <apw> now on a .39 kernel shall see if its any better
[17:56] <jjohansen> apw: ah there where some hdmi improvements in the latest intel drm tree, not sure what made it into .39 though
[17:58] <apw> jjohansen, ok will see how this pans out
[19:06] <JFo> ogasawara, just saw your response :-)
[19:11] <ogasawara> JFo: pick a time when you want to start your kernel patching and git-fu, I'll put it in my schedule.  not sure it'll require a full hour each week, but we should just start
[19:11] <BenC> Any chance that bug #424142 will get fixed in lucid's kernel?
[19:11] <ubot2> Launchpad bug 424142 in linux "Address Collision" [Undecided,Confirmed] https://launchpad.net/bugs/424142
[19:11] <BenC> I've just had a couple customers get bit by it, upgrading them to maverick kernel fixed it
[19:13] <JFo> ogasawara, right, my hope is that some of these will taper off and not be needed.
[19:14] <JFo> just wanted to get them started and indicate how serious I am about them to everyone :)
[19:16] <BenC> I suspect no, since linux-lts-backports-maverick is available
[19:19] <ogasawara> BenC: if it came through the next 2.6.32.y upstream longterm release, it'd get applied to Lucid.  or use the backports kernel.
[19:21] <BenC> ogasawara: No chance of someone actively searching for the fix? Isn't 2.6.32.y inactive? :)
[19:22] <ogasawara> BenC: I thought 2.6.32.40 just came out, was that the last one?  /me hasn't been following
[19:22] <BenC> wait, I didn't realize upstream was maintaining longterm kernels now, so hopefully they do a 2.6.32.y to fix it
[19:24] <bjf> BenC, GregKH still maintains .32
[19:25] <sforshee> BenC, ogasawara: looks like the fix was in 2.6.33 (commit 8c8def26) so it just never made its way to stable
[19:25] <BenC> Right, I knew it was fixed in 2.6.33, was just hoping for some love in lucid, even if 2.6.32.y isn't getting it upstream
[19:26] <sforshee> I'm just saying that if we wait for it to show up in .32 stable it's never going to happen
[19:26] <BenC> That's exactly what I'm saying :)
[19:27] <bjf> sforshee, you want to do an SRU for it?
[19:28] <sforshee> bjf, sure, I'll try to get some testing on it first to make sure it really fixes the problem
[19:28] <bjf> sforshee, that looks like a reasonable candidate
[19:28] <bjf> wfm
[19:29] <bjf> sforshee, looks like BenC might be able to help test :-)
[19:29] <BenC> Customers gave me sudo access to the affected machine, so I plan to abuse it as much as possible...
[19:30] <ogasawara> hehe
[19:30] <BenC> if you get something testable, I'm happy to toss it on there
[19:30] <sforshee> BenC, I'll post a kernel to the bug report shortly, then I'll submit it for SRU as soon as you can get it verified
[19:31] <bjf> sforshee, not a rush, just information, if you can get a fix verified soonish, we are prep'ing kernels for the next cadence cycle
[19:31] <sforshee> bjf, ack
[19:32] <BenC> sforshee: ok, please ping me on here, launchpad traffic doesn't get through my usual filters
[19:33] <sforshee> BenC, will do. If you tell me whether you'll use a 32-bit or 64-bit kernel for testing I'll make sure the one you need is built first.
[19:34] <BenC> sforshee: Thanks, 32-bit
[19:43] <BenC> sforshee: this patch doesn't affect ABI, correct?
[19:43] <sforshee> bjf, would you be so kind as to accept the lucid nomination on bug #424142 ?
[19:43] <ubot2> Launchpad bug 424142 in linux "Address Collision" [Undecided,Confirmed] https://launchpad.net/bugs/424142
[19:44] <sforshee> BenC, it shouldn't
[19:44] <BenC> if it does, I would need to get the headers to fully test against this module
[19:44] <bjf> sforshee, you bet
[19:44] <BenC> sforshee, bjf: a huge thanks for the effort on this as well
[19:44] <bjf> BenC, np
[19:44] <sforshee> BenC, I'll give you the headers, but as it only changes a function body it shouldn't affect the abi at all
[19:45] <bjf> sforshee, done
[19:45] <sforshee> bjf, thanks
[19:45] <BenC> sforshee: I could have approved it for you :)
[19:53] <sforshee> BenC, 32-bit test build is posted at http://people.canonical.com/~sforshee/lp424142/2.6.32-32.62~lp424142v201105231936/
[19:54] <herton> bjf: can you approve nominations for bug 787145
[19:54] <ubot2> Launchpad bug 787145 in linux-ti-omap4 "CVE-2011-1494" [Undecided,New] https://launchpad.net/bugs/787145
[19:55] <bjf> herton, working it
[19:56] <bjf> herton, done
[19:56] <herton> thanks bjf
[19:56] <bjf> np
[20:26] <BenC> sforshee: ok, give me 30 minutes
[21:03] <BenC> sforshee: not stalling...this box doesn't boot unattended so I'm just waiting for some one to kick it
[21:03] <BenC> sforshee: I've at least smoke tested here locally, but not on a box that exhibits the problem
[21:07] <sforshee> BenC, cool, I've got everything ready to go for once we know it fixes the problem
[22:22] <BenC> sforshee: confirmed that it fixes the issue, and commented on the bug report
[22:26] <shankara>  hi all, i'm having a weird issue trying to reboot with linux 2.6.38 (x86_64), ubuntu LTS 10.04, this is on atom D525 - dual core atom
[22:26] <shankara> system hangs on restart with: "will now restart" and then "[<some varying number>] Restarting system"
[22:27] <shankara>  i've tried recompiling a variety of kernels
[22:27] <shankara> i've even compiled specifically for the atom, not using generic
[22:27] <shankara> same issue. but soft halt works fine
[22:27] <shankara> is this a known kernel support issue with atom dual core cpus ?
[22:28] <BenC> shankara: It sounds like an issue with the kernel you are compiling, like a panic, maybe related to your root filesystem
[22:28] <BenC> Sounds suspiciously like you are just compiling the kernel wrong
[22:29] <BenC> shankara: And specifically, it sounds like an issue you just have to figure out through more generic channels #kernelnewbies perhaps?) since it isn't an Ubuntu issue
[22:29] <shankara> BenC: i found this on the generic default kernel that  came with lts 10.0.4
[22:29] <BenC> You said it was 2.6.38
[22:29] <shankara> after a couple of binary kernels, i decided to compile my own
[22:29] <shankara> same issue
[22:29] <bjf> shankara, have your tried our lts-backport kernel?
[22:29] <shankara> that's the most recent kernel i tested
[22:30] <shankara> bjf: not yet, maybe i should
[22:30] <shankara> i only  resorted to source compiles after all the binary kernels in the apt repo gave me the same  soft reboot issue
[22:31] <BenC> shankara: Booting with single (so without quiet) would be more helpful
[22:31] <BenC> The reason for the panic might give some clues to the real problem
[22:32] <shankara> BenC: i'm inclined to the some clues to the real problem might provide a reason for the panic
[22:32] <shankara> actually ... i wouldn't say it's a panic
[22:32] <shankara> there's no "ooops"
[22:32] <BenC> I would say it is a panic
[22:32] <shankara> it jsut doesn't actually restart the hardware, just promises to
[22:32] <BenC> The "will not restart" message comes right after a panic
[22:32] <BenC> err "will now restart"
[22:33] <BenC> shankara: If it fails to exec /sbin/init or similar, it will panic
[22:33] <BenC> panic != BUG
[22:33] <shankara> Benc: yes, sorry: "Will now restart"
[22:33] <BenC> it means "oh crap, I don't know what to do next"
[22:34] <shankara> BenC: it actually get's past stopping all system services, unmounting all filesystems ... then it jsut doesn't , so it seems init runs it's full course
[22:34] <shankara> sorry "then it just doesn't restart the hardware"
[22:34] <BenC> shankara: Do you mean it will actually boot, just not reboot?
[22:35] <shankara> it'll boot, it'll even halt. Just it wil not soft restart
[22:35] <shankara> ctrl-alt-delete has the same effect - no restart
[22:35] <BenC> Oh, I misread "trying to reboot with.." as "trying to reboot into..."
[22:35] <BenC> shankara: I have some tips for this problem...
[22:36] <shankara> yeah, it's a weird one
[22:36] <shankara> most people are trying to boot their boxes, I'm trying the opposite
[22:36] <shankara> restarting is critical for remote support on appliances
[22:37] <BenC> shankara: Try adding reboot=bios to your kernel command line
[22:37] <shankara> BenC: let me try that and get back to you 
[22:37] <BenC> shankara: reboot=acpi might be worth trying too
[22:37] <shankara> ack.
[22:38] <sforshee> BenC, just sent SRU patch to kernel-team list, thanks for testing
[22:40] <BenC> sforshee: np, thank you for taking on the logistics to get it in an SRU
[22:43] <broder> is there anything i can do to accelerate getting help with bug 784335? i don't really have any kernel debugging-fu, but the machine in question isn't my primary machine and doesn't have any data on it, so i can re-install or re-configure it 10 ways to sunday if that helps
[22:43] <ubot2> Launchpad bug 784335 in linux "Heavy network utilization with r8169 leads to kernel panic" [Undecided,Confirmed] https://launchpad.net/bugs/784335
[22:45] <BenC> broder: I would argue that r8169 is a horrid driver and would suggest you'd have better luck wedging an e1000 card in there :)
[22:45] <BenC> but I'm not the official spokesperson, so I digress
[22:47] <BenC> broder: a pic of the on-screen panic would help
[22:47] <broder> BenC: is the core dump not good enough?
[22:49] <BenC> broder: I'd have to set aside time to dig into that, perhaps later tonight
[22:55] <broder> if i were to go and play the role of the apport retracer, would that get the bug more attention?
[22:59] <shankara> BenC! you're a genius! reboot=acpi worked :D
[22:59] <shankara> thanks!
[23:02] <TheSeven> as some people seem to be awake currently, I'd like to re-ask my question from like a week ago: http://paste.ubuntu.com/612064/
[23:02] <TheSeven> any hints?
[23:04] <JFo> TheSeven, have you filed a bug?
[23:06] <TheSeven> no, as i don't have a clue what to file it against
[23:06] <TheSeven> this kinda seems to be an OMAP or ARM specific problem
[23:07] <TheSeven> but it doesn't seem like the OMAP guys would know what's the cause for it
[23:08] <TheSeven> so i'd like to check if there are any general hints for situations like this (some tunables maybe?)
[23:08] <JFo> so you would file it against linux which encompasses all of them and then I would go about determining if it was specific to one of them.
[23:09] <JFo> very simple process too... from a term run 'ubuntu-bug linux'
[23:09] <TheSeven> the maximum throughput being at a sub-sector block size and the fact that it happens both with USB and SD makes me think that this can't really be coming from the MMC/USB controller, but must be coming from some generic I/O code
[23:09] <JFo> presto! bug report! :-) How is that for the soul of ease? :)
[23:09] <JFo> very possible
[23:10] <JFo> but I would like to see the logging we collect from the bug report tool to dig a bit deeper.
[23:10] <JFo> so when it is behaving thus, if you could file that bug it would be most helpful
[23:20] <TheSeven> JFo: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/787246
[23:20] <ubot2> Launchpad bug 787246 in linux-ti-omap4 "Slow SD card and USB HDD I/O for block sizes bigger than a couple of bytes" [Undecided,New]
[23:22] <broder> BenC: does http://pastebin.ubuntu.com/612078/ look like it has the information you wanted?
[23:22] <broder> i'm not super-familiar with digging around in vmcores
[23:41] <hggdh> smb: there?
[23:47] <jjohansen> hggdh: its pretty late in the day for smb to be here (00:47) for him
[23:48] <hggdh> jjohansen: yeah, I had just remembered he is UTC+1 or 2...
[23:48] <hggdh> jjohansen: perhaps you -- I am unable to boot the curretn maverick proposed on AWS, i386/m1.small
[23:49] <jjohansen> ugh, I can have a look
[23:51] <hggdh> jjohansen: what do you need?
[23:52] <jjohansen> hggdh: hrmm, nothing just yet.  I will boot an m1.small and install a proposed kernel and try to duplicate, and go from there
[23:53] <jjohansen> hggdh: actually, which region/zone, and even machine type if you can get that info
[23:53] <hggdh> jjohansen: OK. What I did -- what I always do --: I booted the current AWS Maverick, then run a dist-upgrade with -proposed enabled
[23:53] <jjohansen> hggdh: right, I think I will be a little more selective and just pull the kernel
[23:54] <hggdh> jjohansen: ec2-run-instances ami-b21de3db --instance-type m1.small --region us-east-1