[sclug] Recovering gracefully from lost interrupt

Will Dickson wrd at glaurung.demon.co.uk
Sat Oct 25 09:05:50 UTC 2003


Simon Huggins wrote:
> On Wed, Aug 06, 2003 at 12:19:00AM +0100, Will Dickson wrote:
> 
>>Simon Huggins wrote:
>>
>>Nope! Various other kernels, both custom and standard, various other
>>distros (various versions of SuSE), all OK. This and the other
>>hardware / driver oddities I mentioned earlier appear to be specific
>>to debian.  I'd report it, except I can't work out what the most
>>appropriate package is.
> 
> 
> Or specific to the kernel you were running in Debian.

Perhaps, although IIRC is was just 2.4.20; I can't remember whether it
was Debian's precompiled one or a customised one. (In the latter case, I
am familiar with the kernel compile process; I've been compiling
customised kernels successfully for several years prior to this incident.)
> 
> What I mean is can you reproduce it:
> 	- running the Debian kernel on a different distribution
> 	  (which I'd expect you would be able to)
> 	- running the vanilla kernel of the same version on Debian
> 	- running the vanilla kernel of the same version on something
> 	  else
> Obviously all with the same .config.

Don't know; I don't have the time or the spare machine to test at this
point.
> 
> 
> I'm only trying to work this out because you seem to be propagating FUD
> that Debian eats data and this isn't true IME.

I am not propagating FUD, and I find that remark insulting. I am trying
to alert people to an extremely serious problem that I encountered, in
case they do as well. It may well be that my configuration somehow got
fubared, and that nobody else will ever see this problem, in which case
great. And by happy chance I caught this one before it had any
consequences beyond giving me a fright, so all's well that ends well.
*But* if I hadn't, it could have meant four years' worth of records
going up in smoke, and the consequences for our business would have been
fatal.

Debian per se may well not eat data, but my installation DID.

Will.









More information about the Sclug mailing list