<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi again
<p>Have tried disabling the MMAPIO as suggested and that seems to
have done the trick :-) Many thanks.
<p>I don't know whether you feel it's worth building in some checks
so that these 3940s don't break - The BIOS on mine are 1.24, maybe this
has been superceded with one that does work.
<p>If there's any info that would help....
<p>Nick
<br>---
<p>Doug Ledford wrote:
<blockquote TYPE=CITE>Nick Taylor wrote:
<br>>
<br>> Hi
<br>>
<br>> I am still seeing 3940 problems, I get a similar lock up. For me
it is as
<br>> soon as I try to access 2 hds at the same time.
<br>>
<br>> However it appears that not all 3940Ws fail as some people have indicated
<br>> that they are using them OK.
<br>>
<br>> My problem also appeared with kernel 2.0.36, 2.0.33 being OK. I am
also
<br>> convinced that something has been broken, but sadly am not a C hacker
so
<br>> don't know how this problem can be resolved.
<br>>
<br>> Nick
<br>> ---
<br>>
<br>> Stephan Loescher wrote:
<br>>
<br>> > Hi!
<br>> >
<br>> > 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.
<br>> >
<br>> > 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!
<br>> >
<br>> > 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.
<br>> >
<br>> > 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)
<br>> >
<br>> > 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.
<br>> >
<br>> > 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:
<br>> >
<br>> > 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!
<br>> >
<br>> > 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.)
<br>> >
<br>> > What was changed in the aic7xxx-code after 5.0.10/3.2.2?
<br>> >
<br>> > What can I do to help you finding the bug?
<br>> >
<br>> > Stephan.
<p>OK, I must have missed this report somehow. Anyway, the big item
of change
<br>between the 5.0.10 and later versions is that all later versions default
to
<br>using MMAPIO instead of PIO. So, if you want to test things out,
go into the
<br>aic7xxx.c file, find the line that reads:
<p>#define MMAPIO
<p>and comment that line out then recompile. That should disable
MMAPed I/O on
<br>your system and that will let us know if your problem is related to
<br>simultaneous I/O to different MMAP regions on the card. Note,
there may be
<br>more than one line of the #define MMAPIO in your source code, but assuming
you
<br>are using an Intel based machine, you need only find the one in the
#ifdef
<br>__i386__ block of code. You can ignore the other architectures.
I would give
<br>and exact line number, but depending on which patch you use this could
be
<br>greatly different as that section of code was in a state of flux during
the
<br>5.0.10->14 days.
<p>--
<br> Doug Ledford <dledford@redhat.com>
<br> Opinions expressed are my own, but
<br> they should be everybody's.
<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>