Re: [Fastboot] [RFC] [PATCH 2/2] kdump: cciss driver initialization issue fix

On Mon, Jun 26, 2006 at 10:00:55AM -0600, Eric W. Biederman wrote:

[..]

Looks like there are two problems to be solved.

- Framework/capability to mark and isolate the drivers, either at compile
time or run time, which are not hardened enough to initialize properly
when the underlying device is in operational or in unknown state.

- Actually hardening a driver to be able to initialize in a potentially
unreliable environment.


Solving first problem will help more in terms of people knowing in advance
that certain drivers are known to have problems in specific environemnt and
a user has got the option of skipping the execution/compilation of those
drivers. (This is something close to what CONFIG_EXPERIMENTAL does)

Second problem deals more with actually hardening the driver and not
skipping its compilation/execution.

I think people would like to change a driver's behaviour at run time.
For example if they are booting in a unreliable environment they would
like to reset the device otherwise they would skip that as BIOS has
already done that for them.

In the general case the device reset does not hurt.

I think it does hurt.

- I have seen the case of MPT fusion drvier. It takes significantly more
time to come up if we choose to reset the device during initialization.
One of the reasons that we wait in a tight loop for the controller to
come up after a reset message.

- Long back we fixed ips driver and I remember that the maintainer had
a similar issue with the reset of device. He did not want to reset the
device in normal boot because otherwise it took significantly longer
for the driver to initialize.

- Just now Mike also confirmed that resetting the device definitely
hurts in terms of time.

Yes there
is the case of the slow scsi probe. But a lot of that appears
to be a poor implementation of the scsi probe. So I can see a kernel
command line option to play fast and loose but we should be safe
and thorough by default.

The more code paths you introduce the harder code is to maintain
and test. The earlier discussion suggested you cannot harden
some drivers. We can take action against drivers like that simply
and easily.

Hacks in the driver initialization are a completely different story.


So it is matter of making a choice in case the device does not have a
software reset capability.

- Either try to make driver work through some hacks based on crashboot
option.

- Or mark the driver unusable in kdump scenarios.

Even if one decides to go for second option, at least "crashboot" or
similar parameter will be required so that driver can choose whether
to reset the device or not during initialization due to significant
time penalty.

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

Relevant Pages

  • [PATCH]: Documentation: Updated PCI Error Recovery
    ... PCI error handling doc. ... PCI Error Recovery ... -errors, and to be notified of, and respond to, a reset sequence. ... +including multiple instances of a device driver on multi-function ...
    (Linux-Kernel)
  • Re: pci error recovery procedure
    ... I am reviewing the error handlers of e1000 driver and got some ideas. ... for a full electical reset of the card, instead, it wants to perform ... error_resume could take care of multi-function card. ...
    (Linux-Kernel)
  • Re: pci error recovery procedure
    ... I am reviewing the error handlers of e1000 driver and got some ideas. ... for a full electical reset of the card, instead, it wants to perform ... error_resume could take care of multi-function card. ...
    (Linux-Kernel)
  • POSTing of video cards (WAS: Solo Xgl..)
    ... > Secondary cards needs reset. ... So this means that we have to run the VBIOS reset before probe ... responsibility of the driver to do what it needs at probe time or later. ... If a driver detects that it's card ...
    (Linux-Kernel)
  • Re: LCD_Backlight
    ... You really don't need to reset activity events manually. ... thread in your backlight driver and put the code I posted. ... a backlight driver may use the pair of manual-reset events ...
    (microsoft.public.windowsce.platbuilder)