Problem with full support of FE_GET_PROPERTY #18

masjerang · 2020-07-14T11:26:59Z

Hi,

I would like to address an issue I'm experiencing since I upgraded Mythtv to 0.31.
Mythtv is crashing on DVBv5 API calls because dvbloopback/descrambler is not returning the correct dtv_properties.
Disabling the DVBv5 calls in Mythtv will prevent it from crashing but dvbloopback needs some fixing.

The investigation I did already so far, in a test-bed (using DTV_STAT_SIGNAL_STRENGTH):

Example code:

static struct dtv_property prop[1] = {
        { .cmd = DTV_STAT_SIGNAL_STRENGTH},
    };

static struct dtv_properties dtv_propa = {
    .num = 1, .props = propa
    };
    int ret;
    if ((ret=ioctl(fd, FE_GET_PROPERTY, &dtv_propa)) == -1) {
        perror("ioctl");
        return -1;
    }
    printf("Signal strength: ret=%u res=%u\n",ret, dtv_propa.props->result);

Results in GDB with physical adapter:


	    if ((ret=ioctl(fd, FE_GET_PROPERTY, &dtv_propa)) == -1) {
(gdb) print dtv_propa
$1 = {num = 1, props = 0x5555555580c0 <propa>}
(gdb) print propa
$2 = {{cmd = 62, reserved = {0, 0, 0}, u = {data = 0, st = {len = 0 '\000', stat = {{scale = 0 '\000', {uvalue = 0, svalue = 0}}, {scale = 0 '\000', 
            {uvalue = 0, svalue = 0}}, {scale = 0 '\000', {uvalue = 0, svalue = 0}}, {scale = 0 '\000', {uvalue = 0, svalue = 0}}}}, buffer = {
        data = '\000' <repeats 31 times>, len = 0, reserved1 = {0, 0, 0}, reserved2 = 0x0}}, result = 0}}
(gdb) continue
Continuing.

Breakpoint 2, main () at test-dvb.c:56
56	    printf("Signal strength: ret=%u res=%u\n",ret, dtv_propa.props->result);
(gdb) print dtv_propa
$3 = {num = 1, props = 0x5555555580c0 <propa>}
(gdb) print propa
$4 = {{cmd = 62, reserved = {0, 0, 0}, u = {data = 2853175553, st = {len = 1 '\001', stat = {{scale = 1 '\001', {uvalue = 18446744073709529616, 
              svalue = -22000}}, {scale = 0 '\000', {uvalue = 0, svalue = 0}}, {scale = 0 '\000', {uvalue = 0, svalue = 0}}, {scale = 0 '\000', {
              uvalue = 0, svalue = 0}}}}, buffer = {data = "\001\001\020\252\377\377\377\377\377\377", '\000' <repeats 21 times>, len = 0, 
        reserved1 = {0, 0, 0}, reserved2 = 0x0}}, result = 0}}
(gdb)

Results in GDB with loopback adapter:

	    if ((ret=ioctl(fd, FE_GET_PROPERTY, &dtv_propa)) == -1) {
(gdb) print dtv_propa
$1 = {num = 1, props = 0x5555555580c0 <propa>}
(gdb) print propa
$2 = {{cmd = 62, reserved = {0, 0, 0}, u = {data = 0, st = {len = 0 '\000', stat = {{scale = 0 '\000', {uvalue = 0, svalue = 0}}, {scale = 0 '\000', 
            {uvalue = 0, svalue = 0}}, {scale = 0 '\000', {uvalue = 0, svalue = 0}}, {scale = 0 '\000', {uvalue = 0, svalue = 0}}}}, buffer = {
        data = '\000' <repeats 31 times>, len = 0, reserved1 = {0, 0, 0}, reserved2 = 0x0}}, result = 0}}
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
main () at test-dvb.c:56
56	    printf("Signal strength: ret=%u res=%u\n",ret, dtv_propa.props->result);
(gdb) print dtv_propa
$3 = {num = 1, props = 0xffff9c65bb697850}
(gdb) print propa
$4 = {{cmd = 62, reserved = {0, 0, 0}, u = {data = 2853175553, st = {len = 1 '\001', stat = {{scale = 1 '\001', {uvalue = 18446744073709529616, 
              svalue = -22000}}, {scale = 0 '\000', {uvalue = 0, svalue = 0}}, {scale = 0 '\000', {uvalue = 0, svalue = 0}}, {scale = 0 '\000', {
              uvalue = 0, svalue = 0}}}}, buffer = {data = "\001\001\020\252\377\377\377\377\377\377", '\000' <repeats 21 times>, len = 0, 
        reserved1 = {0, 0, 0}, reserved2 = 0x0}}, result = 0}}
(gdb)

It seems that dtv_propa.props is corrupt and not properly copied.
However propa is set correctly, but is not being referred to by dtv_propa.props
There are some comments in dvb_loopback.c (in function call_func) about copying pointers.

Anyone experiencing similar issues?

The text was updated successfully, but these errors were encountered:

Strunzdesign · 2020-07-14T15:57:07Z

Hi,

I had the same issue. I fixed it by editing file "dvbchannel.cpp" of mythbackend. I deactivated the related section using a comment and the error is gone:

// documented in dvbchannel.h
double DVBChannel::GetUncorrectedBlockCount(bool *ok) const
{
    DVBChannel *master = GetMasterLock();
    if (master != this)
    {
        double val = master->GetUncorrectedBlockCount(ok);
        ReturnMasterLock(master);
        return val;
    }
    ReturnMasterLock(master); // if we're the master we don't need this lock..

    uint32_t ublocks = 0;
    int ret = ioctl(m_fdFrontend, FE_READ_UNCORRECTED_BLOCKS, &ublocks);
    if (ret < 0)
    {
        /*
        if (errno == EOPNOTSUPP || errno == ENOTSUPP)
        {
            return GetUncorrectedBlockCountDVBv5(ok);
        }
        */
        LOG(VB_GENERAL, LOG_ERR, LOC +
            "Getting Frontend uncorrected block count failed." + ENO);
    }

    if (ok)
        *ok = (0 == ret);

    return (double) ublocks;
}

The root of the problem is that a pointer is passed via ioctl() but that pointer is just copied by the "intermediate" software, delivered to the mythbackend, which then tries to dereference it. However, mythbackend lacks permissions to dereference this pointer, as only the "intermediate" software has permissions to do so.

IIRC, this behavior is also documented somewhere, not 100% sure where, but I can find it again. It is a bug caused by not implementing all features up to a level of 100%, but as far as it was required some time ago to get things working.

Regards,
Florian

Strunzdesign · 2020-07-14T16:01:09Z

Now I read your post a second time and realized that you already found that comment regarding that missing copying of pointed-to memory in the code :-)

bas-t · 2020-07-14T16:56:50Z

As you probably know, I don't use this software anymore. However, I'm willing to update it accordinng to your needs.
If you think I should do something, please let me know.
Regards, Tycho

masjerang · 2020-07-14T18:22:35Z

Hi @bas-t,

Thanks, fully understand! I’ll let you know if there is something to commit.

Hi Florian,

It is not only a MythTv problem, even the dvbv5-tools are failing. So it is related how dvbloopback returns the dvt_properties. There is an incorrect pointer returned, but the dtv_property is set correctly. (See my example program and Gdb output).
If there is a chance to fix this, dvbloopback is probably DVBv5 compliant.
I’ve already changed the v5 functions in mythtv as a workaround, but I’m looking for some community support to see if we can get dvbloopback fixed.
Anyway, I’ll do some more digging.

Strunzdesign · 2020-07-14T22:07:43Z

I want to help, but I did not invest enough time yet to understand all the mechanics involved here to carry data back and forth from kernel and user space. My guess is that at some point logic has to be added that is specific to well-known service primitives that involve pointers, and add specific handlers to that. Such a handler would not copy the pointer, but the data pointed to, and deliver a new pointer (just an assumption!). No idea how many handlers would be required. Alone to answer that one may need to have a deeper look into the kernel code at DVBv5 and check all the returned data structures for pointers.

masjerang · 2020-07-15T21:17:37Z

Hi,

Please find attached a small debug program.
dvbloopback provides the correct information back to user program, but the dtv_properties has an altered pointer/address to .props. Setting this back manually will let the program run. So content is there, but address/pointer is wrongly set/altered by dvbloopback.If there is a way to prevent dvbloopback to alter the pointer or set it back to the original, the problems seems to be fixed from my perspective. Happy to hear your thoughts.

A few questions to understand dvbloopback and descramber a bit more:

dvbloopback creates a new virtual adapter with frontend0 and frontend1. User program connects to virtual adapter frontend0, descrambler links real adapter frontend0 with virtual adapter frontend1. Is that correct?
What does copy_to_user do? What does copy_from_user do in dvbloopback? Just to understand the direction.
What is userspace? Is it mythtv or dvb5_scan in this case?
How should I read user_func and dvblb_usercopy? In which direction: from real adapter->virtual adapter>user program or in the opposite direction?

Thanks for providing some info.

[
test-dvb.txt

](url)

Strunzdesign · 2020-07-15T22:10:46Z

Hi,

great that you are having a deeper look into this! I know not much about that stuff yet, but I want to share my thoughts:

Your assumption that descrambler links frontend0 and frontend1: not sure, but descrambler is the entity that "links" a real adaptor to a loopback adaptor. Thus, descrabler would have to deal with three interfaces: one towards the real DVB driver, and twice towards the loopback driver using frontend0 and/or frontend1. Not clear yet why one needs three interface, maybe kind of a read/write path separation?
Your other three questions: no idea yet, I have to look at the code, but I'm going to bed now. Tomorrow maybe.

An user-space application such as mythbackend or your test application communicates with the kernel using calls to ioctl(). Thus, there must be an interface in dvblookback that lurks at the other side of the call to ioctl() in kernel space. This MAY be one of the copy_to/copy_from things. However, there is also the data flow from kernel to descrambler and vice-versa, via frontend0 and frontend1. Makes three "flows" with maybe two directions each. And, there is the communication with the "real" DVB interface. Does frontend0/1 provide kind of an "ioctl tunneling protocol"? And what about the validity of pointers? If you copy the address contained in a pointer from kernel space (DVB driver) to user space (descrambler), then back to kernel space (dvbloopback) and then back to user space (mythbackend) then this pointer may be the same "number", but it may not be valid to dereference it due to isolation of processes / address spaces. Thus, I have the assumption that a pure copying of addresses is not sufficient, maybe one needs to create a duplicate of the pointed-to memory as well. On the other hand, you got this working somehow, and only an address value was altered somewhere.

Just my thoughts, though. Lots of MAYs.

Regards,
Florian

Strunzdesign · 2020-07-16T17:48:58Z

Hi,

"lsof" helped, on an active live-TV session:

/dev/dvb/adapterDVBCARD/demux0 -- opened by ffdecsawrapper, LOTS of times
/dev/dvb/adapterDVBCARD/dvr0 -- opened by ffdecsawrapper, once
/dev/dvb/adapterDVBCARD/frontend0 -- opened by ffdecsawrapper, once
/dev/dvb/adapterLOOPBACK/audio[01] -- not opened
/dev/dvb/adapterLOOPBACK/demux0 -- opened by mythbackend, LOTS of times
/dev/dvb/adapterLOOPBACK/demux1 -- opened by ffdecsawrapper, twice
/dev/dvb/adapterLOOPBACK/dvr0 -- opened by mythbackend, once
/dev/dvb/adapterLOOPBACK/dvr1 -- opened by ffdecsawrapper, twice
/dev/dvb/adapterLOOPBACK/frontend0 -- opened by mythbackend, once
/dev/dvb/adapterLOOPBACK/frontend1 -- opened by ffdecsawrapper,twice
/dev/dvb/adapterLOOPBACK/osd[01] -- not opened
/dev/dvb/adapterLOOPBACK/video[01] -- not opened

Thus, the chain of components is as follows here:

[Kernel DVB device] <--> ffdescawrapper <--> [Loopback subID 1] <--> dvbloopback <-->[Loopback subID 0] <--> Mythbackend

Regards,
Florian

Strunzdesign · 2020-07-16T18:55:20Z

What helps is increasing the verbosity level in dvb_loopback.c. There, set dvblb_debug to 2. Afterwards you may also add subsequent dprintk, dprintk2, or dprintk3 statements to examine the flow of data.

masjerang · 2020-07-16T21:21:57Z

Thanks Florian for confirming my thoughts.
I'm already working on adding more dprintk statements. I'm really thinking that call_func is one of the suspects, juggling with pointers etc. Keep you posted.

masjerang · 2020-07-17T21:08:36Z

hi Florian, and others,

Can you please try the following by adding the following line on line 160 in dvb_loopback.c (just before 'return err'):

tvps->props = oldprops;

(Sorry, no clean patch yet).

masjerang · 2020-07-18T11:27:22Z

I've created a patch to fix the return of the proper tvps-props address.
patch-1.txt

I've also included some changes to dnames as to my opinion, the wrong order is in there, which I found out during debugging.

Please verify and test properly before running on production systems.

Next action is to fix some other things which are going wrong:

dvbv5-scan is not scanning my virtual adapters properly. It bails out with crc failure.
some debugging output raises some other questions. See bold text (cmds).

[47016.988066] dvblb_fake_ioctl (2) : 42
[47016.988901] dvblb_ioctl 2demux1 fd:0 cmd:6f2a
[47016.989683] fake-ioctl wait (28458) returned: 250/18446744073709551615
[47016.990983] dvblb_release 2demux0 fd:1
[47016.992252] dvblb_fake_ioctl (2) : 5
[47016.993645] dvblb_ioctl 2demux1 fd:0 cmd:5
[47016.994420] fake-ioctl wait (5) returned: 250/18446744073709551615
[47016.995755] dvblb_release 2frontend0 fd:1
[47016.996490] dvblb_fake_ioctl (2) : 5
[47016.997278] dvblb_ioctl 2frontend1 fd:0 cmd:5
[47016.998189] fake-ioctl wait (5) returned: 250/18446744073709551615

Strunzdesign · 2020-07-18T18:19:34Z

Hi, your results sound great! However, I wonder that nobody ever noticed the wrong order of names, I hope you are sure what you are doing.

I only have a production system here, that I can abuse for testing if I'm careful. If you give me some info how I should perform tests with your patch in order to maximize the benefit for you, please tell me. Otherwise I would revert my patches applied to mythbackend and check whether it still crashes together with your patched dvbloop device. I'm hoping that no other negative side-effects appear. Regarding side-effects: now you always overwrite tvps->props. May there be situations in which the previous behavior was correct?

Thank you very much,
Florian

masjerang · 2020-07-18T20:09:17Z

Hi Florian,

It looks trivial. Why not many other programs have failed, is because some programs directly call the dtv_property object and not through dtv_properties (like mythtv is doing). Also my test-dvb program does it via two different ways. For querying the DVB api version, I’m calling dtv_property directly, which is not a problem for dvbloopback, as this is filled properly with return values.
For the signal strength I’m querying the dtv_properties and here is goes wrong as the pointer is altered when getting dtv_properties back from dvbloopback.

If you look at call_func, there is some creation, copying and submitting into the real dvb adapter/descrambler. Why there is a copy created, has probably to do with kernel privileges (copy_from_user and copy_to_user), but then the original pointer is not set back to the dtv_property (which is correctly filled by copying tvp back to oldprops).

This bug is only affecting FE_GET_PROPERTY calls where the user program acces dtv_property through the dtv_properties object.

I haven’t tested with mythtv yet as I’m abroad but my test-dvb shows good results (no segfault anymore).
So in order to commit, there are probably a few positive reporters required.

sidamos · 2020-07-19T06:46:16Z

Applied the patch to my test system and Live TV is working, great! EIT scanning is also working.
I will now schedule some recordings and see how it works during the next few days.

kmdewaal · 2020-07-19T07:39:54Z

Does channel scanning with mythtv-setup also work?

sidamos · 2020-07-19T08:55:15Z

Someone else hast to test channel scanning with MythTV. I stopped using that years ago because it messed up my channels. Since then, I scan with an external program and import the results into the database. The external "scan-dvb" works fine with this patch (although I did not test without the patch).

Strunzdesign · 2020-07-19T09:20:10Z

I'm going to conduct a MythTV channel scan today, so "stay tuned" scnr

Strunzdesign · 2020-07-19T15:12:35Z

First feedback with mythbackend 31.0-r1 and patched dvblookback:

LiveTV works, no immediate crash anymore.
Driver warning "Selected fec_inner parameter unsupported by this driver"
Driver warning "Cannot count Uncorrected Blocks - eno: Unbekannter Fehler 524 (524)"

This is my log:

# cat mythbackend.XXXX.log
[...]
2020-07-19 17:01:13.900135 N [9061/9061] CoreContext main_helpers.cpp:605 (run_backend) - MythBackend: Starting up as the master server.
2020-07-19 17:01:14.050679 I [9061/9061] CoreContext cardutil.cpp:1170 (SetDeliverySystem) - CardUtil[1]: Set delivery system: DVB-S2
2020-07-19 17:01:15.248920 W [9061/9061] CoreContext recorders/dvbchannel.cpp:380 (CheckOptions) - DVBChan[1](/dev/dvb/adapter4/frontend0): Selected fec_inner parameter unsupported by this driver.
[...last I+W message pair repeats for every frontend...]
[...]
[..starting live TV session..]
2020-07-19 17:02:17.094972 I [9061/9292] TVRecEvent tv_rec.cpp:1057 (HandleStateChange) - TVRec[4]: Changing from None to WatchingLiveTV
2020-07-19 17:02:17.097179 I [9061/9292] TVRecEvent tv_rec.cpp:3662 (TuningFrequency) - TVRec[4]: TuningFrequency
2020-07-19 17:02:17.115311 I [9061/9292] TVRecEvent cardutil.cpp:1170 (SetDeliverySystem) - CardUtil[1]: Set delivery system: DVB-S2
2020-07-19 17:02:18.312086 W [9061/9292] TVRecEvent recorders/dvbchannel.cpp:380 (CheckOptions) - DVBChan[4](/dev/dvb/adapter4/frontend0): Selected fec_inner parameter unsupported by this driver.
2020-07-19 17:02:18.527200 N [9061/9061] CoreContext autoexpire.cpp:242 (CalcParams) - AutoExpire: CalcParams(): Max required Free Space: 3.0 GB w/freq: 14 min
2020-07-19 17:02:18.578111 N [9061/9292] TVRecEvent recordinginfo.cpp:678 (ApplyRecordRecGroupChange) - ApplyRecordRecGroupChange: LiveTV to LiveTV (2)
2020-07-19 17:02:18.667213 W [9061/9292] TVRecEvent recorders/dvbsignalmonitor.cpp:109 (DVBSignalMonitor) - DVBSigMon[4](/dev/dvb/adapter4/frontend0): Cannot count Uncorrected Blocks
                        eno: Unbekannter Fehler 524 (524)
[...]

The warnings indicate an open issue with invoking FE_GET_PROPERTY.

sidamos · 2020-07-19T16:08:34Z

I always had these 2 warnings with MythTV and dvbloopback. They are not new for MythTV 31 or the patched dvbloopback.

Strunzdesign · 2020-07-19T16:08:55Z

Performing a channel scan with mythtv-setup works here! At first, I got one strange database error multiple times about a missing column "service_type" in table "channelscan_channel", but that seems to be an unrelated bug as the schema specification does not even mention this field. Now I have to reorder my channel list again or revert my backup do get it back online, but scanning works.

During scanning, the mythtv-setup GUI shows bars for "Signal/Noise" and "Signal Strength". So I assume that at some point the software is able to get some quality-related readings from the driver :-)

Thank you very much,
Florian

masjerang · 2020-07-19T16:09:27Z

Thanks for testing!
I’m not convinced this has to do with FE_GET_PROPERTY. I’ll do some further digging and test separately if the test program returns fec and incorrecte blocks. I’ll let you know but first results are good.

Do you have some FTA channels to test this without dvbloopback?

First feedback with mythbackend 31.0-r1 and patched dvblookback:

LiveTV works, no immediate crash anymore.
Driver warning "Selected fec_inner parameter unsupported by this driver"
Driver warning "Cannot count Uncorrected Blocks - eno: Unbekannter Fehler 524 (524)"

This is my log:

# cat mythbackend.XXXX.log
[...]
2020-07-19 17:01:13.900135 N [9061/9061] CoreContext main_helpers.cpp:605 (run_backend) - MythBackend: Starting up as the master server.
2020-07-19 17:01:14.050679 I [9061/9061] CoreContext cardutil.cpp:1170 (SetDeliverySystem) - CardUtil[1]: Set delivery system: DVB-S2
2020-07-19 17:01:15.248920 W [9061/9061] CoreContext recorders/dvbchannel.cpp:380 (CheckOptions) - DVBChan[1](/dev/dvb/adapter4/frontend0): Selected fec_inner parameter unsupported by this driver.
[...last I+W message pair repeats for every frontend...]
[...]
[..starting live TV session..]
2020-07-19 17:02:17.094972 I [9061/9292] TVRecEvent tv_rec.cpp:1057 (HandleStateChange) - TVRec[4]: Changing from None to WatchingLiveTV
2020-07-19 17:02:17.097179 I [9061/9292] TVRecEvent tv_rec.cpp:3662 (TuningFrequency) - TVRec[4]: TuningFrequency
2020-07-19 17:02:17.115311 I [9061/9292] TVRecEvent cardutil.cpp:1170 (SetDeliverySystem) - CardUtil[1]: Set delivery system: DVB-S2
2020-07-19 17:02:18.312086 W [9061/9292] TVRecEvent recorders/dvbchannel.cpp:380 (CheckOptions) - DVBChan[4](/dev/dvb/adapter4/frontend0): Selected fec_inner parameter unsupported by this driver.
2020-07-19 17:02:18.527200 N [9061/9061] CoreContext autoexpire.cpp:242 (CalcParams) - AutoExpire: CalcParams(): Max required Free Space: 3.0 GB w/freq: 14 min
2020-07-19 17:02:18.578111 N [9061/9292] TVRecEvent recordinginfo.cpp:678 (ApplyRecordRecGroupChange) - ApplyRecordRecGroupChange: LiveTV to LiveTV (2)
2020-07-19 17:02:18.667213 W [9061/9292] TVRecEvent recorders/dvbsignalmonitor.cpp:109 (DVBSignalMonitor) - DVBSigMon[4](/dev/dvb/adapter4/frontend0): Cannot count Uncorrected Blocks
                        eno: Unbekannter Fehler 524 (524)
