[gregoire.favre@gmail.com: What breaks aic7xxx in post 2.6.12-rc2 ?]

[gregoire.favre@gmail.com: What breaks aic7xxx in post 2.6.12-rc2 ?]

[Christoph Hellwig]

----- Forwarded message from Gr?goire Favre <gregoire.favre@gmail.com> -----

Date:	Mon, 16 May 2005 10:58:32 +0200
From:	Gr?goire Favre <gregoire.favre@gmail.com>
Subject: What breaks aic7xxx in post 2.6.12-rc2 ?
To:	linux-kernel@vger.kernel.org

Hello,

as I reported in
http://marc.theaimsgroup.com/?l=linux-kernel&m=111554477416794&w=2

I have lots of problem with aic7xxx (and till 2.6.12-rc2 everything
works perfectly). I have tried to compil 2.6.12-rc4-mm1 without probe
all Lun and it don't change anything at all to this problem.

I have two different controllers :

0000:00:05.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02)
0000:00:0a.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U

And I also use libsata.

Anyone got an idea on what's going wrong ?

Please CC to me : I am not on this mailinglist.
-- 
	Gr?goire Favre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

----- End forwarded message -----

Re: [gregoire.favre@gmail.com: What breaks aic7xxx in post 2.6.12-rc2 ?]

[James Bottomley]

On Mon, 2005-05-16 at 16:26 +0100, Christoph Hellwig wrote:
> Anyone got an idea on what's going wrong ?

As I read it, nothing is going wrong ... the trace indicates that the
device is eventually configured async by DV, so the system comes up with
it's full complement of devices.  Which device is this by the way, the
inquiry information is missing from the top.

The bug is that the DV code should shut the driver up while it probes to
avoid frightening users (particularly as the aic7xxx driver prints lots
of scary messages while its in error handling).

James

Re: [gregoire.favre@gmail.com: What breaks aic7xxx in post 2.6.12-rc2 ?]

[Grégoire Favre]

On Mon, May 16, 2005 at 10:46:41AM -0500, James Bottomley wrote:

> As I read it, nothing is going wrong ... the trace indicates that the
> device is eventually configured async by DV, so the system comes up with
> it's full complement of devices.  Which device is this by the way, the
> inquiry information is missing from the top.
> 
> The bug is that the DV code should shut the driver up while it probes to
> avoid frightening users (particularly as the aic7xxx driver prints lots
> of scary messages while its in error handling).

What's DV ?

With 2.6.12-rc4 the system finally boots, but it took about 30
minutes... so it must be some changes introduced in 2.6.12-rc3 that my
computer don't like.

Here's my /proc/scsi/scsi :

Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: DDRS-39130D      Rev: DC1B
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 15 Lun: 00
  Vendor: SEAGATE  Model: ST336706LW       Rev: 0108
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi1 Channel: 00 Id: 01 Lun: 00
  Vendor: TOSHIBA  Model: DVD-ROM SD-M1201 Rev: 1R08
  Type:   CD-ROM                           ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 02 Lun: 00
  Vendor: PLEXTOR  Model: CD-R   PX-R820T  Rev: 1.08
  Type:   CD-ROM                           ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 03 Lun: 00
  Vendor: PLEXTOR  Model: CD-R   PX-R820T  Rev: 1.08
  Type:   CD-ROM                           ANSI SCSI revision: 02
Host: scsi3 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: Maxtor 6B200M0   Rev: BANC
  Type:   Direct-Access                    ANSI SCSI revision: 05
Host: scsi7 Channel: 00 Id: 00 Lun: 00
  Vendor: SMSC     Model: 223 U HS-CF      Rev: 3.60
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi7 Channel: 00 Id: 00 Lun: 01
  Vendor: SMSC     Model: 223 U HS-MS      Rev: 3.60
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi7 Channel: 00 Id: 00 Lun: 02
  Vendor: SMSC     Model: 223 U HS-SM      Rev: 3.60
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi7 Channel: 00 Id: 00 Lun: 03
  Vendor: SMSC     Model: 223 U HS-SD/MMC  Rev: 3.60
  Type:   Direct-Access                    ANSI SCSI revision: 02

