Messages in this thread | | | Date | Sat, 05 Feb 2005 01:52:23 +0100 | From | Carl-Daniel Hailfinger <> | Subject | Re: [RFC] Reliable video POSTing on resume |
| |
Jon Smirl schrieb: > On Fri, 4 Feb 2005 08:44:54 +0100, Pavel Machek <pavel@ucw.cz> wrote: > >>We already try to do that, but it hangs on 70% of machines. See >>Documentation/power/video.txt. > > We know that all of these ROMs are run at power on so they have to > work. This implies that there must be something wrong with the > environment the ROM are being run in. Video ROMs make calls into the > INT vectors of the system BIOS. If these haven't been set up yet > running the VBIOS is sure to hang. Has someone with ROM source and > the appropriate debugging tools tried to debug one of these hangs? > Alternatively code could be added to wakeup.S to try and set these up > or dump the ones that are there and see if they are sane.
My problem (Samsung P35) is that the BIOS wants to call code which is no longer mapped because the BIOS is too big to fit into the standard area. Since that additional area has been overwritten, we are out of luck. Maybe if we did something like backing up all untouched real mode memory immediately after switching to protected mode, it could work. But I don't know whether that is feasible on boot. Anyways, you don't want to run possibly buggy closed source bios code in an environment where a single random memory write may corrupt the kernel without debuggability.
And sometimes there is BIOS code which is can't be run twice. Period. Don't believe that one? I have a machine where calling EDD code in the BIOS twice will hang the second time. See boot parameter edd=off for reference :-(
So I agree that we could try to preserve the state better, but I also can guarantee you it won't help everywhere.
Regards, Carl-Daniel -- http://www.hailfinger.org/ - 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/
| |