Re: "scsi bus continuously busy"
On Sat, May 02, 2020 at 10:22:02AM -0700, Alan Perry via cctalk wrote: > >sc0 at vme24d16 20 vec 0x40 > >sd0 at sc0 slave 0 > >si0: sc_cmd: scsi bus continuously busy > >sc0: resetting scsi bus > >sd1 at sc0 slave 1 Not that I know these particular devices, but is it at all possible one of the cables is in backwards? That sounds like the kind of behaviour you get with 50-pin SCSI if an IDC connector is upside down. But otherwise, this message presumably means the host controller is sensing BSY# asserted when it didn't expect it. So the first order of business would be to find out whether BSY# on the bus is genuinely low. If not, it must be a controller fault. If yes, disconnect the devices one at a time and see if the problem goes away. If it's still stuck low with no devices attached, the issue is either in the controller or termination. p.
Re: "scsi bus continuously busy"
On May 2, 2020, at 12:22 PM, Alan Perry via cctalk wrote: > Are these boards picky about SCSI devices? I believe that the Sun-2 SCSI card only supports devices that support "Unit Attention".
Re: "scsi bus continuously busy"
On 5/2/20 10:44 AM, Warner Losh wrote:
On Sat, May 2, 2020 at 11:22 AM Alan Perry via cctalk
mailto:cctalk@classiccmp.org>> wrote:
Courtesy of a Raspberry Pi serving as the ND server, I am now able to
load SunOS 3.5 over the network onto my 3/260 and it is now coming up
into the OS. I am now seeing this error:
>sc0 at vme24d16 20 vec 0x40
>sd0 at sc0 slave 0
>si0: sc_cmd: scsi bus continuously busy
>sc0: resetting scsi bus
>sd1 at sc0 slave 1
>si0: sc_cmd: scsi bus continuously busy
>sc0: resetting scsi bus
The SCSI controller is the "Sun 2" SCSI card. I saw some corrosion-ish
crap on the board and cleaned it off. It is SCSI, so, of course, I
played with termination. No change in behavior.
Is this likely to be a controller board problem or a device problem?
Are these boards picky about SCSI devices?
_Any other suggestions?_
This comes from code:
/* wait for scsi bus to become free */
for (j = 0; j < SI_WAIT_COUNT/4; j++) {
if ((SBC_RD.cbsr & SBC_CBSR_BSY) == 0)
goto SI_ARB_SEL_FREE;
...
}
printf("si%d: si_arb_sel: scsi bus continuously busy\n",
SINUM(c));
So the busy bit is stuck on and there's no reselect that happens. The
chip in question is NCR 5380 SBC. This is a phase issue on the bus.
After 10s the busy bit in this controller didn't clear. I didn't look it
up, but I'll wager that's the BSY bit on the bus not clearing. This
suggests an electrical issue (maybe termination, maybe not, so not
surprised it didn't help since this is a signal line, not a data line).
Does this happen with no devices on the bus?
sc0 at vme24d16 20 vec 0x40
sd0 at sc0 slave 0
sd1 at sc0 slave 1
sd2 at sc0 slave 8
st0 at sc0 slave 32
st1 at sc0 slave 40
zs0 at obio 2 pri 3
zs1 at obio 0 pri 3
ie0 at obio c pri 3
bwtwo0 at obmem ff00 pri 4
bwtwo0: resolution 1152 x 900
sd0: scsi bus failure
sc0: sd0, unit offline
sd0: scsi bus failure
sc0: sd0, unit offline
root on nd0
Warner
Re: "scsi bus continuously busy"
On Sat, May 2, 2020 at 11:22 AM Alan Perry via cctalk
wrote:
> Courtesy of a Raspberry Pi serving as the ND server, I am now able to
> load SunOS 3.5 over the network onto my 3/260 and it is now coming up
> into the OS. I am now seeing this error:
>
> >sc0 at vme24d16 20 vec 0x40
> >sd0 at sc0 slave 0
> >si0: sc_cmd: scsi bus continuously busy
> >sc0: resetting scsi bus
> >sd1 at sc0 slave 1
> >si0: sc_cmd: scsi bus continuously busy
> >sc0: resetting scsi bus
>
> The SCSI controller is the "Sun 2" SCSI card. I saw some corrosion-ish
> crap on the board and cleaned it off. It is SCSI, so, of course, I
> played with termination. No change in behavior.
>
> Is this likely to be a controller board problem or a device problem?
>
> Are these boards picky about SCSI devices?
>
> *Any other suggestions?*
This comes from code:
/* wait for scsi bus to become free */
for (j = 0; j < SI_WAIT_COUNT/4; j++) {
if ((SBC_RD.cbsr & SBC_CBSR_BSY) == 0)
goto SI_ARB_SEL_FREE;
...
}
printf("si%d: si_arb_sel: scsi bus continuously busy\n",
SINUM(c));
So the busy bit is stuck on and there's no reselect that happens. The chip
in question is NCR 5380 SBC. This is a phase issue on the bus. After 10s
the busy bit in this controller didn't clear. I didn't look it up, but I'll
wager that's the BSY bit on the bus not clearing. This suggests an
electrical issue (maybe termination, maybe not, so not surprised it didn't
help since this is a signal line, not a data line).
Does this happen with no devices on the bus?
Warner
"scsi bus continuously busy"
Courtesy of a Raspberry Pi serving as the ND server, I am now able to load SunOS 3.5 over the network onto my 3/260 and it is now coming up into the OS. I am now seeing this error: >sc0 at vme24d16 20 vec 0x40 >sd0 at sc0 slave 0 >si0: sc_cmd: scsi bus continuously busy >sc0: resetting scsi bus >sd1 at sc0 slave 1 >si0: sc_cmd: scsi bus continuously busy >sc0: resetting scsi bus The SCSI controller is the "Sun 2" SCSI card. I saw some corrosion-ish crap on the board and cleaned it off. It is SCSI, so, of course, I played with termination. No change in behavior. Is this likely to be a controller board problem or a device problem? Are these boards picky about SCSI devices? Any other suggestions? alan
