This is an informal collection of information about network hardware and bug work-arounds.
Here is a quick index:
This message should only occur with kernels 1.0.0 to 1.0.3 or so.
These are mostly harmless messsages produced by error-checking code around line 277 in 8390.c. The root cause is usually some part of the system shutting off interrupts for longer than the net code expects, or that your network is exceptionally busy.
This section of code that produces this message combines a check for unrecognized hardware return values with a check to prevent unlimited work being done during a single interrupt, which might indicate a hardware failure. A kernel patch (1.0.3 I think) increased this 'boguscnt' check from '5'(four actions per network interrupt) to '9' (eight actions per interrupt). This prevents the error message for almost all systems.
Due to my misinterpretation of the 8390 documentation, all drivers based on the 8390 core (3c503, WD80*3, SMC Ultra, NE*000, HP PCLAN and others) do not receive multicast packets in promiscuous mode.
Only network monitoring programs use promiscuous mode, and protocols that use multicast packets are currently rare, so very few people will encounter this problem. Kernels after 1.1.24 already include the following fix:
Ohhh, bad. This "can't" happen when everything is working correctly.
The "DMA" that this message is referring to is the DMA controller internal to the NE2000. It has nothing to do with the motherboard DMA channels. (A few NE1000 clones do allow the two DMA systems to be connected, but DMA results in *slower* system operation when transferring typical ethernet traffic.)
What is likely happening is an interrupt conflict or a noisy interrupt line, causing the device driver to start another packet transfer when it thinks that it has locked out interrupt from the card.
A remote possibility is that you are running an old kernel, or mixing versions of 8390.c and ne.c.
Hmmm, adding a card often results in IRQ conflicts and occasionally results in electrical noise problems. Try swapping card in their slots or changing the interrupt line. (Note: uppen IRQs are often quieter than lower ones! Try IRQ11 or IRQ15.)
I've order five machine in two batches. The first machine was ordered in early January and had the following problems
The lastest four arrived in mid-April and have none of these problems.
Not only was the price great, it was also the only reasonable subnote that was shipping with a 340M drive.
BTW, the first was ordered with a 4M memory expansion because the 8M memory expansion cards were not due to be available until "late February". The recent batch was ordered with 8M modules, but they arrived with only the base 4M because the 8M expansion modules still were not available! Rule: if it's not "in stock for immediate delivery", it doesn't exist. People that ordered IBM Thinkpad 750s back in the fall are just getting them now!
The Other Rule: divide the advertised battery life by two.
(This is a question about why the kernel function snarf_region() only works up to 0x3fff, and why drivers don't bother allocating higher I/O regions.)
The snarf_region() function shares some of the same bitmap functions as the ioperm() call, and only marks the I/O ports used in the 0x0 - 0x3ff (the original PC I/O space). I claim (I wrote the ioperm() and *_region() code, so I feel the need to defend this :->) that this is actually the right thing to do, as some (many?) I/O devices deliberately ignore the upper I/O address bits because some ancient broken PC software required it.
The '8390' part of the 3c503 driver has special code to automatically switch interfaces around line drivers/net/8390.c:156 in version 1.0. This code was added so that the ethercard could automatically configure itself for the network in use. This turned out to be a not-quite-perfect implementation of an otherwise good idea, and around version 1.0.2 the code was changed to only switch interfaces if *no* packets had yet been transmitted without error, rather than anytime in the session.
Acckkkk! A 40 meter printer cable is *way* beyond the specs for even output-only printer traffic! It's unreasonable to expect bidirectional traffic to work on a cable this long.
You should switch to ethernet for this link: not only is ethernet faster, cheaper and more reliable, it's also much *safer* for a connection this long. 10base2 provides at least 600V of isolation if the 'T' taps are insulated, and 10baseT provides over 1500V isolation with fully enclosed contacts. That's protection against lightning hits, ground loops, ground noise and ground offsets that you *need*.
Ooops, when I put in the HP-J2405A special-case code I didn't realize that they were going to come out with an incompatible implementation. The 'lance.c' driver *always* uses the value in the setup register of an HP Lance implementation. In this case it's reading an invalid 0xff value.
That's the right temporary solution, and the right long-term attitude. I'll see if I can find someone at HP that knows how to tell the difference between a J2405A and a Vectra. If there isn't an easy way, I'll just ignore a 0xff setup value and do autoIRQ/autoDMA instead.
The 3c509 driver already supports multiple 3c509 cards on the *ISA* bus. Look in the probe code for the variable 'current tag'. Just make certain that "eth1" and "eth2" are set to probe anywhere (address '0'), not just a specific I/O address.
A side note: the 3c509 probe doesn't mix well with the rest of the probes. It's difficult to predict a priori which card will be accepted "first" -- the order is based on the hardware ethernet address. That means that the ethercard with the lowest ethernet address will be assigned to "eth0", and the next to "eth1", etc. If the "eth0" ethercard is removed, they all shift down one number.
Another note: the 3c509 driver will fail to find multiple EISA-mode 3c509s and 3c579s. The file net/drivers/3c509.c needs to be modified to accept multiple EISA adaptors. This change is already made in later 1.1.* kernels. Around line 94 make the following changes
Please let me know if this works for you.
The EExpress driver is still in alpha test -- it only works on some machines, generally slower 386 machines.
Several people are actively working on the driver, but a stable release is at least several months away.
This is a standard feature of all modern IDE disks. I have a short program (appended) that I use to do the same thing on laptops. A user-level program is a poor way to do this, but I got tired of patching it into my own kernels and I didn't feel I could maintain an Official Kernel Feature.
This is almost normal: the Linux kernel gets upset when the disk doesn't respond immediately. It resets the controller, and by that time the disk has spun up. One annoying misfeature is that the disk drive posts an interrupt when it goes into spin-down mode, the kernel doesn't know where the interrupt is from, and 'syslog' immediately spins the disk back up. The quick, sleazy solution is to configure 'syslog' to ignore those messages.
Hmm, I've never experienced this.
Anyway, here is my short program to put the disk into standby-timer mode. It takes a single optional parameter, the number of seconds to wait before going into standby mode.
The 3c589 uses 16 I/O locations and no memory locations. That makes it much easier to configure than a I/O + memory card.
A quick way to check if the 3c589 is correctly mapped in to run
Until Xircom releases programming information, no non-standard (i.e. non-modem) product can be supported.
The "generic" part of the PCMCIA support will only handle socket enabling. That's all that's needed for devices that adhere to a common register standard, like modems, but ethernet adaptors differ wildly.
You should give Xircom a call and ask for the Linux driver. Tell them that it says right on the box that it "supports all popular operating systems". When they tell you that they don't have a device driver, ask them for the programming specifications:->.
I don't have access to a MCA machine (nor do I fully understand the probing code) so I never wrote the mca_adaptor_select_mode() or mca_adaptor_id() routines. If you can find a way to get the adaptor I/O address that assigned at boot time, you can just hard-wire that in place of the commented-out probe. Be sure to keep the code that reads the IRQ, if_port, and ethernet address.
Sorry I can't be more helpful.