Re: drm2 removed?
On Mon, Feb 11, 2019 at 06:42:29PM +0100, Niclas Zeising wrote: > > > > The patch allows the port to be built. > > > > kldloading the i915kms module causes a 'black screen > > of death' > > > Hi! > I assume you load the kernel module either manually with kldload or > using kld_list in rc.conf, not by loading it from the loader? > So there is two bugs? One bug is that the kernel hangs while booting, > and the other is that you get a black screen when loading the drm module > after the kernel is mostly done booting? > Things have gone sideways. Dumbed down CPUTYPE to pentiumpro for my Core2 duo. Spent all afternoon rebuilding kernel/world. Rebuilt the following ports with new world: drm-legacy-kmod-g20190109 gpu-firmware-kmod-g20181104 libXxf86vm-1.1.4_3 xf86-input-keyboard-1.9.0_3 xf86-input-mouse-1.9.3_2 xf86-video-intel-2.99.917.20181203 xf86-video-vesa-2.4.0_2 xorg-server-1.18.4_11,1 Load /boot/modules/i915kms.ko either manually or from rc.conf, results in a panic. The system didn't create a crash dump as I was expecting. A hand transcribed jpeg of panic screen Fatal trap 12: page fault while in kernel mode cpuid = 0: apic id = 00 fault virtual address = 0x8910 fault code = supervisor write data, page not present instruction pointer= 0x20:0xcc277a stack pointer = 0x28:0xa3cebd4 frame pointer = 0x28:0xa3cec20 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process= 0 (thread taskq) trap number= 12 panic: page fault cpuid = 0 time = 1549933942 KDB: stack backtrace db_trace_self_wrapper kdb_backtrace vpanic panic trap_fatal trap_pfault trap calltrap --- trap 0xc, eip = 0xcc277a, esp = 0x3cebd4, ebp = 0x3cec20 vmem_periodic(0,1,c671ce,a5ad79c,0,...) at vmem_periodic+0x18a/ taskqueue_run_locked taskqueue_thread_loop fork_exit fork_trampoline() at 0xffc033ba/frame 0xa3cecd4 -- trap 0, eip = 0, esp = 0xa3ced20, ebp (null)() at 0 -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2 removed?
On Mon, Feb 11, 2019 at 09:01:55PM +, Graham Perrin wrote: > On 11/02/2019 20:42, Steve Kargl wrote: > > > Are you building on i386 or x86_64? > > $ uname -a > FreeBSD momh167-gjp4-8570p 13.0-CURRENT FreeBSD 13.0-CURRENT r343931 > GENERIC-NODEBUG amd64 amd64 == x86_64 --> no problem as PAE vs no PAE is a i386 thing. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2 removed?
On 11/02/2019 20:42, Steve Kargl wrote: > On Mon, Feb 11, 2019 at 08:40:01PM +, Graham Perrin wrote: > >> On 11/02/2019 16:20, Steve Kargl wrote: >> >>> On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote: >>> Anyone have any idea which recent change broke the drm-legacy-kmod port. This is why I raised an issue with removal of drm2 from src/sys. How is suppose to be fixed? >>> >>> It was r343567. The merging of PAE and NO PAE pmap.h >>> by kib removed all of the missing macros. :( >> >> I found no trouble building drm-legacy-kmod with e.g. r343931. >> >> Just curious, does the breakage occur in only some situations? > > Are you building on i386 or x86_64? $ uname -a FreeBSD momh167-gjp4-8570p 13.0-CURRENT FreeBSD 13.0-CURRENT r343931 GENERIC-NODEBUG amd64 $ HP EliteBook 8570p. drm-kmod prefers drm-current-kmod but that nearly always fails for me, so I prefer legacy. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2 removed?
On Mon, Feb 11, 2019 at 08:40:01PM +, Graham Perrin wrote: > On 11/02/2019 16:20, Steve Kargl wrote: > > > On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote: > > > >> Anyone have any idea which recent change broke the > >> drm-legacy-kmod port. This is why I raised an issue > >> with removal of drm2 from src/sys. How is suppose > >> to be fixed? > > > > It was r343567. The merging of PAE and NO PAE pmap.h > > by kib removed all of the missing macros. :( > > I found no trouble building drm-legacy-kmod with e.g. r343931. > > Just curious, does the breakage occur in only some situations? Are you building on i386 or x86_64? -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2 removed?
On 11/02/2019 16:20, Steve Kargl wrote: > On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote: > >> Anyone have any idea which recent change broke the >> drm-legacy-kmod port. This is why I raised an issue >> with removal of drm2 from src/sys. How is suppose >> to be fixed? > > It was r343567. The merging of PAE and NO PAE pmap.h > by kib removed all of the missing macros. :( I found no trouble building drm-legacy-kmod with e.g. r343931. Just curious, does the breakage occur in only some situations? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: memstick images install broken bootx64.efi
I’ll take a look later today, since it’s likely related to my changes. — Rebecca On January 26, 2019 at 6:43:49 PM, Yuri Pankov (yur...@yuripv.net(mailto:yur...@yuripv.net)) wrote: > Hi, > > Looks like installations from snapshot memstick images (tried all > available ones for amd64 from > http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/) put > broken bootx64.efi to ESP -- the system in question simply tries to boot > via PXE. Fixing this is simple -- mounting the ESP, and copying > /boot/loader.efi from installation media (the same memstick) to > efi/boot/bootx64.efi. And diff shows that the two actually differ, > having the same size and file(1) output though. > > Anyone seeing the same and/or knows what's wrong here (before I try > looking into that)? > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath10k driver status?
hi, I'm trying to update things with Geramy right now. We hit a snag where his updates broke my QCA9880 NIC in STA mode, so we're working through that right now. -adrian On Mon, 11 Feb 2019 at 09:51, Ben Widawsky wrote: > On 19-02-04 00:29:29, Anthony Jenkins wrote: > > [snip] > > Hi Adrian. I too am wondering what the plan is for this chipset. I am > currently > using an awful USB wifi dongle. I can help with testing if needed - but I > just > really want to know if we should expect upstream support which is > relatively > stable in the next month or two. If not, I'll look for alternative > solutions. > > Thanks. > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2 removed?
On Mon, Feb 11, 2019 at 06:42:29PM +0100, Niclas Zeising wrote: > On 2/11/19 6:36 PM, Steve Kargl wrote: > > > > The patch allows the port to be built. > > > > kldloading the i915kms module causes a 'black screen > > of death' > > > > I'll note that there seems to be a race condition in > > booting a kernel (with or without the drm2 stuff). > > During boot the kernel hangs (see below) : > > > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > Firmware Warning (ACPI): Incorrect checksum in table [TCPA] - 0x80, should > > be 0x24 (20190108/tbprint-337) > > ioapic0: Changing APIC ID to 2 > > ioapic0 irqs 0-23 on motherboard > > Launching APs: 1 > > > > *** kernel hangs here sometimes *** > > > > Timecounter "TSC" frequency 1995048460 Hz quality 1000 > > random: entropy device external interface > > kbd1 at kbdmux0 > > I assume you load the kernel module either manually with kldload or > using kld_list in rc.conf, not by loading it from the loader? After a succesful boot. I login as root and manually kldload the i915kms module. > So there is two bugs? One bug is that the kernel hangs while booting, > and the other is that you get a black screen when loading the drm module > after the kernel is mostly done booting? Yes, two bugs. kernel sometimes hangs after lauching the cpus but before random device is ready. Loading the new drm2 module cause a black screen of death. Don't know if it helps. Extracted info from /var/log/messages login[987]: ROOT LOGIN (root) ON ttyv0 (manually kldload i915kms.ko module) kernel: info: [drm] Initialized drm 1.1.0 20060810 kernel: drmn0: on vgapci0 kernel: intel_iicbb0 on drmn0 kernel: iicbus0: on iicbb0 addr 0x30 kernel: iic0: on iicbus0 kernel: iicbus1: on intel_gmbus0 kernel: iic1: on iicbus1 kernel: intel_iicbb1 on drmn0 kernel: iicbus2: on iicbb1 addr 0x30 kernel: iic2: on iicbus2 kernel: iicbus3: on intel_gmbus1 kernel: iic3: on iicbus3 kernel: intel_iicbb2 on drmn0 kernel: iicbus4: on iicbb2 addr 0x30 kernel: iic4: on iicbus4 kernel: iicbus5: on intel_gmbus2 kernel: iic5: on iicbus5 kernel: intel_iicbb3 on drmn0 kernel: iicbus6: on iicbb3 addr 0x30 kernel: iic6: on iicbus6 kernel: iicbus7: on intel_gmbus3 kernel: iic7: on iicbus7 kernel: intel_iicbb4 on drmn0 kernel: iicbus8: on iicbb4 addr 0x30 kernel: iic8: on iicbus8 kernel: iicbus9: on intel_gmbus4 kernel: iic9: on iicbus9 kernel: intel_iicbb5 on drmn0 kernel: iicbus10: on iicbb5 addr 0x30 kernel: iic10: on iicbus10 kernel: iicbus11: on intel_gmbus5 kernel: iic11: on iicbus11 kernel: vgapci0: attempting to allocate 1 MSI vectors (1 supported) kernel: msi: routing MSI IRQ 34 to local APIC 1 vector 55 kernel: vgapci0: using IRQ 34 for MSI kernel: info: [drm] MSI enabled 1 message(s) kernel: info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). kernel: info: [drm] Driver supports precise vblank timestamp query. kernel: composite sync not supported kernel: intel_sdvo_ddc_proxy397632 on drmn0 kernel: intel_sdvo_ddc_proxy397632: detached kernel: intel_sdvo_ddc_proxy397664 on drmn0 kernel: intel_sdvo_ddc_proxy397664: detached kernel: drmn0: taking over the fictitious range 0xe000-0xf000 kernel: info: [drm] initialized overlay support kernel: info: [drm] Connector LVDS-1: get mode from tunables: kernel: info: [drm] - kern.vt.fb.modes.LVDS-1 kernel: info: [drm] - kern.vt.fb.default_mode kernel: info: [drm] Connector VGA-1: get mode from tunables: kernel: info: [drm] - kern.vt.fb.modes.VGA-1 kernel: info: [drm] - kern.vt.fb.default_mode kernel: info: [drm] Connector SVIDEO-1: get mode from tunables: kernel: info: [drm] - kern.vt.fb.modes.SVIDEO-1 kernel: info: [drm] - kern.vt.fb.default_mode kernel: composite sync not supported kernel: fbd0 on drmn0 kernel: VT: Replacing driver "vga" with new "fb". -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath10k driver status?
On 19-02-04 00:29:29, Anthony Jenkins wrote: [snip] Hi Adrian. I too am wondering what the plan is for this chipset. I am currently using an awful USB wifi dongle. I can help with testing if needed - but I just really want to know if we should expect upstream support which is relatively stable in the next month or two. If not, I'll look for alternative solutions. Thanks. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2 removed?
On 2/11/19 6:36 PM, Steve Kargl wrote: On Mon, Feb 11, 2019 at 06:05:03PM +0100, Niclas Zeising wrote: On 2/11/19 5:20 PM, Steve Kargl wrote: On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote: Anyone have any idea which recent change broke the drm-legacy-kmod port. This is why I raised an issue with removal of drm2 from src/sys. How is suppose to be fixed? It was r343567. The merging of PAE and NO PAE pmap.h by kib removed all of the missing macros. :( Can you give attached patch a spin? Thanks! Regards -- Niclas The patch allows the port to be built. kldloading the i915kms module causes a 'black screen of death' I'll note that there seems to be a race condition in booting a kernel (with or without the drm2 stuff). During boot the kernel hangs (see below) : ---<>--- Copyright (c) 1992-2019 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT r343477 MOBILE i386 FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1) VT(vga): resolution 640x480 CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class CPU) Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x2010 AMD Features2=0x1 VT-x: (disabled in BIOS) HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3659202560 (3489 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) Firmware Warning (ACPI): Incorrect checksum in table [TCPA] - 0x80, should be 0x24 (20190108/tbprint-337) ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard Launching APs: 1 *** kernel hangs here sometimes *** Timecounter "TSC" frequency 1995048460 Hz quality 1000 random: entropy device external interface kbd1 at kbdmux0 Hi! I assume you load the kernel module either manually with kldload or using kld_list in rc.conf, not by loading it from the loader? So there is two bugs? One bug is that the kernel hangs while booting, and the other is that you get a black screen when loading the drm module after the kernel is mostly done booting? Regards -- Niclas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2 removed?
On Mon, Feb 11, 2019 at 06:05:03PM +0100, Niclas Zeising wrote: > On 2/11/19 5:20 PM, Steve Kargl wrote: > > On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote: > >> Anyone have any idea which recent change broke the > >> drm-legacy-kmod port. This is why I raised an issue > >> with removal of drm2 from src/sys. How is suppose > >> to be fixed? > >> > > > > It was r343567. The merging of PAE and NO PAE pmap.h > > by kib removed all of the missing macros. :( > > > > Can you give attached patch a spin? > Thanks! > Regards > -- > Niclas The patch allows the port to be built. kldloading the i915kms module causes a 'black screen of death' I'll note that there seems to be a race condition in booting a kernel (with or without the drm2 stuff). During boot the kernel hangs (see below) : ---<>--- Copyright (c) 1992-2019 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT r343477 MOBILE i386 FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1) VT(vga): resolution 640x480 CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class CPU) Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x2010 AMD Features2=0x1 VT-x: (disabled in BIOS) HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3659202560 (3489 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) Firmware Warning (ACPI): Incorrect checksum in table [TCPA] - 0x80, should be 0x24 (20190108/tbprint-337) ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard Launching APs: 1 *** kernel hangs here sometimes *** Timecounter "TSC" frequency 1995048460 Hz quality 1000 random: entropy device external interface kbd1 at kbdmux0 -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2 removed?
> On Mon, Feb 11, 2019 at 04:33:24PM +, Johannes Lundberg wrote: > > > > On 2/11/19 4:23 PM, Niclas Zeising wrote: > > > On 2/11/19 5:20 PM, Steve Kargl wrote: > > >> On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote: > > >>> Anyone have any idea which recent change broke the > > >>> drm-legacy-kmod port.? This is why I raised an issue > > >>> with removal of drm2 from src/sys.? How is suppose > > >>> to be fixed? > > >>> > > >> > > >> It was r343567.? The merging of PAE and NO PAE pmap.h > > >> by kib removed all of the missing macros. :( > > >> > > > > > > The code is still in base, but disabled by default.? I have to have a > > > look at this, but it might take a couple of days before we have a fix. > > > Regards > > > > Commit from 12 days ago and we get the news now... Any progress on the > > CI for drm modules? > > > > The commit ends with > > In collaboarion with: pho > Discussed with: emaste > Reviewed by:markj > MFC after: 2 weeks > Sponsored by: The FreeBSD Foundation > Differential revision: https://reviews.freebsd.org/D18894 > > No exp-run over ports. You'll likely see more reports when > the indicated MFC occurs in a day or two. If this breaks drm2, it must not be MFC'ed until that breakage is fixed, and I am sure kib knows that. I doubt there was any intent to brek drm2, it seems to have been over looked, and yet another reason to not unhook this from the builds in ^head. Rod https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2 removed?
On 2/11/19 5:20 PM, Steve Kargl wrote: On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote: Anyone have any idea which recent change broke the drm-legacy-kmod port. This is why I raised an issue with removal of drm2 from src/sys. How is suppose to be fixed? It was r343567. The merging of PAE and NO PAE pmap.h by kib removed all of the missing macros. :( Can you give attached patch a spin? Thanks! Regards -- Niclas Index: graphics/drm-legacy-kmod/Makefile === --- graphics/drm-legacy-kmod/Makefile (revision 492695) +++ graphics/drm-legacy-kmod/Makefile (working copy) @@ -22,7 +22,7 @@ USE_GITHUB= yes GH_ACCOUNT= FreeBSDDesktop GH_PROJECT= drm-legacy -GH_TAGNAME= 50ea058 +GH_TAGNAME= 1550ba3 .include Index: graphics/drm-legacy-kmod/distinfo === --- graphics/drm-legacy-kmod/distinfo (revision 492695) +++ graphics/drm-legacy-kmod/distinfo (working copy) @@ -1,3 +1,3 @@ -TIMESTAMP = 1548274203 -SHA256 (FreeBSDDesktop-drm-legacy-g20190109-50ea058_GH0.tar.gz) = aec43a977d644c65cd1a59297d6d6fd0a8df085932ebc7e2feb1af0823d4fbfe -SIZE (FreeBSDDesktop-drm-legacy-g20190109-50ea058_GH0.tar.gz) = 1676264 +TIMESTAMP = 1549903495 +SHA256 (FreeBSDDesktop-drm-legacy-g20190109-1550ba3_GH0.tar.gz) = 2922cd4a12594a3e431dd2eaac2780957ee6285fc0fc7eb6484d32e051c199a4 +SIZE (FreeBSDDesktop-drm-legacy-g20190109-1550ba3_GH0.tar.gz) = 1675960 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2 removed?
On Mon, Feb 11, 2019 at 04:33:24PM +, Johannes Lundberg wrote: > > On 2/11/19 4:23 PM, Niclas Zeising wrote: > > On 2/11/19 5:20 PM, Steve Kargl wrote: > >> On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote: > >>> Anyone have any idea which recent change broke the > >>> drm-legacy-kmod port. This is why I raised an issue > >>> with removal of drm2 from src/sys. How is suppose > >>> to be fixed? > >>> > >> > >> It was r343567. The merging of PAE and NO PAE pmap.h > >> by kib removed all of the missing macros. :( > >> > > > > The code is still in base, but disabled by default. I have to have a > > look at this, but it might take a couple of days before we have a fix. > > Regards > > Commit from 12 days ago and we get the news now... Any progress on the > CI for drm modules? > The commit ends with In collaboarion with: pho Discussed with: emaste Reviewed by:markj MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D18894 No exp-run over ports. You'll likely see more reports when the indicated MFC occurs in a day or two. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2 removed?
On 2/11/19 4:23 PM, Niclas Zeising wrote: > On 2/11/19 5:20 PM, Steve Kargl wrote: >> On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote: >>> Anyone have any idea which recent change broke the >>> drm-legacy-kmod port. This is why I raised an issue >>> with removal of drm2 from src/sys. How is suppose >>> to be fixed? >>> >> >> It was r343567. The merging of PAE and NO PAE pmap.h >> by kib removed all of the missing macros. :( >> > > The code is still in base, but disabled by default. I have to have a > look at this, but it might take a couple of days before we have a fix. > Regards Commit from 12 days ago and we get the news now... Any progress on the CI for drm modules? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2 removed?
Hi Steve, This looks like breakage from unifying PAE and non-PAE kernels in r343567. CCing kib@ for context. Cheers, -Enji > On Feb 11, 2019, at 08:12, Steve Kargl > wrote: > > Anyone have any idea which recent change broke the > drm-legacy-kmod port. This is why I raised an issue > with removal of drm2 from src/sys. How is suppose > to be fixed? > > > --- ttm_bo_manager.o --- > cc -O2 -pipe -march=core2 -fno-strict-aliasing -march=core2 -Werror > -D_KERNEL -DKLD_MODULE -nostdinc > -I/usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/drm2/../src/ > -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common -MD > -MF.depend.ttm_bo_manager.o -MTttm_bo_manager.o -mno-mmx -mno-sse > -msoft-float -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ > -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality -Wno-error-unused-function > -Wno-error-pointer-sign -Wno-error-shift-negative-value > -Wno-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 -c > /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo_manager.c > -o ttm_bo_manager.o > --- ttm_bo.o --- > /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1501:12: > error: use of undeclared identifier 'NPGPTD' >1, 0, VM_MAX_ADDRESS, PAGE_SIZE, 0, VM_MEMATTR_UNCACHEABLE); > ^ > ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' > #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) > ^ > ./machine/pmap.h:122:19: note: expanded from macro 'PTDPTDI' > #define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD) > ^ > ./machine/param.h:98:19: note: expanded from macro 'NPDEPTD' > #define NPDEPTD (NBPTD / sizeof(pd_entry_t)) > ^ > ./machine/param.h:96:17: note: expanded from macro 'NBPTD' > #define NBPTD (NPGPTD << PAGE_SHIFT) > ^ > /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1501:12: > error: use of undeclared identifier 'pd_entry_t' > ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' > #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) > ^ > ./machine/pmap.h:122:19: note: expanded from macro 'PTDPTDI' > #define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD) > ^ > ./machine/param.h:98:34: note: expanded from macro 'NPDEPTD' > #define NPDEPTD (NBPTD / sizeof(pd_entry_t)) >^ > /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1501:12: > error: use of undeclared identifier 'NTRPPTD' > ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' > #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) > ^ > ./machine/pmap.h:122:29: note: expanded from macro 'PTDPTDI' > #define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD) > ^ > /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1501:12: > error: use of undeclared identifier 'NPGPTD' > ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' > #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) > ^ > ./machine/pmap.h:122:39: note: expanded from macro 'PTDPTDI' > #define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD) > ^ > /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1505:10: > error: use of undeclared identifier 'NPGPTD' >0, VM_MAX_ADDRESS, PAGE_SIZE, 0)) { > ^ > ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' > #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) > ^ > ./machine/pmap.h:122:19: note: expanded from macro 'PTDPTDI' > #define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD) > ^ > ./machine/param.h:98:19: note: expanded from macro 'NPDEPTD' > #define NPDEPTD (NBPTD / sizeof(pd_entry_t)) > ^ > ./machine/param.h:96:17: note: expanded from macro 'NBPTD' > #define NBPTD (NPGPTD << PAGE_SHIFT) > ^ > /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1505:10: > error: use of undeclared identifier 'pd_entry_t' > ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' > #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) > ^ > ./machine/pmap.h:122:19: note: ex
Re: drm2 removed?
On 2/11/19 5:20 PM, Steve Kargl wrote: On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote: Anyone have any idea which recent change broke the drm-legacy-kmod port. This is why I raised an issue with removal of drm2 from src/sys. How is suppose to be fixed? It was r343567. The merging of PAE and NO PAE pmap.h by kib removed all of the missing macros. :( The code is still in base, but disabled by default. I have to have a look at this, but it might take a couple of days before we have a fix. Regards -- Niclas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm2 removed?
On 2/11/19 5:12 PM, Steve Kargl wrote: Anyone have any idea which recent change broke the drm-legacy-kmod port. This is why I raised an issue with removal of drm2 from src/sys. How is suppose to be fixed? --- ttm_bo_manager.o --- cc -O2 -pipe -march=core2 -fno-strict-aliasing -march=core2 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/drm2/../src/ -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common -MD -MF.depend.ttm_bo_manager.o -MTttm_bo_manager.o -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 -c /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo_manager.c -o ttm_bo_manager.o --- ttm_bo.o --- /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1501:12: error: use of undeclared identifier 'NPGPTD' 1, 0, VM_MAX_ADDRESS, PAGE_SIZE, 0, VM_MEMATTR_UNCACHEABLE); ^ ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) ^ ./machine/pmap.h:122:19: note: expanded from macro 'PTDPTDI' #define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD) ^ ./machine/param.h:98:19: note: expanded from macro 'NPDEPTD' #define NPDEPTD (NBPTD / sizeof(pd_entry_t)) ^ ./machine/param.h:96:17: note: expanded from macro 'NBPTD' #define NBPTD (NPGPTD << PAGE_SHIFT) ^ /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1501:12: error: use of undeclared identifier 'pd_entry_t' ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) ^ ./machine/pmap.h:122:19: note: expanded from macro 'PTDPTDI' #define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD) ^ ./machine/param.h:98:34: note: expanded from macro 'NPDEPTD' #define NPDEPTD (NBPTD / sizeof(pd_entry_t)) ^ /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1501:12: error: use of undeclared identifier 'NTRPPTD' ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) ^ ./machine/pmap.h:122:29: note: expanded from macro 'PTDPTDI' #define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD) ^ /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1501:12: error: use of undeclared identifier 'NPGPTD' ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) ^ ./machine/pmap.h:122:39: note: expanded from macro 'PTDPTDI' #define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD) ^ /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1505:10: error: use of undeclared identifier 'NPGPTD' 0, VM_MAX_ADDRESS, PAGE_SIZE, 0)) { ^ ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) ^ ./machine/pmap.h:122:19: note: expanded from macro 'PTDPTDI' #define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD) ^ ./machine/param.h:98:19: note: expanded from macro 'NPDEPTD' #define NPDEPTD (NBPTD / sizeof(pd_entry_t)) ^ ./machine/param.h:96:17: note: expanded from macro 'NBPTD' #define NBPTD (NPGPTD << PAGE_SHIFT) ^ /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1505:10: error: use of undeclared identifier 'pd_entry_t' ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) ^ ./machine/pmap.h:122:19: note: expanded from macro 'PTDPTDI' #define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD) ^ ./machine/param.h:98:34: note: expanded from macro 'NPDEPTD' #define NPDEPTD (NBPTD / sizeof(pd_entry_t)) ^ /usr/ports/gr
Re: drm2 removed?
On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote: > Anyone have any idea which recent change broke the > drm-legacy-kmod port. This is why I raised an issue > with removal of drm2 from src/sys. How is suppose > to be fixed? > It was r343567. The merging of PAE and NO PAE pmap.h by kib removed all of the missing macros. :( -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
drm2 removed?
Anyone have any idea which recent change broke the drm-legacy-kmod port. This is why I raised an issue with removal of drm2 from src/sys. How is suppose to be fixed? --- ttm_bo_manager.o --- cc -O2 -pipe -march=core2 -fno-strict-aliasing -march=core2 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/drm2/../src/ -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common -MD -MF.depend.ttm_bo_manager.o -MTttm_bo_manager.o -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 -c /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo_manager.c -o ttm_bo_manager.o --- ttm_bo.o --- /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1501:12: error: use of undeclared identifier 'NPGPTD' 1, 0, VM_MAX_ADDRESS, PAGE_SIZE, 0, VM_MEMATTR_UNCACHEABLE); ^ ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) ^ ./machine/pmap.h:122:19: note: expanded from macro 'PTDPTDI' #define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD) ^ ./machine/param.h:98:19: note: expanded from macro 'NPDEPTD' #define NPDEPTD (NBPTD / sizeof(pd_entry_t)) ^ ./machine/param.h:96:17: note: expanded from macro 'NBPTD' #define NBPTD (NPGPTD << PAGE_SHIFT) ^ /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1501:12: error: use of undeclared identifier 'pd_entry_t' ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) ^ ./machine/pmap.h:122:19: note: expanded from macro 'PTDPTDI' #define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD) ^ ./machine/param.h:98:34: note: expanded from macro 'NPDEPTD' #define NPDEPTD (NBPTD / sizeof(pd_entry_t)) ^ /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1501:12: error: use of undeclared identifier 'NTRPPTD' ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) ^ ./machine/pmap.h:122:29: note: expanded from macro 'PTDPTDI' #define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD) ^ /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1501:12: error: use of undeclared identifier 'NPGPTD' ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) ^ ./machine/pmap.h:122:39: note: expanded from macro 'PTDPTDI' #define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD) ^ /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1505:10: error: use of undeclared identifier 'NPGPTD' 0, VM_MAX_ADDRESS, PAGE_SIZE, 0)) { ^ ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) ^ ./machine/pmap.h:122:19: note: expanded from macro 'PTDPTDI' #define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD) ^ ./machine/param.h:98:19: note: expanded from macro 'NPDEPTD' #define NPDEPTD (NBPTD / sizeof(pd_entry_t)) ^ ./machine/param.h:96:17: note: expanded from macro 'NBPTD' #define NBPTD (NPGPTD << PAGE_SHIFT) ^ /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1505:10: error: use of undeclared identifier 'pd_entry_t' ./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS' #define VM_MAX_ADDRESS VADDR(PTDPTDI, 0) ^ ./machine/pmap.h:122:19: note: expanded from macro 'PTDPTDI' #define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD) ^ ./machine/param.h:98:34: note: expanded from macro 'NPDEPTD' #define NPDEPTD (NBPTD / sizeof(pd_entry_t)) ^ /usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm
Re: Lua Loader Failure to Include
On Mon, Feb 11, 2019 at 9:14 AM Cy Schubert wrote: > > On February 11, 2019 5:05:37 AM PST, Cy Schubert > wrote: > >Hi, > > > >Under the old Forth loader the line: > > > > include /boot/testbed/test_sys > > > >would load the file and execute loader commands. > > > >However the the Lua loader results in the following: > > > >OK include /boot/testbed/amd64-current-r > >no error message > >OK > > > >Looking at the code, interp_include() expects to run actual Lua code > >using luaL_dofile(). Is this an intended change? > > > >The loader statements the file above is intending to execute are: > > > >echo > >echo > >echo testbed/amd64-current-r (12.0-CURRENT) loader file selected > >set bootdev=disk1s4a: > >include /boot/testbed/current.hints > >include /boot/testbed/do_load_KOMQUATS > > > >Let me know if I am to rewrite these loader statements into Lua or > >whether the Lua loader should be taught to read loader statements > >instead. > > Thinking about this while travelling to $JOB, it's probably best to leave it > as is. I'll rewrite the includes into Lua. The benefit is greater flexibility > and functionality. > Indeed, this is the best course of action. The translation shouldn't be too hard -- the main caveat to note is that your current.hints include likely can't be required in directly, you'll need to run it through config.load(). I intend to write up a wiki page or something for converting common Forth-isms to either portable loader.conf(5) directives or Lua-specific equivalents, depending on the feasibility of the former. Thanks, Kyle Evans ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Lua Loader Failure to Include
On February 11, 2019 5:05:37 AM PST, Cy Schubert wrote: >Hi, > >Under the old Forth loader the line: > > include /boot/testbed/test_sys > >would load the file and execute loader commands. > >However the the Lua loader results in the following: > >OK include /boot/testbed/amd64-current-r >no error message >OK > >Looking at the code, interp_include() expects to run actual Lua code >using luaL_dofile(). Is this an intended change? > >The loader statements the file above is intending to execute are: > >echo >echo >echo testbed/amd64-current-r (12.0-CURRENT) loader file selected >set bootdev=disk1s4a: >include /boot/testbed/current.hints >include /boot/testbed/do_load_KOMQUATS > >Let me know if I am to rewrite these loader statements into Lua or >whether the Lua loader should be taught to read loader statements >instead. Thinking about this while travelling to $JOB, it's probably best to leave it as is. I'll rewrite the includes into Lua. The benefit is greater flexibility and functionality. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Lua Loader Failure to Include
Hi, Under the old Forth loader the line: include /boot/testbed/test_sys would load the file and execute loader commands. However the the Lua loader results in the following: OK include /boot/testbed/amd64-current-r no error message OK Looking at the code, interp_include() expects to run actual Lua code using luaL_dofile(). Is this an intended change? The loader statements the file above is intending to execute are: echo echo echo testbed/amd64-current-r (12.0-CURRENT) loader file selected set bootdev=disk1s4a: include /boot/testbed/current.hints include /boot/testbed/do_load_KOMQUATS Let me know if I am to rewrite these loader statements into Lua or whether the Lua loader should be taught to read loader statements instead. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"