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.
This is a problem in the drm/ttm code, not libdri.
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).
Created attachment 104143 [details] [review] Fix ttm_bus_placement.base type to accomodate >32 bit physical addresses
(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.
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.