not much difference with
2.6.23.1:
Oct 17 22:33:56 SANfile_m kernel: kobject_add
failed for 1:0:1:0 with -EEXIST, don't try to register things with the same
name in the same directory. Oct 17 22:33:56 SANfile_m kernel:
[<c03074d5>] kobject_shadow_add+0x115/0x1b0 Oct 17 22:33:56 SANfile_m
kernel: [<c03a8f58>] device_add+0xa8/0x5a0 Oct 17 22:33:56
SANfile_m kernel: [<c02fc582>]
__blk_queue_init_tags+0x32/0x70 Oct 17 22:33:56 SANfile_m kernel:
[<c03fb8af>] scsi_sysfs_add_sdev+0x4f/0x220 Oct 17 22:33:56 SANfile_m
kernel: [<f99498b7>] qla2xxx_slave_configure+0x77/0x110
[qla2xxx] Oct 17 22:33:56 SANfile_m kernel: [<c03f986a>]
scsi_probe_and_add_lun+0x92a/0x950 Oct 17 22:33:56 SANfile_m kernel:
[<c03fa26d>] __scsi_scan_target+0x4fd/0x5b0 Oct 17 22:33:56 SANfile_m
kernel: [<c03fa954>] scsi_scan_target+0x94/0xc0 Oct 17 22:33:56
SANfile_m kernel: [<c04014f0>] fc_scsi_scan_rport+0x0/0x90 Oct 17
22:33:56 SANfile_m kernel: [<c0401568>]
fc_scsi_scan_rport+0x78/0x90 Oct 17 22:33:56 SANfile_m kernel:
[<c013e963>] run_workqueue+0x73/0x100 Oct 17 22:33:56 SANfile_m
kernel: [<c0142350>] autoremove_wake_function+0x0/0x50 Oct 17
22:33:56 SANfile_m kernel: [<c013f3dc>]
worker_thread+0x9c/0x100 Oct 17 22:33:56 SANfile_m kernel:
[<c0142350>] autoremove_wake_function+0x0/0x50 Oct 17 22:33:56
SANfile_m kernel: [<c013f340>] worker_thread+0x0/0x100 Oct 17
22:33:56 SANfile_m kernel: [<c0142082>] kthread+0x42/0x70 Oct 17
22:33:56 SANfile_m kernel: [<c0142040>] kthread+0x0/0x70 Oct 17
22:33:56 SANfile_m kernel: [<c0105e6f>]
kernel_thread_helper+0x7/0x18 Oct 17 22:33:56 SANfile_m kernel:
======================= Oct 17 22:33:56 SANfile_m kernel: error
1
----- Original Message -----
Sent: Wednesday, October 17, 2007 6:01
PM
Subject: Re: multibus /
failover and EMC CX600
* Gerald Nowitzky
> The mpath_prio_emc with
group_by_prio did the trick. Thanks! > > But I am still
loosing the paths to the failed devices. I Increased > dev_loss_tmo, but
the maximum seems to be about 600 - thus, after 10 > Minutes, the paths
fail:
The maximum is indeed 600 seconds in 2.6.23.
>
SANfile_m linux # multipath -l > hcfshare
(360060160c820080063502869e459dc11) dm-0 , > [size=3.4T][features=1
queue_if_no_path][hwhandler=1 emc] > \_ round-robin 0
[prio=0][enabled] > \_ #:#:#:# - #:#
[failed][undef] > \_ #:#:#:# - #:#
[failed][undef] > \_ round-robin 0 [prio=0][active] > \_
2:0:0:0 sdd 8:48 [active][undef] > \_ 1:0:0:0 sdb 8:16
[active][undef] > If I put them online again, I run into the -EEXIST
prob. Async SCSI > scanning *is* off in my kernel, so the only thing I
could do from > here is to try the patch, is it?
Matthew Wilcox'
patch solved this particular problem for me, yes. I still had some
problems with -EEXIST when unloading and re-inserting the HBA driver
module, though, but that's a corner case I rarely run into (as well as
being easily worked around by trying again).
Come to think of it, you
never said which kernel version you're running...?
> Oct 17 17:26:36
SANfile_m kernel: kobject_add failed for 1:0:1:0 with > -EEXIST, don't
try to register things with the same name in the same >
directory.
One suggestion... If the sysfs object is still around,
you might be able to delete it manually by running «echo 1
> /sys/class/scsi_device/1:0:1:0/device/delete». If that works,
you can try to rescan again by doing «echo 0 1 0
> /sys/class/scsi_host/host1/scan». With some luck it'll
work...
If it does, most of the time udev will notice and alert
multipath to check out the new device. Sometimes it doesn't work,
though - simply run the «multipath» command manually in that
case.
By the way - the «1» in «host1» maps to the first digit in
«1:0:1:0», while the «0 1 0» in the echo command to the last
three.
Regards -- Tore Anderson
-- dm-devel mailing
list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
|
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel