On 21/11/2014 17:08, behrouz khosravi wrote: > > On Nov 21, 2014 6:23 PM, "Matti Nykyri" <matti.nyk...@iki.fi > <mailto:matti.nyk...@iki.fi>> wrote: >> >> On Nov 21, 2014, at 16:15, behrouz khosravi <bz.khosr...@gmail.com > <mailto:bz.khosr...@gmail.com>> wrote: >> >>> >>> > Do you reboot in the between or are you running somekind of virtual > machine? Usb headphones or what? What sound driver? I've had problems > with NIC between reboots. They were cleared by removing power cord for > multiple minutes while rebooting. I got rid of the problem when i > updated NIC's driver (bug in driver). >>> > >>> > -- >>> > -Matti >>> >>> No. It happen every time I boot into linux. Gentoo or Arch. >>> removing power helps but is annoying. >>> its not usb, but I dont know what is called! the ordinary type! >>> Its a realtek chip . >>> The bug that you mentioned is related to linux driver or windows driver? >> >> >> I have realtek R6168/6111/6169 NIC. It works in Linux with realtek's > driver not with the one included in kernel. Windows fails to initialize > the NIC properly when I reboot from linux to windows. When NIC is reset > by recycling power windows will be able to initialize it. Downgrading > windows (7 64bit) dirver to an ancient one fixed the problem. The > up-to-date realtek driver didn't work correctly. >> >> lspci -v >> >> You can check what driver kernel uses for you audio. Also the bug can > be in alsa. The ways of alsa quite complicated... You are using alsa > right? What error message does alsa give when you try to play audio? > Well I have no problem with it in linux. It always works in linux but I > think there is a problem with alsa or some other linux related part. > Because I have enabled the after post sound in bios. When I power in on > the headphone work. Then I login to linux and when I reboot to login to > windows, the bios post sound does not come from headphone. > It seems something is wrong in the linux part!
This kind of thing is quite common actually, more so in days gone past. Speaking conceptually, what happens is something like this: Consider a driver for a hardware on any OS. That driver knows how it shuts down the hardware. It expects the hardware to be in the same state (registers, sleep state, etc) when powered back up; if so then all is good. There are supposed to be standards for these things and drivers are supposed to obey them to avoid these problems when booting other OSes (or even upgrading a driver that needs a reboot). One of your drivers (Windows or Linux) or the hardware itself is not obeying the standard, so Windows doesn't find the hardware in the state it expects and doesn't properly initialize the hardware. There are 3 ways this can go wrong: 1. The Linux driver is buggy (not 100% per spec) and doesn't shut down/power up the device properly. 2. Same with the Windows driver. 3. The hardware might not be per standard (the Windows driver will have been coded to work around it if this is the case). Usually, the Linux driver is coded per spec. Hardware often doesn't do what the spec says and Windows drivers are often shocking. It's not always true, but I find it's a good assumption to start from. You need to find a combination of various drivers in both OSes that work nice together and with the hardware. It's a trial and error process so unless someone has already solved this for you, expect to try lots of combinations. -- Alan McKinnon alan.mckin...@gmail.com
