[RESEND PATCH 0/1] Fix the "hard LOCKUP" when running a heavy loading
Huang, Tao
huangtao at rock-chips.com
Tue Nov 3 04:00:06 PST 2015
Hello Russell:
在 2015年11月03日 19:14, Russell King - ARM Linux 写道:
> On Tue, Nov 03, 2015 at 04:10:08PM +0800, Caesar Wang wrote:
>> As the Russell said:
>> "in other words, which can be handled by updating a control register in
>> the firmware or boot loader"
>> Maybe the better solution is in firmware.
>
> The full quote is:
>
> "I think we're at the point where we start insisting that workarounds
> which are simple enable/disable feature bit operations (in other words,
> which can be handled by updating a control register in the firmware or
> boot loader) must be done that way, and we are not going to add such
> workarounds to the kernel anymore."
>
> The position hasn't changed. Workarounds such as this should be handled
> in the firmware/boot loader before control is passed to the kernel.
>
> The reason is very simple: if the C compiler can generate code which
> triggers the bug, it can generate code which triggers the bug in the
> boot loader. So, the only place such workarounds can be done is before
> any C code gets executed. Putting such workarounds in the kernel is
> completely inappropriate.
I agree with your reason for CPU0. But how about CPU1~3 if we don't use
any firmware such as ARM Trusted Firmware to take control of CPU power
on? If the CPU1~3 will run on Linux when its first instruction is running?
BTW I don't want to argue with you the workaround is right or wrong
because I know the errata just happen on r0p0 not r0p1.
>
> Sorry, I'm not going to accept this workaround into the kernel.
It seems we should introduce some code outside the kernel to do such
initialization?
More information about the linux-arm-kernel
mailing list