2007-09-18 21:39:41

by Mukker, Atul

[permalink] [raw]
Subject: kdump detection in SCSI drivers

Hi,

Is there a standard way for drivers (RAID) to detect if the current
kernel is running in kdump mode? We would like to adjust driver behavior
dynamically when kdump is active by scaling down resources.

Thanks
-Atul Mukker
LSI Corp.


2007-09-20 10:42:59

by Pavel Machek

[permalink] [raw]
Subject: Re: kdump detection in SCSI drivers

> Hi,
>
> Is there a standard way for drivers (RAID) to detect if the current
> kernel is running in kdump mode? We would like to adjust driver behavior
> dynamically when kdump is active by scaling down resources.

Perhaps you should be automatically using little resources when little
memory is available, or something?

With upcomping kjump patches, it is more "interesting" than kdump
vs. no kdump.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2007-09-20 17:48:19

by Mukker, Atul

[permalink] [raw]
Subject: RE: kdump detection in SCSI drivers

How do we "know" when little memory is available?

Other suggestion which came about was to parse the kernel command line
and look for "elfcorehdr=". Is this ok? Is kernel command line visible
to the SCSI drivers?

Thanks
-Atul

-----Original Message-----
From: Pavel Machek [mailto:[email protected]]
Sent: Thursday, September 20, 2007 6:43 AM
To: Mukker, Atul
Cc: [email protected]; [email protected]
Subject: Re: kdump detection in SCSI drivers

> Hi,
>
> Is there a standard way for drivers (RAID) to detect if the current
> kernel is running in kdump mode? We would like to adjust driver
behavior
> dynamically when kdump is active by scaling down resources.

Perhaps you should be automatically using little resources when little
memory is available, or something?

With upcomping kjump patches, it is more "interesting" than kdump
vs. no kdump.

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2007-10-02 08:00:22

by Pavel Machek

[permalink] [raw]
Subject: Re: kdump detection in SCSI drivers

Hi!

> How do we "know" when little memory is available?

Kernel already scales its hash tables according to total RAM
available, perhaps you can use similar mechanism?

> Other suggestion which came about was to parse the kernel command line
> and look for "elfcorehdr=". Is this ok? Is kernel command line visible
> to the SCSI drivers?

Kernel command line probably is visible, but I'd recommend against
doing that.

Pavel

> Cc: [email protected]; [email protected]
> Subject: Re: kdump detection in SCSI drivers
>
> > Hi,
> >
> > Is there a standard way for drivers (RAID) to detect if the current
> > kernel is running in kdump mode? We would like to adjust driver
> behavior
> > dynamically when kdump is active by scaling down resources.
>
> Perhaps you should be automatically using little resources when little
> memory is available, or something?
>
> With upcomping kjump patches, it is more "interesting" than kdump
> vs. no kdump.
>
> Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2007-10-02 13:20:51

by Mark Salyzyn

[permalink] [raw]
Subject: RE: kdump detection in SCSI drivers

Pavel Machek sez:
> > Other suggestion which came about was to parse the kernel
> > command line and look for "elfcorehdr=". Is this ok? Is
> > kernel command line visible to the SCSI drivers?
> Kernel command line probably is visible, but I'd recommend
> against doing that.

Probably just as pregnant of a plan, what about looking for the
reset_devices being none-zero? It was introduced for kdump to address
the problem with devices that maintain state outside of the driver and
the intent is to have it always set in the kdump kernel context.

Personally, I'd code the driver to acquire memory normally, and have a
backup plan to acquire less should the allocation fail in a memory
limited environment ;-/

Sincerely -- Mark Salyzyn