Linux kernel module crash debug: general protection fault: 0000 [#1] SMP

[157707.736203] general protection fault: 0000 [#1] SMP 

Says that you are doing something horrible in memory (e.g dereferencing a null pointer)

[157707.740102] RIP: 0010:[<ffffffffa00f3fa0>]  [<ffffffffa00f3fa0>] pkt_queue+0x184/0x48a

This line is reporting to you the instruction pointer value when your module crashed; it says that it died inside a function named "pkt_queue" after an offset of "0x184". (btw, the same value appears in the first crash dump, 388 in decimal = 0x184)

Now, you can use objdump to dump the assembly + debug information about your code and you add the address of the function pkt_queue to 0x184 and you get to the offending instruction.
Let's say your pkt_queue function appears(unreasonably hypothetical) at address 0x01 in objdump, it means you should look at line: 0x184 + 0x01 = 0x185 in the assembly to see what's going on.

Objdump allows you view the source + the assembly and line numbers:
objdump -S your_object_file.o this will not only list the assembly but also the corresponding source code assuming the debug symbols are added when compiling.

Oh and for your future reference:
https://opensourceforu.com/2011/01/understanding-a-kernel-oops/

You can also use:

eu-addr2line -f -e object_file.o pkt_queue+0x184

Where -f tells the command that the function name is used with line number and -e is the executable or object file containing the line number.

there is also the script scripts/decode_stacktrace.sh in the kernel source code. You should enable CONFIG_DEBUG_INFO then run the script:

./scripts/decode_stacktrace.sh /path/to/vmlinux /path/to/kernel/tree /path/to/modules/dir < dmesg.log

for example starting in the kernel source code root:

make O=~/kbuild/x86/ -j9
cd ~/kbuild/x86/
make INSTALL_MOD_PATH=~/modpath modules_install
cd -
./scripts/decode_stacktrace.sh ~/kbuild/x86/vmlinux . ~/modpath < crash.log

see https://lwn.net/Articles/592724/