Matt,
Have your resolved the unload race conditions yet?
We'd like to update lpfc for the async scans, but our testing gets blocked
very quickly by the bugs. The bugs are not necessarily specific to lpfc
or to FC.
Stack traces are below. Simple ismod/rmmod loop can trigger them
-- james s
Matthew Wilcox wrote:
On Mon, Dec 11, 2006 at 10:58:06AM -0500, Jeff Garzik wrote:
The time-consuming portion already takes place in a thread. Do you mean
multiple threads? Or, ATA's scan is in one thread, while work continues
in other threads?
Patch seems sane, provided that I am educated
Matthew Wilcox wrote:
Some of the drivers (AHCI was mentioned to me as a culprit) take a long
time to discover all the devices attached to them. Even for ones which
are relatively quick, if you put a lot of them in a machine, it will
take a long time in aggregate. This can be fixed by adding
On Mon, Dec 11, 2006 at 10:58:06AM -0500, Jeff Garzik wrote:
The time-consuming portion already takes place in a thread. Do you mean
multiple threads? Or, ATA's scan is in one thread, while work continues
in other threads?
Patch seems sane, provided that I am educated a bit :)
Each host
Matthew Wilcox wrote:
Some of the drivers (AHCI was mentioned to me as a culprit) take a long
time to discover all the devices attached to them. Even for ones which
are relatively quick, if you put a lot of them in a machine, it will
take a long time in aggregate. This can be fixed by adding
On Mon, Dec 11, 2006 at 11:18:17AM -0500, Jeff Garzik wrote:
ACK. I tried to apply the patch, but git-applymbox choked on every
single file modified. Quite possibly, its due to a whitespace cleanup
in Alan territory.
If you would either (a) wait several hours for libata-dev.git#upstream
since I wrote the patch. I also added a couple of missing slave_destroy
methods to the newly-added drivers.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
... this time with patch ...
Add support for asynchronous scans to libata
Some of the drivers (AHCI was mentioned to me as a culprit
