hello everyone, after loading of via-rhine module I see: MMIO do not match PIO [06] (ff != 00) via-rhine: probe of 0000:02:08.0 failed with error -5 MMIO do not match PIO [06] (ff != 00) via-rhine: probe of 0000:02:09.0 failed with error -5 MMIO do not match PIO [06] (ff != 6c) via-rhine: probe of 0000:02:0a.0 failed with error -5 And only one port is functional. So I tried to disable MMIO & PIO check in via-rhine.c : /* while (mmio_verify_registers[i]) { int reg ...

In attached patch I have rewrote MAC address generation to simple call to random_ether_addr instead of some mysterious pointer parsing :) Paulius

Hi Matthew, I'd prefer the keep it as just 'hso' and change the textual description if necessary. I think module names are just arbitrary, and should not necessarily reflect the original usage too well, otherwise you end up with a situation like with the 'option' module. That module is now used for many devices from differing manufacturers and it doesn't really make much sense to load the option module to service a device from Novatel, Sierra Wireless or Huawei. Just my two pence, Andr...

This patch set includes a number fixes/cleanups to TIPC's socket code. The first 6 are fairly trivial, while the last one does a complete overhaul of the locking TIPC uses to make it more Linux-like. Please see each individual patch for a further description. Summary: include/net/tipc/tipc_port.h | 6 net/tipc/port.c | 31 + net/tipc/socket.c | 1113 ++++++++++++++++++++++++------------------ 3 files changed, 667 insertions(+), 483 deletions(-) Allan Stephens...

This patch causes TIPC to return an error indication if the non- blocking form of connect() is requested (which TIPC does not yet support). Signed-off-by: Allan Stephens <allan.stephens@windriver.com> --- net/tipc/socket.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/net/tipc/socket.c b/net/tipc/socket.c index 4c83aba..348e4ff 100644 --- a/net/tipc/socket.c +++ b/net/tipc/socket.c @@ -1260,6 +1260,11 @@ static int connect(struct socket *sock, struct socka...

This patch modifies TIPC's socket code to follow the same approach used by other protocols. This change eliminates the need for a mutex in the TIPC-specific portion of the socket protocol data structure -- in its place, the standard Linux socket backlog queue and associated locking routines are utilized. These changes fix a long-standing receive queue bug on SMP systems, and also enable individual read and write threads to utilize a socket without unnecessarily interfering with each other. Signe...

This patch optimizes the receive path for SOCK_DGRAM and SOCK_RDM messages by skipping over code that handles connection-based flow control. Signed-off-by: Allan Stephens <allan.stephens@windriver.com> --- net/tipc/socket.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/net/tipc/socket.c b/net/tipc/socket.c index ca6f52f..91aa2dc 100644 --- a/net/tipc/socket.c +++ b/net/tipc/socket.c @@ -919,7 +919,8 @@ restart: /* Consume received message (optional) */ ...

I can reproduce semi-reliably (by kernel standards) corruption in kmalloc-2048. No idea if this can explain all "struct file" related oopses I saw, or SLUB free pointer corruption Pekka and Christoph are looking into. 8139too and atl1 drivers are in use. 8139too connects to outer world, atl1 -- to laptop collecting netconsole logs. However, I never managed to collect late oopses with netconsole even if init scripts which are shutting down interfaces are disabled. :-( Transcribed from photo: ...

Even kernel 2.2.26 (sic) already contains the #undef CONFIG_IRLAN_SEND_GRATUITOUS_ARP with the comment "but for some reason the machine crashes if you use DHCP". Either someone finally looks into this or it's simply time to remove this dead code. Reported-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Adrian Bunk <bunk@kernel.org> --- This patch has been sent on: - 31 Mar 2008 - 1 Mar 2008 include/net/irda/irlan_eth.h | 1 - net/irda/irlan/irlan_common....

Robert P. J. Day spotted that my removal of the Sangoma drivers missed a few bits. Signed-off-by: Adrian Bunk <bunk@kernel.org> --- This patch has been sent on: - 31 Mar 2008 - 25 Feb 2008 Documentation/networking/00-INDEX | 2 Documentation/networking/wan-router.txt | 621 ------------------------ include/linux/Kbuild | 1 include/linux/if_wanpipe.h | 124 ---- 4 files changed, 748 deletions(-) b448ba4228b3dfaacfa7e043e3aa23579d0...

On Mon, 14 Apr 2008 11:01:16 -0700 rtl8169_rx_skb is defined as netif_receive_skb only if NAPI is enabled. But the backtrace has CONFIG_R8169_NAPI disabled. I also concerned that the reset_task calls rx_interrupt with different locking than normal interrupt. --

On Mon, 14 Apr 2008 11:24:04 -0700 The receive path for NAPI would be: netif_receive_skb rtl8169_rx_interrupt rtl8169_napi *** But we are both wrong *** This is not the mainline r8169 driver but more likely the out of tree vendor 8168 driver. There is no rtl8168_rx_interrupt in mainline. --

The lower limit of 80 descriptors in the ring is only valid for one older 8254x chipset. All e1000e devices can use as low as 64 descriptors. Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com> --- drivers/net/e1000e/e1000.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h index f6835c3..38bfd0d 100644 --- a/drivers/net/e1000e/e1000.h +++ b/drivers/net/e1000e/e1000.h @@ -64,11 +64,11 @@ struct e1000_info...

Fix TSO over VLAN's by propagating settings to our VLAN devices. Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com> --- drivers/net/e1000e/ethtool.c | 16 ++++++++++++++++ drivers/net/e1000e/netdev.c | 8 ++++++++ 2 files changed, 24 insertions(+), 0 deletions(-) diff --git a/drivers/net/e1000e/ethtool.c b/drivers/net/e1000e/ethtool.c index ce045ac..23e9703 100644 --- a/drivers/net/e1000e/ethtool.c +++ b/drivers/net/e1000e/ethtool.c @@ -32,6 +32,7 @@ #include <linux/ethtool...

The ethtool -c / -C interface can now be used to modify the irq moderation algorithm. This change does not require an adapter reset and can thus be used at all times. The adapter only supports changing/reading rx-usecs which has special values for 0, 1 and 3: 0 - no irq moderation whatsoever 1 - normal moderation favoring regular mixed traffic (default) 3 - best attempt at low latency possible at cost of CPU For values between 10 and 10000 the rx-usecs defines "the minimum time between successi...

That would be fine with me -- that's one of the goals of ethtool: make the setting of hardware-specific settings as generic and easy as possible. Jeff --

I think this would require new ethtool interfaces (NIC_POLICY ?) so that the driver can decide what the right settings are. Otherwise you would need to hard code a conversion table into the user program, which is probably a bad idea. -Andi --

Suppose a program creates a socket and doesn't bind it to a local address. When the program wants to connect the socket to a remote address (for TCP) or send a datagram to a remote address (for UDP or raw IP), the kernel automatically assigns a local address to it. Questions: 1. What algorithm does the kernel use to select the local address? 2. Where is the source code for the selection? 3. Is this information documented anywhere? Thank you, Alan Stern --

Hi, - The IPv6 handler for receiving packets is ipv6_rcv() in net/ipv6/ip6_input.c. It is called by netif_receive_skb() (net/core/dev.c) According to the documentation, the return value of netif_receive_skb() should be NET_RX_DROP when the packet is dropped; though this return value is usually not used (except maybe for congestion), this patch fixes the ipv6_rcv() to return NET_RX_DROP when the packet is dropped (note that NET_RX_DROP value **is not** 0 but 1; NET_RX_SUCCESS value is in fact 0). ...

When CONFIG_SECURITY_NETWORK_XFRM is undefined the following warnings appears: net/xfrm/xfrm_user.c: In function 'xfrm_add_pol_expire': net/xfrm/xfrm_user.c:1576: warning: 'ctx' may be used uninitialized in this function net/xfrm/xfrm_user.c: In function 'xfrm_get_policy': net/xfrm/xfrm_user.c:1340: warning: 'ctx' may be used uninitialized in this function (security_xfrm_policy_alloc is noop for the case). It seems that they are result of the commit 03e1ad7b5d871d4189b1da3125c2f12d1b5f7d0b Signe...

Thanks for catching this, I was focusing more on the runtime issues with the else statement and forgot about compile time issues. I wonder if it would be better to fix this in the dummy function for security_xfrm_policy_alloc()? It seems cleaner to me. -- paul moore linux @ hp --

Actually it's a generic problem. It also occurs on OLPC, where the libertas wireless device presents two interfaces with the same MAC address -- the 'eth%d' interface for normal 802.11 wireless, and the 'msh%d' interface for mesh. This approach fixes that too. Our previous fix for that was 'TEST=="anycast_mask"' and 'TEST=="lbs_rtap"', which are horridly device-specific hacks. It isn't _broken_ to have more than one device on the same host with the same MAC address; it's just unusual. One thin...

I wouldn't put it like that. We are looking for some way to tell the difference between the two interfaces. If the kernel uses a different basename (wlan%d vs. eth%d, or eth%d vs. msh%d), that's a fairly strong hint about which is which -- and is fairly reliable to boot. The dev_id provides _another_ strong hint which helps us tell which The low 64 bits of the autoconfigured IPv6 address are derived from the MAC address, so for example a MAC address of 00:50:43:28:0A:FC would give you an IPv6...

Right, but you _only_ do that when you're asked to create a rule for a device where the kernel's name matches a pre-existing rule. You don't do it consistently -- and Marco was objecting to a patch which just made it happen consistently. That patch on its own would be sufficient to fix the PS3 and Libertas problems, since the kernel uses a different basename for the logical devices we want to disambiguate. (It would also fix the clash between wlan0 and wmaster0 on mac80211 interfaces). We prob...

Ah, yes -- that's an improvement on the version in udev-120, which would only write it if $INTERFACE_NAME wasn't set _AND_ the current interface It's for compatibility with older configuration. Before udev, the Fedora network configuration used to allow you to set a MAC address for each configured interface, and would rename interfaces accordingly. This preserves that functionality, automatically converting it to udev rules. If we were to include the KERNEL== criterion even when $INTERFACE_NAME ...