/srv/irclogs.ubuntu.com/2013/02/18/#ubuntu-kernel.txt

=== u1neb is now known as benlu
=== work_alkisg is now known as alkisg
alkisgSamba crashes with the new linux-generic-lts-quantal kernel...06:32
alkisgAnd virtualbox (-ose) can't compile its modules with dkms06:34
alkisgsmbd crash: http://paste.ubuntu.com/1675846/06:38
alkisgbrb with the older kernel to verify my setup is working there...06:38
work_alkisgIt 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 reboot07:45
=== work_alkisg is now known as alkisg
alkisgUnfortunately apport asks to file a bug report but it just stops after asking a few samba-related questions07:45
ppisatimoin08:00
=== smb` is now known as smb
smbmorning08:43
* apw yawns08:48
* smb tries not to join08:49
apwalkisg, is there any kernel messages with that from dmesg ? 08:51
apwsac08:51
=== AceLan_ is now known as AceLan
alkisgapw: nothing in dmesg or syslog08:55
alkisgTrying after 1 hour, it worked once more again, then stopped working again08:55
alkisg(with no service reboots involved)08:56
apwalkisg, so this is smbd which i think the #ubuntu-server people probabally deal with most08:57
alkisgapw: ah, thanks, didn't think of that one, will join in a bit08:58
apwalkisg, it must be an interaction between the two but they out to know how to debug it better than us09:00
alkisgGotcha, I'll first gather more info to be in a position to give better feedback and I'll ask there afterwards - thanks again09:01
* ppisati goes to move his car before he gets a fine :P09:15
=== bambee is now known as rperier
=== henrix_ is now known as henrix
apwhenrix, who did the replacent samsung brickage patch backports in the end, and are they already applied ?09:21
apwhenrix, "      efi: Clear EFI_RUNTIME_SERVICES rather than EFI_BOOT by "noefi" boot parameter09:22
apw" that one just hit linus' tree and the merge commit says its anohter bit for that series09:22
henrixapw: i believe we reverted our initial solution and applied the bits from upstream stable updates09:30
apwhenrix, well i think we may be missing a fix, which only appeared over the weekend, sigh09:31
henrixapw: ups! :p09:32
apwhenrix, nothing we did wrong, just a bug found in it.09:32
apwhenrix, 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 anything09:33
apws/effiective/an issue09:33
=== henrix_ is now known as henrix
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
caribousmb: apw: just tested latest linux-crashdump meta-package. Works like a charm !!!10:12
caribousmb: apw: it now pulls kdump-tools which works as expected10:12
smbcaribou, Good to hear... so one more off the list...10:12
caribousmb: I'm on the blueprint now.10:13
caribousmb: the only thing is that I had to increase the crashkernel= parameter above 128Mb (192Mb worked) to get enough space10:13
caribousmb: our default value is at 64Mb which is clearly too small10:14
smbcaribou, 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:15
caribousmb: I was never too worried about it, since anything above 2G was defaulting to 128Mb,but now it is no longer sufficient10:16
caribousmb: let me test again with more memory in my VM10:16
caribousmb: works fine with crashkernel=128M on a 4Gb VM. Maybe my first test was wrong10:20
caribousmb: I'll look at it again later10:20
smbcaribou, 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
apwat least it sounds close10:20
caribousmb: partly true; the crashkernel= syntax makes a difference depending on the size of the available memory10:21
caribousmb: crashkernel=384M-2G:64M,2G-:128M10:21
smbcaribou, I know. Though that is more of a "we don't want to take away too much if there isn't much" thing10:21
caribousmb: yep. in the default case (i.e. < 2G) crash dump woudln't work10:22
caribousmb: Debian defaults to 128Mb for all cases10:22
smbCertainly, on a system with below 512M this is quite a waste... but then...10:24
caribousmb: ok, I'm going to work on adapting apport to the new structure10:25
smbcaribou, ok10:25
=== 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
lantiziaapw: are you about?15:10
ppisatibrb15:52
henrixinfinity: any luck with the bugs verification?16:06
infinityhenrix: Not over the weekend, no.  And it's a holiday in the US (and here) right now, so I dunno about today.16:33
henrixinfinity: ack16:33
infinitylamont: Are you working today?  Did pinky get our console issues on sagari sorted so we can verify those SRUs?16:33
apwlantizia, hi17:01
* ppisati -> gym17:09
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
=== zequence_ is now known as zequence
* rtg -> lunch18:19
=== yofel_ is now known as yofel
rtgapw, you'll enjoy this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1128840/comments/1419:18
ubot2Ubuntu 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:18
apwrtg :)19:34
rtgapw, we'll probably get a diatribe out of it.19:34
apwrtg, dogpile material and no mistake19:35
infinityapw: Preeeeetty sure the "Linus Torvalds" the subscribed isn't actually Linus. :P19:47
infinitys/the/they/19:47
rtginfinity, his LP ID is kind of funny :)19:48
infinityAs is the email address is derived from.19:48
infinityIt's definitely not Linus. :P19:48
rtgno, I think you're right19:49
apwhe cirtainly deserves to be subscribed to every single 20:03
apwbug ... for having that name :)20:03
* apw calls it a day ...20:19
=== cmagina is now known as cmagina_away
=== cmagina_away is now known as cmagina
* rtg -> EOD21:27
infinityhggdh: How goes the regression testing on the precise SRU?23:05
hggdhinfinity: sorry, forgot to check the results, give me a few minutes23:06
hggdhinfinity: done, bug updated.23:08
infinitybjf: Want to do me a favour and turn the crank on the bot a few times and see where it settles?23:08
infinityhggdh: I'm guessing there was some regression testing to be done for armadaxp for precise, too?23:10
infinityppisati: 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
bjfinfinity, ack23:11
ppisatiinfinity: precise respin? wasn't aware23:11
ppisatiinfinity: anyhow, if it's a x86-only fix, i'll skip it23:12
hggdhinfinity: for quantal, kernel 3.5.0-1609.11 is done. For precise, I will jump the gun and start the tests now23:12
infinityppisati: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/112451423:12
ubot2Ubuntu bug 1124514 in Kernel SRU Workflow "linux-ti-omap4: <version to be filled> -proposed tracker" [Medium,In progress]23:12
infinityppisati: 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
ppisatiinfinity: doh!23:13
ppisatiinfinity: completely missed it...23:13
bjfinfinity, i think the bot has done it's all23:22
ppisatiinfinity: done23:26
ppisatiinfinity: but i invalidate it...23:27
ppisatiinfinity: uhm, hope it's ok23:27
=== henrix is now known as henrix_
infinitybjf: 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.23:41

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!