Subject: SCSI trouble with newly supped kernel
To: None <port-mac68k@NetBSD.ORG>
From: Aaron S. Magill <amagill@uiuc.edu>
List: port-mac68k
Date: 02/20/1996 22:37:57
Ok, I have been using a kernel I downloaded around Feb 1 for awhile now, as
I can't get anything more recent to work with my hard drives.  As far as I
can tell, they are plain old run-of-the-mill SCSI hard drives.  I've been
trying to get a more recent kernel, because the one I downloaded Feb 1
doesn't work with my keyboard.  Since I started with the official 1.1
kernel, I was able to get a couple of serial port logins working, but I
really kind of need the adb keyboard working.

So, I set up sup about 2 weeks ago and started trying to recompile the
kernel about every 2 days, after supping the changes, hoping a newer kernel
would help.  Well, it does in the sense that the keyboard now works, if I
boot to single user mode, or if I go into the monitor (debugger?).
However, I have gotten a wide variety of responses to my SCSI drives since
I started with the newer kernels.  The latest kernel I tried was supped
last night.  Here is a snippit of the console output when I try to boot
with it:

ncrscsi0 at mainbus0
scsibus0 at ncrscsi0
ncrscsi0 targ 0 lun 0: <QUANTUM, LP240S GM240S01X, 6.3> SCSI2 0/direct fixed
scsi_inqmatch: 2/0/0 <, , >
sd0 at scsibus0: 234MB, 1818 cyl, 4 head, 65 sec, 512 bytes/sec
ncrscsi0 targ 1 lun 0: <MAXTOR, 7345-SCSI, 1761> SCSI1 0/direct fixed
scsi_inqmatch: 2/0/0 <, , >
sd0 at scsibus0: 329MB, 2220 cyl, 4 head, 76 sec, 512 bytes/sec
ncrscsi0 targ 2 lun 0: <QUANTUM, LP240S GM240S01X, 6.3> SCSI2 0/direct fixed
scsi_inqmatch: 2/0/0 <, , >
sd0 at scsibus0: 234MB, 1818 cyl, 4 head, 65 sec, 512 bytes/sec
ncrscsi96scsi0 at mainbus0 not configured
sbc0 at mainbus0 not configured
asc0 at mainbus0 Apple sound chip
fpu0 at mainbus0 (mc68882)
floppy0 at mainbus0 not configured
Changing root device to sd0a
I/O map kludge for old ROMs that use hardware addresses directly
PRAM: 0x312aadb7, macos_boottime: 0x312aada4
Automatic boot in progress: starting file system checks.
/dev/rsd0a: file system is clean; not checking
/dev/rsd0g: file system is clean; not checking


At this point, it hangs.  No debugger, no nuttin.

Something tells me that this isn't right... ;-)

The scsi_inqmatch lines started appearing about Friday (2/16/96).  Before
that, it would either crash into the debugger, or hang before mentioning
/dev/rsd0g.

Anyone got any ideas?  I am running this on a Mac IIx with 8 mb of memory,
the three drives mentioned above, (sd0 is split into 3 partitions, 1 mac, 1
/, and 1 /usr) while the other 2 are single partition drives.

The drives worked beautifully with the 1.1 kernel, and with kernel sources
downloaded about Feb 1 (maybe 2).  I wasn't using sup then, so I downloaded
the tree off of puma, I believe.

Any help would be appreciated.

Thanks!


--
Aaron Scott Magill                                             amagill@uiuc.edu
-------------------------------------------------------------------------------
}{  "I have SEEN evil!  I have SEEN horror!  I have seen the unholy maggots  }{
}{    which feast in the dark recesses of the human soul!  I have seen all   }{
}{  this, officer, but until today, I had never seen... YOU!" - Gomez Addams }{
-------------------------------------------------------------------------------