[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <19f34abd0904080915t1a47cab4jbfe748eeaa47d675@mail.gmail.com>
Date: Wed, 8 Apr 2009 18:15:21 +0200
From: Vegard Nossum <vegard.nossum@...il.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: Jens Axboe <jens.axboe@...cle.com>,
Arjan van de Ven <arjan@...radead.org>,
Justin Madru <jdm64@...ab.com>,
lkml <linux-kernel@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: 2.6.30-rc1: invalid opcode with call trace
2009/4/8 Ingo Molnar <mingo@...e.hu>:
>
> * Jens Axboe <jens.axboe@...cle.com> wrote:
>
>> On Wed, Apr 08 2009, Vegard Nossum wrote:
>> > Would you please try this patch? It has the same symptoms as a few
>> > other reports, only that this is 32-bit (and that makes it a bit
>> > different).
>> >
>> > http://marc.info/?l=linux-kernel&m=123909566829773&w=2
>> >
>> > I think Len Brown has applied it to the ACPI tree already.
>>
>> Works for me!
>
> My 'boot hang' problem is independent of that bug i think.
I agree.
The problem is that you have two async port probes:
[ 24.177306] calling 1_async_port_probe+0x0/0xaa @ 2841
[ 24.177825] calling 2_async_port_probe+0x0/0xaa @ 2842
of which only the first completes, because the first async call itself
tries to flush the async list while holding a lock (the
&shost->scan_mutex in __scsi_add_device), causing deadlock.
In short, I don't think we should call async_synchronize_full() from
scsi_complete_async_scans() at all. I'm including a more detailed
description/justification in the patch (attached).
Arjan, can you comment?
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
Download attachment "0001-scsi-don-t-wait-for-async-operations-in-scsi_comple.patch" of type "application/octet-stream" (1759 bytes)
Powered by blists - more mailing lists