"The Linux Gazette...making Linux just a little more fun!"

SCSI Resets Due to Command Timeouts

From Gregory Smith on Fri, 09 Jul 1999

Hi,

I was hoping you could help. I have a Gateway P6-200 With an Adaptec 2940 SCSI card. The trouble is upon boot I receive timeout errors from the controller. I installed an IDE drive on a second system pulled the SCSI cable off the disks (ST32155W little SCSI cable,effectively disabling the drives) and was able to install on an IDE drive from the SCSI CD (SCSI-2 I think old style cable).

I think you should take a deep breath, drink some coffee or tea, and re-read that.

I'm not sure quite what you meant but it sounded like you were having problems with your SCSI chain while you had the hard drive attached. You installed an IDE hard drive, disconnected the SCSI hard drive (leaving the SCSI CD-ROM drive attached) and you were able to install Linux.

Is that about right?

That would suggest that the cabling, termination or drive are the source of the problem.

However I would like to install on my system ( that 2nd system was sort of hijacked once Linux was installed on it). I've been in the SCSI bios and turned down the speed settings from 20 to 8 , and turrned off syncronous and probably fiddled with all the setttings at some time. I've booted off the CD (RedHat 6.0) and floppy (RedHat 5.2) to no avail.

I'd suggest resetting them all back to the factory default before trying any further experimentation.

This is a system supplied by my employer so I would prefer not adding an IDE drive supplied by me (my home systems have RH4.2 and RH6.0). Any help would be appreciated. Oh yeah the bios on the AHA seems to auto assign the SCSI-IDs, do you think that could be the trouble? (I haven't tried forcing the IDs set.)

It sounds like some "Plug n Pray" stuff. I'd disable that and manually assign the IDs yourself.

TIA for any help you can supply.

Greg Smith

Hope you don't mind a syslog from the RH5.2 boot dump detailing the errors (it is sort of long).

It's useful though I'll ellide it for publication.

> <4>Memory: sized by int13 088h
> <4>Console: 16 point font, 400 scans
> <4>Console: colour VGA+ 80x25, 1 virtual console (max 63)
> <4>pcibios_init : BIOS32 Service Directory structure at 0x000fd8d0
> <4>pcibios_init : BIOS32 Service Directory entry at 0xfd8e0
> <4>pcibios_init : PCI BIOS revision 2.10 entry at 0xfd901

...

> <4>ide: i82371 PIIX (Triton) on PCI bus 0 function 57
> <4>    ide0: BM-DMA at 0xffa0-0xffa7
> <4>    ide1: BM-DMA at 0xffa8-0xffaf
> <4>scsi : 0 hosts.
> <4>scsi : detected total.

...

So, you don't have your SCSI driver built statically into the kernel.

> <4>Partition check:
> <5>RAMDISK: Compressed image found at block 0
> <4>EXT2-fs warning: checktime reached, running e2fsck is recommended
> <4>VFS: Mounted root (ext2 filesystem).
> <6>(scsi0) <Adaptec AHA-294X Ultra SCSI host adapter> found at PCI 11/0
> <6>(scsi0) Wide Channel, SCSI ID=7, 16/255 SCBs
> <6>(scsi0) Warning - detected auto-termination
> <6>(scsi0) Please verify driver detected settings are correct.
> <6>(scsi0) If not, then please properly set the device termination
> <6>(scsi0) in the Adaptec SCSI BIOS by hitting CTRL-A when prompted
> <6>(scsi0) during machine bootup.

Did your check on your termination? It's attempting to auto terminate --- but you can't be sure of what that's doing. Check that only the devices at the ends of your SCSI chain are terminated. If you have not external devices then the SCSI host adapter is at one end of the chain (and should be terminated).

Contrary to what you read in most places, I've seen and heard that longer SCSI cables can be more reliable than shorter ones (within limits, of course). I assume that this is NOT differential SCSI. As such it can be extremely sensitive to the quality of cable used to connect these devices.

If the drive works fine when the CD-ROM is disconnected, and the gives these errors again when you reconnect it that suggests that both the CD drive and the hard drive are terminated (or they they are trying to use the same ID).

Make sure that the CD-ROM or the hard drive is not terminated. Try swapping them them (cables and termination).

> <6>(scsi0) Cables present (Int-50 YES, Int-68 YES, Ext-68 NO)

This line suggests that you're some how using two different sorts of cables connected to the same controller. Is this really a 2940 PCI card? Does it have headers (attachment points) for both 50-pin (flat ribbon) and 68-pin (micro DB) cables?

Don't discount the possibility that the hard drive is just bad. Try it in another SCSI machine. Look up these drive and adapter models at their respective vendor web sites to ensure that they are compatible.

> <6>(scsi0) Downloading sequencer code... 419 instructions downloaded
> <4>scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI)
> 5.1.2/3.2.4
> <4>       <Adaptec AHA-294X Ultra SCSI host adapter>
> <4>scsi : 1 host.
> <4>  Vendor: SEAGATE   Model: ST32155W          Rev: 0362
> <4>  Type:   Direct-Access                      ANSI SCSI revision: 02
> <4>Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
> <4>  Vendor: MATSHITA  Model: CD-ROM CR-506     Rev: 8S04
> <4>  Type:   CD-ROM                             ANSI SCSI revision: 02
> <4>Detected scsi CD-ROM sr0 at scsi0, channel 0, id 5, lun 0
> <4>scsi : aborting command due to timeout : pid 17, scsi0, channel 0, id 0,
>  lun 0
> 0x00 00 00 00 00 00
> <4>scsi : aborting command due to timeout : pid 17, scsi0, channel 0, id 0,
>  lun 0
> 0x00 00 00 00 00 00
> <4>SCSI host 0 abort (pid 17) timed out - resetting
> <4>SCSI bus is being reset for host 0 channel 0.
> <4>SCSI host 0 channel 0 reset (pid 17) timed out - trying harder
> <4>SCSI bus is being reset for host 0 channel 0.
> <6>(scsi0:0:0:0) Synchronous at 20.0 Mbyte/sec, offset 15.
> <4>scsi : aborting command due to timeout : pid 18, scsi0, channel 0, id 0,
>  lun 0
> 0x25 00 00 00 00 00 00 00 00 00
> <4>scsi : aborting command due to timeout : pid 18, scsi0, channel 0, id 0,
>  lun 0

...

and so on.

Since it's a system provided by your employer --- it's not unreasonable to expect them to get the hardware functioning (even if you are expected to maintain the OS and other software on it).

SCSI Resets Due to Command Timeouts

From Gregory Smith on Mon, 12 Jul 1999

Hi again,

Thanks for your advice. It was indeed the "Plug & Play Scam" causing the problem. Once I disabled it the system wouldn't correctly scan the SCSI IDs from within the BIOS (or boot NT (of course)). So I shutdown the system configured on of the HDs to be SCSI ID 1 and powered back up. I was able to boot into NT then, I put the RH6.0 CD in and once it scanned the SCSI busses I knew it was going to work.BTW "Plug & Play Scam" is the actual name within the Adaptec BIOS, I guess that should have tipped me off .

Actually I think SCAM is supposed to be an acronym for some sort of SCSI Configuration Automation Method (or something like that). However, it may be an unfortunately apt term.

Glad I could help.

Well thanks again for your help. And now ( I'll bet you saw this coming!! ), I don't suppose you know why a sybase dump from a solaris system wouldn't be readable (sybase "load database" command) into a linux sybase server ( I've got sybase 11.03 for linux and solaris)? (Hey it is a shot in the dark no?)

Thanks again for the help, Greg Smith

I'd ask the Sybase support team if there are any issues with this. Are their db dumps supposed to be cross platform readable? Are there big-endian vs. little-endian (byte ordering with 32-bit register) problems?

P.S. here is the error mesg from the " load database " command

> Backup Server session id is:  15.  Use this value when executing the
> 'sp_volchanged' system stored procedure after fulfilling any volume change
> request from the Backup Server.
> Backup Server: 6.28.1.1: Dumpfile name 'v991991670AFEF   ' section number
> 0001 mounted on disk file '/home/gs/sybdumps/greg9915.dump'
> Msg 21, Level 20, State 1:
> Line 1:
> WARNING - Fatal Error 3223 occurred at Jul 12 1999  1:15PM.  Please note
> the error and time, and contact a user with System Administrator (SA)
> authorization.
> Msg 3208, Level 16, State 1:
> Line 1:
> Unexpected end of file while reading beginning of dump.  Please confirm
> that dump media contains a valid SQL Server dump. The SQL Server error log
> may contain more information on the problem.

It sounds, from these errors, like the load database command doesn't recognize the file you're providing as one of it's dump images. You're using a Sybase SQL command to generate this greg9915.dump file, aren't you?

(I wouldn't expect anything involving the Solaris 'dump' command to work on a Linux system).

When trying to transfer data from one database to another I think the best method is to export all of the data through a series of reports, and import it at the other end. Of course, that only transfers the data --- which generally means that all of your schema, triggers, business rules, etc. must be transferred by hand.

Plug and Pray SCAM

From Gregory Smith on Wed, 14 Jul 1999

Hello again,

WOW that was fast, you know what's funny I've been using Linux for about 6 years and never expected any "real" help especially this fast (I originally used TAMU distribution because I was able to download it onto 1.2 Mb floppies w/o X11). And other than a question I had about 1 1/2 years ago I never really got info by asking around (I would fumble around till it worked or I gave up.) I don't think I ever got this response time from my own company (I also used to be a field service rep fixing mini-computer systems). I can't thank you enough for the generosity or time.

Glad I could help.

I never did get around to trying TAMU (from Texas A&M University, wasn't it?).

I wish I could offer such high service levels to all my Answer Guy correspondents. However, it is all volunteer work. That's why I was happy to see companies like Linuxcare come in to provide the commercial support option. (So happy, in fact, that I now work for them; but that's another story).

In response to your questions--

In response, to my questions which were in response to your questions which .... (ugh!)

I'd ask the Sybase support team if there are any issues with this. Are their db dumps supposed to be cross platform readable? Are there big-endian vs. little-endian (byte ordering with 32-bit register) problems?

From what I understand from their download page there is no support for the Linux port. So the answer to the 1st question is "good question", and apparently we have problems doing a dump/load to other platforms (we support Solaris, HP-UX and AIX), sorry I guess I should have asked around here instead of wasting band-width and thinking it was "only" Linux that couldn't read a .dump file

You're using a Sybase SQL command to generate this greg9915.dump file, aren't you?

Yes from an isql command prompt, I'm using the "load database" and "dump database" commands

If you did an strace (Linux) or truss (Solaris) on the process while it was running this command, or issued a 'file' command on the resulting dump file (try to look up its "magic number" you might find out the underlying file format being used.

It may be that your isql command is passing the data into the system's copy of the 'dump' command. Those are NOT platform independent.

When trying to transfer data from one database to another I think the best method is to export all of the data through a series of reports, and import it at the other end. Of course, that only transfers the data --- which generally means that all of your schema, triggers, business rules, etc must be transferred by hand.

Yep this is what I was trying to avoid. Oh well looks like I'll be learning more and more about our DB, (man I liked Oracle, or at least I thought the imp and exp commands created dumps readable by other *nixs)

Hmmm. I'm not an SQL guy, so I have no basis for comparison. I know that both of these (and several other DBMS packages) are available for Linux.

Anyway, I thank you for the help and time you've spent on my problems. Grace and Peace to you,

Greg Smith

Glad I could help.

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 44 August 1999

HTML transformation by Heather Stern of Starshine Techinical Services, https://www.starshine.org/

			1	4	7	9
			11	12	14	17
18	19	20	21	24	25	26
28	29	30	31	32	33	34
35	36	37	38	39	40	41
42	43	44	45	46	47	48