[dm-devel] multibus / failover and EMC CX600

Wed Oct 17 18:04:12 UTC 2007

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.

(Gerald)

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.
Oct 17 20:57:09 SANfile_m kernel:  [number+85/816] kobject_shadow_add+0x115/0x1b0
Oct 17 20:57:09 SANfile_m kernel:  [<c02f95f5>] kobject_shadow_add+0x115/0x1b0
Oct 17 20:57:09 SANfile_m kernel:  [lo_ioctl+1125/2528] device_add+0xc5/0x570
Oct 17 20:57:09 SANfile_m kernel:  [<c03aefd5>] device_add+0xc5/0x570
Oct 17 20:57:09 SANfile_m kernel:  [fc_remote_port_rolechg+127/320] scsi_adjust_queue_depth+0x9f/0xf0
Oct 17 20:57:09 SANfile_m kernel:  [<c03f9d7f>] scsi_adjust_queue_depth+0x9f/0xf0
Oct 17 20:57:09 SANfile_m kernel:  [blk_register_region+18/64] __blk_queue_init_tags+0x32/0x70
Oct 17 20:57:09 SANfile_m kernel:  [<c02eeb72>] __blk_queue_init_tags+0x32/0x70
Oct 17 20:57:09 SANfile_m kernel:  [sr_get_mcn+50/240] scsi_sysfs_add_sdev+0x32/0x230
Oct 17 20:57:09 SANfile_m kernel:  [<c04028b2>] scsi_sysfs_add_sdev+0x32/0x230
Oct 17 20:57:09 SANfile_m kernel:  [<f99445b7>] qla2xxx_slave_configure+0x77/0x110 [qla2xxx]
Oct 17 20:57:09 SANfile_m kernel:  [sd_init_command+313/1088] scsi_probe_and_add_lun+0x8c9/0x940
Oct 17 20:57:09 SANfile_m kernel:  [<c0400859>] scsi_probe_and_add_lun+0x8c9/0x940
Oct 17 20:57:09 SANfile_m kernel:  [sr_probe+72/1472] __scsi_scan_target+0x518/0x5c0
Oct 17 20:57:09 SANfile_m kernel:  [<c04012c8>] __scsi_scan_target+0x518/0x5c0
Oct 17 20:57:09 SANfile_m kernel:  [kallsyms_addresses+36323/130252] schedule+0x2df/0x940
Oct 17 20:57:09 SANfile_m kernel:  [<c053699f>] schedule+0x2df/0x940
Oct 17 20:57:09 SANfile_m kernel:  [sr_init_command+128/944] scsi_scan_target+0xd0/0xe0
Oct 17 20:57:09 SANfile_m kernel:  [<c0401a40>] scsi_scan_target+0xd0/0xe0
Oct 17 20:57:09 SANfile_m kernel:  [SendIocInit+272/784] fc_scsi_scan_rport+0x0/0x90
Oct 17 20:57:09 SANfile_m kernel:  [<c04084e0>] fc_scsi_scan_rport+0x0/0x90
Oct 17 20:57:09 SANfile_m kernel:  [SendIocInit+392/784] fc_scsi_scan_rport+0x78/0x90
Oct 17 20:57:09 SANfile_m kernel:  [<c0408558>] fc_scsi_scan_rport+0x78/0x90
Oct 17 20:57:09 SANfile_m kernel:  [run_workqueue+131/256] run_workqueue+0x73/0x100
Oct 17 20:57:09 SANfile_m kernel:  [<c0131dc3>] run_workqueue+0x73/0x100
Oct 17 20:57:09 SANfile_m kernel:  [autoremove_wake_function+16/80] autoremove_wake_function+0x0/0x50
Oct 17 20:57:09 SANfile_m kernel:  [<c01354e0>] autoremove_wake_function+0x0/0x50
Oct 17 20:57:09 SANfile_m kernel:  [worker_thread+172/256] worker_thread+0x9c/0x100
Oct 17 20:57:09 SANfile_m kernel:  [<c01326dc>] worker_thread+0x9c/0x100
Oct 17 20:57:09 SANfile_m kernel:  [autoremove_wake_function+16/80] autoremove_wake_function+0x0/0x50
Oct 17 20:57:09 SANfile_m kernel:  [<c01354e0>] autoremove_wake_function+0x0/0x50
Oct 17 20:57:09 SANfile_m kernel:  [worker_thread+16/256] worker_thread+0x0/0x100
Oct 17 20:57:09 SANfile_m kernel:  [<c0132640>] worker_thread+0x0/0x100
Oct 17 20:57:09 SANfile_m kernel:  [kthread+82/112] kthread+0x42/0x70
Oct 17 20:57:09 SANfile_m kernel:  [<c0135212>] kthread+0x42/0x70
Oct 17 20:57:09 SANfile_m kernel:  [kthread+16/112] kthread+0x0/0x70
Oct 17 20:57:09 SANfile_m kernel:  [<c01351d0>] kthread+0x0/0x70
Oct 17 20:57:09 SANfile_m kernel:  [print_trace_stack+3/16] kernel_thread_helper+0x7/0x14
Oct 17 20:57:09 SANfile_m kernel:  [<c0104763>] kernel_thread_helper+0x7/0x14
Oct 17 20:57:09 SANfile_m kernel:  =======================
Oct 17 20:57:09 SANfile_m kernel: error 1

  ----- Original Message ----- 
  From: Tore Anderson 
  To: device-mapper development 
  Sent: Wednesday, October 17, 2007 6:01 PM
  Subject: Re: [dm-devel] 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 at redhat.com
  https://www.redhat.com/mailman/listinfo/dm-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20071017/5a89f91c/attachment.htm>