Firefox 89 időnként ledermed

Fórum: 

Üdv Mindenki!

A Firefox frissítését követően (https://ibb.co/wSzND0C 88.0.1+linuxmint1+tricia -> 89.0+linuxmint1+tricia) kellemetlen újdonsággal szembesültem: időnként "ledermed" a program (kezdetben videózás /youtube/ váltotta ki, de most már elég hozzá bármilyen oldal, ha úgy tartja kedve, akkor beáll). Ilyenkor semmire nem reagál, illetve a tálcára le tudom helyezni a megnyitott oldalt, de utána már nem tudom visszavarázsolni az asztalra (https://ibb.co/87m7yh8), csak a bezárás funkció működik, akkor pedig bedob egy ablakot (https://ibb.co/jzmwfyV), mely az ablak elfoglaltságára hivatkozik, mint a jelenség vélhető oka.

Mivel a korábbi verziók használata során ilyet nem tapasztaltam (van esetleg valaki, aki belefutott ilyesmibe közületek?), így arra gondoltam, hogy visszatérnék a korábbi kiadásra (88.0.1+linuxmint1+tricia) és azzal bekkelném ki az időt addig, amíg nem jelenik meg egy újabb frissítés (bízva abban, hogy az megoldja a problémát).

Kutakodtam a lehetőségeket illetően és ezt találtam: https://hup.hu/node/136059

Esetemben valahogy így kellene kinéznie a parancsok sorának:

sudo apt-get purge firefox
apt-cache show firefox | grep Version
sudo apt-get install firefox=88.0.1+linuxmint1+tricia
sudo apt-mark hold firefox

Sajnos már a 2. parancs után bukó a dolog, mert a kimenetben nem szerepel az áhított verzió (az elsőt nem adtam ki, nem töröltem a Firefoxot, csak a verziólistát kérdeztem le):

apt-cache show firefox | grep Version
Version: 89.0+linuxmint1+tricia
Version: 89.0+build2-0ubuntu0.18.04.2
Version: 59.0.2+build1-0ubuntu1

Azért tettem egy próbát és kiadtam a 3. parancsot, de hiába (ahogy sejtettem):

sudo apt-get install firefox=88.0.1+linuxmint1+tricia
[sudo] norbi jelszava:              
Csomaglisták olvasása... Kész
Függőségi fa építése       
Állapotinformációk olvasása... Kész
E: „88.0.1+linuxmint1+tricia” verzió nem található ehhez: „firefox”

Fel lehetne varázsolni valahogy ezt a verziót is a fenti listára vagy csak 2 opcióm van és választhatom:
a.) a 89.0+build2-0ubuntu0.18.04.2 verziót:

sudo apt-get purge firefox
sudo apt-get install firefox=89.0+build2-0ubuntu0.18.04.2
sudo apt-mark hold firefox

Okozhatja a problémámat a Mint verziója (Tina /Linux Mint 19.2 Tina/ nem jön ki Triciával /89.0+linuxmint1+tricia/ - bár ez korábban nem volt probléma /88.0.1+linuxmint1+tricia/)?

norbi@norbi-M540R:~$ lsb_release -a
No LSB modules are available.
Distributor ID:    LinuxMint
Description:    Linux Mint 19.2 Tina
Release:    19.2
Codename:    tina

b.) a 59.0.2+build1-0ubuntu1 ősverziót és ezt tudnám a kívánt változatra frissíteni valahogy.

A válaszokat előre is köszönöm!

 

közben "mesés" volt a net

#249

Ezt én sem bánom, az elmúlt 2 napban jól teljesített, így gondolom megoldották a problémát. A hónap közepe táján aktuális egy tervezett karbantartás, már alig várom :-))

Értékelés: 

0
Még nincs értékelve

közben "mesés" volt a net

#251 Nem ajánlom, csak megemlítem ezt az oldalt: https://gist.github.com/0XDE57/fbd302cef7693e62c769
Vannak benne egész jó oldalak linkjei - és különféle "about:config" beállítási lehetőségek.

Értékelés: 

0
Még nincs értékelve

közben "mesés" volt a net

#252

Köszönöm, átnéztem az oldalt, de úgy láttam, hogy elég haladó beállításokról van szó, illetve van kockázatuk is (, ahogy a szerző is írja: "I am not liable for any damages/loss of data...."), ráadásul a fennmaradó visszajelzésekre, melyeket még időnként tapasztalok, úgy sem jelentenének megoldást (nagy valószínűséggel). A kiindulási problémára (memóriahasználat) már sikerült orvosságot találni, a magánszférám védelmét meg egyelőre letudtam pár korábbi beállítással, meg a Facebook Container, Google Container, illetve az uBlock Origin beélesítésével.

Azért még egyszer köszönöm, lehet, hogy más talál benne olyat, amire pont szüksége van.

Értékelés: 

0
Még nincs értékelve
kimarite képe

[GFX1-]: More than 1 GPU from same vendor... | intel-microcode

#250  Az intel-microcode csomag az Intel processzorhoz kell, azért, hogy nem a BIOS kezelje az eszközöket, hanem a kernel.
Akkor ezzel nagyjából kiváltottuk elviekben a korábban emlegetett BIOS frissítést.

Elvileg igen, de a régi alaplapok erre még nincsenek felkészítve, azaz, ezeknél a BIOS nem minden tekintetben váltható ki a kernel által, azonban lehetséges, hogy valamelyik Firefox frissítés orvosolja a problémát ( [GFX1-]: More than 1 GPU from same vendor detected via PCI, cannot deduce device ), aminek szerencsére a böngésző működésében látható hátránya nincsen. Egészen pontosan be tudtuk állítani a jelenlegi állapotában úgy (2 szál legfeljebb, kikapcsolt hardveres gyorsítás), hogy használható böngészésre, annak minden vonzatával együtt. A hardveres gyorsítás azonban nem lesz bekapcsolható, mert ehhez a CPU integrált videó vezérlőjének (iGP) támogatása is kéne hardveresen vagy szoftveresen. A szoftveres megoldás van bekapcsolva most. Esetleg az Intel talál erre megoldást (szoftveresen):

https://ibb.co/2cLPnhN
https://ibb.co/523prcR
https://ibb.co/fxbnXJY
https://ibb.co/C05nQvG
https://ibb.co/tKdJ3s1
https://linuxmint.hu/comment/48515#comment-48515 )

Persze, erről a régi alaplapokat is értesíteni kéne, de „elakad az információ” :). Nem is értem, miért nem volt telepítve. A rendszer a telepítéskor telepíti az újabb kiadásokon.
Lehet, hogy már olyan régi az alaplap, hogy nem is támogatott a program által és azért nem került telepítésre? Vagy az általam használt régebbi Mint verzió esetén nem települ automatikusan.

Fentebb írom a magyarázatot. Előfordul, hogy nem lehet olyan firmware-t készíteni, amely minden régebbi (elég régi) alaplapot támogat, azért, mert az alaplap csak a a BIOS-sal működik együtt.
Igen, régebbi Linux Mint kiadásoknál az intel-microcode firmware csomag nem települt automatikusan. Az Intel javításai ebbe a csomagba kerülnek bele amúgy, és szinte azonnal, mert a Linux terjesztések készítői először becsomagolják az Intel fejlesztéseit, és a kernelbe is azonnal bekerülnek a fejlesztések (a firmware-ek).

Értékelés: 

0
Még nincs értékelve
kimarite képe

coreboot* | to replace your standard BIOS or UEFI

#254 Egy hírben volt említve a coreboot* projekt. Érdekes, habár nem mélyedtem bele. Jegyzetként...

https://software.intel.com/content/www/us/en/develop/articles/coreboot.html
https://www.coreboot.org/Build_HOWTO
https://doc.coreboot.org/

What is coreboot?

coreboot is an open source firmware alternative which aims to replace your standard BIOS or UEFI. The overall philosophy of coreboot is: Do as much as needed, then jump straight payload. But wait.. what actually is your firmware good for? And what is a payload? Let”s do a short recap before we jump straight into coreboot.

In the book “Embedded Firmware Solutions” by Jiming Sun, Marc Jones, and Vincent Zimmer, firmware is defined as following: “Firmware is the layer of software between hardware and the OS”.

Firmware in general is a piece of software that runs on a very low level.
https://medium.com/swlh/getting-started-with-coreboot-7ade78327e75

Értékelés: 

0
Még nincs értékelve

[GFX1-]: More than 1 GPU from same vendor... | intel-microcode

#254

"lehetséges, hogy valamelyik Firefox frissítés orvosolja a problémát ( [GFX1-]: More than 1 GPU from same vendor detected via PCI, cannot deduce device ), aminek szerencsére a böngésző működésében látható hátránya nincsen."

Az esély megvan rá, volt már korábban is olyan probléma, ami spontán megoldódott egy frissítés után. A használatot meg nem befolyásolja a gyakorlatban, így ha marad az sem egy nagy érvágás.

"Esetleg az Intel talál erre megoldást (szoftveresen)"

Erősen kétlem, hogy komolyabb erőforrásokat fordítanának arra, hogy egy ilyen régi, kihalóban lévő hardver szoftveres támogatásával bajlódjanak. Azt inkább el tudom képzelni, hogy egy nem túl régi vas is produkál hasonló problémákat és az arra kifejlesztett szoftveres megoldás nekem is gyógyírt jelenthet.

"a kernelbe is azonnal bekerülnek a fejlesztések (a firmware-ek)."

Ebből kiindulva akkor egy kernelfrissítés is megoldási mód lehet (különösen azoknál, akik ezt hosszú ideje, pl. a rendszer telepítése óta, mellőzik, ahogy azt én is teszem)?

Értékelés: 

0
Még nincs értékelve

coreboot* | to replace your standard BIOS or UEFI

#255

