Fordítottam magamnek egy jó kis új 2.6.35.3-os kernelt, meg is lett az eredménye: nem megy a sdmount... illetve azóta már megy, kellett tenni bele egy kis várakozást, mivel a kernel már akkor indítja a /sbin/hotplug-ot, amikor a /sys/<százhuszonnyolcalkönyvtár>/block:sdxx fájlt (pontosabban szimlinket) még nem csinálta meg. Dehát ez kell, mondhatni ezzel teszteljük az éberségünket. Note: természetesen a HAL is felmountolja a ketyerét egy neki tetsző könyvtárba (/media/<volume>), akár azt is használhatnám...
Jól látom, hogy a 2.6.29.5-ös illetve 2.6.30-as kernelek egy olyan hibát javítanak, amely spontán felülírhatta a memóriát? Ez annyiban érdekes, hogy ezt a modult használja a gépem. Nem is működik jól...
pid doesn't count with some band having more bitrates than the one associated the first time. Fix that by counting the maximal available bitrate count and allocate big enough space.
Secondly, fix touching uninitialized memory which causes panics. Index sucked from this random memory points to the hell. The fix is to sort the rates on each band change.
De a gyári kernel mellett is feltűnő, mennyivel kevesebbet "eszik" a rendszerem. Szinte alig megy 200 MB fölé, de a 300 MB-ot sosem éri el, pedig az eggyel korábbi kernel 3-400 MB között "zabálta" a memóriát... (2 GB RAM van, nem akkora gáz... :-) )
Szeretem saját magam forgatni a kerneljeimet, pl. ezért. Az init 3 boot után a free parancsra kiadja
Zen "gyári" kernele 2.6.29.2 - used 137456
RW saját kernele 2.6.29.3 - used 48064
Azaz boot után 90 MB-vel kevesebb memóriát foglal a rendszer! Ehhez még az i486 vs p4 optimalizálás, meg néhány egyéb kernel tweak és nem marad kérdéses, miért a saját kernelt preferálom.
Érdekes, november 25. óta nem igazán működött a laptop-akksi kijelzője, vagyis kb. 10-15 perc után lenullázódott és csak reboot után működött megint, de ismét csak 10-15 percig. Minden olyan disztrónál így volt, melyik az akkoriban futó kernellel működött.
Tegnap a 2.6.29.2-re frissítettem a Zenwalk 6.0 snapshot-ot, azóta kifogástalanul működik a kijelzés...
Csak nekem tűnik úgy, hogy a stabilnak mondott Linux kernelek subminor verziói közötti changelog igen hosszú? Nem túl ijesztő ez? Már nem az, hogy kijavítják, janem az, hogy ilyen állapotban lát napvilágot egy-egy kernel release.
Egy érdekes problémával találtam szembe magamat, aminek nem bírok a végére érni. A tárgya egy USB-n keresztül elérhető nand... A kis drága szépen működik egy darabig, lehet rá írni, lehet róla olvasni, majd egyszer csak eltűnik a rendszerből. A kernel logban pedig az alábbi üzeneteket találom:
Apr 28 18:21:43 kernel: ehci_hcd 0000:00:0f.5: port 3 high speed Apr 28 18:21:43 kernel: ehci_hcd 0000:00:0f.5: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT Apr 28 18:21:43 kernel: usb 1-3: reset high speed USB device using ehci_hcd and address 3 Apr 28 18:21:48 kernel: usb 1-3: usb-storage timed out on ep0in len=0/64 Apr 28 18:21:53 kernel: usb 1-3: usb-storage timed out on ep0in len=0/64 Apr 28 18:21:58 kernel: usb 1-3: usb-storage timed out on ep0in len=0/64 Apr 28 18:21:58 kernel: ehci_hcd 0000:00:0f.5: port 3 high speed Apr 28 18:21:58 kernel: ehci_hcd 0000:00:0f.5: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT Apr 28 18:21:58 kernel: usb 1-3: device descriptor read/64, error -110 Apr 28 18:22:04 kernel: usb 1-3: usb-storage timed out on ep0in len=0/64 Apr 28 18:22:09 kernel: usb 1-3: usb-storage timed out on ep0in len=0/64 Apr 28 18:22:14 kernel: usb 1-3: usb-storage timed out on ep0in len=0/64 Apr 28 18:22:14 kernel: ehci_hcd 0000:00:0f.5: port 3 high speed Apr 28 18:22:14 kernel: ehci_hcd 0000:00:0f.5: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT Apr 28 18:22:14 kernel: usb 1-3: device descriptor read/64, error -110 Apr 28 18:22:14 kernel: ehci_hcd 0000:00:0f.5: port 3 high speed Apr 28 18:22:14 kernel: ehci_hcd 0000:00:0f.5: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT Apr 28 18:22:14 kernel: usb 1-3: reset high speed USB device using ehci_hcd and address 3 Apr 28 18:22:19 kernel: usb 1-3: usb-storage timed out on ep0in len=0/64 Apr 28 18:22:24 kernel: usb 1-3: usb-storage timed out on ep0in len=0/64 Apr 28 18:22:29 kernel: usb 1-3: usb-storage timed out on ep0in len=0/64 Apr 28 18:22:29 kernel: ehci_hcd 0000:00:0f.5: port 3 high speed Apr 28 18:22:29 kernel: ehci_hcd 0000:00:0f.5: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT Apr 28 18:22:29 kernel: usb 1-3: device descriptor read/64, error -110 Apr 28 18:22:34 kernel: usb 1-3: usb-storage timed out on ep0in len=0/64 Apr 28 18:22:39 kernel: usb 1-3: usb-storage timed out on ep0in len=0/64 Apr 28 18:22:44 kernel: usb 1-3: usb-storage timed out on ep0in len=0/64 Apr 28 18:22:44 kernel: ehci_hcd 0000:00:0f.5: port 3 high speed Apr 28 18:22:44 kernel: ehci_hcd 0000:00:0f.5: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT Apr 28 18:22:44 kernel: usb 1-3: device descriptor read/64, error -110 Apr 28 18:22:44 kernel: ehci_hcd 0000:00:0f.5: port 3 high speed Apr 28 18:22:44 kernel: ehci_hcd 0000:00:0f.5: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT Apr 28 18:22:45 kernel: usb 1-3: reset high speed USB device using ehci_hcd and address 3 Apr 28 18:22:50 kernel: usb 1-3: usb-storage timed out on ep0out len=0/0 Apr 28 18:22:55 kernel: usb 1-3: usb-storage timed out on ep0out len=0/0 Apr 28 18:22:55 kernel: usb 1-3: device not accepting address 3, error -110 Apr 28 18:22:55 kernel: ehci_hcd 0000:00:0f.5: port 3 high speed Apr 28 18:22:55 kernel: ehci_hcd 0000:00:0f.5: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT Apr 28 18:22:55 kernel: usb 1-3: reset high speed USB device using ehci_hcd and address 3 Apr 28 18:23:00 kernel: usb 1-3: usb-storage timed out on ep0out len=0/0 Apr 28 18:23:05 kernel: usb 1-3: usb-storage timed out on ep0out len=0/0 Apr 28 18:23:06 kernel: usb 1-3: device not accepting address 3, error -110 Apr 28 18:23:06 kernel: hub 1-0:1.0: logical disconnect on port 3 Apr 28 18:23:06 kernel: hub 1-0:1.0: state 7 ports 4 chg 0008 evt 0000 Apr 28 18:23:06 kernel: hub 1-0:1.0: port 3, status 0501, change 0000, 480 Mb/s Apr 28 18:23:06 kernel: usb 1-3: USB disconnect, address 3 Apr 28 18:23:06 kernel: sd 0:0:0:0: Device offlined - not ready after error recovery Apr 28 18:23:06 kernel: usb 1-3: unregistering device Apr 28 18:23:06 kernel: usb 1-3: usb_disable_device nuking all URBs Apr 28 18:23:06 kernel: usb 1-3: unregistering interface 1-3:1.0 Apr 28 18:23:06 kernel: usb 1-3:1.0: uevent Apr 28 18:23:06 kernel: usb 1-3: uevent Apr 28 18:23:06 kernel: ehci_hcd 0000:00:0f.5: port 3 high speed Apr 28 18:23:06 kernel: ehci_hcd 0000:00:0f.5: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT Apr 28 18:23:06 kernel: usb 1-3: new high speed USB device using ehci_hcd and address 4 Apr 28 18:23:11 kernel: usb 1-3: khubd timed out on ep0in len=0/64 Apr 28 18:23:16 kernel: usb 1-3: khubd timed out on ep0in len=0/64 Apr 28 18:23:21 kernel: usb 1-3: khubd timed out on ep0in len=0/64 Apr 28 18:23:21 kernel: ehci_hcd 0000:00:0f.5: port 3 high speed Apr 28 18:23:21 kernel: ehci_hcd 0000:00:0f.5: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT Apr 28 18:23:21 kernel: usb 1-3: device descriptor read/64, error -110 Apr 28 18:23:26 kernel: usb 1-3: khubd timed out on ep0in len=0/64 Apr 28 18:23:31 kernel: usb 1-3: khubd timed out on ep0in len=0/64 Apr 28 18:23:36 kernel: usb 1-3: khubd timed out on ep0in len=0/64
és innentől ez a ciklus pörög még párszor, persze sikertelen eredménnyel. Esetleg van valakinek valami ötlete, hogy mitől lehet, esetleg valaki találkozott már hasonló esettel? A gyógyszer a nand visszahozására a reboot :(
# lsusb Bus 002 Device 004: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC Bus 002 Device 002: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub Bus 002 Device 003: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 003: ID 090c:1000 Feiya Technology Corp. Memory Bar Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
lenne egy apro problemam a 2.6.0-test3-as kernellel. miszerint nem lehet vele titkositott particiokat hasznalni, amit en mar jo ideje hasznalok a 2.4-es sorozattal. eloszor meg orultem neki, hogy nem kell patch-elni a kernelt, milyen rendesek beletettek alapbol, de hiaba nem jo. letezik erre valami kezzelfoghato megoldas?
ezeket a modulokat toltom be elotte, hogy: serpent, loop, cryptoloop. manualisan pedig igy fuznem be: losetup -e serpent /dev/loop0 /dev/hda2. ezutan kelle kernie a kulcsmeretet majd a jelszot, de nem tesz semmi ilyet, holott a loop0-at hozzarenedi az eszkozhoz. ezek utan a mount mar ismeretle fajlrenszerre hivatkozik.
koszi elore is a segitseget.
Működik. :-) Azt hiszem, az volt a probléma, hogy be kell tölteni a snd-seq-oss modult. De ez a modul csak akkor jön létre, ha az egész sound card supportot modulként fordítom le.
Sziasztok! Hátha valaki kisujjából kirázza a választ. :-)
Azt szeretném elérni az ALSA segítségével, hogy az SB Live! hullámtáblájával tudjak MIDI-t lejátszani.
A kernelem 2.6.0-test1 + ac2 patch, a disztrib Gentoo, van devfs, a hangkártya SB Live! 5.1. Korábban modulokat csináltam, most éppen mindent belefordítottam a kernelbe az egyszerűség kedvéért:
Minden OSS programom, ami eddig ment, működik most is, mert azok a /dev/dsp-t használják. (MIDI-t timidity-vel játszottam le, az is megy.)
A pmidi -l a következőket írja:
Port Client name Port name 64:0 Rawmidi 0 - EMU10K1 MPU-401 (U EMU10K1 MPU-401 (UART) 65:0 Emu10k1 WaveTable Emu10k1 Port 0 65:1 Emu10k1 WaveTable Emu10k1 Port 1 65:2 Emu10k1 WaveTable Emu10k1 Port 2 65:3 Emu10k1 WaveTable Emu10k1 Port 3
A pmidi -p 65:0 (igaz, a 64:0 is) úgy csinál, mintha játszaná a megadott midi állományt, de hang az nincs. Gondoltam, azért, mert fel kell tölteni a soundfontot.
nfl@snoopy SFBANK $ sfxload 8MBGMSFX.SF2
/dev/sequencer: No such device or address
nfl@snoopy SFBANK $ cat /dev/sequencer
cat: /dev/sequencer: Nincs ilyen eszköz vagy cím
nfl@snoopy SFBANK $ ls -l /dev/sequencer
lr-xr-xr-x 1 root root 15 2003-07-20 13:31 /dev/sequencer -> sound/sequencer
nfl@snoopy SFBANK $ ls -l /dev/sound/sequencer
crw------- 1 nfl audio 14, 1 1970-01-01 01:00 /dev/sound/sequencer
Szóval nem lehet megnyitni a /dev/sequencer-t. Amikor ezt próbálom, akkor ezt kapom a kernel logba:
Jul 20 12:19:27 [kernel] ALSA sound/core/seq/oss/seq_oss_init.c:221: can't create port
Érdekes lehet még a /proc/asound/oss/sndstat tartalma:
Sound Driver:3.8.1a-980706 (ALSA v0.9.4 emulation code)
Kernel: Linux snoopy 2.6.0-test1-ac1 #5 v júl 20 02:01:47 CEST 2003 i686
Config options: 0
Installed drivers:
Type 10: ALSA emulation
Card config:
Sound Blaster Live! (rev.7) at 0xa400, irq 9
Audio devices:
0: EMU10K1 (DUPLEX)
Synth devices:
0: Emu10k1
Midi devices:
0: EMU10K1 MPU-401 (UART)
Timers:
7: system timer
Mixers:
0: SigmaTel STAC9708/11
Lehet, hogy a Midi devices-nél nem az MPU-401-nek kéne állnia? Hogy tudom azt átállítani a hullámtáblára?
Az ALSA-val kapcsolatban is van egy irinyo-pirinyo apró változás: nem hoz létre device-okat a /proc/asound/dev-ben, azokat a /dev/snd-ben valahogy létre kell hozni. Esetemben a valahogy azt jelentette, hogy letöltöttem az ALSA-0.9.4-et, és abban levő snddevices-t futtattam.
Na igen, a config file sok mindenben változott. Pl. anno elég nagy szívások voltak abból, hogy sok embernek nem ment a billentyűzet. Merthogy a PS/2 keyboard support opcionális része lett a kernelnek (gondolom az egyre terjedő USB eszközök miatt).
Az IPX pedig elbújt az "ANSI/IEE802.2 - aka LLC (IPX, AppleTalk, TokenRing)" mögé a konfigban... pedig szerintem az IPX-hez nem kell feltétlenül 802.2, megy az Ethernet vagy 802.3 fölött is... na mindegy, fő hogy megvan...
Nekem a modulok kezelese okozott problémát, az ftp.kernel.org/pub/linux/kernel/people/rusty/modules könyvtárból kell venni a legfrissebb module-init-tools -t, de arra is ugyelni, hogy a regi insmod,lsmod,rmmod,... is megmaradjon .old neven...
Én a 2.5.42 -től használom ezt kernelt, voltak jobb rosszabb napjai,de egyébként használható. Nagyon gyors , főleg az input kezelés egér, bill.,egyetlen gondja, hogy a konzolok és az X közötti váltásba néha belehal. Mivel én mindig X-et használok multi gnome terminállal, ezért ritkán fagy. Érdemes alá XFS-t rakni filerendszernek, és akkor nem kell félned, hogy elveszik valami adatod. Én lassan fél éve használok 2.5.xx kernelt Debian Sid, a munkahelyemen, tehát napi 8 óra munka, és viszonylag stabil, már amennyire a Sid-től elvárható.
Mert nekem pl. nem 0 problámam van: a Matrox G450 DH kártyám driverei nem igazán akarnak lefordulni.
Igaz, én utóljára kb. egy hónapja próbáltam, de a HUP-on olvastam, hogy most sem megy. Le lehet tölteni patch-et innen, de én még nem próbáltam. Ha valaki esetleg igen, az megoszthatná velem a tapasztalatait...
Azért nyitottam ezt a topicot, mert erősen közeleg a 2.6-os Linux kernel kiadásának a dátuma. Itt meg lehet beszélni, hogy kinek milyen baja/gondja, esetleg nagy öröme van a topicnyitás pillánatában 2.5.70-es (és Linus szerint hamarosan pre-2.6-os) verziószámot viselő Linux-szal.
