That error you report, about the newer SBC kernels freezing at sbc0 at
obio line...that's been reported more than twice :) I experience the same
exact thing...

Try using GENERICSBC #26...but, to tell you the truth, that drive may be
too far gone. You may have lost the info there. I'm not too experienced
with NetBSD, especially the technical stuff like this situation is, but
you may have to end up re doing the formating on whatever drive is hosed
(the DAT or the other?), re-installing the binary, and using GENERICSBC
#26 or older.

For the kernel people out there, the exact error is something like "sbc0
at obio=<PDMA1>" or something similar...I remember an equal sign, and
stuff in brackets like that...I think there was a 1, and I am definate
there was a P :)

So, what's causing this? Can it be fixed? Anything GENERICSBC #27 and up
causes this error...

Hope this helps, and thanks for any help on my question :)

Josh

On Sat, 9 Aug 1997, Sean Sweda wrote:

> 
> Background:  I've been running NetBSD on a Mac IIvx with a Daystar
> 040 accelerator in it since January.  I didn't have time to actively
> track -current for a long time, but the last fully functional kernel
> I compiled from -current was from 1.2B with the sbc scsi driver.
> By fully functional I mean that the machine boots and I can use
> a DAT tape drive (actually its a 4 tape changer).
> 
> Sometime in April I upgraded the binaries using a snapshot 
> (probably 1.2D if I remember correctly), and the sbc kernels I compiled
> would no longer boot (just hang at "sbc0 at obio").  No problem,
> I just switched to an ncrscsi kernel, and everything was fine.
> 
> Or so I thought.  Apparently the DAT drive does not like the ncrscsi
> kernel.  I didn't find that out until last week when I upgraded the
> binaries again, and then tried to restore some info from tape.
> It crapped out with a scsi error (something like "illegal request
> data 00 00 00 00) and complained about not being able to set the
> right mode.  Sorry for the vagueness, I don't have the tape drive
> attached at the moment.
> 
> At any rate, I can't even get a -current ncrscsi kernel to boot, it
> just panics when trying to mount the root filesystem:
> (-current from 8/8, snapshot from 6/10)
> 
> root on sd0a dumps on sd0b
> pdma in:cnt=-8146939 (0xff83b005) (pending cnt 32)
> 
> trace gives:
> 
> do ncr5380_drq_intr
> ncr5380_drq_intr
> rbv_intr
> lev2_intr
> mi_switch
> tsleep
> scsi_execute_xs
> scsi_scsi_cmd
> scsi_prevent
> sdopen
> sdsize
> cpu_dumpconf
> main
> 
> 
> Any ideas?
> 
> Oh, and one more question.  A while back, we played around with putting
> the Daystar 040 into a Mac IIci.  It wouldn't last very long because
> the IIci had non-contiguous memory, but the 040 MMU mapping code
> had no provisions for non-contiguous memory.  I believe we tried hard
> coding the memory, as an ugly hack, but never really tested the kernel.
> Anyways, is this still a problem?
> 
> 
> Sean
> 
> __________________________________________________________________________
> Sean Sweda                        :            Owner, Motor City Marauders
> sweda@us.itd.umich.edu            :   1994 Internet Baseball League Champs
> http://www.ibl.org/~sweda         :                     http://www.ibl.org
> __________________________________________________________________________
>