Bug 1316618 - Duplicate: UUID, hard resetting link [NEEDINFO]
Duplicate: UUID, hard resetting link
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: device-mapper-multipath (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Ben Marzinski
Lin Li
: 1316515 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2016-03-10 10:47 EST by Erbil Civelek
Modified: 2017-09-29 17:51 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-09-29 17:51:31 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
bmarzins: needinfo? (ecivelek)

Attachments (Terms of Use)

  None (edit)
Description Erbil Civelek 2016-03-10 10:47:12 EST
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

 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 15:01:02 EST
*** Bug 1316515 has been marked as a duplicate of this bug. ***
Comment 3 Ben Marzinski 2016-03-10 15:12:49 EST
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.