Subject: More info on scanner and Exabyte problem
To: None <netbsd-help@NetBSD.ORG>
From: david <david@mobtech.com>
List: netbsd-help
Date: 05/15/1996 15:41:06
I've worked on the system a bit more today, so here's some further info...

Here are the boot messages when the Exabyte drive has a tape in it...

aha0 at isa0 port 0x330-0x333 irq 11 drq 5: model AHA-1540A/1542A/1542B, firmware 1.4
(probe): aha_cmd, cmd/data port empty 7
(probe): aha_cmd, host not idle (0x24)
aha0: async, parity
aha0 targ 1: sync, offset 8, period 550nsec
aha0 targ 3: sync, offset 10, period 550nsec
aha0 targ 5: sync, offset 8, period 550nsec
aha0 targ 6: sync, offset 12, period 550nsec
aha0 targ 7: sync, offset 13, period 200nsec
(probe): aha_cmd, host not idle (0x24)
scsibus0 at aha0
probe(aha0:0:0): time outaha0: not taking commands!
panic: should call debugger here (aha1542.c)

Does the Exabyte perhaps need an entry in the quirky devices list? Or is
that useless because it hasn't been detected at this stage.

Again, ejecting the tape makes the system bootable, and I found two problems
and fixed them. The scanner on the machine is a newer model than recognized
by the table in ss.c, (I'll sendpr the diff) building a new kernel with
that change made the ss0 device appear during autoconf.
Secondly, the major device number for the ss devices changed between the
patches to 1.0A and 1.1B, from 18 to 19, so I have to mknod new /dev entries.

Looks like things are great hmm? ;-) Well - almost.

The 'get_scanner' and 'set_scanner' utilites (ioctl calls) work fine, but
when I tried to read from the device (dd if=/dev/scan0 is what's actually
used by the grabscan utility) I got (on console...)

panic: vref used where vget required
syncing disks...

I have a couple of ideas and I'm about to go grep crazy on /usr/src/sys,
but more educated guesses would be great :-)

							David Maxwell
							david@mobtech.com