From owner-freebsd-hackers Mon Jul 24 05:15:10 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id FAA17682 for hackers-outgoing; Mon, 24 Jul 1995 05:15:10 -0700 Received: from crox.net.kiae.su (crox.net.kiae.su [144.206.130.72]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id FAA17663 for ; Mon, 24 Jul 1995 05:14:54 -0700 Received: by crox.net.kiae.su id QAA02818; (8.6.9/vak/1.8a) Mon, 24 Jul 1995 16:08:27 +0400 Date: Mon, 24 Jul 95 16:08:27 +0400 To: paul@netcraft.co.uk Cc: hackers@freebsd.org Message-ID: References: <199507211106.MAA02126@server.netcraft.co.uk> From: vak@cronyx.ru Subject: Re: [patch] if_lnc.c: support for PCI Lance Ethernet adapters added X-Mailer: BML [UNIX Beauty Mail v.1.39] Sender: hackers-owner@freebsd.org Precedence: bulk > > Some notes: > > 1. The Am79C970 chip has the same manufacturer id as the Am79C965 one. > > Probing for it was wrong in the original driver. > > Yeah, the AMD docs are wrong and if you contact AMD they'll even tell > what the id should be and it's still wrong :-) > > Every PCI chip I've seen uses the PCnet-32 ID as you've fuond out. I got it from the AMD Ethernet/IEEE 802.3 Family 1994 World Network Data Book/Handbook. According to specs, both 79c965 and 79c970 have the same values in CSR88-CSR89 registers: struct csr88 { unsigned logic_1 : 1; /* always 1 */ unsigned manufacturer_id : 11; /* 001h for AMD */ unsigned part_number : 16; /* 2430h for PCnet-32 and PCnet-PCI */ unsigned version : 4; /* silicon-revision dependent */ }; struct csr89 { unsigned part_number_hi : 12; /* 243h for PCnet-32 and PCnet-PCI */ unsigned version : 4; /* silicon-revision dependent */ unsigned reserved : 16; /* undefined */ }; Note than csr89.part_number_hi is always = csr88.part_number >> 4. > > 2. Loss of carrier message could happen too often on overloaded networks, > > it surely does not worth printing. > > If you're getting these errors then something is wrong. I'm not planning I agree that something is wrong, but it happens on every transmitted packet here in KIAE... > on removing that error message. The only error on lnc that possibly > needs thinking about is the heartbeat error since some cards don't > do the heartbeat test and you end up with a stream of such errors. I am now working on the FreeBSD-based router project, and PCnet-PCI will be the Ethernet-part of the hardware solution. And it would be not very great if the router would print a lot of diagnostic messages, even in the case of hardware errors. There is another thing in driver which probably should be fixed: if the ethernet cable is not attached, then the driver gets transmit timeouts and resets the adapter every 10 seconds. Better solution would be to detect the situation and print something like ``no cable attached''. I will work on it later. > > + switch (sc->nic.mem_mode) { > > + case DMA_FIXED: printf (", static DMA buffer mode"); break; > > + case DMA_MBUF: printf (", chained DMA buffers mode"); break; > > + case SHMEM: printf (", shared memory mode"); break; > > + } > > You've misunderstood this slightly, the DMA_FIXED version uses pre-allocated No, I understand it well, precisely :-) I consider the driver during attach() should print the full information about the hardware it detected and about all the modes it will use for that hardware. I added these printfs when tried to trace some errors in the driver, and found that dmesg gives not enough information. Probably, the phrases would be better, but it should print something here. :-) > > +/* > > + * PCI bus probe and attach routines for LANCE Ethernet controllers, > > + * by Serge V.Vakulenko, vak@cronyx.ru > > + */ > > I'll file this away and look at it all for 2.2. The pci code shouldn't OK > really go into the isa file. The bus specific probe code needs to be split > out and put in the proper place but this wouldn't be the only driver to > break the rules so.... Initially I tried to make it so. But the pci_attach needed an access to lnc_attach which is hidden, and I decided to put it into the main file. It seems that the pci level needs some redesign... Regards, Serge --- Serge Vakulenko Cronyx Ltd., Moscow Unix consulting and custom programming phone: +7 (095) 939-23-23 FreeBSD support fax: +7 (095) 939-03-00 Relcom network development