[07:35]  * smb yawns and reads scrollback...
[07:41] <smb> hggdh, Have not yet looked back at the bug bug mainly I am looking for a full set of messages from wherever you extracted the order 5 messages. Maybe seeing oom killer going for something and/or at least showing memory levels at that point.
[07:42] <smb> At the time of the order 5 messages it seems like only being bad for higher level allocations but still some reserves for lower orders. Can be related or just a side effect. It is not clear what exactly happens later.
[10:21] <ppisati> guys, what's the debian/rules "action" to just unpack the kernel and do the config?
[10:22] <apw> ppisati, as in to make the debuan/build/build-<flavour> with the .config in it?
[10:22] <apw> ppisati, thats fdr prepare-<flavour>
[10:24] <ppisati> ok
[10:24]  * ppisati needs a fdr cheatsheet
[10:25] <ppisati> btw, there's a clash between one of our option and the TI BSP
[10:25] <ppisati> basically, i get a solid freeze on boot for some reason
[10:25] <ppisati> and i'm trying to find what's wrong without copying opver the entire TI .config
[10:26] <apw> ppisati, if what you are really interested in is the final config then fdr genconfigs makes configs in CONFIGS/* in your tree
[10:27] <ppisati> isn't .config the final config?
[10:28] <apw> ppisati, yes, but i am saying if all you wanted was the config then genconfigs makes the same .config contents in CONFIGS/<names>
[10:28] <ppisati> ok
[10:32] <ppisati> from time to time pusleaudio goes berserk and i get a "nice" metallic/robotic output... :)
[10:36] <apw> ppisati, yep, it does do that, good isn't it
[10:37] <ppisati> yep
[10:40]  * apw cries at the state of launchpad, even worse than normal
[10:40] <apw> (Error ID: OOPS-2020DR100)
[10:40] <ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=2020DR100
[10:40] <apw> (Error ID: OOPS-2020DR100)
[10:40] <ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=2020DR100
[10:41] <bryceh> apw, they just did a rollout a few hours ago
[10:41] <apw> bryceh, i know, and as usual its completely broken for everything i need to use
[10:42] <apw> literally everything i touch just times out, all my scripting is exploding, i can't nominate bugs, other than that it is purfect
[10:44] <bryceh> apw, ouch
[10:44] <apw> yeah they decided to do a h/w change wherein we'll be running on the slave server for a day in parallel to a s/w update
[10:44] <apw> so they have no idea if the issues are the new code or just the slave not being up to the job
[10:45]  * apw knows which bucket he would put that decision
[10:45] <apw> ppisati, ok as we can't use launchpad for CVE coordination ... i am looking at 2011-1010
[10:49] <apw> ppisati, oh and be warned that http://people.canonical.com/~kernel/reports/kernel-cves.html stopped updating at 7:30 UTC as well
[10:53] <ppisati> apw: no prob, i'm all for linaro2ubuntu stuff these days
[10:54] <ppisati> and btw, i just noticed that even the linaro kernel hangs/panics/etcetc on boot
[10:54] <ppisati> so the issue is somewhere else...
[10:54] <ppisati> uhmm...
[13:03] <bastik_> Hi, after automatic upgrade to 2.6.38-10 on natty, my Graphics card (ATI Mobility Radeon X600) stops working. Shall I file a Kernel bug on launchpad?
[13:05] <apw> bastik_, yes
[13:06] <bastik_> ok, bye
[13:06] <smb> ...also point out when filing the bug whether you where using the binary (fglrx) or open source driver (radeon)
[13:08] <herton> bastik_: also file the bug from the affected machine using 'ubuntu-bug -p linux' (see https://wiki.ubuntu.com/Kernel/Bugs)
[13:10] <bastik_> thanks for the hints, I have xserver-xorg-video-radeon, this should be the open source package
[13:12] <bastik_> do you need diagnostic, when old kernel is booted (all is fine then)?
[14:45]  * ogasawara back in 20
[15:03] <sforshee> cking, here's a fun problem. Your stap script indicates that the machine hangs in acpi_hw_write_pm1_control() on the way out of s3. Any ideas? bug 708286
[15:03] <ubot2> Launchpad bug 708286 in linux "Resume after suspend not working - Toshiba Tecra R700" [High,Confirmed] https://launchpad.net/bugs/708286
[15:05] <cking> sforshee, actually it indicates that we've written to the PM1 control register(s) and the machine suspended. that was the last thing we saw. If it did not come out of resume I suspect we did not re-enter the kernel
[15:05] <sforshee> that does make more sense
[15:08] <sforshee> cking, so is there anything more to try with that machine? or is it a hopeless case?
[15:09] <cking> sforshee, we can see if it enters the kernel.
[15:58]  * bjf -> dr. appt.
[16:04]  * herton --> lunch
[16:23]  * smb -> pint
[16:23]  * apw looks at smb with envy
[16:23]  * smb drinks one for apw
[17:04] <apw> jjohansen, flys like a rocket ship ...
[17:05] <jjohansen> hehe, well we are getting to the end of the pastable text
[17:11] <ppetraki> smb, yeah, that bug isn't resurfacing. what I think happened is I continue to run proposed kernels  in response to the s4 video corruption bug I found. Then kernel was upgraded since my return from Dublin and that bug is either fixed or covered up
[17:11] <ppetraki> smb, 100 s3, no fault found
[17:51] <tgardner> kees, what was the name of the tool that removed the U3 partition from a SanDisk Cruzer USB stick ?
[17:52] <kees> tgardner: u3-tool :)
[17:53] <tgardner> kees, ah, cool. thanks.
[17:53] <kees> tgardner: specifically u3-tool -p0 /dev/whatever
[17:53] <kees> (the raw device, not a partition, iirc)
[17:53] <tgardner> yep
[18:16] <kees> ogasawara: pcap issue is 810022 (I still need to check it out). kptr issue I addressed with procps 1:3.2.8-10ubuntu5, and hggdh didn't hit it in his testing, so I think we can ignore that for now.
[18:16] <kees> ogasawara: if there is a CONFIG option for kptr, it'd be nice to turn it on, though.
[18:17] <kees> ogasawara: but I don't think there is
[18:18] <ogasawara> kees: cool.  I'll investigate if there's a config for kptr.  I know the commit message mentioned setting it in /etc/sysctrl.conf if distro's wanted in enabled by default
[18:20] <kees> ogasawara: yeah, unless it went in the last month, I don't think there is, which is fine. procps will cover it
[18:29]  * bjf -> dentist
[18:51] <mjg59> apw: I thought 83ccc92aa7bc9b9d47fc31a7b54e663fb9a3d992 wasn't supposed to end up being shipped?
[18:51] <mjg59> (natty, cd1c7d22c84faf5513e53d0e5618c9b9a3e3824f in oneric)
[19:04]  * jjohansen lunch
[21:00] <tgardner> sforshee, tangerine is back
[21:03] <sforshee> tgardner, cool, thanks
[21:05]  * tgardner --> EOD
[21:35] <chrismsnz> Hi guys, I have a question about bug #586897 - apparently the patch has been released and merged into mainline kernel, is this appropriate for lucid kernel backport and next install media update for lucid?
[21:35] <ubot2> Launchpad bug 586897 in linux "stex driver (Promise SuperTrak 8350/4650,etc) produces drastic I/O errors/corruption with 10.04 or later" [Undecided,Confirmed] https://launchpad.net/bugs/586897
[21:36] <chrismsnz> it's regarding a popular piece of RAID hardware
[22:10] <jjohansen> chrismsnz: maybe, we will have to look at the patch etc, but if the patch is upstream and fixes a real problem for lucid it is something we do want to evaluate
[22:11] <jjohansen> chrismsnz: whether it goes into the lucid kernel or just the currently supported backport kernel will depend
[22:14] <bjf> chrismsnz, the kernel for the next lucid point release has already been uploaded so that patch won't make it in
[22:14] <chrismsnz> jjohansen: good to hear - is this done as part of a process that will happen on it's own or do I need to follow up?
[22:14] <chrismsnz> bjf: i see
[22:16] <jjohansen> chrismsnz: lucid has a long life, there are also the backport kernels.  With the patch going into 2.6.36.3 this should be automatically picked up in our newer kernels as long as it doesn't coincide with anything causing regressions.
[22:17] <bjf> chrismsnz, looking into the git repo to see if it has already been picked up
[22:17] <jjohansen> chrismsnz: their should be a natty backport kernel to lucid that will have this, if its going to go into the Lucid kernel there will have to be more followup
[22:18] <chrismsnz> jjohansen: ok - is there a supported way to use a backport kernel on the install media? The nature of this bug is such that it will install a completely broken system
[22:18] <jjohansen> hrmmm, no that is a problem.
[22:20] <jjohansen> chrismsnz: it would be possible to create a custom usb/iso but that isn't a generic solution
[22:20] <chrismsnz> probably the best solution is to install 9.10 and upgrade to Lucid, then install backported kernel before rebooting
[22:21] <jjohansen> chrismsnz: yeah, the next lucid point release is scheduled for  July 29, 2011
[22:24] <jjohansen> chrismsnz: so the patch is already in the natty kernel
[22:25] <chrismsnz> righto - looks like a karmic -> lucid upgrade, then install the natty backported kernel is the best way to get this system running lucid
[22:25] <chrismsnz> it's running karmic at the moment so no biggie
[22:26] <chrismsnz> I'll update the bug
[22:27] <bjf> chrismsnz, that patch is already in the lucid kernel
[22:28] <chrismsnz> bjf: that's surprising news - was the work done under another bug?
[22:28] <bjf> chrismsnz, looking
[22:28] <chrismsnz> bjf: also, does that mean the new lucid install media being released July 29th will contain the fix?
[22:29] <bjf> chrismsnz, it was picked up as a regular stable update patch set in january, yes it will be on the next media
[22:29] <bjf> chrismsnz, bug 705045
[22:29] <ubot2> Launchpad bug 705045 in linux "Lucid update to 2.6.32.28+drm33.12 stable release " [Medium,In progress] https://launchpad.net/bugs/705045
[22:30] <chrismsnz> that is excellent news
[22:31] <chrismsnz> thank you both for your help, I'll update the bug and suggest it for closure once I can test it
[23:23] <psusi> ok, I need someone to either talk me off the cliff, or join me in my crusade:  seriously, it is 2011 and the Linux kernel still can not handle surprise removal of a drive/media.  discuss.
[23:24] <chrismsnz> surprise removal of a non-hotswap drive?
[23:24] <psusi> eject a cdrom even
[23:24] <psusi> put a cdrom in, open a file on it ( maybe just cd a terminal to a directory on it ) and eject it... shit hits the fan
[23:26] <psusi> specifically, the fs can't be unmounted because it has open files, so it is lazily unmounted, which means it is just removed from the fs namespace... but still remains mounted as long as the open fd(s) exist... then you drop in a new cd, and you can not mount it because the old one is still mounted
[23:26] <psusi> things get even worse when you actually unplug a disk ( think usb flash stick ), especially if it has a raid or lvm on it
[23:27] <psusi> the kernel underwent a serious transition where the device driver layer got reworked to the bus/driver model that supports plug and play, but the block layer is still living in a non plug and play world
[23:28] <psusi> you remove a device ( echo 1 > /sys/block/sda/device/delete ) and the device vanishes from the namespace, but is not actually deleted until it is no longer in use... it can't signal to a fs or md or dm driver on top of it that it needs to go away now, stop using me
[23:29] <chrismsnz> D:
[23:29] <chrismsnz> I guess I've been conditioned after so many years of Linux use just to not attempt those things
[23:29] <psusi> so there it sits, in a zombie state, not there as far as you can see, but not gone until the last reference is dropped
[23:30] <psusi> it is really easy to forget if you have rhthmbox playing an mp3 on a cd, and hit X and it just gets rid of the window, but doesn't actually close.. if it was on pause and still has the mp3 open, everything looks cool so you eject the disk... but it's very much not cool
[23:31] <psusi> the system really needs to be able to deal with surprise removal in a post plug and play world
[23:33] <psusi> and the whole plug and play revolution started with windows 95... it's more than 15 years later and linux still isn't there... urgh...
[23:34] <psusi> must fix this...
[23:38] <psusi> 15 years.... crap now I feel old.
[23:47] <jjohansen> psusi: it started long before win95, and yes its unbelievable that this isn't handled well still