Messages in this thread | | | Date | Tue, 14 Jun 2005 07:58:55 +0200 | From | Ingo Molnar <> | Subject | Re: network driver disabled interrupts in PREEMPT_RT |
| |
* Christoph Hellwig <hch@infradead.org> wrote:
> On Mon, Jun 13, 2005 at 08:56:42PM +0200, Ingo Molnar wrote: > > > > * Kristian Benoit <kbenoit@opersys.com> wrote: > > > > > Hi, > > > I got lots of these messages when accessing the net running > > > 2.6.12-rc6-RT-V0.7.48-25 : > > > > > > "network driver disabled interrupts: tg3_start_xmit+0x0/0x629 [tg3]" > > > > > > it seem to come from net/sched/sch_generic.c. > > > > does the patch below fix it? > > Wouldn't it be much more useful to add spin_trylock_irq?
you are right, a spin_trylock_irqsave() call would be much cleaner.
i think i should explain why you are seeing such hacks in the PREEMPT_RT patch: generally we are trying to achieve near-100% driver API compatibility (that of course is also one of the requirements for any of this to hit mainline), so i'm marking any deviations with _nort or _rt postfixes (depending on where the change in semantics is needed). I consider them temporary hacks, so i'm usually trying to keep the original form of the code, so that i can go back later and fix it.
I had these hacks in tg3.c for some time, and i thought i could drop them now that local_irq_*() uses the soft IRQ-flag - but i was wrong. One example of the _rt/_nort marking process is e.g. the earlier RCU API related grossness, which went away with Paul's PREEMPT_RCU aproach and now PREEMPT_RT is fully compatible with the RCU API. Fortunately, assymetric local_irq_* + spin_lock_* uses (which are perfectly legal!) are relatively rare. Extending the spinlock APIs and converting all upstream code would be a good approach to solve this problem, as it's also a cleanup. (It would probably also make static lock analysis easier.)
Ingo - 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/
| |