On Sun, 26 Jul 2020, John D. Baker wrote: > On Fri, 24 Jul 2020, John D. Baker wrote: > > > [ 1.0000000] NetBSD 9.0_STABLE (NET4501_JDB) #79: Sat Jul 18 08:19:53 CDT > > 2020 > > [ 1.0000000] > > [email protected]:/r0/build/netbsd-9/obj/i386/sys/arch/i386/compile/NET4501_JDB > > [ 1.0000000] total memory = 65148 KB > > [ 1.0000000] avail memory = 60628 KB > > [ 1.0000050] mainbus0 (root) > > [ 1.0000050] cpu0 at mainbus0 > > [ 1.0000050] fatal privileged instruction fault in supervisor mode > > [ 1.0000050] trap type 0 code 0 eip 0xc0114c30 cs 0xc0430008 eflags > > 0x10246 cr2 0 ilevel 0x8 esp 0xc011f0cb > > [ 1.0000050] curlwp 0xc0351960 pid 0 lid 1 lowest kstack 0xc04342c0 > > kernel: supervisor trap privileged instruction fault, code=0 > > Stopped in pid 0.1 (system) at netbsd:cpu_counter: rdtsc > > So, the pull-up of x86 TSC changes to netbsd-9 needs some more attention.
I think the problem lies with: cvs rdiff -u -r1.171.2.1 -r1.171.2.2 src/sys/arch/x86/x86/cpu.c The entire code block following the "if (cpu_hascounter())" should be in braces. Otherwise when "freq != 0" is found to be false, the "else" clause unconditionally calls "cpu_counter_serializing()" which calls "cpu_counter()" which attempts to execute the "rdtsc" instruction which causes the above fault on Soekris net4501. "cpu_get_tsc_freq()" in -current is significantly more sophisticated, but the code paths that could call "cpu_counter()" are protected by testing the result of "cpu_hascounter()". -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSD FreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
