bugreport

Beitrag von **lawww** » Dienstag 4. November 2003, 21:22

hi,

so, wie mir im irc nahegelgt wurde hier ein kleiner bugreport:

bei dem alexw-image vom 4.11.2003 (und den letzten snapshots) tritt bei mir das problem auf, dass die box beim zappen nach einer aufnahme (mit sofortaufnahme per menü getestet) abstürzt. mittlerweile habe ich aber rausbekommen, dass sich das verhindern lässt, indem ich nach dem beenden der aufnahme kurz das epg-auslesen aus und wieder ein schalte. danach ist auch zappen kein problem mehr. das ganze verhält sich so, egal ob ich in den aufnahmeeinstellungen sectionsd anhalten aktiviere oder nicht. wenn ich mich recht erinnere besteht das problem etwa seit der bh-mode-treiber im head aktiv ist, kann ich aber nicht beschwören. ein bootlog habe ich von der situation bereits hier: http://tuxbox-cvs.sourceforge.net/forum ... 5&start=20 gepostet, war mit dem snapshot vom 18.9., ist aber vom verhalten her identisch, denke also dass der kernel oops aktuell entsprechend ist (wenn ich das nächste mal ein ser. kabel an der box habe, verifiziere ich das aber auch gerne nochmal!).

also: meiner erfahrung nach dürfte ein quick and dirty workaround nach dem motto: nach der aufnahme sectionsd start (passiert sowieso schon), delay, sectionsd stop, delay, sectionsd start schon helfen. schöner wäre natürlich die sache am kern zu packen, vielleicht helfen meine infos dabei ja etwas weiter?!

wenn ihr noch infos oder einen tester braucht, bin ich jederzeit verfügbar, leider bin ich nicht fit genug, mehr zu tun - jedenfalls traue ich es mir im moment nicht zu, helfe aber gerne, soweit ich kann...

ich jedenfalls wäre super happy, wenn ihr auch diesen bug noch fixen würdet, ansonsten fallen mir nämlich keine mehr ein, mit denen ich hier zu kämpfen habe - wäre also dann ein traumimage, soweit sich das nach so kurzer zeit sagen lässt...

grüße

lawww

ps: sagem 1xi kabel, interne ucode, camalpha 1_2_5, avia600vb28

----edit----

kleiner nachtrag: das ganze passiert auch, wenn ich während ner aufnahme umschalte (im record mode). außerdem danke an "wer-auch-immer-den-thread-ins-richtige-forum-geschoben-hat"!

Beitrag von **lawww** » Donnerstag 6. November 2003, 19:55

so, wie versprochen, hier noch logs von den kernel oops mit tatsächlich dem alexw image vom 4.11.:

<?xml version="1.0" encoding="iso-8859-1"?>

<neutrino commandversion="1">
<record command="stop">
<channelname>unknown</channelname>
<epgtitle>not available</epgtitle>
<onidsid>0</onidsid>
<epgid>0</epgid>
<mode>1</mode>
<videopid>511</videopid>
<audiopids selected="512">
<audio pid="512" name="Stereo">
<audio pid="515" name="Dolby Digital 2.0 (AC3)">
</audiopids>
</record>
</neutrino>

avia_gt_dmx: client-- on queue 0 (mode 3)
[camd] refusing duplicate service
[camd] refusing duplicate service
[camd] refusing duplicate service
[camd] refusing duplicate service
[camd] refusing duplicate service
[camd] refusing duplicate service
[camd] refusing duplicate service
[camd] refusing duplicate service
[camd] refusing duplicate service
[camd] refusing duplicate service
login[120]: root login on `pts/1'

[dmx.cpp:read:184] read(fd, buf, n): Connection timed out
[camd] starting onid 0085 sid 000a
[basicsocket] send_data: Broken pipe
[camd] set emm caid 1702 capid 1000
descramble onid: 0085 sid: 000a status: 1d1d
avia_gt_dmx: client++ on queue 0 (mode 3)
avia_gt_dmx: client-- on queue 0 (mode 3)
[camd] starting onid 0085 sid 000b
Oops: kernel access of bad area, sig: 11
NIP: C3885E9C XER: 20000000 LR: C388371C SP: C179FDD0 REGS: c179fd20 TRAP: 0300
Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000000, DSISR: 0000014A
TASK = c179e000[90] 'zapit' Last syscall: 54
last math 00000000 last altivec 00000000
GPR00: 0000FFFF C179FDD0 C179E000 FFFFFE00 C3B6C0F8 20006F2A 7FFFFA48 C3884220
GPR08: 7FFFF9D8 000006FF 00000000 00000000 84002082 10034024 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00009032 0179FF40 C3884220 C0127580
GPR24: C194C220 00000001 00000000 7FFFFA48 C3B62C44 C3B62B38 C3B6C0F8 C3B62D0C
Call backtrace:
C3883548 C388371C C3884418 C388722C C3884578 C0041D98 C00025DC
0FDE8A54 10013BDC 10010674 1000D304 10010B24 1000E1F8 0FE52D18
0FE52DA8 10010FE8 0FCE47E0 00000000
[basicsocket] receive timed out.
[CBasicClient] receive failed: /tmp/sectionsd.sock
login[132]: root login on `pts/0'

