11.1 release CD image panics very early during boot on ppc.

[Mark Millard]

On 2018-Apr-20, at 10:23 AM, Jukka Ukkonen <jau789 at gmail.com> wrote:


> So, I tried setting debug.debugger_on_panic=1 and ”boot -v”.
> The first time I tried the ofw did not see the full-HD display
> which was connected to another system via a KVM switch at
> that time. I only got the KVM switched to the correct system
> only when I had got the booting stopped at the ofw prompt.
> So, the early boot assumed a very traditional 80 columns by
> 25 to 30 lines display with a large font. Surprisingly the 11.1 CD
> booted just fine. Obviously I wanted to double check and rebooted
> the system. This time the display was connected via the KVM
> switch to the system right from the start. The ofw obviously figured
> out the true full-HD resolution and used a tiny font. When the kernel 
> got control of the system it selected a bit larger font, showed some
> of the autoconfig messages, and went down hard no matter whether
> I set the debug.debugger_on_panic=1 or not.
> This raises the obvious assumption that there must be something
> going awry with how vt and ofw communicate and how they try to
> control the display. Supposedly this could lead to mismanagement
> of a large chunk of memory such that even the debugger is left
> totally powerless when the crash happens. Because vt is new to 11.1
> and the properly booting 10.4 uses sc, memory corruption seems
> like a plausible explanation to the mysterious crash.
> 
> I hope this helps.
> 
> --jau

It has been a long time since I've booted an old PowerMac with
vt on my larger displays. I actually build a kernel with both
vt and sc in it (no PS3 support) and normally boot sc.

My historical reason for avoiding vt was the early stages having
a fixed sized memory area tied to what was to be displayed and it
going out of bounds of that area and trashing things when I had a
large enough display attached.

But it has been a very long time since I've done such experiments
in this area. So take this note as only suggestive.

As I remember, the display types that had the problem were
2560x1440 or something like that. vt would boot fine for
smaller displays that I used, such as 1920x1200, as I
remember.

Looking in the list history (10.x time frames):

https://lists.freebsd.org/pipermail/freebsd-ppc/2014-September/007260.html
https://lists.freebsd.org/pipermail/freebsd-ppc/2014-September/007263.html

It mattered for GeForce 7800 GT vs. Radeon X1950 for the 2560x1440
behavior.

As I remember, the maximum screen size involved in the kernel
was changed as Nathan indicates, but still to some fixed figures
for the early code. Likely still a problem for a sufficiently
large display. (Beyond what I have access to now.)

(The xf86-video-scfb suggestion did not work for the X1950. I stopped
using X on the old PowerMac long ago.)


>> On 17 Apr 2018, at 18.11, Justin Hibbits <jrh29 at alumni.cwru.edu> wrote:
>> 
>> Hi,
>> 
>>> On Sun, Apr 15, 2018 at 2:10 AM, Jukka Ukkonen <jau789 at gmail.com> wrote:
>>> 
>>> I had a bit of an accident with my old PowerMac G4 which had been
>>> running FreeBSD-10.4. To fix the mess I had to boot the system from
>>> a CD image. So, I decided to try 11.1 while at it. To my astonishment
>>> and disappointment the 11.1 images (both CD and DVD) paniced
>>> very early on during the boot. The messages flashed past the screen
>>> so quickly that I cannot be really sure about anything, but it kind of
>>> seemed like the issue might be yet another installment of the SPRG
>>> related problems (in ofw_machdep.c) which have been troubling
>>> ppc64 systems before.
>>> The 10.4 CD image boots just fine on ppc.
>>> 
>>> --jau
>> 
>> Can you try booting with 'boot -v' and also setting at the loader
>> debug.debugger_on_panic=1?  I think it's set to 0 on release ISOs, so
>> this should let you get a screen capture.
>> 
>> - Justin

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)