Re: amd64 system crash with radeondrm enabled after update

[Sverre Froyen <sverre%viewmark.com@localhost>]

On Sun May 16 2010 12:11:25 David Young wrote:
> On Sun, May 16, 2010 at 11:08:23AM -0600, Sverre Froyen wrote:
> > On Fri May 14 2010 13:41:10 Sverre Froyen wrote:
> > > On Fri May 14 2010 13:02:59 David Young wrote:
> > > > On Fri, May 14, 2010 at 12:24:17PM -0600, Sverre Froyen wrote:
> > ...
> > 
> > > > > db{0}> bt
> > > > > bus_space_write_4() at netbsd:bus_space_write_4+0x3
> > > > > r600_do_init_cp() at netbsd:r600_do_init_cp+0x5ee
> > > > 
> > > > What line is that?  In gdb, 'l *(r600_do_init_cp+0x5ee)'.
> > > 
> > > (gdb) l *(r600_do_init_cp+0x5ee)
> > > 0xffffffff805a80c3 is in r600_do_init_cp
> > > (/usr/src/sys/external/bsd/drm/dist/shared-core/r600_cp.c:2068).
> > > 2063            else
> > > 2064                r600_cp_load_microcode(dev_priv);
> > > 2065
> > > 2066            r600_cp_init_ring_buffer(dev, dev_priv);
> > > 2067
> > > 2068            dev_priv->last_buf = 0;
> > > 2069
> > > 2070            r600_do_engine_reset(dev);
> > > 2071            r600_test_writeback(dev_priv);
> > > 2072
> > 
> > Sprinkling some printfs, I find that the problem is in line
> > 
> > SET_RING_HEAD(dev_priv, 0);
> > 
> > in the function r600_cp_init_ring_buffer (no idea why the trace did not
> > include that function).
> 
> Sometimes function calls or stack frames are optimized way.  Sometimes I
> add DEBUG="-g -fno-omit-frame-pointer -fno-optimize-sibling-calls" to my
> kernel configuration to suppress that optimization for debugging.
> 
> > SET_RING_HEAD is defined in radeon_drv.h as
> > 
> > #define SET_RING_HEAD(dev_priv,val)        DRM_WRITE32(
> > (dev_priv)->ring_rptr, 0, (val) )
> > 
> > and DRM_WRITE32 is defined in /usr/src/sys/external/bsd/drm/dist/bsd-
> > core/drmP.h as
> > 
> > #define DRM_WRITE32(map, offset, val)   \
> > 
> >         bus_space_write_4((map)->bst, (map)->bsh, (offset), (val))
> 
> This is what I expected.  What are (map)->bst and (map)->bsh?

Both are zero.

> > Does any of this code need updating after the bus_space_tag_t change? See
> > 
> > http://mail-index.netbsd.org/source-changes/2010/04/28/msg009341.html
> 
> x86 code that used uninitialized bus_space_tag_t's worked by accident,
> before.  It does not work, now, because an uninitialized bus_space_tag_t
> is treated as a pointer (NULL) instead of as an integer constant (0).

OK. How do we initialize them?

I also notice that drm_netbsd_ioremap in

/usr/src/sys/external/bsd/drm/dist/bsd-core/drm_memory.c

contains code like

        map->bst = dev->pa.pa_memt;

so there may be additional issues down the line.

Thanks,
Sverre