From: Vincent Touquet <vincent.touquet@pandora.be>
To: joe briggs <jbriggs@briggsmedia.com>
Cc: vincent.touquet@pandora.be, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@osdl.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [Bug report] System lockups on Tyan S2469 and lots of io [smp boot time problems too :(]
Date: Tue, 8 Jul 2003 15:10:48 +0200 [thread overview]
Message-ID: <20030708131047.GG14044@ns.mine.dnsalias.org> (raw)
In-Reply-To: <200307080959.54247.jbriggs@briggsmedia.com>
On Tue, Jul 08, 2003 at 09:59:54AM -0400, joe briggs wrote:
>Vincent -
>I wonder if what is really happening is a problem in the in the arbitration
>between the PCI bus and the local bus that the onboard IDE devices are. In
>your case the problem (onboard IDE device data corruption) manifests when you
>are performing sustained transfers (large files) between the onboard IDE
>device and a PCI block device (the 3ware RAID).
Yes, that seems very feasible.
>In my case, the same problem
>manifests when I have sustained data activity from multiple frame grabbers to
>memory, then from memory to RAID. When the system drive is used (code load,
>swap, etc.) it gets corrupted. My point is, the onboard data device only
>seems to get corrupted when there is lots of i/o activity with PCI
>bus-masters that are DMA'ing data to/from memory. What do you think?
I had the same lockups too when pumping a lot of data over the network
onto the array on a similar mainboard (Tyan S2468). So maybe there is
the added problem that there is funny things going on on the PCI bus.
Maybe the problem only occurs when you stress the bus and the dma is not
the real culprit, it just enables high transfers and hence corruption on
the PCI bus.
I would very much like to nail this one down, as its nasty.
regards,
v
next prev parent reply other threads:[~2003-07-08 12:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-06 21:02 [Bug report] System lockups on Tyan S2469 and lots of io [smp boot time problems too :(] Vincent Touquet
2003-07-07 0:30 ` Vincent Touquet
2003-07-07 0:52 ` Andrew Morton
2003-07-07 1:08 ` Vincent Touquet
2003-07-07 0:54 ` Vincent Touquet
2003-07-07 2:19 ` Andrew Morton
2003-07-07 8:32 ` Vincent Touquet
2003-07-07 11:43 ` joe briggs
2003-07-07 11:08 ` Vincent Touquet
2003-07-07 12:47 ` Vincent Touquet
2003-07-08 21:16 ` Vincent Touquet
2003-07-07 16:14 ` Vincent Touquet
2003-07-07 16:15 ` Vincent Touquet
2003-07-07 16:48 ` Vincent Touquet
2003-07-08 10:19 ` Vincent Touquet
2003-07-08 13:59 ` joe briggs
2003-07-08 13:10 ` Vincent Touquet [this message]
2003-07-08 16:14 ` Vincent Touquet
2003-07-08 16:41 ` Vojtech Pavlik
2003-07-08 16:51 ` Vincent Touquet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030708131047.GG14044@ns.mine.dnsalias.org \
--to=vincent.touquet@pandora.be \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jbriggs@briggsmedia.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.