dri-devel October 2011

dri-devel@lists.freedesktop.org

82 participants
530 discussions

[Bug 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901
by bugzilla-daemon＠freedesktop.org 30 Oct '11

30 Oct '11

https://bugs.freedesktop.org/show_bug.cgi?id=35460 --- Comment #8 from Bruno <bonbons67(a)internet.lu> 2011-10-30 05:55:23 PDT --- (In reply to comment #7) > I've just tried to reproduce this running firefox+chromium+others under e17 > using SNA. I'm pretty certain this was the tiling bugs we fixed early. I've not seen them recently either, except for sporadically a pixel line with with white/gray pixels in the e17 cursor. (always at same place of the cursor, more or less middle in height). Might be there is one tiling bug remaining around cursor handling. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

2 1

[Bug 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901
by bugzilla-daemon＠freedesktop.org 30 Oct '11

30 Oct '11

https://bugs.freedesktop.org/show_bug.cgi?id=35460 Chris Wilson <chris(a)chris-wilson.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #7 from Chris Wilson <chris(a)chris-wilson.co.uk> 2011-10-30 05:44:20 PDT --- I've just tried to reproduce this running firefox+chromium+others under e17 using SNA. I'm pretty certain this was the tiling bugs we fixed early. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[ANNOUNCE] libdrm 2.4.27
by Eric Anholt 29 Oct '11

29 Oct '11

Ben Widawsky (1): intel: shared header for shader debugging Chih-Wei Huang (1): Specify the return type explicitly. Daniel Vetter (2): drm/intel: don't clobber bufmgr->pci_device drm/i915: y tiling on i915G/i915GM is different Dave Airlie (3): drm/test: handle usub being empty drmtest: make check should fail so hard on unable to open device nouveau: free in error path if drmAvailable fails. Eric Anholt (6): intel: Use stdbool.h for dealing with boolean values. intel: Add an interface for removing relocs after they're added. intel: Remove stale comment. intel: Don't call the SW_FINISH ioctl unless a CPU-mapped write was done. intel: Share the implementation of BO unmap between CPU and GTT mappings. configure: version bump for 2.4.27 release. Jakob Bornecrantz (5): tests: Add vmwgfx driver to probed drivers in tests vbltest: Check error codes returned from libdrm modetest: Check error message from pageflip ioctl modetest: Print extra info if we fail to create a framebuffer modetest: Call dirty fb on modeset Jesse Barnes (1): modetest: use 24 bit depth on the framebuffer Marcin Slusarz (2): drm mode: fix drmIoctl wrapper nouveau: assert argument cannot have side effects Matt Turner (1): modeprint.c: use PRIu64 for printing uint64_t Tapani Pälli (1): xf86drm.h : wrap C code for C++ compilation/linking Yuanhan Liu (1): intel: fix the wrong method check for bo_get_subdata git tag: 2.4.27 http://dri.freedesktop.org/libdrm/libdrm-2.4.27.tar.bz2 MD5: 0fba4f42735cd3d24dd7a8cde0023fbd libdrm-2.4.27.tar.bz2 SHA1: f5b40d30a7f2bfa369ab9b3bd9a0aa844a7f1e16 libdrm-2.4.27.tar.bz2 SHA256: ea6b04dd3298e36c7a43aadd5f80f48baeafe4caaabcf78b01dc919c5c757973 libdrm-2.4.27.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.27.tar.gz MD5: 235dd2e75d0286a91019cd3aec1b4b47 libdrm-2.4.27.tar.gz SHA1: 2dd6005e2a7e2f186d7b5780fc5e0143d18f90e7 libdrm-2.4.27.tar.gz SHA256: 9f11d369925222c013773ad7ec0812feb4f5388e70a8ef0f729251f956acd7bf libdrm-2.4.27.tar.gz ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World now supports Android Apps for the BlackBerry® PlayBook. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev -- _______________________________________________ Dri-devel mailing list Dri-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel

1 0

[PATCH v2] drm: do not sleep on vblank while holding a mutex
by Ilija Hadzic 29 Oct '11

29 Oct '11

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 vblanks between the current and the one it is waiting for. In some cases it can block the entire windowing system. So, make this ioctl DRM_UNLOCKED, wrap the remaining (very short) critical section with dev->vbl_lock spinlock, and add a comment to the code explaining what we are protecting with the lock. v2: incorporate comments received from Daniel Vetter and Michel Daenzer. Signed-off-by: Ilija Hadzic <ihadzic(a)research.bell-labs.com> --- drivers/gpu/drm/drm_drv.c | 2 +- drivers/gpu/drm/drm_irq.c | 14 +++++++++++++- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index e159f17..c990dab 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -124,7 +124,7 @@ static struct drm_ioctl_desc drm_ioctls[] = { DRM_IOCTL_DEF(DRM_IOCTL_SG_ALLOC, drm_sg_alloc_ioctl, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY), DRM_IOCTL_DEF(DRM_IOCTL_SG_FREE, drm_sg_free, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY), - DRM_IOCTL_DEF(DRM_IOCTL_WAIT_VBLANK, drm_wait_vblank, 0), + DRM_IOCTL_DEF(DRM_IOCTL_WAIT_VBLANK, drm_wait_vblank, DRM_UNLOCKED), DRM_IOCTL_DEF(DRM_IOCTL_MODESET_CTL, drm_modeset_ctl, 0), diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 3830e9e..c8b4da8 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -1160,6 +1160,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data, union drm_wait_vblank *vblwait = data; int ret = 0; unsigned int flags, seq, crtc, high_crtc; + unsigned long irqflags; if ((!drm_dev_to_irq(dev)) || (!dev->irq_enabled)) return -EINVAL; @@ -1193,6 +1194,13 @@ int drm_wait_vblank(struct drm_device *dev, void *data, } seq = drm_vblank_count(dev, crtc); + /* 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 different CRTCs */ + /* do not need to be interlocked, but rather than introducing */ + /* a new per-crtc lock, we reuse vbl_lock for simplicity */ + spin_lock_irqsave(&dev->vbl_lock, irqflags); switch (vblwait->request.type & _DRM_VBLANK_TYPES_MASK) { case _DRM_VBLANK_RELATIVE: vblwait->request.sequence += seq; @@ -1200,12 +1208,15 @@ int drm_wait_vblank(struct drm_device *dev, void *data, case _DRM_VBLANK_ABSOLUTE: break; default: + spin_unlock_irqrestore(&dev->vbl_lock, irqflags); ret = -EINVAL; goto done; } - if (flags & _DRM_VBLANK_EVENT) + if (flags & _DRM_VBLANK_EVENT) { + spin_unlock_irqrestore(&dev->vbl_lock, irqflags); return drm_queue_vblank_event(dev, crtc, vblwait, file_priv); + } if ((flags & _DRM_VBLANK_NEXTONMISS) && (seq - vblwait->request.sequence) <= (1<<23)) { @@ -1215,6 +1226,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data, DRM_DEBUG("waiting on vblank count %d, crtc %d\n", vblwait->request.sequence, crtc); dev->last_vblank_wait[crtc] = vblwait->request.sequence; + spin_unlock_irqrestore(&dev->vbl_lock, irqflags); DRM_WAIT_ON(ret, dev->vbl_queue[crtc], 3 * DRM_HZ, (((drm_vblank_count(dev, crtc) - vblwait->request.sequence) <= (1 << 23)) || -- 1.7.7

2 5

[PATCH] drm: add some comments to drm_wait_vblank and drm_queue_vblank_event
by Ilija Hadzic 29 Oct '11

29 Oct '11

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 flows in the code, to prevent "false alarms" in the future Signed-off-by: Ilija Hadzic <ihadzic(a)research.bell-labs.com> --- drivers/gpu/drm/drm_irq.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index c8b4da8..e9dd19d 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -1065,6 +1065,10 @@ out: return ret; } +/* must acquire vblank reference count (call drm_vblank_get) */ +/* before calling this function; the matching drm_vblank_put */ +/* will either be issued here or in drm_handle_vblank_events */ +/* after the vblank is signaled */ static int drm_queue_vblank_event(struct drm_device *dev, int pipe, union drm_wait_vblank *vblwait, struct drm_file *file_priv) @@ -1124,6 +1128,9 @@ static int drm_queue_vblank_event(struct drm_device *dev, int pipe, trace_drm_vblank_event_delivered(current->pid, pipe, vblwait->request.sequence); } else { + /* can't call drm_vblank_put here because interrupt */ + /* must remain enabled until the event occurs */ + /* drm_handle_vblank_events will do this for us */ list_add_tail(&e->base.link, &dev->vblank_event_list); vblwait->reply.sequence = vblwait->request.sequence; } @@ -1215,6 +1222,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data, if (flags & _DRM_VBLANK_EVENT) { spin_unlock_irqrestore(&dev->vbl_lock, irqflags); + /* drm_queue_vblank_event() will call drm_vblank_put() */ return drm_queue_vblank_event(dev, crtc, vblwait, file_priv); } -- 1.7.7

2 1

[Bug 36386] New: Amnesia game crashes on RV570 (r300g)
by bugzilla-daemon＠freedesktop.org 29 Oct '11

29 Oct '11

https://bugs.freedesktop.org/show_bug.cgi?id=36386 Summary: Amnesia game crashes on RV570 (r300g) Product: Mesa Version: 7.10 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: vand2(a)gmx.de The game Amnesia crashes after a startup screen with a silvery sun symbol displayed. glxinfo | grep string server glx vendor string: SGI server glx version string: 1.2 client glx vendor string: Mesa Project and SGI client glx version string: 1.4 OpenGL vendor string: X.Org R300 Project OpenGL renderer string: Gallium 0.4 on ATI RV570 OpenGL version string: 2.1 Mesa 7.10.2 OpenGL shading language version string: 1.20 gdb backtrace Program received signal SIGSEGV, Segmentation fault. 0x000000000082ab08 in hpl::iParticleEmitter::GetMaterial() () #0 0x000000000082ab08 in hpl::iParticleEmitter::GetMaterial() () #1 0x0000000000805de2 in hpl::iRenderer::RenderObjectZAndAddToRenderList(hpl::iRenderable*) () #2 0x0000000000805e59 in hpl::iRenderer::RenderObjectZAndAddToRenderListStaticCallback(hpl::iRenderer*, hpl::iRenderable*) () #3 0x0000000000807d8f in hpl::iRenderer::RenderAndAddNodeObjects(hpl::iRenderableContainerNode*, bool (*)(hpl::iRenderer*, hpl::iRenderable*), unsigned int) () #4 0x000000000080808a in hpl::iRenderer::CheckForVisibleObjectsAddToListAndRenderZ(hpl::cVisibleRCNodeTracker*, unsigned int, unsigned int, bool, bool (*)(hpl::iRenderer*, hpl::iRenderable*)) () #5 0x00000000007e4841 in hpl::cRendererDeferred::RenderObjects() () #6 0x0000000000809334 in hpl::iRenderer::Render(float, hpl::cFrustum*, hpl::cWorld*, hpl::cRenderSettings*, hpl::cRenderTarget*, bool, std::list<hpl::iRendererCallback*, std::allocator<hpl::iRendererCallback*> >*) () #7 0x000000000082496d in hpl::cScene::Render(float, unsigned int) () #8 0x0000000000925423 in hpl::cEngine::Run() () #9 0x0000000000689890 in hplMain(std::string const&) () #10 0x000000000090ff29 in main () -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 5

[patch] drm/radeon/benchmark: signedness bug in radeon_benchmark_move()
by Dan Carpenter 29 Oct '11

29 Oct '11

radeon_benchmark_do_move() returns an int so "time" should be int too. Making it unsigned breaks the error handling. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c b/drivers/gpu/drm/radeon/radeon_benchmark.c index 5cafc90..17e1a9b 100644 --- a/drivers/gpu/drm/radeon/radeon_benchmark.c +++ b/drivers/gpu/drm/radeon/radeon_benchmark.c @@ -98,7 +98,7 @@ static void radeon_benchmark_move(struct radeon_device *rdev, unsigned size, struct radeon_bo *sobj = NULL; uint64_t saddr, daddr; int r, n; - unsigned int time; + int time; n = RADEON_BENCHMARK_ITERATIONS; r = radeon_bo_create(rdev, size, PAGE_SIZE, true, sdomain, &sobj);

1 0

[Bug 29951] New: [r300g] xscreensaver hack "antspotlight" reveals something other than desktop
by bugzilla-daemon＠freedesktop.org 29 Oct '11

29 Oct '11

https://bugs.freedesktop.org/show_bug.cgi?id=29951 Summary: [r300g] xscreensaver hack "antspotlight" reveals something other than desktop Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: rankincj(a)googlemail.com Created an attachment (id=38368) --> (https://bugs.freedesktop.org/attachment.cgi?id=38368) What the ant saw... The xscreensaver hack "antspotlight" is supposed to depict an ant with a spotlight on its head wandering over your desktop in the dark. The idea is that the ant reveals little patches of your desktop as it wanders around. With r300g and my RV350, the ant is most definitely not revealing my desktop. (Not this time, anyway. It seems to be random.) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 20

[PATCH v2] drm: make DRM_UNLOCKED ioctls with their own mutex
by Ilija Hadzic 29 Oct '11

29 Oct '11

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->struct_mutex. drm_getstats: there is no need for any mutex here because the loop runs through quasi-static (set at load time only) data, and the actual count access is done with atomic_read() drm_getmap already uses dev->struct_mutex to protect dev->maplist, which also used to protect the same structure everywhere else except at three places: * drm_getsarea, which doesn't grab *any* mutex before touching dev->maplist (so no drm_global_mutex doesn't help here either; different issue for a different patch). However, drivers seem to call it only at initialization time so it probably doesn't matter * drm_master_destroy, which is called from drm_master_put, which in turn is protected with dev->struct_mutex everywhere else in drm module, so we are good here too. * drm_getsareactx, which releases the dev->struct_mutex too early, but this patch includes the fix for that. v2: * incorporate comments received from Daniel Vetter * include the (long) explanation above to make it clear what we are doing (and why), also at Daniel Vetter's request * tighten up mutex grab/release locations to only encompass real critical sections, rather than some random code around them Signed-off-by: Ilija Hadzic <ihadzic(a)research.bell-labs.com> --- drivers/gpu/drm/drm_context.c | 5 +++-- drivers/gpu/drm/drm_drv.c | 6 +++--- drivers/gpu/drm/drm_ioctl.c | 15 ++++----------- 3 files changed, 10 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c index 6d440fb..325365f 100644 --- a/drivers/gpu/drm/drm_context.c +++ b/drivers/gpu/drm/drm_context.c @@ -154,8 +154,6 @@ int drm_getsareactx(struct drm_device *dev, void *data, return -EINVAL; } - mutex_unlock(&dev->struct_mutex); - request->handle = NULL; list_for_each_entry(_entry, &dev->maplist, head) { if (_entry->map == map) { @@ -164,6 +162,9 @@ int drm_getsareactx(struct drm_device *dev, void *data, break; } } + + mutex_unlock(&dev->struct_mutex); + if (request->handle == NULL) return -EINVAL; diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index c990dab..dc0eb0b 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -64,9 +64,9 @@ static struct drm_ioctl_desc drm_ioctls[] = { DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, 0), DRM_IOCTL_DEF(DRM_IOCTL_GET_MAGIC, drm_getmagic, 0), DRM_IOCTL_DEF(DRM_IOCTL_IRQ_BUSID, drm_irq_by_busid, DRM_MASTER|DRM_ROOT_ONLY), - DRM_IOCTL_DEF(DRM_IOCTL_GET_MAP, drm_getmap, 0), - DRM_IOCTL_DEF(DRM_IOCTL_GET_CLIENT, drm_getclient, 0), - DRM_IOCTL_DEF(DRM_IOCTL_GET_STATS, drm_getstats, 0), + DRM_IOCTL_DEF(DRM_IOCTL_GET_MAP, drm_getmap, DRM_UNLOCKED), + DRM_IOCTL_DEF(DRM_IOCTL_GET_CLIENT, drm_getclient, DRM_UNLOCKED), + DRM_IOCTL_DEF(DRM_IOCTL_GET_STATS, drm_getstats, DRM_UNLOCKED), DRM_IOCTL_DEF(DRM_IOCTL_GET_CAP, drm_getcap, DRM_UNLOCKED), DRM_IOCTL_DEF(DRM_IOCTL_SET_VERSION, drm_setversion, DRM_MASTER), diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index 904d7e9..956fd38 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -158,14 +158,11 @@ int drm_getmap(struct drm_device *dev, void *data, int i; idx = map->offset; - - mutex_lock(&dev->struct_mutex); - if (idx < 0) { - mutex_unlock(&dev->struct_mutex); + if (idx < 0) return -EINVAL; - } i = 0; + mutex_lock(&dev->struct_mutex); list_for_each(list, &dev->maplist) { if (i == idx) { r_list = list_entry(list, struct drm_map_list, head); @@ -211,9 +208,9 @@ int drm_getclient(struct drm_device *dev, void *data, int i; idx = client->idx; - mutex_lock(&dev->struct_mutex); - i = 0; + + mutex_lock(&dev->struct_mutex); list_for_each_entry(pt, &dev->filelist, lhead) { if (i++ >= idx) { client->auth = pt->authenticated; @@ -249,8 +246,6 @@ int drm_getstats(struct drm_device *dev, void *data, memset(stats, 0, sizeof(*stats)); - mutex_lock(&dev->struct_mutex); - for (i = 0; i < dev->counters; i++) { if (dev->types[i] == _DRM_STAT_LOCK) stats->data[i].value = @@ -262,8 +257,6 @@ int drm_getstats(struct drm_device *dev, void *data, stats->count = dev->counters; - mutex_unlock(&dev->struct_mutex); - return 0; } -- 1.7.7

2 1

Re: [PATCH 3/3] drm: do not sleep on vblank while holding a mutex
by Mario Kleiner 28 Oct '11

28 Oct '11

> Message: 5 > Date: Fri, 28 Oct 2011 11:30:38 +0200 > From: Daniel Vetter <daniel(a)ffwll.ch> > Subject: Re: [PATCH 3/3] drm: do not sleep on vblank while holding a > mutex > To: Ilija Hadzic <ihadzic(a)research.bell-labs.com> > Cc: dri-devel(a)lists.freedesktop.org > Message-ID: <20111028093038.GB2919(a)phenom.ffwll.local> > Content-Type: text/plain; charset=us-ascii >> >>> - Imo we also have a few too many atomic ops going on, e.g. >>> dev->vblank_refcount looks like it's atomic only because or the >>> procfs >>> file, so maybe kill that procfs file entirely. >> >> I am not sure about that. dev->vblank_refcount looks critical to me: >> it is incremented through drm_vblank_get which is called from >> several different contexts: page-flip functions in several drivers >> (which can run in the context of multiple user processes), **_pm_** >> stuff in radeon driver (which looks like it runs in the context of >> kernel worker thread). Mutexes used at all these different places >> are not quite consistent. If anything, as the result of a later >> audit, some other mutexes may be rendered unecessary, but >> definitely, I would keep vblank_refcount atomic. > Hi, 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. > I've re-read the code a bit and in _get it's protected by dev- > >vbl_lock, > but not so in _put (because we issue a timer call to actually > switch it > off). I think we could just shove it under the protection of dev- > >vbl_lock > completely. Another fuzzzy area is the relation between dev- > >vbl_lock and > dev->vblank_time_lock. The latter looks a bit rendundant. > The vblank_time_lock serves a different purpose from vbl_lock. It is used in the vblank irq handler drm_handle_vblank() and in the vblank irq on/off functions to protect the vblank timestamping and counting against races between the irq handler and the on/off code, and some funny races between the cpu reinitializing vblank counts and timestamps in non-irq path and the gpu firing vblank interrupts and/ or updating its hardware vblank counter at the "wrong" moment. vblank_time_lock basically blocks/delays gpu vblank irq processing during such problematic periods. Timing there is criticial for reliable vblank timestamping, kms page flipping and artifact free dynamic gpu power-management. It should be locked as seldomly and held as short as possible. I initially tried to get away only with vbl_lock, but there were uses of vbl_lock that looked as if using it in the interrupt handler as well could cause long delays in irq processing. thanks, -mario ********************************************************************* Mario Kleiner Max Planck Institute for Biological Cybernetics Spemannstr. 38 72076 Tuebingen Germany e-mail: mario.kleiner(a)tuebingen.mpg.de office: +49 (0)7071/601-1623 fax: +49 (0)7071/601-616 www: http://www.kyb.tuebingen.mpg.de/~kleinerm ********************************************************************* "For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." (Richard Feynman)

2 2

← Newer
1
...
35
36
37
38
39
40
41
...
53
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2011