bonustreats Posted February 2, 2017 Author Share Posted February 2, 2017 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! Quote Link to comment
John_M Posted February 3, 2017 Share Posted February 3, 2017 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. Quote Link to comment
bonustreats Posted February 22, 2017 Author Share Posted February 22, 2017 (edited) 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, 2017 by bonustreats Quote Link to comment
John_M Posted February 22, 2017 Share Posted February 22, 2017 6.3.2 has a different kernel so maybe that made the difference. Quote Link to comment
bonustreats Posted February 25, 2017 Author Share Posted February 25, 2017 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 Quote Link to comment
Marv Posted February 25, 2017 Share Posted February 25, 2017 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. Quote Link to comment
Squid Posted February 25, 2017 Share Posted February 25, 2017 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. Quote Link to comment
JorgeB Posted February 25, 2017 Share Posted February 25, 2017 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, . Quote Link to comment
RobJ Posted February 26, 2017 Share Posted February 26, 2017 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. Quote Link to comment
Squid Posted February 26, 2017 Share Posted February 26, 2017 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.... Quote Link to comment
RobJ Posted February 26, 2017 Share Posted February 26, 2017 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. Quote Link to comment
Squid Posted February 26, 2017 Share Posted February 26, 2017 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 Quote Link to comment
JorgeB Posted February 26, 2017 Share Posted February 26, 2017 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. Quote Link to comment
bonustreats Posted March 1, 2017 Author Share Posted March 1, 2017 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. Quote Link to comment
Squid Posted March 1, 2017 Share Posted March 1, 2017 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 Quote Link to comment
bonustreats Posted March 1, 2017 Author Share Posted March 1, 2017 Just now, Squid said: Yes it will Meowlrighty, here they are - thanks for the quick reply! radagast-diagnostics-20170301-1835.zip Quote Link to comment
Squid Posted March 1, 2017 Share Posted March 1, 2017 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] Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.