Re: [patch] de(4) has not worked on 8-current since Feb 13

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