Over the past two weekends I have upgraded my BP6 system to -current, and
ported the patches for the HPT366 UDMA/66 controller which I'd already done
for 1.4.  However, I am so far completely unable to get both UDMA/66 channels
to work simultaneously.  Here is my current configuration:

Mar  6 21:07:51 gibbons /netbsd: pciide0 at pci0 dev 7 function 1: Intel 82371AB IDE controller (PIIX4)
Mar  6 21:07:51 gibbons /netbsd: pciide0: bus-master DMA support present
Mar  6 21:07:52 gibbons /netbsd: pciide0: primary channel wired to compatibility mode
Mar  6 21:07:52 gibbons /netbsd: atapibus0 at pciide0 channel 0
Mar  6 21:07:52 gibbons /netbsd: cd0 at atapibus0 drive 1: <SAMSUNG SC-140B, , BS13> type 5 cdrom removable
Mar  6 21:07:52 gibbons /netbsd: cd0: 32-bits data port
Mar  6 21:07:52 gibbons /netbsd: cd0: drive supports PIO mode 4, DMA mode 2
Mar  6 21:07:52 gibbons /netbsd: wd0 at pciide0 channel 0 drive 0: <QUANTUM LPS340A>
Mar  6 21:07:52 gibbons /netbsd: wd0: drive supports 8-sector pio transfers, chs addressing
Mar  6 21:07:52 gibbons /netbsd: wd0: 325 MB, 1011 cyl, 15 head, 44 sec, 512 bytes/sect x 667260 sectors
Mar  6 21:07:52 gibbons /netbsd: wd0: 32-bits data port
Mar  6 21:07:53 gibbons /netbsd: wd0: drive supports PIO mode 3, DMA mode 1
Mar  6 21:07:53 gibbons /netbsd: pciide0: primary channel interrupting at irq 14
Mar  6 21:07:53 gibbons /netbsd: wd0(pciide0:0:0): using PIO mode 0, DMA mode 1 (using DMA data transfers)
Mar  6 21:07:53 gibbons /netbsd: cd0(pciide0:0:1): using PIO mode 4, DMA mode 2 (using DMA data transfers)
Mar  6 21:07:53 gibbons /netbsd: pciide0: secondary channel wired to compatibility mode
Mar  6 21:07:53 gibbons /netbsd: pciide0: disabling secondary channel (no drives)

	.
	.
	.
Mar  6 21:07:54 gibbons /netbsd: pciide1 at pci0 dev 19 function 0: Triones/Highpoint HPT366 UDMA/66 IDE Controller
Mar  6 21:07:54 gibbons /netbsd: pciide1: bus-master DMA support present
Mar  6 21:07:54 gibbons /netbsd: pciide1: reg51h = 0x00
Mar  6 21:07:54 gibbons /netbsd: pciide1: channel 0 UDMA/66 cable (reg5ah = 0x01)
Mar  6 21:07:54 gibbons /netbsd: pciide1: primary channel configured to native-PCI mode
Mar  6 21:07:55 gibbons /netbsd: pciide1: using irq 11 for native-PCI interrupt
Mar  6 21:07:55 gibbons /netbsd: wd1 at pciide1 channel 0 drive 0: <ST36531A>
Mar  6 21:07:55 gibbons /netbsd: wd1: drive supports 32-sector pio transfers, lba addressing
Mar  6 21:07:55 gibbons /netbsd: wd1: 6204 MB, 13446 cyl, 15 head, 63 sec, 512 bytes/sect x 12706470 sectors
Mar  6 21:07:55 gibbons /netbsd: wd1: 32-bits data port
Mar  6 21:07:55 gibbons /netbsd: wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2
Mar  6 21:07:55 gibbons /netbsd: wd1: bus speed register = 0x90caa731
Mar  6 21:07:55 gibbons /netbsd: wd1(pciide1:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 2 (using DMA data transfers)
Mar  6 21:07:55 gibbons /netbsd: pciide2 at pci0 dev 19 function 1: Triones/Highpoint HPT366 UDMA/66 IDE Controller
Mar  6 21:07:55 gibbons /netbsd: pciide2: bus-master DMA support present
Mar  6 21:07:55 gibbons /netbsd: pciide2: reg51h = 0x00
Mar  6 21:07:55 gibbons /netbsd: pciide2: channel 0 UDMA/66 cable (reg5ah = 0x01)
Mar  6 21:07:56 gibbons /netbsd: pciide2: primary channel configured to native-PCI mode
Mar  6 21:07:56 gibbons /netbsd: pciide2: using irq 11 for native-PCI interrupt
Mar  6 21:07:56 gibbons /netbsd: wd2 at pciide2 channel 0 drive 0: <ST320430A>
Mar  6 21:07:56 gibbons /netbsd: wd2: drive supports 16-sector pio transfers, lba addressing
Mar  6 21:07:56 gibbons /netbsd: wd2: 19569 MB, 16383 cyl, 16 head, 63 sec, 512 bytes/sect x 40079088 sectors
Mar  6 21:07:57 gibbons /netbsd: wd2: 32-bits data port
Mar  6 21:07:57 gibbons /netbsd: wd2: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 4
Mar  6 21:07:58 gibbons /netbsd: wd2: bus speed register = 0x90c9a731
Mar  6 21:07:58 gibbons /netbsd: wd2(pciide2:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 4 (using DMA data transfers)

Note that the HPT366 probes as 2 single-channel controllers.
wd0 is the system disk.  With one exception (which I'll come to later), I can
access EITHER wd1 OR wd2.  I can read partitions with dd, I can mount
filesystems and read from them and write to them.  I can duplicate wd0 to
wd2 (in UDMA mode 4) and boot from it (still in UDMA mode 4).

But when I try to read from wd1 and wd2 simultaneously, I get an immediate
hang, and I can't break in with kgdb to see what's happening.

I wondered if for some reason the chip couldn't actually handle different
UDMA modes on the two interfaces, so I compiled a kernel with the
ST320430A forced to UDMA mode 2, but this hung in the same way.
I have also found that the FreeBSD driver has support for the HPT366,
but I can't see anything obvious which it does and my code doesn't.

An early version of the Linux HOWTO says that only one UDMA/66 channel
is supported, and although a later version says it's now possible to
use both channels I haven't been able to identify the code changes. I am
coming to the conclusion that the HPT366 can't handle concurrent
transfers on the two channels, and (like the CMD chips) requires a
shared command queue.  There is code in the Linux driver which appears
to enforce this restriction, but it is commented out for the HPT366.
This evening I will try modifying the driver to use a shared command queue,
and see if that works.

I'll post some patches this evening, although depending on my success with
a shared command queue, these may only work with one channel.  As I have
only one UDMA/66-capable drive, it would be useful if someone could confirm
that two drives in UDMA mode 4 work on the same channel.

There are two further problems:

1.  I couldn't get the ST36531A (UDMA mode 2) and the ST320430A (UDMA mode 4)
to work on the same channel.  I will go back and look at this when I have
got both channels working, as the cabling is very crowded and I don't want
to disturb it any more than necessary (the last thing I need is for a
cable to go flakey on me!).  I am still not completely sure what combinations
of disk modes are allowed, so I'd be very glad of the following information
from anyone who has a HPT366 running under Linux (or FreeBSD) with more
than one disk attached (whether on one or two channels):

    Your disk configuration, and the UDMA mode in which each disk attaches

    The Kernel version

    The BIOS version (including the HPT366 BIOS version which appears
    briefly on reset before the attached drives are listed).  My BP6
    motherboard was bought in August last year and has the first version
    of the BIOS, so I suppose it's possible something isn't getting set up
    properly.


2.  The other problem is that a test read of a disk using

        dd if=/dev/rwd1d of=/dev/null

    eventually hangs the machine with

        pciide1: lost interrupt

    I think this is because the NetBSD disklabel always seems to be a few
    blocks bigger than the real size of the disk.  When I've used dd in the
    past to read the d partition of a disk as a quick check for bad blocks
    I've always had a few hard errors at the end of the disk.  However,
    with the HPT366 the machine locks up completely, and again I can't get
    in with kgdb to see what's happened.  It's as though the reads from the
    non-existant sectors never complete, so whatever recovery action
    wdctimeout takes never returns.  Reading the last 'real' partition on
    the disk (which ends a few sectors short of the end of the d partition)
    works without any problem.



Roger

------------------------------------------------------------------------------
Roger Brooks (Systems Programmer),          |  Email: R.S.Brooks@liv.ac.uk
Computing Services Dept,                    |  Tel:   +44 151 794 4441
The University of Liverpool,                |  Fax:   +44 151 794 4442
PO Box 147, Liverpool L69 3BX, UK           | 
------------------------------------------------------------------------------