From: Charlie Wilkinson <cwilkins@boinklabs.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Hard lock-ups on RH7.2 install - Via Chipset?
Date: Thu, 18 Apr 2002 16:29:43 -0400 [thread overview]
Message-ID: <20020418162943.A7808@boink.boinklabs.com> (raw)
In-Reply-To: <20020221105756.A9728@boink.boinklabs.com> <E16dw9r-0007R1-00@the-village.bc.nu>
On Thu, Feb 21, 2002 at 04:33:23PM +0000, Alan Cox waxed eloquent:
>.
> > I can confirm that it still locks up. :/ What can I do to help?
>.
> I'm assuming its a hardware issue. It works on non VIA for multiple people
> it fails on VIA for multiple people
I think I found a solution. At the very least, I've found something
that drastically affects reliability of this hardware combo.
The combo in question is a KT133 chipset (Phoenix BIOS), Athlon 1.3GHz,
2 Promise Ultra100 IDE controllers with an IBM 75gb drive on each channel
(4 drives). Doing anything that beat on all 4 drives sufficiently
(such as software RAID5) would hang the system hard.
The magic settings that had a drastic impact on reliability were the PCI
device latency timers. The early settings I tried just changed how long
the system would run before it crashed (in some cases making things *much*
worse). Then after more of something one could loosely term "research", I
hit on some settings that seem to have resulted in a fully stable system!
Forthwith and to wit:
setpci -v -d *:* latency_timer=b0
setpci -v -d 105a:* latency_timer=ff
Yes, that's a baseline setting of 176 for everything, then max settings
for the two Promise cards. Rather drastic? Perhaps, but it works.
More research and tweaking is probably in order.
I wanted to get the news out -- even if a bit premature -- in hopes that
it might relieve someone else's grief. It's really sucked having all
this hardware for three months and not being able to put it to good use
(unless crash testing counts...)
-cw-
next prev parent reply other threads:[~2002-04-18 20:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-12 15:56 Charlie Wilkinson
[not found] ` <E16agiR-0002Sv-00@the-village.bc.nu>
2002-02-21 15:57 ` Charlie Wilkinson
2002-02-21 16:33 ` Alan Cox
2002-02-21 18:02 ` Charlie Wilkinson
2002-04-18 20:29 ` Charlie Wilkinson [this message]
[not found] <20020221110156.B9728@boink.boinklabs.com>
[not found] ` <Pine.LNX.4.33.0202211106340.16271-100000@coffee.psychology.mcmaster.ca>
2002-02-21 17:49 ` Charlie Wilkinson
2002-02-22 20:21 Michael B Allen
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=20020418162943.A7808@boink.boinklabs.com \
--to=cwilkins@boinklabs.com \
--cc=alan@lxorguk.ukuu.org.uk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®