Sun V20z Linux 2.6.11.4 dmesg

[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 :)

[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.

Kérték tőlem, hátha mást is érdekel:
Bootdata ok (command line is root=/dev/sda1 ro )
Linux version 2.6.11.4 (root@debian) (gcc version 4.0.0 20050304 (prerelease) (Debian 4.0-0pre7)) #2 SMP Fri Mar 18 16:26:24 EST 2005
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009a000 (usable)
BIOS-e820: 000000000009a000 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000cc000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000fbf70000 (usable)
BIOS-e820: 00000000fbf70000 - 00000000fbf77000 (ACPI data)
BIOS-e820: 00000000fbf77000 - 00000000fbf80000 (ACPI NVS)
BIOS-e820: 00000000fbf80000 - 00000000fc000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec00400 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
ACPI: RSDP (v002 PTLTD ) @ 0x00000000000f7cc0
ACPI: XSDT (v001 PTLTD XSDT 0x06040000 LTP 0x00000000) @ 0x00000000fbf74c69
ACPI: FADT (v003 SUN V20z 0x06040000 PTEC 0x000f4240) @ 0x00000000fbf76c44
ACPI: MADT (v001 PTLTD APIC 0x06040000 LTP 0x00000000) @ 0x00000000fbf76d38
ACPI: SPCR (v001 PTLTD $UCRTBL$ 0x06040000 PTL 0x00000001) @ 0x00000000fbf76dae
ACPI: SRAT (v001 SUN V20z 0x06040000 SUN 0x00000001) @ 0x00000000fbf76dfe
ACPI: SSDT (v001 SUN V20z 0x06040000 LTP 0x00000001) @ 0x00000000fbf76ec6
ACPI: SSDT (v001 SUN V20z 0x06040000 LTP 0x00000001) @ 0x00000000fbf76f63
ACPI: DSDT (v001 SUN V20z 0x06040000 MSFT 0x0100000e) @ 0x0000000000000000
Scanning NUMA topology in Northbridge 24
Number of nodes 2
Node 0 MemBase 0000000000000000 Limit 000000007fffffff
Node 1 MemBase 0000000080000000 Limit 00000000fbf70000
Using node hash shift of 24
Bootmem setup node 0 0000000000000000-000000007fffffff
Bootmem setup node 1 0000000080000000-00000000fbf70000
On node 0 totalpages: 524287
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 520191 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
On node 1 totalpages: 507760
DMA zone: 0 pages, LIFO batch:1
Normal zone: 507760 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:5 APIC version 16
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 15:5 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x03] address[0xfd000000] gsi_base[24])
IOAPIC[1]: apic_id 3, version 17, address 0xfd000000, GSI 24-27
ACPI: IOAPIC (id[0x04] address[0xfd001000] gsi_base[28])
IOAPIC[2]: apic_id 4, version 17, address 0xfd001000, GSI 28-31
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Checking aperture...
CPU 0: aperture @ 0 size 32 MB
No AGP bridge found
Built 2 zonelists
Kernel command line: root=/dev/sda1 ro console=tty0
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 2390.334 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Memory: 4060840k/4128192k available (1877k kernel code, 0k reserved, 901k data, 164k init)
Calibrating delay loop... 4702.20 BogoMIPS (lpj=2351104)
Mount-cache hash table entries: 256 (order: 0, 4096 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 0(1) -> Node 0
Using local APIC NMI watchdog using perfctr0
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 0(1) -> Node 0
CPU0: AMD Opteron(tm) Processor 250 stepping 0a
per-CPU timeslice cutoff: 1024.00 usecs.
task migration cache decay timeout: 2 msecs.
Booting processor 1/1 rip 6000 rsp ffff8100fbf05f58
Initializing CPU#1
Calibrating delay loop... 4767.74 BogoMIPS (lpj=2383872)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 1(1) -> Node 1
AMD Opteron(tm) Processor 250 stepping 0a
Total of 2 processors activated (9469.95 BogoMIPS).
Using local APIC timer interrupts.
Detected 12.449 MHz APIC timer.
checking TSC synchronization across 2 CPUs: passed.
time.c: Using PIT/TSC based timekeeping.
Brought up 2 CPUs
CPU0 attaching sched-domain:
domain 0: span 01
groups: 01
domain 1: span 03
groups: 01 02
CPU1 attaching sched-domain:
domain 0: span 02
groups: 02
domain 1: span 03
groups: 02 01
NET: Registered protocol family 16
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050211
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 5 *10 11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 *5 10 11)
ACPI: PCI Interrupt Link [LNKC] (IRQs *3 5 10 11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 5 10 *11)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.THOR._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.Z000._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.Z002._PRT]
SCSI subsystem initialized
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically. If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device(). As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior. If this argument makes the device work again,
** please email the output of "lspci" to bjorn.helgaas@hp.com
** so I can fix the driver.
PCI-DMA: Disabling IOMMU.
devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
Initializing Cryptographic API
Linux agpgart interface v0.100 (c) Dave Jones
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
loop: loaded (max 8 devices)
tg3.c:v3.23 (February 15, 2005)
ACPI: PCI interrupt 0000:02:02.0[A] -> GSI 25 (level, low) -> IRQ 25
eth0: Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:09:3d:10:a6:18
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
ACPI: PCI interrupt 0000:02:03.0[A] -> GSI 26 (level, low) -> IRQ 26
eth1: Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:09:3d:10:a6:19
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
Fusion MPT base driver 3.01.18
Copyright (c) 1999-2004 LSI Logic Corporation
ACPI: PCI interrupt 0000:02:04.0[A] -> GSI 27 (level, low) -> IRQ 27
mptbase: Initiating ioc0 bringup
ioc0: 53C1030: Capabilities={Initiator}
Fusion MPT SCSI Host driver 3.01.18
scsi0 : ioc0: LSI53C1030, FwRev=01032300h, Ports=1, MaxQ=222, IRQ=27
Vendor: MAXTOR Model: ATLAS10K4_73SCA Rev: DFV0
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sda: 143666192 512-byte hdwr sectors (73557 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 143666192 512-byte hdwr sectors (73557 MB)
SCSI device sda: drive cache: write back
/dev/scsi/host0/bus0/target0/lun0: p1 p2
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
Vendor: FUJITSU Model: MAP3735NC Rev: 0108
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sdb: 143571316 512-byte hdwr sectors (73509 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 143571316 512-byte hdwr sectors (73509 MB)
SCSI device sdb: drive cache: write back
/dev/scsi/host0/bus0/target1/lun0: unknown partition table
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
Attached scsi generic sg1 at scsi0, channel 0, id 1, lun 0, type 0
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
NET: Registered protocol family 2
IP: routing cache hash table of 16384 buckets, 256Kbytes
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
NET: Registered protocol family 8
NET: Registered protocol family 20
ReiserFS: sda1: found reiserfs format "3.6" with standard journal
ReiserFS: sda1: using ordered data mode
ReiserFS: sda1: journal params: device sda1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda1: checking transaction log (sda1)
ReiserFS: sda1: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 164k freed
NET: Registered protocol family 1
Adding 3470032k swap on /dev/sda2. Priority:-1 extents:1
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is off for TX and off for RX.

[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ő.

[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.

[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.

[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á...