Opened 10 years ago

Closed 10 years ago

#597 closed comment (No Change Needed)

"Some devices could not be assigned an interrupt (out of range)" - Audio does not work

Reported by: Lars Erdmann Owned by:
Priority: minor Milestone: Feedback pending
Component: ACPI PSD Version: 3.22.03
Keywords: Cc:

Description

I have an AsRock? Extreme4 MOBO. It's has an 8-core AMD CPU and AMD chipset. I am using ACPI.PSD without any switches. As such, the system works OK with all 8 CPUs supported (I had some probs with AHCI but that is sorted out). However I get the error message mentioned on bootup. I don't know if it is related but I subsequently get an odd IRQ assignment with IRQ level 16 getting assigned TWICE and IRQ Level 25 also getting assigned to HDA audio. Audio does not work.

Attachments (4)

ECS72420218-20140519-acpi-3.22.03.zip (93.0 KB) - added by Lars Erdmann 10 years ago.
ECS72420218-20140519-uniaud-2.02.01.log (66.2 KB) - added by Lars Erdmann 10 years ago.
AcpiCA.log (255.3 KB) - added by Lars Erdmann 10 years ago.
acpidaemon.log (42.4 KB) - added by Lars Erdmann 10 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 10 years ago by Lars Erdmann

Since I cannot attach tickets:

RMVIEW: Physical view

IRQ Level = 0 PCI Pin = NONE Flg = EXCLUSIVE TIMER_CH_0

IRQ Level = 1 PCI Pin = NONE Flg = EXCLUSIVE KBD_0 Keyboard Controller

IRQ Level = 2 PCI Pin = NONE Flg = EXCLUSIVE PIC_1

IRQ Level = 4 PCI Pin = NONE Flg = MULTIPLEXED SERIAL_0 Serial Controller

IRQ Level = 8 PCI Pin = NONE Flg = EXCLUSIVE RTC

IRQ Level = 9 PCI Pin = NONE Flg = SHARED ACPI Interface

IRQ Level = 12 PCI Pin = NONE Flg = EXCLUSIVE AUX_0 PS/2 Auxiliary Device Controller

IRQ Level = 16 PCI Pin = NONE Flg = SHARED HDA ATI SB

IRQ Level = 16 PCI Pin = NONE Flg = SHARED HDA ATI SB

IRQ Level = 17 PCI Pin = B Flg = SHARED EHCI_0 Enhanced USB Host Controller

IRQ Level = 17 PCI Pin = B Flg = SHARED EHCI_1 Enhanced USB Host Controller

IRQ Level = 17 PCI Pin = B Flg = SHARED EHCI_2 Enhanced USB Host Controller

IRQ Level = 18 PCI Pin = C Flg = SHARED OHCI_2 Open USB Host Controller

IRQ Level = 18 PCI Pin = A Flg = SHARED OHCI_3 Open USB Host Controller

IRQ Level = 18 PCI Pin = A Flg = SHARED OHCI_0 Open USB Host Controller

IRQ Level = 18 PCI Pin = A Flg = SHARED OHCI_1 Open USB Host Controller

IRQ Level = 19 PCI Pin = A Flg = SHARED r8169_0 Network Adapter

IRQ Level = 19 PCI Pin = A Flg = SHARED AHCI_0 Controller

IRQ Level = 25 PCI Pin = NONE Flg = SHARED HDA ATI SB

IRQ Level = 44 PCI Pin = NONE Flg = EXCLUSIVE ACPI Interface

IRQ Level = 45 PCI Pin = NONE Flg = EXCLUSIVE ACPI Interface

IRQ Level = 46 PCI Pin = NONE Flg = EXCLUSIVE ACPI Interface

IRQ Level = 47 PCI Pin = NONE Flg = EXCLUSIVE ACPI Interface

Build Level Display Facility Version 6.12.675 Sep 25 2001 (C) Copyright IBM Corporation 1993-2001 Signature: @#Netlabs:1.09.06#@##1## 19 Sep 2013 16:05:58 DAZAR1 ::::06::@@Universal Audio MMPM/2 Driver for eComStation Vendor: Netlabs Revision: 1.09.06 Date/Time?: 19 Sep 2013 16:05:58 Build Machine: DAZAR1 File Version: 1.9.6 Description: Universal Audio MMPM/2 Driver for eComStation

