Hi, Marc. On Mon, Sep 05, 2005 at 03:43:11PM +0200, Marc Bevand wrote: > Tejun Heo wrote: > | > | >o I am using the controller in a 64-bit 133 MHz PCI-X bus. > | > | Mine is hanging off regular PCI slot. > > I just tried to use a PCI slot instead of a PCI-X one. It does not > change anything. > > | Okay, it seems that command is normally issued and completed. My > | primary suspicion now is regarding memory IO mapping. > | > | - How much memory do you have on the system? > > My system is a dual-Opteron, with 1 GB (attached to the first CPU, > no RAM on the 2nd CPU). I tried to boot with numa=off, nothing changes. > > | - Can you try to boot with iommu=off kernel parameter? > > I tried iommu=soft (what you told me in your 2nd reply). > Nothing changes.
My incorrect guess was that your system has > 4GB memory and iommu was screwed up somehow because new sil24 driver currently sets DMA memory mask to 32bit while original one sets it to 64bit making new sil24 use iommu for memories > 4GB unlike the original one. > | - Can you try to boot with x86 kernel? > > I will try it ASAP (right now I only have a pure 64-bit system). I was suggesting this for about the same reason, so this won't make much difference either, I think. Trying this would be nice anyway to eliminate a possibility. You don't have to install 32bit userland. Just cross-compile 32bit kernel and boot it. System will fail to enter userland but all we need to see is libata probing outputs. I use the following scripts for cross compiling for x86 from x86-64. x86-64 compiler and binutils support x86 binaries out of the box and only some flags are needed. $ cat i386-make #!/bin/bash exec make ARCH=i386 CROSS_COMPILE=i386-linux- "$@" $ cat i386-linux-ar #!/bin/bash exec ar "$@" [EMAIL PROTECTED]:~/bin]$ cat i386-linux-as #!/bin/bash exec as --32 "$@" [EMAIL PROTECTED]:~/bin]$ cat i386-linux-gcc #!/bin/bash exec gcc -m32 "$@" [EMAIL PROTECTED]:~/bin]$ cat i386-linux-ld #!/bin/bash exec ld -melf_i386 "$@" [EMAIL PROTECTED]:~/bin]$ cat i386-linux-nm #!/bin/bash exec nm "$@" [EMAIL PROTECTED]:~/bin]$ cat i386-linux-objcopy #!/bin/bash exec objcopy "$@" [EMAIL PROTECTED]:~/bin]$ cat i386-linux-ar #!/bin/bash exec ar "$@" [EMAIL PROTECTED]:~/bin]$ cat i386-linux-objdump #!/bin/bash exec objdump "$@" [EMAIL PROTECTED]:~/bin]$ cat i386-linux-strip #!/bin/bash exec strip "$@" > Since the current sil24-original head, which is the only kernel detecting > my disks, is really close to a vanilla 2.6.12-rc5 kernel, I have back- > ported the first version of your rewritten sata_sil24 driver to 2.6.12-rc5, > and I am currently testing/examining each patch separating sil24-original > current from 2.6.12-rc5, hoping to find the one that breaks my system. > > Another thing: just to be sure, did you notice that the driver from the > sil24 head prints: > ata9: SATA max UDMA/100 cmd 0xFFFFC20000030000 ctl 0x0 bmdma 0x0 irq 185 > while the driver from the sil24-original head prints: > ata9: SATA max UDMA/100 cmd 0xFFFFC20000490000 ctl 0xFFFFC2000049000A bmdma > 0xFFFFC20000490000 irq 201 > 'ctl' and 'bmdma' are 0x0 in the first case, is it normal ? Yes, those are normal. Those registers are never used / properly supported by sil24 and the original driver just initialized them with meaningless values. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
