isapnp.conf
file.
This has been reported as a side effect of upgrading Slackware 3.4 to 3.5. I'm sorry, but it must be a bug in the distribution, as upgrading from the isapnptools source will not do this. Please notify your distribution supplier as they should not stomp on user generated files during a package update.
If you get the latest isapnptools, it should be possible to
generate a good isapnp.conf
file without editting, though you may
need cleverer boot up scripts to discover the resource allocations.
If you are updating using a non source version of isapnptools, I suggest
you make a copy of the /etc/isapnp.conf
and /etc/isapnp.gone
files if present, just in case they get overwritten.
You may want to regenerate the /etc/isapnp.conf
file to
take advantage of new keywords which may have been introduced. In this
case run pnpdump -c
and capture the output, then edit it in
comparison to the previous /etc/isapnp.conf
file to make the
hardware configuration the same.
Since version 1.16 of isapnptools, resource checking has been added. If your isapnp.conf file contained resource errors, these would have been invisible until you upgraded isapnptools. Note that due to bugs in the resource checking in versions prior to 1.19, resource conflicts may be indicated erroneously.
Adding the line
(CONFLICT (IO WARNING)(IRQ WARNING)(DMA WARNING)(MEM WARNING))
near the beginning of the isapnp.conf file would allow you to restore
the previous behaviour.
This could be due to you specifying a READPORT address which is no longer free.
See also Pnpdump reports "No boards found"
This has been reported with isapnp v1.18. It appears the default readport of 0x203 clashes somehow with the 2.4.1 kernel, even though it has been compiled without kernel PnP support. The solution was to change the readport address to 0x273 (which has been the default since version 1.19).