[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Possible bug or flaw detected.




Donald Becker wrote:

> On Wed, 26 Nov 1997, Wintermute wrote:
>
> > > You didn't include the 'dmesg' output in the attachments.  What value is
> > > being detected?
> > >
> >
> > My fault, I forgot to attach it.  I will send you several dmesg outputs in my next
> > message so that you have some sort of result set for comparison.  I can already
> > tell you that the number it is detecting is most always different, example:
> > 0x0000, 0xFFFF, 0x00FF, 0xFF00.  The only thing constant are the hex values of 0
> > and F.
>
> Is this at the first check for 6d50, or the second?
>   id_read_eeprom(7)
>   inw(ioaddr)
>
> If at id_read_eeprom(), increase the timeout value a *lot* .
>

Houston, we have liftoff!

Before I got this piece of mail from you I did just that (just trying to clarify that
indeed I am QUICK <big smile>).  Now that I see this would be the next thing you would
have done I feel REALLY good.

Ok, now for the details.  The delay I had to modify was the one at id_read_eeprom()
function.  Setting this value in progressive increments of 1000 I reached success at
5000 usec's of delay.

To be on the safe side I also modified the function above it with the same value (Ok, so
I'm paranoid).  This worked like a charm and my 3c509b card is ready to kick some
serious network butt (In a low-level kinda way <grin>).

Now I did notice when I rebooted after inserting the module that Win95 had trouble
detecting the card later on (even with removing the driver from Win95 and reinstalling
it after a warm boot).  To counter this problem I shifted the card back into PnP mode
and configured Windows accordingly.  To test it I restarted the system several times
into Linux and then Win95 and it worked like magic.  (The driver must have left the card
in an unstable state when using it in ISA mode.)  Go figure... I care not..

Now here's what I don't understand.  The usleep() function is used in the diagnostic
program, and the udelay() function is used in the driver.  The usleep function works
correctly, and the udelay function seems to not give enough time for the read on the
card to return information.

Could there be a better way of setting this delay in later releases of the driver by
calibrating the delay to the speed of the system (IE: ISA Bus)?

Anyways, I'm now set to take on my next challenge and set up Linux to use the Road
Runner cablemodem service (which I've read up on quite well in the interim).

I thank you for your help, you do a great service to the Linux community with your
work.  I don't think we (the users) show our appreciation enough.. after all, what would
a Linux machine be without network access?  (It would be something like self mutilation
in my case.. but opinions may vary.)  A thousand thanks to you sir, from all of us out
here in the Linux community!

(BTW, attached is the source code for the 1.14 driver with the delay values changed, for
anyone who isn't C savvy and wants to give it a try to see if it will solve a detection
problem they may be having. -- A few keywords nice and close together for the search
engines --- 3c509, ethernet, detection problem, Linux, Debian).

A content Linux Adeptus Major,
Wintermute



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: