On Tue, 4 Nov 2003, Harti Brandt wrote: HB>On Tue, 4 Nov 2003, John Baldwin wrote: HB> HB>JB> HB>JB>On 04-Nov-2003 Harti Brandt wrote: HB>JB>> HB>JB>> Hi, HB>JB>> HB>JB>> I have an ASUS system with 2 CPUs that I need to run at HZ=10000. This HB>JB>> worked until yesterday, but with the new interrupt code it doesn't boot HB>JB>> anymore. It works for the standard HZ, but if I set HZ=1000 I get a double HB>JB>> fault. I suspect a race condition in the interrupt handling. My config HB>JB>> file has HB>JB>> HB>JB>> options SMP HB>JB>> device apic HB>JB>> options HZ=1000 HB>JB> HB>JB>Ok, I can try to reproduce. HB>JB> HB>JB>> Device configuration finished. HB>JB>> Timecounter "TSC" frequency 1380009492 Hz quality -100 HB>JB>> Timecounters cpuid = 0; apic id = 00 HB>JB>> instruction pointer = 0x8:0xc048995d HB>JB>> stack pointer = 0x10:0xc0821bf4 HB>JB>> frame pointer cpuid = 0; apic id = 00 HB>JB>> HB>JB>> 0xc048995d is in critical_exit. It is the jmp after the popf from HB>JB>> cpu_critical_exit. HB>JB> HB>JB>This is where interrupts are re-enabled, so you are getting an interrupt. HB>JB>It might be helpful to figure what type of fault you are actually getting. HB> HB>tf_err is 0, tf_trapno is 30 (decimal). Hmm, this seems to be the trapno that is set for all otherwise unused vectors, correct? There seems to be no info in the trapframe that shows me where this trap came from. How can I find this out? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt_at_fokus.fraunhofer.de, harti_at_freebsd.orgReceived on Tue Nov 04 2003 - 07:17:27 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:27 UTC