Re: RFC: ATA to CAM integration patch

On Jul 4, 2009, at 5:20 AM, Alexander Motin <mav_at_FreeBSD.org> wrote:

> Mike Tancsa wrote:
>> On the ich10 board, its trying to boot up now, but I am getting
>> uhub8: 4 ports with 4 removable, self powered
>> (probe2:ahcich2:0:0:0): SIGNATURE: eb14
>> run_interrupt_driven_hooks: still waiting after 60 seconds for  
>> xpt_config
>> ahcich2: Timeout on slot 4
>> run_interrupt_driven_hooks: still waiting after 120 seconds for  
>> xpt_config
>> ahcich2: Timeout on slot 5
>> run_interrupt_driven_hooks: still waiting after 180 seconds for  
>> xpt_config
>> ahcich2: Timeout on slot 6
>> run_interrupt_driven_hooks: still waiting after 240 seconds for  
>> xpt_config
>> ahcich2: Timeout on slot 7
>> run_interrupt_driven_hooks: still waiting after 300 seconds for  
>> xpt_config
>> ahcich2: Timeout on slot 8
>> ada0 at ahcich1 bus 0 target 0 lun 0
>> ada0: <ST3500410AS CC34> ATA/ATAPI-8 SATA 2.x device
>> ada0: 300.000MB/s transfers
>> ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
>> ada0: Native Command Queueing Enabled
>
> I've found how to make this DVD work. It refused to process PACKET  
> command until I have explicitly set it's PATA-legacy transfer mode  
> to the maximal supported.
>
> %camcontrol devlist
> <ST3500410AS CC34>                 at scbus0 target 0 lun 0  
> (pass0,ada0)
> <MATSHITA DVD-ROM UJDA780 1.50>    at scbus2 target 0 lun 0  
> (cd0,pass1)
>
> Patch committed to P4.
>
> -- 
> Alexander Motin

I mentioned this a few months ago.  Both atapi and ata devices need a  
state machine to set their max transfer parameters, regardless if they  
are sata or pata.  Newer sata devices might not need it, but older  
ones definitely do.  IMHO, it's easiest to just do the negotiation for  
all sata devices instead of trying to be selective about it.

Scott