netdev - RE: [PATCH net-next 1/1] net: dsa: microchip: Add Microchip KSZ8895 DSA driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <93AF473E2DA327428DE3D46B72B1E9FD4113EACE@CHN-SV-EXMX02.mchp-main.com>
Date:   Sat, 9 Dec 2017 03:55:47 +0000
From:   <Tristram.Ha@...rochip.com>
To:     <pavel@....cz>
CC:     <andrew@...n.ch>, <f.fainelli@...il.com>, <muvarov@...il.com>,
        <nathan.leigh.conrad@...il.com>,
        <vivien.didelot@...oirfairelinux.com>,
        <UNGLinuxDriver@...rochip.com>, <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next 1/1] net: dsa: microchip: Add Microchip KSZ8895
 DSA driver

> Ok, let me retry:
> 
> > One thing to debug this problem is to dump the MIB counters.  Use the
> ethtool
> > utility to show MIB counters of both ports:
> >
> > ethtool -S lan3
> > ethtool -S eth0
> >
> > Assuming eth0 is the MAC controller that drives the switch, the receive
> counters of
> > the host port of the switch should match the transmit counters of
> > lan3, and vice versa.
> 
> Hmm. I'm getting some "interesting" results from mii-tool:
> 
> root@...o:~# mii-tool lan3
> lan3: negotiated 1000baseT-HD flow-control, link ok
> 
> But IIRC the switch is 100mbit? And dmesg does get it right. Its just
> mii-tool that is confused.
> 
> Link detection seems to work
> 
> root@...o:/sys/bus/spi/devices/spi2.0# mii-tool lan1
> lan1: negotiated 1000baseT-HD flow-control, link ok
> root@...o:/sys/bus/spi/devices/spi2.0# mii-tool lan1
> lan1: no link
> 
> (But that really should be 100baseT, not 1000baseT).

ethtool lan3 should also report the correct setting.

> Is there register dump available somewhere? I was using
> /sys/bus/spi/devices/spi32766.0/registers but this does not seem to be
> available.

There is a patch to add that functionality.  It is very simple and I will send it
to you later.  Without that it is hard to debug the DSA driver if there is
something wrong.

I also have a simple utility to communicate with that registers file to read/write
register individually.  Is there a standard Linux utility for that function?

> I tried that ethtool -S, and counters do not seem to match:
> root@...o:~# ethtool -S eth0
> NIC statistics:
>      tx_dropped: 0
>      tx_packets: 55
>      tx_broadcast: 35
>      tx_multicast: 20
>      tx_crc_errors: 0
>      tx_undersize: 0
>      tx_oversize: 0
>      tx_fragment: 0
>      tx_jabber: 0
>      tx_collision: 0
>      tx_64byte: 0
>      tx_65to127byte: 35
>      tx_128to255byte: 0
>      tx_256to511byte: 20
>      tx_512to1023byte: 0
>      tx_1024to2047byte: 0
>      tx_GTE2048byte: 0
>      tx_octets: 9576
>      IEEE_tx_drop: 0
>      IEEE_tx_frame_ok: 55
>      IEEE_tx_1col: 0
>      IEEE_tx_mcol: 0
>      IEEE_tx_def: 0
>      IEEE_tx_lcol: 0
>      IEEE_tx_excol: 0
>      IEEE_tx_macerr: 0
>      IEEE_tx_cserr: 0
>      IEEE_tx_sqe: 0
>      IEEE_tx_fdxfc: 0
>      IEEE_tx_octets_ok: 9576
>      rx_packets: 0
>      rx_broadcast: 0
>      rx_multicast: 0
>      rx_crc_errors: 0
>      rx_undersize: 0
>      rx_oversize: 0
>      rx_fragment: 0
>      rx_jabber: 0
>      rx_64byte: 0
>      rx_65to127byte: 0
>      rx_128to255byte: 0
>      rx_256to511byte: 0
>      rx_512to1023byte: 0
>      rx_1024to2047byte: 0
>      rx_GTE2048byte: 0
>      rx_octets: 0
>      IEEE_rx_drop: 0
>      IEEE_rx_frame_ok: 0
>      IEEE_rx_crc: 0
>      IEEE_rx_align: 0
>      IEEE_rx_macerr: 0
>      IEEE_rx_fdxfc: 0
>      IEEE_rx_octets_ok: 0

These are the MIB counters from the switch host port:

>      p04_rx: 660
>      p04_rx_hi: 0
>      p04_rx_undersize: 0
>      p04_rx_fragments: 20

This indicates a problem with the MAC.  Are you using a MII or RMII version?

>      p04_rx_oversize: 0
>      p04_rx_jabbers: 0
>      p04_rx_symbol_err: 0
>      p04_rx_crc_err: 0
>      p04_rx_align_err: 0
>      p04_rx_mac_ctrl: 0
>      p04_rx_pause: 0
>      p04_rx_bcast: 0
>      p04_rx_mcast: 0
>      p04_rx_ucast: 0
>      p04_rx_64_or_less: 0
>      p04_rx_65_127: 0
>      p04_rx_128_255: 0
>      p04_rx_256_511: 0
>      p04_rx_512_1023: 0
>      p04_rx_1024_1522: 0
>      p04_tx: 388
>      p04_tx_hi: 0
>      p04_tx_late_col: 0
>      p04_tx_pause: 0
>      p04_tx_bcast: 0
>      p04_tx_mcast: 3

This indicates the host port tried to send frames to the MAC.

>      p04_tx_ucast: 0
>      p04_tx_deferred: 0
>      p04_tx_total_col: 0
>      p04_tx_exc_col: 0
>      p04_tx_single_col: 0
>      p04_tx_mult_col: 0
>      p04_rx_discards: 0
>      p04_tx_discards: 0
> root@...o:~# ethtool -S lan3
> NIC statistics:
>      tx_packets: 24
>      tx_bytes: 1356
>      rx_packets: 0
>      rx_bytes: 0

The previous counters are from DSA.  The rest are MIB counters of the port.

>      rx: 566
>      rx_hi: 0
>      rx_undersize: 0
>      rx_fragments: 0
>      rx_oversize: 0
>      rx_jabbers: 0
>      rx_symbol_err: 0
>      rx_crc_err: 0
>      rx_align_err: 0
>      rx_mac_ctrl: 0
>      rx_pause: 0
>      rx_bcast: 0
>      rx_mcast: 4
>      rx_ucast: 0
>      rx_64_or_less: 0
>      rx_65_127: 1
>      rx_128_255: 3
>      rx_256_511: 0
>      rx_512_1023: 0
>      rx_1024_1522: 0
>      tx: 0
>      tx_hi: 0
>      tx_late_col: 0
>      tx_pause: 0
>      tx_bcast: 0
>      tx_mcast: 0
>      tx_ucast: 0
>      tx_deferred: 0
>      tx_total_col: 0
>      tx_exc_col: 0
>      tx_single_col: 0
>      tx_mult_col: 0
>      rx_discards: 0
>      tx_discards: 0

They just reported frames are received from the port.  Because of problem with
the host port there is no transmission coming from the host port.