Bug 1316618 - Duplicate: UUID, hard resetting link [NEEDINFO]
Summary: Duplicate: UUID, hard resetting link
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: device-mapper-multipath
Version: 6.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ben Marzinski
QA Contact: Lin Li
URL:
Whiteboard:
: 1316515 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-10 15:47 UTC by Erbil Civelek
Modified: 2017-09-29 21:51 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-29 21:51:31 UTC
Target Upstream Version:
bmarzins: needinfo? (ecivelek)

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Description Erbil Civelek 2016-03-10 15:47:12 UTC 
Description of problem:

I assigned lun from Hitachi storage to the multipathd installed server. 3 hours later the server locked up. I had to do a "hard reset". There was UUID conflict and SATA link reset logs in /var/log/messages. After that two actions, the local disk turned into read-only mode

Kernel version : 3.8.13-16.2.1.el6uek.x86
device-mapper.x86_64               1.02.79-8.el6

/var/log/messages
 abrtd: Duplicate: UUID
 abrtd: DUP_OF_DIR: /var/spool/abrt/ccpp-2016-03-09-17:47:39-32530
 abrtd: Deleting problem directory ccpp-2016-03-09-18:35:21-25229 (dup of ccpp-2016-03-09-17:47:39-32530)
 abrtd: No actions are found for event 'notify-dup'
 kernel: ata1.00: hard resetting link
 kernel: ata1.01: hard resetting link
 kernel: ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
 kernel: ata1.01: SATA link down (SStatus 4 SControl 300)
 kernel: ata1.00: configured for UDMA/100
 kernel: ata1: EH complete
 kernel: ata2.00: hard resetting link
 kernel: ata2.01: hard resetting link
 kernel: ata2.00: SATA link down (SStatus 4 SControl 300)
 kernel: ata2.01: SATA link down (SStatus 4 SControl 300)
 kernel: ata2: EH complete
Comment 2 Ben Marzinski 2016-03-10 20:01:02 UTC 
*** Bug 1316515 has been marked as a duplicate of this bug. ***
Comment 3 Ben Marzinski 2016-03-10 20:12:49 UTC 
I need a lot more information to be able to have an idea of what's wrong.  Specifically, I don't see anything here that points to multipath. First, the UUID conflict has nothing to do with device-mapper UUIDs. It has to do with the abrt directory UUIDs. Did multipathd crash? Second, there no messages at all that multipath failed writing to the device that went down and failed back errors (which could cause the filesystem to go read-only). Also, are you actually using multipath on the SATA drives associated with the link reset?

What is the output of

# multipath -ll -v3
Note You need to log in before you can comment on or make changes to this bug.