Current problem reports assigned to freebsd-acpi@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/171305 acpi [acpi] acpi_tz0: _CRT value is absurd, ignored (256.0C o kern/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v o kern/163268 acpi [acpi_hp] [patch] fix driver detach in absence of CMI o kern/162859 acpi [acpi] ACPI battery/acline monitoring partialy working o kern/161715 acpi [acpi] Dell E6520 doesn't resume after ACPI suspend o kern/161713 acpi [acpi] Suspend on Dell E6520 o kern/160838 acpi [acpi] ACPI Battery Monitor Non-Functional o kern/160419 acpi [acpi_thermal] acpi_thermal kernel thread high CPU usa o kern/158689 acpi [acpi] value of sysctl hw.acpi.thermal.polling_rate ne o kern/154955 acpi [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3 o kern/152438 acpi [acpi]: patch to acpi_asus(4) to add extra sysctls for o kern/152098 acpi [acpi] Lenovo T61p does not resume o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not p kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o bin/126162 acpi [acpi] ACPI autoload failed : loading required module o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot a i386/122887 acpi [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immed s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/91594 acpi [acpi] FreeBSD 5.4 w/ACPI fails to detect Intel Pro/ o kern/73823 acpi [request] acpi / power-on by timer support o kern/56024 acpi ACPI suspend drains battery while in S3 33 problems total. ___ 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 Sunday, February 24, 2013 2:54:39 pm matt wrote: 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? vgapci's ivar is set by the PCI address. Do you have multiple vgapci devices? -- John Baldwin ___ 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 25 February 2013 17:53, matt sendtom...@gmail.com wrote: 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. 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 ___ 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
[101232] acpi_video0: ACPI video extension on vgapci0 found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 And what do I do with acpi_get_handle ? Adrian On 25 February 2013 18:23, matt sendtom...@gmail.com wrote: 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: ACPI video extension on vgapci0 found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 And what do I do with acpi_get_handle ? I threw printfs into acpi_video, not sure if that would work for both vgapci or not. I'm not sure if I wiped out my debug patches yet, I may have a patch. Basically the idea is to figure out which paths in the DSDT are getting attached to the vgapci devices. This dsdt patch from Mitsuru Iwasaki illustrates fixing a similar issue to X220 via a custom dsdt http://people.freebsd.org/~iwasaki/acpi/tpx61.asl.diff http://people.freebsd.org/%7Eiwasaki/acpi/tpx61.asl.diff It seems like we could either try to find these paths on affected models, or have a tunable override for acpi_video. Matt ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
