From johnandkatyterry@home.com Sat, 3 Mar 2001 22:12:15 -0800 Date: Sat, 3 Mar 2001 22:12:15 -0800 From: John Terry johnandkatyterry@home.com Subject: [3c509] 3c509.c driver won't compile This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C0A42F.01239060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi. I have a problem with the latest version of the 3c509.c driver source = code. It will not compile for me. I found it in: /usr/src/linux-2.2.16/drivers/net and tried to compile it using the compile instructions at the bottom of = the file. Since I am using Red Hat 7.0 I substituted kgcc in place of = gcc, and used the command: kgcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -c 3c509.c I then got a large bunch of error messages, as follows, with no compile: /usr/i386-glibc21-linux/include/asm/pgtable.h: In function = `get_pgd_slow': In file included from /usr/i386-glibc21-linux/include/linux/vmalloc.h:7, from /usr/i386-glibc21-linux/include/asm/io.h:102, from 3c509.c:70: /usr/i386-glibc21-linux/include/asm/pgtable.h:409: `PAGE_OFFSET_RAW' = undeclared (first use in this function) /usr/i386-glibc21-linux/include/asm/pgtable.h:409: (Each undeclared = identifier is reported only once /usr/i386-glibc21-linux/include/asm/pgtable.h:409: for each function it = appears in.) /usr/i386-glibc21-linux/include/asm/pgtable.h: In function = `pte_alloc_kernel': /usr/i386-glibc21-linux/include/asm/pgtable.h:498: `PAGE_OFFSET_RAW' = undeclared (first use in this function) /usr/i386-glibc21-linux/include/asm/pgtable.h:506: warning: control = reaches end of non-void function /usr/i386-glibc21-linux/include/asm/pgtable.h: In function `pte_alloc': /usr/i386-glibc21-linux/include/asm/pgtable.h:516: `PAGE_OFFSET_RAW' = undeclared (first use in this function) /usr/i386-glibc21-linux/include/asm/io.h: In function `virt_to_phys': In file included from 3c509.c:70: /usr/i386-glibc21-linux/include/asm/io.h:116: `PAGE_OFFSET_RAW' = undeclared (first use in this function) /usr/i386-glibc21-linux/include/asm/io.h:118: warning: control reaches = end of non-void function /usr/i386-glibc21-linux/include/asm/io.h: In function `phys_to_virt': /usr/i386-glibc21-linux/include/asm/io.h:125: `PAGE_OFFSET_RAW' = undeclared (first use in this function) /usr/i386-glibc21-linux/include/asm/io.h:127: warning: control reaches = end of non-void function /usr/i386-glibc21-linux/include/asm/io.h: In function `check_signature': /usr/i386-glibc21-linux/include/asm/io.h:184: `PAGE_OFFSET_RAW' = undeclared (first use in this function) 3c509.c: In function `set_multicast_list': 3c509.c:834: warning: unused variable `lp' Since I am just now starting to learn c programming and don't yet know = what all that stuff means, and don't know the meaning of the compile = command line parameters either, I am pretty much stuck. I did try to = compile with the Red Hat 7.0 gcc compiler also, but with no better = results. On my other Linux machine, also running Red Hat 7.0, I = successfully compiled pci-scan.c and tulip.c and pci-scan.h with no = problems, so I don't see what is stopping me here. Can someone help? = Thanks. John Terry. ------=_NextPart_000_0005_01C0A42F.01239060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi.
 
I have a problem with the latest version of the = 3c509.c=20 driver source code.  It will not compile for me.  I found it=20 in:
 
 /usr/src/linux-2.2.16/drivers/net
 
and tried to compile it using the compile = instructions at the=20 bottom of the file.  Since I am using Red Hat 7.0 I substituted = kgcc in=20 place of gcc, and used the command:
 
kgcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes = -O6 -c=20 3c509.c
 
I then got a large bunch of error messages, as = follows, with=20 no compile:
 

/usr/i386-glibc21-linux/include/asm/pgtable.h: In function=20 `get_pgd_slow':

In file included from = /usr/i386-glibc21-linux/include/linux/vmalloc.h:7,

from /usr/i386-glibc21-linux/include/asm/io.h:102,

from 3c509.c:70:

/usr/i386-glibc21-linux/include/asm/pgtable.h:409: `PAGE_OFFSET_RAW'=20 undeclared (first use in this function)

/usr/i386-glibc21-linux/include/asm/pgtable.h:409: (Each undeclared=20 identifier is reported only once

/usr/i386-glibc21-linux/include/asm/pgtable.h:409: for each function = it=20 appears in.)

/usr/i386-glibc21-linux/include/asm/pgtable.h: In function=20 `pte_alloc_kernel':

/usr/i386-glibc21-linux/include/asm/pgtable.h:498: `PAGE_OFFSET_RAW'=20 undeclared (first use in this function)

/usr/i386-glibc21-linux/include/asm/pgtable.h:506: warning: control = reaches=20 end of non-void function

/usr/i386-glibc21-linux/include/asm/pgtable.h: In function = `pte_alloc':

/usr/i386-glibc21-linux/include/asm/pgtable.h:516: `PAGE_OFFSET_RAW'=20 undeclared (first use in this function)

/usr/i386-glibc21-linux/include/asm/io.h: In function = `virt_to_phys':

In file included from 3c509.c:70:

/usr/i386-glibc21-linux/include/asm/io.h:116: `PAGE_OFFSET_RAW' = undeclared=20 (first use in this function)

/usr/i386-glibc21-linux/include/asm/io.h:118: warning: control = reaches end of=20 non-void function

/usr/i386-glibc21-linux/include/asm/io.h: In function = `phys_to_virt':

/usr/i386-glibc21-linux/include/asm/io.h:125: `PAGE_OFFSET_RAW' = undeclared=20 (first use in this function)

/usr/i386-glibc21-linux/include/asm/io.h:127: warning: control = reaches end of=20 non-void function

/usr/i386-glibc21-linux/include/asm/io.h: In function = `check_signature':

/usr/i386-glibc21-linux/include/asm/io.h:184: `PAGE_OFFSET_RAW' = undeclared=20 (first use in this function)

3c509.c: In function `set_multicast_list':

