> On Sun, 22 Mar 1998, Doug Ledford wrote:
>
> > Roland Hautz wrote:
> >
> > > logs, again reading "kernel: (scsi0:0:0) Target busy". The nmi-oops
> > ^^^^^^^^^^^^^^^^^^^^^^
> >
> > Didn't you say this drive is a Barracuda? If so, that message is
> > troublesome. I never see Barracuda drives cause that message unless they
>
> Not exactly. It's a Cheetah 4.3 GB :
> Vendor: SEAGATE Model: ST34501W Rev: 0018
Close enough, you shouldn't ever get Target BUSY messages frmo one of
those. They usually only happen with the cheaper SCSI drives that have
bad firmware or poor design.
> The drive is only 2 weeks old. And there would be a couple of damaged
> sectors, because it happens while reading at different locations.
>
> > change the tar command to tar -cvf - . so that it prints the file names as
>
> Thank you, I'll try it.
Well, it could happen at more than one place, the more interesting item is
if it happens on any particular file, then does it *always* happen on that
file. IOW, if you run the tar command and it locks on a particular file,
then after a reboot, will the machine lock if you try to read just that
one file by doing something like copying that one file to the /tmp
directory. If so, then it's probably a bad sector problem. If not, then
it's likely something else.
> So it is not worth trying a 5.0.x driver version with kernel 2.1.90?
I wouldn't say that :) The 5.0.x drivers are still better than the 4.1
driver that ships in 2.1 IMHO, I just can't test them out to verify
certain things that I'm not positive will work the way I intended them to
work under 2.0.
> Kernel panic aic7xxx: (aic7xxx-queue) Couldn't find a free SCB.
>
> That line came 3 times. Should I try different compile time options for
> the aic7xxx driver?
That's a long standing problem of the 4.1 aic7xxx driver. If the systems
fail to allocate the requested memory (most likely, an 8K allocation) then
it causes a panic. It only happens if the SCSI bus activity increases
enough to cause extra SCBs to get allocated, so it can usually be avoided
by immediately hitting all devices on your SCSI bus with a full load of
commands at boot up so that all of the possible SCBs get allocated before
memory fragmentation and/or usage becomes a problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu