Users report that this patch:
https://www.redhat.com/archives/fedora-devel-list/2004-June/msg00072.html
is still needed to eliminate audio underruns for Radeon users.
Any news on this?
Lee
On Sat, 2006-02-25 at 20:36 -0500, Lee Revell wrote:
> Users report that this patch:
>
> https://www.redhat.com/archives/fedora-devel-list/2004-June/msg00072.html
>
> is still needed to eliminate audio underruns for Radeon users.
>
> Any news on this?
You mean on the plain vanilla stable kernel tree? Users running what?
I'm using 2.6.15-rt18 currently on radeon machines (9250 chipset) with
no problems that I can see.
-- Fernando
On Sat, 2006-02-25 at 18:33 -0800, Fernando Lopez-Lezcano wrote:
> On Sat, 2006-02-25 at 20:36 -0500, Lee Revell wrote:
> > Users report that this patch:
> >
> > https://www.redhat.com/archives/fedora-devel-list/2004-June/msg00072.html
> >
> > is still needed to eliminate audio underruns for Radeon users.
> >
> > Any news on this?
>
> You mean on the plain vanilla stable kernel tree? Users running what?
>
Presumably.
> I'm using 2.6.15-rt18 currently on radeon machines (9250 chipset) with
> no problems that I can see.
We don't want to require the -rt kernel to use JACK at modest latencies,
that's like killing a fly with a gun.
Lee
On Sat, 2006-02-25 at 20:36 -0500, Lee Revell wrote:
> Users report that this patch:
>
> https://www.redhat.com/archives/fedora-devel-list/2004-June/msg00072.html
>
> is still needed to eliminate audio underruns for Radeon users.
>
> Any news on this?
well that patch is not working (it's already in the mail, it schedules
with spinlocks ;)
the other angle is that you're trading 3D performance vs audio
performance....
Lee Revell <[email protected]> wrote:
>
> Users report that this patch:
>
> https://www.redhat.com/archives/fedora-devel-list/2004-June/msg00072.html
>
> is still needed to eliminate audio underruns for Radeon users.
That's a 2.6.4 patch which generates 100% rejects.
But still, if that patch helped and didn't throw a billion might_sleep()
and people were using preemptible kernels then we have a lock_kernel()
problem. A suitable fix would be to make sure all the locking's tight and
to convert DRM to use unlocked_ioctl.
On Sun, 2006-02-26 at 01:44 -0800, Andrew Morton wrote:
> Lee Revell <[email protected]> wrote:
> >
> > Users report that this patch:
> >
> > https://www.redhat.com/archives/fedora-devel-list/2004-June/msg00072.html
> >
> > is still needed to eliminate audio underruns for Radeon users.
>
> That's a 2.6.4 patch which generates 100% rejects.
>
> But still, if that patch helped and didn't throw a billion might_sleep()
> and people were using preemptible kernels then we have a lock_kernel()
> problem.
lock_kernel() is a semaphore nowadays.... unless those people just
turned that off, at which point.. their problem ;)
On Sun, 2006-02-26 at 10:13 +0100, Arjan van de Ven wrote:
> On Sat, 2006-02-25 at 20:36 -0500, Lee Revell wrote:
> > Users report that this patch:
> >
> > https://www.redhat.com/archives/fedora-devel-list/2004-June/msg00072.html
> >
> > is still needed to eliminate audio underruns for Radeon users.
> >
> > Any news on this?
>
> well that patch is not working (it's already in the mail, it schedules
> with spinlocks ;)
>
Understood, your response indicated that you would investigate a proper
solution.
> the other angle is that you're trading 3D performance vs audio
> performance....
>
AFAICT it's more like trading 3D performance for having audio work at
all. Other video drivers that were too aggressive and caused audio
dropouts (VIA) were fixed, even though there was a slight performance
cost.
Lee
On Sun, 2006-02-26 at 10:57 +0100, Arjan van de Ven wrote:
> lock_kernel() is a semaphore nowadays.... unless those people just
> turned that off, at which point.. their problem ;)
>
Thanks I will check on this.
Lee
> AFAICT it's more like trading 3D performance for having audio work at
> all. Other video drivers that were too aggressive and caused audio
> dropouts (VIA) were fixed, even though there was a slight performance
> cost.
In addition, the radeon DRI shouldn't do active spinning like that in
"normal" circumstances ... it should instead block on interrupts. if it
does, I suppose that could safely be considered as a bug in the radeon
DRM/DRI driver. It will do such loops on engine reset and such, which
happen on X launch, VT switches or in case of lockups... I have to
double check what happens in the code path used for 2d/3d transitions
though, those might be a problem.
Ben.
On Mon, 2006-02-27 at 08:11 +1100, Benjamin Herrenschmidt wrote:
> > AFAICT it's more like trading 3D performance for having audio work at
> > all. Other video drivers that were too aggressive and caused audio
> > dropouts (VIA) were fixed, even though there was a slight performance
> > cost.
>
> In addition, the radeon DRI shouldn't do active spinning like that in
> "normal" circumstances ... it should instead block on interrupts. if it
> does, I suppose that could safely be considered as a bug in the radeon
> DRM/DRI driver. It will do such loops on engine reset and such, which
> happen on X launch, VT switches or in case of lockups... I have to
> double check what happens in the code path used for 2d/3d transitions
> though, those might be a problem.
What about switching from 2D->3D mode, like when xscreensaver kicks in?
IIRC people reported audio underruns when that happened but I could
never narrow it down any further.
If as Arjan said the only lock this driver takes is the BKL then it's
either a local config issue (ancient kernel or failure to enable preempt
BKL) or something at the hardware level... I'm waiting for more info
from the original reporter.
Lee
>
> Thanks I will check on this.
>
I don't suppose they are running with X renice -10?
or some such.. that was done by a few vendors previously.. if X is
using hw accel, then it will be in the DRM driver a bit...
Dave.
On Mon, 2006-02-27 at 08:31 +1100, Dave Airlie wrote:
> >
> > Thanks I will check on this.
> >
>
> I don't suppose they are running with X renice -10?
>
> or some such.. that was done by a few vendors previously.. if X is
> using hw accel, then it will be in the DRM driver a bit...
Radeon uses DRI for regular 2D XAA acceleration? That's good to know.
This is not very common right?
Lee
On 2/27/06, Lee Revell <[email protected]> wrote:
> On Mon, 2006-02-27 at 08:31 +1100, Dave Airlie wrote:
> > >
> > > Thanks I will check on this.
> > >
> >
> > I don't suppose they are running with X renice -10?
> >
> > or some such.. that was done by a few vendors previously.. if X is
> > using hw accel, then it will be in the DRM driver a bit...
>
> Radeon uses DRI for regular 2D XAA acceleration? That's good to know.
>
> This is not very common right?
Common in what sense? all radeons that have DRM enabled use the CP to
do 2D XAA accel, the drm is the interface to the CP, granted it
doesn't do a huge amount of work, X sets up all the accel in an
indirect buffer, and just tells the DRM where the buffer starts.. so
it isn't doing a lot in the kernel.
Dave.
>
> Lee
>
>
On Sun, 2006-02-26 at 16:31 -0500, Lee Revell wrote:
> On Mon, 2006-02-27 at 08:11 +1100, Benjamin Herrenschmidt wrote:
> > > AFAICT it's more like trading 3D performance for having audio work at
> > > all. Other video drivers that were too aggressive and caused audio
> > > dropouts (VIA) were fixed, even though there was a slight performance
> > > cost.
> >
> > In addition, the radeon DRI shouldn't do active spinning like that in
> > "normal" circumstances ... it should instead block on interrupts. if it
> > does, I suppose that could safely be considered as a bug in the radeon
> > DRM/DRI driver. It will do such loops on engine reset and such, which
> > happen on X launch, VT switches or in case of lockups... I have to
> > double check what happens in the code path used for 2d/3d transitions
> > though, those might be a problem.
>
> What about switching from 2D->3D mode, like when xscreensaver kicks in?
> IIRC people reported audio underruns when that happened but I could
> never narrow it down any further.
Well... as soon as a 3d window appears, the server starts switching all
the time. there might be some spin loop in there remaining...
> If as Arjan said the only lock this driver takes is the BKL then it's
> either a local config issue (ancient kernel or failure to enable preempt
> BKL) or something at the hardware level... I'm waiting for more info
> from the original reporter.
Ben.
On Mon, 2006-02-27 at 09:53 +1100, Benjamin Herrenschmidt wrote:
> Well... as soon as a 3d window appears, the server starts switching
> all the time. there might be some spin loop in there remaining...
But if the only lock taken in the radeon driver is the BKL, the
SCHED_NORMAL X server should not be able to delay a SCHED_FIFO process
right?
Lee
On Sun, 2006-02-26 at 18:02 -0500, Lee Revell wrote:
> On Mon, 2006-02-27 at 09:53 +1100, Benjamin Herrenschmidt wrote:
> > Well... as soon as a 3d window appears, the server starts switching
> > all the time. there might be some spin loop in there remaining...
>
> But if the only lock taken in the radeon driver is the BKL, the
> SCHED_NORMAL X server should not be able to delay a SCHED_FIFO process
> right?
If you have preempt enabled, I suppose .... can we preempt with the BKL
nowadays ?
On Mon, 2006-02-27 at 11:18 +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2006-02-26 at 18:02 -0500, Lee Revell wrote:
> > On Mon, 2006-02-27 at 09:53 +1100, Benjamin Herrenschmidt wrote:
> > > Well... as soon as a 3d window appears, the server starts switching
> > > all the time. there might be some spin loop in there remaining...
> >
> > But if the only lock taken in the radeon driver is the BKL, the
> > SCHED_NORMAL X server should not be able to delay a SCHED_FIFO process
> > right?
>
> If you have preempt enabled, I suppose .... can we preempt with the BKL
> nowadays ?
Yes.
This seems to have been user error - old kernel and/or broken config.
Until I get more feedback from the user, this can probably be
disregarded.
Lee