Changing IRQ`s at DSDT

Changing IRQ`s at DSDT

[Robert Woerle]

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

Hi

for the history : i am having a issue with ACPI and IRQ`s ( i believe )
i have a configuration where sound ( ali5451 ) , eth0( realtek 8139) and 
usb ( usb-ohci) are using IRQ 5 .
Until now what happens is that when i used 2 out of these 3 devices at 
the same time the unit locked hard .

Now i am able to set eth0 to IRQ7 and a first stress test with 600MB 
dowload and playing songs worked fine .

I am using now 2.4.22 + acpi20030916  + the initrd patch to use my own 
DSDT .

I reached that now in sent the LNK1 in my DSDT to IRQ 7 .

Unfortunatly the systems still uses IRQ 5 for the other 2 devices 
although i also did change the LNK8 and LNKU  at the DSDT ( tryed 6  and 
11 and 7 ) .

find attached my data of the unit ..

can somebody tell me why it ignores my changes to LNK8 and LNKU in my 
DSDT and still uses IRQ5 ?
i am also curious why certain LNK`s are parsed twice ???

thanks

Rob

-- 
_____________________________________
*Robert Woerle
Linux & Customer Support*
*PaceBlade Technology Europe SA*
phone: 	+49 89 552 99935
fax: 	+49 89 552 99910
mobile: 	+49 179 474 45 27
email: 	robert-fPtsKRK0pHxl57MIdRCFDg@public.gmane.org <mailto:robert@paceblade.com>
web: 	http://www.paceblade.com
_____________________________________




[-- Attachment #2: dsdt.dsl.tar.gz --]
[-- Type: application/x-gzip, Size: 9356 bytes --]

[-- Attachment #3: lspci+dmesg+interrupts --]
[-- Type: text/plain, Size: 5395 bytes --]

00:00.0 Host bridge: Transmeta Corporation LongRun Northbridge (rev 03)
00:00.1 RAM memory: Transmeta Corporation SDRAM controller
00:00.2 RAM memory: Transmeta Corporation BIOS scratchpad
00:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:04.0 FireWire (IEEE 1394): Lucent Microelectronics FW323 (rev 04)
00:05.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02)
00:06.0 VGA compatible controller: Silicon Motion, Inc. SM720 Lynx3DM (rev b1)
00:07.0 ISA bridge: ALi Corporation M1533 PCI to ISA Bridge [Aladdin IV]
00:08.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 01)
00:0f.0 IDE interface: ALi Corporation M5229 IDE (rev c3)
00:11.0 Bridge: ALi Corporation M7101 PMU
00:14.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)

Looking for DSDT in initrd ... found (at offset 445158)!
   tbget-0292: *** Info: Table [DSDT] replaced by host OS
 tbxface-0117 [03] acpi_load_tables      : ACPI Tables successfully acquired
