Fwd: Re: ACPI bug submission
Sorry, PEBKAC error, it appears I've been replying off-list. Please find below my response. It appears that the latest problem is something to do with X as it crashes out when trying to return to the console when pressing Ctrl-Alt-F1 too. Thanks Matt Grice div Original message /divdivFrom: Matt Grice m...@atarian.co.uk /divdivDate:21/04/2014 14:51 (GMT+00:00) /divdivTo: Kevin Oberman rkober...@gmail.com /divdivSubject: Re: ACPI bug submission /divdiv /divThanks for the help Kevin, I'm quite new to FreeBSD. I noticed the sysctl for lid_switch wasn't set, but I just thought it was for information only. man 8 sysctl is my friend. Sleep now works, it just won't wake up. I've debugged this kind of thing before with Linux so I'll plough on from here, I expect I'll just have to work out which systems are shut down at sleep and which ones are restarted afterwards. I've had issues with sound modules doing this kind of thing in the past. I think a serial console might be in order. The battery thing is really odd as it's a virtually new battery, and I wasn't aware there were issues before the install. However, the thing won't charge when it's switched off, which screams HARDWARE! It's probably one of those black swan situations. Thanks again for taking the time out to help. It's really appreciated. Matt Grice On 20/04/2014 16:12, Kevin Oberman wrote: On Sun, Apr 20, 2014 at 2:39 AM, Matt Grice m...@atarian.co.uk wrote: Could you provide the output of: sysctl hw.acpi [root@Raptor] /usr/ports/comms/wspr# sysctl hw.acpi hw.acpi.supported_sleep_state: S3 S4 S5 S3 is suspend to RAM, S4 is suspend to disk, and S5 is shutdown hw.acpi.power_button_state: S5 Power button will do a system shutfown and power off hw.acpi.sleep_button_state: S3 Sleep button will suspend to RAM. Little power use and supported by BIOS with minimal OS support. Works on FreeBSD hw.acpi.lid_switch_state: NONE Closing the lid does nothing in BIOS. Display backlight my turn off, but that's it. hw.acpi.standby_state: NONE If the power management system wants to go to a standby mode, nothing happens. hw.acpi.suspend_state: S3 If a suspend is requested by the OS, suspend to RAM is used hw.acpi.sleep_delay: 1 Delay 1 second for OS to do preparation for suspend to RAM hw.acpi.s4bios: 0 BIOS does not support suspend to disk. OS support is required. FreeBSD does not have this support. 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 Power saving Cx states are NOT enabled. hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 ACPI will update temperature information every 10 seconds hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 39.0C Thermal zone 0 is 39C. This is usually the CPU. 39C is VERY cool. Hopefully it i accurate. hw.acpi.thermal.tz0.active: -1 ACPI is NOT throttling the CPU to control temperature hw.acpi.thermal.tz0.passive_cooling: 0 ACPI is not increasing system cooling capability (usually the fan) to reduce temperature. NOTE: This does not mean non-ACPI controls are not used! hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 95.0C At 95C, turn the cooling (fans) to maximum. hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 98.0C At 98C, throttlethe CPU to reduce temperature hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 0 hw.acpi.thermal.tz0._TC2: 50 hw.acpi.thermal.tz0._TSP: 0 hw.acpi.thermal.tz1.temperature: 39.0C Odd that tz0 and tz1 are both 39C. Seems unlikely. May be different CPU sensor or something else. hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 0 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: -1 hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 98.0C At 98C, power down (if supported). This is different from the hardware shutdown on severe overtemp that simply kills power. hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._TC1: -1 hw.acpi.thermal.tz1._TC2: -1 hw.acpi.thermal.tz1._TSP: -1 hw.acpi.battery.life: 0 hw.acpi.battery.time: -1 hw.acpi.battery.state: 4 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.acline: 1 hw.acpi.video.crt0.active: 0 hw.acpi.video.lcd0.active: 1 hw.acpi.video.lcd0.brightness: 100 hw.acpi.video.lcd0.fullpower: 100 hw.acpi.video.lcd0.economy: 60 hw.acpi.video.lcd0.levels: 100 60 10 20 30 40 50 60 70 80 90 100 If you want the system to suspend when the lid closes, sysctl hw.acpi.lid_switch_state=S3. acpiconf -i 0 [root@Raptor] /usr/ports/comms/wspr# acpiconf -i o Design capacity: 4400 mAh Last full capacity: 3757 mAh Battery is getting old and only will charge to 85% of it's design capacity. Technology: secondary (rechargeable) Design voltage: 11100 mV Capacity (warn):185 mAh Capacity (low): 129 mAh Low/warn granularity: 56 mAh Warn/full granularity: 3572
Re: Fixing X220 Video The Right Way
Not sure that it did :) I tried it once early on, and it concerned me enough I never tried again. It was clearly in a violently erroneous state! At one point, X *could* resume the display. This makes me think the problem is solved via the graphics chip state, but it could be an acpi thing. I can't remember if I ever tried to startx after the resume on the blind console. Matt On 08/09/13 23:00, Adrian Chadd wrote: when did it start working? -adrian On 9 August 2013 20:10, matt sendtom...@gmail.com 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: Resume on a Thinkpad L512
Try kldunloading any loaded kernel modules including usb. You may need to compile a more modular kernel. Does suspend/resume work for anyone? Matt On 06/28/13 15:19, Stefan Horomnea wrote: Yes, I did try, didn't help. On Mon, Jun 24, 2013 at 4:30 AM, matt sendtom...@gmail.com wrote: which I think are after I manually power-off and power-on the laptop. If this info helps, Ubuntu is able to suspend/resume properly. I also did a recent upgrade of BIOS. Can anyone help me make progress here ? Thank you, Stefan ___ 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 Have you tried twiddling the values at hw.pci.do_power_resume and hw.pci.do_power_suspend? Rarely, this helps. 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: Resume on a Thinkpad L512
which I think are after I manually power-off and power-on the laptop. If this info helps, Ubuntu is able to suspend/resume properly. I also did a recent upgrade of BIOS. Can anyone help me make progress here ? Thank you, Stefan ___ 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 Have you tried twiddling the values at hw.pci.do_power_resume and hw.pci.do_power_suspend? Rarely, this helps. 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: Fixing X220 Video The Right Way
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: Fixing suspend/resume on Lenovo x220
On 06/13/13 07:16, John Baldwin wrote: Interesting, I connected a serial console via AMT but wasn't able to get any output during resume. Is this with a stock kernel? I think if X is loaded or certain USB peripherals are attached it quietly panics at resume. You'll note that we are sending D3 to the USB bridges, which complain loudly before suspend is complete...I think in the hackintosh world, they are using a custom DSDT that prevents that or something to allow OS X to resume. 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: Thinkpad x230 acpi_ibm
On 04/25/13 10:46, Matthew Gibson wrote: I updated to 9-stable and now the acpi_ibm sysctl tree is created. Only a few of them seem to work. There are some that could work but have different handles in the Lenovo ACPI vs IBM. For instance, there are per-interface RFKILLs in the X220 ACPI that aren't really exposed in our acpi ibm, among others (kills for GPS, WWAN, and I think WiMAX). I was hacking on this and the brightness, had to put it down for a moment. I might get a chance to look at some of this stuff later today. The brightness control will not work, as far as I know on Linux their thinkpad acpi driver skips its own brightness controls on these models in favor of ACPI control. So far I was able to make a patch for acpi_video that does work (the wrong way, by using \_SB.PCI0.VID for attach, but making the brightness calls to \_SB.PCI0.PEG.VID) and was testing a patch from John Baldwin to see if I could get acpi_video to attach directly to the PEG device. 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: Thinkpad x230 acpi_ibm
On 04/24/13 09:46, Matthew Gibson wrote: Hello, I have a thinkpad x230. I have some of the issues others on this mailing list have discussed, such as no brightness controls, and some of the special buttons don't work. I have some experience with freebsd, but not a lot. I am running 9.1-RELEASE (r243825) on amd64. The main issue is similiar to http://lists.freebsd.org/pipermail/freebsd-acpi/2011-July/007227.html If I load the acpi_ibm module, it shows up in kldstat, but no message is given on the dmesg, and nothing appears in sysctl. Any help is appreciated. the volume buttons work, the speaker and microphone mute doesn't work. The brightness fn keys don't work. Also the power button doesn't seem to initiate a shutdown, even though I have hw.acpi.power_button_state: S5 Matthew ___ 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 . Aside from scripts (which work great on X220), we need to figure out what is wrong with Lenovo and what is wrong with acpi_video and get them to meet in the middle. I've had marginal success rewriting acpi_handles for just the brightness methods, but basically Lenovo has some weird acpi locations that don't seem to work, or need a trapdoor we're not doing. Usually one does work, but acpi_video doesn't attach to the working ones. 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: Fixing X220 Video The Right Way
On 02/28/13 09:09, John Baldwin wrote:
On Thursday, February 28, 2013 8:15:46 am matt wrote:
On 02/27/13 12:27, John Baldwin wrote:
On Wednesday, February 27, 2013 1:35:43 pm matt wrote:
On 02/27/13 09:00, John Baldwin wrote:
If that is true, it's because your BIOS is lying. Do you have a URL to
your ASL lying around already?
Too big for pastebin :( +500k
https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing
Here is where I find _DOD and _DOS methods:
Device (PCI0)
Device (VID)
Name (_ADR, 0x0002) // _ADR: Address
Method (_DOS, 1, NotSerialized) // _DOS: Disable Output
Switching
Method (_DOD, 0, NotSerialized) // _DOD: Display Output
Devices
Device (PEG)
Name (_ADR, 0x0001) // _ADR: Address
Device (VID)
Name (_ADR, 0x00) // _ADR: Address
Method (_DOS, 1, NotSerialized) // _DOS: Disable
Output Switching
Method (_DOD, 0, NotSerialized) // _DOD: Display
Output Devices
PCI0.VID is a PCI device at pci0:0:2:0.
PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0.
It would have a child device at 0:0 that would be PCI0.PEG.VID. Does the
X220
have a switchable GPU (e.g. it has built-in Intel graphics, but also has an
Nvidia GPU or some such?). If so, I imagine that PCI0.VID is the Intel
graphics
and PEG is the non-Intel. The output of 'pciconf -lcv' would be useful to
determine
that. If both PCI devices exist you shoudl have both acpi_video0 and
acpi_video1.
However, it may be that the acpi_video driver doesn't cope well with having
multiple
devices.
Only Intel graphics, there is no option for switchable graphics.
I initially thought that PEG was for Optimus usage, and left in the bios
by accident (i.e. Lenovo using a generic DSDT for many machines)
Here is pciconf -lcf, truncated
hostb0@pci0:0:0:0:class=0x06 card=0x21da17aa chip=0x01048086
rev=0x09 hdr=0x00
vendor = 'Intel Corporation'
device = '2nd Generation Core Processor Family DRAM Controller'
class = bridge
subclass = HOST-PCI
cap 09[e0] = vendor (length 12) Intel cap 0 version 1
vgapci0@pci0:0:2:0:class=0x03 card=0x21da17aa chip=0x01268086
rev=0x09 hdr=0x00
vendor = 'Intel Corporation'
device = '2nd Generation Core Processor Family Integrated
Graphics Controller'
class = display
subclass = VGA
cap 05[90] = MSI supports 1 message enabled with 1 message
cap 01[d0] = powerspec 2 supports D0 D3 current D0
cap 13[a4] = PCI Advanced Features: FLR TP
none0@pci0:0:22:0:class=0x078000 card=0x21da17aa chip=0x1c3a8086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
As you can see there is no device at pci0:0:1:0. So no dev_t with for
acpi_video to probe or attach to.
Nonetheless, only PEGs ACPI methods work, which is quite broken. This is
true for a large number of Lenovo devices, back to x61 (non-attaching
AGP adr) and probably including some other x series and t series.
Unfortunately the ASL will not compile which makes fixing the DSDT an
exercise in fixing broken ACPI.
What I find interesting is that as far as I can tell, there's no special
case handling for this device in Linux, yet backlight controls work out
of the box since about 3.0. Installing Linux as the OSI via loader.conf
is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows
2009 (/WIN7). I get correct (for platform) behavior when I call PEGs
_BCM... :(
Is Linux getting this to work by doing it wrong, essentially?
Yes. I think the best way to fix this is to add a way to specify a
hint to override the ACPI path associated with a PCI device. Something
like:
hw.pci0.0.2.0.handle=\_SB_.PCI0.PEG.VID
I think this patch should do the trick:
Index: sys/dev/acpica/acpi_pci.c
===
--- acpi_pci.c(revision 247320)
+++ acpi_pci.c(working copy)
@@ -264,6 +264,40 @@ acpi_pci_save_handle(ACPI_HANDLE handle, UINT32 le
return_ACPI_STATUS (AE_OK);
}
+static void
+acpi_pci_override_handles(device_t dev)
+{
+ struct acpi_pci_devinfo *dinfo;
+ device_t *devlist;
+ int error, i, numdevs;
+ char tunable_name[64], *path;
+ ACPI_HANDLE handle;
+
+ error = device_get_children(dev, devlist, numdevs);
+ if (error)
+ return;
+ for (i = 0; i numdevs; i++) {
+ dinfo = device_get_ivars(devlist[i]);
+ snprintf(tunable_name, sizeof(tunable_name),
+ hw.pci%d.%d.%d.%d.handle, dinfo-ap_dinfo.cfg.domain,
+ dinfo-ap_dinfo.cfg.bus, dinfo-ap_dinfo.cfg.slot,
+ dinfo-ap_dinfo.cfg.func);
+ path = getenv(tunable_name);
+ if (path
Re: Fixing X220 Video The Right Way
On 02/25/13 10:30, John Baldwin wrote: Is there a better place to correct the ACPI_PATH that gets stored in vgapci's ivar? Is there already a tunable I can use to fix this? vgapci's ivar is set by the PCI address. Do you have multiple vgapci devices? No, just one. I think that the DSDT is very creative on recent Lenovos (read: broken). There are multiple video devices defined, with functional calls that nonetheless don't work to actually do anything. The acpi_get_handle() call in acpi_video returns a handle that has no active outputs and doesn't have any control over the brightness. The other path can control brightness. Here's a related discussion on Linux, I'm not sure how much applies other than the situation discussed: http://comments.gmane.org/gmane.linux.acpi.devel/57228 The same thing happens on AGP thinkpads, I believe, based on Mitsuru Iwasaki's comment a long time ago to an X220 thread. 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: what is required to support a new laptop?
On 02/25/13 14:27, Eitan Adler wrote: Tried randomly guessing path names, but nothing resulted in anything but Unknown object type '0' I don't know how to read the ASL, what other paths are likely to work? The SCOPE sections set the base path for the devices in a block, so if you find device vga, scroll up and you'll Replace * with _BCL then _BCM -i value in bcl results (the bcl results are kind of readable in hex) _SB.PCI0.PEG0.VGA.LCD.* _SB.PCI0.PEG1.VGA.LCD.* _SB.PCI0.GFX0.DD02.* Are all I can find. There might be another issue than the thinkpad one at play if none work. All the BCMs call the AINT method (which I hope doesn't stand for AINT GONNA WORK :) ) They all are shell functions for the one under GFX0 (which also has a bunch of thermal checks, maybe it's the best bet). One other method to try is this LVLS method under any of the above...it is involved in transforming the incoming level to ec-values I think? 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: Fixing X220 Video The Right Way
On 02/25/13 18:33, Adrian Chadd wrote: [101232] acpi_video0: ACPI video extension on vgapci0 found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 And what do I do with acpi_get_handle ? I threw printfs into acpi_video, not sure if that would work for both vgapci or not. I'm not sure if I wiped out my debug patches yet, I may have a patch. Basically the idea is to figure out which paths in the DSDT are getting attached to the vgapci devices. This dsdt patch from Mitsuru Iwasaki illustrates fixing a similar issue to X220 via a custom dsdt http://people.freebsd.org/~iwasaki/acpi/tpx61.asl.diff http://people.freebsd.org/%7Eiwasaki/acpi/tpx61.asl.diff It seems like we could either try to find these paths on affected models, or have a tunable override for acpi_video. 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
Fixing X220 Video The Right Way
I am working on fixing acpi_video for X220. My X220 is back to FreeBSD land, and I always felt \VBRC calls were dirty. So I've set out to fix acpi_video to work naturally, as it does in linux land. Background: Lenovo laptops boot in a mode where the brightness keys automagically work, under BIOS/EC control. This gets blown away (for us) shortly after Kernel attach. At this point, the acpi method \NBCF will return 0, which means acpi cannot control video brightness. Once we touch the _BCL method on the video output (even inactive ones), \NBCF returns 1 and will allow acpi control. You may remember that acpi_video records some brightness value that changes with keypresses, but does not work on X220. Current status: If I modify acpi video to attach to \_SB.PCI0.PEG.VID, brightness works via sysctl but not keypress (\NBCF = 1) If I leave that alone, but just redirect the brightness set function to \_SB.PCI0.PEG.VID.LCD0._BCM, the keyboard works That is obviously a hack, but it indicates something is going on here. I think that get_acpi_handle() on the X220 vgapci is returning the wrong ACPI_HANDLE. Perhaps this is why the screen stays off when resume used to work? Obviously it can be fixed by hard coding this path into acpi_video, but I feel like that is definitely the wrong way. A tunable for an acpi_video override might be useful, but it still leaves potentially the wrong path in vgapci's IVARs. Is there a better place to correct the ACPI_PATH that gets stored in vgapci's ivar? Is there already a tunable I can use to fix this? Thanks! 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: what is required to support a new laptop?
On 01/29/13 10:24, Ian Smith wrote:
On Tue, 29 Jan 2013 12:46:43 -0500, Eitan Adler wrote:
On 29 January 2013 12:29, Ian Smith smi...@nimnet.asn.au wrote:
Ah right. I don't suppose kldload -v shows anything useful about the
problem loading it? Ah, never mind, it may be obvious .. lightly
skimming your asl.y530.gz, I recalled folks having to patch something
for Lenovo rather than IBM OEMIDs .. hunt, hunt .. ok, here it is:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164538
This is after the install of a patched acpi_ibm
[3500 root@gravity /usr/src/sys/modules/acpi ]#kldload -v acpi_ibm
Loaded acpi_ibm, id=12
Which looks maybe successful, on the face of it? ..
[5507 eitan@gravity (100)% ~ !1!]%sysctl dev.acpi_ibm
sysctl: unknown oid 'dev.acpi_ibm'
.. but clearly wasn't.
The Y series doesn't have the HKEY stuff, or it's not the same. You want
acpi_video (as does every new Lenovo, thinkpad or not).
The problem is Lenovo is putting the correct _BCL/_BCM under PEG
devicessection from your dsdt follows, temporary workaround test
after that
Device (LCD)
{
Method (_ADR, 0, NotSerialized)
{
Return (0x0110)
}
Method (LVLS, 1, NotSerialized)
{
Store (One, Local0)
Store (Zero, Local1)
If (LEqual (OSYS, 0x07DC))
{
Store (0x14, Local5)
Store (PLV2, Local6)
}
Else
{
Store (0x0F, Local5)
Store (PLVL, Local6)
}
While (Local0)
{
Add (Local1, 0x02, Local2)
Store (DerefOf (Index (Local6, Local2)), Local3)
And (Arg0, 0xFF, Local4)
If (LEqual (Local4, Local3))
{
Store (Zero, Local0)
}
Subtract (Local3, One, Local3)
If (LEqual (Local4, Local3))
{
Store (Zero, Local0)
}
If (LGreaterEqual (Local1, Local5))
{
Store (Zero, Local0)
}
If (Local0)
{
Add (One, Local1, Local1)
}
}
Return (Local1)
}
Method (_BCL, 0, NotSerialized)
{
If (LNotEqual (OSYS, 0x07DC))
{
Return (PLVL)
}
Else
{
Return (PLV2)
}
}
Method (_BCM, 1, NotSerialized)
{
If (IGDS)
{
Store (GFX0.DD02.LVLS (Arg0), Local1)
Store (Local1, LPCB.EC0.BRTS)
GFX0.AINT (One, Arg0)
}
Else
{
Store (LVLS (Arg0), Local1)
Store (Local1, LPCB.EC0.BRTS)
}
Store (Arg0, BRTL)
}
Method (_BQC, 0, NotSerialized)
{
Return (BRTL)
}
}
}
}
This would be under _SB.PCI0.PEG0.VGA
Try acpi_call -p '\_SB.PCI0.PEG0.VGA.LCD._BCL'
then
acpi_call -p '\_SB.PCI0.PEG0.VGA.LCD._BCL' -i 50
Experiment with the numbers.
We need to fix acpi_video so it attaches to the correct _BCL on these
laptops.
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: what is required to support a new laptop?
On 02/24/13 17:04, Eitan Adler wrote: On 24 February 2013 19:57, matt sendtom...@gmail.com wrote: On 01/29/13 10:24, Ian Smith wrote: On Tue, 29 Jan 2013 12:46:43 -0500, Eitan Adler wrote: On 29 January 2013 12:29, Ian Smith smi...@nimnet.asn.au wrote: Ah right. I don't suppose kldload -v shows anything useful about the problem loading it? Ah, never mind, it may be obvious .. lightly skimming your asl.y530.gz, I recalled folks having to patch something for Lenovo rather than IBM OEMIDs .. hunt, hunt .. ok, here it is: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164538 This is after the install of a patched acpi_ibm [3500 root@gravity /usr/src/sys/modules/acpi ]#kldload -v acpi_ibm Loaded acpi_ibm, id=12 Which looks maybe successful, on the face of it? .. [5507 eitan@gravity (100)% ~ !1!]%sysctl dev.acpi_ibm sysctl: unknown oid 'dev.acpi_ibm' .. but clearly wasn't. The Y series doesn't have the HKEY stuff, or it's not the same. You want acpi_video (as does every new Lenovo, thinkpad or not). The problem is Lenovo is putting the correct _BCL/_BCM under PEG devicessection from your dsdt follows, temporary workaround test after that ... This would be under _SB.PCI0.PEG0.VGA Try acpi_call -p '\_SB.PCI0.PEG0.VGA.LCD._BCL' then acpi_call -p '\_SB.PCI0.PEG0.VGA.LCD._BCL' -i 50 Experiment with the numbers. We need to fix acpi_video so it attaches to the correct _BCL on these laptops. Unknown object type '4' regardless of what number is passed to -i. Same with the first call. I made a typo :( Change the second call from _BCL to _BCM. The first call _BCL would trapdoor a thinkpad, and it returns an unknown object type 4. Acpi call has some formatting options to display this object, it's usually (or should be) a list of valid backlight levels. The second call should set the value. _BQC will return the current value. If that does not work, also try replacing PEG0 with PEG1. 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: what is required to support a new laptop?
On 02/24/13 17:29, Eitan Adler wrote: [5398 root@gravity (100)% ...ts/sysutils/acpi_call !5!]#acpi_call -p '\_SB.PCI0.PEG1.VGA.LCD._BQC' -o o 0 [5399 root@gravity (100)% ...ports/sysutils/acpi_call ]#acpi_call -p '\_SB.PCI0.PEG0.VGA.LCD._BQC' -o o 0 [5389 root@gravity (100)% ...ports/sysutils/acpi_call ]#acpi_call -p '\_SB.PCI0.PEG1.VGA.LCD._BCM' -i 50 50 [5390 root@gravity (100)% ...ports/sysutils/acpi_call ]#acpi_call -p '\_SB.PCI0.PEG1.VGA.LCD._BCM' -i 20 20 but nothing visible changes. This is better than before (I think). Thanks! I hope this could work in the end. Next step is to call _BCL then _BCM at every location in the DSDT and see if any of them work. It's probable that one of them does... Lenovo seems to like playing hide the correct acpi methods or something. 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: Acer Aspire One 753 Netbook: ACPI or Sandy Bridge Problem
On 12/18/12 09:53, Master One wrote: - CPU fan goes to maximum after booting - shutdown -p now completes the shutdown process, turns off the screen, but does not turn off the computer - reboot completes the shutdown process, but gets stuck at the line usbus1: Controller shutdown complete for about 30 seconds before it finally reboots - zzz does some USB related disconnecting and then just hangs This sounds like a misbehaving USB device. Disable all peripherals in the BIOS if possible (webcam, fingerprint if present, whatever other junk) And unplug this: uhub3: vendor 0x8087 product 0x0020, class 9/0, rev 2.00/0.00, addr 2 on usbus1 uhub3: 8 ports with 8 removable, self powered ugen1.3: Sonix Technology Co., Ltd. at usbus1 Then give it another try. I don't see anything that screams ACPI problem so much as a device that times out a lot, leaving the kernel waiting. Just a guess though. 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: Sleep/resume in FreeBSD 9 on a ThinkPad
On 11/12/12 23:13, Stefan Horomnea wrote: Hi, I have tried with 1 and then 0 to both settings (hw.pci.do_power_suspend and hw.pci.do_power_resume) but with no luck, it does the same. What happens is, after executing the sleep command, I hear a short beep, the power button blinks rapidly three times, and then monitor, hdd, stop, and the power button pulses as you say, at a slow pace, like it went to sleep. But when I wake it, it reboots. Thanks for your suggestion anyway. Any other suggestions ? Stefan On Mon, Nov 12, 2012 at 6:12 PM, matt sendtom...@gmail.com wrote: That sounds quite odd...unfortunately I think the L series is only cosmetically similar to the SL series. I gave it away, so I can't test with it anymore to see if it's a recent change. Try debug.acpi.suspend_bounce=1 and try to suspend. This will either work with no problems, work with a lot of kernel printf errors, or reboot. I think the result of that would be interesting. Try debug.acpi.resume_beep=1 (with suspend_bounce cleared) and try again...does it beep before rebooting? With my SL410, I also went into the bios and disabled everything I didn't use (although it didn't help). You could also try sending power_off to usb devices manually with usbconfig, and setting hw.pci.do_power_nodriver=3 debug.acpi.reset_video actually caused a similar problem for me on my x220, so make sure it's off as well (I doubt you have it on, but it's worth a mention given the symptoms) 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: x220 notes
On 10/10/12 19:44, Erich Dollansky wrote: Hi, On Wed, 10 Oct 2012 16:26:58 -0700 Любомир Григоров nm.kn...@gmail.com wrote: Hi, I am now running 10 HEAD with latest committed KMS patch. I must admit that I did not update this machine since some time. I do not use currently suspend and resume on my X220. I use a script for the brightness which makes it easy to handle for me. I am still stuck with: - add LEN0086 to acpi_ibm - recompile - kldload acpi_call - acpi_call -p '\VBRC' -i n// n is 0-16 Can you share the script you have made, especially if you were able to bind hotkeys to it? The scripts are still available here http://www.alogreentechnologies.com/freebsd/XonX220 http://www.alogreentechnologies.com/freebsd/setbrightness I never tried to bind the script to keys. I made some menu items in blackbox which works for me. There is a fundamental problem with powerd which stops a notebook to get better battery life time. powerd does not include the display brightness and it does not inlcude user activities in its process to regulate the CPU speed. In addition, the algorithm to find the best CPU speed gets easily irritated with short bursts of peak performance requirements. Erich I do lose about 1-2 hours of battery time as opposed to Windows(I get 7-8 hours there) due to those same bursts of performance, despite running the adaptive profiles. My main concern is manual control of brightness though. You lose only 1-2h? I lose at least 2h. I have had several tries to make it better but got always held up by other things. My last attempts have still been with the Crusoe CPU. They gave the machine near XP battery times but needed manual interaction. So, I never published them. Erich You've swapped the X220 cpu for something? Or a different machine? I find X does horrible things to battery usage on my X220. Getting into the lowest C state, and disabling ALL of the USB devices helps somewhat, as does setting a lower backlight level at boot (you can make an rc script, or catch the backlight buttons while the bios is still loading). 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: [CFT] acpi_ibm event handler
On 06/17/12 11:07, Mitsuru IWASAKI wrote: Hi, Brightness can be adjusted using acpi_call -p '\VBRC' -i n (where n is 0-15). acpi_call must be installed from ports. But this command sets absolute brightness, so it can't raise or lower the brightness unless you have the current value and I don't know how to get that. This is the case on my T520. X61 has the same problem. There are 2 video device object in ACPI namespace, \_SB.PCI0.VID (vgapci attached but brightness control doesn't work) and \_SB.PCI0.AGP.VID (has VBRC method but no driver attached because of wrong _ADR). The custom DSDT with the following patches and acpi_video(4) now can adjust brightness level :) http://people.freebsd.org/~iwasaki/acpi/tpx61.asl.diff If you want to make the custom DSDT, I can help you. Thanks! ___ 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 Would you be interested in seeing the X220 DSDT? It does sound similar, and you sound like you can make sense of the Lenovo/IBM ACPI branches...I think X220 has hooks for Nvidia optimus that are getting in the way, or some trapdoor function needs to be called to tell ACPI we're using the onboard intel (There is no Nvidia X220, but it looks like ACPI thinks there is). 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: How can I help with thinkpad x220 issues?
On 06/28/12 03:08, Natacha Porté wrote: Hello, on Wednesday 27 June 2012 at 07:38, Erich Dollansky wrote: I have also an X220. My experience differs a bit. Would you have any idea about why you see a better behavior? I'm using a 9-STABLE with only LEN0086 addition and Intel_GPU patches form CURRENT. Could it be caused by new developments in CURRENT? Or have you modified or configured something? Would you have any idea on what can be done to further diagnose such differences in behavior? For the reference, in case it might help, here are some relevant sysctl: $ sysctl hw.acpi hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: NONE hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 1 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 55.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 99.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 hw.acpi.battery.life: -1 hw.acpi.battery.time: -1 hw.acpi.battery.state: 7 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.acline: 1 $ sysctl dev.acpi_ibm dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=LEN0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 134217727 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 1144 dev.acpi_ibm.0.lcd_brightness: 0 dev.acpi_ibm.0.volume: 0 dev.acpi_ibm.0.mute: 0 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 2929 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.fan: 1 Thanks for your help, Natacha Porté ___ 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 It's possible you have a crashed EC or need a bios update, a lot of that stuff seems wrong. If the EC is crashed, the fix used to be removing battery, holding power button for 10 seconds and reinstalling battery...I usually see this stuff on Macbooks, but, I suppose it's possible the EC is in an unplanned state and thus has corrupted some values...many of the ACPI calls query the EC. It's also possible you are running an old bios? Trying to get a few things to work, I had the latest bios on my x220...never had problems with the power button. 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: Resume failed after Suspend on Thinkpad x201i
On 07/02/12 02:29, 乔楚/HonestQiao wrote: Follow by step in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html #sysctl debug.bootverbose=1 #sysctl debug.acpi.suspend_bounce=1 #acpiconf -s 3(or push Fn+F3) After a moment, the display is light and black, LED Sleep is light. But it cant be resume. No button can do resume. Some useful info: hw.acpi : http://pastebin.com/zknEPdVS acpidump : http://pastebin.com/uH4hXywR dmesg : http://pastebin.com/wdqi7mfW In /var/log/message: http://pastebin.com/fcWKMUd7 Jul 2 16:43:22 x201i acpi: suspend at 20120702 16:43:22 [It Can't resume, so I push power force to close my x201. ] Jul 2 16:52:11 x201i syslogd: kernel boot file is /boot/kernel/kernel #uname -a FreeBSD x201i.honestqiao 9.0-STABLE FreeBSD 9.0-STABLE #0: Wed Jun 13 22:36:36 CST 2012 root@x201i.honestqiao:/usr/obj/usr/src/sys/GENERIC amd64 #vmstat -i interrupt total rate irq1: atkbd0 16 0 irq9: acpi0 727 4 irq19: ehci1 338 2 irq23: ehci0 255 1 cpu0:timer 7607 50 irq264: em0 135 0 irq265: hdac0 66 0 irq266: iwn0 15781105 irq267: ahci0 5732 38 cpu1:timer 1578 10 cpu3:timer 1819 12 cpu2:timer 1510 10 irq268: vgapci03 0 Total 35567237 #kldstat Id Refs AddressSize Name 1 85 0x8020 1301fa8 kernel 21 0x81502000 2087f0 zfs.ko 32 0x8170b000 5c68 opensolaris.ko 42 0x81711000 484e0linux.ko 51 0x8175a000 f4d8 aio.ko 61 0x8176a000 29e0 coretemp.ko 71 0x8176d000 3028 amdtemp.ko 81 0x81771000 27398drm.ko 91 0x81799000 ba40 mmc.ko 101 0x817a5000 4218 mmcsd.ko 121 0x817b 6568 cuse4bsd.ko 131 0x817b7000 de08 tmpfs.ko 143 0x817c5000 8ab0 libiconv.ko 151 0x817ce000 24c8 libmchain.ko 161 0x817d1000 11c8 cd9660_iconv.ko 171 0x817d3000 11e0 msdosfs_iconv.ko 181 0x817d5000 10768cpufreq.ko 191 0x817e6000 59b8 acpi_ibm.ko 201 0x817ec000 6668 sem.ko 211 0x81a12000 15c2 fdescfs.ko 221 0x81a14000 3dfd linprocfs.ko 231 0x81a18000 a9bb fuse.ko 241 0x81a23000 5f7b7i915kms.ko 251 0x81a83000 123d iicbb.ko 264 0x81a85000 12ff iicbus.ko 271 0x81a87000 dc9 iic.ko 281 0x81a88000 2be29drm2.ko #sysctl dev.acpi_ibm dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 134217727 dev.acpi_ibm.0.events: 1 dev.acpi_ibm.0.eventmask: 134217727 dev.acpi_ibm.0.hotkey: 388 dev.acpi_ibm.0.lcd_brightness: 0 dev.acpi_ibm.0.volume: 7 dev.acpi_ibm.0.mute: 0 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 3265 dev.acpi_ibm.0.fan_level: 2 dev.acpi_ibm.0.fan: 0 -- ___ 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 Try setting hw.pci.do_power_resume and hw.pci.do_power_suspend to 0, then try each at 1, then try both at 1. Many times Thinkpads fail to resume because of something import getting turned off that needs to be on during suspend, or by trying to turn on things that don't like that during resume. Almost all my thinkpads have required some combo of the above settings. Also, try these tests in single user, to rule out some 3rd party kernel modules you have there. Matt ___ 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: Unable to resume amd64 machine
On 06/26/12 04:18, Gustau Pérez i Querol wrote: Hi, it seems there was some problem when I posted this one. Sorry if it shows two times in the mailing list. I've trying to suspend/resume an amd64 machine. The machine is a fujitsu S710 laptop running: FreeBSD 10.0-CURRENT #4 r237339=e61ad3a-dirty: Sat Jun 23 17:12:58 CEST 2012 I did the tests in the following conditions: - No X loaded. Everything in console. The machine has an Intel video card, but the i915kms wasn't there. - When removing modules, I tried in single user mode. The behavior is basically the machine seems to suspend fine (I see the power led blinking) but when resuming it freezes hard. I see the disk spinning for a while and then it stops. I can't ssh to it, I can't use the keyboard at all so I can issue no command at all. I've tried stripping down the kernel (everything is out except if_ath, em and usb stack). No pccard, no sdhci, no sound, no cuse4bsd, no usb hid devices (I'm using uhidd for hid devices), no acpi_video or acpi_fujitsu there but the same result. I tried enabling debug.acpi.resume_beep=1. When doing this, the laptop beeped like crazy. With sysctl debug.acpi.suspend_bounce=1, the suspend put the screen blank, however the machine stayed alive. With acpi.reset_video I got no result. I tried using the serial console on the laptop. I saw the suspend process taking down some usb devices. Resume showed nothing on the serial console. Disabling devices in the BIOS (removing wifi, bluetooth, webcam, etc ...) didn't bring me further. Thanks This could be similar to thinkpads, see my response to Honest Qiao's X201... Here's the short version: In single user, set hw.pci.do_power_resume=0 and hw.pci.do_power_suspend=0 Try suspend bounce (and if successful suspend) with suspend beep sysctl on. If that fails (either bounce or full suspend) try just hw.pci.do_power_resume=1 repeat test (bounce then full suspend) If that fails (either bounc or full suspend) try just hw.pci.do_power_suspend=1 repeat test (bounce then full suspend) I recommend testing laptop with SSH or some other screenless way of seeing if it resumed, as onboard graphics can be tricky these days. Matt 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: Brightness keys and booting the kernel
On 05/01/12 10:13, Nikolay Tychina wrote: Considering the fact that brightness keys work until kernel is loaded, is it possible to make them work after the kernel is booted in some simple way? I remember my previous laptop was able to control brightness without any acpi_* modules and disregarding OS running. What make and model laptop? What OS? (this one, and the previous?) % head -24 /var/run/dmesg.boot should provide a clue or two. cheers, Ian This is Samsung RV511-S02 which runs FreeBSD 9-RELEASE, previous was Acer Aspire 5520G running FreeBSD 8-STABLE until it burned away in 2010, and I couldn't find dmesg for it. Regards ACPI set debug layer 'ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS' level 'ACPI_LV_ERROR' Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #1: Thu Feb 23 18:33:29 MSK 2012 nicholas@rv511:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz (2527.05-MHz K8-class CPU) Origin = GenuineIntel Id = 0x20655 Family = 6 Model = 25 Stepping = 5 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x9ae3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3940532224 (3757 MB) Event timer LAPIC quality 600 ACPI APIC Table:PTLTDAPIC FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 5 ___ 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 I know that Thinkpads (obviously not the same but the information may be useful) start in BIOS mode, where acpi does not handle most hotkeys, brightness etc. So the brightness keys work. As soon as acpi attaches, however, it trapdoors into ACPI mode, where it expects Windows or Linux drivers to handle hotkeys and call either acpi video extensions or other ACPI methods to initiate display changes and brightness. Have you tried using the acpi_video module? The reason it works during early kernel and prior on Thinkpads is due to the fact it hasn't been trapdoored into ACPI mode yet. 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: x220 notes
On 04/04/12 22:46, Любомир Григоров wrote: A couple more things. Fan control doesn't work and returns unknown oid 'dev.acpi_ibm.0.fan'. I didn't find LEN0068, but IBM0068 there. I still don't know if acpi_ibm.c was updated since you first wrote the topic. One other thing is I want to disable the touchpad. It is way too sensitive and I cannot use the lower buttons at all. The cursor keeps moving. xf86-input-synaptics is installed. -- Lyubomir Grigorov (bgalakazam) Yes, edit IBM0068 to LEN0068 as noted a while back...it will attach then. The lower touchpad is nuts...I haven't looked at it too much, but telling psm to recognize a synaptics didn't work when I added it to loader.conf... 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: x220 notes
On 04/05/12 09:35, Любомир Григоров wrote: I just disabled from UEFI/BIOS. I don't use it that much anyway, but it was annoying when it moved when I typed. I can just rebuild acpi_ibm.c without world right? Yes, edit IBM0068 to LEN0068 as noted a while back...it will attach then. The lower touchpad is nuts...I haven't looked at it too much, but telling psm to recognize a synaptics didn't work when I added it to loader.conf... Matt -- Lyubomir Grigorov (bgalakazam) Yes, it should be possible if your sources are in synchronization with world/kernel. Just make the edit and go to /usr/src/sys/modules/acpi/acpi_ibm and type make make install You'll notice that fan speed becomes something ugly after trying to set brightness, but everything will work otherwise as far as I have tested. I have found that the machine gets quite hot on its own especially with turbo core on the i7 and heavy usage, even with power tuning. Adjusting fan speed could be dangerous, I would certainly keep a close eye on temperatures during something like buildworld to be sure. I think the brightness ec address could be wrong in acpi_ibm, leading to corrupting the fan speed value, but that is conjecture. 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: x220 notes
On 04/05/12 18:33, Любомир Григоров wrote: Hey Matt, a couple of things, since I am experiencing a different situation Yes, it should be possible if your sources are in synchronization with world/kernel. Just make the edit and go to /usr/src/sys/modules/acpi/acpi_ibm and type make make install I unloaded, recompiled that part, and rebooted, but I see no change for the hotkeys. Most still don't work. Only volume mute work, but that worked before the change. Trying to change the brightness didn't corrupt the fan. Neither from hotkeys, nor from acpi_call You'll notice that fan speed becomes something ugly after trying to set brightness, but everything will work otherwise as far as I have tested. I have found that the machine gets quite hot on its own especially with turbo core on the i7 and heavy usage, even with power tuning. Adjusting fan speed could be dangerous, I would certainly keep a close eye on temperatures during something like buildworld to be sure. On the other side, my temp now drops below 50C to about 46C. The fan goes into its lowest spin. I didn't have this before. At 50C it kicks to next step, at 60C it kicks to the crazy speed (usually on compile or 720p video). P.S. All tests were done from X with Konstantin's patch on 9.0-STABLE with powerd and no other mods. X220 with i5 2520M, BIOS 1.28, IPS, 9cell batter, 16GB RAM, Intel 1000-N, SSD. P.S.S. Workaround for fan corruption can be changing the brightness while it boots, before OS starts, function keys work there. But I don't have the crazy fan. If by crazy fan you mean not the lowest spin, then I had that before LEN change as well. -- Lyubomir Grigorov (bgalakazam) We have the same bios at least, only difference is 8gb RAM here and i7-2720M. For what it's worth the i5 and i7 are the same as far as I know except amount of L3 cache...maybe amt or vt-d? The corrupt fan speed value occurs only when setting lcd brightness in dev.acpi_ibm.0.lcd_brightness (from memory, so not sure if that's exact). It doesn't affect brightness as only bypassing \_SB.PCI0.LPC.EC.BRNS() seems to change the brightness for us (by using acpi_call to call \VBRC). The hotkeys are interesting, I assume you're familar with the way the mask works etc...once you enable the hotkeys with sysctls, they are then supposed to be handled by devd, I believe, so you would have to create a script to capture the keys and execute some commands. It's been a while since I did this, as I usually didn't use hotkeys...so in this case you *could* capture brightness hotkeys in devd and call acpi_call, but that seems like a hack...I think the best case is to allow ACPI to handle the hotkeys (which it's doing fine) but figure out why the hw.acpi.video.lcd0.brightness (again from memory) has no effect...as the hotkeys do change this value out of the box. 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: x220 notes
On 04/01/12 22:49, Kevin Oberman wrote: 2012/4/1 Любомир Григоровnm.kn...@gmail.com: Well I can't do the brightness switching. acpi_call port is installed, but: # kldload acpi_call kldload: can't load acpi_call: No such file or directory # acpi_call -p '\VBRC' -i 14 ioctl: Device not configured At least closing the lid turns off the monitor (not going to sleep), which is OK to conserve energy when not using. I would like to be able to change brightness, however. And have dimming. A minor problem, with the KMS Intel patch, when I log out of X (startx or xfce4), screen goes black. I don't know if this is acpi related. I typed reboot, and nothing happened. Using all.13.7-stable-9.patch with 9.0-STABLE. # cd /usr/ports/sysutils/acpi_call make install clean # rehash # kld_load acpi_call # acpi_call -p '\VBRC' -i 5 Exactly...I'd like to add it does require appropriate kernel sources, something I discovered as I'm currently testing off a 4gb USB...appropriately to current discussions, /usr/obj /usr/ports/distfiles /tmp /var/run are all tmpfs :) (we'll see how that goes too!). Some general followup/status of brightness: The hotkeys are working just fine out of the box, at least as far as they seem to adjust the brightness value seen by acpi_video, however as we know this doesn't actually seem to do much. There are a couple of branches in the ACPI code when brightness is called, one of which checks for integrated or discrete graphics (why I do not know as discrete is not an option). If \VIGD returns 1 (which I think means graphics are integrated) it talks to the \_SB.PCI0.LPC.EC.BRNS method, which doesn't seem to do anything for us. If \VIGD returns 0 (which I think would mean discrete graphics if available) it calls \VBRC The above method simply bypasses the VIGD switch and calls \VBRC directly. There are other ACPI methods which seem to be related, but I have yet to figure out what they mean...VBTC is one, and some _Q(X)(X) methods also seem to talk to the EC about the panel and brightness etc. It seems like we need to find how to make the EC be in charge of brightness instead of whatever VBRC is doing (it's an SMI call). I think brightness might just work fine...another note is the fact that acpi_video sees lcd0 as inactive...not sure why. Regarding acpi_ibm, it appears that it is also talking to the EC, which is why brightness cannot work there. Although for some reason, probably an alignment or address change, the fan speed appears corrupt after setting brightness via acpi_ibm, the fan controls still work fine in both manual and automatic as far as I can tell. It seems like if we can determine why the EC does not care for brightness settings, or isn't in charge of brightness, that we would be a small patch away from fixing acpi_ibm for this model. HOWEVER, it appears resume is now toast on CURRENT, since at least a few months, with or without Konstantin's patches. I'm not sure what's hanging, although setting suspend_beep=1 creates a horrible sound during the failing resume, which may indicate it's something fairly early in the resume, or even concurrent with beeping. Even bounce does not work, and debugging is complicated by the lack of display. If anyone has anyone ideas for fixing resume on CURRENT, we'd be awful close to having a pretty damn nice laptop for FreeBSD. 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: x220 notes
On 04/02/12 18:42, Любомир Григоров wrote: Interesting. So brightness value is changed, but not acted upon then when using the hotkeys? Yes, value changes with no effect when hotkeys are pressed...I am not sure why there is no effect. I could care less about suspend/resume as I don't really use it. Brightness and the fan (thanks for reminding me about the corruption) are what is killing my use. I have a SSD so even though boot isn't 5sec on FreeBSD, I can still live with waiting 10 extra seconds. Having brightness eat up my battery time and fan spinning like crazy is a problem, though. The fan is horribly noisy on this model. However, it will quiet down a bit on its own when temperature goes down...enabling C states and running powerd -a adaptive -b adaptive should help a lot...I don't recommend manual fan control as at least my i7 already runs way too hot in linux and win7 (for the 10 minutes I had it :) ). Run Lenovo bios updates as well, many complaints about post tsunami fans from Lenovo China instead of Lenovo Japan... What do you mean by the fan controls still work in manual and automatic? Does that mean every time brightness is changed, fan speed needs to be set to auto again for it to work properly? Only the fan speed value shows as 0x or something, however it can still be set 1-7 or back to automatic as usual Also, I assume the dimming from inactivity will not work until EC is responsible for brightness change? I'm not sure...that might be accomplished with dpms.ko, haven't tried ... and then I have the issue with Konstantin's latest patch for STABLE where after I exit X, I have no monitor or keyboard control. I guess I can bypass this with a login manager. http://wiki.freebsd.org/Intel_GPU On Konstantin's page he mentions this...it's a known issue 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: x220 notes
On 02/12/12 12:29, Hannes Mehnert wrote: Hi, I recently got a X220 and installed -CURRENT (with kib's 13.1 patch) on it - let me add some notes on this thread. On 10/17/2011 03:53, Matt wrote: On 09/28/11 16:01, Kevin Oberman wrote: On Wed, Sep 28, 2011 at 12:32 PM, Garrett Cooperyaneg...@gmail.com wrote: On Wed, Sep 28, 2011 at 12:25 PM, Mattsendtom...@gmail.com wrote: On 09/28/11 11:52, Garrett Cooper wrote: On Wed, Sep 28, 2011 at 11:48 AM, Mattsendtom...@gmail.comwrote: acpi_ibm needs LEN0068 added to the list of ibm ids at the beginning of /usr/src/sys/dev/acpi_support/acpi_ibm.c...I'd write a patch but that machine is in a world of ports hurt right now :). With this many of the sysctls and leds work, still no brightness (w or wout intel DRI from Konstantin...thanks Konstantin!!) (there's a pr about that kern/164538) I'm not sure if I mentioned this in another post, but I can confirm that adjusting brightness in ibm_acpi for me results in corrupting the fan speed, which makes me think that addresses have changed, widths/extents have changed, or something else is different. For what it's worth, thinkpad-acpi in Linux does this just fine, although I haven't determined if it's through the EC or ACPI...I am thinking EC however. I have a feeling the answer to brightness (aside from KMS patch for X, which is seperate) might be comparing changelogs for thinkpad ec handlers on a platform that works like Linux...the code looks mostly similar...can anyone confirm if Open/NetBSD have issues with the backlight on these SandyBridge thinkpads? The brightness work fine on Linux, but not on OpenBSD(-CURRENT). But on OpenBSD xbacklight (which uses randr) works to set the brightness once in X. This unfortunately does not work on FreeBSD (receiving No outputs have backlight property when running xbacklight). Cheers, Hannes ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I got 10-CURRENT installed on the x220 again. 1. Standard GENERIC kernel 2. Buildworld/installworld from today's CVS 3. No DRM/KMS patches or any other factors 4. Witness KDB disabled in loader.conf (otherwise panic on suspend). 5. setting hw.pci.do_power_suspend=0 wil prevent some AE_NO_METHOD errors where it tries to set PCI express ports to D2 (the ports themselves, I think...not the attached device) This is what I've found as I investigate the backlight/resume issue. I am not very good at understanding ASL, but here's what I see. 1. _WAK calls a number of display related methods 2. There are apparently brightness related calls here, as well as some other video related calls 3. Some of this behavior depends on /VIGD, whatever that is. 4. The brightness calls seem to connect over LPC to the embedded controller 5. Some of the brightness methods check OSI for WIN7 I will add that iasl finds 35 errors in this fine piece of lenovo work. However, none of the errors appear to be near _wak. I've attached an acpidump asl if it helps anyone who has a better eye for ASL and resume/brightness problems. I think we can control brightness at least with acpi_video, it attaches but not correctly...active=0...I haven't gone back over its source in comparison with ASL yet either. Probably acpi_ibm will work also, as the acpi methods seem to just call the embedded controller over the lpc bus? Unfortunately it seems something has changed with the ec, as some of the data becomes corrupt when acpi_ibm is loaded. Resume obviously works fine in Win7, works 80-95% of the time in Linux (seems like KMS fail when it doesn't resume on Linux), and it resumes fine on FreeBSD except no video. No bad messages in logs after resume. 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: Sleep/Lenovo SL410
Success! After setting every possible suspend/resume sysctl, sysctl hw.pci.do_power_resume=0 allowed suspend and resume. Still beeps 1-3 times before suspend, with rapid sleep light flashing until suspend complete. Kernel conf is attached. World built from last Friday's CVS, -CURRENT acpiconf -s3 works perfectly from console previously opened windows are garbled until refresh in X acpiconf -s4 causes shutdown, does not resume on power on. Swap is 2x RAM. VMstat -i rate is 540. Thank you FreeBSD! Matt # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.544 2010/04/25 22:01:32 thompsa Exp $ cpu HAMMER ident ONOSENDAI #makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options GEOM_BDE# Encrypted filesystems with GBDE options GEOM_ELI# Encrypted filesystems with GELI options GEOM_JOURNAL# GJournal options COMPAT_FREEBSD32# Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. options KBD_INSTALL_CDEV# install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework options FLOWTABLE # per-cpu routing cache #optionsKDTRACE_FRAME # Ensure frames are compiled in #optionsKDTRACE_HOOKS # Kernel DTrace hooks options INCLUDE_CONFIG_FILE # Include this file in kernel # Debugging for use in -current #optionsKDB # Enable kernel debugger #support. #optionsDDB # Support DDB. #optionsGDB # Support remote GDB. #optionsDEADLKRES # Enable the deadlock resolver #optionsINVARIANTS
