Re: managing a fan speed via memory address

[Adrian Chadd]

Is it not an ACPI driver? If not, you could write a quick fan driver!

Is there a thermal sensor(s) you could read to see how warm they get?



-adrian


On Tue, 2 May 2023 at 17:06, Dmitry N. Medvedev 
wrote:

> good morning,
>
> Recently I have learned about the dmidecode program and found the address
> of the FRNTFAN port in my HP Z420 machine: 0x0037.
> Since I am a complete newbie, I would like to learn if there is a way to
> read and change the value at this address.
> I need a bit of guidance.
>
> *The context*: I have added 8 SAS disks to the machine, put noctua fan in
> front of them and connected the fan to the FRNTFAN port on the motherboard.
> It looks like the fan works, but I am sure the disks would benefit if the
> fan produced more pressure. Which I fantasize I could do via changing the
> value at the said address.
> Not sure, of course.
>
> best regards,
> Dmitry N. Medvedev
>

Re: loading the coredump file to memory

[Adrian Chadd]

hi,

What's openbsd do exactly?


-adrian


On Tue, 26 Mar 2019 at 12:00, Shivaprashanth H <
shivprashant...@globaledgesoft.com> wrote:

> Two options. One to use coredump. Other to port from openbsd where
> hibernate is working fine
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------
> *From:* Adrian Chadd 
> *Sent:* Wednesday, March 27, 2019 12:27:55 AM
> *To:* Shivaprashanth H
> *Cc:* Peter Jeremy; freebsd-acpi@freebsd.org
> *Subject:* Re: loading the coredump file to memory
>
> woo!
>
>
>
> -adrian
>
>
> On Tue, 26 Mar 2019 at 11:55, Shivaprashanth H <
> shivprashant...@globaledgesoft.com> wrote:
>
>> Yes 😁
>>
>> Get Outlook for Android <https://aka.ms/ghei36>
>>
>> --
>> *From:* Adrian Chadd 
>> *Sent:* Wednesday, March 27, 2019 12:24:17 AM
>> *To:* Peter Jeremy
>> *Cc:* Shivaprashanth H; freebsd-acpi@freebsd.org
>> *Subject:* Re: loading the coredump file to memory
>>
>> ... is someone trying to make suspend-to-disk work? :)
>>
>>
>> -adrian
>>
>> On Tue, 26 Mar 2019 at 11:45, Peter Jeremy  wrote:
>>
>>> On 2019-Mar-26 13:16:40 +, Shivaprashanth H <
>>> shivprashant...@globaledgesoft.com> wrote:
>>> >using sysctl debug.kdb.panic=1 command, panic can be simulated which
>>> results in system reboot and writing of system context(ram snapshot?) to a
>>> file vmcore.x in /var/crash
>>> >
>>> >my question is, will it be possible to load this file back into memory?
>>>
>>> If you mean, can you take the crashdump and turn it back into a running
>>> system,
>>> no that's not possible.  Maybe if you explain what your objective is, we
>>> might
>>> be able to make suggestions.
>>>
>>> (And, I'm not sure how this relates to ACPI).
>>> --
>>> Peter Jeremy
>>>
>> Disclaimer: "This message is intended only for the designated
>> recipient(s). It may contain confidential or proprietary information and
>> may be subject to other confidentiality protections. If you are not a
>> designated recipient, you may not review, copy or distribute this message.
>> Please notify the sender by e-mail and delete this message. GlobalEdge does
>> not accept any liability for virus infected mails."
>>
> Disclaimer: "This message is intended only for the designated
> recipient(s). It may contain confidential or proprietary information and
> may be subject to other confidentiality protections. If you are not a
> designated recipient, you may not review, copy or distribute this message.
> Please notify the sender by e-mail and delete this message. GlobalEdge does
> not accept any liability for virus infected mails."
>
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: loading the coredump file to memory

[Adrian Chadd]

woo!



-adrian


On Tue, 26 Mar 2019 at 11:55, Shivaprashanth H <
shivprashant...@globaledgesoft.com> wrote:

> Yes 😁
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------
> *From:* Adrian Chadd 
> *Sent:* Wednesday, March 27, 2019 12:24:17 AM
> *To:* Peter Jeremy
> *Cc:* Shivaprashanth H; freebsd-acpi@freebsd.org
> *Subject:* Re: loading the coredump file to memory
>
> ... is someone trying to make suspend-to-disk work? :)
>
>
> -adrian
>
> On Tue, 26 Mar 2019 at 11:45, Peter Jeremy  wrote:
>
>> On 2019-Mar-26 13:16:40 +, Shivaprashanth H <
>> shivprashant...@globaledgesoft.com> wrote:
>> >using sysctl debug.kdb.panic=1 command, panic can be simulated which
>> results in system reboot and writing of system context(ram snapshot?) to a
>> file vmcore.x in /var/crash
>> >
>> >my question is, will it be possible to load this file back into memory?
>>
>> If you mean, can you take the crashdump and turn it back into a running
>> system,
>> no that's not possible.  Maybe if you explain what your objective is, we
>> might
>> be able to make suggestions.
>>
>> (And, I'm not sure how this relates to ACPI).
>> --
>> Peter Jeremy
>>
> Disclaimer: "This message is intended only for the designated
> recipient(s). It may contain confidential or proprietary information and
> may be subject to other confidentiality protections. If you are not a
> designated recipient, you may not review, copy or distribute this message.
> Please notify the sender by e-mail and delete this message. GlobalEdge does
> not accept any liability for virus infected mails."
>
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: loading the coredump file to memory

[Adrian Chadd]

... is someone trying to make suspend-to-disk work? :)


-adrian

On Tue, 26 Mar 2019 at 11:45, Peter Jeremy  wrote:

> On 2019-Mar-26 13:16:40 +, Shivaprashanth H <
> shivprashant...@globaledgesoft.com> wrote:
> >using sysctl debug.kdb.panic=1 command, panic can be simulated which
> results in system reboot and writing of system context(ram snapshot?) to a
> file vmcore.x in /var/crash
> >
> >my question is, will it be possible to load this file back into memory?
>
> If you mean, can you take the crashdump and turn it back into a running
> system,
> no that's not possible.  Maybe if you explain what your objective is, we
> might
> be able to make suggestions.
>
> (And, I'm not sure how this relates to ACPI).
> --
> Peter Jeremy
>
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: suspend to RAM stopped working on 11.2 (11.1 was OK)

[Adrian Chadd]

are you in console or xorg?

if in console try changing virtual consoles (alt-f2, alt-f1, etc)


-a


On Thu, 27 Sep 2018 at 10:59, Petr Fischer via freebsd-acpi <
freebsd-acpi@freebsd.org> wrote:

> Hello, suspend to RAM stopped working on my laptop on 11.2 (11.1 was OK)
>
> freebsd: 11.2-RELEASE-p3
> hardware: Toshiba Portege Z30 - Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
>
> tried with i915kms from FreeBSD base (default) and also with
> drm-next-kmod-4.11.g20180822
> (drm-stable-kmod-g20180822 freezes graphics 1 second after load)
>
> tried with hw.acpi.reset_video=0 and also with hw.acpi.reset_video=1
>
> Is there someone who can help me with debug this problem?
> I can compile something and test when you say.
>
> Thanks very much! Petr Fischer
>
>
> /var/log/messages after acpiconf -s 3 command:
> -
> Sep 27 19:49:40 pf-bsd acpi: suspend at 20180927 19:49:40
> Sep 27 19:49:54 pf-bsd kernel: Power well on
> Sep 27 19:49:54 pf-bsd kernel: vgapci0: child drmn0 requested
> pci_set_powerstate
> Sep 27 19:49:54 pf-bsd kernel: pci0: failed to set ACPI power state D3 on
> \_SB_.PCI0.GFX0: AE_BAD_PARAMETER
> Sep 27 19:49:54 pf-bsd kernel: hdac0: Command timeout on address 0
> Sep 27 19:49:54 pf-bsd kernel: uhub0: at usbus0, port 1, addr 1
> (disconnected)
> Sep 27 19:49:54 pf-bsd kernel: ugen0.2:  at
> usbus0 (disconnected)
> Sep 27 19:49:54 pf-bsd kernel: ums0: at uhub0, port 5, addr 1
> (disconnected)
> Sep 27 19:49:54 pf-bsd kernel: ums0: detached
> Sep 27 19:49:54 pf-bsd kernel: uhid0: at uhub0, port 5, addr 1
> (disconnected)
> Sep 27 19:49:54 pf-bsd kernel: uhid0: detached
> Sep 27 19:49:54 pf-bsd kernel: ugen0.3:  at
> usbus0 (disconnected)
> Sep 27 19:49:54 pf-bsd kernel: uhub3: at uhub0, port 6, addr 2
> (disconnected)
> Sep 27 19:49:54 pf-bsd kernel: ugen0.4:  at
> usbus0 (disconnected)
> Sep 27 19:49:54 pf-bsd kernel: uhub4: at uhub3, port 3, addr 3
> (disconnected)
> Sep 27 19:49:54 pf-bsd kernel: ugen0.5:  at
> usbus0 (disconnected)
> Sep 27 19:49:54 pf-bsd kernel: uhub4: detached
> Sep 27 19:49:54 pf-bsd kernel: uhub3: detached
> Sep 27 19:49:54 pf-bsd kernel: wlan0: link state changed to DOWN
> Sep 27 19:49:54 pf-bsd kernel: uhub1: at usbus1, port 1, addr 1
> (disconnected)
> Sep 27 19:49:54 pf-bsd kernel: ugen1.2:  at
> usbus1 (disconnected)
> Sep 27 19:49:54 pf-bsd kernel: uhub2: at uhub1, port 1, addr 2
> (disconnected)
> Sep 27 19:49:54 pf-bsd kernel: uhub2: detached
> Sep 27 19:49:54 pf-bsd kernel: pcib0: failed to set ACPI power state D2 on
> \_SB_.PCI0: AE_BAD_PARAMETER
> Sep 27 19:49:54 pf-bsd kernel: acpi0: cleared fixed power button status
> Sep 27 19:49:54 pf-bsd kernel: vgapci0: child drmn0 requested
> pci_set_powerstate
> Sep 27 19:49:54 pf-bsd kernel: vgapci0: child drmn0 requested pci_enable_io
> Sep 27 19:49:54 pf-bsd kernel: vgapci0: child drmn0 requested pci_enable_io
> Sep 27 19:49:54 pf-bsd kernel: hdac0: Device stuck in reset
> Sep 27 19:49:54 pf-bsd kernel: hdac0: Command timeout on address 0
> Sep 27 19:49:54 pf-bsd last message repeated 21 times
> Sep 27 19:49:54 pf-bsd kernel: xhci0: Port routing mask set to 0x
> Sep 27 19:49:54 pf-bsd kernel: uhub0: <0x8086 XHCI root HUB, class 9/0,
> rev 3.00/1.00, addr 1> on usbus0
> Sep 27 19:49:54 pf-bsd kernel: uhub1:  2.00/1.00, addr 1> on usbus1
> Sep 27 19:49:54 pf-bsd wpa_supplicant[58136]: wlan0:
> CTRL-EVENT-DISCONNECTED bssid=f0:79:59:d2:7a:00 reason=0
> Sep 27 19:49:54 pf-bsd wpa_supplicant[58136]: ioctl[SIOCS80211, op=20,
> val=0, arg_len=7]: Can't assign requested address
> Sep 27 19:49:54 pf-bsd acpi: resumed at 20180927 19:49:54
> Sep 27 19:49:55 pf-bsd kernel: uhub0: 13 ports with 13 removable, self
> powered
> Sep 27 19:49:55 pf-bsd kernel: uhub1: 2 ports with 2 removable, self
> powered
> Sep 27 19:49:56 pf-bsd kernel: ugen0.2:  at
> usbus0
> Sep 27 19:49:56 pf-bsd kernel: ums0 on uhub0
> Sep 27 19:49:56 pf-bsd kernel: ums0:  0/0, rev 1.10/33.52, addr 1> on usbus0
> Sep 27 19:49:56 pf-bsd kernel: ums0: 5 buttons and [XYZT] coordinates ID=1
> Sep 27 19:49:56 pf-bsd kernel: uhid0 on uhub0
> Sep 27 19:49:56 pf-bsd kernel: uhid0:  0/0, rev 1.10/33.52, addr 1> on usbus0
> Sep 27 19:49:56 pf-bsd kernel: ugen1.2:  at
> usbus1
> Sep 27 19:49:56 pf-bsd kernel: uhub2 on uhub1
> Sep 27 19:49:56 pf-bsd kernel: uhub2:  9/0, rev 2.00/0.04, addr 2> on usbus1
> Sep 27 19:49:56 pf-bsd kernel: ugen0.3:  at
> usbus0
> Sep 27 19:49:56 pf-bsd kernel: uhub3 on uhub0
> Sep 27 19:49:56 pf-bsd kernel: uhub3:  9/0, rev 2.00/85.37, addr 2> on usbus0
> Sep 27 19:49:56 pf-bsd kernel: uhub2: 8 ports with 8 removable, self
> powered
> Sep 27 19:49:57 pf-bsd kernel: uhub3: 3 ports with 0 removable, self
> powered
> Sep 27 19:49:57 pf-bsd kernel: ugen0.4:  at
> usbus0
> Sep 27 19:49:58 pf-bsd kernel: uhub4 on uhub3
> Sep 27 19:49:58 pf-bsd kernel: uhub4:  9/0, rev 1.10/1.10, addr 3> on usbus0
> Sep 27 19:49:58 pf-bsd kernel: uhub4: 4 ports with 3 removable, self
> powered
> Sep 27 19:49:59 pf-bsd kernel: ugen0.5:  at
> us

Re: Thinkpad T450: can't change display backlight

[Adrian Chadd]

Hi,

It needs the graphics driver work done. The backlight control is done by
the driver on these chips, via acpi but not entirely implemented within
acpi.

A
On Jul 5, 2016 10:13 AM, "Marin Bernard"  wrote:

>
>
> Hi,
>
> I just bought a Lenovo Thinkpad T450 laptop and installed FreeBSD on top
> of it. It runs fine except I'm not able to change the display backlight.
> The laptop embeds a Core i5-5300U CPU with an Intel Graphics 5500 adapter
> (Broadwell). I know the adapter is not yet supported, but I hoped to have
> backlight control working anyway!
>
> Backlight control is working fine with OpenBSD 5.9, Linux 4.1+ and
> Windows, which is not very surprising as those OSes also support the
> display adapter. It's not working on FreeBSD 10.3-RELEASE nor 11.0-ALPHA6.
>
> What I have tried:
>   - I tried to load acpi_ibm and acpi_video kernel modules and tweak the
> sysctl they provide: I was able to modify the systctl values, but backlight
> remained the same.
>   - I also tried to install graphics/intel-backlight. There again: I was
> able to change values, but it didn't change the backlight.
>   - I tried to load the i915kms intel modul, just in case backlight
> control needed this to work properly. As before, no effect. I think the
> module is just ignoring my adapter as it does not support it.
>
> I'm ready to cope with the VESA driver for some time but I'd really like
> to get backlight control working. Do you have suggestions ? Is there
> anything I can do to help ?
>
> I use the UEFI framebuffer with vt in graphics mode. I did not try to run
> Xorg yet. Should I do it ?
>
> Thanks,
>
> --Marin
>
>
> ___
> freebsd-acpi@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
>
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: high acpi_task load

[Adrian Chadd]

What's the value of sc->tz_zone.tsp ?


-a


On 21 April 2016 at 07:46, Johannes Dieterich  wrote:
> Dear all,
>
> I have for a long time observed a very high system load (seemingly
> erratic) on my Elitebook 745 G3. I am finally able to reproduce the
> behavior and would love input on how to solve it.
>
> If the laptop is attached to the docking station, acpi_task processes
> are eating up an entire core worth of CPU time, thereby disallowing
> the system to ever get to idle states with temperature and load issues
> associated.
>
> This is in so far reprodroducable as that locking it in at runtime
> causes these processes to appear on top -SH, disconnecting at runtime
> causes them to disappear.
>
> Inspecting a core dump generated during high load seems to point to
> ACPI's thermalzone:
>
> #5  0x803b0a97 in acpi_tz_cooling_thread (arg=)
> at /usr/src/sys/dev/acpica/acpi_thermal.c:1162
> #6  0x809ec8e4 in fork_exit (
> callout=0x803b0620 ,
> arg=0xf800055f9a00, frame=0xfe043f590a40)
>
> This is a timer: tsleep(&sc->tz_cooling_proc, PZERO, "cooling", hz *
> sc->tz_zone.tsp / 10);
>
>
> As I reported earlier, the thermal zones are very broken on this
> notebook. However, it surprises me that this would a) have such an
> impact and b) only when connected to a docking station.
>
> Any input/ideas are appreciated! Happy to test things.
>
> Johannes
> ___
> freebsd-acpi@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Blank screen on resume

[Adrian Chadd]

