Messages in this thread | | | Date | Mon, 23 Mar 1998 07:48:22 -0600 (CST) | From | Doug Ledford <> | Subject | Re: SCSI deadlock |
| |
On Mon, 23 Mar 1998, Roland Hautz wrote:
> 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
| |