* RE: [PATCH 2/2] packet: Add fanout support.
From: Loke, Chetan @ 2011-07-05 21:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Victor Julien, David Miller, netdev
In-Reply-To: <1309890032.2545.8.camel@edumazet-laptop>
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: July 05, 2011 2:21 PM
> To: Loke, Chetan
> Cc: Victor Julien; David Miller; netdev@vger.kernel.org
> Subject: RE: [PATCH 2/2] packet: Add fanout support.
>
> Le mardi 05 juillet 2011 à 13:35 -0400, Loke, Chetan a écrit :
>
> > Sure, a lookup is needed(to steer what I call - Hot/Cold flows) and
> > was proposed by me on the oisf mailing list. Always, use the ip_id
> bit
> > then? Another problem that needs to be solved is, what if some
> > decoders are overloaded, then what? How will this scheme work? How
> > will we utilize other CPUs? RPS is needed for sure.
> >
> > If we maintain a i) per port lookup-table ii) 2^20 flows/table and
> > iii) 16 bytes/flow(one can also squeeze it down to 8 bytes) then we
> > will need around 32MB worth memory/port. It's not a huge memory
> > pressure for folks who want to use linux for doing IPS/IDS sort of
> > stuff.
> >
> > User-space decoders end up copying the packet anyways. So fanout can
> > be implemented in user-space to achieve effective CPU utilization.
> > As long as we don't bounce on different CPU-socket we could be ok.
>
> This is the problem we want to address.
>
> Going into user-space to perform the fanout is what you already have
> today, with one socket, one thread doing the fanout to worker threads.
>
> David patch is non adaptative : its a hash on N queue, with a fixed
> hash
> function.
>
> What you want is to add another 'control queue' where new flows are
> directed. Then user application is able to reinject into kernel flow
> director the "This flow should go to queue X" information.
>
I like the term - 'kernel-flow-director'. The problem with rebalancing from user-space is that we will need to have some 'idle' period before we inject flow-redirection event into the kernel. And for bursty workloads this may be problematic. We may have to rebalance often. And then we will have to export the 'rebalance-idle-interval' knob.
And users may have to tune it for their workloads etc.
> Or, let the kernel do a mix of rxhash and loadbalance : Be able to
> select a queue for a new flow without user land control, using a Flow
> hash table.
>
This is exactly what I had proposed. Hash{== lookup of hot/cold flows}+LB{== kernel-flow-director} is what we need.
So something like:
hot_fanout_id = is_flow_active(rx_hash,lookup_table);
if (hot_fanout_id)
/* This flow is Hot */
steer_to(hot_fanout_id);
else {
/* This flow is cold - Get next_rr fanout_id */
fanout_rr_next(...);
...
steer_to(cold_fanout_id);
}
And,
1)hash on <src_ip_addr,dst_ip_addr,src_port,dst_port>
2)store the ip_id from the first fragment in the flow_hash_table for matching subsequent ip_fragments.
One corner case - If the first fragment arrives out-of-order(OOO).
2.1) user has configured - assemble-fragments: In this case it doesn’t matter.
2.2) user has configured - fwd-as-is: Redirect OOO-fragments to the next_rr_fanout_id.
2.2.1)
And so we may have to set a bit in hash_lookup_table for a flow indicating it arrived 'OOO'.
So, is_flow_active will have to lookup twice. First using ip_id as 3rd var in jhash. And second lookup using ports as 3rd var. Worst case there will be two lookups on OOO.
OR
2.2.2) Effectively treat this fragment as 'assemble-fragments' case(?) as in 2.1).
So {hash+LB} together, should take care of the fragmented/non-fragmented flow.
We will have to purge the flow-entry at some point to avoid false routing. Don't know if the control-queue that you mentioned above can be used for purging flows?
Or the control-queue itself can be mmap'd so that user-space can clear 'a' flow-entry?
Chetan Loke
^ permalink raw reply
* pull request: wireless-next-2.6 2011-07-05
From: John W. Linville @ 2011-07-05 20:41 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Dave,
Here is another big batch of changed intended for 3.1. This looks
bigger than it is, as it also contains a wireless-2.6 pull to resolve
some build conflicts.
The most noteworth item is yet another rtlwifi-based driver (rtl8192de).
There is also some HT-phy work for b43, plus the usual contributions
from the ath9k and iwlwifi crews and a variety of other bits here and
there.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 7d09926d1decb658d4e24f70216b6b0b74168026:
bnx2x: Fix warning message during 57712/8727 initialization (2011-07-05 04:21:40 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git for-davem
Arik Nemtsov (5):
mac80211: fix rx->key NULL dereference during mic failure
mac80211: reestablish mis-configured existing Rx BA sessions
mac80211: dynamic PS - don't enter PS when TX frames are pending
mac80211: propagate information about STA WME support down
wl12xx: AP-mode - use mac80211 indication about STA WME support
Chaoming Li (12):
rtlwifi: rtl8192de: Merge def.h
rtlwifi: rtl8192de: Merge dynamic management routines
rtlwifi: rtl8192de: Merge firmware routines
rtlwifi: rtl8192de: Merge hardware routines
rtlwifi: rtl8192de: Merge led routines
rtlwifi: rtl8192de: Merge phy routines
rtlwifi: rtl8192de: Merge register definitions
rtlwifi: rtl8192de: Merge rf routines
rtlwifi: rtl8192de: Merge main (sw) routines
rtlwifi: rtl8192de: Merge table routines
rtlwifi: rtl8192de: Merge TX and RX routines
rtlwifi: rtl8192de: Modify Kconfig and Makefile routines for new driver
Dan Carpenter (2):
mwifiex: restore handling of NULL parameters
rtlwifi: potential forever loop in rtl92de_hw_init()
Emmanuel Grumbach (1):
iwlagn: Fix a bug introduced by the HUGE command removal
Evgeni Golov (1):
iwlagn: fix *_UCODE_API_MAX output in the firmware field
Geert Uytterhoeven (1):
bcma: main.c needs to include <linux/slab.h>
Hauke Mehrtens (1):
ssb: fix ssb clock rate according to broadcom source
Joe Perches (1):
rt2x00: Fix unspeficied typo
Johannes Berg (10):
iwlagn: fix change_interface for P2P types
iwlagn: use PM ops macro
iwlagn: fix cmd queue unmap
iwlagn: extend host command timeout
iwlagn: fill beacon TX rate properly
iwlagn: don't use CCK rates for P2P interfaces
iwlagn: fix cmd queue unmap
iwlagn: map command buffers BIDI
wireless: unify QoS control field definitions
mac80211: restrict advertised HW scan rates
John W. Linville (6):
Merge branch 'master' of master.kernel.org:/.../padovan/bluetooth-2.6
Merge branch 'wireless-2.6' of git://git.kernel.org/.../iwlwifi/iwlwifi-2.6
Merge branch 'wireless-next-2.6' of git://git.kernel.org/.../iwlwifi/iwlwifi-2.6
iwlagn: use PCI_DMA_* for pci_* operations
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
Jon Mason (3):
iwlegacy: remove unnecessary read of PCI_CAP_ID_EXP
rtlwifi: remove unnecessary read of PCI_CAP_ID_EXP
rtlwifi: use PCI_VENDOR_ID_*
Larry Finger (4):
rtlwifi: rtl8192se: Handle duplicate PCI ID 0x10ec:0x8192 conflict with r8192e_pci
rtl8192cu: Fix missing firmware load
rtlwifi: Fix build problems introduced by merging rtl8192de
rtlwifi: rtl8192de: Fix build errors when using allyes configuration
Mohammed Shafi Shajakhan (4):
ath9k_hw: Add carrier leak correction in desired gain calculation
ath9k_hw: make use of the gain_table_entry macro
ath9k: move few descriptor macros to ath9k.h
ath9k_htc: Add device ID for Sony UWA-BR100
Paul Stewart (1):
mac80211: Drop DS Channel PARAM in directed probe
Rafał Miłecki (10):
b43: HT-PHY: prepare place for HT-PHY tables
b43: HT-PHY: upload PHY values when switching channel
b43: HT-PHY: perform some tables ops on channel switching
b43: HT-PHY: add channel switching tables for 2 GHz band
b43: HT-PHY: implement lacking 0x908 PHY reg op
b43: HT-PHY: replace radio routing magic numbers
b43: HT-PHY: init radio when enabling it
b43: HT-PHY: add init tables
b43: HT-PHY: basic PHY init
b43: HT-PHY: correct 0x2059 radio init
Rajkumar Manoharan (2):
ath9k_hw: Fix false tx hung detection in AR9003 chips
ath9k: Fix locking issue during tx completion
Randy Dunlap (1):
bluetooth: uses crypto interfaces, select CRYPTO
Sergei Shtylyov (2):
ssb: use pci_dev->revision
iwlwifi: use pci_dev->revision, again
Stanislaw Gruszka (1):
iwlagn: fix rmmod crash
drivers/bcma/main.c | 1 +
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 8 +-
drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 38 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 3 +
drivers/net/wireless/ath/ath9k/ath9k.h | 5 +
drivers/net/wireless/ath/ath9k/beacon.c | 8 +
drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +
drivers/net/wireless/ath/ath9k/init.c | 7 -
drivers/net/wireless/ath/ath9k/main.c | 13 +-
drivers/net/wireless/ath/ath9k/xmit.c | 7 +-
drivers/net/wireless/ath/carl9170/rx.c | 2 +-
drivers/net/wireless/b43/Makefile | 1 +
drivers/net/wireless/b43/phy_ht.c | 132 +-
drivers/net/wireless/b43/phy_ht.h | 14 +-
drivers/net/wireless/b43/radio_2059.c | 135 +
drivers/net/wireless/b43/radio_2059.h | 5 +
drivers/net/wireless/b43/tables_phy_ht.c | 750 +++++
drivers/net/wireless/b43/tables_phy_ht.h | 22 +
drivers/net/wireless/iwlegacy/iwl-core.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-2000.c | 7 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 2 +
drivers/net/wireless/iwlwifi/iwl-agn-sta.c | 17 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 26 +-
drivers/net/wireless/iwlwifi/iwl-agn.h | 2 +
drivers/net/wireless/iwlwifi/iwl-core.c | 16 +-
drivers/net/wireless/iwlwifi/iwl-core.h | 7 -
drivers/net/wireless/iwlwifi/iwl-hcmd.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-pci.c | 20 +-
drivers/net/wireless/iwlwifi/iwl-tx.c | 25 +-
drivers/net/wireless/libertas_tf/main.c | 2 +-
drivers/net/wireless/mac80211_hwsim.c | 2 +
drivers/net/wireless/mwifiex/sta_cmd.c | 2 +
drivers/net/wireless/mwifiex/sta_cmdresp.c | 29 +-
drivers/net/wireless/rt2x00/rt2x00queue.h | 2 +-
drivers/net/wireless/rtlwifi/Kconfig | 15 +-
drivers/net/wireless/rtlwifi/Makefile | 1 +
drivers/net/wireless/rtlwifi/pci.c | 23 +-
drivers/net/wireless/rtlwifi/pci.h | 11 -
drivers/net/wireless/rtlwifi/rtl8192ce/reg.h | 2 +
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 20 +
drivers/net/wireless/rtlwifi/rtl8192de/Makefile | 14 +
drivers/net/wireless/rtlwifi/rtl8192de/def.h | 269 ++
drivers/net/wireless/rtlwifi/rtl8192de/dm.c | 1355 ++++++++
drivers/net/wireless/rtlwifi/rtl8192de/dm.h | 212 ++
drivers/net/wireless/rtlwifi/rtl8192de/fw.c | 790 +++++
drivers/net/wireless/rtlwifi/rtl8192de/fw.h | 155 +
drivers/net/wireless/rtlwifi/rtl8192de/hw.c | 2326 ++++++++++++++
drivers/net/wireless/rtlwifi/rtl8192de/hw.h | 66 +
drivers/net/wireless/rtlwifi/rtl8192de/led.c | 159 +
drivers/net/wireless/rtlwifi/rtl8192de/led.h | 38 +
drivers/net/wireless/rtlwifi/rtl8192de/phy.c | 3837 +++++++++++++++++++++++
drivers/net/wireless/rtlwifi/rtl8192de/phy.h | 178 ++
drivers/net/wireless/rtlwifi/rtl8192de/reg.h | 1313 ++++++++
drivers/net/wireless/rtlwifi/rtl8192de/rf.c | 628 ++++
drivers/net/wireless/rtlwifi/rtl8192de/rf.h | 44 +
drivers/net/wireless/rtlwifi/rtl8192de/sw.c | 423 +++
drivers/net/wireless/rtlwifi/rtl8192de/sw.h | 37 +
drivers/net/wireless/rtlwifi/rtl8192de/table.c | 1690 ++++++++++
drivers/net/wireless/rtlwifi/rtl8192de/table.h | 57 +
drivers/net/wireless/rtlwifi/rtl8192de/trx.c | 959 ++++++
drivers/net/wireless/rtlwifi/rtl8192de/trx.h | 756 +++++
drivers/net/wireless/rtlwifi/wifi.h | 3 -
drivers/net/wireless/wl12xx/cmd.c | 9 +-
drivers/ssb/main.c | 4 +-
drivers/ssb/scan.c | 3 +-
include/linux/ieee80211.h | 18 +-
include/net/cfg80211.h | 2 +-
include/net/mac80211.h | 2 +
net/bluetooth/Kconfig | 1 +
net/mac80211/agg-rx.c | 6 +-
net/mac80211/cfg.c | 5 +-
net/mac80211/ieee80211_i.h | 6 +-
net/mac80211/mlme.c | 41 +-
net/mac80211/rx.c | 2 +-
net/mac80211/scan.c | 8 +-
net/mac80211/util.c | 21 +-
net/mac80211/wme.c | 3 +-
net/mac80211/wme.h | 5 -
net/mac80211/work.c | 2 +-
net/mac80211/wpa.c | 8 +-
net/wireless/nl80211.c | 3 +-
84 files changed, 16663 insertions(+), 202 deletions(-)
create mode 100644 drivers/net/wireless/b43/tables_phy_ht.c
create mode 100644 drivers/net/wireless/b43/tables_phy_ht.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/Makefile
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/def.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/dm.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/dm.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/fw.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/fw.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/hw.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/hw.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/led.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/led.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/phy.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/phy.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/reg.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/rf.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/rf.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/sw.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/sw.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/table.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/table.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/trx.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/trx.h
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2011-07-05.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: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-05 20:15 UTC (permalink / raw)
To: Neil Horman
Cc: Alexey Zaytsev, Michael Büsch, Andrew Morton, netdev,
Gary Zambrano, bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <1309896147.2545.28.camel@edumazet-laptop>
Le mardi 05 juillet 2011 à 22:02 +0200, Eric Dumazet a écrit :
> Le mardi 05 juillet 2011 à 15:53 -0400, Neil Horman a écrit :
> > I think this is a goo idea, at least for testing. It seems odd to me that we
> > have the B44_DMARX_PTR value which indicates (ostensibly) the pointer to the
> > descriptor to be processed next (the documentation isnt' very verbose on the
> > subject), along with the EOT bit on a descriptor. It seems like both the
> > register and the bit are capable of conveying the same (or at least overlapping)
> > information.
> >
> > I think what I'm having the most trouble with is understanding when the hw looks
> > at the EOT bit in the descriptor. If it completes a DMA and sees the EOT bit
> > set, does the next DMA occur to the descriptor pointed to by the DMARX_ADDR
> > register? Of does it stall until such time as the DMARX_PTR register is rotated
> > around? What if it doesn't see the EOT bit set? Does it just keep going with
> > the next descriptor?
Since there is no OWN bit (at least not on the online doc I got : it
says the rx_ring is read only by the NIC), I would say we really need to
advance DMARX_PTR to signal NIC a new entry is available for following
incoming frames.
This is the reason rx_pending max value is B44_RX_RING_SIZE - 1, or else
chip could loop on a circular rx_ring.
^ permalink raw reply
* Re: libpcap and tc filters
From: Adam Katz @ 2011-07-05 20:07 UTC (permalink / raw)
To: jhs; +Cc: Eric Dumazet, netdev
In-Reply-To: <1309893553.1733.41.camel@mojatatu>
I don't think so. I tried different versions of tcpreplay.
The solution didn't work on 3 different ubuntu 10.04 machines with
2.6.32-32 (actually one of them had 2.6.32-31) but it DID work on a
fedora core 15 virtual machine with a newer kernel as well as a second
virtual machine with on which I installed stock ubuntu 11.04 just for
this test. It has 2.6.38 i think. On the last three machines (the
third ubuntu 10.04 as well as fc15 and ubuntu 11.04 tcpreplay came
straight from the repository).
Just to make myself clear - earlier, I tried the solution on a 10.04
physical box with various versions of tcpreplay, libpcap, and
iproute2. nothing worked.
On Tue, Jul 5, 2011 at 10:19 PM, jamal <hadi@cyberus.ca> wrote:
> On Tue, 2011-07-05 at 19:54 +0300, Adam Katz wrote:
>
>>
>> unless someone suggests a better solution, it seems like i'll be
>> adhering to the first law of engineering - "if it works, don't fix it"
>> and simply replace install fedora core 15 instead of ubuntu.
>
> My feeling is it has nothing to do with distro. Probably
> your tcpreplay?
>
> I am running ubuntu 10.04, but own compiled kernel (3.0-rc4).
> tcpreplay is older than Eric's version:
> --
> tcpreplay version: 3.4.3 (build 2375)
> Copyright 2001-2009 by Aaron Turner <aturner at synfin dot net>
> Cache file supported: 04
> Not compiled with libdnet.
> Compiled against libpcap: 1.0.0
> 64 bit packet counters: enabled
> Verbose printing via tcpdump: enabled
> Packet editing: disabled
> Fragroute engine: disabled
> Injection method: PF_PACKET send()
> ---
>
> cheers,
> jamal
>
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-05 20:02 UTC (permalink / raw)
To: Neil Horman
Cc: Alexey Zaytsev, Michael Büsch, Andrew Morton, netdev,
Gary Zambrano, bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <20110705195353.GG2959@hmsreliant.think-freely.org>
Le mardi 05 juillet 2011 à 15:53 -0400, Neil Horman a écrit :
> I think this is a goo idea, at least for testing. It seems odd to me that we
> have the B44_DMARX_PTR value which indicates (ostensibly) the pointer to the
> descriptor to be processed next (the documentation isnt' very verbose on the
> subject), along with the EOT bit on a descriptor. It seems like both the
> register and the bit are capable of conveying the same (or at least overlapping)
> information.
>
> I think what I'm having the most trouble with is understanding when the hw looks
> at the EOT bit in the descriptor. If it completes a DMA and sees the EOT bit
> set, does the next DMA occur to the descriptor pointed to by the DMARX_ADDR
> register? Of does it stall until such time as the DMARX_PTR register is rotated
> around? What if it doesn't see the EOT bit set? Does it just keep going with
> the next descriptor?
>
> Also, there seems to be some inconsistency in the settnig of the B44_DMARX_PTR
> register. In bnx2_init_hw its set to the value of bp->rx_pending, which is
> defined as being 200. But in b44_rx its advanced by sizeof(struct dma_desc) for
> every iteration. So in b44_init_hw we write the value 200 to it, ostensibly
> indicating a limit of 200 descriptors, but in b44_rx we iteratively write the
> values 0, 8, 16, 24...4*n to the register to indicate which descriptor we're
> indexing? Something really doesn't sit right with me there. In the former case
> we treat the register as holding number of entries, and in the latter we treat
> it as holding a byte offset into an array. Or am I missing something?
>
Yes, definitely this needs some clarification.
More over, when we hit the last entry (currently at slot 511), the EOT
instructs hardware to go back to slot 0, while our real window is
511-200 -> 511 . Slot 0 contains garbage (well, an old value)
Its late here so I dont plan to send a patch before 8/10 hours.
^ permalink raw reply
* Re: coding style question on indentation
From: Joe Perches @ 2011-07-05 20:01 UTC (permalink / raw)
To: Chris Friesen; +Cc: Sathya.Perla, netdev
In-Reply-To: <4E136C0C.8010806@genband.com>
On Tue, 2011-07-05 at 13:54 -0600, Chris Friesen wrote:
> On 07/01/2011 09:23 AM, Joe Perches wrote:
> > I think this better:
> > 1 2 3 4 5 6 7 8
> > 12345678901234567890123456789012345678901234567890123456789012345678901234567890
> > dma_unmap_page(&adapter->pdev->dev, dma_unmap_addr(rx_page_info, bus),
> > adapter->big_page_size, DMA_FROM_DEVICE);
> > maximally fill to 80 cols, then wrap with maximal tabs using spaces
> > if necessary to align args after opening parenthesis.
> > In this case, 2 tabs, 7 spaces.
> I think the most flexible is to use hard tabs to align the continued
> line to the same level of indentation as the parent line, then use
> spaces for "pretty" alignment. That way, it all lines up regardless of
> how many spaces the viewer has set for the equivalent size of hard tabs.
True, but none of the common editing tools do this.
You could produce and publish emacs/vi modes for this
and then teach checkpatch to understand this mode and
not complain about the spacing if it matters that much
to you.
^ permalink raw reply
* Re: IPv6 destination cache in Linux kernel
From: Chris Friesen @ 2011-07-05 19:58 UTC (permalink / raw)
To: David Miller; +Cc: mparemm, netdev
In-Reply-To: <20110704.174619.1196575558517508080.davem@davemloft.net>
On 07/04/2011 06:46 PM, David Miller wrote:
> From: Mikhail Paremski<mparemm@gmail.com>
> Date: Mon, 4 Jul 2011 17:35:04 -0700
>
>> 1. What are the reasons to rout datagrams differently fromIPv4?
>
> It was just a design decision made when the ipv6 routing code
> was implemented.
Presumably there was some rationale for doing it differently than the
existing IPv4 code. Or was it just for fun?
>> 2. Where I could get details how IPv6 stack routes datagrams?
>
> By reading the source code.
While the source code has the final say, for someone new to a given part
of the kernel it is helpful to have a high-level view of the overall
flow. It's a lot easier to understand something if you can place it in
the overall scheme of of things.
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* Re: coding style question on indentation
From: Chris Friesen @ 2011-07-05 19:54 UTC (permalink / raw)
To: Joe Perches; +Cc: Sathya.Perla, netdev
In-Reply-To: <1309533793.7277.51.camel@Joe-Laptop>
On 07/01/2011 09:23 AM, Joe Perches wrote:
> I think this better:
>
> 1 2 3 4 5 6 7 8
> 12345678901234567890123456789012345678901234567890123456789012345678901234567890
>
> dma_unmap_page(&adapter->pdev->dev, dma_unmap_addr(rx_page_info, bus),
> adapter->big_page_size, DMA_FROM_DEVICE);
>
> maximally fill to 80 cols, then wrap with maximal tabs using spaces
> if necessary to align args after opening parenthesis.
> In this case, 2 tabs, 7 spaces.
I think the most flexible is to use hard tabs to align the continued
line to the same level of indentation as the parent line, then use
spaces for "pretty" alignment. That way, it all lines up regardless of
how many spaces the viewer has set for the equivalent size of hard tabs.
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Neil Horman @ 2011-07-05 19:53 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexey Zaytsev, Michael Büsch, Andrew Morton, netdev,
Gary Zambrano, bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <1309891516.2545.23.camel@edumazet-laptop>
On Tue, Jul 05, 2011 at 08:45:16PM +0200, Eric Dumazet wrote:
> Le mardi 05 juillet 2011 à 20:32 +0200, Eric Dumazet a écrit :
>
> > Then, maybe the driver model is completely wrong, and should really
> > setup 512 buffers, or use less descs but set EOT on last one.
> >
> > Currently it uses a 200 sliding window out of the 512 descs.
> >
> >
>
> One thing we could do would be to allocate a special guard buffer and
> set all 'out of window' descriptors to point to this guard buffer, and
> periodically check if buffer is dirtied by the card.
>
> (first word would be enough)
>
> (instead of setting desc->addr to NULL, set to
> dma_map_single(guard_buffer))
>
I think this is a goo idea, at least for testing. It seems odd to me that we
have the B44_DMARX_PTR value which indicates (ostensibly) the pointer to the
descriptor to be processed next (the documentation isnt' very verbose on the
subject), along with the EOT bit on a descriptor. It seems like both the
register and the bit are capable of conveying the same (or at least overlapping)
information.
I think what I'm having the most trouble with is understanding when the hw looks
at the EOT bit in the descriptor. If it completes a DMA and sees the EOT bit
set, does the next DMA occur to the descriptor pointed to by the DMARX_ADDR
register? Of does it stall until such time as the DMARX_PTR register is rotated
around? What if it doesn't see the EOT bit set? Does it just keep going with
the next descriptor?
Also, there seems to be some inconsistency in the settnig of the B44_DMARX_PTR
register. In bnx2_init_hw its set to the value of bp->rx_pending, which is
defined as being 200. But in b44_rx its advanced by sizeof(struct dma_desc) for
every iteration. So in b44_init_hw we write the value 200 to it, ostensibly
indicating a limit of 200 descriptors, but in b44_rx we iteratively write the
values 0, 8, 16, 24...4*n to the register to indicate which descriptor we're
indexing? Something really doesn't sit right with me there. In the former case
we treat the register as holding number of entries, and in the latter we treat
it as holding a byte offset into an array. Or am I missing something?
Regards
Neil
>
>
> --
> 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
* Re: divide error: 0000, in bictcp_cong_avoid, kernel 2.6.39
From: TB @ 2011-07-05 19:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20110705101618.744bbab0@nehalam.ftrdhcpuser.net>
[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]
On 11-07-05 01:16 PM, Stephen Hemminger wrote:
> On Mon, 04 Jul 2011 14:10:16 -0400
> TB <lkml@techboom.com> wrote:
>
>> On 11-07-04 01:36 PM, Stephen Hemminger wrote:
>>> Any data about the type of connection, kernel configuration or other
>>> information that might be useful in reproducing the problem?
>>>
>>> Also please try 2.6.39.2
>>
>> We haven't found a sure way of reproducing it.
>> It happened on 1.2% of our servers over the weekend and seems random.
>> Both are connected with 2 gigabit ports using bonding. Traffic tends to
>> be heavy, but doesn't seem to be a factor.
>>
>> Would a .config help ?
>>
>> Only the very basic filter module for iptables is compiled in.
>>
>> We will try 2.6.39.2 soon
>
> Kernel config (and compiler version) would help in identifying which
> of the three divides is getting divide by zero.
# gcc --version
gcc (Debian 4.3.2-1.1) 4.3.2
# as --version
GNU assembler (GNU Binutils for Debian) 2.18.0.20080103
This assembler was configured for a target of `x86_64-linux-gnu'.
[-- Attachment #2: config.gz --]
[-- Type: application/x-gzip, Size: 13475 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3 v2] ssb: use pci_dev->subsystem_{vendor,device}
From: John W. Linville @ 2011-07-05 19:34 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: mb, netdev
In-Reply-To: <201107012234.42426.sshtylyov@ru.mvista.com>
On Fri, Jul 01, 2011 at 10:34:42PM +0400, Sergei Shtylyov wrote:
> The SSB code reads PCI subsystem IDs from the PCI configuration registers while
> they are already stored by the PCI subsystem in the 'subsystem_{vendor|device}'
> fields of 'struct pci_dev'...
>
> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Applied.
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 2/3 v2] ssb: use pci_dev->revision
From: John W. Linville @ 2011-07-05 19:34 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: mb, netdev
In-Reply-To: <201107012233.08489.sshtylyov@ru.mvista.com>
On Fri, Jul 01, 2011 at 10:33:08PM +0400, Sergei Shtylyov wrote:
> The SSB code reads PCI revision ID from the PCI configuration register while
> it's already stored by the PCI subsystem in the 'revision' field of 'struct
> pci_dev'...
>
> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Applied.
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 1/3 resend] ssb: PCI revision ID register is 8-bit wide
From: John W. Linville @ 2011-07-05 19:33 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: mb, netdev
In-Reply-To: <201107012235.28745.sshtylyov@ru.mvista.com>
On Fri, Jul 01, 2011 at 10:35:28PM +0400, Sergei Shtylyov wrote:
> The SSB code reads PCI revision ID register as 16-bit entity while the register
> is actually 8-bit only (the next 8 bits are the programming interface register).
> Fix the read and make the 'rev' field of 'struct ssb_boardinfo' 8-bit as well,
> to match the register size.
>
> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Applied.
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: libpcap and tc filters
From: jamal @ 2011-07-05 19:19 UTC (permalink / raw)
To: Adam Katz; +Cc: Eric Dumazet, netdev
In-Reply-To: <CAA0qwj6Wanp45ntTm0FK+fM37b_N8+T72VJfr9Et8oVb9LqOrg@mail.gmail.com>
On Tue, 2011-07-05 at 19:54 +0300, Adam Katz wrote:
>
> unless someone suggests a better solution, it seems like i'll be
> adhering to the first law of engineering - "if it works, don't fix it"
> and simply replace install fedora core 15 instead of ubuntu.
My feeling is it has nothing to do with distro. Probably
your tcpreplay?
I am running ubuntu 10.04, but own compiled kernel (3.0-rc4).
tcpreplay is older than Eric's version:
--
tcpreplay version: 3.4.3 (build 2375)
Copyright 2001-2009 by Aaron Turner <aturner at synfin dot net>
Cache file supported: 04
Not compiled with libdnet.
Compiled against libpcap: 1.0.0
64 bit packet counters: enabled
Verbose printing via tcpdump: enabled
Packet editing: disabled
Fragroute engine: disabled
Injection method: PF_PACKET send()
---
cheers,
jamal
^ permalink raw reply
* RE: [RFC] non-preemptible kernel socket for RAMster
From: Dan Magenheimer @ 2011-07-05 19:18 UTC (permalink / raw)
To: Loke, Chetan, netdev; +Cc: Konrad Wilk, linux-mm
In-Reply-To: <D3F292ADF945FB49B35E96C94C2061B91257D6FD@nsmail.netscout.com>
> From: Loke, Chetan [mailto:Chetan.Loke@netscout.com]
> > From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]
> > Subject: RE: [RFC] non-preemptible kernel socket for RAMster
> >
> > > From: Loke, Chetan [mailto:Chetan.Loke@netscout.com]
> > > Sent: Tuesday, July 05, 2011 10:37 AM
> > > To: Dan Magenheimer; netdev@vger.kernel.org
> > > Cc: Konrad Wilk; linux-mm
> > > Subject: RE: [RFC] non-preemptible kernel socket for RAMster
> > >
> > > > In working on a kernel project called RAMster* (where RAM on a
> > > > remote system may be used for clean page cache pages and for swap
> > > > pages), I found I have need for a kernel socket to be used when
> > >
> > > How is RAMster+swap different than NBD's (pending etc?)support for
> > > SWAP over NBD?
> >
> > I may be ignorant of details about NBD, but did some quick
> > research using google. If I understand correctly, swap over
> > NBD is still writing to a configured swap disk on the remote
>
> Hi - I thought NBD-server needs a backing store(a file).
> Now the file itself could reside on a RAM-drive or disk-drive etc.
> And so a remote NBD(disk or RAM) can be mounted locally as a swap
> device.
> The local client should still see it as a block device.
>
> I haven't used the RAM-drive feature myself but you may want to check if
> it
> works or even borrow that logic in your code.
Actually, RAMster is using a much more flexible type of
RAM-drive; it is built on top of Transcendent Memory
and on top of zcache (and thus on top of cleancache and
frontswap). A RAM-drive is fixed size so is not very suitable
for the flexibility required for RAMster. For example,
suppose you have two machines A and B. At one point in
time A is overcommitted and needs to swap and B is relatively
idle. Then later, B is overcommitted and needs to swap and
A is relatively idle. RAMster can handle this entirely
dynamically, a RAM-drive cannot.
> > machine. RAMster is swapping to *RAM* on the remote machine.
> > The idea is that most machines are very overprovisioned in
> > RAM, and are rarely using all of their RAM, especially when
> > a machine is (mostly) idle. In other words, the "max of
> > the sums" of RAM usage on a group of machines is much lower
> > than the "sum of the max" of RAM usage.
> >
> > So if the network is sufficiently faster than disk for
> > moving a page of data, RAMster provides a significant
> > performance improvement. OR RAMster may allow a significant
> > reduction in the total amount of RAM across a data center.
> >
> > The version of RAMster I am working on now is really
> > a proof-of-concept that works over sockets, using the
> > ocfs2 cluster layer. One can easily envision a future
> > "exo-fabric" which allows one machine to write to the
> > RAM of another machine... for this future hardware,
> > RAMster becomes much more interesting.
>
> Or you can also try scst-in-RAM mode(if you want to experiment with
> different fabrics).
Thanks. Could you provide a pointer for this? I found
the SCST sourceforge page but no obvious references to
scst-in-ram-mode. (But also, since it appears to be
SCSI-related, I wonder if it also assumes a fixed size
target device, RAM or disk or ??)
Dan
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* RE: [RFC] non-preemptible kernel socket for RAMster
From: Dan Magenheimer @ 2011-07-05 19:07 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Konrad Wilk, linux-mm
In-Reply-To: <1309890239.2545.10.camel@edumazet-laptop>
> > > > +++ linux-2.6.37-ramster/net/core/sock.c 2011-07-03 19:10:04.340980799 -0600
> > > > @@ -1587,6 +1587,14 @@ static void __lock_sock(struct sock *sk)
> > > > __acquires(&sk->sk_lock.slock)
> > > > {
> > > > DEFINE_WAIT(wait);
> > > > + if (!preemptible()) {
> > > > + while (sock_owned_by_user(sk)) {
> > > > + spin_unlock_bh(&sk->sk_lock.slock);
> > > > + cpu_relax();
> > > > + spin_lock_bh(&sk->sk_lock.slock);
> > > > + }
> > > > + return;
> > > > + }
> > >
> > > Hmm, was this tested on UP machine ?
> >
> > Hi Eric --
> >
> > Thanks for the reply!
> >
> > I hadn't tested UP in awhile so am testing now, and it seems to
> > work OK so far. However, I am just testing my socket, *not* testing
> > sockets in general. Are you implying that this patch will
> > break (kernel) sockets in general on a UP machine? If so,
> > could you be more specific as to why? (Again, I said
> > I am a networking idiot. ;-) I played a bit with adding
> > a new SOCK_ flag and triggering off of that, but this
> > version of the patch seemed much simpler.
>
> Say you have two processes and socket S
>
> One process locks socket S, and is preempted by another process.
>
> This second process is non preemptible and try to lock same socket.
>
> -> deadlock, since P1 never releases socket S
Oh, OK. My use model is that a socket that is used non-preemptible
must always be used non-preemptible. In other words, this kind
of socket is an extreme form of non-blocking. Doesn't that seem
like a reasonable constraint?
Thanks,
Dan
^ permalink raw reply
* Re: [PATCH net-next 6/6] r8169: support RTL8111E-VL
From: Francois Romieu @ 2011-07-05 18:56 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1309859095-32031-6-git-send-email-hayeswang@realtek.com>
Hayes Wang <hayeswang@realtek.com> :
[...]
> + rtl_writephy(tp, 0x1e, 0x002D);
^^ 2d :o)
Some rtl_eri_write probably deserve to be tabulated. It can wait though.
--
Ueimor
^ permalink raw reply
* Re: [PATCH net-next 5/6] r8169: fix wake on lan setting for 8111E
From: Francois Romieu @ 2011-07-05 18:55 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1309859095-32031-5-git-send-email-hayeswang@realtek.com>
Hayes Wang <hayeswang@realtek.com> :
> Only 8111E needs enable RxConfig bit 0 ~ 3 when suspending or
> shutdowning when supporting wake on lan.
Nit: if it only applies to the non-VL 8111E, it could make sense to apply
it after the 8168E-VL support patch and outline this fact in the comment.
Your call.
--
Ueimor
^ permalink raw reply
* Re: [PATCH net-next 4/6] r8169: add ERI functions
From: Francois Romieu @ 2011-07-05 18:55 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1309859095-32031-4-git-send-email-hayeswang@realtek.com>
Hayes Wang <hayeswang@realtek.com> :
[...]
> @@ -1046,6 +1046,49 @@ static u32 rtl_csi_read(void __iomem *ioaddr, int addr)
> return value;
> }
>
> +static
> +void rtl_eri_write(void __iomem *ioaddr, int addr, u32 mask, u32 val, int type)
> +{
> + unsigned int i;
> +
> + BUG_ON((addr & 3) || (mask == 0));
> + RTL_W32(ERIDR, val);
> + RTL_W32(ERIAR, ERIAR_WRITE_CMD | type | mask | addr);
> +
> + for (i = 0; i < 100; i++) {
> + udelay(100);
> + if (!(RTL_R32(ERIAR) & ERIAR_FLAG))
> + break;
I'd rather reverse those if possible : implicit posted write flushing read,
then udelay.
--
Ueimor
^ permalink raw reply
* Re: [PATCH net-next 3/6] r8169: adjust the settings about RxConfig
From: Francois Romieu @ 2011-07-05 18:55 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1309859095-32031-3-git-send-email-hayeswang@realtek.com>
Hayes Wang <hayeswang@realtek.com> :
[...]
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index cdbbe47..3aeae68 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -71,7 +71,7 @@ static const int multicast_filter_limit = 32;
>
> #define MAX_READ_REQUEST_SHIFT 12
> #define RX_FIFO_THRESH 7 /* 7 means NO threshold, Rx buffer level before first PCI xfer. */
> -#define RX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */
> +#define RX_DMA_BURST 7 /* Maximum PCI burst, '7' is Unlimited */
> #define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */
> #define SafeMtu 0x1c20 /* ... actually life sucks beyond ~7k */
> #define InterFrameGap 0x03 /* 3 means InterFrameGap = the shortest one */
> @@ -272,9 +272,6 @@ enum rtl_registers {
> IntrStatus = 0x3e,
> TxConfig = 0x40,
> RxConfig = 0x44,
> -
> -#define RTL_RX_CONFIG_MASK 0xff7e1880u
> -
Nit: could you remove RxCfgFIFOShift and add something like
#define RXCFG_FIFO_SHIFT 13
/* No threshold before first PCI xfer. */
#define RXCFG_FIFO_THRESH (7 << RXCFG_FIFO_SHIFT)
#define RXCFG_DMA_SHIFT 8
/* Unlimited maximum PCI burst. */
#define RXCFG_DMA_BURST (7 << RXCFG_DMA_SHIFT)
(and move both RX128_INT_EN and RX_MULTI_EN near RxConfig in patch #1)
--
Ueimor
^ permalink raw reply
* Re: [PATCH net-next 2/6] r8169: modify the flow hw reset
From: Francois Romieu @ 2011-07-05 18:55 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1309859095-32031-2-git-send-email-hayeswang@realtek.com>
Hayes Wang <hayeswang@realtek.com> :
> Replace rtl8169_asic_down with rtl8169_hw_reset. Clear RxConfig
> bit 0 ~ 3 and do some checking before reset. Remove hw reset
> which is before hw_start because reset would be done in close or
> down.
The whole description of the changes ought to explain why things are
changed.
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
> ---
> drivers/net/r8169.c | 43 ++++++++++++++++++++++++-------------------
> 1 files changed, 24 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index 701ab6b..cdbbe47 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -731,6 +731,8 @@ static int rtl8169_poll(struct napi_struct *napi, int budget);
> static const unsigned int rtl8169_rx_config =
> (RX_FIFO_THRESH << RxCfgFIFOShift) | (RX_DMA_BURST << RxCfgDMAShift);
>
> +static void rtl8169_init_ring_indexes(struct rtl8169_private *tp);
> +
rtl8169_init_ring_indexes is really short. Please move it before its first use
and avoid the forward declaration.
> static u32 ocp_read(struct rtl8169_private *tp, u8 mask, u16 reg)
> {
> void __iomem *ioaddr = tp->mmio_addr;
> @@ -1076,13 +1078,6 @@ static void rtl8169_irq_mask_and_ack(void __iomem *ioaddr)
> RTL_W16(IntrStatus, 0xffff);
> }
>
> -static void rtl8169_asic_down(void __iomem *ioaddr)
> -{
> - RTL_W8(ChipCmd, 0x00);
> - rtl8169_irq_mask_and_ack(ioaddr);
> - RTL_R16(CPlusCmd);
> -}
> -
> static unsigned int rtl8169_tbi_reset_pending(struct rtl8169_private *tp)
> {
> void __iomem *ioaddr = tp->mmio_addr;
> @@ -3352,10 +3347,12 @@ static void rtl_hw_reset(struct rtl8169_private *tp)
>
> /* Check that the chip has finished the reset. */
> for (i = 0; i < 100; i++) {
> + udelay(100);
> if ((RTL_R8(ChipCmd) & CmdReset) == 0)
> break;
Nit: is it forbidden to perform the read - and thus the implicit PCI flush -
before the first 100 us delay ?
> - msleep_interruptible(1);
> }
> +
> + rtl8169_init_ring_indexes(tp);
> }
>
> static int __devinit
> @@ -3737,6 +3734,16 @@ err_pm_runtime_put:
> goto out;
> }
>
> +static void rtl_rx_close(struct rtl8169_private *tp)
> +{
> + void __iomem *ioaddr = tp->mmio_addr;
> + u32 rxcfg = RTL_R32(RxConfig);
> +
> + rxcfg &= ~(AcceptBroadcast | AcceptMulticast |
> + AcceptMyPhys | AcceptAllPhys);
> + RTL_W32(RxConfig, rxcfg);
> +}
> +
Should not error and runt packets be considered too ?
<shot in the dark>
Is there any relationship with commit ca52efd5490f97f396d3c5863ba714624f272033 ?
</shot in the dark>
> static void rtl8169_hw_reset(struct rtl8169_private *tp)
> {
> void __iomem *ioaddr = tp->mmio_addr;
> @@ -3744,19 +3751,20 @@ static void rtl8169_hw_reset(struct rtl8169_private *tp)
> /* Disable interrupts */
> rtl8169_irq_mask_and_ack(ioaddr);
>
> + rtl_rx_close(tp);
> +
> if (tp->mac_version == RTL_GIGA_MAC_VER_27 ||
> tp->mac_version == RTL_GIGA_MAC_VER_28 ||
> tp->mac_version == RTL_GIGA_MAC_VER_31) {
> while (RTL_R8(TxPoll) & NPQ)
> udelay(20);
>
> + } else {
> + RTL_W8(ChipCmd, RTL_R8(ChipCmd) | StopReq);
> + udelay(100);
No posted PCI write flush ?
Please remove the empty line after the udelay(20). It should not
have been there in the first place.
> }
>
> - /* Reset the chipset */
> - RTL_W8(ChipCmd, CmdReset);
> -
> - /* PCI commit */
> - RTL_R8(ChipCmd);
> + rtl_hw_reset(tp);
> }
>
> static void rtl_set_rx_tx_config_registers(struct rtl8169_private *tp)
> @@ -3776,8 +3784,6 @@ static void rtl_hw_start(struct net_device *dev)
> {
> struct rtl8169_private *tp = netdev_priv(dev);
>
> - rtl_hw_reset(tp);
> -
> tp->hw_start(dev);
>
> netif_start_queue(dev);
> @@ -4718,7 +4724,6 @@ static void rtl8169_reset_task(struct work_struct *work)
>
> rtl8169_tx_clear(tp);
>
> - rtl8169_init_ring_indexes(tp);
> rtl_hw_start(dev);
> netif_wake_queue(dev);
> rtl8169_check_link_status(dev, tp, tp->mmio_addr);
I do not see where the ring indexes will be set when __rtl8169_resume()
schedules rtl8169_reset_task. It could hurt.
--
Ueimor
^ permalink raw reply
* Re: [PATCH net-next 1/6] r8169: adjust some registers
From: Francois Romieu @ 2011-07-05 18:53 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1309859095-32031-1-git-send-email-hayeswang@realtek.com>
Hayes Wang <hayeswang@realtek.com> :
> Define new registers and modify some existing ones.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
> ---
> drivers/net/r8169.c | 30 +++++++++++++++++++++++-------
> 1 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index fbd6838..701ab6b 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -327,7 +327,7 @@ enum rtl8168_8101_registers {
> #define EPHYAR_REG_SHIFT 16
> #define EPHYAR_DATA_MASK 0xffff
> DLLPR = 0xd0,
> -#define PM_SWITCH (1 << 6)
> +#define PFM_EN (1 << 6)
> DBG_REG = 0xd1,
> #define FIX_NAK_1 (1 << 4)
> #define FIX_NAK_2 (1 << 3)
> @@ -335,6 +335,7 @@ enum rtl8168_8101_registers {
> MCU = 0xd3,
> #define EN_NDP (1 << 3)
> #define EN_OOB_RESET (1 << 2)
> +#define NOW_IS_OOB (1 << 7)
^^^ there should be a tab, not a space.
Nit : 3, 2, 7 is a bit surprizing. 7, 3, 2 ?
@@ -345,18 +346,31 @@ enum rtl8168_8101_registers {
};
enum rtl8168_registers {
+ LED_FREQ = 0x1a,
+ EEE_LED = 0x1b,
+
+ /* TxConfig */
+#define AUTO_FIFO (1 << 7)
+#define TX_EMPTY (1 << 11)
Eventually move these close to the existing TxConfig register as :
+#define TXCFG_AUTO_FIFO (1 << 7) /* 8168e (?) */
+#define TXCFG_EMPTY (1 << 11) /* 8168e (?) */
--
Ueimor
^ permalink raw reply
* [BUG] bd4265fe36 bridge: Only flood unreg groups... breaks DHCP setup
From: Michael Guntsche @ 2011-07-05 18:43 UTC (permalink / raw)
To: xu; +Cc: netdev, David Miller
Hello,
After updating from 3.0.0-rc5 to rc6 I noticed that my cellphone was no
longer able to get an address assigned from my DHCP server. While trying
to figure out the problem I noticed that tracing with tcpdump made it
work again.
The setup I have here is the following:
PPC embedded board where the wired NIC and the wlan NIC are in a bridge.
Dnsmasq is listening on the Bridge device itself.
Looking at the changes between rc5 and rc6 I noticed commit
bd4265fe365c0f3945d: bridge: Only flood unregistered groups to routers
For testing purposes I reverted it and the cellphone immediately got an
address even without running tcpdump. Now apparently the commit states
that the user can always force flooding behaviour to any given port by
marking it as a router but I did not find any documentation how to do
that.
Now my question? Is it "normal" that this change breaks my setup here
and if it is expected how can I force my ports to the old behaviour
without reverting the commit.
Thank you very much in advance,
Michael
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-05 18:45 UTC (permalink / raw)
To: Neil Horman
Cc: Alexey Zaytsev, Michael Büsch, Andrew Morton, netdev,
Gary Zambrano, bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <1309890775.2545.17.camel@edumazet-laptop>
Le mardi 05 juillet 2011 à 20:32 +0200, Eric Dumazet a écrit :
> Then, maybe the driver model is completely wrong, and should really
> setup 512 buffers, or use less descs but set EOT on last one.
>
> Currently it uses a 200 sliding window out of the 512 descs.
>
>
One thing we could do would be to allocate a special guard buffer and
set all 'out of window' descriptors to point to this guard buffer, and
periodically check if buffer is dirtied by the card.
(first word would be enough)
(instead of setting desc->addr to NULL, set to
dma_map_single(guard_buffer))
^ permalink raw reply
* Fwd: usbnet suspend issue
From: Chris Fries @ 2011-07-05 18:43 UTC (permalink / raw)
To: netdev, stable, davem
In-Reply-To: <CADuEq9BkW8iHQjacohGJUZzwh--ZrqVEKYa4DzftH9XnMc=JNw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]
(Plain text)
Hi David, Netdev, Stable,
Please evaluate the attached usbnet patch for inclusion to the kernel.
Thanks,
Chris
On Tue, Jul 5, 2011 at 4:49 AM, Oliver Neukum <oliver@neukum.org> wrote:
>
> Am Dienstag, 5. Juli 2011, 04:25:39 schrieb Chris Fries:
> > Hi Oliver,
> >
> > I noticed a bug in usbnet suspend, that's been around for a while and seems
> > to be still present in 3.0. It causes some nasty behavior on ARM (Tegra)
> > when suspend/resume stops working due to a lost suspend count.
> > ...
>
> Thank you. That is a very good catch. Please resend to David Miller
> and netdev@vger.kernel.org and stable@kernel.org. Also please include
> your Signed-off-by: <mail> line. That way it'll be included fastest.
>
> Regards
> Oliver
[-- Attachment #2: usbnet-suspend.patch --]
[-- Type: application/octet-stream, Size: 1041 bytes --]
From 963360b955bae58963399124b4a542827f3272ea Mon Sep 17 00:00:00 2001
From: Chris Fries <C.Fries@motorola.com>
Date: Fri, 1 Jul 2011 15:28:58 -0500
Subject: [PATCH] usb: usbnet: suspend count gets lost when -EBUSY
When suspend is refused due to pending transmits, the
busy counter gets out of sync, and suspend will stop
working correctly.
Change-Id: I89d31d6584e8914192315671c8031a9c7658ca22
Signed-off-by: Chris Fries <C.Fries@motorola.com>
---
drivers/net/usb/usbnet.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index cc95aad..9bcc3e3 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1451,6 +1451,7 @@ int usbnet_suspend (struct usb_interface *intf, pm_message_t message)
/* don't autosuspend while transmitting */
if (dev->txq.qlen && (message.event & PM_EVENT_AUTO)) {
spin_unlock_irq(&dev->txq.lock);
+ dev->suspend_count--;
return -EBUSY;
} else {
set_bit(EVENT_DEV_ASLEEP, &dev->flags);
--
1.7.0.4
^ permalink raw reply related
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