Hi Brad.
I cannot give You any immidiate soloution to You devious
problem, however, I CAN suggest that You try flashing
the mainboards BIOS. The VIA as well as ALI has experienced
many "childhood deceaces" which is often fixed by upgrading
the existing BIOS to a newer version.
Rearranging the cards on the PCI-bus can also produce positive
results. :-)
Good Luck!
// Henrik J.
P.S. The BIOS option might prove pointless since the Linux kernel
uses its own PCI-layer and therefore doesn't rely that much on
the BIOS specs. However, if the card gets gets improperly assigned
at startup, who knows how it will affect the initialization by
the Linux SCSI-subsystem driver. :_) .D.S.
On Thu, 4 Mar 1999, Bradley M. Kuhn wrote:
> I have spent nearly 60-80 hours debugging this problem, and I am not
> sure where to go from here. I humbly ask help from SCSI gurus here.
>
> I have a Tekram DC-390U2B/W card and a Seagate ST39175LW drive. It uses the
> ncr53c8xx. I am using Linux kernel 2.2.2, and the most recent ncr53c8xx
> driver (which is now called symb53c8xx version sym53c8xx/version 1.2a).
>
> I have made it so that these are the *only* two things on that SCSI card, to
> be sure that other items on the chain did not effect my operation.
>
> The Problem:
>
> The drive works for a while. Sometimes up to a few days. However, usually
> under some point of heavy load, the drive locks, with the I/O light on
> continuously, and the device driver on the system can no longer talk to it,
> giving a variety of timeout and other errors (see below for details). Only
> a hard reset of the system brings that SCSI bus alive again.
>
>
> I can always force this behavior by putting it under heavy load immediately
> upon booting.
>
> I know that there is nothing wrong with the driver. I even tried FreeBSD,
> but to know avail.
>
> Configurations I have tried;
>
> 0. Using the special red-white-blue LVD cable that came with the card, I
> hooked the terminator that came with the Tekram card (labeled SCSI LVD/SE
> Terminator) to the end of that red-white-blue LVD cable, and put the
> drive in between the terminator and the card. (THIS IS THE CANONICAL,
> CORRECT CONFIGURATION, I have been told).
>
> 1. I tried using configuration (0), with the drive's internal termination on
> (I realize this does nothing for LVD drives, according to spec, but I was
> desperate).
>
> 2. I tried using plain 68 pin Ultra cable, with the drive's internal
> termination on and the drive in *forced* SE mode (using another jumper),
> and reproduced the problem.
>
> 3. I tried (2), with the drive's internal termination *off* and the LVD/SE
> terminator mentioned in (0) on the chain.
>
> All of these produced similar results---works for a while, then fails
> in the manner described. In almost all cases, it severely corrupts the
> ext2fs almost beyond repair.
>
> Before the crash, the messages in the log look something like (sometimes it
> happens so fast there are no messages at all):
>
> kernel: scsi : aborting command due to timeout : pid 96752, scsi1, channel 0, id 0,
>lun 0 Write (6) 00 00 5f 02 00
> kernel: ncr53c8xx_abort: pid=96752 serial_number=96772 serial_number_at_timeout=96772
> kernel: scsi : aborting command due to timeout : pid 96759, scsi1, channel 0, id 0,
>lun 0 Write (6) 00 80 89 02 00
> kernel: ncr53c8xx_abort: pid=96759 serial_number=96779 serial_number_at_timeout=96779
> kernel: scsi : aborting command due to timeout : pid 96760, scsi1, channel 0, id 0,
>lun 0 Write (6) 00 81 8b 02 00
> kernel: ncr53c8xx_abort: pid=96760 serial_number=96780 serial_number_at_timeout=96780
> kernel: ncr53c875-0: abort ccb=c60ce800 (cancel)kernel: SCSI host 1 abort (pid
>96630) timed out - resetting
> kernel: SCSI bus is being reset for host 1 channel 0.
> kernel: ncr53c8xx_reset: pid=96630 reset_flags=2 serial_number=96650
>serial_number_at_timeout=96650
> kernel: ncr53c875-0: restart (scsi reset).
> kernel: ncr53c875-0: Downloading SCSI SCRIPTS.
> kernel: ncr53c875-0-<0,*>: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 15)
>
>
> (Note these occured when I had it connected as plain Ultra chain---similar
> things happen in LVD mode)
>
> Once, I even got these, which were really strange:
>
> kernel: ncr53c875-0-<0,0>: phase change 2-7 10@07fe0645 resid=16711926.
> kernel: ncr53c875-0-<0,0>: phase change 2-7 10@07fe0645 resid=4.
>
>
> OTOH, a friend of mine with a plain *Ultra* chain put the drive on his
> machine in the middle of the chain (between other devices), and is not
> able to reproduce the problem.
>
> He also used *my card* in his machine, without being able to reproduce the
> problem.
>
> It is *not* a software problem. I have spent a long time exchanging email
> with the very helpful author of the driver, and we are sure it isn't
> software. Plus, I tried installing FreeBSD, and got similar results.
>
> Here is my current thinking on what the problem might be (some of these are
> suggestions from comp.periphs.scsi):
>
> (a) I am running my bus at too fast a rate (100 MhZ). However, I have
> been able to use other cards, even another older SCSI card in that bus
> at that speed. Plus, there is no way (according to my FIC PA-2013
> manual) to use my AMD K6-2/350 at proper speed without the 100 MhZ
> bus.
>
> (b) bad PCI bus/bad PCI slot [0]
>
> (c) bad terminator (being tested in my friends machine now). I don't
> think this is it, though, because the terminator was new.
>
> (d) insufficient power (is there a way I can test this?) I don't think
> this is a problem because I have an expensive server case with a good
> power supply.
>
>
> I believe I am doing things right. I hope you all can help me...
>
>
> [0] can
>
> --
> Bradley M. Kuhn | [EMAIL PROTECTED] | http://www.ebb.org/bkuhn
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
