|
Hannes,
so is this behavior by design? In this case,
patching in the scsi subsystem won't help to much, will it?
Manually updating the multipath information - well,
yes, that will work I guess, but in the end that should work without manual
intervention. Thus, I'd need to have a job checking the multipath table if there
are stale devices, and, if there are, rerun multipath to get them out. Not
exactly smooth, is it?
Thanks
(Gerald)
----- Original Message -----
Sent: Thursday, October 18, 2007 8:19
AM
Subject: Re: multibus /
failover and EMC CX600
On Wed, Oct 17, 2007 at 08:04:12PM +0200, Gerald
Nowitzky wrote:
> I'm afraid the patch did not work for me. I'ts still
the same.
>
> I am using kernel 2.6.22.2 at the moment. Should I
upgrade to 2.6.23 ?
>
> Anybody any Ideas?
> The system is
not in production at the moment. We could do some testing.
>
Well,
yes. By the looks of if the problem is with multipathing still
holding
references to the stale devices.
IE after dev_loss_tmo kicks in,
the devices are removed from sysfs.
But multipathing does _not_ update it's
device-mapper tables (that's why
you see all the '#' in the output), so
there's still a refence on the
removed device and the in-kernel resources
can't be freed.
So when the device is re-registered, you're getting
this Oops.
Try to update the multipath information by running
'multipath' after the
devices have been removed. Once the '#' in the output
are gone, you can
savely re-add the
devices.
Cheers,
Hannes
--
Dr. Hannes Reinecke
zSeries & Storage
hare@xxxxxxx +49
911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nrnberg
GF:
Markus Rex, HRB 16746 (AG Nrnberg)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
|
