Rafael Barrera Oro <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Thu, 03 Aug 2006 11:03:33 -0300:
I have a couple other comments, possible hints, besides alsa... Take them or leave them as you see fit. If you only want the alsa stuff, look for the "snd" entry down near the bottom. > JFS: nTxBlock = 3989, nTxLock = 31916 > SGI XFS with ACLs, large block/inode numbers, no debug enabled I see JFS and XFS file systems here... then down near the bottom... > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > Probing IDE interface ide0... I see you have generic IDE drivers here, then Via below. The generics load first so get used... > md: linear personality registered for level -1 > md: raid0 personality registered for level 0 > md: raid1 personality registered for level 1 > md: raid5 personality registered for level 5 > md: raid4 personality registered for level 4 > md: raid6 personality registered for level 6 > md: multipath personality registered for level -4 > md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27 > md: bitmap version 4.39 > device-mapper: 4.5.0-ioctl (2005-10-04) initialised: [EMAIL PROTECTED] Hmm... RAID and LVM? Cool! =8^) I'm running a RAID 0/1/6 setup here, with LVM but not on root, so I don't have to hassle the initramfs. I'm running partitioned RAID, however, with a working and backup copy of the root partition. Interesting to see someone else with md-raid. If you aren't using all these personalities, you can deconfigure the ones you don't use. It'd be unusual to use the linear personality with the others, for instance, and multipath you probably don't need as well, unless you have a very expensive setup. That's possible, but if so, linear is even more unlikely, so you can almost certainly deconfigure one, and possibly both. Of course, if you're not using RAID/LVM at all, you can disable the entire md and probably device-mapper config as well, saving more kernel memory. > libata version 1.20 loaded. > sata_via 0000:00:0f.0: version 1.1 > sata_via 0000:00:0f.0: routed to hard irq line 10 > ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xB802 bmdma 0xA800 irq 17 > ata2: SATA max UDMA/133 cmd 0xB400 ctl 0xB002 bmdma 0xA808 irq 17 > ata1: SATA link down (SStatus 0) > scsi0 : sata_via > ata2: SATA link down (SStatus 0) > scsi1 : sata_via You have both SATA and PATA drives? Not entirely unusual, but if not, you can kill the config on the one you aren't using, saving a bit more kernel memory/size. > ReiserFS: hda3: warning: sh-2021: reiserfs_fill_super: can not find > reiserfs on hda3 > kjournald starting. Commit interval 5 seconds > EXT3-fs: mounted filesystem with ordered data mode. ... I see ReiserFS and Ext3 here, in addition to the JFS/XFS above. If you aren't using all four filesystem types, you could deconfigure what you aren't using. (I use all reiserfs here, built-in, with FAT, ext2, and iso9660 as modules that aren't normally loaded, therefore saving that bit of kernel size.) > VP_IDE: IDE controller at PCI slot 0000:00:0f.1 > VP_IDE: chipset revision 6 > VP_IDE: not 100% native mode: will probe irqs later > VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1 > VP_IDE: port 0x01f0 already claimed by ide0 > VP_IDE: port 0x0170 already claimed by ide1 > VP_IDE: neither IDE port enabled (BIOS) The second set of IDE drivers. These are the one's for your chipset as it detects the chipset. However, the generic IDE drivers above are already handling the drives, so these do nothing. Unless you have something else (and add-on card?) that needs the generic drivers, I'd say dump them and go with these. That should allow you faster DMA access. Right now you have three separate hard drive chipset drivers loaded, the generic IDE, Via-SATA, and VIA-IDE. Here it says VIA-IDE can't do anything as the generics are already handling the hardware, so you can almost certainly get rid of one or the other of those (I'd say the generics). As mentioned above, if you don't have anything hooked up to the SATA, you might as well deconfigure those as well. You can always reconfigure them if you get SATA drives later. > snd: no version for "struct_module" found: kernel tainted. This one's the only thing I see about sound. As I suspected, it's a version mismatch between your running kernel and the driver that's trying to load. You'll want to either enable the kernel's sound drivers and not worry about the external driver (that's what I do, as it'll be less problems most of the time for all but the newest sound hardware), or ensure that you are compiling the external alsa drivers against the specific kernel you are running, /not/ a different one. As the guide says, you'll need to recompile your alsa drivers each time you recompile the kernel, if you choose the external drivers. **IMPORTANT** The ALSA guide actually deals with exactly the error you are getting, down near the bottom in the troubleshooting stuff. The most common reason, it says, is that you switched from external to in-kernel drivers, and didn't remove the old external drivers. Due to portage's config-protect, which saves all your config files from getting overwritten automatically, portage won't automatically remove the old external drivers, and the initscripts will still try to load the old and stale drivers until you manually remove them so it can use the kernel drivers. Of course, this would be your most likely problem. > eth0: no IPv6 routers present I don't deal with IPv6 here, so can't say for sure on this, but it looks to me like you don't have an IPv6 connection either, based on the above. If that's indeed the case, you're all IPv4, again, deconfiguring IPv6 out of your kernel will save you that bit of memory. Keep in mind that kernel memory is locked memory -- it's never swapped. Therefore, wasted kernel memory is memory that can't be used by your programs or for cache. If you aren't using part of your kernel that's loaded, you aren't running as efficient as you could be. One bonus to setting all the unused stuff above to "no", is that you'll have a rather shorter dmesg log, should you need to do any future troubleshooting. =8^) Hint for testing the kernel, if you aren't sure what you are removing. Remember when testing what that you can safely turn off in your kernel, to make sure you have a working bootable kernel around, then install another one, and configure GRUB/LILO so you can boot either one. That way, if the test one screws up, all you have to do is reboot to the known working one and turn on whatever feature you turned off that made it not boot. FWIW, it does take a bit to learn what all those kernel options are and do, but once you've learned what stuff does and how the kernel is laid out, even switching to an entirely different mobo, or even from x86 to amd64, isn't a big problem, as you'll find you already have a good idea where to look for stuff. I know it took me several sessions of going thru the kernel options to figure out what everything was. After that, as I said, even switching to amd64 wasn't as big a deal as I thought it might be, because I already understood how the kernel config layout worked and where everything was. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [email protected] mailing list
