Port-evbmips archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Latest mips/evbmips observations
Lemote YEELOONG, evbmips-mips64el
So, to complicate matters, I've been building with HAVE_GCC=48. The
kernel boots. Userland mostly works. Mostly same problems from before,
a few new wrinkles...
The very few packages I managed to build using gcc 4.5.4 (sudo and lynx)
seem to work fine with the gcc-4.8.3-built kernel/libraries.
Old news (no change since last posting):
On Sat, 1 Feb 2014, John D. Baker wrote:
> 'amd' (am-utils) fails, claiming "Invalid argument" on all automount
> points.
> The 'dig' utility dies with segfault in pthread_getspecific().
'cvs update' to a pkgsrc tree on local disk is quite slow. Perhaps its
due to said local disk being an "ext2fs" partition that is shared with
the gnewsense-3 and OpenBSD systems also installed on the machine.
What should be a non-fatal error (encountering the "wip" subdirectory)
ultimately is. Using 'ktruss' I observed it traversing the tree down
and then up again at least twice, but no further down than "time" and
then it either seems to get stuck in "select", or terminates when the
remote CVS pserver resets the connection.
A workaround is to update each category subdirectory specifically
with the usual shell filename-generation facilities.
New information:
> PR/48564: 'tar' corrupts files extracted to NFS.
Same problem occurs with data written via output redirection (i.e.,
'cat src > dst' where "dst" is on NFS).
Strangely, a file written by 'tar' and the other written by redirection
are not broken in quite the same fashion. They have the same interleaved
data-block/null-block pattern and they're both truncated to the same
multiple of 8192 bytes but apparently the data blocks after the first
are different. I'll look at this again and see if I can spot what's
going on.
A file edited/written to NFS with 'vi' causes reports of unknown file
format and file truncation, but file appeared to be intact.
toolchain/48696 seems to have analyzed the native compiler problems.
Thanks for that. Hope committable fixes are forthcoming.
Changed behavior:
> 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
Once again failing due to an undefined symbol. Side effect of gcc48?
X.Org X Server 1.10.6
Release Date: 2011-07-08
X Protocol Version 11, Revision 0
Build Operating System: NetBSD/evbmips -
Current Operating System: NetBSD chalk.technoskunk.fur 6.99.40 NetBSD 6.99.40
(YEELOONG) #2: Tue Apr 29 12:13:16 CDT 2014
sysop%verthandi.technoskunk.fur@localhost:/d0/build/current/obj/mips64el/sys/arch/evbmips/compile/YEELOONG
evbmips
Build Date: 01 August 2011 01:01:00AM
Current version of pixman: 0.32.4
Before reporting problems, check http://wiki.X.Org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Apr 29 18:06:06 2014
(==) Using default built-in configuration (12 lines)
(EE) Failed to load /usr/X11R7/lib/modules/drivers/siliconmotion_drv.so:
/usr/X11R7/lib/modules/drivers/siliconmotion_drv.so: Undefined symbol
"exaOffscreenFree" (symnum = 101)
(EE) Failed to load module "siliconmotion" (loader failed, 7)
(EE) No drivers available.
Fatal server error:
no screens found
Please consult the The X.Org Foundation support
at http://wiki.X.Org
for help.
Please also check the log file at "/var/log/Xorg.0.log" for additional
information.
New problems:
'etcupdate' seems to be ignoring the "-a" and "-l" options, requiring
user action on files with no local modifications and files changed, but
with the same RCS IDs as the baseline files from the {,x}etc.tgz sets.
'etcupdate' mangles the invocation of 'postinstall' at the end, somehow
failing to pass it the "-s" switch before the source archives.
'postinstall' then complains about "unknown action 'etc.tgz'" and prints
its usage message. Manual invocation of 'postinstall' succeeds.
Pretty sure these are related to gcc48 weirdness as I don't recall it
happening before I started compiling with HAVE_GCC=48.
Some scripts refuse to run, eliciting a "Bad address." notification
from the interpreter "/bin/sh" and/or "/bin/ksh". If 'dhcpcd' is used,
the 'dhcpcd-run-hooks' script fails this way and the subsequent calls
to 'resolvconf' print repeated usage messages. During startup
'/etc/rc.d/postfix' prints its usage message and exits.
Attempting to start/restart/etc. any service manually via its rc.d
script simply prints its usage message and exits.
Have also seen the "Bad address" notification from other tools. Notably,
attempting to build from pkgsrc resulted in:
make: exec(true) failed. (Bad address)
So, it's other things having that problem as well.
wscons switching doesn't always repaint the display completely, leaving
characters from another virtual terminal on the screen. The specific
case was running 'lynx' in one terminal with an unordered list displayed.
Two spaces to the left of each list item a single character from the
corresponding position of the previous virtual terminal was displayed.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Home |
Main Index |
Thread Index |
Old Index