Re: kernel BUG in drivers/scsi/53c700.c:1129

[Christoph Hellwig]

On Fri, Jun 10, 2016 at 02:43:52PM -0700, James Bottomley wrote:
> OK, I checked: snic and fnic use SCSI_NO_TAG but they don't save
> anything in current_cmnd, so they can't rely on the original behaviour.
>  I think we'll be safe with a local change in 53c700.c

Please move the current_cmnd field in struct scsi_device into the 53c700
driver while you're at it, so that others don't accidentally rely on it.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG in drivers/scsi/53c700.c:1129

[Helge Deller]

On 10.06.2016 23:33, James Bottomley wrote:
> On Fri, 2016-06-10 at 14:01 -0700, James Bottomley wrote:
>> On Fri, 2016-06-10 at 16:58 -0400, Ewan D. Milne wrote:
>>> I'm not sure if this is the problem, but the tagging changes to
>>> scsi_tcq.h may have altered the 53c700 driver's assumptions.
>>> In one case it sets sdev->current_cmnd and then some of the
>>> tagging calls would return it if the tag was SCSI_NO_TAG.
>>>
>>> NCR_700_queuecommand_lck() does:
>>>
>>> if ((hostdata->tag_negotiated & (1<>> SCp->device->simple_tags) {
>>> slot->tag = SCp->request->tag;
>>> CDEBUG(KERN_DEBUG, SCp, "sending out tag %d, slot
>>> %p\n",
>>>slot->tag, slot);
>>> } else {
>>> slot->tag = SCSI_NO_TAG;
>>> /* must populate current_cmnd for
>>> scsi_host_find_tag
>>> to
>>> work */
>>> SCp->device->current_cmnd = SCp;
>>> }
>>
>> Thanks ... I was just about to look for something this.  I'd got to
>> interpreting the script as reselected with tag information present 
>> and then trying to look the command up with no tag present, hence the
>> BUG().
> 
> Yes, you're right, it's
> 
> commit 64d513ac31bd02a3c9b69ef0f36c196f9a9d
> Author: Christoph Hellwig 
> Date:   Thu Oct 8 09:28:04 2015 +0100
> 
> scsi: use host wide tags by default
> 
> Again.  This time because it's transformation of the handling of
> SCSI_NO_TAG is wrong.  You can't replace the return sdev->current_cmnd
> original in scsi_find_tag with the NULL return in scsi_find_host_tag.
> 
> I think this changesets wins the prize for the greatest number of
> generated faults.
> 
> Does this fix 53c700.c?

Yes, the patch below fixes the boot problems for 53c700.c:

[9.869236] 53c700: Version 2.8 By james.bottom...@hansenpartnership.com
[9.949797] scsi0: 53c710 rev 2 
[   10.994453] scsi host0: LASI SCSI 53c700
[   13.008861] scsi 0:0:6:0: Direct-Access QUANTUM  FIREBALL_TM3200S 300X 
PQ: 0 ANSI: 2
[   13.106740] scsi target0:0:6: Beginning Domain Validation
[   13.171889] scsi 0:0:6:0: tag#0 Enabling Tag Command Queuing
[   13.239996] scsi target0:0:6: asynchronous
[   13.305374] scsi target0:0:6: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 8)
[   13.397482] scsi target0:0:6: Domain Validation skipping write tests
[   13.473831] scsi target0:0:6: Ending Domain Validation
[   13.557116] scsi 0:0:6:1: tag#0 Disabling Tag Command Queuing
[   13.637379] st: Version 20160209, fixed bufsize 32768, s/g segs 256
[   13.746803] sd 0:0:6:0: Attached scsi generic sg0 type 0

THANKS!
(please queue the patch up for 4.6-stable at least)
Helge

 
> I suppose we'd better look for other places where no tag fell through
> ...
> 
> James
> 
> ---
> 
> diff --git a/drivers/scsi/53c700.c b/drivers/scsi/53c700.c
> index d4c2856..3ddc85e 100644
> --- a/drivers/scsi/53c700.c
> +++ b/drivers/scsi/53c700.c
> @@ -1122,7 +1122,7 @@ process_script_interrupt(__u32 dsps, __u32 dsp, struct 
> scsi_cmnd *SCp,
>   } else {
>   struct scsi_cmnd *SCp;
>  
> - SCp = scsi_host_find_tag(SDp->host, SCSI_NO_TAG);
> + SCp = SDp->current_cmnd;
>   if(unlikely(SCp == NULL)) {
>   sdev_printk(KERN_ERR, SDp,
>   "no saved request for untagged cmd\n");
> @@ -1826,7 +1826,7 @@ NCR_700_queuecommand_lck(struct scsi_cmnd *SCp, void 
> (*done)(struct scsi_cmnd *)
>  slot->tag, slot);
>   } else {
>   slot->tag = SCSI_NO_TAG;
> - /* must populate current_cmnd for scsi_host_find_tag to work */
> + /* save current command for reselection */
>   SCp->device->current_cmnd = SCp;
>   }
>   /* sanity check: some of the commands generated by the mid-layer
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG in drivers/scsi/53c700.c:1129

[James Bottomley]

On Fri, 2016-06-10 at 14:33 -0700, James Bottomley wrote:
> On Fri, 2016-06-10 at 14:01 -0700, James Bottomley wrote:
> > On Fri, 2016-06-10 at 16:58 -0400, Ewan D. Milne wrote:
> > > I'm not sure if this is the problem, but the tagging changes to
> > > scsi_tcq.h may have altered the 53c700 driver's assumptions.
> > > In one case it sets sdev->current_cmnd and then some of the
> > > tagging calls would return it if the tag was SCSI_NO_TAG.
> > > 
> > > NCR_700_queuecommand_lck() does:
> > > 
> > > if ((hostdata->tag_negotiated & (1< > > SCp->device->simple_tags) {
> > > slot->tag = SCp->request->tag;
> > > CDEBUG(KERN_DEBUG, SCp, "sending out tag %d, slot
> > > %p\n",
> > >slot->tag, slot);
> > > } else {
> > > slot->tag = SCSI_NO_TAG;
> > > /* must populate current_cmnd for
> > > scsi_host_find_tag
> > > to
> > > work */
> > > SCp->device->current_cmnd = SCp;
> > > }
> > 
> > Thanks ... I was just about to look for something this.  I'd got to
> > interpreting the script as reselected with tag information present 
> > and then trying to look the command up with no tag present, hence
> > the
> > BUG().
> 
> Yes, you're right, it's
> 
> commit 64d513ac31bd02a3c9b69ef0f36c196f9a9d
> Author: Christoph Hellwig 
> Date:   Thu Oct 8 09:28:04 2015 +0100
> 
> scsi: use host wide tags by default
> 
> Again.  This time because it's transformation of the handling of
> SCSI_NO_TAG is wrong.  You can't replace the return sdev
> ->current_cmnd
> original in scsi_find_tag with the NULL return in scsi_find_host_tag.
> 
> I think this changesets wins the prize for the greatest number of
> generated faults.
> 
> Does this fix 53c700.c?
> 
> I suppose we'd better look for other places where no tag fell through
> ...

OK, I checked: snic and fnic use SCSI_NO_TAG but they don't save
anything in current_cmnd, so they can't rely on the original behaviour.
 I think we'll be safe with a local change in 53c700.c

James


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG in drivers/scsi/53c700.c:1129

[James Bottomley]

On Fri, 2016-06-10 at 14:01 -0700, James Bottomley wrote:
> On Fri, 2016-06-10 at 16:58 -0400, Ewan D. Milne wrote:
> > I'm not sure if this is the problem, but the tagging changes to
> > scsi_tcq.h may have altered the 53c700 driver's assumptions.
> > In one case it sets sdev->current_cmnd and then some of the
> > tagging calls would return it if the tag was SCSI_NO_TAG.
> > 
> > NCR_700_queuecommand_lck() does:
> > 
> > if ((hostdata->tag_negotiated & (1< > SCp->device->simple_tags) {
> > slot->tag = SCp->request->tag;
> > CDEBUG(KERN_DEBUG, SCp, "sending out tag %d, slot
> > %p\n",
> >slot->tag, slot);
> > } else {
> > slot->tag = SCSI_NO_TAG;
> > /* must populate current_cmnd for
> > scsi_host_find_tag
> > to
> > work */
> > SCp->device->current_cmnd = SCp;
> > }
> 
> Thanks ... I was just about to look for something this.  I'd got to
> interpreting the script as reselected with tag information present 
> and then trying to look the command up with no tag present, hence the
> BUG().

Yes, you're right, it's

commit 64d513ac31bd02a3c9b69ef0f36c196f9a9d
Author: Christoph Hellwig 
Date:   Thu Oct 8 09:28:04 2015 +0100

scsi: use host wide tags by default

Again.  This time because it's transformation of the handling of
SCSI_NO_TAG is wrong.  You can't replace the return sdev->current_cmnd
original in scsi_find_tag with the NULL return in scsi_find_host_tag.

I think this changesets wins the prize for the greatest number of
generated faults.

Does this fix 53c700.c?

I suppose we'd better look for other places where no tag fell through
...

James

---

diff --git a/drivers/scsi/53c700.c b/drivers/scsi/53c700.c
index d4c2856..3ddc85e 100644
--- a/drivers/scsi/53c700.c
+++ b/drivers/scsi/53c700.c
@@ -1122,7 +1122,7 @@ process_script_interrupt(__u32 dsps, __u32 dsp, struct 
scsi_cmnd *SCp,
} else {
struct scsi_cmnd *SCp;
 
-   SCp = scsi_host_find_tag(SDp->host, SCSI_NO_TAG);
+   SCp = SDp->current_cmnd;
if(unlikely(SCp == NULL)) {
sdev_printk(KERN_ERR, SDp,
"no saved request for untagged cmd\n");
@@ -1826,7 +1826,7 @@ NCR_700_queuecommand_lck(struct scsi_cmnd *SCp, void 
(*done)(struct scsi_cmnd *)
   slot->tag, slot);
} else {
slot->tag = SCSI_NO_TAG;
-   /* must populate current_cmnd for scsi_host_find_tag to work */
+   /* save current command for reselection */
SCp->device->current_cmnd = SCp;
}
/* sanity check: some of the commands generated by the mid-layer
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG in drivers/scsi/53c700.c:1129

[James Bottomley]

On Fri, 2016-06-10 at 16:58 -0400, Ewan D. Milne wrote:
> I'm not sure if this is the problem, but the tagging changes to
> scsi_tcq.h may have altered the 53c700 driver's assumptions.
> In one case it sets sdev->current_cmnd and then some of the
> tagging calls would return it if the tag was SCSI_NO_TAG.
> 
> NCR_700_queuecommand_lck() does:
> 
> if ((hostdata->tag_negotiated & (1< SCp->device->simple_tags) {
> slot->tag = SCp->request->tag;
> CDEBUG(KERN_DEBUG, SCp, "sending out tag %d, slot
> %p\n",
>slot->tag, slot);
> } else {
> slot->tag = SCSI_NO_TAG;
> /* must populate current_cmnd for scsi_host_find_tag
> to
> work */
> SCp->device->current_cmnd = SCp;
> }

Thanks ... I was just about to look for something this.  I'd got to
interpreting the script as reselected with tag information present and
then trying to look the command up with no tag present, hence the
BUG().

James


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel BUG in drivers/scsi/53c700.c:1129

[Ewan D. Milne]

I'm not sure if this is the problem, but the tagging changes to
scsi_tcq.h may have altered the 53c700 driver's assumptions.
In one case it sets sdev->current_cmnd and then some of the
tagging calls would return it if the tag was SCSI_NO_TAG.

NCR_700_queuecommand_lck() does:

if ((hostdata->tag_negotiated & (1<device->simple_tags) {
slot->tag = SCp->request->tag;
CDEBUG(KERN_DEBUG, SCp, "sending out tag %d, slot %p\n",
   slot->tag, slot);
} else {
slot->tag = SCSI_NO_TAG;
/* must populate current_cmnd for scsi_host_find_tag to
work */
SCp->device->current_cmnd = SCp;
}

-Ewan

On Fri, 2016-06-10 at 22:25 +0200, Helge Deller wrote:
> On 10.06.2016 00:23, James Bottomley wrote:
> > On Thu, 2016-06-09 at 21:36 +0200, Helge Deller wrote:
> >> Hi James,
> >>
> >> I just tried Debian kernel 4.6.1-1 on my historic 715/64 machine, and it
> >> ran into this  BUG() in the LASI scsi driver:
> >>
> >>  scsi 0:0:6:0: no saved request for untagged cmd
> >>
> >> Any idea?
> >>
> >> Helge
> >>  
> >> [0.00] Linux version 4.6.0-1-parisc 
> >> (debian-ker...@lists.debian.org) (gcc version 5.4.0 20160603 (Debian 
> >> 5.4.0-3) ) #1 Debian 4.6.1-1 (2016-06-06)
> >> ...
> >> [0.00] Determining PDC firmware type: Snake.
> >> [0.00] model 60a0 0481   773c7d2c  
> >> 0004 0072 0072
> >> [0.00] vers  000c
> >> [0.00] model 9000/715
> >> [0.00] Total Memory: 160 MB
> >> ...
> >> [   43.18] SCSI subsystem initialized
> >> [   45.076000] 53c700: Version 2.8 By james.bottom...@hansenpartnership.com
> >> [   45.156000] scsi0: 53c710 rev 2 
> >> [   46.204000] scsi host0: LASI SCSI 53c700
> >> [   58.268000] scsi 0:0:6:0: no saved request for untagged cmd
> >> [   58.336000] [ cut here ]
> >> [   58.392000] kernel BUG at 
> >> /build/linux-XAODSw/linux-4.6.1/drivers/scsi/53c700.c:1129!
> >> [   58.484000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.6.0-1-parisc #1 
> >> Debian 4.6.1-1
> >> [   58.58] task: 1083cdd8 ti: 107b1000 task.ti: 107b1000
> >> [   58.644000] 
> >> [   58.66]  YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> >> [   58.716000] PSW: 01001110 Not tainted
> >> [   58.788000] r00-03  0004ff0e 0084e388 00a8ea8c 107ba400
> >> [   58.848000] r04-07    15b88cc0 0006
> >> [   58.912000] r08-11  198ca400 00ff 0020 
> >> [   58.976000] r12-15  00ff 1003 10801020 0001
> >> [   59.036000] r16-19  107b1240 0002 00ff 0001
> >> [   59.10] r20-23  0001 000e 0084f388 
> >> [   59.164000] r24-27  107ba500 0083b540 1021a7a4 107b5020
> >> [   59.224000] r28-31   0040 107ba480 104d52bc
> >> [   59.288000] sr00-03     000d
> >> [   59.352000] sr04-07     
> >> [   59.416000] 
> >> [   59.432000] IASQ:   IAOQ: 00a8ea8c 00a8ea90
> >> [   59.50]  IIR: 03ffe01fISR: 000d  IOR: 00a8ea90
> >> [   59.564000]  CPU:0   CR30: 107b1000 CR31: f00e
> >> [   59.632000]  ORIG_R28: 10855e80
> >> [   59.668000]  IAOQ[0]: process_script_interrupt+0x13ec/0x16a4 [53c700]
> >> [   59.748000]  IAOQ[1]: process_script_interrupt+0x13f0/0x16a4 [53c700]
> >> [   59.824000]  RP(r2): process_script_interrupt+0x13ec/0x16a4 [53c700]
> >> [   59.90] Backtrace:
> >> [   59.928000]  [<00a8ea8c>] process_script_interrupt+0x13ec/0x16a4 
> >> [53c700]
> >> [   60.012000] 
> >> [   60.028000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.6.0-1-parisc #1 
> >> Debian 4.6.1-1
> >> [   60.12] Backtrace:
> >> [   60.148000]  [<1015bffc>] show_stack+0x3c/0x50
> >> [   60.204000]  [<10425d40>] dump_stack+0x28/0x38
> >> [   60.256000]  [<1015c180>] die_if_kernel+0x134/0x20c
> >> [   60.316000]  [<1015cd34>] handle_interruption+0x804/0x828
> >> [   60.38] 
> >> [   60.40] Kernel panic - not syncing: Fatal exception in interrupt
> >> [   60.40] ---[ end Kernel panic - not syncing: Fatal exception in 
> >> interrupt
> > 
> > It looks like either an unsolicited reselection or possibly a spurious
> > interrupt left over from something.  Can you define NCR_700_DEBUG in
> > drivers/scsi/53c700.h and see what it says?
> 
> I enabled NCR_700_DEBUG and NCR_700_TAG_DEBUG.
> This is from vanilla kernel 4.6:
> 
> [8.70] Uniform Multi-Platform E-IDE driver
> [8.76] ide-gd driver 1.18
> [8.79] ide-cd driver 5.00
> [8.86]  script, patching MessageLocation at 31 to 0x09f684b0
> [8.93]  script, patching StatusAddress at 281 to 0x09f684d0
> [9.00]  script, patching ReceiveMsgAddress at 15 to 0x09f684c0
> [9.08]  script, patching ReceiveMsgAddress at 19 to 0x09f684c0
> [9.15]  script, patching ReceiveMsgAddress at 41 to 0x09f684c0
> 

Re: kernel BUG in drivers/scsi/53c700.c:1129

[Helge Deller]

On 10.06.2016 00:23, James Bottomley wrote:
> On Thu, 2016-06-09 at 21:36 +0200, Helge Deller wrote:
>> Hi James,
>>
>> I just tried Debian kernel 4.6.1-1 on my historic 715/64 machine, and it
>> ran into this  BUG() in the LASI scsi driver:
>>
>>  scsi 0:0:6:0: no saved request for untagged cmd
>>
>> Any idea?
>>
>> Helge
>>  
>> [0.00] Linux version 4.6.0-1-parisc (debian-ker...@lists.debian.org) 
>> (gcc version 5.4.0 20160603 (Debian 5.4.0-3) ) #1 Debian 4.6.1-1 (2016-06-06)
>> ...
>> [0.00] Determining PDC firmware type: Snake.
>> [0.00] model 60a0 0481   773c7d2c  
>> 0004 0072 0072
>> [0.00] vers  000c
>> [0.00] model 9000/715
>> [0.00] Total Memory: 160 MB
>> ...
>> [   43.18] SCSI subsystem initialized
>> [   45.076000] 53c700: Version 2.8 By james.bottom...@hansenpartnership.com
>> [   45.156000] scsi0: 53c710 rev 2 
>> [   46.204000] scsi host0: LASI SCSI 53c700
>> [   58.268000] scsi 0:0:6:0: no saved request for untagged cmd
>> [   58.336000] [ cut here ]
>> [   58.392000] kernel BUG at 
>> /build/linux-XAODSw/linux-4.6.1/drivers/scsi/53c700.c:1129!
>> [   58.484000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.6.0-1-parisc #1 
>> Debian 4.6.1-1
>> [   58.58] task: 1083cdd8 ti: 107b1000 task.ti: 107b1000
>> [   58.644000] 
>> [   58.66]  YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>> [   58.716000] PSW: 01001110 Not tainted
>> [   58.788000] r00-03  0004ff0e 0084e388 00a8ea8c 107ba400
>> [   58.848000] r04-07    15b88cc0 0006
>> [   58.912000] r08-11  198ca400 00ff 0020 
>> [   58.976000] r12-15  00ff 1003 10801020 0001
>> [   59.036000] r16-19  107b1240 0002 00ff 0001
>> [   59.10] r20-23  0001 000e 0084f388 
>> [   59.164000] r24-27  107ba500 0083b540 1021a7a4 107b5020
>> [   59.224000] r28-31   0040 107ba480 104d52bc
>> [   59.288000] sr00-03     000d
>> [   59.352000] sr04-07     
>> [   59.416000] 
>> [   59.432000] IASQ:   IAOQ: 00a8ea8c 00a8ea90
>> [   59.50]  IIR: 03ffe01fISR: 000d  IOR: 00a8ea90
>> [   59.564000]  CPU:0   CR30: 107b1000 CR31: f00e
>> [   59.632000]  ORIG_R28: 10855e80
>> [   59.668000]  IAOQ[0]: process_script_interrupt+0x13ec/0x16a4 [53c700]
>> [   59.748000]  IAOQ[1]: process_script_interrupt+0x13f0/0x16a4 [53c700]
>> [   59.824000]  RP(r2): process_script_interrupt+0x13ec/0x16a4 [53c700]
>> [   59.90] Backtrace:
>> [   59.928000]  [<00a8ea8c>] process_script_interrupt+0x13ec/0x16a4 [53c700]
>> [   60.012000] 
>> [   60.028000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.6.0-1-parisc #1 
>> Debian 4.6.1-1
>> [   60.12] Backtrace:
>> [   60.148000]  [<1015bffc>] show_stack+0x3c/0x50
>> [   60.204000]  [<10425d40>] dump_stack+0x28/0x38
>> [   60.256000]  [<1015c180>] die_if_kernel+0x134/0x20c
>> [   60.316000]  [<1015cd34>] handle_interruption+0x804/0x828
>> [   60.38] 
>> [   60.40] Kernel panic - not syncing: Fatal exception in interrupt
>> [   60.40] ---[ end Kernel panic - not syncing: Fatal exception in 
>> interrupt
> 
> It looks like either an unsolicited reselection or possibly a spurious
> interrupt left over from something.  Can you define NCR_700_DEBUG in
> drivers/scsi/53c700.h and see what it says?

I enabled NCR_700_DEBUG and NCR_700_TAG_DEBUG.
This is from vanilla kernel 4.6:

[8.70] Uniform Multi-Platform E-IDE driver
[8.76] ide-gd driver 1.18
[8.79] ide-cd driver 5.00
[8.86]  script, patching MessageLocation at 31 to 0x09f684b0
[8.93]  script, patching StatusAddress at 281 to 0x09f684d0
[9.00]  script, patching ReceiveMsgAddress at 15 to 0x09f684c0
[9.08]  script, patching ReceiveMsgAddress at 19 to 0x09f684c0
[9.15]  script, patching ReceiveMsgAddress at 41 to 0x09f684c0
[9.23]  script, patching ReceiveMsgAddress at 49 to 0x09f684c0
[9.30]  script, patching ReceiveMsgAddress at 55 to 0x09f684c0
[9.37]  script, patching ReceiveMsgAddress at 71 to 0x09f684c0
[9.45]  script, patching ReceiveMsgAddress at 77 to 0x09f684c0
[9.52]  script, patching ReceiveMsgAddress at 83 to 0x09f684c0
[9.60]  script, patching ReceiveMsgAddress at 89 to 0x09f684c0
[9.67]  script, patching ReceiveMsgAddress at 95 to 0x09f684c0
[9.75]  script, patching ReceiveMsgAddress at 137 to 0x09f684c0
[9.83]  script, patching ReceiveMsgAddress at 147 to 0x09f684c0
[9.90]  script, patching ReceiveMsgAddress at 177 to 0x09f684c0
[9.98]  script, patching ReceiveMsgAddress at 215 to 0x09f684c0
[   10.05]  script, patching ReceiveMsgAddress at 251 to 0x09f684c0
[   10.13]  script, patching ReceiveMsgAddress at 285 to 0x09f684c0
[   10.21] 53c700: Version 2.8 By 

Re: kernel BUG in drivers/scsi/53c700.c:1129

[James Bottomley]

On Thu, 2016-06-09 at 21:36 +0200, Helge Deller wrote:
> Hi James,
> 
> I just tried Debian kernel 4.6.1-1 on my historic 715/64 machine, and it
> ran into this  BUG() in the LASI scsi driver:
> 
>  scsi 0:0:6:0: no saved request for untagged cmd
> 
> Any idea?
> 
> Helge
>  
> [0.00] Linux version 4.6.0-1-parisc (debian-ker...@lists.debian.org) 
> (gcc version 5.4.0 20160603 (Debian 5.4.0-3) ) #1 Debian 4.6.1-1 (2016-06-06)
> ...
> [0.00] Determining PDC firmware type: Snake.
> [0.00] model 60a0 0481   773c7d2c  
> 0004 0072 0072
> [0.00] vers  000c
> [0.00] model 9000/715
> [0.00] Total Memory: 160 MB
> ...
> [   43.18] SCSI subsystem initialized
> [   45.076000] 53c700: Version 2.8 By james.bottom...@hansenpartnership.com
> [   45.156000] scsi0: 53c710 rev 2 
> [   46.204000] scsi host0: LASI SCSI 53c700
> [   58.268000] scsi 0:0:6:0: no saved request for untagged cmd
> [   58.336000] [ cut here ]
> [   58.392000] kernel BUG at 
> /build/linux-XAODSw/linux-4.6.1/drivers/scsi/53c700.c:1129!
> [   58.484000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.6.0-1-parisc #1 
> Debian 4.6.1-1
> [   58.58] task: 1083cdd8 ti: 107b1000 task.ti: 107b1000
> [   58.644000] 
> [   58.66]  YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> [   58.716000] PSW: 01001110 Not tainted
> [   58.788000] r00-03  0004ff0e 0084e388 00a8ea8c 107ba400
> [   58.848000] r04-07    15b88cc0 0006
> [   58.912000] r08-11  198ca400 00ff 0020 
> [   58.976000] r12-15  00ff 1003 10801020 0001
> [   59.036000] r16-19  107b1240 0002 00ff 0001
> [   59.10] r20-23  0001 000e 0084f388 
> [   59.164000] r24-27  107ba500 0083b540 1021a7a4 107b5020
> [   59.224000] r28-31   0040 107ba480 104d52bc
> [   59.288000] sr00-03     000d
> [   59.352000] sr04-07     
> [   59.416000] 
> [   59.432000] IASQ:   IAOQ: 00a8ea8c 00a8ea90
> [   59.50]  IIR: 03ffe01fISR: 000d  IOR: 00a8ea90
> [   59.564000]  CPU:0   CR30: 107b1000 CR31: f00e
> [   59.632000]  ORIG_R28: 10855e80
> [   59.668000]  IAOQ[0]: process_script_interrupt+0x13ec/0x16a4 [53c700]
> [   59.748000]  IAOQ[1]: process_script_interrupt+0x13f0/0x16a4 [53c700]
> [   59.824000]  RP(r2): process_script_interrupt+0x13ec/0x16a4 [53c700]
> [   59.90] Backtrace:
> [   59.928000]  [<00a8ea8c>] process_script_interrupt+0x13ec/0x16a4 [53c700]
> [   60.012000] 
> [   60.028000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.6.0-1-parisc #1 
> Debian 4.6.1-1
> [   60.12] Backtrace:
> [   60.148000]  [<1015bffc>] show_stack+0x3c/0x50
> [   60.204000]  [<10425d40>] dump_stack+0x28/0x38
> [   60.256000]  [<1015c180>] die_if_kernel+0x134/0x20c
> [   60.316000]  [<1015cd34>] handle_interruption+0x804/0x828
> [   60.38] 
> [   60.40] Kernel panic - not syncing: Fatal exception in interrupt
> [   60.40] ---[ end Kernel panic - not syncing: Fatal exception in 
> interrupt

It looks like either an unsolicited reselection or possibly a spurious
interrupt left over from something.  Can you define NCR_700_DEBUG in
drivers/scsi/53c700.h and see what it says?

Thanks,

James


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html