I just installed Urban's most recent patch, and I still get much the same
problems when I reboot from Windows. The main difference appears to be
that there's a few seconds' pause during the via-rhine driver
initialisation (presumably while it tries to find PHY devices), and there
aren't quite so
I just installed Urban's most recent patch, and I still get much the same
problems when I reboot from Windows. The main difference appears to be
that there's a few seconds' pause during the via-rhine driver
initialisation (presumably while it tries to find PHY devices), and there
aren't quite so
On 5 Feb 2001, at 11:58, Manfred Spraul wrote:
> Thomas Stewart wrote:
> Several regs are just the wakeup frames, but some look suspicious.
>
> Could you try Urban's patch, but add
>
>
> writeb(0x00, ioaddr + 0x83);
> writel(0x0101, ioaddr + 0xa0);
> writel(0x0101, ioaddr +
hi!
..I installed Manfred's patch and the d-link-card was now able to
reset after the tx-timeout-error. that means that the card was again
reachable after the error. but the smb-transfer-connection-error still
appeared. then I set "static int debug = 2;" in the patched
via-rhine.c to get more
Thomas Stewart wrote:
>
> Right, i patched the via-diag and its showing more regs.
>
> I applyed Manfred's patch but that changed nothing.
> Then I applyed your patch and still changed nothing as you suspected.
> But there are regs that are different.
>
Several regs are just the wakeup frames,
On 5 Feb 2001, at 9:38, Manfred Spraul wrote:
> That's expected, my patch fixes another bug.
> The NIC now recover from "Tx timeout" messages. ksa confirmed that,
> but there is still a delay of a few seconds. I'll try to fix that.
>
> > Then I applyed your patch and still changed nothing as
On Mon, 5 Feb 2001, Manfred Spraul wrote:
> 6 ms is quite long:
> I added a reset into tx_timeout, and that function should not take more
> than 1 ms or so.
> Did you find something about the delay in the documentation? Is it
> possible to poll for reset completion?
I don't know how long. For
Thomas Stewart wrote:
>
> >
> > CmdReset is not instant, it may need a delay. There is also a "force
> > software reset" operation that sounds good, I assume that one also
> > could use a delay so I gave it 6ms.
> >
6 ms is quite long:
I added a reset into tx_timeout, and that function should
Thomas Stewart wrote:
CmdReset is not instant, it may need a delay. There is also a "force
software reset" operation that sounds good, I assume that one also
could use a delay so I gave it 6ms.
6 ms is quite long:
I added a reset into tx_timeout, and that function should not take
On Mon, 5 Feb 2001, Manfred Spraul wrote:
6 ms is quite long:
I added a reset into tx_timeout, and that function should not take more
than 1 ms or so.
Did you find something about the delay in the documentation? Is it
possible to poll for reset completion?
I don't know how long. For
On 5 Feb 2001, at 9:38, Manfred Spraul wrote:
That's expected, my patch fixes another bug.
The NIC now recover from "Tx timeout" messages. ksa confirmed that,
but there is still a delay of a few seconds. I'll try to fix that.
Then I applyed your patch and still changed nothing as you
Thomas Stewart wrote:
Right, i patched the via-diag and its showing more regs.
I applyed Manfred's patch but that changed nothing.
Then I applyed your patch and still changed nothing as you suspected.
But there are regs that are different.
Several regs are just the wakeup frames, but
hi!
..I installed Manfred's patch and the d-link-card was now able to
reset after the tx-timeout-error. that means that the card was again
reachable after the error. but the smb-transfer-connection-error still
appeared. then I set "static int debug = 2;" in the patched
via-rhine.c to get more
On 4 Feb 2001, at 23:31, Urban Widmark wrote:
> On Sun, 4 Feb 2001, Manfred wrote:
>
> > Ok, I've attached a patch that performs an unconditional reset in
> > tx_timeout().
> >
> > I don't have the hardware, could you test it?
>
> The changed startup code doesn't break anything for me.
>
> >
Urban Widmark wrote:
>
> On Sun, 4 Feb 2001, Manfred Spraul wrote:
>
> > > Oh, that's known already. They haven't released any info on the older
> > > "VT3043" chip either, afaik. And the vt86c100a.pdf document is just a
> > > preliminary version.
> > >
> > Where can I find that file?
> > I'll
On Sun, 4 Feb 2001, Manfred Spraul wrote:
> > Oh, that's known already. They haven't released any info on the older
> > "VT3043" chip either, afaik. And the vt86c100a.pdf document is just a
> > preliminary version.
> >
> Where can I find that file?
> I'll try to implement tx_timeout()
Urban Widmark wrote:
>
> The "transmit timed out" message is simply saying that we told the card to
> send something but it hasn't generated an interrupt or anything allowing
> the driver to know the packet was actually sent.
>
check via_rhine_tx_timeout():
the function is basically empty.
>
>
> This sounds every much like it's related to the problems we're having with
> the card not initialising on reboot from Windows.
It's not the same problem. Here the card initializes just fine. And it
works for a while.
The "transmit timed out" message is simply saying that we told the card to
Hi,
>This sounds every much like it's related to the problems we're having with
>the card not initialising on reboot from Windows.
>
>What's the bets we're looking at a new revision of the chip which VIA
>haven't (publically) released documentation for yet? I'd say they're
>pretty high...
I
>/var/log/messages on the linux-server with the d-link dfe-530 tx:
>[THIS IS THE ERROR-MESSAGE!]
>Feb 1 17:25:56 Nethost kernel: NETDEV WATCHDOG: eth0: transmit timed out
>Feb 1 17:25:56 Nethost kernel: eth0: Transmit timed out, status ,
>PHY status 782d, resetting...
&
with the d-link dfe-530 tx:
[THIS IS THE ERROR-MESSAGE!]
Feb 1 17:25:56 Nethost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 17:25:56 Nethost kernel: eth0: Transmit timed out, status , PHY status
782d, resetting...
after booting everthing is fine (..until the big smb-transfer):
/var
with the d-link dfe-530 tx:
[THIS IS THE ERROR-MESSAGE!]
Feb 1 17:25:56 Nethost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 17:25:56 Nethost kernel: eth0: Transmit timed out, status , PHY status
782d, resetting...
after booting everthing is fine (..until the big smb-transfer):
/var
/var/log/messages on the linux-server with the d-link dfe-530 tx:
[THIS IS THE ERROR-MESSAGE!]
Feb 1 17:25:56 Nethost kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 17:25:56 Nethost kernel: eth0: Transmit timed out, status ,
PHY status 782d, resetting...
after booting everthing
Hi,
This sounds every much like it's related to the problems we're having with
the card not initialising on reboot from Windows.
What's the bets we're looking at a new revision of the chip which VIA
haven't (publically) released documentation for yet? I'd say they're
pretty high...
I had the
Urban Widmark wrote:
The "transmit timed out" message is simply saying that we told the card to
send something but it hasn't generated an interrupt or anything allowing
the driver to know the packet was actually sent.
check via_rhine_tx_timeout():
the function is basically empty.
Oh,
On Sun, 4 Feb 2001, Manfred Spraul wrote:
Oh, that's known already. They haven't released any info on the older
"VT3043" chip either, afaik. And the vt86c100a.pdf document is just a
preliminary version.
Where can I find that file?
I'll try to implement tx_timeout()
Urban Widmark wrote:
On Sun, 4 Feb 2001, Manfred Spraul wrote:
Oh, that's known already. They haven't released any info on the older
"VT3043" chip either, afaik. And the vt86c100a.pdf document is just a
preliminary version.
Where can I find that file?
I'll try to implement
On 4 Feb 2001, at 23:31, Urban Widmark wrote:
On Sun, 4 Feb 2001, Manfred wrote:
Ok, I've attached a patch that performs an unconditional reset in
tx_timeout().
I don't have the hardware, could you test it?
The changed startup code doesn't break anything for me.
I also found
On Wed, 13 Dec 2000, Alan Cox wrote:
> > > > Becker's site http://www.scyld.com/network.
> > > 2.4.x-test has some fixes for via-rhine which don't appear to have made
> > > it into the Becker driver yet...
> >
> > Is either of these likely to make it into the stock 2.2 via-rhine?
>
> If
On Wed, 13 Dec 2000, Alan Cox wrote:
Becker's site http://www.scyld.com/network.
2.4.x-test has some fixes for via-rhine which don't appear to have made
it into the Becker driver yet...
Is either of these likely to make it into the stock 2.2 via-rhine?
If someone ports them
Simon Huggins wrote:
> On Fri, Dec 08, 2000 at 09:56:15AM -0500, Jeff Garzik wrote:
> > Peter Horton wrote:
> > > If the PCI device ID is 3065 then it's via-rhine, but not supported
> > > by the driver in the kernel. Get updated via-rhine from Donald
> > > Becker's site
> > > Becker's site http://www.scyld.com/network.
> > 2.4.x-test has some fixes for via-rhine which don't appear to have made
> > it into the Becker driver yet...
>
> Is either of these likely to make it into the stock 2.2 via-rhine?
If someone ports them over for an earlyish 2.2.19pre
-
To
Hi Linux,
On Fri, Dec 08, 2000 at 09:56:15AM -0500, Jeff Garzik wrote:
> Peter Horton wrote:
> > If the PCI device ID is 3065 then it's via-rhine, but not supported
> > by the driver in the kernel. Get updated via-rhine from Donald
> > Becker's site http://www.scyld.com/network.
> 2.4.x-test has
Hi Linux,
On Fri, Dec 08, 2000 at 09:56:15AM -0500, Jeff Garzik wrote:
Peter Horton wrote:
If the PCI device ID is 3065 then it's via-rhine, but not supported
by the driver in the kernel. Get updated via-rhine from Donald
Becker's site http://www.scyld.com/network.
2.4.x-test has some
Becker's site http://www.scyld.com/network.
2.4.x-test has some fixes for via-rhine which don't appear to have made
it into the Becker driver yet...
Is either of these likely to make it into the stock 2.2 via-rhine?
If someone ports them over for an earlyish 2.2.19pre
-
To unsubscribe
Simon Huggins wrote:
On Fri, Dec 08, 2000 at 09:56:15AM -0500, Jeff Garzik wrote:
Peter Horton wrote:
If the PCI device ID is 3065 then it's via-rhine, but not supported
by the driver in the kernel. Get updated via-rhine from Donald
Becker's site http://www.scyld.com/network.
Peter Horton wrote:
>
> On Wed, Dec 06, 2000 at 07:44:02PM -0500, Mike A. Harris wrote:
> > Which ethernet module works with this card? 2.2.17 kernel
> >
>
> If the PCI device ID is 3065 then it's via-rhine, but not supported by the
> driver in the kernel. Get updated via-rhine from Donald
Peter Horton wrote:
On Wed, Dec 06, 2000 at 07:44:02PM -0500, Mike A. Harris wrote:
Which ethernet module works with this card? 2.2.17 kernel
If the PCI device ID is 3065 then it's via-rhine, but not supported by the
driver in the kernel. Get updated via-rhine from Donald Becker's
On Wed, Dec 06, 2000 at 07:44:02PM -0500, Mike A. Harris wrote:
> Which ethernet module works with this card? 2.2.17 kernel
>
If the PCI device ID is 3065 then it's via-rhine, but not supported by the
driver in the kernel. Get updated via-rhine from Donald Becker's site
It uses the via-rhine driver on my system
On Thu, 7 Dec 2000, James Bourne wrote:
> On Wed, 6 Dec 2000, Mike A. Harris wrote:
>
> > Which ethernet module works with this card? 2.2.17 kernel
>
> Should be the rtl8139 driver.
>
> Regards,
> Jim
>
> >
On Thu, 7 Dec 2000, Marco Colombo wrote:
> On Thu, 7 Dec 2000, James Bourne wrote:
>
> > The DFE-530TX is the viacom chipset, but the DFE530TX+ (Which I guess
> > replaces the 538 as that is no longer listed on the Dlink site) is an
> > rtl8139 chip.
>
> You mean that D-Link made a card named
On Thu, 7 Dec 2000, James Bourne wrote:
> On Thu, 7 Dec 2000, Alan Cox wrote:
>
> > > > Should be the rtl8139 driver.
> > >
> > > AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based.
> > > Mike, if you have problems, search list archives: a few people (including
> > > me)
On Thu, 7 Dec 2000, Alan Cox wrote:
> > > Should be the rtl8139 driver.
> >
> > AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based.
> > Mike, if you have problems, search list archives: a few people (including
> > me) reported problems under load. I've never solved them.
>
>
On Thu, 7 Dec 2000, Alan Cox wrote:
> > > Should be the rtl8139 driver.
> >
> > AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based.
> > Mike, if you have problems, search list archives: a few people (including
> > me) reported problems under load. I've never solved them.
>
>
> > Should be the rtl8139 driver.
>
> AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based.
> Mike, if you have problems, search list archives: a few people (including
> me) reported problems under load. I've never solved them.
2.2.18pre24 has the 8139too driver that Jeff Garzik
On Thu, 7 Dec 2000, James Bourne wrote:
> On Wed, 6 Dec 2000, Mike A. Harris wrote:
>
> > Which ethernet module works with this card? 2.2.17 kernel
>
> Should be the rtl8139 driver.
AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based.
Mike, if you have problems, search list
On Wed, 6 Dec 2000, Mike A. Harris wrote:
> Which ethernet module works with this card? 2.2.17 kernel
Should be the rtl8139 driver.
Regards,
Jim
> --
> Mike A. Harris - Linux advocate - Open source advocate
>
On Wed, 6 Dec 2000, Mike A. Harris wrote:
Which ethernet module works with this card? 2.2.17 kernel
Should be the rtl8139 driver.
Regards,
Jim
--
Mike A. Harris - Linux advocate - Open source advocate
Should be the rtl8139 driver.
AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based.
Mike, if you have problems, search list archives: a few people (including
me) reported problems under load. I've never solved them.
2.2.18pre24 has the 8139too driver that Jeff Garzik built
On Thu, 7 Dec 2000, Alan Cox wrote:
Should be the rtl8139 driver.
AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based.
Mike, if you have problems, search list archives: a few people (including
me) reported problems under load. I've never solved them.
2.2.18pre24 has
On Thu, 7 Dec 2000, Alan Cox wrote:
Should be the rtl8139 driver.
AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based.
Mike, if you have problems, search list archives: a few people (including
me) reported problems under load. I've never solved them.
2.2.18pre24
On Thu, 7 Dec 2000, James Bourne wrote:
On Thu, 7 Dec 2000, Alan Cox wrote:
Should be the rtl8139 driver.
AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based.
Mike, if you have problems, search list archives: a few people (including
me) reported problems under
On Thu, 7 Dec 2000, Marco Colombo wrote:
On Thu, 7 Dec 2000, James Bourne wrote:
The DFE-530TX is the viacom chipset, but the DFE530TX+ (Which I guess
replaces the 538 as that is no longer listed on the Dlink site) is an
rtl8139 chip.
You mean that D-Link made a card named DFE530TX VIA
It uses the via-rhine driver on my system
On Thu, 7 Dec 2000, James Bourne wrote:
On Wed, 6 Dec 2000, Mike A. Harris wrote:
Which ethernet module works with this card? 2.2.17 kernel
Should be the rtl8139 driver.
Regards,
Jim
On Wed, Dec 06, 2000 at 07:44:02PM -0500, Mike A. Harris wrote:
Which ethernet module works with this card? 2.2.17 kernel
If the PCI device ID is 3065 then it's via-rhine, but not supported by the
driver in the kernel. Get updated via-rhine from Donald Becker's site
Which ethernet module works with this card? 2.2.17 kernel
--
Mike A. Harris - Linux advocate - Open source advocate
This message is copyright 2000, all rights reserved.
Views expressed are my own, not
Which ethernet module works with this card? 2.2.17 kernel
--
Mike A. Harris - Linux advocate - Open source advocate
This message is copyright 2000, all rights reserved.
Views expressed are my own, not
57 matches
Mail list logo
