Print Page | Close Window

ASRock 970M Pro3 dual-boot quirks

Printed From: ASRock.com
Category: Technical Support
Forum Name: AMD Motherboards
Forum Description: Question about ASRock AMD motherboards
URL: https://forum.asrock.com/forum_posts.asp?TID=1548
Printed Date: 22 Dec 2024 at 4:51pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com


Topic: ASRock 970M Pro3 dual-boot quirks
Posted By: PetrolHead
Subject: ASRock 970M Pro3 dual-boot quirks
Date Posted: 18 Dec 2015 at 10:23am
I've experienced some strange behaviour related to dual-booting, so I thought I'd share. Neither of these issues really bother me anymore, since I've found a workaround, but I'd still like to know what might be the root cause of these issues.

Issue 1: Booting to Windows removes the Ubuntu boot option from BIOS/UEFI boot menu.

This is something I fought with for some time when I was setting up my system. After installing Windows 8.1 Pro 64-bit, I'd do all the necessary preparations (update Windows, disable secure boot etc.), install Linux Mint Cinnamon 17.2 64-bit and everyting seemed to be fine: Mint appeared in the BIOS/UEFI boot option list as Ubuntu (it's based on Ubuntu), choosing Ubuntu got me to the Grub menu and Mint started without issues. Reboot, do the same, no issues. However, if I booted to Windows from Grub, after a reboot the Ubuntu option no longer appeared in the BIOS/UEFI boot option list. It was as if Mint had never been installed. Re-install, retry and same result.

I first suspected that Windows had noticed the Ubuntu directory on the EFI partition, decided it didn't belong there and removed it. This was not the case, however. The EFI partition had all Linux related files intact. For some reason, the motherboard wasn't paying attention to the contents of the EFI partition. Asking for advice on a Linux Mint forum resulted in an explanation. Bootloader files are stored in the EFI partition, but it is the contents of NVRAM that tells the firmware which bootloader to use. It seemed that for some reason or another, Windows was messing around with the contents of NVRAM. The other possibility was a firmware bug (let's remember that the 970M Pro3 doesn't officially support any other OS than Windows). Luckily, there was a workaround.

What I needed to do in order to get my system to dual-boot was to use Windows' bcdedit to change the path of Windows' boot manager to that of Mint's boot manager. In other words, the BIOS/UEFI boot option for Windows now launches Mint's boot manager instead and from the Grub menu I can now launch both OSs without issues.

Issue 2: Corsair's CUE does not recognize my M65 RGB after booting to Linux and then back to Windows

I bought a new mouse a while back and noticed that every time I booted to Windows after using Linux, Corsair's software failed to initialize the mouse. Windows had no trouble recognizing a mouse was plugged in and the M65 still worked as a generic mouse, but the LED colours were stuck at the factory default, the polling rate was 125 Hz (1000 Hz normally) and I've no idea what the DPI value was. Rebooting the system did not help, but unplugging and replugging the mouse always did, even without a reboot. After this the mouse would work as it should as long as I didn't boot to Linux. All Windows drivers were up to date, the CUE was software was up to date and so was the mouse firmware.

The workaround for this issue was to stop using a USB 3.0 port and switch to a 2.0 (both rear panel ports, I didn't try the side panel USB ports on my case). The difference between these two is that the USB 3.0 ports are controlled by Etron's EJ188H and the USB 2.0 ports are controlled by AMD's chipset. Now, I hadn't installed Etron's own drivers for the USB controller, since I was released almost a year ago and I've read that some people have had more issues using Etron's own driver than the Windows driver. I don't know if those drivers would have solved the issue, but I found this workaround to be the easier and less risky option. Now I can boot to Linux and back to Windows and CUE finds the mouse without issues.

The behaviour of those USB 3.0 ports still puzzles me. I have no idea why booting to Linux would affect them and I have no idea, why they would work well enough for the mouse to work as a generic mouse, but not well enough for the CUE to succeed in initializing the mouse. Googling revealed that Etron has a bit of a history with bugs and speed issues, so it might be just another Etron issue. I don't know if a new driver or new firmware would help.

Slightly OT: My system's side panel USB ports are also controlled by Etron's EJ188H and sometimes my wireless keyboard, whose transmitter is plugged in one of the two USB 3.0 ports, would not work at all in Grub. In my case this meant the system would boot to Linux unless I pressed the restart button on the side panel. After booting to Linux the keyboard would, however, work normally. Rebooting would eventually resolve the issue, but sometimes only after several tries. This issue is intermittent and does not seem to occur solely after booting to Linux. I have not found a decent workaround for this, since the transmitter is not strong enough to work properly from the back panel USB ports.


-------------
Ryzen 5 1500X, ASRock AB350M Pro4, 2x8 GB G.Skill Trident Z 3466CL16, Sapphire Pulse RX Vega56 8G HBM2, Corsair RM550x, Samsung 960 EVO SSD (NVMe) 250GB, Samsung 850 EVO SSD 500 GB, Windows 10 64-bit



Replies:
Posted By: wardog
Date Posted: 18 Dec 2015 at 4:09pm
To #2, USB 2.0 is native to your motherboard and does not require a driver to load to be usable, whereas the eTron USB does require a driver to load before becoming usable.

You'll find most dongles for KB and mouse state to use a USB 2.0 port for this reason. Before USB 3.0, when there was only 2.0 and 1.1, most stated use 1.1. Seems like always a generation behind.

I too occasionally suffer from the not working wireless M/KB at boot and even sometimes when waking from sleep. My trick isn't to reboot but instead simply lift the dongle out of the port, count to three, reinsert it, and it always renegotiates. I use Logitech MK520 wireless mouse/keyboard combos here.


Posted By: PetrolHead
Date Posted: 18 Dec 2015 at 8:39pm
Slightly OT:

I also have the MK520 combo. I had to stop using the mouse, however, since using both mouse and keyboard caused terrible keyboard lag. I originally bought the combo for my Raspberry Pi and thought the lag was due to RPI being so slow, but the problem persisted on my current system. I'm not sure what USB controller the RPI uses, by the way. It could be Etron's for all I know. In any case, I switched the M310 mouse to an old wireless Logitech Click! Plus. It was a lot better mouse and the lag went away, but the Click! Plus also had a transmitter with an awful range. Since I wasn't able to take advantage of the lack of wire, I decided to get a wired mouse instead and upgrade to a "proper" gaming mouse at the same time. Then I ran into the CUE issue...


-------------
Ryzen 5 1500X, ASRock AB350M Pro4, 2x8 GB G.Skill Trident Z 3466CL16, Sapphire Pulse RX Vega56 8G HBM2, Corsair RM550x, Samsung 960 EVO SSD (NVMe) 250GB, Samsung 850 EVO SSD 500 GB, Windows 10 64-bit



Print Page | Close Window

Forum Software by Web Wiz Forums® version 12.04 - http://www.webwizforums.com
Copyright ©2001-2021 Web Wiz Ltd. - https://www.webwiz.net