Re: uma for acpi object cache
on 24/01/2013 22:33 Jung-uk Kim said the following: If I am not completely mistaken, this is what's happening: https://github.com/otcshare/acpica/pull/3 Please see ACPI_OBJECT_COMMON_HEADER macro change in the commit I mentioned the pull request. Before the commit: UINT8 Descriptor; UINT8 Type; UINT16 ReferenceCount; union acpi_operand_object *NextObject; UINT8 Flags; After the commit: union acpi_operand_object *NextObject; UINT8 DescriptorType; UINT8 Type; UINT16 ReferenceCount; UINT8 Flags; It may not look obvious but LinkOffset was used to keep offset of NextObject (and it was only safe for certain compilers platforms). Alas, it is completely bogus now because the pointer became the first element of any object. Although it was the right decision, the author forgot to change the LinkOffset with this commit, I guess. Now, modifying DescriptorType, Type, ReferenceCount, or Flags silently corrupts the linked list. Similarly, modifying any of these before setting the pointer gets silently clobbered. For example, ACPI_SET_DESCRIPTOR_TYPE() in AcpiOsReleaseObject() is effectively no-op because it's overwritten later. Does it make sense to you? Hmm, not sure... Are you trying to improve behavior in use-after-free scenario or some such abnormal situation? My understanding is this. An object is either in use or it's free/cached. When it is in use, then LinkOffset has nothing to do with object (cache linking is not applied to the object). When it is cached, then it is not accessed as the real object (via ACPI_OBJECT_COMMON_HEADER fields), it is accessed only as a cached entity via the LinkOffset hackery. So, I do not see any bug in the current code. Your change makes it look a little bit less ugly, though. But I do not see any functional change. -- Andriy Gapon ___ 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: uma for acpi object cache
on 24/01/2013 22:33 Jung-uk Kim said the following: On 2013-01-24 13:49:07 -0500, Andriy Gapon wrote: on 24/01/2013 20:29 Jung-uk Kim said the following: BTW, I tried something like that long ago. In fact, the first attempt goes all the way back to this patch (warning: it's naive, broken, and overly complicated): http://people.freebsd.org/~jkim/acpica/OsdCache.diff I have more up-to-date and correct patch to use UMA but I'm still not 100% convinced whether we want to do it or not. Hmm, your patch looks a bit more complicated than mine. What is all that extra stuff that you have there? The main issue was AcpiOsPurgeCache(). For example, we didn't have anything like Linux's kmem_cache_shrink() at the time: http://www.kernel.org/doc/htmldocs/kernel-api/API-kmem-cache-shrink.html It seems you implemented that with zone_drain() but it wasn't available until this commit: http://svnweb.freebsd.org/base?view=revisionrevision=166213 Also, I had to make sure the cache is empty before we do uma_zdestroy(), so on and so forth. OK, I see. I don't think that any of that is really needed (now). If you don't object I'll commit my variant in 1-2 weeks from now. -- Andriy Gapon ___ 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: uma for acpi object cache
on 24/01/2013 22:33 Jung-uk Kim said the following: On 2013-01-24 13:49:07 -0500, Andriy Gapon wrote: on 24/01/2013 20:29 Jung-uk Kim said the following: When utcache.c works, it works fairly well, actually. :-) Well, my primary motivation for the patch is all the reports about mysterious panics that seem to involve the cache: http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7562 http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7613 http://thread.gmane.org/gmane.os.freebsd.devel.acpi/7077 There were a few more reports with the same theme. I hoped that using uma(9) instead of hand-rolled code would lead to better diagnostic and debugging cabilities. Hmm... I am not really sure local cache is to blame here. If you really want to prove your theory, I think a simple modification to utcache.c should do: Cache-LinkOffset = 8; Cache-ListName = CacheName; Cache-ObjectSize = ObjectSize; -Cache-MaxDepth = MaxDepth; +Cache-MaxDepth = 0; *ReturnCache = Cache; return (AE_OK); This should effectively kill object caching. That's a very simple trick, I wonder why I didn't think about it :-) Now I need to wait until one of the reporters resurfaces. -- Andriy Gapon ___ 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
acpi resume related patch
If you have ACPI suspend/resume working, if it used to work but stopped working at some time, if it never worked, but you are still hoping, could you please test the following patch and report back? http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch -- Andriy Gapon ___ 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
what is required to support a new laptop?
Hi all, I recently purchased a Lenovo Y530 and attempted to use some of the ACPI features (brightness of backlight, etc.) I attempted to load acpi_ibm but devd reported no events (running with devd -dD). What information might be useful to help support this laptop? Where are events such as fn+pgup (brightness up) reported? http://freebsd.org/~eadler/files/asl.y530.gz - acpidump -dt if this may be useful. -- Eitan Adler ___ 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 Fri, Jan 25, 2013 at 08:55:40AM -0500, Eitan Adler wrote: Hi all, I recently purchased a Lenovo Y530 and attempted to use some of the ACPI features (brightness of backlight, etc.) I attempted to load acpi_ibm but devd reported no events (running with devd -dD). What information might be useful to help support this laptop? Where are events such as fn+pgup (brightness up) reported? http://freebsd.org/~eadler/files/asl.y530.gz - acpidump -dt if this may be useful. Try apci_toshiba.ko. Glen pgpOMRsOQMDF8.pgp Description: PGP signature
Re: acpi resume related patch
On Fri, 25 Jan 2013 19:45:12 +0200, Andriy Gapon wrote: on 25/01/2013 19:40 Ian Smith said the following: On Fri, 25 Jan 2013 10:43:56 +0200, Andriy Gapon wrote: If you have ACPI suspend/resume working, if it used to work but stopped working at some time, if it never worked, but you are still hoping, could you please test the following patch and report back? http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch Sort of a negative report: on my Thinkpad T23 (9.1-REL, i386) suspend and resume finally work flawlessly every time out of the box, with no fudging such as unloading / reloading USB drivers as on 8.2. I always resume it with the Fn key (or lifting lid) but I tried using the power button this time, no problem, so no use testing your patch? Actually, I failed to mention that, but I am trying to check that there are no regressions with the patch. Having spent the last two full nights up almost completely rebuilding a friend's Lenovo SL500 - broken left LCD hinge, design fault, not an uncommon problem on these - I'm almost delerious and shouldn't have tried this tonight .. but here's the patch results. Too late to try building it tonight anyway (yes these are local times), but it doesn't seem to apply happily to 9.1-RELEASE: === Script started on Sat Jan 26 05:07:08 2013 You have mail. root@t23_4ma:/usr/src # patch acpi-apic-wakeup-final.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Index: sys/amd64/amd64/mp_machdep.c |=== |--- sys/amd64/amd64/mp_machdep.c (revision 245694) |+++ sys/amd64/amd64/mp_machdep.c (working copy) -- Patching file sys/amd64/amd64/mp_machdep.c using Plan A... Hunk #1 failed at 1431. 1 out of 1 hunks failed--saving rejects to sys/amd64/amd64/mp_machdep.c.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |Index: sys/dev/acpica/acpi.c |=== |--- sys/dev/acpica/acpi.c (revision 245694) |+++ sys/dev/acpica/acpi.c (working copy) -- Patching file sys/dev/acpica/acpi.c using Plan A... Hunk #1 failed at 2659. Hunk #2 failed at 2744. 2 out of 2 hunks failed--saving rejects to sys/dev/acpica/acpi.c.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |Index: sys/x86/x86/intr_machdep.c |=== |--- sys/x86/x86/intr_machdep.c (revision 245694) |+++ sys/x86/x86/intr_machdep.c (working copy) -- Patching file sys/x86/x86/intr_machdep.c using Plan A... Hunk #1 succeeded at 287. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |Index: sys/x86/x86/local_apic.c |=== |--- sys/x86/x86/local_apic.c (revision 245694) |+++ sys/x86/x86/local_apic.c (working copy) -- Patching file sys/x86/x86/local_apic.c using Plan A... Hunk #1 failed at 160. Hunk #2 succeeded at 167 (offset -4 lines). Hunk #3 succeeded at 567 (offset -3 lines). Hunk #4 succeeded at 1351 (offset -11 lines). 1 out of 4 hunks failed--saving rejects to sys/x86/x86/local_apic.c.rej done root@t23_4ma:/usr/src # exit exit Script done on Sat Jan 26 05:07:41 2013 === cheers, Ian ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: what is required to support a new laptop?
On Fri, Jan 25, 2013 at 6:12 AM, Glen Barber g...@freebsd.org wrote: On Fri, Jan 25, 2013 at 09:09:53AM -0500, Glen Barber wrote: On Fri, Jan 25, 2013 at 08:55:40AM -0500, Eitan Adler wrote: Hi all, I recently purchased a Lenovo Y530 and attempted to use some of the ACPI features (brightness of backlight, etc.) I attempted to load acpi_ibm but devd reported no events (running with devd -dD). What information might be useful to help support this laptop? Where are events such as fn+pgup (brightness up) reported? http://freebsd.org/~eadler/files/asl.y530.gz - acpidump -dt if this may be useful. Try apci_toshiba.ko. Erm.. Sorry, that may not help. I'm confusing thinkpad for toshiba. Sorry for the noise... There are several threads in the archives of acpi@ and mobile@ discussing this. Most things are pretty easy. Use xev to find the events generated by the volume buttons. Mute and the ThinkLight (if your system has one) should work as is. Brightness is a bit bigger issue as Lenovo has completely revamped it These buttons don't generate events. :-( You can install the acpi_call port and use it to set the brightness, but it is a pain as it does not allow for setting incremental changes, only absolute values.(16 of them). Google for FreeBSD acpi x220 notes. That should find the thread with the details. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
