Hi,

Frank Dana (danaf@cs.rpi.edu) wrote:
: With Shakespearian flourish, "Andre Schenk" writes:
: > 
: > I  am  not  sure  if this is a problem with the sbic driver but I
: > often  get  system  lookups,  especially under X.  Synchronous or
: > asynchronous  mode  -  no difference. 

: but if I
: leave X running overnight I'm almost sure to wake up to a frozen
: machine.

I had the same problem - when running NetBSD, the machine froze after an
unpredicatble amount of time (no panic, no output, just frozen). Both 1.0
and current had this problem.

After adding and removing lots of debug statements, I tracked the problem
down to an unexpected behaviour of the WD33C93A-PL 04PROTO, which was
placed on my GVP Series II host adapter. I've replaced the 04PROTO by a
00-08 and haven't had this freezing problem since then.

[ Well, first I got an used 00-08, which didn't work either (I didn't track
  down, why that one didn't work, but it must have been a different
  problem), but I've got two (for the moment) other 00-08, that do work ]

I heard from a friend, that a friend told him (and so on), that the 04PROTO
has a bug in its FSM, which sometimes make the chip freeze, when
disconnecting or reselecting scsi devices. Indeed, most of the time (I made
a lot test runs) the kernel froze in the first WAIT_CIP in sbicselectbus
(1.0 source). The asr register of the chip froze in state 0x30
(ASR_BUSY|ASR_CIP), so the kernel got into an endless loop.

IMHO, there should at least be some kind of debug output everywhere, where
an unexpected behaviour of the hardware could result in endless loops
(sbicwait for instance has such output statements).

BTW: The "Hard Disk" LED of A2000 did not shine, when this occured with the
     GVP Series II, but with a borrowed A2091 it did.

  Hans

--
Hans Maurer                        hans.maurer@informatik.tu-muenchen.de
                                   hans@leo.org      hans@mystery.muc.de