Bug#822665: bumblebee: reports wrong error message from Xorg log

2016-05-14 Thread Luca Boccassi
Control: forwarded -1 https://github.com/Bumblebee-Project/Bumblebee/issues/652
Control: tags -1 pending

On 26 April 2016 at 15:13,  <ydir...@free.fr> wrote:
> No I just reported it to the bts as I saw it

I've sent a patch upstream to ignore the DRM error. Apparently it's
due to DRM, see:
https://github.com/Bumblebee-Project/Bumblebee/issues/652
I'll also backport it as a patch since it's a very annoying red herring.

Besides this, do you have other issues with Bumblebee or is it working?

Kind regards,
Luca Boccassi

> - Mail original -
>> De: "Luca Boccassi" <luca.bocca...@gmail.com>
>> À: ydir...@free.fr, 822...@bugs.debian.org
>> Envoyé: Mardi 26 Avril 2016 11:28:29
>> Objet: Re: Bug#822665: bumblebee: reports wrong error message from Xorg log
>>
>> Control: tags -1 upstream
>>
>> On Tue, 2016-04-26 at 10:17 +0200, ydir...@free.fr wrote:
>> > Package: bumblebee
>> > Version: 3.2.1-10
>> >
>> > When trying to use bumblebee those days, the reported failure is:
>> >
>> > $ optirun xterm
>> > [42519.843834] [ERROR]Cannot access secondary GPU - error: [XORG]
>> > (EE) /dev/dri/card0: failed to set DRM interface version 1.4:
>> > Permission denied
>> >
>> > [42519.843864] [ERROR]Aborting because fallback start is disabled.
>> > $
>> >
>> > Looking in Xorg.8.log, we can see:
>> >
>> > [ 42519.553] (II) xfree86: Adding drm device (/dev/dri/card1)
>> > [ 42519.840] (II) xfree86: Adding drm device (/dev/dri/card0)
>> > [ 42519.840] (EE) /dev/dri/card0: failed to set DRM interface
>> > version 1.4: Permission denied
>> > [ 42519.841] (--) PCI:*(0:1:0:0) 10de:139b:1462:1139 rev 162, Mem @
>> > 0xa200/16777216, 0xc000/268435456, 0xd000/33554432,
>> > I/O @ 0x4000/128, BIOS @ 0x/524288
>> > ...
>> > [ 42519.843] (II) [drm] nouveau interface version: 1.3.1
>> > [ 42519.843] (EE) Unknown chipset: NV117
>> > [ 42519.843] (EE) No devices detected.
>> > [ 42519.843] (EE)
>> > Fatal server error:
>> > [ 42519.843] (EE) no screens found(EE)
>> >
>> > The "permission denied" is quite strange, as the device does have
>> > the ACL allowing RW for the current user.
>> > But anyway that card is already used by :0, could it be that the
>> > error code returned by the DRI device is
>> > just wrong (EPERM instead of EBUSY) ?
>> >
>> > Anyway, that error does not appear to be fatal to Xorg, which does
>> > list the second one as fatal,
>> > and incidentally that error message looks like a much more
>> > understandable reason
>>
>> Hi,
>>
>> Yes unfortunately very often bumblebee errors are a bit misleading or
>> hard to interpret :-(
>> Have you reported this upstream?
>>
>> Kind regards,
>> Luca Boccassi
>>



Bug#822665: bumblebee: reports wrong error message from Xorg log

2016-04-26 Thread ydirson
No I just reported it to the bts as I saw it

- Mail original -
> De: "Luca Boccassi" <luca.bocca...@gmail.com>
> À: ydir...@free.fr, 822...@bugs.debian.org
> Envoyé: Mardi 26 Avril 2016 11:28:29
> Objet: Re: Bug#822665: bumblebee: reports wrong error message from Xorg log
> 
> Control: tags -1 upstream
> 
> On Tue, 2016-04-26 at 10:17 +0200, ydir...@free.fr wrote:
> > Package: bumblebee
> > Version: 3.2.1-10
> > 
> > When trying to use bumblebee those days, the reported failure is:
> > 
> > $ optirun xterm
> > [42519.843834] [ERROR]Cannot access secondary GPU - error: [XORG]
> > (EE) /dev/dri/card0: failed to set DRM interface version 1.4:
> > Permission denied
> > 
> > [42519.843864] [ERROR]Aborting because fallback start is disabled.
> > $
> > 
> > Looking in Xorg.8.log, we can see:
> > 
> > [ 42519.553] (II) xfree86: Adding drm device (/dev/dri/card1)
> > [ 42519.840] (II) xfree86: Adding drm device (/dev/dri/card0)
> > [ 42519.840] (EE) /dev/dri/card0: failed to set DRM interface
> > version 1.4: Permission denied
> > [ 42519.841] (--) PCI:*(0:1:0:0) 10de:139b:1462:1139 rev 162, Mem @
> > 0xa200/16777216, 0xc000/268435456, 0xd000/33554432,
> > I/O @ 0x4000/128, BIOS @ 0x/524288
> > ...
> > [ 42519.843] (II) [drm] nouveau interface version: 1.3.1
> > [ 42519.843] (EE) Unknown chipset: NV117
> > [ 42519.843] (EE) No devices detected.
> > [ 42519.843] (EE)
> > Fatal server error:
> > [ 42519.843] (EE) no screens found(EE)
> > 
> > The "permission denied" is quite strange, as the device does have
> > the ACL allowing RW for the current user.
> > But anyway that card is already used by :0, could it be that the
> > error code returned by the DRI device is
> > just wrong (EPERM instead of EBUSY) ?
> > 
> > Anyway, that error does not appear to be fatal to Xorg, which does
> > list the second one as fatal,
> > and incidentally that error message looks like a much more
> > understandable reason
> 
> Hi,
> 
> Yes unfortunately very often bumblebee errors are a bit misleading or
> hard to interpret :-(
> Have you reported this upstream?
> 
> Kind regards,
> Luca Boccassi
> 



Bug#822665: bumblebee: reports wrong error message from Xorg log

2016-04-26 Thread Luca Boccassi
Control: tags -1 upstream

On Tue, 2016-04-26 at 10:17 +0200, ydir...@free.fr wrote:
> Package: bumblebee
> Version: 3.2.1-10
> 
> When trying to use bumblebee those days, the reported failure is:
> 
> $ optirun xterm
> [42519.843834] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) 
> /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
> 
> [42519.843864] [ERROR]Aborting because fallback start is disabled.
> $ 
> 
> Looking in Xorg.8.log, we can see:
> 
> [ 42519.553] (II) xfree86: Adding drm device (/dev/dri/card1)
> [ 42519.840] (II) xfree86: Adding drm device (/dev/dri/card0)
> [ 42519.840] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: 
> Permission denied
> [ 42519.841] (--) PCI:*(0:1:0:0) 10de:139b:1462:1139 rev 162, Mem @ 
> 0xa200/16777216, 0xc000/268435456, 0xd000/33554432, I/O @ 
> 0x4000/128, BIOS @ 0x/524288
> ...
> [ 42519.843] (II) [drm] nouveau interface version: 1.3.1
> [ 42519.843] (EE) Unknown chipset: NV117
> [ 42519.843] (EE) No devices detected.
> [ 42519.843] (EE) 
> Fatal server error:
> [ 42519.843] (EE) no screens found(EE) 
> 
> The "permission denied" is quite strange, as the device does have the ACL 
> allowing RW for the current user.
> But anyway that card is already used by :0, could it be that the error code 
> returned by the DRI device is
> just wrong (EPERM instead of EBUSY) ?
> 
> Anyway, that error does not appear to be fatal to Xorg, which does list the 
> second one as fatal,
> and incidentally that error message looks like a much more understandable 
> reason

Hi,

Yes unfortunately very often bumblebee errors are a bit misleading or
hard to interpret :-(
Have you reported this upstream?

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part


Bug#822665: bumblebee: reports wrong error message from Xorg log

2016-04-26 Thread ydirson
Package: bumblebee
Version: 3.2.1-10

When trying to use bumblebee those days, the reported failure is:

$ optirun xterm
[42519.843834] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) 
/dev/dri/card0: failed to set DRM interface version 1.4: Permission denied

[42519.843864] [ERROR]Aborting because fallback start is disabled.
$ 

Looking in Xorg.8.log, we can see:

[ 42519.553] (II) xfree86: Adding drm device (/dev/dri/card1)
[ 42519.840] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 42519.840] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: 
Permission denied
[ 42519.841] (--) PCI:*(0:1:0:0) 10de:139b:1462:1139 rev 162, Mem @ 
0xa200/16777216, 0xc000/268435456, 0xd000/33554432, I/O @ 
0x4000/128, BIOS @ 0x/524288
...
[ 42519.843] (II) [drm] nouveau interface version: 1.3.1
[ 42519.843] (EE) Unknown chipset: NV117
[ 42519.843] (EE) No devices detected.
[ 42519.843] (EE) 
Fatal server error:
[ 42519.843] (EE) no screens found(EE) 

The "permission denied" is quite strange, as the device does have the ACL 
allowing RW for the current user.
But anyway that card is already used by :0, could it be that the error code 
returned by the DRI device is
just wrong (EPERM instead of EBUSY) ?

Anyway, that error does not appear to be fatal to Xorg, which does list the 
second one as fatal,
and incidentally that error message looks like a much more understandable reason