From: Thomas Hellstrom <thomas@shipmail.org>
To: "Robert Högberg" <robert@kladdkaka.nu>
Cc: dri-devel@lists.sourceforge.net
Subject: Re: Failing via_cmdbuf_wait
Date: Fri, 05 Feb 2010 21:53:18 +0100 [thread overview]
Message-ID: <4B6C853E.50308@shipmail.org> (raw)
In-Reply-To: <20100205000855.3b995f96.robert@kladdkaka.nu>
Robert Högberg wrote:
> Hello.
>
> I'm trying to debug an issue I'm having with my Via CN400 board. The problem I see is that every time I watch a specific DVD using XvMC the display freezes completely after a short time.
>
> The freeze seems to be caused by a failing via_cmdbuf_wait. I don't understand why it fails, but it fails with the error message:
> *ERROR* via_cmdbuf_wait timed out hw 32700 cur_addr 400 next_addr 87678
>
> And all following calls give the same output. It never recovers.
>
> Any ideas where I should look now? If the buffer isn't emptied as expected, is it a hardware problem? There seems to be no error handling in via_cmdbuf_jump if via_cmdbuf_wait fails. Is it missing or is this situation so fatal that it can't be fixed or is it ok to just move along and ignore the problem?
>
> There's also a pretty huge delay inside via_cmdbuf_wait. In a worst case scenario it will sleep 1000000*1ms (1000 seconds). Is that how it should be? Seems strange to me.
>
> All hints are appreciated!
>
> /Robert
>
Hi, Robert.
What you're seeing is a GPU hang, Either because of a bug in the kernel
module or perhaps a hardware bug. The AGP DMA code is a bit shaky in the
via drm. That has been fixed in the experimental openChrome drm, (but
that driver suite doesn't support XvMC yet). The fixes haven't been
ported over.
/Thomas
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
prev parent reply other threads:[~2010-02-05 20:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-04 23:08 Failing via_cmdbuf_wait Robert Högberg
2010-02-05 20:53 ` Thomas Hellstrom [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B6C853E.50308@shipmail.org \
--to=thomas@shipmail.org \
--cc=dri-devel@lists.sourceforge.net \
--cc=robert@kladdkaka.nu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.