Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q1

Fernando Pablo Lopez-Lezcano
2004-08-30T01:07:17Z

On Sat, 2004-08-28 at 06:01, Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
>
> > * Scott Wood <scott@timesys.com> wrote:
> >
> > > If I'm missing something, please let me know, but I don't see a good
> > > way to implement it without blocking for the IRQ thread's completion
> > > (such as with the per-IRQ waitqueues in M5).
> >
> > agreed, this is a hole in generic_synchronize_irq(). I've added
> > handler-completion waitqueues to my current tree, it will show up in
> > -Q1.
>
> i've uploaded -Q1:
>
> http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q1
>
> as with -Q0, the following patch has to be applied to 2.6.8.1 first:
>
> http://redhat.com/~mingo/voluntary-preempt/diff-bk-040828-2.6.8.1.bz2
>
> those who still have DRI problems under -Q1 - please unapply the
> drm_os_linux.h change, does the fix the lockups?

I managed to do a few quick tests yesterday of voluntary Q3:

SMP kernel on UP machine (Athlon64): hangs during boot, goes a little
further than before but hangs anyway:

requesting new irq thread for IRQ169
ata1: dev 0 ATA, max UDMA/133 ...
IRQ#169 thread started up
ata1: dev 0 configured for UDMA/133 ...
scsi0: sata_promise
ata2: dev 0 ATA ...
--- hangs ---

SMP kernel on SMP machine (dual Athlon):
softirq-preempt=0 hardirq-preempt=0 acpi=on: hangs
afaik hang happens when something needs interrupts, first culprit in
my machine is eth0, if I disable it I can go further ahead and boot
but alsa has timeouts, presumably because it is not getting
interrupts.
softirq-preempt=0 hardirq-preempt=0 acpi=off: boots normally,
jack, glxgears work fine (but high latency spikes)
softirq-preempt=1 hardirq-preempt=1 acpi=off: boots normally,
jack works fine, glxgears hangs machine after a while
Sorry I was not able to check all permutations, I was late and stopped
rebooting the machine :-) I think I did one more test with sort=1,
hard=1, acpi=off and did not manage to hang the machine.

-- Fernando