djmount auf Spark

[MPC823]

Nachdem ich es geschaft hatte das Packet djmount zu bauen hänge ich bei eine Fehlermeldung beim Installieren.

djmount hängt von fuse ab. Fuse habe ich auch gebaut. Beim installieren aber wird angemeckert das er fuse.ko nicht findet. Nun Frage ich mich wie den das sein kann das fuse zwar erfolgreich gebaut wird (laut konsolenausgabe) aber das modul fehlt.

Downloading file://opkg/fuse-2.8.5-1.opk.
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for fuse:
* fuse.ko *
* opkg_install_cmd: Cannot install package fuse.
spark:~ #

Martin

[seife]

bei spark ist die dependency falsch, denn da ist das im Kernel einkompiliert.
=> installiere mit irgendeiner --force option, warte, bis es jemand fixt oder schicke einen patch.

Edit: na gut, wenn's sonst keiner fixt, dann mach ichs halt selbst .
Probier aber bitte, ob es auf der Tripledragon noch geht.
In /var/lib/opkg/info/fuse.control muss "Depends: fuse.ko" drinstehen (auf der TD). Das habe ich jetzt auf die Schnelle nicht geprüft.

[MPC823]

Danke Stefan

In principal gehts nun auf der GM990 aber ab und an fault Neutrino ab siehe :

device probe found 2 display pipelines
copLoadFile (file /boot/audio.elf)
ustslave: Kernel Version: 24
base_address 0x40400000
seeking to 0
seeking to 400
seeking to 5c18
seeking to b058
seeking to ff08
seeking to 136f0
seeking to 15008
seeking to 15018
seeking to 3bcc0
seeking to 3dfb8
seeking to 46558
seeking to 48a58
seeking to 71e68
seeking to 75fe8
seeking to 77878
seeking to 77c88
seeking to 90ef0
seeking to a16c0
seeking to 139f28
seeking to 139ff0
seeking to 13b6b0
seeking to 13ed70
seeking to 1427b0
seeking to 145408
seeking to 14b3c8
seeking to 159f58
seeking to 177b78
seeking to 17a378
seeking to 184460
seeking to 18c9a8
seeking to 221208
seeking to 26e400
seeking to 26e438
seeking to 26e470
seeking to 275820
seeking to 275828
seeking to 275830
seeking to 275840
seeking to 2955c0
copLoadFile (file /boot/video.elf)
ustslave: Kernel Version: 24
base_address 0x40000000
seeking to 0
seeking to 57a40
seeking to 120378
seeking to 1203b0
seeking to 1203e8
seeking to 12f230
seeking to 12f23c
seeking to 12f248
seeking to 1510c0
seeking to 14f0ac
seeking to 151100
starting /etc/init.d/S56load-fuse ...
modprobe: module fuse not found in modules.dep
starting /opt/pkg/etc/init.d/S80djmount ...
Mount options = iocharset=utf-8
Charset : successfully initialised charset='utf-8'
Jan 1 00:00:25 spark daemon.info init: starting pid 925, tty '': '/etc/init.d/start'

Please press Enter to activate this console.
HDMI detected: y
NEUTRINO_DEFAULT_SCART: no

[neutrino] frameBuffer Instance created
libstb-hal debug options can be set by exporting HAL_DEBUG.
The following values (or bitwise OR combinations) are valid:
component: audio 0x01
component: video 0x02
component: demux 0x04
component: play 0x08
component: power 0x10
component: init 0x20
component: ca 0x40
component: record 0x80
all components: 0xff
[LT:00000000:init ] init_td_api begin, initialized=0, debug=0x00
[LT:00000000:init ] LIRC/IRMP input converter thread starting...
[LT:00000000:init ] LIRC/IRMP input thread: symlink /dev/input/nevis_ir to event1
[LT:00000000:init ] LIRC/IRMP input converter going into main loop...
[LT:00000000:init ] init_td_api end
FB: 720x576x32 line length 2880.
8192k video mem
[neutrino] FB: cannot open /dev/bpamem0: No such file or directory
[neutrino start] 1650 -> 0 ms
[LT:00000000:init ] init_td_api begin, initialized=1, debug=0x00
[LT:00000000:init ] init_td_api end
[neutrino start] 1654 -> 0 ms
***************************** rec dir /mnt/dune/spark timeshift dir /mnt/dune/spark/.timeshift
[neutrino start] 1659 -> 42 ms
[neutrino start] 1674 -> 198 ms
[neutrino] settings font file /share/fonts/neutrino.ttf
[neutrino] font family Arial Narrow
[neutrino start] 1677 -> 266 ms
[neutrino start] 1679 -> 266 ms
[neutrino start] 1681 -> 266 ms
[neutrino start] 1683 -> 267 ms
Segmentation fault
Neutrino exited with exit code 139

Martin

[seife]

Falscher Thread, das hat mit djmount nichts zu tun.

Schau mal, ob bei dir das bpamem Modul geladen ist und das device da ist (siehe die Fehlermeldung, sicher hast du das Log das du gepostet hast auch vorher angeschaut?)
Wenn du danach neutrino von Hand nochmal startest, geht es dann?

[MPC823]

Nun seit ich djmount installiert habe schmiert das ab von daher der Zusamenhang von mir angedacht.

Vorher stabil nun eben nicht mehr. Und ja ich kann Neutrino von hand starten.


Martin

P.S ab und an bekomme ich auch im Log diesen Fehler :

