Messages in this thread | | | Date | Sun, 13 Jul 1997 20:24:57 +0200 | From | Franz Sirl <> | Subject | Re: Tulip driver & 2.0.30-pre-patch-2 |
| |
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.
| |