[patch] de(4) has not worked on 8-current since Feb 13
WATANABE Kazuhiro
CQG00620 at nifty.ne.jp
Fri Dec 12 15:37:18 UTC 2008
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)
More information about the freebsd-current
mailing list