Hello,

I incrementally backed out of 1.6.1 changes until the kernel stopped crashing.
The whole sys/arch/vax tree made no difference.  But 1.30.10.1 vs 1.30 of
src/sys/dev/mscp/mscp_disk.c did make a difference -- with 1.6.X, the kernel
will crash with version 1.30.10.1, but appears to work okay with version 1.30.

Here are the diffs that added the bug into the 1.6.X tree:
	http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/mscp/mscp_disk.c.diff?r1=1.30&r2=1.30.10.1&f=h

It appears that rriodone() is shared by the ra and rx devices.  But
rriodone() only calls disk_unbusy() with the ra context but never the rx
context -- that cannot be a good thing.  But looking at the rrfillin()
routine -- it has code to distinguish between the ra and rx devices.  I
cut and pasted this code, from rrfillin(), into rriodone().  This added code
appears to stop the kernel from crashing.

Here are the diffs to mscp_disk.c verision 1.30.10.1, that I tried:

***************
*** 856,862 ****
        /* We assume that this is a reasonable drive. ra_strategy should
           already have verified it. Thus, no checks here... /bqt */
        unit = DISKUNIT(bp->b_dev);
!       ra = ra_cd.cd_devs[unit];
        disk_unbusy(&ra->ra_disk, bp->b_bcount);

        biodone(bp);
--- 856,869 ----
        /* We assume that this is a reasonable drive. ra_strategy should
           already have verified it. Thus, no checks here... /bqt */
        unit = DISKUNIT(bp->b_dev);
! #if NRA
!       if (major(bp->b_dev) == RAMAJOR)
!               ra = ra_cd.cd_devs[unit];
! #endif
! #if NRX
!       if (major(bp->b_dev) != RAMAJOR)
!               ra = rx_cd.cd_devs[unit];
! #endif
        disk_unbusy(&ra->ra_disk, bp->b_bcount);

        biodone(bp);

http://mail-index.netbsd.org/port-vax/2005/01/03/0000.html
http://mail-index.netbsd.org/port-vax/2005/01/03/0001.html
http://mail-index.netbsd.org/port-vax/2005/01/03/0002.html
http://mail-index.netbsd.org/port-vax/2005/01/03/0003.html
http://mail-index.netbsd.org/port-vax/2005/01/04/0000.html

-- 
Kirk Russell            <kirk@ba23.org>            http://www.ba23.org/
Bridlewood Software Testers Guild                  Ottawa Ontario Canada