On 01/26/2019 07:43 PM, Aaro Koskinen wrote:
> Hi,
>
> On Mon, Jan 14, 2019 at 02:16:42PM +0100, Bartlomiej Zolnierkiewicz wrote:
>> On 01/12/2019 04:26 PM, Aaro Koskinen wrote:
>>> Hi,
>>>
>>> On Sun, Jan 06, 2019 at 02:46:07PM +0200, Aaro Koskinen wrote:
>>>> Commit 7ff7a5b1bfff ("MIPS: lemote2f_defconfig: Convert to use libata
>>>> PATA drivers") switched from IDE to libata PATA on Loongson 2F, but
>>>> neither PATA_AMD or PATA_CS5536 work well on this platform compared
>>>> to the AMD74XX IDE driver.
>>
>> Sorry about that.
>>
>>>> During the ATA init/probe there is interrupt storm from irq 14, and
>>>> majority of system boots end up with "nobody cared... IRQ disabled".
>>>> So the result is a very slow disk access.
>>>>
>>>> It seems that the interrupt gets crazy after the port freeze done early
>>>> during the init, and for whatever reason it cannot be cleared.
>>>>
>>>> With the below workaround I was able to boot the system normally. I
>>>> guess that rather than going back to old IDE driver, we should just try
>>>> to make pata_cs5536 work (and forget PATA AMD on this board)...?
>>>
>>> Hmm, even with this hack I get ~500 spurious IRQs during the boot.
>>>
>>> Also compared to old IDE, there's 33 vs 100 speed difference:
>>>
>>> [ 3.324000] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x4ce0 irq 14
>>> [ 3.584000] ata1.00: ATA-8: WDC WD1600BEVS-00VAT0, 11.01A11, max UDMA/133
>>> [ 3.588000] ata1.00: 312581808 sectors, multi 16: LBA48
>>> [ 3.592000] ata1.00: limited to UDMA/33 due to 40-wire cable
>>>
>>> [ 4.540000] Probing IDE interface ide0...
>>> [ 4.992000] hda: WDC WD1600BEVS-00VAT0, ATA DISK drive
>>> [ 5.716000] hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4
>>> [ 5.716000] hda: UDMA/100 mode selected
>>
>> Can you try booting with "libata.force=1:80c" (and if that doesn't work with
>> "libata.force=1:short40c")
>
> (Sorry for delay, this machine is in use so I couldn't reboot it randomly...)
>
> OK, the speed issue can be fixed with command line. So "libata.force=1:80c"
> works with cs5536 libata driver.
>
>> and also provide full dmesg-s for working (ide) and not working
>> (libata) kernels.
>
> Logs are below:
>
> 1) working IDE (no spurious IRQs)
> 2) working PATA AMD (around ~90k spurious IRQs, so it's just a matter of luck)
> 3) failing PATA AMD (100k spurious IRQs reached)
> 4) working PATA CS5536 (same as with PATA AMD)
> 5) failing PATA CS5536 (same as with PATA AMD)
Thank you.
I've looked a bit more into the problem and came with two possible
approaches to investigate it further:
* The major difference between IDE and libata during probing is that
IDE keeps the port's IRQ (if known) disabled during whole probe time.
To replicate this behavior in libata it seems that we would need
to cache IRQ number used in ap->irq, then call disable_irq(ap->irq)
when ATA_PFLAG_LOADING flag is set and enable_irq(ap->irq) when
ATA_PFLAG_LOADING is cleared.
* The other idea is to try to modify your workaround patch to implement
dummy ->sff_set_devctl helper ("empty" one) instead of adding custom
version of ->freeze one.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
