A recent CURRENT build from /head @ 209581 panics when I run
cdrecord -scanbus with the attached backtrace. The culprit
seems to be the extra call fo xpt_lock_buses() added in head rev
208752, but I'm not sure if this is the real cause yet.
--- a/sys/cam/cam_xpt.c Wed Jun 02 17:27:23 2010
M. Warner Losh i...@bsdimp.com writes:
+ /*
+ * Close the PID file, and all other open descriptors.
+ * Inherit std{in,out,err} only.
+ */
+ cfg.close_pidfile();
+ ::closefrom(3);
Actually, closefrom() is sufficient,
On Mon, Jun 28, 2010 at 06:39:29PM +0200, Dag-Erling Smørgrav wrote:
Anton Shterenlikht me...@bristol.ac.uk writes:
I think this only happens when I copy from one xterm to another,
to paste into the mailer. I've checked the command which
I put in a file, and all seems fine. Also, the latest
Anton Shterenlikht me...@bristol.ac.uk writes:
http://seis.bris.ac.uk/~mexas/ia64-lzma-problem.txt
This confirms my suspicion that ld is picking up the wrong liblzma:
attempt to open /usr/local/lib/liblzma.a succeeded
but I still can't figure out why. Can you do the following:
% make
On 2010-06-29 11:25, Dag-Erling Smørgrav wrote:
Anton Shterenlikht me...@bristol.ac.uk writes:
http://seis.bris.ac.uk/~mexas/ia64-lzma-problem.txt
This confirms my suspicion that ld is picking up the wrong liblzma:
attempt to open /usr/local/lib/liblzma.a succeeded
but I still can't
On Tue, Jun 29, 2010 at 11:25:40AM +0200, Dag-Erling Smørgrav wrote:
Anton Shterenlikht me...@bristol.ac.uk writes:
http://seis.bris.ac.uk/~mexas/ia64-lzma-problem.txt
This confirms my suspicion that ld is picking up the wrong liblzma:
attempt to open /usr/local/lib/liblzma.a succeeded
Dag-Erling Smørgrav d...@des.no writes:
This confirms my suspicion that ld is picking up the wrong liblzma:
attempt to open /usr/local/lib/liblzma.a succeeded
but I still can't figure out why.
Uh, I must be blind. It uses /usr/local/lib/liblzma.a because
-L/usr/local/lib was specified on the
Anton Shterenlikht me...@bristol.ac.uk writes:
# make buildenv
Entering world for ia64:ia64
# env
LIBRARY_PATH=/usr/local/lib
where does this come from? Your .bashrc or something?
% make buildenv
% unset LIBRARY_PATH
then run the cc command again.
DES
--
Dag-Erling Smørgrav - d...@des.no
On 2010-06-29 11:59, Anton Shterenlikht wrote:
LIBRARY_PATH=/usr/local/lib
There's your problem. Remove this environment variable, and try
buildworld again. :)
___
freebsd-current@freebsd.org mailing list
On Tue, Jun 29, 2010 at 12:03:39PM +0200, Dag-Erling Smørgrav wrote:
Anton Shterenlikht me...@bristol.ac.uk writes:
# make buildenv
Entering world for ia64:ia64
# env
LIBRARY_PATH=/usr/local/lib
where does this come from? Your .bashrc or something?
I've this set in $HOME/.tcsh. I
2010/6/29 Anton Shterenlikht me...@bristol.ac.uk:
On Tue, Jun 29, 2010 at 12:03:39PM +0200, Dag-Erling Smørgrav wrote:
Anton Shterenlikht me...@bristol.ac.uk writes:
# make buildenv
Entering world for ia64:ia64
# env
LIBRARY_PATH=/usr/local/lib
where does this come from? Your .bashrc
Anton Shterenlikht me...@bristol.ac.uk writes:
However, I've got this set on 3 ia64 boxes.
On two of them I don't have this lzma problem.
Because they either don't have liblzma installed from ports, or they
have a different version that works.
DES
--
Dag-Erling Smørgrav - d...@des.no
On Tue, Jun 29, 2010 at 01:26:23PM +0200, Dag-Erling Smørgrav wrote:
Anton Shterenlikht me...@bristol.ac.uk writes:
However, I've got this set on 3 ia64 boxes.
On two of them I don't have this lzma problem.
Because they either don't have liblzma installed from ports, or they
have a
On 6/28/2010 11:13 PM, Giorgos Keramidas wrote:
A recent CURRENT build from /head @ 209581 panics when I run
cdrecord -scanbus with the attached backtrace. The culprit
seems to be the extra call fo xpt_lock_buses() added in head rev
208752, but I'm not sure if this is the real cause yet.
On 6/28/2010 11:13 PM, Giorgos Keramidas wrote:
A recent CURRENT build from /head @ 209581 panics when I run
cdrecord -scanbus with the attached backtrace. The culprit
seems to be the extra call fo xpt_lock_buses() added in head rev
208752, but I'm not sure if this is the real cause yet.
In message: 86r5jqdz9w@ds4.des.no
Dag-Erling Smørgrav d...@des.no writes:
: M. Warner Losh i...@bsdimp.com writes:
: + /*
: +* Close the PID file, and all other open descriptors.
: +* Inherit std{in,out,err} only.
: +*/
: +
M. Warner Losh i...@bsdimp.com writes:
I went ahead and used pidfile_close in this context because that's
what's recommended in the man page. I know it is likely redundant,
but I thought better safe than sorry...
agreed...
DES
--
Dag-Erling Smørgrav - d...@des.no
On Mon, Jun 28, 2010 at 10:25:15AM -0400, Nathaniel W Filardo wrote:
Well, I'm back in the same town as my sparc64 and so csup'd, built, and
rebooted, trying to get more information about the vm object not owned
panic I reported a while ago. To my dismay, I now get this panic, also late
18 matches
Mail list logo
