NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

port-vax/55415: vax no longer preempts in a timely fashion

>Number:         55415
>Category:       port-vax
>Synopsis:       vax no longer preempts in a timely fashion
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-vax-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jun 24 20:35:00 +0000 2020
>Originator:     Greg Oster
>Release:        NetBSD 9.99.68
System: NetBSD floyd 9.99.68 NetBSD 9.99.68 (GENERICFIX) #0: Wed Jun 24 10:35:26 CST 2020  oster@thog:/u1/builds/build300/src/obj/vax/u1/builds/build300/src/sys/arch/vax/compile/GENERICFIX vax
Architecture: vax
Machine: vax

The vax port currently isn't doing kernel preemption correctly.  That is,
if a userland process decides not to yield the CPU, it can basically stop
the network, console, and any other processes from getting any CPU cycles.

The behaviour was found by attempting to build /usr/pkgsrc/devel/m4, 
and wondering why it kept hanging the machine hard at a certain spot. 
That spot was testing for strstr() functionality.  After much debugging,
it was determined that the machine hadn't actually froze -- the strstr()
call was just consuming all CPU, and would continue to do so until the
call finished.  (Even though the code also had an alarm set to stop the
process after 5 seconds, that alarm would never fire, due to nothing else
getting any CPU cycles.)


Attempt to build /usr/pkgsrc/devel/m4 on a 4000/60.  
Notice that the machine appears to be totally frozen.
The errant behaviour is also be observed on boot, where ping times 
to the vax go from 2ms to 9*seconds* as various /etc/rc.d scripts are run.

Version 1.136 of src/sys/vax/vax/trap.c removed the lines:
		if (curcpu()->ci_want_resched)
 from the trap() function, and version 1.103 of src/sys/vax/include/cpu.c
removed the line:
               (ci)->ci_want_resched = 1; \
 from the cpu_need_resched #define.

Reverting both of these changes restores normal preemption behaviour.


Home | Main Index | Thread Index | Old Index