[ I think this should have been posted to linux-media@xxxxxxxxxxxxxxx instead ] Marko Ristola <marko.ristola@xxxxxxxxxxx> writes: > Hello all interested in a robust Mantis driver. > > I have done some Mantis DMA fixes about two to four years ago > into v4l-dvb/linux/drivers/dvb/media/mantis/mantis_dma.c, > but they were discarded then, but the problems remained. > Those fixes helped at least one individual with Cinergy C PCI HD card > too by lessening the number > of artifacts and making the card usable. I sent the patches for many > Finnish people at those years. I find this very interesting. I have two DVB-C cards, where one of them is a Terratec Cinergy C, and I do see the occasional stuck CPUs. Never realized that the mantis driver might be the cause of that. > For Mauro and other maintainers - the patch in this email is now > against current Mercurial http://linuxtv.org/hg/v4l-dvb branch. > What do you think about this patch? Could you apply it? > I accept that this code may be added to Linux Kernel, or somewhere > else, licensed as GPLv2. > This code is fully written by me (Marko Ristola). > Signed-off-by: Marko Ristola <marko.ristola@xxxxxxxxxxx> I am not Mauro (or other maintainers :-), but I guess you will have a much better chance getting this properly reviewed if you move to git, split up the patch according to your very good 4 point description, and use that description as a commit message for the patches. This will also allow the rest of us to test the effect of each issue independently. > The patch does two things (other two things are just thoughts, related > to robustness): > 1. Don't flush 64K garbage at stream start, occurs if mantis_dma_start > is run more than once. > This fix could be done with altering only about two lines of code by > fixing the broken DMA RISC program code. > (Bug description: At line[0] RISC IRQ will store line=15 on current > code, causing copying of lines between 0 and 14, and next time 15 from > previous DVB TS stream (total 64K garbage). After that line=0 contains > current stream, no garbage. > Bug fix description: RISC program must store at interrupt the active > line variable's value, instead of ( (line - 1) mod 16)). This sounds like a real bug. Maybe a candidate for stable as well? > On my patch, it seems, that risc_step=0 point could be used for the > interrupt instead of risc_step=1, thus making the code a bit easier to > understand. > > 2. Alter DMA transfer so, that each DMA transfer copies only complete > packets (either 188 or 204 bytes) with each DMA transfer. > The hypothesis is that if a DMA transfer transfers only a part of the > 188/204 sized packet, > that packet gets corrupted (last bytes of 2048 sized block). > My DMA transfers are aligned by 64 bytes in CPU memory (DMA buffer > start + multiple of 16x(188 or 204)). I cannot really understand how such corruption could happen, unless there are other bugs here? And if there are, then anything hiding them would be bad... > 3. tasklet_enable/ tasklet_disable for DMA start/stop is commented out > on my patch. > I think that tasklet enabling maintenance should be done at these > points, but I don't know > whether the lack of those might cause spin lock failures. Lack of > these might > cause problems while switching channels (EPG search switches frequency). Sounds reasonable. Did you try it? > 4. There is some problem with rmmod mantis, do lsmod: > Module Size Used by > tda10021 5486 4294967291 > modprobe mantis > tda10021 5486 4294967292 mantis > So the reference count from mantis to tda10021 gets corrupted at rmmod. > I have Fedora 13 kernel, 2.6.33.5-124.fc13.x86_64 FWIW, I do not see this running a Debian kernel (2.6.32-5-amd64) with a backported mantis driver (from 2.6.35-rc1). Module Size Used by tda10021 4774 1 mantis # rmmod mantis tda10021 4774 0 # modprobe mantis tda10021 4774 1 mantis > The second modification is the reason for the big number of changes. > This is also the patch, that isn't easily acceptable, because it is hard > to proof that the packets do get corrupted at DMA transfer cutting > points, or that the hard lockups/reboots are caused > by the DMA transfer misalignment by 188/204 bytes. > The reasoning for the fix is, that without this alignment change there > were too many artefacts (VDR DVB > recordings lost sound after a while, thus VDR recording feature was > unusable). This sounds a bit like magic to me. Any idea why such a change would make any difference? > But with these modifications on recordings the sound was > usable. Picture artefacts weren't so fatal at real time, even > though on Windows side there were much less picture artefacts. I haven't really thought much about artefacts, but I do notice a sharp high pitched sound now and then. Might be a symptom? > For historical reasons, I need still to modprobe mantis by hand, > and then the drivers get probed and loaded. Usually PCI device drivers > get loaded automatically. You are aware of the patch at http://jusst.de/hg/mantis-v4l-dvb/rev/3731f71ed6bf ? Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
