=== u1neb is now known as benlu === work_alkisg is now known as alkisg [06:32] Samba crashes with the new linux-generic-lts-quantal kernel... [06:34] And virtualbox (-ose) can't compile its modules with dkms [06:38] smbd crash: http://paste.ubuntu.com/1675846/ [06:38] brb with the older kernel to verify my setup is working there... [07:45] 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 === work_alkisg is now known as alkisg [07:45] Unfortunately apport asks to file a bug report but it just stops after asking a few samba-related questions [08:00] moin === smb` is now known as smb [08:43] morning [08:48] * apw yawns [08:49] * smb tries not to join [08:51] alkisg, is there any kernel messages with that from dmesg ? [08:51] sac === AceLan_ is now known as AceLan [08:55] apw: nothing in dmesg or syslog [08:55] Trying after 1 hour, it worked once more again, then stopped working again [08:56] (with no service reboots involved) [08:57] alkisg, so this is smbd which i think the #ubuntu-server people probabally deal with most [08:58] apw: ah, thanks, didn't think of that one, will join in a bit [09:00] alkisg, it must be an interaction between the two but they out to know how to debug it better than us [09:01] 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 === bambee is now known as rperier === henrix_ is now known as henrix [09:21] henrix, who did the replacent samsung brickage patch backports in the end, and are they already applied ? [09:22] henrix, " efi: Clear EFI_RUNTIME_SERVICES rather than EFI_BOOT by "noefi" boot parameter [09:22] " that one just hit linus' tree and the merge commit says its anohter bit for that series [09:30] apw: i believe we reverted our initial solution and applied the bits from upstream stable updates [09:31] henrix, well i think we may be missing a fix, which only appeared over the weekend, sigh [09:32] apw: ups! :p [09:32] henrix, nothing we did wrong, just a bug found in it. [09:33] 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] s/effiective/an issue === henrix_ is now known as henrix === henrix is now known as henrix_ === henrix_ is now known as henrix [10:12] smb: apw: just tested latest linux-crashdump meta-package. Works like a charm !!! [10:12] smb: apw: it now pulls kdump-tools which works as expected [10:12] caribou, Good to hear... so one more off the list... [10:13] smb: I'm on the blueprint now. [10:13] smb: the only thing is that I had to increase the crashkernel= parameter above 128Mb (192Mb worked) to get enough space [10:14] smb: our default value is at 64Mb which is clearly too small [10:15] 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] 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] smb: let me test again with more memory in my VM [10:20] smb: works fine with crashkernel=128M on a 4Gb VM. Maybe my first test was wrong [10:20] smb: I'll look at it again later [10:20] 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] at least it sounds close [10:21] smb: partly true; the crashkernel= syntax makes a difference depending on the size of the available memory [10:21] smb: crashkernel=384M-2G:64M,2G-:128M [10:21] 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] smb: yep. in the default case (i.e. < 2G) crash dump woudln't work [10:22] smb: Debian defaults to 128Mb for all cases [10:24] Certainly, on a system with below 512M this is quite a waste... but then... [10:25] smb: ok, I'm going to work on adapting apport to the new structure [10:25] caribou, ok === yofel_ is now known as yofel === henrix is now known as henrix_ === henrix_ is now known as henrix === amitk is now known as amitk-afk === amitk is now known as amitk-afk === amitk-afk is now known as amitk === rsalveti_ is now known as rsalveti [15:10] apw: are you about? [15:52] brb [16:06] infinity: any luck with the bugs verification? [16:33] 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] infinity: ack [16:33] lamont: Are you working today? Did pinky get our console issues on sagari sorted so we can verify those SRUs? [17:01] lantizia, hi [17:09] * ppisati -> gym === henrix is now known as henrix_ === henrix_ is now known as henrix === zequence_ is now known as zequence [18:19] * rtg -> lunch === yofel_ is now known as yofel [19:18] apw, you'll enjoy this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1128840/comments/14 [19:18] 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] rtg :) [19:34] apw, we'll probably get a diatribe out of it. [19:35] rtg, dogpile material and no mistake [19:47] apw: Preeeeetty sure the "Linus Torvalds" the subscribed isn't actually Linus. :P [19:47] s/the/they/ [19:48] infinity, his LP ID is kind of funny :) [19:48] As is the email address is derived from. [19:48] It's definitely not Linus. :P [19:49] no, I think you're right [20:03] he cirtainly deserves to be subscribed to every single [20:03] bug ... for having that name :) [20:19] * apw calls it a day ... === cmagina is now known as cmagina_away === cmagina_away is now known as cmagina [21:27] * rtg -> EOD [23:05] hggdh: How goes the regression testing on the precise SRU? [23:06] infinity: sorry, forgot to check the results, give me a few minutes [23:08] infinity: done, bug updated. [23:08] bjf: Want to do me a favour and turn the crank on the bot a few times and see where it settles? [23:10] hggdh: I'm guessing there was some regression testing to be done for armadaxp for precise, too? [23:11] 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] infinity, ack [23:11] infinity: precise respin? wasn't aware [23:12] infinity: anyhow, if it's a x86-only fix, i'll skip it [23:12] 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] ppisati: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1124514 [23:12] Ubuntu bug 1124514 in Kernel SRU Workflow "linux-ti-omap4: -proposed tracker" [Medium,In progress] [23:13] 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] infinity: doh! [23:13] infinity: completely missed it... [23:22] infinity, i think the bot has done it's all [23:26] infinity: done [23:27] infinity: but i invalidate it... [23:27] infinity: uhm, hope it's ok === henrix is now known as henrix_ [23:41] 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.