Date: Mon, 24 Jul 95 16:08:27 +0400 From: vak@cronyx.ru To: paul@netcraft.co.uk Cc: hackers@freebsd.org Subject: Re: [patch] if_lnc.c: support for PCI Lance Ethernet adapters added Message-ID: <ACxqu4myd2@crox.net.kiae.su> References: <199507211106.MAA02126@server.netcraft.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 <vak@cronyx.msk.su>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ACxqu4myd2>