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-64Assignee: 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)

Description Erhard F. 2018-04-23 01:45:27 UTC
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.
Comment 1 Erhard F. 2018-04-23 01:46:14 UTC
Created attachment 275505 [details]
4.17-rc1 kernel config
Comment 2 Erhard F. 2018-04-23 01:48:41 UTC
Created attachment 275507 [details]
4.16.03 dmesg
Comment 3 Erhard F. 2018-04-23 01:49:17 UTC
Created attachment 275509 [details]
4.17-rc1 dmesg
Comment 4 Michael Ellerman 2018-05-01 10:15:41 UTC
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?
Comment 5 Erhard F. 2018-05-06 22:11:11 UTC
Nope, unfortunately no luck with rc3.
Comment 6 Erhard F. 2018-06-13 01:00:56 UTC
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.
Comment 7 Dennis Clarke 2018-10-14 01:28:40 UTC
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.
Comment 8 Wolfram Sang 2020-02-25 15:29:02 UTC
"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?
Comment 9 Erhard F. 2020-03-01 19:14:34 UTC
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
Comment 10 Erhard F. 2020-03-01 19:17:30 UTC
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(+)
Comment 11 Erhard F. 2020-03-01 19:46:12 UTC
(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.
Comment 12 Erhard F. 2020-03-01 20:02:45 UTC
Created attachment 287745 [details]
dmesg (kernel 4.16.18, PowerMac G5 11,2)
Comment 13 Erhard F. 2020-03-01 20:10:02 UTC
Created attachment 287747 [details]
kernel .config (kernel 4.17, PowerMac G5 11,2)
Comment 14 Erhard F. 2020-03-01 20:10:40 UTC
Created attachment 287749 [details]
dmesg (kernel 4.17, PowerMac G5 11,2)
Comment 15 Wolfram Sang 2020-03-02 13:13:00 UTC
"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.
Comment 16 Wolfram Sang 2020-03-02 14:48:49 UTC
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.
Comment 17 Erhard F. 2020-03-02 15:39:23 UTC
(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");
Comment 18 Erhard F. 2020-03-02 15:40:17 UTC
Created attachment 287757 [details]
dmesg (kernel 5.6-rc4 + patch, PowerMac G5 11,2)
Comment 19 Wolfram Sang 2020-03-03 12:54:12 UTC
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.
Comment 20 Dennis Clarke 2020-04-23 01:21:10 UTC

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
Comment 21 Erhard F. 2020-04-23 01:36:53 UTC
(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.
Comment 22 Wolfram Sang 2020-04-23 06:11:51 UTC
Fixed upstream with commit bcf3588d8ed3517e6ffaf083f034812aee9dc8e2.
Comment 23 Michael Ellerman 2020-04-24 03:12:25 UTC
The memory leak is a separate issue, see bug #206695.

Can anyone verify that bcf3588d8ed fixes the original issue?
Comment 24 Wolfram Sang 2020-04-24 07:55:29 UTC
@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.
Comment 25 Erhard F. 2020-04-24 18:33:59 UTC
(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.
Comment 26 Michael Ellerman 2020-04-28 03:14:47 UTC
OK thanks all.