Old problem still present on 11-ALPHA1 - Pi2

Karl Denninger karl at denninger.net
Mon Jul 11 17:22:21 UTC 2016


On 7/11/2016 11:38, Hans Petter Selasky wrote:
> On 07/11/16 18:15, Karl Denninger wrote:
>> I have two PI2s on the same switch here doing quite-different things.
>>
>> One never shows network problems.  The other one does this:
>>
>> ....
>>
>> ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>> ue0: <USB Ethernet> on smsc0
>> ue0: Ethernet address: b8:27:eb:08:12:1c
>> ugen0.4: <Inateck> at usbus0
>> umass0: <Inateck product 0x5136, class 0/0, rev 2.10/0.01, addr 4> on
>> usbus0
>> umass0:  SCSI over Bulk-Only; quirks = 0x0100
>> umass0:0:0: Attached to scbus0
>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>> da0: <Inateck  0> Fixed Direct Access SPC-4 SCSI device
>> da0: Serial Number 00000000000000000000
>> da0: 40.000MB/s transfers
>> da0: 476940MB (976773168 512 byte sectors)
>> da0: quirks=0x2<NO_6_BYTE>
>> random: unblocking device.
>> smsc0: chip 0xec00, rev. 0002
>> ue0: link state changed to DOWN
>> ue0: link state changed to UP
>> ue0.2: link state changed to UP
>> ue0.3: link state changed to UP
>> ue0: link state changed to DOWN
>> ue0.2: link state changed to DOWN
>> ue0.3: link state changed to DOWN
>> ue0: link state changed to UP
>> ue0.2: link state changed to UP
>> ue0.3: link state changed to UP
>> ue0: link state changed to DOWN
>> ue0.2: link state changed to DOWN
>> ue0.3: link state changed to DOWN
>> ue0: link state changed to UP
>> ue0.2: link state changed to UP
>> ue0.3: link state changed to UP
>> ue0: link state changed to DOWN
>> ue0.2: link state changed to DOWN
>> ue0.3: link state changed to DOWN
>> ue0: link state changed to UP
>> ue0.2: link state changed to UP
>> ue0.3: link state changed to UP
>>
>> Every now and then (every hour or so) the interface flaps.  If I plug a
>> USB interface in and use two network cords I *still* get the flapping.
>> This unit has very low (but non-zero) traffic on the network, while the
>> other actually has *more* traffic on the network yet is completely
>> stable.  Since both are plugged into the same physical switch I doubt
>> the switch itself or its firmware is involved in this.
>>
>> The only difference I can see is that the one that flaps is using
>> vlans.  Specifically, that machine is the network's dhcp server, and it
>> is on three different vlans (untagged and two tagged) so it can provide
>> addresses (and DNS services via unbound) to those VLAN interfaces.
>>
>> This appears to be somehow linked to the ue interface driver, because
>> another machine (Intel based) that is also on multiple vLANs via the em
>> driver does *not* flap.
>>
>> I don't know if this is actually arm related or not; it might not be if
>> Intel machines also use the "ue" driver, but it's very consistent on the
>> PI2 if I want to use vlan tags whether I have one or two interfaces (the
>> second via a USB adapter of course) in use or not.
>>
>> Other than the flapping the box appears to run fine; the flaps do,
>> however, sometimes stop reporting from the snmpd daemon so I have had to
>> stick a cron job out there to restart that on a schedule to prevent it
>> from interrupting reporting to my traffic management tools.  Whether the
>> two are related is not known with certainty (but I suspect it is.)
>>
>
> Did you try to set any media options, like 10MBps instead of 100Mbps ?
>
Yes; it makes no difference.

> What does ifconfig say?
>
> --HPS
No difference -- both are 100BaseTX connected.

Machine with the problem:
% ifconfig ue0
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80009<RXCSUM,VLAN_MTU,LINKSTATE>
        ether b8:27:eb:08:12:1c
        inet 192.168.1.200 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>


Machine without:
% ifconfig ue0
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80009<RXCSUM,VLAN_MTU,LINKSTATE>
        ether b8:27:eb:85:21:de
        inet 192.168.1.214 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

The only difference I can see between them is that the one that exhibits
the flapping has vlans defined on the interface (which are working
normally.)

Current code on both machines:
% uname -v
FreeBSD 11.0-BETA1 #0 r302526: Sun Jul 10 10:39:31 CDT 2016    
karl at NewFS.denninger.net:/pics/CrossBuild/obj/arm.armv6/pics/CrossBuild/src/sys/RPI2

However, this has been an issue since the first 11-Current builds that
had RPI2 capability in them, so it's not version-dependent either.

I have been unable to find a way to log the *reason* the flap occurs
(e.g. nothing in the logs indicating why it thinks link-sense
disappeared, if it actually thinks it did, or if something in the code
performed what amounted to an interface reset.)

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20160711/e31045a3/attachment.bin>


More information about the freebsd-arm mailing list