RTSP
Sziasztok! Ffmpeg/mplayer rtsp-n csatlakozik egy kamerához. Probléma nélkül működik több helyen, de az egyik helyszínen minimális adatmennyiség (pár 10 kbyte/s) esetén is akadozik (akár másodpercekre kimarad), pedig se a hálózat, se a gép nem indokolná. Gbit switch, 1 linuxos PC (i3 4GB RAM) + 3 kamera van bedugva, illetve egy optikai gerinc. Nem a sebességgel van gond. Mind a 3 kamera esetén fennáll a hiba. Ugyanolyan típusú, ugyanolyan beállítású kamerák vannak máshol is, és semmi probléma. Kernel: 5.0.25 Kamera: Axis, h264 800x450 [rtsp @ 0x55b1ef50ce20]max delay reached. need to consume packet [rtsp @ 0x55b1ef50ce20]RTP: missed 104 packets Az UDP csomagok folyamatosan jönnek, nincs kihagyás sehol: ... 16:10:27.862584 IP 10.1.1.34.mrt > 10.1.1.30.13548: UDP, length 1400 16:10:27.862704 IP 10.1.1.34.mrt > 10.1.1.30.13548: UDP, length 1400 16:10:27.862705 IP 10.1.1.34.mrt > 10.1.1.30.13548: UDP, length 92 16:10:27.892484 IP 10.1.1.34.mrt > 10.1.1.30.13548: UDP, length 1400 ... Mire érzékeny az rtsp, mit érdemes megnézni? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Boot vár 2 percet
On Wed, 22 Sep 2021, Attila Rajmund Nohl wrote: [ 131.197879] PM: Image not found (code -22) Nincs egy média-adaptered bedugva? Ismerőst halálra szivatta egy üresen bedugott uSD -> SD adapter.. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: USB-RS232 ttyACM
On Wed, 20 Jan 2021, Zidarics Zoltan wrote: ha az udev rules-ban atallitod, az nem jo? Nem biztos, hogy a problémát megoldja. Egyszerre két átalakító van a gépben, és időnként felcserélődnek: Jan 19 17:37:44 x kernel: usb 6-2: pl2303 converter now attached to ttyUSB0 Jan 19 17:37:44 x kernel: usb 4-2: pl2303 converter now attached to ttyUSB1 ... Jan 19 17:41:54 x kernel: usb 4-2: pl2303 converter now attached to ttyUSB0 Jan 19 17:41:54 x kernel: usb 2-2: pl2303 converter now attached to ttyUSB1 Az okára még nem jöttem rá, hogy miért csereberélődik a BUS ID (a júzerek nem cserélgetik), a többi gépben nincs ilyen probléma. Mondjuk azokban egyforma mind, ebben nem: ID 0557:2008 ATEN International Co., Ltd UC-232A Serial Port [pl2303] ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
USB-RS232 ttyACM
Sziasztok! Tudtok ajánlani típust/gyártót USB-RS232 átalakítóra, ami ttyACM-nek látszik, és nem ttyUSB-nek? Volt egy ilyenem csak beépült valahová. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
mountpoint+
On Tue, 22 Dec 2020, Szima Gábor wrote: Pl. a /mnt -re fel van csatolva mondjuk a /dev/sdc1, viszont én az eredeti, csatolás előtti tartalmát szeretném megnézni, illetve módosítani. (ext4) Pontosítás: nem lehet umountolni és átmozgatni, mivel használatban van. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
mountpoint
Sziasztok! Hogyan lehet benézni egy olyan könyvtár "alá", amelyre valami már fel van mountolva? Pl. a /mnt -re fel van csatolva mondjuk a /dev/sdc1, viszont én az eredeti, csatolás előtti tartalmát szeretném megnézni, illetve módosítani. (ext4) -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Forgalom megáll 5 másodpercekre, Kubernetes/Docker környezetben
On Mon, 27 Jan 2020, Attila Rajmund Nohl wrote: az interaktív session is meg-megáll (nagyon hosszúnak t?n?) másodpercekre, szóval el?sz?r azt hittem, hogy csak a távoli tesztlaborba vezet? VPN szakadozik, de úgy látszik, a helyi hálózat sem jó. Egyel?re a google nem segített, a külföldi kollégák sem. Lehet értelmesen tovább debug-olni? Még a szoftver oldalán is futtathatok tcpdump-ot, hátha ott látszik valami... Valakinek van ötlete, mi okozhatja? VMware? Hasonlóval sz*ptam pár éve. Ott 5 percenként 20 másodpercig ethernet freeze, majd kismillió csomag egyszerre beesett. Megoldást nem tudom, aki csinálta a gépet valamit kalapált rajta. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
PXE initrd
Sziasztok! Initrd nélkül szépen működik egy PXE boot, ami szükséges a root-NFS mountig az a kernel image-ben benne van (eth, fs, NET, stb.). Kernel param: ip=bootp root=/dev/nfs Viszont egy ismert driver/hálókártya (BCM57780) bug miatt néhány gépnél nem jó, ha a driver (broadcom, tg3) a kernel image-ben van, hanem ki kell tenni modulba, és megfelelő sorrendben kell berántani, különben nem találja meg azt. Készítettem erre egy initrd-t, amely tartalmazza a modult. Be is tölti, látja a hálókártyát, viszont annak még IP-t is kellene adni (IP:kernel level autoconfiguration - ip=bootp) alapján. Na itt akadtam el. Valakinek van ötlete rá, merre induljak el? Szóval eth driver betöltésekor kapja meg a kernel paraméterként kapott IP-t. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: VM+NFSD bug
On Mon, 30 Jul 2018, Ferenc Wágner wrote: Szima Gábor writes: Hogyan lehetne megtrace-elni? Például tcpdump/wireshark. Nem hiszem hogy sokat látnánk, mert szerver oldalról ugyanaz lesz (szerintem) minden, viszont hogy milyen állapotban érkeznek meg a csomagok a kliensre, azt nem mondja meg a tcpdump. Most találtam egy ilyen opciót: nfsrootdebug, kipróbálom. Initramfs csatolná fel az NFS rootot, vagy közvetlenül a kernel? MTU probléma nincs? A kernel. ip=bootp root=/dev/nfs nfsroot=,vers=3 rw -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
VM+NFSD bug
Sziasztok! Futottatok már bele VM-es Linuxon futó NFSD bugba? Konkrétan PXE boot során próbálná felcsatolni a terminál a root-ját, a szerver log szerint minden OK, viszont látszik, hogy fél percenként retry megy (6x), majd a kliens elpánikol (no root device). Közben semmi különös, látszik, hogy megkapta az összes szükséges paramétert, IP, GW, DNS, BOOTP/TFTP, stb. A terminál ping, az export könyvtár "élő" gépről felcsatolható és hiba nélkül elérhető rajta minden. Natív vason ugyanaz az image rendben működik, illetve (igaz régebbi kernellel, de VM alatt sem) sosem futottam bele ilyen hibába. Szerver log: Jul 30 15:12:21 peter rpc.mountd[57545]: authenticated mount request from 192.168.0.153:722 for /tftpboot/hosts/term1 (/tftpboot/hosts/term1) Jul 30 15:12:43 peter rpc.mountd[57545]: authenticated mount request from 192.168.0.153:723 for /tftpboot/hosts/term1 (/tftpboot/hosts/term1) Jul 30 15:13:11 peter rpc.mountd[57545]: authenticated mount request from 192.168.0.153:955 for /tftpboot/hosts/term1 (/tftpboot/hosts/term1) Jul 30 15:13:48 peter rpc.mountd[57545]: authenticated mount request from 192.168.0.153:987 for /tftpboot/hosts/term1 (/tftpboot/hosts/term1) Jul 30 15:14:35 peter rpc.mountd[57545]: authenticated mount request from 192.168.0.153:902 for /tftpboot/hosts/term1 (/tftpboot/hosts/term1) Jul 30 15:15:22 peter rpc.mountd[57545]: authenticated mount request from 192.168.0.153:724 for /tftpboot/hosts/term1 (/tftpboot/hosts/term1) Aztán pánik. A kb. fél perces intervallum miatt DNS-re gyanakszom, de azt nem hinném, hogy használja a kliens, a másik, hogy az rendesen működik. Hogyan lehetne megtrace-elni? Egyébként 64bit, 3.16.6 kernel, nfs-kernel-server-1.3.0-4.4.1.x86_64 -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: PDF recrypt
Szia! On Mon, 28 May 2018, Veres Lajos wrote: pdftk? apt-cache show pdftk|grep -i crypt - Decrypt input as necessary (password required) - Encrypt output as desired Köszi, erre gondoltam! -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
PDF recrypt
Sziasztok! Linux alá tudtok ajánlani PDF decrypt+encrypt programot? Ami képes batch-ban is dolgozni (paraméterezni lehet hogy kérje be a 2 jelszót/vagy paraméterben lehessen azt megadni). -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: akonadi adatbazismotor frissites
On Mon, 19 Mar 2018, Kosza Antal wrote: Van valaki, aki sikeres akonadi frissítést hajtott végre postgresql adatbázissal. Jelen esetben 9.6-os postgrseqlről 10.3-ra kellene (debian testing). Adatok migrálása feltétlenül fontos (dump-restore). - 9.6 adatokat dumpolod (egyenként vagy pg_dumpall) - data könyvtárat kiüríted - 10.3-at felteszed - inicializálod a data könyvtárat (az install script ezt lehet megteszi,nem tudom, én forrásból telepítek) - visszateszed az adatbázisokat -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: CUPS+ULD 64bit - megoldva
On Tue, 13 Mar 2018, Szima Gábor wrote: uld_V1.00.39_01.17 -el is bugos. Itt találtam rendesen működő drivert: http://www.bchemnet.com/suldr/suld.html http://www.bchemnet.com/suldr/driver/UnifiedLinuxDriver-4.01.17.tar.gz Nem egy új darab (2012), de rendesen teszi a dolgát. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
CUPS+ULD 64bit
Sziasztok! CUPS 1.4.6 + uld_v1.00.36_00.91 32 bit (SuSe11.4) alatt rendesen ment egy Samsung SXC-3400 printer, viszont CUPS 1.5.4 alatt ugyanaz a driver 64 bites változata (SuSE 13.2) nem mondanám hogy patent. Néha-néha printel, akkor is rondán, mintha ditherelne, illetve az esetek nagy részében csak a középső 50%-a látszik a nyomatnak, a szélei jó vastagon lemaradnak. Logban semmi furcsát nem látok, szerinte rendben kijött a nyomat. Egy másik gépen is megteszteltem, a probléma ugyanaz. Egy sima PCL (Xerox) printert rádugva az jónak tűnik. uld_V1.00.39_01.17 -el is bugos. Találkoztatok már hasonlóval? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: OpenVPN cert hosszabbítás -> megoldás
On Mon, 28 Aug 2017, Szima Gábor wrote: Azt hiszem megvan a megoldás, és igencsak egyszerű... openssl x509 -in ca.crt -days 3650 -out ca_new.crt -signkey ca.key -sha256 Azután a ca.key -t bármilyen sorrendben le lehet cserélni. Fix: nem a key-t, hanem az új crt-re a régit. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: OpenVPN cert hosszabbítás -> megoldás
On Mon, 28 Aug 2017, Szima Gábor wrote: A szerver cert-ről se feledkezzünk meg, általában egyszerre készül a root certtel: Ez nem árt: ./revoke-full server openssl ca -days 3650 -out server_new.crt -in server.csr -extensions server -md sha256 -config openssl.cnf Aztán a kliensek szép sorban: ./revoke-full client openssl ca -days 3650 -out client_new.crt -in client.csr -md sha256 -config openssl.cnf -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: OpenVPN cert hosszabbítás -> megoldás
On Mon, 28 Aug 2017, Szima Gábor wrote: Csak nem szabad megvárni a cert lejártát, mert utána kakukk. Mármint lejárat után is tudunk újítani, csak akkor már nem épül fel a kapcsolat, így VPN-en nem tudjuk eljuttatni a megújított certeket, csak "lóra, magyar!" módszerrel. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: OpenVPN cert hosszabbítás -> megoldás
Azt hiszem megvan a megoldás, és igencsak egyszerű... openssl x509 -in ca.crt -days 3650 -out ca_new.crt -signkey ca.key -sha256 Azután a ca.key -t bármilyen sorrendben le lehet cserélni. Lehet a szerveren először, majd utána a klienseken szép sorban, vagy fordítva, a meglévő kapcsolatok működőképesek maradnak. Csak nem szabad megvárni a cert lejártát, mert utána kakukk. A szerver cert-ről se feledkezzünk meg, általában egyszerre készül a root certtel: openssl ca -days 3650 -out server_new.crt -in server.csr -extensions server -md sha256 -config openssl.cnf Aztán a kliensek szép sorban: openssl ca -days 3650 -out client_new.crt -in client.csr -md sha256 -config openssl.cnf Kipróbáltam egy vadiúj és egy 10 éves konfiggal és működik. Ez egy hasznos oldal a témában: http://geroyblog.blogspot.hu/2017/01/openvpn-renew-expired-ca-revoke.html Köszönöm mindenkinek a segítséget! -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: OpenVPN cert hosszabbítás
On Sun, 27 Aug 2017, Szima Gábor wrote: Most már csak ebben tér el: Subject/Issuer is eltérő (régi/új): Issuer: C=.., ST=..., L=..., O=Sygma, CN=Sygma CA/emailAddress=sy...@tesla.hu Issuer: C=.., ST=..., L=..., O=Sygma/emailAddress=sy...@tesla.hu CN-t kitöltve: Common Name (eg, your name or your server's hostname) []:Sygma O=Sygma, CN=Sygma/emailAddress=sy...@tesla.hu E helyett: O=Sygma, CN=Sygma CA/emailAddress=sy...@tesla.hu Már csak a CN-t kell szétszedni CA-ra. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: OpenVPN cert hosszabbítás
On Sun, 27 Aug 2017, Szima Gábor wrote: Az "X509v3 extensions:" eltér, az újban nincs benne: X509v3 Subject Key Identifier: X509v3 Authority Key Identifier: DirName:/C=../ST=.../L=.../O=Sygma/CN=Sygma CA/emailAddress=sy...@tesla.hu Ez viszont az újban van csak benne: X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment Ebben eltér (régi/új): X509v3 Basic Constraints: CA:TRUE X509v3 Basic Constraints: CA:FALSE Signature Algorithm: sha1WithRSAEncryption Signature Algorithm: sha256WithRSAEncryption Belenéztem hogyan is csinálja az easy-rsa (pkitool script), így már alakul: openssl req -days 3650 -new -key keys/ca.key -sha1 -x509 -out keys/ca_new.crt -config openssl.cnf Most már csak ebben tér el: Subject/Issuer is eltérő (régi/új): Issuer: C=.., ST=..., L=..., O=Sygma, CN=Sygma CA/emailAddress=sy...@tesla.hu Issuer: C=.., ST=..., L=..., O=Sygma/emailAddress=sy...@tesla.hu -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: OpenVPN cert hosszabbítás
On Sat, 26 Aug 2017, Szládovics Péter wrote: Ha megnézed a két CA-t az 'openssl x509 -in -noout -text' paranccsal, akkor mit látsz? Az "X509v3 extensions:" eltér, az újban nincs benne: X509v3 Subject Key Identifier: X509v3 Authority Key Identifier: DirName:/C=../ST=.../L=.../O=Sygma/CN=Sygma CA/emailAddress=sy...@tesla.hu Ez viszont az újban van csak benne: X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment Ebben eltér (régi/új): X509v3 Basic Constraints: CA:TRUE X509v3 Basic Constraints: CA:FALSE Signature Algorithm: sha1WithRSAEncryption Signature Algorithm: sha256WithRSAEncryption Subject/Issuer is eltérő (régi/új): Issuer: C=.., ST=..., L=..., O=Sygma, CN=Sygma CA/emailAddress=sy...@tesla.hu Issuer: C=.., ST=..., L=..., O=Sygma/emailAddress=sy...@tesla.hu C, ST, L egyezik mindenhol -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: OpenVPN cert hosszabbítás
On Sat, 26 Aug 2017, Szládovics Péter wrote: openssl req -config .cnf -new -key -x509 -days <érvényesség_napokban_pl_3650> -extensions certauth -outform PEM -out -extensions certauth (nálam) nincs, csak v3_ca. Kevés esélyt látok arra, hogy a régi és az új CA fingerprintje azonos legyen. Anélkül meg az új CA elhajtja a vérbe a régi certeket... Hát, kipróbáltam: azonos lett. :) Nekem nem, de ha többször megismételtem ezt a fingerprint mindegyiknél más. Egyébként nem engedte be az újjal. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: OpenVPN cert hosszabbítás
On Sat, 26 Aug 2017, Szládovics Péter wrote: A régi CA hogyan készült? easy-rsa 2.0/build-ca -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: OpenVPN cert hosszabbítás
On Sat, 26 Aug 2017, Vasas, Krisztián wrote: On 2017-08-26 15:49, Szima Gábor wrote: On Thu, 24 Aug 2017, Szládovics Péter wrote: Szerintem nem új tanúsítvány generálásáról van szó, hanem megújításról. Ahhoz viszont elég, ha megvana régi CSR fájl, vagy csinálunk egy ugyanolyat a régi privát kulcs megadása mellett - azaz nincs -newkey, hanem -inkey van. Aztán aláírjuk - mindezt persze csak azután, ha a régit előbb visszavontuk. Igen, erről van szó. Tudsz ajánlani ehhez egy step-by-step leírást? Szóval hogy mi a teendő, amikor - a ca.crt kezd lejárni - a cliensek crt-i kezdenek lejárni Ha a CA is kezd lejárni, akkor azt is újítani kell, tehát az összes kliensnek el kell juttatni az újat. Viszont - ha jól tévedek - ekkor az összes certet meg kell újítani, lévén az a régi CA-val lett aláírva. Innentől szerintem egyszerűbb, ha nulláról kezded újra, pl Zsiga leírása alapján... Ezzel az a baj, ha több (száz) kliens van, ráadásul azok csak a (még) működő VPN csatornán keresztül érhető el/lehet frissíteni, akkor nem is olyan egyszerű. Ezért lenne fontos egy olyan megoldás, hogy az átmeneti időszakban is működjön a kapcsolat, amíg mindenki megkapja az új certet/kulcsát. Tehát még működik a régi cert, de már van egy újabb, azokat folyamatosan megkapják a kliensek, majd amikor mind lefrissült akkor a régi cert "goto kuka". -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: OpenVPN cert hosszabbítás
On Thu, 24 Aug 2017, Szládovics Péter wrote: Szerintem nem új tanúsítvány generálásáról van szó, hanem megújításról. Ahhoz viszont elég, ha megvana régi CSR fájl, vagy csinálunk egy ugyanolyat a régi privát kulcs megadása mellett - azaz nincs -newkey, hanem -inkey van. Aztán aláírjuk - mindezt persze csak azután, ha a régit előbb visszavontuk. Igen, erről van szó. Tudsz ajánlani ehhez egy step-by-step leírást? Szóval hogy mi a teendő, amikor - a ca.crt kezd lejárni - a cliensek crt-i kezdenek lejárni Köszönöm! -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
OpenVPN cert hosszabbítás
Sziasztok! Tudtok ajánlani egy jó step-by-step leírást OpenVPN cert hosszabbításról? Gugliztam párat, de eddig mindegyik javaslat hibára futott (SSL3_GET_SERVER_CERTIFICATE:certificate verify failed). A lényeg: lassacskán lejáró szerver/kliens cert-eket szeretném megújítani. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: BT8x8 + GA-B150M-D3H
On Sun, 1 Jan 2017, Gabor Gombas wrote: On Sat, Dec 31, 2016 at 10:20:49AM +0100, Szima Gábor wrote: Régebbi BT878/848 PCI kártyákat áttettem egy GA-B150M-D3H alaplapba: a kép össze-vissza ugrál, akadozik. 40-200ms-enként érkeznek a frame-ek, amelyek nem folyamatosak, hanem előre-hátra ugranak az időben 5-10 képkockát (elvileg 26 frame-et tud map-elni, ebből 4-et használok - V4L2_MEMORY_MMAP). Sorrenben kapom a buffer indexeket, nem itt lesz a gond. Az összes BT mindenféle régebbi/újabb (3-6 éves) alaplapban tökéletesen működik (ugyanazon a kernel verzión). Találkoztatok már hasonlóval? Nem - már egy ideje nem láttam valódi PCI kártyát :-) Két tipp: - A B150 chipset már nem támogat natívan PCI-t, igy a PCI slot-ok egy PCI-to-PCIe bridge chipre vannak rákötve. A manual bölcsen hallgat a bridge típusáról, de van rá esély, hogy nem szeretik egymást a BT878-cal. Mivel a B150 alapvetően a legolcsóbb irodai PC kategóriát célozza, jó eséllyel a PCI bridge sem egy top-of-the-line modell. - A B150 chipset nincs eleresztve PCIe vonalakkal, mondhatni kevés van belőle. A manual megint hallgat arról, hogy melyik PCIe eszköz (beleértve nem csak a PCIe slotokat, hanem az USB3-at, M.2-t, SATA Expresst, stb. is) csatlakozik közvetlenül a CPU-ra, és melyik a chipset-re, ill. hogy a PCI bridge hogyan csatlakozik bárhova is. Próbálj minden mást lehúzni/BIOS-ban letiltani, hátha valamilyen ütközés van. Bár ütközés esetén inkább azt várná az ember, hogy egyáltalán nem működik az eszköz, de ki tudja... Köszi az infót! Egy dologra rájöttem: ha csak 1 félképig (288 sor) digizek, akkor nincs vele baj. Valamilyen időzítési gond lesz. bttv: 0: timeout: drop=12 irq=44/44, risc=33d711f4, bits: HSYNC OFLOW bttv: 0: timeout: drop=33 irq=119/119, risc=341f94bc, bits: HSYNC OFLOW bttv: 0: timeout: drop=45 irq=161/161, risc=341f82e4, bits: HSYNC OFLOW A BIOS-ban minden lehetségest le/átkapcsoltam, a hibás sorok eltűntek, viszont a kép ugyanúgy döcög. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
BT8x8 + GA-B150M-D3H
Sziasztok! Régebbi BT878/848 PCI kártyákat áttettem egy GA-B150M-D3H alaplapba: a kép össze-vissza ugrál, akadozik. 40-200ms-enként érkeznek a frame-ek, amelyek nem folyamatosak, hanem előre-hátra ugranak az időben 5-10 képkockát (elvileg 26 frame-et tud map-elni, ebből 4-et használok - V4L2_MEMORY_MMAP). Sorrenben kapom a buffer indexeket, nem itt lesz a gond. Az összes BT mindenféle régebbi/újabb (3-6 éves) alaplapban tökéletesen működik (ugyanazon a kernel verzión). Találkoztatok már hasonlóval? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Stream check
On Tue, 25 Oct 2016, Kiss Gabor wrote: On 10/25/2016 10:08 AM, Szima Gábor wrote: Olyan parancsot keresek, amely pipe-on keresztül HASH/CRC-t generál az adatfolyamról és azt annak a végére teszi, echo -n lo | tee >(sha1sum|cut -f1 -d' ') Igen, erre gondoltam. illetve ugyanez fordítva is megy: leellenőrzi, hogy jó-e az adatfolyam. Kb. ugyanaz, mint mondjuk a Akkor már jobb, ha írsz egy kurta perl scriptet. Akkor inkább az egészet C-ben. Gondoltam nem találom fel a meleg vizet, de ezek szerint nem nagyon van még ilyen. Köszi! -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Stream check
Sziasztok! Olyan parancsot keresek, amely pipe-on keresztül HASH/CRC-t generál az adatfolyamról és azt annak a végére teszi, illetve ugyanez fordítva is megy: leellenőrzi, hogy jó-e az adatfolyam. Kb. ugyanaz, mint mondjuk a bzip2 -c1 | ... | bzip2 -t páros, csak kompresszió nélkül. A lényeg, hogy streamen jön egy adatfolyam, a forrás oldalon be tudom csövezni valamibe (jelenleg xz -0c), a fogadó oldalon pedig elmentem. Mentés után pedig szeretném ellenőrizni, hogy minden rendben van-e vele. Azért lenne jó más módszer, mert kevesebb lóerőt visz el, mivel úgysem tud már rajta többet tömöríteni. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: usb portot soros portnak láttatni
On Fri, 20 May 2016, Gádori Zsolt wrote: Az van, hogy fejlesztek egy programot, ami /dev/ttySX-et fog használni a cél környezetben. Az asztali gépemen van hw soros port, ott semmi gond, de a laptopomon már nincs, itt csak USB van. Nomost a laptopon nem bírom fejleszteni/tesztelni az adott programot, mert leáll azzal a hibaüzenettel, hogy nincs ilyen hw eszköz. A kérdés az volna, hogy van-e valami módszer arra, hogy "becsapjam" a programot? Az nem szükséges, hogy a fejlesztés során tényleg használni is tudja a portot (ezt meg tudom oldani, hogy ne legyen rá szükség) de sokat segítene, ha legalább "felismerés", tekintetében rá tudnám szedni őkelmét. IrDA van benne? Sorosként látszik, én is használtam lapitopin RS232 "emulátornak". ;) -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Szaggat a video
On Mon, 11 Apr 2016, Kiss Gabor wrote: Youtube, indavideo stb. filmlejátszás. Full screenben villog, csíkos a kép. Kivéve, ha folyamatosan mozgatom a pointert. (Értsd: interruptokat generálok.) Akkor ugyanis tökéletes a képminőség. HD-ben is. (Tehát nem a hálózati sávszélességgel van a baj.) Ki látott már ilyet? :-o Én. ;) (Írtam is róla pár hónapja) Nálam is hasonló van, csak nem csíkos/villog, hanem megáll a video, majd pár másodperc múlva a hang. Ha lökdösöm az egeret, akkor folyamatos a lejátszás. Minél jobban tekeri a háttárben a CPU-t valami, annál rosszabb. Mintha utolsó utáni prioritáson menne a lejátszás végtelen nice mellett. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: screenshotd
On Wed, 3 Feb 2016, Kiss Gabor wrote: On 02/03/2016 01:08 PM, Szima Gábor wrote: bizonyos képernyőiről szeretnél rendszeresen képeket gyűjteni az előtte ülő user folytatólagos közreműködése nélkül. Ez a feladat? Igen, csak nincs előtte user... Mondjuk úgy, hogy ipari kivetítő, amit sokezren látnak. Oké, de az X szerver process mégiscsak valakinek a nevében fut. inittab/systemd -ből indul, nincs semmi login, no kbd, nincs display manager, csak pucér X. Erre dolgozik rá egy daemon szintén inittab-ból, amely xv porton keresztül pakolgatja fel az infókat innen-onnan (video, képek file-ból, info szöveg UDP-n, stb.) Kb. ez történik: X :0 & sleep 5 export DISPLAY=:0 mplayer ... Maga az xwd tökéletesen lekapja, ezzel nincs gond. Forrásszinten sem egy bonyolult dolog, az egész egy képernyőnyi kb. Ebből faragnék web-szervert, amikre egy mezei Surveillance app kapcsolódna, így aki monitorozni szeretné, az bárhonnan kényelmesen nézheti az összes felületet. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: screenshotd
On Wed, 3 Feb 2016, PÁSZTOR György wrote: "Szima Gábor" írta 2016-02-03 13:19-kor: Miért is kell ez neked? Fejtsd ki, kérlek! Le a kalappal! Nagyon szépen kifejtetted, amit én is gondolok az egészről. Gondolom az uránról is kizárólag az atombomba jut az eszetekbe, véletlenül sem az erőmű... Nem, de ha sötétben villlogtat valaki egy nagykést ??? , akkor nem feltétlenül az jut róla eszembe, hogy ő most falatozni szeretne. Ha megkérdezik, hogy hol lehet kést kapni, akkor kizárólag szomszédgyilok lehet a cél.. De ez már offtopic, szerintem itt fejezzük be. Minden segítséget köszönök! -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: screenshotd
On Wed, 3 Feb 2016, PÁSZTOR György wrote: Miért is kell ez neked? Fejtsd ki, kérlek! Le a kalappal! Nagyon szépen kifejtetted, amit én is gondolok az egészről. Gondolom az uránról is kizárólag az atombomba jut az eszetekbe, véletlenül sem az erőmű... A másik amit nem értek: gyakorlatilag le is írta emberünk a megoldást, csak a unix szemlélet hiányzik belőle. Ott a csomó kis legókocka. Az xwd-t, már meg is írta, hogy le tudja menteni a képernyőt. Ha nem akar protokoll-t túlbonyolítani, akkor fogja, és egy one-liner shellscriptbe rágyógyítja, hogy megnézi, ki az aktuális user a :0-n (feltéve, hogy nincs másik X session), sudo-zik rá, hogy a mit bűvös sütijét elérje, majd amit lement tempfile-t a cucc, azt kivágja stdout-ra, és del. Stabil ipari cucc kell, a meleg vizet pedig nem szeretném feltalálni. Ha nincs ilyen, akkor állok neki rendesen megírni. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: screenshotd
On Wed, 3 Feb 2016, [UTF-8] Szládovics Péter wrote: Létezik X alá olyan screenshot app, amivel több gép képernyőképeit lövi adott időnként, és összegyűjti úgy, hogy egy webserver alatt lehet azokat látni? Kb. úgy, mint egy kamerás megfigyelőrendszer, csak itt a monitorok képeit lehetne ellenőrizni. Olyasmi is megfelelne, ami az xwd-hez hasonlóan lövi a képeket, csak nem file-ba teszi le, hanem a 80-as porton ki lehet olvasni, mintha webkamera lenne. 1984... Erre proxy-t és forgalomnaplózást szoktak használni, sokkal kulturáltabb. Ha meg vezetőbácsi nézni akarja, hogy Béla épp milyen oldalt néz, akkor arra találták ki a kamerát. Miből gondolod, hogy ez a feladat? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: screenshotd
On Wed, 3 Feb 2016, Kiss Gabor wrote: Pardon??? Itt valami koncepcionális félreértést látok. Kezdjük ott, hogy a "képernyőkép" nem géphez tartozik, hanem X szerverhez. Amiből egy hardveren akár több is lehet. Például két fizikai és három VNC-s. Ebben az esetben mit is szeretnél lelopni? Adott gép adott (egyetlen) X szerverének képe. Semmi VNC. Ha jól sejtem, bizonyos operációs rendszerű gépek Egyébként Linux, ha valaki esetleg másra tippelt volna. bizonyos képernyőiről szeretnél rendszeresen képeket gyűjteni az előtte ülő user folytatólagos közreműködése nélkül. Ez a feladat? Igen, csak nincs előtte user... Mondjuk úgy, hogy ipari kivetítő, amit sokezren látnak. Miért is kell ez neked? Fejtsd ki, kérlek! Csak. :) Na jó: aki a központi tartalmat szerkeszti, az szeretné látni a végeredményt az adott helyen anélkül, hogy 1001 gépet körbe kellene futnia vagy bekamerázni emiatt az adott helyiséget. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
screenshotd
Sziasztok! Létezik X alá olyan screenshot app, amivel több gép képernyőképeit lövi adott időnként, és összegyűjti úgy, hogy egy webserver alatt lehet azokat látni? Kb. úgy, mint egy kamerás megfigyelőrendszer, csak itt a monitorok képeit lehetne ellenőrizni. Olyasmi is megfelelne, ami az xwd-hez hasonlóan lövi a képeket, csak nem file-ba teszi le, hanem a 80-as porton ki lehet olvasni, mintha webkamera lenne. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: fajlrendszer titkositas
On Thu, 21 Jan 2016, Kosa Attila wrote: Nekem a lenyeg az lenne, hogy Debianon minel kevesebb barkacsolassal mukodokepes legyen, a rendszerindulas folyamataban a leheto legkevesebb fennakadast okozza, a performanciaban ne okozzon jelentos visszaesest az alkalmazasa. Johetnek a tippek, hogy merre erdemes elindulni :) Luks: https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: FireFox akadozik
On Fri, 25 Sep 2015, [UTF-8] Pápai Balázs wrote: Nálam, (Ubuntu 12.04) a flash videó kezd akadozni, ha mozgatom az egeret, de ezt már régebb óta csinálja, szóval csak hasonló jelenség, de nem hiszem, hogy összefügg. Itt igazából halmozottan jelentkezik. Ha megy egy flash video, közben ugyanazon az ablakon egy anim (advert), akkor szinte csak akkor megy a video és az anim, ha folyamatosan rángatom az egeret. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
FireFox akadozik
Sziasztok! Pár napja a FireFox azt műveli, hogy input esemény nélkül (egérmozgás, billencs) pár másodperc után az animált dolgok megállnak (animgif, flash video), majd szintén pár másodperccel később a hozzájuk tartozó hang is megáll (gondolom addigra fogy ki a bufferből). CPU-t, vinyót nem kergeti. Amint meglököm az egeret vagy leütök egy billentyűt, úgy folytatódik minden tovább. FF 40.0.3, 41.0 Xorg 40.0.3 NVIDIA-Linux-x86-340.65 Linux 3.0.101-99-desktop OpenSuSE 11.4 Futott már bele valaki hasonlóba? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: ETH RX dropped
Szia! On Tue, 29 Jul 2014, Farago Janos wrote: Esetleg még ezt megnézhetnéd: http://www.andrews.hu/2013/az-nf_conntrack_log_invalid-sysctl-mukodese-es-lehetseges-ertekei/ A tcpdump az eldobott csomagokra "R (RST)" -t jelez. És nem broadcast, hanem neki szánt csomag. Fura. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: ETH RX dropped
On Tue, 29 Jul 2014, Szima Gábor wrote: Linux 2.6.38.6 BCM5721 (tg3 mod) Egyszer régen szivtam hasonlóval. Én is a hálókártyára gyanakodtam, de szerencsére abban a gépben két azonos NET kártya volt, és egyszerre csak nem mennek tönkre :-). Akkor jöttem rá hogy volt közben egy kernel frissítésem. Ezután kipróbáltam az előző kernelt és gond nélkül hasított. /később az újabb kernellel sem volt gond/. Vagyis a kernelben volt valami bug. Remélem Nálad is ennyire "egyszerű" a megoldás. :-D Az a fura, hogy ugyanaz a kártya ugyanazzal a kernellel valahol 0, máshol sok csomagot dobál el, másik kernellel szintén van 0 és sok eldobálás. Linux 2.6.39.6 82557/8/9 Ethernet Pro 100 RX packets:1020644346 errors:0 dropped:19664244 overruns:175 frame:175 Tehát nem kártyafüggő. Vagy a kernel bugos, vagy valami teleszemeteli a hálózatot. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: ETH RX dropped
Szia! On Thu, 24 Jul 2014, Szilveszter Pinter wrote: Linux 2.6.38.6 BCM5721 (tg3 mod) Egyszer régen szivtam hasonlóval. Én is a hálókártyára gyanakodtam, de szerencsére abban a gépben két azonos NET kártya volt, és egyszerre csak nem mennek tönkre :-). Akkor jöttem rá hogy volt közben egy kernel frissítésem. Ezután kipróbáltam az előző kernelt és gond nélkül hasított. /később az újabb kernellel sem volt gond/. Vagyis a kernelben volt valami bug. Remélem Nálad is ennyire "egyszerű" a megoldás. :-D Az a fura, hogy ugyanaz a kártya ugyanazzal a kernellel valahol 0, máshol sok csomagot dobál el, másik kernellel szintén van 0 és sok eldobálás. Próbálok rájönni a környezetből, mi lehet a nyűgje. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: ETH RX dropped
Szia! On Thu, 24 Jul 2014, Farago Janos wrote: Ez mit mond: head /sys/class/net/ethX/statistics/rx_* ^ X helyett az interface száma ==> /sys/class/net/eth0/statistics/rx_bytes <== 143948877692 ==> /sys/class/net/eth0/statistics/rx_dropped <== 5940928 ==> /sys/class/net/eth0/statistics/rx_missed_errors <== 759 ==> /sys/class/net/eth0/statistics/rx_packets <== 674367903 A többi 0. Elég sok oka lehet az eldobásnak pl. nagy csomagszámnál egész egyszerűen nem bírja a gép. 50-100 csomag/s, szinte semmi. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
ETH RX dropped
Sziasztok! Elég magas, kb 1% az eth RX dropped aránya az RX packets-hez képest. Kábel/switch port csere volt, nem változott. A hálókártya döglődik, vagy lehet ennek egyéb oka is? Pl. valami teleszemeteli a hálózatot. Linux 2.6.38.6 BCM5721 (tg3 mod) -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: ServeRAID belassult -> megoldas
On Mon, 20 Jan 2014, Szima Gábor wrote: Az egyik diszk LED-je folyamatosan jár, a másik néha pislant. Reboot, poweroff is volt, a hiba nem szűnt meg. Diszk hiba. Az egyik belassult, de rendesen (kb. 1/100-ad részére), a RAID kontroller viszont nem dobta ki. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: ServeRAID belassult
Szia! On Mon, 20 Jan 2014, [utf-8] Hegedüs Ervin wrote: A megoldás a firmware upgrade volt - utána kifogástalanul elindult a vezérlő. (Az IBM oldalára is eljutottam a keresés során, ott is a firmware upgarade volt a megoldási javaslat arra a hibaüzenetre) Köszi, valahogy sejtettem. Gondolom ezt élő rendszer alatt nem "illik" megejteni, CD-ről kell boot-olni. Közben a másik probléma, a kikapcsolhatatlan consistency check megoldódott: egy másik arcconf kell, amiben nem CONSISTENCYCHECK, hanem DATASCRUB a paraméter neve. http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=MIGR-5073646 -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
ServeRAID belassult
Sziasztok! IBM x3550, IBM ServeRAID 8k-l, linux-2.6.39-4. Eddig nagyjából megfelelően működött, de ma reggel iszonyatosan belassult, alig képes kiszolgálni a párhuzamos IO-kat. Állandó 4 feletti load (0,2 alatt kellene lennie), ioload 50%-on. Az egyik diszk LED-je folyamatosan jár, a másik néha pislant. Reboot, poweroff is volt, a hiba nem szűnt meg. arcconf alapján semmi baj nincs vele, elvileg semmi háttérfunkciót nem futtat. # arcconf GETSTATUS 1 Controllers found: 1 Current operation : None # arcconf GETCONFIG 1 AD Controllers found: 1 -- Controller information -- Controller Status: Optimal Channel description : SAS/SATA Controller Model : IBM ServeRAID 8k-l Controller Serial Number : *** Physical Slot: 0 Installed memory : 32 MB Copyback : Disabled Background consistency check : Enabled Automatic Failover : Enabled Host bus type: unknown Host bus speed : 0 MHz Host bus link width : 0 bit(s)/link(s) Stayawake period : Disabled Spinup limit internal drives : 0 Spinup limit external drives : 0 Defunct disk drive count : 0 Logical devices/Failed/Degraded : 1/0/0 Controller Version Information BIOS : 5.2-0 (11844) Firmware : 5.2-0 (11844) Driver : 1.1-7 (28000) Boot Flash : 5.1-0 (11835) Controller Battery Information Status : Not Installed # arcconf GETCONFIG 1 PD Controllers found: 1 -- Physical Device information -- Device #0 Device is a Hard drive State : Online Block Size : Unknown Supported : Yes Transfer Speed : SAS 3.0 Gb/s Reported Channel,Device(T:L) : 0,0(0:0) Reported Location : Enclosure 0, Slot 0 Reported ESD(T:L) : 2,0(0:0) Vendor : IBM-ESXS Model : ST373455SS Firmware : BA2D Serial number : World-wide name: Reserved Size : 2577373865 KB Used Size : 0 MB Unused Size: 3369298971 MB Total Size : 4021933058 MB Write Cache: Enabled (write-back) FRU: 39R7360 S.M.A.R.T. : No S.M.A.R.T. warnings: 0 SSD: No Device #1 Device is a Hard drive State : Online Block Size : Unknown Supported : Yes Transfer Speed : SAS 3.0 Gb/s Reported Channel,Device(T:L) : 0,1(1:0) Reported Location : Enclosure 0, Slot 1 Reported ESD(T:L) : 2,0(0:0) Vendor : IBM-ESXS Model : ST373455SS Firmware : BA2D Serial number : World-wide name: Reserved Size : 2577373865 KB Used Size : 0 MB Unused Size: 3369298971 MB Total Size : 4021933058 MB Write Cache: Enabled (write-back) FRU: 39R7360 S.M.A.R.T. : No S.M.A.R.T. warnings: 0 SSD: No Device #2 Device is an Enclosure services device Reported C
NFS/directory quota
Sziasztok! Szerver oldalon egy exportált könyvtárra lehet quota-t beállítani? Fix "össznépit", nem pedig felhasználó/csoport szintűt. Az a cél, hogy a kliensek ne vágják fullra a szervert, ha az adott könyvtár foglaltága elér egy bizonyos szintet, akkor onnantól nincs tovább... Tehát vagy fs szinten a könyvtárat, vagy nfs oldalon az exportot kellene bekorlátozni. Túrom a netet, de nem jutottam közelebb. (ext3/4 ill. NFS3/4) -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
aacraid direct disk access
Sziasztok! IBM ServeRAID 8k-l vezérlővel megoldható, hogy a diszkeket RAID-be fűzés nélkül direkt map-elje (sda, sdb, stb.), mintha csak sima SCSI vezérlő lenne? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: T-com -> maxer.hu DNS bug
On Sun, 16 Dec 2012, [utf-8] Hegedüs Ervin wrote: > maxer.hu-tól kérdezve. > >>> nslookup a.valami.hu 84.2.44.1 Ez (84.2.44.1) a T-mínusz elsődleges DNS szervere. >> Non-authoritative answer: > ^^^ > ez biztos nem cache valahonnan? Lehet a T-com-nál. > mit értesz "oldal" alatt? Maxer vs. T-mínusz. ;) Vagy a Maxer-nél van valami elbaltázva, és időnként hülyeséget ad vissza, vagy a T-nél került be valamikor egy hiba a cache-be, és néha azt kapom vissza. > A domain másodlagos szerverétől kérdezve is előjön ez a hiba, Igen. > vagy amikor nem adja vissza az a.valami.hu-t, akkor az ennek > ellenére válaszol? Az a furcsa, hogy nem timeout-ol, hanem 1-2 ms alatt vagy IP-t kapok, vagy hibát. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
T-com -> maxer.hu DNS bug
Sziasztok! Több különböző (ADSL, LAN) T-com hálózatról a maxer.hu DNS-e által szolgáltatott egy bizonyos host kérés kb. 20-30%-ban hibával tér vissza: > nslookup a.valami.hu 84.2.44.1 Server: 84.2.44.1 Address:84.2.44.1#53 ** server can't find a.valami.hu: NXDOMAIN > dig a.valami.hu DNS ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24139 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;a.valami.hu.IN A ;; AUTHORITY SECTION: valami.hu. 81003 IN SOA ns1.maxer.hu. hostmaster.maxer.hu. 2012120736 10800 3600 604800 3600 Amikor megy: > nslookup a.valami.hu 84.2.44.1 Server: 84.2.44.1 Address:84.2.44.1#53 Non-authoritative answer: Name: a.valami.hu Address: 123.4.5.6 > dig a.valami.hu DNS ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53387 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;a.valami.hu.IN A ;; ANSWER SECTION: a.valami.hu. 827 IN A 123.4.5.6 ... Más hálózatból megy rendesen az "a.valami.hu", illetve T-com hálózatból hiba nélkül a "valami.hu", "www.valami.hu" is... Melyik oldalon lehet a hiba? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: VMware+linux sd akad
On Wed, 10 Oct 2012, Szima Gábor wrote: >> mi a vmware verzioja (esx/esxi)? > > esxi 4.0.0 > build 208167 > > Az a fura, hogy időszakos a leakadás. Pl. tegnep este pont a logbejegyzés > után ledöglött az adott virtuális gép, majd újraindítva megszűnt a > probléma. > Átnéztem a logot, és abból az derül ki, hogy napokra/hetekre megszűnik a > leakadás, majd egyszer csak gondol egyet, és hónapokig folyamatosan > csinálja a műsort. Illetve "akadós" üzemmódban kb. 12 MB/s a diszk olvasási sebessége (hdparm -t), ha meg nem akadozós állapotban van, akkor 90 MB/s. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: VMware+linux sd akad
On Wed, 26 Sep 2012, SZALAI Karoly wrote: > mi a vmware verzioja (esx/esxi)? esxi 4.0.0 build 208167 Az a fura, hogy időszakos a leakadás. Pl. tegnep este pont a logbejegyzés után ledöglött az adott virtuális gép, majd újraindítva megszűnt a probléma. Átnéztem a logot, és abból az derül ki, hogy napokra/hetekre megszűnik a leakadás, majd egyszer csak gondol egyet, és hónapokig folyamatosan csinálja a műsort. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
VMware+linux sd akad
Sziasztok!
Egy virtuális gépen (általában) 5 perc 11 másodpercenként leakad a linux
I/O-ja (HDD, NET) 20 másodpercre. Az ezen idő alatt érkezett TCP
csomagokat a 20 másodperc leteltével viszont feldolgozza.
A logban ezt látom:
Sep 25 21:34:12 linux kernel: [4146227.283171] sd 0:0:0:0: timing out command,
waited 20s
Sep 25 21:39:22 linux kernel: [4146536.763278] sd 0:0:0:0: timing out command,
waited 20s
Sep 25 21:44:33 linux kernel: [4146847.683909] sd 0:0:0:0: timing out command,
waited 20s
Sep 25 21:49:42 linux kernel: [4147156.494162] sd 0:0:0:0: timing out command,
waited 20s
Sep 25 21:54:43 linux kernel: [4147456.440904] sd 0:0:0:0: timing out command,
waited 20s
Sep 25 21:59:53 linux kernel: [4147765.680382] sd 0:0:0:0: timing out command,
waited 20s
Sep 25 22:04:56 linux kernel: [4148068.487113] sd 0:0:0:0: timing out command,
waited 20s
A vas egy erősebb HP szerver (elvileg) SATA diszkekkel, illetve egy újabb
vindóz osztozik még rajta.
Konkrétumot sajnos nem tudok, csak a linuxra van rálátásom távolról.
CPU:
model name : Intel(R) Xeon(R) CPU X3430 @ 2.40GHz
stepping: 5
cpu MHz : 2393.985
cache size : 8192 KB
Kernel: 2.6.34
Ha jól tudom, a VMware + SATA nem túl szerencsés, igaz ez? Vagy csak
bizonyos vezérlőket nem szeret?
lspci:
00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X
Fusion-MPT Dual Ultra320 SCSI (rev 01)
boot.msg:
<5>[1.891455] SCSI subsystem initialized
<6>[1.896527] Fusion MPT base driver 3.04.14
<6>[1.896528] Copyright (c) 1999-2008 LSI Corporation
<6>[1.902420] Fusion MPT SPI Host driver 3.04.14
<7>[1.902453] alloc irq_desc for 17 on node -1
<7>[1.902454] alloc kstat_irqs on node -1
<6>[1.902463] mptspi :00:10.0: PCI INT A -> GSI 17 (level, low) -> IRQ
17
<6>[1.902676] mptbase: ioc0: Initiating bringup
<6>[1.920824] ioc0: LSI53C1030 B0: Capabilities={Initiator}
<6>[1.961291] scsi0 : ioc0: LSI53C1030 B0, FwRev=01032920h, Ports=1,
MaxQ=128, IRQ=17
<5>[1.988724] scsi 0:0:0:0: Direct-Access VMware Virtual disk 1.0
PQ: 0 ANSI: 2
<6>[1.988729] scsi target0:0:0: Beginning Domain Validation
<6>[1.989241] scsi target0:0:0: Domain Validation skipping write tests
<6>[1.989243] scsi target0:0:0: Ending Domain Validation
<6>[1.989280] scsi target0:0:0: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns,
offset 127)
Mi lehet a kínja?
-Sygma
_
linux lista - linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: hibas kernel - binutils bug?
On Thu, 6 Sep 2012, Kovács Attila wrote: > 2012.09.06. 14:18 keltezéssel, Szima Gábor írta: >> Tettem fel újabbat: GNU ld (Linux/GNU Binutils) 2.23.51.0.1.20120806 >> >> Ezzel megy... > Tán ebbe akadtál bele > Hasznos infó... > https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/644850 "Kernels linked with later versions give a KP stating that "IO-APIC + Timer doesn't work" ". Ez lesz az. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: hibas kernel - binutils bug?
On Thu, 6 Sep 2012, Szima Gábor wrote: > GNU ld (GNU Binutils) 2.21 Tettem fel újabbat: GNU ld (Linux/GNU Binutils) 2.23.51.0.1.20120806 Ezzel megy... Van valakinek a gépén 2.21 binutils, aki esetleg kreált vele kernelt? Működött? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: hibas kernel
On Thu, 6 Sep 2012, Kovács Attila wrote: > 2012.09.06. 11:32 keltezéssel, Szima Gábor írta: >> ..MP-BIOS bug: 8254 timer not connected to IO-APIC > Az hogy bios bug-ra panaszkodik, miért indikálja hogy rossz a kernel? Mint írtam, ugyanaz a kernel verzió, ugyanazzal a konfigurációval ugyanazzal a gcc-vel, csak más ld/make/binutils környezetben fordítva működik rendesen ugyanazon a gépen. > Csak érdeklődöm, biztosan van ennek oka, de nem mondtad el pontosan > a környezetet és így nehéz kihüvelyezni hogy mit is akarsz kérdezni Akkor újrakezdem: Környezet: GNU ld (GNU Binutils) 2.21 GNU Make 3.82 util-linux 2.19 gcc version 4.4.7 (GCC) linux-2.6.39.4 Az így fordított kernel _semelyik_ gépen sem fut, a már jelzett hibával leakad (mindegyiken, ugyanott, ugyanúgy). Másik környezet: GNU ld (GNU Binutils) 2.17.50.20070726-14 GNU Make 3.81 util-linux-ng 2.13-rc2 gcc version 4.4.7 (GCC) linux-2.6.39.4 (Ugyanaz a .config) Az ebben fordított (elvileg ugyanolyan) kernel _minden_ gépen fut. Szelektív HW/BIOS hiba? :) Tehát nagy valószínűséggel az ld, make vagy az util-linux lehet a hunyó (vagy ezek kombinációja hozza elő), és tulajdonképp ez lenne a kérdés, hogy melyik okozhat ilyet. Illetve hogy ezeken kívül lehet-e még valami egyéb csomag, ami befolyásolja a fordított kódot? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: hibas kernel
On Thu, 6 Sep 2012, Attila Rajmund Nohl wrote: > Nem lehet hardverhiba a fordítógépen? Nem hinném, ugyanis ha a régebbi rendszert indítom rajta, akkor működőképes kernelt fordít. A kernelfordítás használja a glibc-devel-t (/usr/include/*.h) ? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: hibas kernel
On Thu, 6 Sep 2012, Kovács Attila wrote: > cpu type? Egyik: vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 3.20GHz stepping: 3 cpu MHz : 3200.266 cache size : 2048 KB ... bogomips: 6400.37 Egy másik: vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Celeron(R) CPU 3.06GHz stepping: 1 cpu MHz : 3067.000 cache size : 256 KB ... bogomips: 6118.50 -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: hibas kernel
On Thu, 6 Sep 2012, Krisztian VASAS wrote: >> A lényeg, hogy ugyanez a kernel (2.6.38.x, 2.6.39.x), ugyanazzal a >> fordítóval (gcc447, gcc471), ugyanazzal a konfigurációval (.config) >> több másik gépen lefordítva fut rendesen. > > Ez engem inkább egy hw hibára emlékeztet (alaplap vagy cpu). Biztos nem az, ugyanis a "jó" kernel fut mindenféle vason (összelapátolt vastól Brand PC-n át rendesebb szerverig), míg a "rossz" kernel ugyanezen gépek mindegyikén ugyanezt generálja... Jelenleg linkelési vagy header hibára tippelek, ahol vagy rossz címre ugrik vagy ír/olvas a kernel. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
hibas kernel
Sziasztok! Egy adott környezetben kivétel nélkül hibás kernelt tudok fordítani, ami a következő üzenetekkel száll ell következetesen: ACPI: Core revision 20110316 Enabling APIC mode: Flat. Using 1 I/O APICs ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 ..MP-BIOS bug: 8254 timer not connected to IO-APIC ...trying to set up timer (IRQ0) through the 8259A ... . (found apic 0 pin 2) ... ... failed ...trying to set up timer as Virtual Wire IRQ... . failed ...trying to set up timer as ExtINT IRQ... . failed :(. Kernel panic - not syncing: IO-APIC + timer doesn't work! A lényeg, hogy ugyanez a kernel (2.6.38.x, 2.6.39.x), ugyanazzal a fordítóval (gcc447, gcc471), ugyanazzal a konfigurációval (.config) több másik gépen lefordítva fut rendesen. Viszont amikor azon a bizonyos gépen lefordul (hiba nélkül), nagyjából a mérete is azonos, de induláskor leakad. Amiben különbözik a többitől (ezen nem megy): GNU ld (GNU Binutils) 2.21 GNU Make 3.82 util-linux 2.19 Ezen megy: GNU ld (GNU Binutils) 2.17.50.20070726-14 GNU Make 3.81 util-linux-ng 2.13-rc2 Amiben egyeznek: gcc version 4.4.7 (GCC) linux-2.6.39.4 (& .config) Melyik csomag lehet a hunyó, illetve mi befolyásolhatja még a fordítást? Pl. glibc-devel (/usr/include)? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
NFSv3 NAT cache
Sziasztok!
Okozhat directory inkonzisztenciat NAT-olt halon levo NFS kapcsolat (UDP)?
A kliens megnyitna egy file-t, ami nemreg jott letre a szerveren,
de nem talalja (open ("/mnt/file") -> -1).
Viszont ha a kliensen az egesz konyvtar tartalmat listazzuk (ls /mnt),
akkor utana helyreall a struktura es ott a file, meg tudja nyitni
(gondolom a cache-t teljesen ujratolti).
Egyebkent rendkivul ritkan jon elo, de zavaro tud lenni.
Szoval ez a NAT miatt van, vagy inkabb egyeb oka lehet?
-Sygma
_
linux lista - linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: samba perm
On Wed, 9 May 2012, Kosa Attila wrote: > On Wed, May 09, 2012 at 02:44:28PM +0200, Szima Gábor wrote: >> >> Kozben kiderult a turpissag: apparmor... >> >> https://bugzilla.novell.com/show_bug.cgi?id=751660 >> >> # aa-complain /etc/apparmor.d/usr.sbin.smbd > > Akkor az utolso sorban csak rahibaztam :)) Igen, koszi az ertekes infokat. Egyebkent a nobody (vagy mas, semmijoga juzer) azert kell, hogy ha esetleg torik a samba-t, akkor egy lepessel kevesebb kart okozzanak. Egy readonly konyvtar lesz megosztva (benne kezikonyvekkel), ehhez nem kell irasi jog. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: samba perm
On Wed, 9 May 2012, Kosa Attila wrote: > On Wed, May 09, 2012 at 11:54:12AM +0200, Szima Gábor wrote: >> On Wed, 9 May 2012, Kosa Attila wrote: >> >> Vilagos, tobbiektol bocs: > > Ebben a konfigban nem latok olyat, ami megmagyarazna a > problemadat. Kozben kiderult a turpissag: apparmor... https://bugzilla.novell.com/show_bug.cgi?id=751660 # aa-complain /etc/apparmor.d/usr.sbin.smbd -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: samba perm
On Wed, 9 May 2012, Kosa Attila wrote: >>> Egyelore nem tudom, de esetleg egy >>> # testparm -v < /dev/null > full_smb.conf >>> eredmenyet megneznem (akar maganba is kuldheted). >> >> conf: > > Nem veletlenul irtam oda, hogy milyen parancs kimenete > erdekelne... Vilagos, tobbiektol bocs: [global] dos charset = CP850 unix charset = UTF-8 display charset = LOCALE workgroup = WORKGOUP realm = netbios name = TIVADAR netbios aliases = netbios scope = server string = Teszt interfaces = bind interfaces only = No security = USER auth methods = encrypt passwords = Yes client schannel = Auto server schannel = Auto allow trusted domains = Yes map to guest = Bad User null passwords = No obey pam restrictions = No password server = * smb passwd file = /etc/samba/smbpasswd private dir = /etc/samba passdb backend = tdbsam algorithmic rid base = 1000 root directory = guest account = nobody enable privileges = Yes pam password change = No passwd program = passwd chat = *new*password* %n\n *new*password* %n\n *changed* passwd chat debug = No passwd chat timeout = 2 check password script = username map = password level = 0 username level = 0 unix password sync = No restrict anonymous = 0 lanman auth = No ntlm auth = Yes client NTLMv2 auth = Yes client lanman auth = No client plaintext auth = No client use spnego principal = No send spnego principal = No preload modules = dedicated keytab file = kerberos method = default map untrusted to domain = No log level = 2 syslog = 1 syslog only = No log file = max log size = 5000 debug timestamp = Yes debug prefix timestamp = No debug hires timestamp = Yes debug pid = No debug uid = No debug class = No enable core files = Yes smb ports = 445 139 large readwrite = Yes max protocol = NT1 min protocol = CORE min receivefile size = 0 read raw = Yes write raw = Yes disable netbios = No reset on zero vc = No log writeable files on exit = No acl compatibility = auto defer sharing violations = Yes nt pipe support = Yes nt status support = Yes announce version = 4.9 announce as = NT max mux = 50 max xmit = 16644 name resolve order = lmhosts wins host bcast max ttl = 259200 max wins ttl = 518400 min wins ttl = 21600 time server = No unix extensions = Yes use spnego = Yes client signing = auto server signing = No client use spnego = Yes client ldap sasl wrapping = plain enable asu support = No svcctl list = deadtime = 0 getwd cache = Yes keepalive = 300 lpq cache time = 30 max smbd processes = 0 paranoid server security = Yes max disk size = 0 max open files = 16384 socket options = TCP_NODELAY use mmap = Yes hostname lookups = No name cache timeout = 660 ctdbd socket = cluster addresses = clustering = No ctdb timeout = 0 ctdb locktime warn threshold = 0 smb2 max read = 65536 smb2 max write = 65536 smb2 max trans = 65536 smb2 max credits = 8192 load printers = Yes printcap cache time = 750 printcap name = cups server = cups encrypt = No cups connection timeout = 30 iprint server = disable spoolss = No addport command = enumports command = addprinter command = deleteprinter command = show add printer wizard = Yes os2 driver map = mangling method = hash2 mangle prefix = 1 max stat cache size = 256 stat cache = Yes machine password timeout = 604800 add user script = rename user script = delete user script = add group script = delete group script = add user to group script = delete user from group script = set primary group script = add machine script = shutdown script = abort shutdown script = username map script = username map cache time = 0 logon script = logon path = \\%N\%U\profile logon drive = logon home = \\%N\%U domain logons = No init logon de
Re: samba perm
On Wed, 9 May 2012, Kosa Attila wrote:
> On Wed, May 09, 2012 at 08:58:57AM +0200, Szima Gábor wrote:
>>
>> A samba nobody-kent csak a /tmp -t, illetve az abbol nyilo, kizarolag
>> nobody tulajdonu konyvtarakat es file-okat hajlando megnyitni, hiaba 777
>> a mod.
>>
>> Mi lehet a megoldas?
>
> Egyelore nem tudom, de esetleg egy
> # testparm -v < /dev/null > full_smb.conf
> eredmenyet megneznem (akar maganba is kuldheted).
conf:
[global]
workgroup = WORKGOUP
server string = Teszt
map to guest = Bad User
usershare allow guests = Yes
follow symlinks = yes
unix extensions = yes
wide links = yes
[Teszt]
comment = Teszt
path = /tmp
read only = Yes
guest ok = Yes
testdump:
[global]
workgroup = WORKGOUP
server string = Teszt
map to guest = Bad User
usershare allow guests = Yes
idmap config * : backend = tdb
wide links = Yes
[Teszt]
comment = Teszt
path = /tmp
guest ok = Yes
>> Valamilyen kernel parameterre tippelek.
>
> Miert?
Hirtelen nem ugrik be, de remlik valami jogosultsagi fix, ami nem engedte
ki a daemonokat talan a home-jukbol, vagy ilyesmi.
Az az orjito, hogy a /tmp -be beengedi (chmod 777, chown root), viszont a
/tmp2 -be nem (chmod 777, chown root)...
--
drwxrwxrwx 22 root root 4096 May 9 09:54 tmp
smbclient //192.168.2.1/Teszt
smb: \> dir
. D0 Wed May 9 09:54:52 2012
.. D0 Wed May 9 02:34:40 2012
...
hello1 Wed May 9 11:00:06 2012
mc-root D0 Wed May 9 03:01:57 2012
--
smb: \> get hello
NT_STATUS_ACCESS_DENIED opening remote file \hello
# chown nobody /tmp/hello
smb: \> get hello
getting file \hello of size 1 as hello (1.0 KiloBytes/sec) (average 1.0
KiloBytes/sec)
Viszont:
[Teszt]
comment = Teszt
path = /tmp2
read only = Yes
guest ok = Yes
drwxrwxrwx 22 root root 4096 May 9 09:55 tmp2
smb: \> sygma@tivadar:~> smbclient //192.168.60.1/Teszt
smb: \> dir
NT_STATUS_ACCESS_DENIED listing \*
smb: \> pwd
Current directory is \\192.168.2.1\Teszt\
smb: \> cd xx
smb: \xx\>
strace:
chdir("/tmp2") = 0
getcwd("/tmp2", 4096) = 6
lstat64("/tmp2/*", 0xbf7feb2c) = -1 ENOENT (No such file or
directory)
getcwd("/tmp2", 4096) = 6
getcwd("/tmp2", 4096) = 6
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 EACCES
(Permission denied)
nobody 15574 0.0 0.5 18756 2620 ?S10:52 0:00 /usr/sbin/smbd
-D -s /etc/samba/smb.conf
xyz:/tmp2 # su - nobody
nobody@zyx:~> cd /tmp2/
nobody@xyz:/tmp2> dir
total 4
drwxr-xr-x 2 root root 4096 May 9 10:50 xx
lsattr:
-e- ./tmp
-e- ./tmp2
Na ezt add ossze. ;)
> Mas kernellel mukodott?
Igen, ugyanaz a samba binaris, ugyanaz a konfig, szinte mindenhol megy.
> Amugy en samba konfigra tippelnek, ha kellene :)
A /tmp es /tmp2 kozott nincs mit elrontani a konfigon.
Tehat: csak a /tmp -be enged be, es csak azokat a file-okat engedi
olvasni, aminek nobody a tulajdonosa.
-Sygma
_
linux lista - linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
samba perm
Sziasztok!
A samba nobody-kent csak a /tmp -t, illetve az abbol nyilo, kizarolag
nobody tulajdonu konyvtarakat es file-okat hajlando megnyitni, hiaba 777
a mod.
A konyvtarba belep ugyan, de se a file neveit, sem tartalmukat nem tudja
olvasni.
strace:
chdir("/export") = 0
lstat64("/export/*", 0xbfb11b1c) = -1 ENOENT (No such file or directory)
getcwd("/export", 4096) = 10
getcwd("/export", 4096) = 10
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 EACCES
(Permission denied)
Az az erdekes, hogy nobody-kent loginelve (bash) viszont tovabbra is
rendesen mukodik a jogosultsag.
Linux-2.6.37.6, samba 3.6/3.5, ext4.
Mi lehet a megoldas?
Valamilyen kernel parameterre tippelek.
-Sygma
_
linux lista - linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
ITX+ATI+xorg xv nincs
Sziasztok! Valami nagyon uj vagy mellekvagany ATI videovezerlo van egy ITX alapon. Ujabb disztribuciok nem ismerik fel PCI-ID alapjan (1002:9802). Az xorg 1.9.3 beindul rajta (ati vagy readon driver, radeonhd viszont nem szereti), viszont az xvideo nem megy rajta # xvinfo X-Video Extension version 2.2 screen #0 no adaptors present Lehet ezzel valamit hegeszteni (beallitas, ujabb driver), vagy kuka? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: 3DS/DWG
On Wed, 21 Dec 2011, [ISO-8859-1] Kis János Tamás wrote: > Az egyik fórumon > [http://www.linuxquestions.org/questions/linux-software-2/open-source-dwg-to-dxf-converter-431197/] > dicsérték az "Lx-Viewer"-t [http://lx-viewer.sourceforge.net/], amit > -ha lesz egy kis időm e célra- ki is fogok próbálni. Ezzel ott akadtam meg, hogy 2005-ben megállt a fejlesztése, és akkori libeket kéreget. Kozben sikerut egy regebbi 3dstudioval DXF-re konvertalni, amelyet mar korrektul be tud tolteni a Blender. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: 3DS/DWG
On Tue, 20 Dec 2011, zamek wrote: > A dwg autocad formatum, le lehet tolteni - sajnos windowsos -, dwg2svg > convertert. Az svg nem 2D formatum? Most nezem, a Blender tud importalni 3DS-t (es elvileg svg-t is). -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
3DS/DWG
Sziasztok! A tudomany mai allasa szerint milyen (free) programmal lehet megnyitni a .3DS es .DWG file-okat? Esetleg atkonvertalhatok olyan formatumra, amit linuxos CAD programok szeretnek? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: option driver, Huawei modem
On Tue, 4 Oct 2011, BEREGNYEI Balazs wrote: >> Es mi hozza letre a /dev/ttyUSB* fajlt? Alighanem az udev. Az van >> az ARM-es rendszereden? > > Igen, van, ezt direkt meg is neztem egy masik usb-soros driverrel > (pl2303), radugaskor jon letre a /dev/ttyUSB0. Nem lehet, hogy az option driver nem kedveli az ARM (esetleges) big-endian modjat? Nezd at esetleg a kodot. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
iptables NAT "kill"
Sziasztok! Hogyan lehet iptables segitsegevel egy mar felepult NAT-olt kapcsolatot megszuntetni/lezarni? Van 2 tuzfal scriptem, amelyek bizonyos feltetelek eseten indulnak el felvaltva (vagy az egyik, vagy a masik az aktiv). Az egyik enged egy bizonyos cimre/portra valo NAT-ot, a masik nem. Ez mindaddig szepen mukodik, amig nincs egy mar elo kapcsolat. Ugyanis hiaba van tiltva a masik script altal, a meg aktiv kapcsolatok tovabbra is mukodnek, ami nekem nem jo, el kellene dobni oket. Pelda: firewall_on.sh: ... iptables -t nat -A PREROUTING -p tcp --dport 1234 -j DNAT --to-destination 3.4.5.6:1234 ... firewall_off.sh: iptables -F iptables -F -t nat OFF utan nem epul fel uj kapcsolat, viszont a mar meglevok maradnak. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: load anomalia
On Fri, 20 May 2011, Szima Gábor wrote: > most stabilan beallt egy 0.00/0.01/0.04 bocs: 0.00/0.01/0.05 Es ez tobb mint egy oraja igy maradt. Egy masik, kisse eltero vason is (1 db kisebb CPU, lenyegesen lassabb diszkek) (kernel: 2.6.38.6) De most latom, mas is tapasztalt mar ilyet. ;) http://forum.linode.com/viewtopic.php?p=38438 http://forum.proxmox.com/archive/index.php/t-5916.html?s=d92560ba37f69038d06b5a184f8b9583 -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: load anomalia
On Fri, 20 May 2011, Norbert Vastagh wrote: > 0.00 0.06 0.05 > > E5200 proci, ami éppen 1,2GHz-en megy. A gépen dolgozok: > KDE, OpenOffice több doksival, szól a webrádió, plusz a gép > samba szerver, átjáró, transzparens proxy - néhányan neteznek, > fut dhcp szerver, ftp szerver, web szerver, stb., és ez még így is > kevesebb, mint a több magon és procin a semmilyen meló > közbeni load. Se X, se NET, se samba, se radio. ;) Egy alap-csupasz karakteres disztribucio, az eredetitol a sajat kernelben kulonbozik (jocskan herelt). Gyakorlatilag egy sshd + kb. 4-5 process sleep-ben ami "aktiv". 2 GB RAM-on 2x1.4GHz Xeon-nak ez nem tul nagy feladat egy kb. 80MB/s sebessegu hattertarral, amin kb. 10-20 masodpercenkent megy 200 Blk_wrtn/s az iostat szerint. > Szóval most már én is kíváncsi vagyok, hogy normális-e az > az érték, ami a kolléga gépén van ;-) Nem normalis. Elvileg sikerult javitanom, de az okot meg ne kerdezd. Lehet, hogy a relokalhato kernel vagy a sebessegre optimalizalas a meret helyett javitott rajta, de lehet hogy az Auditing esetleg a Profiling support segitett. Passz. ;) -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: load anomalia
On Fri, 20 May 2011, Attila Rajmund Nohl wrote: >> Termeszetesen tisztaban vagyok vele mi a load, es mivel adott >> korulmenyek gyakorlatilag 0-nak kellene lennie, igy kozel sincs a problema >> megoldva. > > A 0.2 és a 0.7 az gyakorlatilag 0. A 0.2 lehet, de a 0.7 az inkabb majdnem 1. Ezert irtam %-ban (70%). > Ugyanis ha figyelmesen elolvasod amit irtam, se a CPU nem >> dolgozik, se IO-ra nem var semmi. Mi egyeb okozhat meg magas terhelest? > > A 0.2 és a 0.7 nem magas terhelés. Ahhoz kepest hogy _semmit_ sem csinal, boduletesen nagy. > Már hogyne dolgozna. Vagy egy csomó kernelthread a háttérben. A > timerinterruptot le kell kezelni. Stb. Ekkor szokot 0.00/0.00/0.00 lenni, neha be-bevillan egy 0.01/0.00/0.00 2.6.38.6 + par uj parameter utan most stabilan beallt egy 0.00/0.01/0.04 par perce, tehat vagy kernel bug, vagy valami utemezo(-vel kapcsolatos) hianya volt, es (mondjuk) 2 konkurralo sleep() bekavart. ;) -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: load anomalia
On Fri, 20 May 2011, [utf-8] Hegedüs Ervin wrote: >> Sajat forditasu 2.6.35.9 kernelen a load 20 es 70% kozott valtozik annak > > a load %-ban megadva? "éseztígyhogy?" Elnezest, prefixaltam a jobb lathatosag kedveert. Bocs, akkor forditok: A load 0.2 es 0.7 kozott valtozik. >> ellenere, hogy gyakorlatilag semmi sem fogja sem a CPU-t, sem a diszket. >> Neha-neha 0.1%-nyit megmoccan a CPU, illetve par kb-ot kiir a vinyora. >> >> Raadadul ugy, hogy hirtelen felugrik mondjuk 50%-ra, aztan szep lassan >> csokken. Majd megint ugrik. > mármint felugrik a load "50%-ra"? én ezt nem tudom értelmezni... Forditok: felugrik a load mondjuk 0.2-rol 0.5-re. Igen, hirtelen. >> /sys/block/sda/queue/scheduler: noop deadline [cfq] >> >> current scheduling policy: SCHED_OTHER >> >> top - 22:18:17 up 6 days, 5:10, 1 user, load average: 0.37, 0.34, 0.34 >> top - 22:18:53 up 6 days, 5:11, 1 user, load average: 0.55, 0.38, 0.35 > > ebben hol látni ezt a magas load százalékot? Prefixalok: 0.37 = 37% Tudom, ez egyesekben kiveri a biztositekot, azok ne figyeljenek (mert ugysem tudnak segiteni, ha egy egyszeru mertekegyseg-atvaltason leakadnak ;), elnezest kerek erte. Egyebkent nagy valoszinuseggel kernel forditasi opcio hiba lesz, most probalok rajonni mi hianyzik neki. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: load anomalia
On Fri, 20 May 2011, Pirity Tamas Gabor wrote: > Javaslom, hogy inkább nézz utána, mit jelent a load > és utána kényelmesen dőlj hátra a székben, és pipáld ki, hogy probléma > megoldva. Termeszetesen tisztaban vagyok vele mi a load, es mivel adott korulmenyek gyakorlatilag 0-nak kellene lennie, igy kozel sincs a problema megoldva. Ugyanis ha figyelmesen elolvasod amit irtam, se a CPU nem dolgozik, se IO-ra nem var semmi. Mi egyeb okozhat meg magas terhelest? Az sem nyugtat meg, hogy a load 1 alatt van. Most igen, amikor _semmi_ nem dolgozik. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
load anomalia+
On Thu, 19 May 2011, Szima Gábor wrote: > Xeon 3.40GHz Bocs, 2 db CPU (SMP) kernel. Cpu(s): 0.2%us, 0.0%sy, 0.0%ni, 99.5%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2075396k total, 1186340k used, 889056k free,22444k buffers Swap: 256892k total,0k used, 256892k free, 1102428k cached -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
load anomalia
Sziasztok! Sajat forditasu 2.6.35.9 kernelen a load 20 es 70% kozott valtozik annak ellenere, hogy gyakorlatilag semmi sem fogja sem a CPU-t, sem a diszket. Neha-neha 0.1%-nyit megmoccan a CPU, illetve par kb-ot kiir a vinyora. Raadadul ugy, hogy hirtelen felugrik mondjuk 50%-ra, aztan szep lassan csokken. Majd megint ugrik. Ha 1-1 processt kiiktatok, akkor ez mindig par szazalekot csokken. Van egy olyan erzesem, hogy valamilyen utemezo problema lesz. Xeon 3.40GHz, 2xSCSI SOFT-RAID0 (~80 Mb/s), 2 GB ECC RAM, szoval van egy keves loero. /sys/block/sda/queue/scheduler: noop deadline [cfq] current scheduling policy: SCHED_OTHER top - 22:18:17 up 6 days, 5:10, 1 user, load average: 0.37, 0.34, 0.34 top - 22:18:53 up 6 days, 5:11, 1 user, load average: 0.55, 0.38, 0.35 Talalkozott mar valaki ilyesmivel? Hogyan lehetne a load-ot process-bontasban megnezni? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: mail(x) Latin2 text attach
On Sun, 14 Nov 2010, [ISO-8859-1] Kovács Attila wrote: > 2010.11.14. 21:55 keltezéssel, Szima Gábor írta: >> LC_COLLATE (bash) es ttycharset (.mailrc) allitgatasa nem hasznal neki. > Inkább LC_TYPE, illetve a mailcap. Koszi, de nem hasznalt. Viszont mint kiderult, a disztribucioban levo mailx a bunos (12.2), leforditottam az eredetit (12.5) es meggyogyult: http://heirloom.sourceforge.net/mailx.html -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
mail(x) Latin2 text attach
Sziasztok! Hogyan lehetne a mailx-et ravenni arra, hogy ha a csatolmany text/plain, akkor ne UTF-8 -kent ertelmezze, es ne kezdje el (hibara futva - Invalid or incomplete multibyte or wide character) konvertalni? Hanem csak egyszruen base64-elje bele, vagy csak hagyja meg az eredeti kodlappal (ami megegyezik a sencharsets-ben beallitott iso-8859-2 -vel). Az egyeb filetipusokkal (pl. PDF) nincs baj, azt base64-eli es nem ertelmezi, csak a text bajos. LC_COLLATE (bash) es ttycharset (.mailrc) allitgatasa nem hasznal neki. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
X.org Alt+numpad
Sziasztok! Letezik megoldas X alatt az Alt+numpad karakterbevitelre? Turom mar a netet egy ideje, de semmi megoldast nem talaltam eddig ra. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: eth carrier/overruns
On Tue, 12 Oct 2010, Szima Gábor wrote: >> NETDEV WATCHDOG: eth1: transmit timed out >> eth1: Tx timed out, cable problem? TSR=0x16, ISR=0x0, t=23. > > Az archivum kedveert: a switch doglott meg. Pontositok: nem az, amibe be volt kotve a linuxos masina, hanem egy masik gagyi, ami az egyik portra volt radugva. Az pedig idonkent megszorta a halozatot szemettel, es ettol rohadt az egesz. Lattam mar ilyet, hogy hibas halokartya fektette meg a halozatot. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: eth carrier/overruns
On Sat, 2 Oct 2010, Szima Gábor wrote: >>> Ethernet kartyanal a TX carrier es overruns hibak szaporodasa mire enged >>> kovetkeztetni? > >> Nálam megzakkant hálókártya miatt volt ugyanilyen jelenség. > > Probakepp betettem egy teljesen mas tipusu kartyat, ami raadasul 10-es > volt (RTL 8029). Ugyanaz a helyzet, csak a drivere ki is orditott > idonkent: > > NETDEV WATCHDOG: eth1: transmit timed out > eth1: Tx timed out, cable problem? TSR=0x16, ISR=0x0, t=23. Az archivum kedveert: a switch doglott meg. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: eth carrier/overruns
On Wed, 29 Sep 2010, Moczik Gabor wrote: >> Ethernet kartyanal a TX carrier es overruns hibak szaporodasa mire enged >> kovetkeztetni? > Nálam megzakkant hálókártya miatt volt ugyanilyen jelenség. Probakepp betettem egy teljesen mas tipusu kartyat, ami raadasul 10-es volt (RTL 8029). Ugyanaz a helyzet, csak a drivere ki is orditott idonkent: NETDEV WATCHDOG: eth1: transmit timed out eth1: Tx timed out, cable problem? TSR=0x16, ISR=0x0, t=23. Most kapott egy uj vegpontot, amivel valamivel jobb a helyzet, 2 napig nem akadozott, de orankent 1-2 frame es nemi overruns hiba keletkezik. Elkelzelheto ilyen gond PC vas hibabol, vagy ebbol 100% bizonyossaggal megallapithato, hogy a halozat (kabel+switch) a ludas? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: eth carrier/overruns
On Wed, 29 Sep 2010, [utf-8] Hegedüs Ervin wrote: >> Ethernet kartyanal a TX carrier es overruns hibak szaporodasa mire enged >> kovetkeztetni? > > szinte ue volt a tünet IW hosztingban levő gépnél. Kb két hete > felhívtam az operátort, hogy ugyan nézzünk már rá, készségesen > megtette, az autoneg letíltása és a média kézzel történő > beállítása után (-F 100baseTx-FD) 0 lett a hibák száma, és > használható lett a gép. De hogy mitöl/miért jött ez elő... passz. Atallitottam HD-re, de ugyanaz a helyzet. A FD tobbnyire kabelezesi problemanal okoz gondot, en itt switch-re vagy egy megzakkant halokartya altal generalt szemetre gyanakszom. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
eth carrier/overruns
Sziasztok! Ethernet kartyanal a TX carrier es overruns hibak szaporodasa mire enged kovetkeztetni? Percenkent 20-30, neha 50-100 is keletkezik, olyankor akad a halo is. Van nemi RX frame hiba is, kb. a tizede az elobbi kettonek. Evek ota rendben ketyego linux idonkent fogja magat, es bizonyos idoszakokban akadozik a forgalom. Vas/kernel evek ota nem volt piszkalva. Inkabb halozati/switch problema, vagy vas/driver gond lesz? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: bash pipe error handling
On Fri, 14 May 2010, Gergely Madarasz wrote: >> Hogyan lehet egy pipe elso tagjanak return statuszat is elcsipni? > set -o pipefail Ez az, koszi! -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
bash pipe error handling
Sziasztok! Hogyan lehet egy pipe elso tagjanak return statuszat is elcsipni? Pelda: # cat /tmp/abc | des -e3k >/tmp/abc.des cat: /tmp/abc: No such file or directory # echo $? 0 Azaz mintha minden rendben lenne. Ami igaz is a cso masodik tagjara, mert az rendben megcsinalta a dolgat. De hogyan tudom kideriteni az elso tag statuszat _is_? Tehat tudnom kellene rola, ha a lancban barhol fennforgas van. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: local portforward
On Mon, 10 May 2010, Ferenc Wagner wrote: >> Parancs, viszont az 1234 port csak localhost-on figyel, igy a kivulrol >> indulo keresek visszapattannak a 192.168.2.1:1234 -rol. > > Ez rendben? > >Specifying a remote bind_address will only succeed if the server's >GatewayPorts option is enabled (see sshd_config(5)). Most mar igen, es mukodik is rendesen. Koszonom a segitseget! -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
local portforward
Sziasztok! Egy reges-reg elfeledett linuxrol kellene osoreg (2001-es 3.9p1) ssh-val remote portforwardot csinalni. Elvileg mukodik az ujgep# ssh -R192.168.2.1:1234:loaclhost:80 Parancs, viszont az 1234 port csak localhost-on figyel, igy a kivulrol indulo keresek visszapattannak a 192.168.2.1:1234 -rol. Uj ssh-val menne rendesen, de a regitol csak ez telik. Cserere nincs mod, nem akarom tavolrol beboritani emiatt. Mit lehet legyorsabban osszehozni az hogy eth -> lo forwardra? iptables? Vagy van egyszerubb modszer? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: mdadm raid10 szetesik
On Sat, 1 May 2010, [utf-8] Hegedüs Ervin wrote: >> Mekkora is a vinyo (500GB)? >> Hol van a hiba helye... (500GB)? >> Veletlenul nem egy rossz particionalas, es tulfut az olvasas? > > és félévente 1x? Aztán másik diszknél 2 nap alatt 2x? Mert elert egy bizonyos telitettseget, es elkezdte hasznalni azt a reszt is. Akkor szetesett, uj diszknel is hasznalgatta - az is. Jartam mar igy (igaz nem raid, raadasul fat FS) gyarilag (gagyin) formazott K*ngst*n PEN drive-al. De mint kiderult nem ez az ok, hatul MD superblock van. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: mdadm raid10 szetesik
On Sun, 2 May 2010, Gabor Gombas wrote: >> Mekkora is a vinyo (500GB)? >> Hol van a hiba helye... (500GB)? >> Veletlenul nem egy rossz particionalas, es tulfut az olvasas? > > Nem. Szimplan csak ott van az MD superblock. Eddig abban a tudatban voltam, hogy az elejen van, de utananeztem: az utolso 1..12k-n talalhato. -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: mdadm raid10 szetesik
On Fri, 30 Apr 2010, [UTF-8] "Kónya Zoltán (EVM)" wrote: > "A két nappal ezelőtti üzenet ez volt: > ... > . > > [34845002.313723] end_request: I/O error, dev sdc, sector 976767935" > > a mostani meg ez? > "[86349.425488] end_request: I/O error, dev sdc, sector 976767935" > ha jól látom ugyanarra a HW sectorra hivatkozik a két különböző disk esetén!? Mekkora is a vinyo (500GB)? Hol van a hiba helye... (500GB)? Veletlenul nem egy rossz particionalas, es tulfut az olvasas? > lehet, hogy elnéztem, ha nem, akkor inkább kernel bug lehet!? Vagy fdisk. ;) -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
HW-bug lokalizalas
Sziasztok! Egy regebbi gep a legvaltozatosabb hibakkal vagja ki az ssh kapcsolatot: *** glibc detected *** double free or corruption (out): 0x080ca160 *** print_command: bad command type: 135111360 *** glibc detected *** free(): invalid next size (normal): 0x080de630 *** # su - Segmentation fault Mire erdemes leginkabb gyanakodni: RAM, CPU, beserult filesys? -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: van-e host a tartomanyban
On Tue, 16 Mar 2010, Hofferek Attila wrote: >> Miért hosszú? > > Mert egy pingelés min. 1 mp Background ping? (&) Leteker fel mp alatt 250 parhuzamos ping-et, csak gyozd kapkodni a fejed. :) Ha ugyes vagy, akkor a talalatokat ki tudod gyujteni (&&). -Sygma _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
