Re: More amd64 drmkms radeon
I managed to get a panic dump from my -current amd64 host with a FireGL card using DRMKMS. Dmesg, gdb trace and Xorg.0.log attached (if one starts only Xorg, it kinda works - a functional cursor is seen with a small white rectangle at the top left corner; anything more than that results in the panic). Chavdar On 3 September 2014 13:57, Chavdar Ivanov ci4...@gmail.com wrote: The good news is that DRMKMS doesn't crash any more on boot on that machine; Xorg shows the cursor in the screen centre and a small white rectangle in the top left corner; the machine is reachable from outside, but the console is unresponsive from this moment on; if I try something further (like startx or [kg]dm), I get a hard reset. Chavdar On 23 August 2014 17:39, Chavdar Ivanov ci4...@gmail.com wrote: On 22 August 2014 23:39, Chavdar Ivanov ci4...@gmail.com wrote: On 22 August 2014 22:35, Robert Swindells r...@fdy2.co.uk wrote: Chavdar Ivanov wrote: On 22 August 2014 16:56, Taylor R Campbell riastr...@netbsd.org wrote: Date: Fri, 22 Aug 2014 10:18:59 +0100 From: Chavdar Ivanov ci4...@gmail.com A DRMKMS kernel from 15th works as suggested above - switches to 1280x1024 and is fine after (Xorg panics earlier; with the latest build from yesterday it even wedged the machine completely). On the other hand yesterday's kernel panics as follows: [...] drm kern error: radeon_cp: Failed to load firmware radeon/R300_cp.bin Do you still have /usr/libdata/firmware/radeon/R300_cp.bin on the root file system? Yes, the kernel from 15th of August loads it fine: $ uname -a NetBSD uksup1.delcam.local 7.99.1 NetBSD 7.99.1 (DRMKMS) #1: Fri Aug 15 14:06:51 BST 2014 root@support6.delcam.local:/root/a64/compile/DRMKMS amd64 $ ls -l /usr/libdata/firmware/radeon/R300_cp.bin -r--r--r-- 1 root wheel 2048 Jul 6 2010 /usr/libdata/firmware/radeon/R300_cp.bin $ dmesg | grep Microcode drm: Loading R300 Microcode ... I tried a custom kernel with sources from yesterday on i386 with a R300 and it works fine. We really ought to have a better story if it's not, but that's my first guess about the problem. panic: kernel diagnostic assertion ttm-caching_state == tt_cached failed: file ../../../../external/bsd/drm2/dist/drm/ttm/ttm_tt.c, line 423 This is a bug in the rat's nest of error branches in the Radeon code, ugh... Well, it doesn't show up in the earlier version, so it looks a regression. The panic is triggered while cleaning up from the failure to load the microcode. One change between your working kernel and now was to enable wedges, they are disabled in my custom kernel. I have to say, this came to my mind as well. However, that machine has been using raidframe and wedges for ages: ~ df -k -t ffs Filesystem1K-blocks Used Avail %Cap Mounted on /dev/raid0a 105311462 31680686 68365204 31% / However, I have to notice that in the case of the working non-default-slice kernel, the root is not on a wedge, so there may be something about the order in which the wedges are recognized and the firmware loaded. Chavdar /dev/dk0 116306664 65608 110425728 0% /spare /dev/dk1 71674768 615579126533120 90% /data ~ raidctl -s raid0 Components: /dev/wd5a: optimal /dev/wd4a: optimal ... ~ raidctl -s raid1 Components: /dev/wd0a: optimal /dev/wd2a: optimal /dev/wd3a: optimal ... ~ gpt show raid0 start size index contents 0 234441472 ~ gpt show raid1 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 144607293 1 GPT part - NetBSD FFSv1/FFSv2 144607327 32 Sec GPT table 144607359 1 Sec GPT header ~ dkctl raid1 listwedges /dev/rraid1d: 1 wedge: dk1: 5b5a0ae5-1568-11e3-8834-000fea5d15a1, 144607293 blocks at 34, type: ffs (from the working kernel from 15th). Robert Swindells Chavdar -- -- -- -- Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 7.99.1 (DRMKMS) #1: Mon Oct 13 10:49:13 BST 2014 root@support6.delcam.local:/root/a64/compile/DRMKMS total memory = 3071 MB avail memory = 2963 MB kern.module.path=/stand/amd64/7.99.1/modules timecounter: Timecounters tick every 10.000 msec timecounter: Timecounter i8254 frequency 1193182 Hz quality 100 AMD Rhapsody (Rev 4) mainbus0 (root) ACPI: RSDP 0xf6fc0 24 (v02 PTLTD ) ACPI: XSDT 0xbff7b450 3C (v01 PTLTD ? XSDT 0604 LTP ) ACPI: FACP 0xbff7ee46 F4 (v03 AMDHAMMER 0604 PTEC
Re: More amd64 drmkms radeon
The good news is that DRMKMS doesn't crash any more on boot on that machine; Xorg shows the cursor in the screen centre and a small white rectangle in the top left corner; the machine is reachable from outside, but the console is unresponsive from this moment on; if I try something further (like startx or [kg]dm), I get a hard reset. Chavdar On 23 August 2014 17:39, Chavdar Ivanov ci4...@gmail.com wrote: On 22 August 2014 23:39, Chavdar Ivanov ci4...@gmail.com wrote: On 22 August 2014 22:35, Robert Swindells r...@fdy2.co.uk wrote: Chavdar Ivanov wrote: On 22 August 2014 16:56, Taylor R Campbell riastr...@netbsd.org wrote: Date: Fri, 22 Aug 2014 10:18:59 +0100 From: Chavdar Ivanov ci4...@gmail.com A DRMKMS kernel from 15th works as suggested above - switches to 1280x1024 and is fine after (Xorg panics earlier; with the latest build from yesterday it even wedged the machine completely). On the other hand yesterday's kernel panics as follows: [...] drm kern error: radeon_cp: Failed to load firmware radeon/R300_cp.bin Do you still have /usr/libdata/firmware/radeon/R300_cp.bin on the root file system? Yes, the kernel from 15th of August loads it fine: $ uname -a NetBSD uksup1.delcam.local 7.99.1 NetBSD 7.99.1 (DRMKMS) #1: Fri Aug 15 14:06:51 BST 2014 root@support6.delcam.local:/root/a64/compile/DRMKMS amd64 $ ls -l /usr/libdata/firmware/radeon/R300_cp.bin -r--r--r-- 1 root wheel 2048 Jul 6 2010 /usr/libdata/firmware/radeon/R300_cp.bin $ dmesg | grep Microcode drm: Loading R300 Microcode ... I tried a custom kernel with sources from yesterday on i386 with a R300 and it works fine. We really ought to have a better story if it's not, but that's my first guess about the problem. panic: kernel diagnostic assertion ttm-caching_state == tt_cached failed: file ../../../../external/bsd/drm2/dist/drm/ttm/ttm_tt.c, line 423 This is a bug in the rat's nest of error branches in the Radeon code, ugh... Well, it doesn't show up in the earlier version, so it looks a regression. The panic is triggered while cleaning up from the failure to load the microcode. One change between your working kernel and now was to enable wedges, they are disabled in my custom kernel. I have to say, this came to my mind as well. However, that machine has been using raidframe and wedges for ages: ~ df -k -t ffs Filesystem1K-blocks Used Avail %Cap Mounted on /dev/raid0a 105311462 31680686 68365204 31% / However, I have to notice that in the case of the working non-default-slice kernel, the root is not on a wedge, so there may be something about the order in which the wedges are recognized and the firmware loaded. Chavdar /dev/dk0 116306664 65608 110425728 0% /spare /dev/dk1 71674768 615579126533120 90% /data ~ raidctl -s raid0 Components: /dev/wd5a: optimal /dev/wd4a: optimal ... ~ raidctl -s raid1 Components: /dev/wd0a: optimal /dev/wd2a: optimal /dev/wd3a: optimal ... ~ gpt show raid0 start size index contents 0 234441472 ~ gpt show raid1 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 144607293 1 GPT part - NetBSD FFSv1/FFSv2 144607327 32 Sec GPT table 144607359 1 Sec GPT header ~ dkctl raid1 listwedges /dev/rraid1d: 1 wedge: dk1: 5b5a0ae5-1568-11e3-8834-000fea5d15a1, 144607293 blocks at 34, type: ffs (from the working kernel from 15th). Robert Swindells Chavdar -- -- --
Re: More amd64 drmkms radeon
On 22 August 2014 23:39, Chavdar Ivanov ci4...@gmail.com wrote: On 22 August 2014 22:35, Robert Swindells r...@fdy2.co.uk wrote: Chavdar Ivanov wrote: On 22 August 2014 16:56, Taylor R Campbell riastr...@netbsd.org wrote: Date: Fri, 22 Aug 2014 10:18:59 +0100 From: Chavdar Ivanov ci4...@gmail.com A DRMKMS kernel from 15th works as suggested above - switches to 1280x1024 and is fine after (Xorg panics earlier; with the latest build from yesterday it even wedged the machine completely). On the other hand yesterday's kernel panics as follows: [...] drm kern error: radeon_cp: Failed to load firmware radeon/R300_cp.bin Do you still have /usr/libdata/firmware/radeon/R300_cp.bin on the root file system? Yes, the kernel from 15th of August loads it fine: $ uname -a NetBSD uksup1.delcam.local 7.99.1 NetBSD 7.99.1 (DRMKMS) #1: Fri Aug 15 14:06:51 BST 2014 root@support6.delcam.local:/root/a64/compile/DRMKMS amd64 $ ls -l /usr/libdata/firmware/radeon/R300_cp.bin -r--r--r-- 1 root wheel 2048 Jul 6 2010 /usr/libdata/firmware/radeon/R300_cp.bin $ dmesg | grep Microcode drm: Loading R300 Microcode ... I tried a custom kernel with sources from yesterday on i386 with a R300 and it works fine. We really ought to have a better story if it's not, but that's my first guess about the problem. panic: kernel diagnostic assertion ttm-caching_state == tt_cached failed: file ../../../../external/bsd/drm2/dist/drm/ttm/ttm_tt.c, line 423 This is a bug in the rat's nest of error branches in the Radeon code, ugh... Well, it doesn't show up in the earlier version, so it looks a regression. The panic is triggered while cleaning up from the failure to load the microcode. One change between your working kernel and now was to enable wedges, they are disabled in my custom kernel. I have to say, this came to my mind as well. However, that machine has been using raidframe and wedges for ages: ~ df -k -t ffs Filesystem1K-blocks Used Avail %Cap Mounted on /dev/raid0a 105311462 31680686 68365204 31% / However, I have to notice that in the case of the working non-default-slice kernel, the root is not on a wedge, so there may be something about the order in which the wedges are recognized and the firmware loaded. Chavdar /dev/dk0 116306664 65608 110425728 0% /spare /dev/dk1 71674768 615579126533120 90% /data ~ raidctl -s raid0 Components: /dev/wd5a: optimal /dev/wd4a: optimal ... ~ raidctl -s raid1 Components: /dev/wd0a: optimal /dev/wd2a: optimal /dev/wd3a: optimal ... ~ gpt show raid0 start size index contents 0 234441472 ~ gpt show raid1 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 144607293 1 GPT part - NetBSD FFSv1/FFSv2 144607327 32 Sec GPT table 144607359 1 Sec GPT header ~ dkctl raid1 listwedges /dev/rraid1d: 1 wedge: dk1: 5b5a0ae5-1568-11e3-8834-000fea5d15a1, 144607293 blocks at 34, type: ffs (from the working kernel from 15th). Robert Swindells Chavdar -- --
Re: More amd64 drmkms radeon
On 22 August 2014 16:56, Taylor R Campbell riastr...@netbsd.org wrote: Date: Fri, 22 Aug 2014 10:18:59 +0100 From: Chavdar Ivanov ci4...@gmail.com A DRMKMS kernel from 15th works as suggested above - switches to 1280x1024 and is fine after (Xorg panics earlier; with the latest build from yesterday it even wedged the machine completely). On the other hand yesterday's kernel panics as follows: [...] drm kern error: radeon_cp: Failed to load firmware radeon/R300_cp.bin Do you still have /usr/libdata/firmware/radeon/R300_cp.bin on the root file system? Yes, the kernel from 15th of August loads it fine: $ uname -a NetBSD uksup1.delcam.local 7.99.1 NetBSD 7.99.1 (DRMKMS) #1: Fri Aug 15 14:06:51 BST 2014 root@support6.delcam.local:/root/a64/compile/DRMKMS amd64 $ ls -l /usr/libdata/firmware/radeon/R300_cp.bin -r--r--r-- 1 root wheel 2048 Jul 6 2010 /usr/libdata/firmware/radeon/R300_cp.bin $ dmesg | grep Microcode drm: Loading R300 Microcode ... We really ought to have a better story if it's not, but that's my first guess about the problem. panic: kernel diagnostic assertion ttm-caching_state == tt_cached failed: file ../../../../external/bsd/drm2/dist/drm/ttm/ttm_tt.c, line 423 This is a bug in the rat's nest of error branches in the Radeon code, ugh... Well, it doesn't show up in the earlier version, so it looks a regression. Chavdar --
Re: More amd64 drmkms radeon
Chavdar Ivanov wrote: On 22 August 2014 16:56, Taylor R Campbell riastr...@netbsd.org wrote: Date: Fri, 22 Aug 2014 10:18:59 +0100 From: Chavdar Ivanov ci4...@gmail.com A DRMKMS kernel from 15th works as suggested above - switches to 1280x1024 and is fine after (Xorg panics earlier; with the latest build from yesterday it even wedged the machine completely). On the other hand yesterday's kernel panics as follows: [...] drm kern error: radeon_cp: Failed to load firmware radeon/R300_cp.bin Do you still have /usr/libdata/firmware/radeon/R300_cp.bin on the root file system? Yes, the kernel from 15th of August loads it fine: $ uname -a NetBSD uksup1.delcam.local 7.99.1 NetBSD 7.99.1 (DRMKMS) #1: Fri Aug 15 14:06:51 BST 2014 root@support6.delcam.local:/root/a64/compile/DRMKMS amd64 $ ls -l /usr/libdata/firmware/radeon/R300_cp.bin -r--r--r-- 1 root wheel 2048 Jul 6 2010 /usr/libdata/firmware/radeon/R300_cp.bin $ dmesg | grep Microcode drm: Loading R300 Microcode ... I tried a custom kernel with sources from yesterday on i386 with a R300 and it works fine. We really ought to have a better story if it's not, but that's my first guess about the problem. panic: kernel diagnostic assertion ttm-caching_state == tt_cached failed: file ../../../../external/bsd/drm2/dist/drm/ttm/ttm_tt.c, line 423 This is a bug in the rat's nest of error branches in the Radeon code, ugh... Well, it doesn't show up in the earlier version, so it looks a regression. The panic is triggered while cleaning up from the failure to load the microcode. One change between your working kernel and now was to enable wedges, they are disabled in my custom kernel. Robert Swindells
Re: More amd64 drmkms radeon
On Fri, Aug 15, 2014 at 04:47:42PM +0100, Patrick Welche wrote: On Fri, Aug 15, 2014 at 04:09:03PM +0100, Robert Swindells wrote: What does it do now ? Now it panics (and rebuilt the X server with symbols just in case): It (radeon) no longer panics! P
Re: More amd64 drmkms radeon
Taylor R Campbell wrote: Date: Fri, 15 Aug 2014 16:09:03 +0100 (BST) From: Robert Swindells r...@fdy2.co.uk I get a panic in a call to munmap(2) but that may just be happening when the server is cleaning up from some other error. There is a bug somewhere in the establishment of VM mappings for radeon or ttm. Not sure what it is yet, but it's probably in the code I wrote to port ttm to NetBSD, in sys/external/bsd/drm2/ttm or in the #ifdef NetBSD sections of sys/external/bsd/drm2/dist/drm/radeon/radeon_ttm.c sys/external/bsd/drm2/dist/drm/radeon/radeon_object.c sys/external/bsd/drm2/dist/drm/ttm I have tried running with the calls to munmap(2) in libdrm commented out just to see what happened, I'm not getting any panics. I realize it doesn't solve the real problem but it makes it easier to see if there are other things wrong. On i386, the ioctl() of DRM_RADEON_GEM_MMAP is returning addresses above 4GB which obviously cause drmMap() of them to fail. Not tried amd64 yet.
Re: More amd64 drmkms radeon
Date: Sun, 17 Aug 2014 16:19:54 +0100 (BST) From: Robert Swindells r...@fdy2.co.uk On i386, the ioctl() of DRM_RADEON_GEM_MMAP is returning addresses above 4GB which obviously cause drmMap() of them to fail. This isn't obvious to me -- off_t is 64-bit everywhere, and the `addresses' that DRM_RADEON_GEM_MMAP returns are not physical addresses but cookies that correspond to graphics buffers. If drmMap fails, that might mean the mapping between cookies and buffers (the `drm_vma' data structures) is wrong.
Re: More amd64 drmkms radeon
Taylor R Campbell wrote: Date: Sun, 17 Aug 2014 16:19:54 +0100 (BST) From: Robert Swindells r...@fdy2.co.uk On i386, the ioctl() of DRM_RADEON_GEM_MMAP is returning addresses above 4GB which obviously cause drmMap() of them to fail. This isn't obvious to me -- off_t is 64-bit everywhere, and the `addresses' that DRM_RADEON_GEM_MMAP returns are not physical addresses but cookies that correspond to graphics buffers. If drmMap fails, that might mean the mapping between cookies and buffers (the `drm_vma' data structures) is wrong. Ok, obvious was wrong. Things do work better with the following patch though, I get a sort of display and can move a blob representing the mouse around. I'm guessing that the display appearance is related to this: [ 232.356] (II) RADEON(0): Setting screen physical size to 480 x 270 The monitor EDID is decoded correctly as 1920x1080. I also get a panic from pmap_tlb_shootdown() when I kill the server. Maybe some part of the call tree from the drmMap is truncating to 32 bits ? RCS file: /cvsroot/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_ttm.c,v retrieving revision 1.5 diff -u -r1.5 radeon_ttm.c --- radeon_ttm.c26 Jul 2014 21:19:45 - 1.5 +++ radeon_ttm.c17 Aug 2014 16:08:18 - @@ -50,7 +50,11 @@ #include drm/bus_dma_hacks.h #endif +#ifdef _LP64 #define DRM_FILE_PAGE_OFFSET (0x1ULL PAGE_SHIFT) +#else +#defineDRM_FILE_PAGE_OFFSET (0xa000 PAGE_SHIFT) +#endif static int radeon_ttm_debugfs_init(struct radeon_device *rdev); static void radeon_ttm_debugfs_fini(struct radeon_device *rdev);
Re: More amd64 drmkms radeon
Taylor R Campbell wrote: Date: Sun, 17 Aug 2014 16:19:54 +0100 (BST) From: Robert Swindells r...@fdy2.co.uk On i386, the ioctl() of DRM_RADEON_GEM_MMAP is returning addresses above 4GB which obviously cause drmMap() of them to fail. This isn't obvious to me -- off_t is 64-bit everywhere, and the `addresses' that DRM_RADEON_GEM_MMAP returns are not physical addresses but cookies that correspond to graphics buffers. If drmMap fails, that might mean the mapping between cookies and buffers (the `drm_vma' data structures) is wrong. I think the problem is in libdrm, the address argument to drmMap() is just a void*.
Re: More amd64 drmkms radeon
Mine is also much better now - DRMKMS kernel boots into multiuser, switches the mode and works fine in multiuser. Xorg doesn't start; it blanks the screen and I presume panics, but I can't see anything; I will have to switch to serial console to see what is going on (I also had a panic from a KASSERT in igmp.c, which did panic on every shutdown/reboot/halt, but I commented it out and now it reboots cleanly). The dmesg follows: Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 7.99.1 (DRMKMS) #0: Fri Aug 15 13:50:02 BST 2014 root@support6.delcam.local:/root/a64/compile/DRMKMS total memory = 3071 MB avail memory = 2963 MB kern.module.path=/stand/amd64/7.99.1/modules timecounter: Timecounters tick every 10.000 msec timecounter: Timecounter i8254 frequency 1193182 Hz quality 100 AMD Rhapsody (Rev 4) mainbus0 (root) ACPI: RSDP 0xf6fc0 24 (v02 PTLTD ) ACPI: XSDT 0xbff7b450 3C (v01 PTLTD ? XSDT 0604 LTP ) ACPI: FACP 0xbff7ee46 F4 (v03 AMDHAMMER 0604 PTEC 000F4240) ACPI: DSDT 0xbff7b48c 003946 (v01 AMD-K8 AMDACPI 0604 MSFT 010E) ACPI: FACS 0xbff7ffc0 40 ACPI: APIC 0xbff7ef3a 76 (v01 PTLTD ? APIC 0604 LTP ) ACPI: SPCR 0xbff7efb0 50 (v01 PTLTD $UCRTBL$ 0604 PTL 0001) ACPI: All ACPI Tables successfully acquired cpu0 at mainbus0 apid 0: AMD Opteron(tm) Processor 246, id 0xf5a cpu0: erratum 86 present cpu0: erratum 104 present cpu0: erratum 101 present cpu0: WARNING: errata present, BIOS upgrade may be cpu0: WARNING: necessary to ensure reliable operation cpu1 at mainbus0 apid 1: AMD Opteron(tm) Processor 246, id 0xf5a ioapic0 at mainbus0 apid 2: pa 0xfec0, version 0x11, 24 pins ioapic1 at mainbus0 apid 3: pa 0xf000, version 0x11, 4 pins ioapic2 at mainbus0 apid 4: pa 0xf0001000, version 0x11, 4 pins acpi0 at mainbus0: Intel ACPICA 20131218 acpi0: X/RSDT: OemId PTLTD , XSDT ,0604, AslId LTP, acpi0: SCI interrupting at int 9 timecounter: Timecounter ACPI-Fast frequency 3579545 Hz quality 1000 acpibut0 at acpi0 (PWRB, PNP0C0C): ACPI Power Button attimer1 at acpi0 (TMR, PNP0100): io 0x40-0x43 irq 0 pcppi1 at acpi0 (SPKR, PNP0800): io 0x61 midi0 at pcppi1: PC speaker sysbeep0 at pcppi1 SYSR (PNP0C02) WARNING: module error: vfs load failed for `acpiverbose', error 45 at acpi0 not configured pckbc1 at acpi0 (PS2M, PNP0F13) (aux port): irq 12 pckbc2 at acpi0 (PS2K, PNP0303) (kbd port): io 0x60,0x64 irq 1 FDC0 (PNP0700) WARNING: module error: vfs load failed for `acpiverbose', error 45 at acpi0 not configured UAR1 (PNP0501) WARNING: module error: vfs load failed for `acpiverbose', error 45 at acpi0 not configured UAR2 (PNP0501) WARNING: module error: vfs load failed for `acpiverbose', error 45 at acpi0 not configured LPT (PNP0400) WARNING: module error: vfs load failed for `acpiverbose', error 45 at acpi0 not configured ACPI: Enabled 1 GPEs in block 00 to 0F ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20131218/hwxface-646) ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S3_] (20131218/hwxface-646) WARNING: module error: vfs load failed for `acpiverbose', error 45 attimer1: attached to pcppi1 pckbd0 at pckbc2 (kbd slot) pckbc2: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pci0 at mainbus0 bus 0: configuration mode 1 pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok pchb0 at pci0 dev 0 function 0: AMD AMD8151 AGP Device (rev. 0x13) agp0 at pchb0: 2 Miscellaneous Control unit(s) found. agp0: aperture at 0xe000, size 0x1000 ppb0 at pci0 dev 1 function 0: AMD AMD8151 AGP Bridge (rev. 0x13) pci1 at ppb0 bus 1 pci1: i/o space, memory space enabled radeon0 at pci1 dev 0 function 0: ATI Technologies FireGL T2 AT (rev. 0x80) ppb1 at pci0 dev 6 function 0: AMD AMD8111 I/O Hub (rev. 0x07) pci2 at ppb1 bus 2 pci2: i/o space, memory space enabled ohci0 at pci2 dev 0 function 0: AMD AMD8111 USB Host Controller (rev. 0x0b) csr: 02800017 ohci0: interrupting at ioapic0 pin 19 ohci0: OHCI version 1.0, legacy support usb0 at ohci0: USB revision 1.0 ohci1 at pci2 dev 0 function 1: AMD AMD8111 USB Host Controller (rev. 0x0b) csr: 02800017 ohci1: interrupting at ioapic0 pin 19 ohci1: OHCI version 1.0, legacy support usb1 at ohci1: USB revision 1.0 ohci2 at pci2 dev 4 function 0: NEC USB Host Controller (rev. 0x41) csr: 02100016 ohci2: interrupting at ioapic0 pin 17 ohci2: OHCI version 1.0 usb2 at ohci2: USB revision 1.0 ohci3 at pci2 dev 4 function 1: NEC USB Host Controller (rev. 0x41) csr: 02100016 ohci3: interrupting at ioapic0 pin 18 ohci3: OHCI version 1.0 usb3 at ohci3: USB revision 1.0 ehci0 at pci2 dev 4 function 2: NEC USB2 Host Controller (rev. 0x02) ehci0: interrupting at ioapic0 pin 19 ehci0: EHCI
Re: More amd64 drmkms radeon
On Fri, Aug 15, 2014 at 02:48:47PM +0100, Chavdar Ivanov wrote: Mine is also much better now - DRMKMS kernel boots into multiuser, switches the mode and works fine in multiuser. Xorg doesn't start; it blanks the screen and I presume panics, but I can't see anything; I I think X coredumps, but I have played hunt the core and haven't found it yet... (I can ssh in after screen goes blank) Cheers, Patrick
Re: More amd64 drmkms radeon
On Fri, Aug 15, 2014 at 02:55:37PM +0100, Patrick Welche wrote: On Fri, Aug 15, 2014 at 02:48:47PM +0100, Chavdar Ivanov wrote: Mine is also much better now - DRMKMS kernel boots into multiuser, switches the mode and works fine in multiuser. Xorg doesn't start; it blanks the screen and I presume panics, but I can't see anything; I I think X coredumps, but I have played hunt the core and haven't found it yet... (I can ssh in after screen goes blank) That was before Working file: external/mit/libdrm/dist/radeon/radeon_bo_gem.c revision 1.4 date: 2014/08/14 20:56:10; author: mrg; state: Exp; lines: +2 -2 convert an mmap() to drmMap(). P
Re: More amd64 drmkms radeon
On Fri, Aug 15, 2014 at 02:55:37PM +0100, Patrick Welche wrote: On Fri, Aug 15, 2014 at 02:48:47PM +0100, Chavdar Ivanov wrote: Mine is also much better now - DRMKMS kernel boots into multiuser, switches the mode and works fine in multiuser. Xorg doesn't start; it blanks the screen and I presume panics, but I can't see anything; I I think X coredumps, but I have played hunt the core and haven't found it yet... (I can ssh in after screen goes blank) Got it - but no symbols: Program terminated with signal SIGABRT, Aborted. #0 0x7f7ff430d32a in _lwp_kill () from /usr/lib/libc.so.12 (gdb) bt #0 0x7f7ff430d32a in _lwp_kill () from /usr/lib/libc.so.12 #1 0x7f7ff430cfb5 in abort () from /usr/lib/libc.so.12 #2 0x0054ad60 in OsAbort () #3 0x00464707 in ddxGiveUp () #4 0x0054819d in AbortServer () #5 0x0054853b in FatalError () #6 0x0054b578 in ?? () #7 signal handler called #8 0x7f7ff430ce74 in memcpy () from /usr/lib/libc.so.12 #9 0x7f7fee60ecee in ?? () from /usr/X11R7/lib/modules/libexa.so #10 0x7f7fee60f114 in ?? () from /usr/X11R7/lib/modules/libexa.so #11 0x7f7fee60ddad in exaPrepareAccessReg_mixed () from /usr/X11R7/lib/modules/libexa.so #12 0x7f7fee6057f7 in ExaCheckPolyGlyphBlt () from /usr/X11R7/lib/modules/libexa.so #13 0x004b85f8 in miPolyText8 () #14 0x0050622b in ?? () #15 0x0044cc5a in doPolyText () #16 0x0044dada in PolyText () #17 0x00451007 in ProcPolyText () #18 0x004534b1 in Dispatch () #19 0x0059d0da in main () (yesterday's -current/amd64 Device Name: Radeon X600 PCI Express (0x5b62) aka RV380) Cheers, Patrick
Re: More amd64 drmkms radeon
Patrick Welche wrote: On Fri, Aug 15, 2014 at 02:55:37PM +0100, Patrick Welche wrote: On Fri, Aug 15, 2014 at 02:48:47PM +0100, Chavdar Ivanov wrote: Mine is also much better now - DRMKMS kernel boots into multiuser, switches the mode and works fine in multiuser. Xorg doesn't start; it blanks the screen and I presume panics, but I can't see anything; I I think X coredumps, but I have played hunt the core and haven't found it yet... (I can ssh in after screen goes blank) That was before Working file: external/mit/libdrm/dist/radeon/radeon_bo_gem.c revision 1.4 date: 2014/08/14 20:56:10; author: mrg; state: Exp; lines: +2 -2 convert an mmap() to drmMap(). What does it do now ? I get a panic in a call to munmap(2) but that may just be happening when the server is cleaning up from some other error. Robert Swindells
Re: More amd64 drmkms radeon
Date: Thu, 14 Aug 2014 00:29:08 +0100 (BST) From: Robert Swindells r...@fdy2.co.uk I'm seeing basically the same thing with an RV280 on i386, I don't have a crash dump as it goes into a recursive panic but was able to capture a boot trace with a serial console. I was able to add a bit of debug before the call to bus_dmamap_load_raw() to confirm that the arguments looked correctly aligned. Is this by any chance on a machine with AGP? If so, I just checked in a change (ttm_agp_backend.c rev. 1.2) which may fix it. If not, can you tell me anything about the arguments to bus_dmamap_load_raw? Might also be helpful to print the fields of the ttm and bo objects involved in the call stack so I can see what state everything is in. I don't get this error with an RV710 on amd64, it boots fully but Xorg fails with an error from somewhere in ttm/uvm. What's the error? Do you have dmesg output or Xorg.0.log?
Re: More amd64 drmkms radeon
Date: Thu, 14 Aug 2014 19:21:51 +0100 (BST)
From: Robert Swindells r...@fdy2.co.uk
Taylor R Campbell wrote:
Is this by any chance on a machine with AGP? If so, I just checked in
a change (ttm_agp_backend.c rev. 1.2) which may fix it.
Mine was on a machine with AGP, your change does fix the panic and it
boots to multiuser now.
Great!
X fails to start though with:
[64.826] (II) AIGLX: Loaded and initialized
/usr/X11R7/lib/modules/dri/r200_dri.so
[64.826] (II) GLX: Initialized DRI2 GL provider for screen 0
[64.848] (II) RADEON(0): Setting screen physical size to 480 x 270
[66.187] Segmentation fault at address 0x0
I can try debugging this and/or send the logs.
Can you get a stack trace with gdb?
The error is ENODEV (19) returned from the call to mmap(2) from bo_map()
in xsrc/external/mit/libdrm/dist/radeon/radeon_bo_gem.c.
The server is trying to allocate 16384 bytes for the cursor, the drm
ioctl just before the mmap() returns 0x1 as the address to use.
Adding some printfs to the kernel it doesn't look to be calling into
the drm code from the mmap() syscall.
Probably needs to be changed to use drmMap instead of mmap,
un{til,less} we sort out getting proper mmap for non-vnode files.
Re: More amd64 drmkms radeon
Taylor R Campbell wrote:
Date: Thu, 14 Aug 2014 19:21:51 +0100 (BST)
From: Robert Swindells r...@fdy2.co.uk
X fails to start though with:
[64.826] (II) AIGLX: Loaded and initialized
/usr/X11R7/lib/modules/dri/r200_dri.so
[64.826] (II) GLX: Initialized DRI2 GL provider for screen 0
[64.848] (II) RADEON(0): Setting screen physical size to 480 x 270
[66.187] Segmentation fault at address 0x0
I can try debugging this and/or send the logs.
Can you get a stack trace with gdb?
Have done but see below.
The error is ENODEV (19) returned from the call to mmap(2) from bo_map()
in xsrc/external/mit/libdrm/dist/radeon/radeon_bo_gem.c.
The server is trying to allocate 16384 bytes for the cursor, the drm
ioctl just before the mmap() returns 0x1 as the address to use.
Adding some printfs to the kernel it doesn't look to be calling into
the drm code from the mmap() syscall.
Probably needs to be changed to use drmMap instead of mmap,
un{til,less} we sort out getting proper mmap for non-vnode files.
Switching to drmMap() in libdrm_radeon does get a bit further, the
cursor allocations seem to work, but the implementation of drmUnmap()
just calls munmap(2) which panics the kernel, there doesn't seem to be
a DRM_IOCTL_MUNMAP defined.
On i386 with the RV280, the calls to drmMap() fail with an error 19.
Robert Swindells
Re: More amd64 drmkms radeon
I just tried a DRMKMS kernel on my laptop, (source updated less than an hour ago) and compared to several months ago when I tried it last, it gets a lot further! I just tried the kernel though, no updated userland (so I have the old X from 6.1). I didn't really expect that situation to work, but it rebooted while trying to start X. I can imagine that this isn't expected to work, but a reboot was a bit drastic :-) If I disable xdm, the system starts to multiuser fine. I'll try if I can get the full -current system to boot and see what happens then, but would a dmesg or something like that be useful? The laptop has an Intel 915 variant, a Mobile IntelM-BM-. GM45 Express Chipset. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgp37WfWxRSji.pgp Description: PGP signature
re: More amd64 drmkms radeon
Adding some printfs to the kernel it doesn't look to be calling into
the drm code from the mmap() syscall.
Probably needs to be changed to use drmMap instead of mmap,
un{til,less} we sort out getting proper mmap for non-vnode files.
i commited the fix for this i've been using.
.mrg.
