On Tue, Mar 04, 2014 at 10:54:04AM +0200, Leon Pollak wrote:
> I will recheck everything and try. Meanwhile, the news are not good: our
> guys say that it appears that the additional sync DOES NOT SOLVE the
> issue.
Gonna be honest, I have a tough time explaining this. :( Unfortunately
I don't
Hello, all.
I am really sorry for the silence - I was on the business trip and
returned today.
I will recheck everything and try. Meanwhile, the news are not good: our
guys say that it appears that the additional sync DOES NOT SOLVE the
issue.
I ask for excuse, but as I did not know the exact
On Mon, Mar 03, 2014 at 03:13:36PM -0600, Andrew Ruder wrote:
> On Thu, Feb 27, 2014 at 01:22:08PM -0800, Brian Norris wrote:
> > Perhaps Richard or Andrew can comment on whether this patch should help
> > you. But I think JFFS2 on NAND uses write-buffered support which can be
> > affected by this
On Mon, Mar 03, 2014 at 03:13:36PM -0600, Andrew Ruder wrote:
On Thu, Feb 27, 2014 at 01:22:08PM -0800, Brian Norris wrote:
Perhaps Richard or Andrew can comment on whether this patch should help
you. But I think JFFS2 on NAND uses write-buffered support which can be
affected by this bug.
Hello, all.
I am really sorry for the silence - I was on the business trip and
returned today.
I will recheck everything and try. Meanwhile, the news are not good: our
guys say that it appears that the additional sync DOES NOT SOLVE the
issue.
I ask for excuse, but as I did not know the exact
On Tue, Mar 04, 2014 at 10:54:04AM +0200, Leon Pollak wrote:
I will recheck everything and try. Meanwhile, the news are not good: our
guys say that it appears that the additional sync DOES NOT SOLVE the
issue.
Gonna be honest, I have a tough time explaining this. :( Unfortunately
I don't
On Thu, Feb 27, 2014 at 01:22:08PM -0800, Brian Norris wrote:
> Perhaps Richard or Andrew can comment on whether this patch should help
> you. But I think JFFS2 on NAND uses write-buffered support which can be
> affected by this bug.
Definitely sounds like the same issue and I'm kind of glad to
On Thu, Feb 27, 2014 at 01:22:08PM -0800, Brian Norris wrote:
Perhaps Richard or Andrew can comment on whether this patch should help
you. But I think JFFS2 on NAND uses write-buffered support which can be
affected by this bug.
Definitely sounds like the same issue and I'm kind of glad to see
+ others
Hi Leon,
Can you please keep the CC list intact? And please try to reply below
the quotes and trim context, rather than top-posting. Thanks!
On Thu, Feb 27, 2014 at 02:00:25PM +0200, Leon Pollak wrote:
> I am VERY(!) thankful to you for the answer.
> First, I am calm now that there is
+ others
Hi Leon,
Can you please keep the CC list intact? And please try to reply below
the quotes and trim context, rather than top-posting. Thanks!
On Thu, Feb 27, 2014 at 02:00:25PM +0200, Leon Pollak wrote:
I am VERY(!) thankful to you for the answer.
First, I am calm now that there is no
* H. Peter Anvin wrote:
> On 08/12/2013 07:31 AM, Peter Zijlstra wrote:
> > On Wed, Aug 07, 2013 at 07:20:44PM +0200, Borislav Petkov wrote:
> >> Besides, BUG can be disabled in CONFIG_EXPERT.
> >
> > There was some email on this subject a while ago; disabling BUG() is
> > very risky and can
On 08/12/2013 07:31 AM, Peter Zijlstra wrote:
> On Wed, Aug 07, 2013 at 07:20:44PM +0200, Borislav Petkov wrote:
>> Besides, BUG can be disabled in CONFIG_EXPERT.
>
> There was some email on this subject a while ago; disabling BUG() is
> very risky and can cause all kinds of horrid. IIRC the
On Wed, Aug 07, 2013 at 07:20:44PM +0200, Borislav Petkov wrote:
> Besides, BUG can be disabled in CONFIG_EXPERT.
There was some email on this subject a while ago; disabling BUG() is
very risky and can cause all kinds of horrid. IIRC the consensus back
then was to remove this 'feature' and have
On Wed, Aug 07, 2013 at 07:20:44PM +0200, Borislav Petkov wrote:
Besides, BUG can be disabled in CONFIG_EXPERT.
There was some email on this subject a while ago; disabling BUG() is
very risky and can cause all kinds of horrid. IIRC the consensus back
then was to remove this 'feature' and have
On 08/12/2013 07:31 AM, Peter Zijlstra wrote:
On Wed, Aug 07, 2013 at 07:20:44PM +0200, Borislav Petkov wrote:
Besides, BUG can be disabled in CONFIG_EXPERT.
There was some email on this subject a while ago; disabling BUG() is
very risky and can cause all kinds of horrid. IIRC the consensus
* H. Peter Anvin h...@zytor.com wrote:
On 08/12/2013 07:31 AM, Peter Zijlstra wrote:
On Wed, Aug 07, 2013 at 07:20:44PM +0200, Borislav Petkov wrote:
Besides, BUG can be disabled in CONFIG_EXPERT.
There was some email on this subject a while ago; disabling BUG() is
very risky and
On 08/07/2013 11:41 AM, Borislav Petkov wrote:
> On Wed, Aug 07, 2013 at 10:51:43AM -0700, H. Peter Anvin wrote:
>> A bigger issue is probably if panic-on-bug should be the default, with
>> !panic being an opt-in debugging option.
>
> Yes, it might make sense although embedded wants to disable
On Wed, Aug 07, 2013 at 10:51:43AM -0700, H. Peter Anvin wrote:
> A bigger issue is probably if panic-on-bug should be the default, with
> !panic being an opt-in debugging option.
Yes, it might make sense although embedded wants to disable CONFIG_BUG
on systems which cannot report errors:
│
On 08/07/2013 10:46 AM, Steven Rostedt wrote:
> On Wed, 2013-08-07 at 19:37 +0200, Borislav Petkov wrote:
>> On Wed, Aug 07, 2013 at 01:33:06PM -0400, Steven Rostedt wrote:
>>> Right, and this code keeps the same logic as it was before. If it was
>>> disabled by CONFIG_EXPERT, it stays disabled,
On Wed, 2013-08-07 at 19:37 +0200, Borislav Petkov wrote:
> On Wed, Aug 07, 2013 at 01:33:06PM -0400, Steven Rostedt wrote:
> > Right, and this code keeps the same logic as it was before. If it was
> > disabled by CONFIG_EXPERT, it stays disabled, but at least you get to
> > see a warning that
On Wed, Aug 07, 2013 at 01:33:06PM -0400, Steven Rostedt wrote:
> Right, and this code keeps the same logic as it was before. If it was
> disabled by CONFIG_EXPERT, it stays disabled, but at least you get to
> see a warning that your kernel may be corrupt now :-)
Don't we really want to panic
On Wed, 2013-08-07 at 19:20 +0200, Borislav Petkov wrote:
>
> > +static void bug_at(unsigned char *ip, int line)
> > +{
> > + /*
> > +* The location is not an op that we were expecting.
> > +* Something went wrong. Crash the box, as something could be
> > +* corrupting the kernel.
On Wed, Aug 07, 2013 at 12:49:38PM -0400, Steven Rostedt wrote:
> From: Steven Rostedt
>
> When modifying text sections for jump labels, a paranoid check is
> performed. If the check fails, the system "bugs". But why it failed
> is not shown.
>
> The BUG_ON()s in the jump label update code is
From: Steven Rostedt
When modifying text sections for jump labels, a paranoid check is
performed. If the check fails, the system "bugs". But why it failed
is not shown.
The BUG_ON()s in the jump label update code is replaced with bug_at(ip).
This is a function that will show what pointer
From: Steven Rostedt srost...@redhat.com
When modifying text sections for jump labels, a paranoid check is
performed. If the check fails, the system bugs. But why it failed
is not shown.
The BUG_ON()s in the jump label update code is replaced with bug_at(ip).
This is a function that will show
On Wed, Aug 07, 2013 at 12:49:38PM -0400, Steven Rostedt wrote:
From: Steven Rostedt srost...@redhat.com
When modifying text sections for jump labels, a paranoid check is
performed. If the check fails, the system bugs. But why it failed
is not shown.
The BUG_ON()s in the jump label update
On Wed, 2013-08-07 at 19:20 +0200, Borislav Petkov wrote:
+static void bug_at(unsigned char *ip, int line)
+{
+ /*
+* The location is not an op that we were expecting.
+* Something went wrong. Crash the box, as something could be
+* corrupting the kernel.
+*/
On Wed, Aug 07, 2013 at 01:33:06PM -0400, Steven Rostedt wrote:
Right, and this code keeps the same logic as it was before. If it was
disabled by CONFIG_EXPERT, it stays disabled, but at least you get to
see a warning that your kernel may be corrupt now :-)
Don't we really want to panic
On Wed, 2013-08-07 at 19:37 +0200, Borislav Petkov wrote:
On Wed, Aug 07, 2013 at 01:33:06PM -0400, Steven Rostedt wrote:
Right, and this code keeps the same logic as it was before. If it was
disabled by CONFIG_EXPERT, it stays disabled, but at least you get to
see a warning that your
On 08/07/2013 10:46 AM, Steven Rostedt wrote:
On Wed, 2013-08-07 at 19:37 +0200, Borislav Petkov wrote:
On Wed, Aug 07, 2013 at 01:33:06PM -0400, Steven Rostedt wrote:
Right, and this code keeps the same logic as it was before. If it was
disabled by CONFIG_EXPERT, it stays disabled, but at
On Wed, Aug 07, 2013 at 10:51:43AM -0700, H. Peter Anvin wrote:
A bigger issue is probably if panic-on-bug should be the default, with
!panic being an opt-in debugging option.
Yes, it might make sense although embedded wants to disable CONFIG_BUG
on systems which cannot report errors:
│
On 08/07/2013 11:41 AM, Borislav Petkov wrote:
On Wed, Aug 07, 2013 at 10:51:43AM -0700, H. Peter Anvin wrote:
A bigger issue is probably if panic-on-bug should be the default, with
!panic being an opt-in debugging option.
Yes, it might make sense although embedded wants to disable
32 matches
Mail list logo
