Byla vydána Java 27 / JDK 27. Nových vlastností (JEP - JDK Enhancement Proposal) je 9.
Byl vydán Mozilla Firefox 156.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Vestavěný prohlížeč PDF se nyní spouští o 45 % rychleji. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 156 bude brzy k dispozici také na Flathubu a Snapcraftu.
Článek na Raspberry Pi představuje nový vzhled desktopu operačního systému Raspberry Pi OS v aktuálním vydání 2026-09-15.
Nové verze Roundcube Webmailu 1.6.19 a 1.7.4 řeší několik zranitelností.
Na Kickstarteru běží kampaň na podporu hloupého (jenom volání a SMS) tlačítkového DIY telefonu MAKERphone 2.0 od společnosti CircuitMess postaveného na ESP32-S3 a volitelně také s hodinkami MAKERband. S možností psaní vlastních aplikací. S volitelnými HW rozšiřujícími moduly.
Byla vydána nová verze 10.7 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyly balíčky HomeBox a Scrypted.
OpenRGB (GitLab) dospěl do verze 1.0 (YouTube). OpenRGB (dříve OpenAuraSDK) je svobodný multiplatformní software umožňující nastavení podsvícení celé řady různých „herních“ komponent a periferií.
Dnes startuje prodej headsetu Steam Frame. Počínaje dneškem se tedy můžete zapsat na seznam pro jeden z následujících modelů: Steam Frame 256 GB za 1 049 EUR a Steam Frame 1 TB za 1 279 EUR.
Vládní CERT upozorňuje na kritickou zranitelnost v GitLab Community Edition (CE) a Enterprise Edition (EE). Zranitelnost CVE-2026-85706 typu path traversal v Repository Commits API dosahuje skóre CVSS 10.0. Kvůli nedostatečnému omezení cest a chybějícímu vynucení autentizace může za určitých podmínek neautentizovaný útočník číst libovolné soubory ze serveru GitLab, a získat tak přístup k citlivým datům a konfiguraci instance.
Linux může běžet nativně na ESP32-S3 – bez emulace a rovnou s 9,7″ e-paperem.
mem=4G kernelu. Při zjišťování dostupné paměti RAM ale různé programy ukazovaly hodnotu pouze 3,74 GB.
Příklad výpisu z dmesg:
BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 00000000dfd78000 (usable) BIOS-e820: 00000000dfee0000 - 00000000dfee3000 (ACPI NVS) BIOS-e820: 00000000dfee3000 - 00000000dfef0000 (ACPI data) BIOS-e820: 00000000dfef0000 - 00000000dff00000 (reserved) BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved) BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved) BIOS-e820: 0000000100000000 - 0000000120000000 (usable)Všimněte si, že north bridge prokládá úseky použitelné RAMky jinými úseky, do kterých jsou mapované různé IO funkce. A pokud správně koukám, v mapě zbyl i nějaký „vzduch”. Takže kus použitelné RAMky přeteče přes 4 GB. Shodou okolností to podle mého odpovídá tomu poslednímu úseku, tj. 0,5 GB od
0x100000000 výše. Podle mého, pokud Vy kernelu nastavíte strop na 4 GB, tak oříznete tu oblast fyzického adresního prostoru CPU, co je hardwarem mapována nad 4 GB, takže zůstane nevyužita.
Dokumentace kernelu je sice v tomto bodě dost mlhavá, mluví obvykle o „system memory”, takže není jasné, zda se mluví o RAMce nebo o „fyzickém adresním prostoru CPU“ (adresa určená piny A0-A35 v patici procesoru). Podle mého z této situace plyne, že kernelovým command-line argumentem mem=4G omezíte nikoli RAMku, ale fyzický adresní prostor.
Svého času jsem narazil na problém, že některé čipsety od Intelu, přestože podporují CPU s fyzickým adresním prostorem 36 bitů (ať už přes PAE nebo EM64T), mají z north bridge nadrátováno pouze 32 adresních bitů, takže de facto mrzačí fyzický adresní prostor CPU na 4 GB. Týká se to konkrétně jednoprocesorových čipsetů i915, i925 a i7221 (P4/LGA775). Tenhle problém se v úvodu zmíněné základní desky netýká (C2D a i965 umí 36 bitů), což ostatně dokazuje i BIOSem sdělená mapa e820 – u výše uvedených čipsetů nepřekročí hranici 4 GB neboli 0x100000000.
Dostal jsem tehdy od výrobce motherboardu jakési postarší PDFko od Intelu, které je dnes už spíše archivní (rok 2004), nicméně je značeno „Intel Confidential” a nikde na webu jsem ho nevygoogloval, takže si nedovolím ho zveřejnit, přestože je v podstatě neškodné. Nicméně přikládám alespoň tabulku, kde jsou hezky vidět různě velké kusy rezervovaného fyzického adresního prostoru.
Podle údajů z té tabulky bych řekl, že 512 MiB je zabráno převážně PCI a PCI-e config spacem. Řekl bych, že výše zmíněný čipset s adresním prostorem zachází ještě vcelku ohleduplně, s ohledem na to, že pro něj 4GB hranice nepředstavuje problém
Co s tím dál?
Pro mne z výše uvedeného plyne, že za tuto situaci možná nemůže hardware ani BIOS. (Přesto bych se zkusil podívat po novější verzi BIOSu, člověk nikdy neví. Může to mít nějakou vazbu na ACPI bugy při konfiguraci PCI apod.)
Kdo za to může: nevylučuji, že za to může kernelový ovladač nějakého PCI zařízení, který není 64bit ready, a sáhne v paměti někam, kam nemá. Nebo to teoreticky může být problém někde uvnitř nejintimnějších vnitřností Linuxu, v oblasti správy paměti a mapování PCI MMIO oblastí, PCI DMA apod. Tomu ale moc nevěřím… Nejsem natolik zběhlý v oblasti PCI, abych dokázal říct, jestli to může být třeba chybou hardwaru PCI periferie, která umí pouze 32bitovou adresaci DMA přenosů (přestože PCI i 32bitová už nějakou dobu umí 64bitovou adresaci, pomocí „dual address cycle”), zda vůbec Linux podporuje PCI DMA do „high memory” apod. Ona taky adresace PCI není 1:1 s adresací hostitele, opět je tam nějaké mapování, takže těžko říct, zda se tento druh chyby může uplatnit. Každopádně se zdá, že pokud kernelu vnutíte omezení na 32bitový fyzický adresní prostor, tak se mu hračky nerozkutálejí…
Pokud máte čas a náladu to trápit, zkusil bych možná:
irqpoll – šance, že za to můžou IRQčka, je poměrně malá, ale za vyzkoušení nic nedáte.
Dokument vytvořil: Filip Jirsák, 7.8.2007 13:53 | Poslední úprava: Käyttäjä 11133, 12.8.2007 13:44 | Další přispěvatelé: Filip Jirsák | Historie změn | Zobrazeno: 1948×
Tiskni
Sdílej: