Major/Minor Opcodes of failed requests

walter harms wharms at bfs.de
Thu Mar 31 07:11:02 UTC 2016


Just for my curiosity:
is there a function that translates major/minor in something readable ?

re,
 wh

Am 30.03.2016 20:48, schrieb Ingo Bürk:
> Hi Lloyd,
> 
> Adam already decoded the opcode for you. Just a quick Google search of
> request name + "BadAlloc" gives at least a few results. It might be
> worth checking those out. I'm not familiar with GLX, unfortunately.
> 
> 
> Regards
> Ingo
> 
> On 03/30/2016 08:38 PM, Lloyd Brown wrote:
>> Ingo,
>>
>> Thank you for this.
>>
>> Just for clarification, are we talking about system RAM or video card's RAM?
>>
>> The reason I ask is this.  Since we're an HPC lab, we do limit system
>> memory via memory cgroups, based on what the user's job requested.  But
>> since seeing your email, I've gone as high as 64GB in my request,
>> verified that the cgroup reflected that, and the problem still
>> occurred.  If we're talking about video card's RAM, we don't
>> artificially limit it at all, and the card in question is a Tesla K80,
>> which has 2 GPUs, and 12GB of video RAM per GPU.
>>
>> I wonder if there's some other limit going on, that I'm not aware of.
>>
>> Maybe it makes more sense to contact the Paraview software community, at
>> this point.  They may have a better idea where this could be going wrong.
>>
>> Thanks for the info, though.  It was exactly the sort of thing I was
>> hoping for.
>>
>> Lloyd
>>
>>
>>
>>
>> On 03/30/2016 12:18 PM, Ingo Bürk wrote:
>>> Hi Lloyd,
>>>
>>> see here: http://www.x.org/wiki/Development/Documentation/Protocol/OpCodes/
>>>
>>> In your case you are trying to allocate way too much memory. This can
>>> happen, for example, if you by accident try to create enormously large
>>> pixmaps. Of course there's many things that can cause this. Decoding the
>>> opcode will help you debug it.
>>>
>>>
>>> Regards
>>> Ingo
>>>
>>> On 03/30/2016 06:03 PM, Lloyd Brown wrote:
>>>> Can anyone help me understand where the error messages, especially the
>>>> major and minor opcodes, come from in an error like this one?  Are these
>>>> defined by Xorg, by the driver (Nvidia, in this case), or somewhere else
>>>> entirely?
>>>>
>>>>> X Error of failed request:  BadAlloc (insufficient resources for
>>>>> operation)
>>>>>   Major opcode of failed request:  135 (GLX)
>>>>>   Minor opcode of failed request:  34 ()
>>>>>   Serial number of failed request:  26
>>>>>   Current serial number in output stream:  27
>>>>>
>>>> So, here's the background.  I'm launching Xorg to manage the GLX context
>>>> for some processing applications.  When I use things like glxgears,
>>>> glxspheres64 (from the VirtualGL project), glxinfo, or glmark2,
>>>> everything works well.  But when I use the actual user application
>>>> (pvserver, part of Paraview), it gives me this error shortly after I
>>>> connect my paraview frontend, to the pvserver backend.
>>>>
>>>> Running the pvserver inside gdb, with a "break exit", lets me backtrace
>>>> it, but all it really tells me is that it's occurring when the
>>>> application is trying to establish it's context.
>>>>
>>>> I can continue to dink around with it, but if anyone can at least point
>>>> me in the right direction, that would be helpful.
>>>>
>>>> Thanks,
>>>>
> 
> _______________________________________________
> xorg at lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s


More information about the xorg mailing list