Changes between Initial Version and Version 1 of Ticket #14034, comment 3
- Timestamp:
- May 19, 2015 9:17:14 AM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #14034, comment 3
initial v1 1 After reading the indicated link I could not see that this definitely isn't a VBox problem. I presume in the case of this ticket the hardware watchdog is working as expected and is correctly causing a NMI to occur. There have been two more cases of servers rebooting since I submitted the ticket. This occurred with 4.3.26of VirtualBox. The stack traces were[[br]]1 After reading the indicated link I could not see that this definitely isn't a VBox problem. I presume in the case of this ticket the hardware watchdog is working as expected and is correctly causing a NMI to occur. There have been two more cases of servers rebooting since I submitted the ticket. One occurred with 4.3.26 and one occurred with 4.3.28 of VirtualBox. The stack traces were[[br]] 2 2 <4> <NMI> [<ffffffff8152933c>] ? panic+0xa7/0x16f[[br]] 3 3 <4> [<ffffffff8152fac6>] ? kprobe_exceptions_notify+0x16/0x430[[br]] … … 42 42 <4> [<ffffffff8100b072>] ? system_call_fastpath+0x16/0x1b[[br]] 43 43 44 I have now upgraded the machines to 4.3.28 and am awaiting to see if there are any more crashes.45 46 44 So If I read the stack traces correctly the NMIs occur when vboxdrv is trying to allocate memory. In one of the stack traces it looks like the thread is waiting for a semaphore to become signalled before the thread can make progress.

