Rui Sousa wrote:
>
> Hi,
>
> I'm posting this again since I didn't get an answer for the problem
> and also because now I have better information.
>
> As the subject states the problem appeared with kernel 2.3.43,
> and it seems to affect SMP machines only (well at least no report
> yet involving UP).
>
> Basically a task queued in the tq_immediate queue is never run
> and seems to stay in the queue forever. I debugged the driver side
The problem was traced to a corruption in the tasklet list and Jeff Defouw
found the real reason:
>Subject: Re: [Emu10k1-devel] Unable to play any sound through dsp
> Date: Sat, 26 Feb 2000 06:13:54 -0500 (EST)
> From: Jeff DeFouw <defouwj@purdue.edu>
> To: Rui Sousa <rsousa@grad.physics.sunysb.edu>
> CC: emu10k1-devel@opensource.creative.com
>
>
>Solution found. It's not a kernel bug after all. We need to add the CPU
>type to the CFLAGS somehow. "-DCPU=686" in my case. On 586 and 686 CPU
>types the L1_CACHE_BYTES is set to 32 instead of 16, which directly sets
>SMP_CACHE_BYTES. SMP_CACHE_BYTES is used for the per-cpu tasklet list
>byte alignment. On SMP 586 and 686 systems only the first tasklet list
>was being aligned correctly, so when cpu 0 happened to be used there were
>no problems. Once the cpu 1 tasklet list was used, the emu10k1 module
>wrote to the wrong address and bad things happened. The compiler adjusted
>the address for the wrong array increment for the byte alignment. The
>driver's working great now on my system. Now to figure out the best way
>to get the kernel source's -DCPU=xxx ...
>
>--
>Jeff DeFouw <defouwj@purdue.edu>
So I would suggest either always use a 32 bytes alignment for the tasklet list
or state in the config help file that the 586 option is no longer forward
compatible in SMP systems.
Rui Sousa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:15 EST