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*.
bind ALLOW_FILTER_AAAA_ON_V4 changed to ALLOW_FILTER_AAAA
Back at the beginning of April, src/external/bsd/bind/Makefile.inc r1.20 enabled support for the filter--on-v4 option. While I used a similar local modification successfully on netbsd-6, I've recently started migrating to NetBSD-7 where support for that option should now be available by default. Although built starting with a clean (nonexistent) OBJDIR/DESTDIR, the resulting 'named' executable claims that filter--on-v4 was not enabled at compile time and fails to start. It appears that the version of bind in NetBSD-7 and HEAD has changed the enabling macro name to simply ALLOW_FILTER_. As such src/external/bsd/bind/Makefile.inc should be updated to match and pulled up to netbsd-7. Thanks. -- |/\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
daily CVS update output
Updating src tree: P src/external/gpl3/binutils/usr.sbin/dbsym/dbsym.8 P src/external/gpl3/binutils/usr.sbin/dbsym/dbsym.c P src/external/gpl3/gcc/dist/gcc/config/vax/builtins.md P src/external/gpl3/gcc/dist/gcc/config/vax/vax.c P src/lib/libc/compiler_rt/Makefile.inc P src/lib/libc/time/zic.c P src/libexec/ld.elf_so/arch/vax/rtld_start.S P src/sbin/ccdconfig/ccdconfig.c P src/sys/arch/aarch64/conf/Makefile.aarch64 P src/sys/arch/acorn32/conf/EB7500ATX P src/sys/arch/algor/conf/P4032 P src/sys/arch/algor/conf/P5064 P src/sys/arch/algor/conf/P5064-64 P src/sys/arch/algor/conf/P6032 P src/sys/arch/amd64/amd64/locore.S P src/sys/arch/arm/conf/Makefile.arm P src/sys/arch/cats/conf/GENERIC P src/sys/arch/dreamcast/conf/GENERIC P src/sys/arch/epoc32/conf/GENERIC P src/sys/arch/evbarm/conf/ADI_BRH P src/sys/arch/evbarm/conf/ARMADAXP P src/sys/arch/evbarm/conf/ARMADILLO210 P src/sys/arch/evbarm/conf/ARMADILLO9 P src/sys/arch/evbarm/conf/BCM5301X P src/sys/arch/evbarm/conf/BCM56340 P src/sys/arch/evbarm/conf/BEAGLEBOARD P src/sys/arch/evbarm/conf/BEAGLEBOARDXM P src/sys/arch/evbarm/conf/BEAGLEBONE P src/sys/arch/evbarm/conf/CP3100 P src/sys/arch/evbarm/conf/CUBIEBOARD P src/sys/arch/evbarm/conf/DNS323 P src/sys/arch/evbarm/conf/GEMINI P src/sys/arch/evbarm/conf/GEMINI_MASTER P src/sys/arch/evbarm/conf/GEMINI_SLAVE P src/sys/arch/evbarm/conf/GOLDENGATE P src/sys/arch/evbarm/conf/GUMSTIX P src/sys/arch/evbarm/conf/HAWK P src/sys/arch/evbarm/conf/HDL_G P src/sys/arch/evbarm/conf/HPT5325 P src/sys/arch/evbarm/conf/IGEPV2 P src/sys/arch/evbarm/conf/IMX23_OLINUXINO P src/sys/arch/evbarm/conf/IMX31LITE P src/sys/arch/evbarm/conf/INTEGRATOR P src/sys/arch/evbarm/conf/INTEGRATOR_CP P src/sys/arch/evbarm/conf/IQ31244 P src/sys/arch/evbarm/conf/IQ80310 P src/sys/arch/evbarm/conf/IQ80321 P src/sys/arch/evbarm/conf/IXDP425 P src/sys/arch/evbarm/conf/IXM1200 P src/sys/arch/evbarm/conf/KUROBOX_PRO P src/sys/arch/evbarm/conf/LUBBOCK P src/sys/arch/evbarm/conf/MMNET_GENERIC P src/sys/arch/evbarm/conf/MPCSA_GENERIC P src/sys/arch/evbarm/conf/MV2120 P src/sys/arch/evbarm/conf/N900 P src/sys/arch/evbarm/conf/NAPPI P src/sys/arch/evbarm/conf/NSLU2 P src/sys/arch/evbarm/conf/ODROID P src/sys/arch/evbarm/conf/ODROID-U P src/sys/arch/evbarm/conf/OMAP5EVM P src/sys/arch/evbarm/conf/OPENBLOCKS_A6 P src/sys/arch/evbarm/conf/OPENBLOCKS_AX3 P src/sys/arch/evbarm/conf/OSK5912 P src/sys/arch/evbarm/conf/OVERO P src/sys/arch/evbarm/conf/PANDABOARD P src/sys/arch/evbarm/conf/RPI P src/sys/arch/evbarm/conf/SHEEVAPLUG P src/sys/arch/evbarm/conf/TEAMASA_NPWR P src/sys/arch/evbarm/conf/TEAMASA_NPWR_FC P src/sys/arch/evbarm/conf/TISDP2420 P src/sys/arch/evbarm/conf/TISDP2430 P src/sys/arch/evbarm/conf/TS7200 P src/sys/arch/evbarm/conf/TWINTAIL P src/sys/arch/evbarm/conf/VIPER P src/sys/arch/evbarm/conf/ZAO425 P src/sys/arch/evbmips/conf/ADM5120 P src/sys/arch/evbmips/conf/ADM5120-NB P src/sys/arch/evbmips/conf/ADM5120-USB P src/sys/arch/evbmips/conf/ALCHEMY P src/sys/arch/evbmips/conf/AP30 P src/sys/arch/evbmips/conf/CPMBR1400 P src/sys/arch/evbmips/conf/DB120 P src/sys/arch/evbmips/conf/GDIUM64 P src/sys/arch/evbmips/conf/MALTA P src/sys/arch/evbmips/conf/MALTA64 P src/sys/arch/evbmips/conf/MERAKI P src/sys/arch/evbmips/conf/RB153 P src/sys/arch/evbmips/conf/RB433UAH P src/sys/arch/evbmips/conf/WGT624V3 P src/sys/arch/evbmips/conf/XLSATX P src/sys/arch/evbmips/conf/ZYXELKX P src/sys/arch/evbppc/conf/EV64260 P src/sys/arch/evbppc/conf/EXPLORA451 P src/sys/arch/evbppc/conf/MPC8536DS P src/sys/arch/evbppc/conf/MPC8548CDS P src/sys/arch/evbppc/conf/OPENBLOCKS200 P src/sys/arch/evbppc/conf/OPENBLOCKS266 P src/sys/arch/evbppc/conf/OPENBLOCKS600 P src/sys/arch/evbppc/conf/P2020DS P src/sys/arch/evbppc/conf/P2020RDB P src/sys/arch/evbppc/conf/PMPPC P src/sys/arch/evbppc/conf/RB800 P src/sys/arch/evbppc/conf/TWRP1025 P src/sys/arch/evbppc/conf/VIRTEX_DFC P src/sys/arch/evbppc/conf/VIRTEX_GSRD1 P src/sys/arch/evbppc/conf/VIRTEX_GSRD2 P src/sys/arch/evbppc/conf/WALNUT P src/sys/arch/evbsh3/conf/AP_MS104_SH4 P src/sys/arch/evbsh3/conf/T_SH7706LAN P src/sys/arch/evbsh3/conf/T_SH7706LSR P src/sys/arch/i386/i386/locore.S P src/sys/arch/iyonix/conf/GENERIC P src/sys/arch/luna68k/conf/GENERIC P src/sys/arch/luna68k/conf/INSTALL P src/sys/arch/m68k/include/int_fmtio.h P src/sys/arch/mac68k/mac68k/machdep.c P src/sys/arch/macppc/dev/abtn.c P src/sys/arch/netwinder/conf/GENERIC P src/sys/arch/sbmips/conf/GENERIC P src/sys/arch/sbmips/conf/GENERIC.MP P src/sys/arch/sbmips/conf/GENERIC64 P src/sys/arch/sbmips/conf/GENERIC64.MP P src/sys/arch/shark/conf/GENERIC P src/sys/arch/usermode/conf/GENERIC.common P src/sys/arch/zaurus/conf/GENERIC P src/sys/arch/zaurus/conf/INSTALL P src/sys/conf/Makefile.kern.inc P src/sys/conf/files P src/sys/dev/pci/yds.c P src/sys/external/bsd/drm2/dist/drm/drm_gem.c P src/sys/external/bsd/drm2/dist/drm/ttm/ttm_bo.c P src/sys/external/bsd/drm2/ttm/ttm_bo_vm.c P src/sys/kern/exec_elf.c P src/sys/kern/kern_ksyms.c U src/sys/kern/kern_ksyms_buf.c
Re: bind ALLOW_FILTER_AAAA_ON_V4 changed to ALLOW_FILTER_AAAA
In article pine.neb.4.64.1408171840090.19...@david.technoskunk.fur, John D. Baker jdba...@mylinuxisp.com wrote: Back at the beginning of April, src/external/bsd/bind/Makefile.inc r1.20 enabled support for the filter--on-v4 option. While I used a similar local modification successfully on netbsd-6, I've recently started migrating to NetBSD-7 where support for that option should now be available by default. Although built starting with a clean (nonexistent) OBJDIR/DESTDIR, the resulting 'named' executable claims that filter--on-v4 was not enabled at compile time and fails to start. It appears that the version of bind in NetBSD-7 and HEAD has changed the enabling macro name to simply ALLOW_FILTER_. As such src/external/bsd/bind/Makefile.inc should be updated to match and pulled up to netbsd-7. Thanks! christos
