Date: Tue, 10 Dec 2002 11:36:05 -0800 From: oliver <opml@terraflux.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: <freebsd-alpha@freebsd.org> Subject: Re: AlphaServer1200 (5305), FBSD4.7 and Symbios53C875 Message-ID: <BA1B8225.5BA%opml@terraflux.com> In-Reply-To: <15862.16418.170931.930192@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Drew,
So, it allocates sym1. I am not using the sym2 portion (and not intend to).
Can I get by with this? Or does this affect the drive (label partition
issue)?
Is the Disk Label Editor a separate issue? I will try and get an older SRM
release. Anybody have one??
Thanks again for all your help.
Cheers,
Oliver
On 12/10/02 11:27, "Andrew Gallatin" <gallatin@cs.duke.edu> wrote:
>
> 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: <I/O memory> 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: <I/O memory> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BA1B8225.5BA%opml>