<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi
<p>I am still seeing 3940 problems, I get a similar lock up. For me
it is as soon as I try to access 2 hds at the same time.
<p>However it appears that not all 3940Ws fail as some people have indicated
that they are using them OK.
<p>My problem also appeared with kernel 2.0.36, 2.0.33 being OK. I am
also convinced that something has been broken, but sadly am not a C hacker
so don't know how this problem can be resolved.
<p>Nick
<br>---
<p>Stephan Loescher wrote:
<blockquote TYPE=CITE>Hi!
<p>I have found a bug, that appeares first in the aic7xxx-Code in Linux
<br>2.0.34 (5.0.14/3.2.4) and is there up to recent 2.3.xx-kernels! The
<br>aic7xxx-Code in Linux 2.0.33 (4.1.1/3.2.1) runs stable for me.
<p>The sympoms:
<br>When I copy a lot of large files from my harddisk (IBM DCAS-34330W)
to
<br>my magneto-optical (MO) drive, then after some time (5 seconds to
<br>several minutes) the Linux kernel stops. The system is freezed (locked
<br>up) and the SCSI-bus led, the MO-led and the harddisk-led is lighting.
I
<br>can´t log into my system. Mouse and keyboard are "dead".
<br>The source-and target-filesystems are ext2.
<br>I can reproduce this behaviour.
<br>I can copy files between all my harddisks without any error.
<br>With kernel 2.0.33 there are no problems!
<p>I nailed it down with linux/Documentation/BUG-HUNTING to the
<br>aic7xxx-Code, because when I replace the aic7xxx-files in 2.0.34 with
<br>the files from 2.0.33, then the system runs stable.
<p>I have tried the following kernels:
<br>2.0.34
<br>2.0.35
<br>2.0.36
<br>2.1.128
<br>2.2.2
<br>2.2.5
<br>2.2.6
<br>2.2.7
<br>2.2.10
<br>2.3.4
<br>(with and without all AC-patches)
<p>Also disabling all aic7xxx-features does not help.
<br>I tried these options:
<br>aic7xxx=verbose, aic7xxx=pci_parity, aic7xxx=verbose:0x1ffff
<br>and disabled TAGGED_QUEUEING at all.
<p>To help you finding the bug, I tried all aic7xxx-patches for Linux
<br>2.0.33 from the last 4.x.x up to 5.0.13. The results are:
<p>5.0.0 /3.2.2: OK
<br>5.0.1 /3.2.2: does not boot, seems _very_ unstable
<br>5.0.10/3.2.2: OK
<br>5.0.11/3.2.2: Makes endless SCSI-resets after issuing commands like
<br>
echo "scsi remove-single-device 0 0 1 0 " >/proc/scsi/scsi
<br>5.0.12/3.2.2: locks up the system as 5.0.14 does!
<br>5.0.13/3.2.2: locks up the system as 5.0.14 does!
<p>My system:
<br>Pentium-200 (single-CPU)
<br>SCSI-HA: Adaptec 3490U, Bios 1.24
<br>Channel A:
<br>0 : CD Sony CDU-76S
<br>1 : HD Seagate ST32430N
<br>3 : CDRW Yamaha CRW4416S 1.0f
<br>4 : Streamer Tandberg NS20 Pro
<br>5 : HD IBM DCAS-34330
<br>6 : HD IBM DCAS-34330W
<br>(End of SCSI-bus with active termination, and AHA with auto-termination.)
<br>Channel B:
<br>0 : Olympus Deltis-MOS320 (MO)
<br>3 : HP ScanJet
<br>(End of SCSI-bus with passive termination, and AHA with auto-termination.)
<p>What was changed in the aic7xxx-code after 5.0.10/3.2.2?
<p>What can I do to help you finding the bug?
<p>Stephan.
<p>--
<br>loescher@leo.org
<br><a href="http://www.leo.org/~loescher/">http://www.leo.org/~loescher/</a>
<p>To Unsubscribe: send mail to majordomo@FreeBSD.org
<br>with "unsubscribe aic7xxx" in the body of the message</blockquote>
<pre>--
Nick Taylor <A HREF="mailto://nt@dataskill.co.uk">mailto://nt@dataskill.co.uk</A> Dataskill, London, England
<A HREF="mailto://webmaster@reflexology.org">mailto://webmaster@reflexology.org</A>
HOME OF REFLEXOLOGY <A HREF="http://www.reflexology.org">http://www.reflexology.org</A></pre>
</html>