All of lore.kernel.org
 help / color / mirror / Atom feed
From: FUJITA Tomonori <tomof@acm.org>
To: just.for.lkml@googlemail.com
Cc: jens.axboe@oracle.com, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org, linux-scsi@vger.kernel.org,
	linux-ide@vger.kernel.org, fujita.tomonori@lab.ntt.co.jp
Subject: Re: What's in linux-2.6-block.git for 2.6.24
Date: Sun, 23 Sep 2007 22:55:11 +0900	[thread overview]
Message-ID: <20070923225320I.tomof@acm.org> (raw)
In-Reply-To: <64bb37e0709230619v196cf34ev29f0c844e2a79ec9@mail.gmail.com>

On Sun, 23 Sep 2007 15:19:13 +0200
"Torsten Kaiser" <just.for.lkml@googlemail.com> wrote:

> On 9/21/07, Jens Axboe <jens.axboe@oracle.com> wrote:
> > SG chaining bits:
> > - This is the bulk of the patchset. It consists of three major
> >   components:
> >
> >         - sglist-core, which add helpers for iterating sg lists and
> >           switches the block layer and SCSI to use those. Should not
> >           have any functional changes.
> >         - sglist-drivers, which converts drivers to use the sg list
> >           helpers. Again, should not contain functional changes.
> >         - sglist-arch, which adds support to most architectures and
> >           actually enables sg chaining.
> 
> Adding linux-ide and linux-scsi as CC like Andrew did with my last report.
> 
> I still have trouble with my Silicon Image, Inc. SiI 3132 Serial ATA
> Raid II Controller as reported on 2.6.23-rc4-mm1 on the new
> 2.6.23-rc6-mm1.
> 
> I'm not 100% sure if this caused by the sg chaining, but the patch
> from http://lkml.org/lkml/2007/9/10/251 which touches that chaining
> makes a difference, so it might be related.
> 
> First report: http://lkml.org/lkml/2007/9/1/92
> With patch it fails fewer times: http://lkml.org/lkml/2007/9/14/107
> 
> To update the statistik:
> prior to 2.6.23-rc4-mm1: no trouble with any drives on the SiI 3132.
> 2.6.23-rc4-mm1 without patch: 2 out of 2 bad.
> back to 2.6.23-rc3-mm1: 18x good.
> 2.6.23-rc4-mm1 with patch:  2 out of 8 bad
> after that second mail:
> 2.6.23-rc4-mm1 with patch: 1 out of 5 bad
> 2.6.23-rc6-mm1: 1 out of 2 bad

git-block.patch in 2.6.23-rc6-mm1 includes my patch that disables sg
chaining for libata but it still includes libata's sg chaining
changes. So these changes breaks libata or libata was broken after
2.6.23-rc3-mm1.

Can you try Jens's sglist-arch branch? If it works, probably libata in
-mm has bugs.

For your convenience, I put a sglist-arch branch patch against v2.6.23-rc7:

http://www.kernel.org/pub/linux/kernel/people/tomo/misc/v2.6.23-rc7-sglist-arch.diff.bz2


> switching back to 2.6.23-rc3-mm1 to rule out the hardware:
> 2.6.23-rc3-mm1: 6x good
> 
> The error messages from the failed 2.6.23-rc6-mm1:
> Sep 18 18:50:01 treogen [   33.340000] md1: bitmap initialized from
> disk: read 10/10 pages, set 0 bits
> Sep 18 18:50:01 treogen [   33.340000] created bitmap (145 pages) for device md1
> Sep 18 18:50:01 treogen [   63.440000] ata1.00: exception Emask 0x0
> SAct 0x1 SErr 0x0 action 0x6 frozen
> Sep 18 18:50:01 treogen [   63.440000] ata1.00: cmd
> 61/08:00:09:d6:42/00:00:25:00:00/40 tag 0 cdb 0x0 data 4096 out
> Sep 18 18:50:01 treogen [   63.440000]          res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Sep 18 18:50:01 treogen [   63.440000] ata1.00: status: {DRDY }
> Sep 18 18:50:01 treogen [   63.440000] ata1: hard resetting link
> Sep 18 18:50:01 treogen [   65.740000] ata1: softreset failed (port not ready)
> Sep 18 18:50:01 treogen [   65.740000] ata1: reset failed (errno=-5),
> retrying in 8 secs
> Sep 18 18:50:01 treogen [   73.440000] ata1: hard resetting link
> Sep 18 18:50:01 treogen [   75.740000] ata1: softreset failed (port not ready)
> Sep 18 18:50:01 treogen [   75.740000] ata1: reset failed (errno=-5),
> retrying in 8 secs
> Sep 18 18:50:01 treogen [   83.440000] ata1: hard resetting link
> Sep 18 18:50:01 treogen [   85.740000] ata1: softreset failed (port not ready)
> Sep 18 18:50:01 treogen [   85.740000] ata1: reset failed (errno=-5),
> retrying in 33 secs
> Sep 18 18:50:01 treogen [  118.440000] ata1: limiting SATA link speed
> to 1.5 Gbps
> Sep 18 18:50:01 treogen [  118.440000] ata1: hard resetting link
> Sep 18 18:50:01 treogen [  120.740000] ata1: softreset failed (port not ready)
> Sep 18 18:50:01 treogen [  120.740000] ata1: reset failed, giving up
> Sep 18 18:50:01 treogen [  120.740000] ata1.00: disabled
> Sep 18 18:50:01 treogen [  120.740000] ata1: EH complete
> Sep 18 18:50:01 treogen [  120.740000] sd 0:0:0:0: [sda] Result:
> hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
> Sep 18 18:50:01 treogen [  120.740000] end_request: I/O error, dev
> sda, sector 625137161
> Sep 18 18:50:01 treogen [  120.740000] md: super_written gets
> error=-5, uptodate=0
> Sep 18 18:50:01 treogen [  120.740000] raid5: Disk failure on sda2,
> disabling device. Operation continuing on 2 devices
> 
> After that many more errors like this, only differing in the sector number:
> Sep 18 18:50:01 treogen [  120.810000] sd 0:0:0:0: [sda] Result:
> hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
> Sep 18 18:50:01 treogen [  120.810000] end_request: I/O error, dev
> sda, sector 19550919
> 
> Any more infos needed?
> 
> Torsten
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: FUJITA Tomonori <tomof@acm.org>
To: just.for.lkml@googlemail.com
Cc: jens.axboe@oracle.com, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org, linux-scsi@vger.kernel.org,
	linux-ide@vger.kernel.org
Cc: fujita.tomonori@lab.ntt.co.jp
Subject: Re: What's in linux-2.6-block.git for 2.6.24
Date: Sun, 23 Sep 2007 22:55:11 +0900	[thread overview]
Message-ID: <20070923225320I.tomof@acm.org> (raw)
In-Reply-To: <64bb37e0709230619v196cf34ev29f0c844e2a79ec9@mail.gmail.com>

On Sun, 23 Sep 2007 15:19:13 +0200
"Torsten Kaiser" <just.for.lkml@googlemail.com> wrote:

> On 9/21/07, Jens Axboe <jens.axboe@oracle.com> wrote:
> > SG chaining bits:
> > - This is the bulk of the patchset. It consists of three major
> >   components:
> >
> >         - sglist-core, which add helpers for iterating sg lists and
> >           switches the block layer and SCSI to use those. Should not
> >           have any functional changes.
> >         - sglist-drivers, which converts drivers to use the sg list
> >           helpers. Again, should not contain functional changes.
> >         - sglist-arch, which adds support to most architectures and
> >           actually enables sg chaining.
> 
> Adding linux-ide and linux-scsi as CC like Andrew did with my last report.
> 
> I still have trouble with my Silicon Image, Inc. SiI 3132 Serial ATA
> Raid II Controller as reported on 2.6.23-rc4-mm1 on the new
> 2.6.23-rc6-mm1.
> 
> I'm not 100% sure if this caused by the sg chaining, but the patch
> from http://lkml.org/lkml/2007/9/10/251 which touches that chaining
> makes a difference, so it might be related.
> 
> First report: http://lkml.org/lkml/2007/9/1/92
> With patch it fails fewer times: http://lkml.org/lkml/2007/9/14/107
> 
> To update the statistik:
> prior to 2.6.23-rc4-mm1: no trouble with any drives on the SiI 3132.
> 2.6.23-rc4-mm1 without patch: 2 out of 2 bad.
> back to 2.6.23-rc3-mm1: 18x good.
> 2.6.23-rc4-mm1 with patch:  2 out of 8 bad
> after that second mail:
> 2.6.23-rc4-mm1 with patch: 1 out of 5 bad
> 2.6.23-rc6-mm1: 1 out of 2 bad

git-block.patch in 2.6.23-rc6-mm1 includes my patch that disables sg
chaining for libata but it still includes libata's sg chaining
changes. So these changes breaks libata or libata was broken after
2.6.23-rc3-mm1.

Can you try Jens's sglist-arch branch? If it works, probably libata in
-mm has bugs.

For your convenience, I put a sglist-arch branch patch against v2.6.23-rc7:

http://www.kernel.org/pub/linux/kernel/people/tomo/misc/v2.6.23-rc7-sglist-arch.diff.bz2


> switching back to 2.6.23-rc3-mm1 to rule out the hardware:
> 2.6.23-rc3-mm1: 6x good
> 
> The error messages from the failed 2.6.23-rc6-mm1:
> Sep 18 18:50:01 treogen [   33.340000] md1: bitmap initialized from
> disk: read 10/10 pages, set 0 bits
> Sep 18 18:50:01 treogen [   33.340000] created bitmap (145 pages) for device md1
> Sep 18 18:50:01 treogen [   63.440000] ata1.00: exception Emask 0x0
> SAct 0x1 SErr 0x0 action 0x6 frozen
> Sep 18 18:50:01 treogen [   63.440000] ata1.00: cmd
> 61/08:00:09:d6:42/00:00:25:00:00/40 tag 0 cdb 0x0 data 4096 out
> Sep 18 18:50:01 treogen [   63.440000]          res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Sep 18 18:50:01 treogen [   63.440000] ata1.00: status: {DRDY }
> Sep 18 18:50:01 treogen [   63.440000] ata1: hard resetting link
> Sep 18 18:50:01 treogen [   65.740000] ata1: softreset failed (port not ready)
> Sep 18 18:50:01 treogen [   65.740000] ata1: reset failed (errno=-5),
> retrying in 8 secs
> Sep 18 18:50:01 treogen [   73.440000] ata1: hard resetting link
> Sep 18 18:50:01 treogen [   75.740000] ata1: softreset failed (port not ready)
> Sep 18 18:50:01 treogen [   75.740000] ata1: reset failed (errno=-5),
> retrying in 8 secs
> Sep 18 18:50:01 treogen [   83.440000] ata1: hard resetting link
> Sep 18 18:50:01 treogen [   85.740000] ata1: softreset failed (port not ready)
> Sep 18 18:50:01 treogen [   85.740000] ata1: reset failed (errno=-5),
> retrying in 33 secs
> Sep 18 18:50:01 treogen [  118.440000] ata1: limiting SATA link speed
> to 1.5 Gbps
> Sep 18 18:50:01 treogen [  118.440000] ata1: hard resetting link
> Sep 18 18:50:01 treogen [  120.740000] ata1: softreset failed (port not ready)
> Sep 18 18:50:01 treogen [  120.740000] ata1: reset failed, giving up
> Sep 18 18:50:01 treogen [  120.740000] ata1.00: disabled
> Sep 18 18:50:01 treogen [  120.740000] ata1: EH complete
> Sep 18 18:50:01 treogen [  120.740000] sd 0:0:0:0: [sda] Result:
> hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
> Sep 18 18:50:01 treogen [  120.740000] end_request: I/O error, dev
> sda, sector 625137161
> Sep 18 18:50:01 treogen [  120.740000] md: super_written gets
> error=-5, uptodate=0
> Sep 18 18:50:01 treogen [  120.740000] raid5: Disk failure on sda2,
> disabling device. Operation continuing on 2 devices
> 
> After that many more errors like this, only differing in the sector number:
> Sep 18 18:50:01 treogen [  120.810000] sd 0:0:0:0: [sda] Result:
> hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
> Sep 18 18:50:01 treogen [  120.810000] end_request: I/O error, dev
> sda, sector 19550919
> 
> Any more infos needed?
> 
> Torsten
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2007-09-23 13:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-21  8:57 What's in linux-2.6-block.git for 2.6.24 Jens Axboe
2007-09-21  9:15 ` Andrew Morton
2007-09-21  9:24   ` Jens Axboe
2007-09-21  9:36     ` Jens Axboe
2007-09-23 13:19 ` Torsten Kaiser
2007-09-23 13:55   ` FUJITA Tomonori [this message]
2007-09-23 13:55     ` FUJITA Tomonori
2007-09-23 15:31     ` Torsten Kaiser
2007-09-24 18:48       ` Torsten Kaiser
2007-09-25  5:52         ` Torsten Kaiser
2007-09-23 14:11   ` Alan Cox
2007-09-23 15:40     ` Torsten Kaiser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070923225320I.tomof@acm.org \
    --to=tomof@acm.org \
    --cc=akpm@linux-foundation.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=jens.axboe@oracle.com \
    --cc=just.for.lkml@googlemail.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.