Build Level Display Facility Version 6.12.675 Sep 25 2001 (C) Copyright IBM Corporation 1993-2001 Signature: @#Netlabs:2.02.01#@##1## 23 Sep 2013 09:37:47 DAZAR1 :1.0.24:::01::BETA@@Universal Audio Driver for OS/2 and eComStation (KEE) Vendor: Netlabs Revision: 2.02.01 Date/Time?: 23 Sep 2013 09:37:47 Build Machine: DAZAR1 ASD Feature ID: 1.0.24 FixPak? Version: BETA File Version: 2.2.1 Description: Universal Audio Driver for OS/2 and eComStation (KEE)

comment:2 Changed 10 years ago by David Azarewicz

Milestone: Feedback pending

Please attach the log created by "testlog acpi".

Changed 10 years ago by Lars Erdmann

Changed 10 years ago by Lars Erdmann

comment:3 Changed 10 years ago by Lars Erdmann

I also added the uniaud log.
For Windows 7 I see 2 audio devices listed: one NVIDIA HDA device (ven: 0x10DE, dev: 0x42, I have no clue where that comes from, I have an NVidia graphics card but that's about it) and one Realtek HDA device (ven:0x10EC, dev:0x892).

Last edited 10 years ago by Lars Erdmann (previous) (diff)

comment:4 Changed 10 years ago by David Azarewicz

Sorry, but the log has no debug data. Perhaps you executed the testlog command more than once? The debug buffer is cleared when it is read. Only the first execution will capture the needed debug buffer.

comment:5 Changed 10 years ago by Lars Erdmann

I guess you refer to the output of "type acpica$". I tried again but there is still no output. 1) I do have the debug version of ACPI.PSD installed
2) this was set in config.sys: PSD=ACPI.PSD /WA=FBPR /DBGLVL=3 as set by the installation script
3) I only ran testlog.cmd ONCE.

Find attached the bootup log files. Maybe that helps.

Changed 10 years ago by Lars Erdmann

Attachment: AcpiCA.log added

Changed 10 years ago by Lars Erdmann

Attachment: acpidaemon.log added

comment:6 Changed 10 years ago by Lars Erdmann

Forgot to mention: it's an UEFI board with CSM (enabled).
The board has an IOMMU, however it's disabled (I guess that's only relevant for running virtual machines which I don't do on this board).

comment:7 Changed 10 years ago by abwillis

This page has a link to the testlog.cmd and instructions for it: http://trac.netlabs.org/acpi/wiki/Requirements

comment:8 Changed 10 years ago by David Azarewicz

I wonder why people always provide everything except what you ask for...

Why are you using /WA=FBPR? Since you still have not provided a complete log file, I cannot tell if you need this work around. If you have the daemon configured to dump the acpica$ log, this would be a reason why it is not available to the testlog script. The acpica.log you attached is not complete and out of sync with the other information which is why I ask for the testlog output.

Your hardware needlessly uses too many interrupts. Any devices which uses an interrupt higher than 31 is not supported. This cannot be fixed. This is a permanent limitation. On your system device 2:0:0 (a UHCI controller), and device 3:0:0 (a UHCI controller) will not be usable in symmetric mode because they will not get assigned an interrupt. If you need to use these 2 devices, you will have to limit the system initialization with the /VW switch.

None of this has anything to do with your audio problem.

Your system has more than one audio adapter. Uniaud is known to have trouble with multiple audio adapters. The best solution is to disable the audio adapter you don't want to use in the BIOS. If you can't do that, perhaps you can force uniaud32 to only attach to the adapter you want. I don't remember if this is possible or how to do it. You can also try a different Uniaud like 1.09.26. However, this is not an ACPI issue, and this ticket is an ACPI ticket.

comment:9 Changed 10 years ago by Lars Erdmann

There is no UHCI on this MOBO. It only has OHCI controllers (and EHCI and XHCI) and I have no USB plugin card either (UHCI is only Intel and VIA as far as I remember). Where did you get this info from ? The ACPI .dat file ? Maybe the ACPI implementation contains some superfluous stuff ...

Nonetheless you can close this ticket.

comment:10 Changed 10 years ago by David Azarewicz

Resolution: No Change Needed
Status: newclosed

I got the info from the PCI output. I guess they really are XHCI controllers (1B21:1042).

Note: See TracTickets for help on using tickets.