Hello, Marc.
Marc Bevand wrote:
Tejun Heo writes:
Weird, I can tell you that 0.2 driver works for at least two sil24
controllers - mine and Edward Falk's. Can you please apply the
following patch to the current ALL head and post dmesg?
Done. But dmesg is quite large (240 kB), so here it is:
http://epita.fr/~bevand_m/pub/sata_sil24.dmesg
Notes:
o This time 2 disks were plugged (ata19 and ata20, on ports 2 and 3).
o I had to #undef ATA_VERBOSE_DEBUG in your patch else the kernel freezes
when init(8) starts running all the initscripts, probably because too
many messages are printk()ed on the console. Let me know if you _really_
need ATA_VERBOSE_DEBUG, I can try with a serial console.
Nope, ATA_DEBUG is enough.
Here is the relevant part of dmesg, for ata19:
ata_device_add: ata19: probe begin
ata_dev_identify: ENTER, host 19, dev 0
ata_dev_identify: do ATA identify
ata_sg_setup_one: mapped buffer of 512 bytes for read
sil24_host_intr: sata_sil24 ata19: normal interrupt on port2
stat=0x0 irq=0xb00000 cmd_err=0 sstatus=0x113 serror=0x4050000
ata_sg_clean: unmapping 1 sg elements
ata19: dev 0 cfg 49:0000 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000
88:0000
ata19: no dma
ata19: dev 0 not supported, ignoring
ata_dev_identify: EXIT, err
ata_dev_identify: ENTER/EXIT (host 19, dev 1) -- nodev
ata_device_add: ata19: probe end
There is definitely a problem when issuing the IDENTIFY DEVICE command.
However I don't have any hardware doc so I can't interpert the "normal
interrupt" log line.
I don't have hw doc either but the line looks fine compared to my
working output.
More information about my context:
o My arch is x86_64, what is yours ?
Tested both on x86 and EM64T.
o The controller is using a SiI3124-2 chip (SATA 3.0 Gbps) not a
SiI 3124-1 one (1.5 Gbps); does it matter ?
Mine is a 3.0G chip, too.
o I am using the controller in a 64-bit 133 MHz PCI-X bus.
Mine is hanging off regular PCI slot.
o lspci output:
$ lspci -vvs 1:6
0000:01:06.0 RAID bus controller: Silicon Image, Inc. (formerly CMD Technology
Inc) SiI 3124 PCI-X Serial ATA Controller (rev 01)
Subsystem: Silicon Image, Inc. (formerly CMD Technology Inc): Unknown
device 6124
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr-
Stepping+ SERR+ FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Interrupt: pin A routed to IRQ 193
Region 0: Memory at fc5ffc00 (64-bit, non-prefetchable) [size=128]
Region 2: Memory at fc5f0000 (64-bit, non-prefetchable) [size=32K]
Region 4: I/O ports at 8c00 [size=16]
Expansion ROM at fc500000 [disabled] [size=512K]
Capabilities: [64] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [40] PCI-X non-bridge device.
Command: DPERE- ERO+ RBC=0 OST=5
Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-, DC=simple,
DMMRBC=0, DMOST=0, DMCRS=0, RSCEM- Capabilities: [54] Message Signalled
Interrupts: 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
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?
- Can you try to boot with iommu=off kernel parameter?
- Can you try to boot with x86 kernel?
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
