i810 kernel driver vs 7012
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 23 lines · John Fremlin
Quoted 3 lines · Doug Ledford
I think we are chasing one last bit of "flaky" behaviour on the SiS chipset.
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
Quoted 2 lines
Tomorrow, can you rerun this same test
You might say today is already tomorrow <groan>
Quoted 5 lines
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.
Quoted 7 lines
Quoted 3 lines
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 http://people.redhat.com/dledford/i810_audio.c.gz)
Signature · 3 lines
Doug Ledford <[email protected]> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems
Doug Ledford <[email protected]> writes:
[...]
Quoted 1 line
Problem identified. It was a combination of two things. In
[...]
Quoted 3 lines
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.
Works just super. Not an overrun in sight anywhere! Please submit it for the kernel(s) so I don't have to apply yet another patch :-)
Thanks for nailing the problems, Doug! You must have put in a lot of time on this yesterday and it was almost a pleasure to run those tests because of the speed with which you came up with patches. Thanks once again!
[Of course also qudos and thanks to Thomas Gschwind who got the SiS 7012 going in the first place!]
[...]
Signature · 1 line
http://john.fremlin.de