Témata

61

/dev/null / Co u URL znamená _/_/context/

« kdy: 20. 12. 2020, 19:25:52 »

Co v části URL znamená

Kód: [Vybrat]

_/_/context/ 
_/batch
_/_/trace
_/error
_/

je to na webech jako pinterest, medium...
Nějaká jaká funkční část jakého frameworku?
Jsou i jednopodrtžítkové varianty (bez druhyho _/)
Většinou obsahují dlouhá POST data různé objekty , výpisy javascriptu

Nepotřebuji vědět, že to je textový řetězec nebo je to část URL zvaná path., mě zajímá konkrétní význam.

62

/dev/null / Co je to u twitteru

« kdy: 19. 12. 2020, 12:40:33 »

Co na odkazu znamená ?protected_redirect=true ? (např twitter.com/uzivatel/?protected_redirect=true)

63

Sítě / Počet IRQ/sec na paket při trafficu

« kdy: 10. 12. 2020, 15:40:10 »

Spustil jsem monitor přerušení a sleduji počet přerušení za sekundu pokud probíhá traffic na routeru (při velkém downloadu (vnější je wlan); přímo stahuje stroj a nebo to forwarduje na jiný stroj v síti přes druhé další rozhraní)

Jde o rychlost kolem 5 MB/s. Při tom mám 15000 IRQ/s, Vychází to na 220-300 bajtů na IRQ. Při 1500b paketech tedy 5až7 IRQ/na paket (ignoruji ACK pakety, ale to je možná je nebezpečný krok zanedbání malého paketu, který ve výsledku nemá být ignorován, možná to zkreslí úvahu, ale vycházím z toho, že tyto ack pakety jsou menší a jsou tak v v poměru jeden ACK na 2-3 příchozí)

na jeden 1500b paket vychází 5-7 IRQ. Dá se to nějak Odůvodnit?
V příloze je screenshot z watch  -n 4 -d  cat/proc/inte...rupts po 4 sekundách(ty bílé obdélníky  je zvýraznění díky -d)

 .... mmc1 je pravděpodobně  wifi karta , řádek 56 je síťovka na USB, pak je tam DMA IRQ


při kopírování z eth0 to je 2 IRQ na 1500b paket



Co je ještě zajímavější, tento počet je uplně stejný při forwardování i při stahování přímo do zkoumaného stroje, a dokonce i při uploadu ... vypadá to jako kdyby traffic na eth generoval 3.5x méně přerušení , takže se to může zdát že při přenosu z wlan do stroje nebo forwardování  je celkový počet IRQ/paket skoro stejný


Je běžné, že obsluha paketu si žádá víc než 1 IRQ?

64

Sítě / Může si síťový prvek „najít cestu“ i bez DHCP?

« kdy: 09. 12. 2020, 11:58:45 »

Je možné, že třeba nějaké zařízení (které má jedno interface) si dokáže "najít cestu" pro komunikaci, i když "není v síti" vítaný?

Tím myslím, že když mu DHCP server nesdělí adresu brány a nebo ještě víc, ho DHCP neobslouží. Tak, že Zařízení může  na základě  příchozích a odchozích broadcast paketů a  ARP  odhadnout ip adresu brány a dle potřeby ještě používané IP a rozsah sítě.

Je to možné? Že si vydedukuje adresu brány (stačí jen MAC vlastně) zkusí nějakou IP z rozsahu. Samozřejmě za přepokladu, že router  nemá nějaká opatření jako whitelist, vpuštění síti jen po DHCP... A neřeším DNS.

65

Windows a jiné systémy / Podpora iOS aplikací na intel Macboocích

« kdy: 08. 12. 2020, 18:21:04 »

Prý Big Sur umožní spouštět ipadové a iosové aplikace. Bude to ale fungovat na Macboocích s Intel procesormi?

(titulek:Podpora iOS aplikací na intel Macboocích)

66

/dev/null / iptables -Z jde jen u OUTPUT, jinak hlásí chybu

« kdy: 08. 12. 2020, 17:09:58 »

Hází mi a neresetuje čítače. Nevíte čím to?

Kód: [Vybrat]

sudo iptables -v -Z INPUT nebo FORWARD
iptables v1.8.2 (nf_tables):  RULE_REPLACE failed (Invalid argument): rule in chain FORWARD

U OUTPUT ale OK. Počet pravidel u F/I/O je asi 15/10/8.
V OUTPUT jsou jen pravidla -i/-o /dst/src, ale v FORWARD / IN jsou i ctstate,nebo pro match portu...

Znamená ta chyba že tam mám neplatné pravidlo? Takové by se ani přece nevložilo.

67

/dev/null / Znemožnění sniffování na linkové úrovni u veřejné WPA2

« kdy: 08. 12. 2020, 13:35:35 »

Mám situaci: veřejná wifi s veřejným heslem (například ve fastfúdu). Heslo je tedy známé, šifrování je WPA2. Útočník sniffuje provoz. WPA2 zaručuje, že není možné sniffovat provoz lidí, kteří se připojili před tím než útočník začal sniffovat.

Ale samozřejmě může sniffovat nově příchozí. Nebo může udělat "glitch na wifi", že způsobí rozpojení a oběti se připojí znova.

Otázky:

1. Je to z principu logické, že když je známé veřejné heslo ,že nelze očekávat, že si útočník (a klienti, ale mezi tím není rozdíl v důsledku  - ti taky znají heslo) může vidět linkovou komunikaci?

2. Řeší toto WPA3 ?

3. Dá se to řešit bez WPA3?

4. Dá se to řešit bez WPA3 a bez toho, že by každému bylo přiděleno nějaký unikátní přihlašovací údaje (což by byl opruz v cafetériích s veřejnou wifi)?

68

Sítě / Reset statistik RX, TX, iwconfig, ip

« kdy: 08. 12. 2020, 13:25:40 »

Hledám způsob jak, resetovat statistiky příkazu iwconfig nebo ip -s link. Zkoušel jsem ip link set up&down,bez efektu.

Čekal bych že to bude fungovat bez dočasného výpadku připojení (rozhraní), ale není to podmínkou.

Samozřejmě mohu vytáhnout server  ze zásuvky a spustit, ale hledám nějaké elegeantní řešení (nemyslím teď ethtool -G rx xyz;ethtool -G rx puvodni které stejně nefunguje nebo vyndavání a zasouvání jaderných modulů).

69

Software / Nefunguje mall.tv videa v novější verzi chrome, ve starší ano

« kdy: 07. 12. 2020, 12:44:06 »

Překvapilo mě, že gardo problému je Opačné. Tedy v novější verzi chrome 84 nefungují videa na mall.tv.

Ale na starší verz 65 Ano... Kde může být chyba

CO VID ím ve výpisu konzole(84):

Kód: [Vybrat]

DOMException: The play() request was interrupted by a call to pause()

Uncaught ReferenceError: $ is not defined
    at main?v=05OfBbgYbscyUVZ98bEDHzLUi36f3pmrUGRIcvxWmHY1:1
(anonymous) @ main?v=05OfBbgYbscyUVZ98bEDHzLUi36f3pmrUGRIcvxWmHY1:1
video?v=ZRjc-Qr44WTToWxo9YwbxHztcRRoc3yJ59T9wyqz3M01:1 Uncaught ReferenceError: $ is not defined
    at video?v=ZRjc-Qr44WTToWxo9YwbxHztcRRoc3yJ59T9wyqz3M01:1
(anonymous) @ video?v=ZRjc-Qr44WTToWxo9YwbxHztcRRoc3yJ59T9wyqz3M01:1
​
video?v=ZRjc-Qr44WTToWxo9YwbxHztcRRoc3yJ59T9wyqz3M01:1 Uncaught ReferenceError: $ is not defined
    at video?v=ZRjc-Qr44WTToWxo9YwbxHztcRRoc3yJ59T9wyqz3M01:1
    at Object.<anonymous> (video?v=ZRjc-Qr44WTToWxo9YwbxHztcRRoc3yJ59T9wyqz3M01:1)

Také tag video nemá src, je to jen <video autoplay="" playsinline="" crossorigin="anonymous"></video>

70

Windows a jiné systémy / Hardwarová akcelerace VP9 na Haswell ve Windows 7

« kdy: 05. 12. 2020, 18:52:29 »

Chci zprovoznit HW akceleraci dekodovani vp9 na Windows 7, CPU Haswell mobilní.
Tady na tom linku jsem se dočetl, že by to mělo umět partial hw dekodování (čemuž rozumím, že to bylo doprogramováno až po vydání fysického  Intel Silicon-u a je to tam dobastlené přes nějaké shadery, takže to asi bude efektivní někde napůl mezi SW decodingem a HW decodingem  spotřebou třeba jako u H264)
Nahodil jsem tedy nový driver
Dokonce se raduji z poznámky New features: ...- Improved video playback through partial hardware acceleration support for the VP9 video format..

Ale po restartu jsou výsledky stejné: zatížení CPU je furt 100% u 4K(13W) , kolem 90% u 1440p(12W), 50% u FULL_HD(9W), což je situace stejná jako před instalací.. Spotřeba grafiky GT Power furt kolem 1-3W. 4K se je hodně sekané, 1440p občas.  (Odbočka 4K H264 je naprosto OK)
Zkoušeno v chromu na youtube a pak v MPC playeru, který podporuje hw akceleraci(reálně funguje mi na h264), v options má samozřejmě i volby pro AV1,VP9, h264 a všude je na výběr zakázáno nebo VLD bit strem. Stejně se mi ale pak v přehrávači ukazuje že dekodování probíhá přes ffmpeg threaded. A jde samozřejmě o 8bit yuv420p

Ptám, se funguje to někomu nebo jsem nesplnil a přehlédl nějaký předpoklad?



A řečnická otázka: umí linux "~HW" akceleraci dekodování VP9 na Haswellu?

71

Sítě / Hodnoty ip --stats se u Wi-Fi samy resetují

« kdy: 05. 12. 2020, 15:05:05 »

Narazil jsem na trochu nepříjemnou věc: proč  hodnoty u ip --stats -h addr jsou nižší (nebo se resetují, ale nevím kdy a proč)? Očekával bych tam kolem ~50GB/2GB(pro oba směry). (souhlasí s příslušnými iptables -nvL u FORWARD u ACCCEPT pro dané směry)

U eth0 se neresetují, je tam 50GB/2GB, ani když vytáhnu kabel, hodnoty zustanou...

Samozřejmě v iptables v-nvL vidím "vše". K tomu  mám otázku bokem: Chtěl bych nějak mí statistiku přenosů, toků. Nějak základně se k tomu dá iptables použít (že si dám poslední pravidlo ACCEPT a nějak tam udělám roztřídění podle cílové/zdrojové adresy), ale je to fungující jen pro opravdu malý počet sledovaných parametrů (a třeba jen pro in/out, pro počítače uvnitř, a neumí to dělit na časové období a  rozlišovat podle protější adresy by znamenalo kartézský součina pravidel --src --dst, takže  nemyslitelné). Co by se hodilo pro nějaké lepší monitorování (prometheus/grafana nabo cacti/rrdtool/mrtg)?

Všiml jsem si jedné věci: toto vrací ip link/addr:

Kód: [Vybrat]

: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ... připojeno
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 ... když je killnutý wpa_supplicant-nepřipojeno

což bych očekával, že tam bude rozdíl. Ale hodnoty před a po odpojení jsou totožné. Zde se reset neděje (přesněji řečeno: odpojení reset nevyvolává)


rese
Původně jsem se chtěl zeptat na podobnou věc ještě u příkazu iw wlanx link, ale ještě si to rozležím v hlavě:

fun fact?: asi jsem vyhrál sportku  zrovna:

Kód: [Vybrat]

iw wlan0 link
        RX: 4 294 610 786 bytes (33483598 packets) ... (2^32 je 
4 294 967 296)
        TX: 2515682125 bytes (10368959 packets)

... chvíle poté:

        RX: 885175 bytes (33485308 packets) ... mod 2^32 ?
        TX: 2 515 802 652 bytes (10369946 packets)

(co je jistě, že po resetu wpa_supplicant se hodnoty iw wifina link resetují,  ale u ip -s -h a ). Do třetice, ty hodnoty nesouhlasí, vypadá to, že ip -s ukazuje i větší hodnoty než 4 miliardy


Takže když to shrnu: proč se resetují hodnoty u ip -s -h addr? (očividně ano, když tam není 50GB) Neresetují se, když dojde ke ztrátě zpojení/odpojení (to se ale se resetují hodnoty iw wlan0 link). + Do toho bonus s tou sportkou u iw wlan0>4GB (nedá se vyloučit, že by i tento problém postihoval ip -s, prověřím)

