Heads UP - MFC for em coming shortly

[Jack Vogel]

On 10/9/07, Mike Tancsa <mike at sentex.net> wrote:
> At 12:37 AM 10/9/2007, Jack Vogel wrote:
> > > Thanks,
> > >          I did find this reference
> > > http://www.higherorder.com.au/2007/6/25/intel_82573_patch
> > >
> > > Is there a way from FreeBSD to tell remotely if its needed ?
> >
> >Well, there would be a way, reading the MANC register and
> >seeing if the suspect bit is present, but am not sure if there
> >is some important point at which the thing gets misprogrammed,
> >its just best to use the patcher, its harmless if its not needed.
> >
> >Sorry, I realize its a hassle to boot to that wonder DOS :)
>
>
> OK, did some tests on local PM nics here at the office. On one nic
> (same model as what is causing us problems in the field) we can run
> the program over and over again, and it always exits with a zero
> value. Is this normal ?   On another NIC that we recently bought, it
> exits with a 1 which supposedly says "not needed".  How do we know
> that the update has taken ?  Is there any danger of it losing its
> reprogramming ?  In short, how do we verify it "worked"
>
> The version I am using is
>
> lava# ls -l dcgdis.exe
> -rw-r--r--  1 root  wheel  160029 Oct  4  2005 dcgdis.exe
> lava# md5 dcgdis.exe
> MD5 (dcgdis.exe) = a48d9e127c19528bd4a650e692b2f2be
> lava#
>
> Is there a newer one ?

There has only ever been one of these things, and its a binary
wad to me just as to you, so I don't know why it returns success
multple times, I guess it just checks the NIC type and does the
write. People writing this are not Unix types, they are DOS tools
programmers, should tell you something :)

I was just talking to one of our Linux engineers and they actually
export the ability to read and write the eeprom via ethtool, maybe
I should look into adding something like a sysctl for that.

Right now, just run it once, then test to see if the problem has
disappeared.

Jack