It works! Of course, as if 10megabit wasn't bad enough, its an ISA card...

So we can put this one in the books as a buggy PCI bus/bad PCI probe?

> So we can put this one in the books as a buggy PCI bus/bad PCI probe?

I noticed a lot of the options for configuring "PCI quirks" are gone in kernel 2.4.x.

Tempting to blame the motherboard but for the fact that not only did it work for kernel 2.2.x, but back in 2000 the motherboard did as best can be expected as a Windows 95 system as well. Also, correspondance with another person indicates they do have a PCI NIC working under a 2.4.x kernel, so at this point I'm thinking maybe its even particular to whichever version of BIOS is flashed in or maybe even something so stupid as what order the cards are inserted in. I've asked him to mail me a copy of /usr/src/linux/.config (he has rebuilt his own kernels).

What happened to PCI Quirks in 2.4.x? they're still all thru the code, but I cant tell if they are stragglers or if they are always activated - just that the #defines are gone for it. This implies either that the support was removed or that its being forced on people who may not need it now. ???

Again my first attempts would be PCI access mode to BIOS. And the quirks were mostly to do with buggy IDE chipsets iirc.

Setting PCI access mode to BIOS didnt work either, just tried. The person who I wrote to indicated surprise that I had any sort of problems at all.

Just noticed that I can set and unset the arp and promisc flags, as well as verify their setting - but does this actually do any communication with the card prior to ifup, or does it just toggle a flag somewhere in RAM? Also, the kernel is able to successfully determine the card's HWaddr as well as its interupt, so

OH HEY WAIT A MINUTE!

Kernel 2.4.20 (with PCI access set to BIOS) shows the base address of the card as 0x6000. Kernel 2.2.23 (with PCI access set to Any) shows the base address at 0xe800. This looks like the first promising difference I've noticed, but now the question is what to actually do about it. Evidently 2.4.x is guessing wrong. Or is this something thats set up during boot?

And uh, theres evidently no support for "tmpfs" in 2.2.x, so I've discovered both hope and motivation in the last half hour!

# ifconfig eth0 io_addr 0xe800
SIOCSIFMAP: Operation not supported.

Gee.

In /var/log/messages, it shows up as
2.4.20: 0xe0856000
2.2.23: 0xe800

I could see how a difference like that might lock the box up ...

OK. That's news. How is your BIOS handling pnp setup? Is it set to auto or has someone set something funky in the PCI configuration menu? Reboot and poke around your BIOS setup .

As a workaround you could try and pass some options to the card in the modprobe statement. 'modprobe tulip io=0xe800' but if the kernels' PCI handler is looking at 0x6000, well I don't know what toexpect. Have a fire extinguisher handy or at least get some photos for finegan.

I think this os going to be the longest thread for a K6/2 ever on this site. It should be brozed and sent to AMD regardless of a solution.

I backed up 8139too.c to 8139.cold, and hard-coded 0xe800 as the base address. Recompiled the module, removed the old one, installed the new one. Verified that ifconfig eth0 reported 0xe800, and then proceeded to lock the box up same as always with ifup eth0. Argh. OK so hard-coding the answer obviously isnt the right way to do it, but it was worth a shot.

I put the original module back.

modprobe 8139too io=0xe800
(command completes with no responces)
ifconfig -a returns that the base address is 0x6000

The 8139 driver is a completely different file, with a big banner across the top instructing the world to not contact the author of the presumably the other one. An understandable disclaimer, I think! The tulip driver is completely different entity altogether. Its a directory now, even.


Also, from what I've read just about all of the PCI drivers have been totally rewritten in such a manner that the kernel rather than the driver probes (I think). Since the IDE is connected via the PCI bus and works great, as is the SVGA, its probably not purely a PCI problem. Also, chainging the BIOS settings(PNP, reserved IRQs, etc), changing the kernel access mode (BIOS, Direct, Any) has no effect at all. So maybe time to grep thru the source some more and figure out why its reading the wrong values instead of just that it is. Ugh.

What happened when you brought the interface 'up' ? Crash?
Any log barf when you pass those options?
Waht happens when you pass incorrect options?

modprobe modulename io=0xe800 alias eth0
ifconfig eth0 ip.add.res.ss sub.net.arg up

No log barf at all. The crash is similar in appearance to what one might expect if the CPU were plucked from the motherboard: nothing responds at all. No capslock, no mouse, no ctrl-alt-del, no magic keys, video remains exactly as it was the instant it seized. No HD activity of any kind afterwards either.

I turned on a define for debugging in 8139too.c and the module doesnt compile because of a syntax error on line 1902. Guess that option hasn't been tried before eh? Fixed, and now it gives me a couple new lines in dmesg, but nothing useful. Same problem with the address too..

Despite differences in base_addr reported by ifconfig eth0 between kernel 2.2.x and kernel 2.4.x, the io addresses reported by cat /proc/pci both correctly read 0xe800! So in kernel 2.4.x, there is an inconsistency between the address reported by cat /proc/pci and that reported by ifconfig eth0.

http://ftp2.cableaz.com/~jkenner/information.tar.gz

a copy of my .config, and outputs of ifconfig eth0 and /proc/pci for both kernel 2.2.23 and 2.4.20.

I highly recommend both, I'll post those pics in a heartbeat. The quick solution junky in me still thinks that the issue lies in the pci bridge somewhere. If it were networking code why would it work with an ISA card, but reagardless, serial console with tail -f /var/log/messages, or try the pre-emtible kernel patch?

Cheers,

Finegan

Sometime later last year, I was able to locate someone who had the exact same motherboard, exact same CPU, and same RedHat version, never had a problem.

He did, however, have a newer BIOS version.

By then, I had given up, however... I'm gonna bump this thread because I am dragging that old motherboard out of storage for a project.

I popped the heat spreader on the K6-2, put the old stock Duron 1.1 heatsink I had laying around on it, set the voltage down to 2 volts and the clockspeed to 166 (66*2.5). Oh yah, theres no fan on that heatsink. Or the (bare, open - I'm working on a solution here still) power supply board. Oh, and no hard drive - 1GB of SanDisk CF via IDE - just got it this week.

In other words, no moving parts. Dead silent. Except I never did flash that BIOS...

So anyways, a few months ago I tried installing an old slackware disc I had around: Kernel 1.2.x bailed on me, oddball CF access errors into a 64MB flash card. I've seen the same error reported for some type of CDROM or DVDROM (dont remember which) and know its resolved in newer kernels...

Anyways, I dropped "just enough to boot" RH9 into that 64MB of space a few months ago and it .. worked. So apparently the kernel people have patched around this extremely rare BIOS based conflict or problem at some point too. Curiouser and curiouser. At least with the 1GB card I can do a fullish install of just about anything other than XP (ick)