Bug 1958557
| Summary: | Support multiple Airspy devices | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Daniel Rusek <drusek> | ||||||||||||
| Component: | gr-osmosdr | Assignee: | Jaroslav Škarvada <jskarvad> | ||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||
| Severity: | high | Docs Contact: | |||||||||||||
| Priority: | unspecified | ||||||||||||||
| Version: | rawhide | CC: | jskarvad, logans, mail | ||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | Unspecified | ||||||||||||||
| OS: | Unspecified | ||||||||||||||
| URL: | https://osmocom.org/issues/5144 | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | gr-osmosdr-0.2.3-13.20210217gita100eb02.fc36 | Doc Type: | If docs needed, set a value | ||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | Environment: | ||||||||||||||
| Last Closed: | 2021-10-12 21:28:22 UTC | Type: | Bug | ||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||
| Documentation: | --- | CRM: | |||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
| Embargoed: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Daniel Rusek
2021-05-08 19:22:22 UTC
Created attachment 1781826 [details]
Airspy patch adding multiple sources support
Created attachment 1781827 [details]
gr-osmosdr spec file diff
I have found out that even though the patch works fine, it has one behavior change that could be considered as an regression. :( When this patch is applied, the Airspy Source does not find any devices when an "airspy" argument is specified without any value (just "airspy"). It works fine when specifying it as "airspy=0" (which is what Gqrx does by default). I have found no other issues besides this and both my Airspy R2 SDRs work fine now after specifying them by their serial numbers. According to this comment from the source code patch, it should work: "if no device arguments are given or s/n=0, the first found airspy device will be used" - So yeah, it is an regression, unfortunately. :/ Maybe jskarvad or someone else who is more skilled in C than I am could fix the patch? :) This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35. Created attachment 1832160 [details]
Proposed fix
No problem to add the patch downstream, it seems useful, but better to get it to upstream.
Please try the following hack whether it resolves your problem. If yes, it seems like some gcc regression and I will open gcc bug.
Created attachment 1832161 [details]
Proposed fix
Even more simplified version of the hack.
Unfortunately, I cannot check it myself, because I don't have the airspy HW. I unfortunately also do not have any Airspy hw here at the moment. :-/ But when I was using two Airspy R2 dongles, they worked fine when using the original patch that I posted in #c1, however that patch caused a regression as mentioned in #c3. (In reply to Daniel Rusek from comment #10) > I unfortunately also do not have any Airspy hw here at the moment. :-/ > > But when I was using two Airspy R2 dongles, they worked fine when using the > original patch that I posted in #c1, however that patch caused a regression > as mentioned in #c3. Updated patch I posted should target the regression. I have actually managed to find some AirSpy R2s here that I thought were somewhere else. :-) So, I was able to test your patch from #c8, sadly it still does the same thing: When I use the "airspy" argument without any value, it does not find any actual devices. It works fine when I use "airspy=0". (In reply to Daniel Rusek from comment #12) > I have actually managed to find some AirSpy R2s here that I thought were > somewhere else. :-) So, I was able to test your patch from #c8, sadly it > still does the same thing: When I use the "airspy" argument without any > value, it does not find any actual devices. It works fine when I use > "airspy=0". Could you post your gcc version and architecture? Also what it writes to the stderr? "Attempting to open airspy by s/n=...." I think I can rewrite the patch to be more robust, but at first I would like to understand what's going there. I will probably open gcc bug, maybe it's just undefined behavior and not a bug. I probably got it. It seems there was an gcc bug in the gcc-10, but it seem they fixed in the gcc-11. My hack was targeted to the gcc-10. I will provide new version of the patch. Created attachment 1832251 [details]
Proposed fix
Updated version of the patch, that should address the problem with no serial number given.
Thanks Jaroslav, the last patch (from #c15) seems to work fine and does not seem to contain the regression anymore. :-) Any chance you could also submit this patch upstream (probably as an attachment here: https://osmocom.org/issues/5144)? By the way, my gcc version is 11.2.1 20210728 on latest Fedora 35 Workstation beta for x86_64. (In reply to Daniel Rusek from comment #16) > Thanks Jaroslav, the last patch (from #c15) seems to work fine and does not > seem to contain the regression anymore. :-) > > Any chance you could also submit this patch upstream (probably as an > attachment here: https://osmocom.org/issues/5144)? I added comment to the upstream tracker. FEDORA-2021-3fffc46710 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3fffc46710 FEDORA-2021-3fffc46710 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report. |