On Friday 21 Nov 2014 15:24:43 Alan McKinnon wrote: > 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). > > > >>> 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.
On a Dell XPS laptop on occasions I used to find that there was no sound. If I booted into MSWindows the OS would reset the sound, without having to login to a desktop and all would be fine thereafter. Quite a random event, but thankfully I haven't had this problem for a few months now. Perhaps the alsa drivers got better with time. Now if this Radeon kernel regression problem were to go away too so that I can hibernate, I would be quite happy. :-p -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
