More amd64 drmkms radeon

[Chavdar Ivanov]

Hi,

A few days ago one of my systems running -current (updated roughly
twice a week) refused to start Xorg with a message about a missing
global; this has been fixed since and the machine is working fine with
GENERIC and radeondrm. At that moment I decided to try DRMKMS there
and got:
---
...
drm: initializing kernel modesetting (RV350 0x1002:0x4154 0x1002:0x0002).
drm: register mmio base: 0xd0000000
drm: register mmio size: 65535
DRM error in radeon_get_bios: Unable to locate a BIOS ROM
drm: Using generic clock info
radeon0: info: GTT: 256M 0xE0000000 — 0xEFFFFFFF
drm: Generation 2 PCI interface, using max accessible memory
radeon0: info: VRAM: 128M 0x00000000D8000000 — 0x00000000DFFFFFFF (128M used)
drm: Detected VRAM RAM=80M, BAR=128M
drm: RAM width 128bits DDR
Zone kernel: Available graphics memory: 1065632 kiB
drm: radeon: 128M of VRAM memory ready
drm: radeon: 256M of GTT memory ready.
drm: radeon: 1 quad pipes, 1 Z pipes initialized.
fatal protection fault in supervisor mode
trap type 4 code 0 rip ffffffff8022eb64 cs 8 rflags 10246 cr2 0 ileuel
0 rsp fffffe8045b23a50
curlwp 0xfffffe80a83a81e0 pid 0.62 lowest kstack 0xfffffe8045b202c0
kernel: protection fault trap, code=0
Stopped in pid 8.62 (system) at netbsd:bus_dmamap_load_raw+0x34= movq
$0,40(%r14)
db{1}> bt
bus_dmamap_load_raw() at netbsd bus_dmamap_load_raw+0x34
ttm_bus_dma_populate() at netbsd:ttm_bus_dma_populate+0x100
ttm_tt_bind() at netbsd:ttm_tt_bind+0x2f
ttm_bo_handle_move_mem() at netbsd:ttm_bo_handle_move_mem+0x5e2
ttm_bo_validate() at netbsd:ttm_bo_validate+0x217
ttm_bo_init() at netbsd:ttm_bo_init+0x27c
radeon_bo_create() at netbsd:radeon_bo_create+0x15d
radeon_wb_init() at netbsd:radeon_wb_init+0x13c
r300_startup() at netbsd:r300_startup+0x128
r300_init() at netbsd:r300_init+0x11f
radeon_device_init() at netbsd:radeon_device_init+0x4d7
radeon_driver_load_kms() at netbsd:radeon_driver_load_kms+0x6e
drm_dev_register() at netbsd:drm_dev_register+0x87
drm_pci_attach() at netbsd:drm_pci_attach+0x28a
radeon_attach_real() at netbsd:radeon_attach_real+0x68
config_mountroot_thread() at netbsd:config_mountroot_thread+0x2c
db{1}>

...

I understand DRMKMS is WIP, but decided it is worth the mail for the
information only.

The chipset is reported as RADEON(0): Chipset: "ATI FireGL T2 AT
(AGP)" (ChipID = 0x4154).

Regards,

Chavdar Ivanov

[Robert Swindells]

Post by Chavdar Ivanov
A few days ago one of my systems running -current (updated roughly
twice a week) refused to start Xorg with a message about a missing
global; this has been fixed since and the machine is working fine with
GENERIC and radeondrm. At that moment I decided to try DRMKMS there
---
...
drm: initializing kernel modesetting (RV350 0x1002:0x4154 0x1002:0x0002).
drm: register mmio base: 0xd0000000
drm: register mmio size: 65535
DRM error in radeon_get_bios: Unable to locate a BIOS ROM
drm: Using generic clock info
radeon0: info: GTT: 256M 0xE0000000 — 0xEFFFFFFF
drm: Generation 2 PCI interface, using max accessible memory
radeon0: info: VRAM: 128M 0x00000000D8000000 — 0x00000000DFFFFFFF (128M used)
drm: Detected VRAM RAM=80M, BAR=128M
drm: RAM width 128bits DDR
Zone kernel: Available graphics memory: 1065632 kiB
drm: radeon: 128M of VRAM memory ready
drm: radeon: 256M of GTT memory ready.
drm: radeon: 1 quad pipes, 1 Z pipes initialized.
fatal protection fault in supervisor mode
trap type 4 code 0 rip ffffffff8022eb64 cs 8 rflags 10246 cr2 0 ileuel
0 rsp fffffe8045b23a50
curlwp 0xfffffe80a83a81e0 pid 0.62 lowest kstack 0xfffffe8045b202c0
kernel: protection fault trap, code=0
Stopped in pid 8.62 (system) at netbsd:bus_dmamap_load_raw+0x34= movq
$0,40(%r14)
db{1}> bt
bus_dmamap_load_raw() at netbsd bus_dmamap_load_raw+0x34
ttm_bus_dma_populate() at netbsd:ttm_bus_dma_populate+0x100
ttm_tt_bind() at netbsd:ttm_tt_bind+0x2f
ttm_bo_handle_move_mem() at netbsd:ttm_bo_handle_move_mem+0x5e2
ttm_bo_validate() at netbsd:ttm_bo_validate+0x217
ttm_bo_init() at netbsd:ttm_bo_init+0x27c
radeon_bo_create() at netbsd:radeon_bo_create+0x15d
radeon_wb_init() at netbsd:radeon_wb_init+0x13c
r300_startup() at netbsd:r300_startup+0x128
r300_init() at netbsd:r300_init+0x11f
radeon_device_init() at netbsd:radeon_device_init+0x4d7
radeon_driver_load_kms() at netbsd:radeon_driver_load_kms+0x6e
drm_dev_register() at netbsd:drm_dev_register+0x87
drm_pci_attach() at netbsd:drm_pci_attach+0x28a
radeon_attach_real() at netbsd:radeon_attach_real+0x68
config_mountroot_thread() at netbsd:config_mountroot_thread+0x2c
db{1}>

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.

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.

