Regression 2.6.34->2.6.35-rc4: radeaon KMS an RS690 broken

2010-07-11 Thread Torsten Kaiser
I just tried 2.6.35-rc4 to see, if a different bug is fixed, but noted
that this kernel will only boot with radeon.modeset=0.

If KMS is active the display turns off and the system is completely
dead, not even SysRq+B is working.

I build a new kernel with the radeon driver as a module and inserted
it by hand via ssh.
The ssh session, I was using has this output:
ariolc drm # insmod ./drm_kms_helper.ko
ariolc drm # insmod ttm/ttm.ko
ariolc drm # insmod radeon/radeon.ko
Segmentation fault
ariolc drm #

The final insmod segfaulted, the shell was displaying a new prompt,
but not new input was possible.
The system still reacted to ping and trying to create a new ssh
connection resulted in a password prompt, but after entering the
password no shell was provided.
I tried SysRq+S, SysRq+U and SysRq+B, but not visible result. After a
reboot I did not find any additional information in /var/log/messages.
The effect was like the boot time failures with a builtin radeon
driver: The display (attached to the VGA output) just turns off.

But I had a second ssh connection open, doing tail -f /var/log/messages:
Jul 11 21:30:23 ariolc kernel: [  131.720470] [drm] radeon defaulting
to kernel modesetting.
Jul 11 21:30:23 ariolc kernel: [  131.720477] [drm] radeon kernel
modesetting enabled.
Jul 11 21:30:23 ariolc kernel: [  131.720623] radeon :01:05.0: PCI
INT A -> GSI 18 (level, low) -> IRQ 18
Jul 11 21:30:23 ariolc kernel: [  131.726859] [drm] initializing
kernel modesetting (RS690 0x1002:0x791E).
Jul 11 21:30:23 ariolc kernel: [  131.728607] [drm] register mmio
base: 0xFE9F
Jul 11 21:30:23 ariolc kernel: [  131.728613] [drm] register mmio
size: 65536
Jul 11 21:30:23 ariolc kernel: [  131.729591] ATOM BIOS: ATI
Jul 11 21:30:23 ariolc kernel: [  131.729625] radeon :01:05.0:
VRAM: 32M 0xDE00 - 0xDFFF (32M used)
Jul 11 21:30:23 ariolc kernel: [  131.729632] radeon :01:05.0:
GTT: 512M 0xBE00 - 0xDDFF
Jul 11 21:30:23 ariolc kernel: [  131.729675] [drm] radeon: irq initialized.
Jul 11 21:30:23 ariolc kernel: [  131.729690] mtrr: type mismatch for
fc00,200 old: write-back new: write-combining
Jul 11 21:30:23 ariolc kernel: [  131.729696] [drm] Detected VRAM
RAM=32M, BAR=32M
Jul 11 21:30:23 ariolc kernel: [  131.729701] [drm] RAM width 128bits DDR
Jul 11 21:30:23 ariolc kernel: [  131.729796] [TTM] Zone  kernel:
Available graphics memory: 2010998 kiB.
Jul 11 21:30:23 ariolc kernel: [  131.729802] [TTM] Initializing pool allocator.
Jul 11 21:30:23 ariolc kernel: [  131.729841] [drm] radeon: 32M of
VRAM memory ready
Jul 11 21:30:23 ariolc kernel: [  131.729846] [drm] radeon: 512M of
GTT memory ready.
Jul 11 21:30:23 ariolc kernel: [  131.729857] [drm] GART: num cpu
pages 131072, num gpu pages 131072
Jul 11 21:30:23 ariolc kernel: [  131.736223] [drm] radeon: 1 quad
pipes, 1 z pipes initialized.
Jul 11 21:30:23 ariolc kernel: [  131.752553] [drm] Loading
RS690/RS740 Microcode
Jul 11 21:30:23 ariolc kernel: [  131.911461] [drm] radeon: ring at
0xBE00
Jul 11 21:30:23 ariolc kernel: [  132.055912] [drm:r100_ring_test]
*ERROR* radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD)
Jul 11 21:30:23 ariolc kernel: [  132.055918] [drm:r100_cp_init]
*ERROR* radeon: cp isn't working (-22).
Jul 11 21:30:23 ariolc kernel: [  132.055925] radeon :01:05.0:
failled initializing CP (-22).
Jul 11 21:30:23 ariolc kernel: [  132.055929] radeon :01:05.0:
Disabling GPU acceleration
Jul 11 21:30:23 ariolc kernel: [  132.056174] [drm] radeon: cp finalized
Jul 11 21:30:23 ariolc kernel: [  132.057378] [drm] Default TV standard: NTSC
Jul 11 21:30:23 ariolc kernel: [  132.058671] [drm] Default TV standard: NTSC
Jul 11 21:30:23 ariolc kernel: [  132.059748] [drm] Radeon Display Connectors
Jul 11 21:30:23 ariolc kernel: [  132.059753] [drm] Connector 0:
Jul 11 21:30:23 ariolc kernel: [  132.059756] [drm]   VGA
Jul 11 21:30:23 ariolc kernel: [  132.059763] [drm]   DDC: 0x7e50
0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c
Jul 11 21:30:23 ariolc kernel: [  132.059766] [drm]   Encoders:
Jul 11 21:30:23 ariolc kernel: [  132.059770] [drm] CRT1:
INTERNAL_KLDSCP_DAC1
Jul 11 21:30:23 ariolc kernel: [  132.059773] [drm] Connector 1:
Jul 11 21:30:23 ariolc kernel: [  132.059776] [drm]   S-video
Jul 11 21:30:23 ariolc kernel: [  132.059778] [drm]   Encoders:
Jul 11 21:30:23 ariolc kernel: [  132.059781] [drm] TV1:
INTERNAL_KLDSCP_DAC1
Jul 11 21:30:23 ariolc kernel: [  132.059784] [drm] Connector 2:
Jul 11 21:30:23 ariolc kernel: [  132.059787] [drm]   HDMI-A
Jul 11 21:30:23 ariolc kernel: [  132.059792] [drm]   DDC: 0x7e40
0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c
Jul 11 21:30:23 ariolc kernel: [  132.059795] [drm]   Encoders:
Jul 11 21:30:23 ariolc kernel: [  132.059798] [drm] DFP3: INTERNAL_LVTM1
Jul 11 21:30:23 ariolc kernel: [  132.253484] [drm] fb mappable at 0xFC04
Jul 11 21:30:23 ariolc kernel: [  132.253488] [drm] vram apper at 0xFC00
Jul 11 21:30:23 ariolc kernel: [  

[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft

2010-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=28800

--- Comment #6 from Marek Ol??k  2010-07-11 17:33:51 PDT 
---
There is nothing I can do about a crash in WoW and not in the driver, though I
believe WoW without S3TC has not been tested by Blizzard QA because there are
no Windows drivers that do not advertise S3TC.

I don't think there is an equivalent to force_s3tc_enable in Gallium, and I
think the presence of libtxc_dxtn has nothing to do with the texture corruption
issue.

Now let's get back on topic.

There are two issues regarding the corrupted textures on r3xx-r4xx.

1) Assigning texture cache regions. This was fixed in r300g some time ago.

2) Occasional texture corruption which seems to be triggered by some other
state (e.g. a soldier entering the view). This is a bug in r300g, at least.
It's a real mystery to me.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.


