February 2, 20179 yr Author Yes, that's correct. Everything about your array is stored on the boot flash. I hadn't heard that little gem about jumping too many BIOS versions. That really stinks. I've never owned an Intel motherboard and I wouldn't buy one, knowing that. I like Asus and Gigabyte, personally. I'm sorry this has become such a pain for you. Ha - I wouldn't ever again either, now. That thread said they got out of the mobo game in 2013, so hopefully you CAN'T in the future I've heard mixed things about Gigabyte, but (so far) no complaints about Asus, so I'll probably look into a replacement Asus board. Thanks for the support - it's pretty aggravating when stupid things like this crop up. Should I mark this thread as "Solved"? Or maybe "Closed" or something? Thanks everyone for your help and input!
February 3, 20179 yr Good luck with the new motherboard. I wouldn't bother marking the thread - it wasn't a very satisfactory conclusion so no point in raising other people's hopes if they're searching for help with a similar issue.
February 22, 20179 yr Author On 2/2/2017 at 7:31 PM, John_M said: Good luck with the new motherboard. I wouldn't bother marking the thread - it wasn't a very satisfactory conclusion so no point in raising other people's hopes if they're searching for help with a similar issue. It looks like other people are running into the same issue that I was (call trace errors, at least), and unfortunately, I am again. I got a new (to me) MB, processor, and RAM from a friend of mine early last week. Swapped everything over, and it booted right up, I couldn't quite believe how easy everything was. I went through and updated all my plug-ins, as well as went from 6.2.4 to 6.3.1. I ran into a bit of a snag trying to upgrade to 6.3.2, but figured it wasn't a big deal and would upgrade later. Parity check ran; everything seemed great again. Unfortunately, the same call trace error popped up in Fix Common Problems again. I ran the diagnostics to post this yesterday, but it seemed like the forum was down or something, so they're here now. I didn't do a windiff or anything, but it looks like the exact same error that came up before. I was able to upgrade to 6.3.2 and (so far) the issue hasn't resurfaced, so I'm not sure how useful the diagnostics are. However, that makes me wonder how the heck the same error could crop up with completely different hardware. Could it possibly be my flash drive? radagast-diagnostics-20170220-1301.zip Edited February 22, 20179 yr by bonustreats
February 25, 20179 yr Author On 2/21/2017 at 8:08 PM, John_M said: 6.3.2 has a different kernel so maybe that made the difference. I guess it hasn't, because it is now back again; same "irqpoll nobody cared" error. The question now is: is this a serious problem or just some kind of background process that's not going to hurt anything? radagast-diagnostics-20170225-1151.zip
February 25, 20179 yr Hi, I got my call traces error posted here before again aswell with v6.3.2: It's really strange as this all began with v6.3.0 and since then there were quiet a few people reporting this kind of error.
February 25, 20179 yr Just now, Marv said: Hi, I got my call traces error posted here before again aswell with v6.3.2: It's really strange as this all began with v6.3.0 and since then there were quiet a few people reporting this kind of error. The FCP's test for this coincided with the 6.3.0 release, so its not necessarily been caused by 6.3, but may have been going on for quite a while. As I said in a previous post, the call trace *may* be benign and harmless. Initially, if its an IRQ 16: nobody cared, then it may in fact be benign (after all, if nobody cared, then why should you ), especially if everything appears to be working good.
February 25, 20179 yr Community Expert IRQ getting disabled is bad if it's one used by a disk controller, performance will be terrible, as long as don't noticed any issues the one on USB ports like your case seem mostly harmless, .
February 26, 20179 yr 9 hours ago, Squid said: As I said in a previous post, the call trace *may* be benign and harmless. Initially, if its an IRQ 16: nobody cared ... Squid, if you detect an "IRQ * nobody cared", could you also provide them what lsirq reports, limited to that IRQ number? It lists the modules using an IRQ, so may be helpful. If it's a USB controller, probably won't matter, but if it were a drive controller (e.g. mvsas), then that would immediately explain why a set of drives have dropped or why I/O is extremely slow.
February 26, 20179 yr Just now, RobJ said: Squid, if you detect an "IRQ * nobody cared", could you also provide them what lsirq reports, limited to that IRQ number? It lists the modules using an IRQ, so may be helpful. If it's a USB controller, probably won't matter, but if it were a drive controller (e.g. mvsas), then that would immediately explain why a set of drives have dropped or why I/O is extremely slow. I've thought about trying to detect what causes the call trace, and then report that as the issue. Unfortunately it's not quite as easy as it might seem since there is no specific number of lines before the trace that states what caused it. IE: some traces have why 3 lines before, others 5-6 lines, etc. But, I think that if I find IRQ nobody cared within say 10 lines that should suffice....
February 26, 20179 yr 1 minute ago, Squid said: But, I think that if I find IRQ nobody cared within say 10 lines that should suffice.... I don't think most of the "IRQ nobody cared" actually have a Call Trace. Might have to be a separate detection.
February 26, 20179 yr 3 minutes ago, RobJ said: I don't think most of the "IRQ nobody cared" actually have a Call Trace. Might have to be a separate detection. Don't know. The current spate of them have all been reported because of a call trace found by FCP
February 26, 20179 yr Community Expert I don't think most of the "IRQ nobody cared" actually have a Call Trace. Might have to be a separate detection.Yes, I believe the ones I've seen with mvsas involved don't have a call trace, and those have a very negative impact on server performance.
March 1, 20179 yr Author On 2/25/2017 at 10:09 PM, Squid said: I've thought about trying to detect what causes the call trace, and then report that as the issue. Unfortunately it's not quite as easy as it might seem since there is no specific number of lines before the trace that states what caused it. IE: some traces have why 3 lines before, others 5-6 lines, etc. But, I think that if I find IRQ nobody cared within say 10 lines that should suffice.... I got an update to FCP, and ran a rescan - it's now showing the irq 16: nobody cared in the GUI, and it's telling me to post my diagnostics. Will posting the diagnostics now provide any new information compared to the one from Saturday? If so, I'll gladly post them. I haven't seen any particular issues of note; maybe some transfer speed reduction in some cases, but that might be related to the hard drive that's being used for that copy.
March 1, 20179 yr 13 minutes ago, bonustreats said: I got an update to FCP, and ran a rescan - it's now showing the irq 16: nobody cared in the GUI, and it's telling me to post my diagnostics. Will posting the diagnostics now provide any new information compared to the one from Saturday? If so, I'll gladly post them. I haven't seen any particular issues of note; maybe some transfer speed reduction in some cases, but that might be related to the hard drive that's being used for that copy. Yes it will
March 1, 20179 yr Author Just now, Squid said: Yes it will Meowlrighty, here they are - thanks for the quick reply! radagast-diagnostics-20170301-1835.zip
March 1, 20179 yr You should be safe to ignore it. Related to the USB only Quote Mar 1 18:14:06 Radagast root: 16: 50029 49957 50143 50136 IO-APIC 16-fasteoi ehci_hcd:usb1, ahci[0000:03:00.0]
Archived
This topic is now archived and is closed to further replies.