Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

freebsd-ia64 Digest, Vol 353, Issue 4

1 view
Skip to first unread message

freebsd-ia...@freebsd.org

unread,
Mar 19, 2010, 8:00:23 AM3/19/10
to freebs...@freebsd.org
Send freebsd-ia64 mailing list submissions to
freebs...@freebsd.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
or, via email, send a message with subject or body 'help' to
freebsd-ia...@freebsd.org

You can reach the person managing the list at
freebsd-i...@freebsd.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-ia64 digest..."


Today's Topics:

1. [head tinderbox] failure on ia64/ia64 (FreeBSD Tinderbox)
2. Re: ldd leaves the machine unresponsive (Anton Shterenlikht)
3. Re: ldd leaves the machine unresponsive (jhell)
4. Re: ldd leaves the machine unresponsive (Garrett Cooper)


----------------------------------------------------------------------

Message: 1
Date: Thu, 18 Mar 2010 14:18:56 GMT
From: FreeBSD Tinderbox <tind...@freebsd.org>
Subject: [head tinderbox] failure on ia64/ia64
To: FreeBSD Tinderbox <tind...@freebsd.org>, <cur...@freebsd.org>,
<ia...@freebsd.org>
Message-ID: <201003181418....@freebsd-current.sentex.ca>

TB --- 2010-03-18 12:48:58 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-03-18 12:48:58 - starting HEAD tinderbox run for ia64/ia64
TB --- 2010-03-18 12:48:58 - cleaning the object tree
TB --- 2010-03-18 12:49:10 - cvsupping the source tree
TB --- 2010-03-18 12:49:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile
TB --- 2010-03-18 12:49:39 - building world
TB --- 2010-03-18 12:49:39 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-03-18 12:49:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-03-18 12:49:39 - TARGET=ia64
TB --- 2010-03-18 12:49:39 - TARGET_ARCH=ia64
TB --- 2010-03-18 12:49:39 - TZ=UTC
TB --- 2010-03-18 12:49:39 - __MAKE_CONF=/dev/null
TB --- 2010-03-18 12:49:39 - cd /src
TB --- 2010-03-18 12:49:39 - /usr/bin/make -B buildworld
>>> World build started on Thu Mar 18 12:49:40 UTC 2010
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Thu Mar 18 14:06:11 UTC 2010
TB --- 2010-03-18 14:06:11 - generating LINT kernel config
TB --- 2010-03-18 14:06:11 - cd /src/sys/ia64/conf
TB --- 2010-03-18 14:06:11 - /usr/bin/make -B LINT
TB --- 2010-03-18 14:06:11 - building LINT kernel
TB --- 2010-03-18 14:06:11 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-03-18 14:06:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-03-18 14:06:11 - TARGET=ia64
TB --- 2010-03-18 14:06:11 - TARGET_ARCH=ia64
TB --- 2010-03-18 14:06:11 - TZ=UTC
TB --- 2010-03-18 14:06:11 - __MAKE_CONF=/dev/null
TB --- 2010-03-18 14:06:11 - cd /src
TB --- 2010-03-18 14:06:11 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Mar 18 14:06:11 UTC 2010
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_crypto_wep.c
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_ddb.c
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_dfs.c
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_freebsd.c
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_hostap.c
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/net80211/ieee80211_ht.c
/src/sys/net80211/ieee80211_ht.c: In function 'ht_announce':
/src/sys/net80211/ieee80211_ht.c:291: error: 'struct ieee80211com' has no member named 'ic_rxstream'
*** Error code 1

Stop in /obj/ia64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2010-03-18 14:18:56 - WARNING: /usr/bin/make returned exit code 1
TB --- 2010-03-18 14:18:56 - ERROR: failed to build lint kernel
TB --- 2010-03-18 14:18:56 - 4319.61 user 613.23 system 5397.36 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full


------------------------------

Message: 2
Date: Thu, 18 Mar 2010 15:51:13 +0000
From: Anton Shterenlikht <me...@bristol.ac.uk>
Subject: Re: ldd leaves the machine unresponsive
To: jhell <jh...@DataIX.net>
Cc: FreeBSD Current <freebsd...@freebsd.org>,
freebs...@freebsd.org
Message-ID: <2010031815...@mech-cluster241.men.bris.ac.uk>
Content-Type: text/plain; charset=us-ascii

On Thu, Mar 18, 2010 at 11:29:36AM -0400, jhell wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On Wed, 17 Mar 2010 12:32, Anton Shterenlikht wrote:
> In Message-Id: <20100317163...@mech-cluster241.men.bris.ac.uk>
>
> > Just updated to ia64 r205248
> >
> > If my problem is due to my mis-configuration,
> > I apologise in advance.
> >
> > I run this shell script after each upgrade
> > and 'make delete-old-libs' to check
> > if any shared objects need to be rebuilt:
> >
> > <start script>
> >
> > #!/bin/sh
> >
> > for file in `find /bin /sbin /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/local -name "*"`
> > do
> > echo $file
> > ldd $file >> /root/ldd_results 2> /dev/zero
> > done
> >
> > <end script>
> >
>
> This will probably do closer to what you actually would want to look for.
>
> Writing to /dev/zero ... I don't know never tried it since /dev/null is
> usually the standard place to throw trash.
>
> #!/bin/sh
> for file in `find /*bin /usr/*bin /usr/lib* /usr/local/*bin -type f` do
> echo $file
> ldd $file >>/root/ldd_results 2>/dev/null
> done
>
> The problem with your script is that it finds most files that it can not
> or is not useful to run ldd on and leaves you junk in return.
>
> It might be more useful if you searched for dynamically linked ELF
> binaries to run ldd against like the following.
>
> === Script starts here ===
> #!/bin/sh
>
> SEARCHPATH="/*bin /usr/*bin /usr/lib* /usr/local/*bin"
>
> trap 'exit 1' 2
>
> check_libs() {
> for spath in $SEARCHPATH; do
> for ifelf in `find $spath -type f`; do
> ldd `file $ifelf | grep dynamically | cut -f1 -d:`
> done
> done
> }
>
> check_libs 2>/dev/null
> === Script ends here ===
>
> The above will find all type ELF * that are dynamically linked within the
> SEARCHPATH variable and run ldd on them and print the results to stdout.
>
> Obviously since you are going to have thousands of files being questioned,
> stdout is not going to be useful.
>
> So with the about stated:
> save the script to: checklibs.sh
> run with: "sh checklibs.sh >/root/checklibs_output"
> or: "script /root/checklibs_output checklibs.sh"
>
> > After the upgrade to r205248, the script
> > freezes at seemingly random points.
> >
>
> Unneeded disk usage & execution.
>
> > I can still ssh to the machine (using keys), i.e.
> > I see the welcome message, but cannot get to the console prompt.
>
> Of course... to many open files or processes in wait. SSH already has the
> information it needs loaded into memory, that's why you can get sort-of-in
>
> ZFS file-system perhaps ?
>
> >
> > On the serial console I cannot get the prompt
> > after entering the root password.
> >
>
> See above.
>
> > I have top(1) running interactively in another window.
> > The sh process is in "getblk" state, and ignores kill -9.
> > But there's no ldd process.
> >
> > And shutdown requests are also ignored:
> >
> > # shutdown -r now
> > Shutdown NOW!
> > shutdown: [pid 8019]
> > #
> > and nothing happens after that
> >
> > So I have to do a cold reset via MP.
> >
> > On ia64 r204322, this script causes no problems.
> >
> > Please advise
> >
>
> The above edited script should help to limit disk usage and too many open
> processes that causes your machine to bog down like that. This script does
> have its limitations and there is one bug in it... Ill let you figure out
> how to get rid of that bug but it really does not effect the intended
> output so I left it alone and sent error output to fd/2.
>
> The limitations you'll find is how many files that ldd(1) or file(1) can
> handle at one time. But if you specify specific paths like already in
> SEARCHPATH then you will most likely never see this unless the files in
> /*bin grow to be over max number of files that file(1) or ldd(1) can
> handle at one time. Shortly said... use direct paths or short globs like
> above.
>
> > many thanks
> > anton
> >
>
> A final note you might want to just install sysutils/libchk and run that.
>
> Standard Disclaimer: NONE OF THIS CONTAINED HEREIN "THIS MESSAGE" EXCUSES
> ANY OF THE UNEXPLAINED DISK LOCKING THAT IS GOING ON AND THE INFORMATION
> FOR WHICH IT MAY CONTAIN BECOMING UNAVAILABLE AT ANY POINT IN TIME DURING
> THE ORIGINAL RUN OF THE FIRST SCRIPT OR THE SECOND SCRIPT THAT WAS POSTED
> EITHER AS A ATTACHMENT OR IN-LINE.
>
> ;) JK!
>
> Good Luck.

many thanks, this is very helpful

I don't seem to have this lockup anymore.
Don't know what was happening. I've run
it now several times on 3 different ia64
current (different revisions) boxes, with
disks of different speed, and can't reproduce.
My script was very crude, of course.
I'll try sysutils/libchk

thanks again
anton

--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423


------------------------------

Message: 3
Date: Thu, 18 Mar 2010 11:29:36 -0400
From: jhell <jh...@DataIX.net>
Subject: Re: ldd leaves the machine unresponsive
To: Anton Shterenlikht <me...@bristol.ac.uk>
Cc: FreeBSD Current <freebsd...@freebsd.org>,
freebs...@freebsd.org
Message-ID: <alpine.BSF.2.00.1...@pragry.qngnvk.ybpny>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 17 Mar 2010 12:32, Anton Shterenlikht wrote:
In Message-Id: <20100317163...@mech-cluster241.men.bris.ac.uk>

> Just updated to ia64 r205248
>
> If my problem is due to my mis-configuration,
> I apologise in advance.
>
> I run this shell script after each upgrade
> and 'make delete-old-libs' to check
> if any shared objects need to be rebuilt:
>
> <start script>
>
> #!/bin/sh
>
> for file in `find /bin /sbin /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/local -name "*"`
> do
> echo $file
> ldd $file >> /root/ldd_results 2> /dev/zero
> done
>
> <end script>
>

This will probably do closer to what you actually would want to look for.

Writing to /dev/zero ... I don't know never tried it since /dev/null is
usually the standard place to throw trash.

#!/bin/sh
for file in `find /*bin /usr/*bin /usr/lib* /usr/local/*bin -type f` do
echo $file
ldd $file >>/root/ldd_results 2>/dev/null
done

The problem with your script is that it finds most files that it can not
or is not useful to run ldd on and leaves you junk in return.

It might be more useful if you searched for dynamically linked ELF
binaries to run ldd against like the following.

=== Script starts here ===
#!/bin/sh

SEARCHPATH="/*bin /usr/*bin /usr/lib* /usr/local/*bin"

trap 'exit 1' 2

check_libs() {
for spath in $SEARCHPATH; do
for ifelf in `find $spath -type f`; do
ldd `file $ifelf | grep dynamically | cut -f1 -d:`
done
done
}

check_libs 2>/dev/null
=== Script ends here ===

The above will find all type ELF * that are dynamically linked within the
SEARCHPATH variable and run ldd on them and print the results to stdout.

Obviously since you are going to have thousands of files being questioned,
stdout is not going to be useful.

So with the about stated:
save the script to: checklibs.sh
run with: "sh checklibs.sh >/root/checklibs_output"
or: "script /root/checklibs_output checklibs.sh"

> After the upgrade to r205248, the script
> freezes at seemingly random points.
>

Unneeded disk usage & execution.

> I can still ssh to the machine (using keys), i.e.
> I see the welcome message, but cannot get to the console prompt.

Of course... to many open files or processes in wait. SSH already has the
information it needs loaded into memory, that's why you can get sort-of-in

ZFS file-system perhaps ?

>
> On the serial console I cannot get the prompt
> after entering the root password.
>

See above.

> I have top(1) running interactively in another window.
> The sh process is in "getblk" state, and ignores kill -9.
> But there's no ldd process.
>
> And shutdown requests are also ignored:
>
> # shutdown -r now
> Shutdown NOW!
> shutdown: [pid 8019]
> #
> and nothing happens after that
>
> So I have to do a cold reset via MP.
>
> On ia64 r204322, this script causes no problems.
>
> Please advise
>

The above edited script should help to limit disk usage and too many open
processes that causes your machine to bog down like that. This script does
have its limitations and there is one bug in it... Ill let you figure out
how to get rid of that bug but it really does not effect the intended
output so I left it alone and sent error output to fd/2.

The limitations you'll find is how many files that ldd(1) or file(1) can
handle at one time. But if you specify specific paths like already in
SEARCHPATH then you will most likely never see this unless the files in
/*bin grow to be over max number of files that file(1) or ldd(1) can
handle at one time. Shortly said... use direct paths or short globs like
above.

> many thanks
> anton
>

A final note you might want to just install sysutils/libchk and run that.

Standard Disclaimer: NONE OF THIS CONTAINED HEREIN "THIS MESSAGE" EXCUSES
ANY OF THE UNEXPLAINED DISK LOCKING THAT IS GOING ON AND THE INFORMATION
FOR WHICH IT MAY CONTAIN BECOMING UNAVAILABLE AT ANY POINT IN TIME DURING
THE ORIGINAL RUN OF THE FIRST SCRIPT OR THE SECOND SCRIPT THAT WAS POSTED
EITHER AS A ATTACHMENT OR IN-LINE.

;) JK!

Good Luck.

- --

jhell

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iQEcBAEBAgAGBQJLokboAAoJEJBXh4mJ2FR+njQH/12zvjvwkBCEuWCzSg0O6mXA
kFR9XeF7TeFyAgBWTNWblmU6e1QRURI5V6qvR3oG+58jngbvSmAyZRbw3tz+mf2U
TJGhhnFYMph8PLDVmtVfYGf2V3UQXxcmDNtnJLsQT3i2RyRurIDFmtNf5GvBOw3b
6jpTF1xpZfJIfQMSxgQ0NhGFPQcYZCNRZy5Yh+5q7JeKSBx73btgnFSJ9IGSQfZj
xFCxELWDQOc20/M2pIRQ5z9+OyeSP0J7XrX6g0TlofJ5IxcCqNiQ8pruvKUm8/S7
AkYIgh8kqOSGhxOkXN4RqyHN537u6QLATJwMed2jgy8TBj/L+51Y+Ni1ceWdVaU=
=+oRv
-----END PGP SIGNATURE-----


------------------------------

Message: 4
Date: Thu, 18 Mar 2010 11:59:34 -0700
From: Garrett Cooper <yane...@gmail.com>
Subject: Re: ldd leaves the machine unresponsive
To: Anton Shterenlikht <me...@bristol.ac.uk>
Cc: jhell <jh...@dataix.net>, FreeBSD Current
<freebsd...@freebsd.org>, freebs...@freebsd.org
Message-ID:
<7d6fde3d1003181159t3eb...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 18, 2010 at 8:51 AM, Anton Shterenlikht <me...@bristol.ac.uk> wrote:
> On Thu, Mar 18, 2010 at 11:29:36AM -0400, jhell wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> On Wed, 17 Mar 2010 12:32, Anton Shterenlikht wrote:
>> In Message-Id: <20100317163...@mech-cluster241.men.bris.ac.uk>
>>
>> > Just updated to ia64 r205248
>> >
>> > If my problem is due to my mis-configuration,
>> > I apologise in advance.
>> >
>> > I run this shell script after each upgrade
>> > and 'make delete-old-libs' to check
>> > if any shared objects need to be rebuilt:
>> >
>> > <start script>
>> >
>> > #!/bin/sh
>> >
>> > for file in `find /bin /sbin /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/local -name "*"`
>> > do
>> >        echo $file
>> >        ldd $file >> /root/ldd_results 2> /dev/zero
>> > done
>> >
>> > <end script>
>> >
>>
>> This will probably do closer to what you actually would want to look for.
>>
>> Writing to /dev/zero ... I don't know never tried it since /dev/null is
>> usually the standard place to throw trash.
>>
>> #!/bin/sh
>> for file in `find /*bin /usr/*bin /usr/lib* /usr/local/*bin -type f` do
>>       echo $file
>>       ldd $file >>/root/ldd_results 2>/dev/null
>> done
>>
>> The problem with your script is that it finds most files that it can not
>> or is not useful to run ldd on and leaves you junk in return.
>>
>> It might be more useful if you searched for dynamically linked ELF
>> binaries to run ldd against like the following.
>>
>> === Script starts here ===
>> #!/bin/sh
>>
>> SEARCHPATH="/*bin /usr/*bin /usr/lib* /usr/local/*bin"
>>
>> trap 'exit 1' 2
>>
>> check_libs() {
>> for spath in $SEARCHPATH; do
>>          for ifelf in `find $spath -type f`; do
>>                  ldd `file $ifelf | grep dynamically | cut -f1 -d:`
>>          done
>> done
>> }
>>
>> check_libs 2>/dev/null
>> === Script ends here ===
>>
>> The above will find all type ELF * that are dynamically linked within the
>> SEARCHPATH variable and run ldd on them and print the results to stdout.
>>
>> Obviously since you are going to have thousands of files being questioned,
>> stdout is not going to be useful.
>>
>> So with the about stated:
>> save the script to: checklibs.sh
>> run with: "sh checklibs.sh >/root/checklibs_output"
>> or: "script /root/checklibs_output checklibs.sh"
>>
>> > After the upgrade to r205248, the script
>> > freezes at seemingly random points.
>> >
>>
>> Unneeded disk usage & execution.
>>
>> > I can still ssh to the machine (using keys), i.e.
>> > I see the welcome message, but cannot get to the console prompt.
>>
>> Of course... to many open files or processes in wait. SSH already has the
>> information it needs loaded into memory, that's why you can get sort-of-in
>>
>> ZFS file-system perhaps ?
>>
>> >
>> > On the serial console I cannot get the prompt
>> > after entering the root password.
>> >
>>
>> See above.
>>
>> > I have top(1) running interactively in another window.
>> > The sh process is in "getblk" state, and ignores kill -9.
>> > But there's no ldd process.
>> >
>> > And shutdown requests are also ignored:
>> >
>> > # shutdown -r now
>> > Shutdown NOW!
>> > shutdown: [pid 8019]
>> > #
>> > and nothing happens after that
>> >
>> > So I have to do a cold reset via MP.
>> >
>> > On ia64 r204322, this script causes no problems.
>> >
>> > Please advise
>> >
>>
>> The above edited script should help to limit disk usage and too many open
>> processes that causes your machine to bog down like that. This script does
>> have its limitations and there is one bug in it... Ill let you figure out
>> how to get rid of that bug but it really does not effect the intended
>> output so I left it alone and sent error output to fd/2.
>>
>> The limitations you'll find is how many files that ldd(1) or file(1) can
>> handle at one time. But if you specify specific paths like already in
>> SEARCHPATH then you will most likely never see this unless the files in
>> /*bin grow to be over max number of files that file(1) or ldd(1) can
>> handle at one time. Shortly said... use direct paths or short globs like
>> above.
>>
>> > many thanks
>> > anton
>> >
>>
>> A final note you might want to just install sysutils/libchk and run that.
>>
>> Standard Disclaimer: NONE OF THIS CONTAINED HEREIN "THIS MESSAGE" EXCUSES
>> ANY OF THE UNEXPLAINED DISK LOCKING THAT IS GOING ON AND THE INFORMATION
>> FOR WHICH IT MAY CONTAIN BECOMING UNAVAILABLE AT ANY POINT IN TIME DURING
>> THE ORIGINAL RUN OF THE FIRST SCRIPT OR THE SECOND SCRIPT THAT WAS POSTED
>> EITHER AS A ATTACHMENT OR IN-LINE.
>>
>> ;) JK!
>>
>> Good Luck.
>
> many thanks, this is very helpful
>
> I don't seem to have this lockup anymore.
> Don't know what was happening. I've run
> it now several times on 3 different ia64
> current (different revisions) boxes, with
> disks of different speed, and can't reproduce.
> My script was very crude, of course.
> I'll try sysutils/libchk

FWIW I've been seeing some performance issues with iir(4) and mfi(4)
backed UFS2 with softupdate filesystems on my new machine with some
other drivers loaded on my system [a PCI based em(4) card and
nvidia-driver enabled card -- which uses GIANT locking still].

Machine is Core i7 on an ASUS W6T Professional MB, 12GB RAM, with
debug symbols, ddb, kgdb, anti-reslock contention manager, (no
witness) etc.

I don't have much other than that to provide at this time, but it
might help to see if and when there's an overlap in the drivers noted
here.

Thanks,
-Garrett


------------------------------

End of freebsd-ia64 Digest, Vol 353, Issue 4
********************************************

0 new messages