Bug 541981
| Summary: | kernel-2.6.31.6-148.fc12.x86_64: DMAR errors on access to Intel audio device | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tom London <selinux> | ||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 12 | CC: | dougsland, dwmw2, gansalmon, itamar, kernel-maint, manisandro | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2010-12-04 02:41:26 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: | |||||||
| Attachments: |
|
||||||
Hm, can't reproduce on x200s here (F12 + 2.6.32-0.51.rc7.git2.fc13.x86_64). Sound _looks_ like it should be playing fine, and there are lots of interrupts... but silence. Just the normal PulseAudio breakage, I imagine; I'll try removing PA and see if that makes things work as usual. OK, I have sound.... but no DMA errors on the sound device. It's all just working fine. Not sure why it would be trying to read from address zero -- that sounds like a driver bug. Do you know what it's trying to do when this happens? Does it hapen while it's supposed to be playing something, or when it stops, or just at random times when it's supposed to be silent? Does sound work at all? If you can let me know how to trigger the problem, that would be useful. Hmmm... I'm not really sure. It "works" most of the time. On some boots, I notice that when I start rhythmbox, I get no sound. I've determined that when that happens, killing and restarting the pulseaudio daemon usually "makes it work". Also, I've noticed that on rare occasions, when I start to play audio from within audacity (compiled to support mp3s and lame), it plays for about half a second and then freezes (audacity, that is). In such cases, I can only kill off audacity and restart it. On those instances, it comes back and plays fine. Sorry I can't be more helpful. What can I look for, and what I can "dump", if I see this again? (In reply to comment #3) > Hmmm... I'm not really sure. > > It "works" most of the time. > > On some boots, I notice that when I start rhythmbox, I get no sound. > > I've determined that when that happens, killing and restarting the pulseaudio > daemon usually "makes it work". > > Also, I've noticed that on rare occasions, when I start to play audio from > within audacity (compiled to support mp3s and lame), it plays for about half a > second and then freezes (audacity, that is). In such cases, I can only kill > off audacity and restart it. On those instances, it comes back and plays fine. All of these just sound like normal PulseAudio behaviour to me. Can you correlate any of them with the logs you reported? And preferably reproduce without PA? (Not that PA is responsible for the logs you reported -- that's definitely a kernel bug; probably in the sound driver). Running with latest koji fc13 kernel and with Vt-d turned off in BIOS, I see this in /var/log/messages when audacity "freezes": Nov 29 12:11:39 tlondon pulseaudio[2011]: ratelimit.c: 4 events suppressed Nov 29 12:15:18 tlondon kernel: ALSA sound/pci/hda/hda_intel.c:698: azx_get_response timeout, switching to polling mode: last cmd=0x018f0900 Not sure how relevant it is to this problem..... However, checking my logs, I see this every so often: [root@tlondon ~]# grep 'azx_get_response timeout' /var/log/messages* /var/log/messages:Nov 29 12:15:18 tlondon kernel: ALSA sound/pci/hda/hda_intel.c:698: azx_get_response timeout, switching to polling mode: last cmd=0x018f0900 /var/log/messages-20091115:Nov 14 07:14:59 tlondon kernel: ALSA sound/pci/hda/hda_intel.c:691: azx_get_response timeout, switching to polling mode: last cmd=0x010b8000 /var/log/messages-20091122:Nov 16 08:52:13 tlondon kernel: ALSA sound/pci/hda/hda_intel.c:698: azx_get_response timeout, switching to polling mode: last cmd=0x019f000c /var/log/messages-20091122:Nov 19 06:57:13 tlondon kernel: ALSA sound/pci/hda/hda_intel.c:691: azx_get_response timeout, switching to polling mode: last cmd=0x01af0c00 /var/log/messages-20091129:Nov 23 06:07:13 tlondon kernel: ALSA sound/pci/hda/hda_intel.c:691: azx_get_response timeout, switching to polling mode: last cmd=0x017f0900 /var/log/messages-20091129:Nov 25 14:27:01 tlondon kernel: ALSA sound/pci/hda/hda_intel.c:691: azx_get_response timeout, switching to polling mode: last cmd=0x017f0900 /var/log/messages-20091129:Nov 27 16:15:06 tlondon kernel: ALSA sound/pci/hda/hda_intel.c:698: azx_get_response timeout, switching to polling mode: last cmd=0x017f0900 /var/log/messages-20091129:Nov 28 11:40:43 tlondon kernel: ALSA sound/pci/hda/hda_intel.c:698: azx_get_response timeout, switching to polling mode: last cmd=0x016f000c [root@tlondon ~]# Is this to be expected? This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping I am runnning Rawhide. I cannot reproduce. Close? Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |
Created attachment 374292 [details] /var/log/messages from run with DMAR Spew Description of problem: I noticed a spew of "DMAR Read Access" errors on a boot of kernel-2.6.31.6-148.fc12.x86_64: the accesses were for the Intel audio device. System is Thinkpad X200. Nov 24 08:49:53 tlondon kernel: DMAR:[fault reason 06] PTE Read access is not set Nov 24 08:49:53 tlondon kernel: DRHD: handling fault status reg 3 Nov 24 08:49:53 tlondon kernel: DMAR:[DMA Read] Request device [00:1b.0] fault addr 0 Nov 24 08:49:53 tlondon kernel: DMAR:[fault reason 06] PTE Read access is not set Nov 24 08:49:53 tlondon kernel: DRHD: handling fault status reg 3 Nov 24 08:49:53 tlondon kernel: DMAR:[DMA Read] Request device [00:1b.0] fault addr 0 Nov 24 08:49:53 tlondon kernel: DMAR:[fault reason 06] PTE Read access is not set [root@tlondon ~]# lspci 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07) 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) 00:03.0 Communication controller: Intel Corporation Mobile 4 Series Chipset MEI Controller (rev 07) 00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03) 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03) 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03) 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03) 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03) 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93) 00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03) 00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03) 03:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection [root@tlondon ~]# I attach complete /var/log/messages from this boot. Checking my /var/log/messages*, I can see this happening occasionally beginning with my log for 29 September 2009 and kernel-2.6.31.1-56.fc12.x86_64. However, my saved logs start then..... Version-Release number of selected component (if applicable): kernel-2.6.31.6-148.fc12.x86_64 How reproducible: Seen numerous times going back to 29 September 2009 Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: