Am 31.10.2015 um 16:44 schrieb Thomas Meyer: > Am Samstag, den 31.10.2015, 16:30 +0100 schrieb Richard Weinberger: >> Am 31.10.2015 um 16:24 schrieb Thomas Meyer: >>> Am Samstag, den 31.10.2015, 16:21 +0100 schrieb Richard Weinberger: >>>> Am 31.10.2015 um 16:16 schrieb Thomas Meyer: >>>>> mhh. strange. I didn't see this behaviour on my machine, but my >>>>> machine >>>>> is a rare single core system so, likely a race condition while >>>>> relaying >>>>> the timer interrupt to the userspace process. >>>> >>>> Here I can trigger it by starting UML, logging in and waiting >>>> ~5min. >>>> Then i try to run "top" --> top hangs forever. >>>> >>>>> But I'm out of ideas how this could happen! >>>> >>>> Maybe some stupid timeslice over/underflow. >>>> >>>>> what happens when you send the hanging process a SIGVTALRM >>>>> signal? >>>>> does >>>>> it proceed correctly? >>>> >>>> You mean sending SIGVTALRM to the UML host process? >>> >>> No, to the hanging userspace process, maybe the uml host process >>> did >>> receive a timer interrupt, but failed to relay this signal to the >>> correct userspace process. >> >> Well, this is not what top expects and dies. >> signal 26 (VTALRM) was caught by top, please >> see http://www.debian.org/Bugs/Reporting >>
This happens when i send the signal _within_ UML. Of course, top terminates. > So you did send a VTALARM in the UML system to the top process? > When yes then this was a misunderstanding! I wanted you to send a > SIGVTALRM on the uml host system to the hanging pid. does this resolve > the hang? I also sent SIGVTALRM to the hanging pid on the host side. It did not help. :( Thanks, //richard ------------------------------------------------------------------------------ _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
