Sun V20z Linux 2.6.11.4 dmesg

Alaplapok

Sun V20z Linux 2.6.11.4 dmesg

  • 1135 megtekintés

( dozen | 2005. 03. 18., p – 19:12 )

hi!

Nem lesz az tul unstable egy serverre? debian 4.0-pre7 ?

Miert nem raksz ra inkabb fbsdt? grsec-es kernelt nem akarsz?

byez dozen

( andrej_ v | 2005. 03. 18., p – 19:20 )

[quote:14930a69e4="dozen"]hi!

Nem lesz az tul unstable egy serverre? debian 4.0-pre7 ?

Miert nem raksz ra inkabb fbsdt? grsec-es kernelt nem akarsz?

byez dozen

Azt kerte valaki bratol, hogy mutasson egy ilyen dmesget. Ez nem jelenti azt, hogy rogton ezt is fogja hasznalni. Gondolom bootolt egy ilyen kernelt egy olyan gepen, amin lehet jaccani.

( bra | 2005. 03. 18., p – 20:17 )

[quote:54769391cd="dozen"]hi!

Nem lesz az tul unstable egy serverre? debian 4.0-pre7 ?

Miert nem raksz ra inkabb fbsdt? grsec-es kernelt nem akarsz?

byez dozen

Nem őrültem meg. Debiant szerverre?!?! :twisted:

A viccet félretéve: AMD64-re nincs kiadott Debian, így legfeljebb sarge-zsal lehet próbálkozni. Abban viszont alapból gcc 3.3 van (és talán 32 bites userland is? nem is néztem).

Kíváncsiságból frissítettem, hogy nagyobb gcc legyen benne, ez pedig így a 4-es lett. Bár ez még nem hivatalosan kiadott szoftver, meg nyilván vannak hibái, a gép egész jól megy vele.

Éles szolgáltatás van rajta, de tartalékolt, load balanceres környezetben, tehát ha elhasal, nincs semmi gond, nem kap forgalmat, kiszolgálja a kéréseket a többi. Amit meg szeretnék tudni, hogy ezen a gépen a Linux hogy teljesít a FreeBSD-hez képest.

Egyelőre azt látom, amit vártam is. Ha az alkalmazás threadesen fut, a FreeBSD-n lassabb, Linuxon sokkal gyorsabb. Ez ismert hiba a BSD-ben, elméletileg dolgoznak rajta (5.5-ben biztosan jobb lesz :).
Threadek nélkül még nem próbáltam, az lesz a következő.

( bra | 2005. 03. 18., p – 20:19 )

[quote:da4fd37dba="andrej_"][quote:da4fd37dba="dozen"]hi!

Nem lesz az tul unstable egy serverre? debian 4.0-pre7 ?

Miert nem raksz ra inkabb fbsdt? grsec-es kernelt nem akarsz?

byez dozen

Azt kerte valaki bratol, hogy mutasson egy ilyen dmesget. Ez nem jelenti azt, hogy rogton ezt is fogja hasznalni. Gondolom bootolt egy ilyen kernelt egy olyan gepen, amin lehet jaccani.

Majdnem :)
Kérték a dmesget, meg engem is érdekelt, hogy megy a gép Linuxszal.

Egyelőre nagyon szépen, bár a 2.6.8-as alap Debian kernellel, reiserfs-sel kaptam érdekes bejegyzéseket :)
2.6.11-esre frissítve ezek megszűntek.

( andrej_ v | 2005. 03. 18., p – 20:24 )

[quote:04b5fa829f="bra"][quote:04b5fa829f="dozen"]hi!

Nem lesz az tul unstable egy serverre? debian 4.0-pre7 ?

Miert nem raksz ra inkabb fbsdt? grsec-es kernelt nem akarsz?

byez dozen

Nem őrültem meg. Debiant szerverre?!?! :twisted:

A viccet félretéve: AMD64-re nincs kiadott Debian, így legfeljebb sarge-zsal lehet próbálkozni. Abban viszont alapból gcc 3.3 van (és talán 32 bites userland is? nem is néztem).

Kíváncsiságból frissítettem, hogy nagyobb gcc legyen benne, ez pedig így a 4-es lett. Bár ez még nem hivatalosan kiadott szoftver, meg nyilván vannak hibái, a gép egész jól megy vele.

Éles szolgáltatás van rajta, de tartalékolt, load balanceres környezetben, tehát ha elhasal, nincs semmi gond, nem kap forgalmat, kiszolgálja a kéréseket a többi. Amit meg szeretnék tudni, hogy ezen a gépen a Linux hogy teljesít a FreeBSD-hez képest.

