On Sat, Oct 29, 2011 at 2:25 AM, Daniel Vetter wrote:
> On Sat, Oct 29, 2011 at 12:47:18AM +0200, Tormod Volden wrote:
>> On Thu, Oct 27, 2011 at 1:07 PM, Daniel Vetter
>> wrote:
>> ...
>> > @@ -139,13 +99,35 @@ static int sis_drm_alloc(struct drm_device *dev,
>> > struct drm_file *file,
>> ...
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Robert Nelson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Oct 28, 2011, at 9:15 PM, Daniel Vetter wrote:
> On Fri, Oct 28, 2011 at 08:15:11PM +0200, Mario Kleiner wrote:
>> be careful with vblank_refcount. I think it probably should stay
>> atomic. The drm_vblank_put() is often used in interrupt handlers of
>> the kms drivers where you don't want to u
On Sat, 29 Oct 2011, Daniel Vetter wrote:
>> +/* the lock protects this section from itself executed in */
>> +/* the context of another PID, ensuring that the process that */
>> +/* wrote dev->last_vblank_wait is really the last process */
>> +/* that was here; processes waiting
On Fri, Oct 28, 2011 at 01:56:39PM +0100, Chris Wilson wrote:
> On Fri, 28 Oct 2011 20:22:35 +0800, Yong Zhang
> wrote:
> > Hi,
> >
> > Just got below error on Ubuntu-11.10 (kernel: 3.0.0-12-generic),
> > and after that my screen can't show normally.
> > No sure if it's a known issue.
>
> No, t
On Fri, Oct 28, 2011 at 08:15:11PM +0200, Mario Kleiner wrote:
> be careful with vblank_refcount. I think it probably should stay
> atomic. The drm_vblank_put() is often used in interrupt handlers of
> the kms drivers where you don't want to uneccessary wait on a lock,
> but be as quick as possible
Hi,
Just got below error on Ubuntu-11.10 (kernel: 3.0.0-12-generic),
and after that my screen can't show normally.
No sure if it's a known issue.
[169509.080020] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed...
GPU hung
[169509.080026] [drm] capturing error event; look for more in
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #6 from Alex Deucher 2011-10-28 13:17:15 PDT
---
Created attachment 52866
--> https://bugs.freedesktop.org/attachment.cgi?id=52866
possible fix
patch 2/2. Do these patches help?
--
Configure bugmail: https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher changed:
What|Removed |Added
CC||feth at tuttu.info
--- Comment #4 from Al
> Message: 5
> Date: Fri, 28 Oct 2011 11:30:38 +0200
> From: Daniel Vetter
> Subject: Re: [PATCH 3/3] drm: do not sleep on vblank while holding a
> mutex
> To: Ilija Hadzic
> Cc: dri-devel at lists.freedesktop.org
> Message-ID: <20111028093038.GB2919 at phenom.ffwll.local>
> Content-Type: t
On Sat, 29 Oct 2011, Daniel Vetter wrote:
+ /* the lock protects this section from itself executed in */
+ /* the context of another PID, ensuring that the process that */
+ /* wrote dev->last_vblank_wait is really the last process */
+ /* that was here; processes waitin
https://bugs.freedesktop.org/show_bug.cgi?id=29951
Tom Stellard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=36934
--- Comment #17 from auxsvr at gmail.com 2011-10-28 11:26:57 PDT ---
I'm afraid the virtualbox modules have nothing to do with this.
A hopefully helpful observation:
When I first load the large image in firefox, zooming in and out several times
https://bugs.freedesktop.org/show_bug.cgi?id=36609
Tom Stellard changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=36609
Tom Stellard changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
On Fri, Oct 28, 2011 at 05:43:28PM -0400, Ilija Hadzic wrote:
> drm_getclient, drm_getstats and drm_getmap (with a few minor
> adjustments) do not need global mutex, so fix that and
> make the said ioctls DRM_UNLOCKED. Details:
>
> drm_getclient: the only thing that should be protected here
>
On Fri, Oct 28, 2011 at 5:52 PM, wrote:
> From: Jerome Glisse
>
> Polarity needs to be set accordingly to connector status (connected
> or disconnected). Set it up at module init so first hotplug works
> reliably no matter what is the initial set of connector.
>
> Signed-off-by: Jerome Glisse
>
https://bugs.freedesktop.org/show_bug.cgi?id=36386
Tom Stellard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Fri, Oct 28, 2011 at 05:42:23PM -0400, Ilija Hadzic wrote:
> drm_wait_vblank must be DRM_UNLOCKED because otherwise it
> will grab the drm_global_mutex and then go to sleep until the vblank
> event it is waiting for. That can wreck havoc in the windowing system
> because if one process issues th
From: Jerome Glisse
Polarity needs to be set accordingly to connector status (connected
or disconnected). Set it up at module init so first hotplug works
reliably no matter what is the initial set of connector.
Signed-off-by: Jerome Glisse
cc: stable at kernel.org
---
drivers/gpu/drm/radeon/ra
during the review of the fix for locks problems in drm_wait_vblank,
a couple of false concerns were raised about how the drm_vblank_get
and drm_vblank_put are used in this function; it turned out that the
code is correct and that it cannot be simplified
add a few comments to explain non-obvious fl
drm_getclient, drm_getstats and drm_getmap (with a few minor
adjustments) do not need global mutex, so fix that and
make the said ioctls DRM_UNLOCKED. Details:
drm_getclient: the only thing that should be protected here
is dev->filelist and that is already protected everywhere with
dev->stru
drm_wait_vblank must be DRM_UNLOCKED because otherwise it
will grab the drm_global_mutex and then go to sleep until the vblank
event it is waiting for. That can wreck havoc in the windowing system
because if one process issues this ioctl, it will block all other
processes for the duration of all vb
On Sat, Oct 29, 2011 at 12:47:18AM +0200, Tormod Volden wrote:
> On Thu, Oct 27, 2011 at 1:07 PM, Daniel Vetter wrote:
> ...
> > @@ -139,13 +99,35 @@ static int sis_drm_alloc(struct drm_device *dev,
> > struct drm_file *file,
> ...
> > +#if defined(CONFIG_FB_SIS) || defined(CONFIG_FB_SIS_MODULE)
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #15 from Michal 2011-10-28 10:13:15 PDT
---
FBTexPercent to 97
bash-4.1$ cat /var/log/Xorg.0.log|grep text
[ 8077.238] (II) RADEON(0): Will use 114688 kb for textures at offset
0x00c08000
etracer runs smoothly at 40 fps(with mesa 7
On Fri, Oct 28, 2011 at 07:10:51AM -0500, Ilija Hadzic wrote:
> I'll keep it then and figure out the best mutex/spinlock to use. It
> can be anything that exists on one-per-CRTC basis (vblank waits on
> different CTCs are not contending). The critical section is from
> that switch in which vblwait-
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #14 from Michal 2011-10-28 09:44:56 PDT
---
Minimum GARTSize which don't return fallbacks is 16MB.
Now, the problem is somewhere at the kernel side.
samples| %|
--
1295082 93.6410 vmlinux
30154 2.1803 r
From: Tormod Volden
---
On top of danvet's kill-with-fire ad83cc3.
Tormod
drivers/gpu/drm/sis/sis_mm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sis/sis_mm.c b/drivers/gpu/drm/sis/sis_mm.c
index 112a43b..63c2f75 100644
--- a/drivers/gpu/drm/si
On Thu, Oct 27, 2011 at 1:07 PM, Daniel Vetter wrote:
...
> @@ -139,13 +99,35 @@ static int sis_drm_alloc(struct drm_device *dev, struct
> drm_file *file,
...
> +#if defined(CONFIG_FB_SIS) || defined(CONFIG_FB_SIS_MODULE)
> + item->req.size = mem->size;
> + sis_malloc(
On Fri, Oct 28, 2011 at 5:52 PM, wrote:
> From: Jerome Glisse
>
> Polarity needs to be set accordingly to connector status (connected
> or disconnected). Set it up at module init so first hotplug works
> reliably no matter what is the initial set of connector.
>
> Signed-off-by: Jerome Glisse
>
From: Jerome Glisse
Polarity needs to be set accordingly to connector status (connected
or disconnected). Set it up at module init so first hotplug works
reliably no matter what is the initial set of connector.
Signed-off-by: Jerome Glisse
cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/radeo
during the review of the fix for locks problems in drm_wait_vblank,
a couple of false concerns were raised about how the drm_vblank_get
and drm_vblank_put are used in this function; it turned out that the
code is correct and that it cannot be simplified
add a few comments to explain non-obvious fl
drm_getclient, drm_getstats and drm_getmap (with a few minor
adjustments) do not need global mutex, so fix that and
make the said ioctls DRM_UNLOCKED. Details:
drm_getclient: the only thing that should be protected here
is dev->filelist and that is already protected everywhere with
dev->stru
drm_wait_vblank must be DRM_UNLOCKED because otherwise it
will grab the drm_global_mutex and then go to sleep until the vblank
event it is waiting for. That can wreck havoc in the windowing system
because if one process issues this ioctl, it will block all other
processes for the duration of all vb
On Fri, 28 Oct 2011 20:22:35 +0800, Yong Zhang wrote:
> Hi,
>
> Just got below error on Ubuntu-11.10 (kernel: 3.0.0-12-generic),
> and after that my screen can't show normally.
> No sure if it's a known issue.
No, that is the first time I've seen that. It looks as if the fence was
not released,
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #13 from Roland Scheidegger 2011-10-28
06:49:59 PDT ---
(In reply to comment #12)
> csm->gart_limit and csm->vram_limit are correct.
>
> With GARTSize "64", openarena works great. ETRacer does not (but no fallbacks)
> In ETRacer, wh
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #51 from Ilija Hadzic
2011-10-28 06:25:40 PDT ---
(In reply to comment #49)
> (In reply to comment #48)
> > > first) and apply the patch as 'patch -p1 name_of_the_patch.patch'
> >
> > Typo, it should be
> >
> >
> > patch -p1 < nam
Looks like this patch got missed. Dave can you add it and CC: stable?
Alex
On Wed, May 25, 2011 at 2:02 PM, Alex Deucher wrote:
> This should make eDP more reliable.
>
> Signed-off-by: Alex Deucher
> ---
> ?drivers/gpu/drm/radeon/atombios_dp.c | ? 11 +++
> ?include/drm/drm_dp_helper.h
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #6 from Alex Deucher 2011-10-28 13:17:15 PDT ---
Created attachment 52866
--> https://bugs.freedesktop.org/attachment.cgi?id=52866
possible fix
patch 2/2. Do these patches help?
--
Configure bugmail: https://bugs.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher changed:
What|Removed |Added
CC||f...@tuttu.info
--- Comment #4 from Alex
On Oct 28, 2011, at 9:15 PM, Daniel Vetter wrote:
On Fri, Oct 28, 2011 at 08:15:11PM +0200, Mario Kleiner wrote:
be careful with vblank_refcount. I think it probably should stay
atomic. The drm_vblank_put() is often used in interrupt handlers of
the kms drivers where you don't want to uneccessa
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #50 from Siganderson 2011-10-28 05:42:37 PDT
---
I forgot to say that without touching anything in the window there are no
changes (60 fps... obviously 60 is the maximum when vsync is on).
--
Configure bugmail: https://bugs.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #49 from Siganderson 2011-10-28 05:39:21 PDT
---
(In reply to comment #48)
> > first) and apply the patch as 'patch -p1 name_of_the_patch.patch'
>
> Typo, it should be
>
>
> patch -p1 < name_of_the_patch.patch
> ^
>
>
On Fri, Oct 28, 2011 at 08:15:11PM +0200, Mario Kleiner wrote:
> be careful with vblank_refcount. I think it probably should stay
> atomic. The drm_vblank_put() is often used in interrupt handlers of
> the kms drivers where you don't want to uneccessary wait on a lock,
> but be as quick as possible
On Thu, Oct 27, 2011 at 10:19:39PM -0500, Ilija Hadzic wrote:
> On Thu, 27 Oct 2011, Daniel Vetter wrote:
> >The only really hairy thing going on is racing modeset ioctls against
> >vblank waiters. But modeset is protected by the dev->mode_config.mutex
> >and hence already races against wait_vblank
https://bugs.freedesktop.org/show_bug.cgi?id=36934
--- Comment #17 from aux...@gmail.com 2011-10-28 11:26:57 PDT ---
I'm afraid the virtualbox modules have nothing to do with this.
A hopefully helpful observation:
When I first load the large image in firefox, zooming in and out several times
wo
On Fri, 28 Oct 2011 10:56:29 -0700
Keith Packard wrote:
> Kernels with no iommu support cannot ever need the Ironlake
> work-around, so never enable it in that case.
>
> Might be better to completely remove the work-around from the kernel
> in this case?
>
> Signed-off-by: Keith Packard
> Cc:
On Fri, 28 Oct 2011 10:56:29 -0700
Keith Packard wrote:
> Kernels with no iommu support cannot ever need the Ironlake
> work-around, so never enable it in that case.
>
> Might be better to completely remove the work-around from the kernel
> in this case?
>
> Signed-off-by: Keith Packard
> Cc:
On Fri, Oct 28, 2011 at 08:59:04AM +0200, Michel D?nzer wrote:
> On Don, 2011-10-27 at 22:19 -0500, Ilija Hadzic wrote:
> > On Thu, 27 Oct 2011, Daniel Vetter wrote:
> >
> > > So I think the right thing to do is
> > > - Kill dev->last_vblank_wait (in a prep patch).
> >
> > Agreed. Also drm_vblan
Message: 5
Date: Fri, 28 Oct 2011 11:30:38 +0200
From: Daniel Vetter
Subject: Re: [PATCH 3/3] drm: do not sleep on vblank while holding a
mutex
To: Ilija Hadzic
Cc: dri-devel@lists.freedesktop.org
Message-ID: <20111028093038.GB2919@phenom.ffwll.local>
Content-Type: text/plain; charset=us
Better fix it before this obvious typo spreads even more.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_fence.c | 34
drivers/gpu/drm/radeon/radeon_pm.c|4 +-
Only check the previously checked relocs for
duplicates. Also leaving the handle uninitialized
isn't such a good idea.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_cs.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_
Having registered debugfs files globally causes
the files to not show up on the second, third
etc.. card in the system.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h|8
drivers/gpu/drm/radeon/radeon_device.c | 26 ++--
The following three patches are just minor bug fixes.
I've send them to the list previously, but this time they are based upon
drm-next instead of drm-fixes and I also fixed some spelling mistakes in the
commit messages.
Please commit. Thanks,
Christian.
Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.
Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: Keith Packard
Cc: Ben Widawsky
---
Here's a shorter patch which just elides the body of th
Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.
Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: Keith Packard
Cc: Ben Widawsky
---
Here's a shorter patch which just elides the body of th
Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.
Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: Keith Packard
Cc: Ben Widawsky
---
drivers/char/agp/intel-gtt.c |4
1 files chang
Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.
Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: Keith Packard
Cc: Ben Widawsky
---
drivers/char/agp/intel-gtt.c |4
1 files chang
Looks like this patch got missed. Dave can you add it and CC: stable?
Alex
On Wed, May 25, 2011 at 2:02 PM, Alex Deucher wrote:
> This should make eDP more reliable.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/atombios_dp.c | 11 +++
> include/drm/drm_dp_helper.h
2011/10/28 Christian K?nig :
> Only check the previously checked relocs for
> duplicates. Also leaving the handle uninitialized
> isn't such a good idea.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
> ---
> ?drivers/gpu/drm/radeon/radeon_cs.c | ? ?5 +++--
> ?1 files changed, 3
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #15 from Michal 2011-10-28 10:13:15 PDT ---
FBTexPercent to 97
bash-4.1$ cat /var/log/Xorg.0.log|grep text
[ 8077.238] (II) RADEON(0): Will use 114688 kb for textures at offset
0x00c08000
etracer runs smoothly at 40 fps(with mesa 7.
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #14 from Michal 2011-10-28 09:44:56 PDT ---
Minimum GARTSize which don't return fallbacks is 16MB.
Now, the problem is somewhere at the kernel side.
samples| %|
--
1295082 93.6410 vmlinux
30154 2.1803 r2
On Don, 2011-10-27 at 22:19 -0500, Ilija Hadzic wrote:
> On Thu, 27 Oct 2011, Daniel Vetter wrote:
>
> > So I think the right thing to do is
> > - Kill dev->last_vblank_wait (in a prep patch).
>
> Agreed. Also drm_vblank_info function can go away
Actually, I was rather going to submit a patch t
On Fri, Oct 28, 2011 at 07:10:51AM -0500, Ilija Hadzic wrote:
> I'll keep it then and figure out the best mutex/spinlock to use. It
> can be anything that exists on one-per-CRTC basis (vblank waits on
> different CTCs are not contending). The critical section is from
> that switch in which vblwait-
2011/10/28 Christian König :
> Only check the previously checked relocs for
> duplicates. Also leaving the handle uninitialized
> isn't such a good idea.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_cs.c | 5 +++--
> 1 files changed, 3
On Fri, 28 Oct 2011, Daniel Vetter wrote:
> On Fri, Oct 28, 2011 at 08:59:04AM +0200, Michel D?nzer wrote:
>> On Don, 2011-10-27 at 22:19 -0500, Ilija Hadzic wrote:
>>> On Thu, 27 Oct 2011, Daniel Vetter wrote:
>>>
So I think the right thing to do is
- Kill dev->last_vblank_wait (in a
https://bugs.freedesktop.org/show_bug.cgi?id=42117
--- Comment #13 from Roland Scheidegger 2011-10-28
06:49:59 PDT ---
(In reply to comment #12)
> csm->gart_limit and csm->vram_limit are correct.
>
> With GARTSize "64", openarena works great. ETRacer does not (but no fallbacks)
> In ETRacer, wh
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #51 from Ilija Hadzic 2011-10-28
06:25:40 PDT ---
(In reply to comment #49)
> (In reply to comment #48)
> > > first) and apply the patch as 'patch -p1 name_of_the_patch.patch'
> >
> > Typo, it should be
> >
> >
> > patch -p1 < nam
On Fri, 28 Oct 2011 20:22:35 +0800, Yong Zhang wrote:
> Hi,
>
> Just got below error on Ubuntu-11.10 (kernel: 3.0.0-12-generic),
> and after that my screen can't show normally.
> No sure if it's a known issue.
No, that is the first time I've seen that. It looks as if the fence was
not released,
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #50 from Siganderson 2011-10-28 05:42:37 PDT ---
I forgot to say that without touching anything in the window there are no
changes (60 fps... obviously 60 is the maximum when vsync is on).
--
Configure bugmail: https://bugs.freedesk
https://bugs.freedesktop.org/show_bug.cgi?id=39202
--- Comment #49 from Siganderson 2011-10-28 05:39:21 PDT ---
(In reply to comment #48)
> > first) and apply the patch as 'patch -p1 name_of_the_patch.patch'
>
> Typo, it should be
>
>
> patch -p1 < name_of_the_patch.patch
> ^
>
>
On Fri, 28 Oct 2011, Daniel Vetter wrote:
On Fri, Oct 28, 2011 at 08:59:04AM +0200, Michel Dänzer wrote:
On Don, 2011-10-27 at 22:19 -0500, Ilija Hadzic wrote:
On Thu, 27 Oct 2011, Daniel Vetter wrote:
So I think the right thing to do is
- Kill dev->last_vblank_wait (in a prep patch).
Ag
On Thu, Oct 27, 2011 at 10:19:39PM -0500, Ilija Hadzic wrote:
> On Thu, 27 Oct 2011, Daniel Vetter wrote:
> >The only really hairy thing going on is racing modeset ioctls against
> >vblank waiters. But modeset is protected by the dev->mode_config.mutex
> >and hence already races against wait_vblank
On Fri, Oct 28, 2011 at 08:59:04AM +0200, Michel Dänzer wrote:
> On Don, 2011-10-27 at 22:19 -0500, Ilija Hadzic wrote:
> > On Thu, 27 Oct 2011, Daniel Vetter wrote:
> >
> > > So I think the right thing to do is
> > > - Kill dev->last_vblank_wait (in a prep patch).
> >
> > Agreed. Also drm_vblan
Better fix it before this obvious typo spreads even more.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_fence.c | 34
drivers/gpu/drm/radeon/radeon_pm.c|4 +-
The following three patches are just minor bug fixes.
I've send them to the list previously, but this time they are based upon
drm-next instead of drm-fixes and I also fixed some spelling mistakes in the
commit messages.
Please commit. Thanks,
Christian.
___
Only check the previously checked relocs for
duplicates. Also leaving the handle uninitialized
isn't such a good idea.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_cs.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_
Having registered debugfs files globally causes
the files to not show up on the second, third
etc.. card in the system.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h|8
drivers/gpu/drm/radeon/radeon_device.c | 26 ++--
https://bugs.freedesktop.org/show_bug.cgi?id=42090
Tom Stellard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
79 matches
Mail list logo