Átfutottam az olvasnivalót (az értelmezését a hiányos angoltudásom, különösen a szakszókincsem hiánya nem könnyítette meg ugyan), megnéztem, hogy mi a helyzet az alaplapommal (https://coreboot.org/status/board-status.html), nem nagyon találtam meg a listán (az volt a benyomásom, hogy fiatalabb példányokkal próbálkoztak eddig), így arra gyanakszom, hogy nem sokan szereztek vele kapcsolatban ilyen jellegű tapasztalatokat, melyekből megerősítést nyerhetnék arra vonatkozóan, hogy esetemben is megérhet egy próbát ez a módszer is. Jobban belemélyedve a témába, azt szűrtem le, hogy tulajdonképpen egy egyedi, személyre/gépre szabott "BIOS"-ról van szó, mely megalkotása elég haladószintűnek tűnik számomra, és erősen magában rejti a vagy működik, vagy nem kockázatot, így tényleg csak érdekességként tekintek rá. A kísérletező hajlamú egyének számára tök jó lehet, főleg ha van 1-2 régi, feláldozható gépük, amivel "eljátszadozhatnak", esetleg olyan más módon (pl. AMD processzorok/videokártyák és a Linux nem mindig felhőtlen kapcsolata miatt) meg nem oldható problémával találkoznak, egy fiatalabb géppel kapcsolatban, melyre ez egy jó kezelési módszer lehet.

Értékelés: 

0
Még nincs értékelve
kimarite képe

[GFX1-]: More than 1 GPU from same vendor... | intel-microcode

#256 lehetséges, hogy valamelyik Firefox frissítés orvosolja a problémát ( [GFX1-]: More than 1 GPU from same vendor detected via PCI, cannot deduce device ), aminek szerencsére a böngésző működésében látható hátránya nincsen.
Az esély megvan rá, volt már korábban is olyan probléma, ami spontán megoldódott egy frissítés után. A használatot meg nem befolyásolja a gyakorlatban, így ha marad az sem egy nagy érvágás
.

Az esély van meg rá.

Esetleg az Intel talál erre megoldást (szoftveresen)
Erősen kétlem, hogy komolyabb erőforrásokat fordítanának arra, hogy egy ilyen régi, kihalóban lévő hardver szoftveres támogatásával bajlódjanak. Azt inkább el tudom képzelni, hogy egy nem túl régi vas is produkál hasonló problémákat és az arra kifejlesztett szoftveres megoldás nekem is gyógyírt jelenthet.

Nem tudom megmondani, mekkora az esély arra, hogy..., komoly erőforrásokat valószínűleg nem fordítanak külön régi CPU-kra, iGP-kre.

a kernelbe is azonnal bekerülnek a fejlesztések (a firmware-ek).
Ebből kiindulva akkor egy kernelfrissítés is megoldási mód lehet (különösen azoknál, akik ezt hosszú ideje, pl. a rendszer telepítése óta, mellőzik, ahogy azt én is teszem)?

Úgy értettem, hogy amit az Intel újít, arra nem kell várni, bekerül a terjesztésekbe...
Manapság kevesebb támogatást vesznek ki a kernelből, inkább hozzátesznek újakat. Régebben az volt az általános gyakorlat, felfogás, a régi vasakat a régi kernel támogatja, maradjon az. Vélhetően nem Intel firmware szinten, hanem foltozás (patch) terén megoldódhat a géped problémája is. Azaz, semmi sem gátol meg abban, hogy kipróbáld a legújabb stabil kernelt. Ha nem válik be, visszatérhetsz a jelenleg használthoz. Én egy rendszervisszaállítási pontot készítenék a telepítés előtt, mert az új kernel esetleg hoz olyan csomagot, ami a régi kernel működésébe belenyúl, és ami hátrányként is megélhető lehet. Én az általam használt terjesztés által biztosított, a tükrökről származó, legújabb kernelt használom, hátrányát eddig nem éreztem.

echo "### Rendszer, gép és grafika" ; inxi -SMGzxxx ; echo "### Kernel verzió" ; uname -rv ; echo "### Dátum" ; date
### Rendszer, gép és grafika
System:
  Host: debkim Kernel: 5.10.0-0.bpo.8-amd64 x86_64 bits: 64 compiler: N/A
  Desktop: Cinnamon 3.8.8 wm: muffin 3.8.2 dm: LightDM 1.26.0
  Distro: Debian GNU/Linux 10 (buster)
Machine:
  Type: Laptop System: Hewlett-Packard product: HP EliteBook 2570p
  v: A1028C1100 serial: <filter> Chassis: type: 10 serial: <filter>
  Mobo: Hewlett-Packard model: 17DF v: KBC Version 61.20 serial: <filter>
  BIOS: Hewlett-Packard v: 68ISB Ver. F.31 date: 10/01/2012
Graphics:
  Device-1: Intel 3rd Gen Core processor Graphics vendor: Hewlett-Packard
  driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:0166
  Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa
  resolution: 1280x1024~60Hz
  OpenGL: renderer: Mesa DRI Intel Ivybridge Mobile v: 4.2 Mesa 18.3.6
  compat-v: 3.0 direct render: Yes
### Kernel verzió
5.10.0-0.bpo.8-amd64 #1 SMP Debian 5.10.46-2~bpo10+1 (2021-07-22)
### Dátum
2021. aug. 8., vasárnap, 16:58:15 CEST

Nemsokára kijön a Debian 11..., vélhetően váltok arra.

Értékelés: 

0
Még nincs értékelve
kimarite képe

coreboot* | to replace your standard BIOS or UEFI

#257 Én is egy speciális gépcsalád által bejelentett hírt olvastam, csak nem azt közöltem. :)
Nem néztem át, neked mennyire lenne jó megoldás. Még igazad is lehet.

Értékelés: 

0
Még nincs értékelve

Összegezve

#260

Éppen tegnap volt aktuális a biztonsági mentés, így készült egy visszaállítási pont, a Frissítéskezelő Feketelistáján ezek a fájlok voltak (https://ibb.co/0FX63J3 https://ibb.co/gWNXPrV), most telepítésre kerültek. Rendszer újraindítást követően nem látható sem negatív, sem pozitív változás, a memóriafogyasztás hasonló, a megjelenő visszajelzések változatlannak tűnnek, a többi meg majd idővel elválik, egyelőre passzív szemlélő stratégián vagyok :-)

Értékelés: 

0
Még nincs értékelve
kimarite képe

Összegezve

#261 Hm, most nem ugrik be, hogy a „villám” biztonsági frissítés-e. Mindenképpen bízd a rendszerre, mit frissít. Én napi egyszer biztosan frissítek, de, ha jönnek levelek (feliratkoztam) a biztonsági frissítésekről, akkor többször is... :)

Értékelés: 

0
Még nincs értékelve

Összegezve

#262

A "villám" elvileg kernelfrissítést takar és nem biztonságit (nálam azt pajzs jelzi a Frissítéskezelőben és ezeket nem is tartom vissza, a verziófrissítésekkel /felfelé mutató nyíl/ szoktam megvárni egy biztonsági frissítés érkezését és azzal együtt szoktam telepíteni, tehát a kernelfrissítéseket leszámítva mindig elég naprakész vagyok), ezért is voltak eddig feketelistásak (egy másik, korábbi fórumtéma miatt helyeztem őket oda, mivel azt a javaslatot kaptam, hogy ha semmi nem indokolja /hardvercsere, vagy valamilyen hiba/, akkor nem érdemes, életbe vágó folyamatosan frissíteni, jó a bevált régi is). Egy korábbi bejegyzésemben (ennek a végén: https://linuxmint.hu/comment/48593#comment-48593) említettem meg a kernelfrissítést, mint esetleges megoldási módszer, ezt hajtottam most végre (a kép szerint sikeresen: https://ibb.co/CP7WgfD) a feketelistás fájlok telepítésével (eddig a 4.15-ös sorozatból a 4.15.0-54-es volt használatban, most meg a 4.15.0-153-as van, ez a jelenlegi legfrissebb).
Egyébként az eddigi tapasztalatok alapján nem hozott semmilyen változást.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Összegezve | frissítés

#263 Az összes frissítést érdemes mindig telepíteni (biztonsági frissítések vagy egyéb fejlesztések vannak a frissítésekben, ami számodra is fontosak vélhetően), és egyáltalán nem kötelező - nem is alapértelmezett beállítás - beállítani a Frissítéskezelőben, hogy a régebbi kernelek törlődjenek ..., ha van elég szabad hely. Ha van elég szabad hely, logikátlan arról morfondírozni, hogy „túl sok kernel” van telepítve. Mihez képest? Bármikor visszatérhetsz a régebbi kernelhez:

Érdemes időnként akár csak saját magadnak, és nem automatizálva rendszervisszaállítási pontokat készíteni. Ide visszaállíthatod a rendszert vagy egy másik, friss telepítést hozhatsz erre az állapotra.

Értékelés: 

0
Még nincs értékelve

Összegezve | frissítés

#264

Ahogy írtam, a kerneleket leszámítva, szorgalmasan telepítek mindent, ahogy nézem a régi kernelek automatikus törlése sincs beállítva, mégis elég foghíjas a telepítettek listája (előző hozzászólásomban látszik a kép, hogy listázva ugyan vannak, de telepítve mégsem, csak a 4.15.0-153 és a 4.15.0-54), nem mintha ez bármi problémát jelentett volna eddig. Azért nem bolygatom egyébként őket (még egy ártalmatlan frissítés erejéig sem), mert volt hozzájuk köthető problémám korábban (https://linuxmint.hu/forum/kernel-frissites-rendszerinditasi-problema), akkor belekóstolhattam a GRUB szerkesztésébe is.
Ami a visszaállítási pontokat illeti, amikor Ubuntut használtam nagyon szorgalmas voltam, frissítések előtt elég gyakran készítettem visszaállítási pontot, mióta Mintet használok, hanyagabb lettem, kezdetben havi egyet csináltam, mostanában meg 2 havonta egyet a Timeshift segítségével, nem ütemezve, hanem manuálisan indítva (mindig van 3 darab, egy a rendszer telepítést és az alapvető beállításokat követően készült, meg megtartom mindig a 2 legfrissebbet).
A fenti recept eddig elég jól bevált, így nem hiszem, hogy változtatni fogok rajta, ameddig nem kényszerít rá valami a változtatásra.

Egyébként a rendszer jelenlegi állapota kielégítő számomra, a Terminál ablakában látható visszajelzéseket leszámítva (, melyeket már megszoktam és elég ártalmatlanok) kiválóan működik minden (nagyszerű a memóriahasználat és nem is swap-pel), tehát az alapvető célt sikerült elérni, a szépséghibák meg majd megoldódnak maguktól (frissítések, fejlesztők általi javítások segítségével), remélhetőleg.

Értékelés: 

0
Még nincs értékelve

IPC I/O Parent

Történt tegnap egy Firefox frissítés, aminek ez lett az eredménye:

norbi@ALBACOMP:~$ firefox

Úgy néz ki, hogy megoldódott a GPU témaköre is ([GFX1-]: More than 1 GPU from same vendor detected via PCI, cannot deduce device), a frissítés további hatását pedig majd a használat során figyelem.

Némiképp új visszajelzéssel is szembesültem, eddig 1-szer:

[Parent 1538, IPC I/O Parent] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /PROJECT/firefox-91.0+linuxmint1+tricia/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc:19

A kiemelt részt leszámítva (nem tudom, hogy ennek az eltérésnek van-e különösebb jelentősége) a tartalma nagyjából ugyanaz, mint a korábban tapasztaltaké (ezek közül egy példa):

[Parent 2470, Main Thread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /PROJECT/firefox-90.0+linuxmint1+tricia/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc:19

Értékelés: 

0
Még nincs értékelve
kimarite képe

file_descriptor_set_posix.cc | kicsit térjünk ki erre

#266 1) Akár weboldal probléma is lehet. De a cache méretét is lehetne változtatni. A további lehetőségek lentebb.

What to do if file_descriptor_set_posix.cc is down?

If File_Descriptor_Set_Posix is UP but you can’t access the page, try one of the below solutions:

  • Böngésző átmeneti tár. Most popular browsers use page caching to save frequently requested resources on the user’s computer, thus reducing bandwidth consumption and speeding up the browser. To obtain the latest version of the page, ignoring the cache, use the combination Ctrl + F5.
  • A hozzáférés a weboldalhoz nem engedélyezett. If you connect to the Internet via dynamic IP addresses, it’s possible that access to the site for your current IP address was previously blocked. Clear cookies and change your IP address.
  • Antivirus vagy firewall alkalmazás blokkolása. Make sure that the antivirus software or firewall, you may have running on your computer, doesn’t block access to file_descriptor_set_posix.cc.
  • DNS / névfeloldó szerver átmeneti tár probléma. DNS cache contains records of all the recent visits and attempted visits to sites and other Internet domains. For example, if the site has changed its IP address, you will not be able to access it. Clear the DNS cache on your computer and try again.
  • Alternatív DNS szolgáltatás használatával összefüggő probléma. DNS (Domain Name System) converts domain names to IP addresses. Try using an alternative DNS service, other than your ISP’s, for example, OpenDNS or Google Public DNS.

https://file_descriptor_set_posix.cc.updowntoday.com/

2) Illetve lehet most ezt próbálni:

about:config

  • browser.tabs.remote.autostart = false
  • browser.tabs.remote.autostart.2 = false

https://askubuntu.com/questions/1327810/20-04-firefox-not-rendering-or-loading-pages/1327908#1327908

3) én még arra gondolok, valami elfogy.
Kimenetek? (egyben mutatom, hogy nálam, mi a helyzet)

cat /proc/sys/fs/file-max
9223372036854775807
ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 30983
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 95
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 30983
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
ulimit -Hn
1048576
ulimit -Sn
1024

Itt nem mutatom, mutasd te (pasztázva):

cat /etc/sysctl.conf

Értékelés: 

0
Még nincs értékelve

file_descriptor_set_posix.cc | kicsit térjünk ki erre

#267

"Böngésző átmeneti tár"

Az átmeneti tár témájához ez a korábbi kommentem ( https://linuxmint.hu/comment/48052#comment-48052 ), illetve a benne megfogalmazott kérdésem kapcsolódhat:

browser.cache.memory.capacity beillesztése az oldal szűrő mezőjébe, itt az érték valószínűleg -1 (https://ibb.co/L1J30Fq(külső hivatkozás)(külső hivatkozás) ), ezt kell 204800-ra váltani (200MB=204800KB), így megadva a chance-ként felhasználható 200MB-os RAM-területet (https://ibb.co/7v6VgS8(külső hivatkozás)(külső hivatkozás) )

És mégis, ha a Terminálban kiadom a free -h parancsot akkor a kimenetben gazdagon találok a buff/cache alatt 1-1,5G értéket (ez mondjuk nem új keletű jelenség, de most szúrt igazán szemet), pedig a beállítás alapján 200 MB lehetne a max, ha nem tévedek.
 
"A hozzáférés a weboldalhoz nem engedélyezett."

Ebben az esetben, ha jól sejtem, akkor a Firefox nem töltötte volna be az adott oldalt, de ha jól rémlik, akkor semmilyen fennakadás nem volt tapasztalható a böngésző ablakában (ahogy korábban sem, hasonló visszajelzések feltűnésekor), csak a Terminál ablakában jelentek meg a szóban forgó sorok.

"Antivirus vagy firewall alkalmazás blokkolása"

Vírusirtót nem használok, a tűzfal meg ki van kapcsolva (egy korábbi probléma miatt kellett, ha jól emlékszem).

"DNS / névfeloldó szerver átmeneti tár probléma." és "Alternatív DNS szolgáltatás használatával összefüggő probléma"

Ezeket nem tudom kizárni. Töröljem és ha igen akkor hogyan a DNS cache-t? Váltsak OpenDNS-re vagy Google Public DNS-re? Vagy ezekkel még inkább várjunk?

Esetleg az about:config-on belül nem lenne érdemes ránézni, hogy DNS, illetve IPC címszó alatt minden beállítási lehetőség rendben van-e?

A browser.tabs.remote.autostart = false és a browser.tabs.remote.autostart.2 = false beállításokon már korábban túlestünk (itt javasoltad: https://linuxmint.hu/comment/48381#comment-48381 én pedig itt hajtottam végre: https://linuxmint.hu/comment/48392#comment-48392 )

cat /proc/sys/fs/file-max

norbi@ALBACOMP:~$ cat /proc/sys/fs/file-max
395023
norbi@ALBACOMP:~$

ulimit -a

norbi@ALBACOMP:~$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 15475
max locked memory       (kbytes, -l) 65536
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 15475
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
norbi@ALBACOMP:~$

ulimit -Hn

norbi@ALBACOMP:~$ ulimit -Hn
1048576
norbi@ALBACOMP:~$

ulimit -Sn

norbi@ALBACOMP:~$ ulimit -Sn
1024
norbi@ALBACOMP:~$

cat /etc/sysctl.conf: https://paste.ubuntu.com/p/yKhdRTPhkW/

Értékelés: 

0
Még nincs értékelve
kimarite képe

browser.tabs.remote.autostart | browser.tabs.remote.autostart.2

#268 A browser.tabs.remote.autostart = false és a browser.tabs.remote.autostart.2 = false beállításokon már korábban túlestünk (itt javasoltad: https://linuxmint.hu/comment/48381#comment-48381 én pedig itt hajtottam végre: https://linuxmint.hu/comment/48392#comment-48392 )

Igen, de akkor más beállításokat alkalmaztunk. Akkor és most, két helyzet.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Böngésző átmeneti tár | cache

#268   Az átmeneti tár témájához ez a korábbi kommentem ( https://linuxmint.hu/comment/48052#comment-48052 ), illetve a benne megfogalmazott kérdésem kapcsolódhat:
browser.cache.memory.capacity beillesztése az oldal szűrő mezőjébe, itt az érték valószínűleg -1 (https://ibb.co/L1J30Fq ), ezt kell 204800-ra váltani (200MB=204800KB), így megadva a chance-ként felhasználható 200MB-os RAM-területet (https://ibb.co/7v6VgS8 )

Ki lehet próbálni.

És mégis, ha a Terminálban kiadom a free -h parancsot akkor a kimenetben gazdagon találok a buff/cache alatt 1-1,5G értéket (ez mondjuk nem új keletű jelenség, de most szúrt igazán szemet), pedig a beállítás alapján 200 MB lehetne a max, ha nem tévedek.

A free alkalmazás az egész rendszer cache-s memóriafoglalását mutatja. A rendszernek is kell átmeneti tár.

Értékelés: 

0
Még nincs értékelve
kimarite képe

A hozzáférés a weboldalhoz nem engedélyezett.

#268 Ebben az esetben, ha jól sejtem, akkor a Firefox nem töltötte volna be az adott oldalt, de ha jól rémlik, akkor semmilyen fennakadás nem volt tapasztalható a böngésző ablakában (ahogy korábban sem, hasonló visszajelzések feltűnésekor), csak a Terminál ablakában jelentek meg a szóban forgó sorok.

Nem tölt  be az oldal, vagy felhasználónév és jelszó kérés történik. Én belefutottam mostanában mindkettőbe. Ha te nem tapasztaltad, az ok nem ez volt.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Antivirus vagy firewall alkalmazás blokkolása

#268 Vírusirtót nem használok, a tűzfal meg ki van kapcsolva (egy korábbi probléma miatt kellett, ha jól emlékszem).

Mi is volt a tűzfal kikapcsolás oka? Nem mélyedtem bele, írtad volna?

Értékelés: 

0
Még nincs értékelve
kimarite képe

Böngésző átmeneti tár | cache (javítás)

#270 Rosszat írtam. Siettem. Itt ne állíts memória méretet. Az érték -1 vagy 0 lehet.
Magyarázat: http://kb.mozillazine.org/Browser.cache.memory.capacity

Értékelés: 

0
Még nincs értékelve

browser.tabs.remote.autostart | browser.tabs.remote.autostart.2

#269

Ok, de továbbra is false mindkettő, csak jeleztem, hogy ez már korábban beállításra került, így nem ez a jelenség oka.

Értékelés: 

0
Még nincs értékelve

Böngésző átmeneti tár | cache

#270

"Ki lehet próbálni."

Az SSD beépítése óta ez a beállítás, mert része volt az rendszer optimalizálásnak az SSD számára: https://linuxmint.hu/comment/39992#comment-39992

"A free alkalmazás az egész rendszer cache-s memóriafoglalását mutatja. A rendszernek is kell átmeneti tár."

Ok, akkor ez a magyarázat a méretbeli eltérésre.

Értékelés: 

0
Még nincs értékelve

A hozzáférés a weboldalhoz nem engedélyezett.

#271

"Nem tölt  be az oldal, vagy felhasználónév és jelszó kérés történik. Én belefutottam mostanában mindkettőbe. Ha te nem tapasztaltad, az ok nem ez volt."

Ilyen még eddig nem történt, emlékeim szerint és remélem, hogy nem is fog, egyébként mióta frissült a Firefox az egyéb visszajelzésekkel is meglehetősen fukar (javuló tendenciát mutat az eddig sem túl vészes helyzet), nem mintha hiányoznának a korábbiak.

Értékelés: 

0
Még nincs értékelve

Antivirus vagy firewall alkalmazás blokkolása

#272

"Mi is volt a tűzfal kikapcsolás oka? Nem mélyedtem bele, írtad volna?"

Nekem is csak homályosan derengett, hogy valamilyen korábbi problémámmal kapcsolatban került szóba lehetséges kiváltó okként. Utána néztem és a korábbi nyomtatási nehézségekkel kapcsolatban lett megemlítve, de már akkor is kiderült, hogy nem lehetett bűnös, mert már akkor sem volt bekapcsolva (alapbeállításként ki van lőve, és most is így lett hagyva). Bekapcsoljam?

Értékelés: 

0
Még nincs értékelve

Böngésző átmeneti tár | cache (javítás)

#273

Fentebb írtam ( https://linuxmint.hu/comment/48688#comment-48688 ) a változtatás okáról. Most akkor -1 vagy 0 legyen, vagy az SSD kedvére tegyek a jelenlegi beállítással?

Értékelés: 

0
Még nincs értékelve
kimarite képe

browser.tabs.remote.autostart | browser.tabs.remote.autostart.2

#274 Akkor ez így - vélhetően - rendben.
Esetleg kipróbálhatod true beállítással is.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Antivirus vagy firewall alkalmazás blokkolása

#277 Mi is volt a tűzfal kikapcsolás oka? Nem mélyedtem bele, írtad volna?
Nekem is csak homályosan derengett, hogy valamilyen korábbi problémámmal kapcsolatban került szóba lehetséges kiváltó okként. Utána néztem és a korábbi nyomtatási nehézségekkel kapcsolatban lett megemlítve, de már akkor is kiderült, hogy nem lehetett bűnös, mert már akkor sem volt bekapcsolva (alapbeállításként ki van lőve, és most is így lett hagyva). Bekapcsoljam?

Igen. :)

sudo ufw enable

Mert így mindig be lesz kapcsolva.
Lehet, grafikusan is megmarad a beállítás (a rendszer újraindítás után is).
Ellenőrzés:

sudo ufw status

Értékelés: 

0
Még nincs értékelve
kimarite képe

Böngésző átmeneti tár | cache (javítás)

#278 Hagyd így -1 -en, ne bántsuk az SSD-t. El is felejtettem, hogy SSD-ről van szó.

Értékelés: 

0
Még nincs értékelve
kimarite képe

dpkg -l | egrep -i "mesa|i965" | options i915 modeset=1

Ellenőrizzünk bizonyos telepített csomagokat (kimenet):

dpkg -l | egrep -i "mesa|i965"

És egy próba.

echo "options i915 modeset=1" | sudo tee -a /etc/modprobe.d/i915.conf

A parancs lefutása után rendszer újraindítás, és pasztázott kimenet erről.

glxinfo

A modul (options) hatását vizsgáljuk. Bekapcsoljuk.

Jegyzet: https://forums.debian.net//viewtopic.php?t=49881&start=0
https://itectec.com/ubuntu/ubuntu-setting-kernel-options-for-the-i915/
https://feeding.cloud.geek.nz/posts/linux-kernel-module-options-on-debian/

Értékelés: 

0
Még nincs értékelve
kimarite képe

Nem tölt be az oldal: üres | felhasználónév, jelszó kérés

#276   Nem tölt  be az oldal, vagy felhasználónév és jelszó kérés történik. Én belefutottam mostanában mindkettőbe. Ha te nem tapasztaltad, az ok nem ez volt.
Ilyen még eddig nem történt, emlékeim szerint és remélem, hogy nem is fog...

Ha nem tölt be az oldal, úgy értettem, üres lap jelenik meg. Jellemzően akkor történik ilyen, ha a hivatkozás megszűnt a tartalom tekintetében, például egy feltöltött kép törölve lett. Egy példa: http://kepfeltoltes.hu/view/160706/K_perny_k_p___2016-07-06_06-58-00_www.kepfeltoltes.hu_.png . Megnéztem volna, de nincs ott. Ezért kérjük, hogy az Imgur vagy az imgBB kép megosztó oldalakat használja a fórumon mindenki (lehetőleg regisztrációval, és belépve töltse fel a képeket), mert ezeken évek múlva is ott a feltöltött kép, míg sok más képmegosztó portál idővel törli a feltöltött képet. Jó, egy idő múlva megjelenhet egy ilyen üzenet :), amit nem szoktam megvárni:
A kapcsolat időtúllépés miatt megszakadt
A(z) kepfeltoltes.hu helyen lévő kiszolgáló túl hosszú ideig nem válaszol.

A wget alkalmazással sem minden oldalról lehet pl. képet letölteni, de szintén nem találja:

wget kepfeltoltes.hu/view/160706/K_perny_k_p___2016-07-06_06-58-00_www.kepfeltoltes.hu_.png
--2021-08-15 10:01:15--  http://kepfeltoltes.hu/view/160706/K_perny_k_p___2016-07-06_06-58-00_www.kepfeltoltes.hu_.png
kepfeltoltes.hu (kepfeltoltes.hu) feloldása… 195.56.44.48
Csatlakozás a következőhöz: kepfeltoltes.hu (kepfeltoltes.hu)[195.56.44.48]:80… sikertelen: Időtúllépés a kapcsolatban.
Újrapróbálkozás.

Tehát a linkelt tartalom nincs ott, és a fenti oldal nem úgy van beállítva, hogy ilyenkor jelezné, nincs ott semmi, hanem úgy, hogy semmit nem jelez a böngésző felé. Olyan is van, hogy maga a weboldal szűnik meg, ilyenkor vagy az említett üres oldal jön be, esetleg üzenet, hogy mi történt (webes nyelven: például  a 404-es hiba vagy újságoknál: nincs itt a cikk, stb.), vagy egy üzleti ajánlat, hogy vedd meg ezt a domaint. Én az üres oldalra gondoltam...

A fenti a gyakoribb, a felhasználónév és jelszó kérés nagyon ritkán fordul elő, de ha az ember megoldásokat keres és fórumokat böngész, előfordulhat, hogy belefut olykor.

Értékelés: 

0
Még nincs értékelve

Antivirus vagy firewall alkalmazás blokkolása

#280

A sudo ufw enable parancs kiadásával bekapcsoltam.

Értékelés: 

0
Még nincs értékelve

Böngésző átmeneti tár | cache (javítás)

#281

Úgy nézem nem fogalmaztam teljesen világosan :-) A gyári -1 értéket anno - SSD optimalizálási célzattal (, hogy ne bántsam az SSD-t) - módosítottam 204800-ra, ez a jelenlegi beállítás ( https://ibb.co/7v6VgS8 ), így -1-en nem tudom hagyni (max arra változtatni), a fentiek ismeretében akkor ezt a változtatást megtegyem?

Értékelés: 

0
Még nincs értékelve

dpkg -l | egrep -i "mesa|i965" | options i915 modeset=1

#282

dpkg -l | egrep -i "mesa|i965": https://paste.ubuntu.com/p/ZnF4F3Gfhw/

echo "options i915 modeset=1" | sudo tee -a /etc/modprobe.d/i915.conf:

norbi@ALBACOMP:~$ echo "options i915 modeset=1" | sudo tee -a /etc/modprobe.d/i915.conf
options i915 modeset=1
norbi@ALBACOMP:~$

Megtörtént az újraindítás.

glxinfo: https://paste.ubuntu.com/p/RS4FgWxCSt/

 

Értékelés: 

0
Még nincs értékelve

Nem tölt be az oldal: üres | felhasználónév, jelszó kérés

#283

Igazából a visszajelzés ([Parent 1539, IPC I/O Parent] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /PROJECT/firefox-91.0+linuxmint1+tricia/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc:19) megjelenését nem kíséri semmilyen szemmel látható rendellenesség (üres lap, 404-es hiba, felhasználónév és jelszó kérés) a Firefox ablakában, legalábbis eddig nem tűnt fel, minden frankón működik (látszólag), de időnként mégis bedobja, kénye kedve szerint (egyre ritkábban szerencsére, a többi visszajelzés meg szinte el is tűnt már, ha a korábbi gyakorisághoz viszonyítom, egyre többször előfordul, hosszas böngészés során, hogy nem ír ki semmit a Terminál), legutóbb épp akkor, mikor bezártam a böngészőt a gép újraindítása előtt ("A modul (options) hatását vizsgáljuk. Bekapcsoljuk." miatt volt erre szükségem).

Az nem lehet az oka, hogy meg volt nyitva a Mint fórum, be voltam jelentkezve és nem jelentkeztem ki (nem szoktam), mielőtt kinyomtam a böngészőt (eddig nem figyelmet meg, hogy a visszajelzés megjelenése és a Fórum kinyomása között van-e összefüggés)?

Mára búcsúzom, hagylak pihenni.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Böngésző átmeneti tár | cache a RAM-ba (javítás)

#287 Nem fogalmaztál egész világosan. Én azt írtam két lehetőséged van (és több nincs), a 0 értéket beállítva, egyáltalán nincs használva a RAM, mint böngésző átmeneti tár, a -1 értéket beállítva a böngésző a rendelkezére álló RAM-ból számolja ki az átmeneti tárat. Olyan lehetőség nincsen, amit használsz ..., illetve, ebben tévedek (már fáradt voltam tegnap), mégis beállíthatsz pozitív előjelű változót is, de a legmagasabb érték a rendelkezésre álló fizikai RAM mérete lehet, Akkor így lesz jó: mivel 1 MB=1024 KB, ezért 200 MB=204800 KB.
A már linkelt silabusz.
http://kb.mozillazine.org/Browser.cache.memory.capacity
és onnan a magyarázat angolul:

Possible values and their effects

-1

Automatically decide the maximum memory to use to cache decoded images, messages, and chrome based on the total amount of RAM. (Default in all but Thunderbird versions 3.1 or earlier and Minimo).

Physical RAM Memory Cache (in KB)
32 MB 2048
64 MB 4096
128 MB 6144
256 MB 10240
512 MB 14336
1 GB 18432
2 GB 24576
4 GB 30720
8 GB and up 32768

In Firefox 1.5 and SeaMonkey 1.0 and earlier versions, these defaults were the following:

Physical RAM Memory Cache (in KB)
32 MB 2048
64 MB 4096
128 MB 8192
256 MB 14336
512 MB 22528
1 GB 32768
2 GB 45056
4 GB 59392
8 GB 75776

See bug 296538 for details.

0

Do not cache decoded images and chrome in memory.

Any positive integer

Maximum amount of memory in KB to use to cache decoded images and chrome (1 MB = 1024 KB). (Thunderbird default: 4096. Minimo default: 256.) Thunderbird 3.3 will switch to the "-1" default per bug 629247.

És nálad is igaz, hogy a RAM-ba tárazás a true értékkel be lett kapcsolva:
http://kb.mozillazine.org/Browser.cache.memory.enable

browser.cache.memory.enable -> true

És az is igaz, hogy a RAM-ba tárazással, kíméled az SSD-t.
A 200 MB helyett beállíthatsz kevesebbet is, például azt amit a -1 rendel a 4 GB RAM-hoz, amennyi a gépedben van: 59392 (58 MB).

Értékelés: 

0
Még nincs értékelve
kimarite képe

Böngésző átmeneti tár | RAM | about:cache?device=memory

#290 Ellenőrizd, tényleg a RAM-ot használja-e csak a Firefox:

about:cache?device=memory

Ki is tudod, bontani: List Cache Entries

Nálam ezt írja (a true és a -1 beállítással):

Information about the Network Cache Storage Service

  • memory
Number of entries: 155
Maximum storage size: 32768 KiB
Storage in use: 3901 KiB
Storage disk location: none, only stored in memory
List Cache Entries
  • disk
Number of entries: 1862
Maximum storage size: 153600 KiB
Storage in use: 65296 KiB
Storage disk location: /home/debkim/.cache/mozilla/firefox/********.default-release/cache2
List Cache Entries

Értékelés: 

0
Még nincs értékelve
kimarite képe

IPC I/O Parent] WARNING: FileDescriptorSet destroyed ipc/*

#289 Az nem lehet az oka, hogy meg volt nyitva a Mint fórum, be voltam jelentkezve és nem jelentkeztem ki (nem szoktam), mielőtt kinyomtam a böngészőt (eddig nem figyelmet meg, hogy a visszajelzés megjelenése és a Fórum kinyomása között van-e összefüggés)?

Parent 1539, IPC I/O Parent] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /PROJECT/firefox-91.0+linuxmint1+tricia/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc:19

Bármikor, bármilyen weboldalnál megtörténhet. Korábba írtam, ha bezárod a böngésző ablakát, az éppen eindított kommunikáció azt érzékelhet, megszakadt az összeköttetés.

Mára búcsúzom, hagylak pihenni

Neked is jó pihenést! :) ... https://www.youtube.com/watch?v=5cvEVivHVsU

Értékelés: 

0
Még nincs értékelve

Böngésző átmeneti tár | cache a RAM-ba (javítás)

#290

Akkor én egyelőre maradok a jelenlegi (200MB-os) beállításnál az SSD-m védelme érdekében.

Kicsit off a téma, de azért megemlítem (nem mintha nagyon bele akarnék mászni), csak úgy érdekességképpen:

Ma olvasgattam SSD témakörben és más is találkozott hasonló eltéréssel (https://hup.hu/node/171134), mint én (más képet mutat a SMART test és a HDSentinel) korábban ( https://linuxmint.hu/comment/47488#comment-47488 https://linuxmint.hu/comment/47495#comment-47495 https://linuxmint.hu/comment/48374#comment-48374 ), felmerültek megoldási javaslatok is pl. SSD firmware frissítés (azt még nem néztem meg, hogy a jelenleg használtnál van-e újabb) esetleg egy teljes törlés/reset (ez mondjuk teljesítményprobléma esetén volt megoldás, illetve, mivel a Kingstone saját kezelőprogramja nem komázza a Linuxot, így csak ezek a lehetőségek maradtak elméletben: https://serverfault.com/questions/547932/how-to-erase-a-ssd-to-restore-f... https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase ), esetleg lehetne más módon is csekkolni: "... Pendriver-ról bebootolt Live Linux alatt terminálban nézz meg egy sudo smartctl -a /dev/sd[betűjel] parancsot (általában /dev/sda, de az lsblk paranccsal meg lehet nézni), és nézd meg mutat-e hibát a SMART...".

A HDSentinel esetében most vettem észre és furcsának tartom, hogy HDD-ként ( https://paste.ubuntu.com/p/6BzNvshBYF/ : "HDD Device" "HDD Model ID" "HDD Serial No" "HDD Revision" "HDD Size") hivatkozik az SSD-re (ez is erősíti bennem azt a kétséget, hogy totál megfelelő az SSD-k tesztelésére - tudom, hogy ezt már korábban kibeszéltük és Te más véleményen vagy e tekintettben), illetve most ez is szemet szúrt: Interface    : S-ATA Gen3, 6 Gbps. Azt még el tudom képzelni, hogy a meghajtó megfelel ennek a csatlakozási szabványnak, de hogy a gépem nem az 100% (lehet ennek bármi jelentősége a tesztek, illetve az SSD egészsége szempontjából, elképzelhető, hogy egy 10 évvel fiatalabb gépben más eredményeket produkálna?). Azt is érdekesnek találom, hogy ha két HDSentinel tesztet (egy 2021.06.17-én és egy 2021.08.16-án futtatottat) összevetek a hibák értéke (2 hónap eltéréssel is) ugyanaz, azért ennek növekednie kellett volna, olyan mintha a tesztek során rendre ugyanazoknál a feladatoknál nem tudna teljesíteni, ezzel hibát generálva:
Est. lifetime: more than 1000 days
  2000 errors occured during data transfer.
SMART teszt esetén (live változat: https://linuxmint.hu/comment/48374#comment-48374 : https://ibb.co/bWJFwSQ https://ibb.co/275tT53 https://ibb.co/Zg4y1VW ) a hibák okai nem lehetnek a gépem és az SSD közötti kompatibilitásra visszavezethetők (nem a meghajtó a hibás, hanem a géppel nem tud megfelelően együttműködni, illetve a gép nem tudja elvégezni, a korából adódóan, a teszt során teljesítendő feladatokat, így ezt a program hibának jelzi)?

Értékelés: 

0
Még nincs értékelve

Böngésző átmeneti tár | RAM | about:cache?device=memory

#291

08.15.:

Visszatért két régi ismerős:

(firefox:1624): GLib-GObject-CRITICAL **: 17:27:24.409: g_object_ref: assertion 'G_IS_OBJECT (object)' failed

[Child 1872, MediaDecoderStateMachine #1] WARNING: Decoder=7f7156911000 state=DECODING_METADATA Decode metadata failed, shutting down decoder: file /PROJECT/firefox-91.0+linuxmint1+tricia/dom/media/MediaDecoderStateMachine.cpp:366
[Child 1872, MediaDecoderStateMachine #1] WARNING: Decoder=7f7156911000 Decode error: NS_ERROR_DOM_MEDIA_METADATA_ERR (0x806e0006) - static MP4Metadata::ResultAndByteBuffer mozilla::MP4Metadata::Metadata(mozilla::ByteStream *): Cannot parse metadata: file /PROJECT/firefox-91.0+linuxmint1+tricia/dom/media/MediaDecoderStateMachine.cpp:3541

Nagyon úgy fest, hogy ezek Firefox verzióspecifikus jelenségek nálam, legalábbis a második elég valószínű (, de az elsőre is mernék egy komolyabb összeget tenni), mivel firefox-90.0+linuxmint1+tricia esetén volt ( https://linuxmint.hu/comment/48099#comment-48099 ), firefox-90.0.2+linuxmint1+tricia esetén nem, most, firefox-91.0+linuxmint1+tricia használatakor meg megint feltűnt, tehát ezekkel sem biztos, hogy a jövőben érdemes bajlódni (, mire összehoznánk valami működőképeset, addigra egy frissítés nullázná az egész eredményt, a Firefox fejlesztői tudnak ezen bármi maradandót javítani).

08.16.

Information about the Network Cache Storage Service: https://ibb.co/pZRGWWC

A memory és a disk is full ugyanazokat az értékeket tartalmazza, valamint nálam ez látható: Storage disk location:     none, only stored in memory, tehát tényleg csak a RAM-ot használja a Firefox. Kibontottam mindkettőt, ha igényled meg tudom osztani dropbox-on keresztül, de bazi hosszú lista mindegyik.

Amikor az Information about the Network Cache Storage Service memory, illetve disk részét "kibontottam", majd pdf-be akartam "nyomtatni", akkor megint dobálgatta ezt (úgy fest, hogy a Firefoxhoz kapcsolódó pdf-ek váltják ki):

(firefox:1616): GLib-GObject-CRITICAL **: 10:43:04.449: g_object_ref: assertion 'G_IS_OBJECT (object)' failed

Közben a gép/Firefox is ledermedt egy ideig, gondolom sok volt neki az a 2x 300 oldalnyi pdf-é alakítás és kifogyott az erőforrásokból (,bár közben a memóriafogyasztás nem ugrott meg /a htop-on figyelve nem változott az értéke, 1,5-1,6 GB volt/, viszont a proci vagy egyik, vagy másik, vagy mindegyik magja szenvedett rendesen, kiakadt 100%-on).

Nagyon úgy fest, hogy a problémák fő oka a hardverben rejlik (kb. szélmalomharcot vívunk szoftveres fronton), mely már csak szenvedve és kompromisszumokkal tudja teljesíteni a jelen kor kihívásait, úgy ahogy, tehát a lehetőségekhez képest megoldottnak tekinthetem a problémát (memória- swaphasználat), a visszajelzések közül amivel tudtunk azzal elbántunk, a többivel meg meg kell barátkoznom.

Értékelés: 

0
Még nincs értékelve

IPC I/O Parent] WARNING: FileDescriptorSet destroyed ipc/*

#292

Én ezt a felhasználónév- és jelszókérő témával ( https://linuxmint.hu/comment/48707#comment-48707 ) próbáltam bátortalanul párhuzamba állítani, mivel a Fórumon is jelen van jelszó és felhasználónév, így arra gondoltam, hogy egyfajta jogosultsághoz, azonosításhoz köthető jelenség, melyet egy felhasználói fiókból történő kilépés nélküli ablakbezárás is kiválthat.

Mára búcsúzom, holnap meg nem tudom hogy mennyire tudok jelen lenni, mert ma is kínszenvedés volt a nethasználat, holnap meg még karbantartás is lesz :))

Értékelés: 

0
Még nincs értékelve
kimarite képe

Böngésző átmeneti tár | RAM | about:cache?device=memory

#294 A hardveres problémál megoldása szoftveresen olykor nehéz.
A memóriahasználat a RAM-ba megy, rendben, kíméli az SSD-t.

Értékelés: 

0
Még nincs értékelve
kimarite képe

IPC I/O Parent] WARNING: FileDescriptorSet destroyed ipc/*

#295 Nem valószínű, hogy ez okozza a jelenséget.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Google kereső

Nemrég olvastam egy Google keresővel összefüggő problémáról, ami a 91.0.1 és a 92-es FF verziókban javítva lett (előbbit használom pár perce). A Firefox összeomlását okozza az Orca képernyőolvasó használata esetén. Na most, nálad nem omlik a Firefox, és nem használsz szerintem Orca-t, a hibajelenség is más. De a Google kereső van beállítva a böngészőben vagy melyik?
Csak összerakják a legót, a hálózatotokat. :)

Értékelés: 

0
Még nincs értékelve

Google kereső

#298

Alap esetben a Google az a kereső, amit használok, de már egy ideje (1-2 hete), próbaképpen, kacsázok (DuckDuckGo), de semmilyen változást nem vettem észre (, így szerintem vissza is térek rövidesen a Google használatához, mert a Duck nem igazán jött be).
Orca képernyőolvasót nem használok, így ez kizárható.
A nettel én is remélem, hogy kezdenek valamit, mert már kezd idegesíteni, hétfő este (, amikor volt egy jó pillanata a netkapcsolatnak) jeleztem is nekik, hogy nézzenek rá (elvileg kedden volt karbantartásuk a környéken), még nem telt le a 48 óra, de eddig még nem jelentkeztek, illetve tegnap is elég gyalázatos volt a szolgáltatásuk és ma sem sikerült eddig lenyűgözniük, így javítani se sokat javítottak rajta. Most délután csináltam egy-két sebességtesztet, a feltöltési sebesség fullos, a letöltési meg gyalázatos, 150-es a csomag, a minimum 30 lenne, de 13-16 közötti értékeket produkált ( https://ibb.co/8MHtBWK https://ibb.co/mNQxhvc https://ibb.co/hHgGS8Q lehet, hogy a modemmel lesz valami), így ha holnapig nem tesznek csodát, vagy legalább nem adnak életjelet magukról, akkor megy a következő hibabejelentés, a mérési értékekkel együtt, aztán ha nem kapják össze magukat, akkor felvilágosítom őket, hogy elkezdek másik szolgáltató után nézni.

Végezetül egy kis érdekesség:

Tegnap produkált egy érdekes jelenséget videózás közben (egyébként volt egy kernelfrissítés is tegnap /08.17-én/ 4.15.0-154.161-re, nem tudom ennek van-e jelentősége): egyszer csak megállt a kép, a hang ment még egy darabig (gondolom a letöltés a hang esetében előrehaladottabb állapotban van, mint a képanyagé, ezért tapasztalható ez a jelenség a net megszakadásakor), a modem szépen világít, mintha minden OK lenne (egyébként volt már ilyen régebben is, szóval ez eddig még nem lepett meg). Mivel teljes képernyőn volt, így gondoltam, hogy leteszem kicsibe és megnézem, hogy mi a helyzet, az egérre nem reagált, így maradt az Esc (, ha jól rémlik már ilyen is volt). A gép is azt jelezte, hogy rendben van a netkapcsolat (ilyennel is találkoztam már korábban), viszont amikor nyomtam egy frissítést a Firefoxnak, mégsem indult meg az adatmozgás, illetve másik oldalt sem töltött be (próbálkoztam, hátha az adott weboldalnak van valami baja), ergo mégsem volt a valóságban élő kapcsolat. Ilyenkor szokott jönni a kapcsolat bontása, majd ismételt bekapcsolása manuálisan a gépen, esetleg a modem kihúzása, bedugása a konnektorból/ba (volt, amikor csak így talált magára, és csak így kezdte meg a kapcsolódási folyamatot), végül sikerült kicsikarni a kapcsolódást, majd az oldalt lefrissítve elindult a videó. Egy kis idő múltán ismét lejátszódott a fenti folyamat, viszont kiegészült egy olyan (az emlékeim szerint eddig nem tapasztalt) vizuális effekttel, hogy mikor a nethez való kapcsolódás újbóli helyreállítása után újra indítottam volna a videó, nem tudtam, mivel az egérkurzor eltűnt abban a pillanatban, amikor a Firefox ablakára ráhúztam (gondolom a teljes képernyős módból is hasonló ok miatt nem tudtam kilépni az egérrel, csak az Esc-vel), a böngésző kezelőfelülete működött normálisan (, így be is tudtam zárni, ez, illetve az ezt követő Firefox újraindítás volt a megoldás), viszont ahol a weboldal megjelent, az teljes egészében vakfolt volt az egér számára.
Ezt nem igazán tudom mire vélni, vagy az adott weboldal hibája a jelenség, vagy a Firefox-hoz köthető, esetleg a netkapcsolattal van valamilyen összetettebb probléma (pl. modem hiba /lehet, hogy egy reset nem ártana neki, de szolgáltatói felhatalmazás, utasítás nélkül nem nyomkodom, nehogy utána meg rinyáljanak/, esetleg a gép és a modem közti kommunikáció nem valami példás. Egy jó ideje nem ritka jelenség, hogy a videók /, ha visszaemlékszem, akkor Videán szereplők voltak ezek is, mint a fenti jelenséget kiváltó is/ pár perc nézés után megállnak, frissíteni kell az oldalt és akkor meg újraindul - ez erősíti bennem, hogy weboldal-specifikus a jelenség), mindenesetre a jelenség közben szépen szórta a Terminál a korábbról ismert és adatátviteli problémákra utaló visszajelzéseket.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Google kereső | [Parent 21497, IPC I/O Parent] WARNING: FileDesc

#299 Köszi. Közben kiderült, az Orca indítása is kell az összeomláshoz, ez akkor nálad kizárva.

Érdekes dolgot tapasztaltam. A hordozható Firefox könyvtárat átmásoltam az opt könyvtárba (egy teszt miatt).

Amikor a fájlkezelővel másoltam be az opt könyvtárba a firefox-stable könyvtárat, akkor én maradtam a tulajdonosa (ez normális), viszont nem tudtam rekurzívan átállítani a könyvtár tartamát a root felhasználóra (fájlkezelővel, admin joggal), próbáltam, de nem érvényesült rekurzívan, azaz minden fájlra és könyvtárra, maradt a tulajdonos a felhasználó. És így egy olyan jelenséget tapasztaltam, mint te:

/usr/local/bin/firefox-stable
...
[Parent 21497, IPC I/O Parent] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /builds/worker/checkouts/gecko/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc:19

###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost

Azonban, ha a cp másolást használtam - és maradtam ennél a teszthez - rekurzívan a root lett minden tekintetben a tulaj - ami a frissítés érvényesítésének akadálya lehet mellesleg -és nem jelentkezett az IPC-s üzenet, csak az ablak bezárása miatti logikus üzenet:

/usr/local/bin/firefox-stable

###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost

Gondolkodom, nálad, azaz telepített Firefoxnál mi lehet a gond, hol kéne nézelődni.
Tájékoztatás: az /usr/local/bin/firefox-stable szimbolikus link az opt könyvtárban található Firefox indítóra, binárisra.

Értékelés: 

0
Még nincs értékelve

Oldalak