IDE problem: linux-2.5.17

Hello.

Kernel starting from 2.5.8 can not boot my Suse 6.4. Booting on those kernels (tested 2.5.8, 2.5.9 and 2.5.17) I am always getting

{ dma_intr }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: recalibrating!

and system either hangs or falls into endless loop.

Kernel 2.5.7 boots and works just fine.
The boot log containing information about hardware is attached.

Badblock does not see any bad blocks.

Thanks for any clue on the problem.
Lena.

------------------------------------------------------------------------

Linux version 2.5.7 (grev@silver) (gcc version 2.95.2 19991024 (release)) #1 SMP Fri Mar 29 16:20:45 MSK 2002 BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
BIOS-e820: 000000000fff0000 - 000000000fff3000 (ACPI NVS)
BIOS-e820: 000000000fff3000 - 0000000010000000 (ACPI data)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
255MB LOWMEM available.
On node 0 totalpages: 65520
zone(0): 4096 pages.
zone(1): 61424 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=2.5.7 ro root=306 vga=0x0301
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Initializing CPU#0
Detected 698.666 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1392.64 BogoMIPS
Memory: 256464k/262080k available (1241k kernel code, 5232k reserved, 430k data, 208k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: Before vendor init, caps: 0183fbff c1c3fbff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: After vendor init, caps: 0183fbff c1c3fbff 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.

CPU:     After generic, caps: 0183fbff c1c3fbff 00000000 00000000
CPU:             Common caps: 0183fbff c1c3fbff 00000000 00000000

Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
CPU: Before vendor init, caps: 0183fbff c1c3fbff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: After vendor init, caps: 0183fbff c1c3fbff 00000000 00000000 Intel machine check reporting enabled on CPU#0.

CPU:     After generic, caps: 0183fbff c1c3fbff 00000000 00000000
CPU:             Common caps: 0183fbff c1c3fbff 00000000 00000000
WARNING: This combination of AMD processors is not suitable for SMP.
CPU0: AMD Athlon(tm) Processor stepping 01
per-CPU timeslice cutoff: 1463.62 usecs.

task migration cache decay timeout: 10 msecs.
SMP motherboard not detected.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 698.6489 MHz.
..... host bus clock speed is 199.6139 MHz.
cpu: 0, clocks: 1996139, slice: 998069 CPU0<T0:1996128,T1:998048,D:11,S:998069,C:1996139>
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
PCI: PCI BIOS revision 2.10 entry at 0xfb430, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
Starting kswapd
BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec: init pool 0, 1 entries, 12 bytes
biovec: init pool 1, 4 entries, 48 bytes
biovec: init pool 2, 16 entries, 192 bytes
biovec: init pool 3, 64 entries, 768 bytes
biovec: init pool 4, 128 entries, 1536 bytes
biovec: init pool 5, 256 entries, 3072 bytes
VFS: Diskquotas version dquot_6.4.0 initialized
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
block: 256 slots per queue, batch=32
Intel(R) PRO/100 Fast Ethernet Adapter - Loadable driver, ver 2.0.24-pre1 Copyright (c) 2002 Intel Corporation

eth0: Intel(R) PRO/100+ Management Adapter
Mem:0xe5101000 IRQ:11 Speed:100 Mbps Dx:Full
Hardware receive checksums enabled
cpu cycle saver enabled

[drm] Initialized tdfx 1.0.0 20010216 on minor 0
Uniform Multi-Platform E-IDE driver ver.:7.0.0
ide: system bus speed 33MHz
Advanced Micro Devices [AMD] AMD-756 [Viper] IDE: IDE controller on PCI slot 00:07.1 Advanced Micro Devices [AMD] AMD-756 [Viper] IDE: chipset revision 3
Advanced Micro Devices [AMD] AMD-756 [Viper] IDE: not 100% native mode: will probe irqs later
AMD_IDE: Advanced Micro Devices [AMD] AMD-756 [Viper] IDE (rev 03) UDMA66 controller on pci00:07.1

    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio

hda: IBM-DJNA-371800, ATA DISK drive
hdc: SONY CDU4811, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c033dd0c, I/O limit 4095Mb (mask 0xffffffff)
hda: 35239680 sectors (18043 MB) w/1966KiB Cache, CHS=34960/16/63, (U)DMA Partition check:
hda: [PTBL] [2193/255/63] hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 >
Advanced Linux Sound Architecture Driver Version 0.9.0beta12 (Mon Mar 18 15:44:40 2002 UTC).
kmod: failed to exec /sbin/modprobe -s -k snd-card-0, errno = 2
ALSA device list:
No soundcards found.
NET4: Linux TCP/IP 1.0 for NET4.0

IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 1024 buckets, 16Kbytes
TCP: Hash tables configured (established 8192 bind 10922)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 208k freed
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

Quoted 2 lines

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

Since this error can be expected to be quite common. Its an installation error. I will just make the corresponding error message more intelliglible to the average user:
hda: checksum error on data transfer occurred!

Hello!

Quoted 7 lines · Martin Dalecki

Quoted 2 lines

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

Since this error can be expected to be quite common. Its an installation error. I will just make the corresponding error message more intelliglible to the average user:
hda: checksum error on data transfer occurred!

BTW, I have a particular setup that spits out such errors, and I somehow thinks the cable is good.

I have IBM DTLA-307030 drive and Seagate Barracuda IV drive (last one purchased only recently).
IBM drive is connected to far end of 80-wires IDE cable and Barracuda is connected to the middle of this same wire.
Before I bought IBM drive, everything was ok.
But now I see BadCRC errors on hdb (only on hdb, which is barracuda drive) usually when both drives are active.
If I disable DMA on IBM drive (or if kernel disables it by itself for some reason, and it actually does it sometimes), these errors seems to go away.

This is all on 2.4.18, but actually I think this is irrelevant.

If that's a bad cable, why it is only happens when both drives are working in DMA mode?

If that's a bad cable, why it is only happens when both drives are working in DMA mode?

It's most likely the cable. The error comes directly from the status register of the drive. The drive is reporting that it got corrupted data from the wire. This will be only checked in the 80 cable requiring DMA transfer modes. So if the drive resorts to slower operation all will be fine. If it does not - well you see the above...

It can of course be as well that the host chip driver is simply programming the channel for too aggressive values.

How about trying out what Andre Hedrick's convert.10 has to say about your setup if you're convinced the cable is ok?

Sidenote: I'd recommend putting the two drives on separate channels, you're losing quite a bit of performance this way when doing hda<->hdb transfers.

Uz.ytkownik Gryaznova E. napisa?:

Quoted 18 lines

Hello.

Kernel starting from 2.5.8 can not boot my Suse 6.4. Booting on those kernels (tested 2.5.8, 2.5.9 and 2.5.17) I am always getting

{ dma_intr }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: recalibrating!

and system either hangs or falls into endless loop.

Kernel 2.5.7 boots and works just fine.
The boot log containing information about hardware is attached.

Badblock does not see any bad blocks.

Thanks for any clue on the problem.
Lena.

Quoted 2 lines

------------------------------------------------------------------------

You just have cabling problems which where previously hidden by the driver resorting to slower operation modes.

So please first have a look at the cabling inside your system. (First of all plase make sure of course that you are using a 80 wirde cable.) Or have a look in to the host chip driver and penalize the transfer mode supported to lower speeds. You can achieve basically a similar effect by setting the busspeed kernel parameter to some artificially high value as well.

I have 40 wires cable. When ide=nodma is passed to 2.5.17 kernel - kernel boots. Am I correct that it is not possible to have DMA on with such cable? Is there any reason for doing that?

Quoted 3 lines

I have 40 wires cable. When ide=nodma is passed to 2.5.17 kernel - kernel boots. Am I correct that it is not possible to have DMA on with such cable? Is there any reason for doing that?

40-conductor IDE cables are capable of transfering data in DMA modes up to udma2, but no faster.

T.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Not true at all.

Many of the OEM's use 40c's to do 66 and 100, just they have to be very high quality and about 6" in length.

Uz.ytkownik Andre Hedrick napisa?:

Quoted 5 lines

Not true at all.

Many of the OEM's use 40c's to do 66 and 100, just they have to be very high quality and about 6" in length.

Please don't confuse people the standard is clear. The OEM's are just cheap becous they can controll what they put in to the box and how they layout the cables inside the box. If someone asks. The 80 lines are half the same contacts as before and half signal shilding. So indeed 40 wire cables can turn out to work, but thats subjec to "quality" assurance on behalf of the OEM's.

Uz.ytkownik Andre Hedrick napisa?:

Quoted 5 lines

Not true at all.

Many of the OEM's use 40c's to do 66 and 100, just they have to be very high quality and about 6" in length.

Please don't confuse people the standard is clear. The OEM's are just cheap becous they can controll what they put in to the box and how they layout the cables inside the box. If someone asks. The 80 lines are half the same contacts as before and half signal shilding. So indeed 40 wire cables can turn out to work, but thats subjec to "quality" assurance on behalf of the OEM's.

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

Uz.ytkownik Andre Hedrick napisa?:

Quoted 5 lines

Not true at all.

Many of the OEM's use 40c's to do 66 and 100, just they have to be very high quality and about 6" in length.

Please don't confuse people the standard is clear. The OEM's are just cheap becous they can controll what they put in to the box and how they layout the cables inside the box. If someone asks. The 80 lines are half the same contacts as before and half signal shilding. So indeed 40 wire cables can turn out to work, but thats subjec to "quality" assurance on behalf of the OEM's.

Not true at all.

Many of the OEM's use 40c's to do 66 and 100, just they have to be very high quality and about 6" in length.

Quoted 8 lines

Quoted 4 lines

I have 40 wires cable. When ide=nodma is passed to 2.5.17 kernel - kernel boots. Am I correct that it is not possible to have DMA on with such cable? Is there any reason for doing that?

40-conductor IDE cables are capable of transfering data in DMA modes up to udma2, but no faster.

Quoted 7 lines

T.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andre Hedrick
LAD Storage Consulting Group

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

I have 40 wires cable. When ide=nodma is passed to 2.5.17 kernel - kernel boots. Am I correct that it is not possible to have DMA on with such cable? Is there any reason for doing that?

Note that bus speed is 33 MHz when kernel fails to boot. I mean - how do I specify slower bus speed: 22 MHz?

Uz.ytkownik Oleg Drokin napisa?:

Quoted 17 lines

Hello!

Quoted 7 lines · Martin Dalecki

Quoted 2 lines

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

Since this error can be expected to be quite common. Its an installation error. I will just make the corresponding error message more intelliglible to the average user:
hda: checksum error on data transfer occurred!

BTW, I have a particular setup that spits out such errors, and I somehow thinks the cable is good.

I have IBM DTLA-307030

Quoted 12 lines

drive and Seagate Barracuda IV drive (last one purchased
only recently).
IBM drive is connected to far end of 80-wires IDE cable and Barracuda is connected to the middle of this same wire.
Before I bought IBM drive, everything was ok.
But now I see BadCRC errors on hdb (only on hdb, which is barracuda drive) usually when both drives are active.
If I disable DMA on IBM drive (or if kernel disables it by itself for some reason, and it actually does it sometimes), these errors seems to go away.

This is all on 2.4.18, but actually I think this is irrelevant.

Quoted 2 lines

If that's a bad cable, why it is only happens when both drives are working in DMA mode?

It's most likely the cable. The error comes directly from the status register of the drive. The drive is reporting that it got corrupted data from the wire. This will be only checked in the 80 cable requiring DMA transfer modes.

So if the drive resorts to
slower operation all will be fine. If it does not - well you see the above...

Having two drives on a single cable canges the termination of the cable as well as other electrical properties significantly and apparently you are just out of luck with the above system.

What should really help is simple resort to slower operations int he case of the driver.

It can of course be as well that the host chip driver is simply programming the channel for too aggressive values.

Hmm thinking again about it... It occurrs to me that actually there should be a mechanism which tells the host chip drivers whatever there are only just one or two drivers connected. I will have to look in to it.

I have 40 wires cable. When ide=nodma is passed to 2.5.17 kernel - kernel boots.

Am I correct that it is not possible to have DMA on with such cable?

Is there any reason for doing that?

Note that bus speed is 33 MHz when kernel fails to boot. I mean - how do I specify slower bus speed: 22 MHz?

Thanks.
Lena.

Quoted 20 lines · Martin Dalecki

Uz.ytkownik Gryaznova E. napisa?:

Quoted 18 lines

Hello.

Kernel starting from 2.5.8 can not boot my Suse 6.4. Booting on those kernels (tested 2.5.8, 2.5.9 and 2.5.17) I am always getting

{ dma_intr }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: recalibrating!

and system either hangs or falls into endless loop.

Kernel 2.5.7 boots and works just fine.
The boot log containing information about hardware is attached.

Badblock does not see any bad blocks.

Thanks for any clue on the problem.
Lena.

[skipped]

Quoted 5 lines

Quoted 2 lines

------------------------------------------------------------------------

You just have cabling problems which where previously hidden by the driver resorting to slower operation modes.

Quoted 7 lines

So please first have a look at the cabling inside your system. (First of all plase make sure of course that you are using a 80 wirde cable.) Or have a look in to the host chip driver and penalize the transfer mode supported to lower speeds. You can achieve basically a similar effect by setting the busspeed kernel parameter to some artificially high value as well.

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

Quoted 6 lines

I have 40 wires cable. When ide=nodma is passed to 2.5.17 kernel - kernel boots. Am I correct that it is not possible to have DMA on with such cable? Is there any reason for doing that?

Note that bus speed is 33 MHz when kernel fails to boot. I mean - how do I specify slower bus speed: 22 MHz?

You know what? I don't answer you directly I will just put a note about this in to Documentation/ide.txt which is long overdue anyway :-). You should better don't do UDMA>>66 with 40 write cablings. That's all.

Quoted 9 lines

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

Since this error can be expected to be quite common. Its an installation error. I will just make the corresponding error message more intelliglible to the average user:

hda: checksum error on data transfer occurred!

Would have hinted you propably directly at what's wrong.

Uz.ytkownik Oleg Drokin napisa?:

Quoted 28 lines

Hello!

Quoted 7 lines · Martin Dalecki

Quoted 2 lines

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

Since this error can be expected to be quite common. Its an installation error. I will just make the corresponding error message more intelliglible to the average user:
hda: checksum error on data transfer occurred!

BTW, I have a particular setup that spits out such errors, and I somehow thinks the cable is good.

I have IBM DTLA-307030 drive and Seagate Barracuda IV drive (last one purchased only recently).
IBM drive is connected to far end of 80-wires IDE cable and Barracuda is connected to the middle of this same wire.
Before I bought IBM drive, everything was ok.
But now I see BadCRC errors on hdb (only on hdb, which is barracuda drive) usually when both drives are active.
If I disable DMA on IBM drive (or if kernel disables it by itself for some reason, and it actually does it sometimes), these errors seems to go away.

This is all on 2.4.18, but actually I think this is irrelevant.

Quoted 2 lines

If that's a bad cable, why it is only happens when both drives are working in DMA mode?

It's most likely the cable. The error comes directly from the status register of the drive. The drive is reporting that it got corrupted data from the wire. This will be only checked in the 80 cable requiring DMA transfer modes.

So if the drive resorts to
slower operation all will be fine. If it does not - well you see the above...

Having two drives on a single cable canges the termination of the cable as well as other electrical properties significantly and apparently you are just out of luck with the above system.

What should really help is simple resort to slower operations int he case of the driver.

It can of course be as well that the host chip driver is simply programming the channel for too aggressive values.

Hmm thinking again about it... It occurrs to me that actually there should be a mechanism which tells the host chip drivers whatever there are only just one or two drivers connected. I will have to look in to it.

Hello!

Quoted 6 lines · Martin Dalecki

It's most likely the cable. The error comes directly from the status register of the drive. The drive is reporting that it got corrupted data from the wire. This will be only checked in the 80 cable requiring DMA transfer modes. So if the drive resorts to slower operation all will be fine. If it does not - well you see the above...

Note, that errors are only appearing on hdb (barracuda drive), but errors go away once I disable DMA on hda (IBM drive).
So the DMA is apparently is still on.
Hm, or is there some trick that if only one drive on the channel operates in DMA mode and second on in PIO mode, then everything resorts to PIO of some sort? But hdparm seems not to confirm that.

Quoted 3 lines

It can of course be as well that the host chip driver is simply programming the channel for too aggressive values.

BTW, that's
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6

Usually I see something like this:
hdb: dma_intr: error=0x84 { DriveStatusError BadCRC }
hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error } ... (some such messages) ... followed by:
hdb: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: DMA disabled
ide0: reset: success

Since this point, no more error messages.
I checked and hdb is actually in DMA mode at this point.

Hm, I also noticed that hdb have this setting:
I/O support = 3 (32-bit w/sync)

Never saw this before.

Quoted 18 lines · Martin Dalecki

Uz.ytkownik Oleg Drokin napisa?:

Quoted 17 lines

Hello!

Quoted 7 lines · Martin Dalecki

Quoted 2 lines

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

Since this error can be expected to be quite common. Its an installation error. I will just make the corresponding error message more intelliglible to the average user:
hda: checksum error on data transfer occurred!

BTW, I have a particular setup that spits out such errors, and I somehow thinks the cable is good.

I have IBM DTLA-307030

<offtopic>
Be prepared to some serious fun. I'm just in the middle of applying desesperate technics like RAID5/RAID0 on partitions from the same drive. Until I find some money to replace the failing drives I'm in for serious data recovery tricks if I want my grabbed video.
I've 6 drives here, from which 2 are IBM DTLAs and one is an IBM IC35. Guess which 3 ones slowly reported more and more "UncorrectableError"s (aka bad blocks) during last month ?
</offtopic>

Sorry, I feeled the need to hammer IBM drives in public. More insightful text should be find below.

Quoted 12 lines

Quoted 12 lines

drive and Seagate Barracuda IV drive (last one purchased
only recently).
IBM drive is connected to far end of 80-wires IDE cable and Barracuda is connected to the middle of this same wire.
Before I bought IBM drive, everything was ok.
But now I see BadCRC errors on hdb (only on hdb, which is barracuda drive) usually when both drives are active.
If I disable DMA on IBM drive (or if kernel disables it by itself for some reason, and it actually does it sometimes), these errors seems to go away.

This is all on 2.4.18, but actually I think this is irrelevant.

Quoted 7 lines

Quoted 2 lines

If that's a bad cable, why it is only happens when both drives are working in DMA mode?

It's most likely the cable. The error comes directly from the status register of the drive. The drive is reporting that it got corrupted data from the wire. This will be only checked in the 80 cable requiring DMA transfer modes.

If I'm not mistaken it's not the 80-cable tye that allows this (correct me if I'm wrong but the 40 new cables are grounded and act more like a shield between data/signal transport lines than anything else).
IIRC BadCRC is new to UDMA. You could have this error with UDMA mode 0 on a 40-pin cable.

Thanks to Andre Hedrick's code, the kernel automagically slows the dma modes until the BadCRC disappear.

Quoted 7 lines

So if the drive resorts to
slower operation all will be fine. If it does not - well you see the above...

Having two drives on a single cable canges the termination of the cable as well as other electrical properties significantly and apparently you are just out of luck with the above system.

I've seen this behaviour, adding a slave to an IDE bus can sometimes make it less reliable. My current opinion is that the signal/noise ratio on IDE busses has gone down too much with speed growing, you simply can't take whatever controller/drive/cable/power supply combination and say each one seems OK, the whole bus should operate at UDMA100/133 flawlessly. Nowadays you need to either stress test an IDE config or know the exact electronic behaviour of each component to validate that it will work without using Andre's code (and thus getting underspec perf).

Quoted 3 lines

What should really help is simple resort to slower operations int he case of the driver.

Already done, see above.

Quoted 3 lines

It can of course be as well that the host chip driver is simply programming the channel for too aggressive values.

Can be. Then it's a bug.

Quoted 5 lines

Hmm thinking again about it... It occurrs to me that actually there should be a mechanism which tells the host chip drivers whatever there are only just one or two drivers connected. I will have to look in to it.

The driver doesn't know, but the general IDE code does.

LB, going back to his damn drives...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

If you rewrite the whole drive with zeros (or the original data) sector by sector, the uncorrectable errors will go away. I've done this to my 307030 and it works fine again. (Fortunately for me the errors were only in my swap partition).

Quoted 6 lines · Vojtech Pavlik

If you rewrite the whole drive with zeros (or the original data) sector by sector, the uncorrectable errors will go away. I've done this to my 307030 and it works fine again. (Fortunately for me the errors were only in my swap partition).

Don't know for the whole drive yet (currently running) but when I did a mkraid on a raid5 array using 4 partitions on the same drive the sync thread ended and left the array in degraded mode after a bunch of :

May 24 02:05:06 twins kernel: hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
May 24 02:05:06 twins kernel: hdd: dma_intr: error=0x40 { UncorrectableError }, LBA sect=2097375, sector=2097298
May 24 02:05:06 twins kernel: end_request: I/O error, dev 16:41 (hdd), sector 2097298

Then I tried to zero the offending sectors with a slight margin :
[root@twins root]# dd if=/dev/zero of=/dev/hdd1 count=200 bs=512 seek=2097200
dd: writing /dev/hdd1': Erreur d'entrée/sortie
113+0 enregistrements lus.
112+0 enregistrements écrits.

Same error each time, seems sector 2097312 is not my friend.

dd if=/dev/zero of=/dev/hdd bs=<cylinder_size> running.

Too bad lsof doesn't show offsets...
I can't tell if dd passed the offending sector :-|

LB.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 2 lines

Quoted 2 lines

and I somehow thinks the cable is good.
I have IBM DTLA-307030

<offtopic>
Be prepared to some serious fun. I'm just in the middle of applying

Quoted 6 lines · Vojtech Pavlik

If you rewrite the whole drive with zeros (or the original data) sector by sector, the uncorrectable errors will go away. I've done this to my 307030 and it works fine again. (Fortunately for me the errors were only in my swap partition).

Don't know for the whole drive yet (currently running) but when I did a mkraid on a raid5 array using 4 partitions on the same drive the sync thread ended and left the array in degraded mode after a bunch of :

May 24 02:05:06 twins kernel: hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
May 24 02:05:06 twins kernel: hdd: dma_intr: error=0x40 { UncorrectableError }, LBA sect=2097375, sector=2097298
May 24 02:05:06 twins kernel: end_request: I/O error, dev 16:41 (hdd), sector 2097298

Then I tried to zero the offending sectors with a slight margin :
[root@twins root]# dd if=/dev/zero of=/dev/hdd1 count=200 bs=512 seek=2097200
dd: writing /dev/hdd1': Erreur d'entrée/sortie
113+0 enregistrements lus.
112+0 enregistrements écrits.

Same error each time, seems sector 2097312 is not my friend.

dd if=/dev/zero of=/dev/hdd bs=<cylinder_size> running.

Too bad lsof doesn't show offsets...
I can't tell if dd passed the offending sector :-|

Quoted 23 lines · Lionel Bouton

Quoted 6 lines · Vojtech Pavlik

If you rewrite the whole drive with zeros (or the original data) sector by sector, the uncorrectable errors will go away. I've done this to my 307030 and it works fine again. (Fortunately for me the errors were only in my swap partition).

Don't know for the whole drive yet (currently running) but when I did a mkraid on a raid5 array using 4 partitions on the same drive the sync thread ended and left the array in degraded mode after a bunch of :

May 24 02:05:06 twins kernel: hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
May 24 02:05:06 twins kernel: hdd: dma_intr: error=0x40 { UncorrectableError }, LBA sect=2097375, sector=2097298
May 24 02:05:06 twins kernel: end_request: I/O error, dev 16:41 (hdd), sector 2097298

Then I tried to zero the offending sectors with a slight margin :
[root@twins root]# dd if=/dev/zero of=/dev/hdd1 count=200 bs=512 seek=2097200
dd: writing /dev/hdd1': Erreur d'entrée/sortie
113+0 enregistrements lus.
112+0 enregistrements écrits.

Same error each time, seems sector 2097312 is not my friend.

Quoted 4 lines

dd if=/dev/zero of=/dev/hdd bs=<cylinder_size> running.

Too bad lsof doesn't show offsets...
I can't tell if dd passed the offending sector :-|

Well, if writing failed, it means the drive has ran out of relocatable sectors. That's too bad ... best to send it in for replacement.

Quoted 5 lines

Hmm thinking again about it... It occurrs to me that actually there should be a mechanism which tells the host chip drivers whatever there are only just one or two drivers connected. I will have to look in to it.

There is no such mechanism (except for probing the drives). IDE has quite nonsensical "split" termination - the termination resistors are always present even on the middle device. This is to "simplify" things
...

Quoted 7 lines · Użytkownik Vojtech Pavlik

Quoted 5 lines

Hmm thinking again about it... It occurrs to me that actually there should be a mechanism which tells the host chip drivers whatever there are only just one or two drivers connected. I will have to look in to it.

Quoted 5 lines

There is no such mechanism (except for probing the drives). IDE has quite nonsensical "split" termination - the termination resistors are always present even on the middle device. This is to "simplify" things
...

Yes there is the host chip timer setting is basically changing the termination properties on the hsot chips part of the connection. This is the reason I was thinking that making the driver for it know how many drivers are attached to it could make some sense.

Quoted 15 lines · Martin Dalecki

Quoted 11 lines · Użytkownik Vojtech Pavlik

Quoted 4 lines

Hmm thinking again about it... It occurrs to me that actually there should be a mechanism which tells the host chip drivers whatever there are only just one or two drivers connected. I will have to look in to it.

There is no such mechanism (except for probing the drives). IDE has quite nonsensical "split" termination - the termination resistors are always present even on the middle device. This is to "simplify" things
...

Quoted 5 lines

Yes there is the host chip timer setting is basically changing the termination properties on the hsot chips part of the connection. This is the reason I was thinking that making the driver for it know how many drivers are attached to it could make some sense.

Hmm, interesting. Is it on all chips or just some? I don't know about anything like that on Intel, VIA, nVidia, AMD, SiS and Artop controllers ...

Quoted 24 lines · Użytkownik Vojtech Pavlik

Quoted 20 lines · Martin Dalecki

Quoted 11 lines · Użytkownik Vojtech Pavlik

Quoted 4 lines

Hmm thinking again about it... It occurrs to me that actually there should be a mechanism which tells the host chip drivers whatever there are only just one or two drivers connected. I will have to look in to it.

There is no such mechanism (except for probing the drives). IDE has quite nonsensical "split" termination - the termination resistors are always present even on the middle device. This is to "simplify" things
...

Yes there is the host chip timer setting is basically changing the termination properties on the hsot chips part of the connection. This is the reason I was thinking that making the driver for it know how many drivers are attached to it could make some sense.

Quoted 2 lines

Hmm, interesting. Is it on all chips or just some? I don't know about anything like that on Intel, VIA, nVidia, AMD, SiS and Artop controllers ...

Hey what I'm talking about is the "physics" of the hardware. But I would rather expect sane hardware to deal with it transparently to the programmer of the setup registers.

Quoted 3 lines

Hey what I'm talking about is the "physics" of the hardware. But I would rather expect sane hardware to deal with it transparently to the programmer of the setup registers.

Well, when I hear "timer" I think "engineering", not "physics". And a timer would have to be visible somewhere. I really don't think the controller can tell how many drives it sees unless it measures the termination resistance or somesuch.

Quoted 9 lines · Użytkownik Vojtech Pavlik

Quoted 3 lines

Hey what I'm talking about is the "physics" of the hardware. But I would rather expect sane hardware to deal with it transparently to the programmer of the setup registers.

Well, when I hear "timer" I think "engineering", not "physics". And a timer would have to be visible somewhere. I really don't think the controller can tell how many drives it sees unless it measures the termination resistance or somesuch.

Jak się zwał tak się zwał, byle by się dobrze miał :-).

Anyway measuring the termination resistance is rather trivial from the electrical point of view...