[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cvs commit: src/sys/dev/acpica acpi.c
- To: Eric Anderson <anderson_(_at_)_centtech_(_dot_)_com>
- Subject: Re: cvs commit: src/sys/dev/acpica acpi.c
- From: Nate Lawson <nate_(_at_)_root_(_dot_)_org>
- Date: Wed, 15 Jun 2005 13:11:03 -0700
- Cc: freebsd-acpi_(_at_)_FreeBSD_(_dot_)_org, John Baldwin <jhb_(_at_)_FreeBSD_(_dot_)_org>
Eric Anderson wrote:
Ok - I've narrowed it down. A GENERIC kernel will go into S3 just fine
on this laptop. Removing apic from the kernel will break that.
It is interesting that the suspend path without the apic support causes
a hang for you. This should be investigated. Does it work if you have
apic compiled in but boot with hint.apic.0.disabled="1" ? Any ideas
where to look John?
I've also run into some bugs with having smp in the kernel and certain
modules, so beware.
Now, I can successfully go into S3, but coming back out (using the lid
switch button or the power button are the only ways I know of) seems to
reboot the machine. Maybe I should say that I can't tell if it's
rebooting the machine, or if the machine just 'powers up' as if it was
Oh - and here's what it looks like when it goes to sleep:
acpi_lid0: Lid closed
acpi_lid0: wake_prep enabled for \_SB_.LID_ (S3)
acpi_button0: wake_prep enabled for \_SB_.PBTN (S3)
uhci0: wake_prep disabled wake for \_SB_.PCI0.USB0 (S3)
uhci1: wake_prep disabled wake for \_SB_.PCI0.USB1 (S3)
uhci2: wake_prep disabled wake for \_SB_.PCI0.USB2 (S3)
uhci3: wake_prep disabled wake for \_SB_.PCI0.USB4 (S3)
ehci0: wake_prep disabled wake for \_SB_.PCI0.USB3 (S3)
This is acpi enabling devices to wake the system from S3 and disabling
others. This is done before running all DEVICE_SUSPEND methods since
those could potentially power down the device, and then it won't be able
to do the wake prep. (Unlikely since it is the chipset which does the
wake enable function but still just being careful.)
You could disable this by commenting out the acpi_wake_prep_walk(state)
call in acpi_SetSleepState(). I doubt this will change anything.
pci2:0:0: Transition from D0 to D3
vga0: saving 68 bytes of video state
pci0:31:2: Transition from D0 to D3
You could disable PCI power state support with hw.pci.do_power_state="0"
ioapic_suspend: not implemented!
ioapic_suspend: not implemented!
I still think this needs to be implemented although it's not likely to
be your problem.
======== acpi_printcpu() debug dump ========
gdt[0097:c09c7380] idt[07ff:c09c7ea0] ldt tr efl
eax ebx[c23ccc80] ecx edx
esi edi ebp[e3618c5c] esp[e3618c40]
cr0[8005003b] cr2[2813d704] cr3[00c1e000] cr4
cs ds es fs gs[003b] ss
No - it boots up like I had it powered off. Anything I can debug to
figure that out?
When it's suspended, is the sleep light on or are all lights off like it
is already powered off? If it's on, it is likely actually suspended.
On power up, it's possible your bios doesn't even call the wake vector.
There was a beep patch I never committed from takawata that can be
used to see if your bios even calls the asm wake code. imp has it
somewhere. Try disabling the calls to video reset in the wake code
(hw.acpi.reset_video=0). Basically, you see if you're even executing
the wake code.
freebsd-acpi_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe_(_at_)_freebsd_(_dot_)_org"
Visit your host, monkey.org