From: Helge Deller <deller@gmx.de>
To: John David Anglin <dave.anglin@bell.net>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
linux-parisc List <linux-parisc@vger.kernel.org>
Subject: Re: SCSI bug
Date: Tue, 23 Feb 2016 19:06:26 +0100 [thread overview]
Message-ID: <56CC9FA2.6020107@gmx.de> (raw)
In-Reply-To: <38C40D56-D72B-4F87-AAF3-050391B9546D@bell.net>
On 23.02.2016 04:04, John David Anglin wrote:
> On 2016-02-21, at 10:24 PM, John David Anglin wrote:
>
>> On 2016-02-21, at 7:53 PM, John David Anglin wrote:
>>
>>> Backtrace:
>>> [<000000004046f4b0>] scsi_init_sgtable+0x70/0xb8
>>> [<000000004046f564>] scsi_init_io+0x6c/0x220
>>> [<000000000811c5c0>] sd_setup_read_write_cmnd+0x58/0x968 [sd_mod]
>>> [<000000000811cf14>] sd_init_command+0x44/0x130 [sd_mod]
>>> [<000000004046f81c>] scsi_setup_cmnd+0x104/0x1b0
>>> [<000000004046fab8>] scsi_prep_fn+0x100/0x1a0
>>> [<000000004035b9b0>] blk_peek_request+0x1b8/0x298
>>> [<0000000040471028>] scsi_request_fn+0xf8/0xa90
>>> [<0000000040357244>] __blk_run_queue+0x4c/0x70
>>> [<00000000403802c4>] cfq_insert_request+0x2dc/0x580
>>> [<0000000040356404>] __elv_add_request+0x1b4/0x300
>>>
>>> We have in blk-merge.c:
>>>
>>> else {
>>> /*
>>> * If the driver previously mapped a shorter
>>> * list, we could see a termination bit
>>> * prematurely unless it fully inits the sg
>>> * table on each mapping. We KNOW that there
>>> * must be more entries here or the driver
>>> * would be buggy, so force clear the
>>> * termination bit to avoid doing a full
>>> * sg_init_table() in drivers for each command.
>>> */
>>> if (sg_is_last (*sg))
>>> printk ("__blk_segment_map_sg: clearing termination bi
>>> t\n");
>>> sg_unmark_end(*sg);
>>> *sg = sg_next(*sg);
>>> BUG_ON (!*sg);
>>> }
>>>
>>> The comment suggests there must be more entries...
>>
>> I'm thinking with the split the scsi driver needs to provide one or two extra entires in the sg list.
>
>
> With the attached patch, I'm able to boot 4.2.0-rc2+ on linux-block at commit
> 54efd50bfd873e2dbf784e0b21a8027ba4299a3e.
>
> I didn't try to optimize the number of extra entries but I know one is not enough.
>
> I guess the puzzle is why the number of entries isn't calculated correctly in the first place.
> Further, why does blk-merge believe that it's okay to go beyond the terminator? Clearly,
> the magic number isn't always set, etc.
>
> I added the WARN_ON so I'd know when we run off the end of the the list.
Still fails to boot for me on c3000
(although I think the patch is going into the right direction!):
[ 25.140000] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 25.200000] sd 3:0:6:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA
[ 25.304000] sd 3:0:5:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
[ 25.436000] sdb: sdb1 sdb2 sdb3 < sdb5 sdb6 >
[ 25.488000] sda: sda1 sda2 sda3 < sda5 sda6 >
[ 25.560000] sd 3:0:6:0: [sdb] Attached SCSI disk
[ 25.636000] scsi_id(112): unaligned access to 0x00000000faad5009 at ip=0x000000004100390b
[ 25.752000] sd 3:0:5:0: [sda] Attached SCSI disk
[ 25.832000] scsi_id(113): unaligned access to 0x00000000fa90a009 at ip=0x000000004100390b
[ 25.972000] ------------[ cut here ]------------
[ 26.028000] WARNING: at /build/linux-4.4-neu/linux-4.4.2/block/blk-merge.c:466
[ 26.116000] random: nonblocking pool is initialized
[ 26.172000] Modules linked in: sr_mod cdrom sd_mod ata_generic ohci_pci ehci_pci ohci_hcd ehci_hcd pata_ns87415 libata sym53c8xx scsi_transport_spi usbcore scsi_modp
[ 26.368000] CPU: 0 PID: 65 Comm: systemd-udevd Not tainted 4.4.0-1-parisc64-smp #1 Debian 4.4.2-3
[ 26.476000] task: 00000000bbd70b08 ti: 00000000bbea8000 task.ti: 00000000bbea8000
[ 26.564000]
[ 26.584000] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
[ 26.640000] PSW: 00001000000001001111111100001110 Not tainted
[ 26.708000] r00-03 000000ff0804ff0e 00000000409e8380 00000000404f18f4 00000000bbea91e0
[ 26.804000] r04-07 00000000409b2b80 0000000000000000 0000000000000000 000000000000001e
Helge
next prev parent reply other threads:[~2016-02-23 18:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-23 18:00 SCSI bug John David Anglin
2016-02-20 20:13 ` John David Anglin
2016-02-20 20:43 ` John David Anglin
2016-02-20 21:59 ` Helge Deller
2016-02-20 22:52 ` John David Anglin
2016-02-21 2:52 ` John David Anglin
2016-02-21 3:47 ` James Bottomley
2016-02-21 14:45 ` John David Anglin
2016-02-21 18:10 ` James Bottomley
2016-02-21 18:09 ` John David Anglin
2016-02-21 18:13 ` James Bottomley
2016-02-21 18:43 ` John David Anglin
2016-02-21 19:07 ` James Bottomley
2016-02-21 19:36 ` Helge Deller
2016-02-21 20:28 ` James Bottomley
2016-02-21 21:09 ` John David Anglin
2016-02-21 21:17 ` Helge Deller
2016-02-21 21:49 ` James Bottomley
2016-02-21 22:08 ` John David Anglin
2016-02-22 0:53 ` John David Anglin
2016-02-22 3:24 ` John David Anglin
2016-02-23 3:04 ` John David Anglin
2016-02-23 18:06 ` Helge Deller [this message]
2016-02-23 19:10 ` John David Anglin
2016-02-21 20:42 ` John David Anglin
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=56CC9FA2.6020107@gmx.de \
--to=deller@gmx.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=dave.anglin@bell.net \
--cc=linux-parisc@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox