Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

[Martin Dalecki <dalecki@evision-ventures.com>]

Jeff Garzik wrote:
> Martin Dalecki wrote:
> 
>> John Langford wrote:
>>
>>> I went nuts with printk statements and managed to isolate the hang to
>>> one particular line of code.  The final printk in this code fragment
>>> never gets executed.                 } else if (m5229_revision >= 
>>> 0xC3) {
>>>                 /*
>>>                          * 1553/1535 (m1533, 0x79, bit 1)
>>>                          */
>>>                         printk("ata66_ali15x3           } else if 
>>> (m5229_revisi\on >= 0xC3) {\n");
>>>                         pci_write_config_byte(isa_dev, 0x79, tmpbyte 
>>> | 0x02);
>>
>>
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
>>
>>
>> pci_write_config to isa_dev???? This looks at least suspicious.
>> You may very well check whatever isa_dev is trully a PCI device
>> handle or just some random IO base for ISA bus!
> 
> 
> 
> Nope, look at the code and comments around "isa_dev"   :)

OK OK - this was just a blind guess without looking at the actual
code :-).

> isa_dev is the PCI device structure for the ALi ISA bridge... very 
> definitely a PCI device.

Sure i know.

> some background:
> It is normal in some situations that you need to examine or set PCI 
> config registers for the ISA bridge, when dealing with some IDE 
> motherboards.  The southbridge is typically the chip that actually 
> implements IDE on your motherboard.  Even though IDE is normally 
> exported as a separate PCI device, you still have to deal with the ATA 
> register blocks at hardcoded legacy ISA addresses 0x1f0 and 0x170.  So, 
> when you write the ATA registers for channel 0 or channel 1, you are 
> writing to 0x1f? or 0x17?, the ISA bridge is most likely the portion of 
> the southbridge chip actually decoding those addresses for you.

Thank you for elaborating on this, but I did already know this...