linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ming Lei <tom.leiming@gmail.com>,
	John David Anglin <dave.anglin@bell.net>
Cc: Helge Deller <deller@gmx.de>,
	linux-block@vger.kernel.org,
	Linux SCSI List <linux-scsi@vger.kernel.org>,
	linux-parisc List <linux-parisc@vger.kernel.org>,
	Kent Overstreet <kent.overstreet@gmail.com>
Subject: Re: [BUG] "block: make generic_make_request handle arbitrarily sized bios" breaks boot on parisc-linux
Date: Wed, 09 Mar 2016 07:55:11 -0500	[thread overview]
Message-ID: <1457528111.2693.4.camel@HansenPartnership.com> (raw)
In-Reply-To: <CACVXFVM5nLDFGcoo173sK4E3TC4k7c+=Fvin0eAxStAdwx8yXA@mail.gmail.com>

On Thu, 2016-02-25 at 11:38 +0800, Ming Lei wrote:
> On Thu, Feb 25, 2016 at 7:28 AM, John David Anglin <
> dave.anglin@bell.net> wrote:
> > On 2016-02-24, at 4:36 PM, Helge Deller wrote:
> > 
> > > Maybe Dave has more luck, otherwise I'll continue to try to get
> > > some info.
> > 
> > I tried your patch on the commit in linux-block which first failed
> > to boot.  As with Helge, the
> > system crashed and no useful data was output on console.  I then
> > applied following patch
> > to give some extra segments and tired again:
> > 
> > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > index b1a2631..b421f03 100644
> > --- a/drivers/scsi/scsi_lib.c
> > +++ b/drivers/scsi/scsi_lib.c
> > @@ -595,6 +595,11 @@ static int scsi_alloc_sgtable(struct
> > scsi_data_buffer *sdb, int nents, bool mq)
> > 
> >         BUG_ON(!nents);
> > 
> > +       /* Provide extra entries in case of split.  */
> > +       nents += 8;
> > +       if (nents > SCSI_MAX_SG_SEGMENTS)
> > +               nents = SCSI_MAX_SG_SEGMENTS;
> > +
> 
> Yeah, this is needed for sake of safety.
> 
> >         if (mq) {
> >                 if (nents <= SCSI_MAX_SG_SEGMENTS) {
> >                         sdb->table.nents = nents;
> > 
> > The attached file shows the crash in first boot.  The second boot
> > was successful and various output
> > was generated by your check code.
> 
> From the following log(just select one simple, and looks all are
> similar) in
> 2nd boot, the bi_phys_segments is figured out as one by block core
> , which is wrong because the max segment size is 64k according to
> your investigation in the below link, but the whole req/bio is
> 192k(4k*48).
> 
>     http://www.spinics.net/lists/linux-parisc/msg06749.html
> 
> Looks weird, it shouldn't have happened because
> blk_bio_segment_split()
> does respect the max segment size limit.
> 
> BTW, what is the scsi driver for the device?
> 
> blk_rq_map_sg: merge bug: 3 1, extra_len 0, dma_drain 0
> check_bvec: dump bvec for 000000007e53c5f0(f:24490000, t:1)
>             0: 0 4096 245852 000000007e2c4c40
>             1: 0 4096 245853 000000007e2c4c40
>             2: 0 4096 245854 000000007e2c4c40
>             3: 0 4096 245855 000000007e2c4c40
>             4: 0 4096 245856 000000007e2c4c40
>             5: 0 4096 245857 000000007e2c4c40
>             6: 0 4096 245858 000000007e2c4c40
>             7: 0 4096 245859 000000007e2c4c40
>             8: 0 4096 245860 000000007e2c4c40
>             9: 0 4096 245861 000000007e2c4c40
>            10: 0 4096 245862 000000007e2c4c40
>            11: 0 4096 245863 000000007e2c4c40
>            12: 0 4096 245864 000000007e2c4c40
>            13: 0 4096 245865 000000007e2c4c40
>            14: 0 4096 245866 000000007e2c4c40
>            15: 0 4096 245867 000000007e2c4c40
>            16: 0 4096 245868 000000007e2c4c40
>            17: 0 4096 245869 000000007e2c4c40
>            18: 0 4096 245870 000000007e2c4c40
>            19: 0 4096 245871 000000007e2c4c40
>            20: 0 4096 245872 000000007e2c4c40
>            21: 0 4096 245873 000000007e2c4c40
>            22: 0 4096 245874 000000007e2c4c40
>            23: 0 4096 245875 000000007e2c4c40
>            24: 0 4096 245876 000000007e2c4c40
>            25: 0 4096 245877 000000007e2c4c40
>            26: 0 4096 245878 000000007e2c4c40
>            27: 0 4096 245879 000000007e2c4c40
>            28: 0 4096 245880 000000007e2c4c40
>            29: 0 4096 245881 000000007e2c4c40
>            30: 0 4096 245882 000000007e2c4c40
>            31: 0 4096 245883 000000007e2c4c40
>            32: 0 4096 245884 000000007e2c4c40
>            33: 0 4096 245885 000000007e2c4c40
>            34: 0 4096 245886 000000007e2c4c40
>            35: 0 4096 245887 000000007e2c4c40
>            36: 0 4096 245888 000000007e2c4c40
>            37: 0 4096 245889 000000007e2c4c40
>            38: 0 4096 245890 000000007e2c4c40
>            39: 0 4096 245891 000000007e2c4c40
>            40: 0 4096 245892 000000007e2c4c40
>            41: 0 4096 245893 000000007e2c4c40
>            42: 0 4096 245894 000000007e2c4c40
>            43: 0 4096 245895 000000007e2c4c40
>            44: 0 4096 245896 000000007e2c4c40
>            45: 0 4096 245897 000000007e2c4c40
>            46: 0 4096 245898 000000007e2c4c40
>            47: 0 4096 245899 000000007e2c4c40


We've provided all the information you asked for, what's the next step
on this, or do we have to unwind the bio splitting code with reverts
until it starts working?

Thanks,

James



  parent reply	other threads:[~2016-03-09 12:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-24  2:28 [BUG] "block: make generic_make_request handle arbitrarily sized bios" breaks boot on parisc-linux John David Anglin
2016-02-24  7:59 ` Ming Lei
2016-02-24 21:36   ` Helge Deller
2016-02-24 23:28     ` John David Anglin
2016-02-25  3:38       ` Ming Lei
2016-02-25 10:10         ` Aw: " Helge Deller
2016-03-09 12:55         ` James Bottomley [this message]
2016-03-09 14:43           ` Ming Lei
2016-03-09 15:15             ` John David Anglin
2016-03-09 15:51               ` Ming Lei
2016-03-09 21:20               ` Helge Deller
2016-03-10  0:16                 ` James Bottomley
2016-03-10  7:04                 ` Rolf Eike Beer
2016-03-20 18:12                   ` Helge Deller

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=1457528111.2693.4.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=dave.anglin@bell.net \
    --cc=deller@gmx.de \
    --cc=kent.overstreet@gmail.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=tom.leiming@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).