Nějaká jiná událost než odpojení wpa_supplicant (rfkill či "odpojení karty na nižší úrovni")?


Jaký by mohl být důvod resetu hodnot u ip -s -h link ?

72

Hardware / Chvilkové výpadky obrazu ve Fedoře

« kdy: 02. 12. 2020, 21:45:28 »

Nevíte čím by mohlo být, že mi v linxu na fedoře asi 5x za hodiny "vypadne obraz"? Obrazovka je černá asi na sekundu, myslím že monitor ani nedetekuje nepřítomnost signálu (buď krátká doba nebo tam jde černá rly) ,..
Jediné čeho jsem si všiml v dmesg, je [

Kód: [Vybrat]

(563 sekund po bootu)[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

nejspíš asi ve stejné době, kdy se stal první výpadek. (grep -C 10  fifo_und) v okolí logu nic souvisejícího není, ani časově (předtím je čas 16s a potom čas 2700s). Tato hláška je tam jen  jednou.

Nijak jinak se to neprojevuje(že by se něco ukončilo nebo odpojilo)

Monitor je připojený přes displayport. Nikdy jindy jsem si toho nevšiml , bootoval jsem stejně jako vždy. Ani monitor to nikdy jindy s jiným pc nedělal.

73

Hardware / Tříminutové záseky disku

« kdy: 02. 12. 2020, 21:34:29 »

Občas u disku pozoruji, že se na 3 minuty totálně zasekne, iostat hlásí 100% util. programy buď se také zaseknou a nebo ukáží hlášku nějakou že něco nejde . Po té horké chvilce disk zase jde, dokončí se příkazy, ukáží se hlášky...

Je to projev SMR?


Teď se to stalo, když jsem vytvořil 700GB FAT32 oddílv gnome-disks. poté se ukázala hláška něco ve smyslu 4.1kB (4096b) se nepodařilo načíst g-io-disks-quark. Asi to formátovalo a zkoušel i dávat cancel u Erasing

dmesg:

Kód: [Vybrat]

[ 7006.557226] usb 2-3.3: USB disconnect, device number 32
[ 7095.201310] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 7095.322234] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[ 7095.369186] usb 2-4: USB disconnect, device number 28
[ 7129.632135]  sdd: sdd1
[ 7561.205717]  sdd: sdd1
[ 7656.926673] sd 3:0:0:0: [sdd] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD 
[ 7656.926683] sd 3:0:0:0: [sdd] tag#1 CDB: ATA command pass through(16) 85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00
[ 7709.651417] sd 3:0:0:0: [sdd] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD 
[ 7709.651423] sd 3:0:0:0: [sdd] tag#0 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
[ 7709.651427] scsi host3: uas_eh_bus_reset_handler start
[ 7714.771360] usb 2-1: Disable of device-initiated U1 failed.
[ 7719.891357] usb 2-1: Disable of device-initiated U2 failed.
[ 7719.995699] usb 2-1: reset SuperSpeed USB device number 33 using xhci_hcd
[ 7720.010656] scsi host3: uas_eh_bus_reset_handler success
[ 7720.010905] sd 3:0:0:0: [sdd] tag#1 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
[ 7720.010913] sd 3:0:0:0: [sdd] tag#1 CDB: ATA command pass through(16) 85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00
[ 7824.733537] sd 3:0:0:0: [sdd] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD 
[ 7824.733547] sd 3:0:0:0: [sdd] tag#4 CDB: ATA command pass through(16) 85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00
[ 7850.706898] sd 3:0:0:0: [sdd] tag#5 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD IN 
[ 7850.706908] sd 3:0:0:0: [sdd] tag#5 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00
[ 7850.706955] scsi host3: uas_eh_bus_reset_handler start
[ 7850.709510] sd 3:0:0:0: [sdd] tag#6 uas_zap_pending 0 uas-tag 7 inflight: CMD 
[ 7850.709520] sd 3:0:0:0: [sdd] tag#6 CDB: Read(16) 88 00 00 00 00 00 00 00 04 00 00 00 04 00 00 00
[ 7850.709526] sd 3:0:0:0: [sdd] tag#7 uas_zap_pending 0 uas-tag 8 inflight: CMD 
[ 7850.709530] sd 3:0:0:0: [sdd] tag#7 CDB: Read(16) 88 00 00 00 00 00 00 00 08 00 00 00 04 00 00 00
[ 7850.709534] sd 3:0:0:0: [sdd] tag#8 uas_zap_pending 0 uas-tag 9 inflight: CMD 

...až do tagu 29


[ 7850.814639] usb 2-1: reset SuperSpeed USB device number 33 using xhci_hcd
[ 7850.828712] scsi host3: uas_eh_bus_reset_handler success


nyní od tagu 29 k 1

[ 7882.205969] sd 3:0:0:0: [sdd] tag#13 uas_eh_abort_handler 0 uas-tag 14 inflight: CMD IN 
[ 7882.205972] sd 3:0:0:0: [sdd] tag#13 CDB: Read(16) 88 00 00 00 00 00 00 00 34 00 00 00 04 00 00 00
[ 7882.206011] sd 3:0:0:0: [sdd] tag#12 uas_eh_abort_handler 0 uas-tag 13 inflight: CMD IN 
[ 7882.206014] sd 3:0:0:0: [sdd] tag#12 CDB: Read(16) 88 00 00 00 00 00 00 00 30 00 00 00 04 00 00 00
[ 7882.206053] sd 3:0:0:0: [sdd] tag#11 uas_eh_abort_handler 0 uas-tag 12 inflight: CMD IN 
[ 7882.206056] sd 3:0:0:0: [sdd] tag#11 CDB: Read(16) 88 00 00 00 00 00 00 00 2c 00 00 00 04 00 00 00
[ 7882.206106] sd 3:0:0:0: [sdd] tag#10 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD IN 
[ 7882.206112] sd 3:0:0:0: [sdd] tag#10 CDB: Read(16) 88 00 00 00 00 00 00 00 28 00 00 00 04 00 00 00
[ 7882.206162] sd 3:0:0:0: [sdd] tag#9 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD IN 
[ 7882.206167] sd 3:0:0:0: [sdd] tag#9 CDB: Read(16) 88 00 00 00 00 00 00 00 24 00 00 00 04 00 00 00
[ 7882.206213] sd 3:0:0:0: [sdd] tag#8 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD IN 
[ 7882.206218] sd 3:0:0:0: [sdd] tag#8 CDB: Read(16) 88 00 00 00 00 00 00 00 20 00 00 00 04 00 00 00


... tady někdy přišel zase k životu

[ 7885.545762] usb 2-1: stat urb: no pending cmd for uas-tag 5
[ 7892.495569] usb 2-1: stat urb: no pending cmd for uas-tag 6
[ 7899.445371] usb 2-1: stat urb: no pending cmd for uas-tag 7
[ 7906.395204] usb 2-1: stat urb: no pending cmd for uas-tag 8
[ 7911.890101] sd 3:0:0:0: [sdd] tag#27 uas_eh_abort_handler 0 uas-tag 28 inflight: CMD 
[ 7911.890111] sd 3:0:0:0: [sdd] tag#27 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
[ 7911.890121] scsi host3: uas_eh_bus_reset_handler start
[ 7911.996318] usb 2-1: reset SuperSpeed USB device number 33 using xhci_hcd
[ 7912.010877] scsi host3: uas_eh_bus_reset_handler success
[ 7912.011108] sd 3:0:0:0: [sdd] tag#27 Medium access timeout failure. Offlining disk!
[ 7912.011122] sd 3:0:0:0: Device offlined - not ready after error recovery
[ 7912.011139] sd 3:0:0:0: [sdd] tag#4 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
[ 7912.011147] sd 3:0:0:0: [sdd] tag#4 CDB: Read(16) 88 00 00 00 00 00 00 00 10 00 00 00 04 00 00 00
[ 7912.011153] blk_update_request: I/O error, dev sdd, sector 4096
[ 7912.011182] sd 3:0:0:0: rejecting I/O to offline device
[ 7912.011189] sd 3:0:0:0: [sdd] killing request
[ 7912.011197] sd 3:0:0:0: rejecting I/O to offline device
[ 7912.011203] sd 3:0:0:0: [sdd] killing request
[ 7912.011208] sd 3:0:0:0: rejecting I/O to offline device
[ 7912.011215] sd 3:0:0:0: [sdd] killing request
[ 7912.011220] sd 3:0:0:0: rejecting I/O to offline device
[ 7912.011227] sd 3:0:0:0: [sdd] killing request
[ 7912.011231] sd 3:0:0:0: rejecting I/O to offline device
[ 7912.011236] sd 3:0:0:0: killing request
[ 7912.011241] sd 3:0:0:0: rejecting I/O to offline device
[ 7912.011247] sd 3:0:0:0: [sdd] killing request
[ 7912.011257] sd 3:0:0:0: rejecting I/O to offline device
[ 7912.011269] sd 3:0:0:0: rejecting I/O to offline device
[ 7912.011280] sd 3:0:0:0: rejecting I/O to offline device
[ 7912.011289] sd 3:0:0:0: rejecting I/O to offline device
[ 7912.011298] sd 3:0:0:0: rejecting I/O to offline device
[ 7912.011316] sd 3:0:0:0: [sdd] tag#5 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
[ 7912.011322] sd 3:0:0:0: [sdd] tag#5 CDB: Read(16) 88 00 00 00 00 00 00 00 14 00 00 00 04 00 00 00
[ 7912.011326] blk_update_request: I/O error, dev sdd, sector 5120
...
[ 7912.011518] sd 3:0:0:0: [sdd] tag#13 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
[ 7912.011523] sd 3:0:0:0: [sdd] tag#13 CDB: Read(16) 88 00 00 00 00 00 00 00 34 00 00 00 04 00 00 00
[ 7912.011527] blk_update_request: I/O error, dev sdd, sector 13312
[ 7912.011699] sd 3:0:0:0: rejecting I/O to offline device
[ 7912.011705] sd 3:0:0:0: [sdd] killing request
[ 7912.011828] sd 3:0:0:0: rejecting I/O to offline device
[ 7912.014828] sd 3:0:0:0: rejecting I/O to offline device

Může to někdo přeložit z kernel ultraštiny do češtiny, co se dělo počas disk se zmítal? Nepotřebuji  z angličtiny.
jmenovitě (takhle z kontextu vytržené se to hodí jen pro dohledání, samotné útržky asi nic neřeknou spíš mezi kterými dvěma světy se disk nacházel a které vrstvy mezi sebou zápasí):
uas_eh_abort_handler
CDB
uas reset handler
termín tag#
uas_zap_pending
Medium access timeout failure. Offlining disk!
not ready after recovery
hostbyte=DID_
blk_update_request: I/O error
rejecting io to offline
killing request

je tohle normální chování disku? Nebo je vadný nebo jde o záchvat SMR(t)?

74

/dev/null / Ovládání přehrávače v Chrome – kde se vzalo

« kdy: 25. 11. 2020, 16:15:04 »

V nové verzi chromu (kolem 80) jsem si všiml že mezi tlačítkem Anonymní a  a vertikálního oddělovače tlačítek rozšíření se objevilo nové, s symbolem horizontálních čar a noty (Ovládejte hudbu, video a další obsah. Po najetí se ukáže (dokonce i na jiném tabu v jiném okně!) obrázek webu a tlačítka pro přehrávání.

jak se to tam vzalo a odkude bere prohlížeč informaci o tom?

(obrázek v příloze

75

Hardware / Nabíječka dá 2 A do powerbanky, ale ne do mobilu

« kdy: 22. 11. 2020, 17:23:59 »

Jak vysvětlit, že nabíječka nenabíjí mobil 1A?
Nabíječka (Umí i 9V) umí 2A, powerbanku dobíjí tímto proudem. (nezáleží na konektoru powerbanky)
Powerbanka umí (umí i 12V) dobít až 3A, mobil dobíjí proudem 1.2A.
Nabíječka nabíjí mobil (vždy5V) proudem 0.49A.  S vyjímkou první sekundy, to se ukáže 1A (občas, hodně záleží na pořadí zapojení). začarovaný trojúhelník


Proč tedy z mobil bere 0.43A z nabíječka, zatímco z powerbanky 1.2A, když kabel je použit uplně stejný?


Nabíječka má USB-A port. Mobil USB-C.