From: Robert Hancock <hancockrwd@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Grozdan <neutrino8@gmail.com>,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
Tejun Heo <tj@kernel.org>
Subject: Re: Kernel 2.6.30rc7 limits IDE to UDMA33
Date: Sat, 06 Jun 2009 12:16:56 -0600 [thread overview]
Message-ID: <4A2AB298.7020603@gmail.com> (raw)
In-Reply-To: <20090606155636.18bc4f2e@lxorguk.ukuu.org.uk>
Alan Cox wrote:
>> I wouldn't rule out the possibility of a bug. The code in pata_via looks
>> a bit fishy, it reports a 40-wire cable if either the GTM data wasn't
>> present or valid, or if it reports a mode of UDMA2 or less. In the
>> former case it seems like ATA_CABLE_PATA_UNK would be the safer choice
>> since we really don't know, and we should then use drive-side detection,
>> rather than assuming a 40-wire cable by default..
>
> Drive side detection doesn't work for many VIA boards, the neccessary
> components are not included.
Ugh, seems they messed this stuff up as bad as NVIDIA did..
>
> About the only other check I can think to try is to see if the BIOS
> programmed modes > UDMA2 for either device. That has its own problems
> (suspend-resume/hotplug/non-bios devices) which is why we currently don't
> do it.
Well, that's pretty much the same thing that GTM does (it generally just
reads the configured mode out of the controller registers). So it really
wouldn't be much worse than what we're doing now.
Thing is somehow the GTM detection isn't working now and it apparently
was in 2.6.27.1. I'm not seeing any patches to pata_via or libata-acpi
that seem like they would affect this offhand. Grozdan, would you be
able to try git bisect to try to figure out what changed the behavior?
CCing Tejun in case he has any ideas..
next prev parent reply other threads:[~2009-06-06 18:17 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-02 22:25 Kernel 2.6.30rc7 limits IDE to UDMA33 Grozdan
2009-06-03 4:05 ` Robert Hancock
2009-06-03 11:35 ` Grozdan
2009-06-03 12:14 ` Alan Cox
2009-06-03 12:52 ` Grozdan
2009-06-03 13:01 ` Alan Cox
2009-06-03 13:15 ` Grozdan
2009-06-03 13:39 ` Grozdan
2009-06-04 14:50 ` Grozdan
2009-06-05 9:05 ` Alan Cox
2009-06-05 10:35 ` Grozdan
2009-06-05 10:42 ` Alan Cox
2009-06-05 12:43 ` Grozdan
2009-06-05 13:21 ` Alan Cox
2009-06-05 14:02 ` Grozdan
2009-06-06 1:07 ` Robert Hancock
2009-06-06 14:56 ` Alan Cox
2009-06-06 18:16 ` Robert Hancock [this message]
2009-06-06 22:08 ` Alan Cox
2009-06-07 4:39 ` Grozdan
[not found] ` <4A2BF785.3020402@gmail.com>
2009-06-07 18:24 ` Grozdan
2009-06-07 18:46 ` Michael S. Zick
2009-06-07 19:54 ` Alan Cox
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=4A2AB298.7020603@gmail.com \
--to=hancockrwd@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neutrino8@gmail.com \
--cc=tj@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