Bug 199471
Summary: | [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set | ||
---|---|---|---|
Product: | Platform Specific/Hardware | Reporter: | Erhard F. (erhard_f) |
Component: | PPC-64 | Assignee: | platform_ppc-64 |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | dclarke, glaubitz, mathieu.malaterre, michael, rbthomas, wsa |
Priority: | P1 | ||
Hardware: | PPC-64 | ||
OS: | Linux | ||
Kernel Version: | 4.17-rc1 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: |
4.16.03 kernel config
4.17-rc1 kernel config 4.16.03 dmesg 4.17-rc1 dmesg kernel .config (kernel 4.16, PowerMac G5 11,2) bisect.log dmesg (kernel 4.16.18, PowerMac G5 11,2) kernel .config (kernel 4.17, PowerMac G5 11,2) dmesg (kernel 4.17, PowerMac G5 11,2) proof-of-concept patch for testing dmesg (kernel 5.6-rc4 + patch, PowerMac G5 11,2) |
Created attachment 275505 [details]
4.17-rc1 kernel config
Created attachment 275507 [details]
4.16.03 dmesg
Created attachment 275509 [details]
4.17-rc1 dmesg
Thanks for the report. I don't see any change that explains this, and it wasn't something we (powerpc) did on purpose. I assume it hasn't magically been fixed in rc3? Nope, unfortunately no luck with rc3. Situation stays the same on 4.17.0, 4.17.1. However, there is a workaround: In addition to CONFIG_I2C_POWERMAC=y you need to compile "Device Drivers → Macintosh device drivers → WINDFARM=y" statically into the kernel. Then, the relevant WINDFARM_xx module gets automatically loaded again. Don't know if/how this bug affects other machines/arches as well. Maybe it just can be closed, as it is only a change of the default behauviour (at least on my G5 7,3), but one that can be compensated. Tested this. On 4.18.14 the windfarm_pm72 module is not seen at all after : nix# grep CONFIG_I2C_POWERMAC .config CONFIG_I2C_POWERMAC=y nix# grep WINDFARM .config CONFIG_WINDFARM=y CONFIG_WINDFARM_PM81=m CONFIG_WINDFARM_PM72=y CONFIG_WINDFARM_RM31=m CONFIG_WINDFARM_PM91=y CONFIG_WINDFARM_PM112=y CONFIG_WINDFARM_PM121=y nix# Hard to know if this patch has any effect. "This has been quite nice since 4.?.x up to 4.16.x as you only need CONFIG_I2C_POWERMAC=y which selects the proper windfarm_pmXX at boot time." I can't find that in the code. Are you sure i2c-powermac requested that module? Created attachment 287741 [details]
kernel .config (kernel 4.16, PowerMac G5 11,2)
With the attached kernel .config the G5 7,3 and the G5 11,2 automatically load the suitable windfarm module on kernel <4.17. Starting from kernel 4.17 windfarm core needs to be CONFIG_WINDFARM=y to automacitally load the suitable windfarm module, CONFIG_WINDFARM=m is no longer sufficient.
Needed for 4.16.x to automatically load the suitable windfarm module:
# grep -i wind .config
CONFIG_WINDFARM=m
CONFIG_WINDFARM_PM81=m
CONFIG_WINDFARM_PM72=m
CONFIG_WINDFARM_RM31=m
CONFIG_WINDFARM_PM91=m
CONFIG_WINDFARM_PM112=m
CONFIG_WINDFARM_PM121=m
Needed for >=4.17.x to automatically load the suitable windfarm module:
# grep -i wind .config
CONFIG_WINDFARM=y
CONFIG_WINDFARM_PM81=m
CONFIG_WINDFARM_PM72=m
CONFIG_WINDFARM_RM31=m
CONFIG_WINDFARM_PM91=m
CONFIG_WINDFARM_PM112=m
CONFIG_WINDFARM_PM121=m
Created attachment 287743 [details] bisect.log Finally checked on that bug again and bisected it. The offending commit is: # git bisect bad | tee -a ~/bisect02.log af503716ac1444db61d80cb6d17cfe62929c21df is the first bad commit commit af503716ac1444db61d80cb6d17cfe62929c21df Author: Javier Martinez Canillas <javierm@redhat.com> Date: Sun Dec 3 22:40:50 2017 +0100 i2c: core: report OF style module alias for devices registered via OF The buses should honor the firmware interface used to register the device, but the I2C core reports a MODALIAS of the form i2c:<device> even for I2C devices registered via OF. This means that user-space will never get an OF stype uevent MODALIAS even when the drivers modules contain aliases exported from both the I2C and OF device ID tables. For example, an Atmel maXTouch Touchscreen registered by a DT node with compatible "atmel,maxtouch" has the following module alias: $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias i2c:maxtouch So udev won't be able to auto-load a module for an OF-only device driver. Many OF-only drivers duplicate the OF device ID table entries in an I2C ID table only has a workaround for how the I2C core reports the module alias. This patch changes the I2C core to report an OF related MODALIAS uevent if the device was registered via OF. So for the previous example, after this patch, the reported MODALIAS for the Atmel maXTouch will be the following: $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias of:NtrackpadT<NULL>Catmel,maxtouch NOTE: This patch may break out-of-tree drivers that were relying on this behavior, and only had an I2C device ID table even when the device was registered via OF. There are no remaining drivers in mainline that do this, but out-of-tree drivers have to be fixed and define a proper OF device ID table to have module auto-loading working. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Dmitry Mastykin <mastichi@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> drivers/i2c/i2c-core-base.c | 8 ++++++++ 1 file changed, 8 insertions(+) (In reply to Wolfram Sang from comment #8) > "This has been quite nice since 4.?.x up to 4.16.x as you only need > CONFIG_I2C_POWERMAC=y which selects the proper windfarm_pmXX at boot time." > > I can't find that in the code. Are you sure i2c-powermac requested that > module? I guess so 'cause if I build i2c_powermac as a module and manually modprobe it, all the relevant windfarm modules get pulled in. But not before. # modprobe -v i2c_powermac insmod /lib/modules/4.16.18-PowerMacG5+/kernel/drivers/i2c/busses/i2c-powermac.ko # dmesg | tail [ 150.181478] 11 [ 150.182851] 0 [ 150.184220] 0 [ 150.626685] windfarm: Backside control loop started. [ 150.690132] windfarm: Slots control loop started. [ 150.794843] i2c i2c-0: master_xfer[0] W, addr=0x50, len=1 [ 150.796467] i2c i2c-0: master_xfer[1] R, addr=0x50, len=8 [ 150.801851] i2c i2c-0: NAK from device addr 0x50 msg #0 [ 150.807758] windfarm: Drive bay control loop started. Created attachment 287745 [details]
dmesg (kernel 4.16.18, PowerMac G5 11,2)
Created attachment 287747 [details]
kernel .config (kernel 4.17, PowerMac G5 11,2)
Created attachment 287749 [details]
dmesg (kernel 4.17, PowerMac G5 11,2)
"I guess so 'cause if I build i2c_powermac as a module and manually modprobe it, all the relevant windfarm modules get pulled in. But not before." Maybe there is a module dependency I overlooked so far, but at least there is no code loading the pm72 module from i2c-powermac. However, the bisect is very valuable and very likely the commit is the culprit. I was suspecting something changed the MODINFO, so loading fails, but I missed this commit, so far. Also, it took me two approaches until I understood all the behaviour involved. Macintosh drivers are still confusing. I will cook up a patch to test later today to see if I was right. Created attachment 287755 [details]
proof-of-concept patch for testing
Here is the promised patch. I converted all I2C MODULE tables. pm72 didn't have one, so we will see what pulls it in.
A test with a machine needing the lm75 driver would be great. Because some code change was needed there.
(In reply to Wolfram Sang from comment #16) > Created attachment 287755 [details] > proof-of-concept patch for testing > > Here is the promised patch. I converted all I2C MODULE tables. pm72 didn't > have one, so we will see what pulls it in. > > A test with a machine needing the lm75 driver would be great. Because some > code change was needed there. Excellent! Applied your patch on 5.6-rc4 and it just works fine on my G5 11,2! I can leave CONFIG_WINDFARM=m and the correct modules get pulled in just as it was before kernel 4.17. I can't test on the G5 7,3 from my original bug report 'cause I sold this one. But from my understanding this "lm75" sensor is used in pretty any windfarm_pm* module? # grep -i lm75 drivers/macintosh/windfarm_pm*.c drivers/macintosh/windfarm_pm112.c: request_module("windfarm_lm75_sensor"); drivers/macintosh/windfarm_pm121.c: request_module("windfarm_lm75_sensor"); drivers/macintosh/windfarm_pm72.c: request_module("windfarm_lm75_sensor"); drivers/macintosh/windfarm_pm81.c: request_module("windfarm_lm75_sensor"); drivers/macintosh/windfarm_pm91.c: request_module("windfarm_lm75_sensor"); Created attachment 287757 [details]
dmesg (kernel 5.6-rc4 + patch, PowerMac G5 11,2)
Well, yes, the lm75 code gets loaded yet it is not clear to me if the device is now created by DT or not. Well, we will see... Patch sent out: http://patchwork.ozlabs.org/patch/1248349/ Let's discuss this one. The proof-of-concept here had a missing line but worked enough. Possibly unrelated but there appears to be a small memory leak within windfarm_* somewhere given that I see traffic in kmemleak : enceladus# enceladus# uname -a Linux enceladus 5.7.0-rc2 #1 SMP Tue Apr 21 23:32:43 UTC 2020 ppc64 GNU/Linux enceladus# lsmod | grep 'farm' windfarm_cpufreq_clamp 4640 1 windfarm_smu_sensors 9548 1 windfarm_smu_controls 9078 8 windfarm_pm112 15935 0 windfarm_pid 4378 1 windfarm_pm112 windfarm_smu_sat 9802 9 windfarm_pm112 windfarm_max6690_sensor 5434 1 windfarm_lm75_sensor 6148 1 windfarm_core 16619 7 windfarm_cpufreq_clamp,windfarm_smu_controls,windfarm_max6690_sensor,windfarm_smu_sat,windfarm_smu_sensors,windfarm_lm75_sensor,windfarm_pm112 enceladus# enceladus# cat /sys/kernel/debug/kmemleak unreferenced object 0xc00000000867a6a0 (size 32): comm "kwindfarm", pid 175, jiffies 4294894706 (age 1843.540s) hex dump (first 32 bytes): c8 06 02 7f ff 02 ff 01 fb bf 00 59 00 20 00 00 ...........Y. .. 00 07 89 37 00 a0 00 00 6b 6b 6b 6b 6b 6b 6b a5 ...7....kkkkkkk. backtrace: [<00000000fce2b937>] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<00000000e6cc23fc>] .pm112_wf_notify+0x624/0x1460 [windfarm_pm112] [<000000008cdab940>] .notifier_call_chain+0x88/0xf0 [<000000008f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<0000000045480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<0000000079c8bd6f>] .kthread+0x1b8/0x1d0 [<0000000073e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc0000002612a15a0 (size 16): comm "kwindfarm", pid 175, jiffies 4294894926 (age 1842.660s) hex dump (first 16 bytes): c4 04 01 7f a0 12 20 5f ff 55 b8 14 7b 12 00 00 ...... _.U..{... backtrace: [<00000000fce2b937>] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<0000000050e586af>] .pm112_wf_notify+0x66c/0x1460 [windfarm_pm112] [<000000008cdab940>] .notifier_call_chain+0x88/0xf0 [<000000008f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<0000000045480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<0000000079c8bd6f>] .kthread+0x1b8/0x1d0 [<0000000073e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc00000000867ba20 (size 32): comm "kwindfarm", pid 175, jiffies 4294895089 (age 1842.008s) hex dump (first 32 bytes): c9 06 02 7f ff 02 ff 01 fb bf 00 59 00 20 00 00 ...........Y. .. 00 07 89 37 00 a0 00 00 6b 6b 6b 6b 6b 6b 6b a5 ...7....kkkkkkk. backtrace: [<00000000fce2b937>] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<00000000e6cc23fc>] .pm112_wf_notify+0x624/0x1460 [windfarm_pm112] [<000000008cdab940>] .notifier_call_chain+0x88/0xf0 [<000000008f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<0000000045480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<0000000079c8bd6f>] .kthread+0x1b8/0x1d0 [<0000000073e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc0000000061a8740 (size 16): comm "kwindfarm", pid 175, jiffies 4294895309 (age 1841.128s) hex dump (first 16 bytes): c5 04 01 7f a0 12 20 5f ff 55 29 14 7b 12 00 00 ...... _.U).{... backtrace: [<00000000fce2b937>] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<0000000050e586af>] .pm112_wf_notify+0x66c/0x1460 [windfarm_pm112] [<000000008cdab940>] .notifier_call_chain+0x88/0xf0 [<000000008f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<0000000045480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<0000000079c8bd6f>] .kthread+0x1b8/0x1d0 [<0000000073e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc0000000061ab6e0 (size 32): comm "kwindfarm", pid 175, jiffies 4294895473 (age 1840.472s) hex dump (first 32 bytes): c8 06 02 7f ff 02 ff 01 fb bf 00 59 00 20 00 00 ...........Y. .. 00 07 89 37 00 a0 00 00 6b 6b 6b 6b 6b 6b 6b a5 ...7....kkkkkkk. backtrace: [<00000000fce2b937>] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<00000000e6cc23fc>] .pm112_wf_notify+0x624/0x1460 [windfarm_pm112] [<000000008cdab940>] .notifier_call_chain+0x88/0xf0 [<000000008f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<0000000045480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<0000000079c8bd6f>] .kthread+0x1b8/0x1d0 [<0000000073e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc0000000061a8b90 (size 16): comm "kwindfarm", pid 175, jiffies 4294895693 (age 1839.600s) hex dump (first 16 bytes): c4 04 01 7f a0 12 20 5f ff 55 b8 14 7b 12 00 00 ...... _.U..{... backtrace: [<00000000fce2b937>] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<0000000050e586af>] .pm112_wf_notify+0x66c/0x1460 [windfarm_pm112] [<000000008cdab940>] .notifier_call_chain+0x88/0xf0 [<000000008f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<0000000045480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<0000000079c8bd6f>] .kthread+0x1b8/0x1d0 [<0000000073e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc0000000061aa9e0 (size 32): comm "kwindfarm", pid 175, jiffies 4294895857 (age 1838.944s) hex dump (first 32 bytes): c9 06 02 7f ff 02 ff 01 fb bf 00 59 00 20 00 00 ...........Y. .. 00 07 89 37 00 a0 00 00 6b 6b 6b 6b 6b 6b 6b a5 ...7....kkkkkkk. backtrace: [<00000000fce2b937>] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<00000000e6cc23fc>] .pm112_wf_notify+0x624/0x1460 [windfarm_pm112] [<000000008cdab940>] .notifier_call_chain+0x88/0xf0 [<000000008f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<0000000045480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<0000000079c8bd6f>] .kthread+0x1b8/0x1d0 [<0000000073e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc00000025aacd2c0 (size 16): comm "kwindfarm", pid 175, jiffies 4294896076 (age 1838.068s) hex dump (first 16 bytes): c5 04 01 7f a0 12 20 5f ff 55 d7 15 7b 12 00 00 ...... _.U..{... backtrace: [<00000000fce2b937>] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<0000000050e586af>] .pm112_wf_notify+0x66c/0x1460 [windfarm_pm112] [<000000008cdab940>] .notifier_call_chain+0x88/0xf0 [<000000008f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<0000000045480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<0000000079c8bd6f>] .kthread+0x1b8/0x1d0 [<0000000073e2b812>] .ret_from_kernel_thread+0x58/0x74 enceladus# enceladus# cat /sys/kernel/debug/kmemleak unreferenced object 0xc00000000867a6a0 (size 32): comm "kwindfarm", pid 175, jiffies 4294894706 (age 4736.636s) hex dump (first 32 bytes): c8 06 02 7f ff 02 ff 01 fb bf 00 59 00 20 00 00 ...........Y. .. 00 07 89 37 00 a0 00 00 6b 6b 6b 6b 6b 6b 6b a5 ...7....kkkkkkk. backtrace: [<00000000fce2b937>] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<00000000e6cc23fc>] .pm112_wf_notify+0x624/0x1460 [windfarm_pm112] [<000000008cdab940>] .notifier_call_chain+0x88/0xf0 [<000000008f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<0000000045480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<0000000079c8bd6f>] .kthread+0x1b8/0x1d0 [<0000000073e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc0000002612a15a0 (size 16): comm "kwindfarm", pid 175, jiffies 4294894926 (age 4735.756s) hex dump (first 16 bytes): c4 04 01 7f a0 12 20 5f ff 55 b8 14 7b 12 00 00 ...... _.U..{... backtrace: [<00000000fce2b937>] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<0000000050e586af>] .pm112_wf_notify+0x66c/0x1460 [windfarm_pm112] [<000000008cdab940>] .notifier_call_chain+0x88/0xf0 [<000000008f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<0000000045480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<0000000079c8bd6f>] .kthread+0x1b8/0x1d0 [<0000000073e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc00000000867ba20 (size 32): comm "kwindfarm", pid 175, jiffies 4294895089 (age 4735.104s) hex dump (first 32 bytes): c9 06 02 7f ff 02 ff 01 fb bf 00 59 00 20 00 00 ...........Y. .. 00 07 89 37 00 a0 00 00 6b 6b 6b 6b 6b 6b 6b a5 ...7....kkkkkkk. backtrace: [<00000000fce2b937>] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<00000000e6cc23fc>] .pm112_wf_notify+0x624/0x1460 [windfarm_pm112] [<000000008cdab940>] .notifier_call_chain+0x88/0xf0 [<000000008f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<0000000045480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<0000000079c8bd6f>] .kthread+0x1b8/0x1d0 [<0000000073e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc0000000061a8740 (size 16): comm "kwindfarm", pid 175, jiffies 4294895309 (age 4734.224s) hex dump (first 16 bytes): c5 04 01 7f a0 12 20 5f ff 55 29 14 7b 12 00 00 ...... _.U).{... backtrace: [<00000000fce2b937>] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<0000000050e586af>] .pm112_wf_notify+0x66c/0x1460 [windfarm_pm112] [<000000008cdab940>] .notifier_call_chain+0x88/0xf0 [<000000008f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<0000000045480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<0000000079c8bd6f>] .kthread+0x1b8/0x1d0 [<0000000073e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc0000000061ab6e0 (size 32): comm "kwindfarm", pid 175, jiffies 4294895473 (age 4733.568s) hex dump (first 32 bytes): c8 06 02 7f ff 02 ff 01 fb bf 00 59 00 20 00 00 ...........Y. .. 00 07 89 37 00 a0 00 00 6b 6b 6b 6b 6b 6b 6b a5 ...7....kkkkkkk. backtrace: [<00000000fce2b937>] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<00000000e6cc23fc>] .pm112_wf_notify+0x624/0x1460 [windfarm_pm112] [<000000008cdab940>] .notifier_call_chain+0x88/0xf0 [<000000008f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<0000000045480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<0000000079c8bd6f>] .kthread+0x1b8/0x1d0 [<0000000073e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc0000000061a8b90 (size 16): comm "kwindfarm", pid 175, jiffies 4294895693 (age 4732.696s) hex dump (first 16 bytes): c4 04 01 7f a0 12 20 5f ff 55 b8 14 7b 12 00 00 ...... _.U..{... backtrace: [<00000000fce2b937>] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<0000000050e586af>] .pm112_wf_notify+0x66c/0x1460 [windfarm_pm112] [<000000008cdab940>] .notifier_call_chain+0x88/0xf0 [<000000008f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<0000000045480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<0000000079c8bd6f>] .kthread+0x1b8/0x1d0 [<0000000073e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc0000000061aa9e0 (size 32): comm "kwindfarm", pid 175, jiffies 4294895857 (age 4732.040s) hex dump (first 32 bytes): c9 06 02 7f ff 02 ff 01 fb bf 00 59 00 20 00 00 ...........Y. .. 00 07 89 37 00 a0 00 00 6b 6b 6b 6b 6b 6b 6b a5 ...7....kkkkkkk. backtrace: [<00000000fce2b937>] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<00000000e6cc23fc>] .pm112_wf_notify+0x624/0x1460 [windfarm_pm112] [<000000008cdab940>] .notifier_call_chain+0x88/0xf0 [<000000008f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<0000000045480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<0000000079c8bd6f>] .kthread+0x1b8/0x1d0 [<0000000073e2b812>] .ret_from_kernel_thread+0x58/0x74 unreferenced object 0xc00000025aacd2c0 (size 16): comm "kwindfarm", pid 175, jiffies 4294896076 (age 4731.164s) hex dump (first 16 bytes): c5 04 01 7f a0 12 20 5f ff 55 d7 15 7b 12 00 00 ...... _.U..{... backtrace: [<00000000fce2b937>] .smu_sat_get_sdb_partition+0x150/0x2f0 [windfarm_smu_sat] [<0000000050e586af>] .pm112_wf_notify+0x66c/0x1460 [windfarm_pm112] [<000000008cdab940>] .notifier_call_chain+0x88/0xf0 [<000000008f026422>] .__blocking_notifier_call_chain+0x6c/0xc0 [<0000000045480c67>] .wf_thread_func+0xe4/0x1e0 [windfarm_core] [<0000000079c8bd6f>] .kthread+0x1b8/0x1d0 [<0000000073e2b812>] .ret_from_kernel_thread+0x58/0x74 enceladus# I will take a look into it and see what I can see. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional (In reply to Dennis Clarke from comment #20) > > Possibly unrelated but there appears to be a small memory leak within > windfarm_* somewhere given that I see traffic in kmemleak : > > [...] > > I will take a look into it and see what I can see. Thanks, but probably there's no need to. ;) There is already a patch floating around in the bug where I reported the memleak originally: https://bugzilla.kernel.org/show_bug.cgi?id=206695 The patch just didn't went upstream yet. Fixed upstream with commit bcf3588d8ed3517e6ffaf083f034812aee9dc8e2. The memory leak is a separate issue, see bug #206695. Can anyone verify that bcf3588d8ed fixes the original issue? @Michael: commit bcf3588d8ed has the following tags: Reported-by: Erhard Furtner <erhard_f@mailbox.org> Tested-by: Erhard Furtner <erhard_f@mailbox.org> And Erhard is also the one who created this bug entry. (In reply to Michael Ellerman from comment #23) > The memory leak is a separate issue, see bug #206695. > > Can anyone verify that bcf3588d8ed fixes the original issue? Yes, thanks to Wolframs patch the WINDFARM_PM112 is automatically loaded again when built as a module. So my original issue is fixed with that commit. OK thanks all. |
Created attachment 275503 [details] 4.16.03 kernel config I noticed that with 4.17-rc1 the windfarm_pm72 module (necessary for fan control on some PowerMacs) no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is built statically into the kernel. This has been quite nice since 4.?.x up to 4.16.x as you only need CONFIG_I2C_POWERMAC=y which selects the proper windfarm_pmXX at boot time. On my PowerMac G5 7,3 with 4.17-rc1 I need to manually load the module, despite CONFIG_I2C_POWERMAC=y is set: # modprobe -v windfarm_pm72 insmod /lib/modules/4.17.0-rc1/kernel/drivers/macintosh/windfarm_core.ko insmod /lib/modules/4.17.0-rc1/kernel/drivers/macintosh/windfarm_pid.ko insmod /lib/modules/4.17.0-rc1/kernel/drivers/macintosh/windfarm_pm72.ko Not a big deal, I know and maybe this change is even intentional. But maybe it's a side effect of some other change or a bug.