# [Kernel bug at xfs support?] strani blocchi del sistema

## lordalbert

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:

```

>>> 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:

```

>>> 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

```

# 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

----------

## Ic3M4n

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...

----------

## lordalbert

 *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  :Smile: 

----------

## Ic3M4n

dmesg?   :Rolling Eyes: 

le ultime righe prima e dopo il blocco...

----------

## lordalbert

non è così semplice  :Very Happy: 

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:

```

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.

----------

## Kernel78

 *lordalbert wrote:*   

> Si è poi bloccato tutto, non terminava sessione e non si spegneva.

 

nessun effetto nemmeno con i Magic SysRq ?

----------

## lordalbert

 *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 ]------------
> ...

 

Ho notato che il problema si verifica sempre quando il sync arriva a /metadata/cache/gnome...  o qualcosa di simile

----------

## Kernel78

 *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  :Wink: 

```
less /usr/src/linux/Documentation/sysrq.txt
```

----------

## lordalbert

qua una descrizione. http://oss.sgi.com/bugzilla/show_bug.cgi?id=850

E' un bug noto. L'unica soluzione è quindi upgradare alla 2.6.32  :Sad: 

----------

## Peach

 *lordalbert wrote:*   

> qua una descrizione. http://oss.sgi.com/bugzilla/show_bug.cgi?id=850
> 
> E' un bug noto. L'unica soluzione è quindi upgradare alla 2.6.32 

 

azz... pesante...

----------

## lordalbert

 *Peach wrote:*   

>  *lordalbert wrote:*   qua una descrizione. http://oss.sgi.com/bugzilla/show_bug.cgi?id=850
> 
> E' un bug noto. L'unica soluzione è quindi upgradare alla 2.6.32  
> 
> 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?   :Confused: 

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  :Smile: 

----------

## Peach

 *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)

----------

## Kernel78

 *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

----------

## lordalbert

 *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  :Razz: 

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

----------

## Peach

 *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:

```
sata_all_args="-W0"
```

puoi controllare che sia disabilitata con:

```
# hdparm -I /dev/sda
```

e vedi che "Write cache" non sia asteriscata

----------

## lordalbert

si, è asteriscata...

 *Quote:*   

> 
> 
> Commands/features:
> 
> 	Enabled	Supported:
> ...

 

devo toglierlo?

Comunque ora son passato al kernel .32 quindi non dovrebbe più verificarsi il problema

----------

## Peach

 *lordalbert wrote:*   

> si, è asteriscata...
> 
>  *Quote:*   
> 
> Commands/features:
> ...

 

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ì.

----------

## Ic3M4n

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   :Laughing: 

----------

## lordalbert

 *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,
> ...

 

eh, infatti avevo compilato di fretta e l'avevo abilitato  :Very Happy:  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?

----------

## Ic3M4n

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...

----------

## Kernel78

 *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 ...

----------

## lordalbert

 *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  :Smile: 

----------

## Ic3M4n

 *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.

----------

