Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Jun 2015 03:11:23 +0000
From:      Twitter <verify@twitter.com>
To:        Cijos Dianthus <freebsd-sparc64@hub.freebsd.org>
Subject:   Confirm your Twitter account, Cijos Dianthus
Message-ID:  <45.96.40539.B5CF8755@twitter.com>

next in thread | raw e-mail | index | archive | help
Cijos Dianthus,

Confirm your email address to complete your Twitter account. It's easy - just click on the button below.

Click on the link below or copy and paste it into a browser:

https://twitter.com/i/redirect?url=https%3A%2F%2Ftwitter.com%2Faccount%2Fconfirm_user_email%2F3318327491%2F93H39-D3CCF-143399%3Ft%3D1%26cn%3DZW1haWxfY29uZmlybV9pbml0%26sig%3D66f0389e6af45751bc46f223b42469bed34f606a%26al%3D1%26iid%3Db3af625ff9904dea8df58793674e3f47%26ac%3D1%26autoactions%3D1433992283%26uid%3D3318327491%26nid%3D244%2B308&amp;t=1&amp;cn=ZW1haWxfY29uZmlybV9pbml0&amp;sig=28a7e0760db245ab279b78bdb039e3fad80fabdd&amp;iid=b3af625ff9904dea8df58793674e3f47&amp;uid=3318327491&amp;nid=244+308
From owner-freebsd-sparc64@FreeBSD.ORG  Fri Jun 12 13:20:47 2015
Return-Path: <owner-freebsd-sparc64@FreeBSD.ORG>
Delivered-To: freebsd-sparc64@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 514A653D
 for <freebsd-sparc64@hub.freebsd.org>; Fri, 12 Jun 2015 13:20:47 +0000 (UTC)
 (envelope-from jhb@FreeBSD.org)
Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1])
 (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 29E7314EE
 for <freebsd-sparc64@freebsd.org>; Fri, 12 Jun 2015 13:20:47 +0000 (UTC)
 (envelope-from jhb@FreeBSD.org)
Received: from John-Baldwins-MacBook-Pro-2.local (unknown [137.122.64.8])
 by bigwig.baldwin.cx (Postfix) with ESMTPSA id 38130B939
 for <freebsd-sparc64@freebsd.org>; Fri, 12 Jun 2015 09:20:45 -0400 (EDT)
Message-ID: <557ADCAB.9020409@FreeBSD.org>
Date: Fri, 12 Jun 2015 09:20:43 -0400
From: John Baldwin <jhb@FreeBSD.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: freebsd-sparc64@freebsd.org
Subject: Re: PCI range checking under qemu-system-sparc64
References: <53F73E6F.9080805@ilande.co.uk>
 <2084808.1lxSgnvf69@ralph.baldwin.cx>
In-Reply-To: <2084808.1lxSgnvf69@ralph.baldwin.cx>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
 (bigwig.baldwin.cx); Fri, 12 Jun 2015 09:20:45 -0400 (EDT)
X-BeenThere: freebsd-sparc64@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Porting FreeBSD to the Sparc <freebsd-sparc64.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-sparc64>, 
 <mailto:freebsd-sparc64-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-sparc64/>;
List-Post: <mailto:freebsd-sparc64@freebsd.org>
List-Help: <mailto:freebsd-sparc64-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64>,
 <mailto:freebsd-sparc64-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2015 13:20:47 -0000

On 9/4/14 11:55 AM, John Baldwin wrote:
> On Friday, August 22, 2014 01:58:23 PM Mark Cave-Ayland wrote:
>> Hi all,
>>
>> I'm currently working on a set of patches to enable FreeBSD to boot in
>> -nographic mode under qemu-system-sparc64 and I've just come across the
>> following error during boot:
>>
>>
>> Booting [/boot/kernel/kernel]...
>> jumping to kernel entry at 0xc00a0000.
>> Copyright (c) 1992-2014 The FreeBSD Project.
>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>          The Regents of the University of California. All rights reserved.
>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>> FreeBSD 10.0-RELEASE #0 r260789: Fri Jan 17 11:37:19 UTC 2014
>>      root@snap.freebsd.org:/usr/obj/sparc64.sparc64/usr/src/sys/GENERIC
>> sparc64
>> gcc version 4.2.1 20070831 patched [FreeBSD]
>> real memory  = 134217728 (128 MB)
>> avail memory = 106053632 (101 MB)
>> cpu0: Sun Microsystems UltraSparc-IIi Processor (100.00 MHz CPU)
>> random device not loaded; using insecure entropy
>> random: <Software, Yarrow> initialized
>> kbd0 at kbdmux0
>> nexus0: <Open Firmware Nexus device>
>> nexus0: <builtin>: incomplete
>> pcib0: <U2P UPA-PCI bridge> mem 0x1fe00000000-0x1fe01ffffff irq
>> 2032,2030,2031,2021 on nexus0
>> pcib0: Sabre, impl 0, version 0, IGN 0x1f, bus A, 33MHz
>> panic: psycho_attach: unsupported number of ranges
>> cpuid = 0
>> KDB: stack backtrace:
>> #0 0xc085db60 at psycho_attach+0x780
>> #1 0xc0569dd8 at device_attach+0x518
>> #2 0xc056b4e8 at device_probe_and_attach+0x28
>> #3 0xc056b510 at bus_generic_attach+0x10
>> #4 0xc087704c at nexus_attach+0x58c
>> #5 0xc0569dd8 at device_attach+0x518
>> #6 0xc056b4e8 at device_probe_and_attach+0x28
>> #7 0xc056b87c at bus_generic_new_pass+0x11c
>> #8 0xc056aeb8 at bus_set_pass+0xf8
>> #9 0xc056af08 at root_bus_configure+0x8
>> #10 0xc086a9a4 at configure+0x4
>> #11 0xc04d4e3c at mi_startup+0x1dc
>> #12 0xc00a0028 at btext+0x28
>> Uptime: 1s
>>
>>
>> Having a look at the source it looks like we're being tripped by the
>> following check in psycho.c:
>>
>>
>>        /*
>>         * Make sure that the expected ranges are present.  The
>>         * OFW_PCI_CS_MEM64 one is not currently used though.
>>         */
>>        if (i != PSYCHO_NRANGE)
>>                panic("%s: unsupported number of ranges", __func__);
>>
>>
>> Now it seems that this occurs because OpenBIOS currently only supports
>> 32-bit PCI memory space (and so doesn't generate the 64-bit PCI memory
>> space entry withing the corresponding property).
>>
>> I could alter OpenBIOS to add a dummy 64-bit PCI memory space entry to
>> the end of the ranges property, however this particular check does seem
>> to be rather excessive and it is also slightly disingenuous to have
>> OpenBIOS include a declaration for a memory space that it cannot use
>> (plus it seems from the comment above that FreeBSD can't actually use it
>> anyway?!).
>>
>> Does anyone know why this particular assertion was added and what it's
>> actually trying to guard against?
> 
> I suspect it was added out of an abundance of caution based on whatever real 
> hardware it has run on.  You can try this (untested) change:

FYI, I was able to test my earlier patch and have posted an updated patch for
review.  In my case the system appears to hang before it goes into single user
mode both in graphics mode and with -nographic.

https://reviews.freebsd.org/D2791

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45.96.40539.B5CF8755>