Re: rtl8139 driver patch

[Jim McQuillan <jam@McQuil.com>]

Marty,

You-Da-Man!

I ran into a problem today with the rtl8139 and PS/2 mouse.

I decided I would try to understand the problem.  I cleaned off my desk,
got the pencil and paper out, printed out the source code for the
Etherboot
pieces, and was just about to go to work, when a message appeared in my
mailbox.  It was your patch for rtl8139.c

I applied your patch, burned a new eprom, and fired it up.  It worked!!!

I'll give it more of a workout over the next couple of days, to make
sure
it is really working, but so far, it looks great.

I was a little disappointed however, I was really getting ready to do
battle with the driver.  Kind of looking forward to the challenge.
Oh well, I'll just have to find something else to tackle.

Thanks, and good job!!

Jim McQuillan
jam@ltsp.org


Marty Connor wrote:
> 
> On 12/23/1999 5:46 AM ken@nlc.net.au Ken Yap wrote:
> >Rainer who wrote the driver is probably not on the list, but I asked
> >myself this question once. I looked at the data sheet, and it appears
> >you cannot configure fewer than 4. If you can get it to work with less,
> >please do.
> 
> This had been bothering me as well.  I ran the following command to check
> driver sizes:
> 
>     # size *.tmp | sort -r -k4,4
>        text        data     bss     dec     hex filename
>       11428         368   17753   29549    736d smc1211.tmp
>       11428         368   17753   29549    736d rtl8139.tmp
>       11241         312   12537   24090    5e1a tulip.tmp
>       11355         344   11609   23308    5b0c ntulip.tmp
>       11355         344   11609   23308    5b0c mx987x5.tmp
>       11355         344   11609   23308    5b0c lc82c115.tmp
>       11127         248    6560   17935    460f epic100.tmp
>       11063         344    6489   17896    45e8 lancepci.tmp
>       12151         316    5188   17655    44f7 eepro100.tmp
>       13831         404    3417   17652    44f4 3c90x.tmp
>        9027         282    6457   15766    3d96 ne2100.tmp
>        9008         282    6457   15747    3d83 ni6510.tmp
>       11670         202    3353   15225    3b79 cs89x0.tmp
>       11383         340    3385   15108    3b04 nepci.tmp
>        9997         318    3321   13636    3544 smc9000.tmp
>        9864         205    3353   13422    346e 3c509.tmp
>        9686         304    3353   13343    341f wd.tmp
>        8823         828    3353   13004    32cc exos205.tmp
>        9304         202    3417   12923    327b sk_g16.tmp
>        9290         214    3353   12857    3239 ne.tmp
>        8838         512    3353   12703    319f ni5210.tmp
>        8949         354    3353   12656    3170 3c507.tmp
>        8976         202    3353   12531    30f3 3c503.tmp
>        7969         234    3353   11556    2d24 tiara.tmp
> 
> I noted that the driver size for the rtl8139 driver was, as suspected
> quite high.  I looked at the source (rtl8139.c) and noticed that the
> transmit buffer was being allocated for 4 buffers.  I also noticed that
> the Etherboot system is polling, and is a single-threaded architecture.
> 
> I then downloaded the rtl8139A data sheet from the RealTEK site, and
> found that although there are 4 available transmit descriptors, there is
> no requirement that there be 4 seperate buffers for them, since if we are
> in full control of transmission we can be sure that only one packet is
> put in the buffer at a time.
> 
> I made the following changes to rtl8139.c:
> 
>    120c120
>     <       unsigned char tx_bufs[TX_BUF_SIZE * NUM_TX_DESC + 4];
>     ---
>     >       unsigned char tx_bufs[TX_BUF_SIZE + 4];
>     302c302
>     <               tx_buf[i] = my.tx_bufs + i*TX_BUF_SIZE;
>     ---
>     >               tx_buf[i] = my.tx_bufs;
> 
> With the following results:
> 
> before:
>        text        data     bss     dec     hex filename
>       11428         368   17753   29549    736d rtl8139.tmp
> after:
>        text        data     bss     dec     hex filename
>       11428         368   13145   24941    616d rtl8139.tmp
> 
> There is a resulting savings of about 4.5K bytes, which is a lot of space
> when all we have is 32K bytes to play with.  The driver seems to function
> identically, since basically, I just pointed all of its transmit
> descriptors at the same buffer, and made sure that only one transmit
> event was requested at a time.
> 
> Perhaps this change will help people who are having problems with this
> driver that may be related to memory corruption above 32K, by allowing
> more room for stack growth.  There are a few other things that can be
> done, but this is the easiest way to save memory, so let's try this first.
> 
> Those who can, please test the above 2 line patch and see if it helps fix
> problems.
> 
> Regards,
> 
> Marty
> 
> ---
>    Name: Martin D. Connor
> US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
>   Voice: (617) 491-6935, Fax: (617) 491-7046
>   Email: mdc@thinguin.org
>     Web: http://www.thinguin.org/
> 
> ===========================================================================
> This Mail was sent to netboot mailing list by:
> Marty Connor <mdc@thinguin.org>
> To get help about this list, send a mail with 'help' as the only string in
> it's body to majordomo@baghira.han.de. If you have problems with this list,
> send a mail to netboot-owner@baghira.han.de.
===========================================================================
This Mail was sent to netboot mailing list by:
Jim McQuillan <jam@McQuil.com>
To get help about this list, send a mail with 'help' as the only string in
it's body to majordomo@baghira.han.de. If you have problems with this list,
send a mail to netboot-owner@baghira.han.de.