sata_promise driver and 2.6.11 on a MIPS board

sata_promise driver and 2.6.11 on a MIPS board

[Jim Ramsay]

I'm having an odd issue with the sata_promise driver as included with
the 2.6.11 kernel, specifically the kernel downloaded from
www.linux-mips.org, but I think their 2.6.11 branch is up-to-date with
the actual 2.6.11 release in all non-mips-related drivers.

The card in question is a Promise SataII 150 TX4 PCI adapter.  I
currently have only one drive hooked up to it.  Here is a description
of what is happening (have turned ATA debugging on already):

In short, the driver is setting the xfer mode
(libata::ata_dev_set_xfermode) which eventually calls
sata_promise::pdc_packet_start, and this routine writes 1 to what I
believe is the proper control register, and then writes the proper
xfer mode to the data register.  I think.  I don't have a whitepaper
of any sort on the PCI card, so I can't be 100% sure that the values
written or offsets are correct.

The driver then waits via a wait_for_completion apparently waiting for
the PCI card to throw an interrupt so it can continue.  However, I
never see this interrupt generated, and the driver code waits forever.
 I have taken the existing debug and added to it a little to
demostrate the problem:

ata_device_add: ENTER
ata_host_add: ENTER  
dma_alloc_coherent returning 0xa0730000
ata_port_start: prd alloc, virt a0730000, dma 730000
dma_alloc_coherent returning 0xa0733000             
ata1: SATA max UDMA/133 cmd 0xAD049200 ctl 0xAD049238 bmdma 0x0 irq 38
ata_host_add: ENTER                                                   
dma_alloc_coherent returning 0xa0731000
ata_port_start: prd alloc, virt a0731000, dma 731000
dma_alloc_coherent returning 0xa0735000             
ata2: SATA max UDMA/133 cmd 0xAD049280 ctl 0xAD0492B8 bmdma 0x0 irq 38
ata_host_add: ENTER                                                   
dma_alloc_coherent returning 0xa7c4f000
ata_port_start: prd alloc, virt a7c4f000, dma 7c4f000
dma_alloc_coherent returning 0xa0737000              
ata3: SATA max UDMA/133 cmd 0xAD049300 ctl 0xAD049338 bmdma 0x0 irq 38
ata_host_add: ENTER                                                   
dma_alloc_coherent returning 0xa7c46000
ata_port_start: prd alloc, virt a7c46000, dma 7c46000
dma_alloc_coherent returning 0xa7c3b000              
ata4: SATA max UDMA/133 cmd 0xAD049380 ctl 0xAD0493B8 bmdma 0x0 irq 38
ata_device_add: probe begin                                           
ata_device_add: ata1: probe begin
ata_bus_probe: ENTER             
ata1: no device found (phy stat 00000000)
ata_bus_probe: Reset complete            
ata_device_add: ata1: probe end
scsi0 : sata_promise           
ata_device_add: ata2: probe begin
ata_bus_probe: ENTER             
ata2: no device found (phy stat 00000000)
ata_bus_probe: Reset complete            
ata_device_add: ata2: probe end
scsi1 : sata_promise           
ata_device_add: ata3: probe begin
ata_bus_probe: ENTER             
ata3: no device found (phy stat 00000000)
ata_bus_probe: Reset complete            
ata_device_add: ata3: probe end
scsi2 : sata_promise           
ata_device_add: ata4: probe begin
ata_bus_probe: ENTER             
ata_bus_reset: ENTER, host 4, port 3
ata_bus_softreset: ata4: bus reset via SRST
ata_dev_classify: found ATA device by sig  
ata_bus_reset: EXIT                      
ata_bus_probe: Reset complete
ata_dev_identify: ENTER, host 4, dev 0
ata_dev_select: ENTER, ata4: device 0, wait 1
ata_dev_identify: do ATA identify            
ata_qc_issue: ENTER              
pdc_qc_prep: ENTER: Protocol is 2
ata_qc_issue: About to run ap->ops->qc_issue
ata_qc_issue_prot: ENTER                    
ata_dev_select: ENTER, ata4: device 0, wait 1
ata_qc_issue_prot: Doing PIO op              
ata_exec_command_mmio: ata4: cmd 0xEC
ata_qc_issue_prot: EXIT - Ok         
ata_pio_sector: data read   
ata_qc_complete: EXIT    
ata_dump_id: 49==0x2f00  53==0x0007  63==0x0407  64==0x0003  75==0x0000  
ata_dump_id: 80==0x007e  81==0x001b  82==0x346b  83==0x7d01  84==0x4003  
ata_dump_id: 88==0x007f  93==0x0000                                      
ata4: dev 0 ATA, max UDMA/133, 156301488 sectors: lba48
ata_dev_identify: EXIT, drv_stat = 0x50                
ata_dev_identify: ENTER/EXIT (host 4, dev 1) -- nodev
ata_host_set_pio: base 0x8 xfer_mode 0xc mask 0x1f x 4
ata_dev_set_xfermode: set features - xfer mode        
ata_qc_issue: ENTER                           
pdc_qc_prep: ENTER: Protocol is 1
ata_qc_issue: About to run ap->ops->qc_issue
pdc_packet_start: ENTER, ap 87c3e9b8        
pdc_packet_start: Step 1 - Base address is 0xad049000
pdc_packet_start:          Offset is 0x00000010      
pdc_packet_start:          Write complete      
pdc_packet_start:          Read complete (0x00000001)
pdc_packet_start: Step 2 - Base address is 0xad049380
pdc_packet_start:          Offset is 0x00000040      
pdc_packet_start:          Writing 0x07c3b000  
pdc_packet_start:          Write complete    
pdc_packet_start:          Read complete (0x07c3b030)
ata_dev_set_xfermode: Waiting... 

