Very Computer

Any help will be appreciated,

Jacque Bussey

The Ethernet-HOWTO specifically mentions the card and how to get it going.
It works fine!  Also, do as the HOWTO suggests and get the latest version
of the "tulip.c" driver from Donald Beckers (sp?) site and stick it in
the kernel source tree before compiling. (ie. I used that driver - there is
another one included/mentioned in the HOWTO that is supposed to work as
well).

Later

Derric

/*
   NOTICE: this version works with kernels 1.1.82 and later only!
        Written 1994,1995 by Donald Becker.
        ...

        This driver is for the SMC EtherPower PCI ethernet adapter.
        It should work with most other DEC 21*40-based ethercards.

        .....

*/

   >The Ethernet-HOWTO specifically mentions the card and how to get it going.
   >It works fine!  Also, do as the HOWTO suggests and get the latest version
   >of the "tulip.c" driver from Donald Beckers (sp?) site and stick it in
   >the kernel source tree before compiling. (ie. I used that driver - there is
   >another one included/mentioned in the HOWTO that is supposed to work as
   >well).

   Just looked at tulip.c - looks like it doesn't need to be modified to
   support the EtherPower with kernel 1.3.20...  here's what is says:

   /*
      NOTICE: this version works with kernels 1.1.82 and later only!
           Written 1994,1995 by Donald Becker.
           ...

           This driver is for the SMC EtherPower PCI ethernet adapter.
           It should work with most other DEC 21*40-based ethercards.

           .....

   */

The problem is that the tulip.c driver (v0.10) from Donald Becker does
not work off the shelf with kernel versions > 1.3.4? (not sure where
it broke). The problem is with a call to init_etherdev, which has a
prototype in tulip.c of:

 /* This will be in linux/etherdevice.h someday. */
 struct device *init_etherdev(struct device *dev, int sizeof_private,
                                                         unsigned long *mem_startp);

Unfortunately the prototype is already in linux/etherdevice.h as:

 extern struct device    * init_etherdev(struct device *, int);  

and the routine is defined in net_init.c as:

 struct device *
 init_etherdev(struct device *dev, int sizeof_priv)
 {

In tulip.c init_etherdev is called with 3 parameters. A suggestion was
made to simply comment out the #include <linux/etherdevice.h> line in
tulip.c. This works, and it will run (at least I haven't had problems
*yet* - keeping my fingers crossed. From a program correctness point
of view, it is wrong to pass three parameters to a routine that only
accepts two...it just leaves you open for undefined behavior.

Suggestions?

John

--
John Burton                      GATS, Inc.  


(804) 865-7491 (voice)           (804) 865-1021 (fax)

| The problem is that the tulip.c driver (v0.10) from Donald Becker does
| not work off the shelf with kernel versions > 1.3.4? (not sure where
| it broke). The problem is with a call to init_etherdev, which has a
| prototype in tulip.c of:
|
|  /* This will be in linux/etherdevice.h someday. */
|  struct device *init_etherdev(struct device *dev, int sizeof_private,
|                                                          unsigned long *mem_startp);
|  
| Unfortunately the prototype is already in linux/etherdevice.h as:
|
|  extern struct device    * init_etherdev(struct device *, int);  
|
| and the routine is defined in net_init.c as:
|
|  struct device *
|  init_etherdev(struct device *dev, int sizeof_priv)
|  {

The comment is right, it is in the header file. But isn't the TR
code in there as well? I haven't tried 1.3.x on a TR system, but I
was told it had the driver, I which case adding tulip.c might not be
needed.

Clarification someone?

| In tulip.c init_etherdev is called with 3 parameters. A suggestion was
| made to simply comment out the #include <linux/etherdevice.h> line in
| tulip.c. This works, and it will run (at least I haven't had problems
| *yet* - keeping my fingers crossed. From a program correctness point
| of view, it is wrong to pass three parameters to a routine that only
| accepts two...it just leaves you open for undefined behavior.

Agreed, although passing one parameter too many is a lot safer than
one too few, since it sends data not used vs. using data not sent.
The next question is, what is being used for the mem_startp address?
And do you need to be doing this at all?
--

I will support laws and technology which limit what you are allowed
to hear, if you will oppose laws and technology limiting what I am
allowed to say.