[RFC][PATCH] Add suspend and resume support to uli526x
From: Rafael J. Wysocki [EMAIL PROTECTED]
Add suspend/resume support to the uli526x network driver (tested on x86_64,
with 'Ethernet controller: ALi Corporation M5263 Ethernet Controller, rev 40').
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
drivers/net/tulip/uli526x.c | 120 ++--
1 file changed, 105 insertions(+), 15 deletions(-)
Index: linux-2.6.22-rc3/drivers/net/tulip/uli526x.c
===
--- linux-2.6.22-rc3.orig/drivers/net/tulip/uli526x.c 2007-06-03
12:10:41.0 +0200
+++ linux-2.6.22-rc3/drivers/net/tulip/uli526x.c2007-06-03
12:14:33.0 +0200
@@ -220,6 +220,10 @@ static int mode = 8;
static int uli526x_open(struct net_device *);
static int uli526x_start_xmit(struct sk_buff *, struct net_device *);
static int uli526x_stop(struct net_device *);
+#ifdef CONFIG_PM
+static int uli526x_suspend(struct pci_dev *pdev, pm_message_t state);
+static int uli526x_resume(struct pci_dev *pdev);
+#endif
static struct net_device_stats * uli526x_get_stats(struct net_device *);
static void uli526x_set_filter_mode(struct net_device *);
static const struct ethtool_ops netdev_ethtool_ops;
@@ -425,21 +429,14 @@ static void __devexit uli526x_remove_one
/*
- * Open the interface.
- * The interface is opened whenever ifconfig activates it.
+ * Bring the interface up.
+ * Used by uli526x_open and uli526x_resume.
*/
-static int uli526x_open(struct net_device *dev)
+static void uli526x_up(struct net_device *dev)
{
- int ret;
struct uli526x_board_info *db = netdev_priv(dev);
- ULI526X_DBUG(0, uli526x_open, 0);
-
- ret = request_irq(dev-irq, uli526x_interrupt, IRQF_SHARED, dev-name,
dev);
- if (ret)
- return ret;
-
/* system variable init */
db-cr6_data = CR6_DEFAULT | uli526x_cr6_user_set;
db-tx_packet_cnt = 0;
@@ -467,7 +464,25 @@ static int uli526x_open(struct net_devic
db-timer.data = (unsigned long)dev;
db-timer.function = uli526x_timer;
add_timer(db-timer);
+}
+
+
+/*
+ * Open the interface.
+ * The interface is opened whenever ifconfig activates it.
+ */
+static int uli526x_open(struct net_device *dev)
+{
+ int ret;
+
+ ULI526X_DBUG(0, uli526x_open, 0);
+
+ ret = request_irq(dev-irq, uli526x_interrupt, IRQF_SHARED, dev-name,
dev);
+ if (ret)
+ return ret;
+
+ uli526x_up(dev);
return 0;
}
@@ -613,17 +628,15 @@ static int uli526x_start_xmit(struct sk_
/*
- * Stop the interface.
- * The interface is stopped when it is brought.
+ * Take the interface down.
+ * Used by uli526x_stop and uli526x_suspend.
*/
-static int uli526x_stop(struct net_device *dev)
+static void uli526x_down(struct net_device *dev)
{
struct uli526x_board_info *db = netdev_priv(dev);
unsigned long ioaddr = dev-base_addr;
- ULI526X_DBUG(0, uli526x_stop, 0);
-
/* disable system */
netif_stop_queue(dev);
@@ -634,6 +647,21 @@ static int uli526x_stop(struct net_devic
outl(ULI526X_RESET, ioaddr + DCR0);
udelay(5);
phy_write(db-ioaddr, db-phy_addr, 0, 0x8000, db-chip_id);
+}
+
+
+/*
+ * Stop the interface.
+ * The interface is stopped when it is brought.
+ */
+
+static int uli526x_stop(struct net_device *dev)
+{
+ struct uli526x_board_info *db = netdev_priv(dev);
+
+ ULI526X_DBUG(0, uli526x_stop, 0);
+
+ uli526x_down(dev);
/* free interrupt */
free_irq(dev-irq, dev);
@@ -654,6 +682,64 @@ static int uli526x_stop(struct net_devic
}
+#ifdef CONFIG_PM
+
+/*
+ * Suspend the interface.
+ */
+
+static int uli526x_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ struct net_device *dev = pci_get_drvdata(pdev);
+
+ ULI526X_DBUG(0, uli526x_suspend, 0);
+
+ if (dev netdev_priv(dev)) {
+ if (netif_running(dev)) {
+ netif_device_detach(dev);
+ uli526x_down(dev);
+ }
+ pci_save_state(pdev);
+ pci_enable_wake(pdev, pci_choose_state(pdev, state), 0);
+ pci_disable_device(pdev);
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
+ }
+ return 0;
+}
+
+/*
+ * Resume the interface.
+ */
+
+static int uli526x_resume(struct pci_dev *pdev)
+{
+ struct net_device *dev = pci_get_drvdata(pdev);
+ struct uli526x_board_info *db = netdev_priv(dev);
+ int err;
+
+ ULI526X_DBUG(0, uli526x_resume, 0);
+
+ if (dev db) {
+ pci_set_power_state(pdev, PCI_D0);
+ err = pci_enable_device(pdev);
+ if (err) {
+ printk(KERN_WARNING %s: Could not enable device \n,
+ dev-name);
+ return err;
+ }
+
Re: OOPS iproute2/tc/u32_destroy in 2.6.22-rc3-git6
[netdev added to CC]
Strobl Anton pisze:
While trying to stop qdisc/cbq with command
tc qdisc del dev eth1 root
using iproute2-2.6.20-070313, i get following kernel panic:
Oops: [#1]
Modules linked in: cls_route cls_u32 cls_fw sch_prio sch_sfq sch_tbf
sch_cbq ipt_MASQUERADE xt_TCPMSS ipt_LOG parport_pc lp parport tun edd
thermd
CPU:0
EIP:0060:[e09962a3]Not tainted VLI
EFLAGS: 00010282 (2.6.22-44017-default #3)
EIP is at u32_destroy+0x52/0xd8 [cls_u32]
eax: 004b ebx: cb01a400 ecx: c03fa2d0 edx:
esi: edi: cb01a400 ebp: cad1ac80 esp: cae5dc20
ds: 007b es: 007b fs: gs: 0033 ss: 0068
Process tc (pid: 8187, ti=cae5c000 task=cb6bf030 task.ti=cae5c000)
Stack: e0996db9 e0996e2e e0996d99 019e cb01a400 cad1ac00 0010
c02ea549
c02ea566 cad1ad08 e0a1fb1d 0286 cad1ac80
0010
cad1ac80 e0a1fbb9 cad1ac00 cad1ac00 e0a21f60
dd7ab000
Call Trace:
[c02ea549] tcf_destroy+0x9/0x1c
[c02ea566] tcf_destroy_chain+0xa/0x12
[e0a1fb1d] cbq_destroy_class+0x41/0x7e [sch_cbq]
[e0a1fbb9] cbq_destroy+0x44/0x56 [sch_cbq]
[c02e9aa6] qdisc_destroy+0x54/0x77
[c02eb048] tc_get_qdisc+0x16f/0x1b0
[c02eaed9] tc_get_qdisc+0x0/0x1b0
[c02e47d1] rtnetlink_rcv_msg+0x196/0x1b0
[c02e4d00] rtnl_dump_ifinfo+0x55/0x7d
[c03440fa] __mutex_lock_slowpath+0x1ab/0x1b3
[c02f01c5] netlink_run_queue+0x57/0xd0
[c02e463b] rtnetlink_rcv_msg+0x0/0x1b0
[c02e4537] rtnetlink_rcv+0x23/0x3b
[c02f024e] netlink_data_ready+0x10/0x49
[c02ee49a] netlink_sendskb+0x19/0x2f
[c02eff9e] netlink_sendmsg+0x270/0x27c
[c02d59f1] sock_sendmsg+0xcf/0xea
[c0127734] autoremove_wake_function+0x0/0x33
[c0127734] autoremove_wake_function+0x0/0x33
[c0144944] __alloc_pages+0x4d/0x28b
[c02d5b98] sys_sendmsg+0x18c/0x1ed
[c02d5e86] sys_recvmsg+0x152/0x1da
[c02d609a] sys_sendto+0x115/0x135
[c014286b] filemap_nopage+0x15f/0x263
[c014b9f4] __handle_mm_fault+0x2ff/0x77a
[c02d64a3] sys_socketcall+0x240/0x261
[c01039d6] sysenter_past_esp+0x5f/0x89
===
Code: 04 2e 6e 99 e0 c7 04 24 b9 6d 99 e0 e8 dc 48 78 df eb 18 8b 06 89
02 eb 30 8b 42 10 48 85 c0 89 42 10 75 07 89 f8 e8 d9 fd ff ff 8b 46 0c
EIP: [e09962a3] u32_destroy+0x52/0xd8 [cls_u32] SS:ESP 0068:cae5dc20
Kernel panic - not syncing: Fatal exception in interrupt
.config
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_SYSFS_DEPRECATED=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_KMOD=y
CONFIG_BLOCK=y
CONFIG_LBD=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_CFQ=y
CONFIG_DEFAULT_IOSCHED=cfq
CONFIG_TICK_ONESHOT=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_X86_PC=y
CONFIG_M586=y
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_XADD=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_F00F_BUG=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_MINIMUM_CPU_MODEL=4
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_PREEMPT_NONE=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_VM86=y
CONFIG_X86_REBOOTFIXUPS=y
CONFIG_MICROCODE=m
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_EDD=m
CONFIG_EFI_VARS=m
CONFIG_DELL_RBU=m
CONFIG_DCDBAS=m
CONFIG_HIGHMEM4G=y
CONFIG_PAGE_OFFSET=0xC000
CONFIG_HIGHMEM=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
NOTICE...CONGRATULATION!!!2007
- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] qla3xxx: device doesnt do hardware checksumming.
Stephen Hemminger wrote: Reading the code for ql_hw_csum_setup(), it is obvious that this driver is broken for IPV6. The driver sets the NETIF_F_HW_SUM flag, but the code for checksum setup only deals with IPV4. Compile tested only, no hardware available. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] applied to #upstream-fixes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] VLAN: kill_vid is only useful for VLAN filtering devices
Stephen Hemminger wrote: The interface for network device VLAN extension was confusing. The kill_vid function is only really useful for devices that do hardware filtering. Devices that only do VLAN receiption without filtering were being forced to provide the hook, and there were bugs in those devices. Many drivers had kill_vid routine that called vlan_group_set_device, with NULL, but that is done already. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] applied 1-5 to #upstream-fixes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] e1000: disable polling before registering netdevice
Auke Kok wrote: To assure the symmetry of poll enable/disable in up/down, we should initialize the netdevice to be poll_disabled at load time. Doing this after register_netdevice leaves us open to another race, so lets move all the netif_* calls above register_netdevice so the stack starts out how we expect it to be. Signed-off-by: Auke Kok [EMAIL PROTECTED] Cc: Herbert Xu [EMAIL PROTECTED] Cc: Doug Chapman [EMAIL PROTECTED] --- drivers/net/e1000/e1000_main.c | 11 +++ 1 files changed, 7 insertions(+), 4 deletions(-) applied to #upstream-fixes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] NetXen: Removal of extra free_irq call
Mithlesh Thukral wrote: NetXen: Removal of redundant free_irq This patch removes a redundant free_irq() call from remove() routine. This will also eliminate a warning during unload of driver. Signed-by: Mithlesh Thukral [EMAIL PROTECTED] --- drivers/net/netxen/netxen_nic_main.c |2 -- 1 files changed, 2 deletions(-) applied to #upstream-fixes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] myri10ge: report link up/down in standard ethtool way
Brice Goglin wrote: Report link up/down in standard ethtool way Signed-off-by: Brice Goglin [EMAIL PROTECTED] --- drivers/net/myri10ge/myri10ge.c |1 + 1 file changed, 1 insertion(+) applied to #upstream-fixes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NET: add MAINTAINERS entry for ucc_geth driver
Li Yang wrote: Signed-off-by: Li Yang [EMAIL PROTECTED] --- MAINTAINERS |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) applied, w/ Kim's ack - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] NetXen: Multicast filter for NetXen driver
Mithlesh Thukral wrote: NetXen: Add multicast filter code This patch will add manage the multicast filter from driver. It will add capability to write multicast addresses to hardware. Signed-by: Mithlesh Thukral [EMAIL PROTECTED] as has been repeatedly noted, there are endianness bugs. First I noted them, and apparently was ignored. Then Michael Beusch noted them as well. Will continue ignoring your buggy patch here. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] NetXen: Add NETXEN prefix to macros
Mithlesh Thukral wrote: NetXen: Add NETXEN prefix to a macro This patch will add the NETXEN prefix to USER_START macro. Signed-off by: Wen Xiong [EMAIL PROTECTED] Signed-off by: Mithlesh Thukral [EMAIL PROTECTED] --- drivers/net/netxen/netxen_nic.h |4 ++-- drivers/net/netxen/netxen_nic_ethtool.c |2 +- drivers/net/netxen/netxen_nic_hw.c |4 ++-- drivers/net/netxen/netxen_nic_init.c|4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-) Your patch description is useless. Clearly we know -what- it does, simply by reading the patch. But it does not answer the simple question: why? why is this needed in a bug fix Release Candidate series? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] NetXen: Fix ping issue
Mithlesh Thukral wrote: NetXen: Fix initialization and subsequent ping issue This patch will fix the initialization and ping issues seen on certain PPC architecture blades. Signed-off by: Wen Xiong [EMAIL PROTECTED] Signed-off by: Mithlesh Thukral [EMAIL PROTECTED] --- drivers/net/netxen/netxen_nic_main.c |7 +++ drivers/net/netxen/netxen_nic_niu.c |8 ++-- 2 files changed, 9 insertions(+), 6 deletions(-) Again, your patch description is useless. You should describe the problem being fixed, and how/why the changes seen in the patch actually fix the issue. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] NetXen: Fix link status messages
Mithlesh Thukral wrote: NetXen: Correct link status messages. This patch will fix the problem of wrong link status messages that were reported. Signed-off by: Wen Xiong [EMAIL PROTECTED] Signed-off by: Mithlesh Thukral [EMAIL PROTECTED] --- drivers/net/netxen/netxen_nic.h |1 + drivers/net/netxen/netxen_nic_init.c | 21 + drivers/net/netxen/netxen_nic_isr.c | 23 +++ 3 files changed, 37 insertions(+), 8 deletions(-) dropped due to previous patches being dropped - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] myri10ge: limit the number of recoveries
Brice Goglin wrote: Limit the number of recoveries from a NIC hw watchdog reset to 1 by default. It enables detection of defective NICs immediately since these memory parity errors are expected to happen very rarely (less than once per century*NIC). However, a defective NIC (very rare, fortunately) can see such an error quite often, ie. every few minutes under high load. Make the limit tunable to allow people with mission critical installations to crank up the tunable and recover an INTMAX number of times while waiting for a downtime window to replace the NIC. The performance won't be optimal, but at least, it will still work. Signed-off-by: Brice Goglin [EMAIL PROTECTED] --- drivers/net/myri10ge/myri10ge.c | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) NAK. Random broken (unrelated to silicon errata) can happen in any field installation, and manifest itself in any number of ways. If defective NICs are truly rare, it does not sound worth adding this workaround to the driver. If I had to guess, this is a meaningless gesture (from a technical standpoint) for a Big Customer(tm) who is currently throwing a temper-tantrum... :) By definition if you can give them a patch, and they can wait for the driver patch going upstream, then it is not a mission critical situation, otherwise they would already have the patch direct from you. Also, mission critical tends to imply that you cannot remove the driver from operation either, which is counter to the logic of patching a driver for the problem. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[git patches] net driver fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
MAINTAINERS |9 ++-
drivers/net/8139cp.c | 17 +++---
drivers/net/acenic.c | 21 ++---
drivers/net/acenic.h |1 -
drivers/net/amd8111e.c | 11 +
drivers/net/atl1/atl1_main.c | 33 +---
drivers/net/bnx2.c | 14
drivers/net/chelsio/cxgb2.c | 10
drivers/net/cxgb3/cxgb3_main.c |6 -
drivers/net/e1000/e1000_main.c | 11 ++---
drivers/net/forcedeth.c |8 +--
drivers/net/gianfar.c| 16 -
drivers/net/myri10ge/myri10ge.c |1 +
drivers/net/netxen/netxen_nic_main.c |2 -
drivers/net/ns83820.c| 12 --
drivers/net/qla3xxx.c|2 +-
drivers/net/r8169.c | 11 -
drivers/net/s2io.c | 12 --
drivers/net/sky2.c | 31 +++---
drivers/net/smc91x.h |5 +---
drivers/net/spider_net.c | 40 --
drivers/net/tg3.c| 16 -
drivers/net/typhoon.c| 11 +
net/8021q/vlan.c | 10 ++--
24 files changed, 45 insertions(+), 265 deletions(-)
Auke Kok (1):
e1000: disable polling before registering netdevice
Brice Goglin (1):
myri10ge: report link up/down in standard ethtool way
Li Yang (1):
NET: add MAINTAINERS entry for ucc_geth driver
Mithlesh Thukral (1):
NetXen: Removal of extra free_irq call
Paul Mundt (1):
smc91x: sh solution engine fixes.
Stephen Hemminger (6):
qla3xxx: device doesnt do hardware checksumming.
VLAN: kill_vid is only useful for VLAN filtering devices
sky2: Fix VLAN unregistration
8139cp: fix VLAN unregistration
atl1: eliminate unneeded kill_vid code
network drivers: eliminate unneeded kill_vid code
Valerie Henson (1):
Update tulip maintainer email address
diff --git a/MAINTAINERS b/MAINTAINERS
index 124b950..f3b5a39 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1487,6 +1487,13 @@ L: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
S: Maintained
+FREESCALE QUICC ENGINE UCC ETHERNET DRIVER
+P: Li Yang
+M: [EMAIL PROTECTED]
+L: netdev@vger.kernel.org
+L: [EMAIL PROTECTED]
+S: Maintained
+
FILE LOCKING (flock() and fcntl()/lockf())
P: Matthew Wilcox
M: [EMAIL PROTECTED]
@@ -3545,7 +3552,7 @@ S:Maintained
TULIP NETWORK DRIVER
P: Valerie Henson
-M: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
W: http://sourceforge.net/projects/tulip/
S: Maintained
diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c
index e8c9f27..a804965 100644
--- a/drivers/net/8139cp.c
+++ b/drivers/net/8139cp.c
@@ -435,20 +435,12 @@ static void cp_vlan_rx_register(struct net_device *dev,
struct vlan_group *grp)
spin_lock_irqsave(cp-lock, flags);
cp-vlgrp = grp;
- cp-cpcmd |= RxVlanOn;
- cpw16(CpCmd, cp-cpcmd);
- spin_unlock_irqrestore(cp-lock, flags);
-}
-
-static void cp_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid)
-{
- struct cp_private *cp = netdev_priv(dev);
- unsigned long flags;
+ if (grp)
+ cp-cpcmd |= RxVlanOn;
+ else
+ cp-cpcmd = ~RxVlanOn;
- spin_lock_irqsave(cp-lock, flags);
- cp-cpcmd = ~RxVlanOn;
cpw16(CpCmd, cp-cpcmd);
- vlan_group_set_device(cp-vlgrp, vid, NULL);
spin_unlock_irqrestore(cp-lock, flags);
}
#endif /* CP_VLAN_TAG_USED */
@@ -1944,7 +1936,6 @@ static int cp_init_one (struct pci_dev *pdev, const
struct pci_device_id *ent)
#if CP_VLAN_TAG_USED
dev-features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
dev-vlan_rx_register = cp_vlan_rx_register;
- dev-vlan_rx_kill_vid = cp_vlan_rx_kill_vid;
#endif
if (pci_using_dac)
diff --git a/drivers/net/acenic.c b/drivers/net/acenic.c
index 7122b7b..04382f9 100644
--- a/drivers/net/acenic.c
+++ b/drivers/net/acenic.c
@@ -480,12 +480,10 @@ static int __devinit acenic_probe_one(struct pci_dev
*pdev,
#if ACENIC_DO_VLAN
dev-features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
dev-vlan_rx_register = ace_vlan_rx_register;
- dev-vlan_rx_kill_vid = ace_vlan_rx_kill_vid;
#endif
- if (1) {
- dev-tx_timeout = ace_watchdog;
- dev-watchdog_timeo = 5*HZ;
- }
+
+ dev-tx_timeout = ace_watchdog;
+ dev-watchdog_timeo = 5*HZ;
dev-open = ace_open;
dev-stop = ace_close;
@@ -2283,19 +2281,6 @@ static void
Re: b44: regression in 2.6.22 (resend)
On Monday 28 May 2007, Thomas Gleixner wrote: On Mon, 2007-05-28 at 19:44 +0200, Maximilian Engelhardt wrote: Can you please keep CONFIG_HIGH_RES_TIMERS and CONFIG_NOHZ and try the following combinations on the kernel command line: 1) highres=off nohz=off (should be the same as your working config) 2) highres=off 3) nohz=off I tested this with my 2.6.22-rc3 kernel, here are the results: without any special boot parameters: problem does appear highres=off nohz=off: problem does not appear highres=off: problem does not appear nohz=off: problem does appear Is there any other strange behavior of the high res enabled kernel than the b44 problem ? I didn't notice anything in the past (as I wrote). But today I did some tests for an updated version of the p54 mac80211 wlan driver and I noticed exactly the same problem: when booting with highres=off everything is fine. But when I boot an highres enabled kernel and I do the iperf-test with the p54 driver, my systems becomes unresponsive during the test. It seems to be exactly the same problem I have with the b44 driver. So this might not be a bug in the b44 code but a bug somewhere in the linux networking code. I did the test with an 2.6.22-rc3-git4 kernel and the p54 driver built external as module. Maxi signature.asc Description: This is a digitally signed message part.
Re: OOPS iproute2/tc/u32_destroy in 2.6.22-rc3-git6
Michal Piotrowski wrote:
Strobl Anton pisze:
While trying to stop qdisc/cbq with command
tc qdisc del dev eth1 root
EIP is at u32_destroy+0x52/0xd8 [cls_u32]
Please try this patch.
[NET_SCHED]: Fix filter double free
cbq and atm destroy their filters twice when destroying inner classes
during qdisc destruction.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit a2b6772f1b9524b8d3c67bee3b92956d44555b22
tree a4b8b9f3675606ff935d2422e26b24adf6c1ad3c
parent 1df4e603136d09c0aee78102a05fb960be3764bb
author Patrick McHardy [EMAIL PROTECTED] Sun, 03 Jun 2007 18:35:09 +0200
committer Patrick McHardy [EMAIL PROTECTED] Sun, 03 Jun 2007 18:35:09 +0200
net/sched/sch_atm.c |1 +
net/sched/sch_cbq.c |8 +---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/sched/sch_atm.c b/net/sched/sch_atm.c
index be7d299..d1c383f 100644
--- a/net/sched/sch_atm.c
+++ b/net/sched/sch_atm.c
@@ -599,6 +599,7 @@ static void atm_tc_destroy(struct Qdisc *sch)
/* races ? */
while ((flow = p-flows)) {
tcf_destroy_chain(flow-filter_list);
+ flow-filter_list = NULL;
if (flow-ref 1)
printk(KERN_ERR atm_destroy: %p-ref = %d\n,flow,
flow-ref);
diff --git a/net/sched/sch_cbq.c b/net/sched/sch_cbq.c
index a294542..ee2d596 100644
--- a/net/sched/sch_cbq.c
+++ b/net/sched/sch_cbq.c
@@ -1748,10 +1748,12 @@ cbq_destroy(struct Qdisc* sch)
* classes from root to leafs which means that filters can still
* be bound to classes which have been destroyed already. --TGR '04
*/
- for (h = 0; h 16; h++)
- for (cl = q-classes[h]; cl; cl = cl-next)
+ for (h = 0; h 16; h++) {
+ for (cl = q-classes[h]; cl; cl = cl-next) {
tcf_destroy_chain(cl-filter_list);
-
+ cl-filter_list = NULL;
+ }
+ }
for (h = 0; h 16; h++) {
struct cbq_class *next;
L2TP driver review
I've had no comments on the latest version of my L2TP driver which I posted a month ago. Can someone review it or accept/reject it, please? I have a pppd plugin that uses this driver and I'm eager to push it upstream for inclusion in the pppd distribution as soon as possible. But first, this L2TP driver needs to be accepted... Thanks -- James Chapman Katalix Systems Ltd http://www.katalix.com Catalysts for your Embedded Linux software development Original Message Subject: resend [PATCH 0/5 2.6.21] L2TP: Introduce PPP-over-L2TP driver Date: Sat, 26 May 2007 18:46:24 +0100 From: James Chapman [EMAIL PROTECTED] To: netdev@vger.kernel.org On Patrick's request, I'm resending this patch set. There are no changes since they were posted 3 weeks ago. Please review. Thanks. This patch set adds a driver for PPP over L2TP. Patches to follow. The following changes have been made since the previous version submitted 23-APR-07. - Hold list lock while processing reorder queue in pppol2tp_recv_dequeue(). - Fix more __be type annotations. - Add a new UDP encapsulation socket type for L2TP (new patch). Modify driver receive path so that it hooks on udp_encap_rcv() rather than overload the socket's sk_data_ready() for skb reception. - Remove pppol2tp_fget() and friends. Previous code needed to find the tunnel fd from a context other than the one that created the socket. I now use the PPPoX management socket creation (which is done by the same process that creates the UDP socket, i.e. l2tpd) to derive the socket of the UDP tunnel using sockfd_lookup(). - Reorder some functions in proc file handling code to avoid needing function prototypes. - Remove code that sorted entries which are output in /proc/net/pppol2tp. Output now shows tunnels and sessions unordered. - Remove stupid userland conditional includes from the if_pppox.h changes. - Remove skb_queue_walk_safe and pppox-autoload patches from the series since they have now been applied. - Add in-kernel documentation (new patch). - Rebased to 2.6.21. The code still uses sk-sk_destruct() on the tunnel socket to cleanup internal contexts if the tunnel UDP socket is destroyed. About this patch series: The implementation uses the existing PPPoX subsystem that is currently used only by PPPoE. A userspace daemon handles all L2TP control protocol messages, while a PPPoX socket carries user data. The system architecture is similar to PPPoE, where a pppd plugin uses the PPPoX socket to send/receive PPP frames over an L2TP tunnel. PPP control frames are delivered to pppd while data frames are handled entirely by the kernel. There are 5 patches in the series:- 1 - Introduce new UDP encapsulation type for L2TP. 2 - API changes for L2TP. Adds definitions for L2TP in existing headers. 3 - pppol2tp driver core. New code. Requires patches 1, 2, and the recently applied skb_queue_walk_safe patch. 4 - Add an entry to MAINTAINERS file for this driver. 5 - Add in-kernel documentation. The driver is being used on x86, ia64, ppc, arm, mips32 and possibly other architectures. It is also known to work on multi-core SMP boxes. -- James Chapman Katalix Systems Ltd http://www.katalix.com Catalysts for your Embedded Linux software development - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OOPS iproute2/tc/u32_destroy in 2.6.22-rc3-git6
Patch for sch_cbq.c works perfect - no more kernel panic! (sch_atm.c = im not able to test atm shaping, sorry) Thank you for the fast response to my request! Strobl Anton a dot strobl at aws-it dot at Zitat von Patrick McHardy [EMAIL PROTECTED]: Michal Piotrowski wrote: Strobl Anton pisze: While trying to stop qdisc/cbq with command tc qdisc del dev eth1 root EIP is at u32_destroy+0x52/0xd8 [cls_u32] Please try this patch. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OOPS iproute2/tc/u32_destroy in 2.6.22-rc3-git6
Strobl Anton wrote:
Patch for sch_cbq.c works perfect - no more kernel panic!
(sch_atm.c = im not able to test atm shaping, sorry)
Thanks Anton. Dave, please apply.
[NET_SCHED]: Fix filter double free
cbq and atm destroy their filters twice when destroying inner classes
during qdisc destruction.
Reported-and-tested-by: Strobl Anton [EMAIL PROTECTED]
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit ea1601c50bf23af25094511e2a9ce1b755ab9669
tree a4b8b9f3675606ff935d2422e26b24adf6c1ad3c
parent 1df4e603136d09c0aee78102a05fb960be3764bb
author Patrick McHardy [EMAIL PROTECTED] Sun, 03 Jun 2007 18:35:09 +0200
committer Patrick McHardy [EMAIL PROTECTED] Sun, 03 Jun 2007 20:04:21 +0200
net/sched/sch_atm.c |1 +
net/sched/sch_cbq.c |8 +---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/sched/sch_atm.c b/net/sched/sch_atm.c
index be7d299..d1c383f 100644
--- a/net/sched/sch_atm.c
+++ b/net/sched/sch_atm.c
@@ -599,6 +599,7 @@ static void atm_tc_destroy(struct Qdisc *sch)
/* races ? */
while ((flow = p-flows)) {
tcf_destroy_chain(flow-filter_list);
+ flow-filter_list = NULL;
if (flow-ref 1)
printk(KERN_ERR atm_destroy: %p-ref = %d\n,flow,
flow-ref);
diff --git a/net/sched/sch_cbq.c b/net/sched/sch_cbq.c
index a294542..ee2d596 100644
--- a/net/sched/sch_cbq.c
+++ b/net/sched/sch_cbq.c
@@ -1748,10 +1748,12 @@ cbq_destroy(struct Qdisc* sch)
* classes from root to leafs which means that filters can still
* be bound to classes which have been destroyed already. --TGR '04
*/
- for (h = 0; h 16; h++)
- for (cl = q-classes[h]; cl; cl = cl-next)
+ for (h = 0; h 16; h++) {
+ for (cl = q-classes[h]; cl; cl = cl-next) {
tcf_destroy_chain(cl-filter_list);
-
+ cl-filter_list = NULL;
+ }
+ }
for (h = 0; h 16; h++) {
struct cbq_class *next;
Re: [patch 5/7] CAN: Add virtual CAN netdevice driver
Urs Thuermann wrote: Patrick McHardy [EMAIL PROTECTED] writes: And it allows you have both loopback and non-loopback devices in case that would be useful. That sounds very promising. I also was unhappy with the fixed number of vcan devices at module load time and have thought about ioctl's to add/delete devices and to change the loopback flag. A more general approach like the one you seem to be working on is preferable of course. I got a bit delayed, but I hope to have the patches in postable state tommorrow. Qdiscs might change skb-cb. Maybe use skb-sk? When we decided to use skb-cb it seemed the only possible option. We need a field that we can set to zero to indicate we don't want the driver to loop back the packet and the value in that field must survive the path can_send() dev_queue_xmit() ... dev-hard_start_xmit() netif_rx() can_rcv() I think I misread the comment * @cb: Control buffer. Free for use by every layer. Put private vars here to mean I can use it for this purpose and since it worked as intended we felt ok with this. Now I see, it states exactly the opposite that I can't count on the value being preserved across layers. Yes, that comment is a bit misleading. skb-sk can't be used since we shouldn't set it to zero before dev_queue_xmit() as Oliver already pointed out. IIRC, skb-sk couldn't also be used in rx half of that path, since it was set to null somewhere in netif_rx() but now, reading the src, I can't see where this would happen. Maybe this has changed or my memory has some bit errors. I'll look at it again. Even if it turns out skb-sk can be used in rx path, the need remains to pass down a flag from can_send() to dev-hard_start_xmit() indicating whether to loop back or not. That flag is a socket flag acording to Oliver, so you can use the flag itself. You could keep skb-sk for the RX path (don't call skb_orphan in your hard_start_xmit function), if that doesn't work worst case would be to use a flag in the skb (we still have 2 unused bits) until you've figured out a better way. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: L2TP driver review
From: James Chapman [EMAIL PROTECTED] Date: Sun, 03 Jun 2007 18:17:03 +0100 I've had no comments on the latest version of my L2TP driver which I posted a month ago. Can someone review it or accept/reject it, please? I have a pppd plugin that uses this driver and I'm eager to push it upstream for inclusion in the pppd distribution as soon as possible. But first, this L2TP driver needs to be accepted... In my case it is in my backlog, sometimes you just have to be patient as all of us are busy with one thing or another. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 5/7] CAN: Add virtual CAN netdevice driver
Oliver Hartkopp wrote:
The more i was thinking about my own suggested solution the more it
turned out to be ugly for me ...
Summarizing we have two problems to solve:
1. Identify the originating sk to potentially trash my own sent messages.
2. Indicate a requested local loopback to the lower (driver) layer.
Regarding point 1.:
skb-sk is intentionally set to NULL, when ever skb_orphan() or
skb_clone() is invoked to cut the reference to the sk. Performing a
loopback this is a reasonable thing to do as also skb-destructor(skb)
is called in skb_orphan().
Indeed skb-sk is completely unused in the rx path, so we just would
have to 'preserve' skb-sk the way 'up' whenever we make use of
skb_orphan() or skb_clone().
E.g. in af_can.c the deliver() function would be changed like this:
(..)
Now it's done:
1. The needed skb-sk is preserved for the rx path (the way 'up').
2. The loopback indication is done by using the unused skb-protocol in
the tx path.
3. skb-cb is now unused (which was a breaking of rules as remarked by
Patrick)
And finally: It's working fine and appears nice :-)
Please have a look on the sparse changes i would like to commit on the
project SVN.
If there are no objections from your side these (and the other remarked)
changes will go into the next patch series for PF_CAN.
Special thanks to Patrick for the important feedback on the skb-cb usage!!
Best regards,
Oliver
(please excuse the wrong white spaces ...)
Index: net/can/af_can.c
===
--- net/can/af_can.c(revision 324)
+++ net/can/af_can.c(working copy)
@@ -257,7 +257,6 @@
*/
int can_send(struct sk_buff *skb, int loop)
{
-struct sock **tx_sk = (struct sock **)skb-cb;
int err;
if (skb-dev-type != ARPHRD_CAN) {
@@ -268,27 +267,34 @@
if (loop) {
/* local loopback of sent CAN frames (default) */
-/* indication for the CAN driver: do loopback */
-*tx_sk = skb-sk;
+/*
+ * skb-protocol is unused in the tx path. We use it
+ * to indicate to the CAN driver 'do loopback!' by
+ * setting skb-protocol to an appropriate value.
+ */
+skb-protocol = htons(ETH_P_CAN);
/*
- * The reference to the originating sock may be also required
+ * The reference to the originating sock may be required
* by the receiving socket to indicate (and ignore) his own
- * sent data. Example: can_raw sockopt CAN_RAW_RECV_OWN_MSGS
+ * sent data. Example: can_raw sockopt CAN_RAW_RECV_OWN_MSGS.
+ * Therefore we have to ensure that skb-sk remains the
+ * reference to the originating sock by restoring skb-sk
+ * after each skb_clone() or skb_orphan() usage.
+ * skb-sk is usually unused and unset in the rx path.
*/
/* interface not capabable to do the loopback itself? */
if (!(skb-dev-flags IFF_LOOPBACK)) {
+struct sock *srcsk = skb-sk;
struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC);
/* perform the local loopback here */
newskb-protocol = htons(ETH_P_CAN);
newskb-ip_summed = CHECKSUM_UNNECESSARY;
+newskb-sk = srcsk;
netif_rx(newskb);
}
-} else {
-/* indication for the CAN driver: no loopback required */
-*tx_sk = NULL;
}
if (!(skb-dev-flags IFF_UP))
@@ -581,10 +587,12 @@
static inline void deliver(struct sk_buff *skb, struct receiver *r)
{
+struct sock *srcsk = skb-sk;
struct sk_buff *clone = skb_clone(skb, GFP_ATOMIC);
DBG(skbuff %p cloned to %p\n, skb, clone);
if (clone) {
+clone-sk = srcsk;
r-func(clone, r-data);
r-matches++;
}
Index: net/can/raw.c
===
--- net/can/raw.c(revision 324)
+++ net/can/raw.c(working copy)
@@ -154,7 +154,7 @@
if (!ro-recv_own_msgs) {
/* check the received tx sock reference */
-if (*(struct sock **)skb-cb == sk) {
+if (skb-sk == sk) {
DBG(trashed own tx msg\n);
kfree_skb(skb);
return;
Index: drivers/net/can/vcan.c
===
--- drivers/net/can/vcan.c(revision 324)
+++ drivers/net/can/vcan.c(working copy)
@@ -149,8 +149,8 @@
stats-tx_packets++;
stats-tx_bytes += skb-len;
-/* tx socket reference pointer: Loopback required if not NULL */
-loop = *(struct sock **)skb-cb != NULL;
+/* indication for CAN netdevice drivers that loopback is required */
+loop = (skb-protocol == htons(ETH_P_CAN));
if (!loopback) {
/* no loopback handling available inside this driver */
@@ -170,6 +170,8 @@
/* perform standard loopback handling for CAN network interfaces */
if (loop) {
+struct sock *srcsk = skb-sk;
+
Re: raw sockets ignore IP_HDRINCL data
Hi Herbet, Thanks for the feedback. On Sat, 2007-06-02 at 21:07 +1000, Herbert Xu wrote: Mick McCreath [EMAIL PROTECTED] wrote: When I run traceroute -i eth1 5.4.3.2, the UDP packets are routed out eth2. Has anybody seen this behaviour with traceroute?? Well the version of traceroute here actually does a BINDTODEVICE so it will go out of the right interface. It also binds the socket so that it gets the right source address. Which traceroute are you using?? I am using version 1.4a12 by Van Jacobson downloaded from Lawrence Berkeley Labs. In this one, it only binds if IP_HDRINCL is not defined (in a #ifndef). I can see your point of view that it would be nice if the kernel read the IP headers in making its routing decision. However, the current behaviour has been there forever and it's unclear what we might break by changing it. I sort of thought that might be the case :-) Cheers, -- -- Mick McCreath Sr Engineer Secure Computing® your trusted source for enterprise security™ www.securecomputing.com NASDAQ: SCUR 61 7 3435 2803 (Direct Phone) [EMAIL PROTECTED] Secure Computing Corporation 825 Stanley Street Woolloongabba Queensland 4102 Australia The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any review, dissemination, distribution or copying is strictly prohibited. If you have received this email message in error, please notify the sender by reply email and delete the message and any attachments. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raw sockets ignore IP_HDRINCL data
On Mon, Jun 04, 2007 at 08:52:07AM +1000, Mick McCreath wrote:
Which traceroute are you using??
I am using version 1.4a12 by Van Jacobson downloaded from Lawrence
Berkeley Labs.
The one from Debian which is based on the same source. Hmm, it
looks like I came to the same conclusion that you did and added
a patch to it five years ago to get it to bind the interface :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message
When received ICMP Fragmentation Needed message, PATH MTU is always set
to the 576 even if MTU in ICMP message is lager then 576. This is
because of error condition in function ip_rt_frag_needed(), now if
packet size of that ICMP message is less then new MTU, packet size will
be used ,but RFC says ICMP error message return as much as we can
without exceeding 576 bytes.
This patch has Fixed this BUG.
Huh? The test new_mtu = old_mtu should only hold if the sending router
is buggy which is what the hack is for.
Cheers,
Note here old_mtu is not the real old mtu, is the received message's size:
unsigned short old_mtu = ntohs(iph-tot_len);
So maybe the patch would like following.
Signed-off-by: Wei Yongjun [EMAIL PROTECTED]
--- net/ipv4/route.c.orig 2007-05-25 05:22:47.0 +0800
+++ net/ipv4/route.c2007-06-04 08:31:36.0 +0800
@@ -1424,7 +1424,7 @@ unsigned short ip_rt_frag_needed(struct
!(dst_metric_locked(rth-u.dst, RTAX_MTU))) {
unsigned short mtu = new_mtu;
- if (new_mtu 68 || new_mtu = old_mtu) {
+ if (new_mtu 68 || new_mtu =
rth-u.dst.metrics[RTAX_MTU-1]) {
/* BSD 4.2 compatibility hack :-( */
if (mtu == 0
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
doubt about qla3xxx checksum fix
I don't think it's %100 right, I'm referring specifically to e68a8c10c4c5daf363e946d10c1a5cba77d7f92c Sure, qla3xxx is only handling ipv4 in that ql_hw_csum_setup() function, but if you check the call site it really wants CHECKSUM_PARTIAL skb's to work on. And CHECKSUM_PARTIAL skbs are only setup for paths that advertise the NETIF_F_HW_CSUM capability. With Stephen's change it now won't checksum offload anything at all. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: doubt about qla3xxx checksum fix
On Sun, 03 Jun 2007 18:00:51 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: I don't think it's %100 right, I'm referring specifically to e68a8c10c4c5daf363e946d10c1a5cba77d7f92c Sure, qla3xxx is only handling ipv4 in that ql_hw_csum_setup() function, but if you check the call site it really wants CHECKSUM_PARTIAL skb's to work on. And CHECKSUM_PARTIAL skbs are only setup for paths that advertise the NETIF_F_HW_CSUM capability. CHECKSUM_PARTIAL is used on xmit for both NETIF_F_HWCSUM and NETIF_F_IPCSUM See acenic, 3c59x, ... -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: doubt about qla3xxx checksum fix
From: Stephen Hemminger [EMAIL PROTECTED] Date: Sun, 3 Jun 2007 18:50:59 -0700 On Sun, 03 Jun 2007 18:00:51 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: I don't think it's %100 right, I'm referring specifically to e68a8c10c4c5daf363e946d10c1a5cba77d7f92c Sure, qla3xxx is only handling ipv4 in that ql_hw_csum_setup() function, but if you check the call site it really wants CHECKSUM_PARTIAL skb's to work on. And CHECKSUM_PARTIAL skbs are only setup for paths that advertise the NETIF_F_HW_CSUM capability. CHECKSUM_PARTIAL is used on xmit for both NETIF_F_HWCSUM and NETIF_F_IPCSUM See acenic, 3c59x, ... I missed that, thanks a lot Stephen. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message
On Mon, Jun 04, 2007 at 08:39:21AM +0800, Wei Yongjun wrote:
Huh? The test new_mtu = old_mtu should only hold if the sending router
is buggy which is what the hack is for.
Note here old_mtu is not the real old mtu, is the received message's size:
unsigned short old_mtu = ntohs(iph-tot_len);
So maybe the patch would like following.
The size of the packet that caused the ICMP is what we want here. That's
why the router must be buggy.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message
On Mon, Jun 04, 2007 at 08:39:21AM +0800, Wei Yongjun wrote: Huh? The test new_mtu = old_mtu should only hold if the sending router is buggy which is what the hack is for. Note here old_mtu is not the real old mtu, is the received message's size: unsigned short old_mtu = ntohs(iph-tot_len); So maybe the patch would like following. The size of the packet that caused the ICMP is what we want here. That's why the router must be buggy. So I want to know how the route announce a MTU larger then 576, such as 1280? RFC says ICMP error message return as much as we can without exceeding 576 bytes. And ipv4 router alaways return as a packet size 576 because of this. If MTU is greater then 576, HOST will used mtu = guess_mtu(old_mtu) to get a MTU. Method of send ICMP Fragmentation Needed message is difference from receive, how can this resolve? Change the method of send ICMP Fragmentation Needed message? I do not think so, the only think we can do is to change the method of receive ICMP message. Do you agree this? -- A new email address of FJWAN is launched from Apr.1 2007. The updated address is: [EMAIL PROTECTED] -- Wei Yongjun Development Dept.I Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST) 8/F., Civil Defense Building, No.189 Guangzhou Road, Nanjing, 210029, China TEL: +86+25-86630523-858 COINS: 79955-858 FAX: +86+25-83317685 MAIL: [EMAIL PROTECTED] -- - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message
On Mon, Jun 04, 2007 at 12:03:57PM +0800, Wei Yongjun wrote:
So I want to know how the route announce a MTU larger then 576, such as
1280? RFC says ICMP error message return as much as we can without
exceeding 576 bytes.
I think there is a misunderstanding here. The RFC is talking about
how much of the payload may be included in the ICMP packet. It is
not talking about the length field in the original IP header. That
must be left untouched.
And ipv4 router alaways return as a packet size 576 because of this.
If MTU is greater then 576, HOST will used mtu = guess_mtu(old_mtu) to
get a MTU. Method of send ICMP Fragmentation Needed message is
difference from receive,
Which router is doing that?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message
On Mon, Jun 04, 2007 at 12:03:57PM +0800, Wei Yongjun wrote:
So I want to know how the route announce a MTU larger then 576, such as
1280? RFC says ICMP error message return as much as we can without
exceeding 576 bytes.
I think there is a misunderstanding here. The RFC is talking about
how much of the payload may be included in the ICMP packet. It is
not talking about the length field in the original IP header. That
must be left untouched.
As you said, the RFC is talking about the payload of ICMP packet, it's
not greater then 576, if router announce a MTU larger then 1280, the
original IP header must be a size of 704? The format of ICMP message is
like this:
IPv4 header
ICMP header
payload
And ipv4 router alaways return as a packet size 576 because of this.
If MTU is greater then 576, HOST will used mtu = guess_mtu(old_mtu) to
get a MTU. Method of send ICMP Fragmentation Needed message is
difference from receive,
Which router is doing that?
The latest kernel 2.6.21.3 also doing so. The rule to send ICMP message
limit this.
Ref to net/ipv4/icmp.c
line 433 void icmp_send(struct sk_buff *skb_in, int type, int code,
__be32 info)
line 434 {
...
line 572/* RFC says return as much as we can without exceeding 576
bytes. */
line 573
line 574room = dst_mtu(rt-u.dst);
line 575if (room 576)
line 576room = 576;
line 577room -= sizeof(struct iphdr) + icmp_param.replyopts.optlen;
line 578room -= sizeof(struct icmphdr);
line 579
line 560icmp_param.data_len = skb_in-len - icmp_param.offset;
line 561if (icmp_param.data_len room)
line 562icmp_param.data_len = room;
line 563icmp_param.head_len = sizeof(struct icmphdr);
line 576 do this.
--
A new email address of FJWAN is launched from Apr.1 2007.
The updated address is: [EMAIL PROTECTED]
--
Wei Yongjun
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
8/F., Civil Defense Building, No.189 Guangzhou Road,
Nanjing, 210029, China
TEL: +86+25-86630523-858
COINS: 79955-858
FAX: +86+25-83317685
MAIL: [EMAIL PROTECTED]
--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message
On Mon, Jun 04, 2007 at 12:32:49PM +0800, Wei Yongjun wrote:
The latest kernel 2.6.21.3 also doing so. The rule to send ICMP message
limit this.
Ref to net/ipv4/icmp.c
line 433 void icmp_send(struct sk_buff *skb_in, int type, int code,
__be32 info)
line 434 {
...
line 572/* RFC says return as much as we can without exceeding 576
bytes. */
line 573
line 574room = dst_mtu(rt-u.dst);
line 575if (room 576)
line 576room = 576;
line 577room -= sizeof(struct iphdr) + icmp_param.replyopts.optlen;
line 578room -= sizeof(struct icmphdr);
line 579
line 560icmp_param.data_len = skb_in-len - icmp_param.offset;
line 561if (icmp_param.data_len room)
line 562icmp_param.data_len = room;
line 563icmp_param.head_len = sizeof(struct icmphdr);
line 576 do this.
But this is not the old_mtu field that we were talking about. The
old_mtu field comes from iph-tot_len which is the length of field
in the *original* IP header. We're certainly not allowed touch that
field.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message
I know, I misunderstand the iph-tot_len, the ICMP payload is not contained a valid ipv4 packet. I do this under IPv6, it has no problem because IPv6 does not check this. ^_^ Thank you very much. But this is not the old_mtu field that we were talking about. The old_mtu field comes from iph-tot_len which is the length of field in the *original* IP header. We're certainly not allowed touch that field. Cheers, -- A new email address of FJWAN is launched from Apr.1 2007. The updated address is: [EMAIL PROTECTED] -- Wei Yongjun Development Dept.I Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST) 8/F., Civil Defense Building, No.189 Guangzhou Road, Nanjing, 210029, China TEL: +86+25-86630523-858 COINS: 79955-858 FAX: +86+25-83317685 MAIL: [EMAIL PROTECTED] -- - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
