Re: CURRENT -r361544 breaks 2-socket PowerMac G4 booting: "powerpc/mmu: Convert PowerPC pmap drivers to ifunc from kobj"

Mark Millard via freebsd-ppc <[email protected]>
Newsgroups gmane.os.freebsd.devel.ppc
Message-ID <[email protected]>

On 2021-Jan-2, at 09:54, Brandon Bergren <bdragon at FreeBSD.org> wrote:

> I was testing this myself yesterday.
> 
> Things seemed to be working (other than usb weirdness) on my MPC7400 rev 2.9 dual processor G4 (PVR 000c0209) with latest.

On the USB oddities: I've had a boot in which USB is working,
at least for keyboard use. Its bus_dmamem_alloc messages also
stop early on, with the 12th message being the last. The last
3 are shown in context below (showing the phys addr and
alignment figures as well):

. . .
Root mount waiting for: CAM usbus0
Jan  1 17:49:08 FBSDG4S2 kernel: bus_dmamem_alloc failed to align memory properly.
Jan  1 17:49:08 FBSDG4S2 kernel: vtophys(*vaddr)==0x1c48d80 and dmat->alignment-1==0xff
Jan  1 17:49:08 FBSDG4S2 kernel: ugen0.4: <Mitsumi Electric Apple Extended USB Keyboard> at usbus0
Jan  1 17:49:08 FBSDG4S2 kernel: ukbd0 numa-domain 0 on uhub5
Jan  1 17:49:08 FBSDG4S2 kernel: ukbd0: <Mitsumi Electric Apple Extended USB Keyboard, class 0/0, rev 1.10/1.22, addr 4> on usbus0
Jan  1 17:49:08 FBSDG4S2 kernel: kbd1 at ukbd0
Jan  1 17:49:08 FBSDG4S2 kernel: uhid0 numa-domain 0 on uhub5
Jan  1 17:49:08 FBSDG4S2 kernel: uhid0: <Mitsumi Electric Apple Extended USB Keyboard, class 0/0, rev 1.10/1.22, addr 4> on usbus0
Jan  1 17:49:08 FBSDG4S2 kernel: bus_dmamem_alloc failed to align memory properly.
Jan  1 17:49:08 FBSDG4S2 kernel: vtophys(*vaddr)==0x1c48a80 and dmat->alignment-1==0xff
Jan  1 17:49:08 FBSDG4S2 kernel: bus_dmamem_alloc failed to align memory properly.
Jan  1 17:49:08 FBSDG4S2 kernel: vtophys(*vaddr)==0x1c48a80 and dmat->alignment-1==0xff
Jan  1 17:49:08 FBSDG4S2 kernel: Root mount waiting for: CAM usbus0
Jan  1 17:49:08 FBSDG4S2 kernel: ugen0.5: <vendor 0x05ac Studio Display> at usbus0
Jan  1 17:49:08 FBSDG4S2 kernel: uhid1 numa-domain 0 on uhub4
Jan  1 17:49:08 FBSDG4S2 kernel: uhid1: <vendor 0x05ac Studio Display, class 0/0, rev 1.00/1.06, addr 5> on usbus0
Jan  1 17:49:08 FBSDG4S2 kernel: Root mount waiting for: CAM
. . .

Apparently, having ongoing bus_dmamem_alloc messages and having
failing USB are tied together in some manor. For reference,
the boot did get:

Jan  1 17:49:08 FBSDG4S2 kernel: SMP: 2 CPUs found; 2 CPUs usable; 1 CPUs woken

The PowerMac G4 is instead reporting something different
for ongoing notices:

. . .
Jan  2 10:10:37 FBSDG4S2 kernel: ds17750: iicbus read failed
Jan  2 10:12:19 FBSDG4S2 kernel: iichb0: I2C error
Jan  2 10:14:02 FBSDG4S2 syslogd: last message repeated 1 times
Jan  2 10:15:44 FBSDG4S2 syslogd: last message repeated 1 times
Jan  2 10:22:31 FBSDG4S2 syslogd: last message repeated 4 times
Jan  2 10:22:31 FBSDG4S2 kernel: ds17750: iicbus read failed
Jan  2 10:24:14 FBSDG4S2 kernel: iichb0: I2C error
Jan  2 10:25:57 FBSDG4S2 syslogd: last message repeated 1 times
Jan  2 10:27:39 FBSDG4S2 syslogd: last message repeated 1 times
Jan  2 10:32:44 FBSDG4S2 syslogd: last message repeated 3 times
Jan  2 10:32:44 FBSDG4S2 kernel: adm10300: iicbus write failed
Jan  2 10:34:27 FBSDG4S2 kernel: iichb0: I2C error
Jan  2 10:36:09 FBSDG4S2 syslogd: last message repeated 1 times
Jan  2 10:37:52 FBSDG4S2 syslogd: last message repeated 1 times
Jan  2 10:42:57 FBSDG4S2 syslogd: last message repeated 3 times
Jan  2 10:42:57 FBSDG4S2 kernel: ds17750: iicbus read failed
Jan  2 10:44:39 FBSDG4S2 kernel: iichb0: I2C error
Jan  2 10:46:22 FBSDG4S2 syslogd: last message repeated 1 times
Jan  2 10:48:02 FBSDG4S2 syslogd: last message repeated 1 times
Jan  2 10:53:09 FBSDG4S2 syslogd: last message repeated 3 times
Jan  2 10:53:09 FBSDG4S2 kernel: adm10300: iicbus write failed
Jan  2 10:54:52 FBSDG4S2 kernel: iichb0: I2C error
. . .

It was not reporting such previously. (It is my build of
-r368820 with my patches, which had USB failing like
the artifact.ci kernels in previous boots.)


> Can you tell me the exact PVR of your processors? (can find it in OF with 'dev /cpus/PowerPC,G4@0 .properties' and looking at the cpu-version: property.) I'm wondering if it is an errata that we're tripping over here.

This from ofwdump covers that for the PowerPC 7455 revision 3.3,
I think:

# ofwdump -P cpu-version /cpus/PowerPC,G4
Node 0x274: PowerPC,G4
  cpu-version:
    80 01 03 03 

FYI:

# ofwdump -ap
Node 0x38: device-tree
  phandle:
    ff 88 11 a8 
  model:
    50 6f 77 65 72 4d 61 63 33 2c 36 00 
    'PowerMac3,6'
. . .

Also:

Jan  1 17:49:08 FBSDG4S2 kernel: cpu0: Motorola PowerPC 7455 revision 3.3, 1416.74 MHz
Jan  1 17:49:08 FBSDG4S2 kernel: cpu0: Features 9c000000<PPC32,ALTIVEC,FPU,MMU>
Jan  1 17:49:08 FBSDG4S2 kernel: cpu0: HID0 8450c0bc<EMCP,TBEN,NAP,DPM,ICE,DCE,SGE,BTIC,LRSTK,FOLD,BHT>
Jan  1 17:49:08 FBSDG4S2 kernel: real memory  = 2115649536 (2017 MB)
Jan  1 17:49:08 FBSDG4S2 kernel: avail memory = 2052780032 (1957 MB)

NOTE: I have access to a 2nd one of this type of
PowerMac G4.

> Regarding the alignment problem, I'm hoping to be able to update the busdma code to lean on the new MI bits, it's a bit of a mess currently.

It looks to me like this and the USB/I2C problems may be related
in some way.