I also found it odd that it detected this drive as the 4th one even
though it is plugged into the port labeled "J1" on the card.  In fact,
where the card is labelled J1 through 4, the driver detects them as
ATA 4, 2, 1, and 3, in that order.

I originally thought the problem may have had something to do with the
offset not matching the actual physical port location, but port 2 is
detected correctly as ATA2 and experiences the same problem, with
offset 0x08 for the control register.

Any ideas or suggestions on how to troubleshoot this further (or fix
it?) would be appreciated.

-- 
Jim Ramsay
Please CC me with responses, thanks!
"Me fail English?  That's unpossible!"

Re: sata_promise driver and 2.6.11 on a MIPS board

[Jeff Garzik]

Jim Ramsay wrote:
> The driver then waits via a wait_for_completion apparently waiting for
> the PCI card to throw an interrupt so it can continue.  However, I
> never see this interrupt generated, and the driver code waits forever.


This is a known bug that definitely needs fixing:

(to ATA developers)
Any time an ATA command is issued outside of the SCSI layer, we need to 
employ a timer to time out commands.

Since most commands are done within the SCSI layer, which provides a lot 
of error handling apparatus, most commands properly time out.  The ones 
during probe - IDENTIFY DEVICE, set xfer mode, etc. - do not have such a 
timer.

	Jeff

Re: sata_promise driver and 2.6.11 on a MIPS board

[Jim Ramsay]

On 6/6/05, Jeff Garzik <jgarzik@pobox.com> wrote:
> Jim Ramsay wrote:
> > The driver then waits via a wait_for_completion apparently waiting for
> > the PCI card to throw an interrupt so it can continue.  However, I
> > never see this interrupt generated, and the driver code waits forever.
> 
> 
> This is a known bug that definitely needs fixing:
> 
> (to ATA developers)
> Any time an ATA command is issued outside of the SCSI layer, we need to
> employ a timer to time out commands.
> 
> Since most commands are done within the SCSI layer, which provides a lot
> of error handling apparatus, most commands properly time out.  The ones
> during probe - IDENTIFY DEVICE, set xfer mode, etc. - do not have such a
> timer.

So is this an issue with the sata_promise.c driver, or the
libata-core.c?  Which one should implement the timeout?

What would you suggest as a workaround or a proper fix?

-- 
Jim Ramsay
"Me fail English?  That's unpossible!"