[07:31] <jibel> smb, I'm still affected by bug 1021471 with kernel 3.5.0-17.28 and lxc
[07:31] <ubot2> Launchpad bug 1021471 in linux "clone() hang when creating new network namespace (dmesg show unregister_netdevice: waiting for lo to become free. Usage count = 2)" [High,Confirmed] https://launchpad.net/bugs/1021471
[07:31] <smb> jibel, And you are not using wl?
[07:32] <jibel> smb, just by creating a new container and shutting it down with poweroff from inside the container
[07:32] <jibel> smb, no, r8169
[07:33] <smb> jibel, and the count is 2? I did try to do the same you did in my tests and those worked
[07:33] <jibel> smb, count is 1
[07:34] <smb> jibel, Then I think it sounds like a similar thing that Clint still sees
[07:35] <jibel> smb, thne this is the log I get when I try to start a container http://paste.ubuntu.com/1272737/
[07:36] <jibel> smb, do you want another report ?
[07:36] <smb> jibel, I would suggest you and him get in touch. Not sure he already filed the new bug report or not. And you could get the debugging kernel from my people page.
[07:37] <smb> Well the hung task is because of the net namespace not being cleaned in some way. That seems to be the same
[07:38] <smb> jibel, At least it seems to be related with certain drivers or net hw. As Clint said he would have no problems when not using wl (not sure what he was using instead from my head)
[07:38] <jibel> smb, I talked to him yesterday evening and he had not fully tested the latest kernel and didn't filed a new bug report. 
[07:38] <jibel> smb, he's using b43
[07:38] <smb> jibel, So then feel free to go ahead and create one and let him know.
[07:38] <jibel> smb, ack, thanks. 
[07:39] <smb> jibel, debug kernel would be the smb2 at people:~smb/clonetst
[07:39] <smb> It is not the latest but close enough
[07:40] <jibel> ok, I'll give it a try
[07:41] <smb> jibel, I expect it to break in the same way but be more verbose on it. So a syslog from that boot is telling a bit more
[07:42] <smb> jibel, One thing would be of interest. Are you using ipv6 in some way (beyond the stuff that basically always is there)
[07:44] <smb> cd
[07:45] <jibel> smb, I don't use IPv6
[07:45] <smb> jibel, ok, thanks
[07:56] <apw> smb, do we still carry that poweroff change for containers, or is that gone now
[07:56] <smb> apw, I would hope that it is upstream by now... but nothing knowing for sure
[07:57] <apw> and do i surmise that if you take networking down locally it goes away?
[07:57] <smb> and if me remembers correctly that was just changing the signal to its init process in some way
[07:57] <apw> yeah i think it was
[07:58] <smb> So teardown of network would be outside the container
[07:58]  * smb scratches head
[07:58] <smb> well at least the other namespace
[08:00] <smb> But maybe I understand what you try getting at. If the interface would not be shut down correctly inside and still have some refs. The only thing is it seemed to work ok on my own tests
[08:02] <apw> jibel, is this is a lab system we can get access to?h
[08:02] <apw> as it is reproing the issue and we cannot
[08:03] <apw> jibel, or indeed is it a vm
[08:04] <jibel> apw, it's on my machine at home, I don't do it in the lab otherwise, I cannot shutdown the server remotely
[08:05] <apw> hmmm.  can you file a bug with the reproduction steps if there isn't one, as this needs debugging 
[08:05] <smb> jibel, When you report the bug, can you please be verbose on the steps you take to set up lxc, so I will be doing exactly the same
[08:06] <smb> err what apw said
[08:06] <smb> apw, stop saying what I am thinking
[08:06] <apw> time for more coffee
[08:06] <apw> :)
[08:06] <jibel> apw, sure, I trying on another freshly installed machine to find a reproducible test case.
[08:06] <smb> :)
[08:15] <jibel> ok, bug reproduced on another machine, the steps are not exactly clear as I had to start/shutdown the container twice, and it seems to require network activity from inside the container before shutdown. I'll try again to narrow it down.
[08:16] <smb> Could be the one difference to what I did
[09:06] <jibel> smb, So ... I have a minimal test case with your kernel, I can file a bug :)
[09:06] <smb> jibel, Then you shall do so. ;)
[09:11] <cjwatson> Anyone know if we ever got anywhere about escalating bug 1040557 to Samsung BIOS folks?
[09:11] <ubot2> Launchpad bug 1040557 in ubuntu-cdimage "UEFI boot live-usb bricks SAMSUNG 530U3C,np700z5c laptop" [Critical,Confirmed] https://launchpad.net/bugs/1040557
[09:13]  * smb does not
[09:17] <apw> cjwatson, not heard anything myself
[09:17] <cjwatson> Did we even escalate it?
[09:18] <apw> cjwatson, i don't think i know that even
[09:18] <apw> ogasawara, do you know if the above samsung issue was escalated?
[09:20] <cjwatson> I sent mail about it to canonical-uefi and got not much
[09:23] <apw> cjwatson, no indeed.  and i am sure this will be getting more common too
[09:24] <apw> cking was saying he did two in in a day, just by setting efi variables repeatedly
[09:24] <apw> and a different vendor too
[09:25] <apw> smb, there is an interesting networking fix posted sans-explanation to u-k-t
[09:25] <smb> apw, Saw it, ignored it for a bit...
[09:27] <smb> apw, Hm, the bug report explains it better
[09:29] <apw> yeah i don't think there is any doubt that the fix is sane
[09:29] <cjwatson> apw: Sure, I just don't want people to be able to say that laptops are getting bricked because we ignored the reports
[09:31] <apw> cjwatson, i wonder if we can blacklist them
[09:34] <smb> apw, Yeah, so far it did not seem to be in things Dave Miller has sent to stable. And there is usually little to predict what he will send. Plus the meaning of this is upstream is relative...
[09:34] <jibel> smb, bug 1065434
[09:34] <ubot2> Launchpad bug 1065434 in linux ""unregister_netdevice: waiting for lo to become free. Usage count = 1" after LXC container shutdown" [Undecided,Confirmed] https://launchpad.net/bugs/1065434
[09:35] <smb> jibel, Ok, thanks. I will assign it to me
[09:38] <smb> jibel, So simple, just transferring ~300MB before interrupting it... Now do I really want to look at *that* syslog...?
[09:39] <jibel> smb, ok, maybe less, want me to try with ping instead ?
[09:41] <smb> jibel, If it is possible to see with causing less network traffic it would help to make out some trees in the wall of forest that the additional debugging produces.
[09:42] <jibel> smb, ack, I'll chop some trees
[09:43] <smb> jibel, Muchly appreciated, thanks
[09:49] <jibel> smb, 50MB is enough :)
[09:49] <jibel> smb, back in ~20min, I'll attach a smaller syslog with the debug kernel
[09:49] <smb> jibel, Argh, that would be even more than last time
[09:50] <smb> Oh you mean 50M transfer... 
[09:50] <jibel> yeah, I transfered 50MB then stopped
[09:50] <jibel> I didn't reproduce with 10 and 20MB
[09:51] <smb> *sigh* Ok, but *sigh*
[09:51] <jibel> but I don't know if duration is involved or amount of data
[09:53] <smb> I guess it has to be some form of net usage. Sure, could be the time a connection is up or how often things are transferred. We will maybe see...
[10:26] <jibel> smb, it's the amount of data
[10:27] <jibel> I did the following tests: 1) download 1MB at 5kbps and 2) 50MB at 100Mbps
[10:27] <jibel> the second test failed not the first
[10:28] <apw> those wo don't take the saem time do they ?
[10:29] <jibel> no they don't, the second was much faster
[10:29] <apw> ok
[11:29]  * henrix -> lunch
[11:35] <MCR1> Why is Kernel 3.5.6-quantal only available for i386 ?
[12:44] <ogasawara> cjwatson, apw: re: 1040557 and escalating to Samsung BIOS folks...I know cking asked vanhoof to put a request out to some of his guys for contacts.  I unfortunately don't know what the outcome was there.
[12:44] <apw> ogasawara, ok we should follow up with the hoof then today and check
[13:03] <ogasawara> rtg: care to take a quick peek at git://kernel.ubuntu.com/ubuntu/ubuntu-quantal-lbm.git
[13:03] <ogasawara> rtg: I realized last night we never threw lbm together for quantal
[13:05] <rtg> ogasawara, ack, looking
[13:06] <rtg> ogasawara, I'm wondering if we need an LBM for Quantal. We've kind of fallen off doing the backport packages since we've started doing whole kernels.
[13:07] <ogasawara> rtg: it's a good question.  I haven't heard anyone screaming for a 3.6 compat-wireless stack, which is all that's really provided in the quantal lbm that I rolled.
[13:08] <ogasawara> rtg: I was curious what hurdles we'd face trying to upload post release in the event we ever did want lbm for quantal.
[13:08] <rtg> ogasawara, I'd be inclined to just add cw-3.6 to precise and call it good.
[13:10] <rtg> ogasawara, I don't think we did cw for maverick/natty/oneiric did we ? mostly just lucid.
[13:10] <rtg> or if we did, perhaps we should change that trend.
[13:11] <ogasawara> rtg: I think we did have lbm for those older releases, /me double checks
[13:12] <rtg> ogasawara, even if we did (which I suspect you're right about), I think its time to change. 
[13:12] <ogasawara> rtg: works for me
[13:12] <rtg> at least for the short term releases
[13:13] <ogasawara> rtg: I'm just gonna remove that ubuntu-quantal-lbm repo on zinc then, just to avoid any confusion
[13:13] <rtg> ogasawara, I was just gonna say that :)
[13:14] <rtg> ogasawara, you could just about cherry-pick your work in the Precise LBM
[13:14] <rtg> into*
[13:15] <ogasawara> rtg: yep, will do
[13:18] <cjwatson> These days I suspect doing it post-release wouldn't be a particular headache if you did need to
[13:23] <ogasawara> cjwatson: thanks, good to know
[14:56]  * ogasawara back in 20
[15:17] <ppisati> brb
[15:38] <rtg> apw, I'm looking at jk's last comment re: "PATCH 5/5] efivarfs: efivarfs_fill_super() ensure we clean up correctly on error". Would it be sufficient to call efivarfs_kill_sb() just before 'fail:' ?
[15:50] <alexbligh> What would be the recommended way to install the current quantal kernel on precice? (wget the .deb and install produced an unbootable system - not looked into why yet)
[15:52] <rtg> alexbligh, thats not a packaging problem. doing just what you did does work.
[16:00] <apw> rtg, i don't thnk it is necessary because we are already ripping down the sb on the way out, will reply
[16:07] <rtg> apw, I think efivarfs_kill_sb() gets called indirectly anyways if mount_single() gets an error return from fill_super(), so I think its OK, i.e., no resources are orphaned.
[16:07] <apw> rtg, yeah essentially efivars_kill_sb() should be called as part of the tear down ...
[16:07] <apw> yeah we concur
[16:08] <rtg> apw, so, I've got these applied to Quantal branch. shall I post 'em or are you already ahead of me ?
[16:09] <apw> rtg there was a small bit of porting work in the original patches
[16:09] <apw> to do with nameidata going away after quantal
[16:10] <rtg> I've haven't built yet, but they were all clean cherry-picks
[16:10] <apw> right and actuall its not clean when you compile the is a warning
[16:12] <apw> rtg, i'll push these as i have test this combination
[16:12] <rtg> apw, OK
[16:17] <apw> rtg ok pushed
[16:19] <rtg> apw, I'll let ogasawara know that I reviewed them in case she's feeling cranky about stuff appearing in her tree post Beta2 :)
[16:19] <ogasawara> :)
[16:22] <apw> rtg, heh perhaps i should get you to put acks on them :)
[16:22] <rtg> apw, will do.
[16:29] <apw> ogasawara, i think we are expecting to put that in the first sru currently
[16:29] <ogasawara> apw: ack
[16:30] <rtg> apw, repushed. I've done my officious rubber stamping for the day.
[17:01] <apw> rtg, did you add jk's extra patch?
[17:02] <rtg> apw, which one was that ?
[17:02] <rtg> I mostly looked at your cleanup patches
[17:02] <apw> efivarfs: Implement exclusive access for {get,set}_variab...
[17:03] <rtg> apw, that wasn't one of the patches in your push
[17:04] <apw> no i just noticed it on our kernel-team@ list
[17:04] <apw> will review and test
[17:04] <rtg> apw, I must have deleted it already
[17:06] <rtg> apw, are you sure it was on the kteam list ? I don't see anything from jk for Sept or Oct
[17:11] <apw> oh no its not, i missread, i have it cause i am on CC:
[17:11] <rtg> apw, LKML then ?
[17:12] <apw> yeah, thats what confused me, it looked enought like kernel-team to confuse me
[17:12] <alexbligh> rtg, belated thanks
[17:19] <apw> rtg, i'll pull it and test it
[17:22] <rtg> apw, I noticed a pull request for the signed modules patch set
[17:25] <apw> rtg cool
[17:34]  * rtg -> lunch
[17:40] <slangasek> mjg59: hi, any chance you've gotten a look at that shim patch of mine?
[17:44] <mjg59> slangasek: Sorry, not yet
[17:44] <mjg59> Give me 20 minutes or so?
[17:44] <slangasek> mjg59: that works fine, thanks
[18:00] <apw> rtg, well i can still read variables with that locking patch applied
[18:04]  * henrix -> EOD
[18:41] <penalvch> Hello everyone. I am trying to bisect bug 980279 and have gotten stuck. My progress is documented at http://pastebin.com/Heqd1JVN . What would be the next step?
[18:41] <ubot2> Launchpad bug 980279 in linux "BUG: soft lockup - CPU#5 stuck for 22s! [xfce4-sensors-p:1873]; EIP is at generic_exec_single+0x66/0x80" [Medium,Triaged] https://launchpad.net/bugs/980279
[18:50] <rtg> penalvch, instead of bisecting between non-linear tags, you might be better off trying to figure out which stable update caused your regression.
[18:51] <rtg> the various stable releases are pre-built at http://kernel.ubuntu.com/~kernel-ppa/mainline/
[18:56] <penalvch> rtg thank you for responding. This is my first bisect. So your suggestions, while seemingly helpful, have gotten me lost already. :( What I have found was that the last good kernel was 3.2.0-14-generic, and the first bad kernel was 3.2.0-15-generic.
[18:58] <penalvch> rtg, are you suggesting to map the the regressions to the mainline kernel releases via http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html and git bisect the mainline kernel?
[19:00] <rtg> penalvch, no, I'm suggesting that you first narrow down which stable update (if any) caused your problem. if you examine the changelog you'll notice that the kernel was rebased 3 times against stable releases 3.2.3 through 3.2.5
[19:06] <penalvch> rtg, when I run git log --oneline Ubuntu-3.2.0-14.23..Ubuntu-3.2.0-15.24 I see rebase once between the two: 4d41bd7 UBUNTU: [Config] Rebase to v3.2.5 . What are the other two rebases?
[19:07] <rtg> penalvch, I was looking in debian.master/changelog which indicates the rebases that occurred between 3.2.0-14.23 and 3.2.0-15.24
[19:08] <rtg> looks like I got one too mant
[19:08] <rtg> many*
[19:09] <penalvch> rtg, ok glad you found that changelog. This was my original problem. I could not find the debian.master/changelog in the ubuntu-precise folder generated by executing git clone git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git . I looked for it via find and locate, no luck. What is the location of this changelog?
[19:09] <rtg> oh, maybe not. looks like we skipped one of the stable update cycles and went from v3.2.3 to v3.2.5
[19:10] <rtg> penalvch, you can't find it? debian.master/changelog is the exact path.
[19:11] <penalvch> rtg, unfortunately I do not find this path.
[19:12] <rtg> penalvch, I don't what to tell you. If you've correctly cloned this repository, then it can't _not_ be there.
[19:16] <penalvch> rtg, ok. Looks like I have a corrupt?! git repo clone as per http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=tree;h=44aedcec26f76c9a8d4ef7db73cf83047ad988b9;hb=907e57fa9bdc74415eaa69d8b1229ca20d3876b2 . I'll try recloning it. Thanks for your help!
[19:21] <mjg59> slangasek: I'd kind of prefer the shifted down code to be in the if statement rather than adding another goto
[19:21] <mjg59> slangasek: But other than that, looks fine
[19:27] <slangasek> mjg59: ok, thanks for the review
[19:28] <slangasek> mjg59: would you like me to clean that up and resubmit, or do you want to amend it on your side?
[19:29] <mjg59> slangasek: I'm hacking other bits at the moment, so I'll do it
[19:29] <mjg59> But feel free to ship that version
[19:29] <slangasek> yeppers
[19:47]  * ogasawara lunch
[19:51] <hallyn> smb: do you have any thoughts on bug 1065589 ?  (whether the kernel should send a uevent when a netdev is moved to a new netns)
[19:51] <ubot2> Launchpad bug 1065589 in lxc ""initctl list" shows 11974 instances of network-interface-security after two days of uptime" [Medium,Triaged] https://launchpad.net/bugs/1065589
[19:52] <hallyn> probably i need to go ask Eric Biederman what he thinks
[20:10] <develtech> hi
[20:10] <develtech> i have question regarding Crypto API in linux kernel
[20:22] <penalvch> rtg, quick follow up. What I found is that my git repo was not corrupted. Instead, when I execute the following, debian and debian.master are wiped out: git bisect start Ubuntu-3.2.0-15.24 Ubuntu-3.2.0-14.23
[20:23] <penalvch> rtg, I would cd ubuntu-precise immediately prior to git bisect start...
[20:25] <rtg> penalvch, thats because there is no linearity between those 2 tags. the first bisect commit is _before_ Ubuntu-3.2.0-14.23 was introduced. In fact, its before any Debian packaging was applied.
[20:26] <penalvch> rtg, ok. How would one workaround that issue in this case?
[20:26] <rtg> penalvch, you can restore by using 'git fetch origin;git fetch origin master;git reset --hard FETCH_HEAD'
[20:28] <penalvch> rtg, I executed verbatim: 'git fetch origin;git fetch origin master;git reset --hard FETCH_HEAD' and now the missing files are back. What would be the next step?
[20:28] <rtg> penalvch, then, like I said, figure out which stable update caused the regression by installing one of the packages found at http://kernel.ubuntu.com/~kernel-ppa/mainline/, e.g., http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2.4-precise/linux-image-3.2.4-030204-generic_3.2.4-030204.201202031635_amd64.deb
[20:29] <rtg> penalvch, I'm outta here for the day. perhaps ogasawara or bjf can give you some advice. otherwise, contact jsalisbury who can do the bisect for you.
[20:29] <komputes> Hi Ubuntu Kernel Folks! What is the recommended way to boot 12.04 on an EFI system?
[20:30] <penalvch> rtg, ok. Thanks for your help.
[20:30] <bjf> komputes, the same way you boot on a non-efi system
[20:31] <komputes> bjf: I know of an EFI system which will not boot after installation.
[20:32] <bjf> komputes, would you like to elaborate on that a little?
[20:33] <komputes> bjf: Lenovo D30
[20:33] <komputes> bjf: Tried reinstalling ubuntu with both EFI Boot and Bios-grub partition.
[20:34] <komputes> If sw RAID (fakeraid) is set 0+1 it does not boot
[20:34] <komputes> If sw RAID (fakeraid) is set 1 it boot occasionally
[20:34] <slangasek> so why do you believe this is an EFI problem, instead of a fakeraid problem?
[20:35] <komputes> If sw RAID (fakeraid) is set 10 installation is successful, but ubuntu will not boot.
[20:35] <xnox> komputes: can you please spell out what raid you have? do you mean mdadm or something like Intel Matrix Storage / dmraid?
[20:35] <komputes> slangasek: because I'm not too familiar with booting from EFIBoot or biosgrub partitions
[20:35] <xnox> (possibly other "technologies")
[20:36] <slangasek> what do you mean by "biosgrub partition"?
[20:36] <komputes> xnox: Serial Attached SCSI controller [0107]: Intel Corporation Patsburg Dual 4-Port SATA/SAS Storage Control Unit [8086:1d68] (rev 06) 
[20:36] <komputes> slangasek: that's exactly what I said
[20:36] <xnox> komputes: thanks.
[20:36] <slangasek> komputes: I can read what you said, but I have no idea what you mean
[20:37] <komputes> slangasek: I'm quite confused as well
[20:37] <slangasek> booting with GRUB under BIOS doesn't involve any special partitions
[20:37] <komputes> indeed, but this motherboard uses EFI
[20:37] <slangasek> are you booting it in EFI mode, or in BIOS compat mode?
[20:38] <komputes> EFI mode I believe
[20:38] <komputes> fstab seems to show overlayfs being use as a source for root (/)
[20:38] <slangasek> komputes: you can verify this by booting the installer and looking for the presence of /sys/firmware/efi
[20:38] <komputes> that confused me too
[20:39] <komputes> slangasek: will do
[20:39] <slangasek> if you have that directory, you're booted EFI; if not, you're booted BIOS compat.  And if you're booted EFI, you might want to try booting in BIOS compat again to cross-check that this is actually an EFI problem
[20:39] <slangasek> (booting and installing in)
[20:40] <komputes> slangasek: cool, thanks for the advice
[21:36] <xnox> did the kernel auto-removal / cleanup blueprint happened?
[21:56] <hallyn> smb`: fwiw looking at the source it looks like the net-device-{removed,added} uevents SHOULD be getting sent, I'm still digging.
[22:11] <hallyn> but upstart certainly doesnt seem to get it
[22:11] <hallyn> ok, gotta run.  hopefully will figure this out tomorrow
[22:29] <slangasek> xnox: nope, infinity sat on it the whole cycle :)