Here comes a batch of patches for the via-rhine driver. Please apply.
via-rhine is still hardly usable on the most common Rhine hardware; it
can't sustain 100Mbps traffic. The changes presented here improve the
situation considerably; they fix a number of real problems and have been
tested for regression (alas, by few people).
Roger
The Tx underrun handling in the current driver is broken. The details have
been explained in a posting "VIA Rhine 1.15exp1, patch for
testing/discussion" a couple of months ago.
Fix the following bugs:
- after a watchdog timeout (still a common thing with the Rhine), the
driver will fall back to half-duplex, ignoring the auto-negotiation
results, killing performance completely until the driver is reloaded;
fixed by clearing full_duplex in init_registers()
- driver considers only 0x200 for full-duplex option; now 0x220
- duplex code used dev->name before it's initialized; code section moved
The full_duplex and force_media related code is quite a mess, but this
minimal fix will make the most annoying problems go away. Looking at some
other code (e.g. mii.c) it seems to me the interaction between user force,
autoneg results and full_duplex/force_media is amazingly complex, so I'll
leave it at this for now.
The new reset function only waits up to 0.1 ms for the reset to complete,
instead of 10 ms. However, it introduces the use of a forced reset flag if
a chip doesn't seem cooperative. This fixes cases where until now only
reloading the driver or even rebooting the machine would bring the chip
back.
- nuke mii_status_bits
- move clear_tally_counters() up so it can get inlined (pointed out by
Luca Barbieri)
- rename via_restart_tx() -> via_rhine_restart_tx()
Roger Luethi wrote:
> Here comes a batch of patches for the via-rhine driver. Please apply.
>
> via-rhine is still hardly usable on the most common Rhine hardware; it
> can't sustain 100Mbps traffic. The changes presented here improve the
> situation considerably; they fix a number of real problems and have been
> tested for regression (alas, by few people).
Looks good, all patches applied to 2.5.
Should these apply to 2.4, too?
Just a general comment, the reset logic seems a bit too much like voodoo
magic ;-) It would be nice long-term to get an official answer from Via
about the proper reset sequence and time limits. [regardless, like I
said, patch applied...]
Jeff
On Sat, 15 Feb 2003 14:08:24 -0500, Jeff Garzik wrote:
> Looks good, all patches applied to 2.5.
Thx. Patch to bump the version number up attached.
> Should these apply to 2.4, too?
Yes. I'm trying to keep the drivers in both trees in sync.
> Just a general comment, the reset logic seems a bit too much like voodoo
> magic ;-)
Look at the rest of the driver and you will find the reset voodoo magic is
a perfect fit. We'd be waving dead chickens if only tar could handle them.
Actually, the reset logic is slightly better because for every line I have
some reasoning and actual tests conducted. The underlying problem is that
the Rhine is only loosely documented and various revisions differ in
amazing ways from each other and from the documentation that supposedly
describes them.
I've named the magic register in the patch below, does that ease your
voodoo pain?
I've been considering for a while to document the driver somewhat better.
Are documentation patches welcome, or do you just want to have official
word from VIA that they agree with the reset code? And if I need a few
lines to explain some voodoo magic, is the prefered way to put it into the
source or would a freshly created Documentation/network/via-rhine.txt be
(my first choice but the directory typically contains user rather than
developer documentation) the better place?
> It would be nice long-term to get an official answer from Via
> about the proper reset sequence and time limits. [regardless, like I
Heh. If I had a contact at VIA I'd have many and more important questions
than the reset sequence that actually works now, unlike lots of other
stuff. Yes, reliable information from within VIA -- official or not --
would be a big help.
Roger
Roger Luethi wrote:
> Here comes a batch of patches for the via-rhine driver. Please apply.
>
> via-rhine is still hardly usable on the most common Rhine hardware; it
> can't sustain 100Mbps traffic. The changes presented here improve the
> situation considerably; they fix a number of real problems and have been
> tested for regression (alas, by few people).
applied to 2.4, as well.
Roger Luethi wrote:
> On Sat, 15 Feb 2003 14:08:24 -0500, Jeff Garzik wrote:
>
>
>>Looks good, all patches applied to 2.5.
>
>
> Thx. Patch to bump the version number up attached.
applied to 2.4 and 2.5
>>Should these apply to 2.4, too?
>
>
> Yes. I'm trying to keep the drivers in both trees in sync.
noted
>>Just a general comment, the reset logic seems a bit too much like voodoo
>>magic ;-)
>
>
> Look at the rest of the driver and you will find the reset voodoo magic is
> a perfect fit. We'd be waving dead chickens if only tar could handle them.
> Actually, the reset logic is slightly better because for every line I have
> some reasoning and actual tests conducted. The underlying problem is that
> the Rhine is only loosely documented and various revisions differ in
> amazing ways from each other and from the documentation that supposedly
> describes them.
>
> I've named the magic register in the patch below, does that ease your
> voodoo pain?
I applied the patch, but I meant more that wait_for_reset seems
questionable. There is generally a PIO or MMIO write preceding
wait_for_reset function call, and then the function delays. If the PCI
write is posted, for example, which at least my own Via EPIA does, then
you cannot be guaranteed the timing of
write[bwl]()
udelay(5)
PCI writes must be flushed, by doing a read[bwl]().
So, obvious PCI posting bugs in the wait_for_reset may be the cause of
some of the randomness that appears in the field. (Note this applies to
all PCI writes in the driver...)
So, I said "voodoo magic" because it doesn't really seem like we know
what the exact handling is... and randomly placed udelay() calls are,
unfortunately, sometimes a sign of driver bugs instead of necessary
hardware delays.
> I've been considering for a while to document the driver somewhat better.
> Are documentation patches welcome, or do you just want to have official
> word from VIA that they agree with the reset code? And if I need a few
> lines to explain some voodoo magic, is the prefered way to put it into the
> source or would a freshly created Documentation/network/via-rhine.txt be
> (my first choice but the directory typically contains user rather than
> developer documentation) the better place?
I would prefer both user and developer docs go in
Documentation/networking/via-rhine.txt. It is easy enough to note
separate sections of the document...
>>It would be nice long-term to get an official answer from Via
>>about the proper reset sequence and time limits. [regardless, like I
>
>
> Heh. If I had a contact at VIA I'd have many and more important questions
> than the reset sequence that actually works now, unlike lots of other
> stuff. Yes, reliable information from within VIA -- official or not --
> would be a big help.
Let me wave some dead chickens of my own, and see what happens...
Jeff
On Sat, 15 Feb 2003 16:49:24 -0500, Jeff Garzik wrote:
> I applied the patch, but I meant more that wait_for_reset seems
> questionable. There is generally a PIO or MMIO write preceding
> wait_for_reset function call, and then the function delays. If the PCI
> write is posted, for example, which at least my own Via EPIA does, then
> you cannot be guaranteed the timing of
> write[bwl]()
> udelay(5)
>
> PCI writes must be flushed, by doing a read[bwl]().
Thanks for raising that issue. It is my understanding that PIO ops are
synchronous (on IA-32). If that is correct, problems should only occur if
the driver is built with MMIO support, no?
I have been building the driver without MMIO for quite a while to eliminate
one source of problems for now.
> what the exact handling is... and randomly placed udelay() calls are,
> unfortunately, sometimes a sign of driver bugs instead of necessary
> hardware delays.
You won't see me rule out driver bugs as a likely explanation for anything
anytime soon ;-).
> I would prefer both user and developer docs go in
> Documentation/networking/via-rhine.txt. It is easy enough to note
> separate sections of the document...
ACK.
Roger
On Sat, 15 Feb 2003, Roger Luethi wrote:
>
> Thanks for raising that issue. It is my understanding that PIO ops are
> synchronous (on IA-32). If that is correct, problems should only occur if
> the driver is built with MMIO support, no?
No, even PIO ops are asynchronous. They are _more_ synchronous than the
MMIO ones (I think the CPU waits until they hit the bus, and most bridges
just pass them through), but the CPU does not wait for them to hit the
device.
So in practice, this _tends_ to mean that a PIO write will usually hit the
device within a microsecond or less of being issued by the CPU, and you
don't need a IO read to force it out. But considering the wide variety of
PCI bridges out there I bet there are some that will post even PIO writes
and might hold on to them for some time, especially if other activity like
DMA keeps the bus busy.
In other words: I suspect the code will work. But it's probably _safer_ to
do the normal "read to synchronize" unless there are major performance
issues (which is clearly not the case in this particular instance, but
might be somewhere else).
Linus
> On Sat, 15 Feb 2003, Roger Luethi wrote:
> >
> > Thanks for raising that issue. It is my understanding that PIO ops are
> > synchronous (on IA-32). If that is correct, problems should only occur if
> > the driver is built with MMIO support, no?
>
> No, even PIO ops are asynchronous. They are _more_ synchronous than the
> MMIO ones (I think the CPU waits until they hit the bus, and most bridges
Hmmm... A recent thread on PCI write posting seemed to confirm my view [1].
What am I missing here?
------------------------------ cut here -----------------------------------
From: Alan Cox <[email protected]>
Subject: Re: Linux 2.4.21-pre3-ac4
Date: 12 Jan 2003 20:40:54 +0000
On Sun, 2003-01-12 at 19:51, Benjamin Herrenschmidt wrote:
> What about PCI write posting ? How can we enforce the 400ns delay here ?
For i/o space it is ok as in*/out* are synchronous. For mmio right now I
don't know. I need to talk to Andre about that for SATA. I guess for the
PPC its going to be fun
[...]
------------------------------ cut here -----------------------------------
> don't need a IO read to force it out. But considering the wide variety of
> PCI bridges out there I bet there are some that will post even PIO writes
> and might hold on to them for some time, especially if other activity like
> DMA keeps the bus busy.
There was some talking about hwif->IOSYNC() (for IDE). That might be
interesting for other devices, too. It could resolve to a nop for
synchronous operations, and say a read* for MMIO. IMHO it shouldn't be up
to a driver maintainer to figure out what sync op some arch the driver may
run on needs. What a maintainer typically _can_ provide is type of
operation (MMIO/PIO) and a register that is considered safe for a sync
read.
Roger
[1] http://marc.theaimsgroup.com/?l=linux-kernel&m=104240180906935&w=4
Roger Luethi wrote:
>>On Sat, 15 Feb 2003, Roger Luethi wrote:
>>
>>>Thanks for raising that issue. It is my understanding that PIO ops are
>>>synchronous (on IA-32). If that is correct, problems should only occur if
>>>the driver is built with MMIO support, no?
>>
>>No, even PIO ops are asynchronous. They are _more_ synchronous than the
>>MMIO ones (I think the CPU waits until they hit the bus, and most bridges
>
>
> Hmmm... A recent thread on PCI write posting seemed to confirm my view [1].
> What am I missing here?
Basically, in a wait_for_reset, performance doesn't matter, so just
flush with a read, and it will work in all cases :)
A PIO write may be posted through multiple levels of PCI bridges,
perhaps... in any case, even if PIO is completely synchronous in test
cases, an additional read will not hurt here.
Jeff