From owner-freebsd-alpha Fri Aug 31 21:37:55 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 C811E37B425 for ; Fri, 31 Aug 2001 21:37:42 -0700 (PDT) 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 AAA00538; Sat, 1 Sep 2001 00:37:30 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f814b2494385; Sat, 1 Sep 2001 00:37:02 -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 Message-ID: <15248.26093.985320.772619@grasshopper.cs.duke.edu> Date: Sat, 1 Sep 2001 00:37:01 -0400 (EDT) To: Jim Pirzyk Cc: Wilko Bulte , freebsd-alpha@FreeBSD.ORG Subject: Re: XFree86-4 and alpha DS10 In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "hmmm" Since this works for me, I'm assuming it must be a problem specific to the tsunami. I don't suppose either of you has an X log from your attempt to start the X server? Even starting it remotely and saving the output of your ssh session would be helpful. Anyway, do you see it reporting ****INVALID MEM ALLOCATION*** in the log? If so, I've seen a similar problem on my UP1000 where the X server was too smart and tried to remap the AGP video card into space reserved for something else.. Its usually bad news when the X server tries to change the mapping. One blind shot in the dark is to change xc/programs/Xserver/hw/xfree86/os-support/bsd/bsdResource.c's xf86PciBusAccWindowsFromOS(void) RANGE to allow everything, like Linux's: Eg, make it look like this: resPtr xf86PciBusAccWindowsFromOS(void) { resPtr ret = NULL; resRange range; /* * Only allow the upper half of the pci memory range to be used * for allocation. The lower half includes magic regions for DMA. * XXX this is not right for XP1000's and similar where we use the * region 0x40000000-0xbfffffff for DMA but this only matters if * the bios screws up the pci region mappings. */ RANGE(range, 0x00000000, 0xffffffff, ResExcMemBlock); ret = xf86AddResToList(ret, &range, -1); RANGE(range, 0x00000000, 0xffffffff, ResExcIoBlock); ret = xf86AddResToList(ret, &range, -1); return ret; } Let me know if that helps. I'll be out of town all next week, so if we can iterate about this over the weekend that would be great. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message