- Original Message -
From: "Steven Hartland"
Sounds like you have made some good progress. I looked at your prior locking
change and they good. Haven't had time to go through the queue changes
yet.
Just to update people on this, as its taken quite some time to track down the
random
- Original Message -
From: "Doug Ambrisko"
To: "Steven Hartland"
Cc: ;
Sent: Friday, November 09, 2012 5:25 PM
Subject: Re: mfi panic on recused on non-recusive mutex MFI I/O lock
On Fri, Nov 09, 2012 at 05:06:03PM -, Steven Hartland wrote:
|
| --
On Fri, Nov 09, 2012 at 05:06:03PM -, Steven Hartland wrote:
|
| - Original Message -
| From: "Steven Hartland"
| ...
| >I've just had another panic, trace below, but it doesn't seem to be related
| >to my changes so I'd appreciate your feedback on them as they are for now.
| >
| >Whi
- Original Message -
From: "Steven Hartland"
...
I've just had another panic, trace below, but it doesn't seem to be related
to my changes so I'd appreciate your feedback on them as they are for now.
While the lock patch fixes the problems I've seen, its not clear to me
why mfi_tbolt_
ore locking
panics during todays tests anyway, requiring additional fixes. Will update
and post when I'm happy with it.
OK two patches attached
== zz-mfi-lock.patch ==
Fixes mfi panic on recused on non-recusive mutex MFI I/O lock
Removes a mtx_unlock call for mfi_io_lock which is never aq
- Original Message -
From: "Doug Ambrisko"
On Tue, Nov 06, 2012 at 12:09:42AM -, Steven Hartland wrote:
| Thanks Doug, actually just finished another test run with some more
| debugging in and I believe I've found the reason for the non-recusive
| lock and at least some of the queu
On Tue, Nov 06, 2012 at 12:09:42AM -, Steven Hartland wrote:
| Thanks Doug, actually just finished another test run with some more
| debugging in and I believe I've found the reason for the non-recusive
| lock and at least some of the queuing issues.
|
| The non-recursive lock is due to the mf
riginal Message -
From: "Doug Ambrisko"
To: "Steven Hartland"
Cc: ;
Sent: Monday, November 05, 2012 9:29 PM
Subject: Re: mfi panic on recused on non-recusive mutex MFI I/O lock
On Mon, Nov 05, 2012 at 04:55:11PM -, Steven Hartland wrote:
| I've managed to get
I've managed to get the machine to reproduce this fairly regularly
now.
Without a debug kernel it still results in a panic, just at a later
stage or so I believe, the none debug panic messages is "command not
in queue".
In each none debug panic I've seen the cm_flags indicates the
command being
Testing a new machine which is based on 8.3-RELEASE with the mfi
driver from 8-STABLE and just got a panic.
The below is translation of the hand copied from console:-
mfi0: sense error 0, sense_key 0, asc 0, ascq 0
mfisyspd5: hard error cmd=write 90827650-90827905
mfi0: I/O error, status= 46 scs
10 matches
Mail list logo
