All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rachel Greenham <rachel@linuxgrrls.org>
To: "Christian Bornträger" <linux-kernel@borntraeger.net>
Cc: Thomas Molina <tmolina@home.com>, linux-kernel@vger.kernel.org
Subject: Re: VIA KT133A crash *post* 2.4.3-ac6
Date: Sat, 16 Jun 2001 19:27:53 +0100	[thread overview]
Message-ID: <3B2BA529.8040107@linuxgrrls.org> (raw)
In-Reply-To: <Pine.LNX.4.33.0106160827100.13727-100000@localhost.localdomain> <002201c0f66e$90675360$3303a8c0@einstein>



Christian Bornträger wrote:

>>If possible, can you remove the hard disc from the promise and attach it on
>>the VIA-Controller and test if the problem still occurs? (prepare a bootdisc
>>if you cannot boot. Propably, you have to pass a new root-partition to the
>>kernel)
>>I hardly believe that the promise controller has some problems with the new
>>VIA setup introduced in 2.4.3-ac7. Using the promise ports of the A7V133 is
>>the only correlation I see again and again...
>>
Yes, plugging the drive into the primary VIA IDE port, it seems to work 
perfectly. Am now on 2.4.5-ac14 with UDMA5 enabled and it seems quite happy.

Which would seem to indicate that yes, it *is* a Promise issue - or at 
least a Promise-on-VIA issue.

FWIW the Promise BIOS announces itself as version 2.01 build 35.

erk...

Thus far I've been presuming that the Promise IDE ports were 
UDMA100/66/33 and the VIA IDE ports were UDMA66/33, and thus naturally 
wanted to use the Promise ports to get better performance. Now, on more 
careful reading of the manual, it seems to be telling me that *all* of 
the IDE ports are UDMA100/66/33, the main benefit of the Promise chip 
besides being able to plug more IDE devices in, being the RAID 0 support 
(which I don't need [yet]). Then, on looking again at the bonnie 
*results* (rather than just noting that it hadn't *crashed*), I notice 
that the figures are about the same, possibly marginally better, than 
those I was getting out of the Promise ports.

And there I thought I'd have to be slumming it... Doh! :-} <sheepish/>

-- 
Rachel



  reply	other threads:[~2001-06-16 18:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-12 12:10 VIA KT133A crash *post* 2.4.3-ac6 Rachel Greenham
2001-06-12 12:42 ` Christian Bornträger
2001-06-12 13:19   ` Rachel Greenham
2001-06-12 15:58   ` Alan Cox
2001-06-12 15:56 ` Alan Cox
2001-06-16  0:03   ` Thomas Molina
2001-06-16 10:15     ` Rachel Greenham
2001-06-16 13:42       ` Thomas Molina
2001-06-16 14:13         ` Christian Bornträger
2001-06-16 18:27           ` Rachel Greenham [this message]
2001-06-16 15:24         ` Rachel Greenham
2001-06-16 16:57           ` Justin Guyett
2001-06-16 17:25             ` Rachel Greenham
  -- strict thread matches above, loose matches on Subject: below --
2001-06-17 11:56 Jason T. Collins

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=3B2BA529.8040107@linuxgrrls.org \
    --to=rachel@linuxgrrls.org \
    --cc=linux-kernel@borntraeger.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tmolina@home.com \
    /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.