Re: still mbuf leak in 9.0 / 9.1?
Hi List,
I can confirm that it is the bug you mentioned steven.
Here is how I found it.
I recorded hourly zfskern and nfsd stats. like this.
echo PROCSTAT $reportname
pgrep -S (zfskern|nfsd) | xargs procstat -kk $reportname
luckily it crashed this night and logged this.
1910 101508 nfsd nfsd: servicemi_switch+0x186 sleepq_wait+0x42
_sleep+0x376 arc_lowmem+0x77 kmem_malloc+0xc1 uma_large_malloc+0x4a malloc+0xd9
arc_get_data_buf+0xb5 arc_read_nolock+0x1ec arc_read+0x93 dbuf_prefetch+0x12c
dmu_zfetch_dofetch+0x10b dmu_zfetch+0xaf8 dbuf_read+0x4a7
dmu_buf_hold_array_by_dnode+0x16b dmu_buf_hold_array+0x67 dmu_read_uio+0x3f
zfs_freebsd_read+0x3e3
Maybe it would be good to merge this fix into RELENG_9_1 and distribute a fix
via freebsd-update what do you think?
best,
-dennis
Am 16.05.2013 um 11:42 schrieb dennis berger:
This is indeed a ZFS+NFS system and I can see that istgt and nfs are stuck in
some ZIO state. Maybe it's this.
Thank's for pointing out.
Is it this ZFS+NFS deadlock?
--- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
@@ -3720,8 +3720,16 @@ arc_lowmem(void *arg __unused, int howto __unused)
mutex_enter(arc_reclaim_thr_lock);
needfree = 1;
cv_signal(arc_reclaim_thr_cv);
- while (needfree)
- msleep(needfree, arc_reclaim_thr_lock, 0, zfs:lowmem, 0);
+
+ /*
+ * It is unsafe to block here in arbitrary threads, because we can come
+ * here from ARC itself and may hold ARC locks and thus risk a deadlock
+ * with ARC reclaim thread.
+ */
+ if (curproc == pageproc) {
+ while (needfree)
+ msleep(needfree, arc_reclaim_thr_lock, 0, zfs:lowmem, 0);
+ }
mutex_exit(arc_reclaim_thr_lock);
mutex_exit(arc_lowmem_lock);
}
I'll try to crash our testsystem. I'll assume that stressing NFS backed with
ZFS a lot might trigger this bug?
-dennis
Am 16.05.2013 um 00:03 schrieb Steven Hartland:
- Original Message - From: dennis berger d...@nipsi.de
FreeBSD 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10
UTC 2012
3. Regarding this:
A clean shutdown isn't possible though. It hangs after vnode
cleaning, normally you would see detaching of usb devices here, or
other devices maybe?
Please don't conflate this with your above issue. This is almost
certainly unrelated. Please start a new thread about that if desired.
Maybe this is a misunderstanding normally this system will shutdown
cleanly, of course.
This hang only appears after the network problem above.
If this is a ZFS system, its a known issue which is fixed in current,
stable-9, stable-8 and the upcoming 8.4 release.
If not and you have USB devices see if the following sysctl helps:
hw.usb.no_shutdown_wait=1
Regards
Steve
This e.mail is private and confidential between Multiplay (UK) Ltd. and the
person or entity to whom it is addressed. In the event of misdirection, the
recipient is prohibited from using, copying, printing or otherwise
disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Fwd: revision higher than 250508 breaks webcam support
-- Forwarded message -- From: Jože Zobec jozze.z...@gmail.com Date: 2013/5/17 Subject: Re: revision higher than 250508 breaks webcam support To: Jeremy Chadwick j...@koitsu.org, Adrian Chadd adr...@freebsd.org OK, I compiled and tried different revisions r250559 -- OK r250560 -- OK r250561 -- error Upon updating from r250560 to r250561, svn gave me ... U /usr/src/sys/dev/sound/usb/uaudio.c U /usr/src/sys/dev U /usr/src/sys ... I tried # svn diff -r 250560:250561 /usr/src | less to see if I could localize the problem even further, but there are a lot of changes so I don't know where it could go wrong, since I'm not the one who wrote it. I am looking forward to your fast reply, Jože ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: revision higher than 250508 breaks webcam support
'ola! Cool, you've nailed it down to a specific revision. Can you create a PR (www.freebsd.org/send-pr.html) with all of this information? Hans/USB folk - here's an interesting problem. The original email is below. === Sorry, for waiting this long to post this problem, I thought it would be dealt with this week, but since it wasn't better to report it now. I hope this is the right mailing list for this particular problem. I am running FreeBSD 9.1-STABLE and using Logitech Webcam C525. I it's not listed amongst the supported hardware, but it was working perfectly until the updates that came this Sunday, 2013-05-12. The problem I'm getting is this: I keep getting this error message from the kernel, if I'm using 9.1-STABLE r250707 ... pcm6: detached ugen7.2: vendor 0x046d at asbus7 uaudio0: vendor 0x046d HD Webcam C525, class 239/2, rev 2.00/0.10, addr 2 on usbus7 uaudio0: No playback. uaudio0: Record: 48000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 32000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 24000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 16000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio: No MIDI squencer. pcm6: USB audio on uaudio0 uaudio0: No HID volume keys found. ugen7.2: vendor 0x046d at usbus7 (disconnected) uaudio0: at uhub7, port4, addr 2 (disconnected) pcm6: detached ... This message is displayed periodically ad infinitum or at least until I unplug the webcam. It stays this way, even if I use the GENERIC kernel. In a healthy case, revision 250508, kernel message upon plugging the webcam, is ... ugen7.2: vendor 0x046d at usbus7 uaudio0: vendor 0x046d HD Webcam C525, class 239/2, rev 2.00/1.00, addr2 on usbus7 uaudio: No playback. uaudio: Record: 48000 Hz, 1 ch, 16 bit S-LE PCM format, 2x8ms buffer. uaudio: No MIDI sequencer. pcm6: USB audio on uaudio0 uaudio0: No HID volume keys found. And there it stops, and the webcam works in Skype. === adrian On 17 May 2013 04:14, Jože Zobec jozze.z...@gmail.com wrote: OK, I compiled and tried different revisions r250559 -- OK r250560 -- OK r250561 -- error Upon updating from r250560 to r250561, svn give me ... U /usr/src/sys/dev/sound/usb/uaudio.c U /usr/src/sys/dev U /usr/src/sys ... I tried # svn diff -r 250560:250561 /usr/src | less to see if I could localize the problem even further, but there are a lot of changes so I don't know where it could go wrong, since I'm not the one who wrote it. I am looking forward to your fast reply, Jože ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: revision higher than 250508 breaks webcam support
El día Friday, May 17, 2013 a las 01:51:08PM +0200, Jože Zobec escribió: -- Forwarded message -- From: Jože Zobec jozze.z...@gmail.com Date: 2013/5/17 Subject: Re: revision higher than 250508 breaks webcam support To: Jeremy Chadwick j...@koitsu.org, Adrian Chadd adr...@freebsd.org OK, I compiled and tried different revisions r250559 -- OK r250560 -- OK r250561 -- error Upon updating from r250560 to r250561, svn gave me ... U /usr/src/sys/dev/sound/usb/uaudio.c U /usr/src/sys/dev U /usr/src/sys ... Hello, I have the following set of laptops which are all running the same SVN revision of the ports r315646 and only the last one was updated today to a new base/head revision r250588: | name | kernel | date | ports (r or date) | remarks +--+--+--+---+ | Aurora | r235646 | May 19, 2012 | r315646 20130401 | | tiny | r235646 | May 19, 2012 | r315646 20130401 | cloned Aurora | Perlach | r235646 | May 19, 2012 | r315646 20130401 | cloned Aurora | La-Habana| r250588 | May 13, 2013 | r315646 20130401 | the ports have been compiled on Aurora and moved via pkg_create(8) to the other hosts (around 1200 ports); on 'La-Habana' where the new kernel is running I have had to rebuild only cuse4bsd-kmod-0.1.27, because it's a kmod and depends on the sources of the running kernel; on all systems of r235646, Skype is fine with the cams I have, on r250588 my cams are working with pwcview(1) but not with Skype. What can we do to debug this? We should move this thread to freebsd-multimedia only, I suggest. Thanks matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: still mbuf leak in 9.0 / 9.1?
On Fri, May 17, 2013 at 11:37:23AM +0200, dennis berger wrote:
Hi List,
I can confirm that it is the bug you mentioned steven.
Here is how I found it.
I recorded hourly zfskern and nfsd stats. like this.
echo PROCSTAT $reportname
pgrep -S (zfskern|nfsd) | xargs procstat -kk $reportname
luckily it crashed this night and logged this.
1910 101508 nfsd nfsd: servicemi_switch+0x186
sleepq_wait+0x42 _sleep+0x376 arc_lowmem+0x77 kmem_malloc+0xc1
uma_large_malloc+0x4a malloc+0xd9 arc_get_data_buf+0xb5 arc_read_nolock+0x1ec
arc_read+0x93 dbuf_prefetch+0x12c dmu_zfetch_dofetch+0x10b dmu_zfetch+0xaf8
dbuf_read+0x4a7 dmu_buf_hold_array_by_dnode+0x16b dmu_buf_hold_array+0x67
dmu_read_uio+0x3f zfs_freebsd_read+0x3e3
Maybe it would be good to merge this fix into RELENG_9_1 and distribute a fix
via freebsd-update what do you think?
best,
-dennis
Am 16.05.2013 um 11:42 schrieb dennis berger:
This is indeed a ZFS+NFS system and I can see that istgt and nfs are stuck
in some ZIO state. Maybe it's this.
Thank's for pointing out.
Is it this ZFS+NFS deadlock?
--- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
@@ -3720,8 +3720,16 @@ arc_lowmem(void *arg __unused, int howto __unused)
mutex_enter(arc_reclaim_thr_lock);
needfree = 1;
cv_signal(arc_reclaim_thr_cv);
- while (needfree)
-msleep(needfree, arc_reclaim_thr_lock, 0, zfs:lowmem, 0);
+
+ /*
+* It is unsafe to block here in arbitrary threads, because we can come
+* here from ARC itself and may hold ARC locks and thus risk a deadlock
+* with ARC reclaim thread.
+*/
+ if (curproc == pageproc) {
+while (needfree)
+msleep(needfree, arc_reclaim_thr_lock, 0, zfs:lowmem, 0);
+ }
mutex_exit(arc_reclaim_thr_lock);
mutex_exit(arc_lowmem_lock);
}
I'll try to crash our testsystem. I'll assume that stressing NFS backed
with ZFS a lot might trigger this bug?
-dennis
Am 16.05.2013 um 00:03 schrieb Steven Hartland:
- Original Message - From: dennis berger d...@nipsi.de
FreeBSD 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10
UTC 2012
3. Regarding this:
A clean shutdown isn't possible though. It hangs after vnode
cleaning, normally you would see detaching of usb devices here, or
other devices maybe?
Please don't conflate this with your above issue. This is almost
certainly unrelated. Please start a new thread about that if desired.
Maybe this is a misunderstanding normally this system will shutdown
cleanly, of course.
This hang only appears after the network problem above.
If this is a ZFS system, its a known issue which is fixed in current,
stable-9, stable-8 and the upcoming 8.4 release.
If not and you have USB devices see if the following sysctl helps:
hw.usb.no_shutdown_wait=1
I'm sorry to say it won't happen. The only updates that the -RELEASE
branches get are for security. If you want fixes for other things, you
need to follow/run stables branches (i.e. stable/9), otherwise you will
need to wait until 9.2-RELEASE comes out.
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Command line not responding
Running 9.0-Stable on an i386. Whenever I type a command at the prompt I get the output /usr/local/lib/libintl.so.9: Undefined symbol _ThreadRuneLocale and nothing else - the command will not run. Just the above output. Commands like ls and exit work, but not much else. This happends whether I am logged in a user or as root. Cannot even halt the system from the command line. Started to happen after trying to update the freetype2 port. Got an error msg while updating libXft-2.1.14. From that point on I cannot use the command line. I have no idea what to try. Any suggestions. -- Michael Gass mg...@csbsju.edu ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Command line not responding
On 17/05/2013 18:56, Michael Gass wrote: Running 9.0-Stable on an i386. Whenever I type a command at the prompt I get the output /usr/local/lib/libintl.so.9: Undefined symbol _ThreadRuneLocale and nothing else - the command will not run. Just the above output. Commands like ls and exit work, but not much else. This happends whether I am logged in a user or as root. Cannot even halt the system from the command line. Started to happen after trying to update the freetype2 port. Got an error msg while updating libXft-2.1.14. From that point on I cannot use the command line. I have no idea what to try. Any suggestions. It's only things you installed from ports that would be affected. There was a problem with the freetype2 port earlier today, but it has been fixed now. Update your ports and try again at updating. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: Command line not responding
On Fri, May 17, 2013 at 12:56:53PM -0500, Michael Gass wrote:
Running 9.0-Stable on an i386.
Whenever I type a command at the prompt I get
the output
/usr/local/lib/libintl.so.9: Undefined symbol _ThreadRuneLocale
and nothing else - the command will not run. Just the
above output. Commands like ls and exit work, but not much
else. This happends whether I am logged in a user or as root.
Cannot even halt the system from the command line.
Started to happen after trying to update the freetype2 port.
Got an error msg while updating libXft-2.1.14. From that point
on I cannot use the command line.
I have no idea what to try. Any suggestions.
First provide the contents of /etc/make.conf and /etc/src.conf.
The _ThreadRuneLocale thing has come up before, but on -CURRENT circa
early 2012. It happened to a user when trying to build kernel (really)
and that user was tinkering about in make.conf and src.conf heavily,
messing with Clang. I personally remove Clang from my systems entirely
for many reasons, by simply doing WITHOUT_CLANG=true in src.conf and
thus rely entirely on gcc.
My recommendation, and this isn't going to make you happy:
Boot into single-user, mount your filesystems, and try commands there,
in hopes that they work. If they do:
pkg_delete -a -f
cp -pR /usr/local /usr/local.old
rm -fr /usr/local/*
reboot
Boot into multi-user, log in, and things should be fine. Next:
rm -fr /var/db/ports/*
rm -fr /usr/ports/distfiles/*
find /usr/ports -type d -name work -exec rm -fr {} \;
Now begin rebuilding your ports. If you prefer to use packages, go
right ahead, given that this was just announced a few days ago:
http://lists.freebsd.org/pipermail/freebsd-announce/2013-May/001476.html
But I tend to build everything from source, barring large-ish packages
(things like cmake, python27, perl) which I pkg_add -r.
My attitude has always been when something catastrophic impacts a very
large number of commands (particularly a library with a missing symbol
that a very large number of programs link to), start fresh. It's
not worth scrambling around with leftover cruft in place that could
appear months later and make you say I thought I fixed that!, where
you then have to follow up to a thread months old and admit actually
there is more breakage...
Footnote: I am likely to get a large amount of backlash for proposing
the above, with claims that will equate it to fixing a minor cut by
amputating the entire limb. My response to such: that's nice.
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Command line not responding
On May 17, 2013, at 19:56, Michael Gass mg...@csbsju.edu wrote: Running 9.0-Stable on an i386. Whenever I type a command at the prompt I get the output /usr/local/lib/libintl.so.9: Undefined symbol _ThreadRuneLocale and nothing else - the command will not run. Are you running bash, by any chance? Because bash is usually linked to libintl, for its internationalized messages. In any case, it looks like there is a mismatch between your libc.so, and your ports. Did you recently update your base system? Started to happen after trying to update the freetype2 port. Got an error msg while updating libXft-2.1.14. From that point on I cannot use the command line. How did you update those ports? Did you rebuild them, or install precompiled binary packages? If the latter, where exactly did you retrieve those packages from? -Dimitry ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Command line not responding
On Fri, May 17, 2013 at 09:49:20PM -0500, Michael Gass wrote: On Fri, May 17, 2013 at 11:55:13AM -0700, Jeremy Chadwick wrote: On Fri, May 17, 2013 at 12:56:53PM -0500, Michael Gass wrote: Running 9.0-Stable on an i386. Whenever I type a command at the prompt I get the output /usr/local/lib/libintl.so.9: Undefined symbol _ThreadRuneLocale and nothing else - the command will not run. Just the above output. Commands like ls and exit work, but not much else. This happends whether I am logged in a user or as root. Cannot even halt the system from the command line. Started to happen after trying to update the freetype2 port. Got an error msg while updating libXft-2.1.14. From that point on I cannot use the command line. I have no idea what to try. Any suggestions. First provide the contents of /etc/make.conf and /etc/src.conf. Thanks for getting back to me. Here are the contents of the two files. I rebuilt the kernel last fall and have updated ports fairly regularly since. Things have worked fine until today when I tried to update ports. # File: make.conf # The ? in the below is for buildworld CPUTYPE?=pentium2 # Uncomment the below for general builds. CFLAGS= -O -pipe # Uncomment the below for kernel builds. # COPTFLAGS= -O -pipe NO_PROFILE=true INSTALL_NODEBUG=true #WITHOUT_DILLO_IPV6=yes #WITH_DILLO_DLGUI=yes # added by use.perl 2013-05-17 11:04:30 PERL_VERSION=5.12.4 # File: src.conf WITHOUT_PROFILE=true WITHOUT_BLUETOOTH=true These confs look generally good, meaning there isn't the messing about that the other user had. I did catch one thing, however. Speaking strictly about CFLAGS: This should be CFLAGS+= (plus-equals), not CFLAGS= (equals). Otherwise you're effectively overriding CFLAGS for everything, which could cause issues (some portions of the build infrastructure may set or adjust the optimiser flags to something other than -O, and you'd be forcing it to do it anyway). I obviously don't know if that could/would explain the missing symbol issue, but it's still something that's erroneous and major. In general I recommend people *do not* tinker with CFLAGS at all in make.conf -- it's not worth the hassle on i386/amd64 if something goes wrong. If you ever want to know which syntaxes to use (for example, your CPUTYPE?= is correct, and your COPTFLAGS= is correct), review /usr/share/examples/etc/make.conf or src/share/examples/etc/make.conf. Unrelated to all of this (just a useful comment in passing): NO_PROFILE serves no purpose there, just keep WITHOUT_PROFILE=true in src.conf like you have. NO_PROFILE in make.conf would be from old FreeBSD days (i.e. prior to src.conf existing). Your src.conf looks fine. Sorry I can't be of more help. :-( -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Command line not responding
On Fri, May 17, 2013 at 07:34:36PM +0100, Matthew Seaman wrote: On 17/05/2013 18:56, Michael Gass wrote: Running 9.0-Stable on an i386. Whenever I type a command at the prompt I get the output /usr/local/lib/libintl.so.9: Undefined symbol _ThreadRuneLocale and nothing else - the command will not run. Just the above output. Commands like ls and exit work, but not much else. This happends whether I am logged in a user or as root. Cannot even halt the system from the command line. Started to happen after trying to update the freetype2 port. Got an error msg while updating libXft-2.1.14. From that point on I cannot use the command line. I have no idea what to try. Any suggestions. It's only things you installed from ports that would be affected. There was a problem with the freetype2 port earlier today, but it has been fixed now. Update your ports and try again at updating. Thanks for getting back to me. I updated the ports tree via portsnap and then tried installing freetype2. Same problem: right the various prebuild checks for things like gcc I get the following lines config.status: executing libtool commands /usr/local/lib/libintl.so.9: Undefined symbol _ThreadRuneLocale *** Error code 1 Now, like you said, seems anything installed from ports will not run on the command line. I just get the above error message instead. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey -- Michael Gass mg...@csbsju.edu ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Command line not responding
On Fri, May 17, 2013 at 11:55:13AM -0700, Jeremy Chadwick wrote:
On Fri, May 17, 2013 at 12:56:53PM -0500, Michael Gass wrote:
Running 9.0-Stable on an i386.
Whenever I type a command at the prompt I get
the output
/usr/local/lib/libintl.so.9: Undefined symbol _ThreadRuneLocale
and nothing else - the command will not run. Just the
above output. Commands like ls and exit work, but not much
else. This happends whether I am logged in a user or as root.
Cannot even halt the system from the command line.
Started to happen after trying to update the freetype2 port.
Got an error msg while updating libXft-2.1.14. From that point
on I cannot use the command line.
I have no idea what to try. Any suggestions.
First provide the contents of /etc/make.conf and /etc/src.conf.
Thanks for getting back to me. Here are the contents of the two
files. I rebuilt the kernel last fall and have updated ports
fairly regularly since. Things have worked fine until today when
I tried to update ports.
# File: make.conf
# The ? in the below is for buildworld
CPUTYPE?=pentium2
# Uncomment the below for general builds.
CFLAGS= -O -pipe
# Uncomment the below for kernel builds.
# COPTFLAGS= -O -pipe
NO_PROFILE=true
INSTALL_NODEBUG=true
#WITHOUT_DILLO_IPV6=yes
#WITH_DILLO_DLGUI=yes
# added by use.perl 2013-05-17 11:04:30
PERL_VERSION=5.12.4
# File: src.conf
WITHOUT_PROFILE=true
WITHOUT_BLUETOOTH=true
The _ThreadRuneLocale thing has come up before, but on -CURRENT circa
early 2012. It happened to a user when trying to build kernel (really)
and that user was tinkering about in make.conf and src.conf heavily,
messing with Clang. I personally remove Clang from my systems entirely
for many reasons, by simply doing WITHOUT_CLANG=true in src.conf and
thus rely entirely on gcc.
My recommendation, and this isn't going to make you happy:
I may do this if I cannot get things to work otherwise. I appreciate the
advice.
Boot into single-user, mount your filesystems, and try commands there,
in hopes that they work. If they do:
pkg_delete -a -f
cp -pR /usr/local /usr/local.old
rm -fr /usr/local/*
reboot
Boot into multi-user, log in, and things should be fine. Next:
rm -fr /var/db/ports/*
rm -fr /usr/ports/distfiles/*
find /usr/ports -type d -name work -exec rm -fr {} \;
Now begin rebuilding your ports. If you prefer to use packages, go
right ahead, given that this was just announced a few days ago:
http://lists.freebsd.org/pipermail/freebsd-announce/2013-May/001476.html
But I tend to build everything from source, barring large-ish packages
(things like cmake, python27, perl) which I pkg_add -r.
My attitude has always been when something catastrophic impacts a very
large number of commands (particularly a library with a missing symbol
that a very large number of programs link to), start fresh. It's
not worth scrambling around with leftover cruft in place that could
appear months later and make you say I thought I fixed that!, where
you then have to follow up to a thread months old and admit actually
there is more breakage...
Footnote: I am likely to get a large amount of backlash for proposing
the above, with claims that will equate it to fixing a minor cut by
amputating the entire limb. My response to such: that's nice.
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
--
Michael Gass
mg...@csbsju.edu
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Command line not responding
On Fri, May 17, 2013 at 09:26:58PM +0200, Dimitry Andric wrote: On May 17, 2013, at 19:56, Michael Gass mg...@csbsju.edu wrote: Running 9.0-Stable on an i386. Whenever I type a command at the prompt I get the output /usr/local/lib/libintl.so.9: Undefined symbol _ThreadRuneLocale and nothing else - the command will not run. Are you running bash, by any chance? Because bash is usually linked to libintl, for its internationalized messages. Not running bash. Running csh. In any case, it looks like there is a mismatch between your libc.so, and your ports. Did you recently update your base system? Updated the ports tree with portsnap and was in the process of updating my ports when the problem occurred with updating freetype2. Started to happen after trying to update the freetype2 port. Got an error msg while updating libXft-2.1.14. From that point on I cannot use the command line. How did you update those ports? Did you rebuild them, or install precompiled binary packages? If the latter, where exactly did you retrieve those packages from? I use portmaster with the -P option to use a package if available. So some are built and some are downloaded as packages. Thanks for getting back to me. -- Michael Gass mg...@csbsju.edu ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
