Does kernel require IDE enabled in BIOS to access HD, FS errors?

Does kernel require IDE enabled in BIOS to access HD, FS errors?

From: M.H.VanLeeuwen ([email protected])
Date: Sat Jul 07 2001 - 00:25:58 EST

Hi,

I have a SMP P166 system that has been running for years with an AIC7xxx SCSI card as
opposed to the native IDE interface. The BIOS has the IDE 0,1,2,3 set to <NONE>.
Running out of disk space I installed one of the original IDE drives. The kernel
booted and ID'd the drive correctly. Kernel version 2.4.5/6 behave the same.

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
CMD646: IDE controller on PCI bus 00 dev 10
CMD646: chipset revision 1
CMD646: not 100% native mode: will probe irqs later
CMD646: chipset revision 0x01, MultiWord DMA Limited, IRQ workaround enabled
CMD646: simplex device: DMA disabled
ide0: CMD646 Bus-Master DMA disabled (BIOS)
CMD646: simplex device: DMA disabled
ide1: CMD646 Bus-Master DMA disabled (BIOS)
hdb: CD-ROM CDU76E, ATAPI CD/DVD-ROM drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hdc: WDC AC2850F, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hdc: 1667232 sectors (854 MB) w/64KiB Cache, CHS=1654/16/63
hdb: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdb: packet command error: error=0x44
hdb: ATAPI 4X CD-ROM drive, 256kB Cache
Uniform CD-ROM driver Revision: 3.12
Partition check:
hdc: [PTBL] [827/32/63] hdc1

However I can't boot from the SCSI drives if the IDE HD is enabled due to deficiencies
in the BIOS... boot "A: then C:" or "C: then A:" are the only choices, if neither are
present the system boots from the SCSI card, otherwise it fails to boot.

PROBLEM: cannot reliably R/W to the HD unless the BIOS is set to <auto> recognize.
I consistently see MD5SUM errors and FS corruption and other strange FS symptoms
when the BIOS is set to <NONE> for the drive and _never_ see any errors with the
setting set to <AUTO>. There are no messages emitted by the kernel that there
were any system errors encountered leading one to believe that all is well, when
it isn't.

What is interesting, is that the I/O writes increase from once every 14 seconds to
once every 2-3 seconds and the FS corruption diminishes but don't disappear
if a background "dd if=/dev/zero of=/dev/null" is running.

Is this expected kernel behavior?

VMSTAT follow... when copying files from SCSI drives to IDE drive.

More info available if needed...

Thanks,
Martin

Martin, you have an old beast that there are problems in how the chipset was deployed.
How are you confirming the corruption against the various layers in the kernel?
If you would like patches & tests to verify I will send them to you.

Cheers

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-----------------------------------------------------------------------------
ASL, Inc.                                     Toll free: 1-877-ASL-3535
1757 Houret Court                             Fax: 1-408-941-2071
Milpitas, CA 95035                            Web: www.aslab.com

Andre,

Yes, I'd be willing to test ideas / apply any patches you'd like to try.

I was running something like this to verify corruption:

while true ; do mount /dev/hdc1 /misc ;time cp -a /usr/local/soffice52 /misc ; \
cd /misc && md5sum --check /tmp/soffice.md5 ; cd ; umount /misc; \
e2fsck -f -y /dev/hdc1 ; done

md5sum reported errors on the order of 28-37 corrupted files out of 576 files copy time ~11 minutes

with dd if=/dev/zero of=/dev/null running on another terminal, md5sum only reported 3-8 files corrupted.
copy time ~2.5 minutes

Thanks
Martin

BTW:

here is one of the many and more verbose reports of FS corruption from e2fsck:

e2fsck 1.20, 25-May-2001 for EXT2 FS 0.5b, 95/08/09 Pass 1: Checking inodes, blocks, and sizes
Inode 44863, i_size is 56832, should be 3502080. Fix? yes

Inode 44863, i_blocks is 120, should be 144. Fix? yes

Duplicate blocks found... invoking duplicate block passes. Pass 1B: Rescan for duplicate/bad blocks Duplicate/bad block(s) in inode 15303: 37632 Duplicate/bad block(s) in inode 44863: 37632 113 16 Pass 1C: Scan directories for inodes with dup blocks. Pass 1D: Reconciling duplicate blocks
(There are 2 inodes containing duplicate/bad blocks.)

File /office52/share/basic/template.sbl (inode #44863, mod time Mon May 8 01:20:00 2000)
has 3 duplicate block(s), shared with 2 file(s):

        <filesystem metadata>
        /office52/share/gallery/clipart/glas.wmf (inode #15303, mod time Mon May  8 01:20:00 2000)

Clone duplicate/bad blocks? yes

File /office52/share/gallery/clipart/glas.wmf (inode #15303, mod time Mon May 8 01:20:00 2000)
has 1 duplicate block(s), shared with 2 file(s):

        <filesystem metadata>
        /office52/share/basic/template.sbl (inode #44863, mod time Mon May  8 01:20:00 2000)

Duplicated blocks already reassigned or cloned.

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (30518, counted=30515). Fix? yes

Free blocks count wrong (140220, counted=140217).
Fix? yes

/dev/hda1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hda1: 3036/104384 files (0.1% non-contiguous), 68179/208396 blocks

Andre,

I had a chance to play a little more today, here is what I've come up with:

a. w/ hdc disable in BIOS, changing the PIO mode to 0 or 1 seems to allow the
system to run error free. PIO mode 3 still has silent FS corruption issues.

b. w/ hdc enabled in BIOS, the PIO mode doesn't seem to matter. (except for speed;)

c. CONFIG_IDEDMA_PCI_AUTO affects the number of interrupts needed to complete
each block xfer. With it enabled the number of IRQ's per second ~600. With it disabled ~2/block or 5000-6000 per second. I thought from the dmesg output that DMA was disabled and this option should have no affect.

d. CONFIG_IDEDMA_PCI_AUTO does not seem to affect the outcome of "a" or "b" above.

Martin

There appears to be a max-pio sync error. Specifically PIO is used to setup all transfers regardless of DMA/Multi/PIO and if that is wrong the the rest is toast.

CMD has the strangest interlace of PIO ever.

PIO can only as hast as the slowest device.

I need to think about this some more, kick me to keep me on task.

Cheers,

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-----------------------------------------------------------------------------

ASL, Inc.                                     Toll free: 1-877-ASL-3535
1757 Houret Court                             Fax: 1-408-941-2071
Milpitas, CA 95035                            Web: www.aslab.com