Ubuntu 8.04 OpenVZ 2.6.24 su HP ML370: SKIANTOS
twistedbrain
console:
NMI received for unknown reason a1 on CPU0
You have some hardware problem likely on the PCI bus.
Dazed and confused, but trying to continue
Dopodik reagisce solo al ping, ma a null'altro e bisogna togliergli e
ridargli l'alimetazione elettrica perche' riparta.
A questo punto ho attaccato alla piastra madre solo piu` la scheda del
controller RAID, che ho gia` sfilato e riinfilato e quindi se ha
ragione che il BUS PCI da` i numeri, le uniche due cause possono
essere la MB e quella scheda.
Googleando ho visto errori simili, ma con versioni di kernel
precedente e su portatili e di cui non ho capito bene le ragioni. Sono
quindi molto graditi suggerimenti diagnostici e prognostici.
Ho ricompilato OpenVZ all'ultima versione disponibile 2.6.27.21, fatto
ripartire e aspetto che si ripianti, nel frattempo pero` ho visto che
mentre i due kernel openvz hanno dimensioni congrue:
-rw-r--r-- 1 root root 1967480 2009-09-18 22:37 vmlinuz-2.6.24-24-
openvz
-rw-r--r-- 1 root root 2101840 2009-10-12 14:48 vmlinuz-2.6.27.21
i due initrd non le hanno e mi sto chiedendo quello da me auocompilato
quanta memoria a ufo mi sta mangiando:
-rw-r--r-- 1 root root 7950082 2009-10-06 08:24 initrd.img-2.6.24-24-
openvz
-rw-r--r-- 1 root root 57375749 2009-10-12 14:50 initrd.img-2.6.27.21
C'e` modo di ridurlo a dimensioni ragionevoli o comunque occupa RAM
solo per quanto usa di quei 60 MB?
Come al solito saluti a tutti e ringraziamenti ai rispondenti,
Andrea
twistedbrain
Col nuovo kernel non s'e` ancora piantato, ma non vuol dire perche'
l'ultima volta sono passati quasi 20 gg prima che lo facesse.
Ho letto che potrebbe essere un problema legato al tentativo di
attivare il risparmio energetico con delle componenti hw che non
lo supportano.
Andrea
twistedbrain
> 08:34:07 up 17:28, 1 user, load average: 0.00, 0.00, 0.00
09:00:33 up 1 day, 17:55, 1 user, load average: 0.01, 0.00, 0.00
Resiste.Vedremo fra sette giorni.
twistedbrain
> On 13 Ott, 08:39,twistedbrain<andrea.ferra...@gmail.com> wrote:
>
> > 08:34:07 up 17:28, 1 user, load average: 0.00, 0.00, 0.00
>
> 09:00:33 up 1 day, 17:55, 1 user, load average: 0.01, 0.00, 0.00
>
> Resiste.Vedremo fra sette giorni.
Ne ha resistiti alcuni in piu`. Il 24/10 ha generato in console un bel
BUG: unable to handle kernel paging request at ffffff84
e sull' host non ci si riusciva piu` a collegare, ne' da remoto, ne'
da console,
nonostante fornisse un prompt per farlo e recepisse il nome utente
chiedendo
poi la password. Inoltre le macchine virtuali continuavano a
funzionare
senza apparenti problemi e sono riuscito a chiuderlo in modo
relativamente pulito con magic sysreq.
Andrea
twistedbrain
Eccolo qua, nella sua magnificenza (nonostante questo la macchina sta
continuando a funzionare, tanto che lo posso riportare senza dover
fotografare la console):
[84634.211774] BUG: unable to handle kernel paging request at ffffff84
[84634.211840] IP: [<c021a955>] cfq_set_request+0x175/0x400
[84634.211884] *pdpt = 00000000004d1001 *pde = 0000000000008067 *pte =
0000000000000000
[84634.211895] Oops: 0002 [#1] SMP
[84634.211926] Modules linked in: vzethdev vznetdev simfs vzrst vzcpt
tun vzdquota vzmon vzdev af_packet xt_tcpudp xt_length ipt_ttl
xt_tcpmss xt_TCPMSS iptable_mangle xt_multiport xt_limit xt_dscp
ipt_REJECT iptable_filter ip_tables x_tables lp loop serio_raw psmouse
pcspkr i2c_piix4 i2c_core cfi_probe gen_probe parport_pc parport
scb2_flash mtd chipreg map_funcs sworks_agp agpgart container button
ipv6 evdev ext3 jbd mbcache sg sr_mod cdrom pata_serverworks pata_acpi
floppy ata_generic cciss aic7xxx scsi_transport_spi tg3 libata libphy
scsi_mod ohci_hcd dock usbcore ssb dm_mirror dm_log dm_snapshot dm_mod
thermal processor fan thermal_sys fuse
[84634.212414]
[84634.212444] Pid: 189, comm: pdflush Not tainted (2.6.27.21 #1
briullov)
[84634.212486] EIP: 0060:[<c021a955>] EFLAGS: 00010282 CPU: 0
[84634.212529] EIP is at cfq_set_request+0x175/0x400
[84634.212566] EAX: f6c56600 EBX: f3d79cc0 ECX: ffffff80 EDX: 00000000
[84634.212608] ESI: f7307300 EDI: 00000001 EBP: 00000000 ESP: f3c1bb7c
[84634.212650] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[84634.212691] Process pdflush (pid: 189, veid: 0, ti=f3c1a000
task=f448d580 task.ti=f3c1a000)
[84634.212737] Stack: 00000282 00000010 00000010 c23d5c80 f396cfb0
00000001 f7989720 00000001
[84634.212827] 00000282 00000000 c017e795 00008001 c021a7e0
f396cfb0 c23d5c80 f396cfc0
[84634.212916] c020bc2c f396cfb0 00000001 c020ec9e 00000001
c01d1891 f78af720 00000010
[84634.213008] Call Trace:
[84634.213059] [<c017e795>] mempool_alloc+0x35/0xf0
[84634.213104] [<c021a7e0>] cfq_set_request+0x0/0x400
[84634.213147] [<c020bc2c>] elv_set_request+0x1c/0x40
[84634.213191] [<c020ec9e>] get_request+0x26e/0x380
[84634.213234] [<c01d1891>] bio_alloc_bioset+0x61/0x90
[84634.213284] [<c020f259>] get_request_wait+0x19/0x180
[84634.213327] [<c0219cfc>] cfq_merge+0x5c/0xa0
[84634.213365] [<c0219ca0>] cfq_merge+0x0/0xa0
[84634.213403] [<c020bf9d>] elv_merge+0x16d/0x1b0
[84634.213442] [<c020f914>] __make_request+0x64/0x3c0
[84634.213485] [<f887cc34>] dm_request+0xd4/0x120 [dm_mod]
[84634.213554] [<c020e05f>] generic_make_request+0x1bf/0x4b0
[84634.213597] [<c0108c55>] __switch_to+0xa5/0x160
[84634.213645] [<c017e795>] mempool_alloc+0x35/0xf0
[84634.213685] [<c020f7c6>] submit_bio+0x56/0x140
[84634.213725] [<c01d1535>] bvec_alloc_bs+0x65/0x110
[84634.213768] [<c01d1891>] bio_alloc_bioset+0x61/0x90
[84634.213809] [<c01cd711>] submit_bh+0xd1/0x110
[84634.213850] [<c01d115c>] sync_dirty_buffer+0x3c/0xb0
[84634.213893] [<f898d6e0>] journal_dirty_data+0xd0/0x1e0 [jbd]
[84634.213954] [<f89e9738>] ext3_journal_dirty_data+0x18/0x50 [ext3]
[84634.214028] [<f89e89a2>] walk_page_buffers+0x32/0x70 [ext3]
[84634.214078] [<f89ebc7d>] ext3_ordered_writepage+0xcd/0x170 [ext3]
[84634.214130] [<f89e9770>] journal_dirty_data_fn+0x0/0x10 [ext3]
[84634.214179] [<c0182498>] __writepage+0x8/0x30
[84634.214222] [<c0182af9>] write_cache_pages+0x259/0x3b0
[84634.214264] [<c0182490>] __writepage+0x0/0x30
[84634.214305] [<c0182c70>] generic_writepages+0x20/0x30
[84634.214346] [<c0182cc9>] do_writepages+0x49/0x50
[84634.214386] [<c01c9588>] __writeback_single_inode+0x98/0x340
[84634.214430] [<f887e35b>] dm_table_any_congested+0xb/0x60 [dm_mod]
[84634.214482] [<c01c9c8b>] generic_sync_sb_inodes+0x25b/0x330
[84634.214527] [<c01ca0db>] writeback_inodes+0x8b/0xb0
[84634.214568] [<c01835e8>] background_writeout+0x98/0xc0
[84634.214612] [<c0183b30>] pdflush+0x0/0x200
[84634.214650] [<c0183c56>] pdflush+0x126/0x200
[84634.214689] [<c0183550>] background_writeout+0x0/0xc0
[84634.214731] [<c0148ba8>] kthread+0x58/0xa0
[84634.214774] [<c0148b50>] kthread+0x0/0xa0
[84634.214813] [<c010aad3>] kernel_thread_helper+0x7/0x10
[84634.214857] =======================
[84634.214891] Code: 10 8b 82 54 01 00 00 8b 54 24 20 e8 66 00 12 00
31 d2 8b 44 24 18 8b 4c 24 0c 89 41 58 89 59 5c 8b 43 58 8b 48 14 83
c1 80 74 04 <f0> ff 41 04 83 c4 30 89 d0 5b 5e 5f 5d c3 8b 96 ac 00 00
00 b8
[84634.215174] EIP: [<c021a955>] cfq_set_request+0x175/0x400 SS:ESP
0068:f3c1bb7c
[84634.215616] ---[ end trace d6b605fe4f7ec0e0 ]---
Vi piace?
Il kernel e` 2.6.27.21 openvz e funziona su una Ubuntu 8.04 server
LTS aggiornata.
Se foste avidi di altri elementi sono a disposizione per fornirli.
La domanda e` se non siete in gardo di darmi con grande gentilezza e
competenza (nel senso che siete gentili e competenti) un responso,
dove mi convenga postarlo (qualche forum/ml OPenVZ? La linux kernel?)
ed eventualmente con quali altre informazioni.
Saluti e ringraziamenti a chi sa e puo` rispondere
twistedbrain
Riportando il bug su bugzilla di openvz e poi insistendo, sono
riuscito ad ottenere questa risposta:
I'd suggest using stable openvz kernel (i.e. rhel5 based).
http://wiki.openvz.org/Download/kernel/rhel5
Al che ho chiesto se andava bene anche CentOS e sono in attesa di
risposta al riguardo.
Se non va bene, abbandono, credo per sempre, OpenVZ.
twistedbrain
> Riportando il bug su bugzilla di openvz e poi insistendo, sono
> riuscito ad ottenere questa risposta:
>
>
> Al che ho chiesto se andava bene anche CentOS e sono in attesa di
> risposta al riguardo.
> Se non va bene, abbandono, credo per sempre, OpenVZ.
Mi hanno risposto che a loro basta che il kernel sia quello li`, loro
e stabile basato su RedHat e che per il resto posso non cambiare
nulla, anche se per soffrire meno forse e` meglio portare tutto a RHEL
o CentOS che fosse. Provero`. Per ora le certezze raggiunte sono che
l'ultimo openvz disponibile almeno per me non si e` dimostrato stabile
e che quello di default su Ubuntu 8.04 server LTS, almeno in queste
circostanze, e` stato ancora peggio.
twistedbrain
> On 5 Nov, 21:28, twistedbrain <andrea.ferra...@gmail.com> wrote:
>
> > riuscito ad ottenere questa risposta:
>
>
> > Al che ho chiesto se andava bene anche CentOS e sono in attesa di
> > risposta al riguardo.
> > Se non va bene, abbandono, credo per sempre,OpenVZ.
>
> Mi hanno risposto che a loro basta che il kernel sia quello li`, loro
> e stabile basato su RedHat e che per il resto posso non cambiare
> nulla, anche se per soffrire meno forse e` meglio portare tutto a RHEL
> o CentOS che fosse. Provero`. Per ora le certezze raggiunte sono che
> e che quello di default su Ubuntu 8.04 server LTS, almeno in queste
> circostanze, e` stato ancora peggio.
Incrocio le dita, ma sembra funzionare tutto ormai da quasi 3
settimane senza problemi.
Ho anche visto dai report che mi arrivano del bug che avevo aperto,
che ci stanno lavorando.
Andrea