[...]

The warnings indicate an open issue with invoking FE_GET_PROPERTY.

Strunzdesign · 2020-07-19T16:10:03Z

I agree that these warnings "were always there" in the past, but I hope that will go away now as these issues are fixed in the dvbloopback driver.

masjerang · 2020-07-19T16:12:07Z

Thanks both! I like the cooperation with you to have this fixed!
It get me more motivated to look at some other related improvements.

masjerang · 2020-07-19T20:40:44Z

@bas-t are you able to commit the patch in this comment ?

Strunzdesign · 2020-07-20T17:58:00Z

Many thanks again for providing this solution and for merging it. If you plan more changes and need someone to discuss or to test, I want to help. For that, I keep an eye on this bug report and this repository in general.

masjerang · 2020-07-21T19:14:37Z

Hi Florian,

NP. There are some other not that urgent improvements to do. For example: dvbv5-scan gives a crc error while scanning virtual adapter. Descrambler is probably rewriting the PAT and not updating crc correctly. Not a problem for mythtv, but a good one to improve descrambler with dvbloopback. For doing that I need to understand the function of descrambler a bit better (than just decrypting the encrypted TS packets). I’ll raise an issue for that soon.
A second thought which comes back, is an activity I did a couple of years back, was to integrate the descrambling into mythtv using oscam (see mythtv fork in my github, using IPTV AES decryption).
Anyway, sufficient ideas, but lack of enough time. :-)

bas-t · 2020-07-21T19:27:45Z

@masjerang please open a new ticket for any future improvements. Do not continue to communicate in a already closed ticket, unless you discovered an anomaly with this one, inthat case the ticked should be reope d.
Anyway, thanks alot for yor effort.
Cheers,
Tycho.

bas-t · 2020-07-21T20:00:56Z

@masjerang I mean, even if it is a draft, or just some thoughts about how to improve the lot, please open a new ticket. We can alwas change the title of the ticket in case that is appropriate.

Strunzdesign · 2020-08-17T18:13:55Z

Hi @masjerang,

did you test your patch with a recent kernel? On 5.7.15 I get lots of crash dumps in dmesg, but the driver still works.


[    4.877952] ------------[ cut here ]------------
[    4.877953] proc_dir_entry 'adapterX/sec' already registered
[    4.877962] WARNING: CPU: 1 PID: 2160 at fs/proc/generic.c:362 proc_register+0xfd/0x140
[    4.877962] Modules linked in: dvbloopback(+)
[    4.877965] CPU: 1 PID: 2160 Comm: modprobe Tainted: G                T 5.7.15-gentoo #1
[    4.877966] Hardware name: XXXX
[    4.877968] RIP: 0010:proc_register+0xfd/0x140
[    4.877969] Code: 48 aa b2 01 00 5b 48 89 e8 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b b4 24 98 00 00 00 4c 89 fa 48 c7 c7 28 51 40 92 e8 50 1a e0 ff <0f> 0b c6 05 1a aa b2 01 00 8b 85 a0 00 00 00 48 c7 c7 e0 a9 67 92
[    4.877970] RSP: 0000:ffffa4c840f53b78 EFLAGS: 00010286
[    4.877971] RAX: 0000000000000000 RBX: ffff89215cb58068 RCX: 0000000000000376
[    4.877971] RDX: 0000000000000001 RSI: 0000000000000092 RDI: ffffffff92ddb668
[    4.877972] RBP: ffff89215722d840 R08: 0000000000000001 R09: 0000000000000376
[    4.877973] R10: 00000000000131ac R11: 0000000000000001 R12: ffff89215cb58d80
[    4.877973] R13: ffff89215cb58da0 R14: 0000000000000003 R15: ffff89215722d8f0
[    4.877974] FS:  00007feb857e9740(0000) GS:ffff89215fc80000(0000) knlGS:0000000000000000
[    4.877975] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    4.877976] CR2: 00007f1c0c098d60 CR3: 00000004171d6006 CR4: 00000000000606e0
[    4.877976] Call Trace:
[    4.877980]  proc_create_data+0x45/0x60
[    4.877983]  dvblb_init_procfs_device+0x33/0x50 [dvbloopback]
[    4.877986]  create_lb_dev+0x165/0x22b [dvbloopback]
[    4.877988]  dvblb_init+0x38e/0x1000 [dvbloopback]
[    4.877989]  ? 0xffffffffc02ed000
[    4.877991]  do_one_initcall+0x5f/0x210
[    4.877994]  do_init_module+0x56/0x210
[    4.877995]  load_module+0x231a/0x2590
[    4.877997]  ? __do_sys_finit_module+0xd7/0xf0
[    4.877998]  __do_sys_finit_module+0xd7/0xf0
[    4.878000]  do_syscall_64+0x46/0x110
[    4.878003]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[    4.878004] RIP: 0033:0x7feb858e2009
[    4.878005] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 47 0e 0c 00 f7 d8 64 89 01 48
[    4.878006] RSP: 002b:00007ffd9db0ca38 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[    4.878007] RAX: ffffffffffffffda RBX: 0000558ca01ffa70 RCX: 00007feb858e2009
[    4.878007] RDX: 0000000000000000 RSI: 0000558ca01ffdf0 RDI: 0000000000000003
[    4.878008] RBP: 0000000000060020 R08: 0000000000000000 R09: 0000000000000000
[    4.878008] R10: 0000000000000003 R11: 0000000000000246 R12: 0000558ca01ffdf0
[    4.878009] R13: 0000000000000000 R14: 0000558ca01ffb80 R15: 0000000000000000
[    4.878010] ---[ end trace 7d9fe1ca2cbd53c1 ]---

