| View previous topic :: View next topic |
| Author |
Message |
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
 Posted: Mon Mar 08, 2010 7:20 pm Post subject: [Kernel bug at xfs support?] strani blocchi del sistema |
 |
|
Ciao.
Sto notando dei strani comportamenti del sistema.
Innanzitutto, non riesco a fare il sync di emerge. Quando do il comando "emerge --sync" inizia correttamente, ma si blocca dopo un po', e non va più avanti.
Se provo a dare un "emerge -av digikam" si blocca quando sta calcolando le dipendenze. Ma capita solo con quel pacchetto, con gli altri no.
Ho provato a dare un "emerge -e system" per vedere se si risolveva, ma si è bloccato a questo punto:
| Code: |
>>> Emerging (88 of 139) sys-apps/man-pages-3.23
* man-pages-3.23.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ]
* man-pages-gentoo-2.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ]
* checking ebuild checksums ;-) ... [ ok ]
* checking auxfile checksums ;-) ... [ ok ]
* checking miscfile checksums ;-) ... [ ok ]
* CPV: sys-apps/man-pages-3.23
* REPO: gentoo
* USE: elibc_glibc kernel_linux linguas_it nls userland_GNU x86
>>> Unpacking source...
>>> Unpacking man-pages-3.23.tar.bz2 to /var/tmp/portage/sys-apps/man-pages-3.23/work
>>> Unpacking man-pages-gentoo-2.tar.bz2 to /var/tmp/portage/sys-apps/man-pages-3.23/work
xargs: chmod: terminato dal segnale 11
>>> Source unpacked in /var/tmp/portage/sys-apps/man-pages-3.23/work
>>> Compiling source in /var/tmp/portage/sys-apps/man-pages-3.23/work/man-pages-3.23 ...
>>> Source compiled.
>>> Test phase [not enabled]: sys-apps/man-pages-3.23
>>> Install man-pages-3.23 into /var/tmp/portage/sys-apps/man-pages-3.23/image/ category sys-apps
make -j2 install DESTDIR=/var/tmp/portage/sys-apps/man-pages-3.23/image/
for i in man?; do \
install -d -m 755 /var/tmp/portage/sys-apps/man-pages-3.23/image//usr/share/man/"$i" || exit $?; \
install -m 644 "$i"/* /var/tmp/portage/sys-apps/man-pages-3.23/image//usr/share/man/"$i" || exit $?; \
done; \
|
Ho interrotto con Crtl+C e ho ridato il comando "emerge --resume" e questa volta si è bloccato a questo punto:
| Code: |
>>> Emerging (1 of 52) sys-apps/man-pages-3.23
* man-pages-3.23.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ]
* man-pages-gentoo-2.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ]
* checking ebuild checksums ;-) ... [ ok ]
* checking auxfile checksums ;-) ... [ ok ]
* checking miscfile checksums ;-) ... [ ok ]
|
Allego informazioni sul sistema
| Code: |
# emerge --info
Portage 2.1.7.17 (default/linux/x86/10.0/desktop, gcc-4.3.4, glibc-2.10.1-r1, 2.6.31-gentoo-r10 i686)
=================================================================
System uname: Linux-2.6.31-gentoo-r10-i686-Intel-R-_Core-TM-2_Duo_CPU_E8400_@_3.00GHz-with-gentoo-1.12.13
Timestamp of tree: Mon, 08 Mar 2010 13:00:01 +0000
app-shells/bash: 4.0_p35
dev-lang/python: 2.6.4-r1
dev-util/cmake: 2.6.4-r3
sys-apps/baselayout: 1.12.13
sys-apps/sandbox: 1.6-r2
sys-devel/autoconf: 2.13, 2.63-r1
sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1
sys-devel/binutils: 2.18-r3
sys-devel/gcc: 4.3.4
sys-devel/gcc-config: 1.4.1
sys-devel/libtool: 2.2.6b
virtual/os-headers: 2.6.30-r1
ACCEPT_KEYWORDS="x86"
ACCEPT_LICENSE="* -@EULA"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=core2 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -march=core2 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch"
GENTOO_MIRRORS="ftp://mirror.ovh.net/gentoo-distfiles/ ftp://mirror.switch.ch/mirror/gentoo/ "
LANG="it_IT"
LDFLAGS="-Wl,-O1"
LINGUAS="it"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X a52 aac acl acpi alsa berkdb branding bzip2 cairo cdr cli consolekit cracklib crypt cups cxx dbus djvu dri dts dvd dvdr eds emboss encode evo fam firefox flac fortran gdbm gif gnome gpm gstreamer gtk hal iconv ipv6 jpeg jpeg2k ldap libnotify libssh2 mad mikmod mng modules mp3 mp4 mpeg mudflap ncurses nls nptl nptlonly nvidia ogg opengl openmp pam pcre pdf perl png ppds pppd python qt3support quicktime readline reflection sdl session spell spl sse sse2 ssh ssl startup-notification svg sysfs tcpd thunar tiff truetype unicode usb vorbis win32codecs x264 x86 xml xorg xulrunner xv xvid xvmc zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="it" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
|
Last edited by lordalbert on Tue Mar 09, 2010 12:13 pm; edited 1 time in total |
|
| Back to top |
|
 |
Ic3M4n
Advocate
Joined: 02 Nov 2004
Posts: 3489
Location: Bergamo.
|
| Posted: Tue Mar 09, 2010 1:09 am Post subject: |
|
|
dmesg? inode corrotti che fanno bloccare il tutto mentre accedi a determinate parti del filesystem?
è un po' dura dire cosa possa essere... troppo poche le informazioni... |
|
| Back to top |
|
|
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
| Posted: Tue Mar 09, 2010 9:24 am Post subject: |
|
|
| Ic3M4n wrote: | dmesg? inode corrotti che fanno bloccare il tutto mentre accedi a determinate parti del filesystem?
è un po' dura dire cosa possa essere... troppo poche le informazioni... |
se mi dici che altre informazioni possono servire, provvederò a postarle  |
|
| Back to top |
|
|
Ic3M4n
Advocate
Joined: 02 Nov 2004
Posts: 3489
Location: Bergamo.
|
| Posted: Tue Mar 09, 2010 10:30 am Post subject: |
|
|
dmesg? 
le ultime righe prima e dopo il blocco... |
|
| Back to top |
|
|
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
| Posted: Tue Mar 09, 2010 11:36 am Post subject: |
|
|
non è così semplice 
Ho dato un dmesg prima, ma non ho segnato l'output. Vabbè...
Poi ho provato a dare un emerge sync, una delle operazioni che si è sempre bloccata... e infatti anche questa volta, quando arriva ai "metadata/gnome/etcetc"
restituisce i seguenti errori:
| Code: |
rsync: writefd_unbuffered failed to write 8 bytes to message fd [receiver]: Broken pipe (32)
rsync error: error in rsync protocol data stream (code 12) at io.c(1525) [receiver=3.0.6]
|
ha poi cercato di ricollegarsi, e poi altro rsync error per timeout.
Ma quello che ha creato problemi nel postare i dmesg, è che si è bloccato tutto. All'inizio non rispondeva più soltanto firefox e il terminale. Ho provato ad aprire altri programmi come gedit per annotare gli errori, ma non si apriva. Allora ho provato con Ctrl+Alt+Fn a passare al terminale, ma non funzionava. Si è poi bloccato tutto, non terminava sessione e non si spegneva.
Se riesco a vedere l'output di dmesg quando si ripresenta una situazione simile lo posto. Adesso faccio altre prove. |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Tue Mar 09, 2010 11:47 am Post subject: |
|
|
| lordalbert wrote: | | Si è poi bloccato tutto, non terminava sessione e non si spegneva. |
nessun effetto nemmeno con i Magic SysRq ?
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
| Posted: Tue Mar 09, 2010 12:10 pm Post subject: |
|
|
| Kernel78 wrote: | | lordalbert wrote: | | Si è poi bloccato tutto, non terminava sessione e non si spegneva. |
nessun effetto nemmeno con i Magic SysRq ? |
sarebbero?
cmq forse ho individuato il problema. Sembra esserci un bug all supporto xfs nel kernel (stando a quando leggo dall'uotput). Allego l'output di dmesg
| Quote: |
[ 677.301392] Assertion failed: *nmap >= 1, file: fs/xfs/xfs_bmap.c, line: 4846
[ 677.301401] ------------[ cut here ]------------
[ 677.301404] kernel BUG at fs/xfs/support/debug.c:109!
[ 677.301406] invalid opcode: 0000 [#1] SMP
[ 677.301408] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:05:03.0/resource
[ 677.301410] Modules linked in: nvidia(P)
[ 677.301412]
[ 677.301414] Pid: 3858, comm: rsync Tainted: P (2.6.31-gentoo-r10 #2) P5Q
[ 677.301416] EIP: 0060:[<c11bb8f4>] EFLAGS: 00210282 CPU: 0
[ 677.301421] EIP is at assfail+0x10/0x17
[ 677.301422] EAX: 00000054 EBX: 00000000 ECX: 0000f3f3 EDX: 01ad6000
[ 677.301424] ESI: 00000000 EDI: 00000008 EBP: f502bd00 ESP: f502bcf0
[ 677.301426] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 677.301428] Process rsync (pid: 3858, ti=f502a000 task=f53d7300 task.ti=f502a000)
[ 677.301429] Stack:
[ 677.301430] c15a8e43 c159d635 c159c46e 000012ee f502be3c c1175dd9 c11ee07c 00000000
[ 677.301434] <0> 00000002 00001000 f502bd8c c1084b22 c169da80 00000001 c0383a00 c0e4c840
[ 677.301438] <0> 00000000 c0383a00 f6867850 f502bd9c c11ec0ad 01343920 00000000 00800006
[ 677.301442] Call Trace:
[ 677.301446] [<c1175dd9>] ? xfs_bmapi+0x3b/0x1926
[ 677.301450] [<c11ee07c>] ? __make_request+0x303/0x370
[ 677.301453] [<c1084b22>] ? __alloc_pages_nodemask+0xdb/0x451
[ 677.301456] [<c11ec0ad>] ? generic_make_request+0x23c/0x278
[ 677.301458] [<c1081f01>] ? mempool_alloc_slab+0xe/0x10
[ 677.301461] [<c1082161>] ? mempool_alloc+0x33/0xd1
[ 677.301463] [<c11ec19e>] ? submit_bio+0xb5/0xbd
[ 677.301466] [<c1201677>] ? random32+0x16/0x18
[ 677.301469] [<c118c875>] ? xfs_error_test+0x14/0x7b
[ 677.301472] [<c11b4293>] ? xfs_buf_free+0x9a/0x9f
[ 677.301474] [<c11b4366>] ? xfs_buf_rele+0xce/0xd4
[ 677.301476] [<c11aab70>] ? xfs_buf_relse+0x18/0x1b
[ 677.301478] [<c11aad57>] ? xfs_trans_brelse+0x1e4/0x1ea
[ 677.301481] [<c1187319>] ? xfs_dir2_leaf_getdents+0x247/0x80e
[ 677.301485] [<c10b09c4>] ? filldir64+0x0/0xcd
[ 677.301487] [<c1182f5b>] ? xfs_readdir+0xb8/0xc2
[ 677.301490] [<c10b09c4>] ? filldir64+0x0/0xcd
[ 677.301492] [<c10b09c4>] ? filldir64+0x0/0xcd
[ 677.301494] [<c11b50c8>] ? xfs_file_readdir+0x4d/0x64
[ 677.301497] [<c10b09c4>] ? filldir64+0x0/0xcd
[ 677.301499] [<c10b0c68>] ? vfs_readdir+0x63/0x8f
[ 677.301501] [<c10b09c4>] ? filldir64+0x0/0xcd
[ 677.301504] [<c10b0cf7>] ? sys_getdents64+0x63/0xa0
[ 677.301507] [<c1002a84>] ? sysenter_do_call+0x12/0x22
[ 677.301508] Code: 01 52 ba 22 e2 5a c1 50 b8 3f 8e 5a c1 6a 01 6a 10 e8 05 60 04 00 83 c4 14 c9 c3 55 89 e5 51 52 50 68 43 8e 5a c1 e8 ff e8 29 00 <0f> 0b 83 c4 10 eb fe 55 89 e5 57 89 cf 56 89 c6 53 b8 04 52 7a
[ 677.301530] EIP: [<c11bb8f4>] assfail+0x10/0x17 SS:ESP 0068:f502bcf0
[ 677.301534] ---[ end trace 56400400044e17b5 ]---
|
Ho notato che il problema si verifica sempre quando il sync arriva a /metadata/cache/gnome... o qualcosa di simile |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Tue Mar 09, 2010 12:15 pm Post subject: |
|
|
| lordalbert wrote: | | Kernel78 wrote: | | lordalbert wrote: | | Si è poi bloccato tutto, non terminava sessione e non si spegneva. |
nessun effetto nemmeno con i Magic SysRq ? |
sarebbero?
|
un salvagente in casi come questo 
| Code: | | less /usr/src/linux/Documentation/sysrq.txt |
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
|
| Back to top |
|
|
Peach
Advocate
Joined: 08 Mar 2003
Posts: 3686
Location: London, UK
|
| Posted: Tue Mar 09, 2010 8:26 pm Post subject: |
|
|
azz... pesante...
_________________
Gentoo user since 2004.
"It's all fun and games, until someone loses an eye" - mom |
|
| Back to top |
|
|
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
| Posted: Tue Mar 09, 2010 8:49 pm Post subject: |
|
|
| Peach wrote: |
azz... pesante... |
abbastanza. strano che qui non se ne fosse mai accorto nessuno prima!
Cmq l'integrità del filesystem non dovrebbe essere in pericolo, vero? 
EDIT: la mia configurazione di amule è andata persa dall'ultimo riavvio. E anche i dati delle statistiche precedenti sono andati persi. Non so se è un caso, o è imputabile al bug la perdita di alcuni dati. La cosa importante è che il mio storage è su un'altra partizione non xfs |
|
| Back to top |
|
|
Peach
Advocate
Joined: 08 Mar 2003
Posts: 3686
Location: London, UK
|
| Posted: Tue Mar 09, 2010 9:16 pm Post subject: |
|
|
| lordalbert wrote: | abbastanza. strano che qui non se ne fosse mai accorto nessuno prima!
Cmq l'integrità del filesystem non dovrebbe essere in pericolo, vero?
EDIT: la mia configurazione di amule è andata persa dall'ultimo riavvio. E anche i dati delle statistiche precedenti sono andati persi. Non so se è un caso, o è imputabile al bug la perdita di alcuni dati. La cosa importante è che il mio storage è su un'altra partizione non xfs |
sii sicuro di aver disabilitato la write cache tramite [sh]dparm (-W0)
_________________
Gentoo user since 2004.
"It's all fun and games, until someone loses an eye" - mom |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Tue Mar 09, 2010 9:17 pm Post subject: |
|
|
| lordalbert wrote: | | EDIT: la mia configurazione di amule è andata persa dall'ultimo riavvio. E anche i dati delle statistiche precedenti sono andati persi. Non so se è un caso, o è imputabile al bug la perdita di alcuni dati. La cosa importante è che il mio storage è su un'altra partizione non xfs |
se con il termine "riavvio" intendi il crash di cui parlavi sopra ... e se visto che non si spegneva hai dovuto togliere l'alimentazione brutalmente ...
allora si, ti sei giocato i file aperti in scrittura
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
| Posted: Tue Mar 09, 2010 10:02 pm Post subject: |
|
|
| Kernel78 wrote: |
se con il termine "riavvio" intendi il crash di cui parlavi sopra ... e se visto che non si spegneva hai dovuto togliere l'alimentazione brutalmente ...
allora si, ti sei giocato i file aperti in scrittura |
Si, intendevo proprio quello di riavvio 
Vabbè, nulla di grave.
| Peach wrote: |
sii sicuro di aver disabilitato la write cache tramite [sh]dparm (-W0) |
non ho ben capito come controllarlo con sdparm.
Dite sia il caso di segnalare il bug sul bugzilla di gentoo? così magari aggiungono la patch anche sui kernel .30 .31 anche se ora che la patch sarà applicata, si avrà il .32 stabile |
|
| Back to top |
|
|
Peach
Advocate
Joined: 08 Mar 2003
Posts: 3686
Location: London, UK
|
| Posted: Tue Mar 09, 2010 11:19 pm Post subject: |
|
|
| lordalbert wrote: | | Peach wrote: |
sii sicuro di aver disabilitato la write cache tramite [sh]dparm (-W0) |
non ho ben capito come controllarlo con sdparm. |
non uso sdparm, con hdparm ho:
| /etc/conf.d/hdparm: | | sata_all_args="-W0" |
puoi controllare che sia disabilitata con:
| Code: | | # hdparm -I /dev/sda |
e vedi che "Write cache" non sia asteriscata
_________________
Gentoo user since 2004.
"It's all fun and games, until someone loses an eye" - mom |
|
| Back to top |
|
|
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
| Posted: Tue Mar 09, 2010 11:25 pm Post subject: |
|
|
si, è asteriscata...
| Quote: |
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* DOWNLOAD_MICROCODE
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* 64-bit World wide name
* Write-Read-Verify feature set
* WRITE_UNCORRECTABLE_EXT command
* {READ,WRITE}_DMA_EXT_GPL commands
* Gen1 signaling speed (1.5Gb/s)
* Native Command Queueing (NCQ)
* Phy event counters
* Software settings preservation
* SMART Command Transport (SCT) feature set
* SCT Long Sector Access (AC1)
* SCT Error Recovery Control (AC3)
* SCT Features Control (AC4)
* SCT Data Tables (AC5)
unknown 206[12] (vendor specific)
|
devo toglierlo?
Comunque ora son passato al kernel .32 quindi non dovrebbe più verificarsi il problema |
|
| Back to top |
|
|
Peach
Advocate
Joined: 08 Mar 2003
Posts: 3686
Location: London, UK
|
| Posted: Tue Mar 09, 2010 11:29 pm Post subject: |
|
|
| lordalbert wrote: | si, è asteriscata...
| Quote: |
Commands/features:
Enabled Supported:
* Write cache
|
devo toglierlo?
Comunque ora son passato al kernel .32 quindi non dovrebbe più verificarsi il problema |
ci sono i suoi pro e contro nell'averla abilitata o meno. Il pacco è che se hai un freeze di sistema i dati in cache non vengono scritti e nemmeno passati nel journal quindi al riavvio perdi pezzi di file e cose del genere, che generalmente non è bello, specialmente su xfs.
Per questa ragione normalmente me la disabilito. Avrò meno prestazioni come throughput su disco, ma almeno so che i dati sono sempre lì.
_________________
Gentoo user since 2004.
"It's all fun and games, until someone loses an eye" - mom |
|
| Back to top |
|
|
Ic3M4n
Advocate
Joined: 02 Nov 2004
Posts: 3489
Location: Bergamo.
|
| Posted: Wed Mar 10, 2010 11:14 am Post subject: |
|
|
Nel commit è specificato che:
| Quote: | The above only showed up on a CONFIG_XFS_DEBUG=y kernel, because
xfs_bmapi() ASSERTs that it has been asked for at least one map,
|
quindi il bug appare esclusivamente se hai compilato il modulo xfs del kernel con il debug attivato. io fortunatamente no  |
|
| Back to top |
|
|
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
| Posted: Wed Mar 10, 2010 11:21 am Post subject: |
|
|
| Ic3M4n wrote: | Nel commit è specificato che:
| Quote: | The above only showed up on a CONFIG_XFS_DEBUG=y kernel, because
xfs_bmapi() ASSERTs that it has been asked for at least one map,
|
quindi il bug appare esclusivamente se hai compilato il modulo xfs del kernel con il debug attivato. io fortunatamente no |
eh, infatti avevo compilato di fretta e l'avevo abilitato ora è disabilitato invece.
Cmq una cosa che non ho ancora ben capito. Ma ci sono conseguenze dovute a questo bug? O una volta upgradato/disabilitato il modulo di debug ritorna tutto apposto? |
|
| Back to top |
|
|
Ic3M4n
Advocate
Joined: 02 Nov 2004
Posts: 3489
Location: Bergamo.
|
| Posted: Wed Mar 10, 2010 2:53 pm Post subject: |
|
|
| da quanto ho capito il crash avviene nel modulo di debug, credo quando il numero degli elementi presenti in una directory è elevato. Il crash del modulo teoricamente non comporta problemi se riesci a fare un reboot corretto. se hai riavviato il computer in maniera forzata come già detto ti perdi i file aperti in scrittura... |
|
| Back to top |
|
|
Kernel78
Moderator
Joined: 24 Jun 2005
Posts: 3654
|
| Posted: Wed Mar 10, 2010 3:21 pm Post subject: |
|
|
| Ic3M4n wrote: | | da quanto ho capito il crash avviene nel modulo di debug, credo quando il numero degli elementi presenti in una directory è elevato. Il crash del modulo teoricamente non comporta problemi se riesci a fare un reboot corretto. se hai riavviato il computer in maniera forzata come già detto ti perdi i file aperti in scrittura... |
con uno spegnimento forzato il rischio di perdita di dati nei file aperti in scrittura è elevato anche senza questo bug o perlomeno a me era capitato diverse volte su una macchina dove giocavo con le prime versioni di virtualbox che mi freezavano tutto e non ho mai abilitato quel componente nel kernel ...
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con | Code: | | grep -vE '(^[[:space:]]*($|(#|!|;|//)))' |
|
|
| Back to top |
|
|
lordalbert
l33t
Joined: 26 Nov 2006
Posts: 840
Location: Italy
|
| Posted: Wed Mar 10, 2010 3:40 pm Post subject: |
|
|
| Kernel78 wrote: | | Ic3M4n wrote: | | da quanto ho capito il crash avviene nel modulo di debug, credo quando il numero degli elementi presenti in una directory è elevato. Il crash del modulo teoricamente non comporta problemi se riesci a fare un reboot corretto. se hai riavviato il computer in maniera forzata come già detto ti perdi i file aperti in scrittura... |
con uno spegnimento forzato il rischio di perdita di dati nei file aperti in scrittura è elevato anche senza questo bug o perlomeno a me era capitato diverse volte su una macchina dove giocavo con le prime versioni di virtualbox che mi freezavano tutto e non ho mai abilitato quel componente nel kernel ... |
disabilitando il write cache però qualcosina dovrebbe migliorare.
Ad ogni modo è un problema indipendente dal fs |
|
| Back to top |
|
|
Ic3M4n
Advocate
Joined: 02 Nov 2004
Posts: 3489
Location: Bergamo.
|
| Posted: Thu Mar 11, 2010 12:35 am Post subject: |
|
|
| Kernel78 wrote: | | Ic3M4n wrote: | | da quanto ho capito il crash avviene nel modulo di debug, credo quando il numero degli elementi presenti in una directory è elevato. Il crash del modulo teoricamente non comporta problemi se riesci a fare un reboot corretto. se hai riavviato il computer in maniera forzata come già detto ti perdi i file aperti in scrittura... |
con uno spegnimento forzato il rischio di perdita di dati nei file aperti in scrittura è elevato anche senza questo bug o perlomeno a me era capitato diverse volte su una macchina dove giocavo con le prime versioni di virtualbox che mi freezavano tutto e non ho mai abilitato quel componente nel kernel ... |
logico... lui ha chiesto quali problemi poteva avere. un modulo del kernel che crasha può permetterti di riavviare in maniera sana la macchina o no. quindi il problema per lui poteva essere quello. |
|
| Back to top |
|
|
|
Forum italiano (Italian)
