From owner-freebsd-alpha Sun Jan 7 5:12:59 2001 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 CBB0337B402 for ; Sun, 7 Jan 2001 05:12:40 -0800 (PST) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #2) id 14FFck-00077u-00; Sun, 07 Jan 2001 13:12:39 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.1/8.11.1) id f07DDcL81547; Sun, 7 Jan 2001 14:13:38 +0100 (CET) (envelope-from wkb) Date: Sun, 7 Jan 2001 14:13:38 +0100 From: Wilko Bulte To: Andrew Gallatin Cc: freebsd-alpha@freebsd.org Subject: Re: debugging fpa / FDDI panic Message-ID: <20010107141337.A81533@freebie.demon.nl> References: <20010106214357.X77275@freebie.demon.nl> <14935.34600.806565.787237@grasshopper.cs.duke.edu> <20010106224542.A78582@freebie.demon.nl> <14935.37795.408651.78296@grasshopper.cs.duke.edu> <20010106234244.A78789@freebie.demon.nl> <14935.42278.147202.426911@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14935.42278.147202.426911@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Sat, Jan 06, 2001 at 06:25:45PM -0500 X-OS: FreeBSD 4.2-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jan 06, 2001 at 06:25:45PM -0500, Andrew Gallatin wrote: > > Yes. that's what I meant. Sorry for the delay. The maze of #ifdefs in > the driver is making me dizzy.. I wonder if there's an unifdef that's > smart enough to deal with #if defined().. > > Anyway, try changing the typdef of the pdq_bus_memaddr_t from > typedef volatile pdq_uint32_t *pdq_bus_memaddr_t; > to > typedef volatile vm_offset_t *pdq_bus_memaddr_t; > > in the FreeBSD section of ifdefs. > > > Also, printf (with %lx) the value of sc->sc_membase prior to calling > pdq_initialize(). Hmm, this does not seem right: pci1: at 10.0 (no driver attached) fpa0: port 0x9000-0x907f mem 0x80950000-0x8095ffff,0x80960000-0x8096007f irq 4 at device 11.0 on pci0 DEBUG FPA: sc->sc_membase = 0 fatal kernel trap: trap entry = 0x2 (memory management fault) a0 = 0x28 a1 = 0x1 a2 = 0x0 pc = 0xfffffc00003906f8 ra = 0xfffffc0000390438 curproc = 0xfffffc0000611138 pid = 0, comm = swapper Stopped at pdq_initialize+0x538: ldq t0,0(t0) <0x28> db> > If this works, we're still going to need a DMA hack. It will be > something like this: > > #if defined(__FreeBSD__) && defined(__alpha__) > #define PDQ_OS_VA_TO_PA(pdq, p) (vtophys((vm_offset_t)p) | (pdq->pdq_type == PDQ_DEFTA ? 0 : alpha_XXX_dmamap_or)) > #endif > > Ick.. Ouch. -- | / o / / _ Arnhem, The Netherlands email: wilko@freebsd.org |/|/ / / /( (_) Bulte http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Jan 8 13:32:56 2001 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 6E5E737B714; Mon, 8 Jan 2001 12:56:30 -0800 (PST) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #4) id 14FjL8-000JM0-00; Mon, 08 Jan 2001 20:56:27 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.1/8.11.1) id f08KuCI01827; Mon, 8 Jan 2001 21:56:12 +0100 (CET) (envelope-from wkb) Date: Mon, 8 Jan 2001 21:56:12 +0100 From: Wilko Bulte To: Andrew Gallatin Cc: bmah@freebsd.org, FreeBSD-alpha mailing list Subject: Re: debugging fpa / FDDI panic Message-ID: <20010108215612.A1802@freebie.demon.nl> References: <20010106234244.A78789@freebie.demon.nl> <14935.42278.147202.426911@grasshopper.cs.duke.edu> <20010107141337.A81533@freebie.demon.nl> <14936.55164.885512.323554@grasshopper.cs.duke.edu> <20010107225750.A84196@freebie.demon.nl> <14936.59031.486042.446371@grasshopper.cs.duke.edu> <20010107232824.F84536@freebie.demon.nl> <14936.60937.576026.297702@grasshopper.cs.duke.edu> <20010108211138.T793@freebie.demon.nl> <14938.7938.69285.585393@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14938.7938.69285.585393@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Mon, Jan 08, 2001 at 03:13:16PM -0500 X-OS: FreeBSD 4.2-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jan 08, 2001 at 03:13:16PM -0500, Andrew Gallatin wrote: > > Wilko Bulte writes: > > > ..and that seems to be the bullseye: > > Woo-hoo! Yessir! > You have an x86 equipped w/the same adapter, right? Can you try those Sure, that is the other end of my FDDI network. > same patches there, please? I'd like to make sure I don't break x86 > before I commit them ;) I just applied the patch (see attached) to pdqvar.h on x86. Both the x86 and the alpha are now happilly keeping eachother busy, x86 'bonnie' writing to an NFS fs served by the alpha. No problem seen, they are happy with one another ;) So, as far as I'm concerned committing to -current is a go. I'll update RELNOTES / alpha/HARDWARE.TXT myself once I see the commit message go by Wilko -- | / o / / _ Arnhem, The Netherlands email: wilko@freebsd.org |/|/ / / /( (_) Bulte http://www.freebsd.org http://www.nlfug.nl --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=foo --- pdqvar.h.orig Wed Jan 17 23:07:17 2001 +++ pdqvar.h Wed Jan 17 23:07:37 2001 @@ -86,6 +86,8 @@ #define PDQ_OS_MEMZERO(p, n) bzero((caddr_t)(p), (n)) #if defined(__NetBSD__) && defined(__alpha__) #define PDQ_OS_VA_TO_PA(pdq, p) (vtophys((vm_offset_t)p) | (pdq->pdq_type == PDQ_DEFTA ? 0 : 0x40000000)) +#elif defined(__FreeBSD__) && defined(__alpha__) +#define PDQ_OS_VA_TO_PA(pdq, p) (vtophys((vm_offset_t)p) | (pdq->pdq_type == PDQ_DEFTA ? 0 : alpha_XXX_dmamap_or)) #else #define PDQ_OS_VA_TO_PA(pdq, p) vtophys(p) #endif @@ -102,6 +104,7 @@ #if defined(__FreeBSD__) #include #include +#include #include #include typedef void ifnet_ret_t; @@ -176,8 +179,8 @@ #define PDQ_OS_IOWR_32(t, base, offset, data) outl((base) + (offset), data) #define PDQ_OS_IORD_8(t, base, offset) inb((base) + (offset)) #define PDQ_OS_IOWR_8(t, base, offset, data) outb((base) + (offset), data) -#define PDQ_OS_MEMRD_32(t, base, offset) (0 + *((base) + (offset))) -#define PDQ_OS_MEMWR_32(t, base, offset, data) do *((base) + (offset)) = (data); while (0) +#define PDQ_OS_MEMRD_32(t, base, offset) readl((base) + (offset)) +#define PDQ_OS_MEMWR_32(t, base, offset, data) writel((base) + (offset), data) #endif #ifndef PDQ_CSR_OFFSET #define PDQ_CSR_OFFSET(base, offset) (0 + (base) + (offset)) --ew6BAiZeqk4r7MaW-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Jan 8 19:30:18 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 553A937B401 for ; Mon, 8 Jan 2001 19:30:01 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f093U1S10655; Mon, 8 Jan 2001 19:30:01 -0800 (PST) (envelope-from gnats) Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 1BAA537B401 for ; Mon, 8 Jan 2001 19:23:19 -0800 (PST) Received: (from nobody@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f093NJp10125; Mon, 8 Jan 2001 19:23:19 -0800 (PST) (envelope-from nobody) Message-Id: <200101090323.f093NJp10125@freefall.freebsd.org> Date: Mon, 8 Jan 2001 19:23:19 -0800 (PST) From: norm@wiregrass.com To: freebsd-gnats-submit@freebsd.org X-Send-Pr-Version: www-1.0 Subject: alpha/24170: Problem installing on Alpha Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 24170 >Category: alpha >Synopsis: Problem installing on Alpha >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-alpha >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Jan 08 19:30:01 PST 2001 >Closed-Date: >Last-Modified: >Originator: Norm McCaffery >Release: 4.2 >Organization: >Environment: N/A >Description: When trying to do a CD boot install on an Alpha, it comes up with a option list for "Serial console type". There isn't a serial console connected to the machine. This is an exact duplicate machine of another Alpha we loaded FreeBSD on last week. Anyone have any ideas on this? >How-To-Repeat: Boot from FreeBSD 4.2 install CD >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Jan 8 19:43: 6 2001 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 5939037B400 for ; Mon, 8 Jan 2001 19:42:48 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id WAA17458; Mon, 8 Jan 2001 22:42:38 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id f093gcq92868; Mon, 8 Jan 2001 22:42:38 -0500 (EST) (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, 8 Jan 2001 22:42:38 -0500 (EST) To: norm@wiregrass.com Cc: freebsd-alpha@freebsd.org Subject: Re: alpha/24170: Problem installing on Alpha In-Reply-To: <200101090323.f093NJp10125@freefall.freebsd.org> References: <200101090323.f093NJp10125@freefall.freebsd.org> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14938.34411.321981.712401@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org norm@wiregrass.com writes: > >Description: > When trying to do a CD boot install on an Alpha, it comes up with a option list for "Serial console type". There isn't a serial console connected to the machine. This is an exact duplicate machine of another Alpha we loaded FreeBSD on last week. Anyone have any ideas on this? > >How-To-Repeat: > Boot from FreeBSD 4.2 install CD > >Fix: > You failed to give any information regarding the type of machine you are installing onto. This makes us have to guess what your problem is from limited information.. In future reports, please include at least the model of the alpha and a brief description of the attached hardware. Show Conf output from the SRM console is prefered. Does it have a ZLXp- graphics adapter? (use show conf from the >>> SRM firmware prompt to determine this). If so, that adapter is not usable by the console code. You have 3 choices: 1) pull the ZLXp- card and plop in any random VGA card 2) set the console to serial. In the SRM console, do >>> set console serial >>> init You'll need a null modem (or a terminal) connected at 9600,8,n,1 3) try an alpha test version of the TGA driver. Its alpha-quality. Colors don't work, nor does the cursor, and it is glacially slow. If so, try http://www.cs.duke.edu/~gallatin/TGA/kern.tga.flp Assuming it works, after you've installed, grab http://www.cs.duke.edu/~gallatin/TGA/kernel.gz and replace /kernel with it. Otherwise you'll have the same "dead keyboard" symptom.. 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 Tue Jan 9 1:38:18 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from radicalmedia.com (radicalmedia.com [204.254.246.2]) by hub.freebsd.org (Postfix) with ESMTP id 7C58137B400 for ; Tue, 9 Jan 2001 01:37:59 -0800 (PST) Received: (from phiber@localhost) by radicalmedia.com (8.9.3/8.9.3) id EAA26431 for freebsd-alpha@freebsd.org; Tue, 9 Jan 2001 04:37:59 -0500 Date: Tue, 9 Jan 2001 04:37:59 -0500 From: Mark Abene To: freebsd-alpha@freebsd.org Subject: IPSEC Message-ID: <20010109043759.C24873@mail.radicalmedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've asked this question a while ago, but there were no answers... Has anyone tested IPSEC? And did they find any 64-bit broken-ness? Cheers, -Mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 9 2:10:22 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C96CE37B401 for ; Tue, 9 Jan 2001 02:10:01 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f09AA1Z67085; Tue, 9 Jan 2001 02:10:01 -0800 (PST) (envelope-from gnats) Received: from LikeEver.kjkoster.org (a213-84-15-12.adsl.xs4all.nl [213.84.15.12]) by hub.freebsd.org (Postfix) with ESMTP id D623F37B400 for ; Tue, 9 Jan 2001 02:03:16 -0800 (PST) Received: (from kjkoster@localhost) by LikeEver.kjkoster.org (8.11.1/8.9.3) id f09A3GI01173; Tue, 9 Jan 2001 11:03:16 +0100 (CET) (envelope-from kjkoster) Message-Id: <200101091003.f09A3GI01173@LikeEver.kjkoster.org> Date: Tue, 9 Jan 2001 11:03:16 +0100 (CET) From: dutchman@tccn.cs.kun.nl Reply-To: dutchman@tccn.cs.kun.nl To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: alpha/24177: Patch for fxp on Alpha Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 24177 >Category: alpha >Synopsis: Workaround patch for fxp on Alpha >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-alpha >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Tue Jan 09 02:10:01 PST 2001 >Closed-Date: >Last-Modified: >Originator: Kees Jan Koster >Release: FreeBSD 4.2-RC1 alpha >Organization: >Environment: FreeBSD slugout.kjkoster.org 4.2-RC1 FreeBSD 4.2-RC1 #1: Sat Jan 6 16:34:31 CET 2001 root@:/usr/src/sys/compile/SLUGOUT alpha >Description: The current fxp driver does not see some of the cards. In particular it does not see mine (Asus L101 card). It probes af follows: Jan 6 12:06:08 /kernel: fxp0: port 0x10100-0x1011f mem 0x81100000-0x811fffff,0x88000000-0x88000fff irq 5 at device 8.0 on pci0 Jan 6 12:06:08 /kernel: fxp0: interrupting at ISA irq 5 Jan 6 12:06:08 /kernel: fxp0: Ethernet address ff:ff:ff:ff:ff:ff, 10Mbps After the workaround that someone suggested (I plucked it off freebsd-alpha a while ago) the card probes as follows: Jan 6 19:39:04 /kernel: fxp0: port 0x10100-0x1011f mem 0x81100000-0x811fffff,0x88000000-0x88000fff irq 5 at device 8.0 on pci0 Jan 6 19:39:04 /kernel: fxp0: using i/o space access Jan 6 19:39:04 /kernel: fxp0: interrupting at ISA irq 5 Jan 6 19:39:04 /kernel: fxp0: Ethernet address 00:e0:18:00:2b:98 I realize that the workaround is not a complete fix. However, the current state of affairs means that I cannot install FreeBSD/alpha without special tricks. I was hoping that this workaround might be put into the kernel anyway, with proper warning comments. >How-To-Repeat: Use an fxp-driven card in an Alpha. >Fix: Index: if_fxp.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_fxp.c,v retrieving revision 1.77.2.6 diff -u -r1.77.2.6 if_fxp.c --- if_fxp.c 2000/07/19 14:36:36 1.77.2.6 +++ if_fxp.c 2000/07/25 18:53:08 @@ -515,6 +515,8 @@ return ENXIO; } +#define FXP_PREFER_IOSPACE + static int fxp_attach(device_t dev) { @@ -533,12 +535,31 @@ * Enable bus mastering. */ val = pci_read_config(dev, PCIR_COMMAND, 2); +#ifdef FXP_PREFER_IOSPACE /*XXX*/ + val |= (PCIM_CMD_PORTEN|PCIM_CMD_BUSMASTEREN); +#else val |= (PCIM_CMD_MEMEN|PCIM_CMD_BUSMASTEREN); +#endif pci_write_config(dev, PCIR_COMMAND, val, 2); /* * Map control/status registers. */ +#ifdef FXP_PREFER_IOSPACE /*XXX*/ + device_printf(dev, "using i/o space access\n"); + rid = FXP_PCI_IOBA; + sc->io = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, + 0, ~0, 1, RF_ACTIVE); + if (!sc->io) { + device_printf(dev, "could not map memory\n"); + error = ENXIO; + goto fail; + } + + sc->sc_st = rman_get_bustag(sc->io); + sc->sc_sh = rman_get_bushandle(sc->io); + +#else rid = FXP_PCI_MMBA; sc->mem = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, 0, ~0, 1, RF_ACTIVE); @@ -550,7 +571,7 @@ sc->sc_st = rman_get_bustag(sc->mem); sc->sc_sh = rman_get_bushandle(sc->mem); - +#endif /* * Allocate our interrupt. */ @@ -575,7 +596,11 @@ /* Failed! */ bus_teardown_intr(dev, sc->irq, sc->ih); bus_release_resource(dev, SYS_RES_IRQ, 0, sc->irq); +#ifdef FXP_PREFER_IOSPACE /* XXX */ bus_release_resource(dev, SYS_RES_MEMORY, FXP_PCI_MMBA, sc->mem); +#else + bus_release_resource(dev, SYS_RES_IOPORT, FXP_PCI_IOBA, sc->io); +#endif error = ENXIO; goto fail; } @@ -639,8 +664,11 @@ */ bus_teardown_intr(dev, sc->irq, sc->ih); bus_release_resource(dev, SYS_RES_IRQ, 0, sc->irq); +#ifdef FXP_PREFER_IOSPACE /* XXX */ + bus_release_resource(dev, SYS_RES_IOPORT, FXP_PCI_IOBA, sc->io); +#else bus_release_resource(dev, SYS_RES_MEMORY, FXP_PCI_MMBA, sc->mem); - +#endif /* * Free all the receive buffers. */ Index: if_fxpvar.h =================================================================== RCS file: /home/ncvs/src/sys/pci/if_fxpvar.h,v retrieving revision 1.9.2.1 diff -u -r1.9.2.1 if_fxpvar.h --- if_fxpvar.h 2000/03/29 02:02:39 1.9.2.1 +++ if_fxpvar.h 2000/07/25 18:28:23 @@ -46,6 +46,7 @@ #else struct arpcom arpcom; /* per-interface network data */ struct resource *mem; /* resource descriptor for registers */ + struct resource *io; /* resource descriptor for registers */ struct resource *irq; /* resource descriptor for interrupt */ void *ih; /* interrupt handler cookie */ #endif /* __NetBSD__ */ >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 9 9:50:28 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 96C9437B6D4 for ; Tue, 9 Jan 2001 09:50:02 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f09Ho2V05557; Tue, 9 Jan 2001 09:50:02 -0800 (PST) (envelope-from gnats) Date: Tue, 9 Jan 2001 09:50:02 -0800 (PST) Message-Id: <200101091750.f09Ho2V05557@freefall.freebsd.org> To: freebsd-alpha@freebsd.org Cc: From: Matthew Jacob Subject: Re: alpha/24177: Patch for fxp on Alpha Reply-To: Matthew Jacob Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR alpha/24177; it has been noted by GNATS. From: Matthew Jacob To: dutchman@tccn.cs.kun.nl Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: alpha/24177: Patch for fxp on Alpha Date: Tue, 9 Jan 2001 09:41:02 -0800 (PST) You don't say which specific platform this is. It's unusual that I/O space works better than Memory space. It's also true that various flavors of EEPRO are known to work. I sure wish I knew whether the maintainer for this card s active or not on this. I think your patches are in the right direction, but aren't really quite what we should be looking for- they could be a lot tighter and should be runtime as opposed to compile time settable- see isp_pci.c for an example (not the best, granted) of this. I sure would like to know which platform this was. -matt > > >Number: 24177 > >Category: alpha > >Synopsis: Workaround patch for fxp on Alpha > >Confidential: no > >Severity: non-critical > >Priority: medium > >Responsible: freebsd-alpha > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: change-request > >Submitter-Id: current-users > >Arrival-Date: Tue Jan 09 02:10:01 PST 2001 > >Closed-Date: > >Last-Modified: > >Originator: Kees Jan Koster > >Release: FreeBSD 4.2-RC1 alpha > >Organization: > >Environment: > > FreeBSD slugout.kjkoster.org 4.2-RC1 FreeBSD 4.2-RC1 #1: Sat Jan 6 16:34:31 CET 2001 root@:/usr/src/sys/compile/SLUGOUT alpha > > >Description: > > The current fxp driver does not see some of the cards. In particular it does > not see mine (Asus L101 card). It probes af follows: > > Jan 6 12:06:08 /kernel: fxp0: port 0x10100-0x1011f mem 0x81100000-0x811fffff,0x88000000-0x88000fff irq 5 at device 8.0 on pci0 > Jan 6 12:06:08 /kernel: fxp0: interrupting at ISA irq 5 > Jan 6 12:06:08 /kernel: fxp0: Ethernet address ff:ff:ff:ff:ff:ff, 10Mbps > > After the workaround that someone suggested (I plucked it off freebsd-alpha a > while ago) the card probes as follows: > > Jan 6 19:39:04 /kernel: fxp0: port 0x10100-0x1011f mem 0x81100000-0x811fffff,0x88000000-0x88000fff irq 5 at device 8.0 on pci0 > Jan 6 19:39:04 /kernel: fxp0: using i/o space access > Jan 6 19:39:04 /kernel: fxp0: interrupting at ISA irq 5 > Jan 6 19:39:04 /kernel: fxp0: Ethernet address 00:e0:18:00:2b:98 > > I realize that the workaround is not a complete fix. However, the current state > of affairs means that I cannot install FreeBSD/alpha without special tricks. I > was hoping that this workaround might be put into the kernel anyway, with > proper warning comments. > > >How-To-Repeat: > > Use an fxp-driven card in an Alpha. > > >Fix: > > Index: if_fxp.c > =================================================================== > RCS file: /home/ncvs/src/sys/pci/if_fxp.c,v > retrieving revision 1.77.2.6 > diff -u -r1.77.2.6 if_fxp.c > --- if_fxp.c 2000/07/19 14:36:36 1.77.2.6 > +++ if_fxp.c 2000/07/25 18:53:08 > @@ -515,6 +515,8 @@ > return ENXIO; > } > > +#define FXP_PREFER_IOSPACE > + > static int > fxp_attach(device_t dev) > { > @@ -533,12 +535,31 @@ > * Enable bus mastering. > */ > val = pci_read_config(dev, PCIR_COMMAND, 2); > +#ifdef FXP_PREFER_IOSPACE /*XXX*/ > + val |= (PCIM_CMD_PORTEN|PCIM_CMD_BUSMASTEREN); > +#else > val |= (PCIM_CMD_MEMEN|PCIM_CMD_BUSMASTEREN); > +#endif > pci_write_config(dev, PCIR_COMMAND, val, 2); > > /* > * Map control/status registers. > */ > +#ifdef FXP_PREFER_IOSPACE /*XXX*/ > + device_printf(dev, "using i/o space access\n"); > + rid = FXP_PCI_IOBA; > + sc->io = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, > + 0, ~0, 1, RF_ACTIVE); > + if (!sc->io) { > + device_printf(dev, "could not map memory\n"); > + error = ENXIO; > + goto fail; > + } > + > + sc->sc_st = rman_get_bustag(sc->io); > + sc->sc_sh = rman_get_bushandle(sc->io); > + > +#else > rid = FXP_PCI_MMBA; > sc->mem = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, > 0, ~0, 1, RF_ACTIVE); > @@ -550,7 +571,7 @@ > > sc->sc_st = rman_get_bustag(sc->mem); > sc->sc_sh = rman_get_bushandle(sc->mem); > - > +#endif > /* > * Allocate our interrupt. > */ > @@ -575,7 +596,11 @@ > /* Failed! */ > bus_teardown_intr(dev, sc->irq, sc->ih); > bus_release_resource(dev, SYS_RES_IRQ, 0, sc->irq); > +#ifdef FXP_PREFER_IOSPACE /* XXX */ > bus_release_resource(dev, SYS_RES_MEMORY, FXP_PCI_MMBA, sc->mem); > +#else > + bus_release_resource(dev, SYS_RES_IOPORT, FXP_PCI_IOBA, sc->io); > +#endif > error = ENXIO; > goto fail; > } > @@ -639,8 +664,11 @@ > */ > bus_teardown_intr(dev, sc->irq, sc->ih); > bus_release_resource(dev, SYS_RES_IRQ, 0, sc->irq); > +#ifdef FXP_PREFER_IOSPACE /* XXX */ > + bus_release_resource(dev, SYS_RES_IOPORT, FXP_PCI_IOBA, sc->io); > +#else > bus_release_resource(dev, SYS_RES_MEMORY, FXP_PCI_MMBA, sc->mem); > - > +#endif > /* > * Free all the receive buffers. > */ > Index: if_fxpvar.h > =================================================================== > RCS file: /home/ncvs/src/sys/pci/if_fxpvar.h,v > retrieving revision 1.9.2.1 > diff -u -r1.9.2.1 if_fxpvar.h > --- if_fxpvar.h 2000/03/29 02:02:39 1.9.2.1 > +++ if_fxpvar.h 2000/07/25 18:28:23 > @@ -46,6 +46,7 @@ > #else > struct arpcom arpcom; /* per-interface network data */ > struct resource *mem; /* resource descriptor for registers */ > + struct resource *io; /* resource descriptor for registers */ > struct resource *irq; /* resource descriptor for interrupt */ > void *ih; /* interrupt handler cookie */ > #endif /* __NetBSD__ */ > > > >Release-Note: > >Audit-Trail: > >Unformatted: > > > 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 Tue Jan 9 10:50:21 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 52D3937B698 for ; Tue, 9 Jan 2001 10:50:04 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f09Io4V14069; Tue, 9 Jan 2001 10:50:04 -0800 (PST) (envelope-from gnats) Date: Tue, 9 Jan 2001 10:50:04 -0800 (PST) Message-Id: <200101091850.f09Io4V14069@freefall.freebsd.org> To: freebsd-alpha@freebsd.org Cc: From: Kees Jan Koster Subject: Re: alpha/24177: Patch for fxp on Alpha Reply-To: Kees Jan Koster Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR alpha/24177; it has been noted by GNATS. From: Kees Jan Koster To: mjacob@feral.com Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: alpha/24177: Patch for fxp on Alpha Date: Tue, 09 Jan 2001 19:46:26 +0100 > > You don't say which specific platform this is. It's unusual that I/O space > works better than Memory space. It's also true that various flavors of EEPRO > are known to work. > D'oh! I keep forgetting Alpha's aren't PC's. :) Here's the relevant dmesg snippet. DEC AXPpci Alpha PC AXPpci33, 166MHz 8192 byte page size, 1 processor. CPU: LCA Family major=4 minor=2 OSF PAL rev: 0x100090002012d I apologize for not including this information immediately. > > I sure wish I knew whether the maintainer for this card s active or not on > this. I think your patches are in the right direction, but aren't really quite > what we should be looking for- they could be a lot tighter and should be > runtime as opposed to compile time settable- see isp_pci.c for an example (not > the best, granted) of this. > These are not my own patches. I reported this problem earlier on freebsd-alpha and in the resulting discussion these patches came up. I tried them and they worked for me. The discussion was in the "fxp0 hangs on a PC164 using STABLE" and the "fxp0 hangs my AXPpci33" threads, on freebsd-alpha around July 2000. At the time they were not committed because of their hackish nature, as you have noted yourself. Someone hinted that he was going to rework them in a more socially acceptable manner, but his time seems to have been claimed by more important matters. Since this was months ago I figured that I should try to get the patch committed. Yours, Kees Jan ------------------------------------------------------------------ Kees Jan Koster e-mail: dutchman "at" tccn.cs.kun.nl www: http://www.kjkoster.org/ ------------------------------------------------------------------ You're only young once, but you can stay immature all your life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 9 11: 0:22 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 4206237B402 for ; Tue, 9 Jan 2001 11:00:02 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f09J02q15286; Tue, 9 Jan 2001 11:00:02 -0800 (PST) (envelope-from gnats) Date: Tue, 9 Jan 2001 11:00:02 -0800 (PST) Message-Id: <200101091900.f09J02q15286@freefall.freebsd.org> To: freebsd-alpha@freebsd.org Cc: From: Matthew Jacob Subject: Re: alpha/24177: Patch for fxp on Alpha Reply-To: Matthew Jacob Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR alpha/24177; it has been noted by GNATS. From: Matthew Jacob To: Kees Jan Koster Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: alpha/24177: Patch for fxp on Alpha Date: Tue, 9 Jan 2001 10:51:36 -0800 (PST) On Tue, 9 Jan 2001, Kees Jan Koster wrote: > > > > You don't say which specific platform this is. It's unusual that I/O space > > works better than Memory space. It's also true that various flavors of EEPRO > > are known to work. > > > D'oh! I keep forgetting Alpha's aren't PC's. :) Here's the relevant > dmesg snippet. > > DEC AXPpci > Alpha PC AXPpci33, 166MHz > 8192 byte page size, 1 processor. > CPU: LCA Family major=4 minor=2 > OSF PAL rev: 0x100090002012d > > I apologize for not including this information immediately. No, that's fine... I just needed to know. You know, I'd forgotten about LCA- that probably is the only PCI chipset for alphas where I/O space is more functional than Memory space. > > > > > I sure wish I knew whether the maintainer for this card s active or not on > > this. I think your patches are in the right direction, but aren't really quite > > what we should be looking for- they could be a lot tighter and should be > > runtime as opposed to compile time settable- see isp_pci.c for an example (not > > the best, granted) of this. > > > These are not my own patches. I reported this problem earlier on > freebsd-alpha and in the resulting discussion these patches came up. I > tried them and they worked for me. The discussion was in the "fxp0 hangs > on a PC164 using STABLE" and the "fxp0 hangs my AXPpci33" threads, on > freebsd-alpha around July 2000. > > At the time they were not committed because of their hackish nature, as > you have noted yourself. Someone hinted that he was going to rework them > in a more socially acceptable manner, but his time seems to have been > claimed by more important matters. Since this was months ago I figured > that I should try to get the patch committed. Was the driver author gonna do this? Who? Yes, it should be done. I could probably even get to it myself- but not if somebody else is on it. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 9 11:10:23 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 465E637B69D for ; Tue, 9 Jan 2001 11:10:04 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f09JA4H18064; Tue, 9 Jan 2001 11:10:04 -0800 (PST) (envelope-from gnats) Date: Tue, 9 Jan 2001 11:10:04 -0800 (PST) Message-Id: <200101091910.f09JA4H18064@freefall.freebsd.org> To: freebsd-alpha@freebsd.org Cc: From: Kees Jan Koster Subject: Re: alpha/24177: Patch for fxp on Alpha Reply-To: Kees Jan Koster Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR alpha/24177; it has been noted by GNATS. From: Kees Jan Koster To: mjacob@feral.com Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: alpha/24177: Patch for fxp on Alpha Date: Tue, 09 Jan 2001 20:08:17 +0100 > > You know, I'd forgotten about LCA- that probably is the only PCI chipset for > alphas where I/O space is more functional than Memory space. > At the very least for my card. :-) > > Was the driver author gonna do this? Who? Yes, it should be done. I could > probably even get to it myself- but not if somebody else is on it. > I don't know. The author is David Greenman , I will ask him. Yours, Kees Jan ------------------------------------------------------------------ Kees Jan Koster e-mail: dutchman "at" tccn.cs.kun.nl www: http://www.kjkoster.org/ ------------------------------------------------------------------ You're only young once, but you can stay immature all your life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Jan 9 17:40: 5 2001 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 AAA6137B400 for ; Tue, 9 Jan 2001 17:39:46 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id UAA07431; Tue, 9 Jan 2001 20:39:40 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id f0A1ddp95073; Tue, 9 Jan 2001 20:39:39 -0500 (EST) (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, 9 Jan 2001 20:39:39 -0500 (EST) To: Peter Wemm Cc: Wilko Bulte , freebsd-alpha@FreeBSD.ORG Subject: Re: debugging fpa / FDDI panic In-Reply-To: <200101062231.f06MVCq68942@mobile.wemm.org> References: <14935.34600.806565.787237@grasshopper.cs.duke.edu> <200101062231.f06MVCq68942@mobile.wemm.org> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14939.47709.724577.4054@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Wemm writes: > > Actually, what I think we should be doing is the same as how the interrupt > resources are handled... ie: seperate allocation and activation. > > ie: res = bus_alloc_resource(dev, SYS_RES_IRQ, ....) > bus_setup_intr(dev, res, flags, irqhandler, handlerargs, &irqhandle); > > IMHO, we should do the same with memory and IO space. > we presently have: > res = bus_alloc_resource(dev, SYS_RES_MEMORY, ...., RF_ACTIVE|magic_flags); > va = rman_get_virtual(res); > IMHO, this is wrong. We are allocating space within the scope of the bus > and expecting it to silently appear in CPU addressable space and then use > backdoor methods to grab it. > > I think it would be better like this: > > res = bus_alloc_resource(dev, SYS_RES_MEMORY, .... RF_ACTIVE) > bus_map_space(dev, res, magicflags, &bushandle, &bustag, &mappinghandle); > > or something along those lines. > > The allocation would be to reserve the space in the bus, and the > bus_map_space() would be to arrange for it to appear into CPU addressable > space, get the handles, choose convenient mapping modes (dense or sparse - > this is a CPU/core chipset *mapping* property, not a "pci bus resource" > property). The pci space on the alphas appears in several forms in the CPU > space. <...> I think I agree with you for the most part. Layering violations don't concern me as much as they probably should. The only caveat that I have is that the "magicflags" should not be platform dependent. A reasonably well written driver should work without the author having to or in different flags for each platform. Eg, there should be something like RF_MEMORYLIKE and RF_BUSLIKE. (Bad names, I know). RF_MEMORYLIKE means your going to treat the space like memory and do loads/stores from/to it (bad practice, but damned convenient sometimes). RF_BUSLIKE means you promise to go through the buspace interfaces. My main objection is rman_get_virtual() returning an address which will cause a memory management fault if you load or store from/to it on an alpha. This is a big POLA for a driver author. :-( Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 11 5:18:42 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from odin.mdacc.tmc.edu (odin.mdacc.tmc.edu [143.111.62.32]) by hub.freebsd.org (Postfix) with ESMTP id 289FA37B400 for ; Thu, 11 Jan 2001 05:18:22 -0800 (PST) Received: from odin.mdacc.tmc.edu by odin.mdacc.tmc.edu (8.8.8/1.1.10.5/14Dec97-1032AM) id HAA0000021579; Thu, 11 Jan 2001 07:18:08 -0600 (CST) Message-ID: <3A5DB2BF.E88BD078@odin.mdacc.tmc.edu> Date: Thu, 11 Jan 2001 07:18:55 -0600 From: Sylvain Laroche Organization: UT M.D. Anderson Cancer Center X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-alpha@freebsd.org Subject: Installation Problem on AlphaStation 200 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I'm trying to install FreeBSD 4.2 on an AlphaStation 200 4/100. I can get the computer to start booting from the CD-ROM, using "boot dka500", but once it gets to "Booting [kernel]..." it just stalls and nothing more happens. no sign of cd or hard disk activity either. are there some commands i need to issue from the SRM prompt before i should try to boot from the CD? Or are there flags or options i'm missing in the boot command? I'm using keyboard and monitor, not serial console. Any help would be greatly appreciated! Sylvain Laroche Department of Biostatistics M.D. Anderson Cancer Center Houston, TX Email: laroche@mdanderson.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Jan 11 6:11:39 2001 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 769E037B400 for ; Thu, 11 Jan 2001 06:11:22 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id JAA08458; Thu, 11 Jan 2001 09:11:21 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id f0BEBLd01674; Thu, 11 Jan 2001 09:11:21 -0500 (EST) (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, 11 Jan 2001 09:11:20 -0500 (EST) To: Sylvain Laroche Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: Installation Problem on AlphaStation 200 In-Reply-To: <3A5DB2BF.E88BD078@odin.mdacc.tmc.edu> References: <3A5DB2BF.E88BD078@odin.mdacc.tmc.edu> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14941.48605.912263.551659@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sylvain Laroche writes: > Hi, > > I'm trying to install FreeBSD 4.2 on an AlphaStation 200 4/100. I can > get the computer to start booting from the CD-ROM, using "boot dka500", > but once it gets to > "Booting [kernel]..." it just stalls and nothing more happens. no sign > of cd or hard disk activity either. are there some commands i need to > issue from the SRM prompt before i should try to boot from the CD? Or > are there flags or options i'm missing in the boot command? > > I'm using keyboard and monitor, not serial console. > > Any help would be greatly appreciated! One possibility is that your firmware console setting does not match reality. From the SRM console, issue the command: >>> show console If it is set to serial & you're using a graphics head, try setting it to graphics: >>> set console graphics >>> init Or vice-versa if you're using a serial console and it is set to graphics. Another possability that comes to mind is that you're using an unsupported display adapter. If the above doesn't work, please reply with the output of 'show conf' from the SRM console. 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 Jan 13 1:18:53 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from grafin.fujimori.cache.waseda.ac.jp (grafin.fujimori.cache.waseda.ac.jp [133.9.152.154]) by hub.freebsd.org (Postfix) with ESMTP id 886F737B400 for ; Sat, 13 Jan 2001 01:18:35 -0800 (PST) Received: from grafin.fujimori.cache.waseda.ac.jp (fujimori@localhost [127.0.0.1]) by grafin.fujimori.cache.waseda.ac.jp (8.9.3/3.7W) with ESMTP id SAA25842 for ; Sat, 13 Jan 2001 18:18:32 +0900 Message-Id: <200101130918.SAA25842@grafin.fujimori.cache.waseda.ac.jp> To: freebsd-alpha@freebsd.org Subject: Y2K on alphapc164? Date: Sat, 13 Jan 2001 18:18:32 +0000 From: Yoriaki FUJIMORI Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear folks, I am running a few alphapc164 boxes, and one of them runs FreeBSD4.2R. The other day I rebooted this FreeBSD box, and noticed that the boottime date is like `Jan 13, JST 2000.' The system does not know it is 2001! I checked other alphapc164 boxes running Tru64, and they are al'right. The SRM version of the box is the latest one, I believe, v5.5 I got by ftp from gatekeeper.dec.com. Now, I am running `xntpd -g', so that the system time is fixed. But, is there any way to fix the hardware clock from within FreeBSD? Thanks for your attention. Best wishes, Yoriaki FUJIMORI To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message