Re: Hang loading omap_rng on MacchiatoBin with 4.15-rc7

2018-01-09 Thread Riku Voipio
On 9 January 2018 at 11:47, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
> On 9 January 2018 at 08:31, Riku Voipio <riku.voi...@linaro.org> wrote:
>> Hi,
>>
>> Loading omap_rng module on McBin causes hangup (in about 9/10 times).
>> Looking at /proc/interrupts it seems the interrupt starts running like
>> crazy, and after a while the whole system is unresponsive. This with
>> Debian kernel (everything possible as modules) and EFI as bootloader.
>> The EFI firmware appears[1] to use the rng unit to provide a seed for
>> KASRL, I wonder if the driver needs to depend less on the state left
>> by firmware, or the firmware needs to de-initialize the RNG before
>> booting.
>>
> ...
>>  87:  0  0  0  0  ICU.f21e  95
>> Level f276.trng
>>  88:2532580  0  0  0  ICU.f41e  95
>> Level f476.trng
> ...
>
> My original code had
>
> gMarvellTokenSpaceGuid.PcdEip76TrngBaseAddress|0xF276
>
> which means the interrupt storm is being caused by the /other/ RNG,
> not the one UEFI uses.
>
> Could you please check whether your UEFI source is still using the
> same base address?

Good catch. Looks like it is:

https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/marvell-armada-wip-variables/Platforms/Marvell/Armada/Armada.dsc.inc#L374

Riku


Re: Hang loading omap_rng on MacchiatoBin with 4.15-rc7

2018-01-09 Thread Riku Voipio
On 9 January 2018 at 11:21, Gregory CLEMENT
<gregory.clem...@free-electrons.com> wrote:
> Hi Riku,
>
>  On mar., janv. 09 2018, Riku Voipio <riku.voi...@linaro.org> wrote:
>
>> Hi,
>>
>> Loading omap_rng module on McBin causes hangup (in about 9/10 times).
>> Looking at /proc/interrupts it seems the interrupt starts running like
>> crazy, and after a while the whole system is unresponsive. This with
>> Debian kernel (everything possible as modules) and EFI as bootloader.
>> The EFI firmware appears[1] to use the rng unit to provide a seed for
>> KASRL, I wonder if the driver needs to depend less on the state left
>> by firmware, or the firmware needs to de-initialize the RNG before
>> booting.
>
> I do not have a board with an EFI bootloader, so that may explain why I
> didn't managed to reproduce your issue. I really would prefer to make
> the driver less depend to the bootloader than the firmware de-initialize
> the RNG before booting. However both things could be done independently.
>
> I can have a look on the driver but as I don't have the configuration I
> may ask you to test it for me.

Sure, I'll be happy to test.

>>
>> root@debian:~# cat /proc/interrupts
>>CPU0   CPU1   CPU2   CPU3
>>   1:  0  0  0  0 GICv2  25 Level vgic
>>   3:   1268   1983   1175   1139 GICv2  30 Level
>>   arch_timer
>>   4:  0  0  0  0 GICv2  27 Level
>>   kvm guest timer
>>   7:   1956  0  0  0 GICv2  51 Level 
>> ttyS0
>>   9:   4472  0307  0 GICv2  48 Level mmc0
>>  18:  0  0  0  0  pMSI 4096 Edge
>>f040.xor
>>  19:  0  0  0  0  pMSI 6144 Edge
>>f042.xor
>>  20:  0  0  0  0  pMSI 8192 Edge
>>f044.xor
>>  21:  0  0  0  0  pMSI 10240 Edge
>> f046.xor
>>  22:  0  0  0  0  pMSI 12288 Edge
>> f26a.xor
>>  23:  0  0  0  0  pMSI 14336 Edge
>> f26c.xor
>>  24:  0  0  0  0  pMSI 16384 Edge
>> f46a.xor
>>  25:  0  0  0  0  pMSI 18432 Edge
>> f46c.xor
>>  26:  0  0  0  0
>> f03f0100.interrupt-controller  17 Level arm-pmu
>>  27:  0  0  0  0  ICU.f21e  22
>> Level armada8k-pcie, PCIe PME, aerdrv
>>  72: 13  0  0  0  ICU.f41e  40
>> Level eth2
>>  73:  0 10  0  0  ICU.f41e  44
>> Level eth2
>>  74:  0  0 29  0  ICU.f41e  48
>> Level eth2
>>  75:  0  0  0 45  ICU.f41e  52
>> Level eth2
>>  76: 36  0  0 55  ICU.f41e  56
>> Level eth2
>>  78:440  0 42  0  ICU.f21e  27
>> Level mmc1
>>  79:  0  0  0  0  ICU.f41e  77
>> Level f4284000.rtc
>>  80:  0  0  0  0  ICU.f21e 120
>> Level mv64xxx_i2c
>>  81:  0  0  0  0  ICU.f21e 121
>> Level mv64xxx_i2c
>>  82:  0  0  0  0  ICU.f21e 106
>> Level xhci-hcd:usb1
>>  83:  0  0  0  0  ICU.f21e 105
>> Level xhci-hcd:usb3
>>  84:  0  0  0  0  ICU.f41e 106
>> Level xhci-hcd:usb5
>>  85:  0  0  0  0  ICU.f21e 107
>> Level ahci[f254.sata]
>>  86:268  0  0  0  ICU.f41e 107
>> Level ahci[f454.sata]
>> IPI0:  2254   2458   1876   1844   Rescheduling 
>> interrupts
>> IPI1:   110107299165   Function call 
>> interrupts
>> IPI2: 0  0  0  0   CPU stop interrupts
>> IPI3: 0  0  0  0   CPU stop (for
>> crash dump) interrupts
>> IPI4: 0  0  0  0   Timer broadcast
>> interrupts
>> IPI5: 1  0  0  0   IRQ work interrupts
>> IPI6:

Hang loading omap_rng on MacchiatoBin with 4.15-rc7

2018-01-09 Thread Riku Voipio
Hi,

Loading omap_rng module on McBin causes hangup (in about 9/10 times).
Looking at /proc/interrupts it seems the interrupt starts running like
crazy, and after a while the whole system is unresponsive. This with
Debian kernel (everything possible as modules) and EFI as bootloader.
The EFI firmware appears[1] to use the rng unit to provide a seed for
KASRL, I wonder if the driver needs to depend less on the state left
by firmware, or the firmware needs to de-initialize the RNG before
booting.

root@debian:~# cat /proc/interrupts
   CPU0   CPU1   CPU2   CPU3
  1:  0  0  0  0 GICv2  25 Level vgic
  3:   1268   1983   1175   1139 GICv2  30 Level
  arch_timer
  4:  0  0  0  0 GICv2  27 Level
  kvm guest timer
  7:   1956  0  0  0 GICv2  51 Level ttyS0
  9:   4472  0307  0 GICv2  48 Level mmc0
 18:  0  0  0  0  pMSI 4096 Edge
   f040.xor
 19:  0  0  0  0  pMSI 6144 Edge
   f042.xor
 20:  0  0  0  0  pMSI 8192 Edge
   f044.xor
 21:  0  0  0  0  pMSI 10240 Edge
f046.xor
 22:  0  0  0  0  pMSI 12288 Edge
f26a.xor
 23:  0  0  0  0  pMSI 14336 Edge
f26c.xor
 24:  0  0  0  0  pMSI 16384 Edge
f46a.xor
 25:  0  0  0  0  pMSI 18432 Edge
f46c.xor
 26:  0  0  0  0
f03f0100.interrupt-controller  17 Level arm-pmu
 27:  0  0  0  0  ICU.f21e  22
Level armada8k-pcie, PCIe PME, aerdrv
 72: 13  0  0  0  ICU.f41e  40
Level eth2
 73:  0 10  0  0  ICU.f41e  44
Level eth2
 74:  0  0 29  0  ICU.f41e  48
Level eth2
 75:  0  0  0 45  ICU.f41e  52
Level eth2
 76: 36  0  0 55  ICU.f41e  56
Level eth2
 78:440  0 42  0  ICU.f21e  27
Level mmc1
 79:  0  0  0  0  ICU.f41e  77
Level f4284000.rtc
 80:  0  0  0  0  ICU.f21e 120
Level mv64xxx_i2c
 81:  0  0  0  0  ICU.f21e 121
Level mv64xxx_i2c
 82:  0  0  0  0  ICU.f21e 106
Level xhci-hcd:usb1
 83:  0  0  0  0  ICU.f21e 105
Level xhci-hcd:usb3
 84:  0  0  0  0  ICU.f41e 106
Level xhci-hcd:usb5
 85:  0  0  0  0  ICU.f21e 107
Level ahci[f254.sata]
 86:268  0  0  0  ICU.f41e 107
Level ahci[f454.sata]
IPI0:  2254   2458   1876   1844   Rescheduling interrupts
IPI1:   110107299165   Function call interrupts
IPI2: 0  0  0  0   CPU stop interrupts
IPI3: 0  0  0  0   CPU stop (for
crash dump) interrupts
IPI4: 0  0  0  0   Timer broadcast
interrupts
IPI5: 1  0  0  0   IRQ work interrupts
IPI6: 0  0  0  0   CPU wake-up interrupts
Err:  0
root@debian:~# modprobe omap_rng
root@debian:~# cat /proc/interrupts
   CPU0   CPU1   CPU2   CPU3
  1:  0  0  0  0 GICv2  25 Level vgic
  3:   1795   2736   1663   1620 GICv2  30 Level
  arch_timer
  4:  0  0  0  0 GICv2  27 Level
  kvm guest timer
  7:   2183  0  0  0 GICv2  51 Level ttyS0
  9:   4472  0   1759  0 GICv2  48 Level mmc0
 18:  0  0  0  0  pMSI 4096 Edge
   f040.xor
 19:  0  0  0  0  pMSI 6144 Edge
   f042.xor
 20:  0  0  0  0  pMSI 8192 Edge
   f044.xor
 21:  0  0  0  0  pMSI 10240 Edge
f046.xor
 22:  0  0  0  0  pMSI 12288 Edge
f26a.xor
 23:  0  0  0  0  pMSI 14336 Edge
f26c.xor
 24:  0  0  0  0  pMSI 16384 Edge
f46a.xor
 25:  0  0  0  0  pMSI 18432 Edge
f46c.xor
 26:  0  0  0  0
f03f0100.interrupt-controller  17 Level