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