Distribution: SuSE 9.3 Professiona or Knoppix 3.9 (same behaviour) Hardware Environment: Notebook Terra Anima 2200 - Pentium M 735 - Chipset 855 GM - 1 GB RAM - 100 GB Mass Storage - 1x PCMCIA Slot Typ II - ... see this commercial website for more information about my hardware http://www.tuxhardware.de/product_info.html?cPath=124&products_id=515 Software Environment: - KDE Problem Description: If you insert the PCMCIA card Audigy2 ZS Notebook the system will totally freezing a few seconds later. The only thing i can do is a hardware-reset, switching to other consoles isn't possible. If I insert the PCMCIA-card before booting booting the system stops booting at that point where PCMCIA cards are loaded. Steps to reproduce: Put this PCMCIA card in the PCMCIA slot and you will see Linux crashing (freezing).
Please test 2.6.12-rc6 and 2.6.12-rc6-mm1.
I have been working on a driver for this card in Linux. There is a bug somewhere in the pcmcia-core code that fails to setup the resources correctly. I have tested many different kernel versions, including: 2.6.13-rc3-mm1 This PCMCIA cardbus sound card uses exactly the same PCI IDs as the Audigy 2 Value. There is currently support in ALSA for the Audigy 2 Value, so if one inserts the cardbus card, the snd-emu10k1 module is loaded. The problem is due to the first attempt to do the following operation: value = inl(emu->port); For example, emu->port = base IO address of the PCI cardbus card. This returns normally on the Audigy 2 Value, but this hangs the entire PC on the cardbus card. outl(value, emu->port) seems does not halt the PC, but without inl() working, one cannot really use the cardbus card at all. My knowledge of PCI configuration is minimal, so work in diagnosing the problem here is slow as I don't have any of the PCI cardbus/bridge specs. If there is anyone out there who can help me, I would very much appreciate it.
What is the value of emu->port, and how does that compare with /proc/ioports and the dmesg output?
emu->port is set correctly. It equals the output given in /proc/ioports when the driver loads and assigns resources. In any case, irrespective of whether the emu->port is correct or not, it should just return some value, instead of hang the entire machine. For example, if one does read and io port that has no hardware off the back of it, one will get 0xffff.
*** This bug has been marked as a duplicate of 5057 ***