Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
kernel panic from if_em.c
2 views
Skip to first unread message
Jay Reffner
Jul 25, 2016, 11:31:32 AM7/25/16
to
>Synopsis: System panics after several weeks of runtime
>Category: kernel
>Environment:
System : OpenBSD 5.9
Details : OpenBSD 5.9 (GENERIC.MP) #1: Tue Jun 7 11:50:36 EDT
2016
ro...@gateway1.bodieelectric.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Architecture: OpenBSD.amd64
Machine : amd64
>Description:
Jul 25 09:30:17 gateway1 savecore: reboot after panic: kernel diagnostic
assertion "pkt->pkt_m != NULL" failed: file "../../../../dev/pci/if_em.c",
line 2400
Jul 25 09:30:17 gateway1 savecore: /var/crash/bounds: No such file or
directory
Jul 25 09:30:17 gateway1 savecore: writing core to /var/crash/bsd.0.core
(gdb) file /var/crash/bsd.0
Reading symbols from /var/crash/bsd.0...(no debugging symbols found)...done.
(gdb) target kvm /var/crash/bsd.0.core
#0 0xffffffff81322564 in dumpsys ()
(gdb) where
#0 0xffffffff81322564 in dumpsys ()
#1 0x000000017ea80000 in ?? ()
#2 0x0000000000000006 in ?? ()
#3 0xffffffff81366950 in sd_flush ()
Previous frame inner to this frame (corrupt stack?)
>How-To-Repeat:
Let the system run for a few weeks
>Fix:
Unknown - core available if needed
>Category: kernel
>Environment:
System : OpenBSD 5.9
Details : OpenBSD 5.9 (GENERIC.MP) #1: Tue Jun 7 11:50:36 EDT
2016
ro...@gateway1.bodieelectric.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Architecture: OpenBSD.amd64
Machine : amd64
>Description:
Jul 25 09:30:17 gateway1 savecore: reboot after panic: kernel diagnostic
assertion "pkt->pkt_m != NULL" failed: file "../../../../dev/pci/if_em.c",
line 2400
Jul 25 09:30:17 gateway1 savecore: /var/crash/bounds: No such file or
directory
Jul 25 09:30:17 gateway1 savecore: writing core to /var/crash/bsd.0.core
(gdb) file /var/crash/bsd.0
Reading symbols from /var/crash/bsd.0...(no debugging symbols found)...done.
(gdb) target kvm /var/crash/bsd.0.core
#0 0xffffffff81322564 in dumpsys ()
(gdb) where
#0 0xffffffff81322564 in dumpsys ()
#1 0x000000017ea80000 in ?? ()
#2 0x0000000000000006 in ?? ()
#3 0xffffffff81366950 in sd_flush ()
Previous frame inner to this frame (corrupt stack?)
>How-To-Repeat:
Let the system run for a few weeks
>Fix:
Unknown - core available if needed
Theo de Raadt
Jul 25, 2016, 11:36:18 AM7/25/16
to
Jay,
That bug report sucks ass.
It seems you went out of the way to not include all the information
you are required to include.
It is almost impossible to file a report without including the details,
so you must have chosen to delete it.
Are you special enough that you believe you can get away with wasting
everyone's time like that?
Good luck -- you are on your own!
Hitting the 'd' key now. I can assure you almost all the developers
will do the same.
That bug report sucks ass.
It seems you went out of the way to not include all the information
you are required to include.
It is almost impossible to file a report without including the details,
so you must have chosen to delete it.
Are you special enough that you believe you can get away with wasting
everyone's time like that?
Good luck -- you are on your own!
Hitting the 'd' key now. I can assure you almost all the developers
will do the same.
Stefan Sperling
Jul 25, 2016, 11:43:16 AM7/25/16
to
To rule out the obvious:
Do you have all 5.9 kernel errata patches applied?
The timestamp on your kernel indicates otherwise.
http://www.openbsd.org/errata59.html
0 new messages