* Re: Jumbo frame question...
From: Lennart Sorensen @ 2009-07-24 18:45 UTC (permalink / raw)
To: Rick Jones; +Cc: David Miller, rgetz, netdev
In-Reply-To: <4A69E3CF.1040805@hp.com>
On Fri, Jul 24, 2009 at 09:39:43AM -0700, Rick Jones wrote:
> In so far as there is no de jure spec for Jumbo Frames, it is rather
> difficult to have a spec violation :).
>
> Not a case of too much rope? Given that (IIRC) Jumbo Frame was not
> introduced in Ethernet NICs until Gigabit came along (eg Alteon), the
> chances a (legacy) 100 Mbit/s network would have JF-capable NICs is
> epsilon.
Nothing would prevent you from using a 100Mbit fiber PHY on a gigabit
capable network port, so you could have a 100Mbit port that supported
jumbo frames.
--
Len Sorensen
^ permalink raw reply
* Re: ixgbe: panic in ixgbe_clean_rx_irq()
From: Waskiewicz Jr, Peter P @ 2009-07-24 18:47 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: Waskiewicz Jr, Peter P, netdev@vger.kernel.org
In-Reply-To: <1248424910.17215.54.camel@localhost.localdomain>
On Fri, 24 Jul 2009, Jesper Dangaard Brouer wrote:
> On Thu, 2009-07-23 at 17:21 +0200, Jesper Dangaard Brouer wrote:
> > I'm going to run a test with a no-preempt kernel over night...
>
> The no-preempt kernel has been stable for 17 hours, while running a four
> times 10GbE pktgen load test (using 1024 bytes packets).
>
> Kernel git version (git describe):
> v2.6.31-rc1-932-g8e321c4
>
> Git ("git log e594e96..8e321c4 drivers/net/ixgbe") reports not changes
> to the ixgbe driver between these two kernel versions.
Thanks for the additional info Jesper. This is definately a good data
point. I'm not sure where to go with the preemption debugging at this
point with our driver under heavy load. We're still trying to repro here.
I'll keep digging around though in the meantime.
This is the second preemption-induced bug from ixgbe we've had reported in
a few days. Eek!
Cheers,
-PJ Waskiewicz
^ permalink raw reply
* Re: Jumbo frame question...
From: Eric Dumazet @ 2009-07-24 19:13 UTC (permalink / raw)
To: Robin Getz; +Cc: Rick Jones, David Miller, netdev
In-Reply-To: <200907241421.55986.rgetz@blackfin.uclinux.org>
Robin Getz a écrit :
> On Fri 24 Jul 2009 12:39, Rick Jones pondered:
>> David Miller wrote:
>>> From: Robin Getz <rgetz@blackfin.uclinux.org>
>>> Date: Fri, 24 Jul 2009 11:41:55 -0400
>>>
>>>> Should a gigabit card, configured as 100, be sending jumbo UDP frames?
>>>>
>>>> My understanding, is no - this is a spec violation..
>> In so far as there is no de jure spec for Jumbo Frames, it is rather
>> difficult to have a spec violation :).
>
> The spec I was talking about was the MTU...
>
> rgetz@pinky:~> /sbin/ifconfig eth0
> eth0 Link encap:Ethernet HWaddr 00:11:11:B0:A5:D4
> inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0
> inet6 addr: fe80::211:11ff:feb0:a5d4/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:45978 errors:5 dropped:0 overruns:0 frame:0
> TX packets:44536 errors:0 dropped:0 overruns:0 carrier:0
> collisions:3193 txqueuelen:1000
> RX bytes:11583575 (11.0 Mb) TX bytes:20025122 (19.0 Mb)
> Interrupt:16
>
>
> My MTU is 1500, but when tftp requests a block size of over that - the host
> does not fragment it (like I thought it should).
Which broken driver would do this me asking, and how can you be sure a jumbo frame was ever sent ?
I guess your tcpdump is fooled by gso settings... Did you tried
# ethtool -K eth0 gso off
^ permalink raw reply
* [PATCH] ip: fix logic of reverse path filter sysctl
From: Stephen Hemminger @ 2009-07-24 19:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Even though reverse path filter was changed from simple boolean to trinary control,
the loose mode only works if both all and device are configured because of
this logic error.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/include/linux/inetdevice.h 2009-07-24 12:24:54.537399657 -0700
+++ b/include/linux/inetdevice.h 2009-07-24 12:25:11.457119906 -0700
@@ -82,7 +82,7 @@ static inline void ipv4_devconf_setall(s
#define IN_DEV_FORWARD(in_dev) IN_DEV_CONF_GET((in_dev), FORWARDING)
#define IN_DEV_MFORWARD(in_dev) IN_DEV_ANDCONF((in_dev), MC_FORWARDING)
-#define IN_DEV_RPFILTER(in_dev) IN_DEV_ANDCONF((in_dev), RP_FILTER)
+#define IN_DEV_RPFILTER(in_dev) IN_DEV_MAXCONF((in_dev), RP_FILTER)
#define IN_DEV_SOURCE_ROUTE(in_dev) IN_DEV_ANDCONF((in_dev), \
ACCEPT_SOURCE_ROUTE)
#define IN_DEV_BOOTP_RELAY(in_dev) IN_DEV_ANDCONF((in_dev), BOOTP_RELAY)
^ permalink raw reply
* pull request: wireless-next-2.6 2009-07-24
From: John W. Linville @ 2009-07-24 19:36 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
Dave,
Here is the latest huge round of wireless patches intended for 2.6.32.
It hits all the usual areas (i.e. drivers, mac80211, and cfg80211) with
patches from all the usual suspects. This includes the reworking of
mac80211 to eliminate the confusing "master netdev".
FWIW, my laptop has been happy with it. Most of the bits here have been
in -next for at least a few days.
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6/
---
The following changes since commit 74d154189d597b91da4322996dbf4f5c3d1544ab:
David S. Miller (1):
Merge branch 'master' of master.kernel.org:/.../davem/net-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Christian Lamparter (8):
p54: re-enable power save feature
p54: generate channel list dynamically
ar9170: implement transmit aggregation
p54: remove useless code
p54: fix beaconing related firmware crash
p54: fix a fw crash caused by statistic feedback
mac80211: do not monitor the connection while scanning
mac80211: fix spare warnings in driver-trace.h
Gabor Juhos (5):
ath9k: serialize ath9k_hw_setpower calls
ath9k: uninline ath9k_ps_{wakeup,restore} functions
ath9k: serialize ath9k_ps_{wakeup,restore} calls
ath9k: wake up the chip for TSF reset
ath9k: make use ath9k_hw_wait int ath9k_hw_reset_tsf
Gábor Stefanik (1):
cfg80211: fix disabling WPA via wext (SIOCSIWAUTH)
Helmut Schaa (1):
cfg80211: update misleading comment
Hin-Tak Leung (2):
zd1211rw: adding Accton Technology Corp (083a:e501) as a ZD1211B device
rtl8187: updating Kconfig with info of branded devices
Ivo van Doorn (1):
rt2x00: Remove DEVICE_STATE_DISABLED_RADIO_HW
Javier Cardona (2):
mac80211: Assign next hop address to pending mesh frames
mac80211: Fix regression in mesh forwarding path.
Jay Sternberg (2):
iwlwifi: Handle new firmware file with ucode build number in header
iwlwifi: update 1000 series API version to match firmware
Jiri Slaby (1):
wireless: wl12xx, fix lock imbalance
Joe Perches (1):
MAINTAINERS: Update rtl8180 patterns
Johannes Berg (25):
mac80211: fix sparse warning
mac80211: driver operation debugging
cfg80211: fix race in giwrate
cfg80211: fix two buglets
nl80211: introduce new key attributes
cfg80211: rework key operation
mac80211: fix multi-use timer
mac80211: monitor the connection
cfg80211: fix a locking bug
mac80211: mesh: fix two small problems
cfg80211: fix wext stats
mac80211_hwsim: report fixed signal strength
cfg80211: don't look at wdev->ssid for giwessid
cfg80211: fix wext setting SSID
nl80211: report BSS status
cfg80211: fix more bugs in mlme handling
mac80211: cancel the connection monitor timers/work
cfg80211: fix unregistration
iwlwifi: make some logging functions static/unexport
wireless: remove print_mac uses
cfg80211: don't optimise wext calls too much
net: export __dev_addr_sync/__dev_addr_unsync
mac80211: remove master netdev
net: remove unused skb->do_not_encrypt
mac80211: fix ieee80211_xmit call context
Julia Lawall (1):
drivers/net: Drop unnecessary NULL test
Kalle Valo (3):
wl1251: remove accidentally added wl1251_netlink.c
wl1251: remove wl1251_plt_start/stop()
MAINTAINERS: add wl1251 wireless driver
Larry Finger (2):
hostap_cs: Enable shared interrupts
p54: Eliminate unnecessary initialization
Luis Correia (1):
rt2x00: Comment spellchecking
Luis R. Rodriguez (21):
mac80211: drop frames for sta with no valid rate
ath9k: downgrade assert in rc.c for invalid rate
iwlwifi: remove rs_get_rate workaround
ath9k: cleanup try count for MRR in rate control
ath9k: remove unused min rate calculation code
ath9k: remove unused stepdown when looking for the next rate
ath9k: remove pointless wrapper ath_rc_rate_getidx()
ath9k: rename ath_rc_get_nextlowervalid_txrate()
ath9k: remove unused ath_rc_isvalid_txmask()
ath9k: remove ATH9K_MODE_11B
ath9k: remap ATH9K_MODE_*
ath9k: rename ath_rc_ratefind_ht() to ath_rc_get_highest_rix()
ath9k: remove unnecessary IEEE80211_TX_CTL_NO_ACK checks
mac80211: make minstrel/pid RC use ieee80211_is_data(fc)
iwlwifi: use ieee80211_is_data(fc)
mac80211: add helper for management / no-ack frame rate decision
ath9k: remove rate control wraper
ath9k: disable radio when all devices are marked idle
cfg80211: treat ieee80211_regdom hints as user hints
ath9k: do not stop the queues in driver stop
adm8211: remove uneeded code during suspend/resume
Marcin Slusarz (1):
wireless: fix supported cards for rtl8187
Pavel Roskin (1):
ath5k: fix values for bus error bits in ISR2
Reinette Chatre (7):
iwlwifi: fix permissions on debugfs files
iwl3945: cleanup number of queues settings
iwlagn: fix minimum number of queues setting
iwlagn: do not send key clear commands when rfkill enabled
iwlwifi: make debug level more user friendly
iwlwifi: clarify hardware error message
iwlwifi: inform user about rfkill state changes
Roel Kluin (1):
arlan: inverted logic?
Samuel Ortiz (1):
iwmc3200wifi: cfg80211 managed mode port
Senthil Balasubramanian (3):
ath9k: Manipulate and report the correct RSSI
ath9k: RX stucks during heavy traffic in HT40 mode.
ath9k: Fix TX hang issue with Atheros chipsets
Stefan Steuerwald (1):
rt2x00: Implement set_tim callback for all drivers
Stefan Weil (1):
wl12xx: fix spelling
Vasanthakumar Thiagarajan (7):
ath9k: Remove dead code in rate control
ath9k: Remove unused members from rate control structure
ath9k: Use probe interval instead of rssi reduce interval
ath9k: Nuke struct ath_tx_ratectrl_state
ath9k: Remove bogus assert in ath_clone_txbuf()
ath9k: Handle tx desc shortage more appropriately
ath9k: Remove pointless ath9k_ps_restore() in ath_detach()
Vivek Natarajan (1):
ath9k: Add AR9287 based chipsets' register information.
Wey-Yi Guy (9):
iwlwifi: move show_qos to debugfs
iwlagn: modify digital SVR for 1000
iwlwifi: fix rx signal quality reporting in dmesg
iwlwifi: make led functions generic
iwlwifi: add led debugfs function
iwlwifi: Led blinking counting both tx and rx
iwlwifi: checking unknown HW type
iwlwifi: uCode Alive notification with timeout
iwlwifi: change iwl_enable/disable_interrupts to "inline"
Zhu Yi (15):
cfg80211: fix NULL dereference in IBSS SIOCGIWAP
iwmc3200wifi: fix UMAC INIT_COMPLETE notification handling
iwmc3200wifi: hardware does not support IP checksum
iwmc3200wifi: set cipher_suites before registering wiphy
iwmc3200wifi: use correct debug level
iwmc3200wifi: remove setting WEP keys before setting essid support
iwmc3200wifi: make iwm_send_wifi_if_cmd return 0 on success
iwmc3200wifi: remove key caches in driver
cfg80211: remove WARN_ON in __cfg80211_sme_scan_done
cfg80211: set_default_key only for WEP
cfg80211: fix typo of IWEVASSOCRESPIE
iwmc3200wifi: use cfg80211_connect_result to send req/resp IE
iwmc3200wifi: fix cfg80211_connect_result is called in IBSS
iwmc3200wifi: fix a use-after-free bug
cfg80211: avoid setting default_key if add_key fails
MAINTAINERS | 11 +-
drivers/net/wireless/Kconfig | 6 +-
drivers/net/wireless/adm8211.c | 17 -
drivers/net/wireless/arlan-main.c | 2 +-
drivers/net/wireless/ath/ar9170/ar9170.h | 52 ++
drivers/net/wireless/ath/ar9170/main.c | 609 ++++++++++++++++++++++-
drivers/net/wireless/ath/ath5k/reg.h | 12 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 48 +-
drivers/net/wireless/ath/ath9k/calib.c | 13 +-
drivers/net/wireless/ath/ath9k/calib.h | 4 +-
drivers/net/wireless/ath/ath9k/eeprom.c | 20 +-
drivers/net/wireless/ath/ath9k/hw.c | 70 +++-
drivers/net/wireless/ath/ath9k/hw.h | 18 +-
drivers/net/wireless/ath/ath9k/initvals.h | 47 +-
drivers/net/wireless/ath/ath9k/mac.c | 30 +-
drivers/net/wireless/ath/ath9k/main.c | 35 ++-
drivers/net/wireless/ath/ath9k/rc.c | 609 ++++++++----------------
drivers/net/wireless/ath/ath9k/rc.h | 29 +-
drivers/net/wireless/ath/ath9k/recv.c | 25 +-
drivers/net/wireless/ath/ath9k/reg.h | 93 ++++
drivers/net/wireless/ath/ath9k/virtual.c | 17 +
drivers/net/wireless/ath/ath9k/xmit.c | 76 +++-
drivers/net/wireless/b43/main.c | 4 +-
drivers/net/wireless/hostap/hostap_cs.c | 3 +-
drivers/net/wireless/ipw2x00/ipw2200.c | 3 -
drivers/net/wireless/iwlwifi/iwl-1000.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-3945-hw.h | 7 +-
drivers/net/wireless/iwlwifi/iwl-3945-rs.c | 24 +-
drivers/net/wireless/iwlwifi/iwl-3945.c | 52 ++-
drivers/net/wireless/iwlwifi/iwl-3945.h | 3 -
drivers/net/wireless/iwlwifi/iwl-4965.c | 67 +++-
drivers/net/wireless/iwlwifi/iwl-5000.c | 60 +++-
drivers/net/wireless/iwlwifi/iwl-6000.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 16 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 165 ++++---
drivers/net/wireless/iwlwifi/iwl-core.c | 424 ++++++++--------
drivers/net/wireless/iwlwifi/iwl-core.h | 18 +-
drivers/net/wireless/iwlwifi/iwl-debug.h | 16 +-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 69 +++-
drivers/net/wireless/iwlwifi/iwl-dev.h | 40 ++-
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-helpers.h | 21 +
drivers/net/wireless/iwlwifi/iwl-led.c | 34 +-
drivers/net/wireless/iwlwifi/iwl-prph.h | 5 +-
drivers/net/wireless/iwlwifi/iwl-rx.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-sta.c | 19 +-
drivers/net/wireless/iwlwifi/iwl-tx.c | 6 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 89 ++--
drivers/net/wireless/iwmc3200wifi/cfg80211.c | 270 ++++++++---
drivers/net/wireless/iwmc3200wifi/commands.c | 52 +--
drivers/net/wireless/iwmc3200wifi/hal.c | 16 +-
drivers/net/wireless/iwmc3200wifi/iwm.h | 5 +
drivers/net/wireless/iwmc3200wifi/main.c | 7 +
drivers/net/wireless/iwmc3200wifi/rx.c | 96 +++--
drivers/net/wireless/iwmc3200wifi/umac.h | 6 +
drivers/net/wireless/iwmc3200wifi/wext.c | 320 ++-----------
drivers/net/wireless/libertas/assoc.c | 10 +-
drivers/net/wireless/mac80211_hwsim.c | 8 +-
drivers/net/wireless/mwl8k.c | 6 +-
drivers/net/wireless/p54/eeprom.c | 327 ++++++++++---
drivers/net/wireless/p54/fwio.c | 23 +-
drivers/net/wireless/p54/lmac.h | 7 +
drivers/net/wireless/p54/main.c | 112 +++--
drivers/net/wireless/p54/p54.h | 3 +
drivers/net/wireless/p54/txrx.c | 80 +++-
drivers/net/wireless/rt2x00/rt2400pci.c | 1 +
drivers/net/wireless/rt2x00/rt2400pci.h | 2 +-
drivers/net/wireless/rt2x00/rt2500pci.c | 1 +
drivers/net/wireless/rt2x00/rt2500pci.h | 2 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 1 +
drivers/net/wireless/rt2x00/rt2500usb.h | 2 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 9 +-
drivers/net/wireless/rt2x00/rt2800usb.h | 2 +-
drivers/net/wireless/rt2x00/rt2x00.h | 7 +-
drivers/net/wireless/rt2x00/rt2x00config.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00crypto.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00dev.c | 3 +-
drivers/net/wireless/rt2x00/rt2x00link.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00mac.c | 14 +-
drivers/net/wireless/rt2x00/rt2x00queue.h | 10 +-
drivers/net/wireless/rt2x00/rt2x00reg.h | 4 +-
drivers/net/wireless/rt2x00/rt61pci.c | 3 +-
drivers/net/wireless/rt2x00/rt61pci.h | 2 +-
drivers/net/wireless/rt2x00/rt73usb.c | 1 +
drivers/net/wireless/rt2x00/rt73usb.h | 4 +-
drivers/net/wireless/wl12xx/wl1251_acx.c | 4 +-
drivers/net/wireless/wl12xx/wl1251_main.c | 61 +---
drivers/net/wireless/wl12xx/wl1251_netlink.c | 679 --------------------------
drivers/net/wireless/wl12xx/wl1251_ops.c | 4 +-
drivers/net/wireless/wl12xx/wl1251_rx.h | 2 +-
drivers/net/wireless/zd1211rw/zd_usb.c | 1 +
include/linux/nl80211.h | 52 ++
include/linux/skbuff.h | 6 +-
include/net/cfg80211.h | 20 +-
include/net/mac80211.h | 37 ++
net/core/dev.c | 2 +
net/core/skbuff.c | 3 -
net/mac80211/Kconfig | 12 +
net/mac80211/Makefile | 3 +
net/mac80211/agg-tx.c | 3 -
net/mac80211/cfg.c | 2 +-
net/mac80211/debugfs.c | 2 +-
net/mac80211/driver-ops.h | 85 +++-
net/mac80211/driver-trace.c | 6 +
net/mac80211/driver-trace.h | 648 ++++++++++++++++++++++++
net/mac80211/ibss.c | 9 +-
net/mac80211/ieee80211_i.h | 47 +-
net/mac80211/iface.c | 51 +-
net/mac80211/main.c | 120 +-----
net/mac80211/mesh.c | 5 +-
net/mac80211/mesh_hwmp.c | 9 +-
net/mac80211/mesh_pathtbl.c | 26 +-
net/mac80211/mlme.c | 308 ++++++++++---
net/mac80211/rate.c | 31 ++-
net/mac80211/rc80211_minstrel.c | 23 +-
net/mac80211/rc80211_pid_algo.c | 12 +-
net/mac80211/rx.c | 55 ++-
net/mac80211/scan.c | 19 +-
net/mac80211/tx.c | 323 ++++++-------
net/mac80211/util.c | 68 +--
net/mac80211/wep.c | 6 +-
net/mac80211/wep.h | 3 +
net/mac80211/wme.c | 6 +-
net/mac80211/wme.h | 3 +-
net/wireless/core.c | 21 +-
net/wireless/core.h | 32 +-
net/wireless/ibss.c | 84 +++-
net/wireless/mlme.c | 24 +-
net/wireless/nl80211.c | 428 +++++++++++++---
net/wireless/reg.c | 25 +-
net/wireless/sme.c | 112 +++--
net/wireless/util.c | 45 ++-
net/wireless/wext-compat.c | 202 +++++---
net/wireless/wext-sme.c | 76 ++--
134 files changed, 4999 insertions(+), 3237 deletions(-)
delete mode 100644 drivers/net/wireless/wl12xx/wl1251_netlink.c
create mode 100644 net/mac80211/driver-trace.c
create mode 100644 net/mac80211/driver-trace.h
Omnibus patch available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2009-07-24.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* Re: [PATCH 1/1] veth: don't free priv->status until dev->destructor (v2)
From: Stephen Hemminger @ 2009-07-24 19:46 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Linux Containers, Sachin Sant, netdev, David Miller, matthltc,
lkml
In-Reply-To: <20090626162418.GA24828@us.ibm.com>
On Fri, 26 Jun 2009 11:24:18 -0500
"Serge E. Hallyn" <serue@us.ibm.com> wrote:
> Based on the commit msg on ae0e8e82205c903978a79ebf5e31c670b61fa5b4, it looks
> ether_setup(dev);
> @@ -306,7 +320,7 @@ static void veth_setup(struct net_device *dev)
> dev->netdev_ops = &veth_netdev_ops;
> dev->ethtool_ops = &veth_ethtool_ops;
> dev->features |= NETIF_F_LLTX;
> - dev->destructor = free_netdev;
> + dev->destructor = veth_dev_free;
>
This is still going to oops if sysfs statistics referenced
after module unload because module is unloaded (code is gone)
and veth_dev_free no longer exists.
I'll respin the original patch (using free_netdev) and fix
the statistics complaint.
^ permalink raw reply
* Re: [net-next 6/10] bnx2x: Update vlan_features
From: Jay Vosburgh @ 2009-07-24 19:47 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Or Gerlitz, eilong, David Miller, netdev, Eric Dumazet
In-Reply-To: <4A68479F.1000807@trash.net>
Patrick McHardy <kaber@trash.net> wrote:
>In case of bonding, its necessary to update vlan_features so it
>contains the intersection of all underlying devices. But a
>change will only take effect for existing VLANs (f.i. when
>enslaving a new device) if you call netdev_features_change().
Patrick, can you clarify one bit about your above statment? You
say the bonding features should be an "intersection"; is that a strict
intersection (i.e., slave1->vlan_features | slave2->vlan_features), or
does the NETIF_F_ONE_FOR_ALL logic apply for vlan_features as it does
for regular dev->features (using netdev_incrmenet_features() to combine
the feature sets)?
In other words, if a bond has two slaves, one with, e.g.,
NETIF_F_SG in its vlan_features, and the other slave has 0 in
vlan_features, should the bond's vlan_features be NETIF_F_SG, or 0?
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH 2/2] c/r: Add AF_INET support (v3)
From: John Dykstra @ 2009-07-24 20:44 UTC (permalink / raw)
To: Dan Smith; +Cc: containers, netdev, Oren Laaden, Alexey Dobriyan
In-Reply-To: <1246994776-1882-3-git-send-email-danms@us.ibm.com>
On Tue, 2009-07-07 at 12:26 -0700, Dan Smith wrote:
> 2. I don't do anything to redirect or freeze traffic flowing to or from the
> remote system (to prevent a RST from breaking things). I expect that
> userspace will bring down a veth device or freeze traffic to the remote
> system to handle this case.
Theoretically, you can drop any packet that's in flight (ingress or
egress), because IP doesn't guarantee delivery. TCP is able to recover,
and a UDP or raw-socket application should already be designed to. Of
course, retransmissions will have an impact on application performance
in the migration case, so that's got to be considered in the tradeoff.
Main goal should probably be avoiding anything that shoves either end
into slow-start.
Thinking out loud, have you considered draining TCP buffers rather than
including them in the checkpoint? You'd stop ingress traffic, and let
the app run until it had read everything in the socket buffer. On the
egress side, you'd cork the app by telling it that buffers were full,
and then wait until the data already at the socket layer had been
transmitted. Both are somewhat unbounded re time, and probably not
worth it, but maybe there's some variant of this idea that has value.
TCP transmit buffers on 10GE links can be pretty big...
BTW, if you see RSTs, that probably means you've created a protocol
violation due to a buggy restore. Just blocking or dropping packets
shouldn't result in an RST unless it's very long.
-- John
^ permalink raw reply
* [PATCH] r8169: WakeOnLan fix for the 8168
From: Francois Romieu @ 2009-07-24 22:34 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Jaromír Cápík, Edward Hsu
More stuff for http://bugzilla.kernel.org/show_bug.cgi?id=9512
Some 8168 are unable to WoL when receiving is not enabled (plain
old 8169 do not seem to care).
It is not exactly pretty to leave the receiver enabled but we
should now enable DMA late enough for it to be safe. Some late
stage boot failure due to pxe and friends may benefit from the
delayed enabling of bus-mastering as well.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Tested-by: Jaromír Cápík <tavvva@volny.cz>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
---
drivers/net/r8169.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 4b53b58..b82780d 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2060,8 +2060,6 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
}
}
- pci_set_master(pdev);
-
/* ioremap MMIO region */
ioaddr = ioremap(pci_resource_start(pdev, region), R8169_REGS_SIZE);
if (!ioaddr) {
@@ -2089,6 +2087,8 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
RTL_W16(IntrStatus, 0xffff);
+ pci_set_master(pdev);
+
/* Identify chip attached to board */
rtl8169_get_mac_version(tp, ioaddr);
@@ -3874,6 +3874,15 @@ static void rtl_shutdown(struct pci_dev *pdev)
spin_unlock_irq(&tp->lock);
if (system_state == SYSTEM_POWER_OFF) {
+ /* WoL fails with some 8168 when the receiver is disabled. */
+ if (tp->features & RTL_FEATURE_WOL) {
+ pci_clear_master(pdev);
+
+ RTL_W8(ChipCmd, CmdRxEnb);
+ /* PCI commit */
+ RTL_R8(ChipCmd);
+ }
+
pci_wake_from_d3(pdev, true);
pci_set_power_state(pdev, PCI_D3hot);
}
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH] USB host CDC Phonet network interface driver
From: Alan Cox @ 2009-07-24 23:19 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Oliver Neukum, Rémi Denis-Courmont, ext Dan Williams,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1248458401.28545.149.camel@violet>
> we don't want PPP at all. It is just plain stupid and a total braindead
> idea. Non of the GSM/UMTS networks talk PPP over the air interface or
> actually anywhere in their stack. The PPP is just between the host OS
> and the card. It is a pointless encapsulation of IP packets that comes
> from the POTS stuff where PPP over a telephone line made sense.
Well yes. A 3G USB modem is a lovely example of compatibility gone mad
It runs
an emulated PPP session
over an emulated serial port
over a serial port multiplex emulating multiple serial ports
over an emulated serial port
over a USB link which has perfectly good packet facilities
into the Linux kernel
which makes it look like a legacy modem device
which is managed by a set of software tools written for 9600 baud
modems
Unfortunately fixing that has to start at the vendor firmware end, and
that is a lot of interfaces for SMS, voice dialing, fax and god knows
what else as well as data.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next-2.6 PATCH 06/13] igb: move all multicast addresses into multicast table array
From: Peter P Waskiewicz Jr @ 2009-07-25 1:41 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Duyck, Alexander H, David S. Miller, netdev, Kirsher, Jeffrey T,
gospo@redhat.com
In-Reply-To: <Pine.LNX.4.64.0907241053200.24126@tyr.diku.dk>
On Fri, 2009-07-24 at 01:57 -0700, Jesper Dangaard Brouer wrote:
> On Thu, 23 Jul 2009, Jeff Kirsher wrote:
>
> > From: Alexander Duyck <alexander.h.duyck@intel.com>
> >
> > This patch moves all of the multicast addresses out of the free Receive
> > address registers and instead programs them all into the multicast table
> > array. As a result the multicast filtering may not be as precise, but it
> > also greatly reduces the overhead for multicast addresses.
>
> What do you mean by "the multicast filtering may not be as precise" ?
>
> I'm planning to use these NICs for multicast traffic (both routing and
> monitoring). Is there any precausing I need to be aware of?
>
The receive address registers, or RARs, are perfect match filters. The
multicast table array, or MTA, contains hashed values of the multicast
addresses. Therefore, it isn't a perfect match for the multicast
addresses anymore. But to support a larger number of multicast
addresses, they can't be written to the RARs, since those resources are
small and are needed for MAC and unicast address filtering.
Cheers,
-PJ Waskiewicz
^ permalink raw reply
* Re: [RFC] [PATCH] Don't run __qdisc_run() on a stopped TX queue
From: Herbert Xu @ 2009-07-25 3:24 UTC (permalink / raw)
To: Krishna Kumar2; +Cc: davem, Jarek Poplawski, netdev
In-Reply-To: <OFFA0E0F2C.B17AF73A-ON652575FD.00372349-652575FD.0039CB03@in.ibm.com>
On Fri, Jul 24, 2009 at 04:01:15PM +0530, Krishna Kumar2 wrote:
>
> Assuming many CPU's share a queue, only one can xmit due to the
> RUNNING bit. And after RUNNING bit is taken, no other cpu can
> stop the queue. So the only change in the behavior with this
> patch is that the xmit is terminated a little earlier compared
> to the current code. In case of a stopped queue, the patch helps
> a little bit more by removing one stopped check for each queue'd
> skb, including those skbs that are added later while the current
> xmit session (qdisc_run) is ongoing.
>
> I hope I have addressed your concern?
That got me to actually look at your patch :)
You're essentiall reverting f4ab543201992fe499bef5c406e09f23aa97b4d5
which cannot be right since the same problem still exists.
However, I am definitely with you in that we should perform this
optimisation since it makes sense for the majority of people who
use multiqueue TX.
So the fact that our current architecture penalises the people
who actually need multiqueue TX in order to ensure correctness
for the people who cannot use multiqueue TX effectively (i.e.,
those who use non-default qdiscs) makes me uneasy.
Dave, remember our discussion about the benefits of using multiqueue
TX just for the sake of enarlging the TX queues? How about just
going back to using a single queue for non-default qdiscs (at
least until such a time when non-default qdiscs start doing
multiple queues internally)?
Yes it would mean potentially smaller queues for those non-default
qdisc users, but they're usually the same people who want the
hardware to queue as little as possible in order to enforce whatever
it is that their qdisc is designed to enforce.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Jumbo frame question...
From: Herbert Xu @ 2009-07-25 3:28 UTC (permalink / raw)
To: Robin Getz; +Cc: netdev
In-Reply-To: <200907241141.55097.rgetz@blackfin.uclinux.org>
Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> Should a gigabit card, configured as 100, be sending jumbo UDP frames?
>
> My understanding, is no - this is a spec violation..
>
>
> Settings for eth0:
> Supported ports: [ MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Supports auto-negotiation: Yes
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Advertised auto-negotiation: Yes
> Speed: 100Mb/s
> Duplex: Half
> Port: Twisted Pair
> PHYAD: 1
> Transceiver: internal
> Auto-negotiation: on
> Supports Wake-on: g
> Wake-on: d
> Current message level: 0x000000ff (255)
> Link detected: no
>
> happly sends UDP packets over 1500 bytes in length.
>
> Tested with TFTP, and 2.6.27 (as the tftp server).
What's the kernel that you're running on the machine doing the
sending, 2.6.27? If it's the latest kernel then it may be related
to the UFO work that went in recently.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Bugme-new] [Bug 13760] New: 2.6.30 kernel locks up with pppoe in back trace (regression)
From: Herbert Xu @ 2009-07-25 3:33 UTC (permalink / raw)
To: Jarek Poplawski
Cc: davem, akpm, for.poige+bugzilla.kernel.org, bugzilla-daemon,
bugme-daemon, netdev
In-Reply-To: <4A68B5DA.5000307@gmail.com>
Jarek Poplawski <jarkao2@gmail.com> wrote:
>
> Here is a link showing around pppoe problem quite similar to
> the one fixed later in pty.c by Alan Cox, so IMHO the current
> 2.6.31-rc is worth trying.
Well it depends on whether he's using the kernel pppoe stack or
doing pppoe in user-space. If the latter then yes those fixes
may help. Otherwise we really need to see the backtraces.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] man page update (ip.7) to reflect new socket option in 2.6.31
From: Michael Kerrisk @ 2009-07-25 4:43 UTC (permalink / raw)
To: Nivedita Singhvi; +Cc: netdev, linux-man-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4A3B3C92.9050003-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Hello Nivedita
On Fri, Jun 19, 2009 at 9:21 AM, Nivedita Singhvi<niv-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> Nivedita Singhvi wrote:
>>
>> This patch adds the IP_MULTICAST_ALL option to
>> the ip.7 man page, to bring it up to date with
>> 2.6.31 development.
>
> Ah, the "since" is intended to be inclusive.
Yep ;-).
> The
> 2.6.30 needs to be 2.6.31. Correct version below.
> Apologies!
No worries. Glad you caught it. Some belated comments below.
> Signed-off-by: Nivedita Singhvi <niv-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>
> ---
> man7/ip.7 | 10 +++++++++-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/man7/ip.7 b/man7/ip.7
> index ab866a1..6932ba2 100644
> --- a/man7/ip.7
> +++ b/man7/ip.7
> @@ -357,7 +357,6 @@ and retrieve the MTU by calling
> with the
> .B IP_MTU
> option.
> -
> It is possible to implement RFC 4821 MTU probing with
> .B SOCK_DGRAM
> or
> @@ -383,6 +382,15 @@ When an invalid socket option is passed,
> .B ENOPROTOOPT
> is returned.
> .TP
> +.BR IP_MULTICAST_ALL " (since Linux 2.6.31)"
> +Sets the multicast delivery policy to the socket. Argument is a boolean
Is the following better here:
Sets the policy for multicast delivery to the socket
?
> +integer that enables or disables multicast delivery from all groups.
> +If not set, delivery to the socket is restricted to data from those
> multicast
> +groups that have been explicitly subscribed to via a multicast join
> operation
> +for this socket. The default is 1 which means that a socket which is bound
> +to the wildcard address (INADDR_ANY) will receive multicast packets from
> all
> +groups that have been subscribed to on this system.
> +.TP
> .BR IP_MULTICAST_LOOP " (since Linux 1.2)"
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Watch my Linux system programming book progress to publication!
http://blog.man7.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Bugme-new] [Bug 13760] New: 2.6.30 kernel locks up with pppoe in back trace (regression)
From: Igor M Podlesny @ 2009-07-25 4:41 UTC (permalink / raw)
To: Herbert Xu
Cc: Jarek Poplawski, davem, akpm, bugzilla-daemon, bugme-daemon,
netdev
In-Reply-To: <20090725033328.GA30919@gondor.apana.org.au>
2009/7/25 Herbert Xu <herbert@gondor.apana.org.au>:
[...]
> Well it depends on whether he's using the kernel pppoe stack or
> doing pppoe in user-space. If the latter then yes those fixes
In my Bugzilla's bug-report I mentioned pppoe's related functions in
oops-backtraces; how do you think could that really be caused by
user-space pppoe "doing"? I don't think so. I guess you missed that
point.
> may help. Otherwise we really need to see the backtraces.
>
It was always clear that backtraces were welcome but I hadn't a
chance to save it yet.
--
End of message. Next message?
^ permalink raw reply
* Re: [PATCH] fealnx: Write outside array bounds
From: Ilpo Järvinen @ 2009-07-25 9:55 UTC (permalink / raw)
To: Roel Kluin; +Cc: David S. Miller, netdev, Andrew Morton
In-Reply-To: <4A699FC2.2080407@gmail.com>
On Fri, 24 Jul 2009, Roel Kluin wrote:
> phy_idx is checked to be < 4, but np->phys[] is 2 elements long
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> Or should the number of elements be increased?
>
> diff --git a/drivers/net/fealnx.c b/drivers/net/fealnx.c
> index 48385c4..100badd 100644
> --- a/drivers/net/fealnx.c
> +++ b/drivers/net/fealnx.c
> @@ -584,7 +584,7 @@ static int __devinit fealnx_init_one(struct pci_dev *pdev,
> if (np->flags == HAS_MII_XCVR) {
> int phy, phy_idx = 0;
>
> - for (phy = 1; phy < 32 && phy_idx < 4; phy++) {
> + for (phy = 1; phy < 32 && phy_idx < 2; phy++) {
> int mii_status = mdio_read(dev, phy, 1);
>
> if (mii_status != 0xffff && mii_status != 0x0000) {
In either of the case, one should use ARRAY_SIZE(np->phys) instead of the
number.
--
i.
^ permalink raw reply
* tty_register_device NULL pointer dereference in 2.6.31-rc4
From: Oliver Hartkopp @ 2009-07-25 10:01 UTC (permalink / raw)
To: Alan Cox, Marcel Holtmann; +Cc: Linux Netdev List, linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 468 bytes --]
Hello Alan and Marcel,
this morning i got a NULL pointer dereference in tty_register_device() that
looked similar to the one, i posted here on 03-jun-2009:
http://marc.info/?l=linux-bluetooth&m=124404919324542&w=2
As the boot sequence stopped after this point, i was only able to take a
picture of it - see attached jpg.
I was able to shut down the system gracefully by pressing the power button.
The problem emerges really seldom.
Any idea?
Regards,
Oliver
[-- Attachment #2: tty_register_device_2-6-31-rc4.jpg --]
[-- Type: image/jpeg, Size: 134502 bytes --]
^ permalink raw reply
* Re: tty_register_device NULL pointer dereference in 2.6.31-rc4
From: Alan Cox @ 2009-07-25 10:50 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: Marcel Holtmann, Linux Netdev List, linux-bluetooth
In-Reply-To: <4A6AD807.6060706@hartkopp.net>
On Sat, 25 Jul 2009 12:01:43 +0200
Oliver Hartkopp <oliver@hartkopp.net> wrote:
> Hello Alan and Marcel,
>
> this morning i got a NULL pointer dereference in tty_register_device() that
> looked similar to the one, i posted here on 03-jun-2009:
>
> http://marc.info/?l=linux-bluetooth&m=124404919324542&w=2
>
> As the boot sequence stopped after this point, i was only able to take a
> picture of it - see attached jpg.
>
> I was able to shut down the system gracefully by pressing the power button.
>
> The problem emerges really seldom.
>
> Any idea?
tty_register_device appears to have been called with a NULL pointer. Not
sure why however.
^ permalink raw reply
* Re: [Bugme-new] [Bug 13803] New: hso: Tx timed out.
From: Fathi Boudra @ 2009-07-25 10:56 UTC (permalink / raw)
To: Jan Dumon
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r,
bugme-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r, Andrew Morton
In-Reply-To: <20090723154337.709ca0cd.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
I noticed the bug is triggered when the GTM382 module is connected on
my PC/104+ board through the PCI Express MiniCard.
Using Option deviceKit plugged on the CPU board through USB 1.1
connector, the bug isn't triggered.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] [PATCH] Don't run __qdisc_run() on a stopped TX queue
From: Jarek Poplawski @ 2009-07-25 11:04 UTC (permalink / raw)
To: Herbert Xu; +Cc: Krishna Kumar2, davem, netdev
In-Reply-To: <20090725032436.GA30741@gondor.apana.org.au>
On Sat, Jul 25, 2009 at 11:24:36AM +0800, Herbert Xu wrote:
...
> However, I am definitely with you in that we should perform this
> optimisation since it makes sense for the majority of people who
> use multiqueue TX.
>
> So the fact that our current architecture penalises the people
> who actually need multiqueue TX in order to ensure correctness
> for the people who cannot use multiqueue TX effectively (i.e.,
> those who use non-default qdiscs) makes me uneasy.
It would be nice to establish what difference is made by each part of
this patch. The check for stopped queue before each skb xmit was done
earlier too, so it's not exactly multiqueue penalization.
Cheers,
Jarek P.
^ permalink raw reply
* Re: tty_register_device NULL pointer dereference in 2.6.31-rc4
From: Marcel Holtmann @ 2009-07-25 11:07 UTC (permalink / raw)
To: Alan Cox; +Cc: Oliver Hartkopp, Linux Netdev List, linux-bluetooth
In-Reply-To: <20090725115011.7ddf8d00@lxorguk.ukuu.org.uk>
Hi Alan,
> > this morning i got a NULL pointer dereference in tty_register_device() that
> > looked similar to the one, i posted here on 03-jun-2009:
> >
> > http://marc.info/?l=linux-bluetooth&m=124404919324542&w=2
> >
> > As the boot sequence stopped after this point, i was only able to take a
> > picture of it - see attached jpg.
> >
> > I was able to shut down the system gracefully by pressing the power button.
> >
> > The problem emerges really seldom.
> >
> > Any idea?
>
> tty_register_device appears to have been called with a NULL pointer. Not
> sure why however.
if that is the pointer for the struct device, then that used to be fine
in the past. Not all RFCOMM device have a parent when they are created.
Regards
Marcel
^ permalink raw reply
* Re: [RFC] [PATCH] Don't run __qdisc_run() on a stopped TX queue
From: Herbert Xu @ 2009-07-25 11:12 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Krishna Kumar2, davem, netdev
In-Reply-To: <20090725110409.GA3086@ami.dom.local>
On Sat, Jul 25, 2009 at 01:04:09PM +0200, Jarek Poplawski wrote:
>
> It would be nice to establish what difference is made by each part of
> this patch. The check for stopped queue before each skb xmit was done
> earlier too, so it's not exactly multiqueue penalization.
No, but getting into qdisc_restart when we know that the queue is
stopped is just silly. The only reason that is done right now is
because of the pathological case where a packet on qdisc X maps to
hardware queue Y. This is something which almost nobody uses and
yet it penalises everybody.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC] [PATCH] Don't run __qdisc_run() on a stopped TX queue
From: Jarek Poplawski @ 2009-07-25 11:53 UTC (permalink / raw)
To: Herbert Xu; +Cc: Krishna Kumar2, davem, netdev
In-Reply-To: <20090725111207.GA518@gondor.apana.org.au>
On Sat, Jul 25, 2009 at 07:12:07PM +0800, Herbert Xu wrote:
> On Sat, Jul 25, 2009 at 01:04:09PM +0200, Jarek Poplawski wrote:
> >
> > It would be nice to establish what difference is made by each part of
> > this patch. The check for stopped queue before each skb xmit was done
> > earlier too, so it's not exactly multiqueue penalization.
>
> No, but getting into qdisc_restart when we know that the queue is
> stopped is just silly. The only reason that is done right now is
> because of the pathological case where a packet on qdisc X maps to
> hardware queue Y. This is something which almost nobody uses and
> yet it penalises everybody.
Hmm... I agree with you 100%! (I'd only like to see more digits... ;-)
Cheers,
Jarek P.
^ permalink raw reply
* Re: tty_register_device NULL pointer dereference in 2.6.31-rc4
From: Alan Cox @ 2009-07-25 12:10 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Oliver Hartkopp, Linux Netdev List,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1248520053.28545.156.camel@violet>
> > tty_register_device appears to have been called with a NULL pointer. Not
> > sure why however.
>
> if that is the pointer for the struct device, then that used to be fine
> in the past. Not all RFCOMM device have a parent when they are created.
The tty layer doesn't care about the struct device really. Nothing there
has changed. The NULL passed appears to be the driver argument.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox