Sleep/Lenovo SL410
Hope double post is ok, have issue with -CURRENT and ACPI. Kernel is ~week old cvsup -CURRENT amd64, issue has occurred with all versions of freebsd amd64 tried, however. Upon entering S3 sleep (or S4), the laptop emits 3 loud beeps and the sleep indicator begins flashing faster than normal. Older -CURRENT kernels also result in spinning fans at this point, which no longer occurs. Device will remain in this state indefinitely. Device must be powered off using the ten second rule. Occurs with custom kernel as well as GENERIC. Last entry is /var/log/messages is: Aug 23 17:59:09 ono-sendai acpi: suspend at 20100823 17:59:09 Please note atrtc0 error in dmesg? Can provide KERNCONF or other files as needed. Thank you all! I have been using various *bsd since I was 15 (~decade), can't tell you how grateful I am for your work, I hope to be able to help more soon! ACPI dump: http://pastebin.com/buQktjnq Dmesg: Copyright (c) 1992-2010 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-CURRENT #2: Sun Aug 15 23:33:22 PDT 2010 r...@ono-sendai.local:/usr/obj/usr/src/sys/ONOSENDAI amd64 CPU: Intel(R) Core(TM)2 Duo CPU T6570 @ 2.10GHz (2094.80-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x408e3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 3927597056 (3745 MB) Event timer "LAPIC" frequency 0 Hz quality 500 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 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 hpet0: [FILTER] Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x1807 mem 0xf240-0xf27f,0xd000-0xdfff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 131068k stolen memory drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd000 256MB info: [drm] Initialized i915 1.6.0 20080730 vgapci1: mem 0xf210-0xf21f at device 2.1 on pci0 uhci0: port 0x1820-0x183f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1840-0x185f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1860-0x187f irq 19 at device 26.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xf2a04800-0xf2a04bff irq 19 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 hdac0: mem 0xf2a0-0xf2a03fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pcib1: irq 17 at device 28.0 on pci0 pci2: on pcib1 pci2: at device 0.0 (no driver attached) pci2: at device 0.2 (no driver attached) pci2: at device 0.3 (no driver attached) pci2: at device 0.4 (no driver attached) pcib2: irq 16 at device 28.1 on pci0 pci3: on pcib2 pcib3: irq 18 at device 28.2 on pci0 pci4: on pcib3 pcib4: irq 19 at device 28.3 on pci0 pci5: on pcib4 iwn0: mem 0xf220-0xf2201fff irq 19 at device 0.0 on pci5 iwn0: MIMO 1T2R, BGS, address xx:xx:xx:xx:xx:xx iwn0: [ITHREAD] iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps pcib5: irq 17 at device 28.4 on pci0 pci6: on pcib5 pcib6: irq 16 at device 28.5 on pci0 pci8: on pcib6 re0: port 0x3000-0x30ff mem 0xf2004000-0xf2004fff,0xf200-0xf2003fff irq 17 at device 0.0 on pci8 re0: Using 1 MSI messages re0: Chip rev. 0x2800 re0: MAC rev. 0x miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: xx:xx:xx:xx:xx:xx re0: [FILTER] uhci3: port 0x1880-0x189f irq 23 at device 29.0 on pci0 uhci3: [ITHREAD] usbus4: on uhci3 uhci4: port 0x18a0-0x18bf irq 19 at device 29.1 on pci0 uhci4: [ITHREAD] usbus5: on uhci4 uhci5: port 0x18c0-0x18df irq 18 at device 29.2 on pci0 uhci5: [ITHREAD] usbus6: on uhci5 ehci1: mem 0xf2a04c00-0xf2a04fff irq 23 at
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 deadlo
Re: FreeBSD 9: Fn+* keyboard combinations aren't working anymore.
On Sun, 2 Oct 2011 15:49:44 +0400 arrowdodger <6year...@gmail.com> wrote: > On Wed, Sep 28, 2011 at 5:44 PM, arrowdodger <6year...@gmail.com> > wrote: > > > On Wed, Sep 28, 2011 at 5:32 PM, Lars Engels > > wrote: > > > >> On Wed, Sep 28, 2011 at 05:30:25PM +0400, arrowdodger wrote: > >> > Hello. I've used FreeBSD 8-STABLE on my Asus K40IN notebook. This > >> notebook > >> > has an key combination (Fn+F6/F7)to change monitor brightness. > >> > After > >> i've > >> > updated my system to 9-STABLE, these combinations stopped > >> > working. It's worth mentioning, that these combinations still > >> > work at boot screen. > >> > >> Have you tried loading acpi_asus.ko? > >> > > > > I've tried to do so when i was on 8-STABLE and it didn't work. It's > > not working for me on 9-STABLE too: > > acpi_asus0: Unsupported Asus laptop: K40IN > > > > All hotkeys, except ones for switching Wi-Fi and adjusting volume, > > were working on 8-STABLE. > > > > If no one knows a fix for this problem, maybe someone can point me to > relevant code? I may try to bisect revisions, or to check commit log. > ___ > 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" /usr/src/sys/dev/acpi_support/acpi_asus.c Might be a good place to start? You can use 'acpidump -dt > acpidump.aml' to get a dump of the laptop's acpi in the file acpidump.aml...This may allow you to determine what changed, either in the acpi_asus or in your laptop's ACPI 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 Cooper >>> wrote: >>>> On Wed, Sep 28, 2011 at 12:25 PM, Matt wrote: >>>>> On 09/28/11 11:52, Garrett Cooper wrote: >>>>>> On Wed, Sep 28, 2011 at 11:48 AM, Mattwrote: >>>>>>> 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: x220 notes
On 03/06/12 15:25, Любомир Григоров wrote: > I will be buying a X220 soon and have some questions: > > 1. Which wireless has better support? > > ThinkPad 11b/g/n Wireless (Realtek RTL8192SE / RTL8188CE) > Intel Centrino Wireless-N 1000 > > 2. I've read bad reviews about webcam having poor quality on > GNU/Linux, so I would assume it will be the same on FreeBSD with > webcamd and not worth the $30? (which also frees up space for 3x3 antenna) > > 3. Any disadvantages in usage for turning off the UEFI? > > 4. How far is the AMD64 kernel suspend/resume? What do you mean by > video doesn't resume? > > 5. I'll be getting the IPS screen and want to make sure all the > brightness issues won't f it up. Is there yet a working way to control > brightness without interrupting the fan? > > Cheers. > > 2012/2/18 matt mailto:sendtom...@gmail.com>> > > 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 <mailto: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 > <mailto:freebsd-acpi-unsubscr...@freebsd.org>" > > > > > -- > Lyubomir Grigorov (bgalakazam) > Ditch the webcam...it's grainy under linux, probably would be the same under FreeBSD...haven't even tried. Intel wireless is THE way to go...that Realtek is barely supported on Linux (I believe 8192SU is still staging drivers...) FreeBSD only legacy boots, however "UEFI USB Support" must be on to allow USB booting for some reason. I have IPS...it's very nice, but still no brightness yet. I'll get a chance to look at again this weekend most likely. I think it's just an issue with our acpi_ibm that isn't talking to the embedded controller right. Resume works, but the screen is not on. I can now confirm it is *off* and not just "dimmed/no backlight". Setting BIOS to use an external monitor and disabling internal exhibits same behavior as internal display, i.e external monitor set as BIOS primary does not come back from power save. I have tried typing dpms force commands, did not work. Once resume & brightness work, it will be great for FreeBSD...everything else seemed fine, although I have not used fingerprint reader or card reader... An interesting note is that the BIOS does whitelist the wireless card, and the wwan slot defaults to being a mSATA until it detects a whitelisted USB ID or perhaps has no PCIe lines...not sure but my ral card I'm working with will not detect in the second slot at all. The slot may start as PCIe only in earlier bios, haven't checked (google x220 egpu & x220 msata 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 04/01/12 22:49, Kevin Oberman wrote: 2012/4/1 Любомир Григоров: 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 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/06/12 00:10, Любомир Григоров wrote: I am sure, because pressing Mute now lights up the little light besides muting. Value changes to 1 as well. The rest of the buttons are not working. Basically I only need volume since I don't use sleep/resume and I don't care for turning off wifi from a button. But since I set mixer vol and pcm from console, it would be nice to associate with the buttons. Below is output (fan speed does change). 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: 1104 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: 2980 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.fan: 1 Are you sure acpi_ibm is actually doing the connect? What do you see for 'sysctl dev.acpi_ibm'? You should see a list of items, many of which will be '0', even though they should not be. Things like 'fan_speed'. Setting dev.acpi_ibm.0.mute or dev.acpi_ibm.0.thiklight to '1' should work. I think the hotkeys should default to 2484. You should be able to do this: sysctl dev.acpi_ibm.0.eventmask=134217727 then have devd match the incoming "IBM" events and spit them out to console. Once you know which affect what, you can then create a script to match all of them causing hotkey like actions customized for your machine... see /etc/devd/asus.conf for an example, but obviously our codes are different and unfortunately I don't have an example nor recent memory. You probably want to get devd to be very verbose and determine what the codes emitted are. 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=0xbfebfbff Features2=0x9ae3bd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3940532224 (3757 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: 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: 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: How can I help with thinkpad x220 issues?
On 07/03/12 13:08, Hannes Mehnert wrote: I believe you've to patch acpi_ibm with the lenovo (LEN0068) identifier and recompile - see http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164538 Indeed, however I wouldn't hope for too much. The new EC seems to have some differences. While some values appear and work, I'm not sure it will help much. Other values have appeared corrupted for me, while thankfully not appearing to crash the ec or cause malfunction. LEN0068 is a slightly different beast, it would appear. 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: Resume failed after Suspend on Thinkpad x201i
On 08/03/12 23:39, 乔楚 wrote: 2012/8/3 Zack Breckenridge : First of all, let me note that the Kernel config file I posted was for 10.0-CURRENT (a few weeks back now though). I've been looking into it, but still haven't developed a patch yet. I have verified that the screen blanking issue, on my hardware, occurs somewhere in the vm86 mode emulation code (which is how VESA is implemented on amd64), ultimately called by vesa_bios_post(), which is called in turn by vesa_load_state() on resume [see: http://fxr.watson.org/fxr/source/dev/fb/vesa.c?im=3#L1497]. vesa_bios_post() ultimately calls x86bios_call() [see: http://fxr.watson.org/fxr/source/compat/x86bios/x86bios.c?im=10#L584] and emulates the real mode VESA "initialization" code with a call to x86emu_exec_call(). I think in order to figure out whats going on from here I will have to do some DDB scripting and capture the output. I don't believe remote debugging will be possible with my hardware (no serial, no firewire)... Anyway, I'm working on it. So to verify that we are having the same issue, you can take the following steps: 1) build a kernel with debugging and VESA enabled: options VESA options KDB options DDB 2) disable X, boot into the console and issue the following commands: # sysctl debug.acpi.suspend_bounce=1 # sysctl debug.kdb.enter=1 db> break x86emu_exec_call db> c # zzz [you should hit the breakpoint] db> bt x86emu_exec_call() ... vesa_bios_post() ... ... rest of backtrace ... db> c 3) after hitting that last c, your screen should go black. Then you should be able to type "reboot" and reboot cleanly My screen go black, but type "reboot" no effect. I can be sure to type "reboot" and return. LED status: 1. Disk LED is light, and off at a moment. 2. "Z" LED is light, Battary and power LED is light. 3. Wifi LED is light. I'm pretty sure that if you get the same results, we are having the same issue, though I can make no guarantees. When I shutdown from KDE, or type shutdown -p now from console, my laptor can't shutdown complete. The battary LED is light alawys, others LED is off, and vents of the laptor has been blowing hot air. ___ 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" Honest Qiao: Regarding hot air, are you running powerd? Try "powerd -a adaptive -b adaptive" as root and wait 5 minutes to see if the hot air stops. If it works, try "man powerd" for installation instructions. Lenovo laptops are thermally designed for low CPU utilization. I can almost boil water on mine during buildworld. Without powerd, they run at full thermal profile and act as excellent hand warmers. Zack: Regarding remote debugging, do you have an expresscard/cardbus/etc slot? Although hard to find you may be able to find a firewire card for that. Not sure if that would work or not...same goes for a USB->Serial console, my guess is that it wouldn't work? Matt ___ 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 Любомир Григоров 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: 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 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: Sleep/resume in FreeBSD 9 on a ThinkPad
On 11/15/12 13:48, Stefan Horomnea wrote: > Hi, > > After your suggestion, I have searched a bit but found no way so far to > update my BIOS on the ThinkPad without having Windows install, in order to > run the update they provide on the lenovo website. I used all my partitions > for FreeBSD, so I do not space to install Windows. So that would be my last > resort. > If you guys know how I can update my BIOS without installing Windows, let > me know. > Until then, I will continue with the other tests. > > Thank you, > Stefan > > Search for the bios bootable cd. It should be available in small print from the Win7 bios update page. Now without a cdrom drive, it gets tricky, I think I was using a perl script I found somewhere called eltorito.pl to extract the disk image and just dd'd that to a usb disk. If you have a CD drive installed, of course it's much easier to just burn the iso using cdrecord...worked like a charm. 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: on usbus1 uhub3: 8 ports with 8 removable, self powered ugen1.3: 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: No keyboard after Suspend/Resume
On 01/11/13 08:22, Jason Selwitz wrote: > Thought I would shoot off a quick detail of my setup, maybe this will > help shed more light on the issue.. > > firstly this system is a Laptop, in a docking station, the keyboard is > connected to the docking station via both the PS/2 port and a USB > connection, it can also be set up to use 2 USB connections (perhaps the > PS/2 connection is not coming back fully after a suspend/resume cycle). > however after a little more testing after a resume, even the laptops > built in keyboard does not respond though I am able to pull the ps2 > connection remove the adapter and connect it to a USB port and have the > keyboard work again, though if the keyboard is in a USB port during the > suspend/resume I see the system reattaching the keyboard but it does not > allow text input until it is physically unplugged then reconnected. I'll > keep trying a few things and send any interesting debug info that I come > across.. thanks again to all.. > > Jason > > > > > Just some generic hardware wrangling ideas :) Just want to check if this is in the console, X, or both...Just saw a post about "unplugging and replugging" keyboard issues with X/hal (I've had some configs that had similar issues with mice as a pebkac with hal setup). If you've only tried in X switching to a VT and trying in the console (or not starting X) and testing again may be worthwhile to rule out high level problems. You could also try putting something in rc.resume using usbconfig to reset the bus? I'm not sure if there's a way to just send reset, but you could send power_off and then power_on to the specific device/bus combo for the keyboard. Try setting hw.pci.do_power_resume=1 and hw.pci.do_power_suspend=0 in case it's a PCI D state issue. Other combos might be worthwhile, some will likely break resume or suspend however. Might as well set hw.usb.ukbd.debug=1 and check the dmesg on resume as well. 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 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 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 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: 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:19, Adrian Chadd wrote: > > My T400 has: > > > vgapci0@pci0:0:2:0: class=0x03 card=0x20e417aa chip=0x2a428086 > rev=0x07 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Mobile 4 Series Chipset Integrated Graphics Controller' > class = display > subclass = VGA > vgapci1@pci0:0:2:1: class=0x038000 card=0x20e417aa chip=0x2a438086 > rev=0x07 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Mobile 4 Series Chipset Integrated Graphics Controller' > class = display > > And I get glitches in xorg on 9.1 when I have multiple windows of > different sizes. > > > > Adrian > Does acpi_video like either one? Does acpi_get_handle return the same path? 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: 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"
Re: Fixing X220 Video The Right Way
On 02/26/13 10:46, John Baldwin wrote: > On Monday, February 25, 2013 11:20:29 pm matt wrote: >> On 02/25/13 18:33, Adrian Chadd wrote: >>> [101232] acpi_video0: 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. > devinfo -v already tells you that. > > For example: > > nexus0 > acpi0 > pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0 > pci0 > hostb0 pnpinfo vendor=0x8086 device=0x0100 subvendor=0x8086 > subdevice=0x2010 class=0x06 at slot=0 function=0 > pcib1 pnpinfo vendor=0x8086 device=0x0101 subvendor=0x8086 > subdevice=0x2010 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.PEG1 > pci1 > vgapci0 pnpinfo vendor=0x10de device=0x0605 subvendor=0x3842 > subdevice=0xc973 class=0x03 at slot=0 function=0 > > (My desktop doesn't have acpi_video and doesn't have an ACPI handle for the > vgapci device, but you can see how it displays the handle for other PCI > devices like pcib1 which are in the ACPI namespace.) > >> It seems like we could either try to find these paths on affected >> models, or have a tunable override for acpi_video. > Note that the Linux discussion you posted seems a bit off. The _ADR is > not supposed to be unique to the entire system. For PCI devices, _ADR > contains the PCI device (slot) and function (as slot << 16 | func), and > the domain:bus portion of the address is implied by the parent PCI bus > device in the ACPI namespace. Thus, the specific handle assigned by ACPI > is for the exact PCI location of the requisite vgapci device. If your > BIOS lies it is hard for us to do anything useful, at least automatically. > > Do the other devices in your system that have _DOD or _DOS methods show > up as unknown ACPI devices in your devinfo -v output? It's not in devinfo at all for me, Adrian may have a different situation. So my laptop has _SB.PCI0.PEG.VID and _SB.PCI0.VID Only _SB.PCI0.VID is represented in devinfo -rv. As far as I know, PEG is not a "real" device, but an abstraction, possibly for Optimus use. It makes calls to \VIGD (integrated graphics?) and \ISOP (isOptimus?) This is potentially the broken bios part of things. I think I have multiple ACPI devices for a single physical device, and pci is attaching the wrong ACPI device to the physical device in an ivar. acpi_video happily uses this ivar to attempt to control video brightness. I could be entirely wrong on that, all I do know is that the working handle doesn't get used and the useless handle does. 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: Fixing X220 Video The Right Way
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 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: Fixing X220 Video The Right Way
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? 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.
Re: Thinkpad x230 display brightness
On 03/04/13 22:43, Любомир Григоров wrote: > 2012/10/20 Erich Dollansky > >> Hi, >> >> On Sun, 21 Oct 2012 02:20:22 +0200 >> Jan Hannibal Smith wrote: >> >>> Hey Guys, I just installed FreeBSD 9.1 RC2 on my ThinkPad x230, so far >>> everythings works fine except the keys for the brightness adjustment. >>> >>> I tried the tricks I found for the x220 series but nothing helped. >>> Does anybody got a clue how I can get these buttons to work? >>> Maybe there is a patch for the kms driver? >>> >> can you check if the keys do even generate events? >> >> They do not generate them on my X220. >> >> If they do not generate events, you can use only the command line to >> change brightness. >> > any info on this? I got a T430 from my work. I am afraid I will have to do > the manual calls like on my personal X220. > > > Any decoded DSDTs around? It's probably similar to the problem on X220 where there are multiple fake video devices in weird places. 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.
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: 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: 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: 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: 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 > 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: Fixing X220 Video The Right Way
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: 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 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"
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 Original message From: Matt Grice Date:21/04/2014 14:51 (GMT+00:00) To: Kevin Oberman Subject: Re: ACPI bug submission Thanks 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 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
