Hello,
My onboard (Epox 8KTA3+) HPT370 controller seems to set the wrong udma
transfer mode for the attached drive. Resulting in BadCRC errors. The drive
attached is an IBM DJSA-205 2.5" drive. It can do udma4 max.
The HD is connected with the controller with a 3.5"->2.5" adapter
cable that is only 40 pin. The controller BIOS shows that the drive uses
udma2. However when I boot Linux the HPT370 driver sets the drive to udma4.
Setting the mode manually with hdparm makes the drive work.
The drive is correctly accessed with udma2 when attached to the
VIA686B IDE controller. Cable type "40w" is shown in /proc/ide/via. Does the
HPT driver even detect if there is an 80w or 40w cable in place? The
chip should be able to distinguish this somehow since the correct mode is
shown in the BIOS.
The log messages for the ide controllers are (drive set to UDMA(66)):
Kernel is 2.4.16
[...]
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
ide0: BM-DMA at 0xa000-0xa007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xa008-0xa00f, BIOS settings: hdc:pio, hdd:DMA
HPT370A: IDE controller on PCI bus 00 dev 70
PCI: Found IRQ 10 for device 00:0e.0
PCI: Sharing IRQ 10 with 00:09.0
HPT370A: chipset revision 4
HPT370A: not 100% native mode: will probe irqs later
ide2: BM-DMA at 0xcc00-0xcc07, BIOS settings: hde:DMA, hdf:pio
ide3: BM-DMA at 0xcc08-0xcc0f, BIOS settings: hdg:pio, hdh:pio
hda: IBM-DHEA-36481, ATA DISK drive
hdb: IBM-DJNA-351520, ATA DISK drive
hdd: Pioneer CD-ROM ATAPI Model DR-744 0102, ATAPI CD/DVD-ROM drive
hde: IBM-DJSA-205, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xbc00-0xbc07,0xc002 on irq 10
hda: 12692736 sectors (6499 MB) w/472KiB Cache, CHS=790/255/63, UDMA(33)
hdb: 30033360 sectors (15377 MB) w/430KiB Cache, CHS=1869/255/63, UDMA(33)
hde: 9767520 sectors (5001 MB) w/384KiB Cache, CHS=10336/15/63, UDMA(66)
hdd: ATAPI 32X CD-ROM drive, 128kB Cache, DMA
The drive settings after the boot:
/dev/discs/disc2/disc:
Model=IBM-DJSA-205, FwRev=JS1OAB7A, SerialNo=8ZY8Z353728
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=10336/15/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=DualPortCache, BuffSize=384kB, MaxMultSect=16, MultSect=off
CurCHS=10336/15/63, CurSects=9767520, LBA=yes, LBAsects=9767520
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4
Writing/reading data results in:
Jan 10 15:40:42 kiza kernel: hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Jan 10 15:40:42 kiza kernel: hde: dma_intr: error=0x84 { DriveStatusError BadCRC }
Jan 10 15:40:42 kiza kernel: hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Jan 10 15:40:42 kiza kernel: hde: dma_intr: error=0x84 { DriveStatusError BadCRC }
Jan 10 15:40:42 kiza kernel: hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Jan 10 15:40:42 kiza kernel: hde: dma_intr: error=0x84 { DriveStatusError BadCRC }
Jan 10 15:40:42 kiza kernel: hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Jan 10 15:40:42 kiza kernel: hde: dma_intr: error=0x84 { DriveStatusError BadCRC }
Jan 10 15:40:43 kiza kernel: ide2: reset: success
--
Oliver Feiler [email protected]
http://www.lionking.org/~kiza/pgpkey PGP key ID: 0x561D4FD2
http://www.lionking.org/~kiza/
On Thu, 10 Jan 2002, Oliver Feiler wrote:
> My onboard (Epox 8KTA3+) HPT370 controller seems to set the
> wrong udma transfer mode for the attached drive. Resulting in BadCRC
> errors. The drive attached is an IBM DJSA-205 2.5" drive. It can do
> udma4 max.
> Kernel is 2.4.16
I've heard this problem is fixed with Andre Hedrik's new
IDE drivers, available from:
http://www.linuxdiskcert.org/
cheers,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
> My onboard (Epox 8KTA3+) HPT370 controller seems to set the wrong udma
> transfer mode for the attached drive. Resulting in BadCRC errors. The drive
> attached is an IBM DJSA-205 2.5" drive. It can do udma4 max.
Make sure you use the Andre Hedrick ide patches with the HPT 370. That fixed
all my problems with them at least
(http://www.linux-ide.org)
Alan Cox wrote:
> Make sure you use the Andre Hedrick ide patches with the HPT 370. That fixed
> all my problems with them at least
> (http://www.linux-ide.org)
Didn't solve my problem unfortunately.
With the patch applied, the kernel still says it uses UDMA(66) on boot
and hdparm also says the drive is in udma4 mode. Writing data to it results in
BadCRC.
However, /proc/ide/hpt366 with the patch applied shows ATA-33 mode.
Something's wrong here.
CC'ing this to Andre Hedrick. Maybe he knows what's wrong?
Bye
Oliver
--
Oliver Feiler [email protected]
http://www.lionking.org/~kiza/pgpkey PGP key ID: 0x561D4FD2
http://www.lionking.org/~kiza/
On Thu, Jan 10 2002, Oliver Feiler wrote:
>
> Alan Cox wrote:
> > Make sure you use the Andre Hedrick ide patches with the HPT 370. That fixed
> > all my problems with them at least
> > (http://www.linux-ide.org)
>
> Didn't solve my problem unfortunately.
>
> With the patch applied, the kernel still says it uses UDMA(66) on boot
> and hdparm also says the drive is in udma4 mode. Writing data to it results in
> BadCRC.
>
> However, /proc/ide/hpt366 with the patch applied shows ATA-33 mode.
> Something's wrong here.
>
> CC'ing this to Andre Hedrick. Maybe he knows what's wrong?
>
Try this patch... apply it after the latest patch from Andre becuase that
includes several other crucial highpoint fixes. It looks like the cable
detect pins are also used as address lines and so must be configured as
inputs to read valid cable detect state.
-duncan
--- linux/drivers/ide/hpt366.c~ Thu Jan 10 17:08:01 2002
+++ linux/drivers/ide/hpt366.c Thu Jan 10 17:10:17 2002
@@ -1140,7 +1140,21 @@
byte ata66 = 0;
byte regmask = (hwif->channel) ? 0x01 : 0x02;
- pci_read_config_byte(hwif->pci_dev, 0x5a, &ata66);
+ if (pci_rev_check_hpt3xx(hwif->pci_dev)) {
+ byte scr2;
+ /*
+ * The HPT370 uses the CBLID pin outputs as MA15/MA16
+ * address lines to access an external eeprom. To
+ * read cable detect state the pins must be enabled
+ * as inputs by clearing bit 0 of reg 0x5b.
+ */
+ pci_read_config_byte(hwif->pci_dev, 0x5b, &scr2);
+ pci_write_config_byte(hwif->pci_dev, 0x5b, scr2 & ~1);
+ pci_read_config_byte(hwif->pci_dev, 0x5a, &ata66);
+ pci_write_config_byte(hwif->pci_dev, 0x5b, scr2 | 1);
+ } else {
+ pci_read_config_byte(hwif->pci_dev, 0x5a, &ata66);
+ }
#ifdef DEBUG
printk("HPT366: reg5ah=0x%02x ATA-%s Cable Port%d\n",
ata66, (ata66 & regmask) ? "33" : "66",
Duncan Laurie wrote:
>
> Try this patch... apply it after the latest patch from Andre becuase that
> includes several other crucial highpoint fixes. It looks like the cable
> detect pins are also used as address lines and so must be configured as
> inputs to read valid cable detect state.
That solved the problem. Thank you.
Oliver
--
Oliver Feiler [email protected]
http://www.lionking.org/~kiza/pgpkey PGP key ID: 0x561D4FD2
http://www.lionking.org/~kiza/