Date: Wed, 23 Nov 2016 17:16:22 -0800 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Verbose boot output showing where FreeBSD always hangs on a specific PowerMac G4 (other OS's boot it fine): Any thoughts on why or how to avoid? Message-ID: <A6288C50-1A2E-4806-84C8-CA249C0AA104@dsl-only.net>
next in thread | raw e-mail | index | archive | help
I have access to a PowerMac G4 that I've never had FreeBSD manage to boot (10, 11, 12): it hangs at a given point. (Verbose boot output given later.) Mac OS X and the Ubuntu variants that I've tried but the PowerMac just fine. It also operates fine after booting those for anything that I've tried. Does the below suggest anything about why FreeBSD hangs on this PowerMac --or about how to avoid it hanging? The verbose boot's last subsystem lines are: subsystem a800000 boot_run_interrupt_driven_config_hooks(0)... It then shows about 25 lines of usb, ata, and "random: harvesting" related lines before going silent and being hung up. Hand transcribed tail of the verbose boot from a picture of the screen follows: (The 1st line below is actually on the same line as "boot_run_. . ." above.) usbus0: 12Mpbs Full Speed USB v1.0 usbus1: 12Mpbs Full Speed USB v1.0 ugen0.1: <Apple OHCI root HUB> at usbus0 uhub0: <Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 ugen01.1: <Apple OHCI root HUB> at usbus1 uhub1: <Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1 ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata0: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 ata1: reset tp1 mask=3D03 ostat0=3D00 ostat1=3D00 uhub0: 2 ports with 2 removable, self powered random: harvesting attach, 8 bytes (4 bits) from uhub0 uhub1: 2 ports with 2 removable, self powered random: harvesting attach, 8 bytes (4 bits) from uhub1 (aprobe0:ata0:0:0:0): Spinning up device (aprobe0:ata0:0:0:0): Spin-up done ata1: stat0=3D0x00 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata1: stat1=3D0x00 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata1: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x0 ata2: reset tp1 mask=3D03 ostat0=3D00 ostat1=3D00 pcm0: Mixer "vol": ata2: stat0=3D0x00 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat1=3D0x00 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x0 And that is the end of the output: It is effectively hung up, although likely it is doing some sequence of cpu0 mi_switch thread switching and related internal activity. It does not drop to a ddb prompt like other boot-time failures that I've investigated. This is too early for USB keyboard input as well. On a different, slower/older PowerMac G4 (that boots) the above and what is just after it looks like (not hand transcribed this time): (blank lines omitted) subsystem a800000 boot_run_interrupt_driven_config_hooks(0)... usbus0: 12Mbps Full = Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00ugen0.1: <Apple OHCI = root HUB> at usbus0 uhub0: <Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 ugen1.1: <Apple OHCI root HUB> at usbus1 uhub1: <Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1 ata0: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 ata1: reset tp1 mask=3D03 ostat0=3D00 ostat1=3D00 (aprobe0:ata0:0:0:0): Spinning up device (aprobe0:ata0:0:0:0): Spin-up doneata1: stat0=3D0x00 err=3D0x00 lsb=3D0x00= msb=3D0x00 ata1: stat1=3D0x00 err=3D0x00 lsb=3D0x00 msb=3D0x00uhub0: 2 ports with 2 = removable, self powered random: harvesting attach, 8 bytes (4 bits) from uhub0 uhub1: 2 ports with 2 removable, self powered random: harvesting attach, 8 bytes (4 bits) from uhub1 ata1: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x0 ata2: reset tp1 mask=3D03 ostat0=3D00 ostat1=3D00 ata2: stat0=3D0x00 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat1=3D0x00 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x0 pcm0: Mixer "vol": ugen0.2: <Mitsumi Electric Hub in Apple Extended USB Keyboard> at usbus0 uhub2 on uhub0 uhub2: <Mitsumi Electric Hub in Apple Extended USB Keyboard, class 9/0, = rev 1.10/1.22, addr 2> on usbus0 uhub2: 3 ports with 2 removable, bus powered random: harvesting attach, 8 bytes (4 bits) from uhub2 ugen0.3: <Mitsumi Electric Apple Extended USB Keyboard> at usbus0 ukbd0 on uhub2 ukbd0: <Mitsumi Electric Apple Extended USB Keyboard, class 0/0, rev = 1.10/1.22, addr 3> on usbus0 kbd: new array size 4 kbd1 at ukbd0 kbd1: ukbd0, generic (0), config:0x0, flags:0x3d0000 random: harvesting attach, 8 bytes (4 bits) from ukbd0 This suggests that on the failing PowerMac context the next thing expected would have been the "ugen0.2" line for the Apple keyboard but it never appeared. The same boot SSD and the same keyboard and mouse were used on both of these single-processor PowerMac G4's. I'll note an occasional oddity of trying to boot the slower PowerMac G4 with the verbose output. It sometimes gets stuck and prints a message every 60 seconds or so. . . ums0: 4 buttons and [XYZW] coordinates ID=3D0 random: harvesting attach, 8 bytes (4 bits) from ums0 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config Then the last message repeats but with increasing second counts (120, 180, 240, 300, . . .). The other of this pair of PowerMac's does not produce such messages. For reference the kernel booted above used the below KERNCONF (used with head -r308874 [12-CURRENT] in this case): # more /usr/src/sys/powerpc/conf/GENERICvtsc-DBG=20 # # GENERIC -- Custom configuration for the powerpc/powerpc # include "GENERIC" ident GENERICvtsc-DBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols nooptions PS3 # Sony Playstation 3 = HACK!!! to allow sc options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger options GDB # HACK!!! ... # Extra stuff: options VERBOSE_SYSINIT # Enable verbose sysinit = messages options BOOTVERBOSE=3D1 options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP|KTR_PROC ##options KTR_CPUMASK=3D0xF #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=3Dcp437 # Enable any extra checking for. . . options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity = checking options INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS options WITNESS # Enable checks to detect = deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed options DIAGNOSTIC options MALLOC_DEBUG_MAXZONES=3D8 # Separate malloc(9) zones (options GDB has never been used: I turned it on in my very first FreeBSD experiments but have never bothered to turn it back off despite lack of use. For DDB I can build with an internal script that executes just before the ddb> prompt --but in this context that does not help.) The hangup historically has happened both for normal gcc 4.2.1 builds (world and kernel) and for my experimental clang 3.8.0 buildworld's (kernel still gcc 4.2.1 based). For clang 3.8.0 buildworld experiments the kernel has a so-called "red-zone" added for signal delievery to deal with the clang stack-handling ABI violations. In order to boot an iMac G3 I've also added a couple of isync's to moea_activate (around its mtsrin). But the problem above happened long before I did this and continued to happen after the change as well. For reference: At the loader prompt I'm doing an unload and then an explicit "boot kerddb" to use the debug kernel above. The non-debug kernel also hangs, just with less evidence about where in the internal sequence. (I do not normally run using a debug kernel.) =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A6288C50-1A2E-4806-84C8-CA249C0AA104>