[06:32] <alkisg> Samba crashes with the new linux-generic-lts-quantal kernel...
[06:34] <alkisg> And virtualbox (-ose) can't compile its modules with dkms
[06:38] <alkisg> smbd crash: http://paste.ubuntu.com/1675846/
[06:38] <alkisg> brb with the older kernel to verify my setup is working there...
[07:45] <work_alkisg> It works fine with the stock precise kernel, and it works only once with the lts-quantal kernel, even if I restart smbd it doesn't work again without reboot
[07:45] <alkisg> Unfortunately apport asks to file a bug report but it just stops after asking a few samba-related questions
[08:00] <ppisati> moin
[08:43] <smb> morning
[08:48]  * apw yawns
[08:49]  * smb tries not to join
[08:51] <apw> alkisg, is there any kernel messages with that from dmesg ? 
[08:51] <apw> sac
[08:55] <alkisg> apw: nothing in dmesg or syslog
[08:55] <alkisg> Trying after 1 hour, it worked once more again, then stopped working again
[08:56] <alkisg> (with no service reboots involved)
[08:57] <apw> alkisg, so this is smbd which i think the #ubuntu-server people probabally deal with most
[08:58] <alkisg> apw: ah, thanks, didn't think of that one, will join in a bit
[09:00] <apw> alkisg, it must be an interaction between the two but they out to know how to debug it better than us
[09:01] <alkisg> Gotcha, I'll first gather more info to be in a position to give better feedback and I'll ask there afterwards - thanks again
[09:15]  * ppisati goes to move his car before he gets a fine :P
[09:21] <apw> henrix, who did the replacent samsung brickage patch backports in the end, and are they already applied ?
[09:22] <apw> henrix, "      efi: Clear EFI_RUNTIME_SERVICES rather than EFI_BOOT by "noefi" boot parameter
[09:22] <apw> " that one just hit linus' tree and the merge commit says its anohter bit for that series
[09:30] <henrix> apw: i believe we reverted our initial solution and applied the bits from upstream stable updates
[09:31] <apw> henrix, well i think we may be missing a fix, which only appeared over the weekend, sigh
[09:32] <henrix> apw: ups! :p
[09:32] <apw> henrix, nothing we did wrong, just a bug found in it.
[09:33] <apw> henrix, from the looks of it it is only effective if people add extra command line options, so i don't think it is a disaster or anything
[09:33] <apw> s/effiective/an issue
[10:12] <caribou> smb: apw: just tested latest linux-crashdump meta-package. Works like a charm !!!
[10:12] <caribou> smb: apw: it now pulls kdump-tools which works as expected
[10:12] <smb> caribou, Good to hear... so one more off the list...
[10:13] <caribou> smb: I'm on the blueprint now.
[10:13] <caribou> smb: the only thing is that I had to increase the crashkernel= parameter above 128Mb (192Mb worked) to get enough space
[10:14] <caribou> smb: our default value is at 64Mb which is clearly too small
[10:15] <smb> caribou, That would bring back the minimal initrd discussion. Which seemed to sometimes have weird side-effects (at least for me on a desktop with a card-reader)
[10:16] <caribou> smb: I was never too worried about it, since anything above 2G was defaulting to 128Mb,but now it is no longer sufficient
[10:16] <caribou> smb: let me test again with more memory in my VM
[10:20] <caribou> smb: works fine with crashkernel=128M on a 4Gb VM. Maybe my first test was wrong
[10:20] <caribou> smb: I'll look at it again later
[10:20] <smb> caribou, Well, I would assume that it working or not rather depends on how big kernel and initrd are. Which is independent of the overall RAM...
[10:20] <apw> at least it sounds close
[10:21] <caribou> smb: partly true; the crashkernel= syntax makes a difference depending on the size of the available memory
[10:21] <caribou> smb: crashkernel=384M-2G:64M,2G-:128M
[10:21] <smb> caribou, I know. Though that is more of a "we don't want to take away too much if there isn't much" thing
[10:22] <caribou> smb: yep. in the default case (i.e. < 2G) crash dump woudln't work
[10:22] <caribou> smb: Debian defaults to 128Mb for all cases
[10:24] <smb> Certainly, on a system with below 512M this is quite a waste... but then...
[10:25] <caribou> smb: ok, I'm going to work on adapting apport to the new structure
[10:25] <smb> caribou, ok
[15:10] <lantizia> apw: are you about?
[15:52] <ppisati> brb
[16:06] <henrix> infinity: any luck with the bugs verification?
[16:33] <infinity> henrix: Not over the weekend, no.  And it's a holiday in the US (and here) right now, so I dunno about today.
[16:33] <henrix> infinity: ack
[16:33] <infinity> lamont: Are you working today?  Did pinky get our console issues on sagari sorted so we can verify those SRUs?
[17:01] <apw> lantizia, hi
[17:09]  * ppisati -> gym
[18:19]  * rtg -> lunch
[19:18] <rtg> apw, you'll enjoy this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1128840/comments/14
[19:18] <ubot2> Ubuntu bug 1128840 in linux (Ubuntu) "Thousands of lines of "phy0 -> rt2x00pci_regbusy_read: Error - Indirect register access failed" printed to dmesg and to TTY's" [Undecided,Confirmed]
[19:34] <apw> rtg :)
[19:34] <rtg> apw, we'll probably get a diatribe out of it.
[19:35] <apw> rtg, dogpile material and no mistake
[19:47] <infinity> apw: Preeeeetty sure the "Linus Torvalds" the subscribed isn't actually Linus. :P
[19:47] <infinity> s/the/they/
[19:48] <rtg> infinity, his LP ID is kind of funny :)
[19:48] <infinity> As is the email address is derived from.
[19:48] <infinity> It's definitely not Linus. :P
[19:49] <rtg> no, I think you're right
[20:03] <apw> he cirtainly deserves to be subscribed to every single 
[20:03] <apw> bug ... for having that name :)
[20:19]  * apw calls it a day ...
[21:27]  * rtg -> EOD
[23:05] <infinity> hggdh: How goes the regression testing on the precise SRU?
[23:06] <hggdh> infinity: sorry, forgot to check the results, give me a few minutes
[23:08] <hggdh> infinity: done, bug updated.
[23:08] <infinity> bjf: Want to do me a favour and turn the crank on the bot a few times and see where it settles?
[23:10] <infinity> hggdh: I'm guessing there was some regression testing to be done for armadaxp for precise, too?
[23:11] <infinity> ppisati: Were you planning to rebase precise/ti-omap4, or just skip that one, since it looks like it was an x86-only revert?
[23:11] <bjf> infinity, ack
[23:11] <ppisati> infinity: precise respin? wasn't aware
[23:12] <ppisati> infinity: anyhow, if it's a x86-only fix, i'll skip it
[23:12] <hggdh> infinity: for quantal, kernel 3.5.0-1609.11 is done. For precise, I will jump the gun and start the tests now
[23:12] <infinity> ppisati: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1124514
[23:12] <ubot2> Ubuntu bug 1124514 in Kernel SRU Workflow "linux-ti-omap4: <version to be filled> -proposed tracker" [Medium,In progress]
[23:13] <infinity> ppisati: I'll let you be the judge.  If you think it's pointless, please dupe that bug to the older tracking bug to get it off the bot's radar.
[23:13] <ppisati> infinity: doh!
[23:13] <ppisati> infinity: completely missed it...
[23:22] <bjf> infinity, i think the bot has done it's all
[23:26] <ppisati> infinity: done
[23:27] <ppisati> infinity: but i invalidate it...
[23:27] <ppisati> infinity: uhm, hope it's ok
[23:41] <infinity> bjf: Cranking the bot again should look more pleasant now.  I think all I haven't released at this point is ti-omap4 and armadaxp on precise.