Red Hat Bugzilla – Bug 20396
Config of ISAPNP Soundbaster32 Fails
Last modified: 2014-03-16 22:17:08 EDT
When attempting to configure my SoundBlaster 32 ISA PNP card in the setup utility, I get the following error: /etc/isapnp.conf:47 -- Fatal - IO range check attempted while device activated /etc/isapnp.conf:47 -- Fatal - Error occurred executing request '<IORESCHECK> ' --- further action aborted I have tried using all the different soundblaster drivers using the following info (taken from my windows setup): IRQ 05 DMA 01 DMA 05 IO's: 0220-022F, 0330-0331, 0388-038B If there was other information needed other than this, I tried this information with all other combinations. I have used previous version of Red Hat (6.x tree) on this computer and had no problem configuring this sound card. I believe I was using the 32/AWE driver before. This system was upgraded from 6.2. I do not remember if I had the soundcard working prior to the upgrade... I reinstalled Linux a few times and don't remember if I resetup the sound card the last time. Any help would be appreciated. Thanks.
The setup package includes files like /etc/services. Reassigning to the "sndconfig" component.
Is this bug going to be assigned to anyone or just remain as New?
Um, the bug *is* assigned to someone. What's your /etc/isapnp.conf look like?
I see. :) It was just bugging me that the status still said new and there had been no action. I'm attaching my isapnp.conf I've been missing not having a working soundcard.
Created attachment 5704 [details] isapnp.conf
OK, you have an ISAPnP SCSI card as well, correct? The problem *appears* to be a conflict between it and the sound card. Do you have a driver for the SCSI card already loaded?
Yes. It is a sym53c416 SCSI card. I never got it working properly in any of the 6.x versions. I haven't attempted to get the SCSI card running in 7.0. There were no conflicts in the 6.x installs. I was able to easily get my soundcard running each time. This is a *clean* install of 7.0, not an upgrade. I haven't attempted to get the SCSI card running. The only thing I've done is tryied to get the soundcard running. Thanks for all your help!
OK. Edit /etc/isapnp.conf, and put a '#' before all the lines referring to the SCSI card (they're in the (CONFIGURE SLI4161 section). Then run isapnp /etc/isapnp.conf. Does that work?
This did the trick. Wonder why I didn't have a problem in the 6.x series. I did a clean install of 6.0, upgrade to 6.1, clean install of 6.1, upgrade to 6.2, and a clean install of 6.2 on this machine with no problems any time (Yes, I did a ton of installs, mostly bug hunting). Thanks!
Works for me? How can you just resolve the bug like this? There is something wrong with 7.0 if I had this conflict in the first place. I never had this problem on any install (clean or upgrade) of the 6.x tree. I think that constituts as a bug. Thank you.
I'm not sure why it worked for you in 6.2. The code in question didn't change. Can you post the output of 'pnpdump -c'?
Also, what does /proc/ioports look like?
I had the same error message in sndconfig with a clone SB16 ISA card and I found the problem (for me at least). I don't know why everyone doesn't have the problem with the latest sndconfig and isapnptools and an ISA sound card. Probably something else is going on as well, but perhaps this can give a clue. The isapnp program gets run once when the system boots, in rc.sysconfig. This works fine, so long as your BIOS is set to "PnP aware OS" and hasn't already configured and activated the ISA PnP cards. The card is now activated. Subsequent runs (as in sndconfig) do a range CHECK with the board already configured and activated, and this gives the error mentionned above. The sndconfig program bails after encountering the error from isapnp. The problem is that the /etc/isapnp.conf file that pnpdump generates assumes it will only be run once per boot. To get re-entrant isapnp.conf files, you have to turn the card off while checking the ranges. The FAQ (/usr/doc/isapnptools-1.21b/isapnpfaq.txt) says: 4.15. What does "IO range check attempted while device activated" mean (from isapnp) ? This means you have attempted to CHECK <isapnp.conf.5.html#CHECK> the device resource allocation for conflicts using the IO range feature, but the device has already been activated. Either remove the check, or put (ACT N) before the IO allocation. If you rerun isapnp, this is very likely to occur. You must first deactivate any drivers using the board. Then, when you rerun isapnp, make sure there is an (ACT N) at the beginning of the device configuration, configure and check the settings, then (ACT Y) and the end to reactivate it. You can then restart the drivers for the board. My isapnp.conf file now has (ACT N) after each (CONFIGURE...) section with a check in it. You can find these by taking the isapnp.conf file made by sndconfig and running isapnp /etc/isapnp.conf Look at the error message, and it will give a line number after the filename. That's the line with the check on it, so put the (ACT N) anywhere before that and after the start of the section. Do that repeatedly until you don't get any new line numbers. My only question is why this didn't occur for me prior to my recent update. I've been running 6.2 for a long time and have had this card working for 3 years, but sound only broke when I updated a week ago (last update before that was 1 Sep 00). But, neither sndconfig nor isapnptools got updated ever, since 6.2 came out. It would seem that *everyone* should have this problem, which would result in mass hysteria. So, something else is up, and I don't know what. But, doing the above got my card to work, for what it's worth. --jh--
Created attachment 6519 [details] pnpdump -c Output
Created attachment 6520 [details] Contents: /proc/ioports
Hey, working in the official 7.1 :) Good work. Only thing was I had to manually run the sound configuration tool (through setup) to get the soundcard operational. It would be nice if no additional steps pased kudzu were needed. Thanks!
Closing as resolved in the current release; it's not the best solution for 7.0 users as it does require a newer kernel, but it should be fixed there.