Re: APIC-UP related panic
On Wed, 12 Nov 2003, Dag-Erling [iso-8859-1] Smørgrav wrote: Matthew D. Fuller [EMAIL PROTECTED] writes: However, if NO_MIXED_MODE works, that is actually the more desirable way to run your system. How common is the need for this? Does turning of mixed mode when it's not needed give any real advantages higher up? NO_MIXED_MODE disables a hack which allow FreeBSD to work with mother- boards that lie about how APIC pins are wired. In general, you always want to use NO_MIXED_MODE *except* on hardware that has the bug that makes the mixed-mode hack necessary. Any way we can make this a tunable? :) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: APIC-UP related panic
On 13-Nov-2003 Doug White wrote: On Wed, 12 Nov 2003, Dag-Erling [iso-8859-1] Smørgrav wrote: Matthew D. Fuller [EMAIL PROTECTED] writes: However, if NO_MIXED_MODE works, that is actually the more desirable way to run your system. How common is the need for this? Does turning of mixed mode when it's not needed give any real advantages higher up? NO_MIXED_MODE disables a hack which allow FreeBSD to work with mother- boards that lie about how APIC pins are wired. In general, you always want to use NO_MIXED_MODE *except* on hardware that has the bug that makes the mixed-mode hack necessary. Any way we can make this a tunable? :) I need to make it a runtime check again actually at some point. -- 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: APIC-UP related panic
I, for one, am always pleased to see these sort of in-depth explanations of these sort of shims. On Tue, Nov 11, 2003 at 11:35:26AM -0500 I heard the voice of John Baldwin, and lo! it spake thus: It's documented in /sys/i386/conf/NOTES now along with 'device apic'. For a longer explanation of what is happening: [...] So, by default, to work around motherboards that don't hook IRQ 0 up to the I/O APIC, we route IRQ 0 through the the 8259A PICs. [...] However, if NO_MIXED_MODE works, that is actually the more desirable way to run your system. How common is the need for this? Does turning of mixed mode when it's not needed give any real advantages higher up? -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: APIC-UP related panic
Matthew D. Fuller [EMAIL PROTECTED] writes: However, if NO_MIXED_MODE works, that is actually the more desirable way to run your system. How common is the need for this? Does turning of mixed mode when it's not needed give any real advantages higher up? NO_MIXED_MODE disables a hack which allow FreeBSD to work with mother- boards that lie about how APIC pins are wired. In general, you always want to use NO_MIXED_MODE *except* on hardware that has the bug that makes the mixed-mode hack necessary. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: APIC-UP related panic
On 11-Nov-2003 Harald Schmalzbauer wrote: On Monday 10 November 2003 19:33, John Baldwin wrote: On 08-Nov-2003 Harald Schmalzbauer wrote: On Thursday 06 November 2003 17:33, John Baldwin wrote: On 06-Nov-2003 Harald Schmalzbauer wrote: Hello, I have one reproducable panic with sources from 04. Nov when enabling device apic in the kernel. While building OpenOffice about 1 1/2 hours after start the system reboots. This is absolutely reproducable. Removing device apic from the kernel solves the problem! *SNIP* Can you try the patch at http://www.FreeBSD.org/~jhb/patches/spurious.patch Regrettably this hasn't helped. The machine crashed aigain when building OpenOffice. This time I have something different in messages: Nov 7 19:51:27 cale syslogd: kernel boot file is /boot/kernel/kernel Nov 7 19:51:27 cale kernel: panic: Couldn't get vector from ISR! Nov 7 19:51:27 cale kernel: Nov 7 19:51:27 cale kernel: syncing disks, buffers remaining... 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 Nov 7 19:51:27 cale kernel: giving up on 1109 buffers Nov 7 19:51:27 cale kernel: Uptime: 3h57m51s Nov 7 19:51:27 cale kernel: Shutting down ACPI Nov 7 19:51:27 cale kernel: Automatic reboot in 15 seconds - press a key on the console to abort Nov 7 19:51:27 cale kernel: Rebooting... Let me know if I can help. Should I build a debug-kernel? I think that doesn't help too much since the machine rebootos immediately, so I have no chance to type anything like trace. Ok. The problem is that when the spurious interrupt is triggered, it doesn't set a bit in the ISR. Hmm, can you try using 'options NO_MIXED_MODE' instead? Uhm, I don't really understand what's going on. Also I haven't found anything about NO_MIXED_MODE but I made the usual kernel (-current from Nov.09, without the spurious patch) with device apic and options NO_MIXED_MODE. Now quake2forge compiled successfully (which also crashed the machine with the last apic kernel) also OpenOffice compiles fine. I see one difference in dmesg: Timecounter shows now ACPI-fast like with a previous SMP-kernel instead of ACPI-safe like wth the UP kernel. Just for info attached the new dmesg. Do you have any enlightning link for me about apic and NO_MIXED_MODE? It's documented in /sys/i386/conf/NOTES now along with 'device apic'. For a longer explanation of what is happening: The 8259A PICs can generate a spurious interrupt cycle when (I believe) an ISA interrupt is deasserted after the PIC begins the interrupt cycle. Or something like that. It's a weird race condition in the hardware. Anyways, as a result, when the 8259A master PIC notices this, it raises IRQ 7 but doesn't mark it as active/pending in its registers. Now, in the APIC world, things are a bit different. Spurious interrupts have their own separate vector that we handle just fine. However, on some motherboards, IRQ 0 (from the ISA timer) is not connected to the I/O APIC that routes ISA interrupts. To work around this, we have to use something called mixed mode. On the I/O APIC that routes ISA interrupts, the first interrupt pin (0) is special in that it doesn't have an ISA interrupt hooked up to it. Instead, the 8259A Master PIC is hooked up to that pin, and when it generates an Interrupt, the I/O APIC will pass it along transparently to the CPU if that pin on the I/O APIC is enabled. This pin is known as an ExtINT pin. Mixed mode is actually how your SMP machine works with a kernel that doesn't include 'device apic'. The BIOS programs the APICs to use mixed mode in one of two ways (except for some really old SMP motherboards which actually have a hardware switch you have to toggle to enable the APICs): It either enables an ExtINT pin directly on the first CPU that the 82559As talk to, or it enables the ExtINT pin in the first I/O APIC and routes that interrupt pin to the first CPU. When a mixed mode interrupt arrives at the CPU, it is does not go through the local APIC scheduling hardware (per se), but is delivered directly to the CPU. Thus, if the CPU tries to ask the local APIC which interrupt it just received, the local APIC can't tell it which one arrived. (The local APIC tells the CPU via its ISR registers, hence the reason for the panic message mentioning the ISR.) So, by default, to work around motherboards that don't hook IRQ 0 up to the I/O APIC, we route IRQ 0 through the the 8259A PICs. IRQ 0 then uses a different low-level interrupt handler that sends its EOI to the 8259A instead of to the local APIC. We only use a special handler for IRQ 0 though. We assume that IRQ 7 will be routed through the I/O APIC with all the other ISA interrupts. What is happening is that the 8259A PIC is sending a spurious interrupt. This interrupt goes through the ExtINT pin as an IRQ 7 and arrives at the CPU. However, the CPU expects IRQ 7 to come from the I/O
Re: APIC-UP related panic
On Monday 10 November 2003 19:33, John Baldwin wrote: On 08-Nov-2003 Harald Schmalzbauer wrote: On Thursday 06 November 2003 17:33, John Baldwin wrote: On 06-Nov-2003 Harald Schmalzbauer wrote: Hello, I have one reproducable panic with sources from 04. Nov when enabling device apic in the kernel. While building OpenOffice about 1 1/2 hours after start the system reboots. This is absolutely reproducable. Removing device apic from the kernel solves the problem! *SNIP* Can you try the patch at http://www.FreeBSD.org/~jhb/patches/spurious.patch Regrettably this hasn't helped. The machine crashed aigain when building OpenOffice. This time I have something different in messages: Nov 7 19:51:27 cale syslogd: kernel boot file is /boot/kernel/kernel Nov 7 19:51:27 cale kernel: panic: Couldn't get vector from ISR! Nov 7 19:51:27 cale kernel: Nov 7 19:51:27 cale kernel: syncing disks, buffers remaining... 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 Nov 7 19:51:27 cale kernel: giving up on 1109 buffers Nov 7 19:51:27 cale kernel: Uptime: 3h57m51s Nov 7 19:51:27 cale kernel: Shutting down ACPI Nov 7 19:51:27 cale kernel: Automatic reboot in 15 seconds - press a key on the console to abort Nov 7 19:51:27 cale kernel: Rebooting... Let me know if I can help. Should I build a debug-kernel? I think that doesn't help too much since the machine rebootos immediately, so I have no chance to type anything like trace. Ok. The problem is that when the spurious interrupt is triggered, it doesn't set a bit in the ISR. Hmm, can you try using 'options NO_MIXED_MODE' instead? Uhm, I don't really understand what's going on. Also I haven't found anything about NO_MIXED_MODE but I made the usual kernel (-current from Nov.09, without the spurious patch) with device apic and options NO_MIXED_MODE. Now quake2forge compiled successfully (which also crashed the machine with the last apic kernel) also OpenOffice compiles fine. I see one difference in dmesg: Timecounter shows now ACPI-fast like with a previous SMP-kernel instead of ACPI-safe like wth the UP kernel. Just for info attached the new dmesg. Do you have any enlightning link for me about apic and NO_MIXED_MODE? Thanks a lot, -Harry Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #37: Tue Nov 11 01:20:26 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CALE Preloaded elf kernel /boot/kernel/kernel at 0xc09c1000. Preloaded elf module /boot/kernel/linux.ko at 0xc09c1244. Preloaded elf module /boot/kernel/nvidia.ko at 0xc09c12f0. ACPI APIC Table: D815EA EA81510A Timecounter i8254 frequency 1183579 Hz quality 0 CPU: Intel(R) Celeron(TM) CPU1100MHz (1095.82-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 268173312 (255 MB) avail memory = 250781696 (239 MB) ioapic0: Changing APIC ID to 1 ioapic0 Version 2.0 irqs 0-23 on motherboard Pentium Pro MTRR support enabled VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc07603e2 (122) VESA: NVIDIA acpi0: D815EA D815EPFV on motherboard pcibios: BIOS version 2.10 Using $PIR table, 12 entries at 0xc00f2a10 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_cpu0: CPU port 0x530-0x537 on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci2: PCI bus on pcib1 pcib1: slot 0 INTA is routed to irq 16 nvidia0: GeForce4 MX 440 with AGP8X mem 0xf000-0xf3ff,0xfd00-0xfdff irq 16 at device 0.0 on pci2 pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci1: ACPI PCI bus on pcib2 fxp0: Intel 82801BA/CAM (ICH2/3) Pro/100 Ethernet port 0xdf00-0xdf3f mem 0xfc9ff000-0xfc9f irq 20 at device 8.0 on pci1 fxp0: Ethernet address 00:03:47:f0:c2:ef miibus0: MII bus on fxp0 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH2 UDMA100 controller port 0xffa0-0xffaf at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0xef40-0xef5f irq 19 at device 31.2 on pci0 usb0: Intel 82801BA/BAM (ICH2) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ichsmb0: Intel 82801BA (ICH2) SMBus controller port
Re: APIC-UP related panic
On Thursday 06 November 2003 17:33, John Baldwin wrote: On 06-Nov-2003 Harald Schmalzbauer wrote: Hello, I have one reproducable panic with sources from 04. Nov when enabling device apic in the kernel. While building OpenOffice about 1 1/2 hours after start the system reboots. This is absolutely reproducable. Removing device apic from the kernel solves the problem! The only thing I have are these lines from /var/log/messages: (attached the different dmesgs) Nov 5 13:41:40 cale syslogd: kernel boot file is /boot/kernel/kernel Nov 5 13:41:40 cale kernel: instruction pointer= 0x8:0xc054c85d Nov 5 13:41:40 cale kernel: stack pointer = 0x10:0xcdc9dbe0 Nov 5 13:41:40 cale kernel: frame pointer = 0x10:0xcdc9dbe4 Nov 5 13:41:40 cale kernel: code segment = base 0x0, limit 0xf, type 0x1b Nov 5 13:41:40 cale kernel: = DPL 0, pres 1, def32 1, gran 1 Nov 5 13:41:40 cale kernel: processor eflags = interrupt enabled, IOPL = 0 Nov 5 13:41:40 cale kernel: current process= 26 (irq16: nvidia0) Nov 5 13:41:40 cale kernel: trap number= 30 Nov 5 13:41:40 cale kernel: panic: unknown/reserved trap Nov 5 13:41:40 cale kernel: Nov 5 13:41:40 cale kernel: syncing disks, buffers remaining... 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 Nov 5 13:41:40 cale kernel: giving up on 1022 buffers Nov 5 13:41:40 cale kernel: Uptime: 1h38m28s Nov 5 13:41:40 cale kernel: Shutting down ACPI Nov 5 13:41:40 cale kernel: stray irq9 Nov 5 13:41:40 cale kernel: Automatic reboot in 15 seconds - press a key on the console to abort Nov 5 13:41:40 cale kernel: Rebooting... Can you try the patch at http://www.FreeBSD.org/~jhb/patches/spurious.patch Regrettably this hasn't helped. The machine crashed aigain when building OpenOffice. This time I have something different in messages: Nov 7 19:51:27 cale syslogd: kernel boot file is /boot/kernel/kernel Nov 7 19:51:27 cale kernel: panic: Couldn't get vector from ISR! Nov 7 19:51:27 cale kernel: Nov 7 19:51:27 cale kernel: syncing disks, buffers remaining... 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 Nov 7 19:51:27 cale kernel: giving up on 1109 buffers Nov 7 19:51:27 cale kernel: Uptime: 3h57m51s Nov 7 19:51:27 cale kernel: Shutting down ACPI Nov 7 19:51:27 cale kernel: Automatic reboot in 15 seconds - press a key on the console to abort Nov 7 19:51:27 cale kernel: Rebooting... Let me know if I can help. Should I build a debug-kernel? I think that doesn't help too much since the machine rebootos immediately, so I have no chance to type anything like trace. -Harry pgp0.pgp Description: signature
RE: APIC-UP related panic
On 06-Nov-2003 Harald Schmalzbauer wrote: Hello, I have one reproducable panic with sources from 04. Nov when enabling device apic in the kernel. While building OpenOffice about 1 1/2 hours after start the system reboots. This is absolutely reproducable. Removing device apic from the kernel solves the problem! The only thing I have are these lines from /var/log/messages: (attached the different dmesgs) Nov 5 13:41:40 cale syslogd: kernel boot file is /boot/kernel/kernel Nov 5 13:41:40 cale kernel: instruction pointer= 0x8:0xc054c85d Nov 5 13:41:40 cale kernel: stack pointer = 0x10:0xcdc9dbe0 Nov 5 13:41:40 cale kernel: frame pointer = 0x10:0xcdc9dbe4 Nov 5 13:41:40 cale kernel: code segment = base 0x0, limit 0xf, type 0x1b Nov 5 13:41:40 cale kernel: = DPL 0, pres 1, def32 1, gran 1 Nov 5 13:41:40 cale kernel: processor eflags = interrupt enabled, IOPL = 0 Nov 5 13:41:40 cale kernel: current process= 26 (irq16: nvidia0) Nov 5 13:41:40 cale kernel: trap number= 30 Nov 5 13:41:40 cale kernel: panic: unknown/reserved trap Nov 5 13:41:40 cale kernel: Nov 5 13:41:40 cale kernel: syncing disks, buffers remaining... 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 Nov 5 13:41:40 cale kernel: giving up on 1022 buffers Nov 5 13:41:40 cale kernel: Uptime: 1h38m28s Nov 5 13:41:40 cale kernel: Shutting down ACPI Nov 5 13:41:40 cale kernel: stray irq9 Nov 5 13:41:40 cale kernel: Automatic reboot in 15 seconds - press a key on the console to abort Nov 5 13:41:40 cale kernel: Rebooting... Can you try the patch at http://www.FreeBSD.org/~jhb/patches/spurious.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: APIC-UP related panic
On Thursday 06 November 2003 17:33, John Baldwin wrote: On 06-Nov-2003 Harald Schmalzbauer wrote: *SCHNIP* Nov 5 13:41:40 cale kernel: processor eflags = interrupt enabled, IOPL = 0 Nov 5 13:41:40 cale kernel: current process= 26 (irq16: nvidia0) Nov 5 13:41:40 cale kernel: trap number= 30 Nov 5 13:41:40 cale kernel: panic: unknown/reserved trap Nov 5 13:41:40 cale kernel: Nov 5 13:41:40 cale kernel: syncing disks, buffers remaining... 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 Nov 5 13:41:40 cale kernel: giving up on 1022 buffers Nov 5 13:41:40 cale kernel: Uptime: 1h38m28s Nov 5 13:41:40 cale kernel: Shutting down ACPI Nov 5 13:41:40 cale kernel: stray irq9 Nov 5 13:41:40 cale kernel: Automatic reboot in 15 seconds - press a key on the console to abort Nov 5 13:41:40 cale kernel: Rebooting... Can you try the patch at http://www.FreeBSD.org/~jhb/patches/spurious.patch It's my pleasure to do so, but these days I have to move some furniture to pay my rent. Expect feedback at ~Sat., 15.00 UTC. I hope so. Thanks a lot, -Harry pgp0.pgp Description: signature
