On 1/14/19 5:56 AM, Bart Van Assche wrote:
On 1/12/19 12:29 AM, Hannes Reinecke wrote:
On 1/11/19 5:10 PM, Bart Van Assche wrote:
On Fri, 2019-01-11 at 08:31 +0100, Hannes Reinecke wrote:
Could you please check if this depends on any changes to the async
probing mechanism?
Patches one and tw
On 1/12/19 12:29 AM, Hannes Reinecke wrote:
On 1/11/19 5:10 PM, Bart Van Assche wrote:
On Fri, 2019-01-11 at 08:31 +0100, Hannes Reinecke wrote:
Could you please check if this depends on any changes to the async
probing mechanism?
Patches one and two depend on driver core changes. I was assum
On 1/11/19 5:10 PM, Bart Van Assche wrote:
On Fri, 2019-01-11 at 08:31 +0100, Hannes Reinecke wrote:
Could you please check if this depends on any changes to the async
probing mechanism?
Hi Hannes,
Patches one and two depend on driver core changes. I was assuming that
these were already upstr
On Fri, 2019-01-11 at 08:31 +0100, Hannes Reinecke wrote:
> Could you please check if this depends on any changes to the async
> probing mechanism?
Hi Hannes,
Patches one and two depend on driver core changes. I was assuming that
these were already upstream but apparently that is not yet the cas
On 1/11/19 1:08 AM, Bart Van Assche wrote:
As explained during the LSF/MM session about increasing SCSI disk
probing concurrency, the problems with the current probing approach
are as follows:
- The driver core is unaware of asynchronous SCSI LUN probing.
wait_for_device_probe() waits for all
As explained during the LSF/MM session about increasing SCSI disk
probing concurrency, the problems with the current probing approach
are as follows:
- The driver core is unaware of asynchronous SCSI LUN probing.
wait_for_device_probe() waits for all asynchronous probes except
asynchronous SCSI
6 matches
Mail list logo
