lkml.org 
[lkml]   [1999]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kiobuf using kernel pages
On Fri, 12 Nov 1999, Keith Owens wrote:
|>On Thu, 11 Nov 1999 12:56:23 +0000 (GMT),
|>Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
|>>> Trying to port the SGI lcrash code to 2.3.26 ix86. It compiles, runs,
|>>> traps the oops, starts writing the dump to swap, dies with -EFAULT in
|>>> sd_raw_rw. My guess is because the buffer address is c2c00000, i.e. I
|>>
|>>Firstly if your machine has crashed I wouldnt recommend invoking the scsi
|>>disk layer. If your partition info is corrupt or the scsi malloc pool is
|>>corrupt you could hit anything.
|>
|>Agreed. But SGI have gone to the bother of writing a free standing,
|>raw i/o SCSI system to "handle" dumps even when the machine has
|>crashed, using a pre formatted swap partition. I am not convinced
|>myself if it is safe or not, only experience will show. Their patch is
|>only against 2.2.13, I'm porting it to 2.3.26 for testing.

I'm fairly certain it is safe, but if you want help with the port,
I'm more than willing to work and test along with you. :) Also note
that we are working on getting IDE disks working at this time. Now
if we can just get page typing flags used, we can get the entire
ordered dump mechanism going. Not to mention processor-specific
data structures ...

Lots of things to add, but we believe, along with other crash dump
implementations, that this is the right method for crash dumps.

--Matt


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

\
 
 \ /
  Last update: 2005-03-22 13:54    [from the cache]
©2003-2011 Jasper Spaans