The kernels (>2.6.13), whatever gentoo-source or genkernel or vanilla-kernel ... all fail to recognize the sata harddisk on ASUS K8N4-E motherboard. What weird is, this problem only occurs on a gentoo system, nor ubuntu, neither fedora. I'm pretty ensure that there's no problem with the kernel config, cuz even the Gentoo LiveCD cannot recognize the sata harddisk, either. I see someone on the gentoo forums also met this problem with an ASUS K8N4-E motherboard. Reproducible: Always Steps to Reproduce: 1. configure the kernel 2. make && make modules_install && make install the kernel 3. reboot Actual Results: VFS: Cannot open root device "sda9" or unknown-block(0,0). The kernels fail to recognize my sata harddisk. Expected Results: Since the ubuntu and fedora are succeed in recognizing my sata device, so it should does in Gentoo. Here's my partition list : Filesystem Type Size Used Avail Use% Mounted on /dev/sda8 ext2 38M 8.4M 28M 24% /boot /dev/sda9 reiserfs 18G 5.3G 13G 30% / /dev/sda10 reiserfs 8.1G 4.9G 3.2G 61% /home my grub.conf setting : title=Gentoo Linux 2.6.22 root (hd0,7) kernel /boot/vmlinuz-2.6.22-gentoo-r6 root=/dev/sda9 video=vesafb:mtrr,ywrap,1440x900-32 And you can have a look at my original post, where i've told every detail and had some discussion with others already, but still unsolved. http://forums.gentoo.org/viewtopic-t-581033.html
Created attachment 132405 [details] My gentoo-sources-2.6.22-r6 config Here's my gentoo-sources-2.6.22 config file, i do have scsi devices and root filesystem built-in support.
Created attachment 132406 [details] lspci and dmesg output on kernel 2.6.13 Here's the lspci and dmesg output, running on my Gentoo system with gentoo-sources-2.6.13-r6
How does kernel fail to recognize your SATA drives? It clearly *does* recognize them. <snip> ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xD400 irq 17 ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xD408 irq 17 ata1: no device found (phy stat 00000000) scsi0 : sata_nv ata2: no device found (phy stat 00000000) scsi1 : sata_nv ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 22 ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [APSJ] -> GSI 22 (level, low) -> IRQ 18 PCI: Setting latency timer of device 0000:00:08.0 to 64 ata3: SATA max UDMA/133 cmd 0x9E0 ctl 0xBE2 bmdma 0xC000 irq 18 ata4: SATA max UDMA/133 cmd 0x960 ctl 0xB62 bmdma 0xC008 irq 18 ata3: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4773 85:7c68 86:3e01 87:4763 88:407f ata3: dev 0 ATA, max UDMA/133, 312581808 sectors: lba48 nv_sata: Primary device added nv_sata: Primary device removed nv_sata: Secondary device added nv_sata: Secondary device removed ata3: dev 0 configured for UDMA/133 scsi2 : sata_nv ata4: no device found (phy stat 00000000) scsi3 : sata_nv Vendor: ATA Model: Maxtor 6V160E0 Rev: VA11 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) SCSI device sda: drive cache: write back SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 > Attached scsi disk sda at scsi2, channel 0, id 0, lun 0 Attached scsi generic sg0 at scsi2, channel 0, id 0, lun 0, type 0 </snip>
the dmesg output is given under gentoo-sources-2.6.13. the kernels >2.6.13 cannot boot at all.
I say the kernels (>2.6.13) dont recognize my sata harddisk, but kernels (<=2.6.13) do. The dmesg output was given under my current system with gentoo-sources 2.6.13-r6, so it *does * recognize my sata harddisk. This problem is really a headache for anyone who owns the same motherboard as me, i've contacted many of them, tried to comfirm this issue, and no one has solved it so far. Before i reported this as a bug, i found the latest ubuntu and fedora livecd (with kernels 2.6.20) both recognized my sata device, only gentoo did not. So please take my report seriously. As i mentioned before, you can get more info from this post: http://forums.gentoo.org/viewtopic-t-581033.html Best Regards
Can you try booting into a non working kernel with the following parameters: acpi=off irqpol
Ooh, that works. So then i'm not gonna be able to use acpi things any more?
Nforce motherboards don't have the best history with the linux kernel Can you try pci=nommconf without the acpi flag.
It also works, so now i re-configure my kernel to avoid mmconfig mode, then i dont need to append the pci=nommconf parameters. CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set CONFIG_PCI_GODIRECT=y # CONFIG_PCI_GOANY is not set I'm trying to contact some other guys in the forums who met the same problem, asking 'em to have a try of this way. Then i can confirm what really matters.
Please let me go some further on this issue. Since i disabled the mmconf access mode in kernel and used direct mode instead, the new kernel works, as well i can boot the gentoo livecd with parameters pci=nommconf, with good sata device recognition. However, i checked the default config file in Kubuntu 7.0.4 LiveCD, the kernel has CONFIG_PCI_GOANY and CONFIG_PCI_MMCONFIG enabled which would cause the sata device recognition problem under Gentoo. So i still wonder what really matters that making the gentoo fail to recognize my sata device. I'll attach both of my gentoo-sources-2.6.22-r8 config file and the Kubuntu LiveCD's one. Best Regards
Created attachment 132808 [details] Kubuntu LiveCD's kernel config file
Created attachment 132810 [details] My gentoo-sources-2.6.22-r8 config file
There's a large difference between the two configs. Using a tool like kccmp might assist you in tracking down the config settings in the kubuntu config that are not in the gentoo config. http://stoopidsimple.com/kccmp
Punkid, here's another idea you might try: build a kernel for Gentoo using the Kubuntu .config and see if that kernel works for you.
Actually i've tried that way, cp the kubuntu .config and only enable some necessary built-in support option such as the whole sata drivers section, the filesystem, leaving others to be compiled as modules. But it failed as before, only if i disable the CONFIG_PCI_GOANY, avoid the mmconfig mode, then it works. That's strange and frustrating :(
The Kubuntu live cd 7.04 uses linux-2.6.20.15. Does the drive function using gentoo-sources-2.6.20-r10? That uses linux-2.6.20.20. I would be curious if a vanilla 2.6.20.15 works.
So i tried vanilla-sources-2.6.20.15, changed back to CONFIG_PCI_GOANY=y, it still fails. But it works if i append the pci=nommconf parameters to the kernel line. > The Kubuntu live cd 7.04 uses linux-2.6.20.15. > > Does the drive function using gentoo-sources-2.6.20-r10? That uses > linux-2.6.20.20. > > I would be curious if a vanilla 2.6.20.15 works. >
Can you boot from the kubuntu working cd and attach the dmesg please? Please also attach the output of lscpi -vv
Created attachment 135590 [details] The dmesg output in kubuntu
Created attachment 135592 [details] The lspci output in kubuntu
I've attached the dmesg and lspci -vv output.
I'm trying to determine if Kubuntu blacklists the device. Can you add the kernel parameter loglevel=7 when booting the Kubuntu livecd and then attach that dmesg?
Created attachment 135596 [details] The dmesg output with loglevel boot parameters I dont know whether i've appended the parameter correctly, is it okay to just append it to the last of the boot line?
Thanks for following through with all of this. Can you boot into the Kubuntu livecd and attach the output of: cat /proc/iomem
Created attachment 135601 [details] iomem output hope that helps
(In reply to comment #25) > hope that helps > It does, I believe Kubuntu using blacklisting so the MMCONFIG gets disabled. If MMCONFIG was enabled, you should see something like this in /proc/iomem: f0000000-f3ffffff : PCI MMCONFIG 0 This would explain why it works in Kubuntu and not in Gentoo-Sources.
As we have solved the problem with kernel parameters and determined that the other distribution solved the issue the same way via different means, I think we can now close this bug. Thanks for your attention and help in providing everything I asked for.
Okay, thx for your enthusiastic explanation and help. Now i'm gonna close this bug.
Mike, have you determined that upstream regard this as a BIOS/mobo bug and won't be fixed in the kernel? Because ideally we'd obviously like this to work out of the box...
All upstream discussions concerning this motherboard result in a determination of mmconfig being uncompatible with this board. Last bios release was in 2006 and apparently has not resolved the issue.
For the Ubuntu Kernel tested, they have decided to disable MMCONFIG by default and make their uses use the kernel parameter to enable it. Git commit for disabling the MMCONFIG by default: d613cff3d5968d3e93bad197480b90733c71b984 Located at: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-feisty.git;a=blobdiff;h=4c18786c099787d53c0e26b20595f6fb244d4d2a;hp=53ca6e897984a669e4a36ef23295bb0f9e30d561;hb=d613cff3d5968d3e93bad197480b90733c71b984;f=arch/i386/pci/common.c In this same commit, they added an entry to kernel-parameters.txt to indicate that you need the kernel parameter mmconf to enable use of MMCONFIG for PCI. Not sure if we want to follow the same path and disable MMCONFIG by default, but at least we now know more of the details of how they solved the issue.
Hey Mike, thx for that info. I asked one of my friend to have a further check on his ubuntu 7.10 Gusty machine, there's no f0000000-f3ffffff in the output of cat /proc/iomen, too. So we can ensure that ubuntu has disabled mmconfig by default.
