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
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