Forums » Descrambling »
Bus error with tvheadend and oscam combi on wandboard quad
Added by bastiaan evers almost 11 years ago
With the great efforts of stephan-rafin.net/blog/ I've managed to get a working tvheadend on my wandboard quad dev board that I use with a client on a build of xbmc.
Everything works fine and free tv channels come through superb. I also installed oscam to read from my smartcard for DVB-T pay tv. Although everything seems to work, and tvheadend seems to successfully talk to oscam, whenever I switch to a channel that requires descrambling, tvheadend crashes with just the simple message "Bus Error".
I paste here the last few lines of a debug window FYI. Who can help please?
Nov 24 00:06:15 [ DEBUG]:Service: Subscription "192.168.1.66 [ bastiaan | XBMC Media Center ]": Adding adapter "_dev_dvb_adapter0_Zarlink_ZL10353_DVB_T698000000" for service "Zarlink ZL10353 DVB-T/Digitenne: 698,000 kHz/RTL 4"
Nov 24 00:06:15 [ DEBUG]:Service: Subscription "192.168.1.66 [ bastiaan | XBMC Media Center ]": Probing adapter "_dev_dvb_adapter0_Zarlink_ZL10353_DVB_T698000000" without stealing for service "Zarlink ZL10353 DVB-T/Digitenne: 698,000 kHz/RTL 4"
Nov 24 00:06:15 [ DEBUG]:dvb: "/dev/dvb/adapter0" tuning to "Digitenne: 698,000 kHz" (Transport start)
Nov 24 00:06:15 [ DEBUG]:viasat_baltic: install table handlers
Nov 24 00:06:15 [ DEBUG]:uk_freesat: install table handlers
Nov 24 00:06:15 [ DEBUG]:eit: install table handlers
Nov 24 00:06:15 [ DEBUG]:cwc: Zarlink ZL10353 DVB-T/Digitenne: 698,000 kHz/RTL 4 using CWC 192.168.1.68:15050
Nov 24 00:06:15 [ DEBUG]:Service: Zarlink ZL10353 DVB-T/Digitenne: 698,000 kHz/RTL 4: Status changed to [Hardware input]
Nov 24 00:06:15 [ DEBUG]:Service: Zarlink ZL10353 DVB-T/Digitenne: 698,000 kHz/RTL 4: Status changed to [Hardware input] [Input on service]
Nov 24 00:06:15 [ DEBUG]:eit: begin processing
Nov 24 00:06:15 [ DEBUG]:Service: Zarlink ZL10353 DVB-T/Digitenne: 698,000 kHz/RTL 4: Status changed to [Hardware input] [Input on service] [Demuxed packets]
Nov 24 00:06:15 [ DEBUG]:cwc: Insert only one new ECM channel 1019 for service id 11
Nov 24 00:06:15 [ DEBUG]:cwc: Sending ECM (channel 1019) section=0/0, for service RTL 4 (seqno: 2) PID 1019
Nov 24 00:06:16 [ DEBUG]:tdt-tot: time is 2013/11/24 00:06:15
Nov 24 00:06:16 [ DEBUG]:cwc: es->es_nok 0 t->tht_prefcapid 1019
Nov 24 00:06:16 [ DEBUG]:cwc: Received ECM reply (channel 1019) for service "RTL 4" even: 59.9a.c5.b8.f5.51.82.c8 odd: 83.1a.47.e4.f7.c8.42.01 (seqno: 2 Req delay: 370 ms)
Nov 24 00:06:16 [ INFO]:cwc: Obtained key for service "RTL 4" in 370 ms, from 192.168.1.68:15050
Bus error
Replies (3)
RE: Bus error with tvheadend and oscam combi on wandboard quad - Added by bastiaan evers almost 11 years ago
I have some additional info, found in dmesg. It seems an alignment trap. Any suggestions?:
[60052.056976] Alignment trap: tvheadend (14013) PC=0x0006773c Instr=0xe1c000d0 Address=0x3210c7b1 FSR 0x011
[60052.057150] Alignment trap: tvheadend (14013) PC=0x00068380 Instr=0xedc10b00 Address=0x3210c7b1 FSR 0x811
[60052.057176] Alignment trap: not handling instruction edc10b00 at [<00068380>]
[60052.064868] Unhandled fault: alignment exception (0x811) at 0x3210c7b1
RE: Bus error with tvheadend and oscam combi on wandboard quad - Added by Daniel Forsberg over 10 years ago
bastiaan evers wrote:
I have some additional info, found in dmesg. It seems an alignment trap. Any suggestions?:
[60052.056976] Alignment trap: tvheadend (14013) PC=0x0006773c Instr=0xe1c000d0 Address=0x3210c7b1 FSR 0x011
[60052.057150] Alignment trap: tvheadend (14013) PC=0x00068380 Instr=0xedc10b00 Address=0x3210c7b1 FSR 0x811
[60052.057176] Alignment trap: not handling instruction edc10b00 at [<00068380>]
[60052.064868] Unhandled fault: alignment exception (0x811) at 0x3210c7b1
Hi!
You managed to solve this?
I get the same error on a Cuboxi, also using the imx6 arm chips
RE: Bus error with tvheadend and oscam combi on wandboard quad - Added by Stefan Saraev almost 10 years ago
an openelec user reported the same happens on his Cubox-i
compiling tvheadend with "-mno-unaligned-access" in CFLAGS helped.
EDIT: testing current git master (3.9.2182 at the time of writing this)