Z97 extreme6 slooooow boot |
Post Reply | Page <1234> |
Author | |
Xaltar
Moderator Group Joined: 16 May 2015 Location: Europe Status: Offline Points: 25043 |
Post Options
Thanks(0)
|
Lacking the understanding needed to help I saw no point in posting arbitrary non helpful advice. I am not familiar with the intricacies of how the linux kernl and boot loader operate and had nothing of use to offer.
In your situation I would try and rule out hardware being the issue by doing as I stated, install windows and see if your ports fail there too. If that is the case then your particular board may have a defect or BIOS issue in which case an BIOS update or RMA would be warranted. Given the issue arises only when you perform an update it is fairly clear that Linux is making a change to the UEFI that is causing this problem. It may be enabling or disabling legacy USB support for example or any number of inaccessible, hidden controls within the UEFI that can only be set by the OS. I think the misunderstanding here is stemming from the fact that you were not aware of how much the OS interacts with the UEFI. We understand what you are saying and are trying to provide info as to what we think may be the issue.
We sadly do not have any linux gurus here, or at least none that post regularly. You have to understand that this is not tech support, it is a support forum that is largely responded to by the community and on rare occasion a representative from ASRock's Tech department when there is a major update or common problem that they feel needs to be addressed, like the non-Z overclocking and windows 10 issues recently. This means that the advice shared is restricted to the knowledge base of the community. For dedicated Tech Support you should use the official support page to send a support request. The forums are a supplementary service that allows users to help each other out with common issues or non manufacturer based faults. Even the moderators here are community members, we are not in the employ of ASRock. Given your issue is regarding how the OS is changing settings in the UEFI, Tech Support may well be able to help you as it is UEFI related. I can't say for certain but it is worth a shot. |
|
jglynn43
Newbie Joined: 17 Sep 2015 Location: Hardin, IL USA Status: Offline Points: 19 |
Post Options
Thanks(0)
|
Thanks for that reply. Really, I mean it.
It's not so much as Linux as GRUB which gets updated. But here's the thing, even if GRUB is doing something wrong, which it may be, why can't I fix it even inside the BIOS config? And why does it only affect the Intel USB hub and not he ASMedia one? Or more generally, why is only USB effected? This is the cause of the slow boot BTW. The ports are there but they never respond.
|
|
Xaltar
Moderator Group Joined: 16 May 2015 Location: Europe Status: Offline Points: 25043 |
Post Options
Thanks(0)
|
Happy to try and help
As I said in my last post, there are more functions available in the UEFI than are present in the UI. Many of these features are only accessible by the OS/bootloader and are not alterable by the user. All kinds of things are determined by the UEFI and many of these settings could damage the system if the user were able to access them and alter them. The issue in your case seems to be stemming from the intel USB controller that is built into the chipset. As it is chipset based it is far more intricately connected to the UEFI than the Asmedia controller which has its own separate IC. It has been a long time since I delved into the inner workings of the BIOS but if I had to guess, GRUB may be trying to alter a setting related to bootable USB devices. This change is obviously not working correctly with ASRock's UEFI, possibly due to outdated coding in the GRUB system or because compatibility for your board is not properly implemented. Once you clear CMOS after an update the system functions as it should until another update is required. This is a good thing as it means the issue is likely external, stemming from something GRUB is changing. It should be easy to test if it is GRUB causing the issue by setting a hidden UEFI flag incorrectly. Next time you perform an update and the issue occurs (it may not if the update includes a fix for the issue) try resetting to factory defaults within your UEFI. If this works then the problem is likely a setting you have missed as it will reset all user alterable values. If it does not work but clear CMOS does then you know for certain the GRUB is altering something you cannot access. Clear CMOS resets all data including hidden registers and variables. This is the reason both exist and the further battery removal method will additionally reset the Real Time Clock or RTC as it is usually referred to. If this is the case then your best bet is posting your issue on your distro's user forums and seeing if anyone there can help you. You can try Tech Support here directly and they may be able to help you but bare in mind they are not obligated to do so given the issue stems from an unsupported OS. Generally though ASRock's tech support is very helpful and eager to resolve user issues whenever they can. I hope this helps clarify how intricately connected the OS, bootloaders and UEFI are.
|
|
wardog
Moderator Group Joined: 15 Jul 2015 Status: Offline Points: 6447 |
Post Options
Thanks(0)
|
What USB devices do you have plugged in?
Where plugged into? USB 2.0 and or 3.0 devices acting this way? Which ones? |
|
jglynn43
Newbie Joined: 17 Sep 2015 Location: Hardin, IL USA Status: Offline Points: 19 |
Post Options
Thanks(0)
|
@wardog -- just a keyboard and mouse and it's all the Intel USB ports except for the socket on the board next to the power switch. There must be something special about that one.
@Xalter -- that's the clearest explanation yet. I don't need to reset the BIOS to factory defaults because I never change anything there but I tried that anyway . It requires a CMOS reset to get the Intel ports working again. So it's not the hardware itself. At this point it *seems* to be a combination of GRUB setting something it shouldn't and ASRock UEFI letting it do something it shouldn't. Thank you. You've been very helpful.
|
|
Xaltar
Moderator Group Joined: 16 May 2015 Location: Europe Status: Offline Points: 25043 |
Post Options
Thanks(0)
|
Glad to be of help, hopefully your distro will address the issue if they are made aware of it
|
|
wardog
Moderator Group Joined: 15 Jul 2015 Status: Offline Points: 6447 |
Post Options
Thanks(0)
|
As an experiment, plug a couple short, 2' - 4', shielded USB 3.0 extension cables in, separate the ends out distance wise, and connect the KB and mouse to the cables.
I've yet to see the RF/EMI that USB 3 emits actually do what you explain, yet it is thoroughly possible due to sensitivity. Post back you findings please. |
|
jglynn43
Newbie Joined: 17 Sep 2015 Location: Hardin, IL USA Status: Offline Points: 19 |
Post Options
Thanks(0)
|
Thanks I will try that the next time it breaks. I never hurts to get more data.
I have everything working for now and I really don't want to intentionally cause a fault. My desktop is mounted inside a wooden cabinet so it's a real PITA to disassemble it and reset it. Besides I already know that if I run the GRUB installer (which happens every time there is a kernel update) this problem recurs. In fact, the last break was due to uninstalling an old kernel. So, it was the same exact kernel and just running GRUB to remove an older unused one caused the fault. It's very repeatable but I don't want to repeat it again unless I have to. Only once of the five times this has happened was I able to *just* clear the CMOS and have everything work. The other times I've had to disconnect all the drives and remove my video card, clear it and then re-assemble it. Clearing the CMOS seems to be like driving a tack with a sledgehammer. This may explain some of my obvious frustration in earlier posts. If I have offended anyone, I am sorry. I still don't know if GRUB is the culprit or merely the catalyst and I don't want to point fingers anyway. I'm just trying to get as much information out as I can. This is a real issue. Who's issue it belongs to is still open and to me irrelevant. I'm not a GRUB developer or a firmware engineer so who get's the workaround doesn't matter to me.
|
|
wardog
Moderator Group Joined: 15 Jul 2015 Status: Offline Points: 6447 |
Post Options
Thanks(0)
|
I'm thinking kernel changes and or that it's located in a wooden box are a catalyst that exaggerates/exasperates the RF/EMI.
As you imply, the mouse is the affected device. As might be expected, due to the great amount of info traveling along the mouses cable as you move it to and fro and click this and that, RF/EMI could very well be the interruption that begins your woes. The mouse would be more succeptable to this when compared to a keyboards simple instructions sent down the cable. Does your KB have USB ports on it? Are you using a USB hub somewhere? Hardwired networking, or a USB Wi-Fi adapter/dongle? A USB Wi-Fi adapter could be along the same lines, RF/EMI, considering it's in a wooden box! Too bad you have these two plugged into the 3.0 ports instead of the usual 2.0 ports. You might maybe could have simply entered the BIOS to disable the 3.0 ports as a test. |
|
jglynn43
Newbie Joined: 17 Sep 2015 Location: Hardin, IL USA Status: Offline Points: 19 |
Post Options
Thanks(0)
|
lolwhat?
Dude if you think wood cages influence RFI you need to talk to Mr Faraday. Maybe if it was ironwood ... I think you mean well but you're tilting at the wrong windmill here. I will try your experiment when it breaks again because why not, it's already broken.
|
|
Post Reply | Page <1234> |
Tweet
|
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |