Experienţe hardware/software mai neobişnuite...

Sa nu fim absurzi, daca ma car cu un laptop dupa mine si in 2 dintre locuri (la birou si acasa) cuplez si 1-2 monitoare externe...
Nu stiu cum lucreaza altii dar eu am docking conectat la monitor extern (+mouse si tastatura dedicate) si la birou si acasa, nu lucrez direct pe display-ul laptop-ului decat daca sunt undeva unde nu am monitor extern si nu poate astepta pana ajung la birou/acasa. Evident, in cazul meu asta este din cauza ca sunt chior si d-asta folosesc monitoare 34'+ peste tot pe unde pot.
 
Câți oameni cunoști?
La mine pe plantatie sunt peste 2000 de oameni in campus. In majoritatea locurilor (sau birourilor) sunt doua monitoare, unul conectat prin USB-C si celelalt prin DP de primul.
Nimeni nu are probleme.
 
La mine era software, adică era fuzzy și în screenshots. Și testat și hdmi/displayport direct, și prin dock. Acum 99% din docking stations sunt doar port replicators cu multiplexoare, adică tot în ieșirile de pe GPU dai.
 
Face docking station-ul o diferență în apariția acestor probleme?
Facea odata, si doar pentru anumite modele. Dar nu mai sunt de actualitate.
Acum USB-C face legea, diferite feluri de adaptoare.
Pentru mine e relativ comod sa bag un USB-C in laptop si sa am si retea legata de monitor de exemplu.
 
O sa verific cand ajung la birou, ca acolo e docking station, acasa monitoarele sunt legate direct la laptop, unul prin adaptor USB-C la HDMI si unul prin HDMI nativ. Dar la birou de obicei inchid ecranul de la laptop, doar acasa il tin deschis ca sa tin Teams pe el, la birou inchid Teams.
 
nVidia hotfix 551.56 rezolva niste probleme de flickering in Edge, la iconul de Copilot in taskbar la Win 11 si alte chestii similare. La mine pare ca le rezolva complet, nu am mai avut nici un fel de probleme de ieri, de cand l-am instalat. Pana la ultima versiune de driver oficiala, 551.23, erau probleme.
 
Rezolva multe, dar nu rezolva problema inghetarii computerului cand e accesat prin RDP pe durata mai lunga cu ceva video care ruleaza pe el. De pilda Youtube.

Cand lucrez pe laptopul de serviciu mai deschid cate un RDP catre desktopul personal si pun muzica de pe YouTube (ex: Bliss - Quiet Letters). Asta pentru ca la desktop e cuplat sistemul audio (DAC, amplificator, boxe Elac) care e mult mai bun decat boxele integrate in laptop. Din cand in cand desktopul ingheata, o data la cateva ore. Nu face asta niciodata cand il folosesc direct, doar prin RDP. Cred ca e legat de driverele nVidia, fac chestia asta de ani de zile si doar de cand am schimbat placa video in desktop, acum vreo 2-3 luni, am problema respectiva.
 
Last edited:
Asus Tinker Board S, un fel de Raspberry Pi 4 cu mai putin suport tehnic (a se citi "deloc") din partea producatorului. Are un RK808, cip de power management si RTC. Evident, RTC-ul n-are baterie conectata, sau macar o mufa, sau macar niste pad-uri. Nu. E strict pentru power management. Tine minte ora pana il scot din priza.
In weekend, sambata dimineata, imi propun sa-i adaung un PCF8563. Cat de greu poate fi? :doh:
Raspuns: :facepalm::facepalm::facepalm:

Ma apuc voiniceste de un kernel ultimul racnet (6.10.0-rc6) cu driver PCF8563. Intr-o ora e gata. Install. Reboot. Merge. Super! (Kernelul, nu RTC-ul! Ce? Credeati ca-i asa simplu?!?)
Pasul 2, instalat un devicetree actualizat. Il iau pe ala care vine cu kernelul. Install. Reboot. Merge. Super!
Pasul 3, instalat un overlay pentru acel RTC. Evident, Asus n-a scris un astfel de overlay. Caut sursele pentru ala de la Raspberry Pi. Nu le gasesc. :mad: Aparent Raspberry le tine secrete.
Le gasesc in schimb pe alea de Asus pentru DS1307. Modific pe-acolo ID-urile, salvez. Caut compilator. Cica exista ceva numit "dtc". Instalez, compilez, instalez, modific extlinux.conf sa incarce overlay-ul, reboot, siiiii... nimic.
Trec pe consola seriala. Reboot. Syslinux nu sufla o vorba despre vreun overlay. Nasol - cand am facut uboot-ul ultima data n-am inclus suport pentru overlay-uri. Sa-mi fie rusine.
Bootez normal, iau uboot la puricat in cautarea optiunii-fantoma. Te-ai astepta sa fie in "Device Tree Control". Nu, nu-i acolo. Este in "Library routines".
Tot cautand optiunea fantoma, am mai dat peste diverse chestii de ajustat/tweak-uit. Build fail. Pierdut 10 ore (neconsecutive) investigand ce anume din ce am schimbat nu-i place. Intr-un final am uboot cu DT overlays. Instalez, reboot, eroare si nu booteaza. "base fdt does not have a /__symbols__ node"
Google si constat ca overlay-ul trebuia compilat cu "dtc -@". Daca va duceti la manual sa cautati -@, n-o sa-l gasiti. E secret. :mad2:
Deci compilez cu -@, instalez, reboot siiiii ... exact aceeasi eroare. Mai compilez de vreo 3 ori ca sa fiu foarte foarte sigur.
Constat ca nu doar overlay-ul trebuie compilat cu -@, ci si .dtb-ul de baza - adica "base fdt" din eroare - sa-mi fie rusine a doua oara! Evident, cand kernelul compileaza .dtb-uri nu le compileaza cu -@, ca doar de ce ar face-o? Oamenii nu folosesc overlay-uri pe toate drumurile. Patch-ul care ar fi permis kernelului sa faca asa ceva* n-a ajuns inca/vreodata sa fie inclus. *Cu niste env vars suplimentare, desigur, doar nu va asteptati sa vedeti optiunea in Kconfig, nu?!?
Dau sa compilez .dts-ul din kernel cu dtc -@ siiii ... "syntax error". Pentru ca .dts-ul din kernel contine #include <ceva.dtsi> iar dtc nu suporta asemena aberatii de-ale kernelului. :bash: Includes se specifica cu /include/.
Asa cum explica cineva binevoitor pe net, dts-urile cu #include trebuie pre-digerate de cpp inainte sa le dai la compilat cu dtc. Daca cumva mi-ar fi venit ideea absolut absurda sa citesc manualul despre cum se compileaza DTS-urile, ghinion, abia daca aminteste ca exista un compilator numit "dtc".
Asadar, pre-procesez .dts-ul si .dtsi-urile incluse, compilez cu -@, instalez si

IN SFARSIT am un RTC functional.
 
Last edited:
E puțină dramatizare aici, probabil e vorba de lipsă de experiență. Dar măcar ai învățat chestii. Good job!

❯ dtc --version
Version: DTC 1.7.0
❯ dtc --help
Usage: dtc [options] <input file>

Options: -[qI:O:o:V:d:R:S:p:a:fb:i:H:sW:E:@AThv]
[...]
-@, --symbols
Enable generation of symbols
[...]
 
Preferam sa nu fie nevoie sa invat chestii.
Cum naiba e posibil ca niste kernel devs (Linus, in principal) sa introduca notiunea de device tree, sa fie facut un standard, si apoi fix device tree-urile din kernel sa fie neconforme?
BTW, am uitat sa precizez: kernelurile v4.ceva aveau capabilitatea de a incarca overlay-uri live, dupa bootare.
 
PC cu linux conectat la Router2 via cablu ethernet. Ping Router2: nu raspunde.
Router2 face bridge (via switch intern) intre PC si Router1, tot pe cablu. Ping Router1: raspunde.
Login ssh pe Router1. Ping Router2: raspunde. Ping PC: raspunde.
Scot adaptoare, fire, etc. si ma conectez pe serial la Router2. Ping PC: nu raspunde. Ping router1: raspunde.
Instalez tcpdump pe Router2. Ping PC -> Router2: vad cum sosesc pachetele prin bridge, vad cum Router2 trimite pachete inapoi.
Instalez tcpdump pe PC:
Ping PC -> Router2: vad cum se trimit pachete pe eth0 si vad cum sosesc raspunsurile! Ping in continuare 100% loss.
Ping Router2->PC: vad cum sosesc pachetele pe eth0, dar raspunsuri nema.

WTF?

Bootez Windows pe PC: Ping Router2: fix aceeasi situatie !!!
 

Attachments

  • IPv4.png
    IPv4.png
    218.4 KB · Views: 2
Last edited:
Dupa o vreme:
Ma gandesc ca o fi ceva in neregula cu placa de retea. Opresc PC-ul sa ma uit la placa si brusc am o revelatie! Am schimbat placa. :facepalm:

Nu ma loghez prea des pe Router2. E mai mult pe post de switch. Dar Router2 are un ARP stocat permanent (cu "ip neigh add <ip> lladdr <mac> ...") al PC-ului, pentru acele situatii cand trebuie sa trimit un wake-on-lan din internet catre PC si nu pot face asta cu broadcast. PC-ul, fiind oprit, nu va raspunde la ARP-urile "who has <ip>?". ARP-ul trebuie sa fie stocat permanent in cache-ul Router2. Cand am schimbat placa de retea ultima data (acum mult timp) am uitat sa modific MAC-ul in cache-ul ARP al Router2. El trimitea raspunsuri la ping catre IP-ul corect, dar cu MAC-ul gresit.

Deci, da. :facepalm:
Numai mie mi se putea intampla.
 
Back
Top