A FreeBSD 5.1 felhasználók az elmúlt időszakban véletlenszerű adatsérülési és adatvesztési hibával nézhettek szembe. Bosko Milekic ezért egy patchet készített, amely segítségével elkerülhető az adatvesztés.

A hiba oka egyelőre eléggé rosszul körülhatárolt, a workaround pedig az, hogy a kernel fordításnál használni kell a 'DISABLE_PSE' és 'DISABLE_PG_G' opciókat. Ha Bosko foltját használjuk, ezek az opciók szükségtelenek ahhoz, hogy megelőzzük az adatsérülést.

Bosco levele:Date: Mon, 11 Aug 2003 10:05:49 +0000

From: Bosko Milekic

To: freebsd-current@freebsd.org

Subject: 5.1, Data Corruption, Intel, Oh my! [patch]

Message-ID:

[If you're not interested in the history and technical information, and just want to try this out, please scroll down to after the [*]].

Hi,

Over the past few months, it seems that some of our 5.x users have been plagued by various random data corruption problems on some version(s) of the Intel Pentium IV chip (and in another form, on some version(s) of the Intel Pentium Pro and Pentium II chips).

While in several instances the problem has been traced to faulty memory, in some others a work-around solution has been in use. That workaround was to include the DISABLE_PSE and DISABLE_PG_G options in the kernel. It appears to have "solved" the problem.

Although not documented (at least not publically from what I could find), there does appear to be [a] bug[s] on some Intel chips that has to do with PSE, PG, and how their co-existence with legacy 4K page mappings. While the exact details of the bug are to me unknown, some others have come up with reasonable hypothesis and detailed accounts (over my head, but Terry has a fairly consistent one).

Regardless, I have come up with a patch that hopefully solves the data corruption problem for those of you who have been running with DISABLE_PSE and DISABLE_PG_G in your kernels. The patch is attached to this Email.

What the patch does does not directly uncover the true nature of the bug (as I don't know that myself), but it does appear to solve the problem at least for a couple of users I've been confirming with. The first thing it does is load the kernel at 0x400000 instead of 0x100000 (this part was implemented by Peter Wemm who sent it to me a little over a year ago now). The next thing it does is write a page table for the kernel pages that would - given the right pde - map the

entire kernel in 4K pages. However, if PSE is enabled, the page table is not used[*] and instead a pde for a 4M page (or several) mapping the kernel in its entirety is[are] written before paging is ever turned on (that's it, in a nutshell). I don't want to go into much detail on the rationale of all this unless you are really interested, at even then only to a point (please Email privately).

[*] In some cases it's still used for a P==V mapping required to boot the APs.

Ok, so now that all that is out of the way, I'd like to request a massive movement to help test this change. :-)

What has been done:

Georg-W. Koltermann - who has experienced the above-mentionned data corruption problems on his P4, was able to reproduce them fairly reliably, and has been running with DISABLE_PSE and DISABLE_PG_G - has tested the patch and confirmed that it solves his data corruption problem without having to require the two DISABLE options.

I have tested this patch (and have been running with it for a week now) on my -current workstation at the office (although I never experienced the aformentionned data corruption problems).

Robert Watson has tested this patch on one of his SMP machines and it has now been confirmed to work there as well.

We have not yet tested this patch with PAE turned on.

What needs to be done:

If you've had random data corruption problems while running -current on Intel, please try this patch WITHOUT the DISABLE_PSE _nor_ the DISABLE_PG_G options in your kernel and let me know if the problem goes away. (If it does not go away, then suspect bad RAM...)

If you have -current running on Intel, PLEASE TEST THIS patch. This includes UP, SMP, PAE, and any combination of said features. With regards to PAE in particular, I'd like to know if you can boot this thing as I have not yet attempted it.

The information I'd like to see, if possible (private mail is OK):

1) Your hardware, UP or SMP.

2) Whether you have PAE turned on.

3) If you had the data corruption problem, does the patch solve it? Please make sure you do NOT include the DISABLE_PSE and DISABLE_PG_G options when you test for this, as they should no longer be needed.

If for some reason you continue to see data corruption problems with this patch, then make sure that they really do go away with DISABLE_PSE and DISABLE_PG_G before you contact me; it could just be bad RAM.

