On Thu 19-09-13 14:26:27, Andrew Morton wrote:
> On Thu, 5 Sep 2013 17:46:12 +0200 Jan Kara wrote:
> > On Fri 23-08-13 12:58:22, Andrew Morton wrote:
> > > On Fri, 23 Aug 2013 21:48:36 +0200 (CEST) Jiri Kosina
> > > wrote:
> > >
> > > > > > We have customers (quite a few of them actually) whi
On Thu, 5 Sep 2013 17:46:12 +0200 Jan Kara wrote:
> Sorry for a delayed reply. I was on vacation...
>
> On Fri 23-08-13 12:58:22, Andrew Morton wrote:
> > On Fri, 23 Aug 2013 21:48:36 +0200 (CEST) Jiri Kosina
> > wrote:
> >
> > > > > We have customers (quite a few of them actually) which
Sorry for a delayed reply. I was on vacation...
On Fri 23-08-13 12:58:22, Andrew Morton wrote:
> On Fri, 23 Aug 2013 21:48:36 +0200 (CEST) Jiri Kosina wrote:
>
> > > > We have customers (quite a few of them actually) which have machines
> > > > with
> > > > lots of SCSI disks attached (due
On Fri, 23 Aug 2013, Andrew Morton wrote:
> > > > We have customers (quite a few of them actually) which have machines
> > > > with
> > > > lots of SCSI disks attached (due to multipath etc.) and during boot when
> > > > these disks are discovered and partitions set up quite some printing
> > >
On Fri, 23 Aug 2013 21:48:36 +0200 (CEST) Jiri Kosina wrote:
> > > We have customers (quite a few of them actually) which have machines
> > > with
> > > lots of SCSI disks attached (due to multipath etc.) and during boot when
> > > these disks are discovered and partitions set up quite some pr
On Thu, 22 Aug 2013, Andrew Morton wrote:
> Years of hard experience have taught me: don't muck with printk. It
> needs to be robust, simple and to have minimum dependency on both the
> calling environment and on correctly functioning kernel components.
> printk and NMI are the harshest environm
On Thu, 22 Aug 2013, Andrew Morton wrote:
> > We have customers (quite a few of them actually) which have machines with
> > lots of SCSI disks attached (due to multipath etc.) and during boot when
> > these disks are discovered and partitions set up quite some printing
> > happens - multiplied b
On Thu, 22 Aug 2013 23:57:42 +0200 Jan Kara wrote:
> On Thu 22-08-13 12:49:13, Andrew Morton wrote:
> > Desperately seeking alternatives...
> >
> > I suppose there's some reason why we can't just make those drivers shut
> > up? If the messages are in the log buffer but aren't displayed,
> > the
On Thu 22-08-13 12:49:13, Andrew Morton wrote:
> On Thu, 22 Aug 2013 00:59:15 +0200 Jan Kara wrote:
>
> > On Wed 21-08-13 14:27:23, Andrew Morton wrote:
> > > On Wed, 21 Aug 2013 10:08:28 +0200 Jan Kara wrote:
> > >
> > > > These patches avoid softlockups when a CPU gets caught in
> > > > cons
On Thu, 22 Aug 2013 00:59:15 +0200 Jan Kara wrote:
> On Wed 21-08-13 14:27:23, Andrew Morton wrote:
> > On Wed, 21 Aug 2013 10:08:28 +0200 Jan Kara wrote:
> >
> > > These patches avoid softlockups when a CPU gets caught in
> > > console_unlock() for
> > > a long time during heavy printing from
On Wed 21-08-13 14:27:23, Andrew Morton wrote:
> On Wed, 21 Aug 2013 10:08:28 +0200 Jan Kara wrote:
>
> > These patches avoid softlockups when a CPU gets caught in console_unlock()
> > for
> > a long time during heavy printing from other CPU. As is discussed in patch
> > 3/4
> > it isn't enough
On Wed, 21 Aug 2013 10:08:28 +0200 Jan Kara wrote:
> These patches avoid softlockups when a CPU gets caught in console_unlock() for
> a long time during heavy printing from other CPU. As is discussed in patch 3/4
> it isn't enough to just silence the watchdog because if CPU spends too long in
> c
12 matches
Mail list logo
