[06:58]  * smb tries to wake up
[07:11]  * RAOF can spot smb a steaming pot of bees.
[07:13] <smb> RAOF, To bee or not to bee... 
[07:13] <RAOF> Whether tis nobler in the mind to suffer the stings of outrageous fortune...
[07:14]  * smb wished he could remember any more of that just for the fun...
[07:15] <smb> So I rather replenish that coffee that has vaporized from my cup
[08:02] <apw> RAOF, i think you'll find your bees in high demand ...
[09:12] <ekarlso-> Hi
[09:12] <ekarlso-> I'm getting a panic on tcp_gso_segment on a server with 3.13 
[09:12] <ekarlso-> when MASQUERADE is used
[09:15] <ekarlso-> 3.13-24 to be exact
[09:15] <ekarlso-> also I tried the 3.14 kernel off of the mainline ppa but I only get that bnx2 firmware is missing so it fails to load 
[09:16] <ekarlso-> what to do next ?
[09:27] <apw> ekarlso-, so filing a bug against the package "linux" would be a good thing to do
[09:34] <ekarlso-> done apw 
[09:34] <ekarlso-> https://bugs.launchpad.net/ubuntu/+source/linux/+filebug/677a6d72-ceb7-11e3-a597-002481e7f48a
[09:34] <ubot2> ekarlso-: Error: Could not gather data from Launchpad for bug #677 (https://launchpad.net/bugs/677). The error has been logged
[09:35] <ekarlso-> ehm
[09:37] <ekarlso-> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313591 
[09:37] <ubot2> Launchpad bug 1313591 in linux (Ubuntu) "Panic on 3.13.0-24 with bnx2, iptables and MASQUERADE" [Undecided,New]
[09:38] <ekarlso-> apw: u got a cluje on how I can get 3.143 working ?
[09:41] <apw> ekarlso-, ok we really need to catch that panic stack you are getting
[09:41] <apw> as the bug report didn't pick it up
[09:41] <apw> so even if you have to take a photo ...
[09:42] <apw> also we'd be interested in the bnx2 firmware error as emitted on the later kernels, as that is likely to affect utopic
[09:43] <apw> henrix, hey ... you sent out fixes for CVE-2014-2523 for quantal, but i see lts-backport-raring is outstanding; is that dead now?
[09:44] <henrix> apw: let me have a look...
[09:45] <henrix> apw: hmm.. i thought the fix was in 3.8 stable, but i can't see it
[09:45] <apw> do i get to blame kamal ?
[09:45] <henrix> apw: heh, no, not yet :)
[09:45] <henrix> let me double check
[09:45] <apw> damn :)  i was looking forward to some baiting
[09:46]  * apw puts his ratter back in its cage
[09:46] <ekarlso-> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313591/+attachment/4099285/+files/trusty_panic.png < that one
[09:46] <ubot2> Launchpad bug 1313591 in linux (Ubuntu) "Panic on 3.13.0-24 with bnx2, iptables and MASQUERADE" [Undecided,New]
[09:46] <apw> ekarlso-, i _hate_ backtraced ... the first line (and pretty much only the first line) is missing
[09:47] <ekarlso-> apw: ?
[09:47] <ekarlso-> I wonder if this is a openvswitch bug though
[09:48] <henrix> apw: ok, i'll send the fix for lts-backport-raring and also ask kamal to include it in stable as well
[09:48] <henrix> apw: thanks for spotting that ;)
[09:49] <apw> henrix, you know me, i hate "not green"
[09:49] <henrix> heh don't we all? :)
[09:49] <apw> ekarlso-, the most important line of that dump is the one that scrolled off the top (of course)
[09:50] <apw> ekarlso-, and yeah this seems to be higher than the driver, even if the presence triggers the behaviour
[09:51] <apw> it could be any number of layers at fault here indeed
[09:53] <ekarlso-> god I hate this
[09:53] <ekarlso-> trying to find the trace is bleh...
[09:54] <ekarlso-> need to pause at the right millisecond..
[09:55] <apw> ekarlso-, these interfaces suck normally, i think the manufacturer does it just to make us go mad
[09:58] <ekarlso-> hmmms
[09:58] <ekarlso-> how the crap can I get the text ....
[10:10] <ekarlso-> apw: what to do next ?
[10:13] <apw> cry about how pants the interfaces are ... i've had a quick scan of the obvious and don't see anything which i can blame without the clues the top line would likely give us
[10:13] <apw> ekarlso-, i think we need you to be able to test on the later versions, so we need to figure out the firmware issue
[10:16] <ekarlso-> apw: how do we do that ? 
[10:20] <ekarlso-> ok apw 
[10:20] <ekarlso-> got it I think
[10:24] <ekarlso-> https://launchpadlibrarian.net/174035085/trusty_panic_top_edited.png
[10:25] <ekarlso->    apw does that provide better info ?
[10:33] <apw> ekarlso-, yep that is the baby
[10:36] <ekarlso-> what next then apw ?
[10:50] <apw> ekarlso-, i am poking around to see if there is any chatter on that and if there is anything obvious in the area; it would be good to test a 3.14/15 mainline in this context to see if it is fixed there else we have to look backwards to see what broke it
[10:51] <ekarlso-> apw: yeah, but then fthe firmware
[10:52] <apw> ekarlso-, which i am sure is a soluable problem
[10:52] <ekarlso-> how ? :_)
[10:54] <apw> whats the exact error it produces
[10:55] <apw> the other thing you can do if the newer ones don't work is look backwards for one which does
[10:56] <apw> ekarlso-, is there ipv6 traffic on this link
[10:56] <ekarlso-> apw: not that I know of
[10:57] <apw> ekarlso-, i assume as you are using openvswitch there are vlans
[10:57] <ekarlso-> bnx2/bnx2-mips-09-6.2.1b.fw is missing it says.
[10:57] <ekarlso-> yea, but I ain't using ovs for vlans atm
[10:59] <apw> /lib/firmware/3.13.0-24-generic/bnx2/bnx2-mips-09-6.2.1b.fw
[10:59] <apw> that seems to be packaged in the appropriate place
[10:59] <apw> linux-image-3.13.0-24-generic: /lib/firmware/3.13.0-24-generic/bnx2/bnx2-mips-09-6.2.1b.fw
[11:00] <apw> as far as i can see at least
[11:00] <apw> you could try symlinking htat into the mainline build lib directory in a similar place
[11:02] <ekarlso-> apw: sorry?
[11:03] <apw> as this is packaged with the kernel, you could add a symlink in /lib/firmware/VERSION/bnx2
[11:03] <apw> for the mainline version you are running
[11:05] <ekarlso-> I tired 
[11:06] <ekarlso-> ln -s /lib/firmware/3.14.X/bnx2 /lib/firmware
[11:07] <apw> and that didn't work ?
[11:07] <apw> if not, try ln -s /lib/firmware/3.14.X/bnx2 /lib/firmware/`uname -r`/bnx2 in the broke one
[11:07] <ekarlso-> bnx2/bnx2-mips-09-6.2.1b.fw is missing still -,,-
[11:10] <ekarlso-> So I linked that to the 3.14 bnx2 directory and it loads
[11:11] <ekarlso-> ok, booting then into 3.14 and see if that panics
[11:14] <apw> ekarlso-, i would also try v3.15-rc3 if that explodes on you, as that deffo has 2-3 suspicious sounding fixed
[11:16] <ekarlso-> deffo ?
[11:17] <apw> definatly
[11:22] <ekarlso-> 3.14 fixed it apw -,,-
[11:23] <apw> ekarlso-, ok good then there is hope
[11:23] <apw> ekarlso-, put all the info in the bu
[11:23] <apw> bug
[11:24] <ekarlso-> just that 3.14 works ? : )
[11:27] <apw> ekarlso-, it is a start
[11:34] <apw> ekarlso-, 3.14 contains at aleast two of the suspicious sounding fixes
[12:12] <ppisati> felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/ <- Bridge support in git for mercurial and bazaar
[12:12] <ppisati> e.g. git clone "bzr::lp:gnuhello"
[12:12] <ppisati> The original repository will be tracked like any git repository:
[12:12] <ppisati> ...
[12:12] <ppisati> awesome!!!
[12:21] <henrix> ppisati: is that the 'git-bzr' package?
[12:39] <ppisati> henrix: it seems so
[12:39] <ppisati> henrix: but i never used it
[12:40] <henrix> ppisati: me either... but i've installed it loooong ago so that i could give it a try. but never did :)
[12:42] <ppisati> git clone bzr::lp:$PROJECT
[12:42] <ppisati> and it works
=== sz0 is now known as sz0`
=== sz0` is now known as sz0
=== sz0 is now known as sz0`
=== sz0` is now known as sz0
=== sz0 is now known as sz0`
=== sz0` is now known as sz0
=== sz0 is now known as sz0`
=== sz0` is now known as sz0
[14:59] <backjlack> http://dpaste.com/1798914/ <- has anyone seen something like this with 3.13?
[15:05] <rtg> backjlack, have you tried a 3.14 kernel in order to see if this issue has already been fixed ?
[15:05] <backjlack> rtg: No, but I've tried 3.12.16 a few weeks ago and that was OK.
[15:06] <backjlack> Are there any 3.14 kernel packages to try out? I'd rather not build 3.14 right now.
[15:07] <rtg> backjlack, kernel.ubuntu.com/~kernel-ppa/mainline/v3.14.2-utopic/
[15:08] <rtg> backjlack, also, if you've the patience you could work with jsalisbury to bisect the issue
[15:08] <backjlack> rtg: I have patience, but I'm afraid I don't have much time.
[15:09] <rtg> well, thats up to you 'cause a kernel bisect can take awhile.
[15:09] <backjlack> Yes, I'm aware of that. I build my own kernels sometimes.
[15:10] <backjlack> Let's see if 3.14 fixes the problem.
[15:10] <jsalisbury> backjlack, if you open a bug report, I'd be more than happy to help bisect with you.  For your part, it would require you test some kernels after I build them, then report back if they have the bug or not.
[15:10] <rtg> backjlack, jsalisbury builds the kernels for you so you on'y have to install, reboot, and do your snapshot.
[15:17] <backjlack> jsalisbury rtg: Ok, I've got 3.14 installed on the box. I'll test it for 1-2 days and file the bug afterwards.
[15:17] <backjlack> At least we'll know what has to be done at that point.
[15:17] <jsalisbury> backjlack, I'll keep an eye out for the bug report.
[15:17] <backjlack> It really looks like it's snapshot related because I'm running into this with Docker.
[15:18] <backjlack> docker+btrfs
[16:19] <rtg> apw, the patch I sent for the __udivdi3 modpost error ultimately used do_div(). I knew there was a better way. Also pushed to Utopic master-next
[16:30] <apw> rtg, that looks much prettier
[16:30] <rtg> apw, yup
[17:07] <rtg> jsalisbury, please see if you can get this guy to help you with a bisect. There are a lot of bnx2s out there. https://bugs.launchpad.net/bugs/1313591
[17:08] <ubot2> Launchpad bug 1313591 in linux (Ubuntu) "Panic on 3.13.0-24 with bnx2, iptables and MASQUERADE" [Undecided,Confirmed]
[17:08] <jsalisbury> rtg, will do
[17:09] <jsalisbury> rtg, looks to be fixed in 3.14.1, so I'll reverse bisect.
[18:05] <fuzion24> hello, I'm running 14.04 on a 11,1 mbp retina 13", the laptop died because of battery and on boot now hands on "X86 Booting SMP configuration"
[18:06] <fuzion24> this looks similar to my issue, but this kernel was previously booting until it died via power loss.  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1284085
[18:06] <ubot2> Launchpad bug 1284085 in linux (Ubuntu) "unable to boot after install on 2013 macbook air" [High,Confirmed]
[18:07] <fuzion24> yea, what the bot said ^
[20:20] <ernie_> suomesta ketään?
[20:22] <ernie_> I need help making my first kernel module
[20:28] <ernie_> Why makefile says: there is no rule to producing mymodule?
[21:05] <arges> bjf: jsalisbury bug 1289728 says fix committed for ubuntu-quantal. Which tree is it in?
[21:05] <ubot2> Launchpad bug 1289728 in linux-ti-omap4 (Ubuntu Saucy) "CVE-2014-0049" [Medium,Fix committed] https://launchpad.net/bugs/1289728
[21:07] <arges> bjf: jsalisbury n/m my brain isn't working today
[21:12] <arges> bjf: http://zinc.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=commit;h=5a4214563afab122a847035bc64c6e5ef9736d80
[21:40] <sconklin> hay arges, you have any thoughts about this? https://bugzilla.redhat.com/show_bug.cgi?id=1015989 - we're seeing the same thing on stock Ubuntu 14.04 EC2 guests
[21:40] <ubot2> bugzilla.redhat.com bug 1015989 in kernel "kernel panic in nf_nat_cleanup_conntrack in netns_cleanup_net with Docker" [Unspecified,Assigned]
[21:41] <sconklin> here's the upstream bug https://bugzilla.kernel.org/show_bug.cgi?id=65191
[21:41] <ubot2> bugzilla.kernel.org bug 65191 in Netfilter/Iptables "BUG in nf_nat_cleanup_conntrack" [Normal,New]
[21:41] <arges> sconklin: hey! reading through it now
[21:42] <sconklin> I may drop due to weather. Not lack of interest :-)
[21:44] <arges> sconklin:haven't seen this particular issue, was looking at a  few conntrack/netfilter issues in the past few months. But this seems to be slightly different. Have you guys tried any later kernels? 3.15?
[21:56] <sconklin> arges: no, the only thing we've tried is 14.04
[22:04] <sconklin> I have to deal with weather. I'll get back to you tomorrowe
[22:04] <arges> take care
[22:04] <sconklin> http://radar.weather.gov/radar.php?product=NCR&rid=GWX&loop=yes
=== sz0_ is now known as sz0`
=== sz0` is now known as sz0_