Egyelőre azt látom, amit vártam is. Ha az alkalmazás threadesen fut, a FreeBSD-n lassabb, Linuxon sokkal gyorsabb. Ez ismert hiba a BSD-ben, elméletileg dolgoznak rajta (5.5-ben biztosan jobb lesz :).
Threadek nélkül még nem próbáltam, az lesz a következő.

ULE schedullerrel teccik probalkozni? Tudom ez a maniam, de itthon eleg jo eredmenyek szulettek 4BSD-hez kepest a dual PII-esemen.

( bra | 2005. 03. 18., p – 21:29 )

[quote:eb3a66041d="andrej_"][quote:eb3a66041d="bra"][quote:eb3a66041d="dozen"]hi!

Nem lesz az tul unstable egy serverre? debian 4.0-pre7 ?

Miert nem raksz ra inkabb fbsdt? grsec-es kernelt nem akarsz?

byez dozen

Nem őrültem meg. Debiant szerverre?!?! :twisted:

A viccet félretéve: AMD64-re nincs kiadott Debian, így legfeljebb sarge-zsal lehet próbálkozni. Abban viszont alapból gcc 3.3 van (és talán 32 bites userland is? nem is néztem).

Kíváncsiságból frissítettem, hogy nagyobb gcc legyen benne, ez pedig így a 4-es lett. Bár ez még nem hivatalosan kiadott szoftver, meg nyilván vannak hibái, a gép egész jól megy vele.

Éles szolgáltatás van rajta, de tartalékolt, load balanceres környezetben, tehát ha elhasal, nincs semmi gond, nem kap forgalmat, kiszolgálja a kéréseket a többi. Amit meg szeretnék tudni, hogy ezen a gépen a Linux hogy teljesít a FreeBSD-hez képest.

Egyelőre azt látom, amit vártam is. Ha az alkalmazás threadesen fut, a FreeBSD-n lassabb, Linuxon sokkal gyorsabb. Ez ismert hiba a BSD-ben, elméletileg dolgoznak rajta (5.5-ben biztosan jobb lesz :).
Threadek nélkül még nem próbáltam, az lesz a következő.

ULE schedullerrel teccik probalkozni? Tudom ez a maniam, de itthon eleg jo eredmenyek szulettek 4BSD-hez kepest a dual PII-esemen.

Nem, 4BSD-vel, de mint mondtam ismert, hogy a threades programok az új rendszerben eléggé, khm, szuboptimálisan működnek.

Az ULE broken. Az asztali gépemen és ezen is többször lefagyott a vele fordított kernel. Szerintem soha nem is lesz belőle semmi. Nincs aki foglalkozzon vele.

( andrej_ v | 2005. 03. 18., p – 22:04 )

[quote:0436e4ce1c="bra"][quote:0436e4ce1c="andrej_"][quote:0436e4ce1c="bra"][quote:0436e4ce1c="dozen"]hi!

Nem lesz az tul unstable egy serverre? debian 4.0-pre7 ?

Miert nem raksz ra inkabb fbsdt? grsec-es kernelt nem akarsz?

byez dozen

Nem őrültem meg. Debiant szerverre?!?! :twisted:

A viccet félretéve: AMD64-re nincs kiadott Debian, így legfeljebb sarge-zsal lehet próbálkozni. Abban viszont alapból gcc 3.3 van (és talán 32 bites userland is? nem is néztem).

Kíváncsiságból frissítettem, hogy nagyobb gcc legyen benne, ez pedig így a 4-es lett. Bár ez még nem hivatalosan kiadott szoftver, meg nyilván vannak hibái, a gép egész jól megy vele.

Éles szolgáltatás van rajta, de tartalékolt, load balanceres környezetben, tehát ha elhasal, nincs semmi gond, nem kap forgalmat, kiszolgálja a kéréseket a többi. Amit meg szeretnék tudni, hogy ezen a gépen a Linux hogy teljesít a FreeBSD-hez képest.

Egyelőre azt látom, amit vártam is. Ha az alkalmazás threadesen fut, a FreeBSD-n lassabb, Linuxon sokkal gyorsabb. Ez ismert hiba a BSD-ben, elméletileg dolgoznak rajta (5.5-ben biztosan jobb lesz :).
Threadek nélkül még nem próbáltam, az lesz a következő.

ULE schedullerrel teccik probalkozni? Tudom ez a maniam, de itthon eleg jo eredmenyek szulettek 4BSD-hez kepest a dual PII-esemen.

Nem, 4BSD-vel, de mint mondtam ismert, hogy a threades programok az új rendszerben eléggé, khm, szuboptimálisan működnek.

