Bug 5003
| Summary: | Problem with symbios driver on recent -mm trees | ||
|---|---|---|---|
| Product: | IO/Storage | Reporter: | Martin J. Bligh (mbligh) |
| Component: | SCSI | Assignee: | Mike Anderson (andmike) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | jejb |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.13-rc4-mm1 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
|
Description
Martin J. Bligh
2005-08-05 07:30:07 UTC
Comment from Andrew: ------------------------------ sym2 works OK on my little test box with latest -mm lineup, and I have zero patches which touch that driver. James, could some of the scsi core rework have caused this? ---------------------------- I shall rudely cc jejb on this bug without asking him, in the light of the above - sorry ;-) --James Bottomley <James.Bottomley@SteelEye.com> wrote (on Friday, August 05, 2005 09:24:52 -0500): > On Thu, 2005-08-04 at 23:39 -0700, Andrew Morton wrote: >> James, could some of the scsi core rework have caused this? > > Well, I don't think so. The error below: > >> > sdc: Unit Not Ready, sense: >> > : Current: sense key=0x0 >> > ASC=0x0 ASCQ=0x0 >> > target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31) >> > Device not ready. >> > target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31) >> > Device not ready. >> > target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31) >> > Device not ready. >> > sdc : READ CAPACITY failed. >> > sdc : status=1, message=00, host=0, driver=08 >> > sd: Current: sense key=0x0 >> > ASC=0x0 ASCQ=0x0 > > Is coming from the disk not the symbios driver ... I think you have a > disk failure. Howcome it works on all mainline kernels, and not -mm then? ;-) Did we fix an error path to detect failures, maybe? M. Reply-To: James.Bottomley@SteelEye.com On Fri, 2005-08-05 at 07:36 -0700, Martin J. Bligh wrote: > Howcome it works on all mainline kernels, and not -mm then? ;-) > Did we fix an error path to detect failures, maybe? Well, OK, it might be something to do with your drives trying to negotiate IU and QAS. Support for this was added to the sym2 driver but never verified (because no-one seemed to have drives that could do it). The attached should stop the driver from negotiating these two parameters, if you could try it (it will produce complaints about static functions defined but not used, but you can ignore them). James diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.c b/drivers/scsi/sym53c8xx_2/sym_glue.c --- a/drivers/scsi/sym53c8xx_2/sym_glue.c +++ b/drivers/scsi/sym53c8xx_2/sym_glue.c @@ -2122,10 +2122,12 @@ static struct spi_function_template sym2 .show_width = 1, .set_dt = sym2_set_dt, .show_dt = 1, +#if 0 .set_iu = sym2_set_iu, .show_iu = 1, .set_qas = sym2_set_qas, .show_qas = 1, +#endif .get_signalling = sym2_get_signalling, }; > On Fri, 2005-08-05 at 07:36 -0700, Martin J. Bligh wrote: >> Howcome it works on all mainline kernels, and not -mm then? ;-) >> Did we fix an error path to detect failures, maybe? > > Well, OK, it might be something to do with your drives trying to > negotiate IU and QAS. Support for this was added to the sym2 driver but > never verified (because no-one seemed to have drives that could do it). > > The attached should stop the driver from negotiating these two > parameters, if you could try it (it will produce complaints about static > functions defined but not used, but you can ignore them). Nope, is the same as before with this patch .... M. > James > > diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.c b/drivers/scsi/sym53c8xx_2/sym_glue.c > --- a/drivers/scsi/sym53c8xx_2/sym_glue.c > +++ b/drivers/scsi/sym53c8xx_2/sym_glue.c > @@ -2122,10 +2122,12 @@ static struct spi_function_template sym2 > .show_width = 1, > .set_dt = sym2_set_dt, > .show_dt = 1, > +#if 0 > .set_iu = sym2_set_iu, > .show_iu = 1, > .set_qas = sym2_set_qas, > .show_qas = 1, > +#endif > .get_signalling = sym2_get_signalling, > }; > > > > > Reply-To: James.Bottomley@SteelEye.com On Mon, 2005-08-08 at 21:41 -0700, Martin J. Bligh wrote: > Nope, is the same as before with this patch .... Dear novice bug reporter, Thank you for taking the trouble to test this. Unfortunately, without any dmesg output, it's rather hard to tell what's going on here. Would you be so kind as to send this information so we can try to diagnose what's going on. Thanks, James --James Bottomley <James.Bottomley@SteelEye.com> wrote (on Tuesday, August 09, 2005 09:26:44 -0500): > On Mon, 2005-08-08 at 21:41 -0700, Martin J. Bligh wrote: >> Nope, is the same as before with this patch .... > > Dear novice bug reporter, > > Thank you for taking the trouble to test this. Unfortunately, without > any dmesg output, it's rather hard to tell what's going on here. Would > you be so kind as to send this information so we can try to diagnose > what's going on. Dear novice test examiner, It's in http://test.kernel.org with everything else ;-) 2.6.13-rc4-mm1+jejb_fix ... drills down to: http://test.kernel.org/10080/debug/console.log M. Reply-To: James.Bottomley@SteelEye.com On Tue, 2005-08-09 at 07:59 -0700, Martin J. Bligh wrote: > Dear novice test examiner, > > It's in http://test.kernel.org with everything else ;-) > 2.6.13-rc4-mm1+jejb_fix ... drills down to: > > http://test.kernel.org/10080/debug/console.log Well, OK, apparently some novice coder made an error converting from a stack allocated buffer to a kmalloc'd one in the sense handling routines. I think this patch should fix it (or at least restore it to the level of bugginess it had before). James diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -342,12 +342,12 @@ int scsi_execute_req(struct scsi_device sense = kmalloc(SCSI_SENSE_BUFFERSIZE, GFP_KERNEL); if (!sense) return DRIVER_ERROR << 24; - memset(sense, 0, sizeof(*sense)); + memset(sense, 0, SCSI_SENSE_BUFFERSIZE); } result = scsi_execute(sdev, cmd, data_direction, buffer, bufflen, sense, timeout, retries, 0); if (sshdr) - scsi_normalize_sense(sense, sizeof(*sense), sshdr); + scsi_normalize_sense(sense, SCSI_SENSE_BUFFERSIZE, sshdr); kfree(sense); return result; --On Tuesday, August 09, 2005 11:55:36 -0500 James Bottomley <James.Bottomley@SteelEye.com> wrote: > On Tue, 2005-08-09 at 07:59 -0700, Martin J. Bligh wrote: >> Dear novice test examiner, >> >> It's in http://test.kernel.org with everything else ;-) >> 2.6.13-rc4-mm1+jejb_fix ... drills down to: >> >> http://test.kernel.org/10080/debug/console.log > > Well, OK, apparently some novice coder made an error converting from a > stack allocated buffer to a kmalloc'd one in the sense handling > routines. > > I think this patch should fix it (or at least restore it to the level of > bugginess it had before). Wheeeeeee! that fixed it. Thanks very much. Log is here if you want to peek at it: http://test.kernel.org/10431/debug/console.log Triples all round! M. > James > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c > --- a/drivers/scsi/scsi_lib.c > +++ b/drivers/scsi/scsi_lib.c > @@ -342,12 +342,12 @@ int scsi_execute_req(struct scsi_device > sense = kmalloc(SCSI_SENSE_BUFFERSIZE, GFP_KERNEL); > if (!sense) > return DRIVER_ERROR << 24; > - memset(sense, 0, sizeof(*sense)); > + memset(sense, 0, SCSI_SENSE_BUFFERSIZE); > } > result = scsi_execute(sdev, cmd, data_direction, buffer, bufflen, > sense, timeout, retries, 0); > if (sshdr) > - scsi_normalize_sense(sense, sizeof(*sense), sshdr); > + scsi_normalize_sense(sense, SCSI_SENSE_BUFFERSIZE, sshdr); > > kfree(sense); > return result; > > > > Fixed! I owe James a triple. |