On Thu, 31 Jan 2013 13:14:05 +0530
anish singh wrote:
> > If it does need ratelimiting, I'd worry about using jiffies for that.
> > If the kernel is spending a long time with interrupts disabled, jiffies
> > might not be incrementing. Using the CPU timestamp would be better
> > (eg, sched_clock(
On Wed 30-01-13 16:08:27, Andrew Morton wrote:
> On Tue, 29 Jan 2013 15:54:24 +0100
> Jan Kara wrote:
>
> > > So I was testing the attached patch which does what we discussed. The
> > > bad
> > > news is I was able to trigger a situation (twice) when suddently sda
> > > disappeared and thus al
On Fri, Jan 18, 2013 at 3:09 AM, Andrew Morton
wrote:
> On Thu, 17 Jan 2013 22:04:42 +0100
> Jan Kara wrote:
>
>> ...
>>
>> So I played a bit with this. To make things easier for me I added
>> artificial mdelay(len*10) (effectively simulating console able to print 100
>> characters per second)
On Tue, 29 Jan 2013 15:54:24 +0100
Jan Kara wrote:
> > So I was testing the attached patch which does what we discussed. The bad
> > news is I was able to trigger a situation (twice) when suddently sda
> > disappeared and thus all IO requests failed with EIO. There is no trace of
> > what's hap
On Mon 21-01-13 22:00:08, Jan Kara wrote:
> On Thu 17-01-13 15:50:29, Andrew Morton wrote:
> > On Fri, 18 Jan 2013 00:46:14 +0100
> > Jan Kara wrote:
> >
> > > On Thu 17-01-13 13:39:17, Andrew Morton wrote:
> > > > On Thu, 17 Jan 2013 22:04:42 +0100
> > > > Jan Kara wrote:
> > > >
> > > > > ...
On Thu 17-01-13 15:50:29, Andrew Morton wrote:
> On Fri, 18 Jan 2013 00:46:14 +0100
> Jan Kara wrote:
>
> > On Thu 17-01-13 13:39:17, Andrew Morton wrote:
> > > On Thu, 17 Jan 2013 22:04:42 +0100
> > > Jan Kara wrote:
> > >
> > > > ...
> > > >
> > > > So I played a bit with this. To make thin
On Fri, 18 Jan 2013 00:46:14 +0100
Jan Kara wrote:
> On Thu 17-01-13 13:39:17, Andrew Morton wrote:
> > On Thu, 17 Jan 2013 22:04:42 +0100
> > Jan Kara wrote:
> >
> > > ...
> > >
> > > So I played a bit with this. To make things easier for me I added
> > > artificial mdelay(len*10) (effective
On Thu 17-01-13 13:39:17, Andrew Morton wrote:
> On Thu, 17 Jan 2013 22:04:42 +0100
> Jan Kara wrote:
>
> > ...
> >
> > So I played a bit with this. To make things easier for me I added
> > artificial mdelay(len*10) (effectively simulating console able to print 100
> > characters per second) ju
On Thu, 17 Jan 2013 22:04:42 +0100
Jan Kara wrote:
> ...
>
> So I played a bit with this. To make things easier for me I added
> artificial mdelay(len*10) (effectively simulating console able to print 100
> characters per second) just after call_console_drivers() so that I can
> trigger issues
On Wed 16-01-13 16:11:18, Andrew Morton wrote:
> On Thu, 17 Jan 2013 00:55:29 +0100
> Jan Kara wrote:
> > > If this is all a problem then the calling code should stop doing so
> > > much printing!
> > It's mostly a device discovery that triggers the issues in practice. They
> > have over thousan
On Thu, 17 Jan 2013 00:55:29 +0100
Jan Kara wrote:
> On Wed 16-01-13 14:50:05, Andrew Morton wrote:
> > > > > We fix the issue by printing at most 1 KB of messages (unless we are
> > > > > in an
> > > > > early boot stage or oops is happening) in one console_unlock() call.
> > > > > The rest
>
On Wed 16-01-13 14:50:05, Andrew Morton wrote:
> > > > We fix the issue by printing at most 1 KB of messages (unless we are in
> > > > an
> > > > early boot stage or oops is happening) in one console_unlock() call.
> > > > The rest
> > > > of the buffer will be printed either by further callers t
On Wed, 16 Jan 2013 11:16:44 +0100
Jan Kara wrote:
> On Tue 15-01-13 23:37:42, Andrew Morton wrote:
> > On Tue, 15 Jan 2013 18:58:34 +0100 Jan Kara wrote:
> >
> > > A CPU can be caught in console_unlock() for a long time (tens of seconds
> > > are
> > > reported by our customers) when other CP
On Tue 15-01-13 23:37:42, Andrew Morton wrote:
> On Tue, 15 Jan 2013 18:58:34 +0100 Jan Kara wrote:
>
> > A CPU can be caught in console_unlock() for a long time (tens of seconds are
> > reported by our customers) when other CPUs are using printk heavily and
> > serial
> > console makes printing
On Tue, 15 Jan 2013 18:58:34 +0100 Jan Kara wrote:
> A CPU can be caught in console_unlock() for a long time (tens of seconds are
> reported by our customers) when other CPUs are using printk heavily and serial
> console makes printing slow. This triggers softlockup warnings because
> interrupts
A CPU can be caught in console_unlock() for a long time (tens of seconds are
reported by our customers) when other CPUs are using printk heavily and serial
console makes printing slow. This triggers softlockup warnings because
interrupts are disabled for the whole time console_unlock() runs (e.g.
16 matches
Mail list logo
