Hello everyone,
I am currently addressing a power management issue. Upon waking up
from suspend, the login screen briefly appears for a couple of
seconds, followed by the screen going blank for around 7 seconds.
Afterward, the login screen is displayed again. I've identified an
ACPI error in the journalctl entries. In the source code, I located
the line corresponding to the error message, which indicates an error
if the handler is a null pointer. This handler is one of the function
parameters, and I am interested in determining which function assigns
its value and where, how the value was set to NULL initially.
Initially, I attempted manual debugging, but after a few backtraces, I
couldn't pinpoint from where the function was called. Since I have
some experience with gdb, I decided to try it and followed both the
kernel's and gdb's documentation. To reproduce the bug, I needed a
real machine. I ran `gdbserver` by attaching it to pid 1 (I think ACPI
driver is initialized by init (pid 1)), and in another terminal tab, I
executed `gdb vmlinux`. I then set a hardware breakpoint, but when I
used `step`, I encountered an "ignoring packet error." Here is the
output:
$ cd ~/src/linux-next
$ gdb vmlinux
Reading symbols from vmlinux...
(gdb) tar remote :1234
warning: Build ID mismatch between current exec-file
/home/dileep/src/linux-next/vmlinux
and automatically determined exec-file /usr/lib/systemd/systemd
exec-file-mismatch handling is currently "ask"
Load new symbol table from "/usr/lib/systemd/systemd"? (y or n) n
(gdb) hbreak drivers/acpi/acpica/evregion.c:131
Hardware assisted breakpoint 1 at 0xffffffff8197e240:
drivers/acpi/acpica/evregion.c:131. (2 locations)
(gdb) step
warning: Remote failure reply: E01
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
And for gdbserver:
$ sudo gdbserver --attach :1234 1
Attached; pid = 1
Listening on port 1234
Remote debugging from host 127.0.0.1, port 52364
gdbserver: Couldn't write debug register: Invalid argument.
Listening on port 1234
input_interrupt, count = 1 c = 36 ('$')
Firstly, the breakpoint 1 should be set at only one location.
Secondly, I'm puzzled by the error occurring with the `step` command
in both gdb and gdbserver. Is this the correct approach for remote
kernel debugging on the same machine? If not, what would be the proper
method? I also have a MacBook Pro as a second machine. If necessary, I
can use it as a host to run gdb.
Regards,
Dileep
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
