IDE problem: linux-2.5.17

IDE problem: linux-2.5.17

[Gryaznova E.]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

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.




[-- Attachment #2: 2.5.7.dmesg --]
[-- Type: text/plain, Size: 6025 bytes --]

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 }
ide0: reset: success
Adding Swap: 136544k swap-space (priority -1)

Re: IDE problem: linux-2.5.17

[Martin Dalecki]

Uz.ytkownik Gryaznova E. napisa?:
> 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 }
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.

Re: IDE problem: linux-2.5.17

[Martin Dalecki]

> 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.

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Martin Dalecki]

Uz.ytkownik Oleg Drokin napisa?:
> Hello!
> 
> On Thu, May 23, 2002 at 04:27:39PM +0200, Martin Dalecki wrote:
> 
>>>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?

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.

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Oleg Drokin]

Hello!

On Thu, May 23, 2002 at 04:27:39PM +0200, Martin Dalecki wrote:
> >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?

Thank you.

Bye,
    Oleg

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Tomas Szepe]

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

Because, as you probably know, cable problems usually manifest themselves
during high transfer rates, where DMA is the prerequisite. Up to ATA33, you
might nearly hook your drives up using a shoelace w/o running into trouble,
ATA66+, however, seems to be very sensitive to good cabling.

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

T.

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.

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Oleg Drokin]

Hello!

On Thu, May 23, 2002 at 04:44:26PM +0200, Martin Dalecki wrote:

> 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.

> 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. 

Bye,
    Oleg

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Oleg Drokin]

Hello!

On Thu, May 23, 2002 at 05:52:37PM +0200, Tomas Szepe wrote:

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

I'll try.

> 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.

I know this, but my Abit VP6 motherboard burned out and I am resorted to
another one for now, there are only 2 IDE channels present. And I have a CDROM
drive in addition to these drives.

Bye,
    Oleg

Re: IDE problem: linux-2.5.17

[Gryaznova E.]

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.

Martin Dalecki wrote:

> Uz.ytkownik Gryaznova E. napisa?:
> > 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]

> >
> > ------------------------------------------------------------------------
> 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.

Re: IDE problem: linux-2.5.17

[Martin Dalecki]

Uz.ytkownik Andre Hedrick napisa?:
> 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.

Re: IDE problem: linux-2.5.17

[Tomas Szepe]

> 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.

Re: IDE problem: linux-2.5.17

[Martin Dalecki]

Uz.ytkownik Gryaznova E. napisa?:
> 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.

Re: IDE problem: linux-2.5.17

[Andre Hedrick]

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.

On Thu, 23 May 2002, Tomas Szepe wrote:

> > 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 majordomo@vger.kernel.org
> 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

Re: IDE problem: linux-2.5.17

[Andre Hedrick]

Well if people are doing embedded in close quarters and they can use the
knowledge, they need to have it.  The drive is/was designed to deal with
this issue in several ways.

Testing the for the decay from POST for DEVICE side detection of any
capable cable.  Next if the HOST also supports detection and it senses its
own cable capacitance is acceptable, then it will work.

You need to be able to support conclusions of how and why, because people
will see this in the real world and wonder why.

Cheers,


On Thu, 23 May 2002, Martin Dalecki wrote:

> Uz.ytkownik Andre Hedrick napisa?:
> > 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.
> 

Andre Hedrick
LAD Storage Consulting Group

Re: IDE problem: linux-2.5.17

[Andre Hedrick]

Also the standard is clear only in what minimal expected requirements are
needed to support the protocol.  In time you will learn where the tricks
of the trade are and when someone is attempted to go there and/or push
beyond.

Cheers,

On Thu, 23 May 2002, Martin Dalecki wrote:

> Uz.ytkownik Andre Hedrick napisa?:
> > 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 majordomo@vger.kernel.org
> 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

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Lionel Bouton]

On jeu, mai 23, 2002 at 04:44:26 +0200, Martin Dalecki wrote:
> Uz.ytkownik Oleg Drokin napisa?:
> > Hello!
> > 
> > On Thu, May 23, 2002 at 04:27:39PM +0200, Martin Dalecki wrote:
> > 
> >>>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. 

> > 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?
> 
> 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.

> 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).

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

Already done, see above.

> 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.

> 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...

Re: IDE problem: linux-2.5.17

[Vojtech Pavlik]

On Thu, May 23, 2002 at 09:48:35PM +0400, Gryaznova E. wrote:

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

Can you supply the contents of /proc/ide/amd74xx? That'd tell us whether
the cable type is detected correctly, etc.

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

It is possible, though only up to UDMA33.

> 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?

The bus speed IS 33 MHz and it cannot be changed (unless you
overclock(ed) the processor. If you specify a faster speed (eg. 40 MHz),
the IDE controller will be set up for slower operation to compensate,
while the true speed will stay the same.

> 
> Thanks.
> Lena.
> 
> Martin Dalecki wrote:
> 
> > Uz.ytkownik Gryaznova E. napisa?:
> > > 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]
> 
> > >
> > > ------------------------------------------------------------------------
> > 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.
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Vojtech Pavlik
SuSE Labs

Re: IDE problem: linux-2.5.17

[Vojtech Pavlik]

On Thu, May 23, 2002 at 11:44:44AM -0700, Andre Hedrick wrote:
> 
> 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.

Hmm, last time we were discussing you were saying that only 80 wire
cables work, and I was saying that short enough 40 wire cables are OK as
well (even in some older revision of the spec) ....

... interesting.

Anyway, 40 wire cables can really only work with a single drive and have
to be really short. And, Linux should only use UDMA33 and lower on
them, because it can't know the length of the cable.

> 
> On Thu, 23 May 2002, Tomas Szepe wrote:
> 
> > > 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 majordomo@vger.kernel.org
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Vojtech Pavlik
SuSE Labs

Re: IDE problem: linux-2.5.17

[Vojtech Pavlik]

On Thu, May 23, 2002 at 08:07:28PM +0200, Martin Dalecki wrote:

> > 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.

The kernel shouldn't select that automatically. If it does, it's a bug.

As for manual setting, it should emit a warning.

-- 
Vojtech Pavlik
SuSE Labs

Re: IDE problem: linux-2.5.17

[Vojtech Pavlik]

On Thu, May 23, 2002 at 04:27:39PM +0200, Martin Dalecki wrote:
> 
> > 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.

There is a routine in the IDE code to decrease transfer speed in case of
these problems. And it is there for a good reason - many (namely UDMA66)
mainboards have incorrectly wired IDE traces and can never achieve full
UDMA speeds, and there is no way to know.

For that I've also created UDMA_SLOW, which is even slower than UDMA_0
(16.6 MB/sec), which still has CRC protection, and needs even less
physical bandwidth than PIO4.

-- 
Vojtech Pavlik
SuSE Labs

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Vojtech Pavlik]

On Thu, May 23, 2002 at 04:44:26PM +0200, Martin Dalecki wrote:
> Uz.ytkownik Oleg Drokin napisa?:
> > Hello!
> > 
> > On Thu, May 23, 2002 at 04:27:39PM +0200, Martin Dalecki wrote:
> > 
> >>>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?
> 
> 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.

No. It doesn't depend on the number of cables - the additional cables
are GND only. 32-bit CRCs are used even on 40 wire cables.

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

The driver cannot resort to a slower speed by itself - the kernel has to
tell it.

Also note than on UDMA we have two different speeds - for writing we set
it in the controller registers and for reading it's set on the drive by
a set_feature command.

In PIO and DMA modes everything is driven by the controller.

> 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.

It might not be the cable, but the drives - I'd try exchanging their
positions.

> 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.

Depends whether it happens on reads or writes. For reads it'd be the
drive is too fast and the controller can't get the data (because the
data is damaged electrically or it just can't cope with the speed), for
writes it's the opposite.

> 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
...

-- 
Vojtech Pavlik
SuSE Labs

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Vojtech Pavlik]

On Thu, May 23, 2002 at 08:00:05PM +0400, Oleg Drokin wrote:
> Hello!
> 
> On Thu, May 23, 2002 at 04:44:26PM +0200, Martin Dalecki wrote:
> 
> > 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.

It's probably because in DMA mode the IBM drive has different electrical
properties on the cable.

> 
> > 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

Doesn't tell much ...

> 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. 

I think the driver sets this when it sees the problems ...

-- 
Vojtech Pavlik
SuSE Labs

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Vojtech Pavlik]

On Thu, May 23, 2002 at 11:47:20PM +0200, Lionel Bouton wrote:
> On jeu, mai 23, 2002 at 04:44:26 +0200, Martin Dalecki wrote:
> > Uz.ytkownik Oleg Drokin napisa?:
> > > Hello!
> > > 
> > > On Thu, May 23, 2002 at 04:27:39PM +0200, Martin Dalecki wrote:
> > > 
> > >>>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>

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).

