Jozef Babjak napsal/wrote, On 03/21/07 08:23:
>> > no.. zrovna tohle mne na fbsd dost se*e.. ty ruzne limity a vubec
>> > vetsina
>> > hardcoded hodnot ma velikosti nekdy z 80tych let a je to cele naprd...
>> Takze nejake limity nakonec stejne potrebujes a muzes jen spekulovat
>> nad zp
On Wed, Mar 21, 2007 at 08:02:57AM +0100, Jozef Babjak wrote:
> > > no.. zrovna tohle mne na fbsd dost se*e.. ty ruzne limity a vubec
> > > vetsina
> > > hardcoded hodnot ma velikosti nekdy z 80tych let a je to cele naprd...
> > presne tak, uz by mel nekdo zacommitovat zmenu defaultniho poctu
On Wed, Mar 21, 2007 at 08:23:04AM +0100, Jozef Babjak wrote:
> > > no.. zrovna tohle mne na fbsd dost se*e.. ty ruzne limity a vubec
> > > vetsina
> > > hardcoded hodnot ma velikosti nekdy z 80tych let a je to cele naprd...
> >
> > Takze nejake limity nakonec stejne potrebujes a muzes je
> > no.. zrovna tohle mne na fbsd dost se*e.. ty ruzne limity a vubec
> > vetsina
> > hardcoded hodnot ma velikosti nekdy z 80tych let a je to cele naprd...
>
> Takze nejake limity nakonec stejne potrebujes a muzes jen spekulovat
> nad zpusobem, jak je zadavat, jestli maji byt staticke
> > no.. zrovna tohle mne na fbsd dost se*e.. ty ruzne limity a vubec
> > vetsina
> > hardcoded hodnot ma velikosti nekdy z 80tych let a je to cele naprd...
> presne tak, uz by mel nekdo zacommitovat zmenu defaultniho poctu
> semaforu z 10 rekneme na 500, shmmax taky neni nastaveno zvlast
^
Divacky Roman napsal/wrote, On 03/20/07 15:19:
>> Otazka znie, ze ci to je spravne spravanie, ak moze neprivilegovany
>> uzivatel dosiahnut reboot stroja. Ja by som to videl na nejaky bug
>> v kerneli.
>
> to rozhodne neni bug v kernelu :)
No, nerad bych se poustel na tenky led uvah co je
> no.. zrovna tohle mne na fbsd dost se*e.. ty ruzne limity a vubec vetsina
> hardcoded hodnot ma velikosti nekdy z 80tych let a je to cele naprd...
presne tak, uz by mel nekdo zacommitovat zmenu defaultniho poctu
semaforu z 10 rekneme na 500, shmmax taky neni nastaveno zvlast
stedre. U solaris
> To mi je vsetko zhruba jasne, ale dakujem za vysvetlenie. Nemal by vsak
> kernel v takomto stave reagovat radsej tak, ze nedovoli uz vytvorit
> dalsie vlakno a teda ze zabije inkriminovany proces sam? Aj SIGSEGV
> signal zaslany takejto chybnej aplikacii by bol tuto namieste.
ale ono to nepanic
> A jak zni otazka ?
>
> Kazdy novy thread vyzaduje aby pro ni kernel drzel jakousi datovou
> strukturu. Mnozstvi pameti kernelu dostupne je vsak omezene. Po
> vycerpani dalsi alokace mozna neni - a to dopadne prave takhle.
fakt jo? :) chvilku predstirejme ze jsem Dan a napisu dlou
On Tue, Mar 20, 2007 at 02:27:24PM +0100, Dan Lukes wrote:
> Lubomir Host napsal/wrote, On 03/20/07 10:04:
> > stretol sa niekto niekedy s takymto problemom? Tuto je vypis dmesg:
>
> > Mar 20 09:44:14 vyvoj kernel: collecting pv entries -- suggest increasing
> > PMAP_SHPGPERPROC
> > Mar 20 09:46:
Dan Lukes wrote:
> Lubomir Host napsal/wrote, On 03/20/07 10:04:
>> stretol sa niekto niekedy s takymto problemom? Tuto je vypis dmesg:
>
>> Mar 20 09:44:14 vyvoj kernel: collecting pv entries -- suggest increasing
>> PMAP_SHPGPERPROC
Tato chyba sa mne osobne prejavovala pri HW problemoch so str
Lubomir Host napsal/wrote, On 03/20/07 10:04:
> stretol sa niekto niekedy s takymto problemom? Tuto je vypis dmesg:
> Mar 20 09:44:14 vyvoj kernel: collecting pv entries -- suggest increasing
> PMAP_SHPGPERPROC
> Mar 20 09:46:11 vyvoj syslogd: kernel boot file is /boot/kernel/kernel
> Mar 20 09:4
Zdravim,
stretol sa niekto niekedy s takymto problemom? Tuto je vypis dmesg:
%<
Mar 20 09:43:59 vyvoj kernel: collecting pv entries -- suggest increasing
PMAP_SHPGPERPROC
Mar 20 09:44:04 vyvoj
13 matches
Mail list logo
