| 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:16 |
| 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:17 |
| junior_payne | it's not drive specific either. happens on both optical drives. | 01:18 |
| 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:19 |
| TheMuso | /c/c | 01:21 |
| 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? | 09:57 |
| === asac_ is now known as asac | ||
| === foka__ is now known as foka | ||
| Keybuk | how do I "git pull", but only up to a certain commit? | 11:40 |
| soren | Do you have local changes? | 11:50 |
| soren | I.e. will the pull involve a merge? | 11:50 |
| soren | Keybuk: ^ | 11:51 |
| Keybuk | soren: no | 12:24 |
| Keybuk | git fetch | 12:36 |
| Keybuk | git reset --hard sha1 | 12:37 |
| Keybuk | seemed to work | 12:37 |
| 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:40 | |
| Keybuk | it's just as hard to do that in bzr | 12:46 |
| Keybuk | so I'm not complaining ;) | 12:46 |
| 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 | 13:30 |
| soren | Keybuk: Should we update all packages shipping udev rules to put them in /lib/udev/rules.d, then? | 14:05 |
| 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:07 |
| 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:08 |
| soren | Keybuk: Oh, the format changed? Are the changes listed somewhere? | 14:11 |
| Keybuk | NEWS file, as usual | 14:14 |
| 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:15 |
| * apw swears at the jaunty kernel | 14:18 | |
| apw | seems we have some nice little dri lockup in it | 14:18 |
| 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:20 |
| 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:22 |
| apw | i guess i'd better file a bug on it | 14:23 |
| soren | Keybuk: Yikes. All those "Removing obsolete conffile /etc/udev/rules.d/foo" are scary :) | 14:25 |
| 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:27 |
| Keybuk | soren: nope | 14:31 |
| soren | Keybuk: Ok. | 14:32 |
| * 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:33 |
| 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:35 |
| Keybuk | err, did I drop /sbin/vol_id? :P | 14:39 |
| Keybuk | that's probably a bug :p | 14:39 |
| soren | Oh. :) | 14:42 |
| cjwatson | rtg: right, but that's present in 8.10 which the reporter is using | 14:46 |
| rtg | cjwatson: how can you tell that he's using Intrepid? | 14:47 |
| soren | rtg: cjwatson just knows. | 14:48 |
| soren | He's like that. | 14:48 |
| 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:50 |
| * cjwatson accepts linux-backports-modules-2.6.28 binaries | 14:52 | |
| rtg | cjwatson: pata_sch is in d-i/pata_modules. would being a net boot have any affect? | 14:53 |
| 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) | 14:56 |
| 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:05 |
| 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:06 |
| rtg | what about the volume ID problem? I had to specify the root as a /dev | 15:09 |
| 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:11 |
| 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:12 |
| rtg | is there something in the initramfs that trigger UUID functionality? | 15:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| Keybuk | who did _THAT_ hack?! | 15:18 |
| mjg59 | The kernel, 15 years ago | 15:19 |
| Keybuk | eww | 15:19 |
| mjg59 | root=/dev/nfs was always supported | 15:19 |
| cking | rtg: "we just need to map it" - err.. surely not in the kernel? | 15:21 |
| * cking needs some strong coffee | 15:23 | |
| rtg | cking: where else? the kernel is the only thing up at that point, assuming no initramfs. | 15:24 |
| cking | rtg: ..grub? | 15:25 |
| 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:27 |
| apw | but the kernel is what makes up the notion of a uuid in the first place | 15:28 |
| 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:29 |
| rtg | cking: I agree. if you do it in grub 1, then you'll have to do it again for grub 2 | 15:34 |
| cking | rtg: is the "if you do it" a SMOP for me? :-) | 15:35 |
| rtg | cking: aren't you already busy? | 15:35 |
| 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:36 |
| cking | s/does a/has a/ | 15:38 |
| apw | very tricky all over | 15:41 |
| apw | why _is_ initramfs so damn slow | 15:41 |
| rtg | apw: thats rhetorical, right? | 15:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| apw | i am sure it was the 5 s boot guys at plumbers who said "half a second even if it is empty" | 15:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| apw | that is conflicting information from two sources | 15:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| soren | Keybuk: Ah, no, we can work around that. | 15:59 |
| Keybuk | soren: what problem? | 15:59 |
| 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:00 |
| 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:02 |
| Keybuk | it inherently has the hard dep because of the split out of watershed | 16:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| Keybuk | e4f65f4 | 16:07 |
| Keybuk | is what I built | 16:07 |
| apw | that should do most fof it | 16:08 |
| apw | i don't see lp in there | 16:08 |
| 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:09 |
| 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:21 |
| apw | i think legacy count was done | 16:29 |
| apw | interesting figures though | 16:33 |
| cking | Keybuk: excellent analysis. | 16:44 |
| Keybuk | apw: was done? | 16:46 |
| apw | -4 has the legacy count fixed in it right? i think you say that in your second one | 16:47 |
| Keybuk | yes | 16:47 |
| 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:55 |
| 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:57 |
| Keybuk | shouldn't really matter if they do | 16:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!