[SOLVED] VERY slow preclear on disk(s) attached to PCIe SATA card

Biostar support finally responded, but, not to any of my emails or E-support forms on their website.  They responded to my review on Newegg in which I outlined my problems.  Nothing like a negative public review to get a little attention 

They were no help.  I think I know more about this motherboard than the "support" tech.  He will forward my information (syslog, interrupts, lspci output, etc.) on to R&D in Taiwan.  Yeah, I'm sure I'll be hearing from them soon.

In the meantime, the Intel MB just arrived and I will try it and post the results.  I am hoping that all the information I am posting in this thread will help someone else with this issue as it is bound to come up again.

Maybe you should point biostar here also.

@Hoopster - most of Taiwan goes on holiday this week for Chinese New Year and won't be back until the end of the month.  So I genuinely would not expect anything in the way of a response for some time.

@Hoopster - most of Taiwan goes on holiday this week for Chinese New Year and won't be back until the end of the month.  So I genuinely would not expect anything in the way of a response for some time.

"Yeah, I'm sure I'll be hearing from them soon" = total sarcasm regardless of holidays.  Not that I think they won't look at the information I sent, but, I doubt my issue is much of a priority for Biostar R&D. If I hear from them someday, great!  If not, I am seeking other solutions.  In about an hour, I am going to install the Intel MB and see how it behaves with IRQs.

Yes, I realised it was sarcasm - hence my comment pointing out that there was also a genuine reason why you might not hear back, apart from the fact that it would be way down their list of things to do.

I have completed the swap out of my Biostar TH61-ITX motherboard for the Intel DQ67EP.  IRQ #16 is still the home for sata_mv as well as USB1.  Output of cat /proc/interrupts looks just like it did with the Biostar.    I start a preclear on the disk attached to the SATA controller.  >100 MB/s prereads.  Switch monitor to desktop and run unRAID web, unMenu, etc.  All is good.  Switch monitor to unRAID server input - IRQ #16 disabled and pre-read drops to ~2.6 MB/s. 

In other words, behavior with the Intel MB with a different NIC, BIOS and chipset is identical to behavior with the Biostar.  I will try updating Intel MB BIOS as it is a couple of revisions old. However, I am not too optimistic.

I suppose I could also try irqpoll, irqfixup, etc. with this MB.  At this point, I am wondering if the video switching is triggering something in the unRAID Linux kernel.

Of course, other than for BIOS tweaks, I do not need a monitor on the unRAID server and everything seems to be OK through telnet or SSH (at least with the Biostar - haven't tried yet with the Intel MB).

When you say video switching what do you mean?

Just connecting the monitor.

It could be the SATA card that's causing issues.

What is the brand/model of the card?

why not try without the KVM in there to switch the monitor back and forth.  Granted this should not be happening anyway, but it seems it is possible that that KVM might have something to do with this.

 

I am not using a KVM.  A separate keyboard is connected to the unRAID server.  My desktop monitor has several video inputs and I have the tower connected to the monitor via a DVI cable.  I am just switching inputs on the monitor.  I don't have a spare monitor at the moment that I can dedicate to the unRAID server and, of course, I need video when I am playing with the BIOS settings.  Maybe I can round up a monitor for the tower.

Never mind, I see here... If switching the monitor input to the other machine is causing issues, what happens if you just leave it there or off and do network traffic?

There's something causing an interrupt which is causing a hiccup

By video switching, I mean simply changing the input on my desktop monitor from DVI-1 which is my Windows desktop machine to DVI-2 which is my unRAID server.

The SATA card is a SYBA SY-PEX40048 which used the Marvell 88SX7042 chipset. 

http://www.sybausa.com/productInfo.php?iid=1160

This is identical to the Rosewill RC-218 (I have both cards and have tried both with the same result).  Both of these cards have been reported as being successfully used with unRAID servers although, possible not with a mini-ITX board with only the one x16 PCIe expansion slot.

This is identical to the Rosewill RC-218 (I have both cards and have tried both with the same result).  Both of these cards have been reported as being successfully used with unRAID servers although, possible not with a mini-ITX board with only the one x16 PCIe expansion slot.

I've had success with the RC-218.

Have you attempted going to 4.7?

 

Never mind, I see here... If switching the monitor input to the other machine is causing issues, what happens if you just leave it there or off and do network traffic?

 

There's something causing an interrupt which is causing a hiccup

As far as I can tell, if I switch from the unRAID server to the Windows desktop and just do "normal" things in accessing the array or doing array management via telnet or the web services, all is good.  I haven't really tested that long-term (more than a few hours) yet, but, it appears to be the case.  The moment I switch the monitor back to the DVI-2 (unRAID server) input, I get the disabled IRQ.  Switching away from it causes no problems, its switching back to it that blows things up.

I have also tried the HDMI input (Biostar MB) and the DisplayPort input (Intel MB) with the same result so, it is not a particular video signal causing the problem, just the act of switching back to the unRAID server input whatever it is.  Monitor does not have standard VGA input so, I don't know if that would result in anything different.

This is identical to the Rosewill RC-218 (I have both cards and have tried both with the same result).  Both of these cards have been reported as being successfully used with unRAID servers although, possible not with a mini-ITX board with only the one x16 PCIe expansion slot.

 

I've had success with the RC-218.

Have you attempted going to 4.7?

I have not tried 4.7 because the Realtek 8111E NIC on the Biostar requires v5 beta as does the Intel 82579V NIC on the Intel. 

And now I have yet another issue unrelated to the discussion in this thread.  If I insert the power supply in the case, the system will not boot (it acts like it has no power).  If I remove it from the case, leaving all power cables connected of course, the system boots up fine.  I have had it out as updating the BIOS on the Intel MB requires changing a jumper which I cannot access with the PSU mounted in this small case.  I have not yet updated the BIOS, but, I just thought I'd stick the power supply in anyway.  No boot.  Must be causing some kind of short when in the case.

I'm baffled on this one. The Video card/chip is obviously getting some kind of signal, and thus an interrupt is occurring.

And now I have yet another issue unrelated to the discussion in this thread.  If I insert the power supply in the case, the system will not boot (it acts like it has no power).  If I remove it from the case, leaving all power cables connected of course, the system boots up fine.  I have had it out as updating the BIOS on the Intel MB requires changing a jumper which I cannot access with the PSU mounted in this small case.  I have not yet updated the BIOS, but, I just thought I'd stick the power supply in anyway.  No boot.  Must be causing some kind of short when in the case.

Look for a short somewhere on the mobo against the chassis.. Possibly the standoffs?

I'm baffled on this one. The Video card/chip is obviously getting some kind of signal, and thus an interrupt is occurring.

The only thing I can think of is Linux or the BIOS is treating the SATA card like a video card even though both detect it as a SATA card on boot.  When I switch away it thinks it has lost a "video" signal, when I switch back, it is trying to reinitialize a video signal on the card on IRQ #16 it thinks is a video card.  Linux/BIOS fails to get the expected response (the nobody cared message) and disables the IRQ.

Even though I am using the onboard graphics of the Core i3 CPU only, switching the input appears to be directing a signal at IRQ #16.  Video is never interrupted, so, the system always knows it's using the i3 video.

Linux and the BIOS are probably smarter than that, but, I am grasping at straws at this point.

And now I have yet another issue unrelated to the discussion in this thread.  If I insert the power supply in the case, the system will not boot (it acts like it has no power).  If I remove it from the case, leaving all power cables connected of course, the system boots up fine.  I have had it out as updating the BIOS on the Intel MB requires changing a jumper which I cannot access with the PSU mounted in this small case.  I have not yet updated the BIOS, but, I just thought I'd stick the power supply in anyway.  No boot.  Must be causing some kind of short when in the case.

 

Look for a short somewhere on the mobo against the chassis.. Possibly the standoffs?

Fixed this one.  It was an ID10T error.  Space is so tight in this case that you have to be very careful to get the PSU cables out of the way and in the right places.  In all my moving cables around inside the case when I installed the PSU, the 24-pin MB power cable came loose.  That was an easy fix  .  I wish my other issue were this easy!

I'm baffled on this one. The Video card/chip is obviously getting some kind of signal, and thus an interrupt is occurring.

 

The only thing I can think of is Linux or the BIOS is treating the SATA card like a video card even though both detect it as a SATA card on boot.  When I switch away it thinks it has lost a "video" signal, when I switch back, it is trying to reinitialize a video signal on the card on IRQ #16 it thinks is a video card.  Linux/BIOS fails to get the expected response (the nobody cared message) and disables the IRQ.

 

Even though I am using the onboard graphics of the Core i3 CPU only, switching the input appears to be directing a signal at IRQ #16.  Video is never interrupted, so, the system always knows it's using the i3 video.

 

Linux and the BIOS are probably smarter than that, but, I am grasping at straws at this point.

Sounds plausible.

OK, it's time to move on.  I actually heard back from Biostar R&D in Taiwan regarding the IRQ disabling issue.  They came to the same conclusion as I did after much testing.  This issue is related to either the Linux kernel/sata_mv driver or the SATA card hardware.  Not sure where/who to report this, but, it's not an unRAID or MB BIOS issue.

Since the problem only occurs when switching video inputs on my monitor, I have decided to follow the advice given by many a wise doctor.  When the patient says "Dr. I feel fine, but, it sure hurts when I do this, what should I do?";  the wise Dr. responds, "don't do that!"

Since unRAID appears to be otherwise functional and works fine through telnet or SSH until I switch the monitor input, I just won't switch the monitor input!

Yes I know, topic is 2 years old, but just to say I have The same problem. When I plug the monitor, here the IRQ16 problem appears, and without sata card (but with too).

Yesterday, I installed a new disk in the server and unfortunatelly, I plugged the network cable in the wrong connector (I use a pcie intel card and not the realtek chip of the MB) and naturelly, no network. I plugged the monitor to see what was the problem and realize my mistake. So, plugged in the good connector, unplugged the monitor and go for the preclear -> 2,6 MB speed.

After reboot, all is ok.