[Bug 233863] ppc64 r341705 on Apple PowerMac G5 requires kern.smp.disabled=1 and usefdt=1 and then networking fails

[b***@freebsd.org]

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

Bug ID: 233863
Summary: ppc64 r341705 on Apple PowerMac G5 requires
kern.smp.disabled=1 and usefdt=1 and then networking
fails
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: ***@FreeBSD.org
Reporter: ***@blastwave.org

Created attachment 199947
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=199947&action=edit
dmesg output from r341705 on ppc64 with kern.smp.disabled=1 and usefdt=1

As discovered while working on bugid 233579 we require usefdt=1 as well
as kern.smp.disabled=1 in order for the system to boot. The unit will
then boot normally however network devices are status "no carrier".
Also the devices are listing in a different order from RC3 r341271.

See dmesg attached.

[b***@freebsd.org]

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

Dennis Clarke <***@blastwave.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Hardware|Any |powerpc

[b***@freebsd.org]

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

Dennis Clarke <***@blastwave.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|coldboot ppc64 r341705 on |r341705 on PowerMac G5 may
|PowerMac G5 requires |require kern.smp.disabled=1
|kern.smp.disabled=1 and |and must set usefdt=1 which
|usefdt=1 which causes net |causes net interface
|interface reorder |reorder

[b***@freebsd.org]

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

Dennis Clarke <***@blastwave.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|ppc64 r341705 on Apple |ppc64 r341705 on PowerMac
|PowerMac G5 requires |G5 requires
|kern.smp.disabled=1 and |kern.smp.disabled=1 and
|usefdt=1 and then |usefdt=1 which causes net
|networking fails |interface reorder

--- Comment #1 from Dennis Clarke <***@blastwave.org> ---

It was seen that the physical MAC addresses of the bge0 and bge1
interfaces were exchanged in the output from 'ifconfig -a' and thus the
flat device tree option usefdt=1 may be the cause.

Once this was seen it was trivial to bring up both interfaces and to
assign the correct ip to bge1 and then stop start ntpd and sshd etc.

eris# uname -aU
FreeBSD eris 13.0-CURRENT FreeBSD 13.0-CURRENT r341705 GENERIC powerpc 1200086
eris# ifconfig -a
fwe0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 02:11:24:e5:13:d0
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
ch 1 dma -1
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE>
ether 00:14:51:64:67:11
inet 172.16.35.8 netmask 0xffffffc0 broadcast 172.16.35.63
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (none)
status: no carrier
bge1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE>
ether 00:14:51:64:67:10
inet 172.16.35.7 netmask 0xffffffc0 broadcast 172.16.35.63
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex,master>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: lo
eris#

[b***@freebsd.org]

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

--- Comment #4 from Mark Millard <marklmi26-***@yahoo.com> ---
(In reply to Mark Millard from comment #3)

It appears that one difference I get with set usefdt=1 is
that for shutdown -r or -p bufdeamon, bufspacedaemon-1,
and bugspacedaemon-2 time out.

Another difference may be that the fans may be more likely
to go full blast.

[b***@freebsd.org]

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

Dennis Clarke <***@blastwave.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|ppc64 r341705 on PowerMac |coldboot ppc64 r341705 on
|G5 requires |PowerMac G5 requires
|kern.smp.disabled=1 and |kern.smp.disabled=1 and
|usefdt=1 which causes net |usefdt=1 which causes net
|interface reorder |interface reorder

--- Comment #2 from Dennis Clarke <***@blastwave.org> ---
As yet another variable in the mix we see all four cpu's are online
if and only if one performs are warm boot aka shutdown -r 'now' :

1) power on system and wait for loader
2) interrupt the load kernel process
3) set kern.smp.disabled=1
4) set usefdt=1
5) boot -sv
6) once the shell is running simply shutdown -r 'now'
7) interrupt the load kernel process
8) set usefdt=1
9) boot normally

All processor cores wwill come online :


eris# uname -aU
FreeBSD eris 13.0-CURRENT FreeBSD 13.0-CURRENT r341705 GENERIC powerpc 1200086

eris# uptime
11:04PM up 15 mins, 1 user, load averages: 0.18, 0.21, 0.17

eris# sysctl kern.smp.cpus hw.ncpu
kern.smp.cpus: 4
hw.ncpu: 4

[b***@freebsd.org]

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

Mark Millard <marklmi26-***@yahoo.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |marklmi26-***@yahoo.com

--- Comment #3 from Mark Millard <marklmi26-***@yahoo.com> ---
(In reply to Dennis Clarke from comment #2)

Just an FYI about my from-source builds based on devel/powerpc64-xtoolchain-gcc
and the reverted-to-before /usr/src/sys/powerpc/include/vmparam.h -r334498 .

I jumped from -r340287 to -r341766 . It booted fine as smp.

I tried booting with "set usefdt=1" and the ethernet connection moved to
the other plugin position. It also booted fine as smp and the ethernet
works fine.

[I have occasional access to a G5 Quad Core (system total count) again.]