Re: (64-bit) linux 3.10 and nouveau oddity
On Friday, November 08, 2013 06:13:44 AM berenger.morel@neutralite.org wrote:
> Le 05.11.2013 21:26, Neal Murphy a écrit :
> > Is it fair to say this is a bug? In *something*? Or just an
> > incompatibility
> > between Wheezy and the newer kernel?
>
> It is indeed a bug, if it was known to work previously.
> I would have thought about a nouveau bug, but by reading the logs, I do
> not know... lot of non graphic-related stuff failing too.
>
> I think to ensure that it's not nouveau's bug, you can try to use
> another driver, like, say, fbdev or vesa. Things will be slower of
> course, since there won't be as efficient hardware acceleration, but if
> it is nouveau's bug, the behavior will disappear. Otherwise, it could be
> xorg, but I strongly doubt it, or the kernel itself, which is more
>
> probable since even non graphical stuff are buggy according to the log:
> > Nov 5 13:12:11 playground dbus[3133]: [system] Activating service
> > name='org.freedesktop.NetworkManager' (using servicehelper)
> > Nov 5 13:12:11 playground dbus[3133]: [system] Activated service
> > 'org.freedesktop.NetworkManager' failed: Launch helper exited with
> > unknown
> > return code 1
>
> Or maybe the org.freedesktop.NetworkManager service is linked with
> xorg-dbus? With a lot of modern applications comes strange
> dependencies... and so wrong designs, but that's another problem that
> can't be fixed :)
Hmmm. It ain't doin' it now. On either 3.2 or 3.10 kernels. The only system
change: I removed two sticks of RAM. Which seems to have stabilized my system.
I guess my mainboard just can't handle having all four slots filled and was
giving random errors.
But I did uncover a potential bug in top(). Start it and hit '1' to show all
the CPUs. Then stop all but CPU-0 (which you can't stop anyway). top()
dutifully removes the extra CPUs. Now re-enable the other CPUs and see that
top doesn't resume displaying the other CPUs.
Reply to: