* pull request: wireless-next-2.6 2010-05-17
From: John W. Linville @ 2010-05-17 18:26 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Dave,
One last big batch intended for 2.6.35 -- these have all been in
linux-next for several days. Included are the usual driver updates for
iwlwifi, ath9k, and rt2x00 along with a smattering of other bits
(including some trivial fixups).
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 278554bd6579206921f5d8a523649a7a57f8850d:
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 for-davem
Abhijeet Kolekar (3):
iwl3945: fix scan races
iwl3945: add plcp error checking
mac80211: fix paged defragmentation
Dan Carpenter (3):
wl1271: add missing spin_lock()
wl1271: fix notifier interface supported test
wl1271: remove some unneeded code
Felix Fietkau (4):
ath9k: use debugfs_remove_recursive() instead of keeping pointers to all entries
ath9k: add debugfs files for reading/writing the rx and tx chainmask
ath9k: add debugfs files for reading/writing registers
ath9k_hw: clean up EEPROM endian handling on AR9003
Gertjan van Wingerde (6):
rt2x00: Consistently name skb frame descriptor skbdesc.
rt2x00: Fix beacon descriptor writing for rt61pci.
rt2x00: Re-order tx descriptor writing code in drivers.
rt2x00: Simplify TXD handling of beacons.
rt2x00: Dump beacons under a different identifier than TX frames.
rt2x00: In debugfs frame dumping allow the TX descriptor to be part of the skb.
Johannes Berg (34):
iwlagn: wait for asynchronous firmware loading
iwlwifi: use vif iwl_bss_info_changed
iwl3945: use iwl3945_add_bcast_station
iwlwifi: pass address to iwl_remove_station
iwlwifi: manage IBSS station properly
iwlagn: show and store firmware build number
iwl3945: remove ucode access indirection
iwlwifi: remove ucode virtual functions
iwlwifi: move eeprom version printout to eeprom init
iwlagn: prepare for new firmware file format
iwlagn: implement loading a new firmware file type
iwlwifi: remove rts_threshold
iwlagn: move iwl_get_ra_sta_id to 4965
iwlagn: use vif->type to check station
iwlwifi: apply filter flags directly
iwlwifi: push virtual interface through
iwlagn: use virtual interface in TX aggregation handling
iwlwifi: remove useless priv->vif check
iwlwifi: use vif in iwl_ht_conf
iwlwifi: note that priv->bssid is used only by 3945
iwlwifi: fix iwl_sta_init_lq station ID
iwlwifi: split allocation/sending local station LQ
iwlwifi: rework broadcast station management
iwlwifi: track station IDs
iwlwifi: add iwl_sta_id()
iwlwifi: use iwl_find_station less
iwlagn: use iwl_sta_id() for aggregation
iwlwifi: use iwl_sta_id() for TKIP key update
iwlwifi: move iwl_find_station() to 4965
iwlwifi: rename iwl_add_local_station
iwlwifi: remove pointless HT check
iwlwifi: clear driver stations when going down
mac80211: don't process work item with wrong frame
mac80211: add offload channel switch support
John W. Linville (2):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next-2.6 into for-davem
Julia Lawall (1):
drivers/net/wireless/hostap: Drop memory allocation cast
Luis R. Rodriguez (2):
ath5k: drop warning on jumbo frames
ath9k_hw: new initialization values for AR9003
Reinette Chatre (3):
Merge branch 'wireless-2.6' into wireless-next-2.6
iwlwifi: make bcast LQ command available for later restore actions
iwlagn: work around rate scaling reset delay
Shanyu Zhao (2):
iwlwifi: rename 6000 series Gen2 devices to Gen2a
iwlwifi: dump firmware build info in error case
Steve Tanner (1):
ar9170usb: add vendor and device ID for Qwest/Actiontec 802AIN Wireless N USB Network Adapter
Sujith.Manoharan-DlyHzToyqoxBDgjK7y7TUQ@public.gmane.org (5):
ath9k_htc: Lock sta_notify() callback
ath9k_htc: Allocate URBs properly
ath9k_htc: Reorder HTC initialization
ath9k_htc: Fix target ready race condition
ath9k_htc: Fix array overflow
Vasanthakumar Thiagarajan (2):
ath9k: Fix bug in handling rx frames with invalid descriptor content
ath9k: Remove unused rx_edma in ath_rx_addbuffer_edma()
Wey-Yi Guy (11):
iwlwifi: remove powersave debugfs if it is not supported
iwlwifi: rename "tx_power" to "chain_tx_power"
iwlwifi: remove device type checking for tx power in debugfs
iwlwifi: use .cfg to enable/disable continuous ucode trace
iwlwifi: use cfg to configure calibration operation
iwlwifi: give correct return information for tx power debugfs
iwlwifi: wimax co-exist code clean up
iwlwifi: checking for all the possible failure cases
iwlwifi: "tx power per chain" are part of ucode_tx_stats
iwlwifi: provide more comments for cfg structure
mac80211: check channel switch mode for future frames transmit
drivers/net/wireless/ath/ar9170/usb.c | 2 +
drivers/net/wireless/ath/ath5k/base.c | 12 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 174 +++----
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 10 +-
drivers/net/wireless/ath/ath9k/ar9003_initvals.h | 268 ++++++------
drivers/net/wireless/ath/ath9k/debug.c | 236 ++++++++--
drivers/net/wireless/ath/ath9k/debug.h | 8 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 58 ++--
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 7 +
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4 +
drivers/net/wireless/ath/ath9k/htc_hst.c | 51 +-
drivers/net/wireless/ath/ath9k/htc_hst.h | 15 +-
drivers/net/wireless/ath/ath9k/recv.c | 3 +-
drivers/net/wireless/hostap/hostap_80211_rx.c | 3 +-
drivers/net/wireless/hostap/hostap_ioctl.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-3945.c | 147 ++++--
drivers/net/wireless/iwlwifi/iwl-3945.h | 22 +-
drivers/net/wireless/iwlwifi/iwl-4965.c | 100 +++--
drivers/net/wireless/iwlwifi/iwl-5000.c | 27 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 51 ++-
drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c | 16 +
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 31 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 29 +-
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 109 +++--
drivers/net/wireless/iwlwifi/iwl-agn.c | 556 +++++++++++++++-------
drivers/net/wireless/iwlwifi/iwl-agn.h | 14 +-
drivers/net/wireless/iwlwifi/iwl-commands.h | 6 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 199 +++-----
drivers/net/wireless/iwlwifi/iwl-core.h | 60 ++-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 66 +--
drivers/net/wireless/iwlwifi/iwl-dev.h | 89 +++-
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 7 +
drivers/net/wireless/iwlwifi/iwl-power.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-rx.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-scan.c | 16 +-
drivers/net/wireless/iwlwifi/iwl-sta.c | 456 ++++++++----------
drivers/net/wireless/iwlwifi/iwl-sta.h | 60 ++-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 163 ++++---
drivers/net/wireless/rt2x00/rt2400pci.c | 26 +-
drivers/net/wireless/rt2x00/rt2500pci.c | 26 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 55 ++-
drivers/net/wireless/rt2x00/rt2800pci.c | 14 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 8 +-
drivers/net/wireless/rt2x00/rt2x00debug.c | 21 +-
drivers/net/wireless/rt2x00/rt2x00dump.h | 3 +
drivers/net/wireless/rt2x00/rt2x00pci.c | 9 -
drivers/net/wireless/rt2x00/rt2x00queue.c | 15 +-
drivers/net/wireless/rt2x00/rt2x00queue.h | 3 +
drivers/net/wireless/rt2x00/rt2x00usb.c | 8 -
drivers/net/wireless/rt2x00/rt61pci.c | 35 +-
drivers/net/wireless/rt2x00/rt73usb.c | 71 ++--
drivers/net/wireless/wl12xx/wl1271_main.c | 5 +-
include/net/mac80211.h | 39 ++
net/mac80211/driver-ops.h | 11 +
net/mac80211/driver-trace.h | 49 ++
net/mac80211/ieee80211_i.h | 3 +-
net/mac80211/mlme.c | 59 +++-
net/mac80211/rx.c | 6 +
net/mac80211/work.c | 27 +-
60 files changed, 2152 insertions(+), 1442 deletions(-)
Omnibus patch available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2010-05-17.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: [PATCH net-next-2.6 2/2] bonding: allow user-controlled output slave selection
From: Neil Horman @ 2010-05-17 18:45 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: Jay Vosburgh, netdev
In-Reply-To: <20100513171504.GD21535@shamino.rdu.redhat.com>
On Thu, May 13, 2010 at 01:15:04PM -0400, Neil Horman wrote:
> On Wed, May 12, 2010 at 06:14:08PM -0400, Andy Gospodarek wrote:
> > On Wed, May 12, 2010 at 12:41:54PM -0700, Jay Vosburgh wrote:
> > > Neil Horman <nhorman@tuxdriver.com> wrote:
> > >
> > > >On Tue, May 11, 2010 at 01:09:39PM -0700, Jay Vosburgh wrote:
> > > >> Andy Gospodarek <andy@greyhouse.net> wrote:
> > > >>
> > > >> >This patch give the user the ability to control the output slave for
> > > >> >round-robin and active-backup bonding. Similar functionality was
> > > >> >discussed in the past, but Jay Vosburgh indicated he would rather see a
> > > >> >feature like this added to existing modes rather than creating a
> > > >> >completely new mode. Jay's thoughts as well as Neil's input surrounding
> > > >> >some of the issues with the first implementation pushed us toward a
> > > >> >design that relied on the queue_mapping rather than skb marks.
> > > >> >Round-robin and active-backup modes were chosen as the first users of
> > > >> >this slave selection as they seemed like the most logical choices when
> > > >> >considering a multi-switch environment.
> > > >> >
> > > >> >Round-robin mode works without any modification, but active-backup does
> > > >> >require inclusion of the first patch in this series and setting
> > > >> >the 'keep_all' flag. This will allow reception of unicast traffic on
> > > >> >any of the backup interfaces.
> > > >>
> > > >> Yes, I did think that the mark business fit better into existing
> > > >> modes (I thought of it as kind of a new hash for xor and 802.3ad modes).
> > > >> I also didn't expect to see so much new stuff (this, as well as the FCOE
> > > >> special cases being discussed elsewhere) being shoehorned into the
> > > >> active-backup mode. I'm not so sure that adding so many special cases
> > > >> to active-backup is a good thing.
> > > >>
> > > >> Now, I'm starting to wonder if you were right, and it would be
> > > >> better overall to have a "manual" mode that would hopefully satisfy this
> > > >> case as well as the FCOE special case. I don't think either of these is
> > > >> a bad use case, I'm just not sure the right way to handle them is
> > > >> another special knob in active-backup mode (either directly, or
> > > >> implicitly in __netif_receive_skb), which wasn't what I expected to see.
> > > >>
> > > >I honestly don't think a separate mode is warranted here. While I'm not opposed
> > > >to adding a new mode, I really think doing so is no different from overloading
> > > >an existing mode. I say that because to add a new mode in which we explicitly
> > > >expect traffic to be directed to various slaves requires that we implement a
> > > >policy for frames which have no queue mapping determined on egress. Any policy
> > > >I can think of is really an approximation of an existing policy, so we may as
> > > >well reuse the policy code that we already have in place. About the only way a
> > > >separate mode makes sense is in the 'passthrough' queue mode you document below.
> > > >In this model, in which queue ids map to slaves in a 1:1 fashion it doesn't make
> > > >senes.
> > >
> > > One goal I'm hoping to achieve is something that would satisfy
> > > both the queue map stuff that you're looking for, and would meet the
> > > needs of the FCOE people who also want to disable the duplicate
> > > suppression (i.e., permit incoming traffic on the inactive slave) for a
> > > different special case.
> > >
> > > The FCOE proposal revolves around, essentially, active-backup
> > > mode, but permitting incoming traffic on the inactive slave. At the
> > > moment, the patches attempt to special case things such that only
> > > dev_add_pack listeners directly bound to the inactive slave are checked
> > > (to permit the FCOE traffic to pass on the inactive slave, but still
> > > dropping IP, as ip_rcv is a wildcard bind).
> > >
> > > Your keep_all patch is, by and large, the same thing, except
> > > that it permits anything to come in on the "inactive" slave, and it's a
> > > switch that has to be turned on.
> > >
> > > This seems like needless duplication to me; I'd prefer to see a
> > > single solution that handles both cases instead of two special cases
> > > that each do 90% of what the other does.
> > >
> > > As far as a new mode goes, one major reason I think a separate
> > > mode is warranted is the semantics: with either of these changes (to
> > > permit more or less regular use of the "inactive" slaves), the mode
> > > isn't really an "active-backup" mode any longer; there is no "inactive"
> > > or "backup" slave. I think of this as being a major change of
> > > functionality, not simply a minor option.
> > >
> > > Hence my thought that "active-backup" could stay as a "true" hot
> > > standby mode (backup slaves are just that: for backup, only), and this
> > > new mode would be the place to do the special queue-map / FCOE /
> > > whatever that isn't really a hot standby configuration any longer.
> > >
> > > As far as the behavior of the new mode (your concern about its
> > > policy map approximations), in the end, it would probably act pretty
> > > much like active-backup with your patch applied: traffic goes out the
> > > active slave, unless directed otherwise. It's a lot less complicated
> > > than I had feared.
> > >
> >
> > It's beginning to sound like the 'FCoE use-case' and the one Neil and I
> > are proposing are quite similar. The main goal of both is to have the
> > option to have multiple slaves send and receive traffic during the
> > steady-state, but in the event of a failover all traffic would run on a
> > single interface.
> >
> > The implementation proposed with this patch is a bit different that the
> > 'mark-mode' patch you may recall I posted a few months ago. It created
> > a new mode that essentially did exactly what you are describing --
> > transmit on the primary interface unless pushed to another interface via
> > info in the skb and receive on all interfaces. We initially did not
> > create a new mode based on your reservations about the previous
> > mark-mode patch and went the direction of enhancing one or two modes
> > initially (figuring it would be good to run before walking), with the
> > idea that other modes could take care of this output slave selection
> > logic in the future.
>
>
> So, its sounding to me like everyone is leaning toward a new mode approach here.
> Before we go ahead and start coding, I hear the bullet points for this approach
> as:
>
> 1) Implement a new bond mode where queue ids are used to steer frames to output
> interfaces
>
> 2) Use said mode to imply universal frame reception (i.e. remove the keep_all
> knob, and turn on that behavior when this new mode is selected)
>
> 3) use John F.'s skb_should_drop changes to implement the keep_all feature.
>
> Does that sound about right?
>
> Regards
> Neil
>
Ping, Jay, any feedback on these bullet points. I'd like to keep working on
this while we have the time, but I'd rather not play guess & check on the list
here any more than we need to.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* iproute2 issue with adding rules.
From: Ben Greear @ 2010-05-17 19:03 UTC (permalink / raw)
To: NetDev
On older releases, you can do this with iproute:
# ip ru add from 9.9.9.2/32 table 226 pref 400
#
But, in latest git, it returns an error:
# ip ru add from 9.9.9.2/32 table 226 pref 400
Error: an inet prefix is expected rather than "9.9.9.2/32".
Is that on purpose?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Kernel crash with sky2
From: Stephen Hemminger @ 2010-05-17 19:22 UTC (permalink / raw)
To: Joerg Roedel; +Cc: netdev
In-Reply-To: <20100517185228.GG9007@amd.com>
On Mon, 17 May 2010 20:52:28 +0200
Joerg Roedel <joerg.roedel@amd.com> wrote:
> Hi Stephen,
>
> I experience the following crash with 2.6.34 in the sky2 code on my
> laptop when I plug off the lan-cable and then plug-off the power cable
> and switching to battery. It does not happen with acpi=off.
So you have a busted BIOS that powers off the device.
> I havn't tested earlier kernels but I can do that if necessary. I did
> some initial research and found that the driver assumes that port[1] is
> available when the status bits for it are set on the device. Please let
> me know if you need any additional information or want me to test
> anything.
The driver assumes that it won't get garbage in NAPI.
> The crash message is:
>
> [ 107.010134] sky2 0000:02:00.0: PCI hardware error (0xffff)
> [ 107.015614] sky2 0000:02:00.0: PCI Express error (0xffffffff)
> [ 107.021355] sky2 0000:02:00.0: eth0: ram data read parity error
> [ 107.027249] sky2 0000:02:00.0: eth0: ram data write parity error
> [ 107.033253] sky2 0000:02:00.0: eth0: MAC parity error
> [ 107.038283] sky2 0000:02:00.0: eth0: RX parity error
> [ 107.043259] sky2 0000:02:00.0: eth0: TCP segmentation error
> [ 107.048823] BUG: unable to handle kernel NULL pointer dereference at 0000000000000438
> [ 107.053238] IP: [<ffffffffa0001713>] sky2_hw_error+0x153/0x310 [sky2]
> [ 107.053238] PGD 139600067 PUD 139643067 PMD 0
> [ 107.053238] Oops: 0000 [#1] SMP
> [ 107.053238] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
> [ 107.053238] CPU 1
> [ 107.053238] Modules linked in: snd_hda_codec_atihdmi snd_hda_codec_idt snd_hda_intel rfcomm snd_pcm_oss snd_hda_2
> [ 107.053238]
Something in power management has turned off your device.
The fact that the sky2 driver has decided to die is unintended casulty.
This will stop the crash, but not fix the problem with PM.
As soon as it sees the device off, it will go offline until you reboot.
--- a/drivers/net/sky2.c 2010-05-17 12:09:22.721738360 -0700
+++ b/drivers/net/sky2.c 2010-05-17 12:19:52.845893670 -0700
@@ -2904,6 +2904,16 @@ static int sky2_poll(struct napi_struct
int work_done = 0;
u16 idx;
+ if (unlikely(status == ~0)) {
+ int i;
+ dev_err(&hw->pdev->dev,
+ "device no longer available (powered off?)\n");
+
+ for (i = 0; i < hw->ports; i++)
+ netif_device_detach(hw->dev[i]);
+ goto complete;
+ }
+
if (unlikely(status & Y2_IS_ERROR))
sky2_err_intr(hw, status);
@@ -2922,7 +2932,7 @@ static int sky2_poll(struct napi_struct
if (work_done >= work_limit)
goto done;
}
-
+complete:
napi_complete(napi);
sky2_read32(hw, B0_Y2_SP_LISR);
done:
--
^ permalink raw reply
* Kernel crash with sky2
From: Joerg Roedel @ 2010-05-17 18:52 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Hi Stephen,
I experience the following crash with 2.6.34 in the sky2 code on my
laptop when I plug off the lan-cable and then plug-off the power cable
and switching to battery. It does not happen with acpi=off.
I havn't tested earlier kernels but I can do that if necessary. I did
some initial research and found that the driver assumes that port[1] is
available when the status bits for it are set on the device. Please let
me know if you need any additional information or want me to test
anything.
The crash message is:
[ 107.010134] sky2 0000:02:00.0: PCI hardware error (0xffff)
[ 107.015614] sky2 0000:02:00.0: PCI Express error (0xffffffff)
[ 107.021355] sky2 0000:02:00.0: eth0: ram data read parity error
[ 107.027249] sky2 0000:02:00.0: eth0: ram data write parity error
[ 107.033253] sky2 0000:02:00.0: eth0: MAC parity error
[ 107.038283] sky2 0000:02:00.0: eth0: RX parity error
[ 107.043259] sky2 0000:02:00.0: eth0: TCP segmentation error
[ 107.048823] BUG: unable to handle kernel NULL pointer dereference at 0000000000000438
[ 107.053238] IP: [<ffffffffa0001713>] sky2_hw_error+0x153/0x310 [sky2]
[ 107.053238] PGD 139600067 PUD 139643067 PMD 0
[ 107.053238] Oops: 0000 [#1] SMP
[ 107.053238] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
[ 107.053238] CPU 1
[ 107.053238] Modules linked in: snd_hda_codec_atihdmi snd_hda_codec_idt snd_hda_intel rfcomm snd_pcm_oss snd_hda_2
[ 107.053238]
[ 107.053238] Pid: 7, comm: ksoftirqd/1 Not tainted 2.6.34-default #1 307E/HP ProBook 6545b
[ 107.053238] RIP: 0010:[<ffffffffa0001713>] [<ffffffffa0001713>] sky2_hw_error+0x153/0x310 [sky2]
[ 107.053238] RSP: 0018:ffff880001e83d78 EFLAGS: 00010202
[ 107.053238] RAX: 0000000000000001 RBX: 0000000000ffffff RCX: 00000000000001f4
[ 107.053238] RDX: 000000000000000a RSI: 0000000000000202 RDI: ffffffff81a5dc80
[ 107.053238] RBP: ffff880001e83db8 R08: 00000000ffffffff R09: 0000000000000000
[ 107.053238] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88012862da00
[ 107.053238] R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000
[ 107.053238] FS: 00007ff07987b800(0000) GS:ffff880001e80000(0000) knlGS:0000000000000000
[ 107.053238] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 107.053238] CR2: 0000000000000438 CR3: 0000000139641000 CR4: 00000000000006e0
[ 107.053238] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 107.053238] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 107.053238] Process ksoftirqd/1 (pid: 7, threadinfo ffff88013badc000, task ffff88013bad1700)
[ 107.053238] Stack:
[ 107.053238] ffff88013b488b00 ffff8801284f7000 00000a8800000ad7 00000000ffffffff
[ 107.053238] <0> ffff88012862da00 00000000ffffffff ffff88013b4d1000 ffff88013b488b00
[ 107.053238] <0> ffff880001e83ed8 ffffffffa000720f 0000000000000082 0000000000000000
[ 107.053238] Call Trace:
[ 107.053238] <IRQ>
[ 107.053238] [<ffffffffa000720f>] sky2_poll+0xeef/0x1020 [sky2]
[ 107.053238] [<ffffffff8101e1bb>] ? lapic_timer_broadcast+0x1b/0x20
[ 107.053238] [<ffffffff8106a76f>] ? __queue_work+0x3f/0x50
[ 107.053238] [<ffffffff8106a7b9>] ? delayed_work_timer_fn+0x39/0x50
[ 107.053238] [<ffffffff8142bffd>] net_rx_action+0xed/0x1f0
[ 107.053238] [<ffffffff81057250>] __do_softirq+0xb0/0x1d0
[ 107.053238] [<ffffffff81003e4c>] call_softirq+0x1c/0x30
[ 107.053238] <EOI>
[ 107.053238] [<ffffffff810058b5>] ? do_softirq+0x55/0x90
[ 107.053238] [<ffffffff81056dd0>] run_ksoftirqd+0x80/0x130
[ 107.053238] [<ffffffff81056d50>] ? run_ksoftirqd+0x0/0x130
[ 107.053238] [<ffffffff8106e8e6>] kthread+0x96/0xa0
[ 107.053238] [<ffffffff81003d54>] kernel_thread_helper+0x4/0x10
[ 107.053238] [<ffffffff8106e850>] ? kthread+0x0/0xa0
[ 107.053238] [<ffffffff81003d50>] ? kernel_thread_helper+0x0/0x10
[ 107.053238] Code: e8 d3 a7 43 e1 85 c0 0f 85 f5 00 00 00 44 89 f0 ba 00 02 00 00 c1 e0 06 0d a0 01 00 00 89 c0 4
[ 107.053238] RIP [<ffffffffa0001713>] sky2_hw_error+0x153/0x310 [sky2]
[ 107.053238] RSP <ffff880001e83d78>
[ 107.053238] CR2: 0000000000000438
[ 107.392268] ---[ end trace 8a4d942e73cd8681 ]---
[ 107.396866] Kernel panic - not syncing: Fatal exception in interrupt
[ 107.403214] Pid: 7, comm: ksoftirqd/1 Tainted: G D 2.6.34-default #1
[ 107.410230] Call Trace:
[ 107.412695] <IRQ> [<ffffffff8150d49d>] panic+0x7d/0xf7
[ 107.418004] [<ffffffff81511502>] oops_end+0xe2/0xf0
[ 107.422970] [<ffffffff8102dd6b>] no_context+0xfb/0x260
[ 107.428174] [<ffffffff8102dfdd>] __bad_area_nosemaphore+0x10d/0x1c0
[ 107.434523] [<ffffffff8102e0a3>] bad_area_nosemaphore+0x13/0x20
[ 107.440513] [<ffffffff81513aaf>] do_page_fault+0x26f/0x330
[ 107.446084] [<ffffffff815108df>] page_fault+0x1f/0x30
[ 107.451202] [<ffffffffa0001713>] ? sky2_hw_error+0x153/0x310 [sky2]
[ 107.457554] [<ffffffffa00015f6>] ? sky2_hw_error+0x36/0x310 [sky2]
[ 107.463811] [<ffffffffa000720f>] sky2_poll+0xeef/0x1020 [sky2]
[ 107.469706] [<ffffffff8101e1bb>] ? lapic_timer_broadcast+0x1b/0x20
[ 107.475980] [<ffffffff8106a76f>] ? __queue_work+0x3f/0x50
[ 107.481457] [<ffffffff8106a7b9>] ? delayed_work_timer_fn+0x39/0x50
[ 107.487698] [<ffffffff8142bffd>] net_rx_action+0xed/0x1f0
[ 107.493183] [<ffffffff81057250>] __do_softirq+0xb0/0x1d0
[ 107.498558] [<ffffffff81003e4c>] call_softirq+0x1c/0x30
[ 107.503868] <EOI> [<ffffffff810058b5>] ? do_softirq+0x55/0x90
[ 107.509788] [<ffffffff81056dd0>] run_ksoftirqd+0x80/0x130
[ 107.515275] [<ffffffff81056d50>] ? run_ksoftirqd+0x0/0x130
[ 107.520823] [<ffffffff8106e8e6>] kthread+0x96/0xa0
[ 107.525702] [<ffffffff81003d54>] kernel_thread_helper+0x4/0x10
[ 107.531612] [<ffffffff8106e850>] ? kthread+0x0/0xa0
[ 107.536563] [<ffffffff81003d50>] ? kernel_thread_helper+0x0/0x10
[ 107.542657] [drm:drm_fb_helper_panic] *ERROR* panic occurred, switching back to text console
[ 107.551054] BUG: scheduling while atomic: ksoftirqd/1/7/0x10000100
[ 107.552642] Modules linked in: snd_hda_codec_atihdmi snd_hda_codec_idt snd_hda_intel rfcomm snd_pcm_oss snd_hda_2
[ 107.552642] Pid: 7, comm: ksoftirqd/1 Tainted: G D 2.6.34-default #1
[ 107.552642] Call Trace:
[ 107.552642] <IRQ> [<ffffffff810402d1>] __schedule_bug+0x61/0x70
[ 107.552642] [<ffffffff8150ddec>] schedule+0x6cc/0x800
[ 107.552642] [<ffffffff8104c8ba>] __cond_resched+0x2a/0x40
[ 107.552642] [<ffffffff8150e020>] _cond_resched+0x30/0x40
[ 107.552642] [<ffffffff8111e241>] __kmalloc+0xc1/0x190
[ 107.552642] [<ffffffffa00b5613>] ? T.687+0x13/0x20 [drm_kms_helper]
[ 107.552642] [<ffffffffa00b5613>] T.687+0x13/0x20 [drm_kms_helper]
[ 107.552642] [<ffffffffa00b5707>] drm_crtc_helper_set_config+0xe7/0x880 [drm_kms_helper]
[ 107.552642] [<ffffffffa00b35d4>] drm_fb_helper_force_kernel_mode+0x74/0xa0 [drm_kms_helper]
[ 107.552642] [<ffffffffa00b3663>] drm_fb_helper_panic+0x23/0x30 [drm_kms_helper]
[ 107.552642] [<ffffffff81513bc6>] notifier_call_chain+0x56/0x80
[ 107.552642] [<ffffffff81513c2a>] atomic_notifier_call_chain+0x1a/0x20
[ 107.552642] [<ffffffff8150d4c9>] panic+0xa9/0xf7
[ 107.552642] [<ffffffff81511502>] oops_end+0xe2/0xf0
[ 107.552642] [<ffffffff8102dd6b>] no_context+0xfb/0x260
[ 107.552642] [<ffffffff8102dfdd>] __bad_area_nosemaphore+0x10d/0x1c0
[ 107.552642] [<ffffffff8102e0a3>] bad_area_nosemaphore+0x13/0x20
[ 107.552642] [<ffffffff81513aaf>] do_page_fault+0x26f/0x330
[ 107.552642] [<ffffffff815108df>] page_fault+0x1f/0x30
[ 107.552642] [<ffffffffa0001713>] ? sky2_hw_error+0x153/0x310 [sky2]
[ 107.552642] [<ffffffffa00015f6>] ? sky2_hw_error+0x36/0x310 [sky2]
[ 107.552642] [<ffffffffa000720f>] sky2_poll+0xeef/0x1020 [sky2]
[ 107.552642] [<ffffffff8101e1bb>] ? lapic_timer_broadcast+0x1b/0x20
[ 107.552642] [<ffffffff8106a76f>] ? __queue_work+0x3f/0x50
[ 107.552642] [<ffffffff8106a7b9>] ? delayed_work_timer_fn+0x39/0x50
[ 107.552642] [<ffffffff8142bffd>] net_rx_action+0xed/0x1f0
[ 107.552642] [<ffffffff81057250>] __do_softirq+0xb0/0x1d0
[ 107.552642] [<ffffffff81003e4c>] call_softirq+0x1c/0x30
[ 107.552642] <EOI> [<ffffffff810058b5>] ? do_softirq+0x55/0x90
[ 107.552642] [<ffffffff81056dd0>] run_ksoftirqd+0x80/0x130
[ 107.552642] [<ffffffff81056d50>] ? run_ksoftirqd+0x0/0x130
[ 107.552642] [<ffffffff8106e8e6>] kthread+0x96/0xa0
[ 107.552642] [<ffffffff81003d54>] kernel_thread_helper+0x4/0x10
[ 107.552642] [<ffffffff8106e850>] ? kthread+0x0/0xa0
[ 107.552642] [<ffffffff81003d50>] ? kernel_thread_helper+0x0/0x10
lspci -vvv -n of the device:
02:00.0 0200: 11ab:436c (rev 10)
Subsystem: 103c:3080
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 28
Region 0: Memory at d5200000 (64-bit, non-prefetchable) [size=16K]
Region 2: I/O ports at 4000 [size=256]
Expansion ROM at d0000000 [disabled] [size=128K]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] Vital Product Data <?>
Capabilities: [5c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
Address: 00000000fee0100c Data: 4189
Capabilities: [c0] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 unlimited
ClockPM+ Suprise- LLActRep- BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 128 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [100] Advanced Error Reporting <?>
Capabilities: [130] Device Serial Number 70-5a-b6-ff-ff-97-a6-80
Kernel driver in use: sky2
Kernel modules: sky2
Thanks,
Joerg
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/2] bonding: allow user-controlled output slave selection
From: Jay Vosburgh @ 2010-05-17 19:25 UTC (permalink / raw)
To: Neil Horman; +Cc: Andy Gospodarek, netdev
In-Reply-To: <20100517184508.GD17419@hmsreliant.think-freely.org>
Neil Horman <nhorman@tuxdriver.com> wrote:
>Neil Horman <nhorman@tuxdriver.com> wrote:
>> So, its sounding to me like everyone is leaning toward a new mode approach here.
>> Before we go ahead and start coding, I hear the bullet points for this approach
>> as:
>>
>> 1) Implement a new bond mode where queue ids are used to steer frames to output
>> interfaces
>>
>> 2) Use said mode to imply universal frame reception (i.e. remove the keep_all
>> knob, and turn on that behavior when this new mode is selected)
>>
>> 3) use John F.'s skb_should_drop changes to implement the keep_all feature.
>>
>> Does that sound about right?
>>
>> Regards
>> Neil
>>
>Ping, Jay, any feedback on these bullet points. I'd like to keep working on
>this while we have the time, but I'd rather not play guess & check on the list
>here any more than we need to.
I've been thinking on this and trying some variations.
After further discussion with John Fastabend, I don't think a
new mode is warranted for this particular work, largely because the FCOE
case wants to run under essentially any mode (the magic FCOE switches
don't care, they just divert the FC traffic regardless of the switch
port settings). Perhaps some specific multi-queue gizmo will become a
new mode down the road.
Part of my thinking for originally wanting a new mode was that
your changes didn't expose the slave device queues, but after further
discussion, that isn't actually the case.
I thought about removing the whole special case for "deliver to
direct bindings" and have a switch instead to always deliver to
everybody. In the end, I don't think that would end up making things
much simpler, because the special cases have to stay for the "normal"
inactive slave behavior to pass the ARP, ARP-over-VLAN, ETH_P_SLOW, etc
traffic. It also would come at the cost of disabling the duplicate
suppressor for the FCOE case, and I don't think that's what they want.
I'm thinking right now to go with more or less the three patch
series that John Fastabend posted last week, along with a variant of
your patch. As much as I'd like to do both things as a unified patch,
doing so just doesn't seem to simplify the existing code, and ends up
being less than optimal for both cases.
For John's patches, a few minor changes, but that basic idea
(flag in the skb); I'm still chewing on the "VLAN don't copy IFF_MASTER
or SLAVE flag" patch though, just to make sure it won't break anything,
but I don't think it's a critical change.
For your patch, I'm exploring the idea of not setting
IFF_SLAVE_INACTIVE on "inactive" slaves for an "all_slaves_active"
option (I think that's a more descriptive name than "keep_all") instead
of adding a new KEEP_ALL flag bit to priv_flags. Did you consider this
methodology and exclude it for some reason?
Hopefully there won't be any pushback against using a flag bit
in the skb. I haven't thought of a way to do what's desired in an
efficient manner without storing state in the skb somewhere. The
skb->skb_iif does hold the original device receiving the skb, but I have
to believe that converting that to a struct net_device * (for the
"direct bind to original slave" case) in __netif_receive_skb is more
expensive that stashing a flag in the skb.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH] Fix SJA1000 command register writes on SMP systems
From: Oliver Hartkopp @ 2010-05-17 19:47 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: SocketCAN Core Mailing List, Linux Netdev List, David Miller,
stable-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <4BF152E4.1060306-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On 17.05.2010 16:29, Wolfgang Grandegger wrote:
> Hi Oliver,
>
> On 05/17/2010 01:06 PM, Oliver Hartkopp wrote:
>> The SJA1000 command register is concurrently written in the rx-path to free
>> the receive buffer _and_ in the tx-path to start the transmission.
>> On SMP systems this leads to a write stall in the tx-path, which can be
>> solved by adding some locking for the command register in the SMP case.
>
> We should explain why a write stall can happen. Here is the relavant
> part from the SJA1000 data sheet, 6.4.4 COMMAND REGISTER (CMR):
>
> "Between two commands at least one internal clock cycle is needed in
> order to proceed. The internal clock is half of the external oscillator
> frequency."
The delay directly after the register access can only be guaranteed when there
is some locking around the command register write access.
In the end it boils down to a SMP issue again as this is (from all known
environments) the only case, where the problem appears in reality.
This was also what i've taken from the discussion on the SocketCAN ML.
I don't stick on the patch description. Would you like to produce a different
one? My Acked-by for the code remains sure :-)
Regards,
Oliver
^ permalink raw reply
* [PATCH] netfilter: fix description of expected checkentry return code on xt_target
From: Luciano Coelho @ 2010-05-17 20:00 UTC (permalink / raw)
To: netfilter-devel, netdev; +Cc: kaber
The text describing the return codes that are expected on calls to
checkentry() was incorrect. Instead of returning true or false, or an error
code, it should return 0 or an error code.
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
include/linux/netfilter/x_tables.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/netfilter/x_tables.h b/include/linux/netfilter/x_tables.h
index c2ee5d8..c00cc0c 100644
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -333,7 +333,7 @@ struct xt_target {
/* Called when user tries to insert an entry of this type:
hook_mask is a bitmask of hooks from which it can be
called. */
- /* Should return true or false, or an error code (-Exxxx). */
+ /* Should return 0 on success or an error code otherwise (-Exxxx). */
int (*checkentry)(const struct xt_tgchk_param *);
/* Called when entry of this type deleted. */
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] Fix SJA1000 command register writes on SMP systems
From: Wolfgang Grandegger @ 2010-05-17 20:04 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: SocketCAN Core Mailing List, Linux Netdev List, David Miller,
stable-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <4BF19D5B.1070604-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
On 05/17/2010 09:47 PM, Oliver Hartkopp wrote:
> On 17.05.2010 16:29, Wolfgang Grandegger wrote:
>> Hi Oliver,
>>
>> On 05/17/2010 01:06 PM, Oliver Hartkopp wrote:
>>> The SJA1000 command register is concurrently written in the rx-path to free
>>> the receive buffer _and_ in the tx-path to start the transmission.
>>> On SMP systems this leads to a write stall in the tx-path, which can be
>>> solved by adding some locking for the command register in the SMP case.
>>
>> We should explain why a write stall can happen. Here is the relavant
>> part from the SJA1000 data sheet, 6.4.4 COMMAND REGISTER (CMR):
>>
>> "Between two commands at least one internal clock cycle is needed in
>> order to proceed. The internal clock is half of the external oscillator
>> frequency."
>
> The delay directly after the register access can only be guaranteed when there
> is some locking around the command register write access.
Of course.
> In the end it boils down to a SMP issue again as this is (from all known
> environments) the only case, where the problem appears in reality.
> This was also what i've taken from the discussion on the SocketCAN ML.
I know.
> I don't stick on the patch description. Would you like to produce a different
> one? My Acked-by for the code remains sure :-)
I just suggested to mention the hardware requirements in the patch
description so people can understand why we need it. Feel free to add
what I wrote above.
Wolfgang.
^ permalink raw reply
* Re: iproute2 issue with adding rules.
From: Ben Greear @ 2010-05-17 20:13 UTC (permalink / raw)
To: NetDev
In-Reply-To: <4BF192F9.8000008@candelatech.com>
On 05/17/2010 12:03 PM, Ben Greear wrote:
> On older releases, you can do this with iproute:
>
> # ip ru add from 9.9.9.2/32 table 226 pref 400
> #
>
> But, in latest git, it returns an error:
> # ip ru add from 9.9.9.2/32 table 226 pref 400
> Error: an inet prefix is expected rather than "9.9.9.2/32".
>
> Is that on purpose?
I was thinking maybe this was a library issue, since I compiled
on one machine and ran the 'ip' exe on another. So, I tried compiling
on the test system.
But, iproute will not compile, apparently because it finds the
/usr/include/linux header files before whatever is packaged with
iproute:
gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -I../include -DRESOLVE_HOSTNAMES -DLIBDIR=\"/usr/lib/\" -c -o ipaddress.o ipaddress.c
ipaddress.c: In function ‘print_linkinfo’:
ipaddress.c:334: error: ‘IFLA_VFINFO’ undeclared (first use in this function)
ipaddress.c:334: error: (Each undeclared identifier is reported only once
ipaddress.c:334: error: for each function it appears in.)
make[1]: *** [ipaddress.o] Error 1
make[1]: Leaving directory `/root/git/iproute2/ip'
make: *** [all] Error 2
I tried moving /usr/include/linux out of the way, but then it blows up
even worse (can't find errno.h, etc)
Are we supposed to be able to compile iproute2 on a system with moderately
outdated kernel headers?
If not, why bother with the iproute/include/linux directory at all?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH v2] Fix SJA1000 command register writes on SMP systems
From: Oliver Hartkopp @ 2010-05-17 20:17 UTC (permalink / raw)
To: David Miller
Cc: SocketCAN Core Mailing List, Linux Netdev List,
Wolfgang Grandegger
The SJA1000 command register is concurrently written in the rx-path to free
the receive buffer _and_ in the tx-path to start the transmission.
The SJA1000 data sheet, 6.4.4 COMMAND REGISTER (CMR) states:
"Between two commands at least one internal clock cycle is needed in
order to proceed. The internal clock is half of the external oscillator
frequency."
On SMP systems this leads to a write stall in the tx-path, which can be
solved by adding some locking for the command register in the SMP case.
In this special case we also read the status register to settle the command
register write.
Thanks to Klaus Hitschler for the original fix and detailed problem
description.
This patch applies on net-2.6 and (with some offsets) on net-next-2.6 .
Signed-off-by: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
---
diff --git a/drivers/net/can/sja1000/sja1000.c b/drivers/net/can/sja1000/sja1000.c
index 145b1a7..2760085 100644
--- a/drivers/net/can/sja1000/sja1000.c
+++ b/drivers/net/can/sja1000/sja1000.c
@@ -84,6 +84,27 @@ static struct can_bittiming_const sja1000_bittiming_const = {
.brp_inc = 1,
};
+static void sja1000_write_cmdreg(struct sja1000_priv *priv, u8 val)
+{
+ /* the command register needs some locking on SMP systems */
+
+#ifdef CONFIG_SMP
+
+ unsigned long flags;
+
+ spin_lock_irqsave(&priv->cmdreg_lock, flags);
+ priv->write_reg(priv, REG_CMR, val);
+ priv->read_reg(priv, REG_SR);
+ spin_unlock_irqrestore(&priv->cmdreg_lock, flags);
+
+#else
+
+ /* write to the command register without locking */
+ priv->write_reg(priv, REG_CMR, val);
+
+#endif
+}
+
static int sja1000_probe_chip(struct net_device *dev)
{
struct sja1000_priv *priv = netdev_priv(dev);
@@ -297,7 +318,7 @@ static netdev_tx_t sja1000_start_xmit(struct sk_buff *skb,
can_put_echo_skb(skb, dev, 0);
- priv->write_reg(priv, REG_CMR, CMD_TR);
+ sja1000_write_cmdreg(priv, CMD_TR);
return NETDEV_TX_OK;
}
@@ -346,7 +367,7 @@ static void sja1000_rx(struct net_device *dev)
cf->can_id = id;
/* release receive buffer */
- priv->write_reg(priv, REG_CMR, CMD_RRB);
+ sja1000_write_cmdreg(priv, CMD_RRB);
netif_rx(skb);
@@ -374,7 +395,7 @@ static int sja1000_err(struct net_device *dev, uint8_t isrc, uint8_t status)
cf->data[1] = CAN_ERR_CRTL_RX_OVERFLOW;
stats->rx_over_errors++;
stats->rx_errors++;
- priv->write_reg(priv, REG_CMR, CMD_CDO); /* clear bit */
+ sja1000_write_cmdreg(priv, CMD_CDO); /* clear bit */
}
if (isrc & IRQ_EI) {
diff --git a/drivers/net/can/sja1000/sja1000.h b/drivers/net/can/sja1000/sja1000.h
index 97a622b..4527d95 100644
--- a/drivers/net/can/sja1000/sja1000.h
+++ b/drivers/net/can/sja1000/sja1000.h
@@ -168,6 +168,10 @@ struct sja1000_priv {
void __iomem *reg_base; /* ioremap'ed address to registers */
unsigned long irq_flags; /* for request_irq() */
+#ifdef CONFIG_SMP
+ spinlock_t cmdreg_lock; /* lock for concurrent cmd register writes */
+#endif
+
u16 flags; /* custom mode flags */
u8 ocr; /* output control register */
u8 cdr; /* clock divider register */
^ permalink raw reply related
* Re: iproute2 issue with adding rules.
From: Stephen Hemminger @ 2010-05-17 20:27 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4BF1A352.5020500@candelatech.com>
On Mon, 17 May 2010 13:13:06 -0700
Ben Greear <greearb@candelatech.com> wrote:
> On 05/17/2010 12:03 PM, Ben Greear wrote:
> > On older releases, you can do this with iproute:
> >
> > # ip ru add from 9.9.9.2/32 table 226 pref 400
> > #
> >
> > But, in latest git, it returns an error:
> > # ip ru add from 9.9.9.2/32 table 226 pref 400
> > Error: an inet prefix is expected rather than "9.9.9.2/32".
> >
> > Is that on purpose?
>
> I was thinking maybe this was a library issue, since I compiled
> on one machine and ran the 'ip' exe on another. So, I tried compiling
> on the test system.
>
> But, iproute will not compile, apparently because it finds the
> /usr/include/linux header files before whatever is packaged with
> iproute:
>
> gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -I../include -DRESOLVE_HOSTNAMES -DLIBDIR=\"/usr/lib/\" -c -o ipaddress.o ipaddress.c
> ipaddress.c: In function ‘print_linkinfo’:
> ipaddress.c:334: error: ‘IFLA_VFINFO’ undeclared (first use in this function)
> ipaddress.c:334: error: (Each undeclared identifier is reported only once
> ipaddress.c:334: error: for each function it appears in.)
> make[1]: *** [ipaddress.o] Error 1
> make[1]: Leaving directory `/root/git/iproute2/ip'
> make: *** [all] Error 2
>
>
> I tried moving /usr/include/linux out of the way, but then it blows up
> even worse (can't find errno.h, etc)
>
> Are we supposed to be able to compile iproute2 on a system with moderately
> outdated kernel headers?
>
> If not, why bother with the iproute/include/linux directory at all?
The issue is the last minute VF changes in 2.6.34 are not supported
in iproute util yet. Please wait until it is fixed.
^ permalink raw reply
* Re: iproute2 issue with adding rules.
From: Ben Greear @ 2010-05-17 20:28 UTC (permalink / raw)
To: NetDev
In-Reply-To: <4BF1A352.5020500@candelatech.com>
On 05/17/2010 01:13 PM, Ben Greear wrote:
> On 05/17/2010 12:03 PM, Ben Greear wrote:
>> On older releases, you can do this with iproute:
>>
>> # ip ru add from 9.9.9.2/32 table 226 pref 400
>> #
>>
>> But, in latest git, it returns an error:
>> # ip ru add from 9.9.9.2/32 table 226 pref 400
>> Error: an inet prefix is expected rather than "9.9.9.2/32".
>>
>> Is that on purpose?
>
> I was thinking maybe this was a library issue, since I compiled
> on one machine and ran the 'ip' exe on another. So, I tried compiling
> on the test system.
I'm not thinking too well today, but this patch fixes the compile.
No idea if it's actually correct code.
Still can't add the rule like I was trying...but at least it's probably
not an issue with libraries:
[root@ct503-10G-09 iproute2]# git diff
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 48f7b1e..4d4481a 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -331,13 +331,13 @@ int print_linkinfo(const struct sockaddr_nl *who,
);
}
}
- if (do_link && tb[IFLA_VFINFO] && tb[IFLA_NUM_VF]) {
+ if (do_link && tb[IFLA_VFINFO_LIST] && tb[IFLA_NUM_VF]) {
SPRINT_BUF(b1);
- struct rtattr *rta = tb[IFLA_VFINFO];
+ struct rtattr *rta = tb[IFLA_VFINFO_LIST];
struct ifla_vf_info *ivi;
int i;
for (i = 0; i < *(int *)RTA_DATA(tb[IFLA_NUM_VF]); i++) {
- if (rta->rta_type != IFLA_VFINFO) {
+ if (rta->rta_type != IFLA_VFINFO_LIST) {
fprintf(stderr, "BUG: rta type is %d\n", rta->rta_type);
break;
}
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply related
* Re: iproute2 issue with adding rules.
From: Chris Wright @ 2010-05-17 20:30 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4BF1A6D1.70507@candelatech.com>
* Ben Greear (greearb@candelatech.com) wrote:
> On 05/17/2010 01:13 PM, Ben Greear wrote:
> >On 05/17/2010 12:03 PM, Ben Greear wrote:
> >>On older releases, you can do this with iproute:
> >>
> >># ip ru add from 9.9.9.2/32 table 226 pref 400
> >>#
> >>
> >>But, in latest git, it returns an error:
> >># ip ru add from 9.9.9.2/32 table 226 pref 400
> >>Error: an inet prefix is expected rather than "9.9.9.2/32".
> >>
> >>Is that on purpose?
> >
> >I was thinking maybe this was a library issue, since I compiled
> >on one machine and ran the 'ip' exe on another. So, I tried compiling
> >on the test system.
>
> I'm not thinking too well today, but this patch fixes the compile.
> No idea if it's actually correct code.
Needs more changes than that patch.
thanks,
-chris
^ permalink raw reply
* Re: iproute2 issue with adding rules.
From: Ben Greear @ 2010-05-17 20:34 UTC (permalink / raw)
To: Chris Wright; +Cc: NetDev
In-Reply-To: <20100517203004.GD8301@sequoia.sous-sol.org>
On 05/17/2010 01:30 PM, Chris Wright wrote:
> * Ben Greear (greearb@candelatech.com) wrote:
>> On 05/17/2010 01:13 PM, Ben Greear wrote:
>>> On 05/17/2010 12:03 PM, Ben Greear wrote:
>>>> On older releases, you can do this with iproute:
>>>>
>>>> # ip ru add from 9.9.9.2/32 table 226 pref 400
>>>> #
>>>>
>>>> But, in latest git, it returns an error:
>>>> # ip ru add from 9.9.9.2/32 table 226 pref 400
>>>> Error: an inet prefix is expected rather than "9.9.9.2/32".
>>>>
>>>> Is that on purpose?
>>>
>>> I was thinking maybe this was a library issue, since I compiled
>>> on one machine and ran the 'ip' exe on another. So, I tried compiling
>>> on the test system.
>>
>> I'm not thinking too well today, but this patch fixes the compile.
>> No idea if it's actually correct code.
>
> Needs more changes than that patch.
Ok, I'll try going back a few commits to find something that compiles
w/out my hacks.
Also, the rule addition does work..make install put ip in
a different place than it's installed in fedora, so I wasn't
actually running the latest code when I first tried to add
the rule.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: TCP-MD5 checksum failure on x86_64 SMP
From: Stephen Hemminger @ 2010-05-17 20:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: Bijay Singh, David Miller, <bhaskie@gmail.com>,
<bhutchings@solarflare.com>, netdev, Ilpo Järvinen
In-Reply-To: <1274072629.2299.58.camel@edumazet-laptop>
On Mon, 17 May 2010 07:03:49 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 17 mai 2010 à 03:49 +0000, Bijay Singh a écrit :
>
> > I am on quite an old kernel 2.6.27 and could not apply your patches.
> >
> > Then i moved on to the kernel 2.6.32.11 however since then I have not been able to bring up my card, this is something i need to fix before i can test you fix. Working on that.
> >
>
> Thanks again for the status report.
>
> I see bug is older than what I stated in my previous mail
>
> I could reproduce it in my lab and confirm following patch fixes it
>
> This is a stable candidate (2.6.27 kernels)
>
> Thanks
>
> [PATCH] tcp: tcp_synack_options() fix
>
> Commit 33ad798c924b4a (tcp: options clean up) introduced a problem
> if MD5+SACK+timestamps were used in initial SYN message.
>
> Some stacks (old linux for example) try to negotiate MD5+SACK+TSTAMP
> sessions, but since 20 bytes of tcp options space are not enough to
> store all the bits needed, we chose to disable timestamps in this case.
>
> We send a SYN-ACK _without_ timestamp option, but socket has timestamps
> enabled and all further outgoing messages contain a TS block, all with
> the initial timestamp of the remote peer.
>
> Fix is to really disable timestamps option for the whole session.
>
> Reported-by: Bijay Singh <Bijay.Singh@guavus.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/ipv4/tcp_output.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 0dda86e..b8bb226 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -667,7 +667,7 @@ static unsigned tcp_synack_options(struct sock *sk,
> u8 cookie_plus = (xvp != NULL && !xvp->cookie_out_never) ?
> xvp->cookie_plus :
> 0;
> - bool doing_ts = ireq->tstamp_ok;
> + bool doing_ts;
>
> #ifdef CONFIG_TCP_MD5SIG
> *md5 = tcp_rsk(req)->af_specific->md5_lookup(sk, req);
> @@ -680,11 +680,12 @@ static unsigned tcp_synack_options(struct sock *sk,
> * rather than TS in order to fit in better with old,
> * buggy kernels, but that was deemed to be unnecessary.
> */
> - doing_ts &= !ireq->sack_ok;
> + ireq->tstamp_ok &= !ireq->sack_ok;
> }
> #else
> *md5 = NULL;
> #endif
> + doing_ts = ireq->tstamp_ok;
>
> /* We always send an MSS option. */
> opts->mss = mss;
>
>
Since you are doing away with flag variable, why not this instead?
--- a/net/ipv4/tcp_output.c 2010-05-17 13:38:32.822025583 -0700
+++ b/net/ipv4/tcp_output.c 2010-05-17 13:41:47.321734775 -0700
@@ -668,7 +668,6 @@ static unsigned tcp_synack_options(struc
u8 cookie_plus = (xvp != NULL && !xvp->cookie_out_never) ?
xvp->cookie_plus :
0;
- bool doing_ts = ireq->tstamp_ok;
#ifdef CONFIG_TCP_MD5SIG
*md5 = tcp_rsk(req)->af_specific->md5_lookup(sk, req);
@@ -681,7 +680,7 @@ static unsigned tcp_synack_options(struc
* rather than TS in order to fit in better with old,
* buggy kernels, but that was deemed to be unnecessary.
*/
- doing_ts &= !ireq->sack_ok;
+ ireq->tstamp_ok &= !ireq->sack_ok;
}
#else
*md5 = NULL;
@@ -696,7 +695,7 @@ static unsigned tcp_synack_options(struc
opts->options |= OPTION_WSCALE;
remaining -= TCPOLEN_WSCALE_ALIGNED;
}
- if (likely(doing_ts)) {
+ if (likely(ireq->tstamp_ok)) {
opts->options |= OPTION_TS;
opts->tsval = TCP_SKB_CB(skb)->when;
opts->tsecr = req->ts_recent;
@@ -704,7 +703,7 @@ static unsigned tcp_synack_options(struc
}
if (likely(ireq->sack_ok)) {
opts->options |= OPTION_SACK_ADVERTISE;
- if (unlikely(!doing_ts))
+ if (unlikely(!ireq->tstamp_ok))
remaining -= TCPOLEN_SACKPERM_ALIGNED;
}
@@ -712,7 +711,7 @@ static unsigned tcp_synack_options(struc
* If the <SYN> options fit, the same options should fit now!
*/
if (*md5 == NULL &&
- doing_ts &&
+ ireq->tstamp_ok &&
cookie_plus > TCPOLEN_COOKIE_BASE) {
int need = cookie_plus; /* has TCPOLEN_COOKIE_BASE */
--
^ permalink raw reply
* Re: [PATCH 0/6] netns support in the kobject layer
From: Eric W. Biederman @ 2010-05-17 20:58 UTC (permalink / raw)
To: Greg KH
Cc: David Miller, gregkh, kay.sievers, linux-kernel, tj,
cornelia.huck, eric.dumazet, bcrl, serue, netdev
In-Reply-To: <20100517181133.GB18721@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
>> From: Greg KH <greg@kroah.com>
>> Date: Thu, 6 May 2010 13:04:04 -0700
>>
>> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
>> >>
>> >> With the tagged sysfs support finally merged into Greg's tree,
>> >> it is time for the last little bits of work to get the kobject
>> >> layer and network namespaces to play together properly.
>> >>
>> >> These patches are roughly evenly divided between network layer work
>> >> and sysfs layer work. Last time this conundrum came up I believe
>> >> we decided that the easiest way to handle this was for Greg to carry
>> >> all of the patches. David, Greg does that still make sense?
>> >
>> > That's fine, if I get David's ack on these.
>>
>> Looks good to me:
>>
>> Acked-by: David S. Miller <davem@davemloft.net>
>
> Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
> them up then to get some testing in linux-next so that they can make it
> into .36?
Grumble. Grumble. Grumble.
If I must I will resend these, but these patches are already in
production use, and I had them to you weeks before the merge window
closed.
Is there no way we can get these in for 2.6.35?
Eric
^ permalink raw reply
* Re: [PATCH 0/6] netns support in the kobject layer
From: Greg KH @ 2010-05-17 21:03 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Greg KH, David Miller, kay.sievers, linux-kernel, tj,
cornelia.huck, eric.dumazet, bcrl, serue, netdev
In-Reply-To: <m1zkzyfdob.fsf@fess.ebiederm.org>
On Mon, May 17, 2010 at 01:58:44PM -0700, Eric W. Biederman wrote:
> Greg KH <greg@kroah.com> writes:
>
> > On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
> >> From: Greg KH <greg@kroah.com>
> >> Date: Thu, 6 May 2010 13:04:04 -0700
> >>
> >> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
> >> >>
> >> >> With the tagged sysfs support finally merged into Greg's tree,
> >> >> it is time for the last little bits of work to get the kobject
> >> >> layer and network namespaces to play together properly.
> >> >>
> >> >> These patches are roughly evenly divided between network layer work
> >> >> and sysfs layer work. Last time this conundrum came up I believe
> >> >> we decided that the easiest way to handle this was for Greg to carry
> >> >> all of the patches. David, Greg does that still make sense?
> >> >
> >> > That's fine, if I get David's ack on these.
> >>
> >> Looks good to me:
> >>
> >> Acked-by: David S. Miller <davem@davemloft.net>
> >
> > Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
> > them up then to get some testing in linux-next so that they can make it
> > into .36?
>
> Grumble. Grumble. Grumble.
>
> If I must I will resend these, but these patches are already in
> production use, and I had them to you weeks before the merge window
> closed.
Yes, but they were not reviewed by the network maintainer until after
the merge window closed. I already have your sysfs-namespace patches
queued up for .35, and that's a big enough change for me to feel
comfortable with at the moment.
> Is there no way we can get these in for 2.6.35?
No, sorry. One thing at a time please.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] tcp: tcp_synack_options() fix
From: Eric Dumazet @ 2010-05-17 21:04 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Bijay Singh, David Miller, <bhaskie@gmail.com>,
<bhutchings@solarflare.com>, netdev, Ilpo Järvinen
In-Reply-To: <20100517134240.1949f245@nehalam>
Le lundi 17 mai 2010 à 13:42 -0700, Stephen Hemminger a écrit :
> Since you are doing away with flag variable, why not this instead?
>
Sure, we can eliminate this doing_ts variable and save few bytes
Thanks
[PATCH] tcp: tcp_synack_options() fix
Commit 33ad798c924b4a (tcp: options clean up) introduced a problem
if MD5+SACK+timestamps were used in initial SYN message.
Some stacks (old linux for example) try to negotiate MD5+SACK+TSTAMP
sessions, but since 40 bytes of tcp options space are not enough to
store all the bits needed, we chose to disable timestamps in this case.
We send a SYN-ACK _without_ timestamp option, but socket has timestamps
enabled and all further outgoing messages contain a TS block, all with
the initial timestamp of the remote peer.
Fix is to really disable timestamps option for the whole session.
Reported-by: Bijay Singh <Bijay.Singh@guavus.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 0dda86e..44e98d9 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -667,7 +667,6 @@ static unsigned tcp_synack_options(struct sock *sk,
u8 cookie_plus = (xvp != NULL && !xvp->cookie_out_never) ?
xvp->cookie_plus :
0;
- bool doing_ts = ireq->tstamp_ok;
#ifdef CONFIG_TCP_MD5SIG
*md5 = tcp_rsk(req)->af_specific->md5_lookup(sk, req);
@@ -680,7 +679,7 @@ static unsigned tcp_synack_options(struct sock *sk,
* rather than TS in order to fit in better with old,
* buggy kernels, but that was deemed to be unnecessary.
*/
- doing_ts &= !ireq->sack_ok;
+ ireq->tstamp_ok &= !ireq->sack_ok;
}
#else
*md5 = NULL;
@@ -695,7 +694,7 @@ static unsigned tcp_synack_options(struct sock *sk,
opts->options |= OPTION_WSCALE;
remaining -= TCPOLEN_WSCALE_ALIGNED;
}
- if (likely(doing_ts)) {
+ if (likely(ireq->tstamp_ok)) {
opts->options |= OPTION_TS;
opts->tsval = TCP_SKB_CB(skb)->when;
opts->tsecr = req->ts_recent;
@@ -703,7 +702,7 @@ static unsigned tcp_synack_options(struct sock *sk,
}
if (likely(ireq->sack_ok)) {
opts->options |= OPTION_SACK_ADVERTISE;
- if (unlikely(!doing_ts))
+ if (unlikely(!ireq->tstamp_ok))
remaining -= TCPOLEN_SACKPERM_ALIGNED;
}
@@ -711,7 +710,7 @@ static unsigned tcp_synack_options(struct sock *sk,
* If the <SYN> options fit, the same options should fit now!
*/
if (*md5 == NULL &&
- doing_ts &&
+ ireq->tstamp_ok &&
cookie_plus > TCPOLEN_COOKIE_BASE) {
int need = cookie_plus; /* has TCPOLEN_COOKIE_BASE */
^ permalink raw reply related
* [PATCH] [resend] fix non-mergeable buffers packet too large error handling
From: David L Stevens @ 2010-05-17 21:16 UTC (permalink / raw)
To: mst; +Cc: netdev, kvm, virtualization
This patch enforces single-buffer allocation when
mergeable rx buffers is not enabled.
Reported-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 309c570..c346304 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -361,13 +361,21 @@ static void handle_rx(struct vhost_net *net)
break;
}
/* TODO: Should check and handle checksum. */
- if (vhost_has_feature(&net->dev, VIRTIO_NET_F_MRG_RXBUF) &&
- memcpy_toiovecend(vq->hdr, (unsigned char *)&headcount,
- offsetof(typeof(hdr), num_buffers),
- sizeof hdr.num_buffers)) {
- vq_err(vq, "Failed num_buffers write");
+ if (vhost_has_feature(&net->dev, VIRTIO_NET_F_MRG_RXBUF)) {
+ if (memcpy_toiovecend(vq->hdr,
+ (unsigned char *)&headcount,
+ offsetof(typeof(hdr),
+ num_buffers),
+ sizeof hdr.num_buffers)) {
+ vq_err(vq, "Failed num_buffers write");
+ vhost_discard_desc(vq, headcount);
+ break;
+ }
+ } else if (headcount > 1) {
+ vq_err(vq, "rx packet too large (%d) for guest",
+ sock_len);
vhost_discard_desc(vq, headcount);
- break;
+ continue;
}
vhost_add_used_and_signal_n(&net->dev, vq, vq->heads,
headcount);
^ permalink raw reply related
* Re: iproute2 issue with adding rules.
From: Stephen Hemminger @ 2010-05-17 21:41 UTC (permalink / raw)
To: Ben Greear; +Cc: Chris Wright, NetDev
In-Reply-To: <4BF1A855.3090905@candelatech.com>
On Mon, 17 May 2010 13:34:29 -0700
Ben Greear <greearb@candelatech.com> wrote:
> On 05/17/2010 01:30 PM, Chris Wright wrote:
> > * Ben Greear (greearb@candelatech.com) wrote:
> >> On 05/17/2010 01:13 PM, Ben Greear wrote:
> >>> On 05/17/2010 12:03 PM, Ben Greear wrote:
> >>>> On older releases, you can do this with iproute:
> >>>>
> >>>> # ip ru add from 9.9.9.2/32 table 226 pref 400
> >>>> #
> >>>>
> >>>> But, in latest git, it returns an error:
> >>>> # ip ru add from 9.9.9.2/32 table 226 pref 400
> >>>> Error: an inet prefix is expected rather than "9.9.9.2/32".
> >>>>
> >>>> Is that on purpose?
> >>>
> >>> I was thinking maybe this was a library issue, since I compiled
> >>> on one machine and ran the 'ip' exe on another. So, I tried compiling
> >>> on the test system.
> >>
> >> I'm not thinking too well today, but this patch fixes the compile.
> >> No idea if it's actually correct code.
> >
> > Needs more changes than that patch.
>
> Ok, I'll try going back a few commits to find something that compiles
> w/out my hacks.
>
> Also, the rule addition does work..make install put ip in
> a different place than it's installed in fedora, so I wasn't
> actually running the latest code when I first tried to add
> the rule.
Distributions never seem to agree where it should be: /sbin or /usr/sbin
or even /bin
^ permalink raw reply
* Re: [patch] pm_qos update fixing mmotm 2010-05-11 -dies in pm_qos_update_request()
From: Rafael J. Wysocki @ 2010-05-17 21:58 UTC (permalink / raw)
To: markgross
Cc: mgross, Valdis.Kletnieks, e1000-devel, netdev, linux-kernel,
linux-pm, akpm, davem
In-Reply-To: <20100517001241.GA2962@thegnar.org>
On Monday 17 May 2010, mgross wrote:
> On Mon, May 17, 2010 at 12:21:25AM +0200, Rafael J. Wysocki wrote:
> > On Saturday 15 May 2010, mgross wrote:
> > > On Sat, May 15, 2010 at 09:38:47PM +0200, Rafael J. Wysocki wrote:
> > > > On Saturday 15 May 2010, mgross wrote:
> > > > > I apologize for the goofy email address.
> > > > >
> > > > > The following is a fix for the crash reported by Valdis.
> > > > >
> > > > > The problem was that the original pm_qos silently fails when a request
> > > > > update is passed to a parameter that has not been added to the list
> > > > > yet. It seems that the e1000e is doing this. This update restores this
> > > > > behavior.
> > > > >
> > > > > I need to think about how to better handle such abuse, but for now this
> > > > > restores the original behavior.
> > > >
> > > > Can you please post a signed-off incremental patch against
> > > >
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6.git for-llinus
> > > >
> > > > that contains your original PM QOS update?
> > >
> > > No problem:
> > >
> > > Signed-off-by: markgross <markgross@thegnar.org>
> >
> > Thanks! Do you want to use this address for the sign-off or the Intel one?
>
> I guess so. Ever since switching groups within intel last summer my
> mgross@linux.intel.com address isn't checked as often as this one.
>
> The other option is to use my outlook email (mark.gross@intel.com), but
> I really hate posting from outlook. Besides, doing upstream kernel
> stuff isn't my day job any more so using markgross@thegnar.org makes
> sense to me.
Good. Patch applied to suspend-2.6/for-linus.
Thanks,
Rafael
------------------------------------------------------------------------------
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH 0/6] netns support in the kobject layer
From: Eric W. Biederman @ 2010-05-17 22:37 UTC (permalink / raw)
To: Greg KH
Cc: Greg KH, David Miller, kay.sievers, linux-kernel, tj,
cornelia.huck, eric.dumazet, bcrl, serue, netdev
In-Reply-To: <20100517210318.GA6170@suse.de>
Greg KH <gregkh@suse.de> writes:
> On Mon, May 17, 2010 at 01:58:44PM -0700, Eric W. Biederman wrote:
>> Greg KH <greg@kroah.com> writes:
>>
>> > On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
>> >> From: Greg KH <greg@kroah.com>
>> >> Date: Thu, 6 May 2010 13:04:04 -0700
>> >>
>> >> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
>> >> >>
>> >> >> With the tagged sysfs support finally merged into Greg's tree,
>> >> >> it is time for the last little bits of work to get the kobject
>> >> >> layer and network namespaces to play together properly.
>> >> >>
>> >> >> These patches are roughly evenly divided between network layer work
>> >> >> and sysfs layer work. Last time this conundrum came up I believe
>> >> >> we decided that the easiest way to handle this was for Greg to carry
>> >> >> all of the patches. David, Greg does that still make sense?
>> >> >
>> >> > That's fine, if I get David's ack on these.
>> >>
>> >> Looks good to me:
>> >>
>> >> Acked-by: David S. Miller <davem@davemloft.net>
>> >
>> > Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
>> > them up then to get some testing in linux-next so that they can make it
>> > into .36?
>>
>> Grumble. Grumble. Grumble.
>>
>> If I must I will resend these, but these patches are already in
>> production use, and I had them to you weeks before the merge window
>> closed.
>
> Yes, but they were not reviewed by the network maintainer until after
> the merge window closed.
Strictly speaking the day before but I get your point.
> I already have your sysfs-namespace patches
> queued up for .35, and that's a big enough change for me to feel
> comfortable with at the moment.
>
>> Is there no way we can get these in for 2.6.35?
>
> No, sorry. One thing at a time please.
Sure.
If we are going to push this last bit off until the 2.6.36 time frame
Dave, Greg mind if I flip around who I send these patches to?
The big dependency is the sysfs-namespace patches which will be in
2.6.35, and if the patches get into net-next as well as linux-next
there will be a larger number of potential testers.
Eric
^ permalink raw reply
* [PATCH] net: Introduce skb_tunnel_rx() helper
From: Eric Dumazet @ 2010-05-17 22:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev
skb rxhash should be cleared when a skb is handled by a tunnel before
being delivered again, so that correct packet steering can take place.
There are other cleanups and accounting that we can factorize in a new
helper, skb_tunnel_rx()
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/dst.h | 20 ++++++++++++++++++++
net/ipv4/ip_gre.c | 9 +--------
net/ipv4/ipip.c | 7 ++-----
net/ipv4/ipmr.c | 8 +++-----
net/ipv6/ip6_tunnel.c | 8 ++------
net/ipv6/ip6mr.c | 8 +++-----
net/ipv6/sit.c | 8 +++-----
7 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst.h
index aac5a5f..d708c22 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -184,6 +184,26 @@ static inline void skb_dst_drop(struct sk_buff *skb)
skb->_skb_dst = 0UL;
}
+
+/**
+ * skb_tunnel_rx - prepare skb for rx reinsert
+ * @skb: buffer
+ * @dev: tunnel device
+ *
+ * After decapsulation, packet is going to re-enter (netif_rx()) our stack,
+ * so make some cleanups, and perform accounting.
+ */
+static inline void skb_tunnel_rx(struct sk_buff *skb, struct net_device *dev)
+{
+ skb->dev = dev;
+ /* TODO : stats should be SMP safe */
+ dev->stats.rx_packets++;
+ dev->stats.rx_bytes += skb->len;
+ skb->rxhash = 0;
+ skb_dst_drop(skb);
+ nf_reset(skb);
+}
+
/* Children define the path of the packet through the
* Linux networking. Thus, destinations are stackable.
*/
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index fe381d1..498cf69 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -538,7 +538,6 @@ static int ipgre_rcv(struct sk_buff *skb)
struct ip_tunnel *tunnel;
int offset = 4;
__be16 gre_proto;
- unsigned int len;
if (!pskb_may_pull(skb, 16))
goto drop_nolock;
@@ -629,8 +628,6 @@ static int ipgre_rcv(struct sk_buff *skb)
tunnel->i_seqno = seqno + 1;
}
- len = skb->len;
-
/* Warning: All skb pointers will be invalidated! */
if (tunnel->dev->type == ARPHRD_ETHER) {
if (!pskb_may_pull(skb, ETH_HLEN)) {
@@ -644,11 +641,7 @@ static int ipgre_rcv(struct sk_buff *skb)
skb_postpull_rcsum(skb, eth_hdr(skb), ETH_HLEN);
}
- stats->rx_packets++;
- stats->rx_bytes += len;
- skb->dev = tunnel->dev;
- skb_dst_drop(skb);
- nf_reset(skb);
+ skb_tunnel_rx(skb, tunnel->dev);
skb_reset_network_header(skb);
ipgre_ecn_decapsulate(iph, skb);
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index 0b27b14..7fd6367 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -374,11 +374,8 @@ static int ipip_rcv(struct sk_buff *skb)
skb->protocol = htons(ETH_P_IP);
skb->pkt_type = PACKET_HOST;
- tunnel->dev->stats.rx_packets++;
- tunnel->dev->stats.rx_bytes += skb->len;
- skb->dev = tunnel->dev;
- skb_dst_drop(skb);
- nf_reset(skb);
+ skb_tunnel_rx(skb, tunnel->dev);
+
ipip_ecn_decapsulate(iph, skb);
netif_rx(skb);
rcu_read_unlock();
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 7a7ee1c..217ebe0 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1831,14 +1831,12 @@ static int __pim_rcv(struct mr_table *mrt, struct sk_buff *skb,
skb->mac_header = skb->network_header;
skb_pull(skb, (u8*)encap - skb->data);
skb_reset_network_header(skb);
- skb->dev = reg_dev;
skb->protocol = htons(ETH_P_IP);
skb->ip_summed = 0;
skb->pkt_type = PACKET_HOST;
- skb_dst_drop(skb);
- reg_dev->stats.rx_bytes += skb->len;
- reg_dev->stats.rx_packets++;
- nf_reset(skb);
+
+ skb_tunnel_rx(skb, reg_dev);
+
netif_rx(skb);
dev_put(reg_dev);
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 2599870..8f39893 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -723,14 +723,10 @@ static int ip6_tnl_rcv(struct sk_buff *skb, __u16 protocol,
skb->protocol = htons(protocol);
skb->pkt_type = PACKET_HOST;
memset(skb->cb, 0, sizeof(struct inet6_skb_parm));
- skb->dev = t->dev;
- skb_dst_drop(skb);
- nf_reset(skb);
- dscp_ecn_decapsulate(t, ipv6h, skb);
+ skb_tunnel_rx(skb, t->dev);
- t->dev->stats.rx_packets++;
- t->dev->stats.rx_bytes += skb->len;
+ dscp_ecn_decapsulate(t, ipv6h, skb);
netif_rx(skb);
rcu_read_unlock();
return 0;
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 163850e..bd9e7d3 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -658,14 +658,12 @@ static int pim6_rcv(struct sk_buff *skb)
skb->mac_header = skb->network_header;
skb_pull(skb, (u8 *)encap - skb->data);
skb_reset_network_header(skb);
- skb->dev = reg_dev;
skb->protocol = htons(ETH_P_IPV6);
skb->ip_summed = 0;
skb->pkt_type = PACKET_HOST;
- skb_dst_drop(skb);
- reg_dev->stats.rx_bytes += skb->len;
- reg_dev->stats.rx_packets++;
- nf_reset(skb);
+
+ skb_tunnel_rx(skb, reg_dev);
+
netif_rx(skb);
dev_put(reg_dev);
return 0;
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 5abae10..e51e650 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -566,11 +566,9 @@ static int ipip6_rcv(struct sk_buff *skb)
kfree_skb(skb);
return 0;
}
- tunnel->dev->stats.rx_packets++;
- tunnel->dev->stats.rx_bytes += skb->len;
- skb->dev = tunnel->dev;
- skb_dst_drop(skb);
- nf_reset(skb);
+
+ skb_tunnel_rx(skb, tunnel->dev);
+
ipip6_ecn_decapsulate(iph, skb);
netif_rx(skb);
rcu_read_unlock();
^ permalink raw reply related
* Re: [PATCH 0/6] netns support in the kobject layer
From: Greg KH @ 2010-05-17 22:54 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Greg KH, David Miller, kay.sievers, linux-kernel, tj,
cornelia.huck, eric.dumazet, bcrl, serue, netdev
In-Reply-To: <m1hbm6f93x.fsf@fess.ebiederm.org>
On Mon, May 17, 2010 at 03:37:22PM -0700, Eric W. Biederman wrote:
> Greg KH <gregkh@suse.de> writes:
>
> > On Mon, May 17, 2010 at 01:58:44PM -0700, Eric W. Biederman wrote:
> >> Greg KH <greg@kroah.com> writes:
> >>
> >> > On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
> >> >> From: Greg KH <greg@kroah.com>
> >> >> Date: Thu, 6 May 2010 13:04:04 -0700
> >> >>
> >> >> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
> >> >> >>
> >> >> >> With the tagged sysfs support finally merged into Greg's tree,
> >> >> >> it is time for the last little bits of work to get the kobject
> >> >> >> layer and network namespaces to play together properly.
> >> >> >>
> >> >> >> These patches are roughly evenly divided between network layer work
> >> >> >> and sysfs layer work. Last time this conundrum came up I believe
> >> >> >> we decided that the easiest way to handle this was for Greg to carry
> >> >> >> all of the patches. David, Greg does that still make sense?
> >> >> >
> >> >> > That's fine, if I get David's ack on these.
> >> >>
> >> >> Looks good to me:
> >> >>
> >> >> Acked-by: David S. Miller <davem@davemloft.net>
> >> >
> >> > Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
> >> > them up then to get some testing in linux-next so that they can make it
> >> > into .36?
> >>
> >> Grumble. Grumble. Grumble.
> >>
> >> If I must I will resend these, but these patches are already in
> >> production use, and I had them to you weeks before the merge window
> >> closed.
> >
> > Yes, but they were not reviewed by the network maintainer until after
> > the merge window closed.
>
> Strictly speaking the day before but I get your point.
>
> > I already have your sysfs-namespace patches
> > queued up for .35, and that's a big enough change for me to feel
> > comfortable with at the moment.
> >
> >> Is there no way we can get these in for 2.6.35?
> >
> > No, sorry. One thing at a time please.
>
> Sure.
>
> If we are going to push this last bit off until the 2.6.36 time frame
> Dave, Greg mind if I flip around who I send these patches to?
>
> The big dependency is the sysfs-namespace patches which will be in
> 2.6.35, and if the patches get into net-next as well as linux-next
> there will be a larger number of potential testers.
Sure, that's fine with me.
thanks,
greg k-h
^ 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