Radeon GPU card failing while barfing some "*ERROR* failed to bind X pages at 0x00000000"

shimmy00 · 09-28-2022, 11:36 PM

Quote:

Originally Posted by business_kid

From post #1, Looks like you're on a voyage of discovery. May I suggest discovering?

The manufacturer gives you this patched 5.10.66 kernel,but do you have the kernel source?

In the early 2000s, ATI/Radeon dropped linux support. In 2007, AMD who had bought ATI hired a few linux devs and started linux support for ATI/Radeon up again with their newer stuff. They never released a linux driver for old ATI stuff that I know of. So your 'Copyright 2005' card was never at any stage supported by linux. The AMD RS690M integrated graphics I bought in 2008 isn't supported at all either. I'd try for something later. They don't consider their ancient stuff at all, so you are better going at generic drivers than AMD specific code. You wouldn't want the r600 driver anyhow. Maybe r100 or r200, not even r300 (which I used for the RS690M). What Mesa Version do you have?

Yes, I have the kernel source. What do you suggest to do with it? I can't get the Mesa version because the only thing I've found after googling that gives you that is using glxinfo, and you can't do that if the display is not up.

mrmazda · 09-29-2022, 02:49 AM

Quote:

Originally Posted by shimmy00

I can't get the Mesa version because the only thing I've found after googling that gives you that is using glxinfo, and you can't do that if the display is not up.

Code:

> sudo dpkg -l | grep mesa
ii  libegl-mesa0:amd64                    22.0.1-1ubuntu2                         amd64        free implementation of the EGL API -- Mesa vendor library
ii  libgl1-mesa-dri:amd64                 22.0.1-1ubuntu2                         amd64        free implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-glx:amd64                 22.0.1-1ubuntu2                         amd64        transitional dummy package
ii  libglapi-mesa:amd64                   22.0.1-1ubuntu2                         amd64        free implementation of the GL API -- shared library
ii  libglu1-mesa:amd64                    9.0.2-1                                 amd64        Mesa OpenGL utility library (GLU)
ii  libglx-mesa0:amd64                    22.0.1-1ubuntu2                         amd64        free implementation of the OpenGL API -- GLX vendor library
ii  mesa-utils                            8.4.0-1ubuntu1                          amd64        Miscellaneous Mesa utilities -- symlinks
ii  mesa-utils-bin:amd64                  8.4.0-1ubuntu1                          amd64        Miscellaneous Mesa utilities -- native applications

business_kid · 09-29-2022, 04:57 AM

Right, you have the kernel source. Download a vanilla 5.10.66 kernel. Then you can find the patches for each area. Try this

Code:

diff -Naur /path/to/linux-5.10.66-vanilla/drivers/video/ /path/to/linux-5.10.66-patched/drivers/video/  -o my_video.patch

I hope programmers will jump in and correct errors. If they don't, that should recover the patch they applied to your video. So you can see what they have done.

shimmy00 · 09-29-2022, 05:36 PM

Quote:

Originally Posted by mrmazda

Code:

> sudo dpkg -l | grep mesa
ii  libegl-mesa0:amd64                    22.0.1-1ubuntu2                         amd64        free implementation of the EGL API -- Mesa vendor library
ii  libgl1-mesa-dri:amd64                 22.0.1-1ubuntu2                         amd64        free implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-glx:amd64                 22.0.1-1ubuntu2                         amd64        transitional dummy package
ii  libglapi-mesa:amd64                   22.0.1-1ubuntu2                         amd64        free implementation of the GL API -- shared library
ii  libglu1-mesa:amd64                    9.0.2-1                                 amd64        Mesa OpenGL utility library (GLU)
ii  libglx-mesa0:amd64                    22.0.1-1ubuntu2                         amd64        free implementation of the OpenGL API -- GLX vendor library
ii  mesa-utils                            8.4.0-1ubuntu1                          amd64        Miscellaneous Mesa utilities -- symlinks
ii  mesa-utils-bin:amd64                  8.4.0-1ubuntu1                          amd64        Miscellaneous Mesa utilities -- native applications

Thanks. That's what I thought and tried it but wasn't sure it was useful since all the gl and glx packages seem versioned just by the Ubuntu version - what I get is:

Code:

ii  libegl-mesa0:arm64                         20.0.4-2ubuntu1                            arm64        free implementation of the EGL API -- Mesa vendor library
ii  libgl1-mesa-dri:arm64                      20.0.4-2ubuntu1                            arm64        free implementation of the OpenGL API -- DRI modules
ii  libglapi-mesa:arm64                        20.0.4-2ubuntu1                            arm64        free implementation of the GL API -- shared library
ii  libglu1-mesa:arm64                         9.0.1-1build1                              arm64        Mesa OpenGL utility library (GLU)
ii  libglx-mesa0:arm64                         20.0.4-2ubuntu1                            arm64        free implementation of the OpenGL API -- GLX vendor library
ii  mesa-utils                                 8.4.0-1build1                              arm64        Miscellaneous Mesa GL utilities
ii  mesa-vulkan-drivers:arm64                  20.0.4-2ubuntu1                            arm64        Mesa Vulkan graphics drivers

shimmy00 · 09-29-2022, 05:38 PM

Quote:

Originally Posted by business_kid

Right, you have the kernel source. Download a vanilla 5.10.66 kernel. Then you can find the patches for each area. Try this

Code:

diff -Naur /path/to/linux-5.10.66-vanilla/drivers/video/ /path/to/linux-5.10.66-patched/drivers/video/  -o my_video.patch

I hope programmers will jump in and correct errors. If they don't, that should recover the patch they applied to your video. So you can see what they have done.

What are you thinking of when it comes to using those patches? (Esp. given if we already have a patched kernel, why can't we bring up the Mali processor for either X [think I have another thread on this site about that] or console fb?)

business_kid · 09-30-2022, 03:57 AM

IME, most of the issues will come from those, which are not of the same verified quality as the rest of the kernel. The comments can also be useful, and the same patches can be applied to another (earlier or later) kernel.

By all means bring up another GPU if it's available (which I didn't see mention of earlier

)

shimmy00 · 10-01-2022, 12:02 AM

Quote:

Originally Posted by business_kid

IME, most of the issues will come from those, which are not of the same verified quality as the rest of the kernel. The comments can also be useful, and the same patches can be applied to another (earlier or later) kernel.

By all means bring up another GPU if it's available (which I didn't see mention of earlier

)

Yes, it has two GPUs now - I got the Radeon because the other (Mali) was not supported and I couldn't even make the stock image kernel work with it when put under a non-stock surrounding distribution. Also, I have started some threads with the kernel development community about possibly helping to get this code into the mainstream kernels - the problem is that they actually don't always carry over in an absolutely straightforward way in all cases I've found in some dabbling therewith, because of various changes to the kernel coding that have happened since 5.10.66. Even more, I can't even bring up a later kernel on this specific board even though the newest kernels supposedly have enough RK3588 support to at least do basic bring-up, but that's a different issue from that under consideration here. (Something about some quirk of the board, I bet, is causing the kernel to goof up at the very earliest stages of initialization, having "ITS queue timeout" stuff with the IRQchip subsystem which seems far more fundamental.)

business_kid · 10-01-2022, 06:53 AM

So really, this is a software development thread, and not a thread about a usually working pc & OS that should work but don't? That certainly wasn't clear from your early posts, although to be fair, you warned us about the patched kernel.

If you're going to try a second graphics card, use a 100% supported one, if you want my advice. I'd advertise your Radeon card on Ebay unless you have a need for it. Get on the relevant support forum, and post & contribute there. This is a general hardware forum, but your hardware seems newish & good. Your headache is software.

shimmy00 · 10-01-2022, 06:26 PM

Quote:

Originally Posted by business_kid

So really, this is a software development thread, and not a thread about a usually working pc & OS that should work but don't? That certainly wasn't clear from your early posts, although to be fair, you warned us about the patched kernel.

If you're going to try a second graphics card, use a 100% supported one, if you want my advice. I'd advertise your Radeon card on Ebay unless you have a need for it. Get on the relevant support forum, and post & contribute there. This is a general hardware forum, but your hardware seems newish & good. Your headache is software.