Az ULE broken. Az asztali gépemen és ezen is többször lefagyott a vele fordított kernel. Szerintem soha nem is lesz belőle semmi. Nincs aki foglalkozzon vele.

Hát itt eléggé nem broken és csinálják is, legalábbis ahogy olvasgattam a FreeBSD-t erinto iromanyokat. Az elofordulhat, hogy adott driver agyonvagja, ami GIANT fuggo (ahogy kovetkeztettem az irasokbol es a tapasztalatokbul). Én nagyon remélem, hogy lesz belőle valami.

Kukkenbite: http://www.freebsd.org/releases/5.4R/todo.html

Az utolso elotti pontban nekem ugy fest hogy foglalkoznak vele, legalabbis akarnak.

( bra | 2005. 03. 18., p – 22:44 )

[quote:37d2485397="andrej_"][quote:37d2485397="bra"][quote:37d2485397="andrej_"][quote:37d2485397="bra"][quote:37d2485397="dozen"]hi!

Nem lesz az tul unstable egy serverre? debian 4.0-pre7 ?

Miert nem raksz ra inkabb fbsdt? grsec-es kernelt nem akarsz?

byez dozen

Nem őrültem meg. Debiant szerverre?!?! :twisted:

A viccet félretéve: AMD64-re nincs kiadott Debian, így legfeljebb sarge-zsal lehet próbálkozni. Abban viszont alapból gcc 3.3 van (és talán 32 bites userland is? nem is néztem).

Kíváncsiságból frissítettem, hogy nagyobb gcc legyen benne, ez pedig így a 4-es lett. Bár ez még nem hivatalosan kiadott szoftver, meg nyilván vannak hibái, a gép egész jól megy vele.

Éles szolgáltatás van rajta, de tartalékolt, load balanceres környezetben, tehát ha elhasal, nincs semmi gond, nem kap forgalmat, kiszolgálja a kéréseket a többi. Amit meg szeretnék tudni, hogy ezen a gépen a Linux hogy teljesít a FreeBSD-hez képest.

Egyelőre azt látom, amit vártam is. Ha az alkalmazás threadesen fut, a FreeBSD-n lassabb, Linuxon sokkal gyorsabb. Ez ismert hiba a BSD-ben, elméletileg dolgoznak rajta (5.5-ben biztosan jobb lesz :).
Threadek nélkül még nem próbáltam, az lesz a következő.

ULE schedullerrel teccik probalkozni? Tudom ez a maniam, de itthon eleg jo eredmenyek szulettek 4BSD-hez kepest a dual PII-esemen.

Nem, 4BSD-vel, de mint mondtam ismert, hogy a threades programok az új rendszerben eléggé, khm, szuboptimálisan működnek.

Az ULE broken. Az asztali gépemen és ezen is többször lefagyott a vele fordított kernel. Szerintem soha nem is lesz belőle semmi. Nincs aki foglalkozzon vele.

Hát itt eléggé nem broken és csinálják is, legalábbis ahogy olvasgattam a FreeBSD-t erinto iromanyokat. Az elofordulhat, hogy adott driver agyonvagja, ami GIANT fuggo (ahogy kovetkeztettem az irasokbol es a tapasztalatokbul). Én nagyon remélem, hogy lesz belőle valami.

Kukkenbite: http://www.freebsd.org/releases/5.4R/todo.html

Az utolso elotti pontban nekem ugy fest hogy foglalkoznak vele, legalabbis akarnak.

Hát én nem sok commitot láttam hozzá...

( thuglife | 2005. 03. 18., p – 22:46 )

bra nem a mennyiseg hanem a minoseg szamit :) bar pl egyik dragonfly commiter napi legalabb 30x commitol usr.bin/make be mert hogy neki igy esik jol :)

( Mico v | 2005. 03. 19., szo – 05:37 )

[quote:8e09c188d6="bra"]
Éles szolgáltatás van rajta, de tartalékolt, load balanceres környezetben, tehát ha elhasal, nincs semmi gond, nem kap forgalmat, kiszolgálja a kéréseket a többi. Amit meg szeretnék tudni, hogy ezen a gépen a Linux hogy teljesít a FreeBSD-hez képest.

Egyelőre azt látom, amit vártam is. Ha az alkalmazás threadesen fut, a FreeBSD-n lassabb, Linuxon sokkal gyorsabb. Ez ismert hiba a BSD-ben, elméletileg dolgoznak rajta (5.5-ben biztosan jobb lesz :).
Threadek nélkül még nem próbáltam, az lesz a következő.

