Re: [BUG] sky2 broken for Yukon PCI-E Gigabit Ethernet Controller 11ab:4362 (rev 19)
2.6.16-rc2 still misses your patch. Was there a special reason not to
send it
to Linus?
cu,
Knut
On Fri, Jan 27, 2006 at 07:07:34AM +0100, Knut Petersen wrote:
Well, there are no problems if SuSEfirewall2 is disabled. But have a look
at the loaded modules:
ipt_MASQUERADE 3968 1
pppoe 15360 2
pppox 4616 1 pppoe
OK, although we can't rule out sky2/netfilter from the enquiry, I've
identified two bugs in ppp/pppoe that may be responsible for what you
are seeing. So please try the following patch and let us know if the
problem still exists (or deteriorates/improves).
[PPP]: Fixed hardware RX checksum handling
When we pull the PPP protocol off the skb, we forgot to update the
hardware RX checksum. This may lead to messages such as
dsl0: hw csum failure.
Similarly, we need to clear the hardware checksum flag when we use
the existing packet to store the decompressed result.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
diff --git a/drivers/net/ppp_generic.c b/drivers/net/ppp_generic.c
--- a/drivers/net/ppp_generic.c
+++ b/drivers/net/ppp_generic.c
@@ -1610,6 +1610,8 @@ ppp_receive_nonmp_frame(struct ppp *ppp,
}
else if (!pskb_may_pull(skb, skb->len))
goto err;
+ else
+ skb->ip_summed = CHECKSUM_NONE;
len = slhc_uncompress(ppp->vj, skb->data + 2, skb->len - 2);
if (len <= 0) {
@@ -1690,6 +1692,7 @@ ppp_receive_nonmp_frame(struct ppp *ppp,
kfree_skb(skb);
} else {
skb_pull(skb, 2); /* chop off protocol */
+ skb_postpull_rcsum(skb, skb->data - 2, 2);
skb->dev = ppp->dev;
skb->protocol = htons(npindex_to_ethertype[npi]);
skb->mac.raw = skb->data;
-
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: [BUG] 8139too fails for ip autoconfig and nfsroot
Knut Petersen wrote: but found none. Skipping ip autoconfig is no solution, the kernel then fails trying rpc lookup. Then I tried to netboot another system with the same kernel + via rhine driver, same server config. Voila, dhcp ip autoconfig and rpc port lookup is not a problem on this system. During my search for a solution I tried some recent kernels, the oldest 2.6.14. All fail with 8139too. Any ideas? It does work now. How? I enabled "Use PIO instead of MMIO". Everything started to work. I disabled "Use PIO instead of MMIO" and enabled "Use older RX-reset method". Everything still fine. The crazy thing is that it does work now even with both of the options disabled. It does work even after complete power removal for several hours. cu, Knut - 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
[BUG] 8139too fails for ip autoconfig and nfsroot
I have a number of systems equipped with: :05:05.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32 (8000ns min, 16000ns max) Interrupt: pin A routed to IRQ 177 Region 0: I/O ports at d000 [size=1027M] Region 1: Memory at d032 (32-bit, non-prefetchable) [size=256] Expansion ROM at 0002 [disabled] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Those cards have PXE boot roms. There are no problems in normal operation, but something is totaly wrong when I try to use those cards for network booting: I compiled a kernel for nfsroot and dhcp ip autoconfiguration, configured the server and tried to boot. Well, booting memtest and booting msdos works perfectly fine. Loading the kernel is also no problem, but at the point of ip autoconfiguration (ip=dhcp) the kernel loops sending DHCPDISCOVER packets. Those packets arrive at the server, and the server responds appropiately. ic_bootp_recv() never gets called (checked by a printk). I suspected a server malconfiguration, but found none. Skipping ip autoconfig is no solution, the kernel then fails trying rpc lookup. Then I tried to netboot another system with the same kernel + via rhine driver, same server config. Voila, dhcp ip autoconfig and rpc port lookup is not a problem on this system. During my search for a solution I tried some recent kernels, the oldest 2.6.14. All fail with 8139too. Any ideas? cu, Knut - 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: [BUG] sky2 broken for Yukon PCI-E Gigabit Ethernet Controller 11ab:4362 (rev 19)
Herbert Xu wrote: When we pull the PPP protocol off the skb, we forgot to update the hardware RX checksum. This may lead to messages such as dsl0: hw csum failure. Similarly, we need to clear the hardware checksum flag when we use the existing packet to store the decompressed result. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> ACK That patch seems to solve all my problems with sky2 / pppoe / SuSE 9.2 Firewall. Thanks a lot! cu, Knut - 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: [BUG] sky2 broken for Yukon PCI-E Gigabit Ethernet Controller 11ab:4362 (rev 19)
* Herbert Xu wrote: Does the problem go away if you disable conntrack by unloading its module? Please try to capture the offending ICMP packet with tcpdump and show us what it looks like. Well, there are no problems if SuSEfirewall2 is disabled. But have a look at the loaded modules: ipt_MASQUERADE 3968 1 pppoe 15360 2 pppox 4616 1 pppoe af_packet 23240 2 ppp_generic30740 6 pppoe,pppox slhc7040 1 ppp_generic ipt_TOS 2816 28 ipt_TCPMSS 4800 2 ipt_LOG 7232 55 ipt_limit 2880 55 ipt_pkttype 1984 4 ipt_state 2240 46 ip6t_LOG8000 1 ip6t_limit 3008 1 ip6t_REJECT 5824 3 ipt_REJECT 5952 3 iptable_mangle 3200 1 iptable_nat 8836 1 iptable_filter 3264 1 ip6table_mangle 2752 0 ip_nat_ftp 3776 0 ip_nat 18284 3 ipt_MASQUERADE,iptable_nat,ip_nat_ftp ip_conntrack_ftp8240 1 ip_nat_ftp ip_conntrack 51020 6 ipt_MASQUERADE,ipt_state,iptable_nat,ip_nat_ftp,ip_nat,ip_conntrack_ftp ip_tables 24088 11 ipt_MASQUERADE,ipt_TOS,ipt_TCPMSS,ipt_LOG,ipt_limit,ipt_pkttype,ipt_state,ipt_REJECT,iptable_mangle,iptable_nat,iptable_filter ip6table_filter 3136 1 ip6_tables 25624 5 ip6t_LOG,ip6t_limit,ip6t_REJECT,ip6table_mangle,ip6table_filter ipv6 271712 14 ip6t_REJECT How should I unload ip_conntrack alone? * Stephen Hemminger wrote: Does it always show up on icmp only? What are the iptables rules (iptables -L) As far as I can see, all my sky2 problems are gone with -K rx off. So here is more information. I executed the following script: logger Starting test logger "Executing ethtool -K eth0 rx off" ethtool -K eth0 rx off logger "Executing tcpdump -i eth0 -vv > tcpdumpfile &" tcpdump -i eth0 -vv > tcpdumpfile & logger "Executing host www.suse.com" host www.suse.com logger "Sleeping 2 seconds" sleep 2 logger "Executing ping -c 2 195.135.220.3" ping -c 2 195.135.220.3 logger "Sleeping 2 seconds" sleep 2 logger "Executing ethtool -K eth0 rx on" ethtool -K eth0 rx on logger "Sleeping 2 seconds" sleep 2 logger "Executing host www.suse.com" host www.suse.com logger "Sleeping 2 seconds" sleep 2 logger "Executing ping -c 2 195.135.220.3" ping -c 2 195.135.220.3 logger "Sleeping 2 seconds" sleep 2 logger "Executing ethtool -K eth0 rx off" ethtool -K eth0 rx off logger "Sleeping 2 seconds" sleep 2 logger "killall tcpdump" killall tcpdump logger End of test The first host and ping worked fine, after the ethtool -K eth0 rx on the host www.suse.com timed out with ;; connection timed out; no servers could be reached and the ping 195.135.220.3 provoked the stack traces you see in sky2syslog. I attach the syslog for the time of the test, the output of iptables -L and the output of tcpdump as the very long lines included would be hard to read with linebreaks. No, I did _not_ delete anything from the tcpdump file. cu, Knut Jan 27 06:29:38 linux knut: Starting test Jan 27 06:29:38 linux knut: Executing ethtool -K eth0 rx off Jan 27 06:29:38 linux knut: Executing tcpdump -i eth0 -vv > tcpdumpfile & Jan 27 06:29:38 linux knut: Executing host www.suse.com Jan 27 06:29:38 linux kernel: [ 403.606906] device eth0 entered promiscuous mode Jan 27 06:29:38 linux knut: Sleeping 2 seconds Jan 27 06:29:40 linux knut: Executing ping -c 2 195.135.220.3 Jan 27 06:29:41 linux dhcpd: icmp.c(274): trace_write_packet with null trace type Jan 27 06:29:42 linux dhcpd: icmp.c(274): trace_write_packet with null trace type Jan 27 06:29:42 linux knut: Sleeping 2 seconds Jan 27 06:29:44 linux knut: Executing ethtool -K eth0 rx on Jan 27 06:29:44 linux knut: Sleeping 2 seconds Jan 27 06:29:46 linux knut: Executing host www.suse.com Jan 27 06:29:46 linux kernel: [ 406.693484] SFW2-INext-DROP-DEFLT-INV IN=dsl0 OUT= MAC= SRC=217.237.150.33 DST=84.171.112.100 LEN=74 TOS=0x10 PREC=0x00 TTL=57 ID=5 PROTO=UDP SPT=53 DPT=1076 LEN=54 Jan 27 06:29:47 linux kernel: [ 407.125112] SFW2-INext-DROP-DEFLT-INV IN=dsl0 OUT= MAC= SRC=217.237.150.33 DST=84.171.112.100 LEN=116 TOS=0x10 PREC=0x00 TTL=57 ID=24213 PROTO=UDP SPT=53 DPT=1078 LEN=96 Jan 27 06:29:58 linux knut: Sleeping 2 seconds Jan 27 06:30:00 linux knut: Executing ping -c 2 195.135.220.3 Jan 27 06:30:00 linux kernel: [ 412.693613] dsl0: hw csum failure. Jan 27 06:30:00 linux kernel: [ 412.693615] [] dump_stack+0x17/0x20 Jan 27 06:30:00 linux kernel: [ 412.693628] [] netdev_rx_csum_fault+0x31/0x40 Jan 27 06:30:00 linux kernel: [ 412.693632] [] __skb_checksum_complete+0x5a/0x60 Jan 27 06:30:00 linux kernel: [ 412.693635] [] icmp_error+0x10e/0x1e0 [ip_conntrack] Jan 27 06:30:00 linux kernel: [ 412.693644] [] ip_conntrack_in+0x72/0x240 [ip_conntrack] Jan 27 06:30:00 linux kernel: [ 412.
Re: [BUG] sky2 broken for Yukon PCI-E Gigabit Ethernet Controller 11ab:4362 (rev 19)
Stephen Hemminger schrieb: Could you try turning off rx checksumming (with ethtool). ethtool -K eth0 rx off There probably still are (generic) bugs in the netfilter code for CHECKSUM_HW socket buffers. "ethtool -K eth0 rx off" does cure my problem with sky2. Anybody is invited to send patches as the problem is 100% reproducible here. cu, Knut - 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: [BUG] sky2 broken for Yukon PCI-E Gigabit Ethernet Controller 11ab:4362 (rev 19)
Stephen Hemminger wrote: O It seems that the SuSE Firewall locked something I started with kernel 2.6.15-git7, tried 2.6.15.1 and 2.6.16-rc1*. At the moment I do use a kernel 2.6.15-git7 patched with an updated sky2 (v.013). I could not find a single working sky2 configuration. Are you using the full kernel.org kernel, or are you putting sky2 driver into the SUSE kernel? No SuSE kernels here. I started with kernel.org kernel 2.6.15-git7 and had those problems. Then I tried 2.6.16-rc3-git3, the most recent kernel at the time of my original writing. As I had some other problems with that kernel I had a look at the git tree of Linus and applied all sky2 related patches to the otherwise unchanged 2.6.15-git7. 2.6.15.1 also was no solution as sky2 seems to be not available there. There are a number of bug fixes related to hardware checksumming that are in the kernel.org kernel (2.6.15 or later). There was one in ICMP. These fixes relate to places in the code where a protocol decides to trim a packet by removing bytes. I am not familiar with the SuSE Firewall. Is it just standard netfilter modules or additional code? I have to admit that I don´t know enough about the network layers of the kernel, so here is a list of the network modules loaded (sky2 compiled into the kernel). SuSEFirewall is just standard netfiltering using those modules. ipt_MASQUERADE 3968 1 pppoe 15360 2 pppox 4616 1 pppoe af_packet 23240 2 ppp_generic30740 6 pppoe,pppox slhc7040 1 ppp_generic ipt_TOS 2816 28 ipt_TCPMSS 4800 2 ipt_LOG 7232 77 ipt_limit 2880 77 ipt_pkttype 1984 2 ipt_state 2240 45 ip6t_REJECT 5824 3 ipt_REJECT 5952 3 iptable_mangle 3200 1 iptable_nat 8836 1 iptable_filter 3264 1 ip6table_mangle 2752 0 ip_nat_ftp 3776 0 ip_nat 18284 3 ipt_MASQUERADE,iptable_nat,ip_nat_ftp ip_conntrack_ftp8240 1 ip_nat_ftp ip_conntrack 51020 6 ipt_MASQUERADE,ipt_state,iptable_nat,ip_nat_ftp,ip_nat,ip_conntrack_ftp ip_tables 24088 11 ipt_MASQUERADE,ipt_TOS,ipt_TCPMSS,ipt_LOG,ipt_limit,ipt_pkttype,ipt_state,ipt_REJECT,iptable_mangle,iptable_nat,iptable_filter ip6table_filter 3136 1 ip6_tables 25624 3 ip6t_REJECT,ip6table_mangle,ip6table_filter ipv6 271712 14 ip6t_REJECT As said before, rtl8139 does work perfectly well, the same is true for an identical system with a Via Rhine adapter. cu, Knut - 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
