[acpi_battery] vm_soft_fault + vm_page_fault in ReadBatteryStatus()

[michael.weirauch]

hrev32497;gcc4;ata-bm;acpi; specs ​here and ​here

fresh install; happened on using TextSearch Tracker add-on (likely unrelated)

The first two lines in the screenshot are the last two lines of syslog ouput followed by a bt

[anevilyak]

Possibly related to #4152?

[michael.weirauch]

Replying to anevilyak:

Possibly related to #4152?

Hi Rene, at least I don't seem to have any syslog output about global lock issues. No idea if that one is "technically" related.

[anevilyak]

Yeah, I'm wondering if they're different symptoms of the same underlying problems or not...

[michael.weirauch]

Luckily, I was just able to reproduce this with the TextSearch add-on. Happened on a second search after a longer lasting first search through the trunk/headers.

Backtrace looks exactly the same.

Suspiciously an issued reboot freezes the system immedeately, which might be just a coincidence, but I do experience complete freezes described in #3772.

[michael.weirauch]

And another KDL. Just right out of the blue. This time, the KDL showed up, and the system was in a frozen state immedeately.

Really wondering if this might indeed point to some underlying ACPI issues which just show up more "aggressively" on my system.

[phoudoin]

At least, acpi_battery::ReadBatteryStatus doesn't do much check before assuming the ACPI object returned is

• a package
• have indeed 4 sub-objects packaged in it
• all are of integer type.

Last but not least, there is no user_memcpy() to return data to userland. AFAIK and unlike BeOS, Haiku don't lock automatically the memory handed to a driver by the userland caller. Under massive activity, maybe it's logical the userland page is not there...

[phoudoin]

Patch to add missing user_memcpy and some safety checks.

[phoudoin]

Again, I'm not at home to check this patch, so it's untested. But missing user_memcpy and frequent calls doesn't match great...

[michael.weirauch]

Hi Philippe,

I have issues applying the patch:

michael@think:/store/data/devel/haiku/svn/trunk> patch -i ../../_patches/acpi_battery.cpp.patch --verbose --verbose -p5 --dry-run
Hmm...  Looks like a unified diff to me...
(Stripping trailing CRs from patch.)
The text leading up to this was:
--------------------------
|--- /Data/projects/haiku/trunk/src/add-ons/kernel/drivers/power/acpi_battery/acpi_battery.cpp (revision 31481)
|+++ /Data/projects/haiku/trunk/src/add-ons/kernel/drivers/power/acpi_battery/acpi_battery.cpp (working copy)
--------------------------
Patching file src/add-ons/kernel/drivers/power/acpi_battery/acpi_battery.cpp using Plan A...
Hunk #1 succeeded at 49.
Hunk #2 succeeded at 94.
patch: **** malformed patch at line 165: 

[michael.weirauch]

Thanks to Philippe,

the segfault is apparently fixed with hrev32584. Would consider this one closeable.

I now for the first time saw a lot of ACPI erros in the syslog before the system froze. Is probably a candidate for another bug report.

Michael

[michael.weirauch]

Please ignore the previous message...

Attached two shots. One with a freeze and some syslog output full of ACPI errors, the other with a KDL where the last lines of syslog are shown with ACPI erros. The backtrace for the KDL one was ommited because it resembled the ones already given in the ticket.

What is new for me is the ACPI output in the syslogs. Not seen any ACPI related stuff ever before IIRC.

[michael.weirauch]

hrev33299-trunk-gcc4;

I've now grepped (TextSearch) the trunk/src for stdio and trunk/headers for l2cap several times with PowerStatus and acpi_battery installed. No syslog errors, no KDL, no freeze. Would consider this one fixed for real with the recent acpi changes.