Hi! > > 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. > > 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 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