3c509.c:834: warning: unused variable `lp'

 

 

Since I am just now starting to learn c programming and don't yet = know what=20 all that stuff means, and don't know the meaning of the compile command = line=20 parameters either, I am pretty much stuck.  I did try to compile = with the=20 Red Hat 7.0 gcc compiler also, but with no better results.  On my = other=20 Linux machine, also running Red Hat 7.0, I successfully compiled = pci-scan.c and=20 tulip.c and pci-scan.h with no problems, so I don't see what is stopping = me=20 here.  Can someone help?  Thanks.

John Terry.

------=_NextPart_000_0005_01C0A42F.01239060-- From becker@scyld.com Sun, 4 Mar 2001 09:31:08 -0500 (EST) Date: Sun, 4 Mar 2001 09:31:08 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [3c509] 3c509.c driver won't compile On Sat, 3 Mar 2001, John Terry wrote: > I have a problem with the latest version of the 3c509.c driver source > code. It will not compile for me. I found it in: > > /usr/src/linux-2.2.16/drivers/net > > and tried to compile it using the compile instructions at the bottom of the file. Since I am using Red Hat 7.0 I substituted kgcc in place of gcc, and used the command: > > kgcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -c 3c509.c Add -I/usr/src/linux-2.2.16/include to compile line. If this doesn't fix the problem, you must update your glibc package -- the original Red Hat 7.0 one was bogus. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From johnandkatyterry@home.com Mon, 5 Mar 2001 06:43:41 -0800 Date: Mon, 5 Mar 2001 06:43:41 -0800 From: John Terry johnandkatyterry@home.com Subject: [3c509] 3c509.c driver won't compile Donald, Thanks for your timely and excellent support. And thanks for writing the drivers in the first place. After I read your reply, I tried it and it appears to work, in that the source code now compiles, but with a couple of warning messages. After I get off work tonight I will try to install and test the driver module to find out whether I will need to upgrade my glibc or not. After I read your e-mail response, I re-read the stuff on your web site about Red Hat 7.0 and realized that you had already covered the additional parameters to add to the compile command, if I had read more carefully in the first place. Thanks again John Terry ----- Original Message ----- From: "Donald Becker" To: "John Terry" Cc: <3c509@scyld.com> Sent: Sunday, March 04, 2001 6:31 AM Subject: Re: [3c509] 3c509.c driver won't compile > On Sat, 3 Mar 2001, John Terry wrote: > > > I have a problem with the latest version of the 3c509.c driver source > > code. It will not compile for me. I found it in: > > > > /usr/src/linux-2.2.16/drivers/net > > > > and tried to compile it using the compile instructions at the bottom of the file. Since I am using Red Hat 7.0 I substituted kgcc in place of gcc, and used the command: > > > > kgcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -c 3c509.c > > Add -I/usr/src/linux-2.2.16/include to compile line. > > If this doesn't fix the problem, you must update your glibc package -- > the original Red Hat 7.0 one was bogus. > > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters > Annapolis MD 21403 410-990-9993 > From johnandkatyterry@home.com Mon, 5 Mar 2001 23:09:56 -0800 Date: Mon, 5 Mar 2001 23:09:56 -0800 From: John Terry johnandkatyterry@home.com Subject: [3c509] how to use 3c5x9setup and el3-diag This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C0A5C9.64B27380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello. After reading the section on www.scyld.com about Linux Ethercard Status, = Diagnostic and Setup Utilities, I downloaded the source code for = 3c5x9setup and el3-diag and compiled them successfully, then tried to = use them. I'm not quite understanding the process. I have two 3c509 = cards in the same computer (one designated to connect to cable modem, = the other designated to connect to the internal network). I got the = impression that I should use el3-diag to see what the current configurations of my cards are, then = reset them as needed using 3c5x9setup. I tried several ways (with the = programs transported from one of my computers to the other on a floppy), = as follows: /mnt/floppy/3c5x9setup -w -P 0x300 -Q 10 /mnt/floppy/3c5x9setup -w -P 0x300 -Q 10 eth0 /mnt/floppy/3c5x9setup -w -P 0x300 followed by = /mnt/floppy/3c5x9setup -w -Q 10 /mnt/floppy/3c5x9setup -w -P 0x300 eth0 followed by = /mnt/floppy/3c5x9setup -w -Q 10 eth0 /mnt/floppy/3c5x9setup -w -P 0x300, 0x310 -Q 10, 11 eth0, eth1 But no matter how I tried to do it, I ended up with el3-diag showing = BOTH cards set to the exact same I/O port and IRQ setting, namely 0x310 = and IRQ 11. The el3-diag program reports both card 1 and card 2 as = eth0, also. Shouldn't there be a way to set one card to I/O 0x300 and IRQ 10 and set = the other one to I/O port 0x310 and IRQ 11? How can I do it? I'm = stumped. By the way, I'm using Red Hat 7.0 on both the computer I = compiled on and the other one I am trying to set up, if that makes any = difference. Also, the instructions on the web page say that the I/O = port option is -P, but when I run 3c5x9setup -? it says it is -p. Which = should I use? Thanks in advance John Terry ------=_NextPart_000_0005_01C0A5C9.64B27380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello.
 
After reading the section on www.scyld.com about Linux Ethercard = Status,=20 Diagnostic and Setup Utilities, I downloaded the source code for = 3c5x9setup and=20 el3-diag and compiled them successfully, then tried to use them.  = I'm not=20 quite understanding the process.  I have two 3c509 cards in the = same=20 computer (one designated to connect to cable modem, the other designated = to=20 connect to the internal network).  I got the impression that I = should=20 use
el3-diag to see what the current configurations of = my cards=20 are, then reset them as needed using 3c5x9setup.  I tried several = ways=20 (with the programs transported from one of my computers to the other on = a=20 floppy), as follows:
 
/mnt/floppy/3c5x9setup -w -P 0x300 -Q = 10
 
/mnt/floppy/3c5x9setup -w -P 0x300 -Q 10 = eth0
 
/mnt/floppy/3c5x9setup -w -P=20 0x300        followed=20 by      /mnt/floppy/3c5x9setup = -w -Q=20 10
 
/mnt/floppy/3c5x9setup -w -P=20 0x300 eth0       followed=20 by      /mnt/floppy/3c5x9setup = -w -Q 10=20 eth0
 
/mnt/floppy/3c5x9setup -w -P 0x300, = 0x310 -Q 10,=20 11 eth0, eth1
 
But no matter how I tried to do it, I ended up with el3-diag = showing BOTH=20 cards set to the exact same I/O port and IRQ setting, namely 0x310 and = IRQ=20 11.  The el3-diag program reports both card 1 and card 2 as eth0,=20 also.
 
Shouldn't there be a way to set one card to I/O 0x300 and IRQ 10 = and set=20 the other one to I/O port 0x310 and IRQ 11?  How can I do it?  = I'm=20 stumped.  By the way, I'm using Red Hat 7.0 on both the computer I = compiled=20 on and the other one I am trying to set up, if that makes any = difference. =20 Also, the instructions on the web page say that the I/O port option is = -P, but=20 when I run 3c5x9setup -? it says it is -p.  Which should I = use?
 
Thanks in advance
 
John Terry
------=_NextPart_000_0005_01C0A5C9.64B27380-- From bbc@misn.com Fri, 09 Mar 2001 14:51:00 -0600 Date: Fri, 09 Mar 2001 14:51:00 -0600 From: Bryan Campbell bbc@misn.com Subject: [3c509] Hrm . . . Question. Hello All - RedHat 7.0, patched, 2.4.2 kernel, ip_tables redirection to squid (transparent proxy application port:80->3128 ) Traffic load is around 200-400 connections per second. It is configured ( I believe ) as 100TX-FDX. Kernel generates the following . . . over and over and over . . . please translate TIA Bryan - Mar 10 04:43:13 cache01 kernel: eth0: Transmit error, Tx status register 82. Mar 10 04:43:13 cache01 kernel: Flags; bus-master 1, full 0; dirty 13134(14) current 13134(14). Mar 10 04:43:13 cache01 kernel: Transmit list 00000000 vs. ec9e82e0. Mar 10 04:43:13 cache01 kernel: 0: @ec9e8200 length 80000036 status 00010036 Mar 10 04:43:13 cache01 kernel: 1: @ec9e8210 length 8000024e status 0001024e Mar 10 04:43:13 cache01 kernel: 2: @ec9e8220 length 8000024e status 0001024e Mar 10 04:43:13 cache01 kernel: 3: @ec9e8230 length 80000036 status 00010036 Mar 10 04:43:13 cache01 kernel: 4: @ec9e8240 length 8000003e status 0001003e Mar 10 04:43:13 cache01 kernel: 5: @ec9e8250 length 80000042 status 00010042 Mar 10 04:43:13 cache01 kernel: 6: @ec9e8260 length 80000048 status 00010048 Mar 10 04:43:13 cache01 kernel: 7: @ec9e8270 length 8000002a status 0001002a Mar 10 04:43:13 cache01 kernel: 8: @ec9e8280 length 8000004a status 0001004a Mar 10 04:43:13 cache01 kernel: 9: @ec9e8290 length 80000036 status 00010036 Mar 10 04:43:13 cache01 kernel: 10: @ec9e82a0 length 800001d0 status 000101d0 Mar 10 04:43:13 cache01 kernel: 11: @ec9e82b0 length 80000036 status 00010036 Mar 10 04:43:13 cache01 kernel: 12: @ec9e82c0 length 80000036 status 00010036 Mar 10 04:43:13 cache01 kernel: 13: @ec9e82d0 length 8000044d status 8001044d Mar 10 04:43:13 cache01 kernel: 14: @ec9e82e0 length 80000299 status 00010299 Mar 10 04:43:13 cache01 kernel: 15: @ec9e82f0 length 8000018c status 0001018c Mar 10 04:43:14 cache01 kernel: eth0: Transmit error, Tx status register 82. Mar 10 04:43:14 cache01 kernel: Flags; bus-master 1, full 0; dirty 13218(2) current 13218(2). Mar 10 04:43:14 cache01 kernel: Transmit list 00000000 vs. ec9e8220. Mar 10 04:43:14 cache01 kernel: 0: @ec9e8200 length 8000024e status 0001024e Mar 10 04:43:14 cache01 kernel: 1: @ec9e8210 length 8000005a status 8001005a Mar 10 04:43:14 cache01 kernel: 2: @ec9e8220 length 80000042 status 00010042 Mar 10 04:43:14 cache01 kernel: 3: @ec9e8230 length 80000042 status 00010042 Mar 10 04:43:14 cache01 kernel: 4: @ec9e8240 length 80000324 status 00010324 Mar 10 04:43:14 cache01 kernel: 5: @ec9e8250 length 80000036 status 00010036 Mar 10 04:43:14 cache01 kernel: 6: @ec9e8260 length 80000073 status 00010073 Mar 10 04:43:14 cache01 kernel: 7: @ec9e8270 length 80000036 status 00010036 Mar 10 04:43:14 cache01 kernel: 8: @ec9e8280 length 8000004a status 0001004a Mar 10 04:43:14 cache01 kernel: 9: @ec9e8290 length 8000004a status 0001004a Mar 10 04:43:14 cache01 kernel: 10: @ec9e82a0 length 80000036 status 00010036 Mar 10 04:43:14 cache01 kernel: 11: @ec9e82b0 length 80000240 status 00010240 Mar 10 04:43:14 cache01 kernel: 12: @ec9e82c0 length 80000036 status 00010036 Mar 10 04:43:14 cache01 kernel: 13: @ec9e82d0 length 80000073 status 00010073 Mar 10 04:43:14 cache01 kernel: 14: @ec9e82e0 length 8000004a status 0001004a Mar 10 04:43:14 cache01 kernel: 15: @ec9e82f0 length 8000024e status 0001024e Mar 10 04:43:14 cache01 kernel: eth0: Transmit error, Tx status register 82. Mar 10 04:43:14 cache01 kernel: Flags; bus-master 1, full 0; dirty 13246(14) current 13246(14). Mar 10 04:43:14 cache01 kernel: Transmit list 00000000 vs. ec9e82e0. Mar 10 04:43:14 cache01 kernel: 0: @ec9e8200 length 8000024e status 0001024e Mar 10 04:43:14 cache01 kernel: 1: @ec9e8210 length 80000042 status 00010042 Mar 10 04:43:14 cache01 kernel: 2: @ec9e8220 length 8000024e status 0001024e Mar 10 04:43:14 cache01 kernel: 3: @ec9e8230 length 8000024e status 0001024e Mar 10 04:43:14 cache01 kernel: 4: @ec9e8240 length 80000042 status 00010042 Mar 10 04:43:14 cache01 kernel: 5: @ec9e8250 length 80000042 status 00010042 Mar 10 04:43:14 cache01 kernel: 6: @ec9e8260 length 80000042 status 00010042 Mar 10 04:43:14 cache01 kernel: 7: @ec9e8270 length 80000036 status 00010036 Mar 10 04:43:14 cache01 kernel: 8: @ec9e8280 length 80000036 status 00010036 Mar 10 04:43:14 cache01 kernel: 9: @ec9e8290 length 800001b8 status 000101b8 Mar 10 04:43:14 cache01 kernel: 10: @ec9e82a0 length 80000036 status 00010036 -- Bryan Campbell - Steelville Telephone Exchange 573-775-2111 From becker@scyld.com Fri, 9 Mar 2001 16:12:47 -0500 (EST) Date: Fri, 9 Mar 2001 16:12:47 -0500 (EST) From: Donald Becker becker@scyld.com Subject: [3c509] Hrm . . . Question. On Fri, 9 Mar 2001, Bryan Campbell wrote: > To: 3c509@scyld.com Wrong list -- this is a vortex question. > RedHat 7.0, patched, 2.4.2 kernel, ip_tables redirection to squid Ohh, a 2.4 question -- this should go to the kernel list as well. > Mar 10 04:43:13 cache01 kernel: eth0: Transmit error, Tx status register > 82. See http://www.scyld.com/network/vortex.html for your answer. You have an 0x82 Out of window collision. This typically occurs when some other Ethernet host is incorrectly set to full duplex on a half duplex network. The driver should recover from this failure, but it will still stop the card. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From bbc@misn.com Fri, 09 Mar 2001 16:45:59 -0600 Date: Fri, 09 Mar 2001 16:45:59 -0600 From: Bryan Campbell bbc@misn.com Subject: [3c509] Hrm . . . Question. OOps! My apologies . . . Thanks for the answer. B - Donald Becker wrote: > > On Fri, 9 Mar 2001, Bryan Campbell wrote: > > > To: 3c509@scyld.com > > Wrong list -- this is a vortex question. > > > RedHat 7.0, patched, 2.4.2 kernel, ip_tables redirection to squid > > Ohh, a 2.4 question -- this should go to the kernel list as well. > > > Mar 10 04:43:13 cache01 kernel: eth0: Transmit error, Tx status register > > 82. > > See > http://www.scyld.com/network/vortex.html > > for your answer. You have an > > 0x82 Out of window collision. > This typically occurs when some other Ethernet host is incorrectly > set to full duplex on a half duplex network. > > The driver should recover from this failure, but it will still stop the card. > > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters > Annapolis MD 21403 410-990-9993 -- Bryan Campbell - Steelville Telephone Exchange 573-775-2111 From andrewm@uow.edu.au Sun, 11 Mar 2001 23:21:50 +1100 Date: Sun, 11 Mar 2001 23:21:50 +1100 From: Andrew Morton andrewm@uow.edu.au Subject: [3c509] Re: [Fwd: Problem: EISA 3com card detection] > Hi, > While trying to run Linux kernel on an EISA boards with two > 3c592 EISA adapters I noticed that one of them is detected by both: > 3c509 and 3c59x drivers. This came to me... We only check the manufacturer ID, not the device ID so yes, the driver will detect 3c590's as well. I think that rather than trying to match the "known" 3c509 device IDs, it's safer to just exclude the known 3c59x IDs. You're the only person in the world who has an EISA 3c59x, let alone a 3c5x9 as well :) Could you please test this patch? --- linux-2.4.2-ac18/drivers/net/3c509.c Sun Mar 11 15:12:38 2001 +++ linux-ac/drivers/net/3c509.c Sun Mar 11 23:13:17 2001 @@ -216,6 +216,8 @@ if (EISA_bus) { static int eisa_addr = 0x1000; while (eisa_addr < 0x9000) { + int device_id; + ioaddr = eisa_addr; eisa_addr += 0x1000; @@ -223,6 +225,12 @@ if (inw(ioaddr + 0xC80) != 0x6d50) continue; + /* Avoid conflict with 3c590, 3c592, 3c597, etc */ + device_id = (inb(ioaddr + 0xC82)<<8) + inb(ioaddr + 0xC83); + if ((device_id & 0xFF00) == 0x5900) { + continue; + } + /* Change the register set to the configuration window 0. */ outw(SelectWindow | 0, ioaddr + 0xC80 + EL3_CMD); @@ -460,7 +468,7 @@ { const char *if_names[] = {"10baseT", "AUI", "undefined", "BNC"}; - printk("%s: 3c509 at %#3.3lx, %s port, address ", + printk("%s: 3c5x9 at %#3.3lx, %s port, address ", dev->name, dev->base_addr, if_names[dev->if_port]); } From ankry@green.mif.pg.gda.pl Mon, 12 Mar 2001 00:19:16 +0100 (CET) Date: Mon, 12 Mar 2001 00:19:16 +0100 (CET) From: Andrzej Krzysztofowicz ankry@green.mif.pg.gda.pl Subject: [3c509] Re: [Fwd: Problem: EISA 3com card detection] > > While trying to run Linux kernel on an EISA boards with two > > 3c592 EISA adapters I noticed that one of them is detected by both: > > 3c509 and 3c59x drivers. > > We only check the manufacturer ID, not the device ID so yes, > the driver will detect 3c590's as well. > > I think that rather than trying to match the "known" 3c509 > device IDs, it's safer to just exclude the known 3c59x IDs. > > You're the only person in the world who has an EISA > 3c59x, let alone a 3c5x9 as well :) I'd rather think I am the only trying to use both drivers together with an EISA 3c59x adapter plugged :) > Could you please test this patch? I can't at this moment. But I'll try next week. As I see the patch is equivalent to mine (from my point of view). > --- linux-2.4.2-ac18/drivers/net/3c509.c Sun Mar 11 15:12:38 2001 > +++ linux-ac/drivers/net/3c509.c Sun Mar 11 23:13:17 2001 [...] > @@ -223,6 +225,12 @@ > if (inw(ioaddr + 0xC80) != 0x6d50) > continue; > > + /* Avoid conflict with 3c590, 3c592, 3c597, etc */ > + device_id = (inb(ioaddr + 0xC82)<<8) + inb(ioaddr + 0xC83); > + if ((device_id & 0xFF00) == 0x5900) { > + continue; > + } > + But some remarks concerning the driver: - 3Com did not released any other EISA adapter than 3c579 based on this chip (and supported by this driver). So where is the problem with your/my patch ? -- if in "unknown" reported by 3c579 device_id - I am promissed to receive a 3c579 EISA adapter next week, so will be able to perform tests. -- if in "not modifying stable kernel sources" - then no comments. - Alan suggested me in a private mail that we need an EISA API in the kernel, like the MCA API. What is your opinion ? IMO using any EISA API here would require well known device_id. - Do you maintain the 3c509 kernel driver ? As I see it lacks some __init / __initdata. (A patch follows; PCMCIA 3c589 uses a separate driver - so no hotplug/__devinit here) Andrzej ************** __init 3c509 PATCH ************************************* --- linux-2.4.2ac14/drivers/net/3c509.c Thu Mar 8 21:41:56 2001 +++ linux/drivers/net/3c509.c Sun Mar 11 23:49:57 2001 @@ -41,7 +41,6 @@ v1.16 2/3/98 Different ID port handling to avoid sound cards. -djb */ -static char *version = "3c509.c:1.16 (2.2) 2/3/98 becker@cesdis.gsfc.nasa.gov.\n"; /* A few values that may be tweaked. */ /* Time in jiffies before concluding the transmitter is hung. */ @@ -61,6 +60,7 @@ #include #include #include +#include #include #include #include @@ -71,6 +71,9 @@ #include #include +static char *version __initdata = + "3c509.c:1.16 (2.2) 2/3/98 becker@cesdis.gsfc.nasa.gov.\n"; + #ifdef EL3_DEBUG static int el3_debug = EL3_DEBUG; #else @@ -137,7 +140,7 @@ struct sk_buff *queue[SKB_QUEUE_SIZE]; char mca_slot; }; -static int id_port = 0x110; /* Start with 0x110 to avoid new sound cards.*/ +static int id_port __initdata = 0x110; /* Start with 0x110 to avoid new sound cards.*/ static struct net_device *el3_root_dev = NULL; static ushort id_read_eeprom(int index); @@ -158,7 +161,7 @@ int id; }; -static struct el3_mca_adapters_struct el3_mca_adapters[] = { +static struct el3_mca_adapters_struct el3_mca_adapters[] __initdata = { { "3Com 3c529 EtherLink III (10base2)", 0x627c }, { "3Com 3c529 EtherLink III (10baseT)", 0x627d }, { "3Com 3c529 EtherLink III (test mode)", 0x62db }, @@ -169,7 +172,7 @@ #endif /* CONFIG_MCA */ #ifdef CONFIG_ISAPNP -static struct isapnp_device_id el3_isapnp_adapters[] = { +static struct isapnp_device_id el3_isapnp_adapters[] __initdata = { { ISAPNP_ANY_ID, ISAPNP_ANY_ID, ISAPNP_VENDOR('T', 'C', 'M'), ISAPNP_FUNCTION(0x5090), (long) "3Com Etherlink III (TP)" }, @@ -197,7 +200,7 @@ static int nopnp; #endif /* CONFIG_ISAPNP */ -int el3_probe(struct net_device *dev) +int __init el3_probe(struct net_device *dev) { struct el3_private *lp; short lrs_state = 0xff, i; @@ -502,7 +505,7 @@ /* Read a word from the EEPROM using the regular EEPROM access register. Assume that we are in register window zero. */ -static ushort read_eeprom(int ioaddr, int index) +static ushort __init read_eeprom(int ioaddr, int index) { outw(EEPROM_READ + index, ioaddr + 10); /* Pause for at least 162 us. for the read to take place. */ @@ -511,7 +514,7 @@ } /* Read a word from the EEPROM when in the ISA ID probe state. */ -static ushort id_read_eeprom(int index) +static ushort __init id_read_eeprom(int index) { int bit, word = 0; -- ======================================================================= Andrzej M. Krzysztofowicz ankry@mif.pg.gda.pl phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk From andrewm@uow.edu.au Mon, 12 Mar 2001 00:33:34 +0000 Date: Mon, 12 Mar 2001 00:33:34 +0000 From: Andrew Morton andrewm@uow.edu.au Subject: [3c509] Re: [Fwd: Problem: EISA 3com card detection] Andrzej Krzysztofowicz wrote: > > ... > > As I see the patch is equivalent to mine (from my point of view). Yes, it is. > > --- linux-2.4.2-ac18/drivers/net/3c509.c Sun Mar 11 15:12:38 2001 > > +++ linux-ac/drivers/net/3c509.c Sun Mar 11 23:13:17 2001 > [...] > > @@ -223,6 +225,12 @@ > > if (inw(ioaddr + 0xC80) != 0x6d50) > > continue; > > > > + /* Avoid conflict with 3c590, 3c592, 3c597, etc */ > > + device_id = (inb(ioaddr + 0xC82)<<8) + inb(ioaddr + 0xC83); > > + if ((device_id & 0xFF00) == 0x5900) { > > + continue; > > + } > > + > > But some remarks concerning the driver: > - 3Com did not released any other EISA adapter than 3c579 based on this chip > (and supported by this driver). So where is the problem with your/my patch ? > -- if in "unknown" reported by 3c579 device_id - I am promissed to receive > a 3c579 EISA adapter next week, so will be able to perform tests. > -- if in "not modifying stable kernel sources" - then no comments. Well, my problem is that I don't know what all the 3c509 device ID's are. The data sheet doesn't tell us. So I thought that the minimum impact, least-risk approach was to simply skip over the EISA devices which we *know* to cause problems - namely 0x59xx. > - Alan suggested me in a private mail that we need an EISA API in the > kernel, like the MCA API. What is your opinion ? > IMO using any EISA API here would require well known device_id. Probably. But there is very little interest in or motivation to work on [E]ISA nowadays. > - Do you maintain the 3c509 kernel driver ? Well... I have one, so I am keeping an eye out for problems with the driver. There are vey few. > As I see it lacks some __init / > __initdata. (A patch follows; PCMCIA 3c589 uses a separate driver - so no > hotplug/__devinit here) That makes sense - thanks. I'll include that in the device_id patch.