* Pavel Machek ([EMAIL PROTECTED]) wrote:
> Hi!
>
> > > > It seems draconian to drain the entire buffer with ints disabled.
> > > > Is it possible to break this up and send out smaller chunks
> > > > at a time? Maybe by putting a chunk loop in release_console_sem()?
> > >
> > > Well, I believe s
Hi!
> > > It seems draconian to drain the entire buffer with ints disabled.
> > > Is it possible to break this up and send out smaller chunks
> > > at a time? Maybe by putting a chunk loop in release_console_sem()?
> >
> > Well, I believe someone got
> >
> > DDetetccctted ed 113223 HHzz CPUCPU
* Pavel Machek ([EMAIL PROTECTED]) wrote:
> Hi!
>
> > > Hmm, I see this at the beginning of the post-BK era (2.6.12-rc2):
> > >
> > > spin_lock_irqsave(&logbuf_lock, flags);
> > > ...
> > > spin_unlock(&logbuf_lock);
> > > call_console_drivers(_con_start, _
Hi!
> > Hmm, I see this at the beginning of the post-BK era (2.6.12-rc2):
> >
> > spin_lock_irqsave(&logbuf_lock, flags);
> > ...
> > spin_unlock(&logbuf_lock);
> > call_console_drivers(_con_start, _log_end);
> > local_irq_restore(flags)
On Fri, Oct 26, 2007 at 02:57:18PM +0200, Benny Amorsen wrote:
> > "MM" == Matt Mackall <[EMAIL PROTECTED]> writes:
>
> MM> Well there are things we can do, yes, but I'd be worried that
> MM> they've give up the deterministic behavior we rely on quite
> MM> heavily for debugging. If event A ha
> "MM" == Matt Mackall <[EMAIL PROTECTED]> writes:
MM> Well there are things we can do, yes, but I'd be worried that
MM> they've give up the deterministic behavior we rely on quite
MM> heavily for debugging. If event A happens before event B, we must
MM> see the message from A before the one f
On Thu, Oct 25, 2007 at 04:41:55PM -0700, Tim Bird wrote:
> Matt Mackall wrote:
> > On Thu, Oct 25, 2007 at 03:52:28PM -0700, Tim Bird wrote:
> >> Mathieu Desnoyers wrote:
> >>> It might help to read this thread I posted on LKML in January 2006
> >>> explaining the problem, which led to some discus
Matt Mackall wrote:
> On Thu, Oct 25, 2007 at 03:52:28PM -0700, Tim Bird wrote:
>> Mathieu Desnoyers wrote:
>>> It might help to read this thread I posted on LKML in January 2006
>>> explaining the problem, which led to some discussion about the issue.
>>>
>>> http://lkml.org/lkml/2006/6/3/48
>> Th
On Thu, Oct 25, 2007 at 03:52:28PM -0700, Tim Bird wrote:
> Mathieu Desnoyers wrote:
> > It might help to read this thread I posted on LKML in January 2006
> > explaining the problem, which led to some discussion about the issue.
> >
> > http://lkml.org/lkml/2006/6/3/48
>
> This is very helpful.
Mathieu Desnoyers wrote:
> It might help to read this thread I posted on LKML in January 2006
> explaining the problem, which led to some discussion about the issue.
>
> http://lkml.org/lkml/2006/6/3/48
This is very helpful. Jon Smirl's answer seems to give the
rationale for supporting printk ou
* Tim Bird ([EMAIL PROTECTED]) wrote:
> I've been looking at 'IRQ off' latency in the Linux kernel, on
> version 2.6.22 for target using an ARM processor.
> I use a serial console, at 115200 bps.
>
> I've noticed that calls to printk disable interrupts for
> excessively long times. I have a long
Matt Mackall wrote:
> On Thu, Oct 25, 2007 at 12:44:31PM -0700, Tim Bird wrote:
>> I've been looking at 'IRQ off' latency in the Linux kernel, on
>> version 2.6.22 for target using an ARM processor.
>> I use a serial console, at 115200 bps.
>
> Printk to the serial console uses polled I/O to get d
On Thu, Oct 25, 2007 at 12:44:31PM -0700, Tim Bird wrote:
> I've been looking at 'IRQ off' latency in the Linux kernel, on
> version 2.6.22 for target using an ARM processor.
> I use a serial console, at 115200 bps.
Printk to the serial console uses polled I/O to get deterministic,
reliable, and -
13 matches
Mail list logo
