Hello.
Alex Gonzalez wrote:
I got some more information regarding this issue.
After reading "PCI Compatibility and PCI-Native Mode Bus Master
Adapters" as pointed by Sergei, I printed the Bus Master ATA status
register (offset 0x2), the PCI status/command (offset 0x4) register
and the SATA ATA status (offset 0x104), control (offset 0x100) and
error (offset 0x108) registers looking for clues.
:***sil_freeze()***
0:***ata_bmdma_status=00000002
This status means that transfer ended due to a PCI error.
0:PCI status=02b00016
0:SATA status 00000113 ctl 00000310 err 00000000
Everything looks fine to me, except maybe bits 1 and 4 of the PCI
status. The Silicon Image Sil3512 datasheet specifies that bit 4
should be hardcoded to zero, and bit 0 (the IO space enable) is
strangely zero, maybe it's set dynamically when needed?
No, it's setn when enabling the dvice if it has BARs in I/O space. Or
at least it should be...
Following on Tejun's advise, I found out that just the delay of a
printk in ata_bmdma_stop(), right after the iowrite8, gets rid of the
cache error and it's replaced by this:
Hm, maybe it was the cache error was what stopped the DMA transfer?
[4294671.719000] 0:<7>sata_sil 0000:00:01.0: version 2.1
[4294671.720000] 0:<6>sata_sil 0000:00:01.0: Applying R_ERR on DMA
activate FIS errata fix
[4294671.722000] 0:<6>ata1: SATA max UDMA/100 cmd 0xc0000080 ctl
0xc000008a bmdma 0xc0000000 irq 24
[4294671.724000] 0:<6>ata2: SATA max UDMA/100 cmd 0xc00000c0 ctl
0xc00000ca bmdma 0xc0000008 irq 24
Memory mapped registers are used by the driver. So, probably I/O
space was not enabled on purpose -- can't find the implementation of
pci_enable_device() right now...
[4294671.725000] 0:<6>scsi0 : sata_sil
[4294672.182000] 2:<6>ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[4294672.205000] 2:drivers/ata/libata-sff.c:368: Delay
[4294672.219000] 2:<6>ata1.00: ATA-7: ST3160815AS, 4.AAB, max UDMA/133
[4294672.238000] 2:<6>ata1.00: 312581808 sectors, multi 0: LBA48 NCQ
(depth 0/32)
[4294672.259000] 2:drivers/ata/libata-sff.c:368: Delay
[4294672.277000] 2:drivers/ata/libata-sff.c:368: Delay
[4294672.291000] 2:<6>ata1.00: configured for UDMA/100
[4294672.306000] 0:<6>scsi1 : sata_sil
[4294672.610000] 2:<6>ata2: SATA link down (SStatus 0 SControl 310)
[4294672.628000] 0:<5>scsi 0:0:0:0: Direct-Access ATA
ST3160815AS 4.AA PQ: 0 ANSI: 5
[4294672.630000] 0:<5>SCSI device sda: 312581808 512-byte hdwr sectors
(160042 MB)
[4294672.631000] 0:<5>sda: Write Protect is off
[4294672.632000] 0:<7>sda: Mode Sense: 00 3a 00 00
[4294672.633000] 0:<5>SCSI device sda: write cache: enabled, read
cache: enabled, doesn't support DPO or FUA
[4294672.634000] 0:<5>SCSI device sda: 312581808 512-byte hdwr sectors
(160042 MB)
[4294672.635000] 0:<5>sda: Write Protect is off
[4294672.636000] 0:<7>sda: Mode Sense: 00 3a 00 00
[4294672.637000] 0:<5>SCSI device sda: write cache: enabled, read
cache: enabled, doesn't support DPO or FUA
[4294672.638000] 0:<6> sda:0:drivers/ata/libata-sff.c:368: Delay
[4294702.640000] 0:<3>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[4294702.641000] 0:<3>ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0
tag 0 cdb 0x0 data 4096 in
The command failed was READ DMA.
[4294702.641000] res 40/00:00:00:00:00/00:00:00:00:00/00
Emask 0x20 (host bus error)
Hum, the output IDE taskfile looks strange... status of 0x40 and all
0s in other regs...
[4294702.646000] 0:<4>ATA: abnormal status 0x58 on port 0xc0000087
[4294702.651000] 0:<4>ATA: abnormal status 0x58 on port 0xc0000087
[4294702.652000] 0:<4>ATA: abnormal status 0x58 on port 0xc0000087
[4294702.652000] 0:<4>ATA: abnormal status 0x58 on port 0xc0000087
[4294702.652000] 0:<4>ATA: abnormal status 0x58 on port 0xc0000087
[4294702.652000] 0:<4>ATA: abnormal status 0x58 on port 0xc0000087
Hum, it's a status characterisitc for an unfinished PIO transfer.
and never comes back.
I'll try to decode the ATA error see where it takes me next.
Did that for you. :-)
BTW, the tables at
http://ata.wiki.kernel.org/index.php/Libata_error_messages lack the
explanation of a number after the last slash...
Thanks for your continued help and patience,
Alex
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
