sectionsd aktualisiert Kanalliste

Das Original Benutzerinterface Neutrino-SD incl. zapit, sectionsd, yWeb etc...
Homar
Senior Member
Beiträge: 1278
Registriert: Mittwoch 5. September 2001, 00:00

Beitrag von Homar »

vielleicht liegt der Fehler ja ganz woanders,
touch /var/etc/.neutrino
rm /var/etc/.bootinfo

habe vorhin jtg installiert und siehe da, der legt ja eine Zwangspause ein, nachdem er lcd.o geladen hat
JtG-Riker
Image-Team
Beiträge: 1015
Registriert: Freitag 7. Februar 2003, 18:37

Beitrag von JtG-Riker »

Homar hat geschrieben:vielleicht liegt der Fehler ja ganz woanders,
touch /var/etc/.neutrino
rm /var/etc/.bootinfo

habe vorhin jtg installiert und siehe da, der legt ja eine Zwangspause ein, nachdem er lcd.o geladen hat
Das ist die Image-Info - meine Tests waren alle mit abgeschalteter Image-Info, touch /var/etc/.neutrino hat keine Funktion da das nicht abgefragt wird, trotzdem ist die Bootzeit bei mir 1:47 - die lange Wartezeit kommt beim aufruf von zapit, wie schon geschrieben mit dem Image vom 20.10 geht es ja noch.

Riker
mb405
Tuxboxer
Tuxboxer
Beiträge: 2331
Registriert: Donnerstag 24. März 2005, 21:52

Beitrag von mb405 »

also, ich kann Nirvana da zustimmen. habe 4 sats und bootzeit ist 1:15-1:35 (aus-ein).
JTG-Riker hast du die aktuelle zapit.cpp // sectionsd.cpp drin?
Innuendo
Einsteiger
Einsteiger
Beiträge: 281
Registriert: Mittwoch 8. Dezember 2004, 21:45

Beitrag von Innuendo »