Lesznek olyan alkalmazások, ahol jelentősen jobb lesz a Linux - nekem ugyan nincs Linux, de már sokan reportolták. Amire kíváncsi lennék, és egyelőre lusta vagyok kipróbálni: hogy áll a Linux a V20z alaplapi 'hardver' RAID-jével? FreeBSD (és még jó néhány OS) alatt borzalmas a teljesítmény, bár hamarosan várható a javítás (a félhardver RAID egy hagyományos diszket mutat, tehát nem kell szoftveresen duplikálni az írást, viszont pl a diszkeket a drivernek kell beállítani sebességileg, stb, ami szerintem elég gáz). Ami érdekelne még - tippek és trükkök FreeBSD vs. console redirection a management processzoron át kategóriában, különös tekintettel a terminálinkompatibilitási kérdésekben, a freebsd felbootolása után. Másfél órát rászántam, meguntam - igaz, még nem sikerült puttyból kipróbálnom, csak puttó linux alól.

( Mico v | 2005. 03. 19., szo – 05:45 )

Bocsánat. Csak a linuxos terminálomról nem jó.

( bra | 2005. 03. 19., szo – 10:08 )

[quote:974578564b="thuglife"]bra nem a mennyiseg hanem a minoseg szamit :) bar pl egyik dragonfly commiter napi legalabb 30x commitol usr.bin/make be mert hogy neki igy esik jol :)

Tudom én azt jól, de mostanában nem sok aktivitásra emlékszem. Jeff Robertson inkább a VFS témával volt/van elfoglalva.

Én is remélem, hogy lesz valami az ULE-vel, a buildworld tesztben sokkal jobb volt :)

( bra | 2005. 03. 19., szo – 10:13 )

[quote:5a53b33a5c="Mico"]
Lesznek olyan alkalmazások, ahol jelentősen jobb lesz a Linux - nekem ugyan nincs Linux, de már sokan reportolták. Amire kíváncsi lennék, és egyelőre lusta vagyok kipróbálni: hogy áll a Linux a V20z alaplapi 'hardver' RAID-jével? FreeBSD (és még jó néhány OS) alatt borzalmas a teljesítmény, bár hamarosan várható a javítás (a félhardver RAID egy hagyományos diszket mutat, tehát nem kell szoftveresen duplikálni az írást, viszont pl a diszkeket a drivernek kell beállítani sebességileg, stb, ami szerintem elég gáz). Ami érdekelne még - tippek és trükkök FreeBSD vs. console redirection a management processzoron át kategóriában, különös tekintettel a terminálinkompatibilitási kérdésekben, a freebsd felbootolása után. Másfél órát rászántam, meguntam - igaz, még nem sikerült puttyból kipróbálnom, csak puttó linux alól.

Megleptél. Ebben a V20z-ben nincs RAID.

Ezek vannak:
[code:1:5a53b33a5c]
lspci
0000:00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07)
0000:00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05)
0000:00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03)
0000:00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05)
0000:00:0a.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
0000:00:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01)
0000:00:0b.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
0000:00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01)
0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:01:05.0 VGA compatible controller: Trident Microsystems Blade 3D PCI/AGP (rev 3a)
0000:02:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02)
0000:02:03.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02)
0000:02:04.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 08)
[/code:1:5a53b33a5c]
Nekem FreeBSD alatt nem volt terminálkezelési problémám, igaz nem is használok olyan dolgokat, amelyeknél ez jelentősen számítana (mc pld.). Az egyedüli, amit soros terminálból futtattam a vi volt, de rendesen működött minden.
ssh FreeBSD-ről V20z SP-re, majd soros konzol a rajta futó FreeBSD-re.
De a linuxos notebookomról is ment ugyanez, mindenféle extra beállítás nélkül.

( Mico v | 2005. 03. 19., szo – 10:17 )

[quote:6157899146="bra"]
Megleptél. Ebben a V20z-ben nincs RAID.

Az LSI 1030 -ra gondoltam.

[quote:6157899146="bra"]
Nekem FreeBSD alatt nem volt terminálkezelési problémám, igaz nem is használok olyan dolgokat, amelyeknél ez jelentősen számítana (mc pld.). Az egyedüli, amit soros terminálból futtattam a vi volt, de rendesen működött minden.
ssh FreeBSD-ről V20z SP-re, majd soros konzol a rajta futó FreeBSD-re.
De a linuxos notebookomról is ment ugyanez, mindenféle extra beállítás nélkül.

Eddig nekem se, most viszont igen, de azóta megint jó, szóval nem tudom. Kezdek arra gyanakodni hogy kellett neki egy tápfesz ki-be.

üdv,