Przejdź do treści forum
eko.one.pl
OpenWrt, Linux, USB, notebooki i inne ciekawe rzeczy
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Opcje wyszukiwania (Strona 2 z 4)
W CC miałem cały nand dla siebie ~120MB. W wersji trunk jest pozostawiony oryginalny podział mtd i mam około 23MB na root. A to trochę mało. Nie mam żadnego pożytku z oryginalnego softu a ostatnia partycja mtd - syscfg ma 74MB. Fajnie byłoby wykorzystać to jako extroot. Da się zrobić extroot z ubi?
Dodam jeszcze, że scrub sobie nie radzi:
Viper>> nand scrub 0x00f00000 0x80000
NAND scrub: device 0 offset 0xf00000, size 0x80000
Warning: scrub option will erase all factory set bad blocks!
There is no reliable way to recover them.
Use this command only for testing purposes if you
are sure of what you are doing!
Really scrub this NAND flash? <y/N>
NAND 128MB 3,3V 8-bit: MTD Erase failure: -5
Erasing at 0xf60000 -- 100% complete.
OK
Próby z write.e pokazywały błędy w dalszych obszarach pamięci. Robiłem więc scrub na tych obszarach i w końcu:
write.e zrobił tak:
Viper>> nand write.e 0x2000000 0x200000 0x1500000
NAND write: device 0 offset 0x200000, size 0x1500000
Bad block at 0xf00000 in erase block from 0xf00000 will be skipped
Writing data at 0x171f800 -- 100% complete.
22020096 bytes written: OK
I wstał! Trunk też się zainstalował bez problemu. Teraz się zastanawiam, czy mogę jakoś przetestować cały nand?
Wyciachałem, a jakże
Udało się bootloader odzyskać przez kwboot z http://www.wolfteck.com/projects/candyh … 2593096526
I teraz jestem w tym samym punkcie:
Viper>> setenv ipaddr 192.168.1.1
Viper>> setenv serverip 192.168.1.2
Viper>> tftpboot 0x2000000 FW_EA4500_2.1.41.164606.img
Using egiga0 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.1
Filename 'FW_EA4500_2.1.41.164606.img'.
Load address: 0x2000000
Loading: #################################################################
[...]
############################################################
done
Bytes transferred = 21603876 (149a624 hex)
Viper>> nand erase 0x200000 0x1500000
NAND erase: device 0 offset 0x200000, size 0x1500000
Skipping bad block at 0x00f00000
Erasing at 0x16e0000 -- 100% complete.
OK
Viper>> nand write 0x2000000 0x200000 0x1500000
NAND write: device 0 offset 0x200000, size 0x1500000
Failed write verify, nand offset 0x00f00000. Suggest to erase block and repeat write operation!
If problem persists suggest marking block as bad (nand markbad <offset>) and repeating the operation!
13631488 bytes written: ERROR
Viper>> nand bad
Device 0 bad blocks:
00f00000
02300000
Czy skoro mam bad blok na 00f00000 to powinienem coś zmienić w parametrach nand erase/write ('wydłużyć')?
Czy mogę spróbować załadować obraz openwrt trunk bezpośrednio z bootloadera? Czy wszystkie parametry nand erase/nand write byłyby takie same?
Więc chyba przesadziłem, że z nand było wszystko OK. Próba przywrócenia softu oryginalnego:
Viper>> nand erase 0x200000 0x1500000
NAND erase: device 0 offset 0x200000, size 0x1500000
Skipping bad block at 0x00f00000
Erasing at 0x16e0000 -- 100% complete.
OK
Viper>> nand write 0x2000000 0x200000 0x1500000
NAND write: device 0 offset 0x200000, size 0x1500000
Failed write verify, nand offset 0x00f00000. Suggest to erase block and repeat write operation!
If problem persists suggest marking block as bad (nand markbad <offset>) and repeating the operation!
13631488 bytes written: ERROR
Viper>> nand markbad 0x00f00000
block 0x00f00000 successfully marked as bad
Viper>> nand write 0x2000000 0x200000 0x1500000
NAND write: device 0 offset 0x200000, size 0x1500000
Failed write verify, nand offset 0x00f00000. Suggest to erase block and repeat write operation!
If problem persists suggest marking block as bad (nand markbad <offset>) and repeating the operation!
13631488 bytes written: ERROR
Po resetenv i reset router wstał niby na oryginalnym sofcie ale w konsoli było trochę błędów o nieodnalezionych programach i nawet DHCP nie działał. Spróbowałem więc ponownie po serialu, tym razem zgodnie z komunikatami powyżej robiłem nand markbad...ale dalej nand write pokazywał błędy. Próbowałem więc z nand scrub i offsetami i coś zepsułem bo po restarcie na konsoli już sie nic nie pokazuje. Pewnie nand do wymiany? 
Cezary napisał/a:Bo sysupgrade w CC nie działa bo go nie było dla tej platformy.
A gdybym sysupgrade z trunka sobie wkopiowal. Zadziałało by?
Candyhouse był tylko przez chwilę. Od roku mam CC r45856 z którego nie można bezpośrednio przejść na trunk (podobno).
Router działa już prawie rok i nic złego się nie dzieje, więc pewnie można te błędy nand zignorować.
Działa tak dobrze, że aż nudno
Korci mnie więc żeby spróbować nowe obrazy z trunka ale jak rozumiem musiałbym najpierw przez serial przejść na oryginał...
Mogę śmiało powiedzieć, że wyłączenie TSO pomogło.
Łatka wyłączająca TSO na kirkwoodzie już dodana do trunka:
http://git.openwrt.org/?p=openwrt.git;a … d68cc95e5c
Sugerując się: https://bugs.debian.org/cgi-bin/bugrepo … bug=764162
zrobiłem:
ethtool -K eth0 tso off
ethtool -K eth1 tso off
I wygląda na to, że jest OK!
Będę testował dalej...ale dobrze to nie świadczy o platformie/kernelu 
Nie, w logach cisza.
marek napisał/a:Nie mam żadnych błędów (dmesg) ani na EA4500 ani laptopie.
Poza tym na EA4500 działa od paru dni nzbget - a więc par2, unrar - wszystko pięknie mieli - pliki po kilka GB. Działa też yate, które non-stop generuje pare procent obciążenia CPU (to normalne). To samo do tej pory robił WDR3600.
Zupełnie nie rozumiem jak plik kopiowany po TCP (NFS) może się w drodze 'zepsuć'. To nie może być problem sieci, co?
ifconfig
br-lan Link encap:Ethernet HWaddr 94:10:3E:A0:F2:4F
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fd28:acf8:d565::1/60 Scope:Global
inet6 addr: fe80::9610:3eff:fea0:f24f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4535353 errors:0 dropped:0 overruns:0 frame:0
TX packets:4170645 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:514504221 (490.6 MiB) TX bytes:15012056679 (13.9 GiB)
eth0 Link encap:Ethernet HWaddr 94:10:3E:A0:F2:4F
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4157966 errors:0 dropped:0 overruns:0 frame:0
TX packets:4000193 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:564803009 (538.6 MiB) TX bytes:940140500 (896.5 MiB)
Interrupt:83
eth1 Link encap:Ethernet HWaddr 94:10:3E:A0:F2:50
inet addr:192.168.100.236 Bcast:192.168.100.255 Mask:255.255.255.0
inet6 addr: fe80::9610:3eff:fea0:f250/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1572345 errors:0 dropped:0 overruns:0 frame:0
TX packets:965281 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1817782848 (1.6 GiB) TX bytes:61878836 (59.0 MiB)
Interrupt:84
eth2 Link encap:Ethernet HWaddr 58:2C:80:13:92:63
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::5a2c:80ff:fe13:9263/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1515608 errors:0 dropped:0 overruns:0 frame:0
TX packets:1059187 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1540439916 (1.4 GiB) TX bytes:136782149 (130.4 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1254 errors:0 dropped:0 overruns:0 frame:0
TX packets:1254 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:111693 (109.0 KiB) TX bytes:111693 (109.0 KiB)
wlan0 Link encap:Ethernet HWaddr 94:10:3E:A0:F2:51
inet6 addr: fe80::9610:3eff:fea0:f251/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:419736 errors:0 dropped:0 overruns:0 frame:0
TX packets:792252 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:32895388 (31.3 MiB) TX bytes:1203354538 (1.1 GiB)
No to może w końcu ciekawy problem mam - pliki kopiowane z dysku USB ulegają tajemniczej 'korupcji'.
EA4500 ('mój' openwrt/trunk z poprawkami wolfteck'a) ma podłączony hub aktywny i huawei e3272(hilink) oraz dysk 2TB USB2. Oprócz tego drugi 'internet' dostarczony po ethernet i mwan3.
Pozostałe komputery w sieci to laptop (arch linux) i raspberry PI 2 (openelec).
Pierwszy zauważony symptom: błędy przy odtwarzaniu plików mkv na raspberry.
Nie działa (md5sum się nie zgadza):
- kopiowanie pliku z USB po ethernet / NFS (testowane opcje sync/async, tcp/udp itp)
- kopiowanie pliku z USB po ethernet / samba
Działa (md5sum OK):
- kopiowanie pliku z USB po ethernet / SCP
- kopiowanie pliku z USB po wifi / NFS
- ściąganie dużych plików (obrazy iso) z internetu po ethernet i wifi
- wielokrotnie sprawdzałem md5sum dużych plików na dysku USB na samym ea4500 - zawsze OK
Wykluczam problem z laptopem bo problem ma też malinka.
Wykluczam problem z NFS bo problem jest też z sambą.
Wykluczam problem z dyskiem USB bo na samym ea4500 md5sum zawsze jest ok.
Nie mam żadnych błędów (dmesg) ani na EA4500 ani laptopie.
Ten sam osprzęt/połączenia/software działał bez zarzutu do tej pory z WDR3600.
Podsumowanie - pliki transferowane z pamięci USB przez LAN i NFS lub SAMBA ulegają korupcji. To samo po SCP jest OK. Co za licho?
Czy jest np iperf ze sprawdzaniem sum kontrolnych czy coś podobnego? RAM/CPU burn test na openwrt?
Jade dalej i natnkąłem się na problem z mwan3. Przy starcie mwan3 dostaję komunikaty:
RTNETLINK answers: Address family not supported by protocol
Dotarłem do tego, że nie działa 'ip route... table xyz' - mój kernel ma wyłączoną opcję w target/linux/kirkwood/config-3.18
# CONFIG_IP_ADVANCED_ROUTER is not set
To chyba nie jest tylko problem obrazów z wolfteck.com. Czy na Twoich obrazach Cezary działa mwan3 działa bez problemów?
Ok, dzięki. Mogłem przeczytać ze zrozumieniem sekcję "Flash Layout" http://wiki.openwrt.org/toh/linksys/ea4500
Kolejna sprawa.... Zainstalowałem pakiet block-mount. Za każdym razem gdy odpalę 'block info' dostaje w logach:
Sat May 23 18:20:07 2015 kern.err kernel: [20303.534179] __nand_correct_data: uncorrectable ECC error
Sat May 23 18:20:07 2015 kern.err kernel: [20303.539572] __nand_correct_data: uncorrectable ECC error
Sat May 23 18:20:07 2015 kern.err kernel: [20303.544913] blk_update_request: I/O error, dev mtdblock0, sector 0
Sat May 23 18:20:07 2015 kern.err kernel: [20303.551224] __nand_correct_data: uncorrectable ECC error
Sat May 23 18:20:07 2015 kern.err kernel: [20303.556555] __nand_correct_data: uncorrectable ECC error
Sat May 23 18:20:07 2015 kern.err kernel: [20303.561914] blk_update_request: I/O error, dev mtdblock0, sector 8
Sat May 23 18:20:07 2015 kern.err kernel: [20303.568195] __nand_correct_data: uncorrectable ECC error
Sat May 23 18:20:07 2015 kern.err kernel: [20303.573540] __nand_correct_data: uncorrectable ECC error
Sat May 23 18:20:07 2015 kern.err kernel: [20303.578873] blk_update_request: I/O error, dev mtdblock0, sector 16
Sat May 23 18:20:07 2015 kern.err kernel: [20303.585255] __nand_correct_data: uncorrectable ECC error
Sat May 23 18:20:07 2015 kern.err kernel: [20303.590599] __nand_correct_data: uncorrectable ECC error
Sat May 23 18:20:07 2015 kern.err kernel: [20303.595937] blk_update_request: I/O error, dev mtdblock0, sector 24
Sat May 23 18:20:07 2015 kern.err kernel: [20303.602760] __nand_correct_data: uncorrectable ECC error
Sat May 23 18:20:07 2015 kern.err kernel: [20303.608099] __nand_correct_data: uncorrectable ECC error
Sat May 23 18:20:07 2015 kern.err kernel: [20303.613467] blk_update_request: I/O error, dev mtdblock0, sector 0
Sat May 23 18:20:07 2015 kern.err kernel: [20303.619673] Buffer I/O error on dev mtdblock0, logical block 0, async page read
Nawet ktoś zgłaszał: https://dev.openwrt.org/ticket/18612 Ale nie wygląda by było jakieś rozwiązanie.
Bać się? Czy wywalić block-mount i już?
Cezary napisał/a:Tam jest ubifs więc sobie odinstaluj co zbędne.
To jasne, ale przy instalacji oficjalnej przez serial rozumiem, że miałbym więcej do dyspozycji niż tylko 17,5M dla rootfs?
W końcu mam EA4500 w łapkach. Zainstalowałem własny obraz SSA na podstawie https://github.com/cilynx/Candyhouse-Linux/
Wszstko fajnie ale troche mało miejsca na rootfs. Po instalacji wszystkiego co potrzebuję - "df -h":
Filesystem Size Used Available Use% Mounted on
rootfs 17.5M 15.5M 1.9M 89% /
ubi0:rootfs 17.5M 15.5M 1.9M 89% /
tmpfs 61.1M 80.0K 61.1M 0% /tmp
tmpfs 512.0K 0 512.0K 0% /dev
Rozumiem, że 'oficjalna' metoda zajmuje cały NAND i miałbym więcej miejsca?
Widzę, że jest już nieinwazyjna metoda instalacji openwrt:
http://www.wolfteck.com/projects/candyhouse/openwrt/
A jak wygląda proces upgrade'u gdy już mamy openwrt? Czyli czy można wgrać obrazy Cezarego bez konsoli szeregowej?
Sukces! 
upmpdcli i mpd (specjalnie przycięty - curl, alsa output,flac,ogg,mp3) zmieściły się bez extroota.
Kompilacja libupnpp i upmpdcli na podstawie https://code.google.com/p/raspberrypi-openwrt.package/.
Moje pliki Makefile dla libupnpp i upmpdcli niestety są w fatalnym stanie (musiałem jakieś rzeczy ręcznie kopiować do staging-dir) ale pewnie ktoś wprawny by łatwo poprawił...
Podsumowując zestaw:
1. Program sterujący - bubbleupnp na tablecie android (jest wiele alternatyw, do wyboru, do koloru)
2. Biblioteka mp3 (10K plików) serwowana przez minidlna na 'dużym' openwrt z extroot i usb hdd
3. w jednym pomieszczeniu EZCast (renkcast) podłączony przez hdmi do amplitunera
4. w drugim pomieszczeniu openwrt bez extroota z kartą audio usb, mpd, upmpdcli
(upmpdcli może nawet być zainstalowany na innym serwerze - byleby widział mpd.)
Różnica między DMR a DMP tzn czy mamy 'push' czy 'pull' jest jak mam nadzieję dla mnie nieistotna 
Tak, WDR3600 jest DMS (minidlna). EZCast jest DMP/DMR...w każdym razie odtwarza.
BubbleUPnP na tablecie na androidzie 'zawiaduje' tym wszystkim (DMC).
Potrzebny jest DMR (DMP) na openwrt dla "małego".
Znalazłem dwa możliwe rozwiązania:
1. Upmpdcli http://www.lesbonscomptes.com/upmpdcli/upmpdcli.html - steruje "po prostu" mpd.
2. GMediaRender http://gmrender.nongnu.org/ - wymaga gstreamera
Upmpdcli ma szansę być mniejszy chyba... Spróbuję skompilować i dam znać. Dzięki za cierpliwość! 
Tak, problem b)
Sorry, nie wyraźiłem się jasno....
Protokół - DLNA - narzuca mi EZCast - tylko w ten sposób współdziała z 'open source'. Airplay/raop w EZCast jest jakoś dziwnie zaimplementowany i forked-daapd ani inne np pulseaudio-raop2 nie działają.
Serwerem mediów jest 'duży' openwrt z extrootem (tu mam teraz minidlna, ale mogę zainstalować dowonly inny serwer).
EZCast jest jednym 'odbiornikiem' (DLNA renderer), w pomieszczeniu z amplitunerem - bo jest potrzebny hdmi.
Drugim odbiornikiem audio ma być 'mały' openwrt (najlepiej bez extroot) z kartą usb w drugim pomieszczeniu.
I problem: jakie oprogramowanie mogę zainstalować na openwrt, które działałoby jako DLNA renderer (tylko audio oczywiście)?
Szukam programu dla openwrt który działałby jako DLNA renderer dla plików dźwiękowych.
Wiem, mamy forked-daapd i shairplay - ale to dla Airplay/raop. Mamy MPD który może wysyłać do pulseaudio a pulseaudio może łączyć się z innymi serwerami pulse w sieci... i to nawet działa mi nieźle...
Ale wzbogaciłem się o urządzenie 'EZCast' niedawno i jedyny sposób żeby wykorzystać je do odtwarzania muzyki to DLNA (AirPlay w EZCast jest 'skopane' i działa tylko z oficjalnym serwerem iTunes - forked-daapd nie działa - to osobny problem, który próbuję rozwiązać z deweloperem forked-daapd).
EZCast całkiem ładnie działa jako odbiornik/renderer DLNA. Minidlna na 'dużym' ruterku (WDR3600) nawet daje radę z moją kolekcją muzyki (ok. 10tyś plików). Teraz chciałbym odtwarzać muzykę serwowaną przez minidlna także na drugim, małym ruterku z openwrt (bez extroot) i kartą audio usb.
Upieram się by używać EZCast bo to najtańsze rozwiązanie (50zł) dające przez wifi cyfrowy sygnał do mojego amplitunera po hdmi.
Podobny problem mogą mieć użytkownicy 'airmusic'. Tam jak rozumiem też jest 'odbiornik' Airplay i DLNA. Jeśli ktoś chciałby mieć w domu tylko DLNA to fajnie byłoby móc odtwarzać muzykę po DLNA na openwrt z kartą USB audio.
Teoretycznie sprawa niezbyt skomplikowana - istnieje wiele implementacji DLNA...wystrarczy tylko podpiąć do jakiegoś odtwarzacza i dalej alsa lub pulse is alsa.
Może ktoś ma pomysł czego mógłbym użyć? Może rygel?
Po kilku próbach poszedłem na całość - skompilowałem najnowszy na bazie trunka ffmpeg 2.4.2 (zamiast 2.3.4). Teraz działa.
Oczywiście masz rację Cezary...przepraszam, że zaśmiecam forum... Tak sobie tylko pomyślałem, że może ktoś używa trunka i wie co się tam teraz zmienia albo ma jakiś pomysł jak do tego problemu podejść. Fajnie by było znaleźć przyczynę.
Ciekawe, że gdb zgłasza SIGSEGV a valgrind SIGILL (unrecognized instruction).
Postanowiłem sprawdzić co słychać w trunku - jest nowy ffmpeg i forked-daapd... Poinstalowałem na WDR3600 i wygląda na to, że ffmpeg nie bardzo gotowy - sypie "segmentation fault".
Dalej postanowiłem eksperymentować przez qemu i malta - to samo. Nie chce mi się wierzyć żeby wypuścili ffmpeg który nie działa na ar71xx/MIPS. Przecież to chyba najbardziej popularna platforma openwrt. Bardziej prawdopodobne, że coś pominąłem... 
root@OpenWrt:/# gdb --args /usr/bin/ffmpeg -i music.mp3 test.mp3
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mipsel-openwrt-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/ffmpeg...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/ffmpeg -i music.mp3 test.mp3
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
ffmpeg version 2.3.4 Copyright (c) 2000-2014 the FFmpeg developers
built on Oct 27 2014 10:27:16 with gcc 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r43076)
configuration: --enable-cross-compile --cross-prefix=mipsel-openwrt-linux-uclibc- --arch=mipsel --target-os=linux --prefix=/usr --pkg-config=pkg-config --enable-shared --enable-static --enable-small --enable-pthreads --enable-zlib --disable-runtime-cpudetect --disable-doc --disable-debug --enable-gpl --enable-version3 --disable-altivec --disable-amd3dnow --disable-amd3dnowext --disable-mmx --disable-mmxext --disable-sse --disable-sse2 --disable-sse3 --disable-ssse3 --disable-sse4 --disable-sse42 --disable-avx --disable-xop --disable-fma3 --disable-fma4 --disable-avx2 --disable-vfp --disable-neon --disable-inline-asm --disable-yasm --disable-mipsdspr1 --disable-mipsdspr2 --disable-mipsfpu --disable-dxva2 --disable-vaapi --disable-vda --disable-vdpau --disable-outdevs --disable-mips32r2
libavutil 52. 92.100 / 52. 92.100
libavcodec 55. 69.100 / 55. 69.100
libavformat 55. 48.100 / 55. 48.100
libavdevice 55. 13.102 / 55. 13.102
libavfilter 4. 11.100 / 4. 11.100
libswscale 2. 6.100 / 2. 6.100
libswresample 0. 19.100 / 0. 19.100
libpostproc 52. 3.100 / 52. 3.100
warning: GDB can't find the start of the function at 0x77534752.
GDB is unable to find the start of the function at 0x77534752
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0x77534752 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
Program received signal SIGSEGV, Segmentation fault.
0x77534752 in ?? ()
(gdb) info shared
From To Syms Read Shared Object Library
Yes (*) /lib/ld-uClibc.so.0
No /usr/bin/ffmpeg
No /usr/lib/libavdevice.so.55
No /usr/lib/libavfilter.so.4
No /usr/lib/libavformat.so.55
No /usr/lib/libavcodec.so.55
No /usr/lib/libpostproc.so.52
No /usr/lib/libswresample.so.0
No /usr/lib/libswscale.so.2
No /usr/lib/libavutil.so.52
No /lib/libm.so.0
No /lib/libgcc_s.so.1
No /lib/libpthread.so.0
No /lib/libc.so.0
No /usr/lib/libasound.so.2
No /usr/lib/libbz2.so.1.0
No /usr/lib/libz.so.1
No /lib/libdl.so.0
No /lib/librt.so.0
(*): Shared library is missing debugging information.
(gdb)
root@OpenWrt:/# cat valgrind.log
==2784== Memcheck, a memory error detector
==2784== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==2784== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==2784== Command: ffmpeg -i /music.mp3 out.mp3
==2784== Parent PID: 1499
==2784==
--2784--
--2784-- Valgrind options:
--2784-- -v
--2784-- --tool=memcheck
--2784-- --leak-check=full
--2784-- --log-file=valgrind.log
--2784-- Contents of /proc/version:
--2784-- Linux version 3.10.58 (buildbot@debian-amd64) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r43076) ) #2 SMP Mon Oct 27 20:05:18 UTC 2014
--2784-- Arch and hwcaps: MIPS32, LittleEndian, MIPS-baseline
--2784-- Page sizes: currently 4096, max supported 4096
--2784-- Valgrind library directory: /usr/lib/valgrind
--2784-- Scheduler: using generic scheduler lock implementation.
--2784-- Reading suppressions file: /usr/lib/valgrind/default.supp
==2784== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-2784-by-???-on-???
==2784== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-2784-by-???-on-???
==2784== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-2784-by-???-on-???
==2784==
==2784== TO CONTROL THIS PROCESS USING vgdb (which you probably
==2784== don't want to do, unless you know exactly what you're doing,
==2784== or are doing some strange experiment):
==2784== /usr/lib/valgrind/../../bin/vgdb --pid=2784 ...command...
==2784==
==2784== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==2784== /path/to/gdb ffmpeg
==2784== and then give GDB the following command
==2784== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=2784
==2784== --pid is optional if only one valgrind process is running
==2784==
vex mips->IR: unhandled instruction bytes: 0xF0 0x4 0x6A 0x72
==2784== valgrind: Unrecognised instruction at address 0x404b51.
==2784== at 0x404B51: ??? (in /usr/bin/ffmpeg)
==2784== by 0x56F2EB4: ??? (in /lib/libuClibc-0.9.33.2.so)
==2784== Your program just tried to execute an instruction that Valgrind
==2786== i.e. it's Valgrind's fault. If you think this is the case or
==2786== you are not sure, please let us know and we'll try to fix it.
==2786== Either way, Valgrind will now raise a SIGILL signal which will
==2786== probably kill your program.
==2786==
==2786== Process terminating with default action of signal 4 (SIGILL)
==2786== Illegal opcode at address 0x404B51
==2786== at 0x404B51: ??? (in /usr/bin/ffmpeg)
==2786== by 0x56F2EB4: ??? (in /lib/libuClibc-0.9.33.2.so)
==2786==
==2786== HEAP SUMMARY:
==2786== in use at exit: 0 bytes in 0 blocks
==2786== in use at exit: 0 bytes in 0 blocks
==2786== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2786==
==2786== All heap blocks were freed -- no leaks are possible
==2786==
==2786== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)
--2786--
--2786-- used_suppression: 1 ld(Addr4) /usr/lib/valgrind/default.supp:14
==2786==
==2786== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)
Śmiało! Przerobiłem swojego E3272 z Playa na HiLink. Użyłem wersji: 153_22.470.07.00.00 i webui 13.100.10.00.03.
Modem współpracuje z WDR3600 i BB. Jestem bardzo zadowolony.
Chyba to kwestia sprzetu/firmware... Znalazłem ciekawą dyskusję: https://www.mail-archive.com/linux-usb@ … 39446.html
Coś o różnych trybach komunikacji...16/32bit. Może po prostu mój modem chce bufory 16K i już. No trudno...
Znalezione posty: 26 do 50 z 97