Parsing all Control Methods:...............................................................................................................
Table [DSDT](id F004) - 403 Objects with 37 Devices 111 Methods 16 Regions
ACPI Namespace successfully loaded at root c036dffc
evxfevnt-0093 [04] acpi_enable           : Transition to ACPI mode successful
evgpeblk-0748 [06] ev_create_gpe_block   : GPE 00 to 63 [_GPE] 8 regs at 0000000000008018 on int 9
Completing Region/Field/Buffer/Package initialization:.......................................................................
Initialized 16/16 Regions 0/0 Fields 33/33 Buffers 22/22 Packages (411 nodes)
Executing all Device _STA and_INI methods:.........[ACPI Debug] String: LNK2_STA
.[ACPI Debug] String: LNK3_STA
.[ACPI Debug] String: LNK4_STA
.[ACPI Debug] String: LNK5_STA
.[ACPI Debug] String: LNK6_STA
.[ACPI Debug] String: LNK7_STA
.[ACPI Debug] String: LNK8_STA
.......................
38 Devices found containing: 38 _STA, 2 _INI methods
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: System [ACPI] (supports S0 S3 (swsusp) S4 S5)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNK1] (IRQs 7)
[ACPI Debug] String: LNK2_STA
[ACPI Debug] String: LNK2_STA
[ACPI Debug] String: LNK2_STA
[ACPI Debug] String: LNK2_CRS
ACPI: PCI Interrupt Link [LNK2] (IRQs *10)
[ACPI Debug] String: LNK3_STA
[ACPI Debug] String: LNK3_STA
[ACPI Debug] String: LNK3_STA
ACPI: PCI Interrupt Link [LNK3] (IRQs 10)
[ACPI Debug] String: LNK4_STA
[ACPI Debug] String: LNK4_STA
[ACPI Debug] String: LNK4_STA
[ACPI Debug] String: LNK4_CRS
ACPI: PCI Interrupt Link [LNK4] (IRQs 6 7 10 11)
[ACPI Debug] String: LNK5_STA
[ACPI Debug] String: LNK5_STA
[ACPI Debug] String: LNK5_STA
ACPI: PCI Interrupt Link [LNK5] (IRQs 6 7 10 11)
[ACPI Debug] String: LNK6_STA
[ACPI Debug] String: LNK6_STA
[ACPI Debug] String: LNK6_STA
[ACPI Debug] String: LNK6_CRS
ACPI: PCI Interrupt Link [LNK6] (IRQs 11)
[ACPI Debug] String: LNK7_STA
[ACPI Debug] String: LNK7_STA
[ACPI Debug] String: LNK7_STA
[ACPI Debug] String: LNK7_CRS
ACPI: PCI Interrupt Link [LNK7] (IRQs *5)
[ACPI Debug] String: LNK8_STA
[ACPI Debug] String: LNK8_STA
[ACPI Debug] String: LNK8_STA
[ACPI Debug] String: LNK8_CRS
ACPI: PCI Interrupt Link [LNK8] (IRQs 6)
ACPI: PCI Interrupt Link [LNKU] (IRQs 11)
ACPI: Power Resource [LRP0] (off)
PCI: Probing PCI hardware
ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 7
[ACPI Debug] String: LNK6_SRS
[ACPI Debug] String: LNK6_STA
[ACPI Debug] String: LNK6_STA
[ACPI Debug] String: LNK6_CRS
ACPI: PCI Interrupt Link [LNK6] enabled at IRQ 10
[ACPI Debug] String: LNK3_SRS
[ACPI Debug] String: LNK3_STA
[ACPI Debug] String: LNK3_STA
[ACPI Debug] String: LNK3_CRS
ACPI: PCI Interrupt Link [LNK3] enabled at IRQ 10
[ACPI Debug] String: LNK2_SRS
[ACPI Debug] String: LNK2_STA
[ACPI Debug] String: LNK2_STA
[ACPI Debug] String: LNK2_CRS
ACPI: PCI Interrupt Link [LNK2] enabled at IRQ 10
[ACPI Debug] String: LNK8_SRS
[ACPI Debug] String: LNK8_STA
[ACPI Debug] String: LNK8_STA
[ACPI Debug] String: LNK8_CRS
ACPI: PCI Interrupt Link [LNK8] enabled at IRQ 5
 pci_irq-0302 [32] acpi_pci_irq_derive   : Unable to derive IRQ for device 00:0f.0
PCI: No IRQ known for interrupt pin A of device 00:0f.0 - using IRQ 255
ACPI: PCI Interrupt Link [LNKU] enabled at IRQ 5
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
ACPI: AC Adapter [ACAD] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Processor [CPU0] (supports C1 C2 C3, 8 throttling states)
ACPI: Thermal Zone [THRM] (66 C)
vesafb: framebuffer at 0xf8200000, mapped to 0xd6802000, size 3072k
...


           CPU0
  0:     170374          XT-PIC  timer
  1:       2498          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:        817          XT-PIC  usb-ohci, ALI 5451
  7:        760          XT-PIC  eth0
  8:          2          XT-PIC  rtc
  9:          0          XT-PIC  acpi
 10:        757          XT-PIC  ohci1394, i82365
 14:       4363          XT-PIC  ide0
NMI:          0
ERR:          0

