Devices connected to a JMicron PATA controller are not detected.

[bga]

My computer has a JMicron controller that has SATA/PATA ports. I have one SATA HD connected to one of the SATA ports and a 500 GH HD and a DVD-RW drive connected to the PATA port. The SATA HD is detected and works well but the devices connected to the PATA controller are not. For example, when trying to boot Haiku from the PATA HD, it starts booting and then fails because it can not find the boot device. When booting it from the SATA HD, I noticed this in the syslog:

KERN: [34mahci:[0m ahci_scan_bus, cookie 0x9100ce40 KERN: [34mahci:[0m no device present on port 0 Last message repeated 1 time KERN: [34mahci:[0m no device present on port 1 Last message repeated 1 time

These messages probably refer to the PATA controller (only 2 ports) but although it does not find devices, there *ARE* devices attached (and they work under Windows and under Linux).

Full syslog attached.

[bga]

Syslog output

[bga]

Some things I noticed that may or may not be usefull:

1 - My BIOS has an option to configure PATA devices as AHCI or IDE. Either option results in exactly the same problem.

2 - Linux always configures the devices as AHCI, it seems (they show up as sdX devices).

3 - Dunno if it matter but both devices jumpers are set to cable select, which means there is no explicitly configured master/slave.

4 - Even if I disconnect the IDE HD, the DVD drive is still not detected. Didn't try disconnecting only the DVD drive.

[bga]

With Marcus help, it became obviously that the problem was a result of bug #5 and happened like this:

1 - The BIOS had PNP OS enabled so it would not try to configure the devices leaving it to the OS to do that. 2 - The JMicron controller reported itself as 2 different devices but one of them had no interrupt line assigned to it. 3 - So the IDE stack would load, find the PATA controller but fail to work with it as it had no IRQ assigned.

I changed my BIOS settings so the PNP OS option is now disabled (which means that the BIOS itself would configure the devices) and this resulted in better results (I am at work now, will post the syslog when I am back at home later today):

1 - The controller gets an IRQ. 2 - It seems to be correctly initialized and the attached drives (a DVR-RW drive and an HD) are detected and identified as an atapi and an ata device. 3 - But then send_command() fails on both devices and they are ignored.

A side effect of whatever happens is that the HD light in the tower case keeps lit up all the time but the devices are not published to /dev/disk.

Ideas?

[bga]

Working on it...

[bga]

As of hrev26844, the PATA controller works and devices are detected as long as it is configured in IDE MODE. Moving this ticket back to Marcus as I don't know when I will have time to look at it again and, more than that, I have no documentation for the JMicron controllers.

[bga]

Marcus, just as a refernce, Linux does the following when this controller is found:

pci_read_config_dword(pdev, 0x40, &conf1);

/* Enable dual function mode, AHCI on fn 0, IDE fn1 */ /* Set the class codes correctly and then direct IDE 0 */ conf1 |= 0x00C2A1B3; /* Set 0, 1, 4, 5, 7, 8, 13, 15, 17, 22, 23 */

pci_write_config_dword(pdev, 0x40, conf1);

/* Update pdev accordingly */ pci_read_config_byte(pdev, PCI_HEADER_TYPE, &hdr); pdev->hdr_type = hdr & 0x7f; pdev->multifunction = !!(hdr & 0x80);

pci_read_config_dword(pdev, PCI_CLASS_REVISION, &class); pdev->class = class >> 8;

What you did originally in the code was pretty similar to this but it seme sthe mask you used was different from the one Linux uses for updating the device configuration and, also, there ios the class updating that you did not do. I tried using the same mask as in Linux but it did not work (although without updating the class).

What is more interesting is that it seems linux does that without checking the mode the controller is in, which leads me to believe that it simply ignores the BIOS set mode and force it to be the mixed SATA/PATA mode always. Maybe we should do the same?

[bga]

Fixed in hrev26902.