Messages in this thread | | | Date | Thu, 11 Jan 2007 23:01:30 +0300 | From | Alexey Starikovskiy <> | Subject | Re: Sony Vaio VGN-SZ340 (was Re: sonypc with Sony Vaio VGN-SZ1VP) |
| |
Len Brown wrote: > On Friday 05 January 2007 23:09, Bjorn Helgaas wrote: > >> On Friday 05 January 2007 11:10, Len Brown wrote: >> >>> On Friday 05 January 2007 12:24, MoRpHeUz wrote: >>> >>>>> What workaround are you using? >>>>> >>>> This one: http://bugzilla.kernel.org/show_bug.cgi?id=7465 >>>> >>> Ah yes, the duplicate MADT issue is clearly a BIOS bug. >>> It is possible that we can tweak our Linux workaround for it to be more >>> Microsoft Windows Bug Compatbile(TM). >>> >> Maybe Windows discovers processors using the namespace rather >> than the MADT. >> > > Nod. > > Based on the fact that the 1st MADT on this box is toast, they're not using that. > If the last one also doesn't work universally, then they must be using the namespace. > > For us to do the same would be a relatively significant change -- as it means > we either have to push SMP startup after the interpreter init, or move the > interpreter init yet sooner. > > In general, over the last couple of years, we've been forced for compatibility > with various systems to move ACPI initialization sooner and sooner. > (I think the last issue was getting the HW into "ACPI mode" sooner > because some stuff I don't recall didn't work if we didn't) > It would probably make sense to experiment with what the soonest we > can initialize ACPI, as I have a feeling we're going to have to head that way. > > -Len > - > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
If any of the two tables does not work, may be we need both together?
Regards, Alex. - 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/
| |