nachdem ich nun heut morgen meinen cvs-stand aktualisiert habe, bekomme ich beim zappen unregelmäßig folgendes im log:
[controld] VIDEO_EVENT_SIZE_CHANGED 720x576 (4:3 -> 4:3)
[LCDFONT] FTC_Face_Requester (Fix12/Regular)
PES, queue 0 normal.
[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
[basicsocket] receive timed out.
[CBasicClient] receive failed: /tmp/sectionsd.sock
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
PES, queue 0 normal.
PES, queue 0 normal.
PES, queue 0 normal.
PES, queue 0 normal.
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process gb
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process timerd
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
anschließend hilft nur noch ein reset

innu
Nirvana
Erleuchteter
Erleuchteter
Beiträge: 646
Registriert: Mittwoch 16. April 2003, 14:12

Beitrag von Nirvana »

Kleiner Tipp:

Wenn ihr bei der Bugsuche behilflich sein wollt und den sectionsd testen wollt:
- Loggt euch per telnet auf der Box ein.
- killall sectionsd
- /bin/sectionsd -d

Dann sieht man zumindest ein wenig mehr, was passiert.
Innuendo
Einsteiger
Einsteiger
Beiträge: 281
Registriert: Mittwoch 8. Dezember 2004, 21:45

Beitrag von Innuendo »

Nirvana hat geschrieben:/bin/sectionsd -d
ok
die ersten gehversuche waren prima - currentservices.xml erstellt, nach reboot war sie ordentlich verarbeitet - bootzeit bei mir identisch mit ein/aus/ein ohne info (+- ein paar sekündchen)

innu
PauleFoul
Wissender
Wissender
Beiträge: 1839
Registriert: Sonntag 17. August 2003, 01:39

Beitrag von PauleFoul »

Nirvana hat geschrieben:Kleiner Tipp:

Wenn ihr bei der Bugsuche behilflich sein wollt und den sectionsd testen wollt:
- Loggt euch per telnet auf der Box ein.
- killall sectionsd
- /bin/sectionsd -d

Dann sieht man zumindest ein wenig mehr, was passiert.
Wird gemacht und gemeldet...
PauleFoul
Wissender
Wissender
Beiträge: 1839
Registriert: Sonntag 17. August 2003, 01:39

Beitrag von PauleFoul »

Code: Alles auswählen

Service Typ: 2
Bouquet ID: 4160
Bouquet Name: ARD Digital
Original Network ID: 1
Transport Stream ID: 1101
Service ID: 28125
Service Typ: 2
Bouquet ID: 4160
Bouquet Name: ARD Digital
Original Network ID: 1
Transport Stream ID: 1101
Service ID: 28126
Service Typ: 2
Bouquet ID: 4160
Bouquet Name: ARD Digital
Original Network ID: 1
Transport Stream ID: 1101
Service ID: 28127
Service Typ: 2
Bouquet ID: 4160
Bouquet Name: ARD Digital
Original Network ID: 1
Transport Stream ID: 1101
Service ID: 28128
Service Typ: 2
Bouquet ID: 4160
Bouquet Name: ARD Digital
Original Network ID: 1
Transport Stream ID: 1201
Service ID: 28305
Service Typ: 1
Bouquet ID: 4160
Bouquet Name: ARD Digital
Original Network ID: 1
Transport Stream ID: 1201
Service ID: 28306
Service Typ: 1
Bouquet ID: 4160
Bouquet Name: ARD Digital
Original Network ID: 1
Transport Stream ID: 1201
Service ID: 28307
Service Typ: 1
Bouquet ID: 4160
Bouquet Name: ARD Digital
Original Network ID: 1
Transport Stream ID: 1201
Service ID: 28308
Service Typ: 1
Bouquet ID: 4160
Bouquet Name: ARD Digital
Original Network ID: 1
Transport Stream ID: 1201
Service ID: 28309
Service Typ: 1
Bouquet ID: 4160
Bouquet Name: ARD Digital
Original Network ID: 1
Transport Stream ID: 1201
Service ID: 28310
Service Typ: 1
Bouquet ID: 4160
Bouquet Name: ARD Digital
Original Network ID: 1
Transport Stream ID: 1201
Service ID: 28311
Service Typ: 1
Bouquet ID: 4160
Bouquet Name: ARD Digital
Original Network ID: 1
Transport Stream ID: 1201
Service ID: 28312
Service Typ: 1
[sdtThread] added 115 services to bouquet (end)
[sdtThread] BAT with ID: 0x1040 complete
dmxSDT: no new data for 5 seconds
dmxSDT: going to sleep...
Connection from UDS
version: 5, cmd: 24, numbytes: 1
data length: 16
Starting command 24
[sectionsd] commandserviceChanged: Service changed to     2716f001025d
--> '[sectionsd] commandserviceChanged: before messaging lock' 30235.003000
[sectionsd] commandserviceChanged: current service-descriptor not loaded yet!
--> '[sectionsd] commandserviceChanged: before wakeup' 1.355000
--> 'changeDMX: before pthread_mutex_lock(&start_stop_mutex)' 0.634000
--> 'changeDMX: after pthread_mutex_lock(&start_stop_mutex)' 0.652000
dmxEIT: waking up again - requested from .change()
--> 'changeDMX: before pthread_mutex_lock(&start_stop_mutex)' 4.200000
--> 'changeDMX: after pthread_mutex_lock(&start_stop_mutex)' 0.813000
--> '[sectionsd] commandserviceChanged: after doWakeup' 1.346000
dmxNIT: waking up again - requested from .change()
dmxNIT: backing off 20 seconds...
dmxNIT: going to sleep...
Connection from UDS
version: 5, cmd: 16, numbytes: 1
data length: 8
Starting command 16
[sectionsd] Request of current/next information for     2716f001025d
Connection from UDS
version: 5, cmd: 16, numbytes: 1
data length: 8
Starting command 16
[sectionsd] Request of current/next information for     2716f001025d
Connection from UDS
version: 5, cmd: 24, numbytes: 1
data length: 16
Starting command 24
[sectionsd] commandserviceChanged: Service changed to     2716f001025d
--> '[sectionsd] commandserviceChanged: before messaging lock' 127.158000
--> '[sectionsd] commandserviceChanged: before wakeup' 0.722000
[sectionsd] commandserviceChanged: ignoring wakeup request...
--> '[sectionsd] commandserviceChanged: after doWakeup' 0.937000
Connection from UDS
version: 5, cmd: 16, numbytes: 1
data length: 8
Starting command 16
[sectionsd] Request of current/next information for     2716f001025d
Connection from UDS
version: 5, cmd: 29, numbytes: 1
data length: 2
Starting command 29
dmx.read timeout - filter: 4e - timeout# 0[eitThread] skipping to next filter(
 (> TIME_EIT_SKIPPING)
--> 'changeDMX: before pthread_mutex_lock(&start_stop_mutex)' 372.110000
--> 'changeDMX: after pthread_mutex_lock(&start_stop_mutex)' 0.683000
changeDMX [12]-> scheduled (0x50)
--> 'after DMX_SET_FILTER' 7.057000
dmx.read timeout - filter: 50 - timeout# 1dmx.read timeout - filter: 50 - time
t# 2[eitThread] dmxEIT restarted, cache NOT decreased (dt=59)
dmx.read timeout - filter: 50 - timeout# 0Connection from UDS
version: 5, cmd: 16, numbytes: 1
data length: 8
Starting command 16
[sectionsd] Request of current/next information for     2716f001025d
dmx.read timeout - filter: 50 - timeout# 1dmx.read timeout - filter: 50 - time
t# 2[eitThread] dmxEIT restarted
dmx.read timeout - filter: 50 - timeout# 0Connection from UDS
version: 5, cmd: 16, numbytes: 1
data length: 8
Starting command 16
[sectionsd] Request of current/next information for     2716f001025d
dmx.read timeout - filter: 50 - timeout# 1dmx.read timeout - filter: 50 - time
t# 2[eitThread] dmxEIT restarted
dmx.read timeout - filter: 50 - timeout# 0dmx.read timeout - filter: 50 - time
t# 1Connection from UDS
version: 5, cmd: 16, numbytes: 1
data length: 8
Starting command 16
[sectionsd] Request of current/next information for     2716f001025d
dmx.read timeout - filter: 50 - timeout# 2[eitThread] dmxEIT restarted
dmx.read timeout - filter: 50 - timeout# 0dmx.read timeout - filter: 50 - time
t# 1dmx.read timeout - filter: 50 - timeout# 2[eitThread] dmxEIT restarted
dmx.read timeout - filter: 50 - timeout# 0dmx.read timeout - filter: 50 - time
t# 1dmx.read timeout - filter: 50 - timeout# 2[eitThread] dmxEIT restarted
dmx.read timeout - filter: 50 - timeout# 0dmx.read timeout - filter: 50 - time
t# 1dmx.read timeout - filter: 50 - timeout# 2[eitThread] dmxEIT restarted
dmx.read timeout - filter: 50 - timeout# 0dmx.read timeout - filter: 50 - time
t# 1dmx.read timeout - filter: 50 - timeout# 2[eitThread] dmxEIT restarted
Connection from UDS
version: 5, cmd: 16, numbytes: 1
data length: 8
Starting command 16
[sectionsd] Request of current/next information for     2716f001025d
dmx.read timeout - filter: 50 - timeout# 0dmx.read timeout - filter: 50 - time
t# 1dmx.read timeout - filter: 50 - timeout# 2[eitThread] dmxEIT restarted
dmx.read timeout - filter: 50 - timeout# 0dmx.read timeout - filter: 50 - time
t# 1dmx.read timeout - filter: 50 - timeout# 2[eitThread] dmxEIT restarted
dmx.read timeout - filter: 50 - timeout# 0dmx.read timeout - filter: 50 - time
t# 1dmx.read timeout - filter: 50 - timeout# 2[eitThread] dmxEIT restarted
dmx.read timeout - filter: 50 - timeout# 0dmx.read timeout - filter: 50 - time
t# 1dmx.read timeout - filter: 50 - timeout# 2[eitThread] dmxEIT restarted
dmx.read timeout - filter: 50 - timeout# 0dmx.read timeout - filter: 50 - time
t# 1dmx.read timeout - filter: 50 - timeout# 2[eitThread] dmxEIT restarted
dmxNIT: waking up again - looking for new transponders :)
--> 'changeDMX: before pthread_mutex_lock(&start_stop_mutex)' 19540.639000
--> 'changeDMX: after pthread_mutex_lock(&start_stop_mutex)' 0.869000
changeDMX [10]-> current/next (0x40)
--> 'after DMX_SET_FILTER' 2.231000
dmx.read timeout - filter: 50 - timeout# 0dmx.read timeout - filter: 50 - time
t# 1[nitThread] adding transponders [table 0x40] (begin)
[nitThread] added 13 transponders (end)
dmx.read timeout - filter: 50 - timeout# 2[eitThread] dmxEIT restarted
[nitThread] adding transponders [table 0x40] (begin)
[nitThread] added 23 transponders (end)
dmx.read timeout - filter: 50 - timeout# 0dmx.read timeout - filter: 50 - time
t# 1dmx.read timeout - filter: 50 - timeout# 2[eitThread] dmxEIT restarted
dmx.read timeout - filter: 50 - timeout# 0dmx.read timeout - filter: 50 - time
t# 1dmx.read timeout - filter: 50 - timeout# 2[eitThread] dmxEIT restarted
dmx.read timeout - filter: 50 - timeout# 0dmx.read timeout - filter: 50 - time
t# 1dmx.read timeout - filter: 50 - timeout# 2[eitThread] dmxEIT restarted
dmx.read timeout - filter: 50 - timeout# 0dmx.read timeout - filter: 50 - time
t# 1dmxNIT: no new data for 5 seconds
--> 'changeDMX: before pthread_mutex_lock(&start_stop_mutex)' 7027.067000
--> 'changeDMX: after pthread_mutex_lock(&start_stop_mutex)' 0.785000
dmxSDT: waking up again - requested from .change()
dmxNIT: going to sleep...
dmx.read timeout - filter: 50 - timeout# 2[eitThread] dmxEIT restarted
[sdtThread] adding services [table 0x46] (begin)
[sdtThread] added 31 services (end)
[sdtThread] Other SDT with ID: 0x850002 complete
dmx.read timeout - filter: 50 - timeout# 0[sdtThread] adding services [table 0
2] (begin)
[sdtThread] added 10 services (end)
[sdtThread] Actual SDT complete for ONID: 0xf001 TSID: 0x2716
--> 'changeDMX: before pthread_mutex_lock(&start_stop_mutex)' 1150.159000
dmx.read timeout - filter: 50 - timeout# 1--> 'changeDMX: after pthread_mutex_
ck(&start_stop_mutex)' 321.641000
changeDMX [12]-> current/next (0x4e)
--> 'after DMX_SET_FILTER' 9.647000
[eitThread] timeoutsDMX for 0x2716f001025d reset to 0 (not broadcast)
New Filterindex: 1 (ges. 2)
--> 'changeDMX: before pthread_mutex_lock(&start_stop_mutex)' 2.820000
--> 'changeDMX: after pthread_mutex_lock(&start_stop_mutex)' 0.641000
changeDMX [12]-> scheduled (0x50)
--> 'after DMX_SET_FILTER' 7.417000
[sdtThread] adding services [table 0x46] (begin)
[sdtThread] added 14 services (end)
[sdtThread] Other SDT with ID: 0x850004 complete
dmx.read timeout - filter: 50 - timeout# 0[sdtThread] adding services [table 0
6] (begin)
[sdtThread] added 28 services (end)
[sdtThread] Other SDT with ID: 0x850001 complete
[sdtThread] adding services [table 0x46] (begin)
[sdtThread] added 10 services (end)
[sdtThread] Other SDT with ID: 0x10437 complete
dmx.read timeout - filter: 50 - timeout# 1[eitThread] timeoutsDMX for 0x2716f0
025d reset to 0 (not broadcast)
New Filterindex: 2 (ges. 2)
--> 'changeDMX: before pthread_mutex_lock(&start_stop_mutex)' 1018.478000
--> 'changeDMX: after pthread_mutex_lock(&start_stop_mutex)' 0.709000
changeDMX [12]-> scheduled (0xf)
--> 'after DMX_SET_FILTER' 7.282000
[sdtThread] adding services [table 0x46] (begin)
[sdtThread] added 17 services (end)
[sdtThread] Other SDT with ID: 0xf0010070 complete
dmx.read timeout - filter: f - timeout# 0[sdtThread] adding services [table 0x
] (begin)
[sdtThread] added 26 services (end)
[sdtThread] Other SDT with ID: 0x10431 complete
dmx.read timeout - filter: f - timeout# 1dontchange 1
[sdtThread] adding services [table 0x46] (begin)
[sdtThread] added 13 services (end)
[sdtThread] Other SDT with ID: 0xf0012711 complete
dmx.read timeout - filter: f - timeout# 2dontchange 1
[eitThread] dmxEIT restarted
[sdtThread] adding services [table 0x46] (begin)
[sdtThread] added 18 services (end)
[sdtThread] Other SDT with ID: 0x1044d complete
dmx.read timeout - filter: f - timeout# 0[sdtThread] adding services [table 0x
] (begin)
[sdtThread] added 14 services (end)
[sdtThread] Other SDT with ID: 0xf0012714 complete
dmx.read timeout - filter: f - timeout# 1dontchange 1
[sdtThread] adding services [table 0x46] (begin)
[sdtThread] added 14 services (end)
[sdtThread] Other SDT with ID: 0xf0012715 complete
dmx.read timeout - filter: f - timeout# 2dontchange 1
[eitThread] dmxEIT restarted
[sdtThread] adding services [table 0x46] (begin)
[sdtThread] added 7 services (end)
[sdtThread] Other SDT with ID: 0xf00100fe complete
[sdtThread] adding services [table 0x46] (begin)
[sdtThread] added 8 services (end)
[sdtThread] Other SDT with ID: 0xf00100ff complete
dmx.read timeout - filter: f - timeout# 0dmx.read timeout - filter: f - timeou
 1dontchange 1
[sdtThread] adding services [table 0x46] (begin)
[sdtThread] added 16 services (end)
[sdtThread] Other SDT with ID: 0xf00100fa complete
dmx.read timeout - filter: f - timeout# 2dontchange 1
[eitThread] dmxEIT restarted
[sdtThread] adding services [table 0x46] (begin)
[sdtThread] added 16 services (end)
[sdtThread] Other SDT with ID: 0xf00100fb complete
dmx.read timeout - filter: f - timeout# 0[sdtThread] adding services [table 0x
] (begin)
[sdtThread] added 17 services (end)
[sdtThread] Other SDT with ID: 0xf00100fc complete
dmx.read timeout - filter: f - timeout# 1dontchange 1
[sdtThread] adding services [table 0x46] (begin)
[sdtThread] added 15 services (end)
[sdtThread] Other SDT with ID: 0xf00100fd complete
dmx.read timeout - filter: f - timeout# 2dontchange 1
[eitThread] dmxEIT restarted
[sdtThread] adding services [table 0x46] (begin)
[sdtThread] added 15 services (end)
[sdtThread] Other SDT with ID: 0xf0012712 complete
dmx.read timeout - filter: f - timeout# 0[sdtThread] adding services [table 0x
] (begin)
[sdtThread] added 17 services (end)
[sdtThread] Other SDT with ID: 0x850011 complete
[sdtThread] adding services [table 0x46] (begin)
dmx.read timeout - filter: f - timeout# 1Connection from UDS
version: 5, cmd: 24, numbytes: 1
data length: 16
Starting command 24
[sectionsd] commandserviceChanged: Service changed to      43700016d66
--> '[sectionsd] commandserviceChanged: before messaging lock' 19049.353000

Code: Alles auswählen

SPTS, queue 0 extended.

SPTS, queue 0 extended.

[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
[basicsocket] receive timed out.
[CBasicClient] receive failed: /tmp/sectionsd.sock
[basicsocket] receive timed out.
[CBasicClient] receive failed: /tmp/sectionsd.sock
Segmentation fault
starte pcamd -kill
Von ZDF auf ORF und dann wieder zurück. Box aufgehängt...

ORF hat aber keinen EPG bei uns im Kabel!


Gruß
____Paule
Innuendo
Einsteiger
Einsteiger
Beiträge: 281
Registriert: Mittwoch 8. Dezember 2004, 21:45

Beitrag von Innuendo »

PauleFoul hat geschrieben:

Code: Alles auswählen

Segmentation fault
starte pcamd -kill
huch
Npq
Senior Member
Beiträge: 1339
Registriert: Donnerstag 24. April 2003, 12:12

Beitrag von Npq »

Innuendo hat geschrieben:nachdem ich nun heut morgen meinen cvs-stand aktualisiert habe, bekomme ich beim zappen unregelmäßig folgendes im log:
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
Da ist kein RAM mehr frei.
PauleFoul
Wissender
Wissender
Beiträge: 1839
Registriert: Sonntag 17. August 2003, 01:39

Beitrag von PauleFoul »

Innuendo hat geschrieben:
PauleFoul hat geschrieben:

Code: Alles auswählen

Segmentation fault
starte pcamd -kill
huch
Ach daran liegt das... :lol: :lol:
petb
Erleuchteter
Erleuchteter
Beiträge: 785
Registriert: Samstag 6. August 2005, 03:39

Beitrag von petb »

Hallo,
war erst im falschen Thread:
jetzt aber.
----------------------------
Meine Erfahrung mit dem JTG Snap vom 26.11. 18:35

Philips, sections scan auf "ein", aktuell 10 Std. Uptime ohne Probleme.
Zappen ZDF-Infokanal, ohne Probleme.

Nokia, sections scan auf "aus"! auch 10 Std. Uptime, sonst ohne Probleme.

Auf der Nokia hatte ich mit sections scan auf "ein" 2 x kernel panic.
Schalte es jetzt gerade mal wieder ein und schau obs wieder pasiert.

Kurz noch ne Frage generell:
Wie ich erfahren habe bedeutet sections scan....:
ein = sucht nach neuen Kanälen auf dem TRansponder (meldet neuen gefundenen Kanal) nur beim zappen oder immer (interval) ?
(keine info) ein = das ganze ohne Bescheid zu geben wenn ein Kanal gefunden wurde ?
aus = aus

MUSS ich eine Kanalsuche machen wenn ich das Image neu aufspiele, oder kann ich auch meine alten services.xml und bouquets.xml nutzen ?
Muss ich irgend was anderes noch beachten, in bezug auf den sections scan ?
Danke an alle die hier gewerkelt haben, bin ziemlich zufrieden das die EPG Geschichte besser geworden ist.


So und es ist reproduzierbar.
Auf der Nokia passiert immer wenn der scan ein ist das:

Code: Alles auswählen

[timeThread] time(): 27.11.2005 11:22:45, tim: Sun Nov 27 11:22:45 2005
[timeThread] time(): 27.11.2005 11:52:50, tim: Sun Nov 27 11:52:50 2005
Oops: Kernel Mode Software FPU Emulation, sig: 8
NIP: C38A0160 XER: 20000000 LR: C38A011C SP: C0133750 REGS: c01336a0 TRAP: 1000
   Not tainted
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c0131910[0] 'swapper' Last syscall: 120
last math 00000000 last altivec 00000000
GPR00: 00001310 C0133750 C0131910 00000001 00000000 00131022 FFFFFC18 C01342EC
GPR08: 00000013 C38A8000 C38A0000 C38A8000 44393984 10138E04 01FFBD00 00000001
GPR16: FFFFFFFF 007FFF00 01FF6354 00000000 00001032 001337E0 00000000 C0002AA0
GPR24: C0003B60 00000001 C1C93AC0 00131022 00000000 00000080 00000000 C1C93AC0
Call backtrace:
00000001 C38A04D8 C0003A98 C0003B9C C0002AA0 C0004334 C0004350
C0143408 C0002138
PCR discontinuity: PCR: 0x01D3CA6F3, OLDPCR: 0x01D3BAAB9, Diff: 64570
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
 <0>Rebooting in 180 seconds..
Das pasiert ohne das an der Box irgendwas gemacht wird.
Die steht einfach nur still da und läuft, bis zum Fehler.

Bye
PetB
Innuendo
Einsteiger
Einsteiger
Beiträge: 281
Registriert: Mittwoch 8. Dezember 2004, 21:45

Beitrag von Innuendo »

Npq hat geschrieben:
Innuendo hat geschrieben:nachdem ich nun heut morgen meinen cvs-stand aktualisiert habe, bekomme ich beim zappen unregelmäßig folgendes im log:
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
Da ist kein RAM mehr frei.
das war sehr schnell nach einem reboot - vlt eine minute laufzeit - zap ard - zdf - rtl -sat1 und zurück.

vom cvs abweichend benutze ich
static long secondsToCache = 4*24*60*60L;
static long oldEventsAre = 60*60L;
meine vermutung war, das zweimal versucht wird, die selbe datei zum schreiben zu öffnen - weiß es aber nicht, du magst da recht haben.

innu
Nico 77
Semiprofi
Semiprofi
Beiträge: 1383
Registriert: Freitag 18. April 2003, 15:12

Beitrag von Nico 77 »

Npq hat geschrieben:
Innuendo hat geschrieben:nachdem ich nun heut morgen meinen cvs-stand aktualisiert habe, bekomme ich beim zappen unregelmäßig folgendes im log:
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
Da ist kein RAM mehr frei.
Das selbe habe ich hier auch nach 5 Minuten laufzeit kaum bzw kein Ram mehr frei.

Code: Alles auswählen

BusyBox v1.01 (2005.11.12-05:15+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # free
              total         used         free       shared      buffers
  Mem:        63240        61992         1248            0          408
 Swap:            0            0            0
Total:        63240        61992         1248
~ #
Nach 10 Minuten kein einloggen mehr auf Telnet möglich Box schmiert danach auch ab.
Innuendo
Einsteiger
Einsteiger
Beiträge: 281
Registriert: Mittwoch 8. Dezember 2004, 21:45

Beitrag von Innuendo »

Nico 77 hat geschrieben:

Code: Alles auswählen

~ # free
              total         used         free       shared      buffers
  Mem:        63240        61992         1248            0          408
64MB ... hier gehts um neutrino für die dbox, nicht dreambox :lol:
wann kommt noch der overdrive prozessor huckepack?

zum fehler:
kannst du den reproduzieren? ich versuch es nun seit einiger zeit, aber is ja immer so, wenn ein fehler mal auftreten soll, passiert nüx.

innu
Nico 77
Semiprofi
Semiprofi
Beiträge: 1383
Registriert: Freitag 18. April 2003, 15:12

Beitrag von Nico 77 »

Ne, Box nochmal gestart nu geht's, mal abwarten wie lange. :gruebel:
DieMade
Oberlamer, Administrator & Supernanny
Beiträge: 10532
Registriert: Samstag 13. Juli 2002, 10:49

Beitrag von DieMade »

64MB sind doch kein Problem bei Nokia und Sagem :wink:
There are 10 types of people in the world: those who know binary and those who don't
PauleFoul
Wissender
Wissender
Beiträge: 1839
Registriert: Sonntag 17. August 2003, 01:39

Beitrag von PauleFoul »

@ Nico 77

Auf welchem Sender hast Du die Box stehen?? Oder zappst Du??
Möchte mal prüfen ob ich das mit dem Speicher nachvollziehen
kann...


Gruß
____Paule
Nico 77
Semiprofi
Semiprofi
Beiträge: 1383
Registriert: Freitag 18. April 2003, 15:12

Beitrag von Nico 77 »

Das komische ist nun geht es, habe auch nochmal die alten Listen reinkopiert nochmal neu gebootet. Der Speicher wird direkt voll geschrieben aber Box schiesst sich bisher nicht mehr ab oder wird langsam.

Zappen, ka. ARD, ZDF, WDR, Premiere.

Code: Alles auswählen

              total         used         free       shared      buffers
  Mem:        63240        61320         1920            0         3536
Cpu Last beim Umschalten ca.90%.

Achso die angesprochene Bootzeit ist hier auch eine ganze Ecke länger geworden, scan an/aus ist aber egal.

Edit: Absturz lässt sich folgendermaßen reproduzieren. Sectionsd scan ein, einpaar mal hin/her zappen bis der Speicher ziemlich voll ist und dann Tuxcom starten. Dann läuft der Speicher über und die Box steht still.

Ps: Trotzdem nettes Feature, findet sofort neue Kanäle. :D
Zuletzt geändert von Nico 77 am Sonntag 27. November 2005, 14:05, insgesamt 2-mal geändert.
mb405
Tuxboxer
Tuxboxer
Beiträge: 2331
Registriert: Donnerstag 24. März 2005, 21:52

Beitrag von mb405 »

neue sectionsd.cpp eingecheckt ? was ist da neu ?

PS könnte man die prozesslast der sectionsd bisserl später einsetzen lassen (nicht gleich 10sec nach zap ??). ich weiss nicht, ob das machbar ist
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

Nico 77 hat geschrieben:Cpu Last beim Umschalten ca.90%.

Achso die angesprochene Bootzeit ist hier auch eine ganze Ecke länger geworden, scan an/aus ist aber egal.

Ps: Trotzdem hammergeiles Feature, findet sofort neue Kanäle. :D
..ich weiss nicht was daran 'hammergeil' ist...90% CPU-Last und die verlaengerte Bootzeit finde ich weniger 'hammergeil'
Nico 77
Semiprofi
Semiprofi
Beiträge: 1383
Registriert: Freitag 18. April 2003, 15:12

Beitrag von Nico 77 »

Das Feature an sich ist gut die Ausfürhung mal nochnicht, 90% CPU Last kommen von Houdini's Patches. 8)
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

Nico 77 hat geschrieben:Das Feature an sich ist gut die Ausfürhung mal nochnicht, 90% CPU Last kommen von Houdini's Patches. 8)
...weiss ich nicht..kann hier mal einer der Macher/Patcher die Parameter fuer 'scanType' und 'scan_mode' erklaeren...'scanType' steht bei mir zB. auf '3' egal was ich ueber das DBox GUI gewaehlt habe....jetzt habe ich haendig '4' eingestellt was ja wohl aus bedeuten soll...die Bootzeit bleibt trotzdem aetzende >1,5 Minuten :-(
Nico 77
Semiprofi
Semiprofi
Beiträge: 1383
Registriert: Freitag 18. April 2003, 15:12

Beitrag von Nico 77 »

petgun hat geschrieben:
Nico 77 hat geschrieben:Das Feature an sich ist gut die Ausfürhung mal nochnicht, 90% CPU Last kommen von Houdini's Patches. 8)
...weiss ich nicht..kann hier mal einer der Macher/Patcher die Parameter fuer 'scanType' und 'scan_mode' erklaeren...'scanType' steht bei mir zB. auf '3' egal was ich ueber das DBox GUI gewaehlt habe....jetzt habe ich haendig '4' eingestellt was ja wohl aus bedeuten soll...die Bootzeit bleibt trotzdem aetzende >1,5 Minuten :-(
Wie wärs mit 'scanSectionsd=0'. :D

scanType = Service-Auswahl
scan_mode = Schnell Scan
Houdini
Developer
Beiträge: 2183
Registriert: Mittwoch 10. Dezember 2003, 07:59

Beitrag von Houdini »

90% CPU Last kommen von Houdini's Patches
yep, dafür sind die events aber auch zackig da.
Er zieht sich jetzt die events aller sections/tables auf einmal rein und setzt nicht einen Filkter nach dem anderen.