The abrupt merging of...
The abrupt merging of...
Posted Dec 16, 2009 13:33 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)In reply to: The abrupt merging of... by mjthayer
Parent article: The abrupt merging of Nouveau
Posted Dec 16, 2009 13:47 UTC (Wed)
by mjthayer (guest, #39183)
[Link] (3 responses)
Posted Dec 16, 2009 14:53 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Posted Dec 17, 2009 18:39 UTC (Thu)
by mjthayer (guest, #39183)
[Link] (1 responses)
Posted Dec 17, 2009 18:49 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
Performing a full resume cycle is hard. You need to reprogram the memory controller, bring the
The abrupt merging of...
that the last doesn't apply to the CPU, but I don't know much about DRAM) that this can't be done
by driver code without reading ACPI information?
The abrupt merging of...
kernel can't put code there, so performing suspend to RAM on commodity x86 without firmware
assistance is impossible.
The abrupt merging of...
> The kernel can't put code there, so performing suspend to RAM on commodity x86 without
> firmware assistance is impossible.
Is there really no known way to do this without assistance from the ACPI BIOS? I'm no expert, but
my understanding was that DOS extenders did this all the time to switch from protected back to
real mode at a time when there was no ACPI.
The abrupt merging of...
from scratch as far as it's concerned. It's up to the BIOS to check a flag to determine whether it's a
cold power on or a resume.
embedded controller up, dump values back into the thermal monitoring hardware and any number
of low-level initialisations. Only once that's been done does control get passed back to the OS,
which has absolutely no idea how any of that hardware works.