Bug 53293

This same lack of sound problem exists in RHEL3 WS. 

My RHEL3 modules.conf has: 
 
alias parport_lowlevel parport_pc 
alias usb-controller usb-uhci 
alias eth0 xirc2ps_cs 
 
KDE reports unable to use sound.  Other tools that make moise fail to do so. :-( 

Heh, spotted this report by accident.

I had similar problems ages ago on a hp 4100 laptop, here's 
an old mail with my workaround for it that could fix this for you
as well:

> its working with cs4232 if appropriate options are in modules.conf *AND*
> you accept that sound is screwed up unless you remove and re-add the
> cs4232 module.
Sounds exactly like the problem I was having on my HP4100.
I tracked down the problem to the pcmcia code probing the 
SB emulation ports of the chip. These ports aren't used 
by the cs4232 driver, so they're not marked as reserved, but
probing them seems to make the chip crap out anyway.

Changing /etc/pcmcia/config.opts to 
include port 0x100-0x21F,port 0x230-0x4ff, port 0x800-0x8ff, port
0xc00-0xcff

(I suppose an exclude for the sb emulation registers would work as
well:-) )

Yes!!! The remark from comment #3 combined with my mods from 
the original bug post did the trick! 
 
To recap:  I am running a RHEL3 kernel (kernel-2.4.21-9.0.1.EL) 
with the extra drivers (kernel-unsupported-2.4.21-9.0.1.EL) (mainly 
to get the support for my Xircom PCMCIA Ethernet/Modem card). 
I have these xmms rpms: 
 
  (see http://www.xmms.org/files/1.2.x/rpm/fc1) 
	xmms-1.2.10-1 
	xmms-devel-1.2.10-1 
	xmms-esd-1.2.10-1 
	xmms-gl-1.2.10-1 
	xmms-mikmod-1.2.10-1 
	xmms-vorbis-1.2.10-1 
  (see 
ftp://ftp.rpmfind.net/linux/PLD/current/dists/ra/updates/general/i686) 
	libmikmod-3.1.10-2.i686.rpm 
 
In /etc/modules.conf I have: 
 
	# networking 
	# 
	alias eth0 xirc2ps_cs 
 
	# usb devices 
	# 
	alias usb-controller usb-uhci 
 
	# parallel port 
	# 
	alias parport_lowlevel parport_pc 
 
	# sound 
	# 
	alias char-major-116 snd 
	alias snd-card-0 cs4232 
	alias char-major-14 soundcore 
	alias sound-slot-0 snd-card-0 
	alias sound-service-0-0 snd-mixer-oss 
	alias sound-service-0-1 snd-seq-oss 
	alias sound-service-0-3 snd-pcm1-oss 
	alias sound-service-0-12 snd-pcm1-oss 
	alias synth0 opl3 
	options sound dmabuf=1 
	options snd snd_major=116 snd_cards_limit=1 
snd_device_mode=0666 snd_device_gid=0 snd_device_uid=0 
	options opl3 io=0x388 
	options cs4232 io=0x530 mpuio=0x330 irq=5 mpuirq=7 dma=1 
dma2=0 
 
And made the following change (as suggested by Pekka Pietikäinen) 
to /etc/pcmcia/config.opts: 
 
--- config.opts.init    2003-01-25 05:47:27.000000000 -0800 
+++ config.opts 2004-03-30 06:27:26.000000000 -0800 
@@ -5,7 +5,7 @@ 
 
 # System resources available for PCMCIA devices 
 
-include port 0x100-0x4ff, port 0xc00-0xcff 
+include port 0x100-0x21F, port 0x230-0x4ff, port 0x800-0x8ff, port 
0xc00-0xcff 
 include memory 0xc0000-0xfffff 
 include memory 0xa0000000-0xa0ffffff, memory 0x60000000-0x60ffffff 
 
Now all aspects of sound are working! 
 
Q: Should the above patch to /etc/pcmcia/config.opts become a 
   bug fix?  Is certainly made the different for my TP 770Z! 
 

BTW: The www.xmms.org URL for the Fedora Core 1 XMMS 1.2.10 rpms 
     should have been: 
 
	http://www.xmms.org/download.php 
 
BTW: The libmikmod rpm URL should have been: 
 
http://ftp.rpmfind.net//linux/RPM/PLD/dists/ra/updates/general/i686/libmikmod-3.1.10-2.i686.html 
 
I'll attach the patch and /etc/modules.conf file next to address 
formatting problem in Comment #4. 
 

Created attachment 98965 [details]
FYI: modules.conf file used to get sound on the TP 770Z

This is a FYI attachment that documents what I needed to do in
order to get sound working on the IBM ThinkPad 770Z.

Created attachment 98966 [details]
patch to keep PCMCIA from interfering with TP 770Z sound

This patch, as suggested by Pekka Pietikäinen in Comment #3,
is needed to keep the PCMCIA facility from interfering with
the cs4232 sound on the IBM ThinkPad 770Z.

Created attachment 111543 [details]
pcmcia-sb-emulation.patch

I think this patch may achieve the same effect while being somewhat more
palatable.  Give it a try?

This patch should also be available in Fedora as part of rawhide, fwiw...

Sorry it took so long to test.  Your pcmcia-sb-emulation.patch does
not work on a IBM THinkPad 770Z running and up2date RHEL3 WS.

In order to get sound, I had to modify your patch so that the line:

include port 0x100-0x4ff, port 0x800-0x8ff, port 0xc00-0xcff

I had to change it to:

include port 0x100-0x21f, port 0x230-0x4ff, port 0x800-0x8ff, port
0xc00-0xcff

Without that change, no sound was possible.  With that change, sound
was fully functional.

FYI: I left in the "exclude port 0x220-0x22f" line even though it
did not seem to make a difference.

I recommend that you reconsider your patch. 

Well, it really seems like "exclude port 0x220-0x22f" should
work...CHANGES file in pcmcia-cs package mentions a similar problem in
the past that was supposedly fixed...hmmm...

Since you have a good workaround, I'm going to look into what is wrong
w/ the cardmgr configuration routines...

I need the pcmcia-cs version (rpm -q kernel-pcmcia-cs).
Although we did not update it in 3WS, let's be safe.

$ rpm -q kernel-pcmcia-cs
kernel-pcmcia-cs-3.1.31-13

Created attachment 112355 [details]
Patch to fix "exclude" #1

pcmcia-cs 3.1.25 (our package kernel-pcmcia-cs) has this:

-- Fixed two resource handling bugs: one broke "killall -HUP cardmgr"
   on some configurations, and the other caused probing of IO ranges
   that are included but later excluded.

The trick is that the fix applies to the kernel code (distributed by
pcmcia-cs), and apparently it was not submitted to Marcelo kernel, so
our kernel does not have it.

John, this patch is too invasive for RHEL 3, IMHO. Consider two points:
 - The fix is not in Marcelo tree.
 - Probing sequence is changed. It did reprobe after every "include" before,
   now it probes when a device requests a region.

I recommend closing with WONTFIX, regretfuly, but ... RHEL 4 has the same
bug, and the -mm with Dominik's patches kept it (verified in 2.6.12-rc1-mm2).
I'll bounce this off the pcmcia people. Then we might need to open a new
bug for RHEL 4, if someone has a hardware which reporduces this on RHEL 4.

I will be in a position to install RHEL4 WS on this same hardware
in a few weeks ... if that will be of help.  Let me know (I would
suggest that you don't set this bug to WONTFIX) and I'll test it
under that release.

I'll need a new bug for RHEL 4. All this reopening confuses tracking.

Per comment #23, this bug has been reopened as bug #157677