Firefox 73.0.1,1 freezt

Lance

Well-Known Member
Moin,
habe nach dem update einen Freeze beim Staten von Firefox( genaueres siehe unten EDIT) , auch im Terminal freezt es bvor überhaupt weiter was angezeigt wird. Habe auch schon neu installiert und auch neu heruntergeladen (Pkg) als auch unter anderem Nutzeraccount gestartet.

Gibt's ne Möglichkeit, die Vorversion wieder zu bekommen? Versuche es jetzt temporär erstmal mit der ESR Version. Meinen PKG cache hatte ich leider gecleant.

LG Lance

EDIT: Mit Thunderbirds und Firefox-ESR genau das Selbe! >> Es startet nicht und der ganze Desktop freezt. Strg+Alt+Entf und danach Enter fährt aber das aber System herunter.
 
Nur mal so zum Verständnis, in dem Bugreport schreibt einer

"Also, a user not part of 'video' group could start firefox just fine
user in video group always froze up the screen."

Ich bin bei GhostBSD jetzt nicht in der Video Gruppe und es freezte bei mir trotzdem. Bei beiden Nutzern ist das so. (einer staff, einer operator). Zeige ich mir die zugehörigen Nutzer zur Gruppe video an, zeigt er mir lediglich lightdm an.
 
Es kann sein, dass GhostBSD die Rechte anders handhabt. Unter FreeBSD muss man in der Gruppe video sein, um auf die DRM-Devices schreiben zu können. Ist man nicht darin, gibt es keine 3D-Beschleunigung und das Problem triggert nicht.
 
glxgears gibt mir bei meiner Intel HD 3000 (i5-2540M 2,6 GHz) folgende Werte aus:

Code:
294 frames in 5.0 seconds = 58.738 FPS
301 frames in 5.0 seconds = 60.062 FPS
301 frames in 5.0 seconds = 60.064 FPS
301 frames in 5.0 seconds = 60.061 FPS
301 frames in 5.0 seconds = 60.063 FPS
300 frames in 5.0 seconds = 59.863 FPS
301 frames in 5.0 seconds = 60.064 FPS
301 frames in 5.0 seconds = 60.062 FPS

Und Full-HD Filme laufen absolut flüssig.
 
Ich habe mal die 3D Beschleunigung von NVIDIA auf intel/modesetting umgefummelt. Ein mal glxgears gestartet, X friert ein. Kurz gesagt ich kann das reproduzieren. Ich habe den Patch aber nicht getestet sondern wieder zurück auf NVIDIA umgestellt.
 
Mein Notebook zu Hause (mit dem ich den glxgears test gemacht hatte) bekam noch nicht die neuesten Patches ubd ist somit sauber.
Diese Option 4 aus dem Bugreport bedeutet wohl aus den Ports bauen, oder? Ich benutze aber ausschliesslich pkg, so dass ich es wohl aussitzen muss, bis ein Update kommt.
 
Du musst den xorg-server aus Ports bauen. Das war gestern aber in Kombination mit den Latest-Paketen absolut harmlos.
 
Moin !

Hatte hier auch die Probleme. Maus und Tastatur funktionierten nicht mehr.

Habs nicht zum laufen bekommen und mal eine Neu-Installation durchgeführt !
Beim Bau von Xorg die defaults belassen wie Sie sind und wie in pkg-message
beschrieben :

If your kernel is compiled with the EVDEV_SUPPORT option enabled (default starting from FreeBSD 12.1) it is recommended to enable evdev mode in pointer device drivers like ums(4) and psm(4). This will give improvements like better tilt wheel support for mice and centralized gesture support via xf86-input-synaptics or libinput drivers for touchpads.
This is also needed for PS/2 devices to be properly detected by Xorg when moused service is disabled in /etc/rc.conf and kernel is compiled with EVDEV_SUPPORT.
To enable evdev in such a device, run the following:

# sysctl kern.evdev.rcpt_mask=6

To make it persistent across reboots, add the following to /etc/sysctl.conf: kern.evdev.rcpt_mask=6

