This reverts commit 84cd2dfb04.
Some BIOS's break if Wake On Lan is enabled, and the machine
can't boot. Better to have some user's have to call ethtool to
enable WOL than to break a single user's boot.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The driver checks status of PCI power management to mark
default setting of Wake On Lan. On some systems this works, but often
it reports a that WOL is disabled when it isn't.
This patch gets rid of that check and just reports the wake on
lan status based on the hardware capablity.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
When we add the generic napi_disable_pending() breakout
logic to net_rx_action() it means that napi_disable()
can cause NAPI poll interrupt events to be disabled.
And this is exactly what we want. If a napi_disable()
is pending, and we are looping in the ->poll(), we want
->poll() event interrupts to stay disabled and we want
to complete the NAPI poll ASAP.
When ->poll() break out during device down was being handled on a
per-driver basis, often these drivers would turn interrupts back on
when '!netif_running()' was detected.
And this would just cause a reschedule of the NAPI ->poll() in the
interrupt handler before the napi_disable() could get in there and
grab the NAPI_STATE_SCHED bit.
The vast majority of drivers don't care if napi_disable() might have
the side effect of disabling NAPI ->poll() event interrupts. In all
such cases, when a napi_disable() is performed, the driver just
disabled interrupts or is about to.
However there were three exceptions to this in PCNET32, R8169, and
SKY2. To fix those cases, at the subsequent napi_enable() points, I
added code to ensure that the ->poll() interrupt events are enabled in
the hardware.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Don Fry <pcnet32@verizon.net>
I'm using a Marvell 88E8062 on a custom PPC64 blade and ran into RX
lockups while validating the sky2 driver. The receive MAC FIFO would
become stuck during testing with high traffic. One port of the 88E8062
would lockup, while the other port remained functional. Re-inserting
the sky2 module would not fix the problem - only a power cycle would.
I looked over Marvell's most recent sk98lin driver and it looks like
they had a "workaround" for the Yukon XL that the sky2 doesn't have yet.
The sk98lin driver disables the RX MAC FIFO flush feature for all
revisions of the Yukon XL.
According to skgeinit.c of the sk98lin driver, "Flushing must be enabled
(needed for ASF see dev. #4.29), but the flushing mask should be
disabled (see dev. #4.115)". Nice. I implemented this same change in
the sky2 driver and verified that the RX lockup I was seeing was
resolved.
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Prevent deadlock in sky2 recovery logic. sky2_down calls napi_synchronize
which gets stuck if napi was already disabled.
Fix by rearranging slightly and not calling napi_disable until after
both ports are stopped. The napi_disable probably is being overly
paranoid, but it is safe now.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Add workaround for issues FE+ (A0) transmit watermark.
This is copied verbatim from vendor driver sk98lin (10.22.4.3).
Don't have that chip version and no more information seems to be available.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Using PCIE advanced error recovery stuff creates more user problems than it's worth.
The AER stuff depends on MMCONFIG and in many configurations it just doesn't work.
Plus it doesn't add any real functionality to the driver. The sky2
driver handles its own errors fine as is.
This reverts 555382cbfc
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Using the hardware window into PCI config space is more reliable
and smaller/faster than using the pci_config routines. It avoids issues
with MMCONFIG etc.
Reverts: 167f53d05f
Please apply for 2.6.24
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The Marvell Yukon XL chipset appears to have a hardware glitch
where it will repeat the checksum of the last packet. Of course, this is
timing sensitive and only happens sometimes...
More info: http://bugzilla.kernel.org/show_bug.cgi?id=9381
As a workaround just disable hardware checksumming by default on
this chip version. The earlier workaround for PCIX, dual port
was also on Yukon XL so don't need to disable checksumming there.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Found a couple of more chips in the latest version of the vendor driver.
They are minor variations on existing chips.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Netpoll will only work on port 0 because of the restrictive
relationship between NAPI and netpoll.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The PCI AER support may not work for a couple of reasons.
It may not be configured into the kernel or there may be a BIOS
bug that prevents MMCONFIG from working. If MMCONFIG doesn't work
then the PCI registers that control AER will not be accessible via
pci_read_config functions; luckly there is another window to access
PCI space in the device, so use that.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The IRQ's is already masked on shutdown, and on startup avoid
touching PHY until after phy_init().
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Don't need to change LED's after auto negotiation, the chip
sets them correctly.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The D-Link PCI-X board (and maybe others) can lie about status
ring entries. It seems it will update the register for last status
index before completing the DMA for the ring entry. To avoid reading
stale data, zap the old entry and check.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
On some boards, PCI configuration space access is turned off by default.
The 2.6.24 driver doesn't turn it on, and should have.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Solve issues with dual port devices due to shared NAPI.
* shutting down one device shouldn't kill other one.
* suspend shouldn't hang.
Also fix potential race between restart and shutdown.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The call to napi_disable() in the PCI shutdown handler is problematic,
and is aggravated by the new NAPI.
Also, make sure watchdog timer doesn't go off.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Stephen Hemminger
Stephen Hemminger
David S. Miller
Linus Torvalds
Joe Perches