Re: Other interesting mips breakage...

On Sat, Feb 01, 2014 at 02:03:24AM -0600, John D. Baker wrote:
> I should have looked at port-mips@ more diligently before my latest spate
> of PR filing.  The very issues I filed about were discussed here at length.
> 
> In light of that, I'd welcome input on issues already being pursued in
> absence of an active PR.  What I've come to observe since evbmips/LOONGSON
> became operational again (on my Lemote YEELOONG, since that's the only
> mips/evbmips machine I have):
> 
> X server:  the undefined symbol issues seem to have been resolved, but
> now the server complains that it can't load the "int10" module, saying
> that it doesn't exist.  Also what looks like a NULL pointer dereference.

What driver are you using ? Works fine for me, with a SiS video controller.
I also tested wsfb.


> 
> The 'dig' utility dies with segfault in pthread_getspecific().

Yes, I'm also seeing this with glxgears. I guess several threaded binaries
are affected.

> 
> Can't build anything from pkgsrc as the C compiler dies with bus error
> compiling the first real source in "pkgtools/digest".  (It works well
> enough to complete the "./configure" script, though.)

gcc -O2 core dump, but removing -O2 makes it work. I don't know why

> 
> If there are hints on the above, please share.  I suspect the most
> obvious thing to try is nuke OBJDIR and DESTDIR from orbit, just to
> make sure.
> 
> 
> A few things that persist from early 6.99.x days:
> 
> PR/48564: 'tar' corrupts files extracted to NFS.  I originally saw this as
> a result of bizzare modifications suggested when running 'etcupdate' on
> my NFS-root installation.  Then LOONGSON kernel build breakage, etc.
> intervened.  Finally, I sat down and analyzed what the nature of the
> data corruption was.

No idea, but I've not tested nfs.

> 
> 'amd' (am-utils) fails, claiming "Invalid argument" on all automount
> points.  The config file and maps are the same ones I use on all my
> other systems (i386, amd64, sparc, macppc, mvme68k).

Could be a compat-netbsd32 issue. ktrace would show what syscall or ioctl
returns the einval.

> 
> Not yet re-examined:  sshd hangs incoming SSH connections in a quasi-open
> state holding the client inoperative until local terminal is closed
> (close window in GUI or kill parent shell process from other wscons
> virtual terminal).

sshd works fine for me ...

-- 
Manuel Bouyer <[email protected]>
     NetBSD: 26 ans d'experience feront toujours la difference
--