Re: next/pending-fixes boot: 227 boots: 6 failed, 198 passed with 20 offline, 1 untried/unknown, 2 conflicts (v5.2-rc1-375-g3695b18d1e9cd)

[Kevin Hilman <khilman@baylibre.com>]

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-375-g3695b18d1e9cd/
>> > > Full Build Summary: https://kernelci.org/build/next/branch/pending-fixes/kernel/v5.2-rc1-375-g3695b18d1e9cd/
>> > >
>> > > 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