RTL8169 hw IP4CSUM_Tx workaround

In article <061021151532.M0112888mirage.ceres.dti.ne.jp>
I wrote:

> The attached patch seems to work on my RTL8169 and
macppc,
> but is there anyway to confirm if IFCAP_CSUM_IPv4_Tx

Oops, there is a fatal bug in the previous patch.
(uninitialized m_len which would cause random memory
corruption)

Here is a revised one:

---
Index: rtl8169.c
============================================================
=======
RCS file: /cvsroot/src/sys/dev/ic/rtl8169.c,v
retrieving revision 1.48
diff -u -r1.48 rtl8169.c
--- rtl8169.c	24 Oct 2006 11:17:49 -0000	1.48
+++ rtl8169.c	25 Oct 2006 15:45:27 -0000
 -152,8
+152,11 
 
 #include <dev/ic/rtl8169var.h>
 
+#define	ETHER_PAD_LEN	(ETHER_MIN_LEN - ETHER_CRC_LEN)
+
 
 static int re_encap(struct rtk_softc *, struct mbuf *, int
*);
+static inline int re_cksum_pad(struct mbuf *);
 
 static int re_newbuf(struct rtk_softc *, int, struct mbuf
*);
 static int re_rx_list_init(struct rtk_softc *);
 -758,7
+761,7 
 	 */
 
 	ifp->if_capabilities |=
-	    /* IFCAP_CSUM_IPv4_Tx | */ IFCAP_CSUM_IPv4_Rx |
+	    IFCAP_CSUM_IPv4_Tx | IFCAP_CSUM_IPv4_Rx |
 	    IFCAP_CSUM_TCPv4_Tx | IFCAP_CSUM_TCPv4_Rx |
 	    IFCAP_CSUM_UDPv4_Tx | IFCAP_CSUM_UDPv4_Rx |
 	    IFCAP_TSOv4;
 -1501,6
+1504,53 
 	return handled;
 }
 
