[2.5][Trivial] VIA Rhine Kconfig entry
PATCH 1/1 [2.5][Trivial] VIA Rhine Kconfig entry
Fix and update VIA Rhine description at least for 2.5 (I'll do 2.4, too, if there's interest). Removed "experimental" flag for Rhine MMIO while I was at it. Just barely resisted the temptation to make VIA Rhine conflict with IO-APIC -- that seems to emerge as a fatal combo.
Please apply.
Roger
drivers/net/Kconfig renamed from drivers/net/Kconfig.orig +8 -6
@@ -1426,8 +1426,10 @@ tristate "VIA Rhine support" depends on NET_PCI && PCI help - If you have a VIA "rhine" based network card (Rhine-I (3043) or - Rhine-2 (VT86c100A)), say Y here. + If you have a VIA "Rhine" based network card (Rhine-I (VT86C100A), + Rhine-II (VT6102), or Rhine-III (VT6105)), say Y here. Rhine-type + Ethernet functions can also be found integrated on South Bridges + (e.g. VT8235). This driver is also available as a module ( = code which can be inserted in and removed from the running kernel whenever you want).
@@ -1436,15 +1438,15 @@ well as <file:Documentation/networking/net-modules.txt>. config VIA_RHINE_MMIO - bool "Use MMIO instead of PIO (EXPERIMENTAL)" - depends on VIA_RHINE && EXPERIMENTAL + bool "Use MMIO instead of PIO" + depends on VIA_RHINE help This instructs the driver to use PCI shared memory (MMIO) instead of programmed I/O ports (PIO). Enabling this gives an improvement in processing time in parts of the driver. - It is not known if this works reliably on all "rhine" based cards, - but it has been tested successfully on some DFE-530TX adapters. + It is not known if this works reliably on all "Rhine" based cards, + but it has been tested successfully on several adapters. If unsure, say N.
Quoted 2 lines · Roger Luethi
at it. Just barely resisted the temptation to make VIA Rhine conflict with IO-APIC -- that seems to emerge as a fatal combo.
Patch looks ok to me, I'll queue it.
I agree about IO-APIC -- though I also think the reports that replacing via-rhine with linuxfet, and changing nothing else, helps the situation.
It might be something cosmetic like silly dev->tx_timeout handling, or it might be something useful like a chip-specific patch [often happens with on-mobo chips] or even a north/south-bridge-specific fixup.
Jeff
Quoted 6 lines · Jeff Garzik
I agree about IO-APIC -- though I also think the reports that replacing via-rhine with linuxfet, and changing nothing else, helps the situation.
It might be something cosmetic like silly
dev->tx_timeouthandling, or it might be something useful like a chip-specific patch [often happens with on-mobo chips] or even a north/south-bridge-specific fixup.
There are two different kinds of Rhine problems that are reportedly fixed by turning apic support off:
a) No link, card's dead in the water
b) Netdev watchdog triggered despite recent Tx abort fix
No telling whether the cause is the same for both cases. I don't have sufficient data on mobos or chip sets involved and where linuxfet helps. As I am currently short on APIC hardware myself, I'll focus on clean ups and improved diagnostics for now.
Roger
Is it possible that this may be related to this thread???
To: Linus Torvalds <[email protected]>
Subject: Re: /proc/pci deprecation?
From: Alan Cox <[email protected]>
Date: 09 Dec 2002 14:11:07 +0000
Cc: Richard Henderson <[email protected]>,
Patrick Mochel <[email protected]>,
Willy Tarreau <[email protected]>,
Petr Vandrovec <[email protected]>,
Linux Kernel Mailing List <[email protected]>, [email protected]
Quoted 4 lines · Linus Torvalds
- we should _never_ update the
PCI_INTERRUPT_LINEregister, because it destroys boot loader information (the same way we need to not overwrite BIOS extended areas and ACPI areas etc in order to be able to reboot cleanly)
I wonder if this is why we have all these problems with VIA chipset interrupt handling. According to VIA docs they _do_ use PCI_INTERRUPT_LINE on integrated devices to select the IRQ routing between APIC and PCI/ISA etc, as well as 0 meaning "IRQ disabled"
Alan
Quoted 25 lines · you
Quoted 6 lines · Jeff Garzik
I agree about IO-APIC -- though I also think the reports that replacing via-rhine with linuxfet, and changing nothing else, helps the situation.
It might be something cosmetic like silly
dev->tx_timeouthandling, or it might be something useful like a chip-specific patch [often happens with on-mobo chips] or even a north/south-bridge-specific fixup.There are two different kinds of Rhine problems that are reportedly fixed by turning apic support off:
a) No link, card's dead in the water
b) Netdev watchdog triggered despite recent Tx abort fixNo telling whether the cause is the same for both cases. I don't have sufficient data on mobos or chip sets involved and where linuxfet helps. As I am currently short on APIC hardware myself, I'll focus on clean ups and improved diagnostics for now.
Roger
-
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/
Quoted 1 line · Steve Brueggeman
Is it possible that this may be related to this thread???
I am sure it is