Skip site navigation (1)Skip section navigation (2) 
Date:      Thu, 21 Aug 2008 02:48:12 -0700
From:      "Garrett Cooper" <yanefbsd@gmail.com>
To:        pyunyh@gmail.com
Cc:        net@freebsd.org
Subject:   Re: Issues with msk driver on 8-CURRENT amd64
Message-ID:  <7d6fde3d0808210248i2a42c88cr378bfc5b998a236c@mail.gmail.com>
In-Reply-To: <7d6fde3d0808200820n315388eak8782b3583a990f20@mail.gmail.com>
References:  <7d6fde3d0808192345j3c6b595el2f60a21c8353e9ec@mail.gmail.com> <20080820080304.GA87443@cdnetworks.co.kr> <7d6fde3d0808200820n315388eak8782b3583a990f20@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help 
On Wed, Aug 20, 2008 at 8:20 AM, Garrett Cooper <yanefbsd@gmail.com> wrote:
> Comments inline.
>
> On Wed, Aug 20, 2008 at 1:03 AM, Pyun YongHyeon <pyunyh@gmail.com> wrote:
>> On Tue, Aug 19, 2008 at 11:45:48PM -0700, Garrett Cooper wrote:
>>  > Hi Pyun!
>>  >       I know it's been a while since I responded, but after
>>  > reinstalling my system recently I noticed that the issue I mentioned
>>  > almost a year ago
>>  > (http://www.mavetju.org/mail/view_thread.php?list=freebsd-net&id=2570821&thread=yes)
>>  > with my Marvell chipset card has once again returned. In the interim I
>>  > was using x86, and I didn't suffer from any of the issues I have again
>>  > on x64, and I was using XP x64 but now I've switched over to Vista x64
>>  > on my client box.
>>  >       Subsequently, the only thing that's really changed on my system
>>  > is that I'm using CPUTYPE=nocona (for my Core 2 Quad proc).
>>  >       I'm using the 7-RELENG kernel right now (and not really enjoying
>>  > it, but it works -- yay?), but I'd like to help resolve the issue with
>>  > msk under CURRENT with x64 and my chipset.
>>  >       Standing by awaiting marching orders with tcpdump, netcat, and
>>  > pciconf at my side to help debug the issue :).
>>
>> Would you please explain your issues with more information?
>> For instance,
>>  Can you see a valid link is established by msk(4)?
>
> Sort of. A link between the endpoints is established, but then it
> stalls and fails after a "connection reset".
>
>>  Did both ends agree on established speed/duplex?
>
> Yes, they did.
>
>>  What speed/duplex was chosen by msk(4)?
>
> 10/100MBit and GBit duplex, respectively.
>
>>  Forcing speed/duplex have any effects?
>
> Not sure, but using a 100MBit and 1GBit connection yields the same
> results, whereas before I just claimed it was just gigabit
> connections.
>
>>  Turning off checksum offload or TSO have any effects?
>
> How do I do that?
>
>>  Did you use back-to-back connection without switch?
>
> I'm connecting via a switch and it works perfectly fine via 7-RELENG with amd64.
>
>>  tcpdump data for a broken connection might be help too.
>
> Ok.
>
> More help on trying to setup everything to debug this issue would be helpful.
>
> FWIW, the issue might be that the MTU doesn't match for Windows and
> FreeBSD (I remember reading that somewhere a while back)...
> unfortunately, my router speaks this MTU (1464?) so connections via
> msk don't work properly anymore on 8-CURRENT.
>
> Thanks,
> -Garrett

I just started tcpdump and I noticed that my FreeBSD box is doing a
lot of arp who-has queries (1 host / sec). On a static, private
network though this shouldn't be the case, correct?

I also setup a simple echo server via python to do my bidding
(echo'ing foo) and the messages go through via 7-RELENG's kernel, but
I'm seeing a TON of checksum incorrect messages with the 8-CURRENT
kernel. Funny though because this issue used to occur with 7-CURRENT
last year, which is now 7-RELENG, so someone must have accidentally
introduced some kind of regression code into msk(4) or a dependent
portion of the kernel, or my compile options are causing this issue.

I'm posting my simple echo protocol python script at the bottom of the
message, and I'll send you the bzipped format of the tcpdump log
privately to avoid spamming net@.

Thanks,
-Garrett

============= TEST APP ===============

#!/usr/bin/env python
"""
  Name: simple_echoer
  Desc:  Simple echo server using a pre-agreed upon port to transmit
messages between a client and server.
  Author: Garrett Cooper [yanegomi {{_AT__spamfree}} gmail {{_DOT__} com]
  Date: 2008.08.21

  Example usage:

  Case 1 (server): simple_echoer server port_num
  Case 2 (client): simple_echoer client port_num [hostname|ip]

"""

import os
import socket
import sys

class simple_echoer:

        def __init__(self, port):
                self.port = int(port)

        def server(self):

                s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
                s.bind((socket.gethostname(), self.port))
                s.listen(1)

                i = 0

                while 1:
                        cli_s, __ = s.accept()
                        print "Data received from client socket #", i,
cli_s.recv(1500)
                        i = i+1

        def client_exit():
                sys.exit(0)

        def client(self, hostname):

                while 1:
                        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
                        s.connect((socket.gethostbyname(hostname), self.port))
                        s.send("foo")

def usage():
        print """
Usage: simple_echoer {server|client} port_num [hostname,ip]

Note: hostname is only required for the client.
        """
        sys.exit(0)

if len(sys.argv) <= 1 or (type != "client" && type != "server"):
        usage()

type = sys.argv[1]

if (len(sys.argv) != 4 and type == "client") or len(sys.argv) != 3 and
type != "client":
        usage()

se = simple_echoer(sys.argv[2])

if type == "server":
        se.server()
else:
        se.client(sys.argv[3])

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7d6fde3d0808210248i2a42c88cr378bfc5b998a236c>