de(4) does not work on 8.0-RC1 (was: Re: [patch] de(4) has not worked on 8-current since Feb 13)

From: WATANABE Kazuhiro <CQG00620_at_nifty.ne.jp>
Date: Thu, 24 Sep 2009 01:42:46 +0900
Hi, all.

This problem still exists on 8.0-RC1.  Does anyone have the same
problem?

I have two de(4) based NICs and they works well with 7.2-RELEASE.
On 8.0-RC1, they cannot send any (almost all) data from it.

 * Corega FastEther PCI-TX

> dmesg | grep ^de0
de0: <Digital 21140A Fast Ethernet> port 0xe000-0xe07f mem 0xd9001000-0xd900107f irq 12 at device 15.0 on pci0
de0: 21140A [10-100Mb/s] pass 2.2
de0: WARNING: using obsoleted if_watchdog interface
de0: Ethernet address: 00:00:f4:xx:xx:xx
de0: [ITHREAD]
> uname -a
FreeBSD scorpio.sign.local 8.0-RC1 FreeBSD 8.0-RC1 #1: Wed Sep 23 00:44:22 JST 2009     nabe_at_capricorn:/FreeBSD/obj/i386/RELENG_8/FreeBSD/RELENG_8/src/sys/GENERIC  i386

 * SMC EtherPower10/100

> dmesg | grep ^de0
de0: <Digital 21140A Fast Ethernet> port 0x6000-0x607f mem 0x20410000-0x2041007f irq 3 at device 13.0 on pci0
de0: SMC 9332BDT 21140A [10-100Mb/s] pass 2.0
de0: WARNING: using obsoleted if_watchdog interface
de0: Ethernet address: 00:00:c0:xx:xx:xx
de0: [ITHREAD]
> uname -a
FreeBSD aries.sign.local 8.0-RC1 FreeBSD 8.0-RC1 #0: Fri Sep 18 07:57:47 UTC 2009     root_at_asuna:/usr/obj/pc98/usr/src/sys/GENERIC  pc98