If I commit this, I want it to have the longest "Tested By" list ever written in a commit message to date. Please help. :-)

Regards,

--

Bosko Milekic * bmilekic@technokratis.com * bmilekic@FreeBSD.org

TECHNOkRATIS Consulting Services * http://www.technokratis.com/

[...]

Eredeti levél és patch itt.

Hosszú hallgatás után megjelent az MPlayer 0.91-es veriója. Ez egy bugfix kiadás, amely nem tartalmazza a 'main' ág újdonságait (pl. a Sorenson 3-at). Ez a kiadás a 0.90 ág utolsó kiadása. A másik MPlayer hír, hogy erősen valószínű, hogy pár napon belül megjelenik az MPlayer 1.0.

Letöltés:

HTTP:

[HUN1 | HUN2 | USA1 | USA2]

FTP:

[HUN1 | HUN2 | USA1 | USA2]

Változások:Dokumentáció:

* Francia, Magyar, Kínai fordítások frissítése

* a konzol üzenetek fordításának frissítése

* számos javítás a HTML dokumentációban

* javítások, tisztázások a kézikönyvben

* kívánságlista frissítés :)

* Lengyel dokumentációt eltávolítva (elavult)

* Norvég, Román és Török nyelvű segítség fájlok eltávolítva
(elavult)

Javítások:

Megjelent a Debian közösség szokásos heti hírlevelének, a DWN-nek az ez évi 32. száma.

A tartalomból:

Az Oktatási Minisztérium pályázatokat írt ki a műszaki kutatás-fejlesztés támogatására.

Ami titeket is érdekelhet ebből az az IKTA (Infokommunikációs technológiák és alkalmazások alprogram), amelynek keretein belül lehetőség van a technológia- és alkalmazásfejlesztés témakörön belül nyílt forráskódú és szabad szoftverek fejlesztésére pályázatot beadni.

Akinek tehát jó ötlete van, de nincs a megvalósításhoz pénze, egyéb erőforrása, gondolja végig a lehetőségét egy pályázat benyújtásának!


A szabad szoftvereket tartalmazó alprogram témakörei

Tájékoztató füzet

Műszaki kutatás-fejlesztési pályázatok a 2003-as évre

Megjelent a Local Area Security Linux 0.4a verziója. A kicsi, KNOPPIX alapú 'live CD' terjesztés méretre kevesebb, mint 185MB, így elfér egy MiniCD-n. Jelenleg 107MB, FluxBox-ot tartalmaz ablakkezelőként. A terjesztés kb. 100 biztonsággal kapcsolatos (behatolás jelző, tűzfal, hálózati szkenner, sniffer eszközök, stb.) csomagot tartalmaz. Haszna nem kérdéses, hiszen segítségével akár másodpercek alatt elő lehet állítani egy hálózati monitorozó eszközt.

A projekt weboldala itt.

Egy újabb érdekes dokumentummal bővült az oldal RTFM rovata. Holczer Szilárd szakdolgozata 90 oldalon keresztül taglalja azt, hogy hogyan is lehet felhasználóbarát csomagkezelő rendszert kialakítani Debian alapú Linuxokhoz.dpkg, apt, dselect - sajnos nem volt még időm elolvasni, de a tartalma alapján egy jól felépített, és gondosan összeállított dokumentációnak látszik.

A dokumentumot PDF formátumban letöltheted innen.

A Wall Street Journal egyik cikke szerint a SCO azért nem fedi fel az összes (állítólag a) Linux kernelbe másolt Unix forráskódot, mert akkor a Linux fejlesztők azokat könnyen kicserélhetnék. Vagy csak tudja a SCO azt, hogy ha lefedné a lapjait, akkor az emberek markukba nevetve felállnának az asztaltól ahelyett, hogy fizetnének?

A Wall Street Journal cikke itt.

A The Tribune cikke arra keresi a választ, hogy a SCO miért kezdte értékesíteni a részvényeit 4 nappal azután, miután 2003. március elején beperelte az IBM-et. Azért érdekes ez, mert a SCO belső emberei egyetlen részvényt sem adtak el a per megelőző egy évben.

