FreeBSD odstranilo poslední GPL kód ze základního systému. Konkrétně dpv, libdpv, libfigpar a dialog. Instalátor před čtyřmi lety přešel z dialogu na bsddialog.
Sociální síti 𝕏 (dříve Twitter) má dnes 20 let. Pro veřejnost byla zpřístupněna 15. července 2006.
Insula Faktury je open source generátor faktur, který běží přímo ve webovém prohlížeči. Žádná registrace, žádné sledování, žádné omezení. Zdrojové kódy jsou k dispozici na Codebergu.
První Mobile Linux Hackday v Plzni, tj. komunitní setkání věnované Linuxu na mobilních zařízeních, proběhne 24. července od 10:00. Akce je otevřená všem zájemcům – od zvědavců po zkušené vývojáře. Dopoledne proběhnou přednášky Davida Heidelberga a Petra Hodiny o aktuálním stavu mobilního Linuxu: proč vůbec chtít tučňáka v kapse, jaké telefony jsou dnes dobře podporované a co taková podpora obnáší. Po obědě se zaměříme na konkrétní
… více »3D software Blender byl vydán ve verzi 5.2 s prodlouženou podporou. Videopředstavení na YouTube.
SketchForge 3D (GitHub, reddit) je open source 3D editor / CAD běžící ve webovém prohlížeči bez nutnosti účtu nebo cloudového úložiště. Inspirovaný byl Tinkercadem. Doporučena je lokální instalace.
Byla vydána nová verze 11.9 webového prohlížeče Midori (Wikipedie, GitHub). S novým centrem ovládání, pokročilejším blokováním reklam, optimalizací výkonu…
Na Crowd Supply běží kampaň na podporu open source čtečky elektronických knih Open Book Touch. Postavena je na ESP32-S3. Má 4,26palcový dotykový e-papírový displej s rozlišením 480×800 pixelů, podsvícení, slot na microSD kartu. Cena je 149 dolarů a poštovné 12 dolarů. Dodání je plánováno na duben 2027.
Na Humble Bundle běží akce Linux: All the Things by O'Reilly a Picos, HATs, and More by Raspberry Pi Press. Elektronické knihy lze koupit se slevou a současně podpořit organizace Code for America a Raspberry Pi Foundation.
FreeCAD (Wikipedie), tj. svobodný multiplatformní parametrický 3D CAD, má nový vtipný a současně užitečný doplněk Banana For Scale (GitHub). Aktuálně umožňuje do výkresu vložit banán nebo plechovku pro porovnání a určení měřítka.
ip -s -s link show dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb qlen 1000
link/ether 00:1d:92:23:6b:fe brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
747473035 103966270 9 0 0 0
RX errors: length crc frame fifo missed
0 0 0 9 13326
TX: bytes packets errors dropped carrier collsns
4222548359 108744074 0 0 0 0
TX errors: aborted fifo window heartbeat
0 0 0 0
Google toho moc neví, někde jsem našel vysvětlení, že se obě strany linky nedokáží domluvit na rychlosti. Tohle jsem vyloučil postupnout výměnou: Routeru (HW i OS), kabelu, switche. Vše je jiné.
Jediný problém může být v softu. Proběhla změna OS z Fedora4 na CentOS 5.0. Routování (staticky cca 100 cest), nastavení rozhranní, shaping (htb) zůstalo stejné.
Na daný packet loss nemá vliv: vypnuté shapování (tc qdisc del root), vypnutý fw (iptables -F), ani trafic. Začínám mít pocit, že mi tam straší
Dotazy:
Co všechno může způsobit chyby v RX Error Missed?
Jak může vzniknout PL na samotném routeru?
Kudy ten kabel vedeš? Neni tam nějaký rušení? Píšeš že si vyměnil OS, zkoušel si jiné jádro resp. jinou verzi ovladače?
136k 118k 136k 139k 136k 139k 142k 22k 200k 20k 172k 136k 118k 136k ...Průměr tedy odpovídá. Ale když v jedné sekundě dojde k výpadku, tak v další přijde dvojnásobek dat. Tedy i data z toho výpadku a klient jede rychlostí vyšší než má v HTB. Kolega paří WOW a říkal, že vše co se "během" výpadku stane mu přijde (a od něj odejde) o tu sekundu později. Pak to jede opět normálně. Tomu bych u TCP rozumněl, ale proč přijde naráz dvojnásobek dat je mi také záhadou.
ethtool eth1
Settings for eth1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000001 (1)
Link detected: yes
Zkoušel jsi ten switch restartovat ?
Je vyměněn
. Byl tam zcela jiný. Byly tam VLANy, teď je default. Proč si myslíš, že to bude v tom switchi?
Se všemi síťovkami se to chovalo stejně (tedy blbě). Sítovka na to nemá vliv. Celkově bylo vyzkoušeno cca 6 různých kombinací síťovek / switchů. Stále stejné (špatné) chování. Tím to nebude. Problém bude v nastavení toho routeru. :- (
Tak Ti mě napadá,jaký trafic jde přes ten router?
cca 10Mb/s. Nadměrná zátěž tu nikde není, vše je měřeno. Ten router se fláká (doufám, že by to load, htop atd ukázal). Počet konektů hluboko pod maximem. Po snížení TCP timetoutu to ještě více kleslo. Ještě doplním, že přímo na tento router není připojeno žádné domácí PC. Jsou na něm servery (nulový trafic, navíc omezeno v HTB) a další routery a až za nimi obyč PC lidí.
A teď mě napadá, co takle odpojit switch od routeru a připojit jen jedno pecko k routeru a zkusit přez něj komunikovat ven ? Víš bez dalších stanic ...
Ano, tohle bude asi jediná možnost. Jenže, po jednom restartu routeru to vydrží třeba dva dny bez jediného vypadlého packetu. Po dalším restartu je loss okamžitý. Odpojit celou síť na dva dny si nemuho dovolit.
Ano, tohle bude asi jediná možnost. Jenže, po jednom restartu routeru to vydrží třeba dva dny bez jediného vypadlého packetu. Po dalším restartu je loss okamžitý. Odpojit celou síť na dva dny si nemuho dovolit.Co by se stalo, kdybys nic nerestartoval, a rovnou místo toho switche bouchnul PCčko o kterém víš, že je vpořádku a pak začal komunikovat přes ten router ven ? Bylo by to s chybama, které uvádíš ? Tím nechci říct, že by switch, ba ani router nebyly OK, ale pokusil bych se alespoň odstranit doměnku, že si ti dva "nepadly" do oka. Já vím, je to taková šamanština , ale co když ... Jinak , já nevím, mě nic jiného momentálně nenapadá ... Dobrou noc :o)
A nějakej debug to neosvětlí, logování s nejvyšší úrovní?
eth1 Link encap:Ethernet HWaddr 00:10:4B:1C:52:0F
inet addr:80.188.227.18 Bcast:80.188.227.23 Mask:255.255.255.248
inet6 addr: fe80::210:4bff:fe1c:520f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10884428 errors:0 dropped:0 overruns:0 frame:0
TX packets:9087140 errors:0 dropped:0 overruns:0 carrier:129
collisions:2632 txqueuelen:1000
RX bytes:1079902235 (1.0 GiB) TX bytes:1594204219 (1.4 GiB)
Interrupt:18 Base address:0xe000
pomohlo nastaveni na 10Mbit:
root@nat:~# ethtool eth1 Settings for eth1: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Full Advertised auto-negotiation: Yes Speed: 10Mb/s Duplex: Full Port: MII PHYAD: 24 Transceiver: internal Auto-negotiation: on Current message level: 0x00000001 (1) Link detected: yespak prestali v ciscu a na eth1 ty kolize ... chybu z dmesg si nepamatuju a pravdepodobne se jednalo o jiny problem, jen stejna sitovka ... Ja nevim, s 3comama, mam vzdy nejakou chybu, zatim co s realtekama za 90 korun ne ...
A nedochazelo ke zpozdeni a ani vypadavani pingu i OpenVPN jela ok ..
root@nat:~# lspci 00:0a.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) 00:0c.0 Ethernet controller: 3Com Corporation 3c900B-TPO Etherlink XL [Cyclone] (rev 04) 00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Procházel jsem i zdrojáky jádra, abych zjistil co to vlastně znamená a nikde nic.Je to deklarované v linux/netdevice.h, resp. linux/if_link.h. Např. ovladač 8139too (drivers/net/8139too.c) mění tento čítač na třech místech. Váš případ bude asi funkce rtl8139_weird_interrupt(), která je volána při přerušení z důvodu chyby (na PCI sběrnici, příjmu poškozeného rámce, přetečení fronty v síťovce). Počítadlu je přičtena hodnota, která se bere přímo z registru na kartě. Takže bych chybu viděl mezi síťovou kartou a switchem. Ujistit se můžete zapnutím ladění v modulu předefinováním symbolu RTL8139_DEBUG na nenulovou hodnotu (linux-2.6.24.3/drivers/net/8139too.c:129).
na PCI sběrnici, příjmu poškozeného rámce, přetečení fronty v síťovce
Díky. Ano, tohle by tomu odpovídalo, zejména chyba v rámci. To stále více to ukazuje na problém switche. Dám tam ještě lepší a uvidím. Zatím pomáhá restart toho switche (pomůže tak na jeden den) a nastavení 100base TX-HD. Vypadá to, že v něm něco přetéká.
Tiskni
Sdílej: