Date: Sun, 08 Mar 2015 09:52:09 -0700 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: freebsd-ppc@freebsd.org Subject: Re: 10.1-STABLE kern.vty=vt crashes PowerMac G5 extremely early in boot for 2560x1440 display... Message-ID: <54FC7E39.3010602@freebsd.org> In-Reply-To: <8B7B5167-0C94-4BA3-9515-B4CB8A817BDB@dsl-only.net> References: <8B7B5167-0C94-4BA3-9515-B4CB8A817BDB@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Could you please try -CURRENT? vt itself at least works fine there, but I'm not sure anyone has tested it with such a large display on any platform. -Nathan On 03/08/15 03:22, Mark Millard wrote: > Basic context: > > $ freebsd-version -ku; uname -a > 10.1-STABLE > 10.1-STABLE > FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar 6 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc powerpc > > > The crash details (X11 is not part of the context, just console use): > > I tried using a 2560x1440 display with a PowerMac G5 but forgot to switch from kern.vty=vt to kern.vty=sc in /boot/loader.conf first. > > But the result was new since the last time I'd done such a thing (long ago)... > > It crashed so early that it returned to Apple's OpenFirmware. > > That allowed me to use .registers in OpenFirmware to find where it had crashed at. > > It turned out that the Interrupt Vector was 0x700 and SRR0 was 0x380. (Openfirmare does not put an exception handler at 0x380 (leaving zeros) so a 0x380 exception handler's attempted use leads to a double fault when OpenFirmware's handlers are all that are in place, the 2nd of the pair going to the 0x700 exception handler.) > > Luckily LR is preserved in this sequence and it ended up pointing to: > > vtbuf_init_early+0x78 (0x40787c was the address for the build) > > and that was the instruction after a bl to .vtbuf_fill. > > This was fully repeatable. > > > As conformation of the size dependency: Switching to a smaller display booted fine (again fully repeatable). > > > I'll note that kern.vty=sc handles the 2560x1440 display fine for that same PowerMac G5. sc uses most but not all of the width and it uses all of the height. > > > Other context details: > > $ cd /usr/src > $ svnlite info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/stable/10 > Relative URL: ^/stable/10 > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279507 > Node Kind: directory > Schedule: normal > Last Changed Author: ngie > Last Changed Rev: 279507 > Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015) > > $ svnlite st --no-ignore > ? .snap > ? restoresymtable > M sys/ddb/db_main.c > M sys/ddb/db_script.c > I sys/powerpc/conf/GENERIC64vtsc > I sys/powerpc/conf/GENERICvtsc > M sys/powerpc/ofw/ofw_machdep.c > M sys/powerpc/ofw/ofwcall64.S > M sys/powerpc/powerpc/dump_machdep.c > > sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to avoid intermittent boot problems. > > sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get evidence if I do end up with another early-boot failure. DDB and GDB are listed in sys/powerpc/conf/GENERIC64vtsc for the same reason. > > sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer size for dumps to be small enough not to be rejected as too large of a DMA request size. > > sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both vt and sc. It includes the standard GENERIC64. > > # more /etc/make.conf > #CPP=clang-cpp > #CC=clang > #CXX=clang++ > WRKDIRPREFIX=/usr/obj/portswork > WITH_DEBUG= > MALLOC_PRODUCTION= > > # more /etc/src.conf > #CPP=clang-cpp > #CC=clang > #CXX=clang++ > #CFLAGS+=-DELF_VERBOSE > #WITH_DEBUG_FILES= > #WITHOUT_CLANG > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54FC7E39.3010602>