| Summary: | DRI_PRIME regression- radeon: Failed to allocate virtual address for buffer | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | higuita | ||||||||||||||
| Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||||||||||||
| Status: | RESOLVED MOVED | QA Contact: | |||||||||||||||
| Severity: | normal | ||||||||||||||||
| Priority: | medium | CC: | bizyaev, samuel | ||||||||||||||
| Version: | XOrg git | ||||||||||||||||
| Hardware: | Other | ||||||||||||||||
| OS: | All | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
higuita
2017-09-15 20:01:29 UTC
(In reply to higuita from comment #0) > > > Finally, If i boot the system with radeon.runpm=1, it works > > Let me know if you need more logs runpm is enabled by default so specifying it shouldn't change anything. Please attach your xorg log and dmesg output. Sorry, radeon.runpm=0 does not work too, the card was powered off, so it was using Intel card Enabling the dedicated card still fails with the same error. the dmesg show this when enabling the card: [ 180.869486] radeon: switched on [ 180.898877] [drm] probing gen 2 caps for device 8086:9c18 = 5323c42/0 [ 180.898881] [drm] PCIE gen 2 link speeds already enabled [ 180.905022] [drm] PCIE GART of 2048M enabled (table at 0x0000000000040000). [ 180.905150] radeon 0000:06:00.0: WB enabled [ 180.905154] radeon 0000:06:00.0: fence driver on ring 0 use gpu addr 0x0000000080000c00 and cpu addr 0xffff891099a99c00 [ 180.905155] radeon 0000:06:00.0: fence driver on ring 1 use gpu addr 0x0000000080000c04 and cpu addr 0xffff891099a99c04 [ 180.905157] radeon 0000:06:00.0: fence driver on ring 2 use gpu addr 0x0000000080000c08 and cpu addr 0xffff891099a99c08 [ 180.905158] radeon 0000:06:00.0: fence driver on ring 3 use gpu addr 0x0000000080000c0c and cpu addr 0xffff891099a99c0c [ 180.905159] radeon 0000:06:00.0: fence driver on ring 4 use gpu addr 0x0000000080000c10 and cpu addr 0xffff891099a99c10 [ 181.613461] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD) [ 181.613478] [drm:si_resume [radeon]] *ERROR* si startup failed on resume Created attachment 134265 [details]
dmesg on boot
So sorry again :)
runpn=0 do work, but after doing "echo OFF > /sys/kernel/debug/vgaswitcheroo/switch" , it stop working
So attached adding the dmesg on boot and a dmesg after turning OFF and ON again the card. Also the Xorg.0.log, but it didn't output anything useful (some EDI modeset lines)
Created attachment 134266 [details]
dmesg after turning off and on the radeon card
Created attachment 134267 [details]
Xorg.0.log after the Off and On
(In reply to higuita from comment #0) > All this setup worked fine in a previous kernel versions, IIRC, 4.11 and > below and started to fail in 4.12 and above Any chance you can bisect between 4.11 and 4.12? I tried to downgrade the kernel to 4.11, 4.10 and 4.9 and i failed to enable DRI_PRIME on the dedicated card, always with the same error. I then tried to downgrade the mesa and libdrm to the distro original version and also, failed to enabled the card... So yes, the card worked in the past with DynPwr, but now i'm unable to enable it... Maybe some other update, firmware, whatever is also messing this. I do recall being able to boot one older kernel and have the card working, but booting with the more recent, it failed... all this around june I will try to boot from a liveCD, to try to get it working again and try to understand what else is causing this. Anyway, using runpm=0 works and the problems seems to be always with the kernel/atombios being unable to re-enable the card after shut it down Created attachment 134779 [details] [review] workaround to test Does this patch fix the issue? Yes, applying the patch, i can use the radeon card without the runpm=0. Also, turning OFF and ON the dedicated GPU now works fine So will kernel 4.14 will bring any fix to this? or you need more info about my system? just tested kernel 4.14.0 (without the above patch) and it still fails i will apply the patch again, as a workaround Can you verify that the Linux pci subsystem is properly calling the ACPI _PR3 method on your platform? The workaround just uses the legacy AMD ACPI interface. It appears pci is not calling _PR3 properly for some reason on your platform. Can you give me any pointer how to "call the ACPI _PR3 method"? i already install acpi_call, but have no idea how to use it (In reply to higuita from comment #13) > Can you give me any pointer how to "call the ACPI _PR3 method"? > > i already install acpi_call, but have no idea how to use it The pci core should be doing it for you since runtime pm support was added to pcie ports: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d26d3a8f1b0c442339a235f9508bdad8af91043 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=006d44e49a259b39947366728d65a873a19aadc0 Does adding: pcie_port_pm=force to the kernel command line in grub help? no, the with the pcie_port_pm=force and 4.14.0, it still fails Created attachment 136269 [details] [review] workaround to test To narrow things down further, does this patch also work? Sorry for the delay! yes, it works! After applying the patch, i can use the radeon card without the runpm=0 normally Can you attach your dmesg output? Created attachment 136810 [details]
Dmesg with patch
Here is the dmesg with the patch applied
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/821. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.