Bugzilla Bug 126249

On some fibre-channel hardware (my case is a Sun StorEdge A5000 with a
Qlogic2100 controller), there is a very long delay between the kernel informing
udev that the device is coming online, and the device actually being ready to
probe.

The ioerr_cnt check is only part of the problem, as the drive has not yet spun
up then even.

In hotplug's scsi.agent, there is a check for the type attribute with a 10
second timeout. It needs to be greatly extended to pick up my hardware.

If not extended, scsi.agent times out, and then scsi_id fails to get data,
followed by path_id not running because ID_TYPE is not set - a wonderful
cascading failure.

I've produced a patch for this (attached), and I'll apply it in the tree if
there is no response by the end of the week.

I did 100 passes of testing, and found that it took an average of 30 seconds to
come online, with a worst case of 45 seconds. To have some margin, I've set the
timeout 30% higher, 60 seconds.

This change does not cause delays for other hardware, as their type attribute
exists long before the existing 10 second timeout anyway.

Created an attachment (id=82182) [edit]
Increases timeout to 60 seconds.

commited now after ACK by gregkh.