Thanks, it felt rather ambiguous at the start but I guess it evolved in that direction.

business_kid · 10-02-2022, 04:37 AM

Question: Is the Firefly box anything similar to the RockPi 3 3588 or RockPi 5 3588? The only firefly release is for the firefly-3399.

Particularly if the Mali GPU is part of the 3588 chip, you have choices. Slarm64 has releases from last summer for the RockPi 3 3588 & RockPi 5 3588. They're using Slackware x86_64 kernel builds. I've seen 3.x, 4.x, & 5.19-rc6 kernel releases up there. They're released as Binary images, although he will have packages somewhere. You can just dd them onto your MMC card and it boots.

I typically increase the size of /, as there's usually only about 500k of free space. It's also good to install missing packages (for example the development stuff in d/) and add a 3rd /home partition. But his work on the RazPi is excellent, porting upstream patches, etc.

It's only slightly more work to get it on SSD. You will have to get to know (if not love) Slackware. But the kernels are certainly worth a try.

EDIT: The packages are all identical for Arm64, but the boot stuff is wildly different in each SBC.

shimmy00 · 10-02-2022, 05:47 PM

Quote:

Originally Posted by business_kid

Question: Is the Firefly box anything similar to the RockPi 3 3588 or RockPi 5 3588? The only firefly release is for the firefly-3399.

Particularly if the Mali GPU is part of the 3588 chip, you have choices. Slarm64 has releases from last summer for the RockPi 3 3588 & RockPi 5 3588. They're using Slackware x86_64 kernel builds. I've seen 3.x, 4.x, & 5.19-rc6 kernel releases up there. They're released as Binary images, although he will have packages somewhere. You can just dd them onto your MMC card and it boots.

I typically increase the size of /, as there's usually only about 500k of free space. It's also good to install missing packages (for example the development stuff in d/) and add a 3rd /home partition. But his work on the RazPi is excellent, porting upstream patches, etc.

It's only slightly more work to get it on SSD. You will have to get to know (if not love) Slackware. But the kernels are certainly worth a try.

EDIT: The packages are all identical for Arm64, but the boot stuff is wildly different in each SBC.

Thanks. Will see if that works. It has the same RK3588 SoC, so maybe it will go.

business_kid · 10-03-2022, 04:13 AM

I know nothing about either firefly or rock pi, but each has a probably unique boot system. The RazPi is really half-assed, having to download firmware via serial with the gpu before running the cpu proper.

So you stand ready to transpose or copy over your boot stuff. The initrd & kernel will come from slarm64, & make any needed mods. Enjoy!

slackguy2 · 10-09-2022, 04:02 AM

[ 17.218136] [drm:radeon_ttm_backend_bind [radeon]] *ERROR* failed to bind 16 pages at 0x00000000
[ 17.218259] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to allocate GEM object (65536, 2, 4096, )

THAT MEANS WHAT IT SAYS. It wants to load pages at 0 and is not allowed (perhaps the kernel or something else already allocated it). It probably means the kernel DRM or the Xorg/Wayland module was COMPILED INCORRECTLY.

However note: don't load the linux-kernel support for your card if you are PCI it can mess things up for pci.

As far as the kernel message, idk, the warning really says nothing.

you haven't mentioned the important part: if you checked the hardware compatibility list of the linux kernel (if agp) and of Xorg/Wayland and if the drivers said your card and model are suported. without that your wasting time.

return the card before 30days is expired or throw it away

You need an nVidia (video driver that just always works) or to use the (not as fast 3D) video card built-in to your iCore Intel chip

slackguy2 · 10-09-2022, 04:03 AM

sorry to Radeon fans. I didn't mean to say there are not new Radeons which work well. I don't know which to suggest or if.

business_kid · 10-09-2022, 04:49 AM

There's also the little matter whether it's trying to load at 0x00h in GPU memory or in normal memory.

The latter was a favourite ploy by hackers. Engineer a buffer overrun, and have an Assembler instruction like "Goto 0" above the buffer. But every step was cut off by software. Buffers have 'canaries' to prevent overrun. The kernel won't let you near low memory.