> Doug Ledford <firstname.lastname@example.org> writes:
>>I think we are chasing one last bit of "flaky" behaviour on the SiS
> To my untutored eye it looks like some sort of timing issue. I had
> more trouble getting hold of a dma overrun with debugging compiled
> in. My IRQ is shared with eth0 but I once ifdowned eth0 and got
> broadly similar sound effects and problems
>>Tomorrow, can you rerun this same test
> You might say today is already tomorrow <groan>
>>with debug interrupts enabled and send me the output. All I need is
>>one dma overrun to be able to track it I think. The other thing
>>that might be helpful is debug2. A run with both interrupt and
>>debug2 enabled would probably pinpoint the real problem.
>>BTW, I don't get *any* overruns here doing anything with xmms, artsd,
>>esd, or using sox or cat to play a wav file.
> I had to play my beetle file a few times to get one this time :-( This
> trace is just of the beetle file being played. For your enjoyment I
> also attach the beetle file
Problem identified. It was a combination of two things. In drain_dac() we
were calling update_ptr() *after* setting our task state to
TASK_INTERRUPTIBLE. Well, the way that wait queues work is that when
update_ptr() kept calling wake_up() because we had more than 1 userfragsize
of space available to write it would clear our task state back to
TASK_RUNNING before we would ever call schedule_timeout(). The result is
that in drain_dac() we would go into a very tight loop of never sleeping and
always updating things waiting for the dma to finish. That was problem 1.
Problem 2 was that in get_hardware_addr() we were finding a bug the SiS
hardware. Basically on the SiS stuff we were catching the hardware in
updates to the sg segment it was dma'ing. With a slight change to the
routine to cause it to delay slightly and then recheck the hardware to make
sure that what it reads is consistent, the problem should be solved.
Anyway, a new 0.18 version of the driver is up on my site. It should solve
*all* of the particular problems you were seeing. Let me know how it works.
Also, thanks for spending soooo much time getting me the traces and stuff
you did John. It was what allowed me to find these two issues.
(For the people on linux-kernel's benefit, the site again is
Doug Ledford <email@example.com> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/