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

[Robert Woerle <robert-fPtsKRK0pHxl57MIdRCFDg@public.gmane.org>]

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