Per loopback device I get two such crash blocks. They differ in their "topic":

proc_dir_entry 'adapterX/sec' already registered
proc_dir_entry 'adapterX/frontend' already registered

Is this related to your changed / extended dnames variable?

Regards,
Florian

Strunzdesign · 2020-08-17T18:16:21Z

I just noticed there is already a bug open for this.

Strunzdesign · 2020-09-11T15:23:46Z

Tested the current "master" on Linux kernel 5.8.8 without problems. However, no changes to descambler were applied, so there might be a mismatch between the names now. I do not see any warnings regarding that, but I feel not good about it either. However, it works, thanks!

bas-t closed this as completed in c56e73a Jul 20, 2020

masjerang mentioned this issue Jul 28, 2020

Rewrite dnames #19

Closed

masjerang mentioned this issue Aug 23, 2020

Update dnames to match correct device type and names #20

Merged

Strunzdesign mentioned this issue Aug 29, 2020

Anyone experiencing proc_dir_entry 'x' already registered? #21

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Problem with full support of FE_GET_PROPERTY #18

Problem with full support of FE_GET_PROPERTY #18

masjerang commented Jul 14, 2020

Strunzdesign commented Jul 14, 2020 •

edited

Loading

Strunzdesign commented Jul 14, 2020

bas-t commented Jul 14, 2020

masjerang commented Jul 14, 2020

Strunzdesign commented Jul 14, 2020 •

edited

Loading

masjerang commented Jul 15, 2020

Strunzdesign commented Jul 15, 2020

Strunzdesign commented Jul 16, 2020

Strunzdesign commented Jul 16, 2020

masjerang commented Jul 16, 2020

masjerang commented Jul 17, 2020

masjerang commented Jul 18, 2020

Strunzdesign commented Jul 18, 2020

masjerang commented Jul 18, 2020

sidamos commented Jul 19, 2020 •

edited

Loading

kmdewaal commented Jul 19, 2020

sidamos commented Jul 19, 2020 •

edited

Loading

Strunzdesign commented Jul 19, 2020

Strunzdesign commented Jul 19, 2020

sidamos commented Jul 19, 2020

Strunzdesign commented Jul 19, 2020

masjerang commented Jul 19, 2020 •

edited

Loading

Strunzdesign commented Jul 19, 2020

masjerang commented Jul 19, 2020

masjerang commented Jul 19, 2020 •

edited

Loading

Strunzdesign commented Jul 20, 2020

masjerang commented Jul 21, 2020

bas-t commented Jul 21, 2020

bas-t commented Jul 21, 2020

Strunzdesign commented Aug 17, 2020

Strunzdesign commented Aug 17, 2020

Strunzdesign commented Sep 11, 2020

Problem with full support of FE_GET_PROPERTY #18

Problem with full support of FE_GET_PROPERTY #18

Comments

masjerang commented Jul 14, 2020

Strunzdesign commented Jul 14, 2020 • edited Loading

Strunzdesign commented Jul 14, 2020

bas-t commented Jul 14, 2020

masjerang commented Jul 14, 2020

Strunzdesign commented Jul 14, 2020 • edited Loading

masjerang commented Jul 15, 2020

Strunzdesign commented Jul 15, 2020

Strunzdesign commented Jul 16, 2020

Strunzdesign commented Jul 16, 2020

masjerang commented Jul 16, 2020

masjerang commented Jul 17, 2020

masjerang commented Jul 18, 2020

Strunzdesign commented Jul 18, 2020

masjerang commented Jul 18, 2020

sidamos commented Jul 19, 2020 • edited Loading

kmdewaal commented Jul 19, 2020

sidamos commented Jul 19, 2020 • edited Loading

Strunzdesign commented Jul 19, 2020

Strunzdesign commented Jul 19, 2020

sidamos commented Jul 19, 2020

Strunzdesign commented Jul 19, 2020

masjerang commented Jul 19, 2020 • edited Loading

Strunzdesign commented Jul 19, 2020

masjerang commented Jul 19, 2020

masjerang commented Jul 19, 2020 • edited Loading

Strunzdesign commented Jul 20, 2020

masjerang commented Jul 21, 2020

bas-t commented Jul 21, 2020

bas-t commented Jul 21, 2020

Strunzdesign commented Aug 17, 2020

Strunzdesign commented Aug 17, 2020

Strunzdesign commented Sep 11, 2020

Strunzdesign commented Jul 14, 2020 •

edited

Loading

Strunzdesign commented Jul 14, 2020 •

edited

Loading

sidamos commented Jul 19, 2020 •

edited

Loading

sidamos commented Jul 19, 2020 •

edited

Loading

masjerang commented Jul 19, 2020 •

edited

Loading

masjerang commented Jul 19, 2020 •

edited

Loading