On Mon, 3 Jan 2005, Johnny Billquist wrote:

> On Mon, 3 Jan 2005, Kirk Russell wrote:
>
> > Hello,
> >
> > I am trying to debug why the RX50 driver worked with 1.6 but stopped
> > working with 1.6.X:
> > 	http://mail-index.netbsd.org/netbsd-bugs/2004/07/02/0000.html
> >
> > The problem appears to be with the file src/sys/dev/mscp/mscp_disk.c.
> > With 1.6.X, the kernel will crash with version 1.30.10.1, but appears
> > to work okay with version 1.30.
>
> How do you know that file is the culprit? Didn't any other file change
> between 1.6 and 1.6.X?

Just a guess.  I incrementally backed out of 1.6.1 changes until the
kernel stopped faulting.  The whole sys/arch/vax tree made no difference.
But 1.30.10.1 vs 1.30 of mscp_disk.c does make a difference.  Very brute
force :-)

> > Here are the diffs:
> > 	http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/mscp/mscp_disk.c.diff?r1=1.30&r2=1.30.10.1&f=h
> >
> > So, using version 1.30 is my work-a-round.  Does anybody know what the fix
> > is?  It appears that these extra calls to disk_busy() and disk_unbusy()
> > are causing problems.  TIA.
>
> disk_busy() and disk_unbusy() would be very weird if they caused any
> problems...

I noticed that disk_busy() uses ra->ra_disk or rx->ra_disk.  But
disk_unbusy() only uses ra->ra_disk.  Is that an issue?  I know nothing
about this, but just noticed that lack of symmetry :-)

> Hmm, when the system crash, what does a backtrace say?

Using 1.6.1 with simh (from bug report port-vax/26138):

    simhvax# cksum /dev/rx0a
    ra0: dk_busy < 0
    panic: disk_unbusy
    Stopped at      disk_unbusy+0x37:       mfpr    $18, r2
    db> trace
    panic: disk_unbusy
    Stack traceback :
    0x80353ab8: disk_unbusy+0x37(0x885e1c2c,0x800)
    0x80353b14: rriodone+0x44(0x885e1900,0x89a124c8)
    0x80353b34: mscp_dorsp+0x32b(0x885dfc00)
    0x80353b6c: mscp_intr+0x23(0x885dfc00)
    0x80353ba0: udaintr+0x24(0x885d4d00)
    0x80353bc4: eidsptch+0x17(0x8061ea80)
    0x8a9b6cf8: bpendtsleep+0x0(0x89a124c8,0x11,0x8015a46f,0,0)
    0x8a9b6d24: biowait+0x28(0x89a124c8)
    0x8a9b6d68: bread+0x6a(0x816dbd78,0,0x800,0xffffffff,0x8a9b6dcc)
    0x8a9b6d8c: spec_read+0x16c(0x8a9b6e28)
    0x8a9b6dd8: ufsspec_read+0x33(0x8a9b6e28)
    0x8a9b6e0c: VOP_READ+0x3f(0x816dbd78,0x8a9b6eb8,0,0x88634200)
    0x8a9b6e3c: vn_read+0x78(0x80683340,0x80683368,0x8a9b6eb8,0x88634200,0x1)
    0x8a9b6e64: dofileread+0x79(0x8061ea80,0x3,0x80683340,0x7fffbbac,0x4000,0x8
0683368,0x1,0x8a9b6f58)
    0x8a9b6ed8: sys_read+0x43(0x8061ea80,0x8a9b6f60,0x8a9b6f58)
    0x8a9b6f20: syscall+0x103(0x8a9b6fb4)
    db>

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