[00:17] <doctormo> What should I do to fix a known kernel issue to do with a net driver? information follows...
[00:18] <doctormo> I have 10 client machines, each with the same e1000 network card
[00:18] <doctormo> The e1000 driver has a bug which doesn't allow the machine to be shutdown once it's been booted using wakeonlan.
[00:18] <doctormo> See bug:  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/691479
[00:18] <ubot2> Launchpad bug 691479 in linux "HP Computer won't shutdown after WOL" [Undecided,Confirmed]
[00:18] <doctormo> The problem I have is how to apply the linked patch to client machines without manually going to each machine and breaking their upgrade path.
[00:19] <bjf> doctormo, hold one
[00:19] <doctormo> I thought about using dkms, but trying to fit e1000 into a dkms package has been a challenge that I can't beat yet. bjf, yes, holding...
[00:22] <bjf> doctormo, ok, looking at that "patch", it's not something we'd take because it's obviously just a hack
[00:22] <doctormo> bjf: Yes, I can understand that. But there is no known fix otherwise.
[00:22] <bjf> doctormo, do you know if this has been fixed upstream
[00:23] <doctormo> OK, so I've tested with 2.6.38 so far, I can't test beyond that yet.
[00:23] <bjf> doctormo, and .38 has the same issue?
[00:23] <doctormo> yes
[00:33] <bjf> doctormo, there have been changes to that driver since .38 so it's possible it got addressed, however I don't see anything that really jumps out as a fix for that issue
[00:33] <bjf> doctormo, have you opened an upstream bug on it or sent email to the maintainer?
[00:35] <doctormo> I don't know how to do that.
[00:39] <bjf> doctormo, so looking at the email thread on e1000-devel, it looks like the upstream tried to help the bug reporter but the bug reporter wasn't able to test much
[00:39] <bjf> doctormo, also, they may not have been able to reproduce the issue in-house
[00:41] <bjf> doctormo, i'd suggest either adding to that thread with your own report and offer to help test, or try a new email to that mailing list
[00:41] <bjf> doctormo, other than that, yes, a DKMS driver is a lot of work
[00:42] <bjf> doctormo, also the upstream suggested making sure you are running the latest BIOS version
[00:42] <doctormo> bjf: Yes I looked at the latest bios, they say nothing about fixing the wake on lan.
[00:43] <bjf> doctormo, but did you test the latest BIOS, they may not have documented that fix
[00:44] <doctormo> bjf: I will test it and bare a grudge if it works :-)
[00:44] <bjf> doctormo, heh, i'd really suggest an email to the development mailing list
[00:44] <doctormo> thanks for your help bjf
[00:45] <bjf> doctormo, np, didn't really do anything
[00:45] <doctormo> bjf: Your time is worth at least my thanks.
[00:45] <bjf> doctormo, your welcome and don't be afraid to come back
[00:46] <bjf> doctormo, if you can find a real fix, let us know and we can spin a test kernel for you pretty quickly
[00:52] <doctormo> bjf: Heh, an entire kernel.
[00:52] <doctormo> I had an idea that we should somehow force kernel developers to have dkms packages for every single non-core driver ;-)
[00:53] <doctormo> Email sent to mailing list.
[01:04] <azop> doctormo: so a kernel upgrade would take ~2 hours to compile all of the DKMS packages?
=== bryceh is now known as bryce
[02:14] <hallyn> jjohansen: i can't get a kernel with his config to boot in qemu.  it just scrolls constantly looking like it's finding devices but never finishes booting
[02:15] <hallyn> jjohansen: and a stock natty image doesn't reproduce the claimed bug
[02:43] <hallyn> jjohansen: gah, i can't reproduce with my userns tree, or with natty (which doesn't have my patchset), but can with our daily ppa
=== hallyn is now known as hallyn_afk
[04:14] <jjohansen> hallyn_afk: hrmm, okay.  I'll take a peek at it in a couple hours
=== _LibertyZero is now known as LibertyZero
=== smb` is now known as smb
[08:16]  * apw yawns
[08:18] <cooloney> apw: morning man
[08:19] <apw> cooloney, morning, how you ? 
[08:19] <cooloney> apw: very good, working on my Irish visa.
[08:20] <apw> heh, so very many visas required, and i bet they all last 6 months so they are out of date by next time
[08:22]  * smb is glad he has not to do so every journey
[08:22] <cooloney> i need apply visa every time when i'm travelling to EU
[08:23] <cooloney> next time, i will try to apply 1 year multi entry schegen visa 
[08:23] <cooloney> but Ireland is not Schegan states
[08:24] <apw> bah what a pain
[08:41] <smb> cking, morning old man
[08:41] <cking> smb, morning, I'm not *that* old ;-)
[08:42] <smb> cking, At least you should now be wise and know the answer. :)
[08:42] <cking> heh
[08:54] <smb> apw, cking Hows the view up there? Seems there is a volcano remembrance event going on. :-P
[08:55] <apw> smb, sky is clear and blue where i am
[08:55] <htorque> apw: morning! bug 787610 - i'm pretty sure i've found the commit that's responsible for the hangs. should i report this upstream?
[08:55] <ubot2> Launchpad bug 787610 in udev "System fails to boot with Intel HD graphics" [Undecided,New] https://launchpad.net/bugs/787610
[08:55] <smb> Not that we would have seen much last time (even more being away)
[08:55] <jussi> Good morning alll
[08:55] <apw> htorque, is it reported in out bug too ?
[08:56] <jussi> Just had a total freeze of the PC, even reisub didnt help. Anyone feel like helping me diagnose this ?
[08:56] <apw> htorque, and which commit it is?  kernel or udev ?
[08:56] <htorque> apw: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=ff2c503df091e6e4e9ab48cdb6df6ec8b7b525d0
[08:58] <jussi> apw: is it possible the bug I reported yesterday can manifest itself without dropping to the console as it did then? 
[09:00] <apw> htorque, oh man, they have changed socket type .... and rewritten the code completely ... bah
[09:02] <apw> and from the error i guess its when we restart udev across the chroot into / from the initramfs that we hit adrr in use
[09:02] <cking> smb, all clear here, blue sky, no dust
[09:04] <smb> cking, Yeah, did not really expect something to see. There have been two airports affected in the north last time I looked.
[09:05] <smb> cking, Three by now it seems
[09:15] <mnemoc> hi, for this sort of crash http://dpaste.com/546289/ resuming an pure-efi laptop (thinkpad x120e) after suspend, what sort of bug report should I do? (natty/64)
[09:16] <apw> htorque, so have you backed that one out to confirm?
[09:16] <mnemoc> usually it just locks up, this time magically resurented after some minutes with the panel black
[09:17] <apw> mnemoc, that tells you your resume was slow and nothing more, the bits before that in the log are the key information
[09:17] <mnemoc> 1m
[09:17] <apw> mnemoc, do you have the preceeding lines?
[09:17] <mnemoc> yes, let me post it
=== chrisccoulson_ is now known as chrisccoulson
[09:19] <mnemoc> apw: http://dpaste.com/546291/
[09:20] <htorque> apw: i rebooted the revision before that commit ten times without a problem where the offending commit failed 6/10 times
[09:20] <apw>  htorque ok thanks, just checking something, as i have a theory
[09:25] <mnemoc> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/769812 is related to freezes with the wifi driver, but comments imply they are also experiencing freezes on resume
[09:25] <ubot2> Launchpad bug 769812 in linux "X120e crashes randomly (wireless?)" [Undecided,Confirmed]
[09:28] <apw> mnemoc, from that log i'd guess its one or more usb devices.  i think a camera and maybe some kind of storage got borked.  possibly the controller got lost in the d/r
[09:28] <apw> s/r
[09:28] <apw> mnemoc, anyhow file a bug against linux (ubuntu-bug linux) and attach that entire log
[09:29] <mnemoc> apw: thanks a lot, i will now
[09:30] <jussi> Nobody interested to help me get this reported :/
[09:32] <apw> htorque, ok i think i see a possible bug ... not sure why the old version is not also susceptable though
[09:36] <mnemoc> apw: done, thanks :) https://bugs.launchpad.net/ubuntu/+source/linux/+bug/787980
[09:36] <ubot2> Launchpad bug 787980 in linux "thinkpad x120e freezing on resume" [Undecided,New]
[09:38] <apw> mnemoc, did you say this is an efi machine ?
[09:39] <mnemoc> apw: yes, it's in pure-efi mode
[09:39] <mnemoc> apw: should I attach the output of something else?
[09:40] <apw> mnemoc, nothing i know of, but i am no efi expert
[09:41] <apw> mnemoc, is this a sandy bridge machine ?
[09:43] <mnemoc> apw: amd e-350 "fusion"
[09:44] <apw> which graphics drivers are you using mnemoc ?
[09:44] <mnemoc> currently fglrx, not sure if I was getting freezes with the radeon
[09:45] <apw> well that is a good test to know the answer to
[09:45] <mnemoc> apw: ok, i'll uninstall fglrx
[09:45] <apw> binary drivers don't have a good record with suspend/resume
[09:50] <mnemoc> lovely, blank screen.... but I have ssh in
[09:52] <apw> mnemoc, after s/r ?n
[09:52] <mnemoc> no, reboot after uninstalling fglrx, same after a second reboot
[09:52] <apw> mnemoc, try nomodeset on the kernel command line
[09:53] <apw> damn amd and their lack of specs
[09:53] <apw> (or drivers that work)
[09:53] <mnemoc> but 12s since `sudo reboot` to ssh is nice :)
[09:54] <apw> heh thats something i guess, make a nice little server perhaps
[09:55] <mnemoc> mnemoc: nomodeset worked
[10:08] <apw> mnemoc, ok could you file a second bug against xserver-xorg-video-radeon saying you need nomodeset as well
[10:09] <apw> and get me the number of that one too
[10:09] <apw> mnemoc, then pls do test s/r in this combination and see if that works, and report on that in the first bug
[10:12] <mnemoc> apw: 2m an still hasn't returned from s/r :(
[10:12] <mnemoc> and*
[10:13] <apw> so likely the issue is not graphics related
[10:13] <apw> as you changed the drivers and its still there
[10:13]  * mnemoc nods
[10:13] <apw> (binary drivers related should i say)
[10:13] <apw> did this ever work for you or is natty the first install on it
[10:14] <mnemoc> apw: yes, was natty is the first install
[10:15] <mnemoc> btw, I do get beeping when connecting/disconnecting the power, so "something" is alive
[10:15] <apw> thats likely the EC which is outside the OS
[10:15] <mnemoc> ok
[10:20]  * mnemoc powercycling
[10:30] <mnemoc> apw: btw, what's the right place to `dmesg -n8` on init?
[10:30] <mnemoc> (for a netconsole)
[10:30] <apw> mnemoc, hmn  no idea
[10:30] <apw> mnemoc, the next thing to try probabally is taking the latest maverick kernel and install that and see how that behaves
[10:32] <mnemoc> from the last boot I only received one line on the netconsole :-/ "[drm:drm_mode_getfb] *ERROR* invalid framebuffer id"  ... pretty useless for debugging
[10:43] <apw> mnemoc, oh and of course you can try the latest oneiric kernel, if we can find one which works we have some hope of fixing one or other of these bugs
[10:50] <mnemoc> apw: do you suggest to go forward or backward first?
[10:56] <mnemoc> apw: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/788021
[10:56] <ubot2> Launchpad bug 788021 in xserver-xorg-video-ati "Radeon HD 6310 (amd e-350 zacate) needs nomodeset" [Undecided,New]
[11:14] <apw> cking, your fwts blueprint has no work-items yet ...
[11:15] <apw> cking, and tommorrow is feature definition freeze, when we're meant to have work defined :)
[11:16] <apw> actually cking are these ACTIONS meant to be work items ?
[11:26] <cking> apw, thanks for the prod, I'm onto it in a mo
[11:28] <soren> https://lists.ubuntu.com/archives/ubuntu-server/2011-May/005676.html  <--- This looks like something for you guys
[11:31] <apw> cking, if those actions are meant to be work-items i can convert them
[11:32] <cking> apw, I need to work through it and break it up into some sane steps
[11:32] <apw> soren, as far as i know his cpu won't be able to run userspace either
[11:33]  * apw lets smb reply as he is likely subscribed to that list
[11:47] <soren> apw, smb: I can let it through the moderation queue if you're not subscribed.
[11:59] <mnemoc> hi, i've totally failed to find what's the "right way" (tm) of installing oneric's kernel in natty? is there is ppa I've failed to find? or I must use git and build manually?
[12:00] <mnemoc> or just take the .deb from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.39-oneiric/ ?
[12:04] <apw> mnemoc, use the official build from the launchpad librarian:https://www.launchpad.net/ubuntu/+source/linux
[12:10] <mnemoc> apw: but how? :( fetching and installing all .deb manually?
[12:10] <apw> mnemoc,yes there is no automated way
[12:10] <mnemoc> ok
[12:21] <smb> apw, The same mail was cross posted to the kernel-team mailing list. :P Ok, I have not replied (neither did anyone else). But I probably would not have remembered that userspace might be compiled differently too. Though it may be a processor feature which is not relevant for userspace.
[12:34] <mnemoc> apw: what does the '-di' mean in https://launchpad.net/ubuntu/+archive/primary/+files/kernel-image-2.6.39-3-generic-di_2.6.39-3.9_amd64.udeb
[12:34] <mnemoc> ?
[12:35] <mnemoc> .oO(this should be on a ppa :'( )o
[12:37] <apw> mnemoc, thats the wrong one, thats the unstaller, ignore the .udeb forms
[12:38] <mnemoc> ok
[12:38] <apw> mnemoc, no cause then everyone would install it and get themselves into an unsupported combination
[12:38] <apw> mnemoc, it needs to be sufficiently hard to reduce that
[12:40] <mnemoc> so only linux-headers-2.6.39-3-generic_2.6.39-3.9_amd64.deb and linux-image-2.6.39-3-generic_2.6.39-3.9_amd64.deb ? or linux-libc-dev and linux-tools also?
[12:40] <apw> you want the first two and the _all headers package as well
[12:53] <smb> soren, apw, Ok, I replied (likely not making new friends there)
[12:57] <mnemoc> apw: http://dpaste.com/546354/ might be useful for future
[13:46] <soren> smb: I don't see your reply (neither in my inbox, in the ml archive nor in the moderation queue).
[13:47] <smb> soren, I did reply to the mail (which looked identical) that was posted to the kernel-team ml (sorry, forgot to add a crosspost)
[13:48]  * smb forwards it to server
[13:48] <soren> smb: Oh, I didn't spot the original mail on the kernel ml, so didn't even realise he had crossposted. Weird.
[13:49] <soren> Ah, there it is.
[13:49] <smb> soren, Not crossposted in that sense. Just sent it twice I guess
[13:49] <smb> soren, Shall I still push the reply to ubuntu-server?
[13:50] <soren> smb: That would probably be a good idea, yeah. He's probably not alone with this question.
[13:50] <soren> smb: Thanks!
[13:50] <smb> soren, Ok, will do... and maybe I should subscribe to server... *sigh* more mail
[13:51] <soren> smb: meh.
[13:51] <soren> smb: I can just bug you if there's kernel stuff on there.
[13:52] <soren> It's rather low traffic, though.
[13:52] <smb> soren, Yeah, I should not complain. There is always the del-button
[13:53] <soren> Oh, I can totally relate to e-mail overload.
[13:53] <soren> Accepted through the moderation queue and added you as a nomail subscriber. This means you can post without getting caught in the queue.
[13:56] <smb> soren, Bah, thats the reason I got that strange mail when I actually subscribed. :-P I was starting to question my sanity... Oh well.
[13:57] <soren> smb: Heh, sorry :)
[13:58] <smb> soren, Maybe you could change it to a withmail subscription. I still can filter it into a folder that I can ignore...
[13:59] <smb> Sorry for the mind-changes. It is getting warm and I like to complain...
[14:00] <soren> smb: Sounds only fair enough since I caused the confusion. Hang on.
[14:00] <soren> smb: Done. Thanks for following up!
[14:01] <smb> soren, Thanks as well. Hope it is helpful to some degree. Not good news probably...
[14:19] <hallyn_afk> jjohansen: good morning.  did you get any time to look into that capable() null deref?
[14:20] <hallyn_afk> jjohansen: my complete guess is that the recent rcu_free() changes exposed something,
[14:21] <hallyn_afk> jjohansen: but i'll have to do some bisecting, unless you've started that?
=== hallyn_afk is now known as hallyn
[14:28] <ogasawara> cking: was going to pull in your suspend debugging patch to oneiric but didn't know if you were planning on sending a v2 of it taking into smb's and jj's comments about hardcoding some numbers?  I'm indifferent either way so am happy to apply it as is or wait, just let me know.
[14:30] <cking> let me reply on the list, but the hardcoded numbers are in the original code (it's kinda lame), so I just extended it, hence it's just as equally bad
[14:31] <ogasawara> cking: ack
[14:31] <cking> put it this way, I'm not planning on sending a v2 of the patch
[14:31]  * ogasawara goes ahead and applies it then
[14:32] <jjohansen> hallyn: no, I didn't end up getting that far before bed
[14:32] <hallyn> ok
[14:33] <hallyn> i guess i'll try bisecting
[14:40] <schizoschaf> hi. i have issues with my newly installed 64bit natty system freezing after short usage. might this be a kernel issue? is there anything known for 2.6.38?
[14:41] <cking> thanks ogasawara
[15:10] <tgardner> apw, so the Natty MIR into Lucid went OK? I see you've marked it done.
[15:11] <apw> tgardner, yes talked it through with master watson and he decided there was no need for do any hoop jumping, and we should just upload it, so i've uploaded it to ckt PPA and stable has ownership of it now
[15:11] <apw> it'll go through the normal testing into -proposed etc
[15:11] <tgardner> apw, I saw build failures. those are resolved ?
[15:13] <apw> tgardner, those are normal, as in we only build for amd64/i386
[15:13] <apw> we likely should be cleaning more of the control file to prevent builds going there
[15:13] <tgardner> right
[15:14] <apw> i'll add that to my list to check into
[15:23] <tgardner> ogasawara, can you read bug #787740 ? I get the 'Lost something?' page.
[15:24] <ogasawara> tgardner: same here
[15:24] <tgardner> ogasawara, ok, then I'm not insane.
[15:24] <ogasawara> tgardner: well, that's debatable :)
[15:25] <tgardner> hmm, well the amount of email that I've received in 3 days off _is_ driving me insane.
[15:41]  * vanhoof emails tgardner 
[15:41]  * ogasawara back in 20
[15:42] <vanhoof> ogasawara: sorry I can't read well ;)
[15:42] <ogasawara> vanhoof: heh, no worries
[15:44] <hallyn> jjohansen: think the bug's been found.  thanks again for the pointer
[15:45] <apw> sconklin, bjf, wondering if this is any use: http://people.canonical.com/~apw/cve/pkg/combo.html
[15:46] <sconklin> It might interest kees ^^
[15:48] <jjohansen> hallyn: good to hear, sorry I didn't get to it last night but I didn't manage to get my three year old to sleep until after midnight
[15:48] <hallyn> jjohansen: i should've looked at the top of his exploiter program from the start, it was obvious once i did
[15:49] <hallyn> jjohansen: and please don't apologize for not getting to it at 9pm :)
[15:49] <jjohansen> hallyn: oh, /me goes to take a look
[15:49] <hallyn> i was just freaking out since i'm about to disappear for awhile, so taht would look bad if i didn't figure it out first :)
[15:50] <jjohansen> hallyn: /me just looked at the top of his exploiter, wtf :)
[15:51]  * jjohansen should have caught that earlier
[15:51] <hallyn> :)
[15:52] <smb> sconklin, Darn, I just realized that we got the same patch that broke ec2 on maverick in the current lucid proposed as well. I just won't break ec2 because thats different xen code. But we are delayed there anyway you said. So I may have time to create a test install to be sure.
[15:54] <hallyn> smb: (just when you get a chance)  does bug  785668 ring any bells for you?
[15:54] <ubot2> Launchpad bug 785668 in linux "bonding inside a bridge does not update ARP correctly when bridged net accessed from within a VM" [Medium,Confirmed] https://launchpad.net/bugs/785668
[15:54] <sconklin> smb: delayed for -proposed? Check with QA, and should I send a message to everyone to NOT publish it for ec2?
[15:54] <sconklin> and what about Maverick, is it still in -proposed and not published? Do we need to hold publishing?
[15:55] <sconklin> (looking)
[15:55] <smb> hallyn, Not really
[15:55] <hallyn> smb: ok, thanks
[15:55] <smb> sconklin, maverick proposed would need one patch reverted
[15:55] <hallyn> smb: for all i know it's by design
[15:56] <hallyn> (after all, if you're doing round robin over each ethX, maybe you want separate macs?  nah, that doesn't make sense)
[15:56] <sconklin> smb: ec2 only, correct (I'm remembering now)
[15:56] <smb> hallyn, I have not read into the bug, but from what I remember about the bonding it will spoof the mac of one of the real nics
[15:57] <sconklin> well, ec2 branch only for Lucid, Maverick is all in one
[15:57] <smb> sconklin, for maverick yes and only affecting that but as we use the virtual flavor there needs the kernel to be respun (master)
[15:58] <bjf> sconklin, there is nothing in the natty tracker from either cert. or QA
[15:58] <bjf> sconklin, same with maverick
[15:58] <hallyn> smb: right, it only starts to fail when you put the bond0 into a bridge with another device
[15:58] <smb> sconklin, For lucid it would be slightly different as for ec2 we use a different kernel and code. But people tend to run the generic kernels under xen too. I have not verified this yet (need to create an installation first)
[15:59] <bjf> sconklin, for lucid we have cert testing done but nothing from qa
[16:00] <sconklin> bjf: right, but I want to avoid having QA test it and perhaps miss this problem, and then having it published
[16:00] <smb> bjf, I doubt a bit that we cover that exact scenario. Usually we say xen and mean ec2...
[16:01] <smb> hallyn, I would need to draw myself some picture and actually spend a bit of time reading the bug. Just meant it does not ring a bell cause I it did not ring. :)
[16:01] <hallyn> smb: yup, that's all i was asking for right now, thanks :)
[16:02] <hallyn> smb: well, i shoudl ask - do you prefer tha ti go to the bonding m-l, or that i wait for someone on your team to look at it?
[16:03] <smb> hallyn, team? do I have one? ;-P I guess only tgardner may have played with bonding (network!) before...
[16:04] <hallyn> tgardner: are you a NIC bonding pro?
[16:04] <smb> I guess he got enough stale email to trouble him
[16:04] <sconklin> smb: I'm not sure I understand this completely. Is this correct? - We have a patch that was intended to fix a bug but it introduced new problems. We must revert that patch but we have no fix for the original bug yet.
[16:05] <smb> sconklin, Nope... /me takes breath
[16:05] <smb> That patch came through upstream stable. At least for later kernels (natty) it seems ok and I think there was a problem it fixes.
[16:06] <bjf> smb, when did you discover this issue and why wasn't the tracking bugs updated to reflect an issue?
[16:06] <smb> But it applied to earlier kernels too. And at least for .35 there seems to be badness. I just saw it could be in .32 as well. But I have not tested whether it really causes issues there
[16:07] <smb> bjf, hggdh brought it up Mon and I have been posting to the sru list. I probably should have also added to the tracking bug but forgot
[16:08] <bjf> smb, well, hggdh should have put something in the tracking bug, he found the issue
[16:08] <bjf> smb, not that i'm trying to point a finger, but these issues need to get raised right away
[16:09]  * sconklin is sending email now
[16:09] <tgardner> smb, hallyn: no bonding experience here. Steve Hemminger is the upstream expert IIRC
[16:10] <smb> tgardner, thanks
[16:11] <smb> sconklin, bjf Generally the question would also be whether we want to add the combination server installation (at least) running under xen as opposed to run the ec2 kernel on ec2 to the verification matrix
[16:12] <sconklin> smb: everything we support should be in the verification matrix. That's my position.
[16:12] <smb> sconklin, Yeah, not sure we support it really...
[16:12] <bjf> smb, i agree with sconklin
[16:12] <smb> Its just what people do
[16:15] <smb> sconklin, bjf But let me do the lucid server install for xen and test first. Maybe its nothing and all the panic was without reason. Just wanted to warn you about it
[16:15] <apw> move to /public_html/cve/pkg/
[16:15] <sconklin> smb: so status is that we know Maverick is bad, but we're not sure about Lucid?
[16:15] <apw> moved to http://people.canonical.com/~apw/cve/pkg/ALL-linux.html
[16:15] <smb> sconklin, right
[16:16] <hggdh> bjf: when I contacted the channel Monday I asked about posting it, and was suggested to wait
[16:17] <bjf> hggdh, thanks, really wasn't trying to find someone to blame, we just need early notification so folks get a heads-up that something might be broken
[16:18] <bjf> hggdh, i'm thinking that if issues are seen, they should go into the tracking bugs right away
[16:18] <hggdh> bjf: I agree. I would rather add a link to a bug in the results matrix (as opposed to "fail to boot")
[16:18] <bjf> hggdh, we can always add a follow on comment that "it was nothing"
[16:18] <hggdh> yes
[16:19] <hggdh> bjf: from now on it will be there, with a link in the results matrix
[16:20] <sconklin> smb: do we know completely what it required for Maverick? Is it simply to revert the patch or is there another fix that will be required? I'm trying to understand how long this will take.
[16:20] <apw> sconklin, bjf, you have built lts-backports-foo in ckt PPA bebfore, did it error on none x86 for you on those do you remember?
[16:20] <bjf> apw, not that i recall
[16:21] <sconklin> apw: I do not know
[16:21] <smb> sconklin, bjf hggdh I think I misunderstood the posting part back then.
[16:21] <sconklin> dont recall any failure
[16:21] <apw> ok, then its new in the natty one, leave those failures with me and i'll try and get rid of em
[16:21] <hggdh> smb: not really -- *I* should have posted it, after all I was the one running the test
[16:22] <smb> sconklin, Reverting the patch enables boot again. I am currently discussing with the author about it. So to fix it there is maybe a different approach
[16:22] <bjf> smb, was suggesting that as soon as any issue is found with a kernel, a comment should be added to the tracking bug
[16:22] <apw> is not the appropriate thing to do just to revert the broken commit and release ?
[16:22] <hggdh> bjf: in cases like this, would it be better if a new bug is entered?
[16:22] <bjf> smb, if necessary, a follow up can always be added that says something like "was just a test issue" or some such
[16:23] <smb> bjf, Totally agree. I meant when being asked (or when I saw it) I did not connect posting something to add a comment to the tracking bug 
[16:23] <bjf> hggdh, probably, however, since the tracking bug is used for a particular kernel release, that needs to be updated as well
[16:23] <hggdh> bjf: what I propose: (1) new bug; (2) comment in the tracking bug, linking to the new bug; (3) link in the results matrix
[16:23] <bjf> hggdh, that matches my thinking as well
[16:24] <hggdh> bjf: perfect
[16:31] <tgardner> apw, I think the Maverick LTS build doesn't fail because I stripped out all non x86 arch support.
[16:33] <apw> tgardner, odd as i made the support from that support, but i must have missed something ...
[16:34] <apw> easy enough to compare though so ... i'll do that
[16:34] <tgardner> apw, I was just looking at the abi directory. only i386 and amd64 are present
[16:36] <hggdh> bjf: this new bug, should we pre-assign it to the kernel team? Also have it as born high-importance?
[16:37] <bjf> hggdh, sure, let smb know and he'll probably assign it to himself
[16:38] <apw> tgardner, from what i can see on the branch it seems to be correct, i think i borked making the source package
[16:38] <smb> hggdh, Or assign it directly to me 
[16:39] <JFo> smb, I am almost done with your server bugs report
[16:39] <JFo> just FYI
[16:39] <JFo> testing/tweaking now
[16:39] <smb> JFo, Sounds awesome. Though I am a bit scared to find out how much I did not see...
[16:39] <JFo> heh
[16:41] <apw> bjf, if i wanted to re-upload this lts-backport-natty, i'd want to add the tracking bug, whats the proceedure for that
[16:41] <hggdh> smb: ok, you are the lucky winner ;-)
[16:41]  * smb feels so ... special
[16:42] <bjf> apw, from within the git clone, "create-release-tracker"
[16:42] <bjf> apw, this will create the tracking bug and add a line to the changelog
[16:42] <smb> Anyway I will have a sort of early eod today. There is some liquid waiting for me...
[16:43] <JFo> mmmm
[16:44] <smb> sconklin, Just to be sure and out of interest, you got mails I sent to the sru list about maverick bisected?
[16:45] <bjf> smb, i got the emails as well, i just didn't recognize them for what they were, my bad
[16:45] <sconklin> smb: yes, but the implications were not clear to me, and the tracking bugs were not changed. The tracking bugs are the definitive record of problems, so I did not realize the magnitude of the problem
[16:45] <smb> bjf, Ah ok. No I was just wondering whether I sent them to myself or somethign
[16:46] <bjf> sconklin, we need to make sure that the new workflow handles this case really well (bells, lights, sirens, etc.)
[16:48] <JFo> smb, I am only seeing 4 bugs
[16:48] <JFo> are there any other tags you'd like included?
[16:53] <smb> JFo, Four sounds good... though a bit unlikely. There should be more actually with those two tags... For some the main task may be fixed though
[16:53] <smb> or invalid
[16:53] <JFo> could be
[16:53] <JFo> I'll verify
[16:55] <smb> JFo, Well if you mail me some list/link I could check and report at least the ones I find missing 
[16:55] <JFo> ok, will do. I hadn't added the ec2 one yet. doing that now
[16:56] <JFo> I see 18 tagged ec2-images
[16:57] <sconklin> bjf: we're going to need the equivalent of a big red button on the workflow process
[16:57] <smb> That sounds possible. Maybe I just did not add the other tag often enough yet.
[16:58] <smb> JFo, Anyway, I hate to leave like that... but there is reason. :)
[16:58] <JFo> no problem
[17:20] <apw> bjf, AttributeError: class Kernel has no attribute 'series'
[17:20] <apw> from create-release-tracker
[17:20] <bjf> apw, huh
[17:21] <bjf> apw, thanks for trying, i'll run that down
[17:21] <bjf> apw, don't worry about it for now
[17:22] <apw> bjf, i am told that its likely that its an inconsistancy archive wise, that triggered the erorrs on the natty backport and we should worry about it, for now i suggest we only worry about it after its been uploaded once to the archiive
[17:22] <bjf> apw, i'm thinking i've not checked in a change, i have something in my local repo that i've not pushed
[17:22] <apw> and we should not worry about it
[17:22] <bjf> apw, it's in my code
[17:24] <jonpry> i have serious acpi troubles on lenovo y560p. i am a semi experienced kernel hacker on arm platforms, but no idea about how acpi works
[17:25] <mjg59> With magic
[17:25] <jonpry> yeah i get that impression
[17:26] <mjg59> Got a bug number?
[17:26] <jonpry> https://bugzilla.redhat.com/show_bug.cgi?id=699156
[17:26] <ubot2> bugzilla.redhat.com bug 699156 in kernel "Large amount of acpi interrupts on lenovo y560p with 2.6.38+" [Unspecified,New]
[17:27] <mjg59> Huh it's even assigned to me and everything
[17:28] <jonpry> yeah i have been stalking you
[17:28] <mjg59> Could you attach lspci -vvvxxx (run as root) to the bug?
[17:28] <jonpry> sure thing
[17:30] <jonpry> i put up the lspci
[17:35] <jonpry> i tried the simple stuff like turning off the gpe's but it doesn't seem to stick. pcie compat is no help. acpi off does the trick but kills smp
[17:36] <jonpry> whats really cool is that there is GPE storm in dmesg. but all gpe are still running in interrupt mode. that seemed like the most obvious attack point to me
[17:40] <mjg59> jonpry: Looks like I'll need acpidump output as well
[17:41] <jonpry> any options?
[17:41] <mjg59> Nope
[17:43] <jonpry> mjg59: posted
[17:44] <mjg59> Thanks
[17:47] <jonpry> no thank you
=== hallyn is now known as hallyn_afk
[18:37] <JFo> <-lunch back soon
[19:02]  * tgardner --> lunch
[19:20] <sforshee> BenC, for the machines you were working with affected by bug #424142, were there any symptoms beyond the "address space collision" messages?
[19:20] <ubot2> Launchpad bug 424142 in linux "Address Collision" [Medium,Fix committed] https://launchpad.net/bugs/424142
[19:20] <BenC> sforshee: yes, the collision kept the affected device from working (since ioremap would fail)
[19:21] <BenC> other than that, no
[19:26] <sforshee> BenC, thanks
[20:18]  * JFo stepping away to run an errand
=== yofel_ is now known as yofel
[20:40] <bjf> apw, i believe i have fixed the problem you were seeing with create-release-tracker (just fyi)
[20:46] <sconklin> apw: but create-release-tracker has also been changed to the new version, which likely requires you to be a member of the canonical-kernel-sru-team, I have added you
[21:01] <jjohansen> gah, /me is suffering from wonderful graphical corruption again, making the display unreadable.  Time for a reboot, fsck, and lunch
=== hallyn_afk is now known as hallyn
[23:10] <moodaepo> Folks are there plans to ship 2.6.39 with transparent_hugepage enabled? I was quite disappointed it couldn't get shipped as enabled in 2.6.38 but am hoping the i386 crash is fixed in the next release. Cheers
[23:19] <broder> wait, transparent hugepages was finally merged? awesome
[23:58] <jjohansen> broder: yeah