Hi there.
Let's see if anyone can help me solve a few oddities in regards of Linux and Windows dual-boot.
Tin Can #1:
- Gigabyte GA-990FXA-UD3 r4.0, latest BIOS
- AMD FX8350
- 16GB RAM (4x 4GB Corsair Vengeance DDR3-1600)
- Nvidia Titan X (yes, I know the card is overkill; my old GTX550Ti died and I had too much free cash)
- Linux Mint 17.1 / Windows 7 Ultimate x64
OS setup is like this: A 250GB Crucial MX100 SSD on SATA Port 0 containing Windows 7, a 2TB and a 3TB WD Green data drive on Port 1 and 2, a 256GB Crucial MX100 SSD on SATA Port 3 containing Linux Mint 17.1.
Dual-Boot happens via the "BIOS" boot menu - Windows doesn't know about the Linux drive - well, it knows about the drive being there but doesn't even dare to touch it - and in Linux I disabled GRUB's "OS_PROBER" to omit the Windows entry.
Now, both are working fine but there's a tiny issue that is driving me crazy because I can't track it down to the cause.
When I'm booted into Linux and I reboot the system to boot back into Windows (i.e. for playing some game) there's a >90% chance that while Windows will boot up perfectly fine it won't load the VIA USB 3.0 drivers. The Device Manager shows the "Hidden Device" entry and claims that the hardware isn't even there. o.O
Rebooting the thing doesn't resolve the problem... Windows won't load the VIA USB 3.0 drivers unless I power off, wait a few secs and then power on again... that's when Windows will suddenly be aware of the fact that the board does in fact have a USB 3.0 root hub.
Now, this doesn't happen when I reboot into the same OS. Rebooting Windows into Windows - no problem. Rebooting Linux into Linux - no problem. Rebooting to Linux from Windows - no problem. Rebooting to Windows from Linux ... Alzheimer's again.
I'm not sure if this is Windows being Windows or if it is Linux (as in the kernel) doing something incredibly stupid at rebooting the system hence maybe "hanging" the VT6401(?) root hub controller - any help in trying to track down the cause of the Alzheimer attack Windows is having when I boot into it from Linux would be highly appreciated.
On a related note, my second tin can is giving me some troubles when it comes to shared folders.
Tin Can #2:
- Gigabyte GA-970A-UD3
- AMD Phenom II X6 1100T
- 8GB RAM (4x 2GB Kingston DDR3-1333 Value RAM)
- Gigabyte WindForce GTX750Ti 2GB GDDR5
- Linux Mint 17.1 / Windows 8.1 Pro x64
This system is similar to the FX8350 above... 250GB Crucial BX100 SSD containing Windows 8.1 on SATA Port 0, 2TB WD Green data drive on SATA Port 1, 250GB Crucial BX100 SSD containing Linux Mint on SATA Port 2.
Here the trouble is related to shared folders mounted from the FX8350 box.
No matter if the other box is booted into Windows 7 or Linux ... the moment I reboot the box Windows 8.1 keeps on claiming that the mounted shares can't connect. Disconnecting the share and trying to add a new share doesn't work either; Windows 8.1 keeps on telling me that the host can't be found (though it's fully back up and I can see it announcing on the network by capturing with WireShark). Funnily enough, Syncthing does see the other host and syncing works - and even pinging the host by name works - its just "Windows File- and Printersharing" being a moron.
The problem resolves itself once I reboot Windows 8.1 ... though that's a wee bit of a "hardcore" approach to a problem that shouldn't even be there in the first place.
Linux and Windows, on the FX8350, export the same shares (the two data drives) on the same hostname with the very same sharenames in the very same workgroup for the very same users (I know my way around in Linux/Samba ... "Linux N00b since 1995").
Needless to say that this problem doesn't even exist when both tin cans are booted into Linux?
Any ideas what could be the cause of Windows 8.1 acting up?
By the way, I actually slightly modified the kernel commandline on the FX8350 box to prevent a "AMD-V" related error by setting "iommu=pt" (if I leave it at the default "Lazy I/O TLB flush" setting syslog will be spammed with AMD-V related errors once the proprietary Nvidia driver is in use ... according to my research I did back in the days there are also systems out there where the error shows up with the Realtek Gigabit NIC driver when the iommu isn't set "pt" (Pass-Through). Other than that the grub/kernel configuration isn't altered ... well ... other than the additional 1920x1080x32 setup for the framebuffer to fix the "broken plymouth boot-splash" problem.