Hello,
I've encountered a similiar error like Matthias Prager did in his first
mail in this thread in 2012.
I use Debian 8 Kernel 3.16 and also own a LSI 2008 card flashed to IT
mode (firmware P20) and have problems with disks that were spun down.
Writing to them when they are spun down
On 07/25/2012 03:55 PM, James Bottomley wrote:
Well, reading it, so do I. Unfortunately, we get to deal with the world
as it is rather than as we would wish it to be. We likely have this
problem with a lot of USB SATLs as well ...
Has this patch made it into the main git trees yet?
I
Am 16.08.2012 20:26, schrieb Robert Trace:
On 07/25/2012 03:55 PM, James Bottomley wrote:
Well, reading it, so do I. Unfortunately, we get to deal with the world
as it is rather than as we would wish it to be. We likely have this
problem with a lot of USB SATLs as well ...
Has this patch
On 08/16/2012 04:24 PM, Matthias Prager wrote:
Not yet, but it is in James scsi misc tree and last I heard was
scheduled for inclusion in the 3.6 kernel.
Close enough. :-) I didn't track the changes on the SCSI tree and I
just wanted to make sure that it didn't slip through the cracks.
On 07/25/2012 07:56 PM, Matthias Prager wrote:
I don't yet understand all the code but I'm following your discussion
with Tejun: I've set up a minimal vm running gentoo with a mpt2sas
driven controller in passthrough mode. I've applied your proposed patch
against the vanilla 3.5.0 kernel
On 07/25/2012 06:35 PM, tomm wrote:
If this is a driver or firmware bug, then why would commit
85ef06d1d252f6a2e73b678591ab71caad4667bb
cause this to happen? What is the interaction between this issue
and this commit which just flushes events?
That's confusing to me as well. Tejun's patch
[mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Matthias Prager
Sent: Wednesday, July 25, 2012 3:34 AM
To: Tejun Heo
Cc: Robert Trace; linux-scsi@vger.kernel.org; Jens Axboe; Moore, Eric;
James E.J. Bottomley; Alan; Darrick J. Wong; Matthias Prager
Subject: Re: 'Device not ready' issue
On Sun, 2012-07-22 at 10:31 -0700, Tejun Heo wrote:
Hello,
On Sat, Jul 21, 2012 at 02:15:56PM +0200, Matthias Prager wrote:
Now I'm not sure this isn't taping over another bug. Which leads me to
my question: What is the correct behavior?
#1 Issuing a separate spin-up command (START
Hello, James.
On Wed, Jul 25, 2012 at 06:19:13PM +0400, James Bottomley wrote:
I haven't consulted SAT but it seems like a bug in SAS driver or
firmware. If it's a driver bug, we better fix it there. If a
firmware bug, working around those is one of major roles of drivers,
so I think
On Wed, 2012-07-25 at 10:17 -0700, Tejun Heo wrote:
Hello, James.
On Wed, Jul 25, 2012 at 06:19:13PM +0400, James Bottomley wrote:
I haven't consulted SAT but it seems like a bug in SAS driver or
firmware. If it's a driver bug, we better fix it there. If a
firmware bug, working
Tejun Heo tj at kernel.org writes:
Hello,
On Sat, Jul 21, 2012 at 02:15:56PM +0200, Matthias Prager wrote:
Now I'm not sure this isn't taping over another bug. Which leads me to
my question: What is the correct behavior?
#1 Issuing a separate spin-up command (START UNIT?) prior to
Hello James,
Am 25.07.2012 21:55, schrieb James Bottomley:
It looks like a hack like this might be needed.
James
SNIP
I don't yet understand all the code but I'm following your discussion
with Tejun: I've set up a minimal vm running gentoo with a mpt2sas
driven controller in passthrough
Hello everyone,
I retested with a new firmware (P14 - released today), since it contains
a bunch of sata and SATL fixes (according to the changelog).
Unfortunately the observed behavior is unchanged (tested on a 3.4.5 kernel).
Just wanted to let everyone know.
Cheers
Matthias
--
To unsubscribe
Hello,
On Sat, Jul 21, 2012 at 02:15:56PM +0200, Matthias Prager wrote:
Now I'm not sure this isn't taping over another bug. Which leads me to
my question: What is the correct behavior?
#1 Issuing a separate spin-up command (START UNIT?) prior to sending i/o
by setting allow_restart=1 for
Hello Tejun,
Am 22.07.2012 19:31, schrieb Tejun Heo:
I haven't consulted SAT but it seems like a bug in SAS driver or
firmware. If it's a driver bug, we better fix it there. If a
firmware bug, working around those is one of major roles of drivers,
so I think setting allow_restart is fine.
Am 17.07.2012 22:01, schrieb Tejun Heo:
On Tue, Jul 17, 2012 at 09:39:41PM +0200, Matthias Prager wrote:
I could not however reproduce the issue on any other device than a LSI
SAS controller (using SATA disks) - on a regular ICH10 using AHCI and a
SATA drive I don't see these i/o errors. But
Hello,
On Wed, Jul 11, 2012 at 03:48:00PM +0200, Matthias Prager wrote:
I just tested kernel version 3.4.4 without commit
85ef06d1d252f6a2e73b678591ab71caad4667bb and it also works fine (beware
of commit 62d3c5439c534b0e6c653fc63e6d8c67be3a57b1 as it conflicts with
reverting
Hello Tejun,
Am 17.07.2012 20:09, schrieb Tejun Heo:
Hello,
On Wed, Jul 11, 2012 at 03:48:00PM +0200, Matthias Prager wrote:
I'm trying to understand why this commit leads to the issue of i/o
failing on spun down drives, in hopes of being able to fix it. Meanwhile
maybe Tejun Heo (author
Hello,
On Tue, Jul 17, 2012 at 09:39:41PM +0200, Matthias Prager wrote:
I could not however reproduce the issue on any other device than a LSI
SAS controller (using SATA disks) - on a regular ICH10 using AHCI and a
SATA drive I don't see these i/o errors. But since I'm experiencing
these
Am 11.07.2012 01:27, schrieb Robert Trace:
On 07/09/2012 09:51 PM, Robert Trace wrote:
Huh.. I just retested this and I'm seeing really random behavior.
Ok, with a refined test I've been able to reliably reproduce this and I
bisected it back to commit
I just tested kernel version 3.4.4 without commit
85ef06d1d252f6a2e73b678591ab71caad4667bb and it also works fine (beware
of commit 62d3c5439c534b0e6c653fc63e6d8c67be3a57b1 as it conflicts with
reverting 85ef06d1d252f6a2e73b678591ab71caad4667bb).
I'm trying to understand why this commit leads to
On 07/09/2012 09:51 PM, Robert Trace wrote:
Huh.. I just retested this and I'm seeing really random behavior.
Ok, with a refined test I've been able to reliably reproduce this and I
bisected it back to commit 85ef06d1d252f6a2e73b678591ab71caad4667bb in
Linus' tree (introduced between 3.0 and
Hello linux-scsi and linux-raid,
I did some further research regarding my problem.
It appears to me the fault does not lie with the mpt2sas driver (not
that I can definitely exclude it), but with the md implementation.
I reproduced what I think is the same issue on a different machine (also
I did some further research regarding my problem.
It appears to me the fault does not lie with the mpt2sas driver (not
that I can definitely exclude it), but with the md implementation.
I'm actually discovering some of the same issues (LSI 9211-8i w/ SATA
disks), but I've come to a slightly
On Mon, 09 Jul 2012 16:40:15 +0200 Matthias Prager li...@matthiasprager.de
wrote:
Hello linux-scsi and linux-raid,
I did some further research regarding my problem.
It appears to me the fault does not lie with the mpt2sas driver (not
that I can definitely exclude it), but with the md
Am 10.07.2012 00:08, schrieb NeilBrown:
On Mon, 09 Jul 2012 16:40:15 +0200 Matthias Prager li...@matthiasprager.de
wrote:
Even though it says creating aborted it still created md127.
One of my pet peeves in when people interpret the observations wrongly and
then report their
Am 09.07.2012 21:37, schrieb Robert Trace:
I did some further research regarding my problem.
It appears to me the fault does not lie with the mpt2sas driver (not
that I can definitely exclude it), but with the md implementation.
I'm actually discovering some of the same issues (LSI 9211-8i
Am 10.07.2012 00:24, schrieb Robert Trace:
Also, TURs don't appear to actually wake the disk up (should they?).
The only thing I've found that'll wake the disk up is an explicit START
UNIT command.
I haven't checked the scsi logging side, but about the only commands
that wake up the disks
[removed linux-raid since the md layer seems unrelated]
On 07/09/2012 08:12 PM, Matthias Prager wrote:
I've reproduced this behavior on the raw disks themselves, no MD layer
involved (although the freak-out by my MD layer is what alerted me to
this issue too... Having your entire array punted
On 07/09/2012 08:21 PM, Matthias Prager wrote:
I haven't checked the scsi logging side, but about the only commands
that wake up the disks are 'smartctl -a /dev/sda' and 'sg_start'
(smartcl maybe issuing a START UNIT command on it's own).
smartctl -a does appear to wake the disks. The scsi
30 matches
Mail list logo
