From owner-freebsd-smp Sun Dec 5 20:40: 6 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mass.cdrom.com (castles554.castles.com [208.214.165.118]) by hub.freebsd.org (Postfix) with ESMTP id D72B314FA0 for ; Sun, 5 Dec 1999 20:40:03 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id UAA00826; Sun, 5 Dec 1999 20:41:57 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912060441.UAA00826@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Chris Csanady Cc: smp@freebsd.org Subject: Re: incorrect irqs with pci devices In-reply-to: Your message of "Fri, 03 Dec 1999 19:02:14 CST." <38486816.E224F87C@ameslab.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Dec 1999 20:41:57 -0800 From: Mike Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You need to send this to the right list, for starters. You might also consider wrapping your messages at some sane boundary so that it's possible to reply to them cleanly. >>> Yes, it is a SMP box, and yes, the devices work fine. I just thought it >>> was odd that the kernel would report incorrect ones. >> >> They are not incorrect. SMP uses a different interrupt system. > > They are on my box, where incorrect is defined as the interrupts not reaching > their supposed destination. I would really like to fix this, but I don't > know enough about exactly what is wrong. Any ideas would really be > appreciated, as I would like to remove my disgusting hack. :) > > I have an AMI raid controller that the system reports that it is on irq 11. > The problem is that the interrupts actually go to irq 17. If I hard wire > them with Standard reporting procedure for this sort of bug involves sending this list the output of the 'mptable' command. You should make sure that your system is configured for MP 1.4, not MP 1.1, and that you have the system set for '24 interrupt mode', rather than '16 interrupt mode' (there are various other names applied to these modes depending on your BIOS vendor). -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Dec 5 22:31:35 1999 Delivered-To: freebsd-smp@freebsd.org Received: from friley-160-236.res.iastate.edu (friley-160-236.res.iastate.edu [129.186.160.236]) by hub.freebsd.org (Postfix) with ESMTP id E27DA14D74; Sun, 5 Dec 1999 22:31:20 -0800 (PST) (envelope-from cc@137.org) Received: from ameslab.gov (friley-160-235.res.iastate.edu [129.186.160.235]) by friley-160-236.res.iastate.edu (Postfix) with ESMTP id 43F10123; Mon, 6 Dec 1999 00:31:19 -0600 (CST) Message-ID: <384B5836.21E8DE45@ameslab.gov> Date: Mon, 06 Dec 1999 00:31:18 -0600 From: Chris Csanady X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5 i386) X-Accept-Language: en, ru, ja, ko MIME-Version: 1.0 To: Mike Smith Cc: Chris Csanady , smp@freebsd.org Subject: Re: incorrect irqs with pci devices References: <199912060441.UAA00826@mass.cdrom.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Smith wrote: > > You need to send this to the right list, for starters. You might also > consider wrapping your messages at some sane boundary so that it's > possible to reply to them cleanly. I sent a very detailed message in the past, both to hackers and smp, but I never received a response. The subject was "IO APIC misdirecting irq". Sorry about the wrapping though--I usually just write shorter lines than what I am replying to. > >>> Yes, it is a SMP box, and yes, the devices work fine. I just thought it > >>> was odd that the kernel would report incorrect ones. > >> > >> They are not incorrect. SMP uses a different interrupt system. > > > > They are on my box, where incorrect is defined as the interrupts not reaching > > their supposed destination. I would really like to fix this, but I don't > > know enough about exactly what is wrong. Any ideas would really be > > appreciated, as I would like to remove my disgusting hack. :) > > > > I have an AMI raid controller that the system reports that it is on irq 11. > > The problem is that the interrupts actually go to irq 17. If I hard wire > > them with > > Standard reporting procedure for this sort of bug involves sending this > list the output of the 'mptable' command. You should make sure that your > system is configured for MP 1.4, not MP 1.1, and that you have the system > set for '24 interrupt mode', rather than '16 interrupt mode' (there are > various other names applied to these modes depending on your BIOS vendor). My bios is set for MP 1.4. This devices works fine in linux--and it is reported to be on irq 11. I assume the APIC is falsely redirecting irq 11 to irq 17. It looks like the mptable entry does not even match exactly, so this should probably not happen. In /sys/pci/pci.c around line 328, there is something like airq = pci_apic_irq(cfg->bus, cfg->slot, cfg->intpin); where IIRC, the second arg (device #) keeps it from matching the mptable. However, the interrupts still go to irq 17. I do have a device on the first pci bus that does match with irq 11 however, which should be redirected. Not sure if this matters.. I have included my dmesg/mptable output from my other message below. Thanks, Chris =============================================================================== MPTable, version 2.0.15 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f80f0 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0x10 mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f8100 signature: 'PCMP' base table length: 260 version: 1.4 checksum: 0x30 OEM ID: 'INTEL ' Product ID: 'PR440FX ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 24 local APIC address: 0xfec08000 extended table length: 120 extended table checksum: 15 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x11 BSP, usable 6 1 9 0xfbff 12 0x11 AP, usable 6 1 9 0xfbff -- Bus: Bus ID Type 0 PCI 1 PCI 18 ISA -- I/O APICs: APIC ID Version State Address 13 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT active-hi edge 18 0 13 0 INT active-hi edge 18 1 13 1 INT active-hi edge 18 3 13 3 INT active-hi edge 18 4 13 4 INT active-hi edge 18 5 13 5 INT active-hi edge 18 6 13 6 INT active-hi edge 18 7 13 7 INT active-hi edge 18 8 13 8 INT active-hi edge 18 12 13 12 INT active-hi edge 18 14 13 14 INT active-hi edge 18 15 13 15 INT active-lo level 0 19:A 13 19 INT active-lo level 0 17:A 13 18 INT active-lo level 0 11:A 13 16 INT active-lo level 0 9:A 13 17 INT active-lo level 0 6:A 13 18 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT active-hi edge 18 0 255 0 NMI active-hi edge 0 0:A 255 1 ------------------------------------------------------------------------------- MP Config Extended Table Entries: -- bus ID: 0 address type: memory address address base: 0xd4000 address range: 0x4000 -- bus ID: 0 address type: memory address address base: 0xd8000 address range: 0x4000 -- bus ID: 0 address type: memory address address base: 0xdc000 address range: 0x4000 -- bus ID: 0 address type: memory address address base: 0xa0000 address range: 0x20000 -- bus ID: 0 address type: memory address address base: 0x8000000 address range: 0xf8000000 -- bus ID: 0 address type: I/O address address base: 0x0 address range: 0x10000 ------------------------------------------------------------------------------- # SMP kernel config file options: # Required: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optional (built-in defaults will work in most cases): #options NCPU=2 # number of CPUs #options NBUS=3 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs =============================================================================== Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #14: Sat Oct 23 19:15:37 CDT 1999 ccsanady@friley-160-235.res.iastate.edu:/usr/src/sys/compile/EUROPA Calibrating clock(s) ... TSC clock: 198655681 Hz, i8254 clock: 1193129 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium Pro (198.67-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping = 9 Features=0xfbff real memory = 134217728 (131072K bytes) Physical memory chunk(s): 0x00001000 - 0x0009efff, 647168 bytes (158 pages) 0x00322000 - 0x07ff7fff, 130899968 bytes (31958 pages) avail memory = 126820352 (123848K bytes) Programming 24 pins in IOAPIC #0 SMP: CPU0 apic_initialize(): lint0: 0x00000700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfec08000 cpu1 (AP): apic id: 12, version: 0x00040011, at 0xfec08000 io0 (APIC): apic id: 13, version: 0x00170011, at 0xfec00000 bios32: Found BIOS32 Service Directory header at 0xc00fd970 bios32: Entry = 0xfd980 (c00fd980) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xd9a1 pnpbios: Found PnP BIOS data at 0xc00fa170 pnpbios: Entry = f0000:a270 Rev = 1.0 Other BIOS signatures found: ACPI: 00000000 Preloaded elf kernel "kernel" at 0xc0306000. Pentium Pro MTRR support enabled SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000010 SVR: 0x000001ff pci_open(1): mode 1 addr port (0x0cf8) is 0x80000058 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=12378086) npx0: on motherboard npx0: INT 16 interface pci_open(1): mode 1 addr port (0x0cf8) is 0x00000000 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=12378086) pcib0: on motherboard found-> vendor=0x8086, dev=0x1237, revid=0x02 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 Freeing (NOT implemented) redirected PCI irq 9. found-> vendor=0x8086, dev=0x1229, revid=0x02 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=18 map[0]: type 1, range 32, base ffbae000, size 12 map[1]: type 1, range 32, base 0000ff40, size 5 map[2]: type 1, range 32, base fef00000, size 20 found-> vendor=0x8086, dev=0x7000, revid=0x01 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0 secondarybus=0 found-> vendor=0x8086, dev=0x7010, revid=0x00 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[4]: type 1, range 32, base 0000ffa0, size 4 found-> vendor=0x8086, dev=0x7020, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=d, irq=9 map[4]: type 1, range 32, base 0000ff80, size 5 Freeing (NOT implemented) redirected PCI irq 11. found-> vendor=0x9004, dev=0x8078, revid=0x00 class=01-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=17 map[0]: type 1, range 32, base 0000f400, size 8 map[1]: type 1, range 32, base ffbaf000, size 12 Freeing (NOT implemented) redirected PCI irq 10. found-> vendor=0x1000, dev=0x000f, revid=0x14 class=01-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0 secondarybus=0 intpin=a, irq=16 map[0]: type 1, range 32, base 0000f800, size 8 map[1]: type 1, range 32, base ffbea800, size 8 map[2]: type 1, range 32, base ffbe8000, size 12 Freeing (NOT implemented) redirected PCI irq 10. found-> vendor=0x1000, dev=0x000f, revid=0x14 class=01-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0 secondarybus=0 intpin=a, irq=16 map[0]: type 1, range 32, base 0000fc00, size 8 map[1]: type 1, range 32, base ffbeac00, size 8 map[2]: type 1, range 32, base ffbe9000, size 12 found-> vendor=0x8086, dev=0x0960, revid=0x03 class=06-04-00, hdrtype=0x01, mfdev=1 subordinatebus=1 secondarybus=1 found-> vendor=0x8086, dev=0x1960, revid=0x03 class=01-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0 secondarybus=0 intpin=a, irq=11 map[0]: type 1, range 32, base ffbd0000, size 16 Freeing (NOT implemented) redirected PCI irq 9. found-> vendor=0x109e, dev=0x0350, revid=0x12 class=04-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=18 map[0]: type 1, range 32, base ffbeb000, size 12 Freeing (NOT implemented) redirected PCI irq 9. found-> vendor=0x102b, dev=0x0519, revid=0x01 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=19 map[0]: type 1, range 32, base ffbec000, size 14 map[1]: type 1, range 32, base ff000000, size 23 pci0: on pcib0 fxp0: irq 18 at device 6.0 on pci0 fxp0: Ethernet address 00:a0:c9:55:9e:4f bpf: fxp0 attached isab0: at device 7.0 on pci0 I/O Recovery Timing: 8-bit 1 clocks, 16-bit 1 clocks Extended BIOS: enabled Lower BIOS: enabled Coprocessor IRQ13: enabled Mouse IRQ12: disabled Interrupt Routing: A: IRQ10, B: IRQ11, C: IRQ9, D: IRQ9 MB0: , MB1: Trying Read_Port at 203 CSC0000: start dependant CSC0000: adding dma mask 0x2 CSC0000: adding dma mask 0x9 CSC0000: adding irq mask 0x20 CSC0000: adding io range 0x534-0x537, size=0x4, align=0x4 CSC0000: adding io range 0x388-0x38b, size=0x4, align=0x8 CSC0000: adding io range 0x220-0x22f, size=0x10, align=0x20 CSC0000: start dependant CSC0000: adding dma mask 0xa CSC0000: adding dma mask 0xb CSC0000: adding irq mask 0x9aa0 CSC0000: adding io range 0x534-0xfff, size=0x4, align=0x4 CSC0000: adding io range 0x388-0x38b, size=0x4, align=0x8 CSC0000: adding io range 0x220-0x26f, size=0x10, align=0x20 CSC0000: start dependant CSC0000: adding dma mask 0xb CSC0000: adding irq mask 0x9aa0 CSC0000: adding io range 0x534-0xfff, size=0x4, align=0x4 CSC0000: adding io range 0x388-0x3fb, size=0x4, align=0x8 CSC0000: adding io range 0x220-0x30f, size=0x10, align=0x20 CSC0000: end dependant CSC0001: start dependant CSC0001: adding io range 0x200-0x207, size=0x8, align=0x8 CSC0001: start dependant CSC0001: adding io range 0x208-0x20f, size=0x8, align=0x8 CSC0001: end dependant CSC0010: adding io range 0x120-0xfff, size=0x8, align=0x8 CSC0003: start dependant CSC0003: adding irq mask 0x200 CSC0003: adding io range 0x330-0x331, size=0x2, align=0x8 CSC0003: start dependant CSC0003: adding irq mask 0x9a00 CSC0003: adding io range 0x300-0x3f9, size=0x2, align=0x8 CSC0003: end dependant isa0: on isab0 ata-pci0: at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0: iobase=0x01f0 altiobase=0x03f6 ata0: mask=03 status0=50 status1=00 ata0: mask=03 status0=50 status1=00 ata0: devices = 0x1 ata0 at 0x01f0 irq 14 on ata-pci0 ata1: iobase=0x0170 altiobase=0x0376 ata1: mask=00 status0=ff status1=ff chip1: irq 9 at device 7.2 on pci0 ahc0: irq 17 at device 9.0 on pci0 ahc0: Reading SEEPROM...done. ahc0: Low byte termination Enabled ahc0: High byte termination Enabled ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc0: Downloading Sequencer Program... 411 instructions downloaded ncr0: irq 16 at device 11.0 on pci0 ncr0: minsync=12, maxsync=137, maxoffs=16, 128 dwords burst, large dma fifo ncr0: single-ended, open drain IRQ driver, using on-chip SRAM ncr1: irq 16 at device 11.1 on pci0 ncr1: minsync=12, maxsync=137, maxoffs=16, 128 dwords burst, large dma fifo ncr1: single-ended, open drain IRQ driver, using on-chip SRAM using shared irq16. pcib1: at device 15.0 on pci0 pci1: on pcib1 amr0: irq 11 at device 15.1 on pci0 amr0: firmware GH6B bios 1.41 32MB memory, chipset 61 amrd0: on amr0 amrd0: 1553MB (3180544 sectors), state 0x2 properties 0x1 Creating DISK amrd0 amrd1: on amr0 amrd1: 3072MB (6291456 sectors), state 0x2 properties 0x0 Creating DISK amrd1 bktr0: irq 18 at device 17.0 on pci0 using shared irq18. iicbb0: on bti2c0 iicbus0: on iicbb0 master-only iicbus: iic devclass not found smbus0: on bti2c0 smbus: smb devclass not found brooktree0: PCI bus latency is 136. bktr0: buffer size 3555328, addr 0x5000000 bktr: GPIO is 0x003ffffb bktr0: Hauppauge Model 56131 E Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner, dbx stereo. vga-pci0: irq 19 at device 19.0 on pci0 fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 psm0: current command byte:0065 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm: status 00 02 64 psm: status b1 03 c8 psm: status b1 03 c8 psm: status b1 03 c8 psm: status 00 00 3c psm: data 08 00 00 psm: status 00 02 64 psm: data 08 00 00 psm: status 00 02 64 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0-00, 3 buttons psm0: config:00000000, flags:00000000, packet size:3 psm0: syncmask:c0, syncbits:00 vga0: at port 0x3b0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3b0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 60 4f 50 83 55 81 bf 1f 00 4f 0d 0e 00 00 06 40 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 60 4f 50 83 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 60 4f 50 83 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sc0: fb0 kbd0 sio0: irq maps: 0x8063 0x8073 0x8063 0x8063 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio1: irq maps: 0x8063 0x806b 0x8063 0x8063 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A pcm0: at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0 pcm: setmap 40000, ff00; 0xc88d3000 -> 40000 pcm: setmap 50000, ff00; 0xc88e3000 -> 50000 unknown0: at port 0x200-0x207 on isa0 unknown1: at port 0x120-0x127 on isa0 unknown2: at port 0x330-0x331 irq 9 on isa0 SMP: enabled INTs: 1, 3, 4, 5, 6, 11, 12, 14, 16, 17, 18, apic_imen: 0x00f8a785 BIOS Geometries: 0:03fefe3f 0..1022=1023 cylinders, 0..254=255 heads, 1..63=63 sectors 1:00c4fe3f 0..196=197 cylinders, 0..254=255 heads, 1..63=63 sectors 2:0186fe3f 0..390=391 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for Device configuration finished. APIC_IO: routing 8254 via 8259 on pin 0 bpf: lo0 attached Linux-ELF exec handler installed SMP: AP CPU #1 Launched! SMP: CPU1 apic_initialize(): lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff ata0: master: success setting up WDMA2 mode on PIIX4 chip ad0: piomode=4 dmamode=2 udmamode=2 ad0: ATA-4 disk at ata0 as master ad0: 9671MB (19807200 sectors), 19650 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 31 depth queue, DMA Creating DISK ad0 Creating DISK wd0 Waiting 2 seconds for SCSI devices to settle To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 6 12:16:27 1999 Delivered-To: freebsd-smp@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 3AB8615514; Mon, 6 Dec 1999 12:16:19 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id PAA07442; Mon, 6 Dec 1999 15:16:02 -0500 (EST) (envelope-from luoqi) Date: Mon, 6 Dec 1999 15:16:02 -0500 (EST) From: Luoqi Chen Message-Id: <199912062016.PAA07442@lor.watermarkgroup.com> To: cc@137.org, msmith@FreeBSD.ORG Subject: Re: incorrect irqs with pci devices Cc: smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > They are on my box, where incorrect is defined as the interrupts not > reaching > > > their supposed destination. I would really like to fix this, but I don't > > > know enough about exactly what is wrong. Any ideas would really be > > > appreciated, as I would like to remove my disgusting hack. :) > > > > > > I have an AMI raid controller that the system reports that it is on irq 11. > > > The problem is that the interrupts actually go to irq 17. If I hard wire > > > them with The irq 11 you saw in the system report (care to share with us what kind of report that was) must be for the PIC compatible mode. When the IO APIC is in the symmetric I/O mode, the interrupt should be routed through pin #17 of the IO APIC (that is if mptable is correct). If the interrupt was still routed to pin #11, then your mptable (BIOS) must be broken. Try to find out if there is a BIOS update available for your motherboard. As far as I can tell, our code is correct. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 6 13: 1:24 1999 Delivered-To: freebsd-smp@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id AE1051561D; Mon, 6 Dec 1999 13:01:05 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id QAA08375; Mon, 6 Dec 1999 16:01:02 -0500 (EST) (envelope-from luoqi) Date: Mon, 6 Dec 1999 16:01:02 -0500 (EST) From: Luoqi Chen Message-Id: <199912062101.QAA08375@lor.watermarkgroup.com> To: cc@137.org, msmith@FreeBSD.ORG Subject: Re: incorrect irqs with pci devices Cc: smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > They are on my box, where incorrect is defined as the interrupts not > > reaching > > > > their supposed destination. I would really like to fix this, but I don't > > > > know enough about exactly what is wrong. Any ideas would really be > > > > appreciated, as I would like to remove my disgusting hack. :) > > > > > > > > I have an AMI raid controller that the system reports that it is on irq 11. > > > > The problem is that the interrupts actually go to irq 17. If I hard wire > > > > them with > > The irq 11 you saw in the system report (care to share with us what kind of > report that was) must be for the PIC compatible mode. When the IO APIC is > in the symmetric I/O mode, the interrupt should be routed through pin #17 > of the IO APIC (that is if mptable is correct). If the interrupt was still > routed to pin #11, then your mptable (BIOS) must be broken. Try to find out > if there is a BIOS update available for your motherboard. As far as I can > tell, our code is correct. > > -lq > Sorry, I have to correct my own diagnosis, I didn't read your report carefully enough. It looked as if your AMI raid controller comes with a PCI-to-PCI bridge, is that right? It is interesting to see the controller was probed as on pci0, not behind the bridge on pci1. I recall there're problems with SMP motherboards and PCI-to-PCI bridges, but I don't know enough to say anything about it. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 6 13:50:37 1999 Delivered-To: freebsd-smp@freebsd.org Received: from friley-160-236.res.iastate.edu (friley-160-236.res.iastate.edu [129.186.160.236]) by hub.freebsd.org (Postfix) with ESMTP id EEC2414F9A; Mon, 6 Dec 1999 13:50:34 -0800 (PST) (envelope-from cc@137.org) Received: from ameslab.gov (friley-160-235.res.iastate.edu [129.186.160.235]) by friley-160-236.res.iastate.edu (Postfix) with ESMTP id 58AE4123; Mon, 6 Dec 1999 15:22:29 -0600 (CST) Message-ID: <384C2915.4E13A3D8@ameslab.gov> Date: Mon, 06 Dec 1999 15:22:29 -0600 From: Chris Csanady X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.5 i386) X-Accept-Language: en, ru, ja, ko MIME-Version: 1.0 To: Luoqi Chen Cc: msmith@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: incorrect irqs with pci devices References: <199912062101.QAA08375@lor.watermarkgroup.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luoqi Chen wrote: > > > > > > They are on my box, where incorrect is defined as the interrupts not > > > reaching > > > > > their supposed destination. I would really like to fix this, but I don't > > > > > know enough about exactly what is wrong. Any ideas would really be > > > > > appreciated, as I would like to remove my disgusting hack. :) > > > > > > > > > > I have an AMI raid controller that the system reports that it is on irq 11. > > > > > The problem is that the interrupts actually go to irq 17. If I hard wire > > > > > them with > > > > The irq 11 you saw in the system report (care to share with us what kind of > > report that was) must be for the PIC compatible mode. When the IO APIC is > > in the symmetric I/O mode, the interrupt should be routed through pin #17 > > of the IO APIC (that is if mptable is correct). If the interrupt was still > > routed to pin #11, then your mptable (BIOS) must be broken. Try to find out > > if there is a BIOS update available for your motherboard. As far as I can > > tell, our code is correct. I unfortunately have not been able to update the bios. However, this board is one of the few that is "Whitelisted" by the linux kernel--so I assume it is correct. > > -lq > > > Sorry, I have to correct my own diagnosis, I didn't read your report carefully > enough. It looked as if your AMI raid controller comes with a PCI-to-PCI > bridge, is that right? It is interesting to see the controller was probed > as on pci0, not behind the bridge on pci1. I recall there're problems with > SMP motherboards and PCI-to-PCI bridges, but I don't know enough to say > anything about it. > > -lq Yes, the device is bridged--I should have probably mentioned that. I don't really understand how this works either. I had thought that the problems with PCI-PCI bridges were cleared up a while ago, but I'm not sure. I would have thought it should be probed as being on bus 1 though. The mptable matches (bus ?, device 9, irq 11) which is the adaptec, but does not match (bus ?, device 15, irq 11) which is the megaraid. I don't recall the ?, but I'm pretty sure the bus matched. I don't understand how this relates to the output of mptable, which does not mention device #. :\ Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 6 14:21:30 1999 Delivered-To: freebsd-smp@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id 50DD614C3F for ; Mon, 6 Dec 1999 14:21:25 -0800 (PST) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.9.3/8.9.3) id QAA22088; Mon, 6 Dec 1999 16:21:19 -0600 (CST) Date: Mon, 6 Dec 1999 16:21:19 -0600 From: "Matthew D. Fuller" To: Kelly Yancey Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Most Beautiful Baby Contest! + an actual question Message-ID: <19991206162119.U22444@futuresouth.com> References: <199912042157.NAA04852@mass.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: X-OS: FreeBSD Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Dec 04, 1999 at 05:45:30PM -0500, a little birdie told me that Kelly Yancey remarked > On Sat, 4 Dec 1999, Mike Smith wrote: > > > > While I'm here, I'd like to know if anyone's tried and had success with any > > > quad-, six-proc-, or eight-proc motherboards with FreeBSD (3.x or -CURRENT). > > > Just curious. > > > > Can we change the subject of this thread? I'm not looking forward to > telling someone to look though the archives for "Most Beautiful Baby > Contest" when they come looking for 8-proc motherboards :) Are you kidding? If I had an 8-proc system sitting around, it'd certainly be *MY* Most Beautiful Baby! OTOH, *ARE* there any officially-supported 8-way setups on Intel hardware? Do any non-custom chips[sets] really even support better than 4-way? I have a 6-way PPro motherboard gathering dust in a box at home, but I believe it was a fairly custom (if large-quantity) job. Mmm. I have a sudden desire to run the world's first 32-processor P-66 system. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ FutureSouth Communications | ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 6 14:28:47 1999 Delivered-To: freebsd-smp@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 7022414FEB for ; Mon, 6 Dec 1999 14:28:44 -0800 (PST) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id QAA15624; Mon, 6 Dec 1999 16:28:43 -0600 (CST) Received: (from jlemon@localhost) by right.PCS (8.8.5/8.6.4) id QAA16661; Mon, 6 Dec 1999 16:28:41 -0600 (CST) Message-ID: <19991206162841.09664@right.PCS> Date: Mon, 6 Dec 1999 16:28:41 -0600 From: Jonathan Lemon To: "Matthew D. Fuller" Cc: smp@freebsd.org Subject: Re: Most Beautiful Baby Contest! + an actual question References: <199912042157.NAA04852@mass.cdrom.com> <19991206162119.U22444@futuresouth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <19991206162119.U22444@futuresouth.com>; from Matthew D. Fuller on Dec 12, 1999 at 04:21:19PM -0600 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Dec 12, 1999 at 04:21:19PM -0600, Matthew D. Fuller wrote: > OTOH, *ARE* there any officially-supported 8-way setups on Intel > hardware? Do any non-custom chips[sets] really even support better than > 4-way? I have a 6-way PPro motherboard gathering dust in a box at home, > but I believe it was a fairly custom (if large-quantity) job. This wouldn't be an ALR machine? (Also known as Aquanta, and resold by Gateway). I just got one of those things, and it's sitting right here, it's 6 PPros humming away, running FreeBSD. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 6 17:13:48 1999 Delivered-To: freebsd-smp@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 80A7F15061 for ; Mon, 6 Dec 1999 17:13:44 -0800 (PST) (envelope-from marc@oldserver.demon.nl) Received: from [212.238.105.241] (helo=propro) by post.mail.nl.demon.net with esmtp (Exim 2.12 #1) id 11v9C7-0008he-00 for freebsd-smp@freebsd.org; Tue, 7 Dec 1999 01:13:35 +0000 Date: Tue, 7 Dec 1999 02:13:27 +0100 (CET) From: Marc Schneiders To: freebsd-smp@freebsd.org Subject: bogus MP table Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following error occurs with an SMP-kernel of 4.0 current (as of two hours ago, but also with source of two days old): bogus MP table, 2 IO APIC pins connected to the same PCI device or ISA/EISA interrupt I presume the problem is: npx0: INT 16 [...] ncr0: irq 16 ... after the ncr0 the bogus MP pops up, and panic. Two things are quite strange here: 1. This box (ECS Elite P6FX2-A, dual PPro 200) has been running FreeBSD, both 3.3 and 4.0 before, without any problem. Another box, same board, two PPro 180, is running 4.0 ok for some months. But it does not have the ncr. Is there a way to tell the controller to pick another IRQ?? 2. The GENERIC kernel was running ok on the panicking box. Now it does not run anymore. It hangs while probing ed0 (SMC/WD 8013EPC). If I remove that it works again. I reinstalled from scratch and rebuilt the SMP-kernel. No joy. Any ideas, references, anything? TIA! Marc Schneiders marc@venster.nl marc@oldserver.demon.nl propro 2:02am up 22:51, load average: 2.29 2.30 2.13 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Dec 7 16:27:34 1999 Delivered-To: freebsd-smp@freebsd.org Received: from opus.cts.cwu.edu (opus.cts.cwu.edu [198.104.92.71]) by hub.freebsd.org (Postfix) with ESMTP id BE86514D00; Tue, 7 Dec 1999 16:27:27 -0800 (PST) (envelope-from skynyrd@opus.cts.cwu.edu) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.9.3/8.9.1) with ESMTP id QAA04519; Tue, 7 Dec 1999 16:27:08 -0800 (PST) Date: Tue, 7 Dec 1999 16:27:07 -0800 (PST) From: Chris Timmons To: Luoqi Chen Cc: cc@137.org, msmith@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: incorrect irqs with pci devices In-Reply-To: <199912062101.QAA08375@lor.watermarkgroup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org A couple of years ago to get an adaptec 3940 with the PCI-to-PCI bridge to work, one had to hack around in the code and customize a table entry or two, as described in: http://www.freebsd.org/~fsmp/SMP/pcibridge.html *WARNING* enough may have changed in the SMP implementation since the article was written, so it may not accurately reflect the status quo any longer. -Chris On Mon, 6 Dec 1999, Luoqi Chen wrote: > Sorry, I have to correct my own diagnosis, I didn't read your report carefully > enough. It looked as if your AMI raid controller comes with a PCI-to-PCI > bridge, is that right? It is interesting to see the controller was probed > as on pci0, not behind the bridge on pci1. I recall there're problems with > SMP motherboards and PCI-to-PCI bridges, but I don't know enough to say > anything about it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Dec 8 7:18:59 1999 Delivered-To: freebsd-smp@freebsd.org Received: from shaft.noc.clara.net (shaft.noc.clara.net [195.8.70.216]) by hub.freebsd.org (Postfix) with ESMTP id 2F04014D47 for ; Wed, 8 Dec 1999 07:18:54 -0800 (PST) (envelope-from mivens@clara.net) Received: (from mark@localhost) by shaft.noc.clara.net (8.9.3/8.9.3) id PAA75623 for freebsd-smp@freebsd.org; Wed, 8 Dec 1999 15:18:53 GMT Date: Wed, 8 Dec 1999 15:18:53 +0000 From: Mark Ivens To: freebsd-smp@freebsd.org Subject: tx0 interface lock-ups Message-ID: <19991208151853.H71307@clara.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I've been trying a 3.3-RELEASE SMP kernel with an old Micronics M54E2 motherboard we have (its a Neptune chipset so it only supports MP 1.1). Unfortunately the tx0 (SMC Etherpower II 9432) interface sporadically locks up with repeated error messages of the form /kernel: tx0: device timeout 16 packets, seems we can continue normaly Ifconfig-ing the interface down then up from the console gets the box back on the network. Being an SMP newbie if I understand the documentation correctly, the problem with PCI bridging doesn't seem to apply as the NIC and Adaptec card are on pci0.13.0 and pci0.15.0. I presume this means that neither card is bridged. I was wondering if this way a case of error in my part in configuring the kernel or if its something more serious. If it something more serious, what is the best way that I can help get this resolved? I would be very grateful for any advice you could give. Relevant bits from kernel config: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O options NCPU=2 # number of CPUs options NBUS=3 # number of busses #options NAPIC=1 # number of IO APICs options NINTR=16 # number of INTs mptable output: =============================================================================== MPTable, version 2.0.15 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: EBDA physical address: 0x0009fcc0 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0xca mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x0009fcd4 signature: 'PCMP' base table length: 260 version: 1.1 checksum: 0x1e OEM ID: 'INTEL ' Product ID: '430 NX EISA ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 24 local APIC address: 0xfee00000 extended table length: 0 extended table checksum: 0 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x10 BSP, usable 5 2 12 0x03bf 1 0x10 AP, usable 5 2 12 0x03bf -- Bus: Bus ID Type 0 ISA 1 EISA 2 PCI -- I/O APICs: APIC ID Version State Address 2 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT active-hi edge 0 0 2 0 INT conforms conforms 0 1 2 1 INT conforms conforms 0 0 2 2 INT conforms conforms 0 3 2 3 INT conforms conforms 0 4 2 4 INT conforms conforms 0 5 2 5 INT conforms conforms 0 6 2 6 INT conforms conforms 0 7 2 7 INT conforms conforms 0 8 2 8 INT conforms conforms 0 9 2 9 INT conforms conforms 0 10 2 10 INT conforms conforms 0 11 2 11 INT conforms conforms 0 12 2 12 INT conforms conforms 0 13 2 13 INT conforms conforms 0 14 2 14 INT conforms conforms 0 15 2 15 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT active-hi edge 0 0 255 0 NMI active-hi edge 0 0 255 1 Dmesg output: Dec 8 10:09:25 eros /kernel: Copyright (c) 1992-1999 FreeBSD Inc. Dec 8 10:09:25 eros /kernel: Copyright (c) 1982, 1986, 1989, 1991, 1993 Dec 8 10:09:25 eros /kernel: The Regents of the University of California. All rights reserved. Dec 8 10:09:25 eros /kernel: FreeBSD 3.3-RELEASE #7: Tue Dec 7 19:05:01 GMT 1999 Dec 8 10:09:25 eros /kernel: mark@eros.clara.net:/usr/src/sys/compile/EROS Dec 8 10:09:25 eros /kernel: Timecounter "i8254" frequency 1193182 Hz Dec 8 10:09:25 eros /kernel: CPU: Pentium/P54C (586-class CPU) Dec 8 10:09:25 eros /kernel: Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Dec 8 10:09:25 eros /kernel: Features=0x3bf Dec 8 10:09:25 eros /kernel: real memory = 536870912 (524288K bytes) Dec 8 10:09:25 eros /kernel: config> q Dec 8 10:09:25 eros /kernel: avail memory = 519532544 (507356K bytes) Dec 8 10:09:25 eros /kernel: Programming 16 pins in IOAPIC #0 Dec 8 10:09:25 eros /kernel: FreeBSD/SMP: Multiprocessor motherboard Dec 8 10:09:25 eros /kernel: cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee00000 Dec 8 10:09:25 eros /kernel: cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee00000 Dec 8 10:09:25 eros /kernel: io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec00000 Dec 8 10:09:25 eros /kernel: Preloaded elf kernel "kernel" at 0xc0298000. Dec 8 10:09:25 eros /kernel: Preloaded userconfig_script "/boot/kernel.conf" at 0xc029809c. Dec 8 10:09:25 eros /kernel: eisa0: Dec 8 10:09:25 eros /kernel: Probing for devices on the EISA bus Dec 8 10:09:25 eros /kernel: Probing for devices on PCI bus 0: Dec 8 10:09:25 eros /kernel: chip0: rev 0x11 on pci0.0.0 Dec 8 10:09:25 eros /kernel: chip1: rev 0x05 on pci0.2.0 Dec 8 10:09:25 eros /kernel: tx0: rev 0x06 int a irq 11 on pci0.13.0 Dec 8 10:09:25 eros /kernel: tx0: address 00:e0:29:22:71:4a, type SMC9432TX, Auto-Neg 100Mbps Dec 8 10:09:25 eros /kernel: ahc0: rev 0x01 int a irq 9 on pci0.15.0 Dec 8 10:09:25 eros /kernel: ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs Dec 8 10:09:25 eros /kernel: Probing for PnP devices: Dec 8 10:09:25 eros /kernel: Probing for devices on the ISA bus: Dec 8 10:09:25 eros /kernel: sc0 on isa Dec 8 10:09:25 eros /kernel: sc0: VGA color <16 virtual consoles, flags=0x0> Dec 8 10:09:25 eros /kernel: atkbdc0 at 0x60-0x6f on motherboard Dec 8 10:09:25 eros /kernel: atkbd0 irq 1 on isa Dec 8 10:09:25 eros /kernel: psm0 not found Dec 8 10:09:25 eros /kernel: sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa Dec 8 10:09:25 eros /kernel: sio0: type 16550A Dec 8 10:09:25 eros /kernel: sio1 at 0x2f8-0x2ff irq 3 on isa Dec 8 10:09:25 eros /kernel: sio1: type 16550A Dec 8 10:09:25 eros /kernel: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa Dec 8 10:09:25 eros /kernel: fdc0: FIFO enabled, 8 bytes threshold Dec 8 10:09:25 eros /kernel: fd0: 1.44MB 3.5in Dec 8 10:09:25 eros /kernel: vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa Dec 8 10:09:25 eros /kernel: npx0 on motherboard Dec 8 10:09:25 eros /kernel: npx0: INT 16 interface Dec 8 10:09:25 eros /kernel: stray irq 7 Dec 8 10:09:25 eros /kernel: Intel Pentium detected, installing workaround for F00F bug Dec 8 10:09:25 eros /kernel: APIC_IO: Testing 8254 interrupt delivery Dec 8 10:09:25 eros /kernel: APIC_IO: routing 8254 via pin 2 Dec 8 10:09:26 eros /kernel: IP packet filtering initialized, divert disabled, rule-based forwarding disabled, default to accept, logging limited to 10 packets /entry by default Dec 8 10:09:26 eros /kernel: ccd0-3: Concatenated disk drivers -- ---------------------------------------------------------------------- Mark Ivens mivens@clara.net Lottery: a tax Systems Administrator on people who ClaraNET UK Ltd 0207 903 3203 are bad at maths ---------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Dec 8 10:15:54 1999 Delivered-To: freebsd-smp@freebsd.org Received: from dns1.sjcoe.net (sjcoe.net [204.129.128.252]) by hub.freebsd.org (Postfix) with ESMTP id 8F5F4158F2 for ; Wed, 8 Dec 1999 10:15:36 -0800 (PST) (envelope-from kpugsley@dns1.sjcoe.net) Received: from [204.129.166.21] (intergate.lincolnusd.k12.ca.us [204.129.158.10]) by dns1.sjcoe.net (8.9.1b+Sun/8.9.1) with ESMTP id JAA26121 for ; Wed, 8 Dec 1999 09:57:28 -0800 (PST) Message-Id: <199912081757.JAA26121@dns1.sjcoe.net> X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Wed, 08 Dec 1999 09:53:08 -0800 Subject: CPU 1 lockup and strange mptable output on ALR 2-way From: "Ken Pugsley" To: freebsd-smp@freebsd.org Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm experiencing trouble with an older (yet new to me) ALR 2-way P133 machine. It seems to run fine with only one processor, but when I try to bring it up with a SMP kernel I get periodic crashes that seem to be attributed to processor 1 (more detail below). It seems to be only MP1.1 compliant, I can't find any settings in the BIOS for MP1.4. BTW: I'm using FreeBSD 3.3-RELEASE. The SMP kernel tends to stay up for 6-15 hours between crashes, and I've not been able to come up with any repeatable conditions to cause it. I run this machine predominantly as a web server (less than 5000 hits/day), with a number of associated scripts (all in perl). On crashing, I get messages on the screen, but not in the log files... I've tried a number of builds and options. When compiled with the NO_F00F_HACK flag in a SMP kernel, the system will generally reboot itself after crashing, but otherwise it behaves no better. Unfortunately I'm out of ideas to try and beyond my limited knowledge, so I'm hoping someone can help me. One other strange thing is the output from mptable. I do not get any output regarding "MP Config Base Table Entries". Is that normal for a system like this? Anyone able to help me on this? Am I simply going to have to let that second processor sit limp and lifeless? Any info or help greatly appreciated! Some details on crashes: below is some of the output on the screen from one crash that seems relevant (this is from a kernel without the NO_F00F_HACK option): CPU reset called on CPU#1 CPU reset: Stopping other CPUs panic: apic_ipi was stuck mp_lock=0.000002; cpuid=1 lapic.id=01000000 instruction pointer = 0x8:0xc0194838 stack pointer = 0x10: 0xc370a680 frame pointer = 0x10: 0xc370a6c8 code segment = base 0x0, limit 0xfffff, type 0x1b DPL 0, pres=1, def32 1, gran 1 processor eflags = interupt enabled, IOPL=0 current process = 7802 (perl) interupt mask = net tty boi cam <-SMP.XXX trap number = 29 panic: unknown/reserved trap mp_lock = 01000002; cpuid=1 lapic.id=01000000 boot() called on CPU# 1 Automatic reboot in 15 seconds Rebooting... cpu_reset called on CPU#1 cpu_reset: stopping other CPUs cpu_reset: Restarting BSP cpu_reset_proxy: Grabbed mp lock for BSP mptable output (while using my "semistable" SMP kernel): mptable -dmesg -verbose ============================================================================ === MPTable, version 2.0.15 looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009fc00 MP FPS found in Extended BIOS Data Area @ physical addr: 0x0009fc30 ---------------------------------------------------------------------------- --- MP Floating Pointer Structure: location: EBDA physical address: 0x0009fc30 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0x9d mode: Virtual Wire ---------------------------------------------------------------------------- --- MP default config type: 6 bus: EISA+PCI, APIC: Integrated ---------------------------------------------------------------------------- --- # SMP kernel config file options: # Required: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optional (built-in defaults will work in most cases): #options NCPU=2 # number of CPUs #options NBUS=2 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs ---------------------------------------------------------------------------- --- dmesg output: Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.3-RELEASE #0: Mon Nov 29 15:12:14 PST 1999 root@lhscience.lincolnusd.k12.ca.us:/usr/src/sys/compile/SMP4LHS1 Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P54C (586-class CPU) Origin = "GenuineIntel" Id = 0x52b Stepping = 11 Features=0x3bf real memory = 41943040 (40960K bytes) config> di sio1 No such device: sio1 Invalid command or syntax. Type `?' for help. config> di sio0 No such device: sio0 Invalid command or syntax. Type `?' for help. config> di ppc0 No such device: ppc0 Invalid command or syntax. Type `?' for help. config> di zp0 No such device: zp0 Invalid command or syntax. Type `?' for help. config> di ze0 No such device: ze0 Invalid command or syntax. Type `?' for help. config> di lnc0 No such device: lnc0 Invalid command or syntax. Type `?' for help. config> di le0 No such device: le0 Invalid command or syntax. Type `?' for help. config> di ie0 No such device: ie0 Invalid command or syntax. Type `?' for help. config> di fe0 No such device: fe0 Invalid command or syntax. Type `?' for help. config> di ex0 No such device: ex0 Invalid command or syntax. Type `?' for help. config> di ep0 No such device: ep0 Invalid command or syntax. Type `?' for help. config> di ed0 No such device: ed0 Invalid command or syntax. Type `?' for help. config> di cs0 No such device: cs0 Invalid command or syntax. Type `?' for help. config> di wt0 No such device: wt0 Invalid command or syntax. Type `?' for help. config> di wdc1 No such device: wdc1 Invalid command or syntax. Type `?' for help. config> di scd0 No such device: scd0 Invalid command or syntax. Type `?' for help. config> di mcd0 No such device: mcd0 Invalid command or syntax. Type `?' for help. config> di matcdc0 No such device: matcdc0 Invalid command or syntax. Type `?' for help. config> di bt0 No such device: bt0 Invalid command or syntax. Type `?' for help. config> di aha0 No such device: aha0 Invalid command or syntax. Type `?' for help. config> di adv0 No such device: adv0 Invalid command or syntax. Type `?' for help. config> q avail memory = 38567936 (37664K bytes) Programming 16 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc023b000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc023b09c. eisa0: Probing for devices on the EISA bus Probing for devices on PCI bus 0: chip0: rev 0x11 on pci0.0.0 chip1: rev 0x05 on pci0.2.0 xl0: <3Com 3c905B-TX Fast Etherlink XL> rev 0x30 int a irq 9 on pci0.15.0 xl0: Ethernet address: 00:50:da:72:b7:71 xl0: autoneg complete, link status good (half-duplex, 10Mbps) Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 1039MB (2128896 sectors), 2112 cyls, 16 heads, 63 S/T, 512 B/S vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface stray irq 7 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 changing root device to wd0s1a SMP: AP CPU #1 Launched! ============================================================================ === -- Ken Pugsley (kpugsley@sjcoe.net) Chemsitry Instructor Lincoln High School Stockton, CA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Dec 12 3:10:34 1999 Delivered-To: freebsd-smp@freebsd.org Received: from yyy.or.jp (mail.yyy.or.jp [202.214.252.21]) by hub.freebsd.org (Postfix) with SMTP id 2B2CF150CD for ; Sun, 12 Dec 1999 03:10:15 -0800 (PST) (envelope-from hnokubi@yyy.or.jp) Received: (qmail 54134 invoked from network); 12 Dec 1999 20:10:06 +0900 Received: from urayasu116.interwave.or.jp (HELO ppp-client.yyy.or.jp) (210.138.157.152) by mail.yyy.or.jp with SMTP; 12 Dec 1999 20:10:06 +0900 Received: from sassaby.nokubi.or.jp (sassaby [192.168.9.3]) by ppp-client.yyy.or.jp (8.9.1/3.5Wpl7-ppp) with ESMTP id UAA16411 for ; Sun, 12 Dec 1999 20:11:56 +0900 (JST) Received: from sassaby.nokubi.or.jp (localhost.nokubi.or.jp [127.0.0.1]) by sassaby.nokubi.or.jp (8.9.3/3.5Wpl7-glove) with ESMTP id UAA00746 for ; Sun, 12 Dec 1999 20:11:45 +0900 (JST) To: freebsd-smp@freebsd.org Subject: IRQ and APIC pin mapping question Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 12 Dec 1999 20:11:45 +0900 From: NOKUBI Hirotaka Message-Id: <19991212111015.2B2CF150CD@hub.freebsd.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello. I've been trying SMP kernel on NEC PC9821RvII which is not PC-AT compatible, FreeBSD PC98 port works fine on it with UP kernel. I made it possible to access MPCT at the top of the physical memory, SMP kernel works fine on it. But there is a problem around interrupt. Would you advice me about that? Almost all MPCT I've seen has same source IRQ# and destination APIC PIN#, like IRQ4 is connected to APIC PIN4. But PC9821RvII's MPCT shows some IRQ# is connected to different APIC PIN#, like IRQ8 is connected to APIC PIN7 (please see mptable output). My question is the meaning of int_to_apicintpin[]. Interrupt is managed with IRQ#, so it needs to know that which IRQ# corresponds to which APIC PIN#. Although I think that is the reason int_to_apicintpin[] is provided, initialization of it confused me. Function setup_apic_irq_mapping() initialize int_to_apicintpin[] using assign_apic_irq() with same value as argument `intpin' and `irq' (please see patch). It works fine on the machine which has same IRQ# and APIC PIN#. But on my PC9821RvII, it is impossible for kernel to get correct APIC PIN# corresponds to IRQ# to handle. For example, kernel wants to disable IRQ10, APIC PIN9 should be disabled, but without patch, kernel disables APIC PIN10. How can I fix this problem without affecting PC-AT compatible? ---- NOKUBI Hirotaka Fingerprint20 = DEBC 0793 7CD6 92F1 0A1F A792 9E2F EEEE A41B 171D =============================================================================== MPTable, version 2.0.15 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f50f0 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0xa1 mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x05fff704 signature: 'PCMP' base table length: 252 version: 1.4 checksum: 0x47 OEM ID: 'NEC ' Product ID: 'T63M0.06 ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 23 local APIC address: 0xfee00000 extended table length: 0 extended table checksum: 0 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x11 BSP, usable 6 3 3 0x0381 1 0x11 AP, usable 6 3 4 0x0381 -- Bus: Bus ID Type 0 NEC98 1 PCI -- I/O APICs: APIC ID Version State Address 2 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# INT active-hi edge 0 0 2 0 INT active-hi edge 0 1 2 1 INT active-hi edge 0 2 2 2 INT active-hi level 0 3 2 3 INT active-hi edge 0 4 2 4 INT active-hi edge 0 5 2 5 INT active-hi edge 0 6 2 6 INT active-hi edge 0 8 2 7 INT active-hi edge 0 9 2 8 INT active-hi level 0 10 2 9 INT active-hi edge 0 11 2 10 INT active-hi edge 0 12 2 11 INT active-hi edge 0 13 2 12 INT active-hi edge 0 14 2 13 INT active-hi edge 0 15 2 14 ExtINT active-hi edge 0 0 2 15 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT active-hi edge 0 0 0 0 NMI active-hi edge 0 1 0 1 ------------------------------------------------------------------------------- # SMP kernel config file options: # Required: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optional (built-in defaults will work in most cases): #options NCPU=2 # number of CPUs #options NBUS=2 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs =============================================================================== Index: i386/i386/mp_machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v retrieving revision 1.111 diff -u -u -r1.111 mp_machdep.c --- mp_machdep.c 1999/10/15 21:38:15 1.111 +++ mp_machdep.c 1999/12/12 10:59:25 @@ -966,7 +966,7 @@ int x; if (int_to_apicintpin[irq].ioapic != -1) - panic("assign_apic_irq: inconsistent table"); + return; int_to_apicintpin[irq].ioapic = apic; int_to_apicintpin[irq].int_pin = intpin; @@ -1070,7 +1070,7 @@ io_apic_ints[x].int_type == 3)) { assign_apic_irq(0, io_apic_ints[x].dst_apic_int, - io_apic_ints[x].dst_apic_int); + io_apic_ints[x].src_bus_irq); } } int_vector = 0; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Dec 12 20:51:20 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mtiwmhc01.worldnet.att.net (mtiwmhc01.worldnet.att.net [204.127.131.36]) by hub.freebsd.org (Postfix) with ESMTP id E773C14EC6 for ; Sun, 12 Dec 1999 20:51:00 -0800 (PST) (envelope-from Thrumbar@Worldnet.att.net) Received: from 11.neworleans-01-02rs16rt.la.dial-access.att.net ([12.73.238.11]) by mtiwmhc01.worldnet.att.net (InterMail v03.02.07.07 118-134) with SMTP id <19991213045058.GYMQ5516@11.neworleans-01-02rs16rt.la.dial-access.att.net> for ; Mon, 13 Dec 1999 04:50:58 +0000 From: Thrumbar Pathfinder To: freebsd-smp@freebsd.org Subject: Developer's Interface Guide for IA-64 Servers (DIG64) Adopter Date: Sun, 12 Dec 1999 22:47:57 -0600 Organization: OmniCorp Interstellar Message-ID: <94t85s8a563qkqk9378pnuem4ifm7g7bhc@4ax.com> X-Mailer: Forte Agent 1.7/32.534 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Attention, all FreeBSD, OpenBSD and NetBSD developers.. This is a chance we cannot ignore.. Please form up a development team with a central tram leader and get signed up for this offer. The Documentation personnel should sign up for the Contributors link to add BSD's voice in setting the guidelines for future BSD development for all three forms... Please read below.. (also, team leaders, send me a e-mail when you sign-up to keep me informed as to the process and to get an idea on how many teams there is involved) About the DIG64 Leading hardware and software vendors have formed an industry group to develop the DIG64 guidelines. These guidelines establish basic system building blocks, interfaces, and programming conventions for upcoming IA-64 based servers and their system-level software in order to define hardware and software compatibility and interoperability.=20 DIG64 is...=20 an industry-driven set of technical guidelines that define hardware, firmware and operating system's compatibility for IA-64 servers providing IT with systems built on common, stabilized interfaces that improve reliability and interoperability, lower qualification and support costs developed and backed by the key IA-64 OEMs, OSVs, and BIOS vendors who are contributing to its development and are building compliant products allowing the industry to accelerate the pace of IA-64 technology adoption=20 By defining common building blocks and interfaces and proactively addressing legacy issues, the DIG64 provides an array of benefits for both developers and IT organizations.=20 =46or developers, the DIG64: =20 Increases the efficiency of the design process, freeing developers to focus design resources of features that add unique value and differentiate their products in the marketplace. =20 Gives firmware and OS vendors a known set of interfaces to build to, enabling them to confidentially develop their products concurrently with the hardware and shrink time to markets. =20 Provides a technology migration roadmap that extends the planning horizon for developers and allows them to create designs with increased longevity.=20 =46or business users and Information Technology (IT) departments: =20 Standard interfaces and interoperable layers enhance the reliability and robustness of the resulting servers as well as lowering qualification costs. Since developers find it easier to build components that work together, customers can enjoy a greater choice of robust, innovative server solutions. Because the DIG64 addresses the migration of support-intensive, obsolete technologies to newer, more robust choices, IT departments can control or reduce the cost of server support.=20 DIG64 Defined =20 The DIG64 specification defines basic system building blocks, interfaces and programming conventions between IA-64 based servers and system-level software such as the operating system and device drivers. The specification covers:=20 Core system components such as the processor, chipset, memory, I/O bus, and server management hardware.=20 =20 Interfaces to peripheral devices for networking, communications and storage.=20 =20 Low-level firmware interfaces to the operating system for system configuration, boot and runtime services.=20 The guide does not create new standards and interfaces, but selects components and interfaces from already existing technologies. To ensure interoperability, the DIG64 also specifies implementation requirements for each specification or standard.=20 The DIG64 spells out a roadmap for eliminating obsolete technologies. Release 1.0, which is currently available , pertains to servers=20 based on the Intel=AE Itanium=99 processor. Subsequent versions will address future processors as they are developed. A three-level hierarchy of required, recommended and optional features enables vendors to choose how quickly they want to remove older technologies.=20 The DIG64 is operating-system independent, promoting cross-platform interoperability among servers running Windows 2000*, Linux and other UNIX* operating systems.=20 Join Other Industry Leaders Already Building Compatible IA-64 Server Solutions! =20 =20 There is still time to get involved by becoming a DIG64 Adopter member. To find out more about the advantages of becoming a DIG64 Adopter, take look at the DIG64 www site.... http://www.dig64.org/ To sign up as a Developer's Interface Guide for IA-64 Servers (DIG64) Adopter, complete all of the information at the link listed below and hit the submit button. You will then be able to download a "DIG64 Adopters Agreement". http://www.dig64.org/signup.htm By becoming a DIG64 Contributor, you will be able to provide technical input into the development of the DIG64 guidelines in addition to gaining access to the latest published draft. All input will be reviewed by the DIG64 Working Group for possible inclusion in the guideline. http://www.dig64.org/contributor.htm When you have formed your group please e-mail me so that I will know how many groups there are.. Please include a list of the individuals on the team and their position on said team as well as any contact information you are willing to provide... Thrumbar@Worldnet.att.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Dec 12 23:12:55 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mass.cdrom.com (castles516.castles.com [208.214.165.80]) by hub.freebsd.org (Postfix) with ESMTP id BD4FF14F72 for ; Sun, 12 Dec 1999 23:12:53 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id XAA05688; Sun, 12 Dec 1999 23:15:20 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912130715.XAA05688@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: remy@synx.com Cc: smp@freebsd.org Subject: Re: Fwd: Idle loop in SMP. In-reply-to: Your message of "Sun, 12 Dec 1999 15:11:08 +0100." <199912121411.PAA39511@gw0.boostworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 Dec 1999 23:15:20 -0800 From: Mike Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > (Forwarded to -current, due to lack of audience in -smp. Sorry for > bothering you). Wrong course of action. This should have stayed on -smp. > While investigating a temperature problem, I seen that the default_halt > entry called for an idle processor do not really halt the processor. I > found the reason on the CVS logs and it is intended to react to changes > made on the run queue by the other processor. (i386/i386/swtch.s, 1.61). > > Since this is dated Sept 97, can we expect a better solution regarding > the progress made in the SMP area ? Such as what? Any other solution adds overhead (eg. sending an IPI to a halted processor), and the rationale for SMP would seem to be performance, not economy. Naturally, patches that actually halted the idle CPUs and woke them in an efficient fashion would be accepted, but I don't think that anyone actively working on SMP currently considers this a major problem. (Hence the lack of response to your original post.) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 13 17:57: 5 1999 Delivered-To: freebsd-smp@freebsd.org Received: from relay.securify.com (relay.securify.com [207.5.63.61]) by hub.freebsd.org (Postfix) with SMTP id A8D491502C for ; Mon, 13 Dec 1999 17:56:54 -0800 (PST) (envelope-from tomb@cgf.net) Received: by relay.securify.com; id RAA27829; Mon, 13 Dec 1999 17:55:40 -0800 Received: from unknown(10.5.63.100) by relay.securify.com via smap (V5.5) id xma027719; Mon, 13 Dec 99 17:55:01 -0800 Message-ID: <3855A375.166D5E5C@cgf.net> Date: Mon, 13 Dec 1999 17:55:01 -0800 From: tomb X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-smp@FreeBSD.ORG Subject: Compaq proliant 1850R won't boot with new SMP kernel. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I'm trying to get SMP working on a Compaq ProLiant 1850R. Using FreeBSD 3.3. I unhashed the standard SMP options and built the kernel. Rebooted The first boot complained about the number of interupts. It even provided me with a suggestion to raise the number in the kernel to 36. Which I did (see below). Here's the SMP kernel options that I used. options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optionally these may need tweaked, (defaults shown): options NCPU=2 # number of CPUs options NBUS=4 # number of busses options NAPIC=2 # number of IO APICs options NINTR=36 # number of INTs The second time I boot with the newly increased number of NINTR's I got the following message at boot and the machine just freeze's. Config>q avail memory = 13307904 (122996K bytes) Programming 35 pin's in IOAPIC #0 IOAPIC #0 intpin 28->irq-1 IOAPIC #0 intpin 29->irq-1 IOAPIC #0 intpin 30->irq-1 IOAPIC #0 intpin 31->irq-1 And that's as far as it goes, it has to be powercycled!!! Any ideas would be welcomed.. Tom -- Tom Brown --------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 13 19:59:28 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mass.cdrom.com (castles528.castles.com [208.214.165.92]) by hub.freebsd.org (Postfix) with ESMTP id 7D454153F2 for ; Mon, 13 Dec 1999 19:59:20 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id UAA00486; Mon, 13 Dec 1999 20:02:15 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912140402.UAA00486@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: tomb Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Compaq proliant 1850R won't boot with new SMP kernel. In-reply-to: Your message of "Mon, 13 Dec 1999 17:55:01 PST." <3855A375.166D5E5C@cgf.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Dec 1999 20:02:14 -0800 From: Mike Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org These boxes can be a real pain in the rear. You'll need to boot the config CD and get into the system setup stuff in order to tweak the MP mode. Here's some information relating to the 1600; AFAIK the 1850 is going to be very similar: ---8<---snip---8<--- Many thanks to Steven J. Bauer for the pointer. I now have SMP working like a charm on the machine. The secret was to consult the web page: http://potter.ieee.uh.edu/compaq.html The summary is that I had to install the Compaq Configuration Utility onto the hard drive (using the Smartstart CD), reboot and press F10 to enter the Config Utility. At the first selection screen, press Ctrl-A to enter the advanced config (a dialogue box pops up to confirm) and select 'Configure Hardware'. Choose the manual configure (i.e: don't auto-detect) and skip to the 'Edit and Review details' menu. Move down to the 'APIC option' and set to 'Full Table' (nothing else). Save and reboot and if your kernel is SMP aware, you should be away. :-) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Dec 16 0: 6:27 1999 Delivered-To: freebsd-smp@freebsd.org Received: from dhcp9541090.columbus.rr.com (dhcp9541090.columbus.rr.com [24.95.41.90]) by hub.freebsd.org (Postfix) with ESMTP id 0094C14E1E for ; Thu, 16 Dec 1999 00:06:21 -0800 (PST) (envelope-from rowland@dhcp9541090.columbus.rr.com) Received: (from rowland@localhost) by dhcp9541090.columbus.rr.com (8.9.3/8.9.3) id CAA00562; Thu, 16 Dec 1999 02:37:40 -0500 (EST) (envelope-from rowland) To: freebsd-smp@freebsd.org Subject: ping -R kernel panic in 3.3-R SMP ? X-Face: "<|%>c@Vfv/8}+Av1z:R5sDzf!3QVer!n\,.&+&h\k1,BHAoyw8Gp10<-SqZ<*"|!U!a#xg6ls?1,Vj$m@r?uHcfB,'i:LLgtyb;~}O8v7zZThuB`X~#IE{v*"PhI]cl/>&ys(MGa%y:6~TuHFw&~|V?!9HZ_R"<}dC5D:%igP2Q6ZJex,P0M From: Shaun Rowland Date: 16 Dec 1999 02:37:40 -0500 Message-ID: <87u2ljmj3v.fsf@dhcp9541090.columbus.rr.com> Lines: 73 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Bryce Canyon" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was playing around with ping the other day and discovered that "ping -R" will cause my 3.3-R SMP system to panic. I get the following message when this occurs: Fatal trap 12: page fault while in kernel mode mp_lock = 000000002; cpuid = 0; lapic.id = 00000000 fault virtual address = 0x35000232 fault code = supervisor read, page not present instruction pointer = 0x8:0xc017dc92 stack pointer = 0x10:0xc5ebadf0 frame pointer = 0x10:0xc5ebadf8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1 prcessor eflags = inturrupt enabled, resume, IOPL=0 current process = 381 (ping) inturrupt mask = <- SMP : XXX kernel : type 12 trap, code = 0 Stopped at div_input + 0xca: movswl 0x22(%edx)%eax I have the DDB compiled into my kernel and my dumpdev set to my swap partition, but I did not get a crash dump (I am new at this if you cannot tell), but I assume the function this died in is div_input. If I do: nm /kernel |grep c017 I get the following list: c017df74 t div_abort c017deb0 t div_attach c017dfa8 t div_bind c017df50 t div_detach c017df8c t div_disconnect c017db68 T div_init c017dbc8 T div_input c017dd34 t div_output c017dfe8 t div_send c017dfd8 t div_shutdown c017d6b4 t in_addroute c017d808 t in_clsroute c017db28 T in_ifadown c017dad8 t in_ifadownkill c017da88 T in_inithead c017d2d4 T in_losing c017d7d8 t in_matroute c017d094 T in_pcbdetach c017d060 T in_pcbdisconnect c017d4e4 T in_pcbinshash c017d430 T in_pcblookup_hash c017d370 T in_pcblookup_local c017d1f8 T in_pcbnotify c017d5bc T in_pcbrehash c017d618 t in_pcbremlists c017d34c t in_rtchange c017da30 T in_rtqdrain c017d86c t in_rtqkill c017d918 t in_rtqtimo c017d180 T in_setpeeraddr c017d108 T in_setsockaddr of which the function in question is a member. If I had a crash dump I would attempt to fire up gdb on my debug kernel, but I do not. I'll work on that later, but I am not quite yet a kernel hacker. I apologize if this should go somewhere else as I have never had this type of thing happen. I was wondering if anyone else with an SMP system has seen, or can reproduce this problem that I have. This option to ping isn't all that useful, but the behavior is peculiar as this does not occur on my UP FreeBSD box. If I am in need of a ticket to ride the "clue-bus" a pointer to this fact would be appreciated :-) -- Shaun Rowland rowland@cis.ohio-state.edu http://www.cis.ohio-state.edu/~rowland/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Dec 16 13:53:57 1999 Delivered-To: freebsd-smp@freebsd.org Received: from opus.cts.cwu.edu (opus.cts.cwu.edu [198.104.92.71]) by hub.freebsd.org (Postfix) with ESMTP id B8498150A4 for ; Thu, 16 Dec 1999 13:49:22 -0800 (PST) (envelope-from skynyrd@opus.cts.cwu.edu) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.9.3/8.9.1) with ESMTP id NAA53482; Thu, 16 Dec 1999 13:48:58 -0800 (PST) Date: Thu, 16 Dec 1999 13:48:58 -0800 (PST) From: Chris Timmons To: Shaun Rowland Cc: freebsd-smp@FreeBSD.ORG Subject: Re: ping -R kernel panic in 3.3-R SMP ? In-Reply-To: <87u2ljmj3v.fsf@dhcp9541090.columbus.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just for a quick data point I tried it on a tyan dua-ppro running 3.4-RC and got the expected results for a couple of hosts at different distances from the machine. Does it panic no matter which host you are pinging, or does it only happen to certain hosts (or on some invocations to the same host but not all)? -c On 16 Dec 1999, Shaun Rowland wrote: > I was playing around with ping the other day and discovered that > "ping -R" will cause my 3.3-R SMP system to panic. I get the following > message when this occurs: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Dec 16 14: 4:59 1999 Delivered-To: freebsd-smp@freebsd.org Received: from darkstar.cis.ohio-state.edu (darkstar.cis.ohio-state.edu [164.107.114.52]) by hub.freebsd.org (Postfix) with ESMTP id C8A4315962 for ; Thu, 16 Dec 1999 14:04:52 -0800 (PST) (envelope-from rowland@darkstar.cis.ohio-state.edu) Received: (from rowland@localhost) by darkstar.cis.ohio-state.edu (8.9.3/8.9.3) id QAA13199; Thu, 16 Dec 1999 16:58:58 -0500 To: Chris Timmons Cc: freebsd-smp@FreeBSD.ORG Subject: Re: ping -R kernel panic in 3.3-R SMP ? References: From: Shaun Rowland Date: 16 Dec 1999 16:58:58 -0500 In-Reply-To: Chris Timmons's message of "Thu, 16 Dec 1999 13:48:58 -0800 (PST)" Message-ID: Lines: 15 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Bryce Canyon" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chris Timmons writes: > Does it panic no matter which host you are pinging, or does it only happen > to certain hosts (or on some invocations to the same host but not all)? I tried two different hostnames. One was on my local internal network (I do NAT through a cable modem) and the other was on a different network. Both times it generated a panic. I will try some different hosts and double check what I have seen so far. I did not try this without an actual hostname. I would think that prints the usage. When the panic occurs it happens immediately. The command does not work intermittently. -- Shaun Rowland rowland@cis.ohio-state.edu http://www.cis.ohio-state.edu/~rowland/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Dec 16 14: 9:43 1999 Delivered-To: freebsd-smp@freebsd.org Received: from alpha.netaccess.on.ca (alpha.netaccess.on.ca [199.243.225.10]) by hub.freebsd.org (Postfix) with ESMTP id 5791514DFB for ; Thu, 16 Dec 1999 14:09:40 -0800 (PST) (envelope-from rob@ControlQ.com) Received: from fatlady.controlq.com (dial151.nas.net [199.243.225.151]) by alpha.netaccess.on.ca (8.9.0/8.9.0) with SMTP id RAA11219; Thu, 16 Dec 1999 17:08:09 -0500 (EST) Date: Thu, 16 Dec 1999 17:12:59 -0500 (EST) From: "Robert S. Sciuk" Reply-To: "Robert S. Sciuk" To: Chris Timmons Cc: Shaun Rowland , freebsd-smp@FreeBSD.ORG Subject: Re: ping -R kernel panic in 3.3-R SMP ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org FYI, 3.3 Release Candidate, CVsupped to 3.3-RELEASE works OK as both sender and recipient of ping -R on my network -- it is a QDI m/b with dual 233's I DID have some instability with 3.3-RC-SMP, but the cvsup to the release level sorted that out ... Cheers, R. On Thu, 16 Dec 1999, Chris Timmons wrote: > > Just for a quick data point I tried it on a tyan dua-ppro running 3.4-RC > and got the expected results for a couple of hosts at different distances > from the machine. > > Does it panic no matter which host you are pinging, or does it only happen > to certain hosts (or on some invocations to the same host but not all)? > > -c > > On 16 Dec 1999, Shaun Rowland wrote: > > > I was playing around with ping the other day and discovered that > > "ping -R" will cause my 3.3-R SMP system to panic. I get the following > > message when this occurs: > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Dec 16 14:34:27 1999 Delivered-To: freebsd-smp@freebsd.org Received: from wiretap.read.tasc.com (wiretap.read.tasc.com [147.81.246.176]) by hub.freebsd.org (Postfix) with ESMTP id 9BDBB14C39 for ; Thu, 16 Dec 1999 14:34:24 -0800 (PST) (envelope-from ira@wiretap.read.tasc.com) Received: (from ira@localhost) by wiretap.read.tasc.com (8.8.8/8.8.8) id RAA00221; Thu, 16 Dec 1999 17:34:18 -0500 (EST) (envelope-from ira) To: freebsd-smp@freebsd.org Subject: Re: ping -R kernel panic in 3.3-R SMP ? References: From: ilcooper@tasc.com (Ira L. Cooper) Date: 16 Dec 1999 17:34:18 -0500 In-Reply-To: "Robert S. Sciuk"'s message of "Thu, 16 Dec 1999 17:12:59 -0500 (EST)" Message-ID: <86iu1ysefp.fsf@wiretap.read.tasc.com> Lines: 6 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Can you post the boot log from your machine so we know what hardware is involved? I tried this myself on a dual P2 400, with a 3COM 3C905C-TX and it worked just fine, with FreeBSD 3.4-RC. The motherboard is a TYAN S1836DLUAN. -Ira To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Dec 16 17:18:45 1999 Delivered-To: freebsd-smp@freebsd.org Received: from rins.st.ryukoku.ac.jp (rins.st.ryukoku.ac.jp [133.83.4.1]) by hub.freebsd.org (Postfix) with ESMTP id 9C6B5152F3 for ; Thu, 16 Dec 1999 17:18:34 -0800 (PST) (envelope-from fujii@humpty.elec.ryukoku.ac.jp) Received: from humpty.elec.ryukoku.ac.jp (humpty.elec.ryukoku.ac.jp [133.83.88.11]) by rins.st.ryukoku.ac.jp (8.9.3+3.2W/3.7W/RINS-1.9.6-NOSPAM) with ESMTP id KAA21435; Fri, 17 Dec 1999 10:18:31 +0900 (JST) Received: (from fujii@localhost) by humpty.elec.ryukoku.ac.jp (8.9.3/8.8.8(humpty)) id KAA01388; Fri, 17 Dec 1999 10:18:29 +0900 (JST) (envelope-from fujii) Message-Id: <199912170118.KAA01388@humpty.elec.ryukoku.ac.jp> From: fujii@elec.ryukoku.ac.jp (FUJII Daisuke) Date: Fri, 17 Dec 1999 10:18:28 +0900 In-Reply-To: Your message of "Fri, 17 Dec 1999 7:41 JST" X-Mailer: Mail User's Shell (7.2.6 beta(4) 03/19/98) To: "Robert S. Sciuk" , Chris Timmons Subject: Re: ping -R kernel panic in 3.3-R SMP ? Cc: Shaun Rowland , freebsd-smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ##Refer to# "Robert S. Sciuk", 99/Dec/17, ##Refer to# "Re: ping -R kernel panic in 3.3-R SMP ?" > > FYI, > > 3.3 Release Candidate, CVsupped to 3.3-RELEASE works OK as both sender and > recipient of ping -R on my network -- it is a QDI m/b with dual 233's > > I DID have some instability with 3.3-RC-SMP, but the cvsup to the release > level sorted that out ... > > Cheers, > R. > > > On Thu, 16 Dec 1999, Chris Timmons wrote: > > > > > Just for a quick data point I tried it on a tyan dua-ppro running 3.4-RC > > and got the expected results for a couple of hosts at different distances > > from the machine. > > > > Does it panic no matter which host you are pinging, or does it only happen > > to certain hosts (or on some invocations to the same host but not all)? > > > > -c > > > > On 16 Dec 1999, Shaun Rowland wrote: > > > > > I was playing around with ping the other day and discovered that > > > "ping -R" will cause my 3.3-R SMP system to panic. I get the following > > > message when this occurs: > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message ls To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Dec 16 17:38:49 1999 Delivered-To: freebsd-smp@freebsd.org Received: from kx2.lh.net (kx2.lh.net [216.81.128.204]) by hub.freebsd.org (Postfix) with ESMTP id 6C43D15680 for ; Thu, 16 Dec 1999 17:38:47 -0800 (PST) (envelope-from tom@winamp.com) Received: from winamp.com ([158.252.215.12]) by kx2.lh.net (InterMail v4.01.00 201-232-112) with ESMTP id <19991217013809.PZJ330.kx2@winamp.com> for ; Thu, 16 Dec 1999 20:38:09 -0500 Message-ID: <385994F8.1B0AF7CD@winamp.com> Date: Thu, 16 Dec 1999 17:42:16 -0800 From: Tom Pepper X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-smp@FreeBSD.ORG Subject: unsubscribe References: <199912170118.KAA01388@humpty.elec.ryukoku.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org unsubscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Dec 16 19:28:43 1999 Delivered-To: freebsd-smp@freebsd.org Received: from dhcp9541090.columbus.rr.com (dhcp9541090.columbus.rr.com [24.95.41.90]) by hub.freebsd.org (Postfix) with ESMTP id 26FF6152F6 for ; Thu, 16 Dec 1999 19:28:36 -0800 (PST) (envelope-from rowland@dhcp9541090.columbus.rr.com) Received: (from rowland@localhost) by dhcp9541090.columbus.rr.com (8.9.3/8.9.3) id WAA02245; Thu, 16 Dec 1999 22:26:34 -0500 (EST) (envelope-from rowland) To: freebsd-smp@FreeBSD.ORG Subject: Re: ping -R kernel panic in 3.3-R SMP ? References: <86iu1ysefp.fsf@wiretap.read.tasc.com> X-Face: "<|%>c@Vfv/8}+Av1z:R5sDzf!3QVer!n\,.&+&h\k1,BHAoyw8Gp10<-SqZ<*"|!U!a#xg6ls?1,Vj$m@r?uHcfB,'i:LLgtyb;~}O8v7zZThuB`X~#IE{v*"PhI]cl/>&ys(MGa%y:6~TuHFw&~|V?!9HZ_R"<}dC5D:%igP2Q6ZJex,P0M From: Shaun Rowland Date: 16 Dec 1999 22:26:34 -0500 In-Reply-To: ilcooper@tasc.com's message of "16 Dec 1999 17:34:18 -0500" Message-ID: <87hfhimemt.fsf@dhcp9541090.columbus.rr.com> Lines: 99 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Bryce Canyon" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ilcooper@tasc.com (Ira L. Cooper) writes: > Can you post the boot log from your machine so we know what hardware > is involved? I tried this myself on a dual P2 400, with a 3COM 3C905C-TX > and it worked just fine, with FreeBSD 3.4-RC. The motherboard is a TYAN > S1836DLUAN. > > -Ira I will see if a cvsup will fix my problem. For now I can deal with it (who uses -R anyway?). Here is my dmesg output: Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.3-RELEASE #6: Thu Dec 16 01:52:26 EST 1999 toor@dhcp9541090.columbus.rr.com:/usr/src/sys/compile/SERVER Timecounter "i8254" frequency 1193182 Hz CPU: Celeron (686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183fbff real memory = 134217728 (131072K bytes) avail memory = 127635456 (124644K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc02c9000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc02c909c. Pentium Pro MTRR support enabled Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x02 on pci0.1.0 chip2: rev 0x02 on pci0.7.0 ide_pci0: rev 0x01 on pci0.7.1 chip3: rev 0x02 on pci0.7.3 pn0: <82c169 PNIC 10/100BaseTX> rev 0x21 int a irq 16 on pci0.15.0 pn0: Ethernet address: 00:a0:cc:39:c9:7c pn0: autoneg complete, link status good (half-duplex, 10Mbps) fxp0: rev 0x05 int a irq 17 on pci0.16.0 bogus MP table, 2 IO APIC pins connected to the same PCI device or ISA/EISA interrupt Registered extra interrupt handler for int 19 (in addition to int 17) fxp0: Ethernet address 00:90:27:18:a3:75 vga0: rev 0x04 int a irq 17 on pci0.20.0 Probing for devices on PCI bus 1: Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A pcm0 at 0x220 irq 5 drq 1 flags 0x15 on isa fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-16 wd0: 26059MB (53369568 sectors), 52946 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 flags 0xa0ffa0ff on isa wdc1: unit 0 (atapi): , removable, accel, dma, iordis acd0: drive speed 4134KB/sec, 2048KB cache acd0: supported read types: CD-R, CD-RW, CD-DA, packet track acd0: supported write types: CD-R, CD-RW, test write acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked ppc0 at 0x378 irq 7 flags 0x40 on isa ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 plip0: on ppbus 0 vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 IP packet filtering initialized, divert enabled, rule-based forwarding disabled, logging limited to 100 packets/entry by default changing root device to wd0s1a SMP: AP CPU #1 Launched! This box is a dual Celeron 400. The only problem I have had is with the MP version in the BIOS. If I set it at 1.4 the output of mptable is corrupted. If I set the BIOS to MP 1.1 I am fine. Other than that this box runs very well. The performance, even though this is a Celeron system, is quite good. I will cvsup shortly and try this all again. I don't know how much of a difference it makes, but this box is doing NAT. The pn0 interface is on a cable modem and fxp0 is on a HUB serving my internal network of a few machines. -- Shaun Rowland rowland@cis.ohio-state.edu http://www.cis.ohio-state.edu/~rowland/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Dec 16 20:18:58 1999 Delivered-To: freebsd-smp@freebsd.org Received: from dhcp9541090.columbus.rr.com (dhcp9541090.columbus.rr.com [24.95.41.90]) by hub.freebsd.org (Postfix) with ESMTP id 1D35D14E78 for ; Thu, 16 Dec 1999 20:18:56 -0800 (PST) (envelope-from rowland@dhcp9541090.columbus.rr.com) Received: (from rowland@localhost) by dhcp9541090.columbus.rr.com (8.9.3/8.9.3) id XAA00720; Thu, 16 Dec 1999 23:15:08 -0500 (EST) (envelope-from rowland) To: Chris Timmons Cc: freebsd-smp@FreeBSD.ORG Subject: Re: ping -R kernel panic in 3.3-R SMP ? References: X-Face: "<|%>c@Vfv/8}+Av1z:R5sDzf!3QVer!n\,.&+&h\k1,BHAoyw8Gp10<-SqZ<*"|!U!a#xg6ls?1,Vj$m@r?uHcfB,'i:LLgtyb;~}O8v7zZThuB`X~#IE{v*"PhI]cl/>&ys(MGa%y:6~TuHFw&~|V?!9HZ_R"<}dC5D:%igP2Q6ZJex,P0M From: Shaun Rowland Date: 16 Dec 1999 23:15:07 -0500 In-Reply-To: Chris Timmons's message of "Thu, 16 Dec 1999 13:48:58 -0800 (PST)" Message-ID: <87ogbqryno.fsf@dhcp9541090.columbus.rr.com> Lines: 12 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Bryce Canyon" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chris Timmons writes: > Does it panic no matter which host you are pinging, or does it only happen > to certain hosts (or on some invocations to the same host but not all)? This only occurs when I ping -R a host which is not on the same physical network. If I ping -R a host that is on my local network (HUB side of NAT) I am OK, but as soon as I ping -R a host which is on the other side of the main interface I get the kernel panic immediately. -- Shaun Rowland rowland@cis.ohio-state.edu http://www.cis.ohio-state.edu/~rowland/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Dec 17 14: 0: 9 1999 Delivered-To: freebsd-smp@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id B503415008 for ; Fri, 17 Dec 1999 14:00:05 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id B5FFC1C03; Sat, 18 Dec 1999 06:00:02 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Shaun Rowland Cc: Chris Timmons , freebsd-smp@FreeBSD.ORG Subject: Re: ping -R kernel panic in 3.3-R SMP ? In-Reply-To: Message from Shaun Rowland of "16 Dec 1999 16:58:58 EST." Date: Sat, 18 Dec 1999 06:00:02 +0800 From: Peter Wemm Message-Id: <19991217220002.B5FFC1C03@overcee.netplex.com.au> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Shaun Rowland wrote: > Chris Timmons writes: > > > Does it panic no matter which host you are pinging, or does it only happen > > to certain hosts (or on some invocations to the same host but not all)? > > I tried two different hostnames. One was on my local internal network > (I do NAT through a cable modem) and the other was on a different > network. Both times it generated a panic. I will try some different > hosts and double check what I have seen so far. I did not try this > without an actual hostname. I would think that prints the usage. When > the panic occurs it happens immediately. The command does not work > intermittently. This is a divert socket problem (natd). The panic was in: Stopped at div_input + 0xca: movswl 0x22(%edx)%eax and fault virtual address = 0x35000232 fault code = supervisor read, page not present ie: %edx is wild. Folks who are not running natd will not be able to reproduce this. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Dec 18 8: 1:15 1999 Delivered-To: freebsd-smp@freebsd.org Received: from ipamzlx.physik.uni-mainz.de (ipamzlx.Physik.Uni-Mainz.DE [134.93.180.54]) by hub.freebsd.org (Postfix) with ESMTP id 1144E14D68 for ; Sat, 18 Dec 1999 08:01:12 -0800 (PST) (envelope-from ohartman@ipamzlx.physik.uni-mainz.de) Received: from ipamzlx.Physik.Uni-Mainz.DE (ipamzlx.Physik.Uni-Mainz.DE [134.93.180.54]) by ipamzlx.physik.uni-mainz.de (8.9.3/8.9.3) with ESMTP id RAA26541 for ; Sat, 18 Dec 1999 17:02:40 +0100 (CET) (envelope-from ohartman@ipamzlx.physik.uni-mainz.de) Date: Sat, 18 Dec 1999 17:02:40 +0100 (CET) From: "O. Hartmann" To: freebsd-smp@freebsd.org Subject: parallelport problems, ALi 1542 chipset Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear Sirs. I posted a question before in one of the related newsgroup for this problem but it seems that nobody wants to give an answer or nobody has an answer. I'll try it here again and hope it will have success. I have a printserver, based on FreeBSD 3.4. Hardware is: Gigabyte 5GAA main PCB, based on ALi Chipset 1542-100 (Aladdin-V AGPset Chip) CPU AMD K6-2 500MHz memory 128MBytes PC100 RAM NIC 3COM 3C905B-TX (at 100MB/full duplex) Adaptec 2940U Controller Matrox G200 graphics device noname 8 bit additional parallel port card on ISA bus, EPP capabilities. Phenomenon: this system is our printserver, operating with two laser printers. When printing via lpt0 (built in port) I recognize no performance losses of the system, but whenever someone prints out via lpt1, the additional parallel port interface, this system crashes in performance and for the time the spooler is copying data via lpt1 the server is not accessible via network. Working on console of this machine I realise nothing, but performance of diskdevice seems to be compromised. Accessing this machine via network is impossible! Whenever someone prints out, ping latency pushes up to >16, >25 ms (nomrally 0.200 - 0.500 on our LAN). I changed this additional parallelport card against an older type board (16 bit multi I/O adaptor) - and realized the same! Before I used a GigaByte board based on SiS chipset and I never realized those performance losses so it seems to be a problem of the internal driver of FreeBSD or generally a problem of the PCI-ISA bridge of ALi chips. Before posting my kernel configurations it would be nice whether you can give me hints and tips or discuss this problem. If you're sure it was related to the mainboard/chipset please report me! But ordering a new main PCB could run me into the same problems so I would like to be informed prior to avoid mistakes. Additional, I must say that I configured the additional port like this: controller ppbus0 controller ppbus1 controller ppc0 at isa? port "IO_LPT1" flags 0x08 tty irq 7 drq 1 controller ppc1 at isa? port "IO_LPT2" flags 0x04 tty irq 5 drq 3 device lpt0 at ppbus0 device lpt1 at ppbus1 Hope that is enough information to make any decissions ... Best wishes and thanks in advance, O. Hartmann Gruss O. Hartmann ------------------------------------------------------------------- ohartman@ipamzlx.physik.uni-mainz.de Klimadatenserver des IPA, Universitaet Mainz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Dec 19 18:15:29 1999 Delivered-To: freebsd-smp@freebsd.org Received: from nhimc0a.doosan.com (nhimc0a.doosan.com [203.226.167.201]) by hub.freebsd.org (Postfix) with ESMTP id 06DDF152C8 for ; Sun, 19 Dec 1999 18:15:11 -0800 (PST) (envelope-from JAMESYOO@DOOSAN.COM) Received: by nhimc0a.doosan.com with Internet Mail Service (5.0.1460.8) id ; Mon, 20 Dec 1999 11:13:22 +0900 Message-ID: <11F066DDFA3BD311B7A300805F15F3955EB9A2@suex0a.doosan.com> From: =?euc-kr?B?t/m/tcH4ILTruK4gsPy4riC/rLz2v/hCVb+svPbGwLDmv7Ww/Liu?= To: freebsd-smp@freebsd.org Subject: smp? Date: Mon, 20 Dec 1999 11:14:44 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi ! This is Jamesyoo in Korea. Can u do me a favor? I am just curious about SMP. Please let me know what SMP stands for. (Is that a board name? beta code name?.......) Expecting your help, thx. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Dec 19 18:17:47 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mail.rdc1.ab.home.com (ha2.rdc1.ab.wave.home.com [24.64.2.51]) by hub.freebsd.org (Postfix) with ESMTP id 53A59151FA for ; Sun, 19 Dec 1999 18:17:45 -0800 (PST) (envelope-from vipw@home.com) Received: from FatMan ([24.66.193.63]) by mail.rdc1.ab.home.com (InterMail v4.01.01.07 201-229-111-110) with SMTP id <19991220021744.TDDA10361.mail.rdc1.ab.home.com@FatMan>; Sun, 19 Dec 1999 18:17:44 -0800 Message-ID: <012f01bf4af5$1216f2c0$0564000a@fast.b0rk.net> From: "Adam Serediuk" To: =?iso-8859-1?B?t/m/tcH4ILTruK4gsPy4riC/rLz2v/hCVb+svPbGwLDmv7Ww/Liu?= Cc: References: <11F066DDFA3BD311B7A300805F15F3955EB9A2@suex0a.doosan.com> Subject: Re: smp? Date: Mon, 20 Dec 1999 07:18:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org symmetric multi processing ----- Original Message ----- From: 류영진 대리 관리 연수원BU연수팀경영관리 To: Sent: Sunday, December 19, 1999 7:14 PM Subject: smp? > Hi ! > > This is Jamesyoo in Korea. > > Can u do me a favor? > I am just curious about SMP. Please let me know what SMP stands for. > (Is that a board name? beta code name?.......) > > Expecting your help, thx. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Dec 19 22:15:44 1999 Delivered-To: freebsd-smp@freebsd.org Received: from picalon.gun.de (picalon.gun.de [192.109.159.1]) by hub.freebsd.org (Postfix) with ESMTP id C5609150F1 for ; Sun, 19 Dec 1999 22:15:33 -0800 (PST) (envelope-from andreas@klemm.gtn.com) Received: from klemm.gtn.com (pppak04.gtn.com [194.231.123.169]) by picalon.gun.de (8.9.3/8.9.3) with ESMTP id HAA19844 for ; Mon, 20 Dec 1999 07:15:19 +0100 (MET) Received: (from andreas@localhost) by klemm.gtn.com (8.9.3/8.9.3) id HAA01930 for smp@freebsd.org; Mon, 20 Dec 1999 07:15:15 +0100 (CET) (envelope-from andreas) Date: Mon, 20 Dec 1999 07:15:15 +0100 From: Andreas Klemm To: smp@freebsd.org Subject: staroffice doesn't work with a 3.4-SMP kernel Message-ID: <19991220071515.A1654@titan.klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i X-Operating-System: FreeBSD 3.4-STABLE SMP X-Disclaimer: A free society is one where it is safe to be unpopular Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I only get staroffice installed and working, when using a single processor kernel. Otherwise both programs hang: - the staroffice installation program which does the user setup install-user: ${PREFIX}/Office51/bin/setup - staroffice itself When using the SMP kernel, I get messages in the console window, like that: shared address space fork attempted: pid: 817 shared address space fork attempted: pid: 817 shared address space fork attempted: pid: 817 shared address space fork attempted: pid: 817 shared address space fork attempted: pid: 817 shared address space fork attempted: pid: 817 When using the single processor kernel these messages doesn't show up and everything works. I use the Linux Emulator as module, it's not compiled in into the kernel. This is my kernel config file: # # TITAN # machine "i386" cpu "I686_CPU" ident TITAN maxusers 100 options INCLUDE_CONFIG_FILE # Include this file in kernel #options USERCONFIG #boot -c editor #options VISUAL_USERCONFIG #visual boot -c editor options LKM # LKM support options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O #options "I4B_SMP_WORKAROUND" # Options for the VM subsystem #options PQ_NOOPT # No coloring #options PQ_LARGECACHE # color for 512k/16k cache options PQ_HUGECACHE # color for 1024k/16k cache # # Certain applications can grow to be larger than the 128M limit # that FreeBSD initially imposes. Below are some options to # allow that limit to grow to 256MB, and can be increased further # with changing the parameters. MAXDSIZ is the maximum that the # limit can be set to, and the DFLDSIZ is the default value for # the limit. You might want to set the default lower than the # max, and explicitly set the maximum with a shell command for processes # that regularly exceed the limit like INND. # options "MAXDSIZ=(256*1024*1024)" options "DFLDSIZ=(256*1024*1024)" options NMBCLUSTERS=4096 # # Allow user-mode programs to manipulate their local descriptor tables. # This option is required for the WINE Windows(tm) emulator, and is # not used by anything else (that we know of). # #options USER_LDT #allow user-level control of i386 ldt # # Allow processes to switch to vm86 mode, as well as enabling direct # user-mode access to the I/O port space. This option is necessary for # the doscmd emulator to run and the VESA modes in syscons to be available. # #options "VM86" #options VESA # needs VM86 defined too!! # Debugging #options DDB options KTRACE #kernel tracing # Network options MROUTING # Multicast routing options IPX #IPX/SPX communications protocols options NETATALK #Appletalk communications protocols options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #print information about # dropped packets options IPFIREWALL_FORWARD #enable xparent proxy support options "IPFIREWALL_VERBOSE_LIMIT=100" #limit verbosity options IPDIVERT #divert sockets options "ICMP_BANDLIM" options DUMMYNET options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options SOFTUPDATES #Softupdates options MFS #Memory Filesystem options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options KERNFS #Kernel filesystem options NFS #Network File System options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options UCONSOLE #Allow users to grab the console options SYSVSHM, SYSVSEM, SYSVMSG options "MD5" options NSWAPDEV=4 #options PCI_QUIET #options COMPAT_LINUX options SHOW_BUSYBUFS #options FDESC #File descriptor filesystem #options NTFS #File descriptor filesystem #options UNION #Union filesystem #options CODA #CODA filesystem. #pseudo-device vcoda 4 #coda minicache <-> venus comm. options "P1003_1B" options "_KPOSIX_PRIORITY_SCHEDULING" options "_KPOSIX_VERSION=199309L" # netgraph(4). Enable the base netgraph code with the NETGRAPH option. options NETGRAPH #netgraph(4) system options NETGRAPH_ASYNC options NETGRAPH_BPF options NETGRAPH_CISCO options NETGRAPH_ECHO #options NETGRAPH_FRAME_RELAY options NETGRAPH_HOLE options NETGRAPH_IFACE options NETGRAPH_KSOCKET options NETGRAPH_LMI options NETGRAPH_PPP options NETGRAPH_PPPOE options NETGRAPH_PPTPGRE options "NETGRAPH_RFC1490" options NETGRAPH_SOCKET options NETGRAPH_TEE options NETGRAPH_TTY options NETGRAPH_UI options NETGRAPH_VJC # Size of the kernel message buffer. Should be N * pagesize. options "MSGBUF_SIZE=40960" config kernel root on da0s2a controller isa0 controller pci0 controller pnp0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 disk fd0 at fdc0 drive 0 controller ahc0 controller scbus0 # SCSI bus (required) device da0 # Direct Access (disks) device sa0 # Sequential Access (tape etc) device cd0 # CD device pass0 # Passthrough device (direct SCSI) device pt0 at scbus? # SCSI processor type device sctarg0 at scbus? # SCSI target #controller scbus0 at ahc0 #disk da0 at scbus0 target 0 unit 0 #disk da4 at scbus0 target 1 unit 0 #tape sa0 at scbus0 target 4 #device cd0 at scbus0 target 5 #device cd1 at scbus0 target 6 #device pass0 # CAM passthrough driver # AHA 2940 #controller ahc1 #controller scbus1 at ahc1 #disk da1 at scbus1 target 1 unit 0 #disk da2 at scbus1 target 2 unit 0 #disk da3 at scbus1 target 3 unit 0 # options SCSI_DELAY=8000 #Be pessimistic about Joe SCSI device options AHC_ALLOW_MEMIO options SCSI_REPORT_GEOMETRY # Options for the CAM sequential access driver: # SA_SPACE_TIMEOUT: Timeout for space operations, in minutes # SA_REWIND_TIMEOUT: Timeout for rewind operations, in minutes # SA_ERASE_TIMEOUT: Timeout for erase operations, in minutes options "SA_SPACE_TIMEOUT=(60)" options "SA_REWIND_TIMEOUT=(2*60)" options "SA_ERASE_TIMEOUT=(4*60)" # atkbdc0 controlls both the keyboard and the PS/2 mouse controller atkbdc0 at isa? port IO_KBD tty device atkbd0 at isa? tty irq 1 device psm0 at isa? tty irq 12 device vga0 at isa? port ? conflicts # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? tty options MAXCONS=4 # number of virtual consoles options SC_HISTORY_SIZE=200 # number of history buffer lines device npx0 at isa? port IO_NPX irq 13 device sio0 at isa? port "IO_COM1" flags 0x10 tty irq 4 device sio1 at isa? port "IO_COM2" tty irq 3 # device lpt0 at isa? port? tty irq 7 # Parallel port and friends. This replaces lpt0 (see lint or man pages) device ppc0 at isa? port? flags 0x40 tty irq 7 controller ppbus0 device lpt0 at ppbus? device xl0 device ed0 at isa? port 0x280 net irq 10 iomem 0xd8000 # Luigis new sound driver #device pcm0 at isa? port ? tty irq 5 drq 1 flags 0x0 pseudo-device loop pseudo-device ether pseudo-device pty 256 pseudo-device gzip #Exec gzipped a.out's pseudo-device vn #Vnode driver (turns a file into a device) pseudo-device snp 3 #Snoop device - to look at pty/vty/etc.. pseudo-device bpfilter 4 #Berkeley packet filter #pseudo-device sppp #Generic Synchronous PPP pseudo-device tun 1 #pseudo-device ppp 1 pseudo-device ccd 4 #Concatenated disk driver options PPP_BSDCOMP #PPP BSD-compress support options PPP_DEFLATE #PPP zlib/deflate/gzip support options PPP_FILTER #enable bpf filtering (needs bpfilter) -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD Get new songs from our band: http://www.freebsd.org/~andreas/64bits/index.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Dec 19 23: 4:22 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mail.zuhause.org (c2-178.xtlab.com [205.215.217.178]) by hub.freebsd.org (Postfix) with ESMTP id DDC3014F6C for ; Sun, 19 Dec 1999 23:04:20 -0800 (PST) (envelope-from bruce@zuhause.mn.org) Received: by mail.zuhause.org (Postfix, from userid 1001) id F0AE17C31; Mon, 20 Dec 1999 01:04:18 -0600 (CST) From: Bruce Albrecht MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14429.54514.741408.247090@celery.zuhause.org> Date: Mon, 20 Dec 1999 01:04:18 -0600 (CST) To: Andreas Klemm Cc: smp@freebsd.org Subject: Re: staroffice doesn't work with a 3.4-SMP kernel In-Reply-To: <19991220071515.A1654@titan.klemm.gtn.com> References: <19991220071515.A1654@titan.klemm.gtn.com> X-Mailer: VM 6.72 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you want to use StarOffice (or wine) on an SMP system, you'll need to upgrade to -current. There was some fix to the memory system around the time 3.1 came out that disabled forking with shared memory on an SMP system. This was eventually fixed in -current, but never retrofitted to -stable. Andreas Klemm writes: > I only get staroffice installed and working, when using a single > processor kernel. Otherwise both programs hang: > - the staroffice installation program which does the > user setup > install-user: > ${PREFIX}/Office51/bin/setup > - staroffice itself > > When using the SMP kernel, I get messages in the console window, > like that: > shared address space fork attempted: pid: 817 > shared address space fork attempted: pid: 817 > shared address space fork attempted: pid: 817 > shared address space fork attempted: pid: 817 > shared address space fork attempted: pid: 817 > shared address space fork attempted: pid: 817 > > When using the single processor kernel these messages doesn't show > up and everything works. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 20 9:25:45 1999 Delivered-To: freebsd-smp@freebsd.org Received: from picalon.gun.de (picalon.gun.de [192.109.159.1]) by hub.freebsd.org (Postfix) with ESMTP id 569D515371 for ; Mon, 20 Dec 1999 09:25:41 -0800 (PST) (envelope-from andreas@klemm.gtn.com) Received: from klemm.gtn.com (pppak04.gtn.com [194.231.123.169]) by picalon.gun.de (8.9.3/8.9.3) with ESMTP id SAA10678; Mon, 20 Dec 1999 18:25:24 +0100 (MET) Received: (from andreas@localhost) by klemm.gtn.com (8.9.3/8.9.3) id SAA19599; Mon, 20 Dec 1999 18:24:01 +0100 (CET) (envelope-from andreas) Date: Mon, 20 Dec 1999 18:24:01 +0100 From: Andreas Klemm To: Bruce Albrecht Cc: Andreas Klemm , smp@freebsd.org Subject: Re: staroffice doesn't work with a 3.4-SMP kernel Message-ID: <19991220182400.A19277@titan.klemm.gtn.com> References: <19991220071515.A1654@titan.klemm.gtn.com> <14429.54514.741408.247090@celery.zuhause.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <14429.54514.741408.247090@celery.zuhause.org>; from bruce@zuhause.mn.org on Mon, Dec 20, 1999 at 01:04:18AM -0600 X-Operating-System: FreeBSD 3.4-STABLE SMP X-Disclaimer: A free society is one where it is safe to be unpopular Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Dec 20, 1999 at 01:04:18AM -0600, Bruce Albrecht wrote: > If you want to use StarOffice (or wine) on an SMP system, you'll need > to upgrade to -current. There was some fix to the memory system > around the time 3.1 came out that disabled forking with shared memory > on an SMP system. This was eventually fixed in -current, but never > retrofitted to -stable. Ah, thanks ! Could perhaps somebody think about, if it would be possible to integrate this patch into -stable ? Or are differences in vm subsystem already so big, that a simple merge of it isn't possible ? Andreas /// -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD Get new songs from our band: http://www.freebsd.org/~andreas/64bits/index.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 20 10:27:14 1999 Delivered-To: freebsd-smp@freebsd.org Received: from fhut.fingerhut.com (fhut.fingerhut.com [204.221.45.3]) by hub.freebsd.org (Postfix) with ESMTP id 0B11815364 for ; Mon, 20 Dec 1999 10:27:02 -0800 (PST) (envelope-from Bruce.Albrecht@fingerhut.com) Received: from dtcbrg1.fingerhut.com (dtcbrg1.dtcbrg.fhut [151.210.147.35]) by fhut.fingerhut.com (8.9.1/8.9.1) with ESMTP id MAA05195; Mon, 20 Dec 1999 12:26:44 -0600 (CST) Received: from seag.fingerhut.com (GF007E0.SEAG.fingerhut.com [151.210.140.7]) by dtcbrg1.fingerhut.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id ZDCQ9Y64; Mon, 20 Dec 1999 12:26:47 -0600 Received: from gf003e0.fingerhut.com. by seag.fingerhut.com (8.8.8+Sun/SMI-SVR4) id MAA16234; Mon, 20 Dec 1999 12:26:40 -0600 (CST) Received: (from w246@localhost) by gf003e0.fingerhut.com. (8.8.8+Sun/8.8.8) id MAA12063; Mon, 20 Dec 1999 12:26:35 -0600 (CST) X-Sybari-Space: 00000000 00000000 00000000 From: Bruce Albrecht MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14430.29915.446373.106339@fingerhut.com> Date: Mon, 20 Dec 1999 12:26:35 -0600 (CST) To: Andreas Klemm Cc: smp@freebsd.org Subject: Re: staroffice doesn't work with a 3.4-SMP kernel In-Reply-To: <19991220182400.A19277@titan.klemm.gtn.com> References: <19991220071515.A1654@titan.klemm.gtn.com> <14429.54514.741408.247090@celery.zuhause.org> <19991220182400.A19277@titan.klemm.gtn.com> X-Mailer: VM 6.71 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andreas Klemm writes: > On Mon, Dec 20, 1999 at 01:04:18AM -0600, Bruce Albrecht wrote: > > If you want to use StarOffice (or wine) on an SMP system, you'll need > > to upgrade to -current. There was some fix to the memory system > > around the time 3.1 came out that disabled forking with shared memory > > on an SMP system. This was eventually fixed in -current, but never > > retrofitted to -stable. > > Ah, thanks ! Could perhaps somebody think about, if it would > be possible to integrate this patch into -stable ? > Or are differences in vm subsystem already so big, that a simple > merge of it isn't possible ? I brought this up about 6 months ago, and the answer then was that there were no plans by anyone who could implement it to do so. Now that -current is in a feature freeze (or is about to enter it), and 4.0 will probably be released about two months from now, it's even more unlikely that anyone will step up and do it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Dec 20 22:50:40 1999 Delivered-To: freebsd-smp@freebsd.org Received: from shell7.ba.best.com (shell7.ba.best.com [206.184.139.138]) by hub.freebsd.org (Postfix) with ESMTP id 1ECF81540B for ; Mon, 20 Dec 1999 22:50:35 -0800 (PST) (envelope-from spadger@shell7.ba.best.com) Received: (from spadger@localhost) by shell7.ba.best.com (8.9.3/8.9.2/best.sh) id WAA00362 for freebsd-smp@freebsd.org; Mon, 20 Dec 1999 22:50:30 -0800 (PST) From: Andrew Sparrow Message-Id: <199912210650.WAA00362@shell7.ba.best.com> Subject: Socket 8 -> PPGA convertor? To: freebsd-smp@freebsd.org Date: Mon, 20 Dec 1999 22:50:30 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Has anyone looked at the PowerLeap PL-Pro/II socket 8 -> PPGA convertor (http://www.powerleap.com)? It apparently supports up to dual 533Mhz Celerons on a 66Mhz bus, and is currently in Beta. It is supposed to work[1] with Linux... They're thinking of supporting quad-way Xeons (for ALR-style hardware) in the future - interesting, and considerably cheaper than those PII Overdrives that no-one's even advertising anymore... :=) Cheers, AS [1] For some definition of "work" - it's not too clear. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Dec 24 12:44:21 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mass.cdrom.com (castles551.castles.com [208.214.165.115]) by hub.freebsd.org (Postfix) with ESMTP id 12B0814D42 for ; Fri, 24 Dec 1999 12:44:17 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA11237; Fri, 24 Dec 1999 12:47:51 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912242047.MAA11237@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: NOKUBI Hirotaka Cc: freebsd-smp@freebsd.org Subject: Re: IRQ and APIC pin mapping question In-reply-to: Your message of "Sun, 12 Dec 1999 20:11:45 +0900." <19991212111015.2B2CF150CD@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Dec 1999 12:47:50 -0800 From: Mike Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I've been trying SMP kernel on NEC PC9821RvII which is not PC-AT > compatible, FreeBSD PC98 port works fine on it with UP kernel. > > I made it possible to access MPCT at the top of the physical memory, Neat. Looking at the MPCT parsing code as it stands, it should probably be integrated with our other BIOS signature search code. How do you find the MPCP at the top of memory? > SMP kernel works fine on it. But there is a problem around interrupt. > Would you advice me about that? > > Almost all MPCT I've seen has same source IRQ# and destination > APIC PIN#, like IRQ4 is connected to APIC PIN4. But PC9821RvII's > MPCT shows some IRQ# is connected to different APIC PIN#, like > IRQ8 is connected to APIC PIN7 (please see mptable output). > > My question is the meaning of int_to_apicintpin[]. > > Interrupt is managed with IRQ#, so it needs to know that which IRQ# > corresponds to which APIC PIN#. Although I think that is the reason > int_to_apicintpin[] is provided, initialization of it confused me. > > Function setup_apic_irq_mapping() initialize int_to_apicintpin[] using > assign_apic_irq() with same value as argument `intpin' and `irq' > (please see patch). It works fine on the machine which has same > IRQ# and APIC PIN#. But on my PC9821RvII, it is impossible for kernel > to get correct APIC PIN# corresponds to IRQ# to handle. For example, > kernel wants to disable IRQ10, APIC PIN9 should be disabled, > but without patch, kernel disables APIC PIN10. That's all basically correct, yes. > How can I fix this problem without affecting PC-AT compatible? I can't claim to be any sort of expert regarding this code, but since nobody else seems to be responding to your query, and since I've been looking at it a bit over the last few days... What appears to be needed is the ability to search for an intpin given some or all of a source bus, interrupt type and bus IRQ number. > Index: i386/i386/mp_machdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v > retrieving revision 1.111 > diff -u -u -r1.111 mp_machdep.c > --- mp_machdep.c 1999/10/15 21:38:15 1.111 > +++ mp_machdep.c 1999/12/12 10:59:25 > @@ -966,7 +966,7 @@ > int x; > > if (int_to_apicintpin[irq].ioapic != -1) > - panic("assign_apic_irq: inconsistent table"); > + return; > > int_to_apicintpin[irq].ioapic = apic; > int_to_apicintpin[irq].int_pin = intpin; This isn't good because it causes us to lose all of the other mappings between the supplied IRQ and interrupt pins. We probably need to chain these structures. (That's how the Linux folks do it, if I understand their code correctly). > @@ -1070,7 +1070,7 @@ > io_apic_ints[x].int_type == 3)) { > assign_apic_irq(0, > io_apic_ints[x].dst_apic_int, > - io_apic_ints[x].dst_apic_int); > + io_apic_ints[x].src_bus_irq); > } > } > int_vector = 0; This seems right on the surface, but falls down because of the assumption that the 'irq' argument to assign_apic_irq must always be unique. I'm not entirely sure what the right approach to take here is. Suggestions, anyone? -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Dec 25 7:35:27 1999 Delivered-To: freebsd-smp@freebsd.org Received: from yyy.or.jp (mail.yyy.or.jp [202.214.252.21]) by hub.freebsd.org (Postfix) with SMTP id 9109915206 for ; Sat, 25 Dec 1999 07:35:17 -0800 (PST) (envelope-from hnokubi@yyy.or.jp) Received: (qmail 20188 invoked from network); 26 Dec 1999 00:35:12 +0900 Received: from urayasu110.interwave.or.jp (HELO ppp-client.yyy.or.jp) (210.138.157.146) by mail.yyy.or.jp with SMTP; 26 Dec 1999 00:35:12 +0900 Received: from sassaby.nokubi.or.jp (sassaby [192.168.9.3]) by ppp-client.yyy.or.jp (8.9.1/3.5Wpl7-ppp) with ESMTP id AAA38441; Sun, 26 Dec 1999 00:36:21 +0900 (JST) Received: from sassaby.nokubi.or.jp (localhost.nokubi.or.jp [127.0.0.1]) by sassaby.nokubi.or.jp (8.9.3/3.5Wpl7-glove) with ESMTP id AAA00660; Sun, 26 Dec 1999 00:35:43 +0900 (JST) To: Mike Smith Cc: freebsd-smp@freebsd.org Subject: Re: IRQ and APIC pin mapping question In-reply-to: Your message of "Fri, 24 Dec 99 12:47:50 PST." <199912242047.MAA11237@mass.cdrom.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 26 Dec 1999 00:35:43 +0900 From: NOKUBI Hirotaka Message-Id: <19991225153517.9109915206@hub.freebsd.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks for your response. In message <199912242047.MAA11237@mass.cdrom.com>, Mike Smith writes: >> I've been trying SMP kernel on NEC PC9821RvII which is not PC-AT >> compatible, FreeBSD PC98 port works fine on it with UP kernel. >> >> I made it possible to access MPCT at the top of the physical memory, > >Neat. Looking at the MPCT parsing code as it stands, it should probably >be integrated with our other BIOS signature search code. How do you find >the MPCP at the top of memory? Probably, my poor English would mislead you, sorry. I beleive you are talking about MP Floating Pointer Structure. Current FreeBSD code can find it on NEC PC98. No new BIOS signature search code is needed. I mean that MP Configuration Table is placed at the top of the physical memory on NEC PC98, that's the problem. Current FreeBSD code can't handle it, because these areas are not mapped, and used for message buffer before mptable_pass2() is called. Although latter problem will be solved in PC98 part, it needs to modify common part code for solving former one. I'll attach a patch for it. Please review. After appling patch, mp_probe() is called after pmap_bootstrap() so that making it possible that mp_probe() to use pmap_enter() for reading MPCT at the top of physical memory. >> How can I fix this problem without affecting PC-AT compatible? > >I can't claim to be any sort of expert regarding this code, but since >nobody else seems to be responding to your query, and since I've been >looking at it a bit over the last few days... Thank you for your time, and sorry, I've had to tell that Tor Egge replied to me personally two weeks ago, and he made patch. It solves problems, and I'm just waiting it to be committed. ---- NOKUBI Hirotaka Fingerprint20 = DEBC 0793 7CD6 92F1 0A1F A792 9E2F EEEE A41B 171D Index: i386/i386/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v retrieving revision 1.379 diff -u -u -r1.379 machdep.c --- machdep.c 1999/11/24 01:02:58 1.379 +++ machdep.c 1999/12/25 15:10:12 @@ -1567,9 +1567,6 @@ #ifdef SMP /* make hole for AP bootstrap code */ physmap[1] = mp_bootaddress(physmap[1] / 1024); - - /* look for the MP hardware - needed for apic addresses */ - mp_probe(); #endif /* @@ -1631,6 +1628,10 @@ /* call pmap initialization to make new kernel address space */ pmap_bootstrap(first, 0); +#ifdef SMP + /* look for the MP hardware - needed for apic addresses */ + mp_probe(); +#endif /* * Size up each available chunk of physical memory. */ Index: i386/i386/mp_machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v retrieving revision 1.111 diff -u -u -r1.111 mp_machdep.c --- mp_machdep.c 1999/10/15 21:38:15 1.111 +++ mp_machdep.c 1999/12/25 15:10:12 @@ -391,7 +391,7 @@ found: /* calculate needed resources */ - mpfps = (mpfps_t)x; + mpfps = (mpfps_t)(x + KERNBASE); if (mptable_pass1()) panic("you must reconfigure your kernel"); @@ -690,12 +690,12 @@ {UNKNOWN_BUSTYPE, "---"}, {UNKNOWN_BUSTYPE, "---"}, {ISA, "ISA"}, + {ISA, "NEC98"}, {UNKNOWN_BUSTYPE, "---"}, {UNKNOWN_BUSTYPE, "---"}, {UNKNOWN_BUSTYPE, "---"}, {UNKNOWN_BUSTYPE, "---"}, {UNKNOWN_BUSTYPE, "---"}, - {UNKNOWN_BUSTYPE, "---"}, {PCI, "PCI"}, {UNKNOWN_BUSTYPE, "---"}, {UNKNOWN_BUSTYPE, "---"}, @@ -757,6 +757,10 @@ int count; int type; int mustpanic; +#ifdef SMP + int i, j; + struct globaldata *gd; +#endif POSTCODE(MPTABLE_PASS1_POST); @@ -791,6 +795,14 @@ if ((cth = mpfps->pap) == 0) panic("MP Configuration Table Header MISSING!"); + if (cth >= (mpcth_t)0x100000) { + pmap_enter(kernel_pmap, (vm_offset_t)CADDR1, + trunc_page((vm_offset_t)cth), VM_PROT_READ, TRUE); + /* XXX do not support MPCT across page boundary */ + cth = (mpcth_t)(CADDR1 + ((int)cth & PAGE_MASK)); + } else { + cth = (mpcth_t)((u_int)cth + KERNBASE); + } cpu_apic_address = (vm_offset_t) cth->apic_address; /* walk the table, recording info of interest */ @@ -857,6 +869,46 @@ --mp_naps; /* subtract the BSP */ + if (cpu_apic_address == 0) + panic("pmap_bootstrap: no local apic!"); + + /* local apic is mapped on last page */ + SMPpt[NPTEPG - 1] = (pt_entry_t)(PG_V | PG_RW | PG_N | /*pgeflag |*/ + (cpu_apic_address & PG_FRAME)); + + for (i = 0; i < mp_napics; i++) { + for (j = 0; j < mp_napics; j++) { + /* same page frame as a previous IO apic? */ + if (((vm_offset_t)SMPpt[NPTEPG-2-j] & PG_FRAME) == + (io_apic_address[0] & PG_FRAME)) { + ioapic[i] = (ioapic_t *)((u_int)SMP_prvspace + + (NPTEPG-2-j)*PAGE_SIZE); + break; + } + /* use this slot if available */ + if (((vm_offset_t)SMPpt[NPTEPG-2-j] & PG_FRAME) == 0) { + SMPpt[NPTEPG-2-j] = (pt_entry_t)(PG_V | PG_RW | + /*pgeflag|*/ (io_apic_address[i] & PG_FRAME)); + ioapic[i] = (ioapic_t *)((u_int)SMP_prvspace + + (NPTEPG-2-j)*PAGE_SIZE); + break; + } + } + } + + /* BSP does this itself, AP's get it pre-set */ + gd = &SMP_prvspace[0].globaldata; + gd->gd_prv_CMAP1 = &SMPpt[1]; + gd->gd_prv_CMAP2 = &SMPpt[2]; + gd->gd_prv_CMAP3 = &SMPpt[3]; + gd->gd_prv_PMAP1 = &SMPpt[4]; + gd->gd_prv_CADDR1 = SMP_prvspace[0].CPAGE1; + gd->gd_prv_CADDR2 = SMP_prvspace[0].CPAGE2; + gd->gd_prv_CADDR3 = SMP_prvspace[0].CPAGE3; + gd->gd_prv_PADDR1 = (unsigned *)SMP_prvspace[0].PPAGE1; + + invltlb(); + return mustpanic; } @@ -914,6 +966,15 @@ if ((cth = mpfps->pap) == 0) panic("MP Configuration Table Header MISSING!"); + + if (cth >= (mpcth_t)0x100000) { + pmap_enter(kernel_pmap, (vm_offset_t)CADDR1, + trunc_page((vm_offset_t)cth), VM_PROT_READ, TRUE); + /* XXX do not support MPCT across page boundary */ + cth = (mpcth_t)(CADDR1 + ((int)cth & PAGE_MASK)); + } else { + cth = (mpcth_t)((u_int)cth + KERNBASE); + } /* walk the table, recording info of interest */ totalSize = cth->base_table_length - sizeof(struct MPCTH); Index: i386/i386/pmap.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/pmap.c,v retrieving revision 1.250 diff -u -u -r1.250 pmap.c --- pmap.c 1999/11/19 21:34:26 1.250 +++ pmap.c 1999/12/25 15:10:12 @@ -283,10 +283,6 @@ { vm_offset_t va; pt_entry_t *pte; -#ifdef SMP - int i, j; - struct globaldata *gd; -#endif avail_start = firstaddr; @@ -412,46 +408,6 @@ invltlb(); #endif } -#endif - -#ifdef SMP - if (cpu_apic_address == 0) - panic("pmap_bootstrap: no local apic!"); - - /* local apic is mapped on last page */ - SMPpt[NPTEPG - 1] = (pt_entry_t)(PG_V | PG_RW | PG_N | pgeflag | - (cpu_apic_address & PG_FRAME)); - - for (i = 0; i < mp_napics; i++) { - for (j = 0; j < mp_napics; j++) { - /* same page frame as a previous IO apic? */ - if (((vm_offset_t)SMPpt[NPTEPG-2-j] & PG_FRAME) == - (io_apic_address[0] & PG_FRAME)) { - ioapic[i] = (ioapic_t *)((u_int)SMP_prvspace - + (NPTEPG-2-j)*PAGE_SIZE); - break; - } - /* use this slot if available */ - if (((vm_offset_t)SMPpt[NPTEPG-2-j] & PG_FRAME) == 0) { - SMPpt[NPTEPG-2-j] = (pt_entry_t)(PG_V | PG_RW | - pgeflag | (io_apic_address[i] & PG_FRAME)); - ioapic[i] = (ioapic_t *)((u_int)SMP_prvspace - + (NPTEPG-2-j)*PAGE_SIZE); - break; - } - } - } - - /* BSP does this itself, AP's get it pre-set */ - gd = &SMP_prvspace[0].globaldata; - gd->gd_prv_CMAP1 = &SMPpt[1]; - gd->gd_prv_CMAP2 = &SMPpt[2]; - gd->gd_prv_CMAP3 = &SMPpt[3]; - gd->gd_prv_PMAP1 = &SMPpt[4]; - gd->gd_prv_CADDR1 = SMP_prvspace[0].CPAGE1; - gd->gd_prv_CADDR2 = SMP_prvspace[0].CPAGE2; - gd->gd_prv_CADDR3 = SMP_prvspace[0].CPAGE3; - gd->gd_prv_PADDR1 = (unsigned *)SMP_prvspace[0].PPAGE1; #endif invltlb(); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message