Der Hund liegt wohl bei dem Schwenk auf udev !?!

Jetzt läuft hier alles fein (Nvidia-Grafik) !

Keinerlei Probleme bei Firefox , mpv .....

Gruss
 

Anhänge

  • xorg_config.png
    xorg_config.png
    13 KB · Aufrufe: 227
Der Patch ist inzwischen im Port angekommen, aber die Option ist standardmäßig abgeschaltet. Um das Selbstbauen wird man also auch mit dem aktualisierten Port nicht drum herum kommen, man muss ihn nur nicht mehr manuell patchen. In dem Bug Report wird aber inzwischen empfohlen sich den Patch komplett zu sparen und LIBGL_DRI3_ENABLE=1 global zu setzen, was viel weniger invasiv ist.
 
Moin !

Hatte hier auch die Probleme. Maus und Tastatur funktionierten nicht mehr.

Habs nicht zum laufen bekommen und mal eine Neu-Installation durchgeführt !
Beim Bau von Xorg die defaults belassen wie Sie sind und wie in pkg-message
beschrieben :

If your kernel is compiled with the EVDEV_SUPPORT option enabled (default starting from FreeBSD 12.1) it is recommended to enable evdev mode in pointer device drivers like ums(4) and psm(4). This will give improvements like better tilt wheel support for mice and centralized gesture support via xf86-input-synaptics or libinput drivers for touchpads.
This is also needed for PS/2 devices to be properly detected by Xorg when moused service is disabled in /etc/rc.conf and kernel is compiled with EVDEV_SUPPORT.
To enable evdev in such a device, run the following:

# sysctl kern.evdev.rcpt_mask=6

To make it persistent across reboots, add the following to /etc/sysctl.conf: kern.evdev.rcpt_mask=6

Der Hund liegt wohl bei dem Schwenk auf udev !?!

Jetzt läuft hier alles fein (Nvidia-Grafik) !

Keinerlei Probleme bei Firefox , mpv .....

Gruss

Wie, jetzt wird standardmäßig nicht mehr das native devd genommen, welches unter FreeBSD und im Zusammenhang mit xorg immer gut funktioniert hat, seitdem endlich von HAL Abstand genommen wurde? Und was ist udev? Ist das nicht wieder so ein Linux-Kram? Aufklärung bitte???
 
LIBGL_DRI3_ENABLE=1
Muss ich dann trotzdem kompilieren?? Wenn ich diese Variable bei /etc/profile setze bleibt mein Problem bestehen, setze ich sie bei ~/.profile bleibt das Problem ebenfalls bestehen und ich muss mein Notebook dann sogar gewaltsam beenden (Powerknopf gedrückt halten). Ziehmlich dumme Situation momentan.
 
Wie, jetzt wird standardmäßig nicht mehr das native devd genommen, welches unter FreeBSD und im Zusammenhang mit xorg immer gut funktioniert hat, seitdem endlich von HAL Abstand genommen wurde?
Es wird weiterhin devd genommen. udev heißt hier nur, dass X.org mit libudev-devd spricht und nicht mit devd direkt. Es wird also nur ein recht schlanker Wrapper zwischengeschaltet. Grund dafür ist wohl, dass die X.org-Entwickler verständlicherweise die Schnittstellen ihrer Software verringern möchten. Statt einem Event-Backend, einem Input-Backend und so weiter pro Plattform soll es eben nur noch libudev für Event, libinput für Input, etc. geben. Die jeweiligen Schnittstellen bereitzustellen ist dann Aufgabe der Plattform und nicht mehr der X.org-Entwickler.
 
Ich bin seit über 2 Std dabei, mir auf ner virtuellen Maschine ein pkg des xorg-servers zu erstellen.

Das ginge ja dann sogar viel schneller, würde ich eine Neuinstallation machen. Brächte diese denn etwas?
 
Ich will einfach nur so schnell wie möglich wieder ein funktionierendes System haben ohne zu kompilieren.
 
