Subject: Re: NetBSD Multiprocessor on 264DP
To: NetBSD/Alpha Discussion List <port-alpha@NetBSD.org>
From: Anders Hogrelius <ahs@hogrelius.nu>
List: port-alpha
Date: 12/21/2006 03:05:23
Well, so far I've been unable to get this box to run with a MP kernel. I
tried the 3.1 GENERIC.MP kernel that is on the install cd. -Didn't work.
It refuses to recognize sd0a as root. The GENERIC kernel works and finds
sd0a, so this seemed weird. I went on to compile a kernel of my own and
used the GENERIC.MP config file. The compilation went fine but the problem
is still the same. A home-rolled GENERIC kernel works and finds the sd0a
slice, but add the MP option to the same config file and it stops working.

Is this a known bug and if so, is there a cure for it?


Cheers,
Anders
--
This mail was sent on Wed 12/20/06 at 6:01PM PST


You're dead, Jim.
		-- McCoy, "Amok Time", stardate 3372.7

*************************************************************************
*                        Cell :   +46(0)70 677-0210
* Anders Hogrelius, MSc  Phone:   +1(714)408-7868
* Tessingatan 12         E-mail:  anders@hogrelius.nu
* SE-72216 Vasteras      Web:     http://www.hogrelius.nu/~ahs/
* SWEDEN                 SkypeID: ahogrelius

On Sun, 17 Dec 2006, Greg A. Woods wrote:

