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