> On Thu, Dec 31, 2020, at 3:35 PM, Mark Millard wrote:
>> [Continuation of testing kernel builds, but testing my own kernel
>> builds for the head powerpc updates not available from artifacts.ci.
>> Ends up: -r361544 breaks things.]
>> 
>> On 2020-Dec-30, at 17:07, Mark Millard <marklmi at yahoo.com> wrote:
>> 
>>> A quick summary of what I found in a crude artifact bisect is coded into
>>> the filenames listed later. The earliest major point is the "1 CPUs woken"
>>> issue from what I can tell. It still happens in -r368820 .
>>> 
>>> "2cpus_booted" means things booted and worked normally.
>>> 
>>> "1cpuwoke_" means that the following was reported:
>>> 
>>> SMP: 2 CPUs found; 2 CPUs usable; 1 CPUs woken
>>> 
>>> "_hung" means that it appeared to stop without reporting a crash. Never
>>> got to login prompt.
>>> 
>>> "crashes_quickly" means that the the kernel did not get very far before
>>> the crash happened.
>>> 
>>> -rw-r--r--   1 root  wheel  19179328 May 25 21:44:01 2020 kernel-r361494-2cpus_booted.txz
>>> 
>>> Note: No artifact kernel.txz files for the range -r361495 .. -r361583 .
>>> powerpc checkins in that range include:
>>> 
>>> -r361542 : [PowerPC] Fix invalid asm in trap code (Brandon)
>>> -r361544 : powerpc/mmu: Convert PowerPC pmap drivers to ifunc from kobj (Justin)
>>> -r361545 : Properly sort ifdef archs in vm_fault_soft_fast superpage guards. (Justin)
>>> -r361568 : [PowerPC] Fix radix crash when passing -1 from userspace (Brandon)
>>> -r361570 : powerpc/pmap: Remove some debug from r361544 (Justin)
>>> 
>>> -rw-r--r--   1 root  wheel  19133836 May 28 04:28:01 2020 kernel-r361584-1cpuwoke_hung.txz
>>> -rw-r--r--   1 root  wheel  19181596 May 29 04:42:42 2020 kernel-r361624-1cpuwoke_hung.txz
>>> -rw-r--r--   1 root  wheel  19254832 Jun  3 10:26:42 2020 kernel-r361754-1cpuwoke_hung.txz
>>> -rw-r--r--   1 root  wheel  18869112 Jun 10 16:53:57 2020 kernel-r362034-1cpuwoke_hung.txz
>>> -rw-r--r--   1 root  wheel  19245524 Jul  8 06:04:41 2020 kernel-r363008-1cpuwoke_hung.txz
>>> -rw-r--r--   1 root  wheel  19259816 Aug 16 12:03:55 2020 kernel-r364274-1cpuwoke_hung.txz
>>> 
>>> NOTE: -r364284 is where clang 11 started and the -O newly meaning -O1 problem started.
>>>     (Previously -O meant -O2. -O1 messed up the kernel's ifunc handling until it
>>>     was changed to explicitly use -O2.)
>>> 
>>> -rw-r--r--   1 root  wheel  19369960 Aug 22 11:38:22 2020 kernel-r364488-crashes_quickly.txz
>>> -rw-r--r--   1 root  wheel  19203632 Sep  1 01:38:18 2020 kernel-r365024-crashes_quickly.txz
>>> -rw-r--r--   1 root  wheel  19367776 Sep  3 11:02:58 2020 kernel-r365304-crashes_quickly.txz
>>> -rw-r--r--   1 root  wheel  19279564 Sep  6 08:06:11 2020 kernel-r365378-crashes_quickly.txz
>>> -rw-r--r--   1 root  wheel  19205456 Sep  7 22:53:14 2020 kernel-r365444-1cpuwoke_crashes_late.txz
>>> -rw-r--r--   1 root  wheel  19446448 Sep 10 08:08:23 2020 kernel-r365578-1cpuwoke_hung.txz
>>> -rw-r--r--   1 root  wheel  19398268 Oct  9 06:05:48 2020 kernel-r366598-1cpuwoke_hung.txz
>>> 
>>> Note: -r368820 still has "1cpuwoke" status and its USB is messed up (and
>>>     it reports DMA misalignment) but it does boot. (I accessed it via ssh.)
>> 
>> Note: for the below kernel builds I provided a "int yydebug;" for:
>> 
>> usr.bin/localedef/localedef.c
>> 
>> so kernel-toolchain could build (avoiding a link failure).
>> 
>> Other than that, the kernel builds are of pure code from git using 
>> KERNCONF=GENERIC ,
>> TARGET=powerpc , TARGET_ARCH=powerpc and no other tailoring, avoiding 
>> any questions
>> about my personal patches contributing.
>> 
>> 
>> -r361542 (64cc3b0c28b9) : [PowerPC] Fix invalid asm in trap code (Brandon)
>> 
>> Things booted and worked as expected.
>> 
>> 
>> -r361544 (45b69dd63e84) : powerpc/mmu: Convert PowerPC pmap drivers to 
>> ifunc from kobj (Justin)
>> 
>> SMP: 2 CPUs found; 2 CPUs usable; 1 CPUs woken
>> 
>> was reported and it appeared to stop without reporting a crash. Never
>> got to login prompt.
>> 
>> 
>> NOTE: -r361453 was on stable/ instead of head/ so the above is a
>> works-then-fails pair with nothing between on CURRENT.
> 
> 

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

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.