r336876 breaks sysutils/acpi_call
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? Theron ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r336876 breaks sysutils/acpi_call
On Sat, Aug 25, 2018 at 11:51:21PM -0400, Theron 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. Does system freeze or panic ? I would expect the later. The fact that it occurs on some system and not another is encouraging and if my expectations are right, it fails on the system where SMAP is supported by hardware. If true, this means that this kernel module is already broken and accesses userspace directly without using copyin(9). Detecting such situations and stopping the system is the whole point of SMAP. > > 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? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r336876 breaks sysutils/acpi_call
On 8/25/18 11:51 PM, Theron wrote: A recent change in CURRENT has sysutils/acpi_call reliably cause a kernel panic The problem is with the port itself, not with CURRENT. A bug is filed accordingly. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r336876 breaks sysutils/acpi_call
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 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? > > Theron > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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 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. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
