Jump to content

Call Traces and IRQ 18


chalk4

Recommended Posts

I have recently installed Unraid and have been working to get everything setup correctly.  I have been experiencing very slow transfer speeds while I was migrating data to the array.   After some reading on the forum I removed the Parity disks and the write speeds seemed to improve from 2-4Mbit/Sec to 10-13Mbit/sec.   I have recently ran the CA Fix Common Problems tool and the following errors appeared.  It was recommended I post the diagnostics to the forums.   Can anyone please assist?

 

On another note I am trying to run unBALANCE for the first time and it is running at 1Mbit/sec,  slower than any transfers I have had since I started.unBALANCE.thumb.jpg.ecb80e13f300f9413d9cd6d1c27baa89.jpg

diagnostics-20170814-1215.zip

Link to comment

You are using very slow 4 port Sil3114 PCI controllers, all 8 disks will share the 130MB/s available for the PCI bus, you should replace both with a 8 port PCIe controller, LSI recommended.

 

Also, your onboard controller is in IDE mode, change it to AHCI, better performance for the SSDs (beside IDE mode won't even support trim).

Link to comment
4 minutes ago, chalk4 said:

Will the new LSI solve the Call Traces and IRQ 18 issues being reported?

 

Possibly, look also for a board bios update and there are reports of these being fixed by booting using UEFI (only supported on v6.4rc), BTW both IRQ 17 and 18 are being disabled.

 

6 minutes ago, chalk4 said:

Would this card work fine?

 

Yes

Link to comment

In your case, IRQ 17 & 18 were both used for the PCI sata controllers.

 

IRQ stands for Interrupt ReQuest

 

Basically an OS (any OS) tells your controllers, "hey can you grab this data for me".   When the IRQ is active, the controller responds with "Sure thing buddy, I'll let you know when I've got it".  When the data is ready, the controller Interrupts whatever is going on and send the data.

 

Without the Interrupt being active,  the controller responds with "Ok.  Check back later when you have some time"  At some point in the future, the OS checks back, and the data may or may not be there waiting for it.  If its there then everything is good, if its not, then the OS proceeds to continue to execute whatever other applicication happens to be running at the time and then eventually gets around to checking for it again.

 

Net result is that if an IRQ gets disabled, the whole process is significantly slower (as you're seeing)

 

 

Why it gets disabled, I'm not entirely sure.

 

Side note:

 

Many motherboard manuals (at least for the ones I've ever bought) show you on the expansion slots which slots share which interrupts with other slots.  In a perfect world, you want to try and isolate cards from each other's interrupts (or at least think about what you don't care about on a collision.  IE:  My use case dictates that I pretty much never have USB3 ports actually in use, therefore I don't care about if the interrupts the motherboard shares with them collide with a particular slot).

 

And the command that @johnnie.black listed is logged in the syslog when FCP finds that an IRQ has been disabled to assist him and others in figuring out if its actually a problem or not.

Link to comment
3 minutes ago, Squid said:

And the command that @johnnie.black listed is logged in the syslog when FCP finds that an IRQ has been disabled to assist him and others in figuring out if its actually a problem or not.

 

That's good that FCP logs that, didn't know and hadn't checked the syslog that far, with the controllers getting their IRQ disable it's no wonder you're having terrible performance, much worse than would already have because of them being older PCI controllers.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...