* Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-11-09 13:35 ` Nick
0 siblings, 0 replies; 75+ messages in thread
From: Nick @ 2022-11-09 13:35 UTC (permalink / raw)
To: jia-wei.chang, rex-bc.chen, angelogioacchino.delregno, viresh.kumar
Cc: linux-pm, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, Daniel Golle, Hühn,
Thomas
Hi,
while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the kernel
is crashing while booting on a Banana Pi R64 (MT7622):
> [ 1.055565] ------------[ cut here ]------------
> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose debug info unavailable]
> [ 1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
> [ 1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
> [ 1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
> [ 1.081257] Modules linked in:
> [ 1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G S 6.1-rc2 #0
> [ 1.087088] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff -> 0x0020000000
> [ 1.090126] Hardware name: Bananapi BPI-R64 (DT)
> [ 1.110541] Workqueue: events dbs_work_handler
> [ 1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 1.121944] pc : regulator_check_voltage+0xb0/0xf0
> [ 1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
> [ 1.129638] mmc1: host does not support reading read-only switch, assuming write-enable
> [ 1.132207] sp : ffffffc00956bb30
> [ 1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27: 0000000000000024
> [ 1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24: 00000000001312d0
> [ 1.132227] x23: 0000000000149970
> [ 1.146036] mmc1: new high speed SDHC card at address e624
> [ 1.150642] x22: ffffff800038f800
> [ 1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB
> [ 1.161068] x21: ffffff8000efb100
> [ 1.161072] x20: 00000000001312d0
> [ 1.175424] GPT:partition_entry_array_crc32 values don't match: 0xa0b5ce6d != 0xab54d286
> [ 1.177757] x19: 0000000000000000 x18: 00000000799b2550
> [ 1.181067] GPT:Primary header thinks Alt. header is not at the end of the disk.
> [ 1.189143] x17: 0000000000000003 x16: 0000000000000001 x15: 0000000000000000
> [ 1.189151] x14: 0000000000000000 x13: 0000000000000146 x12: 00000000fa83b2da
> [ 1.189159] x11: 000000000000013d x10: 0000000000000850
> [ 1.194472] GPT:305184 != 31116287
> [ 1.201842] x9 : ffffffc00956b910
> [ 1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
> [ 1.208970] GPT:Alternate GPT header not at the end of the disk.
> [ 1.216092] x6 : 00000000001312d0
> [ 1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 : 0000000000000000
> [ 1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
> [ 1.221321] GPT:305184 != 31116287
> [ 1.224706] x0 : ffffff800038f800
> [ 1.228095] GPT: Use GNU Parted to correct GPT errors.
> [ 1.233307]
> [ 1.233309] Call trace:
> [ 1.233312] regulator_check_voltage+0xb0/0xf0
> [ 1.242680] FIT: Selected configuration: "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64 with mt7622-bananapi-bpi-r64-pcie1)
> [ 1.242694] regulator_set_voltage+0x3c/0x64
> [ 1.249831] FIT: kernel sub-image 0x00001000..0x0052fd0a "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2)
> [ 1.255030] mtk_cpufreq_voltage_tracking+0x11c/0x26c
> [ 1.255039] mtk_cpufreq_set_target+0x1c4/0x350
> [ 1.258444] FIT: flat_dt sub-image 0x00530000..0x005380c5 "fdt-1" (ARM64 OpenWrt bananapi_bpi-r64 device tree blob)
> [ 1.261820] __cpufreq_driver_target+0x2f4/0x674
> [ 1.261826] od_dbs_update+0xb8/0x19c
> [ 1.266969] FIT: flat_dt sub-image 0x00539000..0x0053911a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64 OpenWrt bananapi_bpi-r64 device tree overlay mt7622-bananapi-bpi-r64-pcie1)
> [ 1.268431] dbs_work_handler+0x3c/0x7c
> [ 1.270883] FIT: flat_dt sub-image 0x0053a000..0x0053a20f "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64 OpenWrt bananapi_bpi-r64 device tree overlay mt7622-bananapi-bpi-r64-sata)
> [ 1.275297] process_one_work+0x200/0x3a0
> [ 1.287998] FIT: filesystem sub-image 0x0053b000..0x00859fff "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs)
> [ 1.292237] worker_thread+0x170/0x4c0
> [ 1.292244] kthread+0xd4/0xe0
> [ 1.302066] FIT: selecting configured loadable "rootfs-1" to be root filesystem
> [ 1.307092] ret_from_fork+0x10/0x20
> [ 1.311631] mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1) p66(rootfs_data) p128
> [ 1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
> [ 1.413322] ---[ end trace 0000000000000000 ]---
The complete log can be found here:
https://gist.githubusercontent.com/PolynomialDivision/395d009c84b426d780549c5fa1f64ff1/raw/886d621d2bf6f03429586adf8a14a6c37c8d8a7d/mt7622-6-1.log
Reverting commit "cpufreq: mediatek: Refine
mtk_cpufreq_voltage_tracking()" fixes the kernel bug:
https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
The revert commit can be found here:
https://github.com/PolynomialDivision/openwrt/commit/1df941d0334000e3aced43b7d50cdac0da8bf427
The branch I use to build the 6.1rc2 on a Banana Pi R64 can be found here:
https://github.com/PolynomialDivision/openwrt/commits/bump-mt7622-rebase
Bests
Nick
^ permalink raw reply [flat|nested] 75+ messages in thread
* Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-11-09 13:35 ` Nick
0 siblings, 0 replies; 75+ messages in thread
From: Nick @ 2022-11-09 13:35 UTC (permalink / raw)
To: jia-wei.chang, rex-bc.chen, angelogioacchino.delregno, viresh.kumar
Cc: linux-pm, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, Daniel Golle, Hühn,
Thomas
Hi,
while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the kernel
is crashing while booting on a Banana Pi R64 (MT7622):
> [ 1.055565] ------------[ cut here ]------------
> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose debug info unavailable]
> [ 1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
> [ 1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
> [ 1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
> [ 1.081257] Modules linked in:
> [ 1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G S 6.1-rc2 #0
> [ 1.087088] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff -> 0x0020000000
> [ 1.090126] Hardware name: Bananapi BPI-R64 (DT)
> [ 1.110541] Workqueue: events dbs_work_handler
> [ 1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 1.121944] pc : regulator_check_voltage+0xb0/0xf0
> [ 1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
> [ 1.129638] mmc1: host does not support reading read-only switch, assuming write-enable
> [ 1.132207] sp : ffffffc00956bb30
> [ 1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27: 0000000000000024
> [ 1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24: 00000000001312d0
> [ 1.132227] x23: 0000000000149970
> [ 1.146036] mmc1: new high speed SDHC card at address e624
> [ 1.150642] x22: ffffff800038f800
> [ 1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB
> [ 1.161068] x21: ffffff8000efb100
> [ 1.161072] x20: 00000000001312d0
> [ 1.175424] GPT:partition_entry_array_crc32 values don't match: 0xa0b5ce6d != 0xab54d286
> [ 1.177757] x19: 0000000000000000 x18: 00000000799b2550
> [ 1.181067] GPT:Primary header thinks Alt. header is not at the end of the disk.
> [ 1.189143] x17: 0000000000000003 x16: 0000000000000001 x15: 0000000000000000
> [ 1.189151] x14: 0000000000000000 x13: 0000000000000146 x12: 00000000fa83b2da
> [ 1.189159] x11: 000000000000013d x10: 0000000000000850
> [ 1.194472] GPT:305184 != 31116287
> [ 1.201842] x9 : ffffffc00956b910
> [ 1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
> [ 1.208970] GPT:Alternate GPT header not at the end of the disk.
> [ 1.216092] x6 : 00000000001312d0
> [ 1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 : 0000000000000000
> [ 1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
> [ 1.221321] GPT:305184 != 31116287
> [ 1.224706] x0 : ffffff800038f800
> [ 1.228095] GPT: Use GNU Parted to correct GPT errors.
> [ 1.233307]
> [ 1.233309] Call trace:
> [ 1.233312] regulator_check_voltage+0xb0/0xf0
> [ 1.242680] FIT: Selected configuration: "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64 with mt7622-bananapi-bpi-r64-pcie1)
> [ 1.242694] regulator_set_voltage+0x3c/0x64
> [ 1.249831] FIT: kernel sub-image 0x00001000..0x0052fd0a "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2)
> [ 1.255030] mtk_cpufreq_voltage_tracking+0x11c/0x26c
> [ 1.255039] mtk_cpufreq_set_target+0x1c4/0x350
> [ 1.258444] FIT: flat_dt sub-image 0x00530000..0x005380c5 "fdt-1" (ARM64 OpenWrt bananapi_bpi-r64 device tree blob)
> [ 1.261820] __cpufreq_driver_target+0x2f4/0x674
> [ 1.261826] od_dbs_update+0xb8/0x19c
> [ 1.266969] FIT: flat_dt sub-image 0x00539000..0x0053911a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64 OpenWrt bananapi_bpi-r64 device tree overlay mt7622-bananapi-bpi-r64-pcie1)
> [ 1.268431] dbs_work_handler+0x3c/0x7c
> [ 1.270883] FIT: flat_dt sub-image 0x0053a000..0x0053a20f "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64 OpenWrt bananapi_bpi-r64 device tree overlay mt7622-bananapi-bpi-r64-sata)
> [ 1.275297] process_one_work+0x200/0x3a0
> [ 1.287998] FIT: filesystem sub-image 0x0053b000..0x00859fff "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs)
> [ 1.292237] worker_thread+0x170/0x4c0
> [ 1.292244] kthread+0xd4/0xe0
> [ 1.302066] FIT: selecting configured loadable "rootfs-1" to be root filesystem
> [ 1.307092] ret_from_fork+0x10/0x20
> [ 1.311631] mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1) p66(rootfs_data) p128
> [ 1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
> [ 1.413322] ---[ end trace 0000000000000000 ]---
The complete log can be found here:
https://gist.githubusercontent.com/PolynomialDivision/395d009c84b426d780549c5fa1f64ff1/raw/886d621d2bf6f03429586adf8a14a6c37c8d8a7d/mt7622-6-1.log
Reverting commit "cpufreq: mediatek: Refine
mtk_cpufreq_voltage_tracking()" fixes the kernel bug:
https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
The revert commit can be found here:
https://github.com/PolynomialDivision/openwrt/commit/1df941d0334000e3aced43b7d50cdac0da8bf427
The branch I use to build the 6.1rc2 on a Banana Pi R64 can be found here:
https://github.com/PolynomialDivision/openwrt/commits/bump-mt7622-rebase
Bests
Nick
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622) #forregzbot
2022-11-09 13:35 ` Nick
@ 2022-11-09 19:40 ` Thorsten Leemhuis
-1 siblings, 0 replies; 75+ messages in thread
From: Thorsten Leemhuis @ 2022-11-09 19:40 UTC (permalink / raw)
To: linux-arm-kernel, regressions; +Cc: linux-pm, linux-mediatek
[Note: this mail is primarily send for documentation purposes and/or for
regzbot, my Linux kernel regression tracking bot. That's why I removed
most or all folks from the list of recipients, but left any that looked
like a mailing lists. These mails usually contain '#forregzbot' in the
subject, to make them easy to spot and filter out.]
[TLDR: I'm adding this regression report to the list of tracked
regressions; all text from me you find below is based on a few templates
paragraphs you might have encountered already already in similar form.]
Hi, this is your Linux kernel regression tracker.
On 09.11.22 14:35, Nick wrote:
> Hi,
> while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the kernel
> is crashing while booting on a Banana Pi R64 (MT7622):
>
>> [ 1.055565] ------------[ cut here ]------------
>> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0
>> [verbose debug info unavailable]
[...]
> Reverting commit "cpufreq: mediatek: Refine
> mtk_cpufreq_voltage_tracking()" fixes the kernel bug:
> https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
Thanks for the report. To be sure below issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression
tracking bot:
#regzbot ^introduced 6a17b3876bc
#regzbot title cpufreq: mediatek: Kernel BUG at regulator_check_voltage
#regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply -- ideally with also
telling regzbot about it, as explained here:
https://linux-regtracking.leemhuis.info/tracked-regression/
Reminder for developers: When fixing the issue, add 'Link:' tags
pointing to the report (the mail this one replies to), as explained for
in the Linux kernel's documentation; above webpage explains why this is
important for tracked regressions.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622) #forregzbot
@ 2022-11-09 19:40 ` Thorsten Leemhuis
0 siblings, 0 replies; 75+ messages in thread
From: Thorsten Leemhuis @ 2022-11-09 19:40 UTC (permalink / raw)
To: linux-arm-kernel, regressions; +Cc: linux-pm, linux-mediatek
[Note: this mail is primarily send for documentation purposes and/or for
regzbot, my Linux kernel regression tracking bot. That's why I removed
most or all folks from the list of recipients, but left any that looked
like a mailing lists. These mails usually contain '#forregzbot' in the
subject, to make them easy to spot and filter out.]
[TLDR: I'm adding this regression report to the list of tracked
regressions; all text from me you find below is based on a few templates
paragraphs you might have encountered already already in similar form.]
Hi, this is your Linux kernel regression tracker.
On 09.11.22 14:35, Nick wrote:
> Hi,
> while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the kernel
> is crashing while booting on a Banana Pi R64 (MT7622):
>
>> [ 1.055565] ------------[ cut here ]------------
>> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0
>> [verbose debug info unavailable]
[...]
> Reverting commit "cpufreq: mediatek: Refine
> mtk_cpufreq_voltage_tracking()" fixes the kernel bug:
> https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
Thanks for the report. To be sure below issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression
tracking bot:
#regzbot ^introduced 6a17b3876bc
#regzbot title cpufreq: mediatek: Kernel BUG at regulator_check_voltage
#regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply -- ideally with also
telling regzbot about it, as explained here:
https://linux-regtracking.leemhuis.info/tracked-regression/
Reminder for developers: When fixing the issue, add 'Link:' tags
pointing to the report (the mail this one replies to), as explained for
in the Linux kernel's documentation; above webpage explains why this is
important for tracked regressions.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-11-09 13:35 ` Nick
@ 2022-11-10 11:26 ` Matthias Brugger
-1 siblings, 0 replies; 75+ messages in thread
From: Matthias Brugger @ 2022-11-10 11:26 UTC (permalink / raw)
To: Nick, jia-wei.chang, rex-bc.chen, angelogioacchino.delregno,
viresh.kumar, Frank Wunderlich
Cc: linux-pm, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, Daniel Golle, Hühn,
Thomas
Hi Nick,
On 09/11/2022 14:35, Nick wrote:
> Hi,
> while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the kernel is
> crashing while booting on a Banana Pi R64 (MT7622):
>
>> [ 1.055565] ------------[ cut here ]------------
>> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose debug
>> info unavailable]
>> [ 1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
>> [ 1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>> [ 1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
>> [ 1.081257] Modules linked in:
>> [ 1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G S
>> 6.1-rc2 #0
>> [ 1.087088] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff ->
>> 0x0020000000
>> [ 1.090126] Hardware name: Bananapi BPI-R64 (DT)
>> [ 1.110541] Workqueue: events dbs_work_handler
>> [ 1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>> [ 1.121944] pc : regulator_check_voltage+0xb0/0xf0
>> [ 1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
>> [ 1.129638] mmc1: host does not support reading read-only switch, assuming
>> write-enable
>> [ 1.132207] sp : ffffffc00956bb30
>> [ 1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27: 0000000000000024
>> [ 1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24: 00000000001312d0
>> [ 1.132227] x23: 0000000000149970
>> [ 1.146036] mmc1: new high speed SDHC card at address e624
>> [ 1.150642] x22: ffffff800038f800
>> [ 1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB
>> [ 1.161068] x21: ffffff8000efb100
>> [ 1.161072] x20: 00000000001312d0
>> [ 1.175424] GPT:partition_entry_array_crc32 values don't match: 0xa0b5ce6d
>> != 0xab54d286
>> [ 1.177757] x19: 0000000000000000 x18: 00000000799b2550
>> [ 1.181067] GPT:Primary header thinks Alt. header is not at the end of the
>> disk.
>> [ 1.189143] x17: 0000000000000003 x16: 0000000000000001 x15: 0000000000000000
>> [ 1.189151] x14: 0000000000000000 x13: 0000000000000146 x12: 00000000fa83b2da
>> [ 1.189159] x11: 000000000000013d x10: 0000000000000850
>> [ 1.194472] GPT:305184 != 31116287
>> [ 1.201842] x9 : ffffffc00956b910
>> [ 1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
>> [ 1.208970] GPT:Alternate GPT header not at the end of the disk.
>> [ 1.216092] x6 : 00000000001312d0
>> [ 1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 : 0000000000000000
>> [ 1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
>> [ 1.221321] GPT:305184 != 31116287
>> [ 1.224706] x0 : ffffff800038f800
>> [ 1.228095] GPT: Use GNU Parted to correct GPT errors.
>> [ 1.233307]
>> [ 1.233309] Call trace:
>> [ 1.233312] regulator_check_voltage+0xb0/0xf0
>> [ 1.242680] FIT: Selected configuration:
>> "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64 with
>> mt7622-bananapi-bpi-r64-pcie1)
>> [ 1.242694] regulator_set_voltage+0x3c/0x64
>> [ 1.249831] FIT: kernel sub-image 0x00001000..0x0052fd0a
>> "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2)
>> [ 1.255030] mtk_cpufreq_voltage_tracking+0x11c/0x26c
>> [ 1.255039] mtk_cpufreq_set_target+0x1c4/0x350
>> [ 1.258444] FIT: flat_dt sub-image 0x00530000..0x005380c5 "fdt-1"
>> (ARM64 OpenWrt bananapi_bpi-r64 device tree blob)
>> [ 1.261820] __cpufreq_driver_target+0x2f4/0x674
>> [ 1.261826] od_dbs_update+0xb8/0x19c
>> [ 1.266969] FIT: flat_dt sub-image 0x00539000..0x0053911a
>> "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64 OpenWrt bananapi_bpi-r64 device
>> tree overlay mt7622-bananapi-bpi-r64-pcie1)
>> [ 1.268431] dbs_work_handler+0x3c/0x7c
>> [ 1.270883] FIT: flat_dt sub-image 0x0053a000..0x0053a20f
>> "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64 OpenWrt bananapi_bpi-r64 device tree
>> overlay mt7622-bananapi-bpi-r64-sata)
>> [ 1.275297] process_one_work+0x200/0x3a0
>> [ 1.287998] FIT: filesystem sub-image 0x0053b000..0x00859fff
>> "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs)
>> [ 1.292237] worker_thread+0x170/0x4c0
>> [ 1.292244] kthread+0xd4/0xe0
>> [ 1.302066] FIT: selecting configured loadable "rootfs-1" to be root
>> filesystem
>> [ 1.307092] ret_from_fork+0x10/0x20
>> [ 1.311631] mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1) p66(rootfs_data) p128
>> [ 1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>> [ 1.413322] ---[ end trace 0000000000000000 ]---
> The complete log can be found here:
> https://gist.githubusercontent.com/PolynomialDivision/395d009c84b426d780549c5fa1f64ff1/raw/886d621d2bf6f03429586adf8a14a6c37c8d8a7d/mt7622-6-1.log
>
> Reverting commit "cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()"
> fixes the kernel bug:
> https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
>
> The revert commit can be found here:
> https://github.com/PolynomialDivision/openwrt/commit/1df941d0334000e3aced43b7d50cdac0da8bf427
>
> The branch I use to build the 6.1rc2 on a Banana Pi R64 can be found here:
> https://github.com/PolynomialDivision/openwrt/commits/bump-mt7622-rebase
>
Thanks for the report.
Could you test with a plain upstream kernel? That would help us to verify that
this is a upstream problem and not introduced by some openwrt patches.
Regards,
Matthias
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-11-10 11:26 ` Matthias Brugger
0 siblings, 0 replies; 75+ messages in thread
From: Matthias Brugger @ 2022-11-10 11:26 UTC (permalink / raw)
To: Nick, jia-wei.chang, rex-bc.chen, angelogioacchino.delregno,
viresh.kumar, Frank Wunderlich
Cc: linux-pm, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, Daniel Golle, Hühn,
Thomas
Hi Nick,
On 09/11/2022 14:35, Nick wrote:
> Hi,
> while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the kernel is
> crashing while booting on a Banana Pi R64 (MT7622):
>
>> [ 1.055565] ------------[ cut here ]------------
>> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose debug
>> info unavailable]
>> [ 1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
>> [ 1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>> [ 1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
>> [ 1.081257] Modules linked in:
>> [ 1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G S
>> 6.1-rc2 #0
>> [ 1.087088] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff ->
>> 0x0020000000
>> [ 1.090126] Hardware name: Bananapi BPI-R64 (DT)
>> [ 1.110541] Workqueue: events dbs_work_handler
>> [ 1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>> [ 1.121944] pc : regulator_check_voltage+0xb0/0xf0
>> [ 1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
>> [ 1.129638] mmc1: host does not support reading read-only switch, assuming
>> write-enable
>> [ 1.132207] sp : ffffffc00956bb30
>> [ 1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27: 0000000000000024
>> [ 1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24: 00000000001312d0
>> [ 1.132227] x23: 0000000000149970
>> [ 1.146036] mmc1: new high speed SDHC card at address e624
>> [ 1.150642] x22: ffffff800038f800
>> [ 1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB
>> [ 1.161068] x21: ffffff8000efb100
>> [ 1.161072] x20: 00000000001312d0
>> [ 1.175424] GPT:partition_entry_array_crc32 values don't match: 0xa0b5ce6d
>> != 0xab54d286
>> [ 1.177757] x19: 0000000000000000 x18: 00000000799b2550
>> [ 1.181067] GPT:Primary header thinks Alt. header is not at the end of the
>> disk.
>> [ 1.189143] x17: 0000000000000003 x16: 0000000000000001 x15: 0000000000000000
>> [ 1.189151] x14: 0000000000000000 x13: 0000000000000146 x12: 00000000fa83b2da
>> [ 1.189159] x11: 000000000000013d x10: 0000000000000850
>> [ 1.194472] GPT:305184 != 31116287
>> [ 1.201842] x9 : ffffffc00956b910
>> [ 1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
>> [ 1.208970] GPT:Alternate GPT header not at the end of the disk.
>> [ 1.216092] x6 : 00000000001312d0
>> [ 1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 : 0000000000000000
>> [ 1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
>> [ 1.221321] GPT:305184 != 31116287
>> [ 1.224706] x0 : ffffff800038f800
>> [ 1.228095] GPT: Use GNU Parted to correct GPT errors.
>> [ 1.233307]
>> [ 1.233309] Call trace:
>> [ 1.233312] regulator_check_voltage+0xb0/0xf0
>> [ 1.242680] FIT: Selected configuration:
>> "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64 with
>> mt7622-bananapi-bpi-r64-pcie1)
>> [ 1.242694] regulator_set_voltage+0x3c/0x64
>> [ 1.249831] FIT: kernel sub-image 0x00001000..0x0052fd0a
>> "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2)
>> [ 1.255030] mtk_cpufreq_voltage_tracking+0x11c/0x26c
>> [ 1.255039] mtk_cpufreq_set_target+0x1c4/0x350
>> [ 1.258444] FIT: flat_dt sub-image 0x00530000..0x005380c5 "fdt-1"
>> (ARM64 OpenWrt bananapi_bpi-r64 device tree blob)
>> [ 1.261820] __cpufreq_driver_target+0x2f4/0x674
>> [ 1.261826] od_dbs_update+0xb8/0x19c
>> [ 1.266969] FIT: flat_dt sub-image 0x00539000..0x0053911a
>> "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64 OpenWrt bananapi_bpi-r64 device
>> tree overlay mt7622-bananapi-bpi-r64-pcie1)
>> [ 1.268431] dbs_work_handler+0x3c/0x7c
>> [ 1.270883] FIT: flat_dt sub-image 0x0053a000..0x0053a20f
>> "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64 OpenWrt bananapi_bpi-r64 device tree
>> overlay mt7622-bananapi-bpi-r64-sata)
>> [ 1.275297] process_one_work+0x200/0x3a0
>> [ 1.287998] FIT: filesystem sub-image 0x0053b000..0x00859fff
>> "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs)
>> [ 1.292237] worker_thread+0x170/0x4c0
>> [ 1.292244] kthread+0xd4/0xe0
>> [ 1.302066] FIT: selecting configured loadable "rootfs-1" to be root
>> filesystem
>> [ 1.307092] ret_from_fork+0x10/0x20
>> [ 1.311631] mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1) p66(rootfs_data) p128
>> [ 1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>> [ 1.413322] ---[ end trace 0000000000000000 ]---
> The complete log can be found here:
> https://gist.githubusercontent.com/PolynomialDivision/395d009c84b426d780549c5fa1f64ff1/raw/886d621d2bf6f03429586adf8a14a6c37c8d8a7d/mt7622-6-1.log
>
> Reverting commit "cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()"
> fixes the kernel bug:
> https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
>
> The revert commit can be found here:
> https://github.com/PolynomialDivision/openwrt/commit/1df941d0334000e3aced43b7d50cdac0da8bf427
>
> The branch I use to build the 6.1rc2 on a Banana Pi R64 can be found here:
> https://github.com/PolynomialDivision/openwrt/commits/bump-mt7622-rebase
>
Thanks for the report.
Could you test with a plain upstream kernel? That would help us to verify that
this is a upstream problem and not introduced by some openwrt patches.
Regards,
Matthias
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-11-10 11:26 ` Matthias Brugger
@ 2022-11-15 19:44 ` Nick
-1 siblings, 0 replies; 75+ messages in thread
From: Nick @ 2022-11-15 19:44 UTC (permalink / raw)
To: Matthias Brugger, jia-wei.chang, rex-bc.chen,
angelogioacchino.delregno, viresh.kumar, Frank Wunderlich
Cc: linux-pm, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, Daniel Golle, Hühn,
Thomas
Hi,
I used now the linux-next kernel tree (with
https://patchwork.ozlabs.org/project/linux-mtd/list/?series=327227 so
single uImage.FIT will work). Same issue:
> [ 0.886209] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose
> debug info unavailable]
>
> [ 0.894663] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>
> [ 0.900759] Modules linked in:
>
> [ 0.903819] CPU: 1 PID: 79 Comm: kworker/1:1 Tainted: G S
> 6.1.0-rc5-next-20221115+ #0
>
> [ 0.904360] pstore: Using crash dump compression: deflate
>
> [ 0.913038] Hardware name: Bananapi BPI-R64 (DT)
>
> [ 0.913043] Workqueue: events dbs_work_handler
>
> [ 0.913056] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
> BTYPE=--)
>
> [ 0.913063] pc : regulator_check_voltage+0xb0/0xf0
>
> [ 0.913070] lr : regulator_set_voltage_unlocked+0x88/0x110
>
> [ 0.913077] sp : ffffffc00cef3b30
>
> [ 0.913080] x29: ffffffc00cef3b30 x28: ffffff8006f6f800 x27:
> ffffff8006f6fa00
>
> [ 0.931243] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
>
> [ 0.934474]
>
> [ 0.934475] x26: 00000000001312d0 x25: 0000000000000024
>
> [ 0.939298] mtk-pcie 1a143000.pcie: Parsing ranges property...
>
> [ 0.944730] x24: 0000000000118c30
>
> [ 0.948038] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff ->
> 0x0020000000
>
> [ 0.955155]
>
> [ 0.955157] x23: 0000000000149970 x22: ffffff8000861800 x21:
> ffffff8006f6f800
>
> [ 0.955166] x20: 00000000001312d0 x19: 0000000000000000 x18:
> 00000000cfad1bd3
>
> [ 0.955174] x17: 000000000000000c x16: 0000000000000005 x15:
> 0000000000000000
>
> [ 1.008473] x14: 0000000000000000 x13: 0000000000000165 x12:
> 0101010101010101
>
> [ 1.015608] x11: 00000000017d7840 x10: 0000000000000850 x9 :
> ffffffc00cef3900
>
> [ 1.017014] mmc0: new HS200 MMC card at address 0001
>
> [ 1.022740] x8 : ffffff8005ee9f30 x7 : 0000000000000001 x6 :
> 00000000001312d0
>
> [ 1.022748] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
> 0000000000000000
>
> [ 1.022756] x2 : ffffffc00cef3b68 x1 : ffffffc00cef3b6c
>
> [ 1.029034] mmcblk0: mmc0:0001 008G30 7.28 GiB
>
> [ 1.034833] x0 : ffffff8000861800
>
> [ 1.034838] Call trace:
>
> [ 1.044528] Alternate GPT is invalid, using primary GPT.
>
> [ 1.047175] regulator_check_voltage+0xb0/0xf0
>
> [ 1.052603] FIT: Selected configuration: "config-1" (OpenWrt
> bananapi_bpi-r64)
>
> [ 1.055090] regulator_set_voltage+0x3c/0x64
>
> [ 1.057539] FIT: kernel sub-image 0x00001000..0x005200f9 "kernel-1"
> (ARM64 OpenWrt Linux-6.1-rc2)
>
> [ 1.062824] mtk_cpufreq_voltage_tracking+0x12c/0x27c
>
> [ 1.062831] mtk_cpufreq_set_target+0x1c4/0x350
>
> [ 1.062837] __cpufreq_driver_target+0x2dc/0x660
>
> [ 1.067289] FIT: flat_dt sub-image 0x00521000..0x005272d9 "fdt-1"
> (ARM64 OpenWrt bananapi_bpi-r64 device tree blob)
>
> [ 1.074484] od_dbs_update+0xb8/0x19c
>
> [ 1.074490] dbs_work_handler+0x3c/0x7c
>
> [ 1.078774] FIT: filesystem sub-image 0x00528000..0x00829fff
> "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs)
>
> [ 1.088560] process_one_work+0x200/0x3a0
>
> [ 1.093624] mmcblk0: p1 p2 p3 p4 p65(rootfs-1) p66(rootfs_data) p128
>
> [ 1.098116] worker_thread+0x170/0x4c0
>
> [ 1.104575] mmcblk0boot0: mmc0:0001 008G30 4.00 MiB
>
> [ 1.114009] kthread+0xd4/0xe0
>
> [ 1.114016] ret_from_fork+0x10/0x20
>
> [ 1.114028] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>
> [ 1.114033] ---[ end trace 0000000000000000 ]---
> [ 0.878926] ------------[ cut here ]------------
>
Full log:
https://gist.github.com/PolynomialDivision/4a555079887b288f4795b28eb3607aa9
Big thanks to Daniel helping me to build a vanilla kernel with OpenWrt
build system.
Bests
Nick
On 11/10/22 12:26, Matthias Brugger wrote:
> Hi Nick,
>
> On 09/11/2022 14:35, Nick wrote:
>> Hi,
>> while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the
>> kernel is crashing while booting on a Banana Pi R64 (MT7622):
>>
>>> [ 1.055565] ------------[ cut here ]------------
>>> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0
>>> [verbose debug info unavailable]
>>> [ 1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000
>>> ranges:
>>> [ 1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>> [ 1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>> [ 1.081257] Modules linked in:
>>> [ 1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G
>>> S 6.1-rc2 #0
>>> [ 1.087088] mtk-pcie 1a143000.pcie: MEM
>>> 0x0020000000..0x0027ffffff -> 0x0020000000
>>> [ 1.090126] Hardware name: Bananapi BPI-R64 (DT)
>>> [ 1.110541] Workqueue: events dbs_work_handler
>>> [ 1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>>> BTYPE=--)
>>> [ 1.121944] pc : regulator_check_voltage+0xb0/0xf0
>>> [ 1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
>>> [ 1.129638] mmc1: host does not support reading read-only switch,
>>> assuming write-enable
>>> [ 1.132207] sp : ffffffc00956bb30
>>> [ 1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27:
>>> 0000000000000024
>>> [ 1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24:
>>> 00000000001312d0
>>> [ 1.132227] x23: 0000000000149970
>>> [ 1.146036] mmc1: new high speed SDHC card at address e624
>>> [ 1.150642] x22: ffffff800038f800
>>> [ 1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB
>>> [ 1.161068] x21: ffffff8000efb100
>>> [ 1.161072] x20: 00000000001312d0
>>> [ 1.175424] GPT:partition_entry_array_crc32 values don't match:
>>> 0xa0b5ce6d != 0xab54d286
>>> [ 1.177757] x19: 0000000000000000 x18: 00000000799b2550
>>> [ 1.181067] GPT:Primary header thinks Alt. header is not at the
>>> end of the disk.
>>> [ 1.189143] x17: 0000000000000003 x16: 0000000000000001 x15:
>>> 0000000000000000
>>> [ 1.189151] x14: 0000000000000000 x13: 0000000000000146 x12:
>>> 00000000fa83b2da
>>> [ 1.189159] x11: 000000000000013d x10: 0000000000000850
>>> [ 1.194472] GPT:305184 != 31116287
>>> [ 1.201842] x9 : ffffffc00956b910
>>> [ 1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
>>> [ 1.208970] GPT:Alternate GPT header not at the end of the disk.
>>> [ 1.216092] x6 : 00000000001312d0
>>> [ 1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>>> 0000000000000000
>>> [ 1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
>>> [ 1.221321] GPT:305184 != 31116287
>>> [ 1.224706] x0 : ffffff800038f800
>>> [ 1.228095] GPT: Use GNU Parted to correct GPT errors.
>>> [ 1.233307]
>>> [ 1.233309] Call trace:
>>> [ 1.233312] regulator_check_voltage+0xb0/0xf0
>>> [ 1.242680] FIT: Selected configuration:
>>> "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64
>>> with mt7622-bananapi-bpi-r64-pcie1)
>>> [ 1.242694] regulator_set_voltage+0x3c/0x64
>>> [ 1.249831] FIT: kernel sub-image
>>> 0x00001000..0x0052fd0a "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2)
>>> [ 1.255030] mtk_cpufreq_voltage_tracking+0x11c/0x26c
>>> [ 1.255039] mtk_cpufreq_set_target+0x1c4/0x350
>>> [ 1.258444] FIT: flat_dt sub-image
>>> 0x00530000..0x005380c5 "fdt-1" (ARM64 OpenWrt bananapi_bpi-r64
>>> device tree blob)
>>> [ 1.261820] __cpufreq_driver_target+0x2f4/0x674
>>> [ 1.261826] od_dbs_update+0xb8/0x19c
>>> [ 1.266969] FIT: flat_dt sub-image
>>> 0x00539000..0x0053911a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64
>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>> mt7622-bananapi-bpi-r64-pcie1)
>>> [ 1.268431] dbs_work_handler+0x3c/0x7c
>>> [ 1.270883] FIT: flat_dt sub-image
>>> 0x0053a000..0x0053a20f "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64
>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>> mt7622-bananapi-bpi-r64-sata)
>>> [ 1.275297] process_one_work+0x200/0x3a0
>>> [ 1.287998] FIT: filesystem sub-image
>>> 0x0053b000..0x00859fff "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64
>>> rootfs)
>>> [ 1.292237] worker_thread+0x170/0x4c0
>>> [ 1.292244] kthread+0xd4/0xe0
>>> [ 1.302066] FIT: selecting configured loadable "rootfs-1" to be
>>> root filesystem
>>> [ 1.307092] ret_from_fork+0x10/0x20
>>> [ 1.311631] mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1)
>>> p66(rootfs_data) p128
>>> [ 1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>> [ 1.413322] ---[ end trace 0000000000000000 ]---
>> The complete log can be found here:
>> https://gist.githubusercontent.com/PolynomialDivision/395d009c84b426d780549c5fa1f64ff1/raw/886d621d2bf6f03429586adf8a14a6c37c8d8a7d/mt7622-6-1.log
>>
>>
>> Reverting commit "cpufreq: mediatek: Refine
>> mtk_cpufreq_voltage_tracking()" fixes the kernel bug:
>> https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
>>
>>
>> The revert commit can be found here:
>> https://github.com/PolynomialDivision/openwrt/commit/1df941d0334000e3aced43b7d50cdac0da8bf427
>>
>>
>> The branch I use to build the 6.1rc2 on a Banana Pi R64 can be found
>> here:
>> https://github.com/PolynomialDivision/openwrt/commits/bump-mt7622-rebase
>>
>
> Thanks for the report.
> Could you test with a plain upstream kernel? That would help us to
> verify that this is a upstream problem and not introduced by some
> openwrt patches.
>
> Regards,
> Matthias
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-11-15 19:44 ` Nick
0 siblings, 0 replies; 75+ messages in thread
From: Nick @ 2022-11-15 19:44 UTC (permalink / raw)
To: Matthias Brugger, jia-wei.chang, rex-bc.chen,
angelogioacchino.delregno, viresh.kumar, Frank Wunderlich
Cc: linux-pm, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, Daniel Golle, Hühn,
Thomas
Hi,
I used now the linux-next kernel tree (with
https://patchwork.ozlabs.org/project/linux-mtd/list/?series=327227 so
single uImage.FIT will work). Same issue:
> [ 0.886209] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose
> debug info unavailable]
>
> [ 0.894663] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>
> [ 0.900759] Modules linked in:
>
> [ 0.903819] CPU: 1 PID: 79 Comm: kworker/1:1 Tainted: G S
> 6.1.0-rc5-next-20221115+ #0
>
> [ 0.904360] pstore: Using crash dump compression: deflate
>
> [ 0.913038] Hardware name: Bananapi BPI-R64 (DT)
>
> [ 0.913043] Workqueue: events dbs_work_handler
>
> [ 0.913056] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
> BTYPE=--)
>
> [ 0.913063] pc : regulator_check_voltage+0xb0/0xf0
>
> [ 0.913070] lr : regulator_set_voltage_unlocked+0x88/0x110
>
> [ 0.913077] sp : ffffffc00cef3b30
>
> [ 0.913080] x29: ffffffc00cef3b30 x28: ffffff8006f6f800 x27:
> ffffff8006f6fa00
>
> [ 0.931243] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
>
> [ 0.934474]
>
> [ 0.934475] x26: 00000000001312d0 x25: 0000000000000024
>
> [ 0.939298] mtk-pcie 1a143000.pcie: Parsing ranges property...
>
> [ 0.944730] x24: 0000000000118c30
>
> [ 0.948038] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff ->
> 0x0020000000
>
> [ 0.955155]
>
> [ 0.955157] x23: 0000000000149970 x22: ffffff8000861800 x21:
> ffffff8006f6f800
>
> [ 0.955166] x20: 00000000001312d0 x19: 0000000000000000 x18:
> 00000000cfad1bd3
>
> [ 0.955174] x17: 000000000000000c x16: 0000000000000005 x15:
> 0000000000000000
>
> [ 1.008473] x14: 0000000000000000 x13: 0000000000000165 x12:
> 0101010101010101
>
> [ 1.015608] x11: 00000000017d7840 x10: 0000000000000850 x9 :
> ffffffc00cef3900
>
> [ 1.017014] mmc0: new HS200 MMC card at address 0001
>
> [ 1.022740] x8 : ffffff8005ee9f30 x7 : 0000000000000001 x6 :
> 00000000001312d0
>
> [ 1.022748] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
> 0000000000000000
>
> [ 1.022756] x2 : ffffffc00cef3b68 x1 : ffffffc00cef3b6c
>
> [ 1.029034] mmcblk0: mmc0:0001 008G30 7.28 GiB
>
> [ 1.034833] x0 : ffffff8000861800
>
> [ 1.034838] Call trace:
>
> [ 1.044528] Alternate GPT is invalid, using primary GPT.
>
> [ 1.047175] regulator_check_voltage+0xb0/0xf0
>
> [ 1.052603] FIT: Selected configuration: "config-1" (OpenWrt
> bananapi_bpi-r64)
>
> [ 1.055090] regulator_set_voltage+0x3c/0x64
>
> [ 1.057539] FIT: kernel sub-image 0x00001000..0x005200f9 "kernel-1"
> (ARM64 OpenWrt Linux-6.1-rc2)
>
> [ 1.062824] mtk_cpufreq_voltage_tracking+0x12c/0x27c
>
> [ 1.062831] mtk_cpufreq_set_target+0x1c4/0x350
>
> [ 1.062837] __cpufreq_driver_target+0x2dc/0x660
>
> [ 1.067289] FIT: flat_dt sub-image 0x00521000..0x005272d9 "fdt-1"
> (ARM64 OpenWrt bananapi_bpi-r64 device tree blob)
>
> [ 1.074484] od_dbs_update+0xb8/0x19c
>
> [ 1.074490] dbs_work_handler+0x3c/0x7c
>
> [ 1.078774] FIT: filesystem sub-image 0x00528000..0x00829fff
> "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs)
>
> [ 1.088560] process_one_work+0x200/0x3a0
>
> [ 1.093624] mmcblk0: p1 p2 p3 p4 p65(rootfs-1) p66(rootfs_data) p128
>
> [ 1.098116] worker_thread+0x170/0x4c0
>
> [ 1.104575] mmcblk0boot0: mmc0:0001 008G30 4.00 MiB
>
> [ 1.114009] kthread+0xd4/0xe0
>
> [ 1.114016] ret_from_fork+0x10/0x20
>
> [ 1.114028] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>
> [ 1.114033] ---[ end trace 0000000000000000 ]---
> [ 0.878926] ------------[ cut here ]------------
>
Full log:
https://gist.github.com/PolynomialDivision/4a555079887b288f4795b28eb3607aa9
Big thanks to Daniel helping me to build a vanilla kernel with OpenWrt
build system.
Bests
Nick
On 11/10/22 12:26, Matthias Brugger wrote:
> Hi Nick,
>
> On 09/11/2022 14:35, Nick wrote:
>> Hi,
>> while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the
>> kernel is crashing while booting on a Banana Pi R64 (MT7622):
>>
>>> [ 1.055565] ------------[ cut here ]------------
>>> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0
>>> [verbose debug info unavailable]
>>> [ 1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000
>>> ranges:
>>> [ 1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>> [ 1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>> [ 1.081257] Modules linked in:
>>> [ 1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G
>>> S 6.1-rc2 #0
>>> [ 1.087088] mtk-pcie 1a143000.pcie: MEM
>>> 0x0020000000..0x0027ffffff -> 0x0020000000
>>> [ 1.090126] Hardware name: Bananapi BPI-R64 (DT)
>>> [ 1.110541] Workqueue: events dbs_work_handler
>>> [ 1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>>> BTYPE=--)
>>> [ 1.121944] pc : regulator_check_voltage+0xb0/0xf0
>>> [ 1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
>>> [ 1.129638] mmc1: host does not support reading read-only switch,
>>> assuming write-enable
>>> [ 1.132207] sp : ffffffc00956bb30
>>> [ 1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27:
>>> 0000000000000024
>>> [ 1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24:
>>> 00000000001312d0
>>> [ 1.132227] x23: 0000000000149970
>>> [ 1.146036] mmc1: new high speed SDHC card at address e624
>>> [ 1.150642] x22: ffffff800038f800
>>> [ 1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB
>>> [ 1.161068] x21: ffffff8000efb100
>>> [ 1.161072] x20: 00000000001312d0
>>> [ 1.175424] GPT:partition_entry_array_crc32 values don't match:
>>> 0xa0b5ce6d != 0xab54d286
>>> [ 1.177757] x19: 0000000000000000 x18: 00000000799b2550
>>> [ 1.181067] GPT:Primary header thinks Alt. header is not at the
>>> end of the disk.
>>> [ 1.189143] x17: 0000000000000003 x16: 0000000000000001 x15:
>>> 0000000000000000
>>> [ 1.189151] x14: 0000000000000000 x13: 0000000000000146 x12:
>>> 00000000fa83b2da
>>> [ 1.189159] x11: 000000000000013d x10: 0000000000000850
>>> [ 1.194472] GPT:305184 != 31116287
>>> [ 1.201842] x9 : ffffffc00956b910
>>> [ 1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
>>> [ 1.208970] GPT:Alternate GPT header not at the end of the disk.
>>> [ 1.216092] x6 : 00000000001312d0
>>> [ 1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>>> 0000000000000000
>>> [ 1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
>>> [ 1.221321] GPT:305184 != 31116287
>>> [ 1.224706] x0 : ffffff800038f800
>>> [ 1.228095] GPT: Use GNU Parted to correct GPT errors.
>>> [ 1.233307]
>>> [ 1.233309] Call trace:
>>> [ 1.233312] regulator_check_voltage+0xb0/0xf0
>>> [ 1.242680] FIT: Selected configuration:
>>> "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64
>>> with mt7622-bananapi-bpi-r64-pcie1)
>>> [ 1.242694] regulator_set_voltage+0x3c/0x64
>>> [ 1.249831] FIT: kernel sub-image
>>> 0x00001000..0x0052fd0a "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2)
>>> [ 1.255030] mtk_cpufreq_voltage_tracking+0x11c/0x26c
>>> [ 1.255039] mtk_cpufreq_set_target+0x1c4/0x350
>>> [ 1.258444] FIT: flat_dt sub-image
>>> 0x00530000..0x005380c5 "fdt-1" (ARM64 OpenWrt bananapi_bpi-r64
>>> device tree blob)
>>> [ 1.261820] __cpufreq_driver_target+0x2f4/0x674
>>> [ 1.261826] od_dbs_update+0xb8/0x19c
>>> [ 1.266969] FIT: flat_dt sub-image
>>> 0x00539000..0x0053911a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64
>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>> mt7622-bananapi-bpi-r64-pcie1)
>>> [ 1.268431] dbs_work_handler+0x3c/0x7c
>>> [ 1.270883] FIT: flat_dt sub-image
>>> 0x0053a000..0x0053a20f "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64
>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>> mt7622-bananapi-bpi-r64-sata)
>>> [ 1.275297] process_one_work+0x200/0x3a0
>>> [ 1.287998] FIT: filesystem sub-image
>>> 0x0053b000..0x00859fff "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64
>>> rootfs)
>>> [ 1.292237] worker_thread+0x170/0x4c0
>>> [ 1.292244] kthread+0xd4/0xe0
>>> [ 1.302066] FIT: selecting configured loadable "rootfs-1" to be
>>> root filesystem
>>> [ 1.307092] ret_from_fork+0x10/0x20
>>> [ 1.311631] mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1)
>>> p66(rootfs_data) p128
>>> [ 1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>> [ 1.413322] ---[ end trace 0000000000000000 ]---
>> The complete log can be found here:
>> https://gist.githubusercontent.com/PolynomialDivision/395d009c84b426d780549c5fa1f64ff1/raw/886d621d2bf6f03429586adf8a14a6c37c8d8a7d/mt7622-6-1.log
>>
>>
>> Reverting commit "cpufreq: mediatek: Refine
>> mtk_cpufreq_voltage_tracking()" fixes the kernel bug:
>> https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
>>
>>
>> The revert commit can be found here:
>> https://github.com/PolynomialDivision/openwrt/commit/1df941d0334000e3aced43b7d50cdac0da8bf427
>>
>>
>> The branch I use to build the 6.1rc2 on a Banana Pi R64 can be found
>> here:
>> https://github.com/PolynomialDivision/openwrt/commits/bump-mt7622-rebase
>>
>
> Thanks for the report.
> Could you test with a plain upstream kernel? That would help us to
> verify that this is a upstream problem and not introduced by some
> openwrt patches.
>
> Regards,
> Matthias
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-11-15 19:44 ` Nick
@ 2022-12-01 15:08 ` Thorsten Leemhuis
-1 siblings, 0 replies; 75+ messages in thread
From: Thorsten Leemhuis @ 2022-12-01 15:08 UTC (permalink / raw)
To: Nick, Matthias Brugger, jia-wei.chang, rex-bc.chen,
angelogioacchino.delregno, viresh.kumar, Frank Wunderlich,
regressions
Cc: linux-pm, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, Daniel Golle, Hühn,
Thomas
Hi, this is your Linux kernel regression tracker. Top-posting for once,
to make this easily accessible to everyone.
I noticed this regression didn't make any progress
Matthias, is that because Nick didn't exactly do what you asked for (he
afaics tried -next, but nevertheless patches it)? Or is there another
reason?
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.
On 15.11.22 20:44, Nick wrote:
> I used now the linux-next kernel tree (with
> https://patchwork.ozlabs.org/project/linux-mtd/list/?series=327227 so
> single uImage.FIT will work).
>
> Same issue:
>
>> [ 0.886209] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose
>> debug info unavailable]
>>
>> [ 0.894663] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>
>> [ 0.900759] Modules linked in:
>>
>> [ 0.903819] CPU: 1 PID: 79 Comm: kworker/1:1 Tainted: G S
>> 6.1.0-rc5-next-20221115+ #0
>>
>> [ 0.904360] pstore: Using crash dump compression: deflate
>>
>> [ 0.913038] Hardware name: Bananapi BPI-R64 (DT)
>>
>> [ 0.913043] Workqueue: events dbs_work_handler
>>
>> [ 0.913056] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>> BTYPE=--)
>>
>> [ 0.913063] pc : regulator_check_voltage+0xb0/0xf0
>>
>> [ 0.913070] lr : regulator_set_voltage_unlocked+0x88/0x110
>>
>> [ 0.913077] sp : ffffffc00cef3b30
>>
>> [ 0.913080] x29: ffffffc00cef3b30 x28: ffffff8006f6f800 x27:
>> ffffff8006f6fa00
>>
>> [ 0.931243] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
>>
>> [ 0.934474]
>>
>> [ 0.934475] x26: 00000000001312d0 x25: 0000000000000024
>>
>> [ 0.939298] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>
>> [ 0.944730] x24: 0000000000118c30
>>
>> [ 0.948038] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff ->
>> 0x0020000000
>>
>> [ 0.955155]
>>
>> [ 0.955157] x23: 0000000000149970 x22: ffffff8000861800 x21:
>> ffffff8006f6f800
>>
>> [ 0.955166] x20: 00000000001312d0 x19: 0000000000000000 x18:
>> 00000000cfad1bd3
>>
>> [ 0.955174] x17: 000000000000000c x16: 0000000000000005 x15:
>> 0000000000000000
>>
>> [ 1.008473] x14: 0000000000000000 x13: 0000000000000165 x12:
>> 0101010101010101
>>
>> [ 1.015608] x11: 00000000017d7840 x10: 0000000000000850 x9 :
>> ffffffc00cef3900
>>
>> [ 1.017014] mmc0: new HS200 MMC card at address 0001
>>
>> [ 1.022740] x8 : ffffff8005ee9f30 x7 : 0000000000000001 x6 :
>> 00000000001312d0
>>
>> [ 1.022748] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>> 0000000000000000
>>
>> [ 1.022756] x2 : ffffffc00cef3b68 x1 : ffffffc00cef3b6c
>>
>> [ 1.029034] mmcblk0: mmc0:0001 008G30 7.28 GiB
>>
>> [ 1.034833] x0 : ffffff8000861800
>>
>> [ 1.034838] Call trace:
>>
>> [ 1.044528] Alternate GPT is invalid, using primary GPT.
>>
>> [ 1.047175] regulator_check_voltage+0xb0/0xf0
>>
>> [ 1.052603] FIT: Selected configuration: "config-1" (OpenWrt
>> bananapi_bpi-r64)
>>
>> [ 1.055090] regulator_set_voltage+0x3c/0x64
>>
>> [ 1.057539] FIT: kernel sub-image 0x00001000..0x005200f9 "kernel-1"
>> (ARM64 OpenWrt Linux-6.1-rc2)
>>
>> [ 1.062824] mtk_cpufreq_voltage_tracking+0x12c/0x27c
>>
>> [ 1.062831] mtk_cpufreq_set_target+0x1c4/0x350
>>
>> [ 1.062837] __cpufreq_driver_target+0x2dc/0x660
>>
>> [ 1.067289] FIT: flat_dt sub-image 0x00521000..0x005272d9 "fdt-1"
>> (ARM64 OpenWrt bananapi_bpi-r64 device tree blob)
>>
>> [ 1.074484] od_dbs_update+0xb8/0x19c
>>
>> [ 1.074490] dbs_work_handler+0x3c/0x7c
>>
>> [ 1.078774] FIT: filesystem sub-image 0x00528000..0x00829fff
>> "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs)
>>
>> [ 1.088560] process_one_work+0x200/0x3a0
>>
>> [ 1.093624] mmcblk0: p1 p2 p3 p4 p65(rootfs-1) p66(rootfs_data) p128
>>
>> [ 1.098116] worker_thread+0x170/0x4c0
>>
>> [ 1.104575] mmcblk0boot0: mmc0:0001 008G30 4.00 MiB
>>
>> [ 1.114009] kthread+0xd4/0xe0
>>
>> [ 1.114016] ret_from_fork+0x10/0x20
>>
>> [ 1.114028] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>
>> [ 1.114033] ---[ end trace 0000000000000000 ]---
>> [ 0.878926] ------------[ cut here ]------------
>>
>
> Full log:
> https://gist.github.com/PolynomialDivision/4a555079887b288f4795b28eb3607aa9
>
> Big thanks to Daniel helping me to build a vanilla kernel with OpenWrt
> build system.
>
> Bests
> Nick
>
> On 11/10/22 12:26, Matthias Brugger wrote:
>> Hi Nick,
>>
>> On 09/11/2022 14:35, Nick wrote:
>>> Hi,
>>> while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the
>>> kernel is crashing while booting on a Banana Pi R64 (MT7622):
>>>
>>>> [ 1.055565] ------------[ cut here ]------------
>>>> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0
>>>> [verbose debug info unavailable]
>>>> [ 1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000
>>>> ranges:
>>>> [ 1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>>> [ 1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>>> [ 1.081257] Modules linked in:
>>>> [ 1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G
>>>> S 6.1-rc2 #0
>>>> [ 1.087088] mtk-pcie 1a143000.pcie: MEM
>>>> 0x0020000000..0x0027ffffff -> 0x0020000000
>>>> [ 1.090126] Hardware name: Bananapi BPI-R64 (DT)
>>>> [ 1.110541] Workqueue: events dbs_work_handler
>>>> [ 1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>>>> BTYPE=--)
>>>> [ 1.121944] pc : regulator_check_voltage+0xb0/0xf0
>>>> [ 1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
>>>> [ 1.129638] mmc1: host does not support reading read-only switch,
>>>> assuming write-enable
>>>> [ 1.132207] sp : ffffffc00956bb30
>>>> [ 1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27:
>>>> 0000000000000024
>>>> [ 1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24:
>>>> 00000000001312d0
>>>> [ 1.132227] x23: 0000000000149970
>>>> [ 1.146036] mmc1: new high speed SDHC card at address e624
>>>> [ 1.150642] x22: ffffff800038f800
>>>> [ 1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB
>>>> [ 1.161068] x21: ffffff8000efb100
>>>> [ 1.161072] x20: 00000000001312d0
>>>> [ 1.175424] GPT:partition_entry_array_crc32 values don't match:
>>>> 0xa0b5ce6d != 0xab54d286
>>>> [ 1.177757] x19: 0000000000000000 x18: 00000000799b2550
>>>> [ 1.181067] GPT:Primary header thinks Alt. header is not at the
>>>> end of the disk.
>>>> [ 1.189143] x17: 0000000000000003 x16: 0000000000000001 x15:
>>>> 0000000000000000
>>>> [ 1.189151] x14: 0000000000000000 x13: 0000000000000146 x12:
>>>> 00000000fa83b2da
>>>> [ 1.189159] x11: 000000000000013d x10: 0000000000000850
>>>> [ 1.194472] GPT:305184 != 31116287
>>>> [ 1.201842] x9 : ffffffc00956b910
>>>> [ 1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
>>>> [ 1.208970] GPT:Alternate GPT header not at the end of the disk.
>>>> [ 1.216092] x6 : 00000000001312d0
>>>> [ 1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>>>> 0000000000000000
>>>> [ 1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
>>>> [ 1.221321] GPT:305184 != 31116287
>>>> [ 1.224706] x0 : ffffff800038f800
>>>> [ 1.228095] GPT: Use GNU Parted to correct GPT errors.
>>>> [ 1.233307]
>>>> [ 1.233309] Call trace:
>>>> [ 1.233312] regulator_check_voltage+0xb0/0xf0
>>>> [ 1.242680] FIT: Selected configuration:
>>>> "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64
>>>> with mt7622-bananapi-bpi-r64-pcie1)
>>>> [ 1.242694] regulator_set_voltage+0x3c/0x64
>>>> [ 1.249831] FIT: kernel sub-image
>>>> 0x00001000..0x0052fd0a "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2)
>>>> [ 1.255030] mtk_cpufreq_voltage_tracking+0x11c/0x26c
>>>> [ 1.255039] mtk_cpufreq_set_target+0x1c4/0x350
>>>> [ 1.258444] FIT: flat_dt sub-image
>>>> 0x00530000..0x005380c5 "fdt-1" (ARM64 OpenWrt bananapi_bpi-r64
>>>> device tree blob)
>>>> [ 1.261820] __cpufreq_driver_target+0x2f4/0x674
>>>> [ 1.261826] od_dbs_update+0xb8/0x19c
>>>> [ 1.266969] FIT: flat_dt sub-image
>>>> 0x00539000..0x0053911a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64
>>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>>> mt7622-bananapi-bpi-r64-pcie1)
>>>> [ 1.268431] dbs_work_handler+0x3c/0x7c
>>>> [ 1.270883] FIT: flat_dt sub-image
>>>> 0x0053a000..0x0053a20f "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64
>>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>>> mt7622-bananapi-bpi-r64-sata)
>>>> [ 1.275297] process_one_work+0x200/0x3a0
>>>> [ 1.287998] FIT: filesystem sub-image
>>>> 0x0053b000..0x00859fff "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64
>>>> rootfs)
>>>> [ 1.292237] worker_thread+0x170/0x4c0
>>>> [ 1.292244] kthread+0xd4/0xe0
>>>> [ 1.302066] FIT: selecting configured loadable "rootfs-1" to be
>>>> root filesystem
>>>> [ 1.307092] ret_from_fork+0x10/0x20
>>>> [ 1.311631] mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1)
>>>> p66(rootfs_data) p128
>>>> [ 1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>>> [ 1.413322] ---[ end trace 0000000000000000 ]---
>>> The complete log can be found here:
>>> https://gist.githubusercontent.com/PolynomialDivision/395d009c84b426d780549c5fa1f64ff1/raw/886d621d2bf6f03429586adf8a14a6c37c8d8a7d/mt7622-6-1.log
>>>
>>> Reverting commit "cpufreq: mediatek: Refine
>>> mtk_cpufreq_voltage_tracking()" fixes the kernel bug:
>>> https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
>>>
>>> The revert commit can be found here:
>>> https://github.com/PolynomialDivision/openwrt/commit/1df941d0334000e3aced43b7d50cdac0da8bf427
>>>
>>> The branch I use to build the 6.1rc2 on a Banana Pi R64 can be found
>>> here:
>>> https://github.com/PolynomialDivision/openwrt/commits/bump-mt7622-rebase
>>>
>>
>> Thanks for the report.
>> Could you test with a plain upstream kernel? That would help us to
>> verify that this is a upstream problem and not introduced by some
>> openwrt patches.
>>
>> Regards,
>> Matthias
#regzbot ignore-activity
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-01 15:08 ` Thorsten Leemhuis
0 siblings, 0 replies; 75+ messages in thread
From: Thorsten Leemhuis @ 2022-12-01 15:08 UTC (permalink / raw)
To: Nick, Matthias Brugger, jia-wei.chang, rex-bc.chen,
angelogioacchino.delregno, viresh.kumar, Frank Wunderlich,
regressions
Cc: linux-pm, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, Daniel Golle, Hühn,
Thomas
Hi, this is your Linux kernel regression tracker. Top-posting for once,
to make this easily accessible to everyone.
I noticed this regression didn't make any progress
Matthias, is that because Nick didn't exactly do what you asked for (he
afaics tried -next, but nevertheless patches it)? Or is there another
reason?
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.
On 15.11.22 20:44, Nick wrote:
> I used now the linux-next kernel tree (with
> https://patchwork.ozlabs.org/project/linux-mtd/list/?series=327227 so
> single uImage.FIT will work).
>
> Same issue:
>
>> [ 0.886209] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose
>> debug info unavailable]
>>
>> [ 0.894663] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>
>> [ 0.900759] Modules linked in:
>>
>> [ 0.903819] CPU: 1 PID: 79 Comm: kworker/1:1 Tainted: G S
>> 6.1.0-rc5-next-20221115+ #0
>>
>> [ 0.904360] pstore: Using crash dump compression: deflate
>>
>> [ 0.913038] Hardware name: Bananapi BPI-R64 (DT)
>>
>> [ 0.913043] Workqueue: events dbs_work_handler
>>
>> [ 0.913056] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>> BTYPE=--)
>>
>> [ 0.913063] pc : regulator_check_voltage+0xb0/0xf0
>>
>> [ 0.913070] lr : regulator_set_voltage_unlocked+0x88/0x110
>>
>> [ 0.913077] sp : ffffffc00cef3b30
>>
>> [ 0.913080] x29: ffffffc00cef3b30 x28: ffffff8006f6f800 x27:
>> ffffff8006f6fa00
>>
>> [ 0.931243] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
>>
>> [ 0.934474]
>>
>> [ 0.934475] x26: 00000000001312d0 x25: 0000000000000024
>>
>> [ 0.939298] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>
>> [ 0.944730] x24: 0000000000118c30
>>
>> [ 0.948038] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff ->
>> 0x0020000000
>>
>> [ 0.955155]
>>
>> [ 0.955157] x23: 0000000000149970 x22: ffffff8000861800 x21:
>> ffffff8006f6f800
>>
>> [ 0.955166] x20: 00000000001312d0 x19: 0000000000000000 x18:
>> 00000000cfad1bd3
>>
>> [ 0.955174] x17: 000000000000000c x16: 0000000000000005 x15:
>> 0000000000000000
>>
>> [ 1.008473] x14: 0000000000000000 x13: 0000000000000165 x12:
>> 0101010101010101
>>
>> [ 1.015608] x11: 00000000017d7840 x10: 0000000000000850 x9 :
>> ffffffc00cef3900
>>
>> [ 1.017014] mmc0: new HS200 MMC card at address 0001
>>
>> [ 1.022740] x8 : ffffff8005ee9f30 x7 : 0000000000000001 x6 :
>> 00000000001312d0
>>
>> [ 1.022748] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>> 0000000000000000
>>
>> [ 1.022756] x2 : ffffffc00cef3b68 x1 : ffffffc00cef3b6c
>>
>> [ 1.029034] mmcblk0: mmc0:0001 008G30 7.28 GiB
>>
>> [ 1.034833] x0 : ffffff8000861800
>>
>> [ 1.034838] Call trace:
>>
>> [ 1.044528] Alternate GPT is invalid, using primary GPT.
>>
>> [ 1.047175] regulator_check_voltage+0xb0/0xf0
>>
>> [ 1.052603] FIT: Selected configuration: "config-1" (OpenWrt
>> bananapi_bpi-r64)
>>
>> [ 1.055090] regulator_set_voltage+0x3c/0x64
>>
>> [ 1.057539] FIT: kernel sub-image 0x00001000..0x005200f9 "kernel-1"
>> (ARM64 OpenWrt Linux-6.1-rc2)
>>
>> [ 1.062824] mtk_cpufreq_voltage_tracking+0x12c/0x27c
>>
>> [ 1.062831] mtk_cpufreq_set_target+0x1c4/0x350
>>
>> [ 1.062837] __cpufreq_driver_target+0x2dc/0x660
>>
>> [ 1.067289] FIT: flat_dt sub-image 0x00521000..0x005272d9 "fdt-1"
>> (ARM64 OpenWrt bananapi_bpi-r64 device tree blob)
>>
>> [ 1.074484] od_dbs_update+0xb8/0x19c
>>
>> [ 1.074490] dbs_work_handler+0x3c/0x7c
>>
>> [ 1.078774] FIT: filesystem sub-image 0x00528000..0x00829fff
>> "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs)
>>
>> [ 1.088560] process_one_work+0x200/0x3a0
>>
>> [ 1.093624] mmcblk0: p1 p2 p3 p4 p65(rootfs-1) p66(rootfs_data) p128
>>
>> [ 1.098116] worker_thread+0x170/0x4c0
>>
>> [ 1.104575] mmcblk0boot0: mmc0:0001 008G30 4.00 MiB
>>
>> [ 1.114009] kthread+0xd4/0xe0
>>
>> [ 1.114016] ret_from_fork+0x10/0x20
>>
>> [ 1.114028] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>
>> [ 1.114033] ---[ end trace 0000000000000000 ]---
>> [ 0.878926] ------------[ cut here ]------------
>>
>
> Full log:
> https://gist.github.com/PolynomialDivision/4a555079887b288f4795b28eb3607aa9
>
> Big thanks to Daniel helping me to build a vanilla kernel with OpenWrt
> build system.
>
> Bests
> Nick
>
> On 11/10/22 12:26, Matthias Brugger wrote:
>> Hi Nick,
>>
>> On 09/11/2022 14:35, Nick wrote:
>>> Hi,
>>> while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the
>>> kernel is crashing while booting on a Banana Pi R64 (MT7622):
>>>
>>>> [ 1.055565] ------------[ cut here ]------------
>>>> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0
>>>> [verbose debug info unavailable]
>>>> [ 1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000
>>>> ranges:
>>>> [ 1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>>> [ 1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>>> [ 1.081257] Modules linked in:
>>>> [ 1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G
>>>> S 6.1-rc2 #0
>>>> [ 1.087088] mtk-pcie 1a143000.pcie: MEM
>>>> 0x0020000000..0x0027ffffff -> 0x0020000000
>>>> [ 1.090126] Hardware name: Bananapi BPI-R64 (DT)
>>>> [ 1.110541] Workqueue: events dbs_work_handler
>>>> [ 1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>>>> BTYPE=--)
>>>> [ 1.121944] pc : regulator_check_voltage+0xb0/0xf0
>>>> [ 1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
>>>> [ 1.129638] mmc1: host does not support reading read-only switch,
>>>> assuming write-enable
>>>> [ 1.132207] sp : ffffffc00956bb30
>>>> [ 1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27:
>>>> 0000000000000024
>>>> [ 1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24:
>>>> 00000000001312d0
>>>> [ 1.132227] x23: 0000000000149970
>>>> [ 1.146036] mmc1: new high speed SDHC card at address e624
>>>> [ 1.150642] x22: ffffff800038f800
>>>> [ 1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB
>>>> [ 1.161068] x21: ffffff8000efb100
>>>> [ 1.161072] x20: 00000000001312d0
>>>> [ 1.175424] GPT:partition_entry_array_crc32 values don't match:
>>>> 0xa0b5ce6d != 0xab54d286
>>>> [ 1.177757] x19: 0000000000000000 x18: 00000000799b2550
>>>> [ 1.181067] GPT:Primary header thinks Alt. header is not at the
>>>> end of the disk.
>>>> [ 1.189143] x17: 0000000000000003 x16: 0000000000000001 x15:
>>>> 0000000000000000
>>>> [ 1.189151] x14: 0000000000000000 x13: 0000000000000146 x12:
>>>> 00000000fa83b2da
>>>> [ 1.189159] x11: 000000000000013d x10: 0000000000000850
>>>> [ 1.194472] GPT:305184 != 31116287
>>>> [ 1.201842] x9 : ffffffc00956b910
>>>> [ 1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
>>>> [ 1.208970] GPT:Alternate GPT header not at the end of the disk.
>>>> [ 1.216092] x6 : 00000000001312d0
>>>> [ 1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>>>> 0000000000000000
>>>> [ 1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
>>>> [ 1.221321] GPT:305184 != 31116287
>>>> [ 1.224706] x0 : ffffff800038f800
>>>> [ 1.228095] GPT: Use GNU Parted to correct GPT errors.
>>>> [ 1.233307]
>>>> [ 1.233309] Call trace:
>>>> [ 1.233312] regulator_check_voltage+0xb0/0xf0
>>>> [ 1.242680] FIT: Selected configuration:
>>>> "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64
>>>> with mt7622-bananapi-bpi-r64-pcie1)
>>>> [ 1.242694] regulator_set_voltage+0x3c/0x64
>>>> [ 1.249831] FIT: kernel sub-image
>>>> 0x00001000..0x0052fd0a "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2)
>>>> [ 1.255030] mtk_cpufreq_voltage_tracking+0x11c/0x26c
>>>> [ 1.255039] mtk_cpufreq_set_target+0x1c4/0x350
>>>> [ 1.258444] FIT: flat_dt sub-image
>>>> 0x00530000..0x005380c5 "fdt-1" (ARM64 OpenWrt bananapi_bpi-r64
>>>> device tree blob)
>>>> [ 1.261820] __cpufreq_driver_target+0x2f4/0x674
>>>> [ 1.261826] od_dbs_update+0xb8/0x19c
>>>> [ 1.266969] FIT: flat_dt sub-image
>>>> 0x00539000..0x0053911a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64
>>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>>> mt7622-bananapi-bpi-r64-pcie1)
>>>> [ 1.268431] dbs_work_handler+0x3c/0x7c
>>>> [ 1.270883] FIT: flat_dt sub-image
>>>> 0x0053a000..0x0053a20f "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64
>>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>>> mt7622-bananapi-bpi-r64-sata)
>>>> [ 1.275297] process_one_work+0x200/0x3a0
>>>> [ 1.287998] FIT: filesystem sub-image
>>>> 0x0053b000..0x00859fff "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64
>>>> rootfs)
>>>> [ 1.292237] worker_thread+0x170/0x4c0
>>>> [ 1.292244] kthread+0xd4/0xe0
>>>> [ 1.302066] FIT: selecting configured loadable "rootfs-1" to be
>>>> root filesystem
>>>> [ 1.307092] ret_from_fork+0x10/0x20
>>>> [ 1.311631] mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1)
>>>> p66(rootfs_data) p128
>>>> [ 1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>>> [ 1.413322] ---[ end trace 0000000000000000 ]---
>>> The complete log can be found here:
>>> https://gist.githubusercontent.com/PolynomialDivision/395d009c84b426d780549c5fa1f64ff1/raw/886d621d2bf6f03429586adf8a14a6c37c8d8a7d/mt7622-6-1.log
>>>
>>> Reverting commit "cpufreq: mediatek: Refine
>>> mtk_cpufreq_voltage_tracking()" fixes the kernel bug:
>>> https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
>>>
>>> The revert commit can be found here:
>>> https://github.com/PolynomialDivision/openwrt/commit/1df941d0334000e3aced43b7d50cdac0da8bf427
>>>
>>> The branch I use to build the 6.1rc2 on a Banana Pi R64 can be found
>>> here:
>>> https://github.com/PolynomialDivision/openwrt/commits/bump-mt7622-rebase
>>>
>>
>> Thanks for the report.
>> Could you test with a plain upstream kernel? That would help us to
>> verify that this is a upstream problem and not introduced by some
>> openwrt patches.
>>
>> Regards,
>> Matthias
#regzbot ignore-activity
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-12-01 15:08 ` Thorsten Leemhuis
(?)
@ 2022-12-01 15:26 ` Daniel Golle
-1 siblings, 0 replies; 75+ messages in thread
From: Daniel Golle @ 2022-12-01 15:26 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Nick, Matthias Brugger, jia-wei.chang, rex-bc.chen,
angelogioacchino.delregno, viresh.kumar, Frank Wunderlich,
regressions, linux-pm, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, Hühn, Thomas
On Thu, Dec 01, 2022 at 04:08:50PM +0100, Thorsten Leemhuis wrote:
> Hi, this is your Linux kernel regression tracker. Top-posting for once,
> to make this easily accessible to everyone.
>
> I noticed this regression didn't make any progress
>
> Matthias, is that because Nick didn't exactly do what you asked for (he
> afaics tried -next, but nevertheless patches it)? Or is there another
> reason?
I've also tried this on plain linux-next, also using the BPi-R64 and
can confirm the issue exists also there, without any additional patches
applied.
Reverting commit 6a17b3876b ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()")
fixes the issue. Unfortunately, by now it no longer reverts cleanly and
requires a tiny amount of manual clean-up...
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>
> P.S.: As the Linux kernel's regression tracker I deal with a lot of
> reports and sometimes miss something important when writing mails like
> this. If that's the case here, don't hesitate to tell me in a public
> reply, it's in everyone's interest to set the public record straight.
>
> On 15.11.22 20:44, Nick wrote:
> > I used now the linux-next kernel tree (with
> > https://patchwork.ozlabs.org/project/linux-mtd/list/?series=327227 so
> > single uImage.FIT will work).
> >
> > Same issue:
> >
> >> [ 0.886209] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose
> >> debug info unavailable]
> >>
> >> [ 0.894663] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
> >>
> >> [ 0.900759] Modules linked in:
> >>
> >> [ 0.903819] CPU: 1 PID: 79 Comm: kworker/1:1 Tainted: G S
> >> 6.1.0-rc5-next-20221115+ #0
> >>
> >> [ 0.904360] pstore: Using crash dump compression: deflate
> >>
> >> [ 0.913038] Hardware name: Bananapi BPI-R64 (DT)
> >>
> >> [ 0.913043] Workqueue: events dbs_work_handler
> >>
> >> [ 0.913056] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
> >> BTYPE=--)
> >>
> >> [ 0.913063] pc : regulator_check_voltage+0xb0/0xf0
> >>
> >> [ 0.913070] lr : regulator_set_voltage_unlocked+0x88/0x110
> >>
> >> [ 0.913077] sp : ffffffc00cef3b30
> >>
> >> [ 0.913080] x29: ffffffc00cef3b30 x28: ffffff8006f6f800 x27:
> >> ffffff8006f6fa00
> >>
> >> [ 0.931243] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
> >>
> >> [ 0.934474]
> >>
> >> [ 0.934475] x26: 00000000001312d0 x25: 0000000000000024
> >>
> >> [ 0.939298] mtk-pcie 1a143000.pcie: Parsing ranges property...
> >>
> >> [ 0.944730] x24: 0000000000118c30
> >>
> >> [ 0.948038] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff ->
> >> 0x0020000000
> >>
> >> [ 0.955155]
> >>
> >> [ 0.955157] x23: 0000000000149970 x22: ffffff8000861800 x21:
> >> ffffff8006f6f800
> >>
> >> [ 0.955166] x20: 00000000001312d0 x19: 0000000000000000 x18:
> >> 00000000cfad1bd3
> >>
> >> [ 0.955174] x17: 000000000000000c x16: 0000000000000005 x15:
> >> 0000000000000000
> >>
> >> [ 1.008473] x14: 0000000000000000 x13: 0000000000000165 x12:
> >> 0101010101010101
> >>
> >> [ 1.015608] x11: 00000000017d7840 x10: 0000000000000850 x9 :
> >> ffffffc00cef3900
> >>
> >> [ 1.017014] mmc0: new HS200 MMC card at address 0001
> >>
> >> [ 1.022740] x8 : ffffff8005ee9f30 x7 : 0000000000000001 x6 :
> >> 00000000001312d0
> >>
> >> [ 1.022748] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
> >> 0000000000000000
> >>
> >> [ 1.022756] x2 : ffffffc00cef3b68 x1 : ffffffc00cef3b6c
> >>
> >> [ 1.029034] mmcblk0: mmc0:0001 008G30 7.28 GiB
> >>
> >> [ 1.034833] x0 : ffffff8000861800
> >>
> >> [ 1.034838] Call trace:
> >>
> >> [ 1.044528] Alternate GPT is invalid, using primary GPT.
> >>
> >> [ 1.047175] regulator_check_voltage+0xb0/0xf0
> >>
> >> [ 1.052603] FIT: Selected configuration: "config-1" (OpenWrt
> >> bananapi_bpi-r64)
> >>
> >> [ 1.055090] regulator_set_voltage+0x3c/0x64
> >>
> >> [ 1.057539] FIT: kernel sub-image 0x00001000..0x005200f9 "kernel-1"
> >> (ARM64 OpenWrt Linux-6.1-rc2)
> >>
> >> [ 1.062824] mtk_cpufreq_voltage_tracking+0x12c/0x27c
> >>
> >> [ 1.062831] mtk_cpufreq_set_target+0x1c4/0x350
> >>
> >> [ 1.062837] __cpufreq_driver_target+0x2dc/0x660
> >>
> >> [ 1.067289] FIT: flat_dt sub-image 0x00521000..0x005272d9 "fdt-1"
> >> (ARM64 OpenWrt bananapi_bpi-r64 device tree blob)
> >>
> >> [ 1.074484] od_dbs_update+0xb8/0x19c
> >>
> >> [ 1.074490] dbs_work_handler+0x3c/0x7c
> >>
> >> [ 1.078774] FIT: filesystem sub-image 0x00528000..0x00829fff
> >> "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs)
> >>
> >> [ 1.088560] process_one_work+0x200/0x3a0
> >>
> >> [ 1.093624] mmcblk0: p1 p2 p3 p4 p65(rootfs-1) p66(rootfs_data) p128
> >>
> >> [ 1.098116] worker_thread+0x170/0x4c0
> >>
> >> [ 1.104575] mmcblk0boot0: mmc0:0001 008G30 4.00 MiB
> >>
> >> [ 1.114009] kthread+0xd4/0xe0
> >>
> >> [ 1.114016] ret_from_fork+0x10/0x20
> >>
> >> [ 1.114028] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
> >>
> >> [ 1.114033] ---[ end trace 0000000000000000 ]---
> >> [ 0.878926] ------------[ cut here ]------------
> >>
> >
> > Full log:
> > https://gist.github.com/PolynomialDivision/4a555079887b288f4795b28eb3607aa9
> >
> > Big thanks to Daniel helping me to build a vanilla kernel with OpenWrt
> > build system.
> >
> > Bests
> > Nick
> >
> > On 11/10/22 12:26, Matthias Brugger wrote:
> >> Hi Nick,
> >>
> >> On 09/11/2022 14:35, Nick wrote:
> >>> Hi,
> >>> while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the
> >>> kernel is crashing while booting on a Banana Pi R64 (MT7622):
> >>>
> >>>> [ 1.055565] ------------[ cut here ]------------
> >>>> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0
> >>>> [verbose debug info unavailable]
> >>>> [ 1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000
> >>>> ranges:
> >>>> [ 1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
> >>>> [ 1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
> >>>> [ 1.081257] Modules linked in:
> >>>> [ 1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G
> >>>> S 6.1-rc2 #0
> >>>> [ 1.087088] mtk-pcie 1a143000.pcie: MEM
> >>>> 0x0020000000..0x0027ffffff -> 0x0020000000
> >>>> [ 1.090126] Hardware name: Bananapi BPI-R64 (DT)
> >>>> [ 1.110541] Workqueue: events dbs_work_handler
> >>>> [ 1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
> >>>> BTYPE=--)
> >>>> [ 1.121944] pc : regulator_check_voltage+0xb0/0xf0
> >>>> [ 1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
> >>>> [ 1.129638] mmc1: host does not support reading read-only switch,
> >>>> assuming write-enable
> >>>> [ 1.132207] sp : ffffffc00956bb30
> >>>> [ 1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27:
> >>>> 0000000000000024
> >>>> [ 1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24:
> >>>> 00000000001312d0
> >>>> [ 1.132227] x23: 0000000000149970
> >>>> [ 1.146036] mmc1: new high speed SDHC card at address e624
> >>>> [ 1.150642] x22: ffffff800038f800
> >>>> [ 1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB
> >>>> [ 1.161068] x21: ffffff8000efb100
> >>>> [ 1.161072] x20: 00000000001312d0
> >>>> [ 1.175424] GPT:partition_entry_array_crc32 values don't match:
> >>>> 0xa0b5ce6d != 0xab54d286
> >>>> [ 1.177757] x19: 0000000000000000 x18: 00000000799b2550
> >>>> [ 1.181067] GPT:Primary header thinks Alt. header is not at the
> >>>> end of the disk.
> >>>> [ 1.189143] x17: 0000000000000003 x16: 0000000000000001 x15:
> >>>> 0000000000000000
> >>>> [ 1.189151] x14: 0000000000000000 x13: 0000000000000146 x12:
> >>>> 00000000fa83b2da
> >>>> [ 1.189159] x11: 000000000000013d x10: 0000000000000850
> >>>> [ 1.194472] GPT:305184 != 31116287
> >>>> [ 1.201842] x9 : ffffffc00956b910
> >>>> [ 1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
> >>>> [ 1.208970] GPT:Alternate GPT header not at the end of the disk.
> >>>> [ 1.216092] x6 : 00000000001312d0
> >>>> [ 1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
> >>>> 0000000000000000
> >>>> [ 1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
> >>>> [ 1.221321] GPT:305184 != 31116287
> >>>> [ 1.224706] x0 : ffffff800038f800
> >>>> [ 1.228095] GPT: Use GNU Parted to correct GPT errors.
> >>>> [ 1.233307]
> >>>> [ 1.233309] Call trace:
> >>>> [ 1.233312] regulator_check_voltage+0xb0/0xf0
> >>>> [ 1.242680] FIT: Selected configuration:
> >>>> "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64
> >>>> with mt7622-bananapi-bpi-r64-pcie1)
> >>>> [ 1.242694] regulator_set_voltage+0x3c/0x64
> >>>> [ 1.249831] FIT: kernel sub-image
> >>>> 0x00001000..0x0052fd0a "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2)
> >>>> [ 1.255030] mtk_cpufreq_voltage_tracking+0x11c/0x26c
> >>>> [ 1.255039] mtk_cpufreq_set_target+0x1c4/0x350
> >>>> [ 1.258444] FIT: flat_dt sub-image
> >>>> 0x00530000..0x005380c5 "fdt-1" (ARM64 OpenWrt bananapi_bpi-r64
> >>>> device tree blob)
> >>>> [ 1.261820] __cpufreq_driver_target+0x2f4/0x674
> >>>> [ 1.261826] od_dbs_update+0xb8/0x19c
> >>>> [ 1.266969] FIT: flat_dt sub-image
> >>>> 0x00539000..0x0053911a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64
> >>>> OpenWrt bananapi_bpi-r64 device tree overlay
> >>>> mt7622-bananapi-bpi-r64-pcie1)
> >>>> [ 1.268431] dbs_work_handler+0x3c/0x7c
> >>>> [ 1.270883] FIT: flat_dt sub-image
> >>>> 0x0053a000..0x0053a20f "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64
> >>>> OpenWrt bananapi_bpi-r64 device tree overlay
> >>>> mt7622-bananapi-bpi-r64-sata)
> >>>> [ 1.275297] process_one_work+0x200/0x3a0
> >>>> [ 1.287998] FIT: filesystem sub-image
> >>>> 0x0053b000..0x00859fff "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64
> >>>> rootfs)
> >>>> [ 1.292237] worker_thread+0x170/0x4c0
> >>>> [ 1.292244] kthread+0xd4/0xe0
> >>>> [ 1.302066] FIT: selecting configured loadable "rootfs-1" to be
> >>>> root filesystem
> >>>> [ 1.307092] ret_from_fork+0x10/0x20
> >>>> [ 1.311631] mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1)
> >>>> p66(rootfs_data) p128
> >>>> [ 1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
> >>>> [ 1.413322] ---[ end trace 0000000000000000 ]---
> >>> The complete log can be found here:
> >>> https://gist.githubusercontent.com/PolynomialDivision/395d009c84b426d780549c5fa1f64ff1/raw/886d621d2bf6f03429586adf8a14a6c37c8d8a7d/mt7622-6-1.log
> >>>
> >>> Reverting commit "cpufreq: mediatek: Refine
> >>> mtk_cpufreq_voltage_tracking()" fixes the kernel bug:
> >>> https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
> >>>
> >>> The revert commit can be found here:
> >>> https://github.com/PolynomialDivision/openwrt/commit/1df941d0334000e3aced43b7d50cdac0da8bf427
> >>>
> >>> The branch I use to build the 6.1rc2 on a Banana Pi R64 can be found
> >>> here:
> >>> https://github.com/PolynomialDivision/openwrt/commits/bump-mt7622-rebase
> >>>
> >>
> >> Thanks for the report.
> >> Could you test with a plain upstream kernel? That would help us to
> >> verify that this is a upstream problem and not introduced by some
> >> openwrt patches.
> >>
> >> Regards,
> >> Matthias
>
> #regzbot ignore-activity
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-01 15:26 ` Daniel Golle
0 siblings, 0 replies; 75+ messages in thread
From: Daniel Golle @ 2022-12-01 15:26 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Project_Global_Chrome_Upstream_Group, Nick, viresh.kumar,
linux-pm, regressions, rex-bc.chen, linux-mediatek,
Matthias Brugger, Hühn, Thomas, jia-wei.chang,
linux-arm-kernel, angelogioacchino.delregno
On Thu, Dec 01, 2022 at 04:08:50PM +0100, Thorsten Leemhuis wrote:
> Hi, this is your Linux kernel regression tracker. Top-posting for once,
> to make this easily accessible to everyone.
>
> I noticed this regression didn't make any progress
>
> Matthias, is that because Nick didn't exactly do what you asked for (he
> afaics tried -next, but nevertheless patches it)? Or is there another
> reason?
I've also tried this on plain linux-next, also using the BPi-R64 and
can confirm the issue exists also there, without any additional patches
applied.
Reverting commit 6a17b3876b ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()")
fixes the issue. Unfortunately, by now it no longer reverts cleanly and
requires a tiny amount of manual clean-up...
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>
> P.S.: As the Linux kernel's regression tracker I deal with a lot of
> reports and sometimes miss something important when writing mails like
> this. If that's the case here, don't hesitate to tell me in a public
> reply, it's in everyone's interest to set the public record straight.
>
> On 15.11.22 20:44, Nick wrote:
> > I used now the linux-next kernel tree (with
> > https://patchwork.ozlabs.org/project/linux-mtd/list/?series=327227 so
> > single uImage.FIT will work).
> >
> > Same issue:
> >
> >> [ 0.886209] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose
> >> debug info unavailable]
> >>
> >> [ 0.894663] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
> >>
> >> [ 0.900759] Modules linked in:
> >>
> >> [ 0.903819] CPU: 1 PID: 79 Comm: kworker/1:1 Tainted: G S
> >> 6.1.0-rc5-next-20221115+ #0
> >>
> >> [ 0.904360] pstore: Using crash dump compression: deflate
> >>
> >> [ 0.913038] Hardware name: Bananapi BPI-R64 (DT)
> >>
> >> [ 0.913043] Workqueue: events dbs_work_handler
> >>
> >> [ 0.913056] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
> >> BTYPE=--)
> >>
> >> [ 0.913063] pc : regulator_check_voltage+0xb0/0xf0
> >>
> >> [ 0.913070] lr : regulator_set_voltage_unlocked+0x88/0x110
> >>
> >> [ 0.913077] sp : ffffffc00cef3b30
> >>
> >> [ 0.913080] x29: ffffffc00cef3b30 x28: ffffff8006f6f800 x27:
> >> ffffff8006f6fa00
> >>
> >> [ 0.931243] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
> >>
> >> [ 0.934474]
> >>
> >> [ 0.934475] x26: 00000000001312d0 x25: 0000000000000024
> >>
> >> [ 0.939298] mtk-pcie 1a143000.pcie: Parsing ranges property...
> >>
> >> [ 0.944730] x24: 0000000000118c30
> >>
> >> [ 0.948038] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff ->
> >> 0x0020000000
> >>
> >> [ 0.955155]
> >>
> >> [ 0.955157] x23: 0000000000149970 x22: ffffff8000861800 x21:
> >> ffffff8006f6f800
> >>
> >> [ 0.955166] x20: 00000000001312d0 x19: 0000000000000000 x18:
> >> 00000000cfad1bd3
> >>
> >> [ 0.955174] x17: 000000000000000c x16: 0000000000000005 x15:
> >> 0000000000000000
> >>
> >> [ 1.008473] x14: 0000000000000000 x13: 0000000000000165 x12:
> >> 0101010101010101
> >>
> >> [ 1.015608] x11: 00000000017d7840 x10: 0000000000000850 x9 :
> >> ffffffc00cef3900
> >>
> >> [ 1.017014] mmc0: new HS200 MMC card at address 0001
> >>
> >> [ 1.022740] x8 : ffffff8005ee9f30 x7 : 0000000000000001 x6 :
> >> 00000000001312d0
> >>
> >> [ 1.022748] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
> >> 0000000000000000
> >>
> >> [ 1.022756] x2 : ffffffc00cef3b68 x1 : ffffffc00cef3b6c
> >>
> >> [ 1.029034] mmcblk0: mmc0:0001 008G30 7.28 GiB
> >>
> >> [ 1.034833] x0 : ffffff8000861800
> >>
> >> [ 1.034838] Call trace:
> >>
> >> [ 1.044528] Alternate GPT is invalid, using primary GPT.
> >>
> >> [ 1.047175] regulator_check_voltage+0xb0/0xf0
> >>
> >> [ 1.052603] FIT: Selected configuration: "config-1" (OpenWrt
> >> bananapi_bpi-r64)
> >>
> >> [ 1.055090] regulator_set_voltage+0x3c/0x64
> >>
> >> [ 1.057539] FIT: kernel sub-image 0x00001000..0x005200f9 "kernel-1"
> >> (ARM64 OpenWrt Linux-6.1-rc2)
> >>
> >> [ 1.062824] mtk_cpufreq_voltage_tracking+0x12c/0x27c
> >>
> >> [ 1.062831] mtk_cpufreq_set_target+0x1c4/0x350
> >>
> >> [ 1.062837] __cpufreq_driver_target+0x2dc/0x660
> >>
> >> [ 1.067289] FIT: flat_dt sub-image 0x00521000..0x005272d9 "fdt-1"
> >> (ARM64 OpenWrt bananapi_bpi-r64 device tree blob)
> >>
> >> [ 1.074484] od_dbs_update+0xb8/0x19c
> >>
> >> [ 1.074490] dbs_work_handler+0x3c/0x7c
> >>
> >> [ 1.078774] FIT: filesystem sub-image 0x00528000..0x00829fff
> >> "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs)
> >>
> >> [ 1.088560] process_one_work+0x200/0x3a0
> >>
> >> [ 1.093624] mmcblk0: p1 p2 p3 p4 p65(rootfs-1) p66(rootfs_data) p128
> >>
> >> [ 1.098116] worker_thread+0x170/0x4c0
> >>
> >> [ 1.104575] mmcblk0boot0: mmc0:0001 008G30 4.00 MiB
> >>
> >> [ 1.114009] kthread+0xd4/0xe0
> >>
> >> [ 1.114016] ret_from_fork+0x10/0x20
> >>
> >> [ 1.114028] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
> >>
> >> [ 1.114033] ---[ end trace 0000000000000000 ]---
> >> [ 0.878926] ------------[ cut here ]------------
> >>
> >
> > Full log:
> > https://gist.github.com/PolynomialDivision/4a555079887b288f4795b28eb3607aa9
> >
> > Big thanks to Daniel helping me to build a vanilla kernel with OpenWrt
> > build system.
> >
> > Bests
> > Nick
> >
> > On 11/10/22 12:26, Matthias Brugger wrote:
> >> Hi Nick,
> >>
> >> On 09/11/2022 14:35, Nick wrote:
> >>> Hi,
> >>> while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the
> >>> kernel is crashing while booting on a Banana Pi R64 (MT7622):
> >>>
> >>>> [ 1.055565] ------------[ cut here ]------------
> >>>> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0
> >>>> [verbose debug info unavailable]
> >>>> [ 1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000
> >>>> ranges:
> >>>> [ 1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
> >>>> [ 1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
> >>>> [ 1.081257] Modules linked in:
> >>>> [ 1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G
> >>>> S 6.1-rc2 #0
> >>>> [ 1.087088] mtk-pcie 1a143000.pcie: MEM
> >>>> 0x0020000000..0x0027ffffff -> 0x0020000000
> >>>> [ 1.090126] Hardware name: Bananapi BPI-R64 (DT)
> >>>> [ 1.110541] Workqueue: events dbs_work_handler
> >>>> [ 1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
> >>>> BTYPE=--)
> >>>> [ 1.121944] pc : regulator_check_voltage+0xb0/0xf0
> >>>> [ 1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
> >>>> [ 1.129638] mmc1: host does not support reading read-only switch,
> >>>> assuming write-enable
> >>>> [ 1.132207] sp : ffffffc00956bb30
> >>>> [ 1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27:
> >>>> 0000000000000024
> >>>> [ 1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24:
> >>>> 00000000001312d0
> >>>> [ 1.132227] x23: 0000000000149970
> >>>> [ 1.146036] mmc1: new high speed SDHC card at address e624
> >>>> [ 1.150642] x22: ffffff800038f800
> >>>> [ 1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB
> >>>> [ 1.161068] x21: ffffff8000efb100
> >>>> [ 1.161072] x20: 00000000001312d0
> >>>> [ 1.175424] GPT:partition_entry_array_crc32 values don't match:
> >>>> 0xa0b5ce6d != 0xab54d286
> >>>> [ 1.177757] x19: 0000000000000000 x18: 00000000799b2550
> >>>> [ 1.181067] GPT:Primary header thinks Alt. header is not at the
> >>>> end of the disk.
> >>>> [ 1.189143] x17: 0000000000000003 x16: 0000000000000001 x15:
> >>>> 0000000000000000
> >>>> [ 1.189151] x14: 0000000000000000 x13: 0000000000000146 x12:
> >>>> 00000000fa83b2da
> >>>> [ 1.189159] x11: 000000000000013d x10: 0000000000000850
> >>>> [ 1.194472] GPT:305184 != 31116287
> >>>> [ 1.201842] x9 : ffffffc00956b910
> >>>> [ 1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
> >>>> [ 1.208970] GPT:Alternate GPT header not at the end of the disk.
> >>>> [ 1.216092] x6 : 00000000001312d0
> >>>> [ 1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
> >>>> 0000000000000000
> >>>> [ 1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
> >>>> [ 1.221321] GPT:305184 != 31116287
> >>>> [ 1.224706] x0 : ffffff800038f800
> >>>> [ 1.228095] GPT: Use GNU Parted to correct GPT errors.
> >>>> [ 1.233307]
> >>>> [ 1.233309] Call trace:
> >>>> [ 1.233312] regulator_check_voltage+0xb0/0xf0
> >>>> [ 1.242680] FIT: Selected configuration:
> >>>> "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64
> >>>> with mt7622-bananapi-bpi-r64-pcie1)
> >>>> [ 1.242694] regulator_set_voltage+0x3c/0x64
> >>>> [ 1.249831] FIT: kernel sub-image
> >>>> 0x00001000..0x0052fd0a "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2)
> >>>> [ 1.255030] mtk_cpufreq_voltage_tracking+0x11c/0x26c
> >>>> [ 1.255039] mtk_cpufreq_set_target+0x1c4/0x350
> >>>> [ 1.258444] FIT: flat_dt sub-image
> >>>> 0x00530000..0x005380c5 "fdt-1" (ARM64 OpenWrt bananapi_bpi-r64
> >>>> device tree blob)
> >>>> [ 1.261820] __cpufreq_driver_target+0x2f4/0x674
> >>>> [ 1.261826] od_dbs_update+0xb8/0x19c
> >>>> [ 1.266969] FIT: flat_dt sub-image
> >>>> 0x00539000..0x0053911a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64
> >>>> OpenWrt bananapi_bpi-r64 device tree overlay
> >>>> mt7622-bananapi-bpi-r64-pcie1)
> >>>> [ 1.268431] dbs_work_handler+0x3c/0x7c
> >>>> [ 1.270883] FIT: flat_dt sub-image
> >>>> 0x0053a000..0x0053a20f "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64
> >>>> OpenWrt bananapi_bpi-r64 device tree overlay
> >>>> mt7622-bananapi-bpi-r64-sata)
> >>>> [ 1.275297] process_one_work+0x200/0x3a0
> >>>> [ 1.287998] FIT: filesystem sub-image
> >>>> 0x0053b000..0x00859fff "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64
> >>>> rootfs)
> >>>> [ 1.292237] worker_thread+0x170/0x4c0
> >>>> [ 1.292244] kthread+0xd4/0xe0
> >>>> [ 1.302066] FIT: selecting configured loadable "rootfs-1" to be
> >>>> root filesystem
> >>>> [ 1.307092] ret_from_fork+0x10/0x20
> >>>> [ 1.311631] mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1)
> >>>> p66(rootfs_data) p128
> >>>> [ 1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
> >>>> [ 1.413322] ---[ end trace 0000000000000000 ]---
> >>> The complete log can be found here:
> >>> https://gist.githubusercontent.com/PolynomialDivision/395d009c84b426d780549c5fa1f64ff1/raw/886d621d2bf6f03429586adf8a14a6c37c8d8a7d/mt7622-6-1.log
> >>>
> >>> Reverting commit "cpufreq: mediatek: Refine
> >>> mtk_cpufreq_voltage_tracking()" fixes the kernel bug:
> >>> https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
> >>>
> >>> The revert commit can be found here:
> >>> https://github.com/PolynomialDivision/openwrt/commit/1df941d0334000e3aced43b7d50cdac0da8bf427
> >>>
> >>> The branch I use to build the 6.1rc2 on a Banana Pi R64 can be found
> >>> here:
> >>> https://github.com/PolynomialDivision/openwrt/commits/bump-mt7622-rebase
> >>>
> >>
> >> Thanks for the report.
> >> Could you test with a plain upstream kernel? That would help us to
> >> verify that this is a upstream problem and not introduced by some
> >> openwrt patches.
> >>
> >> Regards,
> >> Matthias
>
> #regzbot ignore-activity
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-01 15:26 ` Daniel Golle
0 siblings, 0 replies; 75+ messages in thread
From: Daniel Golle @ 2022-12-01 15:26 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Nick, Matthias Brugger, jia-wei.chang, rex-bc.chen,
angelogioacchino.delregno, viresh.kumar, Frank Wunderlich,
regressions, linux-pm, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, Hühn, Thomas
On Thu, Dec 01, 2022 at 04:08:50PM +0100, Thorsten Leemhuis wrote:
> Hi, this is your Linux kernel regression tracker. Top-posting for once,
> to make this easily accessible to everyone.
>
> I noticed this regression didn't make any progress
>
> Matthias, is that because Nick didn't exactly do what you asked for (he
> afaics tried -next, but nevertheless patches it)? Or is there another
> reason?
I've also tried this on plain linux-next, also using the BPi-R64 and
can confirm the issue exists also there, without any additional patches
applied.
Reverting commit 6a17b3876b ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()")
fixes the issue. Unfortunately, by now it no longer reverts cleanly and
requires a tiny amount of manual clean-up...
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>
> P.S.: As the Linux kernel's regression tracker I deal with a lot of
> reports and sometimes miss something important when writing mails like
> this. If that's the case here, don't hesitate to tell me in a public
> reply, it's in everyone's interest to set the public record straight.
>
> On 15.11.22 20:44, Nick wrote:
> > I used now the linux-next kernel tree (with
> > https://patchwork.ozlabs.org/project/linux-mtd/list/?series=327227 so
> > single uImage.FIT will work).
> >
> > Same issue:
> >
> >> [ 0.886209] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose
> >> debug info unavailable]
> >>
> >> [ 0.894663] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
> >>
> >> [ 0.900759] Modules linked in:
> >>
> >> [ 0.903819] CPU: 1 PID: 79 Comm: kworker/1:1 Tainted: G S
> >> 6.1.0-rc5-next-20221115+ #0
> >>
> >> [ 0.904360] pstore: Using crash dump compression: deflate
> >>
> >> [ 0.913038] Hardware name: Bananapi BPI-R64 (DT)
> >>
> >> [ 0.913043] Workqueue: events dbs_work_handler
> >>
> >> [ 0.913056] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
> >> BTYPE=--)
> >>
> >> [ 0.913063] pc : regulator_check_voltage+0xb0/0xf0
> >>
> >> [ 0.913070] lr : regulator_set_voltage_unlocked+0x88/0x110
> >>
> >> [ 0.913077] sp : ffffffc00cef3b30
> >>
> >> [ 0.913080] x29: ffffffc00cef3b30 x28: ffffff8006f6f800 x27:
> >> ffffff8006f6fa00
> >>
> >> [ 0.931243] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
> >>
> >> [ 0.934474]
> >>
> >> [ 0.934475] x26: 00000000001312d0 x25: 0000000000000024
> >>
> >> [ 0.939298] mtk-pcie 1a143000.pcie: Parsing ranges property...
> >>
> >> [ 0.944730] x24: 0000000000118c30
> >>
> >> [ 0.948038] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff ->
> >> 0x0020000000
> >>
> >> [ 0.955155]
> >>
> >> [ 0.955157] x23: 0000000000149970 x22: ffffff8000861800 x21:
> >> ffffff8006f6f800
> >>
> >> [ 0.955166] x20: 00000000001312d0 x19: 0000000000000000 x18:
> >> 00000000cfad1bd3
> >>
> >> [ 0.955174] x17: 000000000000000c x16: 0000000000000005 x15:
> >> 0000000000000000
> >>
> >> [ 1.008473] x14: 0000000000000000 x13: 0000000000000165 x12:
> >> 0101010101010101
> >>
> >> [ 1.015608] x11: 00000000017d7840 x10: 0000000000000850 x9 :
> >> ffffffc00cef3900
> >>
> >> [ 1.017014] mmc0: new HS200 MMC card at address 0001
> >>
> >> [ 1.022740] x8 : ffffff8005ee9f30 x7 : 0000000000000001 x6 :
> >> 00000000001312d0
> >>
> >> [ 1.022748] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
> >> 0000000000000000
> >>
> >> [ 1.022756] x2 : ffffffc00cef3b68 x1 : ffffffc00cef3b6c
> >>
> >> [ 1.029034] mmcblk0: mmc0:0001 008G30 7.28 GiB
> >>
> >> [ 1.034833] x0 : ffffff8000861800
> >>
> >> [ 1.034838] Call trace:
> >>
> >> [ 1.044528] Alternate GPT is invalid, using primary GPT.
> >>
> >> [ 1.047175] regulator_check_voltage+0xb0/0xf0
> >>
> >> [ 1.052603] FIT: Selected configuration: "config-1" (OpenWrt
> >> bananapi_bpi-r64)
> >>
> >> [ 1.055090] regulator_set_voltage+0x3c/0x64
> >>
> >> [ 1.057539] FIT: kernel sub-image 0x00001000..0x005200f9 "kernel-1"
> >> (ARM64 OpenWrt Linux-6.1-rc2)
> >>
> >> [ 1.062824] mtk_cpufreq_voltage_tracking+0x12c/0x27c
> >>
> >> [ 1.062831] mtk_cpufreq_set_target+0x1c4/0x350
> >>
> >> [ 1.062837] __cpufreq_driver_target+0x2dc/0x660
> >>
> >> [ 1.067289] FIT: flat_dt sub-image 0x00521000..0x005272d9 "fdt-1"
> >> (ARM64 OpenWrt bananapi_bpi-r64 device tree blob)
> >>
> >> [ 1.074484] od_dbs_update+0xb8/0x19c
> >>
> >> [ 1.074490] dbs_work_handler+0x3c/0x7c
> >>
> >> [ 1.078774] FIT: filesystem sub-image 0x00528000..0x00829fff
> >> "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs)
> >>
> >> [ 1.088560] process_one_work+0x200/0x3a0
> >>
> >> [ 1.093624] mmcblk0: p1 p2 p3 p4 p65(rootfs-1) p66(rootfs_data) p128
> >>
> >> [ 1.098116] worker_thread+0x170/0x4c0
> >>
> >> [ 1.104575] mmcblk0boot0: mmc0:0001 008G30 4.00 MiB
> >>
> >> [ 1.114009] kthread+0xd4/0xe0
> >>
> >> [ 1.114016] ret_from_fork+0x10/0x20
> >>
> >> [ 1.114028] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
> >>
> >> [ 1.114033] ---[ end trace 0000000000000000 ]---
> >> [ 0.878926] ------------[ cut here ]------------
> >>
> >
> > Full log:
> > https://gist.github.com/PolynomialDivision/4a555079887b288f4795b28eb3607aa9
> >
> > Big thanks to Daniel helping me to build a vanilla kernel with OpenWrt
> > build system.
> >
> > Bests
> > Nick
> >
> > On 11/10/22 12:26, Matthias Brugger wrote:
> >> Hi Nick,
> >>
> >> On 09/11/2022 14:35, Nick wrote:
> >>> Hi,
> >>> while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the
> >>> kernel is crashing while booting on a Banana Pi R64 (MT7622):
> >>>
> >>>> [ 1.055565] ------------[ cut here ]------------
> >>>> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0
> >>>> [verbose debug info unavailable]
> >>>> [ 1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000
> >>>> ranges:
> >>>> [ 1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
> >>>> [ 1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
> >>>> [ 1.081257] Modules linked in:
> >>>> [ 1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G
> >>>> S 6.1-rc2 #0
> >>>> [ 1.087088] mtk-pcie 1a143000.pcie: MEM
> >>>> 0x0020000000..0x0027ffffff -> 0x0020000000
> >>>> [ 1.090126] Hardware name: Bananapi BPI-R64 (DT)
> >>>> [ 1.110541] Workqueue: events dbs_work_handler
> >>>> [ 1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
> >>>> BTYPE=--)
> >>>> [ 1.121944] pc : regulator_check_voltage+0xb0/0xf0
> >>>> [ 1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
> >>>> [ 1.129638] mmc1: host does not support reading read-only switch,
> >>>> assuming write-enable
> >>>> [ 1.132207] sp : ffffffc00956bb30
> >>>> [ 1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27:
> >>>> 0000000000000024
> >>>> [ 1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24:
> >>>> 00000000001312d0
> >>>> [ 1.132227] x23: 0000000000149970
> >>>> [ 1.146036] mmc1: new high speed SDHC card at address e624
> >>>> [ 1.150642] x22: ffffff800038f800
> >>>> [ 1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB
> >>>> [ 1.161068] x21: ffffff8000efb100
> >>>> [ 1.161072] x20: 00000000001312d0
> >>>> [ 1.175424] GPT:partition_entry_array_crc32 values don't match:
> >>>> 0xa0b5ce6d != 0xab54d286
> >>>> [ 1.177757] x19: 0000000000000000 x18: 00000000799b2550
> >>>> [ 1.181067] GPT:Primary header thinks Alt. header is not at the
> >>>> end of the disk.
> >>>> [ 1.189143] x17: 0000000000000003 x16: 0000000000000001 x15:
> >>>> 0000000000000000
> >>>> [ 1.189151] x14: 0000000000000000 x13: 0000000000000146 x12:
> >>>> 00000000fa83b2da
> >>>> [ 1.189159] x11: 000000000000013d x10: 0000000000000850
> >>>> [ 1.194472] GPT:305184 != 31116287
> >>>> [ 1.201842] x9 : ffffffc00956b910
> >>>> [ 1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
> >>>> [ 1.208970] GPT:Alternate GPT header not at the end of the disk.
> >>>> [ 1.216092] x6 : 00000000001312d0
> >>>> [ 1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
> >>>> 0000000000000000
> >>>> [ 1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
> >>>> [ 1.221321] GPT:305184 != 31116287
> >>>> [ 1.224706] x0 : ffffff800038f800
> >>>> [ 1.228095] GPT: Use GNU Parted to correct GPT errors.
> >>>> [ 1.233307]
> >>>> [ 1.233309] Call trace:
> >>>> [ 1.233312] regulator_check_voltage+0xb0/0xf0
> >>>> [ 1.242680] FIT: Selected configuration:
> >>>> "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64
> >>>> with mt7622-bananapi-bpi-r64-pcie1)
> >>>> [ 1.242694] regulator_set_voltage+0x3c/0x64
> >>>> [ 1.249831] FIT: kernel sub-image
> >>>> 0x00001000..0x0052fd0a "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2)
> >>>> [ 1.255030] mtk_cpufreq_voltage_tracking+0x11c/0x26c
> >>>> [ 1.255039] mtk_cpufreq_set_target+0x1c4/0x350
> >>>> [ 1.258444] FIT: flat_dt sub-image
> >>>> 0x00530000..0x005380c5 "fdt-1" (ARM64 OpenWrt bananapi_bpi-r64
> >>>> device tree blob)
> >>>> [ 1.261820] __cpufreq_driver_target+0x2f4/0x674
> >>>> [ 1.261826] od_dbs_update+0xb8/0x19c
> >>>> [ 1.266969] FIT: flat_dt sub-image
> >>>> 0x00539000..0x0053911a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64
> >>>> OpenWrt bananapi_bpi-r64 device tree overlay
> >>>> mt7622-bananapi-bpi-r64-pcie1)
> >>>> [ 1.268431] dbs_work_handler+0x3c/0x7c
> >>>> [ 1.270883] FIT: flat_dt sub-image
> >>>> 0x0053a000..0x0053a20f "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64
> >>>> OpenWrt bananapi_bpi-r64 device tree overlay
> >>>> mt7622-bananapi-bpi-r64-sata)
> >>>> [ 1.275297] process_one_work+0x200/0x3a0
> >>>> [ 1.287998] FIT: filesystem sub-image
> >>>> 0x0053b000..0x00859fff "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64
> >>>> rootfs)
> >>>> [ 1.292237] worker_thread+0x170/0x4c0
> >>>> [ 1.292244] kthread+0xd4/0xe0
> >>>> [ 1.302066] FIT: selecting configured loadable "rootfs-1" to be
> >>>> root filesystem
> >>>> [ 1.307092] ret_from_fork+0x10/0x20
> >>>> [ 1.311631] mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1)
> >>>> p66(rootfs_data) p128
> >>>> [ 1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
> >>>> [ 1.413322] ---[ end trace 0000000000000000 ]---
> >>> The complete log can be found here:
> >>> https://gist.githubusercontent.com/PolynomialDivision/395d009c84b426d780549c5fa1f64ff1/raw/886d621d2bf6f03429586adf8a14a6c37c8d8a7d/mt7622-6-1.log
> >>>
> >>> Reverting commit "cpufreq: mediatek: Refine
> >>> mtk_cpufreq_voltage_tracking()" fixes the kernel bug:
> >>> https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
> >>>
> >>> The revert commit can be found here:
> >>> https://github.com/PolynomialDivision/openwrt/commit/1df941d0334000e3aced43b7d50cdac0da8bf427
> >>>
> >>> The branch I use to build the 6.1rc2 on a Banana Pi R64 can be found
> >>> here:
> >>> https://github.com/PolynomialDivision/openwrt/commits/bump-mt7622-rebase
> >>>
> >>
> >> Thanks for the report.
> >> Could you test with a plain upstream kernel? That would help us to
> >> verify that this is a upstream problem and not introduced by some
> >> openwrt patches.
> >>
> >> Regards,
> >> Matthias
>
> #regzbot ignore-activity
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-12-01 15:26 ` Daniel Golle
(?)
@ 2022-12-01 15:39 ` Thorsten Leemhuis
-1 siblings, 0 replies; 75+ messages in thread
From: Thorsten Leemhuis @ 2022-12-01 15:39 UTC (permalink / raw)
To: jia-wei.chang, viresh.kumar
Cc: Nick, Matthias Brugger, rex-bc.chen, angelogioacchino.delregno,
Frank Wunderlich, regressions, linux-pm, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, Hühn,
Thomas, Daniel Golle
On 01.12.22 16:26, Daniel Golle wrote:
> On Thu, Dec 01, 2022 at 04:08:50PM +0100, Thorsten Leemhuis wrote:
>> Hi, this is your Linux kernel regression tracker. Top-posting for once,
>> to make this easily accessible to everyone.
>>
>> I noticed this regression didn't make any progress
>>
>> Matthias, is that because Nick didn't exactly do what you asked for (he
>> afaics tried -next, but nevertheless patches it)? Or is there another
>> reason?
>
> I've also tried this on plain linux-next, also using the BPi-R64 and
> can confirm the issue exists also there, without any additional patches
> applied.
>
> Reverting commit 6a17b3876b ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()")
> fixes the issue. Unfortunately, by now it no longer reverts cleanly and
> requires a tiny amount of manual clean-up...
Thx for clarifying. And I noticed I made a mistake: I should have
directed my earlier question wrt to any progress here more into the
direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh Kumar
(who committed it).
Sorry Matthias.
Ciao, Thorsten
>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>
>> P.S.: As the Linux kernel's regression tracker I deal with a lot of
>> reports and sometimes miss something important when writing mails like
>> this. If that's the case here, don't hesitate to tell me in a public
>> reply, it's in everyone's interest to set the public record straight.
>>
>> On 15.11.22 20:44, Nick wrote:
>>> I used now the linux-next kernel tree (with
>>> https://patchwork.ozlabs.org/project/linux-mtd/list/?series=327227 so
>>> single uImage.FIT will work).
>>>
>>> Same issue:
>>>
>>>> [ 0.886209] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose
>>>> debug info unavailable]
>>>>
>>>> [ 0.894663] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>>>
>>>> [ 0.900759] Modules linked in:
>>>>
>>>> [ 0.903819] CPU: 1 PID: 79 Comm: kworker/1:1 Tainted: G S
>>>> 6.1.0-rc5-next-20221115+ #0
>>>>
>>>> [ 0.904360] pstore: Using crash dump compression: deflate
>>>>
>>>> [ 0.913038] Hardware name: Bananapi BPI-R64 (DT)
>>>>
>>>> [ 0.913043] Workqueue: events dbs_work_handler
>>>>
>>>> [ 0.913056] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>>>> BTYPE=--)
>>>>
>>>> [ 0.913063] pc : regulator_check_voltage+0xb0/0xf0
>>>>
>>>> [ 0.913070] lr : regulator_set_voltage_unlocked+0x88/0x110
>>>>
>>>> [ 0.913077] sp : ffffffc00cef3b30
>>>>
>>>> [ 0.913080] x29: ffffffc00cef3b30 x28: ffffff8006f6f800 x27:
>>>> ffffff8006f6fa00
>>>>
>>>> [ 0.931243] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
>>>>
>>>> [ 0.934474]
>>>>
>>>> [ 0.934475] x26: 00000000001312d0 x25: 0000000000000024
>>>>
>>>> [ 0.939298] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>>>
>>>> [ 0.944730] x24: 0000000000118c30
>>>>
>>>> [ 0.948038] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff ->
>>>> 0x0020000000
>>>>
>>>> [ 0.955155]
>>>>
>>>> [ 0.955157] x23: 0000000000149970 x22: ffffff8000861800 x21:
>>>> ffffff8006f6f800
>>>>
>>>> [ 0.955166] x20: 00000000001312d0 x19: 0000000000000000 x18:
>>>> 00000000cfad1bd3
>>>>
>>>> [ 0.955174] x17: 000000000000000c x16: 0000000000000005 x15:
>>>> 0000000000000000
>>>>
>>>> [ 1.008473] x14: 0000000000000000 x13: 0000000000000165 x12:
>>>> 0101010101010101
>>>>
>>>> [ 1.015608] x11: 00000000017d7840 x10: 0000000000000850 x9 :
>>>> ffffffc00cef3900
>>>>
>>>> [ 1.017014] mmc0: new HS200 MMC card at address 0001
>>>>
>>>> [ 1.022740] x8 : ffffff8005ee9f30 x7 : 0000000000000001 x6 :
>>>> 00000000001312d0
>>>>
>>>> [ 1.022748] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>>>> 0000000000000000
>>>>
>>>> [ 1.022756] x2 : ffffffc00cef3b68 x1 : ffffffc00cef3b6c
>>>>
>>>> [ 1.029034] mmcblk0: mmc0:0001 008G30 7.28 GiB
>>>>
>>>> [ 1.034833] x0 : ffffff8000861800
>>>>
>>>> [ 1.034838] Call trace:
>>>>
>>>> [ 1.044528] Alternate GPT is invalid, using primary GPT.
>>>>
>>>> [ 1.047175] regulator_check_voltage+0xb0/0xf0
>>>>
>>>> [ 1.052603] FIT: Selected configuration: "config-1" (OpenWrt
>>>> bananapi_bpi-r64)
>>>>
>>>> [ 1.055090] regulator_set_voltage+0x3c/0x64
>>>>
>>>> [ 1.057539] FIT: kernel sub-image 0x00001000..0x005200f9 "kernel-1"
>>>> (ARM64 OpenWrt Linux-6.1-rc2)
>>>>
>>>> [ 1.062824] mtk_cpufreq_voltage_tracking+0x12c/0x27c
>>>>
>>>> [ 1.062831] mtk_cpufreq_set_target+0x1c4/0x350
>>>>
>>>> [ 1.062837] __cpufreq_driver_target+0x2dc/0x660
>>>>
>>>> [ 1.067289] FIT: flat_dt sub-image 0x00521000..0x005272d9 "fdt-1"
>>>> (ARM64 OpenWrt bananapi_bpi-r64 device tree blob)
>>>>
>>>> [ 1.074484] od_dbs_update+0xb8/0x19c
>>>>
>>>> [ 1.074490] dbs_work_handler+0x3c/0x7c
>>>>
>>>> [ 1.078774] FIT: filesystem sub-image 0x00528000..0x00829fff
>>>> "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs)
>>>>
>>>> [ 1.088560] process_one_work+0x200/0x3a0
>>>>
>>>> [ 1.093624] mmcblk0: p1 p2 p3 p4 p65(rootfs-1) p66(rootfs_data) p128
>>>>
>>>> [ 1.098116] worker_thread+0x170/0x4c0
>>>>
>>>> [ 1.104575] mmcblk0boot0: mmc0:0001 008G30 4.00 MiB
>>>>
>>>> [ 1.114009] kthread+0xd4/0xe0
>>>>
>>>> [ 1.114016] ret_from_fork+0x10/0x20
>>>>
>>>> [ 1.114028] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>>>
>>>> [ 1.114033] ---[ end trace 0000000000000000 ]---
>>>> [ 0.878926] ------------[ cut here ]------------
>>>>
>>>
>>> Full log:
>>> https://gist.github.com/PolynomialDivision/4a555079887b288f4795b28eb3607aa9
>>>
>>> Big thanks to Daniel helping me to build a vanilla kernel with OpenWrt
>>> build system.
>>>
>>> Bests
>>> Nick
>>>
>>> On 11/10/22 12:26, Matthias Brugger wrote:
>>>> Hi Nick,
>>>>
>>>> On 09/11/2022 14:35, Nick wrote:
>>>>> Hi,
>>>>> while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the
>>>>> kernel is crashing while booting on a Banana Pi R64 (MT7622):
>>>>>
>>>>>> [ 1.055565] ------------[ cut here ]------------
>>>>>> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0
>>>>>> [verbose debug info unavailable]
>>>>>> [ 1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000
>>>>>> ranges:
>>>>>> [ 1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>>>>> [ 1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>>>>> [ 1.081257] Modules linked in:
>>>>>> [ 1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G
>>>>>> S 6.1-rc2 #0
>>>>>> [ 1.087088] mtk-pcie 1a143000.pcie: MEM
>>>>>> 0x0020000000..0x0027ffffff -> 0x0020000000
>>>>>> [ 1.090126] Hardware name: Bananapi BPI-R64 (DT)
>>>>>> [ 1.110541] Workqueue: events dbs_work_handler
>>>>>> [ 1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>>>>>> BTYPE=--)
>>>>>> [ 1.121944] pc : regulator_check_voltage+0xb0/0xf0
>>>>>> [ 1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
>>>>>> [ 1.129638] mmc1: host does not support reading read-only switch,
>>>>>> assuming write-enable
>>>>>> [ 1.132207] sp : ffffffc00956bb30
>>>>>> [ 1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27:
>>>>>> 0000000000000024
>>>>>> [ 1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24:
>>>>>> 00000000001312d0
>>>>>> [ 1.132227] x23: 0000000000149970
>>>>>> [ 1.146036] mmc1: new high speed SDHC card at address e624
>>>>>> [ 1.150642] x22: ffffff800038f800
>>>>>> [ 1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB
>>>>>> [ 1.161068] x21: ffffff8000efb100
>>>>>> [ 1.161072] x20: 00000000001312d0
>>>>>> [ 1.175424] GPT:partition_entry_array_crc32 values don't match:
>>>>>> 0xa0b5ce6d != 0xab54d286
>>>>>> [ 1.177757] x19: 0000000000000000 x18: 00000000799b2550
>>>>>> [ 1.181067] GPT:Primary header thinks Alt. header is not at the
>>>>>> end of the disk.
>>>>>> [ 1.189143] x17: 0000000000000003 x16: 0000000000000001 x15:
>>>>>> 0000000000000000
>>>>>> [ 1.189151] x14: 0000000000000000 x13: 0000000000000146 x12:
>>>>>> 00000000fa83b2da
>>>>>> [ 1.189159] x11: 000000000000013d x10: 0000000000000850
>>>>>> [ 1.194472] GPT:305184 != 31116287
>>>>>> [ 1.201842] x9 : ffffffc00956b910
>>>>>> [ 1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
>>>>>> [ 1.208970] GPT:Alternate GPT header not at the end of the disk.
>>>>>> [ 1.216092] x6 : 00000000001312d0
>>>>>> [ 1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>>>>>> 0000000000000000
>>>>>> [ 1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
>>>>>> [ 1.221321] GPT:305184 != 31116287
>>>>>> [ 1.224706] x0 : ffffff800038f800
>>>>>> [ 1.228095] GPT: Use GNU Parted to correct GPT errors.
>>>>>> [ 1.233307]
>>>>>> [ 1.233309] Call trace:
>>>>>> [ 1.233312] regulator_check_voltage+0xb0/0xf0
>>>>>> [ 1.242680] FIT: Selected configuration:
>>>>>> "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64
>>>>>> with mt7622-bananapi-bpi-r64-pcie1)
>>>>>> [ 1.242694] regulator_set_voltage+0x3c/0x64
>>>>>> [ 1.249831] FIT: kernel sub-image
>>>>>> 0x00001000..0x0052fd0a "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2)
>>>>>> [ 1.255030] mtk_cpufreq_voltage_tracking+0x11c/0x26c
>>>>>> [ 1.255039] mtk_cpufreq_set_target+0x1c4/0x350
>>>>>> [ 1.258444] FIT: flat_dt sub-image
>>>>>> 0x00530000..0x005380c5 "fdt-1" (ARM64 OpenWrt bananapi_bpi-r64
>>>>>> device tree blob)
>>>>>> [ 1.261820] __cpufreq_driver_target+0x2f4/0x674
>>>>>> [ 1.261826] od_dbs_update+0xb8/0x19c
>>>>>> [ 1.266969] FIT: flat_dt sub-image
>>>>>> 0x00539000..0x0053911a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64
>>>>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>>>>> mt7622-bananapi-bpi-r64-pcie1)
>>>>>> [ 1.268431] dbs_work_handler+0x3c/0x7c
>>>>>> [ 1.270883] FIT: flat_dt sub-image
>>>>>> 0x0053a000..0x0053a20f "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64
>>>>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>>>>> mt7622-bananapi-bpi-r64-sata)
>>>>>> [ 1.275297] process_one_work+0x200/0x3a0
>>>>>> [ 1.287998] FIT: filesystem sub-image
>>>>>> 0x0053b000..0x00859fff "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64
>>>>>> rootfs)
>>>>>> [ 1.292237] worker_thread+0x170/0x4c0
>>>>>> [ 1.292244] kthread+0xd4/0xe0
>>>>>> [ 1.302066] FIT: selecting configured loadable "rootfs-1" to be
>>>>>> root filesystem
>>>>>> [ 1.307092] ret_from_fork+0x10/0x20
>>>>>> [ 1.311631] mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1)
>>>>>> p66(rootfs_data) p128
>>>>>> [ 1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>>>>> [ 1.413322] ---[ end trace 0000000000000000 ]---
>>>>> The complete log can be found here:
>>>>> https://gist.githubusercontent.com/PolynomialDivision/395d009c84b426d780549c5fa1f64ff1/raw/886d621d2bf6f03429586adf8a14a6c37c8d8a7d/mt7622-6-1.log
>>>>>
>>>>> Reverting commit "cpufreq: mediatek: Refine
>>>>> mtk_cpufreq_voltage_tracking()" fixes the kernel bug:
>>>>> https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
>>>>>
>>>>> The revert commit can be found here:
>>>>> https://github.com/PolynomialDivision/openwrt/commit/1df941d0334000e3aced43b7d50cdac0da8bf427
>>>>>
>>>>> The branch I use to build the 6.1rc2 on a Banana Pi R64 can be found
>>>>> here:
>>>>> https://github.com/PolynomialDivision/openwrt/commits/bump-mt7622-rebase
>>>>>
>>>>
>>>> Thanks for the report.
>>>> Could you test with a plain upstream kernel? That would help us to
>>>> verify that this is a upstream problem and not introduced by some
>>>> openwrt patches.
>>>>
>>>> Regards,
>>>> Matthias
>>
>> #regzbot ignore-activity
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-01 15:39 ` Thorsten Leemhuis
0 siblings, 0 replies; 75+ messages in thread
From: Thorsten Leemhuis @ 2022-12-01 15:39 UTC (permalink / raw)
To: jia-wei.chang, viresh.kumar
Cc: regressions, linux-pm, Daniel Golle,
Project_Global_Chrome_Upstream_Group, rex-bc.chen,
linux-mediatek, Matthias Brugger, Hühn, Thomas,
angelogioacchino.delregno, linux-arm-kernel, Nick
On 01.12.22 16:26, Daniel Golle wrote:
> On Thu, Dec 01, 2022 at 04:08:50PM +0100, Thorsten Leemhuis wrote:
>> Hi, this is your Linux kernel regression tracker. Top-posting for once,
>> to make this easily accessible to everyone.
>>
>> I noticed this regression didn't make any progress
>>
>> Matthias, is that because Nick didn't exactly do what you asked for (he
>> afaics tried -next, but nevertheless patches it)? Or is there another
>> reason?
>
> I've also tried this on plain linux-next, also using the BPi-R64 and
> can confirm the issue exists also there, without any additional patches
> applied.
>
> Reverting commit 6a17b3876b ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()")
> fixes the issue. Unfortunately, by now it no longer reverts cleanly and
> requires a tiny amount of manual clean-up...
Thx for clarifying. And I noticed I made a mistake: I should have
directed my earlier question wrt to any progress here more into the
direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh Kumar
(who committed it).
Sorry Matthias.
Ciao, Thorsten
>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>
>> P.S.: As the Linux kernel's regression tracker I deal with a lot of
>> reports and sometimes miss something important when writing mails like
>> this. If that's the case here, don't hesitate to tell me in a public
>> reply, it's in everyone's interest to set the public record straight.
>>
>> On 15.11.22 20:44, Nick wrote:
>>> I used now the linux-next kernel tree (with
>>> https://patchwork.ozlabs.org/project/linux-mtd/list/?series=327227 so
>>> single uImage.FIT will work).
>>>
>>> Same issue:
>>>
>>>> [ 0.886209] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose
>>>> debug info unavailable]
>>>>
>>>> [ 0.894663] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>>>
>>>> [ 0.900759] Modules linked in:
>>>>
>>>> [ 0.903819] CPU: 1 PID: 79 Comm: kworker/1:1 Tainted: G S
>>>> 6.1.0-rc5-next-20221115+ #0
>>>>
>>>> [ 0.904360] pstore: Using crash dump compression: deflate
>>>>
>>>> [ 0.913038] Hardware name: Bananapi BPI-R64 (DT)
>>>>
>>>> [ 0.913043] Workqueue: events dbs_work_handler
>>>>
>>>> [ 0.913056] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>>>> BTYPE=--)
>>>>
>>>> [ 0.913063] pc : regulator_check_voltage+0xb0/0xf0
>>>>
>>>> [ 0.913070] lr : regulator_set_voltage_unlocked+0x88/0x110
>>>>
>>>> [ 0.913077] sp : ffffffc00cef3b30
>>>>
>>>> [ 0.913080] x29: ffffffc00cef3b30 x28: ffffff8006f6f800 x27:
>>>> ffffff8006f6fa00
>>>>
>>>> [ 0.931243] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
>>>>
>>>> [ 0.934474]
>>>>
>>>> [ 0.934475] x26: 00000000001312d0 x25: 0000000000000024
>>>>
>>>> [ 0.939298] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>>>
>>>> [ 0.944730] x24: 0000000000118c30
>>>>
>>>> [ 0.948038] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff ->
>>>> 0x0020000000
>>>>
>>>> [ 0.955155]
>>>>
>>>> [ 0.955157] x23: 0000000000149970 x22: ffffff8000861800 x21:
>>>> ffffff8006f6f800
>>>>
>>>> [ 0.955166] x20: 00000000001312d0 x19: 0000000000000000 x18:
>>>> 00000000cfad1bd3
>>>>
>>>> [ 0.955174] x17: 000000000000000c x16: 0000000000000005 x15:
>>>> 0000000000000000
>>>>
>>>> [ 1.008473] x14: 0000000000000000 x13: 0000000000000165 x12:
>>>> 0101010101010101
>>>>
>>>> [ 1.015608] x11: 00000000017d7840 x10: 0000000000000850 x9 :
>>>> ffffffc00cef3900
>>>>
>>>> [ 1.017014] mmc0: new HS200 MMC card at address 0001
>>>>
>>>> [ 1.022740] x8 : ffffff8005ee9f30 x7 : 0000000000000001 x6 :
>>>> 00000000001312d0
>>>>
>>>> [ 1.022748] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>>>> 0000000000000000
>>>>
>>>> [ 1.022756] x2 : ffffffc00cef3b68 x1 : ffffffc00cef3b6c
>>>>
>>>> [ 1.029034] mmcblk0: mmc0:0001 008G30 7.28 GiB
>>>>
>>>> [ 1.034833] x0 : ffffff8000861800
>>>>
>>>> [ 1.034838] Call trace:
>>>>
>>>> [ 1.044528] Alternate GPT is invalid, using primary GPT.
>>>>
>>>> [ 1.047175] regulator_check_voltage+0xb0/0xf0
>>>>
>>>> [ 1.052603] FIT: Selected configuration: "config-1" (OpenWrt
>>>> bananapi_bpi-r64)
>>>>
>>>> [ 1.055090] regulator_set_voltage+0x3c/0x64
>>>>
>>>> [ 1.057539] FIT: kernel sub-image 0x00001000..0x005200f9 "kernel-1"
>>>> (ARM64 OpenWrt Linux-6.1-rc2)
>>>>
>>>> [ 1.062824] mtk_cpufreq_voltage_tracking+0x12c/0x27c
>>>>
>>>> [ 1.062831] mtk_cpufreq_set_target+0x1c4/0x350
>>>>
>>>> [ 1.062837] __cpufreq_driver_target+0x2dc/0x660
>>>>
>>>> [ 1.067289] FIT: flat_dt sub-image 0x00521000..0x005272d9 "fdt-1"
>>>> (ARM64 OpenWrt bananapi_bpi-r64 device tree blob)
>>>>
>>>> [ 1.074484] od_dbs_update+0xb8/0x19c
>>>>
>>>> [ 1.074490] dbs_work_handler+0x3c/0x7c
>>>>
>>>> [ 1.078774] FIT: filesystem sub-image 0x00528000..0x00829fff
>>>> "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs)
>>>>
>>>> [ 1.088560] process_one_work+0x200/0x3a0
>>>>
>>>> [ 1.093624] mmcblk0: p1 p2 p3 p4 p65(rootfs-1) p66(rootfs_data) p128
>>>>
>>>> [ 1.098116] worker_thread+0x170/0x4c0
>>>>
>>>> [ 1.104575] mmcblk0boot0: mmc0:0001 008G30 4.00 MiB
>>>>
>>>> [ 1.114009] kthread+0xd4/0xe0
>>>>
>>>> [ 1.114016] ret_from_fork+0x10/0x20
>>>>
>>>> [ 1.114028] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>>>
>>>> [ 1.114033] ---[ end trace 0000000000000000 ]---
>>>> [ 0.878926] ------------[ cut here ]------------
>>>>
>>>
>>> Full log:
>>> https://gist.github.com/PolynomialDivision/4a555079887b288f4795b28eb3607aa9
>>>
>>> Big thanks to Daniel helping me to build a vanilla kernel with OpenWrt
>>> build system.
>>>
>>> Bests
>>> Nick
>>>
>>> On 11/10/22 12:26, Matthias Brugger wrote:
>>>> Hi Nick,
>>>>
>>>> On 09/11/2022 14:35, Nick wrote:
>>>>> Hi,
>>>>> while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the
>>>>> kernel is crashing while booting on a Banana Pi R64 (MT7622):
>>>>>
>>>>>> [ 1.055565] ------------[ cut here ]------------
>>>>>> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0
>>>>>> [verbose debug info unavailable]
>>>>>> [ 1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000
>>>>>> ranges:
>>>>>> [ 1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>>>>> [ 1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>>>>> [ 1.081257] Modules linked in:
>>>>>> [ 1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G
>>>>>> S 6.1-rc2 #0
>>>>>> [ 1.087088] mtk-pcie 1a143000.pcie: MEM
>>>>>> 0x0020000000..0x0027ffffff -> 0x0020000000
>>>>>> [ 1.090126] Hardware name: Bananapi BPI-R64 (DT)
>>>>>> [ 1.110541] Workqueue: events dbs_work_handler
>>>>>> [ 1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>>>>>> BTYPE=--)
>>>>>> [ 1.121944] pc : regulator_check_voltage+0xb0/0xf0
>>>>>> [ 1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
>>>>>> [ 1.129638] mmc1: host does not support reading read-only switch,
>>>>>> assuming write-enable
>>>>>> [ 1.132207] sp : ffffffc00956bb30
>>>>>> [ 1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27:
>>>>>> 0000000000000024
>>>>>> [ 1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24:
>>>>>> 00000000001312d0
>>>>>> [ 1.132227] x23: 0000000000149970
>>>>>> [ 1.146036] mmc1: new high speed SDHC card at address e624
>>>>>> [ 1.150642] x22: ffffff800038f800
>>>>>> [ 1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB
>>>>>> [ 1.161068] x21: ffffff8000efb100
>>>>>> [ 1.161072] x20: 00000000001312d0
>>>>>> [ 1.175424] GPT:partition_entry_array_crc32 values don't match:
>>>>>> 0xa0b5ce6d != 0xab54d286
>>>>>> [ 1.177757] x19: 0000000000000000 x18: 00000000799b2550
>>>>>> [ 1.181067] GPT:Primary header thinks Alt. header is not at the
>>>>>> end of the disk.
>>>>>> [ 1.189143] x17: 0000000000000003 x16: 0000000000000001 x15:
>>>>>> 0000000000000000
>>>>>> [ 1.189151] x14: 0000000000000000 x13: 0000000000000146 x12:
>>>>>> 00000000fa83b2da
>>>>>> [ 1.189159] x11: 000000000000013d x10: 0000000000000850
>>>>>> [ 1.194472] GPT:305184 != 31116287
>>>>>> [ 1.201842] x9 : ffffffc00956b910
>>>>>> [ 1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
>>>>>> [ 1.208970] GPT:Alternate GPT header not at the end of the disk.
>>>>>> [ 1.216092] x6 : 00000000001312d0
>>>>>> [ 1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>>>>>> 0000000000000000
>>>>>> [ 1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
>>>>>> [ 1.221321] GPT:305184 != 31116287
>>>>>> [ 1.224706] x0 : ffffff800038f800
>>>>>> [ 1.228095] GPT: Use GNU Parted to correct GPT errors.
>>>>>> [ 1.233307]
>>>>>> [ 1.233309] Call trace:
>>>>>> [ 1.233312] regulator_check_voltage+0xb0/0xf0
>>>>>> [ 1.242680] FIT: Selected configuration:
>>>>>> "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64
>>>>>> with mt7622-bananapi-bpi-r64-pcie1)
>>>>>> [ 1.242694] regulator_set_voltage+0x3c/0x64
>>>>>> [ 1.249831] FIT: kernel sub-image
>>>>>> 0x00001000..0x0052fd0a "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2)
>>>>>> [ 1.255030] mtk_cpufreq_voltage_tracking+0x11c/0x26c
>>>>>> [ 1.255039] mtk_cpufreq_set_target+0x1c4/0x350
>>>>>> [ 1.258444] FIT: flat_dt sub-image
>>>>>> 0x00530000..0x005380c5 "fdt-1" (ARM64 OpenWrt bananapi_bpi-r64
>>>>>> device tree blob)
>>>>>> [ 1.261820] __cpufreq_driver_target+0x2f4/0x674
>>>>>> [ 1.261826] od_dbs_update+0xb8/0x19c
>>>>>> [ 1.266969] FIT: flat_dt sub-image
>>>>>> 0x00539000..0x0053911a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64
>>>>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>>>>> mt7622-bananapi-bpi-r64-pcie1)
>>>>>> [ 1.268431] dbs_work_handler+0x3c/0x7c
>>>>>> [ 1.270883] FIT: flat_dt sub-image
>>>>>> 0x0053a000..0x0053a20f "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64
>>>>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>>>>> mt7622-bananapi-bpi-r64-sata)
>>>>>> [ 1.275297] process_one_work+0x200/0x3a0
>>>>>> [ 1.287998] FIT: filesystem sub-image
>>>>>> 0x0053b000..0x00859fff "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64
>>>>>> rootfs)
>>>>>> [ 1.292237] worker_thread+0x170/0x4c0
>>>>>> [ 1.292244] kthread+0xd4/0xe0
>>>>>> [ 1.302066] FIT: selecting configured loadable "rootfs-1" to be
>>>>>> root filesystem
>>>>>> [ 1.307092] ret_from_fork+0x10/0x20
>>>>>> [ 1.311631] mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1)
>>>>>> p66(rootfs_data) p128
>>>>>> [ 1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>>>>> [ 1.413322] ---[ end trace 0000000000000000 ]---
>>>>> The complete log can be found here:
>>>>> https://gist.githubusercontent.com/PolynomialDivision/395d009c84b426d780549c5fa1f64ff1/raw/886d621d2bf6f03429586adf8a14a6c37c8d8a7d/mt7622-6-1.log
>>>>>
>>>>> Reverting commit "cpufreq: mediatek: Refine
>>>>> mtk_cpufreq_voltage_tracking()" fixes the kernel bug:
>>>>> https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
>>>>>
>>>>> The revert commit can be found here:
>>>>> https://github.com/PolynomialDivision/openwrt/commit/1df941d0334000e3aced43b7d50cdac0da8bf427
>>>>>
>>>>> The branch I use to build the 6.1rc2 on a Banana Pi R64 can be found
>>>>> here:
>>>>> https://github.com/PolynomialDivision/openwrt/commits/bump-mt7622-rebase
>>>>>
>>>>
>>>> Thanks for the report.
>>>> Could you test with a plain upstream kernel? That would help us to
>>>> verify that this is a upstream problem and not introduced by some
>>>> openwrt patches.
>>>>
>>>> Regards,
>>>> Matthias
>>
>> #regzbot ignore-activity
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-01 15:39 ` Thorsten Leemhuis
0 siblings, 0 replies; 75+ messages in thread
From: Thorsten Leemhuis @ 2022-12-01 15:39 UTC (permalink / raw)
To: jia-wei.chang, viresh.kumar
Cc: Nick, Matthias Brugger, rex-bc.chen, angelogioacchino.delregno,
Frank Wunderlich, regressions, linux-pm, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, Hühn,
Thomas, Daniel Golle
On 01.12.22 16:26, Daniel Golle wrote:
> On Thu, Dec 01, 2022 at 04:08:50PM +0100, Thorsten Leemhuis wrote:
>> Hi, this is your Linux kernel regression tracker. Top-posting for once,
>> to make this easily accessible to everyone.
>>
>> I noticed this regression didn't make any progress
>>
>> Matthias, is that because Nick didn't exactly do what you asked for (he
>> afaics tried -next, but nevertheless patches it)? Or is there another
>> reason?
>
> I've also tried this on plain linux-next, also using the BPi-R64 and
> can confirm the issue exists also there, without any additional patches
> applied.
>
> Reverting commit 6a17b3876b ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()")
> fixes the issue. Unfortunately, by now it no longer reverts cleanly and
> requires a tiny amount of manual clean-up...
Thx for clarifying. And I noticed I made a mistake: I should have
directed my earlier question wrt to any progress here more into the
direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh Kumar
(who committed it).
Sorry Matthias.
Ciao, Thorsten
>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>
>> P.S.: As the Linux kernel's regression tracker I deal with a lot of
>> reports and sometimes miss something important when writing mails like
>> this. If that's the case here, don't hesitate to tell me in a public
>> reply, it's in everyone's interest to set the public record straight.
>>
>> On 15.11.22 20:44, Nick wrote:
>>> I used now the linux-next kernel tree (with
>>> https://patchwork.ozlabs.org/project/linux-mtd/list/?series=327227 so
>>> single uImage.FIT will work).
>>>
>>> Same issue:
>>>
>>>> [ 0.886209] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose
>>>> debug info unavailable]
>>>>
>>>> [ 0.894663] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>>>
>>>> [ 0.900759] Modules linked in:
>>>>
>>>> [ 0.903819] CPU: 1 PID: 79 Comm: kworker/1:1 Tainted: G S
>>>> 6.1.0-rc5-next-20221115+ #0
>>>>
>>>> [ 0.904360] pstore: Using crash dump compression: deflate
>>>>
>>>> [ 0.913038] Hardware name: Bananapi BPI-R64 (DT)
>>>>
>>>> [ 0.913043] Workqueue: events dbs_work_handler
>>>>
>>>> [ 0.913056] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>>>> BTYPE=--)
>>>>
>>>> [ 0.913063] pc : regulator_check_voltage+0xb0/0xf0
>>>>
>>>> [ 0.913070] lr : regulator_set_voltage_unlocked+0x88/0x110
>>>>
>>>> [ 0.913077] sp : ffffffc00cef3b30
>>>>
>>>> [ 0.913080] x29: ffffffc00cef3b30 x28: ffffff8006f6f800 x27:
>>>> ffffff8006f6fa00
>>>>
>>>> [ 0.931243] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
>>>>
>>>> [ 0.934474]
>>>>
>>>> [ 0.934475] x26: 00000000001312d0 x25: 0000000000000024
>>>>
>>>> [ 0.939298] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>>>
>>>> [ 0.944730] x24: 0000000000118c30
>>>>
>>>> [ 0.948038] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff ->
>>>> 0x0020000000
>>>>
>>>> [ 0.955155]
>>>>
>>>> [ 0.955157] x23: 0000000000149970 x22: ffffff8000861800 x21:
>>>> ffffff8006f6f800
>>>>
>>>> [ 0.955166] x20: 00000000001312d0 x19: 0000000000000000 x18:
>>>> 00000000cfad1bd3
>>>>
>>>> [ 0.955174] x17: 000000000000000c x16: 0000000000000005 x15:
>>>> 0000000000000000
>>>>
>>>> [ 1.008473] x14: 0000000000000000 x13: 0000000000000165 x12:
>>>> 0101010101010101
>>>>
>>>> [ 1.015608] x11: 00000000017d7840 x10: 0000000000000850 x9 :
>>>> ffffffc00cef3900
>>>>
>>>> [ 1.017014] mmc0: new HS200 MMC card at address 0001
>>>>
>>>> [ 1.022740] x8 : ffffff8005ee9f30 x7 : 0000000000000001 x6 :
>>>> 00000000001312d0
>>>>
>>>> [ 1.022748] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>>>> 0000000000000000
>>>>
>>>> [ 1.022756] x2 : ffffffc00cef3b68 x1 : ffffffc00cef3b6c
>>>>
>>>> [ 1.029034] mmcblk0: mmc0:0001 008G30 7.28 GiB
>>>>
>>>> [ 1.034833] x0 : ffffff8000861800
>>>>
>>>> [ 1.034838] Call trace:
>>>>
>>>> [ 1.044528] Alternate GPT is invalid, using primary GPT.
>>>>
>>>> [ 1.047175] regulator_check_voltage+0xb0/0xf0
>>>>
>>>> [ 1.052603] FIT: Selected configuration: "config-1" (OpenWrt
>>>> bananapi_bpi-r64)
>>>>
>>>> [ 1.055090] regulator_set_voltage+0x3c/0x64
>>>>
>>>> [ 1.057539] FIT: kernel sub-image 0x00001000..0x005200f9 "kernel-1"
>>>> (ARM64 OpenWrt Linux-6.1-rc2)
>>>>
>>>> [ 1.062824] mtk_cpufreq_voltage_tracking+0x12c/0x27c
>>>>
>>>> [ 1.062831] mtk_cpufreq_set_target+0x1c4/0x350
>>>>
>>>> [ 1.062837] __cpufreq_driver_target+0x2dc/0x660
>>>>
>>>> [ 1.067289] FIT: flat_dt sub-image 0x00521000..0x005272d9 "fdt-1"
>>>> (ARM64 OpenWrt bananapi_bpi-r64 device tree blob)
>>>>
>>>> [ 1.074484] od_dbs_update+0xb8/0x19c
>>>>
>>>> [ 1.074490] dbs_work_handler+0x3c/0x7c
>>>>
>>>> [ 1.078774] FIT: filesystem sub-image 0x00528000..0x00829fff
>>>> "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs)
>>>>
>>>> [ 1.088560] process_one_work+0x200/0x3a0
>>>>
>>>> [ 1.093624] mmcblk0: p1 p2 p3 p4 p65(rootfs-1) p66(rootfs_data) p128
>>>>
>>>> [ 1.098116] worker_thread+0x170/0x4c0
>>>>
>>>> [ 1.104575] mmcblk0boot0: mmc0:0001 008G30 4.00 MiB
>>>>
>>>> [ 1.114009] kthread+0xd4/0xe0
>>>>
>>>> [ 1.114016] ret_from_fork+0x10/0x20
>>>>
>>>> [ 1.114028] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>>>
>>>> [ 1.114033] ---[ end trace 0000000000000000 ]---
>>>> [ 0.878926] ------------[ cut here ]------------
>>>>
>>>
>>> Full log:
>>> https://gist.github.com/PolynomialDivision/4a555079887b288f4795b28eb3607aa9
>>>
>>> Big thanks to Daniel helping me to build a vanilla kernel with OpenWrt
>>> build system.
>>>
>>> Bests
>>> Nick
>>>
>>> On 11/10/22 12:26, Matthias Brugger wrote:
>>>> Hi Nick,
>>>>
>>>> On 09/11/2022 14:35, Nick wrote:
>>>>> Hi,
>>>>> while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the
>>>>> kernel is crashing while booting on a Banana Pi R64 (MT7622):
>>>>>
>>>>>> [ 1.055565] ------------[ cut here ]------------
>>>>>> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0
>>>>>> [verbose debug info unavailable]
>>>>>> [ 1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000
>>>>>> ranges:
>>>>>> [ 1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>>>>> [ 1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>>>>> [ 1.081257] Modules linked in:
>>>>>> [ 1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G
>>>>>> S 6.1-rc2 #0
>>>>>> [ 1.087088] mtk-pcie 1a143000.pcie: MEM
>>>>>> 0x0020000000..0x0027ffffff -> 0x0020000000
>>>>>> [ 1.090126] Hardware name: Bananapi BPI-R64 (DT)
>>>>>> [ 1.110541] Workqueue: events dbs_work_handler
>>>>>> [ 1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>>>>>> BTYPE=--)
>>>>>> [ 1.121944] pc : regulator_check_voltage+0xb0/0xf0
>>>>>> [ 1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
>>>>>> [ 1.129638] mmc1: host does not support reading read-only switch,
>>>>>> assuming write-enable
>>>>>> [ 1.132207] sp : ffffffc00956bb30
>>>>>> [ 1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27:
>>>>>> 0000000000000024
>>>>>> [ 1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24:
>>>>>> 00000000001312d0
>>>>>> [ 1.132227] x23: 0000000000149970
>>>>>> [ 1.146036] mmc1: new high speed SDHC card at address e624
>>>>>> [ 1.150642] x22: ffffff800038f800
>>>>>> [ 1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB
>>>>>> [ 1.161068] x21: ffffff8000efb100
>>>>>> [ 1.161072] x20: 00000000001312d0
>>>>>> [ 1.175424] GPT:partition_entry_array_crc32 values don't match:
>>>>>> 0xa0b5ce6d != 0xab54d286
>>>>>> [ 1.177757] x19: 0000000000000000 x18: 00000000799b2550
>>>>>> [ 1.181067] GPT:Primary header thinks Alt. header is not at the
>>>>>> end of the disk.
>>>>>> [ 1.189143] x17: 0000000000000003 x16: 0000000000000001 x15:
>>>>>> 0000000000000000
>>>>>> [ 1.189151] x14: 0000000000000000 x13: 0000000000000146 x12:
>>>>>> 00000000fa83b2da
>>>>>> [ 1.189159] x11: 000000000000013d x10: 0000000000000850
>>>>>> [ 1.194472] GPT:305184 != 31116287
>>>>>> [ 1.201842] x9 : ffffffc00956b910
>>>>>> [ 1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
>>>>>> [ 1.208970] GPT:Alternate GPT header not at the end of the disk.
>>>>>> [ 1.216092] x6 : 00000000001312d0
>>>>>> [ 1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>>>>>> 0000000000000000
>>>>>> [ 1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
>>>>>> [ 1.221321] GPT:305184 != 31116287
>>>>>> [ 1.224706] x0 : ffffff800038f800
>>>>>> [ 1.228095] GPT: Use GNU Parted to correct GPT errors.
>>>>>> [ 1.233307]
>>>>>> [ 1.233309] Call trace:
>>>>>> [ 1.233312] regulator_check_voltage+0xb0/0xf0
>>>>>> [ 1.242680] FIT: Selected configuration:
>>>>>> "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64
>>>>>> with mt7622-bananapi-bpi-r64-pcie1)
>>>>>> [ 1.242694] regulator_set_voltage+0x3c/0x64
>>>>>> [ 1.249831] FIT: kernel sub-image
>>>>>> 0x00001000..0x0052fd0a "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2)
>>>>>> [ 1.255030] mtk_cpufreq_voltage_tracking+0x11c/0x26c
>>>>>> [ 1.255039] mtk_cpufreq_set_target+0x1c4/0x350
>>>>>> [ 1.258444] FIT: flat_dt sub-image
>>>>>> 0x00530000..0x005380c5 "fdt-1" (ARM64 OpenWrt bananapi_bpi-r64
>>>>>> device tree blob)
>>>>>> [ 1.261820] __cpufreq_driver_target+0x2f4/0x674
>>>>>> [ 1.261826] od_dbs_update+0xb8/0x19c
>>>>>> [ 1.266969] FIT: flat_dt sub-image
>>>>>> 0x00539000..0x0053911a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64
>>>>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>>>>> mt7622-bananapi-bpi-r64-pcie1)
>>>>>> [ 1.268431] dbs_work_handler+0x3c/0x7c
>>>>>> [ 1.270883] FIT: flat_dt sub-image
>>>>>> 0x0053a000..0x0053a20f "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64
>>>>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>>>>> mt7622-bananapi-bpi-r64-sata)
>>>>>> [ 1.275297] process_one_work+0x200/0x3a0
>>>>>> [ 1.287998] FIT: filesystem sub-image
>>>>>> 0x0053b000..0x00859fff "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64
>>>>>> rootfs)
>>>>>> [ 1.292237] worker_thread+0x170/0x4c0
>>>>>> [ 1.292244] kthread+0xd4/0xe0
>>>>>> [ 1.302066] FIT: selecting configured loadable "rootfs-1" to be
>>>>>> root filesystem
>>>>>> [ 1.307092] ret_from_fork+0x10/0x20
>>>>>> [ 1.311631] mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1)
>>>>>> p66(rootfs_data) p128
>>>>>> [ 1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>>>>> [ 1.413322] ---[ end trace 0000000000000000 ]---
>>>>> The complete log can be found here:
>>>>> https://gist.githubusercontent.com/PolynomialDivision/395d009c84b426d780549c5fa1f64ff1/raw/886d621d2bf6f03429586adf8a14a6c37c8d8a7d/mt7622-6-1.log
>>>>>
>>>>> Reverting commit "cpufreq: mediatek: Refine
>>>>> mtk_cpufreq_voltage_tracking()" fixes the kernel bug:
>>>>> https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
>>>>>
>>>>> The revert commit can be found here:
>>>>> https://github.com/PolynomialDivision/openwrt/commit/1df941d0334000e3aced43b7d50cdac0da8bf427
>>>>>
>>>>> The branch I use to build the 6.1rc2 on a Banana Pi R64 can be found
>>>>> here:
>>>>> https://github.com/PolynomialDivision/openwrt/commits/bump-mt7622-rebase
>>>>>
>>>>
>>>> Thanks for the report.
>>>> Could you test with a plain upstream kernel? That would help us to
>>>> verify that this is a upstream problem and not introduced by some
>>>> openwrt patches.
>>>>
>>>> Regards,
>>>> Matthias
>>
>> #regzbot ignore-activity
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-12-01 15:39 ` Thorsten Leemhuis
(?)
@ 2022-12-01 21:40 ` Nick
-1 siblings, 0 replies; 75+ messages in thread
From: Nick @ 2022-12-01 21:40 UTC (permalink / raw)
To: Thorsten Leemhuis, jia-wei.chang, viresh.kumar
Cc: Matthias Brugger, rex-bc.chen, angelogioacchino.delregno,
Frank Wunderlich, regressions, linux-pm, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, Hühn,
Thomas, Daniel Golle
When I revert the "cpufreq-commit" and add some debug information to the
"regulator_check_voltage" function "rdev_err(rdev,"min:%d
max:%d",*min_uV,*max_uV);" it looks like this:
> [ 0.969537] vcore1: min:1150000 max:1160000
> [ 0.974922] vm: min:1150000 max:1150000
> [ 0.986928] vcore1: min:1100000 max:1110000
> [ 0.999054] vcore1: min:1200000 max:1210000
> [ 1.003809] vcore1: min:1150000 max:1160000
> [ 1.020147] vcore1: min:1200000 max:1210000
> [ 1.024794] vcore1: min:1050000 max:1060000
> [ 1.050438] vcore1: min:1200000 max:1210000
> [ 1.069050] vcore1: min:1250000 max:1260000
> [ 1.166036] vcore1: min:1310000 max:1320000
> [ 1.167463] vcore1: min:1050000 max:1060000
> [ 1.209071] vcore1: min:1200000 max:1210000
> [ 1.213883] vcore1: min:1000000 max:1010000
> [ 1.223359] vm: min:1100000 max:1110000
Without the revert it crashes with those values:
> [ 0.939804] vcore1: min:1250000 max:1150000
More information:
https://forum.banana-pi.org/t/banana-pi-r64-trying-to-bump-openwrt-kernel-to-6-1/14189/5
Bests
Nick
On 12/1/22 16:39, Thorsten Leemhuis wrote:
>
> On 01.12.22 16:26, Daniel Golle wrote:
>> On Thu, Dec 01, 2022 at 04:08:50PM +0100, Thorsten Leemhuis wrote:
>>> Hi, this is your Linux kernel regression tracker. Top-posting for once,
>>> to make this easily accessible to everyone.
>>>
>>> I noticed this regression didn't make any progress
>>>
>>> Matthias, is that because Nick didn't exactly do what you asked for (he
>>> afaics tried -next, but nevertheless patches it)? Or is there another
>>> reason?
>> I've also tried this on plain linux-next, also using the BPi-R64 and
>> can confirm the issue exists also there, without any additional patches
>> applied.
>>
>> Reverting commit 6a17b3876b ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()")
>> fixes the issue. Unfortunately, by now it no longer reverts cleanly and
>> requires a tiny amount of manual clean-up...
> Thx for clarifying. And I noticed I made a mistake: I should have
> directed my earlier question wrt to any progress here more into the
> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh Kumar
> (who committed it).
>
> Sorry Matthias.
>
> Ciao, Thorsten
>
>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>>
>>> P.S.: As the Linux kernel's regression tracker I deal with a lot of
>>> reports and sometimes miss something important when writing mails like
>>> this. If that's the case here, don't hesitate to tell me in a public
>>> reply, it's in everyone's interest to set the public record straight.
>>>
>>> On 15.11.22 20:44, Nick wrote:
>>>> I used now the linux-next kernel tree (with
>>>> https://patchwork.ozlabs.org/project/linux-mtd/list/?series=327227 so
>>>> single uImage.FIT will work).
>>>>
>>>> Same issue:
>>>>
>>>>> [ 0.886209] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose
>>>>> debug info unavailable]
>>>>>
>>>>> [ 0.894663] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>>>>
>>>>> [ 0.900759] Modules linked in:
>>>>>
>>>>> [ 0.903819] CPU: 1 PID: 79 Comm: kworker/1:1 Tainted: G S
>>>>> 6.1.0-rc5-next-20221115+ #0
>>>>>
>>>>> [ 0.904360] pstore: Using crash dump compression: deflate
>>>>>
>>>>> [ 0.913038] Hardware name: Bananapi BPI-R64 (DT)
>>>>>
>>>>> [ 0.913043] Workqueue: events dbs_work_handler
>>>>>
>>>>> [ 0.913056] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>>>>> BTYPE=--)
>>>>>
>>>>> [ 0.913063] pc : regulator_check_voltage+0xb0/0xf0
>>>>>
>>>>> [ 0.913070] lr : regulator_set_voltage_unlocked+0x88/0x110
>>>>>
>>>>> [ 0.913077] sp : ffffffc00cef3b30
>>>>>
>>>>> [ 0.913080] x29: ffffffc00cef3b30 x28: ffffff8006f6f800 x27:
>>>>> ffffff8006f6fa00
>>>>>
>>>>> [ 0.931243] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
>>>>>
>>>>> [ 0.934474]
>>>>>
>>>>> [ 0.934475] x26: 00000000001312d0 x25: 0000000000000024
>>>>>
>>>>> [ 0.939298] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>>>>
>>>>> [ 0.944730] x24: 0000000000118c30
>>>>>
>>>>> [ 0.948038] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff ->
>>>>> 0x0020000000
>>>>>
>>>>> [ 0.955155]
>>>>>
>>>>> [ 0.955157] x23: 0000000000149970 x22: ffffff8000861800 x21:
>>>>> ffffff8006f6f800
>>>>>
>>>>> [ 0.955166] x20: 00000000001312d0 x19: 0000000000000000 x18:
>>>>> 00000000cfad1bd3
>>>>>
>>>>> [ 0.955174] x17: 000000000000000c x16: 0000000000000005 x15:
>>>>> 0000000000000000
>>>>>
>>>>> [ 1.008473] x14: 0000000000000000 x13: 0000000000000165 x12:
>>>>> 0101010101010101
>>>>>
>>>>> [ 1.015608] x11: 00000000017d7840 x10: 0000000000000850 x9 :
>>>>> ffffffc00cef3900
>>>>>
>>>>> [ 1.017014] mmc0: new HS200 MMC card at address 0001
>>>>>
>>>>> [ 1.022740] x8 : ffffff8005ee9f30 x7 : 0000000000000001 x6 :
>>>>> 00000000001312d0
>>>>>
>>>>> [ 1.022748] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>>>>> 0000000000000000
>>>>>
>>>>> [ 1.022756] x2 : ffffffc00cef3b68 x1 : ffffffc00cef3b6c
>>>>>
>>>>> [ 1.029034] mmcblk0: mmc0:0001 008G30 7.28 GiB
>>>>>
>>>>> [ 1.034833] x0 : ffffff8000861800
>>>>>
>>>>> [ 1.034838] Call trace:
>>>>>
>>>>> [ 1.044528] Alternate GPT is invalid, using primary GPT.
>>>>>
>>>>> [ 1.047175] regulator_check_voltage+0xb0/0xf0
>>>>>
>>>>> [ 1.052603] FIT: Selected configuration: "config-1" (OpenWrt
>>>>> bananapi_bpi-r64)
>>>>>
>>>>> [ 1.055090] regulator_set_voltage+0x3c/0x64
>>>>>
>>>>> [ 1.057539] FIT: kernel sub-image 0x00001000..0x005200f9 "kernel-1"
>>>>> (ARM64 OpenWrt Linux-6.1-rc2)
>>>>>
>>>>> [ 1.062824] mtk_cpufreq_voltage_tracking+0x12c/0x27c
>>>>>
>>>>> [ 1.062831] mtk_cpufreq_set_target+0x1c4/0x350
>>>>>
>>>>> [ 1.062837] __cpufreq_driver_target+0x2dc/0x660
>>>>>
>>>>> [ 1.067289] FIT: flat_dt sub-image 0x00521000..0x005272d9 "fdt-1"
>>>>> (ARM64 OpenWrt bananapi_bpi-r64 device tree blob)
>>>>>
>>>>> [ 1.074484] od_dbs_update+0xb8/0x19c
>>>>>
>>>>> [ 1.074490] dbs_work_handler+0x3c/0x7c
>>>>>
>>>>> [ 1.078774] FIT: filesystem sub-image 0x00528000..0x00829fff
>>>>> "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs)
>>>>>
>>>>> [ 1.088560] process_one_work+0x200/0x3a0
>>>>>
>>>>> [ 1.093624] mmcblk0: p1 p2 p3 p4 p65(rootfs-1) p66(rootfs_data) p128
>>>>>
>>>>> [ 1.098116] worker_thread+0x170/0x4c0
>>>>>
>>>>> [ 1.104575] mmcblk0boot0: mmc0:0001 008G30 4.00 MiB
>>>>>
>>>>> [ 1.114009] kthread+0xd4/0xe0
>>>>>
>>>>> [ 1.114016] ret_from_fork+0x10/0x20
>>>>>
>>>>> [ 1.114028] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>>>>
>>>>> [ 1.114033] ---[ end trace 0000000000000000 ]---
>>>>> [ 0.878926] ------------[ cut here ]------------
>>>>>
>>>> Full log:
>>>> https://gist.github.com/PolynomialDivision/4a555079887b288f4795b28eb3607aa9
>>>>
>>>> Big thanks to Daniel helping me to build a vanilla kernel with OpenWrt
>>>> build system.
>>>>
>>>> Bests
>>>> Nick
>>>>
>>>> On 11/10/22 12:26, Matthias Brugger wrote:
>>>>> Hi Nick,
>>>>>
>>>>> On 09/11/2022 14:35, Nick wrote:
>>>>>> Hi,
>>>>>> while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the
>>>>>> kernel is crashing while booting on a Banana Pi R64 (MT7622):
>>>>>>
>>>>>>> [ 1.055565] ------------[ cut here ]------------
>>>>>>> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0
>>>>>>> [verbose debug info unavailable]
>>>>>>> [ 1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000
>>>>>>> ranges:
>>>>>>> [ 1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>>>>>> [ 1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>>>>>> [ 1.081257] Modules linked in:
>>>>>>> [ 1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G
>>>>>>> S 6.1-rc2 #0
>>>>>>> [ 1.087088] mtk-pcie 1a143000.pcie: MEM
>>>>>>> 0x0020000000..0x0027ffffff -> 0x0020000000
>>>>>>> [ 1.090126] Hardware name: Bananapi BPI-R64 (DT)
>>>>>>> [ 1.110541] Workqueue: events dbs_work_handler
>>>>>>> [ 1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>>>>>>> BTYPE=--)
>>>>>>> [ 1.121944] pc : regulator_check_voltage+0xb0/0xf0
>>>>>>> [ 1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
>>>>>>> [ 1.129638] mmc1: host does not support reading read-only switch,
>>>>>>> assuming write-enable
>>>>>>> [ 1.132207] sp : ffffffc00956bb30
>>>>>>> [ 1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27:
>>>>>>> 0000000000000024
>>>>>>> [ 1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24:
>>>>>>> 00000000001312d0
>>>>>>> [ 1.132227] x23: 0000000000149970
>>>>>>> [ 1.146036] mmc1: new high speed SDHC card at address e624
>>>>>>> [ 1.150642] x22: ffffff800038f800
>>>>>>> [ 1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB
>>>>>>> [ 1.161068] x21: ffffff8000efb100
>>>>>>> [ 1.161072] x20: 00000000001312d0
>>>>>>> [ 1.175424] GPT:partition_entry_array_crc32 values don't match:
>>>>>>> 0xa0b5ce6d != 0xab54d286
>>>>>>> [ 1.177757] x19: 0000000000000000 x18: 00000000799b2550
>>>>>>> [ 1.181067] GPT:Primary header thinks Alt. header is not at the
>>>>>>> end of the disk.
>>>>>>> [ 1.189143] x17: 0000000000000003 x16: 0000000000000001 x15:
>>>>>>> 0000000000000000
>>>>>>> [ 1.189151] x14: 0000000000000000 x13: 0000000000000146 x12:
>>>>>>> 00000000fa83b2da
>>>>>>> [ 1.189159] x11: 000000000000013d x10: 0000000000000850
>>>>>>> [ 1.194472] GPT:305184 != 31116287
>>>>>>> [ 1.201842] x9 : ffffffc00956b910
>>>>>>> [ 1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
>>>>>>> [ 1.208970] GPT:Alternate GPT header not at the end of the disk.
>>>>>>> [ 1.216092] x6 : 00000000001312d0
>>>>>>> [ 1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>>>>>>> 0000000000000000
>>>>>>> [ 1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
>>>>>>> [ 1.221321] GPT:305184 != 31116287
>>>>>>> [ 1.224706] x0 : ffffff800038f800
>>>>>>> [ 1.228095] GPT: Use GNU Parted to correct GPT errors.
>>>>>>> [ 1.233307]
>>>>>>> [ 1.233309] Call trace:
>>>>>>> [ 1.233312] regulator_check_voltage+0xb0/0xf0
>>>>>>> [ 1.242680] FIT: Selected configuration:
>>>>>>> "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64
>>>>>>> with mt7622-bananapi-bpi-r64-pcie1)
>>>>>>> [ 1.242694] regulator_set_voltage+0x3c/0x64
>>>>>>> [ 1.249831] FIT: kernel sub-image
>>>>>>> 0x00001000..0x0052fd0a "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2)
>>>>>>> [ 1.255030] mtk_cpufreq_voltage_tracking+0x11c/0x26c
>>>>>>> [ 1.255039] mtk_cpufreq_set_target+0x1c4/0x350
>>>>>>> [ 1.258444] FIT: flat_dt sub-image
>>>>>>> 0x00530000..0x005380c5 "fdt-1" (ARM64 OpenWrt bananapi_bpi-r64
>>>>>>> device tree blob)
>>>>>>> [ 1.261820] __cpufreq_driver_target+0x2f4/0x674
>>>>>>> [ 1.261826] od_dbs_update+0xb8/0x19c
>>>>>>> [ 1.266969] FIT: flat_dt sub-image
>>>>>>> 0x00539000..0x0053911a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64
>>>>>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>>>>>> mt7622-bananapi-bpi-r64-pcie1)
>>>>>>> [ 1.268431] dbs_work_handler+0x3c/0x7c
>>>>>>> [ 1.270883] FIT: flat_dt sub-image
>>>>>>> 0x0053a000..0x0053a20f "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64
>>>>>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>>>>>> mt7622-bananapi-bpi-r64-sata)
>>>>>>> [ 1.275297] process_one_work+0x200/0x3a0
>>>>>>> [ 1.287998] FIT: filesystem sub-image
>>>>>>> 0x0053b000..0x00859fff "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64
>>>>>>> rootfs)
>>>>>>> [ 1.292237] worker_thread+0x170/0x4c0
>>>>>>> [ 1.292244] kthread+0xd4/0xe0
>>>>>>> [ 1.302066] FIT: selecting configured loadable "rootfs-1" to be
>>>>>>> root filesystem
>>>>>>> [ 1.307092] ret_from_fork+0x10/0x20
>>>>>>> [ 1.311631] mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1)
>>>>>>> p66(rootfs_data) p128
>>>>>>> [ 1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>>>>>> [ 1.413322] ---[ end trace 0000000000000000 ]---
>>>>>> The complete log can be found here:
>>>>>> https://gist.githubusercontent.com/PolynomialDivision/395d009c84b426d780549c5fa1f64ff1/raw/886d621d2bf6f03429586adf8a14a6c37c8d8a7d/mt7622-6-1.log
>>>>>>
>>>>>> Reverting commit "cpufreq: mediatek: Refine
>>>>>> mtk_cpufreq_voltage_tracking()" fixes the kernel bug:
>>>>>> https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
>>>>>>
>>>>>> The revert commit can be found here:
>>>>>> https://github.com/PolynomialDivision/openwrt/commit/1df941d0334000e3aced43b7d50cdac0da8bf427
>>>>>>
>>>>>> The branch I use to build the 6.1rc2 on a Banana Pi R64 can be found
>>>>>> here:
>>>>>> https://github.com/PolynomialDivision/openwrt/commits/bump-mt7622-rebase
>>>>>>
>>>>> Thanks for the report.
>>>>> Could you test with a plain upstream kernel? That would help us to
>>>>> verify that this is a upstream problem and not introduced by some
>>>>> openwrt patches.
>>>>>
>>>>> Regards,
>>>>> Matthias
>>> #regzbot ignore-activity
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-01 21:40 ` Nick
0 siblings, 0 replies; 75+ messages in thread
From: Nick @ 2022-12-01 21:40 UTC (permalink / raw)
To: Thorsten Leemhuis, jia-wei.chang, viresh.kumar
Cc: regressions, linux-pm, Daniel Golle,
Project_Global_Chrome_Upstream_Group, rex-bc.chen,
linux-mediatek, Matthias Brugger, Hühn, Thomas,
linux-arm-kernel, angelogioacchino.delregno
When I revert the "cpufreq-commit" and add some debug information to the
"regulator_check_voltage" function "rdev_err(rdev,"min:%d
max:%d",*min_uV,*max_uV);" it looks like this:
> [ 0.969537] vcore1: min:1150000 max:1160000
> [ 0.974922] vm: min:1150000 max:1150000
> [ 0.986928] vcore1: min:1100000 max:1110000
> [ 0.999054] vcore1: min:1200000 max:1210000
> [ 1.003809] vcore1: min:1150000 max:1160000
> [ 1.020147] vcore1: min:1200000 max:1210000
> [ 1.024794] vcore1: min:1050000 max:1060000
> [ 1.050438] vcore1: min:1200000 max:1210000
> [ 1.069050] vcore1: min:1250000 max:1260000
> [ 1.166036] vcore1: min:1310000 max:1320000
> [ 1.167463] vcore1: min:1050000 max:1060000
> [ 1.209071] vcore1: min:1200000 max:1210000
> [ 1.213883] vcore1: min:1000000 max:1010000
> [ 1.223359] vm: min:1100000 max:1110000
Without the revert it crashes with those values:
> [ 0.939804] vcore1: min:1250000 max:1150000
More information:
https://forum.banana-pi.org/t/banana-pi-r64-trying-to-bump-openwrt-kernel-to-6-1/14189/5
Bests
Nick
On 12/1/22 16:39, Thorsten Leemhuis wrote:
>
> On 01.12.22 16:26, Daniel Golle wrote:
>> On Thu, Dec 01, 2022 at 04:08:50PM +0100, Thorsten Leemhuis wrote:
>>> Hi, this is your Linux kernel regression tracker. Top-posting for once,
>>> to make this easily accessible to everyone.
>>>
>>> I noticed this regression didn't make any progress
>>>
>>> Matthias, is that because Nick didn't exactly do what you asked for (he
>>> afaics tried -next, but nevertheless patches it)? Or is there another
>>> reason?
>> I've also tried this on plain linux-next, also using the BPi-R64 and
>> can confirm the issue exists also there, without any additional patches
>> applied.
>>
>> Reverting commit 6a17b3876b ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()")
>> fixes the issue. Unfortunately, by now it no longer reverts cleanly and
>> requires a tiny amount of manual clean-up...
> Thx for clarifying. And I noticed I made a mistake: I should have
> directed my earlier question wrt to any progress here more into the
> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh Kumar
> (who committed it).
>
> Sorry Matthias.
>
> Ciao, Thorsten
>
>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>>
>>> P.S.: As the Linux kernel's regression tracker I deal with a lot of
>>> reports and sometimes miss something important when writing mails like
>>> this. If that's the case here, don't hesitate to tell me in a public
>>> reply, it's in everyone's interest to set the public record straight.
>>>
>>> On 15.11.22 20:44, Nick wrote:
>>>> I used now the linux-next kernel tree (with
>>>> https://patchwork.ozlabs.org/project/linux-mtd/list/?series=327227 so
>>>> single uImage.FIT will work).
>>>>
>>>> Same issue:
>>>>
>>>>> [ 0.886209] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose
>>>>> debug info unavailable]
>>>>>
>>>>> [ 0.894663] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>>>>
>>>>> [ 0.900759] Modules linked in:
>>>>>
>>>>> [ 0.903819] CPU: 1 PID: 79 Comm: kworker/1:1 Tainted: G S
>>>>> 6.1.0-rc5-next-20221115+ #0
>>>>>
>>>>> [ 0.904360] pstore: Using crash dump compression: deflate
>>>>>
>>>>> [ 0.913038] Hardware name: Bananapi BPI-R64 (DT)
>>>>>
>>>>> [ 0.913043] Workqueue: events dbs_work_handler
>>>>>
>>>>> [ 0.913056] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>>>>> BTYPE=--)
>>>>>
>>>>> [ 0.913063] pc : regulator_check_voltage+0xb0/0xf0
>>>>>
>>>>> [ 0.913070] lr : regulator_set_voltage_unlocked+0x88/0x110
>>>>>
>>>>> [ 0.913077] sp : ffffffc00cef3b30
>>>>>
>>>>> [ 0.913080] x29: ffffffc00cef3b30 x28: ffffff8006f6f800 x27:
>>>>> ffffff8006f6fa00
>>>>>
>>>>> [ 0.931243] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
>>>>>
>>>>> [ 0.934474]
>>>>>
>>>>> [ 0.934475] x26: 00000000001312d0 x25: 0000000000000024
>>>>>
>>>>> [ 0.939298] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>>>>
>>>>> [ 0.944730] x24: 0000000000118c30
>>>>>
>>>>> [ 0.948038] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff ->
>>>>> 0x0020000000
>>>>>
>>>>> [ 0.955155]
>>>>>
>>>>> [ 0.955157] x23: 0000000000149970 x22: ffffff8000861800 x21:
>>>>> ffffff8006f6f800
>>>>>
>>>>> [ 0.955166] x20: 00000000001312d0 x19: 0000000000000000 x18:
>>>>> 00000000cfad1bd3
>>>>>
>>>>> [ 0.955174] x17: 000000000000000c x16: 0000000000000005 x15:
>>>>> 0000000000000000
>>>>>
>>>>> [ 1.008473] x14: 0000000000000000 x13: 0000000000000165 x12:
>>>>> 0101010101010101
>>>>>
>>>>> [ 1.015608] x11: 00000000017d7840 x10: 0000000000000850 x9 :
>>>>> ffffffc00cef3900
>>>>>
>>>>> [ 1.017014] mmc0: new HS200 MMC card at address 0001
>>>>>
>>>>> [ 1.022740] x8 : ffffff8005ee9f30 x7 : 0000000000000001 x6 :
>>>>> 00000000001312d0
>>>>>
>>>>> [ 1.022748] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>>>>> 0000000000000000
>>>>>
>>>>> [ 1.022756] x2 : ffffffc00cef3b68 x1 : ffffffc00cef3b6c
>>>>>
>>>>> [ 1.029034] mmcblk0: mmc0:0001 008G30 7.28 GiB
>>>>>
>>>>> [ 1.034833] x0 : ffffff8000861800
>>>>>
>>>>> [ 1.034838] Call trace:
>>>>>
>>>>> [ 1.044528] Alternate GPT is invalid, using primary GPT.
>>>>>
>>>>> [ 1.047175] regulator_check_voltage+0xb0/0xf0
>>>>>
>>>>> [ 1.052603] FIT: Selected configuration: "config-1" (OpenWrt
>>>>> bananapi_bpi-r64)
>>>>>
>>>>> [ 1.055090] regulator_set_voltage+0x3c/0x64
>>>>>
>>>>> [ 1.057539] FIT: kernel sub-image 0x00001000..0x005200f9 "kernel-1"
>>>>> (ARM64 OpenWrt Linux-6.1-rc2)
>>>>>
>>>>> [ 1.062824] mtk_cpufreq_voltage_tracking+0x12c/0x27c
>>>>>
>>>>> [ 1.062831] mtk_cpufreq_set_target+0x1c4/0x350
>>>>>
>>>>> [ 1.062837] __cpufreq_driver_target+0x2dc/0x660
>>>>>
>>>>> [ 1.067289] FIT: flat_dt sub-image 0x00521000..0x005272d9 "fdt-1"
>>>>> (ARM64 OpenWrt bananapi_bpi-r64 device tree blob)
>>>>>
>>>>> [ 1.074484] od_dbs_update+0xb8/0x19c
>>>>>
>>>>> [ 1.074490] dbs_work_handler+0x3c/0x7c
>>>>>
>>>>> [ 1.078774] FIT: filesystem sub-image 0x00528000..0x00829fff
>>>>> "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs)
>>>>>
>>>>> [ 1.088560] process_one_work+0x200/0x3a0
>>>>>
>>>>> [ 1.093624] mmcblk0: p1 p2 p3 p4 p65(rootfs-1) p66(rootfs_data) p128
>>>>>
>>>>> [ 1.098116] worker_thread+0x170/0x4c0
>>>>>
>>>>> [ 1.104575] mmcblk0boot0: mmc0:0001 008G30 4.00 MiB
>>>>>
>>>>> [ 1.114009] kthread+0xd4/0xe0
>>>>>
>>>>> [ 1.114016] ret_from_fork+0x10/0x20
>>>>>
>>>>> [ 1.114028] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>>>>
>>>>> [ 1.114033] ---[ end trace 0000000000000000 ]---
>>>>> [ 0.878926] ------------[ cut here ]------------
>>>>>
>>>> Full log:
>>>> https://gist.github.com/PolynomialDivision/4a555079887b288f4795b28eb3607aa9
>>>>
>>>> Big thanks to Daniel helping me to build a vanilla kernel with OpenWrt
>>>> build system.
>>>>
>>>> Bests
>>>> Nick
>>>>
>>>> On 11/10/22 12:26, Matthias Brugger wrote:
>>>>> Hi Nick,
>>>>>
>>>>> On 09/11/2022 14:35, Nick wrote:
>>>>>> Hi,
>>>>>> while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the
>>>>>> kernel is crashing while booting on a Banana Pi R64 (MT7622):
>>>>>>
>>>>>>> [ 1.055565] ------------[ cut here ]------------
>>>>>>> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0
>>>>>>> [verbose debug info unavailable]
>>>>>>> [ 1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000
>>>>>>> ranges:
>>>>>>> [ 1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>>>>>> [ 1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>>>>>> [ 1.081257] Modules linked in:
>>>>>>> [ 1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G
>>>>>>> S 6.1-rc2 #0
>>>>>>> [ 1.087088] mtk-pcie 1a143000.pcie: MEM
>>>>>>> 0x0020000000..0x0027ffffff -> 0x0020000000
>>>>>>> [ 1.090126] Hardware name: Bananapi BPI-R64 (DT)
>>>>>>> [ 1.110541] Workqueue: events dbs_work_handler
>>>>>>> [ 1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>>>>>>> BTYPE=--)
>>>>>>> [ 1.121944] pc : regulator_check_voltage+0xb0/0xf0
>>>>>>> [ 1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
>>>>>>> [ 1.129638] mmc1: host does not support reading read-only switch,
>>>>>>> assuming write-enable
>>>>>>> [ 1.132207] sp : ffffffc00956bb30
>>>>>>> [ 1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27:
>>>>>>> 0000000000000024
>>>>>>> [ 1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24:
>>>>>>> 00000000001312d0
>>>>>>> [ 1.132227] x23: 0000000000149970
>>>>>>> [ 1.146036] mmc1: new high speed SDHC card at address e624
>>>>>>> [ 1.150642] x22: ffffff800038f800
>>>>>>> [ 1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB
>>>>>>> [ 1.161068] x21: ffffff8000efb100
>>>>>>> [ 1.161072] x20: 00000000001312d0
>>>>>>> [ 1.175424] GPT:partition_entry_array_crc32 values don't match:
>>>>>>> 0xa0b5ce6d != 0xab54d286
>>>>>>> [ 1.177757] x19: 0000000000000000 x18: 00000000799b2550
>>>>>>> [ 1.181067] GPT:Primary header thinks Alt. header is not at the
>>>>>>> end of the disk.
>>>>>>> [ 1.189143] x17: 0000000000000003 x16: 0000000000000001 x15:
>>>>>>> 0000000000000000
>>>>>>> [ 1.189151] x14: 0000000000000000 x13: 0000000000000146 x12:
>>>>>>> 00000000fa83b2da
>>>>>>> [ 1.189159] x11: 000000000000013d x10: 0000000000000850
>>>>>>> [ 1.194472] GPT:305184 != 31116287
>>>>>>> [ 1.201842] x9 : ffffffc00956b910
>>>>>>> [ 1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
>>>>>>> [ 1.208970] GPT:Alternate GPT header not at the end of the disk.
>>>>>>> [ 1.216092] x6 : 00000000001312d0
>>>>>>> [ 1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>>>>>>> 0000000000000000
>>>>>>> [ 1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
>>>>>>> [ 1.221321] GPT:305184 != 31116287
>>>>>>> [ 1.224706] x0 : ffffff800038f800
>>>>>>> [ 1.228095] GPT: Use GNU Parted to correct GPT errors.
>>>>>>> [ 1.233307]
>>>>>>> [ 1.233309] Call trace:
>>>>>>> [ 1.233312] regulator_check_voltage+0xb0/0xf0
>>>>>>> [ 1.242680] FIT: Selected configuration:
>>>>>>> "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64
>>>>>>> with mt7622-bananapi-bpi-r64-pcie1)
>>>>>>> [ 1.242694] regulator_set_voltage+0x3c/0x64
>>>>>>> [ 1.249831] FIT: kernel sub-image
>>>>>>> 0x00001000..0x0052fd0a "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2)
>>>>>>> [ 1.255030] mtk_cpufreq_voltage_tracking+0x11c/0x26c
>>>>>>> [ 1.255039] mtk_cpufreq_set_target+0x1c4/0x350
>>>>>>> [ 1.258444] FIT: flat_dt sub-image
>>>>>>> 0x00530000..0x005380c5 "fdt-1" (ARM64 OpenWrt bananapi_bpi-r64
>>>>>>> device tree blob)
>>>>>>> [ 1.261820] __cpufreq_driver_target+0x2f4/0x674
>>>>>>> [ 1.261826] od_dbs_update+0xb8/0x19c
>>>>>>> [ 1.266969] FIT: flat_dt sub-image
>>>>>>> 0x00539000..0x0053911a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64
>>>>>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>>>>>> mt7622-bananapi-bpi-r64-pcie1)
>>>>>>> [ 1.268431] dbs_work_handler+0x3c/0x7c
>>>>>>> [ 1.270883] FIT: flat_dt sub-image
>>>>>>> 0x0053a000..0x0053a20f "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64
>>>>>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>>>>>> mt7622-bananapi-bpi-r64-sata)
>>>>>>> [ 1.275297] process_one_work+0x200/0x3a0
>>>>>>> [ 1.287998] FIT: filesystem sub-image
>>>>>>> 0x0053b000..0x00859fff "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64
>>>>>>> rootfs)
>>>>>>> [ 1.292237] worker_thread+0x170/0x4c0
>>>>>>> [ 1.292244] kthread+0xd4/0xe0
>>>>>>> [ 1.302066] FIT: selecting configured loadable "rootfs-1" to be
>>>>>>> root filesystem
>>>>>>> [ 1.307092] ret_from_fork+0x10/0x20
>>>>>>> [ 1.311631] mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1)
>>>>>>> p66(rootfs_data) p128
>>>>>>> [ 1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>>>>>> [ 1.413322] ---[ end trace 0000000000000000 ]---
>>>>>> The complete log can be found here:
>>>>>> https://gist.githubusercontent.com/PolynomialDivision/395d009c84b426d780549c5fa1f64ff1/raw/886d621d2bf6f03429586adf8a14a6c37c8d8a7d/mt7622-6-1.log
>>>>>>
>>>>>> Reverting commit "cpufreq: mediatek: Refine
>>>>>> mtk_cpufreq_voltage_tracking()" fixes the kernel bug:
>>>>>> https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
>>>>>>
>>>>>> The revert commit can be found here:
>>>>>> https://github.com/PolynomialDivision/openwrt/commit/1df941d0334000e3aced43b7d50cdac0da8bf427
>>>>>>
>>>>>> The branch I use to build the 6.1rc2 on a Banana Pi R64 can be found
>>>>>> here:
>>>>>> https://github.com/PolynomialDivision/openwrt/commits/bump-mt7622-rebase
>>>>>>
>>>>> Thanks for the report.
>>>>> Could you test with a plain upstream kernel? That would help us to
>>>>> verify that this is a upstream problem and not introduced by some
>>>>> openwrt patches.
>>>>>
>>>>> Regards,
>>>>> Matthias
>>> #regzbot ignore-activity
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-01 21:40 ` Nick
0 siblings, 0 replies; 75+ messages in thread
From: Nick @ 2022-12-01 21:40 UTC (permalink / raw)
To: Thorsten Leemhuis, jia-wei.chang, viresh.kumar
Cc: Matthias Brugger, rex-bc.chen, angelogioacchino.delregno,
Frank Wunderlich, regressions, linux-pm, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, Hühn,
Thomas, Daniel Golle
When I revert the "cpufreq-commit" and add some debug information to the
"regulator_check_voltage" function "rdev_err(rdev,"min:%d
max:%d",*min_uV,*max_uV);" it looks like this:
> [ 0.969537] vcore1: min:1150000 max:1160000
> [ 0.974922] vm: min:1150000 max:1150000
> [ 0.986928] vcore1: min:1100000 max:1110000
> [ 0.999054] vcore1: min:1200000 max:1210000
> [ 1.003809] vcore1: min:1150000 max:1160000
> [ 1.020147] vcore1: min:1200000 max:1210000
> [ 1.024794] vcore1: min:1050000 max:1060000
> [ 1.050438] vcore1: min:1200000 max:1210000
> [ 1.069050] vcore1: min:1250000 max:1260000
> [ 1.166036] vcore1: min:1310000 max:1320000
> [ 1.167463] vcore1: min:1050000 max:1060000
> [ 1.209071] vcore1: min:1200000 max:1210000
> [ 1.213883] vcore1: min:1000000 max:1010000
> [ 1.223359] vm: min:1100000 max:1110000
Without the revert it crashes with those values:
> [ 0.939804] vcore1: min:1250000 max:1150000
More information:
https://forum.banana-pi.org/t/banana-pi-r64-trying-to-bump-openwrt-kernel-to-6-1/14189/5
Bests
Nick
On 12/1/22 16:39, Thorsten Leemhuis wrote:
>
> On 01.12.22 16:26, Daniel Golle wrote:
>> On Thu, Dec 01, 2022 at 04:08:50PM +0100, Thorsten Leemhuis wrote:
>>> Hi, this is your Linux kernel regression tracker. Top-posting for once,
>>> to make this easily accessible to everyone.
>>>
>>> I noticed this regression didn't make any progress
>>>
>>> Matthias, is that because Nick didn't exactly do what you asked for (he
>>> afaics tried -next, but nevertheless patches it)? Or is there another
>>> reason?
>> I've also tried this on plain linux-next, also using the BPi-R64 and
>> can confirm the issue exists also there, without any additional patches
>> applied.
>>
>> Reverting commit 6a17b3876b ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()")
>> fixes the issue. Unfortunately, by now it no longer reverts cleanly and
>> requires a tiny amount of manual clean-up...
> Thx for clarifying. And I noticed I made a mistake: I should have
> directed my earlier question wrt to any progress here more into the
> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh Kumar
> (who committed it).
>
> Sorry Matthias.
>
> Ciao, Thorsten
>
>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>>
>>> P.S.: As the Linux kernel's regression tracker I deal with a lot of
>>> reports and sometimes miss something important when writing mails like
>>> this. If that's the case here, don't hesitate to tell me in a public
>>> reply, it's in everyone's interest to set the public record straight.
>>>
>>> On 15.11.22 20:44, Nick wrote:
>>>> I used now the linux-next kernel tree (with
>>>> https://patchwork.ozlabs.org/project/linux-mtd/list/?series=327227 so
>>>> single uImage.FIT will work).
>>>>
>>>> Same issue:
>>>>
>>>>> [ 0.886209] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose
>>>>> debug info unavailable]
>>>>>
>>>>> [ 0.894663] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>>>>
>>>>> [ 0.900759] Modules linked in:
>>>>>
>>>>> [ 0.903819] CPU: 1 PID: 79 Comm: kworker/1:1 Tainted: G S
>>>>> 6.1.0-rc5-next-20221115+ #0
>>>>>
>>>>> [ 0.904360] pstore: Using crash dump compression: deflate
>>>>>
>>>>> [ 0.913038] Hardware name: Bananapi BPI-R64 (DT)
>>>>>
>>>>> [ 0.913043] Workqueue: events dbs_work_handler
>>>>>
>>>>> [ 0.913056] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>>>>> BTYPE=--)
>>>>>
>>>>> [ 0.913063] pc : regulator_check_voltage+0xb0/0xf0
>>>>>
>>>>> [ 0.913070] lr : regulator_set_voltage_unlocked+0x88/0x110
>>>>>
>>>>> [ 0.913077] sp : ffffffc00cef3b30
>>>>>
>>>>> [ 0.913080] x29: ffffffc00cef3b30 x28: ffffff8006f6f800 x27:
>>>>> ffffff8006f6fa00
>>>>>
>>>>> [ 0.931243] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
>>>>>
>>>>> [ 0.934474]
>>>>>
>>>>> [ 0.934475] x26: 00000000001312d0 x25: 0000000000000024
>>>>>
>>>>> [ 0.939298] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>>>>
>>>>> [ 0.944730] x24: 0000000000118c30
>>>>>
>>>>> [ 0.948038] mtk-pcie 1a143000.pcie: MEM 0x0020000000..0x0027ffffff ->
>>>>> 0x0020000000
>>>>>
>>>>> [ 0.955155]
>>>>>
>>>>> [ 0.955157] x23: 0000000000149970 x22: ffffff8000861800 x21:
>>>>> ffffff8006f6f800
>>>>>
>>>>> [ 0.955166] x20: 00000000001312d0 x19: 0000000000000000 x18:
>>>>> 00000000cfad1bd3
>>>>>
>>>>> [ 0.955174] x17: 000000000000000c x16: 0000000000000005 x15:
>>>>> 0000000000000000
>>>>>
>>>>> [ 1.008473] x14: 0000000000000000 x13: 0000000000000165 x12:
>>>>> 0101010101010101
>>>>>
>>>>> [ 1.015608] x11: 00000000017d7840 x10: 0000000000000850 x9 :
>>>>> ffffffc00cef3900
>>>>>
>>>>> [ 1.017014] mmc0: new HS200 MMC card at address 0001
>>>>>
>>>>> [ 1.022740] x8 : ffffff8005ee9f30 x7 : 0000000000000001 x6 :
>>>>> 00000000001312d0
>>>>>
>>>>> [ 1.022748] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>>>>> 0000000000000000
>>>>>
>>>>> [ 1.022756] x2 : ffffffc00cef3b68 x1 : ffffffc00cef3b6c
>>>>>
>>>>> [ 1.029034] mmcblk0: mmc0:0001 008G30 7.28 GiB
>>>>>
>>>>> [ 1.034833] x0 : ffffff8000861800
>>>>>
>>>>> [ 1.034838] Call trace:
>>>>>
>>>>> [ 1.044528] Alternate GPT is invalid, using primary GPT.
>>>>>
>>>>> [ 1.047175] regulator_check_voltage+0xb0/0xf0
>>>>>
>>>>> [ 1.052603] FIT: Selected configuration: "config-1" (OpenWrt
>>>>> bananapi_bpi-r64)
>>>>>
>>>>> [ 1.055090] regulator_set_voltage+0x3c/0x64
>>>>>
>>>>> [ 1.057539] FIT: kernel sub-image 0x00001000..0x005200f9 "kernel-1"
>>>>> (ARM64 OpenWrt Linux-6.1-rc2)
>>>>>
>>>>> [ 1.062824] mtk_cpufreq_voltage_tracking+0x12c/0x27c
>>>>>
>>>>> [ 1.062831] mtk_cpufreq_set_target+0x1c4/0x350
>>>>>
>>>>> [ 1.062837] __cpufreq_driver_target+0x2dc/0x660
>>>>>
>>>>> [ 1.067289] FIT: flat_dt sub-image 0x00521000..0x005272d9 "fdt-1"
>>>>> (ARM64 OpenWrt bananapi_bpi-r64 device tree blob)
>>>>>
>>>>> [ 1.074484] od_dbs_update+0xb8/0x19c
>>>>>
>>>>> [ 1.074490] dbs_work_handler+0x3c/0x7c
>>>>>
>>>>> [ 1.078774] FIT: filesystem sub-image 0x00528000..0x00829fff
>>>>> "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs)
>>>>>
>>>>> [ 1.088560] process_one_work+0x200/0x3a0
>>>>>
>>>>> [ 1.093624] mmcblk0: p1 p2 p3 p4 p65(rootfs-1) p66(rootfs_data) p128
>>>>>
>>>>> [ 1.098116] worker_thread+0x170/0x4c0
>>>>>
>>>>> [ 1.104575] mmcblk0boot0: mmc0:0001 008G30 4.00 MiB
>>>>>
>>>>> [ 1.114009] kthread+0xd4/0xe0
>>>>>
>>>>> [ 1.114016] ret_from_fork+0x10/0x20
>>>>>
>>>>> [ 1.114028] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>>>>
>>>>> [ 1.114033] ---[ end trace 0000000000000000 ]---
>>>>> [ 0.878926] ------------[ cut here ]------------
>>>>>
>>>> Full log:
>>>> https://gist.github.com/PolynomialDivision/4a555079887b288f4795b28eb3607aa9
>>>>
>>>> Big thanks to Daniel helping me to build a vanilla kernel with OpenWrt
>>>> build system.
>>>>
>>>> Bests
>>>> Nick
>>>>
>>>> On 11/10/22 12:26, Matthias Brugger wrote:
>>>>> Hi Nick,
>>>>>
>>>>> On 09/11/2022 14:35, Nick wrote:
>>>>>> Hi,
>>>>>> while trying to bump OpenWrt Kernel to 6.1rc2 I noticed that the
>>>>>> kernel is crashing while booting on a Banana Pi R64 (MT7622):
>>>>>>
>>>>>>> [ 1.055565] ------------[ cut here ]------------
>>>>>>> [ 1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0
>>>>>>> [verbose debug info unavailable]
>>>>>>> [ 1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000
>>>>>>> ranges:
>>>>>>> [ 1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
>>>>>>> [ 1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
>>>>>>> [ 1.081257] Modules linked in:
>>>>>>> [ 1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G
>>>>>>> S 6.1-rc2 #0
>>>>>>> [ 1.087088] mtk-pcie 1a143000.pcie: MEM
>>>>>>> 0x0020000000..0x0027ffffff -> 0x0020000000
>>>>>>> [ 1.090126] Hardware name: Bananapi BPI-R64 (DT)
>>>>>>> [ 1.110541] Workqueue: events dbs_work_handler
>>>>>>> [ 1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
>>>>>>> BTYPE=--)
>>>>>>> [ 1.121944] pc : regulator_check_voltage+0xb0/0xf0
>>>>>>> [ 1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
>>>>>>> [ 1.129638] mmc1: host does not support reading read-only switch,
>>>>>>> assuming write-enable
>>>>>>> [ 1.132207] sp : ffffffc00956bb30
>>>>>>> [ 1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27:
>>>>>>> 0000000000000024
>>>>>>> [ 1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24:
>>>>>>> 00000000001312d0
>>>>>>> [ 1.132227] x23: 0000000000149970
>>>>>>> [ 1.146036] mmc1: new high speed SDHC card at address e624
>>>>>>> [ 1.150642] x22: ffffff800038f800
>>>>>>> [ 1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB
>>>>>>> [ 1.161068] x21: ffffff8000efb100
>>>>>>> [ 1.161072] x20: 00000000001312d0
>>>>>>> [ 1.175424] GPT:partition_entry_array_crc32 values don't match:
>>>>>>> 0xa0b5ce6d != 0xab54d286
>>>>>>> [ 1.177757] x19: 0000000000000000 x18: 00000000799b2550
>>>>>>> [ 1.181067] GPT:Primary header thinks Alt. header is not at the
>>>>>>> end of the disk.
>>>>>>> [ 1.189143] x17: 0000000000000003 x16: 0000000000000001 x15:
>>>>>>> 0000000000000000
>>>>>>> [ 1.189151] x14: 0000000000000000 x13: 0000000000000146 x12:
>>>>>>> 00000000fa83b2da
>>>>>>> [ 1.189159] x11: 000000000000013d x10: 0000000000000850
>>>>>>> [ 1.194472] GPT:305184 != 31116287
>>>>>>> [ 1.201842] x9 : ffffffc00956b910
>>>>>>> [ 1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
>>>>>>> [ 1.208970] GPT:Alternate GPT header not at the end of the disk.
>>>>>>> [ 1.216092] x6 : 00000000001312d0
>>>>>>> [ 1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 :
>>>>>>> 0000000000000000
>>>>>>> [ 1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
>>>>>>> [ 1.221321] GPT:305184 != 31116287
>>>>>>> [ 1.224706] x0 : ffffff800038f800
>>>>>>> [ 1.228095] GPT: Use GNU Parted to correct GPT errors.
>>>>>>> [ 1.233307]
>>>>>>> [ 1.233309] Call trace:
>>>>>>> [ 1.233312] regulator_check_voltage+0xb0/0xf0
>>>>>>> [ 1.242680] FIT: Selected configuration:
>>>>>>> "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64
>>>>>>> with mt7622-bananapi-bpi-r64-pcie1)
>>>>>>> [ 1.242694] regulator_set_voltage+0x3c/0x64
>>>>>>> [ 1.249831] FIT: kernel sub-image
>>>>>>> 0x00001000..0x0052fd0a "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2)
>>>>>>> [ 1.255030] mtk_cpufreq_voltage_tracking+0x11c/0x26c
>>>>>>> [ 1.255039] mtk_cpufreq_set_target+0x1c4/0x350
>>>>>>> [ 1.258444] FIT: flat_dt sub-image
>>>>>>> 0x00530000..0x005380c5 "fdt-1" (ARM64 OpenWrt bananapi_bpi-r64
>>>>>>> device tree blob)
>>>>>>> [ 1.261820] __cpufreq_driver_target+0x2f4/0x674
>>>>>>> [ 1.261826] od_dbs_update+0xb8/0x19c
>>>>>>> [ 1.266969] FIT: flat_dt sub-image
>>>>>>> 0x00539000..0x0053911a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64
>>>>>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>>>>>> mt7622-bananapi-bpi-r64-pcie1)
>>>>>>> [ 1.268431] dbs_work_handler+0x3c/0x7c
>>>>>>> [ 1.270883] FIT: flat_dt sub-image
>>>>>>> 0x0053a000..0x0053a20f "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64
>>>>>>> OpenWrt bananapi_bpi-r64 device tree overlay
>>>>>>> mt7622-bananapi-bpi-r64-sata)
>>>>>>> [ 1.275297] process_one_work+0x200/0x3a0
>>>>>>> [ 1.287998] FIT: filesystem sub-image
>>>>>>> 0x0053b000..0x00859fff "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64
>>>>>>> rootfs)
>>>>>>> [ 1.292237] worker_thread+0x170/0x4c0
>>>>>>> [ 1.292244] kthread+0xd4/0xe0
>>>>>>> [ 1.302066] FIT: selecting configured loadable "rootfs-1" to be
>>>>>>> root filesystem
>>>>>>> [ 1.307092] ret_from_fork+0x10/0x20
>>>>>>> [ 1.311631] mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1)
>>>>>>> p66(rootfs_data) p128
>>>>>>> [ 1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000)
>>>>>>> [ 1.413322] ---[ end trace 0000000000000000 ]---
>>>>>> The complete log can be found here:
>>>>>> https://gist.githubusercontent.com/PolynomialDivision/395d009c84b426d780549c5fa1f64ff1/raw/886d621d2bf6f03429586adf8a14a6c37c8d8a7d/mt7622-6-1.log
>>>>>>
>>>>>> Reverting commit "cpufreq: mediatek: Refine
>>>>>> mtk_cpufreq_voltage_tracking()" fixes the kernel bug:
>>>>>> https://github.com/torvalds/linux/commit/6a17b3876bc8303612d7ad59ecf7cbc0db418bcd
>>>>>>
>>>>>> The revert commit can be found here:
>>>>>> https://github.com/PolynomialDivision/openwrt/commit/1df941d0334000e3aced43b7d50cdac0da8bf427
>>>>>>
>>>>>> The branch I use to build the 6.1rc2 on a Banana Pi R64 can be found
>>>>>> here:
>>>>>> https://github.com/PolynomialDivision/openwrt/commits/bump-mt7622-rebase
>>>>>>
>>>>> Thanks for the report.
>>>>> Could you test with a plain upstream kernel? That would help us to
>>>>> verify that this is a upstream problem and not introduced by some
>>>>> openwrt patches.
>>>>>
>>>>> Regards,
>>>>> Matthias
>>> #regzbot ignore-activity
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH] Revert "cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()"
2022-11-09 13:35 ` Nick
@ 2022-12-02 5:26 ` Viresh Kumar
-1 siblings, 0 replies; 75+ messages in thread
From: Viresh Kumar @ 2022-12-02 5:26 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Matthias Brugger
Cc: linux-pm, Vincent Guittot, regressions, daniel, thomas.huehn,
v5 . 19+,
Nick, linux-kernel, linux-arm-kernel, linux-mediatek
This reverts commit 6a17b3876bc8303612d7ad59ecf7cbc0db418bcd.
This commit caused regression on Banana Pi R64 (MT7622), revert until
the problem is identified and fixed properly.
Link: https://lore.kernel.org/all/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
Cc: v5.19+ <stable@vger.kernel.org> # v5.19+
Reported-by: Nick <vincent@systemli.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/cpufreq/mediatek-cpufreq.c | 147 +++++++++++++++++++----------
1 file changed, 96 insertions(+), 51 deletions(-)
diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
index 7f2680bc9a0f..4466d0c91a6a 100644
--- a/drivers/cpufreq/mediatek-cpufreq.c
+++ b/drivers/cpufreq/mediatek-cpufreq.c
@@ -8,7 +8,6 @@
#include <linux/cpu.h>
#include <linux/cpufreq.h>
#include <linux/cpumask.h>
-#include <linux/minmax.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_platform.h>
@@ -16,6 +15,8 @@
#include <linux/pm_opp.h>
#include <linux/regulator/consumer.h>
+#define VOLT_TOL (10000)
+
struct mtk_cpufreq_platform_data {
int min_volt_shift;
int max_volt_shift;
@@ -55,7 +56,6 @@ struct mtk_cpu_dvfs_info {
unsigned int opp_cpu;
unsigned long current_freq;
const struct mtk_cpufreq_platform_data *soc_data;
- int vtrack_max;
bool ccifreq_bound;
};
@@ -82,7 +82,6 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
struct regulator *proc_reg = info->proc_reg;
struct regulator *sram_reg = info->sram_reg;
int pre_vproc, pre_vsram, new_vsram, vsram, vproc, ret;
- int retry = info->vtrack_max;
pre_vproc = regulator_get_voltage(proc_reg);
if (pre_vproc < 0) {
@@ -90,44 +89,91 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
"invalid Vproc value: %d\n", pre_vproc);
return pre_vproc;
}
+ /* Vsram should not exceed the maximum allowed voltage of SoC. */
+ new_vsram = min(new_vproc + soc_data->min_volt_shift,
+ soc_data->sram_max_volt);
+
+ if (pre_vproc < new_vproc) {
+ /*
+ * When scaling up voltages, Vsram and Vproc scale up step
+ * by step. At each step, set Vsram to (Vproc + 200mV) first,
+ * then set Vproc to (Vsram - 100mV).
+ * Keep doing it until Vsram and Vproc hit target voltages.
+ */
+ do {
+ pre_vsram = regulator_get_voltage(sram_reg);
+ if (pre_vsram < 0) {
+ dev_err(info->cpu_dev,
+ "invalid Vsram value: %d\n", pre_vsram);
+ return pre_vsram;
+ }
+ pre_vproc = regulator_get_voltage(proc_reg);
+ if (pre_vproc < 0) {
+ dev_err(info->cpu_dev,
+ "invalid Vproc value: %d\n", pre_vproc);
+ return pre_vproc;
+ }
- pre_vsram = regulator_get_voltage(sram_reg);
- if (pre_vsram < 0) {
- dev_err(info->cpu_dev, "invalid Vsram value: %d\n", pre_vsram);
- return pre_vsram;
- }
+ vsram = min(new_vsram,
+ pre_vproc + soc_data->min_volt_shift);
- new_vsram = clamp(new_vproc + soc_data->min_volt_shift,
- soc_data->sram_min_volt, soc_data->sram_max_volt);
+ if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
+ vsram = soc_data->sram_max_volt;
- do {
- if (pre_vproc <= new_vproc) {
- vsram = clamp(pre_vproc + soc_data->max_volt_shift,
- soc_data->sram_min_volt, new_vsram);
- ret = regulator_set_voltage(sram_reg, vsram,
- soc_data->sram_max_volt);
+ /*
+ * If the target Vsram hits the maximum voltage,
+ * try to set the exact voltage value first.
+ */
+ ret = regulator_set_voltage(sram_reg, vsram,
+ vsram);
+ if (ret)
+ ret = regulator_set_voltage(sram_reg,
+ vsram - VOLT_TOL,
+ vsram);
- if (ret)
- return ret;
-
- if (vsram == soc_data->sram_max_volt ||
- new_vsram == soc_data->sram_min_volt)
vproc = new_vproc;
- else
+ } else {
+ ret = regulator_set_voltage(sram_reg, vsram,
+ vsram + VOLT_TOL);
+
vproc = vsram - soc_data->min_volt_shift;
+ }
+ if (ret)
+ return ret;
ret = regulator_set_voltage(proc_reg, vproc,
- soc_data->proc_max_volt);
+ vproc + VOLT_TOL);
if (ret) {
regulator_set_voltage(sram_reg, pre_vsram,
- soc_data->sram_max_volt);
+ pre_vsram);
return ret;
}
- } else if (pre_vproc > new_vproc) {
+ } while (vproc < new_vproc || vsram < new_vsram);
+ } else if (pre_vproc > new_vproc) {
+ /*
+ * When scaling down voltages, Vsram and Vproc scale down step
+ * by step. At each step, set Vproc to (Vsram - 200mV) first,
+ * then set Vproc to (Vproc + 100mV).
+ * Keep doing it until Vsram and Vproc hit target voltages.
+ */
+ do {
+ pre_vproc = regulator_get_voltage(proc_reg);
+ if (pre_vproc < 0) {
+ dev_err(info->cpu_dev,
+ "invalid Vproc value: %d\n", pre_vproc);
+ return pre_vproc;
+ }
+ pre_vsram = regulator_get_voltage(sram_reg);
+ if (pre_vsram < 0) {
+ dev_err(info->cpu_dev,
+ "invalid Vsram value: %d\n", pre_vsram);
+ return pre_vsram;
+ }
+
vproc = max(new_vproc,
pre_vsram - soc_data->max_volt_shift);
ret = regulator_set_voltage(proc_reg, vproc,
- soc_data->proc_max_volt);
+ vproc + VOLT_TOL);
if (ret)
return ret;
@@ -137,24 +183,32 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
vsram = max(new_vsram,
vproc + soc_data->min_volt_shift);
- ret = regulator_set_voltage(sram_reg, vsram,
- soc_data->sram_max_volt);
+ if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
+ vsram = soc_data->sram_max_volt;
+
+ /*
+ * If the target Vsram hits the maximum voltage,
+ * try to set the exact voltage value first.
+ */
+ ret = regulator_set_voltage(sram_reg, vsram,
+ vsram);
+ if (ret)
+ ret = regulator_set_voltage(sram_reg,
+ vsram - VOLT_TOL,
+ vsram);
+ } else {
+ ret = regulator_set_voltage(sram_reg, vsram,
+ vsram + VOLT_TOL);
+ }
+
if (ret) {
regulator_set_voltage(proc_reg, pre_vproc,
- soc_data->proc_max_volt);
+ pre_vproc);
return ret;
}
- }
-
- pre_vproc = vproc;
- pre_vsram = vsram;
-
- if (--retry < 0) {
- dev_err(info->cpu_dev,
- "over loop count, failed to set voltage\n");
- return -EINVAL;
- }
- } while (vproc != new_vproc || vsram != new_vsram);
+ } while (vproc > new_vproc + VOLT_TOL ||
+ vsram > new_vsram + VOLT_TOL);
+ }
return 0;
}
@@ -250,8 +304,8 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
* If the new voltage or the intermediate voltage is higher than the
* current voltage, scale up voltage first.
*/
- target_vproc = max(inter_vproc, vproc);
- if (pre_vproc <= target_vproc) {
+ target_vproc = (inter_vproc > vproc) ? inter_vproc : vproc;
+ if (pre_vproc < target_vproc) {
ret = mtk_cpufreq_set_voltage(info, target_vproc);
if (ret) {
dev_err(cpu_dev,
@@ -513,15 +567,6 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
*/
info->need_voltage_tracking = (info->sram_reg != NULL);
- /*
- * We assume min voltage is 0 and tracking target voltage using
- * min_volt_shift for each iteration.
- * The vtrack_max is 3 times of expeted iteration count.
- */
- info->vtrack_max = 3 * DIV_ROUND_UP(max(info->soc_data->sram_max_volt,
- info->soc_data->proc_max_volt),
- info->soc_data->min_volt_shift);
-
return 0;
out_disable_inter_clock:
--
2.31.1.272.g89b43f80a514
^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH] Revert "cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()"
@ 2022-12-02 5:26 ` Viresh Kumar
0 siblings, 0 replies; 75+ messages in thread
From: Viresh Kumar @ 2022-12-02 5:26 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Matthias Brugger
Cc: linux-pm, Vincent Guittot, regressions, daniel, thomas.huehn,
v5 . 19+,
Nick, linux-kernel, linux-arm-kernel, linux-mediatek
This reverts commit 6a17b3876bc8303612d7ad59ecf7cbc0db418bcd.
This commit caused regression on Banana Pi R64 (MT7622), revert until
the problem is identified and fixed properly.
Link: https://lore.kernel.org/all/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
Cc: v5.19+ <stable@vger.kernel.org> # v5.19+
Reported-by: Nick <vincent@systemli.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/cpufreq/mediatek-cpufreq.c | 147 +++++++++++++++++++----------
1 file changed, 96 insertions(+), 51 deletions(-)
diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
index 7f2680bc9a0f..4466d0c91a6a 100644
--- a/drivers/cpufreq/mediatek-cpufreq.c
+++ b/drivers/cpufreq/mediatek-cpufreq.c
@@ -8,7 +8,6 @@
#include <linux/cpu.h>
#include <linux/cpufreq.h>
#include <linux/cpumask.h>
-#include <linux/minmax.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_platform.h>
@@ -16,6 +15,8 @@
#include <linux/pm_opp.h>
#include <linux/regulator/consumer.h>
+#define VOLT_TOL (10000)
+
struct mtk_cpufreq_platform_data {
int min_volt_shift;
int max_volt_shift;
@@ -55,7 +56,6 @@ struct mtk_cpu_dvfs_info {
unsigned int opp_cpu;
unsigned long current_freq;
const struct mtk_cpufreq_platform_data *soc_data;
- int vtrack_max;
bool ccifreq_bound;
};
@@ -82,7 +82,6 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
struct regulator *proc_reg = info->proc_reg;
struct regulator *sram_reg = info->sram_reg;
int pre_vproc, pre_vsram, new_vsram, vsram, vproc, ret;
- int retry = info->vtrack_max;
pre_vproc = regulator_get_voltage(proc_reg);
if (pre_vproc < 0) {
@@ -90,44 +89,91 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
"invalid Vproc value: %d\n", pre_vproc);
return pre_vproc;
}
+ /* Vsram should not exceed the maximum allowed voltage of SoC. */
+ new_vsram = min(new_vproc + soc_data->min_volt_shift,
+ soc_data->sram_max_volt);
+
+ if (pre_vproc < new_vproc) {
+ /*
+ * When scaling up voltages, Vsram and Vproc scale up step
+ * by step. At each step, set Vsram to (Vproc + 200mV) first,
+ * then set Vproc to (Vsram - 100mV).
+ * Keep doing it until Vsram and Vproc hit target voltages.
+ */
+ do {
+ pre_vsram = regulator_get_voltage(sram_reg);
+ if (pre_vsram < 0) {
+ dev_err(info->cpu_dev,
+ "invalid Vsram value: %d\n", pre_vsram);
+ return pre_vsram;
+ }
+ pre_vproc = regulator_get_voltage(proc_reg);
+ if (pre_vproc < 0) {
+ dev_err(info->cpu_dev,
+ "invalid Vproc value: %d\n", pre_vproc);
+ return pre_vproc;
+ }
- pre_vsram = regulator_get_voltage(sram_reg);
- if (pre_vsram < 0) {
- dev_err(info->cpu_dev, "invalid Vsram value: %d\n", pre_vsram);
- return pre_vsram;
- }
+ vsram = min(new_vsram,
+ pre_vproc + soc_data->min_volt_shift);
- new_vsram = clamp(new_vproc + soc_data->min_volt_shift,
- soc_data->sram_min_volt, soc_data->sram_max_volt);
+ if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
+ vsram = soc_data->sram_max_volt;
- do {
- if (pre_vproc <= new_vproc) {
- vsram = clamp(pre_vproc + soc_data->max_volt_shift,
- soc_data->sram_min_volt, new_vsram);
- ret = regulator_set_voltage(sram_reg, vsram,
- soc_data->sram_max_volt);
+ /*
+ * If the target Vsram hits the maximum voltage,
+ * try to set the exact voltage value first.
+ */
+ ret = regulator_set_voltage(sram_reg, vsram,
+ vsram);
+ if (ret)
+ ret = regulator_set_voltage(sram_reg,
+ vsram - VOLT_TOL,
+ vsram);
- if (ret)
- return ret;
-
- if (vsram == soc_data->sram_max_volt ||
- new_vsram == soc_data->sram_min_volt)
vproc = new_vproc;
- else
+ } else {
+ ret = regulator_set_voltage(sram_reg, vsram,
+ vsram + VOLT_TOL);
+
vproc = vsram - soc_data->min_volt_shift;
+ }
+ if (ret)
+ return ret;
ret = regulator_set_voltage(proc_reg, vproc,
- soc_data->proc_max_volt);
+ vproc + VOLT_TOL);
if (ret) {
regulator_set_voltage(sram_reg, pre_vsram,
- soc_data->sram_max_volt);
+ pre_vsram);
return ret;
}
- } else if (pre_vproc > new_vproc) {
+ } while (vproc < new_vproc || vsram < new_vsram);
+ } else if (pre_vproc > new_vproc) {
+ /*
+ * When scaling down voltages, Vsram and Vproc scale down step
+ * by step. At each step, set Vproc to (Vsram - 200mV) first,
+ * then set Vproc to (Vproc + 100mV).
+ * Keep doing it until Vsram and Vproc hit target voltages.
+ */
+ do {
+ pre_vproc = regulator_get_voltage(proc_reg);
+ if (pre_vproc < 0) {
+ dev_err(info->cpu_dev,
+ "invalid Vproc value: %d\n", pre_vproc);
+ return pre_vproc;
+ }
+ pre_vsram = regulator_get_voltage(sram_reg);
+ if (pre_vsram < 0) {
+ dev_err(info->cpu_dev,
+ "invalid Vsram value: %d\n", pre_vsram);
+ return pre_vsram;
+ }
+
vproc = max(new_vproc,
pre_vsram - soc_data->max_volt_shift);
ret = regulator_set_voltage(proc_reg, vproc,
- soc_data->proc_max_volt);
+ vproc + VOLT_TOL);
if (ret)
return ret;
@@ -137,24 +183,32 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
vsram = max(new_vsram,
vproc + soc_data->min_volt_shift);
- ret = regulator_set_voltage(sram_reg, vsram,
- soc_data->sram_max_volt);
+ if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
+ vsram = soc_data->sram_max_volt;
+
+ /*
+ * If the target Vsram hits the maximum voltage,
+ * try to set the exact voltage value first.
+ */
+ ret = regulator_set_voltage(sram_reg, vsram,
+ vsram);
+ if (ret)
+ ret = regulator_set_voltage(sram_reg,
+ vsram - VOLT_TOL,
+ vsram);
+ } else {
+ ret = regulator_set_voltage(sram_reg, vsram,
+ vsram + VOLT_TOL);
+ }
+
if (ret) {
regulator_set_voltage(proc_reg, pre_vproc,
- soc_data->proc_max_volt);
+ pre_vproc);
return ret;
}
- }
-
- pre_vproc = vproc;
- pre_vsram = vsram;
-
- if (--retry < 0) {
- dev_err(info->cpu_dev,
- "over loop count, failed to set voltage\n");
- return -EINVAL;
- }
- } while (vproc != new_vproc || vsram != new_vsram);
+ } while (vproc > new_vproc + VOLT_TOL ||
+ vsram > new_vsram + VOLT_TOL);
+ }
return 0;
}
@@ -250,8 +304,8 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
* If the new voltage or the intermediate voltage is higher than the
* current voltage, scale up voltage first.
*/
- target_vproc = max(inter_vproc, vproc);
- if (pre_vproc <= target_vproc) {
+ target_vproc = (inter_vproc > vproc) ? inter_vproc : vproc;
+ if (pre_vproc < target_vproc) {
ret = mtk_cpufreq_set_voltage(info, target_vproc);
if (ret) {
dev_err(cpu_dev,
@@ -513,15 +567,6 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
*/
info->need_voltage_tracking = (info->sram_reg != NULL);
- /*
- * We assume min voltage is 0 and tracking target voltage using
- * min_volt_shift for each iteration.
- * The vtrack_max is 3 times of expeted iteration count.
- */
- info->vtrack_max = 3 * DIV_ROUND_UP(max(info->soc_data->sram_max_volt,
- info->soc_data->proc_max_volt),
- info->soc_data->min_volt_shift);
-
return 0;
out_disable_inter_clock:
--
2.31.1.272.g89b43f80a514
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-12-01 15:39 ` Thorsten Leemhuis
(?)
@ 2022-12-02 5:27 ` Viresh Kumar
-1 siblings, 0 replies; 75+ messages in thread
From: Viresh Kumar @ 2022-12-02 5:27 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: jia-wei.chang, Nick, Matthias Brugger, rex-bc.chen,
angelogioacchino.delregno, Frank Wunderlich, regressions,
linux-pm, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, Hühn, Thomas,
Daniel Golle
On 01-12-22, 16:39, Thorsten Leemhuis wrote:
> Thx for clarifying. And I noticed I made a mistake: I should have
> directed my earlier question wrt to any progress here more into the
> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh Kumar
> (who committed it).
I was waiting for the platform maintainers to come up with a fix. I
have sent a patch now to revert this, in-reply-to this thread.
Please confirm this is working fine. Thanks.
--
viresh
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 5:27 ` Viresh Kumar
0 siblings, 0 replies; 75+ messages in thread
From: Viresh Kumar @ 2022-12-02 5:27 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Project_Global_Chrome_Upstream_Group, Nick, linux-pm,
Daniel Golle, regressions, rex-bc.chen, linux-mediatek,
Matthias Brugger, Hühn, Thomas, jia-wei.chang,
linux-arm-kernel, angelogioacchino.delregno
On 01-12-22, 16:39, Thorsten Leemhuis wrote:
> Thx for clarifying. And I noticed I made a mistake: I should have
> directed my earlier question wrt to any progress here more into the
> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh Kumar
> (who committed it).
I was waiting for the platform maintainers to come up with a fix. I
have sent a patch now to revert this, in-reply-to this thread.
Please confirm this is working fine. Thanks.
--
viresh
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 5:27 ` Viresh Kumar
0 siblings, 0 replies; 75+ messages in thread
From: Viresh Kumar @ 2022-12-02 5:27 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: jia-wei.chang, Nick, Matthias Brugger, rex-bc.chen,
angelogioacchino.delregno, Frank Wunderlich, regressions,
linux-pm, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, Hühn, Thomas,
Daniel Golle
On 01-12-22, 16:39, Thorsten Leemhuis wrote:
> Thx for clarifying. And I noticed I made a mistake: I should have
> directed my earlier question wrt to any progress here more into the
> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh Kumar
> (who committed it).
I was waiting for the platform maintainers to come up with a fix. I
have sent a patch now to revert this, in-reply-to this thread.
Please confirm this is working fine. Thanks.
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-12-02 5:27 ` Viresh Kumar
(?)
@ 2022-12-02 8:57 ` AngeloGioacchino Del Regno
-1 siblings, 0 replies; 75+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-12-02 8:57 UTC (permalink / raw)
To: Viresh Kumar, Thorsten Leemhuis
Cc: jia-wei.chang, Nick, Matthias Brugger, rex-bc.chen,
Frank Wunderlich, regressions, linux-pm, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, Hühn,
Thomas, Daniel Golle
Il 02/12/22 06:27, Viresh Kumar ha scritto:
> On 01-12-22, 16:39, Thorsten Leemhuis wrote:
>> Thx for clarifying. And I noticed I made a mistake: I should have
>> directed my earlier question wrt to any progress here more into the
>> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh Kumar
>> (who committed it).
>
> I was waiting for the platform maintainers to come up with a fix. I
> have sent a patch now to revert this, in-reply-to this thread.
>
> Please confirm this is working fine. Thanks.
>
Can you guys try this patch that I've sent a while ago?
https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
There were comments on it, but if that solves your issue I can push a v2
to solve what was reported.
Regards,
Angelo
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 8:57 ` AngeloGioacchino Del Regno
0 siblings, 0 replies; 75+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-12-02 8:57 UTC (permalink / raw)
To: Viresh Kumar, Thorsten Leemhuis
Cc: regressions, linux-pm, Daniel Golle,
Project_Global_Chrome_Upstream_Group, rex-bc.chen,
linux-mediatek, Matthias Brugger, Hühn, Thomas,
jia-wei.chang, linux-arm-kernel, Nick
Il 02/12/22 06:27, Viresh Kumar ha scritto:
> On 01-12-22, 16:39, Thorsten Leemhuis wrote:
>> Thx for clarifying. And I noticed I made a mistake: I should have
>> directed my earlier question wrt to any progress here more into the
>> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh Kumar
>> (who committed it).
>
> I was waiting for the platform maintainers to come up with a fix. I
> have sent a patch now to revert this, in-reply-to this thread.
>
> Please confirm this is working fine. Thanks.
>
Can you guys try this patch that I've sent a while ago?
https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
There were comments on it, but if that solves your issue I can push a v2
to solve what was reported.
Regards,
Angelo
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 8:57 ` AngeloGioacchino Del Regno
0 siblings, 0 replies; 75+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-12-02 8:57 UTC (permalink / raw)
To: Viresh Kumar, Thorsten Leemhuis
Cc: jia-wei.chang, Nick, Matthias Brugger, rex-bc.chen,
Frank Wunderlich, regressions, linux-pm, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, Hühn,
Thomas, Daniel Golle
Il 02/12/22 06:27, Viresh Kumar ha scritto:
> On 01-12-22, 16:39, Thorsten Leemhuis wrote:
>> Thx for clarifying. And I noticed I made a mistake: I should have
>> directed my earlier question wrt to any progress here more into the
>> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh Kumar
>> (who committed it).
>
> I was waiting for the platform maintainers to come up with a fix. I
> have sent a patch now to revert this, in-reply-to this thread.
>
> Please confirm this is working fine. Thanks.
>
Can you guys try this patch that I've sent a while ago?
https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
There were comments on it, but if that solves your issue I can push a v2
to solve what was reported.
Regards,
Angelo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-12-02 8:57 ` AngeloGioacchino Del Regno
(?)
@ 2022-12-02 9:19 ` AngeloGioacchino Del Regno
-1 siblings, 0 replies; 75+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-12-02 9:19 UTC (permalink / raw)
To: Viresh Kumar, Thorsten Leemhuis
Cc: jia-wei.chang, Nick, Matthias Brugger, rex-bc.chen,
Frank Wunderlich, regressions, linux-pm, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, Hühn,
Thomas, Daniel Golle
Il 02/12/22 09:57, AngeloGioacchino Del Regno ha scritto:
> Il 02/12/22 06:27, Viresh Kumar ha scritto:
>> On 01-12-22, 16:39, Thorsten Leemhuis wrote:
>>> Thx for clarifying. And I noticed I made a mistake: I should have
>>> directed my earlier question wrt to any progress here more into the
>>> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh Kumar
>>> (who committed it).
>>
>> I was waiting for the platform maintainers to come up with a fix. I
>> have sent a patch now to revert this, in-reply-to this thread.
>>
>> Please confirm this is working fine. Thanks.
>>
>
> Can you guys try this patch that I've sent a while ago?
>
> https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
>
> There were comments on it, but if that solves your issue I can push a v2
> to solve what was reported.
>
> Regards,
> Angelo
Wait, sorry, I've re-read the stacktrace and that won't help at all.
MediaTek, can you please look at this issue?
Reverting the proposed commit will make MT8183 unstable.
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 9:19 ` AngeloGioacchino Del Regno
0 siblings, 0 replies; 75+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-12-02 9:19 UTC (permalink / raw)
To: Viresh Kumar, Thorsten Leemhuis
Cc: regressions, linux-pm, Daniel Golle,
Project_Global_Chrome_Upstream_Group, rex-bc.chen,
linux-mediatek, Matthias Brugger, Hühn, Thomas,
jia-wei.chang, linux-arm-kernel, Nick
Il 02/12/22 09:57, AngeloGioacchino Del Regno ha scritto:
> Il 02/12/22 06:27, Viresh Kumar ha scritto:
>> On 01-12-22, 16:39, Thorsten Leemhuis wrote:
>>> Thx for clarifying. And I noticed I made a mistake: I should have
>>> directed my earlier question wrt to any progress here more into the
>>> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh Kumar
>>> (who committed it).
>>
>> I was waiting for the platform maintainers to come up with a fix. I
>> have sent a patch now to revert this, in-reply-to this thread.
>>
>> Please confirm this is working fine. Thanks.
>>
>
> Can you guys try this patch that I've sent a while ago?
>
> https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
>
> There were comments on it, but if that solves your issue I can push a v2
> to solve what was reported.
>
> Regards,
> Angelo
Wait, sorry, I've re-read the stacktrace and that won't help at all.
MediaTek, can you please look at this issue?
Reverting the proposed commit will make MT8183 unstable.
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 9:19 ` AngeloGioacchino Del Regno
0 siblings, 0 replies; 75+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-12-02 9:19 UTC (permalink / raw)
To: Viresh Kumar, Thorsten Leemhuis
Cc: jia-wei.chang, Nick, Matthias Brugger, rex-bc.chen,
Frank Wunderlich, regressions, linux-pm, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, Hühn,
Thomas, Daniel Golle
Il 02/12/22 09:57, AngeloGioacchino Del Regno ha scritto:
> Il 02/12/22 06:27, Viresh Kumar ha scritto:
>> On 01-12-22, 16:39, Thorsten Leemhuis wrote:
>>> Thx for clarifying. And I noticed I made a mistake: I should have
>>> directed my earlier question wrt to any progress here more into the
>>> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh Kumar
>>> (who committed it).
>>
>> I was waiting for the platform maintainers to come up with a fix. I
>> have sent a patch now to revert this, in-reply-to this thread.
>>
>> Please confirm this is working fine. Thanks.
>>
>
> Can you guys try this patch that I've sent a while ago?
>
> https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
>
> There were comments on it, but if that solves your issue I can push a v2
> to solve what was reported.
>
> Regards,
> Angelo
Wait, sorry, I've re-read the stacktrace and that won't help at all.
MediaTek, can you please look at this issue?
Reverting the proposed commit will make MT8183 unstable.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-12-02 9:19 ` AngeloGioacchino Del Regno
(?)
@ 2022-12-02 9:43 ` Allen-KH Cheng (程冠勳)
-1 siblings, 0 replies; 75+ messages in thread
From: Allen-KH Cheng (程冠勳) @ 2022-12-02 9:43 UTC (permalink / raw)
To: regressions, viresh.kumar, angelogioacchino.delregno
Cc: linux-mediatek, regressions, linux-pm, vincent, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
Hi Angelo,
Jia-wei is working on this issue.
We will update progress ASAP.
Thanks,
Allen
On Fri, 2022-12-02 at 10:19 +0100, AngeloGioacchino Del Regno wrote:
> Il 02/12/22 09:57, AngeloGioacchino Del Regno ha scritto:
> > Il 02/12/22 06:27, Viresh Kumar ha scritto:
> > > On 01-12-22, 16:39, Thorsten Leemhuis wrote:
> > > > Thx for clarifying. And I noticed I made a mistake: I should
> > > > have
> > > > directed my earlier question wrt to any progress here more into
> > > > the
> > > > direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh
> > > > Kumar
> > > > (who committed it).
> > >
> > > I was waiting for the platform maintainers to come up with a fix.
> > > I
> > > have sent a patch now to revert this, in-reply-to this thread.
> > >
> > > Please confirm this is working fine. Thanks.
> > >
> >
> > Can you guys try this patch that I've sent a while ago?
> >
> >
https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
> >
> > There were comments on it, but if that solves your issue I can push
> > a v2
> > to solve what was reported.
> >
> > Regards,
> > Angelo
>
> Wait, sorry, I've re-read the stacktrace and that won't help at all.
> MediaTek, can you please look at this issue?
>
> Reverting the proposed commit will make MT8183 unstable.
>
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 9:43 ` Allen-KH Cheng (程冠勳)
0 siblings, 0 replies; 75+ messages in thread
From: Allen-KH Cheng (程冠勳) @ 2022-12-02 9:43 UTC (permalink / raw)
To: regressions, viresh.kumar, angelogioacchino.delregno
Cc: vincent, linux-pm, daniel, Project_Global_Chrome_Upstream_Group,
Rex-BC Chen (陳柏辰),
linux-mediatek, matthias.bgg, thomas.huehn,
Jia-wei Chang (張佳偉),
linux-arm-kernel, regressions
Hi Angelo,
Jia-wei is working on this issue.
We will update progress ASAP.
Thanks,
Allen
On Fri, 2022-12-02 at 10:19 +0100, AngeloGioacchino Del Regno wrote:
> Il 02/12/22 09:57, AngeloGioacchino Del Regno ha scritto:
> > Il 02/12/22 06:27, Viresh Kumar ha scritto:
> > > On 01-12-22, 16:39, Thorsten Leemhuis wrote:
> > > > Thx for clarifying. And I noticed I made a mistake: I should
> > > > have
> > > > directed my earlier question wrt to any progress here more into
> > > > the
> > > > direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh
> > > > Kumar
> > > > (who committed it).
> > >
> > > I was waiting for the platform maintainers to come up with a fix.
> > > I
> > > have sent a patch now to revert this, in-reply-to this thread.
> > >
> > > Please confirm this is working fine. Thanks.
> > >
> >
> > Can you guys try this patch that I've sent a while ago?
> >
> >
https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
> >
> > There were comments on it, but if that solves your issue I can push
> > a v2
> > to solve what was reported.
> >
> > Regards,
> > Angelo
>
> Wait, sorry, I've re-read the stacktrace and that won't help at all.
> MediaTek, can you please look at this issue?
>
> Reverting the proposed commit will make MT8183 unstable.
>
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 9:43 ` Allen-KH Cheng (程冠勳)
0 siblings, 0 replies; 75+ messages in thread
From: Allen-KH Cheng (程冠勳) @ 2022-12-02 9:43 UTC (permalink / raw)
To: regressions, viresh.kumar, angelogioacchino.delregno
Cc: linux-mediatek, regressions, linux-pm, vincent, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
Hi Angelo,
Jia-wei is working on this issue.
We will update progress ASAP.
Thanks,
Allen
On Fri, 2022-12-02 at 10:19 +0100, AngeloGioacchino Del Regno wrote:
> Il 02/12/22 09:57, AngeloGioacchino Del Regno ha scritto:
> > Il 02/12/22 06:27, Viresh Kumar ha scritto:
> > > On 01-12-22, 16:39, Thorsten Leemhuis wrote:
> > > > Thx for clarifying. And I noticed I made a mistake: I should
> > > > have
> > > > directed my earlier question wrt to any progress here more into
> > > > the
> > > > direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh
> > > > Kumar
> > > > (who committed it).
> > >
> > > I was waiting for the platform maintainers to come up with a fix.
> > > I
> > > have sent a patch now to revert this, in-reply-to this thread.
> > >
> > > Please confirm this is working fine. Thanks.
> > >
> >
> > Can you guys try this patch that I've sent a while ago?
> >
> >
https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
> >
> > There were comments on it, but if that solves your issue I can push
> > a v2
> > to solve what was reported.
> >
> > Regards,
> > Angelo
>
> Wait, sorry, I've re-read the stacktrace and that won't help at all.
> MediaTek, can you please look at this issue?
>
> Reverting the proposed commit will make MT8183 unstable.
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-12-02 9:43 ` Allen-KH Cheng (程冠勳)
(?)
@ 2022-12-02 10:02 ` AngeloGioacchino Del Regno
-1 siblings, 0 replies; 75+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-12-02 10:02 UTC (permalink / raw)
To: Allen-KH Cheng (程冠勳), regressions, viresh.kumar
Cc: linux-mediatek, regressions, linux-pm, vincent, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
Il 02/12/22 10:43, Allen-KH Cheng (程冠勳) ha scritto:
> Hi Angelo,
>
> Jia-wei is working on this issue.
>
> We will update progress ASAP.
>
I think I've found something: the MT7622/7623 voltage constraints
set in mediatek-cpufreq's platform data seem to be wrong.
I've sent a commit to fix those [1] and that should solve the issue
that was seen on MT7622, but the code in the voltage tracking algorithm
is unsafe: this crash should be happening because we may be calling
regulator_set_voltage() with max_uV < min_uV --- and this is not legal.
That's happening due to the OPP tables in devicetree asking for a voltage
that is higher than the {proc,sram}_max_volt declared by the platform data
in the mediatek-cpufreq driver: the solution would be to either check the
validity of the constraints everytime se call regulator_set_voltage there,
which wouldn't be optimal IMO, or walk the OPP table at mediatek-cpufreq
probe time (or init time) to either:
1. Print a big warning in kmsg and always ignore all of the OPP entries
that request a voltage that's higher than the maximum that we declared; or
2. Fail probe/init with an error explicitly saying that the OPP entries
are declaring an out of range voltage for sram/proc.
Anyway, thanks for the response, hope that Jia-wei confirms, or denies
my findings and makes this driver more robust ASAP.
Thank you!
Angelo
[1]:
https://lore.kernel.org/lkml/20221202095227.167492-1-angelogioacchino.delregno@collabora.com/
> Thanks,
> Allen
>
> On Fri, 2022-12-02 at 10:19 +0100, AngeloGioacchino Del Regno wrote:
>> Il 02/12/22 09:57, AngeloGioacchino Del Regno ha scritto:
>>> Il 02/12/22 06:27, Viresh Kumar ha scritto:
>>>> On 01-12-22, 16:39, Thorsten Leemhuis wrote:
>>>>> Thx for clarifying. And I noticed I made a mistake: I should
>>>>> have
>>>>> directed my earlier question wrt to any progress here more into
>>>>> the
>>>>> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh
>>>>> Kumar
>>>>> (who committed it).
>>>>
>>>> I was waiting for the platform maintainers to come up with a fix.
>>>> I
>>>> have sent a patch now to revert this, in-reply-to this thread.
>>>>
>>>> Please confirm this is working fine. Thanks.
>>>>
>>>
>>> Can you guys try this patch that I've sent a while ago?
>>>
>>>
> https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
>>>
>>> There were comments on it, but if that solves your issue I can push
>>> a v2
>>> to solve what was reported.
>>>
>>> Regards,
>>> Angelo
>>
>> Wait, sorry, I've re-read the stacktrace and that won't help at all.
>> MediaTek, can you please look at this issue?
>>
>> Reverting the proposed commit will make MT8183 unstable.
>>
>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 10:02 ` AngeloGioacchino Del Regno
0 siblings, 0 replies; 75+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-12-02 10:02 UTC (permalink / raw)
To: Allen-KH Cheng (程冠勳), regressions, viresh.kumar
Cc: vincent, linux-pm, daniel, Project_Global_Chrome_Upstream_Group,
Rex-BC Chen (陳柏辰),
linux-mediatek, matthias.bgg, thomas.huehn,
Jia-wei Chang (張佳偉),
linux-arm-kernel, regressions
Il 02/12/22 10:43, Allen-KH Cheng (程冠勳) ha scritto:
> Hi Angelo,
>
> Jia-wei is working on this issue.
>
> We will update progress ASAP.
>
I think I've found something: the MT7622/7623 voltage constraints
set in mediatek-cpufreq's platform data seem to be wrong.
I've sent a commit to fix those [1] and that should solve the issue
that was seen on MT7622, but the code in the voltage tracking algorithm
is unsafe: this crash should be happening because we may be calling
regulator_set_voltage() with max_uV < min_uV --- and this is not legal.
That's happening due to the OPP tables in devicetree asking for a voltage
that is higher than the {proc,sram}_max_volt declared by the platform data
in the mediatek-cpufreq driver: the solution would be to either check the
validity of the constraints everytime se call regulator_set_voltage there,
which wouldn't be optimal IMO, or walk the OPP table at mediatek-cpufreq
probe time (or init time) to either:
1. Print a big warning in kmsg and always ignore all of the OPP entries
that request a voltage that's higher than the maximum that we declared; or
2. Fail probe/init with an error explicitly saying that the OPP entries
are declaring an out of range voltage for sram/proc.
Anyway, thanks for the response, hope that Jia-wei confirms, or denies
my findings and makes this driver more robust ASAP.
Thank you!
Angelo
[1]:
https://lore.kernel.org/lkml/20221202095227.167492-1-angelogioacchino.delregno@collabora.com/
> Thanks,
> Allen
>
> On Fri, 2022-12-02 at 10:19 +0100, AngeloGioacchino Del Regno wrote:
>> Il 02/12/22 09:57, AngeloGioacchino Del Regno ha scritto:
>>> Il 02/12/22 06:27, Viresh Kumar ha scritto:
>>>> On 01-12-22, 16:39, Thorsten Leemhuis wrote:
>>>>> Thx for clarifying. And I noticed I made a mistake: I should
>>>>> have
>>>>> directed my earlier question wrt to any progress here more into
>>>>> the
>>>>> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh
>>>>> Kumar
>>>>> (who committed it).
>>>>
>>>> I was waiting for the platform maintainers to come up with a fix.
>>>> I
>>>> have sent a patch now to revert this, in-reply-to this thread.
>>>>
>>>> Please confirm this is working fine. Thanks.
>>>>
>>>
>>> Can you guys try this patch that I've sent a while ago?
>>>
>>>
> https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
>>>
>>> There were comments on it, but if that solves your issue I can push
>>> a v2
>>> to solve what was reported.
>>>
>>> Regards,
>>> Angelo
>>
>> Wait, sorry, I've re-read the stacktrace and that won't help at all.
>> MediaTek, can you please look at this issue?
>>
>> Reverting the proposed commit will make MT8183 unstable.
>>
>>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 10:02 ` AngeloGioacchino Del Regno
0 siblings, 0 replies; 75+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-12-02 10:02 UTC (permalink / raw)
To: Allen-KH Cheng (程冠勳), regressions, viresh.kumar
Cc: linux-mediatek, regressions, linux-pm, vincent, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
Il 02/12/22 10:43, Allen-KH Cheng (程冠勳) ha scritto:
> Hi Angelo,
>
> Jia-wei is working on this issue.
>
> We will update progress ASAP.
>
I think I've found something: the MT7622/7623 voltage constraints
set in mediatek-cpufreq's platform data seem to be wrong.
I've sent a commit to fix those [1] and that should solve the issue
that was seen on MT7622, but the code in the voltage tracking algorithm
is unsafe: this crash should be happening because we may be calling
regulator_set_voltage() with max_uV < min_uV --- and this is not legal.
That's happening due to the OPP tables in devicetree asking for a voltage
that is higher than the {proc,sram}_max_volt declared by the platform data
in the mediatek-cpufreq driver: the solution would be to either check the
validity of the constraints everytime se call regulator_set_voltage there,
which wouldn't be optimal IMO, or walk the OPP table at mediatek-cpufreq
probe time (or init time) to either:
1. Print a big warning in kmsg and always ignore all of the OPP entries
that request a voltage that's higher than the maximum that we declared; or
2. Fail probe/init with an error explicitly saying that the OPP entries
are declaring an out of range voltage for sram/proc.
Anyway, thanks for the response, hope that Jia-wei confirms, or denies
my findings and makes this driver more robust ASAP.
Thank you!
Angelo
[1]:
https://lore.kernel.org/lkml/20221202095227.167492-1-angelogioacchino.delregno@collabora.com/
> Thanks,
> Allen
>
> On Fri, 2022-12-02 at 10:19 +0100, AngeloGioacchino Del Regno wrote:
>> Il 02/12/22 09:57, AngeloGioacchino Del Regno ha scritto:
>>> Il 02/12/22 06:27, Viresh Kumar ha scritto:
>>>> On 01-12-22, 16:39, Thorsten Leemhuis wrote:
>>>>> Thx for clarifying. And I noticed I made a mistake: I should
>>>>> have
>>>>> directed my earlier question wrt to any progress here more into
>>>>> the
>>>>> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh
>>>>> Kumar
>>>>> (who committed it).
>>>>
>>>> I was waiting for the platform maintainers to come up with a fix.
>>>> I
>>>> have sent a patch now to revert this, in-reply-to this thread.
>>>>
>>>> Please confirm this is working fine. Thanks.
>>>>
>>>
>>> Can you guys try this patch that I've sent a while ago?
>>>
>>>
> https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
>>>
>>> There were comments on it, but if that solves your issue I can push
>>> a v2
>>> to solve what was reported.
>>>
>>> Regards,
>>> Angelo
>>
>> Wait, sorry, I've re-read the stacktrace and that won't help at all.
>> MediaTek, can you please look at this issue?
>>
>> Reverting the proposed commit will make MT8183 unstable.
>>
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-12-02 10:02 ` AngeloGioacchino Del Regno
(?)
@ 2022-12-02 10:41 ` Thorsten Leemhuis
-1 siblings, 0 replies; 75+ messages in thread
From: Thorsten Leemhuis @ 2022-12-02 10:41 UTC (permalink / raw)
To: AngeloGioacchino Del Regno,
Allen-KH Cheng (程冠勳),
viresh.kumar
Cc: linux-mediatek, regressions, linux-pm, vincent, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
On 02.12.22 11:02, AngeloGioacchino Del Regno wrote:
> Il 02/12/22 10:43, Allen-KH Cheng (程冠勳) ha scritto:
>>
>> Jia-wei is working on this issue.
>> We will update progress ASAP.
>>
>
> I think I've found something: the MT7622/7623 voltage constraints
> set in mediatek-cpufreq's platform data seem to be wrong.
Thx for looking into this.
> I've sent a commit to fix those [1]
Quick question: is that relative to apply at this point of the 6.1 devel
cycle? Or would it be better to revert the culprit (already introduced
in 5.19) for now and reapply it together with that fix for 6.2 (and then
backport to 6.1 stable later)?
> and that should solve the issue
> that was seen on MT7622, but the code in the voltage tracking algorithm
> is unsafe: this crash should be happening because we may be calling
> regulator_set_voltage() with max_uV < min_uV --- and this is not legal.
[...]
> [1]:
> https://lore.kernel.org/lkml/20221202095227.167492-1-angelogioacchino.delregno@collabora.com/
Side note, that patch afaics should have:
Reported-by: Nick <vincent@systemli.org>
Link:
https://lore.kernel.org/r/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
To explain: Linus[1] and others considered proper link tags important in
cases like this, as they allow anyone to look into the backstory of a
commit weeks or years later. That's nothing new, the documentation[2]
for some time says to place tags in cases like this. I care personally
(and made it a bit more explicit in the docs a while ago), because these
tags make my regression tracking efforts a whole lot easier, as they
allow my tracking bot 'regzbot' to automatically connect reports with
patches posted or committed to fix tracked regressions.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
[1] for details, see:
https://lore.kernel.org/all/CAHk-=wjMmSZzMJ3Xnskdg4+GGz=5p5p+GSYyFBTh0f-DgvdBWg@mail.gmail.com/
https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/
https://lore.kernel.org/all/CAHk-=wjxzafG-=J8oT30s7upn4RhBs6TX-uVFZ5rME+L5_DoJA@mail.gmail.com/
[2] see Documentation/process/submitting-patches.rst
(http://docs.kernel.org/process/submitting-patches.html) and
Documentation/process/5.Posting.rst
(https://docs.kernel.org/process/5.Posting.html)
>> Thanks,
>> Allen
>>
>> On Fri, 2022-12-02 at 10:19 +0100, AngeloGioacchino Del Regno wrote:
>>> Il 02/12/22 09:57, AngeloGioacchino Del Regno ha scritto:
>>>> Il 02/12/22 06:27, Viresh Kumar ha scritto:
>>>>> On 01-12-22, 16:39, Thorsten Leemhuis wrote:
>>>>>> Thx for clarifying. And I noticed I made a mistake: I should
>>>>>> have
>>>>>> directed my earlier question wrt to any progress here more into
>>>>>> the
>>>>>> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh
>>>>>> Kumar
>>>>>> (who committed it).
>>>>>
>>>>> I was waiting for the platform maintainers to come up with a fix.
>>>>> I
>>>>> have sent a patch now to revert this, in-reply-to this thread.
>>>>>
>>>>> Please confirm this is working fine. Thanks.
>>>>>
>>>>
>>>> Can you guys try this patch that I've sent a while ago?
>>>>
>>>>
>> https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
>>>>
>>>> There were comments on it, but if that solves your issue I can push
>>>> a v2
>>>> to solve what was reported.
>>>>
>>>> Regards,
>>>> Angelo
>>>
>>> Wait, sorry, I've re-read the stacktrace and that won't help at all.
>>> MediaTek, can you please look at this issue?
>>>
>>> Reverting the proposed commit will make MT8183 unstable.
>>>
>>>
#regzbot monitor:
https://lore.kernel.org/r/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 10:41 ` Thorsten Leemhuis
0 siblings, 0 replies; 75+ messages in thread
From: Thorsten Leemhuis @ 2022-12-02 10:41 UTC (permalink / raw)
To: AngeloGioacchino Del Regno,
Allen-KH Cheng (程冠勳),
viresh.kumar
Cc: vincent, linux-pm, daniel, Project_Global_Chrome_Upstream_Group,
Rex-BC Chen (陳柏辰),
linux-mediatek, matthias.bgg, thomas.huehn,
Jia-wei Chang (張佳偉),
linux-arm-kernel, regressions
On 02.12.22 11:02, AngeloGioacchino Del Regno wrote:
> Il 02/12/22 10:43, Allen-KH Cheng (程冠勳) ha scritto:
>>
>> Jia-wei is working on this issue.
>> We will update progress ASAP.
>>
>
> I think I've found something: the MT7622/7623 voltage constraints
> set in mediatek-cpufreq's platform data seem to be wrong.
Thx for looking into this.
> I've sent a commit to fix those [1]
Quick question: is that relative to apply at this point of the 6.1 devel
cycle? Or would it be better to revert the culprit (already introduced
in 5.19) for now and reapply it together with that fix for 6.2 (and then
backport to 6.1 stable later)?
> and that should solve the issue
> that was seen on MT7622, but the code in the voltage tracking algorithm
> is unsafe: this crash should be happening because we may be calling
> regulator_set_voltage() with max_uV < min_uV --- and this is not legal.
[...]
> [1]:
> https://lore.kernel.org/lkml/20221202095227.167492-1-angelogioacchino.delregno@collabora.com/
Side note, that patch afaics should have:
Reported-by: Nick <vincent@systemli.org>
Link:
https://lore.kernel.org/r/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
To explain: Linus[1] and others considered proper link tags important in
cases like this, as they allow anyone to look into the backstory of a
commit weeks or years later. That's nothing new, the documentation[2]
for some time says to place tags in cases like this. I care personally
(and made it a bit more explicit in the docs a while ago), because these
tags make my regression tracking efforts a whole lot easier, as they
allow my tracking bot 'regzbot' to automatically connect reports with
patches posted or committed to fix tracked regressions.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
[1] for details, see:
https://lore.kernel.org/all/CAHk-=wjMmSZzMJ3Xnskdg4+GGz=5p5p+GSYyFBTh0f-DgvdBWg@mail.gmail.com/
https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/
https://lore.kernel.org/all/CAHk-=wjxzafG-=J8oT30s7upn4RhBs6TX-uVFZ5rME+L5_DoJA@mail.gmail.com/
[2] see Documentation/process/submitting-patches.rst
(http://docs.kernel.org/process/submitting-patches.html) and
Documentation/process/5.Posting.rst
(https://docs.kernel.org/process/5.Posting.html)
>> Thanks,
>> Allen
>>
>> On Fri, 2022-12-02 at 10:19 +0100, AngeloGioacchino Del Regno wrote:
>>> Il 02/12/22 09:57, AngeloGioacchino Del Regno ha scritto:
>>>> Il 02/12/22 06:27, Viresh Kumar ha scritto:
>>>>> On 01-12-22, 16:39, Thorsten Leemhuis wrote:
>>>>>> Thx for clarifying. And I noticed I made a mistake: I should
>>>>>> have
>>>>>> directed my earlier question wrt to any progress here more into
>>>>>> the
>>>>>> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh
>>>>>> Kumar
>>>>>> (who committed it).
>>>>>
>>>>> I was waiting for the platform maintainers to come up with a fix.
>>>>> I
>>>>> have sent a patch now to revert this, in-reply-to this thread.
>>>>>
>>>>> Please confirm this is working fine. Thanks.
>>>>>
>>>>
>>>> Can you guys try this patch that I've sent a while ago?
>>>>
>>>>
>> https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
>>>>
>>>> There were comments on it, but if that solves your issue I can push
>>>> a v2
>>>> to solve what was reported.
>>>>
>>>> Regards,
>>>> Angelo
>>>
>>> Wait, sorry, I've re-read the stacktrace and that won't help at all.
>>> MediaTek, can you please look at this issue?
>>>
>>> Reverting the proposed commit will make MT8183 unstable.
>>>
>>>
#regzbot monitor:
https://lore.kernel.org/r/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 10:41 ` Thorsten Leemhuis
0 siblings, 0 replies; 75+ messages in thread
From: Thorsten Leemhuis @ 2022-12-02 10:41 UTC (permalink / raw)
To: AngeloGioacchino Del Regno,
Allen-KH Cheng (程冠勳),
viresh.kumar
Cc: linux-mediatek, regressions, linux-pm, vincent, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
On 02.12.22 11:02, AngeloGioacchino Del Regno wrote:
> Il 02/12/22 10:43, Allen-KH Cheng (程冠勳) ha scritto:
>>
>> Jia-wei is working on this issue.
>> We will update progress ASAP.
>>
>
> I think I've found something: the MT7622/7623 voltage constraints
> set in mediatek-cpufreq's platform data seem to be wrong.
Thx for looking into this.
> I've sent a commit to fix those [1]
Quick question: is that relative to apply at this point of the 6.1 devel
cycle? Or would it be better to revert the culprit (already introduced
in 5.19) for now and reapply it together with that fix for 6.2 (and then
backport to 6.1 stable later)?
> and that should solve the issue
> that was seen on MT7622, but the code in the voltage tracking algorithm
> is unsafe: this crash should be happening because we may be calling
> regulator_set_voltage() with max_uV < min_uV --- and this is not legal.
[...]
> [1]:
> https://lore.kernel.org/lkml/20221202095227.167492-1-angelogioacchino.delregno@collabora.com/
Side note, that patch afaics should have:
Reported-by: Nick <vincent@systemli.org>
Link:
https://lore.kernel.org/r/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
To explain: Linus[1] and others considered proper link tags important in
cases like this, as they allow anyone to look into the backstory of a
commit weeks or years later. That's nothing new, the documentation[2]
for some time says to place tags in cases like this. I care personally
(and made it a bit more explicit in the docs a while ago), because these
tags make my regression tracking efforts a whole lot easier, as they
allow my tracking bot 'regzbot' to automatically connect reports with
patches posted or committed to fix tracked regressions.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
[1] for details, see:
https://lore.kernel.org/all/CAHk-=wjMmSZzMJ3Xnskdg4+GGz=5p5p+GSYyFBTh0f-DgvdBWg@mail.gmail.com/
https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/
https://lore.kernel.org/all/CAHk-=wjxzafG-=J8oT30s7upn4RhBs6TX-uVFZ5rME+L5_DoJA@mail.gmail.com/
[2] see Documentation/process/submitting-patches.rst
(http://docs.kernel.org/process/submitting-patches.html) and
Documentation/process/5.Posting.rst
(https://docs.kernel.org/process/5.Posting.html)
>> Thanks,
>> Allen
>>
>> On Fri, 2022-12-02 at 10:19 +0100, AngeloGioacchino Del Regno wrote:
>>> Il 02/12/22 09:57, AngeloGioacchino Del Regno ha scritto:
>>>> Il 02/12/22 06:27, Viresh Kumar ha scritto:
>>>>> On 01-12-22, 16:39, Thorsten Leemhuis wrote:
>>>>>> Thx for clarifying. And I noticed I made a mistake: I should
>>>>>> have
>>>>>> directed my earlier question wrt to any progress here more into
>>>>>> the
>>>>>> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh
>>>>>> Kumar
>>>>>> (who committed it).
>>>>>
>>>>> I was waiting for the platform maintainers to come up with a fix.
>>>>> I
>>>>> have sent a patch now to revert this, in-reply-to this thread.
>>>>>
>>>>> Please confirm this is working fine. Thanks.
>>>>>
>>>>
>>>> Can you guys try this patch that I've sent a while ago?
>>>>
>>>>
>> https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
>>>>
>>>> There were comments on it, but if that solves your issue I can push
>>>> a v2
>>>> to solve what was reported.
>>>>
>>>> Regards,
>>>> Angelo
>>>
>>> Wait, sorry, I've re-read the stacktrace and that won't help at all.
>>> MediaTek, can you please look at this issue?
>>>
>>> Reverting the proposed commit will make MT8183 unstable.
>>>
>>>
#regzbot monitor:
https://lore.kernel.org/r/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-12-02 10:41 ` Thorsten Leemhuis
(?)
@ 2022-12-02 10:47 ` Viresh Kumar
-1 siblings, 0 replies; 75+ messages in thread
From: Viresh Kumar @ 2022-12-02 10:47 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: AngeloGioacchino Del Regno,
Allen-KH Cheng (程冠勳),
linux-mediatek, regressions, linux-pm, vincent, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
On 02-12-22, 11:41, Thorsten Leemhuis wrote:
> Quick question: is that relative to apply at this point of the 6.1 devel
> cycle? Or would it be better to revert the culprit (already introduced
> in 5.19) for now and reapply it together with that fix for 6.2 (and then
> backport to 6.1 stable later)?
I am not comfortable applying the revert to 6.1 kernel right now, it
is too late and the revert is big enough. Also it isn't something that
came in 6.1 cycle itself, so it isn't ideal to merge it as a fix this
late.
I would like to apply the fix, if we are able to settle on one, for
6.2 and let it get backported via stable to all the affected kernels.
--
viresh
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 10:47 ` Viresh Kumar
0 siblings, 0 replies; 75+ messages in thread
From: Viresh Kumar @ 2022-12-02 10:47 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Rex-BC Chen (陳柏辰),
regressions, linux-pm, daniel,
Project_Global_Chrome_Upstream_Group, matthias.bgg,
linux-mediatek, Allen-KH Cheng (程冠勳),
thomas.huehn, Jia-wei Chang (張佳偉),
AngeloGioacchino Del Regno, linux-arm-kernel, vincent
On 02-12-22, 11:41, Thorsten Leemhuis wrote:
> Quick question: is that relative to apply at this point of the 6.1 devel
> cycle? Or would it be better to revert the culprit (already introduced
> in 5.19) for now and reapply it together with that fix for 6.2 (and then
> backport to 6.1 stable later)?
I am not comfortable applying the revert to 6.1 kernel right now, it
is too late and the revert is big enough. Also it isn't something that
came in 6.1 cycle itself, so it isn't ideal to merge it as a fix this
late.
I would like to apply the fix, if we are able to settle on one, for
6.2 and let it get backported via stable to all the affected kernels.
--
viresh
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 10:47 ` Viresh Kumar
0 siblings, 0 replies; 75+ messages in thread
From: Viresh Kumar @ 2022-12-02 10:47 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: AngeloGioacchino Del Regno,
Allen-KH Cheng (程冠勳),
linux-mediatek, regressions, linux-pm, vincent, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
On 02-12-22, 11:41, Thorsten Leemhuis wrote:
> Quick question: is that relative to apply at this point of the 6.1 devel
> cycle? Or would it be better to revert the culprit (already introduced
> in 5.19) for now and reapply it together with that fix for 6.2 (and then
> backport to 6.1 stable later)?
I am not comfortable applying the revert to 6.1 kernel right now, it
is too late and the revert is big enough. Also it isn't something that
came in 6.1 cycle itself, so it isn't ideal to merge it as a fix this
late.
I would like to apply the fix, if we are able to settle on one, for
6.2 and let it get backported via stable to all the affected kernels.
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-12-02 10:47 ` Viresh Kumar
(?)
@ 2022-12-02 10:51 ` Thorsten Leemhuis
-1 siblings, 0 replies; 75+ messages in thread
From: Thorsten Leemhuis @ 2022-12-02 10:51 UTC (permalink / raw)
To: Viresh Kumar
Cc: AngeloGioacchino Del Regno,
Allen-KH Cheng (程冠勳),
linux-mediatek, regressions, linux-pm, vincent, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
On 02.12.22 11:47, Viresh Kumar wrote:
> On 02-12-22, 11:41, Thorsten Leemhuis wrote:
>> Quick question: is that relative to apply at this point of the 6.1 devel
>> cycle? Or would it be better to revert the culprit (already introduced
>> in 5.19) for now and reapply it together with that fix for 6.2 (and then
>> backport to 6.1 stable later)?
>
> I am not comfortable applying the revert to 6.1 kernel right now, it
> is too late and the revert is big enough. Also it isn't something that
> came in 6.1 cycle itself, so it isn't ideal to merge it as a fix this
> late.
>
> I would like to apply the fix, if we are able to settle on one, for
> 6.2 and let it get backported via stable to all the affected kernels.
Okay, thx, fine for me, just was wondering how to best handle this.
Ciao, Thorsten
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 10:51 ` Thorsten Leemhuis
0 siblings, 0 replies; 75+ messages in thread
From: Thorsten Leemhuis @ 2022-12-02 10:51 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rex-BC Chen (陳柏辰),
regressions, linux-pm, daniel,
Project_Global_Chrome_Upstream_Group, matthias.bgg,
linux-mediatek, Allen-KH Cheng (程冠勳),
thomas.huehn, Jia-wei Chang (張佳偉),
AngeloGioacchino Del Regno, linux-arm-kernel, vincent
On 02.12.22 11:47, Viresh Kumar wrote:
> On 02-12-22, 11:41, Thorsten Leemhuis wrote:
>> Quick question: is that relative to apply at this point of the 6.1 devel
>> cycle? Or would it be better to revert the culprit (already introduced
>> in 5.19) for now and reapply it together with that fix for 6.2 (and then
>> backport to 6.1 stable later)?
>
> I am not comfortable applying the revert to 6.1 kernel right now, it
> is too late and the revert is big enough. Also it isn't something that
> came in 6.1 cycle itself, so it isn't ideal to merge it as a fix this
> late.
>
> I would like to apply the fix, if we are able to settle on one, for
> 6.2 and let it get backported via stable to all the affected kernels.
Okay, thx, fine for me, just was wondering how to best handle this.
Ciao, Thorsten
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 10:51 ` Thorsten Leemhuis
0 siblings, 0 replies; 75+ messages in thread
From: Thorsten Leemhuis @ 2022-12-02 10:51 UTC (permalink / raw)
To: Viresh Kumar
Cc: AngeloGioacchino Del Regno,
Allen-KH Cheng (程冠勳),
linux-mediatek, regressions, linux-pm, vincent, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
On 02.12.22 11:47, Viresh Kumar wrote:
> On 02-12-22, 11:41, Thorsten Leemhuis wrote:
>> Quick question: is that relative to apply at this point of the 6.1 devel
>> cycle? Or would it be better to revert the culprit (already introduced
>> in 5.19) for now and reapply it together with that fix for 6.2 (and then
>> backport to 6.1 stable later)?
>
> I am not comfortable applying the revert to 6.1 kernel right now, it
> is too late and the revert is big enough. Also it isn't something that
> came in 6.1 cycle itself, so it isn't ideal to merge it as a fix this
> late.
>
> I would like to apply the fix, if we are able to settle on one, for
> 6.2 and let it get backported via stable to all the affected kernels.
Okay, thx, fine for me, just was wondering how to best handle this.
Ciao, Thorsten
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-12-02 10:41 ` Thorsten Leemhuis
(?)
@ 2022-12-02 11:00 ` AngeloGioacchino Del Regno
-1 siblings, 0 replies; 75+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-12-02 11:00 UTC (permalink / raw)
To: Thorsten Leemhuis, Allen-KH Cheng (程冠勳),
viresh.kumar
Cc: linux-mediatek, regressions, linux-pm, vincent, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
Il 02/12/22 11:41, Thorsten Leemhuis ha scritto:
> On 02.12.22 11:02, AngeloGioacchino Del Regno wrote:
>> Il 02/12/22 10:43, Allen-KH Cheng (程冠勳) ha scritto:
>>>
>>> Jia-wei is working on this issue.
>>> We will update progress ASAP.
>>>
>>
>> I think I've found something: the MT7622/7623 voltage constraints
>> set in mediatek-cpufreq's platform data seem to be wrong.
>
> Thx for looking into this.
>> I've sent a commit to fix those [1]
>
> Quick question: is that relative to apply at this point of the 6.1 devel
> cycle? Or would it be better to revert the culprit (already introduced
> in 5.19) for now and reapply it together with that fix for 6.2 (and then
> backport to 6.1 stable later)?
>
>> and that should solve the issue
>> that was seen on MT7622, but the code in the voltage tracking algorithm
>> is unsafe: this crash should be happening because we may be calling
>> regulator_set_voltage() with max_uV < min_uV --- and this is not legal.
>
> [...]
>
>> [1]:
>> https://lore.kernel.org/lkml/20221202095227.167492-1-angelogioacchino.delregno@collabora.com/
>
> Side note, that patch afaics should have:
>
> Reported-by: Nick <vincent@systemli.org>
> Link:
> https://lore.kernel.org/r/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
>
I'm sorry, forgot about those. I'll wait for feedback on that patch first.
If Viresh can add those while applying the patch, that's fine for me - otherwise
I can send a v2 adding the two suggested missing tags.
Thanks all!
Angelo
> To explain: Linus[1] and others considered proper link tags important in
> cases like this, as they allow anyone to look into the backstory of a
> commit weeks or years later. That's nothing new, the documentation[2]
> for some time says to place tags in cases like this. I care personally
> (and made it a bit more explicit in the docs a while ago), because these
> tags make my regression tracking efforts a whole lot easier, as they
> allow my tracking bot 'regzbot' to automatically connect reports with
> patches posted or committed to fix tracked regressions.
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>
> [1] for details, see:
> https://lore.kernel.org/all/CAHk-=wjMmSZzMJ3Xnskdg4+GGz=5p5p+GSYyFBTh0f-DgvdBWg@mail.gmail.com/
> https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/
> https://lore.kernel.org/all/CAHk-=wjxzafG-=J8oT30s7upn4RhBs6TX-uVFZ5rME+L5_DoJA@mail.gmail.com/
>
> [2] see Documentation/process/submitting-patches.rst
> (http://docs.kernel.org/process/submitting-patches.html) and
> Documentation/process/5.Posting.rst
> (https://docs.kernel.org/process/5.Posting.html)
>
>
>
>>> Thanks,
>>> Allen
>>>
>>> On Fri, 2022-12-02 at 10:19 +0100, AngeloGioacchino Del Regno wrote:
>>>> Il 02/12/22 09:57, AngeloGioacchino Del Regno ha scritto:
>>>>> Il 02/12/22 06:27, Viresh Kumar ha scritto:
>>>>>> On 01-12-22, 16:39, Thorsten Leemhuis wrote:
>>>>>>> Thx for clarifying. And I noticed I made a mistake: I should
>>>>>>> have
>>>>>>> directed my earlier question wrt to any progress here more into
>>>>>>> the
>>>>>>> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh
>>>>>>> Kumar
>>>>>>> (who committed it).
>>>>>>
>>>>>> I was waiting for the platform maintainers to come up with a fix.
>>>>>> I
>>>>>> have sent a patch now to revert this, in-reply-to this thread.
>>>>>>
>>>>>> Please confirm this is working fine. Thanks.
>>>>>>
>>>>>
>>>>> Can you guys try this patch that I've sent a while ago?
>>>>>
>>>>>
>>> https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
>>>>>
>>>>> There were comments on it, but if that solves your issue I can push
>>>>> a v2
>>>>> to solve what was reported.
>>>>>
>>>>> Regards,
>>>>> Angelo
>>>>
>>>> Wait, sorry, I've re-read the stacktrace and that won't help at all.
>>>> MediaTek, can you please look at this issue?
>>>>
>>>> Reverting the proposed commit will make MT8183 unstable.
>>>>
>>>>
>
> #regzbot monitor:
> https://lore.kernel.org/r/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
--
AngeloGioacchino Del Regno
Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 11:00 ` AngeloGioacchino Del Regno
0 siblings, 0 replies; 75+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-12-02 11:00 UTC (permalink / raw)
To: Thorsten Leemhuis, Allen-KH Cheng (程冠勳),
viresh.kumar
Cc: vincent, linux-pm, daniel, Project_Global_Chrome_Upstream_Group,
Rex-BC Chen (陳柏辰),
linux-mediatek, matthias.bgg, thomas.huehn,
Jia-wei Chang (張佳偉),
linux-arm-kernel, regressions
Il 02/12/22 11:41, Thorsten Leemhuis ha scritto:
> On 02.12.22 11:02, AngeloGioacchino Del Regno wrote:
>> Il 02/12/22 10:43, Allen-KH Cheng (程冠勳) ha scritto:
>>>
>>> Jia-wei is working on this issue.
>>> We will update progress ASAP.
>>>
>>
>> I think I've found something: the MT7622/7623 voltage constraints
>> set in mediatek-cpufreq's platform data seem to be wrong.
>
> Thx for looking into this.
>> I've sent a commit to fix those [1]
>
> Quick question: is that relative to apply at this point of the 6.1 devel
> cycle? Or would it be better to revert the culprit (already introduced
> in 5.19) for now and reapply it together with that fix for 6.2 (and then
> backport to 6.1 stable later)?
>
>> and that should solve the issue
>> that was seen on MT7622, but the code in the voltage tracking algorithm
>> is unsafe: this crash should be happening because we may be calling
>> regulator_set_voltage() with max_uV < min_uV --- and this is not legal.
>
> [...]
>
>> [1]:
>> https://lore.kernel.org/lkml/20221202095227.167492-1-angelogioacchino.delregno@collabora.com/
>
> Side note, that patch afaics should have:
>
> Reported-by: Nick <vincent@systemli.org>
> Link:
> https://lore.kernel.org/r/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
>
I'm sorry, forgot about those. I'll wait for feedback on that patch first.
If Viresh can add those while applying the patch, that's fine for me - otherwise
I can send a v2 adding the two suggested missing tags.
Thanks all!
Angelo
> To explain: Linus[1] and others considered proper link tags important in
> cases like this, as they allow anyone to look into the backstory of a
> commit weeks or years later. That's nothing new, the documentation[2]
> for some time says to place tags in cases like this. I care personally
> (and made it a bit more explicit in the docs a while ago), because these
> tags make my regression tracking efforts a whole lot easier, as they
> allow my tracking bot 'regzbot' to automatically connect reports with
> patches posted or committed to fix tracked regressions.
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>
> [1] for details, see:
> https://lore.kernel.org/all/CAHk-=wjMmSZzMJ3Xnskdg4+GGz=5p5p+GSYyFBTh0f-DgvdBWg@mail.gmail.com/
> https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/
> https://lore.kernel.org/all/CAHk-=wjxzafG-=J8oT30s7upn4RhBs6TX-uVFZ5rME+L5_DoJA@mail.gmail.com/
>
> [2] see Documentation/process/submitting-patches.rst
> (http://docs.kernel.org/process/submitting-patches.html) and
> Documentation/process/5.Posting.rst
> (https://docs.kernel.org/process/5.Posting.html)
>
>
>
>>> Thanks,
>>> Allen
>>>
>>> On Fri, 2022-12-02 at 10:19 +0100, AngeloGioacchino Del Regno wrote:
>>>> Il 02/12/22 09:57, AngeloGioacchino Del Regno ha scritto:
>>>>> Il 02/12/22 06:27, Viresh Kumar ha scritto:
>>>>>> On 01-12-22, 16:39, Thorsten Leemhuis wrote:
>>>>>>> Thx for clarifying. And I noticed I made a mistake: I should
>>>>>>> have
>>>>>>> directed my earlier question wrt to any progress here more into
>>>>>>> the
>>>>>>> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh
>>>>>>> Kumar
>>>>>>> (who committed it).
>>>>>>
>>>>>> I was waiting for the platform maintainers to come up with a fix.
>>>>>> I
>>>>>> have sent a patch now to revert this, in-reply-to this thread.
>>>>>>
>>>>>> Please confirm this is working fine. Thanks.
>>>>>>
>>>>>
>>>>> Can you guys try this patch that I've sent a while ago?
>>>>>
>>>>>
>>> https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
>>>>>
>>>>> There were comments on it, but if that solves your issue I can push
>>>>> a v2
>>>>> to solve what was reported.
>>>>>
>>>>> Regards,
>>>>> Angelo
>>>>
>>>> Wait, sorry, I've re-read the stacktrace and that won't help at all.
>>>> MediaTek, can you please look at this issue?
>>>>
>>>> Reverting the proposed commit will make MT8183 unstable.
>>>>
>>>>
>
> #regzbot monitor:
> https://lore.kernel.org/r/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
--
AngeloGioacchino Del Regno
Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 11:00 ` AngeloGioacchino Del Regno
0 siblings, 0 replies; 75+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-12-02 11:00 UTC (permalink / raw)
To: Thorsten Leemhuis, Allen-KH Cheng (程冠勳),
viresh.kumar
Cc: linux-mediatek, regressions, linux-pm, vincent, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
Il 02/12/22 11:41, Thorsten Leemhuis ha scritto:
> On 02.12.22 11:02, AngeloGioacchino Del Regno wrote:
>> Il 02/12/22 10:43, Allen-KH Cheng (程冠勳) ha scritto:
>>>
>>> Jia-wei is working on this issue.
>>> We will update progress ASAP.
>>>
>>
>> I think I've found something: the MT7622/7623 voltage constraints
>> set in mediatek-cpufreq's platform data seem to be wrong.
>
> Thx for looking into this.
>> I've sent a commit to fix those [1]
>
> Quick question: is that relative to apply at this point of the 6.1 devel
> cycle? Or would it be better to revert the culprit (already introduced
> in 5.19) for now and reapply it together with that fix for 6.2 (and then
> backport to 6.1 stable later)?
>
>> and that should solve the issue
>> that was seen on MT7622, but the code in the voltage tracking algorithm
>> is unsafe: this crash should be happening because we may be calling
>> regulator_set_voltage() with max_uV < min_uV --- and this is not legal.
>
> [...]
>
>> [1]:
>> https://lore.kernel.org/lkml/20221202095227.167492-1-angelogioacchino.delregno@collabora.com/
>
> Side note, that patch afaics should have:
>
> Reported-by: Nick <vincent@systemli.org>
> Link:
> https://lore.kernel.org/r/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
>
I'm sorry, forgot about those. I'll wait for feedback on that patch first.
If Viresh can add those while applying the patch, that's fine for me - otherwise
I can send a v2 adding the two suggested missing tags.
Thanks all!
Angelo
> To explain: Linus[1] and others considered proper link tags important in
> cases like this, as they allow anyone to look into the backstory of a
> commit weeks or years later. That's nothing new, the documentation[2]
> for some time says to place tags in cases like this. I care personally
> (and made it a bit more explicit in the docs a while ago), because these
> tags make my regression tracking efforts a whole lot easier, as they
> allow my tracking bot 'regzbot' to automatically connect reports with
> patches posted or committed to fix tracked regressions.
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>
> [1] for details, see:
> https://lore.kernel.org/all/CAHk-=wjMmSZzMJ3Xnskdg4+GGz=5p5p+GSYyFBTh0f-DgvdBWg@mail.gmail.com/
> https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/
> https://lore.kernel.org/all/CAHk-=wjxzafG-=J8oT30s7upn4RhBs6TX-uVFZ5rME+L5_DoJA@mail.gmail.com/
>
> [2] see Documentation/process/submitting-patches.rst
> (http://docs.kernel.org/process/submitting-patches.html) and
> Documentation/process/5.Posting.rst
> (https://docs.kernel.org/process/5.Posting.html)
>
>
>
>>> Thanks,
>>> Allen
>>>
>>> On Fri, 2022-12-02 at 10:19 +0100, AngeloGioacchino Del Regno wrote:
>>>> Il 02/12/22 09:57, AngeloGioacchino Del Regno ha scritto:
>>>>> Il 02/12/22 06:27, Viresh Kumar ha scritto:
>>>>>> On 01-12-22, 16:39, Thorsten Leemhuis wrote:
>>>>>>> Thx for clarifying. And I noticed I made a mistake: I should
>>>>>>> have
>>>>>>> directed my earlier question wrt to any progress here more into
>>>>>>> the
>>>>>>> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh
>>>>>>> Kumar
>>>>>>> (who committed it).
>>>>>>
>>>>>> I was waiting for the platform maintainers to come up with a fix.
>>>>>> I
>>>>>> have sent a patch now to revert this, in-reply-to this thread.
>>>>>>
>>>>>> Please confirm this is working fine. Thanks.
>>>>>>
>>>>>
>>>>> Can you guys try this patch that I've sent a while ago?
>>>>>
>>>>>
>>> https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
>>>>>
>>>>> There were comments on it, but if that solves your issue I can push
>>>>> a v2
>>>>> to solve what was reported.
>>>>>
>>>>> Regards,
>>>>> Angelo
>>>>
>>>> Wait, sorry, I've re-read the stacktrace and that won't help at all.
>>>> MediaTek, can you please look at this issue?
>>>>
>>>> Reverting the proposed commit will make MT8183 unstable.
>>>>
>>>>
>
> #regzbot monitor:
> https://lore.kernel.org/r/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
--
AngeloGioacchino Del Regno
Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-12-02 11:00 ` AngeloGioacchino Del Regno
(?)
@ 2022-12-02 11:01 ` Viresh Kumar
-1 siblings, 0 replies; 75+ messages in thread
From: Viresh Kumar @ 2022-12-02 11:01 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: Thorsten Leemhuis, Allen-KH Cheng (程冠勳),
linux-mediatek, regressions, linux-pm, vincent, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
On 02-12-22, 12:00, AngeloGioacchino Del Regno wrote:
> If Viresh can add those while applying the patch, that's fine for me - otherwise
> I can send a v2 adding the two suggested missing tags.
Sure, no problem.
--
viresh
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 11:01 ` Viresh Kumar
0 siblings, 0 replies; 75+ messages in thread
From: Viresh Kumar @ 2022-12-02 11:01 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: Project_Global_Chrome_Upstream_Group,
Allen-KH Cheng (程冠勳),
linux-pm, daniel, regressions,
Rex-BC Chen (陳柏辰),
Thorsten Leemhuis, linux-mediatek, matthias.bgg, thomas.huehn,
Jia-wei Chang (張佳偉),
linux-arm-kernel, vincent
On 02-12-22, 12:00, AngeloGioacchino Del Regno wrote:
> If Viresh can add those while applying the patch, that's fine for me - otherwise
> I can send a v2 adding the two suggested missing tags.
Sure, no problem.
--
viresh
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 11:01 ` Viresh Kumar
0 siblings, 0 replies; 75+ messages in thread
From: Viresh Kumar @ 2022-12-02 11:01 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: Thorsten Leemhuis, Allen-KH Cheng (程冠勳),
linux-mediatek, regressions, linux-pm, vincent, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
On 02-12-22, 12:00, AngeloGioacchino Del Regno wrote:
> If Viresh can add those while applying the patch, that's fine for me - otherwise
> I can send a v2 adding the two suggested missing tags.
Sure, no problem.
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH] Revert "cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()"
2022-12-02 5:26 ` Viresh Kumar
@ 2022-12-02 12:17 ` Rafael J. Wysocki
-1 siblings, 0 replies; 75+ messages in thread
From: Rafael J. Wysocki @ 2022-12-02 12:17 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael J. Wysocki, Matthias Brugger, linux-pm, Vincent Guittot,
regressions, daniel, thomas.huehn, v5 . 19+,
Nick, linux-kernel, linux-arm-kernel, linux-mediatek
On Fri, Dec 2, 2022 at 6:26 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> This reverts commit 6a17b3876bc8303612d7ad59ecf7cbc0db418bcd.
>
> This commit caused regression on Banana Pi R64 (MT7622), revert until
> the problem is identified and fixed properly.
>
> Link: https://lore.kernel.org/all/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
> Cc: v5.19+ <stable@vger.kernel.org> # v5.19+
> Reported-by: Nick <vincent@systemli.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Do you want me to push this revert for -rc8?
> ---
> drivers/cpufreq/mediatek-cpufreq.c | 147 +++++++++++++++++++----------
> 1 file changed, 96 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
> index 7f2680bc9a0f..4466d0c91a6a 100644
> --- a/drivers/cpufreq/mediatek-cpufreq.c
> +++ b/drivers/cpufreq/mediatek-cpufreq.c
> @@ -8,7 +8,6 @@
> #include <linux/cpu.h>
> #include <linux/cpufreq.h>
> #include <linux/cpumask.h>
> -#include <linux/minmax.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_platform.h>
> @@ -16,6 +15,8 @@
> #include <linux/pm_opp.h>
> #include <linux/regulator/consumer.h>
>
> +#define VOLT_TOL (10000)
> +
> struct mtk_cpufreq_platform_data {
> int min_volt_shift;
> int max_volt_shift;
> @@ -55,7 +56,6 @@ struct mtk_cpu_dvfs_info {
> unsigned int opp_cpu;
> unsigned long current_freq;
> const struct mtk_cpufreq_platform_data *soc_data;
> - int vtrack_max;
> bool ccifreq_bound;
> };
>
> @@ -82,7 +82,6 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> struct regulator *proc_reg = info->proc_reg;
> struct regulator *sram_reg = info->sram_reg;
> int pre_vproc, pre_vsram, new_vsram, vsram, vproc, ret;
> - int retry = info->vtrack_max;
>
> pre_vproc = regulator_get_voltage(proc_reg);
> if (pre_vproc < 0) {
> @@ -90,44 +89,91 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> "invalid Vproc value: %d\n", pre_vproc);
> return pre_vproc;
> }
> + /* Vsram should not exceed the maximum allowed voltage of SoC. */
> + new_vsram = min(new_vproc + soc_data->min_volt_shift,
> + soc_data->sram_max_volt);
> +
> + if (pre_vproc < new_vproc) {
> + /*
> + * When scaling up voltages, Vsram and Vproc scale up step
> + * by step. At each step, set Vsram to (Vproc + 200mV) first,
> + * then set Vproc to (Vsram - 100mV).
> + * Keep doing it until Vsram and Vproc hit target voltages.
> + */
> + do {
> + pre_vsram = regulator_get_voltage(sram_reg);
> + if (pre_vsram < 0) {
> + dev_err(info->cpu_dev,
> + "invalid Vsram value: %d\n", pre_vsram);
> + return pre_vsram;
> + }
> + pre_vproc = regulator_get_voltage(proc_reg);
> + if (pre_vproc < 0) {
> + dev_err(info->cpu_dev,
> + "invalid Vproc value: %d\n", pre_vproc);
> + return pre_vproc;
> + }
>
> - pre_vsram = regulator_get_voltage(sram_reg);
> - if (pre_vsram < 0) {
> - dev_err(info->cpu_dev, "invalid Vsram value: %d\n", pre_vsram);
> - return pre_vsram;
> - }
> + vsram = min(new_vsram,
> + pre_vproc + soc_data->min_volt_shift);
>
> - new_vsram = clamp(new_vproc + soc_data->min_volt_shift,
> - soc_data->sram_min_volt, soc_data->sram_max_volt);
> + if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
> + vsram = soc_data->sram_max_volt;
>
> - do {
> - if (pre_vproc <= new_vproc) {
> - vsram = clamp(pre_vproc + soc_data->max_volt_shift,
> - soc_data->sram_min_volt, new_vsram);
> - ret = regulator_set_voltage(sram_reg, vsram,
> - soc_data->sram_max_volt);
> + /*
> + * If the target Vsram hits the maximum voltage,
> + * try to set the exact voltage value first.
> + */
> + ret = regulator_set_voltage(sram_reg, vsram,
> + vsram);
> + if (ret)
> + ret = regulator_set_voltage(sram_reg,
> + vsram - VOLT_TOL,
> + vsram);
>
> - if (ret)
> - return ret;
> -
> - if (vsram == soc_data->sram_max_volt ||
> - new_vsram == soc_data->sram_min_volt)
> vproc = new_vproc;
> - else
> + } else {
> + ret = regulator_set_voltage(sram_reg, vsram,
> + vsram + VOLT_TOL);
> +
> vproc = vsram - soc_data->min_volt_shift;
> + }
> + if (ret)
> + return ret;
>
> ret = regulator_set_voltage(proc_reg, vproc,
> - soc_data->proc_max_volt);
> + vproc + VOLT_TOL);
> if (ret) {
> regulator_set_voltage(sram_reg, pre_vsram,
> - soc_data->sram_max_volt);
> + pre_vsram);
> return ret;
> }
> - } else if (pre_vproc > new_vproc) {
> + } while (vproc < new_vproc || vsram < new_vsram);
> + } else if (pre_vproc > new_vproc) {
> + /*
> + * When scaling down voltages, Vsram and Vproc scale down step
> + * by step. At each step, set Vproc to (Vsram - 200mV) first,
> + * then set Vproc to (Vproc + 100mV).
> + * Keep doing it until Vsram and Vproc hit target voltages.
> + */
> + do {
> + pre_vproc = regulator_get_voltage(proc_reg);
> + if (pre_vproc < 0) {
> + dev_err(info->cpu_dev,
> + "invalid Vproc value: %d\n", pre_vproc);
> + return pre_vproc;
> + }
> + pre_vsram = regulator_get_voltage(sram_reg);
> + if (pre_vsram < 0) {
> + dev_err(info->cpu_dev,
> + "invalid Vsram value: %d\n", pre_vsram);
> + return pre_vsram;
> + }
> +
> vproc = max(new_vproc,
> pre_vsram - soc_data->max_volt_shift);
> ret = regulator_set_voltage(proc_reg, vproc,
> - soc_data->proc_max_volt);
> + vproc + VOLT_TOL);
> if (ret)
> return ret;
>
> @@ -137,24 +183,32 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> vsram = max(new_vsram,
> vproc + soc_data->min_volt_shift);
>
> - ret = regulator_set_voltage(sram_reg, vsram,
> - soc_data->sram_max_volt);
> + if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
> + vsram = soc_data->sram_max_volt;
> +
> + /*
> + * If the target Vsram hits the maximum voltage,
> + * try to set the exact voltage value first.
> + */
> + ret = regulator_set_voltage(sram_reg, vsram,
> + vsram);
> + if (ret)
> + ret = regulator_set_voltage(sram_reg,
> + vsram - VOLT_TOL,
> + vsram);
> + } else {
> + ret = regulator_set_voltage(sram_reg, vsram,
> + vsram + VOLT_TOL);
> + }
> +
> if (ret) {
> regulator_set_voltage(proc_reg, pre_vproc,
> - soc_data->proc_max_volt);
> + pre_vproc);
> return ret;
> }
> - }
> -
> - pre_vproc = vproc;
> - pre_vsram = vsram;
> -
> - if (--retry < 0) {
> - dev_err(info->cpu_dev,
> - "over loop count, failed to set voltage\n");
> - return -EINVAL;
> - }
> - } while (vproc != new_vproc || vsram != new_vsram);
> + } while (vproc > new_vproc + VOLT_TOL ||
> + vsram > new_vsram + VOLT_TOL);
> + }
>
> return 0;
> }
> @@ -250,8 +304,8 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
> * If the new voltage or the intermediate voltage is higher than the
> * current voltage, scale up voltage first.
> */
> - target_vproc = max(inter_vproc, vproc);
> - if (pre_vproc <= target_vproc) {
> + target_vproc = (inter_vproc > vproc) ? inter_vproc : vproc;
> + if (pre_vproc < target_vproc) {
> ret = mtk_cpufreq_set_voltage(info, target_vproc);
> if (ret) {
> dev_err(cpu_dev,
> @@ -513,15 +567,6 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
> */
> info->need_voltage_tracking = (info->sram_reg != NULL);
>
> - /*
> - * We assume min voltage is 0 and tracking target voltage using
> - * min_volt_shift for each iteration.
> - * The vtrack_max is 3 times of expeted iteration count.
> - */
> - info->vtrack_max = 3 * DIV_ROUND_UP(max(info->soc_data->sram_max_volt,
> - info->soc_data->proc_max_volt),
> - info->soc_data->min_volt_shift);
> -
> return 0;
>
> out_disable_inter_clock:
> --
> 2.31.1.272.g89b43f80a514
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH] Revert "cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()"
@ 2022-12-02 12:17 ` Rafael J. Wysocki
0 siblings, 0 replies; 75+ messages in thread
From: Rafael J. Wysocki @ 2022-12-02 12:17 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael J. Wysocki, Matthias Brugger, linux-pm, Vincent Guittot,
regressions, daniel, thomas.huehn, v5 . 19+,
Nick, linux-kernel, linux-arm-kernel, linux-mediatek
On Fri, Dec 2, 2022 at 6:26 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> This reverts commit 6a17b3876bc8303612d7ad59ecf7cbc0db418bcd.
>
> This commit caused regression on Banana Pi R64 (MT7622), revert until
> the problem is identified and fixed properly.
>
> Link: https://lore.kernel.org/all/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
> Cc: v5.19+ <stable@vger.kernel.org> # v5.19+
> Reported-by: Nick <vincent@systemli.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Do you want me to push this revert for -rc8?
> ---
> drivers/cpufreq/mediatek-cpufreq.c | 147 +++++++++++++++++++----------
> 1 file changed, 96 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
> index 7f2680bc9a0f..4466d0c91a6a 100644
> --- a/drivers/cpufreq/mediatek-cpufreq.c
> +++ b/drivers/cpufreq/mediatek-cpufreq.c
> @@ -8,7 +8,6 @@
> #include <linux/cpu.h>
> #include <linux/cpufreq.h>
> #include <linux/cpumask.h>
> -#include <linux/minmax.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_platform.h>
> @@ -16,6 +15,8 @@
> #include <linux/pm_opp.h>
> #include <linux/regulator/consumer.h>
>
> +#define VOLT_TOL (10000)
> +
> struct mtk_cpufreq_platform_data {
> int min_volt_shift;
> int max_volt_shift;
> @@ -55,7 +56,6 @@ struct mtk_cpu_dvfs_info {
> unsigned int opp_cpu;
> unsigned long current_freq;
> const struct mtk_cpufreq_platform_data *soc_data;
> - int vtrack_max;
> bool ccifreq_bound;
> };
>
> @@ -82,7 +82,6 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> struct regulator *proc_reg = info->proc_reg;
> struct regulator *sram_reg = info->sram_reg;
> int pre_vproc, pre_vsram, new_vsram, vsram, vproc, ret;
> - int retry = info->vtrack_max;
>
> pre_vproc = regulator_get_voltage(proc_reg);
> if (pre_vproc < 0) {
> @@ -90,44 +89,91 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> "invalid Vproc value: %d\n", pre_vproc);
> return pre_vproc;
> }
> + /* Vsram should not exceed the maximum allowed voltage of SoC. */
> + new_vsram = min(new_vproc + soc_data->min_volt_shift,
> + soc_data->sram_max_volt);
> +
> + if (pre_vproc < new_vproc) {
> + /*
> + * When scaling up voltages, Vsram and Vproc scale up step
> + * by step. At each step, set Vsram to (Vproc + 200mV) first,
> + * then set Vproc to (Vsram - 100mV).
> + * Keep doing it until Vsram and Vproc hit target voltages.
> + */
> + do {
> + pre_vsram = regulator_get_voltage(sram_reg);
> + if (pre_vsram < 0) {
> + dev_err(info->cpu_dev,
> + "invalid Vsram value: %d\n", pre_vsram);
> + return pre_vsram;
> + }
> + pre_vproc = regulator_get_voltage(proc_reg);
> + if (pre_vproc < 0) {
> + dev_err(info->cpu_dev,
> + "invalid Vproc value: %d\n", pre_vproc);
> + return pre_vproc;
> + }
>
> - pre_vsram = regulator_get_voltage(sram_reg);
> - if (pre_vsram < 0) {
> - dev_err(info->cpu_dev, "invalid Vsram value: %d\n", pre_vsram);
> - return pre_vsram;
> - }
> + vsram = min(new_vsram,
> + pre_vproc + soc_data->min_volt_shift);
>
> - new_vsram = clamp(new_vproc + soc_data->min_volt_shift,
> - soc_data->sram_min_volt, soc_data->sram_max_volt);
> + if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
> + vsram = soc_data->sram_max_volt;
>
> - do {
> - if (pre_vproc <= new_vproc) {
> - vsram = clamp(pre_vproc + soc_data->max_volt_shift,
> - soc_data->sram_min_volt, new_vsram);
> - ret = regulator_set_voltage(sram_reg, vsram,
> - soc_data->sram_max_volt);
> + /*
> + * If the target Vsram hits the maximum voltage,
> + * try to set the exact voltage value first.
> + */
> + ret = regulator_set_voltage(sram_reg, vsram,
> + vsram);
> + if (ret)
> + ret = regulator_set_voltage(sram_reg,
> + vsram - VOLT_TOL,
> + vsram);
>
> - if (ret)
> - return ret;
> -
> - if (vsram == soc_data->sram_max_volt ||
> - new_vsram == soc_data->sram_min_volt)
> vproc = new_vproc;
> - else
> + } else {
> + ret = regulator_set_voltage(sram_reg, vsram,
> + vsram + VOLT_TOL);
> +
> vproc = vsram - soc_data->min_volt_shift;
> + }
> + if (ret)
> + return ret;
>
> ret = regulator_set_voltage(proc_reg, vproc,
> - soc_data->proc_max_volt);
> + vproc + VOLT_TOL);
> if (ret) {
> regulator_set_voltage(sram_reg, pre_vsram,
> - soc_data->sram_max_volt);
> + pre_vsram);
> return ret;
> }
> - } else if (pre_vproc > new_vproc) {
> + } while (vproc < new_vproc || vsram < new_vsram);
> + } else if (pre_vproc > new_vproc) {
> + /*
> + * When scaling down voltages, Vsram and Vproc scale down step
> + * by step. At each step, set Vproc to (Vsram - 200mV) first,
> + * then set Vproc to (Vproc + 100mV).
> + * Keep doing it until Vsram and Vproc hit target voltages.
> + */
> + do {
> + pre_vproc = regulator_get_voltage(proc_reg);
> + if (pre_vproc < 0) {
> + dev_err(info->cpu_dev,
> + "invalid Vproc value: %d\n", pre_vproc);
> + return pre_vproc;
> + }
> + pre_vsram = regulator_get_voltage(sram_reg);
> + if (pre_vsram < 0) {
> + dev_err(info->cpu_dev,
> + "invalid Vsram value: %d\n", pre_vsram);
> + return pre_vsram;
> + }
> +
> vproc = max(new_vproc,
> pre_vsram - soc_data->max_volt_shift);
> ret = regulator_set_voltage(proc_reg, vproc,
> - soc_data->proc_max_volt);
> + vproc + VOLT_TOL);
> if (ret)
> return ret;
>
> @@ -137,24 +183,32 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> vsram = max(new_vsram,
> vproc + soc_data->min_volt_shift);
>
> - ret = regulator_set_voltage(sram_reg, vsram,
> - soc_data->sram_max_volt);
> + if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
> + vsram = soc_data->sram_max_volt;
> +
> + /*
> + * If the target Vsram hits the maximum voltage,
> + * try to set the exact voltage value first.
> + */
> + ret = regulator_set_voltage(sram_reg, vsram,
> + vsram);
> + if (ret)
> + ret = regulator_set_voltage(sram_reg,
> + vsram - VOLT_TOL,
> + vsram);
> + } else {
> + ret = regulator_set_voltage(sram_reg, vsram,
> + vsram + VOLT_TOL);
> + }
> +
> if (ret) {
> regulator_set_voltage(proc_reg, pre_vproc,
> - soc_data->proc_max_volt);
> + pre_vproc);
> return ret;
> }
> - }
> -
> - pre_vproc = vproc;
> - pre_vsram = vsram;
> -
> - if (--retry < 0) {
> - dev_err(info->cpu_dev,
> - "over loop count, failed to set voltage\n");
> - return -EINVAL;
> - }
> - } while (vproc != new_vproc || vsram != new_vsram);
> + } while (vproc > new_vproc + VOLT_TOL ||
> + vsram > new_vsram + VOLT_TOL);
> + }
>
> return 0;
> }
> @@ -250,8 +304,8 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
> * If the new voltage or the intermediate voltage is higher than the
> * current voltage, scale up voltage first.
> */
> - target_vproc = max(inter_vproc, vproc);
> - if (pre_vproc <= target_vproc) {
> + target_vproc = (inter_vproc > vproc) ? inter_vproc : vproc;
> + if (pre_vproc < target_vproc) {
> ret = mtk_cpufreq_set_voltage(info, target_vproc);
> if (ret) {
> dev_err(cpu_dev,
> @@ -513,15 +567,6 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
> */
> info->need_voltage_tracking = (info->sram_reg != NULL);
>
> - /*
> - * We assume min voltage is 0 and tracking target voltage using
> - * min_volt_shift for each iteration.
> - * The vtrack_max is 3 times of expeted iteration count.
> - */
> - info->vtrack_max = 3 * DIV_ROUND_UP(max(info->soc_data->sram_max_volt,
> - info->soc_data->proc_max_volt),
> - info->soc_data->min_volt_shift);
> -
> return 0;
>
> out_disable_inter_clock:
> --
> 2.31.1.272.g89b43f80a514
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-12-02 10:41 ` Thorsten Leemhuis
(?)
@ 2022-12-02 12:25 ` Nick
-1 siblings, 0 replies; 75+ messages in thread
From: Nick @ 2022-12-02 12:25 UTC (permalink / raw)
To: Thorsten Leemhuis, AngeloGioacchino Del Regno,
Allen-KH Cheng (程冠勳),
viresh.kumar
Cc: linux-mediatek, regressions, linux-pm, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
On 12/2/22 11:41, Thorsten Leemhuis wrote:
> Reported-by: Nick<vincent@systemli.org>
You can also use "Reported-by: Nick Hainke <vincent@systemli.org>" ;)
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 12:25 ` Nick
0 siblings, 0 replies; 75+ messages in thread
From: Nick @ 2022-12-02 12:25 UTC (permalink / raw)
To: Thorsten Leemhuis, AngeloGioacchino Del Regno,
Allen-KH Cheng (程冠勳),
viresh.kumar
Cc: regressions, linux-pm, daniel,
Project_Global_Chrome_Upstream_Group,
Rex-BC Chen (陳柏辰),
linux-mediatek, matthias.bgg, thomas.huehn,
Jia-wei Chang (張佳偉),
linux-arm-kernel
On 12/2/22 11:41, Thorsten Leemhuis wrote:
> Reported-by: Nick<vincent@systemli.org>
You can also use "Reported-by: Nick Hainke <vincent@systemli.org>" ;)
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-02 12:25 ` Nick
0 siblings, 0 replies; 75+ messages in thread
From: Nick @ 2022-12-02 12:25 UTC (permalink / raw)
To: Thorsten Leemhuis, AngeloGioacchino Del Regno,
Allen-KH Cheng (程冠勳),
viresh.kumar
Cc: linux-mediatek, regressions, linux-pm, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
On 12/2/22 11:41, Thorsten Leemhuis wrote:
> Reported-by: Nick<vincent@systemli.org>
You can also use "Reported-by: Nick Hainke <vincent@systemli.org>" ;)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH] Revert "cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()"
2022-12-02 5:26 ` Viresh Kumar
@ 2022-12-02 12:47 ` Nick
-1 siblings, 0 replies; 75+ messages in thread
From: Nick @ 2022-12-02 12:47 UTC (permalink / raw)
To: Viresh Kumar, Rafael J. Wysocki, Matthias Brugger
Cc: linux-pm, Vincent Guittot, regressions, daniel, thomas.huehn,
v5 . 19+,
linux-kernel, linux-arm-kernel, linux-mediatek
I tested this again on linux/master on the Banana Pi R64 (mt7622). Seems
to work fine:
https://gist.githubusercontent.com/PolynomialDivision/5022dec1874a1c411ece6c9dabec59b5/raw/7ac62b38d10e41a56ff1db3142571117ee6f4c26/mt7622-cpufreq-revert.log
So if you want you can add:
Reported-by: Nick Hainke <vincent@systemli.org>
Tested-by: Nick Hainke <vincent@systemli.org>
Bests
Nick
On 12/2/22 06:26, Viresh Kumar wrote:
> This reverts commit 6a17b3876bc8303612d7ad59ecf7cbc0db418bcd.
>
> This commit caused regression on Banana Pi R64 (MT7622), revert until
> the problem is identified and fixed properly.
>
> Link: https://lore.kernel.org/all/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
> Cc: v5.19+ <stable@vger.kernel.org> # v5.19+
> Reported-by: Nick <vincent@systemli.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/cpufreq/mediatek-cpufreq.c | 147 +++++++++++++++++++----------
> 1 file changed, 96 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
> index 7f2680bc9a0f..4466d0c91a6a 100644
> --- a/drivers/cpufreq/mediatek-cpufreq.c
> +++ b/drivers/cpufreq/mediatek-cpufreq.c
> @@ -8,7 +8,6 @@
> #include <linux/cpu.h>
> #include <linux/cpufreq.h>
> #include <linux/cpumask.h>
> -#include <linux/minmax.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_platform.h>
> @@ -16,6 +15,8 @@
> #include <linux/pm_opp.h>
> #include <linux/regulator/consumer.h>
>
> +#define VOLT_TOL (10000)
> +
> struct mtk_cpufreq_platform_data {
> int min_volt_shift;
> int max_volt_shift;
> @@ -55,7 +56,6 @@ struct mtk_cpu_dvfs_info {
> unsigned int opp_cpu;
> unsigned long current_freq;
> const struct mtk_cpufreq_platform_data *soc_data;
> - int vtrack_max;
> bool ccifreq_bound;
> };
>
> @@ -82,7 +82,6 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> struct regulator *proc_reg = info->proc_reg;
> struct regulator *sram_reg = info->sram_reg;
> int pre_vproc, pre_vsram, new_vsram, vsram, vproc, ret;
> - int retry = info->vtrack_max;
>
> pre_vproc = regulator_get_voltage(proc_reg);
> if (pre_vproc < 0) {
> @@ -90,44 +89,91 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> "invalid Vproc value: %d\n", pre_vproc);
> return pre_vproc;
> }
> + /* Vsram should not exceed the maximum allowed voltage of SoC. */
> + new_vsram = min(new_vproc + soc_data->min_volt_shift,
> + soc_data->sram_max_volt);
> +
> + if (pre_vproc < new_vproc) {
> + /*
> + * When scaling up voltages, Vsram and Vproc scale up step
> + * by step. At each step, set Vsram to (Vproc + 200mV) first,
> + * then set Vproc to (Vsram - 100mV).
> + * Keep doing it until Vsram and Vproc hit target voltages.
> + */
> + do {
> + pre_vsram = regulator_get_voltage(sram_reg);
> + if (pre_vsram < 0) {
> + dev_err(info->cpu_dev,
> + "invalid Vsram value: %d\n", pre_vsram);
> + return pre_vsram;
> + }
> + pre_vproc = regulator_get_voltage(proc_reg);
> + if (pre_vproc < 0) {
> + dev_err(info->cpu_dev,
> + "invalid Vproc value: %d\n", pre_vproc);
> + return pre_vproc;
> + }
>
> - pre_vsram = regulator_get_voltage(sram_reg);
> - if (pre_vsram < 0) {
> - dev_err(info->cpu_dev, "invalid Vsram value: %d\n", pre_vsram);
> - return pre_vsram;
> - }
> + vsram = min(new_vsram,
> + pre_vproc + soc_data->min_volt_shift);
>
> - new_vsram = clamp(new_vproc + soc_data->min_volt_shift,
> - soc_data->sram_min_volt, soc_data->sram_max_volt);
> + if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
> + vsram = soc_data->sram_max_volt;
>
> - do {
> - if (pre_vproc <= new_vproc) {
> - vsram = clamp(pre_vproc + soc_data->max_volt_shift,
> - soc_data->sram_min_volt, new_vsram);
> - ret = regulator_set_voltage(sram_reg, vsram,
> - soc_data->sram_max_volt);
> + /*
> + * If the target Vsram hits the maximum voltage,
> + * try to set the exact voltage value first.
> + */
> + ret = regulator_set_voltage(sram_reg, vsram,
> + vsram);
> + if (ret)
> + ret = regulator_set_voltage(sram_reg,
> + vsram - VOLT_TOL,
> + vsram);
>
> - if (ret)
> - return ret;
> -
> - if (vsram == soc_data->sram_max_volt ||
> - new_vsram == soc_data->sram_min_volt)
> vproc = new_vproc;
> - else
> + } else {
> + ret = regulator_set_voltage(sram_reg, vsram,
> + vsram + VOLT_TOL);
> +
> vproc = vsram - soc_data->min_volt_shift;
> + }
> + if (ret)
> + return ret;
>
> ret = regulator_set_voltage(proc_reg, vproc,
> - soc_data->proc_max_volt);
> + vproc + VOLT_TOL);
> if (ret) {
> regulator_set_voltage(sram_reg, pre_vsram,
> - soc_data->sram_max_volt);
> + pre_vsram);
> return ret;
> }
> - } else if (pre_vproc > new_vproc) {
> + } while (vproc < new_vproc || vsram < new_vsram);
> + } else if (pre_vproc > new_vproc) {
> + /*
> + * When scaling down voltages, Vsram and Vproc scale down step
> + * by step. At each step, set Vproc to (Vsram - 200mV) first,
> + * then set Vproc to (Vproc + 100mV).
> + * Keep doing it until Vsram and Vproc hit target voltages.
> + */
> + do {
> + pre_vproc = regulator_get_voltage(proc_reg);
> + if (pre_vproc < 0) {
> + dev_err(info->cpu_dev,
> + "invalid Vproc value: %d\n", pre_vproc);
> + return pre_vproc;
> + }
> + pre_vsram = regulator_get_voltage(sram_reg);
> + if (pre_vsram < 0) {
> + dev_err(info->cpu_dev,
> + "invalid Vsram value: %d\n", pre_vsram);
> + return pre_vsram;
> + }
> +
> vproc = max(new_vproc,
> pre_vsram - soc_data->max_volt_shift);
> ret = regulator_set_voltage(proc_reg, vproc,
> - soc_data->proc_max_volt);
> + vproc + VOLT_TOL);
> if (ret)
> return ret;
>
> @@ -137,24 +183,32 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> vsram = max(new_vsram,
> vproc + soc_data->min_volt_shift);
>
> - ret = regulator_set_voltage(sram_reg, vsram,
> - soc_data->sram_max_volt);
> + if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
> + vsram = soc_data->sram_max_volt;
> +
> + /*
> + * If the target Vsram hits the maximum voltage,
> + * try to set the exact voltage value first.
> + */
> + ret = regulator_set_voltage(sram_reg, vsram,
> + vsram);
> + if (ret)
> + ret = regulator_set_voltage(sram_reg,
> + vsram - VOLT_TOL,
> + vsram);
> + } else {
> + ret = regulator_set_voltage(sram_reg, vsram,
> + vsram + VOLT_TOL);
> + }
> +
> if (ret) {
> regulator_set_voltage(proc_reg, pre_vproc,
> - soc_data->proc_max_volt);
> + pre_vproc);
> return ret;
> }
> - }
> -
> - pre_vproc = vproc;
> - pre_vsram = vsram;
> -
> - if (--retry < 0) {
> - dev_err(info->cpu_dev,
> - "over loop count, failed to set voltage\n");
> - return -EINVAL;
> - }
> - } while (vproc != new_vproc || vsram != new_vsram);
> + } while (vproc > new_vproc + VOLT_TOL ||
> + vsram > new_vsram + VOLT_TOL);
> + }
>
> return 0;
> }
> @@ -250,8 +304,8 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
> * If the new voltage or the intermediate voltage is higher than the
> * current voltage, scale up voltage first.
> */
> - target_vproc = max(inter_vproc, vproc);
> - if (pre_vproc <= target_vproc) {
> + target_vproc = (inter_vproc > vproc) ? inter_vproc : vproc;
> + if (pre_vproc < target_vproc) {
> ret = mtk_cpufreq_set_voltage(info, target_vproc);
> if (ret) {
> dev_err(cpu_dev,
> @@ -513,15 +567,6 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
> */
> info->need_voltage_tracking = (info->sram_reg != NULL);
>
> - /*
> - * We assume min voltage is 0 and tracking target voltage using
> - * min_volt_shift for each iteration.
> - * The vtrack_max is 3 times of expeted iteration count.
> - */
> - info->vtrack_max = 3 * DIV_ROUND_UP(max(info->soc_data->sram_max_volt,
> - info->soc_data->proc_max_volt),
> - info->soc_data->min_volt_shift);
> -
> return 0;
>
> out_disable_inter_clock:
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH] Revert "cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()"
@ 2022-12-02 12:47 ` Nick
0 siblings, 0 replies; 75+ messages in thread
From: Nick @ 2022-12-02 12:47 UTC (permalink / raw)
To: Viresh Kumar, Rafael J. Wysocki, Matthias Brugger
Cc: linux-pm, Vincent Guittot, regressions, daniel, thomas.huehn,
v5 . 19+,
linux-kernel, linux-arm-kernel, linux-mediatek
I tested this again on linux/master on the Banana Pi R64 (mt7622). Seems
to work fine:
https://gist.githubusercontent.com/PolynomialDivision/5022dec1874a1c411ece6c9dabec59b5/raw/7ac62b38d10e41a56ff1db3142571117ee6f4c26/mt7622-cpufreq-revert.log
So if you want you can add:
Reported-by: Nick Hainke <vincent@systemli.org>
Tested-by: Nick Hainke <vincent@systemli.org>
Bests
Nick
On 12/2/22 06:26, Viresh Kumar wrote:
> This reverts commit 6a17b3876bc8303612d7ad59ecf7cbc0db418bcd.
>
> This commit caused regression on Banana Pi R64 (MT7622), revert until
> the problem is identified and fixed properly.
>
> Link: https://lore.kernel.org/all/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
> Cc: v5.19+ <stable@vger.kernel.org> # v5.19+
> Reported-by: Nick <vincent@systemli.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/cpufreq/mediatek-cpufreq.c | 147 +++++++++++++++++++----------
> 1 file changed, 96 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
> index 7f2680bc9a0f..4466d0c91a6a 100644
> --- a/drivers/cpufreq/mediatek-cpufreq.c
> +++ b/drivers/cpufreq/mediatek-cpufreq.c
> @@ -8,7 +8,6 @@
> #include <linux/cpu.h>
> #include <linux/cpufreq.h>
> #include <linux/cpumask.h>
> -#include <linux/minmax.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_platform.h>
> @@ -16,6 +15,8 @@
> #include <linux/pm_opp.h>
> #include <linux/regulator/consumer.h>
>
> +#define VOLT_TOL (10000)
> +
> struct mtk_cpufreq_platform_data {
> int min_volt_shift;
> int max_volt_shift;
> @@ -55,7 +56,6 @@ struct mtk_cpu_dvfs_info {
> unsigned int opp_cpu;
> unsigned long current_freq;
> const struct mtk_cpufreq_platform_data *soc_data;
> - int vtrack_max;
> bool ccifreq_bound;
> };
>
> @@ -82,7 +82,6 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> struct regulator *proc_reg = info->proc_reg;
> struct regulator *sram_reg = info->sram_reg;
> int pre_vproc, pre_vsram, new_vsram, vsram, vproc, ret;
> - int retry = info->vtrack_max;
>
> pre_vproc = regulator_get_voltage(proc_reg);
> if (pre_vproc < 0) {
> @@ -90,44 +89,91 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> "invalid Vproc value: %d\n", pre_vproc);
> return pre_vproc;
> }
> + /* Vsram should not exceed the maximum allowed voltage of SoC. */
> + new_vsram = min(new_vproc + soc_data->min_volt_shift,
> + soc_data->sram_max_volt);
> +
> + if (pre_vproc < new_vproc) {
> + /*
> + * When scaling up voltages, Vsram and Vproc scale up step
> + * by step. At each step, set Vsram to (Vproc + 200mV) first,
> + * then set Vproc to (Vsram - 100mV).
> + * Keep doing it until Vsram and Vproc hit target voltages.
> + */
> + do {
> + pre_vsram = regulator_get_voltage(sram_reg);
> + if (pre_vsram < 0) {
> + dev_err(info->cpu_dev,
> + "invalid Vsram value: %d\n", pre_vsram);
> + return pre_vsram;
> + }
> + pre_vproc = regulator_get_voltage(proc_reg);
> + if (pre_vproc < 0) {
> + dev_err(info->cpu_dev,
> + "invalid Vproc value: %d\n", pre_vproc);
> + return pre_vproc;
> + }
>
> - pre_vsram = regulator_get_voltage(sram_reg);
> - if (pre_vsram < 0) {
> - dev_err(info->cpu_dev, "invalid Vsram value: %d\n", pre_vsram);
> - return pre_vsram;
> - }
> + vsram = min(new_vsram,
> + pre_vproc + soc_data->min_volt_shift);
>
> - new_vsram = clamp(new_vproc + soc_data->min_volt_shift,
> - soc_data->sram_min_volt, soc_data->sram_max_volt);
> + if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
> + vsram = soc_data->sram_max_volt;
>
> - do {
> - if (pre_vproc <= new_vproc) {
> - vsram = clamp(pre_vproc + soc_data->max_volt_shift,
> - soc_data->sram_min_volt, new_vsram);
> - ret = regulator_set_voltage(sram_reg, vsram,
> - soc_data->sram_max_volt);
> + /*
> + * If the target Vsram hits the maximum voltage,
> + * try to set the exact voltage value first.
> + */
> + ret = regulator_set_voltage(sram_reg, vsram,
> + vsram);
> + if (ret)
> + ret = regulator_set_voltage(sram_reg,
> + vsram - VOLT_TOL,
> + vsram);
>
> - if (ret)
> - return ret;
> -
> - if (vsram == soc_data->sram_max_volt ||
> - new_vsram == soc_data->sram_min_volt)
> vproc = new_vproc;
> - else
> + } else {
> + ret = regulator_set_voltage(sram_reg, vsram,
> + vsram + VOLT_TOL);
> +
> vproc = vsram - soc_data->min_volt_shift;
> + }
> + if (ret)
> + return ret;
>
> ret = regulator_set_voltage(proc_reg, vproc,
> - soc_data->proc_max_volt);
> + vproc + VOLT_TOL);
> if (ret) {
> regulator_set_voltage(sram_reg, pre_vsram,
> - soc_data->sram_max_volt);
> + pre_vsram);
> return ret;
> }
> - } else if (pre_vproc > new_vproc) {
> + } while (vproc < new_vproc || vsram < new_vsram);
> + } else if (pre_vproc > new_vproc) {
> + /*
> + * When scaling down voltages, Vsram and Vproc scale down step
> + * by step. At each step, set Vproc to (Vsram - 200mV) first,
> + * then set Vproc to (Vproc + 100mV).
> + * Keep doing it until Vsram and Vproc hit target voltages.
> + */
> + do {
> + pre_vproc = regulator_get_voltage(proc_reg);
> + if (pre_vproc < 0) {
> + dev_err(info->cpu_dev,
> + "invalid Vproc value: %d\n", pre_vproc);
> + return pre_vproc;
> + }
> + pre_vsram = regulator_get_voltage(sram_reg);
> + if (pre_vsram < 0) {
> + dev_err(info->cpu_dev,
> + "invalid Vsram value: %d\n", pre_vsram);
> + return pre_vsram;
> + }
> +
> vproc = max(new_vproc,
> pre_vsram - soc_data->max_volt_shift);
> ret = regulator_set_voltage(proc_reg, vproc,
> - soc_data->proc_max_volt);
> + vproc + VOLT_TOL);
> if (ret)
> return ret;
>
> @@ -137,24 +183,32 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> vsram = max(new_vsram,
> vproc + soc_data->min_volt_shift);
>
> - ret = regulator_set_voltage(sram_reg, vsram,
> - soc_data->sram_max_volt);
> + if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
> + vsram = soc_data->sram_max_volt;
> +
> + /*
> + * If the target Vsram hits the maximum voltage,
> + * try to set the exact voltage value first.
> + */
> + ret = regulator_set_voltage(sram_reg, vsram,
> + vsram);
> + if (ret)
> + ret = regulator_set_voltage(sram_reg,
> + vsram - VOLT_TOL,
> + vsram);
> + } else {
> + ret = regulator_set_voltage(sram_reg, vsram,
> + vsram + VOLT_TOL);
> + }
> +
> if (ret) {
> regulator_set_voltage(proc_reg, pre_vproc,
> - soc_data->proc_max_volt);
> + pre_vproc);
> return ret;
> }
> - }
> -
> - pre_vproc = vproc;
> - pre_vsram = vsram;
> -
> - if (--retry < 0) {
> - dev_err(info->cpu_dev,
> - "over loop count, failed to set voltage\n");
> - return -EINVAL;
> - }
> - } while (vproc != new_vproc || vsram != new_vsram);
> + } while (vproc > new_vproc + VOLT_TOL ||
> + vsram > new_vsram + VOLT_TOL);
> + }
>
> return 0;
> }
> @@ -250,8 +304,8 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
> * If the new voltage or the intermediate voltage is higher than the
> * current voltage, scale up voltage first.
> */
> - target_vproc = max(inter_vproc, vproc);
> - if (pre_vproc <= target_vproc) {
> + target_vproc = (inter_vproc > vproc) ? inter_vproc : vproc;
> + if (pre_vproc < target_vproc) {
> ret = mtk_cpufreq_set_voltage(info, target_vproc);
> if (ret) {
> dev_err(cpu_dev,
> @@ -513,15 +567,6 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
> */
> info->need_voltage_tracking = (info->sram_reg != NULL);
>
> - /*
> - * We assume min voltage is 0 and tracking target voltage using
> - * min_volt_shift for each iteration.
> - * The vtrack_max is 3 times of expeted iteration count.
> - */
> - info->vtrack_max = 3 * DIV_ROUND_UP(max(info->soc_data->sram_max_volt,
> - info->soc_data->proc_max_volt),
> - info->soc_data->min_volt_shift);
> -
> return 0;
>
> out_disable_inter_clock:
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH] Revert "cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()"
2022-12-02 12:17 ` Rafael J. Wysocki
@ 2022-12-02 19:46 ` Rafael J. Wysocki
-1 siblings, 0 replies; 75+ messages in thread
From: Rafael J. Wysocki @ 2022-12-02 19:46 UTC (permalink / raw)
To: Viresh Kumar
Cc: Matthias Brugger, linux-pm, Vincent Guittot, regressions, daniel,
thomas.huehn, v5 . 19+,
Nick, linux-kernel, linux-arm-kernel, linux-mediatek
On Fri, Dec 2, 2022 at 1:17 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Fri, Dec 2, 2022 at 6:26 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> >
> > This reverts commit 6a17b3876bc8303612d7ad59ecf7cbc0db418bcd.
> >
> > This commit caused regression on Banana Pi R64 (MT7622), revert until
> > the problem is identified and fixed properly.
> >
> > Link: https://lore.kernel.org/all/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
> > Cc: v5.19+ <stable@vger.kernel.org> # v5.19+
> > Reported-by: Nick <vincent@systemli.org>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> Do you want me to push this revert for -rc8?
After all, I've decided to queue it up for 6.2, thanks!
> > ---
> > drivers/cpufreq/mediatek-cpufreq.c | 147 +++++++++++++++++++----------
> > 1 file changed, 96 insertions(+), 51 deletions(-)
> >
> > diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
> > index 7f2680bc9a0f..4466d0c91a6a 100644
> > --- a/drivers/cpufreq/mediatek-cpufreq.c
> > +++ b/drivers/cpufreq/mediatek-cpufreq.c
> > @@ -8,7 +8,6 @@
> > #include <linux/cpu.h>
> > #include <linux/cpufreq.h>
> > #include <linux/cpumask.h>
> > -#include <linux/minmax.h>
> > #include <linux/module.h>
> > #include <linux/of.h>
> > #include <linux/of_platform.h>
> > @@ -16,6 +15,8 @@
> > #include <linux/pm_opp.h>
> > #include <linux/regulator/consumer.h>
> >
> > +#define VOLT_TOL (10000)
> > +
> > struct mtk_cpufreq_platform_data {
> > int min_volt_shift;
> > int max_volt_shift;
> > @@ -55,7 +56,6 @@ struct mtk_cpu_dvfs_info {
> > unsigned int opp_cpu;
> > unsigned long current_freq;
> > const struct mtk_cpufreq_platform_data *soc_data;
> > - int vtrack_max;
> > bool ccifreq_bound;
> > };
> >
> > @@ -82,7 +82,6 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> > struct regulator *proc_reg = info->proc_reg;
> > struct regulator *sram_reg = info->sram_reg;
> > int pre_vproc, pre_vsram, new_vsram, vsram, vproc, ret;
> > - int retry = info->vtrack_max;
> >
> > pre_vproc = regulator_get_voltage(proc_reg);
> > if (pre_vproc < 0) {
> > @@ -90,44 +89,91 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> > "invalid Vproc value: %d\n", pre_vproc);
> > return pre_vproc;
> > }
> > + /* Vsram should not exceed the maximum allowed voltage of SoC. */
> > + new_vsram = min(new_vproc + soc_data->min_volt_shift,
> > + soc_data->sram_max_volt);
> > +
> > + if (pre_vproc < new_vproc) {
> > + /*
> > + * When scaling up voltages, Vsram and Vproc scale up step
> > + * by step. At each step, set Vsram to (Vproc + 200mV) first,
> > + * then set Vproc to (Vsram - 100mV).
> > + * Keep doing it until Vsram and Vproc hit target voltages.
> > + */
> > + do {
> > + pre_vsram = regulator_get_voltage(sram_reg);
> > + if (pre_vsram < 0) {
> > + dev_err(info->cpu_dev,
> > + "invalid Vsram value: %d\n", pre_vsram);
> > + return pre_vsram;
> > + }
> > + pre_vproc = regulator_get_voltage(proc_reg);
> > + if (pre_vproc < 0) {
> > + dev_err(info->cpu_dev,
> > + "invalid Vproc value: %d\n", pre_vproc);
> > + return pre_vproc;
> > + }
> >
> > - pre_vsram = regulator_get_voltage(sram_reg);
> > - if (pre_vsram < 0) {
> > - dev_err(info->cpu_dev, "invalid Vsram value: %d\n", pre_vsram);
> > - return pre_vsram;
> > - }
> > + vsram = min(new_vsram,
> > + pre_vproc + soc_data->min_volt_shift);
> >
> > - new_vsram = clamp(new_vproc + soc_data->min_volt_shift,
> > - soc_data->sram_min_volt, soc_data->sram_max_volt);
> > + if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
> > + vsram = soc_data->sram_max_volt;
> >
> > - do {
> > - if (pre_vproc <= new_vproc) {
> > - vsram = clamp(pre_vproc + soc_data->max_volt_shift,
> > - soc_data->sram_min_volt, new_vsram);
> > - ret = regulator_set_voltage(sram_reg, vsram,
> > - soc_data->sram_max_volt);
> > + /*
> > + * If the target Vsram hits the maximum voltage,
> > + * try to set the exact voltage value first.
> > + */
> > + ret = regulator_set_voltage(sram_reg, vsram,
> > + vsram);
> > + if (ret)
> > + ret = regulator_set_voltage(sram_reg,
> > + vsram - VOLT_TOL,
> > + vsram);
> >
> > - if (ret)
> > - return ret;
> > -
> > - if (vsram == soc_data->sram_max_volt ||
> > - new_vsram == soc_data->sram_min_volt)
> > vproc = new_vproc;
> > - else
> > + } else {
> > + ret = regulator_set_voltage(sram_reg, vsram,
> > + vsram + VOLT_TOL);
> > +
> > vproc = vsram - soc_data->min_volt_shift;
> > + }
> > + if (ret)
> > + return ret;
> >
> > ret = regulator_set_voltage(proc_reg, vproc,
> > - soc_data->proc_max_volt);
> > + vproc + VOLT_TOL);
> > if (ret) {
> > regulator_set_voltage(sram_reg, pre_vsram,
> > - soc_data->sram_max_volt);
> > + pre_vsram);
> > return ret;
> > }
> > - } else if (pre_vproc > new_vproc) {
> > + } while (vproc < new_vproc || vsram < new_vsram);
> > + } else if (pre_vproc > new_vproc) {
> > + /*
> > + * When scaling down voltages, Vsram and Vproc scale down step
> > + * by step. At each step, set Vproc to (Vsram - 200mV) first,
> > + * then set Vproc to (Vproc + 100mV).
> > + * Keep doing it until Vsram and Vproc hit target voltages.
> > + */
> > + do {
> > + pre_vproc = regulator_get_voltage(proc_reg);
> > + if (pre_vproc < 0) {
> > + dev_err(info->cpu_dev,
> > + "invalid Vproc value: %d\n", pre_vproc);
> > + return pre_vproc;
> > + }
> > + pre_vsram = regulator_get_voltage(sram_reg);
> > + if (pre_vsram < 0) {
> > + dev_err(info->cpu_dev,
> > + "invalid Vsram value: %d\n", pre_vsram);
> > + return pre_vsram;
> > + }
> > +
> > vproc = max(new_vproc,
> > pre_vsram - soc_data->max_volt_shift);
> > ret = regulator_set_voltage(proc_reg, vproc,
> > - soc_data->proc_max_volt);
> > + vproc + VOLT_TOL);
> > if (ret)
> > return ret;
> >
> > @@ -137,24 +183,32 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> > vsram = max(new_vsram,
> > vproc + soc_data->min_volt_shift);
> >
> > - ret = regulator_set_voltage(sram_reg, vsram,
> > - soc_data->sram_max_volt);
> > + if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
> > + vsram = soc_data->sram_max_volt;
> > +
> > + /*
> > + * If the target Vsram hits the maximum voltage,
> > + * try to set the exact voltage value first.
> > + */
> > + ret = regulator_set_voltage(sram_reg, vsram,
> > + vsram);
> > + if (ret)
> > + ret = regulator_set_voltage(sram_reg,
> > + vsram - VOLT_TOL,
> > + vsram);
> > + } else {
> > + ret = regulator_set_voltage(sram_reg, vsram,
> > + vsram + VOLT_TOL);
> > + }
> > +
> > if (ret) {
> > regulator_set_voltage(proc_reg, pre_vproc,
> > - soc_data->proc_max_volt);
> > + pre_vproc);
> > return ret;
> > }
> > - }
> > -
> > - pre_vproc = vproc;
> > - pre_vsram = vsram;
> > -
> > - if (--retry < 0) {
> > - dev_err(info->cpu_dev,
> > - "over loop count, failed to set voltage\n");
> > - return -EINVAL;
> > - }
> > - } while (vproc != new_vproc || vsram != new_vsram);
> > + } while (vproc > new_vproc + VOLT_TOL ||
> > + vsram > new_vsram + VOLT_TOL);
> > + }
> >
> > return 0;
> > }
> > @@ -250,8 +304,8 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
> > * If the new voltage or the intermediate voltage is higher than the
> > * current voltage, scale up voltage first.
> > */
> > - target_vproc = max(inter_vproc, vproc);
> > - if (pre_vproc <= target_vproc) {
> > + target_vproc = (inter_vproc > vproc) ? inter_vproc : vproc;
> > + if (pre_vproc < target_vproc) {
> > ret = mtk_cpufreq_set_voltage(info, target_vproc);
> > if (ret) {
> > dev_err(cpu_dev,
> > @@ -513,15 +567,6 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
> > */
> > info->need_voltage_tracking = (info->sram_reg != NULL);
> >
> > - /*
> > - * We assume min voltage is 0 and tracking target voltage using
> > - * min_volt_shift for each iteration.
> > - * The vtrack_max is 3 times of expeted iteration count.
> > - */
> > - info->vtrack_max = 3 * DIV_ROUND_UP(max(info->soc_data->sram_max_volt,
> > - info->soc_data->proc_max_volt),
> > - info->soc_data->min_volt_shift);
> > -
> > return 0;
> >
> > out_disable_inter_clock:
> > --
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH] Revert "cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()"
@ 2022-12-02 19:46 ` Rafael J. Wysocki
0 siblings, 0 replies; 75+ messages in thread
From: Rafael J. Wysocki @ 2022-12-02 19:46 UTC (permalink / raw)
To: Viresh Kumar
Cc: Matthias Brugger, linux-pm, Vincent Guittot, regressions, daniel,
thomas.huehn, v5 . 19+,
Nick, linux-kernel, linux-arm-kernel, linux-mediatek
On Fri, Dec 2, 2022 at 1:17 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Fri, Dec 2, 2022 at 6:26 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> >
> > This reverts commit 6a17b3876bc8303612d7ad59ecf7cbc0db418bcd.
> >
> > This commit caused regression on Banana Pi R64 (MT7622), revert until
> > the problem is identified and fixed properly.
> >
> > Link: https://lore.kernel.org/all/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
> > Cc: v5.19+ <stable@vger.kernel.org> # v5.19+
> > Reported-by: Nick <vincent@systemli.org>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> Do you want me to push this revert for -rc8?
After all, I've decided to queue it up for 6.2, thanks!
> > ---
> > drivers/cpufreq/mediatek-cpufreq.c | 147 +++++++++++++++++++----------
> > 1 file changed, 96 insertions(+), 51 deletions(-)
> >
> > diff --git a/drivers/cpufreq/mediatek-cpufreq.c b/drivers/cpufreq/mediatek-cpufreq.c
> > index 7f2680bc9a0f..4466d0c91a6a 100644
> > --- a/drivers/cpufreq/mediatek-cpufreq.c
> > +++ b/drivers/cpufreq/mediatek-cpufreq.c
> > @@ -8,7 +8,6 @@
> > #include <linux/cpu.h>
> > #include <linux/cpufreq.h>
> > #include <linux/cpumask.h>
> > -#include <linux/minmax.h>
> > #include <linux/module.h>
> > #include <linux/of.h>
> > #include <linux/of_platform.h>
> > @@ -16,6 +15,8 @@
> > #include <linux/pm_opp.h>
> > #include <linux/regulator/consumer.h>
> >
> > +#define VOLT_TOL (10000)
> > +
> > struct mtk_cpufreq_platform_data {
> > int min_volt_shift;
> > int max_volt_shift;
> > @@ -55,7 +56,6 @@ struct mtk_cpu_dvfs_info {
> > unsigned int opp_cpu;
> > unsigned long current_freq;
> > const struct mtk_cpufreq_platform_data *soc_data;
> > - int vtrack_max;
> > bool ccifreq_bound;
> > };
> >
> > @@ -82,7 +82,6 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> > struct regulator *proc_reg = info->proc_reg;
> > struct regulator *sram_reg = info->sram_reg;
> > int pre_vproc, pre_vsram, new_vsram, vsram, vproc, ret;
> > - int retry = info->vtrack_max;
> >
> > pre_vproc = regulator_get_voltage(proc_reg);
> > if (pre_vproc < 0) {
> > @@ -90,44 +89,91 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> > "invalid Vproc value: %d\n", pre_vproc);
> > return pre_vproc;
> > }
> > + /* Vsram should not exceed the maximum allowed voltage of SoC. */
> > + new_vsram = min(new_vproc + soc_data->min_volt_shift,
> > + soc_data->sram_max_volt);
> > +
> > + if (pre_vproc < new_vproc) {
> > + /*
> > + * When scaling up voltages, Vsram and Vproc scale up step
> > + * by step. At each step, set Vsram to (Vproc + 200mV) first,
> > + * then set Vproc to (Vsram - 100mV).
> > + * Keep doing it until Vsram and Vproc hit target voltages.
> > + */
> > + do {
> > + pre_vsram = regulator_get_voltage(sram_reg);
> > + if (pre_vsram < 0) {
> > + dev_err(info->cpu_dev,
> > + "invalid Vsram value: %d\n", pre_vsram);
> > + return pre_vsram;
> > + }
> > + pre_vproc = regulator_get_voltage(proc_reg);
> > + if (pre_vproc < 0) {
> > + dev_err(info->cpu_dev,
> > + "invalid Vproc value: %d\n", pre_vproc);
> > + return pre_vproc;
> > + }
> >
> > - pre_vsram = regulator_get_voltage(sram_reg);
> > - if (pre_vsram < 0) {
> > - dev_err(info->cpu_dev, "invalid Vsram value: %d\n", pre_vsram);
> > - return pre_vsram;
> > - }
> > + vsram = min(new_vsram,
> > + pre_vproc + soc_data->min_volt_shift);
> >
> > - new_vsram = clamp(new_vproc + soc_data->min_volt_shift,
> > - soc_data->sram_min_volt, soc_data->sram_max_volt);
> > + if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
> > + vsram = soc_data->sram_max_volt;
> >
> > - do {
> > - if (pre_vproc <= new_vproc) {
> > - vsram = clamp(pre_vproc + soc_data->max_volt_shift,
> > - soc_data->sram_min_volt, new_vsram);
> > - ret = regulator_set_voltage(sram_reg, vsram,
> > - soc_data->sram_max_volt);
> > + /*
> > + * If the target Vsram hits the maximum voltage,
> > + * try to set the exact voltage value first.
> > + */
> > + ret = regulator_set_voltage(sram_reg, vsram,
> > + vsram);
> > + if (ret)
> > + ret = regulator_set_voltage(sram_reg,
> > + vsram - VOLT_TOL,
> > + vsram);
> >
> > - if (ret)
> > - return ret;
> > -
> > - if (vsram == soc_data->sram_max_volt ||
> > - new_vsram == soc_data->sram_min_volt)
> > vproc = new_vproc;
> > - else
> > + } else {
> > + ret = regulator_set_voltage(sram_reg, vsram,
> > + vsram + VOLT_TOL);
> > +
> > vproc = vsram - soc_data->min_volt_shift;
> > + }
> > + if (ret)
> > + return ret;
> >
> > ret = regulator_set_voltage(proc_reg, vproc,
> > - soc_data->proc_max_volt);
> > + vproc + VOLT_TOL);
> > if (ret) {
> > regulator_set_voltage(sram_reg, pre_vsram,
> > - soc_data->sram_max_volt);
> > + pre_vsram);
> > return ret;
> > }
> > - } else if (pre_vproc > new_vproc) {
> > + } while (vproc < new_vproc || vsram < new_vsram);
> > + } else if (pre_vproc > new_vproc) {
> > + /*
> > + * When scaling down voltages, Vsram and Vproc scale down step
> > + * by step. At each step, set Vproc to (Vsram - 200mV) first,
> > + * then set Vproc to (Vproc + 100mV).
> > + * Keep doing it until Vsram and Vproc hit target voltages.
> > + */
> > + do {
> > + pre_vproc = regulator_get_voltage(proc_reg);
> > + if (pre_vproc < 0) {
> > + dev_err(info->cpu_dev,
> > + "invalid Vproc value: %d\n", pre_vproc);
> > + return pre_vproc;
> > + }
> > + pre_vsram = regulator_get_voltage(sram_reg);
> > + if (pre_vsram < 0) {
> > + dev_err(info->cpu_dev,
> > + "invalid Vsram value: %d\n", pre_vsram);
> > + return pre_vsram;
> > + }
> > +
> > vproc = max(new_vproc,
> > pre_vsram - soc_data->max_volt_shift);
> > ret = regulator_set_voltage(proc_reg, vproc,
> > - soc_data->proc_max_volt);
> > + vproc + VOLT_TOL);
> > if (ret)
> > return ret;
> >
> > @@ -137,24 +183,32 @@ static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
> > vsram = max(new_vsram,
> > vproc + soc_data->min_volt_shift);
> >
> > - ret = regulator_set_voltage(sram_reg, vsram,
> > - soc_data->sram_max_volt);
> > + if (vsram + VOLT_TOL >= soc_data->sram_max_volt) {
> > + vsram = soc_data->sram_max_volt;
> > +
> > + /*
> > + * If the target Vsram hits the maximum voltage,
> > + * try to set the exact voltage value first.
> > + */
> > + ret = regulator_set_voltage(sram_reg, vsram,
> > + vsram);
> > + if (ret)
> > + ret = regulator_set_voltage(sram_reg,
> > + vsram - VOLT_TOL,
> > + vsram);
> > + } else {
> > + ret = regulator_set_voltage(sram_reg, vsram,
> > + vsram + VOLT_TOL);
> > + }
> > +
> > if (ret) {
> > regulator_set_voltage(proc_reg, pre_vproc,
> > - soc_data->proc_max_volt);
> > + pre_vproc);
> > return ret;
> > }
> > - }
> > -
> > - pre_vproc = vproc;
> > - pre_vsram = vsram;
> > -
> > - if (--retry < 0) {
> > - dev_err(info->cpu_dev,
> > - "over loop count, failed to set voltage\n");
> > - return -EINVAL;
> > - }
> > - } while (vproc != new_vproc || vsram != new_vsram);
> > + } while (vproc > new_vproc + VOLT_TOL ||
> > + vsram > new_vsram + VOLT_TOL);
> > + }
> >
> > return 0;
> > }
> > @@ -250,8 +304,8 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
> > * If the new voltage or the intermediate voltage is higher than the
> > * current voltage, scale up voltage first.
> > */
> > - target_vproc = max(inter_vproc, vproc);
> > - if (pre_vproc <= target_vproc) {
> > + target_vproc = (inter_vproc > vproc) ? inter_vproc : vproc;
> > + if (pre_vproc < target_vproc) {
> > ret = mtk_cpufreq_set_voltage(info, target_vproc);
> > if (ret) {
> > dev_err(cpu_dev,
> > @@ -513,15 +567,6 @@ static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
> > */
> > info->need_voltage_tracking = (info->sram_reg != NULL);
> >
> > - /*
> > - * We assume min voltage is 0 and tracking target voltage using
> > - * min_volt_shift for each iteration.
> > - * The vtrack_max is 3 times of expeted iteration count.
> > - */
> > - info->vtrack_max = 3 * DIV_ROUND_UP(max(info->soc_data->sram_max_volt,
> > - info->soc_data->proc_max_volt),
> > - info->soc_data->min_volt_shift);
> > -
> > return 0;
> >
> > out_disable_inter_clock:
> > --
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH] Revert "cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()"
2022-12-02 19:46 ` Rafael J. Wysocki
@ 2022-12-05 4:30 ` Viresh Kumar
-1 siblings, 0 replies; 75+ messages in thread
From: Viresh Kumar @ 2022-12-05 4:30 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Matthias Brugger, linux-pm, Vincent Guittot, regressions, daniel,
thomas.huehn, v5 . 19+,
Nick, linux-kernel, linux-arm-kernel, linux-mediatek
On 02-12-22, 20:46, Rafael J. Wysocki wrote:
> On Fri, Dec 2, 2022 at 1:17 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Fri, Dec 2, 2022 at 6:26 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > >
> > > This reverts commit 6a17b3876bc8303612d7ad59ecf7cbc0db418bcd.
> > >
> > > This commit caused regression on Banana Pi R64 (MT7622), revert until
> > > the problem is identified and fixed properly.
> > >
> > > Link: https://lore.kernel.org/all/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
> > > Cc: v5.19+ <stable@vger.kernel.org> # v5.19+
> > > Reported-by: Nick <vincent@systemli.org>
> > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> >
> > Do you want me to push this revert for -rc8?
No, I was planning to make it part of my pull request.
> After all, I've decided to queue it up for 6.2, thanks!
Can you please drop that ? AngeloGioacchino already reported that
Reverting the proposed commit will make MT8183 unstable.
So the right thing to do now is apply the fix, which is on the list
and getting tested.
--
viresh
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH] Revert "cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()"
@ 2022-12-05 4:30 ` Viresh Kumar
0 siblings, 0 replies; 75+ messages in thread
From: Viresh Kumar @ 2022-12-05 4:30 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Matthias Brugger, linux-pm, Vincent Guittot, regressions, daniel,
thomas.huehn, v5 . 19+,
Nick, linux-kernel, linux-arm-kernel, linux-mediatek
On 02-12-22, 20:46, Rafael J. Wysocki wrote:
> On Fri, Dec 2, 2022 at 1:17 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Fri, Dec 2, 2022 at 6:26 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > >
> > > This reverts commit 6a17b3876bc8303612d7ad59ecf7cbc0db418bcd.
> > >
> > > This commit caused regression on Banana Pi R64 (MT7622), revert until
> > > the problem is identified and fixed properly.
> > >
> > > Link: https://lore.kernel.org/all/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
> > > Cc: v5.19+ <stable@vger.kernel.org> # v5.19+
> > > Reported-by: Nick <vincent@systemli.org>
> > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> >
> > Do you want me to push this revert for -rc8?
No, I was planning to make it part of my pull request.
> After all, I've decided to queue it up for 6.2, thanks!
Can you please drop that ? AngeloGioacchino already reported that
Reverting the proposed commit will make MT8183 unstable.
So the right thing to do now is apply the fix, which is on the list
and getting tested.
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH] Revert "cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()"
2022-12-05 4:30 ` Viresh Kumar
@ 2022-12-05 12:08 ` Rafael J. Wysocki
-1 siblings, 0 replies; 75+ messages in thread
From: Rafael J. Wysocki @ 2022-12-05 12:08 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael J. Wysocki, Matthias Brugger, linux-pm, Vincent Guittot,
regressions, daniel, thomas.huehn, v5 . 19+,
Nick, linux-kernel, linux-arm-kernel, linux-mediatek
On Mon, Dec 5, 2022 at 5:30 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 02-12-22, 20:46, Rafael J. Wysocki wrote:
> > On Fri, Dec 2, 2022 at 1:17 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > >
> > > On Fri, Dec 2, 2022 at 6:26 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > > >
> > > > This reverts commit 6a17b3876bc8303612d7ad59ecf7cbc0db418bcd.
> > > >
> > > > This commit caused regression on Banana Pi R64 (MT7622), revert until
> > > > the problem is identified and fixed properly.
> > > >
> > > > Link: https://lore.kernel.org/all/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
> > > > Cc: v5.19+ <stable@vger.kernel.org> # v5.19+
> > > > Reported-by: Nick <vincent@systemli.org>
> > > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > >
> > > Do you want me to push this revert for -rc8?
>
> No, I was planning to make it part of my pull request.
Well, this was a bit unclear.
> > After all, I've decided to queue it up for 6.2, thanks!
>
> Can you please drop that ? AngeloGioacchino already reported that
> Reverting the proposed commit will make MT8183 unstable.
OK, dropped now.
> So the right thing to do now is apply the fix, which is on the list
> and getting tested.
Alright then, I'll assume that the proper fix will come in through
your pull request for 6.2 (but please send that one before the merge
window opens), thanks!
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH] Revert "cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()"
@ 2022-12-05 12:08 ` Rafael J. Wysocki
0 siblings, 0 replies; 75+ messages in thread
From: Rafael J. Wysocki @ 2022-12-05 12:08 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael J. Wysocki, Matthias Brugger, linux-pm, Vincent Guittot,
regressions, daniel, thomas.huehn, v5 . 19+,
Nick, linux-kernel, linux-arm-kernel, linux-mediatek
On Mon, Dec 5, 2022 at 5:30 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 02-12-22, 20:46, Rafael J. Wysocki wrote:
> > On Fri, Dec 2, 2022 at 1:17 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > >
> > > On Fri, Dec 2, 2022 at 6:26 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > > >
> > > > This reverts commit 6a17b3876bc8303612d7ad59ecf7cbc0db418bcd.
> > > >
> > > > This commit caused regression on Banana Pi R64 (MT7622), revert until
> > > > the problem is identified and fixed properly.
> > > >
> > > > Link: https://lore.kernel.org/all/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/
> > > > Cc: v5.19+ <stable@vger.kernel.org> # v5.19+
> > > > Reported-by: Nick <vincent@systemli.org>
> > > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > >
> > > Do you want me to push this revert for -rc8?
>
> No, I was planning to make it part of my pull request.
Well, this was a bit unclear.
> > After all, I've decided to queue it up for 6.2, thanks!
>
> Can you please drop that ? AngeloGioacchino already reported that
> Reverting the proposed commit will make MT8183 unstable.
OK, dropped now.
> So the right thing to do now is apply the fix, which is on the list
> and getting tested.
Alright then, I'll assume that the proper fix will come in through
your pull request for 6.2 (but please send that one before the merge
window opens), thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH] Revert "cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()"
2022-12-05 12:08 ` Rafael J. Wysocki
@ 2022-12-05 23:30 ` Viresh Kumar
-1 siblings, 0 replies; 75+ messages in thread
From: Viresh Kumar @ 2022-12-05 23:30 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Matthias Brugger, linux-pm, Vincent Guittot, regressions, daniel,
thomas.huehn, v5 . 19+,
Nick, linux-kernel, linux-arm-kernel, linux-mediatek
On 05-12-22, 13:08, Rafael J. Wysocki wrote:
> Well, this was a bit unclear.
Hmm, yeah. I assumed that the arm stuff will go via my tree and you
will be in sync with this. But yeah, a comment in the patch won't have
hurt.
> Alright then, I'll assume that the proper fix will come in through
> your pull request for 6.2 (but please send that one before the merge
> window opens), thanks!
I was ready with pull request since several days, was just waiting for
this to get sorted out. And I think this may get delayed a bit too, so
I better send the first pull request now and worry about this later.
--
viresh
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH] Revert "cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()"
@ 2022-12-05 23:30 ` Viresh Kumar
0 siblings, 0 replies; 75+ messages in thread
From: Viresh Kumar @ 2022-12-05 23:30 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Matthias Brugger, linux-pm, Vincent Guittot, regressions, daniel,
thomas.huehn, v5 . 19+,
Nick, linux-kernel, linux-arm-kernel, linux-mediatek
On 05-12-22, 13:08, Rafael J. Wysocki wrote:
> Well, this was a bit unclear.
Hmm, yeah. I assumed that the arm stuff will go via my tree and you
will be in sync with this. But yeah, a comment in the patch won't have
hurt.
> Alright then, I'll assume that the proper fix will come in through
> your pull request for 6.2 (but please send that one before the merge
> window opens), thanks!
I was ready with pull request since several days, was just waiting for
this to get sorted out. And I think this may get delayed a bit too, so
I better send the first pull request now and worry about this later.
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-12-02 11:01 ` Viresh Kumar
(?)
@ 2022-12-07 15:34 ` Nick
-1 siblings, 0 replies; 75+ messages in thread
From: Nick @ 2022-12-07 15:34 UTC (permalink / raw)
To: Viresh Kumar, AngeloGioacchino Del Regno
Cc: Thorsten Leemhuis, Allen-KH Cheng (程冠勳),
linux-mediatek, regressions, linux-pm, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
Did something changed on master? I compiled now the image I use on the
BPI-R64 a bit differently.
I used the openwrt toolchain "aarch64-openwrt-linux-musl-" to
cross-compile the original linux repository on current master. Than I
compiled with OpenWrt-Buildsystem a initramfs, put that together with
mkimage to a "itb" and booted it. Suddenly it works:
https://gist.githubusercontent.com/PolynomialDivision/5e49529206ba5d273bf6a416c42c6234/raw/7ecff7be397a6e9a41ef120c3fa61060c488cf5b/mt7622-bpi-vanilla
Bests
Nick
On 12/2/22 12:01, Viresh Kumar wrote:
> On 02-12-22, 12:00, AngeloGioacchino Del Regno wrote:
>> If Viresh can add those while applying the patch, that's fine for me - otherwise
>> I can send a v2 adding the two suggested missing tags.
> Sure, no problem.
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-07 15:34 ` Nick
0 siblings, 0 replies; 75+ messages in thread
From: Nick @ 2022-12-07 15:34 UTC (permalink / raw)
To: Viresh Kumar, AngeloGioacchino Del Regno
Cc: Allen-KH Cheng (程冠勳),
linux-pm, daniel, Project_Global_Chrome_Upstream_Group,
Rex-BC Chen (陳柏辰),
Thorsten Leemhuis, linux-mediatek, matthias.bgg, thomas.huehn,
Jia-wei Chang (張佳偉),
linux-arm-kernel, regressions
Did something changed on master? I compiled now the image I use on the
BPI-R64 a bit differently.
I used the openwrt toolchain "aarch64-openwrt-linux-musl-" to
cross-compile the original linux repository on current master. Than I
compiled with OpenWrt-Buildsystem a initramfs, put that together with
mkimage to a "itb" and booted it. Suddenly it works:
https://gist.githubusercontent.com/PolynomialDivision/5e49529206ba5d273bf6a416c42c6234/raw/7ecff7be397a6e9a41ef120c3fa61060c488cf5b/mt7622-bpi-vanilla
Bests
Nick
On 12/2/22 12:01, Viresh Kumar wrote:
> On 02-12-22, 12:00, AngeloGioacchino Del Regno wrote:
>> If Viresh can add those while applying the patch, that's fine for me - otherwise
>> I can send a v2 adding the two suggested missing tags.
> Sure, no problem.
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-07 15:34 ` Nick
0 siblings, 0 replies; 75+ messages in thread
From: Nick @ 2022-12-07 15:34 UTC (permalink / raw)
To: Viresh Kumar, AngeloGioacchino Del Regno
Cc: Thorsten Leemhuis, Allen-KH Cheng (程冠勳),
linux-mediatek, regressions, linux-pm, frank-w,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, Jia-wei Chang (張佳偉),
Rex-BC Chen (陳柏辰),
thomas.huehn, daniel
Did something changed on master? I compiled now the image I use on the
BPI-R64 a bit differently.
I used the openwrt toolchain "aarch64-openwrt-linux-musl-" to
cross-compile the original linux repository on current master. Than I
compiled with OpenWrt-Buildsystem a initramfs, put that together with
mkimage to a "itb" and booted it. Suddenly it works:
https://gist.githubusercontent.com/PolynomialDivision/5e49529206ba5d273bf6a416c42c6234/raw/7ecff7be397a6e9a41ef120c3fa61060c488cf5b/mt7622-bpi-vanilla
Bests
Nick
On 12/2/22 12:01, Viresh Kumar wrote:
> On 02-12-22, 12:00, AngeloGioacchino Del Regno wrote:
>> If Viresh can add those while applying the patch, that's fine for me - otherwise
>> I can send a v2 adding the two suggested missing tags.
> Sure, no problem.
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* RE: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-12-07 15:34 ` Nick
@ 2022-12-19 12:21 ` Allen-KH Cheng (程冠勳)
-1 siblings, 0 replies; 75+ messages in thread
From: Allen-KH Cheng (程冠勳) @ 2022-12-19 12:21 UTC (permalink / raw)
To: viresh.kumar, angelogioacchino.delregno, vincent
Cc: linux-mediatek, linux-pm, regressions, regressions,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, daniel, Rex-BC Chen (陳柏辰),
thomas.huehn, Jia-wei Chang (張佳偉)
Hi Nick,
This issue doesn't seem to be going to happen.
Is there anything else we need help confirming?
Thanks,
Allen
-----Original Message-----
From: Linux-mediatek <linux-mediatek-bounces@lists.infradead.org> On
Behalf Of Nick
Sent: Wednesday, December 7, 2022 11:35 PM
To: Viresh Kumar <viresh.kumar@linaro.org>; AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>
Cc: Allen-KH Cheng (程冠勳) <Allen-KH.Cheng@mediatek.com>;
linux-pm@vger.kernel.org; daniel@makrotopia.org;
Project_Global_Chrome_Upstream_Group <
Project_Global_Chrome_Upstream_Group@mediatek.com>; Rex-BC Chen (陳柏辰) <
Rex-BC.Chen@mediatek.com>; Thorsten Leemhuis <regressions@leemhuis.info
>; linux-mediatek@lists.infradead.org; matthias.bgg@gmail.com;
thomas.huehn@hs-nordhausen.de; Jia-wei Chang (張佳偉) <
Jia-wei.Chang@mediatek.com>; linux-arm-kernel@lists.infradead.org;
regressions@lists.linux.dev
Subject: Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine
mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
Did something changed on master? I compiled now the image I use on the
BPI-R64 a bit differently.
I used the openwrt toolchain "aarch64-openwrt-linux-musl-" to cross-
compile the original linux repository on current master. Than I
compiled with OpenWrt-Buildsystem a initramfs, put that together with
mkimage to a "itb" and booted it. Suddenly it works:
https://urldefense.com/v3/__https://gist.githubusercontent.com/PolynomialDivision/5e49529206ba5d273bf6a416c42c6234/raw/7ecff7be397a6e9a41ef120c3fa61060c488cf5b/mt7622-bpi-vanilla__;!!CTRNKA9wMg0ARbw!glNhziJx8pjvVsVoRm0LO8wshXJL_b2P_jYV5vO_9uhe1EnbMpWRnIEcj_561Ijxurd8C-Fjc7uCbBNIM_E-7YYc$
Bests
Nick
On 12/2/22 12:01, Viresh Kumar wrote:
> On 02-12-22, 12:00, AngeloGioacchino Del Regno wrote:
> > If Viresh can add those while applying the patch, that's fine for
> > me
> > - otherwise I can send a v2 adding the two suggested missing tags.
>
> Sure, no problem.
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* RE: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-19 12:21 ` Allen-KH Cheng (程冠勳)
0 siblings, 0 replies; 75+ messages in thread
From: Allen-KH Cheng (程冠勳) @ 2022-12-19 12:21 UTC (permalink / raw)
To: viresh.kumar, angelogioacchino.delregno, vincent
Cc: linux-mediatek, linux-pm, regressions, regressions,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, daniel, Rex-BC Chen (陳柏辰),
thomas.huehn, Jia-wei Chang (張佳偉)
Hi Nick,
This issue doesn't seem to be going to happen.
Is there anything else we need help confirming?
Thanks,
Allen
-----Original Message-----
From: Linux-mediatek <linux-mediatek-bounces@lists.infradead.org> On
Behalf Of Nick
Sent: Wednesday, December 7, 2022 11:35 PM
To: Viresh Kumar <viresh.kumar@linaro.org>; AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>
Cc: Allen-KH Cheng (程冠勳) <Allen-KH.Cheng@mediatek.com>;
linux-pm@vger.kernel.org; daniel@makrotopia.org;
Project_Global_Chrome_Upstream_Group <
Project_Global_Chrome_Upstream_Group@mediatek.com>; Rex-BC Chen (陳柏辰) <
Rex-BC.Chen@mediatek.com>; Thorsten Leemhuis <regressions@leemhuis.info
>; linux-mediatek@lists.infradead.org; matthias.bgg@gmail.com;
thomas.huehn@hs-nordhausen.de; Jia-wei Chang (張佳偉) <
Jia-wei.Chang@mediatek.com>; linux-arm-kernel@lists.infradead.org;
regressions@lists.linux.dev
Subject: Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine
mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
Did something changed on master? I compiled now the image I use on the
BPI-R64 a bit differently.
I used the openwrt toolchain "aarch64-openwrt-linux-musl-" to cross-
compile the original linux repository on current master. Than I
compiled with OpenWrt-Buildsystem a initramfs, put that together with
mkimage to a "itb" and booted it. Suddenly it works:
https://urldefense.com/v3/__https://gist.githubusercontent.com/PolynomialDivision/5e49529206ba5d273bf6a416c42c6234/raw/7ecff7be397a6e9a41ef120c3fa61060c488cf5b/mt7622-bpi-vanilla__;!!CTRNKA9wMg0ARbw!glNhziJx8pjvVsVoRm0LO8wshXJL_b2P_jYV5vO_9uhe1EnbMpWRnIEcj_561Ijxurd8C-Fjc7uCbBNIM_E-7YYc$
Bests
Nick
On 12/2/22 12:01, Viresh Kumar wrote:
> On 02-12-22, 12:00, AngeloGioacchino Del Regno wrote:
> > If Viresh can add those while applying the patch, that's fine for
> > me
> > - otherwise I can send a v2 adding the two suggested missing tags.
>
> Sure, no problem.
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
2022-12-19 12:21 ` Allen-KH Cheng (程冠勳)
@ 2022-12-20 14:37 ` Nick
-1 siblings, 0 replies; 75+ messages in thread
From: Nick @ 2022-12-20 14:37 UTC (permalink / raw)
To: Allen-KH Cheng (程冠勳),
viresh.kumar, angelogioacchino.delregno
Cc: linux-mediatek, linux-pm, regressions, regressions,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, daniel, Rex-BC Chen (陳柏辰),
thomas.huehn, Jia-wei Chang (張佳偉)
Hey,
thanks for all your help. I guess it's fine now.
If someone wants to reproduce my setup, I published the exact steps here:
https://forum.openwrt.org/t/running-vanilla-kernel-on-banana-pi-r64/145351
I still wonder why my initial try using the OpenWrt build-environment
together with the 6.1 kernel failed.
Bests
Nick
On 12/19/22 13:21, Allen-KH Cheng (程冠勳) wrote:
> Hi Nick,
>
> This issue doesn't seem to be going to happen.
> Is there anything else we need help confirming?
>
> Thanks,
> Allen
>
> -----Original Message-----
> From: Linux-mediatek <linux-mediatek-bounces@lists.infradead.org> On
> Behalf Of Nick
> Sent: Wednesday, December 7, 2022 11:35 PM
> To: Viresh Kumar <viresh.kumar@linaro.org>; AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
> Cc: Allen-KH Cheng (程冠勳) <Allen-KH.Cheng@mediatek.com>;
> linux-pm@vger.kernel.org; daniel@makrotopia.org;
> Project_Global_Chrome_Upstream_Group <
> Project_Global_Chrome_Upstream_Group@mediatek.com>; Rex-BC Chen (陳柏辰) <
> Rex-BC.Chen@mediatek.com>; Thorsten Leemhuis <regressions@leemhuis.info
>> ; linux-mediatek@lists.infradead.org; matthias.bgg@gmail.com;
> thomas.huehn@hs-nordhausen.de; Jia-wei Chang (張佳偉) <
> Jia-wei.Chang@mediatek.com>; linux-arm-kernel@lists.infradead.org;
> regressions@lists.linux.dev
> Subject: Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine
> mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
>
> Did something changed on master? I compiled now the image I use on the
> BPI-R64 a bit differently.
> I used the openwrt toolchain "aarch64-openwrt-linux-musl-" to cross-
> compile the original linux repository on current master. Than I
> compiled with OpenWrt-Buildsystem a initramfs, put that together with
> mkimage to a "itb" and booted it. Suddenly it works:
>
> https://urldefense.com/v3/__https://gist.githubusercontent.com/PolynomialDivision/5e49529206ba5d273bf6a416c42c6234/raw/7ecff7be397a6e9a41ef120c3fa61060c488cf5b/mt7622-bpi-vanilla__;!!CTRNKA9wMg0ARbw!glNhziJx8pjvVsVoRm0LO8wshXJL_b2P_jYV5vO_9uhe1EnbMpWRnIEcj_561Ijxurd8C-Fjc7uCbBNIM_E-7YYc$
>
>
> Bests
> Nick
>
> On 12/2/22 12:01, Viresh Kumar wrote:
>> On 02-12-22, 12:00, AngeloGioacchino Del Regno wrote:
>>> If Viresh can add those while applying the patch, that's fine for
>>> me
>>> - otherwise I can send a v2 adding the two suggested missing tags.
>> Sure, no problem.
>>
>
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
@ 2022-12-20 14:37 ` Nick
0 siblings, 0 replies; 75+ messages in thread
From: Nick @ 2022-12-20 14:37 UTC (permalink / raw)
To: Allen-KH Cheng (程冠勳),
viresh.kumar, angelogioacchino.delregno
Cc: linux-mediatek, linux-pm, regressions, regressions,
Project_Global_Chrome_Upstream_Group, linux-arm-kernel,
matthias.bgg, daniel, Rex-BC Chen (陳柏辰),
thomas.huehn, Jia-wei Chang (張佳偉)
Hey,
thanks for all your help. I guess it's fine now.
If someone wants to reproduce my setup, I published the exact steps here:
https://forum.openwrt.org/t/running-vanilla-kernel-on-banana-pi-r64/145351
I still wonder why my initial try using the OpenWrt build-environment
together with the 6.1 kernel failed.
Bests
Nick
On 12/19/22 13:21, Allen-KH Cheng (程冠勳) wrote:
> Hi Nick,
>
> This issue doesn't seem to be going to happen.
> Is there anything else we need help confirming?
>
> Thanks,
> Allen
>
> -----Original Message-----
> From: Linux-mediatek <linux-mediatek-bounces@lists.infradead.org> On
> Behalf Of Nick
> Sent: Wednesday, December 7, 2022 11:35 PM
> To: Viresh Kumar <viresh.kumar@linaro.org>; AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
> Cc: Allen-KH Cheng (程冠勳) <Allen-KH.Cheng@mediatek.com>;
> linux-pm@vger.kernel.org; daniel@makrotopia.org;
> Project_Global_Chrome_Upstream_Group <
> Project_Global_Chrome_Upstream_Group@mediatek.com>; Rex-BC Chen (陳柏辰) <
> Rex-BC.Chen@mediatek.com>; Thorsten Leemhuis <regressions@leemhuis.info
>> ; linux-mediatek@lists.infradead.org; matthias.bgg@gmail.com;
> thomas.huehn@hs-nordhausen.de; Jia-wei Chang (張佳偉) <
> Jia-wei.Chang@mediatek.com>; linux-arm-kernel@lists.infradead.org;
> regressions@lists.linux.dev
> Subject: Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine
> mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)
>
> Did something changed on master? I compiled now the image I use on the
> BPI-R64 a bit differently.
> I used the openwrt toolchain "aarch64-openwrt-linux-musl-" to cross-
> compile the original linux repository on current master. Than I
> compiled with OpenWrt-Buildsystem a initramfs, put that together with
> mkimage to a "itb" and booted it. Suddenly it works:
>
> https://urldefense.com/v3/__https://gist.githubusercontent.com/PolynomialDivision/5e49529206ba5d273bf6a416c42c6234/raw/7ecff7be397a6e9a41ef120c3fa61060c488cf5b/mt7622-bpi-vanilla__;!!CTRNKA9wMg0ARbw!glNhziJx8pjvVsVoRm0LO8wshXJL_b2P_jYV5vO_9uhe1EnbMpWRnIEcj_561Ijxurd8C-Fjc7uCbBNIM_E-7YYc$
>
>
> Bests
> Nick
>
> On 12/2/22 12:01, Viresh Kumar wrote:
>> On 02-12-22, 12:00, AngeloGioacchino Del Regno wrote:
>>> If Viresh can add those while applying the patch, that's fine for
>>> me
>>> - otherwise I can send a v2 adding the two suggested missing tags.
>> Sure, no problem.
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622) #forregzbot
2022-12-20 14:37 ` Nick
@ 2022-12-21 9:24 ` Thorsten Leemhuis
-1 siblings, 0 replies; 75+ messages in thread
From: Thorsten Leemhuis @ 2022-12-21 9:24 UTC (permalink / raw)
To: regressions; +Cc: linux-mediatek, linux-pm, linux-arm-kernel
[Note: this mail contains only information for Linux kernel regression
tracking. Mails like these contain '#forregzbot' in the subject to make
then easy to spot and filter out. The author also tried to remove most
or all individuals from the list of recipients to spare them the hassle.]
On 20.12.22 15:37, Nick wrote:
> thanks for all your help. I guess it's fine now.
I'm a bit confused here. The revert afaics never made it to mainline,
but nevertheless the report claimed two times now that the problem is
gone, hence marking it as resolved
#regzbot resolved: problem doesn't show up anymore according to the reporter
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.
^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622) #forregzbot
@ 2022-12-21 9:24 ` Thorsten Leemhuis
0 siblings, 0 replies; 75+ messages in thread
From: Thorsten Leemhuis @ 2022-12-21 9:24 UTC (permalink / raw)
To: regressions; +Cc: linux-mediatek, linux-pm, linux-arm-kernel
[Note: this mail contains only information for Linux kernel regression
tracking. Mails like these contain '#forregzbot' in the subject to make
then easy to spot and filter out. The author also tried to remove most
or all individuals from the list of recipients to spare them the hassle.]
On 20.12.22 15:37, Nick wrote:
> thanks for all your help. I guess it's fine now.
I'm a bit confused here. The revert afaics never made it to mainline,
but nevertheless the report claimed two times now that the problem is
gone, hence marking it as resolved
#regzbot resolved: problem doesn't show up anymore according to the reporter
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 75+ messages in thread
end of thread, other threads:[~2022-12-21 9:25 UTC | newest]
Thread overview: 75+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-09 13:35 Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622) Nick
2022-11-09 13:35 ` Nick
2022-11-09 19:40 ` Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622) #forregzbot Thorsten Leemhuis
2022-11-09 19:40 ` Thorsten Leemhuis
2022-11-10 11:26 ` Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622) Matthias Brugger
2022-11-10 11:26 ` Matthias Brugger
2022-11-15 19:44 ` Nick
2022-11-15 19:44 ` Nick
2022-12-01 15:08 ` Thorsten Leemhuis
2022-12-01 15:08 ` Thorsten Leemhuis
2022-12-01 15:26 ` Daniel Golle
2022-12-01 15:26 ` Daniel Golle
2022-12-01 15:26 ` Daniel Golle
2022-12-01 15:39 ` Thorsten Leemhuis
2022-12-01 15:39 ` Thorsten Leemhuis
2022-12-01 15:39 ` Thorsten Leemhuis
2022-12-01 21:40 ` Nick
2022-12-01 21:40 ` Nick
2022-12-01 21:40 ` Nick
2022-12-02 5:27 ` Viresh Kumar
2022-12-02 5:27 ` Viresh Kumar
2022-12-02 5:27 ` Viresh Kumar
2022-12-02 8:57 ` AngeloGioacchino Del Regno
2022-12-02 8:57 ` AngeloGioacchino Del Regno
2022-12-02 8:57 ` AngeloGioacchino Del Regno
2022-12-02 9:19 ` AngeloGioacchino Del Regno
2022-12-02 9:19 ` AngeloGioacchino Del Regno
2022-12-02 9:19 ` AngeloGioacchino Del Regno
2022-12-02 9:43 ` Allen-KH Cheng (程冠勳)
2022-12-02 9:43 ` Allen-KH Cheng (程冠勳)
2022-12-02 9:43 ` Allen-KH Cheng (程冠勳)
2022-12-02 10:02 ` AngeloGioacchino Del Regno
2022-12-02 10:02 ` AngeloGioacchino Del Regno
2022-12-02 10:02 ` AngeloGioacchino Del Regno
2022-12-02 10:41 ` Thorsten Leemhuis
2022-12-02 10:41 ` Thorsten Leemhuis
2022-12-02 10:41 ` Thorsten Leemhuis
2022-12-02 10:47 ` Viresh Kumar
2022-12-02 10:47 ` Viresh Kumar
2022-12-02 10:47 ` Viresh Kumar
2022-12-02 10:51 ` Thorsten Leemhuis
2022-12-02 10:51 ` Thorsten Leemhuis
2022-12-02 10:51 ` Thorsten Leemhuis
2022-12-02 11:00 ` AngeloGioacchino Del Regno
2022-12-02 11:00 ` AngeloGioacchino Del Regno
2022-12-02 11:00 ` AngeloGioacchino Del Regno
2022-12-02 11:01 ` Viresh Kumar
2022-12-02 11:01 ` Viresh Kumar
2022-12-02 11:01 ` Viresh Kumar
2022-12-07 15:34 ` Nick
2022-12-07 15:34 ` Nick
2022-12-07 15:34 ` Nick
2022-12-19 12:21 ` Allen-KH Cheng (程冠勳)
2022-12-19 12:21 ` Allen-KH Cheng (程冠勳)
2022-12-20 14:37 ` Nick
2022-12-20 14:37 ` Nick
2022-12-21 9:24 ` Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622) #forregzbot Thorsten Leemhuis
2022-12-21 9:24 ` Thorsten Leemhuis
2022-12-02 12:25 ` Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622) Nick
2022-12-02 12:25 ` Nick
2022-12-02 12:25 ` Nick
2022-12-02 5:26 ` [PATCH] Revert "cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()" Viresh Kumar
2022-12-02 5:26 ` Viresh Kumar
2022-12-02 12:17 ` Rafael J. Wysocki
2022-12-02 12:17 ` Rafael J. Wysocki
2022-12-02 19:46 ` Rafael J. Wysocki
2022-12-02 19:46 ` Rafael J. Wysocki
2022-12-05 4:30 ` Viresh Kumar
2022-12-05 4:30 ` Viresh Kumar
2022-12-05 12:08 ` Rafael J. Wysocki
2022-12-05 12:08 ` Rafael J. Wysocki
2022-12-05 23:30 ` Viresh Kumar
2022-12-05 23:30 ` Viresh Kumar
2022-12-02 12:47 ` Nick
2022-12-02 12:47 ` Nick
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.