Subject: Re: Patch for recent ncr.c lossage / not just ncr.c
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Erik Bertelsen <erik@mediator.uni-c.dk>
List: current-users
Date: 10/16/1999 23:44:42
On Sat, Oct 16, 1999 at 11:18:27AM -0700, Jason Thorpe wrote:
> On Sat, 16 Oct 1999 11:08:10 +0200 
>  Erik Bertelsen <erik@mediator.uni-c.dk> wrote:
> 
>  > Sigh :-(
> 
> Yah, I know.
> 
> Do me a favor, and set the "ncr53c9x_debug" variable in ncr53c9x.c so that
> you can get a trace of that driver's activity?  The mid-layer, according
[also suggested by Allen Briggs]

Setting ncr53c9x_debug to 0x3ff (covering all flags as far as I could read)
gives the following boot messages:


...
esp0 at obio0 (quick): address 0x8b0000: NCR53C96, 16MHz, SCSI ID 7
[NCR_INIT(1)] <cmd:0x2><cmd:0x0><cmd:0x3>scsibus0 at esp0: 8 targets, 8 luns per target
...
   several lines about zsc0 and zstty0 and 1
...
nubus0 at mainbus0
fpu0 at mainbus0 (mc68040)
scsibus0: waiting for 2 seconds for devices to settle...
[ncr53c9x_scsi_cmd] [0x0, 6]->0 

and that's it -- here the machine hangs still.

Pressing the debug button and doing a t command to ddb gives

_cpu_Debugger
_nmi_hand
_lev7intr
_mi_switch
_tsleep
_scsipi_execute
_scsi_scsipi_cmd(1026a80, 183ea2,6,0,0)
_scsipi_test_unit_ready
_scsi_probedev
_scsi_probe_bus
_scsibus_config_interrupts
_config_process_deferred
_configure
panic: lockmgr: no context



- Erik