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 <[EMAIL PROTECTED]>
> To: Rui Sousa <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
>
>
>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 <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