seeking to 14f0ac
seeking to 151100
starting /etc/init.d/S56load-fuse ...
modprobe: module fuse not found in modules.dep
starting /opt/pkg/etc/init.d/S80djmount ...
Mount options = iocharset=utf-8
Charset : successfully initialised charset='utf-8'
Jan 1 00:00:24 spark daemon.info init: starting pid 920, tty '': '/etc/init.d/start'

Please press Enter to activate this console. Jan 1 00:00:25 spark daemon.info init: starting pid 926, tty '': '-/bin/sh'
spark:/ #
HDMI detected: y

[MPC823]

Nun da das System vorher stabil war und nun mal der Fehler da ist und ab und an bootet liegt ein Zusammenhang den ich aber nicht erkennen kann nahe. das Einzige was ich installierte war djmount.

Nun habe ich ein 3 sek sleep vor dem starten von Neutrino eingefügt und nun tritt der Fehler nicht mehr auf (bisher) was auf ein timing Problem schliessen lässt.


Martin

[seife]

Ok, dann ist der djmount nur der Trigger aber nicht der Grund.

Ich vermute, wir brauchen ein "udevadm settle" equivalent für mdev -- etwas das wartet, bis mdev mit allen seinen dingern durch ist.
Ein ähnliches Problem hatte ich beim lirc - da hatte ich erst uinput im lirc initskript geladen, aber das hat dann relativ lange gedauert bis das device da war und deswegen hat lircd kein input-device anlegen können. Deswegen habe ich uinput in die loadmodules gelegt... der "warte aufs device"-Code ist im lirc init-skript noch drin.

Evtl. müsste man sowas noch für alle wichtigen devices in ein letztes initskript einbauen, das auf "alles wichtige" wartet. Evtl. in /proc/<pid>/fd schauen, welche devices neutrino öffnet und auf alle warten. Freiwillige vor

[doc]

Da der Sparkkernel nicht ganz aus so ferner Vorzeit ist (wie bei anderen Boxen) könnte ich mich mal wieder an einem echten udev probieren.

Ach ja Martin, ohne debuggen ist so was immer Rätselraten und man liegt eigentlich mit seiner Vermutung immer falsch. Installiere mal den GDB auf der Box und führe dann einen Backtrace aus. Allerdings müssen dann Debugsymbole in den Anwendungen sein.
Mini Tutorial GDB
https://wiki.ubuntu.com/Backtrace

[seife]

Der segfault liegt daran, dass das bpamem device nicht da ist. Da muss man nichts debuggen mmap auf filedescriptor -1 ist keine Gute Idee[tm]

Udev würde ich gerne vermeiden, insbesondere weil das dann wieder anders als auf der TD ist. Wobei -- das ist es sowieso, die TD hat ja noch devfs.
Aber trotzdem, ich halte udev für overkill. Mal schauen, was sich bei mdev noch optimieren lässt.

[MPC823]

warum kann man die Abfrage nicht direkt isn Neutrino einbauen da man ja weiss das es das bestimmte device geben muss. Also vor dem Öffnen abfragen ob es da ist und wenn es nicht da ist warten.

Martin

[doc]

Na wenn Du das sofort siehst das es an dem Device bpamem liegt .. o.k. Natürlich sollte ein Zugriff aus so ein Device möglich sein, nur prüfen muss man schon ob es überhaupt da ist.

Hinter den Syntax von mdev bin ich noch nicht wirklich gestiegen, und aus Experimentierfreude hatte ich mich mit dem UDev beschäftigt. Sollte keine besondere Schwierigkeit sein das testweise in eine Sparkumgebung zu bekommen. Dann kann man das vergleichen.

[seife]

Vermutlich liegt das daran, dass per mdev.seq die events sequenziell abgearbeitet werden.
Das will man aber nicht abschalten, weil sonst das mounten nicht funktioniert.
Deswegen habe ich jetzt ein init-skript eingebaut, was einfach auf die devices wartet.Dauert typischerweise etwas über anderthalb Sekunden:

Code: Alles auswählen

starting /etc/init.d/S99devwait ...
waiting for mandatory devices to show up
waiting for device /dev/dvb/adapter0/demux0.. ok
waiting for device /dev/dvb/adapter0/video0. ok
waiting for device /dev/bpamem... ok
...had to wait 1680ms for devices to show up

Keine Ahnung warum das früher nie gestört hat. Mit djmount scheint es nicht wirklich zusammenzuhängen, aber vielleicht macht das die 10 zusätzlichen Milisekunden, die es zum Krachen bringen.

[Striper]

Ein simples sync nach dem mdev Aufruft reicht vermutlich genauso.

[seife]

nein. Weil zu der Zeit gibt es noch nichts zu schreiben und sync kommt sofort zurück (ein tmpfs sync'ed sehr schnell
Es ist einfach so, dass einige mdev-Regeln länger dauern (USB-Storage mounten z.B.) und alle anderen dahinter in der Queue liegen bleiben. Deswegen dauert es dann insgesamt ein paar Sekunden, bis alle devices da sind.
Bei udev gibt es dasselbe Problem und deswegen "udevadm settle".
Natürlich ist mdev auch nicht übertrieben effizient implementiert (bei udev wird über netlink messages ein neues event erzeugt, mdev wird einfach für jedes event gestartet), aber für den Anwendungszweck ist es ok.
Irgendwann schaue ich mir mal an, wie ich die 1,5 Sekunden von der Bootzeit noch wegbekomme, aber das hat momentan niedrige Priorität.