+/*
+ * This function is just taken and modified from bge(4)
driver.
+ *
+ * Although re(4) chips support auto-padding small packets,
+ * but it seems to cause a bug on IPv4 hardware checksum
offload.
+ * To avoid the bug, pad packets manually if ip4csum is
enabled.
+ */
+static inline int
+re_cksum_pad(struct mbuf *pkt)
+{
+	struct mbuf *m_last, *m_pad;
+	int padlen;
+
+	padlen = ETHER_PAD_LEN - pkt->m_pkthdr.len;
+
+	/*
+	 * Walk packet chain to find last mbuf. We will either
+	 * pad there, or append a new mbuf and pad it.
+	 */
+	for (m_last = pkt; m_last->m_next != NULL; m_last =
m_last->m_next)
+		continue;
+
+	/* `m_last' now points to last in chain. */
+	if (M_TRAILINGSPACE(m_last) < padlen) {
+		/*
+		 * Allocate new empty mbuf chain pad it. Compact later.
+		 *
+		 * XXX
+		 * Is it better to allocate a new mbuf by MCLGET(9)
+		 * and copy whole data to avoid one more fragment
+		 * since the packet size is small enough in this case.
+		 */
+		MGET(m_pad, M_DONTWAIT, MT_DATA);
+		if (m_pad == NULL)
+			return ENOMEM;
+		m_pad->m_len = 0;
+		m_last->m_next = m_pad;
+		m_last = m_pad;
+	}
+
+	memset(mtod(m_last, char *) + m_last->m_len, 0,
padlen);
+	m_last->m_len += padlen;
+	pkt->m_pkthdr.len += padlen;
+
+	return 0;
+}
+
 static int
 re_encap(struct rtk_softc *sc, struct mbuf *m, int *idx)
 {
 -1541,6
+1591,15 
 		if ((m->m_pkthdr.csum_flags &
 		    (M_CSUM_IPv4 | M_CSUM_TCPv4 | M_CSUM_UDPv4)) != 0) {
 			rtk_flags |= RTK_TDESC_CMD_IPCSUM;
+			/*
+			 * Pad small packets explicitly if ip4csum is enabled
+			 * to avoid a hardware bug around IPv4 outboard cksum.
+			 */
+			if (m->m_pkthdr.len < ETHER_PAD_LEN) {
+				error = re_cksum_pad(m);
+				if (error != 0)
+					return error;
+			}
 			if (m->m_pkthdr.csum_flags & M_CSUM_TCPv4) {
 				rtk_flags |= RTK_TDESC_CMD_TCPCSUM;
 			} else if (m->m_pkthdr.csum_flags & M_CSUM_UDPv4)
{

---
Izumi Tsutsui

Hi,

On Tue, Dec 26, 2006 at 03:53:05AM +0100, Matthias Ferdinand
wrote:
> Hello,
> 
> I converted my Compaq Armada M700 notebook (P3) from
SuSE Linux 9.1 to 
> NetBSD3.0. While most other things work ok,  I seem to
have trouble 
> accessing the data/fax capability of my cellphone
(Siemens ME45 or Siemens 
> S35) from the notebook. Connected via data cable to
serial port /dev/tty00.

This should just work - at least I had another two Siemens
phones work
with some Notebooks and NetBSD until very recently.

> Dec 26 03:14:00 shlab pppd[173]: Modem hangup
> Dec 26 03:14:00 shlab pppd[173]: Connection terminated.

Hm. Try to use the non-DCD device, /dev/dty00, instead.

> Dec 26 03:14:02 shlab pppd[173]: Exit.
> 
> Immediately after "Serial connection
established", pppd says "Modem 
> hangup".
> 
> And sometimes (very rarely, indeed), it says "not
8-bit clean":

This happens when ppp connection is trying to start
negotiation while
the modem is in command mode. 

crtscts should be ok; combine with (no)modem and maybe
(no)local.

And try /dev/dty00 as mentioned above.

> I am running out of things to try. Can somebody give me
some more hints? 
> Perhaps I need to look into 8N1 (... not 8-bit clean
...), where is this 
> set in pppd (or outside of pppd?) ?

Always.

If this doesn't help, we'd need a log of the PPP
negotiations to find
out what happens - use kdebug 7 and log the kernel debug
messages to
some file using appropriate syslog.conf settings.

Regards,

	-is

--On Dienstag, Dezember 26, 2006 08:26:17 +0100 Ignatios
Souvatzis 
<isnetbsd.org> wrote:
> This happens when ppp connection is trying to start
negotiation while
> the modem is in command mode.
>
> crtscts should be ok; combine with (no)modem and maybe
(no)local.
>
> And try /dev/dty00 as mentioned above.
>
>> I am running out of things to try. Can somebody
give me some more hints?
>> Perhaps I need to look into 8N1 (... not 8-bit
clean ...), where is this
>> set in pppd (or outside of pppd?) ?
>
> Always.
>
> If this doesn't help, we'd need a log of the PPP
negotiations to find
> out what happens - use kdebug 7 and log the kernel
debug messages to
> some file using appropriate syslog.conf settings.

Hello,

thanks for your answer. Tried /dev/dty00, modem, local, but
none of this
makes any difference. kdebug 7 does not show any packets,
the link is
terminated before ppp takes place, this could be confirmed
on the dialin
server side.

As the login dialog worked using minicom, I tried to let
chat do the login,
so the server side would definitively be in PPP mode. The
link is still
terminated immediately, but now there is some kernel message
in the log:

Dec 26 13:30:40 shlab chat[9634]: CONNECT
Dec 26 13:30:40 shlab chat[9634]:  -- got it
Dec 26 13:30:40 shlab chat[9634]: send ()
Dec 26 13:30:40 shlab chat[9634]: expect (ogin
Dec 26 13:30:40 shlab chat[9634]:  9600/RLP^M
Dec 26 13:30:42 shlab chat[9634]: ^M
Dec 26 13:30:42 shlab chat[9634]: ^M
Dec 26 13:30:42 shlab chat[9634]:  login:
Dec 26 13:30:42 shlab chat[9634]:  -- got it
Dec 26 13:30:42 shlab chat[9634]: send (<user>^M)
Dec 26 13:30:42 shlab chat[9634]: expect (word
Dec 26 13:30:42 shlab chat[9634]: <user>^M
Dec 26 13:30:42 shlab chat[9634]: Password:
Dec 26 13:30:42 shlab chat[9634]:  -- got it
Dec 26 13:30:42 shlab chat[9634]: send (<pwd>^M)
Dec 26 13:30:43 shlab chat[9634]: expect (~)
Dec 26 13:30:43 shlab chat[9634]:  ^M
Dec 26 13:30:44 shlab chat[9634]: PPP session from
(<ip1>) to <ip2> 
beginning....~
Dec 26 13:30:44 shlab chat[9634]:  -- got it
Dec 26 13:30:44 shlab pppd[11205]: Serial connection
established.
Dec 26 13:30:44 shlab pppd[11205]: Using interface ppp0
Dec 26 13:30:44 shlab pppd[11205]: Connect: ppp0 <-->
/dev/dty00
Dec 26 13:30:44 shlab pppd[11205]: Modem hangup
Dec 26 13:30:44 shlab pppd[11205]: Connection terminated.
Dec 26 13:30:44 shlab /netbsd: ppp0: bad protocol 3402
Dec 26 13:30:46 shlab pppd[11205]: Exit.

There is some variety to that kernel message:

Dec 26 13:05:49 shlab /netbsd: ppp0: bad protocol 206c
...
Dec 26 13:10:20 shlab /netbsd: ppp0: bad protocol 14
...
Dec 26 13:12:31 shlab /netbsd: ppp0: bad protocol 206
...
Dec 26 13:17:46 shlab /netbsd: ppp0: bad fcs 470a
...
Dec 26 13:23:45 shlab /netbsd: ppp0: bad protocol 3402
...
Dec 26 13:30:44 shlab /netbsd: ppp0: bad protocol 3402

Then I started hacking at pppd. In main.c, it decides
"Modem hangup"
whenever the read from the ttyfd returns with zero length. I
disabled
this code section, and here is the result:

  - chat as before
  - "bad protocol" kernel message
  - receiving packets from the dialin server (!)
    (confirmed with a ppp log from server side)
  - sending/replying packets to dialin server
    (but not received at server)
  - lots of "received short packet"


Dec 26 17:55:41 shlab chat[3370]: PPP session from
(<ip1>) to <ip2> 
beginning....~
Dec 26 17:55:41 shlab chat[3370]:  -- got it
Dec 26 17:55:41 shlab /netbsd: ppp0: bad protocol 14
Dec 26 17:55:41 shlab pppd[19684]: Serial connection
established.
Dec 26 17:55:41 shlab pppd[19684]: Using interface ppp0
Dec 26 17:55:41 shlab pppd[19684]: Connect: ppp0 <-->
/dev/dty00
Dec 26 17:55:41 shlab pppd[19684]: received short packet:
Dec 26 17:55:42 shlab last message repeated 7603 times
Dec 26 17:55:42 shlab pppd[19684]: sent [LCP ConfReq id=0x1
<mru 552> 
<asyncmap 0x0> <magic 0x39b2d523> <pcomp>
<accomp>]
Dec 26 17:55:42 shlab pppd[19684]: received short packet:
Dec 26 17:55:44 shlab last message repeated 15810 times
Dec 26 17:55:44 shlab /netbsd: ppp0: got 24 bytes
Dec 26 17:55:44 shlab /netbsd: 
ff03c02101020014020600000000050633854f1707020802
Dec 26 17:55:44 shlab pppd[19684]: received short packet:
Dec 26 17:55:44 shlab pppd[19684]: rcvd [LCP ConfReq id=0x2
<asyncmap 0x0> 
<magic 0x33854f17> <pcomp> <accomp>]
Dec 26 17:55:44 shlab pppd[19684]: lcp_reqci: returning
CONFACK.
Dec 26 17:55:44 shlab pppd[19684]: sent [LCP ConfAck id=0x2
<asyncmap 0x0> 
<magic 0x33854f17> <pcomp> <accomp>]
Dec 26 17:55:44 shlab pppd[19684]: received short packet:
Dec 26 17:55:45 shlab last message repeated 8592 times
Dec 26 17:55:45 shlab pppd[19684]: sent [LCP ConfReq id=0x1
<mru 552> 
<asyncmap 0x0> <magic 0x39b2d523> <pcomp>
<accomp>]
Dec 26 17:55:45 shlab pppd[19684]: received short packet:
Dec 26 17:55:47 shlab last message repeated 16211 times
Dec 26 17:55:47 shlab /netbsd: ppp0: got 24 bytes
Dec 26 17:55:47 shlab /netbsd: 
ff03c02101030014020600000000050633854f1707020802
Dec 26 17:55:47 shlab pppd[19684]: received short packet:
Dec 26 17:55:47 shlab pppd[19684]: rcvd [LCP ConfReq id=0x3
<asyncmap 0x0> 
<magic 0x33854f17> <pcomp> <accomp>]
Dec 26 17:55:47 shlab pppd[19684]: lcp_reqci: returning
CONFACK.
Dec 26 17:55:47 shlab pppd[19684]: sent [LCP ConfAck id=0x3
<asyncmap 0x0> 
<magic 0x33854f17> <pcomp> <accomp>]
Dec 26 17:55:47 shlab pppd[19684]: received short packet:

Since packets arrive, there actually was no modem hangup.
pppd tries to send packets, but as the kernel sees the line
as being
disconnected, it probably just discards them.
The serial driver must be interpreting some signal from the
cellphone
as a modem hangup, which apparently is not correct (either
the phone
or the serial driver does it not correctly).
I can see this behaviour with a Siemens ME45, and two
Siemens S35i. This
probably means that the behaviour of the cellphones is
intended and not
because of a single broken unit.

Is there a way to get the kernel to log events on the serial
line? Are there
sysctl knobs to tune serial behaviour?

Best regards
Matthias Ferdinand

On Tue, Dec 26, 2006 at 06:26:35PM +0100, Matthias Ferdinand
wrote:
> --On Dienstag, Dezember 26, 2006 08:26:17 +0100
Ignatios Souvatzis 
> <isnetbsd.org> wrote:
> >This happens when ppp connection is trying to start
negotiation while
> >the modem is in command mode.
> >
> >crtscts should be ok; combine with (no)modem and
maybe (no)local.
> >
> >And try /dev/dty00 as mentioned above.
> >
> >>I am running out of things to try. Can somebody
give me some more hints?
> >>Perhaps I need to look into 8N1 (... not 8-bit
clean ...), where is this
> >>set in pppd (or outside of pppd?) ?
> >
> >Always.
> >
> >If this doesn't help, we'd need a log of the PPP
negotiations to find
> >out what happens - use kdebug 7 and log the kernel
debug messages to
> >some file using appropriate syslog.conf settings.
> 
> Hello,
> 
> thanks for your answer. Tried /dev/dty00, modem, local,
but none of this
> makes any difference. kdebug 7 does not show any
packets, the link is
> terminated before ppp takes place, this could be
confirmed on the dialin
> server side.

> Then I started hacking at pppd. In main.c, it decides
"Modem hangup"
> whenever the read from the ttyfd returns with zero
length. I disabled
> this code section, and here is the result:

[Deleted by me]

None of this is relevant - if the kernel signals EOF to the
userland pppd,
you can't help by ignoring it. Maybe the answer to the 3rd
question below
will tell us why it thinks it should do that.

1st question: do you run pppd as root? If not, please do.

2nd question: is the Siemens phone connected by an USB cable
or by an
RS232 cable? (Some USB-RS232 dongles have carrier detection
problems in NetBSD-3ish OS kernel versions, and the Siemens
USB cables
are RS232 over USB in disguise. In this case, a netbsd-4
beta2 kernel
should help.)

3rd question: can yo please increase the "debug"
count to pppd, and show
us pppd's debug output?

Regards,
	-is

--On Dienstag, Dezember 26, 2006 22:24:37 +0100 Ignatios
Souvatzis 
<isnetbsd.org> wrote:
> None of this is relevant - if the kernel signals EOF to
the userland pppd,
> you can't help by ignoring it. Maybe the answer to the
3rd question below
> will tell us why it thinks it should do that.

Hello,

no, I did not intend to use that hack for production  Just to
prove that 
the modem does not mean to hangup but actually is still
delivering data.

> 1st question: do you run pppd as root? If not, please
do.
yes, I called it as root. Logged in as adminmf, then su,
then pppd. Same 
when logging in directly as root

> 2nd question: is the Siemens phone connected by an USB
cable or by an
> RS232 cable? (Some USB-RS232 dongles have carrier
detection
it's an RS232 cable. Sorry for not telling straight away.
dmesg excercpt:
  isa0 at pcib0
  lpt0 at isa0 port 0x378-0x37b irq 7
  com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working
fifo
  com2 at isa0 port 0x3e8-0x3ef irq 5: ns16550a, working
fifo

> are RS232 over USB in disguise. In this case, a
netbsd-4 beta2 kernel
> should help.)
I tried with netbsd-3 (3.1) kernel, same result. I will try
netbsd-4 next.

Although the issue is probably not the phones, there might
still be some 
hardware issue in the notebook itself, even though it works
with the 
standard voice modem. Last time I used that under Linux was
about a year 
ago, and at the moment I cannot afford to temporarily
reinstall just for 
checking. Although it lists com0 and com2, there is only one
rs232 
connector. The other one is presumably an ir adapter, but
that does not 
seem to connect to the phones ir.

> 3rd question: can yo please increase the
"debug" count to pppd, and show
> us pppd's debug output?
It was already running with 4 "debug"s. As the
hangup is signalled 
immediately after "Serial connection established",
pppd does not get a 
chance to do any negotiations. Only my hacked pppd that
ignored the hangup 
could see some LCP packets from remote.

/etc/syslog.conf:
...
kern,daemon,local2.*                                   
/var/log/ppp-log


with kdebug 7, 4x debug:
Dec 27 00:05:36 shlab chat[565]: PPP session from
(<ip1>) to <ip2> 
beginning....~
Dec 27 00:05:36 shlab chat[565]:  -- got it
Dec 27 00:05:36 shlab pppd[563]: Serial connection
established.
Dec 27 00:05:36 shlab pppd[563]: Using interface ppp0
Dec 27 00:05:36 shlab pppd[563]: Connect: ppp0 <-->
/dev/tty00
Dec 27 00:05:36 shlab pppd[563]: Modem hangup
Dec 27 00:05:36 shlab pppd[563]: Connection terminated.
Dec 27 00:05:36 shlab /netbsd: ppp0: bad protocol 206
Dec 27 00:05:38 shlab pppd[563]: Exit.


Thank you.

Best regards
Matthias

--On Mittwoch, Dezember 27, 2006 00:27:53 +0100 Matthias
Ferdinand 
<mf+tech-netmfedv.net> wrote:
> I tried with netbsd-3 (3.1) kernel, same result. I will
try netbsd-4 next.
just noticed that "config" from NetBSD-3 does not
work with kernel 
netbsd-4.
I don't know how to convert the complete system to
NetBSD-current, seems 
possible only via source. I only have 1-2 hours tomorrow
evening before I 
leave for a short holiday. But I can try afterwards.

Thanks for helping out on a holiday!

Best regards
Matthias

On Wed, Dec 27, 2006 at 12:54:55AM +0100, Matthias Ferdinand
wrote:
> --On Mittwoch, Dezember 27, 2006 00:27:53 +0100
Matthias Ferdinand 
> <mf+tech-netmfedv.net> wrote:
> >I tried with netbsd-3 (3.1) kernel, same result. I
will try netbsd-4 next.
> just noticed that "config" from NetBSD-3 does
not work with kernel 
> netbsd-4.

Sorry - this is the first time I suspect you're using a
wrong kernel.
(You mentioned GENERIC in your first message). 

What's the difference between GENERIC and your GENERIC?

	-is

--On Mittwoch, Dezember 27, 2006 11:19:27 +0100 Ignatios
Souvatzis 
<ignatioscs.uni-bonn.de> wrote:
> Sorry - this is the first time I suspect you're using a
wrong kernel.
> (You mentioned GENERIC in your first message).
>
> What's the difference between GENERIC and your GENERIC?

Ah, I tried to save compilation time for netbsd-4 (for which
I could not 
find a binary version) by using a stripped down config I had
been using 
before with 3.0, and then config claimed syntax errors after
updating the 
/usr/src/sys tree to netbsd-4.
To be really sure I had not messed with config or compiler
or such, I 
downloaded the binary NetBSD 3.1 kernel (-GENERIC and
-GENERIC_LAPTOP) from 
ftp.netbsd.org and tried again with both, but the result is
exactly the 
same.

To make sure it is not caused by hardware alone, I will try
again with 
Linux after I return, in about 10 days. For now, I have a
good excuse to 
leave my notebook at home during the trip 

Best regards
Matthias

On Wed, Dec 27, 2006 at 09:36:46PM +0100, Matthias Ferdinand
wrote:
> Ah, I tried to save compilation time for netbsd-4 (for
which I could not find a 
> binary version) 

ftp://ftp.netbsd.org/pub/NetBSD-daily/netbsd-4/200612080000Z
/i386/binary/kernel/