HEADS UP: powerpc64 kernel format change [boot-time kern.vty=vt temporary display oddity]
Mark Millard
markmi at dsl-only.net
Sun Feb 1 23:26:53 UTC 2015
I've done a bunch of PowerMac G5 quad-core boots and have some behavior to report that might be of interest.
For my 11.0-CURRENT (-r277990) boots (stop 10.1-RELASE-p5 then unload then boot kernel11C, details later):
During the kernel11C boot when kern.vty=vt there is always a block of boot message lines that get extra text on screen in odd positions, some (all?) of the extra text with unusual (non-black) background colors, for example. I've not noticed such in prior 11.0-CURRENT vintages that I've booted. Such text does not show up in /var/log/messages or the like, just on screen. The lines from the boot that get this are approximately the range:
Feb 1 13:22:40 FBSDG5M1 kernel: pci3: <OFW PCI bus> on pcib3
Feb 1 13:22:40 FBSDG5M1 kernel: bge0: <Broadcom BCM5714 B3, ASIC rev. 0x008003> mem 0xfa530000-0xfa53ffff,0xfa520000-0xfa52ffff irq 66 at device 4.0 on pci3
Feb 1 13:22:40 FBSDG5M1 kernel: bge0: CHIP ID 0x00008003; ASIC REV 0x08; CHIP REV 0x80; PCI-X 33 MHz
Feb 1 13:22:40 FBSDG5M1 kernel: miibus0: <MII bus> on bge0
Feb 1 13:22:40 FBSDG5M1 kernel: brgphy0: <BCM5780 1000BASE-T media interface> PHY 1 on miibus0
Feb 1 13:22:40 FBSDG5M1 kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
Feb 1 13:22:40 FBSDG5M1 kernel: bge0: Ethernet address: 00:14:51:68:5a:44
Feb 1 13:22:40 FBSDG5M1 kernel: bge1: <Broadcom BCM5714 B3, ASIC rev. 0x008003> mem 0xfa510000-0xfa51ffff,0xfa500000-0xfa50ffff irq 67 at device 4.1 on pci3
Feb 1 13:22:40 FBSDG5M1 kernel: bge1: CHIP ID 0x00008003; ASIC REV 0x08; CHIP REV 0x80; PCI-X 33 MHz
Feb 1 13:22:40 FBSDG5M1 kernel: miibus1: <MII bus> on bge1
Feb 1 13:22:40 FBSDG5M1 kernel: brgphy1: <BCM5780 1000BASE-T media interface> PHY 1 on miibus1
Feb 1 13:22:40 FBSDG5M1 kernel: brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
Feb 1 13:22:40 FBSDG5M1 kernel: bge1: Ethernet address: 00:14:51:68:5a:45
Feb 1 13:22:40 FBSDG5M1 kernel: pcib4: <OFW PCI-PCI bridge> at device 3.0 on pci1
As for the video card: The Radeon identified as... Chipset: "ATI Radeon X1950" (ChipID = 0x7240). The screen used is small enough that the historical 2560x1440 boot display issue for this card is not involved.
With kern.vty=sc used instead no such odd text appears.
Booting 10.1-RELEASE-p5 (directly) and 10.1-STABLE (-r277808 via the same sort of sequence as indicated below) do not get this display oddity with any of the 3 loader versions [from 10.1-RELEASE-p5, 10.1-STABLE (-r277808), and 11.0-CURRENT (-r277990)], be it vt or sc style.
Context: using the /boot/loader file from 11.0-CURRENT (-r277990)...
$ freebsd-version -ku; uname -a
10.1-RELEASE-p5
11.0-CURRENT
FreeBSD FBSDG5M1 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r277990M: Sat Jan 31 18:27:29 PST 2015 root at FBSDG5M1:/usr/obj/usr/home/markmi/src_11_current/sys/GENERIC64vtsc powerpc
The 11.0-CURRENT build is not the usual debug build but is like my 10.1-RELEASE-p5 and 10.1-STABLE builds: all use the same GENERIC64vtsc content that adjusts the GENERIC64 that is included. There are explicit nooptions to disable various potential debug options.
$ ls -Fd /boot/kernel*
/boot/kernel/ /boot/kernel10.1RE/ /boot/kernel10.1S/ /boot/kernel11C/
$ more /boot/loader.conf
kernel="kernel10.1RE"
verbose_loading="YES"
kern.vty=vt
I boot as above (kernel10.1RE, i.e. a variant of 10.1-RELEASE-p5 from RelEng) but use the "any other key for a command prompt" to stop it and then I:
unload
boot kernel11C
This sequence is because directly listing "kernel11C" in /boot/loader.conf fails to boot far enough to reach the "any other key for a command prompt" stage. (But its text= data= syms=[...] loading line does show up before it fails when kernel11C is tried directly.) The direct-booting issue is not new to -r277990 and 10.1-STABLE also has had it and continues to. I'm not reporting this aspect of things as part of a -r277990 problem but I figured the odd boot style should be noted as part of the test context.
$ svnlite status ~markmi/src_11_current/
M /home/markmi/src_11_current/sys/ddb/db_main.c
M /home/markmi/src_11_current/sys/ddb/db_script.c
? /home/markmi/src_11_current/sys/powerpc/conf/GENERIC64vtsc
M /home/markmi/src_11_current/sys/powerpc/ofw/ofw_machdep.c
M /home/markmi/src_11_current/sys/powerpc/ofw/ofwcall64.S
M /home/markmi/src_11_current/sys/powerpc/powermac/powermac_thermal.c
The *.[cS] files other than powermac_thermal.c and part of GENERIC64vtsc are my hacks for investigating early-boot problems on PowerMac G5s and avoiding the most frequent one from stopping my boots. powermac_thermal.c is a Justin H. patch for making the fan/pump RPMs more aggressive but the G5 it was used to test is gone. My 10.1-RELEASE-p5 and 10.1-STABLE variants have the same hacks and patch, other than the 11.0-CURRENT ofwcall64.S details were adjusted for the relocatable kernel changes. (Stick with non-volitile register storage in more places.)
The below forward has some more context detail included.
===
Mark Millard
markmi at dsl-only.net
On 2015-Feb-1, at 12:04 AM, Mark Millard <markmi at dsl-only.net> wrote:
Just an FYI, not a request for anything.
I've booted my powerpc64 11.0-CURRENT -r277990 "GENERIC64vtsc" variant on a PowerMac G5 quad core, but a little oddly. I've also used the new loader to boot 10.1-RELEASE-p5 and 10.1-STABLE (-r277808), 10.1-RELEASE-p5 being a normal boot but 10.1-STABLE also being odd in the same way as 11.0-CURRENT. (The oddity is not new to the -r277990 context.)
Before attempting this I'd already adapted my powermac-g5-more-reliable-booting-investigation-hacks to powerpc64 11-CURRENT after the relocatable kernel changes touched ofwcall64.S and I had booted a with-hack 11.0-CURRENT kernel before this. (The recent Justin H. patch for fan/pump RPMs is also present, although the problem powermac is gone.)
Like for 10.1-STABLE, for 11-CURRENT (-R277990) the sequence buildworld, buildkernel, installkernel, installworld, reboot failed to boot before getting to the "any other key for a command prompt" stage, although the SRR0 figure was different.
%SRR0: 00000000.01c287ac (10.1-STABLE reports 1c277fc)
%SRR1: 10000000.00003030
But the same technique that allows me to boot 10.1-STABLE works for 11-CURRENT as well. More below for what I did to have 11-CURRENT kernel+world running despite the above.
To make swapping contexts easier I've established copies of the 3 vintages of loader, each copy established just after the matching installworld:
$ ls -F /boot/loader /boot/loader1*
/boot/loader* /boot/loader10.1S_from_usr_obj*
/boot/loader10.1RE* /boot/loader11C*
/boot/loader10.1RE_from_usr_obj* /boot/loader11C_from_usr_obj*
/boot/loader10.1S*
and I copy /boot/loader11C to /boot/loader to test using it for whatever I'm going to boot with it. (I've not tried any that I copied from /usr/obj/... I may just delete those.) "RE" stands for RelEng, "S" for Stable, "C" for Current.
Note that 10.1RE here is 10.1-RELEASE-p5 (RELENG -r277807) but with my original powermac-g5-more-reliable-booting-investigation-hacks and the fan/pump RPM patch. (My 10.1-STABLE has those as well.)
I also have separate kernel copies (via INSTKERNNAME use):
$ ls -Fd /boot/kernel*
/boot/kernel/ /boot/kernel10.1RE/ /boot/kernel10.1S/ /boot/kernel11C/
(Ignore /boot/kernel here. I tend to use the other ones.)
And I use /boot/loader.conf to control which kernel is initially started, such as:
$ more /boot/loader.conf
kernel="kernel10.1RE"
verbose_loading="YES"
kern.vty=vt
The kernel10.RE one boots and runs fine with any of the 3 vintages of loader. Listing kernel10.1S or kernel11C in loader.conf instead gets the SRR0/SRR1 failures referenced above, even when loader (and world) is from the matching buildworld.
So I boot as above (kernel10.1RE) but use the "any other key for a command prompt" to stop it and then (for example):
unload
boot kernel11C
and that boots and runs fine if I've done the 11-CURRENT installworld before the reboot.
(At this point 10.1-RELEASE-p5 and 10.1-STABLE buildworlds (loader updated) do not mix very well with 11-CURRENT kernels. "init: getting kqueues resource limit invalid argument" notices are an example. And I had kernel panics after a while for such combinations. So far the above 11-CURRENT kernel+world combination seems okay despite the boot sequence having a 10.1-RELEASE-p5 kernel variant involved for a bit.)
$ freebsd-version -ku; uname -a
10.1-RELEASE-p5
11.0-CURRENT
FreeBSD FBSDG5M1 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r277990M: Sat Jan 31 18:27:29 PST 2015 root at FBSDG5M1:/usr/obj/usr/home/markmi/src_11_current/sys/GENERIC64vtsc powerpc
Other details controlling how things were built (all 3 are built similarly):
$ more /etc/make.conf
WRKDIRPREFIX=/usr/obj/portswork
WITH_DEBUG=
MALLOC_PRODUCTION=
$ more /etc/src.conf
#WITH_DEBUG_FILES=
#WITHOUT_CLANG=
(I have separate svn source directory trees for 10.1-RELEASE-p5, 10.1-STABLE (-r277808), and 11.0-CURRENT (-r277990).)
$ more ~markmi/src_11_current/sys/powerpc/conf/GENERIC64vtsc
include GENERIC64
ident GENERIC64vtsc
nooptions PS3 #Sony Playstation 3 HACK!!! to allow sc
options DDB # HACK!!! to dump early crash info (but 11.0-CURRENT already has it)
options GDB # HACK!!! ...
#options KTR
#options KTR_MASK=KTR_TRAP
#options KTR_CPUMASK=0xF
#options KTR_VERBOSE
# HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt historically mishandled during booting
device sc
#device kbdmux # HACK: already listed by vt
options SC_OFWFB # OFW frame buffer
options SC_DFLT_FONT # compile font in
makeoptions SC_DFLT_FONT=cp437
# Disable extra checking typically used for FreeBSD 11.0-CURRENT:
nooptions DEADLKRES #Enable the deadlock resolver
nooptions INVARIANTS #Enable calls of extra sanity checking
nooptions INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS
nooptions WITNESS #Enable checks to detect deadlocks and cycles
nooptions WITNESS_SKIPSPIN #Don't run witness on spinlocks for speed
nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones
(My 10.1-RELEASE-p5 and 10.1-STABLE variants use the same file contents as above.)
$ svnlite status ~markmi/src_11_current/
M /home/markmi/src_11_current/sys/ddb/db_main.c
M /home/markmi/src_11_current/sys/ddb/db_script.c
? /home/markmi/src_11_current/sys/powerpc/conf/GENERIC64vtsc
M /home/markmi/src_11_current/sys/powerpc/ofw/ofw_machdep.c
M /home/markmi/src_11_current/sys/powerpc/ofw/ofwcall64.S
M /home/markmi/src_11_current/sys/powerpc/powermac/powermac_thermal.c
$ svnlite info ~markmi/src_11_current/
Path: /home/markmi/src_11_current
Working Copy Root Path: /home/markmi/src_11_current
URL: https://svn0.us-west.freebsd.org/base/head
Relative URL: ^/head
Repository Root: https://svn0.us-west.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 277990
Node Kind: directory
Schedule: normal
Last Changed Author: nwhitehorn
Last Changed Rev: 277990
Last Changed Date: 2015-01-31 11:16:51 -0800 (Sat, 31 Jan 2015)
===
Mark Millard
markmi at dsl-only.net
More information about the freebsd-ppc
mailing list