lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 17 Feb 2019 22:37:03 -0300
From:   Alexandre Oliva <lxoliva@...la.org>
To:     Aaro Koskinen <aaro.koskinen@....fi>
Cc:     Tom Li <tomli@...li.me>, James Hogan <jhogan@...nel.org>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Huacai Chen <chenhc@...ote.com>,
        Ralf Baechle <ralf@...ux-mips.org>, linux-mips@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers

On Feb 17, 2019, Aaro Koskinen <aaro.koskinen@....fi> wrote:

> I tested few older kernels, and it seems that the spurious IRQ issue has
> been always there after switching to libata (commit 7ff7a5b1bfff). It has
> been unnoticed as the 100000 irq limit wasn't reached during boot.

I see, thanks.  That would probably make it hard to bisect indeed.

>> The kernel still disables irq14 early on, and then runs slow.

> This hack works only for CONFIG_PATA_CS5536. You are probably using PATA_AMD.

That's a reasonable guess, but I don't think so.  I do have PATA_AMD
enabled as a module indeed, but it's not even loaded, much as I can
tell, whereas PATA_CS5536 is built into the kernel image, and dmesg
says:

[    4.460000] scsi host0: pata_cs5536
[    4.464000] scsi host1: pata_cs5536
[    4.464000] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x4c60 irq 14
[    4.464000] ata2: DUMMY
[    4.464000] pcnet32: [...]
[    4.644000] random: [...]
[    5.908000] irq 14: nobody cared (try booting with the "irqpoll" option)


Just to be sure, I added some printks to cs5536_noop_freeze, and here's
what I got in dmesg instead:

[    4.452000] pata_cs5536: freeze: checking status...
[    4.452000] pata_cs5536: freeze: checked, clearing...
[    4.452000] pata_cs5536: freeze: cleared
[    4.460000] scsi host0: pata_cs5536
[    4.464000] scsi host1: pata_cs5536
[    4.464000] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x4c60 irq 14
[    4.464000] ata2: DUMMY
[    4.464000] pcnet32: [...]
[    4.468000] pata_cs5536: freeze: checking status...
[    4.468000] pata_cs5536: freeze: checked, clearing...
[    4.468000] pata_cs5536: freeze: cleared
[    4.652000] random: [...]
[    5.920000] irq 14: nobody cared (try booting with the "irqpoll" option)

now, maybe I just don't understand what effects the patch was supposed
to have.

The system still feels very slow, but I haven't timed anything; could it
be that it had the effect of keeping the IRQ functional after all, but
5.0-rc6 is slower than earlier kernels for other reasons?  Like,
/proc/irq/14/pata_cs5536/ is there, but I haven't checked whether it was
there before the patch.

Do you suggest any way to tell whether it had the intended effect?

-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free!         FSF Latin America board member
GNU Toolchain Engineer                Free Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