[00:11] <rtg> zul: I'm still having problems with xen x86. x86_64 build OK. The reason is that slow_down_io() in include/asm-x86/mach-xen/asm/io_32.h uses xen_io_delay() which is not correctly exported, or at least fails to link into vmlinuz.
[00:38] <rtg> zul: ok, I fixed the xen 32 bit build with a gross hack on the xen patch files to have it call native_io_delay (like x86_64) instead of xen_io_delay. Feel free to send an update, but now it at least builds.
[08:57] <jiraia> hi
[08:57] <jiraia> someone knows how intercept syscall with kernel 2.6 ?
[09:23] <cking> jiraia: hi, perhaps looking at how strace does it is worth a try 
[10:17] <kraut> moin
[12:41] <abogani> Bug #177895
[12:42] <ubotu> Launchpad bug 177895 in linux "Kernel 2.6.24-2 causing ~1000 wakeups by "Rescheduling Interrupts"" [Medium,In progress] https://launchpad.net/bugs/177895
[13:34] <BenC> Good morning folks
[13:47] <rtg> tjaalton: did you notice I uploaded a -14 kernel ?
[14:38] <tjaalton> rtg: yes, so lrm is ready to go?
[14:38] <tjaalton> I've enabled ltmodem again, gentoo had a small patch to make it compile against .24
[14:39] <rtg> tjaalton: well, the kernel built for all arches. I'll bug an archive admin to ACCEPT it.
[14:40] <tjaalton> and, made nvidia-glx* to depend 'lrm-VER-generic | nvidia-kernel-VER' instead of just the latter, because it's against policy to depend only on a virtual package and it's possible to get a wrong flavor kernel on upgrade
[14:40] <tjaalton> like I get a -386 every time, and that doesn't even boot
[14:44] <rtg> tjaalton: looks like the kernel has already been accepted into the archive. I just misread the state.
[14:44] <tjaalton> rtg: cool, I'll do a test build and upload
[14:44] <rtg> tjaalton: did you add openvz? I'm working on lum/lbm.
[14:45] <tjaalton> hmm nope
[14:45] <rtg> tjaalton: I'm wondering why you get a -386 kernel? Something wrong with meta still?
[14:46] <tjaalton> no it's just apt trying to figure out what package to get to fulfill the dependancy, and uses the first in alphabetical order
[14:47] <tjaalton> see bug 188287
[14:47] <ubotu> Launchpad bug 188287 in linux-restricted-modules-2.6.24 "dependencies installs -386 kernel which hangs on boot" [Undecided,In progress] https://launchpad.net/bugs/188287
[14:49] <rtg> tjaalton: are you whom marked it 'In Progress' ? You should assign yourself to the bug if so.
[14:50] <tjaalton> rtg: yep, done
[14:51] <rtg> tjaalton: thanks
[14:56] <tjaalton> rtg: is -openvz needed for lrm? there's no -virtual either
[14:56] <tjaalton> and rightly so :)
[14:59] <rtg> tjaalton: hmm, you are probably correct. Doesn't really make sense :)
[15:00] <rtg> just like there is no xen version, right?
[15:02] <tjaalton> xen is different, since you run dom0 on real hw
[15:02] <tjaalton> but, it's not there.. hmm
[15:02] <tjaalton> I know that it nvidia_new doesn't build for it, but
[15:03] <tjaalton> -it
[15:05] <tjaalton> hmm, there _is_ lrm for xen
[15:08] <rtg> tjaalton: right, I forget about dom0 (cause I never use xen). But, I don't think openvz/virtual is needed for LRM.
[15:14] <BenC> rtg, smb, amitk, cking: http://iso.qa.ubuntu.com/qatracker/subscriptions to track what ISO testing you will be expected to do
[15:15] <BenC> rtg: virtual may need to be
[15:15] <BenC> rtg: openevz maybe as well. A lot of the server tools (which can be used for dom0) are GUI
[15:15] <BenC> rtg: *openvz ... anyway, if it compiles, might as well build it
[15:17] <smb> BenC: Hm, I see the list but I am not sure I know how to interpret it...
[15:17] <rtg> tjaalton: ^^
[15:19] <cking> BenC: any instructions on what to do?
[15:19] <tjaalton> BenC: is openvz comparable to xen in this regard? -virtual isn't :)
[15:21] <BenC> tjaalton: yes
[15:21] <BenC> tjaalton: actually, you are right, we don't need lrm for -virtual
[15:22] <BenC> but openvz is bare-metal and virtualized, so needs it
[15:22] <BenC> (like xen)
[15:22] <tjaalton> ok, I'll add it
[15:36] <tjaalton> openvz is for amd64/i386?
[15:40] <rtg> tjaalton: yep
[15:42] <tjaalton> ok, let's see if it builds..
[15:42] <tjaalton> ..all the modules
[15:54] <tjaalton> wow, it did
[16:18] <tjaalton> hmh, the build failed on 32bit which I need to look at more closely later this evening..
[16:18] <tjaalton> in 4h or so
[16:18] <rtg> tjaalton: I've upload lum/lbm. I'll do met in awhile.
[16:19] <rtg> s/met/meta/
[17:45] <rtg> tjaalton: I stuck you on Bug #122703 in case the madwifi 0.9.4 update supports AR5008.
[17:45] <ubotu> Launchpad bug 122703 in linux-restricted-modules-2.6.24 "Upgrade Atheros drivers to snapshot/trunk to support AR5008" [Low,In progress] https://launchpad.net/bugs/122703
[19:08] <rtg> zul: did you review the xen fixes I hacked in yesterday?
[19:39] <zul> rtg: sorry was on a call no I havent
[19:40] <rtg> zul: please have a look and make sure I've have not totally screwed the pooch.
[19:40] <rtg> zul: you should probably produce a better fix then what I've done.
[19:40] <zul> yeah, looks ok to me
[20:00] <blueyed> Does it make sense to provide virtualbox modules for Xen and OpenVZ kernels? IMHO yes, but I may be wrong. There are some for -virtual already.
[20:01] <zul> blueyed: no it doesnt for xen 
[20:01] <blueyed> zul: but you could run virtualbox inside of xen, can't you?
[20:02] <zul> blueyed: maybe but if you are running xen then you want to run xen
[20:03] <blueyed> zul: yes, I see. I don't say that it's a common use case, but I can see it. E.g. a bigiron server running Xen machines and virtualbox, too.
[20:04] <zul> its overkill IMHO
[20:58] <Solarion>  7285 solarion  20   0  220m  41m  15m D  100  4.1 163:07.83 totem              
[20:59] <Solarion> cat /proc/7285/mem says "No such process"
[20:59] <Solarion> how does this make any sense?
[20:59] <BenC> Solarion: what doesn't make sense?
[20:59] <Solarion> it's sleeping but eating 100% cpu
[21:00] <Solarion> mem says no such process
[21:00] <BenC> sounds like a kernel bug or similar
[21:00] <Solarion> that would be why I'm here
[21:00] <Solarion> I want it dead.  :)
[21:00] <BenC> reboot
[21:00] <Solarion> don't want to figure out the kernel bug with me?
[21:00] <Solarion> I hate rebooting
[21:01] <BenC> check dmesg
[21:01] <BenC> but to get rid of it, you have to reboot
[21:01] <Solarion> dmesg says nothing
[21:01] <Solarion> ah, D is "disk sleep"
[21:02] <BenC> I thought you knew that...the D is IO wait, basically
[21:02] <Solarion> I didn't, but I'm figuring it out as I go along
[21:02] <Solarion> the question is what is the kernel spinning on
[21:02] <BenC> block device reads most likely (especially if it's playing as cdrom or something)
[21:03] <BenC> cat /proc/7285/wchan
[21:03] <Solarion> 0
[21:05] <Solarion> what is wchan?
[21:05] <BenC> hmm...wchan doesn't seem to be producing useful info anymore
[21:06] <Solarion> io isn't budging
[21:06] <Solarion> (watch cat io)
[21:07] <BenC> wchan is the function where the process is sleeping in the kernel
[21:07] <BenC> Solarion: well, not much info to go on...I'd say reboot is your only option at this point
[21:08] <Solarion> I want to know what happened tho
[21:08] <Solarion> so it doesn't happen again
[21:08] <BenC> So far, there's no way to see that
[21:08] <BenC> you could try "strace -p 7285", but I suspect strace will lock up as well
[21:08] <Solarion> it does
[21:08] <Solarion> can you reset the ulimits?
[21:08] <BenC> ulimits have nothing to do with it
[21:08] <Solarion> e.g. make max open files 1 or something ridiculous?
[21:09] <Solarion> part of it is trying to figure out how to kill it creatively. :)
[21:09] <BenC> you can't
[21:09] <Solarion> rebooting has no panache
[21:09] <BenC> you cannot kill a 'D' state process
[21:09] <BenC> it's stuck, and you have no choice but to reboot
[21:09] <Solarion> and there's no way of figuring out where it's stuck and why?
[21:10] <BenC> I've exhausted the known ways of figuring that out
[21:10] <Solarion> stupid horked thing
[21:13] <Solarion> wonder what totem is doing with xulrunner
[21:13] <Solarion> totem   7285 solarion   44u  sock        0,4           1464374 can't identify protocol
[21:13] <Solarion> what is that (lsof output)?
[21:28] <tjaalton> rtg: seems like it's not in 0.9.4
[21:29] <rtg> tjaalton: bummer.. then new AR5008 users are screwed for now.
[21:29] <tjaalton> rtg: yeah
[21:56] <infinity> rtg: Is there a new LRM on the way..?
[21:57] <rtg> tjaalton: ^^
[21:57] <infinity> rtg: Updating -meta without updating LRM seems suboptimal. :)
[21:58] <rtg> infinity: it shakes out eventually, doesn't it?
[21:58] <infinity> rtg: Err, no...
[21:58] <infinity> rtg: If you update meta first, kernels get upgraded without LRM.
[21:58] <infinity> rtg: "linux-image-generic" gets upgraded, pulls in the new kernel, while "linux-generic" and "linux-restricted-modules-generic" get held back.
[21:59] <infinity> rtg: So, boom, anyone not paying attention will reboot and have no network, video, whatever.
[22:00] <rtg> infinity: my bad. I must not have any boxes using LRM or I would have noticed.
[22:00] <infinity> rtg: Well, yes, it's my own fault for using evil binary blobs, but I suspect I'm not alone. ;)
[22:00] <rtg> infinity: probably not.
[22:01] <infinity> Anyhow, if LRM doesn't have a mess of pending changes, you could just do the ABI bump and upload to keep me happy. :)
[22:01] <infinity> (If it does, you could still do the ABI bump, then followup with another upload later)
[22:01] <tjaalton> infinity: I'm still figuring out why 32bit build fails now
[22:02] <tjaalton> the -server flavour
[22:02] <infinity> tjaalton: Oh, ick.
[22:02] <infinity> tjaalton: Which module?
[22:02] <tjaalton> nv.c:14:
[22:02] <tjaalton> include/xen/interface/memory.h: At top level:
[22:02] <tjaalton> include/xen/interface/memory.h:32: error: expected specifier-qualifier-list before 'GUEST_HANDLE'
[22:02] <tjaalton> that's nv-new
[22:02] <infinity> tjaalton: The most obvious question here is "why are we building nv stuff for -server at all?"
[22:02] <infinity> I'm pretty sure I didn't back when I maintained it..
[22:03] <rtg> infinity: a surprising number of folks run the -server flavor on their desktop
[22:03] <tjaalton> infinity: because someone want's to use vast amounts of memory on a workstation
[22:03] <infinity> rtg: Which is, I suppose, their problem, not ours. ;)
[22:03] <infinity> tjaalton: Define "vast"...
[22:03] <tjaalton> 16gig?
[22:03] <rtg> infinity: oh, I think some of the use is legitimate. 
[22:05] <infinity> See, 16GB doesn't sound that excessive to me anymore.
[22:05] <infinity> What's the -generic kernel currently top out at?  (My laptop only has 4GB, which works fine, so I'm not sure)
[22:06] <tjaalton> mine too has 4Gb
[22:06] <tjaalton> GB even
[22:06] <tjaalton> anyway, 64bit build works fine
[22:06] <tjaalton> something has changed in the headers?
[22:07] <infinity> I'd guess.
[22:07] <infinity> Time to get to bisecting? :/
[22:11] <tjaalton> well tbh it's not the latest headers it's using, but the first -13 upload
[22:11] <tjaalton> I'll update the mirror
[22:12] <rtg> tjaalton: the big change with server was CGROUPS, which seems to have fundamental effect on some low level macro. 
[22:13] <tjaalton> oh, I'm still building -13 :P
[22:13] <rtg> tjaalton: there were about a zillion ABI changes which is what forced the ABI update.
[22:13] <rtg> tjaalton: you definitely need -14 headers.
[22:13] <tjaalton> hah, time to bump the abi again
[22:13] <tjaalton> yep..
[22:13] <rtg> tjaalton: ok, I'm outta here for awhile. I'll check back in a few hours.
[22:14] <tjaalton> rtg: ok, hopefully this works by then
[22:15] <tjaalton> infinity: btw, check bug 188287 and the proposed solution (included in the lrm I'm testing). anything alarming you see?
[22:15] <ubotu> Launchpad bug 188287 in linux-restricted-modules-2.6.24 "dependencies installs -386 kernel which hangs on boot" [Undecided,In progress] https://launchpad.net/bugs/188287
[22:19] <tjaalton> hm, still no -14
[22:21] <tjaalton> ..but now
[22:24] <infinity> tjaalton: Well, "pure virtuals" violate policy, but in this case, it's hard to define a "preferred package", which is why it's always been this way...
[22:25] <infinity> tjaalton: (For the record, this bug has existed for 3+ years)
[22:25] <tjaalton> infinity: a tough one
[22:25] <infinity> tjaalton: And only triggers during development cycles, generally, since we don't often update the nvidia drivers in released dists.
[22:25] <infinity> (so, nvidia-kernel-$ver doesn't bump)
[22:26] <tjaalton> infinity: but it does bump for dist-upgrades
[22:26] <infinity> tjaalton: Yeah, true.  But the dist-upgrader can be taught to cope with that.
[22:26] <infinity> tjaalton: And we don't technically support people doing raw apt-get dist-upgrades.
[22:27] <infinity> (We support packages not being absolutely broken, but we don't support people blindly telling apt "yeah, your package selection looks sane, I totally want 3 new kernels, and a removed openoffice!")
[22:28] <tjaalton> infinity: I've also seen it doing a fresh install by preseeding the package list with nvidia-glx on it, but it doesn't always do that
[22:30] <infinity> tjaalton: Yeah, if you ask apt to install "nvidia-glx linux-generic", it will install "nvidia-glx, lrm-386, linux-generic", because of its brain-dead dep resolution policy.
[22:30] <infinity> It goes for "fastest loop unrolling" rather than "path of least possible system change" (which, say, dselect does)
[22:31] <infinity> tjaalton: The problem with the proposed solution is that it just shifts the bug to all the other kernel:nvidia combinations, while appearing to "fix" it for generic.
[22:32] <infinity> tjaalton: Given our general preference for generic, that may be a win, just pointing out that it's no more correct. ;)
[22:32] <tjaalton> infinity: anyway, I'll drop the change for now, since it needs further discussion
[22:34] <infinity> tjaalton: Given that one can never guarantee a kernel interface is there (because, y'know, the user might not reboot before hitting Ctrl-Alt-Backspace and blowing up X), I've often wondered if dropping the dep entirely, or even just lowering it to a Recommends, might not be out of line.
[22:34] <infinity> tjaalton: userspace:kernel dependencies are much harder to enforce than kernel:kernel or userspace:userspace, since we have no control over which grub option they select on boot.
[22:35] <tjaalton> hmm.. true
[22:36] <infinity> tjaalton: One will note that the fglrx packages have no such painful userspace:kernel dep.
[22:36] <tjaalton> infinity: because there's only one version?
[22:36] <infinity> tjaalton: No, the driver->kernel dep is OLD... Predates the multiple version thing.
[22:37] <infinity> tjaalton: It's just inherited from the Debian nvidia packaging.
[22:37] <tjaalton> oh
[22:37] <infinity> tjaalton: The multiple version thing is a red herring, since the LRM packages provide all 3 kernel modules.
[22:38] <tjaalton> yep
[22:38] <infinity> tjaalton: But, yeah, in every release cycle, I see maybe one complaint about fglrx lacking a kernel dep, and dozens of complaints about the nvidia kernel dep being broken.
[22:39] <infinity> tjaalton: Given that fantastic bit of statistical analysis, I'd say the fglrx situation is "less broken".
[22:39] <tjaalton> infinity: hehe :)
[23:37] <tjaalton> now it builds, the xen patch messed things up
[23:44] <infinity> tjaalton: Is "it builds" code for "I'm uploading it"? :)
[23:45] <tjaalton> infinity: you bet :)
[23:48] <tjaalton> infinity: I dropped the nvidia-kernel* dependencies
[23:49] <infinity> \o/
[23:57] <tjaalton> ok, uploading..