Hoopster

Yep, that's why I am trying the Intel ITX MB, although reports are it has trouble running headless and complains if no keyboard and monitor are attached. I figure Intel ought to be able to figure out IRQ management. It's their chipset, CPU and NIC on this board. I wish the Supermicro ITX offerings did not use the mobile G2 socket and used the standard desktop 1155 socket. Although I cannot find any of the mobile i3 CPUs in retail channels, I did find one on eBay that, supposedly is "new" pulled from an HP laptop (why would anyone pull a "new" CPU out of a "new" laptop?). If it stays at .99 and $5 shipping, I'll pick it up and try the Supermicro if the Intel also has issues. I don't know why Supermicro thinks I want a mobile CPU on a "server" board. It also uses SODIMM laptop RAM. The advantage to the Supermicro is that it has 6 onboard SATA ports instead of the 4 of the Biostar and Intel MBs.

Because I need a monitor and keyboard attached for tweaking the BIOS. I do not believe the monitor is the issue as I used to be switching back and forth without IRQ #16 being disabled by a video switch. That is a recent and now every time occurrence and must have been triggered by a BIOS tweak that I am trying to track down. Before that became a trigger, it appeared to be NIC traffic that would trigger the disabling of IRQ #16 (or #11 when using nopic switch). I have been playing with BIOS settings to see if any of them affect IRQ assignments/APIC. What I have is a moving target right now. I have ordered the Intel DQ67EP board to see if its BIOS handles IRQ better than the Biostar.

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.

Well, that was quick. - Loaded v5 beta 12a on a USB stick. (this version contains the Realtek NIC driver from Realtek) - No extras at all, not even unMenu. - Default syslinux.cfg without the noapic line - Booted tower - Log in as root - Switch monitor to Windows 7 desktop - Access //tower/main from browser - Assign a couple of disks - Hit monitor switch to return to console on Tower - "disabling IRQ #16" appears immediately. Monitor signal switching seems to affect interrupts. Next test - various irqpoll, irqfixup, noapic combinations in syslinux.cfg At least I have eliminated the slight possibility of any add-ons contributing to the problem.

Of course, with APIC disabled, Shutdown from unRAID web page does not shutdown the server. I am going to try one of the betas with the Realtek driver and APIC enabled and see what happens. It looks like both beta 10 and beta 12a have the native Realtek driver? Changes from 5.0-beta12 to 5.0-beta12a -------------------------------------- - emhttp: inventory up to 26 total storage devices - linux: remove built-in r8169 driver - linux: add Realtek r8168 driver version r8168-8.025.00 (for Realtek PCI-Express NIC's) - linux: add Realtek r8169 driver version r8169-6.015.00 (for Realtek PCI NIC's) - linux: include /lib/firmware directory for e100, bnx2, tigon drivers - linux: increase scsi command time-out from 10sec to 30sec or Changes from 5.0-beta9 to 5.0-beta10 ------------------------------------ - afp: upgraded netatalk to version 2.2.0-p6 - afp: added "TimeMachine volume size limit" parameter for AFP - afp: always mount array/cache disks with extended attributes enabled - linux: upgraded to version 2.6.39.3 - linux: use Realtek r8168 driver instead of linux r8169 driver - linux: added Adaptec AIC79xx U320 support - linux: added Adaptec AIC94xx SAS/SATA support - linux: added UDF file system support - shfs: implement persistent inode numbers (AFP fix) I'll try 12a first then 10.

I think I'll order the Intel DQ67EP board just to see if the Intel NIC/BIOS on this board will play nicely, although even it requires unRAID v5 beta. The Supermicro mini-ITX MBs I mentioned are not an option as they use the G2 mobile CPU socket not the regular 1155 desktop CPU socket. I can't even find any of the mobile i3 CPUs in retail channels.

After running it twice, chkdsk on unRAID flash drive appears to have resolved the "read-only" issues. I have disabled USB 3.0 and XHCI. PS/2 keyboard now works; not sure how those are related. Preclear started on unRAID console. Web interfaces all functioning without LAN traffic causing problems. All looked good. Switched monitor input to unRAID server - BOOM, IRQ #11 disabled (maybe just poor timing - or switching video signal also messes with IRQs). Here is the latest cat/proc/interrupts with USB 3.xhci disabled: CPU0 0: 63525 XT-PIC-XT-PIC timer 1: 175 XT-PIC-XT-PIC i8042 2: 0 XT-PIC-XT-PIC cascade 3: 322 XT-PIC-XT-PIC ahci 5: 26 XT-PIC-XT-PIC ehci_hcd:usb2 11: 400405 XT-PIC-XT-PIC ehci_hcd:usb1, sata_mv, eth0 12: 3 XT-PIC-XT-PIC i8042 NMI: 0 Non-maskable interrupts LOC: 0 Local timer interrupts SPU: 0 Spurious interrupts PMI: 0 Performance monitoring interrupts IWI: 0 IRQ work interrupts RES: 0 Rescheduling interrupts CAL: 0 Function call interrupts TLB: 0 TLB shootdowns TRM: 0 Thermal event interrupts THR: 0 Threshold APIC interrupts MCE: 0 Machine check exceptions MCP: 3 Machine check polls ERR: 0 MIS: 0 Next step, play with all the irqpoll, apic options in different combinations. Yeah, I think the NIC driver is a problem. I'm off to church now, maybe praying is my only hope

Try any and/or all of these options. Do a search on the net to learn how they work. I think I had to use them on one of my older motherboards. along with iqpoll. acpi=off noapic nolapic Added acpi=off noapic nolapic to syslinux.cfg. There appears to be some progress in resolving the issue. USB1, sata_mv and eth0 are all now on IRQ #11. A preclear is running on the disk attached to the PCIe controller. It is currently running at > 100 MB/s on the pre-read. I have started unRAID web and run unMenu and unRAID Main from within unRAID Web. IRQ #11 was not disabled. Preclear continues to run and I have bounced back and forth between several unRAID web pages with no adverse affects other than the web access to the unRAID box appears to be a bit sluggish compared to when apic was enabled. The one undesirable side affect of adding "acpi=off noapic nolapic" to syslinux.cfg is that when unRAID booted I could not login to the server from the keyboard attached to the server (it's been there for convenience in all my testing). The keyboard input is dead. I figured it was because it is a PS/2 keyboard, so. I plugged in a USB keyboard. BOOM! IRQ #11 disabled With the USB keyboard plugged in USB 2.0 port, IRQ #11 gets disabled when the server boots. I plugged it into one of the USB 3.0 ports (what a waste! not that I need the USB 3.0 ports on this box for something else) and it booted without disabling IRQ #11. However, a few minutes later, IRQ #11 is disabled. So, I went back to the PS/2 keyboard; server boots, no keyboard input, no IRQ #11 disabled and I can sill telnet and access the server from the keyboard on my Windows box. Preclear is running in a Telnet session. I tried to output the latest cat /proc/interrupts results to a file and now it appears I cannot write anything to the flash disk as it says I have a "read-only filesystem." On to troubleshooting the next issue. Apparently, I can't write to the array either everything is read-only. One step forward, one step back.

Before I completely abandon the Biostar MB (although that is likely) and go with the Intel DQ67EP or Supermicro X9SCV-Q or QV4 MB (I need a socket 1155 MB for my i3 2100 CPU), here is a map of any BIOS settings I think I may be able to tweak. There is nothing in the BIOS that is APIC specific and I don't know enough enough about many of these to know if a different setting would help or not. The current setting is in [] Any suggestions? Advanced Settings PCI Subsystem PCI ROM Priority [EFI Compatible] Legacy Compatible PCI Latency Timer [32 Bus Clocks] Various settings between 32 - 248 Clocks VGA Palette Snoop [Disabled] Enabled No Snoop [Enabled] Disabled Max Payload [Auto] Various settings from 128 - 4096 Bytes Max Read Requests [Auto] Various Settings from 128 - 4096 Bytes PCI-E Link Settings ASPM Suport [Auto] Enabled Disabled ACPI Settings EuP Support [Enabled] Disabled ACPI Sleep [s3] S1 Disabled Lock Legacy Resources [Disabled] Enabled CPU Config SATA Config SATA Mode [AHCI] IDE Disabled S.M.A.R.T. [Enabled] Disabled Aggressive Link Power Management [Enabled] Disabled USB Config Legacy USB Support [Enabled] Disabled USB 3.0 [Enabled] Disabled XHCI Handoff [Enabled] Disabled EHCI Handoff [Enabled] Disabled Mass Storage Lists USB drives Smart Fan Super IO H/W Monitor Chipset North Bridge A bunch of onboard graphics settings PCI-E Port [Enabled] Disabled Detect Non-Compliant Device [Enabled] Disabled PEX16_1 Gen X [Auto] Gen 1 (The PCIe SATA Controller is Gen 1, but, Auto should cover it) Gen 2 South Bridge Azalia HD Audio [Disabled] Enabled High-Precision Timer [Enabled] Disabled USB 1.0/2.0 [Enabled] Disabled EHCI 1 [Enabled] Disabled EHCI 2 [Enabled] Disabled Onboard PCI-E Launch PXE opROM [Disabled] Enabled Lauch Storage opROM [Disabled] Enabled Onboard PCI-E Giga LAN [Enabled] Disabled Rear USB 3.0 [Enabled] Disabled Front USB 3.0 [Disabled] Enabled Boot Gate A20 Active [upon Request] Enabled Disabled Option ROM Messages [Force BIOS] Keep Current INT 19 Capture [Disabled] Enabled UEFI Boot [Disabled] Enabled A bunch of boot priority settings

Or maybe, any network activity over a certain level. Web-services do not equate to interrupts. (other than the network card issues them. Perhaps if too many, too quickly from your NIC to the chipset on the MB, it loses an interrupt.) If you've already tried a different NIC, I'd look for a different motherboard. Joe L. I am limited on motherboard selection because only a mini-ITX MB fits in my Lian-Li case. I have looked at the Intel DQ67EP as a possible replacement. It has the Intel 82579LM gigabit NIC, but, I understand a v5 beta version is also required to support this NIC as well, correct?

I haven't tried any early beta versions, but, I do need to be running v5 beta because my NIC is the dreaded Realtek 8111E. Installing a PCIe NIC is not an option since I need the one and only PCIe slot for the SATA controller. I will check out the BIOS for any APIC-related options. Do you have a suggestion for which earlier beta to try? Do I need to do anything special when moving from one v5 beta version to another?

OK, I just discovered something interesting. If I start a preclear from the command prompt after booting unRAID without accessing the unRAID server from a browser, pre-reads run at over 100 MB/s and keep running with no problems. I had it running successfully for over two hours and IRQ #16 is NEVER disabled. I also have unMenu and unRAID Web installed. I went to my windows machine and started unMenu (medianas:8080), immediately, I got the disabling IRQ #16 message and the pre-read performance tanked to 2.6 MB/s Although I had considered it to be a separate issue to be resolved after clearing up this IRQ mess, any time I started unRAID web (medianas:89), I would get a whole bunch of PHP undefined variable/constant messages on the unRAID console. Shortly thereafter, the "disabling IRQ #16" message would appear (but, it may only be when I access unMenu via unRAID web), but, I never associated the two together until this morning's test. Apparently, the disabling of IRQ #16 occurs when I access the unRAID box via unMenu (or maybe, any web service). What I can I look for to correct?

Hmmm...it looks like usb1 and sata_mv are sharing IRQ #16. Is that a problem?

Results of cat /proc/interrupts attached. Interrupts.txt

This issue is really bothering me. Just for fun, I booted into Windows, installed the driver for the PCIe SATA controller and updated it to the latest available version I could find (3.6.3). The controller installed with no problems. All disks attached to the controller appeared in device manager (unRAID recognizes them as well). The same IRQ (#16) was assigned to it by the BIOS as in unRAID. I checked all devices in device manager and there were no IRQ conflicts in Windows and all devices were reported as working properly. I waited 10 minutes and checked them all again. Still no problems. I shut down Windows and booted into unRAID, six minutes after booting, I got this is the syslog (with the familiar "disabling IRQ #16" on the monitor"): Jan 13 16:38:22 MediaNAS kernel: irq 16: nobody cared (try booting with the "irqpoll" option) (Errors) Jan 13 16:38:22 MediaNAS kernel: Pid: 0, comm: swapper Not tainted 3.1.1-unRAID #1 (Errors) Jan 13 16:38:22 MediaNAS kernel: Call Trace: (Errors) Jan 13 16:38:22 MediaNAS kernel: [<c104fa8c>] __report_bad_irq+0x1f/0x95 (Errors) Jan 13 16:38:22 MediaNAS kernel: [<c104fc39>] note_interrupt+0x137/0x1a8 (Errors) Jan 13 16:38:22 MediaNAS kernel: [<c104e776>] handle_irq_event_percpu+0xef/0x100 (Errors) Jan 13 16:38:22 MediaNAS kernel: [<c1050152>] ? handle_edge_irq+0xcb/0xcb (Errors) Jan 13 16:38:22 MediaNAS kernel: [<c104e7ab>] handle_irq_event+0x24/0x3b (Errors) Jan 13 16:38:22 MediaNAS kernel: [<c1050152>] ? handle_edge_irq+0xcb/0xcb (Errors) Jan 13 16:38:22 MediaNAS kernel: [<c10501bb>] handle_fasteoi_irq+0x69/0x82 (Errors) Jan 13 16:38:22 MediaNAS kernel: <IRQ> [<c1003566>] ? do_IRQ+0x37/0x90 Jan 13 16:38:22 MediaNAS kernel: [<c130c669>] ? common_interrupt+0x29/0x30 (Errors) Jan 13 16:38:22 MediaNAS kernel: [<c11ddd89>] ? acpi_idle_enter_bm+0x22a/0x25e (Errors) Jan 13 16:38:22 MediaNAS kernel: [<c12734f0>] ? cpuidle_idle_call+0x75/0xbd (Errors) Jan 13 16:38:22 MediaNAS kernel: [<c1001a5f>] ? cpu_idle+0x39/0x5a (Errors) Jan 13 16:38:22 MediaNAS kernel: [<c12fbd40>] ? rest_init+0x58/0x5a (Errors) Jan 13 16:38:22 MediaNAS kernel: [<c145172d>] ? start_kernel+0x28c/0x291 (Errors) Jan 13 16:38:22 MediaNAS kernel: [<c14510b0>] ? i386_start_kernel+0xb0/0xb7 (Errors) Jan 13 16:38:22 MediaNAS kernel: handlers: Jan 13 16:38:22 MediaNAS kernel: [<c1243aca>] usb_hcd_irq (Drive related) Jan 13 16:38:22 MediaNAS kernel: [<f848bf28>] mv_interrupt Jan 13 16:38:22 MediaNAS kernel: Disabling IRQ #16 Jan 13 16:41:42 MediaNAS kernel: NTFS driver 2.1.30 [Flags: R/W MODULE]. (System) I am by no means an expert on Linux/UnRAID, but, as I read through the forums I see that several of us have the same problem, all with different MBs and different SATA controllers with different chipsets. We also all seem to be running unRAID 5 beta. Again, I don't know enough to be making any declarations, but, is there any way this is an unRAID/Linux kernel issue with certain hardware combinations or do those of us with the problems all just happen to have different combinations of MB BIOS and SATA chipsets that throw these errors?

I have this exact issue on a Biostar motherboard and a PCIe SATA controller with the Marvell 88XS7042 chipset. I have updated the Biostar BIOS to the latest. There is no BIOS update for the controller (or even any way to update the BIOS on this controller). In my case it is IRQ #16. It gets disabled right after boot and happens to be the IRQ assigned to the SATA controller. The disks on that controller suffer horrible performance degradation as a result. http://lime-technology.com/forum/index.php?topic=17823.0 Did you ever resolve this issue avalonlea?

I think Hades may freeze over before I ever get anything from Biostar. Unfortunately, I have tried to contact them three different ways, and they have not responded to any of my inquiries from more than a week ago. I'll try it again, but, I am not hopeful. I may have to go with one of the Intel motherboards. At least they have decent support and you can actually speak with someone there, not just fill out an "E Support" form that never gets answered or send an email that ends up in the "do not respond" bin. Biostar "support" is nonexistent.

See if you can find an update to the BIOS on our board. This is ultimately the fault of the BIOS for not handeling thr IRQ's quite right. Well, I installed Window 7 on one of the disks and downloaded and installed the latest BIOS for the Biostar TH61-ITX MB. I set anything in the BIOS I thought might make a difference and rebooted. Although IRQ #16 was not immediately disabled it was eventually disabled after 3-4 minutes. I noticed in the syslog that IRQ #16 seems to be assigned to the NIC as well as all four ports on the PCIe SATA controller (if I am reading it correctly). When IRQ #16 is disabled, I still have network connectivity, but, performance on the SATA drives on the controller goes in the tank as noted in preclear attempts. Time to give up on this MB?

Well, the "disabling IRQ #16" issue is definitely the root of the problem. After reading through every post on the forums I could find about IRQ errors, I noticed that one user has set the PCI ROM option in his BIOS to "EFI compatible." Mine had that option plus "legacy." It was set to "legacy." Setting it to "EFI compatible" helped for a couple of minutes. The "disabling IRQ #16" message did not appear right before the login prompt when unRAID booted. Through a telnet session, I was able to start a preclear on the disk attached to the PCIe SATA controller and it was prereading at >100 MB/s. This is the first time I had ever seen that! I was doing a happy dance!. My joy was short-lived however. I terminated the telnet session and switched over to the command prompt on the unRAID box (I have a keyboard attached to it and an input on my desktop monitor so I can switch with a button press) only to be greeted by the "disabling IRQ #16" message. Preclear pre-reads are now back to 2.6 MB/s.

The BIOS on the MB was released June 1, 2011. There is a new BIOS for the MB released December 5, 2011; however, it lists as the only change support for 22nm CPUs. The only method for updating the BIOS seems to be a Windows utility. I guess I'll have to install windows on one of my spare disks and boot to that to install a new BIOS although I am not sure this new BIOS has any IRQ-related fixes. Would I be better off to swap the motherboard for an Intel DQ67EP or DH67CF?

No joy! I tried adding both irqpoll and irqfixup to the syslinux.cfg by modifying the line "append initrd=bzroot rootdelay=10 irqpoll" to try each option. The only difference is abysmal boot times (dare I say, almost Windows like?) and a noticeable performance lag. Right before the login prompt appears is says disabling IRQ #16 regardless of what I add to syslinux.cfg Does my syslog indicate anything else I might try?

See my last post in this thread on page 5 for why I consider this issue solved. I have a 4-port x4 PCIe SATA card inserted in the PCIe x16 slot of my mini-ITX MB. Preclears on any drive attached to this controller are reading at about 2.6 MB/s. The MB is a Biostar TH61-ITX On the MB SATA ports, the pre-read runs at over 100 MB/s The PCIe SATA controller is based on the Marvel 88SX7042 chipset. I have tried both the SYBA SY-PEX40048 card and the Rosewill RC-218. They are absolutely identical in every detail and both yield the same results. Both are reported by numerous people as working with unRAID through the sata_mv driver in Linux kernel 2.6 and above. As it is now, I am limited to a 4-drive array as the MB has only 4 SATA ports. I need the 4 more the controller card offers, but, not at this performance level. All drives Including those attached to the MB ports are showing up as UDMA/133. I thought that was an IDE standard. All drives are SATA and the MB BIOS is set to AHCI. In the syslog, the drive ST2000DL003-9VT166_6YD1Q84W (sda) is the one attached to the PCIe controller. The other three are attached to MB SATA ports. I note in the syslog (near the end) that IRQ #16 is being disabled and it appears to have something to do with the SATA drives. Running unRAID v5b14 Syslog attached. Any idea? Is my MB PCIe slot at fault. Syslog_-_Jan_12_13.doc

Yes, there is plenty of room on the other side of the SATA connector for an angle connector in that direction. The standard right-angle connector would not fit because the SATA port is right next to the Molex power connector.

Yeah that's the problem i'm finding with mini-ITX boards and this thread brought the board to my attention, hence my post. I really hope the x16 PCIe slot is not the problem. Although I have not yet determined that the PCIe slot on the Biostar board is a problem, I have been looking at alternatives just in case. I contacted Intel regarding the DH67CF mini-ITX board http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/desktop-board-dh67cf.html?wapkw=Dh67CF According to Intel, although the x16 PCIe slot is designed primarily for graphics cards, it will support any industry-standard PCIe card and not just graphics cards. It also (obviously) has an Intel NIC controller (82579V) and not the Realtek 8111E.

Hi, I am planning a build using the same case & motherboard. If you don't mind, could you please post the make & model of the controller card you are using? Thanks in advance, Andi I used the SYBA SY-PEX40048 controller which is an x4 PCIe controller and has 4 SATA II ports. It's based on the Marvell 88SX7042 chipset. Other PCIe x4 controllers using this same chipset are the Rosewill RC-218 and the Adaptec 1430SA (you can find both at Newegg). I have a bit of a problem right now with drives attached to this controller in that write speed to these drives is significantly lower than to drives attached to the MB SATA ports. This is not a general problem with all Marvell 88SX7042-based controllers as all three of the above mentioned cards have been used successfully by unRAID users with no issues. I am trying to find a way to check the BIOS configuration/update the BIOS etc. You also have to be careful in selecting a mini-ITX MB as some only support video cards in the x16 PCIe slot. There is no mention of this restriction in the Biostar TH61-ITX manual, product page or support forums, so, I hope that is not the problem I am having right now.