Re: jmide regression on amd64/current

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Thu, Mar 27, 2008 at 06:21:38PM -0700, Scott Ellis wrote:
> After noticing an issue with not being able to set the MTU on my msk(4) 
> (I think the arguments in ifioctl_common() are reversed, but that's 
> another story), I figured I'd update from Feb 11 -current amd64 to today 
> (March 27).  Upon doing so, I find that the drive connected to jmide0 no 
> longer is attached correctly.
> 
> Using the Feb 11 kernel, I see:
> 
> [...]
> jmide0 at pci5 dev 0 function 0: vendor 0x197b product 0x2363
> jmide0: 1 PATA port, 2 SATA ports
> jmide0: interrupting at ioapic0 pin 17 (irq 10)
> ahcisata0 at jmide0
> ahcisata0: AHCI revision 1.0, 2 ports, 32 command slots, features 0xc722e000
> atabus0 at ahcisata0 channel 0
> atabus1 at ahcisata0 channel 1
> jmide1 at pci5 dev 0 function 1: vendor 0x197b product 0x2363
> jmide1: 1 PATA port, 2 SATA ports
> jmide1: interrupting at ioapic0 pin 18 (irq 0)
> jmide1: PCI IDE interface used
> jmide1: device disabled (at device)
> [...]
> wd0 at atabus1 drive 0: <WDC WD5000YS-01MPB0>
> wd0: drive supports 16-sector PIO transfers, LBA48 addressing
> wd0: 465 GB, 969021 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168 sectors
> wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
> wd0(ahcisata0:1:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 
> (Ultra/133) (using DMA)
> 
> 
> Updating to the March 27th kernel instead yields:
> 
> [...]
> wd0d: device timeout reading fsbn 0 (wd0 bn 0; cn 0 tn 0 sn 0), retrying
> ahcisata0 port 1: device present, speed: 3.0Gb/s
> wd0d: device timeout reading fsbn 0 (wd0 bn 0; cn 0 tn 0 sn 0), retrying
> ahcisata0 port 1: device present, speed: 3.0Gb/s
> [...]
> 
> This continues forever, which is less than satisfying. :-)  Looking at 
> changes to jmide.c, I don't see anything immediately obvious, but I'm 
> not sure about the SATA DVD changes that went in.  They look fine, but 
> that's where my eye is drawn.
> 
> Any ideas here?  (The drive really is alive...booting back on the Feb 11 
> kernel makes it come alive and behave fine.)

Looks like an interrupt issue (the driver's interrupt handler may not be
called). Did the boot message about jmide* interrupts
change between the two kernels ?

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