New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TBS6285 V12M no signal #84
Comments
Silicon Labs Si2168 should be loading dvb-demod-si2168-b40-01.fw afaik. |
Is that an issue on my end or the driver end? It seems like the driver is specifically looking for that version of the firmware... Looking at my board, the chip label says "SI2168 20" on it. Are you sure about needing B40 firmware? |
Can't tell, Luis did not merge latest patch series for Si2168 and SI2157 yet. Are you running Debian Jessie? |
I'm running Gentoo (gentoo-sources-3.17.7) |
Well, you can try compiling from my repos, works for me. git clone git://github.com/bas-t/media_build.git -b arch And now, poweroff your system completely for a minute or so. After boot, it should work. |
Ok, the sed line is in two lines, should be on one line |
Thanks bas-t. But how does your repo differ from Luis' ? |
It is updated with the patch series that Luis does not have, also I synced 2157 with upstream, so it differs from Luis' branch. (I've sent Luis a PR for that, but he did not merge it yet) |
Ok thanks. I've currently got my own Gentoo ebuild which installs into a folder I've named "dvb-os" which gives the same result. @ljalves Is it possible to merge the above patches? |
FYI the output of w_scan with FE set to DVBT2 using dvb-fe-tool: (there should ~140 services) .... .... Info: no data from SDT(actual) Info: no data from PMT Info: no data from PMT Info: no data from PMT Info: no data from PMT Info: no data from PMT Info: no data from PMT Info: no data from PMT Info: no data from PMT Info: no data from PMT Info: no data from PMT Info: no data from NIT(actual) dumping lists (12 services) service_id 8258;(null):498000:B8:T:27500:1701=2:1702=eng@4,1703=eng:0;1731:0:8258:0:0:0 service_id 8325;(null):498000:B8:T:27500:1801=2:1802=eng@4,1803=eng:0;1831:0:8325:0:0:0 service_id 8357;(null):498000:B8:T:27500:1901=2:1902=eng@4,1903=eng:0;1931:0:8357:0:0:0 service_id 8448;(null):498000:B8:T:27500:1301=2:1302=eng@4,1303=eng:0;1331:0:8448:0:0:0 service_id 8452;(null):498000:B8:T:27500:1201=2:1202=eng@4,1203=eng:0;1231:0:8452:0:0:0 service_id 8500;(null):498000:B8:T:27500:1601=2:1602=eng@4,1603=eng:0;1631:0:8500:0:0:0 service_id 4287;(null):522000:B8:T:27500:201=2:202=eng@3,206=eng:0;205:0:4287:0:0:0 service_id 5632;(null):522000:B8:T:27500:0:1402=eng@3:0:0:5632:0:0:0 service_id 5760;(null):522000:B8:T:27500:0:1602=eng@3:0:0:5760:0:0:0 service_id 5888;(null):522000:B8:T:27500:0:1802=eng@3:0:0:5888:0:0:0 service_id 6848;(null):522000:B8:T:27500:0:1202=eng@3:0:0:6848:0:0:0 service_id 6912;(null):522000:B8:T:27500:0:1302=eng@3:0:0:6912:0:0:0 |
Looks like you're in the UK epon. I've got a 6281. TBS drivers work mostly okay for me with int_type=1, only issue I have is occasional pixelation when both tuners are in use. Did you have the same issue bas-t? (I vaguely remember you mentioning it somewhere) With ljalves drivers, DVBT seems to work okay, but not DVBT2. First dvbv5-zap failed to lock, second worked, but all subsequent attempts fail (but DVBT continues to work). I posted in another issue: I tried your arch branch today bas-t. Much the same result, only difference was that it was the first T2 zap attempt that locked. The T2 steams I did manage to capture suffer constant pixelation (you'll have to open the full size version to see!): |
@Compulsion |
@Epon : try the sed method in favour of the dvb-fe-thingy. You just might get lucky! |
@bas-t Hmm, should I set it to DVB-T or DVB-T2? |
Dunno, try one. Educated guess: DVB-T |
@bas-t It's a tricky one because here in the UK we use both DVB-T and DVB-T2. The latter are HD muxes only. |
@Epon However, you still have to load the right firmware. You may or may not remember: I've got a V12M too. In fact, that was the board Luis used to get this 6285 thing going. And I must say: thanks to Luis, I'm still going strong! I don't know for sure, but you can try (in one line) : sed -i 's/SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A/SYS_DVBT, SYS_DVBT2/' drivers/media/dvb-frontends/si2168.c This should support both DVB-T and DVB-T2 |
I realy don't know if the driver supports both DVB-T and DVB-T2 at the same time. I'm guessing it doesn't. So, if you need both systems, you best set one or two of the si2168 chips to DVB-T and the others to DVB-T2. Of course, that brings you back to the dvb-fe-thingy. |
@bas-t Looking at the image in my first post I'm thinking the firmware is correct.
@bas-t If this is true then it's a real shame and this driver won't be any good for me. It's simply too inefficient to have tuners restricted to either DVB-T or DVB-T2... :( |
I don't really know much (or anything) about these things but should it be much different to how all the DVB-S2 cards can handle both S and S2 broadcasts with the @ljalves drivers? |
I'm also have V12M 6285 board with Si2168-20 chip and tried today using DVB-T2 without any success.
TBS proprietary drivers work fine(I'm using CrazyCat's tree https://bitbucket.org/CrazyCat/linux-tbs-drivers). If I load proprietary drivers after opensource ones there are some warnings about demod command is not responding during load, but card starts working fine. I'm also have 6985 V11 board on the same machine, not tested it much but looks like working fine with this tree. |
I don't have access to a DVB-T2 mux so I can't help much... I would first ask if anyone using a card with those chips works ok with dvb-t2. |
I'll give it a try with mailing list. |
Just for FIY. Yesterday with latest branch I successfully tunned 6285 V12M board to our DVB-T2 muxes. No issues since then. Dunno whats changed in codebase from May. Interesting if it'll be more stable than proprietary driver with which I had "no data" stucks after 1-2 weeks of uptime. According to beholders forum silabs made new demod firmware patch specifically for Russian DVB-T2 muxes. But it is not clear if it even exist for si2168-a20, they are not using those chips and provide fix only for A30/B40. |
Closing - reopen if needed. |
IPv6 addresses which are used for tunnels are stored in a hash table with reference counting. When a new GRE tunnel is configured, the driver is notified and configures it in hardware. Currently, any change in the tunnel is not applied in the driver. It means that if the remote address is changed, the driver is not aware of this change and the first address will be used. This behavior results in a warning [1] in scenarios such as the following: # ip link add name gre1 type ip6gre local 2000::3 remote 2000::fffe tos inherit ttl inherit # ip link set name gre1 type ip6gre local 2000::3 remote 2000::ffff ttl inherit # ip link delete gre1 The change of the address is not applied in the driver. Currently, the driver uses the remote address which is stored in the 'parms' of the overlay device. When the tunnel is removed, the new IPv6 address is used, the driver tries to release it, but as it is not aware of the change, this address is not configured and it warns about releasing non existing IPv6 address. Fix it by using the IPv6 address which is cached in the IPIP entry, this address is the last one that the driver used, so even in cases such the above, the first address will be released, without any warning. [1]: WARNING: CPU: 1 PID: 2197 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2920 mlxsw_sp_ipv6_addr_put+0x146/0x220 [mlxsw_spectrum] ... CPU: 1 PID: 2197 Comm: ip Not tainted 5.17.0-rc8-custom-95062-gc1e5ded51a9a ljalves#84 Hardware name: Mellanox Technologies Ltd. MSN4700/VMOD0010, BIOS 5.11 07/12/2021 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x146/0x220 [mlxsw_spectrum] ... Call Trace: <TASK> mlxsw_sp2_ipip_rem_addr_unset_gre6+0xf1/0x120 [mlxsw_spectrum] mlxsw_sp_netdevice_ipip_ol_event+0xdb/0x640 [mlxsw_spectrum] mlxsw_sp_netdevice_event+0xc4/0x850 [mlxsw_spectrum] raw_notifier_call_chain+0x3c/0x50 call_netdevice_notifiers_info+0x2f/0x80 unregister_netdevice_many+0x311/0x6d0 rtnl_dellink+0x136/0x360 rtnetlink_rcv_msg+0x12f/0x380 netlink_rcv_skb+0x49/0xf0 netlink_unicast+0x233/0x340 netlink_sendmsg+0x202/0x440 ____sys_sendmsg+0x1f3/0x220 ___sys_sendmsg+0x70/0xb0 __sys_sendmsg+0x54/0xa0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: e846efe ("mlxsw: spectrum: Add hash table for IPv6 address mapping") Reported-by: Maksym Yaremchuk <maksymy@nvidia.com> Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/20220511115747.238602-1-idosch@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
I've re-opened this and removed posts from other issues to prevent them being brought off-topic.
However I have the following:
V12M TBS 6285 which I can't get any signal with.
My motherboard block diagram is like this:
Notice that the card is connected on PCIE4 through a PCI-E siwtch (PLX PEX 8747).
I've tried the card in PCIE3 and PCI7 i.e. not though a switch in case it was that that was causing the problems but the card isn't even recognized by the BIOS on those sockets!
I just tried with the latest repos, using firmware from both bas-t and OE repo with int_type=1 and int_type=0:
int_type=0: I can scan but get only some channel information but can't play and of the channels. TVHeadend reports a transport error:
int_type=1: I can scan but get no channel information at all and can't play any channels.
I'm not using IOMMU and I'm also doing a "full initialization" of the card to DVBT2 using dvb-fe-tool.
I've also tested just using w_scan and it finds things but never gets any channel information.
The official drivers work, however they're unstable (whole system tends to freeze after a few days of uptime).
Nothing appears to be working :(
Dmesg:
The text was updated successfully, but these errors were encountered: