Newsgroup: it.politica
Titolo: OT - Kernel Panic

Incredibile!
 
Per la seconda volta nella mia vita da utente Mac OS X, mi e' crashato il
sistema. Visto che ne abbiamo parlato recentemente (credo buddenbrook).
DEM, mi dispiace, ma crasha anche il mac.
 
Thu Jan 12 15:20:04 2012
 
panic(cpu 0 caller 0x2951bf): "pmap_pv_remove(0xdf7aa6c,0xd000,0x42000,
0x42000000): pv not on hash, head: 0xdf7ab54,
0x188eff000"@/SourceCache/xnu/xnu-1504.15.3/osfmk/i386/pmap_internal.h:742
 
BSD process name corresponding to current thread: gtar
 
Kernel version:
Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011;
root:xnu-1504.15.3~1/RELEASE_I386
System model name: MacBookPro5,3 (Mac-F22587C8)
 
 

 DEM, mi dispiace, ma crasha anche il mac.
 
A me è crashato diverse volte, anche per colpa di problemi hardware.
Hardware originale del macbook, in ogni caso.
 
(Per Windows 7, non sono soddisfatto delle performance ma non è mai
crashato; Ubuntu talvolta si incasina da solo in fase di aggiornamento
ma non crasha neanche lui).
 
-- bb

 ma non crasha neanche lui).
 
Boh!

 Mah, per l'hardware, ho cambiato RAM settimana scorsa, 4-> 8 Gb.
 
ehm ...

 ehm ...
 
Di piu' non si poteva :)


Strano comunque ... nel senso che o la ram ha problemi (ma di solito
non va giù di botto, incomincia a dare segnali che dovresti vedere sul
messages del sistema) oppure , se la vede durante il boot, non vedo
perchè dovrebbe dare problemi in seguito.
 
Cosa stavi facendo?

 wrote:

E certo che che "crashia" anche quello. Crascia il DB2 sopra
l' MVS , figuriamoci.
 
Comunque mi sembra di capire che hai un programma residente
in ram che si va ad impicciare con la tabella in memoria che mantiene
i puntamenti dei processi attivi.
 
Ci vorrebbe un sistemista di quelli con i controcoglioni, anche
perche' (immagino) 'sto cazzo di programma non lo fa sempre.
 
 

 Cosa stavi facendo?
 
Subroutine che apre archivi .tgz, estrare in una temp creata ad-hoc,
parsing, salvataggio in piu' hash.
 
Su queste hash devo fare delle statistiche.
 
Settimana scorsa ho comprato RAM perche' ho visto che alcuni algoritmi
calcolavano le distribuzioni statistiche con una passata sola, su tutta la
hash caricata in memoria, via Perl Data Language.
 
dim hash = 16.3 millions points, float. 
 
Magari con una linux nativa a 64bit andava meglio. Lo stack del mac e'
piccolo, non ci sta nulla dentro e malloc stiantava con:
 
malloc: *** mmap(size=112 238 592) failed (error code=12)
 
Mi e' chiaro che Perl alloca le hash frammentate e non potendo
ricompilarlo a 64bit, piuttosto che dividere in chunks il dataset e poi
ricomporre le distribuzioni (con evidenti problemi di introdurre
artifatti) ho deciso di ampliare la RAM.
 
Inoltre Perl non restituisce subito la memoria all'OS, e ha un suo Garbage
Collector di cui io non ho la minima idea.
 
(Alla fine mi sono convertito ad un algoritmo online ricorsivo,
comunque).
 
Comuqnue qui e' la subroutine dove probabilmente e' schiattato l'OS.
 
 
sub collectfilesfromtar(){
 
  my ($DIR, $SDATE, $EDATE) = @_;
 
  my @filelist = <$DIR/*/*/*.tgz>;
  push(@filelist,<$DIR/*.tgz>);
 
  my @reslist = findinfilelist(\$SDATE,  \$EDATE, \@filelist);
  if(!@reslist){ die " --- No files found in $DIR\n"; }
 
  my @filesextfromtar; my @allfilesfromtar;
 
  foreach my $filename (@reslist){
    @filesextfromtar =  `tar vxzf $filename`;
 
/* ---------------------------------------------
/* a questo punto, dopo un centinaio di .tgz 
/* aperti e letti mi compare nel log:
 
tar: Skipping to next header
gzip: stdin: invalid compressed data--crc error
gzip: stdin: invalid compressed data--length error
tar: Child returned status 1
tar: Error is not recoverable: exiting now
 
/* ma non so se e' stato questo il problema. Mi sembrerebbe MOLTO strano.
/* ---------------------------------------------------------------------
 
    my @filesextfromtar = grep(!/\.dlr$/, @filesextfromtar);
    push(@allfilesfromtar, @filesextfromtar) if(@filesextfromtar;
 
  return(@allfilesfromtar);
}

 parsing, salvataggio in piu' hash.
 
Vorrei dirti che sto facendo un po' il cialtrone ( non troppo pero' )
visto che di mac non so niente.
 
pero ...
 
se un os va in crash per una serie di tar è da buttare. Siccome non
credo sia così instabile, potrebbe mancarti qualche patch. Mac ha un
database dove cercare e scaricare le patch? se sì , andrei a cercare
qualche "critical"( se mi va giù per un tar non può che essere così)
da tirare giù.
 
I messaggi di errore che ricevi sono direi classici ... gzip di file
troppo grossi , tar di file che o non ci sono o sono o sembrano
corrotti ...
 
non è che prima non utilizzavi del tutto la ram e , con i programmi
che stai facendo girare adesso , la utilizzi tutta e vai a "trovare"
banchi di ram difettosi che non avevi mai esplorato?
 
Direi che ti conviene sperare che posti qualche skilled specializzato
di mac :-)
 
 
 
 

 da tirare giù.
 
Probabile, non ci avevo pensato. 
E' la prima volta che fa cosi' con tar. Non e' sistematico. A logica,
sembra giustamente la gestione della RAM. 
Vedremo. Speriamo non lo faccia piu'. 
Comunque un punto a favore degli anti-mac :)

Comunque un punto a favore degli anti-mac :)
 
Trovato l'errore. 
Non hai quotato il carattere "." dei file con il carattere di escape
"\".
 
fp.copy("/home/neurino/.foto/mohamm_nudo.jpg","/var/tmp/foto_zozze/mohamm_nudo.jpg",fp.len,
TRUE);
...
fp.copy("/home/neurino/.foto/cazzone_turco.jpg","/var/tmp/foto_zozze/cazzone_turco.jpg",fp.len,TRUE)
...
sys.exec("gtar --add "/var/tmp/foto_zozze/mohamm_nudo.jpg") 
[WRITELOG] Fatal error, invoke kernel panic!
sys.proc.send(KERNEL_PANIC)
 
 
 


Butta via tutto e comprati un pc serio. e hai risolto.
 
Salvini

 'stardo! ;-)
 
Fa la pazza e la gelosa solo perche' non lo invito ai festini á-la-turca
che gli piacciono tanto.

 Butta via tutto e comprati un pc serio. e hai risolto.
 
Ma quanto sei cialtrone?


Dipende, quando cazzeggio direi 8 in una scala da uno a 10.
 
Salvini