Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 Mar 2005 18:23:35 +0100
From:      Filippo Forti <filippo.forti@fastwebnet.it>
To:        Ian Dowse <iedowse@maths.tcd.ie>
Cc:        Nate Lawson <nate@root.org>
Subject:   Re: Panic on suspend
Message-ID:  <20050303172334.GA674@portatile.fastwebnet.it>
In-Reply-To: <200503030132.aa82163@salmon.maths.tcd.ie>
References:  <20050302165516.GB674@portatile.fastwebnet.it> <200503030132.aa82163@salmon.maths.tcd.ie>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 03, 2005 at 01:32:29AM +0000, Ian Dowse wrote:
> In message <20050302165516.GB674@portatile.fastwebnet.it>, Filippo Forti writes
> :
> >On Tue, Mar 01, 2005 at 03:19:42PM -0800, Nate Lawson wrote:
> >> That is in the VGA BIOS.  Try setting this sysctl before suspending:
> >> 
> >> hw.acpi.reset_video=0
> >Unfortunately this doesn't make the trick
> >Thanks anyway
> 
> Did updating to the version 1.49 of vesa.c fix the crash for you?
> There is a new patch at:
> 
> 	http://people.freebsd.org/~iedowse/vesa_restore.diff
> 
> This needs to be applied on top of version 1.49, and should hopefully
> correct the behaviour when the VESA state requires more than 4k of
> space. Would you be able to test that this version does not crash
> for you on suspend?
> 
Thanks,
it's much better now, even if I still have a problem (the laptop reboots
instead of resuming from sleep), but I'll google to find a solution

> I don't fully understand why the previous version was faulting at
> 0x2000, since that page should have been mapped into the VM86 address
> space. However my code was definitely handling the kernel virtual
> addresses incorrectly, so maybe that was causing something to be
> overwritten. The updated patch allocates a contiguous virtual buffer
> and then maps each page into the VM86 address space starting at
> 0x1000.
> 
> Ian

Filippo



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050303172334.GA674>