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