* Re: Dscape ieee80211: enabling/disabling the radio
From: Jiri Benc @ 2006-05-10 14:10 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: netdev, Olivier
In-Reply-To: <200605101553.52031.IvDoorn@gmail.com>
On Wed, 10 May 2006 15:53:48 +0200, Ivo van Doorn wrote:
> I think the problem is what the dscape exactly expects the driver to do when
> add_interface() is called by the stack. When that call has finished, does the stack
> expects the radio to be enabled, or should it instruct the driver to enable the radio later
> on through a field in the config structure.
At least for now, enabled if this is the first interface going up. Of
course, if a second (or so) interface is added, you shouldn't reenable
radio if it was disabled by previous config() call.
> But this might be resolved by demanding that the driver is keeping track of the number
> of interfaces added, and enabling the radio when at least 1 interface has been added
> and only disable the radio when all interfaces have been removed. And completely
> remove the open() and stop() handlers since they would only confuse matters.
Yes, this is the way it is supposed to work.
> Ah ok, I'll fix rt2x00 then to do the correct behaviour and no longer rely on open() and stop()
> for the radio, and add the counter for the number of interfaces that are up so the radio
> will behave in the correct fashion. :)
Please see http://www.spinics.net/lists/netdev/msg03975.html (and
following thread probably as well) for a description how to implement
this correctly.
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* [PATCH] phy: mdiobus_register(): initialize all phy_map entries
From: Herbert Valerio Riedel @ 2006-05-10 16:12 UTC (permalink / raw)
To: netdev; +Cc: Andy Fleming
make sure phy_map entries whose PHY address is masked are initialized
to NULL, given that other code (such as mdiobus_unregister for
instance) assumes that non-NULL phy_map entries are allocated
phy_devices
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
---
drivers/net/phy/mdio_bus.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
Index: b/drivers/net/phy/mdio_bus.c
===================================================================
--- a/drivers/net/phy/mdio_bus.c 2006-05-10 17:02:12.000000000 +0200
+++ b/drivers/net/phy/mdio_bus.c 2006-05-10 17:05:27.000000000 +0200
@@ -60,8 +60,10 @@
for (i = 0; i < PHY_MAX_ADDR; i++) {
struct phy_device *phydev;
- if (bus->phy_mask & (1 << i))
+ if (bus->phy_mask & (1 << i)) {
+ bus->phy_map[i] = NULL;
continue;
+ }
phydev = get_phy_device(bus, i);
--
^ permalink raw reply
* Re: Dscape ieee80211: enabling/disabling the radio
From: Jouni Malinen @ 2006-05-10 17:03 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Jiri Benc, netdev, Olivier
In-Reply-To: <200605101553.52031.IvDoorn@gmail.com>
On Wed, May 10, 2006 at 03:53:48PM +0200, Ivo van Doorn wrote:
> I think the problem is what the dscape exactly expects the driver to do when
> add_interface() is called by the stack. When that call has finished, does the stack
> expects the radio to be enabled, or should it instruct the driver to enable the radio later
> on through a field in the config structure.
I think the current expectation is for the interface to be set into
enabled state at this point.
> What currently happens in rt2x00 (Which might not be doing what the stack expects)
> is that when add_interface() is called the radio remains off untill open() is called or
> radio_enabled has been set in the config structure.
We used radio_enabled (or well, the previously used name adm_status) as
a "soft disable", i.e., the radio hardware was mostly enabled, but no TX
or RX happened. This could, e.g., mean masking out interrupts and/or
disabling receive part of the radio.
This has been used to provide a mechanism for disabling the radio
without having to set the interface down, i.e., without causing IP
addresses to be dropped or bridging status changed.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* [PATCH 2/2] bridge: do sysfs registration inside rtnl
From: Stephen Hemminger @ 2006-05-10 17:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20060510171452.619146000@localhost.localdomain>
[-- Attachment #1: bridge-register.patch --]
[-- Type: text/plain, Size: 896 bytes --]
Now that netdevice sysfs registration is done as part of register_netdevice;
bridge code no longer has to be tricky when adding it's kobjects to bridges.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
--- bridge.orig/net/bridge/br_if.c 2006-05-04 16:22:29.000000000 -0700
+++ bridge/net/bridge/br_if.c 2006-05-09 11:27:16.000000000 -0700
@@ -308,26 +308,19 @@
if (ret)
goto err2;
- /* network device kobject is not setup until
- * after rtnl_unlock does it's hotplug magic.
- * so hold reference to avoid race.
- */
- dev_hold(dev);
- rtnl_unlock();
-
ret = br_sysfs_addbr(dev);
- dev_put(dev);
-
- if (ret)
- unregister_netdev(dev);
- out:
- return ret;
+ if (ret)
+ goto err3;
+ rtnl_unlock();
+ return 0;
+ err3:
+ unregister_netdev(dev);
err2:
free_netdev(dev);
err1:
rtnl_unlock();
- goto out;
+ return ret;
}
int br_del_bridge(const char *name)
--
^ permalink raw reply
* [PATCH 0/2] register_netdevice and sysfs changes
From: Stephen Hemminger @ 2006-05-10 17:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
This is a signed-off version of yesterday's fix, plus the bridge
code no longer needs to be so tricky.
--
^ permalink raw reply
* [PATCH 1/2] netdev: do sysfs registration as part of register_netdevice
From: Stephen Hemminger @ 2006-05-10 17:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20060510171452.619146000@localhost.localdomain>
[-- Attachment #1: dev-register-sleep.patch --]
[-- Type: text/plain, Size: 4223 bytes --]
The last step of netdevice registration was being done by a delayed
call, but because it was delayed, it was impossible to return any error
code if the class_device registration failed.
Side effects:
* one state in registration process is unnecessary.
* register_netdevice can sleep inside class_device registration/hotplug
* code in netdev_run_todo only does unregistration so it is simpler.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
--- bridge.orig/include/linux/netdevice.h 2006-05-09 11:17:08.000000000 -0700
+++ bridge/include/linux/netdevice.h 2006-05-09 11:18:52.000000000 -0700
@@ -433,8 +433,7 @@
/* register/unregister state machine */
enum { NETREG_UNINITIALIZED=0,
- NETREG_REGISTERING, /* called register_netdevice */
- NETREG_REGISTERED, /* completed register todo */
+ NETREG_REGISTERED, /* completed register_netdevice */
NETREG_UNREGISTERING, /* called unregister_netdevice */
NETREG_UNREGISTERED, /* completed unregister todo */
NETREG_RELEASED, /* called free_netdev */
--- bridge.orig/net/core/dev.c 2006-05-09 11:17:09.000000000 -0700
+++ bridge/net/core/dev.c 2006-05-09 11:37:18.000000000 -0700
@@ -2777,6 +2777,8 @@
BUG_ON(dev_boot_phase);
ASSERT_RTNL();
+ might_sleep();
+
/* When net_device's are persistent, this will be fatal. */
BUG_ON(dev->reg_state != NETREG_UNINITIALIZED);
@@ -2863,6 +2865,11 @@
if (!dev->rebuild_header)
dev->rebuild_header = default_rebuild_header;
+ ret = netdev_register_sysfs(dev);
+ if (ret)
+ goto out_err;
+ dev->reg_state = NETREG_REGISTERED;
+
/*
* Default initial state at registry is that the
* device is present.
@@ -2878,14 +2885,11 @@
hlist_add_head(&dev->name_hlist, head);
hlist_add_head(&dev->index_hlist, dev_index_hash(dev->ifindex));
dev_hold(dev);
- dev->reg_state = NETREG_REGISTERING;
write_unlock_bh(&dev_base_lock);
/* Notify protocols, that a new device appeared. */
blocking_notifier_call_chain(&netdev_chain, NETDEV_REGISTER, dev);
- /* Finish registration after unlock */
- net_set_todo(dev);
ret = 0;
out:
@@ -3008,7 +3012,7 @@
*
* We are invoked by rtnl_unlock() after it drops the semaphore.
* This allows us to deal with problems:
- * 1) We can create/delete sysfs objects which invoke hotplug
+ * 1) We can delete sysfs objects which invoke hotplug
* without deadlocking with linkwatch via keventd.
* 2) Since we run with the RTNL semaphore not held, we can sleep
* safely in order to wait for the netdev refcnt to drop to zero.
@@ -3017,8 +3021,6 @@
void netdev_run_todo(void)
{
struct list_head list = LIST_HEAD_INIT(list);
- int err;
-
/* Need to guard against multiple cpu's getting out of order. */
mutex_lock(&net_todo_run_mutex);
@@ -3041,40 +3043,29 @@
= list_entry(list.next, struct net_device, todo_list);
list_del(&dev->todo_list);
- switch(dev->reg_state) {
- case NETREG_REGISTERING:
- err = netdev_register_sysfs(dev);
- if (err)
- printk(KERN_ERR "%s: failed sysfs registration (%d)\n",
- dev->name, err);
- dev->reg_state = NETREG_REGISTERED;
- break;
-
- case NETREG_UNREGISTERING:
- netdev_unregister_sysfs(dev);
- dev->reg_state = NETREG_UNREGISTERED;
-
- netdev_wait_allrefs(dev);
-
- /* paranoia */
- BUG_ON(atomic_read(&dev->refcnt));
- BUG_TRAP(!dev->ip_ptr);
- BUG_TRAP(!dev->ip6_ptr);
- BUG_TRAP(!dev->dn_ptr);
-
-
- /* It must be the very last action,
- * after this 'dev' may point to freed up memory.
- */
- if (dev->destructor)
- dev->destructor(dev);
- break;
-
- default:
+ if (unlikely(dev->reg_state != NETREG_UNREGISTERING)) {
printk(KERN_ERR "network todo '%s' but state %d\n",
dev->name, dev->reg_state);
- break;
+ dump_stack();
+ continue;
}
+
+ netdev_unregister_sysfs(dev);
+ dev->reg_state = NETREG_UNREGISTERED;
+
+ netdev_wait_allrefs(dev);
+
+ /* paranoia */
+ BUG_ON(atomic_read(&dev->refcnt));
+ BUG_TRAP(!dev->ip_ptr);
+ BUG_TRAP(!dev->ip6_ptr);
+ BUG_TRAP(!dev->dn_ptr);
+
+ /* It must be the very last action,
+ * after this 'dev' may point to freed up memory.
+ */
+ if (dev->destructor)
+ dev->destructor(dev);
}
out:
--
^ permalink raw reply
* Re: [PATCH wireless-dev] d80211: Add support for user space clientMLME
From: Jouni Malinen @ 2006-05-10 17:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: Jiri Benc, John W. Linville, netdev, jkmaline
In-Reply-To: <1146745613.1137.28.camel@localhost>
On Thu, May 04, 2006 at 02:26:53PM +0200, Johannes Berg wrote:
> On Wed, 2006-05-03 at 09:44 -0700, Jouni Malinen wrote:
> > But there is.. I committed changes to the wpa_supplicant devel branch
> > for this yesterday. It seems to work fine with net/d80211 and bcm43xx
> > with this small patch to d80211 to allow the functionality to be moved
> > into user space.
>
> Cool, do you have a list of things that we need to support for it to
> work on a 'softmac' based driver (iow removing softmac in favour of
> this)?
This is still somewhat open, but at minimum, there needs to be a
mechanism for receiving and sending management frames from user space.
d80211 uses a "management netdev" for this currently (the same one that
was used before with hostapd for AP mode). In addition to that,
wpa_supplicant expect to be able to read list of support channels and TX
rates (get_hw_feature_data handler in driver wrapper) and to be able to
add and remove STA entries (e.g., for TX rate control and association
status validation in kernel code).
Currently, scanning is done simply by setting the channel with
SIOCSIWFREQ and listening for management frames. However, the goal is to
provide simple atomic operations that user space programs can request
the kernel code to do. This would cover not only scanning, but also some
other needs like IEEE 802.11k radio measurements. These operations could
be something like "stop transmit, move to channel 5, report received
management frames, record noise level, do this for 5 ms, return to
operational channel, enable transmit".
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [PATCH -mm] dl2k gcc 4.1 warning fix
From: Jon Mason @ 2006-05-10 17:54 UTC (permalink / raw)
To: Daniel Walker; +Cc: akpm, edward_peng, linux-kernel, netdev
In-Reply-To: <200605100255.k4A2tvqm031661@dwalker1.mvista.com>
On Tue, May 09, 2006 at 07:55:57PM -0700, Daniel Walker wrote:
> Fixes the following warning,
Please CC netdev on networking patches.
All the changed lines are over 80 chars. Please fix.
Thanks,
Jon
> drivers/net/dl2k.c: In function 'rio_free_tx':
> drivers/net/dl2k.c:768: warning: integer constant is too large for 'long' type
> drivers/net/dl2k.c: In function 'receive_packet':
> drivers/net/dl2k.c:896: warning: integer constant is too large for 'long' type
> drivers/net/dl2k.c:904: warning: integer constant is too large for 'long' type
> drivers/net/dl2k.c:916: warning: integer constant is too large for 'long' type
> drivers/net/dl2k.c: In function 'rio_close':
> drivers/net/dl2k.c:1803: warning: integer constant is too large for 'long' type
> drivers/net/dl2k.c:1813: warning: integer constant is too large for 'long' type
>
> Signed-Off-By: Daniel Walker <dwalker@mvista.com>
>
> Index: linux-2.6.16/drivers/net/dl2k.c
> ===================================================================
> --- linux-2.6.16.orig/drivers/net/dl2k.c
> +++ linux-2.6.16/drivers/net/dl2k.c
> @@ -765,7 +765,7 @@ rio_free_tx (struct net_device *dev, int
> break;
> skb = np->tx_skbuff[entry];
> pci_unmap_single (np->pdev,
> - np->tx_ring[entry].fraginfo & 0xffffffffffff,
> + np->tx_ring[entry].fraginfo & 0xffffffffffffULL,
> skb->len, PCI_DMA_TODEVICE);
> if (irq)
> dev_kfree_skb_irq (skb);
> @@ -893,7 +893,7 @@ receive_packet (struct net_device *dev)
> /* Small skbuffs for short packets */
> if (pkt_len > copy_thresh) {
> pci_unmap_single (np->pdev,
> - desc->fraginfo & 0xffffffffffff,
> + desc->fraginfo & 0xffffffffffffULL,
> np->rx_buf_sz,
> PCI_DMA_FROMDEVICE);
> skb_put (skb = np->rx_skbuff[entry], pkt_len);
> @@ -901,7 +901,7 @@ receive_packet (struct net_device *dev)
> } else if ((skb = dev_alloc_skb (pkt_len + 2)) != NULL) {
> pci_dma_sync_single_for_cpu(np->pdev,
> desc->fraginfo &
> - 0xffffffffffff,
> + 0xffffffffffffULL,
> np->rx_buf_sz,
> PCI_DMA_FROMDEVICE);
> skb->dev = dev;
> @@ -913,7 +913,7 @@ receive_packet (struct net_device *dev)
> skb_put (skb, pkt_len);
> pci_dma_sync_single_for_device(np->pdev,
> desc->fraginfo &
> - 0xffffffffffff,
> + 0xffffffffffffULL,
> np->rx_buf_sz,
> PCI_DMA_FROMDEVICE);
> }
> @@ -1800,7 +1800,7 @@ rio_close (struct net_device *dev)
> skb = np->rx_skbuff[i];
> if (skb) {
> pci_unmap_single(np->pdev,
> - np->rx_ring[i].fraginfo & 0xffffffffffff,
> + np->rx_ring[i].fraginfo & 0xffffffffffffULL,
> skb->len, PCI_DMA_FROMDEVICE);
> dev_kfree_skb (skb);
> np->rx_skbuff[i] = NULL;
> @@ -1810,7 +1810,7 @@ rio_close (struct net_device *dev)
> skb = np->tx_skbuff[i];
> if (skb) {
> pci_unmap_single(np->pdev,
> - np->tx_ring[i].fraginfo & 0xffffffffffff,
> + np->tx_ring[i].fraginfo & 0xffffffffffffULL,
> skb->len, PCI_DMA_TODEVICE);
> dev_kfree_skb (skb);
> np->tx_skbuff[i] = NULL;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH -mm] updated dl2k gcc 4.1 warning fix
From: Daniel Walker @ 2006-05-10 18:12 UTC (permalink / raw)
To: akpm; +Cc: edward_peng, netdev, linux-kernel
Fixes the following warning,
drivers/net/dl2k.c: In function 'rio_free_tx':
drivers/net/dl2k.c:768: warning: integer constant is too large for 'long' type
drivers/net/dl2k.c: In function 'receive_packet':
drivers/net/dl2k.c:896: warning: integer constant is too large for 'long' type
drivers/net/dl2k.c:904: warning: integer constant is too large for 'long' type
drivers/net/dl2k.c:916: warning: integer constant is too large for 'long' type
drivers/net/dl2k.c: In function 'rio_close':
drivers/net/dl2k.c:1803: warning: integer constant is too large for 'long' type
drivers/net/dl2k.c:1813: warning: integer constant is too large for 'long' type
Signed-Off-By: Daniel Walker <dwalker@mvista.com>
Index: linux-2.6.16/drivers/net/dl2k.c
===================================================================
--- linux-2.6.16.orig/drivers/net/dl2k.c
+++ linux-2.6.16/drivers/net/dl2k.c
@@ -765,7 +765,8 @@ rio_free_tx (struct net_device *dev, int
break;
skb = np->tx_skbuff[entry];
pci_unmap_single (np->pdev,
- np->tx_ring[entry].fraginfo & 0xffffffffffff,
+ np->tx_ring[entry].fraginfo &
+ 0xffffffffffffULL,
skb->len, PCI_DMA_TODEVICE);
if (irq)
dev_kfree_skb_irq (skb);
@@ -893,7 +894,8 @@ receive_packet (struct net_device *dev)
/* Small skbuffs for short packets */
if (pkt_len > copy_thresh) {
pci_unmap_single (np->pdev,
- desc->fraginfo & 0xffffffffffff,
+ desc->fraginfo &
+ 0xffffffffffffULL,
np->rx_buf_sz,
PCI_DMA_FROMDEVICE);
skb_put (skb = np->rx_skbuff[entry], pkt_len);
@@ -901,7 +903,7 @@ receive_packet (struct net_device *dev)
} else if ((skb = dev_alloc_skb (pkt_len + 2)) != NULL) {
pci_dma_sync_single_for_cpu(np->pdev,
desc->fraginfo &
- 0xffffffffffff,
+ 0xffffffffffffULL,
np->rx_buf_sz,
PCI_DMA_FROMDEVICE);
skb->dev = dev;
@@ -912,8 +914,8 @@ receive_packet (struct net_device *dev)
pkt_len, 0);
skb_put (skb, pkt_len);
pci_dma_sync_single_for_device(np->pdev,
- desc->fraginfo &
- 0xffffffffffff,
+ desc->fraginfo &
+ 0xffffffffffffULL,
np->rx_buf_sz,
PCI_DMA_FROMDEVICE);
}
@@ -1800,7 +1802,8 @@ rio_close (struct net_device *dev)
skb = np->rx_skbuff[i];
if (skb) {
pci_unmap_single(np->pdev,
- np->rx_ring[i].fraginfo & 0xffffffffffff,
+ np->rx_ring[i].fraginfo &
+ 0xffffffffffffULL,
skb->len, PCI_DMA_FROMDEVICE);
dev_kfree_skb (skb);
np->rx_skbuff[i] = NULL;
@@ -1810,7 +1813,8 @@ rio_close (struct net_device *dev)
skb = np->tx_skbuff[i];
if (skb) {
pci_unmap_single(np->pdev,
- np->tx_ring[i].fraginfo & 0xffffffffffff,
+ np->tx_ring[i].fraginfo &
+ 0xffffffffffffULL,
skb->len, PCI_DMA_TODEVICE);
dev_kfree_skb (skb);
np->tx_skbuff[i] = NULL;
^ permalink raw reply
* Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
From: Andi Kleen @ 2006-05-10 18:28 UTC (permalink / raw)
To: Roland Dreier
Cc: xen-devel, Ian Pratt, netdev, linux-kernel, Chris Wright,
virtualization, Stephen Hemminger
In-Reply-To: <ada1wv3apu0.fsf@cisco.com>
On Tuesday 09 May 2006 22:46, Roland Dreier wrote:
> Keir> Where should we get our entropy from in a VM environment?
> Keir> Leaving the pool empty can cause processes to hang.
>
> You could have something like a virtual HW RNG driver (with a frontend
> and backend), which steals from the dom0 /dev/random pool.
They already have a vTPM - iirc TPMs support random numbers so
that could be used. But it's probably complicated to use.
But if sampling virtual events for randomness is really unsafe (is it
really?) then native guests in Xen would also get bad random numbers
and this would need to be somehow addressed.
I haven't seen real evidence yet why the virtual events should
provide less randomness than the hardware.
-And
^ permalink raw reply
* possible problem with TSO and ip_queue
From: Chris Caputo @ 2006-05-10 18:44 UTC (permalink / raw)
To: netdev, netfilter-devel; +Cc: Paul Jakma
Environment is 2.6.16.9 with e1000 NICs.
Paul and I (as part of the Quagga project) are working on a user mode
method for doing BGP MD5 checksums using ip_queue. All is working except
when TSO is enabled I am seeing some problems.
It appears that when TSO is enabled, ip_queue can be used to manipulate
packets that have a size higher than the particular MSS (and MTU) for a
TCP stream.
This results in a larger than MSS packet going out to the NIC with a TCP
MD5 checksum, getting split by the NIC to match the MTU of the LAN, and
then being received as multiple packets with incorrect MD5 checksums.
Then a retransmit with a smaller/correct MSS happens and the packets are
received with valid MD5 checksums.
So in effect, the data eventually makes it across the link, but it is sent
twice, once with invalid checksums and once with valid checksums, and
throughput is slow.
When TSO is disabled, things happen as they should.
Does this sound like a bug or by design?
Does it make sense that ip_queue mangled packets be subjected to TSO,
given that the TCP header can be messed with by the user mode code?
Chris
^ permalink raw reply
* [PATCH] dl2k: use explicit DMA_48BIT_MASK
From: Francois Romieu @ 2006-05-10 18:57 UTC (permalink / raw)
To: Daniel Walker; +Cc: akpm, edward_peng, netdev, linux-kernel
In-Reply-To: <200605101812.k4AICpRo006555@dwalker1.mvista.com>
Typo will be harder with this one.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
---
drivers/net/dl2k.c | 13 ++++++-------
include/linux/dma-mapping.h | 1 +
2 files changed, 7 insertions(+), 7 deletions(-)
5019a27a2a4e259f29a7bd03e905764eedfa034c
diff --git a/drivers/net/dl2k.c b/drivers/net/dl2k.c
index ca73f07..18d67cf 100644
--- a/drivers/net/dl2k.c
+++ b/drivers/net/dl2k.c
@@ -765,8 +765,7 @@ rio_free_tx (struct net_device *dev, int
break;
skb = np->tx_skbuff[entry];
pci_unmap_single (np->pdev,
- np->tx_ring[entry].fraginfo &
- 0xffffffffffffULL,
+ np->tx_ring[entry].fraginfo & DMA_48BIT_MASK,
skb->len, PCI_DMA_TODEVICE);
if (irq)
dev_kfree_skb_irq (skb);
@@ -895,7 +894,7 @@ receive_packet (struct net_device *dev)
if (pkt_len > copy_thresh) {
pci_unmap_single (np->pdev,
desc->fraginfo &
- 0xffffffffffffULL,
+ DMA_48BIT_MASK,
np->rx_buf_sz,
PCI_DMA_FROMDEVICE);
skb_put (skb = np->rx_skbuff[entry], pkt_len);
@@ -903,7 +902,7 @@ receive_packet (struct net_device *dev)
} else if ((skb = dev_alloc_skb (pkt_len + 2)) != NULL) {
pci_dma_sync_single_for_cpu(np->pdev,
desc->fraginfo &
- 0xffffffffffffULL,
+ DMA_48BIT_MASK,
np->rx_buf_sz,
PCI_DMA_FROMDEVICE);
skb->dev = dev;
@@ -915,7 +914,7 @@ receive_packet (struct net_device *dev)
skb_put (skb, pkt_len);
pci_dma_sync_single_for_device(np->pdev,
desc->fraginfo &
- 0xffffffffffffULL,
+ DMA_48BIT_MASK,
np->rx_buf_sz,
PCI_DMA_FROMDEVICE);
}
@@ -1803,7 +1802,7 @@ rio_close (struct net_device *dev)
if (skb) {
pci_unmap_single(np->pdev,
np->rx_ring[i].fraginfo &
- 0xffffffffffffULL,
+ DMA_48BIT_MASK,
skb->len, PCI_DMA_FROMDEVICE);
dev_kfree_skb (skb);
np->rx_skbuff[i] = NULL;
@@ -1814,7 +1813,7 @@ rio_close (struct net_device *dev)
if (skb) {
pci_unmap_single(np->pdev,
np->tx_ring[i].fraginfo &
- 0xffffffffffffULL,
+ DMA_48BIT_MASK,
skb->len, PCI_DMA_TODEVICE);
dev_kfree_skb (skb);
np->tx_skbuff[i] = NULL;
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index ff61817..635690c 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -14,6 +14,7 @@ enum dma_data_direction {
};
#define DMA_64BIT_MASK 0xffffffffffffffffULL
+#define DMA_48BIT_MASK 0x0000ffffffffffffULL
#define DMA_40BIT_MASK 0x000000ffffffffffULL
#define DMA_39BIT_MASK 0x0000007fffffffffULL
#define DMA_32BIT_MASK 0x00000000ffffffffULL
--
1.3.1
^ permalink raw reply related
* address pingable with interface down
From: Jon DeVree @ 2006-05-10 19:48 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]
I've noticed in the past that the address owned by an interface is still
pingable after that interface is brought down. This appears to be
because the routing table entry for the address itself is never removed
when the interface is brought down. I'm curious if this is desired
behavior or if this is a bug. I've managed to patch my kernel to remove
the leftover entry and it doesn't seem to have any ill effects but I
haven't tried any of the more advanced routing setups with it this way.
Attached is one possible patch. Its a simple one, not the best one
because like I said, I don't know if this was the desired behavior or
not. If this is the desired behavior I'm curious why.
Steps to reproduce:
# ip route show table 0 dev eth0
# ifconfig eth0 1.2.3.4
# ip route show table 0 dev eth0
1.0.0.0/8 proto kernel scope link src 1.2.3.4
broadcast 1.0.0.0 table local proto kernel scope link src 1.2.3.4
local 1.2.3.4 table local proto kernel scope host src 1.2.3.4
broadcast 1.255.255.255 table local proto kernel scope link src 1.2.3.4
# ifconfig eth0 down
# ip route show table 0 dev eth0
local 1.2.3.4 table local proto kernel scope host src 1.2.3.4
# ping -c 1 1.2.3.4
PING 1.2.3.4 (1.2.3.4) 56(84) bytes of data.
64 bytes from 1.2.3.4: icmp_seq=1 ttl=64 time=0.104 ms
--- 1.2.3.4 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.104/0.104/0.104/0.000 ms
I asked on LKML about this when I first noticed it but didn't get an
answer, so I figured I'd try the more specific mailing list.
--
Jon
X(7x): A program for managing terminals. See also screen(1).
[-- Attachment #2: fib_disable_ip.diff --]
[-- Type: text/plain, Size: 348 bytes --]
--- linux-2.6.13.2-clean/net/ipv4/fib_frontend.c 2006-05-10 15:36:14.000000000 -0400
+++ linux-2.6.13.2/net/ipv4/fib_frontend.c 2006-05-10 15:36:25.000000000 -0400
@@ -629,7 +629,7 @@
rt_cache_flush(-1);
break;
case NETDEV_DOWN:
- fib_disable_ip(dev, 0);
+ fib_disable_ip(dev, 1);
break;
case NETDEV_CHANGEMTU:
case NETDEV_CHANGE:
^ permalink raw reply
* Re: possible problem with TSO and ip_queue
From: David S. Miller @ 2006-05-10 19:49 UTC (permalink / raw)
To: ccaputo; +Cc: netdev, netfilter-devel, paul
In-Reply-To: <Pine.LNX.4.64.0605101815430.16614@nacho.alt.net>
From: Chris Caputo <ccaputo@alt.net>
Date: Wed, 10 May 2006 18:44:30 +0000 (GMT)
> Does this sound like a bug or by design?
>
> Does it make sense that ip_queue mangled packets be subjected to TSO,
> given that the TCP header can be messed with by the user mode code?
This is by design. Netfilter looks at full TSO frames, but the
TSO hardware in the cards do not interpret the TCP options in any
way whatsoever when splitting the TSO packet up into MSS frames,
they just copy the options as-is into each sub-frame.
Once you add MD5 checksums to the TCP packet, TSO can no longer be
used on that path, so you'll have to disable TSO either in the route
or via some other means.
^ permalink raw reply
* Re: Initial benchmarks of some VJ ideas [mmap memcpy vs copy_to_user].
From: David S. Miller @ 2006-05-10 19:58 UTC (permalink / raw)
To: johnpol; +Cc: netdev, caitlinb, kelly, rusty
In-Reply-To: <20060508122418.GA22554@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Mon, 8 May 2006 16:24:22 +0400
> I hope he does not take offence at name shortening :)
Perhaps you are still not convinced how truly expensive the code path
from netif_receive_skb() to the protocol receive processing really is.
Van's channels eliminate that entire code path, and all it's data
structure references and locks, completely. And by foregoing all of
those data references and expensive locks, we free up precious cpu
cache space and cpu cycles for other work.
Because you cannot "simulate" the extra cache lines that are available
by eliminating the code path between netif_receive_skb() and udp_rcv()
you will really need to compare with a full implementation of channels
to say anything for certain.
And we've known that getting rid of this code path is necessary for
_AGES_. Ask anyone who has been to any of the yearly Linux networking
conferences, over and over again we talk about a grand unified flow
cache that would turn all of the routing, netfilter, and socket lookups
into one lookup.
All of these lookups touch different data structures, have different
locking rules, and have very poor cache behavior.
Van gets the transformation into a single lookup as a side effect of
how his channels work.
It is absolutely necessary to find ways to get rid of these layering
costs. "Layering is how you design networking protocols, not how you
implement them."
^ permalink raw reply
* Re: address pingable with interface down
From: David S. Miller @ 2006-05-10 20:00 UTC (permalink / raw)
To: jadevree; +Cc: netdev
In-Reply-To: <20060510194818.GB4460@junkers.homelinux.net>
From: Jon DeVree <jadevree@mtu.edu>
Date: Wed, 10 May 2006 15:48:18 -0400
> I've noticed in the past that the address owned by an interface is
> still pingable after that interface is brought down.
People bring this up all the time and this behavior is
intentional.
Linux uses a "host based" addressing model, IP addresses are owned by
the host, not individual interfaces. So as long as the IP address is
configured to some interface, we will accept packets destinated to
that IP address as our's.
This is becoming a serious FAQ and very tiresome to explain over and
over again.
^ permalink raw reply
* Re: possible problem with TSO and ip_queue
From: Paul Jakma @ 2006-05-10 20:07 UTC (permalink / raw)
To: David S. Miller; +Cc: ccaputo, netdev, netfilter-devel
In-Reply-To: <20060510.124955.114056211.davem@davemloft.net>
On Wed, 10 May 2006, David S. Miller wrote:
> This is by design. Netfilter looks at full TSO frames,
That explains it.
> Once you add MD5 checksums to the TCP packet, TSO can no longer be
> used on that path, so you'll have to disable TSO either in the
> route or via some other means.
Ok.
Is there a better way to deal with TSO besides documenting:
"disable TSO on all interfaces which /ever/ potentially could be used
to reach TCP-MD5 authenticated BGP peers."
?
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Nothing ever becomes real until it is experienced.
- John Keats
^ permalink raw reply
* Re: possible problem with TSO and ip_queue
From: David S. Miller @ 2006-05-10 20:09 UTC (permalink / raw)
To: paul; +Cc: ccaputo, netdev, netfilter-devel
In-Reply-To: <Pine.LNX.4.64.0605102105290.3813@sheen.jakma.org>
From: Paul Jakma <paul@clubi.ie>
Date: Wed, 10 May 2006 21:07:31 +0100 (IST)
> Is there a better way to deal with TSO besides documenting:
>
> "disable TSO on all interfaces which /ever/ potentially could be used
> to reach TCP-MD5 authenticated BGP peers."
>
> ?
When you have a rule installed that will add MD5, just mark
the route as not being TSO capable.
What's the problem?
^ permalink raw reply
* Re: possible problem with TSO and ip_queue
From: Paul Jakma @ 2006-05-10 20:17 UTC (permalink / raw)
To: David S. Miller; +Cc: ccaputo, netdev, netfilter-devel
In-Reply-To: <20060510.130919.37497120.davem@davemloft.net>
On Wed, 10 May 2006, David S. Miller wrote:
> When you have a rule installed that will add MD5, just mark the
> route as not being TSO capable.
Ah, didn't realise this could be done with netfilter. What's the
magic incantation? :)
> What's the problem?
None, that's perfect - we just didn't know!
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
You will be run over by a beer truck.
^ permalink raw reply
* [PATCH] tcpdump may trace some outbound packets twice.
From: Ranjit Manomohan @ 2006-05-10 20:17 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
This patch fixes the problem where tcpdump shows duplicate packets
while tracing outbound packets on drivers which support lockless
transmit. The patch changes the current behaviour to tracing the
packets only on a successful transmit.
Signed-off-by: Ranjit Manomohan <ranjitm@google.com>
--- linux-2.6/net/sched/sch_generic.c 2006-05-10 12:34:52.000000000 -0700
+++ linux/net/sched/sch_generic.c 2006-05-10 12:39:38.000000000 -0700
@@ -136,8 +136,12 @@
if (!netif_queue_stopped(dev)) {
int ret;
+ struct sk_buff *skbc = NULL;
+ /* Clone the skb so that we hold a reference
+ * to its data and we can trace it after a
+ * successful transmit. */
if (netdev_nit)
- dev_queue_xmit_nit(skb, dev);
+ skbc = skb_clone(skb, GFP_ATOMIC);
ret = dev->hard_start_xmit(skb, dev);
if (ret == NETDEV_TX_OK) {
@@ -145,6 +149,15 @@
dev->xmit_lock_owner = -1;
spin_unlock(&dev->xmit_lock);
}
+ if(skbc) {
+ /* transmit succeeded,
+ * trace the clone. */
+ dev_queue_xmit_nit(skbc,dev);
+ kfree_skb(skbc);
+ }
+ /* Free clone if it exists */
+ if(skbc)
+ kfree_skb(skbc);
spin_lock(&dev->queue_lock);
return -1;
}
^ permalink raw reply
* Re: [PATCH] sis900 Foxconn 661FX7MI-S PHY support
From: Daniele Venzano @ 2006-05-10 20:17 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: James Cameron, netdev
In-Reply-To: <20060510103109.148197cd@localhost.localdomain>
Il giorno 10/mag/06, alle ore 19:31, Stephen Hemminger ha scritto:
> On Wed, 10 May 2006 10:04:50 +1000 James Cameron
> <james.cameron@hp.com> wrote:
>>
>> I'm not sure, but I wonder if it means the default behaviour
>> should be
>> changed, so as to better handle future transceivers.
Well, my previous experience showed that the current default was the
best, but obviously, when I decided that, things began to change.
Since it is quite easy to add new transceivers this is hardly a big
problem.
> I am waiting for a fixed patch and ack from driver maintainer.
Ack. :-)
Thanks.
--
Daniele Venzano
http://www.brownhat.org
^ permalink raw reply
* Re: [PATCH 0/2] register_netdevice and sysfs changes
From: David S. Miller @ 2006-05-10 20:19 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20060510171452.619146000@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Wed, 10 May 2006 10:14:52 -0700
> This is a signed-off version of yesterday's fix, plus the bridge
> code no longer needs to be so tricky.
I'll apply this stuff, thanks a lot.
Although since I have the blocking --> raw notifier fixup in
my tree I'll need to fixup the rejects in the net/core/dev.c
part of the first patch.
Thanks.
^ permalink raw reply
* Re: [PATCH] skb leakage in inet6_csk_xmit
From: David S. Miller @ 2006-05-10 20:24 UTC (permalink / raw)
To: kuznet; +Cc: netdev
In-Reply-To: <20060510090216.GA1968@ms2.inr.ac.ru>
From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Date: Wed, 10 May 2006 13:02:16 +0400
> inet6_csk_xit does not free skb when routing fails.
>
> Signed-off-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Applied, thanks a lot.
^ permalink raw reply
* Re: possible problem with TSO and ip_queue
From: David S. Miller @ 2006-05-10 20:30 UTC (permalink / raw)
To: paul; +Cc: ccaputo, netdev, netfilter-devel
In-Reply-To: <Pine.LNX.4.64.0605102116390.3813@sheen.jakma.org>
From: Paul Jakma <paul@clubi.ie>
Date: Wed, 10 May 2006 21:17:33 +0100 (IST)
> On Wed, 10 May 2006, David S. Miller wrote:
>
> > When you have a rule installed that will add MD5, just mark the
> > route as not being TSO capable.
>
> Ah, didn't realise this could be done with netfilter. What's the
> magic incantation? :)
Unfortunately, you can't disable this per-route like I thought
was possible, you can only disable it per-device or per-socket.
^ permalink raw reply
* Re: address pingable with interface down
From: Jason Lunz @ 2006-05-10 20:47 UTC (permalink / raw)
To: netdev
In-Reply-To: <20060510.130012.128043400.davem@davemloft.net>
davem@davemloft.net said:
> This is becoming a serious FAQ and very tiresome to explain over and
> over again.
So where's the linux networking faq? I've been lurking here long enough
to know that there's no shortage of faqs, but there's no canonical
netdev faq that i'm aware of. Maybe one should be started?
Jason
^ 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