Initialize param.flags.
Signed-off-by: Eberhard Mattes
---
Not setting param.flags was the real cause of the inability of the Cinergy T2
driver to tune under certain circumstances. Moving stuff from the stack to the
heap did not really solve the problem. As there are several other drivers which
t the frontend ops are entered by
only one thread at a time?
-emagick
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ot; member of that structure is not initialized
to zero (as was done by kzalloc)!
-emagick
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Johannes Stezenbach wrote:
There is a fair amount of code duplication. A better aproach would
be to allocate buffers once in cinergyt2_fe_attach()
(add them to struct cinergyt2_fe_state).
Yes, but first I have to investigate why tuning is still quite unreliable
(ie, more unreliable than in 2.
Here's a patch for cinergyT2-core.c:
--- a/drivers/media/dvb/dvb-usb/cinergyT2-fe.c 2009-06-10 05:05:27.0
+0200
+++ b/drivers/media/dvb/dvb-usb/cinergyT2-fe.c 2009-07-31 22:02:48.0
+0200
@@ -146,66 +146,103 @@
fe_status_t *status)
{
The patch I sent is incomplete, there are more instances of the same problem
in cinergyT2-core.c.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
There might be a more elegant solution, but this seems to work for me:
--- drivers/media/dvb/dvb-usb/cinergyT2-fe.c2009-06-10 05:05:27.0
+0200
+++ drivers/media/dvb/dvb-usb/cinergyT2-fe.c2009-07-31 22:02:48.0
+0200
@@ -146,66 +146,103 @@
I think I've found the problem:
static int cinergyt2_fe_set_frontend(struct dvb_frontend *fe,
struct dvb_frontend_parameters *fep)
{
struct cinergyt2_fe_state *state = fe->demodulato
I wrote:
Addendum: with 3 additional local variables and compiled for i486 mythweb fails
to
tune, but mplayer can tune. Note that I mentioned cases where mplayer can tune
but
mythweb fails to tune. Perhaps alignment in the user-mode stack is a factor.
Oops, there was no instance of mythweb b
Addendum: with 3 additional local variables and compiled for i486 mythweb fails
to
tune, but mplayer can tune. Note that I mentioned cases where mplayer can tune
but
mythweb fails to tune. Perhaps alignment in the user-mode stack is a factor.
Anyone listening?
--
To unsubscribe from this list:
I've added dummy 32-bit variables to dvb_frontend_swzigzag_autotune() to change
the
frame size. Here are the results for mythweb (can tune/cannot tune):
#variables i486 i586
0 ok failure
1 failureok
2 ok ok
3 failu
I've now compared the generated assembly code for
dvb_frontend_swzigzag_autotune()
built with CONFIG_M486 vs. CONFIG_M586. Both versions are correct, but the one
compiled
with -march=i586 (for which tuning does not work) uses more stack space (one
32-bit
word).
Does this ring any bells?
--
To
The more I look into this problem the stranger it becomes. I've compiled
the kernel for different CPUs:
|mplayer mythtv
-+
CONFIG_M486 |works works
CONFIG_M586 |works
There are two new discoveries about my Cinergy T2 problem:
- the Cinergy T2 works when attached to an Intel Core2 board, but doesn't work
when
attached to an Intel Atom N270 board (tuning times out)
- "git bisect" of the Linux kernel points to a bad merge of
commit 60db56422043aaa455ac7f858
My Cinergy T2 (T²) doesn't work with kernels 2.6.30, 2.6.30.1, and 2.6.31-rc3,
but it works with kernel 2.6.29. The kernel logs
dvb-usb: recv bulk message failed: -110
and the application (I've tried mythtv and mplayer) trying to access the DVB
receiver
times out when trying to tune to a cha
15 matches
Mail list logo
