PCI config space is not restored upon resume (macbook pro)
Jung-uk Kim
jkim at FreeBSD.org
Mon Aug 16 18:22:17 UTC 2010
On Monday 16 August 2010 12:46 pm, Oleg Sharoyko wrote:
> On 6 August 2010 08:15, Oleg Sharoyko <osharoiko at gmail.com> wrote:
> >> When using the NVIDIA driver, you will need to make sure that
> >> you're using 256.44, you'll need to be running X at the time of
> >> entry to S3/S4, and you'll need to make sure you've switched
> >> away from X's VT (this didn't happen automatically on FreeBSD
> >> last time I checked).
> >
> > I'll give 256.44 a try, but at first I'll try to fix bios
> > emulation issues.
>
> Sorry for a long delay - it has been a really busy week here. It
> does indeed works with 256.44 just the way you describe. Though I
> had a couple of strange lockups of ACPI subsystem, but I haven't
> had enough time to debug them. I guess other drivers could also
> work if only this wasn't a MacBook. FreeBSD can call BIOS reset,
> but it looks like this doesn't work with MacBook as it has no BIOS,
> and would require to copy video card BIOS into memory and execute
> it in emulation mode. I've seen such a code for linux loader (to
> boot linux in non-emulation mode), but I don't think it worth doing
> this on resume.
I am glad to hear it helped. :-)
In theory, we can shadow video ROM and execute it in emulation *iff*
it actually contains x86 real mode code. It won't be too hard but I
am not sure whether it is worth trying. Are you sure the option ROM
is actually real mode code but not shadowed again after resume? FYI,
you can add a printf() in sys/dev/fb/vesa.c like this to verify, I
think:
if (x86bios_get_orm(0xc0000) == NULL) {
printf("No option ROM found\n");
return (1);
}
Jung-uk Kim
More information about the freebsd-hackers
mailing list