From owner-freebsd-smp Sun Oct 24 2:12:41 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 F145B14EEA; Sun, 24 Oct 1999 02:12:23 -0700 (PDT) (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 2CFA6FC; Sun, 24 Oct 1999 04:11:56 -0500 (CDT) Message-ID: <3812CD5C.1E990C73@ameslab.gov> Date: Sun, 24 Oct 1999 04:11:56 -0500 From: Chris Csanady X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en, ru, ja, ko MIME-Version: 1.0 To: freebsd-smp@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: IO APIC misdirecting irq (Re: SMP/interrupt problems..) References: <381159FF.D38E76FD@ameslab.gov> <38115BD9.6B8BE3BA@ameslab.gov> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sorry for the post to both lists--the original message probably belonged on freebsd-smp. Anyways, please follow up there only. I have tracked down the problem with the Megaraid controller in SMP, and it seems it is due to an irq being misrouted. While the controller thinks it is on irq 11, all the interrupts are actually going to apic irq 17. I have confirmed this by hardwiring amr0's interrupt to be irq 17--in which case it works perfectly. :) It is not clear to me whether the irq should or should not be routed to irq 17 though--only that it is what is happening with the current configuration. Does anyone know in particular how this should work? (Or better yet, have a fix? ;) It is kind of weird, because the amr0 controller is actually the same device as the pci-pci bridge, just a different function. So, I assume it is just on the host bus. In any case, even though the irq/int pin match in the mptable, the device (slot) does not. :\ I have included my dmesg, pciconf output, and mptable output. The device in question is the vendor=0x8086, dev=0x1960. Anyone have any ideas? Chris 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 [scsi device probing deleted..] chip0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x12378086 rev=0x02 hdr=0x00 fxp0@pci0:6:0: class=0x020000 card=0x00000000 chip=0x12298086 rev=0x02 hdr=0x00 isab0@pci0:7:0: class=0x060100 card=0x00000000 chip=0x70008086 rev=0x01 hdr=0x00 ata-pci0@pci0:7:1: class=0x010180 card=0x00000000 chip=0x70108086 rev=0x00 hdr=0x00 chip1@pci0:7:2: class=0x0c0300 card=0x00000000 chip=0x70208086 rev=0x01 hdr=0x00 ahc0@pci0:9:0: class=0x010000 card=0x00000000 chip=0x80789004 rev=0x00 hdr=0x00 ncr0@pci0:11:0: class=0x010000 card=0x87601092 chip=0x000f1000 rev=0x14 hdr=0x00 ncr1@pci0:11:1: class=0x010000 card=0x87601092 chip=0x000f1000 rev=0x14 hdr=0x00 pcib1@pci0:15:0: class=0x060400 card=0x00000000 chip=0x09608086 rev=0x03 hdr=0x01 amr0@pci0:15:1: class=0x010000 card=0x0466101e chip=0x19608086 rev=0x03 hdr=0x00 bktr0@pci0:17:0: class=0x040000 card=0x00000000 chip=0x0350109e rev=0x12 hdr=0x00 vga-pci0@pci0:19:0: class=0x030000 card=0x00000000 chip=0x0519102b rev=0x01 hdr=0x00 =============================================================================== 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 =============================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sun Oct 24 23:55:45 1999 Delivered-To: freebsd-smp@freebsd.org Received: from dingo.cdrom.com (castles546.castles.com [208.214.165.110]) by hub.freebsd.org (Postfix) with ESMTP id AF3D314C86 for ; Sun, 24 Oct 1999 23:55:43 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id XAA16687; Sun, 24 Oct 1999 23:46:55 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199910250646.XAA16687@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: twinkle.star@263.net Cc: freebsd-smp@freebsd.org Subject: Re: inquire(second time) In-reply-to: Your message of "Sat, 23 Oct 1999 18:52:08 +0800." <001101bf1d44$ad4316e0$c226a8c0@jut.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Oct 1999 23:46:55 -0700 From: Mike Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bill, like I told you last time, you need to send _FLAT_ASCII_ = messages. You're not getting answered because very few people can read = the crap you're generating. > Dear Sir: > I would like to know how does the IRQs be handled in > a SMP system.Will they be handled by all the processors equally or by a= > single processor?If it is the former,who > will handle them finally and what kind of lock mechanism > will they follow: > I expect for your answer and thank you very much for your kindness > and attention. The distribution of interrupts depends on the architecture of the SMP = system. Your question is almost hopelessly vague, which in addition to = your poor choice of mailing software makes answering it almost = impossible. If you are looking for specific answers, you will need to ask specific = questions. Which SMP system are you asking about? (what hardware, = what OS, etc.) What do you mean by "who will handle them"? What do = you mean by "what kind of lock mechanism will they follow"? -- = \\ 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 Oct 25 2:28:30 1999 Delivered-To: freebsd-smp@freebsd.org Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by hub.freebsd.org (Postfix) with ESMTP id CD442150A1 for ; Mon, 25 Oct 1999 02:28:27 -0700 (PDT) (envelope-from niklass@ifi.uio.no) Received: from gram.ifi.uio.no (3831@gram.ifi.uio.no [129.240.64.40]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id LAA02335 for ; Mon, 25 Oct 1999 11:28:24 +0200 (MET DST) Received: from localhost (niklass@localhost) by gram.ifi.uio.no ; Mon, 25 Oct 1999 11:28:23 +0200 (MET DST) Date: Mon, 25 Oct 1999 11:28:23 +0200 (MET DST) From: Niklas Johannes Saers To: freebsd-smp@freebsd.org Subject: subscribe 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 subscribe -- # Beren # Da du ikke var her, hvor var jeg? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Oct 25 2:45: 3 1999 Delivered-To: freebsd-smp@freebsd.org Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by hub.freebsd.org (Postfix) with ESMTP id 108BF15111 for ; Mon, 25 Oct 1999 02:45:00 -0700 (PDT) (envelope-from niklass@ifi.uio.no) Received: from gram.ifi.uio.no (3831@gram.ifi.uio.no [129.240.64.40]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id LAA06487 for ; Mon, 25 Oct 1999 11:44:57 +0200 (MET DST) Received: from localhost (niklass@localhost) by gram.ifi.uio.no ; Mon, 25 Oct 1999 11:44:55 +0200 (MET DST) Date: Mon, 25 Oct 1999 11:44:54 +0200 (MET DST) From: Niklas Johannes Saers To: freebsd-smp@freebsd.org Subject: 0%'s 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 Hi. I hope this is the right forum for this question: I've got a dual PII system on which I run FreeBSD. I've compiled my kernel for two processors by including options SMP and options APIC_IO in my kernel-config. At boot I get to know that both CPU's are launched and at shutdown the one tells the other to quit working. So far so good. My only question is when it comes to top. Right now it sais: last pid: 456; load averages: 0.90, 0.35, 0.14 up 0+00:26:43 11:42:59 59 processes: 2 running, 57 sleeping CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle Mem: 48M Active, 17M Inact, 22M Wired, 8334K Buf, 163M Free Swap: 512M Total, 512M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 454 root 81 20 14796K 14544K CPU1 1 1:41 0.00% 0.00% setiathome 271 root 2 0 33304K 31960K select 0 1:34 0.00% 0.00% XF86_SVGA 308 niklas 2 0 6820K 4952K select 0 0:54 0.00% 0.00% enlightenmen 346 root 2 0 3000K 2512K select 1 0:02 0.00% 0.00% Eterm etc. My questions are to the 0%'s at WCPU, CPU, user, nice, system, interrupt and idle. This has been like this each and every time I've compiled an SMP system. Could someone please point out to me where I'm going wrong so that I can watch a bit more what my system is doing? Thanks in advance Niklas -- # Beren # Da du ikke var her, hvor var jeg? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Oct 25 2:49:30 1999 Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 23E7C15111 for ; Mon, 25 Oct 1999 02:49:28 -0700 (PDT) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id DAA23878; Mon, 25 Oct 1999 03:11:31 -0700 (PDT) Date: Mon, 25 Oct 1999 03:11:31 -0700 (PDT) From: Alfred Perlstein To: Niklas Johannes Saers Cc: freebsd-smp@FreeBSD.ORG Subject: Re: 0%'s 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 On Mon, 25 Oct 1999, Niklas Johannes Saers wrote: > Hi. I hope this is the right forum for this question: I've got a dual PII > system on which I run FreeBSD. I've compiled my kernel for two processors > by including options SMP and options APIC_IO in my kernel-config. At boot > I get to know that both CPU's are launched and at shutdown the one tells > the other to quit working. So far so good. My only question is when it > comes to top. Right now it sais: > > last pid: 456; load averages: 0.90, 0.35, 0.14 up 0+00:26:43 11:42:59 > 59 processes: 2 running, 57 sleeping > CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle > Mem: 48M Active, 17M Inact, 22M Wired, 8334K Buf, 163M Free > Swap: 512M Total, 512M Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND > 454 root 81 20 14796K 14544K CPU1 1 1:41 0.00% 0.00% setiathome > 271 root 2 0 33304K 31960K select 0 1:34 0.00% 0.00% XF86_SVGA > 308 niklas 2 0 6820K 4952K select 0 0:54 0.00% 0.00% enlightenmen > 346 root 2 0 3000K 2512K select 1 0:02 0.00% 0.00% Eterm I've experianced this with Asus P2D motherboards, if you have a P2D either upgrading your BIOS image or downgrading it may help. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Oct 25 2:50:58 1999 Delivered-To: freebsd-smp@freebsd.org Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by hub.freebsd.org (Postfix) with ESMTP id DBD2A15111 for ; Mon, 25 Oct 1999 02:50:56 -0700 (PDT) (envelope-from niklass@ifi.uio.no) Received: from gram.ifi.uio.no (3831@gram.ifi.uio.no [129.240.64.40]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id LAA07510; Mon, 25 Oct 1999 11:50:55 +0200 (MET DST) Received: from localhost (niklass@localhost) by gram.ifi.uio.no ; Mon, 25 Oct 1999 11:50:55 +0200 (MET DST) Date: Mon, 25 Oct 1999 11:50:54 +0200 (MET DST) From: Niklas Johannes Saers To: Alfred Perlstein Cc: freebsd-smp@FreeBSD.ORG Subject: Re: 0%'s 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 > I've experianced this with Asus P2D motherboards, if you have a P2D either > upgrading your BIOS image or downgrading it may help. I have an Asus P2B-DS board. Could you recommend me any particular BIOS-version? Sincerely yours Niklas -- # Beren # Da du ikke var her, hvor var jeg? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Oct 25 4:19:33 1999 Delivered-To: freebsd-smp@freebsd.org Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by hub.freebsd.org (Postfix) with ESMTP id CD12415146 for ; Mon, 25 Oct 1999 04:19:29 -0700 (PDT) (envelope-from niklass@ifi.uio.no) Received: from gram.ifi.uio.no (3831@gram.ifi.uio.no [129.240.64.40]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id NAA29022; Mon, 25 Oct 1999 13:19:28 +0200 (MET DST) Received: from localhost (niklass@localhost) by gram.ifi.uio.no ; Mon, 25 Oct 1999 13:19:28 +0200 (MET DST) Date: Mon, 25 Oct 1999 13:19:27 +0200 (MET DST) From: Niklas Johannes Saers To: Alfred Perlstein Cc: freebsd-smp@FreeBSD.ORG Subject: Re: 0%'s 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 On Mon, 25 Oct 1999, Alfred Perlstein wrote: > I've experianced this with Asus P2D motherboards, if you have a P2D either > upgrading your BIOS image or downgrading it may help. Thanks a lot. Version 1010 solved this problem. :) Niklas -- # Beren # Da du ikke var her, hvor var jeg? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Oct 25 4:21:10 1999 Delivered-To: freebsd-smp@freebsd.org Received: from megadodo.segNET.COM (megadodo.segNET.COM [206.34.181.3]) by hub.freebsd.org (Postfix) with ESMTP id CCC6114A10 for ; Mon, 25 Oct 1999 04:21:00 -0700 (PDT) (envelope-from adams@digitalspark.net) Received: from nightfall.digitalspark.net (arc0a75.bf.sover.net [209.198.85.75]) by megadodo.segNET.COM (8.9.1a/8.8.5) with ESMTP id HAA18916; Mon, 25 Oct 1999 07:20:54 -0400 (EDT) Date: Mon, 25 Oct 1999 07:25:28 +0000 (GMT) From: Adam Strohl To: Niklas Johannes Saers Cc: Alfred Perlstein , freebsd-smp@FreeBSD.ORG Subject: Re: 0%'s 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 Upgrading to 1010 will fix it. - ----( Adam Strohl )------------------------------------------------ - - UNIX Operations/Systems http://www.digitalspark.net - - adams (at) digitalspark.net xxx.xxx.xxxx xxxxx - - ----------------------------------------( DigitalSpark.NET )------- - On Mon, 25 Oct 1999, Niklas Johannes Saers wrote: > > I've experianced this with Asus P2D motherboards, if you have a P2D either > > upgrading your BIOS image or downgrading it may help. > > I have an Asus P2B-DS board. Could you recommend me any particular > BIOS-version? > > Sincerely yours > > Niklas > > -- > # Beren # Da du ikke var her, hvor var jeg? > > > > 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 Mon Oct 25 16:55:18 1999 Delivered-To: freebsd-smp@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id B345815381 for ; Mon, 25 Oct 1999 16:55:13 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA13959; Mon, 25 Oct 1999 16:55:11 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd013938; Mon Oct 25 16:55:07 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id QAA16485; Mon, 25 Oct 1999 16:55:06 -0700 (MST) From: Terry Lambert Message-Id: <199910252355.QAA16485@usr06.primenet.com> Subject: Re: inquire(second time) To: twinkle.star@263.net Date: Mon, 25 Oct 1999 23:55:06 +0000 (GMT) Cc: freebsd-smp@FreeBSD.ORG In-Reply-To: <001101bf1d44$ad4316e0$c226a8c0@jut.edu.cn> from "=?gb2312?B?s8LA8g==?=" at Oct 23, 99 06:52:08 pm X-Mailer: ELM [version 2.4 PL25] 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 > Dear Sir: > I would like to know how does the IRQs be handled in a SMP > system. Will they be handled by all the processors equally or > by a single processor? If it is the former,who will handle > them finally and what kind of lock mechanism will they follow? > > I expect for your answer and thank you very much for your > kindness and attention. > > In addtion, thank you very much for your telling me the > excellent aphorism. [ ... ] > Dear Sir: > I would like to know how does the IRQs be handled in > a SMP system. Will they be handled by all the processors > equally or by a single processor? If it is the former,who > will handle them finally and what kind of lock mechanism > will they follow: > > I expect for your answer and thank you very much for your > kindness and attention. > Yours sincerely, > Bill Chen You should read the Multiprocessor specification, version 1.4; it is available in PDF form from: http://developer.intel.com/design/pro/datashts/242016.htm The short answer is that Interrupts are handled according to the specification in "virtual wire" mode. This means that Interrupts are handled symmetrically by any of the processors in your system. Currently, only one processor is allowed into the kernel at a time. This means that two interrupts will not be handled concurrently by different processors. Serialization of processor entry into the kernel is handled by a single global kernel lock. The same lock is used for all kernel entry (traps, faults, and interrupts). BSDI has implemented interrupt handling using kernel threads which are lazy-bound. There has been some talk of doing this for FreeBSD, as well, but it is generally discounts as a bad idea, since the technique is 11 years old, and better techniques have been documented in the literature, such as a soft interrupt queue so that the interrupt handling process does not run to completion, rather just to the point where the hardwre can be disengaged. Because the I/O bus can not have simultaneous access for inb/outb for several processors (i.e., there is only one I/O bus), the code needed to actually signal or poll the hardware will likely need to always be serialized, at the lowest level. The need to exclusively access the I/O bus is one of the main factors sited for the developing RAMBus technology coming from major vendors. The console hardware, especially the keyboard and mouse I/O are also driving USB support into SMP machines in order to get larger buffers (keyboard LED maniuplation is one of the worst things you could do on an SMP box, since it is all inb/outb work, with huge spin latencies to not overwhelm the controller). I expect that the 3 and 4 processor Alpha systems from Compaq that are currently at Walnut Creek CDROM for FreeBSD Alpha SMP work will address many of these issues, though I suspect that the I/O bus on those systems, unless they are VME, is still going to have multiplex problems that require serialization. If the intent of the interrupt processing question is to get the best performance you can get out of the hardware, you would do well to not worry so much about the interrupt processing symmetry; one of the main things that NT did on the quad Xeon systems in order to get good numbers relative to Linux was to bind each one of the four 10/100 ethernet cards to a particular processor for interrupt handling. Frankly, you would be better off doing this, and picking hardware that could be communicated with in mapped memory regions instead of using the I/O bus for anything beyond initialization. PS: Please do not send BASE64 encoded ASCII data to the list; thanks. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Oct 25 19:15:17 1999 Delivered-To: freebsd-smp@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 24A1F14C04 for ; Mon, 25 Oct 1999 19:15:07 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id TAA19260; Mon, 25 Oct 1999 19:14:45 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199910260214.TAA19260@gndrsh.dnsmgr.net> Subject: Re: inquire(second time) In-Reply-To: <199910252355.QAA16485@usr06.primenet.com> from Terry Lambert at "Oct 25, 1999 11:55:06 pm" To: tlambert@primenet.com (Terry Lambert) Date: Mon, 25 Oct 1999 19:14:44 -0700 (PDT) Cc: twinkle.star@263.net, freebsd-smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (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 > > The need to exclusively access the I/O bus is one of the main > factors sited for the developing RAMBus technology coming from > major vendors. You had better go sit in the corner and think about that real real real hard. RAMBus technology in no way effects exclusive access to the I/O bus. That is purely in the domain of the CPU / IO bridge chip, and no place near the CPU / Memory controller bridge chip. The main factor driving RAMBus and other fast memory technologies is the fact that our CPU cores are now running in production at 2 to 4 times the data rate of the fastest memory system designs in production. And thats for a single CPU design. The problem of CPU demand vs memory bandwidth is only aggrevated, and thusly requireing a faster memory subsystem, by SMP. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net Design Engineer, HAWK/32, aka MIL MV8000, etc seq memory systems To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Oct 25 19:26:58 1999 Delivered-To: freebsd-smp@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id D960214DEA for ; Mon, 25 Oct 1999 19:26:56 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id TAA21826; Mon, 25 Oct 1999 19:26:52 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpdAAAAMa4CQ; Mon Oct 25 19:26:38 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA26348; Mon, 25 Oct 1999 19:26:34 -0700 (MST) From: Terry Lambert Message-Id: <199910260226.TAA26348@usr06.primenet.com> Subject: Re: inquire(second time) To: freebsd@gndrsh.dnsmgr.net (Rodney W. Grimes) Date: Tue, 26 Oct 1999 02:26:34 +0000 (GMT) Cc: tlambert@primenet.com, twinkle.star@263.net, freebsd-smp@FreeBSD.ORG In-Reply-To: <199910260214.TAA19260@gndrsh.dnsmgr.net> from "Rodney W. Grimes" at Oct 25, 99 07:14:44 pm X-Mailer: ELM [version 2.4 PL25] 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 > > The need to exclusively access the I/O bus is one of the main > > factors sited for the developing RAMBus technology coming from > > major vendors. > > > You had better go sit in the corner and think about that real > real real hard. RAMBus technology in no way effects exclusive > access to the I/O bus. That is purely in the domain of the > CPU / IO bridge chip, and no place near the CPU / Memory controller > bridge chip. > > The main factor driving RAMBus and other fast memory technologies > is the fact that our CPU cores are now running in production at 2 > to 4 times the data rate of the fastest memory system designs in > production. And thats for a single CPU design. The problem of > CPU demand vs memory bandwidth is only aggrevated, and thusly > requireing a faster memory subsystem, by SMP. It was my understanding that this would apply to memory mapped I/O, as well, but of course I haven't investigated RAMBus closely enough (obviously) to be able to say for sure. The idea I was trying to communicate is that memory mapped I/O is a hell of a lot more friendly to SMP than inb/outb based device communication (c.v. my keyboard LED example later in the posting). Anyway, if the RAMBus stuff is useless for direct memory mapped regions on devices (e.g. they can't come in except via slower memory elsewhere), then consider me thwacked. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Oct 25 19:53: 8 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0BA9414E09 for ; Mon, 25 Oct 1999 19:53:04 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA11014; Mon, 25 Oct 1999 19:52:54 -0700 (PDT) (envelope-from dillon) Date: Mon, 25 Oct 1999 19:52:54 -0700 (PDT) From: Matthew Dillon Message-Id: <199910260252.TAA11014@apollo.backplane.com> To: Terry Lambert Cc: freebsd@gndrsh.dnsmgr.net (Rodney W. Grimes), tlambert@primenet.com, twinkle.star@263.net, freebsd-smp@FreeBSD.ORG Subject: Re: inquire(second time) References: <199910260226.TAA26348@usr06.primenet.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> CPU demand vs memory bandwidth is only aggrevated, and thusly :> requireing a faster memory subsystem, by SMP. : :It was my understanding that this would apply to memory mapped I/O, :as well, but of course I haven't investigated RAMBus closely enough :(obviously) to be able to say for sure. Like all memory subsystems, RAMBus depends heavily on pipeline burst memory ops -- i.e. cache line fills and drains to obtain its performance. The two main features of RAMBus is that the RAMBus controller uses a MIPS-like command queueing interface between the cpu and the controller that allows memory ops to be pipelined and a special very high speed serial-like interface between the controller and memory. But this does didily for I/O operations. If you read from an I/O location, whether it is memory-mapped or not, the cpu will stall badly. The same goes for writing to an I/O location though in the case of writing there is usually a small write pipeline that allows some decoupling to occur. RAMBus doesn't help here. The only way to decouple the I/O bus from the processor completely is to use a bus-master-DMA messaging interface whereby the cpu stores an I/O request in main memory and the I/O board DMAs the message in and then DMAs the response back out. A DMA transaction involves no stalls (or, more specifically, the I/O board can release the bus when its pipeline is full to avoid stalling other memory or I/O transactions on the bus). Alternatively it is possible for the I/O device to have a certain amount of cacheable local memory which is mapped into the cpu's address space, allowing the cpu to access I/O requests and responses through its L1 and L2 caches directly (and to burst-cache-line-fill reading back the I/O request). This alternative offers double the bandwidth (you avoid a copy) but requires a bus-snooping cache to allow the I/O device to cache-invalidate the area the message response is stored in. The former mechanisms can also theoretically use the L2 cache and not even bother to flush the I/O requests to main memory, depending on the sophistication of the cpu/cache/memory subsystem. This allows the I/O board to be implemented without duel port memory and maintains the fiction of a main-memory rendezvous without actually incuring the overhead of main memory. -Matt Matthew Dillon :The idea I was trying to communicate is that memory mapped I/O is :a hell of a lot more friendly to SMP than inb/outb based device :communication (c.v. my keyboard LED example later in the posting). : :Anyway, if the RAMBus stuff is useless for direct memory mapped :regions on devices (e.g. they can't come in except via slower :memory elsewhere), then consider me thwacked. 8-). : : Terry Lambert : terry@lambert.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Oct 26 10:15:26 1999 Delivered-To: freebsd-smp@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 13AF514EDE for ; Tue, 26 Oct 1999 10:15:14 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id KAA20511; Tue, 26 Oct 1999 10:14:36 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199910261714.KAA20511@gndrsh.dnsmgr.net> Subject: Re: inquire(second time) In-Reply-To: <199910260226.TAA26348@usr06.primenet.com> from Terry Lambert at "Oct 26, 1999 02:26:34 am" To: tlambert@primenet.com (Terry Lambert) Date: Tue, 26 Oct 1999 10:14:36 -0700 (PDT) Cc: twinkle.star@263.net, freebsd-smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (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 > > > The need to exclusively access the I/O bus is one of the main > > > factors sited for the developing RAMBus technology coming from > > > major vendors. > > > > > > You had better go sit in the corner and think about that real > > real real hard. RAMBus technology in no way effects exclusive > > access to the I/O bus. That is purely in the domain of the > > CPU / IO bridge chip, and no place near the CPU / Memory controller > > bridge chip. > > > > The main factor driving RAMBus and other fast memory technologies > > is the fact that our CPU cores are now running in production at 2 > > to 4 times the data rate of the fastest memory system designs in > > production. And thats for a single CPU design. The problem of > > CPU demand vs memory bandwidth is only aggrevated, and thusly > > requireing a faster memory subsystem, by SMP. > > It was my understanding that this would apply to memory mapped I/O, > as well, but of course I haven't investigated RAMBus closely enough > (obviously) to be able to say for sure. > > The idea I was trying to communicate is that memory mapped I/O is > a hell of a lot more friendly to SMP than inb/outb based device > communication (c.v. my keyboard LED example later in the posting). > > Anyway, if the RAMBus stuff is useless for direct memory mapped > regions on devices (e.g. they can't come in except via slower > memory elsewhere), then consider me thwacked. 8-). Thwack... RAMBus will not change the fact that the I/O devices are hanging on a PCI bus, unless someone decided to design RAMbusPCI :-). Memory mapped IO devices still sit on the PCI bus, and are in no way effected by the real memory bus. They simply map a portion of the memory address space to the PCI bus, and it runs at PCI speeds. Memory on things like PCI Video cards will continue to operate at PCI memory speeds of 132MiB/s (32b/33MHz PCI) or 533MiB/s (64b/66MHz PCI) regardless of the system memory interface type (SDRAM, DDRAM, RAMBus). The keyboard LED speed issue would require a new design of the keyboard interface and a new keyboard design. The major problem here is the very slow 8042 chips used in controlling the keyboard and the bit level dumb (ie, non-intelegent) interface protocol over a single set of bit lines (serial interface) at a fairly low clock rate (I seem to want to say 100KHz, but can't remember what f of keyclk is, anyway, it has not changed since the original IBM PC in frequency, and only mildly changed in protocol since the XT). RAMBus can not and will not effect this in any way. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Oct 26 17:12:52 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 567A514FCC for ; Tue, 26 Oct 1999 17:12:43 -0700 (PDT) (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 4FEFB119 for ; Tue, 26 Oct 1999 19:12:42 -0500 (CDT) Message-ID: <3816437A.304EDD10@ameslab.gov> Date: Tue, 26 Oct 1999 19:12:42 -0500 From: Chris Csanady X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en, ru, ja, ko MIME-Version: 1.0 To: freebsd-smp@freebsd.org Subject: IO APIC misdirecting irq (Re: SMP/interrupt problems..) References: <381159FF.D38E76FD@ameslab.gov> <38115BD9.6B8BE3BA@ameslab.gov> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, this belongs on the SMP list, but it didn't seem to make it here with my first try. Anyways, something is broken here, but I can't put my finger on it. If someone could point me in the right direction, I would be more than willing to try to help fix it. Chris -- I have tracked down the problem with the Megaraid controller in SMP, and it seems it is due to an irq being misrouted. While the controller thinks it is on irq 11, all the interrupts are actually going to apic irq 17. I have confirmed this by hardwiring amr0's interrupt to be irq 17--in which case it works perfectly. :) It is not clear to me whether the irq should or should not be routed to irq 17 though--only that it is what is happening with the current configuration. Does anyone know in particular how this should work? (Or better yet, have a fix? ;) It is kind of weird, because the amr0 controller is actually the same device as the pci-pci bridge, just a different function. So, I assume it is just on the host bus. In any case, even though the irq/int pin match in the mptable, the device (slot) does not. :\ I have included my dmesg, pciconf output, and mptable output. The device in question is the vendor=0x8086, dev=0x1960. Anyone have any ideas? Chris 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 [scsi device probing deleted..] chip0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x12378086 rev=0x02 hdr=0x00 fxp0@pci0:6:0: class=0x020000 card=0x00000000 chip=0x12298086 rev=0x02 hdr=0x00 isab0@pci0:7:0: class=0x060100 card=0x00000000 chip=0x70008086 rev=0x01 hdr=0x00 ata-pci0@pci0:7:1: class=0x010180 card=0x00000000 chip=0x70108086 rev=0x00 hdr=0x00 chip1@pci0:7:2: class=0x0c0300 card=0x00000000 chip=0x70208086 rev=0x01 hdr=0x00 ahc0@pci0:9:0: class=0x010000 card=0x00000000 chip=0x80789004 rev=0x00 hdr=0x00 ncr0@pci0:11:0: class=0x010000 card=0x87601092 chip=0x000f1000 rev=0x14 hdr=0x00 ncr1@pci0:11:1: class=0x010000 card=0x87601092 chip=0x000f1000 rev=0x14 hdr=0x00 pcib1@pci0:15:0: class=0x060400 card=0x00000000 chip=0x09608086 rev=0x03 hdr=0x01 amr0@pci0:15:1: class=0x010000 card=0x0466101e chip=0x19608086 rev=0x03 hdr=0x00 bktr0@pci0:17:0: class=0x040000 card=0x00000000 chip=0x0350109e rev=0x12 hdr=0x00 vga-pci0@pci0:19:0: class=0x030000 card=0x00000000 chip=0x0519102b rev=0x01 hdr=0x00 =============================================================================== 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 =============================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" 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 Tue Oct 26 18:52:46 1999 Delivered-To: freebsd-smp@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 8C3F9152A4 for ; Tue, 26 Oct 1999 18:52:42 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id SAA18497; Tue, 26 Oct 1999 18:52:32 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpdAAAkEaObK; Tue Oct 26 18:52:22 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id SAA17157; Tue, 26 Oct 1999 18:52:07 -0700 (MST) From: Terry Lambert Message-Id: <199910270152.SAA17157@usr02.primenet.com> Subject: Re: inquire(second time) To: freebsd@gndrsh.dnsmgr.net (Rodney W. Grimes) Date: Wed, 27 Oct 1999 01:52:07 +0000 (GMT) Cc: tlambert@primenet.com, twinkle.star@263.net, freebsd-smp@FreeBSD.ORG In-Reply-To: <199910261714.KAA20511@gndrsh.dnsmgr.net> from "Rodney W. Grimes" at Oct 26, 99 10:14:36 am X-Mailer: ELM [version 2.4 PL25] 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 > The keyboard LED speed issue would require a new design of the > keyboard interface and a new keyboard design. The major problem > here is the very slow 8042 chips used in controlling the keyboard > and the bit level dumb (ie, non-intelegent) interface protocol > over a single set of bit lines (serial interface) at a fairly > low clock rate (I seem to want to say 100KHz, but can't remember > what f of keyclk is, anyway, it has not changed since the original > IBM PC in frequency, and only mildly changed in protocol since > the XT). RAMBus can not and will not effect this in any way. Getting way off topic, but the intended fix for this one was a USB keyboard... it seems that there are actually some ISA-free systems out there, even some pure-PCI SMP systems from Intel. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Oct 27 0:13:24 1999 Delivered-To: freebsd-smp@freebsd.org Received: from dingo.cdrom.com (castles520.castles.com [208.214.165.84]) by hub.freebsd.org (Postfix) with ESMTP id EA91914F66 for ; Wed, 27 Oct 1999 00:12:46 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id AAA01010; Wed, 27 Oct 1999 00:04:17 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199910270704.AAA01010@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: " " Cc: smp@freebsd.org Subject: Re: inquire(third time) In-reply-to: Your message of "Sat, 02 Oct 1999 15:45:43 +0800." <001301bf0caa$2a58cea0$c226a8c0@jut.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Oct 1999 00:04:17 -0700 From: Mike Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Dear Mr. Smith: > I'm awfully sorry for asking such vague questions.It is because th= at I > haven't known much of the interrupt mechanism.I was studying Linux an= d was > interested in its interrupts.I have read the Multiprocessor specificati= on, > version 1.4 and I know that interrupts can be handled symmetrically by= any > of the processors in the system.But I still wonder how they are handled= by > the OS. This varies depending on the operating system in question. Which = operating system are you asking about? > While interrupts can be handled symmetrically by any of the > processors ,one interrupt should be handled only once and by a single > processor,I think. That's fairly obvious, really. > I wonder which processor will handle it ? And why it is his turn? > Maybe the processor possesses some kind of lock ,and how can 'he' > obtain the lock? These all depend on the operating system in question, and the algorithms that system may use. Currently FreeBSD uses a single giant kernel = lock, and if an interrupt is handled by a process that doesn't hold the = lock, and another does, the interrupt is forwarded to the CPU that does = hold the lock so that it can process it in the kernel context. > I think there are maybe some similarity between Linux and > Freebsd in dealing with the interrupts since they follow the same MP > Specification. There is some similarity, yes, but FreeBSD and Linux also have = different interrupt architectures and different locking and masking = primitives, so they differ perhaps more than they resemble one another. > I don't know whether I have expressed myself clearly this time.I'm= very > sorry for my poor English. I think that the problem you're having is just that you're not making = clear to me what it is that you actually want to know. Have you looked = at the FreeBSD code yet, and want explanations of how we do things? = Are you asking generalised questions and looking for wide-ranging = answers? As far as it goes, your English is great; you shouldn't be = apologising for it at all. -- = \\ 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 Wed Oct 27 1: 6:23 1999 Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 1BC05152C4 for ; Wed, 27 Oct 1999 01:06:16 -0700 (PDT) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id BAA29129 for ; Wed, 27 Oct 1999 01:28:41 -0700 (PDT) Date: Wed, 27 Oct 1999 01:28:41 -0700 (PDT) From: Alfred Perlstein To: smp@freebsd.org Subject: SMP infoletter #1 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 Infoletter #1 This is the start of what I hope to be several informative documents describing the current and ongoing state of SMP in FreeBSD. The purpose is to avoid duplicate research of the current state of FreeBSD's SMP behavior by those who haven't been following FreeBSD-SMP since 'day one'. It also points out some areas that are still unclear to me. This document was written on Tue Oct 26 1999 referencing the HEAD branch of the code, things may have significantly changed since. I also hope that this series helps to shed some light onto the low level routines in the kernel such as trap and interrupt handling, ASTs and scheduling. Where possible direct pointers are given to source code to reduce the amount of digging one must do to locate routines of interest. It is also important to note that the document is the result of the author investigation into the code, and much appreciated help from various members of the FreeBSD development team, (Poul-Henning Kamp (phk), Alan Cox (alc), Matt Dillon (dillon)) and Terry Lambert. As I am not the writer of the code there may be missing or incorrect information contained in this document. Please email any corrections or comments to smp@freebsd.org and please make sure I get a CC. (alfred@freebsd.org) ------------------------------------------------------------ The Big Giant Lock: (src/sys/i386/i386/mplock.s) The current state of SMP in FreeBSD is by means of the Big Giant Lock, (BGL). The BGL is an exclusive counting semaphore, the lock may be recursively acquired by a single CPU, from that point on other CPUs will spin while waiting to acquire the lock. The implementation on i386 is contained in the file src/sys/i386/i386/mplock.s The function 'void MPgetlock(unsigned int *lock)' acquires the BGL. An important side effect of MPgetlock is that it routes all interrupts to the processor that has acquired the lock. This is done so that if an interrupt occurs the handler doesn't need to spin waiting for the BGL. The code that is responsible for routing the interrupts is the GRAB_HWI macro within the MPgetlock code. Which fiddles the local APIC's interrupt priority level. Other MPlock functions exist in mplock.s to initialize, test and release the lock. --- Usage of the BGL: (src/sys/i386/i386/mplock.s) The BGL is pushed down (acquired) on all entry into the kernel, by means of syscall, trap or interrupt. The file src/sys/i386/i386/exception.s contains all the initial entry points for syscalls, traps and interrupts. syscalls and 'altsyscalls' acquire the lock through the macros SYSCALL_LOCK, and ALTSYSCALL_LOCK which map to the functions assembler functions _get_syscall_lock and _get_altsyscall_lock on SMP machines (if SMP is not defined they are not called) _get_syscall_lock and _get_altsyscall_lock are also present in src/sys/i386/i386/mplock.s, they save the contents of the local apic's interrupt priority and call MPgetlock. It would seem that the syscall lock could simply be delayed until entry to the actual system call (write/read/...) however several issues arise: 1) fault on copyin of user's syscall arguments This is actually a non-issue, if a fault occurs the processor will spin to acquire the MPlock, before potentially recursing into the non-re-entrant vm system. Although this leaves the processor in a faulted state for quite some time, it is no different than when CPU 1 has the lock and a process running on CPU 2 page faults. Problem #1 takes care of itself because of the recursive MPlock. 2) ktrace hooks src/sys/kern/kern_ktrace.c The ktrace hooks in the syscalls manipulate kernel resources that are not MP safe, ktrace touches many parts of the kernel that need work to become MP safe, a temporary solution would be to raise the BGL when entering the ktrace code. 3) STOPEVENT aka void stopevent(struct proc*, unsigned int, unsigned int); /home/src/sys/kern/sys_process.c stopevent will be called if the process is marked to sleep via procfs, stopping the process requires entry into the scheduler which is not MP safe. again a temporary hack would be to conditionally set the MPlock if the condition exists. --- SPL issues: (src/sys/i386/isa/ipl_funcs.c) There exists an inherent race condition with the spl() system in a MP environment, consider: system is at splbio: process A process B int s; int s; s = splhigh(); /* spl raised to high however, saved spl 's' has old value of splbio */ s = splhigh(); /* spl still high */ splx(s); /* processor spl now at bio even though B still needs splhigh */ splx(s); Process B may be interrupted in a critical section. Also note that the asymmetric nature of the spl system makes it very difficult to pinpoint down locations in the the bottom half of the kernel (the part that services interrupts) that may collide with the top half (user process context). A short sighted solution would be to enforce spl as an MPlock, an exclusive counting semaphore, however since no locking protocol or ordering of spl pushdown is required deadlock becomes a major problem. The only solution that may work with spl, is adding the pushdown of the BGL when first asserting any level of spl and releasing the MPlock when spl0 is reached. It may also be interesting to see what a separate lock based only on spl would accomplish, moving to a model where the spl entry points become our new BGL might also be something to investigate. Since spl is used only for short time mutual exclusion it may actually work nicely as a course grained locking system for the time being. --- Simple locks: (src/sys/i386/i386/simplelock.s) cursory research into the CVS logs reveals: on the file kern/vfs_syscalls.c: 1.28 Thu Jul 13 8:47:42 1995 UTC by davidg Diffs to 1.27 NOTE: libkvm, w, ps, 'top', and any other utility which depends on struct proc or any VM system structure will have to be rebuilt!!! Much needed overhaul of the VM system. Included in this first round of changes: ... 4) simple_lock's removed. Discussion with several people reveals that the SMP locking primitives used in the VM system aren't likely the mechanism that we'll be adopting. Even if it were, the locking that was in the code was very inadequate and would have to be mostly re-done anyway. The locking in a uni-processor kernel was a no-op but went a long way toward making the code difficult to read and debug. However with the Lite/2 merge they were re-introduced and the kernel is littered with them, the ones in place seem somewhat adequate for short term exclusion. essentially they are spinlocks. What's interesting is that the simplelocks seem to provide for MP sync with lockmgr locks, however the code is littered with calls to unsafe functions such as MALLOC. It looks like someone decided to do the hard stuff first. Why are the simplelocks necessary if the kernel is still guarded by the BGL? (besides use in the lockmgr) --- Scheduler: The scheduler in cpu_switch() (src/sys/i386/i386/swtch.s) saves the current nesting level of the process's MPlock (after masking off the CPUid bits from it) into the PCB (process control block) (lines 317-324) before attempting to switch to another process where it restores the next process's nesting level (lines 453-455). --- -Alfred Perlstein - [bright@rush.net|alfred@freebsd.org] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [bright@wintelcom.net] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Oct 27 8:36:37 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 94A1B14FFE for ; Wed, 27 Oct 1999 08:36:34 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id LAA04300; Wed, 27 Oct 1999 11:35:58 -0400 (EDT) (envelope-from luoqi) Date: Wed, 27 Oct 1999 11:35:58 -0400 (EDT) From: Luoqi Chen Message-Id: <199910271535.LAA04300@lor.watermarkgroup.com> To: bright@wintelcom.net, smp@FreeBSD.ORG Subject: Re: SMP infoletter #1 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I would like to offer some comments here. > > Usage of the BGL: (src/sys/i386/i386/mplock.s) > > The BGL is pushed down (acquired) on all entry into the kernel, by ^^^^^^^^^^^ My understanding is push down is a completely different term. > means of syscall, trap or interrupt. ... > It would seem that the syscall lock could simply be delayed until > entry to the actual system call (write/read/...) however several > issues arise: > > 1) fault on copyin of user's syscall arguments ... > > Problem #1 takes care of itself because of the recursive MPlock. > > 2) ktrace hooks ... > > 3) STOPEVENT aka void stopevent(struct proc*, unsigned int, unsigned int); ... You missed one very important part of the code path, which is also the most difficult one to be dealt with to make the path MP safe: userret(), it involves scheduling (relatively easier) and signal delivery (difficult). > > --- > > SPL issues: (src/sys/i386/isa/ipl_funcs.c) > > There exists an inherent race condition with the spl() system in > a MP environment, consider: > > system is at splbio: > > process A process B > > int s; int s; > s = splhigh(); /* spl raised to high however, > saved spl 's' has old value > of splbio */ > s = splhigh(); /* spl still high */ > splx(s); /* processor spl now at bio > even though B still needs > splhigh */ > splx(s); > > > Process B may be interrupted in a critical section. > > Also note that the asymmetric nature of the spl system makes it > very difficult to pinpoint down locations in the the bottom half > of the kernel (the part that services interrupts) that may collide > with the top half (user process context). > > A short sighted solution would be to enforce spl as an MPlock, an > exclusive counting semaphore, however since no locking protocol or > ordering of spl pushdown is required deadlock becomes a major > problem. > > The only solution that may work with spl, is adding the pushdown > of the BGL when first asserting any level of spl and releasing the > MPlock when spl0 is reached. > > It may also be interesting to see what a separate lock based only > on spl would accomplish, moving to a model where the spl entry > points become our new BGL might also be something to investigate. > I actually have a working implementation for this (I'm willing to provide the patch if anyone is interested to try). But I believe this leads to a dead-end. We should use some kind of interrupt level aware mutex instead, something like this s = splimp(); simple_lock(&mbuf_lock); ... simple_unlock(&mbuf_lock); splx(s); If everyone agrees on this direction, there is an immediate benefit we can reap by moving cpl to per-cpu storage and getting rid of cpl_lock, which might a reduce significant amount of system time (5~10% unscientifically). > Since spl is used only for short time mutual exclusion it may > actually work nicely as a course grained locking system for the > time being. > The reason I believe this is leading us to nowhere is that it is a hack and it could only marginally improve the performance as most of the kernel is running under some spl protection, e.g., it's impossible to move tcp stack outside the BGL under this scheme. > > Why are the simplelocks necessary if the kernel is still guarded > by the BGL? (besides use in the lockmgr) > Under BGL it's not even necessary in the lockmgr, in fact, the only useful simplelocks are the fast interrupt lock and the lock on i/o apic register window (fast interrupt handlers are not under BGL protection, IIRC, the only instance is sio). But BGL is to go and hence simplelock is here to stay. One interest things NetBSD has done was a read/write spinlock, it could be used to protect lists like allproc. I think it is nice to have in our system too. > --- > > Scheduler: > > The scheduler in cpu_switch() (src/sys/i386/i386/swtch.s) saves the > current nesting level of the process's MPlock (after masking off > the CPUid bits from it) into the PCB (process control block) (lines > 317-324) before attempting to switch to another process where it > restores the next process's nesting level (lines 453-455). > One thing that is relatively easy to do in this area is to allow a processor spin waiting for the BGL to pick up another user process. I'm currently looking into this problem myself, one thing I would like to do is to move the nesting level field from the u area to struc proc, so that we could easily tell if a process was (involuntarily) context switched in the user mode and a candidate to schedule on a non-lock holding processor. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Oct 29 16: 3:48 1999 Delivered-To: freebsd-smp@freebsd.org Received: from vip.consys.com (VIP.ConSys.COM [209.141.107.6]) by hub.freebsd.org (Postfix) with ESMTP id 9FBEF1513E for ; Fri, 29 Oct 1999 16:03:34 -0700 (PDT) (envelope-from rcarter@pinyon.org) Received: (from pinyon@localhost) by vip.consys.com (8.9.3/8.9.1) id QAA07832 for freebsd-smp@freebsd.org; Fri, 29 Oct 1999 16:03:33 -0700 (MST) Date: Fri, 29 Oct 1999 16:03:33 -0700 (MST) From: "Russell L. Carter" Message-Id: <199910292303.QAA07832@vip.consys.com> To: freebsd-smp@freebsd.org Subject: signal changes and LinuxThreads SMP problem Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Are there any obvious semantic differences between the behavior of signals on SMP now as opposed to before Marcel's greatly appreciated changes -current? I just brought across Richard Seaman's LinuxThreads port, and it works fine on UP but crashes and burns on SMP. Previously I encountered no problems on SMP, testing using ACE+TAO pretty heavily. The problem is quite easily reproducible with the tiny examples included in the port. ex2 and ex4 fail on SMP, work perfectly on the same system booted UP. Doesn't matter if I link with libgcc_r or not. I put up an updated version of the port at http://www.Pinyon.ORG/ace/lthreads-991029.tar.gz if anyone is interested. Cheers, Russell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Oct 29 17:24: 2 1999 Delivered-To: freebsd-smp@freebsd.org Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30]) by hub.freebsd.org (Postfix) with ESMTP id 8B68314A27 for ; Fri, 29 Oct 1999 17:23:32 -0700 (PDT) (envelope-from blanquer@cast-info.es) Received: from cast-info.es (tack [128.111.40.39]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id RAA22881 for ; Fri, 29 Oct 1999 17:23:29 -0700 (PDT) Message-ID: <381A3BB5.6AE8ACA8@cast-info.es> Date: Fri, 29 Oct 1999 17:28:37 -0700 From: "Josep M. Blanquer" X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-smp@freebsd.org Subject: SMP testing machine Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there, We're looking on buying a new SMP machine for testing/fixing our kernel extensions to be 'SMP compliant'. For that we'd like a non-SMP-problematic machine, known to work well with the actual SMP implementation. After a little bit of digging I came up with 2/3 possible choices: 1- A Supermicro P6DGU based box (2xP3,440GX, 7890 Ultra2). This seems to be a board that works fine as far as the list archives. 2- A DELL poweredge 1300 (440BX based) or 2300 (440GX based) , (2xP3, Ultra2 LVD) I have no clue on how the system behaves on SMP ( from the archives, it seems that it worked fine in uniprocessor mode about a year ago...) Since it is mainly for SMP testing and I want to minimize the possible hw problems, I'd really appreciate any comments from anyone that knows or it's using any of them with an SMP kernel. Thanks, J. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Oct 29 17:33:32 1999 Delivered-To: freebsd-smp@freebsd.org Received: from bajor.hosteng.org (bajor.hosteng.org [194.248.74.241]) by hub.freebsd.org (Postfix) with ESMTP id CBBD214A19 for ; Fri, 29 Oct 1999 17:33:11 -0700 (PDT) (envelope-from ivar@hosteng.org) Received: from praxis (praxis.hosteng.org [194.248.74.243]) by bajor.hosteng.org (8.9.3/8.9.3) with SMTP id CAA00401 for ; Sat, 30 Oct 1999 02:33:07 +0200 (CEST) (envelope-from ivar@hosteng.org) From: "=?iso-8859-1?Q?Ivar_E._H=F8steng?=" To: Subject: Samba performance problems running on FreeBSD 3.3-STABLE using the SMP kernal and 2 PPros Date: Sat, 30 Oct 1999 02:33:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- I have just discovered that my performance problems with samba (2.0.5a) dissapears if I build a non SMP version of the FreeBSD kernal on my dual 200Mhz PPro system. Using the SMP enabled kernal writes from the Windows98 explorer is painfully slow. A 121MB file takes around 30 minutes to copy from a local harddisk on the win98 machine to a samba share on the FreeBSD server. Using the exactly same kernel and samba configuration except commenting out the SMP stuff in the kernel config file the same copy takes aroud 20 seconds. Reads from the samba share are not noticably affected when using the nonSMP kernal. Here is my kernel config file: # # SMP-GENERIC -- Smp machine with WD/AHx/NCR/BTx family disks # # For more information read the handbook part System Administration - -> # Configuring the FreeBSD Kernel -> The Configuration File. # The handbook is available in /usr/share/doc/handbook or online as # latest version from the FreeBSD World Wide Web server # # # An exhaustive list of options and more detailed explanations of the # device lines is present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $Id: SMP-GENERIC,v 1.17 1998/10/16 04:44:05 peter Exp $ machine "i386" # SMP does NOT support 386/486 CPUs. #cpu "I386_CPU" #cpu "I486_CPU" cpu "I686_CPU" ident Ivar maxusers 100 # Create a SMP capable kernel (mandatory options): options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optional, these are the defaults: #options NCPU=2 # number of CPUs #options NBUS=4 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs # Lets always enable the kernel debugger for SMP. options DDB # SMP shouldn't need x87 emulation, disable by default. #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options MFS #Memory Filesystem options MFS_ROOT #MFS usable as root device, "MFS" req'ed options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, "NFS" req'ed options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options "CD9660_ROOT" #CD-ROM usable as root. "CD9660" req'ed options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=3000 #Be pessimistic about Joe SCSI device options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options IPFIREWALL options IPFIREWALL_VERBOSE options IPDIVERT options IPFILTER options IPFILTER_LOG config kernel root on wd0 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 # Unless you know very well what you're doing, leave ft0 at drive 2, or # remove the line entirely if you don't need it. Trying to configure # it on another unit might cause surprises, see PR kern/7176. options "CMD640" # work around CMD640 chip deficiency controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 options ATAPI #Enable ATAPI support for IDE bus options ATAPI_STATIC #Don't do it as an LKM # A single entry for any of these controllers (ncr, ahb, ahc, amd) is # sufficient for any number of installed devices. controller ahc0 # This controller offers a number of configuration options, too many to # document here - see the LINT file in this directory and look up the # dpt0 entry there for much fuller documentation on this. controller scbus0 device da0 device sa0 device pass0 device cd0 #Only need one of these, the code dynamically grows # atkbdc0 controls 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 device npx0 at isa? port "IO_NPX" irq 13 vector npxintr # # Laptop support (see LINT for more options) # device sio0 at isa? port "IO_COM1" flags 0x10 tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr # Parallel port device ppc0 at isa? port? flags 0x40 net irq 7 controller ppbus0 # Parallel port bus (required) device lpt0 at ppbus? # Printer device plip0 at ppbus? # TCP/IP over parallel device ppi0 at ppbus? # Parallel port interface device #controller vpo0 at ppbus? # Requires scbus and da0 # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. # Right now it appears that the ie0 must be probed before ep0. See # revision 1.20 of this file. device fxp0 device xl0 pseudo-device loop pseudo-device ether pseudo-device vn 10 pseudo-device sl 1 pseudo-device ppp 1 pseudo-device tun 8 pseudo-device ccd 4 pseudo-device pty 256 pseudo-device gzip # Exec gzipped a.out's # KTRACE enables the system-call tracing facility ktrace(2). # This adds 4 KB bloat to your kernel, and slightly increases # the costs of each syscall. options KTRACE #kernel tracing # This provides support for System V shared memory. # options SYSVSHM options SYSVMSG options SYSVSEM # The `bpfilter' pseudo-device enables the Berkeley Packet Filter. Be # aware of the legal and administrative consequences of enabling this # option. The number of devices determines the maximum number of # simultaneous BPF clients programs runnable. pseudo-device bpfilter 4 #Berkeley packet filter pseudo-device snp 4 mptable gives the following output: ====================================================================== ======== MPTable, version 2.0.15 looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009fc00 searching CMOS 'top of mem' @ 0x0009f800 (638K) searching default 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f0000 MP FPS found in BIOS @ physical addr: 0x000f7ed0 - ---------------------------------------------------------------------- - -------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f7ed0 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0x33 mode: Virtual Wire - ---------------------------------------------------------------------- - -------- MP Config Table Header: physical address: 0x000f7ee0 signature: 'PCMP' base table length: 260 version: 1.4 checksum: 0xce OEM ID: 'INTEL ' Product ID: 'PR440FX ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 24 local APIC address: 0xfec08000 extended table length: 100 extended table checksum: 49 - ---------------------------------------------------------------------- - -------- 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 9 13 9 INT active-hi edge 18 12 13 12 INT active-hi edge 18 14 13 14 INT active-lo level 1 5:A 13 18 INT active-lo level 1 4:A 13 17 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# - ---------------------------------------------------------------------- - -------- MP Config Extended Table Entries: - -- 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 ====================================================================== ======== and dmesg: 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-STABLE #4: Sun Oct 10 16:58:15 CEST 1999 ivar@bajor.hosteng.org:/usr/src/sys/compile/ivar Timecounter "i8254" frequency 1193182 Hz CPU: Pentium Pro (686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping = 9 Features=0xfbff real memory = 134217728 (131072K bytes) avail memory = 127315968 (124332K bytes) Programming 24 pins in IOAPIC #0 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 Preloaded elf kernel "kernel" at 0xc02f7000. Pentium Pro MTRR support enabled Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 fxp0: rev 0x01 int a irq 18 on pci0.6.0 fxp0: Ethernet address 00:a0:c9:06:bf:a6 chip1: rev 0x01 on pci0.7.0 ide_pci0: rev 0x00 on pci0.7.1 ahc0: rev 0x00 int a irq 17 on pci0.9.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs xl0: <3Com 3c905-TX Fast Etherlink XL> rev 0x00 int a irq 16 on pci0.11.0 xl0: Ethernet address: 00:60:97:1d:07:a9 xl0: autoneg not complete, no carrier (forcing half-duplex, 10Mbps) chip2: rev 0x02 on pci0.15.0 ahc1: rev 0x01 int a irq 18 on pci0.17.0 ahc1: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs vga0: rev 0x00 int a irq 19 on pci0.19.0 Probing for devices on PCI bus 1: ahc2: rev 0x00 int a irq 17 on pci1.4.0 ahc2: aic7870 Single Channel A, SCSI Id=7, 16/255 SCBs ahc3: rev 0x00 int a irq 18 on pci1.5.0 ahc3: aic7870 Single Channel B, SCSI Id=7, 16/255 SCBs 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 not found sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A, console sio1: configured irq 3 not in bitmap of probed irqs 0 sio1 not found at 0x2f8 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 not found at 0x1f0 ppc0 at 0x378 irq 7 flags 0x40 on isa ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppb0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: PJL,MLC,PCLXL,PCL,POSTSCRIPT 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: routing 8254 via 8259 on pin 0 IP packet filtering initialized, divert enabled, rule-based forwarding disabled, unlimited logging ccd0-3: Concatenated disk drivers IP Filter: initialized. Default = pass all, Logging = enabled Waiting 3 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! sa0 at ahc2 bus 0 target 2 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 15) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) da4 at ahc2 bus 0 target 0 lun 0 da4: Fixed Direct Access SCSI-2 device da4: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da4: 8669MB (17755614 512 byte sectors: 255H 63S/T 1105C) cd0 at ahc3 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 4.629MB/s transfers (4.629MHz, offset 8) cd0: cd present [125982 x 2048 byte records] da3 at ahc1 bus 0 target 4 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled da3: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) da2 at ahc1 bus 0 target 0 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) changing root device to da0s1a Does anyone have a clue of why this is happening? Regards, Ivar E. Hosteng email: ivar@hosteng.org -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1i for non-commercial use iQCVAwUBOBousXeH1nNr2gf9AQEK8wP+K6GT9v0XQQXIp0w8r9xAUWKCxxz5IFAO 1h8p661eAKl8fr3Eq+/Fj4JYP3zJ6l+D4jXlcwfXUBcbr0NEUCfvN0kFRMvMxfkl VN9PfmpZMWo/mGdB8yj9A9jLMnG7OWBpE5Ls1J3mTLyx94V0750hXHXI8z2lGMi2 HHTb2rnlccA= =D7iQ -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Oct 29 18: 7:45 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 7298214C88 for ; Fri, 29 Oct 1999 18:07:25 -0700 (PDT) (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 11hN00-000K7m-00; Sat, 30 Oct 1999 01:08:06 +0000 Date: Sat, 30 Oct 1999 03:07:11 +0200 (CEST) From: Marc Schneiders To: "Josep M. Blanquer" Cc: freebsd-smp@freebsd.org Subject: Re: SMP testing machine In-Reply-To: <381A3BB5.6AE8ACA8@cast-info.es> 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 On Fri, 29 Oct 1999, Josep M. Blanquer wrote: > > Hi there, > > We're looking on buying a new SMP machine for testing/fixing our > kernel extensions to be 'SMP compliant'. For that we'd like a > non-SMP-problematic machine, known to work well with the actual > SMP implementation. > > After a little bit of digging I came up with 2/3 possible > choices: > > 1- A Supermicro P6DGU based box (2xP3,440GX, 7890 Ultra2). This > seems to be > a board that works fine as far as the list archives. > > 2- A DELL poweredge 1300 (440BX based) or 2300 (440GX based) , > (2xP3, Ultra2 LVD) > I have no clue on how the system behaves on SMP ( from the > archives, it seems that it worked fine in uniprocessor mode about > a year ago...) > > Since it is mainly for SMP testing and I want to minimize the > possible hw problems, I'd really appreciate any comments from > anyone that knows or it's using any of them with an SMP kernel. > Unfortunately these boards/cpu's are out of my reach financially. I do have two identical smp-boxes, that run great, both FreeBSD as well as other SMP-Os's. You never see the board in lists (I didn't anyway), probably because it has no problems (except when running with one particular Diamond card here). It is the ECS (alias Elitegroup) P6FX2-A for two Pentium Pro's. The Pro's (certainly the ones with 256k cache) are below $100 for the two. The board I got here in Holland for about $50. It eats EDO RAM. It is not the latest of the latest, but well, you can buy something else as well for your money. Marc Marc Schneiders || In re tam justa || nulla est deliberatio! marc@venster.nl || marc@oldserver.demon.nl || Acta SS. MM. Scillitanorum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Oct 29 18:18:44 1999 Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id C44C514CFB for ; Fri, 29 Oct 1999 18:18:33 -0700 (PDT) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id SAA04301; Fri, 29 Oct 1999 18:41:24 -0700 (PDT) Date: Fri, 29 Oct 1999 18:41:24 -0700 (PDT) From: Alfred Perlstein To: "Josep M. Blanquer" Cc: freebsd-smp@FreeBSD.ORG Subject: Re: SMP testing machine In-Reply-To: <381A3BB5.6AE8ACA8@cast-info.es> 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 On Fri, 29 Oct 1999, Josep M. Blanquer wrote: > > Hi there, > > We're looking on buying a new SMP machine for testing/fixing our > kernel extensions > to be 'SMP compliant'. For that we'd like a non-SMP-problematic machine, > known > to work well with the actual SMP implementation. I know several people using Asus P2D boards, besideds somewhat weird BIOS (an upgrade may fix it) they run pretty good. Lately with all the hardware I've been looking at most generic motherboards seem to work fine with FreeBSD, a few of the more proprietary stuff can be a pain though. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Oct 29 20:59:11 1999 Delivered-To: freebsd-smp@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 411EA14D4E for ; Fri, 29 Oct 1999 20:59:07 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id UAA32986; Fri, 29 Oct 1999 20:58:49 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199910300358.UAA32986@gndrsh.dnsmgr.net> Subject: Re: SMP testing machine In-Reply-To: from Alfred Perlstein at "Oct 29, 1999 06:41:24 pm" To: bright@wintelcom.net (Alfred Perlstein) Date: Fri, 29 Oct 1999 20:58:48 -0700 (PDT) Cc: blanquer@cast-info.es (Josep M. Blanquer), freebsd-smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (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 > On Fri, 29 Oct 1999, Josep M. Blanquer wrote: > > > > > Hi there, > > > > We're looking on buying a new SMP machine for testing/fixing our > > kernel extensions > > to be 'SMP compliant'. For that we'd like a non-SMP-problematic machine, > > known > > to work well with the actual SMP implementation. > > I know several people using Asus P2D boards, besideds somewhat weird > BIOS (an upgrade may fix it) they run pretty good. > > Lately with all the hardware I've been looking at most generic > motherboards seem to work fine with FreeBSD, a few of the more > proprietary stuff can be a pain though. And we, AAI, the very first supplier of SMP boxes for the development effort, are the in process of switching from the ASUS boards (they still work great, I'm not in any way down grading the quality/name brand status of ASUS) to Soltek (www.soltek,com.tw) due to our being a manufacture direct distributor for their products. I have run they SL-68A through the ringers here and it works just as good as the ASUS board at 1/2 the price. The board is a very similar to the ASUS card, with some minor physical component location differences, the more familiar standard AWARD 4.51PG bios interface, and no play around with games called ``jumperfreee'' and some of the other not so good stunts ASUS has pulled in their more recent product offering. That and we get A#1 support from Soltek on this product, right down to an Engineer on the phone if we have a problem of some sort (we have not had to do that on this board, but on our more popular SL54U1 super socket 7 there where early issues with AMD K6-2 100Mhz bus CPU's that they had fixed in days for us, no marketing sales people got in our way, it was engineer to engineer, though we could have used a translator :-).) -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Sat Oct 30 3:54:53 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id D6B811503D for ; Sat, 30 Oct 1999 03:54:47 -0700 (PDT) (envelope-from freebsd-smp@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id MAA93942 for smp@FreeBSD.org; Sat, 30 Oct 1999 12:43:12 +0200 (CEST) (envelope-from freebsd-smp@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for smp@FreeBSD.org (smp@FreeBSD.org) To: smp@FreeBSD.org Date: Sat, 30 Oct 1999 12:43:04 +0200 From: Marcel Moolenaar Message-ID: <381ACBB8.B348B707@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <199910292303.QAA07832@vip.consys.com> Subject: Re: signal changes and LinuxThreads SMP problem Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Russell L. Carter" wrote: > Are there any obvious semantic differences between > the behavior of signals on SMP now as opposed to before > Marcel's greatly appreciated changes -current? The translation of signals has been changed semantically, but this should only affect the svr4 emulator. > I just brought > across Richard Seaman's LinuxThreads port, and it works > fine on UP but crashes and burns on SMP. Previously > I encountered no problems on SMP, testing using > ACE+TAO pretty heavily. Tell me about the port. BTW: I run SMP, so testing should not be a problem. -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message