[top posting because context may be missing otherwise, over a week later]
Excellent analysis, Willy. Quite frankly, I am not keen on making this
driver any more complex, especially if the gains are marginal at best. VIA
Rhine will never be high-performance hardware, and we have too much special
ca
On Thu, 11 May 2006 22:59:44 -0700, David Lang wrote:
> I haven't had time to go back and find where is started (my prior kernel
> was 2.6.15-rc7), but with 2.6.17-rc1/2/3/4 I've been running into a
> problem where when transfering large amounts of data (trying to ftp a TB
"where is started" so
On Thu, 13 Apr 2006 14:02:52 -0700, Stephen Hemminger wrote:
> > I am not keen on patches that make via-rhine more of a special case even if
> > it was safe now; next thing you know generic_mii_ioctl is changed in a way
> > that breaks the only driver that foolishly made assumptions about the
> > s
On Thu, 13 Apr 2006 11:40:18 -0700, Stephen Hemminger wrote:
> The right thing to do is get rid of the locking in via_rhine:netdev_ioctl
> and push the locking down into mdio_read, mdio_write.
As I said before, a dozen other network drivers do the exact same thing --
they call generic_mii_ioctl ri
On Thu, 13 Apr 2006 14:26:43 -0400, John W. Linville wrote:
> > I wonder if low latency for ancient Rhine-I chips is worth the trouble.
>
> IIRC, the point was that mdelay was getting called in interrupt
> context and causing ugly messages to show-up in dmesg.
I suppose the patch back then was to
On Fri, 24 Mar 2006 16:49:10 +0100, Marco Berizzi wrote:
> Hello evebody.
> I get this error on linux vanilla 2.6.16
> with via_rhine module loaded when
> I run mii-tool:
That was caused by a recent change that replaced an mdelay with msleep.
netdev_ioctl and friends (ethtool calls, too) are kno
