This message was just bounced, host netbsd.org unknown, Valid name but no A or
MX, I can't see anything wrong with the MX record now, so I'm trying again...


On Feb 19, 16:16, Sean Murphy wrote:
> Subject: SCSI problems
> I am currently running 1.1 on my SE/30 8/200 and have been trying to add
> another partion off of a 200 meg SyQuest drive.  I partitioned the SyQuest
> drive so that almost all of it was a Usr partition and then ran Mkfs on it
> using the default values.  I can get it to mount, but then as soon as I try
> to do anything with it it hangs with the drive access light on.  I am using
> netbsd.scsi kernel, because I also has this happen with the netbsd11 kernal
> with my regular HD, but as soon as I put netbsd.scsi in that stopped.  To
> make a long confusing explantion short, what kernel should I be using or
> doesn't NetBSD support SyQuest drives?

OK, I'm seeing the same problems with fairly recent (within last two days)
-current kernels and a ZIP drive. I've been looking at this, but not getting
very far as the students are coming back on Monday, and I've got a few little
jobs to do. What I've found so far seems to indicate that the dirve is fine in
single user mode, with raw reads and writes of any size, I can dd files on and
off the cartridge just fine, and I can read and write whole cartridges of junk
without any problems. When I'm in multiuser and running X, with a filesystem on
a cartridge, any write to the disk appears to wedge the machine somehow. If I
drop into the debugger, It locks up pretty quickly (sometimes trace only gives
me the _Debugger line before hanging hard).

I'm not sure that the machine is actually hanging on the disk, as the network
still seems to be there at a low level. The machine has a relatively permanent
PPP link (not active in single user tests above), which still shows keepalive
traffic and is pingable while the console is unresponsive. I'm going to put a
serial terminal on the other port tonight so that I can have another local
interface to hopefully have a look around the next time it happens. From the
little I can tell, it looks like the problem is a wedge in the file system/SCSI
that's stopping processes from starting and possible stopping swapping.

The other thing I will try sometime when I'm feeling gutsy is power cycling
things on the SCSI bus to see if it's one of the disks going into never never
land as used to happen with the tape drive on an Ultrix machine I had to
manage, power cycling the offending device would suddenly bring the machine
back to life with a flurry of CAM SCSI messages.

Bernard.