On Fri, Dec 01, 2006 at 03:32:47PM -0800, [EMAIL PROTECTED] wrote: > On Fri, Dec 01, 2006 at 03:29:22PM -0800, Pete Zaitcev wrote: > > On Fri, 1 Dec 2006 15:23:39 -0800, [EMAIL PROTECTED] wrote: > > > > > BIOS handoff assumes an SMI, right? Could SMI be masked? > > > > That might be a bad idea, because things like fans may be controlled > > by SMM BIOS. The best thing we can do is to follow the published > > procedure, and maybe insert a workaround if Sebastian can identify it. > > Sorry, I don't mean "could we mask it" but rather "is it possible that it > is already masked"? > > Tim
Hi, I can't see any negative effects when the handoff fails. But if any of you think it's worth to get to the bottom of this I'm more than willing to help the best I can. But I don't know what SMI nor SMM BIOS is, just so you know that I can't figure out these things on my own. I extracted my BIOS' dsdt and disassembled it (on a hunch). I grepped it for strings like "Microsoft" and "Windows" and found three: Method (_INI, 0, NotSerialized) { If (STRC (_OS, "Microsoft Windows")) { Store (0x56, SMIP) } Else { If (STRC (_OS, "Microsoft Windows NT")) { If (CondRefOf (_OSI, Local0)) { If (_OSI ("Windows 2001")) { Store (0x59, SMIP) Store (Zero, OSFL) Store (0x03, OSFX) } } Else { Store (0x58, SMIP) Store (Zero, OSFL) } } Else { Store (0x57, SMIP) Store (0x02, OSFL) } } } So I tried all possible combinations of acpi_os_name and acpi_osi (allthough the latter seemed to be ignored by the ACPI system). But this didn't change the OHCI handoff behaviour. At least we can rule this one out. But probably disassembling the dsdt was a waste of time :-) Regards Sebastian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/