making kernel, drinking LI tea and writing an opus magnum enspired by the freebsd commit logs: first of all i should state that we are the only os that uses pentium counters in their microtime (freebsd, netbsd, etc checked). the bug fixed derives from the fact that #UD (divide by zero) is generated in two cases: 	a) divide by zero; 	b) divide overflow. so, the later case was the one causing panics on reboot. due to the divl insn design in the intel processors, the possible sizes of operands and results are: 16/8=8,8; 32/16=16,16; 64/32=32,32. the division will generate an #UD exception when the quotient won't fit into result, that is 32bit in our case (64bit is divided on 32bit). problem solved by normalizing the dividend by the divisor, so the quotient would not result a divide overflow.
making kernel, drinking LI tea and writing an opus magnum enspired
by the freebsd commit logs:
first of all i should state that we are the only os that uses pentium
counters in their microtime (freebsd, netbsd, etc checked).
the bug fixed derives from the fact that #UD (divide by zero)
is generated in two cases:
	a) divide by zero;
	b) divide overflow.
so, the later case was the one causing panics on reboot.
due to the divl insn design in the intel processors, the possible
sizes of operands and results are: 16/8=8,8; 32/16=16,16; 64/32=32,32.
the division will generate an #UD exception when the quotient
won't fit into result, that is 32bit in our case (64bit is divided on 32bit).
problem solved by normalizing the dividend by the divisor, so the quotient
would not result a divide overflow.

tested by: mickey, gene, mickey.
talked over: mickey, gene, marc, maillists, mickey.

orumin/openbsd-efivars,orumin/openbsd-efivars,orumin/openbsd-efivars,orumin/openbsd-efivars