From owner-freebsd-alpha Tue Dec 10 11:28: 4 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76BFB37B401 for ; Tue, 10 Dec 2002 11:28:01 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9F7E43E4A for ; Tue, 10 Dec 2002 11:28:00 -0800 (PST) (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.3/8.9.3) with ESMTP id OAA10612; Tue, 10 Dec 2002 14:28:00 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id gBAJRUF04575; Tue, 10 Dec 2002 14:27:30 -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 Message-ID: <15862.16418.170931.930192@grasshopper.cs.duke.edu> Date: Tue, 10 Dec 2002 14:27:30 -0500 (EST) To: oliver Cc: Subject: Re: AlphaServer1200 (5305), FBSD4.7 and Symbios53C875 In-Reply-To: References: <15862.664.705642.80134@grasshopper.cs.duke.edu> 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 oliver writes: > Drew, > > Here is the "rman output": Thanks. Sorry to make you do this, but at least it let me see the problem. I've highlighted the interesting bits below. It turns out that the problem is with the SRM console, or the hardware. sym1's memory size (0x2000) is exactly 2x what it (probably) should be, and it starts only 0x1000 below the mem range allocated for sym1. So its colliding with the memory range by sym2 in the region 0x7d9f000-0x7d9ffff. The freebsd rman resource manager is noticing this, and failing to attach a device in the disputed region. This is not a FreeBSD bug, its FreeBSD being a bit paranoid and (maybe) saving your butt from a bad hardware config. I'd try for different SRM console versions, and/or firmware updates to the board with the scsi controllers on them. As a last resort, you might be able to hack the sym driver: Index: sym/sym_hipd.c =================================================================== RCS file: /home/ncvs/src/sys/dev/sym/sym_hipd.c,v retrieving revision 1.36 diff -u -r1.36 sym_hipd.c --- sym/sym_hipd.c 16 Oct 2002 08:48:38 -0000 1.36 +++ sym/sym_hipd.c 10 Dec 2002 19:24:46 -0000 @@ -9209,7 +9209,7 @@ if ((command & PCIM_CMD_MEMEN) != 0) { int regs_id = SYM_PCI_MMIO; np->mmio_res = bus_alloc_resource(dev, SYS_RES_MEMORY, ®s_id, - 0, ~0, 1, RF_ACTIVE); + 0, ~0, 1, RF_ACTIVE | RF_SHARABLE); } if (!np->mmio_res) { device_printf(dev, "failed to allocate MMIO resources\n"); This is totally unsafe, unsupported, and not at all recommended. It could result in the system failing in a spectacular way, and you loosing data on any disk connected to any sym interface. Drew > map[10]: type 4, range 32, base 01fffd00, size 8, enabled > map[14]: type 1, range 32, base 07d9dd00, size 8, enabled > map[18]: type 1, range 32, base 07d9e000, size 13, enabled ....................................................^^^^^^ > found-> vendor=0x1000, dev=0x000f, revid=0x04 > bus=2, slot=0, func=0 > class=01-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0107, statreg=0x0200, cachelnsz=16 (dwords) > lattimer=0xff (7650 ns), mingnt=0x11 (4250 ns), maxlat=0x40 (16000 ns) > intpin=a, irq=8 > map[10]: type 4, range 32, base 01fffe00, size 8, enabled > map[14]: type 1, range 32, base 07d9de00, size 8, enabled > map[18]: type 1, range 32, base 07d9f000, size 12, enabled ....................................................^^^^^^ <...> > sym1: <875> port 0x1fffd00-0x1fffdff mem > 0x7d9e000-0x7d9ffff,0x7d9dd00-0x7d9ddff irq 8 at device 0.0 on pci2 <...> > pcib2: device sym1 requested decoded memory range 0x7d9e000-0x7d9ffff > rman_reserve_resource: request: [0x7d9e000, 0x7d9ffff], length > 0x2000, flags 2, device sym1 ....^^^^^ > considering [0x7d9de00, 0x100000000] > truncated region: [0x7d9e000, 0x7da0000]; size 0x2001 (requested 0x2000) > candidate region: [0x7da0000, 0x7d9e000], size 0x2001 > splitting region in three parts: [0x7d9de00, 0x7d9dfff]; [0x7d9e000, > 0x7d9ffff]; [0x7da0000, 0x100000000] <...> > sym2: <875> port 0x1fffe00-0x1fffeff mem > 0x7d9f000-0x7d9ffff,0x7d9de00-0x7d9deff irq 9 at device 1.0 on pci2 <...> > pcib2: device sym2 requested decoded memory range 0x7d9f000-0x7d9ffff > rman_reserve_resource: request: [0x7d9f000, 0x7d9ffff], length > 0x1000, flags 2, device sym2 ....^^^^^ > considering [0x7d9e000, 0x7d9ffff] > region is allocated > considering [0x7da0000, 0x100000000] > s->r_start (0x7da0000) > end (0x7d9ffff) > no unshared regions found > sym2: failed to allocate RAM resources To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message