netdev - Re: EG20T and Micrel KSZ9021 Gigabit Ethernet

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] [day] [month] [year] [list]

Message-ID: <5072D3B7.1090807@intcomgrp.com>
Date:	Mon, 8 Oct 2012 09:23:03 -0400
From:	James Kosin <jkosin@...comgrp.com>
To:	Francois Romieu <romieu@...zoreil.com>
CC:	<netdev@...r.kernel.org>
Subject: Re: EG20T and Micrel KSZ9021 Gigabit Ethernet

On 10/5/2012 5:09 PM, Francois Romieu wrote:
> (please don't top post)
>
> James Kosin <jkosin@...comgrp.com> :
>> The driver is always reporting:
>>     [...] pch_gbe: Transfer Carrier Sense Error
> You should send more information. Say dmesg, link stats (ip link),
> ethtool information, stats and offload settings.
>
> We have a small Micrel ksz9021 phy driver that the pch_gbe driver does
> not use and the latter pokes into some phy specific register (0x10) that
> the Micrel document does not include in its list of vendor registers...
>
> Does your motherboard vendor offer some linux driver ?
>
> /note to myself: pch_gbe should use standard mii.h registers instead
> of defining its own redundant set of registers.
>
> --
> Ueimor
>
I've attached the kernel configuration and the output of:
  dmesg > debug.log
  ifconfig >> debug.log

I'm currently in contact with the vendor of the Atom module, for
reference it is located here:
    http://www.congatec.com/en/products/qseven/dView/conga-qa6.html
They don't have any drivers yet listed for the linux kernel; other than
their API interface.

The pch_gbe driver seems to work; but, is expecting a different PHY
chipset installed.  I'm guessing by the directory that it is a Oki-Semi
conductor part.... (or maybe a LAPIS semiconductor part)  The driver
indicates it was a copy of the e1000e driver that has been modified.

What seems to be needed is a generic MAC driver that allows different
PHY sets installed over top of the implementation.  I know this may be a
bit late in the architecture...  My only other option is to also include
a copy of the e1000e driver modified for the Micrel PHY installed.  But,
again there should be a better way.

I'll let everyone know if anything changes or I find a solution from the
vendor.

Thanks,
James Kosin

View attachment "config-3.5.5" of type "text/plain" (132109 bytes)

View attachment "debug.log" of type "text/plain" (67163 bytes)