[bumblebee] 04/04: Update changelog for #815888

Luca Boccassi luca.boccassi at gmail.com
Sun May 8 21:29:02 UTC 2016


On Sun, 2016-05-08 at 17:21 +0100, Luca Boccassi wrote:
> On 1 May 2016 at 21:32, Luca Boccassi <luca.boccassi at gmail.com> wrote:
> > Also, I noticed I still hit the problem with bumblebee when switching
> > driver branch via update-glx --config nvidia: starting on current, all
> > works, moving to 340xx, all works, but try to move back to current and
> > it breaks because the legacy kernel module is still loaded. Restarting X
> > and bumblebeed doesn't solve it.
> 
> Andreas,
> 
> I finally figured this out! Wore down GDB in the process, but now we
> have a root cause :-)
> 
> Note that the problem is the opposite of what I said above, ie: the
> correct kernel module is loaded, but the wrong libglx is used by Xorg.
> 
> The configuration file we ship lists as the Xorg modules path:
> 
> XorgModulePath=/usr/lib/nvidia,/usr/lib/xorg/modules
> 
> This is correct, as the active driver's libglx.so and nvidia_drv.so
> are symlinked by update-alternatives in there.
> 
> But the reason the wrong libglx is loaded by Xorg is that the
> FindModule and FindModuleInSubdir functions in
> hw/xfree86/loader/loadmod.c do a depth-first search. Depending on the
> order in which the content of a directory is listed by the readdir
> syscall, if a subdirectory is returned, it will follow it instead of
> checking all the files in the current directory first.
> 
> For whatever reason, legacy-340xx is always listed by readdir -before-
> both current and libglx.so, so /usr/lib/nvidia/legacy-340xx/libglx.so
> is found before /usr/lib/nvidia/libglx.so.
> 
> A quick workaround is to pass /etc/alternatives/nvidia to bumblebee's
> XorgModulePath config variable, so that only the active driver
> subdirectory is searched, and there's no room for mistakes.
> 
> I will try and see if Xorg's upstream would be willing to accept
> changing the search to be breadth-first. Given it would change the
> current behaviour, I fear such a change might not be accepted.
> 
> So, I propose to upload the workaround first so that we fix the bug,
> and then if the problem is solved upstream in Xorg we can take it out.
> What do you think?
> 
> Funnily enough, while searching to see if others had reported this
> behaviour before, I found that you were poking in the exact same code
> paths a few years back :-)
> https://lists.debian.org/debian-x/2011/08/msg00157.html
> 
> Kind regards,
> Luca Boccassi

Sent patch upstream for xorg-server:

https://lists.x.org/archives/xorg-devel/2016-May/049629.html

Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20160508/3bd373dc/attachment.sig>


More information about the pkg-nvidia-devel mailing list