[basicsocket] receive timed out.
[CBasicClient] receive failed: /tmp/sectionsd.sock
[basicsocket] receive timed out.
[CBasicClient] receive failed: /tmp/sectionsd.sock
[basicsocket] receive timed out.
[CBasicClient] receive failed: /tmp/sectionsd.sock

//////////////////////////////////////////////////////////////////////////////////////////////

[controld] VIDEO_EVENT_SIZE_CHANGED 704x576 (4:3 -> 16:9)
Record channel_id: 85000a epg: 85000a414a, apids mode 1
Send command: 1 channel_id: 85000a epgid: 85000a414a
connect to server: 192.168.2.2:4000
[CBasicClient] receive failed: /tmp/zapit.sock
sending to vcr-client:

<?xml version="1.0" encoding="iso-8859-1"?>

<neutrino commandversion="1">
<record command="record">
<channelname>PREMIERE 1</channelname>
<epgtitle>Blond</epgtitle>
<onidsid>8716298</onidsid>
<epgid>571231322442</epgid>
<mode>1</mode>
<videopid>511</videopid>
<audiopids selected="512">
<audio pid="512" name="Stereo">
<audio pid="515" name="Dolby Digital 2.0 (AC3)">
</audiopids>
</record>
</neutrino>

[CBasicClient] receive failed: /tmp/zapit.sock
[CBasicClient] receive failed: /tmp/zapit.sock
[CBasicClient] receive failed: /tmp/zapit.sock
avia_gt_dmx: client++ on queue 0 (mode 3)
login[113]: root login on `pts/0'

avia_gt_dmx: client-- on queue 0 (mode 3)
[camd] refusing duplicate service
Oops: kernel access of bad area, sig: 11
NIP: C3885E9C XER: 20000000 LR: C388371C SP: C18FDDD0 REGS: c18fdd20 TRAP: 0300
Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000000, DSISR: 0000014A
TASK = c18fc000[90] 'zapit' Last syscall: 54
last math 00000000 last altivec 00000000
GPR00: 0000FFFF C18FDDD0 C18FC000 FFFFFE00 C3B6B07C 20006F2A 7FFFFA48 C3884220
GPR08: 7FFFF9D8 000006FF 00000000 00000000 84002082 10034024 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00009032 018FDF40 C3884220 C0127890
GPR24: C1A49B20 00000001 00000000 7FFFFA48 C3B62C44 C3B62B38 C3B6B07C C3B62D0C
Call backtrace:
C3883548 C388371C C3884418 C388722C C3884578 C0041D98 C00025DC
0FDE8A54 10013BDC 10010674 1000D304 10010B24 1000E1F8 0FE52D18
0FE52DA8 10010FE8 0FCE47E0 00000000
[CBasicClient] connect failed.
/tmp/zapit.sock: Connection refused
[CBasicClient] connect failed.
/tmp/zapit.sock: Connection refused
[CBasicClient] connect failed.
/tmp/zapit.sock: Connection refused
Stop
[CBasicClient] connect failed.
/tmp/zapit.sock: Connection refused
login[128]: root login on `pts/1'

[basicsocket] receive timed out.
[CBasicClient] receive failed: /tmp/sectionsd.sock
[CBasicClient] connect failed.
/tmp/zapit.sock: Connection refused
Send command: 2 channel_id: 0 epgid: 0
connect to server: 192.168.2.2:4000
[CBasicClient] connect failed.
/tmp/zapit.sock: Connection refused
[CBasicClient] connect failed.
/tmp/zapit.sock: Connection refused
[CBasicClient] connect failed.
/tmp/zapit.sock: Connection refused
[CBasicClient] connect failed.
/tmp/zapit.sock: Connection refused

wie ihr seht, sind es zwei log-ausschnitte der abstürze. im prinzip wohl das gleiche, wie beim snap vom 18.9., allerdings last syscall 54 statt 4.

hoffe es hilft weiter,

grüße

lawww

Beitrag von **Homar** » Donnerstag 6. November 2003, 20:52

die Zapitabstürze treten auch ohne eine Aufnahme auf, sogar ziemlich oft auf SAT.

Auf einer Kabelbox ist das nicht bei mir nicht zu beobachten.

Auf SAT tritt das besonders häufig auf, wenn mann mit einer freigeschalteten camd auf ein anderes verschlüsselten Sender zapt. Danach ist ersteinmal die camd2 tot; einige male hin und herschalten und die Zapit auch.

Beitrag von **obi** » Freitag 7. November 2003, 06:14

meines erachtens darf zapit ruhig abstuerzen wenn der kernel unter seinem hintern wegstirbt...

Beitrag von **zexma** » Freitag 7. November 2003, 10:21

obi hat geschrieben:meines erachtens darf zapit ruhig abstuerzen wenn der kernel unter seinem hintern wegstirbt...

ROTFL

Beitrag von **torres** » Montag 10. November 2003, 11:55

Hallo,

ich kann den o.g. Fehler von lawww nur bestätigen. Auch wenn es ein Treiberproblem ist, vielleicht lässt sich ja doch ein Weg bewerkstelligen, der den Absturz verhindert, allerdings hilft bei mir der Tip mit EPG ein oder aus nicht.

1. Bei Aufnahmen über den Streamingserver mit Playback an klappt bei meiner Sagem1x-Kabel alles wunderbar.
Bei Aufnahmen mit Playback aus hingegen stürzt die Box bei der nächsten Aktion nach Ende der Aufnahme ab (umschalten etc., Ausschalten geht noch). Ist mir eigentlich nur wichtig für Aufnahmen von ARD, da hier nur mit Playback aus gute Ergebnisse rauskommen. Meine Idee ist, dass es mit dem record-mode zusammenhängt. Leider kann ich den ja nicht auf der Box verändern, oder ?

2. Bei Aufnahmen über JTG kommt dieses Problem aber nie vor. Auch bei Sofortaufnahmen mit sectionsd und playback aus, sowie record-mode ein stürzt die Box nicht ab.

Also muss jtg irgendwas anders machen, als die Box bei Aufnahmen über den Streamingserver ? Befehle in anderer Reihenfolge ? Irgendwo noch ein delay dazwischen ?

Hat jemand noch Erfahrungen damit ?

torres

Beitrag von **Sepp776** » Montag 10. November 2003, 12:37

Mit delays und anderer Reihenfolge habe ich schon alles Mögliche ausprobiert. Bringt alles keine Änderung

CU,
Sepp.

Hi,

sepp76 kannst du dich mal bitte mit ksymoops beschaeftigen und dann raussuchenw as genau crasht. habs schon ewig nimmer benutzt und moechte deshalb hier keine falsche anleitung geben.

Gruss woglinde

jo, werde ich mir mal angucken. Wurde das hier schon mal benutzt?

Beitrag von **lawww** » Dienstag 11. November 2003, 23:48

hm, falls euch das weiterhilft, ich habe auch schon mal den Inhalt von /lib/modules, /proc/ksyms und /proc/modules ausgelesen, allerdings recht "spät" nach dem oops, k.a. ob das noch aussagekräftig ist. zu einem direkten auslesen bin ich noch nicht gekommen, zeitmangel halt. aber wenns hilft, kann ich da gerne auch noch infos zu posten, sagt einfach, was ihr braucht. danke an dieser stelle an thegoodguy, der mich auf die "fehlenden" infos hingewiesen und mir erklärt hat, wie man da drankommt...

grüße

lawww

Hey lawww!
Vielleicht kannst du das ja dann machen mit dem ksymoops? Bei mir ist das was schlecht mit dem Log, weil Antennendose und Rechner so weit auseinander sind

Der Befehl muss glaube ich etwa so aussehen:

Code: Alles auswählen

ksymoops [oops-Datei] -v /tuxbox-cvs/cdk/linux-2.4.22/vmlinux -k [ksyms-Datei] -l [modules-Datei] -o /yadd/cdkroot/lib/modules/2.4.22-dbox2/ -m /yadd/cdkroot/boot/System.map-2.4.22-dbox2 -e

Kannste ja mal ausprobieren...

Ciao,
Sepp.

OT: Wie leite ich auf der Box die serielle Ausgabe in ne Datei um?

Beitrag von **obi** » Donnerstag 13. November 2003, 11:07

das ksymoops muss fuer ppc sein und deshalb auf der box ausgefuehrt werden.
man kann die version und binutils fuer ppc von debian woody (ppc!) benutzen.

Code: Alles auswählen

dmesg | ksymoops > /tmp/oops.txt 2>&1

oh weia. Das ist mir ne Nummer zu groß. Bin doch ein absoluter Linux-Dummy

Auf dem PC kann man bei ksymoops mit -e auf big-endian (oder little? Jedenfalls das andere

) umstellen und mit -a ne Architektur angeben. Reicht das nicht?

Schö,
Sepp.

Beitrag von **petgun** » Freitag 21. November 2003, 00:52

hi,
und auch im neuen Snapshot vom 20.11 ist der 'Fehler' noch enthalten...schade, da ich ARD-Sender nur ohne Playback artefaktfrei aufnehmen kann...also nur ueber JtG und nicht ueber den Streamserver.

cu,
peter