Re: Problems with ANA-6944A + 5.3-BETA + IRQ sharing?

From: Oliver Lehmann (lehmann_at_ans-netz.de)
Date: 09/26/04

  • Next message: M. Warner Losh: "Re: USB memory stick hotswap problems"
    Date: Sun, 26 Sep 2004 22:15:18 +0200
    To: freebsd-current@freebsd.org
    
    

    Ok,

    I did some more investegating

    I plugged that card now into my testsystem (PI-166, xl0, xl1 de[0-3],
    running 5.3-BETA4).

    Configuration:
     * ANA 6944A (provides de0-3)
     * 3Com-905B (provides xl0)
     * 3Com-905B (provides xl1)
     * de3 -> 10.0.0.60 -> 10.0.0.0/24
     * de0 -> 10.0.1.60 -> 10.0.1.0/24
     * default route -> 10.0.0.1
     * /mnt/files is a nfs mount from 10.0.0.21
     * logged in with ssh from 10.0.1.51 to 10.0.1.60 three paralell sessions

    I started twice dd if=/mnt/files/dill_dd of=/dev/null in the first and
    second login session (4GB hdd image).

    During the two dd where running, I noticed verry strange things happen.
    I'll try to explain it... ;)

    For example: I typed on my ssh login-shell (my 3rd login)
            abcdefghijkl
    and nothing happend. I continued typing (same line)
            mnopqrstuvwx
    And as I typed "m", "a" showed up immediately. As I typed "n", "b" showed
    up immediately - and so on until "l" showed up.
    "m" didn't showed up. I waited and waited... nothing.. and after much time
    of waiting, "m" "n" and so on started to show up...
    I hope I explained it understandable...

    After that I pinged 10.0.1.51(->de0): (logged in from 10.0.1.51(->de0))

    test# ping 10.0.1.51
    PING 10.0.1.51 (10.0.1.51): 56 data bytes
    64 bytes from 10.0.1.51: icmp_seq=0 ttl=64 time=26257.896 ms
    64 bytes from 10.0.1.51: icmp_seq=1 ttl=64 time=25982.936 ms
    64 bytes from 10.0.1.51: icmp_seq=2 ttl=64 time=24977.955 ms
    64 bytes from 10.0.1.51: icmp_seq=3 ttl=64 time=23971.104 ms
    64 bytes from 10.0.1.51: icmp_seq=4 ttl=64 time=22965.371 ms
    64 bytes from 10.0.1.51: icmp_seq=5 ttl=64 time=21958.377 ms
    64 bytes from 10.0.1.51: icmp_seq=6 ttl=64 time=20951.601 ms
    64 bytes from 10.0.1.51: icmp_seq=7 ttl=64 time=19942.864 ms

    I can speed up the time to ~800ms by keeping Enter pressed in the
    ssh-login-shell which runs ping.

    xl0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
            options=9<RXCSUM,VLAN_MTU>
            inet6 fe80::210:5aff:fe60:9092%xl0 prefixlen 64 scopeid 0x1
            ether 00:10:5a:60:90:92
            media: Ethernet autoselect (none)
            status: no carrier
    xl1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
            options=9<RXCSUM,VLAN_MTU>
            ether 00:50:04:0c:e7:a1
            media: Ethernet autoselect (none)
            status: no carrier
    de0: flags=108843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
            inet6 fe80::200:d1ff:fe1f:e3a1%de0 prefixlen 64 scopeid 0x3
            inet 10.0.0.60 netmask 0xffffff00 broadcast 10.0.0.255
            ether 00:00:d1:1f:e3:a1
            media: Ethernet autoselect (100baseTX <full-duplex>)
            status: active
    de1: flags=108c02<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> mtu 1500
            ether 00:00:d1:1f:e3:a2
            media: Ethernet autoselect
    de2: flags=108c02<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> mtu 1500
            ether 00:00:d1:1f:e3:a3
            media: Ethernet autoselect
    de3: flags=108843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
            inet 10.0.1.60 netmask 0xffffff00 broadcast 10.0.1.255
            inet6 fe80::200:d1ff:fe1f:e3a4%de3 prefixlen 64 scopeid 0x6
            ether 00:00:d1:1f:e3:a4
            media: Ethernet autoselect (100baseTX <full-duplex>)
            status: active
    lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
            inet 127.0.0.1 netmask 0xff000000
            inet6 ::1 prefixlen 128
            inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7

    xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xe400-0xe47f mem
            0xdf800000-0xdf80007f irq 12 at device 10.0 on pci0
    xl1: <3Com 3c905B-TX Fast Etherlink XL> port 0xe000-0xe07f mem
            0xdf000000-0xdf00007f irq 10 at device 11.0 on pci0
    de0: <Digital 21140A Fast Ethernet> port 0xd800-0xd87f mem
            0xde800000-0xde80007f irq 7 at device 4.0 on pci1
    de1: <Digital 21140A Fast Ethernet> port 0xd400-0xd47f mem
            0xde000000-0xde00007f irq 10 at device 5.0 on pci1
    de2: <Digital 21140A Fast Ethernet> port 0xd000-0xd07f mem
            0xdd800000-0xdd80007f irq 12 at device 6.0 on pci1
    de3: <Digital 21140A Fast Ethernet> port 0xb800-0xb87f mem
            0xdd000000-0xdd00007f irq 7 at device 7.0 on pci1
    atkbd0: <AT Keyboard> irq 1 on atkbdc0
    fdc0: <Enhanced floppy controller (i82077, NE72065 or clone)> at port
            0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0
    sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
    sio1 at port 0x2f8-0x2ff irq 3 on isa0

    First time I ever saw such a behaviour. Tomorrow I'll go setting up a 4.X
    installation. But my feeling says... it's "just" the card...

    -- 
     Oliver Lehmann
      http://www.pofo.de/
      http://wishlist.ans-netz.de/
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
    

  • Next message: M. Warner Losh: "Re: USB memory stick hotswap problems"

    Relevant Pages

    • Re: SSH SMTP Tunneling problem
      ... > There is a firewall between the two machines than allow ssh connections ... It almost sounds like an mtu path discovery problem. ... If Linux2 is on on adsl and Linux1 is on dialup or company network, ...
      (comp.os.linux.networking)
    • Re: ssh works, scp hangs
      ... >i guess i am needing help from some ssh grand masters... ... >two debian boxes with sshd running on both. ... >scp from A to B works ... I'd check you have the MTU set correctly on box A. SSH usually uses ...
      (Debian-User)
    • Re: ssh works, scp hangs
      ... > ssh from A to B works ... > scp from A to B works ... This is a classic sign of MTU differences... ...
      (Debian-User)
    • Re: Trying to run an ssh server on a laptop behind a router... mtu mismatch?
      ... have forwarded the ssh port to the correct machine, and the packets are ... The ssh server works ... I suspect it has something to do with mismatched MTU. ...
      (comp.os.linux.networking)
    • Re: POP3 Connector Issue
      ... the DF number will always be 28 bytes less than the MTU ... using this ping test. ... your server is not connected to the Internet." ... the router should return the message "packet needs to ...
      (microsoft.public.windows.server.sbs)