make installworld crashes the system in g_slice_access geom_slice.c:127
Hello, While upgrading from source my 13-CURRENT box from ALPHA1 to BETA1, I got the following crash on make installworld. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x30 fault code = supervisor read data, page not present instruction pointer = 0x20:0x8034d5b0 stack pointer = 0x28:0xfe00c8204600 frame pointer = 0x28:0xfe00c8204640 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 65294 (fsck_ufs) trap number = 12 panic: page fault cpuid = 1 time = 1613467739 #16 0x8034d5b0 in g_slice_access (pp=0xf80003ca5100, dr=1, dw=0, de=0) at /usr/src/sys/geom/geom_slice.c:127 #17 0x8034e6e4 in g_access (cp=0xf80003c82e00, dcr=, dcr@entry=1, dcw=, dcw@entry=0, dce=dce@entry=0) at /usr/src/sys/geom/geom_subr.c:1042 #18 0x8034698f in g_dev_open (dev=, flags=, fmt=, td=) at /usr/src/sys/geom/geom_dev.c:442 #19 0x80342e46 in devfs_open (ap=0xfe00c82047a0) at /usr/src/sys/fs/devfs/devfs_vnops.c:1290 #20 0x806bb05c in VOP_OPEN_APV (vop=0x80863e20 , a=a@entry=0xfe00c82047a0) at vnode_if.c:436 #21 0x804bef1e in VOP_OPEN (vp=0xf80003cdc000, mode=1, cred=0xf800029d4420, td=0x0, fp=0xf802a7208140) at ./vnode_if.h:220 #22 vn_open_vnode (vp=vp@entry=0xf80003cdc000, fmode=fmode@entry=1, cred=, cred@entry=0xf80002993700, td=, td@entry=0xfe00c8149300, fp=) at /usr/src/sys/kern/vfs_vnops.c:411 #23 0x804bead0 in vn_open_cred (ndp=ndp@entry=0xfe00c8204970, flagp=, flagp@entry=0xfe00c8204a94, cmode=, vn_open_flags=vn_open_flags@entry=0, cred=, fp=0x7) at /usr/src/sys/kern/vfs_vnops.c:318 #24 0x804be6ad in vn_open (ndp=0xf80003ca5100, ndp@entry=0xfe00c8204970, flagp=0xf800029d43c0, flagp@entry=0xfe00c8204a94, cmode=0, fp=0xf800029d4420) at /usr/src/sys/kern/vfs_vnops.c:193 #25 0x804b4983 in kern_openat (td=0xfe00c8149300, fd=, path=, pathseg=, flags=1, mode=) at /usr/src/sys/kern/vfs_syscalls.c:1143 #26 0x8068ea5c in syscallenter (td=0xfe00c8149300) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189 (kgdb) frame 16 #16 0x8034d5b0 in g_slice_access (pp=0xf80003ca5100, dr=1, dw=0, de=0) at /usr/src/sys/geom/geom_slice.c:127 127 if ((pp->acw + dw) > 0 && pp2->ace > 0) (kgdb) p pp2 $2 = (struct g_provider *) 0x0 pp2 is null, and pp2->ace crashes the system. Does the above crash pattern rings any bell? My system uses UFS SU+trim on GELI. On reboot, I had to manually run fsck. At the end I did reinstall successfully world from my poudriere server through NFS, since I wasn't sure about the state of the files in /usr/obj... Regards, Ali ___ 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"
snd_hda random crack noise on Realtek ALC257
Hello, I'm running 13-current on my Thinkpad T495 (AMD Ryzen 7 PRO 3700U) It has the following sound devices: cat /dev/sndstat Installed devices: pcm0: (play) default pcm1: (play) pcm2: (play) pcm3: (play/rec) pcm4: (play/rec) No devices installed from userspace. So far so good, but randomly, while listening to music videos, there is a random crack noise for about a second coming out of the HDMI monitor speaker (or the internal laptop speaker when pcm3 is used). It is not very frequent, but quiet annoying. The noise is not associated particularly with heavy load, it is random even when I'm running literally nothing but the music player. I've played with the vchans settings, snd.latency setting, but nothing improved the situation. The only thing that solved completely the issue is assigning a single processor to the media player. $ cpuset -l 0 mpv --audio-device=oss//dev/dsp0 video_file.mp4 That worked with firefox as well, even under heavy load. I don't have pulseaudio, but I've tried also sound with pulseaudio and sndio, same issue. Any thoughts? Ali ___ 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"
MII media status race condition causing fictitious link down
Hello, As I've sent a couple of patches to add support for Thinkpad USB-C gen2 to if_ure(4), I came across a very strange link random state change, causing dhclient to think the link went effectively down, which is not the case. First I thought that if_ure(4) doesn't play well with the new chip of the dock, but after lot of debugging, it turns out to be a nasty race condition in mii bus code [1]. I'm sending this mail to raise awareness about this issue. Apparently it exists since long time (I even remember having had this issue in the past on my older Thinkpad). [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252165 Regards, -- Ali Abdallah | SUSE L3 Engineer GPG fingerprint: 51A0 F4A0 C8CF C98F 842E A9A8 B945 56F8 1C85 D0D5 ___ 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: Issues with USB-C external monitors
Sorry for the noise, you can the patches at the following link: https://github.com/Alix82/FreeBSD-xorg-drm-hotplug On 03.12.2020 08:05, Ali Abdallah wrote: > On 02.12.2020 11:28, Ali Abdallah wrote: > > Actually Xorg on FreeBSD with UDEV is compiled with > > --disable-config-udev-kms, thus the server never calls: > > > > udev_monitor_filter_add_match_subsystem_devtype > > > > for GPU devices, and thus libudev-devd doesn't forward kms events to the > > server. Actually Xorg doesn't even process them, even if the filter check > > is bypassed in libudev-devd (udev-monitor.c:261). > > > > Basically Xorg is missing bsd platform code for drm devices, on Linux > > the code that implements that can be found in: > > hw/xfree86/os-support/linux/lnx_platform.c > > I'm attaching two patches that make hotpluggable drm connectors work on > FreeBSD with xorg-server compiled with UDEV. > > If you want to give them a try, for libudev-devd it is enough to apply > patch-libudev-devd-drm-hotplug.c, but for xorg-server you need to change > its Makefile to enable udev-kms, and apply > patch-xorg-server-drm-bsd-platform.c > > UDEV_CONFIGURE_ON= --disable-config-udev-kms > > to > > UDEV_CONFIGURE_ON= --enabled-config-udev-kms > > The bsd-platform code for the xorg-server is basically the same as Linux, > expect for the systemd bit obviously. For now, I appended the code to > hw/xfree86/os-support/bsd/bsd_VTsw.c just because I didn't want to patch > the Makefile.in or Makefile.am and fight with autotools. But that code > should finish in the future in bsd_platform.c. > > It is working perfectly fine for me, also got positive feedback from a > friend using it on a Thinkpad X280 with a USB-C dock. > > The patches even for onboard connectors deliver for "complete" desktop > plugging/unplugging external monitors events (such as Xfce, gnome, KDE), > and then the external monitors are configured automatically. > > I will also later on work on DEVD support as well. > > Regards. > > -- > Ali Abdallah | SUSE Linux L3 Engineer > GPG fingerprint: 51A0 F4A0 C8CF C98F 842E A9A8 B945 56F8 1C85 D0D5 > -- Ali Abdallah | SUSE Linux L3 Engineer GPG fingerprint: 51A0 F4A0 C8CF C98F 842E A9A8 B945 56F8 1C85 D0D5 ___ 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: Issues with USB-C external monitors
On 02.12.2020 11:28, Ali Abdallah wrote: > Actually Xorg on FreeBSD with UDEV is compiled with > --disable-config-udev-kms, thus the server never calls: > > udev_monitor_filter_add_match_subsystem_devtype > > for GPU devices, and thus libudev-devd doesn't forward kms events to the > server. Actually Xorg doesn't even process them, even if the filter check > is bypassed in libudev-devd (udev-monitor.c:261). > > Basically Xorg is missing bsd platform code for drm devices, on Linux > the code that implements that can be found in: > hw/xfree86/os-support/linux/lnx_platform.c I'm attaching two patches that make hotpluggable drm connectors work on FreeBSD with xorg-server compiled with UDEV. If you want to give them a try, for libudev-devd it is enough to apply patch-libudev-devd-drm-hotplug.c, but for xorg-server you need to change its Makefile to enable udev-kms, and apply patch-xorg-server-drm-bsd-platform.c UDEV_CONFIGURE_ON= --disable-config-udev-kms to UDEV_CONFIGURE_ON= --enabled-config-udev-kms The bsd-platform code for the xorg-server is basically the same as Linux, expect for the systemd bit obviously. For now, I appended the code to hw/xfree86/os-support/bsd/bsd_VTsw.c just because I didn't want to patch the Makefile.in or Makefile.am and fight with autotools. But that code should finish in the future in bsd_platform.c. It is working perfectly fine for me, also got positive feedback from a friend using it on a Thinkpad X280 with a USB-C dock. The patches even for onboard connectors deliver for "complete" desktop plugging/unplugging external monitors events (such as Xfce, gnome, KDE), and then the external monitors are configured automatically. I will also later on work on DEVD support as well. Regards. -- Ali Abdallah | SUSE Linux L3 Engineer GPG fingerprint: 51A0 F4A0 C8CF C98F 842E A9A8 B945 56F8 1C85 D0D5 signature.asc Description: PGP signature
Re: Issues with USB-C external monitors
On 01.12.2020 17:10, myfreeweb wrote: > devd (really drm in the kernel) provides hotplug events (system DRM, type > HOTPLUG). > libudev-devd translates these to UD_ACTION_HOTPLUG. > This works well with wlroots compositors at least. > How xorg does this I have no idea, as I don't use xorg. > If your xorg is built with DEVD instead of UDEV option, it shouldn't work, I > don't recall anyone adding support for that there. > With UDEV it might work? Actually Xorg on FreeBSD with UDEV is compiled with --disable-config-udev-kms, thus the server never calls: udev_monitor_filter_add_match_subsystem_devtype for GPU devices, and thus libudev-devd doesn't forward kms events to the server. Actually Xorg doesn't even process them, even if the filter check is bypassed in libudev-devd (udev-monitor.c:261). Basically Xorg is missing bsd platform code for drm devices, on Linux the code that implements that can be found in: hw/xfree86/os-support/linux/lnx_platform.c Compiling the server with --enable-config-udev-kms, the server expects to have the following functions implemented xf86PlatformReprobeDevice, xf86PlatformDeviceProbe, DeleteGPUDeviceRequest and xf86PlatformDeviceCheckBusID. Those are fairly easy to implement to enable Xorg to listen to libudev-devd drm events and to re-configure the drm connectors. I have already some scratch code, will test more and probably send upstream. I will probably also add devd code for that, as I use xorg server with devd on my FreeBSD 12.x machines. Thanks, Ali ___ 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: Issues with USB-C external monitors
On 01.12.2020 20:33, Poul-Henning Kamp wrote: > > > When I last tried this on my T480/T3-Dock/xorg, the screen comes back, but > xrandr shows it with ever increasing names "DP-3", "DP-4" etc. > > For now I've given up and use the T480's HDMI output instead. I've noticed that as well, the sys.class.drm.card0-DP-3 disappears and sys.class.drm.card0-DP-4 is created instead. I need to drive two external monitors, that's why I need the external dock. ___ 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: Issues with USB-C external monitors
On 01.12.2020 11:08, Scott Long wrote: > I have a work-in-progress to support Thunderbolt, but that’s not always the > same as just DisplayPort-over-USBC. If your connector has the Thunderbolt > logo, then it’s Thunderbolt, if it has the DP logo then it’s not. Even then, > the Thunderbolt component only controls enable/disable permissions and > bandwidth partitioning. The graphics chip and DRM code does the rest of the > work, and it sounds like the problems here are with those components. T495 has AMD Ryzen silicon, and AMD never associated Thunderbolt with its Ryzen platforms. The dock connector is just a USB-C. On dock removal, the devd events (system DRM, type HOTPLUG) are correctly generated and received by libudev-devd, but then for some reason UD_ACTION_HOTPLUG is not causing the X server to re-scan drm connectors and to re-configure them. Will dig further into the issue as I feel it should be easy to solve. > > Scott > Ali ___ 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: Issues with USB-C external monitors
On 01.12.2020 17:10, myfreeweb wrote:
> >> __snippet__
> >> res = drmModeGetResources(fd);
> >> for (int i = 0; i < res->count_connectors; ++i) {
> >> conn = drmModeGetConnector(fd, res->connectors[i]);
>
> Note: you can run graphics/drm_info instead of writing custom code.
Thanks for the tip.
> devd (really drm in the kernel) provides hotplug events (system DRM, type
> HOTPLUG).
> libudev-devd translates these to UD_ACTION_HOTPLUG.
> This works well with wlroots compositors at least.
>
> How xorg does this I have no idea, as I don't use xorg.
> If your xorg is built with DEVD instead of UDEV option, it shouldn't work, I
> don't recall anyone adding support for that there.
> With UDEV it might work?
On current, for now I'm using the standard xorg-server from pkg, built
with UDEV according to [1], so apparently that is not working either. At
least in my case.
Will dig futher into it.
>
> >There is missing code in the kernel to handle USB-C PCI express
> >attach/detach. CC'ing Scott Long.
>
> Seems like this is about regular DisplayPort over USB-C (the USB side almost
> always handled in firmware for this on non-embedded computers).
> I don't think I've ever seen a *monitor* connecting over PCIe to an existing
> GPU ;)
> (in this case card0, the onboard vega)
Yes, this is just the DisplayPort over USB-C from the onboard vega GPU.
[1] https://www.freshports.org/x11-servers/xorg-server/
___
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"
Issues with USB-C external monitors
Hello,
I have a T495 with a USB-C docking station with two external monitors,
running current to get the vega 10 amdgpu to work.
When the power is lost for on the USB-C dock, then the X server looses
all external monitors. They appear as disconnected after running xrandr
and I cannot figure out a way to bring them back without killing my
current session and start X again, but that is very annoying...
I tried to debug the issue and I'm pretty sure that the X server on
FreeBSD is not reconfiguring the drm connectors automatically.
Let's say I have DP-4 as external connector, when the power is lost,
DP-4 disappears, when the power is back, DP-4 re-appear again but in
unknown status.
$ sysctl sys.class.drm | grep DP-4
sys.class.drm.card0-DP-4.modes:
sys.class.drm.card0-DP-4.dpms: Off
sys.class.drm.card0-DP-4.enabled: disabled
sys.class.drm.card0-DP-4.status: unknown
Now just running a simple libdrm code to rescan the connectors:
__snippet__
res = drmModeGetResources(fd);
for (int i = 0; i < res->count_connectors; ++i) {
conn = drmModeGetConnector(fd, res->connectors[i]);
After running the above code, the drm stack is somehow triggered to
re-read the DP-4.status, which appears now to be connected, but not
configured.
$ sysctl sys.class.drm | grep DP-4
sys.class.drm.card0-DP-4.modes: 1920x1080
sys.class.drm.card0-DP-4.dpms: Off
sys.class.drm.card0-DP-4.enabled: disabled
sys.class.drm.card0-DP-4.status: connected
I didn't dig further to see if I can trigger the X server to re-scan drm
connectors and eventually remove those that vanished, and add newly
detected connectors. On Linux that seems to work automatically.
Any thoughts?
Regards,
Ali.
___
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"
HD audio problem on FreeBSD 12.1 bhyve VM
Hello, I'm running FreeBSD 12.1 release host with the HD bhyve audio patch from 13-current. On a OpenSUSE 15.2 bhyve guest, audio works perfectly fine. However, on FreeBSD 12.1 only noise comes out. Using /dev/dsp4 (which is a USB sound device), audio works fine, but not on /dev/dsp0, the default sound device on my system. I see the following relevant errors: pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead pin dump from FreeBSD 12.1 VM. -- hdaa0: Dumping AFG pins: hdaa0: nid 0xas seq device conn jackloccolor misc hdaa0: 3 1010 1 0 Line-out Jack Unknown 0x00 Black 0 hdaa0: Caps:OUT Sense: 0x8000 (connected) hdaa0: 5 00805020 2 0 Line-in Jack Unknown 0x00 Red 0 hdaa0: Caps: IN Sense: 0x8000 (connected) hdaa0: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 I tried sysctl dev.hdac.0.polling=1 with no success. Note that: The above problem is also reproducible on 13-Current 20200917. Any help is appreciated. Kind regards, Ali ___ 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"
No battery detected due to _STA method removal
Hello, I hope the fix for the bug below will be committed before FreeBSD 12 is released. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 Cheers, Ali ___ 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: fuser does not list id of processes that have a file
>> I tested on zfs, perhaps there is something extra going on on other
filesystems.
I tested on UFS2, and I get nothing out of the patched fuser.c.
On Thu, Oct 18, 2018 at 11:24 PM Mateusz Guzik wrote:
> On 10/17/18, Ali Abdallah wrote:
> >> diff --git a/usr.bin/fstat/fuser.c b/usr.bin/fstat/fuser.c
> >> index b4225328fc1f..17d06f1c5b13 100644
> >> --- a/usr.bin/fstat/fuser.c
> >> +++ b/usr.bin/fstat/fuser.c
> >> @@ -92,7 +92,7 @@ struct consumer {
> >>STAILQ_ENTRY(consumer) next;
> >> };
> >> struct reqfile {
> >> - uint32_tfsid;
> >> + uint64_tfsid;
> >>uint64_tfileid;
> >>const char *name;
> >>STAILQ_HEAD(, consumer) consumers;
> >
> > The above patch does not resolve the problem for me.
> >
>
> Are you sure you recompiled and reinstalled the tool with the patch
> applied?
> You can recompile and install like this:
> # make -j 3 clean all install
>
> If this indeed still does not work, can you show output of:
> uname -m
> mount
>
> I tested on zfs, perhaps there is something extra going on on other
> filesystems.
>
> --
> Mateusz Guzik
>
___
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: fuser does not list id of processes that have a file
> diff --git a/usr.bin/fstat/fuser.c b/usr.bin/fstat/fuser.c
> index b4225328fc1f..17d06f1c5b13 100644
> --- a/usr.bin/fstat/fuser.c
> +++ b/usr.bin/fstat/fuser.c
> @@ -92,7 +92,7 @@ struct consumer {
>STAILQ_ENTRY(consumer) next;
> };
> struct reqfile {
> - uint32_tfsid;
> + uint64_tfsid;
>uint64_tfileid;
>const char *name;
>STAILQ_HEAD(, consumer) consumers;
The above patch does not resolve the problem for me.
Regards.
On Tue, Oct 16, 2018 at 5:17 PM Ed Schouten wrote:
> Hi there,
>
> Op di 16 okt. 2018 om 15:05 schreef Mateusz Guzik :
> > struct reqfile {
> > - uint32_tfsid;
> > + uint64_tfsid;
> > uint64_tfileid;
>
> Considering that these are based on sb.st_{ino,dev}, maybe better to
> use the occasion to switch these fields to dev_t and ino_t?
>
> --
> Ed Schouten
>
___
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"
fuser does not list id of processes that have a file
Hello, On FreeBSD 12 ALPHA9 > less .vimrc > fuser .vimrc .vimrc: gives no pid, on FreeBSD 11.2 the above works as expected. Regards, Ali ___ 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 Issue with em(4) ALPHA7
I'm having also the same problem on my Thinkpad x230. However I'm running a minimal kernel, so usually I do kldunload/kldload if_em, to reset the hardware and to avoid a reboot. Hopefully this gets fixed soon. Cheers, Ali On Sat, Sep 29, 2018 at 7:06 PM Pete Wright wrote: > Hello, > > More suspend/resume testing on my end. This system is a desktop, so not > critical for my daily workflow but wanted to flag it regardless. The > system is a Lenovo m900 with skylake and em(4) NIC. Entering suspend > works without issues, resuming seems to mostly work as well. I.e. no > issues with display or input from keyboard or mouse. > > The one issue I am running into is my NIC is non-functional after > resume. restarting the network stack via "service netif restart" does > not work - as in no DHCP lease is aquired and no link is detected. Nor > does manually down'ing and up'ing the interface work. I see these > messages in my dmesg buffer after resume: > > in6_purgeaddr: err=65, destination address delete failed > lo0: link state changed to DOWN > lo0: link state changed to UP > Link state changed to down > em0: link state changed to DOWN > em0: TX(0) desc avail = 1024, pidx = 0 > em0: TX(0) desc avail = 1024, pidx = 0 > em0: TX(0) desc avail = 1024, pidx = 0 > em0: TX(0) desc avail = 1024, pidx = 0 > > Another thing I noticed is that after resume "ifconfig" hangs for a > couple seconds printing after printing the first line of my em0 device > (after the flags). Not sure if that's helpful but thought it could be a > useful datapoint. > > It is easy to reproduce this, so I am happy to do any additional > debugging or testing on this. > > > 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" > ___ 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: Intel help with i915 drm-next-kmod (was: drm / drm2 removal in 12)
On Wed, Sep 12, 2018 at 4:19 AM, Graham Perrin wrote: > On 25/08/2018 09:32, Ali Abdallah wrote: > > Isn't Intel supposed to be working on a native drm driver for FreeBSD? > > > > https://bwidawsk.net/blog/index.php/2018/06/i965- > compiler-architecture-from-2015/ > … > > Not that I can see. > > A more recent blog post <https://bwidawsk.net/blog/ > index.php/2018/06/freebsd-work-week-2/> mentions "Help i915 drm-next-kmod > work". > I saw that post already, It also mentions "Create native Intel graphics driver." > > HTH > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm / drm2 removal in 12
Isn't Intel supposed to be working on a native drm driver for FreeBSD? https://bwidawsk.net/blog/index.php/2018/06/i965-compiler-architecture-from-2015/ On Sat, Aug 25, 2018 at 12:19 AM, Matthew Macy wrote: > > > On Fri, Aug 24, 2018 at 14:53 Ali wrote: > >> On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: >> > Just in case anyone misses the change to UPDATING: >> > >> > 20180821: >> > drm and drm2 have been removed. Users on powerpc, 32-bit >> hardware, >> > or with GPUs predating Radeon and i915 will need to install the >> > graphics/drm-legacy-kmod. All other users should be able to use >> > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, >> > graphics/drm-next-kmod, graphics/drm-devel-kmod. >> > Note that this applies only to 12. >> >> I see that The removal of drm and drm2 has been reverted on svn. Could >> you please kindly share the reasons behind the re-inclusion? >> > > > I can’t really give the blow by blow of internal project drama, but the > gist of it is that “best practices” (which are not yet actually documented > anywhere that I’ve seen) were not followed with regards to the deprecation > process. Warner and others believe that we can address the objectives of > the drm removal (improving the user experience and communicating that > drm/drm2 are _completely_ unsupported apart from continuing to compile) > through less disruptive means. I am only acting as a lightning rod and > representative of the graphics team and so have done an inadequate job of > tracking their activities with respect to project timelines. As a result of > this misunderstanding Johannes Lundberg will be sponsored for a bit and > will be able to be involved in internal discussions that impact his work. > > Our only continued frustration is that we were never given any guidance by > RE or core on said “best practices” when the discussion was taking place in > May and then those groups behaved as if this were a surprise when the > removal happened. I’m cautiously optimistic that this well expedite > improving communications on those matters. > > > Cheers. > -M > ___ 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: top -n -o res shows empty output
I have submitted a bug report with a patch https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229842 Best, Ali On Tue, Jul 17, 2018 at 1:41 PM Ali Abdallah wrote: > Hello, > > From around the revision r334918, the command 'top -n -o res' shows empty > output. > > With best regards, > Ali > ___ 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"
top -n -o res shows empty output
Hello, >From around the revision r334918, the command 'top -n -o res' shows empty output. With best regards, Ali ___ 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"
