On Tue, Sep 09, 2003 at 05:13:48AM -0400, Thor Lancelot Simon wrote
(to tech-kern@netbsd.org):

> A number of disk device drivers use threads to manage bus events,
> for example the isp driver, the mlx and mly drivers, and the I2O
> drivers.

Sigh.  I'm pretty sure I was right about what was going on with isp,
in the fibrechannel machine at work, but what on earth is happening 
with mlx and i2o in my test machine at home, I couldn't say.

It's not what I thought it was, though -- I commented out the
mlx_periodic_thread and instead of getting messages from it about
software command timeouts etc. for every command, I just get a
dead silent hang.

DDB now shows only six processes running, all kernel processes,
at the point where it hangs:

PID		S	FLAGS		COMMAND		WAIT
5		2	0x20200		usbtask		usbtsk
4		2	0x20200		usb0		usbevt
3		2	0x20200		atapibus0	sccomp
2		2	0x20200		sysmon taskq	smtaskq
1		2	0		init		initexe
0		2	0x20200		swapper		biowait

The command that I _was_ getting an mlx timeout report about before
was an attempt to read ld1's disklabel.  It's almost as if all
disk interrupts are blocked and the init image can't be read in;
but how they'd get blocked at this point, and why adding the mlx
or iop card to a working system (the root fs is on ld0 on a 3ware
card) causes it is beyond me.

Anyone have any ideas?  The hardware's not particularly unusual,
an AMD760MPX machine with one processor, a gig of ram, the 3ware
card, and an intel GigE.  And it all works fine without the 
mlx/isp/iop.  Hm, perhaps the twe driver is forgetting to lower
the spl somewhere (but then why's it work with only the twe)?

Thor