> > Also another case you broke is kexec.
>
> 1. If kexec is done while either of amd74xx or pata_amd is loaded, the
> currently configured mode is what the kexeced kernel would use as
> reference. If the port has been slowed down during operation, yeah, it
> would be sub-optimal but again the worst can happen is udma33.
So we now have an exciting "well kexec might work but here is a new
random weirdness to screw people who it hit".
> CK804 IDE, at least mine, reports 80c in a lot of cases where it
> shouldn't. I dunno the reason but it also makes drives confused about
> cable type. Maybe it has the wrong capacitor attached or something.
> This is A8N-E from ASUS, probably one of the popular ones using nf4.
I take it this was how you came to find every cable related bug while
trying to work out what was going on ?
> When that happens, libata EH does its job and slows the interface to
> udma33 after quite a few error messages. On IDE, if this happens, the
> drive is put into PIO mode making the machine painful to use.
No the IDE layer does DMA changedown fine, well apart from all the
error/timer races in the old IDE code.
> Googling... I'm listing a few which seem similar.
All of which are before you fixed the drive side stuff
> http://search.luky.org/linux-kernel.2005/msg30919.html
> http://www.centos.org/modules/newbb/viewtopic.php?topic_id=4662
> http://blog.gmane.org/gmane.linux.bios/month=20060601/page=6
And the third is LinuxBIOS so you've actually not fixed anything for that
one.
> Please keep in mind that no one has reported driver side detection is
> wrong in all these years even when in some cases we just assume 80c on
> host side and depended on driver side detection (amd74xx UDMA66
> controllers), but I'm pretty sure it has caused some griefs out in the wild.
Yep.
> I agree with you that this is a hack and ugly as hell. I don't like it
> either, but it solves an existing problem which could have and possibly
> will hit many users. So, I think this problem should at least be
> verified. If it's just my BIOS/motherboard that's crazy, I have no
> problem forgetting about this.
It certainly seems to be Nvidia specific, so perhaps Nvidia can provide
more details on the Nforce4 cable detection ? As with a lot of Nvidia
stuff there was much reverse engineering involved in the original code
base.
And if its a specific board or couple of boards then we should perhaps
use DMI to match them specifically.
> So, anyone with CK804 (a.k.a NF4) up for some testing?
If it still goes I've got a rather iffy NF3 but not an NF4 handy.
Alan
Alan wrote:
[--snip--]
>> CK804 IDE, at least mine, reports 80c in a lot of cases where it
>> shouldn't. I dunno the reason but it also makes drives confused about
>> cable type. Maybe it has the wrong capacitor attached or something.
>> This is A8N-E from ASUS, probably one of the popular ones using nf4.
>
> I take it this was how you came to find every cable related bug while
> trying to work out what was going on ?
Yeap, pretty much. I thought fixing drive side cable detection would
fix it, but hell no.
>> When that happens, libata EH does its job and slows the interface to
>> udma33 after quite a few error messages. On IDE, if this happens, the
>> drive is put into PIO mode making the machine painful to use.
>
> No the IDE layer does DMA changedown fine, well apart from all the
> error/timer races in the old IDE code.
I dunno. It always ended up in PIO mode in my case. I can post the log
if necessary.
[--snip--]
>> I agree with you that this is a hack and ugly as hell. I don't like it
>> either, but it solves an existing problem which could have and possibly
>> will hit many users. So, I think this problem should at least be
>> verified. If it's just my BIOS/motherboard that's crazy, I have no
>> problem forgetting about this.
>
> It certainly seems to be Nvidia specific, so perhaps Nvidia can provide
> more details on the Nforce4 cable detection ? As with a lot of Nvidia
> stuff there was much reverse engineering involved in the original code
> base.
Hmmm... Anyone happen to have working nvidia contact?
> And if its a specific board or couple of boards then we should perhaps
> use DMI to match them specifically.
>
>> So, anyone with CK804 (a.k.a NF4) up for some testing?
>
> If it still goes I've got a rather iffy NF3 but not an NF4 handy.
Yeah, please. If I connect a hdd at the end of 40c cable and leaving
the middle connector empty, the 80c bit is always one and the drive says
it's 80c cable while the BIOS configured mode is correctly udma33. This
is the same for SAMSUNG SP0802N, Maxtor 91301U3 and HITACHI_DK23BA-20.
--
tejun
> > No the IDE layer does DMA changedown fine, well apart from all the
> > error/timer races in the old IDE code.
>
> I dunno. It always ended up in PIO mode in my case. I can post the log
> if necessary.
Ok testing my hardware
- AMD get it right for those with host cable detect
- AMD get it right for disk side detect
- My NV03 gets it wrong on all counts but it pauses only briefly to
change neatly down to UDMA33 with old IDE.
(We could speed that with libata by going straight to UDMA33 on cable
error with PATA_CBL_UNK or some other way to flag "cable detection
untrusted")
The BIOS seems to get the detection it does right, so we need an Nvidia
person to answer this properly. Nvidia + 40pin cable is still clearly such
an obscure setting we don't want to damage general behaviour for it.
Good news is that the AMD just works, that AFAIK means all the non x86 PC
cases just work.
Alan
Unfortunately there's no standard way to do host side cable detect on
nForce systems without going through ACPI. It's done through a GPIO
pin. Board vendors are free to reallocate which GPIO pin is used for
this feature.
One possible solution is to leave the default DMA mode at whatever the
BIOS left it at. So if it's a UDMA5 drive but the BIOS left it at UDMA2
it was because of cable detect.
The *real* solution is to use the BIOS ACPI _GTM _STM methods for this.
Then you can remove all chipset specific knowledge from the IDE driver.
This is what the MS driver does on Windows, so you know it's received a
lot of testing from NVIDIA and board vendors.
-Allen
> -----Original Message-----
> From: Bartlomiej Zolnierkiewicz [mailto:[email protected]]
> Sent: Monday, February 05, 2007 7:09 AM
> To: Allen Martin
> Subject: Fwd: Nvidia cable detection problems (was [PATCH]
> amd74xx: don't configure udma mode higher than BIOS did)
>
> Hi Allen,
>
> Would it be possible to get some help on this issue?
>
> Thanks,
> Bart
>
> ---------- Forwarded message ----------
> From: Tejun Heo <[email protected]>
> Date: Feb 5, 2007 3:50 PM
> Subject: Re: Nvidia cable detection problems (was [PATCH] amd74xx:
> don't configure udma mode higher than BIOS did)
> To: Alan <[email protected]>
> Cc: [email protected], [email protected],
> [email protected]
>
>
> Alan wrote:
> [--snip--]
> >> CK804 IDE, at least mine, reports 80c in a lot of cases where it
> >> shouldn't. I dunno the reason but it also makes drives confused
> >> about cable type. Maybe it has the wrong capacitor
> attached or something.
> >> This is A8N-E from ASUS, probably one of the popular ones
> using nf4.
> >
> > I take it this was how you came to find every cable related
> bug while
> > trying to work out what was going on ?
>
> Yeap, pretty much. I thought fixing drive side cable
> detection would fix it, but hell no.
>
> >> When that happens, libata EH does its job and slows the
> interface to
> >> udma33 after quite a few error messages. On IDE, if this happens,
> >> the drive is put into PIO mode making the machine painful to use.
> >
> > No the IDE layer does DMA changedown fine, well apart from all the
> > error/timer races in the old IDE code.
>
> I dunno. It always ended up in PIO mode in my case. I can
> post the log if necessary.
>
> [--snip--]
> >> I agree with you that this is a hack and ugly as hell. I
> don't like
> >> it either, but it solves an existing problem which could have and
> >> possibly will hit many users. So, I think this problem should at
> >> least be verified. If it's just my BIOS/motherboard
> that's crazy, I
> >> have no problem forgetting about this.
> >
> > It certainly seems to be Nvidia specific, so perhaps Nvidia can
> > provide more details on the Nforce4 cable detection ? As
> with a lot of
> > Nvidia stuff there was much reverse engineering involved in the
> > original code base.
>
> Hmmm... Anyone happen to have working nvidia contact?
>
> > And if its a specific board or couple of boards then we
> should perhaps
> > use DMI to match them specifically.
> >
> >> So, anyone with CK804 (a.k.a NF4) up for some testing?
> >
> > If it still goes I've got a rather iffy NF3 but not an NF4 handy.
>
> Yeah, please. If I connect a hdd at the end of 40c cable and
> leaving the middle connector empty, the 80c bit is always one
> and the drive says it's 80c cable while the BIOS configured
> mode is correctly udma33. This is the same for SAMSUNG
> SP0802N, Maxtor 91301U3 and HITACHI_DK23BA-20.
>
> --
> tejun
>
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
> The *real* solution is to use the BIOS ACPI _GTM _STM methods for this.
> Then you can remove all chipset specific knowledge from the IDE driver.
> This is what the MS driver does on Windows, so you know it's received a
> lot of testing from NVIDIA and board vendors.
Well we can certainly do some of that if ACPI is present and active. In
particular since _GTM will give us current modes allowing for hotplug and
post BIOS boot kexec etc it ought to be safe to do Tejun's hack that way.
We could even probe UDMA3+ capable devices by doing _STM to a high mode
and _GTM to determine the cable type 8)
Alan
Alan wrote:
>> The *real* solution is to use the BIOS ACPI _GTM _STM methods for this.
>> Then you can remove all chipset specific knowledge from the IDE driver.
>> This is what the MS driver does on Windows, so you know it's received a
>> lot of testing from NVIDIA and board vendors.
>
> Well we can certainly do some of that if ACPI is present and active. In
> particular since _GTM will give us current modes allowing for hotplug and
> post BIOS boot kexec etc it ought to be safe to do Tejun's hack that way.
> We could even probe UDMA3+ capable devices by doing _STM to a high mode
> and _GTM to determine the cable type 8)
Glad to see the problem getting solved. Now that we know the solution,
any volunteers? :-)
--
tejun
Hi,
On 2/5/07, Tejun Heo <[email protected]> wrote:
> Alan wrote:
> >> The *real* solution is to use the BIOS ACPI _GTM _STM methods for this.
> >> Then you can remove all chipset specific knowledge from the IDE driver.
> >> This is what the MS driver does on Windows, so you know it's received a
> >> lot of testing from NVIDIA and board vendors.
Allen, thanks for quick reply.
Your mail explained the issue pretty well and saved us a lot of time.
> > Well we can certainly do some of that if ACPI is present and active. In
> > particular since _GTM will give us current modes allowing for hotplug and
> > post BIOS boot kexec etc it ought to be safe to do Tejun's hack that way.
> > We could even probe UDMA3+ capable devices by doing _STM to a high mode
> > and _GTM to determine the cable type 8)
agreed
> Glad to see the problem getting solved. Now that we know the solution,
> any volunteers? :-)
Well, since you posted the initial patches and have the affected hardware... 8)
Thanks,
Bart
> > Well we can certainly do some of that if ACPI is present and active. In
> > particular since _GTM will give us current modes allowing for hotplug and
> > post BIOS boot kexec etc it ought to be safe to do Tejun's hack that way.
> > We could even probe UDMA3+ capable devices by doing _STM to a high mode
> > and _GTM to determine the cable type 8)
>
> Glad to see the problem getting solved. Now that we know the solution,
> any volunteers? :-)
I am currently putting together an experimental pata_acpi driver to play
with this stuff. May take a bit of time while I work out the current acpi
interface gunge and how to expand it.
The fact we have to try each mode to see what we can set doesn't make it
pretty either!
Alan
Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> On 2/5/07, Tejun Heo <[email protected]> wrote:
>> Alan wrote:
>> >> The *real* solution is to use the BIOS ACPI _GTM _STM methods for
>> this.
>> >> Then you can remove all chipset specific knowledge from the IDE
>> driver.
>> >> This is what the MS driver does on Windows, so you know it's
>> received a
>> >> lot of testing from NVIDIA and board vendors.
>
> Allen, thanks for quick reply.
>
> Your mail explained the issue pretty well and saved us a lot of time.
My thanks too.
>> > Well we can certainly do some of that if ACPI is present and active. In
>> > particular since _GTM will give us current modes allowing for
>> hotplug and
>> > post BIOS boot kexec etc it ought to be safe to do Tejun's hack that
>> way.
>> > We could even probe UDMA3+ capable devices by doing _STM to a high mode
>> > and _GTM to determine the cable type 8)
>
> agreed
>
>> Glad to see the problem getting solved. Now that we know the solution,
>> any volunteers? :-)
>
> Well, since you posted the initial patches and have the affected
> hardware... 8)
I'll be on the road for the next two weeks and Alan seems to have taken
it already. :-)
--
tejun
> Unfortunately there's no standard way to do host side cable detect on
> nForce systems without going through ACPI. It's done through a GPIO
> pin. Board vendors are free to reallocate which GPIO pin is used for
> this feature.
Want to know how to make incompatibility? "Ask me How!(tm)".
Regarding ACPI, please see Linus at first,
<http://permalink.gmane.org/gmane.linux.kernel/487507>
And then, are you sure MSACPI will be compatible with any competitor
in near future?
[]
> The *real* solution is to use the BIOS ACPI _GTM _STM methods for this.
> Then you can remove all chipset specific knowledge from the IDE driver.
> This is what the MS driver does on Windows, so you know it's received a
> lot of testing from NVIDIA and board vendors.
Do you mean: with all possible crutches?
I'm very upset, that hardware nvidia-lego forces system software (and
programmers) to know "unfortunately no standard" ways of desinging
things... One read-only-for-os, hardware set bit in kind of control
register isn't possible at all, tphu. BDU market (BDU=brain dead user),
which Microsoft dominates, makes BDD (... designers ;)
> -Allen
No, you don't.
Do you know, why top posting is bad?
Hi.
> From: "Allen Martin"
> Newsgroups: gmane.linux.kernel,gmane.linux.ide
> Subject: RE: Nvidia cable detection problems (was [PATCH] amd74xx: don't configure udma mode higher than BIOS did)
> Archived-At: <http://permalink.gmane.org/gmane.linux.kernel/489859>
> Date: Mon, 5 Feb 2007 09:08:03 -0800
>> -----Original Message-----
>> From: Bartlomiej Zolnierkiewicz [mailto:[email protected]]
>> Sent: Monday, February 05, 2007 7:09 AM
>> To: Allen Martin
>> Subject: Fwd: Nvidia cable detection problems (was [PATCH]
>> amd74xx: don't configure udma mode higher than BIOS did)
>>
>> Hi Allen,
>>
>> Would it be possible to get some help on this issue?
>>
>> Thanks,
>> Bart
>>
>> ---------- Forwarded message ----------
>> From: Tejun Heo <[email protected]>
>> Date: Feb 5, 2007 3:50 PM
>> Subject: Re: Nvidia cable detection problems (was [PATCH] amd74xx:
>> don't configure udma mode higher than BIOS did)
>> To: Alan <[email protected]>
>> Cc: [email protected], [email protected],
>> [email protected]
>>
>>
>> Alan wrote:
>> [--snip--]
>> >> CK804 IDE, at least mine, reports 80c in a lot of cases where it
>> >> shouldn't. I dunno the reason but it also makes drives confused
>> >> about cable type. Maybe it has the wrong capacitor
>> attached or something.
>> >> This is A8N-E from ASUS, probably one of the popular ones
>> using nf4.
>> >
>> > I take it this was how you came to find every cable related
>> bug while
>> > trying to work out what was going on ?
>>
>> Yeap, pretty much. I thought fixing drive side cable
>> detection would fix it, but hell no.
>>
>> >> When that happens, libata EH does its job and slows the
>> interface to
>> >> udma33 after quite a few error messages. On IDE, if this happens,
>> >> the drive is put into PIO mode making the machine painful to use.
>> >
>> > No the IDE layer does DMA changedown fine, well apart from all the
>> > error/timer races in the old IDE code.
>>
>> I dunno. It always ended up in PIO mode in my case. I can
>> post the log if necessary.
>>
>> [--snip--]
>> >> I agree with you that this is a hack and ugly as hell. I
>> don't like
>> >> it either, but it solves an existing problem which could have and
>> >> possibly will hit many users. So, I think this problem should at
>> >> least be verified. If it's just my BIOS/motherboard
>> that's crazy, I
>> >> have no problem forgetting about this.
>> >
>> > It certainly seems to be Nvidia specific, so perhaps Nvidia can
>> > provide more details on the Nforce4 cable detection ? As
>> with a lot of
>> > Nvidia stuff there was much reverse engineering involved in the
>> > original code base.
>>
>> Hmmm... Anyone happen to have working nvidia contact?
>>
>> > And if its a specific board or couple of boards then we
>> should perhaps
>> > use DMI to match them specifically.
>> >
>> >> So, anyone with CK804 (a.k.a NF4) up for some testing?
>> >
>> > If it still goes I've got a rather iffy NF3 but not an NF4 handy.
>>
>> Yeah, please. If I connect a hdd at the end of 40c cable and
>> leaving the middle connector empty, the 80c bit is always one
>> and the drive says it's 80c cable while the BIOS configured
>> mode is correctly udma33. This is the same for SAMSUNG
>> SP0802N, Maxtor 91301U3 and HITACHI_DK23BA-20.
>>
>> --
>> tejun
>>
> -----------------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and may contain
> confidential information. Any unauthorized review, use, disclosure or distribution
> is prohibited. If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
> -----------------------------------------------------------------------------------
Wha? Cool!
____
On 2/5/07, Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> > > Well we can certainly do some of that if ACPI is present and active. In
> > > particular since _GTM will give us current modes allowing for hotplug and
> > > post BIOS boot kexec etc it ought to be safe to do Tejun's hack that way.
> > > We could even probe UDMA3+ capable devices by doing _STM to a high mode
> > > and _GTM to determine the cable type 8)
>
> agreed
New look at the issue:
Since we are already using UDMA mode set by BIOS to determine if 80c cable
is present so why not also use it to determine if the 40c cable is present?
I mean just ignoring AMD_CABLE_DETECT register for NVIDIA devices.
2-lines change and we wouldn't have to deal with ACPI at ell.
What do you think?
Bart
Alan wrote:
>>> Well we can certainly do some of that if ACPI is present and active. In
>>> particular since _GTM will give us current modes allowing for hotplug and
>>> post BIOS boot kexec etc it ought to be safe to do Tejun's hack that way.
>>> We could even probe UDMA3+ capable devices by doing _STM to a high mode
>>> and _GTM to determine the cable type 8)
>> Glad to see the problem getting solved. Now that we know the solution,
>> any volunteers? :-)
>
> I am currently putting together an experimental pata_acpi driver to play
> with this stuff. May take a bit of time while I work out the current acpi
> interface gunge and how to expand it.
>
> The fact we have to try each mode to see what we can set doesn't make it
> pretty either!
Make sure you take a look at libata-dev.git#acpi which is the origin of
the libata ACPI support found in -mm
That's pending for an upstream merge.
Jeff
> Since we are already using UDMA mode set by BIOS to determine if 80c cable
> is present so why not also use it to determine if the 40c cable is present?
>
> I mean just ignoring AMD_CABLE_DETECT register for NVIDIA devices.
>
> 2-lines change and we wouldn't have to deal with ACPI at ell.
And as I explained earlier you get false values. The existing hack is
dodgy as well and breaks on suspend/resume then loading the driver for
one. It's probably the best that can be done without ACPI but the ACPI
_GTM/_STM methods are pretty clean so its not hard to use them. You need
them for full suspend/resume support anyway.
Alan
> I'm very upset, that hardware nvidia-lego forces system software (and
> programmers) to know "unfortunately no standard" ways of desinging
> things... One read-only-for-os, hardware set bit in kind of control
The hardware doesn't. The BIOS authors do by not setting the cable flags.
We actually need to use the STM and GTM methods for PC suspend/resume so
it makes sense to see if they will work out in this case too.
Alan
Alan wrote:
>> I'm very upset, that hardware nvidia-lego forces system software (and
>> programmers) to know "unfortunately no standard" ways of desinging
>> things... One read-only-for-os, hardware set bit in kind of control
>
> The hardware doesn't. The BIOS authors do by not setting the cable flags.
> We actually need to use the STM and GTM methods for PC suspend/resume so
> it makes sense to see if they will work out in this case too.
We also need ACPI, where available, because that's the only way to
obtain a BIOS-set hard drive password. And BIOS vendors often deliver
hard drive-specific errata this way, if the problem is serious enough
(though certainly we would prefer that the OS knows about drive errata,
when a runtime patch is necessary)
Jeff
On 2/5/07, Alan <[email protected]> wrote:
> > Since we are already using UDMA mode set by BIOS to determine if 80c cable
> > is present so why not also use it to determine if the 40c cable is present?
> >
> > I mean just ignoring AMD_CABLE_DETECT register for NVIDIA devices.
> >
> > 2-lines change and we wouldn't have to deal with ACPI at ell.
>
> And as I explained earlier you get false values. The existing hack is
> dodgy as well and breaks on suspend/resume then loading the driver for
> one. It's probably the best that can be done without ACPI but the ACPI
> _GTM/_STM methods are pretty clean so its not hard to use them. You need
> them for full suspend/resume support anyway.
OK
(i don't know a single bit of details of what i'm writing, so... ;)
Jeff Garzik wrote:
> Alan wrote:
> >>I'm very upset, that hardware nvidia-lego forces system software (and
> >>programmers) to know "unfortunately no standard" ways of desinging
> >>things... One read-only-for-os, hardware set bit in kind of control
> >
> >The hardware doesn't. The BIOS authors do by not setting the cable flags.
> >We actually need to use the STM and GTM methods for PC suspend/resume so
> >it makes sense to see if they will work out in this case too.
Before that. I mean, to let Vendor to choose (and software operate) GPIO
and then to have headache, you've described. Also, here i'm not going
wider, than hardware cabel detection/max speed test (IMHO it must be
pretty easy).
> We also need ACPI, where available, because that's the only way to
> obtain a BIOS-set hard drive password.
Plain-text passwords -- i don't actually know, if they are useful at all.
What if BIOS has admin/user passwords set?
(kernel: if you have BIOS password, press RESET; if you don't press POWER ;)
> And BIOS vendors often deliver hard drive-specific errata this way, if
> the problem is serious enough (though certainly we would prefer that
> the OS knows about drive errata, when a runtime patch is necessary)
I thought versions, revisions, stepping are indicators of that, and
OS have workarounds, fixes, optimizations, based on that kind of
information. "BIOS vendors", as i read here, are IMHO -bug-in-the-middle-
attack (:
Kind regards, guys.
--
-o--=O`C
#oo'L O
<___=E M
Oleg Verych wrote:
>> We also need ACPI, where available, because that's the only way to
>> obtain a BIOS-set hard drive password.
>
> Plain-text passwords -- i don't actually know, if they are useful at all.
> What if BIOS has admin/user passwords set?
> (kernel: if you have BIOS password, press RESET; if you don't press POWER ;)
It's not a matter of usefulness, but of accessing data.
The password must be provided to the hard drive at the ATA command
level, otherwise the hard drive will simply refuse to read or write data.
Jeff