<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=utf-8"> <META content="MSHTML 6.00.2900.2802" name=GENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=#ffffff> <DIV><FONT face=Arial size=2>I'm afraid the patch did not work for me. I'ts still the same.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV> <DIV><FONT face=Arial size=2>I am using kernel 2.6.22.2 at the moment. Should I upgrade to 2.6.23 ?</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV></DIV> <DIV><FONT face=Arial size=2>Anybody any Ideas?</FONT></DIV> <DIV><FONT face=Arial size=2>The system is not in production at the moment. We could do some testing.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>(Gerald)</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>Oct 17 20:57:09 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.<BR>Oct 17 20:57:09 SANfile_m kernel: [number+85/816] kobject_shadow_add+0x115/0x1b0<BR>Oct 17 20:57:09 SANfile_m kernel: [<c02f95f5>] kobject_shadow_add+0x115/0x1b0<BR>Oct 17 20:57:09 SANfile_m kernel: [lo_ioctl+1125/2528] device_add+0xc5/0x570<BR>Oct 17 20:57:09 SANfile_m kernel: [<c03aefd5>] device_add+0xc5/0x570<BR>Oct 17 20:57:09 SANfile_m kernel: [fc_remote_port_rolechg+127/320] scsi_adjust_queue_depth+0x9f/0xf0<BR>Oct 17 20:57:09 SANfile_m kernel: [<c03f9d7f>] scsi_adjust_queue_depth+0x9f/0xf0<BR>Oct 17 20:57:09 SANfile_m kernel: [blk_register_region+18/64] __blk_queue_init_tags+0x32/0x70<BR>Oct 17 20:57:09 SANfile_m kernel: [<c02eeb72>] __blk_queue_init_tags+0x32/0x70<BR>Oct 17 20:57:09 SANfile_m kernel: [sr_get_mcn+50/240] scsi_sysfs_add_sdev+0x32/0x230<BR>Oct 17 20:57:09 SANfile_m kernel: [<c04028b2>] scsi_sysfs_add_sdev+0x32/0x230<BR>Oct 17 20:57:09 SANfile_m kernel: [<f99445b7>] qla2xxx_slave_configure+0x77/0x110 [qla2xxx]<BR>Oct 17 20:57:09 SANfile_m kernel: [sd_init_command+313/1088] scsi_probe_and_add_lun+0x8c9/0x940<BR>Oct 17 20:57:09 SANfile_m kernel: [<c0400859>] scsi_probe_and_add_lun+0x8c9/0x940<BR>Oct 17 20:57:09 SANfile_m kernel: [sr_probe+72/1472] __scsi_scan_target+0x518/0x5c0<BR>Oct 17 20:57:09 SANfile_m kernel: [<c04012c8>] __scsi_scan_target+0x518/0x5c0<BR>Oct 17 20:57:09 SANfile_m kernel: [kallsyms_addresses+36323/130252] schedule+0x2df/0x940<BR>Oct 17 20:57:09 SANfile_m kernel: [<c053699f>] schedule+0x2df/0x940<BR>Oct 17 20:57:09 SANfile_m kernel: [sr_init_command+128/944] scsi_scan_target+0xd0/0xe0<BR>Oct 17 20:57:09 SANfile_m kernel: [<c0401a40>] scsi_scan_target+0xd0/0xe0<BR>Oct 17 20:57:09 SANfile_m kernel: [SendIocInit+272/784] fc_scsi_scan_rport+0x0/0x90<BR>Oct 17 20:57:09 SANfile_m kernel: [<c04084e0>] fc_scsi_scan_rport+0x0/0x90<BR>Oct 17 20:57:09 SANfile_m kernel: [SendIocInit+392/784] fc_scsi_scan_rport+0x78/0x90<BR>Oct 17 20:57:09 SANfile_m kernel: [<c0408558>] fc_scsi_scan_rport+0x78/0x90<BR>Oct 17 20:57:09 SANfile_m kernel: [run_workqueue+131/256] run_workqueue+0x73/0x100<BR>Oct 17 20:57:09 SANfile_m kernel: [<c0131dc3>] run_workqueue+0x73/0x100<BR>Oct 17 20:57:09 SANfile_m kernel: [autoremove_wake_function+16/80] autoremove_wake_function+0x0/0x50<BR>Oct 17 20:57:09 SANfile_m kernel: [<c01354e0>] autoremove_wake_function+0x0/0x50<BR>Oct 17 20:57:09 SANfile_m kernel: [worker_thread+172/256] worker_thread+0x9c/0x100<BR>Oct 17 20:57:09 SANfile_m kernel: [<c01326dc>] worker_thread+0x9c/0x100<BR>Oct 17 20:57:09 SANfile_m kernel: [autoremove_wake_function+16/80] autoremove_wake_function+0x0/0x50<BR>Oct 17 20:57:09 SANfile_m kernel: [<c01354e0>] autoremove_wake_function+0x0/0x50<BR>Oct 17 20:57:09 SANfile_m kernel: [worker_thread+16/256] worker_thread+0x0/0x100<BR>Oct 17 20:57:09 SANfile_m kernel: [<c0132640>] worker_thread+0x0/0x100<BR>Oct 17 20:57:09 SANfile_m kernel: [kthread+82/112] kthread+0x42/0x70<BR>Oct 17 20:57:09 SANfile_m kernel: [<c0135212>] kthread+0x42/0x70<BR>Oct 17 20:57:09 SANfile_m kernel: [kthread+16/112] kthread+0x0/0x70<BR>Oct 17 20:57:09 SANfile_m kernel: [<c01351d0>] kthread+0x0/0x70<BR>Oct 17 20:57:09 SANfile_m kernel: [print_trace_stack+3/16] kernel_thread_helper+0x7/0x14<BR>Oct 17 20:57:09 SANfile_m kernel: [<c0104763>] kernel_thread_helper+0x7/0x14<BR>Oct 17 20:57:09 SANfile_m kernel: =======================<BR>Oct 17 20:57:09 SANfile_m kernel: error 1<BR></FONT></DIV> <BLOCKQUOTE style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV> <DIV style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> <A title=tore@linpro.no href="mailto:tore@linpro.no">Tore Anderson</A> </DIV> <DIV style="FONT: 10pt arial"><B>To:</B> <A title=dm-devel@redhat.com href="mailto:dm-devel@redhat.com">device-mapper development</A> </DIV> <DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, October 17, 2007 6:01 PM</DIV> <DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [dm-devel] multibus / failover and EMC CX600</DIV> <DIV><BR></DIV>* Gerald Nowitzky<BR><BR>> The mpath_prio_emc with group_by_prio did the trick. Thanks!<BR>> <BR>> But I am still loosing the paths to the failed devices. I Increased<BR>> dev_loss_tmo, but the maximum seems to be about 600 - thus, after 10<BR>> Minutes, the paths fail:<BR><BR>The maximum is indeed 600 seconds in 2.6.23.<BR><BR>> SANfile_m linux # multipath -l<BR>> hcfshare (360060160c820080063502869e459dc11) dm-0 ,<BR>> [size=3.4T][features=1 queue_if_no_path][hwhandler=1 emc]<BR>> \_ round-robin 0 [prio=0][enabled]<BR>> \_ #:#:#:# - #:# [failed][undef]<BR>> \_ #:#:#:# - #:# [failed][undef]<BR>> \_ round-robin 0 [prio=0][active]<BR>> \_ 2:0:0:0 sdd 8:48 [active][undef]<BR>> \_ 1:0:0:0 sdb 8:16 [active][undef]<BR>> If I put them online again, I run into the -EEXIST prob. Async SCSI<BR>> scanning *is* off in my kernel, so the only thing I could do from<BR>> here is to try the patch, is it?<BR><BR>Matthew Wilcox' patch solved this particular problem for me, yes. I<BR>still had some problems with -EEXIST when unloading and re-inserting the<BR>HBA driver module, though, but that's a corner case I rarely run into<BR>(as well as being easily worked around by trying again).<BR><BR>Come to think of it, you never said which kernel version you're running...?<BR><BR>> Oct 17 17:26:36 SANfile_m kernel: kobject_add failed for 1:0:1:0 with<BR>> -EEXIST, don't try to register things with the same name in the same<BR>> directory.<BR><BR>One suggestion... If the sysfs object is still around, you might be<BR>able to delete it manually by running «echo 1 ><BR>/sys/class/scsi_device/1:0:1:0/device/delete». If that works, you can<BR>try to rescan again by doing «echo 0 1 0 ><BR>/sys/class/scsi_host/host1/scan». With some luck it'll work...<BR><BR>If it does, most of the time udev will notice and alert multipath to<BR>check out the new device. Sometimes it doesn't work, though - simply<BR>run the «multipath» command manually in that case.<BR><BR>By the way - the «1» in «host1» maps to the first digit in «1:0:1:0»,<BR>while the «0 1 0» in the echo command to the last three.<BR><BR>Regards<BR>-- <BR>Tore Anderson<BR><BR>--<BR>dm-devel mailing list<BR><A href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</A><BR><A href="https://www.redhat.com/mailman/listinfo/dm-devel">https://www.redhat.com/mailman/listinfo/dm-devel</A></BLOCKQUOTE></BODY></HTML>