Resume failed after Suspend on Thinkpad x201i

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Resume failed after Suspend on Thinkpad x201i

乔楚/HonestQiao
Follow by step in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html
#sysctl debug.bootverbose=1
#sysctl debug.acpi.suspend_bounce=1
#acpiconf -s 3    (or push Fn+F3)

After a moment, the display is light and black, LED Sleep is light.
But it cant be resume. No button can do resume.

Some useful info:
hw.acpi : http://pastebin.com/zknEPdVS
acpidump : http://pastebin.com/uH4hXywR
dmesg : http://pastebin.com/wdqi7mfW

In /var/log/message: http://pastebin.com/fcWKMUd7
Jul  2 16:43:22 x201i acpi: suspend at 20120702 16:43:22
[It Can't resume, so I push power force to close my x201. ]
Jul  2 16:52:11 x201i syslogd: kernel boot file is /boot/kernel/kernel

#uname -a
FreeBSD x201i.honestqiao 9.0-STABLE FreeBSD 9.0-STABLE #0: Wed Jun 13 22:36:36 CST 2012     [hidden email]:/usr/obj/usr/src/sys/GENERIC  amd64
#vmstat -i
interrupt                          total       rate
irq1: atkbd0                          16          0
irq9: acpi0                          727          4
irq19: ehci1                         338          2
irq23: ehci0                         255          1
cpu0:timer                          7607         50
irq264: em0                          135          0
irq265: hdac0                         66          0
irq266: iwn0                       15781        105
irq267: ahci0                       5732         38
cpu1:timer                          1578         10
cpu3:timer                          1819         12
cpu2:timer                          1510         10
irq268: vgapci0                        3          0
Total                              35567        237

#kldstat
Id Refs Address            Size     Name
 1   85 0xffffffff80200000 1301fa8  kernel
 2    1 0xffffffff81502000 2087f0   zfs.ko
 3    2 0xffffffff8170b000 5c68     opensolaris.ko
 4    2 0xffffffff81711000 484e0    linux.ko
 5    1 0xffffffff8175a000 f4d8     aio.ko
 6    1 0xffffffff8176a000 29e0     coretemp.ko
 7    1 0xffffffff8176d000 3028     amdtemp.ko
 8    1 0xffffffff81771000 27398    drm.ko
 9    1 0xffffffff81799000 ba40     mmc.ko
10    1 0xffffffff817a5000 4218     mmcsd.ko
12    1 0xffffffff817b0000 6568     cuse4bsd.ko
13    1 0xffffffff817b7000 de08     tmpfs.ko
14    3 0xffffffff817c5000 8ab0     libiconv.ko
15    1 0xffffffff817ce000 24c8     libmchain.ko
16    1 0xffffffff817d1000 11c8     cd9660_iconv.ko
17    1 0xffffffff817d3000 11e0     msdosfs_iconv.ko
18    1 0xffffffff817d5000 10768    cpufreq.ko
19    1 0xffffffff817e6000 59b8     acpi_ibm.ko
20    1 0xffffffff817ec000 6668     sem.ko
21    1 0xffffffff81a12000 15c2     fdescfs.ko
22    1 0xffffffff81a14000 3dfd     linprocfs.ko
23    1 0xffffffff81a18000 a9bb     fuse.ko
24    1 0xffffffff81a23000 5f7b7    i915kms.ko
25    1 0xffffffff81a83000 123d     iicbb.ko
26    4 0xffffffff81a85000 12ff     iicbus.ko
27    1 0xffffffff81a87000 dc9      iic.ko
28    1 0xffffffff81a88000 2be29    drm2.ko

#sysctl dev.acpi_ibm
dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras
dev.acpi_ibm.0.%driver: acpi_ibm
dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY
dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0
dev.acpi_ibm.0.%parent: acpi0
dev.acpi_ibm.0.initialmask: 2060
dev.acpi_ibm.0.availmask: 134217727
dev.acpi_ibm.0.events: 1
dev.acpi_ibm.0.eventmask: 134217727
dev.acpi_ibm.0.hotkey: 388
dev.acpi_ibm.0.lcd_brightness: 0
dev.acpi_ibm.0.volume: 7
dev.acpi_ibm.0.mute: 0
dev.acpi_ibm.0.thinklight: 0
dev.acpi_ibm.0.bluetooth: 0
dev.acpi_ibm.0.wlan: 1
dev.acpi_ibm.0.fan_speed: 3265
dev.acpi_ibm.0.fan_level: 2
dev.acpi_ibm.0.fan: 0

--------------
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Resume failed after Suspend on Thinkpad x201i

Matt-332
On 07/02/12 02:29, 乔楚/HonestQiao wrote:

> Follow by step in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html
> #sysctl debug.bootverbose=1
> #sysctl debug.acpi.suspend_bounce=1
> #acpiconf -s 3    (or push Fn+F3)
>
> After a moment, the display is light and black, LED Sleep is light.
> But it cant be resume. No button can do resume.
>
> Some useful info:
> hw.acpi : http://pastebin.com/zknEPdVS
> acpidump : http://pastebin.com/uH4hXywR
> dmesg : http://pastebin.com/wdqi7mfW
>
> In /var/log/message: http://pastebin.com/fcWKMUd7
> Jul  2 16:43:22 x201i acpi: suspend at 20120702 16:43:22
> [It Can't resume, so I push power force to close my x201. ]
> Jul  2 16:52:11 x201i syslogd: kernel boot file is /boot/kernel/kernel
>
> #uname -a
> FreeBSD x201i.honestqiao 9.0-STABLE FreeBSD 9.0-STABLE #0: Wed Jun 13 22:36:36 CST 2012     [hidden email]:/usr/obj/usr/src/sys/GENERIC  amd64
> #vmstat -i
> interrupt                          total       rate
> irq1: atkbd0                          16          0
> irq9: acpi0                          727          4
> irq19: ehci1                         338          2
> irq23: ehci0                         255          1
> cpu0:timer                          7607         50
> irq264: em0                          135          0
> irq265: hdac0                         66          0
> irq266: iwn0                       15781        105
> irq267: ahci0                       5732         38
> cpu1:timer                          1578         10
> cpu3:timer                          1819         12
> cpu2:timer                          1510         10
> irq268: vgapci0                        3          0
> Total                              35567        237
>
> #kldstat
> Id Refs Address            Size     Name
>   1   85 0xffffffff80200000 1301fa8  kernel
>   2    1 0xffffffff81502000 2087f0   zfs.ko
>   3    2 0xffffffff8170b000 5c68     opensolaris.ko
>   4    2 0xffffffff81711000 484e0    linux.ko
>   5    1 0xffffffff8175a000 f4d8     aio.ko
>   6    1 0xffffffff8176a000 29e0     coretemp.ko
>   7    1 0xffffffff8176d000 3028     amdtemp.ko
>   8    1 0xffffffff81771000 27398    drm.ko
>   9    1 0xffffffff81799000 ba40     mmc.ko
> 10    1 0xffffffff817a5000 4218     mmcsd.ko
> 12    1 0xffffffff817b0000 6568     cuse4bsd.ko
> 13    1 0xffffffff817b7000 de08     tmpfs.ko
> 14    3 0xffffffff817c5000 8ab0     libiconv.ko
> 15    1 0xffffffff817ce000 24c8     libmchain.ko
> 16    1 0xffffffff817d1000 11c8     cd9660_iconv.ko
> 17    1 0xffffffff817d3000 11e0     msdosfs_iconv.ko
> 18    1 0xffffffff817d5000 10768    cpufreq.ko
> 19    1 0xffffffff817e6000 59b8     acpi_ibm.ko
> 20    1 0xffffffff817ec000 6668     sem.ko
> 21    1 0xffffffff81a12000 15c2     fdescfs.ko
> 22    1 0xffffffff81a14000 3dfd     linprocfs.ko
> 23    1 0xffffffff81a18000 a9bb     fuse.ko
> 24    1 0xffffffff81a23000 5f7b7    i915kms.ko
> 25    1 0xffffffff81a83000 123d     iicbb.ko
> 26    4 0xffffffff81a85000 12ff     iicbus.ko
> 27    1 0xffffffff81a87000 dc9      iic.ko
> 28    1 0xffffffff81a88000 2be29    drm2.ko
>
> #sysctl dev.acpi_ibm
> dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras
> dev.acpi_ibm.0.%driver: acpi_ibm
> dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY
> dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0
> dev.acpi_ibm.0.%parent: acpi0
> dev.acpi_ibm.0.initialmask: 2060
> dev.acpi_ibm.0.availmask: 134217727
> dev.acpi_ibm.0.events: 1
> dev.acpi_ibm.0.eventmask: 134217727
> dev.acpi_ibm.0.hotkey: 388
> dev.acpi_ibm.0.lcd_brightness: 0
> dev.acpi_ibm.0.volume: 7
> dev.acpi_ibm.0.mute: 0
> dev.acpi_ibm.0.thinklight: 0
> dev.acpi_ibm.0.bluetooth: 0
> dev.acpi_ibm.0.wlan: 1
> dev.acpi_ibm.0.fan_speed: 3265
> dev.acpi_ibm.0.fan_level: 2
> dev.acpi_ibm.0.fan: 0
>
> --------------
>
>
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "[hidden email]"
Try setting hw.pci.do_power_resume and hw.pci.do_power_suspend to 0,
then try each at 1, then try both at 1.

Many times Thinkpads fail to resume because of something import getting
turned off that needs to be on during suspend, or by trying to turn on
things that don't like that during resume. Almost all my thinkpads have
required some combo of the above settings.

Also, try these tests in single user, to rule out some 3rd party kernel
modules you have there.

Matt

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Re: Resume failed after Suspend on Thinkpad x201i

乔楚/HonestQiao
>On 07/02/12 02:29, 乔楚/HonestQiao wrote:

>> Follow by step in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html
>> #sysctl debug.bootverbose=1
>> #sysctl debug.acpi.suspend_bounce=1
>> #acpiconf -s 3    (or push Fn+F3)
>>
>> After a moment, the display is light and black, LED Sleep is light.
>> But it cant be resume. No button can do resume.
>>
>> Some useful info:
>> hw.acpi : http://pastebin.com/zknEPdVS
>> acpidump : http://pastebin.com/uH4hXywR
>> dmesg : http://pastebin.com/wdqi7mfW
>>
>> In /var/log/message: http://pastebin.com/fcWKMUd7
>> Jul  2 16:43:22 x201i acpi: suspend at 20120702 16:43:22
>> [It Can't resume, so I push power force to close my x201. ]
>> Jul  2 16:52:11 x201i syslogd: kernel boot file is /boot/kernel/kernel
>>
>> #uname -a
>> FreeBSD x201i.honestqiao 9.0-STABLE FreeBSD 9.0-STABLE #0: Wed Jun 13 22:36:36 CST 2012     [hidden email]:/usr/obj/usr/src/sys/GENERIC  amd64
>> #vmstat -i
>> interrupt                          total       rate
>> irq1: atkbd0                          16          0
>> irq9: acpi0                          727          4
>> irq19: ehci1                         338          2
>> irq23: ehci0                         255          1
>> cpu0:timer                          7607         50
>> irq264: em0                          135          0
>> irq265: hdac0                         66          0
>> irq266: iwn0                       15781        105
>> irq267: ahci0                       5732         38
>> cpu1:timer                          1578         10
>> cpu3:timer                          1819         12
>> cpu2:timer                          1510         10
>> irq268: vgapci0                        3          0
>> Total                              35567        237
>>
>> #kldstat
>> Id Refs Address            Size     Name
>>   1   85 0xffffffff80200000 1301fa8  kernel
>>   2    1 0xffffffff81502000 2087f0   zfs.ko
>>   3    2 0xffffffff8170b000 5c68     opensolaris.ko
>>   4    2 0xffffffff81711000 484e0    linux.ko
>>   5    1 0xffffffff8175a000 f4d8     aio.ko
>>   6    1 0xffffffff8176a000 29e0     coretemp.ko
>>   7    1 0xffffffff8176d000 3028     amdtemp.ko
>>   8    1 0xffffffff81771000 27398    drm.ko
>>   9    1 0xffffffff81799000 ba40     mmc.ko
>> 10    1 0xffffffff817a5000 4218     mmcsd.ko
>> 12    1 0xffffffff817b0000 6568     cuse4bsd.ko
>> 13    1 0xffffffff817b7000 de08     tmpfs.ko
>> 14    3 0xffffffff817c5000 8ab0     libiconv.ko
>> 15    1 0xffffffff817ce000 24c8     libmchain.ko
>> 16    1 0xffffffff817d1000 11c8     cd9660_iconv.ko
>> 17    1 0xffffffff817d3000 11e0     msdosfs_iconv.ko
>> 18    1 0xffffffff817d5000 10768    cpufreq.ko
>> 19    1 0xffffffff817e6000 59b8     acpi_ibm.ko
>> 20    1 0xffffffff817ec000 6668     sem.ko
>> 21    1 0xffffffff81a12000 15c2     fdescfs.ko
>> 22    1 0xffffffff81a14000 3dfd     linprocfs.ko
>> 23    1 0xffffffff81a18000 a9bb     fuse.ko
>> 24    1 0xffffffff81a23000 5f7b7    i915kms.ko
>> 25    1 0xffffffff81a83000 123d     iicbb.ko
>> 26    4 0xffffffff81a85000 12ff     iicbus.ko
>> 27    1 0xffffffff81a87000 dc9      iic.ko
>> 28    1 0xffffffff81a88000 2be29    drm2.ko
>>
>> #sysctl dev.acpi_ibm
>> dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras
>> dev.acpi_ibm.0.%driver: acpi_ibm
>> dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY
>> dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0
>> dev.acpi_ibm.0.%parent: acpi0
>> dev.acpi_ibm.0.initialmask: 2060
>> dev.acpi_ibm.0.availmask: 134217727
>> dev.acpi_ibm.0.events: 1
>> dev.acpi_ibm.0.eventmask: 134217727
>> dev.acpi_ibm.0.hotkey: 388
>> dev.acpi_ibm.0.lcd_brightness: 0
>> dev.acpi_ibm.0.volume: 7
>> dev.acpi_ibm.0.mute: 0
>> dev.acpi_ibm.0.thinklight: 0
>> dev.acpi_ibm.0.bluetooth: 0
>> dev.acpi_ibm.0.wlan: 1
>> dev.acpi_ibm.0.fan_speed: 3265
>> dev.acpi_ibm.0.fan_level: 2
>> dev.acpi_ibm.0.fan: 0
>>
>> --------------
>>
>>
>> _______________________________________________
>> [hidden email] mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>> To unsubscribe, send any mail to "[hidden email]"
>Try setting hw.pci.do_power_resume and hw.pci.do_power_suspend to 0,
>then try each at 1, then try both at 1.
>
>Many times Thinkpads fail to resume because of something import getting
>turned off that needs to be on during suspend, or by trying to turn on
>things that don't like that during resume. Almost all my thinkpads have
>required some combo of the above settings.
>
>Also, try these tests in single user, to rule out some 3rd party kernel
>modules you have there.
>
>Matt
>
>
#kldstat
kernel zfs.ko opensolaris.ko acpi_ibm.ko
#cat /root/set.sh
#!/bin/csh
sysclt -w sysctl debug.bootverbose=1
sysclt -w sysctl debug.acpi.suspend_bounce=1


sysclt -w hw.acpi.reset_video="$argv[1]"
sysclt -w hw.pci.do_power_resume="$argv[2]"
sysclt -w hw.pci.do_power_suspend="$argv[3]"

Test:(8 times)
/root/set.sh 0 0 0; acpiconf -s 3
/root/set.sh 0 0 1; acpiconf -s 3
/root/set.sh 0 1 0; acpiconf -s 3
/root/set.sh 0 1 1; acpiconf -s 3

/root/set.sh 1 0 0; acpiconf -s 3
/root/set.sh 1 0 1; acpiconf -s 3
/root/set.sh 1 1 0; acpiconf -s 3
/root/set.sh 1 1 1; acpiconf -s 3

In All the test, the screen is light and black, system is hangup, nothing can be done.
The only thing can be done, is push power button, to force it shutdown.

In single user mode, the problem remains the same.
Load or UnLoad acpi_ibm.ko, no effect on.

Maybe Suspend isn't success.

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Resume failed after Suspend on Thinkpad x201i

Peter Zehm-3
Am 03.07.2012 08:11, schrieb 乔楚/HonestQiao:

> #kldstat
> kernel zfs.ko opensolaris.ko acpi_ibm.ko
> #cat /root/set.sh
> #!/bin/csh
> sysclt -w sysctl debug.bootverbose=1
> sysclt -w sysctl debug.acpi.suspend_bounce=1
>
>
> sysclt -w hw.acpi.reset_video="$argv[1]"
> sysclt -w hw.pci.do_power_resume="$argv[2]"
> sysclt -w hw.pci.do_power_suspend="$argv[3]"
>
> Test:(8 times)
> /root/set.sh 0 0 0; acpiconf -s 3
> /root/set.sh 0 0 1; acpiconf -s 3
> /root/set.sh 0 1 0; acpiconf -s 3
> /root/set.sh 0 1 1; acpiconf -s 3
>
> /root/set.sh 1 0 0; acpiconf -s 3
> /root/set.sh 1 0 1; acpiconf -s 3
> /root/set.sh 1 1 0; acpiconf -s 3
> /root/set.sh 1 1 1; acpiconf -s 3
>
> In All the test, the screen is light and black, system is hangup, nothing can be done.
> The only thing can be done, is push power button, to force it shutdown.
>
> In single user mode, the problem remains the same.
> Load or UnLoad acpi_ibm.ko, no effect on.
>
> Maybe Suspend isn't success.
Your script seems to try to execute "sysclt" instead of "sysctl". Just
want to get sure this is only a typo in your mail not in the script itsself.

Regards
Peter
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Re: Resume failed after Suspend on Thinkpad x201i

clutton-2
In reply to this post by 乔楚/HonestQiao
On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote:

> >On 07/02/12 02:29, 乔楚/HonestQiao wrote:
> >> Follow by step in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html
> >> #sysctl debug.bootverbose=1
> >> #sysctl debug.acpi.suspend_bounce=1
> >> #acpiconf -s 3    (or push Fn+F3)
> >>
> >> After a moment, the display is light and black, LED Sleep is light.
> >> But it cant be resume. No button can do resume.
> >>
> >> Some useful info:
> >> hw.acpi : http://pastebin.com/zknEPdVS
> >> acpidump : http://pastebin.com/uH4hXywR
> >> dmesg : http://pastebin.com/wdqi7mfW
> >>
> >> In /var/log/message: http://pastebin.com/fcWKMUd7
> >> Jul  2 16:43:22 x201i acpi: suspend at 20120702 16:43:22
> >> [It Can't resume, so I push power force to close my x201. ]
> >> Jul  2 16:52:11 x201i syslogd: kernel boot file is /boot/kernel/kernel
> >>
> >> #uname -a
> >> FreeBSD x201i.honestqiao 9.0-STABLE FreeBSD 9.0-STABLE #0: Wed Jun 13 22:36:36 CST 2012     [hidden email]:/usr/obj/usr/src/sys/GENERIC  amd64
> >> #vmstat -i
> >> interrupt                          total       rate
> >> irq1: atkbd0                          16          0
> >> irq9: acpi0                          727          4
> >> irq19: ehci1                         338          2
> >> irq23: ehci0                         255          1
> >> cpu0:timer                          7607         50
> >> irq264: em0                          135          0
> >> irq265: hdac0                         66          0
> >> irq266: iwn0                       15781        105
> >> irq267: ahci0                       5732         38
> >> cpu1:timer                          1578         10
> >> cpu3:timer                          1819         12
> >> cpu2:timer                          1510         10
> >> irq268: vgapci0                        3          0
> >> Total                              35567        237
> >>
> >> #kldstat
> >> Id Refs Address            Size     Name
> >>   1   85 0xffffffff80200000 1301fa8  kernel
> >>   2    1 0xffffffff81502000 2087f0   zfs.ko
> >>   3    2 0xffffffff8170b000 5c68     opensolaris.ko
> >>   4    2 0xffffffff81711000 484e0    linux.ko
> >>   5    1 0xffffffff8175a000 f4d8     aio.ko
> >>   6    1 0xffffffff8176a000 29e0     coretemp.ko
> >>   7    1 0xffffffff8176d000 3028     amdtemp.ko
> >>   8    1 0xffffffff81771000 27398    drm.ko
> >>   9    1 0xffffffff81799000 ba40     mmc.ko
> >> 10    1 0xffffffff817a5000 4218     mmcsd.ko
> >> 12    1 0xffffffff817b0000 6568     cuse4bsd.ko
> >> 13    1 0xffffffff817b7000 de08     tmpfs.ko
> >> 14    3 0xffffffff817c5000 8ab0     libiconv.ko
> >> 15    1 0xffffffff817ce000 24c8     libmchain.ko
> >> 16    1 0xffffffff817d1000 11c8     cd9660_iconv.ko
> >> 17    1 0xffffffff817d3000 11e0     msdosfs_iconv.ko
> >> 18    1 0xffffffff817d5000 10768    cpufreq.ko
> >> 19    1 0xffffffff817e6000 59b8     acpi_ibm.ko
> >> 20    1 0xffffffff817ec000 6668     sem.ko
> >> 21    1 0xffffffff81a12000 15c2     fdescfs.ko
> >> 22    1 0xffffffff81a14000 3dfd     linprocfs.ko
> >> 23    1 0xffffffff81a18000 a9bb     fuse.ko
> >> 24    1 0xffffffff81a23000 5f7b7    i915kms.ko
> >> 25    1 0xffffffff81a83000 123d     iicbb.ko
> >> 26    4 0xffffffff81a85000 12ff     iicbus.ko
> >> 27    1 0xffffffff81a87000 dc9      iic.ko
> >> 28    1 0xffffffff81a88000 2be29    drm2.ko
> >>
> >> #sysctl dev.acpi_ibm
> >> dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras
> >> dev.acpi_ibm.0.%driver: acpi_ibm
> >> dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY
> >> dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0
> >> dev.acpi_ibm.0.%parent: acpi0
> >> dev.acpi_ibm.0.initialmask: 2060
> >> dev.acpi_ibm.0.availmask: 134217727
> >> dev.acpi_ibm.0.events: 1
> >> dev.acpi_ibm.0.eventmask: 134217727
> >> dev.acpi_ibm.0.hotkey: 388
> >> dev.acpi_ibm.0.lcd_brightness: 0
> >> dev.acpi_ibm.0.volume: 7
> >> dev.acpi_ibm.0.mute: 0
> >> dev.acpi_ibm.0.thinklight: 0
> >> dev.acpi_ibm.0.bluetooth: 0
> >> dev.acpi_ibm.0.wlan: 1
> >> dev.acpi_ibm.0.fan_speed: 3265
> >> dev.acpi_ibm.0.fan_level: 2
> >> dev.acpi_ibm.0.fan: 0
> >>
> >> --------------
> >>
> >>
> >> _______________________________________________
> >> [hidden email] mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> >> To unsubscribe, send any mail to "[hidden email]"
> >Try setting hw.pci.do_power_resume and hw.pci.do_power_suspend to 0,
> >then try each at 1, then try both at 1.
> >
> >Many times Thinkpads fail to resume because of something import getting
> >turned off that needs to be on during suspend, or by trying to turn on
> >things that don't like that during resume. Almost all my thinkpads have
> >required some combo of the above settings.
> >
> >Also, try these tests in single user, to rule out some 3rd party kernel
> >modules you have there.
> >
> >Matt
> >
> >
>
> #kldstat
> kernel zfs.ko opensolaris.ko acpi_ibm.ko
> #cat /root/set.sh
> #!/bin/csh
> sysclt -w sysctl debug.bootverbose=1
> sysclt -w sysctl debug.acpi.suspend_bounce=1
>
>
> sysclt -w hw.acpi.reset_video="$argv[1]"
> sysclt -w hw.pci.do_power_resume="$argv[2]"
> sysclt -w hw.pci.do_power_suspend="$argv[3]"
>
> Test:(8 times)
> /root/set.sh 0 0 0; acpiconf -s 3
> /root/set.sh 0 0 1; acpiconf -s 3
> /root/set.sh 0 1 0; acpiconf -s 3
> /root/set.sh 0 1 1; acpiconf -s 3
>
> /root/set.sh 1 0 0; acpiconf -s 3
> /root/set.sh 1 0 1; acpiconf -s 3
> /root/set.sh 1 1 0; acpiconf -s 3
> /root/set.sh 1 1 1; acpiconf -s 3
>
> In All the test, the screen is light and black, system is hangup, nothing can be done.
> The only thing can be done, is push power button, to force it shutdown.

Which graphic card have you used? If you have had nvidia, it's normal,
I've had the same problem "the screen is light and black".

> In single user mode, the problem remains the same.
> Load or UnLoad acpi_ibm.ko, no effect on.
>
> Maybe Suspend isn't success.
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "[hidden email]"


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Re: Resume failed after Suspend on Thinkpad x201i

Brandon Gooch
On Wed, Jul 4, 2012 at 4:23 PM, mbsd <[hidden email]> wrote:
> On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote:
[SNIP]
>>
>> In All the test, the screen is light and black, system is hangup, nothing can be done.
>> The only thing can be done, is push power button, to force it shutdown.
>
> Which graphic card have you used? If you have had nvidia, it's normal,
> I've had the same problem "the screen is light and black".

Can both of you show the output of `devinfo -v` from your systems?

I was able to solve my suspend/resume issue with my nvidia-equipped
notebook by forcing the module load ordering of vgapm in
sys/isa/vga_isa.c:

Index: sys/isa/vga_isa.c
===================================================================
--- sys/isa/vga_isa.c   (revision 237779)
+++ sys/isa/vga_isa.c   (working copy)
@@ -379,4 +379,4 @@
        0
 };

-DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0);
+DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, SI_ORDER_ANY);


The system requires however that I load the nvidia module in
/boot/loader.conf (as opposed to loading it after system is up and
running).

-Brandon
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Re: Resume failed after Suspend on Thinkpad x201i

乔楚/HonestQiao
>On Wed, Jul 4, 2012 at 4:23 PM, mbsd <[hidden email]> wrote:

>> On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote:
>[SNIP]
>>>
>>> In All the test, the screen is light and black, system is hangup, nothing can be done.
>>> The only thing can be done, is push power button, to force it shutdown.
>>
>> Which graphic card have you used? If you have had nvidia, it's normal,
>> I've had the same problem "the screen is light and black".
>
>Can both of you show the output of `devinfo -v` from your systems?
>
>I was able to solve my suspend/resume issue with my nvidia-equipped
>notebook by forcing the module load ordering of vgapm in
>sys/isa/vga_isa.c:
>
>Index: sys/isa/vga_isa.c
>===================================================================
>--- sys/isa/vga_isa.c   (revision 237779)
>+++ sys/isa/vga_isa.c   (working copy)
>@@ -379,4 +379,4 @@
>        0
> };
>
>-DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0);
>+DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, SI_ORDER_ANY);
>
>
>The system requires however that I load the nvidia module in
>/boot/loader.conf (as opposed to loading it after system is up and
>running).
>
>-Brandon
devinfo -v : http://pastebin.com/BFBHt3Sr
dmidecode: http://pastebin.com/dWVbe7t4

My x201i:
Model: 3249A64
CPU: Intel(R) Core(TM) i3 CPU       M 380  @ 2.53GHz
MainBoard: Intel QM57.
Graphics card  is Intel GMA HD(integration).

/etc/make.conf
......
#KMS
WITH_NEW_XORG="YES"
WITH_KMS="YES"
......

My kernel build with kms, which can support the Intel GMA HD graphics card.
My gui is used KDE 4.8. Everything runs ok, except suspend/resume.

The latest situation:
When I close  LCD,x201i will become to Sleep status.
Sleep LED is light, LCD is close.
But, no button can resume it.

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Re: Resume failed after Suspend on Thinkpad x201i

Brandon Gooch
In reply to this post by Brandon Gooch
On Sat, Jul 7, 2012 at 10:40 AM, Brandon Gooch
<[hidden email]> wrote:

> On Wed, Jul 4, 2012 at 4:23 PM, mbsd <[hidden email]> wrote:
>> On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote:
> [SNIP]
>>>
>>> In All the test, the screen is light and black, system is hangup, nothing can be done.
>>> The only thing can be done, is push power button, to force it shutdown.
>>
>> Which graphic card have you used? If you have had nvidia, it's normal,
>> I've had the same problem "the screen is light and black".
>
> Can both of you show the output of `devinfo -v` from your systems?
>
> I was able to solve my suspend/resume issue with my nvidia-equipped
> notebook by forcing the module load ordering of vgapm in
> sys/isa/vga_isa.c:
>
> Index: sys/isa/vga_isa.c
> ===================================================================
> --- sys/isa/vga_isa.c   (revision 237779)
> +++ sys/isa/vga_isa.c   (working copy)
> @@ -379,4 +379,4 @@
>         0
>  };
>
> -DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0);
> +DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, SI_ORDER_ANY);
>
>
> The system requires however that I load the nvidia module in
> /boot/loader.conf (as opposed to loading it after system is up and
> running).
>
> -Brandon

Oops, the patch above should instead be:

Index: sys/isa/vga_isa.c
===================================================================
--- sys/isa/vga_isa.c   (revision 238266)
+++ sys/isa/vga_isa.c   (working copy)
@@ -379,4 +379,4 @@
        0
 };

-DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0);
+DRIVER_MODULE_ORDERED(vgapm, vgapci, vgapm_driver, vgapm_devclass,
NULL, NULL, SI_ORDER_ANY);

I made the edit for the diff on a clean tree, but I'm actually
building from another :)

The above is correct. However, I'm still not sure this pertains to
your Intel video problem.

-Brandon
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Re: Resume failed after Suspend on Thinkpad x201i

乔楚/HonestQiao
>On Sat, Jul 7, 2012 at 10:40 AM, Brandon Gooch

><[hidden email]> wrote:
>> On Wed, Jul 4, 2012 at 4:23 PM, mbsd <[hidden email]> wrote:
>>> On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote:
>> [SNIP]
>>>>
>>>> In All the test, the screen is light and black, system is hangup, nothing can be done.
>>>> The only thing can be done, is push power button, to force it shutdown.
>>>
>>> Which graphic card have you used? If you have had nvidia, it's normal,
>>> I've had the same problem "the screen is light and black".
>>
>> Can both of you show the output of `devinfo -v` from your systems?
>>
>> I was able to solve my suspend/resume issue with my nvidia-equipped
>> notebook by forcing the module load ordering of vgapm in
>> sys/isa/vga_isa.c:
>>
>> Index: sys/isa/vga_isa.c
>> ===================================================================
>> --- sys/isa/vga_isa.c   (revision 237779)
>> +++ sys/isa/vga_isa.c   (working copy)
>> @@ -379,4 +379,4 @@
>>         0
>>  };
>>
>> -DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0);
>> +DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, SI_ORDER_ANY);
>>
>>
>> The system requires however that I load the nvidia module in
>> /boot/loader.conf (as opposed to loading it after system is up and
>> running).
>>
>> -Brandon
>
>Oops, the patch above should instead be:
>
>Index: sys/isa/vga_isa.c
>===================================================================
>--- sys/isa/vga_isa.c   (revision 238266)
>+++ sys/isa/vga_isa.c   (working copy)
>@@ -379,4 +379,4 @@
>        0
> };
>
>-DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0);
>+DRIVER_MODULE_ORDERED(vgapm, vgapci, vgapm_driver, vgapm_devclass,
>NULL, NULL, SI_ORDER_ANY);
>
>I made the edit for the diff on a clean tree, but I'm actually
>building from another :)
>
>The above is correct. However, I'm still not sure this pertains to
>your Intel video problem.
>
>-Brandon
Yesterday, I upgrade my freebsd to FreeBSD 9.1-PRERELEASE.
This method did not work.

And command 'shutdown -p now' can shutdown the system,
but the Screen is black and light, and Battery LED is light.
This command can't power off.

Whethe in:
sysctl -w hw.acpi.reset_video=0
sysctl -w hw.pci.do_power_suspend=1
sysctl -w hw.pci.do_power_resume=1
Or in:
sysctl -w hw.acpi.reset_video=0
sysctl -w hw.pci.do_power_suspend=1
sysctl -w hw.pci.do_power_resume=1

I can execute acpiconf -s 3, but can't resume the screen which is black and light.

Log for command 'acpiconf -s 3':

Jul 20 16:06:53 x201i acpi: suspend at 20120720 16:06:53
Jul 20 16:06:56 x201i kernel: acpi_timer0: switching timecounter, TSC-low -> ACPI-safe
Jul 20 16:06:56 x201i kernel: (ada0:ahcich0:0:0:0): spin-down
Jul 20 16:07:00 x201i kernel: acpi_lid0: wake_prep enabled for \_SB_.LID_ (S3)
Jul 20 16:07:00 x201i kernel: acpi_button0: wake_prep enabled for \_SB_.SLPB (S3)
Jul 20 16:07:00 x201i kernel: uhub0: at usbus0, port 1, addr 1 (disconnected)
Jul 20 16:07:00 x201i kernel: ugen0.2: <vendor 0x8087> at usbus0 (disconnected)
Jul 20 16:07:00 x201i kernel: uhub2: at uhub0, port 1, addr 2 (disconnected)
Jul 20 16:07:00 x201i kernel: pci0:0:28:0: Transition from D0 to D3
Jul 20 16:07:00 x201i kernel: pci0:0:28:3: Transition from D0 to D3
Jul 20 16:07:00 x201i kernel: wlan0: link state changed to DOWN
Jul 20 16:07:00 x201i kernel: pci0:2:0:0: Transition from D0 to D3
Jul 20 16:07:00 x201i kernel: pci0:0:28:4: Transition from D0 to D3
Jul 20 16:07:00 x201i kernel: uhub1: at usbus1, port 1, addr 1 (disconnected)
Jul 20 16:07:00 x201i kernel: ugen1.2: <vendor 0x8087> at usbus1 (disconnected)
Jul 20 16:07:00 x201i kernel: uhub3: at uhub1, port 1, addr 2 (disconnected)
Jul 20 16:07:00 x201i kernel: vga0: saving 4804 bytes of video state
Jul 20 16:07:00 x201i kernel: vga0: saving color palette
Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP1: AE_BAD_PARAMETER
Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP4: AE_BAD_PARAMETER
Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP5: AE_BAD_PARAMETER
Jul 20 16:07:00 x201i kernel: acpi_lid0: wake_prep enabled for \_SB_.LID_ (S3)
Jul 20 16:07:00 x201i kernel: acpi_button0: wake_prep enabled for \_SB_.SLPB (S3)
Jul 20 16:07:00 x201i kernel: pci255: set ACPI power state D0 on \_SB_.UNCR.SAD_
Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.VID_
Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.IGBE
Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EHC2
Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.HDEF
Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EXP1
Jul 20 16:07:00 x201i kernel: pci0:0:28:0: Transition from D3 to D0
Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EXP4
Jul 20 16:07:00 x201i kernel: pci0:0:28:3: Transition from D3 to D0
Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EXP5
Jul 20 16:07:00 x201i kernel: pci0:0:28:4: Transition from D3 to D0
Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EHC1
Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.PCI1
Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.LPC_
Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.SAT1
Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EXP1
Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EXP4
Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EXP5
Jul 20 16:07:00 x201i kernel: pci0:2:0:0: Transition from D3 to D0
Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.PCI1
Jul 20 16:07:00 x201i kernel: vga0: calling BIOS POST
Jul 20 16:07:00 x201i kernel: ahcich0: AHCI reset...
Jul 20 16:07:00 x201i kernel: ahcich0: SATA connect time=100us status=00000123
Jul 20 16:07:00 x201i kernel: ahcich0: AHCI reset: device found
Jul 20 16:07:00 x201i kernel: ahcich1: AHCI reset...
Jul 20 16:07:00 x201i kernel: ahcich1: SATA connect timeout time=10000us status=00000000
Jul 20 16:07:00 x201i kernel: ahcich1: AHCI reset: device not found
Jul 20 16:07:00 x201i kernel: ahcich4: AHCI reset...
Jul 20 16:07:00 x201i kernel: ahcich4: SATA connect timeout time=10000us status=00000000
Jul 20 16:07:00 x201i kernel: ahcich4: AHCI reset: device not found
Jul 20 16:07:00 x201i kernel: ahcich5: AHCI reset...
Jul 20 16:07:00 x201i kernel: ahcich5: SATA connect timeout time=10000us status=00000000
Jul 20 16:07:00 x201i kernel: ahcich5: AHCI reset: device not found
Jul 20 16:07:00 x201i kernel: atkbd: the current kbd controller command byte 0047
Jul 20 16:07:00 x201i kernel: atkbd: keyboard ID 0x54ab (2)
Jul 20 16:07:00 x201i kernel: kbdc: RESET_KBD return code:00fa
Jul 20 16:07:00 x201i kernel: kbdc: RESET_KBD status:00aa
Jul 20 16:07:00 x201i kernel: kbdc: TEST_AUX_PORT status:0000
Jul 20 16:07:00 x201i kernel: kbdc: RESET_AUX return code:00fa
Jul 20 16:07:00 x201i kernel: kbdc: RESET_AUX status:00aa
Jul 20 16:07:00 x201i kernel: kbdc: RESET_AUX ID:0000
Jul 20 16:07:00 x201i kernel: battery0: battery initialization start
Jul 20 16:07:00 x201i kernel: ahcich0: AHCI reset: device ready after 100ms
Jul 20 16:07:00 x201i kernel: battery0: battery initialization done, tried 1 times
Jul 20 16:07:00 x201i kernel: (ada0:ahcich0:0:0:0): resume
Jul 20 16:07:00 x201i kernel: acpi_timer0: restoring timecounter, ACPI-safe -> TSC-low
Jul 20 16:07:00 x201i kernel: uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
Jul 20 16:07:00 x201i kernel: uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
Jul 20 16:07:00 x201i kernel: wlan0: link state changed to UP
Jul 20 16:07:00 x201i kernel: uhub0: 3 ports with 3 removable, self powered
Jul 20 16:07:00 x201i kernel: uhub1: 3 ports with 3 removable, self powered
Jul 20 16:06:57 x201i wpa_supplicant[525]: CTRL-EVENT-DISCONNECTED bssid=c0:c5:20:1b:59:aa reason=0
Jul 20 16:06:57 x201i wpa_supplicant[525]: Failed to initiate AP scan.
Jul 20 16:06:59 x201i acpi: resumed at 20120720 16:06:59
Jul 20 16:06:59 x201i wpa_supplicant[525]: Trying to associate with c0:c5:20:1b:69:8a (SSID='LITB-AP' freq=2417 MHz)
Jul 20 16:07:00 x201i wpa_supplicant[525]: Associated with c0:c5:20:1b:69:8a
Jul 20 16:07:00 x201i wpa_supplicant[525]: WPA: Key negotiation completed with c0:c5:20:1b:69:8a [PTK=CCMP GTK=CCMP]
Jul 20 16:07:00 x201i wpa_supplicant[525]: CTRL-EVENT-CONNECTED - Connection to c0:c5:20:1b:69:8a completed (reauth) [id=0 id_str=]
Jul 20 16:07:00 x201i dhclient: New IP Address (wlan0): 192.168.61.184
Jul 20 16:07:00 x201i dhclient: New Subnet Mask (wlan0): 255.255.255.0
Jul 20 16:07:00 x201i dhclient: New Broadcast Address (wlan0): 192.168.61.255
Jul 20 16:07:00 x201i dhclient: New Routers (wlan0): 192.168.61.1
Jul 20 16:07:01 x201i kernel: ugen1.2: <vendor 0x8087> at usbus1
Jul 20 16:07:01 x201i kernel: uhub2: <vendor 0x8087 product 0x0020, class 9/0, rev 2.00/0.00, addr 2> on usbus1
Jul 20 16:07:01 x201i kernel: ugen0.2: <vendor 0x8087> at usbus0
Jul 20 16:07:01 x201i kernel: uhub3: <vendor 0x8087 product 0x0020, class 9/0, rev 2.00/0.00, addr 2> on usbus0
Jul 20 16:07:02 x201i kernel: uhub3: 6 ports with 6 removable, self powered
Jul 20 16:07:02 x201i kernel: uhub2: 8 ports with 8 removable, self powered

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Re: Resume failed after Suspend on Thinkpad x201i

Zack Breckenridge
If you look at the line:


> Jul 20 16:07:00 x201i kernel: vga0: calling BIOS POST

in your dmesg output, and then grep through the source, you'll find this is
actually being printed
from "src/sys/dev/fb/vesa.c" .

I had a similar problem. After syncing with FreeBSD 10-CURRENT and
compiling a kernel without
VESA support, I was able to get graphics to work on resume, but only when
running X.

I don't think you actually have to sync with CURRENT though -- I think you
just need to compile without
VESA. I synced with CURRENT to get the newer Intel GMA driver and KMS
subsystem. Also, looking at
the Witness output from the Intel driver, it looks like the graphics card
simply isn't accessible after
this function in vesa.c is called, which means it probably causes the same
problem with your nvidia driver
as well.

I believe this problem is related to the "x86bios_init_regs" function,
though I haven't had time to debug
it yet. Also, I'm running amd64.

Try it out...

- Zack

On Fri, Jul 20, 2012 at 1:09 AM, 乔楚/HonestQiao <[hidden email]> wrote:

> >On Sat, Jul 7, 2012 at 10:40 AM, Brandon Gooch
> ><[hidden email]> wrote:
> >> On Wed, Jul 4, 2012 at 4:23 PM, mbsd <[hidden email]> wrote:
> >>> On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote:
> >> [SNIP]
> >>>>
> >>>> In All the test, the screen is light and black, system is hangup,
> nothing can be done.
> >>>> The only thing can be done, is push power button, to force it
> shutdown.
> >>>
> >>> Which graphic card have you used? If you have had nvidia, it's normal,
> >>> I've had the same problem "the screen is light and black".
> >>
> >> Can both of you show the output of `devinfo -v` from your systems?
> >>
> >> I was able to solve my suspend/resume issue with my nvidia-equipped
> >> notebook by forcing the module load ordering of vgapm in
> >> sys/isa/vga_isa.c:
> >>
> >> Index: sys/isa/vga_isa.c
> >> ===================================================================
> >> --- sys/isa/vga_isa.c   (revision 237779)
> >> +++ sys/isa/vga_isa.c   (working copy)
> >> @@ -379,4 +379,4 @@
> >>         0
> >>  };
> >>
> >> -DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0);
> >> +DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0,
> SI_ORDER_ANY);
> >>
> >>
> >> The system requires however that I load the nvidia module in
> >> /boot/loader.conf (as opposed to loading it after system is up and
> >> running).
> >>
> >> -Brandon
> >
> >Oops, the patch above should instead be:
> >
> >Index: sys/isa/vga_isa.c
> >===================================================================
> >--- sys/isa/vga_isa.c   (revision 238266)
> >+++ sys/isa/vga_isa.c   (working copy)
> >@@ -379,4 +379,4 @@
> >        0
> > };
> >
> >-DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0);
> >+DRIVER_MODULE_ORDERED(vgapm, vgapci, vgapm_driver, vgapm_devclass,
> >NULL, NULL, SI_ORDER_ANY);
> >
> >I made the edit for the diff on a clean tree, but I'm actually
> >building from another :)
> >
> >The above is correct. However, I'm still not sure this pertains to
> >your Intel video problem.
> >
> >-Brandon
>
> Yesterday, I upgrade my freebsd to FreeBSD 9.1-PRERELEASE.
> This method did not work.
>
> And command 'shutdown -p now' can shutdown the system,
> but the Screen is black and light, and Battery LED is light.
> This command can't power off.
>
> Whethe in:
> sysctl -w hw.acpi.reset_video=0
> sysctl -w hw.pci.do_power_suspend=1
> sysctl -w hw.pci.do_power_resume=1
> Or in:
> sysctl -w hw.acpi.reset_video=0
> sysctl -w hw.pci.do_power_suspend=1
> sysctl -w hw.pci.do_power_resume=1
>
> I can execute acpiconf -s 3, but can't resume the screen which is black
> and light.
>
> Log for command 'acpiconf -s 3':
>
> Jul 20 16:06:53 x201i acpi: suspend at 20120720 16:06:53
> Jul 20 16:06:56 x201i kernel: acpi_timer0: switching timecounter, TSC-low
> -> ACPI-safe
> Jul 20 16:06:56 x201i kernel: (ada0:ahcich0:0:0:0): spin-down
> Jul 20 16:07:00 x201i kernel: acpi_lid0: wake_prep enabled for \_SB_.LID_
> (S3)
> Jul 20 16:07:00 x201i kernel: acpi_button0: wake_prep enabled for
> \_SB_.SLPB (S3)
> Jul 20 16:07:00 x201i kernel: uhub0: at usbus0, port 1, addr 1
> (disconnected)
> Jul 20 16:07:00 x201i kernel: ugen0.2: <vendor 0x8087> at usbus0
> (disconnected)
> Jul 20 16:07:00 x201i kernel: uhub2: at uhub0, port 1, addr 2
> (disconnected)
> Jul 20 16:07:00 x201i kernel: pci0:0:28:0: Transition from D0 to D3
> Jul 20 16:07:00 x201i kernel: pci0:0:28:3: Transition from D0 to D3
> Jul 20 16:07:00 x201i kernel: wlan0: link state changed to DOWN
> Jul 20 16:07:00 x201i kernel: pci0:2:0:0: Transition from D0 to D3
> Jul 20 16:07:00 x201i kernel: pci0:0:28:4: Transition from D0 to D3
> Jul 20 16:07:00 x201i kernel: uhub1: at usbus1, port 1, addr 1
> (disconnected)
> Jul 20 16:07:00 x201i kernel: ugen1.2: <vendor 0x8087> at usbus1
> (disconnected)
> Jul 20 16:07:00 x201i kernel: uhub3: at uhub1, port 1, addr 2
> (disconnected)
> Jul 20 16:07:00 x201i kernel: vga0: saving 4804 bytes of video state
> Jul 20 16:07:00 x201i kernel: vga0: saving color palette
> Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2 on
> \_SB_.PCI0.EXP1: AE_BAD_PARAMETER
> Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2 on
> \_SB_.PCI0.EXP4: AE_BAD_PARAMETER
> Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2 on
> \_SB_.PCI0.EXP5: AE_BAD_PARAMETER
> Jul 20 16:07:00 x201i kernel: acpi_lid0: wake_prep enabled for \_SB_.LID_
> (S3)
> Jul 20 16:07:00 x201i kernel: acpi_button0: wake_prep enabled for
> \_SB_.SLPB (S3)
> Jul 20 16:07:00 x201i kernel: pci255: set ACPI power state D0 on
> \_SB_.UNCR.SAD_
> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> \_SB_.PCI0.VID_
> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> \_SB_.PCI0.IGBE
> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> \_SB_.PCI0.EHC2
> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> \_SB_.PCI0.HDEF
> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> \_SB_.PCI0.EXP1
> Jul 20 16:07:00 x201i kernel: pci0:0:28:0: Transition from D3 to D0
> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> \_SB_.PCI0.EXP4
> Jul 20 16:07:00 x201i kernel: pci0:0:28:3: Transition from D3 to D0
> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> \_SB_.PCI0.EXP5
> Jul 20 16:07:00 x201i kernel: pci0:0:28:4: Transition from D3 to D0
> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> \_SB_.PCI0.EHC1
> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> \_SB_.PCI0.PCI1
> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> \_SB_.PCI0.LPC_
> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> \_SB_.PCI0.SAT1
> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> \_SB_.PCI0.EXP1
> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> \_SB_.PCI0.EXP4
> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> \_SB_.PCI0.EXP5
> Jul 20 16:07:00 x201i kernel: pci0:2:0:0: Transition from D3 to D0
> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> \_SB_.PCI0.PCI1
> Jul 20 16:07:00 x201i kernel: vga0: calling BIOS POST
> Jul 20 16:07:00 x201i kernel: ahcich0: AHCI reset...
> Jul 20 16:07:00 x201i kernel: ahcich0: SATA connect time=100us
> status=00000123
> Jul 20 16:07:00 x201i kernel: ahcich0: AHCI reset: device found
> Jul 20 16:07:00 x201i kernel: ahcich1: AHCI reset...
> Jul 20 16:07:00 x201i kernel: ahcich1: SATA connect timeout time=10000us
> status=00000000
> Jul 20 16:07:00 x201i kernel: ahcich1: AHCI reset: device not found
> Jul 20 16:07:00 x201i kernel: ahcich4: AHCI reset...
> Jul 20 16:07:00 x201i kernel: ahcich4: SATA connect timeout time=10000us
> status=00000000
> Jul 20 16:07:00 x201i kernel: ahcich4: AHCI reset: device not found
> Jul 20 16:07:00 x201i kernel: ahcich5: AHCI reset...
> Jul 20 16:07:00 x201i kernel: ahcich5: SATA connect timeout time=10000us
> status=00000000
> Jul 20 16:07:00 x201i kernel: ahcich5: AHCI reset: device not found
> Jul 20 16:07:00 x201i kernel: atkbd: the current kbd controller command
> byte 0047
> Jul 20 16:07:00 x201i kernel: atkbd: keyboard ID 0x54ab (2)
> Jul 20 16:07:00 x201i kernel: kbdc: RESET_KBD return code:00fa
> Jul 20 16:07:00 x201i kernel: kbdc: RESET_KBD status:00aa
> Jul 20 16:07:00 x201i kernel: kbdc: TEST_AUX_PORT status:0000
> Jul 20 16:07:00 x201i kernel: kbdc: RESET_AUX return code:00fa
> Jul 20 16:07:00 x201i kernel: kbdc: RESET_AUX status:00aa
> Jul 20 16:07:00 x201i kernel: kbdc: RESET_AUX ID:0000
> Jul 20 16:07:00 x201i kernel: battery0: battery initialization start
> Jul 20 16:07:00 x201i kernel: ahcich0: AHCI reset: device ready after 100ms
> Jul 20 16:07:00 x201i kernel: battery0: battery initialization done, tried
> 1 times
> Jul 20 16:07:00 x201i kernel: (ada0:ahcich0:0:0:0): resume
> Jul 20 16:07:00 x201i kernel: acpi_timer0: restoring timecounter,
> ACPI-safe -> TSC-low
> Jul 20 16:07:00 x201i kernel: uhub0: <Intel EHCI root HUB, class 9/0, rev
> 2.00/1.00, addr 1> on usbus1
> Jul 20 16:07:00 x201i kernel: uhub1: <Intel EHCI root HUB, class 9/0, rev
> 2.00/1.00, addr 1> on usbus0
> Jul 20 16:07:00 x201i kernel: wlan0: link state changed to UP
> Jul 20 16:07:00 x201i kernel: uhub0: 3 ports with 3 removable, self powered
> Jul 20 16:07:00 x201i kernel: uhub1: 3 ports with 3 removable, self powered
> Jul 20 16:06:57 x201i wpa_supplicant[525]: CTRL-EVENT-DISCONNECTED
> bssid=c0:c5:20:1b:59:aa reason=0
> Jul 20 16:06:57 x201i wpa_supplicant[525]: Failed to initiate AP scan.
> Jul 20 16:06:59 x201i acpi: resumed at 20120720 16:06:59
> Jul 20 16:06:59 x201i wpa_supplicant[525]: Trying to associate with
> c0:c5:20:1b:69:8a (SSID='LITB-AP' freq=2417 MHz)
> Jul 20 16:07:00 x201i wpa_supplicant[525]: Associated with
> c0:c5:20:1b:69:8a
> Jul 20 16:07:00 x201i wpa_supplicant[525]: WPA: Key negotiation completed
> with c0:c5:20:1b:69:8a [PTK=CCMP GTK=CCMP]
> Jul 20 16:07:00 x201i wpa_supplicant[525]: CTRL-EVENT-CONNECTED -
> Connection to c0:c5:20:1b:69:8a completed (reauth) [id=0 id_str=]
> Jul 20 16:07:00 x201i dhclient: New IP Address (wlan0): 192.168.61.184
> Jul 20 16:07:00 x201i dhclient: New Subnet Mask (wlan0): 255.255.255.0
> Jul 20 16:07:00 x201i dhclient: New Broadcast Address (wlan0):
> 192.168.61.255
> Jul 20 16:07:00 x201i dhclient: New Routers (wlan0): 192.168.61.1
> Jul 20 16:07:01 x201i kernel: ugen1.2: <vendor 0x8087> at usbus1
> Jul 20 16:07:01 x201i kernel: uhub2: <vendor 0x8087 product 0x0020, class
> 9/0, rev 2.00/0.00, addr 2> on usbus1
> Jul 20 16:07:01 x201i kernel: ugen0.2: <vendor 0x8087> at usbus0
> Jul 20 16:07:01 x201i kernel: uhub3: <vendor 0x8087 product 0x0020, class
> 9/0, rev 2.00/0.00, addr 2> on usbus0
> Jul 20 16:07:02 x201i kernel: uhub3: 6 ports with 6 removable, self powered
> Jul 20 16:07:02 x201i kernel: uhub2: 8 ports with 8 removable, self powered
>
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "[hidden email]"
>
>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Re: Resume failed after Suspend on Thinkpad x201i

乔楚/HonestQiao
2012/7/20 Zack Breckenridge <[hidden email]>:

> If you look at the line:
>
>
>> Jul 20 16:07:00 x201i kernel: vga0: calling BIOS POST
>
> in your dmesg output, and then grep through the source, you'll find this is
> actually being printed
> from "src/sys/dev/fb/vesa.c" .
>
> I had a similar problem. After syncing with FreeBSD 10-CURRENT and compiling
> a kernel without
> VESA support, I was able to get graphics to work on resume, but only when
> running X.
>
> I don't think you actually have to sync with CURRENT though -- I think you
> just need to compile without
> VESA. I synced with CURRENT to get the newer Intel GMA driver and KMS
> subsystem. Also, looking at
> the Witness output from the Intel driver, it looks like the graphics card
> simply isn't accessible after
> this function in vesa.c is called, which means it probably causes the same
> problem with your nvidia driver
> as well.
>
> I believe this problem is related to the "x86bios_init_regs" function,
> though I haven't had time to debug
> it yet. Also, I'm running amd64.
>
> Try it out...
>
> - Zack
>
> On Fri, Jul 20, 2012 at 1:09 AM, 乔楚/HonestQiao <[hidden email]> wrote:
>>
>> >On Sat, Jul 7, 2012 at 10:40 AM, Brandon Gooch
>> ><[hidden email]> wrote:
>> >> On Wed, Jul 4, 2012 at 4:23 PM, mbsd <[hidden email]> wrote:
>> >>> On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote:
>> >> [SNIP]
>> >>>>
>> >>>> In All the test, the screen is light and black, system is hangup,
>> >>>> nothing can be done.
>> >>>> The only thing can be done, is push power button, to force it
>> >>>> shutdown.
>> >>>
>> >>> Which graphic card have you used? If you have had nvidia, it's normal,
>> >>> I've had the same problem "the screen is light and black".
>> >>
>> >> Can both of you show the output of `devinfo -v` from your systems?
>> >>
>> >> I was able to solve my suspend/resume issue with my nvidia-equipped
>> >> notebook by forcing the module load ordering of vgapm in
>> >> sys/isa/vga_isa.c:
>> >>
>> >> Index: sys/isa/vga_isa.c
>> >> ===================================================================
>> >> --- sys/isa/vga_isa.c   (revision 237779)
>> >> +++ sys/isa/vga_isa.c   (working copy)
>> >> @@ -379,4 +379,4 @@
>> >>         0
>> >>  };
>> >>
>> >> -DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0);
>> >> +DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0,
>> >> SI_ORDER_ANY);
>> >>
>> >>
>> >> The system requires however that I load the nvidia module in
>> >> /boot/loader.conf (as opposed to loading it after system is up and
>> >> running).
>> >>
>> >> -Brandon
>> >
>> >Oops, the patch above should instead be:
>> >
>> >Index: sys/isa/vga_isa.c
>> >===================================================================
>> >--- sys/isa/vga_isa.c   (revision 238266)
>> >+++ sys/isa/vga_isa.c   (working copy)
>> >@@ -379,4 +379,4 @@
>> >        0
>> > };
>> >
>> >-DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0);
>> >+DRIVER_MODULE_ORDERED(vgapm, vgapci, vgapm_driver, vgapm_devclass,
>> >NULL, NULL, SI_ORDER_ANY);
>> >
>> >I made the edit for the diff on a clean tree, but I'm actually
>> >building from another :)
>> >
>> >The above is correct. However, I'm still not sure this pertains to
>> >your Intel video problem.
>> >
>> >-Brandon
>>
>> Yesterday, I upgrade my freebsd to FreeBSD 9.1-PRERELEASE.
>> This method did not work.
>>
>> And command 'shutdown -p now' can shutdown the system,
>> but the Screen is black and light, and Battery LED is light.
>> This command can't power off.
>>
>> Whethe in:
>> sysctl -w hw.acpi.reset_video=0
>> sysctl -w hw.pci.do_power_suspend=1
>> sysctl -w hw.pci.do_power_resume=1
>> Or in:
>> sysctl -w hw.acpi.reset_video=0
>> sysctl -w hw.pci.do_power_suspend=1
>> sysctl -w hw.pci.do_power_resume=1
>>
>> I can execute acpiconf -s 3, but can't resume the screen which is black
>> and light.
>>
>> Log for command 'acpiconf -s 3':
>>
>> Jul 20 16:06:53 x201i acpi: suspend at 20120720 16:06:53
>> Jul 20 16:06:56 x201i kernel: acpi_timer0: switching timecounter, TSC-low
>> -> ACPI-safe
>> Jul 20 16:06:56 x201i kernel: (ada0:ahcich0:0:0:0): spin-down
>> Jul 20 16:07:00 x201i kernel: acpi_lid0: wake_prep enabled for \_SB_.LID_
>> (S3)
>> Jul 20 16:07:00 x201i kernel: acpi_button0: wake_prep enabled for
>> \_SB_.SLPB (S3)
>> Jul 20 16:07:00 x201i kernel: uhub0: at usbus0, port 1, addr 1
>> (disconnected)
>> Jul 20 16:07:00 x201i kernel: ugen0.2: <vendor 0x8087> at usbus0
>> (disconnected)
>> Jul 20 16:07:00 x201i kernel: uhub2: at uhub0, port 1, addr 2
>> (disconnected)
>> Jul 20 16:07:00 x201i kernel: pci0:0:28:0: Transition from D0 to D3
>> Jul 20 16:07:00 x201i kernel: pci0:0:28:3: Transition from D0 to D3
>> Jul 20 16:07:00 x201i kernel: wlan0: link state changed to DOWN
>> Jul 20 16:07:00 x201i kernel: pci0:2:0:0: Transition from D0 to D3
>> Jul 20 16:07:00 x201i kernel: pci0:0:28:4: Transition from D0 to D3
>> Jul 20 16:07:00 x201i kernel: uhub1: at usbus1, port 1, addr 1
>> (disconnected)
>> Jul 20 16:07:00 x201i kernel: ugen1.2: <vendor 0x8087> at usbus1
>> (disconnected)
>> Jul 20 16:07:00 x201i kernel: uhub3: at uhub1, port 1, addr 2
>> (disconnected)
>> Jul 20 16:07:00 x201i kernel: vga0: saving 4804 bytes of video state
>> Jul 20 16:07:00 x201i kernel: vga0: saving color palette
>> Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2 on
>> \_SB_.PCI0.EXP1: AE_BAD_PARAMETER
>> Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2 on
>> \_SB_.PCI0.EXP4: AE_BAD_PARAMETER
>> Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2 on
>> \_SB_.PCI0.EXP5: AE_BAD_PARAMETER
>> Jul 20 16:07:00 x201i kernel: acpi_lid0: wake_prep enabled for \_SB_.LID_
>> (S3)
>> Jul 20 16:07:00 x201i kernel: acpi_button0: wake_prep enabled for
>> \_SB_.SLPB (S3)
>> Jul 20 16:07:00 x201i kernel: pci255: set ACPI power state D0 on
>> \_SB_.UNCR.SAD_
>> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> \_SB_.PCI0.VID_
>> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> \_SB_.PCI0.IGBE
>> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> \_SB_.PCI0.EHC2
>> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> \_SB_.PCI0.HDEF
>> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> \_SB_.PCI0.EXP1
>> Jul 20 16:07:00 x201i kernel: pci0:0:28:0: Transition from D3 to D0
>> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> \_SB_.PCI0.EXP4
>> Jul 20 16:07:00 x201i kernel: pci0:0:28:3: Transition from D3 to D0
>> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> \_SB_.PCI0.EXP5
>> Jul 20 16:07:00 x201i kernel: pci0:0:28:4: Transition from D3 to D0
>> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> \_SB_.PCI0.EHC1
>> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> \_SB_.PCI0.PCI1
>> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> \_SB_.PCI0.LPC_
>> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> \_SB_.PCI0.SAT1
>> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> \_SB_.PCI0.EXP1
>> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> \_SB_.PCI0.EXP4
>> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> \_SB_.PCI0.EXP5
>> Jul 20 16:07:00 x201i kernel: pci0:2:0:0: Transition from D3 to D0
>> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> \_SB_.PCI0.PCI1
>> Jul 20 16:07:00 x201i kernel: vga0: calling BIOS POST
>> Jul 20 16:07:00 x201i kernel: ahcich0: AHCI reset...
>> Jul 20 16:07:00 x201i kernel: ahcich0: SATA connect time=100us
>> status=00000123
>> Jul 20 16:07:00 x201i kernel: ahcich0: AHCI reset: device found
>> Jul 20 16:07:00 x201i kernel: ahcich1: AHCI reset...
>> Jul 20 16:07:00 x201i kernel: ahcich1: SATA connect timeout time=10000us
>> status=00000000
>> Jul 20 16:07:00 x201i kernel: ahcich1: AHCI reset: device not found
>> Jul 20 16:07:00 x201i kernel: ahcich4: AHCI reset...
>> Jul 20 16:07:00 x201i kernel: ahcich4: SATA connect timeout time=10000us
>> status=00000000
>> Jul 20 16:07:00 x201i kernel: ahcich4: AHCI reset: device not found
>> Jul 20 16:07:00 x201i kernel: ahcich5: AHCI reset...
>> Jul 20 16:07:00 x201i kernel: ahcich5: SATA connect timeout time=10000us
>> status=00000000
>> Jul 20 16:07:00 x201i kernel: ahcich5: AHCI reset: device not found
>> Jul 20 16:07:00 x201i kernel: atkbd: the current kbd controller command
>> byte 0047
>> Jul 20 16:07:00 x201i kernel: atkbd: keyboard ID 0x54ab (2)
>> Jul 20 16:07:00 x201i kernel: kbdc: RESET_KBD return code:00fa
>> Jul 20 16:07:00 x201i kernel: kbdc: RESET_KBD status:00aa
>> Jul 20 16:07:00 x201i kernel: kbdc: TEST_AUX_PORT status:0000
>> Jul 20 16:07:00 x201i kernel: kbdc: RESET_AUX return code:00fa
>> Jul 20 16:07:00 x201i kernel: kbdc: RESET_AUX status:00aa
>> Jul 20 16:07:00 x201i kernel: kbdc: RESET_AUX ID:0000
>> Jul 20 16:07:00 x201i kernel: battery0: battery initialization start
>> Jul 20 16:07:00 x201i kernel: ahcich0: AHCI reset: device ready after
>> 100ms
>> Jul 20 16:07:00 x201i kernel: battery0: battery initialization done, tried
>> 1 times
>> Jul 20 16:07:00 x201i kernel: (ada0:ahcich0:0:0:0): resume
>> Jul 20 16:07:00 x201i kernel: acpi_timer0: restoring timecounter,
>> ACPI-safe -> TSC-low
>> Jul 20 16:07:00 x201i kernel: uhub0: <Intel EHCI root HUB, class 9/0, rev
>> 2.00/1.00, addr 1> on usbus1
>> Jul 20 16:07:00 x201i kernel: uhub1: <Intel EHCI root HUB, class 9/0, rev
>> 2.00/1.00, addr 1> on usbus0
>> Jul 20 16:07:00 x201i kernel: wlan0: link state changed to UP
>> Jul 20 16:07:00 x201i kernel: uhub0: 3 ports with 3 removable, self
>> powered
>> Jul 20 16:07:00 x201i kernel: uhub1: 3 ports with 3 removable, self
>> powered
>> Jul 20 16:06:57 x201i wpa_supplicant[525]: CTRL-EVENT-DISCONNECTED
>> bssid=c0:c5:20:1b:59:aa reason=0
>> Jul 20 16:06:57 x201i wpa_supplicant[525]: Failed to initiate AP scan.
>> Jul 20 16:06:59 x201i acpi: resumed at 20120720 16:06:59
>> Jul 20 16:06:59 x201i wpa_supplicant[525]: Trying to associate with
>> c0:c5:20:1b:69:8a (SSID='LITB-AP' freq=2417 MHz)
>> Jul 20 16:07:00 x201i wpa_supplicant[525]: Associated with
>> c0:c5:20:1b:69:8a
>> Jul 20 16:07:00 x201i wpa_supplicant[525]: WPA: Key negotiation completed
>> with c0:c5:20:1b:69:8a [PTK=CCMP GTK=CCMP]
>> Jul 20 16:07:00 x201i wpa_supplicant[525]: CTRL-EVENT-CONNECTED -
>> Connection to c0:c5:20:1b:69:8a completed (reauth) [id=0 id_str=]
>> Jul 20 16:07:00 x201i dhclient: New IP Address (wlan0): 192.168.61.184
>> Jul 20 16:07:00 x201i dhclient: New Subnet Mask (wlan0): 255.255.255.0
>> Jul 20 16:07:00 x201i dhclient: New Broadcast Address (wlan0):
>> 192.168.61.255
>> Jul 20 16:07:00 x201i dhclient: New Routers (wlan0): 192.168.61.1
>> Jul 20 16:07:01 x201i kernel: ugen1.2: <vendor 0x8087> at usbus1
>> Jul 20 16:07:01 x201i kernel: uhub2: <vendor 0x8087 product 0x0020, class
>> 9/0, rev 2.00/0.00, addr 2> on usbus1
>> Jul 20 16:07:01 x201i kernel: ugen0.2: <vendor 0x8087> at usbus0
>> Jul 20 16:07:01 x201i kernel: uhub3: <vendor 0x8087 product 0x0020, class
>> 9/0, rev 2.00/0.00, addr 2> on usbus0
>> Jul 20 16:07:02 x201i kernel: uhub3: 6 ports with 6 removable, self
>> powered
>> Jul 20 16:07:02 x201i kernel: uhub2: 8 ports with 8 removable, self
>> powered
>>
>> _______________________________________________
>> [hidden email] mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>> To unsubscribe, send any mail to "[hidden email]"
>>
>

Today , I build my kernel disabled vesa.
Now , there has so many error messages in dmesg:
Jul 22 16:42:18 x201i kernel: ACPI Error: No object attached to node
0xfffffe00029a6780 (20110527/exresnte-139)
Jul 22 16:42:18 x201i kernel: ACPI Error: Method execution failed
[\_SB_.PCI0.LPC_.EC__.BAT0._HID] (Node 0xfffffe00029a6780),
AE_AML_NO_OPERAND (20110527/uteval-113)



When I test acpiconf -s 3, it's hangup:
#sysctl debug.acpi.suspend_bounce=1
#acpiconf -s 3
ahcich0: AHCI reset: device not ready after 31000ms (tfd = 00000080)
ahcich0: Timeout on slot 12 port 0
......
achich0: AHCI reset ...
ahcich0: SATA connect time=100us status=0000123
ahcich0: AHCI reset: device found
(aprobe0:ahchih0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00
(aprobe0:ahchih0:0:0:0): CAM status: command timeout
(aprobe0:ahchih0:0:0:0): Error 5, Retry was blocked

reboot by push power button:
#sysctl debug.acpi.suspend_bounce=0
#acpiconf -s 3
It's will suspend, and sleep LED will light.
But can't resume. No button can resume it.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Re: Resume failed after Suspend on Thinkpad x201i

Zack Breckenridge
Attached is the kernel configuration file I used to build my kernel without
VESA.

I went through the same process as you: setting suspend bounce, etc., and
looking at the dmesg output. Again, I also looked at the witness output
from my Intel driver when resuming X -- and I noticed that it simply wasn't
able to reach the GPU.

So I think it is some sort of bus error on resume and is related to our
different BIOSes. Since it worked for me, probably some int 10 call in VESA
was causing the error. In your case - not being able to issue commands to
an ATA device could also be a bus issue, caused by NOT calling the proper
INT 10 setup functions on resume.

I'm going to build a debug kernel today and see if I can start tracking the
problem to it's root.

- Zack

On Sun, Jul 22, 2012 at 4:36 AM, 乔楚 <[hidden email]> wrote:

> 2012/7/20 Zack Breckenridge <[hidden email]>:
> > If you look at the line:
> >
> >
> >> Jul 20 16:07:00 x201i kernel: vga0: calling BIOS POST
> >
> > in your dmesg output, and then grep through the source, you'll find this
> is
> > actually being printed
> > from "src/sys/dev/fb/vesa.c" .
> >
> > I had a similar problem. After syncing with FreeBSD 10-CURRENT and
> compiling
> > a kernel without
> > VESA support, I was able to get graphics to work on resume, but only when
> > running X.
> >
> > I don't think you actually have to sync with CURRENT though -- I think
> you
> > just need to compile without
> > VESA. I synced with CURRENT to get the newer Intel GMA driver and KMS
> > subsystem. Also, looking at
> > the Witness output from the Intel driver, it looks like the graphics card
> > simply isn't accessible after
> > this function in vesa.c is called, which means it probably causes the
> same
> > problem with your nvidia driver
> > as well.
> >
> > I believe this problem is related to the "x86bios_init_regs" function,
> > though I haven't had time to debug
> > it yet. Also, I'm running amd64.
> >
> > Try it out...
> >
> > - Zack
> >
> > On Fri, Jul 20, 2012 at 1:09 AM, 乔楚/HonestQiao <[hidden email]>
> wrote:
> >>
> >> >On Sat, Jul 7, 2012 at 10:40 AM, Brandon Gooch
> >> ><[hidden email]> wrote:
> >> >> On Wed, Jul 4, 2012 at 4:23 PM, mbsd <[hidden email]> wrote:
> >> >>> On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote:
> >> >> [SNIP]
> >> >>>>
> >> >>>> In All the test, the screen is light and black, system is hangup,
> >> >>>> nothing can be done.
> >> >>>> The only thing can be done, is push power button, to force it
> >> >>>> shutdown.
> >> >>>
> >> >>> Which graphic card have you used? If you have had nvidia, it's
> normal,
> >> >>> I've had the same problem "the screen is light and black".
> >> >>
> >> >> Can both of you show the output of `devinfo -v` from your systems?
> >> >>
> >> >> I was able to solve my suspend/resume issue with my nvidia-equipped
> >> >> notebook by forcing the module load ordering of vgapm in
> >> >> sys/isa/vga_isa.c:
> >> >>
> >> >> Index: sys/isa/vga_isa.c
> >> >> ===================================================================
> >> >> --- sys/isa/vga_isa.c   (revision 237779)
> >> >> +++ sys/isa/vga_isa.c   (working copy)
> >> >> @@ -379,4 +379,4 @@
> >> >>         0
> >> >>  };
> >> >>
> >> >> -DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0);
> >> >> +DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0,
> >> >> SI_ORDER_ANY);
> >> >>
> >> >>
> >> >> The system requires however that I load the nvidia module in
> >> >> /boot/loader.conf (as opposed to loading it after system is up and
> >> >> running).
> >> >>
> >> >> -Brandon
> >> >
> >> >Oops, the patch above should instead be:
> >> >
> >> >Index: sys/isa/vga_isa.c
> >> >===================================================================
> >> >--- sys/isa/vga_isa.c   (revision 238266)
> >> >+++ sys/isa/vga_isa.c   (working copy)
> >> >@@ -379,4 +379,4 @@
> >> >        0
> >> > };
> >> >
> >> >-DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0);
> >> >+DRIVER_MODULE_ORDERED(vgapm, vgapci, vgapm_driver, vgapm_devclass,
> >> >NULL, NULL, SI_ORDER_ANY);
> >> >
> >> >I made the edit for the diff on a clean tree, but I'm actually
> >> >building from another :)
> >> >
> >> >The above is correct. However, I'm still not sure this pertains to
> >> >your Intel video problem.
> >> >
> >> >-Brandon
> >>
> >> Yesterday, I upgrade my freebsd to FreeBSD 9.1-PRERELEASE.
> >> This method did not work.
> >>
> >> And command 'shutdown -p now' can shutdown the system,
> >> but the Screen is black and light, and Battery LED is light.
> >> This command can't power off.
> >>
> >> Whethe in:
> >> sysctl -w hw.acpi.reset_video=0
> >> sysctl -w hw.pci.do_power_suspend=1
> >> sysctl -w hw.pci.do_power_resume=1
> >> Or in:
> >> sysctl -w hw.acpi.reset_video=0
> >> sysctl -w hw.pci.do_power_suspend=1
> >> sysctl -w hw.pci.do_power_resume=1
> >>
> >> I can execute acpiconf -s 3, but can't resume the screen which is black
> >> and light.
> >>
> >> Log for command 'acpiconf -s 3':
> >>
> >> Jul 20 16:06:53 x201i acpi: suspend at 20120720 16:06:53
> >> Jul 20 16:06:56 x201i kernel: acpi_timer0: switching timecounter,
> TSC-low
> >> -> ACPI-safe
> >> Jul 20 16:06:56 x201i kernel: (ada0:ahcich0:0:0:0): spin-down
> >> Jul 20 16:07:00 x201i kernel: acpi_lid0: wake_prep enabled for
> \_SB_.LID_
> >> (S3)
> >> Jul 20 16:07:00 x201i kernel: acpi_button0: wake_prep enabled for
> >> \_SB_.SLPB (S3)
> >> Jul 20 16:07:00 x201i kernel: uhub0: at usbus0, port 1, addr 1
> >> (disconnected)
> >> Jul 20 16:07:00 x201i kernel: ugen0.2: <vendor 0x8087> at usbus0
> >> (disconnected)
> >> Jul 20 16:07:00 x201i kernel: uhub2: at uhub0, port 1, addr 2
> >> (disconnected)
> >> Jul 20 16:07:00 x201i kernel: pci0:0:28:0: Transition from D0 to D3
> >> Jul 20 16:07:00 x201i kernel: pci0:0:28:3: Transition from D0 to D3
> >> Jul 20 16:07:00 x201i kernel: wlan0: link state changed to DOWN
> >> Jul 20 16:07:00 x201i kernel: pci0:2:0:0: Transition from D0 to D3
> >> Jul 20 16:07:00 x201i kernel: pci0:0:28:4: Transition from D0 to D3
> >> Jul 20 16:07:00 x201i kernel: uhub1: at usbus1, port 1, addr 1
> >> (disconnected)
> >> Jul 20 16:07:00 x201i kernel: ugen1.2: <vendor 0x8087> at usbus1
> >> (disconnected)
> >> Jul 20 16:07:00 x201i kernel: uhub3: at uhub1, port 1, addr 2
> >> (disconnected)
> >> Jul 20 16:07:00 x201i kernel: vga0: saving 4804 bytes of video state
> >> Jul 20 16:07:00 x201i kernel: vga0: saving color palette
> >> Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2 on
> >> \_SB_.PCI0.EXP1: AE_BAD_PARAMETER
> >> Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2 on
> >> \_SB_.PCI0.EXP4: AE_BAD_PARAMETER
> >> Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2 on
> >> \_SB_.PCI0.EXP5: AE_BAD_PARAMETER
> >> Jul 20 16:07:00 x201i kernel: acpi_lid0: wake_prep enabled for
> \_SB_.LID_
> >> (S3)
> >> Jul 20 16:07:00 x201i kernel: acpi_button0: wake_prep enabled for
> >> \_SB_.SLPB (S3)
> >> Jul 20 16:07:00 x201i kernel: pci255: set ACPI power state D0 on
> >> \_SB_.UNCR.SAD_
> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> >> \_SB_.PCI0.VID_
> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> >> \_SB_.PCI0.IGBE
> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> >> \_SB_.PCI0.EHC2
> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> >> \_SB_.PCI0.HDEF
> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> >> \_SB_.PCI0.EXP1
> >> Jul 20 16:07:00 x201i kernel: pci0:0:28:0: Transition from D3 to D0
> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> >> \_SB_.PCI0.EXP4
> >> Jul 20 16:07:00 x201i kernel: pci0:0:28:3: Transition from D3 to D0
> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> >> \_SB_.PCI0.EXP5
> >> Jul 20 16:07:00 x201i kernel: pci0:0:28:4: Transition from D3 to D0
> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> >> \_SB_.PCI0.EHC1
> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> >> \_SB_.PCI0.PCI1
> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> >> \_SB_.PCI0.LPC_
> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> >> \_SB_.PCI0.SAT1
> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> >> \_SB_.PCI0.EXP1
> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> >> \_SB_.PCI0.EXP4
> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> >> \_SB_.PCI0.EXP5
> >> Jul 20 16:07:00 x201i kernel: pci0:2:0:0: Transition from D3 to D0
> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
> >> \_SB_.PCI0.PCI1
> >> Jul 20 16:07:00 x201i kernel: vga0: calling BIOS POST
> >> Jul 20 16:07:00 x201i kernel: ahcich0: AHCI reset...
> >> Jul 20 16:07:00 x201i kernel: ahcich0: SATA connect time=100us
> >> status=00000123
> >> Jul 20 16:07:00 x201i kernel: ahcich0: AHCI reset: device found
> >> Jul 20 16:07:00 x201i kernel: ahcich1: AHCI reset...
> >> Jul 20 16:07:00 x201i kernel: ahcich1: SATA connect timeout time=10000us
> >> status=00000000
> >> Jul 20 16:07:00 x201i kernel: ahcich1: AHCI reset: device not found
> >> Jul 20 16:07:00 x201i kernel: ahcich4: AHCI reset...
> >> Jul 20 16:07:00 x201i kernel: ahcich4: SATA connect timeout time=10000us
> >> status=00000000
> >> Jul 20 16:07:00 x201i kernel: ahcich4: AHCI reset: device not found
> >> Jul 20 16:07:00 x201i kernel: ahcich5: AHCI reset...
> >> Jul 20 16:07:00 x201i kernel: ahcich5: SATA connect timeout time=10000us
> >> status=00000000
> >> Jul 20 16:07:00 x201i kernel: ahcich5: AHCI reset: device not found
> >> Jul 20 16:07:00 x201i kernel: atkbd: the current kbd controller command
> >> byte 0047
> >> Jul 20 16:07:00 x201i kernel: atkbd: keyboard ID 0x54ab (2)
> >> Jul 20 16:07:00 x201i kernel: kbdc: RESET_KBD return code:00fa
> >> Jul 20 16:07:00 x201i kernel: kbdc: RESET_KBD status:00aa
> >> Jul 20 16:07:00 x201i kernel: kbdc: TEST_AUX_PORT status:0000
> >> Jul 20 16:07:00 x201i kernel: kbdc: RESET_AUX return code:00fa
> >> Jul 20 16:07:00 x201i kernel: kbdc: RESET_AUX status:00aa
> >> Jul 20 16:07:00 x201i kernel: kbdc: RESET_AUX ID:0000
> >> Jul 20 16:07:00 x201i kernel: battery0: battery initialization start
> >> Jul 20 16:07:00 x201i kernel: ahcich0: AHCI reset: device ready after
> >> 100ms
> >> Jul 20 16:07:00 x201i kernel: battery0: battery initialization done,
> tried
> >> 1 times
> >> Jul 20 16:07:00 x201i kernel: (ada0:ahcich0:0:0:0): resume
> >> Jul 20 16:07:00 x201i kernel: acpi_timer0: restoring timecounter,
> >> ACPI-safe -> TSC-low
> >> Jul 20 16:07:00 x201i kernel: uhub0: <Intel EHCI root HUB, class 9/0,
> rev
> >> 2.00/1.00, addr 1> on usbus1
> >> Jul 20 16:07:00 x201i kernel: uhub1: <Intel EHCI root HUB, class 9/0,
> rev
> >> 2.00/1.00, addr 1> on usbus0
> >> Jul 20 16:07:00 x201i kernel: wlan0: link state changed to UP
> >> Jul 20 16:07:00 x201i kernel: uhub0: 3 ports with 3 removable, self
> >> powered
> >> Jul 20 16:07:00 x201i kernel: uhub1: 3 ports with 3 removable, self
> >> powered
> >> Jul 20 16:06:57 x201i wpa_supplicant[525]: CTRL-EVENT-DISCONNECTED
> >> bssid=c0:c5:20:1b:59:aa reason=0
> >> Jul 20 16:06:57 x201i wpa_supplicant[525]: Failed to initiate AP scan.
> >> Jul 20 16:06:59 x201i acpi: resumed at 20120720 16:06:59
> >> Jul 20 16:06:59 x201i wpa_supplicant[525]: Trying to associate with
> >> c0:c5:20:1b:69:8a (SSID='LITB-AP' freq=2417 MHz)
> >> Jul 20 16:07:00 x201i wpa_supplicant[525]: Associated with
> >> c0:c5:20:1b:69:8a
> >> Jul 20 16:07:00 x201i wpa_supplicant[525]: WPA: Key negotiation
> completed
> >> with c0:c5:20:1b:69:8a [PTK=CCMP GTK=CCMP]
> >> Jul 20 16:07:00 x201i wpa_supplicant[525]: CTRL-EVENT-CONNECTED -
> >> Connection to c0:c5:20:1b:69:8a completed (reauth) [id=0 id_str=]
> >> Jul 20 16:07:00 x201i dhclient: New IP Address (wlan0): 192.168.61.184
> >> Jul 20 16:07:00 x201i dhclient: New Subnet Mask (wlan0): 255.255.255.0
> >> Jul 20 16:07:00 x201i dhclient: New Broadcast Address (wlan0):
> >> 192.168.61.255
> >> Jul 20 16:07:00 x201i dhclient: New Routers (wlan0): 192.168.61.1
> >> Jul 20 16:07:01 x201i kernel: ugen1.2: <vendor 0x8087> at usbus1
> >> Jul 20 16:07:01 x201i kernel: uhub2: <vendor 0x8087 product 0x0020,
> class
> >> 9/0, rev 2.00/0.00, addr 2> on usbus1
> >> Jul 20 16:07:01 x201i kernel: ugen0.2: <vendor 0x8087> at usbus0
> >> Jul 20 16:07:01 x201i kernel: uhub3: <vendor 0x8087 product 0x0020,
> class
> >> 9/0, rev 2.00/0.00, addr 2> on usbus0
> >> Jul 20 16:07:02 x201i kernel: uhub3: 6 ports with 6 removable, self
> >> powered
> >> Jul 20 16:07:02 x201i kernel: uhub2: 8 ports with 8 removable, self
> >> powered
> >>
> >> _______________________________________________
> >> [hidden email] mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> >> To unsubscribe, send any mail to "[hidden email]"
> >>
> >
>
> Today , I build my kernel disabled vesa.
> Now , there has so many error messages in dmesg:
> Jul 22 16:42:18 x201i kernel: ACPI Error: No object attached to node
> 0xfffffe00029a6780 (20110527/exresnte-139)
> Jul 22 16:42:18 x201i kernel: ACPI Error: Method execution failed
> [\_SB_.PCI0.LPC_.EC__.BAT0._HID] (Node 0xfffffe00029a6780),
> AE_AML_NO_OPERAND (20110527/uteval-113)
>
>
>
> When I test acpiconf -s 3, it's hangup:
> #sysctl debug.acpi.suspend_bounce=1
> #acpiconf -s 3
> ahcich0: AHCI reset: device not ready after 31000ms (tfd = 00000080)
> ahcich0: Timeout on slot 12 port 0
> ......
> achich0: AHCI reset ...
> ahcich0: SATA connect time=100us status=0000123
> ahcich0: AHCI reset: device found
> (aprobe0:ahchih0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00
> 00 00
> (aprobe0:ahchih0:0:0:0): CAM status: command timeout
> (aprobe0:ahchih0:0:0:0): Error 5, Retry was blocked
>
> reboot by push power button:
> #sysctl debug.acpi.suspend_bounce=0
> #acpiconf -s 3
> It's will suspend, and sleep LED will light.
> But can't resume. No button can resume it.
>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Re: Resume failed after Suspend on Thinkpad x201i

Zack Breckenridge
Oops, there was an error with the attachment. Here's a second try.

- Zack

On Sun, Jul 22, 2012 at 2:45 PM, Zack Breckenridge <[hidden email]> wrote:

> Attached is the kernel configuration file I used to build my kernel
> without VESA.
>
> I went through the same process as you: setting suspend bounce, etc., and
> looking at the dmesg output. Again, I also looked at the witness output
> from my Intel driver when resuming X -- and I noticed that it simply wasn't
> able to reach the GPU.
>
> So I think it is some sort of bus error on resume and is related to our
> different BIOSes. Since it worked for me, probably some int 10 call in VESA
> was causing the error. In your case - not being able to issue commands to
> an ATA device could also be a bus issue, caused by NOT calling the proper
> INT 10 setup functions on resume.
>
> I'm going to build a debug kernel today and see if I can start tracking
> the problem to it's root.
>
> - Zack
>
> On Sun, Jul 22, 2012 at 4:36 AM, 乔楚 <[hidden email]> wrote:
>
>> 2012/7/20 Zack Breckenridge <[hidden email]>:
>> > If you look at the line:
>> >
>> >
>> >> Jul 20 16:07:00 x201i kernel: vga0: calling BIOS POST
>> >
>> > in your dmesg output, and then grep through the source, you'll find
>> this is
>> > actually being printed
>> > from "src/sys/dev/fb/vesa.c" .
>> >
>> > I had a similar problem. After syncing with FreeBSD 10-CURRENT and
>> compiling
>> > a kernel without
>> > VESA support, I was able to get graphics to work on resume, but only
>> when
>> > running X.
>> >
>> > I don't think you actually have to sync with CURRENT though -- I think
>> you
>> > just need to compile without
>> > VESA. I synced with CURRENT to get the newer Intel GMA driver and KMS
>> > subsystem. Also, looking at
>> > the Witness output from the Intel driver, it looks like the graphics
>> card
>> > simply isn't accessible after
>> > this function in vesa.c is called, which means it probably causes the
>> same
>> > problem with your nvidia driver
>> > as well.
>> >
>> > I believe this problem is related to the "x86bios_init_regs" function,
>> > though I haven't had time to debug
>> > it yet. Also, I'm running amd64.
>> >
>> > Try it out...
>> >
>> > - Zack
>> >
>> > On Fri, Jul 20, 2012 at 1:09 AM, 乔楚/HonestQiao <[hidden email]>
>> wrote:
>> >>
>> >> >On Sat, Jul 7, 2012 at 10:40 AM, Brandon Gooch
>> >> ><[hidden email]> wrote:
>> >> >> On Wed, Jul 4, 2012 at 4:23 PM, mbsd <[hidden email]> wrote:
>> >> >>> On Tue, 2012-07-03 at 14:11 +0800, 乔楚/HonestQiao wrote:
>> >> >> [SNIP]
>> >> >>>>
>> >> >>>> In All the test, the screen is light and black, system is hangup,
>> >> >>>> nothing can be done.
>> >> >>>> The only thing can be done, is push power button, to force it
>> >> >>>> shutdown.
>> >> >>>
>> >> >>> Which graphic card have you used? If you have had nvidia, it's
>> normal,
>> >> >>> I've had the same problem "the screen is light and black".
>> >> >>
>> >> >> Can both of you show the output of `devinfo -v` from your systems?
>> >> >>
>> >> >> I was able to solve my suspend/resume issue with my nvidia-equipped
>> >> >> notebook by forcing the module load ordering of vgapm in
>> >> >> sys/isa/vga_isa.c:
>> >> >>
>> >> >> Index: sys/isa/vga_isa.c
>> >> >> ===================================================================
>> >> >> --- sys/isa/vga_isa.c   (revision 237779)
>> >> >> +++ sys/isa/vga_isa.c   (working copy)
>> >> >> @@ -379,4 +379,4 @@
>> >> >>         0
>> >> >>  };
>> >> >>
>> >> >> -DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0);
>> >> >> +DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0,
>> >> >> SI_ORDER_ANY);
>> >> >>
>> >> >>
>> >> >> The system requires however that I load the nvidia module in
>> >> >> /boot/loader.conf (as opposed to loading it after system is up and
>> >> >> running).
>> >> >>
>> >> >> -Brandon
>> >> >
>> >> >Oops, the patch above should instead be:
>> >> >
>> >> >Index: sys/isa/vga_isa.c
>> >> >===================================================================
>> >> >--- sys/isa/vga_isa.c   (revision 238266)
>> >> >+++ sys/isa/vga_isa.c   (working copy)
>> >> >@@ -379,4 +379,4 @@
>> >> >        0
>> >> > };
>> >> >
>> >> >-DRIVER_MODULE(vgapm, vgapci, vgapm_driver, vgapm_devclass, 0, 0);
>> >> >+DRIVER_MODULE_ORDERED(vgapm, vgapci, vgapm_driver, vgapm_devclass,
>> >> >NULL, NULL, SI_ORDER_ANY);
>> >> >
>> >> >I made the edit for the diff on a clean tree, but I'm actually
>> >> >building from another :)
>> >> >
>> >> >The above is correct. However, I'm still not sure this pertains to
>> >> >your Intel video problem.
>> >> >
>> >> >-Brandon
>> >>
>> >> Yesterday, I upgrade my freebsd to FreeBSD 9.1-PRERELEASE.
>> >> This method did not work.
>> >>
>> >> And command 'shutdown -p now' can shutdown the system,
>> >> but the Screen is black and light, and Battery LED is light.
>> >> This command can't power off.
>> >>
>> >> Whethe in:
>> >> sysctl -w hw.acpi.reset_video=0
>> >> sysctl -w hw.pci.do_power_suspend=1
>> >> sysctl -w hw.pci.do_power_resume=1
>> >> Or in:
>> >> sysctl -w hw.acpi.reset_video=0
>> >> sysctl -w hw.pci.do_power_suspend=1
>> >> sysctl -w hw.pci.do_power_resume=1
>> >>
>> >> I can execute acpiconf -s 3, but can't resume the screen which is black
>> >> and light.
>> >>
>> >> Log for command 'acpiconf -s 3':
>> >>
>> >> Jul 20 16:06:53 x201i acpi: suspend at 20120720 16:06:53
>> >> Jul 20 16:06:56 x201i kernel: acpi_timer0: switching timecounter,
>> TSC-low
>> >> -> ACPI-safe
>> >> Jul 20 16:06:56 x201i kernel: (ada0:ahcich0:0:0:0): spin-down
>> >> Jul 20 16:07:00 x201i kernel: acpi_lid0: wake_prep enabled for
>> \_SB_.LID_
>> >> (S3)
>> >> Jul 20 16:07:00 x201i kernel: acpi_button0: wake_prep enabled for
>> >> \_SB_.SLPB (S3)
>> >> Jul 20 16:07:00 x201i kernel: uhub0: at usbus0, port 1, addr 1
>> >> (disconnected)
>> >> Jul 20 16:07:00 x201i kernel: ugen0.2: <vendor 0x8087> at usbus0
>> >> (disconnected)
>> >> Jul 20 16:07:00 x201i kernel: uhub2: at uhub0, port 1, addr 2
>> >> (disconnected)
>> >> Jul 20 16:07:00 x201i kernel: pci0:0:28:0: Transition from D0 to D3
>> >> Jul 20 16:07:00 x201i kernel: pci0:0:28:3: Transition from D0 to D3
>> >> Jul 20 16:07:00 x201i kernel: wlan0: link state changed to DOWN
>> >> Jul 20 16:07:00 x201i kernel: pci0:2:0:0: Transition from D0 to D3
>> >> Jul 20 16:07:00 x201i kernel: pci0:0:28:4: Transition from D0 to D3
>> >> Jul 20 16:07:00 x201i kernel: uhub1: at usbus1, port 1, addr 1
>> >> (disconnected)
>> >> Jul 20 16:07:00 x201i kernel: ugen1.2: <vendor 0x8087> at usbus1
>> >> (disconnected)
>> >> Jul 20 16:07:00 x201i kernel: uhub3: at uhub1, port 1, addr 2
>> >> (disconnected)
>> >> Jul 20 16:07:00 x201i kernel: vga0: saving 4804 bytes of video state
>> >> Jul 20 16:07:00 x201i kernel: vga0: saving color palette
>> >> Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2
>> on
>> >> \_SB_.PCI0.EXP1: AE_BAD_PARAMETER
>> >> Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2
>> on
>> >> \_SB_.PCI0.EXP4: AE_BAD_PARAMETER
>> >> Jul 20 16:07:00 x201i kernel: pci0: failed to set ACPI power state D2
>> on
>> >> \_SB_.PCI0.EXP5: AE_BAD_PARAMETER
>> >> Jul 20 16:07:00 x201i kernel: acpi_lid0: wake_prep enabled for
>> \_SB_.LID_
>> >> (S3)
>> >> Jul 20 16:07:00 x201i kernel: acpi_button0: wake_prep enabled for
>> >> \_SB_.SLPB (S3)
>> >> Jul 20 16:07:00 x201i kernel: pci255: set ACPI power state D0 on
>> >> \_SB_.UNCR.SAD_
>> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> >> \_SB_.PCI0.VID_
>> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> >> \_SB_.PCI0.IGBE
>> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> >> \_SB_.PCI0.EHC2
>> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> >> \_SB_.PCI0.HDEF
>> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> >> \_SB_.PCI0.EXP1
>> >> Jul 20 16:07:00 x201i kernel: pci0:0:28:0: Transition from D3 to D0
>> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> >> \_SB_.PCI0.EXP4
>> >> Jul 20 16:07:00 x201i kernel: pci0:0:28:3: Transition from D3 to D0
>> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> >> \_SB_.PCI0.EXP5
>> >> Jul 20 16:07:00 x201i kernel: pci0:0:28:4: Transition from D3 to D0
>> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> >> \_SB_.PCI0.EHC1
>> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> >> \_SB_.PCI0.PCI1
>> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> >> \_SB_.PCI0.LPC_
>> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> >> \_SB_.PCI0.SAT1
>> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> >> \_SB_.PCI0.EXP1
>> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> >> \_SB_.PCI0.EXP4
>> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> >> \_SB_.PCI0.EXP5
>> >> Jul 20 16:07:00 x201i kernel: pci0:2:0:0: Transition from D3 to D0
>> >> Jul 20 16:07:00 x201i kernel: pci0: set ACPI power state D0 on
>> >> \_SB_.PCI0.PCI1
>> >> Jul 20 16:07:00 x201i kernel: vga0: calling BIOS POST
>> >> Jul 20 16:07:00 x201i kernel: ahcich0: AHCI reset...
>> >> Jul 20 16:07:00 x201i kernel: ahcich0: SATA connect time=100us
>> >> status=00000123
>> >> Jul 20 16:07:00 x201i kernel: ahcich0: AHCI reset: device found
>> >> Jul 20 16:07:00 x201i kernel: ahcich1: AHCI reset...
>> >> Jul 20 16:07:00 x201i kernel: ahcich1: SATA connect timeout
>> time=10000us
>> >> status=00000000
>> >> Jul 20 16:07:00 x201i kernel: ahcich1: AHCI reset: device not found
>> >> Jul 20 16:07:00 x201i kernel: ahcich4: AHCI reset...
>> >> Jul 20 16:07:00 x201i kernel: ahcich4: SATA connect timeout
>> time=10000us
>> >> status=00000000
>> >> Jul 20 16:07:00 x201i kernel: ahcich4: AHCI reset: device not found
>> >> Jul 20 16:07:00 x201i kernel: ahcich5: AHCI reset...
>> >> Jul 20 16:07:00 x201i kernel: ahcich5: SATA connect timeout
>> time=10000us
>> >> status=00000000
>> >> Jul 20 16:07:00 x201i kernel: ahcich5: AHCI reset: device not found
>> >> Jul 20 16:07:00 x201i kernel: atkbd: the current kbd controller command
>> >> byte 0047
>> >> Jul 20 16:07:00 x201i kernel: atkbd: keyboard ID 0x54ab (2)
>> >> Jul 20 16:07:00 x201i kernel: kbdc: RESET_KBD return code:00fa
>> >> Jul 20 16:07:00 x201i kernel: kbdc: RESET_KBD status:00aa
>> >> Jul 20 16:07:00 x201i kernel: kbdc: TEST_AUX_PORT status:0000
>> >> Jul 20 16:07:00 x201i kernel: kbdc: RESET_AUX return code:00fa
>> >> Jul 20 16:07:00 x201i kernel: kbdc: RESET_AUX status:00aa
>> >> Jul 20 16:07:00 x201i kernel: kbdc: RESET_AUX ID:0000
>> >> Jul 20 16:07:00 x201i kernel: battery0: battery initialization start
>> >> Jul 20 16:07:00 x201i kernel: ahcich0: AHCI reset: device ready after
>> >> 100ms
>> >> Jul 20 16:07:00 x201i kernel: battery0: battery initialization done,
>> tried
>> >> 1 times
>> >> Jul 20 16:07:00 x201i kernel: (ada0:ahcich0:0:0:0): resume
>> >> Jul 20 16:07:00 x201i kernel: acpi_timer0: restoring timecounter,
>> >> ACPI-safe -> TSC-low
>> >> Jul 20 16:07:00 x201i kernel: uhub0: <Intel EHCI root HUB, class 9/0,
>> rev
>> >> 2.00/1.00, addr 1> on usbus1
>> >> Jul 20 16:07:00 x201i kernel: uhub1: <Intel EHCI root HUB, class 9/0,
>> rev
>> >> 2.00/1.00, addr 1> on usbus0
>> >> Jul 20 16:07:00 x201i kernel: wlan0: link state changed to UP
>> >> Jul 20 16:07:00 x201i kernel: uhub0: 3 ports with 3 removable, self
>> >> powered
>> >> Jul 20 16:07:00 x201i kernel: uhub1: 3 ports with 3 removable, self
>> >> powered
>> >> Jul 20 16:06:57 x201i wpa_supplicant[525]: CTRL-EVENT-DISCONNECTED
>> >> bssid=c0:c5:20:1b:59:aa reason=0
>> >> Jul 20 16:06:57 x201i wpa_supplicant[525]: Failed to initiate AP scan.
>> >> Jul 20 16:06:59 x201i acpi: resumed at 20120720 16:06:59
>> >> Jul 20 16:06:59 x201i wpa_supplicant[525]: Trying to associate with
>> >> c0:c5:20:1b:69:8a (SSID='LITB-AP' freq=2417 MHz)
>> >> Jul 20 16:07:00 x201i wpa_supplicant[525]: Associated with
>> >> c0:c5:20:1b:69:8a
>> >> Jul 20 16:07:00 x201i wpa_supplicant[525]: WPA: Key negotiation
>> completed
>> >> with c0:c5:20:1b:69:8a [PTK=CCMP GTK=CCMP]
>> >> Jul 20 16:07:00 x201i wpa_supplicant[525]: CTRL-EVENT-CONNECTED -
>> >> Connection to c0:c5:20:1b:69:8a completed (reauth) [id=0 id_str=]
>> >> Jul 20 16:07:00 x201i dhclient: New IP Address (wlan0): 192.168.61.184
>> >> Jul 20 16:07:00 x201i dhclient: New Subnet Mask (wlan0): 255.255.255.0
>> >> Jul 20 16:07:00 x201i dhclient: New Broadcast Address (wlan0):
>> >> 192.168.61.255
>> >> Jul 20 16:07:00 x201i dhclient: New Routers (wlan0): 192.168.61.1
>> >> Jul 20 16:07:01 x201i kernel: ugen1.2: <vendor 0x8087> at usbus1
>> >> Jul 20 16:07:01 x201i kernel: uhub2: <vendor 0x8087 product 0x0020,
>> class
>> >> 9/0, rev 2.00/0.00, addr 2> on usbus1
>> >> Jul 20 16:07:01 x201i kernel: ugen0.2: <vendor 0x8087> at usbus0
>> >> Jul 20 16:07:01 x201i kernel: uhub3: <vendor 0x8087 product 0x0020,
>> class
>> >> 9/0, rev 2.00/0.00, addr 2> on usbus0
>> >> Jul 20 16:07:02 x201i kernel: uhub3: 6 ports with 6 removable, self
>> >> powered
>> >> Jul 20 16:07:02 x201i kernel: uhub2: 8 ports with 8 removable, self
>> >> powered
>> >>
>> >> _______________________________________________
>> >> [hidden email] mailing list
>> >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>> >> To unsubscribe, send any mail to "[hidden email]
>> "
>> >>
>> >
>>
>> Today , I build my kernel disabled vesa.
>> Now , there has so many error messages in dmesg:
>> Jul 22 16:42:18 x201i kernel: ACPI Error: No object attached to node
>> 0xfffffe00029a6780 (20110527/exresnte-139)
>> Jul 22 16:42:18 x201i kernel: ACPI Error: Method execution failed
>> [\_SB_.PCI0.LPC_.EC__.BAT0._HID] (Node 0xfffffe00029a6780),
>> AE_AML_NO_OPERAND (20110527/uteval-113)
>>
>>
>>
>> When I test acpiconf -s 3, it's hangup:
>> #sysctl debug.acpi.suspend_bounce=1
>> #acpiconf -s 3
>> ahcich0: AHCI reset: device not ready after 31000ms (tfd = 00000080)
>> ahcich0: Timeout on slot 12 port 0
>> ......
>> achich0: AHCI reset ...
>> ahcich0: SATA connect time=100us status=0000123
>> ahcich0: AHCI reset: device found
>> (aprobe0:ahchih0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00
>> 00 00
>> (aprobe0:ahchih0:0:0:0): CAM status: command timeout
>> (aprobe0:ahchih0:0:0:0): Error 5, Retry was blocked
>>
>> reboot by push power button:
>> #sysctl debug.acpi.suspend_bounce=0
>> #acpiconf -s 3
>> It's will suspend, and sleep LED will light.
>> But can't resume. No button can resume it.
>>
>
>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"

NOVESA (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Resume failed after Suspend on Thinkpad x201i

乔楚/HonestQiao
In reply to this post by Zack Breckenridge
2012-07-23 05:45, Zack Breckenridge<[hidden email]> wrote:

>Attached is the kernel configuration file I used to build my kernel without
>VESA.
>
>I went through the same process as you: setting suspend bounce, etc., and
>looking at the dmesg output. Again, I also looked at the witness output
>from my Intel driver when resuming X -- and I noticed that it simply wasn't
>able to reach the GPU.
>
>So I think it is some sort of bus error on resume and is related to our
>different BIOSes. Since it worked for me, probably some int 10 call in VESA
>was causing the error. In your case - not being able to issue commands to
>an ATA device could also be a bus issue, caused by NOT calling the proper
>INT 10 setup functions on resume.
>
>I'm going to build a debug kernel today and see if I can start tracking the
>problem to it's root.
>
>- Zack
>
Are you new messages?
My kernel configuration file is similar to your.
But I removed the debugging options.

Can you list a step to test?
 I'll test each side to provide you with full information, which make it easy to find the problem?
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Re: Resume failed after Suspend on Thinkpad x201i

Zack Breckenridge
First of all, let me note that the Kernel config file I posted was for
10.0-CURRENT (a few weeks back now though).

I've been looking into it, but still haven't developed a patch yet. I
have verified that the screen blanking issue, on my hardware, occurs
somewhere in the vm86 mode emulation code (which is how VESA is
implemented on amd64), ultimately called by vesa_bios_post(), which is
called in turn by vesa_load_state() on resume [see:
http://fxr.watson.org/fxr/source/dev/fb/vesa.c?im=3#L1497].
vesa_bios_post() ultimately calls x86bios_call() [see:
http://fxr.watson.org/fxr/source/compat/x86bios/x86bios.c?im=10#L584]
and emulates the real mode VESA "initialization" code with a call to
x86emu_exec_call().

I think in order to figure out whats going on from here I will have to
do some DDB scripting and capture the output. I don't believe remote
debugging will be possible with my hardware (no serial, no
firewire)... Anyway, I'm working on it.

So to verify that we are having the same issue, you can take the
following steps:

1) build a kernel with debugging and VESA enabled:
    options VESA
    options KDB
    options DDB
2) disable X, boot into the console and issue the following commands:
    # sysctl debug.acpi.suspend_bounce=1
    # sysctl debug.kdb.enter=1
    db> break x86emu_exec_call
    db> c
    # zzz
    [you should hit the breakpoint]
    db> bt
    x86emu_exec_call() ...
    vesa_bios_post() ...
    ... rest of backtrace ...
    db> c
3) after hitting that last c, your screen should go black. Then you
should be able to type "reboot" and reboot cleanly

I'm pretty sure that if you get the same results, we are having the
same issue, though I can make no guarantees.



On Wed, Aug 1, 2012 at 10:07 AM, 乔楚/HonestQiao <[hidden email]> wrote:

>
> 2012-07-23 05:45, Zack Breckenridge<[hidden email]> wrote:
> >Attached is the kernel configuration file I used to build my kernel without
> >VESA.
> >
> >I went through the same process as you: setting suspend bounce, etc., and
> >looking at the dmesg output. Again, I also looked at the witness output
> >from my Intel driver when resuming X -- and I noticed that it simply wasn't
> >able to reach the GPU.
> >
> >So I think it is some sort of bus error on resume and is related to our
> >different BIOSes. Since it worked for me, probably some int 10 call in VESA
> >was causing the error. In your case - not being able to issue commands to
> >an ATA device could also be a bus issue, caused by NOT calling the proper
> >INT 10 setup functions on resume.
> >
> >I'm going to build a debug kernel today and see if I can start tracking the
> >problem to it's root.
> >
> >- Zack
> >
>
> Are you new messages?
> My kernel configuration file is similar to your.
> But I removed the debugging options.
>
> Can you list a step to test?
>  I'll test each side to provide you with full information, which make it easy to find the problem?
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Re: Resume failed after Suspend on Thinkpad x201i

乔楚/HonestQiao
2012/8/3 Zack Breckenridge <[hidden email]>:

> First of all, let me note that the Kernel config file I posted was for
> 10.0-CURRENT (a few weeks back now though).
>
> I've been looking into it, but still haven't developed a patch yet. I
> have verified that the screen blanking issue, on my hardware, occurs
> somewhere in the vm86 mode emulation code (which is how VESA is
> implemented on amd64), ultimately called by vesa_bios_post(), which is
> called in turn by vesa_load_state() on resume [see:
> http://fxr.watson.org/fxr/source/dev/fb/vesa.c?im=3#L1497].
> vesa_bios_post() ultimately calls x86bios_call() [see:
> http://fxr.watson.org/fxr/source/compat/x86bios/x86bios.c?im=10#L584]
> and emulates the real mode VESA "initialization" code with a call to
> x86emu_exec_call().
>
> I think in order to figure out whats going on from here I will have to
> do some DDB scripting and capture the output. I don't believe remote
> debugging will be possible with my hardware (no serial, no
> firewire)... Anyway, I'm working on it.
>
> So to verify that we are having the same issue, you can take the
> following steps:
>
> 1) build a kernel with debugging and VESA enabled:
>     options VESA
>     options KDB
>     options DDB
> 2) disable X, boot into the console and issue the following commands:
>     # sysctl debug.acpi.suspend_bounce=1
>     # sysctl debug.kdb.enter=1
>     db> break x86emu_exec_call
>     db> c
>     # zzz
>     [you should hit the breakpoint]
>     db> bt
>     x86emu_exec_call() ...
>     vesa_bios_post() ...
>     ... rest of backtrace ...
>     db> c
> 3) after hitting that last c, your screen should go black. Then you
> should be able to type "reboot" and reboot cleanly

My screen go black, but type "reboot" no effect. I can be sure to type
"reboot" and return.
LED status:
1. Disk LED is light, and off at a moment.
2. "Z" LED is light, Battary and power LED is light.
3. Wifi LED is light.

>
> I'm pretty sure that if you get the same results, we are having the
> same issue, though I can make no guarantees.
>
>

When I shutdown from KDE, or type shutdown -p now from console, my
laptor can't shutdown complete.
The battary LED is light alawys, others LED is off, and vents of the
laptor has been blowing hot air.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Resume failed after Suspend on Thinkpad x201i

Matt-332
On 08/03/12 23:39, 乔楚 wrote:

> 2012/8/3 Zack Breckenridge <[hidden email]>:
>> First of all, let me note that the Kernel config file I posted was for
>> 10.0-CURRENT (a few weeks back now though).
>>
>> I've been looking into it, but still haven't developed a patch yet. I
>> have verified that the screen blanking issue, on my hardware, occurs
>> somewhere in the vm86 mode emulation code (which is how VESA is
>> implemented on amd64), ultimately called by vesa_bios_post(), which is
>> called in turn by vesa_load_state() on resume [see:
>> http://fxr.watson.org/fxr/source/dev/fb/vesa.c?im=3#L1497].
>> vesa_bios_post() ultimately calls x86bios_call() [see:
>> http://fxr.watson.org/fxr/source/compat/x86bios/x86bios.c?im=10#L584]
>> and emulates the real mode VESA "initialization" code with a call to
>> x86emu_exec_call().
>>
>> I think in order to figure out whats going on from here I will have to
>> do some DDB scripting and capture the output. I don't believe remote
>> debugging will be possible with my hardware (no serial, no
>> firewire)... Anyway, I'm working on it.
>>
>> So to verify that we are having the same issue, you can take the
>> following steps:
>>
>> 1) build a kernel with debugging and VESA enabled:
>>      options VESA
>>      options KDB
>>      options DDB
>> 2) disable X, boot into the console and issue the following commands:
>>      # sysctl debug.acpi.suspend_bounce=1
>>      # sysctl debug.kdb.enter=1
>>      db> break x86emu_exec_call
>>      db> c
>>      # zzz
>>      [you should hit the breakpoint]
>>      db> bt
>>      x86emu_exec_call() ...
>>      vesa_bios_post() ...
>>      ... rest of backtrace ...
>>      db> c
>> 3) after hitting that last c, your screen should go black. Then you
>> should be able to type "reboot" and reboot cleanly
> My screen go black, but type "reboot" no effect. I can be sure to type
> "reboot" and return.
> LED status:
> 1. Disk LED is light, and off at a moment.
> 2. "Z" LED is light, Battary and power LED is light.
> 3. Wifi LED is light.
>
>> I'm pretty sure that if you get the same results, we are having the
>> same issue, though I can make no guarantees.
>>
>>
> When I shutdown from KDE, or type shutdown -p now from console, my
> laptor can't shutdown complete.
> The battary LED is light alawys, others LED is off, and vents of the
> laptor has been blowing hot air.
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "[hidden email]"
>
Honest Qiao: Regarding hot air, are you running powerd? Try "powerd -a
adaptive -b adaptive" as root and wait 5 minutes to see if the hot air
stops. If it works, try "man powerd" for installation instructions.
Lenovo laptops are thermally designed for low CPU utilization. I can
almost boil water on mine during buildworld. Without powerd, they run at
full thermal profile and act as excellent hand warmers.

Zack: Regarding remote debugging, do you have an expresscard/cardbus/etc
slot? Although hard to find you may be able to find a firewire card for
that. Not sure if that would work or not...same goes for a USB->Serial
console, my guess is that it wouldn't work?

Matt
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Resume failed after Suspend on Thinkpad x201i

乔楚/HonestQiao
2012/8/5 matt <[hidden email]>:

> On 08/03/12 23:39, 乔楚 wrote:
>>
>> 2012/8/3 Zack Breckenridge <[hidden email]>:
>>>
>>> First of all, let me note that the Kernel config file I posted was for
>>> 10.0-CURRENT (a few weeks back now though).
>>>
>>> I've been looking into it, but still haven't developed a patch yet. I
>>> have verified that the screen blanking issue, on my hardware, occurs
>>> somewhere in the vm86 mode emulation code (which is how VESA is
>>> implemented on amd64), ultimately called by vesa_bios_post(), which is
>>> called in turn by vesa_load_state() on resume [see:
>>> http://fxr.watson.org/fxr/source/dev/fb/vesa.c?im=3#L1497].
>>> vesa_bios_post() ultimately calls x86bios_call() [see:
>>> http://fxr.watson.org/fxr/source/compat/x86bios/x86bios.c?im=10#L584]
>>> and emulates the real mode VESA "initialization" code with a call to
>>> x86emu_exec_call().
>>>
>>> I think in order to figure out whats going on from here I will have to
>>> do some DDB scripting and capture the output. I don't believe remote
>>> debugging will be possible with my hardware (no serial, no
>>> firewire)... Anyway, I'm working on it.
>>>
>>> So to verify that we are having the same issue, you can take the
>>> following steps:
>>>
>>> 1) build a kernel with debugging and VESA enabled:
>>>      options VESA
>>>      options KDB
>>>      options DDB
>>> 2) disable X, boot into the console and issue the following commands:
>>>      # sysctl debug.acpi.suspend_bounce=1
>>>      # sysctl debug.kdb.enter=1
>>>      db> break x86emu_exec_call
>>>      db> c
>>>      # zzz
>>>      [you should hit the breakpoint]
>>>      db> bt
>>>      x86emu_exec_call() ...
>>>      vesa_bios_post() ...
>>>      ... rest of backtrace ...
>>>      db> c
>>> 3) after hitting that last c, your screen should go black. Then you
>>> should be able to type "reboot" and reboot cleanly
>>
>> My screen go black, but type "reboot" no effect. I can be sure to type
>> "reboot" and return.
>> LED status:
>> 1. Disk LED is light, and off at a moment.
>> 2. "Z" LED is light, Battary and power LED is light.
>> 3. Wifi LED is light.
>>
>>> I'm pretty sure that if you get the same results, we are having the
>>> same issue, though I can make no guarantees.
>>>
>>>
>> When I shutdown from KDE, or type shutdown -p now from console, my
>> laptor can't shutdown complete.
>> The battary LED is light alawys, others LED is off, and vents of the
>> laptor has been blowing hot air.
>> _______________________________________________
>> [hidden email] mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>> To unsubscribe, send any mail to "[hidden email]"
>>
> Honest Qiao: Regarding hot air, are you running powerd? Try "powerd -a
> adaptive -b adaptive" as root and wait 5 minutes to see if the hot air
> stops. If it works, try "man powerd" for installation instructions. Lenovo
> laptops are thermally designed for low CPU utilization. I can almost boil
> water on mine during buildworld. Without powerd, they run at full thermal
> profile and act as excellent hand warmers.
>
> Zack: Regarding remote debugging, do you have an expresscard/cardbus/etc
> slot? Although hard to find you may be able to find a firewire card for
> that. Not sure if that would work or not...same goes for a USB->Serial
> console, my guess is that it wouldn't work?
>
> Matt

Regarding powerd:
I know powerd.
I also set it autostart in rc.conf:
powerd_enable="YES"
powerd_flags="-a adaptive -b adaptive"
And I know that sysctl named dev.cpu.0.freq will change between 333 to
2333 with system load.

But, When I shutdown the system, the battery indicator finally closed,
the fan also continue to operate;
Because the fan is in operation, and blow hot air, indicating that the
CPU does not really stop working.

So my system did not really close.If I do not press the power button
to force shut down the power supply, the battery LED is always on,
whether connected to AC power.
If I accidentally put it in a laptor bag, he will become hot.


Regarding extend slot:
Lenovo thinkpad x201 only has USB slot. It hasn't Serial slot.
I also think that a USB => serial can not be with the remote debugging.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Resume failed after Suspend on Thinkpad x201i

Zack Breckenridge
At this point, after having simply read through the sources and done
some research, it looks like remote debugging might not be necessary,
or even very useful, in this case after all (though it would be nice
to have for future debugging endeavors so I will look into your
suggestions, thank you).

So once again, on my hardware and probably Honest Qiao's as well, the
call the vesa_bios_post() on resume really boils down to:

   x86bios_call(&regs, X86BIOS_PHYSTOSEG(vesa_bios_offs + 3),
X86BIOS_PHYSTOOFF(vesa_bios_offs + 3));

I think this is used to "normalize" the graphics card state [see:
http://fxr.watson.org/fxr/source/dev/fb/vesa.c#L1506], before using
VBE (real mode) state restore code to restore the state of the
graphics device. All it's doing is executing the POST code in the VESA
option ROM, copied to 0xc0000 by the BIOS (and this is an old "legacy"
boot method, apparently. UEFI BIOSes support this for "backward
compatibility"). So there's real mode code at this location and the
x86emu library is used to execute it, etc. This call is what is
causing my screen to "blank". However, it is also what is causing my
display to power on after a resume. If I comment out the call to
vesa_bios_post() in vesa_load_state(), then set
debug.acpi.suspend_bounce=1 and go S3, everything just works. The
screen even flashes when the VESA state restore code is executed and I
can use the VESA driver as usual - for example I can change the video
mode with "vidcontrol MODE_280".

But if I actually let the machine power down, on resume the display
never powers back on. I was hoping I could use the VESA DPMS driver to
power it back on and everything would just work (though this would
still be a temporary hack).

So I'm looking for a general way of powering on the display after
resume that works for everyone. Obviously this code worked for the
original developer(s) hardware and may work well for a set of hardware
out there. One line of inquiry I'm following is how i915kms powers the
device on after a resume - because it does and works just fine.

Zack

On Sun, Aug 5, 2012 at 12:14 AM, 乔楚 <[hidden email]> wrote:

> 2012/8/5 matt <[hidden email]>:
>> On 08/03/12 23:39, 乔楚 wrote:
>>>
>>> 2012/8/3 Zack Breckenridge <[hidden email]>:
>>>>
>>>> First of all, let me note that the Kernel config file I posted was for
>>>> 10.0-CURRENT (a few weeks back now though).
>>>>
>>>> I've been looking into it, but still haven't developed a patch yet. I
>>>> have verified that the screen blanking issue, on my hardware, occurs
>>>> somewhere in the vm86 mode emulation code (which is how VESA is
>>>> implemented on amd64), ultimately called by vesa_bios_post(), which is
>>>> called in turn by vesa_load_state() on resume [see:
>>>> http://fxr.watson.org/fxr/source/dev/fb/vesa.c?im=3#L1497].
>>>> vesa_bios_post() ultimately calls x86bios_call() [see:
>>>> http://fxr.watson.org/fxr/source/compat/x86bios/x86bios.c?im=10#L584]
>>>> and emulates the real mode VESA "initialization" code with a call to
>>>> x86emu_exec_call().
>>>>
>>>> I think in order to figure out whats going on from here I will have to
>>>> do some DDB scripting and capture the output. I don't believe remote
>>>> debugging will be possible with my hardware (no serial, no
>>>> firewire)... Anyway, I'm working on it.
>>>>
>>>> So to verify that we are having the same issue, you can take the
>>>> following steps:
>>>>
>>>> 1) build a kernel with debugging and VESA enabled:
>>>>      options VESA
>>>>      options KDB
>>>>      options DDB
>>>> 2) disable X, boot into the console and issue the following commands:
>>>>      # sysctl debug.acpi.suspend_bounce=1
>>>>      # sysctl debug.kdb.enter=1
>>>>      db> break x86emu_exec_call
>>>>      db> c
>>>>      # zzz
>>>>      [you should hit the breakpoint]
>>>>      db> bt
>>>>      x86emu_exec_call() ...
>>>>      vesa_bios_post() ...
>>>>      ... rest of backtrace ...
>>>>      db> c
>>>> 3) after hitting that last c, your screen should go black. Then you
>>>> should be able to type "reboot" and reboot cleanly
>>>
>>> My screen go black, but type "reboot" no effect. I can be sure to type
>>> "reboot" and return.
>>> LED status:
>>> 1. Disk LED is light, and off at a moment.
>>> 2. "Z" LED is light, Battary and power LED is light.
>>> 3. Wifi LED is light.
>>>
>>>> I'm pretty sure that if you get the same results, we are having the
>>>> same issue, though I can make no guarantees.
>>>>
>>>>
>>> When I shutdown from KDE, or type shutdown -p now from console, my
>>> laptor can't shutdown complete.
>>> The battary LED is light alawys, others LED is off, and vents of the
>>> laptor has been blowing hot air.
>>> _______________________________________________
>>> [hidden email] mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>>> To unsubscribe, send any mail to "[hidden email]"
>>>
>> Honest Qiao: Regarding hot air, are you running powerd? Try "powerd -a
>> adaptive -b adaptive" as root and wait 5 minutes to see if the hot air
>> stops. If it works, try "man powerd" for installation instructions. Lenovo
>> laptops are thermally designed for low CPU utilization. I can almost boil
>> water on mine during buildworld. Without powerd, they run at full thermal
>> profile and act as excellent hand warmers.
>>
>> Zack: Regarding remote debugging, do you have an expresscard/cardbus/etc
>> slot? Although hard to find you may be able to find a firewire card for
>> that. Not sure if that would work or not...same goes for a USB->Serial
>> console, my guess is that it wouldn't work?
>>
>> Matt
>
> Regarding powerd:
> I know powerd.
> I also set it autostart in rc.conf:
> powerd_enable="YES"
> powerd_flags="-a adaptive -b adaptive"
> And I know that sysctl named dev.cpu.0.freq will change between 333 to
> 2333 with system load.
>
> But, When I shutdown the system, the battery indicator finally closed,
> the fan also continue to operate;
> Because the fan is in operation, and blow hot air, indicating that the
> CPU does not really stop working.
>
> So my system did not really close.If I do not press the power button
> to force shut down the power supply, the battery LED is always on,
> whether connected to AC power.
> If I accidentally put it in a laptor bag, he will become hot.
>
>
> Regarding extend slot:
> Lenovo thinkpad x201 only has USB slot. It hasn't Serial slot.
> I also think that a USB => serial can not be with the remote debugging.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Resume failed after Suspend on Thinkpad x201i

乔楚/HonestQiao
2012/8/6 Zack Breckenridge <[hidden email]>:

> At this point, after having simply read through the sources and done
> some research, it looks like remote debugging might not be necessary,
> or even very useful, in this case after all (though it would be nice
> to have for future debugging endeavors so I will look into your
> suggestions, thank you).
>
> So once again, on my hardware and probably Honest Qiao's as well, the
> call the vesa_bios_post() on resume really boils down to:
>
>    x86bios_call(&regs, X86BIOS_PHYSTOSEG(vesa_bios_offs + 3),
> X86BIOS_PHYSTOOFF(vesa_bios_offs + 3));
>
> I think this is used to "normalize" the graphics card state [see:
> http://fxr.watson.org/fxr/source/dev/fb/vesa.c#L1506], before using
> VBE (real mode) state restore code to restore the state of the
> graphics device. All it's doing is executing the POST code in the VESA
> option ROM, copied to 0xc0000 by the BIOS (and this is an old "legacy"
> boot method, apparently. UEFI BIOSes support this for "backward
> compatibility"). So there's real mode code at this location and the
> x86emu library is used to execute it, etc. This call is what is
> causing my screen to "blank". However, it is also what is causing my
> display to power on after a resume. If I comment out the call to
> vesa_bios_post() in vesa_load_state(), then set
> debug.acpi.suspend_bounce=1 and go S3, everything just works. The
> screen even flashes when the VESA state restore code is executed and I
> can use the VESA driver as usual - for example I can change the video
> mode with "vidcontrol MODE_280".
>
> But if I actually let the machine power down, on resume the display
> never powers back on. I was hoping I could use the VESA DPMS driver to
> power it back on and everything would just work (though this would
> still be a temporary hack).
>
> So I'm looking for a general way of powering on the display after
> resume that works for everyone. Obviously this code worked for the
> original developer(s) hardware and may work well for a set of hardware
> out there. One line of inquiry I'm following is how i915kms powers the
> device on after a resume - because it does and works just fine.
>
> Zack
>
> On Sun, Aug 5, 2012 at 12:14 AM, 乔楚 <[hidden email]> wrote:
>> 2012/8/5 matt <[hidden email]>:
>>> On 08/03/12 23:39, 乔楚 wrote:
>>>>
>>>> 2012/8/3 Zack Breckenridge <[hidden email]>:
>>>>>
>>>>> First of all, let me note that the Kernel config file I posted was for
>>>>> 10.0-CURRENT (a few weeks back now though).
>>>>>
>>>>> I've been looking into it, but still haven't developed a patch yet. I
>>>>> have verified that the screen blanking issue, on my hardware, occurs
>>>>> somewhere in the vm86 mode emulation code (which is how VESA is
>>>>> implemented on amd64), ultimately called by vesa_bios_post(), which is
>>>>> called in turn by vesa_load_state() on resume [see:
>>>>> http://fxr.watson.org/fxr/source/dev/fb/vesa.c?im=3#L1497].
>>>>> vesa_bios_post() ultimately calls x86bios_call() [see:
>>>>> http://fxr.watson.org/fxr/source/compat/x86bios/x86bios.c?im=10#L584]
>>>>> and emulates the real mode VESA "initialization" code with a call to
>>>>> x86emu_exec_call().
>>>>>
>>>>> I think in order to figure out whats going on from here I will have to
>>>>> do some DDB scripting and capture the output. I don't believe remote
>>>>> debugging will be possible with my hardware (no serial, no
>>>>> firewire)... Anyway, I'm working on it.
>>>>>
>>>>> So to verify that we are having the same issue, you can take the
>>>>> following steps:
>>>>>
>>>>> 1) build a kernel with debugging and VESA enabled:
>>>>>      options VESA
>>>>>      options KDB
>>>>>      options DDB
>>>>> 2) disable X, boot into the console and issue the following commands:
>>>>>      # sysctl debug.acpi.suspend_bounce=1
>>>>>      # sysctl debug.kdb.enter=1
>>>>>      db> break x86emu_exec_call
>>>>>      db> c
>>>>>      # zzz
>>>>>      [you should hit the breakpoint]
>>>>>      db> bt
>>>>>      x86emu_exec_call() ...
>>>>>      vesa_bios_post() ...
>>>>>      ... rest of backtrace ...
>>>>>      db> c
>>>>> 3) after hitting that last c, your screen should go black. Then you
>>>>> should be able to type "reboot" and reboot cleanly
>>>>
>>>> My screen go black, but type "reboot" no effect. I can be sure to type
>>>> "reboot" and return.
>>>> LED status:
>>>> 1. Disk LED is light, and off at a moment.
>>>> 2. "Z" LED is light, Battary and power LED is light.
>>>> 3. Wifi LED is light.
>>>>
>>>>> I'm pretty sure that if you get the same results, we are having the
>>>>> same issue, though I can make no guarantees.
>>>>>
>>>>>
>>>> When I shutdown from KDE, or type shutdown -p now from console, my
>>>> laptor can't shutdown complete.
>>>> The battary LED is light alawys, others LED is off, and vents of the
>>>> laptor has been blowing hot air.
>>>> _______________________________________________
>>>> [hidden email] mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>>>> To unsubscribe, send any mail to "[hidden email]"
>>>>
>>> Honest Qiao: Regarding hot air, are you running powerd? Try "powerd -a
>>> adaptive -b adaptive" as root and wait 5 minutes to see if the hot air
>>> stops. If it works, try "man powerd" for installation instructions. Lenovo
>>> laptops are thermally designed for low CPU utilization. I can almost boil
>>> water on mine during buildworld. Without powerd, they run at full thermal
>>> profile and act as excellent hand warmers.
>>>
>>> Zack: Regarding remote debugging, do you have an expresscard/cardbus/etc
>>> slot? Although hard to find you may be able to find a firewire card for
>>> that. Not sure if that would work or not...same goes for a USB->Serial
>>> console, my guess is that it wouldn't work?
>>>
>>> Matt
>>
>> Regarding powerd:
>> I know powerd.
>> I also set it autostart in rc.conf:
>> powerd_enable="YES"
>> powerd_flags="-a adaptive -b adaptive"
>> And I know that sysctl named dev.cpu.0.freq will change between 333 to
>> 2333 with system load.
>>
>> But, When I shutdown the system, the battery indicator finally closed,
>> the fan also continue to operate;
>> Because the fan is in operation, and blow hot air, indicating that the
>> CPU does not really stop working.
>>
>> So my system did not really close.If I do not press the power button
>> to force shut down the power supply, the battery LED is always on,
>> whether connected to AC power.
>> If I accidentally put it in a laptor bag, he will become hot.
>>
>>
>> Regarding extend slot:
>> Lenovo thinkpad x201 only has USB slot. It hasn't Serial slot.
>> I also think that a USB => serial can not be with the remote debugging.

Thank you for your hard work.

I want to know, is there any way to  solve problems that can not be
shutdown the system.
As I said earlier, command "shutdown -p now" can shutdown the os, but
it can not turn off the battery and can not real turn off CPU and fan.
This Problem made ​​me a headache. Every time I have to hold the power
button to force shutdown.
I'm afraid that when forgotten, will lead to serious consequences.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[hidden email]"