On 22/11/2007, Michael Pyne <[EMAIL PROTECTED]> wrote: > On Wednesday 21 November 2007, Andrew Morton wrote: > > On Wed, 21 Nov 2007 15:34:52 -0800 > > > > "Ayaz Abdulla" <[EMAIL PROTECTED]> wrote: > > > The solution is to get the OEM to update their BIOS (instead of > > > integrating this patch) since the MCP61 specs indicate that the MAC > > > Address should be in correct order from BIOS. > > > > > > By changing the feature DEV_HAS_CORRECT_MACADDR to all MCP61 boards, it > > > could cause it to break on other OEM systems who have implemented it > > > correctly. > > > > Getting an OEM to fix their BIOS isn't always a simple thing... > > > > Perhaps Michael's change should be enabled by a module parameter for > > those who happen to have the busted BIOS? > > I have contacted the motherboard vendor about this a couple of weeks ago per > Ayaz's request and have received no response. I've also upgraded to the > latest firmware for this motherboard and the bug remains. > > I think it would be ideal if there were a way to detect broken MCP61's (i.e. > those with a Gigabyte MAC ID instead of the nVidia one) and only reverse the > MAC address then. A module parameter would also work but then I'd need to > remember to apply it. :) >
Hmm, MAC address makeups are not my strong point, but are the no rules describing the various parts of the address that could perhaps be used to infer programatically if the address seems to be reversed or not, and then use that detection logic for all boards that are known to potentially have the issue? A module parameter that overrules the automatic detection (for when it gets it wrong) would probably also be a good idea. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
