Messages in this thread | | | Date | Fri, 12 May 2006 07:59:01 -0400 | From | Mark Hounschell <> | Subject | Re: [RFC][PATCH -rt] irqd starvation on SMP by a single process? |
| |
Ingo Molnar wrote: > * Mark Hounschell <markh@compro.net> wrote: > >> Steven Rostedt wrote: >>> On Fri, 12 May 2006, Ingo Molnar wrote: >>> >>>> ah. This actually uncovered a real bug. We were calling __do_softirq() >>>> with interrupts enabled (and being preemptible) - which is certainly >>>> bad. >>> Hmm, I wonder if this is also affecting Mark's problem. >> I thought the same thing when I read it?? > > could you try the patch below? > > Ingo > > ---- > > * Steven Rostedt <rostedt@goodmis.org> wrote: > >>> one solution would be to forbid disable_irq() from softirq contexts, and >>> to convert the vortex timeout function to a workqueue and use the >>> *_delayed_work() APIs to drive it - and cross fingers there's not many >>> places to fix. >> I prefer the above. Maybe even add a WARN_ON(in_softirq()) in >> disable_irq. >> >> But I must admit, I wouldn't know how to make that change without >> spending more time on it then I have for this. > > the simplest fix for now would be to use the _nosync variant in the > vortex timeout function. > > Mark, does this fix the problem? > > Ingo > > Index: linux-rt.q/drivers/net/3c59x.c > =================================================================== > --- linux-rt.q.orig/drivers/net/3c59x.c > +++ linux-rt.q/drivers/net/3c59x.c > @@ -1897,7 +1897,8 @@ vortex_timer(unsigned long data) > > if (vp->medialock) > goto leave_media_alone; > - disable_irq(dev->irq); > + /* hack! */ > + disable_irq_nosync(dev->irq); > old_window = ioread16(ioaddr + EL3_CMD) >> 13; > EL3WINDOW(4); > media_status = ioread16(ioaddr + Wn4_Media); >
I'm trying that right this moment. It may take a while before I know if it helps.
Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |