via_drm broken on netbsd-5

[Matthew Mondor]

It appears that via_drm is now broken on netbsd-5 (this used to build
fine before):

CC=/usr/tools/bin/i386--netbsdelf-gcc /usr/tools/bin/nbmkdep -f \
via_dma.d --  -march=i686 -O2 -mtune=pentiumpro -pipe -ffreestanding \
-fno-zero-initialized-in-bss  -O2 -std=gnu99 -fstack-protector \
-Wstack-protector --param ssp-buffer-size=1 -fno-strict-aliasing \
-fstack-protector -Wstack-protector --param ssp-buffer-size=1   -Werror \
-Wall -Wno-main -Wno-format-zero-length -Wpointer-arith \
-Wmissing-prototypes -Wstrict-prototypes -Wswitch -Wshadow -Wcast-qual \
-Wwrite-strings -Wno-unreachable-code -Wno-sign-compare \
-Wno-pointer-sign -Wno-attributes -Wextra -Wno-unused-parameter \
-Werror -march=i686 -O2 -mtune=pentiumpro   -Di386 -I. \
-I/usr/src/sys/contrib/dev/ath/netbsd -I/usr/src/sys/../common/include \
-I/usr/src/sys/arch  -I/usr/src/sys -nostdinc  -DMAXUSERS=64 -D_KERNEL \
-D_KERNEL_OPT -I/usr/src/sys/lib/libkern/../../../common/lib/libc/quad \
-I/usr/src/sys/lib/libkern/../../../common/lib/libc/string \
-I/usr/src/sys/lib/libkern/../../../common/lib/libc/arch/i386/string \
-I/usr/src/sys/../common/include -I/usr/src/sys/dist/pf \
-I/usr/src/sys/external/bsd/drm/dist/bsd-core \
-I/usr/src/sys/external/bsd/drm/dist/shared-core \
-I/usr/src/sys/dist/ipf  /usr/src/sys/external/bsd/drm/dist/shared-core/via_dma.c
In file included
from /usr/src/sys/external/bsd/drm/dist/shared-core/via_dma.c:40: /usr/src/sys/external/bsd/drm/dist/shared-core/via_drv.h:27:22:
error: drm_sman.h: No such file or directory nbmkdep: compile failed.

Thanks,
--
Matt

[matthew green]

the via drm code depends on some linux-specific code that has not
been ported to netbsd yet.  you can find drm_sman.h in the mesa-drm
"linux-core" subdir.  someone needs to port it and any other parts
to the "bsd-core" subdir.


.mrg.

[Matthew Mondor]

On Mon, 29 Jun 2009 14:49:43 +1000
matthew green <mrg@...> wrote:

> the via drm code depends on some linux-specific code that has not
> been ported to netbsd yet.  you can find drm_sman.h in the mesa-drm
> "linux-core" subdir.  someone needs to port it and any other parts
> to the "bsd-core" subdir.

I however think this used to work at 5.0 release.  I have no Via
hardware however so simply removed the viadrm line from my GENERIC_MM
for now.

Another problem I experience is when using the Savage driver:
/usr/X11R7/lib/modules/drivers/savage_drv.so: Undefined PLT symbol
"SAVAGEDRIScreenInit".  The vesa driver fortunately works for now, but
is of course suboptimal...

Thanks,
--
Matt

[matthew green]

   
   I however think this used to work at 5.0 release.  I have no Via
   hardware however so simply removed the viadrm line from my GENERIC_MM
   for now.

yeah.  not much to do about it now..
   
   Another problem I experience is when using the Savage driver:
   /usr/X11R7/lib/modules/drivers/savage_drv.so: Undefined PLT symbol
   "SAVAGEDRIScreenInit".  The vesa driver fortunately works for now, but
   is of course suboptimal...

is this with netbsd 5.0 as well?


.mrg.

[Matthew Mondor]

On Mon, 29 Jun 2009 17:05:18 +1000
matthew green <mrg@...> wrote:

>    Another problem I experience is when using the Savage driver:
>    /usr/X11R7/lib/modules/drivers/savage_drv.so: Undefined PLT symbol
>    "SAVAGEDRIScreenInit".  The vesa driver fortunately works for now, but
>    is of course suboptimal...
>
> is this with netbsd 5.0 as well?

I'm actually unsure.  Another laptop with S3 was working with XF86 on
netbsd-4, then the box was upgraded to -current and tracked it until
5.99.10 with its base-xorg, on which it also works, but I've not
touched it since the x11 upgrades.  It's probable that it worked on the
NetBSD 5.0 release.

Thanks,
--
Matt

[Matthew Mondor]

On Mon, 29 Jun 2009 03:22:23 -0400
Matthew Mondor <mm_lists@...> wrote:

> On Mon, 29 Jun 2009 17:05:18 +1000
> matthew green <mrg@...> wrote:
>
> >    Another problem I experience is when using the Savage driver:
> >    /usr/X11R7/lib/modules/drivers/savage_drv.so: Undefined PLT symbol
> >    "SAVAGEDRIScreenInit".  The vesa driver fortunately works for now, but
> >    is of course suboptimal...
> >
> > is this with netbsd 5.0 as well?
>
> I'm actually unsure.  Another laptop with S3 was working with XF86 on
> netbsd-4, then the box was upgraded to -current and tracked it until
> 5.99.10 with its base-xorg, on which it also works, but I've not
> touched it since the x11 upgrades.  It's probable that it worked on the
> NetBSD 5.0 release.

So with an update to yesterday's netbsd-5 things are different; I no
longer see a PLT symbol related error.  However, with both DRI and
without, the laptop reboots when starting X11 with the savage driver.

Unfortunately, the dmesg backlog is lost, dumpcore doesn't seem to work
(it complains about (null) bad address at reboot), so I couldn't
diagnose the problem yet.  I might try remote console with ddb later if
I have the time.

On a side note, I also see these in dmesg when savagedrm is enabled
(might not be related):

savagedrm0 at vga1error: [drm:pid0:drm_attach] *ERROR* pci_mapreg info for 32 fa
iled
error: [drm:pid0:drm_attach] *ERROR* pci_mapreg info for 36 failed
: SuperSavage IX/C SDR
savagedrm0: AGP at 0x00000000 0MB
savagedrm0: Initialized savage 2.4.1 20050313

Thanks,
--
Matt

[matthew green]

   
   Unfortunately, the dmesg backlog is lost, dumpcore doesn't seem to work
   (it complains about (null) bad address at reboot), so I couldn't
   diagnose the problem yet.  I might try remote console with ddb later if
   I have the time.

try running "savecore -N /netbsd" (or your kernel).  there's a bug...
   
   On a side note, I also see these in dmesg when savagedrm is enabled
   (might not be related):
   
   savagedrm0 at vga1error: [drm:pid0:drm_attach] *ERROR* pci_mapreg info for 32 fa
   iled
   error: [drm:pid0:drm_attach] *ERROR* pci_mapreg info for 36 failed
   : SuperSavage IX/C SDR
   savagedrm0: AGP at 0x00000000 0MB
   savagedrm0: Initialized savage 2.4.1 20050313

those *ERROR* messages are harmless and you've reminded me i want to
pullup the change to demote them...


if there's a way to get Xorg.0.log as well, that would be nice, but it
probably isn't written to disk in time.

anyone know if there's a way to get all the info written to the log
to also go to stdout/err?  then you could monitor the output remotely.
(i test many things by running 'startx' manually remotely on my test
box, and setting my $DISPLAY.)


.mrg.

[Rafal Boni]

On Fri, Jul 10, 2009 at 08:42:46AM +1000, matthew green wrote:
> if there's a way to get Xorg.0.log as well, that would be nice, but it
> probably isn't written to disk in time.

In cases where I've tried debugging failures like these, there's nothing
in the Xorg.0.log after the reboot, but YMMV.

> anyone know if there's a way to get all the info written to the log
> to also go to stdout/err?  then you could monitor the output remotely.
> (i test many things by running 'startx' manually remotely on my test
> box, and setting my $DISPLAY.)

I think 'X -keeptty -verbose 9 should dump most of the info to stdout/
stderr, but I've also had trouble getting all of that to flush via a
remote connection when the machine reboots :)

--rafal

--
  Time is an illusion; lunchtime, doubly so.     |/\/\|           Rafal Boni
                   -- Ford Prefect               |\/\/|      rafal@...