After today's update, vesa mode is no longer able to detect my graphics card: [ 31.110] (WW) Falling back to old probe method for scfb [ 31.110] scfb trace: probe start [ 31.111] scfb trace: probe done [ 31.111] vesa: Ignoring device with a bound kernel driver [ 31.111] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 31.111] (EE) Screen 0 deleted because of no matching config section. [ 31.111] (II) UnloadModule: "modesetting" [ 31.111] (EE) Screen 0 deleted because of no matching config section. [ 31.111] (II) UnloadModule: "vesa" The "device with a bound kernel driver" message rings a bell. Didn't something like this happen a few years ago? Anyway, nothing else changed today other than the xorg-server update, so I can't account for why this would happen.
Which should it be: "vesa fails" (not UEFI) vs. "for scfb" (UEFI)? vesa is documented to not be appropriate for UEFI. scfb is documented as being appropriate for UEFI . . . https://docs.freebsd.org/en/books/handbook/x11/ reports: "VESA module must be used when booting in BIOS mode and SCFB module must be used when booting in UEFI mode" There are separate ports: xf86-video-scfb xf86-video-vesa The little bit of material that you present references both. (Be warned: I'm no expert in the area. I'm just repeating material that I read.)
I am booting with BIOS mode. I have no explicit xorg.conf file; xorg-server figures out on its own to use the vesa module. So far, I have avoided UEFI like the plague.
The "vesa: Ignoring device with a bound kernel driver" message comes from the x11-drivers/xf86-video-vesa port, the source file vesa.c. However, the ChangeLog file (the file literally named ChangeLog in the port work directory after "make patch") shows no changes since September 2020. Probably doesn't help debug the problem, but I thought I'd mention it. ChangeLog says that the check for a kernel driver bound to the device was introduced December 8, 2010.
(In reply to George Mitchell from comment #2) Hmm. Did your historical logs also show the lines that contain "scfb" that you show here (or contain other such scfb lines)? If xf86-video-scfb is installed, may be it would be good to uninstall it, given your BIOS use? That might stop it from trying scfb (beyond a possible set of not-found activity).
Created attachment 241194 [details] Hack to delete the call to pci_device_has_kernel_driver(dev) This can not in any way be considered to be a fix, but it does let me temporarily work around the problem. I'm eagerly awaiting someone doing some actual analysis of the problem. Since there have not been any recent changes to xf86-video-vesa, perhaps there's something new in the pci_device_has_kernel_driver(dev) routine, wherever that may live.
(In reply to Mark Millard from comment #4) Here are the references to scfb, and I think they are pretty consistent in every Xorg.0.log I have: [...] [ 24.700] (==) Matched scfb as autoconfigured driver 2 [ 24.700] (==) Matched vesa as autoconfigured driver 3 [...] [ 24.854] (II) LoadModule: "scfb" [ 24.854] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so [ 24.863] (II) Module scfb: vendor="X.Org Foundation" [ 24.863] compiled for 1.21.1.4, module version = 0.0.5 [ 24.863] ABI class: X.Org Video Driver, version 25.2 [...] [ 24.876] (WW) Falling back to old probe method for scfb [ 24.876] scfb trace: probe start [ 24.876] scfb trace: probe done [...] [ 25.066] (II) UnloadModule: "scfb" [ 25.066] (II) Unloading scfb [...] On a separate part of this issue, the title of the bug report probably needs to be changed. pci_device_has_kernel_driver is defined in the port devel/libpciaccess. One of the changes from three days ago seems to have removed a FreeBSD change to that subroutine. I think I may know what to do next.
devel/libpciaccess: I think the deletion of files/patch-src_freebsd__pci.c might be a mistake. It causes x11-driver/xf86-video-vesa to fail.
Okay, the correct fix for this is definitely in libpciaccess. The patch in files/patch-src_freebsd__pci.c, just deleted 3 days ago, was created in August 2019 to fix this exact same problem I am having again! That's why the "device with a bound kernel driver" seemed familiar to me!
(In reply to George Mitchell from comment #6) That you have /usr/local/lib/xorg/modules/drivers/scfb_drv.so indicates that xf86-video-scfb is installed for some reason. Unless something is forcing it to be around, you likely could delete the installation and so simplify things a bit. Cool that you found the vesa related problem. Nice work.
The correct fix is to revert the part of commit df10dcefa427fcc3a4b1405387b12466dc5a9cdc that deleted files/patch-src_freebsd__pci.c. The Makefile, distinfo, and pkg-plist changes are correct. My attachment 241194 [details], which was a hack from the word go, is wrong and should be ignored. I have verified that making this fix allows my system to run the VESA driver without problem once again.
I'm adding Niclas Zeising <zeising@FreeBSD.org> (the person who originally committed the fix for this bug) and Emmanuel Vadot <manu@FreeBSD.org> (the person who committed the removal of the fix) to the CC list in the hope of expediting the restoration of the fix.
Comment on attachment 241194 [details] Hack to delete the call to pci_device_has_kernel_driver(dev) Obsoleting my hack fix.
Mhm ok I'll have a look at that. I didn't see any problems running without the "fix" and since there where no explanation about it I simply remove it.
Created attachment 241202 [details] xf86-video-vesa patch Can you check this patch against xf86-video-vesa ? The commit itself explains the situation.
Oh I see that this is the hack that you posted earlier, does it work ?
The xf86-video-vesa patch definitely works. My initial gut reaction was that it was odd that it should be required in this widely distributed package from outside FreeBSD world, and probably would never be adopted upstream. But on further reflection I find myself asking why the driver cares about whether a kernel driver is attached, especially since in the FreeBSD world it seems unavoidable that the vgapci kernel driver will be attached. Plus, among the only five ports I use that depend on libpciaccess, only xf86-video-vesa calls pci_device_has_kernel_driver. So now I'm convinced that your version of my hack is the correct patch to apply.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=b6d89731d542582d2cc751e7a56b78df76a38ce7 commit b6d89731d542582d2cc751e7a56b78df76a38ce7 Author: Emmanuel Vadot <manu@FreeBSD.org> AuthorDate: 2023-03-30 08:05:52 +0000 Commit: Emmanuel Vadot <manu@FreeBSD.org> CommitDate: 2023-03-30 19:03:20 +0000 x11-drivers/xf86-video-vesa: Add patch for ignoring if kernel as a driver The vesa driver checks if the kernel as a driver attached to the pci device. This used to work before df10dcefa427 ("devel/libpciaccess: Update to 0.17") because we had a patch in libpciaccess that always said that the kernel didn't had any driver attached. This is obviously not a correct way. The problem is that vgapci is always attached for us so for pci video devices we always have a driver attached. Ignoring the check in xf86-video-vesa seems the best way for us. PR: 270509 Sponsored by: Beckhoff Automation GmbH & Co. KG x11-drivers/xf86-video-vesa/Makefile | 2 +- x11-drivers/xf86-video-vesa/files/patch-src_vesa.c (new) | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-)
I hope I'm doing this right, but it seems to me this bug is now fixed. Was I right to close it?
(In reply to George Mitchell from comment #18) Yup :)
The following drivers also need to be patched: xf86-video-ast xf86-video-cirrus xf86-video-mga xf86-video-nv (Or the original libpciaccess patch could be restored.)
As Tijl Coosemans noted, the problem also affects nv and mga drivers. Here the problem reported in the Xorg.#.log file is "The PCI device [...] has a kernel module claiming it." followed by "This driver cannot operate until it has been unloaded." Even "Xorg -configure" doesn't work. What pkg calls libpciaccess version 16 works. The current version (17) does not, for me, with any driver (mga, nv, nvidia, vesa, modesetting, or any others I tried) and any xorg.conf file or lack thereof I tried, though the various choices (such as vesa) and settings sometimes got different complaints. Manually reverting libpciaccess to version 16 fixed the problem. Maybe it's the same issue as bug 239065? In that case, 13.5 worked, 14 didn't, and newly released 16 did. -WBE
(In reply to wbe from comment #21) > Manually reverting libpciaccess to version [0.]16 fixed the problem. After removing useless and auto-generated files, the difference between two versions looks manageable: $ diff -rdupbw libpciaccess-0.1* | wc -l 1127 Shouldn't be too hard to find the upstream change (commit) which broke things, so current version could be fixed instead of downgrading.
(In reply to wbe from comment #21) I'm the one who put this misleading title on the bug. This problem really seems to be in the video drivers incorrectly expecting that no kernel driver will attach to the graphics cards and not to a libpciaccess problem. I'll fix the title now.
Sorry for my stupid question. Will the suggested solution in this thread help resolve this (bug #267606)
(In reply to Sergiy from comment #24) Seems very unlikely to me: this bug never caused core dumps. It merely made the video drivers erroneously ignore the video card.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=9fa263c21fb287ab1edc085498d8ecb36b494614 commit 9fa263c21fb287ab1edc085498d8ecb36b494614 Author: Tijl Coosemans <tijl@FreeBSD.org> AuthorDate: 2023-04-15 15:31:17 +0000 Commit: Tijl Coosemans <tijl@FreeBSD.org> CommitDate: 2023-04-16 08:34:17 +0000 x11-drivers/xf86-video-nv: Update to 2.1.22 Also fix regression from df10dcefa427 [1] PR: 270869, 270509 [1] Approved by: x11 (manu) x11-drivers/xf86-video-nv/Makefile | 5 ++--- x11-drivers/xf86-video-nv/distinfo | 6 +++--- x11-drivers/xf86-video-nv/files/patch-src-nv_driver.c | 19 ++++++++++++++++++- .../xf86-video-nv/files/patch-src_riva__xaa.c (gone) | 14 -------------- 4 files changed, 23 insertions(+), 21 deletions(-)
OK. Thanks for the answer.
I'm pleased to report that the new xf86-video-nv 2.1.22 indeed now works with libpciaccess 0.17 for me. It would be helpful if the mga driver (xf86-video-mga) were similarly upgraded to work with libpciaccess 0.17. I don't recall whether the vesa driver had this particular problem ("... has a kernel module claiming it") or not, but I do recall that it didn't work for me with 0.17 as the driver for mga or nv hardware.
(In reply to wbe from comment #28) How about this patch for x11-drivers/xf86-video-mga? diff -urN /usr/ports/x11-drivers/xf86-video-mga/files/patch-src_mga__driver.c ./x11-drivers/xf86-video-mga/files/patch-src_mga__driver.c --- /usr/ports/x11-drivers/xf86-video-mga/files/patch-src_mga__driver.c 1970-01-01 09:00:00.000000000 +0900 +++ ./x11-drivers/xf86-video-mga/files/patch-src_mga__driver.c 2023-06-28 14:09:39.602063000 +0900 @@ -0,0 +1,18 @@ +--- src/mga_driver.c.orig 2018-12-08 10:08:01.000000000 +0900 ++++ src/mga_driver.c 2023-06-28 14:08:34.513506000 +0900 +@@ -702,6 +702,7 @@ + ScrnInfoPtr pScrn = NULL; + MGAPtr pMga; + ++#ifndef __FreeBSD__ + if (pci_device_has_kernel_driver(dev)) { + /* If it's a G200 server chip, it's probably on KMS, so bail; if not, + * it might be using matroxfb, which is ok. */ +@@ -721,6 +722,7 @@ + return FALSE; + } + } ++#endif + + /* Allocate a ScrnInfoRec and claim the slot */ + pScrn = xf86ConfigPciEntity(pScrn, 0, entity_num, MGAPciChipsets,
I haven't tried the patch because the system in question runs entirely on pkg packages. I've watched for a new version of xf86-video-mga, but I haven't seen one so far. I then hoped the update would be included with FreeBSD 14.0, but it wasn't. I haven't had occasion to use git (ever). My experience from the portsnap days is that trying to build a small piece (such as this driver) may try to drag in and build the whole hierarchy, and I'm not interested in building all of X11 just to get this piece, so I've shied away from trying. If my worries are unfounded, and it's possible to build just xf86-video-mga using the otherwise existing 14.0-RELEASE pkg installed X11 headers and libraries, point me to a description of how to use git to do that and I'll give it a try.
(In reply to wbe from comment #30) Handbook explains how to use git: https://docs.freebsd.org/en/books/handbook/mirrors/#git I updated my FUJITSU TX1330 M2 Server from 13.2-RELEASE-p10 to 13.3-RELEASE using freebsd-update. And my patch in comment #29 is still helpful with x11-drivers/xf86-video-mga and libpciaccess 0.18. pciconf -lv says: vgapci0@pci0:2:0:0: class=0x030000 rev=0x05 hdr=0x00 vendor=0x102b device=0x0522 subvendor=0x1734 subdevice=0x11cc vendor = 'Matrox Electronics Systems Ltd.' device = 'MGA G200e [Pilot] ServerEngines (SEP1)' class = display subclass = VGA Thanks.
To the best of my knowledge, this bug is fixed and I would be happy to close it. But I have just the one specific type of video hardware. Does anyone know of some hardware that still has a problem with this bug? If not, I will close it as overcome by events.
Ah, so you were waiting for me to try it. I've been busy doing something else I wanted to finish before trying to fight building this from git (see Comment 30). If the mga change is basically the same as the nvidia change, I would expect it to work. If any other drivers (e.g., the VESA driver) need the same fix, I would hope they get it, too. If the xf86-video-mga change appears as a pkg upgrade, I can try it pretty quickly and then follow up here.
Regrettably, there's no entry in the xf86-video-mga log that would indicate that this patch (comment #29) has been committed, and I'm not a committer. So I guess it's too soon to close.
(In reply to George Mitchell from comment #34) The same may be true of comment #20 's items: xf86-video-ast xf86-video-cirrus since no commit reports are list here yet for them either.
(In reply to wbe from comment #30) This is too my exact situation. When xf86-video-mga appear as pkg I'll test it right away.
I encountered the same issue on an IBM server. # dmidecode -t system # dmidecode 3.5 # SMBIOS entry point at 0x7e7bf000 Found SMBIOS entry point in EFI, reading table from /dev/mem. SMBIOS 2.7 present. Handle 0x0015, DMI type 1, 27 bytes System Information Manufacturer: IBM Product Name: IBM System x3300 M4 -[7382PBC]- [...] # pciconf -lv | grep -B3 display vgapci0@pci0:4:0:0: class=0x030000 rev=0x00 hdr=0x00 vendor=0x102b device=0x0534 subvendor=0x1014 subdevice=0x0405 vendor = 'Matrox Electronics Systems Ltd.' device = 'G200eR2' class = display # pkg search xf86-video-mga xf86-video-mga-2.0.0_4,3 X.Org mga display driver # cat /var/log/Xorg.0.log [ 208.073] X.Org X Server 1.21.1.13 X Protocol Version 11, Revision 0 [ 208.073] Current Operating System: FreeBSD bluey 14.1-RC1 FreeBSD 14.1-RC1 releng/14.1-n267678-4de43de58f51 GENERIC amd64 [ 208.073] [ 208.073] Current version of pixman: 0.42.2 [ 208.073] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 208.073] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 208.074] (==) Log file: "/var/log/Xorg.0.log", Time: Thu May 30 22:21:32 2024 [ 208.134] (==) Using config directory: "/usr/local/etc/X11/xorg.conf.d" [ 208.134] (==) Using system config directory "/usr/local/share/X11/xorg.conf.d" [ 208.148] (==) No Layout section. Using the first Screen section. [ 208.148] (==) No screen section available. Using defaults. [ 208.148] (**) |-->Screen "Default Screen Section" (0) [ 208.148] (**) | |-->Monitor "<default monitor>" [ 208.149] (==) No device specified for screen "Default Screen Section". Using the first device section listed. [ 208.149] (**) | |-->Device "Card0" [ 208.149] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 208.149] (**) Allowing byte-swapped clients [ 208.149] (==) Automatically adding devices [ 208.149] (==) Automatically enabling devices [ 208.149] (==) Automatically adding GPU devices [ 208.149] (==) Automatically binding GPU devices [ 208.149] (==) Max clients allowed: 256, resource mask: 0x1fffff [ 208.307] (==) FontPath set to: /usr/local/share/fonts/misc/, /usr/local/share/fonts/TTF/, /usr/local/share/fonts/OTF/, /usr/local/share/fonts/Type1/, /usr/local/share/fonts/100dpi/, /usr/local/share/fonts/75dpi/, catalogue:/usr/local/etc/X11/fontpath.d [ 208.307] (==) ModulePath set to "/usr/local/lib/xorg/modules" [ 208.307] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 208.307] (II) Module ABI versions: [ 208.307] X.Org ANSI C Emulation: 0.4 [ 208.307] X.Org Video Driver: 25.2 [ 208.307] X.Org XInput driver : 24.4 [ 208.307] X.Org Server Extension : 10.0 [ 208.310] (--) PCI:*(4@0:0:0) 102b:0534:1014:0405 rev 0, Mem @ 0x92000000/16777216, 0x917fc000/16384, 0x91800000/8388608, BIOS @ 0x????????/65536 [ 208.311] (II) LoadModule: "glx" [ 208.339] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so [ 208.407] (II) Module glx: vendor="X.Org Foundation" [ 208.407] compiled for 1.21.1.13, module version = 1.0.0 [ 208.407] ABI class: X.Org Server Extension, version 10.0 [ 208.407] (II) LoadModule: "mga" [ 208.408] (II) Loading /usr/local/lib/xorg/modules/drivers/mga_drv.so [ 208.423] (II) Module mga: vendor="X.Org Foundation" [ 208.423] compiled for 1.21.1.13, module version = 2.0.0 [ 208.423] Module class: X.Org Video Driver [ 208.423] ABI class: X.Org Video Driver, version 25.2 [ 208.423] (II) MGA: driver for Matrox chipsets: mga2064w, mga1064sg, mga2164w, mga2164w AGP, mgag100, mgag100 PCI, mgag200, mgag200 PCI, mgag200 SE A PCI, mgag200 SE B PCI, mgag200 EV Maxim, mgag200 ER SH7757, mgag200 eW Nuvoton, mgag200 eW3 Nuvoton, mgag200eH, mgag200eH3, mgag400, mgag550 [ 208.424] (--) Using syscons driver with X support (version 2.0) [ 208.424] (--) using VT number 9 [ 208.424] (EE) mga: The PCI device 0x534 at 04@00:00:0 has a kernel module claiming it. [ 208.424] (EE) mga: This driver cannot operate until it has been unloaded. [ 208.424] (EE) No devices detected. [ 208.424] (EE) Fatal server error: [ 208.424] (EE) no screens found(EE) [ 208.424] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 208.424] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 208.424] (EE) [ 208.424] (EE) Server terminated with error (1). Closing log file. #
HP microservers also have this problem. vgapci0@pci0:1:0:1: class=0x030000 rev=0x00 hdr=0x00 vendor=0x102b device=0x0533 subvendor=0x103c subdevice=0x3381 vendor = 'Matrox Electronics Systems Ltd.' device = 'MGA G200EH' class = display subclass = VGA
I don't know if it's an oversight or intentional, but as of upgrading from 14.0 to 14.1 in early June, xf86-video-mga has been absent from the pkg repository. I just checked again, and it's still absent. In the best case, it's absent because it's known not to work and will reappear once it's been fixed, but there may be a testing issue: a patch was posted in Comment #29 which I'd be happy to test once it comes out via pkg, but I think the developers want someone to get the source from ports, apply the patch, build it all, install, and test it and confirm it works first.
(In reply to wbe from comment #39) FYI: x11-drivers/xf86-video-mga was deleted from the ports tree: QUOTE 2.0.0_4,3 01 Jul 2024 08:13:58 x11-drivers: Remove old video drivers Remove drivers for ancient hardware. Differential Revision: https://reviews.freebsd.org/D45741 Reviewed by: bapt Sponsored by: Beckhoff Automation GmbH & Co. KG END QUOTE FreshPorts shows packages for x11-drivers/xf86-video-mg only for platforms that last updated the package repo based on source from before that delete happened. (I'm not trying to be fully detailed about the timing for quarterly.)
(In reply to heikki from comment #38) Heikki: How old are those HP microservers? Are they "ancient hardware"? (In reply to Mark Millard from comment #40) Mark: Is a copy of the source + FreeBSD patches for 2.0.0_4,3 still available? Am I correct in interpreting your comment as saying that xf86-video-mga is still available upstream and that it's just a FreeBSD decision to stop supporting that driver?
(In reply to wbe from comment #41) > Heikki: How old are those HP microservers? Are they "ancient hardware"? Matrox MGA is THE onboard graphics chip on server boards. Look at Supermicro, HPE and the like. These do not need overblown gaming graphics hardware. > ... that it's just a FreeBSD decision to stop supporting that driver? More exactly, it is the decision of a few high-handed FreeBSD devs. Actually, in my view removing THE server graphics chipset driver from the system looks like a bad joke that puts in question the slogan "The power to serve". Mr. Vadot already announced in the mailing lists long time ago that he wants to throw out _all_ graphics drivers except for the oligopol Intel/AMD/Nvidia together with the SC console, and made clear that he is bent to do so, and he will try again and again until his will will go through without too much protests. I am now unsure whether it is more prudent to search for the latest xf86-video-mga snapshot before it got deleted, to make a package of it to enable servers use graphics without having to install an energy-burning AMD/Nvidia graphics card, or to altogether completely abandon FreeBSD after almost 30 years and to migrate to Linux.
(In reply to Stefan B. from comment #42) Hi, Stefan. Maybe another BSD (e.g., OpenBSD, NetBSD) would be less work than switching to some flavor of Linux? > Matrox MGA is THE onboard graphics chip on server boards. > Look at Supermicro, HPE and the like. You mean like my server board or Heikki's HP microservers? :-) OTOH, once upon a time (years ago), the VESA driver actually worked better than the MGA driver for me. I forget off-hand at which xorg-server major version change it broke, but the VESA driver now only comes up in "if all else fails" 640x480 mode, and the screen is garbled. However, since xf86-video-vesa is still supported, if that were fixed to work on the MGA hardware, I wouldn't miss the mga driver.
(In reply to wbe from comment #41) The git history still contains x11-drivers/xf86-video-mga and it could be be made visible again.
> Heikki: How old are those HP microservers? Are they "ancient hardware"? HPE microservers are currently manufactured and are quite popular (I have several versions). Current GEN10 Plus version (release 2019) has Matrox G200eH3, GEN8 (2013) has G200EH. It is embedded in Intel chipsets, that is why it is very common in servers. Some of the HPE Microservers have AMD CPU and thus AMD graphics, but there is no way to tell that from version and release date, as Gen8 has versions with both CPUs. HPE Microservers have been cheapest servers which support ECC, and have 4 drive bays, so they are very useful for smaller servers, running zfs happily. They do have one x8 slot, but it is usually used for OS SSD to leave 3.5inch bays for larger disks and thus not usable for additional graphics card, which would be wasteful anyway. I find it odd that people in FreeBSD team does not know this, being a server focused OS ? Removing things should be very seriously considered and not to be done on a whim, as it may force expensive hardware or OS replacement and narrows available options. In this case, no more servers with Intel chipsets is pretty bad, as Intel is still pretty strong in server area, even if they have been taking some damage lately. Embedded or industrial computers also tend to use chipsets which some may consider "obsolete", so this is a worrying trend, if hardware support disappears in new releases and FreeBSD drops support for older FreeBSD releases.
I didn't knew those where still commonly found, I though that this was only for the old Matrox card popular in early 2000 (even before maybe ?). Anyway, I'll restore this driver soon-ish.
While you are listening, I need SC console instead of VT (with nvidia, nv or vesa in X, without kernel modesetting). I'm greatly alarmed by intention to destroy SC. Don't judge by your own needs.
Why is sc(4) needed for nvidia ?
The video chip GeForce 6150 on my motherboard was supported by x11/nvidia-driver-304, but not anymore. I had to switch from nvidia to nv and from i386 to amd64. I use KOI8-R/KOI8-U locale (as was standard for Russian and Ukrainian when I switched from MS-DOS to FreeBSD) instead of UTF-8. editors/aee doesn't support Unicode, and to distinguish text files from binary files for migration to Unicode is quite non-trivial and error-prone. VT requires Unicode locale. I use 11 virtual SC consoles for everything text, including email (mail/mutt). You want to move everything into X, I don't. Don't force everybody to do everything exactly same as you do.
(In reply to heikki from comment #45) > I find it odd that people in FreeBSD team does not know this, being a server focused OS ? Maybe this is because one particularity of FreeBSD is that most developers use MacBooks and virtual machines for testing. Eating their dog food isn´t very popular with them. Warren Block already tried to address this, without success. So I wonder less and less why Mr. Vadot wrote a laptop backlight tool while at the same time pushing for removal of support for server-typical hardware. (In reply to Emmanuel Vadot from comment #46) FYI, it is actually _not_ the chipset, but the _logic_ that Matrox sells to OEMs and which is being integrated on silicon by several companies who manufacture server/industrial targeted chipsets. And please also consider restoring at least the xf86-video-ast driver and applying the simple fix shown in comment #29 to make it work again after your decision to remove pci.c without any apparent objective need and not to bother fixing the graphics drivers you rendered dysfunctional with this action, as the aspeed graphics chip is another popular server-only onboard graphics chip being used on currently manufactured server boards, albeit with smaller market share than Matrox. Finally, please also keep in mind that 99% of the typical server users will not complain/post PR's, but just drop FreeBSD and never consider again using it when they notice that it became useless due to the sudden, unexpected removal of essential drivers for current hardware. (In reply to Emmanuel Vadot from comment #48) Years ago, in the mailing list we already had a discussion about your desire to remove SC, and one of the main reasons is that for Nvidia cards suspend/resume only is supported by SC, but not by VT. Confronted by the sheer volume of substantiated protests, you postponed your intent to remove it. Here is the link: https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000468.html I have to admit that I feel disgusted by way you tried to force the removal of the non-Intel/AMD/Nvidia drivers through the backdoor by making them dysfunctional by removing pci.c, and let the users clean up the mess. This all puts up the question whether it is wise making ones' company's existence dependent on an OS that can break at any time because of such things.
(In reply to Stefan B. from comment #50) > Maybe this is because one particularity of FreeBSD is that most developers use > MacBooks and virtual machines for testing. Eating their dog food isn´t very > popular with them. Warren Block already tried to address this, without success. > So I wonder less and less why Mr. Vadot wrote a laptop backlight tool while at > the same time pushing for removal of support for server-typical hardware. Why would I wrote a backlight tool if I used virtual machines and a macbook ? I wrote it because I need to control the backlight on my FreeBSD laptops, is it hard to understand the reason ? > Years ago, in the mailing list we already had a discussion about your desire to remove SC, and one of the main > reasons is that for Nvidia cards suspend/resume only is supported by SC, but not by VT. Confronted by the sheer > volume of substantiated protests, you postponed your intent to remove it. > Here is the link: https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000468.html Why did no one bother working on adding support for suspend/resume for nvidia on vt(4) ? Also are you sure that it's not working at all of is that only for some old generation ? If it's not working at all it means that nvidia users currently don't use uefi (as sc(4) don't support it) and I feel that a bit odd. > I have to admit that I feel disgusted by way you tried to force the removal of > the non-Intel/AMD/Nvidia drivers through the backdoor by making them > dysfunctional by removing pci.c, and let the users clean up the mess. This all > puts up the question whether it is wise making ones' company's existence > dependent on an OS that can break at any time because of such things. Seriously ? First I didn't removed pci.c, I remove an not-upstreamed patch that, at the time, I though useless. And obviously I didn't do it on purpose to "force the removal of he non-Intel/AMD/Nvidia drivers through the backdoor", that's freaking nuts of you to think that.
(In reply to Lena from comment #49) > The video chip GeForce 6150 on my motherboard was supported by x11/nvidia-driver-304, but not anymore. > I had to switch from nvidia to nv and from i386 to amd64. Well, that's one problem when you use hardware from 2004. > I use KOI8-R/KOI8-U locale (as was standard for Russian and Ukrainian when I switched from MS-DOS to FreeBSD) instead of UTF-8. > editors/aee doesn't support Unicode, and to distinguish text files from binary files for migration to Unicode is quite non-trivial and error-prone. > VT requires Unicode locale. So you're not using unicode because of one tool that you use ? > I use 11 virtual SC consoles for everything text, including email (mail/mutt). You want to move everything into X, I don't. Don't force everybody to do everything exactly same as you do. No I want to move everything that uses X to Wayland but that's another story :)
I use nvidia chip (inbuilt into motherboard), and I cannot and don't want to use UEFI. Even if I buy nvidia card for a new motherboard for xgamma(1) to work with nv (because xgamma doesn't work with vesa), why would I prefer UEFI? Text editor is the most important tool for me. You want to force me to break all my habits just because of your whim. And to break my filesystem with iconv a binary file by mistake. Are you a sadist?
> Well, that's one problem when you use hardware from 2004. Do you want to buy me new hardware? And to all other (silent) users.
(In reply to Lena from comment #53) > I use nvidia chip (inbuilt into motherboard), and I cannot and don't want to > use UEFI. Even if I buy nvidia card for a new motherboard for xgamma(1) to work > with nv (because xgamma doesn't work with vesa), why would I prefer UEFI? UEFI is inevitable for newer hardware, so at some point you will need to deal with it. > Text editor is the most important tool for me. You want to force me to break > all my habits just because of your whim. And to break my filesystem with iconv > a binary file by mistake. Are you a sadist? I force you to do nothing, just keep in mind that you are the one insisting on using non-unicode supporting tool while all the world have moved to unicode a long time ago.
> while all the world have moved to unicode a long time ago. Don't talk for all the world.
> I force you to do nothing Don't destroy SC.
People, please stay professional and gentle with each other. A solution to the missing Matrox video driver was already proposed in comment #46) "Anyway, I'll restore this driver soon-ish."
This is from a new R760xs server acquired directly from Dell in the beginning of this year: # pciconf -lv | egrep -A4 ^vga vgapci0@pci0:3:0:0: class=0x030000 rev=0x04 hdr=0x00 vendor=0x102b device=0x0536 subvendor=0x1028 subdevice=0x0b9e vendor = 'Matrox Electronics Systems Ltd.' device = 'Integrated Matrox G200eW3 Graphics Controller' class = display subclass = VGA Is this "ancient hardware" already?
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=29ca44b9b5b8893d4a80b3053fa40756303668b2 commit 29ca44b9b5b8893d4a80b3053fa40756303668b2 Author: Emmanuel Vadot <manu@FreeBSD.org> AuthorDate: 2024-08-01 13:32:52 +0000 Commit: Emmanuel Vadot <manu@FreeBSD.org> CommitDate: 2024-08-01 13:34:26 +0000 x11-drivers/xf86-video-ast: Fix pci access after df10dcefa427 Sponsored by: Beckhoff Automation GmbH & Co. KG PR: 270509 x11-drivers/xf86-video-ast/Makefile | 2 +- .../files/patch-src_ast__driver.c (new) | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=6e5bffcde1c9f14f2348556bccb9c1a9d557c7b7 commit 6e5bffcde1c9f14f2348556bccb9c1a9d557c7b7 Author: Emmanuel Vadot <manu@FreeBSD.org> AuthorDate: 2024-08-01 13:31:01 +0000 Commit: Emmanuel Vadot <manu@FreeBSD.org> CommitDate: 2024-08-01 13:34:19 +0000 x11-drivers/xf86-video-mga: Restore port This hardware is still present on server hardware. Sponsored by: Beckhoff Automation GmbH & Co. KG PR: 270509 x11-drivers/Makefile | 1 + x11-drivers/xf86-video-mga/Makefile (new) | 16 ++++++++++++++++ x11-drivers/xf86-video-mga/distinfo (new) | 3 +++ .../files/patch-src_mga__dac3026.c (new) | 15 +++++++++++++++ .../files/patch-src_mga__dri.c (new) | 22 ++++++++++++++++++++++ .../files/patch-src_mga__driver.c (new) | 19 +++++++++++++++++++ x11-drivers/xf86-video-mga/pkg-descr (new) | 1 + x11-drivers/xf86-video-mga/pkg-plist (new) | 2 ++ 8 files changed, 79 insertions(+)
I am very pleased to report that xf86-video-mga version 2.0.0_5,3 that I just got from the pkg repository for 14.1 works on my system.
A commit in branch 2024Q3 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=810c909c9e3325cae336761073ca8e2d5c070bfa commit 810c909c9e3325cae336761073ca8e2d5c070bfa Author: Emmanuel Vadot <manu@FreeBSD.org> AuthorDate: 2024-08-01 13:31:01 +0000 Commit: Emmanuel Vadot <manu@FreeBSD.org> CommitDate: 2024-08-05 07:17:05 +0000 x11-drivers/xf86-video-mga: Restore port This hardware is still present on server hardware. Sponsored by: Beckhoff Automation GmbH & Co. KG PR: 270509 (cherry picked from commit 6e5bffcde1c9f14f2348556bccb9c1a9d557c7b7) x11-drivers/Makefile | 1 + x11-drivers/xf86-video-mga/Makefile (new) | 16 ++++++++++++++++ x11-drivers/xf86-video-mga/distinfo (new) | 3 +++ .../files/patch-src_mga__dac3026.c (new) | 15 +++++++++++++++ .../files/patch-src_mga__dri.c (new) | 22 ++++++++++++++++++++++ .../files/patch-src_mga__driver.c (new) | 19 +++++++++++++++++++ x11-drivers/xf86-video-mga/pkg-descr (new) | 1 + x11-drivers/xf86-video-mga/pkg-plist (new) | 2 ++ 8 files changed, 79 insertions(+)
A commit in branch 2024Q3 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=898cd9b1435203590d214138cf2b45197ddb9141 commit 898cd9b1435203590d214138cf2b45197ddb9141 Author: Emmanuel Vadot <manu@FreeBSD.org> AuthorDate: 2024-08-01 13:32:52 +0000 Commit: Emmanuel Vadot <manu@FreeBSD.org> CommitDate: 2024-08-05 07:17:05 +0000 x11-drivers/xf86-video-ast: Fix pci access after df10dcefa427 Sponsored by: Beckhoff Automation GmbH & Co. KG PR: 270509 (cherry picked from commit 29ca44b9b5b8893d4a80b3053fa40756303668b2) x11-drivers/xf86-video-ast/Makefile | 2 +- .../files/patch-src_ast__driver.c (new) | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-)
BTW: it can help to submit a dmesg of your servers at https://dmesgd.nycbug.org/index.cgi . So this list can be used to see what hardware is running FreeBSD.