| smb_tp | soren, Not that one immediatly comes to me. Since that is remote, might it also be that there is no network? | 00:00 |
|---|---|---|
| soren | smb_tp: No, it never comes up. I've checked the logs afterwards (I can boot it up in a special rescue mode). | 00:04 |
| soren | Actually, I tried booting it with kvm from the special rescue mode, and I got a panic in create_proc_entry, IIRC. I really need that machine to be up, so I quickly pointed lilo at the old kernel and got it running again. | 00:06 |
| * soren considers giving 2.6.21 a chance | 00:06 | |
| soren | Er.. | 00:07 |
| soren | 2.6.24-21, of course. | 00:07 |
| * soren does that. It's late at night, anyway. | 00:07 | |
| smb_tp | soren, Ok, proc might be something to look. I scanned over the changes and did not catch something immediately | 00:07 |
| === RAOF_ is now known as RAOF | ||
| soren | smb_tp: No, 2.6.24-21 doesn't love me either. | 00:12 |
| smb_tp | soren, too bad. :( If you could find out where it hangs, later of course. For the moment you seem to be stuck with -17 | 00:13 |
| soren | smb_tp: http://people.ubuntu.com/~soren/bootfail.png | 00:18 |
| soren | smb_tp: Anything you want me to try before I go back to -17? | 00:19 |
| smb_tp | soren, no thanks. I take that and dig | 00:20 |
| soren | Lovely, thanks. | 00:20 |
| soren | Quite a novel use of kvm there :) | 00:22 |
| smb_tp | soren, yep. as long as the bug persists with virtual hw as well. hm, could it also create memory dumps... :) | 00:24 |
| soren | Sure, if that would be helpful. | 00:25 |
| soren | I can't imagine why it won't boot, though. It can't possibly be hardware related if it fails in kvm, too. | 00:25 |
| smb_tp | soren, Not immediatly but I could keep this in mind. Havn't used crash on x86 yet | 00:25 |
| smb_tp | soren, this atm function is defined in net/atm/clip.c so it sound a bit like something in network. but no change in that file, as far as I can see on a quick look | 00:27 |
| soren | I'm a bit afraid it might be an initramfs thing.. | 00:28 |
| smb_tp | soren, how that? | 00:28 |
| soren | Sorry, I was half talking about something else. The -17 kernel won't boot now, either. | 00:29 |
| smb_tp | soren, no prob with that. but that is really strange. | 00:31 |
| smb_tp | soren, the kernel parms have not changed? | 00:31 |
| soren | Ah, I'm being an idiot. | 00:33 |
| soren | I tried to use the kernel as my initramfs.. Typing is hard at this hour. | 00:33 |
| smb_tp | soren, interesting concept. :) but true its quite early for you... | 00:34 |
| * soren crosses fingeres | 00:34 | |
| soren | And I've got pingage. \o/ | 00:35 |
| smb_tp | soren, \o/ the old kernel or was that even a newer one? | 00:36 |
| soren | Oh, still the old kernel. | 00:37 |
| smb_tp | soren, ok, then I keep on looking. :) | 00:37 |
| soren | smb_tp: Which module had the atm_clip function? | 00:38 |
| smb_tp | soren, The atm net driver | 00:38 |
| smb_tp | soren, oh, rather atm protocol families... | 00:39 |
| soren | It's listed in System.map... Does that mean it's in the kernel image and not in a module? | 00:41 |
| soren | System.map-2.6.24-21-server:ffffffff80657170 t atm_clip_init | 00:41 |
| smb_tp | soren, afaik yes | 00:42 |
| smb_tp | soren, confirmed CONFIG_ATM_CLIP=y | 00:43 |
| soren | Yeah, just found that too | 00:44 |
| === asac_ is now known as asac | ||
| smb_tp | soren, The bad thing is that if git doesn't fool me there has been no single change in net/atm between -17 and -19 | 00:45 |
| soren | I agree. | 00:45 |
| smb_tp | soren, The strange thing is, this atm driver is built in, so why does it only crash for you... | 00:54 |
| soren | Yeah. It's quite weird. | 00:58 |
| soren | And I don't have atm hardware. | 00:58 |
| smb_tp | soren, That doesn't matter. If I read correctly its some protocol driver that gets always initialized. | 00:58 |
| soren | Ah, yes, that's probably true. | 00:59 |
| soren | smb_tp: If you can think of anything you think I should try, just shout. | 01:00 |
| smb_tp | soren, I'll do, but for the moment I am clueless. Maybe it would be good to postpone it till tomorrow. | 01:01 |
| smb_tp | soren, tomorrow for me, later for you... | 01:01 |
| soren | YEah. I'm on my way to bed, too. | 01:01 |
| soren | Er, no, tomorrow for me too. It's 2 AM here :) | 01:01 |
| smb_tp | so it is tomorrow :) | 01:02 |
| smb_tp | never mind | 01:02 |
| soren | Oh, right :) | 01:02 |
| smb_tp | good night then | 01:02 |
| soren | You too :) | 01:02 |
| smb_tp | thanks | 01:02 |
| smb_tp | :) | 01:02 |
| liquidbeef | Hello, I'm reading a book (LDD Linux Device Drivers) and I want to start doing some of the examples. In the book, it tells me to build my own kernel so that I can have the proper headers, but reading some other discussions, it tells me I just need the kernel headers package (check), how do I properly link to them? | 08:08 |
| soren | Do you guys have an opinion on dkms? I'm strongly considering switching kvm to use it in Intrepid, but I have no experience with it. | 13:08 |
| soren | Hi, guys. I was hoping you could help me out a bit.. I'm having the weirdest problem. | 13:14 |
| soren | I have a server that refuses to boot anything but 2.6.24-17-server. If I give it a newer kernel, it fails like this: http://people.ubuntu.com/~soren/bootfail.png | 13:14 |
| soren | (I got that screenshot by pointing kvm at the disks from a rescue system.) | 13:14 |
| soren | ...so it's not hardware related (since it happens in kvm, too). | 13:14 |
| soren | This works, though: kvm -kernel /mnt/boot/vmlinuz-2.6.24-19-server -initrd /mnt/boot/initrd.img-2.6.24-19-server -append "root=UUID=96c1a0f4-28af-4de4-a1f1-c9fe254545ed" -hda /dev/sda -hdb /dev/sdb | 13:15 |
| soren | So the kernel and initrd image is fine. | 13:15 |
| soren | And lilo manages to boot the -17 kernel just fine. | 13:15 |
| soren | ...so lilo is working, too. | 13:16 |
| soren | nothing changed in the atm code (see the reference in the backtrace) between -17 and -19. | 13:16 |
| amitk_ | soren: does kvm have external modules that need to be recompiled with every kernel? | 13:16 |
| soren | It breaks at the same place for both -21 and -19. | 13:16 |
| soren | amitk_: Yes. | 13:17 |
| amitk_ | soren: why? | 13:17 |
| rtg | soren: dkms is the preferred solution for ABI sensitive 3rd party kernel modules. | 13:17 |
| soren | amitk_: Well, the kernel ships some kvm modules, but half of a kvm release is kernel modules, so there are updates outside of the kernel. | 13:17 |
| amitk_ | soren: or rather, what are those modules and why are they external? | 13:17 |
| soren | amitk_: they're replacements for the kvm modules in the kernel. | 13:18 |
| soren | amitk_: It's mostly to avoid the pain of updating the modules in the kernel build, and since upstream provides them in a way that's easy to build out-of-tree, it makes sense to use it. | 13:18 |
| amitk_ | soren: I think this would be a wrong use of DKMS. But if the objective is to short-circuit the kernel upload dependency temporarily till kvm matures, then I guess DKMS is a good way to go about it. | 13:19 |
| amitk_ | IMHO, ofcourse :) | 13:19 |
| soren | amitk_: Why do you think it would be a wrong use of it? | 13:20 |
| amitk_ | soren: multiple sources of kernel modules (open source ones at that!), for one. In my mind DKMS is for modules that have no hope of being merged into the kernel (fglrx, nvidia), are open but alpha-grade right now. | 13:22 |
| soren | Each kvm release has a userspace and a kernel space part to it. This is hardly surprising, given kvm's nature. kvm's release schedule is not synced with linux's, so either we're stuck with whatever is in the kernel we're shipping, or I have to spend a day or two merging a new kvm release into our existing kernel tree every time there's a new kvm release. | 13:24 |
| soren | virtualbox has chosen a different approach. A week doesn't go by without someone filing a new bug with the problems that arise from that approach. | 13:25 |
| soren | dkms seems rather immune to this. | 13:25 |
| amitk_ | soren: Understood. Till kvm becomes 'feature complete' I guess it might be easier to just package it separately (using dkms). | 13:25 |
| soren | Granted, this is a smaller problem in Intrepid where IIUIC, you've redefined what constitutes an ABI bump, but if I had switched to dkms for hardy, my life would have been much, much easier. | 13:26 |
| soren | I can upload a kvm version that uses dkms and see how it fares. We still have a week before FF :) | 13:27 |
| amitk_ | soren: Go for it. | 13:27 |
| soren | Any clever input on my other problem (the boot failure mentioned above)? | 13:27 |
| amitk_ | soren: did I read correctly that networking is through ATM? | 13:28 |
| soren | No. | 13:29 |
| soren | There's no atm hardware at all. | 13:29 |
| smb_tp | The crash is just reported int the atm init code | 13:29 |
| soren | smb_tp: There more I think about this problem, the more confused I get. It makes very, very little sense. | 13:29 |
| smb_tp | This code should be run an all machines since the driver (some sort of protocol) is built into the kernel (not a module) | 13:30 |
| smb_tp | And suddenly (on this server) it crashesh when trying to create a proc entry | 13:30 |
| soren | ..but only when I use lilo to boot the kernel. | 13:31 |
| smb_tp | With grub it works? | 13:31 |
| amitk_ | soren: you changed from grub to lilo? | 13:31 |
| soren | I haven't tried with grub, but I'm quite reluctant to just throw away this setup before I've figured out what's wrong. | 13:31 |
| soren | amitk_: Always used lilo on that box. | 13:32 |
| soren | It boots from RAID1. | 13:32 |
| soren | smb_tp: I tried using kvm's own boot loader. | 13:32 |
| smb_tp | soren, Ah ok, and that did worked better? | 13:32 |
| soren | smb_tp: I can pass a kernel, initrd, and kernel command line to kvm, and then it boots that instead of using the on-disk boot loader. | 13:32 |
| soren | smb_tp: Yeah, that worked fine. So the kernel and initrd are both in good shape. | 13:33 |
| smb_tp | soren, very very odd. | 13:33 |
| soren | Hmm... | 13:34 |
| soren | I think I'll try grabbing the kernel and initrd and try booting it on my laptop with lilo.. | 13:34 |
| smb_tp | Might be something to try. And otherwise we might try to gather as much msg log from working and non-working cases as we can. And try to find differences in mem allocations/addresses... | 13:37 |
| smb_tp | soren: http://www.mail-archive.com/debian-bugs-closed@lists.debian.org/msg195980.html | 13:46 |
| smb_tp | soren, There is also some other place that mentions lilo option "large-memory" | 13:46 |
| soren | smb_tp: large-memory looks very interesting indeed.. | 13:55 |
| soren | smb_tp: Well, cover me with eggs and flour and bake me for forty minutes... It works! | 13:56 |
| soren | smb_tp: I owe you one! | 13:56 |
| smb_tp | soren, So it seems you need a lilo update... :) | 13:56 |
| smb_tp | Or hardy might... | 13:57 |
| soren | Yeah. | 13:58 |
| smb_tp | soren, I am not yet at the bottom of the report, but there seem to be a relation to the initramfs size... | 13:58 |
| soren | From -17 to -19 the initrd *just* squeezed over 8MB (8192*1024*1024 bytes) | 13:58 |
| soren | Er.. | 13:59 |
| soren | 8192*1024 bytes, I mean. | 13:59 |
| smb_tp | soren, :) We all get carried away by those giant nombers nowadays... | 14:00 |
| smb_tp | soren, Ok, bottom line seems it should be fixed in 1:22.8-5 | 14:00 |
| smb_tp | While fixed is relative: debian/liloconfig: Warn about large initrd images, as not | 14:01 |
| smb_tp | all systems can successfully boot when the 8MB barrier is reached, | 14:01 |
| smb_tp | it depends a lot on system BIOS and chipset configuration. | 14:01 |
| soren | -6 sets large-memory by default, it seems. | 14:01 |
| soren | Well, it puts "large-memory" into newly generated lilo.conf's by default. | 14:03 |
| smb_tp | Yes, that seems to be the only change there (beside of a new email address... | 14:03 |
| smb_tp | Well anyways. You can boot our shiny new (well almost) kernels again. :) | 14:05 |
| smb_tp | ... and I should remember panics near net init are also near ramdisk init... | 14:06 |
| soren | I can. I'm very happy! | 14:06 |
| smb_tp | Nice to be of service :) | 14:07 |
| * smb_tp goes and brews some coffee... | 14:07 | |
| * soren too | 14:08 | |
| fbond | Hi, I'm trying to sort out some inconsistent reports regarding Ubuntu kernels on VIA C3 CPUs. | 16:01 |
| fbond | This is all about support for CMOV, as I understand things. | 16:01 |
| fbond | I've got one user trying to use 8.04 Server Edition on a C3 and is getting "This kernel requires the following features not present on the CPU: cmov | 16:03 |
| fbond | Unable to boot - please use a kernel appropriate for your CPU." | 16:03 |
| fbond | (Or similar) | 16:03 |
| fbond | He gets this message on the first reboot *after* installation. | 16:03 |
| fbond | Then I hear from another user (discussion at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/254453) that 8.04 server edition works fine on his C3, which claims to be a Samuel 2 (and therefore shouldn't support CMOV). | 16:04 |
| fbond | So here are the choices: | 16:04 |
| rtg | fbond: the actual requirement is PAE. | 16:04 |
| fbond | PAE? | 16:04 |
| rtg | physical address extension support in the page table mechanism | 16:05 |
| rtg | its also a known problem. | 16:05 |
| fbond | rtg: Known in intrepid, you mean? | 16:05 |
| rtg | or rather, the issue that its not detected at install time is known. | 16:05 |
| rtg | dunno about Intrepid, but probably. | 16:06 |
| fbond | So does 8.04 SE install the -server kernel? | 16:06 |
| fbond | Maybe more pertinent: is the problem specific to the -server kernel (I had been assuming it is)? | 16:07 |
| rtg | fbond: I'm unfamiliar with 'SE', but the issue is specific to the server kernel. | 16:07 |
| fbond | rtg: Okay, that's what I thought. | 16:07 |
| fbond | SE = Server Edition | 16:07 |
| rtg | fbond: ah. should have guessed | 16:08 |
| fbond | I have one user claiming that SE installed -generic, and another is having this issue with SE, so I assume he somehow got -server. | 16:08 |
| fbond | Just trying to figure out what the heck happened. | 16:08 |
| rtg | fbond: -generic should work fine. it supports 586 and higher | 16:08 |
| fbond | rtg: Yeah, I know :) | 16:08 |
| fbond | Who would know the server installatino process well enough to tell me how one could get a different kernel in different install runs? | 16:09 |
| rtg | fbond: you could look on the server CD and see for sure, but I don't think it has the generic kernel. | 16:10 |
| fbond | rtg: Thanks for your help. | 16:11 |
| rtg | fbond: I think one of the real problems is that the server CD boots the generic kernel, but installs the server kernel. | 16:11 |
| fbond | I think one user is using the "server" isolinux boot target on a Desktop CD, or something. | 16:12 |
| fbond | rtg: Yes, that is related to the problem the user that actually used the Server Edition CD is having. | 16:12 |
| fbond | Oh, that boot target doesn't exist anymore... | 16:13 |
| rtg | fbond: you can use the alternate installer to install a command line only -generic kernel for use on appliances (such as the VIA C3) | 16:13 |
| fbond | rtg: Yep. In fact, I think the user that reports SE works on his C3 really just did that. | 16:14 |
| fbond | rtg: So the issue at hand is not related to CMOV, though? | 16:15 |
| rtg | not as far as I know. I'm not really sure what CMOV is. | 16:15 |
| fbond | There are some C3s that support CMOV. Would those C3's still not support -server due to the PAE requirement? | 16:15 |
| fbond | rtg: There's a lot of confusing information out there. | 16:15 |
| rtg | fbond: I know for a fact the VIA C3 doesn't support PAE, which is a requirement of the server kernel. | 16:16 |
| rtg | fbond: New P6 OpCodes: CMOV (conditional move) | 16:17 |
| mjg59 | CMOV is a P6 opcode, not a (required) i686 one | 16:19 |
| mjg59 | But everything that supports PAE should support cmov | 16:19 |
| fbond | mjg59: So ... which kernel options determine PAE/CMOV requirements for a given kernel build? | 16:20 |
| mjg59 | PAE will be required if CONFIG_HIGHMEM64G is set | 16:20 |
| fbond | Okay. Is CONFIG_M586/CONFIG_M686 relevant? | 16:21 |
| mjg59 | If the kernel's not build with i586 or C3 support, then it'll probably end up requiring cmov | 16:23 |
| mjg59 | s/build/built/ | 16:23 |
| fbond | mjg59: I've seen in the past reports that gcc is buggy and uses CMOV when compiling for 686 (despite the fact that it is an optional instruction). Is that the source of that dependency? | 16:23 |
| fbond | Sorry for all of the questions :) | 16:23 |
| fbond | I'm going to document all of this somewhere obvious so that other people can avoid spending a lot of time hunting this info down. | 16:24 |
| mjg59 | fbond: cmov is about the only useful bit of the i686 instruction set in most cases | 16:25 |
| mjg59 | So yeah, gcc uses it. The kernel build system is smart enough not to do that if you've asked it to support a CPU that doesn't have cmov. | 16:25 |
| fbond | mjg59: Would you consider this a bug in gcc? | 16:25 |
| mjg59 | fbond: Arguably, but it's an argument that occured a long time ago and it's not changing now | 16:26 |
| fbond | mjg59: Okay, I can settle with that. | 16:26 |
| fbond | Thanks! | 16:26 |
| zul | BenC: any reason why CONFIG_XEN is not turned on for the generic kernels? | 16:32 |
| BenC | I think because it wont turn on unless we enable 64-bit DMA which does a lot of other weird crap | 16:44 |
| BenC | disables some drivers in fact (legacy drivers, but drivers we always had in generic kernels) | 16:44 |
| laga | BenC: did you have a chance to review aufs? or are you watching for me to submit that minor fix for the config? | 16:44 |
| === mkrufky is now known as mkrufky-lunch | ||
| === mkrufky-lunch is now known as mkrufky | ||
| === rikai_ is now known as rikai | ||
| === mkrufky is now known as Guest73656 | ||
| === mkrufk1 is now known as mkrufky | ||
| === thegodfather is now known as fabbione | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
