|
[ combuster @ 10.06.2009. 09:49 ] @
[ Tyler Durden @ 10.06.2009. 13:09 ] @
Super!!
Dobices mustuluk za ovo :)
[ combuster @ 10.06.2009. 13:16 ] @
Pa ti rece da ti quota pravi problem a posto si na Gentoo ionako nema sta da cekas (osim ako ne koristis genkernel sa portage-a...)
I nemesys ce da se odusevi :D
[ Tyler Durden @ 10.06.2009. 13:54 ] @
Ne, to je za neke Debian servere, za desktop mi nije frka... :)
[ Silencer @ 10.06.2009. 22:54 ] @
Cudi me da jos nisu krenuli sa 2.7 Kernelom. Mada mi je drago sto cujem da je ext4 ispeglan. Jedva cekam distro koji izadje sa finom podrskom, pa da napokon posle pauze od 3 godine bez linuxa vidim sta se to tolko promenilo.
[ nemysis @ 11.06.2009. 00:28 ] @
Hvala combuster
To je dobra vest, da je izasao novi Kernel.
Ja ne koristim vise genericki Kernel, nego samo Gentoo-Sources.
[ combuster @ 11.06.2009. 08:12 ] @
Hehehe, ja sam do skoro koristio iskljucivo arch-ov generic kernel, pa kada sam krenuo da testiram GMA965 kompajlirao sam 2.6.30-rc4 i koristio ga za testing only, sada kada je izasao 2.6.30 final sam na njemu i pravo da ti kazem vise volim njega da koristim, malko sam ga tunirao...
CONFIG_HZ=1000 (verovao ili ne malo sam se cimao ali mi je stvarno zivlji sistem)
CONFIG_MCORE2=y (umesto generic_cpu)
CONFIG_DRM_i915_KMS=y (ovo za sada jos uvek degradira performanse pa sam primenio kasnije workaround)...
CONFIG_PREEMPT=y (iz svega vidjenog tunirao sam ga iskljucivo za desktop namene)
I naravno da sam ga strip-ovao od svega sto mi nije bilo potrebno, ono bas mi je slim kernel (osim sto sam ostavio podrsku za gomilu usb uredjaja i jos ponekih stvarcica za koje nisam bio siguran da li vaze za moju masinu ili ne...) Ima i nekih specificnih modula za DELL laptopove koji nisu bili ukljuceni u generic kernel pa mi je i to dobro doslo...
Za sada nema problema, juce je drndao lap ceo dan...
[ combuster @ 12.06.2009. 20:43 ] @
Uf, sad sam primetio da zato sto sam promenio sysname prilikom kompajliranja software-a vecina configure skripti ne prolazi jer ne prepoznaje verziju sistema...
Citat:
Arch vostro 2.6.30-DELL #1 SMP PREEMPT Wed Jun 10 13:07:43 CEST 2009 x86_64
Intel(R) Core(TM)2 Duo CPU T5670 @ 1.80GHz GenuineIntel GNU/Linux
Hm, override-ujem ga ja sa --build=x86_64-linux ali me nervira, vidi se iz uname-a da je x86_64 i GNU/Linux u pitanju... Nevermind, za sada je sve ok mada koliko vidim patch-evi se samo gomilaju, izgleda da cim je pusten u opticaj 2.6.30 odmah je community pocela da daje jaci feedback linusu...
[ Srđan Pavlović @ 12.06.2009. 21:25 ] @
A iz kog razloga si bas zapeo da promenis sysname? :) Jel to ono kao ja za poruku GRUB-a? Zezanje? :)
Evo, sad samo Gojku i tebi pise Unix compatible, cini mi se ;)
Ozbiljno, pretpostavljam da je to kompajliranje softvera samo jedan od problema koji moze da
uzrokuje promena tog imena u neko custom, mozda naidjes na jos neke probleme...
[ combuster @ 12.06.2009. 22:23 ] @
Ma naleteo sam odmah na problem sa neprepoznavanjem tastature i misa, neke od hal polisa su bile podesene tako da se uporedi sysname sa stringom Linux, kada sam to promenio u moj sysname sve je bilo ok. Osim toga i ovog sa configure skriptama nemam nikakvih problema, mada ni ovo nije sto se nije dalo resiti ;-)
A jeste zezanje, a znas da iz zezanja i najvise ucimo :D
[ R A V E N @ 18.06.2009. 04:55 ] @
Ja bih da isprobam 3.0.0 Alphu ako ima gdje se za skinuti. 
[ combuster @ 18.06.2009. 06:35 ] @
Hm, 3.0 kernel ? Nikad ni cuo da postoji tako nesto a ni da je u najavi a sacuvaj me Boze da je jos u alpha fazi...
http://www.linux-magazine.com/.../linus_torvalds_no_kernel_3_0/
Ovo sam dobio posle google-anja za svaki slucaj... :)
[ R A V E N @ 18.06.2009. 13:59 ] @
Možda moje pitanje potječe iz nedovoljnog poznavanja, ali pitam se da li bi se Linux kernel mogao preraditi tako da obavlja ulogu operativnog sistema na vozilima koja slijeću na Mars ili letjelicama koje istražuju planete?
Pretpostavljam da ove naprave imaju ugrađen neki tip kompjutera i neki operativni sistem na njemu.
[ combuster @ 18.06.2009. 14:11 ] @
[ madcama @ 18.06.2009. 14:12 ] @
Mozda je to vec i uradjeno.
[ R A V E N @ 18.06.2009. 14:33 ] @
 Da, ali valjda teoretski je nemoguće napraviti OS ili program savršenim, tako da oni i računaju sa nekom mogućnošću greške kada lansiraju te uređaje. Čak je i jedno od onih pokretnih kola dobilo obnovu softwarea direkto sa Zemlje, dok je bilo na Marsu.
