I am almost finished with configuring my second box with Slackware 10.1 and KDE 3.3.2. One remaining obstacle before I try updating to 10.2 and KDE 3.4.3. The 2.4.28 kernel will not scan ISA PNP devices---and my modem is such a device.

Scanning works just fine in my first box. To expedite my building of this box I copied the current 2.4.28 kernel that I compiled about a year ago to my second box (the boxes are similar). Other than not scanning ISA PNP devices, the logs show that all is running very well.

I suspect the scanning problem is that although I copied the kernel, I still need to run some sort of nominal recompile with the kernel using the config file from my first box, where I enabled ISA PNP support. Copying the config file is easy, but do I need to run every step of recompiling? For example, I don't need to make a new bzimage, but only get the module dependencies updated.

I toyed with recompiling a year ago and then only just enough to add some minor tweaks to my first box. Thus, my memory and notes of that experience are untrustworthy. I'm still green behind the ears trying to understand the kernel recompiling process. After copying the config file from Box 1 to Box 2, what else do I need to do? Is make dep and depmod -a sufficient or do I need to run make install, make modules, make modules_install, etc. In other words, I'm asking whether I can skip certain steps---is there a shortcut method to quickly configuring my second box?

Thanks again.

you probably need to run make oldconfig first.

also check the bios to make sure that pnp is enabled on the isa slots.

Doesn't seem to matter how I toggle that option in the BIOS.

After further investigation, recompiling is not the problem. The kernel simply is not probing isa-pnp. Why?

After some hair-pulling and bleary eyes I finally recognized that nowhere in the boot sequence is the command to modprobe isa-pnp directly called. In my first box, probing isa-pnp is indirectly performed when the probing for the sound card initializes. In that box I use an older isa pnp AWE32 soundblaster. Thus, my /var/log/messages log always shows that the kernel is probing for isa-pnp devices. This is misleading.

In my second box, I have no device installed that can similarly modprobe isa-pnp in such an indirect manner. The only isa-pnp device in that box is my modem. All other cards are PCI or AGP. I know the modem is functional and there are plenty of clues, but the kernel never modprobes isa-pnp and hence, the card does not exist with respect to "seeing" the card.

I manually performed a modprobe isa-pnp and lo and behold, /var/log/messages finally showed the isa-pnp probe and that the modem card exists.

I next asked why doesn't Slack do this automatically? I checked /etc/rc.d/rc.modules and there is no direct call to modprobe isa-pnp.

I added the line to modprobe isa-pnp to rc.modules. At least now my modem is recognized. That at least resolves the issue of the kernel not probing for isa-pnp devices. But all is not yet resolved.

When I open KPPP and query the modem, I never succeed. I always receive a modem is busy response. But I will start a new thread for that.

For now, my primary question for this thread is why doesn't Slack directly probe isa-pnp? Is this an oversight that PV needs to know about? If not, then how is this issue more easily resolved in the future for other people who might use isa-pnp cards that are not sound cards?

Slackware has always tried to be streamline and not load/search/install every possible configuration. my guess is that probing for isa stuff on non isa boards may cause lockups, and since the majority of boards now days don't have isa slots that is the default.
adding the isa-pnp to modules is an easy fix, even if it wasn't evident at first.

One reason Slack is popular is the distro runs well on "older" hardware. A reasonable presumption, therefore, is that many of these people use boxes with ISA slots. And rc.modules is filled with support for older, almost obsolete devices.

I agree, but often I'm thinking in terms of usability.

In this particular instance, I ran into a box anomaly that caused the kernel to fail to probe for isa-pnp devices. Just one of those quirks having only one isa-pnp device that had no references in modules.conf and nothing in rc.modules to trigger the probing.

Most of the rc.modules is commented out and I think a similar approach works for these isolated cases like mine in which an isa-pnp device is installed but is not scanned or probed. So I've added the following to the end of my rc.modules:


#### Miscellaneous ISA Plug-and-Play Support ####
# Despite all other modules being loaded, possibly nothing indirectly called
# or loaded the isa-pnp module. Usually the isa-pnp module is called indirectly
# through another device, typically sound cards. So we perform the following as
# a last resort. Enable this only if you have an isa-pnp card installed that is
# not being scanned or probed by the kernel upon booting. Look in /var/log/messages
# for references to "kernel: isapnp: Scanning for PnP cards..." If you have a
# isa-pnp card installed and that message is missing then enable this section.
echo "Probing for ISA Plug-and-Play cards."
/sbin/modprobe isa-pnp

Hopefully this might help somebody else someday.

Problem Solved

I wanted to leave a note here that I solved the problem because I dislike reading unfinished problem-resolution threads.

My original problem was that I could not get my US Robotics ISA Plug-and-Play modem to work with Slack.

The modem in my primary box is ISA, but uses old-fashioned, dependable jumpers. Therefore this particular card was actually my first experience playing with a PnP modem.

I knew that the PnP modem worked. A Knoppix CD proved the card worked. Lots of troubleshooting, lots of online reading, but no answer why not now. The only clue was, as I originally posted above, that the kernel did not seem to be scanning or probing for ISA PnP devices. Thus began my frustrations of the past two days.

Because of that previous observation, as seen by my previous post, I thought I had to manually modprobe isa-pnp. Superficially this effort seemed to slap the card upside its proverbial head, but still no response when I queried the modem in KPPP.

After playing with the isapnp tool, I knew that the modem was responding. The interesting quirk to all of this is the modem insisted upon using port 0x2e8 and interrupt 3 despite being assigned to ttyS2, which normally runs at port 0x3e8 and IRQ 4.

At this point I more or less figured that the problem lied there. I just did not know what to do to solve the problem. After much trial and error, however, I finally got the modem to work.

The 2.4.x kernel is supposed to be PnP-ready, but I nonetheless still had to run the isapnp /etc/isapnp.conf command in /etc/rc.S. This seemed necessary to get the modem willing to play. I then added a line to /etc/serial.conf:

/dev/ttyS2 uart 16550 port 0x2E8 irq 3

Then, when /etc/rc.d/rc.serial ran, ttyS2 would be reconfigured to match the configuration demanded by the modem. And I have to run these config changes in this sequence or the modem refuses to work.

Additional testing showed that I also do not need to modify /etc/rc.d/rc.modules as I thought in my previous post.

Perhaps this solution is found in all of the related how-tos, but I found this solution mostly by trial-and-error. The how-tos clued me in to some of the tools I might need to use, but that is all the usefulness I got from them.

Also misleading is that the 2.4.x kernel is suppose to make the isapnp tools obsolete, and that alleged fact led me astray from continuing to use those tools to provide a solution. But apparently I cannot get this card to function without those tools.

Still a mystery to me is why the kernel does not assign the third serial port to ttyS3 to remain consistent with the convention of port 0x2e8 (as the modem requests), or why a PnP device refuses to cooperate and reassign itself to 0x3e8. Is there a way to reconfigure the modem card to use 0x3e8/IRQ4?

Anyway, I'm online right now using the PnP modem in my second box. These are the kinds of problems where one learns a few things, and the primary lesson one learns is that computers still are some of the most user-hostile tools ever invented.

I hope this explanation helps somebody and I'm interested if anybody can explain this mystery to me!