Re: r336876 breaks sysutils/acpi_call

Max Ignatenko wrote:
> Hi,
> 
> Sorry for a late reply!
> 
> First of all, thank you for taking time to investigate and even providing a
> fix (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230993) ! Your patch
> makes perfect sense to me and modifying userspace memory from kernel is
> indeed something I didn't consider to be a problem at the time.
> 
> Second, I'm not actively participating in FreeBSD community and development
> at the moment, and if you're willing to take over sysutils/acpi_call - I'll
> be happy to cooperate. Otherwise, I'll try to take time to incorporate your
> fix in the few upcoming weeks.
> 
> 
> On Sun, 26 Aug 2018 at 04:51, Theron <theron.tarigo_at_gmail.com> wrote:
> 
>>
>> A recent change in CURRENT has sysutils/acpi_call reliably cause a
>> kernel panic when run on a Dell XPS laptop system.  I bisected this to
>> r336876: Use SMAP on amd64.  I would have thought that this is a simple
>> compatibility problem requiring only a port update, except that the same
>> kernel and acpi_call on different hardware are not affected.  On the
>> problematic system, the kernel module loads without incident; it is when
>> executing ACPI commands, even normally harmless operations such as
>> requesting read-only constants, that the system freeze occurs.  ACPI
>> functionality seems otherwise unaffected.
>>
>> Kernel debugging console and crash dumps are also broken on this system
>> (I suspect due to Intel graphics) however it is an unrelated problem,
>> and is only an excuse for my inability to provide any further crash
>> information.
>>
>> Having already bisected to the breaking commit, is there anything else I
>> should do to improve the chances this problem gets fixed, or are there
>> any hardware compatibility notes I may have missed?

Just wondering if we could follow what DFBSD did, and integrate this 
utility in the base as it seems simple enough, and apparently useful in 
a lot of cases.