Hi, I finally have an update on this issue. It all boiled down to an errata on the XLR CPU (PA1041.1 - PCI-X host mode can only use BAR0 in 32-bit mode ). The bootloader had a workaround applied for it, but it had a bug when applying the workaround to specific CPU revisions, and unfortunately the revision I was using needed the fix but didn't have it applied. The result was the PCI subblock sometimes not recognizing the correct addressing. Thanks for your help, really appreciated. Alex On Thu, Sep 18, 2008 at 10:30 AM, Alex Gonzalez <langabe@xxxxxxxxx> wrote: > Thanks for that Sergei. > > To this point there is little more information we can get from a > software perspective. I am handing this over to hardware design. I'll > make sure I'll update the thread when a solution is found, if only to > assert it as a hardware design issue. > > Thanks for all your help, > Alex > > On Tue, Sep 16, 2008 at 11:13 AM, Sergei Shtylyov > <sshtylyov@xxxxxxxxxxxxx> wrote: >> 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
