Re: Tulip driver & 2.0.30-pre-patch-2

Franz Sirl (Franz.Sirl@munich.netsurf.de)
Sun, 13 Jul 1997 20:24:57 +0200


At 23:53 12.07.97 -0700, Y0SHi wrote:
>
> I recently tried the 2.0.30-pre-patch-2 which was available
> on ftp.kernel.org under davem's directory, and have a little
> "complaint" to make about it.
>
> Call me flaming, but as a sys-admin, I think I have a right to
> be in such a state. I'm getting a little tired of people tinker-
> ing with the DEC Tulip (21041) driver. I've seen 2.1.xx kernels
> return weird information on an ifconfig, such as that the card
> has sent out -382928429138 packets, but yet (!!!) still continues
> to work as if nothing was flawed. Too odd for me.
>
> Myself, like many sys-admins out there, use Kensington EtherRx
> cards, which use the DEC 21041 chipset. Excellent chip, too.
> These cards work flawlessly under 2.0.30 (without modifications
> or pre-patches installed). No errors. No weirdness. Nothing but
> pure happiness comes from the kernel. These are PCI cards: in
> my case, PnP is obviously disabled.
>
> However, when pre-patch-2 is installed, the kernel decides to
> inform us that it has heartburn.
>
> Easy solution: Don't install the pre-patches. Wise idea, 'cept
> for the fact that I've seen strange occurances of "swapper"
> giving kernel errors. This hasn't happened more than twice,
> and the machine doesn't even halt (it continues to work as if
> nothing ever happened). Therefore I was hoping the pre-patches
> fixed this problem.
>
> I've included a log taken from /var/log/syslog when our
> main server booted up with the pre-patch-2 installed against
> a 100% clean 2.0.30 kernel. Take a look at the ethernet side
> of the log.
>
> gcc 2.7.2.1, libc 5.4.23.
>
> Any comments or feedback is appreciated greatly. If you need
> more information from me, just Email.

Hmm, for most (95%) people this version of the driver works better than the
one from 2.0.30. I see you are using a 386/486 system, eventually the
problem is related due to the different alignment of the PCI accesses
between the old and the new driver. I am currently preparing a cleaned up
version of tulip.c for inclusion into 2.0.31
(<http://homepages.munich.netsurf.de/Franz.Sirl/tulip.c-pre-2.0.31-6>),
which includes the following lines:

#if defined(MODULE)
/* When a module we don't have 'x86' to check. */
outl(0x00200000 | 0x4800, ioaddr + CSR0); /* align 8,
burstsize 8 */
#else
#if defined(__i386__)
switch (x86) {
case 3:
i = 0x4800; /* align 8, burstsize 8 */
break;
case 4:
i = 0xC000; /* align 32, burstsize unlimited */
break;
case 5:
i = 0x8000; /* align 16, burstsize unlimited */
break;
case 6:
i = 0x8000; /* align 16, burstsize unlimited */
break;
default:
i = 0x8000; /* align 16, burstsize unlimited */
break;
}

outl(0x00200000 | i, ioaddr + CSR0);

if (x86 <= 4)
printk(KERN_INFO "This is a 386/486 PCI system, setting cache
alignment to %x.\n",
0x00200000 | i);
#endif
#endif

The driver from 2.0.30 always used 0xC000, the new one uses 0x4800. I have
already modified my version for you to use 0xC000 when compiled into the
kernel for 486. If you are using the module and/or 386, you have to change
the corresponding values yourself.
Other possible values you can try: 0xC800, 0xE000, 0x5000, 0x8800, 0x9000.

Please report your results.

Ciao,
Franz.