Re: Changing IRQ`s at DSDT

[Andrew de Quincey]

On Monday 29 September 2003 11:44, Robert Woerle wrote:
> Hi
>
> for the history : i am having a issue with ACPI and IRQ`s ( i believe )
> i have a configuration where sound ( ali5451 ) , eth0( realtek 8139) and
> usb ( usb-ohci) are using IRQ 5 .
> Until now what happens is that when i used 2 out of these 3 devices at
> the same time the unit locked hard .
>
> Now i am able to set eth0 to IRQ7 and a first stress test with 600MB
> dowload and playing songs worked fine .
>
> I am using now 2.4.22 + acpi20030916  + the initrd patch to use my own
> DSDT .
>
> I reached that now in sent the LNK1 in my DSDT to IRQ 7 .
>
> Unfortunatly the systems still uses IRQ 5 for the other 2 devices
> although i also did change the LNK8 and LNKU  at the DSDT ( tryed 6  and
> 11 and 7 ) .
>
> find attached my data of the unit ..
>
> can somebody tell me why it ignores my changes to LNK8 and LNKU in my
> DSDT and still uses IRQ5 ?
> i am also curious why certain LNK`s are parsed twice ???

Aha, that diff doesn't include the other patch I released more recently, which makes ACPI not 
reallocate an IRQ if the BIOS has already allocated one.. this sounds like the 
problem you are encontering.

Try this (against 2.4.23-pre3, so you may have to wiggle it into place). Lemme know if it helps.


--- linux-2.4.23-pre3.null_crs/drivers/acpi/pci_link.c	2003-09-05 23:57:39.000000000 +0100
+++ linux-2.4.23-pre3.nochangeirq/drivers/acpi/pci_link.c	2003-09-16 23:59:49.212387016 +0100
@@ -507,15 +507,15 @@
 		irq = link->irq.active;
 	} else {
 		irq = link->irq.possible[0];
-	}
 
-	/* 
-	 * 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];
+		/* 
+		 * 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];
+		}
 	}
 
 	/* Attempt to enable the link device at this IRQ. */



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

Re: Changing IRQ`s at DSDT

[Robert Woerle]

Andrew de Quincey schrieb:

>On Monday 29 September 2003 11:44, Robert Woerle wrote:
>  
>
>>Hi
>>
>>for the history : i am having a issue with ACPI and IRQ`s ( i believe )
>>i have a configuration where sound ( ali5451 ) , eth0( realtek 8139) and
>>usb ( usb-ohci) are using IRQ 5 .
>>Until now what happens is that when i used 2 out of these 3 devices at
>>the same time the unit locked hard .
>>
>>Now i am able to set eth0 to IRQ7 and a first stress test with 600MB
>>dowload and playing songs worked fine .
>>
>>I am using now 2.4.22 + acpi20030916  + the initrd patch to use my own
>>DSDT .
>>
>>I reached that now in sent the LNK1 in my DSDT to IRQ 7 .
>>
>>Unfortunatly the systems still uses IRQ 5 for the other 2 devices
>>although i also did change the LNK8 and LNKU  at the DSDT ( tryed 6  and
>>11 and 7 ) .
>>
>>find attached my data of the unit ..
>>
>>can somebody tell me why it ignores my changes to LNK8 and LNKU in my
>>DSDT and still uses IRQ5 ?
>>i am also curious why certain LNK`s are parsed twice ???
>>    
>>
>
>Aha, that diff doesn't include the other patch I released more recently, which makes ACPI not 
>reallocate an IRQ if the BIOS has already allocated one.. this sounds like the 
>problem you are encontering.
>
>Try this (against 2.4.23-pre3, so you may have to wiggle it into place). Lemme know if it helps.
>
>
>--- linux-2.4.23-pre3.null_crs/drivers/acpi/pci_link.c	2003-09-05 23:57:39.000000000 +0100
>+++ linux-2.4.23-pre3.nochangeirq/drivers/acpi/pci_link.c	2003-09-16 23:59:49.212387016 +0100
>@@ -507,15 +507,15 @@
> 		irq = link->irq.active;
> 	} else {
> 		irq = link->irq.possible[0];
>-	}
> 
>-	/* 
>-	 * 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];
>+		/* 
>+		 * 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];
>+		}
> 	}
> 
> 	/* Attempt to enable the link device at this IRQ. */
>  
>
hmm .. this patch doenst change too much ... .it only let run that code 
in the else {} ?? right ?

i used it but didnt found any difference ... all the IRQ`s which are 
active stay active and i cannot change them
with my DSDT ...

is there a way to not mark them as active and then be able to change 
them like i want ???

Cheers Rob

-- 
_____________________________________
*Robert Woerle
Linux & Customer Support*
*PaceBlade Technology Europe SA*
phone: 	+49 89 552 99935
fax: 	+49 89 552 99910
mobile: 	+49 179 474 45 27
email: 	robert-fPtsKRK0pHxl57MIdRCFDg@public.gmane.org <mailto:robert@paceblade.com>
web: 	http://www.paceblade.com
_____________________________________






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

Re: Changing IRQ`s at DSDT

[Robert Woerle]

Andrew de Quincey schrieb:

>>hmm .. this patch doenst change too much ... .it only let run that code
>>in the else {} ?? right ?
>>    
>>
>
>yeah
>
>  
>
>>i used it but didnt found any difference ... all the IRQ`s which are
>>active stay active and i cannot change them
>>with my DSDT ...
>>
>>is there a way to not mark them as active and then be able to change
>>them like i want ???
>>    
>>
>
>Hmm, which bit of the DSDT are you changing them in? The _PRT? Try checking 
>out the _CRS method as well.. sometimes it is hardcoded to always return the 
>same value.
>
>_CRS is also how you mark an IRQ as active... if it returns nonzero, the code 
>assumes the BIOS allocated it (and that patch makes it not mess with it).
>  
>

this is a example piece of my DSDT ...
all the other LNK`s look the same beside the IRQ ( some use 10 ) and
the PIRX where X is the Number of the LNK

so what makes it hardcoded here ???
what exactly does this _CRS make it active .. and how can i change it ?
or am i suffering of an hardwired IRQ ?



Device (LNK8)
                {
                    Name (_HID, EisaId ("PNP0C0F"))
                    Name (_UID, 0x08)
                    Name (_PRS, ResourceTemplate ()
                    {
                        IRQ (Level, ActiveLow, Shared) {5}
                    })
                    Name (RSRC, ResourceTemplate ()
                    {
                        IRQ (Level, ActiveLow, Shared) {}
                    })
                    Method (_DIS, 0, NotSerialized)
                    {
                        Store ("LNK8_DIS", Debug)
                        Store (0x00, PIR8)
                    }

                    Method (_CRS, 0, NotSerialized)
                    {
                        Store ("LNK8_CRS", Debug)
                        CreateWordField (RSRC, 0x01, IRQ0)
                        Store (PIR8, Local0)
                        Store (DerefOf (Index (PIRI, Local0)), Local1)
                        If (Local1)
                        {
                            ShiftLeft (0x01, Local1, IRQ0)
                        }

                        Return (RSRC)
                    }

                    Method (_SRS, 1, NotSerialized)
                    {
                        Store ("LNK8_SRS", Debug)
                        CreateWordField (Arg0, 0x01, IRQ0)
                        FindSetRightBit (IRQ0, Local0)
                        Decrement (Local0)
                        Store (DerefOf (Index (PIIR, Local0)), PIR8)
                    }

                    Method (_STA, 0, NotSerialized)
                    {
                        Store ("LNK8_STA", Debug)
                        If (PIR8)
                        {
                            Return (0x0B)
                        }

                        Return (0x09)
                    }
                }

>
>  
>

-- 
_____________________________________
*Robert Woerle
Linux & Customer Support*
*PaceBlade Technology Europe SA*
phone: 	+49 89 552 99935
fax: 	+49 89 552 99910
mobile: 	+49 179 474 45 27
email: 	robert-fPtsKRK0pHxl57MIdRCFDg@public.gmane.org <mailto:robert@paceblade.com>
web: 	http://www.paceblade.com
_____________________________________






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

Re: Changing IRQ`s at DSDT

[Andrew de Quincey]

> hmm .. this patch doenst change too much ... .it only let run that code
> in the else {} ?? right ?

yeah

> i used it but didnt found any difference ... all the IRQ`s which are
> active stay active and i cannot change them
> with my DSDT ...
>
> is there a way to not mark them as active and then be able to change
> them like i want ???

Hmm, which bit of the DSDT are you changing them in? The _PRT? Try checking 
out the _CRS method as well.. sometimes it is hardcoded to always return the 
same value.

_CRS is also how you mark an IRQ as active... if it returns nonzero, the code 
assumes the BIOS allocated it (and that patch makes it not mess with it).




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