Wie langsam ist denn die VM? :) x11/xorg-server zu bauen dauerte vorgestern auf meinem wirklich nicht mehr taufrischen T430s mit seiner Dualcore Low Voltage CPU von 2012 keine 5 Minuten. Aber wenn es hilft, kann ich dir heute Abend gerne ein Paket mit dem gepatchten xorg-server bauen. Jetzt im Moment geht es nur nicht, da ich meine Bürokiste besser nicht update, bis die Schmerzen ausgestanden sind.
 
Jetzt im Moment geht es nur nicht, da ich meine Bürokiste besser nicht update, bis die Schmerzen ausgestanden sind.
Danke, das ist lieb @Yamagi aber ich habe soeben erfahren dass man sich bei GhostBSD auch der Sache annimmt und ebenfalls aktualisierte Pakete bereitstellen will. Nachdem sie getestet werden dürften sie also auch bald online sein.
 
Wie langsam ist denn die VM? :) x11/xorg-server zu bauen dauerte vorgestern auf meinem wirklich nicht mehr taufrischen T430s mit seiner Dualcore Low Voltage CPU von 2012 keine 5 Minuten.
Bis eben immer noch am rödeln, habe ich die Virtuelle Maschine jetzt ausgestellt.
Es handelt sich um ein Ubuntu mit i3 i3-2370M CPU 2.40GHz × 4 und VirtualBox. Ich hatte die Option vdpau und noch eine drüber auch aktiviert. Aber 5 Minuten vs über 3 Stunden das ist doch nicht normal???? Baut er evtl bei mir die ganzen Abhängigkeiten mit die bei dir schon fertig waren? Denn ich hatte auf dem FreeBSD in der VM lediglich exfat gebaut um es dann per pkg add bei GhostBSD zu installieren. Da dauerte das ganze auch locker über eine halbe Stunde oder auch mehr.
 
Wenn ich das richtig verstanden habe, tritt dieses Problem für nvidia-driver Nutzer nicht auf, egal wie der xorg-server Port kompiliert ist?

If your kernel is compiled with the EVDEV_SUPPORT option enabled (default starting from FreeBSD 12.1) it is recommended to enable evdev mode in pointer device drivers like ums(4) and psm(4). This will give improvements like better tilt wheel support for mice and centralized gesture support via xf86-input-synaptics or libinput drivers for touchpads.
This is also needed for PS/2 devices to be properly detected by Xorg when moused service is disabled in /etc/rc.conf and kernel is compiled with EVDEV_SUPPORT.

Also es geht hier nur um "improvements like better tilt wheel support for mice and centralized gesture support via xf86-input-synaptics" was das auch immer genau ist, mit anderen Worten, wenn die alten Peripheriegeräte bisher immer funktioniert haben, und man eine nvidia Karte hat, bekommt man das Problem erst gar nicht?
 
Es handelt sich um ein Ubuntu mit i3 i3-2370M CPU 2.40GHz × 4 und VirtualBox. Ich hatte die Option vdpau und noch eine drüber auch aktiviert. Aber 5 Minuten vs über 3 Stunden das ist doch nicht normal???? Baut er evtl bei mir die ganzen Abhängigkeiten mit die bei dir schon fertig waren? Denn ich hatte auf dem FreeBSD in der VM lediglich exfat gebaut um es dann per pkg add bei GhostBSD zu installieren. Da dauerte das ganze auch locker über eine halbe Stunde oder auch mehr.
Ich habe es nun mit allen Abhängigkeiten durch Poudriere geschoben. Das dauerte auf dem doch recht schnellen Ryzen 3700X immerhin noch gute 20 Minuten, wovon ein Großteil für meinen ganz besonderen Freund llvm drauf ging. Also kann es mit allen Abhängigkeiten auf einem auch nicht mehr ganz taufrischen i3 schon einige Stunden dauern.

Das Paket ist hier: https://deponie.yamagi.org/temp/xorg-server-1.20.7_1,1.txz Es ist aus den Ports Revision r527171 gebaut. Die SHA256 Summe ist 22a43b9a13f794135b67bff953d125810cf2dca445892eb6d0d331865e5266c6
 
Zurück
Oben