Hi!

quoted text
> > The DSDT code clearly can't touch the hardware itself - hardware access 
> > is carried out by the kernel. If we can identify cases where ACPI reads 
> > and writes would touch resources claimed by other drivers, that would be 
> > a good starting point for working out what's going on.
> 
> I'm not familiar with APCI at all so I didn't know, but what you write
> here brings some hope. Would it be possible to parse all the DSDT code
> at boot time and deduce all the ports which ACPI would need to request
> to be safe?

I'm afraid it is about as hard as disassembling SMM BIOS to figure out
what it accesses.

quoted text
> > Of course, this ignores the case where the DSDT just traps into SMM 
> > code. That one is clearly unsolvable.
> 
> Yeah, SMM is an even more complex problem :(
> 
> Do we know in advance when we are going to SMM mode and back? If we

SMM is often invoked by timer, AC unplug, etc.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/