At Sat, 13 Dec 2008 00:37:14 +0900,
WATANABE Kazuhiro wrote:
> Hi.
> 
> I've posted a tcpdump output ("tcpdump -i de0 -w
> scp_local_to_remote.pcap") to the URL below.
> 
> http://homepage2.nifty.com/dumb_show/unix/work/scp_local_to_remote.pcap
> 
> In this output I ran "scp /boot/kernel/kernel remote_host:"
> on the system, and interruped it after 5 minutes
> (local_host = "scorpio", remote_host = "pisces").
> 
> At Thu, 11 Dec 2008 12:53:39 -0800,
> Garrett Cooper wrote:
> > On Thu, Dec 11, 2008 at 5:00 AM, WATANABE Kazuhiro <CQG00620_at_nifty.ne.jp> wrote:
> > > CC'ed to freebsd-current.
> > >
> > > At Wed, 10 Dec 2008 12:34:03 -0700,
> > > Scott Long wrote:
> > >> WATANABE Kazuhiro wrote:
> > >> > Hi, all.
> > >> >
> > >> > My de(4) NICs has not worked on 8-current since Feb 13.
> > >> >
> > >> >
> > >>
> > >> Can you define "not worked" a little better?  Does it give errors, or
> > >> corrupt data, or appear to not transmit and/or receive?
> > >>
> > >> Scott
> > >
> > > Thanks for your reply.  I should have written more details about the
> > > problem...
> > >
> > > On recent 8-current, my de(4) NICs cannot send any (almost all) data
> > > from it.
> > >
> > >  * The system boots normally.
> > >
> > >  * Probing/attaching the de(4) NICs are done successfully.
> > >
> > >  * The system can receive data from the other hosts.  For example the
> > >   following command was finished normally in 14 seconds:
> > >
> > > $ /usr/bin/time scp other_host:/boot/kernel/kernel .
> > > Password:
> > > kernel                                        100% 4717KB 471.7KB/s   00:10
> > >       14.03 real         0.53 user         0.40 sys
> > > $
> > >
> > >  * The system cannot send any data to the other hosts.  For example
> > >   the following command was "stalled" and never finished
> > >   (I interrupted the command after 5 minutes).  None of the data were
> > >   sent:
> > >
> > > $ /usr/bin/time scp /boot/kernel/kernel other_host:
> > > Password:
> > > kernel                                          1%  192KB   0.0KB/s - stalled -^CKilled by signal 2.
> > >      336.01 real         0.05 user         0.17 sys
> > > $
> > >
> > >  * The system doesn't show any error/warning messages.
> > >
> > >  * I can "slogin" from the other hosts to the system, and some small
> > >   amount of text output (ex. an output of "dmesg") are done
> > >   successfully.  But a bit large amount of text output are stopped
> > >   after a few seconds.  For example:
> > >
> > > $ ls -l /boot/kernel/kernel
> > > -r-xr-xr-x  1 root  wheel  10975839 Dec 11 13:46 /boot/kernel/kernel
> > > $ hd /boot/kernel/kernel | head
> > > 00000000  7f 45 4c 46 01 01 01 09  00 00 00 00 00 00 00 00  |.ELF............|
> > > 00000010  02 00 03 00 01 00 00 00  e0 c5 46 c0 34 00 00 00  |..........F.4...|
> > > 00000020  58 22 92 00 00 00 00 00  34 00 20 00 05 00 28 00  |X"......4. ...(.|
> > > 00000030  23 00 20 00 06 00 00 00  34 00 00 00 34 00 40 c0  |#. .....4...4._at_.|
> > > 00000040  34 00 40 c0 a0 00 00 00  a0 00 00 00 05 00 00 00  |4._at_.............|
> > > 00000050  04 00 00 00 03 00 00 00  d4 00 00 00 d4 00 40 c0  |.............._at_.|
> > > 00000060  d4 00 40 c0 0d 00 00 00  0d 00 00 00 04 00 00 00  |.._at_.............|
> > > 00000070  01 00 00 00 01 00 00 00  00 00 00 00 00 00 40 c0  |.............._at_.|
> > > 00000080  00 00 40 c0 a0 ca 81 00  a0 ca 81 00 05 00 00 00  |.._at_.............|
> > > 00000090  00 10 00 00 01 00 00 00  a0 ca 81 00 a0 da c1 c0  |................|
> > > $ hd /boot/kernel/kernel
> > > 00000000  7f 45 4c 46 01 01 01 09  00 00 00 00 00 00 00 00  |.ELF............|
> > > 00000010  02 00 03 00 01 00 00 00  e0 c5 46 c0 34 00 00 00  |..........F.4...|
> > > 00000020  58 22 92 00 00 00 00 00  34 00 20 00 05 00 28 00  |X"......4. ...(.|
> > > 00000030  23 00 20 00 06 00 00 00  34 00 00 00 34 00 40 c0  |#. .....4...4._at_.|
> > > 00000040  34 00 40 c0 a0 00 00 00  a0 00 00 00 05 00 00 00  |4._at_.............|
> > > (snip)
> > > 00005d90  0a 20 00 00 0b 00 00 00  00 00 00 00 70 15 00 00  |. ..........p...|
> > > 00005da0  ce 2a 00 00 36 23 00 00  c6 2a 00 00 0b 14 00 00  |.*..6#...*......|
> > > 00005db0  7c 03 00 00 b1 27 00 00  d9 1e 00 00 2e 15 00 00  ||....'..........|
> > > 00005dc0  00 00 00 00 6d 22 00 00  04 2a 00 00 72 23 00 00  |....m"...*..r#..|
> > > 00005dd0  00 00 00 00 00 00 00 00  d3 1f 00 00 00 00 00 00  |................|
> > > (Stopped here.  0x5de0 == 24032 bytes)
> > 
> > Hmm... definitely a TXO issue.
> > 
> > msk(4) had similar problems with my chipset using an MTU of 1492 and
> > checksumming until I provided Pyun some data which helped him improve
> > the driver code for the chipset.
> > 
> > Probably not the case here, but are there any tcpdump sessions with
> > raw frames that we could get to help traceback the cause?
> > 
> > Thanks,
> > -Garrett

---
WATANABE Kazuhiro (CQG00620_at_nifty.ne.jp)
Received on Wed Sep 23 2009 - 15:00:37 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:55 UTC