next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd)
Full Boot Summary: https://kernelci.org/boot/all/job/next/branch/pending-fixes/kernel/v5.2-rc1-... Full Build Summary: https://kernelci.org/build/next/branch/pending-fixes/kernel/v5.2-rc1-375-g36...
Tree: next Branch: pending-fixes Git Describe: v5.2-rc1-375-g3695b18d1e9cd Git Commit: 3695b18d1e9cd6bb739579e782670518d500839d Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Tested: 82 unique boards, 24 SoC families, 19 builds out of 223
Boot Regressions Detected:
arm:
qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 3 days (last pass: v5.1-11016-gf31c9c9ee122 - first fail: v5.1-12956-g8d4b83476a8f) qcom-apq8064-ifc6410: lab-baylibre-seattle: failing since 3 days (last pass: v5.1-11016-gf31c9c9ee122 - first fail: v5.1-12956-g8d4b83476a8f)
arm64:
defconfig: gcc-8: meson-g12a-x96-max: lab-baylibre: failing since 7 days (last pass: v5.1-10265-g58c33df2baf5 - first fail: v5.1-11016-gf31c9c9ee122)
defconfig+CONFIG_RANDOMIZE_BASE=y: gcc-8: meson-g12a-x96-max: lab-baylibre: new failure (last pass: v5.1-11016-gf31c9c9ee122)
Boot Failures Detected:
arm: qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: 1 failed lab qcom-apq8064-ifc6410: 1 failed lab
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: gcc-8: rk3288-veyron-jaq: 1 failed lab
multi_v7_defconfig+CONFIG_SMP=n: gcc-8: rk3288-veyron-jaq: 1 failed lab
multi_v7_defconfig: gcc-8: bcm4708-smartrg-sr400ac: 1 failed lab rk3288-veyron-jaq: 1 failed lab
Offline Platforms:
arm:
sama5_defconfig: gcc-8 at91-sama5d4_xplained: 1 offline lab at91-sama5d4ek: 1 offline lab
multi_v7_defconfig: gcc-8 alpine-db: 1 offline lab at91-sama5d4_xplained: 1 offline lab at91-sama5d4ek: 1 offline lab stih410-b2120: 1 offline lab sun5i-r8-chip: 1 offline lab tegra124-jetson-tk1: 1 offline lab
tegra_defconfig: gcc-8 tegra124-jetson-tk1: 1 offline lab
sunxi_defconfig: gcc-8 sun5i-r8-chip: 1 offline lab
bcm2835_defconfig: gcc-8 bcm2835-rpi-b: 1 offline lab
arm64:
defconfig+CONFIG_CPU_BIG_ENDIAN=y: gcc-8 apq8016-sbc: 1 offline lab juno-r2: 1 offline lab
defconfig: gcc-8 apq8016-sbc: 1 offline lab juno-r2: 1 offline lab mt7622-rfb1: 1 offline lab sun50i-a64-pine64-plus: 1 offline lab
defconfig+CONFIG_RANDOMIZE_BASE=y: gcc-8 apq8016-sbc: 1 offline lab juno-r2: 1 offline lab mt7622-rfb1: 1 offline lab
Conflicting Boot Failures Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)
arm64: defconfig: meson-g12a-x96-max: lab-baylibre: FAIL (gcc-8) lab-baylibre-seattle: PASS (gcc-8)
defconfig+CONFIG_RANDOMIZE_BASE=y: meson-g12a-x96-max: lab-baylibre: FAIL (gcc-8) lab-baylibre-seattle: PASS (gcc-8)
--- For more info write to info@kernelci.org
[ + Andy Gross, Stephen Boyd ]
"kernelci.org bot" bot@kernelci.org writes:
next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd)
Full Boot Summary: https://kernelci.org/boot/all/job/next/branch/pending-fixes/kernel/v5.2-rc1-... Full Build Summary: https://kernelci.org/build/next/branch/pending-fixes/kernel/v5.2-rc1-375-g36...
Tree: next Branch: pending-fixes Git Describe: v5.2-rc1-375-g3695b18d1e9cd Git Commit: 3695b18d1e9cd6bb739579e782670518d500839d Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Tested: 82 unique boards, 24 SoC families, 19 builds out of 223
Boot Regressions Detected:
arm:
qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 3 days (last pass: v5.1-11016-gf31c9c9ee122 - first fail: v5.1-12956-g8d4b83476a8f) qcom-apq8064-ifc6410: lab-baylibre-seattle: failing since 3 days (last pass: v5.1-11016-gf31c9c9ee122 - first fail: v5.1-12956-g8d4b83476a8f)
Andy, 8064 not happy in linux-next lately, I haven't had a chance to look closer.
Kevin
Quoting Kevin Hilman (2019-05-23 17:18:50)
[ + Andy Gross, Stephen Boyd ]
"kernelci.org bot" bot@kernelci.org writes:
next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd)
Full Boot Summary: https://kernelci.org/boot/all/job/next/branch/pending-fixes/kernel/v5.2-rc1-... Full Build Summary: https://kernelci.org/build/next/branch/pending-fixes/kernel/v5.2-rc1-375-g36...
Tree: next Branch: pending-fixes Git Describe: v5.2-rc1-375-g3695b18d1e9cd Git Commit: 3695b18d1e9cd6bb739579e782670518d500839d Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Tested: 82 unique boards, 24 SoC families, 19 builds out of 223
Boot Regressions Detected:
arm:
qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 3 days (last pass: v5.1-11016-gf31c9c9ee122 - first fail: v5.1-12956-g8d4b83476a8f) qcom-apq8064-ifc6410: lab-baylibre-seattle: failing since 3 days (last pass: v5.1-11016-gf31c9c9ee122 - first fail: v5.1-12956-g8d4b83476a8f)
Andy, 8064 not happy in linux-next lately, I haven't had a chance to look closer.
Looks like some sort of tsens crash with a bad regmap_field or something.
[ 4.001041] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 4.008631] pgd = (ptrval) [ 4.016914] [00000000] *pgd=00000000 [ 4.019374] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 4.023100] Modules linked in: [ 4.028402] CPU: 2 PID: 21 Comm: kworker/2:0 Tainted: G W 5.2.0-rc1 #1 [ 4.031259] Hardware name: Generic DT based system [ 4.039175] Workqueue: events deferred_probe_work_func [ 4.043859] PC is at regmap_field_read+0x1c/0x70 [ 4.048973] LR is at is_sensor_enabled+0x40/0x74 [ 4.053743] pc : [] lr : [] psr: 20000013 [ 4.058340] sp : c02f1dc8 ip : 00000000 fp : 00000007 [ 4.064332] r10: c0de1534 r9 : c0bb596c r8 : ee4eda00 [ 4.068214] usb 1-1: New USB device found, idVendor=04b4, idProduct=6570, bcdDevice=32.99 [ 4.069539] r7 : c02f0000 r6 : c02f1de0 r5 : 00000000 r4 : c02f0000 [ 4.069549] r3 : c02f1dc8 r2 : 11403009 r1 : c02f1de0 r0 : 00000000 [ 4.074838] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 4.083085] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 4.083096] Control: 10c5787d Table: 8020406a DAC: 00000051 [ 4.083108] Process kworker/2:0 (pid: 21, stack limit = 0x(ptrval)) [ 4.083118] Stack: (0xc02f1dc8 to 0xc02f2000) [ 4.083152] 1dc0: c02f0000 c093d93c c02f0000 00000000 00000000 c093dabc [ 4.083192] 1de0: 0000000b 11403009 ee39b040 ee39b040 ee39b040 c093d794 00000000 11403009 [ 4.089507] usb 1-1: Product: USB2.0 Hub [ 4.096045] 1e00: 0000000b 11403009 ee4eda10 00000000 c10a2b84 00000000 c10c2f78 00000000 [ 4.096085] 1e20: c10a2b84 c080b940 c110b37c ee4eda10 c110b380 00000000 c10c2f78 c0809480 [ 4.096126] 1e40: c02f1ecc ee4eda10 ffffe000 ee4eda10 c10a2b84 c02f1ecc c0809b78 00000001 [ 4.105168] hub 1-1:1.0: USB hub found [ 4.110367] 1e60: c0dbb994 c10c2f78 ffffe000 c0809938 ee4eda10 00000001 00000001 00000000 [ 4.116581] hub 1-1:1.0: 4 ports detected [ 4.122170] 1e80: c02f0000 c02f1ecc c0809b78 00000001 c0dbb994 c10c2f78 ffffe000 c0807718 [ 4.187285] 1ea0: ffffe000 c028c26c ee20acb8 11403009 ee4eda10 ee4eda10 c02f0000 ee4eda54 [ 4.195443] 1ec0: c10938a8 c08092d8 ee4eda10 ee4eda10 00000001 11403009 ee4eda10 ee4eda10 [ 4.203603] 1ee0: c1093b18 c10938a8 c10c2f78 c08084e4 ee4eda10 c1093894 c1093894 c0808a2c [ 4.211762] 1f00: c10938cc c0208880 eefc0cc0 eefc3e00 00000000 c10b76b0 00000000 c033c804 [ 4.219921] 1f20: eefc0cc0 eefc0cc0 eefc0cd8 c0208880 c0208894 eefc0cc0 00000108 c1003d00 [ 4.228082] 1f40: eefc0cd8 eefc0cc0 ffffe000 c033d6dc c023ed00 c10b70e8 c0d44c58 00000000 [ 4.236242] 1f60: c023ed1c c023ed00 c023ec80 00000000 c02f0000 c0208880 c033d448 c029bdec [ 4.244400] 1f80: c023ed1c c034289c 00000000 c023ec80 c0342754 00000000 00000000 00000000 [ 4.252559] 1fa0: 00000000 00000000 00000000 c03010e8 00000000 00000000 00000000 00000000 [ 4.260719] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 4.268878] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 4.277031] [] (regmap_field_read) from [] (is_sensor_enabled+0x40/0x74) [ 4.285185] [] (is_sensor_enabled) from [] (tsens_probe+0x170/0x2d4) [ 4.293699] [] (tsens_probe) from [] (platform_drv_probe+0x48/0x98) [ 4.301764] [] (platform_drv_probe) from [] (really_probe+0x108/0x40c) [ 4.309490] [] (really_probe) from [] (driver_probe_device+0x78/0x1c0) [ 4.317822] [] (driver_probe_device) from [] (bus_for_each_drv+0x84/0xc8) [ 4.326069] [] (bus_for_each_drv) from [] (__device_attach+0xd4/0x16c) [ 4.334662] [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) [ 4.342815] [] (bus_probe_device) from [] (deferred_probe_work_func+0x84/0xc4) [ 4.351081] [] (deferred_probe_work_func) from [] (process_one_work+0x204/0x570) [ 4.359935] [] (process_one_work) from [] (worker_thread+0x294/0x580) [ 4.369218] [] (worker_thread) from [] (kthread+0x148/0x150) [ 4.377288] [] (kthread) from [] (ret_from_fork+0x14/0x2c) [ 4.384735] Exception stack(0xc02f1fb0 to 0xc02f1ff8) [ 4.391775] 1fa0: 00000000 00000000 00000000 00000000 [ 4.396916] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 4.405068] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 4.413232] Code: e1a06001 e1a0300d e3c34d7f e3c4403f
[1] https://storage.kernelci.org/next/pending-fixes/v5.2-rc1-375-g3695b18d1e9cd/...
On Fri, May 24, 2019 at 3:29 AM Stephen Boyd sboyd@kernel.org wrote:
Quoting Kevin Hilman (2019-05-23 17:18:50)
[ + Andy Gross, Stephen Boyd ]
"kernelci.org bot" bot@kernelci.org writes:
next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd)
Full Boot Summary: https://kernelci.org/boot/all/job/next/branch/pending-fixes/kernel/v5.2-rc1-... Full Build Summary: https://kernelci.org/build/next/branch/pending-fixes/kernel/v5.2-rc1-375-g36...
Tree: next Branch: pending-fixes Git Describe: v5.2-rc1-375-g3695b18d1e9cd Git Commit: 3695b18d1e9cd6bb739579e782670518d500839d Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Tested: 82 unique boards, 24 SoC families, 19 builds out of 223
Boot Regressions Detected:
arm:
qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 3 days (last pass: v5.1-11016-gf31c9c9ee122 - first fail: v5.1-12956-g8d4b83476a8f) qcom-apq8064-ifc6410: lab-baylibre-seattle: failing since 3 days (last pass: v5.1-11016-gf31c9c9ee122 - first fail: v5.1-12956-g8d4b83476a8f)
Andy, 8064 not happy in linux-next lately, I haven't had a chance to look closer.
Looks like some sort of tsens crash with a bad regmap_field or something.
[ 4.001041] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 4.008631] pgd = (ptrval) [ 4.016914] [00000000] *pgd=00000000 [ 4.019374] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 4.023100] Modules linked in: [ 4.028402] CPU: 2 PID: 21 Comm: kworker/2:0 Tainted: G W 5.2.0-rc1 #1 [ 4.031259] Hardware name: Generic DT based system [ 4.039175] Workqueue: events deferred_probe_work_func [ 4.043859] PC is at regmap_field_read+0x1c/0x70 [ 4.048973] LR is at is_sensor_enabled+0x40/0x74 [ 4.053743] pc : [] lr : [] psr: 20000013 [ 4.058340] sp : c02f1dc8 ip : 00000000 fp : 00000007 [ 4.064332] r10: c0de1534 r9 : c0bb596c r8 : ee4eda00 [ 4.068214] usb 1-1: New USB device found, idVendor=04b4, idProduct=6570, bcdDevice=32.99 [ 4.069539] r7 : c02f0000 r6 : c02f1de0 r5 : 00000000 r4 : c02f0000 [ 4.069549] r3 : c02f1dc8 r2 : 11403009 r1 : c02f1de0 r0 : 00000000 [ 4.074838] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 4.083085] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 4.083096] Control: 10c5787d Table: 8020406a DAC: 00000051 [ 4.083108] Process kworker/2:0 (pid: 21, stack limit = 0x(ptrval)) [ 4.083118] Stack: (0xc02f1dc8 to 0xc02f2000) [ 4.083152] 1dc0: c02f0000 c093d93c c02f0000 00000000 00000000 c093dabc [ 4.083192] 1de0: 0000000b 11403009 ee39b040 ee39b040 ee39b040 c093d794 00000000 11403009 [ 4.089507] usb 1-1: Product: USB2.0 Hub [ 4.096045] 1e00: 0000000b 11403009 ee4eda10 00000000 c10a2b84 00000000 c10c2f78 00000000 [ 4.096085] 1e20: c10a2b84 c080b940 c110b37c ee4eda10 c110b380 00000000 c10c2f78 c0809480 [ 4.096126] 1e40: c02f1ecc ee4eda10 ffffe000 ee4eda10 c10a2b84 c02f1ecc c0809b78 00000001 [ 4.105168] hub 1-1:1.0: USB hub found [ 4.110367] 1e60: c0dbb994 c10c2f78 ffffe000 c0809938 ee4eda10 00000001 00000001 00000000 [ 4.116581] hub 1-1:1.0: 4 ports detected [ 4.122170] 1e80: c02f0000 c02f1ecc c0809b78 00000001 c0dbb994 c10c2f78 ffffe000 c0807718 [ 4.187285] 1ea0: ffffe000 c028c26c ee20acb8 11403009 ee4eda10 ee4eda10 c02f0000 ee4eda54 [ 4.195443] 1ec0: c10938a8 c08092d8 ee4eda10 ee4eda10 00000001 11403009 ee4eda10 ee4eda10 [ 4.203603] 1ee0: c1093b18 c10938a8 c10c2f78 c08084e4 ee4eda10 c1093894 c1093894 c0808a2c [ 4.211762] 1f00: c10938cc c0208880 eefc0cc0 eefc3e00 00000000 c10b76b0 00000000 c033c804 [ 4.219921] 1f20: eefc0cc0 eefc0cc0 eefc0cd8 c0208880 c0208894 eefc0cc0 00000108 c1003d00 [ 4.228082] 1f40: eefc0cd8 eefc0cc0 ffffe000 c033d6dc c023ed00 c10b70e8 c0d44c58 00000000 [ 4.236242] 1f60: c023ed1c c023ed00 c023ec80 00000000 c02f0000 c0208880 c033d448 c029bdec [ 4.244400] 1f80: c023ed1c c034289c 00000000 c023ec80 c0342754 00000000 00000000 00000000 [ 4.252559] 1fa0: 00000000 00000000 00000000 c03010e8 00000000 00000000 00000000 00000000 [ 4.260719] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 4.268878] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 4.277031] [] (regmap_field_read) from [] (is_sensor_enabled+0x40/0x74)
Sorry for breaking the boot on 8064. That was one of the platforms that I didn't convert over to regmap (needs more refactoring). I had hoped kernelci would catch any issues but looks like thermal-soc tree entered linux-next quite late and didn't catch this.
Does reverting 3e6a8fb33084 ("drivers: thermal: tsens: Add new operation to check if a sensor is enabled") fix the issue? If so, reverting that commit might be the best course of action since I've started vacations and can't fix this for 8064 in a meaningful amount of time (until 3rd week of June). cc'ing Bjorn in case this needs more investigation, but I think that patch is fairly self contained and reverting it shouldn't have any knock-on effects.
Regards, Amit
[ 4.285185] [] (is_sensor_enabled) from [] (tsens_probe+0x170/0x2d4) [ 4.293699] [] (tsens_probe) from [] (platform_drv_probe+0x48/0x98) [ 4.301764] [] (platform_drv_probe) from [] (really_probe+0x108/0x40c) [ 4.309490] [] (really_probe) from [] (driver_probe_device+0x78/0x1c0) [ 4.317822] [] (driver_probe_device) from [] (bus_for_each_drv+0x84/0xc8) [ 4.326069] [] (bus_for_each_drv) from [] (__device_attach+0xd4/0x16c) [ 4.334662] [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) [ 4.342815] [] (bus_probe_device) from [] (deferred_probe_work_func+0x84/0xc4) [ 4.351081] [] (deferred_probe_work_func) from [] (process_one_work+0x204/0x570) [ 4.359935] [] (process_one_work) from [] (worker_thread+0x294/0x580) [ 4.369218] [] (worker_thread) from [] (kthread+0x148/0x150) [ 4.377288] [] (kthread) from [] (ret_from_fork+0x14/0x2c) [ 4.384735] Exception stack(0xc02f1fb0 to 0xc02f1ff8) [ 4.391775] 1fa0: 00000000 00000000 00000000 00000000 [ 4.396916] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 4.405068] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 4.413232] Code: e1a06001 e1a0300d e3c34d7f e3c4403f
[1] https://storage.kernelci.org/next/pending-fixes/v5.2-rc1-375-g3695b18d1e9cd/...
On Sun, May 26, 2019 at 4:51 PM Amit Kucheria amit.kucheria@linaro.org wrote:
<snip>
Sorry for breaking the boot on 8064. That was one of the platforms that I didn't convert over to regmap (needs more refactoring). I had hoped kernelci would catch any issues but looks like thermal-soc tree entered linux-next quite late and didn't catch this.
Does reverting 3e6a8fb33084 ("drivers: thermal: tsens: Add new operation to check if a sensor is enabled") fix the issue? If so, reverting that commit might be the best course of action since I've started vacations and can't fix this for 8064 in a meaningful amount of time (until 3rd week of June). cc'ing Bjorn in case this needs more investigation, but I think that patch is fairly self contained and reverting it shouldn't have any knock-on effects.
I am ok with this. I'll check with Bjorn before adding this to a fixes for -rc2.
Andy
+Eduardo
On Tue, May 28, 2019 at 1:09 PM Andy Gross andygro@gmail.com wrote:
On Sun, May 26, 2019 at 4:51 PM Amit Kucheria amit.kucheria@linaro.org wrote:
<snip>
Sorry for breaking the boot on 8064. That was one of the platforms that I didn't convert over to regmap (needs more refactoring). I had hoped kernelci would catch any issues but looks like thermal-soc tree entered linux-next quite late and didn't catch this.
Does reverting 3e6a8fb33084 ("drivers: thermal: tsens: Add new operation to check if a sensor is enabled") fix the issue? If so, reverting that commit might be the best course of action since I've started vacations and can't fix this for 8064 in a meaningful amount of time (until 3rd week of June). cc'ing Bjorn in case this needs more investigation, but I think that patch is fairly self contained and reverting it shouldn't have any knock-on effects.
I am ok with this. I'll check with Bjorn before adding this to a fixes for -rc2.
Eduardo, we have a situation with the Qcom tsens driver and commit 3e6a8fb33084. Do you mind if I send in a revert for this through my tree or can you do this for us for -rc2?
Thanks, Andy
Hello,
On Tue, May 28, 2019 at 04:37:15PM -0500, Andy Gross wrote:
+Eduardo
On Tue, May 28, 2019 at 1:09 PM Andy Gross andygro@gmail.com wrote:
On Sun, May 26, 2019 at 4:51 PM Amit Kucheria amit.kucheria@linaro.org wrote:
<snip>
Sorry for breaking the boot on 8064. That was one of the platforms that I didn't convert over to regmap (needs more refactoring). I had hoped kernelci would catch any issues but looks like thermal-soc tree entered linux-next quite late and didn't catch this.
Does reverting 3e6a8fb33084 ("drivers: thermal: tsens: Add new operation to check if a sensor is enabled") fix the issue? If so, reverting that commit might be the best course of action since I've started vacations and can't fix this for 8064 in a meaningful amount of time (until 3rd week of June). cc'ing Bjorn in case this needs more investigation, but I think that patch is fairly self contained and reverting it shouldn't have any knock-on effects.
I am ok with this. I'll check with Bjorn before adding this to a fixes for -rc2.
Eduardo, we have a situation with the Qcom tsens driver and commit 3e6a8fb33084. Do you mind if I send in a revert for this through my tree or can you do this for us for -rc2?
I can revert this patch. I can confirm that it is selfcontained and reverting seams to work. I am sending the revert to -rc3, as rc2 is already out.
Thanks, Andy
On Tue, May 28, 2019 at 8:06 PM Eduardo Valentin edubezval@gmail.com wrote:
Hello,
On Tue, May 28, 2019 at 04:37:15PM -0500, Andy Gross wrote:
+Eduardo
On Tue, May 28, 2019 at 1:09 PM Andy Gross andygro@gmail.com wrote:
On Sun, May 26, 2019 at 4:51 PM Amit Kucheria amit.kucheria@linaro.org wrote:
<snip>
Sorry for breaking the boot on 8064. That was one of the platforms that I didn't convert over to regmap (needs more refactoring). I had hoped kernelci would catch any issues but looks like thermal-soc tree entered linux-next quite late and didn't catch this.
Does reverting 3e6a8fb33084 ("drivers: thermal: tsens: Add new operation to check if a sensor is enabled") fix the issue? If so, reverting that commit might be the best course of action since I've started vacations and can't fix this for 8064 in a meaningful amount of time (until 3rd week of June). cc'ing Bjorn in case this needs more investigation, but I think that patch is fairly self contained and reverting it shouldn't have any knock-on effects.
I am ok with this. I'll check with Bjorn before adding this to a fixes for -rc2.
Eduardo, we have a situation with the Qcom tsens driver and commit 3e6a8fb33084. Do you mind if I send in a revert for this through my tree or can you do this for us for -rc2?
I can revert this patch. I can confirm that it is selfcontained and reverting seams to work. I am sending the revert to -rc3, as rc2 is already out.
Perfect. Thanks Eduardo!
Andy
This reverts commit 3e6a8fb3308419129c7a52de6eb42feef5a919a0.
Cc: Andy Gross agross@kernel.org Cc: David Brown david.brown@linaro.org Cc: Amit Kucheria amit.kucheria@linaro.org Cc: Zhang Rui rui.zhang@intel.com Cc: Daniel Lezcano daniel.lezcano@linaro.org Suggested-by: Amit Kucheria amit.kucheria@linaro.org Reported-by: Andy Gross andygro@gmail.com Signed-off-by: Eduardo Valentin edubezval@gmail.com ---
Added this for next -rc, as per request.
drivers/thermal/qcom/tsens-common.c | 14 -------------- drivers/thermal/qcom/tsens-v0_1.c | 1 - drivers/thermal/qcom/tsens-v2.c | 1 - drivers/thermal/qcom/tsens.c | 5 ----- drivers/thermal/qcom/tsens.h | 1 - 5 files changed, 22 deletions(-)
diff --git a/drivers/thermal/qcom/tsens-common.c b/drivers/thermal/qcom/tsens-common.c index 928e8e8..528df88 100644 --- a/drivers/thermal/qcom/tsens-common.c +++ b/drivers/thermal/qcom/tsens-common.c @@ -64,20 +64,6 @@ void compute_intercept_slope(struct tsens_priv *priv, u32 *p1, } }
-bool is_sensor_enabled(struct tsens_priv *priv, u32 hw_id) -{ - u32 val; - int ret; - - if ((hw_id > (priv->num_sensors - 1)) || (hw_id < 0)) - return -EINVAL; - ret = regmap_field_read(priv->rf[SENSOR_EN], &val); - if (ret) - return ret; - - return val & (1 << hw_id); -} - static inline int code_to_degc(u32 adc_code, const struct tsens_sensor *s) { int degc, num, den; diff --git a/drivers/thermal/qcom/tsens-v0_1.c b/drivers/thermal/qcom/tsens-v0_1.c index a319283..6f26fad 100644 --- a/drivers/thermal/qcom/tsens-v0_1.c +++ b/drivers/thermal/qcom/tsens-v0_1.c @@ -334,7 +334,6 @@ static const struct reg_field tsens_v0_1_regfields[MAX_REGFIELDS] = { /* CTRL_OFFSET */ [TSENS_EN] = REG_FIELD(SROT_CTRL_OFF, 0, 0), [TSENS_SW_RST] = REG_FIELD(SROT_CTRL_OFF, 1, 1), - [SENSOR_EN] = REG_FIELD(SROT_CTRL_OFF, 3, 13),
/* ----- TM ------ */ /* INTERRUPT ENABLE */ diff --git a/drivers/thermal/qcom/tsens-v2.c b/drivers/thermal/qcom/tsens-v2.c index 1099069..0a4f2b8 100644 --- a/drivers/thermal/qcom/tsens-v2.c +++ b/drivers/thermal/qcom/tsens-v2.c @@ -44,7 +44,6 @@ static const struct reg_field tsens_v2_regfields[MAX_REGFIELDS] = { /* CTRL_OFF */ [TSENS_EN] = REG_FIELD(SROT_CTRL_OFF, 0, 0), [TSENS_SW_RST] = REG_FIELD(SROT_CTRL_OFF, 1, 1), - [SENSOR_EN] = REG_FIELD(SROT_CTRL_OFF, 3, 18),
/* ----- TM ------ */ /* INTERRUPT ENABLE */ diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c index 36b0b52..0627d86 100644 --- a/drivers/thermal/qcom/tsens.c +++ b/drivers/thermal/qcom/tsens.c @@ -85,11 +85,6 @@ static int tsens_register(struct tsens_priv *priv) struct thermal_zone_device *tzd;
for (i = 0; i < priv->num_sensors; i++) { - if (!is_sensor_enabled(priv, priv->sensor[i].hw_id)) { - dev_err(priv->dev, "sensor %d: disabled\n", - priv->sensor[i].hw_id); - continue; - } priv->sensor[i].priv = priv; priv->sensor[i].id = i; tzd = devm_thermal_zone_of_sensor_register(priv->dev, i, diff --git a/drivers/thermal/qcom/tsens.h b/drivers/thermal/qcom/tsens.h index eefe384..2fd9499 100644 --- a/drivers/thermal/qcom/tsens.h +++ b/drivers/thermal/qcom/tsens.h @@ -315,7 +315,6 @@ void compute_intercept_slope(struct tsens_priv *priv, u32 *pt1, u32 *pt2, u32 mo int init_common(struct tsens_priv *priv); int get_temp_tsens_valid(struct tsens_priv *priv, int i, int *temp); int get_temp_common(struct tsens_priv *priv, int i, int *temp); -bool is_sensor_enabled(struct tsens_priv *priv, u32 hw_id);
/* TSENS target */ extern const struct tsens_plat_data data_8960;
Amit Kucheria amit.kucheria@linaro.org writes:
On Fri, May 24, 2019 at 3:29 AM Stephen Boyd sboyd@kernel.org wrote:
Quoting Kevin Hilman (2019-05-23 17:18:50)
[ + Andy Gross, Stephen Boyd ]
"kernelci.org bot" bot@kernelci.org writes:
next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd)
Full Boot Summary: https://kernelci.org/boot/all/job/next/branch/pending-fixes/kernel/v5.2-rc1-... Full Build Summary: https://kernelci.org/build/next/branch/pending-fixes/kernel/v5.2-rc1-375-g36...
Tree: next Branch: pending-fixes Git Describe: v5.2-rc1-375-g3695b18d1e9cd Git Commit: 3695b18d1e9cd6bb739579e782670518d500839d Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Tested: 82 unique boards, 24 SoC families, 19 builds out of 223
Boot Regressions Detected:
arm:
qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 3 days (last pass: v5.1-11016-gf31c9c9ee122 - first fail: v5.1-12956-g8d4b83476a8f) qcom-apq8064-ifc6410: lab-baylibre-seattle: failing since 3 days (last pass: v5.1-11016-gf31c9c9ee122 - first fail: v5.1-12956-g8d4b83476a8f)
Andy, 8064 not happy in linux-next lately, I haven't had a chance to look closer.
Looks like some sort of tsens crash with a bad regmap_field or something.
[ 4.001041] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 4.008631] pgd = (ptrval) [ 4.016914] [00000000] *pgd=00000000 [ 4.019374] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 4.023100] Modules linked in: [ 4.028402] CPU: 2 PID: 21 Comm: kworker/2:0 Tainted: G W 5.2.0-rc1 #1 [ 4.031259] Hardware name: Generic DT based system [ 4.039175] Workqueue: events deferred_probe_work_func [ 4.043859] PC is at regmap_field_read+0x1c/0x70 [ 4.048973] LR is at is_sensor_enabled+0x40/0x74 [ 4.053743] pc : [] lr : [] psr: 20000013 [ 4.058340] sp : c02f1dc8 ip : 00000000 fp : 00000007 [ 4.064332] r10: c0de1534 r9 : c0bb596c r8 : ee4eda00 [ 4.068214] usb 1-1: New USB device found, idVendor=04b4, idProduct=6570, bcdDevice=32.99 [ 4.069539] r7 : c02f0000 r6 : c02f1de0 r5 : 00000000 r4 : c02f0000 [ 4.069549] r3 : c02f1dc8 r2 : 11403009 r1 : c02f1de0 r0 : 00000000 [ 4.074838] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 4.083085] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 4.083096] Control: 10c5787d Table: 8020406a DAC: 00000051 [ 4.083108] Process kworker/2:0 (pid: 21, stack limit = 0x(ptrval)) [ 4.083118] Stack: (0xc02f1dc8 to 0xc02f2000) [ 4.083152] 1dc0: c02f0000 c093d93c c02f0000 00000000 00000000 c093dabc [ 4.083192] 1de0: 0000000b 11403009 ee39b040 ee39b040 ee39b040 c093d794 00000000 11403009 [ 4.089507] usb 1-1: Product: USB2.0 Hub [ 4.096045] 1e00: 0000000b 11403009 ee4eda10 00000000 c10a2b84 00000000 c10c2f78 00000000 [ 4.096085] 1e20: c10a2b84 c080b940 c110b37c ee4eda10 c110b380 00000000 c10c2f78 c0809480 [ 4.096126] 1e40: c02f1ecc ee4eda10 ffffe000 ee4eda10 c10a2b84 c02f1ecc c0809b78 00000001 [ 4.105168] hub 1-1:1.0: USB hub found [ 4.110367] 1e60: c0dbb994 c10c2f78 ffffe000 c0809938 ee4eda10 00000001 00000001 00000000 [ 4.116581] hub 1-1:1.0: 4 ports detected [ 4.122170] 1e80: c02f0000 c02f1ecc c0809b78 00000001 c0dbb994 c10c2f78 ffffe000 c0807718 [ 4.187285] 1ea0: ffffe000 c028c26c ee20acb8 11403009 ee4eda10 ee4eda10 c02f0000 ee4eda54 [ 4.195443] 1ec0: c10938a8 c08092d8 ee4eda10 ee4eda10 00000001 11403009 ee4eda10 ee4eda10 [ 4.203603] 1ee0: c1093b18 c10938a8 c10c2f78 c08084e4 ee4eda10 c1093894 c1093894 c0808a2c [ 4.211762] 1f00: c10938cc c0208880 eefc0cc0 eefc3e00 00000000 c10b76b0 00000000 c033c804 [ 4.219921] 1f20: eefc0cc0 eefc0cc0 eefc0cd8 c0208880 c0208894 eefc0cc0 00000108 c1003d00 [ 4.228082] 1f40: eefc0cd8 eefc0cc0 ffffe000 c033d6dc c023ed00 c10b70e8 c0d44c58 00000000 [ 4.236242] 1f60: c023ed1c c023ed00 c023ec80 00000000 c02f0000 c0208880 c033d448 c029bdec [ 4.244400] 1f80: c023ed1c c034289c 00000000 c023ec80 c0342754 00000000 00000000 00000000 [ 4.252559] 1fa0: 00000000 00000000 00000000 c03010e8 00000000 00000000 00000000 00000000 [ 4.260719] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 4.268878] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 4.277031] [] (regmap_field_read) from [] (is_sensor_enabled+0x40/0x74)
Sorry for breaking the boot on 8064. That was one of the platforms that I didn't convert over to regmap (needs more refactoring). I had hoped kernelci would catch any issues but looks like thermal-soc tree entered linux-next quite late and didn't catch this.
Does reverting 3e6a8fb33084 ("drivers: thermal: tsens: Add new operation to check if a sensor is enabled") fix the issue? If so, reverting that commit might be the best course of action since I've started vacations and can't fix this for 8064 in a meaningful amount of time (until 3rd week of June). cc'ing Bjorn in case this needs more investigation, but I think that patch is fairly self contained and reverting it shouldn't have any knock-on effects.
Tested-by: Kevin Hilman khilman@baylibre.com
Reverting that commit gets things booting again in my lab.
Kevin
kernel-build-reports@lists.linaro.org