> At Sun, 17 Dec 2006 21:15:55 +0100 (CET),
> Anders Hogrelius wrote:
> >
> >
> > Does anyone have any experience with NetBSD running on a 264DP
> > motherboard?
>
> [ using 333784 bytes of netbsd ELF symbol table ]
> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
>     The NetBSD Foundation, Inc.  All rights reserved.
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>     The Regents of the University of California.  All rights reserved.
>
> NetBSD 1.6.2_STABLE (PC264DP.MP) #0: Tue Jul 11 12:33:06 EDT 2006
>     woods@whats:/build/woods/whats/NetBSD-1.6.x-alpha-alpha-21164a-obj/building/work/woods/m-NetBSD-1.6/sys/arch/alpha/compile/PC264DP.MP
> AlphaPC 264DP 500 MHz, s/n 000233
> 8192 byte page size, 2 processors.
> total memory = 512 MB
> (2808 KB reserved for PROM, 509 MB used by NetBSD)
> avail memory = 436 MB
> using 6510 buffers containing 52080 KB of memory
> mainbus0 (root)
> cpu0 at mainbus0: ID 0 (primary), 21264-4
> cpu0: Architecture extensions: 303<PAT,MVI,FIX,BWX>
> cpu1 at mainbus0: ID 1, 21264-4
> cpu1: Architecture extensions: 303<PAT,MVI,FIX,BWX>
> tsc0 at mainbus0: 21272 Core Logic Chipset, Cchip rev 0
> tsc0: 8 Dchips, 2 memory buses of 32 bytes
> tsc0: arrays present: 0MB, 512MB, 0MB, 0MB, Dchip 0 rev 1
> tsp0 at tsc0
> pci0 at tsp0 bus 0
> pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
> sio0 at pci0 dev 5 function 0: Contaq Microsystems 82C693 PCI-ISA Bridge (rev. 0x00)
> pciide0 at pci0 dev 5 function 1: Cypress 82C693 IDE Controller (rev. 0x00)
> pciide0: bus-master DMA support present
> pciide0: primary channel wired to compatibility mode
> atapibus0 at pciide0 channel 0: 2 targets
> cd0 at atapibus0 drive 0: <CD-ROM CDU701, , 1.0r> type 5 cdrom removable
> cd0: 32-bit data port
> cd0: drive supports PIO mode 4, DMA mode 2
> pciide0: primary channel interrupting at isa irq 14
> cd0(pciide0:0:0): using PIO mode 4, DMA mode 2 (using DMA data transfers)
> pciide1 at pci0 dev 5 function 2: Cypress 82C693 IDE Controller (rev. 0x00)
> pciide1: hardware does not support DMA
> pciide1: primary channel wired to compatibility mode
> pciide1: disabling primary channel (no drives)
> ohci0 at pci0 dev 5 function 3: Contaq Microsystems 82C693 PCI-ISA Bridge (rev. 0x00)
> ohci0: interrupting at isa irq 10
> ohci0: OHCI version 1.0, legacy support
> usb0 at ohci0: USB revision 1.0
> uhub0 at usb0
> uhub0: Contaq Microsys OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> uhub0: 2 ports with 2 removable, self powered
> ahc0 at pci0 dev 6 function 0
> ahc0: interrupting at dec 6600 irq 19
> ahc0: aic7895C: Ultra Wide Channel A, SCSI Id=7, 32/253 SCBs
> scsibus0 at ahc0: 16 targets, 8 luns per target
> ahc1 at pci0 dev 6 function 1
> ahc1: interrupting at dec 6600 irq 18
> ahc1: aic7895C: Ultra Wide Channel B, SCSI Id=7, 32/253 SCBs
> scsibus1 at ahc1: 16 targets, 8 luns per target
> vga0 at pci0 dev 7 function 0: Texas Instruments TVP4020 Permedia 2 (rev. 0x01)
> pci_mem_find: void region
> pci_mem_find: void region
> pci_mem_find: void region
> wsdisplay0 at vga0 (kbdmux ignored)
> ex0 at pci0 dev 9 function 0: 3Com 3c905B-TX 10/100 Ethernet (rev. 0x30)
> ex0: interrupting at dec 6600 irq 23
> ex0: MAC address 00:10:5a:67:84:73
> exphy0 at ex0 phy 24: 3Com internal media interface
> exphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> isa0 at sio0
> com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
> com0: console
> com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
> pckbc0 at isa0 port 0x60-0x64
> lpt0 at isa0 port 0x3bc-0x3bf irq 7
> pcppi0 at isa0 port 0x61
> midi0 at pcppi0: PC speaker
> spkr0 at pcppi0
> isabeep0 at pcppi0
> fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
> fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
> mcclock0 at isa0 port 0x70-0x71: mc146818 or compatible
> tsp1 at tsc0
> pci1 at tsp1 bus 0
> pci1: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
> tlp0 at pci1 dev 7 function 0: DECchip 21140 Ethernet, pass 1.2
> tlp0: broken MicroWire interface detected; setting SROM size to 1Kb
> tlp0: interrupting at dec 6600 irq 47
> tlp0: DEC DE500-XA, Ethernet address 00:00:f8:1e:25:75
> tlp0: 10baseT, 100baseTX, 100baseTX-FDX, 10baseT-FDX
> mlx0 at pci1 dev 9 function 0: Mylex RAID (v2 interface)
> mlx0: interrupting at dec 6600 irq 39
> mlx0: DAC960P/PD, 3 channels, firmware 2.70-0-00, interface V2, 4MB RAM
> ld0 at mlx0 unit 0: RAID0, online
> ld0: 32766 MB, 8321 cyl, 128 head, 63 sec, 512 bytes/sect x 67104768 sectors
> ld1 at mlx0 unit 1: RAID0, online
> ld1: 19332 MB, 9819 cyl, 64 head, 63 sec, 512 bytes/sect x 39591936 sectors
> scsibus0: waiting 2 seconds for devices to settle...
> sd0 at scsibus0 target 0 lun 0: <DEC, RZ29B    (C) DEC, 0016> SCSI2 0/direct fixed
> sd0: 4091 MB, 3708 cyl, 20 head, 113 sec, 512 bytes/sect x 8380080 sectors
> sd0: sync (172.0ns offset 8), 16-bit (11.626MB/s) transfers, tagged queueing
> scsibus1: waiting 2 seconds for devices to settle...
> sd1 at scsibus1 target 1 lun 0: <DEC, RZ29B    (C) DEC, 0016> SCSI2 0/direct fixed
> sd1: 4091 MB, 3708 cyl, 20 head, 113 sec, 512 bytes/sect x 8380080 sectors
> sd1: sync (172.0ns offset 8), 16-bit (11.626MB/s) transfers, tagged queueing
> sd2 at scsibus1 target 2 lun 0: <DEC, RZ29B    (C) DEC, 0016> SCSI2 0/direct fixed
> sd2: 4091 MB, 3708 cyl, 20 head, 113 sec, 512 bytes/sect x 8380080 sectors
> sd2: sync (172.0ns offset 8), 16-bit (11.626MB/s) transfers, tagged queueing
> Kernelized RAIDframe activated
> RAIDframe: NOTICE: no RAID sets found, no root RAID possible...
> root on sd0a dumps on sd0b
> IP Filter: v3.4.29 initialized.  Default = pass all, Logging = enabled
> vga_init_screen: no font
> wsdisplay0: screen 1 added (80x50, vt100 emulation)
> vga_init_screen: no font
> wsdisplay0: screen 2 added (80x50, vt100 emulation)
> vga_init_screen: no font
> wsdisplay0: screen 3 added (80x50, vt100 emulation)
> vga_init_screen: no font
> wsdisplay0: screen 4 added (80x50, vt100 emulation)
> vga_init_screen: no font
> wsdisplay0: screen 5 added (80x50, vt100 emulation)
> wsdisplay0: screen 6 added (80x25, vt100 emulation)
> wsdisplay0: screen 7 added (80x25, vt100 emulation)
>
>
> > I'm about to upgrade my server and would like to know if
> > there are any quirks getting a Multiprocessor kernel running on one of
> > these boards.
>
> Nope, it should just work, though I don't remember if I've tried a
> GENERIC.MP kernel on it or not (I had tried my TSUNAMI (es40) kernel on
> it, but that didn't work so well so I hacked a custom one based on
> mappings I discovered running the GENERIC kernel)
>
> > Are there any limitations to the amount of memory?
>
> There shouldn't be, at least within the hardware limitations of the
> board (which are quite high, IIRC)
>
> > Is it
> > stable?
>
> Very.  At least with my hacked 1.6.x kernels.  It works as well as the
> ES40, which is to be expected.
>
> I use mine to build and test binary releases and binary packages, as
> well as some testing, and sometimes more transient emacs sessions.
>
> --
> 						Greg A. Woods
>
> H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
> Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>
>