Alexey Starikovskiy wrote: > Alan Jenkins wrote: >> It could be a coincidence. But it's suspicious enough to advise >> caution. We know what the bug is, and we have a very nice workaround >> queued up now. There's no reason to test any more of these specific >> systems to destruction :). >> I did try re-installing off the vendor DVD and it was still broken. >> I fear I bought it from the wrong place to get sympathetic >> _frontline_ support / warrantee. I'm not interested in RMA back to >> Asus - too much work and downtime for a cheap system, when I have an >> easy workaround. I haven't noticed any problems with "noapic". >> >> >> The symptoms strongly suggest overflow in an event buffer or counter >> maintained by the Embedded Controller. So the EC firmware may have a >> bug, of the sort that results in "unspecified behaviour". A bug in a >> special purpose (read: not subject to wide testing) subsystem which >> has direct connections to things like frequency and voltage control. >> >> Hopefully I'm wrong, and I don't really know what I'm talking about >> here. >> >> Regards >> Alan >> > Did you try to disconnect all power resources (e.g. AC adapter and all > batteries and wait for some time)? Yes, I tried leaving it with AC + battery unplugged overnight. > May be there are some default settings in the BIOS? > This looks small enough to be a HW failure... I also upgraded the BIOS to the latest version. And tried the BIOS setup option to restore defaults. Maybe there is some more state, but it's not like a desktop where I can easily remove the CMOS battery. Thanks Alan -- 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
