Bug 249925

Summary: Domain validation detected failure error during bootup
Product: [Fedora] Fedora Reporter: Wayne Channell <wchannell771>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 7CC: chris.brown
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-01 08:43:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
This is a segment of the SYSTEM LOG file during bootup. none

Description Wayne Channell 2007-07-28 00:41:36 UTC
Description of problem:

A Dell PowerVault 100T DDS4 internal magtape drive worked reliably when using RH
EL WS4.  Upon loading the new F7 operating system the Seagate Python DAT drive
produces parity errors and "Domain validation detected failure" errors during
the bootup process.  The DAT drive is configured as SCSI ID#6.  The Python name
comes up on the screen during the bootup process, however, the domain validation
process consistently fails.  The computer system with F7 seems to be running
normally in all other respects.

Jul 27 16:58:04 hp1 kernel: scsi 0:0:6:0: Sequential-Access ARCHIVE  Python
06408-XXX 9050 PQ: 0 ANSI: 3 

Version-Release number of selected component (if applicable):

Linux hp1 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 15:37:31 EDT 2007 i686 i686 i386
GNU/Linux

How reproducible:

The "domain validation detected failure" error occurs during each bootup.

There are no error warning lights on the DAT tape drive.  The tape drive is
functioning properly since it was used to do a backup prior to loading the new
F7 operating system.

Steps to Reproduce:
1.  Boot up from cold start, or reboot
2.  The DAT tape drive cannot be accessed by tar to list a tape, or extract from
a tape. 
3.
  
Actual results:

A "domain validation detected failure" error is detected during the bootup
process at the point when the system querries the Python magtape drive.

The following is an excerpt from the System Log during bootup.

------------------
Jul 27 16:58:04 hp1 kernel: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA
DRIVER, Rev 7.0 
Jul 27 16:58:04 hp1 kernel:         <Adaptec 29160N Ultra160 SCSI adapter> 
Jul 27 16:58:04 hp1 kernel:         aic7892: Ultra160 Wide Channel A, SCSI Id=7,
32/253 SCBs 
Jul 27 16:58:04 hp1 kernel: 
Jul 27 16:58:04 hp1 kernel: scsi 0:0:0:0: Direct-Access     FUJITSU  MAN3735MP 
      5507 PQ: 0 ANSI: 3 
Jul 27 16:58:04 hp1 kernel: scsi0:A:0:0: Tagged Queuing enabled.  Depth 4 
Jul 27 16:58:04 hp1 kernel:  target0:0:0: Beginning Domain Validation 
Jul 27 16:58:04 hp1 kernel:  target0:0:0: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns,
offset 127) 
Jul 27 16:58:04 hp1 kernel:  target0:0:0: Ending Domain Validation 
Jul 27 16:58:04 hp1 kernel: ata1: PATA max UDMA/100 cmd 0x000101f0 ctl
0x000103f6 bmdma 0x0001ffa0 irq 14 
Jul 27 16:58:04 hp1 kernel: ata2: PATA max UDMA/100 cmd 0x00010170 ctl
0x00010376 bmdma 0x0001ffa8 irq 15 
Jul 27 16:58:04 hp1 kernel: scsi1 : ata_piix 
Jul 27 16:58:04 hp1 kernel: scsi2 : ata_piix 
Jul 27 16:58:04 hp1 kernel: ata2.00: ATAPI, max UDMA/33 
Jul 27 16:58:04 hp1 kernel: ata2.00: configured for UDMA/33 
Jul 27 16:58:04 hp1 kernel: scsi: waiting for bus probes to complete ... 
Jul 27 16:58:04 hp1 kernel: scsi 0:0:6:0: Sequential-Access ARCHIVE  Python
06408-XXX 9050 PQ: 0 ANSI: 3 
Jul 27 16:58:04 hp1 kernel:  target0:0:6: Beginning Domain Validation 
Jul 27 16:58:04 hp1 kernel:  target0:0:6: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns,
offset 32) 
Jul 27 16:58:04 hp1 kernel: (scsi0:A:6:0): parity error detected in Data-in
phase. SEQADDR(0x1a7) SCSIRATE(0x95) 
Jul 27 16:58:04 hp1 kernel: (scsi0:A:6:0): parity error detected in Data-in
phase. SEQADDR(0x1a7) SCSIRATE(0x95) 
Jul 27 16:58:04 hp1 kernel:  target0:0:6: Domain Validation detected failure,
dropping back 
------------------

Expected results:

The DDS magtape should mount properly during the bootup process, as it did when
using RH EL WS4.  However, it does not.

Additional info:

Comment 1 Wayne Channell 2007-07-28 00:41:36 UTC
Created attachment 160148 [details]
This is a segment of the SYSTEM LOG file during bootup.

Comment 2 Christopher Brown 2007-09-21 12:09:08 UTC
Hello Wayne,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.

Cheers
Chris

Comment 3 Wayne Channell 2007-10-01 02:45:26 UTC
Multiple attempts were made to solve the problem.  The following features were
turned off in the Adaptec host adapter.

1.  Set enable disconnect = NO
2.  Set Speed to 10 Mb/sec
3.  Set INt13 support = NO
4.  Set Domain Validation = Disable
5.  Set Initiate wide negociation = NO
6.  Set Send start unit command = NO
7.  Set Parity (odd) = OFF

All of the options for the Adaptec host adapter were turned OFF.  This did not
solve the problem.  A new cable with a 50 pin to 68 pin converter was purchased.
and installed  This also did not solve the problem.  The old cable was reinstalled.

A DIP switch on the tape drive was to switch between "narrow and wide" data
communications.  The switch was changed from the wide setting to the narrow
setting, and the tape drive began to work properly.  Everything else was set to
their original settings, and operation returned to normal.  The domain
validation errors disappeared.  The parity errors disappeared.  Everything is
working fine.

Apparently the previous operation system (RH EL WS4) experienced the same
wide/narrow errors, but ignored them.  The new Fedora F7 operating system must
check for errors more closely.

The problem is solved.  This report may be closed.  Thank you.