On Fri, 2005-04-15 at 10:11 -0600, Moore, Eric Dean wrote:
> Thus I think its safe to say, we can remove the
> scsi_device_online from mptscsih_flush_running_cmds.
> Right??
Yes, as long as you now tear down all the outstanding commands while the
error handler is executing, you should be safe fro
On Friday, April 15, 2005 8:30 AM, James Bottomley wrote:
>
> On Fri, 2005-04-15 at 19:13 +0900, Masao Fukuchi wrote:
> > The sequence is:
> > 1.Host issues SCSI command to fusion MPT driver.
> > 2.Mid layer detects command timeout and then performs
> > error recovery sequence.
> > But the
On Fri, 2005-04-15 at 19:13 +0900, Masao Fukuchi wrote:
> The sequence is:
> 1.Host issues SCSI command to fusion MPT driver.
> 2.Mid layer detects command timeout and then performs
> error recovery sequence.
> But the sequence fails and it causes device offline.
> (fusion MPT driver still
Hi Eric.
The problem was caused by calling pci_unmap_sg()
after device offline.
The sequence is:
1.Host issues SCSI command to fusion MPT driver.
2.Mid layer detects command timeout and then performs
error recovery sequence.
But the sequence fails and it causes device offline.
(fusion M
Masao Fukuchi reported an issue when the
outstanding mf queue was being flushed in
contents of slave_destroy, the scsi dev was
offlined already by the mid-layer.
They may not be an issue anymore since I removed
the error handling timers from mptscsih.
Masao can you validate this pls?
Christoph
On Sat, Apr 02, 2005 at 02:35:57PM +0900, Tejun Heo wrote:
> Hello, Eric.
> Hello, James.
>
> I've been working on new SCSI state model and was checking on
> scsi_device_online() users. As the state model is going to change, I
> need to audit device state usages in lldd's and I'm having diffic
6 matches
Mail list logo
