[01:16] does a kernel bug qualify as development discussion? [01:16] yes [01:16] (support for it, on the other hand, is a slippery slope) [01:17] getting buffer I/O errors and end_request errors on my dvd any ideas on what could cause it? it's a sata drive using the sata_nv module I belive. [01:17] example: [01:17] Jan 5 18:55:53 quantum kernel: [79454.205582] end_request: I/O error, dev sr0, sector 684956 [01:17] Jan 5 18:55:53 quantum kernel: [79454.205592] Buffer I/O error on device sr0, logical block 171239 [01:18] it's not drive specific either. happens on both optical drives. [01:19] I read other bug reports on similar cases but they were resolved and the workarounds didn't work for me. I was just wondering if there is some code I can look at to see if I could identify the problem. [01:21] /c/c [09:57] is there away to get SysRq on the console instead of syslog? (for case when syslog is dead) [09:57] or does it only work with serial console? === asac_ is now known as asac === foka__ is now known as foka [11:40] how do I "git pull", but only up to a certain commit? [11:50] Do you have local changes? [11:50] I.e. will the pull involve a merge? [11:51] Keybuk: ^ [12:24] soren: no [12:36] git fetch [12:37] git reset --hard sha1 [12:37] seemed to work [12:40] Exactly what I would have done. :) If I needed to merge local changes, I think I would have had to create a new branch, do the git-reset trick there, and merge from that. [12:40] * soren really finds git to be a hassle. [12:46] it's just as hard to do that in bzr [12:46] so I'm not complaining ;) [13:30] anyone feeling brave? [13:30] http://launchpadlibrarian.net/20947618/udev_136%7Egit%2B34ac42b-3_source.changes [13:30] udev 136 now in my PPA :p [14:05] Keybuk: Should we update all packages shipping udev rules to put them in /lib/udev/rules.d, then? [14:07] Guess so. [14:07] soren: I suspect it'd be easier to update dh_installudev [14:07] but yes, in general [14:07] since the rules file format has changed slightly, all packages at least need to be checked [14:07] they have changed the udev file format, what is with udev [14:08] Keybuk, ok i've got a patch to add modalias love for mmc [14:08] apw: Kay's POV is that only distributors ship udev [14:08] so it's better to make improvements and fix issues than retain backwards compatibility [14:11] Keybuk: Oh, the format changed? Are the changes listed somewhere? [14:14] NEWS file, as usual [14:15] the basic change is that things you probably tried to do before that didn't work now do [14:15] ie. NAME=="a*", NAME=="*b" is now valid [14:15] (previously it would only use one of those matches) [14:15] also NAME="foo" is no longer special cased to be non-overridable [14:18] * apw swears at the jaunty kernel [14:18] seems we have some nice little dri lockup in it [14:20] anyone have a clue which device in https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/314175 corresponds to the CD drive? [14:20] Malone bug 314175 in debian-installer "Fujitsu U820 Hard Disk not detected by the installer" [Undecided,New] [14:20] apw: all of the DRI stuff is back to being modules, right? [14:20] err, sorry - the hard disk I guess [14:20] I thought it must be 8086:811a, but that module is available in the 8.10 installer unless I'm completely on crack [14:22] rtg it was a module yes in the kernel i was testing against, 2.6.28-4 [14:22] i have booted it twice and twice had X lock up on me after about 10 mins [14:22] second time i got to login remote and found X sleeping and repeatedly trying to ioctl the dri deive [14:23] i guess i'd better file a bug on it [14:25] Keybuk: Yikes. All those "Removing obsolete conffile /etc/udev/rules.d/foo" are scary :) [14:27] cjwatson: that ID is served by pata_sch.c --> debian/config/i386/config:CONFIG_PATA_SCH=y [14:27] Keybuk: Do you have a list of stuff that needs to be fixed along with the udev update? [14:31] soren: nope [14:32] Keybuk: Ok. [14:33] * soren makes a list [14:33] anything with /etc/udev/rules.d in its contents [14:33] update-grub for instance, calls /sbin/vol_id, but that's gone now. [14:33] I somehow doubt it's alone. [14:35] Hmm... I suppose we could just (sort of) fix that now by pointing it at /lib/udev/vol_id, but its syntax (both output and arguments and such) is subject to change, isn't it? [14:39] err, did I drop /sbin/vol_id? :P [14:39] that's probably a bug :p [14:42] Oh. :) [14:46] rtg: right, but that's present in 8.10 which the reporter is using [14:47] cjwatson: how can you tell that he's using Intrepid? [14:48] rtg: cjwatson just knows. [14:48] He's like that. [14:50] rtg: he says at the top. "This is during a netboot over internet installation of intrepid." [14:50] ah, he says it in lower case :) [14:52] * cjwatson accepts linux-backports-modules-2.6.28 binaries [14:53] cjwatson: pata_sch is in d-i/pata_modules. would being a net boot have any affect? [14:56] pata-modules is fetched by the installer once the network is up [14:56] thats what I assumed. [14:56] it's not in the initrd but otherwise it should still work perfectly well for netboot (if this didn't work, netboot wouldn't recognise *any* hard disks) [15:05] rtg: it looks like changing to CONFIG_LEGACY_PTY_COUNT=0 alone gives us ~1.6s [15:05] Keybuk: is there a graceful way to disable initramfs? [15:06] rtg: don't put an initrd on the grub command line? [15:06] Keybuk: so, you just comment out the menu.lst entry? [15:06] rtg: yeah, or press "d" at the grub boot menu [15:09] what about the volume ID problem? I had to specify the root as a /dev [15:11] rtg: some insight on why root=UUID=xxxx does not work would be useful :-) [15:11] ..I was just thinking the same thing a moment ago [15:12] cking: thats kind of what I'm asking. why doesn't the kernel know the volume ID by the time it attempts to mount the root device. [15:13] is there something in the initramfs that trigger UUID functionality? [15:14] rtg: I just grabbed your no initramfs git tree and was going to put some debug in to see why it was failing [15:14] I don't think the kernel supports root=UUID= [15:15] cking: we're still building an initramfs, its just that there are fewer modules that go into it. [15:15] Keybuk: isn't that kind of a sticky problem? [15:15] Keybuk: This is what I find a mystery: cat /proc/cmdline [15:15] root=UUID=302714e7-5fcd-4db3-b0dd-c17d36bc7696 ro quiet splash [15:15] it's a SMOP [15:16] SMOP --> sticky problem [15:16] case $ROOT in [15:16] UUID=*) [15:16] ROOT="/dev/disk/by-uuid/${ROOT#UUID=}" [15:16] ;; [15:16] (from the initramfs init :p) [15:16] Ahah [15:17] No wonder why I could no see how the kernel was parsing this [15:17] cking: so the info is there, we just need to map it [15:17] ugh [15:17] /dev/nfs) [15:17] [ -z "${BOOT}" ] && BOOT=nfs [15:17] ;; [15:18] who did _THAT_ hack?! [15:19] The kernel, 15 years ago [15:19] eww [15:19] root=/dev/nfs was always supported [15:21] rtg: "we just need to map it" - err.. surely not in the kernel? [15:23] * cking needs some strong coffee [15:24] cking: where else? the kernel is the only thing up at that point, assuming no initramfs. [15:25] rtg: ..grub? [15:27] ..but that would be really perverse [15:27] cking: I guess. grub has to be able to read the root device in order to boot. [15:28] but the kernel is what makes up the notion of a uuid in the first place [15:29] apw: err. true, but grub can do the mapping for most file systems too - I kind of think it's better to do it in the kernel though [15:34] cking: I agree. if you do it in grub 1, then you'll have to do it again for grub 2 [15:35] rtg: is the "if you do it" a SMOP for me? :-) [15:35] cking: aren't you already busy? [15:36] actually it seems udev is responsible for the mapping, in userspace [15:36] rtg: ..always :-) [15:36] apw: but udev isn't up at that point [15:36] apw: yeah - the udev has a library that does a UUID mapping library which I coerced into grub [15:38] s/does a/has a/ [15:41] very tricky all over [15:41] why _is_ initramfs so damn slow [15:42] apw: thats rhetorical, right? [15:43] a bit of both, half a second just for an empty one is mad [15:43] I suppose it takes a bit for busybox to launch [15:43] define slow [15:44] half a second [15:44] what is half a second? [15:44] it was quoted at UDS as something we want to stop using if at all possible [15:44] where are you starting and stopping the clock? :) [15:44] because it has a half second overhead even if its emptry [15:45] sadly it wasn't me, thats why i am wondering why its such a problem [15:45] for me, the time between the first and last line of initramfs (as near as damnit, anyway) is ~3.6s [15:45] Keybuk: New udev drops me at a initramfs prompt. [15:45] and why is it 3.6s [15:45] Keybuk: I'm still trying to work out why. [15:45] soren: debug for me ;) [15:45] and more how much of that would need to be done after initramfs either way [15:45] apw: 70-80% of initramfs time is spent in udev [15:46] so we can ignore that right? [15:46] modprobe, bus scans, waiting for the root disk to show up, etc. [15:46] as we will have to run it in real root once we get there [15:46] if its not done already [15:46] right [15:46] so, the real question is how much is done in there which is pointless [15:47] i am sure it was the 5 s boot guys at plumbers who said "half a second even if it is empty" [15:48] Keybuk: Ah, got it. [15:48] soren: missing /sbin/vol_id? :p [15:48] Keybuk: You'd think so, wouldn't you? :) [15:48] No cigar. [15:49] oh [15:49] /usr/share/initramfs-tools/hooks/lvm2 does: [15:49] cp -p /etc/udev/rules.d/85-lvm2.rules ${DESTDIR}/etc/udev/rules.d [15:49] rtg, have you got a boot time comparison for booting without an initrd time wise? overall from bios to login? [15:49] At that point, there is no etc/udev/rules.d, so it's created. As a file. [15:49] Boom. [15:49] apw: just anecdotal from pitti [15:50] shaves approc 20 seconds [15:50] soren: ah :) [15:50] * apw worries about all the effort UUID in the kernel would be, if nothing would be saved [15:50] apw: I tried it today on a dell with an SSD, and saved ~8 seconds without initramfs [15:50] soren: that should be /lib/udev/rules.d of course [15:50] cking, and any idea why it saves 8s ? [15:50] apw: and thats without readahead [15:50] Keybuk: Well, yes. As a transition, the udev hook file should probable create the etc/udev/rules.d directory, though. [15:51] apw: less modules to load I suspect. [15:51] so you did more than add an initrd, you built extra things in? [15:51] thats all backwards, but you get my drift [15:51] Keybuk: Until we've fixed everything else to use /lib/udev/rules.d, this is going to blow up in our face, I think. [15:52] soren: I disagree [15:52] apw: I took rtg's kernel https://lists.ubuntu.com/archives/kernel-team/2009-January/003987.html [15:52] it's far easier to find the broken things if they break [15:52] otherwise they'll just break later when we remove the transition [15:52] apw: The BIOS is the major time waster now :-) [15:53] so thats comparing a stock to one with lots built in and no initrd [15:53] so its not really an apples with apples comparison [15:54] actually [15:54] interestingly [15:54] there's no discernible difference in the kernel start time between everything built-in and everything a module [15:55] that is conflicting information from two sources [15:56] you are free to replicate my test ;) [15:56] Keybuk: I don't see why we'd be more willing to break and fall apart in initramfs than outside of it. Once the system is running, udev deals fine with stuff in /etc/udev/rules.d. If anything, we should be more accepting in initramfs. Failure to boot is worse. [15:57] soren: VERY few things should be installing rules into the initramfs [15:57] those that are should definitely be fixed to use /lib anyway [15:57] you'll note that udev doesn't really install any rules itself anymore [15:58] Keybuk: YEs, I noticed. [15:58] apw: I suggest you try the experiment yourself.. it won't take long . [15:58] Keybuk: There is one problem, AFAICS, though. [15:59] Keybuk: Ah, no, we can work around that. [15:59] soren: what problem? [16:00] Keybuk: I was thinking that we'd need to make a hard, versioned dependency between lvm2 and udev, because older udev versions wouldn't work with rules in /lib/udev/rules.d, and lvm2 wouldn't allow me to boot until it's moved to lib/udev/rules.d, but I guess in the meantime we can just make lvm2 create the /etc/udev/rules.d directory in the initramfs. [16:02] actually, it will need a hard version anyway [16:02] it doesn't depend on udev at all, no? :p [16:02] which is a mistake [16:03] it inherently has the hard dep because of the split out of watershed [16:04] huh [16:04] cking, yeah will have to do that, its all very confusing [16:04] apw: ok, weird [16:04] Keybuk, ? [16:04] lsmod | wc -l [16:04] 67 [16:05] uname -r [16:05] 2.6.28-4-generic [16:05] that's a lot more things in lsmod than I expected! [16:05] 28-4 isn't an all builtin kernel, just a lot more built in [16:05] sound is likely half of it [16:06] yeah, but I'm sure we talked about more of this stuff being built-in [16:06] apw: I'd like to understand it myself as deep analysis always results in better understanding - maybe when I have a spare moment :-) [16:06] acpi_cpufreq [16:06] parport parport_pc lp [16:06] psmouse [16:06] etc. [16:06] yep i thought those made the cut [16:06] as my machine hangs running that one i've not spent much time looking at it [16:07] e4f65f4 [16:07] is what I built [16:08] that should do most fof it [16:08] i don't see lp in there [16:09] ok, well it doesn't look like I fluffed the build [16:09] yeah its much better than mine, i have 105 [16:09] (on an intrepid kernel) so something has improved [16:21] see my last two mails to kernel-team [16:21] https://lists.ubuntu.com/archives/kernel-team/2009-January/004023.html [16:21] https://lists.ubuntu.com/archives/kernel-team/2009-January/004024.html [16:29] i think legacy count was done [16:33] interesting figures though [16:44] Keybuk: excellent analysis. [16:46] apw: was done? [16:47] -4 has the legacy count fixed in it right? i think you say that in your second one [16:47] yes [16:55] Keybuk: what are you going to do in postinsts when files in /etc/udev/rules.d/ turn out to be modified? [16:55] cjwatson: leave them [16:57] oh yeah, same name overrides [16:57] as long as no bright spark changes their rule filename (e.g. number) at the same time ... [16:58] shouldn't really matter if they do