netdev - Re: [PATCH] e1000e: Intel 82571EB: Don't wait for MNG cycle on unmanaged chips

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: <AANLkTin69t9Z4vunB4t4X6p77=QSR9m+JueCcKSm8jEL@mail.gmail.com>
Date:	Mon, 30 Aug 2010 13:49:29 -0700
From:	Jesse Brandeburg <jesse.brandeburg@...il.com>
To:	Kyle Moffett <Kyle.D.Moffett@...ing.com>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	e1000-devel@...ts.sourceforge.net,
	Kyle Moffett <kyle@...fetthome.net>
Subject: Re: [PATCH] e1000e: Intel 82571EB: Don't wait for MNG cycle on
 unmanaged chips

On Fri, Aug 27, 2010 at 12:10 PM, Kyle Moffett
<Kyle.D.Moffett@...ing.com> wrote:
> The Intel 82571EB chipset can be used in an unmanaged configuration as a
> fast dual-port Gig-E controller.  Unfortunately a board constructed that
> way would fail to correctly come up because the driver polls for the
> completion of a management cycle that will never occur.
>
> To resolve this problem, we disable the poll and error return on chips
> whose EEPROMs indicate no management.  As a protection against
> misconfigured chipsets, we still delay for the entire management poll
> timeout.
>
> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@...ing.com>

Hi Kyle, thanks for submitting this patch.  Are you fixing this
problem for a device that is a LOM?  The reason I ask is that most if
not all of our current eeprom images require some firmware interaction
to correctly initialize the PHY when the part is reset, even for the
no_mng (no managability) case.

Your code below will avoid reading of and waiting for the cfg_done
bit, which means that the firmware could end up racing with the
driver, with them both trying to configure the part.

Was there a specific bug you were trying to fix, and can you reply (if
you want to me in private) with your ethtool -e ethX output?

The concern here is that you may simply have an out of date eeprom
image, which might fix the original issue and get the driver to work
correctly, as the behavior you are describing is not how it should
work according to our design.

At the very least we would like to reproduce your issue here so we can
investigate further.

Jesse
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html