scsi init problem in 2.4.0-test10?

scsi init problem in 2.4.0-test10?

[chen, xiangping]

Hello,

I met a problem when trying to upgrade my Linux kernel to 2.4.0-test10.
The machine is Compay AP550, dual processor, mem 512 MB, and 863 MHZ freq.
It has two scsi host adaptors. one is AIC-7892 ultra 160/m connected to 
internal hard disk, and the other is AHA-3944 ultra scsi connected to 
an attached disk. The boot process stops after detection of the first
scsi host, error info is:
	scsi: aborting command due to time out: pid0, scsci1, channel 0, 
	id 0, lun 0, Inquiry 00 00 00 ff 00

Previous OS on this machine was RedHat 6.2 kernel version 2.2.14

looking forward to your help!

Xiangping
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: scsi init problem in 2.4.0-test10?

[Elizabeth Morris-Baker]

> 
> Hello,

	Yes, I encountered the same problem, and have a fix, but
	want to test it. If the author of scsi_scan.c would like
	to correct it, then that would be fine.

	Basically the problem is in scan_scsis_single.
	Some scsi devices are notoriously brain dead
	about answering inquiries without having 
	recived a TUR and then spinning up.
	The problem seems to be the disk, not the controller,
	if this is the same problem.

	The problem appeared in the test kernels because
	the TUR *used* to be there, now it is not.

	Hope this helps.

	Just curious, what kind of scsi disk do you have??
	lemme guess... Compaq Atlas?? :>

	cheers, 

	Elizabeth

> 
> I met a problem when trying to upgrade my Linux kernel to 2.4.0-test10.
> The machine is Compay AP550, dual processor, mem 512 MB, and 863 MHZ freq.
> It has two scsi host adaptors. one is AIC-7892 ultra 160/m connected to 
> internal hard disk, and the other is AHA-3944 ultra scsi connected to 
> an attached disk. The boot process stops after detection of the first
> scsi host, error info is:
> 	scsi: aborting command due to time out: pid0, scsci1, channel 0, 
> 	id 0, lun 0, Inquiry 00 00 00 ff 00
> 
> Previous OS on this machine was RedHat 6.2 kernel version 2.2.14
> 
> looking forward to your help!
> 
> Xiangping
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: scsi init problem in 2.4.0-test10?

[Elizabeth Morris-Baker]

> 

	You need to send the TUR first, but yes, 
	START_STOP will guarantee that you are
	ready to rock and roll.
	The first fix I wrote did a TUR, then
	3 tries at a START_STOP, till it worked.
	
	cheers, 

	Elizabeth
	
> 
> --8t9RHnE3ZwKMSgU+
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Thu, Nov 02, 2000 at 03:58:24PM -0600, Elizabeth Morris-Baker wrote:
> > 	Basically the problem is in scan_scsis_single.
> > 	Some scsi devices are notoriously brain dead
> > 	about answering inquiries without having=20
> > 	recived a TUR and then spinning up.
> > 	The problem seems to be the disk, not the controller,
> > 	if this is the same problem.
> >=20
> > 	The problem appeared in the test kernels because
> > 	the TUR *used* to be there, now it is not.
> 
> Strictly speaking, shouldn't we send a START_STOP, not a TUR to get the
> disks (or other devices) to spin up?
> 
> Matt
> 
> --=20
> Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.=
> net=20
> Maintainer, Linux USB Mass Storage Driver
> 
> S:  Another stupid question?
> G:  There's no such thing as a stupid question, only stupid people.
> 					-- Stef and Greg
> User Friendly, 7/15/1998
> 
> --8t9RHnE3ZwKMSgU+
> Content-Type: application/pgp-signature
> Content-Disposition: inline
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE6AfBfz64nssGU+ykRAiG4AJ9d96tbBNs6zCwR8qIkGs5fJGs6EQCeLtO9
> khi+5UEoM5/apYkaEBBgnow=
> =/YMd
> -----END PGP SIGNATURE-----
> 
> --8t9RHnE3ZwKMSgU+--
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: scsi init problem in 2.4.0-test10?

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

On Thu, Nov 02, 2000 at 03:58:24PM -0600, Elizabeth Morris-Baker wrote:
> 	Basically the problem is in scan_scsis_single.
> 	Some scsi devices are notoriously brain dead
> 	about answering inquiries without having 
> 	recived a TUR and then spinning up.
> 	The problem seems to be the disk, not the controller,
> 	if this is the same problem.
> 
> 	The problem appeared in the test kernels because
> 	the TUR *used* to be there, now it is not.

Strictly speaking, shouldn't we send a START_STOP, not a TUR to get the
disks (or other devices) to spin up?

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

S:  Another stupid question?
G:  There's no such thing as a stupid question, only stupid people.
					-- Stef and Greg
User Friendly, 7/15/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: scsi init problem in 2.4.0-test10?

[Torben Mathiasen]

The SCSI spec says that INQUIRY and not
TUR + INQUIRY is the way to go, but maybe we
should make it a compile time option for buggy
drives.


On Thu, Nov 02 2000, Elizabeth Morris-Baker wrote:
> > 
> 
> 	You need to send the TUR first, but yes, 
> 	START_STOP will guarantee that you are
> 	ready to rock and roll.
> 	The first fix I wrote did a TUR, then
> 	3 tries at a START_STOP, till it worked.
> 	
> 	cheers, 
> 
> 	Elizabeth
>

[deleted]

-- 
Torben Mathiasen <tmm@kernel.dk>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: scsi init problem in 2.4.0-test10? [PATCH]

[Elizabeth Morris-Baker]

> 

	Yes, I know that is in the spec, but truly,
	some scsi devices do act this way....
	Maybe they need to read the spec :>

	I have included the START_STOP for Matthew, but
	I never see it execute with the ATLAS disks...
	A diff follows for those that want to try it..

	cheers, 

	Elizabeth

> The SCSI spec says that INQUIRY and not
> TUR + INQUIRY is the way to go, but maybe we
> should make it a compile time option for buggy
> drives.

-------------------------cut here ----------------------
*** scsi_scan.c.orig	Tue Oct 24 14:01:54 2000
--- scsi_scan.c	Thu Nov  2 18:59:30 2000
***************
*** 471,476 ****
--- 471,479 ----
  	Scsi_Request * SRpnt;
  	int bflags, type = -1;
  	extern devfs_handle_t scsi_devfs_handle;
+ 	int spintime = 0;
+ 	int retries = 0;
+ 	unsigned long spintime_value = 0;
  
  	SDpnt->host = shpnt;
  	SDpnt->id = dev;
***************
*** 499,504 ****
--- 502,574 ----
  	 * not really necessary.  Spec recommends using INQUIRY to scan for
  	 * devices (and TEST_UNIT_READY to poll for media change). - Paul G.
  	 */
+ /* Add TUR back in to sync up the disk -- 
+    mostly borrowed from 2.2 kernel  -- eamb */
+ 
+ 	do 	
+ 	{
+                 retries = 0;
+ 
+                 while (retries < 3) 
+ 		{
+                         scsi_cmd[0] = TEST_UNIT_READY;
+                         scsi_cmd[1] = (lun << 5) & 0xe0;
+                         memset((void *) &scsi_cmd[2], 0, 8);
+                         SRpnt->sr_cmd_len = 0;
+                         SRpnt->sr_sense_buffer[0] = 0;
+                         SRpnt->sr_sense_buffer[2] = 0;
+                         SRpnt->sr_data_direction = SCSI_DATA_READ;
+ 
+ 			scsi_wait_req (SRpnt, (void *) scsi_cmd,
+                   		(void *) scsi_result,
+                   		256, SCSI_TIMEOUT+4*HZ, 3);
+ 
+                         retries++;
+                         if (SRpnt->sr_result == 0
+                             || SRpnt->sr_sense_buffer[2] != UNIT_ATTENTION)
+                                 break;
+                 }
+ 
+                 if( SRpnt->sr_result != 0
+                     && ((driver_byte(SRpnt->sr_result) & DRIVER_SENSE) != 0)
+                     && SRpnt->sr_sense_buffer[2] == UNIT_ATTENTION)
+ 		{
+                         break;
+                 }
+ 
+                 /* Look for devices that are NOT_READY.
+                  * Issue command to spin up drive for these cases. */
+                 if(SRpnt->sr_sense_buffer[2] == NOT_READY) 
+ 		{
+                         unsigned long time1;
+                         if (!spintime) 
+ 			{
+                                 scsi_cmd[0] = START_STOP;
+                                 scsi_cmd[1] = (lun << 5) & 0xe0;
+                                 scsi_cmd[1] |= 1;    /* Return immediately */
+                                 memset((void *) &scsi_cmd[2], 0, 8);
+                                 scsi_cmd[4] = 1;     /* Start spin cycle */
+                                 SRpnt->sr_cmd_len = 0;
+                                 SRpnt->sr_sense_buffer[0] = 0;
+                                 SRpnt->sr_sense_buffer[2] = 0;
+ 
+                                 SRpnt->sr_data_direction = SCSI_DATA_READ;
+ 				scsi_wait_req (SRpnt, (void *) scsi_cmd,
+                   			(void *) scsi_result,
+                   			256, SCSI_TIMEOUT+4*HZ, 3);
+                         }
+                         spintime = 1;
+                         spintime_value = jiffies;
+                         time1 = HZ;
+                         /* Wait 1 second for next try */
+                         do 
+ 			{
+                                 current->state = TASK_UNINTERRUPTIBLE;
+                                 time1 = schedule_timeout(time1);
+                         } while(time1);
+                 }
+         } while (SRpnt->sr_result && spintime && (retries < 3) &&
+                  time_after(spintime_value + 100 * HZ, jiffies));
  
  	SCSI_LOG_SCAN_BUS(3, printk("scsi: performing INQUIRY\n"));
  	/*
-------------------------cut here ----------------------
> 
> 
> On Thu, Nov 02 2000, Elizabeth Morris-Baker wrote:
> > > 
> > 
> > 	You need to send the TUR first, but yes, 
> > 	START_STOP will guarantee that you are
> > 	ready to rock and roll.
> > 	The first fix I wrote did a TUR, then
> > 	3 tries at a START_STOP, till it worked.
> > 	
> > 	cheers, 
> > 
> > 	Elizabeth
> >
> 
> [deleted]
> 
> -- 
> Torben Mathiasen <tmm@kernel.dk>
> Linux ThunderLAN maintainer 
> http://tlan.kernel.dk
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: scsi init problem in 2.4.0-test10? [PATCH]

[David Weinehall]

On Thu, Nov 02, 2000 at 06:24:47PM -0600, Elizabeth Morris-Baker wrote:
> > 
> 
> 	Yes, I know that is in the spec, but truly,
> 	some scsi devices do act this way....
> 	Maybe they need to read the spec :>
> 
> 	I have included the START_STOP for Matthew, but
> 	I never see it execute with the ATLAS disks...
> 	A diff follows for those that want to try it..
> 
> 	cheers, 
> 
> 	Elizabeth

Well, if I'm not all mistaken, this is the code that got removed earlier
on from the kernel because it caused some SCSI-adapters to hang on
scsi-scan?! If so, what's better: to follow the specs and penalise the
bad guys, or ignore the specs and penalise the good guys...


/David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: scsi init problem in 2.4.0-test10?

[stefan mojschewitsch]

"chen, xiangping" wrote:
> 
> Hello,
> 
> I met a problem when trying to upgrade my Linux kernel to 2.4.0-test10.
> The machine is Compay AP550, dual processor, mem 512 MB, and 863 MHZ freq.
> It has two scsi host adaptors. one is AIC-7892 ultra 160/m connected to
> internal hard disk, and the other is AHA-3944 ultra scsi connected to
> an attached disk. The boot process stops after detection of the first
> scsi host, error info is:
>         scsi: aborting command due to time out: pid0, scsci1, channel 0,
>         id 0, lun 0, Inquiry 00 00 00 ff 00
> 
im having this problem too with an quad ppro 166Mhz machine, but older
scsi-
controllers. when booting with 2.2.1[67] or 2.4.0.test[6-9] and 
kernelcmdline noapic, its okay.
on my machine, an AIC-7870 as scsi0 is aborting, when booting with apic 
enabled.

tnx for reading

stefan

-- 
stefan mojschewitsch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: scsi init problem in 2.4.0-test10? [PATCH]

[Elizabeth Morris-Baker]

> 

	Thank you for the information.
	I will give it some thought and see if I can come up
	with something that will fit both bills...

	The problem is that the disks that I have are
	very wide-spread, I would imagine. Compaq is shipping
	them in their newer machines, so some compromise has
	to be arrived at.
	
	I will look into the matter further.
	Thanks again.

	cheers, 

	eamb

> On Thu, Nov 02, 2000 at 06:24:47PM -0600, Elizabeth Morris-Baker wrote:
> > > 
> > 
> > 	Yes, I know that is in the spec, but truly,
> > 	some scsi devices do act this way....
> > 	Maybe they need to read the spec :>
> > 
> > 	I have included the START_STOP for Matthew, but
> > 	I never see it execute with the ATLAS disks...
> > 	A diff follows for those that want to try it..
> > 
> > 	cheers, 
> > 
> > 	Elizabeth
> 
> Well, if I'm not all mistaken, this is the code that got removed earlier
> on from the kernel because it caused some SCSI-adapters to hang on
> scsi-scan?! If so, what's better: to follow the specs and penalise the
> bad guys, or ignore the specs and penalise the good guys...
> 
> 
> /David Weinehall
>   _                                                                 _
>  // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
> //  Project MCA Linux hacker        //  Dance across the winter sky //
> \>  http://www.acc.umu.se/~tao/    </   Full colour fire           </
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/