Using INITRDDSDT: was Re: Changing IRQ`s at DSDT

[Robert Woerle]

Hi

so now i managed it ( i think )

as i said i was suffering from a hard lock on my unit when using 2 out 
of the 3 devices which use IRQ 5 ( eth0 , sound , usb ) at the same time .
I now changed my DSDT and provided eth0 to IRQ 7 ( which is not obviosly 
used before ) and it looks good ...
a stress test with 2 GB traffic on eth0 , while playing the whole 
Metallica -St. Anger album and using contiounsly my USB-keyboard ..
gave me no lock at all ....

i am now convinced that this will be the way to go and  i will do 
further more testing .

Of course ( like always ) i already discovered a new flaw with my new 
configuration .
Since i want to use swsusp i get now a hard lock after i resume and 
bring the eht0 up again ...

I am blaming swsusp for that ( i will contact their devel-list today) . 
Maybe they do not act
probably to restore a selfmade DSDT IRQ context .....

we will see ..

Suggestion :  Why dont you guys put the "Read DSDT from initrd " into 
the core ACPI source .. so that it gets
merged to the vanilla kernel at one point .
I really like idea to be able to load fixed DSDT`s . This can also be 
extended by the big distributions then to implement a routine
in their hardware scan so if a known Mainboard with  a buggy BIOS 
version ( is there a tool to check the version string of a BIOS ?? ) is
found they can load a fixed DSDT ....
This would be a great thing which ACPI enable`s us and so make Linux run 
even better on more units ...

Cheers Rob

Andrew de Quincey schrieb:

>>hmm .. this patch doenst change too much ... .it only let run that code
>>in the else {} ?? right ?
>>    
>>
>
>yeah
>
>  
>
>>i used it but didnt found any difference ... all the IRQ`s which are
>>active stay active and i cannot change them
>>with my DSDT ...
>>
>>is there a way to not mark them as active and then be able to change
>>them like i want ???
>>    
>>
>
>Hmm, which bit of the DSDT are you changing them in? The _PRT? Try checking 
>out the _CRS method as well.. sometimes it is hardcoded to always return the 
>same value.
>
>_CRS is also how you mark an IRQ as active... if it returns nonzero, the code 
>assumes the BIOS allocated it (and that patch makes it not mess with it).
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Acpi-devel mailing list
>Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>https://lists.sourceforge.net/lists/listinfo/acpi-devel
>
>  
>

-- 
_____________________________________
*Robert Woerle
Linux & Customer Support*
*PaceBlade Technology Europe SA*
phone: 	+49 89 552 99935
fax: 	+49 89 552 99910
mobile: 	+49 179 474 45 27
email: 	robert-fPtsKRK0pHxl57MIdRCFDg@public.gmane.org <mailto:robert@paceblade.com>
web: 	http://www.paceblade.com
_____________________________________






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

Re: Using INITRDDSDT: was Re: Changing IRQ`s at DSDT

[Bas Mevissen]

Robert Woerle wrote:

> 
> Suggestion :  Why dont you guys put the "Read DSDT from initrd " into 
> the core ACPI source .. so that it gets
> merged to the vanilla kernel at one point .

The patch that floats around works quite well, but it is a hack. It 
would be better to make a module that can be loaded from initrd at boot 
time. With some modprobe.conf smartness, you can select the proper table 
module to be loaded.

But I'm not sure if the ability to load modules doesn't come availabe 
too late in the boot process for ACPI as ACPI has influence on the 
interrupt routing.

> I really like idea to be able to load fixed DSDT`s . This can also be 
> extended by the big distributions then to implement a routine
> in their hardware scan so if a known Mainboard with  a buggy BIOS 
> version ( is there a tool to check the version string of a BIOS ?? ) is
> found they can load a fixed DSDT ....
> This would be a great thing which ACPI enable`s us and so make Linux run 
> even better on more units ...
> 

I agree only in part. Main problem is that you need the fix for exactly 
the same revision as in the BIOS to be sure you don't introduce 
problems. So that means that distribution makers need to maintain a huge 
collection of fixed DSDT's and need a fully reliable way to detect the 
BIOS version to be safe.

I think the best solution for the present time is to relax the ACPI 
interpreter syntax checking even more. But it should warn at boot time 
when it does work around syntax errors to attend the user that it's DSDT 
is actually wrong, but readable to the interpreter.


Bas.





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