#13620: Strange/wrong channel attachment by generic ATA with more than one
IDE/ATA
controller
--------------------------------+----------------------------
Reporter: Alexco | Owner: nobody
Type: bug | Status: new
Priority: normal | Milestone: Unscheduled
Component: Drivers/Disk/ATA | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 1 | Platform: All
--------------------------------+----------------------------
Comment (by Alexco):
The reason for this behaviour lies in the implementation of
ata_adapter.cpp and generic_ide_pci.cpp. Every IDE controller which is
handled by generic_ide_pci is configured with "compatibility" mode set to
true:
generic_ide_pci.cpp:
{{{
static status_t
probe_controller(device_node *parent)
{
return sATAAdapter->probe_controller(parent,
GENERIC_IDE_PCI_CONTROLLER_MODULE_NAME, "generic_ide_pci",
"Generic IDE PCI Controller",
GENERIC_IDE_PCI_CHANNEL_MODULE_NAME,
true,
true, // assume that
command queuing works
1, // assume
16 bit alignment is enough
0xffff, // boundary is on
64k according to spec
0x10000, // up to 64k per
S/G block according to spec
true); // by default,
compatibility mode is used
}
}}}
This forces fixed addresses for IDE channels:
ata_adapter.cpp:
{{{
if (supports_compatibility_mode
&& channel_index == 0 && (api & PCI_ide_primary_native) ==
0) {
command_block_base = 0x1f0;
control_block_base = 0x3f6;
intnum = 14;
TRACE("PCI-ATA: Controller in legacy mode: cmd %#x, ctrl
%#x, irq %d\n",
command_block_base, control_block_base, intnum);
} else if (supports_compatibility_mode
&& channel_index == 1 && (api & PCI_ide_secondary_native)
== 0) {
command_block_base = 0x170;
control_block_base = 0x376;
intnum = 15;
TRACE("PCI-ATA: Controller in legacy mode: cmd %#x, ctrl
%#x, irq %d\n",
command_block_base, control_block_base, intnum);
}
}}}
If a system is equipped with additional IDE controllers (compared to the
chipset one, which is configured by BIOS), these are of course then
configured to use different command & control block bases and interrupts.
What happens now is that during driver/PCI device enumeration the
additional controller is enumerated first, with the chipset controller
beeing second. The additional controller then creates the IDE channels and
configures these in compatibility mode with the command & control block
bases and interrupts of the chipset controller.
This results in
1. strange/wrong channel attachments (this ticket)
2. not working DMA, since the wrong controller is used (#12292)
Since not much systems feature more than one IDE controller I would
propose not to change the current implementation but to provide additional
IDE controller drivers on a case-by-case basis (in my case I wrote a
Highpoint driver which initialises all channels correctly, so I was able
to verify the dependency of non-working DMA).
But I have no idea if a similar issue exists for modern SATA controllers.
--
Ticket URL: <https://dev.haiku-os.org/ticket/13620#comment:3>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
