Re: [2/3] 2.6.22-rc2: known regressions v2

[Chris Newport <crn@netunix.com>]

Sorry, I did not make myself clear.

Linus Torvalds wrote:

> On Fri, 25 May 2007, Chris Newport wrote:
>  
>
> > Maybe we should take a hint from Solaris.
> >    
>
> No. Solaris is shit. They make their decisions based on "we control the 
> hardware" kind of setup.
>  
Not really a Solaris feature. This is a feature of the  Openboot  PROM
which is also used by several other vendors.
The Openboot PROM knows how to write to disk. The same should
apply on Apple hardware and others which use the openboot
convention.

If dumps are enabled (disabled by default in a file read at boot) the
crash() function need only  set a couple of registers and do a prom
interrupt. At this point the kernel is no longer involved so broken
drivers etc are not an issue.

The cute bit is that the SunOS debug program can be called as
debug $DUMPFILE and it takes you to the failure point just like
a tracefile.

Crashdumps should not be enabled by default, they can chew rather
a lot of disk space making a crashdump.datetime file every time
something breaks <B-).
In most cases only developers will use this but it does resolve the
problem of error messages vanishing before they can be saved.


>  
>
> > If the kernel crashes Solaris dumps core to swap and sets a flag.
> > At the next boot this image is copied to /var/adm/crashdump where
> > it is preserved for future debugging. Obviously swap needs to be
> > larger than core, but this is usually the case.
> >    
>
> (a) it's not necessarily the case at all on many systems
>
> (b) _most_ crashes that are real BUG()'s (rather than WARN_ON()'s) leave 
>    the system in such a fragile state that trying to write to disk is the 
>    _last_ thing you should do.
>
>    Linux does the right thing: it tries to not make bugs fatal. 
>    Generally, you should see an oops, and things continue. Or a 
>    WARN_ON(), and things continue. But you should avoid the "the machine 
>    is now dead" cases.
>
> (c) have you looked at the size of drivers lately? I'd argue that *most* 
>    bugs by far happen in something driver-related, and most of our source 
>    code is likely drivers.
>
>    Writing to disk when the biggest problem is a driver to begin with 
>    is INSANE.
>
> So the fact is, Solaris is crap, and to a large degree Solaris is crap 
> exactly _because_ it assumes that it runs in a "controlled environment".
>
> Yes, in a controlled environment, dumping the whole memory image to disk 
> may be the right thing to do. BUT: in a controlled environment, you'll 
> never get the kind of usage that Linux gets. Why do you think Linux (and 
> Windows, for that matter) took away a lot of the market from traditional 
> UNIX? 
>
> Answer: the traditional UNIX hardware/control model doesn't _work_. People 
> want more flexibility, both on a hardware side and on a usage side. And 
> once you have the flexibility, the "dump everything to disk" is simply not 
> an option any more.
>
> Disk dumps etc are options at things like wall street. But look at the bug 
> reports, and ask yourself how many of them happen at Wall Street, and how 
> many of them would even be _relevant_ to somebody there? 
>
> So forget about it. The whole model is totally broken. We need to make 
> bug-reports short and sweet, enough so that random people can 
> copy-and-paste them into an email or take a digital photo. Anything else 
> IS TOTALLY INSANE AND USELESS!
>
> 			Linus
>  

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/