Robert Swindells

[Taylor R Campbell]

Date: Thu, 14 Aug 2014 00:29:08 +0100 (BST)
From: Robert Swindells <***@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?

[Robert Swindells]

Post by Taylor R Campbell
Date: Thu, 14 Aug 2014 00:29:08 +0100 (BST)
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.

Mine was on a machine with AGP, your change does fix the panic and it
boots to multiuser now.

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.

Post by Taylor R Campbell
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?

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 0x100000000 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.

Robert Swindells

[Taylor R Campbell]

Date: Thu, 14 Aug 2014 19:21:51 +0100 (BST)

Post by Taylor R Campbell
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 0x100000000 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.

[Robert Swindells]

Post by Taylor R Campbell
Date: Thu, 14 Aug 2014 19:21:51 +0100 (BST)
[ 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.

Post by Taylor R Campbell
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 0x100000000 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

[Rhialto]

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.

[matthew green]

Post by Robert Swindells
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.

[Chavdar Ivanov]

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
***@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 000024 (v02 PTLTD )
ACPI: XSDT 0xbff7b450 00003C (v01 PTLTD ? XSDT 06040000 LTP 00000000)
ACPI: FACP 0xbff7ee46 0000F4 (v03 AMD HAMMER 06040000 PTEC 000F4240)
ACPI: DSDT 0xbff7b48c 003946 (v01 AMD-K8 AMDACPI 06040000 MSFT 0100000E)
ACPI: FACS 0xbff7ffc0 000040
ACPI: APIC 0xbff7ef3a 000076 (v01 PTLTD ? APIC 06040000 LTP 00000000)
ACPI: SPCR 0xbff7efb0 000050 (v01 PTLTD $UCRTBL$ 06040000 PTL 00000001)
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 0xfec00000, version 0x11, 24 pins
ioapic1 at mainbus0 apid 3: pa 0xf0000000, 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 ,06040000>, AslId < LTP,00000000>
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 0xe0000000, size 0x10000000
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 version 0.95
ehci0: companion controllers, 3 ports each: ohci2 ohci3
usb4 at ehci0: USB revision 2.0
bge0 at pci2 dev 5 function 0: Broadcom BCM5705 Gigabit Ethernet
bge0: interrupting at ioapic0 pin 19
bge0: HW config 00000155, 00000015, 00000000, 00000000 00000000
bge0: ASIC BCM5705 A3 (0x3003), Ethernet address 00:0f:ea:5d:15:a1
bge0: setting short Tx thresholds
brgphy0 at bge0 phy 1: BCM5705 1000BASE-T media interface, rev. 2
brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
satalink0 at pci2 dev 6 function 0: Silicon Image SATALink 3114 (rev. 0x02)
satalink0: 33MHz PCI bus
satalink0: bus-master DMA support present
satalink0: using ioapic0 pin 18 for native-PCI interrupt
atabus0 at satalink0 channel 0
atabus1 at satalink0 channel 1
atabus2 at satalink0 channel 2
atabus3 at satalink0 channel 3
pcib0 at pci0 dev 7 function 0: AMD AMD8111 LPC Controller (rev. 0x05)
viaide0 at pci0 dev 7 function 1: AMD AMD8111 IDE Controller (rev. 0x03)
viaide0: bus-master DMA support present
viaide0: primary channel configured to compatibility mode
viaide0: primary channel interrupting at ioapic0 pin 14
atabus4 at viaide0 channel 0
viaide0: secondary channel configured to compatibility mode
viaide0: secondary channel interrupting at ioapic0 pin 15
atabus5 at viaide0 channel 1
amdpm0 at pci0 dev 7 function 3: AMD AMD8111 ACPI Controller (rev. 0x05)
timecounter: Timecounter "amdpm0" frequency 3579545 Hz quality 1000
amdpm0: 24-bit timer
iic at amdpm0 not configured
amdpm0: random number generator enabled (apprx. 57ms)
pchb1 at pci0 dev 24 function 0: AMD K8 AMD64 HyperTransport
Configuration (rev. 0x00)
pchb2 at pci0 dev 24 function 1: AMD K8 AMD64 Address Map
Configuration (rev. 0x00)
pchb3 at pci0 dev 24 function 2: AMD K8 AMD64 DRAM Configuration (rev. 0x00)
amdnb_misc0 at pci0 dev 24 function 3: AMD NB Misc Configuration
pchb4 at pci0 dev 25 function 0: AMD K8 AMD64 HyperTransport
Configuration (rev. 0x00)
pchb5 at pci0 dev 25 function 1: AMD K8 AMD64 Address Map
Configuration (rev. 0x00)
pchb6 at pci0 dev 25 function 2: AMD K8 AMD64 DRAM Configuration (rev. 0x00)
amdnb_misc1 at pci0 dev 25 function 3: AMD NB Misc Configuration
isa0 at pcib0
lpt0 at isa0 port 0x378-0x37b irq 7
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
pci3 at mainbus0 bus 8
pci3: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
ppb2 at pci3 dev 3 function 0: AMD AMD8131 PCI-X Tunnel (rev. 0x12)
pci4 at ppb2 bus 9
pci4: i/o space, memory space enabled
rtk0 at pci4 dev 1 function 0: Realtek 8139 10/100BaseTX (rev. 0x10)
rtk0: interrupting at ioapic1 pin 1
rtk0: Ethernet address 00:c0:df:13:2a:be
rlphy0 at rtk0 phy 7: Realtek internal PHY
rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
aapic0 at pci3 dev 3 function 1: AMD AMD8131 IO Apic (rev. 0x01)
ppb3 at pci3 dev 4 function 0: AMD AMD8131 PCI-X Tunnel (rev. 0x12)
pci5 at ppb3 bus 14
pci5: i/o space, memory space enabled
pdcsata0 at pci5 dev 2 function 0: Promise PDC20375 SATA150 controller
(rev. 0x02)
pdcsata0: interrupting at ioapic2 pin 2
pdcsata0: bus-master DMA support present
atabus6 at pdcsata0 channel 0
atabus7 at pdcsata0 channel 1
atabus8 at pdcsata0 channel 2
aapic1 at pci3 dev 4 function 1: AMD AMD8131 IO Apic (rev. 0x01)
acpicpu0 at cpu0: ACPI CPU
acpicpu0: C1: HLT, lat 0 us, pow 0 mW
acpicpu1 at cpu1: ACPI CPU
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
satalink0: port 0: device present, speed: 1.5Gb/s
satalink0: port 1: device present, speed: 1.5Gb/s
satalink0: port 2: device present, speed: 1.5Gb/s
satalink0: port 3: device present, speed: 1.5Gb/s
wd0 at atabus0 drive 0
wd0: <WDC WD360GD-00FNA0>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 35304 MB, 71730 cyl, 16 head, 63 sec, 512 bytes/sect x 72303840 sectors
IPsec: Initialized Security Association Processing.
uhub0 at usb0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
uhub1 at usb1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 3 ports with 3 removable, self powered
uhub2 at usb2: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 3 ports with 3 removable, self powered
uhub3 at usb3: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub3: 2 ports with 2 removable, self powered
uhub4 at usb4: NEC EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub4: 5 ports with 5 removable, self powered
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd0(satalink0:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
wd1 at atabus1 drive 0
wd1: <ST3120827AS>
wd1: drive supports 16-sector PIO transfers, LBA48 addressing
wd1: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 sectors
wd1: GPT GUID: ef1257a1-6735-11e3-b719-000fea5d15a1
dk0 at wd1: ef1257d9-6735-11e3-b719-000fea5d15a1
dk0: 234441581 blocks at 34, type: ffs
pdcsata0 port 0: device present, speed: 1.5Gb/s
pdcsata0 port 1: device present, speed: 1.5Gb/s
wd1: 32-bit data port
wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd1(satalink0:1:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
wd2 at atabus2 drive 0
wd2: <WDC WD360ADFD-00NLR4>
wd2: drive supports 16-sector PIO transfers, LBA48 addressing
wd2: 35304 MB, 71730 cyl, 16 head, 63 sec, 512 bytes/sect x 72303840 sectors
wd2: 32-bit data port
wd2: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd2(satalink0:2:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
wd3 at atabus3 drive 0
wd3: <WDC WD360ADFD-00NLR5>
wd3: drive supports 16-sector PIO transfers, LBA48 addressing
wd3: 35304 MB, 71730 cyl, 16 head, 63 sec, 512 bytes/sect x 72303840 sectors
wd3: 32-bit data port
wd3: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd3(satalink0:3:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
wd4 at atabus6 drive 0
uhidev0 at uhub1 port 2 configuration 1 interface 0
uhidev0: HP HP USB Laser Mouse, rev 2.00/31.00, addr 2, iclass 3/1
ums0 at uhidev0: 3 buttons, W and Z dirs
wsmouse0 at ums0 mux 0
pdcsata0:0:0: lost interrupt
type: ata tc_bcount: 512 tc_skip: 0
wd4: <ST3120827AS>
wd4: drive supports 16-sector PIO transfers, LBA48 addressing
wd4: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 sectors
wd4: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd4(pdcsata0:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
wd5 at atabus7 drive 0
pdcsata0:1:0: lost interrupt
type: ata tc_bcount: 512 tc_skip: 0
wd5: <ST3120827AS>
wd5: drive supports 16-sector PIO transfers, LBA48 addressing
wd5: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 sectors
wd5: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd5(pdcsata0:1:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
Kernelized RAIDframe activated
pad0: outputs: 44100Hz, 16-bit, stereo
audio0 at pad0: half duplex, playback, capture
Component on: wd0a: 72303777
Row: 0 Column: 0 Num Rows: 1 Num Columns: 3
Version: 2 Serial Number: 2013090401 Mod Counter: 3709
Clean: No Status: 0
sectPerSU: 64 SUsPerPU: 1 SUsPerRU: 1
RAID Level: 5 blocksize: 512 numBlocks: 72303680
Autoconfig: Yes
Root partition: No
Last configured as: raid1
Component on: wd2a: 72303777
Row: 0 Column: 1 Num Rows: 1 Num Columns: 3
Version: 2 Serial Number: 2013090401 Mod Counter: 3709
Clean: No Status: 0
sectPerSU: 64 SUsPerPU: 1 SUsPerRU: 1
RAID Level: 5 blocksize: 512 numBlocks: 72303680
Autoconfig: Yes
Root partition: No
Last configured as: raid1
Component on: wd3a: 72303777
Row: 0 Column: 2 Num Rows: 1 Num Columns: 3
Version: 2 Serial Number: 2013090401 Mod Counter: 3709
Clean: No Status: 0
sectPerSU: 64 SUsPerPU: 1 SUsPerRU: 1
RAID Level: 5 blocksize: 512 numBlocks: 72303680
Autoconfig: Yes
Root partition: No
Last configured as: raid1
Component on: wd4a: 234441585
Row: 0 Column: 1 Num Rows: 1 Num Columns: 2
Version: 2 Serial Number: 2013083001 Mod Counter: 2077
Clean: No Status: 0
sectPerSU: 128 SUsPerPU: 1 SUsPerRU: 1
RAID Level: 1 blocksize: 512 numBlocks: 234441472
Autoconfig: Yes
Root partition: Force
Last configured as: raid0
Component on: wd5a: 234441585
Row: 0 Column: 0 Num Rows: 1 Num Columns: 2
Version: 2 Serial Number: 2013083001 Mod Counter: 2077
Clean: No Status: 0
sectPerSU: 128 SUsPerPU: 1 SUsPerRU: 1
RAID Level: 1 blocksize: 512 numBlocks: 234441472
Autoconfig: Yes
Root partition: Force
Last configured as: raid0
Found: wd0a at 0
Found: wd2a at 1
Found: wd3a at 2
RAID autoconfigure
Configuring raid1:
Starting autoconfiguration of RAID set...
Looking for 0 in autoconfig
Found: wd0a at 0
Looking for 1 in autoconfig
Found: wd2a at 1
Looking for 2 in autoconfig
Found: wd3a at 2
raid1: allocating 30 buffers of 32768 bytes.
raid1: RAID Level 5
raid1: Components: /dev/wd0a /dev/wd2a /dev/wd3a
raid1: Total Sectors: 144607360 (70609 MB)
raid1: GPT GUID: 5b5a0aae-1568-11e3-8834-000fea5d15a1
dk1 at raid1: 5b5a0ae5-1568-11e3-8834-000fea5d15a1
dk1: 144607293 blocks at 34, type: ffs
Found: wd5a at 0
Found: wd4a at 1
RAID autoconfigure
Configuring raid0:
Starting autoconfiguration of RAID set...
Looking for 0 in autoconfig
Found: wd5a at 0
Looking for 1 in autoconfig
Found: wd4a at 1
raid0: allocating 20 buffers of 65536 bytes.
raid0: RAID Level 1
raid0: Components: /dev/wd5a /dev/wd4a
raid0: Total Sectors: 234441472 (114473 MB)
boot device: raid0
root on raid0a dumps on raid0b
dump_misc_init: max_paddr = 0xbff70000
mountroot: trying smbfs...
mountroot: trying ntfs...
mountroot: trying nfs...
mountroot: trying msdos...
mountroot: trying lfs...
mountroot: trying ext2fs...
mountroot: trying ffs...
root file system type: ffs
drm: initializing kernel modesetting (RV350 0x1002:0x4154 0x1002:0x0002).
drm: register mmio base: 0xd0000000
drm: register mmio size: 65536
DRM error in radeon_get_bios: Unable to locate a BIOS ROM
drm: Using generic clock info
radeon0: info: GTT: 256M 0xE0000000 - 0xEFFFFFFF
drm: Generation 2 PCI interface, using max accessible memory
radeon0: info: VRAM: 128M 0x00000000D8000000 - 0x00000000DFFFFFFF (128M used)
drm: Detected VRAM RAM=80M, BAR=128M
drm: RAM width 128bits DDR
Zone kernel: Available graphics memory: 1065624 kiB
drm: radeon: 128M of VRAM memory ready
drm: radeon: 256M of GTT memory ready.
drm: radeon: 1 quad pipes, 1 Z pipes initialized.
radeon0: info: WB disabled
radeon0: info: fence driver on ring 0 use gpu addr 0x00000000e0000000
and cpu addr 0x0xffff8000373bc000
drm: Supports vblank timestamp caching Rev 2 (21.10.2013).
drm: Driver supports precise vblank timestamp query.
radeon0: interrupting at ioapic0 pin 16 (radeon)
drm: radeon: irq initialized.
drm: Loading R300 Microcode
init: copying out path `/sbin/init' 11
drm: radeon: ring at 0x00000000E0001000
drm: ring test succeeded in 0 usecs
drm: ib test succeeded in 0 usecs
drm: Connector Table: 1 (generic)
drm: No TMDS info found in BIOS
drm: No TV DAC info found in BIOS
drm: Radeon Display Connectors
drm: Connector 0:
drm: DVI-I-1
drm: HPD1
drm: DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
drm: Encoders:
drm: DFP1: INTERNAL_TMDS1
drm: CRT2: INTERNAL_DAC2
drm: Connector 1:
drm: VGA-1
drm: DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
drm: Encoders:
drm: CRT1: INTERNAL_DAC1
drm: Connector 2:
drm: SVIDEO-1
drm: Encoders:
drm: TV1: INTERNAL_DAC2
radeondrmkmsfb0 at radeon0
radeon0: info: registered panic notifier
radeondrmkmsfb0: framebuffer at 0xffff8000375f0000, size 1280x1024,
depth 32, stride 5120
wsdisplay0 at radeondrmkmsfb0 kbdmux 1: console (default, vt100
emulation), using wskbd0
wsmux1: connecting to wsdisplay0
bge0: link state DOWN (was UNKNOWN)
rtk0: link state UP (was UNKNOWN)
bge0: link state UP (was DOWN)
wsdisplay0: screen 1 added (default, vt100 emulation)
wsdisplay0: screen 2 added (default, vt100 emulation)
wsdisplay0: screen 3 added (default, vt100 emulation)
wsdisplay0: screen 4 added (default, vt100 emulation)
/spare: replaying log to disk
/data: replaying log to disk
---

/var/log/Xorg.0.log is blank.

Chavdar

Post by matthew green

Post by Robert Swindells
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.

[Patrick Welche]

Post by Chavdar Ivanov
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

[Patrick Welche]

Post by Patrick Welche

Post by Chavdar Ivanov
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

[Robert Swindells]

Post by Patrick Welche

Post by Patrick Welche

Post by Chavdar Ivanov
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

[Taylor R Campbell]

Date: Fri, 15 Aug 2014 16:09:03 +0100 (BST)
From: Robert Swindells <***@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

[Robert Swindells]

Post by Taylor R Campbell
Date: Fri, 15 Aug 2014 16:09:03 +0100 (BST)
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.

[Taylor R Campbell]

Date: Sun, 17 Aug 2014 16:19:54 +0100 (BST)
From: Robert Swindells <***@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.

[Robert Swindells]

Post by Taylor R Campbell
Date: Sun, 17 Aug 2014 16:19:54 +0100 (BST)
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.c 26 Jul 2014 21:19:45 -0000 1.5
+++ radeon_ttm.c 17 Aug 2014 16:08:18 -0000
@@ -50,7 +50,11 @@
#include <drm/bus_dma_hacks.h>
#endif

+#ifdef _LP64
#define DRM_FILE_PAGE_OFFSET (0x100000000ULL >> PAGE_SHIFT)
+#else
+#define DRM_FILE_PAGE_OFFSET (0xa0000000 >> PAGE_SHIFT)
+#endif

static int radeon_ttm_debugfs_init(struct radeon_device *rdev);
static void radeon_ttm_debugfs_fini(struct radeon_device *rdev);

[Robert Swindells]

Post by Taylor R Campbell
Date: Sun, 17 Aug 2014 16:19:54 +0100 (BST)
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*.

[Patrick Welche]

Post by Robert Swindells

Post by Patrick Welche

Post by Patrick Welche

Post by Chavdar Ivanov
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 ?

Now it panics (and rebuilt the X server with symbols just in case):

panic: kernel diagnostic assertion "uvm_page_locked_p(pg)" failed: file "../../../../arch/x86/x86/pmap.c", line 3316
cpu1: Begin traceback...
vpanic() at netbsd:vpanic+0x13c
kern_assert() at netbsd:kern_assert+0x4f
pmap_remove_pte() at netbsd:pmap_remove_pte+0x2c6
pmap_remove() at netbsd:pmap_remove+0x1ff
uvm_unmap_remove() at netbsd:uvm_unmap_remove+0x283
sys_munmap() at netbsd:sys_munmap+0x8a
syscall() at netbsd:syscall+0x187
--- syscall (number 73) ---
7f7ff430171a:
cpu1: End traceback...

I seem to have acquired a successful kernel core dump too...


Cheers,

Patrick

[matthew green]

Post by Patrick Welche
panic: kernel diagnostic assertion "uvm_page_locked_p(pg)" failed: file "../../../../arch/x86/x86/pmap.c", line 3316
cpu1: Begin traceback...
vpanic() at netbsd:vpanic+0x13c
kern_assert() at netbsd:kern_assert+0x4f
pmap_remove_pte() at netbsd:pmap_remove_pte+0x2c6
pmap_remove() at netbsd:pmap_remove+0x1ff
uvm_unmap_remove() at netbsd:uvm_unmap_remove+0x283
sys_munmap() at netbsd:sys_munmap+0x8a
syscall() at netbsd:syscall+0x187
--- syscall (number 73) ---
cpu1: End traceback...
I seem to have acquired a successful kernel core dump too...

this problem is caused by the pmap_remove() taking the pmap->pm_lock,
but the page being removed not being held by that lock, so the assert
that this page is locked failed. it belongs to a different uobject.

i have no idea why or how to fix it.

i instrumented this a little last weekend, to keep track of the last
few pages being freed via pmap_remove_pte(), and this is what we have:

pmap_remove_pte: not locked pg 0xffff800003401b18 va 0x7f7fecb00000
opg[0..3] = 0xffff8000038d2548 0xffff8000038d2548 0xffff8000038d2548 0xffff8000038ca7a8
opm[0..3] = 0xffffffff80df0ac0 0xffffffff80df0ac0 0xffffffff80df0ac0 0xffffffff80df0ac0
panic: kernel diagnostic assertion "uvm_page_locked_p(pg)" failed: file "/usr/src4/sys/arch/x86/x86/pmap.c", line 3320 pmap_remove_pte: not locked pg 0xffff800003401b18 va 0x7f7fecb00000
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x13c
kern_assert() at netbsd:kern_assert+0x4f
pmap_remove_pte() at netbsd:pmap_remove_pte+0x41a
pmap_remove() at netbsd:pmap_remove+0x1ff
uvm_unmap_remove() at netbsd:uvm_unmap_remove+0x283
sys_munmap() at netbsd:sys_munmap+0x8a
syscall() at netbsd:syscall+0x9a
--- syscall (number 73) ---
7f7ff430171a:
cpu0: End traceback...
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip ffffffff8021adcd cs 8 rflags 3246 cr2 7f7fefc0b7f8 ilevel 0 rsp fffffe8045ed5c90
curlwp 0xfffffe80be01f680 pid 107.1 lowest kstack 0xfffffe8045ed22c0
Stopped in pid 107.1 (Xorg) at netbsd:breakpoint+0x5: leave
db{0}> show page 0xffff800003401b18
PAGE 0xffff800003401b18:
flags=0x4<TABLED>, pqflags=0x4<AOBJ>, wire_count=1, pa=0xb45ba000
uobject=0xfffffe80b4fff508, uanon=0x0, offset=0x0 loan_count=0
[page ownership tracking disabled]
db{0}> show page 0xffff8000038d2548
PAGE 0xffff8000038d2548:
flags=0x8c<TABLED,CLEAN,RDONLY>, pqflags=0x200<PRIVATE2>, wire_count=0, pa=0xbea14000
uobject=0xfffffe80bea05820, uanon=0x0, offset=0x10c000 loan_count=0
[page ownership tracking disabled]
db{0}> show page 0xffff8000038d2548
PAGE 0xffff8000038d2548:
flags=0x8c<TABLED,CLEAN,RDONLY>, pqflags=0x200<PRIVATE2>, wire_count=0, pa=0xbea14000
uobject=0xfffffe80bea05820, uanon=0x0, offset=0x10c000 loan_count=0
[page ownership tracking disabled]
db{0}> show object 0xfffffe80b4fff508
OBJECT 0xfffffe80b4fff508: locked=0, pgops=0xffffffff809e1f40, npages=768, refs=1
db{0}> show object 0xfffffe80bea05820
OBJECT 0xfffffe80bea05820: locked=0, pgops=0xffffffff809e23c0, npages=1194, refs=65

[Patrick Welche]

Post by Robert Swindells
What does it do now ?

It (radeon) no longer panics!

P

[Chavdar Ivanov]

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: register mmio size: 65536
pci_io_find: expected type i/o, found mem
DRM error in radeon_get_bios: Unable to locate a BIOS ROM
drm: Using generic clock info
radeon0: info: GTT: 256M 0xE0000000 - 0xEFFFFFFF
drm: Generation 2 PCI interface, using max accessible memory
radeon0: info: VRAM: 128M 0x00000000D8000000 - 0x00000000DFFFFFFF (128M used)
drm: Detected VRAM RAM=80M, BAR=128M
drm: RAM width 128bits DDR
Zone kernel: Available graphics memory: 1065574 kiB
drm: radeon: 128M of VRAM memory ready
drm: radeon: 256M of GTT memory ready.
drm: radeon: 1 quad pipes, 1 Z pipes initialized.
radeon0: info: WB disabled
radeon0: info: fence driver on ring 0 use gpu addr 0x00000000e0000000
and cpu addr 0x0xffff800037393000
drm: Supports vblank timestamp caching Rev 2 (21.10.2013).
drm: Driver supports precise vblank timestamp query.
DRM debug in drm_irq_install: irq=268570634
radeon0: interrupting at ioapic0 pin 16 (radeon)
drm: radeon: irq initialized.
DRM debug in r100_cp_init_microcode:
drm: Loading R300 Microcode
drm kern error: radeon_cp: Failed to load firmware "radeon/R300_cp.bin"
DRM error in r100_cp_init: Failed to load firmware!
radeon0: error: failed initializing CP (-2).
radeon0: error: Disabling GPU acceleration
drm: radeon: cp finalized
panic: kernel diagnostic assertion "ttm->caching_state == tt_cached"
failed: file "../../../../external/bsd/drm2/dist/drm/ttm/ttm_tt.c",
line 423
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip ffffffff8028bcfd cs 8 rflags 246 cr2 0 ilevel 0
rsp fffffe8045b27bb8
curlwp 0xfffffe8045b3d1a0 pid 0.57 lowest kstack 0xfffffe8045b242c0
Stopped in pid 0.57 (system) at netbsd:breakpoint+0x5: leave
db{0}> bt
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x13c
kern_assert() at netbsd:kern_assert+0x4f
ttm_tt_swapout() at netbsd:ttm_tt_swapout+0x123
ttm_bus_dma_unpopulate() at netbsd:ttm_bus_dma_unpopulate+0x35
ttm_tt_destroy() at netbsd:ttm_tt_destroy+0x42
ttm_bo_cleanup_memtype_use() at netbsd:ttm_bo_cleanup_memtype_use+0x3a
ttm_bo_release() at netbsd:ttm_bo_release+0x36d
radeon_bo_unref() at netbsd:radeon_bo_unref+0x3f
radeon_wb_fini() at netbsd:radeon_wb_fini+0xe3
r300_init() at netbsd:r300_init+0x148
radeon_device_init() at netbsd:radeon_device_init+0x4d7
radeon_driver_load_kms() at netbsd:radeon_driver_load_kms+0x6e
drm_dev_register() at netbsd:drm_dev_register+0x87
drm_pci_attach() at netbsd:drm_pci_attach+0x28a
radeon_attach_real() at netbsd:radeon_attach_real+0x68
config_mountroot_thread() at netbsd:config_mountroot_thread+0x2c

Post by Patrick Welche

Post by Robert Swindells
What does it do now ?

It (radeon) no longer panics!
P

Chavdar

(BTW I finally sat down and configured serial console on this machine;
took me all of two minutes - would have saved me all those screenshots
taken with a phone camera then manually input... or even
text-recognized...).

[Taylor R Campbell]

Date: Fri, 22 Aug 2014 10:18:59 +0100
From: Chavdar Ivanov <***@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?

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...

[Chavdar Ivanov]

Post by Taylor R Campbell
Date: Fri, 22 Aug 2014 10:18:59 +0100
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).
[...]
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
***@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
...

Post by Taylor R Campbell
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

[Robert Swindells]

Post by Chavdar Ivanov

Post by Taylor R Campbell
Date: Fri, 22 Aug 2014 10:18:59 +0100
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).
[...]
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?

$ uname -a
NetBSD uksup1.delcam.local 7.99.1 NetBSD 7.99.1 (DRMKMS) #1: Fri Aug
15 14:06:51 BST 2014
$ 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.

Post by Chavdar Ivanov

Post by Taylor R Campbell
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

[Chavdar Ivanov]

Post by Robert Swindells

Post by Chavdar Ivanov

Post by Taylor R Campbell
Date: Fri, 22 Aug 2014 10:18:59 +0100
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).
[...]
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?

$ uname -a
NetBSD uksup1.delcam.local 7.99.1 NetBSD 7.99.1 (DRMKMS) #1: Fri Aug
15 14:06:51 BST 2014
$ 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.

Post by Chavdar Ivanov

Post by Taylor R Campbell
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
Filesystem 1K-blocks Used Avail %Cap Mounted on
/dev/raid0a 105311462 31680686 68365204 31% /
/dev/dk0 116306664 65608 110425728 0% /spare
/dev/dk1 71674768 61557912 6533120 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).

Post by Robert Swindells
Robert Swindells

Chavdar

[Chavdar Ivanov]

Post by Chavdar Ivanov

Post by Robert Swindells

Post by Chavdar Ivanov

Post by Taylor R Campbell
Date: Fri, 22 Aug 2014 10:18:59 +0100
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).
[...]
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?

$ uname -a
NetBSD uksup1.delcam.local 7.99.1 NetBSD 7.99.1 (DRMKMS) #1: Fri Aug
15 14:06:51 BST 2014
$ 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.

Post by Chavdar Ivanov

Post by Taylor R Campbell
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
~ df -k -t ffs
Filesystem 1K-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

Post by Chavdar Ivanov
/dev/dk0 116306664 65608 110425728 0% /spare
/dev/dk1 71674768 61557912 6533120 90% /data
~ raidctl -s raid0
/dev/wd5a: optimal
/dev/wd4a: optimal
...
~ raidctl -s raid1
/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
dk1: 5b5a0ae5-1568-11e3-8834-000fea5d15a1, 144607293 blocks at 34, type: ffs
(from the working kernel from 15th).

Post by Robert Swindells
Robert Swindells

Chavdar
--
----

[Chavdar Ivanov]

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

Post by Chavdar Ivanov

Post by Chavdar Ivanov

Post by Robert Swindells

Post by Chavdar Ivanov

Post by Taylor R Campbell
Date: Fri, 22 Aug 2014 10:18:59 +0100
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).
[...]
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?

$ uname -a
NetBSD uksup1.delcam.local 7.99.1 NetBSD 7.99.1 (DRMKMS) #1: Fri Aug
15 14:06:51 BST 2014
$ 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.

Post by Chavdar Ivanov

Post by Taylor R Campbell
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
~ df -k -t ffs
Filesystem 1K-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

Post by Chavdar Ivanov
/dev/dk0 116306664 65608 110425728 0% /spare
/dev/dk1 71674768 61557912 6533120 90% /data
~ raidctl -s raid0
/dev/wd5a: optimal
/dev/wd4a: optimal
...
~ raidctl -s raid1
/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
dk1: 5b5a0ae5-1568-11e3-8834-000fea5d15a1, 144607293 blocks at 34, type: ffs
(from the working kernel from 15th).

Post by Robert Swindells
Robert Swindells

Chavdar
--
----

--
----

[Chavdar Ivanov]

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

Post by Chavdar Ivanov
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

Post by Chavdar Ivanov

Post by Chavdar Ivanov

Post by Robert Swindells

Post by Chavdar Ivanov

Post by Taylor R Campbell
Date: Fri, 22 Aug 2014 10:18:59 +0100
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).
[...]
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?

$ uname -a
NetBSD uksup1.delcam.local 7.99.1 NetBSD 7.99.1 (DRMKMS) #1: Fri Aug
15 14:06:51 BST 2014
$ 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.

Post by Chavdar Ivanov

Post by Taylor R Campbell
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
~ df -k -t ffs
Filesystem 1K-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

Post by Chavdar Ivanov
/dev/dk0 116306664 65608 110425728 0% /spare
/dev/dk1 71674768 61557912 6533120 90% /data
~ raidctl -s raid0
/dev/wd5a: optimal
/dev/wd4a: optimal
...
~ raidctl -s raid1
/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
dk1: 5b5a0ae5-1568-11e3-8834-000fea5d15a1, 144607293 blocks at 34, type: ffs
(from the working kernel from 15th).

Post by Robert Swindells
Robert Swindells

Chavdar
--
----

--
----

--
----

[Patrick Welche]

Post by Patrick Welche

Post by Chavdar Ivanov
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 0x00007f7ff430d32a in _lwp_kill () from /usr/lib/libc.so.12
(gdb) bt
#0 0x00007f7ff430d32a in _lwp_kill () from /usr/lib/libc.so.12
#1 0x00007f7ff430cfb5 in abort () from /usr/lib/libc.so.12
#2 0x000000000054ad60 in OsAbort ()
#3 0x0000000000464707 in ddxGiveUp ()
#4 0x000000000054819d in AbortServer ()
#5 0x000000000054853b in FatalError ()
#6 0x000000000054b578 in ?? ()
#7 <signal handler called>
#8 0x00007f7ff430ce74 in memcpy () from /usr/lib/libc.so.12
#9 0x00007f7fee60ecee in ?? () from /usr/X11R7/lib/modules/libexa.so
#10 0x00007f7fee60f114 in ?? () from /usr/X11R7/lib/modules/libexa.so
#11 0x00007f7fee60ddad in exaPrepareAccessReg_mixed ()
from /usr/X11R7/lib/modules/libexa.so
#12 0x00007f7fee6057f7 in ExaCheckPolyGlyphBlt ()
from /usr/X11R7/lib/modules/libexa.so
#13 0x00000000004b85f8 in miPolyText8 ()
#14 0x000000000050622b in ?? ()
#15 0x000000000044cc5a in doPolyText ()
#16 0x000000000044dada in PolyText ()
#17 0x0000000000451007 in ProcPolyText ()
#18 0x00000000004534b1 in Dispatch ()
#19 0x000000000059d0da in main ()

(yesterday's -current/amd64
Device Name: Radeon X600 PCI Express (0x5b62)
aka RV380)

Cheers,

Patrick