Bug 18154 - DRM support for addressing >32 bits on 32 bit cores
Summary: DRM support for addressing >32 bits on 32 bit cores
Status: RESOLVED INVALID
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/other (show other bugs)
Version: unspecified
Hardware: PowerPC Linux (All)
: high major
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-21 07:03 UTC by Steve Winiecki
Modified: 2019-10-14 13:20 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
libdrm support for addressing >32 bits on 32 bit cores - syslog w/ drm debug msgs (27.25 KB, text/plain)
2008-10-21 07:03 UTC, Steve Winiecki
no flags Details
Fix ttm_bus_placement.base type to accomodate >32 bit physical addresses (1.29 KB, patch)
2014-08-06 09:59 UTC, Andrej Krutak
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Winiecki 2008-10-21 07:03:50 UTC
Created attachment 19785 [details]
libdrm support for addressing >32 bits on 32 bit cores - syslog w/ drm debug msgs

Using git versions Xorg/Mesa/DRM built last week

Using a PPC 32-bit platform, with a 32 bit core and 36-bit addressing (460EX). The PCIe space is mapped physically above a 32 bit address range.  Have a radeon 1650 adapter plugged in the PCIe slot.

When enabling DRI - get the following Oops error:

------------------------
[drm:radeon_driver_open]
[drm:drm_addmap_core] offset = 0x98000000, size = 0x00010000, type = 1
[drm:drm_addmap_core] offset = 0x80000000, size = 0x10000000, type = 0
[drm:drm_addmap_core] offset = 0x00000000, size = 0x00002000, type = 2
[drm:drm_setup]
[drm:drm_ioctl] pid=2058, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1
[drm:drm_ioctl] pid=2058, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1
[drm:drm_release] open_count = 1
[drm:drm_release] pid = 2058, device = 0xe200, open_count = 1
[drm:drm_fasync] fd = -1, device = 0xe200
[drm:drm_lastclose]
Machine check in kernel mode.
Data Write PLB Error
Oops: Machine check, sig: 7 [#2]
Canyonlands
Modules linked in:
NIP: 00000000 LR: c01796ec CTR: 00000008
REGS: c039bf50 TRAP: 0202   Tainted: G      D   (2.6.25.7-00002-geaaf8db)
MSR: 00000000 <>  CR: 24000428  XER: 00000002
TASK = ded4d3f0[2058] 'X' THREAD: ded86000
GPR00: e93e0b0c ded87e60 ded4d3f0 dfaa7400 000040c1 ffffffff c018c924 00004000
GPR08: 00000000 e93e0b0c 00000000 e93e0000 24000422 101e6c34 101dec74 101def08
GPR16: 101e0000 101e0000 101e0000 101e0000 101e0000 101e0000 00000004 101e0000
GPR24: c03a0000 dfaa7618 dfaa760c dedb5a80 deddc580 dfaa7400 dfaa7400 dfaa7800
NIP [00000000] 0x0
LR [c01796ec] radeon_driver_lastclose+0x40/0x74
Call Trace:
[ded87e60] [c001eacc] printk+0x50/0x60 (unreliable)
[ded87e80] [c01796ec] radeon_driver_lastclose+0x40/0x74
[ded87e90] [c0169b2c] drm_lastclose+0x40/0x340
[ded87ec0] [c016af14] drm_release+0x438/0x498
[ded87ef0] [c007762c] __fput+0xb4/0x19c
[ded87f10] [c00740ac] filp_close+0x68/0xb0
[ded87f30] [c0074184] sys_close+0x90/0xb4
[ded87f40] [c000ccf0] ret_from_syscall+0x0/0x3c
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
---[ end trace a2cb362184c9762b ]---
------------------------------------

Note that the physical mapping for the card has the MMIO and FB at addresses above 32 bits:

------------------------------
0000:81:00.0 VGA compatible controller: ATI Technologies Inc Unknown device 7291 (prog-if 00 [VGA])
        Subsystem: Connect Components Ltd Unknown device 7291
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at e80000000 (64-bit, prefetchable) [size=256M]
        Region 2: Memory at e98000000 (64-bit, non-prefetchable) [size=64K]
        Region 4: I/O ports at <unassigned>
        Expansion ROM at e90000000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express Endpoint IRQ 0
                Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+
                Device: Latency L0s <4us, L1 unlimited
                Device: AtnBtn- AtnInd- PwrInd-
                Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
                Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
                Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0
                Link: Latency L0s <64ns, L1 <1us
                Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
                Link: Speed 2.5Gb/s, Width x4
        Capabilities: [80] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000
---------------------------

It appears that within libdrm, the mapping does not support addressing above 32-bts on 32 bit cores, and the addresses are getting truncated.  Note the offsets from the drm debug messages:

---------------------------
[drm:drm_addmap_core] offset = 0x98000000, size = 0x00010000, type = 1
[drm:drm_addmap_core] offset = 0x80000000, size = 0x10000000, type = 0
[drm:drm_addmap_core] offset = 0x00000000, size = 0x00002000, type = 2
----------------------------

Within the mapping function the address/offset is defined as a long wich cannot hold the full physical address:

struct drm_map {
        unsigned long offset;    /**< Requested physical address (0 for SAREA)*/
        unsigned long size;      /**< Requested physical size (bytes) */
        enum drm_map_type type;  /**< Type of memory to map */
        enum drm_map_flags flags;        /**< Flags */
        void *handle;            /**< User-space: "Handle" to pass to mmap() */
                                 /**< Kernel-space: kernel-virtual address */
        int mtrr;                /**< MTRR slot used */
        /*   Private data */
};

I am assuming this is contributing to the error.  Not sure if there are other places this is an issue.  

Last part of Xorg.0.log:
--------------------------------
(II) Primary Device is: PCI 81@00:00:0
(II) resource ranges after xf86ClaimFixedResources() call:
(II) resource ranges after probing:
(II) RADEON(0): TOTO SAYS 0000000e98000000
(II) RADEON(0): MMIO registers at 0x0000000e98000000: size 64KB
(II) RADEON(0): PCI bus 129 card 0 func 0
(**) RADEON(0): Depth 24, (--) framebuffer bpp 32
(II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
(==) RADEON(0): Default visual is TrueColor
(II) RADEON(0): VGAAccess option set to FALSE, VGA module load skipped
(==) RADEON(0): RGB weight 888
(II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
(--) RADEON(0): Chipset: "ATI Radeon X1650" (ChipID = 0x7291)
(WW) RADEON(0): R500 support is under development. Please report any issues to xorg-driver-ati@lists.x.org
(--) RADEON(0): Linear framebuffer at 0x0000000e80000000
(II) RADEON(0): PCIE card detected
(II) RADEON(0): ATOM BIOS detected
(II) RADEON(0): ATOM BIOS Rom: 
	SubsystemVendorID: 0x17ee SubsystemID: 0x7291
	IOBaseAddress: 0x0000
	Filename: S3A88003.102
	BIOS Bootup Message: 
113-A88003-102 RV560XT BIOS 574e/675m                                       

(II) RADEON(0): Framebuffer space used by Firmware (kb): 0
(WW) RADEON(0): rhdAtomGetFbBaseAndSize: AtomBIOS specified VRAM scratch space size invalid
(II) RADEON(0):  default to: 20480
(II) RADEON(0): Cannot get VRAM scratch space. Allocating in main memory instead
(II) RADEON(0): Default Engine Clock: 574000
(II) RADEON(0): Default Memory Clock: 675000
(II) RADEON(0): Maximum Pixel ClockPLL Frequency Output: 1100000
(II) RADEON(0): Minimum Pixel ClockPLL Frequency Output: 0
(II) RADEON(0): Maximum Pixel ClockPLL Frequency Input: 13500
(II) RADEON(0): Minimum Pixel ClockPLL Frequency Input: 1000
(II) RADEON(0): Maximum Pixel Clock: 400000
(II) RADEON(0): Reference Clock: 27000
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
---------------------------------

Syslog w/ drm debug messages attached.
Comment 1 Andrej Krutak 2014-08-06 09:56:15 UTC
This is a problem in the drm/ttm code, not libdri.
Comment 2 Andrej Krutak 2014-08-06 09:58:01 UTC
I'm attaching a patch that resolves this problem at least with p3041 board + radeon card, where I saw similar problem (the mmio base being truncated). The issue was too small type of ttm_bus_placement.base. Also, the debug prints at the beginning only print 32 bits of the values (even if they are 64 bit).
Comment 3 Andrej Krutak 2014-08-06 09:59:27 UTC
Created attachment 104143 [details] [review]
Fix ttm_bus_placement.base type to accomodate >32 bit physical addresses
Comment 4 Michel Dänzer 2014-08-07 06:13:55 UTC
(In reply to comment #3)
> Created attachment 104143 [details] [review] [review]
> Fix ttm_bus_placement.base type to accomodate >32 bit physical addresses

You should probably split up the TTM and radeon changes into separate patches. Then, please submit them to the dri-devel mailing list directly.
Comment 5 Martin Peres 2019-10-14 13:20:18 UTC
Hi,

Freedesktop's Bugzilla instance is EOLed and open bugs are about to be migrated to http://gitlab.freedesktop.org.

To avoid migrating out of date bugs, I am now closing all the bugs that did not see any activity in the past year. If the issue is still happening, please create a new bug in the relevant project at https://gitlab.freedesktop.org/drm (use misc by default).

Sorry about the noise!


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.