> No, just the vt82c686. vt82c686a and vt82c686b are OK.
So can the vt82c686 be replaced with one of these other chips? What
action is available to owners of MBs with chips that don't work w/Linux?
On Wed, 7 Mar 2001, Vojtech Pavlik wrote:
> Date: Wed, 7 Mar 2001 20:14:37 +0100
> From: Vojtech Pavlik <[email protected]>
> To: George Garvey <[email protected]>
> Cc: [email protected]
> Subject: Re: Linux 2.4.2ac12 (vt82c686 info)
>
> On Tue, Mar 06, 2001 at 05:05:46AM -0800, George Garvey wrote:
> >
> > > No, just the vt82c686. vt82c686a and vt82c686b are OK.
> >
> > So can the vt82c686 be replaced with one of these other chips? What
> > action is available to owners of MBs with chips that don't work w/Linux?
>
> It can be replaced if you can desolder a 352 contact BGA chip. I don't
> know of anyone who does.
>
> Also, the vt82c686 will work just fine with Linux, but will be limited
> to UDMA33, because UDMA66 on this chip does reliably fail.
Based on following the lkml threads on Via chipsets, it seems that
the 686a at or above rev 22, will run UDMA66 just fine.
Below that, lies the flakiness...
My Tyan based 686a rev 22 has been trouble free save a bad cable.
I just acquired a new 1.1G athlon on an asus a7v133. It has a 686b.
What should I expect w the 686b? and is the Via 686b data sheet
available somewhere?
Thanx
>
> Furthermore, these chips are very rare - I don't know anyone owning one.
>
> --
> Vojtech Pavlik
> SuSE Labs
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
[email protected]
http://www.sc-software.com
-----------------------------------------------------------------
On Tue, Mar 06, 2001 at 05:05:46AM -0800, George Garvey wrote:
>
> > No, just the vt82c686. vt82c686a and vt82c686b are OK.
>
> So can the vt82c686 be replaced with one of these other chips? What
> action is available to owners of MBs with chips that don't work w/Linux?
It can be replaced if you can desolder a 352 contact BGA chip. I don't
know of anyone who does.
Also, the vt82c686 will work just fine with Linux, but will be limited
to UDMA33, because UDMA66 on this chip does reliably fail.
Furthermore, these chips are very rare - I don't know anyone owning one.
--
Vojtech Pavlik
SuSE Labs
On Mar 07 2001, Vojtech Pavlik wrote:
> Also, the vt82c686 will work just fine with Linux, but will be limited
> to UDMA33, because UDMA66 on this chip does reliably fail.
How do I know which one I have? Using the revision of the
chip?
lspci only shows that I have a vt82c686 (revision 22 --
perhaps this is the clue), but I have been using UDMA66 drives
here with *no* corruption so far (or I haven't stressed my
system enough to notice it).
Here are the lines from my lspci which I think are relevant
here:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10)
00:04.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
00:04.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Any hints are more than welcome.
[]s, Roger...
P.S.: This is an ASUS A7V mobo.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rogerio Brito - [email protected] - http://www.ime.usp.br/~rbrito/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
On Wed, Mar 07, 2001 at 01:23:49PM +0000, John Heil wrote:
> > Also, the vt82c686 will work just fine with Linux, but will be limited
> > to UDMA33, because UDMA66 on this chip does reliably fail.
>
> Based on following the lkml threads on Via chipsets, it seems that
> the 686a at or above rev 22, will run UDMA66 just fine.
> Below that, lies the flakiness...
> My Tyan based 686a rev 22 has been trouble free save a bad cable.
686 rev 00-0f => 686, UDMA33 (UDMA66 broken, chip very rare)
686 rev 10-2f => 686a, UDMA66
686 rev 40 => 686b, UDMA100
> I just acquired a new 1.1G athlon on an asus a7v133. It has a 686b.
> What should I expect w the 686b? and is the Via 686b data sheet
> available somewhere?
Make sure you use the latest 2.4.2-acxx drivers. Most other versions of
my drivers have little bugs in the 686b support. Harmless but somewhat
annoying.
--
Vojtech Pavlik
SuSE Labs
In mailing-lists.linux-kernel, you wrote:
> Make sure you use the latest 2.4.2-acxx drivers. Most other versions of
> my drivers have little bugs in the 686b support. Harmless but somewhat
> annoying.
Does this mean that the version 3.21 of your driver in the latest
2.4.2-acxx is newer than the version 4.3 that you distributed to the
LKML a couple weeks ago?
Cheers,
Wayne
On Thu, Mar 08, 2001 at 09:17:06AM +0100, Vojtech Pavlik wrote:
>On Wed, Mar 07, 2001 at 01:23:49PM +0000, John Heil wrote:
>Make sure you use the latest 2.4.2-acxx drivers. Most other versions of
>my drivers have little bugs in the 686b support. Harmless but somewhat
>annoying.
Hi,
Hmm, last I checked, Alan had only included v3.21 of your VIA ide
driver in the 2.4.2-acxx series, which still had some minor problems with
the 686B. These didn't clear up until v4.3 of the driver.
-Harold
--
"Life sucks, deal with it!"
On Thu, Mar 08, 2001 at 09:30:23AM -0800, Wayne Whitney wrote:
> In mailing-lists.linux-kernel, you wrote:
>
> > Make sure you use the latest 2.4.2-acxx drivers. Most other versions of
> > my drivers have little bugs in the 686b support. Harmless but somewhat
> > annoying.
>
> Does this mean that the version 3.21 of your driver in the latest
> 2.4.2-acxx is newer than the version 4.3 that you distributed to the
> LKML a couple weeks ago?
They're about the same - only Alan didn't like the PCI speed measurement
code that's new in the 4.x series, so I added all the other changes to
the 3.20 driver, and 3.21 was born.
4.x is development
3.x is stable
--
Vojtech Pavlik
SuSE Labs
On Thu, Mar 08, 2001 at 11:35:42AM -0700, Harold Oga wrote:
> On Thu, Mar 08, 2001 at 09:17:06AM +0100, Vojtech Pavlik wrote:
> >On Wed, Mar 07, 2001 at 01:23:49PM +0000, John Heil wrote:
> >Make sure you use the latest 2.4.2-acxx drivers. Most other versions of
> >my drivers have little bugs in the 686b support. Harmless but somewhat
> >annoying.
> Hi,
> Hmm, last I checked, Alan had only included v3.21 of your VIA ide
> driver in the 2.4.2-acxx series, which still had some minor problems with
> the 686B. These didn't clear up until v4.3 of the driver.
3.21 has these fixes in it. It's series 3 because it doesn't include the
PCI speed measurement feature.
--
Vojtech Pavlik
SuSE Labs
On Thu, 8 Mar 2001 19:51:07 +0100, Vojtech Pavlik wrote:
>They're about the same - only Alan didn't like the PCI speed measurement
>code that's new in the 4.x series, so I added all the other changes to
>the 3.20 driver, and 3.21 was born.
I do understand Alan's objections against this speed measurement code
very well. I have similar code built into other (non-Linux) drivers,
and according to the many user reports that I got the measurement
results should be taken with a grain of salt. It is working perfectly
in most cases, but it may fail from time to time. There is a hidden
assumption in this type of measurement which the device that you run
the test against has to fulfill. If it doesn't (and it is not required
to do to be conforming to the ATA spec), the measurement results (PCI
bus clock) are bogus (typically way too high).
Ciao,
Dani
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniela Engert, systems engineer at MEDAV GmbH
Gr?fenberger Str. 34, 91080 Uttenreuth, Germany
Phone ++49-9131-583-348, Fax ++49-9131-583-11
On Fri, Mar 09, 2001 at 08:25:43AM +0100, Daniela Engert wrote:
> >They're about the same - only Alan didn't like the PCI speed measurement
> >code that's new in the 4.x series, so I added all the other changes to
> >the 3.20 driver, and 3.21 was born.
>
> I do understand Alan's objections against this speed measurement code
> very well. I have similar code built into other (non-Linux) drivers,
> and according to the many user reports that I got the measurement
> results should be taken with a grain of salt. It is working perfectly
> in most cases, but it may fail from time to time. There is a hidden
> assumption in this type of measurement which the device that you run
> the test against has to fulfill. If it doesn't (and it is not required
> to do to be conforming to the ATA spec), the measurement results (PCI
> bus clock) are bogus (typically way too high).
Actually I don't think my method can ever result in a measurement higher
than real PCI clock, but can result in a lower one (if the device
deasserts IORDY even on a speed slower than PIO_0), which is also a
problem. Anyway, on fast machines the accuracy of the current algorithm
is +- .01 MHz.
Once tested a little more, the measurement will probably go in, however
with an option for the user to override it with a command line
parameter.
Btw, if it isn't a secret - what other drivers are those and what is the
exact method you used ... ?
--
Vojtech Pavlik
SuSE Labs
On Thu, Mar 08, 2001 at 09:54:48PM +0100, Vojtech Pavlik wrote:
>On Thu, Mar 08, 2001 at 11:35:42AM -0700, Harold Oga wrote:
>
>> On Thu, Mar 08, 2001 at 09:17:06AM +0100, Vojtech Pavlik wrote:
>> >On Wed, Mar 07, 2001 at 01:23:49PM +0000, John Heil wrote:
>> >Make sure you use the latest 2.4.2-acxx drivers. Most other versions of
>> >my drivers have little bugs in the 686b support. Harmless but somewhat
>> >annoying.
>> Hi,
>> Hmm, last I checked, Alan had only included v3.21 of your VIA ide
>> driver in the 2.4.2-acxx series, which still had some minor problems with
>> the 686B. These didn't clear up until v4.3 of the driver.
>
>3.21 has these fixes in it. It's series 3 because it doesn't include the
>PCI speed measurement feature.
Hi,
Hmm, ok, I'll have to go back and try it again, because I could have
sworn these fixes were not in 3.21.
-Harold
--
"Life sucks, deal with it!"
On Fri, Mar 09, 2001 at 06:10:56AM -0700, Harold Oga wrote:
>On Thu, Mar 08, 2001 at 09:54:48PM +0100, Vojtech Pavlik wrote:
>>3.21 has these fixes in it. It's series 3 because it doesn't include the
>>PCI speed measurement feature.
>Hi,
> Hmm, ok, I'll have to go back and try it again, because I could have
>sworn these fixes were not in 3.21.
Hi,
Ok, I officially withdraw my claim that 3.21 has problems with the
686B, and apologize to Vojtech for not actually testing 3.21 before I made
the claim. I should know better that to trust my memory :)
-Harold
--
"Life sucks, deal with it!"
Daniela,
Great to hear from you again my dear! ;-)
On Fri, 9 Mar 2001, Vojtech Pavlik wrote:
> On Fri, Mar 09, 2001 at 08:25:43AM +0100, Daniela Engert wrote:
>
> > >They're about the same - only Alan didn't like the PCI speed measurement
> > >code that's new in the 4.x series, so I added all the other changes to
> > >the 3.20 driver, and 3.21 was born.
> >
> > I do understand Alan's objections against this speed measurement code
> > very well. I have similar code built into other (non-Linux) drivers,
> > and according to the many user reports that I got the measurement
> > results should be taken with a grain of salt. It is working perfectly
> > in most cases, but it may fail from time to time. There is a hidden
> > assumption in this type of measurement which the device that you run
> > the test against has to fulfill. If it doesn't (and it is not required
> > to do to be conforming to the ATA spec), the measurement results (PCI
> > bus clock) are bogus (typically way too high).
>
> Actually I don't think my method can ever result in a measurement higher
> than real PCI clock, but can result in a lower one (if the device
> deasserts IORDY even on a speed slower than PIO_0), which is also a
> problem. Anyway, on fast machines the accuracy of the current algorithm
> is +- .01 MHz.
>
> Once tested a little more, the measurement will probably go in, however
> with an option for the user to override it with a command line
> parameter.
>
> Btw, if it isn't a secret - what other drivers are those and what is the
> exact method you used ... ?
>
> --
> Vojtech Pavlik
> SuSE Labs
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-----------------------------------------------------------------------------
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035 Web: http://www.aslab.com