A The Tribune cikke itt.A VNunet cikke szerint a SuSE az egyik legnagyobb riválisa - a Red Hat - mögé sorakozik fel a SCO elleni közdelemben. A SuSE egy hivatalos állásfpglalásban azt mondta, hogy megtapsolja a Red Hat azon erőfeszítéseit, amelyek arra irányulnak, hogy meggátolják a SCO FUD-ját.

A VNunet cikke itt.

A Weta Digital és a Massey Egyetem nemet mond a SCO-nak. A Weta Digital és a Massey Egyetem komoly számlát lenne kénytelen kifizetni, ha a SCO által kitalált licencelést követné. A Massey Egyetem Helix szuperszámítógépe egy 128 CPU-t tartalmazó Beowulf klaszter, amelyre a kedvezményes licenceléssel is 97.875 amerokai dollár lenne a jogdíj. Nagyobb bajban lenne a Weta Digital akinek több, mint 2000 CPU-ból álló linuxos render farmja van. Nem igazán akarják kifizetni a 1.149.000-1.500.000 USD-t a SCO-nak.

A ComputerWorld cikke itt.

Ahogy a FreeBSD.org-on olvashatjuk, online elérhető a FreeBSD Architecture Handbook névre hallgató dokumentum. A doksi elsősorban azoknak szól, akik többet akarnak tudni a FreeBSD kernel belső működéséről. Az információk nagy része a Developers' Handbook-ból származik, amely mostnatól kizárólag a userland programozásra fókuszál. Mindkét dokumentum fejlesztés alatt áll.

Csomag: perl

Sebezhetőség: oldalközi scriptelhetőség

Probléma típus: távoli

Debian-specifikus: nem

CVE Idk: CAN-2003-0615Egy oldalközi scriptelős sebezhetőség létezik a CGI.pm start_form() függvényében. Ez a függvény a kimenetre küldi a felhasználó által megadott adatot az űrlap action attribútumába, annélkül, hogy kitisztítaná, lehetővé téve evvel egy távoli felhasználónak, hogy tetszőleges web scriptet futtasson a generált weboldalon. Bármelyik program, amelyik ezt a függvényt használja érintett lehet.


Az aktuális stabil terjesztés (woody) ezt a problémát az 5.6.1-8.3 verzióban javítja.


Az aktuális instabil terjesztls (sid) ezt a problémát az 5.8.0-19 verzióban javítja.


Javasoljuk a perl csomagok frissítését.

Matt Zimmerman levele a debian-security-announce listán.

A frissítésről szóló FAQ-nk.

Az OpenBSD Journal szerint az OpenBSD ismét elérkezett egy fontos állomása előtti állapothoz. Ez azt jelenti, hogy az eddig OpenBSD 3.3-current néven futó stuff átneveződött OpenBSD 3.4-beta-ra. Legalábbis a cvs log szerint:

"CVSROOT: /cvs

Module name: src

Changes by: deraadtcvs.openbsd.org 2003/08/11 08:52:43

Modified files:

distrib/miniroot: install.sub

etc/root : root.mail

sys/conf : newvers.sh

sys/sys : param.h

share/mk : sys.mk

share/tmac/mdoc: doc-common doc-syms

sys/arch/macppc/stand/tbxidata: bsd.tbxi

Log message:

move to 3.4-beta

[...]"

Mintha felgyorsultak volna a fejlesztések az OpenBSD körül.

Az Opera Software ASA. kiadta az Opera első 7.x verzióját FreeBSD OS-re.Sokat nem beszéltek hozzá, mindössze egy rövid bejelentést mellékeltek:

"Elérhetőek az Opera 7.20 Beta 3 csomagok FreeBSD/i386-ra. Kérjük olvasd el az Opera 7.20 linuxos bejelentését a változások logjának megismeréséhez. A Beta verziót letöltheted innen."

Az Opera FreeBSD-s oldala itt.

Augusztus 16-án 10 éves a Debian projekt!

További részletek a weblapon.

A SCO Group eladta az első Linux licencét (Intellectual Property Compliance License for SCO UNIX Rights).A SCO ezt egy sajtóbejelentésben hozta nyilvánoosságra. A felhasználó - aki a licencet megvásárolta - egy Fortune 500 cég, akinek a nevét egyelőre nem hozták nyilvánosságra.

A sajtóbejelentés itt.

A GCC csapat bojkottálja a SCO-t?

A pár nappal ezelőtt megjelent a GCC 3.3.1-es kiadása, amely tartalmaz egy nem szokványos `README.SCO' filet. A fileban utalást találhatunk a SCO Linux elleni támadására. A filet Richard Stallman és Eben Moglen íta, amelyben az FSF álláspontját adják közre az SCO-val kapcsolatban.Felvetődött a lehetősége annak is, hogy a GCC-ből eltávolítják a SCO UNIX platform támogatást. Ezzel is jelezve nemtetszésüket az iránt, hogy a SCO fenyegeti a szabad szoftveres közösséget.

Bővebben Mark Mitchell levelében.

A kernelfejlesztők érdekes emberek. Néha aprólékos precizitással oldanak meg problémákat, néha pedig teljesen elvesznek a részletkérdésekben. Történt ez a minap is, amikor Jasper Spaans egy olyan kernel foltot küldött az LKML-re, amely a 2.6-os kernel teljes forrásában kicseréli a 'flavour' szót 'flavor'-ra (a flavour írásmódot az angolok és az ausztrálok használják, míg a flavor formát az amerikaiak).

Linus többször is kijelentette, hogy az egységesítés hasznos dolog, de őt kevésbé érdekli.

A dologból szokás szerint óriási flame lett.A csapat két táborra szakadt. Az egyik az amerikai helyesírás szerinti kódolás mellett tette le a voksát (flavor, color, neighbor, zeros), míg mások az angol helyesírás mellett kardoskodtak (flavour, colour, neighbour, zeroes). Volt aki statisztikát készített, amelyből kiderült, hogy az amerikai írásmód magasan vezet az angol felett. Sokak szerint ez nem véletlen, hiszen a számítógép történelem inkább amerikai, mintsem angol.

[2003. 08. 10.] FreeBSD-SA-03:10.ibcs2

[2003. 08. 10.] FreeBSD-SA-03:09.signal

A Linux egyre népszerűbb Németországban. Nemrég arról olvashattunk, hogy München városi tanácsa olyan döntést hozott, amelynek alapján Németország harmadik legnagyobb városában 14.000 számítógépet és notebookot fognak átállítani Linuxra. Most pedig az egyik legnagyobb légitársaságának - a Lufthansa-nak - rendszerintegrátora (Lufthansa Systems) választotta a Linuxot.A Lufthansa és a SuSE Linux AG közös sajtóbejelentéséből lehet bővebb információt kinyerni annak, aki tud németül. Aki nem tud, annak álljon itt a Babelfish által angolra fordított sajtóbejelentés:

Lufthansa's of system becomes new SuSE Business partner

Hi!

Újabb egy év telt el, és úgy tűnik, hogy még mindig itt az oldal. A site valamikor '99 őszén indult útjára. Akkoriban még nem volt ennyi hasonló témájú oldal a cybertérben, mint manapság. Azóta születtek, és szűntek meg hasonló oldalak, de a HUP stabilan tartja magát. Hogy hogyan?

A site az indulása óta külsőleg többször átalakult, a kezdeti statikus HOWTO oldalból dinamikus híroldallá vált. A korábbi alacsony látogatottság (ami sohasem volt baj, mert többször hangsúlyoztam, hogy ennek az oldalnak nem kell látogatottságot produkálnia a szponzorok felé) mára már jóval nagyobb, és néhányan már úgy emlegetik a HUP-ot, mint az ország legnagyobb szabad szoftveres oldalát.

Mi történt az elmúlt egy évben? Idén 33.979.348 találatot kaptunk (szemben a tavalyi 7.319.612-vel), a napi átlagos látogatások száma felemelkedett ~850-ről ~1950-re. Ez mintegy havi ~60.000 látogatót jelent (forrás). Mindezt, talán mondhatom, hogy ~100%-os rendelkezésreállással produkálta az oldal (forrás).

Külön örömmel tölt el, hogy ezt az évet is sikerült úgy végigcsinálni, hogy nem volt szükség állandó szponzor keresésre, fizetett hirdetések megjelentetésére. Emellett azonban köszönetet kell mondanom az oldal támogatóinak - kiemelve az Axelero-t aki a szervert hostolja - , akik nélkül a szolgáltatás nem létezhetne a jelenlegi színvonalon.

Mi történt az elmúlt egy évben?

Újra működőképes az ftp.fsn.hu. Kérek mindenkit, hogy ha az eddigiektől eltérő működést tapasztal, jelezze nekem!

A FreeBSD egyik nagyszerű része a ports gyűjtemény, amely már közel 10000 könnyen telepíthető programot tartalmaz. A FreeBSD felhasználók nagy része úgy használja a ports gyűjteményt, hogy megkeresi a megfelelő portot, belépve annak könyvtárába kiad egy make install clean parancsot. De ezen kívül a legtöbbjének foglama sincs, hogy ezen kívül számos más funkció is be van építve a port eszközökbe.Dru Lavigne azt meséli el ezen a héten, hogy hogyan teheted az életed sokkal könnyebbé a ports ezen funkcióinak felhasználásával.

Dru cikke itt.

Véget ért a "Ellátogatsz a V. GNU/Linux szakmai konferenciára?" című szavazás, az eredményeket meg lehet tekinteni itt.

A hét kérdése: Melyik a legjobb SMTP szerver? Szavazni lehet itt.

Ma megjelent a 2.6-os kernel harmadik teszt verziója. Úgy gondoltam itt az ideje, hogy összehasonlítsam a 2.4-es kernellel. Mivel a 2.6-os (teszt) kernelt lassan 2-3 hónapja folyamatosan használom (a 2.5.70-től) és nekem megfelelően működik, nem a stabilitiására voltam kíváncsi. Inkább arra, hogy mit nyújt az új kernel a tipikus otthoni desktop felhasználónak. Így a teszteket nem arra hegyeztem ki, hogy hány ezer levelet tud elküldeni egységnyi idő alatt, vagy hogy mennyi idő alatt dumpol ki egy 500Mb-os MySQL adatbázist.

Inkább azt néztem meg, hogy átlagos otthoni alkalmazások futtatása mellett X-en, milyen sebességgel lehet kernelt fordítani, mennyi idő alatt fordul le az MPlayer G2, mennyi idő alatt tudok egy kis (14MB-os) filet gzip -9-cel összenyomni, és ugyanezt mennyi idő alatt tudom elvégezni mondjuk egy 780MB-os file esetén.

Lássuk a tesztkörnyezetet:A hardver:

Intel G845PEBT2 alaplap (82845G/GL [Brookdale-G] Chipset)

Intel(R) Pentium(R) 4 CPU 3.06GHz processzor 512KB cache

512MB DDR266 RAM

nVidia Corporation NV11 [GeForce2 MX/MX 400]

Intel Corp. 82801DB AC'97 Audio

Creative Labs SB Live! EMU10k1

CMD Technology Inc Silicon Image SiI 3112 SATARaid Controller

Intel Corp. 82801BD PRO/100 VE (LOM) Ethernet Controller

Intel Corp. 82801DB ICH4 IDE

Intel Corp. 82557/8/9 [Ethernet Pro 100]

Rendszer busz sebesség: 533MHz

Rendszer memória sebesség: 266MHz

cat /proc/cpuinfo

dmesg

Szoftver környezet:

Debian GNU/Linux testing/unstable 'Sarge'

gcc 3.3

A teszt ideje alatt próbáltam egy átlagos napi használat közbeni mérést készíteni. Így azok a programok futottak, amelyeket naponta használok:

Linus kiadta a 2.6.0-test3 kernelt. SELinux beolvasztás, CPU frekvencia frissítések, hálózati eszközmeghajtó javítások, USB javítások. PCMCIA lock-up javítás, read-ahead bug javítás.

Letölthető patch-2.6.0-test3.bz2, FULL

Változások logja Linus levelében itt.

Soeren Schmidt elérhetővé tette az ATAng (új generációs ATA) eszközmeghajtóit FreeBSD-hez. Mielőtt az új driverekben levő radikális változásokat commitelné a forrásfába, lehetőséget biztosít a szélesebb körű tesztelére. A driverek keretmunkákat tartalmaznak, amelyek az új ATA kontrollerek támogatását célozzák meg (láncolásos parancsok, hardveres XOR, stb.). A driverekben összevonásra kerültek az ATA és az ATAPI kódok. Eltávolításra került a GIANT az ATA kódból.

Bővebben Soeren levelében:From: Soeren Schmidt

Date: Fri, 8 Aug 2003 21:55:11 +0200 (CEST)

Subject: TESTERS WANTED for ATAng preview 1

The first preview release of ATAng is now available on:

ftp://ftp.deepcore.dk/pub/ATAng

>From the README there:

ATAng preview 1 release

Before these rather radical changes to the ATA driver hits the

tree, here is the opportunity to test them out, give usefull

feedback and for the depending subsytems to adjust to the new ways of things (burncd & atapicam are good examples).

Now why all these changes suddenly ?

1. Get GIANT out of the ATA driver. This was pretty tedious in the old version (I tried that long ago and found it way too painfull). With this new structure it was a walk in the park since handling of ATA commands/requests are now split up in a "queue" part and a "lowlevel" part. This makes the places where locks are needed a lot more obvious to locate, making it easier to implement and maintain.

2. Provide the framework for supporting new ATA controllers that has facilities for chaining commands and HW XOR's etc. This called for some radical changes to the basic framework which fitted nicely with item 1 above. Most of the hooks needed for "exotic" HW are now present, and the next step will be for drivers to use this to get an edge over conventional ATA controllers. Promise Inc. has kindly provided HW and

documentation for their latests chips that has lots of interesting features that we can now start to use. Much more on this when these basic bits has settled..

3. Merge of ATA and ATAPI code. As an effect of the new framework there is now a single entrypoint for ATA/ATAPI commands. This will extend to userland where it will be possible to issue both ATA and ATAPI commands just as before with just ATAPI ones. This will add the ability to do all kinds of stuff from userland, like SMART etc, however it will also provide a nice way of trashing your system :)

The code for this is not included in this preview as I still need

to settle on the API for this.

4. During all this lots of bugs and problems in the old code has been found and fixed.

5. The way ATA RAID support works today need to change as well to make full use of fx Promise's new chips. This is NOT done yet, in fact the ata-raid.? driver is still the same, bugs and all.

To try this out you need to apply the "conf-patch" file to your sys tree then delete the contents of dev/ata and put the contents of the ATAng-.tgz in there instead. You might want to include "device ataraid" in your kernel config file if you use ATA RAID's. Config & make your kernel as usual.

Now, some things are not completly done yet, some things will not be done at all and there are bound to be bugs lurking, so use protective measures for safe engagement, you have been warned 8)

Constructive feedback as always very welcome!!

Enjoy!

-Søren

Mark Mitchell bejelentette a GCC 3.3.1-et. A kiadásban a készítők szerint "nagyon sok hibajavítás található a GCC 3.3-hoz képest". A hibajavítások teljes és hosszú listáját megtalálod itt. Mark Mitchell szerint a GCC következő kiadása a GCC 3.3.2 lesz, amely szintén bugfix kiadásként jelenik majd meg.

--------------------------------------------------------------------

From: Mark Mitchell

To: gcc-announce

Subject: GCC 3.3.1 Released

Date: Fri, 8 Aug 2003 11:00:12 -0700

The GCC 3.3.1 release is now available from the sites listed at:

http://www.gnu.org/order/ftp.html

This release contains a very large number of bug-fixes relative to GCC 3.3.

Scroll to the bottom of:

http://gcc.gnu.org/gcc-3.3/changes.html

for a complete list of bugs fixed.

The next release of GCC will be GCC 3.3.2, which will be a bug-fix release.

As always, there are far too many people involved in the development and testing of GCC to name them all, but I would like to recognize a few people whose efforts made it notably easier for me to manage this release:

In alphabetical order:

- Joe Buck, for producing our release notes.

- Wolfgang Bangerth and Andrew Pinski for classifying and triaging lots of bugs.

- Janis Johnson for tracking down the causes of numerous regressions.

I've also been asked to mention Paolo Carlini's

--

Mark Mitchell

CodeSourcery, LLC