Negdje sam pročitao podatak, ne znam da li je tačan, koji kaže da bi otvaranje prosječne Internet stranice na Marsu, sa servera koji se nalazi na Zemlji, uz današnje brzine protoka podataka na relaciji Mars-Zemlja, trajalo oko 8 sati.
[ Srđan Pavlović @ 18.06.2009. 16:33 ] @
Vi to hocete da ovo zavrsi u Advocacy ili u MadZone, kako ste krenuli :)
Bolje da se diskusija ovde ogranici na nove stvari koje donosi 2.6.30 verzija kernela, kako je i pocelo..
POzz ;)
[ combuster @ 21.06.2009. 13:22 ] @
Ubise se od patch-ovanja ovih dana, 17 update kroz git, evo recimo poboljsanja vezana za drm:
Citat:
Merge branch 'drm-linus' of git://git./linux/kernel/git/airlied/drm-2.6
* 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (24 commits)
agp/intel: Make intel_i965_mask_memory use dma_addr_t for physical addresses
agp: add user mapping support to ATI AGP bridge.
drm/i915: enable GEM on PAE.
drm/radeon: fix unused variables warning
agp: switch AGP to use page array instead of unsigned long array
agpgart: detected ALi M???? chipset with M1621
drm/radeon: command stream checker for r3xx-r5xx hardware
drm/radeon: Fully initialize LVDS info also when we can't get it from the ROM.
radeon: Fix CP byte order on big endian architectures with KMS.
agp/uninorth: Handle user memory types.
drm/ttm: Add some powerpc cache flush code.
radeon: Enable modesetting on non-x86.
drm/radeon: Respect AGP cant_use_aperture flag.
drm: EDID endianness fixes.
drm/radeon: this VRAM vs aperture test is wrong, just remove it.
drm/ttm: fix an error path to exit function correctly
drm: Apply "Memory fragmentation from lost alignment blocks"
ttm: Return -ERESTART when a signal interrupts bo eviction.
drm: Remove memory debugging infrastructure.
drm/i915: Clear fence register on tiling stride change.
Yupi! :D
[ Sudomaster @ 21.06.2009. 15:34 ] @
Zaista fino, samo neka se nastavi ovim tempom 
[ combuster @ 21.06.2009. 15:59 ] @
Jeste fino do mojega :(
Sad sam hteo da isprobam tomoyo i rekoh taman da vidim da li su ove ispravke "na papiru" zaista ok...
Patch-ujem 2.6.30 source sa git17 patch-om, rekonfigurisem kernel sa podrskom za tomoyo i kompajliram... Reboot, pazi sad ovo:
1. dmesg|grep drm <<EE: no connectors found on LVDS1 assuming 800x600 8bit>> ili tako nesto
2. X naravno takodje nece da se podigne, ne moze da ocita default rezoluciju na LVDS-u, pap konzola...
Dakle nije do x-a nego vec u kernel-u kada treba da setuje 1280x800 (imam kms enable-ovan) on mi sabije rezoluciju od 800x600
Eto toliko o poboljsanjima, ajd razumem ja jos to nista nije final ali sam naucio sad da se ne radujem prerano samo na osnovu changelog-a...
Tomoyo makar radi kako treba
Code:
(II) intel(0): Creating default Display subsection in Screen section
"Builtin Default intel Screen 0" for depth/fbbpp 24/32
(==) intel(0): Depth 24, (--) framebuffer bpp 32
(==) intel(0): RGB weight 888
(==) intel(0): Default visual is TrueColor
(II) intel(0): Integrated Graphics Chipset: Intel(R) 965GM
(--) intel(0): Chipset: "965GM"
(WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB
(II) intel(0): Resizable framebuffer: available (0 4)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:02.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: drmOpenMinor returns 8
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
(II) [drm] DRM interface version 1.3
(II) [drm] DRM open master succeeded.
(II) intel(0): Output VGA1 has no monitor section
(II) intel(0): Output LVDS1 has no monitor section
(II) intel(0): Output TV1 has no monitor section
(II) intel(0): Output VGA1 disconnected
(II) intel(0): Output LVDS1 connected
(II) intel(0): Output TV1 disconnected
(WW) intel(0): Unable to find initial modes
(EE) intel(0): Output LVDS1 enabled but has no modes
(==) intel(0): video overlay key set to 0x101fe
(==) intel(0): Using gamma correction (1.0, 1.0, 1.0)
(EE) intel(0): No modes.
(II) UnloadModule: "intel"
(EE) Screen(s) found, but none have a usable configuration.
Fatal server error:
no screens found
Napominjem xserver 1.6 je u pitanju, ne treba mu xorg.conf...
[ Sudomaster @ 21.06.2009. 16:26 ] @
Pa šta se buniš još nije final... pošalji critical bug 
[ combuster @ 21.06.2009. 16:59 ] @
Poslao... :D
[ Tyler Durden @ 21.06.2009. 19:35 ] @
Jel se neko slučajno sretao sa ovom greškom? Ne mogu ni na netu ništa da nađem...
Code: [33555.012980] ------------[ cut here ]------------
[33555.012984] WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xc1/0x131()
[33555.012986] Hardware name: X6DH8
[33555.012989] Pid: 228, comm: pdflush Tainted: G W 2.6.30 #1
[33555.012991] Call Trace:
[33555.012995] [<ffffffff80452525>] ? __down_read+0x15/0x9d
[33555.012999] [<ffffffff802b6614>] ? dquot_claim_space+0xc1/0x131
[33555.013004] [<ffffffff80230bf0>] ? warn_slowpath_common+0x72/0x9e
[33555.013008] [<ffffffff802b6614>] ? dquot_claim_space+0xc1/0x131
[33555.013012] [<ffffffff802f4fec>] ? ext4_mb_mark_diskspace_used+0x33f/0x3f8
[33555.013017] [<ffffffff802f364f>] ? ext4_mb_use_preallocated+0x195/0x1bc
[33555.013021] [<ffffffff802f84ed>] ? ext4_mb_new_blocks+0x1c5/0x374
[33555.013026] [<ffffffff802f115c>] ? ext4_ext_get_blocks+0xbfa/0xe0e
[33555.013031] [<ffffffff8032410e>] ? elv_insert+0x169/0x229
[33555.013039] [<ffffffff802e01bc>] ? ext4_get_blocks_wrap+0x110/0x289
[33555.013046] [<ffffffff802e06c7>] ? mpage_da_map_blocks+0xb0/0x59f
[33555.013051] [<ffffffff8025d432>] ? pagevec_lookup_tag+0x1a/0x21
[33555.013056] [<ffffffff8025bd8d>] ? write_cache_pages+0x162/0x322
[33555.013060] [<ffffffff802e0335>] ? ext4_normal_get_block_write+0x0/0x5a
[33555.013065] [<ffffffff802e103e>] ? __mpage_da_writepage+0x0/0x12f
[33555.013069] [<ffffffff802e0e3b>] ? ext4_da_writepages+0x285/0x3e7
[33555.013073] [<ffffffff8025bf89>] ? do_writepages+0x20/0x2d
[ combuster @ 21.06.2009. 21:40 ] @
Jel to dobijas pri kompajliranju ili iz dmesg-a pri boot-ovanju ili je u pitanju critical error?
Code:
/*
* Claim reserved quota space
*/
static void dquot_claim_reserved_space(struct dquot *dquot,
qsize_t number)
{
WARN_ON(dquot->dq_dqb.dqb_rsvspace < number);
dquot->dq_dqb.dqb_curspace += number;
dquot->dq_dqb.dqb_rsvspace -= number;
}
Ovo je funkcija zaduzena za taj warning... Proverava da li ima dovoljno prostora na disku koliko je rezervisano za quota-u i reservise je...
Jel mozes da nam objasnis pod kakvim uslovima i tacno kada ti se javlja upozorenje?
Pratio sam malo dalje ovo:
Code:
/*
* This operation can block, but only after everything is updated
*/
int dquot_free_space(struct inode *inode, qsize_t number)
{
unsigned int cnt;
char warntype[MAXQUOTAS];
/* First test before acquiring mutex - solves deadlocks when we
* re-enter the quota code and are already holding the mutex */
if (IS_NOQUOTA(inode)) {
out_sub:
inode_sub_bytes(inode, number);
return QUOTA_OK;
}
down_read(&sb_dqopt(inode->i_sb)->dqptr_sem);
/* Now recheck reliably when holding dqptr_sem */
if (IS_NOQUOTA(inode)) {
up_read(&sb_dqopt(inode->i_sb)->dqptr_sem);
goto out_sub;
}
spin_lock(&dq_data_lock);
for (cnt = 0; cnt < MAXQUOTAS; cnt++) {
if (!inode->i_dquot[cnt])
continue;
warntype[cnt] = info_bdq_free(inode->i_dquot[cnt], number);
dquot_decr_space(inode->i_dquot[cnt], number);
}
inode_sub_bytes(inode, number);
spin_unlock(&dq_data_lock);
/* Dirtify all the dquots - this can block when journalling */
for (cnt = 0; cnt < MAXQUOTAS; cnt++)
if (inode->i_dquot[cnt])
mark_dquot_dirty(inode->i_dquot[cnt]);
flush_warnings(inode->i_dquot, warntype);
up_read(&sb_dqopt(inode->i_sb)->dqptr_sem);
return QUOTA_OK;
}
EXPORT_SYMBOL(dquot_free_space);
/*
* This operation can block, but only after everything is updated
*/
int dquot_free_inode(const struct inode *inode, qsize_t number)
{
unsigned int cnt;
char warntype[MAXQUOTAS];
/* First test before acquiring mutex - solves deadlocks when we
* re-enter the quota code and are already holding the mutex */
if (IS_NOQUOTA(inode))
return QUOTA_OK;
down_read(&sb_dqopt(inode->i_sb)->dqptr_sem);
/* Now recheck reliably when holding dqptr_sem */
if (IS_NOQUOTA(inode)) {
up_read(&sb_dqopt(inode->i_sb)->dqptr_sem);
return QUOTA_OK;
}
spin_lock(&dq_data_lock);
for (cnt = 0; cnt < MAXQUOTAS; cnt++) {
if (!inode->i_dquot[cnt])
continue;
warntype[cnt] = info_idq_free(inode->i_dquot[cnt], number);
dquot_decr_inodes(inode->i_dquot[cnt], number);
}
spin_unlock(&dq_data_lock);
/* Dirtify all the dquots - this can block when journalling */
for (cnt = 0; cnt < MAXQUOTAS; cnt++)
if (inode->i_dquot[cnt])
mark_dquot_dirty(inode->i_dquot[cnt]);
flush_warnings(inode->i_dquot, warntype);
up_read(&sb_dqopt(inode->i_sb)->dqptr_sem);
return QUOTA_OK;
}
EXPORT_SYMBOL(dquot_free_inode);
Hm, i sad nemam pojma da li je problem pri rezervisanju prostora definisane quota-om ili pri oslobadjanju quote prostora. kako kazu u komentarima ako tada filesystem obavlja journaling moze doci do blokiranja...
[Ovu poruku je menjao combuster dana 21.06.2009. u 23:11 GMT+1]
[ Tyler Durden @ 22.06.2009. 10:30 ] @
To vraća dmesg kad su uključene kvote i delayed allocation :-)
Nisam primjetio da je došlo do nekog gubitka podataka ili nečeg sličnog, ali mi se ne sviđa to uopšte.
Sad mi je trenutno opet isključeno delayed allocation.
[ combuster @ 22.06.2009. 10:59 ] @
http://kerneltrap.org/index.ph...e/linux-ext4/2008/11/7/4017534
https://bugzilla.redhat.com/show_bug.cgi?id=490628
Heh, izgleda mi i da sam pogodio deo source-a :) (pogledaj pdf u attachment-u)
Izgleda mi da nije neki critical bug koliko je u stvari feature dok se ovo sve ne razresi, mozda to isprave skroz na skroz kroz reviziju 2.6.30 kernel-a ili ces sacekati jos dva meseca do 2.6.31. No delalloc resava stvar privremeno ali ko sto ti rece u onom thread-u o quota na debian-u srozava ti performanse jbg...
[ Sudomaster @ 23.06.2009. 11:38 ] @
Koliko mo\e da se primeti ovaj kernel je jako nestabilan, zato je najbolje sacekati finalni izlazak, finalni mislim sa ispravljenim bugovima 
[ combuster @ 23.06.2009. 13:31 ] @
Pa ja sam evo na 2.6.30 od momenta kako je uploadovan na ftp.kernel.org i nijedan freeze ili nesto slicno... Jedino ovaj git17 sto sam probao kasnije pa ima bug u i915 modulu ali ispravice to valjda...
[ Sudomaster @ 23.06.2009. 13:39 ] @
A koji distro koristis?
[ combuster @ 23.06.2009. 14:00 ] @
Arch linux...
[ combuster @ 27.06.2009. 08:54 ] @
Posto sam hteo da enable-ujem tomoyo rekoh ajde da skinem 2.6.31-rc1 i da iskompajliram kad ne lezi vraze...
KMS ne radi, tj ne mogu ni da pokrenem X, i915 ne moze da setuje mod na LVDS-u pa me baca u framebuffer rezoluciju u 800x600, samim tim ni X ne moze da se startuje jer kao i pri boot-u ne moze da setuje korektan mod...
Code:
[drm:drm_helper_initial_config] *ERROR* connectors have no modes, using standard modes
Jun 26 11:01:40 vostro kernel: allocated 800x600 fb: 0x007df000, bo ffff88007d9b3480
Jun 26 11:01:40 vostro kernel: Console: switching to colour frame buffer device 100x37
Jun 26 11:01:40 vostro kernel: [drm] LVDS-8: set mode 800x600 18
Poslao sam mail Jesse Barnes-u koji radi na razvoju intel-ovog drajvera pa mi rece da su ispravke dospele u linus-ov tree i evo sad skidam snapshot sa git-a...
Istina snimio sam da su radili na intel-ovom drajveru (intel_lvds.c je patch-ovan za korektnu detekciju lvds modova) a da li radi videcemo za koji sat...
Podneo sam bug report za ovo kao i za jos dva bug-a vezana za intelov xorg drajver, izgleda da nisu ni znali za njih koliko sam primetio po Jesse-jevom mail-u...
http://bugzilla.kernel.org/show_bug.cgi?id=13593
https://bugs.freedesktop.org/show_bug.cgi?id=22503
https://bugs.freedesktop.org/show_bug.cgi?id=22504
[update]
Ispravili su bug i ne da su ga samo ispravili nego su mi performanse x3100 skocile duplo, glxgears sa 420 na 1000fps, urban terror takodje dupliran framerate...
Sta god da rade samo neka nastave, bojiim se samo da za dva meseca za koliko ocekujem 2.6.31 imaju dosta vremena da naprave neko s***** :D
[Ovu poruku je menjao combuster dana 27.06.2009. u 11:34 GMT+1]
[ BigFoot @ 27.06.2009. 23:06 ] @
Citat: combuster: Code:
/* Now recheck reliably when holding dqptr_sem */
if (IS_NOQUOTA(inode)) {
up_read(&sb_dqopt(inode->i_sb)->dqptr_sem);
goto out_sub;
}
Nije ni čudo što se pojavljuju bug-ovi kad još koriste goto naredbu. Mislio sam da je izbačena pre mnogo godina 
[ Srđan Pavlović @ 27.06.2009. 23:15 ] @
Nije problem u samoj GOTO naredbi, vec u njenom velikom potencijalu da je oni koji NE ZNAJU, neispravno iskoriste ;)
[ combuster @ 27.06.2009. 23:20 ] @
Jos je ona tu za one koje programiraju prljavo :) Istina goto u c-u treba da se izbegava kad god je to moguce... Zar nije lakse jednostavno pozvati funkciju sa eventualno neophodnim parametrima za prosledjivanje? Sta znas, mozda ima i ovih sto su navikli na assembler pa naletis na JNE :) Jos crnja varijanta :D
[ Srđan Pavlović @ 27.06.2009. 23:25 ] @
GOTO je prosto naredba bezuslovnog prelaska sa jednog dela koda na izvrsavanje nekog drugog,
i u samoj toj cinjenici nema nikakav problem. Problem moze nastati ako programer ima pogresan
algoritam, pa sa goto naredbom napravi neke skokove koji uzrokuju infinite loop-ove ili nesto slicno,
zast je opet odgovoran sam programer zbog toga sto on osmilja logiku koda, a ne sama naredba ;)
Ali, opet kazem, bilo koja druga naredba, neadekvatno upotrebljena, moze napraviti potpuno isto
s***** kao i goto naredba.
[ combuster @ 27.06.2009. 23:34 ] @
Pa najveci problem je upravo kao sto si i rekao kod dead loop-ova, kod struktuiranog programiranja ako skocis pomocu goto na odredjeni deo kod-a jos pogotovo prilikom ispitivanja nekog uslova (kao sto je u ovom slucaju) mozes da napravis zestoko s*****... Ali oni znaju kakav se rezultat ocekuje ispitivanjem tog uslova i moze se iskoristiti za skok na odredjeni deo kod-a sve dok se uslov ne ispuni (ili ispuni)... Uglavnom svakako da kernel developeri nisu blesavi toliko :)
[ combuster @ 17.07.2009. 09:29 ] @
Copyright (C) 2001-2025 by www.elitesecurity.org. All rights reserved.
|