From: <bug...@fr...> - 2007-06-15 03:44:59
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 br...@br... changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |br...@br... ------- Comment #8 from br...@br... 2007-06-14 20:44 PST ------- Another similar freeze with 3D apps on Unichrome has been reported with the KM400, which I assume is this same bug: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/118163 The user was able to workaround it by downgrading from mesa 6.5.2 to 6.5.1. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-06-25 11:18:23
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #9 from sha...@gm... 2007-06-25 04:18 PST ------- (In reply to comment #2) > The situation appears to be more complicated than I thought initially. I've did > additional debugging and now think that all games are suffering from the same > bug in a driver - the symptoms are quite similar. However, there are many ways > to "activate" this bug, so every game (or GL app in general) has it's own > workaround. For instance, in Trigger you should avoid GL_LINEAR_MIPMAP_LINEAR, > in Torcs you should disable GL_ALPHA_TEST when rendering multitextures (it is > always connected with textures somehow) and so on. Usually, the program hangs > between return statement and the next line of code, i.e. in the sample code below: > > int some_func() { > ... > printf("BEFORE\n"); > return 1; > } > ... > while (some_func) { > printf("AFTER\n"); > } > > you will see "BEFORE" line but not "AFTER". > > So, I've prepared a very simple demo program (see attachement) below which hangs > my computer. Hope it will help debugging driver. More details are in attachment > comments. I looked into this a bit more and I infer the following. I realise that you looked at the bug in terms of high-level errors at the mesa DRI code. I however, went lower than that to the exact root cause. My observations may be different from yours, but here I go. 1. Debugging into this using gdb caused a hard lock in the glFlush() portion of glx code, which in turn goes to the __mesa_Flush() in unichrome_dri.so. The locking happens at different points of the code and therefore I figured that it is an asynchronous event driven code that is causing this lock. 2. I finally went into the DRM portion of the code(libdrm) which ioctl's the kernel for running various kernel level code from user space. 3. Adding printk's to DRM code finally isolated the problem. There is a function in via_irq.c called via_driver_vblank_wait(), which is probably serviced when the VIA_IRQ_VBLANK_PENDING interrupt bit is set. It calls viadrv_acknowledge_irqs(). 4. This reads the VIA_INTERRUPTS_REG using the VIA_READ macro(which is a readl PCI post), 'or' it with the VIA_IRQ_VBLANK_PENDING bit. QUESTION: If it is interrupt driven, this bit should already be set. Why is it being set during acknowledge? Then it writes the VIA_INTERRUPTS_REG back using VIA_WRITE. 5. Looking at the sequence of printk's I see that VIA_READ and VIA_WRITE happens several times and that at one point VIA_READ simply locks. Observations: 1. Since this locking is happening in a mmio PCI Posting, it probably means there is some bus arbitration problems(memory space must be mapped to agpgart). So is the bug in agpgart? Or is there something in the hardware that says you cannot read and write to HW registers using PCI posts continuously and maybe you should introduce gaps or delays between READ's and WRITE's? 2. Since the hw is mmio, I would imagine that PCI posting(reading and writing together) although non-blocking would be properly handled by the bus aribitration queue. It would be a great help if we had the manufacturer specs. This is wierder because it happens only to a few via chipsets(Unichrome Pro B). 3. I think it must be related to certain HW timing differences between the chipsets. Matters are not helped by the fact that the bug seems to lie at kernel space where debugging is a lot more difficult. Debugging with Linice seems to be a good way of reducing wastage of time, but I don't think it is stable enough for the latest 2.6.x kernels. 4. Finally, just giving arbitray udelays do not seem to solve the problem. On the other hand, they just slow the system much more. And the VIA_READ still hangs. If it is a timing issue, then there is more to it than just simple delay between reading and writing of HW registers. 5. Would very much like someone, to go further into this, and if possible, get help from the DRI architects, as they maybe the best persons to deal with this problem, with or without HW specs for the chipset. Hope this helped in some way. I would love for comments or corrections on what I have written. It may happen that your code flow happens entirely differently. Please let me know if so. Hope this helps. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-06-25 12:31:16
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #10 from e_...@in... 2007-06-25 05:30 PST ------- (In reply to comment #9) First of all, thank you for the information: very nice job! I suspected it's something to deal with VBLANK IRQ - and now we know this for sure. This lock-up is often connected to timing issues in wikis so this partially support your conclusion. Unfortunately, I know a little about low-level hardware programming and can't imagine how to fix it but I'm sure the maintainer of this DRI driver (when it'll have one) would be be able to use your data to fix the problem. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-06-25 13:30:12
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #11 from sha...@gm... 2007-06-25 06:29 PST ------- (In reply to comment #10) > (In reply to comment #9) > First of all, thank you for the information: very nice job! I suspected it's > something to deal with VBLANK IRQ - and now we know this for sure. This lock-up > is often connected to timing issues in wikis so this partially support your > conclusion. Unfortunately, I know a little about low-level hardware programming > and can't imagine how to fix it but I'm sure the maintainer of this DRI driver > (when it'll have one) would be be able to use your data to fix the problem. > Thank you. It just occured to me that this could be in some way related to [Bug 8641] New: interrupts not properly handled for VIA K8M00 / UniChrome Pro. This bug has to do with setting and clearing of interrupts not working properly. And according to description, rewriting the status register does not clear the interrupt. And the kernel disables the IRQ too. So just maybe, if someone fixes this, our bug could be fixed too! Just a thought. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-06-25 13:37:36
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #12 from e_...@in... 2007-06-25 06:36 PST ------- > It just occured to me that this could be in some way related to [Bug 8641] New: interrupts not properly handled for VIA K8M00 / UniChrome Pro. It probably has something to do with it, but what's the bug number and/or Bugzilla where it was reported? Looking for #8641 in this Bugzilla leads to closed one: "xcb should provide (and use in generated C files) opcode defines." -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-06-25 13:43:12
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #13 from e_...@in... 2007-06-25 06:40 PST ------- (In reply to comment #12) > It probably has something to do with it, but what's the bug number and/or > Bugzilla where it was reported? Looking for #8641 in this Bugzilla leads to > closed one: "xcb should provide (and use in generated C files) opcode defines." I found it - it's in the kernel Bugzilla: http://www.mail-archive.com/dri...@li.../msg31026.html These problems look like being connected for me. I'm not a kernel hacker (although I've read both Linux Kernel Development, 2nd Edition and Understanding Linux Kernel ;-) but if you'd need someone with real hardware to help debugging, I'm ready to do this job. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-06-25 13:57:11
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #14 from sha...@gm... 2007-06-25 06:56 PST ------- (In reply to comment #13) > (In reply to comment #12) > > > It probably has something to do with it, but what's the bug number and/or > > Bugzilla where it was reported? Looking for #8641 in this Bugzilla leads to > > closed one: "xcb should provide (and use in generated C files) opcode defines." > > I found it - it's in the kernel Bugzilla: > http://www.mail-archive.com/dri...@li.../msg31026.html > > These problems look like being connected for me. I'm not a kernel hacker > (although I've read both Linux Kernel Development, 2nd Edition and > Understanding Linux Kernel ;-) but if you'd need someone with real hardware to > help debugging, I'm ready to do this job. > Thanks for your offer. We probably would need the real hardware to trigger the same kind of conditions needed to cause this failure. Your dmesg logs should report the error about IRQs as soon as X is loaded. I'm pretty sure we would all see the error message. I'm not a real kernel hacker either. ;-) It seems to me that if we approach this problem from both ends(both bugs) we may stand a better chance of solving this quickly. Although there is still the possiblity that they may entirely be unrelated. Another thing we can verify is to put printk's in the kernel in exactly the same way I said and run different games and 3d applications and verify that the same root cause persists. If they are the same, we get added confirmation about the root cause. We can, in the meantime continue working on this in our spare time and hope for a breakthrough quickly. What seems to be the priority to me is to eliminate libGL, libGLX and pinpoint the bug on the kernel DRM code. All my investigations point to it, but it is always good to be more sure. ;-) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-06-26 19:15:48
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #15 from sha...@gm... 2007-06-26 12:15 PST ------- Update: http://bugzilla.kernel.org/show_bug.cgi?id=8641 I have submitted a patch to this bug that deals with the IRQ interrupt bug. It seems to work, but sadly, this doesn't solve the lockup issue we face here. Maybe the two are not related. Can someone confirm the patch works? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-06-27 06:17:08
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #16 from e_...@in... 2007-06-26 23:16 PST ------- > Update: http://bugzilla.kernel.org/show_bug.cgi?id=8641 > I have submitted a patch to this bug that deals with the IRQ interrupt bug. It > seems to work, but sadly, this doesn't solve the lockup issue we face here. > Maybe the two are not related. Can someone confirm the patch works? Thanks for the information, I'll try to put the patch to work. In the meantime I 've seen no traces of spurious IRQ you've observed in dmesg output, so probably these to issues are really different (although IRQ handler definitely plays a role in both cases ;-). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-06-27 07:53:20
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #17 from sha...@gm... 2007-06-27 00:53 PST ------- I agree. The spurious interrupt issue was specifically for the K8M800 device, that is device id, 3108. So if you do not have this device, then you probably wouldn't see this issue. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-06-28 13:43:39
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #18 from sha...@gm... 2007-06-28 06:40 PST ------- Have an update for this. Please check http://bugzilla.kernel.org/show_bug.cgi?id=8641 (Sometimes the link is not resolved properly. So here it is again without the full url. bugzilla.kernel.org/show_bug.cgi?id=8641 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-06-28 14:26:00
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #19 from e_...@in... 2007-06-28 07:25 PST ------- (In reply to comment #18) > Have an update for this. Please check > http://bugzilla.kernel.org/show_bug.cgi?id=8641 > (Sometimes the link is not resolved properly. So here it is again without the > full url. bugzilla.kernel.org/show_bug.cgi?id=8641 > Sound sane to me. Have you seen http://sourceforge.net/docman/display_doc.php?docid=23693&group_id=102048 AFAIK there is noone around with the knowledge of VIA 3D spec so miss and try is the only way. Isn't it possible to check your conclusions by masking the annoying interrupt on PIC and enabling it, say, 10 times per second via dynamic timer? It's a huge hack but it will show the cause of the starvation (although I'm almost sure it's IRQ). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-06-28 14:28:39
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #20 from e_...@in... 2007-06-28 07:28 PST ------- > Sound sane to me. But the question is: why do we observe random lookups (i.e. one game runs fine second game locks up) if IRQ acknowledge code is incorrect? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-06-28 14:43:27
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #21 from sha...@gm... 2007-06-28 07:42 PST ------- Good question. ;-) I have no answers to that one. But notice that the bug is not at all random. The bug is fully reproducible each and everytime it happens, and in exactly the same way. Therefore, I can only speculate that in all the offending code, some action is being done in the code that causes a large number of VBLANK's. One operation would be a glFlush I think(which, incidently, seems to be the trigger for the small test case you have written in c). AFAIK it seems to me that a combination of calls that force a lot of VBLANK's seems to be the immediate trigger. Maybe the way the game uses and clears the texture memory or the way drawing is done on screen is responsible for this. In that case, this speculation makes some sense. Each application has different methods of drawing, texture manipulation etc. So a combination of different methods of calling the DRM handler may be the trigger to this. But again, your statement is very logical. If the IRQ ACK is not accurate, the interrupts should fire continuously, but it happens under only certain conditions. Again, note the critical change in behavior. No longer hard lock, but barely responsive. That means something is eating the processor cycles, maybe a sleeping spinlock in a thread or something similar. We have some work to do! ;-) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-06-28 18:52:53
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #22 from th...@tu... 2007-06-28 11:52 PST ------- Hi. The IRQ issue on K8M800 has been around for ages. I'm not saying it can't be fixed (sometimes when my K8M800 has been running for quite some time it will work nicely), but trying to initialize it from scratch it always fails. The reason is that K8M800 fires a huge amount of spurious interrupts. If irq debug is turned off, the handler slows down the machine considerably trying to handle the interrupts. The problem is probably a hardware bug. The same problem occurs on certain variants of KM400. I once asked via about it and they claimed that IRQ functionality was never verified on these chips since they didn't do video capture. Hence no use for IRQs in VIAs windows drivers. The only sane thing to do is to not enable IRQs for these chips. Regarding the texture lockup issue, the same code works much better on other chips with the same 3D engine. It might just be a memory timing issue on K8M800, which means that tracking it down using software can be very difficult. /Thomas -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-06-29 04:57:44
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #23 from sha...@gm... 2007-06-28 21:57 PST ------- Appreciate your comments. You may have saved us a long time in going off in some wrong direction. ;-) As of now, turning IRQ off in the X Driver causes more frequent lockups than before. Even a simple glxinfo is a candidate for this lockup. I know timing problems are hell of a lot difficult to find, but we have no choice. Lacking open specs from the manufacturer, we have to do some blind hit and misses to get it. Another thing, if it is a memory timing issue, I assume this will lockup during a readl, writel or during writes to some buffers. Maybe, if we can isolate this, we have a better chance to understand what the issue is. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-07-05 21:14:42
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #24 from th...@tu... 2007-07-05 14:04 PST ------- It's a little more complicated than that. The Unichromes have an AGP command queue which feeds a "Virtual Queue" in vram. If the lockup occurs during a texture read, it's hard to tell exactly what primitive caused it, because it may be in the middle of reading 2MB of data. The AGP command queue has never been completely stable, so first thing would be to turn that off. "EnableAGPDMA" to "false" would eliminate AGP-related lockups. Then the Virtual command queue can also be turned off using a 2D driver option, but I can't remember which ATM. After that, all command register writes should stall until the device is ready to accept them, which may help tracking this issue down. /Thomas -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-07-07 17:43:01
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #25 from sha...@gm... 2007-07-07 10:42 PST ------- Appreciate that piece of wisdom. :-) Will certainly try as you advise. Will keep posting on progress as and when time permits. Thanks again. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-12-18 07:10:58
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 gar...@gm... changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gar...@gm... ------- Comment #26 from gar...@gm... 2007-12-17 23:10 PST ------- Via released a new driver. Anyone tried it? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-12-18 10:00:27
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #27 from e_...@in... 2007-12-18 02:00 PST ------- > Via released a new driver. > Anyone tried it? Which one? AFAIK, Via drivers have nothing to do with DRI - please correct me if I'm wrong. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-12-18 10:11:11
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 li...@sk... changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Comment #28 from li...@sk... 2007-12-18 02:11 PST ------- VIA provides only binaries for DRI modules these days, so they should not be considered in the context of this bugreport. We are not even able to find the time to fix bugs in a free dri driver, so feel free to explain how we could support binary only drivers. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-12-18 17:02:20
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #29 from gar...@gm... 2007-12-18 09:02 PST ------- (In reply to comment #28) > VIA provides only binaries for DRI modules these days, so they should not be > considered in the context of this bugreport. We are not even able to find the > time to fix bugs in a free dri driver, so feel free to explain how we could > support binary only drivers. > [quote]stinke on Ubuntu lauchpad[/quote Okay, so someone has reported the new release in the DRI Mailing List [1] and it's been commented. It doesn't look like Valentine Sinitsyn and Luc Verhaegen have really had a look at the sources (yet). >From what I can tell everything except the libddmpeg.so is provided as source code in the package, contrary to what they are saying. The only question is if what is provided can resolve the Texture issue for the K8M800. I've read some very contrary reports in [2] and the Via Arena forum. OTOH I'm not sure those people are using this new code at all as it shouldn't even start X with the VIA BIOS checksum of the K8M800 (or maybe just mine? Can someone verify?). I'll see this evening If I can compile the X driver without the checksum check and see what happens. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-12-18 17:49:27
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #30 from e_...@in... 2007-12-18 09:49 PST ------- > It doesn't look like Valentine Sinitsyn and Luc Verhaegen Just to make it clear: I'm only the original bug reporter, not Unichrome-DRI/Unichrome/OpenChrome developer. > have really had a look at the sources (yet). > From what I can tell everything except the libddmpeg.so > is provided as source code in the package, > contrary to what they are saying. In fact, I've already skimmed through the code VIA released on Dec, 13th. DRI part looks pretty much like the thing you can find in current Mesa tree (although I haven't done any thorough comparison and if there is a one-liner, I would definitely miss it). The archive is 14 Mb and most of it is precompiled .so libraries for different distros (outdated ones, unfortunately). I was not able to figure out whether they are just compiled sources or contain some proprietary code. It would be really nice if they don't but the release notes are somewhat misleading: This software package supports 2D, 3D, TV-Out, hardware video mpeg2/4 and hardware video overlay. Aiglx function can be supported on Fedora Core Linux 6/7, ubuntu Desktop 7.04.Other distributions only support 2D, TV-Out, hardware video mpeg2/4 and hardware video overlay. Distros in the list are among those you can find precompiled .so for. Anyway, if the code works, it would be really nice. Unfortunately, I'll hardly have an opportunity to test it in the coming days, but if you have some news on the subject (link missed from the previous post would be helpful, too), please let me/us know. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-12-18 18:05:27
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #31 from red...@gm... 2007-12-18 10:05 PST ------- > Just to make it clear: I'm only the original bug reporter, not > Unichrome-DRI/Unichrome/OpenChrome developer. Right, you're not. It wasn't meant to be offensive. Also not to Luc. Instead it's good news more people are interested in this release. Lets hope it's worth it. Meaning, I'm just about where you are. From the original post on Launchpad: I used the X-Drivers from one of the binary releases and compiled the drm.ko and via.ko from the source package. I commented out the BIOS checksum code but the X-Drivers part of the source package is impossible to build using the provided build chain. It's a huge mess. I'm working on it ... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2007-12-18 18:27:46
|
http://bugs.freedesktop.org/show_bug.cgi?id=5092 ------- Comment #32 from e_...@in... 2007-12-18 10:27 PST ------- > Right, you're not. It wasn't meant to be offensive. Also not to Luc. Heh. Confusing me with driver developer looked like a compliment, not the offense. ;-) > It's a huge mess. Absolutely! -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |