Bug 736419 - (NetApp CQ209655) RHEL 6.0 DMMP SANboot from alternate controller will not boot with LUNs mapped to host other than SANboot LUN
Summary: (NetApp CQ209655) RHEL 6.0 DMMP SANboot from alternate controller will not bo...
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: device-mapper-multipath
Version: 6.0
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Ben Marzinski
QA Contact: Storage QE
Depends On:
Blocks: 720380 756082
TreeView+ depends on / blocked
Reported: 2011-09-07 16:24 UTC by Michael Potyandy
Modified: 2015-10-08 18:32 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-01-05 14:59:25 UTC

Attachments (Terms of Use)

Description Michael Potyandy 2011-09-07 16:24:03 UTC
Description of problem: When booting SANboot RHEL 6.0 DMMP with the SANboot LUN owned by the alternate path on the storage array along with having LUNs mapped from multiple arrays, the OS begins to boot but then hangs reporting "INFO: task jbd2/dm-67-8:3367 blocked for more than 120 seconds." 

Version-Release number of selected component (if applicable):
RHEL 6.0

How reproducible:
The issue occurs everytime when trying to boot the SANboot LUN from the alterate path with additional LUNs mapped.

Steps to Reproduce:
1. Create 80 GB LUN (for SANboot).
2. Install OS to the SANboot LUN.
3. The SANboot LUN as well as 64 additional LUNs (32 from each array) are mapped to the host
3. Host is restarted to configure hba to boot from alternate controller
4. Reboot host.
Actual results:
The host begins to boot but hangs with message "INFO: task jbd2/dm-67-8:3367 blocked for more than 120 seconds."

Expected results:
OS boots up without any issues.

Additional info: We are seeing this issue using a QMI8142 Manteo FCoE HBA going to DS3500 and DS5300 arrays; iSCSI using Emulex eRaptor CNA (P/N: 49Y4235) going to two DS3500 arrays; and an IBM HS22 Blade server using a Meteorite (IBM P/N 43W3974) SAS pass-thru adapter going to DS3500 and DS3200 arrays.

Comment 2 Ben Marzinski 2011-09-08 20:16:15 UTC
There were some problems with both device-mapper-multipath and anaconda in RHEL 6.0, which could have caused them. This looks like it could be 644111. Would it be possible for you to retest this with 6.1?

Comment 3 Michael Potyandy 2011-09-08 20:43:00 UTC
We won't be able to try with 6.1 for probably another week or two with any of the same HBAs.  We were able to successfully SANboot from the alternate controller with volumes mapped on RHEL 6.1 using an Emulex fibre channel 8Gb Tetra (LPe1205-CIOv) HBA.

Comment 8 Abdel Sadek 2011-12-06 21:04:07 UTC
Adding IBM.

Comment 10 Michael Potyandy 2011-12-20 21:27:53 UTC
We do not see the issue on RHEL 6.1 or 6.2 using different HBAs/CNAs.  We have successfully booted from the alternate path with additional LUNs mapped using an Emulex fibre channel 8Gb (LPe1205-CIOv), Brocade Wanchese CNA (BR-1020) with FCoE, and 4Gb QLogic (QMI2472) & Emulex (LP1105-BC) HBAs.

Comment 11 Ben Marzinski 2012-01-04 19:43:54 UTC
So, can this be closed?

Comment 13 Michael Potyandy 2012-05-10 21:07:02 UTC
Yes, this can be closed.

Note You need to log in before you can comment on or make changes to this bug.