On Wed, 30 Jan 2008 11:29:59 +0100 michael <[EMAIL PROTECTED]> wrote: > > Now, _that_ is strange. I can't see anything that needs protection > > across that call; in fact, I think we can lock a lot less than what we > > currently do. > > > > > I explain it bad: > - with spin_lock the system seems, there is no problem with Valuntary > Preeption and > Preemptible Kernel > - with full preemption it runs but the serial line can't be used for > receiving at > high bit rate (using lrz)
...but if you drop the spinlock across the call to tty_flip_buffer_push, you get an Oops? Could you post the Oops? > >> Complete Preemption (Real-Time) ok but the serials is just unusable due > >> to too many overruns (just using lrz) > >> > > > > Is it worse than before? IIRC Remy mentioned something about > > IRQF_NODELAY being the reason for moving all this code to softirq > > context in the first place; does the interrupt handler run in hardirq > > context? > > > > > In the complete preemption yes. Which question did you answer "yes" to? That it's worse than before or that the interrupt handler runs in hardirq context (i.e. IRQF_NODELAY)? > > I think you're right. Can you change it and see if it helps? > > > > > I just change it because I have corruption on receiving buffer. All > my test are done with this fix Ok. > > I guess I didn't test it thoroughly enough with DMA > > disabled...slub_debug ought to catch such things, but not until we > > receive enough data to actually overflow the buffer. > > > > > I just test it I don't have > buffer overflow. No, I'd expect your allocation fix to take care of that. Or did you by any chance test without the fix and with slub_debug enabled? > I protect with a spinlock the access to the register when we sending > from the tasklet. It is correct? I have no idea. Could you post some more specifics about what you modified, for example a diff? Most of the tasklet is already protected by the spinlock, so you must be careful to avoid any lock recursion. Haavard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
