[05:28] <jmg> hello all
[05:29] <jmg> what is the reference way to build a -generic kernel from the linux-source package?
[05:35] <crimsun> apt-get source linux-image-$(uname -r)
[05:36] <crimsun> then use debian/rules's target
[05:39] <jmg> is that how the pbuilder does it?
[05:41] <crimsun> yes
[05:41] <crimsun> depending whether you're using feisty or gutsy, you'll need to remove the unneeded configs
[05:42] <crimsun> please see the kernel wiki  (/topic)
[06:08] <jmg> thanks
[06:09] <jmg> crimsun: im trying to compile the gutsy 2.6.22 kernel for feisty (to work around my sdhc bug)
[06:35] <BenC> jmg: here's a better idea, just install the gutsy kernel on feisty
[06:35] <BenC> doesn't matter where it is compiled
[06:35] <jmg> orly?
[06:35] <jmg> it'll work?
[06:35] <BenC> I wouldn't tell you to do it if it would break :)
[06:59] <jmg> BenC: thanks! :)
[11:45] <Lure> any reason we do not enable CONFIG_SND_AC97_POWER_SAVE as suggested by powertop?
[11:45] <crimsun> it's very, very experimental.
[11:45] <crimsun> last I used it in the feisty round, it did Interesting Things on several machines running emu10k1- and intel8x0- driven boards.
[11:46] <crimsun> I can rerun some tests (and more testing is appreciated), but I don't expect things to have changed much.
[11:46] <crimsun> I suppose we need more hda-intel coverage, too.
[11:52] <Lure> crimsun: ok, I may try it here next time I build my custom kernel
[12:15] <mjg59> crimsun: It does nothing with hda-intel
[01:09] <jmg> BenC: I just realised - i need the nvidia binary drivers
[01:34] <ph8> hey guys - is anyone aware of a patch/driver/fix for "Atheros Communications Inc." "Unknown device 001c" "Unknown Device 1033" (From Abit Comp. Corp)? - It's an ethernet controller
[01:34] <ph8> atm i can only boot in recovery mode for some reason and the only difference i can find is that non-recovery tries to start networks
[01:34] <ph8> i'd like to try networks from recovery but have no idea how to get the OS to 'mount' the network cards
[01:36] <lfittl> hm, does anybody know what happened to the linux/ip6_tunnel.h header, debian linux-headers package has it, ubuntu doesn't?
[02:04] <ivoks> we should add DAC960.ko to /lib/modules inside initrd, by default :/
[06:52] <shawarma> Was there a recent kernel update for Feisty?
[06:54] <ivoks> yes
[06:54] <shawarma> Crap. My girlfriend's laptop doesn't boot anymore.
[06:54] <ivoks> sda<->hda change
[06:56] <rtg> shawarma: If you turn off 'quiet splash' from the grub menu, do you see USB crashes? Or does it just fail to boot?
[06:56] <shawarma> rtg: It's using lilo..
[06:56] <shawarma> rtg: ah, and it boots with the old kernel.
[06:56] <shawarma> rtg: I'll switch to grub, and grab some debug info.
[06:57] <ivoks> lots of people reported that with new kernel their disks aren't sdx anymore, but hdx...
[06:57] <rtg> shawarma: You'll have to ask BenC about that one. I know vanishingly little about lilo.
[06:57] <shawarma> rtg: Ah, don't worry about that.
[06:57] <shawarma> rtg: I got it.
[06:57] <rtg> ivoks: You are talking about the lib-ata transition from edgy to feisty. I think shawarma already had feisty installed.
[06:58] <ivoks> no, i'm talking about feisty old kernel to feisty new kernel
[06:58] <ivoks> there are bugs about it
[07:00] <shawarma> Now, that's odd. "No ACPI support in kernel" with the old kernel. There used to be..
[07:07] <shawarma> Oh, ffs..
[07:15] <shawarma> That's odd. It boots just fine with grub.
[07:21] <shawarma> Does that make any sense at all?
[07:22] <mjg59> shawarma: Do you have root=/dev/sda set in lilo.conf?
[07:22] <mjg59> Rather than root=uuid=foo?
[07:22] <pkl_> shawarma: yup, grub probably uses UUIDs in the meu.lst file, Lilo probably hard codes /dev/sdX
[07:23] <shawarma> mjg59: It says root=/dev/hda3
[07:23] <mjg59> shawarma: That's probably wrong
[07:23] <pkl_> shawarma: where is your root partition now?
[07:24] <shawarma> mjg59: But lilo shouldn't worry about that, should it? It installed the new kernel while the old one was running.. Looked up /dev/hda3 to be the third partition on the first harddrive and when rebooting it would just use that? Or have I not understood lilo at all?
[07:24] <shawarma> pkl_: Interestingly, it's the same.
[07:24] <shawarma> pkl_: So nothing has changed w.r.t. device names.
[07:24] <mjg59> shawarma: It passes that argument to the kernel
[07:25] <shawarma> mjg59: Doh.. Of course.
[07:25] <shawarma> mjg59: Nevertheless: It's the same name.
[07:26] <pkl_> shawarma: how far does the boot get?  Do you get past the LILO message?
[07:26] <shawarma> When I came to the machine it was in an initramfs prompt. When I rebooted it, I got impatient, booted the old kernel and fixed it.. It would have been interesting to find out what went wrong.
[07:27] <shawarma> I suppose I could reinstall lilo just for kicks if you're interested?
[07:27] <pkl_> reinstalling lilo would probably make the problem go away anyway.
[07:28] <shawarma> You think? If I do it with the old kernel running?
[07:30] <pkl_> shawarma: hmm, it may not work with the old kernel no.
[07:31] <shawarma> Would it be helpful in any way to get some debugging info this way?
[07:31] <maks_> no you should just use uuid ;)
[07:32] <shawarma> Yes.. I wonder why it wasn't migrated back in the day.
[07:32] <shawarma> Did we only do it for grub?
[07:32] <maks_> afaik lilo is not directly supported
[07:32] <shawarma> raid doesn't work with grub, so it must be supported to some degree.
[07:33] <maks_> why shouldn't it work, sure it does with grub
[07:36] <shawarma> Hm..
[07:36] <shawarma> I'm *almost* sure the installer falls back to lilo if you're either using xfs or raid (or both).
[07:41] <maks_> grub has the xfs patch
[07:41] <maks_> last lilo fallback i know of is when you go all on lvm
[07:42] <shawarma> That works with grub.
[07:43] <shawarma> I'm almost sure of it.
[07:43] <maks_> hehe *almost*
[07:44] <shawarma> I'll try. I've got a feisty install on the way in a virtualbox
[07:45] <JanC> grub works with lvm
[07:45] <JanC> but you need a non-lvm boot partition then  :)
[07:46] <maks_> sure i was speaking of *all* on lvm
[07:46] <maks_> ;)
[07:49] <JanC> why wait until christmas?
[07:51] <shawarma> JanC: Good point.
[08:15] <JoseMedina> hi averyone
[08:16] <JoseMedina> problems with kacpid process
[08:16] <JoseMedina> ??
[08:16] <JoseMedina> on mi Server it's eating 90% of CPU
[08:18] <JoseMedina> root@linux:/home/jose# ps aux | grep acpid
[08:18] <JoseMedina> root        37 81.9  0.0      0     0 ?        R<   12:37  32:29 [kacpid] 
[08:19] <JoseMedina> help me! please!
[08:26] <shawarma> maks_: You're right. LVM-only -> lilo
[10:03] <crimsun> mjg59: right, I'm speaking of upstream's plans for HDA (not AC'97)
[10:04] <mjg59> Ah, ok
[10:14] <Sapote> hi all!
[10:14] <Sapote> have a question about limit of processors of support for ubuntu
[10:15] <Sapote> how many processor is the limit? 16? 32? 128? 256?
[10:15] <Sapote> maxcpus parameter
[10:16] <JanC> Sapote: depends on the kernel you use
[10:17] <Sapote> smp
[10:17] <Sapote> default smp amd64 
[10:18] <JanC> so -generic kernel for amd64?
[10:18] <JanC> I don't know the exact number, but AFAIK it should be more than enough for any desktop   :)
[10:19] <Sapote> ;D 
[10:19] <Sapote> yes.. but i find the magic number
[10:20] <JanC> isn't that in the kernel config files?
[10:21] <Sapote> maybe
[10:23] <JanC> grep for CONFIG_NR_CPUS in the kernel config file of your kernel in /boot/  :)
[10:24] <JanC> at least, I think that's the setting you need (I'm no kernel dev)
[10:24] <rtg> Sapote: /boot/config-2.6.20-12-generic:CONFIG_NR_CPUS=8
[10:25] <Sapote> 8 ok
[10:25] <Sapote> thanks!
[10:25] <JanC> I don't think many desktops have more  :)
[10:26] <JanC> server kernels might have support for more CPUs
[10:27] <JanC> rtg: you have amd64, or it's always the same for -generic ?
[10:27] <rtg> Sapote: debian/config/i386/config.server-bigiron:CONFIG_NR_CPUS=64
[10:27] <JanC> yeah, server-bigiron is for people with deep pockets :)
[10:27] <Sapote> lol!
[10:27] <rtg> JanC: generic is the same for i386 and amd64.
[10:27] <Sapote> :D
[10:28] <Sapote> maxcups parameter 1-256  is correct?
[10:28] <JanC> rtg: thanks, good to know, wasn't sure about that  :)
[10:28] <rtg> Here are all of the CPU configs:
[10:28] <rtg> debian/config/i386/config.server:CONFIG_NR_CPUS=8
[10:28] <rtg> debian/config/i386/config.server-bigiron:CONFIG_NR_CPUS=64
[10:28] <rtg> debian/config/i386/config.generic:CONFIG_NR_CPUS=8
[10:28] <rtg> debian/config/ia64/config:CONFIG_NR_CPUS=64
[10:28] <rtg> debian/config/hppa/config:CONFIG_NR_CPUS=32
[10:28] <rtg> debian/config/amd64/config.server:CONFIG_NR_CPUS=64
[10:29] <rtg> debian/config/amd64/config.generic:CONFIG_NR_CPUS=8
[10:29] <rtg> debian/config/sparc/config.sparc64-smp:CONFIG_NR_CPUS=64
[10:29] <rtg> debian/config/powerpc/config.powerpc-smp:CONFIG_NR_CPUS=4
[10:29] <rtg> debian/config/powerpc/config.powerpc64-smp:CONFIG_NR_CPUS=32
[10:30] <Sapote> thanks rtg, JanC
[10:30] <JanC> well, except for the i386 UP kernel  :)
[10:34] <rtg> JanC: CONFIG_NR_CPUS depends on CONFIG_SMP
[10:36] <JanC> so if CONFIG_SMP is not set, NR_CPU == 1
[10:36] <JanC> :)