Which info should I sent in order to find what's the problem is ?

Thank you and please keep CC to me as I am not in this ml.
-- 
	Grégoire Favre
-
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

Re: [gregoire.favre@gmail.com: What breaks aic7xxx in post 2.6.12-rc2 ?]

[James Bottomley]

On Mon, 2005-05-16 at 17:54 +0200, Grégoire Favre wrote:
> What's DV ?

Domain Validation ... it's a way of probing the SCSI bus to check that
the transport parameters for the device are correct (and that nothing on
the bus is interfering with the transmissions).

> Host: scsi1 Channel: 00 Id: 01 Lun: 00
>   Vendor: TOSHIBA  Model: DVD-ROM SD-M1201 Rev: 1R08
>   Type:   CD-ROM                           ANSI SCSI revision: 02

Aha, this wouldn't be the first DVD to screw up in domain validation.
The first such problem was because the device lied about having an echo
buffer ... I suspect that may be the case here too.

The initial fix was just to disbelieve the device if it didn't support
ppr.  Could you try the attached?  It expands the check to disbelieve
the return for all CD type devices.

Thanks,

James

--- a/drivers/scsi/scsi_transport_spi.c
+++ b/drivers/scsi/scsi_transport_spi.c
@@ -799,7 +799,7 @@ spi_dv_device_internal(struct scsi_reque
 	 * do the SPI pattern write tests */
 
 	len = 0;
-	if (sdev->ppr)
+	if (sdev->ppr && sdev->type != TYPE_ROM)
 		len = spi_dv_device_get_echo_buffer(sreq, buffer);
 
  retry:


-
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

Re: [gregoire.favre@gmail.com: What breaks aic7xxx in post 2.6.12-rc2 ?]

[Grégoire Favre]

On Mon, May 16, 2005 at 11:33:32AM -0500, James Bottomley wrote:

> The initial fix was just to disbelieve the device if it didn't support
> ppr.  Could you try the attached?  It expands the check to disbelieve
> the return for all CD type devices.

Unfortunately, it don't seems to change anything, 2.6.12-rc4-mm1 is in a
infinite loop :

aic7xxx_abort returns 0x2002
scsi1:0:1:0: Attempting to queue an ABORT message
CDB: 0x0 0x0 0x0 0x0 0x0 0x0
scsi1:0:1:0: Command found on device queue
aic7xxx_abort returns 0x2002
scsi: Device offlined - not ready after error recovery: host 1 channel 0
 target1:0:1: domain Validation detected failure, dropping back
scsi1:0:1:0: Attempting to queue an ABORT message
...

Thank for the explanation and the patch :-)
-- 
	Grégoire Favre
-
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

Re: [gregoire.favre@gmail.com: What breaks aic7xxx in post 2.6.12-rc2 ?]

[James Bottomley]

On Mon, 2005-05-16 at 20:05 +0200, Grégoire Favre wrote:
> Unfortunately, it don't seems to change anything, 2.6.12-rc4-mm1 is in a
> infinite loop :

Actually, the loop's not infinite; it's dropping the transfer parameters
each time it goes around ... it should exit after 8 or so.

> aic7xxx_abort returns 0x2002
> scsi1:0:1:0: Attempting to queue an ABORT message
> CDB: 0x0 0x0 0x0 0x0 0x0 0x0
> scsi1:0:1:0: Command found on device queue
> aic7xxx_abort returns 0x2002
> scsi: Device offlined - not ready after error recovery: host 1 channel 0
>  target1:0:1: domain Validation detected failure, dropping back
> scsi1:0:1:0: Attempting to queue an ABORT message

I'm fairly certain it's something to do with the DVD settings.  Could
you send me the output of

/proc/scsi/aic7xxx/1

With the earlier version of the kernel

Thanks,

James


-
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