linux-kernel - v2.6.34: IDE on IRQ15 starving Serial on IRQ10, not on v2.4

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <4CBEC1F4.9080700@sadel.it>
Date:	Wed, 20 Oct 2010 12:18:28 +0200
From:	Matteo Fortini <matteo.fortini@...el.it>
To:	linux-kernel@...r.kernel.org
Subject: v2.6.34: IDE on IRQ15 starving Serial on IRQ10, not on v2.4

Hi,
we were having serial buffer overruns on a 4800bps 16550A with a Geode 
GX1 SBC,
the serial port is on IRQ10, so it should have higher priority than IDE 
(which is on IRQ15).

The PIC is in XT-PIC-XT mode, we have no APIC unfortunately.

The overruns are triggered easily with a dd if=/dev/hda of=/dev/null

IDE is a CF card using PIO mode 4, no DMA enabled.

We tried various build options, like preemption etc., and we tried both 
ide and libata.

We traced this down to the fact that the IDE subsystem is keeping the 
serial IRQ pending for the whole max request time, which is 256 requests 
in our current setup.

We fixed it by changing the value at drivers/ide/ide-probe.c:751 from 
256 to e.g. 32, which gave the IDE disk less time to keep the others 
pending, but we feel this could be some other issue.

The unmaskirq option as in hdparm -u1 /dev/hda was not fixing the 
problem, and changing the transfer mode to 32bit w/sync didn't either.

The strange thing is that the behavior is completely different in Linux 
2.4.x: we can see with a scope that the IDE request is continuously 
interrupted by the serial port, which should be the default with the 
8259 PIC.

Thank you,
Matteo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/