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
On 6 August 2010 00:00, Christian Zander 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 POST (either
>
On 6 August 2010 00:35, Jung-uk Kim 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.
--
Oleg Sharoy
On 6 August 2010 00:23, Jung-uk Kim 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 shadowed prope
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 "ssp-lo
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
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 automa
On Thursday 05 August 2010 02:41 pm, Oleg Sharoyko wrote:
> On 5 August 2010 19:45, John Baldwin 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 can
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. F
>> (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 = 0xff
On Thursday, August 05, 2010 11:59:37 am m...@freebsd.org wrote:
> On Wed, Aug 4, 2010 at 11:55 AM, John Baldwin 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 wrote:
> >> > On Tuesday, August 03, 2010 9:46:16 pm m...
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 s
On 5 August 2010 19:45, John Baldwin 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): Fail
On Thursday, August 05, 2010 12:01:22 pm m...@freebsd.org wrote:
> On Wed, Aug 4, 2010 at 9:20 AM, wrote:
> > On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin 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 l
On Thursday, August 05, 2010 11:30:23 am Oleg Sharoyko wrote:
> On 4 August 2010 19:12, John Baldwin 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?
>
On Thu, Aug 05, 2010 at 09:01:22AM -0700, m...@freebsd.org wrote:
> On Wed, Aug 4, 2010 at 9:20 AM, wrote:
> > On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin 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
On Wed, Aug 4, 2010 at 9:20 AM, wrote:
> On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin 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" pc_spinlocks and non-zero for th
On Wed, Aug 4, 2010 at 11:55 AM, John Baldwin 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 wrote:
>> > On Tuesday, August 03, 2010 9:46:16 pm m...@freebsd.org wrote:
>> >> On Fri, Jul 30, 2010 at 2:31 PM, John Baldwin
On 4 August 2010 19:12, John Baldwin 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 there's such a
19 matches
Mail list logo
