acpi_pci_link_check's attempt to find the _best_ irq prevents system from using ACPI irq routing

acpi_pci_link_check's attempt to find the _best_ irq prevents system from using ACPI irq routing

[Malte Doersam]

Hi everybody,

After my Thinkpad R31 didn't want to boot without pci=noacpi, I tried today to 
find out, what the reason for this is. With pci=acpi it booted right away 
till 

ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
Transparent bridge - Intel Corp. 82801BAM/CAM PCI Bri
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
ACPI: PCI Interrupt Link [PILA] (IRQs 3 4 5 6 7 9 *11 12 14 15)
ACPI: PCI Interrupt Link [PILB] (IRQs 3 4 5 6 7 9 *11 12 14 15)
ACPI: PCI Interrupt Link [PILC] (IRQs 3 4 5 6 7 9 *11 12 14 15)
ACPI: PCI Interrupt Link [PILD] (IRQs 3 4 5 6 7 9 *11 12 14 15)
ACPI: PCI Interrupt Link [PILE] (IRQs 3 4 5 6 7 9 *11 12 14 15)
ACPI: PCI Interrupt Link [PILF] (IRQs 3 4 5 6 7 9 *11 12 14 15)
ACPI: PCI Interrupt Link [PILG] (IRQs 3 4 5 6 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [PILH] (IRQs 3 4 5 6 7 9 11 12 14 15, disabled)
ACPI: Embedded Controller [EC0] (gpe 29)
block request queues:
 128 requests per read queue
 128 requests per write queue
 8 requests per batch
 enter congestion at 15

then it stoped without any warning or failure message. I had no clue, why the 
kernel behaved like this. 

The 'show stopper' is one nifty loop in the drivers/acpi/pci_link.c:
Actually its the part which has this comment: "Pass #2: Enable boot-disabled 
Links at 'best' IRQ."

/* 
* Select the best IRQ.  This is done in reverse to promote 
* the use of IRQs 9, 10, 11, and >15.
*/
for (i=(link->irq.possible_count-1); i>0; i--) {
	if (acpi_irq_penalty[irq] > acpi_irq_penalty[link->irq.possible[i]])
 		irq = link->irq.possible[i];
	}

After commenting out this loop, the 'boot-disabled Links' got both irq 3 
(which isn't the best, but seemingly quite okay.) And the system started as 
expected with 'pci=acpi'. *hooray* It seems quite stable, though only S1 is 
working properly. S3 has still problems at wake-up-stadium. 

Maybe some brighter soul can review this... ;-)

thanks for this great work

cheers Malte



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: acpi_pci_link_check's attempt to find the _best_ irq prevents system from using ACPI irq routing

[Malte Doersam]

Hi Andy, Hi everbody

It took me severel hours to track down this to this point. As you stated, the 
acpi_pci_link_check doesn't block the booting.  I observed the loop with some 
printks in acpi_pci_link_check:

FYI my links: 
ACPI: PCI Interrupt Link [PILA] (IRQs 3 4 5 6 7 9 *11 12 14 15)
ACPI: PCI Interrupt Link [PILB] (IRQs 3 4 5 6 7 9 *11 12 14 15)
ACPI: PCI Interrupt Link [PILC] (IRQs 3 4 5 6 7 9 *11 12 14 15)
ACPI: PCI Interrupt Link [PILD] (IRQs 3 4 5 6 7 9 *11 12 14 15)
ACPI: PCI Interrupt Link [PILE] (IRQs 3 4 5 6 7 9 *11 12 14 15)
ACPI: PCI Interrupt Link [PILF] (IRQs 3 4 5 6 7 9 *11 12 14 15)
ACPI: PCI Interrupt Link [PILG] (IRQs 3 4 5 6 7 9 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [PILh] (IRQs 3 4 5 6 7 9 11 12 14 15, disabled)

and here are my printks, the numbers in {{x}} represent the content of the 
variable before...

acpi_pci_link_check entered
link->irq.active --> IRQ: 11 Penalty: 100
link->irq.active --> IRQ: 11 Penalty: 200
link->irq.active --> IRQ: 11 Penalty: 300
link->irq.active --> IRQ: 11 Penalty: 400
link->irq.active --> IRQ: 11 Penalty: 500
link->irq.active --> IRQ: 11 Penalty: 600
!link->irq.active
!link->irq.active
first list_for_each completed

!link->irq.active
irq=link->irq.possible[0] {{3}}
for (i=( link->irq.possible_count {{10}} -1; i>0;i--) {
if (acpi_irq_penalty[irq] {{10020}} > acpi_irq_penalty[link->irq.possible[i]] 
{{10020} ) { 	// 15
if (acpi_irq_penalty[irq] {{10020}} > acpi_irq_penalty[link->irq.possible[i]] 
{{10020} ) {	// 14
if (acpi_irq_penalty[irq] {{10020}} > acpi_irq_penalty[link->irq.possible[i]] 
{{10020} ) {	// 12
if (acpi_irq_penalty[irq] {{10020}} > acpi_irq_penalty[link->irq.possible[i]] 
{{620} ) {	// 11
irq = link->irq.possible[i] {{11}} ;
if (acpi_irq_penalty[irq] {{620}} > acpi_irq_penalty[link->irq.possible[i]] 
{{20} ) {		//  9
irq = link->irq.possible[i] {{9}} ;
if (acpi_irq_penalty[irq] {{20}} > acpi_irq_penalty[link->irq.possible[i]] 
{{10020} ) {		//  7
if (acpi_irq_penalty[irq] {{20}} > acpi_irq_penalty[link->irq.possible[i]] 
{{10020} ) {		//  6
if (acpi_irq_penalty[irq] {{20}} > acpi_irq_penalty[link->irq.possible[i]] 
{{20} ) {		//  5
if (acpi_irq_penalty[irq] {{20}} > acpi_irq_penalty[link->irq.possible[i]] 
{{10020} ) {		//  4
second list_for_each complete

acpi_pci_link_set(link,irq);

Ok, as you can see, it is trying to do the acpi_pci_link_set with IRQ 9, which 
doesn't work. Commenting out this check-loop made the disabled links to use 
the first IRQ (3) which worked.

Now to the interesting part, why IRQ doesn't work:

I followed the acpi_pci_link_set through zillions of lines of code ;) to this 
function ( drivers/acpi/parser/psparse.c)

acpi_status acpi_ps_parse_loop ( struct acpi_walk_state * walk_state)

The "offending part" is this:

/* This op complete, notify the dispatcher */

if (walk_state->ascending_callback != NULL ) {
  walk_state->op    = op;
  walk_state->opcode = op->common.aml_opcode;
  printk("Malte DEBUG: last seen line\n");
  status = walk_state->ascending_callback (walk_state);
  printk("Malte DEBUG: never got to this point with IRQ9\n");
  status = acpi_ps_next_parse_state (walk_state, op, status);
  if (status == AE_CTRL_PENDING) {
    status = AE_OK;
    goto close_this_op;
  }
}

Maybe you can send me some appropriate printk-instruction which print some 
usefull information for you about this 'blocker'? :-)
I'm not sure whether this might be an AML-Bug, but my dsdt.asl does compile 
fine with iasl. In the mean time I'm just using IRQ 3 for these links :-)

http://home.fhtw-berlin.de/~s0502837/linux.kernel/2.5.66.dsdt
http://home.fhtw-berlin.de/~s0502837/linux.kernel/dsdt.asl

cheers Malte




Am Mittwoch, 23. April 2003 20:19 schrieben Sie:
> Looks OK to me. You guys need to tell me *why* commenting it out fixes
> things - with it left in, what irq is it picking, and why isn't that irq
> working OK?
>
> Thanks -- Regards -- Andy



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf