[Bug 216123] ofwfb: r269278 broke booting on Power Mac G4

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216123

Mark Linimon  changed:

   What|Removed |Added

   Keywords||patch
   Assignee|freebsd-bugs@FreeBSD.org|nwhiteh...@freebsd.org

--- Comment #9 from Mark Linimon  ---
Assign to committer of r269278.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 216123] ofwfb: r269278 broke booting on Power Mac G4

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216123

--- Comment #8 from Tom Lane  ---
Created attachment 179069
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=179069=edit
Minimum part of reverting r269278 to get CURRENT to boot

I've not had any luck bringing a kernel debugger to bear, but I've experimented
with the r269278 patch some more, and I can report that the portions attached
to this comment are the minimum needed to make it work.  Without the
seemingly-superfluous OF_open call in ofwfb_initialize, it freezes during boot
in the way previously described.  If the set-depth method call isn't removed
from ofwfb_init, it boots but the screen display is completely messed up ---
looks like it has the wrong idea about the framebuffer stride.

I'm not sure what to make of this.  I do not understand the division of labor
between ofwfb_initialize and ofwfb_init, nor what the intended call sequence
is, but I sort of suspect that the actual call sequence is different from what
the code's author expected.

Obviously, this is still not a committable patch; the "extra" OF_open call
might be safe enough, but removing the set-depth call would presumably
represent a loss on better hardware.  But perhaps this will give somebody an
idea of what to pursue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 216123] ofwfb: r269278 broke booting on Power Mac G4

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216123

--- Comment #7 from Kevin Bowling  ---
I don't think they need to be the same version, but you could revert the one
commit on the display system.  I've never used this though, so I can't validate
that it actually works still.  But it seems worth trying to see if there is a
useful panic string or whatever where the screen is going blank when debugging
is enabled, and you can also run kgdb remotely over it.

Otherwise maybe Nathan has enough context with your report now to take a look.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 216123] ofwfb: r269278 broke booting on Power Mac G4

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216123

--- Comment #6 from Tom Lane  ---
(In reply to Kevin Bowling from comment #5)
Hmm ... I lack a firewire cable, but that could be remedied.  The only other
firewire machine I have is a G4 laptop, which I'm pretty sure won't boot 11 or
12 for the same reason this one won't.  I do have 10.3 installed on it though. 
Does the debug host need to be same FreeBSD version?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 216123] ofwfb: r269278 broke booting on Power Mac G4

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216123

--- Comment #4 from Tom Lane  ---
(In reply to Kevin Bowling from comment #2)
> Can you set 'sysctl debug.debugger_on_panic=1' and see if you can get a 
> better idea
> where it dies from the db> prompt or by switching to kgdb from that?

I couldn't figure out how to do that using the Open Firmware boot loader --- it
doesn't understand sysctl, AFAICT.  I tried the -d kernel switch but it didn't
change anything.

This machine lacks a serial port, which makes traditional kernel debugging
difficult.  I noticed that its Open Firmware version does support telnet
connections, though.  Is there a way to use that facility for a kernel debug
console?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 216123] ofwfb: r269278 broke booting on Power Mac G4

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216123

--- Comment #3 from Tom Lane  ---
Created attachment 178976
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=178976=edit
ofwdump -ap output

> I don't have any G4 hw so maybe a dump of OFW tree as well.

Here's ofwdump -ap output from the FreeBSD 10.3 installation on the machine;
is that what you wanted?

I'll look into the other part tomorrow.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 216123] ofwfb: r269278 broke booting on Power Mac G4

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216123

--- Comment #2 from Kevin Bowling  ---
Can you set 'sysctl debug.debugger_on_panic=1' and see if you can get a better
idea where it dies from the db> prompt or by switching to kgdb from that?

I don't have any G4 hw so maybe a dump of OFW tree as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 216123] ofwfb: r269278 broke booting on Power Mac G4

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216123

--- Comment #1 from Tom Lane  ---
Created attachment 178973
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=178973=edit
Revert r269278, in a way that applies to CURRENT

Just for fun, I tried reverting r269278 against CURRENT (r312314 to be
precise).
The result boots, confirming my theory that that's what broke it.

I've attached the reversion patch in case anyone really needs it, but to be
clear,
I am not proposing that this be committed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 216123] ofwfb: r269278 broke booting on Power Mac G4

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216123

Bug ID: 216123
   Summary: ofwfb: r269278 broke booting on Power Mac G4
   Product: Base System
   Version: CURRENT
  Hardware: powerpc
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: t...@sss.pgh.pa.us

I've been trying to install FreeBSD on a Power Mac G4 ("PowerMac 3,6",
a/k/a Mirrored Drive Doors 2003).  10.3 works fine, but neither
11-STABLE nor CURRENT are able to boot.  I've bisected the problem
and can state confidently that this commit broke it:

  r269278 | nwhitehorn | 2014-07-29 19:11:05 -0400 (Tue, 29 Jul 2014) | 6 lines

  Make mmap() of the console device when using ofwfb work like other supported
  framebuffer drivers. This lets ofwfb work with xf86-video-scfb and makes
  the driver much more generic and less PCI-centric. This changes some
  user-visible behavior and will require updates to the xorg-server port
  on PowerPC when using ATI graphics cards.

The immediately preceding commit boots fine, with or without kernel debug
options.  (Well, I have to back-patch r269365 and r305901, but then it
boots fine.)  With r269278, the behavior is one of these:

* kernel debug options enabled: seems to freeze immediately at boot.
After the boot loader says it's booting the kernel, the screen goes
black as expected, but no kernel output text ever appears.

* kernel debug options disabled: fatal kernel trap after a few dozen
lines of dmesg output.  I've transcribed a screen shot:

...
gem0: 10kB RX FIFO, 4kB TX FIFO
gem0: Ethernet address: (machine's MAC address here)
cryptosoft0:  on nexus0

fatal kernel trap:

   exception  = 0xd0004840 (unknown)
   srr0   = 0x0
   srr1   = 0x0
   lr = 0x861104
   curthread  = 0

panic: unknown trap
cpuid = 0
KDB: stack backtrace:
#0 0x4a93ac at panic+0x16c
#1 0x861308 at trap_fatal+0x1bc
#2 0x8622e4 at trap+0xfb4
#3 0x84fef0 at powerpc_interrupt+0x170
Uptime: 1s
(reboots)


Furthermore, on the way to isolating when the problem was introduced,
I discovered that the non-debug behavior changed from a trap to a silent
freeze at r279750 ("Make 32-bit PowerPC kernels, like 64-bit PowerPC
kernels, position-independent executables").  It seems to occur at the
same place though, right after reporting cryptosoft0, so I suppose that
it's the same bug manifesting differently.

These behaviors of freeze at boot with debug options, or freeze after
"cryptosoft0" without, are still present in CURRENT and 11-STABLE.
I gather from recent reports on the freebsd-ppc list that a number of
other people see these same behaviors, but not everyone does.  I am unable
to offer a theory as to just what the triggering difference is, or how the
bug might be fixed.  But I'd be happy to run further testing if given some
guidance.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"