Hi,

On Sat, Nov 08, 2003 at 02:47:20AM -0000, briggs@ninthwonder.com wrote:
> >Environment:
> NetBSD  1.6ZE NetBSD 1.6ZE (IQ80321) #0: Fri Nov  7 17:05:49 EST 2003
> Machine arch: arm
> Machine: evbarm
> >Description:
> 	Using a Silicon Image 3112 adapter with one Maxtor 6Y080M0 SATA
> 	disk attached, I get hard hangs (like can't break into DDB) when
> 	I try to access the disk after boot.  For example, if I run
> 	'disklabel wd0', the machine locks up solid.
> 
> 	cmdide0 at pci0 dev 6 function 0
> 	cmdide0: Silicon Image SATALink 3112 (rev. 0x01)
> 	cmdide0: bus-master DMA support present
> 	cmdide0: primary channel wired to native-PCI mode
> 	cmdide0: using irq 29 for native-PCI interrupt
> 	atabus0 at cmdide0 channel 0
> 	cmdide0: secondary channel wired to native-PCI mode
> 	atabus1 at cmdide0 channel 1 
> 	wd0 at atabus0 drive 0: <Maxtor 6Y080M0>
> 	wd0: drive supports 16-sector PIO transfers, LBA addressing
> 	wd0: 78167 MB, 158816 cyl, 16 head, 63 sec, 512 bytes/sect x 160086528 sectors
> 	wd0: 32-bit data port
> 	wd0: drive supports PIO mode 4, Ultra-DMA mode 6 (Ultra/133)
> 	wd0(cmdide0:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA data transfers)
> 
> 	If I drop into DDB before that point and set wdcdebug_mask to 0xff,
> 	it works fine.  If I set it to anything except 2, in fact, it
> 	seems to work.  When I use 2, I get:
> 
> 		wdc_exec_xfer 0xc12e0000 channel 0 drive 0
> 		wdcstart from wdc_exec_xfer, flags 0x0
> 		wdcstart: xfer 0xc12e0000 channel 0 drive 0
> 		wdc_exec_xfer 0xc12e0000 channel 0 drive 0
> 		wdcstart from wdc_exec_xfer, flags 0x0
> 		wdcstart: xfer 0xc12e0000 channel 0 drive 0
> 		<hang>

Did you try each bit individually ?
Only the first 7 four bits are used.


> 
> 	This controller still has the 31s timeout on the empty channel,
> 	for what that's worth.

On i386 too ?
Anyway, for SATA the probe probably needs to be reworked (use the PHY
status instead)

> 	It does, however, work fine on a kernel from sources updated with:
> 	$ cvs -q up -PdA -D"2003/10/08 06:00:00"
> 	(just before the ATA mid-layer commits from bouyer)
> 
>       [...]
> 	This suggests to me that there is some condition tickled by the
> 	introduction of the mid-layer.  It's not clear, however, if it's
> 	a platform-specific error, a timing error, or what.

I guess a timing problem. 

Can you try to see if it hangs in the
	if (__predict_false(drvp->state < READY)) {
block, or later ?
Maybe set a breakpoint on cmdintr() too, in case it would be an
interrupt loop.

> 
> 	A Promise PATA (Ultra100TX2) seems to work fine with old and new
> 	kernels--although it appears to want to drop back to Ultra/33
> 	when I request a disklabel (on older and current kernels).

Both on i386 and evbarm ?

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 23 ans d'experience feront toujours la difference
--