Robert Redelmeier wrote:
>
> bug1 wrote:
> > I got the drivers for my various hdd to put them permanently on udma/33
> > mode, however one of my drives is still detected as UDMA/66 by the
> > HPT366 BIOS
>
> This is normal. The BIOS asks the drives what they can do. Then
> Linux ignores it. But it sounds like you're using the HPT366 Linux
> driver. This may have bugs in it. AFAIK, the Bootprompt method
> uses the standard EIDE drivers&kernel, and just tells Linux where
> to find the HPT366. I would consider this method most reliable
> until the HPT366 driver is fully debugged.
>
How can i tell if im using the ide HPT366 drivers or the generic ide
drivers ?
Today ive been doing "lspci -vv" to get the ioports and passing them as
kernel parameters.
eg. "ide2=0x9800,0x9c00 ide3=0xa400,0xa800 ide4=0xb000,0xb400
ide5=0xbc00,0xc000"
An extract for hpt366 lspci -vv gives four listing like below (with
different numbers)
Latency: 8 min, 8 max, 248 set, cache line size 08
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at 9800 [size=8]
Region 1: I/O ports at 9c00 [size=4]
Region 4: I/O ports at a000 [size=256]
When i compiled hpt366 support LATENCY was set to 120, how come it says
min 8, max 8, surely they cant all be correct values ?
The intel ide channel has a latency set to 32, it doesnt have any min or
max entry.
Also, the interrupt line differs, the two onboard hpt366 channels are
exactly the same, but the PCI HPT366 (plub-in board) has
ide2 Interrupt: pin A routed to IRQ 16
ide3 Interrupt: pin A routed to IRQ 16
ide4 Interrupt: pin A routed to IRQ 18
ide5 Interrupt: pin B routed to IRQ 18
Should ide2 and ide3 be exactly the same, same pin and everything ?
When i boot i get
....
hde: probing with STATUS(0x50) instead of ALTSTATUS(0xff)
hde: QUANTUM FIREBALLP KX20.5, ATA DISK drive
hdf: probing with STATUS(0x00) instead of LATSTATUS(0xff)
hdf: probing with STATUS(0x00) instead of ALTSTATUS(0xff)
ide3: port already in use, skipping probe
it continues from here but all my ide values increased by one, i.e.
ide4=previous ide3.
I compiled a kernel *without* any HPT366 options selected and still when
i boot the kernel it still recognises my hpt366 controller, i initially
thought i must have still been using my old kernel, i dont get it.
It looks to the untrained eye (me) like the kernel is trying to use the
generic drivers and the HPT366 drives (even though i renamed hpt366.c to
hpt366.c.goaway)
Maybe im making stupid mistakes, i really dont know.
> > Both the onboard and PCI card HPT366 use the same interrupt for two
> > channels. I have interrupt shareing compiled into the kernel though,
>
> So this isn't a BP6 or other board with an on-mobo HPT366.
>
Yes, its a bp6 motherboard, with an abit hotrod pci card (has hpt366
chip).
The motherboard provides 2 Intel ide channels which use irq14+15 plus
two hpt366 channels which have both been using irq 16
The pci card provides another two hpt366 channels which both use irq 18
> Another hint: Fast EIDE is hard on cables. Keep them short
> and messy (don't block airflow). IIRC 14" is spec, but I often
> cut off the last connector. And never leave a dangling connector
> at the end but unused connector in the middle is OK. Always use
> a UDMA/66 cable if the card/socket expects one (HPT366 controller).
>
Ok, ive done this, i chopped all the ends of my cables, they are now all
about 30 cm (12"), I think it is working a bit better from doing this.
> Furthermore, for an EIDE disk farm I'd look into possibly
> resetting the interrupt priorities. Some old serial ports
> had trouble with too low a priority. That may be coming back
> for fast EIDE disks if the buffers/transfers are small (512-1024B)
> --
Hmmm, resetting the interupts doesnt look that easy, is what they refer
to in the kernel docs as irq affinity, this bit here ?
PCI->APIC IRQ transform: (B0,I11,P0) -> 18
PCI->APIC IRQ transform: (B0,I15,P0) -> 16
PCI->APIC IRQ transform: (B0,I15,P0) -> 16
PCI->APIC IRQ transform: (B0,I19,P0) -> 18
PCI->APIC IRQ transform: (B0,I19,P1) -> 18
I did try a few times to pass an interupt with my other boot parameters,
they wernt used.
I read that sharing interrupts does reduce performance, is it possible
to stop the channels sharing interrupts ?
How can i tell what interrupts i can use?
Lots of questions, all advice/opinions apreciated.
Thanks
Glenn McGrath
--
=- To unsubscribe, email [EMAIL PROTECTED] with the -=
=- body of "unsubscribe linux-abit". -=
