> I wonder if we are preventing scsi_device_dev_release_usercontext() from
> making forward progress?
>
> ...the attached patch should confirm this or give more info otherwise.
>
[ 148.960318] console [netcon0] enabled
[ 148.960363] netconsole: network logging started
[ 170.415487] mptbase: ioc
>> [ 174.758218] scsi_remove_target[0]: reap 0:0 state: 2 reap: 1 dev_del: 1
>
> Thanks! Does the attached patch fix the issue for you?
>
That worked!
[ 169.402990] netconsole: network logging started
[ 200.903700] mptbase: ioc0: LogInfo(0x31110d00): Originator={PL},
Code={Reset}, SubCode(0x0
On Thu, Aug 23, 2012 at 1:34 PM, John Drescher wrote:
> Over the last few weeks I have done some reliability testing with
> mdraid6 on a machine with 2 lsi mptsas controllers and 13 SATA I
> drives. My testing involved physically hot removing a drive forcing
> the raid to grab a spare
On Fri, Aug 24, 2012 at 3:34 PM, John Drescher wrote:
> On Thu, Aug 23, 2012 at 1:34 PM, John Drescher wrote:
>> Over the last few weeks I have done some reliability testing with
>> mdraid6 on a machine with 2 lsi mptsas controllers and 13 SATA I
>> drives. My testing in
>> I have bisected it down to the following patch:
>>
>> Bisecting: 0 revisions left to test after this (roughly 0 steps)
>> [10f8d5b86743b33d841a175303e2bf67fd620f42] SCSI: fix hot unplug vs
>> async scan race
>>
>> It appears this patch caused the bad behavior although I have not
>> tested that y
For the last few weeks I have been doing some reliability testing on a
mdraid6 array. One of my test was to physically hot remove a raid
member disk. This worked flawlessly with gentoo-sources-3.5.0 for the
5 or so times I tried it with my 12 disk + 1 spare mdraid6 array.
After pulling a disk a fe
On Fri, Aug 17, 2012 at 6:30 PM, John Drescher wrote:
> For the last few weeks I have been doing some reliability testing on a
> mdraid6 array. One of my test was to physically hot remove a raid
> member disk. This worked flawlessly with gentoo-sources-3.5.0 for the
> 5 or so time
I am trying to debug this problem since it appears this is causing
mythtv to truncate recordings on top of other very long delays.
# uname -a
Linux jmd0.comcast.net 3.11.4-gentoo-jmd0 #1 SMP PREEMPT Mon Oct 7
21:04:44 EDT 2013 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz
GenuineIntel GNU/Li
8 matches
Mail list logo