Old problem still present on 11-ALPHA1 - Pi2

Tue Jul 12 14:33:35 UTC 2016

On 7/12/2016 04:39, Bernd Walter wrote:
> On Mon, Jul 11, 2016 at 08:28:19PM -0500, Karl Denninger wrote:
>>
>> On 7/11/2016 15:58, Bernd Walter wrote:
>>> On Mon, Jul 11, 2016 at 12:21:53PM -0500, Karl Denninger wrote:
>>>> On 7/11/2016 11:38, Hans Petter Selasky wrote:
>>>>> On 07/11/16 18:15, Karl Denninger wrote:
>>>>> 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.
>>> Sure it is not the board, powersupply, cable or switchport?
>> Yes, considering that I have (multiple times) swapped literally
>> everything (I have a bunch of PI2s here.)  Just for grins and giggles I
>> did it again; swapped in a known working (no problems of this sort)
>> board, power supply that was used with it and network cable, and moved
>> it to a different switch port.
>>
>> The problem is still there.
>>
>> It *only* happens if I have the VLANs enabled.  If I am running a single
>> network on an interface it's fine.
>>> Check if the red power LED on the Raspberry is on - it goes off under
>>> a certain supply voltage, although the board contiues to work.
>> Uh, the red LED only comes on during the boot sequence until the kernel
>> init's the GPIO on FreeBSD.  You're thinking of Linux.  I have a little
>> program that runs and slowly blinks the green LED though once started;
>> it's purpose is to provide a visible "system is running" indication.
> Strange - I'll have to test it, but I could have sworn that the power LED is
> independend from the OS.
>
>>> AFAIK all Raspberries have the same ethernet chip.
>>> Well - some earlier B (not B+) had used the 9512 instead of the 9514.
>>> Doesn't sound very logical if the same driver behaves different.
>>> A link down/up isn't something I would expect from the host controller
>>> causing this either.
>>> I also never had this problem on a Pi2.
>> How many people are running three networks (base plus two VLANs) on them?
> Not just Pi2 - I wonder how many do VLAN with USB ethernet at all?
>
>>>> 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.)
>>> Usually it is the PHY (which is integrated into the 9514), that detects
>>> and negotiates the link.
>>> The PHY runs on it's own internal state machine.
>>> The OS just gets informed, so that it can trigger some processing,
>>> such as updating the MAC for the negotiated link speed/duplex, logging
>>> the event, ...
>> I know.
>>
>> This has been an issue since the first RPI2 builds with this particular
>> configuration -- and still is.  If I could figure out *why* it thinks
>> the PHY is going down I could track it down, but there's nothing I can
>> find that tells me that.
> The strange thing is tha VLANs have nothing to do with the link at all.
> The only obvious difference for the PHY is that it may see more traffic
> with more LANs.
> I currently have no Pi running FreeBSD accessable - I run my 24/7
> FreeBSD ARM systems on Wandboards, but you ifconfig doewsn't show any
> VLAN offloading capabilities, so not an explanation either.
>
>> Oh, and the switch doesn't think it flapped either (!!); there is
>> nothing in the switch log about the link being lost and restored.
> So it is the receiver side which has a problem.
> I assume if you had packet loss you would have mentioned.
> Makes me wonder if this is really a link loss at all and not just
> some kind of missinformation.
> The PHY status is something, which usually gets polled, so maybe
> data corruption at any time may lead to this problem?
>
That's my assumption at this point; the claim of the flip is wrong. 
But.... data corruption anywhere in a driver is very very bad!

-- 
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/20160712/27ae6e30/attachment.bin>