Exabyte 4200C/tar problem
Brendan McKenna
I am using an Exabyte 4200C tape drive connected to an Adaptec 1542CF host
adapter and it is causing my system to hang pretty consistently. I am running
Linux 1.2.1 (I know, I'm behind the times), with all the necessary SCSI
drivers/support compiled in. I am running the latest version of GNU's tar (I
think the version is 1.11.x -- I forget the exact version, and do not have my
Linux box here at work). What happens is that when trying to backup my system
to the DAT drive it starts out fine, but after a while my entire system locks
up. A few times, rather than locking up, tar has aborted with a general
protection fault/segmentation fault (more info on that below). The motherboard
is a 486/33 with 20Mb memory, ISA bus. I also have a hard disk and a CD-ROM
drive connected to the 1542CF, and have had no problems at all with them. One
other point: I had to change cables in order to add the new internal device,
since the one I had only had two connectors for devices, in case the cabling is
playing a role in this....
When my system doesn't lock up, tar gives me the following error report, or one
very like it (this one is just the one that I wrote down):
General Protection: fffc
EIP: 0010:00155203
EFLAGS: 00010206
eax: 0092a5a0 ebx: 00000400 ecx: 00000400 edx: 00920000
esi: 00920000 edi: 00028400 ebp: 006e7eb8 esp: 006e7e50
ds: 0018 es: 0018 fs: 002b gs: 002b ss:0018
Process tar (pid: 88 process nr.: 20 stackpage=006e7000)
Stack: 0015002b 00910018 00088f90 00002800 012ea700 00002600 00000000 00000000
006e7f14 001dc5c4 006e7ebc 00000003 00000000 000001ad 00000000 00002800
ffffffe4 00918fb4 00918e10 00918e4c 00918e88 00918ec4 00918b40 00918b7c
Call Trace: 0015002b 001a317f 001b4d88 00183d50 00125638 0011ecd8 00125578
0011074d 0011002b 0011002b
Code: 07 f6 c1 01 74 01 a4 f6 c1 02 74 02 66 a5 c1 e9 02 f3 a5 07
Segmentation Fault
I imagine that this information is somewhat less than useful without the
linkage map, but just in case it is....
Any suggestions on what to try would be greatly appreciated!
Thanks,
Brendan