LKML Archive on
help / color / mirror / Atom feed
From: Alistair John Strachan <>
To: Chris Rankin <>
Cc: Ken Moffat <>,
	Alan <>,
Subject: Re: 2.6.18-stable release plans?
Date: Thu, 25 Jan 2007 23:26:50 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thursday 25 January 2007 09:16, Chris Rankin wrote:
> But anyway - can someone please tell me what "Eeek! page_mapcount(page)
> went negative! (-1)" is *really* saying/implying? Because I am currently
> translating this as "I WANT TO EAT YOUR FILESYSTEMS".

Hugh already did, multiple times. If there's an external hardware event that 
corrupts memory, code executing on your CPU is no longer going to behave 
deterministically. So cases that are typically "impossible" in the design of 
the code have a chance to trigger.

You can continue to flame 2.6.19, but you're an extreme minority when it comes 
to this kind of bug and as, again, Hugh already said, almost all of the 
reports of this and similar other bugs have led to hardware problems that 
were either unchecked or difficult to detect.

Imagine this scenario. It might seem unrealistic to you, but it's not 

First Use of Linux -> Upgrading to 2.6.19
	Undetected hardware error never triggered.

Running 2.6.19
	Hardware error triggers. Linux crashes.

Going back to 2.6.18
	Hardware error has not yet triggered again.

Will it eat your filesystem? Maybe. But it probably won't, if you claim the 
memory is tested, it could have been a single bit error, or a cosmic ray 
event, or a brownout, or anything similar. It's much more likely to simply 
crash your machine, as it did.

Not running the affected kernel again is a sure way to have _nobody_ listen to 
your complaints about 2.6.19 having a real software bug, because you're 
totally unwilling to test the kernel again and see if it triggers. A single 
report is simply not enough evidence. 

Additionally, reports from other users (who may have a million different 
experimental variables involved) are also insufficient, for reasons which 
have already been explained (drivers, proprietary code, et cetera).


Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

  parent reply	other threads:[~2007-01-25 23:26 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-24 15:53 2.6.18-stable release plans? Chris Rankin
2007-01-24 16:12 ` Hugh Dickins
2007-01-24 17:33   ` Chris Rankin
2007-01-24 16:28 ` Mark Rustad
2007-01-24 22:37   ` Chris Rankin
2007-01-24 23:11     ` Alan
2007-01-24 23:05       ` Chris Rankin
2007-01-24 23:32       ` Mark Rustad
2007-01-24 23:45         ` Chris Rankin
2007-01-25  1:00           ` Ken Moffat
2007-01-25  9:16             ` Chris Rankin
2007-01-25 19:36               ` Ken Moffat
2007-01-26 13:02                 ` Chris Rankin
2007-01-25 23:26               ` Alistair John Strachan [this message]
2007-01-25  3:05           ` Mark Rustad
2007-01-25 21:04       ` Matt Mackall
2007-02-02  4:02     ` Valdis.Kletnieks
2007-02-02  6:47       ` Jon Masters
2007-02-02  8:17         ` Valdis.Kletnieks
     [not found] <>
2007-01-25  8:51 ` Chris Rankin
  -- strict thread matches above, loose matches on Subject: below --
2007-01-24 15:06 Chris Rankin
2007-01-24 15:40 ` Hugh Dickins
2007-01-24 13:30 Chris Rankin
2007-01-24 14:37 ` Hugh Dickins
2007-01-22 22:13 Chuck Ebbert
2007-01-23  0:23 ` Jesper Juhl
2007-01-23 20:33   ` Chuck Ebbert
2007-01-23 20:56     ` Adrian Bunk
2007-01-24  4:50   ` Daniel Barkalow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).