| 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:11 |
|---|---|---|
| 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. | 00:38 |
| === kraut_ is now known as kraut | ||
| === \sh_away is now known as \sh | ||
| jiraia | hi | 08:57 |
| jiraia | someone knows how intercept syscall with kernel 2.6 ? | 08:57 |
| cking | jiraia: hi, perhaps looking at how strace does it is worth a try | 09:23 |
| kraut | moin | 10:17 |
| === asac_ is now known as asac | ||
| abogani | Bug #177895 | 12:41 |
| 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 | 12:42 |
| BenC | Good morning folks | 13:34 |
| rtg | tjaalton: did you notice I uploaded a -14 kernel ? | 13:47 |
| === \sh is now known as \sh_away | ||
| === \sh_away is now known as \sh | ||
| === cradek_ is now known as cradek | ||
| 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:38 |
| rtg | tjaalton: well, the kernel built for all arches. I'll bug an archive admin to ACCEPT it. | 14:39 |
| 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:40 |
| 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:44 |
| tjaalton | hmm nope | 14:45 |
| rtg | tjaalton: I'm wondering why you get a -386 kernel? Something wrong with meta still? | 14:45 |
| 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:46 |
| 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:47 |
| rtg | tjaalton: are you whom marked it 'In Progress' ? You should assign yourself to the bug if so. | 14:49 |
| tjaalton | rtg: yep, done | 14:50 |
| rtg | tjaalton: thanks | 14:51 |
| tjaalton | rtg: is -openvz needed for lrm? there's no -virtual either | 14:56 |
| tjaalton | and rightly so :) | 14:56 |
| rtg | tjaalton: hmm, you are probably correct. Doesn't really make sense :) | 14:59 |
| rtg | just like there is no xen version, right? | 15:00 |
| 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:02 |
| tjaalton | -it | 15:03 |
| tjaalton | hmm, there _is_ lrm for xen | 15:05 |
| rtg | tjaalton: right, I forget about dom0 (cause I never use xen). But, I don't think openvz/virtual is needed for LRM. | 15:08 |
| BenC | rtg, smb, amitk, cking: http://iso.qa.ubuntu.com/qatracker/subscriptions to track what ISO testing you will be expected to do | 15:14 |
| 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:15 |
| smb | BenC: Hm, I see the list but I am not sure I know how to interpret it... | 15:17 |
| rtg | tjaalton: ^^ | 15:17 |
| cking | BenC: any instructions on what to do? | 15:19 |
| tjaalton | BenC: is openvz comparable to xen in this regard? -virtual isn't :) | 15:19 |
| BenC | tjaalton: yes | 15:21 |
| BenC | tjaalton: actually, you are right, we don't need lrm for -virtual | 15:21 |
| 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:22 |
| tjaalton | openvz is for amd64/i386? | 15:36 |
| rtg | tjaalton: yep | 15:40 |
| tjaalton | ok, let's see if it builds.. | 15:42 |
| tjaalton | ..all the modules | 15:42 |
| tjaalton | wow, it did | 15:54 |
| 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:18 |
| rtg | s/met/meta/ | 16:19 |
| 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 | 17:45 |
| === \sh is now known as \sh_away | ||
| === thegodfather is now known as fabbione | ||
| rtg | zul: did you review the xen fixes I hacked in yesterday? | 19:08 |
| === Jay-laptop_ is now known as Jay-laptop | ||
| zul | rtg: sorry was on a call no I havent | 19:39 |
| 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 | 19:40 |
| 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:00 |
| zul | blueyed: no it doesnt for xen | 20:01 |
| blueyed | zul: but you could run virtualbox inside of xen, can't you? | 20:01 |
| zul | blueyed: maybe but if you are running xen then you want to run xen | 20:02 |
| 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:03 |
| zul | its overkill IMHO | 20:04 |
| Solarion | 7285 solarion 20 0 220m 41m 15m D 100 4.1 163:07.83 totem | 20:58 |
| 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 | 20:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| BenC | cat /proc/7285/wchan | 21:03 |
| Solarion | 0 | 21:03 |
| Solarion | what is wchan? | 21:05 |
| BenC | hmm...wchan doesn't seem to be producing useful info anymore | 21:05 |
| Solarion | io isn't budging | 21:06 |
| Solarion | (watch cat io) | 21:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| BenC | I've exhausted the known ways of figuring that out | 21:10 |
| Solarion | stupid horked thing | 21:10 |
| 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:13 |
| tjaalton | rtg: seems like it's not in 0.9.4 | 21:28 |
| rtg | tjaalton: bummer.. then new AR5008 users are screwed for now. | 21:29 |
| tjaalton | rtg: yeah | 21:29 |
| infinity | rtg: Is there a new LRM on the way..? | 21:56 |
| rtg | tjaalton: ^^ | 21:57 |
| infinity | rtg: Updating -meta without updating LRM seems suboptimal. :) | 21:57 |
| 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:58 |
| infinity | rtg: So, boom, anyone not paying attention will reboot and have no network, video, whatever. | 21:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:05 |
| 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:06 |
| infinity | I'd guess. | 22:07 |
| infinity | Time to get to bisecting? :/ | 22:07 |
| 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:11 |
| rtg | tjaalton: the big change with server was CGROUPS, which seems to have fundamental effect on some low level macro. | 22:12 |
| 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:13 |
| tjaalton | rtg: ok, hopefully this works by then | 22:14 |
| 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:15 |
| tjaalton | hm, still no -14 | 22:19 |
| tjaalton | ..but now | 22:21 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:34 |
| tjaalton | hmm.. true | 22:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| infinity | tjaalton: Given that fantastic bit of statistical analysis, I'd say the fglrx situation is "less broken". | 22:39 |
| tjaalton | infinity: hehe :) | 22:39 |
| === smb_tp is now known as smb_away | ||
| tjaalton | now it builds, the xen patch messed things up | 23:37 |
| infinity | tjaalton: Is "it builds" code for "I'm uploading it"? :) | 23:44 |
| tjaalton | infinity: you bet :) | 23:45 |
| tjaalton | infinity: I dropped the nvidia-kernel* dependencies | 23:48 |
| infinity | \o/ | 23:49 |
| tjaalton | ok, uploading.. | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!