Bug 154961
| Summary: | 2.6.11-1.14_FC3 kernel mutes Creative SB AudioPCI 64V sound card using ens1371 driver | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Frank Wang <yafrank> |
| Component: | kernel | Assignee: | Dave Jones <davej> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5 | CC: | jonstanley, nate, pfrields, richard.zatorski |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| URL: | https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1023 | ||
| Whiteboard: | MassClosed | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-01-20 04:38:38 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Frank Wang
2005-04-15 03:41:01 UTC
can you go through the volume controls and make sure they're all unmuted and non-zero ? Yes, alsamixer can be invoked and I'm sure all channels are unmuted and
non-zero. The problem is that there is not PCM channel anymore. Here is some info:
[root@twinhead ~]# uname -r
2.6.11-1.14_FC3
[root@twinhead ~]# alsamixer
[root@twinhead ~]# alsactl store
[root@twinhead ~]# cat /etc/asound.state
state.AudioPCI {
control.1 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 31'
iface MIXER
name 'Master Playback Volume'
value.0 31
value.1 31
}
control.2 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Center Playback Switch'
value true
}
control.3 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 31'
iface MIXER
name 'Center Playback Volume'
value 31
}
control.4 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'LFE Playback Switch'
value true
}
control.5 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 31'
iface MIXER
name 'LFE Playback Volume'
value 31
}
control.6 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 31'
iface MIXER
name 'Master Mono Playback Volume'
value 31
}
control.7 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 15'
iface MIXER
name 'Tone Control - Bass'
value 15
}
control.8 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 15'
iface MIXER
name 'Tone Control - Treble'
value 15
}
control.9 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'PC Speaker Playback Switch'
value true
}
control.10 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 15'
iface MIXER
name 'PC Speaker Playback Volume'
value 15
}
control.11 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Mic Boost (+20dB)'
value true
}
control.12 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 15'
iface MIXER
name 'Video Playback Volume'
value.0 15
value.1 15
}
control.13 {
comment.access 'read write'
comment.type ENUMERATED
comment.count 2
comment.item.0 Mic
comment.item.1 CD
comment.item.2 Video
comment.item.3 Aux
comment.item.4 Line
comment.item.5 Mix
comment.item.6 'Mix Mono'
comment.item.7 Phone
iface MIXER
name 'Capture Source'
value.0 Mic
value.1 Mic
}
control.14 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 15'
iface MIXER
name 'Capture Volume'
value.0 0
value.1 0
}
control.15 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Mic Capture Switch'
value true
}
control.16 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 15'
iface MIXER
name 'Mic Capture Volume'
value 0
}
}
[root@twinhead ~]# lspci -v | grep Creative -A6
00:06.0 Multimedia audio controller: Creative Labs Ectiva EV1938
Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device 0e70
Flags: bus master, slow devsel, latency 96, IRQ 5
I/O ports at fcc0 [size=64]
I/O ports at fc40 [size=32]
Capabilities: [dc] Power Management version 1
[root@twinhead ~]# lsmod | grep snd
snd_ens1371 30753 0
snd_rawmidi 28641 1 snd_ens1371
snd_seq_device 8781 1 snd_rawmidi
snd_ac97_codec 71097 1 snd_ens1371
snd_pcm_oss 51953 0
snd_mixer_oss 18241 1 snd_pcm_oss
snd_pcm 99657 3 snd_ens1371,snd_ac97_codec,snd_pcm_oss
snd_timer 33093 1 snd_pcm
snd 56741 8
snd_ens1371,snd_rawmidi,snd_seq_device,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore 10785 1 snd
snd_page_alloc 9669 1 snd_pcm
gameport 5057 1 snd_ens1371
Just wondering if there is any traction being made on this bug? I'm seeing a similar symptoms on my thinkpad. My volume controls are all set correctly there is no muting, but when I play audio, there is nothing coming out. The players are driving along as if there's no problem. I'm having a same problem with the kernel 2.6.11-1.14_FC3. Everything works okay with the older kernel 2.6.9-1.667 but when I use the newer one there is no sound at all and No Mixer Controls for PCM and Master. I have a AC97 integrated sound chip on the motherboard. This problem still exists in FC4, no PCM channel in my volume controls, and other channels, such as LINEIN, disappear occasionally. I tried the offical kernel 2.6.12-rc6-git8 from www.kernel.org. No help. This has also happened to me with a PCI-SB that uses the ens1371 module and a Dell D600 Notebook using Fedora Core 3. With the PCI card, the std mixer wouldn't work and mythtv cannot record any audio. I think this may be a problem with /dev/dsp in the kernel. This would also explain why PCM is missing off some people's mixers. The Dell D600's mixer does not work at all and comes up with "No mixer device found". I have only noticed this with the last 2 kernels. An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you. Tried the latest 2.6.12-1.1398_FC4 kernel with no help. I've updated the bug version to fc4. Various people using FC-based machines for radio linking at www.irlp.net have reported that they lost audio on older true SoundBlaster cards (SB16, etc) between 2.6.10 and 2.6.11. What information do you need from these machines to figure out the issue? It's hit at least three machines in our group, perhaps more - we can probably get you plenty of data to figure it out. This has been open long enough that it's probably not going to get fixed without attention from the alsa folks. Working with them directly through their bugtracker at https://bugtrack.alsa-project.org is probably going to get this resolved a lot quicker. Reported to alsa bugtracker the same time as of this one, still waiting... Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (2.6.13.2). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks. Tried the 2.6.13-1.1526_FC4 kernel with no help. Alsamixer can show all the
channels including PCM this time but all mute controls are gone. Still no sound
can be played no matter whatever value set in alsamixer. The soundcard irq
handle seems has problem in new kernel according to dmesg:
...
hdb: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdb: packet command error: error=0x50 { LastFailedSense=0x05 }
...
irq 5: nobody cared (try booting with the "irqpoll" option)
[<c0169156>] __report_bad_irq+0x24/0x7f
[<c0169231>] note_interrupt+0x62/0xb1
[<c0167458>] __do_IRQ+0x39f/0x577
[<c01212d7>] scheduler_tick+0x1a/0x569
[<c02eda54>] elv_queue_empty+0x12/0x1f
[<c03177ba>] ide_do_request+0xb1/0x5ea
[<c010695d>] do_IRQ+0x66/0x82
[<c0104622>] common_interrupt+0x1a/0x20
[<c0167076>] handle_IRQ_event+0x17/0x5a
[<c0167280>] __do_IRQ+0x1c7/0x577
[<c0106941>] do_IRQ+0x4a/0x82
=======================
[<c0104622>] common_interrupt+0x1a/0x20
handlers:
[<cc919e3c>] (snd_audiopci_interrupt+0x0/0x314 [snd_ens1371])
Disabling IRQ #5
spurious 8259A interrupt: IRQ7.
Also tried to boot it with irqpoll option with no help either. But the
correspondent dmesg part is slighly different:
...
irq 5: nobody cared (try booting with the "irqpoll" option)
[<c0169156>] __report_bad_irq+0x24/0x7f
[<c0169231>] note_interrupt+0x62/0xb1
[<c0167458>] __do_IRQ+0x39f/0x577
[<c010695d>] do_IRQ+0x66/0x82
[<c0104622>] common_interrupt+0x1a/0x20
[<c0167076>] handle_IRQ_event+0x17/0x5a
[<c0167280>] __do_IRQ+0x1c7/0x577
[<c0106941>] do_IRQ+0x4a/0x82
=======================
[<c0104622>] common_interrupt+0x1a/0x20
[<c0130657>] do_setitimer+0x3e8/0x1058
[<c01042a5>] do_signal+0x7c/0x105
[<c0379e61>] sys_socketcall+0x1b9/0x292
[<c0137b02>] sys_alarm+0x30/0x56
[<c0104465>] syscall_call+0x7/0xb
handlers:
[<cc919e3c>] (snd_audiopci_interrupt+0x0/0x314 [snd_ens1371])
Disabling IRQ #5
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you. Kernel 2.6.14-1.1637_FC4 has similar problem like 2.6.13-1.1526_FC4. Dmesg shows following: ... eth0: link up, 10Mbps, half-duplex, lpa 0x0000 irq 5: nobody cared (try booting with the "irqpoll" option) [<c013b11b>] __report_bad_irq+0x24/0x7f [<c013b1f6>] note_interrupt+0x62/0xac [<c013ac0d>] __do_IRQ+0xc4/0xd7 [<c01045cd>] do_IRQ+0x66/0x82 [<c01030aa>] common_interrupt+0x1a/0x20 [<c013ab06>] handle_IRQ_event+0x17/0x5a [<c013abc1>] __do_IRQ+0x78/0xd7 [<c01045b1>] do_IRQ+0x4a/0x82 ======================= [<c01030aa>] common_interrupt+0x1a/0x20 [<c013bbd3>] page_waitqueue+0x20/0x32 [<c013bc6c>] unlock_page+0x1c/0x26 [<c0149ff3>] do_wp_page+0x233/0x304 [<c0148c69>] pte_alloc_map+0x29/0xab [<c014ae9b>] __handle_mm_fault+0x18b/0x190 [<c030cb41>] _spin_unlock_irq+0x5/0x7 [<c030d91e>] do_page_fault+0x25e/0x640 [<c030d6c0>] do_page_fault+0x0/0x640 [<c0103107>] error_code+0x4f/0x54 handlers: [<cc90c048>] (snd_audiopci_interrupt+0x0/0xdf [snd_ens1371]) Disabling IRQ #5 This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you. Tried the 2.6.15-1.1830_FC4 kernel with no help. The symptom is similar as in #16. Dmesg shows following this time: ... eth0: link up, 10Mbps, half-duplex, lpa 0x0000 irq 5: nobody cared (try booting with the "irqpoll" option) [<c013d305>] __report_bad_irq+0x24/0x7f [<c013d3e0>] note_interrupt+0x62/0xb2 [<c013cdc3>] __do_IRQ+0xca/0xd7 [<c0104f56>] do_IRQ+0x66/0x82 [<c01038ba>] common_interrupt+0x1a/0x20 [<c013ccb6>] handle_IRQ_event+0x17/0x5a [<c013cd77>] __do_IRQ+0x7e/0xd7 [<c0104f3a>] do_IRQ+0x4a/0x82 ======================= [<c01038ba>] common_interrupt+0x1a/0x20 [<c014c39b>] do_wp_page+0x36/0x311 [<c0170acb>] dput+0x221/0x265 [<c014d459>] __handle_mm_fault+0x21d/0x254 [<c0317a79>] do_page_fault+0x259/0x630 [<c0317820>] do_page_fault+0x0/0x630 [<c01039a7>] error_code+0x4f/0x54 handlers: [<cc908018>] (snd_audiopci_interrupt+0x0/0xdf [snd_ens1371]) Disabling IRQ #5 spurious 8259A interrupt: IRQ7. spurious 8259A interrupt: IRQ15. [This comment added as part of a mass-update to all open FC4 kernel bugs] FC4 has now transitioned to the Fedora legacy project, which will continue to release security related updates for the kernel. As this bug is not security related, it is unlikely to be fixed in an update for FC4, and has been migrated to FC5. Please retest with Fedora Core 5. Thank you. A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you. (this is a mass-close to kernel bugs in NEEDINFO state) As indicated previously there has been no update on the progress of this bug therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue still occurs for you and I will try to assist in its resolution. Thank you for taking the time to report the initial bug. If you believe that this bug was closed in error, please feel free to reopen this bug. |