Re: sysutils/pam_xdg: Cancelled on -CURRENT
On Tue, 19 Mar 2024 07:55:15 +
Alastair Hogge wrote:
> On 2024-03-19 15:23, Emmanuel Vadot wrote:
> > Hi,
>
> Hey Emmanuel,
>
> > On Tue, 19 Mar 2024 06:54:27 +
> > Alastair Hogge wrote:
> >
> >> Hello,
> >>
> >> Recently a similar module (PAM) mentioned in the subject was committed
> >> to base[1]. The module in base masks the currently installed Port, the
> >> man page can be accessed with man -M /usr/local/share/man 8 pam_xdg,
> >> however, I can now no longer build the Port. I noticed that the base
> >> module has no WITHOUT_ option, tho, that might be extreme for one
> >> module, but then again, the base module masks a more feature full
> >> module. What is the practice to enable use of the Port again? At the
> >> moment I am updating my host, and testing the following:
> >>
> >> diff --git a/lib/libpam/modules/modules.inc
> >> b/lib/libpam/modules/modules.inc
> >> index f3ab65333f4f..ddbb326f0312 100644
> >> --- a/lib/libpam/modules/modules.inc
> >> +++ b/lib/libpam/modules/modules.inc
> >> @@ -30,4 +30,3 @@ MODULES += pam_ssh
> >> .endif
> >> MODULES+= pam_tacplus
> >> MODULES+= pam_unix
> >> -MODULES+= pam_xdg
> >> \ No newline at end of file
> >>
> >> 1:
> >> https://cgit.freebsd.org/src/commit/?id=6e69612d5df1c1d5bd86990ea4d9a170c030b292
> >>
> >> Thanks.
> >>
> >
> > I don't see why you can't build the ports.
>
> From sysutils/pam_xdg[2]:
>
> if exists(/usr/lib/pam_xdg.so)
> IGNORE= module name conflict with a different implementation in
> base system
> endif
Ah yes, I've missed this :)
> > Using would be a problem but why do you want to use it now that we
> > have one in base ?
> > Do you have any problems with the one in base ?
>
> I would like to continue using sysutils/pam_xdg because it handles all
> ${XDG_*_HOME}, and local name spaces.
XDG_*_HOME variables aren't needed, all applications must have a
fallback to the base directories in the spec and sysutils/pam_xdg
doesn't offer to use other directories so that's why I didn't implement
those in the base one.
What do you mean by "local name spaces" ?
> 2: https://cgit.freebsd.org/ports/tree/sysutils/pam_xdg/Makefile#n16
>
> Thanks.
>
Cheers,
--
Emmanuel Vadot
Re: sysutils/pam_xdg: Cancelled on -CURRENT
Hi, On Tue, 19 Mar 2024 06:54:27 + Alastair Hogge wrote: > Hello, > > Recently a similar module (PAM) mentioned in the subject was committed > to base[1]. The module in base masks the currently installed Port, the > man page can be accessed with man -M /usr/local/share/man 8 pam_xdg, > however, I can now no longer build the Port. I noticed that the base > module has no WITHOUT_ option, tho, that might be extreme for one > module, but then again, the base module masks a more feature full > module. What is the practice to enable use of the Port again? At the > moment I am updating my host, and testing the following: > > diff --git a/lib/libpam/modules/modules.inc > b/lib/libpam/modules/modules.inc > index f3ab65333f4f..ddbb326f0312 100644 > --- a/lib/libpam/modules/modules.inc > +++ b/lib/libpam/modules/modules.inc > @@ -30,4 +30,3 @@ MODULES += pam_ssh > .endif > MODULES+= pam_tacplus > MODULES+= pam_unix > -MODULES+= pam_xdg > \ No newline at end of file > > 1: > https://cgit.freebsd.org/src/commit/?id=6e69612d5df1c1d5bd86990ea4d9a170c030b292 > > Thanks. > I don't see why you can't build the ports. Using would be a problem but why do you want to use it now that we have one in base ? Do you have any problems with the one in base ? Cheers, -- Emmanuel Vadot
Re: Possible PEBKAC bug for fwget(8)?
Hi Kenneth, On Thu, 6 Jul 2023 23:58:06 + Kenneth Raplee wrote: > Hi folks, > > I was made aware of the fwget(8) utility on IRC after mentioning how I > supplemented a missing amdgpu firmware from the gpu-firmware-kmod package for > my RX 6600 XT from the linux-firmware git repo in order to load the amdgpu > 515 driver without the screen freezing at boot. > > When I tried running `fwget -vn pci`, it only prints out the following usage > info: > > ``` > Usage: fwget [options] [subsystem] > > Supported subsystems > pci > > Options: > -n-- Do not install package, only print the results > -v-- More verbose > ``` > > I tried running the command other ways, outputs the same thing. > > I didn't think this was worth reporting as a bug since it seems like a minor > fix. > > % uname -aKU > FreeBSD freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #0 > main-n263946-ac40021c935d: Tue Jul 4 09:10:17 PDT 2023 > root@freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400092 > 1400092 > > Sincerely, > Kenneth Thanks for reporting, it's fixed now in https://cgit.freebsd.org/src/commit/?id=c81495a621c461b3d3395a7c5b0e73458201c443 Note that -vn will not work but -v -n will, switching to getopt(1) should fix that but I don't plan to work on that right now. Cheers, -- Emmanuel Vadot
Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?
On Fri, 12 May 2023 00:20:47 +0300 Toomas Soome wrote: > > > > On 12. May 2023, at 00:11, Oleg Lelchuk wrote: > > > > Guys, there is something that I find puzzling. Why doesn't the EFI boot > > loader want to display the graphical orb logo in its boot menu on an Asus > > Prime 7590-P motherboard? Is there something quirky about this particular > > motherboard that forces the FreeBSD EFI loader to display the old style > > ASCII orb logo in its boot menu? Please explain to me the cause of this > > problem and if possible, give me a solution to it. > > There can be two reasons. One is that resolution is low and there is no space > to put the image on. Second one is that the screen is forced to use ?text? > mode, which happens when system has configured to have serial console > (redirection). > > rgds, > toomas There is a third reason : you have multiple screens and EFI firmware output on all of them. Never took the time to dig into this one. -- Emmanuel Vadot
Re: CFT: fwget(8)
On Thu, 11 May 2023 12:03:51 +0300
Oleksandr Kryvulia wrote:
> 11.05.23 10:59, Emmanuel Vadot :
> > Hello,
> >
> > Recently I've adde the fwget(8) utility, see
> > https://cgit.freebsd.org/src/commit/?id=d198b8774d2cfb6f140893e1c6236af9e97d1497
> >
> > The goal of this program is to scan the hardware and download the
> > needed firmwares, for now it only do that for Intel GPUs and recent AMD
> > GPUs (the one supported by amdgpu.ko).
> >
> > I'd like to know if I handled correctly the mapping between ids on
> > Intel and AMD GPUs (for i915kms and amdgpu drm module).
> > I'm pretty sure that Intel is correct but I could have messed up some
> > AMD ones. Also for some AMD GPUs you need two firmware generations and
> > it's hard to know by looking at the code. It would be good to fix any
> > bugs/miss-match before 14.0
> > The best way to test if everything works is :
> >
> > 1/ pkg delete gpu-firmware-\*
> > 2/ (optional) pkg install drm-515-kmod/drm-510-kmod (if you had the
> > meta package drm-kmod installed it would have been removed in step 1)
> > 3/ fwget
> > 4/ kldload i915kms/amdgpu
> >
> > For i915kms just check dmesg for lines saying something like
> > "drmn0: successfully loaded firmware image ...", this means that
> > everything is correct for your hardware.
> > If you see a line like
> > "drmn0: could not load firmware image ..."
> > please open a PR on bugzilla with dmesg and pciconf -vl attached.
> > Note that firmware for i915kms are optional, they only help with power
> > management and suspend/resume.
> >
> > For amdgpu the driver will fail to attach and you will loose the
> > display if the firmwares aren't present so you will need to ssh into
> > the machine to check for similar lines like i915kms.
> >
> > Thanks,
> >
>
> Hi,
> for me it correctly detects needed package
> gpu-firmware-intel-kmod-kabylake, but not install it.
> Propposed fix:
>
> - pkg install -q ${package}
> + pkg install -qy ${package}
Yes this is on purpose, I didn't wanted to automatically install
packages until bugs where solved, but I planned to enable this before
14.0.
Cheers,
--
Emmanuel Vadot
CFT: fwget(8)
Hello, Recently I've adde the fwget(8) utility, see https://cgit.freebsd.org/src/commit/?id=d198b8774d2cfb6f140893e1c6236af9e97d1497 The goal of this program is to scan the hardware and download the needed firmwares, for now it only do that for Intel GPUs and recent AMD GPUs (the one supported by amdgpu.ko). I'd like to know if I handled correctly the mapping between ids on Intel and AMD GPUs (for i915kms and amdgpu drm module). I'm pretty sure that Intel is correct but I could have messed up some AMD ones. Also for some AMD GPUs you need two firmware generations and it's hard to know by looking at the code. It would be good to fix any bugs/miss-match before 14.0 The best way to test if everything works is : 1/ pkg delete gpu-firmware-\* 2/ (optional) pkg install drm-515-kmod/drm-510-kmod (if you had the meta package drm-kmod installed it would have been removed in step 1) 3/ fwget 4/ kldload i915kms/amdgpu For i915kms just check dmesg for lines saying something like "drmn0: successfully loaded firmware image ...", this means that everything is correct for your hardware. If you see a line like "drmn0: could not load firmware image ..." please open a PR on bugzilla with dmesg and pciconf -vl attached. Note that firmware for i915kms are optional, they only help with power management and suspend/resume. For amdgpu the driver will fail to attach and you will loose the display if the firmwares aren't present so you will need to ssh into the machine to check for similar lines like i915kms. Thanks, -- Emmanuel Vadot
Re: Switching MK_ATM to no by default
On Fri, 27 Jan 2023 11:34:10 +0100 Emmanuel Vadot wrote: > > Hello, > > It's 2023 and I don't think that ATM have any users (but could be > wrong hence the mail). > Is everyone ok with switching MK_ATF to no by default ? > This will stop installed sscop(1) and libngatm (Netgraph support). > > If no one complain I'll do that for 14-CURRENT mid-february. > > Cheers, See https://reviews.freebsd.org/D38844 and child reviews. Cheers, -- Emmanuel Vadot
Re: Could not change brightness anymore with i915kms & acpi_video modules c 202211
On Thu, 02 Feb 2023 20:58:58 + "Poul-Henning Kamp" wrote: > > parv/FreeBSD writes: > > > > Does backlight(8) works for you? > > > > Thanks for the clue. It does! It does ... > > > > - I get the same number back via "backlight" without any arguments as > > what I gave it earlier. There was no reporting of value being > > subtracted by one; > > Sorry for the delay in reporting back. > > I consistently read one less back, except for 0 and 100. Even 50 ? > (This could easily be a BIOS bug) At first I though so too but I'll need to check if this isn't a rounding error between backlight(4) and linuxkpi wrappers. I know that some hardware don't have a perfect pwm controller for the backlight and so you have only some steps that it can do (but you don't know them). > It also looks like the "no-op" behaviour I reported previously have > gone away with my latest kernel update. Weird, nothing has changed for a while in this area but happy that it's fixed ;) > But I see a new behaviour, but this may be intentional: When it > comes out of screen-blanking, it goes to 100 (and reports 100). I'm not too surprised about this behavior, there is probably something that we could do about it but this will need more digging in linux framework and the drm drivers. > Also happens when an external monitor is connected, which is a > bit annoying... So if you have, let's say brightness at 50%, and you plug an external monitor, brightness goes up to 100% ? > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > -- Emmanuel Vadot
Re: Could not change brightness anymore with i915kms & acpi_video modules c 202211
On Tue, 31 Jan 2023 13:09:39 + "Poul-Henning Kamp" wrote: > ---- > Emmanuel Vadot writes: > > > > > Does backlight(8) works for you? > > > > > > Speaking of backlight(8): On my T14s, I see the following: > > > > > > If I set the light with backlight(8) to something, say 30%, and then > > > change the power-situation, for instance by unplugging the charger, > > > the backlight goes up to 100%. > > > > > > If I then try to set it back to 30% with backlight(8), nothing happens. > > > > > > If I use any other value, for instance 31%, backlight(8) does the job. > > > > > > I guess somewhere some code says "It's always 30%, just return" ? > > > > > > This might be a bit confusing if you have the intensity encoded in > > > some script, which then "sometimes does not work"... > > > > Smells like > > https://cgit.freebsd.org/src/commit/sys/dev/backlight/backlight.c?id=e26ef41f79902991c772b59927c721aa7fa5fc64 > > It's not in 13.1 but will be in 13.2 > > I'm running > > 14.0-CURRENT #0 main-n260119-7f2109f240c2: Mon Jan 16 22:54:18 UTC 2023 What does backlight reports after you've unplugged the AC adaptor ? -- Emmanuel Vadot
Re: Could not change brightness anymore with i915kms & acpi_video modules c 202211
On Tue, 31 Jan 2023 12:33:02 + "Poul-Henning Kamp" wrote: > > Oleksandr Kryvulia writes: > > > Does backlight(8) works for you? > > Speaking of backlight(8): On my T14s, I see the following: > > If I set the light with backlight(8) to something, say 30%, and then > change the power-situation, for instance by unplugging the charger, > the backlight goes up to 100%. > > If I then try to set it back to 30% with backlight(8), nothing happens. > > If I use any other value, for instance 31%, backlight(8) does the job. > > I guess somewhere some code says "It's always 30%, just return" ? > > This might be a bit confusing if you have the intensity encoded in > some script, which then "sometimes does not work"... Smells like https://cgit.freebsd.org/src/commit/sys/dev/backlight/backlight.c?id=e26ef41f79902991c772b59927c721aa7fa5fc64 It's not in 13.1 but will be in 13.2 > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > -- Emmanuel Vadot
Switching MK_ATM to no by default
Hello, It's 2023 and I don't think that ATM have any users (but could be wrong hence the mail). Is everyone ok with switching MK_ATF to no by default ? This will stop installed sscop(1) and libngatm (Netgraph support). If no one complain I'll do that for 14-CURRENT mid-february. Cheers, -- Emmanuel Vadot
Re: loader.efi module path vs kernel directory
On Thu, 20 Oct 2022 13:03:26 +0300 Andriy Gapon wrote: > > I recently needed to recover a system by manually preloading a driver. > To a bit of surprise, simple 'load $modname' did not work, I had to use 'load > /boot/kernel/$modname.ko'. I didn't have to do this in a long time, but I > recall that the short command used to work. Additionally, required modules > also > failed to get loaded automatically because loader couldn't find them. > > I am not sure what the issue is. Is it that /boot/kernel is not in module > path > (as per /boot/defaults/loader.conf) ? Or is it that /boot/kernel does not get > added to the *effective* module path? > > Thanks! > -- > Andriy Gapon > if you escape to prompt directly loader didn't loaded all it's config so there is no modulepath defined, you need to 'boot-conf' to load the configuration files. Cheers, -- Emmanuel Vadot
Re: WITH_BHYVE_SNAPSHOT broken after 9cc9abf4
On Mon, 12 Sep 2022 23:05:29 + Filipe da Silva Santos wrote: > int vcpu declared in line 1247 isn't being used, since it's now being > redefined inside the for loop in line 1589. > > diff --git a/usr.sbin/bhyve/bhyverun.c b/usr.sbin/bhyve/bhyverun.c > index 550cc9d15..27f1d8ea8 100644 > --- a/usr.sbin/bhyve/bhyverun.c > +++ b/usr.sbin/bhyve/bhyverun.c > @@ -1244,7 +1244,6 @@ main(int argc, char *argv[]) > #ifdef BHYVE_SNAPSHOT > char *restore_file; > struct restore_state rstate; > - int vcpu; > > restore_file = NULL; > #endif Hello Filipe, Sorry for the breakage, should be fixed in 10c6af344108. -- Emmanuel Vadot
Re: Problem with Radeon
On Tue, 7 Jun 2022 12:10:35 + (UTC) Filippo Moretti wrote: > I have reinstalled CURRENT and I get an error while trying to initialize > radeon:it was working fine before reinstalling CURRENT. > > [drm] radeon kernel modesetting enabled. > > drmn0: on vgapci0 > > vgapci0: child drmn0 requested pci_enable_io > > vgapci0: child drmn0 requested pci_enable_io > > sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)! > > [drm] initializing kernel modesetting (REDWOOD 0x1002:0x68D8 0x1043:0x0356 > 0x00) . > > [drm ERROR :radeon_atombios_init] Unable to find PCI I/O BAR; using MMIO for > ATO M IIO > > ATOM BIOS: 68D8.12.17.0.4.AS06.U122 > drmn0: VRAM: 1024M 0x - 0x3FFF (1024M used) > drmn0: GTT: 1024M 0x4000 - 0x7FFF > [drm] Detected VRAM RAM=1024M, BAR=256M > [drm] RAM width 128bits DDR > [TTM] Zone kernel: Available graphics memory: 8373714 KiB > [TTM] Zone dma32: Available graphics memory: 2097152 KiB > [TTM] Initializing pool allocator > [drm] radeon: 1024M of VRAM memory ready > [drm] radeon: 1024M of GTT memory ready. > [drm] Loading REDWOOD Microcode > drmn0: could not load firmware image 'radeon/REDWOOD_pfp.bin' > r600_cp: Failed to load firmware "radeon/REDWOOD_pfp.bin" > [drm ERROR :evergreen_init] Failed to load firmware! > drmn0: Fatal error during GPU init > [drm] radeon: finishing device. > [TTM] Finalizing pool allocator > [TTM] Zone kernel: Used memory at exit: 0 KiB > [TTM] Zone dma32: Used memory at exit: 0 KiB > [drm] radeon: ttm finalized > Warning: can't remove non-dynamic nodes (dri)! > device_attach: drmn0 attach returned 2 > acpi_wmi0: on acpi0 > These are the ports installed:drm-510-kmod-5.10.113_1 DRM drivers > modules > drm-kmod-20220501 Metaport of DRM modules for the linuxkpi-based > KMS components > gpu-firmware-amd-kmod-banks-20220511 Firmware modules for banks AMD GPUs > gpu-firmware-kmod-20220511,1 Firmware modules for the drm-kmod drivers > gpu-firmware-radeon-kmod-aruba-20220511 Firmware modules for aruba Radeon GPUs "drmn0: could not load firmware image 'radeon/REDWOOD_pfp.bin'" You don't have the firmware installed for your card. How did you installed the packages ? because I see that you have gpu-firmware-kmod so it should have installed all of them. Anyway, pkg install gpu-firmware-radeon-kmod-redwood should solve your problems. > FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-85d7875d42: Mon Jun > 6 13:40:11 CEST 2022 filippo@STING:/usr/obj/usr/src/amd64.amd64/sys/STING > amd64 -- Emmanuel Vadot
Re: no hw.acpi.video.lcd0 with graphics/drm-510-kmod
On Sun, 22 May 2022 09:08:12 -0700 Pete Wright wrote: > hello, > i have a lenovo P43s laptop running current. i've noticed that since > graphics/drm-510-kmod became available hw.acpi.video.lcd0 ceases to > exist (which makes it impossible to adjust screen brightness). i've > installed graphics/drm-54-kmod and things work as expected. previously > i was running drm-devel-kmod without issues, so i think it's probably an > issue with the 5.10 driver? > > i can file a bug report for this (or just test out patches here if > that's easier), but wanted to see if anyone here had observed this on > other laptops first. > > cheers, > -pete > > -- > Pete Wright > p...@nomadlogic.org > @nomadlogicLA > > Not sure what's happening as this sysctl is exposed by acpi_video(4) and not related to drm. But you shouldn't need this, backlight(8) should work everywhere once drm is loaded. Cheers, -- Emmanuel Vadot
Re: loader_4th.efi broke?
On Fri, 20 May 2022 20:19:58 +0300 Toomas Soome wrote: > > > > On 20. May 2022, at 20:11, Bjoern A. Zeeb > > wrote: > > > > On Fri, 20 May 2022, Toomas Soome wrote: > > > >>> On 20. May 2022, at 20:00, Bjoern A. Zeeb > >>> wrote: > >>> > >>> Hi, > >>> > >>> something between > >>> 255692.f70de61e567df59bceb2d18c8bc1b54943a7466b and > >>> 255723.b3fa36efe797445cb0b4fd26d79226836db2a2b3 > >>> made loader_4th.efi go all > >>> "failed to allocate staging area: 9" > >>> > >>> I am netbooting booting, no ZFS involved. > >>> One other data point: the base system compile may have changed in that > >>> time. > >>> > >>> I haven't dug into yet. Is anyone else seeing this? > >>> > >> > >> staging area will be allocated very early, so for some reason either the > >> memory map is fragmented or there is just too low memory. > >> > >> 9 is EFI_OUT_OF_RESOURCES. > > > > The UEFI hasn't changed; 64GB of memory haven't changed. Power > > cycling didn't make a difference. Going back to the old one > > immediately worked again. I saw no changes in stand/ relevant. > > > > Is there a way to debug this or should we simply "stop" if this fails > > rather than endlessly fill the console with it? > > > > > um, ok 64GB should be plenty;) of course, if the firmware is squashing low > memory map to small chunks, then there is problem (we are asking to use low > 4GB because of buggy firmwares?), but you can try loader_lua.efi. The other > cause could be grown kernel modules - we try to allocate 64MB staging area > first, if it is not enough, then we try to get larger chunk?. > > Of course, screen spamming is bug, that should not happen. > > rgds, > toomas See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264021 It was bisected to the latest llvm update, I haven't digged yet. -- Emmanuel Vadot
Re: 'set but unused' breaks drm-*-kmod
On Thu, 21 Apr 2022 08:51:26 -0400
Michael Butler wrote:
> On 4/21/22 03:42, Emmanuel Vadot wrote:
> >
> > Hello Michael,
> >
> > On Wed, 20 Apr 2022 23:39:12 -0400
> > Michael Butler wrote:
> >
> >> Seems this new requirement breaks kmod builds too ..
> >>
> >> The first of many errors was (I stopped chasing them all for lack of
> >> time) ..
> >>
> >> --- amdgpu_cs.o ---
> >> /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.7.19_3/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1210:26:
> >> error: variable 'priority' set but not used
> >> [-Werror,-Wunused-but-set-variable]
> >> enum drm_sched_priority priority;
> >> ^
> >> 1 error generated.
> >> *** [amdgpu_cs.o] Error code 1
> >>
> >
> > How are you building the port, directly or with PORTS_MODULES ?
> > I do make passes on the warning for drm and I did for set-but-not-used
> > case but unfortunately this option doesn't exists in 13.0 so I couldn't
> > apply those in every branch.
>
> I build this directly on -current. I'm guessing that these are what
> triggered this behaviour:
>
> commit 8b83d7e0ee54416b0ee58bd85f9c0ae7fb3357a1
> Author: John Baldwin
> Date: Mon Apr 18 16:06:27 2022 -0700
>
> Make -Wunused-but-set-variable a fatal error for clang 13+ for
> kernel builds.
>
> Reviewed by:imp, emaste
> Differential Revision: https://reviews.freebsd.org/D34949
>
> commit 615d289ffefe2b175f80caa9b1e113c975576472
> Author: John Baldwin
> Date: Mon Apr 18 16:06:14 2022 -0700
>
> Re-enable set but not used warnings for kernel builds.
>
> make tinderbox now passes with this warning enabled as a fatal error,
> so revert the change to hide it in preparation for making it fatal.
>
> This reverts commit e8e691983bb75e80153b802f47733f1531615fa2.
>
> Reviewed by:imp, emaste
> Differential Revision: https://reviews.freebsd.org/D34948
>
>
Ok I see,
I won't have time until monday (maybe tuesday to fix this) but if
someone wants to beat me to it we should add some new CWARNFLAGS for
each problematic files in the 5.4-lts and 5.7-table branches of
drm-kmod (master which is following 5.10 is already good) only
if $ {COMPILER_VERSION} >= 13.
Cheers,
--
Emmanuel Vadot
Re: Daily black screen of death
Hello Steve, On Tue, 19 Apr 2022 11:32:32 -0700 Steve Kargl wrote: > FYI, > > I'm experiencing an almost daily black screen of death panic. > Kernel, world, drm-current-kmod, and gpu-firmware-kmod were > all rebuilt and installed at the same time. Uname shows > > FreeBSD 14.0-CURRENT #0 main-n254360-eb9d205fa69: Tue Apr 5 13:49:47 PDT 2022 > > So, April 5th sources. > > The panic results in a keyboard lock and no dump. The system > does not have a serial console. Only recourse is a hard rest. > > Hand transcribed from photo > > _sleep() at _sleep+0x38a/frame 0xfe012b7c0680 > buf_daemon_shutdown() at buf_daemon_shutdown+0x6b/frame 0xfe012b7c06a0 > kern_reboot() at kern_reboot+0x2ae/frame 0xfe012b7c06e0 > vpanic() at vpanic+0x1ee/frame 0xfe012b7c0730 > panic() at panic+0x43/frame 0xfe012b7c0790 > > Above repeats 100s of time scrolling off the screen with ever > increasing frame pointer. > > Final message, > > mi_switch() at mi_switch+0x18e/frame 0xfe012b7c14b0 > __mtx_lock_sleep() at __mtx_lock_sleep+0x173/frame 0xfe012b7c1510 > __mtx_lock_flags() at __mtx_lock_flags+0xc0/frame 0xfe012b7c1550 > linux_wake_up() at linux_wake_up+0x38/frame 0xfe012b7c15a0 > radeon_fence_is_signaled() at radeon_fence_is_signaled+0x99/frame > 0xfe012b7c15f0 > dma_resv_add_shared_fence() at dma_resv_add_shared_fence+0x99/frame > 0xfe012b7c1640 > ttm_eu_fence_buffer_objects() at ttm_eu_fence_buffer_objects+0x79/frame > 0xfe012b7c1680 > radeon_cs_parser_fini() at radeon_cs_parser_fini+0x53/frame 0xfe012b7c16b0 > radeaon_cs_ioctl() at radeaon_cs_ioctl+0x75e/frame 0xfe012b7c1b30 > drm_ioctl_kernel() at drm_ioctl_kernel+0xc7/frame 0xfe012b7c1b80 > drm_ioctl() at drm_ioctl+0x2c3/frame 0xfe012b7c1c70 > linux_file_ioctl() at linux_file_ioctl+0x309/frame 0xfe012b7c1cd0 > kern_ioctl() at kern_ioctl+0x1dc/frame 0xfe012b7c1d40 > sys_ioctl() at sys_ioctl+0x121/frame 0xfe012b7c1e10 > amd64_syscall() at amd64_syscall+0x108/frame 0xfe012b7c1f30 > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe012b7c1f30 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x36a096c34ea, rsp = > 0x3fa11e623eb8, \ > rbp = 0x3fa11e623ee0 --- > panic: _sleep: curthread not running > cpuid = 4 > time = 1650389478 > KDB: stack backtrace: > > One common trigger appears to be the use of firefox-99.0,2 from > the ports collection. > > -- > Steve > What version of drm are you using ? Since when do you experience this ? drm as not changed much for a long time now except adapting a few files for new linuxkpi addition. Cheers, -- Emmanuel Vadot
Re: 'set but unused' breaks drm-*-kmod
Hello Michael, On Wed, 20 Apr 2022 23:39:12 -0400 Michael Butler wrote: > Seems this new requirement breaks kmod builds too .. > > The first of many errors was (I stopped chasing them all for lack of > time) .. > > --- amdgpu_cs.o --- > /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.7.19_3/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1210:26: > > error: variable 'priority' set but not used > [-Werror,-Wunused-but-set-variable] > enum drm_sched_priority priority; > ^ > 1 error generated. > *** [amdgpu_cs.o] Error code 1 > How are you building the port, directly or with PORTS_MODULES ? I do make passes on the warning for drm and I did for set-but-not-used case but unfortunately this option doesn't exists in 13.0 so I couldn't apply those in every branch. Cheers, -- Emmanuel Vadot
Re: loading amfgpu results in immefiate power off on 12.3-STABLE r371721
On Sun, 27 Mar 2022 12:33:34 -0600 Warner Losh wrote: > On Sun, Mar 27, 2022 at 11:09 AM Pete Wright wrote: > > > > > > > On 3/25/22 21:42, Chris wrote: > > > This probably isn't the correct list. But it's the closest of > > > all the lists I'm subscribed to. Please forgive me. > > > OK so here's what happened. I couldn't get the trackpad on a > > > Dell laptop I just got to work in FreeBSD-13. So after a couple > > > of days, I gave up and tried 12.3-STABLE r371721 today. Once I got > > > the network (wifi) going. I pkg installed drm-kmod && it's depends. > > > Added kld_list="amdgpu" to rc.conf && rebooted. The moment it > > > loaded, the screen went black and it powered off. Booted to > > > single-user, fsck && cp /var/log/messages to ~/ . > > > I'm attaching a copy in case it sheds any light on the cause. > > > The most interesting thing about all this, is that amdgpu > > > worked flawlessly on 13 -- go figure. > > > > > > > this discussion is probably best suited for the freebsd-x11 mailing > > list, but i think you can try a couple things: > > > > - give NomadBSD a spin (https://nomadbsd.org/). it's a live USB image > > that does a really good job at auto-detecting hardware and giving you > > nice desktop. it's based on freebsd-13.0. you can also install it on > > your disk if everything looks good. i frequently use it to test > > hardware support on new systems i encounter. > > > > - it's hard to tell without any hardware info provided, but its possible > > you have an older AMD gpu, as such you might want to try using radeonkms > > in rc.conf rather than amdgpu. > > > > if neither of those things help i'd definitely suggest subscribing to > > the freebsd-x11@ mailing list to get the appropriate eyes on things: > > https://lists.freebsd.org/subscription/freebsd-x11 > > > > I'd like to share with people that I'm working on a statement of what works > and what the graphics team will spend a lot of effort on vs continue to have > build support in the tree. > > The short version is that the latest stable branch, the latest current and > the > last most-recent release will be the ones best supported. Anything older > than that (prior stable branches, even those supported by the rest of the > project) may work great, but may also be broken or perform less well or > support fewer newer graphics cards. In addition, cards older than about > a decade may stop working on an upgrade because upstream's attention > to these isn't so great or the driver is a binary driver that the upstream > vendor > has not upgraded to support its older cards with newer interfaces, etc. > Short of doubling or tripling the graphics team size (volunteers welcome), > it's too > hard to commit to more than this limited subset of support. Even with a > larger > active developer group, expanding beyond this envelope would be hard given > the size of the testing matrix... I do confirm the above. I'll also say that currently the graphics team is just me and wulf@ (and sometimes small contribution from others), we can't do everything. > Also, I don't think we've ever supported unloading the drm drivers, so it's > not > too surprising that didn't work. It used to work for i915kms, it never worked for amdgpu. I'm (well $WORK) is interested in unloading mostly for GPU-passthough. That will allow one user to boot FreeBSD, use the graphics, unload the module and start a Windows VM or whatever, use the graphics in it and after shutting down the VM one could use again the GPU on FreeBSD. It's a bit low on my todo list though. > Also, I know the older hardware thing is hard to swallow. I get that people > want > that stuff to work forever because it performs adequately. However, we are > heavily > dependent on leveraging the work of others to support what we can, so when > the > work we depend on starts to bitrot, our support for that hardware suffers > as well... > > Warner > > > > -pete > > > > -- > > Pete Wright > > p...@nomadlogic.org > > @nomadlogicLA > > > > > > -- Emmanuel Vadot
Re: Kernel changes causing AMDGPU / DRM to fail? i2c related?
On Mon, 31 Jan 2022 14:19:53 +0300 Vladimir Kondratyev wrote: > On 30.01.2022 22:43, Stefan Esser wrote: > > Am 30.01.22 um 19:23 schrieb Vladimir Kondratyev: > >> On 30.01.2022 00:25, Stefan Esser wrote: > >>> After rebooting with freshly built world, kernel and the amdgpu driver > >>> my console stopped working. It goes blank and the display goes into a > >>> power save mode, as soon as the amdgpu driver is loaded. > >>> > >>> The GPU (a Radeon R7 250E) is correctly detected as before, but there > >>> is an error message "drmn0: [drm] Cannot find any crtc or sizes". > >>> > > [...] > >>> [drm] AMDGPU Display Connectors > >>> [drm] Connector 0: > >>> [drm] DP-1 > >>> [drm] HPD4 > >>> [drm] DDC: 0x1950 0x1950 0x1951 0x1951 0x1952 0x1952 0x1953 0x1953 > >>> [drm] Encoders: > >>> [drm] DFP1: INTERNAL_UNIPHY2 > >>> [drm] Connector 1: > >>> [drm] HDMI-A-1 > >>> [drm] HPD1 > >>> [drm] DDC: 0x195c 0x195c 0x195d 0x195d 0x195e 0x195e 0x195f 0x195f > >>> [drm] Encoders: > >>> [drm] DFP2: INTERNAL_UNIPHY2 > >>> [drm] Connector 2: > >>> [drm] DVI-I-1 > >>> [drm] HPD2 > >>> [drm] DDC: 0x1958 0x1958 0x1959 0x1959 0x195a 0x195a 0x195b 0x195b > >>> [drm] Encoders: > >>> [drm] DFP3: INTERNAL_UNIPHY > >>> [drm] CRT1: INTERNAL_KLDSCP_DAC1 > >>> drmn0: [drm] Cannot find any crtc or sizes > >>> drmn0: [drm] Cannot find any crtc or sizes > >>> drmn0: [drm] Cannot find any crtc or sizes > >>> [drm] Initialized amdgpu 3.37.0 20150101 for drmn0 on minor 0 > >>> > >>> A successful driver attach from a reboot a few days ago had ended in: > >>> > >>> [drm] CRT1: INTERNAL_KLDSCP_DAC1 > >>> [drm] fb mappable at 0xE0503000 > >>> [drm] vram apper at 0xE000 > >>> [drm] size 33177600 > >>> [drm] fb depth is 24 > >>> [drm] pitch is 15360 > >>> [drm] Initialized amdgpu 3.36.0 20150101 for drmn0 on minor 0 > >>> > >>> Regards, STefan > >> > >> drm-kmod commit 534aa199c10d forced it to use i2c from base. > > > > Hi Vladimir, > > > > thank you for the information! I'm using drm-devel-kmod, and in fact found > > that 5.5.19.g20211230 works, while 5.7.19.g20220126 (committed as > > 0c38674b389ad > > on 2022-01-26) causes the failure. > > > >> You may try to checkout previous revision (444dc58f0247) to find out if > >> in-base > >> i2c is guilty or not. > > > > Assuming that the same change to use the system i2c code has been in the > > latest > > commit to the drm-devel-kmod port, this should be proven, now. ;-) > > > > These is the list of in-kernel i2c modules on my system (a Ryzen 9 5950 on > > an > > ASUS mainboard with B550 chip-set): > > > > $ kldstat -v | grep iic > > 68 iicsmb/smbus > > 67 iicbus/iicsmb > > 66 iichb/iicbus > > 65 iicbb/iicbus > > 64 iicbus/iic > > 63 iicbus/ic > > 213 lkpi_iicbb/iicbb > > 212 lkpi_iic/lkpi_iicbb > > 211 lkpi_iic/iicbus > > 210 drmn/lkpi_iic > > 56 iichid/hidbus > > > > Can I help debug this issue? > > > > I could re-install the latest version and boot with hw.dri.drm_debug or > > dev.drm.drm_debug set? > > > > Or are there other settings to get a debug log from the i2c side? > > > > Regards, STefan > > > > PS: I'm keeping the CC to current@, since this might be an issue in the i2c > > kernel code ... > > There are no successful lkpi_iic attachments in your output. They look like: > > lkpi_iic0: on drmn0 > > Please share your `devinfo -v` output. > Kldload output with verbose boot enabled can be helpful too. That's because this card is probably using the bitbang part. As stated in the commit this wasn't tested as I don't have compatible hardware. It's likely a timing issue in the bitbang part. That's the main reason it's only in master and 5.7 branch of drm-kmod, so people can debug/fix. -- Emmanuel Vadot
Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?
On Thu, 16 Dec 2021 07:01:30 -0800 Gleb Smirnoff wrote: > Emmanuel, > > On Thu, Dec 16, 2021 at 10:17:33AM +0100, Emmanuel Vadot wrote: > E> > E> I'm not sure I understand the logic here. > E> > E> We're keeping drivers for museum grade hardware that no developer > have > E> > E> access to and likely no one uses nowadays just for an hypothetical > E> > E> situation where someone will try to use those cards on FreeBSD 14 i386 > E> > E> in 2021 ? > E> > E> And we're doing that just because the drivers compiles ? > E> > > E> > We are doing that because the hardware is still produced and can be > E> > purchased at http://cronyx.ru/price/#taupci And this is not a dead > E> > website, I gave a call to tech support last year. Who uses it? No > E> > idea. For some obscure reason they are still produced along with > E> > conventional PCI industrial mainboards (you can google that). > E> > E> I'm sure that if one looks deep enough, a lot of obsolete hardware > E> that we've removed are still produced by some industrial computer maker. > E> And I don't think that this is a valid reason to keep everything that > E> is old. > > I'd be interested to see at least one example of removed driver for > a hardware that is still produced. Can you demonstrate one please? This was an hypothetical situation. > E> > I agree that actual intersection of FreeBSD users and Cronyx > E> > users could be zero today. But potentially it can be non-zero. > E> > I would appreciate if somebody chooses FreeBSD for their very > E> > strange industrial communications equipment. > E> > > E> > Some corrections on above statements. > E> > > E> > 1) We build cp(4) on amd64. We don't build ce(4) on amd64 for a > E> >reason that some functions are marked with __attribute__ fastcall. > E> >I'm 99% sure that attribute can be removed and ce(4) will build > E> >on amd64. sconfig(8) is build on amd64. > E> > E> No we don't, see : > E> https://cgit.freebsd.org/src/tree/sys/modules/Makefile#n772 > > Well, that was my miss, when I moved it from options.i386 to options.x86. > Forgot about modules. The Makefile also has a comment at line 764. > > With "we build" I meant that we can add it to kernel config and build. > > E> > Does sconfig create any problems for you? I'm fine with removing > E> > the drivers and the tool if they do really create a burden for us. > E> > That was case with their sppp(4) half, and I removed it in 6aae3517ed25. > E> > If there is no maintainance burden, why remove them? Just to save > E> > disk space? > E> > E> They don't really create a burden. > E> The reason that made me look at this is that I've noticed that my > E> FreeBSD-runtime package had this sconfig binary that I've never heard > E> of before. After digging I saw that it was for those old cards. > E> I honestly don't care if we keep the drivers as of today we only > E> compile them for i386. I don't think that we should enable them for > E> amd64, we've lived ~20 years on amd64 without them, nobody complained > E> that they weren't present so clearly nobody cares about having them. We > E> shouldn't enable drivers on some arch just "because we can". > E> With a46856c3f9ec in main right now I'm perfectly happy as I don't > E> have some useless tool, if it could stay that way that would be great. > > I'm not. Your position is simply: "the utility existence bugs me cause > it is useless for me", and "I don't care if it exist on i386, cause I > don't use i386". Kind of selfish position. What's selfish about removing some binary that 100% of our amd64 users never needed since the creation of FreeBSD/amd64 ? > For myself FreeBSD also contains quite a lot of tools I never use and > probably never would. > > E> But it will be nice to have some kind of official statement on what > E> FreeBSD should deliver in term of drivers, I think we're way too > E> conservative on keeping old stuff that nobody uses just because "it > E> compiles". > > I agree with that. We need such policy. It is being promised, and while > it is not there yet, there is this document: > > https://wiki.freebsd.org/DeprecationPlan > > As you see, a developer who wants to remove something needs to propose > that, communicate that and plan. And as you can see there, Cronyx devices > were proposed properly by Ed. The ISA ones were deleted quickly. For the > PCI ones I communicated Cronyx and checked their status. Later the > drivers were made as minimal as possible, removing sppp(4). This is a > proper process. Not do a drive by commit and refuse to revert it. Where did I refuse to revert ? -- Emmanuel Vadot
Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?
On Wed, 15 Dec 2021 10:11:16 -0800 Gleb Smirnoff wrote: > On Wed, Dec 15, 2021 at 05:52:02PM +0100, Emmanuel Vadot wrote: > E> > > I've noticed this /sbin/sconfig binary and after looking it's for > E> > > configuring Cronyx E1 PCI (PCI as in PCI, not PCIe). > E> > > The products pages ([1], [2]) seems to say that FreeBSD >=7 isn't > E> > > supported. > E> > > We currently only build the drivers for i386 (and they contain native > E> > > compiled code). > E> > > > E> > > Anyway, I'd like to remove this from the tree, I really doubt that > E> > > anyone uses this cards nowadays (or even E1) but just in case I send > E> > > this mail. > E> > > E> > I posted a similar query to -stable in 2020, at > E> > > https://lists.freebsd.org/pipermail/freebsd-stable/2020-February/092037.html > E> > and did not get any response. > E> > > E> > I have D23928 for a deprecation notice for ce and cp. Gleb commented > E> > there that he'd offer to maintain them (and as part of that, removed > E> > sppp in 6aae3517ed25). > E> > > E> > E> I'm not sure I understand the logic here. > E> We're keeping drivers for museum grade hardware that no developer have > E> access to and likely no one uses nowadays just for an hypothetical > E> situation where someone will try to use those cards on FreeBSD 14 i386 > E> in 2021 ? > E> And we're doing that just because the drivers compiles ? > > We are doing that because the hardware is still produced and can be > purchased at http://cronyx.ru/price/#taupci And this is not a dead > website, I gave a call to tech support last year. Who uses it? No > idea. For some obscure reason they are still produced along with > conventional PCI industrial mainboards (you can google that). I'm sure that if one looks deep enough, a lot of obsolete hardware that we've removed are still produced by some industrial computer maker. And I don't think that this is a valid reason to keep everything that is old. > I agree that actual intersection of FreeBSD users and Cronyx > users could be zero today. But potentially it can be non-zero. > I would appreciate if somebody chooses FreeBSD for their very > strange industrial communications equipment. > > Some corrections on above statements. > > 1) We build cp(4) on amd64. We don't build ce(4) on amd64 for a >reason that some functions are marked with __attribute__ fastcall. >I'm 99% sure that attribute can be removed and ce(4) will build >on amd64. sconfig(8) is build on amd64. No we don't, see : https://cgit.freebsd.org/src/tree/sys/modules/Makefile#n772 > 2) Drivers don't contain native precompiled code. They contain >obfuscated code. Ok, I actually didn't looked, just noticed that they where listed under MK_SOURCELESS_HOST. > Does sconfig create any problems for you? I'm fine with removing > the drivers and the tool if they do really create a burden for us. > That was case with their sppp(4) half, and I removed it in 6aae3517ed25. > If there is no maintainance burden, why remove them? Just to save > disk space? They don't really create a burden. The reason that made me look at this is that I've noticed that my FreeBSD-runtime package had this sconfig binary that I've never heard of before. After digging I saw that it was for those old cards. I honestly don't care if we keep the drivers as of today we only compile them for i386. I don't think that we should enable them for amd64, we've lived ~20 years on amd64 without them, nobody complained that they weren't present so clearly nobody cares about having them. We shouldn't enable drivers on some arch just "because we can". With a46856c3f9ec in main right now I'm perfectly happy as I don't have some useless tool, if it could stay that way that would be great. But it will be nice to have some kind of official statement on what FreeBSD should deliver in term of drivers, I think we're way too conservative on keeping old stuff that nobody uses just because "it compiles". Cheers, -- Emmanuel Vadot
Deprecate and remove publickey(5) stuff
Hello, it's me again, I've posted some review some time ago but didn't follow up with some mail so users might see it. I'd like to remove publickey(5) related programs, those are the only DES users iirc and likely unused. https://reviews.freebsd.org/D30682 https://reviews.freebsd.org/D30683 I'll commit this in two weeks unless there is some valid argument to keep this. Cheers, -- Emmanuel Vadot
Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?
On Wed, 15 Dec 2021 10:42:36 -0500 Ed Maste wrote: > On Wed, 15 Dec 2021 at 10:27, Emmanuel Vadot wrote: > > > > > > Hello all, > > > > I've noticed this /sbin/sconfig binary and after looking it's for > > configuring Cronyx E1 PCI (PCI as in PCI, not PCIe). > > The products pages ([1], [2]) seems to say that FreeBSD >=7 isn't > > supported. > > We currently only build the drivers for i386 (and they contain native > > compiled code). > > > > Anyway, I'd like to remove this from the tree, I really doubt that > > anyone uses this cards nowadays (or even E1) but just in case I send > > this mail. > > I posted a similar query to -stable in 2020, at > https://lists.freebsd.org/pipermail/freebsd-stable/2020-February/092037.html > and did not get any response. > > I have D23928 for a deprecation notice for ce and cp. Gleb commented > there that he'd offer to maintain them (and as part of that, removed > sppp in 6aae3517ed25). > I'm not sure I understand the logic here. We're keeping drivers for museum grade hardware that no developer have access to and likely no one uses nowadays just for an hypothetical situation where someone will try to use those cards on FreeBSD 14 i386 in 2021 ? And we're doing that just because the drivers compiles ? -- Emmanuel Vadot
Any Cronyx Tau* (ce(4) or cp(4)) users ?
Hello all, I've noticed this /sbin/sconfig binary and after looking it's for configuring Cronyx E1 PCI (PCI as in PCI, not PCIe). The products pages ([1], [2]) seems to say that FreeBSD >=7 isn't supported. We currently only build the drivers for i386 (and they contain native compiled code). Anyway, I'd like to remove this from the tree, I really doubt that anyone uses this cards nowadays (or even E1) but just in case I send this mail. Links to the review for the removal : https://reviews.freebsd.org/D33465 https://reviews.freebsd.org/D33466 https://reviews.freebsd.org/D33467 https://reviews.freebsd.org/D33468 https://reviews.freebsd.org/D33469 Cheers, [1]: http://www.cronyx.ru/hardware/tau32.html [2]: http://www.cronyx.ru/hardware/taupci.html -- Emmanuel Vadot
Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore
On Tue, 14 Dec 2021 11:05:19 + Alexey Dokuchaev wrote: > On Tue, Dec 14, 2021 at 11:27:07AM +0100, Emmanuel Vadot wrote: > > On Tue, 14 Dec 2021 10:14:24 + Alexey Dokuchaev wrote: > > > ... > > > I know that I had problemless desktop some 10-5 years ago, okayish > > > desktop ~three years ago, tolerable experience with 4.16.x DRM bits > > > and shitty one with current 5.4.x (FWIW, 5.x had been problematic > > > for me since the beginning, but previously it was fairly easy to > > > build drm-fbsd12.0-kmod on -CURRENT to avoid regressions, now the > > > source bases had divered too far enough; it's probably still possible > > > to patch, but would take longer time). > > > > Any PR open for your issues? > > At first I was going to say something about such PRs would be closed > as overcome by events anyways, but I like the change of your tone, so > I won't. :) All those PR that I closed were old and mostly unrelevant anymore. > I've just ordered a Full HD IPS screen for my laptop so I could play > modern (well, relatively modern) games, thus I expect I'd be sticking > my hands into X11 stack deeper. I'll collect my notes and stories in > a submittable shape and file them. > > > Well this telegram chat is still a community one, I don't see how it > > makes a difference. > > Well, it'a a group of actual FreeBSD users vs. Twitter where random > people who probably don't even use FreeBSD could see the poll and would > gladly click on preloaded correct answer. Still doesn't change the fact that not a lot of people are there. And we're back to my point back then during the bikesched, we do not have a good and reliable way to do poll for FreeBSD users. > > Also I can't see the poll result. > > Hmm, indeed, it does not display results even when viewed via browser, > that is, unlogged. OTOH you should really try Telegram, there's nothing > better right now on the market. > > ./danfe > I manage to see it (and even vote :P) via my phone, I don't use (nor want to) telegram on my desktops. -- Emmanuel Vadot
Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore
On Tue, 14 Dec 2021 10:14:24 + Alexey Dokuchaev wrote: > On Tue, Dec 14, 2021 at 09:14:27AM +0100, Emmanuel Vadot wrote: > > On Tue, 14 Dec 2021 07:11:28 + Alexey Dokuchaev wrote: > > > ... > > > Oh, you know, it's about steadily deteriorating quality of our gfx > > > stack once we had started pulling things from Linux. > > > > Right. > > That just proves that you know nothing and will just complain on > > everything "new". > > I know that I had problemless desktop some 10-5 years ago, okayish > desktop ~three years ago, tolerable experience with 4.16.x DRM bits > and shitty one with current 5.4.x (FWIW, 5.x had been problematic > for me since the beginning, but previously it was fairly easy to > build drm-fbsd12.0-kmod on -CURRENT to avoid regressions, now the > source bases had divered too far enough; it's probably still possible > to patch, but would take longer time). Any PR open for your issues ? > > We've *always* pulled drm bits from Linux, always. > > You know what I've meant. I do because I know the history, not everyone does. > > > In FreeBSD chat and with less biased poll than the one Warner had posted > > > on Twitter, most people had actually voted against making it off by > > > default: https://t.me/FreeBSD1/25129. > > > > So nothing changes then? > > How do you mean? Most FreeBSD people, not some random Twitter crowd, want > the bell to be on by default, but it's still off. > > ./danfe > Sorry I didn't see the "against". Well this telegram chat is still a community one, I don't see how it makes a difference. Also I can't see the poll result. -- Emmanuel Vadot
Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore
On Tue, 14 Dec 2021 07:11:28 + Alexey Dokuchaev wrote: > On Mon, Dec 13, 2021 at 06:32:22PM +0100, Emmanuel Vadot wrote: > > On Mon, 13 Dec 2021 17:01:43 + Alexey Dokuchaev wrote: > > > On Mon, Dec 13, 2021 at 07:45:07AM -0800, John Baldwin wrote: > > > > ... > > > > However, it was a bit harder to see this originally as the 915kms driver > > > > tries to do a malloc(M_WAITOK) from cn_grab() when entering DDB which > > > > recursively panics (even a malloc(M_NOWAIT) from cn_grab() is probably a > > > > bad idea). > > > > > > Funny how these new Linuxish DRM bits could affect so many things. :( > > > > What is this comment about exactly? > > Oh, you know, it's about steadily deteriorating quality of our gfx stack > once we had started pulling things from Linux. Right. That just proves that you know nothing and will just complain on everything "new". We've *always* pulled drm bits from Linux, always. What changed is that instead of, say, replacing all calls to kmalloc in the drm sources to our malloc we have stubs in linuxkpi. And this helped a lot, not patching the upstream sources helps us updating drm much faster. Now for John's case, this is very edge case. The panic happened in a critical section, which put us in a problematic state. I think that Linux can malloc almost all the time and we can't. Even if we had done drm porting "the old way" we will had the same problem. Getting the framebuffer working on a panic works today, unless this kind of stuff happens and I don't think that we can fix that (at least easily). > > > > The fact that that sysbeep is off so I couldn't tell if typing in > > > > commands > > > > was doing anything vs emitting errors probably didn't improve trying to > > > > diagnose the hang as "sitting in ddb" initially, though I don't know if > > > > DDB itself emits a beep for invalid commands, etc. > > > > > > Now that Warner had fixed the beeper frequency, why we still didn't enable > > > it back on by default? > > > > Because all people who wanted it off wasn't because it wasn't the > > right vt100 frequency, they just wanted it off. > > In FreeBSD chat and with less biased poll than the one Warner had posted > on Twitter, most people had actually voted against making it off by > default: https://t.me/FreeBSD1/25129. So nothing changes then ? > If John's assumption that muting > it pessimizes debugging is correct, it really leaves no strong reasons > NOT to turn it back on by default. > > ./danfe I wouldn't be opposed to enable the beep when we drop to ddb. It's already annoying to panic so adding annoying beep that *could* help in some edge cases isn't the end of the world. -- Emmanuel Vadot
Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore
On Mon, 13 Dec 2021 17:01:43 + Alexey Dokuchaev wrote: > On Mon, Dec 13, 2021 at 07:45:07AM -0800, John Baldwin wrote: > > ... > > However, it was a bit harder to see this originally as the 915kms driver > > tries to do a malloc(M_WAITOK) from cn_grab() when entering DDB which > > recursively panics (even a malloc(M_NOWAIT) from cn_grab() is probably a > > bad idea). > > Funny how these new Linuxish DRM bits could affect so many things. :( What is this comment about exactly ? > > The fact that that sysbeep is off so I couldn't tell if typing in commands > > was doing anything vs emitting errors probably didn't improve trying to > > diagnose the hang as "sitting in ddb" initially, though I don't know if > > DDB itself emits a beep for invalid commands, etc. > > Now that Warner had fixed the beeper frequency, why we still didn't enable > it back on by default? > > ./danfe > Because all people who wanted it off wasn't because it wasn't the right vt100 frequency, they just wanted it off. -- Emmanuel Vadot
Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled?
for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > GEOM: new disk da0 > pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > pass0: Fixed Direct Access SPC-4 SCSI device > pass0: Serial Number REPLACED > pass0: 400.000MB/s transfers > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number REPLACED > da0: 400.000MB/s transfers > da0: 953869MB (1953525168 512 byte sectors) > da0: quirks=0x2 > da0: Delete methods: > random: unblocking device. > Warning: bad time from time-of-day clock, system time will not be set > accurately > Dual Console: Serial Primary, Video Secondary > start_init: trying /sbin/init > . . . > > (I'll stop with that.) > > So I end up with a 1400042 kernel and a 1400043 world in order to > boot. > > The e.MMC has only: > > # ls -FTld * > -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT > drwxr-xr-x 23 root wheel 1536 Dec 8 20:18:34 2021 boot/ > drwxr-xr-x 2 root wheel512 Apr 26 14:39:22 2020 etc/ > drwx-- 2 root wheel 33280 Nov 27 09:46:08 2019 lost+found/ > > where the etc/ has only: > > # find etc/ -print > etc/ > etc/hostid > > World comes from the USB3 SSD that is attached but the kernel > comes from the e.MMC instead. (The kernel can deal with the > USB3 SSD just fine, unlike the U-Boot that is involved.) > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > Could you try reverting 8661e085fb953855dbc7059f21a64a05ae61b22c "mmc: Fix HS200/HS400 capability check" and let me know ? Thanks, -- Emmanuel Vadot
Re: FreeBSD base pkg (packaging) and critical ports build alongside
On Wed, 29 Sep 2021 09:42:46 +0100 David Chisnall wrote: > Hi, > > I think your best option would be to do the opposite of what you > suggest. Poudriere can build pkgbase sets from a source tree and > populate a jail from them. No it doesn't populate the jail from the pkgbase sets, the jail will still be populated using make installworld and friends. I still need to add the possibility to create a jail (and update it) just from a pkgbase but haven't got time yet for this. > The flow that I'd suggest is: > > - Poudriere jail to build a jail from an existing source tree. > - If there are kernel changes, install the packages on the package > builder and reboot. > - Poudriere bulk in the new jail to build the new package set. > > Note: You can *normally* skip the second step (drm ports, for example, > will be built against the new kernel sources in the jail, though they > might not be loadable on the host) but there's no guarantee that you can > run a newer userland on an older kernel so things may break. > > If you enable reproduceable builds in the src.conf that you use for > building the jail then you should be able to just diff the kernel binary > to see if anything has changed. > > If you have bhyve or are running on a cloud platform then you can > replace the second step with a poudriere image invocation to build a VM > image containing poudriere and your newly-built base system and deploy > this to build the packages. I'm planning on working on some tooling to > do this in Azure with GitHub Actions. > > Note that poudriere uses packages installed on the host system to build > a jail. If you have, for example, installed llvm12 then you can put a > line in your src-env.conf for the jail to tell it to use that as an > external toolchain and skip the toolchain-bootstrap phase of the build. > This means that the base-build is fairly fast even on quite modest > hardware (it still builds clang, but at least it does it only once). > > David > > > On 29/09/2021 09:28, FreeBSD User wrote: > > Hello, > > > > I use FreeBSD-base packages built on self hosted systems to update 13-STABLE > > and CURRENT hosts. I run into the problem, that the packages of the FreeBSD > > base, built via the FreeBSD framework and from most recent 13-STABLE > > sources, > > are often oit of synchronisation with our poudriere packaging builders, > > that is > > especially true for critical ports with kernel modules, like i915 drm, > > virtualbox and so on. The problem is, obviously, barehanded: 13-STABLE > > sources > > and probably the API changes more rapidly than those of the appropriate > > builder > > hosts for poudriere and since it takes a bunch of days to build a whole > > poudriere packages repository, there is often a gap between the revision of > > the > > kernel and the port containing kernel modules. > > > > So, the question is: how can I add ports to the building process of the > > FreeBSD > > sources tree in the way they get build every time I build the FreeBSD-base > > packages alongside the OS? > > > > Thanks in advance, > > > > oh > > > -- Emmanuel Vadot
Re: FreeBSD base pkg (packaging) and critical ports build alongside
Hello, On Wed, 29 Sep 2021 10:28:05 +0200 FreeBSD User wrote: > Hello, > > I use FreeBSD-base packages built on self hosted systems to update 13-STABLE > and CURRENT hosts. I run into the problem, that the packages of the FreeBSD > base, built via the FreeBSD framework and from most recent 13-STABLE sources, > are often oit of synchronisation with our poudriere packaging builders, that > is > especially true for critical ports with kernel modules, like i915 drm, > virtualbox and so on. The problem is, obviously, barehanded: 13-STABLE sources > and probably the API changes more rapidly than those of the appropriate > builder > hosts for poudriere and since it takes a bunch of days to build a whole > poudriere packages repository, there is often a gap between the revision of > the > kernel and the port containing kernel modules. > > So, the question is: how can I add ports to the building process of the > FreeBSD > sources tree in the way they get build every time I build the FreeBSD-base > packages alongside the OS? > > Thanks in advance, > > oh > What I do to have packages (from ports) and pkgbase in sync is that I use poudriere to also build pkgbase. It's available in poudriere-devel using -B when creating the jail. Then I simply cpdup the packages and pkgbase at the same time at the end of the package build. poudriere knows how to do make update-package for pkgbase so your machine will just update the modified packages (provided that you are on a RELEASE/STABLE branch or have WITH_REPRODUCIBLE_BUILD=yes in your jail src.conf for CURRENT). There is still one problem with that approch for kernel modules, they will be recompiled but as the version isn't bumped it will not be upgraded, so I just pkg install -f drm-devel-kmod from time to time. Cheers, -- Emmanuel Vadot
Re: Building multiple kernels with "make release"
On Thu, 29 Jul 2021 00:13:54 +
Glen Barber wrote:
> On Wed, Jul 28, 2021 at 06:00:28PM -0600, Alan Somers wrote:
> > On Wed, Jul 28, 2021 at 5:52 PM Miroslav Lachman <000.f...@quip.cz> wrote:
> >
> > > On 28/07/2021 20:46, Juraj Lutter wrote:
> > > >
> > > >
> > > >> On 28 Jul 2021, at 20:37, Glen Barber wrote:
> > > >>
> > > >> On Wed, Jul 28, 2021 at 12:05:25PM -0600, Alan Somers wrote:
> > > >>> On Wed, Jul 28, 2021 at 11:57 AM Glen Barber wrote:
> > > >>>> Just on a hunch, could you try with adding INSTALLKERNEL="${KERNEL}"
> > > to
> > > >>>> your release.conf?
> > > >>>>
> > > >>>> I now seem to recall some weirdness with this, but the exact details
> > > >>>> elude me at the moment.
> > > >>>>
> > > >>>
> > > >>> Setting INSTALLKERNEL="GENERIC-NODEBUG" during "make installkernel"
> > > >>> overrides whatever KERNCONF was set to. But it still only installs
> > > >>> one
> > > >>> kernel. Trying to set that variable to a list doesn't work.
> > > >>
> > > >> Ok. Give me a day or so to try to figure out what is (or isn't)
> > > >> happening here. I do not recall any recent-ish changes that would have
> > > >> caused this, and I am 95% certain it has worked in the past.
> > > >
> > > > According to Makefile.inc1:
> > > >
> > > > make installkernel KERNCONF=?KERN1 KERN2?
> > > >
> > > > should install KERN1 and KERN2. Similar goes for buildkernel.
> > > >
> > > > Or is there something I am missing?
> > >
> > > Does 'make installkernel KERNCONF=?KERN1 KERN2?' really install both
> > > kernels? Under which names?
> > > I have 3 kernels defined in KERNCONF in /etc/make.conf for years. 3
> > > kernels are built by "make buildkernel" but only one installed by "make
> > > installkernel".
> > >
> > > To install other kernels I use:
> > >
> > > make installkernel KERNCONF=KERN2 KODIR=/boot/kernel.KERN2
> > >
> > > make installkernel KERNCONF=KERN3 KODIR=/boot/kernel.KERN3
> > >
> >
> > Miroslav is right. Despite the comment that Juraj found, "make
> > installkernel" only installs the first kernel listed in KERNCONF.
>
> Good find. I honestly thought this worked as expected versus as
> written. In fact, I *thought* secondary, tertiary, etc. kernels were
> installed as /boot/kernel.KERN2, /boot/kernel.KERN3 (using the example
> above).
You need to set NO_INSTALLEXTRAKERNELS=no for that to happens (yes the
variable name and double no sucks if anyone have a patch for that that
would be awesome).
> Although, I may be misremembering, and 'kernel.KERN2.txz' may be created
> instead, although not installed/extracted. Though, we are going back at
> least seven years, and I do not even remember what I had eaten for
> dinner last night, so there's that...
>
> Glen
>
--
Emmanuel Vadot
MMCCAM metabug
Hello all, I've created a metabug for all MMCCAM issues that I know (there might be more of course). Of course bugzilla sucks at this for the metabug itself but the tree is ok I think : https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=257385_resolved=1 If you have any bugs not listed there don't hesitate to create one and add it in the metabug (no idea if anyone can do that so if this isn't the case just add a comment on the metabug and I'll add the depends). Almost all of them are required to be fixed before we switch any arch to use MMCCAM by default so if you have any spare time don't hesitate to contact me. Cheers, -- Emmanuel Vadot
Re: 13 stable build fail
Hi, On Sat, 3 Jul 2021 04:33:24 +0300 Rozhuk Ivan wrote: > > ... > In file included from /usr/src/lib/libc/gen/fstab.c:38: > In file included from > /tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/mount.h:38: > /tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/ucred.h:42:10: fatal > error: 'bsm/audit.h' file not found > #include > ^ > 1 error generated. > --- fstab.o --- > *** [fstab.o] Error code 1 > > make[4]: stopped in /usr/src/lib/libc > In file included from /usr/src/lib/libc/gen/fts.c:40: > In file included from > /tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/mount.h:38: > /tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/ucred.h:42:10: fatal > error: 'bsm/audit.h' file not found > #include > ^ > In file included from /usr/src/lib/libc/gen/fts-compat.c:41: > In file included from > /tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/mount.h:38: > /tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/ucred.h:42:10: fatal > error: 'bsm/audit.h' file not found > #include > ^ > 1 error generated. > --- fts.o --- > *** [fts.o] Error code 1 > > make[4]: stopped in /usr/src/lib/libc > ... > Sorry, forgot to mfc the fix for this. Should be fixed now. -- Emmanuel Vadot
Re: Trying to build Current
On Thu, 15 Apr 2021 10:51:39 +0200 Willem Jan Withagen via freebsd-current wrote: > Hi, > > I actually went completely back to the basic setup with directories > /usr/src and /usr/obj > But even then I do not manage to buildworld. > The process keeps bumping into missing bsm/audit. > > First case was when it tried to build the 64bit libc. > I copied the bsm directory into > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/ > > Which allowed it to continue. > But then a bit further on it halts again in 32bit libc. > Whcih I could fix the same way. > > --- fts.o --- > In file included from /usr/src/lib/libc/gen/fts.c:40: > In file included from > /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/mount.h:38: > /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/ucred.h:42:10: > fatal error: 'bsm/audit.h' file not found > #include > ^ > > Even defining HISTORICAL_MAKE_WORLD did not help, but then I'm not doing > 'make world' > > So why is this include file missing? > > --WjW > > ___ > 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" Try with https://cgit.freebsd.org/src/commit/?id=f41efc453ab5563cde214cb19273d87e6e4aa2d4 applied. You probably have WITHOUT_AUDIT=yes in src.conf -- Emmanuel Vadot ___ 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: panic in drm or vt or deadlock on mutex or ...
On Mon, 08 Feb 2021 21:05:24 +0300 Greg V wrote: > > > On Mon, Feb 8, 2021 at 04:53, Alastair Hogge wrote: > > On 2021-02-04 17:50, Emmanuel Vadot wrote: > > > > [...] > > > >> Only happens with drm when you do what ? > > > > Boot to multi-user; login (getty): > > $ doas kldload /boot/modules/amdgpu.ko > > $ sysctl > > [panic] > > > > ..is a guaranteed way to panic my system. > > > https://github.com/freebsd/drm-kmod/issues/15 ? > https://github.com/freebsd/drm-kmod/pull/37 ? Yeah I was about to link that. To my knowledge this should be fixed but maybe something else is needed for some different gpu. Alastair: Can you report a bug there : https://github.com/freebsd/drm-kmod/issues Cheers, -- Emmanuel Vadot ___ 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: panic in drm or vt or deadlock on mutex or ...
On Wed, 3 Feb 2021 08:03:24 -0800 Steve Kargl wrote: > On Wed, Feb 03, 2021 at 10:42:21AM +0200, Andriy Gapon wrote: > > On 03/02/2021 07:08, Steve Kargl wrote: > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 0; apic id = 00 > > > fault virtual address = 0xc374 > > > fault code= supervisor read data, page not present > > > instruction pointer = 0x20:0xef411f > > > stack pointer = 0x28:0x4074e97c > > > frame pointer = 0x28:0x4074e988 > > > 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 = 91696 (chrome) > > > trap number = 12 > > ... > > > panic: page fault > > > cpuid = 0 > > > time = 1612328062 > > > KDB: stack backtrace: > > > db_trace_self_wrapper(2,4074e93c,c,0,4074e800,...) at > > > db_trace_self_wrapper+0x28/frame 0x4074e7d4 > > > vpanic(f9d603,4074e80c,4074e80c,4074e834,f6e2b7,...) at > > > vpanic+0x11a/frame 0x4074e7ec > > > panic(f9d603,fe16b8,0,f,c39b,...) at panic+0x14/frame 0x4074e800 > > > trap_fatal(1327100,0,c95893,78f03f4,4074e860,...) at > > > trap_fatal+0x347/frame 0x4074e834 > > > trap_pfault(c374,0,0) at trap_pfault+0x30/frame 0x4074e864 > > > trap(4074e93c,8,28,28,0,...) at trap+0x381/frame 0x4074e930 > > > calltrap() at 0xffc0319f/frame 0x4074e930 > > > --- trap 0xc, eip = 0xef411f, esp = 0x4074e97c, ebp = 0x4074e988 --- > > > vm_radix_lookup(28c7b884,2,0) at vm_radix_lookup+0x7f/frame 0x4074e988 > > > vm_page_lookup(28c7b854,2,0) at vm_page_lookup+0x15/frame 0x4074e99c > > > vm_fault(24ed8d58,3488b000,2,0,4074eab0) at vm_fault+0x839/frame > > > 0x4074ea48 > > > vm_fault_quick_hold_pages(24ed8d58,34889f00,8000,2,4074eaa8,12) at > > > vm_fault_quick_hold_pages+0x122/frame 0x4074ea88 > > > vn_io_fault1(247f4380) at vn_io_fault1+0x214/frame 0x4074eb44 > > > vn_io_fault(2f5a58e8,4074ebc8,262c1e00,0,247f4380) at > > > vn_io_fault+0x1c4/frame 0x4074eb7c > > > dofileread(2f5a58e8,4074ebc8,,,0) at > > > dofileread+0x6d/frame 0x4074ebac > > > sys_read(247f4380,247f4618,343fb000,247f4380,40516068,...) at > > > sys_read+0x67/frame 0x4074ec00 > > > syscall(4074ece8,3b,3b,3b,2d130d1c,...) at syscall+0x17d/frame 0x4074ecdc > > > Xint0x80_syscall() at 0xffc033f9/frame 0x4074ecdc > > > --- syscall (881410048), eip = 0x2d086faf, esp = 0xfa1e339c, ebp = > > > 0xfa1e33c8 --- > > > KDB: enter: panic > > > > This is the crash. > > The DRM mutex noise is just noise (but it would be good to get rid of it). > > OK. It only happens with drm. > > What other info is needed to help track this down? > I have kernel.debug, vmcore.0, and core.txt.0, so > can use kgdb if someone would like more information. > > __ > steve Only happens with drm when you do what ? -- Emmanuel Vadot ___ 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: drm-fbsd13-kmod pkg-descr
On Fri, 29 Jan 2021 04:59:27 -0500 monochrome wrote: > correct me if I'm wrong, but shouldn't it say: > > Currently corresponding to Linux 5.4.62 DRM. > > instead of: > > Currently corresponding to Linux 4.16 DRM. > > got caught by this while trying to update drm-devel-kmod from ports on > stable/13, and took a chance that it was just an oversight :) Indeed, just fixed this. Thanks, -- Emmanuel Vadot ___ 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: i915kms and chip resets on rsc0?
On Thu, 28 Jan 2021 12:02:55 -0800 Steve Kargl wrote: > On Thu, Jan 28, 2021 at 08:48:06PM +0100, Emmanuel Vadot wrote: > > On Thu, 28 Jan 2021 11:15:10 -0800 > > Steve Kargl wrote: > > > > > All, > > > > > > I have finally gotten my old laptop somewhat back to it > > > 2 Dec 2020 working state. The kernel/world/drm-current-kmod > > > from 2 Dec 2020 worked wonderfully. Sadly, the two week > > > recover from a failed update has one final hurdle. > > > > > > With nearly top-of-tree src/ and ports/ > > > > > > % cd /usr/src > > > % git log | more > > > commit 0e01ea872ee475d7aef11d21588504e2ef4eb32c > > > Author: Cy Schubert > > > Date: Wed Jan 27 21:52:08 2021 -0800 > > > > > > % pkg info | grep kmod > > > drm-current-kmod-5.4.62.g20210128 DRM modules for the linuxkpi-based KMS > > > components > > > gpu-firmware-kmod-g20201213Firmware modules for the linuxkpi-based > > > KMS components > > > > > (snip) > > > > Asynchronous wait on fence i915:Xorg[100156]:4 timed out > > > (hint:0x24ad37f0S) > > > drmn0: GPU recovery timed out, cancelling all in-flight rendering. > > > drmn0: Resetting chip for hang on rcs0 > > > > > > > Does 5.4.62.g20210118 works ? > > It works to the extent that the X server loads and > the fvwm2 window manager comes up with my normal > desktop. In fact, I'm typing this in a xterm at > that moment. > > What I don't know is if the X server is ignoring the GPU. > It is unclear to me if the last "drmn0: Resetting chip > for hang on rcs0" is disabling some functionality. xwininfo > reports > > % xwininfo > > xwininfo: Window id: 0xef (the root window) (has no name) > > Absolute upper-left X: 0 > Absolute upper-left Y: 0 > Relative upper-left X: 0 > Relative upper-left Y: 0 > Width: 1400 > Height: 1050 > Depth: 24 > Visual: 0x21 > Visual Class: TrueColor > Border width: 0 > Class: InputOutput > Colormap: 0x20 (installed) > Bit Gravity State: ForgetGravity > Window Gravity State: NorthWestGravity > Backing Store State: NotUseful > Save Under State: no > Map State: IsViewable > Override Redirect State: no > Corners: +0+0 -0+0 -0-0 +0-0 > -geometry 1400x1050+0+0 > > which looks like what I expect for 'startx -- -depth 24'. > > -- > Steve No I meant does the previous version of the ports works or was it since today's update ? -- Emmanuel Vadot ___ 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: i915kms and chip resets on rsc0?
ng on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > tun0: link state changed to UP > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: Resetting chip for hang on rcs0 > Asynchronous wait on fence i915:Xorg[100156]:4 timed out (hint:0x24ad37f0S) > drmn0: GPU recovery timed out, cancelling all in-flight rendering. > drmn0: Resetting chip for hang on rcs0 > > > > ___ > freebsd-...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org" Does 5.4.62.g20210118 works ? If so I suggest you clone the 5.4-lts branch from https://github.com/freebsd/drm-kmod/ and bisect between tags drm_v5.4.62_9 and drm_v5.4.92_1. Cheers, -- Emmanuel Vadot ___ 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: loading drm crashes system
On Tue, 26 Jan 2021 07:02:11 + Alexey Dokuchaev wrote: > On Mon, Jan 25, 2021 at 10:21:16PM -0500, Robert Huff wrote: > > Niclas Zeising asks: > > > When did it stop working? > > > > September ... I _think_. > > Yeah, that sounds about right. > > There are known issues with Radeon cards, they were quite well supported > a year ago, then something got broken. I've promised to bisect this and > find the cause, but there were several syscall-related changes in -CURRENT > though the course of the last year, so bisecting just the kernel is not > enough (machine won't get to login prompt if the userland does not match), > which cripples the process. > > I still intend to take this quest, just not sure when. :( > > ./danfe So back in November I applied a few commits from tijl@ related to radeon and i386 (added to cc) : https://github.com/freebsd/drm-kmod/commits/5.4-lts?author=t...@coosemans.org For me this fixed radeon so that gives some timeline if someone with non working hardware wants to bisect. I know that bisecting drm-kmod is somewhat hard as you always need matching kernel code when we update it to use some new functionality in base linuxkpi but there is nothing that I can do about it. It might work and be quicker to only bisect the kernel with a stable/12 userland (no need to recompile) so I would start by testing a kernel from early november and same date for drm-kmod. Tijl since you also reported a build failure a few days/weeks ago for radeon can you report if your radeon card works ? (And which one it is). Cheers, -- Emmanuel Vadot ___ 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: make buildkernel is broken (linuxkpi vs drm)
On Wed, 20 Jan 2021 22:21:09 -0800 Steve Kargl wrote: > On Thu, Jan 21, 2021 at 07:18:07AM +0100, Hans Petter Selasky wrote: > > On 1/21/21 7:13 AM, Steve Kargl wrote: > > > It is 'make buildkernel' in /usr/src after a 'make buildworld'. > > > I have 'PORTS_MODULES+= graphics/drm-current-kmod' in /etc/make.conf. > > > > Try to update the ports tree. I'm not aware of any current build issues in > > this area. > > > > I tried that. I did not fix the problem. Commenting > out the PORTS_MODULES line in /etc/make.conf allows > me to finish building the new kernel. I re-install > the port after I install world/kernel. > > -- > Steve Does it works now ? I think that PORTS_MODULES shouldn't be used for drm-current-kmod or we should not install the source with it if PORTS_MODULES is the right way. The problem is that drm-current-kmod install its sources in /usr/local/sys and by default all modules there will be rebuild when doing make buildkernel unless LOCAL_MODULES is defined. The problem with installing sources is that if something changed in base that broke the build with a certain version of drm-current-kmod you first need to upgrade the ports/package to have the new sources to be able to make buildkernel correctly. I personally hate the fact that we install the sources as it only causes problems for users but some people seems to like it. It seems that if we don't install the sources and one uses PORTS_MODULES we just need to upgrade the ports tree before running make buildkernel if there is a conflicting changes which seems saner to me tbh. For now I've been focusing the rage that LOCAL_MODULES exists and cause this kind of problems on migrating more stuff into base so that one day we will finally have drm in base again. But I'm a bit tired of dealing with all those problems and I've wondered a lot of times about removing installing sources for drm-current-kmod. Adding jhb@ to cc as I know he uses LOCAL_MODULES so maybe he can explain the advantage over PORTS_MODULES. -- Emmanuel Vadot ___ 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: DRM problem installing kernel on main-c561-gc3e75b6c1
On Wed, 20 Jan 2021 09:47:28 -0800 Pete Wright wrote: > > > On 1/19/21 11:55 PM, Emmanuel Vadot wrote: > > > >> i'm happy now running the current-kmod but let me know if it'd be > >> helpful to do any more tests or provide additional info. > > So what did you change ? > > > ok i think i spot the issue - in my checkout of the ports tree via the > github mirror at git://github.com/freebsd/freebsd-ports.git it looks > like the pkg-plist doesn't include the %%SOURCE%%KMODSRC%% statements: > > $ cat pkg-plist > %%AMDGPU%%/%%KMODDIR%%/amdgpu.ko > %%AMDKFD%%/%%KMODDIR%%/amdkfd.ko > /%%KMODDIR%%/drm.ko > %%I915%%/%%KMODDIR%%/i915kms.ko > /%%KMODDIR%%/linuxkpi_gplv2.ko > /%%KMODDIR%%/radeonkms.ko > /%%KMODDIR%%/ttm.ko > $ > > on the drm-current-kmod plist things look as we would expect them i believe: > $ head pkg-plist > %%AMDGPU%%/%%KMODDIR%%/amdgpu.ko > /%%KMODDIR%%/drm.ko > %%I915%%/%%KMODDIR%%/i915kms.ko > /%%KMODDIR%%/linuxkpi_gplv2.ko > /%%KMODDIR%%/radeonkms.ko > /%%KMODDIR%%/ttm.ko > %%SOURCEKMODSRC%%/Makefile > %%SOURCEKMODSRC%%/kconfig.mk > %%SOURCEKMODSRC%%/amd/Makefile > %%SOURCEKMODSRC%%/amd/amdgpu/Makefile > $ > > > I can file a PR with a patch later today if that's helpful, if this > isn't due to bad git workspace on my end. > > cheers, > -pete > > -- > Pete Wright > p...@nomadlogic.org > @nomadlogicLA drm-devel-kmod doesn't install the sources on purpose. It never had and never will. So, did you "solve" the problem by switching to drm-current-kmod or to drm-devel-kmod ? -- Emmanuel Vadot ___ 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: DRM problem installing kernel on main-c561-gc3e75b6c1
On Tue, 19 Jan 2021 13:29:12 -0800 Pete Wright wrote: > > > On 1/19/21 1:18 PM, Emmanuel Vadot wrote: > > > >> interesting - so it seems like if i have drm-devel-kmod installed this > >> will fail (missing or wrong linuxkpi_gplv2.ko). this happens both if i > >> install the pkg and rebuild the kernel, and if i build the kernel w/o > >> the pkg installed. > > Don't use the package, always rebuild from the latest ports. > see bellow > >> yet, if i have the drm-current-kmod pkg installed, then "make > >> buildkernel" it looks like the i915/amdgpu modules get build and an > >> "installkernel" drops the linuxkpi_gplv2.ko module under /boot/kernel. > >> at that point i am able to successfully load the amdgpu.ko. > > drm-current-kmod will also install its sources in /usr/local/sys/ and > > this will get built with buildkernel. The problem is that if the > > package is old (and it is right now) you might have sources that either > > don't compile or don't work correctly. > OK interesting, in both cases I was building the package from my local > ports tree (via "make package"). i should have better explained that in > previous emails. Ok > i verified my checkout was up to date as well (it includes your latest > commits from Sunday and Monday). Ok > i'm happy now running the current-kmod but let me know if it'd be > helpful to do any more tests or provide additional info. So what did you change ? > cheers, > -pete > > > > > -- > Pete Wright > p...@nomadlogic.org > @nomadlogicLA > > ___ > 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" -- Emmanuel Vadot ___ 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: DRM problem installing kernel on main-c561-gc3e75b6c1
On Tue, 19 Jan 2021 13:06:37 -0800 Pete Wright wrote: > > > On 1/19/21 12:18 PM, Pete Wright wrote: > > > > > > On 1/19/21 12:11 PM, Emmanuel Vadot wrote: > >> On Tue, 19 Jan 2021 11:40:04 -0800 > >> Pete Wright wrote: > >> > >>> > >>> On 1/19/21 11:33 AM, Pete Wright wrote: > >>>> > >>>> On 1/19/21 6:26 AM, Thomas Laus wrote: > >>>>> I perform a CURRENT build weekly on a more powerful build machine and > >>>>> then export /usr/src and /usr/obj via NFS to other slower PC's. The > >>>>> 'installkernel' phase failed with 'linuxkpi_gplv2.ko' not found. It > >>>>> looks like this file is not installed before the rest of the > >>>>> 'drm-current-kmod' files. This causes the 'installkernel' over NFS > >>>>> to fail. > >>>>> > >>>>> My fis was to un-install drm-current-kmod, install the kernel and > >>>>> then > >>>>> re-install drm-current-kmod. > >>>> hrm, i'm not sure this is specifically an NFS issue. I am > >>>> building/installing locally on my workstation but am getting similar > >>>> errors trying to load drm-devel-kmod's amdgpu mod. at this point even > >>>> uninstalling drm-devel-kmod, make installkernel, install > >>>> drm-devel-kmod pkg results in the same problem. > >>>> > >>> forgot to include dmesg error: > >>> KLD drm.ko: depends on linuxkpi_gplv2 - not available or version > >>> mismatch > >>> linker_load_file: /boot/modules/drm.ko - unsupported file type > >>> KLD amdgpu.ko: depends on drmn - not available or version mismatch > >>> linker_load_file: /boot/modules/amdgpu.ko - unsupported file type > >>> > >>> -pete > >>> > >>> -- > >>> Pete Wright > >>> p...@nomadlogic.org > >>> @nomadlogicLA > >> Sound like you have an old linuxkpi_gplv2.ko in /boot/kernel/ > >> > > > > Thanks Manu - so it looks like i don't have that file under > > /boot/kernel/ but in /boot/modules instead: > > $ find /boot/ -name '*linuxkpi*' -print > > /boot/modules/linuxkpi_gplv2.ko > > /boot/kernel/linuxkpi.ko > > /boot/kernel.old/linuxkpi.ko > > $ pkg which /boot/modules/linuxkpi_gplv2.ko > > /boot/modules/linuxkpi_gplv2.ko was installed by package > > drm-current-kmod-5.4.62.g20210118 > > $ > > > > above is after installing the current kmod to see if it behaved > > differently than the devel one. > > > > -pete > > > > > > interesting - so it seems like if i have drm-devel-kmod installed this > will fail (missing or wrong linuxkpi_gplv2.ko). this happens both if i > install the pkg and rebuild the kernel, and if i build the kernel w/o > the pkg installed. Don't use the package, always rebuild from the latest ports. > yet, if i have the drm-current-kmod pkg installed, then "make > buildkernel" it looks like the i915/amdgpu modules get build and an > "installkernel" drops the linuxkpi_gplv2.ko module under /boot/kernel. > at that point i am able to successfully load the amdgpu.ko. drm-current-kmod will also install its sources in /usr/local/sys/ and this will get built with buildkernel. The problem is that if the package is old (and it is right now) you might have sources that either don't compile or don't work correctly. > finally, i install the drm-current-pkg fresh (without doing the above > buildkernel/installkernel) i get the linuxkpi_gplv2 error as above. > > -pete > > -- > Pete Wright > p...@nomadlogic.org > @nomadlogicLA > -- Emmanuel Vadot ___ 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: DRM problem installing kernel on main-c561-gc3e75b6c1
On Tue, 19 Jan 2021 11:40:04 -0800 Pete Wright wrote: > > > On 1/19/21 11:33 AM, Pete Wright wrote: > > > > > > On 1/19/21 6:26 AM, Thomas Laus wrote: > >> I perform a CURRENT build weekly on a more powerful build machine and > >> then export /usr/src and /usr/obj via NFS to other slower PC's. The > >> 'installkernel' phase failed with 'linuxkpi_gplv2.ko' not found. It > >> looks like this file is not installed before the rest of the > >> 'drm-current-kmod' files. This causes the 'installkernel' over NFS > >> to fail. > >> > >> My fis was to un-install drm-current-kmod, install the kernel and then > >> re-install drm-current-kmod. > > hrm, i'm not sure this is specifically an NFS issue. I am > > building/installing locally on my workstation but am getting similar > > errors trying to load drm-devel-kmod's amdgpu mod. at this point even > > uninstalling drm-devel-kmod, make installkernel, install > > drm-devel-kmod pkg results in the same problem. > > > forgot to include dmesg error: > KLD drm.ko: depends on linuxkpi_gplv2 - not available or version mismatch > linker_load_file: /boot/modules/drm.ko - unsupported file type > KLD amdgpu.ko: depends on drmn - not available or version mismatch > linker_load_file: /boot/modules/amdgpu.ko - unsupported file type > > -pete > > -- > Pete Wright > p...@nomadlogic.org > @nomadlogicLA Sound like you have an old linuxkpi_gplv2.ko in /boot/kernel/ -- Emmanuel Vadot ___ 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: Current kernel build broken with linuxkpi?
On Wed, 13 Jan 2021 16:19:09 -0500 Robert Huff wrote: > > Emmanuel Vadot writes: > > > That's one of the problems of having external kmods. > > drm-current-kmod have the option by default to install it's > > sources in /usr/local/sys/ and when doing a make buildkernel > > those sources are getting built too. > > That would be the SOURCE option? Yes > Further: if I have that set ... does that mean I can remove it > from PORTS_MODULES? I don't know what that is > (And I assume a note about this will appear in UPDATING?) A note about what ? Cheers, > > Respectfully, > > > Robert Huff > > > ___ > 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" -- Emmanuel Vadot ___ 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: Current kernel build broken with linuxkpi?
On Wed, 13 Jan 2021 14:52:32 -0500 Robert Huff wrote: > > Hans Petter Selasky : > > > You need to update that DRM port you are using before the issue > > will be fixed. > > I'm confused. > I have drm-current-kmod listed in PORTS_MODULES; things on that > list get built _after_ buildkernel (installkernel??) for reasons I > thought I understood. > You are telling me I need to update this _before_ buildkernel? > > > Perplexedly, > > > Robert Huff > That's one of the problems of having external kmods. drm-current-kmod have the option by default to install it's sources in /usr/local/sys/ and when doing a make buildkernel those sources are getting built too. One problem is that when, like with the latest update to linuxkpi that I did, we introduce changes that breaks external kmods, you first need to upgrade your ports/package (not your ports tree) so the new sources are updated too and then do a make buildkernel. That really sucks but still helps a bit when there isn't conflicted changes in the source tree but you still need to rebuild your kernel module. -- Emmanuel Vadot ___ 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: Problem compiling drm-current-kmod
On Wed, 13 Jan 2021 11:45:31 +0100
Emmanuel Vadot wrote:
> On Wed, 13 Jan 2021 10:32:01 + (UTC)
> Filippo Moretti wrote:
>
> > Good morning, my system:[root@STING
> > /usr/ports/graphics/drm-current-kmod]# uname -a
> > FreeBSD STING 13.0-CURRENT FreeBSD 13.0-CURRENT #16
> > main-c255860-g2903606b606: Tue Jan 12 04:59:16 CET 2021
> > root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING amd64
> >
> > I get the following error while trying to upgrade drm-current-kmod from
> > ports:/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_6/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4009:6:
> > error: implicit declaration of function 'pci_is_root_bus' is invalid in
> > C99 [-Werror,-Wimplicit-function-declaration]
> > if (pci_is_root_bus(adev->pdev->bus)) {
> > ^
> > /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_6/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4009:6:
> > note: did you mean 'pci_set_bus'?
> > /usr/src/sys/dev/pci/pcivar.h:385:1: note: 'pci_set_bus' declared here
> > PCI_ACCESSOR(bus, BUS, uint8_t)
> > ^
> > /usr/src/sys/dev/pci/pcivar.h:371:2: note: expanded from macro
> > 'PCI_ACCESSOR'
> > __BUS_ACCESSOR(pci, var, PCI, ivar, type)
> > ^
> > /usr/src/sys/sys/bus.h:812:22: note: expanded from macro '__BUS_ACCESSOR'
> > static __inline void varp ## _set_ ## var(device_t dev, type t) \
> > ^
> > :77:1: note: expanded from here
> > pci_set_bus
> > ^
> > 1 error generated.*** Error code 1
> >
> > Stop.
> > make[4]: stopped in
> > /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_6/amd/amdgpu
> > *** Error code 1
> > *** Error code 1
> > *** Error code 1
> >
> > Stop.
> > make[1]: stopped in /usr/ports/graphics/drm-current-kmod
> > *** Error code 1
> >
> > Stop.
> > make: stopped in /usr/ports/graphics/drm-current-kmod
> >
> > Filippo
> > ___
> > 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"
>
> Sorry that's my fault.
> https://github.com/freebsd/drm-kmod/blob/master/linuxkpi/gplv2/include/linux/pci.h#L121
>
> This if 0 should have been #if __FreeBSD_version < 1300135
> I'll check if I've missed more and update the port.
> In the meantime either update your kernel after commit
> 35a39dc5b34962081eeda8dbcf0b99a31585499b or wait that I fix this.
Fixed in r561457.
--
Emmanuel Vadot
___
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: Problem compiling drm-current-kmod
On Wed, 13 Jan 2021 10:32:01 + (UTC)
Filippo Moretti wrote:
> Good morning, my system:[root@STING
> /usr/ports/graphics/drm-current-kmod]# uname -a
> FreeBSD STING 13.0-CURRENT FreeBSD 13.0-CURRENT #16
> main-c255860-g2903606b606: Tue Jan 12 04:59:16 CET 2021
> root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING amd64
>
> I get the following error while trying to upgrade drm-current-kmod from
> ports:/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_6/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4009:6:
> error: implicit declaration of function 'pci_is_root_bus' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]
> if (pci_is_root_bus(adev->pdev->bus)) {
> ^
> /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_6/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4009:6:
> note: did you mean 'pci_set_bus'?
> /usr/src/sys/dev/pci/pcivar.h:385:1: note: 'pci_set_bus' declared here
> PCI_ACCESSOR(bus, BUS, uint8_t)
> ^
> /usr/src/sys/dev/pci/pcivar.h:371:2: note: expanded from macro 'PCI_ACCESSOR'
> __BUS_ACCESSOR(pci, var, PCI, ivar, type)
> ^
> /usr/src/sys/sys/bus.h:812:22: note: expanded from macro '__BUS_ACCESSOR'
> static __inline void varp ## _set_ ## var(device_t dev, type t) \
> ^
> :77:1: note: expanded from here
> pci_set_bus
> ^
> 1 error generated.*** Error code 1
>
> Stop.
> make[4]: stopped in
> /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_6/amd/amdgpu
> *** Error code 1
> *** Error code 1
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/graphics/drm-current-kmod
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/graphics/drm-current-kmod
>
> Filippo
> ___
> 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"
Sorry that's my fault.
https://github.com/freebsd/drm-kmod/blob/master/linuxkpi/gplv2/include/linux/pci.h#L121
This if 0 should have been #if __FreeBSD_version < 1300135
I'll check if I've missed more and update the port.
In the meantime either update your kernel after commit
35a39dc5b34962081eeda8dbcf0b99a31585499b or wait that I fix this.
--
Emmanuel Vadot
___
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: Build failure
On Fri, 2 Oct 2020 19:53:44 -0500 Patrick McMunn wrote: > I update the sources today and ran "make -j24 buildworld buildkernel > KERNCONF=GENERIC-NODEBUG", and the build failed. I made sure to "make > clean" and "make cleanworld" and try again, and I got the same result. > > -- > Patrick McMunn > > - Learn more about the Catholic Faith: http://www.catholic.com/ > - Pray with the Church: http://www.universalis.com/ Hi, You need to update your ports tree. the drm-current-kmod ports install it's sources so the module will be rebuilt when you build a kernel. This works as long as no changes in base need changes in those sources too. If there is needed changes in drm-kmod sources this unfortunatelly fails to compile, not much we can do here. Cheers, -- Emmanuel Vadot ___ 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: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
On Thu, 10 Sep 2020 16:36:44 + Glen Barber wrote: > On Thu, Sep 10, 2020 at 06:25:51PM +0200, Emmanuel Vadot wrote: > > On Thu, 3 Sep 2020 16:00:51 + > > Glen Barber wrote: > > > > > On Thu, Sep 03, 2020 at 05:33:54PM +0200, Emmanuel Vadot wrote: > > > > > > > > Hello, > > > > > > > > On Thu, 3 Sep 2020 15:02:45 + > > > > Glen Barber wrote: > > > > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > > Hash: SHA256 > > > > > > > > > > New FreeBSD development branch installation ISOs and virtual machine > > > > > disk images have been uploaded to the FreeBSD Project mirrors. > > > > > > > > > > NOTE: These are the first snapshots built from the FreeBSD Git > > > > > sources. > > > > > Also note: The armv6 and armv7 builds failed, and the cause is being > > > > > investigated. > > > > > > > > There is also no embbeded aarch64 image (pine64* rpi3 etc ...), do you > > > > have more info ? > > > > > > > > > > The ports tree failed to mount within the chroot directory. I think > > > I see why, and am testing a fix now. > > > > > > > Looks like there was a problem this week too. > > How can I help ? > > > > Nothing really. I know what the problem is. The ports tree mounting > issue had been fixed, but two things: 1) the u-boot port failed to > fetch for at least one of the boards; 2) something got screwed up in the > environment, due to path changes and how the git checkout structure is > set up. > > The first is basically a timing issue with a ports commit and > distribution of the distfiles. The second I am working on fixing now, > which should be Relatively Easy(tm). > > Glen > Which port commit and which board ? There haven't been a commit in the u-boot ports or rpi-firmware this a month now so I fails to understand without more info. -- Emmanuel Vadot ___ 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: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
On Thu, 3 Sep 2020 16:00:51 + Glen Barber wrote: > On Thu, Sep 03, 2020 at 05:33:54PM +0200, Emmanuel Vadot wrote: > > > > Hello, > > > > On Thu, 3 Sep 2020 15:02:45 + > > Glen Barber wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA256 > > > > > > New FreeBSD development branch installation ISOs and virtual machine > > > disk images have been uploaded to the FreeBSD Project mirrors. > > > > > > NOTE: These are the first snapshots built from the FreeBSD Git sources. > > > Also note: The armv6 and armv7 builds failed, and the cause is being > > > investigated. > > > > There is also no embbeded aarch64 image (pine64* rpi3 etc ...), do you > > have more info ? > > > > The ports tree failed to mount within the chroot directory. I think > I see why, and am testing a fix now. > > Glen > Looks like there was a problem this week too. How can I help ? -- Emmanuel Vadot ___ 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"
DRM Report 2020-08-31
Hello all, Time for a report on DRM progress. I've updated the drm-devel-ports to be in sync (minus a few patches) to Linux v5.4.62, the latest LTS release. The Linux default for PSR (Panel Self Refresh) and Power Well was modified for FreeBSD, meaning that PSR is always off and power well is always on. Both defaults don't work well on FreeBSD, the PSR issue is the biggest one as when activated on certain hardware the console only refresh every 30 seconds or so and since I don't have the hardware to reproduce the issue it's better to just switch it off for now. The power well issue manifest when using an hdmi monitor, this cause a large numbers of message to be printed on the console and also on certain hardware hdmi audio won't come back after display is put to sleep. Both issues are likely due to some missing pieces in the LinuxKPI framework but I'm unsure which for now. I think that it's almost time to have drm-devel-kmod content put in drm-current-kmod, I plan to open a review during next week. I'm still working on making live usb image that will automate a lot of test and generate a report that users can paste directly on a wiki page but in the mean time I've generated two images for users to test the current state of affairs of drm drivers on their hardware without needing to install freebsd current + packages etc ... This first one is just FreeBSD current + ports head. The only customization on the ports are the VAAPI and VDPAU option to graphics/mesa-dri. The second one contains modification to the base tree and the drm-devel-ports to have the backlight subsystem built (https://reviews.freebsd.org/D26250 and child revisions). The TLDR on backlight is that you don't need acpi_video or intel-backlight to control your screen backlight anymore, simply use backlight(8). This should work on all Intel or AMD laptops while other ways (acpi_video or intel-backlight) don't always works. I intend to commit this next week. The -devel image also have hw.amdgpu.exp_hw_support set to 1 so users of Renoir GPU might have a chance that it works. It also have mesa 20.2-rc4 which is needed for AMD Navi and Renoir. Both images autoload i915kms and amdgpu at startup, this cause problems on Intel machine with an AMD discret gpu and I will look into this during next week (only found out this weekend when testing on one of my laptop that have such a configuration). They also contains two short video files (ten seconds of Big Buck Bunny in 2016p and native resolution) that could be used to test that gpu decoding is working (both mpv and vlc are included in this image). The root user don't have a password and there is a 'freebsd' user without password too. For Xorg users only twm is included, for Wayland users sway is included. Both X and Wayland work out of the box by either typing 'startx' or 'sway' at the console. Both glxinfo/glxgears and vkcube-xlib There is NO NVidia drivers, we don't have nouveau ported and the NVidia drivers have their own DRM implementation so I'm not interested in it. As a reminder : The i915kms driver support up to Ice Lake/Gen 11 (maybe Tiger Lake but I don't think that hardware is out yet). The amdgpu driver supports every GCN-based architectures, from Southern Island (Radeon HD 7000) to Navi (RX 5000). And Renoir is experimental in 5.4 so it need hw.amdgpu.exp_hw_support to be set to 1 at loader prompt or in loader.conf. The radeonkms supports older (<2012, up to Northern Island/HD 5000) AMD/ATI GPUs. Links for the images : http://wopr.blih.net/drm-live-20200906.img.xz http://wopr.blih.net/drm-live-devel-20200906.img.xz They are both ~500MB compressed and 3GB uncompressed (with ~400MB free on the disk if you want to install more packages). I'll post the receipe for building them next week after a cleanup. glxinfo and glxgears are present to test gpu acceleration and vkcube-xlib/vkcube-wayland to test Vulkan. What I'm most interested in the result of testing this image is kernel panic at boot or unsupported hardware (relevant hardware so >= 2012). In that case a issue at https://github.com/freebsd/drm-kmod/ would be the best thing to do. I'm also interested in AMD users telling me if they use the mesa-dri option VDPAU, I can't make it work with my system (but mpv -vo=gpu works perfectly). -- Emmanuel Vadot ___ 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: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
2fab5776f94a5074777963bf6904c6310 > SHA512 (FreeBSD-13.0-CURRENT-i386-20200903-c122cf32f2a.raw.xz) = > 16b7b2746fb5dd00a04527a9741ed32ed09ddf3acff27dbf712503fd27bcfa92d020999e93040690b0d1618647e00af72687a387560ffa76a70895ea9ce16e61 > SHA512 (FreeBSD-13.0-CURRENT-i386-20200903-c122cf32f2a.vhd.xz) = > d0dfc43b99987540837977722b0525867c1e2a724de29e9a7e99e9a0e731091ac7f8b9fa391a306290b83f4ecd5ac2f4b7e8ca065f5b359c8c7d5b55279cb637 > SHA512 (FreeBSD-13.0-CURRENT-i386-20200903-c122cf32f2a.vmdk.xz) = > bd08a356b4d8cd93815a68b1b572d9b3930264f68608a71c085037ee94bb50f1c9733e50c185d996c4480001f03533410229ad443c7f24d3da655ff2b3ebe062 > > SHA256 (FreeBSD-13.0-CURRENT-i386-20200903-c122cf32f2a.qcow2.xz) = > 19ebe05527887c1bd77a0f64f71849e559cfcf4b598af02e7a275be44bd43df5 > SHA256 (FreeBSD-13.0-CURRENT-i386-20200903-c122cf32f2a.raw.xz) = > 330962c111dca2eee00cc74947d0c6c17f0e0100b8691f4e3bab5816d531b11b > SHA256 (FreeBSD-13.0-CURRENT-i386-20200903-c122cf32f2a.vhd.xz) = > 8c927c800f9063fbfa7b0cc29d2d45ba7d57490edf566ae75fd7b1200e423c2f > SHA256 (FreeBSD-13.0-CURRENT-i386-20200903-c122cf32f2a.vmdk.xz) = > 048eeacc8bfbd609a87a09f65907d78bb73969e94213c28a0591eca850d45ff1 > > > o 13.0-CURRENT aarch64: > SHA512 (FreeBSD-13.0-CURRENT-arm64-aarch64-20200903-c122cf32f2a.qcow2.xz) = > 27271c817add01cc08cad66dbf534e8de01fd9a048de93c3778e63e8097f7417de3772f4740346520b56a07733c5fe5984282b25af70d66f10c6e4006fd8528a > SHA512 (FreeBSD-13.0-CURRENT-arm64-aarch64-20200903-c122cf32f2a.raw.xz) = > 5ea379e64d534468033a84b62d1696f715843073cb25ef34d7cdc0b2bd459e90325c77f270b0546d39589aa08108cb1a5622a856992f33e41ea7f882fda9c33a > SHA512 (FreeBSD-13.0-CURRENT-arm64-aarch64-20200903-c122cf32f2a.vhd.xz) = > d86bfa42b8f6adcfe8e5377312d7a918bbd713ecc2a273bc7b35423709ba9b680fc2b4270c322920e690cbbde9f63eae7cc1d905ca956c9a18fc10bec7441803 > SHA512 (FreeBSD-13.0-CURRENT-arm64-aarch64-20200903-c122cf32f2a.vmdk.xz) = > d72ea26a292613a1481da39e5afae4a20cb9731b4c0e99b5ef41ee3b5e4bbecdec46342f3481d175cb6222a4873fa81db3b9c6f0cf8b2bc06d158a67dd3386e2 > > SHA256 (FreeBSD-13.0-CURRENT-arm64-aarch64-20200903-c122cf32f2a.qcow2.xz) = > 4caacd5bf858bbf2fd346963af103c06f9abb9cfa5b1f7e0cd5a9b9763d7ee58 > SHA256 (FreeBSD-13.0-CURRENT-arm64-aarch64-20200903-c122cf32f2a.raw.xz) = > 7ac321d23dd3280b7ea5c72730b6f5586027bb709365663258e7154e47071e50 > SHA256 (FreeBSD-13.0-CURRENT-arm64-aarch64-20200903-c122cf32f2a.vhd.xz) = > cb9849e4c832d04cc6235cb42619a30ad0705aa012949e3658a5ae3d97a05ece > SHA256 (FreeBSD-13.0-CURRENT-arm64-aarch64-20200903-c122cf32f2a.vmdk.xz) = > 198cbd12b5143d45af7702a43fa76f0003a036d8bb79466fba77bf8309913f4a > > Regards, > > Glen > > Love FreeBSD? Support this and future releases with a donation to > the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/ > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAl9RBZUACgkQAxRYpUeP > 4pMLBg/9EHxM0cnCo80mXhguMQWaWvhPUH+ZaGgAfYda5i/MK9O28Ni7FcURsBK+ > E0OzQYFre26xfHfDNWj8s2PMJGx/Vs45yuXVXsRPno6idZjdCEpmifeHuvdeuAhs > AfgA7wWdBKSTgZHVXgfsKwhZarbaAAD3n4qA1rGQWHp2eYvza7KlciJzWNDfecUZ > x1T+TAiGY1/UG/QD3bCLM/cFkhshAbLaxDiT5L9BAi/YsbGwBie2UaXhtWLQdlWy > A+dDGw+PNJwPzV7gWZ3o1k8qv9/j25fFClKQO0SZFlq73j/+hEziYvkL9q1+cin/ > R+3KkAO+hjCfyLZefqK/ox2yWT2tTxNuf5UX+iTFYEbPWZNy+6XsEbaLG2Uy/bz4 > lv3LnhPTXFGNJLEDRiVwaBR8l+8FvsXblu4GtW3gI2eH6h8zX3RRq+g+NKKvz/gs > wuosAJziJajTv4JWjf+HV8T4RmgU2LEiPUCZXvtkIsw59kueRucNiaU3J86iRHzG > 4AE30G12zYMHXDEE9vlZsFCNRfHDjBqjABSPrui+x1IMHRMlj9ixyMr7xp6klTun > nuZJ+5DS4bDh7lfG9Y5dKMYb5kFMBKeGHTZ830ovWEd39YD9bbO+uLJO7pbT3Zch > 6NQ670ogcJ8TAzUbjuFZ1EBnPfjqDkpg9jtQFDSGllF8UNsTI4E= > =x/JX > -END PGP SIGNATURE- > ___ > 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" -- Emmanuel Vadot ___ 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: ld: error: duplicate symbol:
On Mon, 17 Aug 2020 21:49:52 +0200 Dimitry Andric wrote: > On 17 Aug 2020, at 15:42, O. Hartmann wrote: > > > > On CURRENT 9not necessarily most recent with LLVM11, but since noon of > > today it > > is FreeBSD 13.0-CURRENT #15 r364297: Mon Aug 17 14:39:06 CEST 2020 amd64) > > I'm > > faced with some very sticky and nasty micompilations in several essential > > ports, for instance > > > > ports-mgmt/pkg > > devel/libunwind > > devel/binutils > > > > In most cases somewhere in the (parallel) build the process fails with the > > error > > > > ld: error: duplicate symbol: > > This is because clang 11 (and gcc 10) now default to -fno-common. The > rationale is explained pretty well in > <https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=6271dd984d7f920d4fb17ad37af6a1f8e6b796dc>: > > "GCC currently defaults to -fcommon. As discussed in the PR, this is an > ancient > C feature which is not conforming with the latest C standards. On many > targets > this means global variable accesses have a codesize and performance penalty. > This applies to C code only, C++ code is not affected by -fcommon. It is > about > time to change the default." > > A quick fix is to add CFLAGS+=-fcommon to your make.conf, but that is > rather a big hammer. It is better to add it to just the ports that show > problems due to duplicated symbols. And ideally, those duplicated > symbols should be patched out of the ports. > > For example, ports-mgmt/pkg already has such a patch: > https://github.com/freebsd/pkg/commit/7fbde60c4af4a1a07db7c5c36efbb2a495f7b1a4 > but I have no idea why it is not yet in the ports tree. I was sure it was at least in pkg-devel but no, I guess I forgot to update svn. It's now unbroke in both pkg and pkg-devel. > -Dimitry > -- Emmanuel Vadot ___ 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: DRM Project report (week of August 10)
On Tue, 18 Aug 2020 10:25:10 +0200 Emmanuel Vadot wrote: > On Mon, 17 Aug 2020 20:44:38 +0200 > Jan Beich wrote: > > > Emmanuel Vadot writes: > > > > > Hello, > > > > > > 5.4 was finilly reached ! > > > For AMD users it means that Navi12/14, Arctarus and Renoir should work. > > > For Intel users it means that TigerLake should work too. > > > > > > No ports update for now as I want to give current users a bit of time > > > to update their base (as the ports needs recent addition to > > > base linuxkpi) but if you have a current >= 364233 you can test > > > directly the master branch of https://github.com/freebsd/drm-kmod/ > > > > > > I plan to commit the port update at the end of the week, and probably > > > at the end of the month we will switch drm-current-kmod to 5.4. > > > > > > It's now time to do 2 main things : > > > - Update stable/12 so it have all the needed code to run 5.4 > > > - Remove the remaining GPLv2 code to start thinking of import into > > > base. > > > > Upstream v5.4 was tagged on 2019-11-24. Did you check linux-5.4.y (LTS) > > doesn't require more LinuxKPI changes? For example, when drm-v5.0 was > > the latest I've played with grafting linux-4.19.y only to discover > > some commits had to be reverted due to missing LinuxKPI bits. > > Not yet, but those bits could be added in the ports for 12.2 if they > are needed anyway. > I did a quick test and only two commits needs to be back-out to have v5.4.58 : https://github.com/torvalds/linux/commit/f14f27b1663269a81ed62d3961fe70250a1a0623 https://github.com/torvalds/linux/commit/873a95e0d59ac06901ae261dda0b7165ffd002b8 I'll look at what's really needed in a few days. I've pushed a 5.4-lts branch https://github.com/freebsd/drm-kmod/tree/5.4-lts This has not been tested yet (just compiled). -- Emmanuel Vadot ___ 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: DRM Project report (week of August 10)
On Mon, 17 Aug 2020 20:44:38 +0200 Jan Beich wrote: > Emmanuel Vadot writes: > > > Hello, > > > > 5.4 was finilly reached ! > > For AMD users it means that Navi12/14, Arctarus and Renoir should work. > > For Intel users it means that TigerLake should work too. > > > > No ports update for now as I want to give current users a bit of time > > to update their base (as the ports needs recent addition to > > base linuxkpi) but if you have a current >= 364233 you can test > > directly the master branch of https://github.com/freebsd/drm-kmod/ > > > > I plan to commit the port update at the end of the week, and probably > > at the end of the month we will switch drm-current-kmod to 5.4. > > > > It's now time to do 2 main things : > > - Update stable/12 so it have all the needed code to run 5.4 > > - Remove the remaining GPLv2 code to start thinking of import into > > base. > > Upstream v5.4 was tagged on 2019-11-24. Did you check linux-5.4.y (LTS) > doesn't require more LinuxKPI changes? For example, when drm-v5.0 was > the latest I've played with grafting linux-4.19.y only to discover > some commits had to be reverted due to missing LinuxKPI bits. Not yet, but those bits could be added in the ports for 12.2 if they are needed anyway. -- Emmanuel Vadot ___ 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: DRM Project report (week of August 10)
On Mon, 17 Aug 2020 10:56:08 -0400 Ed Maste wrote: > On Mon, 17 Aug 2020 at 04:46, Emmanuel Vadot wrote: > > > > - Remove the remaining GPLv2 code to start thinking of import into > > base. > > How much GPLv2 code do we have left now? ~50% of what's in https://github.com/freebsd/drm-kmod/tree/5.4-cleanup-lkpi/linuxkpi/gplv2/src + the includes + all the dma-buf. I have some dma-buf in my drmbase branch for arm that will help. > ___ > 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" -- Emmanuel Vadot ___ 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"
DRM Project report (week of August 10)
Hello, 5.4 was finilly reached ! For AMD users it means that Navi12/14, Arctarus and Renoir should work. For Intel users it means that TigerLake should work too. No ports update for now as I want to give current users a bit of time to update their base (as the ports needs recent addition to base linuxkpi) but if you have a current >= 364233 you can test directly the master branch of https://github.com/freebsd/drm-kmod/ I plan to commit the port update at the end of the week, and probably at the end of the month we will switch drm-current-kmod to 5.4. It's now time to do 2 main things : - Update stable/12 so it have all the needed code to run 5.4 - Remove the remaining GPLv2 code to start thinking of import into base. I'll also start producing some usb image so people could test latest current with 5.4 on their machine and starts reporting bug soon (this is needed for making 5.4 default on 13-CURRENT and later 12.2). All this work is under sponsorship from the FreeBSD Foundation. -- Emmanuel Vadot ___ 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: nightly snapshot for CURRENT ?
On Mon, 27 Jul 2020 14:14:13 + Glen Barber wrote: > On Sat, Jul 25, 2020 at 12:29:42PM +0200, Emmanuel Vadot wrote: > > On Fri, 24 Jul 2020 22:28:39 + > > Glen Barber wrote: > > > > > On Sat, Jul 25, 2020 at 12:14:52AM +0200, Emmanuel Vadot wrote: > > > > On Fri, 24 Jul 2020 22:06:07 + > > > > Glen Barber wrote: > > > > > > > > > On Fri, Jul 24, 2020 at 10:31:35PM +0200, Emmanuel Vadot wrote: > > > > > > On Tue, 9 Jun 2020 22:04:07 +0200 > > > > > > Emmanuel Vadot wrote: > > > > > > > > > > > > > On Tue, 9 Jun 2020 19:56:30 + > > > > > > > Glen Barber wrote: > > > > > > > > > > > > > > > On Tue, Jun 09, 2020 at 09:47:56PM +0200, Emmanuel Vadot wrote: > > > > > > > > > > > > > > > > > > Hello all, > > > > > > > > > > > > > > > > > > I've just hit again something that I've hit (and probably > > > > > > > > > others too) > > > > > > > > > often. > > > > > > > > > If a change in base break some ports and it's snapshoted in > > > > > > > > > the txz > > > > > > > > > available at download.freebsd.org, you need to wait a week > > > > > > > > > for the next > > > > > > > > > tarball to be available. > > > > > > > > > Since poudriere uses the tarball when you setup a jail it > > > > > > > > > means that > > > > > > > > > the only solution you have is to recreate your jail by > > > > > > > > > building it, and > > > > > > > > > since building world nowdays is very expensive that delay > > > > > > > > > your work too > > > > > > > > > much. > > > > > > > > > Would it be possible to generate the tarballs every day > > > > > > > > > instead of > > > > > > > > > every week ? At least for tier-1 arches. > > > > > > > > > > > > > > > > > > > > > > > > > Let's revisit this sometime next week after 11.4 is out. > > > > > > > > > > > > > > > > Glen > > > > > > > > > > > > > > > > > > > > > > Sure, works for me. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > Ping ? > > > > > > > > > > > > > > > > I thought the artifacts from the jenkins builder for CI were > > > > > sufficient. > > > > > > > > > > Glen > > > > > > > > > > > > > Yes and no, > > > > > > > > I can add something to poudriere for getting the tarballs from the CI > > > > artifacts but that won't be by default. > > > > > > > > > > To be honest, that would be the preferred route, since updating the > > > various *.txz distribution sets would break things like bootonly.iso, > > > mini-memstick.img, and so on. > > > > Why would it break things ? > > > > The bootonly.iso and mini-memstick.img do not contain the distribution > sets, only the MANIFEST file. So, people using these to install > a system would not be able to do so, because the checksums for the sets > would not match that in the MANIFEST. What about putting the daily sets in another directory ? With maybe the latest 7 days or something like that. > > > In other words, we already have a system in place that generates these > > > archive files, so I personally see no need to disrupt the "official" > > > snapshot build process to appease a subset of the user base while > > > unnecessarily adding a pain point for the rest. > > > > > > > If only the sets are generated each day I don't see how it can cause a > > pain to anyone. > > > > See above. > > Glen > -- Emmanuel Vadot ___ 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: nightly snapshot for CURRENT ?
On Fri, 24 Jul 2020 22:28:39 + Glen Barber wrote: > On Sat, Jul 25, 2020 at 12:14:52AM +0200, Emmanuel Vadot wrote: > > On Fri, 24 Jul 2020 22:06:07 + > > Glen Barber wrote: > > > > > On Fri, Jul 24, 2020 at 10:31:35PM +0200, Emmanuel Vadot wrote: > > > > On Tue, 9 Jun 2020 22:04:07 +0200 > > > > Emmanuel Vadot wrote: > > > > > > > > > On Tue, 9 Jun 2020 19:56:30 + > > > > > Glen Barber wrote: > > > > > > > > > > > On Tue, Jun 09, 2020 at 09:47:56PM +0200, Emmanuel Vadot wrote: > > > > > > > > > > > > > > Hello all, > > > > > > > > > > > > > > I've just hit again something that I've hit (and probably others > > > > > > > too) > > > > > > > often. > > > > > > > If a change in base break some ports and it's snapshoted in the > > > > > > > txz > > > > > > > available at download.freebsd.org, you need to wait a week for > > > > > > > the next > > > > > > > tarball to be available. > > > > > > > Since poudriere uses the tarball when you setup a jail it means > > > > > > > that > > > > > > > the only solution you have is to recreate your jail by building > > > > > > > it, and > > > > > > > since building world nowdays is very expensive that delay your > > > > > > > work too > > > > > > > much. > > > > > > > Would it be possible to generate the tarballs every day instead > > > > > > > of > > > > > > > every week ? At least for tier-1 arches. > > > > > > > > > > > > > > > > > > > Let's revisit this sometime next week after 11.4 is out. > > > > > > > > > > > > Glen > > > > > > > > > > > > > > > > Sure, works for me. > > > > > > > > > > Thanks, > > > > > > > > > > > > > Ping ? > > > > > > > > > > I thought the artifacts from the jenkins builder for CI were sufficient. > > > > > > Glen > > > > > > > Yes and no, > > > > I can add something to poudriere for getting the tarballs from the CI > > artifacts but that won't be by default. > > > > To be honest, that would be the preferred route, since updating the > various *.txz distribution sets would break things like bootonly.iso, > mini-memstick.img, and so on. Why would it break things ? > In other words, we already have a system in place that generates these > archive files, so I personally see no need to disrupt the "official" > snapshot build process to appease a subset of the user base while > unnecessarily adding a pain point for the rest. > > Glen > If only the sets are generated each day I don't see how it can cause a pain to anyone. -- Emmanuel Vadot ___ 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: nightly snapshot for CURRENT ?
On Fri, 24 Jul 2020 22:06:07 + Glen Barber wrote: > On Fri, Jul 24, 2020 at 10:31:35PM +0200, Emmanuel Vadot wrote: > > On Tue, 9 Jun 2020 22:04:07 +0200 > > Emmanuel Vadot wrote: > > > > > On Tue, 9 Jun 2020 19:56:30 + > > > Glen Barber wrote: > > > > > > > On Tue, Jun 09, 2020 at 09:47:56PM +0200, Emmanuel Vadot wrote: > > > > > > > > > > Hello all, > > > > > > > > > > I've just hit again something that I've hit (and probably others too) > > > > > often. > > > > > If a change in base break some ports and it's snapshoted in the txz > > > > > available at download.freebsd.org, you need to wait a week for the > > > > > next > > > > > tarball to be available. > > > > > Since poudriere uses the tarball when you setup a jail it means that > > > > > the only solution you have is to recreate your jail by building it, > > > > > and > > > > > since building world nowdays is very expensive that delay your work > > > > > too > > > > > much. > > > > > Would it be possible to generate the tarballs every day instead of > > > > > every week ? At least for tier-1 arches. > > > > > > > > > > > > > Let's revisit this sometime next week after 11.4 is out. > > > > > > > > Glen > > > > > > > > > > Sure, works for me. > > > > > > Thanks, > > > > > > > Ping ? > > > > I thought the artifacts from the jenkins builder for CI were sufficient. > > Glen > Yes and no, I can add something to poudriere for getting the tarballs from the CI artifacts but that won't be by default. -- Emmanuel Vadot ___ 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: nightly snapshot for CURRENT ?
On Tue, 9 Jun 2020 22:04:07 +0200 Emmanuel Vadot wrote: > On Tue, 9 Jun 2020 19:56:30 + > Glen Barber wrote: > > > On Tue, Jun 09, 2020 at 09:47:56PM +0200, Emmanuel Vadot wrote: > > > > > > Hello all, > > > > > > I've just hit again something that I've hit (and probably others too) > > > often. > > > If a change in base break some ports and it's snapshoted in the txz > > > available at download.freebsd.org, you need to wait a week for the next > > > tarball to be available. > > > Since poudriere uses the tarball when you setup a jail it means that > > > the only solution you have is to recreate your jail by building it, and > > > since building world nowdays is very expensive that delay your work too > > > much. > > > Would it be possible to generate the tarballs every day instead of > > > every week ? At least for tier-1 arches. > > > > > > > Let's revisit this sometime next week after 11.4 is out. > > > > Glen > > > > Sure, works for me. > > Thanks, > Ping ? -- Emmanuel Vadot ___ 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: -CURRENT and drm-devel-kmod
On Fri, 10 Jul 2020 23:57:52 +0200 Andreas Nilsson wrote: > Hello, > > I've been running -CURRENT on my x1 yoga 1st gen for a long time, with > drm-current-kmod. As I understand it that port is no longer recommended and > one should run drm-devel-kmod . I don't think that somebody ever said that. For now use current if that works for you. > However, when I load i915kms from -devel > the console stops refreshing. It only refreshes when I switch > (Ctrl+alt+Fx). I see it refresh and display the new content just before > switching to the requested console. add hw.i915kms.enable_psr=0 to /boot/loader.conf This is a bug that none of my hardware have and I don't really know what's happening for now. > X behaves the same way. Has anyone experienced this? > > Best regards > Andreas > ___ > 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" -- Emmanuel Vadot ___ 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: DRM Project report (week of July 6th)
On Sat, 11 Jul 2020 00:41:53 +0300 Yuri Pankov wrote: > Emmanuel Vadot wrote: > [...] > > Hi Emmanuel, > > Sorry for somewhat hijacking the thread, but as you mentioned (IIRC) > testing the vmwgfx in one of the previous mails, I'd like to ask if any > work/fixes is done for that. Currently I don't have a VM with X11 > installed as all my attempts didn't succeed -- it's either a hard hang, > panic, or VM dying with exception, even with a workaround of 1 CPU > (core) provided in the Wiki. I can reinstall and provide panic info if > you are interested in looking into it. Hi, I haven't tested vmwgfx or vboxvideo yet, iirc someone told me that at least vboxvideo used to work, I have no idea if vmwgfx used to. If you have any panic please open an issue there : https://github.com/freebsd/drm-kmod/ To be honest with you intel and amd are my priorities and already occupy most of my time for testing. The plan that I have is to be sure to have for vboxvideo and vmwgfx when I reach 5.4 -- Emmanuel Vadot ___ 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"
DRM Project report (week of July 6th)
Hello, Last report was more than a month ago so a lot have happened. 5.3 is done and is in the ports tree since June 30th. This bring us support for NAVI10 card in the kernel, but if you have this card you will need mesa-devel port or wait that we update the mesa* port to 20.1 when they release. Speaking of mesa the first merge request for FreeBSD related patches was merged on July 4th (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3559), since reduce a lot the number of patches that we will need in the ports tree when 20.1 will be release. Other merge requests are still opened : https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests?scope=all=%E2%9C%93=opened=freebsd and after talking to upstream they would really like some FreeBSD support in their CI, the ideal would be to have a gitlab-runner somewhere but for now I've took the road of creating a CI compliant image that have sshd allowed without root password that will work with QEMU, see https://reviews.freebsd.org/D25598, we'll see how it goes but I hope that it will allow us to have more CI support in freedesktop projects (mesa, libdrm, xorg, wayland etc ...), don't forget that DRM drivers are a bit useless without proper support for FreeBSD on userland libs and program :) To have testing easier for me and others I've added into poudriere a mode to create a pkgbase image, this allow me to create small usb disk image that have all the necessary userland program for testing drm drivers. I've also started an image that will test various graphics related stuff like trying some drm driver sysctl tweaks etc ... all done with a dialog based program. The image is intended to be used to generate a wiki page that users could just upload and also quick testing FreeBSD on desktops/laptops. https://github.com/freebsd/poudriere/pull/756 I intend to publish scripts for creating the image at the end of next week and will possibly generate one image per week that people could download. Back on DRM I've started 5.4 update, for now it's ~20% done and I expect the sync to be finish at the end of July. https://github.com/freebsd/drm-kmod/tree/5.4 I don't think that I've forgotten something, if I did it will be included in next week reports :) All this work is under sponsorship from the FreeBSD Foundation. -- Emmanuel Vadot ___ 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: nightly snapshot for CURRENT ?
On Tue, 9 Jun 2020 19:56:27 -0500 Kyle Evans wrote: > On Tue, Jun 9, 2020 at 7:17 PM Clay Daniels wrote: > > > > On Tue, Jun 9, 2020 at 2:48 PM Emmanuel Vadot wrote: > > > > > > > > Hello all, > > > > > > I've just hit again something that I've hit (and probably others too) > > > often. > > > If a change in base break some ports and it's snapshoted in the txz > > > available at download.freebsd.org, you need to wait a week for the next > > > tarball to be available. > > > Since poudriere uses the tarball when you setup a jail it means that > > > the only solution you have is to recreate your jail by building it, and > > > since building world nowdays is very expensive that delay your work too > > > much. > > > Would it be possible to generate the tarballs every day instead of > > > every week ? At least for tier-1 arches. > > > > > > Cheers, > > > > > > -- > > > Emmanuel Vadot > > > ___ > > > > > > > At first I thought you were referring to the weekly snapshots packaged as > > install images: > > https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/ > > > > But I think you are talking about the snapshots of each part, like base, > > kernel, ports. src, etc to use as a roll your own install like: > > https://download.freebsd.org/ftp/snapshots/arm64/13.0-CURRENT/ > > > > Yes, these are the parts he's talking about. My initial impression is > that it'd be nice if we could (somehow) leverage Jenkins artifacts [0] > to get even more frequent updates if we really needed to without > significantly impacting re@ -- that's a little more difficult, though, > because build breakage makes it hard to predict what the latest > snapshot you can actually grab is, if any. Perhaps a script that > creates a symlink to the 'last known functional across the board' > revision periodically... > > [0] http://artifacts.ci.freebsd.org/snapshot/head/r361934/amd64/amd64/ I haven't thought about using those, I'll see if I can come up with a poudriere patch that could use this. Thanks for the idea :) > > From my selfish perspective as a weekly installer of the regular Thursday > > image or iso of 13.0 Current, I would hate to lose the pre-rolled > > installer, and I think there are probably others like me. As long as you > > keep the weekly install snapshots, it will not affect folks like me. I must > > say that what you want to do is how NetBSD does their daily cent > > snapshots, and they do not even offer pre-rolled install images. > > > > But you are a real developer and I'm just a retired guy playing with his > > hobby, so go ahead and do what you think is best for you. > > > > This was brought up in a public forum, you should probably feel free > to make non-obstructive comments like this to make sure a fairly > common need is represented. The (light-hearted?) self-deprecation near > the end of this makes me a bit uneasy- I certainly hope you didn't > feel like it was mandatory to acknowledge that he's a developer and > you're a hobbyist, because there's most assuredly more hobbyists (such > as myself) lurking with similar needs/desires. =-) > > 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" -- Emmanuel Vadot ___ 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: nightly snapshot for CURRENT ?
On Tue, 9 Jun 2020 19:16:47 -0500 Clay Daniels wrote: > On Tue, Jun 9, 2020 at 2:48 PM Emmanuel Vadot wrote: > > > > > Hello all, > > > > I've just hit again something that I've hit (and probably others too) > > often. > > If a change in base break some ports and it's snapshoted in the txz > > available at download.freebsd.org, you need to wait a week for the next > > tarball to be available. > > Since poudriere uses the tarball when you setup a jail it means that > > the only solution you have is to recreate your jail by building it, and > > since building world nowdays is very expensive that delay your work too > > much. > > Would it be possible to generate the tarballs every day instead of > > every week ? At least for tier-1 arches. > > > > Cheers, > > > > -- > > Emmanuel Vadot > > ___ > > > > At first I thought you were referring to the weekly snapshots packaged as > install images: > https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/ > > But I think you are talking about the snapshots of each part, like base, > kernel, ports. src, etc to use as a roll your own install like: > https://download.freebsd.org/ftp/snapshots/arm64/13.0-CURRENT/ Yup > From my selfish perspective as a weekly installer of the regular Thursday > image or iso of 13.0 Current, I would hate to lose the pre-rolled > installer, and I think there are probably others like me. As long as you > keep the weekly install snapshots, it will not affect folks like me. I must > say that what you want to do is how NetBSD does their daily current > snapshots, and they do not even offer pre-rolled install images. > > But you are a real developer and I'm just a retired guy playing with his > hobby, so go ahead and do what you think is best for you. > > Clay I'm not talking about loosing those weekly installer image, I just want more tarballs :) -- Emmanuel Vadot ___ 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: nightly snapshot for CURRENT ?
On Tue, 9 Jun 2020 19:56:30 + Glen Barber wrote: > On Tue, Jun 09, 2020 at 09:47:56PM +0200, Emmanuel Vadot wrote: > > > > Hello all, > > > > I've just hit again something that I've hit (and probably others too) > > often. > > If a change in base break some ports and it's snapshoted in the txz > > available at download.freebsd.org, you need to wait a week for the next > > tarball to be available. > > Since poudriere uses the tarball when you setup a jail it means that > > the only solution you have is to recreate your jail by building it, and > > since building world nowdays is very expensive that delay your work too > > much. > > Would it be possible to generate the tarballs every day instead of > > every week ? At least for tier-1 arches. > > > > Let's revisit this sometime next week after 11.4 is out. > > Glen > Sure, works for me. Thanks, -- Emmanuel Vadot ___ 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"
nightly snapshot for CURRENT ?
Hello all, I've just hit again something that I've hit (and probably others too) often. If a change in base break some ports and it's snapshoted in the txz available at download.freebsd.org, you need to wait a week for the next tarball to be available. Since poudriere uses the tarball when you setup a jail it means that the only solution you have is to recreate your jail by building it, and since building world nowdays is very expensive that delay your work too much. Would it be possible to generate the tarballs every day instead of every week ? At least for tier-1 arches. Cheers, -- Emmanuel Vadot ___ 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: Resume almost never works Dell XPS 9370
On Fri, 05 Jun 2020 14:58:37 +0200
Malcolm Matalka wrote:
>
> Emmanuel Vadot writes:
>
> > On Fri, 05 Jun 2020 10:41:48 +0200
> > Malcolm Matalka wrote:
> >
> >>
> >> Emmanuel Vadot writes:
> >>
> >> > On Fri, 05 Jun 2020 10:25:59 +0200
> >> > Malcolm Matalka wrote:
> >> >
> >> >>
> >> >> Hans Petter Selasky writes:
> >> >>
> >> >> > On 2020-06-05 06:56, Malcolm Matalka wrote:
> >> >> >> I'm using the i915kms driver and resuming from suspend almost never
> >> >> >> works. What I get is a blank screen with a rectangle cursor in the
> >> >> >> top
> >> >> >> right, like what the screen looks like for that split second when X11
> >> >> >> starts. It is then stuck and I have to force shutdown with the
> >> >> >> physical
> >> >> >> button.
> >> >> >>
> >> >> >> I am not sure but I feel like this happens more frequently after I've
> >> >> >> been running bhyve but I can't guarantee that's actually causally
> >> >> >> related.
> >> >> >>
> >> >> >> The only special thing I do that I'm aware of is I turn off my usb
> >> >> >> when
> >> >> >> I suspend and back on when I resume, I don't know if this is possibly
> >> >> >> related.
> >> >> >>
> >> >> >> usbconfig list | cut -f 1 -d ':' | xargs -n1 -I'{}' usbconfig '{}'
> >> >> >> power_save
> >> >> >>
> >> >> >> Any tips on what to do?
> >> >> >>
> >> >> >
> >> >> > Which version of kernel and kms driver are you using?
> >> >>
> >> >> I am on 361660 and drm-current-kmod-4.16.g20200320.
> >> >>
> >> >> This is not a new problem, by the way, I finally just rebooted again
> >> >> today and decided to ask.
> >> >
> >> > Resume could be due to TPM being active, try to disable it in the bios
> >> > you should have an option (set it to disable, not discrete).
> >> > If the problem is related to the drm driver (I doubt), you could
> >> > always try drm-devel-kmod.
> >>
> >> What makes you think TPM is related? Note that this does work
> >> sometimes, just hit or miss and mostly not.
> >
> > Because I got hit by this problem many times on most of my laptops.
>
> Looks like I had already disabled TPM. So sadly not the cause in my
> case.
What generation of intel is it ?
Please share pciconf -vl and dmesg
Also, can you ssh to the machine after it failed to resume or is it
really hanged ?
>
> >
> >> >
> >> >> >
> >> >> > --HPS
> >> >>
> >> ___
> >> 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"
--
Emmanuel Vadot
___
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: Resume almost never works Dell XPS 9370
On Fri, 05 Jun 2020 10:41:48 +0200
Malcolm Matalka wrote:
>
> Emmanuel Vadot writes:
>
> > On Fri, 05 Jun 2020 10:25:59 +0200
> > Malcolm Matalka wrote:
> >
> >>
> >> Hans Petter Selasky writes:
> >>
> >> > On 2020-06-05 06:56, Malcolm Matalka wrote:
> >> >> I'm using the i915kms driver and resuming from suspend almost never
> >> >> works. What I get is a blank screen with a rectangle cursor in the top
> >> >> right, like what the screen looks like for that split second when X11
> >> >> starts. It is then stuck and I have to force shutdown with the physical
> >> >> button.
> >> >>
> >> >> I am not sure but I feel like this happens more frequently after I've
> >> >> been running bhyve but I can't guarantee that's actually causally
> >> >> related.
> >> >>
> >> >> The only special thing I do that I'm aware of is I turn off my usb when
> >> >> I suspend and back on when I resume, I don't know if this is possibly
> >> >> related.
> >> >>
> >> >> usbconfig list | cut -f 1 -d ':' | xargs -n1 -I'{}' usbconfig '{}'
> >> >> power_save
> >> >>
> >> >> Any tips on what to do?
> >> >>
> >> >
> >> > Which version of kernel and kms driver are you using?
> >>
> >> I am on 361660 and drm-current-kmod-4.16.g20200320.
> >>
> >> This is not a new problem, by the way, I finally just rebooted again
> >> today and decided to ask.
> >
> > Resume could be due to TPM being active, try to disable it in the bios
> > you should have an option (set it to disable, not discrete).
> > If the problem is related to the drm driver (I doubt), you could
> > always try drm-devel-kmod.
>
> What makes you think TPM is related? Note that this does work
> sometimes, just hit or miss and mostly not.
Because I got hit by this problem many times on most of my laptops.
> >
> >> >
> >> > --HPS
> >>
> ___
> 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"
--
Emmanuel Vadot
___
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: Resume almost never works Dell XPS 9370
On Fri, 05 Jun 2020 10:25:59 +0200
Malcolm Matalka wrote:
>
> Hans Petter Selasky writes:
>
> > On 2020-06-05 06:56, Malcolm Matalka wrote:
> >> I'm using the i915kms driver and resuming from suspend almost never
> >> works. What I get is a blank screen with a rectangle cursor in the top
> >> right, like what the screen looks like for that split second when X11
> >> starts. It is then stuck and I have to force shutdown with the physical
> >> button.
> >>
> >> I am not sure but I feel like this happens more frequently after I've
> >> been running bhyve but I can't guarantee that's actually causally
> >> related.
> >>
> >> The only special thing I do that I'm aware of is I turn off my usb when
> >> I suspend and back on when I resume, I don't know if this is possibly
> >> related.
> >>
> >> usbconfig list | cut -f 1 -d ':' | xargs -n1 -I'{}' usbconfig '{}'
> >> power_save
> >>
> >> Any tips on what to do?
> >>
> >
> > Which version of kernel and kms driver are you using?
>
> I am on 361660 and drm-current-kmod-4.16.g20200320.
>
> This is not a new problem, by the way, I finally just rebooted again
> today and decided to ask.
Resume could be due to TPM being active, try to disable it in the bios
you should have an option (set it to disable, not discrete).
If the problem is related to the drm driver (I doubt), you could
always try drm-devel-kmod.
> >
> > --HPS
>
--
Emmanuel Vadot
___
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"
drm drivers project report (week of May 11th and May 18th)
Hello all, First of all sorry for forgetting to send a report last week. A lot happened in two weeks. We are now 98% synced with Linux 5.2 and I've taggued a release yesterday (https://github.com/freebsd/drm-kmod/releases/tag/drm_v5.2_8) and this is now in ports in graphics/drm-devel-kmod (https://svnweb.freebsd.org/ports?view=revision=536403). The 2% remaining is a small patch that uses the rcu in Linux and cause problem for us on FreeBSD. I'll send an email this week to hackers with more details as I've spent quite some time on it and don't really understand what's goind on. This ports should be fine to use for any users of Intel or AMD. If any users of the vboxvideo and vmwgfx see any problem please tell my and I'll fix any issue. For users of >Skylake Intel there is a known problem with laptop panel where the console doesn't refresh, this is due to a mechanism called PSR, Panel Self Refresh, where the driver shutdown the embedded display port link to save battery and the panel keeps a copy of framebuffer to display it. This is a known problem for any of our kmod >4.16. I mostly understand what's going on but will be able to fix it when I receive my > Skylake laptop (hopefully tomorow). If you have such issue setting hw.i915kms.enable_psr=0 in /boot/loader.conf (See below for the sysctl update). To have 5.2 correctly compiling and running a number of commits have been made to linuxkpi in base : https://svnweb.freebsd.org/changeset/base/361007 https://svnweb.freebsd.org/changeset/base/361245 https://svnweb.freebsd.org/changeset/base/361246 https://svnweb.freebsd.org/changeset/base/361247 https://svnweb.freebsd.org/changeset/base/361343 On the code side a new file kconfig.mk was added, it's used to "emulate" the kconfig option of the Linux kernel and allow us to define the needed options based on the architectures but also enabling/disabling some option based on make variable such as DRM_LEGACY (Linux have deprecated some drm interface and they are only compiled if DRM_LEGACY is in KConfig). We use to define the CONFIG_* in a header file but doing it this way allow us to compile or not some files based on the options. The main Makefile was also reworked to allow compiling only certain modules using the KMODS make variable, this is mostly useful for developement purpose (when bisecting a problem on a certain kmod for example) but could also be used as port options so people won't waste cycle compiling amdgpu+radeon+ttm modules when they only want the i915kms one. I'll add such options in the port during this week. The sysctls exposed by the drm drivers also have changed, due to how linuxkpi works every module parametters is translated to sysctls under compat.linuxkpi, I didn't liked that as a users doesn't need to know what linuxkpi is or that the drm drivers uses it. So I've added them under hw.. So if you used compat.linuxkpi.i915_something it's now also exposed as hw.i915kms.something. It's more logical, I think, to use hw. as this is where we put the sysctls/tunable for hardware related configuration. It also allow a users to sysctl -d hw. and see every configuration description without having to sysctl -a | grep . The old sysctls under compat.linuxkpi are still there so if you already rely on some configuration it will still work. On the 5.3 side, it's now synced at ~33%. 5.3 is a big release, more than 1500 patches for the differents DRM modules. You can track the progress here : https://github.com/freebsd/drm-kmod/tree/5.3 There is a known issue on intel (at least skylake), the commit have been identified and I'm working on fixing the issue. On amd side it's working well for me on my picasso laptop. Again a number of commits in base linuxkpi have been made : https://svnweb.freebsd.org/changeset/base/361138 https://svnweb.freebsd.org/changeset/base/361139 https://svnweb.freebsd.org/changeset/base/361140 https://svnweb.freebsd.org/changeset/base/361418 https://svnweb.freebsd.org/changeset/base/361419 I hope to finish 5.3 this week. Cheers, -- Emmanuel Vadot ___ 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"
drm drivers project report (week of May 4th)
Hello all, This is the first report for this project of updating our drm drivers as it started this week. I've started this week by cleaning our drm-v5.0 port comparing it with Linux as the less diff we have, the easiest it is to apply the patches from Linux. One commit was made to base linuxkpi so we have less patches in the DRM drivers themself : https://svnweb.freebsd.org/changeset/base/360787 Next part was trying to find what is the best way to update without too much hassle. I had some somewhat hacky scripts lying around for the drm on ARM project so I've made them a bit more generic and commited them here https://github.com/freebsd/drm-kmod/tree/master/scripts . This still isn't the best way I think. Due to how Linux is "constructed" patches can comes from differents branches and aren't necessary in the correct order. There is also some weird commits that appears in two releases of Linux, I think this is because they come late in a fixes merge and then the maintainer of one of the drm branches do stuff in the other branch for the next Linux release. If anyone have a lot of git skill I'm interested in how they would approch this problem. I also have to see if it would make more sense to track the differents commits in the merge branch from the drm repos (https://cgit.freedesktop.org/drm/) or not. After finding a almost good way to update I proceeded with updating to Linux 5.1 . This update was almost too easy, thanks to Austin Shafer who updated linuxkpi to include a few more helpers and functions needed by 5.1. There is no ports for now but if you want to test on your system you can checkout or download a tarball here : https://github.com/freebsd/drm-kmod/releases Only FreeBSD 13-CURRENT is supported. Also if you are using one of the drm-kmod ports be sure to delete /boot/kernel/drm.ko /boot/kernel/amdgpu.ko /boot/kernel/i915kms.ko /boot/kernel/linuxkpi_gplv2.ko /boot/kernel/radeon.ko As the drm-kmod ports install the sources in the system a kernel compilation will rebuild those modules and install them in /boot/kernel whereas using https://github.com/freebsd/drm-kmod/ will install everything in /boot/modules This branch was tested with : i915 on : - i7-5600U - HD Graphics 5500 (Broadwell) - i7-7500U - Skylake GT2 [HD Graphics 520] (Skylake) amdgpu on : - Ryzen 7 3700U (Picasso/Vega10) Except Skylake which doesn't have working vulkan (but doesn't have either with drm-v5.0) everything works great. I've started then the update to 5.2, it's still wip and only have i915 enabled as I haven't fixed everything for amdgpu/radeon or vmware/vbox but a wip branch is available there : https://github.com/freebsd/drm-kmod/tree/5.2-wip A few commits where made in base linuxkpi : https://svnweb.freebsd.org/changeset/base/360851 https://svnweb.freebsd.org/changeset/base/360870 https://svnweb.freebsd.org/changeset/base/360871 I don't suggest that you track this branch as I will fix the commits and force push on it, this is because I want to have every commit that is buildable for Linux, buildable for us, very conveniant for bisecting problems but I'd appreciate if people would test and report to me directly on replying to this thread. I have plan to create a usb/iso image that people could burn and tes but that will not be before a few weeks. This was tested on the same Intel systems as above with the addition of : i915 on : - Silver N5000 CPU (Thanks to Austin Shafer) - i7-6700K (Skylake) (Thanks to jbeich@) - i7-8665U (Whiskeylake) (Thanks to db@) The goal for next week is obviously to continue the update for 5.2 and updating to 5.3. The goal is to go as quickly as possible to 5.4 and stabilise there in a branch while going further on the master branch as 5.4 is a LTS branch in Linux and receive a lot of fix update. Regards, -- Emmanuel Vadot ___ 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: svn commit: r351858 - in head: bin/uuidgen ...
On Sat, 14 Sep 2019 19:41:06 +0200 mj-mailingl...@gmx.de wrote: > Building a jail from pkgbase packages after base r351858 shows this cap_mkdb > message: > > to create the jail this command is used: > > pkg --rootdir /jails/test01 -o 'ASSUME_ALWAYS_YES=true' -o > 'ABI=FreeBSD:13:amd64' install --repository FreeBSD-base FreeBSD-utilities > FreeBSD-rc > (note: FreeBSD-base is the repository name, not a package) > > ... > Checking integrity... done (0 conflicting) > [1/20] Installing FreeBSD-clibs-13.0.s20190914152450... > [1/20] Extracting FreeBSD-clibs-13.0.s20190914152450: .. done > [2/20] Installing FreeBSD-runtime-13.0.s20190914152450... > [2/20] Extracting FreeBSD-runtime-13.0.s20190914152450: .. done > cap_mkdb: file argument: No such file or directory > [3/20] Installing FreeBSD-utilities-13.0.s20190914152450... > [3/20] Extracting FreeBSD-utilities-13.0.s20190914152450: .. done > [4/20] Installing FreeBSD-rc-13.0.s20190914152450... > [4/20] Extracting FreeBSD-rc-13.0.s20190914152450: .. done > ... > > This happens, after the login.conf file was moved into the Freebsd-utilities > package. > The order in which the packages are installed is problematic, since cap_mkdb > is executed in step 2, the FreeBSD-runtime package installation, > but the login.conf file is installed in step 3, the FreeBSD-utilities. > > > I opened a bugreport: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240582 > > -- > Martin Hi, thanks for the report, it's now fixed in r352389. -- Emmanuel Vadot ___ 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: HEADSUP: drm-current-kmod now installs sources
On Wed, 14 Aug 2019 11:04:03 -0700 John Baldwin wrote: > On 8/14/19 10:23 AM, Emmanuel Vadot wrote: > > On Wed, 14 Aug 2019 10:13:48 -0700 > > John Baldwin wrote: > > > >> On 8/14/19 9:22 AM, Ian Lepore wrote: > >>> This all sounds vaguely wrong, backwards, to me. A developer who is > >>> using a given module on their build system might want that module to be > >>> rebuilt automatically, but only if the build parameters match those of > >>> the running build host system. > >>> > >>> If my build host is running freebsd 12 amd64 and I'm doing a build for > >>> freebsd 13 armv7, I have no interest in automatic rebuilds of an amd64 > >>> driver module for a different OS arch and version just because that > >>> module happens to be installed on the system I use to do crossbuilds. > >>> > >>> My objections are theoretical... this automation just seems improperly > >>> designed to me. But it won't actually affect me in any way, because I > >>> don't build video driver modules from ports, and I don't run freebsd > >>> current on my build host machine. Probably the number of people doing > >>> crossbuilding is small enough that nobody else is going to object to > >>> this "the whole world is amd64" automation. > >> > >> You assume DRM is amd64-only when it is definitely not. It also has > >> suitable guards in its Makefile to only build the relevant kernel > >> modules on supported architectures. > > > > I clearly don't want to spend time to build the drm and radeon modules > > when I'm hacking on arm64. > > Didn't you when DRM2 was in base? No, DRM2 was never connected for aarch64. > Do you use MODULES_OVERRIDE now to > limit the number of modules you are building? Most of the time yes, but if I don't set it, it shouldn't mean that I want to compile an out of tree module that I installed for another arch. > Setting LOCAL_MODULES would > be no different to setting MODULES_OVERRIDE. If you aren't setting > MODULES_OVERRIDE, then I don't buy your argument as the default set of > modules dwarfs DRM several times over. If nothing changes I will endup setting LOCAL_MODULES="" everytime but again this is not the problem, see above. > -- > John Baldwin > ___ > 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" -- Emmanuel Vadot ___ 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: HEADSUP: drm-current-kmod now installs sources
On Wed, 14 Aug 2019 19:55:02 +0200
Niclas Zeising wrote:
> On 2019-08-14 19:23, Emmanuel Vadot wrote:
> > On Wed, 14 Aug 2019 10:13:48 -0700
> > John Baldwin wrote:
> >
> >> On 8/14/19 9:22 AM, Ian Lepore wrote:
> >>> This all sounds vaguely wrong, backwards, to me. A developer who is
> >>> using a given module on their build system might want that module to be
> >>> rebuilt automatically, but only if the build parameters match those of
> >>> the running build host system.
> >>>
> >>> If my build host is running freebsd 12 amd64 and I'm doing a build for
> >>> freebsd 13 armv7, I have no interest in automatic rebuilds of an amd64
> >>> driver module for a different OS arch and version just because that
> >>> module happens to be installed on the system I use to do crossbuilds.
> >>>
> >>> My objections are theoretical... this automation just seems improperly
> >>> designed to me. But it won't actually affect me in any way, because I
> >>> don't build video driver modules from ports, and I don't run freebsd
> >>> current on my build host machine. Probably the number of people doing
> >>> crossbuilding is small enough that nobody else is going to object to
> >>> this "the whole world is amd64" automation.
> >>
> >> You assume DRM is amd64-only when it is definitely not. It also has
> >> suitable guards in its Makefile to only build the relevant kernel
> >> modules on supported architectures.
> >
> > I clearly don't want to spend time to build the drm and radeon modules
> > when I'm hacking on arm64.
> > Shouldn't LOCAL_MODULE have ${TARGET}.${TARGET_ARCH} as a
> > subdirectory ? So when you install drm-kmod-* it will only install the
> > source in /usr/local/modules/${TARGET}.${TARGET_ARCH}/ ? (or whatever
> > the correct dir is).
> >
>
> I'm not sure what you're trying to accomplish. I might be
> misunderstanding completely, but, at least the drm ports have safeguards
> in their makefiles so they'll only be built for those arches where there
> is support, and only the modules needed, as an example, i915kms.ko will
> only be built on amd64 and i386, if that's what you're worried about.
> Regards
> --
> Niclas Zeising
Greg.V is making radeon/amdgpu building on aarch64. So when the
ports will have support for it if I don't set some env variable I will
spend some time building drm + amdgpu when I buildkernel on my amd64
13-CURRENT machine for aarch64. This is not something that I want to do.
So what I said was that if I install drm-kmod-* on an amd64 machine
this should only trigger a build of the module when I'm building an
amd64 kernel, hence my proposal to only install sources in a ${TARGET}.$
{TARGET_ARCH} subdir.
--
Emmanuel Vadot
___
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: HEADSUP: drm-current-kmod now installs sources
On Wed, 14 Aug 2019 10:13:48 -0700
John Baldwin wrote:
> On 8/14/19 9:22 AM, Ian Lepore wrote:
> > This all sounds vaguely wrong, backwards, to me. A developer who is
> > using a given module on their build system might want that module to be
> > rebuilt automatically, but only if the build parameters match those of
> > the running build host system.
> >
> > If my build host is running freebsd 12 amd64 and I'm doing a build for
> > freebsd 13 armv7, I have no interest in automatic rebuilds of an amd64
> > driver module for a different OS arch and version just because that
> > module happens to be installed on the system I use to do crossbuilds.
> >
> > My objections are theoretical... this automation just seems improperly
> > designed to me. But it won't actually affect me in any way, because I
> > don't build video driver modules from ports, and I don't run freebsd
> > current on my build host machine. Probably the number of people doing
> > crossbuilding is small enough that nobody else is going to object to
> > this "the whole world is amd64" automation.
>
> You assume DRM is amd64-only when it is definitely not. It also has
> suitable guards in its Makefile to only build the relevant kernel
> modules on supported architectures.
I clearly don't want to spend time to build the drm and radeon modules
when I'm hacking on arm64.
Shouldn't LOCAL_MODULE have ${TARGET}.${TARGET_ARCH} as a
subdirectory ? So when you install drm-kmod-* it will only install the
source in /usr/local/modules/${TARGET}.${TARGET_ARCH}/ ? (or whatever
the correct dir is).
--
Emmanuel Vadot
___
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: CFT: FreeBSD Package Base
On Mon, 29 Apr 2019 10:05:59 -0400 Kris Moore wrote: > On Mon, Apr 29, 2019 at 9:55 AM Emmanuel Vadot > wrote: > > > On Mon, 29 Apr 2019 09:25:05 -0400 > > Kris Moore wrote: > > > > > On Mon, Apr 29, 2019 at 8:12 AM Emmanuel Vadot > > > wrote: > > > > > > > > > > > Hi Kris, > > > > > > > > On Sun, 28 Apr 2019 15:52:21 -0400 > > > > wrote: > > > > > > > > > FreeBSD Community, > > > > > > > > > > > > > > > > > > > > I'm pleased to announce a CFT for builds of FreeBSD 12-stable and > > > > 13-current > > > > > using "TrueOS-inspired" packaged base. These are stock FreeBSD images > > > > which > > > > > will allow users to perform all updating via the 'pkg' command > > directly. > > > > > Rather than trying to answer all questions in this announcement, > > we've > > > > > created a FAQ page with more details. Please refer to this page, and > > let > > > > us > > > > > know if you have additional questions that we can include on that > > page > > > > going > > > > > forward. > > > > > > > > > > > > > While I appreciate the effort I have some doubt about your > > > > "re-implementation" of pkgbase. I don't see any improvement compared to > > > > what is in base currently, I even see downside of your implementation. > > > > > > > > - How do you plan with the need of updating kernel first, reboot and > > > > updating the rest of the userland after ? (Needed for major and minor > > > > upgrade, 12.0 to 12.1 for example, and simple update in -STABLE and > > > > -HEAD branch). This is still a problem with the base pkgbase. > > > > > > > > > > We've written our own tool "sysutils/sysup" in GO which handles this. It > > > performs updates using Boot-Environments to ensure that kernel/world are > > > updated at same time. > > > > > > > Which could never be imported into FreeBSD. > > > > Not suggesting it should be. Just information on how we solved that problem > in our own appliance / platforms. For FreeBSD it would need some tooling > still to handle this style of updating, regardless of which pkg base is > used. > > And for what it's worth, FreeBSD is all the poorer for not being able to > bring modern language based tools into the base. Personally I'm hoping the > shift to base-packages makes this a moot point since the idea of 'what is > base' can be diluted to just a manifest of what gets installed out of box. > Just my 2C on the matter though :) > > > > > > > > > > > > > > - This is even worse because you are using the same repository for > > > > base and pkg so if a user pkg update and both kernel and pkg(8) needs > > > > to be updated and pkg use a new syscall or capsicum thing it will be > > > > updated first and couldn't proceed with the rest of the update (this is > > > > a supposition, I haven't personally tested). > > > > > > > > > > See above. > > > > You can selectively update os/kernel and reboot before doing rest. > > > > > > > > > > > > - It seems that multiple kernels isn't supported in your > > > > implementation, this is already supported in pkgbase but still need > > > > some love. This is an important point as it will allow user to choose > > > > easily the kernel that they want to use and will also allow us > > > > developper to push kernels with new features to help testing. > > > > > > > > > > Incorrect, on the 13-CURRENT build if you install kernel-debug, you'll > > get > > > the Witness-enabled kernel installed alongside non-debugging one. > > > > Mhm no, the kernel-debug packages only add the debug file > > in /usr/lib/debug/boot/ > > I'm talking about installing multiple kernels in // > > (i.e. /boot/kernel.GENERIC /boot/kernel.MYFEATUREIWANTTOTEST) like > > describe here : > > > > https://wiki.freebsd.org/PkgBase#Project_goals_and_additional_unresolved_issues > > in the "How to handle /boot/kernel and /boot/kernel.$KERNCONF" point. > > > > > Incorrect, os/kernel-debug installs /boot/kernel-debug which is (on > 13-CURRENT) the Witness enabled kernel. os/kernel-debug-symbols are the > /usr/lib/debug bits. I only
Re: CFT: FreeBSD Package Base
On Mon, 29 Apr 2019 09:25:05 -0400 Kris Moore wrote: > On Mon, Apr 29, 2019 at 8:12 AM Emmanuel Vadot > wrote: > > > > > Hi Kris, > > > > On Sun, 28 Apr 2019 15:52:21 -0400 > > wrote: > > > > > FreeBSD Community, > > > > > > > > > > > > I'm pleased to announce a CFT for builds of FreeBSD 12-stable and > > 13-current > > > using "TrueOS-inspired" packaged base. These are stock FreeBSD images > > which > > > will allow users to perform all updating via the 'pkg' command directly. > > > Rather than trying to answer all questions in this announcement, we've > > > created a FAQ page with more details. Please refer to this page, and let > > us > > > know if you have additional questions that we can include on that page > > going > > > forward. > > > > > > > While I appreciate the effort I have some doubt about your > > "re-implementation" of pkgbase. I don't see any improvement compared to > > what is in base currently, I even see downside of your implementation. > > > > - How do you plan with the need of updating kernel first, reboot and > > updating the rest of the userland after ? (Needed for major and minor > > upgrade, 12.0 to 12.1 for example, and simple update in -STABLE and > > -HEAD branch). This is still a problem with the base pkgbase. > > > > We've written our own tool "sysutils/sysup" in GO which handles this. It > performs updates using Boot-Environments to ensure that kernel/world are > updated at same time. > Which could never be imported into FreeBSD. > > > > - This is even worse because you are using the same repository for > > base and pkg so if a user pkg update and both kernel and pkg(8) needs > > to be updated and pkg use a new syscall or capsicum thing it will be > > updated first and couldn't proceed with the rest of the update (this is > > a supposition, I haven't personally tested). > > > > See above. > > > > - It seems that multiple kernels isn't supported in your > > implementation, this is already supported in pkgbase but still need > > some love. This is an important point as it will allow user to choose > > easily the kernel that they want to use and will also allow us > > developper to push kernels with new features to help testing. > > > > Incorrect, on the 13-CURRENT build if you install kernel-debug, you'll get > the Witness-enabled kernel installed alongside non-debugging one. Mhm no, the kernel-debug packages only add the debug file in /usr/lib/debug/boot/ I'm talking about installing multiple kernels in // (i.e. /boot/kernel.GENERIC /boot/kernel.MYFEATUREIWANTTOTEST) like describe here : https://wiki.freebsd.org/PkgBase#Project_goals_and_additional_unresolved_issues in the "How to handle /boot/kernel and /boot/kernel.$KERNCONF" point. > > > - Since you reduced the granularity on the userland bits it would mean > > that if we use your implementation for -p updates we would download the > > whole userland packages instead of just updating the package that was > > patched. For example with pkgbase, updating from 12.0 to 12.0p1 will > > only update the FreeBSD-runtime package. Yes this package is still big > > to download when you compare to what have changed but until pkg(8) have > > delta pkg supports (and if it will have support, I don't know if > > this is a wish or not) this is the best way to go. > > > > Correct, this is by design. We used the in-tree pkg base for nearly a year, > and found that the granularity didn't really offer any savings from a > download or time perspective. Updating 100+ packages took far longer than a > single one, due to all the meta operations. Additionally in real-world > usage, we found that base packages tended to all get updated at the same > time, which took far longer via pkg, since it had to go and perform 100+ > fetch operations just to download the base system bits. > But you never need to update 100+ packages on a proper pkgbase setup for -p updates. Again on a 12.0 to 12.0-p1 update only one package will be updated. > > > - I see that you are sorting the plist for kernel and userland based > > on the line length [1], why is that ? > > > Whoops! I'll fix :) > > > > > > I think that the only advantage that your solution offers is that if > > we remove a componant of base (rcmds for example in 12-CURRENT) those > > files would be removed as they are in the userland-base package while > > for pkgbase the FreeBSD-rcmd package will be deleted in the repo and > > will not
Re: CFT: FreeBSD Package Base
Hi Kris, On Sun, 28 Apr 2019 15:52:21 -0400 wrote: > FreeBSD Community, > > > > I'm pleased to announce a CFT for builds of FreeBSD 12-stable and 13-current > using "TrueOS-inspired" packaged base. These are stock FreeBSD images which > will allow users to perform all updating via the 'pkg' command directly. > Rather than trying to answer all questions in this announcement, we've > created a FAQ page with more details. Please refer to this page, and let us > know if you have additional questions that we can include on that page going > forward. > While I appreciate the effort I have some doubt about your "re-implementation" of pkgbase. I don't see any improvement compared to what is in base currently, I even see downside of your implementation. - How do you plan with the need of updating kernel first, reboot and updating the rest of the userland after ? (Needed for major and minor upgrade, 12.0 to 12.1 for example, and simple update in -STABLE and -HEAD branch). This is still a problem with the base pkgbase. - This is even worse because you are using the same repository for base and pkg so if a user pkg update and both kernel and pkg(8) needs to be updated and pkg use a new syscall or capsicum thing it will be updated first and couldn't proceed with the rest of the update (this is a supposition, I haven't personally tested). - It seems that multiple kernels isn't supported in your implementation, this is already supported in pkgbase but still need some love. This is an important point as it will allow user to choose easily the kernel that they want to use and will also allow us developper to push kernels with new features to help testing. - Since you reduced the granularity on the userland bits it would mean that if we use your implementation for -p updates we would download the whole userland packages instead of just updating the package that was patched. For example with pkgbase, updating from 12.0 to 12.0p1 will only update the FreeBSD-runtime package. Yes this package is still big to download when you compare to what have changed but until pkg(8) have delta pkg supports (and if it will have support, I don't know if this is a wish or not) this is the best way to go. - I see that you are sorting the plist for kernel and userland based on the line length [1], why is that ? I think that the only advantage that your solution offers is that if we remove a componant of base (rcmds for example in 12-CURRENT) those files would be removed as they are in the userland-base package while for pkgbase the FreeBSD-rcmd package will be deleted in the repo and will not be deleted in the user computer. > > Additionally, I will be hosting a Package Base working group at BSDCan 2019, > and welcome user and developer attendance to discuss this and other ongoing > package work: > > > > https://wiki.freebsd.org/DevSummit/201905/PackageBase > I will be present and looking forward to work with you on this. Cheers, P.S. : FYI I'm working on pkgbase currently and I will have some patches to commit soon (bsdinstall support, memstick creation that install a pkgbase aware installaton etc ...). [1] : https://github.com/trueos/trueos-ports/blob/trueos-master/os/userland-base/Makefile#L35 -- Emmanuel Vadot ___ 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: Switching fb backend back to default
On Sun, 17 Mar 2019 16:32:43 + Johannes Lundberg wrote: > > On 3/17/19 3:34 PM, Greg V wrote: > > > > > > On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg > > wrote: > >> Hi > >> > >> I'm working on making i915kms unload properly. I've come to what I think > >> is the last issue. The drm driver unloads ok, the "efifb" backend is > >> restored (according to logs) and vt_efifb_init() is being called but the > >> screen (laptop built in display) stays black. The system seems > >> operational otherwise. If I load i915kms again in this state I get back > >> a visible (i915kms) framebuffer. > >> > >> Did we ever have this working so it's known to work? > > > > Recently on the linux kernel mailing list: > > > > http://lkml.iu.edu/hypermail/linux/kernel/1903.1/01162.html > > > > > Of course, once native drivers like i915 or radeon take over, such a > > framebuffer is toast... [6] > > > > > [6] linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb() > > > linux/drivers/gpu/drm/radeon/radeon_drv.c::radeon_pci_probe() > > > > So it seems like efifb is not supposed to work after a driver has been > > loaded at least once. > > > > > Hmm, well the code is there to handle switching back to the boot time > fb. What I think is happening is that i915 powers off the displays at > unload and vt doesn't know how to power on (or that it should). > That and if the display pipeline is de-configured or the resolution changed you cannot reset it to the original state. Unloading drm modules is only useful for testing (and finding leaks). > > ___ > 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" -- Emmanuel Vadot ___ 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: What is evdev and autoloading?
e working on drm for arm/arm64 and we hope to have something commitable soon, we need the same thing for i386 (and probably other arches). > This is not some leap forward for anyone, and defanitly a slight > step backwards for some, many, who knows, I put it in the 1000's, > of users. Again wrong, this is a big leap forward for 99% of the users. > We have never been very good at having kmod's > work well over a long period, we break them left and right, and > we got away with it in virtualbox, but you start doing that to > the graphics driver and you are going to driver users away as > they simply can not have there desktop go non-functional for > even hours, let alone days. > > -- > Rod Grimes rgri...@freebsd.org > ___ > freebsd-hack...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" Cheers, -- Emmanuel Vadot ___ 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: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Fri, 18 Jan 2019 22:50:31 +0300 Lev Serebryakov wrote: > On 18.01.2019 22:35, Rodney W. Grimes wrote: > > >>> errm.. you press a key and enter device and or loader path. if it is not > >>> working - the code is there to be fixed. > >> And loader looks to "bootme" attribute and try to boot from partition > >> which has one, even if it is loaded from other partition itself. > >> > >>> GPT does not have the concept of active partition. > >> It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't have > >> any tools to set these attributes, AFAIK. Same for UEFI boot code. > > > > The gpart(8) command is used to set/unset these. > gpart need booted system. NanoBSD typically have two "system" > partitions, "old" (previous) and "new" (current). After upgrade they > switched (new code is written to "previos" partition and bootable > atteibute is set to it, "active" in case of MBR and "bootme" in case of > GPT). > > If this new partition has problems and could not be booted, it is hard > to boot from "old" (previous) one. MBR + boot0 could (interactively) > change active partition before system is booted, and this problem could > be solved with one keypress: you select old partition on boot. > > -- > // Lev Serebryakov > With UEFI Boot* variable you could do : - Update previous partition and set BootNext to it - If it fail next boot will be on current partition due to BootOrder - If it succeed, change the BootOrder to have the new partition first. -- Emmanuel Vadot ___ 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: Fujitsu Lifebook E751 (iGPU: HM65): distorted console with UEFI boot
Hi, On Wed, 28 Nov 2018 10:51:11 +0100 "O. Hartmann" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > I ran into some trouble booting off a Fujitsu Lifebook E751 (firmware is > latest, r1.22 > from 2013). The E751 is of model series S26391-K326-V100 and equipted with a > Core > i5-2520M CPU and supposed to be also equipted with a iGPU HM65 according to > the > techniscal specifications from Fujitsu. > > Trying to boot off 12-PRERELEASE/12-RC2 and/or 13-CURRENT (most recent I > could grap from > the download page), the screen becomes distorted immediately after the kernel > has > loaded and initialised/booted. The screen is at the loader's all right so far. > > Trying to disable graphics mode via escaping to the loader's prompt and > setting > > set hw.vga.textmode=1 > > subsequently loading the kernel and then booting, doesn't help. The screen is > distorted > again. The notebook seems UEFI only and doesn't boot off from MBR partioned > devices (i.e. > NanoBSD I used to use). > > Loading /boot/kernel/i915kms.ko > > after manually having loaded /boot/kernel/kernel (and not booted yet) doesn't > change > anything either. > > Booting off and installing Linux (Ubuntu, Mint so far, most revent verions I > can get my > hands on) is no problem. The console works fine from the beginning and so the > graphics. > > Is there a chance to get a FreeBSD booting the easy way? > > The provided boot images do not contain any of the > graphics/drm-stable|next|legacy-kmod > stuff, I tried to load i915kms.ko off from /boot/modules/ (were those modules > from the > ports are supposed to reside) but no chance. > > Before starting investigating this issue further I'd like to ask wether there > is a > general support provided or is that type of notebook dead matter for FreeBSD > of the > modern kind? > > Thanks in advance, > > oh > > p.s. please CC me, I'm not subscribing all lists. > > - -- > O. Hartmann > -BEGIN PGP SIGNATURE- > > iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW/5lKgAKCRDS528fyFhY > lMhRAf4yv4MqmHYVZIKo+TE1VACuHpXSv8ad4JzVKMG/S9uGcLLDfLgSM9699FDP > /QhIMCCHJ1hGAtXACdwGCsyZ5LmiAf93JHFU0W+GJWdXJI+sRcWvEZrzQlb5Czhf > vaM5QZ+3n0ermbe5/Ibvo/yzhL5YyonG7/lEqvnf7GAA+snv+Dvg > =XD7b > -END PGP SIGNATURE- Could you post a picture somewhere ? I have a laptop which have efifb problem, what I need to do is (at loader prompt) : gop set 4 (to switch to a different mode) gop set 0 (switch to the correct mode) You can gop list (iirc) to checks the available mode. The problem is that we are mixing serial and gop in loader.efi and when you set one mode in serial (or for SIMPLE_TEXT_PROTOCOL) is can mess the graphical mode. -- Emmanuel Vadot ___ 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: axp288 on Intel HW
Hi, Allwinner PMIC on X86, interesting :) On Fri, 16 Nov 2018 08:51:31 + Johannes Lundberg wrote: > Hi > > I have a Lenovo Ideapad Miix 310 that has a Intel CherryTrail CPU and it > runs FreeBSD quite nicely (with accelerated graphics). What I'm missing is > battery life status.. > > I can get this information using smb (for some reason i2c just returns > error sending start condition) > smbmsg -f /dev/smb6 -s 0x68 -c 0xB9 -i 1 -F %d > > In emergency this works but it would be nice to have a kernel driver for > it. > > I found the axp2xx driver for Allwinner in the tree. Would it be possible > to share this with amd64 with not too much effort? The first step would be to add acpi attach functions (no idea how this works), then compare the registers with the pmics supported by the axp2xx driver to check what regulators are present and controllable (if any) and also checking the registers for talking to the battery controller part. I don't see why it wouldn't work but I haven't checked details on how supported chips differs with this one. > > If not, all I'm really interested in is battery status so I might just hack > together a simple driver for that report values to hw.acpi.battery (because > I don't think there is a sysctl for battery info that aggregates different > sources?) We don't have a generic battery/power supply framework yes. > > Datasheet for the pmic can be found here > http://download.bbs.ickey.cn/201707/cfe88ee7ef01eed7a4586ce340165da0.pdf > > Cheers > ___ > 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" -- Emmanuel Vadot ___ 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: Sound issues with Dell Latitude 7490 (kabylake)
On Tue, 2 Oct 2018 14:29:39 -0500 Eric van Gyzen wrote: > >>> Thanks. So if you try this: > >>> > >>> sysctl dev.hdaa.0.nid24_config="as=4 seq=15" > >>> sysctl dev.hdaa.0.nid21_config="as=1 seq=15" > >>> sysctl dev.hdaa.0.reconfig=1 > >> > >> Works, thank you! > > > > Dude that's some serious shit ! > > Jacob, is this documented somewhere ? > > I haven't read the driver code but what does as/seq etc represent > > there ? > > snd_hda(4) is very helpful. Indeed it is but I'm not sure that everyone (me included) can produce what Jacob did to have headphone re-routed and muting the other outputs just by reading the manual. > > > What could we do to make this > > easier for users ? > > We can commit similar changes to the kernel driver. kstaring on github > has ported many such changes from Linux to FreeBSD: > > https://github.com/freebsd/freebsd/pull/139 > https://github.com/freebsd/freebsd/pull/144 > > I don't know if his port includes the changes Rod needs. > > I was planning to commit these when life calms down enough to test them. > If anyone beats me to it, I would be delighted. I was also waiting > until after 12.0, but in hindsight, I wish I had just committed them. Please do as soon as 13-CURRENT branches and let people test/complain :) > > Eric > ___ > 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" -- Emmanuel Vadot ___ 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: Sound issues with Dell Latitude 7490 (kabylake)
On Tue, 2 Oct 2018 12:03:50 -0700 (PDT) "Rodney W. Grimes" wrote: > > On 10/2/18 6:27 PM, Rodney W. Grimes wrote: > > >> On 10/1/18 6:43 PM, Rodney W. Grimes wrote: > > >>>> Hi > > >>>> > > >>>> While sound work out of the box (with headphone switching) on the 1-2 > > >>>> year > > >>>> older Latitude 7270, it does not on my new machine. > > >>>> > > >>>> The internal speaker works fine. If I plug in external speakers in the > > >>>> headphone jack, sound still goes to the internal speaker while a very > > >>>> load > > >>>> buzz comes from the external speakers. > > >>>> > > >>>> Do we have a solution for this? > > >>> I do not believe we have anything that detects stuff plugged into > > >>> and removed from the newer sound stuff that needs switching to > > >>> change from internal to external speakers. > > >>> > > >>> I think you need to do what I have to do when I plug in external > > >>> speakers on my thinkpad x230: > > >>> sysctl hw.snd.default_unit=1 > > >>> > > >>> And when I unplug them I have to do: > > >>> sysctl hw.snd.default_unit=0 > > >>> > > >>> to switch back to the internal speakers. > > >> > > >> Hi Rod, > > >> > > >> > > >> Can you post the output of 'sysctl dev.pcm' and 'sysctl dev.hdaa' > > > Sure: > > > @x230a:~ # sysctl dev.pcm > > > dev.pcm.4.bitperfect: 0 > ... > ... > > > > Thanks. So if you try this: > > > > sysctl dev.hdaa.0.nid24_config="as=4 seq=15" > > sysctl dev.hdaa.0.nid21_config="as=1 seq=15" > > sysctl dev.hdaa.0.reconfig=1 > > Works, thank you! Dude that's some serious shit ! Jacob, is this documented somewhere ? I haven't read the driver code but what does as/seq etc represent there ? What could we do to make this easier for users ? > > That should make pcm0 and pcm1 "merge" into pcm0 and enable > > auto-switching when plugging something > > > > in the headphones jack. > > > > If it works you might want to put the following two lines in > > /boot/loader.conf > > > > hint.hdaa.0.nid24.config="as=4 seq=15" > > hint.hdaa.0.nid21.config="as=1 seq=15" > > > -- > Rod Grimes rgri...@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" -- Emmanuel Vadot ___ 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: devmatch sideeffec: No sound
On Sun, 30 Sep 2018 07:51:38 + Poul-Henning Kamp wrote: > HW: Thinkpad T480 with T3 Dock. > > SW: -current, r338952 > > With devmatch enabled in /etc/rc.conf (the default0, snd_uaudio > gets loaded automatically and finds the audio stuff in the dock, > which is connected to a screen output(s) I do not use. > > Firefox ends up with /dev/dsp2.0 which goes there, and as a result > I get no sound through the laptops speakers where I expect it. > > Obvious workaround: Disable devmatch. Warner talked about adding blacklist to devmatch > Yet to be discovered workaround: Prioritize sound devices, when > there are multiple. hw.snd.default_unit=XXX hw.snd.default_auto=0 in /etc/sysctl.conf should do the trick. > This kind of thing may cause some support-work when 12 comes out... The only new "issue" is that now with devmatch every hardware got its driver loaded, so on this case this would cause "problems" but for other it solve the problem of finding which driver you need to load to use your usb/pci/blah driver. > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > ___ > 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" -- Emmanuel Vadot ___ 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: ALPHA3 niggles
On Tue, 28 Aug 2018 22:10:18 +1000 Brian Scott wrote: > Hi, > > Just a couple of small observations with 12.0-ALPHA3 from testing on a > Raspberry-Pi 3: > > * The boot loader (I presume the new LUA based one) is sending escape > sequences to the screen to format up a boot menu. The screen doesn't > recognise them and shows a series of ^[ style sequences instead. If it's stuff like that : https://people.freebsd.org/~manu/RPI2-HDMI.jpg it's known, we should remove the beastie menu from the image I think > * The timeout countdown of the boot loader has reverted to very slow. > The loader did this earlier in the year on -CURRENT but had obviously > been fixed for a few months now. Maybe some change needs to be adapted > from the old to the new loader. I don't have this problem on my RPI3B+ with latest ALPHA snapshot. The patch is still in the u-boot-rpi3 port (https://svnweb.freebsd.org/ports/head/sysutils/u-boot-rpi3/files/patch-lib_efi__loader_efi__console.c?revision=468630=markup) so I don't know what going on for you. > * The root user on the image doesn't have a .login file. The users are added with pw directly (iirc) and the /etc/skel content isn't copied in their home directory, that's something we should change for 13 and mfc back for 12.1 > I realise these are all cosmetic issues in the overall scheme of things > but if anyone is working on a bit of spit-and-polish for the new release > they might want to have a look at a few of these. > > Otherwise I'm happy to say that I haven't found any significant problems > yet. I'll keep looking though. > > Keep up the good work, > > Brian > > ___ > 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" -- Emmanuel Vadot ___ 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: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Sat, 04 Aug 2018 09:47:11 -0600 Ian Lepore wrote: > On Sat, 2018-08-04 at 18:43 +0300, Konstantin Belousov wrote: > > On Sat, Aug 04, 2018 at 09:25:47AM -0600, Ian Lepore wrote: > > > > > > On Sat, 2018-08-04 at 18:22 +0300, Konstantin Belousov wrote: > > > > > > > > On Sat, Aug 04, 2018 at 09:58:43AM -0500, Kyle Evans wrote: > > > > > > > > > > > > > > > On Sat, Aug 4, 2018 at 9:51 AM, Ian Lepore wrote: > > > > > > > > > > > > > > > > > > > [...] > > > > > > What do we do on 32-bit arm that has no dmap but may have efi > > > > > > runtime > > > > > > support? > > > > > > > > > > > This should probably just be compiled out for !arm64 && !x86 - its > > > > > sole purpose was to compensate for outdated loader.efi that hasn't > > > > > done the SetVirtualAddressMap. EFI on 32-bit ARM is "new" enough > > > > > that > > > > > it shouldn't have this problem. > > > > Does EFI on 32bit arm have RT support ? > > > I suspect the uboot implementation doesn't, but I can't think of any > > > reason why other implementations are not possible/available. In > > > particular, even 32bit arm supports virtualization and such an > > > environment could provide rt support. > > No, I mean, does our kernel has RT support on armv7 ? I only implemented > > necessary VM tricks for amd64, then it was ported to arm64, and in both > > cases it relies on 64bit address space and specific location of the KVA. > > I didn't realize the kernel implementation was arch-specific. So I > guess this comes under the category of "we'll solve that problem when > something comes along that provides efi rt for arm32." U-Boot doesn't provide a runtime service, I never tested the available port of EDK2 for BBB or RPI, I guess they boot the kernel in HYP/non-secure mode and install an runtime in secure world along with some psci firmware. -- Emmanuel Vadot ___ 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: Booting arm64 uefi broken
On Sat, 28 Jul 2018 13:27:08 -0600 Warner Losh wrote: > Let me know the rev... all my fixes are in the tree... > > Warner Fixed by r336837 Thanks, > On Sat, Jul 28, 2018, 12:52 PM Emmanuel Vadot wrote: > > > On Sat, 28 Jul 2018 20:34:31 +0200 > > Emmanuel Vadot wrote: > > > > > On Sat, 28 Jul 2018 20:28:30 +0200 > > > Emmanuel Vadot wrote: > > > > > > > On Sat, 28 Jul 2018 13:17:45 -0400 > > > > Shawn Webb wrote: > > > > > > > > > It appears with the latest 12-CURRENT/arm64, booting is broken. The > > > > > boot process gets stuck after the "Using DTB provided by..." message. > > > > > > > > > > This is on my SoftIron OverDrive 1000: > > > > > > > > > > >> FreeBSD EFI boot block > > > > > > >Loader path: /boot/loader.efi > > > > > > > > > > > > > >Initializing modules: ZFS UFS > > > > > > >Load Path: \EFI\BOOT\BOOTAA64.EFI > > > > > > >Load Device: > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(1,GPT,73365FD5-9260-11E8-9F00-0026B93F5298,0x3,0x640) > > > > >BootCurrent: 0002 > > > > > > >BootOrder: 0001 0005 0006 0002[*] > > > > > > >Probing 7 block devices..+..* done > > > > > > > ZFS found the following pools: rpool > > > > > > > UFS found 1 partition > > > > > > > Consoles: EFI console > > > > > > > FreeBSD/arm64 EFI loader, Revision 1.1 > > > > > > > (Sat Jul 28 11:32:06 UTC 2018 r...@nyi-01.build.hardenedbsd.org) > > > > > > > > > > > > > >Command line arguments: loader.efi > > > > > > >EFI version: 2.60 > > > > > > >EFI Firmware: SoftIron Overdrive 1000 (rev 1.00) > > > > > > >Console: efi (0) > > > > > > >Load Path: > > HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > > >Load Device: > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > > >BootCurrent: 0002 > > > > > > >BootOrder: 0001 0005 0006 0002[*] > > > > > > >BootInfo Path: > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0) > > > > > Ignoring Boot0002: Only one DP found > > > > > > > Trying ESP: > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > > > Setting currdev to disk1p2: > > > > > > > Loading /boot/defaults/loader.conf > > > > > > > /boot/kernel/kernel text=0x8a7169 data=0x1384d0+0x7d39fc > > syms=[0x8+0x11d108+0x8+0x10e646] > > > > > /boot/entropy size=0x1000 > > > > > > > efi-autoresizecons: Neither Graphics Output Protocol nor Universal > > Graphics Adapter present > > > > > > > > > > > > Hit [Enter] to boot immediately, or any other key for command > > prompt. > > > > > Booting [/boot/kernel/kernel]... > > > > > > > Using DTB provided by EFI at 0x801fe0. > > > > > > > > > > Thanks, > > > > > > > > > > -- > > > > > Shawn Webb > > > > > Cofounder and Security Engineer > > > > > HardenedBSD > > > > > > > > > > Tor-ified Signal:+1 443-546-8752 > > > > > Tor+XMPP+OTR:latt...@is.a.hacker.sx > > > > > GPG Key ID: 0x6A84658F52456EEE > > > > > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 > > 6EEE > > > > > > > > Latest kernel works for me : > > > > > > > > FreeBSD od1000.home.blih.net 12.0-CURRENT FreeBSD 12.0-CURRENT #3 > > > > r336834: Sat Jul 28 20:23:33 CEST 2018 > > > > r...@od1000.home.blih.net:/usr/o bj/usr/src/arm64.aarch64/sys/GENERIC > > > > arm64 > > > > > > > > I'll try with latest loader.efi > > > > > > > > -- > > > > Emmanuel Vadot > > > > ___ > > > > 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" > > > > > > Latest loader.efi fails for me the same way, Shawn did you start > > > bisecting ? > > > > > > > Problem is between 20180709 and 20180719 > > > > -- > > Emmanuel Vadot > > > ___ > 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" -- Emmanuel Vadot ___ 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: Booting arm64 uefi broken
On Sat, 28 Jul 2018 20:34:31 +0200 Emmanuel Vadot wrote: > On Sat, 28 Jul 2018 20:28:30 +0200 > Emmanuel Vadot wrote: > > > On Sat, 28 Jul 2018 13:17:45 -0400 > > Shawn Webb wrote: > > > > > It appears with the latest 12-CURRENT/arm64, booting is broken. The > > > boot process gets stuck after the "Using DTB provided by..." message. > > > > > > This is on my SoftIron OverDrive 1000: > > > > > > >> FreeBSD EFI boot block > > > >> > > >Loader path: /boot/loader.efi > > > > > > > > > > > >Initializing modules: ZFS UFS > > > > > >Load Path: \EFI\BOOT\BOOTAA64.EFI > > > > > >Load Device: > > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(1,GPT,73365FD5-9260-11E8-9F00-0026B93F5298,0x3,0x640) > > >BootCurrent: 0002 > > > > > >BootOrder: 0001 0005 0006 0002[*] > > > > > >Probing 7 block devices..+..* done > > > > > > ZFS found the following pools: rpool > > > > > > UFS found 1 partition > > > > > > Consoles: EFI console > > > > > > FreeBSD/arm64 EFI loader, Revision 1.1 > > > > > > (Sat Jul 28 11:32:06 UTC 2018 r...@nyi-01.build.hardenedbsd.org) > > > > > > > > > > > >Command line arguments: loader.efi > > > > > >EFI version: 2.60 > > > > > >EFI Firmware: SoftIron Overdrive 1000 (rev 1.00) > > > > > >Console: efi (0) > > > > > >Load Path: > > > HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > >Load Device: > > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > >BootCurrent: 0002 > > > > > >BootOrder: 0001 0005 0006 0002[*] > > > > > >BootInfo Path: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0) > > > > > > Ignoring Boot0002: Only one DP found > > > > > > Trying ESP: > > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > Setting currdev to disk1p2: > > > > > > Loading /boot/defaults/loader.conf > > > > > > /boot/kernel/kernel text=0x8a7169 data=0x1384d0+0x7d39fc > > > syms=[0x8+0x11d108+0x8+0x10e646] > > > /boot/entropy size=0x1000 > > > > > > efi-autoresizecons: Neither Graphics Output Protocol nor Universal > > > Graphics Adapter present > > > > > > > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > > > > > Booting [/boot/kernel/kernel]... > > > > > > Using DTB provided by EFI at 0x801fe0. > > > > > > Thanks, > > > > > > -- > > > Shawn Webb > > > Cofounder and Security Engineer > > > HardenedBSD > > > > > > Tor-ified Signal:+1 443-546-8752 > > > Tor+XMPP+OTR:latt...@is.a.hacker.sx > > > GPG Key ID: 0x6A84658F52456EEE > > > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > > > > Late
Re: Booting arm64 uefi broken
On Sat, 28 Jul 2018 20:28:30 +0200 Emmanuel Vadot wrote: > On Sat, 28 Jul 2018 13:17:45 -0400 > Shawn Webb wrote: > > > It appears with the latest 12-CURRENT/arm64, booting is broken. The > > boot process gets stuck after the "Using DTB provided by..." message. > > > > This is on my SoftIron OverDrive 1000: > > > > >> FreeBSD EFI boot block > > >> > >Loader path: /boot/loader.efi > > > > > > > >Initializing modules: ZFS UFS > > > >Load Path: \EFI\BOOT\BOOTAA64.EFI > > > >Load Device: > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(1,GPT,73365FD5-9260-11E8-9F00-0026B93F5298,0x3,0x640) > >BootCurrent: 0002 > > > >BootOrder: 0001 0005 0006 0002[*] > > > >Probing 7 block devices..+..* done > > > > ZFS found the following pools: rpool > > > > UFS found 1 partition > > > > Consoles: EFI console > > > > FreeBSD/arm64 EFI loader, Revision 1.1 > > > > (Sat Jul 28 11:32:06 UTC 2018 r...@nyi-01.build.hardenedbsd.org) > > > > > > > >Command line arguments: loader.efi > > > >EFI version: 2.60 > > > >EFI Firmware: SoftIron Overdrive 1000 (rev 1.00) > > > >Console: efi (0) > > > >Load Path: HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > > >Load Device: > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > >BootCurrent: 0002 > > > >BootOrder: 0001 0005 0006 0002[*] > > > >BootInfo Path: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0) > > > > Ignoring Boot0002: Only one DP found > > > > Trying ESP: > > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > > Setting currdev to disk1p2: > > > > Loading /boot/defaults/loader.conf > > > > /boot/kernel/kernel text=0x8a7169 data=0x1384d0+0x7d39fc > > syms=[0x8+0x11d108+0x8+0x10e646] > > /boot/entropy size=0x1000 > > > > efi-autoresizecons: Neither Graphics Output Protocol nor Universal Graphics > > Adapter present > > > > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > > > Booting [/boot/kernel/kernel]... > > > > Using DTB provided by EFI at 0x801fe0. > > > > Thanks, > > > > -- > > Shawn Webb > > Cofounder and Security Engineer > > HardenedBSD > > > > Tor-ified Signal:+1 443-546-8752 > > Tor+XMPP+OTR:latt...@is.a.hacker.sx > > GPG Key ID: 0x6A84658F52456EEE > > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > > Latest kernel works for me : > > FreeBSD od1000.home.blih.net 12.0-CURRENT FreeBSD 12.0-CURRENT #3 > r336834: Sat Jul 28 20:23:33 CEST 2018 > r...@od1000.home.blih.net:/usr/o bj/usr/src/arm64.aarch64/sys/GENERIC > arm64 > > I'll try with latest loader.efi > > -- > Emmanuel Vadot > ___ > 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" Latest loader.efi fails for me the same way, Shawn did you start bisecting ? -- Emmanuel Vadot ___ 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: Booting arm64 uefi broken
On Sat, 28 Jul 2018 13:17:45 -0400 Shawn Webb wrote: > It appears with the latest 12-CURRENT/arm64, booting is broken. The > boot process gets stuck after the "Using DTB provided by..." message. > > This is on my SoftIron OverDrive 1000: > > >> FreeBSD EFI boot block > >> >Loader path: /boot/loader.efi > > > >Initializing modules: ZFS UFS > >Load Path: \EFI\BOOT\BOOTAA64.EFI > >Load Device: > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(1,GPT,73365FD5-9260-11E8-9F00-0026B93F5298,0x3,0x640) >BootCurrent: 0002 > >BootOrder: 0001 0005 0006 0002[*] > >Probing 7 block devices..+..* done > > ZFS found the following pools: rpool > > UFS found 1 partition > > Consoles: EFI console > > FreeBSD/arm64 EFI loader, Revision 1.1 > > (Sat Jul 28 11:32:06 UTC 2018 r...@nyi-01.build.hardenedbsd.org) > > > >Command line arguments: loader.efi > >EFI version: 2.60 > >EFI Firmware: SoftIron Overdrive 1000 (rev 1.00) > >Console: efi (0) > >Load Path: HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > >Load Device: > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) >BootCurrent: 0002 > >BootOrder: 0001 0005 0006 0002[*] > >BootInfo Path: PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0) > > Ignoring Boot0002: Only one DP found > > Trying ESP: > PcieRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/USB(0x2,0x0)/HD(2,GPT,73365FE7-9260-11E8-9F00-0026B93F5298,0x643,0x107D00) > Setting currdev to disk1p2: > > Loading /boot/defaults/loader.conf > > /boot/kernel/kernel text=0x8a7169 data=0x1384d0+0x7d39fc > syms=[0x8+0x11d108+0x8+0x10e646] > /boot/entropy size=0x1000 > > efi-autoresizecons: Neither Graphics Output Protocol nor Universal Graphics > Adapter present > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > Booting [/boot/kernel/kernel]... > > Using DTB provided by EFI at 0x801fe0. > > Thanks, > > -- > Shawn Webb > Cofounder and Security Engineer > HardenedBSD > > Tor-ified Signal:+1 443-546-8752 > Tor+XMPP+OTR:latt...@is.a.hacker.sx > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE Latest kernel works for me : FreeBSD od1000.home.blih.net 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r336834: Sat Jul 28 20:23:33 CEST 2018 r...@od1000.home.blih.net:/usr/o bj/usr/src/arm64.aarch64/sys/GENERIC arm64 I'll try with latest loader.efi -- Emmanuel Vadot ___ 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: EFI booting from external USB pen drive
On 2018-07-06 09:34, Bjoern A. Zeeb wrote: On 6 Jul 2018, at 6:34, Emmanuel Vadot wrote: FAT12 can work with all EFI implementation, the problem is the size of the FAT12 part that sometimes causes problems. Ok, now that we are all on the same page, changing it to newfs_msdos -F 32 did not make a change to my problem of the boot menu changing to the blank screen and immediately returning to itself. /bz What boot menu and what blank screen ? -- Emmanuel Vadot ___ 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"
