VirtualBox

Changes between Initial Version and Version 1 of Ticket #14034, comment 3


Ignore:
Timestamp:
May 19, 2015 9:17:14 AM (9 years ago)
Author:
nj

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.26 of VirtualBox. The stack traces were[[br]]
     1After 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]]
    22<4> <NMI>  [<ffffffff8152933c>] ? panic+0xa7/0x16f[[br]]
    33<4> [<ffffffff8152fac6>] ? kprobe_exceptions_notify+0x16/0x430[[br]]
     
    4242<4> [<ffffffff8100b072>] ? system_call_fastpath+0x16/0x1b[[br]]
    4343
    44 I have now upgraded the machines to 4.3.28 and am awaiting to see if there are any more crashes.
    45 
    4644So 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.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy