ASRock 970M Pro3 dual-boot quirks

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.

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...