10 najpopularniejszych błędów w jądrze Linux znajdowanych w mijającym tygodniu
- Dodano: 23 maja 2008
- Wprowadził: optimizationkit
- Komentarze: 19
Arjan van de Ven podesłał swój cotygodniowy raport zawierający zestawienie dziesięciu najczęściej znajdowanych błędów w Linuksie w mijającym tygodniu.
Numerem 1 jest WARN_ON: __register_sysctl_paths
Zgłoszony 1260 razy (2491 razy w całej swojej karierze)
Występuje na jądrze splugawionym (ang. tainted pewnie więcej mówi, ale tłumaczenie mi się bardzo podoba 
) przez sterownik madwifi (okazyjnie widziany w sterowniku portu równoległego).
Ten błąd był ostatnio widziany w 2.6.25.4, po raz pierwszy znaleziony w 2.6.25-rc3.
Więcej informacji: http://www.kerneloops.org/searchweek.php?search=__register_sysctl_paths
Numerem 2 jest WARN_ON: sysfs_add_one
Zgłoszony 264 razy (528 razy w całej swojej karierze)
Najprawdopodobniej błąd Grega KH.
Ten błąd był ostatnio widziany w 2.6.26-rc3, po raz pierwszy znaleziony w 2.6.24-rc6.
Więcej informacji: http://www.kerneloops.org/searchweek.php?search=sysfs_add_one
Numerem 3 jest WARN_ON: mark_buffer_dirty
Zgłoszony 253 razy (547 razy w całej swojej karierze)
Błąd Ext3, który można wywołać odłączając urządzenie bez wcześniejszego odmontowania systemu plików.
Ten błąd był ostatnio widziany w 2.6.25.3, po raz pierwszy znaleziony w 2.6.24-rc6.
Więcej informacji: http://www.kerneloops.org/searchweek.php?search=mark_buffer_dirty
Numerem 4 jest WARN_ON: bad_io_access
Zgłoszony 111 razy (153 razy w całej swojej karierze)
Błąd w pata_isapnp powoduje wywalenie innych sterowników ata
Łatka dostępna w http://bugzilla.kernel.org/show_bug.cgi?id=10752
Ten błąd był ostatnio widziany w 2.6.25.3, po raz pierwszy znaleziony w 2.6.24.
Więcej informacji: http://www.kerneloops.org/searchweek.php?search=bad_io_access
Numerem 5 jest OOPS: _spin_unlock_irqrestore
Zgłoszony 80 razy (207 razy w całej swojej karierze)
Wygląda na to, że występuje gdy system jest bezczynny… problem sprzętowy?
Ten błąd był ostatnio widziany w 2.6.25.3, po raz pierwszy znaleziony w 2.6.22-rc1.
Więcej informacji: http://www.kerneloops.org/searchweek.php?search=_spin_unlock_irqrestore
Numerem 6 jest WARN_ON: ieee80211_stop_tx_ba_session
Zgłoszony 49 razy (104 razy w całej swojej karierze)
Błąd w sterowniku iwl4965
Ten błąd był ostatnio widziany w 2.6.25.3, po raz pierwszy znaleziony w 2.6.25-rc7-git6.
Więcej informacji: http://www.kerneloops.org/searchweek.php?search=ieee80211_stop_tx_ba_session
Numerem 7 jest WARN_ON: __alloc_pages
Zgłoszony 49 razy (79 razy w całej swojej karierze)
Błąd w sterownikach sata_nv i velocity. Łatka dla sata_nv dostępna w http://lkml.org/lkml/2008/5/20/604
Ten błąd był ostatnio widziany w 2.6.25.3, po raz pierwszy znaleziony w 2.6.18-rc1.
Więcej informacji: http://www.kerneloops.org/searchweek.php?search=__alloc_pages
Numerem 8 jest WARN_ON: set_irq_wake
Zgłoszony 38 razy (zgłoszony 43 w całej swojej karierze)
Błąd w serial_core.c wynikający z niepoprawnego zrównoważenia disable_irq_wake/enable_irq_wake.
Łatka dostępna w http://lkml.org/lkml/2008/5/20/218 (i -mm)
Ten błąd był ostatnio widziany w 2.6.25.3, po raz pierwszy znaleziony w 2.6.25-rc9-git1.
Więcej informacji: http://www.kerneloops.org/searchweek.php?search=set_irq_wake
Numerem 9 jest OOPS: task_has_capability
Zgłoszony 38 razy
Występuje na jądrze splugawionym sterownikiem firegl
Ten błąd był ostatnio widziany w 2.6.25.3, po raz pierwszy znaleziony w 2.6.25.
Więcej informacji: http://www.kerneloops.org/searchweek.php?search=task_has_capability
Numerem 10 jest OOPS: sk_free
Zgłoszony 29 razy (109 razy w całej swojej karierze)
Występuje na jądrze splugawionym przez VMWare.
Ten błąd był ostatnio widziany w 2.6.25.4, po raz pierwszy znaleziony w 2.6.23.9.
Więcej informacji: http://www.kerneloops.org/searchweek.php?search=sk_free
Na stronie projektu kerneloops.org znajduje się statystyka pokazująca ilość zebranych błędów w bazie dla poszczególnych wersji jądra systemu
| 2.6.20 | 111 |
| 2.6.21 | 99 |
| 2.6.22 | 189 |
| 2.6.23 | 237 |
| 2.6.24 | 2006 |
| 2.6.25 | 5344 |
Jednak nie należy tego odczytywać jako dramatyczny wzrost ilości znajdowanych w jądrze błędów, tylko jako dramatyczny wzrost ilości błędów, które mają szansę dotrzeć do świadomości deweloperów jądra. Ten wzrost jest w dużej mierze spowodowany włączeniem do Fedory 8 i 9 programu kerneloops, który monitoruje logi systemowe i automatycznie wysyła znalezione błędy (w Fedorze 9 jest on domyślnie zainstalowany). Należy mieć nadzieję, że inne dystrybucje pójdą za tym przykładem i w nich kerneloops również będzie domyślnie zainstalowany.
Jeśli ktoś nie chce czekać na nowe wydanie ulubionej dystrybucji i już teraz chce automatycznie wysyłać do deweloperów informacje o błędach w swoim systemie, to polecam pobranie źródeł kerneloops lub pakietów przygotowanych dla Debiana, Gentoo.
Więcej informacji: http://www.ussg.iu.edu/hypermail/linux/k.../3928.html
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
19 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
No właśnie. Tak nie wiele do zrobienia (zainstalowanie programu), ale za to ogromna pomoc dla developerów przy wyłapywaniu i poprawianiu kernela. Problem tylko w tym, że aby wyłapywać oopsy, trzeba mieć włączony debug kernela, inaczej kerneloops tego nie wyłapie. Cytując odpowiedź Dave'a Jones'a na pytanie czy kerneloops wyłapie błędy w kernelu z wyłączonym debugiem:
[w wolnym tyłumaczeniu: od kąd w stabilnym kernelu debugowanie jest wyłączone, musisz zainstalować pakiet kernel-debug aby go dalej móc wyłapywać (zakładając że błąd wciąż tam jest) ]
DEBUG_KERNEL jest potrzebny do włączenia choćby 4KB stosu, który w Fedorze jest od hoho… Dave miał chyba na myśli DEBUG_INFO, bez którego backtrace błędu jest mniej użyteczny.
mam kerneloops, ale w takim razie co dokładnie jeszcze muszę zrobić aby moje errory leciały do developerów?
Sprawdź konfigurację w /etc/kerneloops.conf i uruchamiaj /usr/sbin/kerneloops podczas każdego startu systemu.
Warto zaznaczyć, że kerneloops nie wyśle każdego błędu – czasami zdarza się tak, że treść błędu nie zostanie zapisana w logu, więc kerneloops niczego nie zauważy. Wtedy trzeba się pobawić konsolami szeregowymi/sieciowymi/etc.
W pliku konfiguracyjnym mam:
allow-submit = ask
allow-pass-on = yes
submit-url = http://submit.kerneloops.org/submitoops.php
kerneloops mi się ładuje podczas startu
ale nigdy nie wyskoczyło mi żadne okienko z pytaniem czy wysłać loga
a polecenie kerneloops w konsoli nic nie uruchamia
jak sprawdzić czy to działa?
#kerneloops –debug
ale nie wiem czy po restarcie kompa to będzie działało, czy trzeba za każdym razem wpisywać.
#kerneloops –debug
o tak jest poprawnie (dwie kreski)
no tak, automatycznie są usuwane…
Sforumolowanie "czestosc znajdywania bledow" chyba nie jest najszczesliwsze… blad wystarczy znalezc raz. Przydaloby sie napisac precyzyjnie co opisuja te statystki (rowniez tabelka ponizej) – liczbe zgloszen/tydzien, liczbe unikalnych zgloszen?
Domyslam sie ze chodzi o czestosc wystepowania bledow/zglaszania ich z wykorzystaniem kerneloops?
"blad wystarczy znalezc raz"
Chyba nie zrozumiałeś do końca intencji – najczęściej znajdowane, czyli takie, które są znajdowane na wielu systemach i uprzykrzają życie wielu użytkownikom.
"Przydaloby sie napisac precyzyjnie co opisuja te statystki (rowniez tabelka ponizej) – liczbe zgloszen/tydzien, liczbe unikalnych zgloszen?"
Napisz do Arjana lub stwórz własne statystyki
"Domyslam sie ze chodzi o czestosc wystepowania bledow/zglaszania ich z wykorzystaniem kerneloops?"
Nie tylko, projekt kerneloops zbiera też dane z list dyskusyjnych i bugzilli.
developerzy sie przejma, ze system wykrywa bledy blednego odlaczenia systemu plikow
uruchomiłem kerneloops i wyświetliło mi raport w konsoli, co z tym zrobić?
U mnie wyświetlane jest okienko mówiące, że znaleziono błąd bla bla bla i czy chcę go wysłać – dlatego niewiele mi mówi to co piszesz. Może gdybyś powiedział co jest w nim napisane ew. wrzucił go tutaj.
http://madwifi.org/wiki/DevDocs/KernelOops
nie widzę czy pyta o wysłanie, oto treść raportu
[root@localhost mariusz]# kerneloops –debug
Starting kerneloops in debug mode
Found start of oops at line 13208
start line is -Unable to handle kernel paging request at ffffc200009600f8 RI
P: -
Submit text is:
—[start of oops]—
Unable to handle kernel paging request at ffffc200009600f8 RIP:
[] :fglrx:ulReadMmRegisterUlongViaAddr+0×9/0×10
PGD 3ed0c067 PUD 3ed0d067 PMD 3dd68067 PTE 0
Oops: 0000 [1] SMP
CPU 0
Modules linked in: ipt_IFWLOG ipt_psd ip_set_iptree iptable_raw xt_comment xt_po
licy ipt_ULOG ipt_TTL ipt_ttl ipt_TOS ipt_tos ipt_set ipt_SAME ipt_REJECT ipt_RE
DIRECT ipt_recent ipt_owner ipt_NETMAP ipt_MASQUERADE ipt_LOG ipt_iprange ipt_EC
N ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic nf_nat
_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amand
a ts_kmp nf_conntrack_amanda nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pro
to_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntra
ck_netbios_ns nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp ip_set_portmap
ip_set_macipmap ip_set_ipmap ip_set_iphash ip_set xt_tcpmss xt_pkttype xt_physd
ev xt_NFQUEUE xt_NFLOG xt_multiport xt_MARK xt_mark xt_mac xt_limit xt_length xt
_helper xt_hashlimit ip6_tables xt_DSCP xt_dscp xt_dccp xt_conntrack xt_CONNMARK
xt_connmark xt_CLASSIFY xt_tcpudp xt_state iptable_nat nf_nat nf_conntrack_ipv4
nf_conntrack iptable_mangle nfnetl
nk fglrx(P) iptable_filter ip_tables x_tables fuse af_packet snd_seq_dummy snd_s
eq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6
binfmt_misc loop dm_mod floppy cpufreq_ondemand cpufreq_conservative cpufreq_pow
ersave powernow_k8 freq_table arc4 ecb blkcipher rt2400pci rt2x00pci rt2x00lib r
fkill input_polldev crc_itu_t mac80211 cfg80211 eeprom_93cx6 parport_pc parport
rtc_cmos pcspkr k8temp snd_intel8x0 snd_ac97_codec shpchp pci_hotplug ac97_bus s
nd_pcm snd_timer snd ide_cd soundcore forcedeth snd_page_alloc fan i2c_nforce2 t
hermal processor i2c_core button evdev sg ide_disk amd74xx ide_core sata_nv liba
ta sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd usbcore
Pid: 5948, comm: X Tainted: P 2.6.24.4-desktop-1mnb #1
RIP: 0010:[] [] :fglrx:ulReadMmRegisterUlon
gViaAddr+0×9/0×10
RSP: 0018:ffff81003815bd90 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff81003c5d2800 RCX: 0000000000000007
RDX: 000000000000003e RSI: 000000000000003e RDI: ffffc20000960000
RBP: ffffc20000960000 R08: 00000000381a7000 R09: 00000000000000d0
R10: 0000000000000000 R11: ffffffff8040bcb0 R12: 000000000000003e
R13: 000000004038646a R14: ffff8100341b89c0 R15: ffffffff884dfb68
FS: 00002ac562435730(0000) GS:ffffffff8059a000(0000) knlGS:00000000f71466d0
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffc200009600f8 CR3: 000000003ac36000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process X (pid: 5948, threadinfo ffff81003815a000, task ffff81003c938000)
Stack: ffffffff88373fa9 00000000e9010000 ffffffff8022744e ffff81003c5d2970
0000000010000000 ffff81003c5d2800 ffffffff883610a9 ffff81003c5d2800
ffff81003c5d2970 00007fff4a3cfab0 ffffffff8834dc49 ffffffff884dfb20
Call Trace:
[] :fglrx:ulReadMmRegisterUlong+0×69/0xf0
[] __ioremap+0xfe/0×140
[] :fglrx:WriteAsicConfigMemsize+0×109/0×150
[] :fglrx:CAILExit+0×19/0×180
[] :fglrx:firegl_cail_free+0×43/0×70
[] :fglrx:firegl_init_asic+0xf5/0x1e0
[] :fglrx:firegl_init_asic+0×0/0x1e0
[] :fglrx:firegl_ioctl+0x1b6/0×230
[] do_ioctl+0xa6/0xc0
[] vfs_ioctl+0×220/0x2c0
[] vfs_write+0x14e/0×190
[] sys_ioctl+0×91/0xb0
[] system_call+0x7e/0×83
Code: 8b 04 97 c3 66 66 90 48 85 ff 74 05 89 f1 89 14 8f c3 66 66
RIP [] :fglrx:ulReadMmRegisterUlongViaAddr+0×9/0×10
RSP
CR2: ffffc200009600f8
—[ end trace a2ec9d67584e80ec ]—
—[end of oops]—
"nie widzę czy pyta o wysłanie, oto treść raportu"
Pewnie wysyła automatycznie, jak ustawisz allow-submit = ask w /etc/kerneloops.conf wtedy wyskakuje okienko. Nie musisz uruchamiać kerneloops z opcją debug, wtedy pokazuje dużo informacji, między innymi znalezionego oopsa.
Błąd, który został znaleziony, nie będzie mógł być poprawiony przez deweloperów jądra, bo jest w zamkniętym sterowniku. Możliwe, że ludzie z AMD/ATI go wygrzebią na kooops dot org i poprawią.
ze tez sie tobie chciało tego szukac
dzieki od razu instaluję ten kerneloops
@optimizationkit
Tekst fajny, ale chciałby zostać upiększony. Jakieś pogrubienie (np. nazwy błędu), kursywa (ilość zgłoszeń), może kolorek? Cokolwiek, bo czyta się to kiepsko i wygląda jak jeden wielki, nieczytelny kloc tekstu. (: