On Wed 23-04-14 11:17:50, Andrew Morton wrote:
> On Wed, 23 Apr 2014 13:08:47 +0200 Jan Kara wrote:
>
> > > If you want reliable crash logging then we need to be able to set a
> > > printk level mask per console and just set the serial console for
> > > "crit/err" and the queue console for the re
On Wed, 23 Apr 2014 23:41:59 +0200 (CEST)
Jiri Kosina wrote:
> On Wed, 23 Apr 2014, One Thousand Gnomes wrote:
>
> > Given this all only affects huge boxes and the only fix we have right
> > now is hideously ugly I'd rather it stayed in the vendor hacks to their
> > trees, until someone is ins
On Wed, 23 Apr 2014, One Thousand Gnomes wrote:
> Given this all only affects huge boxes and the only fix we have right
> now is hideously ugly I'd rather it stayed in the vendor hacks to their
> trees, until someone is inspired to sort it properly.
I have to say I am rather disappointed by thi
> The problem of course will be in sizing the driver's queue. Perhaps we
> can have a driver which uses a huge queue, temporarily use that driver
> during boot then switch over to a conventional console driver?
It depends how early in boot you are but this is true equally of kernel
threads and ot
On Wed, 23 Apr 2014 13:08:47 +0200 Jan Kara wrote:
> > If you want reliable crash logging then we need to be able to set a
> > printk level mask per console and just set the serial console for
> > "crit/err" and the queue console for the rest, with a 'cat
> > >/dev/ttywhatever' running if this fe
On Wed 23-04-14 13:35:44, One Thousand Gnomes wrote:
> > > It's not worth adding for upstream anyway - not in that form. If it just
> > > used schedule_work it would be way way cleaner anyway.
> > Alan, please stop complaining that the patches don't use schedule_work()
> > when you didn't bother
> > It's not worth adding for upstream anyway - not in that form. If it just
> > used schedule_work it would be way way cleaner anyway.
> Alan, please stop complaining that the patches don't use schedule_work()
> when you didn't bother to answer to me when I was explaining to you twice
> what is
On Tue 22-04-14 11:22:59, One Thousand Gnomes wrote:
> On Fri, 18 Apr 2014 11:54:38 -0700
> Andrew Morton wrote:
>
> > On Wed, 26 Mar 2014 20:28:15 +0100 Jan Kara wrote:
> >
> > > > All the afflicted consoles are serial, all go via the uart layer as far
> > > > as I can see.
> > > >
> > > > Th
On Fri 18-04-14 11:54:38, Andrew Morton wrote:
> On Wed, 26 Mar 2014 20:28:15 +0100 Jan Kara wrote:
>
> > > All the afflicted consoles are serial, all go via the uart layer as far
> > > as I can see.
> > >
> > > The uart layer has a queue mechanism that could be used
> > I'm sorry, I don't fol
On Fri, 18 Apr 2014 11:54:38 -0700
Andrew Morton wrote:
> On Wed, 26 Mar 2014 20:28:15 +0100 Jan Kara wrote:
>
> > > All the afflicted consoles are serial, all go via the uart layer as far
> > > as I can see.
> > >
> > > The uart layer has a queue mechanism that could be used
> > I'm sorry,
On Wed, 26 Mar 2014 20:28:15 +0100 Jan Kara wrote:
> > All the afflicted consoles are serial, all go via the uart layer as far
> > as I can see.
> >
> > The uart layer has a queue mechanism that could be used
> I'm sorry, I don't follow here - what can the uart queueing be used for?
Alan, I'm
On Wed 26-03-14 17:23:32, One Thousand Gnomes wrote:
> On Tue, 25 Mar 2014 18:55:01 +0100
> Jan Kara wrote:
>
> > Necessity for offloading of printing was observed only for large
> > systems. So add a config option (disabled by default) which removes most
> > of the overhead added by this functio
On Tue, 25 Mar 2014 18:55:01 +0100
Jan Kara wrote:
> Necessity for offloading of printing was observed only for large
> systems. So add a config option (disabled by default) which removes most
> of the overhead added by this functionality.
If its an option it'll not get used. It ought to be auto
13 matches
Mail list logo
