Changing IRQ`s at DSDT
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
Signature · 10 lines
_____________________________________ *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: [email protected] <mailto:[email protected]> web: http://www.paceblade.com _____________________________________
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 20 lines · Robert Woerle
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 ) .
Quoted 5 lines
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.
drivers/acpi/pci_link.c +8 -8
@@ -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
A message that is not in the archive (sent off-list or not yet received): 200309291937.53825.adq_dvb-fmPXVN3awWJAJAzL26g0SA@public.gmane.org
Quoted 54 lines · Andrew de Quincey
Quoted 20 lines · Robert Woerle
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 ) .
Quoted 7 lines
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.
drivers/acpi/pci_link.c +1
-8@@ -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]; +/*
drivers/acpi/pci_link.c line 521
Quoted 10 lines
drivers/acpi/pci_link.c +7
-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]; + } }/* 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
Signature · 20 lines
_____________________________________ *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: [email protected] <mailto:[email protected]> web: http://www.paceblade.com _____________________________________ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 2 lines
hmm .. this patch doenst change too much ... .it only let run that code in the else {} ?? right ?
yeah
Quoted 6 lines
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
A message that is not in the archive (sent off-list or not yet received): 200309301215.13202.adq_dvb-fmPXVN3awWJAJAzL26g0SA@public.gmane.org
Quoted 13 lines · Andrew de Quincey
Quoted 4 lines
hmm .. this patch doenst change too much ... .it only let run that code in the else {} ?? right ?
yeah
Quoted 4 lines
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 ...
Quoted 10 lines
Quoted 4 lines
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_CRSmethod as well.. sometimes it is hardcoded to always return the same value.
_CRSis 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)
}
}Quoted 3 lines
Signature · 20 lines
_____________________________________ *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: [email protected] <mailto:[email protected]> web: http://www.paceblade.com _____________________________________ ------------------------------------------------------- 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
In reply to a message not in the archiveHi
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
Quoted 36 lines · Andrew de Quincey
Quoted 4 lines
hmm .. this patch doenst change too much ... .it only let run that code in the else {} ?? right ?
yeah
Quoted 8 lines
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_CRSmethod as well.. sometimes it is hardcoded to always return the same value.
_CRSis 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 [email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-devel
Signature · 20 lines
_____________________________________ *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: [email protected] <mailto:[email protected]> web: http://www.paceblade.com _____________________________________ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: Using INITRDDSDT: was Re: Changing IRQ`s at DSDT
Quoted 3 lines · Robert Woerle
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.
Quoted 5 lines
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