No subject

2010-07-11 Thread
If I go one commit back, cubestorm works. It's quite a large commit and it's
not clear to me what the commit does in terms of functionality.

BTW, cubestorm is a single-buffered application.

--=20
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=3Demail
--- You are receiving this mail because: ---
You are the assignee for the bug.=


[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft

2010-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=28800

--- Comment #5 from Chris Rankin  2010-07-11 
16:17:50 PDT ---
(In reply to comment #3)
> Can you obtain a backtrace of the crash?

With r300c, I can remove the libtxc_dtxn.so library but set a flag in my .drirc
file instead:



This adds the GL_EXT_texture_compression_s3tc and GL_S3_s3tc extensions back,
and is enough to stop WoW crashing with r300c. However, this  does not
work with r300g. Is there an equivalent option with a different name for r300g
instead, please?

Note that the texture corruption is still present with r300c, even with the
libtxc_dtxn.so library removed. However, it would be interesting to test r300g
as well.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.


[PATCH] drm/via: fixed coding style issues, simplified return

2010-07-11 Thread Nicolas Kaiser
Fixed brace, macro and spacing coding style issues.
Simplified
 -if (ret) return ret;
 -return 0;
 +return ret;

Signed-off-by: Nicolas Kaiser 
---
 drivers/gpu/drm/via/via_dma.c  |  120 
 drivers/gpu/drm/via/via_dmablit.c  |   71 ++
 drivers/gpu/drm/via/via_dmablit.h  |8 +-
 drivers/gpu/drm/via/via_drv.h  |   22 +++---
 drivers/gpu/drm/via/via_irq.c  |   13 ++--
 drivers/gpu/drm/via/via_map.c  |4 +-
 drivers/gpu/drm/via/via_mm.c   |7 +-
 drivers/gpu/drm/via/via_verifier.c |   47 ++
 drivers/gpu/drm/via/via_verifier.h |4 +-
 drivers/gpu/drm/via/via_video.c|6 +-
 10 files changed, 136 insertions(+), 166 deletions(-)

diff --git a/drivers/gpu/drm/via/via_dma.c b/drivers/gpu/drm/via/via_dma.c
index bfb92d2..68dda74 100644
--- a/drivers/gpu/drm/via/via_dma.c
+++ b/drivers/gpu/drm/via/via_dma.c
@@ -58,28 +58,29 @@
*((uint32_t *)(vb)) = ((nReg) >> 2) | HALCYON_HEADER1;  \
*((uint32_t *)(vb) + 1) = (nData);  \
vb = ((uint32_t *)vb) + 2;  \
-   dev_priv->dma_low +=8;  \
+   dev_priv->dma_low += 8; \
 }

 #define via_flush_write_combine() DRM_MEMORYBARRIER()

-#define VIA_OUT_RING_QW(w1,w2) \
+#define VIA_OUT_RING_QW(w1, w2)do {\
*vb++ = (w1);   \
*vb++ = (w2);   \
-   dev_priv->dma_low += 8;
+   dev_priv->dma_low += 8; \
+} while (0)

-static void via_cmdbuf_start(drm_via_private_t * dev_priv);
-static void via_cmdbuf_pause(drm_via_private_t * dev_priv);
-static void via_cmdbuf_reset(drm_via_private_t * dev_priv);
-static void via_cmdbuf_rewind(drm_via_private_t * dev_priv);
-static int via_wait_idle(drm_via_private_t * dev_priv);
-static void via_pad_cache(drm_via_private_t * dev_priv, int qwords);
+static void via_cmdbuf_start(drm_via_private_t *dev_priv);
+static void via_cmdbuf_pause(drm_via_private_t *dev_priv);
+static void via_cmdbuf_reset(drm_via_private_t *dev_priv);
+static void via_cmdbuf_rewind(drm_via_private_t *dev_priv);
+static int via_wait_idle(drm_via_private_t *dev_priv);
+static void via_pad_cache(drm_via_private_t *dev_priv, int qwords);

 /*
  * Free space in command buffer.
  */

