Re: New interrupt stuff breaks ASUS 2 CPU system
On 11-Nov-2003 John Hay wrote: With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue ... Copyright (c) 1992-2003 The FreeBSD Project. ... Now why didn't I think of trying 'continue'? Hey there my old dual Pentium I diskless machine is running in SMP mode. Can you try this patch: http://www.FreeBSD.org/~jhb/patches/atpic.patch Ah, great, continue is not needed anymore. Now to see if someone can figure out why my dual PII get a panic: probing for non-PCI bus when booting. :-) Actually, can you try spurious.patch (same URL directory) instead and see if that is sufficient to fix it? Nope, this behaves the same as without the patches, ie. I have to type continue. Grrr, that's really bogus then. :( -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
On Thu, Nov 06, 2003 at 12:22:45PM -0500, John Baldwin wrote: On 06-Nov-2003 Harti Brandt wrote: JBI figured out what is happenning I think. You are getting a spurious JBinterrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register JBlists pending interrupts still waiting to be serviced. Try using JB'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if JBthe spurious IRQ 7 interrupts go away. Ok, that seems to help. Interesting although why do these interrupts happen only with a larger HZ and when the kernel is doing printfs (this machine has a serial console). I have also not tried to disable SIO2 and the parallel port. Can you also try turning mixed mode back on and using http://www.FreeBSD.org/~jhb/patches/spurious.patch You should get some stray IRQ 7's in the vmstat -i output as well as a few printf's to the kernel console. I think I'm seeing something related here, with the old interrupt code I got: ... Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... ACPI autoload failed - no such file or directory stray irq 7 ^^^ Copyright (c) 1992-2003 The FreeBSD Project. ... With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue SMAP type=01 base= len=0009f400 SMAP type=02 base=0009f400 len=0c00 SMAP type=02 base=000d len=0003 SMAP type=01 base=0010 len=1fdf SMAP type=03 base=1fef len=f000 SMAP type=04 base=1feff000 len=1000 SMAP type=01 base=1ff0 len=0008 SMAP type=02 base=1ff8 len=0008 SMAP type=02 base=fec0 len=4000 SMAP type=02 base=fee0 len=1000 SMAP type=02 base=fff8 len=0008 Copyright (c) 1992-2003 The FreeBSD Project. ... Neiter the spurious interrupt patch nor setting 'options NO_MIXED_MODE' makes a difference. This is on a Tyan Tiger MPX S2466N-4M board, a full verbose boot log is at: http://quad.zeist.de/newintr.log ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue ... Copyright (c) 1992-2003 The FreeBSD Project. ... Now why didn't I think of trying 'continue'? Hey there my old dual Pentium I diskless machine is running in SMP mode. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
On 10-Nov-2003 Marius Strobl wrote: On Thu, Nov 06, 2003 at 12:22:45PM -0500, John Baldwin wrote: On 06-Nov-2003 Harti Brandt wrote: JBI figured out what is happenning I think. You are getting a spurious JBinterrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register JBlists pending interrupts still waiting to be serviced. Try using JB'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if JBthe spurious IRQ 7 interrupts go away. Ok, that seems to help. Interesting although why do these interrupts happen only with a larger HZ and when the kernel is doing printfs (this machine has a serial console). I have also not tried to disable SIO2 and the parallel port. Can you also try turning mixed mode back on and using http://www.FreeBSD.org/~jhb/patches/spurious.patch You should get some stray IRQ 7's in the vmstat -i output as well as a few printf's to the kernel console. I think I'm seeing something related here, with the old interrupt code I got: ... Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... ACPI autoload failed - no such file or directory stray irq 7 ^^^ Copyright (c) 1992-2003 The FreeBSD Project. Peter has seen this on an amd64 machine. It seems we can get an interrupt from the AT PIC before we get a chance to program the PICs to mask all their inputs. ... With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue SMAP type=01 base= len=0009f400 SMAP type=02 base=0009f400 len=0c00 SMAP type=02 base=000d len=0003 SMAP type=01 base=0010 len=1fdf SMAP type=03 base=1fef len=f000 SMAP type=04 base=1feff000 len=1000 SMAP type=01 base=1ff0 len=0008 SMAP type=02 base=1ff8 len=0008 SMAP type=02 base=fec0 len=4000 SMAP type=02 base=fee0 len=1000 SMAP type=02 base=fff8 len=0008 Copyright (c) 1992-2003 The FreeBSD Project. ... Neiter the spurious interrupt patch nor setting 'options NO_MIXED_MODE' makes a difference. This is on a Tyan Tiger MPX S2466N-4M board, a full verbose boot log is at: http://quad.zeist.de/newintr.log -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
On 10-Nov-2003 John Hay wrote: With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue ... Copyright (c) 1992-2003 The FreeBSD Project. ... Now why didn't I think of trying 'continue'? Hey there my old dual Pentium I diskless machine is running in SMP mode. Can you try this patch: http://www.FreeBSD.org/~jhb/patches/atpic.patch -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
On Mon, Nov 10, 2003 at 02:12:56PM -0500, John Baldwin wrote: On 10-Nov-2003 John Hay wrote: With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue ... Copyright (c) 1992-2003 The FreeBSD Project. ... Now why didn't I think of trying 'continue'? Hey there my old dual Pentium I diskless machine is running in SMP mode. Can you try this patch: http://www.FreeBSD.org/~jhb/patches/atpic.patch Works here, thanks! Btw., I also get such a stray interrupt on my Sun U60, IIRC also from the printer port :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
On Mon, Nov 10, 2003 at 02:12:56PM -0500, John Baldwin wrote: On 10-Nov-2003 John Hay wrote: With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue ... Copyright (c) 1992-2003 The FreeBSD Project. ... Now why didn't I think of trying 'continue'? Hey there my old dual Pentium I diskless machine is running in SMP mode. Can you try this patch: http://www.FreeBSD.org/~jhb/patches/atpic.patch Ah, great, continue is not needed anymore. Now to see if someone can figure out why my dual PII get a panic: probing for non-PCI bus when booting. :-) John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
On 10-Nov-2003 John Hay wrote: On Mon, Nov 10, 2003 at 02:12:56PM -0500, John Baldwin wrote: On 10-Nov-2003 John Hay wrote: With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue ... Copyright (c) 1992-2003 The FreeBSD Project. ... Now why didn't I think of trying 'continue'? Hey there my old dual Pentium I diskless machine is running in SMP mode. Can you try this patch: http://www.FreeBSD.org/~jhb/patches/atpic.patch Ah, great, continue is not needed anymore. Now to see if someone can figure out why my dual PII get a panic: probing for non-PCI bus when booting. :-) Actually, can you try spurious.patch (same URL directory) instead and see if that is sufficient to fix it? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
With the new interrupt code I get: ... OK boot cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 current process = 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 ... However, if I enter 'continue' at the DDB prompt it continues to boot and the system seems to runs fine: ... db continue ... Copyright (c) 1992-2003 The FreeBSD Project. ... Now why didn't I think of trying 'continue'? Hey there my old dual Pentium I diskless machine is running in SMP mode. Can you try this patch: http://www.FreeBSD.org/~jhb/patches/atpic.patch Ah, great, continue is not needed anymore. Now to see if someone can figure out why my dual PII get a panic: probing for non-PCI bus when booting. :-) Actually, can you try spurious.patch (same URL directory) instead and see if that is sufficient to fix it? Nope, this behaves the same as without the patches, ie. I have to type continue. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On Thu, 6 Nov 2003, John Baldwin wrote: On 06-Nov-2003 Harti Brandt wrote: JBI figured out what is happenning I think. You are getting a spurious JBinterrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register JBlists pending interrupts still waiting to be serviced. Try using JB'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if JBthe spurious IRQ 7 interrupts go away. Ok, that seems to help. Interesting although why do these interrupts happen only with a larger HZ and when the kernel is doing printfs (this machine has a serial console). I have also not tried to disable SIO2 and the parallel port. Can you also try turning mixed mode back on and using http://www.FreeBSD.org/~jhb/patches/spurious.patch You should get some stray IRQ 7's in the vmstat -i output as well as a few printf's to the kernel console. Other changes fixed the problem with the apic case not working on my BP6, except the apic causes many more interrupts on serial ports at 921600 bps, almost enough to overload the system with just 2 active serial ports. I've now gathered lots of statistics for sio interrupt performance. The bad effect of the apic on performance is shown in the -current(apic) lines for a45 and a45b only: %%% Keywords: c04 = send at 115200 bps on cuac00, receive at 115200 bps on cuac04 c04b = like c04 plus send and receive in other direction too (b = bidirectional) (cuac* are on a Cyclades 8yo (2 * cd1400 isa)) a01 = like c04 except use ports cuaa[01] a01b = like a01 except bidirectional (cuaa[01] are standard motherboard 16550 clones) a45 = like a01 except use speed 921600 bps and ports cuaa[45] a45b = like a45 except bidirectional (cuaa[45] are on a VScom 200HV2 (2 * 16950 pci)) -current(ointr) = -current before new interrupt code -current = plain current (2003/11/06) -current(apic) = -current with apic configured for UP kernel on SMP hardware -current(bde) = my version of -current (new interrupt code not merged yet) +iir,+stream,+intr0 = my version of -current with variants of sio optimizations (only UART-independent ones; optimizations for 16950 UARTs give factor of 2 reduction in overheads) Overheads for doing above I/O in percent (min-max for 3 runs) on an ABIT BP6 with 366 MHz and 400 MHz Celerons: Devices OS UP SMP --- -- -- --- c04 RELENG_4(4.9) 6.58-6.59 Not measured (method problems) -current(ointr) 9.65-9.76 6.77-7.11 -current10.64-10.69 6.09-6.36 -current(apic) 9.63-9.90 As above (apic standard) -current(bde) 6.83-6.96 3.54-3.78 c04bRELENG_4(4.9) 12.83-12.90 Not measured (method problems) -current(ointr) 19.42-19.44 13.70-13.90 -current20.23-20.24 12.01-12.48 -current(apic) 17.77-17.89 As above (apic standard) -current(bde) 12.74-13.23 6.23-6.53 a01 RELENG_4(4.9) 7.50-7.50 Not measured (method problems) -current(ointr) 7.67-7.69 4.44-4.77 -current8.09-8.13 4.72-5.60 -current(apic) 7.75-8.02 As above (apic standard) -current(bde) 7.53-7.63 4.49-4.54 +iir 7.09-7.30 Not measured (kernel problems) +stream6.23-6.24 +iir+stream5.47-5.52 +intr0+iir 5.24-5.26 2.75-2.91 a01bRELENG_4(4.9) 14.64-14.84 Not measured (method problems) -current(ointr) 14.36-15.10 8.65-8.92 -current14.79-14.87 8.18-9.77 -current(apic) 14.80-14.91 As above (apic standard) -current(bde) 14.19-14.24 8.13-8.46 +iir 14.05-14.13 +stream12.12-12.17 +iir+stream10.58-10.62 +intr0+iir 10.07-10.12 5.10-5.63 a45 RELENG_4(4.9) 21.81-21.86 Not measured (method problems) -current(ointr) 24.00-24.04 13.3 -current25.13-25.20 31.4-31.5(86) -current(apic) 51.02-51.05(87) As above (apic standard) -current(bde) 21.83-22.02 10.71-10.89 +iir 21.98-22.05 +stream27.78-27.81 +iir+stream22.08-22.16 +intr0+iir 16.76-16.92 6.85-8.11 a45bRELENG_4(4.9) 46.23-46.44(87) Not measured (method problems) -current(ointr) 54.01-54.37(86) 25.2 (82/82) -current56.04-56.93(85) 70.1-70.7(80) -current(apic) 87.35-88.22(78) As above (apic standard) -current(bde) 42.06-42.12 Not measured (kernel problems)
RE: New interrupt stuff breaks ASUS 2 CPU system
On Thu, 6 Nov 2003, John Baldwin wrote: JB JBOn 06-Nov-2003 Harti Brandt wrote: JB JBI figured out what is happenning I think. You are getting a spurious JB JBinterrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register JB JBlists pending interrupts still waiting to be serviced. Try using JB JB'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if JB JBthe spurious IRQ 7 interrupts go away. JB JB Ok, that seems to help. Interesting although why do these interrupts JB happen only with a larger HZ and when the kernel is doing printfs (this JB machine has a serial console). I have also not tried to disable SIO2 and JB the parallel port. JB JBCan you also try turning mixed mode back on and using JBhttp://www.FreeBSD.org/~jhb/patches/spurious.patch JB JBYou should get some stray IRQ 7's in the vmstat -i output as well as a few JBprintf's to the kernel console. Now I'm getting the same 'Couldn't get vector from ISR!' as before on Xapic_isr1. Again ISR1 is 0 and IRR1 is 0x100. Here is some data: db trace Debugger(c05ea5f4,0,c05fa63b,c0821b5c,100) at Debugger+0x55 panic(c05fa63b,c0821b6c,c062ab80,c0821bb4,c05ab57d) at panic+0x156 lapic_handle_intr() at lapic_handle_intr+0x1b Xapic_isr1() at Xapic_isr1+0x3d --- interrupt, eip = 0xc04bbbfd, esp = 0xc0821bb0, ebp = 0xc0821bb4 --- critical_exit(c0821bf4,c059af49,c0638100,0,c05f7a08) at critical_exit+0x2d _mtx_unlock_spin_flags(c0638100,0,c05f7a08,c88,c0821bec) at _mtx_unlock_spin_flags+0x23 siocnputc(c061e8e0,a,5,c0821d10,a) at siocnputc+0xe9 cnputc(a,2060d900,1,0,c05eec77) at cnputc+0x7a putchar(a,c0821d10,1,0,0) at putchar+0x6c kvprintf(c05eec76,c04d46b0,c0821d10,a,c0821d30) at kvprintf+0x8d printf(c05eec76,0,,0,c05c6e20) at printf+0x57 tc_init(c0622c60,c0821d78,c05c7b8f,8,8) at tc_init+0xc4 init_TSC_tc(8,8,c05c6e20,0,a0) at init_TSC_tc+0x91 cpu_initclocks(c0821d98,c0490ac5,0,81e000,81ec00) at cpu_initclocks+0x11f initclocks(0,81e000,81ec00,81e000,0) at initclocks+0x8 mi_startup() at mi_startup+0xb5 begin() at begin+0x2c db x *lapic+0x110 0xd78f8110: 0 db x *lapic+0x210 0xd78f8210: 100 IRQ7 is the parallel port according to dmesg. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
On Fri, 7 Nov 2003, Stefan [iso-8859-1] Eßer wrote: On 2003-11-07 20:04 +1100, Bruce Evans [EMAIL PROTECTED] wrote: However, using the apic almost doubles the overheads for the a45 cases. This seems to be due to extra interrupts. The UART and/or driver already Just another data point: Seems that the interrupt rate doubled for drm0 on my system (from 60 to 120 driving a LCD at 60Hz vertical refresh). I thought this might be a problem with shared interrupts (drm0 and xl0 shared APIC IRQ 16), but removing the (actually unused) xl driver did not make a difference ... Hmm. My a45 UARTs are the only ones with a pci level triggered interrupt: Nov 7 01:48:44 gamplex kernel: ioapic0: Routing IRQ 5 - intpin 19 Nov 7 01:48:44 gamplex kernel: ioapic0: intpin 5 disabled Nov 7 01:48:44 gamplex kernel: ioapic0: intpin 19 trigger: level Nov 7 01:48:44 gamplex kernel: ioapic0: intpin 19 polarity: active-lo There is only one other level triggered interrupt the system that is used: Nov 7 01:48:44 gamplex kernel: ioapic0: Routing IRQ 11 - intpin 18 Nov 7 01:48:44 gamplex kernel: ioapic0: intpin 11 disabled Nov 7 01:48:44 gamplex kernel: ioapic0: intpin 18 trigger: level Nov 7 01:48:44 gamplex kernel: ioapic0: intpin 18 polarity: active-lo and I suspect it may be doing strange things too: I found that rev.1.23 of ata_lowlevel.c broke atapicam, but the new interrupt code magically fixed it. One of the atapicam devices is the only device on IRQ11. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On Wed, 5 Nov 2003, John Baldwin wrote: JB JBOn 05-Nov-2003 Harti Brandt wrote: JB On Tue, 4 Nov 2003, John Baldwin wrote: JB JB JB JB JBOn 04-Nov-2003 Harti Brandt wrote: JB JB On Tue, 4 Nov 2003, Harti Brandt wrote: JB JB JB JB HBOn Tue, 4 Nov 2003, John Baldwin wrote: JB JB HB JB JB HBJB JB JB HBJBOn 04-Nov-2003 Harti Brandt wrote: JB JB HBJB JB JB HBJB Hi, JB JB HBJB JB JB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This JB JB HBJB worked until yesterday, but with the new interrupt code it doesn't boot JB JB HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double JB JB HBJB fault. I suspect a race condition in the interrupt handling. My config JB JB HBJB file has JB JB HBJB JB JB HBJB options SMP JB JB HBJB device apic JB JB HBJB options HZ=1000 JB JB HBJB JB JB HBJBOk, I can try to reproduce. JB JB HBJB JB JB HBJB Device configuration finished. JB JB HBJB Timecounter TSC frequency 1380009492 Hz quality -100 JB JB HBJB Timecounters cpuid = 0; apic id = 00 JB JB HBJB instruction pointer = 0x8:0xc048995d JB JB HBJB stack pointer = 0x10:0xc0821bf4 JB JB HBJB frame pointercpuid = 0; apic id = 00 JB JB HBJB JB JB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from JB JB HBJB cpu_critical_exit. JB JB HBJB JB JB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. JB JB HBJBIt might be helpful to figure what type of fault you are actually getting. JB JB HB JB JB HBtf_err is 0, tf_trapno is 30 (decimal). JB JB JB JB More information: JB JB JB JB I have replaced all the reserved vectors with individual ones, that set JB JB tf_err to the index (vector number). It appears the the vector number is JB JB 39 decimal. What does that mean? JB JB JB JBIRQ 7. JB JBCan you post a verbose dmesg? Also, can you try both with and without JB JBACPI? JB JB Attached are both dmesgs. JB JB More datapoints: JB JB I had the parallel port (irq7) and the second sio disabled in the BIOS. JB After enabling both I now get a panic in lapic_handle_intr: Couldn't get JB vector from ISR! After fetching the relevant docs from intel I checked the JB registers of the apic pointed to by lapic. The interrupt taken is JB Xapic_irq1. isr1 is zero, but irr1 is 0x100 (that was without ACPI). How JB may that happen? As I understand ISR are the interrupts that have been JB delivered to the CPU so if it is interrupted a bit should be set, correct? JB JBI figured out what is happenning I think. You are getting a spurious JBinterrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register JBlists pending interrupts still waiting to be serviced. Try using JB'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if JBthe spurious IRQ 7 interrupts go away. Ok, that seems to help. Interesting although why do these interrupts happen only with a larger HZ and when the kernel is doing printfs (this machine has a serial console). I have also not tried to disable SIO2 and the parallel port. Thanks, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On 06-Nov-2003 Harti Brandt wrote: JBI figured out what is happenning I think. You are getting a spurious JBinterrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register JBlists pending interrupts still waiting to be serviced. Try using JB'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if JBthe spurious IRQ 7 interrupts go away. Ok, that seems to help. Interesting although why do these interrupts happen only with a larger HZ and when the kernel is doing printfs (this machine has a serial console). I have also not tried to disable SIO2 and the parallel port. Can you also try turning mixed mode back on and using http://www.FreeBSD.org/~jhb/patches/spurious.patch You should get some stray IRQ 7's in the vmstat -i output as well as a few printf's to the kernel console. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On Wed, 5 Nov 2003, Harti Brandt wrote: HBOn Tue, 4 Nov 2003, John Baldwin wrote: HB HBJB HBJBOn 04-Nov-2003 Harti Brandt wrote: HBJB On Tue, 4 Nov 2003, Harti Brandt wrote: HBJB HBJB HBOn Tue, 4 Nov 2003, John Baldwin wrote: HBJB HB HBJB HBJB HBJB HBJBOn 04-Nov-2003 Harti Brandt wrote: HBJB HBJB HBJB HBJB Hi, HBJB HBJB HBJB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This HBJB HBJB worked until yesterday, but with the new interrupt code it doesn't boot HBJB HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double HBJB HBJB fault. I suspect a race condition in the interrupt handling. My config HBJB HBJB file has HBJB HBJB HBJB HBJB options SMP HBJB HBJB device apic HBJB HBJB options HZ=1000 HBJB HBJB HBJB HBJBOk, I can try to reproduce. HBJB HBJB HBJB HBJB Device configuration finished. HBJB HBJB Timecounter TSC frequency 1380009492 Hz quality -100 HBJB HBJB Timecounters cpuid = 0; apic id = 00 HBJB HBJB instruction pointer = 0x8:0xc048995d HBJB HBJB stack pointer = 0x10:0xc0821bf4 HBJB HBJB frame pointercpuid = 0; apic id = 00 HBJB HBJB HBJB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from HBJB HBJB cpu_critical_exit. HBJB HBJB HBJB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. HBJB HBJBIt might be helpful to figure what type of fault you are actually getting. HBJB HB HBJB HBtf_err is 0, tf_trapno is 30 (decimal). HBJB HBJB More information: HBJB HBJB I have replaced all the reserved vectors with individual ones, that set HBJB tf_err to the index (vector number). It appears the the vector number is HBJB 39 decimal. What does that mean? HBJB HBJBIRQ 7. HBJBCan you post a verbose dmesg? Also, can you try both with and without HBJBACPI? HB HBAttached are both dmesgs. HB HBMore datapoints: HB HBI had the parallel port (irq7) and the second sio disabled in the BIOS. HBAfter enabling both I now get a panic in lapic_handle_intr: Couldn't get HBvector from ISR! After fetching the relevant docs from intel I checked the HBregisters of the apic pointed to by lapic. The interrupt taken is HBXapic_irq1. isr1 is zero, but irr1 is 0x100 (that was without ACPI). How HBmay that happen? As I understand ISR are the interrupts that have been HBdelivered to the CPU so if it is interrupted a bit should be set, correct? HB HBI then have replaced the panic by a printf() followed by a return. Now the HBsystem comes to live, but I get a couple of these warnings. When the HBsystem is idle everyting seems fine, but when I start my simulation HBapplication (which normally generates between 20k and 250k interrupts/sec HBdepending on the MPSAFE setting of the ATM drivers) I get approx 1-2 of HBthese messages per second (this is with HZ=1000). HB HBA question while reading the code: what does the global lapic variable HBrefer to? As I understand every CPU has its local APIC. Does it point to HBone of those two? To which? An additional point. In the above test where I got 1-2 message per second I have now disabled a debugging printout in the ATM driver that gave 3-4 messages per second (from the interrupt handler). Now the 'Couldn't get...' messages have disappeared. So this really looks like a race somewhere. Is it possible that the bit in the ISR gets somehow cleared between the point where the interrupt is handed to the processor but before the Xapic_irq1 really runs and sees that bit? Perhaps from another Xapic_irq1 instance or whatever? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
Another data point: I can't get my Asus A7M266-D to boot with the new interrupt code at all, perhaps because I have an Adaptec 39160. Whether acpi is on or off, whether it's in the kernel config or not, booting always hangs right after waiting 10 sec for scsi to settle and 0 scb's aborted. I've also tried it with 0,1 or 2 of the ide controllers enabled, with no change in result. Sometimes I get a spurious interrupt from ata1 message, sometimes not. Kernel from 10/27 works fine. Kernels from last couple of days fail. dmesg, config available on request, if wanted. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On 05-Nov-2003 Harti Brandt wrote: On Tue, 4 Nov 2003, John Baldwin wrote: JB JBOn 04-Nov-2003 Harti Brandt wrote: JB On Tue, 4 Nov 2003, Harti Brandt wrote: JB JB HBOn Tue, 4 Nov 2003, John Baldwin wrote: JB HB JB HBJB JB HBJBOn 04-Nov-2003 Harti Brandt wrote: JB HBJB JB HBJB Hi, JB HBJB JB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This JB HBJB worked until yesterday, but with the new interrupt code it doesn't boot JB HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double JB HBJB fault. I suspect a race condition in the interrupt handling. My config JB HBJB file has JB HBJB JB HBJB options SMP JB HBJB device apic JB HBJB options HZ=1000 JB HBJB JB HBJBOk, I can try to reproduce. JB HBJB JB HBJB Device configuration finished. JB HBJB Timecounter TSC frequency 1380009492 Hz quality -100 JB HBJB Timecounters cpuid = 0; apic id = 00 JB HBJB instruction pointer = 0x8:0xc048995d JB HBJB stack pointer = 0x10:0xc0821bf4 JB HBJB frame pointercpuid = 0; apic id = 00 JB HBJB JB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from JB HBJB cpu_critical_exit. JB HBJB JB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. JB HBJBIt might be helpful to figure what type of fault you are actually getting. JB HB JB HBtf_err is 0, tf_trapno is 30 (decimal). JB JB More information: JB JB I have replaced all the reserved vectors with individual ones, that set JB tf_err to the index (vector number). It appears the the vector number is JB 39 decimal. What does that mean? JB JBIRQ 7. JBCan you post a verbose dmesg? Also, can you try both with and without JBACPI? Attached are both dmesgs. More datapoints: I had the parallel port (irq7) and the second sio disabled in the BIOS. After enabling both I now get a panic in lapic_handle_intr: Couldn't get vector from ISR! After fetching the relevant docs from intel I checked the registers of the apic pointed to by lapic. The interrupt taken is Xapic_irq1. isr1 is zero, but irr1 is 0x100 (that was without ACPI). How may that happen? As I understand ISR are the interrupts that have been delivered to the CPU so if it is interrupted a bit should be set, correct? I figured out what is happenning I think. You are getting a spurious interrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register lists pending interrupts still waiting to be serviced. Try using 'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if the spurious IRQ 7 interrupts go away. A question while reading the code: what does the global lapic variable refer to? As I understand every CPU has its local APIC. Does it point to one of those two? To which? Every CPU can get to its APIC at the same physical address. Thus, CPU A can only get to its own local APIC, and not to any other CPUs. The 'lapic' variable has a virtual address mapped to the physical address of the local APIC. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
Hi. I have an ASUS system with 2 CPUs that I need to run at HZ=1. This worked until yesterday, but with the new interrupt code it doesn't boot anymore. It works for the standard HZ, but if I set HZ=1000 I get a double Compiled a new kernel with source from Nov. 3'rd where SMP and APIC had to be enabled to use SMP. A make kernel would complete in 10 min's. So I cvsupped to test the 'interrupt stuff' and recompiled. Upon boot it seemed that it only saw one of my two Xeons at 2.4 Ghz. Hypert. was enabled as default. So I reverted to the source the day before. I also have an ASUS motherboard with an Intel 875P chipset. regards Claus Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og virusscan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
On 04-Nov-2003 Claus Guttesen wrote: Hi. I have an ASUS system with 2 CPUs that I need to run at HZ=1. This worked until yesterday, but with the new interrupt code it doesn't boot anymore. It works for the standard HZ, but if I set HZ=1000 I get a double Compiled a new kernel with source from Nov. 3'rd where SMP and APIC had to be enabled to use SMP. A make kernel would complete in 10 min's. So I cvsupped to test the 'interrupt stuff' and recompiled. Upon boot it seemed that it only saw one of my two Xeons at 2.4 Ghz. Hypert. was enabled as default. So I reverted to the source the day before. I also have an ASUS motherboard with an Intel 875P chipset. Can you post a dmesg? Note that if you want hyperthreading, you need to enable it in your BIOS. The ACPI (and soon the MPTable) drivers will not use HT CPUs unless HT is enabled in the BIOS. My test machines with HT used the 865 chipset. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On 04-Nov-2003 Harti Brandt wrote: Hi, I have an ASUS system with 2 CPUs that I need to run at HZ=1. This worked until yesterday, but with the new interrupt code it doesn't boot anymore. It works for the standard HZ, but if I set HZ=1000 I get a double fault. I suspect a race condition in the interrupt handling. My config file has options SMP device apic options HZ=1000 Ok, I can try to reproduce. Device configuration finished. Timecounter TSC frequency 1380009492 Hz quality -100 Timecounters cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc048995d stack pointer = 0x10:0xc0821bf4 frame pointercpuid = 0; apic id = 00 0xc048995d is in critical_exit. It is the jmp after the popf from cpu_critical_exit. This is where interrupts are re-enabled, so you are getting an interrupt. It might be helpful to figure what type of fault you are actually getting. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On Tue, 4 Nov 2003, John Baldwin wrote: JB JBOn 04-Nov-2003 Harti Brandt wrote: JB JB Hi, JB JB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This JB worked until yesterday, but with the new interrupt code it doesn't boot JB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double JB fault. I suspect a race condition in the interrupt handling. My config JB file has JB JB options SMP JB device apic JB options HZ=1000 JB JBOk, I can try to reproduce. JB JB Device configuration finished. JB Timecounter TSC frequency 1380009492 Hz quality -100 JB Timecounters cpuid = 0; apic id = 00 JB instruction pointer = 0x8:0xc048995d JB stack pointer = 0x10:0xc0821bf4 JB frame pointercpuid = 0; apic id = 00 JB JB 0xc048995d is in critical_exit. It is the jmp after the popf from JB cpu_critical_exit. JB JBThis is where interrupts are re-enabled, so you are getting an interrupt. JBIt might be helpful to figure what type of fault you are actually getting. tf_err is 0, tf_trapno is 30 (decimal). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On Tue, 4 Nov 2003, Harti Brandt wrote: HBOn Tue, 4 Nov 2003, John Baldwin wrote: HB HBJB HBJBOn 04-Nov-2003 Harti Brandt wrote: HBJB HBJB Hi, HBJB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This HBJB worked until yesterday, but with the new interrupt code it doesn't boot HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double HBJB fault. I suspect a race condition in the interrupt handling. My config HBJB file has HBJB HBJB options SMP HBJB device apic HBJB options HZ=1000 HBJB HBJBOk, I can try to reproduce. HBJB HBJB Device configuration finished. HBJB Timecounter TSC frequency 1380009492 Hz quality -100 HBJB Timecounters cpuid = 0; apic id = 00 HBJB instruction pointer = 0x8:0xc048995d HBJB stack pointer = 0x10:0xc0821bf4 HBJB frame pointercpuid = 0; apic id = 00 HBJB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from HBJB cpu_critical_exit. HBJB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. HBJBIt might be helpful to figure what type of fault you are actually getting. HB HBtf_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 [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On Tue, 4 Nov 2003, Harti Brandt wrote: HBOn Tue, 4 Nov 2003, John Baldwin wrote: HB HBJB HBJBOn 04-Nov-2003 Harti Brandt wrote: HBJB HBJB Hi, HBJB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This HBJB worked until yesterday, but with the new interrupt code it doesn't boot HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double HBJB fault. I suspect a race condition in the interrupt handling. My config HBJB file has HBJB HBJB options SMP HBJB device apic HBJB options HZ=1000 HBJB HBJBOk, I can try to reproduce. HBJB HBJB Device configuration finished. HBJB Timecounter TSC frequency 1380009492 Hz quality -100 HBJB Timecounters cpuid = 0; apic id = 00 HBJB instruction pointer = 0x8:0xc048995d HBJB stack pointer = 0x10:0xc0821bf4 HBJB frame pointercpuid = 0; apic id = 00 HBJB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from HBJB cpu_critical_exit. HBJB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. HBJBIt might be helpful to figure what type of fault you are actually getting. HB HBtf_err is 0, tf_trapno is 30 (decimal). More information: I have replaced all the reserved vectors with individual ones, that set tf_err to the index (vector number). It appears the the vector number is 39 decimal. What does that mean? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On 04-Nov-2003 Harti Brandt wrote: On Tue, 4 Nov 2003, Harti Brandt wrote: HBOn Tue, 4 Nov 2003, John Baldwin wrote: HB HBJB HBJBOn 04-Nov-2003 Harti Brandt wrote: HBJB HBJB Hi, HBJB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This HBJB worked until yesterday, but with the new interrupt code it doesn't boot HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double HBJB fault. I suspect a race condition in the interrupt handling. My config HBJB file has HBJB HBJB options SMP HBJB device apic HBJB options HZ=1000 HBJB HBJBOk, I can try to reproduce. HBJB HBJB Device configuration finished. HBJB Timecounter TSC frequency 1380009492 Hz quality -100 HBJB Timecounters cpuid = 0; apic id = 00 HBJB instruction pointer = 0x8:0xc048995d HBJB stack pointer = 0x10:0xc0821bf4 HBJB frame pointercpuid = 0; apic id = 00 HBJB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from HBJB cpu_critical_exit. HBJB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. HBJBIt might be helpful to figure what type of fault you are actually getting. HB HBtf_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? You can't easily. If you have an APIC, you can try looking at the ISR registers. You need to add some code to local_apic.c that dumps the ISR contents and then call that from trap() prehaps. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New interrupt stuff breaks ASUS 2 CPU system
Hi. I also have an ASUS motherboard with an Intel 875P chipset. Can you post a dmesg? Note that if you want hyperthreading, you need to enable it in your BIOS. The ACPI (and soon the MPTable) drivers will not use HT CPUs unless HT is enabled in the BIOS. My test machines with HT used the 865 chipset. Upon boot the screen says that it's a dual Xeon with HT. I downgraded the server before I read this thread, so it's running the previous days src. I guess that a dmesg won't help from that. regards Claus Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og virusscan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On 04-Nov-2003 Harti Brandt wrote: On Tue, 4 Nov 2003, Harti Brandt wrote: HBOn Tue, 4 Nov 2003, John Baldwin wrote: HB HBJB HBJBOn 04-Nov-2003 Harti Brandt wrote: HBJB HBJB Hi, HBJB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This HBJB worked until yesterday, but with the new interrupt code it doesn't boot HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double HBJB fault. I suspect a race condition in the interrupt handling. My config HBJB file has HBJB HBJB options SMP HBJB device apic HBJB options HZ=1000 HBJB HBJBOk, I can try to reproduce. HBJB HBJB Device configuration finished. HBJB Timecounter TSC frequency 1380009492 Hz quality -100 HBJB Timecounters cpuid = 0; apic id = 00 HBJB instruction pointer = 0x8:0xc048995d HBJB stack pointer = 0x10:0xc0821bf4 HBJB frame pointercpuid = 0; apic id = 00 HBJB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from HBJB cpu_critical_exit. HBJB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. HBJBIt might be helpful to figure what type of fault you are actually getting. HB HBtf_err is 0, tf_trapno is 30 (decimal). More information: I have replaced all the reserved vectors with individual ones, that set tf_err to the index (vector number). It appears the the vector number is 39 decimal. What does that mean? IRQ 7. Can you post a verbose dmesg? Also, can you try both with and without ACPI? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
