[07:54] <apw> mornin
[08:19] <ppisati> morning *
[08:20] <jk-> hey ppisati 
[08:20] <smb> morning .+
[08:21] <jk-> ooh, it's a fnmatch vs. regex competition
[08:21] <smb> not competition really... :-P
[09:09] <mooky68> Sorry for asking again but I have observed a memory leak issue with the 2.6.31-rt kernel on Lucid: /proc/slabinfo shows a growing count of mm_struct after a resume from hibernate (I didn't reproduced the issue with the corresponding 2.6.32 generic kernel or with a vanilla RT kernel). Is this a known issue ? Should I open a bug report on launchpad ? Thank you
[12:18] <Kano> apw: how about adding the 3 commints for dvb which should be in the stable kernel as bugfix anyway?
[12:19] <apw> which are those then?
[12:19] <Kano> its even in launchpad, a bit hidden by a bugs.debian link
[12:21] <smb> telling a bug number _may_ help
[12:23] <Kano> #838130
[12:24] <apw> bug #838130
[12:24] <ubot2> Launchpad bug 838130 in linux "Kernel 3.0 breaks DVB-T (ISDB-Tb) in DiBcom 8000" [Undecided,Confirmed] https://launchpad.net/bugs/838130
[12:24] <Kano> http://git.linuxtv.org/pb/media_tree.git/shortlog/refs/heads/for_v3.0
[12:25] <Kano> 3 patches basically, i only knew of 2 first, added am and they worked. but most likely it would be best to add all 3
[12:27] <Kano> they are in another position too
[12:27] <Kano> i fetched it from
[12:27] <Kano> http://git.linuxtv.org/media_tree.git/patch/79fcce3230b140f7675f8529ee53fe2f9644f902
[12:27] <Kano> http://git.linuxtv.org/media_tree.git/patch/bff469f4167fdabfe15294f375577d7eadbaa1bb
[12:27] <Kano> but the position should not matter
[12:29] <Kano> otherwise same dvb-t devices do not work
[12:32] <Kano> did somebody try btrfs with -11.18 kernel, somehow it seems to be very slow
[12:38] <tjaalton> oh, I just bought the same dvb tuner
[12:39] <tjaalton> well, the used module is the same, hauppauge nova-td
[12:41] <Kano> and it worked with 3.0?
[12:43] <tjaalton> bought it yesterday, haven't really tested it yet
[12:44] <Kano> good idea to test, .38 should do
[12:44] <Kano> 3.0 without patch most likely not
[12:44] <tjaalton> but apparently vlc supports dvb?
[12:44] <Kano> never used vlc for that
[12:45] <Kano> only kaffeine, vlc, tvheadend
[12:45] <Kano> err vdr not vlc
[12:45] <tjaalton> trying to forward the device to a kvm vdr instance, but it doesn't see the device
[12:46] <Kano> not my problem
[12:46] <tjaalton> was i suggesting that?
[14:21] <jwi> tgardner: for the ENERGY_PERF_BIAS patch, you might want to consider picking 17edf2d79f1ea6dfdb4c444801d928953b9f98d6 as well
[14:23] <tgardner> jwi, good catch.
[14:27] <jwi> maverick too, when 2.6.35.14 lands there
[14:29] <tgardner> jwi, I'll work on Maverick once its determined that these patches really have an impact.
[14:29] <smb> tgardner, Hm, was that the right thread to re: on?
[14:29] <tgardner> smb, shit
[14:31] <tgardner> smb, since the original PERF BIAS patch has already been acked, I'm just gonna apply the correction.
[14:33] <smb> tgardner, It looks safe enough to be ok even if it wouldn't... You could add my ack there...
[14:34] <tgardner> smb, done
[14:37]  * apw might have found .3s to shave off the kernel boot time
[14:38] <smb> apw, serial init?
[14:38] <apw> heh oddly not, acpi_init, over halving it in my rather unscientific testing
[14:39] <smb> uhm... acpi not very scientific, just this uneasy feeling of speeding that up...
[14:39] <apw> getting my test platform back to around the 0.98s to userspace
[14:40] <apw> smb, heh the speedup is all in kernel map handling
[14:40] <smb> ok, that sounds less worrying
[14:41] <apw> yeah its poor-mans RCU handling which is fine unless you are racing with a cpu hog, like unpacking the initramfs
[15:01] <bjf> apw, have you looked at the boot-speed reports i've generated ?
[15:01] <bjf> apw, if so, are they useful ?
[15:09] <jwi> tgardner: what i was trying to say is: 2.6.35.14 has the initial PERF_BIAS patch you just added, but it's missing the print fix. so when 2.6.35.14 lands in maverick, it will need the same fix up.
[15:12] <tgardner> jwi, 2.6.35.14 hasn't been pushed yet, has it? if not, then I ought to bug Andi to add the second patch.
[15:13] <jwi> tgardner: http://lkml.org/lkml/2011/8/1/324 - pushed about 50 days ago :)
[15:15] <tgardner> jwi, looks like the last stable update we pulled was .13
[15:16] <tgardner> q
[15:16]  * ogasawara back in 20
[15:27] <cr3> in the output of dmidecode, under the Processor section, is the ID attribute expected to be unique across processors?
[15:35] <CluelessPerson> hi everyone
[15:36] <CluelessPerson> Hi
[15:36] <CluelessPerson> I get an error sometimes when I reboot my server
[15:36] <CluelessPerson> init: ureadahead-other main process (712) terminated with status 4
[15:36] <CluelessPerson> [   103.509461] [drm:pch_irq_handler] *ERROR* PCH poison interrupt
[15:36] <CluelessPerson> after doing some sort of check disk or whatever
[15:36] <CluelessPerson> it prevents my server from booting, and so is problematic
[15:52] <CluelessPerson> hello?
[16:10] <tgardner> apw, have you noticed that the changelog version numbers for the daily builds of LBM and linux-meta in pre-proposed are not correct? I think there should be tilde in it.
[17:11] <apw> tgardner, actually i think they are as intended, the linux-meta packages are alway built off of the closed tip, but they actually have just the abi incremented
[17:11] <apw> tgardner, thus they are always less than any official bump would be, whether ~ or not
[17:11] <jbicha> the Oneiric kernel is actually 3.0.4, right? just wondering if our version number should reflect that
[17:12] <apw> jbicha, it doesn't do that in order to prevent abui bumps unecesarily
[17:12] <apw> jbicha, typically our version numbers there have not reflected the stable number, they are always 2.6.38-x
[17:13] <apw> jbicha, and these would have been just 3.0-x if userspace wasn't so utterly broken in soooo many ways
[17:14] <jbicha> oh ok, it's the Linux 3.0 problem, thanks!
[17:30] <apw> CluelessPerson, it sounds like that error implies the graphics h/w got all upset about something, an error indication of some sort.  what though is not specified.  only ever seen it on resume in the past
[17:31] <CluelessPerson> apw,  only happens during check disk or checking the file systems mounts
[17:31] <CluelessPerson> apw, appeared immediately after adding automounts to fstab
[17:32] <apw> CluelessPerson, that is odd indeed as the interrupt definatly comes from the display adapter
[17:33] <apw> CluelessPerson, and the other error should just indicate ureadahead is not helping but should not trigger machine death
[17:34] <apw> bjf, have you noticed the Launchpad Janitor has taken it upon itself to mark our bugs Confirmed, when they ahve more than one person affected
[17:34] <apw> we may need to use Triaged instead when we have sufficient logs
[17:40]  * apw calls it a day, i am not right
[17:55]  * tgardner --> lunch
[17:55]  * CluelessPerson is proud of himself.  He is learning. :D
[17:59] <CluelessPerson> hrm, for some reason it won't start, but everything else functions correctly.
[17:59] <CluelessPerson> AH, lol. no wonder.
[18:01] <jbicha> x`/wc
[18:09] <CluelessPerson> lol
[18:10] <CluelessPerson> my changes are  being stupid
[18:45] <CluelessPerson> hrm..
[18:45] <CluelessPerson> For some reason the script isn't detecting the lock file in ramdisk.
[18:45] <CluelessPerson> and so the server is starting, and the script isn't detecting it.
[19:10]  * jjohansen -> lunch
[20:47] <esoergel> I have a possible kernel regression (I'm told).  I'm running a clean install of Ubuntu 11.04 on a Thinkpad R400 purchased new in 2009.  The display freezes at random; I can't switch to console mode, I can't move the mouse, and any on-screen animations freeze.  This problem doesn't occur if I have Ubuntu 10.04 installed.  How should I file this bug? 
[20:59] <sforshee> esoergel, start by running 'ubuntu-bug linux' in a terminal, that will take you through the process of filing the bug and attach some information about your hardware to the bug report
[21:00] <esoergel> sforshee: thank you, can you think of any other tests or anything I should run to add to it?
[21:00] <sforshee> esoergel, if you can manage to trigger the bug in console mode you might get some information printed to the screen that you could photograph and attach to the bug
[21:01] <sforshee> otherwise you should get some guidance on what to do next after you file the bug
[21:01] <esoergel> sforshee: okay, thanks, I'll file it
[23:03] <bryceh> apw, lp #850772 is weird.  an intel gpu lockup on a system with i915 loaded but no Intel graphics card in sight.
[23:03] <ubot2> Launchpad bug 850772 in xserver-xorg-video-intel "False GPU lockup EIR: 0x00000010 PGTBL_ER: 0x00000012" [Undecided,Incomplete] https://launchpad.net/bugs/850772