On 4 August 2010 19:12, John Baldwin j...@freebsd.org wrote:
Cool, I actually think that the ACPI PCI-PCI driver can just use the
stock PCI-PCI bridge driver's suspend and resume methods. Can you try
out this alternate patch instead?
It works, and sure looks better than mine. I didn't know
On Wed, Aug 4, 2010 at 11:55 AM, John Baldwin j...@freebsd.org wrote:
On Wednesday, August 04, 2010 12:20:31 pm m...@freebsd.org wrote:
On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin j...@freebsd.org wrote:
On Tuesday, August 03, 2010 9:46:16 pm m...@freebsd.org wrote:
On Fri, Jul 30, 2010 at
On Wed, Aug 4, 2010 at 9:20 AM, m...@freebsd.org wrote:
On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin j...@freebsd.org wrote:
Actually, I would beg to differ in that case. If PCPU_GET(spinlocks)
returns non-NULL, then it means that you hold a spin lock,
ll_count is 0 for the correct
On Thu, Aug 05, 2010 at 09:01:22AM -0700, m...@freebsd.org wrote:
On Wed, Aug 4, 2010 at 9:20 AM, m...@freebsd.org wrote:
On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin j...@freebsd.org wrote:
Actually, I would beg to differ in that case. If PCPU_GET(spinlocks)
returns non-NULL, then it
On Thursday, August 05, 2010 11:30:23 am Oleg Sharoyko wrote:
On 4 August 2010 19:12, John Baldwin j...@freebsd.org wrote:
Cool, I actually think that the ACPI PCI-PCI driver can just use the
stock PCI-PCI bridge driver's suspend and resume methods. Can you try
out this alternate patch
On Thursday, August 05, 2010 12:01:22 pm m...@freebsd.org wrote:
On Wed, Aug 4, 2010 at 9:20 AM, m...@freebsd.org wrote:
On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin j...@freebsd.org wrote:
Actually, I would beg to differ in that case. If PCPU_GET(spinlocks)
returns non-NULL, then it
On 5 August 2010 19:45, John Baldwin j...@freebsd.org wrote:
I'm afraid things are not that simple. I have tried without success
acpi_video.ko,
dmps.ko, sysctl hw.acpi.reset_video and sysutils/vbetool. And what worries
me,
X server cannon start on resumed system. From Xorg.log:
(EE) NV(0):
On Tue, Aug 03, 2010 at 11:46:51AM -0400, Alexander Kabaev wrote:
I have no objection, but think we should cave in and investigate the
possibility of using linker script wrapping libc.so in FreeBSD-9.0:
Below is Linux' counterpart:
/* GNU ld script
Use the shared library, but some
On Thursday, August 05, 2010 11:59:37 am m...@freebsd.org wrote:
On Wed, Aug 4, 2010 at 11:55 AM, John Baldwin j...@freebsd.org wrote:
On Wednesday, August 04, 2010 12:20:31 pm m...@freebsd.org wrote:
On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin j...@freebsd.org wrote:
On Tuesday, August
(gdb) p panic_cpu
$9 = 2
(gdb) p dumptid
$12 = 100751
(gdb) p cpuhead.slh_first-pc_allcpu.sle_next-pc_curthread-td_tid
$14 = 100751
(gdb) p *cpuhead.slh_first-pc_allcpu.sle_next
$6 = {
pc_curthread = 0xff00716d6960,
pc_cpuid = 2,
pc_spinlocks = 0x80803198,
(gdb) p
On Thu, Aug 05, 2010 at 11:41:26AM -0700, Oleg Sharoyko wrote:
(...)
I'm afraid things are not that simple. I have tried without success
acpi_video.ko,
dmps.ko, sysctl hw.acpi.reset_video and sysutils/vbetool. And what worries
me,
X server cannon start on resumed system. From Xorg.log:
On Thursday 05 August 2010 02:41 pm, Oleg Sharoyko wrote:
On 5 August 2010 19:45, John Baldwin j...@freebsd.org wrote:
I'm afraid things are not that simple. I have tried without
success acpi_video.ko,
dmps.ko, sysctl hw.acpi.reset_video and sysutils/vbetool. And
what worries me, X server
On Thursday 05 August 2010 04:00 pm, Christian Zander 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
On Thu, Aug 05, 2010 at 01:35:01PM -0700, Jung-uk Kim 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
On Tue Aug 3 15:22:00 UTC 2010, Jeremie Le Hen wrote:
...
I therefore propose the following change to always link in
libssp_nonshared.a. I think this change is harmless when the symbol is
not needed in one of the objects linked together since the linker won't
pull in the library member
On 6 August 2010 00:23, Jung-uk Kim j...@freebsd.org wrote:
Basically, it means the video ROM is not accessible or failed to POST.
FYI, Mac's don't have BIOS any more. It is just emulated via Boot
Camp. Thus, my guess is the BIOS emulation is not being restored
and/or video ROM is not
On 6 August 2010 00:35, Jung-uk Kim j...@freebsd.org wrote:
We *do* switch VTs unless it is explicitly turned off by 'sysctl
hw.syscons.sc_no_suspend_vtswitch=1'. However, it was slightly
broken but I fixed it recently.
I can confirm that it works on another box with rather recent stable.
On 6 August 2010 00:00, Christian Zander czan...@nvidia.com wrote:
Neither the `nv' nor the `vesa' driver have support for power
management. You'll typically only be able to get X back
with those drivers if you're starting it from scratch following
an S4 cycle, or an S3 cycle that involved a
Hi Kib,
In-Reply-To: 20100629083901.gg13...@deviant.kiev.zoral.com.ua
On Tue, Jun 29, 2010 at 11:39:01AM +0300, Kostik Belousov wrote:
On Tue, Jun 29, 2010 at 10:26:39AM +0200, Marius Strobl wrote:
On Mon, Jun 28, 2010 at 05:48:59PM +0300, Kostik Belousov wrote:
On Wed, Jun 23, 2010 at
19 matches
Mail list logo