-static uint32_t via_cmdbuf_space(drm_via_private_t * dev_priv)
+static uint32_t via_cmdbuf_space(drm_via_private_t *dev_priv)
 {
uint32_t agp_base = dev_priv->dma_offset + (uint32_t) dev_priv->agpAddr;
uint32_t hw_addr = *(dev_priv->hw_addr_ptr) - agp_base;
@@ -93,7 +94,7 @@ static uint32_t via_cmdbuf_space(drm_via_private_t * dev_priv)
  * How much does the command regulator lag behind?
  */

-static uint32_t via_cmdbuf_lag(drm_via_private_t * dev_priv)
+static uint32_t via_cmdbuf_lag(drm_via_private_t *dev_priv)
 {
uint32_t agp_base = dev_priv->dma_offset + (uint32_t) dev_priv->agpAddr;
uint32_t hw_addr = *(dev_priv->hw_addr_ptr) - agp_base;
@@ -108,7 +109,7 @@ static uint32_t via_cmdbuf_lag(drm_via_private_t * dev_priv)
  */

 static inline int
-via_cmdbuf_wait(drm_via_private_t * dev_priv, unsigned int size)
+via_cmdbuf_wait(drm_via_private_t *dev_priv, unsigned int size)
 {
uint32_t agp_base = dev_priv->dma_offset + (uint32_t) dev_priv->agpAddr;
uint32_t cur_addr, hw_addr, next_addr;
@@ -146,14 +147,13 @@ static inline uint32_t *via_check_dma(drm_via_private_t * 
dev_priv,
dev_priv->dma_high) {
via_cmdbuf_rewind(dev_priv);
}
-   if (via_cmdbuf_wait(dev_priv, size) != 0) {
+   if (via_cmdbuf_wait(dev_priv, size) != 0)
return NULL;
-   }

return (uint32_t *) (dev_priv->dma_ptr + dev_priv->dma_low);
 }

-int via_dma_cleanup(struct drm_device * dev)
+int via_dma_cleanup(struct drm_device *dev)
 {
if (dev->dev_private) {
drm_via_private_t *dev_priv =
@@ -171,9 +171,9 @@ int via_dma_cleanup(struct drm_device * dev)
return 0;
 }

-static int via_initialize(struct drm_device * dev,
- drm_via_private_t * dev_priv,
- drm_via_dma_init_t * init)
+static int via_initialize(struct drm_device *dev,
+ drm_via_private_t *dev_priv,
+ drm_via_dma_init_t *init)
 {
if (!dev_priv || !dev_priv->mmio) {
DRM_ERROR("via_dma_init called before via_map_init\n");
@@ -258,7 +258,7 @@ static int via_dma_init(struct drm_device *dev, void *data, 
struct drm_file *fil
return retcode;
 }

-static int via_dispatch_cmdbuffer(struct drm_device * dev, drm_via_cmdbuffer_t 
* cmd)
+static int via_dispatch_cmdbuffer(struct drm_device *dev, drm_via_cmdbuffer_t 
*cmd)
 {
drm_via_private_t *dev_priv;
uint32_t *vb;
@@ -271,9 +271,8 @@ static int via_dispatch_cmdbuffer(struct drm_device * 

[Bug 28563] [r300g] CubeStorm hack from XScreenSaver freezes X

2010-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=28563

Marek Ol??k  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Marek Ol??k  2010-07-11 15:07:56 PDT 
---
Fixed in master, closing..

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.


deadlock possiblity introduced by "drm/nouveau: use drm_mm in preference to custom code doing the same thing"

2010-07-11 Thread Ben Skeggs
On Sun, 2010-07-11 at 01:24 +0200, Marcin Slusarz wrote:
> Hi
> 
> Patch "drm/nouveau: use drm_mm in preference to custom code doing the same 
> thing"
> in nouveau tree introduced new deadlock possibility, for which lockdep 
> complains loudly:
> 
> [ 1541.070202] [drm] nouveau :02:00.0: Allocating FIFO number 3
> [ 1541.084772] [drm] nouveau :02:00.0: nouveau_channel_alloc: initialised 
> FIFO 3
> [ 2417.733440] [drm] nouveau :02:00.0: nouveau_channel_free: freeing fifo 
> 3
> [ 2417.746638] 
> [ 2417.746639] ==
> [ 2417.746642] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
> [ 2417.746644] 2.6.35-rc4-nv+ #379
> [ 2417.746645] --
> [ 2417.746648] warsow/2850 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
> [ 2417.746650]  (&(>unused_lock)->rlock){+.+...}, at: 
> [] drm_mm_put_block+0x17a/0x1c0
> [ 2417.746657] 
> [ 2417.746658] and this task is already holding:
> [ 2417.746659]  (&(_priv->context_switch_lock)->rlock){-.}, at: 
> [] nouveau_channel_free+0x10f/0x233 [nouveau]
> [ 2417.746669] which would create a new lock dependency:
> [ 2417.746671]  (&(_priv->context_switch_lock)->rlock){-.} -> 
> (&(>unused_lock)->rlock){+.+...}
> [ 2417.746676] 
> [ 2417.746676] but this new dependency connects a HARDIRQ-irq-safe lock:
> [ 2417.746678]  (&(_priv->context_switch_lock)->rlock){-.}
> [ 2417.746680] ... which became HARDIRQ-irq-safe at:
> [ 2417.746682]   [] __lock_acquire+0x671/0x8f4
> [ 2417.746685]   [] lock_acquire+0x148/0x18d
> [ 2417.746688]   [] _raw_spin_lock_irqsave+0x41/0x53
> [ 2417.746692]   [] nouveau_irq_handler+0x56/0xa48 [nouveau]
> [ 2417.746698]   [] handle_IRQ_event+0xec/0x25d
> [ 2417.746702]   [] handle_fasteoi_irq+0x92/0xd2
> [ 2417.746705]   [] handle_irq+0x83/0x8c
> [ 2417.746707]   [] do_IRQ+0x57/0xbe
> [ 2417.746711]   [] ret_from_intr+0x0/0xf
> [ 2417.746714]   [] cpu_idle+0x5c/0xb3
> [ 2417.746717]   [] start_secondary+0x1c7/0x1cb
> [ 2417.746720] 
> [ 2417.746720] to a HARDIRQ-irq-unsafe lock:
> [ 2417.746722]  (&(>unused_lock)->rlock){+.+...}
> [ 2417.746724] ... which became HARDIRQ-irq-unsafe at:
> [ 2417.746725] ...  [] __lock_acquire+0x6eb/0x8f4
> [ 2417.746729]   [] lock_acquire+0x148/0x18d
> [ 2417.746732]   [] _raw_spin_lock+0x36/0x45
> [ 2417.746735]   [] drm_mm_pre_get+0x20/0x1a7
> [ 2417.746738]   [] ttm_bo_init+0x234/0x385 [ttm]
> [ 2417.746743]   [] nouveau_bo_new+0x366/0x3eb [nouveau]
> [ 2417.746750]   [] nouveau_mem_init+0x262/0x44a [nouveau]
> [ 2417.746756]   [] nouveau_card_init+0xa73/0xd7e [nouveau]
> [ 2417.746761]   [] nouveau_load+0x6ba/0x70a [nouveau]
> [ 2417.746766]   [] drm_get_dev+0x470/0x5a1
> [ 2417.746769]   [] nouveau_pci_probe+0x10/0x12 [nouveau]
> [ 2417.746778]   [] local_pci_probe+0x12/0x16
> [ 2417.746781]   [] pci_device_probe+0x60/0x8f
> [ 2417.746784]   [] driver_probe_device+0xa7/0x136
> [ 2417.746788]   [] __driver_attach+0x5c/0x80
> [ 2417.746790]   [] bus_for_each_dev+0x54/0x89
> [ 2417.746793]   [] driver_attach+0x19/0x1b
> [ 2417.746796]   [] bus_add_driver+0x183/0x2ef
> [ 2417.746799]   [] driver_register+0x98/0x109
> [ 2417.746801]   [] __pci_register_driver+0x63/0xd3
> [ 2417.746805]   [] drm_init+0x6b/0xd1
> [ 2417.746807]   [] 0xa0128048
> [ 2417.746810]   [] do_one_initcall+0x59/0x14e
> [ 2417.746814]   [] sys_init_module+0x9c/0x1dd
> [ 2417.746817]   [] system_call_fastpath+0x16/0x1b
> [ 2417.746820] 
> [ 2417.746820] other info that might help us debug this:
> [ 2417.746821] 
> [ 2417.746823] 1 lock held by warsow/2850:
> [ 2417.746824]  #0:  (&(_priv->context_switch_lock)->rlock){-.}, at: 
> [] nouveau_channel_free+0x10f/0x233 [nouveau]
> [ 2417.746833] 
> [ 2417.746833] the dependencies between HARDIRQ-irq-safe lock and the holding 
> lock:
> [ 2417.746841] -> (&(_priv->context_switch_lock)->rlock){-.} ops: 18 {
> [ 2417.746845]IN-HARDIRQ-W at:
> [ 2417.746847][] 
> __lock_acquire+0x671/0x8f4
> [ 2417.746851][] 
> lock_acquire+0x148/0x18d
> [ 2417.746854][] 
> _raw_spin_lock_irqsave+0x41/0x53
> [ 2417.746858][] 
> nouveau_irq_handler+0x56/0xa48 [nouveau]
> [ 2417.746865][] 
> handle_IRQ_event+0xec/0x25d
> [ 2417.746868][] 
> handle_fasteoi_irq+0x92/0xd2
> [ 2417.746871][] 
> handle_irq+0x83/0x8c
> [ 2417.746874][] 
> do_IRQ+0x57/0xbe
> [ 2417.746878][] 
> ret_from_intr+0x0/0xf
> [ 2417.746881][] 
> cpu_idle+0x5c/0xb3
> [ 2417.746885][] 
> start_secondary+0x1c7/0x1cb
> [ 2417.746888]INITIAL USE at:
> [ 2417.746890]   

[Bug 28563] [r300g] CubeStorm hack from XScreenSaver freezes X

2010-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=28563

--- Comment #2 from Marek Ol??k  2010-07-11 10:16:59 PDT 
---
Bisected. The first bad commit which locks up:

commit bd1ce874728c06d08a1f9881f51edbdd2f1c9db0
Author: Chia-I Wu 
Date:   Mon Mar 8 22:19:48 2010 +0800

st/dri: Switch from st_public.h to st_api.h.

This is tested with demos found in progs/demos.  However, only the DRI2
path is tested.



[Bug 28860] [r300g] Yo Frankie - shaders not working: Too many instructions

2010-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #9 from Sven Arvidsson  2010-07-11 10:05:51 PDT ---
(In reply to comment #8)
> 
> I pulled 1 of the 3 failing shaders from the error log.  If you have some
> familiarity with assembly code, you can look through the log and try to find
> optimization opportunities that would reduce the number of instructions we 
> need
> to emit.  This would be very helpful. I would recommend looking at the code
> after the dataflow passes, because at this point most of our optimizations 
> have
> already been done.  If you are unsure of what the instructions do, their
> definitions are in this file:
> src/mesa/drivers/dri/r300/compiler/radeon_opcodes.h

Thanks for having a look at the bug! Unfortunately I don't think I can be of
much help, this sounds like something well above my meager skills.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.


deadlock possiblity introduced by "drm/nouveau: use drm_mm in preference to custom code doing the same thing"

2010-07-11 Thread Marcin Slusarz
Hi

Patch "drm/nouveau: use drm_mm in preference to custom code doing the same 
thing"
in nouveau tree introduced new deadlock possibility, for which lockdep 
complains loudly:

[ 1541.070202] [drm] nouveau :02:00.0: Allocating FIFO number 3
[ 1541.084772] [drm] nouveau :02:00.0: nouveau_channel_alloc: initialised 
FIFO 3
[ 2417.733440] [drm] nouveau :02:00.0: nouveau_channel_free: freeing fifo 3
[ 2417.746638] 
[ 2417.746639] ==
[ 2417.746642] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
[ 2417.746644] 2.6.35-rc4-nv+ #379
[ 2417.746645] --
[ 2417.746648] warsow/2850 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 2417.746650]  (&(>unused_lock)->rlock){+.+...}, at: [] 
drm_mm_put_block+0x17a/0x1c0
[ 2417.746657] 
[ 2417.746658] and this task is already holding:
[ 2417.746659]  (&(_priv->context_switch_lock)->rlock){-.}, at: 
[] nouveau_channel_free+0x10f/0x233 [nouveau]
[ 2417.746669] which would create a new lock dependency:
[ 2417.746671]  (&(_priv->context_switch_lock)->rlock){-.} -> 
(&(>unused_lock)->rlock){+.+...}
[ 2417.746676] 
[ 2417.746676] but this new dependency connects a HARDIRQ-irq-safe lock:
[ 2417.746678]  (&(_priv->context_switch_lock)->rlock){-.}
[ 2417.746680] ... which became HARDIRQ-irq-safe at:
[ 2417.746682]   [] __lock_acquire+0x671/0x8f4
[ 2417.746685]   [] lock_acquire+0x148/0x18d
[ 2417.746688]   [] _raw_spin_lock_irqsave+0x41/0x53
[ 2417.746692]   [] nouveau_irq_handler+0x56/0xa48 [nouveau]
[ 2417.746698]   [] handle_IRQ_event+0xec/0x25d
[ 2417.746702]   [] handle_fasteoi_irq+0x92/0xd2
[ 2417.746705]   [] handle_irq+0x83/0x8c
[ 2417.746707]   [] do_IRQ+0x57/0xbe
[ 2417.746711]   [] ret_from_intr+0x0/0xf
[ 2417.746714]   [] cpu_idle+0x5c/0xb3
[ 2417.746717]   [] start_secondary+0x1c7/0x1cb
[ 2417.746720] 
[ 2417.746720] to a HARDIRQ-irq-unsafe lock:
[ 2417.746722]  (&(>unused_lock)->rlock){+.+...}
[ 2417.746724] ... which became HARDIRQ-irq-unsafe at:
[ 2417.746725] ...  [] __lock_acquire+0x6eb/0x8f4
[ 2417.746729]   [] lock_acquire+0x148/0x18d
[ 2417.746732]   [] _raw_spin_lock+0x36/0x45
[ 2417.746735]   [] drm_mm_pre_get+0x20/0x1a7
[ 2417.746738]   [] ttm_bo_init+0x234/0x385 [ttm]
[ 2417.746743]   [] nouveau_bo_new+0x366/0x3eb [nouveau]
[ 2417.746750]   [] nouveau_mem_init+0x262/0x44a [nouveau]
[ 2417.746756]   [] nouveau_card_init+0xa73/0xd7e [nouveau]
[ 2417.746761]   [] nouveau_load+0x6ba/0x70a [nouveau]
[ 2417.746766]   [] drm_get_dev+0x470/0x5a1
[ 2417.746769]   [] nouveau_pci_probe+0x10/0x12 [nouveau]
[ 2417.746778]   [] local_pci_probe+0x12/0x16
[ 2417.746781]   [] pci_device_probe+0x60/0x8f
[ 2417.746784]   [] driver_probe_device+0xa7/0x136
[ 2417.746788]   [] __driver_attach+0x5c/0x80
[ 2417.746790]   [] bus_for_each_dev+0x54/0x89
[ 2417.746793]   [] driver_attach+0x19/0x1b
[ 2417.746796]   [] bus_add_driver+0x183/0x2ef
[ 2417.746799]   [] driver_register+0x98/0x109
[ 2417.746801]   [] __pci_register_driver+0x63/0xd3
[ 2417.746805]   [] drm_init+0x6b/0xd1
[ 2417.746807]   [] 0xa0128048
[ 2417.746810]   [] do_one_initcall+0x59/0x14e
[ 2417.746814]   [] sys_init_module+0x9c/0x1dd
[ 2417.746817]   [] system_call_fastpath+0x16/0x1b
[ 2417.746820] 
[ 2417.746820] other info that might help us debug this:
[ 2417.746821] 
[ 2417.746823] 1 lock held by warsow/2850:
[ 2417.746824]  #0:  (&(_priv->context_switch_lock)->rlock){-.}, at: 
[] nouveau_channel_free+0x10f/0x233 [nouveau]
[ 2417.746833] 
[ 2417.746833] the dependencies between HARDIRQ-irq-safe lock and the holding 
lock:
[ 2417.746841] -> (&(_priv->context_switch_lock)->rlock){-.} ops: 18 {
[ 2417.746845]IN-HARDIRQ-W at:
[ 2417.746847][] 
__lock_acquire+0x671/0x8f4
[ 2417.746851][] 
lock_acquire+0x148/0x18d
[ 2417.746854][] 
_raw_spin_lock_irqsave+0x41/0x53
[ 2417.746858][] 
nouveau_irq_handler+0x56/0xa48 [nouveau]
[ 2417.746865][] 
handle_IRQ_event+0xec/0x25d
[ 2417.746868][] 
handle_fasteoi_irq+0x92/0xd2
[ 2417.746871][] 
handle_irq+0x83/0x8c
[ 2417.746874][] 
do_IRQ+0x57/0xbe
[ 2417.746878][] 
ret_from_intr+0x0/0xf
[ 2417.746881][] 
cpu_idle+0x5c/0xb3
[ 2417.746885][] 
start_secondary+0x1c7/0x1cb
[ 2417.746888]INITIAL USE at:
[ 2417.746890]   [] 
__lock_acquire+0x767/0x8f4
[ 2417.746893]   [] 
lock_acquire+0x148/0x18d
[ 2417.746897]   [] 
_raw_spin_lock_irqsave+0x41/0x53
[ 2417.746900] 

[PATCH] drm/savage: fixed brace, macro and spacing coding style issues

2010-07-11 Thread Nicolas Kaiser
Fixed brace, macro and spacing coding style issues.

Signed-off-by: Nicolas Kaiser 
---
Supersedes patch "drm/savage: fixed brace coding style issues".

 drivers/gpu/drm/savage/savage_bci.c   |   48 +++
 drivers/gpu/drm/savage/savage_drv.h   |  109 +
 drivers/gpu/drm/savage/savage_state.c |   63 +--
 3 files changed, 109 insertions(+), 111 deletions(-)

diff --git a/drivers/gpu/drm/savage/savage_bci.c 
b/drivers/gpu/drm/savage/savage_bci.c
index 2d0c9ca..def6dd0 100644
--- a/drivers/gpu/drm/savage/savage_bci.c
+++ b/drivers/gpu/drm/savage/savage_bci.c
@@ -35,7 +35,7 @@
 static int savage_do_cleanup_bci(struct drm_device *dev);

 static int
-savage_bci_wait_fifo_shadow(drm_savage_private_t * dev_priv, unsigned int n)
+savage_bci_wait_fifo_shadow(drm_savage_private_t *dev_priv, unsigned int n)
 {
uint32_t mask = dev_priv->status_used_mask;
uint32_t threshold = dev_priv->bci_threshold_hi;
@@ -64,7 +64,7 @@ savage_bci_wait_fifo_shadow(drm_savage_private_t * dev_priv, 
unsigned int n)
 }

 static int
-savage_bci_wait_fifo_s3d(drm_savage_private_t * dev_priv, unsigned int n)
+savage_bci_wait_fifo_s3d(drm_savage_private_t *dev_priv, unsigned int n)
 {
uint32_t maxUsed = dev_priv->cob_size + SAVAGE_BCI_FIFO_SIZE - n;
uint32_t status;
@@ -85,7 +85,7 @@ savage_bci_wait_fifo_s3d(drm_savage_private_t * dev_priv, 
unsigned int n)
 }

 static int
-savage_bci_wait_fifo_s4(drm_savage_private_t * dev_priv, unsigned int n)
+savage_bci_wait_fifo_s4(drm_savage_private_t *dev_priv, unsigned int n)
 {
uint32_t maxUsed = dev_priv->cob_size + SAVAGE_BCI_FIFO_SIZE - n;
uint32_t status;
@@ -117,7 +117,7 @@ savage_bci_wait_fifo_s4(drm_savage_private_t * dev_priv, 
unsigned int n)
  * rule. Otherwise there may be glitches every 2^16 events.
  */
 static int
-savage_bci_wait_event_shadow(drm_savage_private_t * dev_priv, uint16_t e)
+savage_bci_wait_event_shadow(drm_savage_private_t *dev_priv, uint16_t e)
 {
uint32_t status;
int i;
@@ -140,7 +140,7 @@ savage_bci_wait_event_shadow(drm_savage_private_t * 
dev_priv, uint16_t e)
 }

 static int
-savage_bci_wait_event_reg(drm_savage_private_t * dev_priv, uint16_t e)
+savage_bci_wait_event_reg(drm_savage_private_t *dev_priv, uint16_t e)
 {
uint32_t status;
int i;
@@ -161,7 +161,7 @@ savage_bci_wait_event_reg(drm_savage_private_t * dev_priv, 
uint16_t e)
return -EBUSY;
 }

-uint16_t savage_bci_emit_event(drm_savage_private_t * dev_priv,
+uint16_t savage_bci_emit_event(drm_savage_private_t *dev_priv,
   unsigned int flags)
 {
uint16_t count;
@@ -203,7 +203,7 @@ uint16_t savage_bci_emit_event(drm_savage_private_t * 
dev_priv,
 /*
  * Freelist management
  */
-static int savage_freelist_init(struct drm_device * dev)
+static int savage_freelist_init(struct drm_device *dev)
 {
drm_savage_private_t *dev_priv = dev->dev_private;
struct drm_device_dma *dma = dev->dma;
@@ -269,7 +269,7 @@ static struct drm_buf *savage_freelist_get(struct 
drm_device * dev)
return NULL;
 }

-void savage_freelist_put(struct drm_device * dev, struct drm_buf * buf)
+void savage_freelist_put(struct drm_device *dev, struct drm_buf *buf)
 {
drm_savage_private_t *dev_priv = dev->dev_private;
drm_savage_buf_priv_t *entry = buf->dev_private, *prev, *next;
@@ -292,7 +292,7 @@ void savage_freelist_put(struct drm_device * dev, struct 
drm_buf * buf)
 /*
  * Command DMA
  */
-static int savage_dma_init(drm_savage_private_t * dev_priv)
+static int savage_dma_init(drm_savage_private_t *dev_priv)
 {
unsigned int i;

@@ -316,7 +316,7 @@ static int savage_dma_init(drm_savage_private_t * dev_priv)
return 0;
 }

-void savage_dma_reset(drm_savage_private_t * dev_priv)
+void savage_dma_reset(drm_savage_private_t *dev_priv)
 {
uint16_t event;
unsigned int wrap, i;
@@ -331,7 +331,7 @@ void savage_dma_reset(drm_savage_private_t * dev_priv)
dev_priv->first_dma_page = dev_priv->current_dma_page = 0;
 }

-void savage_dma_wait(drm_savage_private_t * dev_priv, unsigned int page)
+void savage_dma_wait(drm_savage_private_t *dev_priv, unsigned int page)
 {
uint16_t event;
unsigned int wrap;
@@ -415,7 +415,7 @@ uint32_t *savage_dma_alloc(drm_savage_private_t * dev_priv, 
unsigned int n)
return dma_ptr;
 }

-static void savage_dma_flush(drm_savage_private_t * dev_priv)
+static void savage_dma_flush(drm_savage_private_t *dev_priv)
 {
unsigned int first = dev_priv->first_dma_page;
unsigned int cur = dev_priv->current_dma_page;
@@ -498,7 +498,7 @@ static void savage_dma_flush(drm_savage_private_t * 
dev_priv)
  dev_priv->dma_pages[cur].flushed);
 }

-static void savage_fake_dma_flush(drm_savage_private_t * dev_priv)
+static void savage_fake_dma_flush(drm_savage_private_t *dev_priv)
 {
unsigned int i, j;
BCI_LOCALS;
@@ -525,9 

[PATCH 1/3] drm: kill BKL from common code

2010-07-11 Thread Arnd Bergmann
This restricts the use of the big kernel lock to the i830 and i810
device drivers. The three remaining users in common code (open, ioctl
and release) get converted to a new mutex, the drm_global_mutex,
making the locking stricter than the big kernel lock.

This may have a performance impact, but only in those cases that
currently don't use DRM_UNLOCKED flag in the ioctl list and would
benefit from that anyway.

The reason why i810 and i830 cannot use drm_global_mutex in their
mmap functions is a lock-order inversion problem between the current
use of the BKL and mmap_sem in these drivers. Since the BKL has
release-on-sleep semantics, it's harmless but it would cause trouble
if we replace the BKL with a mutex.

Instead, these drivers get their own ioctl wrappers that take the
BKL around every ioctl call and then set their own handlers as
DRM_UNLOCKED.

Signed-off-by: Arnd Bergmann 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_drv.c   |4 +-
 drivers/gpu/drm/drm_fops.c  |   23 +--
 drivers/gpu/drm/i810/i810_dma.c |   44 +-
 drivers/gpu/drm/i810/i810_drv.c |2 +-
 drivers/gpu/drm/i810/i810_drv.h |1 +
 drivers/gpu/drm/i830/i830_dma.c |   42 
 drivers/gpu/drm/i830/i830_drv.c |2 +-
 drivers/gpu/drm/i830/i830_drv.h |1 +
 include/drm/drmP.h  |2 +-
 9 files changed, 75 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 4a66201..76d98f4 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -506,9 +506,9 @@ long drm_ioctl(struct file *filp,
if (ioctl->flags & DRM_UNLOCKED)
retcode = func(dev, kdata, file_priv);
else {
-   lock_kernel();
+   mutex_lock(_global_mutex);
retcode = func(dev, kdata, file_priv);
-   unlock_kernel();
+   mutex_unlock(_global_mutex);
}

if (cmd & IOC_OUT) {
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index e7aace2..2ca8df8 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -39,6 +39,9 @@
 #include 
 #include 

+/* from BKL pushdown: note that nothing else serializes idr_find() */
+DEFINE_MUTEX(drm_global_mutex);
+
 static int drm_open_helper(struct inode *inode, struct file *filp,
   struct drm_device * dev);

@@ -175,8 +178,7 @@ int drm_stub_open(struct inode *inode, struct file *filp)

DRM_DEBUG("\n");

-   /* BKL pushdown: note that nothing else serializes idr_find() */
-   lock_kernel();
+   mutex_lock(_global_mutex);
minor = idr_find(_minors_idr, minor_id);
if (!minor)
goto out;
@@ -197,7 +199,7 @@ int drm_stub_open(struct inode *inode, struct file *filp)
fops_put(old_fops);

 out:
-   unlock_kernel();
+   mutex_unlock(_global_mutex);
return err;
 }

@@ -472,7 +474,7 @@ int drm_release(struct inode *inode, struct file *filp)
struct drm_device *dev = file_priv->minor->dev;
int retcode = 0;

-   lock_kernel();
+   mutex_lock(_global_mutex);

DRM_DEBUG("open_count = %d\n", dev->open_count);

@@ -573,17 +575,14 @@ int drm_release(struct inode *inode, struct file *filp)
if (atomic_read(>ioctl_count)) {
DRM_ERROR("Device busy: %d\n",
  atomic_read(>ioctl_count));
-   spin_unlock(>count_lock);
-   unlock_kernel();
-   return -EBUSY;
+   retcode = -EBUSY;
+   goto out;
}
-   spin_unlock(>count_lock);
-   unlock_kernel();
-   return drm_lastclose(dev);
+   retcode = drm_lastclose(dev);
}
+out:
spin_unlock(>count_lock);
-
-   unlock_kernel();
+   mutex_unlock(_global_mutex);

return retcode;
 }
diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index 997d917..0090693 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -37,6 +37,7 @@
 #include/* For task queue support */
 #include 
 #include 
+#include 
 #include 

 #define I810_BUF_FREE  2
@@ -1245,22 +1246,35 @@ int i810_driver_dma_quiescent(struct drm_device * dev)
return 0;
 }

+/*
+ * call the drm_ioctl under the big kernel lock because
+ * to lock against the i810_mmap_buffers function.
+ */
+long i810_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+{
+   int ret;
+   lock_kernel();
+   ret = drm_ioctl(file, cmd, arg);
+   unlock_kernel();
+   return ret;
+}
+
 struct drm_ioctl_desc i810_ioctls[] = {
-   DRM_IOCTL_DEF(DRM_I810_INIT, i810_dma_init, 

[PATCH 0/3] further BKL removal

2010-07-11 Thread Arnd Bergmann
With the ioctl, block, tty, vfs and llseek series
on their way into linux-next, these three patches
are attacking the hardest remaining issues.

If we get these ready for 2.6.36, the kernel should
be almost usable with the BKL disabled. In all three
cases, I'm cheating a bit, because the BKL still
remains lurking in the dark corners of the three
subsystems (i810/i830 for drm, OSS for sound and
lockd for fs/locks.c).

Arnd

Cc: Christoph Hellwig 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Jaroslav Kysela 
Cc: "J. Bruce Fields" 
Cc: John Kacur 
Cc: Matthew Wilcox 
Cc: Miklos Szeredi 
Cc: Takashi Iwai 
Cc: Trond Myklebust 
Cc: alsa-devel at alsa-project.org
Cc: linux-fsdevel at vger.kernel.org
Cc: linux-kernel at vger.kernel.org

Arnd Bergmann (2):
  drm: kill BKL from common code
  sound: push BKL into open functions

Matthew Wilcox (1):
  Remove BKL from fs/locks.c

 arch/um/drivers/hostaudio_kern.c   |6 ++
 drivers/gpu/drm/drm_drv.c  |4 +-
 drivers/gpu/drm/drm_fops.c |   23 
 drivers/gpu/drm/i810/i810_dma.c|   44 +-
 drivers/gpu/drm/i810/i810_drv.c|2 +-
 drivers/gpu/drm/i810/i810_drv.h|1 +
 drivers/gpu/drm/i830/i830_dma.c|   42 +
 drivers/gpu/drm/i830/i830_drv.c|2 +-
 drivers/gpu/drm/i830/i830_drv.h|1 +
 fs/Kconfig |4 +
 fs/locks.c |  116 ++--
 include/drm/drmP.h |2 +-
 sound/core/hwdep.c |   14 +++-
 sound/core/oss/mixer_oss.c |   19 ---
 sound/oss/au1550_ac97.c|   26 +---
 sound/oss/dmasound/dmasound_core.c |   28 +++--
 sound/oss/msnd_pinnacle.c  |   10 ++-
 sound/oss/sh_dac_audio.c   |9 ++-
 sound/oss/soundcard.c  |   20 ---
 sound/oss/swarm_cs4297a.c  |   17 +-
 sound/oss/vwsnd.c  |8 +++
 sound/sound_core.c |6 +--
 22 files changed, 267 insertions(+), 137 deletions(-)



[PATCH] drm/via: fixed coding style issues, simplified return

2010-07-11 Thread Nicolas Kaiser
Fixed brace, macro and spacing coding style issues.
Simplified
 -if (ret) return ret;
 -return 0;
 +return ret;

Signed-off-by: Nicolas Kaiser ni...@nikai.net
---
 drivers/gpu/drm/via/via_dma.c  |  120 
 drivers/gpu/drm/via/via_dmablit.c  |   71 ++
 drivers/gpu/drm/via/via_dmablit.h  |8 +-
 drivers/gpu/drm/via/via_drv.h  |   22 +++---
 drivers/gpu/drm/via/via_irq.c  |   13 ++--
 drivers/gpu/drm/via/via_map.c  |4 +-
 drivers/gpu/drm/via/via_mm.c   |7 +-
 drivers/gpu/drm/via/via_verifier.c |   47 ++
 drivers/gpu/drm/via/via_verifier.h |4 +-
 drivers/gpu/drm/via/via_video.c|6 +-
 10 files changed, 136 insertions(+), 166 deletions(-)

diff --git a/drivers/gpu/drm/via/via_dma.c b/drivers/gpu/drm/via/via_dma.c
index bfb92d2..68dda74 100644
--- a/drivers/gpu/drm/via/via_dma.c
+++ b/drivers/gpu/drm/via/via_dma.c
@@ -58,28 +58,29 @@
*((uint32_t *)(vb)) = ((nReg)  2) | HALCYON_HEADER1;  \
*((uint32_t *)(vb) + 1) = (nData);  \
vb = ((uint32_t *)vb) + 2;  \
-   dev_priv-dma_low +=8;  \
+   dev_priv-dma_low += 8; \
 }
 
 #define via_flush_write_combine() DRM_MEMORYBARRIER()
 
-#define VIA_OUT_RING_QW(w1,w2) \
+#define VIA_OUT_RING_QW(w1, w2)do {\
*vb++ = (w1);   \
*vb++ = (w2);   \
-   dev_priv-dma_low += 8;
+   dev_priv-dma_low += 8; \
+} while (0)
 
-static void via_cmdbuf_start(drm_via_private_t * dev_priv);
-static void via_cmdbuf_pause(drm_via_private_t * dev_priv);
-static void via_cmdbuf_reset(drm_via_private_t * dev_priv);
-static void via_cmdbuf_rewind(drm_via_private_t * dev_priv);
-static int via_wait_idle(drm_via_private_t * dev_priv);
-static void via_pad_cache(drm_via_private_t * dev_priv, int qwords);
+static void via_cmdbuf_start(drm_via_private_t *dev_priv);
+static void via_cmdbuf_pause(drm_via_private_t *dev_priv);
+static void via_cmdbuf_reset(drm_via_private_t *dev_priv);
+static void via_cmdbuf_rewind(drm_via_private_t *dev_priv);
+static int via_wait_idle(drm_via_private_t *dev_priv);
+static void via_pad_cache(drm_via_private_t *dev_priv, int qwords);
 
 /*
  * Free space in command buffer.
  */
 
-static uint32_t via_cmdbuf_space(drm_via_private_t * dev_priv)
+static uint32_t via_cmdbuf_space(drm_via_private_t *dev_priv)
 {
uint32_t agp_base = dev_priv-dma_offset + (uint32_t) dev_priv-agpAddr;
uint32_t hw_addr = *(dev_priv-hw_addr_ptr) - agp_base;
@@ -93,7 +94,7 @@ static uint32_t via_cmdbuf_space(drm_via_private_t * dev_priv)
  * How much does the command regulator lag behind?
  */
 
-static uint32_t via_cmdbuf_lag(drm_via_private_t * dev_priv)
+static uint32_t via_cmdbuf_lag(drm_via_private_t *dev_priv)
 {
uint32_t agp_base = dev_priv-dma_offset + (uint32_t) dev_priv-agpAddr;
uint32_t hw_addr = *(dev_priv-hw_addr_ptr) - agp_base;
@@ -108,7 +109,7 @@ static uint32_t via_cmdbuf_lag(drm_via_private_t * dev_priv)
  */
 
 static inline int
-via_cmdbuf_wait(drm_via_private_t * dev_priv, unsigned int size)
+via_cmdbuf_wait(drm_via_private_t *dev_priv, unsigned int size)
 {
uint32_t agp_base = dev_priv-dma_offset + (uint32_t) dev_priv-agpAddr;
uint32_t cur_addr, hw_addr, next_addr;
@@ -146,14 +147,13 @@ static inline uint32_t *via_check_dma(drm_via_private_t * 
dev_priv,
dev_priv-dma_high) {
via_cmdbuf_rewind(dev_priv);
}
-   if (via_cmdbuf_wait(dev_priv, size) != 0) {
+   if (via_cmdbuf_wait(dev_priv, size) != 0)
return NULL;
-   }
 
return (uint32_t *) (dev_priv-dma_ptr + dev_priv-dma_low);
 }
 
-int via_dma_cleanup(struct drm_device * dev)
+int via_dma_cleanup(struct drm_device *dev)
 {
if (dev-dev_private) {
drm_via_private_t *dev_priv =
@@ -171,9 +171,9 @@ int via_dma_cleanup(struct drm_device * dev)
return 0;
 }
 
-static int via_initialize(struct drm_device * dev,
- drm_via_private_t * dev_priv,
- drm_via_dma_init_t * init)
+static int via_initialize(struct drm_device *dev,
+ drm_via_private_t *dev_priv,
+ drm_via_dma_init_t *init)
 {
if (!dev_priv || !dev_priv-mmio) {
DRM_ERROR(via_dma_init called before via_map_init\n);
@@ -258,7 +258,7 @@ static int via_dma_init(struct drm_device *dev, void *data, 
struct drm_file *fil
return retcode;
 }
 
-static int via_dispatch_cmdbuffer(struct drm_device * dev, drm_via_cmdbuffer_t 
* cmd)
+static int via_dispatch_cmdbuffer(struct drm_device *dev, drm_via_cmdbuffer_t 
*cmd)
 {
drm_via_private_t *dev_priv;
uint32_t *vb;
@@ -271,9 +271,8 @@ static int via_dispatch_cmdbuffer(struct drm_device 

[Bug 28860] [r300g] Yo Frankie - shaders not working: Too many instructions

2010-07-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #9 from Sven Arvidsson s...@whiz.se 2010-07-11 10:05:51 PDT ---
(In reply to comment #8)
 
 I pulled 1 of the 3 failing shaders from the error log.  If you have some
 familiarity with assembly code, you can look through the log and try to find
 optimization opportunities that would reduce the number of instructions we 
 need
 to emit.  This would be very helpful. I would recommend looking at the code
 after the dataflow passes, because at this point most of our optimizations 
 have
 already been done.  If you are unsure of what the instructions do, their
 definitions are in this file:
 src/mesa/drivers/dri/r300/compiler/radeon_opcodes.h

Thanks for having a look at the bug! Unfortunately I don't think I can be of
much help, this sounds like something well above my meager skills.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Regression 2.6.34-2.6.35-rc4: radeaon KMS an RS690 broken

2010-07-11 Thread Torsten Kaiser
I just tried 2.6.35-rc4 to see, if a different bug is fixed, but noted
that this kernel will only boot with radeon.modeset=0.

If KMS is active the display turns off and the system is completely
dead, not even SysRq+B is working.

I build a new kernel with the radeon driver as a module and inserted
it by hand via ssh.
The ssh session, I was using has this output:
ariolc drm # insmod ./drm_kms_helper.ko
ariolc drm # insmod ttm/ttm.ko
ariolc drm # insmod radeon/radeon.ko
Segmentation fault
ariolc drm #

The final insmod segfaulted, the shell was displaying a new prompt,
but not new input was possible.
The system still reacted to ping and trying to create a new ssh
connection resulted in a password prompt, but after entering the
password no shell was provided.
I tried SysRq+S, SysRq+U and SysRq+B, but not visible result. After a
reboot I did not find any additional information in /var/log/messages.
The effect was like the boot time failures with a builtin radeon
driver: The display (attached to the VGA output) just turns off.

But I had a second ssh connection open, doing tail -f /var/log/messages:
Jul 11 21:30:23 ariolc kernel: [  131.720470] [drm] radeon defaulting
to kernel modesetting.
Jul 11 21:30:23 ariolc kernel: [  131.720477] [drm] radeon kernel
modesetting enabled.
Jul 11 21:30:23 ariolc kernel: [  131.720623] radeon :01:05.0: PCI
INT A - GSI 18 (level, low) - IRQ 18
Jul 11 21:30:23 ariolc kernel: [  131.726859] [drm] initializing
kernel modesetting (RS690 0x1002:0x791E).
Jul 11 21:30:23 ariolc kernel: [  131.728607] [drm] register mmio
base: 0xFE9F
Jul 11 21:30:23 ariolc kernel: [  131.728613] [drm] register mmio
size: 65536
Jul 11 21:30:23 ariolc kernel: [  131.729591] ATOM BIOS: ATI
Jul 11 21:30:23 ariolc kernel: [  131.729625] radeon :01:05.0:
VRAM: 32M 0xDE00 - 0xDFFF (32M used)
Jul 11 21:30:23 ariolc kernel: [  131.729632] radeon :01:05.0:
GTT: 512M 0xBE00 - 0xDDFF
Jul 11 21:30:23 ariolc kernel: [  131.729675] [drm] radeon: irq initialized.
Jul 11 21:30:23 ariolc kernel: [  131.729690] mtrr: type mismatch for
fc00,200 old: write-back new: write-combining
Jul 11 21:30:23 ariolc kernel: [  131.729696] [drm] Detected VRAM
RAM=32M, BAR=32M
Jul 11 21:30:23 ariolc kernel: [  131.729701] [drm] RAM width 128bits DDR
Jul 11 21:30:23 ariolc kernel: [  131.729796] [TTM] Zone  kernel:
Available graphics memory: 2010998 kiB.
Jul 11 21:30:23 ariolc kernel: [  131.729802] [TTM] Initializing pool allocator.
Jul 11 21:30:23 ariolc kernel: [  131.729841] [drm] radeon: 32M of
VRAM memory ready
Jul 11 21:30:23 ariolc kernel: [  131.729846] [drm] radeon: 512M of
GTT memory ready.
Jul 11 21:30:23 ariolc kernel: [  131.729857] [drm] GART: num cpu
pages 131072, num gpu pages 131072
Jul 11 21:30:23 ariolc kernel: [  131.736223] [drm] radeon: 1 quad
pipes, 1 z pipes initialized.
Jul 11 21:30:23 ariolc kernel: [  131.752553] [drm] Loading
RS690/RS740 Microcode
Jul 11 21:30:23 ariolc kernel: [  131.911461] [drm] radeon: ring at
0xBE00
Jul 11 21:30:23 ariolc kernel: [  132.055912] [drm:r100_ring_test]
*ERROR* radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD)
Jul 11 21:30:23 ariolc kernel: [  132.055918] [drm:r100_cp_init]
*ERROR* radeon: cp isn't working (-22).
Jul 11 21:30:23 ariolc kernel: [  132.055925] radeon :01:05.0:
failled initializing CP (-22).
Jul 11 21:30:23 ariolc kernel: [  132.055929] radeon :01:05.0:
Disabling GPU acceleration
Jul 11 21:30:23 ariolc kernel: [  132.056174] [drm] radeon: cp finalized
Jul 11 21:30:23 ariolc kernel: [  132.057378] [drm] Default TV standard: NTSC
Jul 11 21:30:23 ariolc kernel: [  132.058671] [drm] Default TV standard: NTSC
Jul 11 21:30:23 ariolc kernel: [  132.059748] [drm] Radeon Display Connectors
Jul 11 21:30:23 ariolc kernel: [  132.059753] [drm] Connector 0:
Jul 11 21:30:23 ariolc kernel: [  132.059756] [drm]   VGA
Jul 11 21:30:23 ariolc kernel: [  132.059763] [drm]   DDC: 0x7e50
0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c
Jul 11 21:30:23 ariolc kernel: [  132.059766] [drm]   Encoders:
Jul 11 21:30:23 ariolc kernel: [  132.059770] [drm] CRT1:
INTERNAL_KLDSCP_DAC1
Jul 11 21:30:23 ariolc kernel: [  132.059773] [drm] Connector 1:
Jul 11 21:30:23 ariolc kernel: [  132.059776] [drm]   S-video
Jul 11 21:30:23 ariolc kernel: [  132.059778] [drm]   Encoders:
Jul 11 21:30:23 ariolc kernel: [  132.059781] [drm] TV1:
INTERNAL_KLDSCP_DAC1
Jul 11 21:30:23 ariolc kernel: [  132.059784] [drm] Connector 2:
Jul 11 21:30:23 ariolc kernel: [  132.059787] [drm]   HDMI-A
Jul 11 21:30:23 ariolc kernel: [  132.059792] [drm]   DDC: 0x7e40
0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c
Jul 11 21:30:23 ariolc kernel: [  132.059795] [drm]   Encoders:
Jul 11 21:30:23 ariolc kernel: [  132.059798] [drm] DFP3: INTERNAL_LVTM1
Jul 11 21:30:23 ariolc kernel: [  132.253484] [drm] fb mappable at 0xFC04
Jul 11 21:30:23 ariolc kernel: [  132.253488] [drm] vram apper at 0xFC00
Jul 11 21:30:23 ariolc kernel: [  132.253489] 

[Bug 28563] [r300g] CubeStorm hack from XScreenSaver freezes X

2010-07-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=28563

Marek Olšák mar...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Marek Olšák mar...@gmail.com 2010-07-11 15:07:56 PDT ---
Fixed in master, closing..

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft

2010-07-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=28800

--- Comment #5 from Chris Rankin ranki...@googlemail.com 2010-07-11 16:17:50 
PDT ---
(In reply to comment #3)
 Can you obtain a backtrace of the crash?

With r300c, I can remove the libtxc_dtxn.so library but set a flag in my .drirc
file instead:

option name=force_s3tc_enable value=true /

This adds the GL_EXT_texture_compression_s3tc and GL_S3_s3tc extensions back,
and is enough to stop WoW crashing with r300c. However, this option/ does not
work with r300g. Is there an equivalent option with a different name for r300g
instead, please?

Note that the texture corruption is still present with r300c, even with the
libtxc_dtxn.so library removed. However, it would be interesting to test r300g
as well.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 28800] [r300c, r300g] Texture corruption with World of Warcraft

2010-07-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=28800

--- Comment #6 from Marek Olšák mar...@gmail.com 2010-07-11 17:33:51 PDT ---
There is nothing I can do about a crash in WoW and not in the driver, though I
believe WoW without S3TC has not been tested by Blizzard QA because there are
no Windows drivers that do not advertise S3TC.

I don't think there is an equivalent to force_s3tc_enable in Gallium, and I
think the presence of libtxc_dxtn has nothing to do with the texture corruption
issue.

Now let's get back on topic.

There are two issues regarding the corrupted textures on r3xx-r4xx.

1) Assigning texture cache regions. This was fixed in r300g some time ago.

2) Occasional texture corruption which seems to be triggered by some other
state (e.g. a soldier entering the view). This is a bug in r300g, at least.
It's a real mystery to me.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel