In the mainline kernel, p54usb will fail because the TX queue length can
become < 0. This problem has been reported as Bugzilla #13725. The failure
is expressed by the following message in the logs:
WARNING: at net/mac80211/tx.c:1325 ieee80211_tx+0x23c/0x298 [mac80211]()
Hardware name: HP Pavilion dv2700 Notebook PC
tx refused but queue active
This problem has been recently observed in the wireless-testing tree, where
a full solution is being tested. That fix is too invasive for 2.6.31-rcX,
but the simple change supplied here will prevent the failure.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Atheros top level menu needs a "depends WLAN_80211" to properly indent
within menuconfig and xconfig interfaces.
This is purely a visual issue but it effects all subsequent drivers.
The issue is the top level menu does not include a dependency on
WLAN_80211 so within the tree structure, Atheros is at the same level as
WLAN_80211 but when WLAN_80211 collapsed, the menu disappears along with
all subsequent drives, so it is really a subordinate.
Signed-off-by: Jay Sternberg <jay.e.sternberg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There's a race condition -- started can be set to true
before channel is set due to the way mac80211 callbacks
currently work (->start should probably pass the channel
we would like to have initially). For now simply add a
check to hwsim to avoid dereferencing the NULL channel
pointer.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Added support for the Broadcom 4318E chipset on PCMCIA/CF cards. The
4318E can do 802.11A/B/G, only B and G mode are supported in b43.
Signed-off-by: Clyde McPherson <ccmcphe@verizon.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Yevgen Kotikov reported success on the sourceforge zd1211-devs list
with the following details:
Brand/retail: SONY IFU-WLM2
USB-IDs: Vendor: 0x054C Device: 0x0257
chip ID: zd1211b chip 054c:0257 v4802 high 00-0b-6b AL2230_RF pa0 -----
FCC ID: unknown
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Tested-by: Yevgen Kotikov <yevgen.kotikov@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On a shuttle machine here we got 07b8:6001 device, handled by zd1211rw, which does not work.
Scanning is OK but association does not work, we get "direct probe to AP xxx timed out"
It appears that this simple patch makes the device work perfectly.
This id was already there in initial import of the driver so I don't know if it has ever been
working as ZD1211 (which would mean they changed it and kept the id :( ).
Signed-off-by: Pascal Terjan <pterjan@mandriva.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We're missing a Kconfig help for the iwmc3200wifi driver.
Signed-off-by: Samuel Ortiz <samuel.ortiz@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When we reclaim the tx desc, we always assume that the
last desc is a holding desc, which is not true, and skip it.
If the tx queue is drained during channel change, internal
reset and etc, the last descriptor may not be the holding
descriptor and we fail to reclaim them. This results in the
following two issues.
1. Tx stuck - We drop all the frames coming from upper layer
due to shortage in tx desc.
2. Crash - If we fail to reclaim a tx descriptor, we miss to
update the tx BA window with the seq number of the frame
associated to that desc, which, at some point, result in
the following crash due to an assert failure in ath_tx_addto_baw().
This patch fixes these two issues.
kernel BUG at ../drivers/net/wireless/ath/ath9k/xmit.c:180!
[155064.304164] invalid opcode: 0000 [#1] SMP
Call Trace:
[<fbc6d83b>] ? ath9k_tx+0xeb/0x160 [ath9k]
[<fbbc9591>] ipv6? __ieee80211_tx+0x41/0x120 [mac80211]
[<fbbcb5ae>] ? aes_i586ieee80211_master_start_xmit+0x28e/0x560 [mac80211]
[<c037e501>] aes_generic? _spin_lock_irqsave+0x31/0x40
[<c02f347b>] ? dev_hard_start_xmit+0x16b/0x1c0
[<c03058b5>] ? __qdisc_run+0x1b5/0x200
[<fbbcda5a>] ? af_packetieee80211_select_queue+0xa/0x100 [mac80211]
[<c02f53b7>] ? i915dev_queue_xmit+0x2e7/0x3f0
[<fbbc9b49>] ? ieee80211_subif_start_xmit+0x369/0x7a0 [mac80211]
[<c031bc35>] ? ip_output+0x55/0xb0
[<c02e0188>] ? show_memcpy_count+0x18/0x60
[<c02eb186>] ? __kfree_skb+0x36/0x90
[<c02f2202>] ? binfmt_miscdev_queue_xmit_nit+0xd2/0x110
[<c02f347b>] ? dev_hard_start_xmit+0x16b/0x1c0
[<c03058b5>] ? __qdisc_run+0x1b5/0x200
[<c033bca7>] ? scoarp_create+0x57/0x2a0
[<c02f53b7>] ? bridgedev_queue_xmit+0x2e7/0x3f0
[<c03034a0>] ? eth_header+0x0/0xc0
[<c033b95f>] stp? arp_xmit+0x5f/0x70
[<c033bf4f>] ? arp_send+0x5f/0x70
[<c033c8f5>] bnep? arp_solicit+0x105/0x210
[<c02fa5aa>] ? neigh_timer_handler+0x19a/0x390
[<c013bf88>] ? run_timer_softirq+0x138/0x210
[<c02fa410>] ? ppdevneigh_timer_handler+0x0/0x390
[<c02fa410>] ? neigh_timer_handler+0x0/0x390
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix condition in which radio LED did not initialize correctly, and remove
4 compilation warnings.
After the recent changes in rfkill, the radio LED used by b43/b43legacy
did not always initialize correctly.
Both b43 and b43legacy used the deprecated variable radio_enabled in
struct ieee80211_conf.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Eric Dumazet a écrit :
> Ingo Molnar a écrit :
>>> The following changes since commit 5298976562:
>>> Linus Torvalds (1):
>>> Merge git://git.kernel.org/.../davem/net-2.6
>>>
>>> are available in the git repository at:
>>>
>>> master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
>> Hm, something in this lot quickly wrecked networking here - see the
>> tx timeout dump below. It starts with:
>>
>> [ 351.004596] WARNING: at net/sched/sch_generic.c:246 dev_watchdog+0x10b/0x19c()
>> [ 351.011815] Hardware name: System Product Name
>> [ 351.016220] NETDEV WATCHDOG: eth0 (forcedeth): transmit queue 0 timed out
>>
>> Config attached. Unfortunately i've got no time to do bisection
>> today.
>
>
>
> forcedeth might have a problem, in its netif_wake_queue() logic, but
> I could not see why a recent patch could make this problem visible now.
>
> CPU0/1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
> is not a new cpu either :)
>
> forcedeth uses an internal tx_stop without appropriate barrier.
>
> Could you try following patch ?
>
> (random guess as I dont have much time right now)
We might have a race in napi_schedule(), leaving interrupts disabled forever.
I cannot test this patch, I dont have the hardware...
Tested-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: David S. Miller <davem@davemloft.net>
The call resource_size(res) returns res->end - res->start + 1 and thus the
second change is semantics-preserving. res_size is then used as the second
argument of a call to request_mem_region, and the memory allocated by this
call appears to be the same as what is released in the two calls to
release_mem_region. So the size argument for those calls should be
resource_size(size) as well. Alternatively, in the second call to
release_mem_region, the second argument could be res_size, as that variable
has already been initialized at the point of this call.
The problem was found using the following semantic patch:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@
struct resource *res;
@@
- (res->end - res->start) + 1
+ resource_size(res)
@@
struct resource *res;
@@
- res->end - res->start
+ BAD(resource_size(res))
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
add new id (RIOS System PC CARD3 ETHERNET).
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch properly defines the maximum values for rx/tx coalescing timeouts.
Signed-off-by: Vlad Zolotarov <vladz@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Problem reported by Flavio Leitner <fleitner@redhat.com>:
When setting rx/tx coalescing timeout to the values less than 12 traffic was
stopped.
The FW supports coalescing in 12us granularity, and so value of less then 12
should be interpreted as disabling coalescing
Signed-off-by: Vlad Zolotarov <vladz@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It is currently possible for an asynchronous device unregister
to cause the same tun device to be unregistered twice. This
is because the unregister in tun_chr_close only checks whether
__tun_get(tfile) != NULL. This however has nothing to do with
whether the device has already been unregistered. All it tells
you is whether __tun_detach has been called.
This patch fixes this by using the most obvious thing to test
whether the device has been unregistered.
It also moves __tun_detach outside of rtnl_unlock since nothing
that it does requires that lock.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Occasionally we may see an interrupt without an event in the eq.
In intx, we currently see the event queue and return IRQ_NONE causing
a the irq to be disabled ("no one cared".) Instead, read the CEV_ISR
reg to check the existence of the interrupt.
Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This workaround is required for an issue in hardware where noise on the
interconnect between the MAC and PHY could be generated by a lower power
mode (K1) at 1000Mbps resulting in bad packets. Disable K1 while at 1000
Mbps but keep it enabled for 10/100Mbps and when the cable is disconnected.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some PHYs may require two reads of the PHY_STATUS register to determine the
link status. If the PHY is being accessed by another thread it is possible
the first read could timeout and fail. In this case, put a delay in so
the second read will pick up the correct link status.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Limit NVM writes to 4K sections to prevent NVM corruption on larger
sector allocations (up to 64K).
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The driver was accessing register bits for features on parts that do
not support that feature. This could cause problems in the hardware.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A previous workaround for 82578 to avoid link stall causes some PHY
registers to get cleared inadvertently. Add a delay after all LCD resets
to make sure PHY registers are in a stable state before continuing. Also,
after resets check the EEC register for the state of PHY configuration
performed by the MAC for ICH9 and earlier parts (as done before), but check
the LAN_INIT_DONE bit in the STATUS register for ICH10 and newer parts (EEC
doesn't exist in these newer parts).
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
PHY loopback on 82578 fails to work as a result of flushing the packets
in the FIFO buffer in the link stall workaround. Don't perform the
workaround if in PHY loopback mode.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Wake-on-lan is currently only supported by 82599 KX4 devices, in all
other cases return a proper value from ixgbe_wol_exclusion function call.
Otherwise from ethtool we will be able to change wol options of
unsupported 8259x devices.
Signed-off-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently if we loaded the driver, insert an unsupported module, and then
attempt to "ifconfig up" the device it will be brought down but the netdev
would not be unregistered. This behavior is different than all other
code paths. This patch corrects that by down'ing the device and then
scheduling the sfp_config_module_task tasklet. The tasklet will detect
this condition (like it does with other code paths) and do the
unregister_netdev().
I also removed the log message as this condition (an unsupported SFP+
module) will be logged in sfp_config_module_task.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The change to check the SFP+ module again on open() was
causing the XFP (non-SFP+) adapters to be rejected. We
only want to try and re-identify the SFP+ module if the
original probe found that this device was an SFP+ device.
So for this code path (driver loaded with SFP module, module
inserted, ifconfig up of the device) the type will be
ixgbe_phy_unknown for an unidentified SFP+ module. So we
only check if that is the case.
This problem also shows up on Copper devices.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Several small fixes around negative test case of the insertion of a
IXGBE_ERR_NOT_SUPPORTED module.
- mdio45_probe call was always failing due to mdio.prtad not being
set. The function set to mdio.mdio_read was still working as we just
happen to always be at prtad == 0. This will allow us to set the phy_id
and phy.type correctly now.
- There was timing issue with i2c calls when initiated from a tasklet.
A small delay was added to allow the electrical oscillation to calm down.
- Logic change in ixgbe_sfp_task that allows NOT_SUPPORTED condition
to be recognized.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some usage was only sizing a pointer rather than the data type.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We need to set/clear the mac address register when the link goes up/down
respectively. Without this both ports of a 2-port device can end up
with the same mac address in a bonding scenario.
The new ql_link_on() and ql_link_off() will also be used in handling
certain firmware events.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This addes functionality to set/clear the MAC address in the hardware
when the link goes up/down.
The MAC address register is persistent across function resets. In
bonding the same address can bounce from one port to the other. This
can cause packets to be delivered to the wrong port.
This patch clears the MAC address in the hardware when the link is down
and sets it when the link comes up.
It was found that pulling/pushing the cable from one port to another
causes the same MAC address to be in both ports.
The next patch in this series will use this functionality as well.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The caller will free acquired resouces if a failure occurs.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We were turning on the carrier without verifying the link was up.
This adds link up to the link initialize check before turning carrier
on.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Not clearing the routing bits can cause frames to erroneously get routed to
management processor.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The hardware semaphore covers the configuration register as well as the
ICB registers. The ICB high and low regs contain the address of the
initialization control block and the config register is used to signal
the hardware that a block is ready to be downloaded. Currently we were
only protecting the ICB regs. This changes expands to cover the config
register as well.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The PHY_HALTED state disables phydev->link, but the link will not be
updated upon entering PHY_RESUMING. Add a call to phy_read_status() to
update the link before entering PHY_RUNNING. If the link is not up at
this point, enter the PHY_NOLINK state instead.
Also, when transitioning from PHY_RESUMING to PHY_RUNNING, calls to
netif_carrier_on() and phydev->adjust_link() are missing. Add the calls
similar to the other transitions to PHY_RUNNING.
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
Acked-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Restrict firmware reset to following cases -
o chip rev is NX2031 (firmare doesn't support heartbit).
o firmware is dead.
o previous attempt to init firmware had failed.
o we have got newer file firmware.
This speeds up module load tremendously (by upto 8 sec),
also avoids downtime for NCSI (management) pass-thru
traffic.
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Correct firmware encoding is 8 bit major, 8 bit minor and
16 bit subversion. Flash has sizes rightly set, but original
driver submission messed it leaving 16 bit major and 8 bit
subversion.
Also fix a infinite loop when cut-thru file firmware is
invalid.
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
PCI drivers that implement the io_error_detected callback should return
PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for igb.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
on permanent failure
PCI drivers that implement the io_error_detected callback
should return PCI_ERS_RESULT_DISCONNECT if the state
passed in is pci_channel_io_perm_failure. This state is not
checked in many of the network drivers.
This patch fixes the omission in the e1000e driver.
Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
PCI drivers that implement the io_error_detected callback
should return PCI_ERS_RESULT_DISCONNECT if the state
passed in is pci_channel_io_perm_failure. This state is
not checked in many of the network drivers.
The patch fixes the omission in the e1000 driver.
Based on Mike Mason's similar patch for e1000e.
Signed-off-by: Andre Detsch <adetsch@br.ibm.com>
CC: Mike Mason <mmlnx@us.ibm.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
driver was mixing NET_IP_ALIGN count bytes in map/unmap calls
unevenly. Only map the bytes that the hardware might dma into
also fix unmap related bug where ->dma was not being cleared
after unmap
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch addresses three WARN_ON statements from DMA-API debug code
ixgbe is mapping more than it unmaps, reduce the length of the map call and
remove the "used once" local variable.
found by Joerg Roedel <joerg.roedel@amd.com> in 2.6.30, so is a candidate
for -stable.
in addition, fix missing ->dma = 0 after unmap to prevent double free with
pci_unmap_single
and lastly, don't unmap (half) pages that aren't mapped.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Adapter link advertisement capabilities were not persistent during
adapter resets. While configuring multispeed fiber link check for
phy autoneg_advertised settings before overwriting with default
link capabilities
Signed-off-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
82599 single speed fiber modules only support 10G/Full. Return
proper device capabilities while querrying the adapter and error
while changing device advertisement/speed/duplex capabilities.
Signed-off-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We had a wide range of log messages for the same sort of SFP
failure. This patch makes them all more similar and less
confusing along with converting them to dev_err.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Now that netdev has its own stats structure we should use that
instead.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Now that netdev has its own stats structure we should use that
instead.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
