Date: Wed, 25 Mar 2009 13:23:38 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: zenxyzzy <zenxyzzy@gmail.com> Cc: freebsd-sparc64@freebsd.org Subject: Re: UltraSparc III still busted - X server causes hang, current panics at boot Message-ID: <20090325122338.GB74306@alchemy.franken.de> In-Reply-To: <bc4edd860903242030p56e13e46x86b061916438bcb5@mail.gmail.com> References: <bc4edd860903242030p56e13e46x86b061916438bcb5@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 24, 2009 at 10:30:44PM -0500, zenxyzzy wrote:
> ouch. the subject line says most of it.
>
> It appears that the -current isn't a direct descendent of the code
> that marius built the mostly successful Jan11-snap with.
> is this just a branch that hasn't been integrated into the main tree yet?
>
> until this stuff is checked in, using -current with US-III seems
> pointless right now. any ETA on this integration??
The 8.0-20090111-SNAP-sparc64-disc1.iso.gz I provided is just
a snapshot built from the official sources at that time for
the last status report as no official snapshots have been built
for 200901 and there were several changes relevant for sparc64
since the 200812 snapshot.
>
> on another note, I've built (using -current ports) an X-server for my
> creator3d, and it reliably hangs the jan11 snap kernel:
>
> using truss:
>
> <enormous amount of trace..>
> stat("/usr/local/lib/xorg/modules/internal/freebsd/",0x7fdffffdc88)
> ERR#2 'No such file or directory'
> stat("/usr/local/lib/xorg/modules/internal/",0x7fdffffdc88) ERR#2 'No
> such file or directory'
> write(0,"(WW) Warning, couldn't open modu"...,40) = 40 (0x28)
> write(0,"(II) UnloadModule: "vesa"\n",26) = 26 (0x1a)
> (EE) Failed to load module "vesa" (module does not exist, 0)
> write(2,"(EE) Failed to load module "vesa"...,61) = 61 (0x3d)
> write(0,"(EE) Failed to load module "vesa"...,61) = 61 (0x3d)
> write(0,"(II) SUNFFB: driver for Creator,"...,57) = 57 (0x39)
> ioctl(7,PCIOCREAD,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCREAD,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCREAD,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCREAD,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCREAD,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCREAD,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCREAD,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCREAD,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCREAD,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCREAD,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCREAD,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCREAD,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCREAD,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCREAD,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCREAD,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCREAD,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE,0xffffe24c) = 0 (0x0)
> ioctl(7,PCIOCWRITE
>
> and here the kernel hangs hard. no hot key to debugger, nothing.
> power down hard reset time.
>
> I'll shove some printf's in the code later tonight if I can find it,
> and see what the 18th pci register write is...
>
Trying to use X.Org 7.4 with sources prior to r188018
(r189080 for stable/7) on sparc64 (and for that matter also
powerpc and even some amd64 and i386 machines) is pointless.
Also make sure to use libpciaccess-0.10.5_5 which was built
with this revision in place so it actually uses PCIOCGETBAR.
I'd also suggest to disable hald as it's just an additional
source of problems for IMO no real gain.
Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090325122338.GB74306>