Hi Linus/Andrew,
Another 2.6.14 DRM fix.. they always come in 3s.. hopefully thats it..
Dave.
--
I've seen similar failure on alpha.
Obviously, someone forgot to convert sg->handle stuff for
PCI gart case.
Ivan.
From: Ivan Kokshaysky <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
--- 2.6.14-rc5/drivers/char/drm/radeon_cp.c Fri Sep 23 23:39:48 2005
+++ linux/drivers/char/drm/radeon_cp.c Sat Sep 24 02:59:22 2005
@@ -1136,7 +1136,7 @@ static void radeon_cp_init_ring_buffer(
} else
#endif
ring_start = (dev_priv->cp_ring->offset
- - dev->sg->handle
+ - (unsigned long)dev->sg->virtual
+ dev_priv->gart_vm_start);
RADEON_WRITE( RADEON_CP_RB_BASE, ring_start );
@@ -1164,7 +1164,8 @@ static void radeon_cp_init_ring_buffer(
drm_sg_mem_t *entry = dev->sg;
unsigned long tmp_ofs, page_ofs;
- tmp_ofs = dev_priv->ring_rptr->offset - dev->sg->handle;
+ tmp_ofs = dev_priv->ring_rptr->offset -
+ (unsigned long)dev->sg->virtual;
page_ofs = tmp_ofs >> PAGE_SHIFT;
RADEON_WRITE( RADEON_CP_RB_RPTR_ADDR,
@@ -1491,8 +1492,8 @@ static int radeon_do_init_cp( drm_device
else
#endif
dev_priv->gart_buffers_offset = (dev->agp_buffer_map->offset
- - dev->sg->handle
- + dev_priv->gart_vm_start);
+ - (unsigned long)dev->sg->virtual
+ + dev_priv->gart_vm_start);
DRM_DEBUG( "dev_priv->gart_size %d\n",
dev_priv->gart_size );
On 10/26/05, Dave Airlie <[email protected]> wrote:
>
> Hi Linus/Andrew,
>
> Another 2.6.14 DRM fix.. they always come in 3s.. hopefully thats it..
>
> Dave.
>
Seems to have fixed my problem.
Thanks,
Badari
On Wed, 2005-10-26 at 21:11 -0700, Badari Pulavarty wrote:
> On 10/26/05, Dave Airlie <[email protected]> wrote:
> >
> > Hi Linus/Andrew,
> >
> > Another 2.6.14 DRM fix.. they always come in 3s.. hopefully thats it..
> >
> > Dave.
> >
>
> Seems to have fixed my problem.
Spoke too early, with your patch X is spinning in the kernel :(
Could be completely different problem though ..
Thanks,
Badari
top - 08:23:50 up 20 min, 1 user, load average: 1.51, 1.38, 1.02
Tasks: 60 total, 2 running, 58 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.4% us, 46.1% sy, 0.0% ni, 52.0% id, 1.5% wa, 0.0% hi,
0.0% si
Mem: 4043140k total, 226364k used, 3816776k free, 16156k buffers
Swap: 4192924k total, 0k used, 4192924k free, 139904k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3623 root 18 0 51996 11m 2524 R 92.3 0.3 18:43.36 X
3957 root 16 0 6204 884 688 R 1.6 0.0 0:00.01 top
1 root 16 0 4820 576 480 S 0.0 0.0 0:00.50 init
2 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
4 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
sysrq-t shows nothing :(
X R running task 0 3623 3620 3910
(NOTLB)
On Thu, 27 Oct 2005, Badari Pulavarty wrote:
>
> sysrq-t shows nothing :(
Use sysrq-p to show register state.
On SMP, you may need to press it several times, to get the right CPU. And
if you _never_ get the right CPU, that's likely an indication that it
disabled interrupts, or your platform just sends all keyboard interrupts
to the same CPU (try to see what happens with interrupt balancing).
Linus
On Thu, 2005-10-27 at 08:45 -0700, Linus Torvalds wrote:
>
> On Thu, 27 Oct 2005, Badari Pulavarty wrote:
> >
> > sysrq-t shows nothing :(
>
> Use sysrq-p to show register state.
>
> On SMP, you may need to press it several times, to get the right CPU. And
> if you _never_ get the right CPU, that's likely an indication that it
> disabled interrupts, or your platform just sends all keyboard interrupts
> to the same CPU (try to see what happens with interrupt balancing).
>
> Linus
I tried that earlier, it never showed anything useful.
(2-proc EM64T machine).
SysRq : Show Regs
SysRq : Show Regs
SysRq : Show Regs
SysRq : Show Regs
SysRq : Show Regs
SysRq : Show Regs
SysRq : Show Regs
SysRq : Show Regs
SysRq : Show Regs
SysRq : Show Regs
SysRq : Show Regs
SysRq : Show Regs
SysRq : Show Regs
SysRq : Show Regs
SysRq : Show Regs
SysRq : Show Regs
SysRq : Show Regs
SysRq : Show Regs
...
Thanks,
Badari
This is an X hang.. and I'd seriously doubt it has anything to do with
the kernel at that point..
A really hacky patch somehow has made its way into X.org releases from
a few vendors and it seems to break PCI GART system really badly on
first boot... I'm not the happiest person with RH/Dell/ATI engineering
at the moment who were all involved....
Benh is working on fixing this up in X.org but I've no idea how long
it will take to reach the real world...
Dave.