Date: Tue, 9 Apr 2019 23:27:30 -0700 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: head -r345758 32-bit powerpc FreeBSD (used on a PowerMac G5): usefdt mode breaks cpufreq (and so powerd) Message-ID: <4110295C-FB5B-4197-B573-DF57D19C9103@yahoo.com>
next in thread | raw e-mail | index | archive | help
When I boot the PowerMac11,2 G5 (2 sockets, 2 cores each) via 32-bit powerpc FreeBSD without usefdt mode, cpufreq and powerpd work normally. But with usefdt cpufreq ends up only existing for cpu3: # sysctl -a | grep freq kern.timecounter.tc.timebase.frequency: 33333333 device cpufreq kern.eventtimer.et.decrementer.frequency: 33333333 kern.acct_chkfreq: 15 net.inet.sctp.sack_freq: 2 debug.cpufreq.lowest: 0 debug.cpufreq.verbose: 0 debug.uart_poll_freq: 50 dev.cpufreq.0.%parent: cpu3 dev.cpufreq.0.%pnpinfo:=20 dev.cpufreq.0.%location:=20 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%desc:=20 dev.cpufreq.%parent:=20 dev.pcr.3.freq_settings: 10000/-1 5000/-1 dev.cpu.3.freq_levels: 2500/-1 1250/-1 dev.cpu.3.freq: 1250 dev.iicbus.3.frequency: 100000 dev.iicbus.2.frequency: 100000 dev.iicbus.1.frequency: 100000 dev.iicbus.0.frequency: 100000 powerpd ends up reporting "no cpufreq(4) support -- aborting". (Note: non-usefdt boots list dev.cpufreq material for all 4 cpus, not just cpu3, and powerd works in that context.) Part of this *may* be an ordering issue: usefdt mode has the traversal order (just showing cpu# examples): /device-tree/cpus/PowerPC,G5/cpu#: hex_bytes_line# 0: 00 00 00 03 /device-tree/cpus/PowerPC,G5/cpu#: txt_bytes_line# 0: \000\000\000\^C /device-tree/cpus/PowerPC,G5/cpu#: hex_bytes_line# 0: 00 00 00 02 /device-tree/cpus/PowerPC,G5/cpu#: txt_bytes_line# 0: \000\000\000\^B /device-tree/cpus/PowerPC,G5/cpu#: hex_bytes_line# 0: 00 00 00 01 /device-tree/cpus/PowerPC,G5/cpu#: txt_bytes_line# 0: \000\000\000\^A /device-tree/cpus/PowerPC,G5/cpu#: hex_bytes_line# 0: 00 00 00 00 /device-tree/cpus/PowerPC,G5/cpu#: txt_bytes_line# 0: \000\000\000\000 but non-usefdt mode (the historical order) has the order: /device-tree/cpus/PowerPC,G5/cpu#: hex_bytes_line# 0: 00 00 00 00 /device-tree/cpus/PowerPC,G5/cpu#: txt_bytes_line# 0: \000\000\000\000 /device-tree/cpus/PowerPC,G5/cpu#: hex_bytes_line# 0: 00 00 00 01 /device-tree/cpus/PowerPC,G5/cpu#: txt_bytes_line# 0: \000\000\000\^A /device-tree/cpus/PowerPC,G5/cpu#: hex_bytes_line# 0: 00 00 00 02 /device-tree/cpus/PowerPC,G5/cpu#: txt_bytes_line# 0: \000\000\000\^B /device-tree/cpus/PowerPC,G5/cpu#: hex_bytes_line# 0: 00 00 00 03 /device-tree/cpus/PowerPC,G5/cpu#: txt_bytes_line# 0: \000\000\000\^C If some code expects the sequence to be increasing, it might only pick up the first one (cpu3) for usefdt mode. (The outputs are from my own tool that I run its output through sort -s -k1,1 . Thus, the common prefix text is grouped together, but in the original relative ordering. The tool in turn uses code from ofwdump.) This is far from the only type of thing that ends up reversed from the historical order in usefdt mode. Another possible contribution to lack of some froms of control is the notice that usefdt mode gives out: Error -2 adding node /ht@0,f2000000/pci@8/mac-io@7/i2c@18000/i2c-bus@0 = (i2c-bus@0), skipping (I'm using 32-bit powerpc FreeBSD because there are more problems for powerpc64 FreeBSD: in non-usefdt mode ofwdump or tools like it get system crashes for "timeout stopping cpus" or other such. This goes back to at least -r333596 (but not to -r302214). ofwdump works in 32-bit powerpc FreeBSD, no system crash.) =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?4110295C-FB5B-4197-B573-DF57D19C9103>