Cinergy T2 stopped working with kernel 2.6.30

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 channel.

Is there anyone for whom dvb_usb_cinergyT2 of kernel 2.6.30 or later does work?

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 60db56422043aaa455ac7f858ce23c273220f9d9 (good) and commit be0ea69674ed95e1e98cb3687a241badc756d228 (good) yielding commit 6e15cf04860074ad032e88c306bea656bbdd0f22 (bad).

So, the problem is probably interrupt-related, not dvb-usb-related. Any idea on how to continue from here?

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                 cannot tune
CONFIG_MCORE2    |    cannot tune           cannot tune

These results are for my Atom N270 board. On my Core2 board, the Cinergy T2 works all the time.

By applying -march=i486 and -march=i586 to individual source files, I found out that dvb_frontend.c is the culprit.

By editing the assembly output for dvb_frontend.c, I found out that only dvb_frontend_swzigzag_autotune() needs to be compiled with CONFIG_M486 to make the Cinergy T2 work, everything else can be compiled with CONFIG_M586.

Both compiled versions of dvb_frontend_swzigzag_autotune() look OK (but I haven't yet strictly verified the assembly code). Anyway, nothing in that code should make a difference on N270 vs. Core, except for timing. Adding NOPs doesn't seem to make a difference.

Any ideas? Could this be a CPU bug?

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?

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             failure    ok
 2             ok         ok
 3             failure    failure
 4             failure    ok
 5             ok         ok
 6             ok         ok
 7             ok         ok
 8             ok         failure
 9             failure    ok
10             ok         ok
11             ok         failure
12             failure    ok
13             ok         ok
14             ok         ok
15             ok         ok
16             ok         ok
17             ok         ok
18             ok         failure
19             ok         failure
20             failure    ok

There's a pattern with some exceptions. Could be an alignment-related problem.

Anyone listening?

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?

Oops, there was no instance of mythweb being able to tune, but mplayer not being able to tune. Sorry.

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->demodulator_priv;
	struct dvbt_set_parameters_msg param;
	char result[2];
	int err;

	param.cmd = CINERGYT2_EP1_SET_TUNER_PARAMETERS;
	param.tps = cpu_to_le16(compute_tps(fep));
	param.freq = cpu_to_le32(fep->frequency / 1000);
	param.bandwidth = 8 - fep->u.ofdm.bandwidth - BANDWIDTH_8_MHZ;

	err = dvb_usb_generic_rw(state->d,
			(char *)&param, sizeof(param),
			result, sizeof(result), 0);

------------------------------------------------------------------------

As dvbt_set_parameters_msg is declared with __attribute__((packed)), its alignment is 8 bits. In fact, cinergyt2_fe_set_frontend()'s param variable is not aligned on a 32-bit boundary. Note that param is passed to usb_bulk_msg(). This seems to cause DMA problems on my hardware (Atom N270 + 945GSE + ICH7M).

I hope that I'm not talking to a black hole.

Unfortunately, aligning cinergyt2_fe_set_frontend()'s param and result on a 32-bit boundary doesn't help.

Apparently, usb_bulk_msg() cannot be used with data on the stack:

http://www.linuxtv.org/pipermail/linux-dvb/2008-August/028150.html
http://www.mail-archive.com/[email protected]/msg19158.html

As far as I recall this has been documented for ages already... Although many people stumble over it... last but not least there's no reason to have USB drivers in the kernel anyway..

Markus

I doubt that. AFAIK EHCI has no alignment requirements on data, and the x86 architecture has DMA consistent caches. The code in question is broken on ARM. MIPS etc. but it should work (and according to you has worked up to 2.6.29) on x86. (I'm not at all against fixing the code for MIPS/ARM but I don't think that would fix the problem for you.)

Initialize param.flags.

---
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 pass buffers on the stack to the USB layer, I leave fixing that to others. This patch is against 2.6.30.

@@ -275,6 +275,7 @@ static int cinergyt2_fe_set_frontend(str
 	param.tps = cpu_to_le16(compute_tps(fep));
 	param.freq = cpu_to_le32(fep->frequency / 1000);
 	param.bandwidth = 8 - fep->u.ofdm.bandwidth - BANDWIDTH_8_MHZ;
+	param.flags = 0;
 
 	err = dvb_usb_generic_rw(state->d,
 			(char *)&param, sizeof(param),