On 14 March 2016 at 13:22, Eric McCorkle  wrote:
> So no options at all until then? :(

If you want to figure out what minimal set you need from the
dri/i915kms code to restore backlight happiness, please do. :-P

But yeah. We'll need to wait for the next dri sync


-adrian

>
> On March 14, 2016 3:43:08 PM EDT, Adrian Chadd 
> wrote:
>>
>> Hiya,
>>
>> Yeah - the drm2 code needs to be involved in resuming, and right now
>> there's no broadwell support in i915kms.
>>
>> Once that gets updated then yeah, the resume backlight will work. :-P
>>
>>
>>
>> -a
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Blank screen on resume

[Adrian Chadd]

Hiya,

Yeah - the drm2 code needs to be involved in resuming, and right now
there's no broadwell support in i915kms.

Once that gets updated then yeah, the resume backlight will work. :-P



-a
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Blank screen on resume

[Adrian Chadd]

Hi,

Which laptop? Which chipset? etc.



-adrian
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Toshiba L675D wifi rfkill acpi support

[Adrian Chadd]

You'll have to figure out what the deal is, or disable it in the driver.

The rfkill switch is either hardware or software. Yours is hardware,
so I'm guessing it's one of the GPIO lines on the PCIE bus. I don't
know how the intel driver figures out which GPIO line is rfkill and
pays attention to it; search for that error string in the if_iwn.c
driver. Chances are it's reading a register and disabling it in
software.


-a


On 30 January 2016 at 14:34, J.R. Oldroyd  wrote:
> I have just upgraded the wifi mini-PCIe adapters in some older model
> Toshiba laptops, specifically L305D and L675D models, to AR9280
> adapters.  This in order to be able to use the 5 GHz band.
>
> On the L305D, everything is working well.
>
> But on the L675D, the AR9280 radio remains off.  Switching the wifi
> adapter to an Intel 6200 actually reports:
> iwn0: radio is disabled by hardware switch
> They both probe and initialize normally in the dmesg and you can
> talk to them normally using ifconfig.  It is just the radio that
> remains off.
>
> Thing is, the L675D does not have a hardware rfkill switch.  It does
> have Fn+F8, however.
>
> I should note that two other wifi adapters, the original RTL8191SE
> and also an AR9285 do both work fine in the L675D.  They do not seem
> to see a phantom rfkill switch!  But, neither of these adapters
> support the 5 GHz band.
>
> Despite the RTL8191SE and AR9285 working, I figured that it would be
> useful to have Fn+F8 working so that I could check and toggle the
> radio state of the AT9280.  I therefore set about updating
> acpi_toshiba.c to support the TOS1900 HID [1].
>
> I am still no closer, though.  I was not able to enable the hotkey
> Fn+Fx support, so I've implemented a hw.acpi.toshiba.wireless_wifi
> sysctl which shows that the wifi is enabled and allows it to be
> toggled.  Testing with one of the working adapters (AR9285) does show
> the wifi LED going on and off and the interface does pass or not-pass
> traffic accordingly.  But, with the AR9280, the LED and the radio
> remain steadfastly off.
>
> I have studied the acpidump[2] and found that the relevant ACPI method
> (TOI0==0xFF00 TOI1==0x56) supports four devices:
> 0x0200  wifi
> 0x0800  unknown
> 0x2000  wwan (3G device, according to google)
> 0x  unknown
>
> I have played with all of them, but still cannot get the AR9280 radio
> or the wifi LED on.
>
> I have not found any documentation, other than the Linux driver
> toshiba_acpi.c which provides no further help.
>
> Anyone have any thoughts about what is needed to enable the AR9280 (or
> Intel 6200) in the Toshiba L675D?
>
> Thanks,
> -jr
>
> [1] http://opal.com/jr/toshiba_l675d/acpi_toshiba.c
> [2] http://opal.com/jr/toshiba_l675d/toshiba_l675d.asl
> ___
> freebsd-wirel...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Get information about batteries

[Adrian Chadd]

acpiconf -i0 and acpiconf -i1? does that work?


-a


On 9 December 2015 at 10:17,   wrote:
> Hi!
>
> On a FreeBSD machine, I can get information about the AC-adapter or battery
> with
>
> sysctl hw.acpi.battery
>
> I can get how many of them installed in that machne (hw.acpi.battery.units).
> But if I have 2 of them, how can I get the information about them?
>
> Eg, the battery life or the time - but not accumulated, but separately.
>
> Thank,
>
> Gabor < Gabor at Zahemszky dot HU >
> ___
> freebsd-acpi@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: acpi suspend debugging techniques?

[Adrian Chadd]

oioo, would you please put that radeon patch into a review?

I have an older machine with a radeon card in it that doesn't yet
suspend/resume; I can now test it out!


-a


On 3 September 2015 at 10:50, Andriy Gapon  wrote:
> On 31/08/2015 11:53, Adrian Chadd wrote:
>> Try disabling hardware one at a time. Ie, unload usb; unload wifi;
>> leave kms loaded for mostly obvious reasons.
>
> Adrian, Garrett,
>
> thank you very much for your tips.
> Turned out that it was radeonkms that was causing the problem :-)
>
> BTW, here is another tool for the toolkit: on sufficiently recent system 
> devctl
> suspend and devctl resume can be used to test individual drivers.
>
> So, I noticed that I could suspend/resume drmn0 device just fine but with
> vgapci0 I had a trouble suspending.  One thing led to another and here is a
> patch that seems to fix the problem for me:
> ---
> commit fecb5e8a90631f06600d87165cc8b6de3e035dfc
> Author: Andriy Gapon 
> Date:   Thu Sep 3 17:24:23 2015 +0300
>
> radeon_suspend_kms: don't mess with pci state that's managed by the bus
>
> The pci bus driver handles the power state and configuration state saving
> and restoring for its child devices.
>
> diff --git a/sys/dev/drm2/radeon/radeon_device.c
> b/sys/dev/drm2/radeon/radeon_device.c
> index e5c676b11ed47..73b2f4c51ada2 100644
> --- a/sys/dev/drm2/radeon/radeon_device.c
> +++ b/sys/dev/drm2/radeon/radeon_device.c
> @@ -1342,14 +1342,10 @@ int radeon_suspend_kms(struct drm_device *dev)
>
> radeon_agp_suspend(rdev);
>
> -   pci_save_state(device_get_parent(dev->dev));
>  #ifdef FREEBSD_WIP
> if (state.event == PM_EVENT_SUSPEND) {
> /* Shut down the device */
> pci_disable_device(dev->pdev);
> -#endif /* FREEBSD_WIP */
> -   pci_set_powerstate(dev->dev, PCI_POWERSTATE_D3);
> -#ifdef FREEBSD_WIP
> }
> console_lock();
>  #endif /* FREEBSD_WIP */
> @@ -1380,10 +1376,6 @@ int radeon_resume_kms(struct drm_device *dev)
>
>  #ifdef FREEBSD_WIP
> console_lock();
> -#endif /* FREEBSD_WIP */
> -   pci_set_powerstate(device_get_parent(dev->dev), PCI_POWERSTATE_D0);
> -   pci_restore_state(device_get_parent(dev->dev));
> -#ifdef FREEBSD_WIP
> if (pci_enable_device(dev->pdev)) {
> console_unlock();
> return -1;
> ---
>
> However, I am not sure about an exact mechanism of the hard system hang that I
> experienced without the patch.
>
> BTW, I noticed that only very few drivers make explicit calls to
> pci_set_powerstate and pci_save_state/pci_restore_state.
> sys/dev/usb/controller/ohci_pci.c looks like a good use of pci_set_powerstate.
> sys/dev/ixgbe/if_ix.c looks like an incorrect / redundant use of the 
> functions.
>
> --
> Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: acpi suspend debugging techniques?

[Adrian Chadd]

hi,

Try disabling hardware one at a time. Ie, unload usb; unload wifi;
leave kms loaded for mostly obvious reasons.

I hit a few of these which turned out to be an issue in the suspend
path of a driver - and once I found it was the USB hardware but the
BIOS itself that was hanging - FreeBSD put USB hardware into S3, but
the ACPI BIOS requested S2 and just hung if we had USB in S3. :(



-adrian


On 30 August 2015 at 23:33, Garrett Cooper  wrote:
>
>> On Aug 30, 2015, at 23:13, Andriy Gapon  wrote:
>>
>>
>> I would appreciate any pointers at how to debug an ACPI suspend problem that 
>> I have.
>>
>> What I have so far.  The system hangs when I try to suspend it and it gets 
>> reset
>> by a watchdog.  Setting debug.acpi.suspend_bounce=1 does not make any
>> difference, so the hang happens before the final sleep code is executed.  I
>> think that the device suspend stage is executed, because disks get spun down 
>> and
>> video signals gets cut off.
>>
>> I could enable / add some debug printfs, but I suppose that their output 
>> would
>> get lost due to the above.  RAM content unfortunately does not survive across
>> the resets.
>
> When I last had to do this to figure out what magic formula was required to 
> get my netbook working, I did something like this:
>
> 1. Stripped down the kernel to just the storage driver and core pieces.
> 2. Loaded all other modules after boot, if necessary.
> 3. Called zzz with the appropriate ACPI tunables/sysctls set.
>
> That got me pointed in the right direction (IIRC it was psm at the time). 
> What I did to get a real smoking gun was I put printf statements in 
> subr_bus.c (IIRC) to track device quiescing at suspend and reawakening at 
> resume.
>
> There’s `options BUS_DEBUG` too, which may or may not help.
>
> FWIW I found debug.acpi.suspend_bounce less useful, but it still exercised 
> the quiesce->reawaken cycle, sorta.
>
> There’s also `hw.acpi.reset_video` and `debug.acpi.resume_beep`.
>
> You might need to hack /etc/rc.resume and /etc/rc.suspend, BTW, depending on 
> what you discover (switching my vty was definitely required in order for X11 
> to come back in a sane manner at resume).
>
> Cheers,
> -NGie
> ___
> freebsd-curr...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Attempting to diagnose suspend/resume issue

[Adrian Chadd]

Hi,

can you post some more debugging showing that the VGA driver is
restoring the VGA state before the power is applied?

Thanks!


-a


On 9 July 2015 at 21:34, Eric McCorkle  wrote:
> A long while ago, I reported my screen not coming back on after resume,
> shortly after r274386 went in.  Unfortunately, the follow-on patch
> didn't seem to work for me.
>
> (r274386 changed the way devices get powered down/up, and r274397 fixed
> a typo in r274386 that tried to power down/up the wrong devices.)
>
> I finally found the time to try and track this thing down, and I got
> some information that might prove useful in tracking it down.
>
>
> * The screen comes back up only for syscons in pixel mode up to r274835.
>  As far as I can tell, it doesn't work for vt in any revision (not as
> sure about text-mode syscons, but there is at least one revision where
> it works for pixel mode, but not text mode)
>
> * Comparing logs from r274385 and r274397, it seems the likely cause is
> that the changes in r274386 reordered things so that the VGA driver
> attempts to restore the state of the card before its power has been
> turned back on (you can clearly see this happening, and you can see the
> attempt to restore the state failing).
>
> * Suspend/resume works fine in Linux (I'm not sure how to get linux to
> printout a debug trace similar to debug.bootverbose), so the hardware
> can't be /that/ broken.
>
> * The order in which things happen during resume seems to be different
> between vt and syscons resumes, though I can't tell where vt restores
> the state of the card (or the efifb device)
>
> My guess as to the likely cause is that vt also tries to restore the
> state of the card before its power has been turned back on similar to
> what syscons does after r274386, or else the dual happens during suspend
> (it tries to save the state after the device is powered down).  It does
> seem a little wierd that syscons would behave differently in that
> respect for pixel mode vs text mode, though.
>
> I'm open to suggestions as to what to look at next, or theories as to
> what might be the culprit.  I also have dmesg logs for the various
> revisions and drivers.
>
> Best,
> Eric
>
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Laptop Battery drains insanely Fast!

[Adrian Chadd]

Hi,

TEMP is fine - pcm.x TEMP isn't in degrees. It's something CPU specific.

You're now at like, 9W laptop consumption and the core/package spends
most of its time in C7. About the only other thing I'd suggest is
lowering the backlight. But 9W is pretty good right now. Your battery
should be lasting the 4 hours it says it is. :)



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Fwd: Activating Suspend/Resume on FreeBSD 10.1

[Adrian Chadd]

Hi,

Please try a freebsd-head snapshot and see if that resolves your issue.

The fixes may not have been backported.

Thanks!

-a


On 29 January 2015 at 07:07, Anthony Jenkins  wrote:
> On 01/29/2015 08:42 AM, Mohammad Najafi wrote:
>> Dear Members:
>>
>> "acpiconf -s 3" results in kernel panic.
>>
>> For more info, I have attached my FreeBSD kernel boot message
>
> I don't see anything in the boot messages about a panic...
>
> Some suggestions:
>
>  - You can try to capture a kernel dump.  See
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#kerneldebug-obtain
>  - Try the hints in DebuggingSuspendResume on the FreeBSD wiki.  See
> https://wiki.freebsd.org/SuspendResume and
> https://wiki.freebsd.org/DebuggingSuspendResume
>  - Try running FreeBSD-CURRENT.  You can boot it off a USB flash drive
> and try suspend/resume.
>
> Also read the FreeBSD ACPI stuff at
> https://www.freebsd.org/doc/handbook/acpi-overview.html .
>
> Anthony Jenkins
>
>> Any help is highly welcome.
>>
>> Thanks in advance.
>> M.Najafi
>>
>>
>> ___
>> freebsd-acpi@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
>
> ___
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Lenovo T520: Present (-STABLE) vs. Future (-CURRENT) ACPI Support

[Adrian Chadd]

hm, someone just needs to do the MFC. I don't have stable/10 on any
laptop, so I'd be doing it blind.

Would someone with stable/10 please MFC 270516 from HEAD? Pretty please?


-a


On 18 January 2015 at 15:28, Bigby James  wrote:
> So as part of setting up a Poudriere build server I decided to run a 
> buildworld
> on my machines and, as per John Baldwin's request, I merged r270516 from HEAD
> with r277351 from STABLE. I can confirm Kevin Oberman's findings---things are
> working fine so far.  I got to learn a thing or two about FreeBSD development
> and some of the basics of using Subversion. Thanks a lot for the pointers,
> folks. So what are the chances of getting this merged into STABLE so myself 
> and
> others don't have to MFC every update?
>
> --
> "A common mistake that people make when trying to design something completely
> foolproof is to underestimate the ingenuity of complete fools." - Douglas 
> Adams
>
> ___
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: [Bug 162859] [acpi] ACPI battery/acline monitoring partialy working (switching)

[Adrian Chadd]

Hm, +jkim. Any ideas?


On 7 January 2015 at 10:23, Juris Kaminskis  wrote:
> 2015-01-05 17:27 GMT+02:00 Juris Kaminskis :
>
>>
>> 2015-01-04 15:17 GMT+02:00 Ian Smith :
>> >
>> > On Sat, 3 Jan 2015 11:45:05 +, bugzilla-nore...@freebsd.org wrote:
>> >
>> > Please excuse this off-'zilla merely speculative response.  No time, but
>> > I've spent (wasted?) some time chasing a couple of these outside the PR.
>> >
>> >  > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=162859
>> >  >
>> >  > --- Comment #14 from juris  ---
>> >  > Problem on /head/ branch is introduced with revision 216942.
>> >
>> > If true (in all cases) this is great news for those with a variety of HP
>> > laptops that have been experiencing partial - or in some cases complete
>> > after boot - failures in CMBAT monitoring since 9.0.  And a Macbook Pro.
>> >
>> > So, reverting rev 216942 fixes it for you?  On what FreeBSD version?
>>
>> I have compiled head branch revision 216941 and battery status via
>> acpiconf works. When compiling from source revision 216942 acpiconf stops
>> responding. I also tried to remove r216942 and compiled from source release
>> 9.3, but there battery status was not working. Apparently there are more
>> things than just one that breaks HP ACPI .
>>
>
> Sorry for my previous email that was confusing. I did not revert r216941
> when compiled release 9.3. So when I did that, battery status works. I also
> compiled release 10.1 with excluding r216942, and battery status works. So
> this single change for some reason creates problem for HP laptops.
>
>> >
>> >
>> > If so, with scant comprehension of the code, questions that occur:
>> >
>> > a) did that revision fix some existing problem, the reverting of which
>> > might reestablish problem/s in other machines?  jkim?
>> >
>> > b) what is it in various HP ACPI implementations that don't seem to be a
>> > reported problem on other hardware, particularly concerning EC handling?
>> >
>> > c) if this was wrong (for HPs), what would be right?  (the hard one :)
>> >
>> > cheers, Ian
>>
>>  On Sat, 3 Jan 2015 11:45:05 +, bugzilla-nore...@freebsd.org wrote:
>>
>> Please excuse this off-'zilla merely speculative response.  No time, but
>> I've spent (wasted?) some time chasing a couple of these outside the PR.
>>
>>  > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=162859
>>  >
>>  > --- Comment #14 from juris  ---
>>  > Problem on /head/ branch is introduced with revision 216942.
>>
>> If true (in all cases) this is great news for those with a variety of HP
>> laptops that have been experiencing partial - or in some cases complete
>> after boot - failures in CMBAT monitoring since 9.0.  And a Macbook Pro.
>>
>> So, reverting rev 216942 fixes it for you?  On what FreeBSD version?
>>
>> If so, with scant comprehension of the code, questions that occur:
>>
>> a) did that revision fix some existing problem, the reverting of which
>> might reestablish problem/s in other machines?  jkim?
>>
>> b) what is it in various HP ACPI implementations that don't seem to be a
>> reported problem on other hardware, particularly concerning EC handling?
>>
>> c) if this was wrong (for HPs), what would be right?  (the hard one :)
>>
>> cheers, Ian
>>
> ___
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Lenovo T520: Present (-STABLE) vs. Future (-CURRENT) ACPI Support

[Adrian Chadd]

Hi!

On 26 December 2014 at 08:57, Bigby James  wrote:
> Howdy-ha, folks,
>
> Please forgive my ignorance if my question is rather mundane and/or inane. I'm
> pretty new to FreeBSD and its development cycle. Here's my situation: I've
> recently  migrated my laptop (Levovo Thinkpad T520) to FreeBSD using the
> 10.1-STABLE snapshot, and most everything works pretty well. The only
> exceptions are some of the hardware keys, including the LCD brightness control
> keys, which is something I'd really like to have.
>
> Before going ahead with that install, though, on a lark I decided to try out 
> the
> 11-CURRENT snapshot to see how it worked out. As it turns out, everything
> presently missing from 10-STABLE worked out of the box on -CURRENT. So I know
> that full support for my machine is in the source tree now and, barring any
> fundamental changes in the development branch, will be in the next -RELEASE. I
> don't really have the time, know-how or guts to maintain a -CURRENT install on
> this machine, so for the time being I'm sticking with 10-STABLE. So I'm
> wondering just how often ACPI functionality gets moved from the -CURRENT 
> branch
> into the most recent release's -STABLE branch. In other words, what are the
> chances that the features I'm waiting for will get moved into the 10-STABLE
> branch in the near future? Are the ACPI devs pretty conservative with this? 
> For
> the time being I can control screen brightness using xrandr, and as fond as I 
> am
> with the convenience it is just a convenince all the same, so I can always
> remain patient. But I'm wondering if there's a way to know if and when ACPI
> functionality will get backported to -STABLE.  I currently follow this list 
> and
> the SVN mailing list for 10-STABLE, so I can also just keep an eye on them if
> that's the answer.  Thanks in advance.

Thanks for asking!

developers backport to freebsd-stable (and earlier branches) whenever
they have a need or desire. There's no hard and fast policy requiring
it as we're all volunteers and there's noone being paid to maintain or
develop laptop / tablet support for FreeBSD.

In my particular case I run FreeBSD-HEAD on almost everything, and
thus I don't backport things. I have enough limits on my time right
now and trying to backport and test everything would be very time
consuming.

Other developers are different - some will run stable/10 (or
stable/9!) and will end up backporting things that they need for
whichever hardware they're using.

But outside of a handful of strange situations, FreeBSD-HEAD has been
remarkably wonderful to use as a desktop for the last 18 months.


-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ENXIOing non-present battery

[Adrian Chadd]

Just remember, batteries can come and go, so we can't just ignore a
battery because the status says "not present."

So I think it's a bug in hald.


-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ENXIOing non-present battery

[Adrian Chadd]

What's the output of acpiconf -i0 and acpiconf -i1?

I wonder if changing 'state' to something else would keep everything happy.



-adrian


On 8 December 2014 at 15:08, Colin Percival  wrote:
> On 12/07/14 08:03, Adrian Chadd wrote:
>> How's this work on other systems? KDE on Linux doesn't lose its mind
>> if the second battery is totally flat.
>
> I just booted Ubuntu 14.04, and both "batteries" appear in /proc/acpi/battery;
> but BAT1 just shows "present: no" without any statistics, and the GUI shows
> the correct state for the single present battery.
>
> --
> Colin Percival
> Security Officer Emeritus, FreeBSD | The power to serve
> Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ENXIOing non-present battery

[Adrian Chadd]

Hi,

Wait - so it reports a battery with 0% in it, but not that it's not present?

How's this work on other systems? KDE on Linux doesn't lose its mind
if the second battery is totally flat.



-adrian


On 6 December 2014 at 23:53, Colin Percival  wrote:
> Hi ACPI people,
>
> On my Dell Latitude E7440 laptop, the ACPI reports two batteries: First
> the battery which exists; and second, a "Not Present" battery with zeroed
> statistics.  FreeBSD, not realizing that this second battery is a complete
> myth -- the E7440 only has one battery, and there is nowhere to add another
> -- faithfully reports the data from ACPI to userland.
>
> Unfortunately it causes some problems there; in particular, KDE interprets
> it as meaning that the system should have two batteries, and when it sees
> that the "second" battery has 0% power remaining it kicks off the "battery
> is low, turn the laptop off" code.  If that code is disabled, it still
> displays the wrong battery-charge-remaining status icons.
>
> For dealing with such broken ACPIs, it seems like not attaching a non-present
> battery would be a good idea.  This shouldn't be the default behaviour, since
> there are plenty of systems where a non-present battery might be inserted at
> a later time; but I see nothing wrong with adding an option.
>
> The attached patch adds a acpi.cmbat.hide_not_present loader tunable which,
> as the name suggests, hides non-present batteries; this is done in the probe
> code by returning ENXIO if the tunable is set to a nonzero value and
> acpi_BatteryIsPresent returns zero.  With this patch and the tunable set my
> laptop behaves appropriately; and (aside from wasting a few bytes of memory)
> there should be no effect on systems where the tunable is not set.
>
> Any objections to me committing this?
>
> --
> Colin Percival
> Security Officer Emeritus, FreeBSD | The power to serve
> Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
>
> ___
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Fix issue with battery status update on HP Elitebook 8440p

[Adrian Chadd]

Hm, looks like they're what, $300 from Amazon?

If someone shouts me one I'll take a look at it. I've exceeded my
"buying stuff to make freebsd work better on" budget for a while. :(




-adrian

On 17 November 2014 12:17, Lars Engels  wrote:
> On Fri, Nov 14, 2014 at 07:40:05AM -0800, Adrian Chadd wrote:
>> Is there a cheaply available HP notebook that exhibits this?
>>
>> I don't have any HP hardware to test it out on, sorry :(
>
> Would an ssh connection be sufficient? Maybe I can get one for some
> days...
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Lenovo W540 blank screen on suspend/resume after update

[Adrian Chadd]

hi!

So this patch makes your video pop back up again after suspend?

Would you mind creating a new PR for this and putting the patch in it?

That way we can track what we eventually need to MFC to stable/10.

Thanks!


-adrian


On 17 November 2014 10:21, Chagin Dmitry  wrote:
> On Fri, Nov 14, 2014 at 03:33:26PM -0500, Eric McCorkle wrote:
>> Sorry, don't remember the working version.
>>
>> I have acpi_video compiled in to my kernel. I've tried it with both vt and 
>> sc and gotten the same result.
>>
>> Might try to do more diagnostics this weekend.
>>
>> On November 14, 2014 11:18:57 AM EST, Chagin Dmitry  
>> wrote:
>> >On Thu, Nov 13, 2014 at 02:13:35PM -0800, Adrian Chadd wrote:
>> >> Hi,
>> >>
>> >> Does it stay blank if you have acpi_video (+ vt) loaded?
>> >>
>> >> What was the revision of 11 you were previously running?
>> >>
>> >>
>> >>
>> >> -adrian
>> >>
>> >>
>> >> On 13 November 2014 14:10, Eric McCorkle 
>> >wrote:
>> >> > Hello,
>> >> >
>> >> > I updated my kernel and userland with a fresh update from 11
>> >yesterday, and
>> >> > I'm now seeing a blank screen after suspend/resume, where it was
>> >working
>> >> > fine previously.
>> >> >
>> >> > I had been trying out the new vt console, so I switched back to sc,
>> >but the
>> >> > blank screen is still there.
>> >> >
>> >> > Sorry, I don't have any information beyond this (quite busy these
>> >days).
>> >> >
>> >> > Eric
>> >
>> >
>> >Lenovo t540, same here. r274463 + sc. resume worked two weeks ago.
>> >
>> >
>> >--
>> >Have fun!
>> >chd
>>
>
> try attached patch. it seems we should take a close look to other
> PCIB_POWER_FOR_SLEEP() calls.
>
> --
> Have fun!
> chd
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Lenovo W540 blank screen on suspend/resume after update

[Adrian Chadd]

What about one or the other one?

It sounds like this may have hidden up some other issues in what / how
we're powering things down.



-adrian


On 15 November 2014 02:05, Chagin Dmitry  wrote:
> On Fri, Nov 14, 2014 at 03:40:21PM -0800, Adrian Chadd wrote:
>> Hi,
>>
>> Thanks. Please do. start by reverting the patches from me and jkim;
>> see if it changes the behaviour.
>>
>> Thanks,
>>
>>
>> -adrian
>>
>>
>> On 14 November 2014 12:33, Eric McCorkle  wrote:
>> > Sorry, don't remember the working version.
>> >
>> > I have acpi_video compiled in to my kernel. I've tried it with both vt and
>> > sc and gotten the same result.
>> >
>> > Might try to do more diagnostics this weekend.
>> >
>> > On November 14, 2014 11:18:57 AM EST, Chagin Dmitry 
>> > wrote:
>> >>
>> >> On Thu, Nov 13, 2014 at 02:13:35PM -0800, Adrian Chadd wrote:
>> >>>
>> >>>  Hi,
>> >>>
>> >>>  Does it stay blank if you have acpi_video (+ vt) loaded?
>> >>>
>> >>>  What was the revision of 11 you were previously running?
>> >>>
>> >>>
>> >>>
>> >>>  -adrian
>> >>>
>> >>>
>> >>>  On 13 November 2014 14:10, Eric McCorkle  wrote:
>> >>>>
>> >>>>  Hello,
>> >>>>
>> >>>>  I updated my kernel and userland with a fresh update from 11 yesterday,
>> >>>> and
>> >>>>  I'm now seeing a blank screen after suspend/resume, where it was
>> >>>> working
>> >>>>  fine previously.
>> >>>>
>> >>>>  I had been trying out the new vt console, so I switched back to sc, but
>> >>>> the
>> >>>>  blank screen is still there.
>> >>>>
>> >>>>  Sorry, I don't have any information beyond this (quite busy
>> >>>> these days).
>> >>>>
>> >>>>  Eric
>> >>
>> >>
>> >>
>> >> Lenovo t540, same here. r274463 + sc. resume worked two weeks ago.
>> >>
>> >
>
>
> reverting both r274386 & r274397 and resume back to normal.
>
>
> tt
> Have fun!
> chd
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Lenovo W540 blank screen on suspend/resume after update

[Adrian Chadd]

Hi,

Thanks. Please do. start by reverting the patches from me and jkim;
see if it changes the behaviour.

Thanks,


-adrian


On 14 November 2014 12:33, Eric McCorkle  wrote:
> Sorry, don't remember the working version.
>
> I have acpi_video compiled in to my kernel. I've tried it with both vt and
> sc and gotten the same result.
>
> Might try to do more diagnostics this weekend.
>
> On November 14, 2014 11:18:57 AM EST, Chagin Dmitry 
> wrote:
>>
>> On Thu, Nov 13, 2014 at 02:13:35PM -0800, Adrian Chadd wrote:
>>>
>>>  Hi,
>>>
>>>  Does it stay blank if you have acpi_video (+ vt) loaded?
>>>
>>>  What was the revision of 11 you were previously running?
>>>
>>>
>>>
>>>  -adrian
>>>
>>>
>>>  On 13 November 2014 14:10, Eric McCorkle  wrote:
>>>>
>>>>  Hello,
>>>>
>>>>  I updated my kernel and userland with a fresh update from 11 yesterday,
>>>> and
>>>>  I'm now seeing a blank screen after suspend/resume, where it was
>>>> working
>>>>  fine previously.
>>>>
>>>>  I had been trying out the new vt console, so I switched back to sc, but
>>>> the
>>>>  blank screen is still there.
>>>>
>>>>  Sorry, I don't have any information beyond this (quite busy
>>>> these days).
>>>>
>>>>  Eric
>>
>>
>>
>> Lenovo t540, same here. r274463 + sc. resume worked two weeks ago.
>>
>
> --
> Sent from my Blackphone with K-9 Mail. Please excuse my brevity.
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Fix issue with battery status update on HP Elitebook 8440p

[Adrian Chadd]

Is there a cheaply available HP notebook that exhibits this?

I don't have any HP hardware to test it out on, sorry :(



-adrian


On 14 November 2014 03:50, Lars Engels  wrote:
> On Thu, Nov 13, 2014 at 11:13:14AM -0800, Adrian Chadd wrote:
>> Hm.. Have you disabled anything in the bios?
>>
>> Are there any bios updates available for that laptop?
>>
>> Can you upload the full acpidump output somewhere?
>>
>
> AFAIK ACPI battery status support is broken on most (all?) HP notebooks.
> I've read some other people reporting this, too.
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Lenovo W540 blank screen on suspend/resume after update

[Adrian Chadd]

Hi,

Does it stay blank if you have acpi_video (+ vt) loaded?

What was the revision of 11 you were previously running?



-adrian


On 13 November 2014 14:10, Eric McCorkle  wrote:
> Hello,
>
> I updated my kernel and userland with a fresh update from 11 yesterday, and
> I'm now seeing a blank screen after suspend/resume, where it was working
> fine previously.
>
> I had been trying out the new vt console, so I switched back to sc, but the
> blank screen is still there.
>
> Sorry, I don't have any information beyond this (quite busy these days).
>
> Eric
> ___
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Fix issue with battery status update on HP Elitebook 8440p

[Adrian Chadd]

Hm.. Have you disabled anything in the bios?

Are there any bios updates available for that laptop?

Can you upload the full acpidump output somewhere?

Adrian
 On Nov 13, 2014 11:06 AM, "Juris Kaminskis" 
wrote:

> sorry for so many emails
>
> My battery status updates only after reboot, is there a way I can get the
> >>> fix for this?
> >>>
> >>> My system is 10.0-RELEASE-p11
> >>>
> >>
> >> i have compiled kernel with debug acpi and I get following messages
> every
> >> 10 seconds, how is it possible to understand those? my loader.conf has:
> >> debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" and
> >> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS"
> >>
> >> compiling my ASL as per Freebsd ACPI-debug manual, i get following
> compilation errors:
>
> $ iasl foo.asl
>
> Intel ACPI Component Architecture
> ASL Optimizing Compiler version 20130823-64
> Copyright (c) 2000 - 2013 Intel Corporation
>
> Compiler aborting due to parser-detected syntax error(s)
> foo.asl3703: If (CondRefOf (FPED))
> Error6126 -syntax error ^
>
> foo.asl   25675:
> Error6126 - syntax error and premature End-Of-File
>
> ASL Input: foo.asl - 25675 lines, 879034 bytes, 9572 keywords
>
> Compilation complete. 2 Errors, 0 Warnings, 0 Remarks, 0 Optimizations
>
> Details at line 3703:
> If (CondRefOf (FPED))
> {
> FPED ()
> }
>
> and searching on FPED give me following:
> External (FPED, MethodObj)// Warning: Unresolved Method, guessing 0
> argu
> ments (may be incorrect, see warning above)
>
> Can you help me if this is way forward to correct the ASL code here and
> recompile?
> thanks
> Juris
>
>
>
> > I also noticed below message appear on booting the system, how I can read
> > this information? Is there a way I can search for what it means and if
> this
> > highlights actual error?
> >
> > Nov 13 19:33:49  kernel: evmisc-0181 [578222] EvQueueNotifyRequest  :
> > Dispatching Notify on [BAT0] (Device) Value 0x80 (Device Speci
> > fic) Node 0xf80002abba40
> > Nov 13 19:33:49  kernel: evmisc-0181 [578804] EvQueueNotifyRequest  :
> > Dispatching Notify on [BAT0] (Device) Value 0x80 (Device Speci
> > fic) Node 0xf80002abba40
> >
> >
> ___
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
>
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: [Bug 194884] [acpi] Asus UX31E USB hangs during suspend, due to putting the USB controllers into D3 state

[Adrian Chadd]

Hi,

On 8 November 2014 09:25, Ian Smith  wrote:
> On Fri, 7 Nov 2014 19:08:58 +, bugzilla-nore...@freebsd.org wrote:
>
>  > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194884
>  >
>  > Adrian Chadd  changed:
>  >
>  >What|Removed |Added
>  > 
> 
>  >Assignee|freebsd-b...@freebsd.org|freebsd-acpi@FreeBSD.org
>
> Not loving bugzilla all that much.  I'm going to reply here, after
> reformatting from cut'n'paste; do what thou wilt if anything's useful.

:(

>  > The laptop won't suspend with the USB drivers (ehci, xhci) loaded.
>
> Won't suspend, or won't resume?

Won't suspend - it hangs before it powers everything off.

>  > Suspend bounce works fine - everything gets powered down fine, then
>  > comes back up.
>  >
>  > Unloading the USB drivers fixes the problem, but that's hiding the
>  > underlying causes - the trick is the transition of the USB ports into
>  > D3.
>
>  > The ACPI BIOS has this:
>  >
>  >Device (EHC1)
>  > {
>  > Name (_ADR, 0x001D)  // _ADR: Address
>  > OperationRegion (PWKE, PCI_Config, 0x62, 0x04)
>  > Field (PWKE, DWordAcc, NoLock, Preserve)
>  > {
>  > ,   1,
>  > PWUC,   8
>  > }
>  >
>  > Method (_PSW, 1, NotSerialized)  // _PSW: Power State Wake
>  > {
>  > If (Arg0)
>  > {
>  > Store (Ones, PWUC) /* \_SB_.PCI0.EHC1.PWUC */
>  > }
>  > Else
>  > {
>  > Store (0x00, PWUC) /* \_SB_.PCI0.EHC1.PWUC */
>  > }
>  > }
>  >
>  > Method (_S3D, 0, NotSerialized)  // _S3D: S3 Device State
>  > {
>  > Return (0x02)
>  > }
>  >
>  > Method (_S4D, 0, NotSerialized)  // _S4D: S4 Device State
>  > {
>  > Return (0x02)
>  > }
>  >
>  > .. so, we should be trying to put it into D2, not D3.
>
> I can't figure this.  Methods _S3D and _S4D aren't apparently referenced
> or called anywhere else?, and there's nothing similar (I could spot) for
> EHC2.  Are you assuming 0x02 here is the requested power state?  How?

It's apparently in the spec and we do check for it - grep for _S%dD in
sys/dev/acpica/ .

> If so, even if it wanted to leave some? power on during suspend, what
> good would that do in S4 (hibernate/STDisk) when the power is turned
> right off? - not that we support that, but W*s and maybe Linux do ..

I think it likely needs to be powered on during the transition to
S3/S4, but then for S4 you can just yank the power.
I doubt the USB controllers need to be on if the rest of th machine is
powered off.

>  > But then:
>  >
>  > ehci0 pnpinfo vendor=0x8086 device=0x1c26 subvendor=0x1043
>  > subdevice=0x1427 class=0x0c0320 at slot=29 function=0
>  > handle=\_SB_.PCI0.EHC1
>  >
>  > ehci0@pci0:0:29:0:   class=0x0c0320 card=0x14271043 chip=0x1c268086
>  > rev=0x05 hdr=0x00
>  > vendor = 'Intel Corporation'
>  > device = '6 Series/C200 Series Chipset Family USB Enhanced Host 
> Controller'
>  > class  = serial bus
>  > subclass   = USB
>  > cap 01[50] = powerspec 2  supports D0 D3  current D0
>  > cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14
>  > cap 13[98] = PCI Advanced Features: FLR TP
>  >
>  > .. we shouldn't be putting it into D2, because the device doesn't
>  > support it.
>
> Right.  Or at least, so we detect ..

Right, but we don't. If you check the .txt files, we are actually
probing the bus itself to find the _SxD node, when apparently this
ACPI table has it in the device.

ie:

acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=3
acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=3
acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=3
acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=3
acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=3
acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=3
acpi_device_pwr_for_sleep: \134_SB_.PCI0.RP01: dstate=3
acpi_device_pwr_for_sleep: \134_SB_.PCI0.RP01: now dstate=3
acpi_device_pwr_for_sleep: \134_SB_.PCI0: 

Re: Support for Lenovo acpi_video and nVidia GT740M Optimus video adaptor

[Adrian Chadd]

Hi,

A lot of the management of this stuff got offloaded to the
architecture specific stuff in DRI.

So, brightness controls likely require some plumbing from i915kms.

I think half of your problems will be solved with the haswell DRI
module. The Optimus side of things will require a little more
investigation.


-a


On 23 September 2014 03:16, O. Hartmann  wrote:
>
> I have a Lenovo ThinkPad E540 which has the following CPU:
>
>
> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
> VT: running with driver "efifb".
> info: [drm] Initialized drm 1.1.0 20060810
> CPU: Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz (2494.28-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x306c3  Family=0x6  Model=0x3c  Stepping=3
>   
> Features=0xbfebfbff
>   
> Features2=0x7fdafbbf,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
>   AMD Features=0x2c100800
>   AMD Features2=0x21
>   Structured Extended 
> Features=0x27ab
>   XSAVE Features=0x1
>   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> real memory  = 9636413440 (9190 MB)
> avail memory = 8149209088 (7771 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: 
> [...]
>
> This laptop has a integrated HD4600 iGPU (Haswell CPU) as well as a nVidia GT 
> 740M GPU,
> which is supposed to be with Optimus technology. I will refer to this issue 
> later in this
> post.
>
> ACPI_VIDEO/ACPI_IBM:
>
> loading both of these ACPI kernel modules seem not to provide any 
> fiunctionality as
> expected. The laptop runs with 100% brightness of the LCD and consumes the 
> battery very
> quickly. Trying
> #
> #   Display
> #
> hw.acpi.video.lcd0.fullpower=75
> hw.acpi.video.lcd1.fullpower=75
> hw.acpi.video.lcd0.econony=50
> hw.acpi.video.lcd1.econony=50
> hw.acpi.video.lcd0.brigthness=75
> hw.acpi.video.lcd1.brigthness=75
>
> in /etc/sysctl remains without effect. I presume this is due to the laptop is 
> neither
> supported by the acpi_ibm.ko nor acpi_video.ko modules either?
>
> Is there a way to manipulate the LCD brightnes? The Firmware Lenovo provides 
> doesn't
> allow without operating system running the change of the brightness or muting 
> the
> speakers with FN + FXX key, as it is provided by many other EFI/UEFI 
> firmwares.
>
>
> iGPU/GPU/Optimus:
>
>
> Another serious issue is the built-in video adaptor. In UEFI, I have the 
> opportunity of
> selecting either "integrated" or "nVidia Optimus". Selecting "integrated" is 
> supposed to
> utilize the built in iGPU HD4600 - which is since Haswell's dawn unsupported 
> in FreeBSD.
> So, for some reasons along with my work, I'd like to have the dedicated GPU 
> anyway, the
> nVidia GT 740M.
> And here is the culprit.
>
> First, I do not know whether this device is a hybrid or real discrete GPU 
> with the
> ability of sharing, what nVidia calls Optimus.
> Starting X11 with any of the nVidia provided BLOBs (xf86-video-nv doesn't 
> support modern
> GPUs like that and FreeBSD doesn't have, in contrary to many Linux 
> distributions, modern
> xf86-video-nouveau: the driver is simply extinct from the ports) with 340.24, 
> 340.32 and
> 343.13 gives a blank vt() console screen with a carrett in the uppermost 
> lefthand corner.
>
> Checking the the Xorg.log I realize, that the driver recognizes the existence 
> of the GPU,
> but it doesn't reveal any(!) display sockets, not even the built-in LCD. 
> Whenever the
> nvidia driver tries to access the video hardware, I see this messages popping 
> up on the
> console, indicating that there is something wrong, I presume:
>
> [...]
> Sep 21 09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: 
> Argument #4 type
> mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) 
> Sep 21
> 09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 
> type
> mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) 
> Sep 21
> 09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 
> type
> mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) 
> Sep 21
> 09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 
> type
> mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) 
> Sep 21
> 09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 
> type
> mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) 
> Sep 21
> 09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 
> type
> mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) 
> Sep 21
> 09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 
> type
> mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97) 
> Sep 21
> 09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 
> type
> mismatch - Found [Buffer], ACPI requ

Re: 答复: 答复: 答复: 答复: 答复: My laptop can't resume from suspend.

[Adrian Chadd]

What's the thing that needs porting?



-a
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: 答复: 答复: My laptop can't resume from suspend.

[Adrian Chadd]

Hm!

Cool, so you've reimplemented the RTC accesses to go via ACPI.

Shouldn't this be another device though? One that gets attached if it
finds it on the ACPI bus?


-a


On 25 August 2014 09:10, Anthony Jenkins  wrote:
> No problem... attached.  And amd64 doesn't matter - works for x86-based 
> computers with the basic CMOS RTC chip (PNP0B00).  Hopefully your 
> suspend/resume problems are due to your ACPI BIOS needing to read/write info 
> from/to CMOS and not finding a CMOS handler.
>
> Anthony
>
> On 08/25/2014 11:50, 张晓靖 wrote:
>> I google less than complete information. Do you have the relevant code can 
>> be shared under it? I found atrtc.c file in /usr/src/sys/x86/isa directory, 
>> but my system is amd64 of ..
>>
>> root@skycn:~ # uname -a
>> FreeBSD skycn 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #2: Sat Aug 16 
>> 00:06:30 CST 2014 root@skycn:/usr/obj/usr/src/sys/MyKernel  amd64
>>
>>
>> -邮件原件-
>> 发件人: Anthony Jenkins [mailto:anthony.b.jenk...@att.net]
>> 发送时间: 2014年8月16日 5:18
>> 收件人: 张晓靖; 'Kevin Oberman'
>> 抄送: freebsd-acpi@freebsd.org
>> 主题: Re: 答复: My laptop can't resume from suspend.
>>
>> On 08/15/2014 16:20, 张晓靖 wrote:
>>> Thank Bykov Vladislav and Kevin Oberman's recommendations. Later I
>>> received an e-mail,
>>>
>>> immediately compile the kernel (make a note #options VESA).But the
>>> problem persists, dmesg
>>>
>>> Information Reference url http://url.cn/SQ0vXD.
>>>
>>>
>>>
>>> Even worse thing is, I do use "acpiconf -s 3"debugger, resulting in a
>>> notebook can not boot
>>>
>>> until yesterday afternoon for a good notebook motherboard, now do not
>>> dare to use “acpiconf
>>>
>>> -s 3” testing.
>>>
>>>
>>>
>>> Do you have suggestions for me?
>> You could dig up my kernel patch (Google "FreeBSD ACPI CMOS region support 
>> atrtc.c.patch") to play with, it works to enable suspend/resume on some 
>> laptops and should be safe to try.  I still need to clean it up (style, 
>> other suggestions) for submission to FreeBSD, haven't gotten around to it 
>> yet.
>>
>> Anthony Jenkins
>>
>>> Thanks you~
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -邮件原件-
>>> 发件人: Bykov Vladislav [mailto:envol...@gmail.com]
>>> 发送时间: 2014年8月13日 0:13
>>> 收件人: 张晓靖
>>> 主题: Re: My laptop can't resume from suspend.
>>>
>>>
>>>
>>> On Tue, Aug 12, 2014 at 12:20:28PM +0800, 张晓靖 wrote:
>>>
 The laptop can't resume, the screen no display, no beep sound.
>>> Can you please try to install video driver for your card and remove VESA 
>>> device from kernel configuration?
>>>
>>>
>>>
>>>
>>>
>>> 发件人: kob6...@gmail.com [mailto:kob6...@gmail.com] 代表 Kevin Oberman
>>> 发送时间: 2014年8月13日 1:15
>>> 收件人: 张晓靖
>>> 抄送: freebsd-acpi@freebsd.org
>>> 主题: Re: My laptop can't resume from suspend.
>>>
>>>
>>>
>>> On Mon, Aug 11, 2014 at 9:20 PM, 张晓靖 >>  > wrote:
>>>
>>> Hello,
>>>
>>>I am having a problem.
>>>
>>>My laptop is lenovo's zhaoyang K47A series HM65.
>>>
>>>I used ati graphics CARDS, Use the url (
>>>  https://wiki.freebsd.org/Graphics)
>>> the method of normal driving the graphics card.
>>>
>>>
>>>
>>>   After set "
>>>
>>> sysctl debug. Bootverbose = 1
>>>
>>> sysctl debug. Acpi. Suspend_bounce = 1
>>>
>>> sysctl debug. Acpi. Resume_beep = 1
>>>
>>> acpiconf -s 3
>>>
>>> "
>>>
>>> The laptop can't resume, the screen no display, no beep sound.
>>>
>>>
>>>
>>> Disabling ACPI not helps to fix the problem. All files downloaded from
>>> http://url.cn/WVISGF.
>>>
>>>
>>>
>>> Output from sysctl hw.acpi
>>>
>>> hw.acpi.supported_sleep_state: S1 S3 S4 S5
>>>
>>> hw.acpi.power_button_state: S5
>>>
>>> hw.acpi.sleep_button_state: S1
>>>
>>> hw.acpi.lid_switch_state: NONE
>>>
>>> hw.acpi.standby_state: S1
>>>
>>> hw.acpi.suspend_state: S3
>>>
>>> hw.acpi.sleep_delay: 1
>>>
>>> hw.acpi.s4bios: 0
>>>
>>> hw.acpi.verbose: 1
>>>
>>> hw.acpi.disable_on_reboot: 0
>>>
>>> hw.acpi.handle_reboot: 0
>>>
>>> hw.acpi.reset_video: 0
>>>
>>> hw.acpi.cpu.cx_lowest: C1
>>>
>>> hw.acpi.acline: 1
>>>
>>> hw.acpi.battery.life: 100
>>>
>>> hw.acpi.battery.time: -1
>>>
>>> hw.acpi.battery.state: 0
>>>
>>> hw.acpi.battery.units: 2
>>>
>>> hw.acpi.battery.info_expire: 5
>>>
>>> hw.acpi.thermal.min_runtime: 0
>>>
>>> hw.acpi.thermal.polling_rate: 10
>>>
>>> hw.acpi.thermal.user_override: 0
>>>
>>> hw.acpi.thermal.tz0.temperature: 62.0C
>>>
>>> hw.acpi.thermal.tz0.active: -1
>>>
>>> hw.acpi.thermal.tz0.passive_cooling: 1
>>>
>>> hw.acpi.thermal.tz0.thermal_flags: 0
>>>
>>> hw.acpi.thermal.tz0._PSV: 95.0C
>>>
>>> hw.acpi.thermal.tz0._HOT: -1
>>>
>>> hw.acpi.thermal.tz0._CRT: 100.0C
>>>
>>> hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
>>>
>>> hw.acpi.thermal.tz0._TC1: 2
>>>
>>> hw.acpi.thermal.tz0._TC2: 3
>>>
>>> hw.acpi.thermal.tz0._TSP: 100
>>>
>>>
>>>
>>> Sincerely,
>>> ZhangXiaoJing.
>>>
>>>
>>>
>>> Have you tried building the kernel without VESA? Many laptops won't resume 
>>> if you leave VESA in the kernel build.
>>>
>>> --
>>>
>>>
>>> R. 

Re: 答复: My laptop can't resume from suspend.

[Adrian Chadd]

Please do tidy it up and submit it for review!



-a


On 15 August 2014 14:17, Anthony Jenkins  wrote:
> On 08/15/2014 16:20, 张晓靖 wrote:
>> Thank Bykov Vladislav and Kevin Oberman's recommendations. Later I received 
>> an e-mail,
>>
>> immediately compile the kernel (make a note #options VESA).But the problem 
>> persists, dmesg
>>
>> Information Reference url http://url.cn/SQ0vXD.
>>
>>
>>
>> Even worse thing is, I do use "acpiconf -s 3"debugger, resulting in a 
>> notebook can not boot
>>
>> until yesterday afternoon for a good notebook motherboard, now do not dare 
>> to use “acpiconf
>>
>> -s 3” testing.
>>
>>
>>
>> Do you have suggestions for me?
>
> You could dig up my kernel patch (Google "FreeBSD ACPI CMOS region support 
> atrtc.c.patch") to play with, it works to enable suspend/resume on some 
> laptops and should be safe to try.  I still need to clean it up (style, other 
> suggestions) for submission to FreeBSD, haven't gotten around to it yet.
>
> Anthony Jenkins
>
>> Thanks you~
>>
>>
>>
>>
>>
>>
>>
>> -邮件原件-
>> 发件人: Bykov Vladislav [mailto:envol...@gmail.com]
>> 发送时间: 2014年8月13日 0:13
>> 收件人: 张晓靖
>> 主题: Re: My laptop can't resume from suspend.
>>
>>
>>
>> On Tue, Aug 12, 2014 at 12:20:28PM +0800, 张晓靖 wrote:
>>
>>> The laptop can't resume, the screen no display, no beep sound.
>> Can you please try to install video driver for your card and remove VESA 
>> device from kernel configuration?
>>
>>
>>
>>
>>
>> 发件人: kob6...@gmail.com [mailto:kob6...@gmail.com] 代表 Kevin Oberman
>> 发送时间: 2014年8月13日 1:15
>> 收件人: 张晓靖
>> 抄送: freebsd-acpi@freebsd.org
>> 主题: Re: My laptop can't resume from suspend.
>>
>>
>>
>> On Mon, Aug 11, 2014 at 9:20 PM, 张晓靖 >  > wrote:
>>
>> Hello,
>>
>>I am having a problem.
>>
>>My laptop is lenovo's zhaoyang K47A series HM65.
>>
>>I used ati graphics CARDS, Use the url (
>>  https://wiki.freebsd.org/Graphics) the
>> method of normal driving the graphics card.
>>
>>
>>
>>   After set "
>>
>> sysctl debug. Bootverbose = 1
>>
>> sysctl debug. Acpi. Suspend_bounce = 1
>>
>> sysctl debug. Acpi. Resume_beep = 1
>>
>> acpiconf -s 3
>>
>> "
>>
>> The laptop can't resume, the screen no display, no beep sound.
>>
>>
>>
>> Disabling ACPI not helps to fix the problem. All files downloaded from
>> http://url.cn/WVISGF.
>>
>>
>>
>> Output from sysctl hw.acpi
>>
>> hw.acpi.supported_sleep_state: S1 S3 S4 S5
>>
>> hw.acpi.power_button_state: S5
>>
>> hw.acpi.sleep_button_state: S1
>>
>> hw.acpi.lid_switch_state: NONE
>>
>> hw.acpi.standby_state: S1
>>
>> hw.acpi.suspend_state: S3
>>
>> hw.acpi.sleep_delay: 1
>>
>> hw.acpi.s4bios: 0
>>
>> hw.acpi.verbose: 1
>>
>> hw.acpi.disable_on_reboot: 0
>>
>> hw.acpi.handle_reboot: 0
>>
>> hw.acpi.reset_video: 0
>>
>> hw.acpi.cpu.cx_lowest: C1
>>
>> hw.acpi.acline: 1
>>
>> hw.acpi.battery.life: 100
>>
>> hw.acpi.battery.time: -1
>>
>> hw.acpi.battery.state: 0
>>
>> hw.acpi.battery.units: 2
>>
>> hw.acpi.battery.info_expire: 5
>>
>> hw.acpi.thermal.min_runtime: 0
>>
>> hw.acpi.thermal.polling_rate: 10
>>
>> hw.acpi.thermal.user_override: 0
>>
>> hw.acpi.thermal.tz0.temperature: 62.0C
>>
>> hw.acpi.thermal.tz0.active: -1
>>
>> hw.acpi.thermal.tz0.passive_cooling: 1
>>
>> hw.acpi.thermal.tz0.thermal_flags: 0
>>
>> hw.acpi.thermal.tz0._PSV: 95.0C
>>
>> hw.acpi.thermal.tz0._HOT: -1
>>
>> hw.acpi.thermal.tz0._CRT: 100.0C
>>
>> hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
>>
>> hw.acpi.thermal.tz0._TC1: 2
>>
>> hw.acpi.thermal.tz0._TC2: 3
>>
>> hw.acpi.thermal.tz0._TSP: 100
>>
>>
>>
>> Sincerely,
>> ZhangXiaoJing.
>>
>>
>>
>> Have you tried building the kernel without VESA? Many laptops won't resume 
>> if you leave VESA in the kernel build.
>>
>> --
>>
>>
>> R. Kevin Oberman, Network Engineer, Retired
>> E-mail: rkober...@gmail.com 
>>
>> ___
>> freebsd-acpi@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
>
> ___
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Investigating failed suspend/resume T61

[Adrian Chadd]

That's odd. Is it still trying to resume hdac0 ?


-a


On 6 June 2014 03:57, Edward Tomasz Napierała  wrote:
> The difference in dmesg with (-) and without (+) the modem looks like this:
>
> --- dmesg.modem 2014-06-06 09:46:02.0 +0200
> +++ dmesg.bez   2014-06-06 09:52:45.0 +0200
> @@ -48,7 +48,7 @@ Event timer "HPET1" frequency 14318180 H
>  Event timer "HPET2" frequency 14318180 Hz quality 440
>  atrtc0:  port 0x70-0x71 irq 8 on acpi0
>  Event timer "RTC" frequency 32768 Hz quality 0
> -Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
> +Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
>  acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
>  acpi_lid0:  on acpi0
>  acpi_button0:  on acpi0
> @@ -157,12 +157,13 @@ est0:   coretemp1:  on cpu1
>  est1:  on cpu1
>  Timecounters tick every 1.000 msec
> +hdac0: Command timeout on address 1
> +hdac0: Command timeout on address 1
> +hdac0: CODEC is not responding!
>  hdacc0:  at cad 0 on hdac0
>  hdaa0:  at nid 1 on hdacc0
>  pcm0:  at nid 18,17 and 28,20,21 
> on hdaa0
>  pcm1:  at nid 27 on hdaa0
> -hdacc1:  at cad 1 on hdac0
> -unknown:  at nid 2 on 
> hdacc1 (no driver attached)
>  random: unblocking device.
>  usbus0: 12Mbps Full Speed USB v1.0
>  usbus1: 12Mbps Full Speed USB v1.0
>
> Note that with modem disabled, it's not suspend that fails - it's the
> resuming.
>
> On 0605T2152, Adrian Chadd wrote:
>> ok so when you disable the modem, does it still think there's a modem
>> there? Is it still trying to power the device off via ACPI even though
>> it's not probed?
>>
>>
>> -a
>>
>>
>> On 5 June 2014 10:50, Sean Bruno  wrote:
>> > On Wed, 2014-06-04 at 15:32 -0700, Adrian Chadd wrote:
>> >> Hi,
>> >>
>> >> Please also document why it is/isn't working. It's only documented as
>> >> "suspend/resume doesn't work" :)
>> >>
>> >>
>> >> -a
>> >
>> >
>> > Well there's this that trasz updated to indicate that it works:
>> > https://wiki.freebsd.org/SuspendResume
>> >
>> > I just updated this to indicate the same information:
>> > https://wiki.freebsd.org/Laptops/Thinkpad_T61
>> >
>> > sean
>> >
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: [PATCH] Naive implementation of AcpiExCmosSpaceHandler()

[Adrian Chadd]

ah! you're zetalog?


-a


On 6 June 2014 17:05, Jung-uk Kim  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2014-06-06 19:33:13 -0400, Adrian Chadd wrote:
>> Hi!
>>
>> Would you mind throwing this into a bugzilla report?
>>
>> https://bugs.freebsd.org/bugzilla/
>>
>> That way it won't get lost?
>>
>> Let me know what number it is and I'll chase it down and get it
>> into -HEAD.
> ...
> Actually, it is a patch for upstream to review.
>
> https://bugs.acpica.org
> https://lists.acpica.org/mailman/listinfo
> https://github.com/acpica/acpica
>
> Jung-uk Kim
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBAgAGBQJTkldRAAoJEHyflib82/FGnoEH/A2t0nFfkIHSEPICxvuQKucB
> D1sG3oQjn4tScyL7Izy4mhGLev7b0zw0u8g1GbAkva8lrr/NSUOgBS5aS/o+LMLE
> 6gddnOGlpq5BZCBsddpSpKqSIahQarzDHlqhd4mhF9dox+D4XsZ8IfiVIteEjXyc
> K/UscdtBHc2SKLRWpbBzm3eS2SRB0R6fRoUkPcZ1MW6y0Np95zUwsa/Ok8vemwyP
> /X5u33Q2OdTSwlhQBE7hR3iszEebpvS0+cBUKcM6PFV8RZLlZXMOxdkTyx6o+nxq
> 5rHsoCZWOn9/yLYxs0NetoLZrm00/nq2LcMTBAE1qJZWfXxKmZ1BSAp7SKZ8zes=
> =ZRDm
> -END PGP SIGNATURE-
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: [PATCH] Naive implementation of AcpiExCmosSpaceHandler()

[Adrian Chadd]

Hi!

Would you mind throwing this into a bugzilla report?

https://bugs.freebsd.org/bugzilla/

That way it won't get lost?

Let me know what number it is and I'll chase it down and get it into -HEAD.

Thanks!


-a


On 4 June 2014 05:53, Anthony Jenkins  wrote:
> Here's a naive implementation of AcpiExCmosSpaceHandler(), it simply uses I/O 
> ports 0x70 and 0x71 to read/write CMOS registers using 
> AcpiHwWritePort()/AcpiHwReadPort() calls.  I'm new(ish) to the ACPICA 
> subsystem and I'm probably not going about this the right way - I think I 
> should implement an actual CMOS RTC device which handles the three PNP IDs 
> that represent those hardware devices, but this was good enough for what I 
> was trying to do.
>
> This fixes my HP Envy 6z-1100 laptop's suspend/resume (except video fails to 
> resume, but I believe that's due to backlight handling from my research).  
> Before, initiating a suspend (zzz(8)) caused the laptop to seemingly suspend 
> and immediately resume.
>
> Now trying to track down the backlight issue. I implemented a missing _BQC 
> method which returns a single value from the _BCL listj; I think Linux does 
> some kind of vendor backlight control method if this method is missing.
>
> Suggestions welcome.
> Anthony Jenkins
>
> Index: sys/contrib/dev/acpica/components/events/evhandler.c
> ===
> --- sys/contrib/dev/acpica/components/events/evhandler.c(revision 266756)
> +++ sys/contrib/dev/acpica/components/events/evhandler.c(working copy)
> @@ -70,6 +70,7 @@
>  ACPI_ADR_SPACE_SYSTEM_MEMORY,
>  ACPI_ADR_SPACE_SYSTEM_IO,
>  ACPI_ADR_SPACE_PCI_CONFIG,
> +ACPI_ADR_SPACE_CMOS,
>  ACPI_ADR_SPACE_DATA_TABLE
>  };
>
> @@ -379,9 +380,12 @@
>   */
>  if ((Node->Type != ACPI_TYPE_DEVICE) &&
>  (Node->Type != ACPI_TYPE_PROCESSOR)  &&
> +(Node->Type != ACPI_TYPE_REGION) &&
>  (Node->Type != ACPI_TYPE_THERMAL)&&
>  (Node != AcpiGbl_RootNode))
>  {
> +ACPI_DEBUG_PRINT ((ACPI_DB_OPREGION,
> +"Device %p not a DEVICE, PROCESSOR, REGION, THERMAL type or root 
> node.\n", Node));
>  Status = AE_BAD_PARAMETER;
>  goto UnlockAndExit;
>  }
> Index: sys/contrib/dev/acpica/components/executer/exregion.c
> ===
> --- sys/contrib/dev/acpica/components/executer/exregion.c(revision 266756)
> +++ sys/contrib/dev/acpica/components/executer/exregion.c(working copy)
> @@ -449,7 +449,21 @@
>  return_ACPI_STATUS (Status);
>  }
>
> +static UINT8 AcpiExCmosRead(ACPI_PHYSICAL_ADDRESS Address)
> +{
> +UINT32 Value32;
>
> +AcpiHwWritePort((ACPI_IO_ADDRESS) 0x70, (UINT32) Address, 8);
> +AcpiHwReadPort ((ACPI_IO_ADDRESS) 0x71, &Value32, 8);
> +return Value32 & 0xFF;
> +}
> +
> +static void AcpiExCmosWrite(ACPI_PHYSICAL_ADDRESS Address, UINT8 Value)
> +{
> +AcpiHwWritePort((ACPI_IO_ADDRESS) 0x70, (UINT32) Address, 8);
> +AcpiHwWritePort((ACPI_IO_ADDRESS) 0x71, (UINT32) Value, 8);
> +}
> +
>  
> /***
>   *
>   * FUNCTION:AcpiExCmosSpaceHandler
> @@ -473,7 +487,7 @@
>  UINT32  Function,
>  ACPI_PHYSICAL_ADDRESS   Address,
>  UINT32  BitWidth,
> -UINT64  *Value,
> +UINT64  *Value64,
>  void*HandlerContext,
>  void*RegionContext)
>  {
> @@ -482,7 +496,23 @@
>
>  ACPI_FUNCTION_TRACE (ExCmosSpaceHandler);
>
> +if (Address < 0x80 &&
> +(Function == ACPI_READ || Function == ACPI_WRITE) &&
> +BitWidth <= 64)
> +{
> +UINT32 i;
> +UINT8 *Value = (UINT8 *)Value64;
>
> +for (i = 0; i < (BitWidth + 7) / 8; ++i, ++Address, ++Value) {
> +if (Function == ACPI_READ) {
> +*Value = AcpiExCmosRead(Address);
> +} else {
> +AcpiExCmosWrite(Address, *Value);
> +}
> +}
> +} else {
> +Status = AE_BAD_PARAMETER;
> +}
>  return_ACPI_STATUS (Status);
>  }
>
> Index: sys/contrib/dev/acpica/include/acconfig.h
> ===
> --- sys/contrib/dev/acpica/include/acconfig.h(revision 266756)
> +++ sys/contrib/dev/acpica/include/acconfig.h(working copy)
> @@ -194,7 +194,7 @@
>  /* Maximum SpaceIds for Operation Regions */
>
>  #define ACPI_MAX_ADDRESS_SPACE  255
> -#define ACPI_NUM_DEFAULT_SPACES 4
> +#define ACPI_NUM_DEFAULT_SPACES 5
>
>  /* Array sizes. Used for range checking also */
>
>
>
> ___
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
_

Re: Investigating failed suspend/resume T61

[Adrian Chadd]

ok so when you disable the modem, does it still think there's a modem
there? Is it still trying to power the device off via ACPI even though
it's not probed?


-a


On 5 June 2014 10:50, Sean Bruno  wrote:
> On Wed, 2014-06-04 at 15:32 -0700, Adrian Chadd wrote:
>> Hi,
>>
>> Please also document why it is/isn't working. It's only documented as
>> "suspend/resume doesn't work" :)
>>
>>
>> -a
>
>
> Well there's this that trasz updated to indicate that it works:
> https://wiki.freebsd.org/SuspendResume
>
> I just updated this to indicate the same information:
> https://wiki.freebsd.org/Laptops/Thinkpad_T61
>
> sean
>
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Investigating failed suspend/resume T61

[Adrian Chadd]

Hi,

Please also document why it is/isn't working. It's only documented as
"suspend/resume doesn't work" :)


-a


On 4 June 2014 12:46, Edward Tomasz Napierała  wrote:
> Wiadomość napisana przez John Baldwin w dniu 4 cze 2014, o godz. 19:30:
>
>> On Wednesday, June 04, 2014 1:17:14 pm Edward Tomasz Napierała wrote:
>>> On 0604T0907, Sean Bruno wrote:
 On Thu, 2014-05-29 at 09:30 -0400, John Baldwin wrote:
> On Thursday, May 29, 2014 9:16:41 am Sean Bruno wrote:
>> On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> On 2014-05-28 17:29:35 -0400, John Baldwin wrote:
 Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a
 length of zero (and is thus invalid)?
>>>
>>> BTW, ACPI 5.0a (page 121) says:
>>>
>>> "This is an optional field; if this register block is not supported,
>>> this field contains zero."
>>>
>>> Therefore, we must assume X_GPE1_BLK it is NOT supported.
>>>
>>> Jung-uk Kim
>>
>> So, reverting John's changes and applying yours seems to do new things
>> while not quieting the old error messages.  Perhaps this is significant?
>>
>> real memory  = 2147483648 (2048 MB)
>> avail memory = 2007089152 (1914 MB)
>> Event timer "LAPIC" quality 400
>> ACPI APIC Table: 
>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>> FreeBSD/SMP: 1 package(s) x 2 core(s)
>> cpu0 (BSP): APIC ID:  0
>> cpu1 (AP): APIC ID:  1
>> ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32
>> (20130823/tbfadt-601)
>> ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address
>> or length: 0x102C/0x0 (20130823/tbfadt-630)
>> ioapic0: Changing APIC ID to 1
>> ioapic0  irqs 0-23 on motherboard
>> random:  initialized
>> kbd1 at kbdmux0
>> acpi0:  on motherboard
>> CPU0: local APIC error 0x40
>> ACPI Error: GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 0 to
>> 15) - Ignoring GPE1 (20130823/evgpeinit-178)
>
> Actually, I think all these patches are changing nothing, and this 
> actually
> points out that I misread your FADT at the first.  GPE1 should actually be
> ignored since it does in fact overlap.  Can you just try reverting all 
> your
> changes and seeing if suspend/resume works?
>


 Boy oh boy ... talk about a waste of time.

 trasz@ and I have the same laptop and I just confirmed with him that the
 patch does nothing useful (as both of you suggested).  The *ACTUAL*
 problem seems to be related to disabling devices in the Thinkpad BIOS.
>>>
>>>
>>> Yup.  The culprit seems to be the "Security -> IO Port Access -> Modem"
>>> BIOS control: setting it to disabled breaks resume; the 
>>> AcpiEnterSleepState()
>>> never returns.
>>>
>>> With that option set to enabled, the suspend/resume works seems to work
>>> flawlessly on T61 with Intel graphics, with VT kernel and i915kms.ko,
>>> on 11-CURRENT/amd64 from a few days ago, without any patches or special
>>> sysctl/tunables.
>>
>> Well, document it on the wiki at least.
>
> Thanks for suggestion; done.
>
> ___
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Investigating failed suspend/resume T61

[Adrian Chadd]

Which devices?


-a

On 4 June 2014 09:07, Sean Bruno  wrote:
> On Thu, 2014-05-29 at 09:30 -0400, John Baldwin wrote:
>> On Thursday, May 29, 2014 9:16:41 am Sean Bruno wrote:
>> > On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote:
>> > > -BEGIN PGP SIGNED MESSAGE-
>> > > Hash: SHA1
>> > >
>> > > On 2014-05-28 17:29:35 -0400, John Baldwin wrote:
>> > > > Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a
>> > > > length of zero (and is thus invalid)?
>> > >
>> > > BTW, ACPI 5.0a (page 121) says:
>> > >
>> > > "This is an optional field; if this register block is not supported,
>> > > this field contains zero."
>> > >
>> > > Therefore, we must assume X_GPE1_BLK it is NOT supported.
>> > >
>> > > Jung-uk Kim
>> >
>> > So, reverting John's changes and applying yours seems to do new things
>> > while not quieting the old error messages.  Perhaps this is significant?
>> >
>> > real memory  = 2147483648 (2048 MB)
>> > avail memory = 2007089152 (1914 MB)
>> > Event timer "LAPIC" quality 400
>> > ACPI APIC Table: 
>> > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>> > FreeBSD/SMP: 1 package(s) x 2 core(s)
>> >  cpu0 (BSP): APIC ID:  0
>> >  cpu1 (AP): APIC ID:  1
>> > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32
>> > (20130823/tbfadt-601)
>> > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address
>> > or length: 0x102C/0x0 (20130823/tbfadt-630)
>> > ioapic0: Changing APIC ID to 1
>> > ioapic0  irqs 0-23 on motherboard
>> > random:  initialized
>> > kbd1 at kbdmux0
>> > acpi0:  on motherboard
>> > CPU0: local APIC error 0x40
>> > ACPI Error: GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 0 to
>> > 15) - Ignoring GPE1 (20130823/evgpeinit-178)
>>
>> Actually, I think all these patches are changing nothing, and this actually
>> points out that I misread your FADT at the first.  GPE1 should actually be
>> ignored since it does in fact overlap.  Can you just try reverting all your
>> changes and seeing if suspend/resume works?
>>
>
>
> Boy oh boy ... talk about a waste of time.
>
> trasz@ and I have the same laptop and I just confirmed with him that the
> patch does nothing useful (as both of you suggested).  The *ACTUAL*
> problem seems to be related to disabling devices in the Thinkpad BIOS.
>
> Disabling devices seems to cause the resume to not work correctly, but
> whatever.  So none of these patches are actually needed.
>
> sean
>
> ___
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: device.hints -> hint.acpi_throttle.0.disabled="1

[Adrian Chadd]

TL;DR - yes. That's why it was made as disabled by default now in hints.


-a

On 21 May 2014 12:53, Sean Bruno  wrote:
> I found sys/dev/acpica/acpi_throttle.c today.  Should I have this
> removed from a standard laptop configuration?  I would think I would
> want the system to throttle itself when appropriate.  Is this an older
> way of doing something like C-states or have I missed something?
>
> sean
>
> ___
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax

[Adrian Chadd]

The documentation is uhm, what's on intel's (growing) blog post and responses:

https://software.intel.com/en-us/articles/intel-performance-counter-monitor-a-better-way-to-measure-cpu-utilization

Yes, we can / should add clearer documentation. I had to also go
hunting in the source to figure some of it out.

FREQ/AFREQ is just the current clock cycle counters / clock reference
counter (TSC).

Ie, a freq or afreq of 1.0 means the clock cycle counters == TSC counter.

FREQ takes the sleep state into account (ie, only counts _running_
cycles.) AFREQ doesn't. So FREQ gives you a good indication of the
running duty cycle versus the ideal maximum, and AFREQ tells you what
frequency the core is running at versus the reference frequency. An
AFREQ of < 1.0 means that the chip is underclocking that core. An
AFREQ of > 1.0 means turboboost is on and it's overclocking that core.


-a


On 11 May 2014 17:40, Kevin Oberman  wrote:
> On Fri, May 9, 2014 at 1:36 PM, Adrian Chadd  wrote:
>>
>> cool!
>>
>> next;
>>
>> # pkg install intel-pcm
>> # kldload cpuctl
>> # pcm.x 1
>>
>> See what it reports.
>
>
> OK. Any documentation on what this is supposed to tell me? Some of it makes
> perfect sense and some baffles me.
>
> I see C-states of C1 and C6 when on AC and C1, C3, and C7 when on battery
> (and, of course, C0). FREQ vs. AFREQ look interesting, but I'm not sure I
> really understand the implications. The last few lines, from " PHYSICAL CORE
> IPC", are particularly mysterious to me. I can understand the words, but I
> think that they carry more significance than is obvious, at least to me. I'm
> not a hardware guy.
>  --
> R. Kevin Oberman, Network Engineer, Retired
> E-mail: rkober...@gmail.com
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax

[Adrian Chadd]

cool!

next;

# pkg install intel-pcm
# kldload cpuctl
# pcm.x 1

See what it reports.


-a


On 9 May 2014 13:12, Kevin Oberman  wrote:
> On Fri, May 9, 2014 at 3:25 AM, Adrian Chadd  wrote:
>>
>> Hi!
>>
>> On 9 May 2014 02:55, Poul-Henning Kamp  wrote:
>> > In message <20140505163316.r11...@sola.nimnet.asn.au>, Ian Smith writes:
>> >>On Mon, 5 May 2014 06:25:21 +, Poul-Henning Kamp wrote:
>> >> > In message <20140505153421.w11...@sola.nimnet.asn.au>, Ian Smith
>> >> > writes:
>> >> >
>> >> > Do we have a canonical page with all the various workarounds one
>> >> > should
>> >> > attempt in order to get suspend/resume to work ?
>> >>
>> >>Bits scattered all over the place.  For the above there's:
>> >
>> > So based on various scattered hints, I tried booting the VT kernel,
>> > r265336, on my Thinkpad T430s and that seems to fix both Suspend/Resume
>> > and also console switching.
>> >
>> > Much appreciated!
>> >
>> > I'll keep an eye on any peripheral bogons as I used it now.
>>
>> Woo!
>>
>> Would you mind populating http://wiki.freebsd.org/Laptops with your
>> details?
>>
>> Thanks!
>>
>>
>> -a
>
>
> Excellent! This alone will save batteries and also lower the carbon
> footprint of FreeBSD servers!
>
> Just to clarify the various settings of *_cx_lowest in rc.conf, HIGH is
> obvious. At one time, LOW was also obvious, but then some vendors started
> shipping BIOS that "skipped" some C-states in different power conditions.
> E.g. C1, C2 and C3 when on Battery, but only C1 and C3 when on AC. This
> scenario was common on Sandybridge systems (like my T320). Skipping a state
> broke "LOW" as it only saw C1 when on AC.  Thus, Cmax appeared. Cmax is
> simply C8. It is just easier ot remember then C8. The code was re-written to
> ignore "missing" C-states and try all possible C-states until C8 was
> reached.
>
> Why "LOW" was not just changed to deal with this I don't understand, but
> Cmax (or C8) is recommended to gain the maximum power savings from
> C-states.
>
> On AC power:
> dev.cpu.0.cx_supported: C1/1/1 C2/3/104
> dev.cpu.0.cx_lowest: C8
> dev.cpu.0.cx_usage: 8.86% 91.13% last 2685us
>
> On battery:
> dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109
> dev.cpu.0.cx_lowest: C8
> dev.cpu.0.cx_usage: 3.09% 0.74% 96.15% last 728us
>
> Note the supported list on AC?
> C2/3/104 The first part, "C2", is what the OS labels that second state. The
> next part, "3", is the ACPI number of this state. On AC, this system has no
> C-state 2, so FreeBSD call the ACPI state 3 "C2". Oh, the last number is the
> number of clock cycles required to get into/out of that state. so in my
> case, when on battery, my CPU goes ot C2 after being halted for 80 clock
> cycles and C3 after 109. I hope this makes sense to everyone. I'm not really
> sure that it does to me!
> --
> R. Kevin Oberman, Network Engineer, Retired
> E-mail: rkober...@gmail.com
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax

[Adrian Chadd]

Hi!

On 9 May 2014 02:55, Poul-Henning Kamp  wrote:
> In message <20140505163316.r11...@sola.nimnet.asn.au>, Ian Smith writes:
>>On Mon, 5 May 2014 06:25:21 +, Poul-Henning Kamp wrote:
>> > In message <20140505153421.w11...@sola.nimnet.asn.au>, Ian Smith writes:
>> >
>> > Do we have a canonical page with all the various workarounds one should
>> > attempt in order to get suspend/resume to work ?
>>
>>Bits scattered all over the place.  For the above there's:
>
> So based on various scattered hints, I tried booting the VT kernel,
> r265336, on my Thinkpad T430s and that seems to fix both Suspend/Resume
> and also console switching.
>
> Much appreciated!
>
> I'll keep an eye on any peripheral bogons as I used it now.

Woo!

Would you mind populating http://wiki.freebsd.org/Laptops with your details?

Thanks!


-a
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Emitting keyboard events

[Adrian Chadd]

On 7 May 2014 08:46, Xīcò  wrote:
> On Wed, May 07, 2014 at 03:51:17PM +0200, Lars Engels wrote:
>> IIRC Rui (CC'ed) did some work on implementing new ACPI key events in
>> acpi_asus for the first EeePC.
>
> Looking around the acpi drivers, some hard-encode actions associated to
> the events (like brightness control), some emit messages for devd (like
> sound control for the asus), and most mix the two options.
>
> Emitting devd events is both easy and highly user configurable. But it
> still does not solve the problem of reinjecting the special keys as
> generic keyboard events, for instance to let the user configure them
> through xorg. Writing a virtual keyboard in each acpi driver seems a lot
> of duplication, and maybe too heavy. IMHO acpi drivers should just emit
> information to be caught by devd. Maybe with a single format, so that a
> shared other component can listen to them and reinject them as generic
> keyboard events.

Indeed. Hack it up, send through patches. :)


-a
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Emitting keyboard events

[Adrian Chadd]

Just to follow up - I'd love to know how the hell to do this too.
acpi_ibm needs some updating. :(


-a


On 1 May 2014 13:57, Xīcò  wrote:
> Dear freebsd-acpi,
>
> Being a systemd refugee, I am trying to setup FreeBSD on several
> machines here. As a first question, I cannot find any driver to handle
> the hotkeys on a 2011 Sony VPCZ2. sys/dev/acpi_support/acpi_sony.c only
> contains backlight support for old laptops. Is anyone aware of such a
> driver?
>
> In any case, I started playing a bit with ACPI in a module, and have
> been able to register a handler for the hotkeys, and decode the
> associated events. Unfortunately, I have no idead of what I could do
> with them. At some point, I would like Xorg to receive keyboard events,
> such as XF86MonBrightnessUp, but I lack the knowledge on how to emit
> that from kernel space.
>
> Thank you for your help!
>
> Best,
>
> --
> Xīcò
> ___
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax

[Adrian Chadd]

On 5 May 2014 13:57, John Baldwin  wrote:

> The user in question found this on 9-stable with the existing defaults as the
> HPET was just plain broken on their system and that was unrelated to Cx 
> states.
> (Rather, Cx states were only involved because worries about them are why the
> system chose to use HPET.  Had Cx states been enabled by default, they would
> have had to disable those as well in addition to forcing LAPIC instead of
> HPET.)

Hm. Sounds uncomfortable. How does Windows run on systems like this?
Do the windows drivers just disable HPET and use LAPIC or worse for
timing, and just ignore anything lower than C1?

I'm going to flip the switch to enable Cmax on defaults/rc.conf on -HEAD today.



-a
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: suspend issues with latest -HEAD, ahci failing to complete something?

[Adrian Chadd]

Hi,

Would you mind testing the latest -HEAD out? It worked a couple weeks
ago with my last rebuild on this particular laptop.



-a


On 5 May 2014 12:51, Alexander Motin  wrote:
> On 05.05.2014 20:37, Adrian Chadd wrote:
>>
>> (I know, I just emailed out asking about setting S3 for the default
>> lid suspend state, however I just updated to the very latest head and
>> things went a little backwards.)
>>
>> Suspend no longer works for me:
>>
>> May  5 10:33:10 lucy-11i386 acpi: suspend at 20140505 10:33:10
>> May  5 10:33:47 lucy-11i386 kernel: ahcich0: Timeout on slot 19 port 0
>> May  5 10:33:47 lucy-11i386 kernel: ahcich0: is  cs fff80fff
>> ss fff80fff rs fff80fff tfd d0 serr  cmd d317
>> May  5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0):
>> WRITE_FPDMA_QUEUED. ACB: 61 08 e0 b0 fa 40 42 00 00 00 00 00
>> May  5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): CAM status:
>> Command timeout
>> May  5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): Retrying command
>> May  5 10:33:13 lucy-11i386 acpi: resumed at 20140505 10:33:13
>>
>> May  5 10:33:59 lucy-11i386 acpi: suspend at 20140505 10:33:59
>> May  5 10:34:37 lucy-11i386 kernel: ahcich0: Timeout on slot 9 port 0
>> May  5 10:34:37 lucy-11i386 kernel: ahcich0: is  cs ff83
>> ss ff83 rs ff83 tfd d0 serr  cmd c717
>> May  5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0):
>> WRITE_FPDMA_QUEUED. ACB: 61 08 18 5c f7 40 42 00 00 00 00 00
>> May  5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): CAM status:
>> Command timeout
>> May  5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): Retrying command
>> May  5 10:34:03 lucy-11i386 acpi: resumed at 20140505 10:34:03
>>
>> What has recently changed that'd possibly break ahci's ability to
>> correctly suspend?
>
>
> When I tested it last time (awhile ago), it was working for me.
> ahci_ch_suspend() should block all I/O on the channel and wait until all
> active commands complete. On resume channel should be reinitialized, device
> reset and only then I/Os should be released. Do you see those timeouts on
> suspend or resume?
>
> Do you have kern.cam.ada.spindown_suspend enabled? Can you try to disable
> it?
>
> --
> Alexander Motin
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

suspend issues with latest -HEAD, ahci failing to complete something?

[Adrian Chadd]

Hiya,

(I know, I just emailed out asking about setting S3 for the default
lid suspend state, however I just updated to the very latest head and
things went a little backwards.)

Suspend no longer works for me:

May  5 10:33:10 lucy-11i386 acpi: suspend at 20140505 10:33:10
May  5 10:33:47 lucy-11i386 kernel: ahcich0: Timeout on slot 19 port 0
May  5 10:33:47 lucy-11i386 kernel: ahcich0: is  cs fff80fff
ss fff80fff rs fff80fff tfd d0 serr  cmd d317
May  5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0):
WRITE_FPDMA_QUEUED. ACB: 61 08 e0 b0 fa 40 42 00 00 00 00 00
May  5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): CAM status:
Command timeout
May  5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): Retrying command
May  5 10:33:13 lucy-11i386 acpi: resumed at 20140505 10:33:13

May  5 10:33:59 lucy-11i386 acpi: suspend at 20140505 10:33:59
May  5 10:34:37 lucy-11i386 kernel: ahcich0: Timeout on slot 9 port 0
May  5 10:34:37 lucy-11i386 kernel: ahcich0: is  cs ff83
ss ff83 rs ff83 tfd d0 serr  cmd c717
May  5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0):
WRITE_FPDMA_QUEUED. ACB: 61 08 18 5c f7 40 42 00 00 00 00 00
May  5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): CAM status:
Command timeout
May  5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): Retrying command
May  5 10:34:03 lucy-11i386 acpi: resumed at 20140505 10:34:03

What has recently changed that'd possibly break ahci's ability to
correctly suspend?

Thanks,


-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax

[Adrian Chadd]

On 5 May 2014 08:09, John Baldwin  wrote:
> On Sunday, May 04, 2014 4:27:38 am Adrian Chadd wrote:
>> Hi,
>>
>> I'd like to propose flipping a few things:
>>
>> * Flipping the default lid state to S3. I think ACPI suspend/resume
>> seems to work well enough these days and I've not met anyone lately
>> who expects the default from their laptop to be "stay awake with the
>> lid shut."
>> * Save chip bugs that we should add workarounds for, we should be OK
>> to enter lower sleep states when idling. Flipping this may expose some
>> further crazy driver, platform or timer bugs, but they again likely
>> should be fixed.
>>
>> what do people think?
>
> I think the lid switch thing is premature.  Even on my X220 I use a devd
> hook to enable it only when i915drm is loaded as resume doesn't work until
> that is done.
>
> I think the Cmax thing OTOH is probably more appropriate.  We have several
> things place that should "mostly" DTRT for picking the correct timers to
> use.  The one case I know of recently were some somewhat older systems where
> the HPET wasn't reliable, but the system chose to use HPET instead of LAPIC
> becuase the LAPIC was known to stop during C1E, etc.  In this case the user
> just stuck with plain old C1 and forced the LAPIC timer which worked fine.
> However, it is hard to identify those cases.  On modern systems I would
> expect the LAPIC to work just fine, so this problem will become less and
> less important as time goes on.

right. I'd rather we start finding more of these sooner rather than later. :-)



-a
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax

[Adrian Chadd]

On 4 May 2014 22:18, Ian Smith  wrote:
> On Sun, 4 May 2014 17:25:50 -0700, Adrian Chadd wrote:
>  > [snip]
>  >
>  > The easy-to-run test is "sysctl dev.cpu.0.cx_lowest=Cmax" and then use 
> stuff.
>
> This doesn't work, on stable/9 at least, in that it only sets cpu.0 ..
> you need to set sysctl hw.acpi.cpu.cx_lowest - which rather surprised
> me, although that's what /etc/rc.d/power_profile has always set.  I
> guess it's only cpu.0.freq that still sets all CPUs in sync.

Yeah. Sorry, my mistake. One should just do the rc.conf change and reboot.

> Further, rather than
>  -economy_cx_lowest="HIGH" # Offline CPU idle state
>  +economy_cx_lowest="Cmax" # Offline CPU idle state
> you could use "LOW" which already sets it to "Cmax", though on 8.2:
>  lowest_value="`(sysctl -n dev.cpu.0.cx_supported | \
> awk '{ print "C" split($0, a) }' -) 2> /dev/null`"
>
> I'm not sure what the point of setting cx_lowest to C8 is on a machine
> where lowest cx_supported is C3, but it seems to do no harm on mine.

Well, it's just convenient to set it to that. It's the same as Cmax.

> Where does C8 come from anyway?  Is that the lowest on any known
> hardware, or the lowest the ACPI spec supports?

Not sure. It's what's chosen when you use Cmax. :-)

> root@x200:~ # sysctl -a | grep cx
> hw.acpi.cpu.cx_lowest: C3
> dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
> dev.cpu.0.cx_lowest: C3
> dev.cpu.0.cx_usage: 0.00% 0.79% 99.20% last 35us
> dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
> dev.cpu.1.cx_lowest: C3
> dev.cpu.1.cx_usage: 0.08% 1.59% 98.32% last 62us
>
> root@x200:~ # sysctl dev.cpu.0.cx_lowest=Cmax
> dev.cpu.0.cx_lowest: C3 -> C8
> root@x200:~ # sysctl -a | grep cx
> hw.acpi.cpu.cx_lowest: C3
> dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
> dev.cpu.0.cx_lowest: C8 <<<<
> dev.cpu.0.cx_usage: 0.00% 5.66% 94.33% last 73us
> dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
> dev.cpu.1.cx_lowest: C3 <<<<
> dev.cpu.1.cx_usage: 0.07% 1.91% 98.01% last 2us
>
> root@x200:~ # sysctl dev.cpu.1.cx_lowest=C2
> dev.cpu.1.cx_lowest: C3 -> C2
> root@x200:~ # sysctl -a | grep cx
> hw.acpi.cpu.cx_lowest: C3   <<<<
> dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
> dev.cpu.0.cx_lowest: C8 <<<<
> dev.cpu.0.cx_usage: 0.00% 0.19% 99.80% last 474us
> dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
> dev.cpu.1.cx_lowest: C2 <<<<
> dev.cpu.1.cx_usage: 3.47% 96.52% 0.00% last 1us
>
> root@x200:~ # sysctl hw.acpi.cpu.cx_lowest=Cmax
> hw.acpi.cpu.cx_lowest: C3 -> C8
> root@x200:~ # sysctl -a | grep cx
> hw.acpi.cpu.cx_lowest: C8
> dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
> dev.cpu.0.cx_lowest: C8
> dev.cpu.0.cx_usage: 0.00% 3.05% 96.94% last 351us
> dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
> dev.cpu.1.cx_lowest: C8
> dev.cpu.1.cx_usage: 0.00% 7.05% 92.94% last 2us
>
> I've long run with C3 in AC power mode without issue, but don't know if
> that's true for all machines; all yours and mine are Thinkpads!

I've only had problems on an older Atom. That I'll bring with me to
bsdcan to finally show mav. Linux has had the same problem with this
particular Atom and timekeeping. ;(

>  > The problem is that we're not getting anywhere near enough exposure to
>  > this kind of stuff because we don't have it on by default and we don't
>  > have an active QA group with ridiculous amounts of hardware.
>  >
>  > So, I'd like to flip it on and then start blacklisting devices that
>  > actively don't work in halt states above C1. We're never going to
>  > cross this bridge fully if we leave things at C1 out of fear.
>  >
>  > I'm only suggesting we do this on -HEAD. If it's too scary then we can
>  > always flip the default back to C1 for 11.0-RELEASE.
>
> Yeah, I think this likely uncontroversial - unlike lid state S3 - and I
> don't recall hearing about machines that fail below C1 if lower states
> are shown as available.  As you say, this might shake these out.
>
> But where would you put such a blacklist?  Someting like USB quirks?

I'm not sure yet. Maybe make it userland and as part of the rc / power
scripts. That way Cmax gets turned into C1.



-a
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax

[Adrian Chadd]

On 4 May 2014 17:53, Warren Block  wrote:
> On Sun, 4 May 2014, Adrian Chadd wrote:
>
>> [snip]
>>
>> The easy-to-run test is "sysctl dev.cpu.0.cx_lowest=Cmax" and then use
>> stuff.
>
>
> It's that "use stuff" step that would preferably be automated.  Is the
> failure mode a lockup, or could a program detect problems?  The idea is to
> get lots of feedback, fast.

The lack of a general test suite is a bigger problem. :-)


-a
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax

[Adrian Chadd]

[snip]

The easy-to-run test is "sysctl dev.cpu.0.cx_lowest=Cmax" and then use stuff.

The problem is that we're not getting anywhere near enough exposure to
this kind of stuff because we don't have it on by default and we don't
have an active QA group with ridiculous amounts of hardware.

So, I'd like to flip it on and then start blacklisting devices that
actively don't work in halt states above C1. We're never going to
cross this bridge fully if we leave things at C1 out of fear.

I'm only suggesting we do this on -HEAD. If it's too scary then we can
always flip the default back to C1 for 11.0-RELEASE.



-a
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax

[Adrian Chadd]

On 4 May 2014 13:00, Poul-Henning Kamp  wrote:
> In message <20140505011654.o11...@sola.nimnet.asn.au>, Ian Smith writes:
>>On Sun, 4 May 2014 01:27:38 -0700, Adrian Chadd wrote:
>
>>'Seems to work well enough' on a still fairly limited range of laptops,
>>I gather.
>
> I'd say.
>
> I havn't seen suspend/resume work for ages on my T4xx laptops and
> as far as I recall it never worked on this T430s at all.

I've tested it (-HEAD) on:

* T43
* T60
* T60p
* T400
* T500
* T420
* X220

I'm actively using the T60, T400 and X220 right now.

I'd like to see it working on more laptops and I've worked with
various people in the past to try and fix whichever resume issues I
find.

I'm happy leaving this as-is but at some point something has to be
bitten and the bugs in the drivers / ACPI stuff need to be fixed. :)


-a
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

proposal: set default lid state to S3, performance/economy Cx states to Cmax

[Adrian Chadd]

Hi,

I'd like to propose flipping a few things:

* Flipping the default lid state to S3. I think ACPI suspend/resume
seems to work well enough these days and I've not met anyone lately
who expects the default from their laptop to be "stay awake with the
lid shut."
* Save chip bugs that we should add workarounds for, we should be OK
to enter lower sleep states when idling. Flipping this may expose some
further crazy driver, platform or timer bugs, but they again likely
should be fixed.

what do people think?


-a


Index: etc/defaults/rc.conf
===
--- etc/defaults/rc.conf (revision 265255)
+++ etc/defaults/rc.conf (working copy)
@@ -642,9 +642,9 @@
 devfs_set_rulesets="" # A list of /mount/dev=ruleset_name settings to
  # apply (must be mounted already, i.e. fstab(5))
 devfs_load_rulesets="YES" # Enable to always load the default rulesets
-performance_cx_lowest="HIGH" # Online CPU idle state
+performance_cx_lowest="Cmax" # Online CPU idle state
 performance_cpu_freq="NONE" # Online CPU frequency
-economy_cx_lowest="HIGH" # Offline CPU idle state
+economy_cx_lowest="Cmax" # Offline CPU idle state
 economy_cpu_freq="NONE" # Offline CPU frequency
 virecover_enable="YES" # Perform housekeeping for the vi(1) editor
 ugidfw_enable="NO" # Load mac_bsdextended(4) rules on boot
Index: sys/dev/acpica/acpi.c
===
--- sys/dev/acpica/acpi.c (revision 265255)
+++ sys/dev/acpica/acpi.c (working copy)
@@ -620,11 +620,12 @@

 /*
  * Dispatch the default sleep state to devices.  The lid switch is set
- * to UNKNOWN by default to avoid surprising users.
+ * to S3 to mirror what everything else iBook and later does.
  */
 sc->acpi_power_button_sx = acpi_sleep_states[ACPI_STATE_S5] ?
  ACPI_STATE_S5 : ACPI_STATE_UNKNOWN;
-sc->acpi_lid_switch_sx = ACPI_STATE_UNKNOWN;
+sc->acpi_lid_switch_sx = acpi_sleep_states[ACPI_STATE_S3] ?
+ACPI_STATE_S3 : ACPI_STATE_UNKNOWN;
 sc->acpi_standby_sx = acpi_sleep_states[ACPI_STATE_S1] ?
  ACPI_STATE_S1 : ACPI_STATE_UNKNOWN;
 sc->acpi_suspend_sx = acpi_sleep_states[ACPI_STATE_S3] ?
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: kern/187152

[Adrian Chadd]

The following reply was made to PR kern/187152; it has been noted by GNATS.

From: Adrian Chadd 
To: "bug-follo...@freebsd.org" , Adrian Chadd 

Cc:  
Subject: Re: kern/187152
Date: Mon, 3 Mar 2014 15:46:30 -0800

 Hi,
 
 After resume, starting any processes would also result in SIGFPE.
 
 This time i was lucky enough to get to a non-X newcons login prompt,
 and login would spawn fine, but the shell(s) would die instantly with
 SIGFPE.
 
 
 -a
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Fixing X220 Video The Right Way

[Adrian Chadd]

So now that i have everything else working on this x230, I'm taking a
fresh look at the acpi brightness support.

I'm in the same boat - only PEG works. But I have integrated graphics
only, rather than both integrated and nvidia graphics.

A cursory reading of the linux acpi and video / video-detect code
doesn't show anything terribly obvious. I may end up downloading and
booting ubuntu on USB at some point to see what the ACPI device tree
looks like, in case they are somehow linking vgapci0 correctly to
SB.PCI0.PEG.VID.

Any other ideaS?


-a
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

P-state setting suddenly disappeared, what gives?

[Adrian Chadd]

Hi all,

I have this Lenovo T400 that I've been doing FreeBSD development on for a while.

It has a P8700 in it:

CPU: Intel(R) Core(TM)2 Duo CPU P8700  @ 2.53GHz (2527.07-MHz 686-class CPU)

Now, up until yesterday, ACPI exported the required twiddles to enter
various different P-states.

However, as of sometime yesterday, it stopped being able to do so.

sysctl dev.cpu.0.freq returns nothing. Setting it to something retuns
"device not configured." The frequency list (ie, the P-state list) is
still fine.

I had to load cpufreq.ko to get the enhanced speedstep stuff to show
up, but (a) it doesn't support this CPU (and it seems to have stopped
growing EST bits after Pentium M CPUs..) and (b) setting the frequency
using it versus P-state settings doesn't save as much power.

I'd like to try and debug why the heck this is.

The laptop still works fine, things are just not as "nice" as they once were.

Any ideas? Any suggestions on where to start debugging this?

Thanks!



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Problems with amd FX 8 core and freq scaling

[Adrian Chadd]

On 11 November 2013 13:47, Jung-uk Kim  wrote:

> Just in case, here I attached the uncommitted (and untested) patch.
>

Would you mind describing everything that this patch does?



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Re: Problems with amd FX 8 core and freq scaling

[Adrian Chadd]

On 11 November 2013 12:00, Jung-uk Kim  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2013-11-11 13:16:47 -0500, Nicholas McKenzie wrote:
>> But wouldn't this just disable frequency scaling and the whole
>> point of powerd?
>
> No.  acpi_throttle (and p4tcc) controls T-state.  "Frequency scaling"
> should be done by changing P-state.

Right.

IIRC, T-state is just for emergency temperature throttling. It
shouldn't be used outside of that.


>>> There have been a number of reports of throttling causing
>>> crashes. This setting does not prevent powerd from adjusting
>>> your CPU's clock, it just disables some arcane feature which
>>> pre-dates the modern power management methods.

.. did anyone ever figure out why crashes would be caused by T-state adjustment?

> I rewrote acpi_throttle.c at some point to fix the problem but never
> committed it because nobody was really interested in testing the
> patch.  Also, it is really an arcane and archaic feature:
>
> http://software.intel.com/en-us/blogs/2013/10/15/c-states-p-states-where-the-heck-are-those-t-states
>
> Now I think we should disable the feature by default because it is
> causing too much hassle for us (attached).  Any objection?

No, I think we should correctly identify which particular features are
required for which particular CPUs and enable/disable it based on
that.

So, if it's relevant for P4 era hardware, let's default to having it
on for that class hardware.

If it's not relevant for core and core 2 (and later) hardware, then
let's default to leaving it off for that.

So, how about we come up with a table of CPUs and what particular
power save technologies we should be using, then start implementing
that?

I'm reading the SDM bits on the adaptive frequency stuff (turbo boost,
etc) and I'll see about writing up some data gathering knobs for the
kernel.

People still spin up FreeBSD on P4 (and earlier) class hardware. I'd
rather we get it right versus just flipping crap on and off based on
what 'current' hardware expects. I watched people do this with the RTC
code. It's ridiculous.


-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Xeon E5 cpu work in low status

[Adrian Chadd]

On 4 November 2013 14:24, Konstantin Belousov  wrote:

> My Intel board DQ67OW starts with the fixed CPU speed, which is
> configurable in BIOS. Unless OS starts managing the frequency with the
> cpufreq and powerd, CPU is locked to the pre-configured speed. It was
> not easy to understand why my single-user memory b/w benchmarks show
> half of the expected throughput for the cache, until I found the setting
> and found that Intel defaults to 1/2 of the marketing frequency.
>
> For my board, it is Performance->Processor Overrides->Maximum Non-Turbo
> Ratio.  It was set to 17, normal CPU mode is 34, turbo is 38 max.

Does powerd throttle each individual core like this? I don't have
anything laptop-y that's recent enough for that to matter.



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Xeon E5 cpu work in low status

[Adrian Chadd]

.. and what I'd really like to see is some tools to inspect power
consumption on the CPU side of things.

I'd also like something for the GPU side of things too. I can't find
anything in our DRM driver code that twiddles the clock PLL registers
to slow things down.

Thanks,



-adrian

On 4 November 2013 10:00, Adrian Chadd  wrote:
> A lot of us think this. The question is .. who's going to fix it?
>
> :-)
>
>
>
> -adrian
>
>
> On 4 November 2013 09:52, Kevin Oberman  wrote:
>> On Mon, Nov 4, 2013 at 12:46 AM, 李森  wrote:
>>
>>> hi,all:
>>> the cpu of my machine is :  Intel(R) Xeon(R) CPU E5-2643 0 @
>>> 3.30GHz.
>>>
>>> after a reboot. The cpu freq is : sysctl dev.cpu.0.freq
>>> dev.cpu.0.freq: 1200
>>>
>>> i didn't set any power savings config in rc.conf.
>>>
>>> How can i fix this?
>>>
>>
>> It's not clear what is broken. Is the server busy? Is there some reason to
>> expect it to be running at full clock-rate?
>>
>> What is the content of dev.cpu.0.freq_levels?
>>
>> By default, FreeBSD runs powerd and that will, by default, throttle back
>> the clock when the system is not busy. I think that this is a bad thing.,
>> but it is not a bug. It's by design. I really think, based on my own
>> testing, research and a major NSF computer center (SDSC), and work done by
>> mav@ which can be found on the FreeBSD wiki (
>> https://wiki.freebsd.org/TuningPowerConsumption), those "power management"
>> tools are broken by design a they are actually there for thermal control,
>> not power management and are, at best, break-even, and in most cases are
>> actually a loser in both power savings and system performance. (There are a
>> very few edge cases where they can be beneficial, but as a side effect for
>> very specific loads under fairly unusual circumstances.)
>>
>> To turn off these (mis)features, add the following to /boot/loader.conf:
>> # Disable CPU throttling
>> hint.p4tcc.0.disabled=1
>> hint.acpi_throttle.0.disabled=1
>>
>> 
>> All real power management is through the use of EST and CPU sleep (CX)
>> states. These  can provide a big power win at minimal performance impact.
>> Unfortunately CX states and throttling lay very badly together, probably
>> because processor designers don't think that TCC and throttling are for
>> power management, so are not an issue.
>>
>> For reasons that have always baffled me, rather than disable the
>> inappropriate use of thermal management as power management, we disable the
>> most effective power management tools by default.
>> performance_cx_lowest="HIGH" # Online CPU idle state
>> economy_cx_lowest="HIGH" # Offline CPU idle state
>>
>> Even the comments are confusing: what do "Online" and "Offline" mean?
>> Offline means running on battery and online means AC power.
>>
>> In any case, it's not clear that there is any issue with your system other
>> than that, by default, FreeBSD tries to really, really hard to manage power
>> as badly as humanly possible.
>> 
>>
>> --
>> R. Kevin Oberman, Network Engineer
>> E-mail: rkober...@gmail.com
>> ___
>> freebsd-acpi@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Xeon E5 cpu work in low status

[Adrian Chadd]

A lot of us think this. The question is .. who's going to fix it?

:-)



-adrian


On 4 November 2013 09:52, Kevin Oberman  wrote:
> On Mon, Nov 4, 2013 at 12:46 AM, 李森  wrote:
>
>> hi,all:
>> the cpu of my machine is :  Intel(R) Xeon(R) CPU E5-2643 0 @
>> 3.30GHz.
>>
>> after a reboot. The cpu freq is : sysctl dev.cpu.0.freq
>> dev.cpu.0.freq: 1200
>>
>> i didn't set any power savings config in rc.conf.
>>
>> How can i fix this?
>>
>
> It's not clear what is broken. Is the server busy? Is there some reason to
> expect it to be running at full clock-rate?
>
> What is the content of dev.cpu.0.freq_levels?
>
> By default, FreeBSD runs powerd and that will, by default, throttle back
> the clock when the system is not busy. I think that this is a bad thing.,
> but it is not a bug. It's by design. I really think, based on my own
> testing, research and a major NSF computer center (SDSC), and work done by
> mav@ which can be found on the FreeBSD wiki (
> https://wiki.freebsd.org/TuningPowerConsumption), those "power management"
> tools are broken by design a they are actually there for thermal control,
> not power management and are, at best, break-even, and in most cases are
> actually a loser in both power savings and system performance. (There are a
> very few edge cases where they can be beneficial, but as a side effect for
> very specific loads under fairly unusual circumstances.)
>
> To turn off these (mis)features, add the following to /boot/loader.conf:
> # Disable CPU throttling
> hint.p4tcc.0.disabled=1
> hint.acpi_throttle.0.disabled=1
>
> 
> All real power management is through the use of EST and CPU sleep (CX)
> states. These  can provide a big power win at minimal performance impact.
> Unfortunately CX states and throttling lay very badly together, probably
> because processor designers don't think that TCC and throttling are for
> power management, so are not an issue.
>
> For reasons that have always baffled me, rather than disable the
> inappropriate use of thermal management as power management, we disable the
> most effective power management tools by default.
> performance_cx_lowest="HIGH" # Online CPU idle state
> economy_cx_lowest="HIGH" # Offline CPU idle state
>
> Even the comments are confusing: what do "Online" and "Offline" mean?
> Offline means running on battery and online means AC power.
>
> In any case, it's not clear that there is any issue with your system other
> than that, by default, FreeBSD tries to really, really hard to manage power
> as badly as humanly possible.
> 
>
> --
> R. Kevin Oberman, Network Engineer
> E-mail: rkober...@gmail.com
> ___
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Update: Lenovo X230, suspend/resume

[Adrian Chadd]

Hi,

I've just updated to the latest -HEAD.

* if I leave VESA in, then suspend works; resume brings the backlight back
but not the video screen. Same behavour in X and console.

* If I leave VESA out, then suspend works; resume doesn't restore the
backlight. Same behaviour in X and console.

Does anyone have any ideas on this?

Thanks,



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: 9.2-RC3 - suspend/resume causes slow system performance

[Adrian Chadd]

.. anything happening?


-adrian


On 2 September 2013 07:29, Adrian Chadd  wrote:

>
> On 2 September 2013 07:25, Mike Harding  wrote:
>
>> It's detailed in the ticket,  see
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for
>> 'reverted'.
>>
>>
> Ok. You and avg@ are digging into it deeper, so I'll leave it be for now.
> I'll retest this on my test laptops when I'm back home.
>
>
>
> -adrian
>
>
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: suspend/resume on Lenovo X1 (regression from reports on wiki)

[Adrian Chadd]

Whoa whoa.

I'm confused. Well, a bit. How is it up to syscons to fix the backlight
configuration, which seems to be a large part of the problem here?

Or what else is going on here with restoring the system state?

I'm worried that we'll have the same problem with newcons, with or without
KMS. Why would KMS get involved if I'm in console mode doing 80x60 text? :)



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: 9.2-RC3 - suspend/resume causes slow system performance

[Adrian Chadd]

On 2 September 2013 07:25, Mike Harding  wrote:

> It's detailed in the ticket,  see
> http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for
> 'reverted'.
>
>
Ok. You and avg@ are digging into it deeper, so I'll leave it be for now.
I'll retest this on my test laptops when I'm back home.



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: 9.2-RC3 - suspend/resume causes slow system performance

[Adrian Chadd]

So you tinkered with this - which particular line(s) did you revert back to
get the old behaviour?

-adrian


On 1 September 2013 22:46, Mike Harding  wrote:

> Why not put this out to stable and take a survey with more than 2
> members?  I am sure that there
> are those who will be delighted, as I was with 9.1, to discover that
> suspend/resume worked without
> rebooting the machine.
>
> I can make the system available to you, contact me at this email.  I am in
> the PDT time zone.
>
>
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: 9.2-RC3 - suspend/resume causes slow system performance

[Adrian Chadd]

.. well, when is that pointer NULL? It looks like it's supposed to be NULL
for one pair of the two HT CPUs?

Are you taking the whole core into an ACPI idle state if one of two logical
CPUs representing a core is going idle?



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: 9.2-RC3 - suspend/resume causes slow system performance

[Adrian Chadd]

On 1 September 2013 14:35, Andriy Gapon  wrote:


> Do you have any evidence that there is anybody else besides Mike who has
> this
> problem?
>


Nope! but we can't assume that users are reporting all the system slowdowns.

And honestly, I've heard enough strange stories on mailing lists and IRC of
things like "during disk IO, blah would be really slow, when I change
timekeeping or halt from ACPI to something else, things get better." So I
can't discount that this is affecting people and they either don't know, or
just chalk it up as "shitty hardware."

Also, I usually try to "sort out" things after there is a clear
> understanding of
> what the problem is and how it should be fixed.
>
>
Well, the big change is that it's now going into a sleep state on a HT
core, right?

Are you able to go into an ACPI sleep state on a HT logical CPU, rather
than the physical core? Or am I mis-understanding what's going on?



> > Reverting and fixing it later seems like the safest option to me. Is
> there a
> > bigger problem that you tried to fix in that patch that wasn't as
> obvious?
>
> I do not see any problem with the code*.*  I do not see any explanation of
> the
> root cause of the problem that Mike has.  I do not see why anything has to
> be
> reverted.  Especially because "since we're so close to 9.2-REL".
> Just in case, I'll remind that the commit in question is in stable/9 since
> Dec
> 23 2012.
>
>
Right, but I also know a lot of people who just have stayed with 8.x or
9.0-RELEASE and haven't bothered upgrading. Again, I can't assume that
everyone has been keeping up to date with stable/9 and providing feedback.

Thanks,


-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: 9.2-RC3 - suspend/resume causes slow system performance

[Adrian Chadd]

On 31 August 2013 23:41, Andriy Gapon  wrote:

> >
> > I've tracked this down to a single line, details in
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=181632.  Basically, the
> code is
> > now doing a 'sti, hlt' vs. a 'sti' in some code that is only
> supposed to run
> > if idle is disabled.  Given that 'hlt' is the idle instruction, this
> doesn't
> > seem right.
> >
> >
> > Wow, nice!
> >
> > Avg - can we get this fixed? Or just revert this!
>
> Thank you for trying to be helpful.  But let's not jump to conclusions.
> BTW, I am following up on the problem in the PR.
>

Sure, I'd like to know why it's behaving badly. But since we're so close to
9.2-REL, do you think you can get it sorted out and bug-free on all the
existing platforms that people are using 9.2 on (including server, desktop
and laptop) without reverting it?

Reverting and fixing it later seems like the safest option to me. Is there
a bigger problem that you tried to fix in that patch that wasn't as obvious?

Thanks,



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: suspend/resume on Lenovo X1 (regression from reports on wiki)

[Adrian Chadd]

(cc jkim)

Hi! Would you mind taking a look at the -acpi list posts with this subject?
It looks like a lot of the video suspend/resume issues on these thinkpads
boil down to the VESA driver code. If it's disabled, (at least) x11 resume
works.

Would you be able to help us track down what's going on?

Thanks!



-adrian



On 31 August 2013 10:23, Kevin Oberman  wrote:

> On Sat, Aug 31, 2013 at 9:53 AM, Adrian Chadd  wrote:
>
>> Ok.
>>
>> I'm glad this is actually working for people.
>>
>> But now comes the hard bit - figuring out why the VESA driver is breaking
>> resume. :(
>>
>> I actually use VESA text modes in console mode so I'll take a look but I
>> can't promise anything.
>>
>> Who actually has experience with the VESA code and may be able to help?
>> Does anyone know?
>>
>> Thanks,
>>
>>
>>
>> -adrian
>>
>>
> Of course this is the real issue. Removing VESA is just a band-aid and
> will become a problem once newcons makes it out the door (any day now).
>
> I'd like to try to figure out the scope of the problem, if possible. In
> most (all?) reports, removing VESA has worked on Thinkpads. I think I have
> seen reports that it works on other platforms, but I'm not positive. I also
> believe that it has been reported to not work for attempts to
> suspend/resume when in text mode... only when in X. (I guess I can test
> this myself.)
>
> For almost four years all vesa commits were by jkim.
>
> --
> R. Kevin Oberman, Network Engineer
> E-mail: rkober...@gmail.com
>
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: 9.2-RC3 - suspend/resume causes slow system performance

[Adrian Chadd]

On 31 August 2013 10:35, Mike Harding  wrote:

> I've tracked this down to a single line, details in
> http://www.freebsd.org/cgi/query-pr.cgi?pr=181632.  Basically, the code
> is now doing a 'sti, hlt' vs. a 'sti' in some code that is only supposed to
> run if idle is disabled.  Given that 'hlt' is the idle instruction, this
> doesn't seem right.
>
>
Wow, nice!

Avg - can we get this fixed? Or just revert this!



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: suspend/resume on Lenovo X1 (regression from reports on wiki)

[Adrian Chadd]

Ok.

I'm glad this is actually working for people.

But now comes the hard bit - figuring out why the VESA driver is breaking
resume. :(

I actually use VESA text modes in console mode so I'll take a look but I
can't promise anything.

Who actually has experience with the VESA code and may be able to help?
Does anyone know?

THanks,



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: suspend/resume on Lenovo X1 (regression from reports on wiki)

[Adrian Chadd]

On 29 August 2013 20:14, Sergey A. Osokin  wrote:

> On Wed, Aug 28, 2013 at 07:03:10PM +0400, Gleb Smirnoff wrote:
> >   Laura,
> >
> >   Now bad news :) Last major Xorg update in ports, which happened couple
> > of months ago, introduced a regression: xorg performs very slowly after
> > resume. If the server process is restarted, then a new one performs okay.
>
> Agree with Gleb.  Kind of a slowness exist after resume.
>
>
Can y'all grab some basic, naive benchmarks (disk, CPU) and compare them
before/after a suspend/resume cycle?



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: 9.2-RC3 - suspend/resume causes slow system performance

[Adrian Chadd]

On 29 August 2013 23:46, Mike Harding  wrote:

> I was able to track this down by building kernels against /base/stable/9
> (it took
> -hours!-).
>

Wow, thanks!


> The issue does occur with commit 244616, but does not occur with 244614.
> The
> only difference is a small patch to /usr/src/sys/dev/acpica/acpi_cpu.c -
> this
> code appears to do with c-state processing.  I'll note it in the ticket,
> but somebody
> might want to look at this ASAP
>

That's awesome. It's a very small ACPI patch. Let's see if the others who
are having this issue can test this out and report back!

Thanks!



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: suspend/resume on Lenovo X1 (regression from reports on wiki)

[Adrian Chadd]

Hi!

On 29 August 2013 09:42, Laura Marie Feeney  wrote:

> Hi
>
> Yes! I now have working suspend/resume building xorg using the updated
> ports and compile options that Gleb Smirnoff kindly pointed me at.
>
> No xorg.conf is needed and all acpi options are as default.  It seems to
> work correctly both with and without acpi_video and acpi_ibm in the kernel.
>  It's still necessary to compile  out 'options VESA' from the kernel,
> otherwise resume fails entirely.
>
> I also observe the issue that Gleb Smirnoff mentions below, that the xorg
> server is quite slow after result.  Using 'xterm -sb' and moving the
> scrollbar up and down very fast, I was able to able to get the xorg process
> up to ~20% of CPU.  On casual observation, it didn't seem to get worse
> after several suspend/resume cycles.
>
> Definitely suspend/resume are working and amazingly fast compared to 8.2
> (though running on a much older machine).
>
> Thanks to all for the useful suggestions!
>
>>
>>
Let's not finish this just yet! I'd like to try and nail down exactly
what's going on so PRs can be filed.

* Is this with 9.2-RC2? Are you wiling to try out a -HEAD snapshot to make
sure this stuff in -10 is also going to work?
* Ok, so if you have no VESA option, does suspend/resume work in console
mode?
* Try manually setting the cpu frequency low and high (sysctl dev.0.cpu -
you can change 'freq') - see if that fixes your speed issues. Someone else
has reported this.

Thanks!



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: suspend/resume on Lenovo X1 (regression from reports on wiki)

[Adrian Chadd]

Hi!

What's the result of all of this? Laura - do you have functioning
suspend/resume with xorg now?



-adrian



On 28 August 2013 08:03, Gleb Smirnoff  wrote:

>   Laura,
>
>   according to your Xorg.log PCI device ID of your video card exactly
> matches mine 8086:0166:17aa:21f9, so it should work.
>
>   It looks like versions of Xorg and Xorg Intel driver installed from
> packages are too old, and this is the biggest difference between your
> setup and mine. You are running Xorg 1.7.7.
>
>   This is what I run:
>
> glebius@think:~:|>pkg info xorg-server xf86-video-intel
> xorg-server-1.12.4,1
> xf86-video-intel-2.21.9
>
>   To get these packages you need to update your ports tree, put
> these lines into /etc/make.conf:
>
> WITH_NEW_XORG=yes
> WITH_KMS=yes
>
>   , and reinstall xorg-server and xf86-video-intel from ports. You'd
> probably need to rebuild all xorg drivers like mouse and keyboard,
> to make them compatible with new server version.
>
>   If this isn't enough I can send my xorg.conf and kernel config. But
> I hope default configs should be fine.
>
>
>   Now bad news :) Last major Xorg update in ports, which happened couple
> of months ago, introduced a regression: xorg performs very slowly after
> resume. If the server process is restarted, then a new one performs okay.
> So this looks like xorg issue, not FreeBSD kernel problem.
>
> On Wed, Aug 28, 2013 at 02:48:04PM +0200, Laura Marie Feeney wrote:
> L> Thanks!  I think that X1 and Carbon are different names, as Lenovo seems
> L> to use them quite interchangably (perhaps for different countries?).
> L> This isn't an X1 Touch, which surely has non-trivial differences for the
> L> touchscreen.
>
> X1 and X1 Carbon are really different, I owned both. Yep, both work with
> FreeBSD.
>
> --
> Totus tuus, Glebius.
> ___
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
>
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: suspend/resume on Lenovo X1 (regression from reports on wiki)

[Adrian Chadd]

Hi!

Can you try 9.0-RELEASE? ANd 9.1-RELEASE?

When you get a panic on resume - how do you know that? Can you get a photo
of it?



-adrian


On 27 August 2013 12:53, Laura Marie Feeney  wrote:

> At 
> https://wiki.freebsd.org/**SuspendResume,
> users osa and glebius both report on Thinkpad Carbon X1.  They agree that
> suspend and resume work from X (but not console) for '9.0-stable' and
> 'head' respectively.
>
> Sadly, I can't reproduce this on 9.2-RC2: Under X, resume fails to restore
> video.  I don't know whether this is a configuration error on my part, or a
> regression, or the original reports on the wiki were misunderstood. (I do
> reproduce it not working on console.)
>
> Suggestions are welcome, especially from those who report working
> configurations.  Details below, log files at
> http://www.sics.se/~lmfeeney/**9.2-RC2
> .
>
> This is a new machine, with a minimal 9.2-RC2 install from memstick.  X
> and its dependencies are installed from packages via portmaster and hald
> and dbus are enabled, as is ssh.  These are the only packages installed.  X
> is started using startx (with twm) and no xorg.conf.
>
> The kernel is a minimal kernel with no devices complied in and no option
> VESA (see ANKUNGE.config, dmesg, devinfo, pciconf, acpi.)
>
> Suspend appears to work (screen turns off, no ping, power light pulses
> slowly).
>
> On resume, the kernel resumes and if iwn is loaded, I can ssh into the
> machine.  The screen does not resume, not even the backlight. (Looking with
> a flashlight, it doesn't seem to be in any mode.)  The X server seems to
> have exited with error message (see messages, Xorg.0.log), but hald and
> dbus are still running.
>
> Fatal server error:
> EnterVT failed for screen 0
>
> Using debug.bootverbose and debug.acpi.suspend_bounce leaves the backlight
> on, but doesn't restore the screen.  If I ssh into the machine, the X
> server seems still be running (see messages_bouce, Xorg.0.log_bounce).
>
> Loading acpi_video and acpi_ibm modules into the kernel doesn't change the
> behavior. Same is true for i915 module.  (These modules are reported in the
> working configuration info on the wiki.)
>
> The SuspendResume wiki notes that sdhci must be unloaded.  These aren't in
> my minimal kernel, checked by loading and unloading the module).
>
> The old acpi.reset_video=1 option gives kernel panic on resume.
>
> With option VESA in the  minimal kernel, the machine seems to suspend OK.
>  On resume, the backlight comes on and the wlan indicator blinks a couple
> of times.  Otherwise, the machine is unresponsive to both ping and (blind)
> keyboard commands.  The GENERIC kernel has similar behavior.
>
> Thanks for any suggestion -- I really hope it's a configuration error on
> my part,
>
> Laura
> __**_
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/**mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to 
> "freebsd-acpi-unsubscribe@**freebsd.org
> "
>
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Fixing X220 Video The Right Way

[Adrian Chadd]

when did it start working?


-adrian

On 9 August 2013 20:10, matt  wrote:
> hw.acpi.reset_video used to send this machine X220 into a reboot loop,
> with flashing thinklight. Interesting that it no longer causes this
> problem. I kind of paused since the trackpad sucks so much in X.
>
> I think since ssh still works, that just the display or graphics port
> is off.
>
> It may be worth trying to do some acpi_calls via ssh to try to hack
> the display back on...
>
> Matt
>
> On 08/09/13 08:57, John Baldwin wrote:
>> On Friday, August 09, 2013 4:37:50 am Adrian Chadd wrote:
>>> Hi!
>>>
>>> Hm, resurrecting this thread, I'll try this on my X230 tomorrow
>>> and see if it makes the (non-xorg, console only) video work on
>>> resume.
>>>
>>> If it does, what will it take to automatically determine that
>>> this kind of work-around is needed?
>>
>>
>> This does not affect suspend/resume.  It only fixes LCD brightness
>> handling via acpi_video(4).
>>
>
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Lenovo X230 - suspend/resume video issues

[Adrian Chadd]

On 9 August 2013 06:46, John Baldwin  wrote:
> On Friday, August 09, 2013 4:31:07 am Adrian Chadd wrote:
>> Hi,
>>
>> Ignore xorg. Like, just pretend I don't even know it exists. I'm just
>> using syscons. Why isn't the video display resuming?
>
> This is a common issue on my laptops sadly. :(  Some folks have claimed that
> the X220 will resume in single user mode just fine, but mine doesn't have
> video when I do that.
>

Hm, let me dig into that. I vaguely remember that on my T420.



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Lenovo X230 - suspend/resume video issues

[Adrian Chadd]

On 9 August 2013 01:36, Lars Engels  wrote:
> On Fri, Aug 09, 2013 at 01:31:07AM -0700, Adrian Chadd wrote:
>> Hi,
>>
>> Ignore xorg. Like, just pretend I don't even know it exists. I'm just
>> using syscons. Why isn't the video display resuming?
>
> Have you tried setting hw.acpi.reset_video?

Yup. Then resume doesn't work. Like, hitting the button does nothing.



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Fixing X220 Video The Right Way

[Adrian Chadd]

Hi!

Hm, resurrecting this thread, I'll try this on my X230 tomorrow and
see if it makes the (non-xorg, console only) video work on resume.

If it does, what will it take to automatically determine that this
kind of work-around is needed?

Thanks!


-adrian


On 14 June 2013 16:00, matt  wrote:
> On 06/14/13 08:39, John Baldwin wrote:
>
>> I got this to work by using 4 backslashes.  At that point the patch
>> worked. (I recently got access to an X220.)  I get a local APIC
>> error each time I adjust the brightness though (probably the BIOS
>> is doing something wonky).
>>
>
>
> That's awesome! I've asked -CURRENT about the
>
> I tried single quotes, double quotes, double backslash, and I meant to
> try ascii escapes next :)
>
> I'm glad you got this working, it makes the X220 (and probably other
> laptops with similar issues) more usable on FreeBSD.
>
> I'll have to bring my X220 back up to current and start looking at
> sleep issues next.
>
> Matt
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Lenovo X230 - suspend/resume video issues

[Adrian Chadd]

Hi,

Ignore xorg. Like, just pretend I don't even know it exists. I'm just
using syscons. Why isn't the video display resuming?




-adrian

On 8 August 2013 22:34, Kevin Oberman  wrote:
> On Thu, Aug 8, 2013 at 4:00 PM, Adrian Chadd  wrote:
>>
>> Hiya,
>>
>> I have an Lenovo Thinkpad X230 running FreeBSD-10. I'd like some help
>> in sorting out the following issues:
>>
>> * the ACPI and IBM sysctls for twiddling the LCD brightness don't at all
>> work
>> * The backlight comes on during resume, but the video definitely doesn't
>> * I'm still investigating whether xorg actually comes back from resume
>> (and it's a video problem) or whether it hangs on resume.
>>
>> The files are here:
>>
>> http://people.freebsd.org/~adrian/laptop/lenovo_x230
>>
>> Thanks!
>>
>>
>> -adrian
>> ___
>> freebsd-acpi@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
>
>
> Adrian,
>
> Take a look at the thread "Fixing X220 Video The Right Way" in the ACPI ML.
> Also look at "Fixing suspend/resume on Lenovo x220". Both went over several
> months, but ended in mid-June. Whether this aproach will work on the X230 is
> not entirely clear. Use of ACPI_CALL is really a mostly unworkable kludge.
>
> The suspend/resume issues will almost certainly not be resolved on any
> platform with recent Intel or Radeon GPUs requiring KMS until the newcons
> code is committed. That likely won't resolve all issues, but will deal with
> a major one and one that largely blocks resolving (or even identifying)
> others.
>
> I have a T550 which has a BIOS that largely is similar to the X220. One
> issue that Thinkpads of this vintage all seem to have is the inability to
> boot a gpt disk.. (Actually, if you have another drive (even USB) with
> booteasy on it, you can, but BIOS refuses to run an MBR from a GPT formatted
> disk. It assumes that GPT disks are all EUFI, which is seriously broken. I'd
> love to see that this is fixed. Guess I should see if Lenovo has a new BIOS
> that might fix it.
> --
> R. Kevin Oberman, Network Engineer
> E-mail: rkober...@gmail.com
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Lenovo X230 - suspend/resume video issues

[Adrian Chadd]

Hiya,

I have an Lenovo Thinkpad X230 running FreeBSD-10. I'd like some help
in sorting out the following issues:

* the ACPI and IBM sysctls for twiddling the LCD brightness don't at all work
* The backlight comes on during resume, but the video definitely doesn't
* I'm still investigating whether xorg actually comes back from resume
(and it's a video problem) or whether it hangs on resume.

The files are here:

http://people.freebsd.org/~adrian/laptop/lenovo_x230

Thanks!


-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Lenovo X230 - suspend/resume video issues

[Adrian Chadd]

Hiya,

I have an Lenovo Thinkpad X230 running FreeBSD-10. I'd like some help
in sorting out the following issues:

* the ACPI and IBM sysctls for twiddling the LCD brightness don't at all work
* The backlight comes on during resume, but the video definitely doesn't
* I'm still investigating whether xorg actually comes back from resume
(and it's a video problem) or whether it hangs on resume.

The files are here:

http://people.freebsd.org/~adrian/laptop/lenovo_x230


-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Adrian Chadd]

Nope, no such joy.

What else can I try?


-adrian

On 16 July 2013 02:16, Adrian Chadd  wrote:
> I'll try it out soon, thanks!
>
>
>
> -adrian
>
> On 15 July 2013 14:35, Taku YAMAMOTO  wrote:
>> This reminds me of my local patch which I wrote and forgot about deep in
>> the git :)
>>
>> This hack was required to have working USB ports on X61 after resume,
>> but I'm not sure whether it's still required because I don't have X61 handy
>> anymore...
>>
>>
>> On Mon, 8 Jul 2013 11:09:20 -0700
>> Adrian Chadd  wrote:
>>
>>> On 7 July 2013 22:00, Ian Smith  wrote:
>>>
>>> > Checking one more point .. do the USB ports come up ok if you originally
>>> > boot with nothing plugged in?  If so (or if not), does that local APIC
>>>
>>> Yes.
>>>
>>> > error message appear the same then too?
>>>
>>> >
>>>
>>> No
>>>
>>>
>>> -adrian
>>> ___
>>> freebsd-acpi@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>>> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
>>
>>
>> --
>> -|-__   山本　拓 / YAMAMOTO, Taku
>>  | __ < 
>>
>>   - A chicken is an egg's way of producing more eggs. -
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Adrian Chadd]

I'll try it out soon, thanks!



-adrian

On 15 July 2013 14:35, Taku YAMAMOTO  wrote:
> This reminds me of my local patch which I wrote and forgot about deep in
> the git :)
>
> This hack was required to have working USB ports on X61 after resume,
> but I'm not sure whether it's still required because I don't have X61 handy
> anymore...
>
>
> On Mon, 8 Jul 2013 11:09:20 -0700
> Adrian Chadd  wrote:
>
>> On 7 July 2013 22:00, Ian Smith  wrote:
>>
>> > Checking one more point .. do the USB ports come up ok if you originally
>> > boot with nothing plugged in?  If so (or if not), does that local APIC
>>
>> Yes.
>>
>> > error message appear the same then too?
>>
>> >
>>
>> No
>>
>>
>> -adrian
>> ___
>> freebsd-acpi@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
>
>
> --
> -|-__   山本　拓 / YAMAMOTO, Taku
>  | __ < 
>
>   - A chicken is an egg's way of producing more eggs. -
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Adrian Chadd]

On 8 July 2013 11:19, John Baldwin  wrote:

> From sys/amd64/include/apicreg.h:

This system runs an i386 kernel.

> /* fields in ESR */
> #define APIC_ESR_SEND_CS_ERROR  0x0001
> #define APIC_ESR_RECEIVE_CS_ERROR   0x0002
> #define APIC_ESR_SEND_ACCEPT0x0004
> #define APIC_ESR_RECEIVE_ACCEPT 0x0008
> #define APIC_ESR_SEND_ILLEGAL_VECTOR0x0020
> #define APIC_ESR_RECEIVE_ILLEGAL_VECTOR 0x0040
> #define APIC_ESR_ILLEGAL_REGISTER   0x0080
>
> Receive illegal vector (if look in Intel's SDM manuals) means it
> got an interrupt vector < 32 (probably zero).  Perhaps it asserted
> an interrupt in an I/O APIC before the I/O APIC was properly reset?
> Are you using MSI at all?

I think iwn uses MSI. I'm sure other hardware in here does. I can dig
through it and let you know.


-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Adrian Chadd]

On 7 July 2013 22:00, Ian Smith  wrote:

> Checking one more point .. do the USB ports come up ok if you originally
> boot with nothing plugged in?  If so (or if not), does that local APIC

Yes.

> error message appear the same then too?

>

No


-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Adrian Chadd]

Nope, no power after first resume if i have nothing plugged in.

Why?



-adrian

On 7 July 2013 13:49, Lars Engels  wrote:
> On Sun, Jun 30, 2013 at 03:02:57PM -0700, Adrian Chadd wrote:
>> On 30 June 2013 07:22, Ian Smith  wrote:
>>
>> > After removing [numbers] (for WITNESS?), diff started making sense.
>> > The below is between the first and second suspend/resume cycles in
>> > dmesg-3.txt, encompassing the others.
>>
>> Cool!
>>
>> > Nothing of note that I can see, if that usb hub-to-bus remapping is
>> > normal.  As you said, 'CPU0: local APIC error 0x40' looks maybe sus.
>> > Maybe someone who knows might comment on that?
>> >
>> > Just checking: you've tried other USB devices apart from uftdi0?
>>
>> Yup, there's no 5v on the port.
>
> Oh, BTW: can you check if you have power on the ports after the first
> resume and no power after all next resumes until you reboot your
> notebook?
> That's the situation I had and maybe it can lead to something. ;)
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Adrian Chadd]

I don't think it's a USB controller issue.

Those ports are connected to USB hubs, right? I wonder if there's some
ACPI nonsense that's resulting in the hubs not being powered up on
resume.



-adrian

On 7 July 2013 00:32, Hans Petter Selasky
 wrote:
> Hi,
>
> FYI: The USB stack will currently run a complete controller reset upon
> resume, like during boot.
>
> --HPS
>
>
>
> -Original message-
>> From:Ian Smith 
>> Sent: Sunday 7th July 2013 7:52
>> To: Adrian Chadd 
>> Cc: freebsd-acpi@freebsd.org; freebsd-sta...@freebsd.org;
>> freebsd-...@freebsd.org
>> Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume
>>
>> On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote:
>>  > On 30 June 2013 07:22, Ian Smith  wrote:
>> [..]
>>  > > Nothing of note that I can see, if that usb hub-to-bus remapping is
>>  > > normal.  As you said, 'CPU0: local APIC error 0x40' looks maybe sus.
>>  > > Maybe someone who knows might comment on that?
>>
>> Does noone know what that signifies?  Maybe it's not relevant to this.
>>
>>  > > Just checking: you've tried other USB devices apart from uftdi0?
>>  >
>>  > Yup, there's no 5v on the port.
>>
>> I was rather taken aback to hear this.  Would not this indicate a
>> failure to reinitialise the basic underlying USB hardware on resume?
>>
>> More than a bit bemused, Ian
>> ___
>> freebsd-acpi@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
>>
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Adrian Chadd]

On 30 June 2013 07:22, Ian Smith  wrote:

> After removing [numbers] (for WITNESS?), diff started making sense.
> The below is between the first and second suspend/resume cycles in
> dmesg-3.txt, encompassing the others.

Cool!

> Nothing of note that I can see, if that usb hub-to-bus remapping is
> normal.  As you said, 'CPU0: local APIC error 0x40' looks maybe sus.
> Maybe someone who knows might comment on that?
>
> Just checking: you've tried other USB devices apart from uftdi0?

Yup, there's no 5v on the port.



-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Adrian Chadd]

On 27 June 2013 04:58, Ian Smith  wrote:

> Well if there's a functional change in head that fixes this on Lars' and
> yours, getting it into stable shouldn't be so hard I expect.  However if
> there's a fix (or some Lenovo workaround) for yours on 9 it'd be useful
> to hunt it down, no?  I utterly depend on 100% working resume too.
>
> We don't yet know if this is a bus, ACPI &/or USB issue.  Home yet? :)

Yup:

http://people.freebsd.org/~adrian/usb/

dmesg.boot = dmesg at startup

1 - after powerup, usb device in
2 - after acpiconf -s3 suspend/resume, w/ a USB device plugged in
3 - after acpiconf -s3 suspend/resume, with a USB device removed
before suspend/resume

Thanks,


-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Adrian Chadd]

On 26 June 2013 12:51, Lars Engels  wrote:
> On Tue, Jun 25, 2013 at 11:09:20PM -0700, Adrian Chadd wrote:
>> [snip] ok, I'll do a boot -v tonight when I get home and log things.
>>
>> Thanks!
>
> Please also try a recent CURRENT. I was having the same issues with dead
> USB ports on my X200, but IIRC it suddenly worked a few weeks ago.
> Unfotunately with the new X.org resuming doesn't work for me, so I can't
> try it now.

.. having resume not work with xorg is a big, big red flag.

I'm happy to boot a -head snapshot on this thing, but I can't really
migrate to running -head if resume doesn't work. :(



adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Adrian Chadd]

[snip] ok, I'll do a boot -v tonight when I get home and log things.

Thanks!



Adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Adrian Chadd]

On 21 June 2013 05:48, Ian Smith  wrote:

> No acpidump output on -stable or -acpi anyway .. likely best as an URL,
> if it comes down to ACPI.

Ok, I'll put it online in a sec.

> So the fingerprint reader, camera and bluetooth shown in your usbconfig
> don't serve as 'USB devices plugged in' in this regard?  Do they work ok
> after resume, or not?

they work after resume.


> No, the above are still on the suspend path, but logged on resume.  I
> don't know what CDBS or EXP0,1,3,4 are.  You've left out something like
> 'pci0:X:Y:0 Transition from D0 to D2' (or D3) before these ones, right?

Nope, nothing is left out. I can boot with -v to get _all_ of the
messages, if that'll help.


> I hope 'slept' message is still in 10, I've seen a few listed without,
> and they're very handy if there's any resume delay, as I had up to 8.2
> (plus exactly 60 seconds) unless I unloaded (in particular) UHCI and
> reloaded it on resume, needing a kernel w/out uhci, ohci and ehci,
> loading on boot and unload/reload in rc.suspend/resume.  This however
> was fixed by 9.1 for me, the first release where suspend/resume works
> flawlessly on the T23.  I haven't tried a recent 9-STABLE though.

[snip]

> Well, the earlier resume issues on UHCI might still not be fixed?  You
> could try a kernel without UHCI, with the unload/reload dance ..

I just tried that. unloading/reloading uhci doesn't affect things -
the external ports are still powered down after a suspend/resume pass.

Thanks,


Adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

USB ports on Lenovo T400 do not work after a suspend/resume

[Adrian Chadd]

Hi,

FreeBSD-9 works fine on this Lenovo T400 - except that suspending with
no USB devices plugged in result in no ports working after resume.

If I have a device plugged in during suspend - on any port - then all
the ports work fine after resume.

I've attached usbconfig and acpidump output.

here's what is logged in the kernel buffer during suspend and resume:


Her'es the suspend:

Jun 20 14:03:34 lucy acpi: suspend at 20130620 14:03:34
Jun 20 14:03:38 lucy kernel: [100031] uhub0: at usbus0, port 1, addr 1
(disconnected)
Jun 20 14:03:38 lucy kernel: [100036] uhub1: at usbus1, port 1, addr 1
(disconnected)
Jun 20 14:03:38 lucy kernel: ugen1.2:  at usbus1 (disconnected)
Jun 20 14:03:38 lucy kernel: ugen1.3:  at usbus1
(disconnected)
Jun 20 14:03:38 lucy kernel: [100036] ubt0: at uhub1, port 2, addr 3
(disconnected)
Jun 20 14:03:47 lucy kernel: [100041] uhub2: at usbus2, port 1, addr 1
(disconnected)
Jun 20 14:03:47 lucy kernel: [100046] uhub3: at usbus3, port 1, addr 1
(disconnected)
Jun 20 14:03:47 lucy kernel: ugen3.2:  at usbus3 (disconnected)
Jun 20 14:03:47 lucy kernel: [100046] umass0: at uhub3, port 1, addr 2
(disconnected)
Jun 20 14:03:47 lucy kernel: (da0:umass-sim0:0:0:0): lost device - 0
outstanding, 1 refs
Jun 20 14:03:47 lucy kernel: (da0:umass-sim0:0:0:0): removing device entry
Jun 20 14:03:47 lucy kernel: ugen3.3: 
at usbus3 (disconnected)
Jun 20 14:03:47 lucy kernel: uhci_interrupt: resume detect
Jun 20 14:03:47 lucy kernel: [100052] uhub4: at usbus4, port 1, addr 1
(disconnected)
Jun 20 14:03:47 lucy kernel: [100057] uhub5: at usbus5, port 1, addr 1
(disconnected)
Jun 20 14:03:47 lucy kernel: [100062] uhub6: at usbus6, port 1, addr 1
(disconnected)
Jun 20 14:03:47 lucy kernel: [100067] uhub7: at usbus7, port 1, addr 1
(disconnected)

..and resume: I wonder what these devices are?

Jun 20 14:03:47 lucy kernel: [100095] pci21: failed to set ACPI power
state D2 on \_SB_.PCI0.PCI1.CDBS: AE_BAD_PARAMETER
Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power
state D2 on \_SB_.PCI0.EXP0: AE_BAD_PARAMETER
Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power
state D2 on \_SB_.PCI0.EXP1: AE_BAD_PARAMETER
Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power
state D2 on \_SB_.PCI0.EXP3: AE_BAD_PARAMETER
Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power
state D2 on \_SB_.PCI0.EXP4: AE_BAD_PARAMETER
Jun 20 14:03:47 lucy kernel: [100095] acpi0: cleared fixed power button status
Jun 20 14:03:47 lucy kernel: uhci_interrupt: resume detect
Jun 20 14:03:47 lucy kernel: wakeup from sleeping state (slept 00:00:06)

Jun 20 14:03:47 lucy kernel: [100067] uhub0:  on usbus7
Jun 20 14:03:47 lucy kernel: [100046] uhub1:  on usbus3
Jun 20 14:03:47 lucy kernel: [100031] uhub2:  on usbus0
Jun 20 14:03:47 lucy kernel: [100036] uhub3:  on usbus1
Jun 20 14:03:47 lucy kernel: [100057] uhub4:  on usbus5
Jun 20 14:03:47 lucy kernel: [100052] uhub5:  on usbus4
Jun 20 14:03:47 lucy kernel: [100062] uhub6:  on usbus6
Jun 20 14:03:47 lucy kernel: [100041] uhub7:  on usbus2

.. local APIC error?

Jun 20 14:03:47 lucy kernel: CPU0: local APIC error 0x40
Jun 20 14:03:47 lucy acpi: resumed at 20130620 14:03:47

It probes the hubs fine though.

Thanks!



Adrian
ugen0.1:  at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) 
pwr=SAVE (0mA)
ugen1.1:  at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) 
pwr=SAVE (0mA)
ugen2.1:  at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) 
pwr=SAVE (0mA)
ugen3.1:  at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) 
pwr=SAVE (0mA)
ugen4.1:  at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) 
pwr=SAVE (0mA)
ugen5.1:  at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) 
pwr=SAVE (0mA)
ugen6.1:  at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) 
pwr=SAVE (0mA)
ugen7.1:  at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) 
pwr=SAVE (0mA)
ugen3.2:  at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) 
pwr=ON (200mA)
ugen1.2:  at usbus1, cfg=0 md=HOST spd=FULL 
(12Mbps) pwr=ON (100mA)
ugen3.3:  at usbus3, cfg=0 
md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
ugen1.3:  
at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

.. another "it hangs during reboot" data point

[Adrian Chadd]

Hi,

My Lenovo T400 is hanging when I reboot. I'm running a semi-stale (~ 3
month) 9-STABLE. It never used to do this.

I recently rebooted it with the output non-muted. I discovered that
when it hangs, I get a repeating sequence of beeps.

I'm not sure whether those beeps are the ACPI code in FreeBSD, or
whether it's the BIOS during shutdown, or during startup. No idea.

Does anyone have any helpful insights into what beeps mean what these days? :)



Adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"