From: Bill Davidsen <davidsen@tmr.com>
To: Stephen.Clark@seclark.us
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Jeff Garzik <jeff@garzik.org>, Robert Hancock <hancockr@shaw.ca>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-ide@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] libata: warn if speed limited due to 40-wire cable (v2)
Date: Mon, 05 Mar 2007 10:32:22 -0500 [thread overview]
Message-ID: <45EC3806.90509@tmr.com> (raw)
In-Reply-To: <45EB5B3A.2040009@seclark.us>
Stephen Clark wrote:
> Bill Davidsen wrote:
>
>> Stephen Clark wrote:
>>
>>
>>> Bill Davidsen wrote:
>>>
>>>
>>>> Alan Cox wrote:
>>>>
>>>>
>>>>
>>>>>> it seems broken to manipulate xfer_mask after returning from the
>>>>>> driver's ->mode_filter hook.
>>>>>>
>>>>>> this patch is more than just a speed-limited warning printk, afaics
>>>>>>
>>>>> I actually suggested that order because the only way the printk
>>>>> can be
>>>>> done correctly is for it to be the very last test made. Since the
>>>>> mode
>>>>> filter is not told what mode will be used but just subtracts modes
>>>>> that
>>>>> are not allowed this should be safe.
>>>>>
>>>>>
>>>> Far better to have a drive which works slowly than one which works
>>>> unreliably.
>>>>
>>>>
>>>>
>>>>
>>> That would be true if the 40 wire detection was 100% accurate!
>>>
>> The statement is completely correct, even though the detection may
>> not be. ;-)
>>
>> With the current set(s) of patches to do better detection, cable
>> evaluation should be better. But even if not, a slow system is more
>> useful than one which doesn't work, crashes because of swap i/o
>> errors, etc.
>>
>>
>>
> I have had problems with cable detection on my previous laptop and my
> current laptop. It almost made
> my systems unusable. On my current laptop I was getting a thruput of a
> little over 1 mbps instead
> of the 44 mbps I get with udma set to the correct value. It took hours
> to upgrade my laptop from
> fc5 to fc6 because of this mis detection.
>
As far as I can see, if you are getting that low a speed, you have other
problems. I have a system with old slow drives which are really on a 40
pin cable, and they run at UDMA(33). One of the experts in this can
undoubtedly tell us more, but your system should run faster than that,
mine does, and I really HAVE a 40 pin cable (and drive).
If your system drops to PIO modes, I doubt cable is the only issue, I
think there are other issues (acpi comes to mind).
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
prev parent reply other threads:[~2007-03-05 15:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-20 0:45 [PATCH] libata: warn if speed limited due to 40-wire cable (v2) Robert Hancock
2007-02-20 13:11 ` Alan
2007-03-02 23:33 ` Jeff Garzik
2007-03-03 0:54 ` Alan Cox
2007-03-03 0:14 ` Jeff Garzik
2007-03-03 20:28 ` Bill Davidsen
2007-03-04 18:14 ` Stephen Clark
2007-03-04 23:00 ` Bill Davidsen
2007-03-04 23:50 ` Stephen Clark
2007-03-05 15:32 ` Bill Davidsen [this message]
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=45EC3806.90509@tmr.com \
--to=davidsen@tmr.com \
--cc=Stephen.Clark@seclark.us \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hancockr@shaw.ca \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
--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.