From owner-freebsd-alpha Sun Oct 24 6:25:45 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from smtp04.wxs.nl (smtp04.wxs.nl [195.121.6.59]) by hub.freebsd.org (Postfix) with ESMTP id E4FAE14F5D; Sun, 24 Oct 1999 06:25:36 -0700 (PDT) (envelope-from bottemanne@capitolonline.nl) Received: from capitolonline.nl ([195.121.169.45]) by smtp04.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA6922; Sun, 24 Oct 1999 15:25:14 +0200 Message-ID: <3813145D.72C0EF6A@capitolonline.nl> Date: Sun, 24 Oct 1999 15:14:53 +0100 From: Aernoudt Bottemanne X-Mailer: Mozilla 4.04 [en] (OS/2; I) MIME-Version: 1.0 To: Andrew Gallatin Cc: dfr@nlsystems.com, alpha@freebsd.org, "freebsd-alpha@freebsd.org" Subject: Re: small fix for irq mappig probelm References: <14354.8792.767477.900314@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This fix works for my PWS 433au (miata) ! Just to let you know. Andrew Gallatin wrote: > Doug, > > When using a kernel built after your recent changes to pci.c, alpha > PCI devices with intline==0 fail to map their interrupt. This > typically happens with the on-board tulip in a miata: > > de0: irq 0 at device 3.0 on pci0 > pci_map_int: can't allocate interrupt > > The appended patch fixes it, but I am unsure it is correct. Can you > approve it? > > Thanks, > > Drew > ------------------------------------------------------------------------------ > Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin > Duke University Email: gallatin@cs.duke.edu > Department of Computer Science Phone: (919) 660-6590 > > Index: sys/pci/pci.c > =================================================================== > RCS file: /home/ncvs/src/sys/pci/pci.c,v > retrieving revision 1.123 > diff -u -r1.123 pci.c > --- pci.c 1999/10/17 06:48:47 1.123 > +++ pci.c 1999/10/23 20:56:52 > @@ -1045,7 +1045,7 @@ > (unsigned int) base, ln2size); > } > } > - if (cfg->intline) > + if (cfg->intpin) > resource_list_add(rl, SYS_RES_IRQ, 0, > cfg->intline, cfg->intline, 1); > } > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sun Oct 24 6:25:47 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from smtp01.wxs.nl (smtp01.wxs.nl [195.121.6.61]) by hub.freebsd.org (Postfix) with ESMTP id 11F2314E2E for ; Sun, 24 Oct 1999 06:25:32 -0700 (PDT) (envelope-from bottemanne@capitolonline.nl) Received: from capitolonline.nl ([195.121.169.45]) by smtp01.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA22A7; Sun, 24 Oct 1999 15:25:23 +0200 Message-ID: <3813170B.5A22F06F@capitolonline.nl> Date: Sun, 24 Oct 1999 15:26:19 +0100 From: Aernoudt Bottemanne X-Mailer: Mozilla 4.04 [en] (OS/2; I) MIME-Version: 1.0 To: "freebsd-alpha@freebsd.org" , Andrew Gallatin , marcel@scc.nl Subject: buildworld problem + received processor correctable error message on PWS433au Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Now that the irq problwm is fixed, I tried to build a new world: (make -j 32 buildworld > make.out 2>&1 ) It starts the job, but somewhere along the way it stops. The machine does not hang, I can login on other consoles etc, but the make process does not continue. During compilation I get these messages: "received processor correctable errors" From the mailinglist archives I found that Andrew already mentioned them before, as a Hardware problem with ECC memory (eg ECC memory being cnot in a well shape) In the make.out however there is no error message on th last line, in order to indicate what the problem could be. In order to make provide some information that could be helpful to solve this problem, I have included the kernel configuration, aswell as the dmesg output: KERNEL configuration: ******************************************************************** machine alpha cpu EV5 ident PRINCESS maxusers 32 # Platforms supported options DEC_ST550 # Personal Workstation 433, 500, 600 options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=10000 #Be pessimistic about Joe SCSI device options SOFTUPDATES options UCONSOLE #Allow users to grab the console options KTRACE #ktrace(1) syscall trace support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores # Standard busses controller isa0 controller pci0 # Floppy drives controller fdc0 at isa? port IO_FD1 irq 6 drq 2 disk fd0 at fdc0 drive 0 # SCSI Controllers controller isp0 # Qlogic family controller scbus0 # SCSI bus (required) device da0 # Direct Access (disks) device cd0 # CD device pass0 # Passthrough device (direct SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0 at atkbdc? 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? # real time clock device mcclock0 at isa0 port 0x70 # Serial (COM) ports device sio0 at isa0 port IO_COM1 irq 4 device sio1 at isa0 port IO_COM2 irq 3 flags 0x50 # PCI Ethernet NICs. device de0 # DEC/Intel DC21x4x (``Tulip'') # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support pseudo-device pty # Pseudo-ttys (telnet etc) # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf #Berkeley packet filter ******************************************************************************** DMESG Output: ******************************************************************************** Unrecognized boot flag '0'. 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 #1: Tue May 18 14:49:21 CEST 1999 root@princess.capitolonline.nl:/usr/src/sys/compile/PRINCESS Digital Personal Workstation (Miata) Digital Personal WorkStation 433au, 432MHz 8192 byte page size, 1 processor. CPU: EV56 (21164A) major=7 minor=0 extensions=0x1 OSF PAL rev: 0x1000000020116 real memory = 132177920 (129080K bytes) avail memory = 123650048 (120752K bytes) => Preloaded elf kernel "kernel" at 0xfffffc00005ec000. => cia0: Pyxis, pass 1 => cia0: extended capabilities: 1 => cia0: WARNING: Pyxis pass 1 DMA bug; no bets... pcib0: <2117x PCI host bus adapter> on cia0 pci0: on pcib0 de0: irq 0 at device 3.0 on pci0 de0: interrupting at CIA irq 0 de0: DEC 21142 [10-100Mb/s] pass 1.1 de0: address 00:00:f8:75:48:c1 de0: enabling 10baseT port chip0: irq 1 at device 4.0 on pci0 isab0: at device 7.0 on pci0 isa0: on isab0 pcib1: at device 8.0 on pci0 pci1: on pcib1 isp0: irq 20 at device 10.0 on pci1 isp0: interrupting at CIA irq 20 isp0: Ultra Mode Capable vga-pci0: irq 8 at device 12.0 on pci0 mcclock0: at port 0x70-0x71 on isa0 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio0: interrupting at ISA irq 4 sio1: reserved for low-level i/o fdc0: interrupting at ISA irq 6 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 atkbd0: interrupting at ISA irq 1 psm0: irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 psm0: interrupting at ISA irq 12 vga0: at port 0x3b0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> => struct nfssvc_sock bloated (> 256bytes) => Try reducing NFS_UIDHASHSIZ => struct nfsuid bloated (> 128bytes) => Try unionizing the nu_nickname and nu_flag fields Timecounter "alpha" frequency 433214142 Hz Waiting 10 seconds for SCSI devices to settle isp0: driver initiated bus reset of bus 0 Creating DISK da0 Creating DISK da1 Creating DISK da2 Creating DISK cd0 da0 at isp0 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: 4095MB (8388314 512 byte sectors: 255H 63S/T 522C) da1 at isp0 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: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) cd0 at isp0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 3.300MB/s transfers cd0: cd present [326562 x 2048 byte records] da2 at isp0 bus 0 target 4 lun 0 da2: Removable Direct Access SCSI-2 device da2: 3.300MB/s transfers da2: 96MB (196608 512 byte sectors: 64H 32S/T 96C) ************************************************************************ The => indications are put in by me, they are not part of the output ! These remarks I put in since they wondered me. Cheers, Aernoudt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sun Oct 24 6:25:50 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from smtp04.wxs.nl (smtp04.wxs.nl [195.121.6.59]) by hub.freebsd.org (Postfix) with ESMTP id E4FAE14F5D; Sun, 24 Oct 1999 06:25:36 -0700 (PDT) (envelope-from bottemanne@capitolonline.nl) Received: from capitolonline.nl ([195.121.169.45]) by smtp04.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA6922; Sun, 24 Oct 1999 15:25:14 +0200 Message-ID: <3813145D.72C0EF6A@capitolonline.nl> Date: Sun, 24 Oct 1999 15:14:53 +0100 From: Aernoudt Bottemanne X-Mailer: Mozilla 4.04 [en] (OS/2; I) MIME-Version: 1.0 To: Andrew Gallatin Cc: dfr@nlsystems.com, alpha@freebsd.org, "freebsd-alpha@freebsd.org" Subject: Re: small fix for irq mappig probelm References: <14354.8792.767477.900314@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This fix works for my PWS 433au (miata) ! Just to let you know. Andrew Gallatin wrote: > Doug, > > When using a kernel built after your recent changes to pci.c, alpha > PCI devices with intline==0 fail to map their interrupt. This > typically happens with the on-board tulip in a miata: > > de0: irq 0 at device 3.0 on pci0 > pci_map_int: can't allocate interrupt > > The appended patch fixes it, but I am unsure it is correct. Can you > approve it? > > Thanks, > > Drew > ------------------------------------------------------------------------------ > Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin > Duke University Email: gallatin@cs.duke.edu > Department of Computer Science Phone: (919) 660-6590 > > Index: sys/pci/pci.c > =================================================================== > RCS file: /home/ncvs/src/sys/pci/pci.c,v > retrieving revision 1.123 > diff -u -r1.123 pci.c > --- pci.c 1999/10/17 06:48:47 1.123 > +++ pci.c 1999/10/23 20:56:52 > @@ -1045,7 +1045,7 @@ > (unsigned int) base, ln2size); > } > } > - if (cfg->intline) > + if (cfg->intpin) > resource_list_add(rl, SYS_RES_IRQ, 0, > cfg->intline, cfg->intline, 1); > } > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sun Oct 24 12:47:10 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 3CD7714BD7 for ; Sun, 24 Oct 1999 12:47:06 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id PAA01697; Sun, 24 Oct 1999 15:47:05 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id PAA13411; Sun, 24 Oct 1999 15:46:35 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 24 Oct 1999 15:46:35 -0400 (EDT) To: Aernoudt Bottemanne Cc: "freebsd-alpha@freebsd.org" , marcel@scc.nl Subject: Re: buildworld problem + received processor correctable error message on PWS433au In-Reply-To: <3813170B.5A22F06F@capitolonline.nl> References: <3813170B.5A22F06F@capitolonline.nl> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14355.24089.447439.7651@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Aernoudt Bottemanne writes: > Hi, > > > Now that the irq problwm is fixed, I tried to build a new world: > (make -j 32 buildworld > make.out 2>&1 ) > > It starts the job, but somewhere along the way it stops. The machine > does > not hang, I can login on other consoles etc, but the make process does > not > continue. During compilation I get these messages: > "received processor correctable errors" From the mailinglist archives I > found > that Andrew already mentioned them before, as a Hardware problem with > ECC memory (eg ECC memory being cnot in a well shape) This is probably a red herring. > In the make.out however there is no error message on th last line, in > order to > indicate what the problem could be. Did the make/cc/cpp callchain die? Is it a zombie? If it is not dead, what state is it in? Are there any jobs with a WCHAN of obtrm? (to see use ps axl or break into the debugger & do a ps if ps doesn't work because of a kernel/userland mismatch). Try running your buildworld with 'make buildworld' & avoid using any -j args. Something in the vm system is not using the atomic macros to change object state & there is a chance that under extreme load, jobs will hang in objtrm. BTW, the things you've highlighted in your dmesg (the nfs stuff) is also a red herring. => cia0: Pyxis, pass 1 => cia0: extended capabilities: 1 => cia0: WARNING: Pyxis pass 1 DMA bug; no bets... Read this as "Don't use this machine as a high volume server". ;-) The first generation pyxis (the chipset in your machine) has several problems. Formost is that PCI DMA reads that cross a page boundary don't work right. This is not a problem for the 32 bit slots because PCI-PCI bridge breaks transfers and prevents this from occuring. The firmware prevents you from putting "unknown" cards in the 64-bit slots. You can override this by doing 'set pci_device_override ' at the srm console prompt. Its other problems include piss-poor DMA performance for DMA reads and a tendancy to lock solid when the PCI bus is pushed hard. Although they sound bad, none of these things should affect its use as a personal workstation. In fact, I wish I had one at home ;-) => struct nfssvc_sock bloated (> 256bytes) => Try reducing NFS_UIDHASHSIZ => struct nfsuid bloated (> 128bytes) => Try unionizing the nu_nickname and nu_flag fields This is a red herring. ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sun Oct 24 22:21:11 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from mail.cybcon.com (mail.cybcon.com [216.190.188.5]) by hub.freebsd.org (Postfix) with ESMTP id 5E8A8151AD for ; Sun, 24 Oct 1999 22:21:05 -0700 (PDT) (envelope-from wwoods@cybcon.com) Received: from freebsd.cybcon.com (william@usr1-11.cybcon.com [205.147.75.12]) by mail.cybcon.com (8.9.0/8.9.0) with SMTP id WAA04556 for ; Sun, 24 Oct 1999 22:21:03 -0700 (PDT) From: william woods Reply-To: wwoods@cybcon.com To: freebsd-alpha@freebsd.org Subject: Alpha snapshots.... Date: Sun, 24 Oct 1999 22:20:22 -0700 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <99102422211601.00301@freebsd.cybcon.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org How often are snapshots of Alpha current put up on current.freebsd.org ? -- William Woods FreeBSD 3.3-Stable To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sun Oct 24 23:28:24 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id B86E2151D2 for ; Sun, 24 Oct 1999 23:28:07 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from localhost (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id XAA42708; Sun, 24 Oct 1999 23:27:57 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: wwoods@cybcon.com Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: Alpha snapshots.... In-reply-to: Your message of "Sun, 24 Oct 1999 22:20:22 PDT." <99102422211601.00301@freebsd.cybcon.com> Date: Sun, 24 Oct 1999 23:27:57 -0700 Message-ID: <42689.940832877@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > How often are snapshots of Alpha current put up on current.freebsd.org ? Sort of whenever I remember to make one and/or the tree builds on the alpha. Anyone out there willing to create an alpha snap server that current.freebsd.org can mirror? - Jordan > > -- > > William Woods > FreeBSD 3.3-Stable > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Oct 25 0:31:20 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from smtp02.wxs.nl (smtp02.wxs.nl [195.121.6.60]) by hub.freebsd.org (Postfix) with ESMTP id 1C9CC1507F for ; Mon, 25 Oct 1999 00:31:10 -0700 (PDT) (envelope-from bottemanne@capitolonline.nl) Received: from capitolonline.nl ([195.121.169.36]) by smtp02.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA1563; Mon, 25 Oct 1999 09:31:07 +0200 Message-ID: <381415A6.6E898CF7@capitolonline.nl> Date: Mon, 25 Oct 1999 09:32:39 +0100 From: Aernoudt Bottemanne X-Mailer: Mozilla 4.04 [en] (OS/2; I) MIME-Version: 1.0 To: Andrew Gallatin Cc: "freebsd-alpha@freebsd.org" , marcel@scc.nl Subject: Re: buildworld problem + received processor correctable error message on PWS433au References: <3813170B.5A22F06F@capitolonline.nl> <14355.24089.447439.7651@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Red herrings ... I wonder how they taste : - ) I suppose this means I should not worry to much about them. Yesterday evening (or early this morning...) I compiled again. This time it a little further, but it stopped. However this time it stopped with an error message, which is underneath. Hopefully that helps. I used this command: " make buildworld > make.out 2>&1 " The error messages are form the make.out. Thsis time the make.out is 5,8MB, last time it was 1,2MB so it was a petty to have it crash... It took about 3 hours, and I was under the impression that this time it finally worked : - ( The machine was idle after this, PS does not work, I tried to recompile but that didnot work either.... Anyway, here is the output: ****************************************************************** AutoSplitting lib/Getopt/Long.pm (lib/auto/Getopt/Long) touch autosplit sh cflags.sh Extracting cflags (with variable substitutions) cd ext/DynaLoader; miniperl -I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib Makefile.PL LINKTYPE=static INSTALLDIRS=perl PERL_SRC=/usr/obj/usr/src/gnu/usr.bin/perl/perl LIBS="-lperl" INSTALLMAN3DIR=/usr/obj/usr/src/tmp/usr/share/perl/man3; make -B config PERL_SRC=/usr/obj/usr/src/gnu/usr.bin/perl/perl Writing Makefile for DynaLoader Warning: /usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/Config.pm may be out of date with /usr/obj/usr/src/gnu/usr.bin/perl/perl/config.sh cd /usr/obj/usr/src/gnu/usr.bin/perl/perl && make lib/Config.pm `lib/Config.pm' is up to date. Warning: /usr/obj/usr/src/gnu/usr.bin/perl/perl/config.h out of date with /usr/obj/usr/src/gnu/usr.bin/perl/perl/config.sh Makefile out-of-date with respect to /usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/Config.pm /usr/obj/usr/src/gnu/usr.bin/perl/perl/config.h Cleaning current config before rebuilding Makefile... *** Error code 1 (ignored) make -f Makefile.old clean > /dev/null 2>&1 || /bin/sh -c true /usr/obj/usr/src/tmp/usr/bin/miniperl "-I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib" "-I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib" Makefile.PL "LINKTYPE=static" "INSTALLDIRS=perl" "PERL_SRC=/usr/obj/usr/src/gnu/usr.bin/perl/perl" "LIBS=-lperl" "INSTALLMAN3DIR=/usr/obj/usr/src/tmp/usr/share/perl/man3" Writing Makefile for DynaLoader ==> Your Makefile has been rebuilt. <== ==> Please rerun the make command. <== false false:No such file or directory *** Error code 1 Stop in /ftp/obj/usr/src/gnu/usr.bin/perl/perl/ext/DynaLoader. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/perl. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. ****************************************************************** Kind regards, Aernoudt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Oct 25 1:54:33 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id 230CF150E0 for ; Mon, 25 Oct 1999 01:54:26 -0700 (PDT) (envelope-from freebsd-alpha@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id KAA22612 for alpha@FreeBSD.org; Mon, 25 Oct 1999 10:38:47 +0200 (CEST) (envelope-from freebsd-alpha@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for alpha@FreeBSD.org (alpha@FreeBSD.org) To: alpha@FreeBSD.org Date: Mon, 25 Oct 1999 10:38:38 +0200 From: Marcel Moolenaar Message-ID: <3814170E.ADEBBEBF@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Alpha libs in compat3x Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, With the sigset_t change and the bumping of the version numbers of libc and friends, shouldn't we have Alpha libraries in compat3x? We can do it like: .for lib in ${LIBS} ${lib}: ${lib}.${MACHINE_ARCH}.gz.uu uudecode -p ${.CURDIR}/${lib}.${MACHINE_ARCH}.gz.uu | gunzip > ${lib} .endfor I have a commit ready for compat3x which add the libraries touched by the sigset_t change. I can add Alpha libraries while I'm there and we all agree on it and someone can give me the following -stable/alpha libraries (I only have -current/alpha): libc.so.3 libc_r.so.3 libdialog.so.3 libedit.so.2 libf2c.so.2 libftpio.so.4 libg++.so.4 libhistory.so.3 libreadline.so.3 libss.so.2 libstdc++.so.2 Comments? -- 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-alpha" in the body of the message From owner-freebsd-alpha Mon Oct 25 2:15:36 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id CAAA915098 for ; Mon, 25 Oct 1999 02:15:34 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id CAA59156; Mon, 25 Oct 1999 02:15:30 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id CAA87386; Mon, 25 Oct 1999 02:15:29 -0700 (PDT) (envelope-from obrien) Date: Mon, 25 Oct 1999 02:15:29 -0700 From: "David O'Brien" To: Marcel Moolenaar Cc: alpha@FreeBSD.org Subject: Re: Alpha libs in compat3x Message-ID: <19991025021529.A58951@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <3814170E.ADEBBEBF@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i In-Reply-To: <3814170E.ADEBBEBF@scc.nl> X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > We can do it like: > > .for lib in ${LIBS} > ${lib}: ${lib}.${MACHINE_ARCH}.gz.uu > uudecode -p ${.CURDIR}/${lib}.${MACHINE_ARCH}.gz.uu | gunzip > > ${lib} > .endfor I'd rather see src/lib/compat/{i386,alpha}/compat3x/ -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Oct 25 2:18:39 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 06CB015098 for ; Mon, 25 Oct 1999 02:18:37 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id CAA59169; Mon, 25 Oct 1999 02:18:37 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id CAA87414; Mon, 25 Oct 1999 02:18:37 -0700 (PDT) (envelope-from obrien) Date: Mon, 25 Oct 1999 02:18:37 -0700 From: "David O'Brien" To: Marcel Moolenaar Cc: alpha@freebsd.org Subject: Re: Alpha libs in compat3x Message-ID: <19991025021837.B58951@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <3814170E.ADEBBEBF@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i In-Reply-To: <3814170E.ADEBBEBF@scc.nl> X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I have a commit ready for compat3x which add the libraries touched by ... > Comments? I've been thinking about compat3x issues for a while, and I'm not sure we shouldn't hold off on committing more compat3x libs until just before 4.0 release. The problem is we are still change things in the 3x libs (such as adding new functions), and don't bump the version number. The problem is committing an update to an uuencoded library bloats the ,v files tremdiously since every line of the uuencoded library file is different from the previous one. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Oct 25 2:55: 7 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id A872315111 for ; Mon, 25 Oct 1999 02:55:03 -0700 (PDT) (envelope-from marcel@scc.nl) Received: from [212.238.132.94] (helo=scones.sup.scc.nl) by post.mail.nl.demon.net with esmtp (Exim 2.02 #1) id 11fgqE-0003EB-00; Mon, 25 Oct 1999 09:55:02 +0000 Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id LAA57555; Mon, 25 Oct 1999 11:54:43 +0200 (CEST) (envelope-from marcel@scc.nl) Message-ID: <381428E2.6502053@scc.nl> Date: Mon, 25 Oct 1999 11:54:42 +0200 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: obrien@nuxi.com Cc: alpha@freebsd.org Subject: Re: Alpha libs in compat3x References: <3814170E.ADEBBEBF@scc.nl> <19991025021837.B58951@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David O'Brien wrote: > > > I have a commit ready for compat3x which add the libraries touched by > ... > > Comments? > > I've been thinking about compat3x issues for a while, and I'm not sure we > shouldn't hold off on committing more compat3x libs until just before 4.0 > release. The problem is we are still change things in the 3x libs (such > as adding new functions), and don't bump the version number. Fine with me. -- 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-alpha" in the body of the message From owner-freebsd-alpha Mon Oct 25 4:55:14 1999 Delivered-To: freebsd-alpha@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 2B68D150A1 for ; Mon, 25 Oct 1999 04:55:10 -0700 (PDT) (envelope-from marcel@scc.nl) Received: from [212.238.132.94] (helo=scones.sup.scc.nl) by post.mail.nl.demon.net with esmtp (Exim 2.12 #1) id 11fijJ-000Nrb-00; Mon, 25 Oct 1999 11:56:01 +0000 Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id NAA10815; Mon, 25 Oct 1999 13:55:03 +0200 (CEST) (envelope-from marcel@scc.nl) Message-ID: <38144517.E758CBDA@scc.nl> Date: Mon, 25 Oct 1999 13:55:03 +0200 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: obrien@nuxi.com Cc: alpha@FreeBSD.org Subject: Re: Alpha libs in compat3x References: <3814170E.ADEBBEBF@scc.nl> <19991025021529.A58951@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David O'Brien wrote: > > > We can do it like: > > > > .for lib in ${LIBS} > > ${lib}: ${lib}.${MACHINE_ARCH}.gz.uu > > uudecode -p ${.CURDIR}/${lib}.${MACHINE_ARCH}.gz.uu | gunzip > > > ${lib} > > .endfor > > I'd rather see src/lib/compat/{i386,alpha}/compat3x/ In that case, use ``src/lib/compat.{i386,alpha}/compat3x'', because bsd.subdir.mk already knows about such a scheme. -- 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-alpha" in the body of the message From owner-freebsd-alpha Mon Oct 25 6:58:51 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 277AC14CA1 for ; Mon, 25 Oct 1999 06:58:43 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id JAA18721; Mon, 25 Oct 1999 09:58:38 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id JAA14943; Mon, 25 Oct 1999 09:57:08 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 25 Oct 1999 09:57:08 -0400 (EDT) To: "Jordan K. Hubbard" Cc: wwoods@cybcon.com, freebsd-alpha@FreeBSD.ORG Subject: Re: Alpha snapshots.... In-Reply-To: <42689.940832877@localhost> References: <99102422211601.00301@freebsd.cybcon.com> <42689.940832877@localhost> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14356.23355.259482.310764@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jordan K. Hubbard writes: > > How often are snapshots of Alpha current put up on current.freebsd.org ? > > Sort of whenever I remember to make one and/or the tree builds on the > alpha. Anyone out there willing to create an alpha snap server that > current.freebsd.org can mirror? I've been trying to get a make release to finish. The night before last, it failed because jade is marked as broken on alpha: .if ${MACHINE_ARCH} == "alpha" BROKEN= nsgmls coredumps in static constructors .endif I commented out the broken line in my local cvs repo just to see what happened. I don't know didly about jade, but I do know that the handbook it built last night seems to look just fine. Also, we need to slim the GENERIC kernel down somewhat in order to get it to fit on a floppy: linking BOOTMFS text data bss dec hex filename 2423093 202244 134936 2760273 2a1e51 BOOTMFS mv /R/stage/kernels/BOOTMFS /R/stage/image.kern/kernel Setting up /boot directory for kern floppy /R/stage/image.kern/kernel: 65.6% -- replaced with /R/stage/image.kern/kern el.gz sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt 1440 /R/stage/image.kern 80000 fd1440 Warning: Block size restricts cylinders per group to 6. Warning: 1216 sector(s) in last cylinder unallocated /dev/rvn0c: 2880 sectors in 1 cylinders of 1 tracks, 4096 sectors 1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 32 i/g) super-block backups (for fsck -b #) at: 32 cpio: write error: No space left on device *** Error code 1 Stop in /usr/src/release. *** Error code 1 I've already tried removing the Turbochannel machines from the install floppy, but that doesn't seem to be enough. The top 10 remaining files are: text data bss dec hex filename 31984 720 8 32712 7fc8 if_xl.o 35368 1680 128 37176 9138 cam_xpt.o 20295 0 20912 41207 a0f7 vm_map.o 32184 9592 160 41936 a3d0 ncr.o 44392 96 264 44752 aed0 if_de.o 48240 168 32 48440 bd38 isp.o 35368 472 14728 50568 c588 syscons.o 10792 0 41424 52216 cbf8 vm_object.o 71032 5408 10 76450 12aa2 aic7xxx.o 110240 1440 16 111696 1b450 nfs_vnops.o 189464 456 40 189960 2e608 isp_pci.o Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Oct 25 8:56:35 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 1947114BCD for ; Mon, 25 Oct 1999 08:56:33 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id IAA60225; Mon, 25 Oct 1999 08:56:10 -0700 (PDT) (envelope-from obrien) Date: Mon, 25 Oct 1999 08:56:10 -0700 From: "David O'Brien" To: Marcel Moolenaar Cc: alpha@FreeBSD.org Subject: Re: Alpha libs in compat3x Message-ID: <19991025085610.A1565@relay.nuxi.com> Reply-To: obrien@NUXI.com References: <3814170E.ADEBBEBF@scc.nl> <19991025021529.A58951@dragon.nuxi.com> <38144517.E758CBDA@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i In-Reply-To: <38144517.E758CBDA@scc.nl> X-Operating-System: FreeBSD 3.3-STABLE Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > uudecode -p ${.CURDIR}/${lib}.${MACHINE_ARCH}.gz.uu | gunzip > .... > > I'd rather see src/lib/compat/{i386,alpha}/compat3x/ > > In that case, use ``src/lib/compat.{i386,alpha}/compat3x'', because > bsd.subdir.mk already knows about such a scheme. Difficult as it would mean a repository copy of tagged files would be needed. Thus we would double the size of src/lib/compat/ as the compat1* and compat2* stuff isn't easily moveable. compat3x has no tags, so we can repository copy it elsewhere and totally remove the current stuff away (ie, `rm', not putting it in the Attic). -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Oct 25 16:59:59 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id EDBD814BF8 for ; Mon, 25 Oct 1999 16:59:57 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA15677; Mon, 25 Oct 1999 16:59:57 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd015628; Mon Oct 25 16:59:49 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id QAA16866; Mon, 25 Oct 1999 16:59:46 -0700 (MST) From: Terry Lambert Message-Id: <199910252359.QAA16866@usr06.primenet.com> Subject: Re: small fix for irq mappig probelm To: gallatin@cs.duke.edu (Andrew Gallatin) Date: Mon, 25 Oct 1999 23:59:44 +0000 (GMT) Cc: dfr@nlsystems.com, alpha@FreeBSD.ORG In-Reply-To: <14354.8792.767477.900314@grasshopper.cs.duke.edu> from "Andrew Gallatin" at Oct 23, 99 05:07:35 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-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Doug, > > When using a kernel built after your recent changes to pci.c, alpha > PCI devices with intline==0 fail to map their interrupt. This > typically happens with the on-board tulip in a miata: > > de0: irq 0 at device 3.0 on pci0 > pci_map_int: can't allocate interrupt > > > The appended patch fixes it, but I am unsure it is correct. Can you > approve it? Same thing on some Intel motherboards, FWIW. SMP seems to be the way to fix it; perhaps we could do whatever the equivalent is on Alpha? http://support.intel.com/support/motherboards/desktop/pr440fx/irqs.htm http://support.intel.com/support/motherboards/desktop/dk440lx/irqs.htm 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-alpha" in the body of the message From owner-freebsd-alpha Mon Oct 25 17:51:31 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 01FE014DDA for ; Mon, 25 Oct 1999 17:51:28 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from storm.cs.duke.edu (storm.cs.duke.edu [152.3.140.12]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id UAA06386; Mon, 25 Oct 1999 20:51:21 -0400 (EDT) Received: (gallatin@localhost) by storm.cs.duke.edu (8.8.4/8.6.9) id UAA09280; Mon, 25 Oct 1999 20:51:21 -0400 (EDT) Date: Mon, 25 Oct 1999 20:51:21 -0400 (EDT) Message-Id: <199910260051.UAA09280@storm.cs.duke.edu> From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: dfr@nlsystems.com, alpha@FreeBSD.ORG Subject: Re: small fix for irq mappig probelm In-Reply-To: <199910252359.QAA16866@usr06.primenet.com> References: <14354.8792.767477.900314@grasshopper.cs.duke.edu> <199910252359.QAA16866@usr06.primenet.com> X-Mailer: VM 6.32 under 19.15 XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry Lambert writes: > > > > de0: irq 0 at device 3.0 on pci0 > > pci_map_int: can't allocate interrupt > > > > > > The appended patch fixes it, but I am unsure it is correct. Can you > > approve it? > > Same thing on some Intel motherboards, FWIW. SMP seems to be the > way to fix it; perhaps we could do whatever the equivalent is on > Alpha? Huh? I'm not talking about running out of irqs, I'm talking about having a valid inline which happens to be zero. (Most) Alphas aren't limited to 16 irqs like PCs, even without SMP support. Many support up to 64 irqs. Starting at 0 & including 0. Having 0 as a valid intline is the problem. My patch assumes that an intpin should never be 0. Is this true? Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Oct 25 19:18:34 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id C82F314C04 for ; Mon, 25 Oct 1999 19:18:29 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id TAA17636; Mon, 25 Oct 1999 19:18:17 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpdAAArMaiBI; Mon Oct 25 19:18:10 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA25849; Mon, 25 Oct 1999 19:18:19 -0700 (MST) From: Terry Lambert Message-Id: <199910260218.TAA25849@usr06.primenet.com> Subject: Re: small fix for irq mappig probelm To: gallatin@cs.duke.edu (Andrew Gallatin) Date: Tue, 26 Oct 1999 02:18:19 +0000 (GMT) Cc: tlambert@primenet.com, dfr@nlsystems.com, alpha@FreeBSD.ORG In-Reply-To: <199910260051.UAA09280@storm.cs.duke.edu> from "Andrew Gallatin" at Oct 25, 99 08:51:21 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-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > > > de0: irq 0 at device 3.0 on pci0 > > > pci_map_int: can't allocate interrupt > > > > > > > > > The appended patch fixes it, but I am unsure it is correct. Can you > > > approve it? > > > > Same thing on some Intel motherboards, FWIW. SMP seems to be the > > way to fix it; perhaps we could do whatever the equivalent is on > > Alpha? > > Huh? I'm not talking about running out of irqs, I'm talking about > having a valid inline which happens to be zero. My point was more toward virtualizing the interrupts via an APIC would be an acceptable workaround, if the system had APIC's. I bet Alphas don't, but they have to have some type of MP coherency and "virtual wire" model that might be there in all Alphas, that could do in a pinch. > (Most) Alphas aren't limited to 16 irqs like PCs, even without SMP > support. Many support up to 64 irqs. Starting at 0 & including 0. > > Having 0 as a valid intline is the problem. My patch assumes that an > intpin should never be 0. Is this true? Julian Elisher would be a good person to ask about this on the PC hadware side of things, since he dealt with all of the Cyrix Media GX chipset problems for Whistle just recently. ...OK, I'm back from asking him. 8-). The answer is that zero isn't allowed under any circumstances, and that you are probably missing a mapping somewhere in the PCI chipset configuration. According to: PCI System Architecture Tom Shanley, Don Anserson MindShare, Inc. ISBN: 0-201-40993-3 Chapter 17: Configuration Registers ... Interrupt Pin Register The read-only interrupt pin register defines which of the four PCI interrupt request pins, INTA# through INTD#, a PCI functional device is connected to. The values one through four correspond to PCI interrupt request lines INTA# through INTD#. A return value of zero indicates that the device doesn't use interrupts. For additional information, refer to the chapter entitled "Interrupt- Related Issues". ... Julian says: The BIOS is supposed to twiddle with the registers on the board, and some number is supposed to show up there. Then after the number shows up there, the BIOS is supposed to read that number back from the IPR, then using its own internal knowledge of the traces on the motherboard, map that number into an ICU interrupt number. It then is supposed to write than number into the Interrupt Line Register. Then the OS is supposed to be able to independantly read the ILR, and get the right interrupt for the CPU to associate with the driver (the ILR is not attached to any hardware, its sole purpose is to act as an IPC mechanism between the BIOS and the OS). So, it looks like your BIOS is not setting things up right; Julian also says: The BIOS on the motherboard is responsible for the mapping IPR->ILR mapping, and the BIOS code stored on the card is responsible for twiddling the bits in a device dependent fashion in order to make the value turn up in the IPR. The BIOS on the motherboard is responsible for the BIOS code on the card, which of INTA# through INTD# are avaiable on that slot, and then the card gets to grab one (or more) to play with. On a lot of motherboards, all the Interrupt pin lines, INTA# thorugh INTD#, are all wired together on most motherboards, so you only have 4 lines coming from the PCI to the interrupt controller. This makes the mapping discussed above rather simple, which is why the PCI BIOS' give you an option to hook PCI interrupts lines to some specific interrupt. But since not all motherboards are wired this way, particularly some of the high performance ones that seperate the interrupts so that they are not shared (think SMP), the mapping process is necessary for full PCI compliance. Well, pretty clearly, the BIOS on the card is not being run; big surprise, since it's x86 code, and your processor is an Alpha. 8-(. I think you will need to deal with the card specific setup directly, as if you were the BIOS on the card. Generally, the IPR is not writeable, but there is some other register on the card, which, when written, lets you change the value visible in the IPR. Well, we all knew that there would be some BIOS arrows to take in the back over the non-x86 platforms. It might be useful to look at what NetBSD does to deal with the PCI issues over on their side of the fence; they've had to deal with this on both their Alpha and PowerPC ports, so they probably have a generic way of doing things. I believe that the DEC approach was to run the x86 code in an emulator in the firmware; this was also the approach taken on the Motorolla PowerStack (PowerPC) systems. Some of the later DEC systems "knew" what hardware was "allowed" to be installed; these are generally the ones that twiddle the hardware directly through promiscuous knowledge of the hardware, and they can (usually) be identified by whether the SRM is small enough to fit in the same firmware as the "AlphaBIOS" of "ARC" code. It may be that your firmware is broken or the wrong version, or just doesn't have this code... you might want to look at what is supposed to be happening here, according to CGD's documents for Alpha that he collected during the NetBSD port. Anyway, hope that gives you enough from the PC side of the fence that you can get this problem solved the right way. 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-alpha" in the body of the message From owner-freebsd-alpha Tue Oct 26 0:39:34 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 41EB314C48 for ; Tue, 26 Oct 1999 00:39:28 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id IAA29992; Tue, 26 Oct 1999 08:39:20 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 26 Oct 1999 08:39:20 +0100 (BST) From: Doug Rabson To: Andrew Gallatin Cc: alpha@freebsd.org Subject: Re: small fix for irq mappig probelm In-Reply-To: <14354.8792.767477.900314@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 23 Oct 1999, Andrew Gallatin wrote: > > Doug, > > When using a kernel built after your recent changes to pci.c, alpha > PCI devices with intline==0 fail to map their interrupt. This > typically happens with the on-board tulip in a miata: > > de0: irq 0 at device 3.0 on pci0 > pci_map_int: can't allocate interrupt > > > The appended patch fixes it, but I am unsure it is correct. Can you > approve it? > > Thanks, I think the correct fix is to compare against 255. I will commit the following patch: Index: pci.c =================================================================== RCS file: /home/ncvs/src/sys/pci/pci.c,v retrieving revision 1.123 diff -u -r1.123 pci.c --- pci.c 1999/10/17 06:48:47 1.123 +++ pci.c 1999/10/26 07:36:14 @@ -1045,7 +1045,7 @@ (unsigned int) base, ln2size); } } - if (cfg->intline) + if (cfg->intline != 255) resource_list_add(rl, SYS_RES_IRQ, 0, cfg->intline, cfg->intline, 1); } -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Oct 26 0:43:47 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 47AF914C1A for ; Tue, 26 Oct 1999 00:43:43 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id IAA33591; Tue, 26 Oct 1999 08:43:24 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 26 Oct 1999 08:43:24 +0100 (BST) From: Doug Rabson To: Andrew Gallatin Cc: Terry Lambert , alpha@FreeBSD.ORG Subject: Re: small fix for irq mappig probelm In-Reply-To: <199910260051.UAA09280@storm.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 25 Oct 1999, Andrew Gallatin wrote: > > Terry Lambert writes: > > > > > > de0: irq 0 at device 3.0 on pci0 > > > pci_map_int: can't allocate interrupt > > > > > > > > > The appended patch fixes it, but I am unsure it is correct. Can you > > > approve it? > > > > Same thing on some Intel motherboards, FWIW. SMP seems to be the > > way to fix it; perhaps we could do whatever the equivalent is on > > Alpha? > > Huh? I'm not talking about running out of irqs, I'm talking about > having a valid inline which happens to be zero. > > (Most) Alphas aren't limited to 16 irqs like PCs, even without SMP > support. Many support up to 64 irqs. Starting at 0 & including 0. > > Having 0 as a valid intline is the problem. My patch assumes that an > intpin should never be 0. Is this true? The 'invalid' value for intline is 255 according to the spec. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Oct 26 2: 7:42 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id D3B3614E90 for ; Tue, 26 Oct 1999 02:07:25 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id KAA01660; Tue, 26 Oct 1999 10:07:09 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 26 Oct 1999 10:07:09 +0100 (BST) From: Doug Rabson To: Matthew Jacob Cc: Andrew Gallatin , alpha@freebsd.org Subject: Re: builds: another odd one... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 21 Oct 1999, Matthew Jacob wrote: > > Well, I installed vgrind by hand and restarted. We'll see.... Build and install libc and csh. There was a window where libc had a bogus implementation of sigpending(). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Oct 26 2: 9:34 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 4D7F514A13 for ; Tue, 26 Oct 1999 02:09:29 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id KAA01918; Tue, 26 Oct 1999 10:09:27 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 26 Oct 1999 10:09:27 +0100 (BST) From: Doug Rabson To: Aernoudt Bottemanne Cc: "freebsd-alpha@freebsd.org" Subject: Re: boot errors after upgrading to current: cvsupped yesterday In-Reply-To: <38123302.D8A39378@capitolonline.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 23 Oct 1999, Aernoudt Bottemanne wrote: > Hi, > > > After upgrading my PWS 433au to current yesterday, the deo adapter does > not > get an interrupt. Also some other messages: I just committed a fix for this. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Oct 26 3:57:42 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 70DD514EE3 for ; Tue, 26 Oct 1999 03:57:36 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40358>; Tue, 26 Oct 1999 20:52:37 +1000 Content-return: prohibited Date: Tue, 26 Oct 1999 20:57:26 +1000 From: Peter Jeremy Subject: Multia booting woes To: freebsd-alpha@FreeBSD.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Oct26.205237est.40358@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I thought this was all going to be easy when I decided to buy a Multia... Latest try: I've dd'd releases/3.2-RELEASE/floppies/boot.flp from 3.2-RELEASE CD-ROM 2 onto a SCSI disk, stuck the disk into the Multia and it still dies (log below). I presume the `Unit Attention' messages are being triggered by SCSI bus resets during the boot, rather than a disk problem. Any suggestions? (`%' in the following refers to the twirling bar). Testing Memory from 8 to 64 meg... Executing power-up script... Testing TGA version BL5 V3.8-3 Aug 10 1995 03:22:55 dka0.0.0.6.0 DKA0 SEAGATE ST32151N 9470 ewa0.0.0.8.0 EWA0 08-00-2B-E4-41-77 pka0.7.0.6.0 PKA0 SCSI Bus ID 7 64 Meg of system memory CPU speed is 166 MHZ Cache size is 256 Kbytes *** keyboard not plugged in... Keyboard error; using serial port terminal Switching network ewa0.0.0.8.0 from AUI to Thin Wire... Switching network ewa0.0.0.8.0 from Thin Wire to Twisted Pair... >>>boot dka0 (boot dka0.0.0.6.0 -flags 0) *** Soft Error - Error #27 - SCSI: sense key = 'Unit Attention' (29|02) from dka0.0.0.6.0 Diagnostic Name ID Device Pass Test Hard/Soft 26-OCT-2019 boot 00000089 0 0 0 1 19:45:39 *** End of Error *** block 0 of dka0.0.0.6.0 is a valid boot block reading 14 blocks from dka0.0.0.6.0 bootstrap code read in base = 166000, image_start = 0, image_bytes = 1c00 initializing HWRPB at 2000 initializing page table at 158000 initializing machine state setting affinity to the primary CPU jumping to bootstrap code *** Soft Error - Error #27 - SCSI: sense key = 'Unit Attention' (29|02) from dka0.0.0.6.0 Diagnostic Name ID Device Pass Test Hard/Soft 26-OCT-2019 boot 00000089 0 0 0 2 19:45:41 *** End of Error *** %Console: SRM firmware console VMS PAL rev: 0x1000000010530 OSF PAL rev: 0x1000000020123 Switch to OSF PAL code succeeded. FreeBSD/alpha SRM disk boot, Revision (jkh@beast.cdrom.com, Sun May 16 17:48:25 GMT 1999) Memory: 65536 k *** Soft Error - Error #27 - SCSI: sense key = 'Unit Attention' (29|02) from dka0.0.0.6.0 Diagnostic Name ID Device Pass Test Hard/Soft 26-OCT-2019 boot 00000089 0 0 0 3 19:45:44 *** End of Error *** %> load /kernel %inflate: (null) panic: free: guard1 fail @ 0x200094a0 halted CPU 0 halt code = 5 HALT instruction executed PC = 2001f3b8 access violation fault PCB = 03F542C0 (entry) PC = 0004FED0 VA = 00000028 exception context saved starting at 03F562C0 GPRs: 0: 00000000 00000000 16: 00000000 00000000 1: 00000000 000BFFFF 17: 00000000 000E1518 2: 00000000 0010B610 18: 00000000 000464D4 3: 00000000 00038B20 19: 00000000 00109390 4: 00000000 00000000 20: 00000000 00038320 5: 00000000 00038B20 21: 00000000 00110CA0 6: 00000000 00000000 22: 00000000 00142B90 7: 00000000 00000000 23: 00000000 00000000 8: 00000000 00000000 24: 00000000 00000000 9: 00000000 00000000 25: 00000000 00000002 10: 00000000 00000000 26: 00000000 0004FEB0 11: 00000000 00000000 27: 00000000 00114228 12: 00000000 00000000 28: 00000000 00016050 13: 00000000 00000000 29: 00000000 03F56428 14: 00000000 00000000 30: 00000000 03F56428 15: 00000000 00000000 dump of active call frames: PC = 0004FED0 PD = 0010B610 (decc$fclose) FP = 03F56428 SP = 03F56428 R2 R3 R4 R29 saved starting at 03F56430 R2 = 00111A30 R3 = 03F542C0 R4 = 03F54398 R29 = 03F56458 PC = 0006A83C PD = 00111A30 (krn$_process) FP = 03F56458 SP = 03F56458 R2 R3 R4 R5 R29 saved starting at 03F56460 R2 = 00000000 R3 = 00000000 R4 = 00000000 R5 = 00000000 R29 = 00000000 Brk 0 at 0012FF08 0012FF08! BPT -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Oct 26 14:36:23 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 4BB7114CC5 for ; Tue, 26 Oct 1999 14:36:06 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id XAA04490 for freebsd-alpha@freebsd.org; Tue, 26 Oct 1999 23:24:09 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id XAA56041 for freebsd-alpha@freebsd.org; Tue, 26 Oct 1999 23:05:08 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199910262105.XAA56041@yedi.iaf.nl> Subject: Mach64-svga on FreeBSD/alpha To: freebsd-alpha@freebsd.org (FreeBSD-alpha mailing list) Date: Tue, 26 Oct 1999 23:05:08 +0200 (CEST) X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Does anyone have FreeBSD/alpha configured with an Xserver running on a Mach64-based SVGA card? If so, any comments on: alpine#XF86_Mach64 XFree86 Version 3.3.3.1 / X Window System (protocol Version 11, revision 0, vendor release 6300) Release Date: January 4 1999 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (see http://www.XFree86.Org/FAQ) Operating System: FreeBSD 4.0-CURRENT alpha [ELF] Configured drivers: Mach64: accelerated server for ATI Mach64 graphics adaptors (Patchlevel 0) Using syscons driver with X support (version 2.0) (using VT number 5) XF86Config: /etc/XF86Config (**) stands for supplied, (--) stands for probed/default values (**) XKB: disabled (**) XKB: keymap: "xfree86(us)" (overrides other XKB settings) (**) Mouse: type: PS/2, device: /dev/mouse, buttons: 3 (**) Mach64: Graphics device ID: "winturbo" (**) Mach64: Monitor ID: "Idek" (--) Mach64: Mode "1600x1200" needs hsync freq of 87.50 kHz. Deleted. (--) Mach64: Mode "1152x864" needs hsync freq of 89.62 kHz. Deleted. (--) Mach64: Mode "1280x1024" needs hsync freq of 91.15 kHz. Deleted. (--) Mach64: Mode "1600x1200" needs hsync freq of 93.75 kHz. Deleted. (--) Mach64: Mode "1600x1200" needs hsync freq of 105.77 kHz. Deleted. (--) Mach64: Mode "1280x1024" needs hsync freq of 107.16 kHz. Deleted. (--) Mach64: Mode "1800X1440" needs hsync freq of 96.15 kHz. Deleted. (--) Mach64: Mode "1800X1440" needs hsync freq of 104.52 kHz. Deleted. (**) FontPath set to "/usr/X11R6/lib/X11/fonts/local/,/usr/X11R6/lib/X11/fonts/ isc/,/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/100dpi/: nscaled,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X 1R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/" >>>>>> (--) Mach64: PCI: Mach64 CX rev 1, Aperture @ 0x81000000, Sparse I/O @ 0x02ec *** None of the configured devices were detected.*** Fatal server error: no screens found I'm especially puzzled by the line marked with >>>> The card is an ATI WinTurbo which was OK in my Intel box. TIA -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Oct 26 14:45: 1 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 74A4614C56 for ; Tue, 26 Oct 1999 14:44:53 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id RAA03894; Tue, 26 Oct 1999 17:44:52 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id RAA27845; Tue, 26 Oct 1999 17:44:22 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 26 Oct 1999 17:44:22 -0400 (EDT) To: Wilko Bulte Cc: freebsd-alpha@FreeBSD.ORG (FreeBSD-alpha mailing list) Subject: Re: Mach64-svga on FreeBSD/alpha In-Reply-To: <199910262105.XAA56041@yedi.iaf.nl> References: <199910262105.XAA56041@yedi.iaf.nl> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14358.8254.334980.730088@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte writes: <..> > (--) Mach64: Mode "1800X1440" needs hsync freq of 104.52 kHz. Deleted. > (**) FontPath set to > "/usr/X11R6/lib/X11/fonts/local/,/usr/X11R6/lib/X11/fonts/ > isc/,/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/100dpi/: > nscaled,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X > 1R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/" > > >>>>>> (--) Mach64: PCI: Mach64 CX rev 1, Aperture @ 0x81000000, Sparse I/O @ > 0x02ec > > *** None of the configured devices were detected.*** > > Fatal server error: > no screens found > > > I'm especially puzzled by the line marked with >>>> > > The card is an ATI WinTurbo which was OK in my Intel box. Perhaps your mode lines are overly aggressive? Is this the same config file you used on the Intel box? Does it say anything between the line about Aperture @ 0x81000000 & the no screens found line? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Oct 26 15: 2:33 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from ns2.cetlink.net (ns2.cetlink.net [209.198.2.20]) by hub.freebsd.org (Postfix) with ESMTP id 7200114E00 for ; Tue, 26 Oct 1999 15:02:25 -0700 (PDT) (envelope-from jeff@cetlink.net) Received: from cartman (cartman.cetlink.net [209.198.61.152]) by ns2.cetlink.net (8.9.3/8.9.3) with SMTP id RAA84678 for ; Tue, 26 Oct 1999 17:59:34 -0400 (EDT) From: "Jeffrey Wheat" To: "FreeBSD-alpha mailing list" Subject: IRRD on FreeBSD alpha Date: Tue, 26 Oct 1999 18:02:22 -0400 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) In-Reply-To: <14358.8254.334980.730088@grasshopper.cs.duke.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just wondering if anyone has managed to get the IRRD package from Merit.EDU to run on a FreeBSD alpha box. Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Oct 26 16: 9:27 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 3B49714CEC for ; Tue, 26 Oct 1999 16:09:23 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40396>; Wed, 27 Oct 1999 09:04:21 +1000 Content-return: prohibited Date: Wed, 27 Oct 1999 09:09:13 +1000 From: Peter Jeremy Subject: Re: Multia booting woes In-reply-to: <19991026205726.A52927@gsmx07.alcatel.com.au> To: freebsd-alpha@FreeBSD.ORG Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Oct27.090421est.40396@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <19991026205726.A52927@gsmx07.alcatel.com.au> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-Oct-26 20:57:26 +1000, I wrote: >Latest try: I've dd'd releases/3.2-RELEASE/floppies/boot.flp from >3.2-RELEASE CD-ROM 2 onto a SCSI disk, stuck the disk into the Multia >and it still dies (log below). I put the disk back onto my 386 box and re-checked the contents. This showed about half-a-dozen random bytes were not what I (thought I) wrote. I re-dd'd the boot image and all is now working. I have no idea why the data was corrupted. Sorry for the false alarm. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Oct 26 21:20:20 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from GATE.joy-tech.com.tw (gate.joy-tech.com.tw [202.60.89.1]) by hub.freebsd.org (Postfix) with ESMTP id C7D6114A18 for ; Tue, 26 Oct 1999 21:20:15 -0700 (PDT) (envelope-from tate@joy-tech.com.tw) Received: (from nobody@localhost) by GATE.joy-tech.com.tw (8.9.3/8.9.3) id MAA57256 for freebsd-alpha@freebsd.org; Wed, 27 Oct 1999 12:20:06 +0800 (CST) (envelope-from tate@joy-tech.com.tw) X-Authentication-Warning: GATE.joy-tech.com.tw: nobody set sender to tate@joy-tech.com.tw using -f Message-ID: <940998006.38167d761d1a4@mail.joy-tech.com.tw> Date: Wed, 27 Oct 1999 12:20:06 +0800 To: freebsd-alpha@freebsd.org From: "Tate <­«¥Í>" MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.0-cvs Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi: Does anyone running MySQL(3.22.27) on a FreeBSD-Current Alpha without problem? I compiled from source with the following, but I got the error message "ERROR 2013: Lost connection to MySQL server during query" when I query. CFLAGS= -O3 -pipe CXXFLAGS -O3 -pipe ./configure --localstatedir=/home/mysql --without-perl --without-debug --without-readline --without-bench --with-charset=big5 --enable-large-files --with-low-memory OS: FreeBSD Current (0915-snapshot) Hardware: Digital AlphaPC 164LX 533 MHz with 256M RAM Any suggestion? +-----------------------------------------------------------------------+ |Tate Chen JOY-TECH Computer Center http://www.joy-tech.com.tw | |183 CHUNG CHENG RD. TA YA HSIANG, TAICHUNG HSIEN, TAIWAN, R.O.C. | |mailto:tate@joy-tech.com.tw Tel:(886)4-5668888 Fax:(886)4-5675456| +-----------------------------------------------------------------------+ ----------------------------------------------------------- This mail sent through JOY-TECH Mail System To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Oct 27 15:21:24 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 7A1DD14A11 for ; Wed, 27 Oct 1999 15:20:59 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id AAA13647; Thu, 28 Oct 1999 00:12:48 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id AAA67502; Thu, 28 Oct 1999 00:06:49 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199910272206.AAA67502@yedi.iaf.nl> Subject: Re: Mach64-svga on FreeBSD/alpha In-Reply-To: <14358.8254.334980.730088@grasshopper.cs.duke.edu> from Andrew Gallatin at "Oct 26, 1999 5:44:22 pm" To: gallatin@cs.duke.edu (Andrew Gallatin) Date: Thu, 28 Oct 1999 00:06:49 +0200 (CEST) Cc: freebsd-alpha@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Andrew Gallatin wrote ... > > Wilko Bulte writes: > <..> > > (--) Mach64: Mode "1800X1440" needs hsync freq of 104.52 kHz. Deleted. > > (**) FontPath set to > > "/usr/X11R6/lib/X11/fonts/local/,/usr/X11R6/lib/X11/fonts/ > > isc/,/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/100dpi/: > > nscaled,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X > > 1R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/" > > > > >>>>>> (--) Mach64: PCI: Mach64 CX rev 1, Aperture @ 0x81000000, Sparse I/O @ > > 0x02ec > > > > *** None of the configured devices were detected.*** > > > > Fatal server error: > > no screens found > > I'm especially puzzled by the line marked with >>>> > > The card is an ATI WinTurbo which was OK in my Intel box. > > Perhaps your mode lines are overly aggressive? Is this the same > config file you used on the Intel box? > Does it say anything between the line about Aperture @ 0x81000000 & > the no screens found line? No, it does not. Which is a bit !verbose to me to be honest. Does the aperture line give any useful info? It does not to me, but.. ;-) Wilko -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Oct 27 16:22:14 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id B40D914C0E for ; Wed, 27 Oct 1999 16:22:06 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40344>; Thu, 28 Oct 1999 09:16:59 +1000 Content-return: prohibited Date: Thu, 28 Oct 1999 09:21:57 +1000 From: Peter Jeremy Subject: halting back to Multia SRM To: freebsd-alpha@FreeBSD.ORG, multia-users@explode.unsw.edu.au Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Oct28.091659est.40344@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I notice that when I halt FreeBSD 3.2-RELEASE, my multia reports: halted CPU 0 halt code = 5 HALT instruction executed PC = fffffc0000482cc0 access violation fault PCB = 03F542E0 (entry) PC = 0004FED0 VA = 00000028 exception context saved starting at 03F56300 ... Brk 0 at 0012FF08 0012FF08! BPT Does anyone know how to make the `halt' return directly to the SRM console? Alternatively, does anyone have documentation for the `ROM monitor' mode that I wind up in. So far, I've experimentally determined that TAB is some sort of exception, trying hex characters lets me change addresses and `o' single-steps. I haven't found a command to exit back to the SRM (or even perform a reset). Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Oct 27 17:10:12 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 9143014D09 for ; Wed, 27 Oct 1999 17:09:41 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id UAA09568; Wed, 27 Oct 1999 20:09:38 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id UAA30135; Wed, 27 Oct 1999 20:09:07 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 27 Oct 1999 20:09:07 -0400 (EDT) To: Wilko Bulte Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: Mach64-svga on FreeBSD/alpha In-Reply-To: <199910272206.AAA67502@yedi.iaf.nl> References: <14358.8254.334980.730088@grasshopper.cs.duke.edu> <199910272206.AAA67502@yedi.iaf.nl> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14359.36582.911428.608670@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte writes: > > > >>>>>> (--) Mach64: PCI: Mach64 CX rev 1, Aperture @ 0x81000000, Sparse I/O @ > > > 0x02ec > > > <...> > > No, it does not. Which is a bit !verbose to me to be honest. Does the > aperture line give any useful info? It does not to me, but.. ;-) Yes, it says what address the frame buffer is mapped into & what i/o port it is using for register access. Neither of those is terribly useful for figuring out why it doesn't want to start the server. Darn. I should have thought about this sooner.... About 1 year ago, when we were first getting X working, I used one of the ATI Mach64 cards that shipped in some older AS200s. This was a borrowed card. I wrote the following about it in private email after getting it working: > I borrowed an Ati Mach64 from a friend (thanks Sean!), and it > appears to work just fine. My AS200 has been up for 1/2 hour running > netperf TCP streams (over a 100mb nic), Bonnie, a remotely displayed > 'ico', all while I drag opaque windows around over a complex gif > background. Its not exactly speedy, but its rock solid. > > Speaking of the ATI server, it tries to grope around in the bios > strings to figure out the ramdac & clock chip. I bludgeoned the driver > into submission & specified the ramdac/clock chips in my config file. > But there are probably more drivers that do this; I guess we'll need > to make xf86ReadBIOS work.. I don't know if xf86ReadBIOS was ever fixed. But you might want to try specifying the clock chip & ramdac. I no longer recall what I meant by "bludgeon the driver into submission" & I no longer have that copy of the X server code. I do still have the xf86 config file where I said: Section "Device" Identifier "m64" ClockChip "ics2595" Ramdac "stg1702" Option "override_bios" Option "no_block_write" Option "no_bios_clocks" # Clocks 135.0 80.0 40.0 EndSection These are almost certainly wrong for your spiffy new card, but you get an idea of what I needed to inform the X server about. Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Oct 27 17:31:30 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from alfheim.satanic.net (alfheim.satanic.net [194.200.106.33]) by hub.freebsd.org (Postfix) with SMTP id D0F0A14F51 for ; Wed, 27 Oct 1999 17:31:05 -0700 (PDT) (envelope-from nicolai@satanic.net) Received: from nicolai by alfheim.satanic.net with local (Exim) id 11gdSw-0004fi-00; Thu, 28 Oct 1999 01:30:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14359.39229.647906.434227@alfheim.satanic.net> Date: Thu, 28 Oct 1999 01:30:53 +0100 (BST) From: Nicolai E M Plum To: peter.jeremy@alcatel.com.au Cc: freebsd-alpha@FreeBSD.ORG, multia-users@explode.unsw.edu.au Subject: halting back to Multia SRM In-Reply-To: <99Oct28.091659est.40344@border.alcanet.com.au> References: <99Oct28.091659est.40344@border.alcanet.com.au> X-Mailer: VM 6.67 under Emacs 19.34.1 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Jeremy writes: > I notice that when I halt FreeBSD 3.2-RELEASE, my multia > reports: > > halted CPU 0 > > halt code = 5 > HALT instruction executed > PC = fffffc0000482cc0 > > access violation fault > PCB = 03F542E0 (entry) > PC = 0004FED0 > VA = 00000028 > > exception context saved starting at 03F56300 > ... > Brk 0 at 0012FF08 > > 0012FF08! BPT > > Does anyone know how to make the `halt' return directly to the SRM > console? > > Alternatively, does anyone have documentation for the `ROM monitor' > mode that I wind up in. So far, I've experimentally determined that > TAB is some sort of exception, trying hex characters lets me change > addresses and `o' single-steps. I haven't found a command to exit > back to the SRM (or even perform a reset). I believe it is the XDELTA debugger, for which I have to date found only poor documentation on Digital/Compaq's website. Typing ;P will cause more register dumps &c, then ;P again will after some seconds drop you to the >>> SRM prompt. I would also dearly like to know how to avoid this; OpenBSD does the right thing on one of my Multias if I reboot the operating system, although it emits some of the above sort of messages before it boots. FreeBSD just sits there in the debugger if either 'reboot'ed or 'halt'ed. I can't actually test the OpenBSD machine at the moment because it's got a burnt-out logic chip that I cannot find a UK source for yet (74FCT623, if anyone knows?). I can see no PROM configuration variables that are different and they are running the same SRM version. Nicolai To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Oct 27 17:44:13 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 80AE514C3D for ; Wed, 27 Oct 1999 17:43:50 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40325>; Thu, 28 Oct 1999 10:38:44 +1000 Content-return: prohibited Date: Thu, 28 Oct 1999 10:43:40 +1000 From: Peter Jeremy Subject: Re: Netbooting a Multia with FreeBSD In-reply-to: <19991019085210.A86077@gsmx07.alcatel.com.au> To: freebsd-alpha@freebsd.org, multia-users@explode.unsw.edu.au Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Oct28.103844est.40325@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <19991019085210.A86077@gsmx07.alcatel.com.au> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-Oct-19 08:52:10 +1000, I wrote: >My problem is that netboot seems unable to accept the DHCP or RARP >responses returned to its requests. It just cycles between DHCP >and RARP requests until it times out. After some experimenting, it appears that making broken_firmware a boolean in /usr/src/sys/boot/alpha/libalpha/srmnet.c does not cover the Multia (at least with SRM 3.8.3). This SRM is broken enough to need the MAC address explicitly included in netbbinfo, but call to prom_read() in prom_get() _does_ need to specify the receiving structure size (ie the broken_firmware test is not needed). Without background on what other varieties of brokenness DEC implemented in various SRMs, I can't offer a sensible patch. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Oct 27 18:15:58 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from note.orchestra.cse.unsw.EDU.AU (note.orchestra.cse.unsw.EDU.AU [129.94.242.29]) by hub.freebsd.org (Postfix) with SMTP id 2873414BF5 for ; Wed, 27 Oct 1999 18:15:31 -0700 (PDT) (envelope-from danielp@cse.unsw.edu.au) Received: From paulaner With LocalMail ; Thu, 28 Oct 99 11:12:32 +1000 From: Daniel Potts To: Nicolai E M Plum Date: Thu, 28 Oct 1999 11:12:31 +1000 (EST) X-Sender: danielp@paulaner.disy.cse.unsw.EDU.AU Cc: peter.jeremy@alcatel.com.au, freebsd-alpha@FreeBSD.ORG, multia-users@explode.unsw.edu.au Subject: Re: halting back to Multia SRM In-Reply-To: <14359.39229.647906.434227@alfheim.satanic.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 28 Oct 1999, Nicolai E M Plum wrote: > Peter Jeremy writes: > > I notice that when I halt FreeBSD 3.2-RELEASE, my multia > > reports: > > > > halted CPU 0 > > > > halt code = 5 > > HALT instruction executed > > PC = fffffc0000482cc0 > > > > access violation fault > > PCB = 03F542E0 (entry) > > PC = 0004FED0 > > VA = 00000028 Those messages show it is well into the SRM code.. perhaps something in memory has been trashed (that shouldnt really be) by BSD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Oct 27 19:40:43 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 7D14714CD0; Wed, 27 Oct 1999 19:40:32 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id WAA12294; Wed, 27 Oct 1999 22:40:31 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id WAA30300; Wed, 27 Oct 1999 22:40:00 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 27 Oct 1999 22:40:00 -0400 (EDT) To: freebsd-hackers@freebsd.org Cc: freebsd-alpha@freebsd.org Subject: ip forwarding broken on alpha X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14359.43410.495963.975277@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have an older AlphaStation 600 5/266 running -current (cvsupped last week) which is setup as a router between 2 100mb networks. When the machine is pushed fairly hard (like running a netperf -tUDP_STREAM -- -m 100 across the router, eg about 10-20k 100byte packets/sec ) the alpha falls over almost instantly. I have not enabled any NAT or firewall functionality, just ip forwarding. It generally crashes in MCLGET down in the ethernet driver's receiver interrupt handler. The driver doesn't seem to matter -- I've tried Intel Etherexpress Pro 100Bs and 3Com 3c905C-TX Fast Etherlink XLs. A typical stack trace looks like this: fatal kernel trap: trap entry = 0x2 (memory management fault) a0 = 0x826417b78f222 a1 = 0x1 a2 = 0x0 pc = 0xfffffc00004b31bc ra = 0xfffffc00004b315c curproc = 0 ddbprinttrap from 0xfffffc00004b31bc ddbprinttrap(0x826417b78f222, 0x1, 0x0, 0x2) panic: trap panic Stopped at Debugger+0x2c: ldq ra,0(sp) <0xfffffe0005ab57d0> db> tr Debugger() at Debugger+0x2c panic() at panic+0xf4 trap() at trap+0x5cc xl_newbuf() at xl_newbuf+0x15c (null)() at 0x4 db> c this maps to pci/if_xl.c:1654. But the if_xl driver is probably not at fault, as I can crash just as easily in fxp_add_rfabuf() when using intel nics. Before trying the 3com cards, I had been working under the assumption that it was a problem with the fxp driver. I instrumented the mbuf routines somewhat (i hate debugging macros) and it seems the bad access is due to mclfree getting trashed & replaced by a "random" bad value (0x826417b78f222 in this panic). This might be a red herring, but I've found that if I run the entire ip_input path under splnet() (added splnet() around the call to ip_input() in ipintr().), things get a hell of a lot more stable. Rather than crashing in a few seconds, it sometimes takes minutes. And rather than an illegal access, I tend to run out of kernel stack space ( either a panic("possible stack overflow\n"); in alpha/alpha/interrupt.c, or I end up in the SRM console after calling halt from a PC which isn't in the kernel, which smells like an overrun stack to me). I'm not sure if this is related, or if it is a separate problem entirely. Since an x86 (PII@300MHz, 440lx motherboard, kernel built from same sources) is rock solid under the same workload, I suspect there's something wrong that is alpha specific, but I'll be damned if I can figure it out. My best guess is that it has something to do with the different interrupt structure on i386 & alpha. As I understand it, the i386 can mask off particular interrupt sources, but the alpha simply raises & lowers the ipl with the following levels available (from alpha/include/alpha_cpu.h): #define ALPHA_PSL_IPL_0 0x0000 /* all interrupts enabled */ #define ALPHA_PSL_IPL_SOFT 0x0001 /* software ints disabled */ #define ALPHA_PSL_IPL_IO 0x0004 /* I/O dev ints disabled */ #define ALPHA_PSL_IPL_CLOCK 0x0005 /* clock ints disabled */ #define ALPHA_PSL_IPL_HIGH 0x0006 /* all but mchecks disabled */ Can anybody hazard a guess as to what's going on? I've appended dmesg output & my config file for completeness. BTW, as long as the load is light, ip forwarding seems to work. I can't seem to make this happen using 2 100Mb tulips in this box (which must copy on the input path due to DMA alignment problems, this slows things down quite a bit, due to the low memory bandwidth of this machine) Thanks, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 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 #4: Wed Oct 27 11:35:25 EDT 1999 gallatin@torrent.cs.duke.edu:/usr/project/ari_scratch2/gallatin/src/sys/comp ile/ALPHA AlphaStation 500 or 600 (KN20AA) Digital AlphaStation 600 5/266, 266MHz 8192 byte page size, 1 processor. CPU: EV5 (21164) major=5 minor=0 OSF PAL rev: 0x1000000020116 real memory = 131940352 (128848K bytes) avail memory = 122200064 (119336K bytes) Preloaded elf kernel "kernel" at 0xfffffc0000674000. cia0: ALCOR/ALCOR2, pass 2 pcib0: <2117x PCI host bus adapter> on cia0 pci0: on pcib0 xl0: <3Com 3c905C-TX Fast Etherlink XL> irq 8 at device 7.0 on pci0 xl0: interrupting at CIA irq 8 xl0: Ethernet address: 00:50:da:09:3e:41 miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcib1: at device 8.0 on pci0 pci1: on pcib1 de0: irq 16 at device 0.0 on pci1 de0: interrupting at CIA irq 16 de0: DEC 21040 [10Mb/s] pass 2.3 de0: address 08:00:2b:e7:e6:d6 isp0: irq 17 at device 1.0 on pci1 isp0: interrupting at CIA irq 17 isp0: invalid NVRAM header (aa,aa,aa,aa) isp0: isp_mboxcmd sees mailbox int with 0x0 in mbox0 isp0: isp_mboxcmd sees mailbox int with 0x0 in mbox0 <..> isp1: irq 18 at device 2.0 on pci1 isp1: interrupting at CIA irq 18 isp1: isp_mboxcmd sees mailbox int with 0x0 in mbox0 isp1: invalid NVRAM header (55,55,55,55) isp1: isp_mboxcmd sees mailbox int with 0x0 in mbox0 isp1: isp_mboxcmd sees mailbox int with 0x0 in mbox0 de1: irq 12 at device 9.0 on pci0 de1: interrupting at CIA irq 12 de1: DEC DE500-XA 21140 [10-100Mb/s] pass 1.1 de1: address 00:00:f8:00:99:ba de1: enabling Full Duplex 100baseTX port isab0: at device 10.0 on pci0 isa0: on isab0 xl1: <3Com 3c905C-TX Fast Etherlink XL> irq 0 at device 11.0 on pci0 xl1: interrupting at CIA irq 0 xl1: Ethernet address: 00:50:da:09:42:41 miibus1: on xl1 xlphy1: <3c905C 10/100 internal PHY> on miibus1 xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl2: <3Com 3c905C-TX Fast Etherlink XL> irq 4 at device 12.0 on pci0 xl2: interrupting at CIA irq 4 xl2: Ethernet address: 00:50:da:09:3f:e8 miibus2: on xl2 xlphy2: <3c905C 10/100 internal PHY> on miibus2 xlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto mcclock0: at port 0x70-0x71 on isa0 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A, console sio0: interrupting at ISA irq 4 sio1 at port 0x2f8-0x2ff irq 3 flags 0x80 on isa0 sio1: type 16550A sio1: interrupting at ISA irq 3 fdc0: interrupting at ISA irq 6 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 atkbd0: interrupting at ISA irq 1 struct nfssvc_sock bloated (> 256bytes) Try reducing NFS_UIDHASHSIZ struct nfsuid bloated (> 128bytes) Try unionizing the nu_nickname and nu_flag fields Timecounter "alpha" frequency 266671691 Hz Waiting 3 seconds for SCSI devices to settle isp0: driver initiated bus reset of bus 0 isp1: driver initiated bus reset of bus 0 de0: autosense failed: cable problem? Creating DISK da0 Creating DISK da1 Creating DISK cd0 da0 at isp0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da0: 4095MB (8388315 512 byte sectors: 255H 63S/T 522C) da1 at isp0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da1: 2062MB (4223444 512 byte sectors: 255H 63S/T 262C) cd0 at isp0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 4.032MB/s transfers (4.032MHz, offset 12) cd0: Attempt to query device size failed: NOT READY, Medium not present # machine alpha cpu EV4 cpu EV5 ident ALPHA maxusers 32 # Platforms supported options DEC_AXPPCI_33 # UDB, Multia, AXPpci33, Noname options DEC_EB164 # EB164, PC164, PC164LX, PC164SX options DEC_EB64PLUS # EB64+, Aspen Alpine, etc options DEC_2100_A50 # AlphaStation 200, 250, 255, 400 options DEC_KN20AA # AlphaStation 500, 600 options DEC_ST550 # Personal Workstation 433, 500, 600 options DEC_ST6600 # xp1000, dp264, ds20, ds10, family #options DEC_3000_300 # DEC3000/300* Pelic* family #options DEC_3000_500 # DEC3000/[4-9]00 Flamingo/Sandpiper family options INET #InterNETworking `options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options MFS #Memory Filesystem options MFS_ROOT #Memory Filesystem as rootfs options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root device options FFS_ROOT #FFS usable as root device [keep this!] options NFS_ROOT #NFS usable as root device 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 SOFTUPDATES # Standard busses controller pci0 controller isa0 # A single entry for any of these controllers (ncr, ahb, ahc, amd) is # sufficient for any number of installed devices. controller ncr0 controller isp0 controller ahc0 #controller esp0 controller scbus0 device da0 device sa0 device pass0 device cd0 # # ATA and ATAPI devices # This is work in progress, use at your own risk. # It currently reuses the majors of wd.c and friends. # It cannot co-exist with the old system in one kernel. # You only need one "controller ata0" for it to find all # PCI devices on modern machines. controller ata0 device atadisk0 # ATA disk drives device atapicd0 # ATAPI CDROM drives device atapifd0 # ATAPI floppy drives device atapist0 # ATAPI tape drives # real time clock device mcclock0 at isa0 port 0x70 controller fdc0 at isa? port IO_FD1 irq 6 drq 2 disk fd0 at fdc0 drive 0 controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0 at atkbdc? 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? device sio0 at isa0 port IO_COM1 irq 4 device sio1 at isa0 port IO_COM2 irq 3 flags 0x80 # MII bus support, required for some 10/100 NICs. controller miibus0 # Operational PCI Ethernet drivers. device al0 device ax0 device de0 device dm0 device fxp0 device le0 device mx0 device pn0 device rl0 device sf0 device sis0 device ste0 device tl0 device vr0 device wb0 device xl0 pseudo-device loop pseudo-device ether pseudo-device sl 1 pseudo-device ppp 1 pseudo-device tun pseudo-device pty pseudo-device bpf 4 # 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 and message queues. # options SYSVSHM options SYSVMSG options SYSVSEM # # everything above is essentially GENERIC. customizations below. # options DDB options BREAK_TO_DEBUGGER To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Oct 28 14:33: 6 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 96F7C14C18 for ; Thu, 28 Oct 1999 14:32:59 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id WAA15028; Thu, 28 Oct 1999 22:56:14 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id VAA17273; Thu, 28 Oct 1999 21:54:44 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199910281954.VAA17273@yedi.iaf.nl> Subject: Re: Mach64-svga on FreeBSD/alpha In-Reply-To: <14359.36582.911428.608670@grasshopper.cs.duke.edu> from Andrew Gallatin at "Oct 27, 1999 8: 9: 7 pm" To: gallatin@cs.duke.edu (Andrew Gallatin) Date: Thu, 28 Oct 1999 21:54:44 +0200 (CEST) Cc: freebsd-alpha@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Andrew Gallatin wrote ... > > Wilko Bulte writes: > Darn. I should have thought about this sooner.... About 1 year ago, > when we were first getting X working, I used one of the ATI Mach64 > cards that shipped in some older AS200s. This was a borrowed card. I > wrote the following about it in private email after getting it working: > > > I borrowed an Ati Mach64 from a friend (thanks Sean!), and it > > appears to work just fine. My AS200 has been up for 1/2 hour running > > netperf TCP streams (over a 100mb nic), Bonnie, a remotely displayed > > 'ico', all while I drag opaque windows around over a complex gif > > background. Its not exactly speedy, but its rock solid. > > > > Speaking of the ATI server, it tries to grope around in the bios > > strings to figure out the ramdac & clock chip. I bludgeoned the driver > > into submission & specified the ramdac/clock chips in my config file. > > But there are probably more drivers that do this; I guess we'll need > > to make xf86ReadBIOS work.. > > I don't know if xf86ReadBIOS was ever fixed. But you might want to > try specifying the clock chip & ramdac. I no longer recall what I > meant by "bludgeon the driver into submission" & I no longer have that > copy of the X server code. I do still have the xf86 config file where > I said: > > Section "Device" > Identifier "m64" > ClockChip "ics2595" > Ramdac "stg1702" > Option "override_bios" > Option "no_block_write" > Option "no_bios_clocks" > # Clocks 135.0 80.0 40.0 > EndSection I tried these, building on my i386 version of XF86config that I used on my Intel box with this card. The only difference is my Ramdac BTW. Alas it does not work :-( Some more hacking to do I guess. > These are almost certainly wrong for your spiffy new card, but you get > an idea of what I needed to inform the X server about. It is not a spiffy new card :) I already have it a couple of years (and I bought it for a few bucks at a flea market) -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Oct 28 17:39: 5 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from post.bgnett.no (post.bgnett.no [194.54.96.133]) by hub.freebsd.org (Postfix) with ESMTP id 58C6F154AD for ; Thu, 28 Oct 1999 17:38:41 -0700 (PDT) (envelope-from erik@habatech.no) Received: from bsdbox.habatech.no ([62.92.133.3]) by post.bgnett.no (8.8.8/8.8.8) with ESMTP id CAA11063 for ; Fri, 29 Oct 1999 02:38:33 +0200 (CEST) (envelope-from erik@habatech.no) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 29 Oct 1999 02:38:29 +0200 (CEST) From: "Erik H. Bakke" To: freebsd-alpha@freebsd.org Subject: Strange problem with ATA on my 164SX Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well, there seems to be no end to the madness I am able to invoke in my Alpha system :) This night I pulled out the graphics adapter from the box, thinking I could run it headless for a while (after all, I have used the serial console as the primary communication method for several months...) Oh man, how I was wrong... Once the card was out, the ATA driver went totally crazy. Whenever I tried to access my drive(s) I was instantly greeted by "lost disk contact" and friends. After some hours of scratching my head, saying bad words and endless reboot cycles, I put the graphics card back in, just to see what happened, and lo and behold... The system was back to normal again. So, this leads to an obvious question: Is FreeBSD supposed to be able to run headless on Alpha systems? After all, everything worked OK, except for the ATA drives... If it is, then this may be something to look into. ===========================+================+=============================== Erik H. Bakke | | To be or not to be... Senior Consultant/Developer|erik@habatech.no| Is simply a question of Habatech AS | | binary logic ===========================+================+============================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Oct 28 17:55:16 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 34ECE14ED6 for ; Thu, 28 Oct 1999 17:55:03 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id UAA08707; Thu, 28 Oct 1999 20:54:59 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id UAA33147; Thu, 28 Oct 1999 20:54:29 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 28 Oct 1999 20:54:28 -0400 (EDT) To: "Erik H. Bakke" Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: Strange problem with ATA on my 164SX In-Reply-To: References: X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14360.61161.234897.646014@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Erik H. Bakke writes: > > After some hours of scratching my head, saying bad words and endless reboot > cycles, I put the graphics card back in, just to see what happened, and lo and > behold... The system was back to normal again. > > So, this leads to an obvious question: > > Is FreeBSD supposed to be able to run headless on Alpha systems? Yes. We have over 20 alphas running FreeBSD headless here. 6 of them are DS10s with nothing but IDE drives (and local hacks to get them booting off of ide drives). Just a WAG: Try putting a DELAY(1000) at the top of ad_transfer. There are some timing issues I've seen w/addump that might be biting you. I have NFC why a graphics card would matter though. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Oct 28 18:10: 0 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from post.bgnett.no (post.bgnett.no [194.54.96.133]) by hub.freebsd.org (Postfix) with ESMTP id 59A7F154AD for ; Thu, 28 Oct 1999 18:09:38 -0700 (PDT) (envelope-from erik@habatech.no) Received: from bsdbox.habatech.no ([62.92.133.3]) by post.bgnett.no (8.8.8/8.8.8) with ESMTP id DAA11102; Fri, 29 Oct 1999 03:09:27 +0200 (CEST) (envelope-from erik@habatech.no) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <14360.61161.234897.646014@grasshopper.cs.duke.edu> Date: Fri, 29 Oct 1999 03:09:23 +0200 (CEST) From: "Erik H. Bakke" To: Andrew Gallatin Subject: Re: Strange problem with ATA on my 164SX Cc: freebsd-alpha@FreeBSD.ORG Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 29-Oct-99 Andrew Gallatin wrote: > Just a WAG: Try putting a DELAY(1000) at the top of ad_transfer. > There are some timing issues I've seen w/addump that might be biting > you. I gave it a try, but sad to say, it did not remedy the situation. > > I have NFC why a graphics card would matter though. > It seems my system is quite intent on driving me crazy these days :) Maybe the removal of the graphics card freed up some PCI bus cycles, which again led to some timing problem? But then, it could have something to do with the SRM firmware not doing the Right Thing without the graphics card. I will try upgrading the SRM during the weekend. As a sidenote. When fooling around with a reinstall of a fairly recent snapshot, I got loads of Signal 12's. Init would terminate with the signal. This again, would only happen when I included the ATA drivers in the kernel. But, I have to agree with you. It is very hard to see how the absence of a graphics card would cause the problem. Introduction of a new card would have been a much more likely source of problems. Anyway, the problem goes away when the card is reinserted, so it is not a big deal, but it could be a symptom of something wrong that only surfaces under certain conditions. Thanks for the help, anyway. ===========================+================+=============================== Erik H. Bakke | | To be or not to be... Senior Consultant/Developer|erik@habatech.no| Is simply a question of Habatech AS | | binary logic ===========================+================+============================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Oct 28 18:33:48 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 51CC314EE8; Thu, 28 Oct 1999 18:33:24 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id VAA09459; Thu, 28 Oct 1999 21:33:21 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id VAA33215; Thu, 28 Oct 1999 21:32:51 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 28 Oct 1999 21:32:51 -0400 (EDT) To: dfr@nlsystems.com Cc: freebsd-hackers@freebsd.org, freebsd-alpha@freebsd.org Subject: Re: ip forwarding broken on alpha In-Reply-To: <14359.43410.495963.975277@grasshopper.cs.duke.edu> References: <14359.43410.495963.975277@grasshopper.cs.duke.edu> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14360.62787.116526.830259@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andrew Gallatin writes: > > I have an older AlphaStation 600 5/266 running -current (cvsupped > last week) which is setup as a router between 2 100mb networks. When > the machine is pushed fairly hard (like running a netperf -tUDP_STREAM > -- -m 100 across the router, eg about 10-20k 100byte packets/sec ) the > alpha falls over almost instantly. I have not enabled any NAT or > firewall functionality, just ip forwarding. <...> > > This might be a red herring, but I've found that if I run the entire > ip_input path under splnet() (added splnet() around the call to > ip_input() in ipintr().), things get a hell of a lot more stable. > Rather than crashing in a few seconds, it sometimes takes minutes. > And rather than an illegal access, I tend to run out of kernel stack > space ( either a panic("possible stack overflow\n"); in > alpha/alpha/interrupt.c, or I end up in the SRM console after calling > halt from a PC which isn't in the kernel, which smells like an overrun > stack to me). I'm not sure if this is related, or if it is a separate > problem entirely. That was it. The problem is that the interrupt handler returns through exception_return, like the trap handler does. Exception_return checks to see if the last ipl the system was at was 0. If it was, it eventually lowers the ipl to zero and checks for a pending ast. This was the problem. If you're getting interrupts quickly enough, there's large window when you're still running on the interrupt stack where you're sitting at ipl0 and you can get another interrupt & build onto that stack. If you're getting 40,000 interrupts per second (forwarding 20,000 packets/sec), this can build up & rapidly run you out of stack space. I've found the system can forward 70,000 packets per second & remain perfectly stable with the appended patch. I'm not terribly good at assembler, so rather than try to be tricky & check to see if the current ipl is >= 4 (handling a device interrupt), I simply copied exception_return & skipped the ipl lowering & the check for an ast since I don't think you're ever going to need to check for an ast after an interrupt. I have NFC why mclfree was getting trashed, but it must have been caused by running out of stack space as the appended patch seems to take care of everything. Doug -- should I commit this as-is, or do you want to take a more refined approach? Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 Index: exception.s =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/exception.s,v retrieving revision 1.3 diff -u -r1.3 exception.s --- exception.s 1999/08/28 00:38:26 1.3 +++ exception.s 1999/10/28 19:17:26 @@ -76,7 +76,7 @@ /* a0, a1, & a2 already set up */ mov sp, a3 ; .loc 1 __LINE__ CALL(interrupt) - jmp zero, exception_return + jmp zero, interrupt_return END(XentInt) /**************************************************************************/ Index: swtch.s =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/swtch.s,v retrieving revision 1.11 diff -u -r1.11 swtch.s --- swtch.s 1999/08/28 00:38:32 1.11 +++ swtch.s 1999/10/28 20:08:24 @@ -308,6 +308,61 @@ .set at END(exception_return) + + +LEAF(interrupt_return, 1) /* XXX should be NESTED */ + br pv, Lintr_er1 +Lintr_er1: LDGP(pv) + + ldq s1, (FRAME_PS * 8)(sp) /* get the saved PS */ + and s1, ALPHA_PSL_IPL_MASK, t0 /* look at the saved IPL */ + bne t0, Lintr_restoreregs /* != 0: can't do AST or SIR */ + + /* see if we can do an SIR */ + ldl t1, ipending /* SIR pending? */ + beq t1, Lintr_chkast /* no, try an AST*/ + + /* We've got a SIR. */ + CALL(do_sir) /* do the SIR; lowers IPL */ + +Lintr_chkast: + + and s1, ALPHA_PSL_USERMODE, t0 /* are we returning to user? */ + beq t0, Lintr_restoreregs /* no: just return */ + +Lintr_setfpenable: + /* enable FPU based on whether the current proc is fpcurproc */ + ldq t0, curproc + ldq t1, fpcurproc + cmpeq t0, t1, t0 + mov zero, a0 + cmovne t0, 1, a0 + call_pal PAL_OSF1_wrfen + +Lintr_restoreregs: + /* set the hae register if this process has specified a value */ + ldq t0, curproc + beq t0, Lintr_nohae + ldq t1, P_MD_FLAGS(t0) + and t1, MDP_HAEUSED + beq t1, Lintr_nohae + ldq a0, P_MD_HAE(t0) + ldq pv, chipset + CHIPSET_WRITE_HAE + CALL((pv)) +Lintr_nohae: + + /* restore the registers, and return */ + bsr ra, exception_restore_regs /* jmp/CALL trashes pv/t12 */ + ldq ra,(FRAME_RA*8)(sp) + .set noat + ldq at_reg,(FRAME_AT*8)(sp) + + lda sp,(FRAME_SW_SIZE*8)(sp) + call_pal PAL_OSF1_rti + .set at + END(interrupt_return) + + LEAF(exception_save_regs, 0) stq v0,(FRAME_V0*8)(sp) stq a3,(FRAME_A3*8)(sp) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Oct 28 21:56:22 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.33.127]) by hub.freebsd.org (Postfix) with ESMTP id 51ED214C20; Thu, 28 Oct 1999 21:56:20 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id VAA10430; Thu, 28 Oct 1999 21:56:05 -0700 (PDT) Message-Id: <199910290456.VAA10430@lestat.nas.nasa.gov> To: Andrew Gallatin Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: ip forwarding broken on alpha Reply-To: Jason Thorpe From: Jason Thorpe Date: Thu, 28 Oct 1999 21:56:04 -0700 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 28 Oct 1999 21:32:51 -0400 (EDT) Andrew Gallatin wrote: > exception_return & skipped the ipl lowering & the check for an ast > since I don't think you're ever going to need to check for an ast > after an interrupt. Nonsense. ASTs are a key part of process scheduling, and I'd bet that you run into strange scheduling behaviour if you don't deal with ASTs after e.g. clock interrupts. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Oct 29 2:53:13 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 8F84E14D0B; Fri, 29 Oct 1999 02:53:06 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id KAA72539; Fri, 29 Oct 1999 10:53:29 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Fri, 29 Oct 1999 10:53:29 +0100 (BST) From: Doug Rabson To: Andrew Gallatin Cc: freebsd-hackers@freebsd.org, freebsd-alpha@freebsd.org Subject: Re: ip forwarding broken on alpha In-Reply-To: <14360.62787.116526.830259@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 28 Oct 1999, Andrew Gallatin wrote: > > Andrew Gallatin writes: > > > > I have an older AlphaStation 600 5/266 running -current (cvsupped > > last week) which is setup as a router between 2 100mb networks. When > > the machine is pushed fairly hard (like running a netperf -tUDP_STREAM > > -- -m 100 across the router, eg about 10-20k 100byte packets/sec ) the > > alpha falls over almost instantly. I have not enabled any NAT or > > firewall functionality, just ip forwarding. > > <...> > > > > > This might be a red herring, but I've found that if I run the entire > > ip_input path under splnet() (added splnet() around the call to > > ip_input() in ipintr().), things get a hell of a lot more stable. > > Rather than crashing in a few seconds, it sometimes takes minutes. > > And rather than an illegal access, I tend to run out of kernel stack > > space ( either a panic("possible stack overflow\n"); in > > alpha/alpha/interrupt.c, or I end up in the SRM console after calling > > halt from a PC which isn't in the kernel, which smells like an overrun > > stack to me). I'm not sure if this is related, or if it is a separate > > problem entirely. > > That was it. > > The problem is that the interrupt handler returns through > exception_return, like the trap handler does. Exception_return checks > to see if the last ipl the system was at was 0. If it was, it > eventually lowers the ipl to zero and checks for a pending ast. This > was the problem. If you're getting interrupts quickly enough, there's > large window when you're still running on the interrupt stack where > you're sitting at ipl0 and you can get another interrupt & build onto > that stack. If you're getting 40,000 interrupts per second > (forwarding 20,000 packets/sec), this can build up & rapidly run you > out of stack space. > > I've found the system can forward 70,000 packets per second & remain > perfectly stable with the appended patch. I'm not terribly good at > assembler, so rather than try to be tricky & check to see if the > current ipl is >= 4 (handling a device interrupt), I simply copied > exception_return & skipped the ipl lowering & the check for an ast > since I don't think you're ever going to need to check for an ast > after an interrupt. > > I have NFC why mclfree was getting trashed, but it must have been > caused by running out of stack space as the appended patch seems to > take care of everything. > > Doug -- should I commit this as-is, or do you want to take a more > refined approach? I think the intention of ASTs is that they are generated whenever you are returning to user mode. This patch will essentially defer the AST until the next system call which might be unacceptable. I can see the window and its a serious problem but I'm worried about fixing it in this way. What I really want is some way to generate a 'real' AST after the PALcode has dropped the exception frame for the interrupt. Without changing to use the VMS palcode, we aren't going to get that though :-). (ASTs and SWIs are derived from the way VAXen work and the VMS palcode emulates the old vax behaviour). The main problem as I see it is that we are dropping the IPL to zero before calling the ast. I don't see why we are doing this at all. We should be able to just call the ast without changing the ipl at all. This still leaves a window in do_sir (which lowers the IPL to 1) though. Perhaps, SWIs should be handled by using another kernel thread which can be switched to instead of calling do_sir. I have to think about that some more. Could you test just removing the swpipl(0) code and see if it improves things, thanks. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Oct 29 2:59:41 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 33FDF14A0B; Fri, 29 Oct 1999 02:59:35 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id LAA76319; Fri, 29 Oct 1999 11:00:07 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Fri, 29 Oct 1999 11:00:07 +0100 (BST) From: Doug Rabson To: Jason Thorpe Cc: Andrew Gallatin , freebsd-hackers@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: ip forwarding broken on alpha In-Reply-To: <199910290456.VAA10430@lestat.nas.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 28 Oct 1999, Jason Thorpe wrote: > On Thu, 28 Oct 1999 21:32:51 -0400 (EDT) > Andrew Gallatin wrote: > > > exception_return & skipped the ipl lowering & the check for an ast > > since I don't think you're ever going to need to check for an ast > > after an interrupt. > > Nonsense. ASTs are a key part of process scheduling, and I'd bet that > you run into strange scheduling behaviour if you don't deal with ASTs > after e.g. clock interrupts. Thats correct. The problem is that we are calling the AST with interrupts enabled which allows unbounded interrupt recursion. This is true in NetBSD (at least in version 1.60 of locore.s) as well. The whole idea of ASTs and SWIs is an awful hangover from the VAX; there must be a better way. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Oct 29 7:20:33 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id DD99E14EBB; Fri, 29 Oct 1999 07:20:25 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id KAA21656; Fri, 29 Oct 1999 10:20:14 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id KAA34233; Fri, 29 Oct 1999 10:19:44 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 29 Oct 1999 10:19:44 -0400 (EDT) To: Doug Rabson Cc: Andrew Gallatin , freebsd-hackers@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: ip forwarding broken on alpha In-Reply-To: References: <14360.62787.116526.830259@grasshopper.cs.duke.edu> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14361.41684.912860.445771@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Doug Rabson writes: > > I think the intention of ASTs is that they are generated whenever you are > returning to user mode. This patch will essentially defer the AST until > the next system call which might be unacceptable. Whoops! I hadn't realized this. > I can see the window and its a serious problem but I'm worried about > fixing it in this way. What I really want is some way to generate a 'real' > AST after the PALcode has dropped the exception frame for the interrupt. > Without changing to use the VMS palcode, we aren't going to get that > though :-). (ASTs and SWIs are derived from the way VAXen work and the VMS > palcode emulates the old vax behaviour). > > The main problem as I see it is that we are dropping the IPL to zero > before calling the ast. I don't see why we are doing this at all. We > should be able to just call the ast without changing the ipl at all. This > still leaves a window in do_sir (which lowers the IPL to 1) though. I think this is safe because if we don't lower the ipl to 0, then we cannot get recursion because of this check: ldq s1, (FRAME_PS * 8)(sp) /* get the saved PS */ and s1, ALPHA_PSL_IPL_MASK, t0 /* look at the saved IPL */ bne t0, Lrestoreregs /* != 0: can't do AST or SIR */ I think the worst that can happen is 0: ?: ipl0, interrupted 1: device interrupt : ipl4 prev. ipl == 0 --> calls do_sir, lowers ipl to 1, interrupted 2: device interrupt : ipl4, previous ipl != 0, returns > Perhaps, SWIs should be handled by using another kernel thread which can > be switched to instead of calling do_sir. I have to think about that some > more. Could you test just removing the swpipl(0) code and see if it > improves things, thanks. Yes, it improves things. Removing the swpipl(0) appears to make an alpha stable under extreme interrupt load. I'm most of the way through a cvs checkout of -current while forwarding about 15,000 packets/sec. If I can get through a buildworld under this load, I'll call it stable. I am also curious as to why the swpipl(0) was there in the first place. I was initially concerned that it was required for some reason I did not understand (like something higher up was expecting exception_return to clean up the ipl state). I did know that the PALcode puts the ipl back where it was after a hardware interrupt. This is another reason I previously thought that special casing hardware interrupts might be the right thing to do. I looked at NetBSD's CVS web, and it looks like it has been there since day one. It will be nice to loose it, as it should reduce overhead quite a bit. For clarity, I'm running with just the following now: Index: swtch.s =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/swtch.s,v retrieving revision 1.11 diff -u -c -r1.11 swtch.s cvs diff: conflicting specifications of output style *** swtch.s 1999/08/28 00:38:32 1.11 --- swtch.s 1999/10/29 13:39:46 *************** *** 263,271 **** CALL(do_sir) /* do the SIR; lowers IPL */ Lchkast: - ldiq a0, ALPHA_PSL_IPL_0 /* drop IPL to zero*/ - call_pal PAL_OSF1_swpipl - and s1, ALPHA_PSL_USERMODE, t0 /* are we returning to user? */ beq t0, Lrestoreregs /* no: just return */ --- 263,268 ---- Thanks, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Oct 29 8: 9:37 1999 Delivered-To: freebsd-alpha@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 608) id 0135414BF7; Fri, 29 Oct 1999 08:09:35 -0700 (PDT) From: "Jonathan M. Bresler" To: gallatin@cs.duke.edu Cc: erik@habatech.no, freebsd-alpha@FreeBSD.ORG In-reply-to: <14360.61161.234897.646014@grasshopper.cs.duke.edu> (message from Andrew Gallatin on Thu, 28 Oct 1999 20:54:28 -0400 (EDT)) Subject: Re: Strange problem with ATA on my 164SX Message-Id: <19991029150935.0135414BF7@hub.freebsd.org> Date: Fri, 29 Oct 1999 08:09:35 -0700 (PDT) Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Drew, i have an alpha that i cant use till i get a kern.flp created after 19991012 (your commit). can you create one for me? its actually rather easy. if its too much hassle, skip it. download ftp://current.freebsd.org/pub/FreeBSD/snapshots/alpha/4.0-19990915-CURRENT/floppies/kern.flp. vnconfig vn0c kern.flp mount /dev/vn0c /mnt create a new kernel gzip kernel cp kernel.gz /mnt vnconfig -d vn0c dd if=kern.flp of=/dev/fd0a bs=9k ;) jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Oct 29 9:59:15 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 6BE2E14E7E for ; Fri, 29 Oct 1999 09:59:09 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.1/8.9.1) id JAA32062; Fri, 29 Oct 1999 09:59:02 -0700 Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp05.primenet.com, id smtpdl9SsUa; Fri Oct 29 09:58:29 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id JAA16006; Fri, 29 Oct 1999 09:58:21 -0700 (MST) From: Terry Lambert Message-Id: <199910291658.JAA16006@usr02.primenet.com> Subject: Re: your mail To: tate@joy-tech.com.tw (Tate) Date: Fri, 29 Oct 1999 16:58:21 +0000 (GMT) Cc: freebsd-alpha@FreeBSD.ORG In-Reply-To: <940998006.38167d761d1a4@mail.joy-tech.com.tw> from "Tate" at Oct 27, 99 12:20:06 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-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Does anyone running MySQL(3.22.27) on a FreeBSD-Current Alpha without > problem? > I compiled from source with the following, but I got the error message > "ERROR 2013: Lost connection to MySQL server during query" when I query. > > CFLAGS= -O3 -pipe > CXXFLAGS -O3 -pipe > ./configure --localstatedir=/home/mysql --without-perl --without-debug > --without-readline --without-bench --with-charset=big5 --enable-large-files > --with-low-memory > > OS: FreeBSD Current (0915-snapshot) > Hardware: Digital AlphaPC 164LX 533 MHz with 256M RAM > > Any suggestion? Look at the compile time thread signal handling options. 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-alpha" in the body of the message From owner-freebsd-alpha Fri Oct 29 11:10:59 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37]) by hub.freebsd.org (Postfix) with ESMTP id AEDA115594 for ; Fri, 29 Oct 1999 11:10:50 -0700 (PDT) (envelope-from bottemanne@capitolonline.nl) Received: from capitolonline.nl ([195.121.168.11]) by smtp03.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA3ABF; Fri, 29 Oct 1999 20:10:47 +0200 Message-ID: <3819F192.CEFEB1BA@capitolonline.nl> Date: Fri, 29 Oct 1999 20:12:18 +0100 From: Aernoudt Bottemanne X-Mailer: Mozilla 4.04 [en] (OS/2; I) MIME-Version: 1.0 To: Andrew Gallatin Cc: "freebsd-alpha@freebsd.org" Subject: Re: ip forwarding broken on alpha References: <14359.43410.495963.975277@grasshopper.cs.duke.edu> <14360.62787.116526.830259@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Andrew, About the osf libraries: I downloaded your patch file, but it does not: make depend, make, make install. It says: don't know how to make depend/install. After downloading, I unpacked/archived it. It made the /Alpha/osf1 directory in sys/modules. What do I do wrong ? I would love to use netscape again.... Cheers, Aernoudt Andrew Gallatin wrote: > Andrew Gallatin writes: > > > > I have an older AlphaStation 600 5/266 running -current (cvsupped > > last week) which is setup as a router between 2 100mb networks. When > > the machine is pushed fairly hard (like running a netperf -tUDP_STREAM > > -- -m 100 across the router, eg about 10-20k 100byte packets/sec ) the > > alpha falls over almost instantly. I have not enabled any NAT or > > firewall functionality, just ip forwarding. > > <...> > > > > > This might be a red herring, but I've found that if I run the entire > > ip_input path under splnet() (added splnet() around the call to > > ip_input() in ipintr().), things get a hell of a lot more stable. > > Rather than crashing in a few seconds, it sometimes takes minutes. > > And rather than an illegal access, I tend to run out of kernel stack > > space ( either a panic("possible stack overflow\n"); in > > alpha/alpha/interrupt.c, or I end up in the SRM console after calling > > halt from a PC which isn't in the kernel, which smells like an overrun > > stack to me). I'm not sure if this is related, or if it is a separate > > problem entirely. > > That was it. > > The problem is that the interrupt handler returns through > exception_return, like the trap handler does. Exception_return checks > to see if the last ipl the system was at was 0. If it was, it > eventually lowers the ipl to zero and checks for a pending ast. This > was the problem. If you're getting interrupts quickly enough, there's > large window when you're still running on the interrupt stack where > you're sitting at ipl0 and you can get another interrupt & build onto > that stack. If you're getting 40,000 interrupts per second > (forwarding 20,000 packets/sec), this can build up & rapidly run you > out of stack space. > > I've found the system can forward 70,000 packets per second & remain > perfectly stable with the appended patch. I'm not terribly good at > assembler, so rather than try to be tricky & check to see if the > current ipl is >= 4 (handling a device interrupt), I simply copied > exception_return & skipped the ipl lowering & the check for an ast > since I don't think you're ever going to need to check for an ast > after an interrupt. > > I have NFC why mclfree was getting trashed, but it must have been > caused by running out of stack space as the appended patch seems to > take care of everything. > > Doug -- should I commit this as-is, or do you want to take a more > refined approach? > > Drew > ------------------------------------------------------------------------------ > Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin > Duke University Email: gallatin@cs.duke.edu > Department of Computer Science Phone: (919) 660-6590 > > Index: exception.s > =================================================================== > RCS file: /home/ncvs/src/sys/alpha/alpha/exception.s,v > retrieving revision 1.3 > diff -u -r1.3 exception.s > --- exception.s 1999/08/28 00:38:26 1.3 > +++ exception.s 1999/10/28 19:17:26 > @@ -76,7 +76,7 @@ > /* a0, a1, & a2 already set up */ > mov sp, a3 ; .loc 1 __LINE__ > CALL(interrupt) > - jmp zero, exception_return > + jmp zero, interrupt_return > END(XentInt) > > /**************************************************************************/ > Index: swtch.s > =================================================================== > RCS file: /home/ncvs/src/sys/alpha/alpha/swtch.s,v > retrieving revision 1.11 > diff -u -r1.11 swtch.s > --- swtch.s 1999/08/28 00:38:32 1.11 > +++ swtch.s 1999/10/28 20:08:24 > @@ -308,6 +308,61 @@ > .set at > END(exception_return) > > + > + > +LEAF(interrupt_return, 1) /* XXX should be NESTED */ > + br pv, Lintr_er1 > +Lintr_er1: LDGP(pv) > + > + ldq s1, (FRAME_PS * 8)(sp) /* get the saved PS */ > + and s1, ALPHA_PSL_IPL_MASK, t0 /* look at the saved IPL */ > + bne t0, Lintr_restoreregs /* != 0: can't do AST or SIR */ > + > + /* see if we can do an SIR */ > + ldl t1, ipending /* SIR pending? */ > + beq t1, Lintr_chkast /* no, try an AST*/ > + > + /* We've got a SIR. */ > + CALL(do_sir) /* do the SIR; lowers IPL */ > + > +Lintr_chkast: > + > + and s1, ALPHA_PSL_USERMODE, t0 /* are we returning to user? */ > + beq t0, Lintr_restoreregs /* no: just return */ > + > +Lintr_setfpenable: > + /* enable FPU based on whether the current proc is fpcurproc */ > + ldq t0, curproc > + ldq t1, fpcurproc > + cmpeq t0, t1, t0 > + mov zero, a0 > + cmovne t0, 1, a0 > + call_pal PAL_OSF1_wrfen > + > +Lintr_restoreregs: > + /* set the hae register if this process has specified a value */ > + ldq t0, curproc > + beq t0, Lintr_nohae > + ldq t1, P_MD_FLAGS(t0) > + and t1, MDP_HAEUSED > + beq t1, Lintr_nohae > + ldq a0, P_MD_HAE(t0) > + ldq pv, chipset + CHIPSET_WRITE_HAE > + CALL((pv)) > +Lintr_nohae: > + > + /* restore the registers, and return */ > + bsr ra, exception_restore_regs /* jmp/CALL trashes pv/t12 */ > + ldq ra,(FRAME_RA*8)(sp) > + .set noat > + ldq at_reg,(FRAME_AT*8)(sp) > + > + lda sp,(FRAME_SW_SIZE*8)(sp) > + call_pal PAL_OSF1_rti > + .set at > + END(interrupt_return) > + > + > LEAF(exception_save_regs, 0) > stq v0,(FRAME_V0*8)(sp) > stq a3,(FRAME_A3*8)(sp) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Oct 29 14:57:11 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from sonet.crimea.ua (OTC-sl3-FLY.CRIS.NET [212.110.136.71]) by hub.freebsd.org (Postfix) with ESMTP id 29E6814BF3 for ; Fri, 29 Oct 1999 14:56:26 -0700 (PDT) (envelope-from phantom@scorpion.crimea.ua) Received: (from uucp@localhost) by sonet.crimea.ua (8.8.8/8.8.8) with UUCP id BAA23499 for alpha@FreeBSD.org; Sat, 30 Oct 1999 01:00:55 +0400 (MSD) (envelope-from phantom@scorpion.crimea.ua) Received: (from phantom@localhost) by scorpion.crimea.ua (8.8.8/8.8.5+ssl+keepalive) id AAA26703; Sat, 30 Oct 1999 00:32:19 +0400 (MSD) Date: Sat, 30 Oct 1999 00:32:19 +0400 From: Alexey Zelkin To: alpha@FreeBSD.org Subject: man4 Message-ID: <19991030003219.A26597@scorpion.crimea.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i X-Operating-System: FreeBSD 2.2.7-RELEASE i386 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hi, Can someone look to src/share/man/man4/man4.i386 and say which drivers are using at Alpha boxes ? I just wanna move non i386 specific manpages from man4.i386 directory. Thanks ! PS: I am also interesting about fea0/fpa0 drivers. Are these drivers available for Alpha ? -- /* Alexey Zelkin && phantom@cris.net */ /* Tavric National University && phantom@crimea.edu */ /* http://www.ccssu.crimea.ua/~phantom && phantom@FreeBSD.org */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sat Oct 30 8:27:47 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from hermes.mixx.net (hermes.mixx.net [194.152.58.71]) by hub.freebsd.org (Postfix) with ESMTP id 6E63E1506C for ; Sat, 30 Oct 1999 08:19:29 -0700 (PDT) (envelope-from graichen@innominate.de) Received: from innominate.de (gatekeeper.innominate.de [212.5.16.129]) by hermes.mixx.net (8.9.3/8.9.3) with SMTP id OAA17604 for ; Tue, 26 Oct 1999 14:17:26 +0200 Received: (qmail 17712 invoked from network); 26 Oct 1999 12:17:13 -0000 Received: from piano.innominate.local (192.168.0.213) by lingo01.innominate.local with SMTP; 26 Oct 1999 12:17:13 -0000 Received: from localhost (graichen@localhost) by piano.innominate.local (8.9.3/8.9.3) with ESMTP id OAA09887 for ; Tue, 26 Oct 1999 14:17:12 +0200 (CEST) (envelope-from graichen@innominate.de) X-Authentication-Warning: piano.innominate.local: graichen owned process doing -bs Date: Tue, 26 Oct 1999 14:17:12 +0200 (CEST) From: Thomas Graichen X-Sender: graichen@piano.innominate.local To: freebsd-alpha@FreeBSD.org Subject: supported alphas Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org is there anywhere an actual list of supported alpha hardware by FreeBSD - especially - what is the current state vs. booting - do i still need an srm console to get FreeBSD booted or is there now too support for booting from the arc console ? a lot of thanks in advance t -- graichen@innominate.de innominate AG networking people fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sat Oct 30 10:13:45 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from mail.cybcon.com (mail.cybcon.com [216.190.188.5]) by hub.freebsd.org (Postfix) with ESMTP id 881C914A0E for ; Sat, 30 Oct 1999 10:13:44 -0700 (PDT) (envelope-from wwoods@cybcon.com) Received: from freebsd.cybcon.com (william@usr1-10.cybcon.com [205.147.75.11]) by mail.cybcon.com (8.9.0/8.9.0) with SMTP id KAA22380 for ; Sat, 30 Oct 1999 10:13:42 -0700 (PDT) From: william woods Reply-To: wwoods@cybcon.com To: freebsd-alpha@freebsd.org Subject: IDE Drive in an Alpha? Date: Sat, 30 Oct 1999 10:12:21 -0700 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <99103010131601.00368@freebsd.cybcon.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have an AlphaStation 200 4/233 that has a 1 gig SCSI on it. I also have an extra WD Cavier 2 gig IDE drive and would like to know if I can put the IDE drive in the Alpha along with the SCSI....does an Alpha have an IDE controler? -- William Woods FreeBSD 3.3-Stable To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sat Oct 30 13:48: 2 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 802D814D6D for ; Sat, 30 Oct 1999 13:47:59 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id QAA23493; Sat, 30 Oct 1999 16:47:52 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id QAA41830; Sat, 30 Oct 1999 16:47:22 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 30 Oct 1999 16:47:21 -0400 (EDT) To: wwoods@cybcon.com Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: IDE Drive in an Alpha? In-Reply-To: <99103010131601.00368@freebsd.cybcon.com> References: <99103010131601.00368@freebsd.cybcon.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14363.22498.951801.446968@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org william woods writes: > I have an AlphaStation > 200 4/233 that has a 1 gig SCSI on it. I also have an extra WD Cavier 2 gig > IDE drive and would like to know if I can put the IDE drive in the Alpha along > with the SCSI....does an Alpha have an IDE controler? Some alphas do. Yours does not. You *might* be able to get a Promise IDE card ($25 the last time I looked) to work, but such a configuration has not been tested on alpha. Also, IDE on alpha isn't supported in 3.x & probably never will be. IDE on alpha requires the new ata driver which exists only in 4.0-CURRENT. Cheers, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sat Oct 30 14:57:53 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37]) by hub.freebsd.org (Postfix) with ESMTP id 4824D14C2F for ; Sat, 30 Oct 1999 14:57:44 -0700 (PDT) (envelope-from bottemanne@capitolonline.nl) Received: from capitolonline.nl ([195.121.169.234]) by smtp03.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA3184; Sat, 30 Oct 1999 23:57:43 +0200 Message-ID: <381B7828.FE3B14EE@capitolonline.nl> Date: Sat, 30 Oct 1999 23:58:48 +0100 From: Aernoudt Bottemanne X-Mailer: Mozilla 4.04 [en] (OS/2; I) MIME-Version: 1.0 To: Andrew Gallatin , "freebsd-alpha@freebsd.org" Subject: osf1 problem/netscape not running, error message says: References: <14359.43410.495963.975277@grasshopper.cs.duke.edu> <14360.62787.116526.830259@grasshopper.cs.duke.edu> <3819F192.CEFEB1BA@capitolonline.nl> <14362.17827.942878.205141@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello Andrew, The method underneath indeed worked. However when I start netscape, I get the following error message: netscape: locale 'C' not supported perhaps the $XNLSPATH environment variable is not set correctly ? Warning: locale not supported by Xlib, locale set to C Warning: X locale modifiers not supported, using default X Error: BadAtom Request Major code 18 () AtomID 0x0 Error Serial #27 Current Serial #32 I hope you can make something out of this .... Just to be on the safe side, I put the osf libraries both in /usr/compat/osf1 and the appropriate files also in /etc, /usr /usr/sbin (in ordr to make sure it can find them) Aernoudt Andrew Gallatin wrote: > Looks like i gave you poor instructions. Do > > cd /usr/src/sys > tar zxvf /some/path/to/osf1.tar.gz > cd modules/osf1 > make depend > make > make install > rehash > osf1 > > Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Sat Oct 30 16:15:29 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 0F35E14D2B for ; Sat, 30 Oct 1999 16:15:06 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id TAA25265; Sat, 30 Oct 1999 19:15:04 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id TAA42219; Sat, 30 Oct 1999 19:14:33 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 30 Oct 1999 19:14:33 -0400 (EDT) To: Aernoudt Bottemanne Cc: freebsd-alpha@freebsd.org Subject: Re: osf1 problem/netscape not running, error message says: In-Reply-To: <381B7828.FE3B14EE@capitolonline.nl> References: <14359.43410.495963.975277@grasshopper.cs.duke.edu> <14360.62787.116526.830259@grasshopper.cs.duke.edu> <3819F192.CEFEB1BA@capitolonline.nl> <14362.17827.942878.205141@grasshopper.cs.duke.edu> <381B7828.FE3B14EE@capitolonline.nl> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14363.31595.631986.159740@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Aernoudt Bottemanne writes: > netscape: locale 'C' not supported > perhaps the $XNLSPATH environment variable is not set correctly ? > Warning: locale not supported by Xlib, locale set to C > Warning: X locale modifiers not supported, using default > X Error: BadAtom > Request Major code 18 () > AtomID 0x0 > Error Serial #27 > Current Serial #32 Do you have all the OSF/1 X11 stuff installed?: <7:13pm>bacon/gallatin:~>ls /compat/osf1/usr/lib/X11/locale Compose/ compose.dir locale.dir XLC_LOCALE/ locale.alias tbl_data/ Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message