Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 194531 - Kernels (>2.6.13) dont recognize the sata harddisk on ASUS K8N4-E motherboard
Summary: Kernels (>2.6.13) dont recognize the sata harddisk on ASUS K8N4-E motherboard
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
Depends on:
Reported: 2007-10-02 17:40 UTC by punkid
Modified: 2007-11-12 02:56 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---

My gentoo-sources-2.6.22-r6 config (.config,33.40 KB, text/plain)
2007-10-02 17:42 UTC, punkid
lspci and dmesg output on kernel 2.6.13 (output,16.83 KB, text/plain)
2007-10-02 17:47 UTC, punkid
Kubuntu LiveCD's kernel config file (linux-header-2.6.20-15-generic-config,81.28 KB, text/plain)
2007-10-07 11:39 UTC, punkid
My gentoo-sources-2.6.22-r8 config file (.config,37.93 KB, text/plain)
2007-10-07 11:40 UTC, punkid
The dmesg output in kubuntu (kubuntu-dmesg.txt,27.33 KB, text/plain)
2007-11-09 15:21 UTC, punkid
The lspci output in kubuntu (kubuntu-lspci.txt,17.70 KB, text/plain)
2007-11-09 15:22 UTC, punkid
The dmesg output with loglevel boot parameters (kubuntu-dmesg-loglevel7.txt,27.34 KB, text/plain)
2007-11-09 16:03 UTC, punkid
iomem output (iomem.txt,1.18 KB, text/plain)
2007-11-09 17:18 UTC, punkid

Note You need to log in before you can comment on or make changes to this bug.
Description punkid 2007-10-02 17:40:29 UTC
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.
Comment 1 punkid 2007-10-02 17:42:32 UTC
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.
Comment 2 punkid 2007-10-02 17:47:43 UTC
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
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2007-10-02 21:09:40 UTC
How does kernel fail to recognize your SATA drives? It clearly *does* recognize them.

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
Comment 4 punkid 2007-10-03 02:17:33 UTC
the dmesg output is given under gentoo-sources-2.6.13. the kernels >2.6.13 cannot boot at all.
Comment 5 punkid 2007-10-05 03:48:26 UTC
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:

Best Regards
Comment 6 Mike Pagano gentoo-dev 2007-10-05 14:12:37 UTC
Can you try booting into a non working kernel with the following parameters:

acpi=off irqpol
Comment 7 punkid 2007-10-05 14:32:38 UTC
Ooh, that works. So then i'm not gonna be able to use acpi things any more? 
Comment 8 Mike Pagano gentoo-dev 2007-10-05 18:50:17 UTC
Nforce motherboards don't have the best history with the linux kernel

Can you try pci=nommconf without the acpi flag.
Comment 9 punkid 2007-10-06 03:14:17 UTC
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_GOBIOS is not set
# 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.
Comment 10 punkid 2007-10-07 11:38:33 UTC
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
Comment 11 punkid 2007-10-07 11:39:29 UTC
Created attachment 132808 [details]
Kubuntu LiveCD's kernel config file
Comment 12 punkid 2007-10-07 11:40:25 UTC
Created attachment 132810 [details]
My gentoo-sources-2.6.22-r8 config file
Comment 13 Mike Pagano gentoo-dev 2007-10-07 20:46:40 UTC
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.
Comment 14 Maarten Bressers (RETIRED) gentoo-dev 2007-10-13 21:49:22 UTC
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.
Comment 15 punkid 2007-10-14 04:16:32 UTC
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 :(

Comment 16 Mike Pagano gentoo-dev 2007-11-09 01:26:27 UTC
The Kubuntu live cd 7.04 uses linux-

Does the drive function using gentoo-sources-2.6.20-r10? That uses linux-

I would be curious if a vanilla works.
Comment 17 punkid 2007-11-09 03:21:30 UTC
So i tried vanilla-sources-, 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-
> Does the drive function using gentoo-sources-2.6.20-r10? That uses
> linux-
> I would be curious if a vanilla works.

Comment 18 Mike Pagano gentoo-dev 2007-11-09 14:47:57 UTC
Can you boot from the kubuntu working cd and attach the dmesg please?

Please also attach the output of lscpi -vv
Comment 19 punkid 2007-11-09 15:21:52 UTC
Created attachment 135590 [details]
The dmesg output in kubuntu
Comment 20 punkid 2007-11-09 15:22:15 UTC
Created attachment 135592 [details]
The lspci output in kubuntu
Comment 21 punkid 2007-11-09 15:23:22 UTC
I've attached the dmesg and lspci -vv output.

Comment 22 Mike Pagano gentoo-dev 2007-11-09 15:35:07 UTC
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?

Comment 23 punkid 2007-11-09 16:03:48 UTC
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?
Comment 24 Mike Pagano gentoo-dev 2007-11-09 16:51:48 UTC
Thanks for following through with all of this.

Can you boot into the Kubuntu livecd and attach the output of:
cat /proc/iomem

Comment 25 punkid 2007-11-09 17:18:55 UTC
Created attachment 135601 [details]
iomem output

hope that helps
Comment 26 Mike Pagano gentoo-dev 2007-11-09 17:34:14 UTC
(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.

Comment 27 Mike Pagano gentoo-dev 2007-11-09 20:02:41 UTC
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.
Comment 28 punkid 2007-11-10 03:26:55 UTC
Okay, thx for your enthusiastic explanation and help. Now i'm gonna close this bug.

Comment 29 Daniel Drake (RETIRED) gentoo-dev 2007-11-10 12:45:14 UTC
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...
Comment 30 Mike Pagano gentoo-dev 2007-11-10 16:26:31 UTC
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.

Comment 31 Mike Pagano gentoo-dev 2007-11-11 20:57:12 UTC
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:

Located at:;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.

Comment 32 punkid 2007-11-12 02:56:50 UTC
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.