> Sorry, I feeled the need to hammer IBM drives in public. More insightful text
> should be find below. 
> 
> > > 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?
> > 
> > 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.
> 
> > 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).
> 
> > What should really help is simple resort to slower operations
> > int he case of the driver.
> > 
> 
> Already done, see above.
> 
> > 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.
> 
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Vojtech Pavlik
SuSE Labs

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Lionel Bouton]

On Fri, May 24, 2002 at 12:55:25AM +0200, Vojtech Pavlik wrote:
> 
> 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.

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Andre Hedrick]

Well now you know the use of the pass throught diagnotics interface of the
deleted IOCTL.  You could get there from here but not anymore.

On Fri, 24 May 2002, Lionel Bouton wrote:

> On Fri, May 24, 2002 at 12:55:25AM +0200, Vojtech Pavlik wrote:
> > 
> > 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 majordomo@vger.kernel.org
> 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

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Oleg Drokin]

Hello!

On Thu, May 23, 2002 at 11:47:20PM +0200, Lionel Bouton wrote:

> > > 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

Yes, I know.
It is failing already, but SMART is doing it's job. Why do you think
I bought the Barracuda in first place? ;)
Funnily, IBM's disk tool says "0x72 Excessive shock" as an error code for the
drive ;)

Bye,
    Oleg

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Vojtech Pavlik]

On Fri, May 24, 2002 at 02:23:51AM +0200, Lionel Bouton wrote:
> On Fri, May 24, 2002 at 12:55:25AM +0200, Vojtech Pavlik wrote:
> > 
> > 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 :-|

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.

-- 
Vojtech Pavlik
SuSE Labs

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Lionel Bouton]

On Fri, May 24, 2002 at 07:56:34AM +0200, Vojtech Pavlik wrote:
> On Fri, May 24, 2002 at 02:23:51AM +0200, Lionel Bouton wrote:
> > On Fri, May 24, 2002 at 12:55:25AM +0200, Vojtech Pavlik wrote:
> > > 
> > > 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 :-|
> 
> 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.
> 

Guarantee expired.
But...

The dd on the whole disk was successful!
Now I really wonder how IBM drives handle my data.

This drive ss now splitted in 4 partitions with a RAID5 array built on top.
BTW the raid5 sync was succesful.
If badblocks bring their ugly head again I've one more chance to move
the data out. Glad I don't need much throughput...

I've 2 other drives that are waiting such a treatment. The data I can
get on the first should be safe in a couple of hours. If someone
curious wants me to make tests on them, feel free to ask as I don't have any
insight on what to test to get a clear picture.

LB.

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Martin Dalecki]

Użytkownik Vojtech Pavlik napisał:

> 
>>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.

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Martin Dalecki]

Użytkownik Vojtech Pavlik napisał:
> On Fri, May 24, 2002 at 01:03:26PM +0200, Martin Dalecki wrote:
> 
>>Użytkownik Vojtech Pavlik napisał:
>>
>>
>>>>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.
> 
> 
> 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.

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Vojtech Pavlik]

On Fri, May 24, 2002 at 01:03:26PM +0200, Martin Dalecki wrote:
> Użytkownik Vojtech Pavlik napisał:
> 
> > 
> >>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.

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 ...

-- 
Vojtech Pavlik
SuSE Labs

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Vojtech Pavlik]

On Fri, May 24, 2002 at 02:15:30PM +0200, Martin Dalecki wrote:
> Użytkownik Vojtech Pavlik napisał:
> > On Fri, May 24, 2002 at 01:03:26PM +0200, Martin Dalecki wrote:
> > 
> >>Użytkownik Vojtech Pavlik napisał:
> >>
> >>
> >>>>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.
> > 
> > 
> > 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.

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.

-- 
Vojtech Pavlik
SuSE Labs

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Martin Dalecki]

Użytkownik Vojtech Pavlik napisał:

>>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...

Re: [reiserfs-dev] Re: IDE problem: linux-2.5.17

[Vojtech Pavlik]

On Fri, May 24, 2002 at 03:40:32PM +0200, Martin Dalecki wrote:
> Użytkownik Vojtech Pavlik napisał:
> 
> >>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...

Yes, but trust me that if they don't absolutely have to do it to make it
work, they won't do it. IDE hardware is cheap in the first place.

-- 
Vojtech Pavlik
SuSE Labs

Re: IDE problem: linux-2.5.17

[Alan Cox]

> Uz.ytkownik Andre Hedrick napisa?:
> > 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.

And Linux is supposed to run properly on those boxes not on some abstract
specification. Never forget that.

Alan