Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 2 Jan 2021 11:38:09 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        Brandon Bergren <bdragon@FreeBSD.org>
Cc:        Justin Hibbits <chmeeedalf@gmail.com>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject:   Re: CURRENT -r361544 breaks 2-socket PowerMac G4 booting: "powerpc/mmu: Convert PowerPC pmap drivers to ifunc from kobj"
Message-ID:  <F6B1536C-51D8-4ABD-BCA8-A045C7E7E2E6@yahoo.com>
In-Reply-To: <c9ce1ac1-28dc-42af-8fd8-b0714475be6b@www.fastmail.com>
References:  <00423D88-0367-4220-B20A-50307DA72A81@yahoo.com> <A9CDA051-466A-4FC6-A57A-D9D751E4FD00@yahoo.com> <c9ce1ac1-28dc-42af-8fd8-b0714475be6b@www.fastmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help


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

> I was testing this myself yesterday.
>=20
> 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)=3D=3D0x1c48d80 and =
dmat->alignment-1=3D=3D0xff
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)=3D=3D0x1c48a80 and =
dmat->alignment-1=3D=3D0xff
Jan  1 17:49:08 FBSDG4S2 kernel: bus_dmamem_alloc failed to align memory =
properly.
Jan  1 17:49:08 FBSDG4S2 kernel: vtophys(*vaddr)=3D=3D0x1c48a80 and =
dmat->alignment-1=3D=3D0xff
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=20

FYI:

# ofwdump -ap
Node 0x38: device-tree
  phandle:
    ff 88 11 a8=20
  model:
    50 6f 77 65 72 4d 61 63 33 2c 36 00=20
    '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  =3D 2115649536 (2017 MB)
Jan  1 17:49:08 FBSDG4S2 kernel: avail memory =3D 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.]
>>=20
>> On 2020-Dec-30, at 17:07, Mark Millard <marklmi at yahoo.com> wrote:
>>=20
>>> 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 .
>>>=20
>>> "2cpus_booted" means things booted and worked normally.
>>>=20
>>> "1cpuwoke_" means that the following was reported:
>>>=20
>>> SMP: 2 CPUs found; 2 CPUs usable; 1 CPUs woken
>>>=20
>>> "_hung" means that it appeared to stop without reporting a crash. =
Never
>>> got to login prompt.
>>>=20
>>> "crashes_quickly" means that the the kernel did not get very far =
before
>>> the crash happened.
>>>=20
>>> -rw-r--r--   1 root  wheel  19179328 May 25 21:44:01 2020 =
kernel-r361494-2cpus_booted.txz
>>>=20
>>> Note: No artifact kernel.txz files for the range -r361495 .. =
-r361583 .
>>> powerpc checkins in that range include:
>>>=20
>>> -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)
>>>=20
>>> -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
>>>=20
>>> 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.)
>>>=20
>>> -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
>>>=20
>>> 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.)
>>=20
>> Note: for the below kernel builds I provided a "int yydebug;" for:
>>=20
>> usr.bin/localedef/localedef.c
>>=20
>> so kernel-toolchain could build (avoiding a link failure).
>>=20
>> Other than that, the kernel builds are of pure code from git using=20
>> KERNCONF=3DGENERIC ,
>> TARGET=3Dpowerpc , TARGET_ARCH=3Dpowerpc and no other tailoring, =
avoiding=20
>> any questions
>> about my personal patches contributing.
>>=20
>>=20
>> -r361542 (64cc3b0c28b9) : [PowerPC] Fix invalid asm in trap code =
(Brandon)
>>=20
>> Things booted and worked as expected.
>>=20
>>=20
>> -r361544 (45b69dd63e84) : powerpc/mmu: Convert PowerPC pmap drivers =
to=20
>> ifunc from kobj (Justin)
>>=20
>> SMP: 2 CPUs found; 2 CPUs usable; 1 CPUs woken
>>=20
>> was reported and it appeared to stop without reporting a crash. Never
>> got to login prompt.
>>=20
>>=20
>> NOTE: -r361453 was on stable/ instead of head/ so the above is a
>> works-then-fails pair with nothing between on CURRENT.
>=20
>=20

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F6B1536C-51D8-4ABD-BCA8-A045C7E7E2E6>