On 2018-08-20 10:39, Arnd Bergmann wrote:
On Mon, Aug 20, 2018 at 4:17 PM Mikulas Patocka <mpatocka@xxxxxxxxxx>
wrote:
On Sun, 19 Aug 2018, okaya@xxxxxxxxxxxxxx wrote:
> +my new email
>
> On 2018-08-18 19:03, Arnd Bergmann wrote:
> > On Sat, Aug 18, 2018 at 12:05 AM Maciej W. Rozycki <macro@xxxxxxxxxxxxxx>
> I think we need to identify the driver that is failing.
It also may be some timing issue.
I observed that not every kernel with the patch
92d7223a74235054f2aa7227d207d9c57f84dca0 fails, some of them get stuck
only at boot, some get stuck only at shutdown, some not at all.
Although
all the kernels with this patch reverted work.
So the patch may have uncovered some timing problem somewhere.
x86 has the function io_delay that injects delays between I/O accesses
for
hardware that needs it - does alpha have something like this?
The I/O delay would be very low on my list of possible root causes
for this, hardly any hardware at all relies on it, and all uses I see
are related to outb(), which you've already shown not to be the problem
with my test patch.
How about interrupt controller code?
Which drivers does this Arch use in the failing system?
If drivers are using raw API or direct memory manipulation after writel,
they could be in trouble.
Is there any ordering guarantee regarding register writes with respect
to reads following ?
Arnd
