Blog Marcina Bojko

Linux,Windows,serwer, i tak dalej ;)

Walk ciąg dalszy.

Niestety, po 12 godzinach kernel wpadł w sidła błędu ksoftirqd – zajeżdzając pierwszy CPU prawie do 100%.  Rekompilacja kernela z wyłączeniem opcji kernel software interrupt ani ze zmianą częstotliwości zegara na 100Hz nic nie dała – procek zapchany, wszystko wykonuje się w dziwnie wolnym trybie.

Pozostaje jeszcze zabawa z samym vmwaretool – rekompilacja i zapychanie do kernela w trakcie.

Może ktoś ma jakieś pomysły?

Update 1: czwartek, 09:34

Z niewiadomych przyczyn ksoftirqd przestał zabijać jeden z procesorów, utylizacja spadła do 10 %.  Niestety, kernel 2.6.28.10 oraz cała rodzina 2.6.29.x ma jakieś problemy z kolejką esfq, co wyklucza je na razie z zastosowań produkcyjnych. Klasyczny impas 😉

Update 2 czwartek 16:43

Przygotowanie kernela 2.6.29.1 z łatą na esfq/imq/layer7/conntrack i paroma innymi rzeczami (reiserfs4), iptables 1.4.1.iproute powiodło się w końcu. Rzutem na taśmę pomocny okazał sie pakiet xtables-addons w wersji prehistorycznej (od 1.08 w górę iptables 1.4.1 nie jest obsługiwane).

Kernel skompilowany, paczki przesyłają się na wirtualkę testową. Na produkcyjną to chyba ze dwie doby później, jak poświateczny szał opadnie 😉

Update 3 czwartek 23:09

Walka z iptables zakończona, maszyna wydaje się chodzić stabilnie. 12 godzin testów co najmniej 😉

Update 4 piątek 9:30

Przeniesienie ruchu na maszynę z kernelem 2.6.29.1 od razu powoduje uaktywnienie ksoftirqd na 100%.

Written by marcinbojko

Czerwiec 9, 2009 @ 20:26

Napisane w Uncategorized

%d bloggers like this: