[09:05] <jk-> eep, first victim of yama/ptrace_scope changes: wine will no longer run Rosetta Stone
[09:09] <jk-> .. not that it ran that well in the first place, but would indicate that wine uses ptrace() on non-child processes
[09:11] <jjohansen> jk-: you can turn yama off
[09:11] <jk-> yep
[09:35] <amitk> cooloney: did you look at the patches that Tony posted on linux-omap for SMP kernel on UP?
[09:36] <amitk> I asked him to post patches so you or someone else can test it
[09:36] <cooloney> amitk: yeah, man
[09:36] <cooloney> amitk: i tested rmk's version 
[09:36] <cooloney> and tony posted a fixing just now
[09:36] <cooloney> i am going to testing that on my board
[09:37] <amitk> cool
[09:37] <cooloney> amitk: so we a close to boot smp kernel on beagle, i think.
[09:37] <amitk> cooloney: hopefully :)
[09:38] <cooloney> amitk: but the patch changes several important low level assemble line code. 
[09:38] <cooloney> need more testing and review
[09:38] <amitk> cooloney: Tony said that he doesn't think we need to rewrite locking primitives during runtime like is done on x86
[09:40] <cooloney> amitk: no sure about that. spin_lock version is different in smp and up, i think.
[16:29] <sconklin> not traffic shaping, just saturatign my uplink
[16:29] <sconklin> the tests that failed were obviously ones that were not for ext4, but were not correctly excluded from the tests
[16:31] <smb> Hm, ok. I think I had at least one about aio but those failed before and after.
[16:31]  * smb goes to reboot the test machine
[17:04] <JFo> is the -rt kernel being added to main that anyone knows of?
[17:05] <JFo> rather -lowlatency and -preempt
[17:05] <JFo> I am being asked about them
[17:06] <JFo> apw or tgardner ^^?
[17:07] <tgardner> JFo, preempt is an official flavour for Lucid, not for Maverick
[17:07] <JFo> ah, I see
[17:08] <JFo> anything for the -lowlatency?
[17:08] <tgardner> JFo, not in maverick
[17:08] <tgardner> nor lucid
[17:08] <JFo> tgardner, thank you
[17:09] <JFo> tgardner, is there any rationale for not including them?
[17:09] <JFo> I have been asked that specifically
[17:10] <tgardner> the -rt guys are providing a kernel AFAIK, so it was duplicated functionality.
[17:10] <JFo> cool, thanks again tgardner 
[20:44] <sabdfl> ps ax is hanging over here, known issue? kernel or elsewhere?
[20:45] <sabdfl> fwiw it gets to  1751 ?        S      0:00 udisks-daemon: polling /dev/sr0
[20:46] <kees> sabdfl: what does "strace ps ax" show it's stuck on?
[20:47] <sabdfl> read(6, "Name:\tchromium-browse\nState:\tD ("..., 1023) = 786
[20:47] <sabdfl> close(6)                                = 0
[20:47] <sabdfl> open("/proc/1898/cmdline", O_RDONLY)    = 6
[20:47] <sabdfl> read(6, 
[20:47] <kees> ew
[20:47] <tgardner> sabdfl, maverick?
[20:47] <sabdfl> tgardner: very :-)
[20:48] <tgardner> cat /proc/version_signature
[20:49] <sabdfl> Ubuntu 2.6.35-16.22-generic 2.6.35.2
[20:49] <sabdfl>  ~/ $ ls /lib/modules/2.6.35-16-generic/updates/dkms 
[20:49] <sabdfl> hid.ko	hid-magicmouse.ko  vboxdrv.ko  vboxnetadp.ko  vboxnetflt.ko
[20:50] <tgardner> sabdfl, lots of stable fixes since then. I hate to give you the runaround, but can you install just the -proposed kernel and try again?
[20:50] <sabdfl> sure, url?
[20:50] <tgardner> one sec
[20:50] <sabdfl> didn't realise we had -proposed on maverick
[20:51] <tgardner> sabdfl, doh, I was thinking Lucid. never mind.
[20:51] <sabdfl> :-)
[20:51] <sabdfl> i think about lucid often, too :-) best release EVAR
[20:51] <tgardner> though we do have stable updates in the pipe for Maverick
[20:51] <sabdfl> how's .35 treating us?
[20:52] <tgardner> not too bad, but there is a known mm regression in the version you are running. I wonder if thats it
[20:53] <tgardner> ogasawara should be releasing an update with a couple of days
[20:53] <kees> is it always chromium it blocks on, or is it at random?
[20:54] <tgardner> kees, 'mm: fix page table unmap for stack guard page properly' is what I suspect
[20:55] <kees> tgardner: what sha is that?
[20:55] <kees> tgardner: I think we have it in the -security kernels, but I wanted to double-check
[20:55] <tgardner> in the maverick repo its 6106dafae6d0ff50c82bb544b3b999562238504b
[20:56] <mjg59> sabdfl: While hung, writing W to /proc/sysrq-trigger should give you the in-kernel backtrace for the blocked task
[20:57] <tgardner> sabdfl, you could also reboot to Ubuntu-2.6.35-14.20. Thats based on 2.6.35 _before_ any stable updates (which actually destabilized things a bit)
[20:57] <kees> yup
[20:57] <sabdfl> mjg59: hello there! nice to see you again
[20:58] <sabdfl> so, echo W > /proc/sysrq-trigger ?
[20:58] <mjg59> Yeah, as root
[20:58] <tgardner> echo W | sudo tee /proc/sysrq-trigger
[20:58] <sabdfl> tgardner: still have it around, iirc, so yes can roll back
[20:59] <tgardner> sabdfl, remember you have to hold the shift key just prior to grub getting control or you'lll miss the grub menu
[20:59] <sabdfl> so, that's put stuff in dmesg?
[20:59] <mjg59> Yup
[21:00] <sabdfl> lots of blech at http://pastebin.ubuntu.com/480605/
[21:01] <mjg59> sabdfl: Hm. Sure you did w? And ps is still blocked in read?
[21:01] <tgardner> mjg59, anon_vma_prepare, wasn't this what Linus was seeing?
[21:02] <mjg59> Yeah, looks like something's very unhappy there
[21:03]  * jjohansen -> lunch
[21:03] <tgardner> I'm pretty sure thats the stack guard regression
[21:04] <sabdfl> mjg59: just tried again, ps ax in one terminal tab, and the echo W magic in another
[21:05] <sabdfl> ps doesn't get unblocked
[21:05] <mjg59> Yeah, ps is pretty solidly dead at that point
[21:05] <mjg59> One of those scheduling while atomic errors probably left a lock held
[21:08] <tgardner> sabdfl, I think your best bet for now is to use the older kernel until ogasawara get the next stable update uploaded.
[21:08] <sabdfl> okdokey
[21:08] <ogasawara> sabdfl: hoping to upload this afternoon actually.  just have a few more patches I wanted to review and possibly apply.
[21:09] <sabdfl> other than the vbox bits, which i am not using so doubt they are active, i'm on standard bits with dell m1330
[21:09] <sabdfl> so i wouldn't be surprised if others see the same thing
[21:09] <sabdfl> thanks leanne
[21:10] <ogasawara> sabdfl: I think I've got a test kernel with a fix for that bug 480605, just a sec
[21:10] <ubot2> Launchpad bug 480605 in telepathy-haze (Ubuntu) (and 2 other projects) "Repeated subscription request from same user (affects: 12) (dups: 2) (heat: 78)" [Medium,Triaged] https://launchpad.net/bugs/480605
[21:11] <ogasawara> bah, not bug, the pastebin
[21:11] <sabdfl> ok, will let you guys know if the next update fixes it
[21:11] <ogasawara> sabdfl: bug 618846, http://people.canonical.com/~ogasawara/lp618846/
[21:11] <ubot2> Launchpad bug 618846 in linux (Ubuntu) "Kernel 2.6.35.2 reports "scheduling while atomic" (affects: 1) (heat: 6)" [Medium,Fix committed] https://launchpad.net/bugs/618846
[21:13] <sabdfl> will reboot to prior kernel. thanks for the help, hope the report was helpful, nice to see you mjg59
[21:28]  * ogasawara drops to grab lunch, back in an hour
[22:03] <joshhunt> can someone provide a pointer to the differences between ubuntu server kernel and desktop kernel? i have found this: https://help.ubuntu.com/10.04/serverguide/C/preparing-to-install.html but was wondering if there are any other differences
[22:06] <tgardner> joshhunt, there are no source code differences. the only differences are in some of the config options.
[22:07] <joshhunt> tgardner, ok thanks. that's what i suspected, but wasn't sure.
[22:09] <joshhunt> tgardner, is there a place where i can download the kernels manually. instead of going through apt, etc?
[22:45] <kees> joshhunt: I tend to do it through Launchpad. https://edge.launchpad.net/ubuntu/+source/linux