When I boot into unRAID/xen v6.0b5a option I am missing all my disks on my marvell controller.  When I boot without xen all drives are accounted for.

 

I have attached both syslogs.

syslog_xen.txt

syslog.txt

Maybe worth posting a link to this thread in the release of the beta you're using so tom deffo sees it.

 

Sent from my Nexus 5 using Tapatalk

 

 

SATA communications are on 2 levels, the low level SATA link first, then the higher level comms between the SATA disk controller and the drive.  All of the SATA link layers were built fine with no issues, but with XEN loaded, the SATA controller never received an intelligible response.  The kernel tried slowing down the SATA link connections, but that did not help.  Since it works fine without XEN, we can conclude it is not a hardware issue.

 

At almost the same time, an "irq 16: nobody cared" error was logged (in both syslogs!), and IRQ 16 was quickly disabled.  And in both syslogs, the only handler reported to be using it was usb_hcd_irq, so several USB ports were no longer usable, thankfully not the one with your UnRAID flash drive.  To the best of my understanding, an unhandled interrupt means buggy software somewhere.  It could be in the motherboard BIOS, the disk controller firmware, the XEN module handling the setup here, etc.  It works without XEN involvement, it does not work with XEN involved.  I personally suspect a bug in the XEN handling here, and here's why I think so.

 

In the non-XEN syslog, IRQ 16 is only mapped to a few of the USB ports, so no loss in your case when it fails.  In the XEN case though, XEN sets up its own table of mapped interrupts, with a GSI notation, and you can see them mapped in a one to one relationship with the ordinary IRQ's, GSI 3 to IRQ 3, GSI 4 to IRQ 4, etc, GSI 15 to IRQ 15, and then farther down, GSI 16 through 19 to IRQ 16 to 19.  GSI 16 is then assigned to a number of things, including the Marvell card!  That makes it highly suspicious then, that only the usb_hcd_irq handler is registered to IRQ 16!  I'm in no way an expert here though, and don't fully understand the relationships set up here, but it does look more than coincidental that it is IRQ 16 that is disabled, and the Marvell card is using GSI 16.

 

What to do?  Hopefully a future version will fix this, or a firmware or BIOS update will help.  I see your BIOS is very recent, so probably no help there.  For now, all you can do is try another controller.  But perhaps others with more experience with your card will have ideas.

 

Correction:  I forgot to make it clear that the unhandled IRQ 16 is a bug that has nothing at all to do with XEN (occurs with or without XEN), so there appears to be 2 bugs here.  The unhandled IRQ is *I think* a bug in the BIOS (even if it's a new BIOS version).

My bios is the most recent and I forgot to mention that the MB is a Asrock C226 WS with a Xeon 1245 v3.

 

The controllers that are having the issue are on the MB and I don't want to add a sata card to get my drives back.

 

Sent from my SCH-I545 using Tapatalk

 

This Marvell controller (88SE9172) doesn't play nicely with Xen.  I have two of them in my motherboard and have avoided using them for now (don't have that many disks yet) because I saw the issues when researching if my MB would be xen friendly.

 

Google "marvell 9172 xen" will show you some xen distribution list discussions about it, some discussion about it here, and other places as well.  I seem to remember someone posting a workaround but not with much detail for implementing it without some understanding of what you're doing.

 

Edit:  I see you're other thread now asking about this, so disregard.  I can't really help you but I'm interested in your findings.

I have a 2 port 9172 and a 4 port 9230. I have an SSD and 2.5" sata ii drive on the 9172.  The SSD I mount for vm's and I mount the hard drive inside a vm. You might try turning off SMART and sata aggressive link power management in the bios under Advanced/Storage Configuration. I have read about problems with Marvells and smart and I have had problems with drives dropping/disappearing with ALPM turned on.

 

Edit:

I previously had shared drives on the 9172 and recently moved the 2 vm drives on to it to help with performance during parity checks. It also more than doubled my transfer rate between my cache SSD (on intel sata3) and my vm drive (on marvell 9172)