On 08/28/2014 02:34 AM, James Smart wrote:
Mike,
Can you confirm - the "nulls" this patch correct are because the
probe_one and error_detect threads are running concurrently, thus
battling ?
If so - this fix looks insufficient and we should rework it.
Yes, it is. My patch is just a workaro
Mike,
Can you confirm - the "nulls" this patch correct are because the
probe_one and error_detect threads are running concurrently, thus battling ?
If so - this fix looks insufficient and we should rework it.
Q: why are they allowed to run concurrently ? I could see this solved
at the platf
On 07/17/2014 02:32 PM, Mike Qiu wrote:
Hi, all
How about this patch ?
Any idea ?
In IBM Power servers, when hardware error occurs during probe
state, EEH subsystem will call driver's error_detected interface,
which will call pci_disable_device(). But driver's probe function also
call pci_di
On 07/17/2014 10:15 PM, Joe Lawrence wrote:
[ +cc linux-pci and Bjorn, comments inline/below ... ]
On Thu, 17 Jul 2014 02:32:31 -0400
Mike Qiu wrote:
In IBM Power servers, when hardware error occurs during probe
state, EEH subsystem will call driver's error_detected interface,
which will call
[ +cc linux-pci and Bjorn, comments inline/below ... ]
On Thu, 17 Jul 2014 02:32:31 -0400
Mike Qiu wrote:
> In IBM Power servers, when hardware error occurs during probe
> state, EEH subsystem will call driver's error_detected interface,
> which will call pci_disable_device(). But driver's probe
In IBM Power servers, when hardware error occurs during probe
state, EEH subsystem will call driver's error_detected interface,
which will call pci_disable_device(). But driver's probe function also
call pci_disable_device() in this situation.
So pci_dev will be disabled twice:
Device lpfc disabl
6 matches
Mail list logo