Major/Minor Opcodes of failed requests
admin at airblader.de
Wed Mar 30 18:48:52 UTC 2016
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.
On 03/30/2016 08:38 PM, Lloyd Brown wrote:
> 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.
> 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.
>> 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
>>>> X Error of failed request: BadAlloc (insufficient resources for
>>>> 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.
More information about the xorg