i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Fri Aug 30 22:34:55 PDT 2002 -- Kernel build for GENERIC completed on Fri Aug 30 23:38:55 PDT 2002 -- Kernel build for LINT started on Fri Aug 30 23:38:55 PDT 2002 -- === xe /local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:480: warning: no previous prototype for `AcpiDbDecodeNode' /local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:131: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbexec.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbhistry.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbinput.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbstats.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbxface.c:127: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/hwgpe.c:122: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/nsxfname.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/nsxfobj.c:126: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/rsdump.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utclib.c:129: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utdebug.c:122: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:492: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:530: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:607: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:610: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/acpica/acpi_acad.c:50: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_cmbat.c:56: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:274: warning: `acpi_pwr_deregister_consumer' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:212: warning: `acpi_pwr_deregister_resource' defined but not used /local0/scratch/des/src/sys/dev/hea/eni_buffer.c: In function `eni_test_memory': /local0/scratch/des/src/sys/dev/hea/eni_buffer.c:127: warning: passing arg 1 of pointer to function makes pointer from integer without a cast /local0/scratch/des/src/sys/dev/hea/eni_vcm.c: In function `eni_closevcc': /local0/scratch/des/src/sys/dev/hea/eni_vcm.c:289: warning: passing arg 1 of pointer to function makes pointer from integer without a cast /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieattach': /local0/scratch/des/src/sys/dev/ie/if_ie.c:779: warning: assignment discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieget':
openssh and lastlog
I've been seeing these messages for months.. Aug 31 20:19:29 cinq sshd[2342]: /var/log/lastlog: Permission denied .. because sshd has dropped root privileges by the time pam_lastlog tries to log the message. I realise this was discussed on this list about 2 months ago, but it hasn't been fixed yet. Why not just go back to using openssh's built-in lastlog code until pam_lastlog can be made to work from within openssh? Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel compile at aic7xxx/aicasm today's current.
Today's current gave me the following error while building a new kernel after a successful make world. cd /usr/src/sys/modules ; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/PIII850N/modules KMODDIR=/boot/kernel MACHINE=i386 make cleandir === 3dfx === accf_data === accf_http === agp === aha === aic7xxx === aic7xxx/aicasm make: don't know how to make cleandir. Stop *** Error code 2 Stop in /usr/src/sys/modules/aic7xxx. *** Error code 1 Thanks, ed -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[] freebsd-current .
Title: ½Åû¼¸ÞÀÏÆû ¼º¸í Áֹεî·Ï ¹øÈ£ (-ÀÔ·Â) Á÷Àå ÀüÈ ÈÞ´ëÆù ½Å±Ô ȸ¿ø ¿¬È¸ºñ ¸éÁ¦ Çö´ë ÀÚµ¿Â÷ ±¸ÀԽà Æ÷ÀÎÆ® ÇÒÀÎ ±¹³»ÃÖÃÊ ÁÖÀ¯ º¸Ç蹫·á °¡ÀÔ Á¤ºñ ÀÚµ¿Â÷ ¿ëÇ° ÇÒÀÎ Çö´ë M Ä«µå ½Å±Ô ȸ¿ø ¿¬È¸ºñ ¸éÁ¦ ±â¾ÆÀÚµ¿Â÷ ±¸ÀԽà Æ÷ÀÎÆ® ÇÒÀÎ ±¹³»ÃÖÃÊ ÁÖÀ¯ º¸Ç蹫·á °¡ÀÔ Á¤ºñ ÀÚµ¿Â÷ ¿ëÇ° ÇÒÀÎ ±â¾Æ ³ëºí·¹½º Æò»ý¿¬È¸ºñ ¸éÁ¦ Æ÷ÀÎÆ®³³ºÎ,°ø°ú±Ý Ä«µå°áÁ¦ ¼ºñ½º Çö´ëÁ¤À¯ §¤ ´ç 40¿ø ¿µÈ ¿¹¸Å Àå´ç 2,000¿ø ÇÒÀÎ KT ºôÇöóÀÚ »ç¿ëÇÑ 0.5%¸¦ ºÒ¿ìÀÌ¿ôµ½±â Æò»ý¿¬È¸ºñ ¸éÁ¦ ±ÝÀ¶¼ºñ½º 5¾ï ¹«·á º¸Çè »ç¶ûÀÇ ¼Õ°áÆì±â ±ÍÇÏÀÇ ¸ÞÀÏÁÖ¼Ò´Â À¥¼ÇÎÀ» ÅëÇØ ¼öÁýÇÑ °ÍÀ̸ç, ±×¿Ü¿¡ ¾î¶°ÇÑ Á¤º¸µµ °®°í ÀÖÁö ¾ÊÀ½À» ¹àÈü´Ï´Ù. ÀÌ E-mailÀº ¹ß½ÅÀü¿ëÀ̸ç, ¿øÄ¡ ¾ÊÀ¸½Ç °æ¿ì ¾Æ·¡ â¿¡ ¸ÞÀÏÁÖ¼Ò¸¦ ÀÔ·ÂÇÏ¿© ÁÖ½Ã¸é µÎ ¹ø ´Ù½Ã ¸ÞÀÏÀÌ °¡Áö ¾Êµµ·Ï ÇÏ°Ú½À´Ï´Ù. º» ¸ÞÀÏÀº Á¤º¸Åë½ÅºÎ ±Ç°í »çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡ [±¤°í]¶ó°í Ç¥½ÃµÈ ±¤°í ¸ÞÀÏÀÔ´Ï´Ù. ¹öÆ°À» Ŭ¸¯ÇÏ½Ã¸é ¼ö½Å°ÅºÎ󸮰¡ ÀÌ·ç¾î Áý´Ï´Ù. If you won't receive any more mail about this site, press button and fill your e-mail address. And then we will not send any mail to you [EMAIL PROTECTED]
Re: Kernel compile at aic7xxx/aicasm today's current.
Today's current gave me the following error while building a new kernel after a successful make world. cd /usr/src/sys/modules ; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/PIII850N/modules KMODDIR=/boot/kernel MACHINE=i386 make cleandir === 3dfx === accf_data === accf_http === agp === aha === aic7xxx === aic7xxx/aicasm make: don't know how to make cleandir. Stop *** Error code 2 Stop in /usr/src/sys/modules/aic7xxx. *** Error code 1 Ooops. I never use the buildkernel target. Try re-cvsup'ing and see if the change I just checked in fixes this for you. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel compile at aic7xxx/aicasm today's current.
Quoting Justin T. Gibbs [EMAIL PROTECTED]: | Today's current gave me the following error while building a new kernel | after a successful make world. | | cd /usr/src/sys/modules ; | MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/PIII850N/modules | KMODDIR=/boot/kernel MACHINE=i386 make cleandir | === 3dfx | === accf_data | === accf_http | === agp | === aha | === aic7xxx | === aic7xxx/aicasm | make: don't know how to make cleandir. Stop | *** Error code 2 | | Stop in /usr/src/sys/modules/aic7xxx. | *** Error code 1 | | Ooops. I never use the buildkernel target. Try re-cvsup'ing and see | if the change I just checked in fixes this for you. I'll do it right now. Thanks, ed To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI no longer disabled when APM enabled?
On Thu, 29 Aug 2002, Gavin Atkinson wrote:
Since the recent ACPI import (i believe), it seems that ACPI is no longer
disabled when APM is enabled. I do not explicitely disable API anywhere.
In the past, I have seen upon bootup a message apm: Other PM system
enabled. and the kernel would carry on booting as if ACPI had not been
loaded.
As a follow-up to this... adding the hint hint.acpi.0.disable=1 fixes
the suspend problems, but produces the following error messages on
boot-up:
unknown: PNP0303 can't assign resources (port)
unknown: PNP0f13 can't assign resources (irq)
unknown: PNP0700 can't assign resources (port)
unknown: PNP0501 can't assign resources (port)
unknown: PNP0401 can't assign resources (port)
These only exist with the acpi hint above. Removing the hint and
reverting to a previous kernel (where ACPI is disabled because APM is
enabled) shows them with the hint in place too, but obviously acpi is not
enabled then. I have confirmed that this is new with the latest acpi
import.
The recent heads-up about hw.acpi.0.disable=1 has not fixed the problem
I am seeing.
Those ISA PNP IDs correspond to,
/usr/src/sys/isa/atkbdc_isa.c: { 0x0303d041, Keyboard controller (i8042) },/*
PNP0303 */
/usr/src/sys/boot/common/pnpdata:ident=PNP0700 module=fd # PC standard
floppy disk controller
/usr/src/sys/boot/common/pnpdata:ident=PNP0501 module=sio#
16550A-compatible COM port
/usr/src/sys/boot/common/pnpdata:ident=PNP0401 module=lpt# ECP printer port
/usr/src/sys/isa/psm.c: { 0x130fd041, PS/2 mouse port }, /* PNP0F13 */
These devices seem to work fine however.
Gavin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Kernel compile at aic7xxx/aicasm today's current.
I now get a bit further: === aic7xxx === aic7xxx/aicasm make -f /.amd_mnt/han/host/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/Makefile MAKESRCPATH=/.amd_mnt/han/host/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm cleandir make -f /.amd_mnt/han/host/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/Makefile MAKESRCPATH=/.amd_mnt/han/host/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm clean rm -f aicasm_gram.h aicasm_macro_gram.h aicasm_gram.output aicasm_macro_gram.output aicasm aicasm.o aicasm_symbol.o aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o aicasm_macro_scan.o aicasm_scan.c aicasm_macro_scan.c aicasm_gram.c aicasm_gram.h aicasm_macro_gram.c aicasm_macro_gram.h make: don't know how to make cleandepend. Stop *** Error code 2 Stop in /.amd_mnt/han/host/usr/src/sys/modules/aic7xxx/aicasm. *** Error code 1 Stop in /.amd_mnt/han/host/usr/src/sys/modules/aic7xxx/aicasm. *** Error code 1 Stop in /.amd_mnt/han/host/usr/src/sys/modules/aic7xxx. *** Error code 1 Stop in /.amd_mnt/han/host/usr/src/sys/modules. *** Error code 1 Stop in /.amd_mnt/han/host/usr/obj/.amd_mnt/han/host/usr/src/sys/GREEDO. *** Error code 1 Stop in /.amd_mnt/han/host/usr/src. *** Error code 1 Stop in /.amd_mnt/han/host/usr/src. On Sat, Aug 31, 2002 at 08:50:33AM -0600, Justin T. Gibbs wrote: Today's current gave me the following error while building a new kernel after a successful make world. cd /usr/src/sys/modules ; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/PIII850N/modules KMODDIR=/boot/kernel MACHINE=i386 make cleandir === 3dfx === accf_data === accf_http === agp === aha === aic7xxx === aic7xxx/aicasm make: don't know how to make cleandir. Stop *** Error code 2 Stop in /usr/src/sys/modules/aic7xxx. *** Error code 1 Ooops. I never use the buildkernel target. Try re-cvsup'ing and see if the change I just checked in fixes this for you. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Bob WillcoxWe seem to have forgotten the simple truth that [EMAIL PROTECTED] reason is never perfect. Only non-sense attains Austin, TX perfection. -- Poul Henningsen [1894-1967] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Truss segfaults when tracing sshd
Submitter-Id: current-users
Originator:Anders Nordby [EMAIL PROTECTED]
Organization:
Confidential: no
Synopsis: Truss segfaults when tracing sshd
Severity: serious
Priority: medium
Category: bin
Class: sw-bug
Release: FreeBSD 5.0-CURRENT i386
Environment:
FreeBSD current 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Aug 31 09:31:05 GMT 2002
root@current:/usr/obj/usr/src/sys/MYGENERIC i386
Filesystems mounted:
/dev/ad0s1a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/ad0s1f on /tmp (ufs, local, soft-updates)
/dev/ad0s1g on /usr (ufs, local, soft-updates)
/dev/ad0s1e on /var (ufs, local, soft-updates)
eggsilo:/space/distfiles on /usr/ports/distfiles (nfs)
procfs on /proc (procfs, local)
The processor on the system is a 466 MHz Intel Celeron.
Description:
Find your sshd process:
# sockstat -l | grep sshd
root sshd 175 3 tcp6 *:22 *:*
root sshd 175 4 tcp4 *:22 *:*
Truss it through gdb:
# gdb truss
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
(no debugging symbols found)...
(gdb) run -p 175
Starting program: /usr/bin/truss -p 175
Now log in to the machine (I'm logging in as root), and return to gdb:
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x08049c77 in free ()
(gdb) bt
#0 0x08049c77 in free ()
#1 0x2806d000 in ?? ()
#2 0x08049e3e in free ()
#3 0x0804eb6d in free ()
#4 0x08049182 in free ()
#5 0x08048d31 in free ()
(gdb)
How-To-Repeat:
On a vanilla -current system from today:
# truss -p `sockstat -l | egrep 'sshd.*tcp4' | awk '{print $3}'`
Log into the system with sshd, and truss will segfault:
Segmentation fault (core dumped)
This also seems to happen if you truss sshd while logging out another ssh
session.
Fix:
N/A
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Kernel compile at aic7xxx/aicasm today's current.
[I tried to send this unicast to [EMAIL PROTECTED], but the attempt was rejected with an reason: 550 5.7.1 Access denied as the only excuse given for the behavior. dhw] Adding a cleandepend stanza similar to the just-added cleandir stanza seems to get beyond that. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] To paraphrase David Hilbert, there can be no conflicts between the discipline of systems administration and Microsoft, since they have nothing in common. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
New SCSI: can't 'make depend'
Apparently Makefile not have aicasm target (newly created clean building directory): rm -f .olddep if [ -f .depend ]; then mv .depend .olddep; fi make _kernel-depend cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -include opt_global.h -mpreferred-stack-boundary=2 -ffreestanding ../../../i386/i386/genassym.c NM=nm OBJFORMAT=elf sh ../../../kern/genassym.sh genassym.o assym.s awk -f ../../../tools/vnode_if.awk ../../../kern/vnode_if.src -h make: don't know how to make aicasm. Stop *** Error code 2 Stop in /usr/src/sys/i386/compile/POBRECITA. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New SCSI: can't 'make depend'
Apparently Makefile not have aicasm target (newly created clean building directory): I can't reproduce this here. My kernel Makefile includes an aicasm target. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New SCSI: can't 'make depend'
On Sat, Aug 31, 2002 at 11:15:55 -0600, Justin T. Gibbs wrote: Apparently Makefile not have aicasm target (newly created clean building directory): I can't reproduce this here. My kernel Makefile includes an aicasm target. From where aicasm target must come in? As I see, src/sys/conf/Makefile.i386 v1.257 not have it. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT's termcap broken
... # # and midnight commander shows all with -, +, | instead of # # pesudo-graphics. # # It seems this is the price we pay for alignment with what XFree86 ships. # # I see Wait, maybe I was too fast and there is a solution. Looking at the xterm FAQ, http://dickey.his.com/xterm/xterm.faq.html My terminal doesn't show box characters Xterm displays the 7-bit ASCII and VT100 graphic characters (including box corners) using specially arranged fixed-pitch fonts. The first 32 glyph positions (which would correspond to nonprinting control characters) are used to hold the VT100 graphic characters. Some fonts that otherwise look fine (such as courier) do not have glyphs defined for these positions. So they display as blanks. Use xfd to display the font. XFree86 xterm can form its own line-drawing characters (see patch 90, for example). It does not draw all of the graphic characters, only those that may be done with straight lines. But those are the most used, making most of the fixed-pitch fonts useful for xterm. You may also have a problem with the terminfo description. As distributed, the X11R6 terminfo for xterm does not have the acsc string defined, so most implementations of curses do not try to use the alternate character set. Finally, some people confuse the VT100 graphic characters with the VT220 support for DEC technical character set. These are distinct (7-bit) character sets. Xterm currently does not support this. I found that it is really dependent on the font. I use some IBM font from an AIX system (Rom14) by default, which has no box characters and thus displays blanks instead. If I use e.g. $ xterm -fn fixed -e midc I have all the box characters and midc looks good. Use $ xfd -fn whateverfont and look at the first 32 characters. Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New SCSI: can't 'make depend'
On Sat, Aug 31, 2002 at 11:15:55 -0600, Justin T. Gibbs wrote:
Apparently Makefile not have aicasm target (newly created clean
building directory):
I can't reproduce this here. My kernel Makefile includes an aicasm target.
I have only this lines included, but not aicasm target itself.
I have 'device ahc'.
Maybe tabs/spaces/continuation lines or 'config' issue with
/sys/conf/files?
I wonder about
optional ahc ahd
line here. Is it assumes that _both_ must be on?
aic7xxx_{seq.h,reg.h,reg_print.c}: $S/dev/aic7xxx/aic7xxx.{reg,seq}
$S/cam/scsi/scsi_message.h aicasm
./aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o
aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i
$S/dev/aic7xxx/aic7xxx_osm.h $S/dev/aic7xxx/aic7xxx.seq
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sat Aug 31 10:40:36 PDT 2002 -- === aic7xxx/aicasm make: don't know how to make cleandir. Stop *** Error code 2 Stop in /local0/scratch/des/src/sys/modules/aic7xxx. *** Error code 1 Stop in /local0/scratch/des/src/sys/modules. *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New SCSI: can't 'make depend'
On Sat, Aug 31, 2002 at 21:39:40 +0400, Andrey A. Chernov wrote:
I wonder about
optional ahc ahd
line here. Is it assumes that _both_ must be on?
Yes, it was the bug place. Here is the workaround which fix it for me:
--- files.bak Sat Aug 31 20:46:30 2002
+++ files Sat Aug 31 21:40:55 2002
@@ -4,7 +4,7 @@
# limitations in config: backslash-newline doesn't work in strings, and
# dependency lines other than the first are silently ignored.
#
-aicasm optional ahc ahd \
+aicasm optional ahc \
dependency $S/dev/aic7xxx/aicasm/*.[chyl] \
compile-with${MAKE} -f $S/dev/aic7xxx/aicasm/Makefile
MAKESRCPATH=$S/dev/aic7xxx/aicasm \
no-obj no-implicit-rule\
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: New SCSI: can't 'make depend'
I think this is in -STABLE not -CURRENT, I'm having this problem there. Later, George -- George V. Neville-Neil [EMAIL PROTECTED] Neville-Neil Consulting www.neville-neil.com I learn only to be contented. inscription at Ryoan-ji in Kyoto, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New SCSI: can't 'make depend'
On Sat, Aug 31, 2002 at 10:52:09 -0700, George V. Neville-Neil wrote: I think this is in -STABLE not -CURRENT, I'm having this problem there. The problem is in -current too, see my following optional ahc ahd bug explanation, aicasm target inserted only when _both_ of them are enabled. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 release schedule?
On Wed, Aug 28, 2002 at 09:28:20AM -0400, Bosko Milekic wrote: I think we're on our way to stabilizing -CURRENT enough for a DP2 soon. I would sit and wait it out just a tad longer. :-) A 5.0 DP2 branch was created just yesterday. So how ever good yesterday's -current was will affect DP2. I rather expected the release engineers to at least querry the lists to ask what the known issues are before picking which code to base DP2 on. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT's termcap broken
On Wed, Aug 28, 2002 at 09:41:05PM +0200, Jens Schweikhardt wrote: 20020827: Our /etc/termcap now has all the entries from the XFree86 xterm almost unchanged. This means xterm now supports color by default. If you used TERM=xterm-color in the past you now should use TERM=xterm. (xterm-color will lead to benign warnings). This is unacceptable -- you are breaking cross-platform (even -stable to -current) logins. TERM=xterm-color should work just as well and w/o warnings it did before your commit. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT's termcap broken
On Wed, Aug 28, 2002 at 07:06:40PM +0200, Jens Schweikhardt wrote: # Mutt shows this when I start vi as my editor or run fetchmail: # # TERMCAP, line 0, terminal 'xterm-color': enter_alt_charset_mode but no acs_chars # # My centericq window ends up using pipe signs (|), minus signs (-) and # plus signs (+) to draw boxes. . Please use plain TERM=xterm which now has color support. If any problems remain, please let me know. Are you saying to try TERM=xterm as a test, or that TERM=xterm-color is not longer supported? If the second, that is unacceptable. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT's termcap broken
On Wed, Aug 28, 2002 at 02:06:54PM -0500, Dan Nelson wrote: In the last episode (Aug 28), Jens Schweikhardt said: On Wed, Aug 28, 2002 at 07:35:32PM +0200, Sheldon Hearn wrote: # On (2002/08/28 19:04), Jens Schweikhardt wrote: # Yes, use plain TERM=xterm. It's got color now as it should. I'm # thinking of removing xterm-color if I can't resolve the # enter_alt_charset_mode stuff. Let me know if TERM=xterm does not # work as expected in mutt et al. I'll post a minor HEADS UP to # current@. # # Doesn't work for centericq or mutt. Are you sure? I use mutt too (in an rxvt), and TERM=xterm works wonderfully with colors. Hang on, will test mutt in plain xterm... yes, works there too. Older versions of the mutt port used the slang terminal library, which had (has?) a bug that assumed that all xterms supported color. It didn't matter what your termcap says. This is *totally* UNTRUE: /usr/local/bin//mutt: libslang.so = /usr/local/lib/libslang.so (0x280e5000) libm.so.2 = /usr/lib/libm.so.2 (0x28148000) libssl.so.2 = /usr/lib/libssl.so.2 (0x28167000) libcrypto.so.2 = /usr/lib/libcrypto.so.2 (0x28199000) libxpg4.so.3 = /usr/lib/libxpg4.so.3 (0x28263000) libintl.so.2 = /usr/local/lib/libintl.so.2 (0x28265000) libiconv.so.3 = /usr/local/lib/libiconv.so.3 (0x2826c000) libncurses.so.5 = /usr/lib/libncurses.so.5 (0x2834) libc.so.5 = /usr/lib/libc.so.5 (0x28382000) note the use of libslang. TERM=xterm and not having COLORTERM set, mutt will not use colors. TERM=xterm and COLORTERM=yes, mutt will use colors. TERM=xterm-color (COLORTERM set or not), mutt will use colors. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Tue, Aug 27, 2002 at 05:55:18PM -0700, Terry Lambert wrote: In general, though, the answer is that 3.1 sucks and 2.9x does not. 8-). Feh. 3.1's optimizer is less buggy in my experience. Use at least GCC 3.2, if you feel compelled to use a buggy non-maintenance release level GCC; alternately, wait for 3.3. What in the world are you trying to say?? non-maintenance release??? Why do you think 3.2 is buggy?? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bin/42255: Truss segfaults when tracing sshd
On Sat, Aug 31, 2002 at 05:45:26PM +0200, Anders Nordby wrote:
# truss -p `sockstat -l | egrep 'sshd.*tcp4' | awk '{print $3}'`
Log into the system with sshd, and truss will segfault:
There is an even easier way to reproduce this:
gonzo 9% sleep 10
[2] 35245
gonzo 10% truss -p 35245
*segfaults*
It is actually just strcmping a NULL syscall name, which can happen
if you truss a process which is waiting for a syscall to return
when you first attach to the process.
The patch below seems to fix the problem, but I Matthew would like
a more complex fix.
David.
ndex: syscalls.c
===
RCS file: /cvs/FreeBSD-CVS/src/usr.bin/truss/syscalls.c,v
retrieving revision 1.25
diff -u -r1.25 syscalls.c
--- syscalls.c 7 Aug 2002 11:35:18 - 1.25
+++ syscalls.c 31 Aug 2002 21:10:51 -
@@ -411,7 +411,7 @@
if (trussinfo-flags FOLLOWFORKS)
len += fprintf(trussinfo-outfile, %5d: , trussinfo-pid);
- if (!strcmp(name, execve) || !strcmp(name, exit)) {
+ if (name != NULL (!strcmp(name, execve) || !strcmp(name, exit))) {
clock_gettime(CLOCK_REALTIME, trussinfo-after);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Problems reading vmcores
I'm having difficulty reading vmcore images with gdb (either the system version or the port). (gdb) gohan10# gdb /a/kernel.debug /a/vmcore.0 GNU gdb 5.2.0 (FreeBSD) 20020627 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... /a/vmcore.0 is not a core dump: File format not recognized I have a lovely collection of panics from the bento cluster over the last 12 hours, but no way to get tracebacks. savecore: reboot after panic: ufs_dirbad: bad dir savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: page fault savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: sleeping thread owns a mutex savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: page fault savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: page fault savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: pipe buffer gone savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: Most recently used by AD driver savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 Kris msg42353/pgp0.pgp Description: PGP signature
Re: Problems reading vmcores
On Sat, 31 Aug 2002, Kris Kennaway wrote: I'm having difficulty reading vmcore images with gdb (either the system version or the port). (gdb) gohan10# gdb /a/kernel.debug /a/vmcore.0 But you need to specify the -k flag to gdb to use it against kernel dumps, I'm sure it will give much better results :) regards, - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
emu10k1 maintainer
Is there still someone maintaining the emu10k1 driver, or the pcm driver in general? -mg To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problems reading vmcores
On Sat, Aug 31, 2002 at 11:42:01PM +0200, Yann Berthier wrote: On Sat, 31 Aug 2002, Kris Kennaway wrote: I'm having difficulty reading vmcore images with gdb (either the system version or the port). (gdb) gohan10# gdb /a/kernel.debug /a/vmcore.0 But you need to specify the -k flag to gdb to use it against kernel dumps, I'm sure it will give much better results :) Oops, pasted the wrong thing: gohan10# gdb -k kernel.debug vmcore.0 GNU gdb 5.2.0 (FreeBSD) 20020627 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... /a/vmcore.0: Undefined error: 0. Kris msg42356/pgp0.pgp Description: PGP signature
Re: Problems reading vmcores
On Sat, Aug 31, 2002 at 03:00:43PM -0700, Kris Kennaway wrote: On Sat, Aug 31, 2002 at 11:42:01PM +0200, Yann Berthier wrote: On Sat, 31 Aug 2002, Kris Kennaway wrote: I'm having difficulty reading vmcore images with gdb (either the system version or the port). (gdb) gohan10# gdb /a/kernel.debug /a/vmcore.0 But you need to specify the -k flag to gdb to use it against kernel dumps, I'm sure it will give much better results :) Oops, pasted the wrong thing: gohan10# gdb -k kernel.debug vmcore.0 GNU gdb 5.2.0 (FreeBSD) 20020627 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... /a/vmcore.0: Undefined error: 0. Also gohan10# bin/gdb52 -k kernel.debug vmcore.0 GNU gdb 5.2 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-portbld-freebsd5.0... /a/vmcore.0: Bad file descriptor. Kris msg42357/pgp0.pgp Description: PGP signature
Re: gcc 3.1 / streambuf.h broken with using namespace std;
David O'Brien wrote: On Tue, Aug 27, 2002 at 05:55:18PM -0700, Terry Lambert wrote: In general, though, the answer is that 3.1 sucks and 2.9x does not. 8-). Feh. 3.1's optimizer is less buggy in my experience. Use at least GCC 3.2, if you feel compelled to use a buggy non-maintenance release level GCC; alternately, wait for 3.3. What in the world are you trying to say?? non-maintenance release??? Why do you think 3.2 is buggy?? Because rather than leaving it alone for a while, they are already planning a 3.3. 8-). And comments on this list to that effect. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
On Sat, Aug 31, 2002 at 03:06:08PM -0700, Terry Lambert wrote: David O'Brien wrote: On Tue, Aug 27, 2002 at 05:55:18PM -0700, Terry Lambert wrote: In general, though, the answer is that 3.1 sucks and 2.9x does not. 8-). Feh. 3.1's optimizer is less buggy in my experience. Use at least GCC 3.2, if you feel compelled to use a buggy non-maintenance release level GCC; alternately, wait for 3.3. What in the world are you trying to say?? non-maintenance release??? Why do you think 3.2 is buggy?? Because rather than leaving it alone for a while, they are already planning a 3.3. 8-). And comments on this list to that effect. I don't follow. The GCC group branches previous to a release and makes an initial + point releases from it. How is this different from FreeBSD? (other than they branch much before the .0 release and we don't). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problems reading vmcores
On Sat, 31 Aug 2002, Kris Kennaway wrote: On Sat, Aug 31, 2002 at 03:00:43PM -0700, Kris Kennaway wrote: On Sat, Aug 31, 2002 at 11:42:01PM +0200, Yann Berthier wrote: On Sat, 31 Aug 2002, Kris Kennaway wrote: I'm having difficulty reading vmcore images with gdb (either the system version or the port). (gdb) gohan10# gdb /a/kernel.debug /a/vmcore.0 But you need to specify the -k flag to gdb to use it against kernel dumps, I'm sure it will give much better results :) Oops, pasted the wrong thing: gohan10# gdb -k kernel.debug vmcore.0 GNU gdb 5.2.0 (FreeBSD) 20020627 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... /a/vmcore.0: Undefined error: 0. Also gohan10# bin/gdb52 -k kernel.debug vmcore.0 GNU gdb 5.2 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-portbld-freebsd5.0... /a/vmcore.0: Bad file descriptor. Sorry, I can't help you: I never uncountered this behavior, and certainly not on the recent kernel dumps I have under the hood. PS: I must admit I was a bit surprised by your initial post, I have classified it in the 'he must be aspleep / under caffeined ' category :) - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
David O'Brien wrote: Because rather than leaving it alone for a while, they are already planning a 3.3. 8-). And comments on this list to that effect. I don't follow. The GCC group branches previous to a release and makes an initial + point releases from it. I thought it was the general consensus that the 3.1 version of the compiler was broken, and generated bad code, and that the 3.2 compiler had a lot of these problems corrected, but destroyed binary compatability with 3.1. I guess the fear is that, if they are willing to destroy binary compatability between point releases, with another point release in the wings, it would be risky to pick the point release one behind to standardise upon. It was my understanding that FreeBSD 5.0 release was not going to be GCC 3.3 (because GCC 3.3 would not be released in time for FreeBSD to not be pulling a RedHat if they shipped a beta and called it 3.3) , might be GCC 3.2, and was currently down-rev from there. How is this different from FreeBSD? (other than they branch much before the .0 release and we don't). FreeBSD has been been branched for 18 months before the 5.0 release; what are you talking about?!? There's not much more much than that, in the entire history of GCC. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Page faults from bento cluster (Re: Problems reading vmcores)
I worked out what was wrong: some of them were very old vmcores that
had never been saved. There's another problem though, because those
machines have all panicked in the past 24 hours, so I don't know where
the remaining dumps went.
Kris
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x28
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc02012ed
stack pointer = 0x10:0xd7b24b1c
frame pointer = 0x10:0xd7b24b30
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 88342 (umount)
trap number = 12
panic: page fault
Uptime: 10h9m31s
Dumping 510 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 /usr/src/sys/kern/kern_shutdown.c: No such file or directory.
in /usr/src/sys/kern/kern_shutdown.c
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc0242ed4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345
#2 0xc024310b in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#3 0xc03a86f3 in trap_fatal (frame=0x104, eva=0)
at /usr/src/sys/i386/i386/trap.c:846
#4 0xc03a83d2 in trap_pfault (frame=0xd7b24adc, usermode=0, eva=40)
at /usr/src/sys/i386/i386/trap.c:760
#5 0xc03a7efd in trap (frame=
{tf_fs = -676200424, tf_es = -1071120368, tf_ds = -977731568, tf_edi = 0, tf_esi
= -977701728, tf_ebp = -676181200, tf_isp = -676181240, tf_ebx = -676181080, tf_edx =
-1006065664, tf_ecx = 0, tf_eax = -676181080, tf_trapno = 12, tf_err = 0, tf_eip =
-1071639827, tf_cs = 8, tf_eflags = 66118, tf_esp = -676181080, tf_ss = 104})
at /usr/src/sys/i386/i386/trap.c:446
#6 0xc0399a48 in calltrap () at {standard input}:98
#7 0xc029198d in vflush (mp=0xc4a75400, rootrefs=0, flags=2) at vnode_if.h:309
#8 0xc0200eaa in devfs_unmount (mp=0xc4a75400, mntflags=524288, td=0xc41b29c0)
at /usr/src/sys/fs/devfs/devfs_vfsops.c:130
#9 0xc028d9b4 in dounmount (mp=0xc4a75400, flags=-995666944, td=0xc41b29c0)
at /usr/src/sys/kern/vfs_mount.c:1296
#10 0xc028d79c in unmount (td=0xc41b29c0, uap=0xd7b24d10)
at /usr/src/sys/kern/vfs_mount.c:1239
#11 0xc03a8a31 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134845070, tf_esi = 134951997,
tf_ebp = -1077938952, tf_isp = -676180620, tf_ebx = 0, tf_edx = 1, tf_ecx = 3, tf_eax
= 22, tf_trapno = 12, tf_err = 2, tf_eip = 134524579, tf_cs = 31, tf_eflags = 514,
tf_esp = -1077939076, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1050
#12 0xc0399a9d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x28
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc02012ed
stack pointer = 0x10:0xd7b27b1c
frame pointer = 0x10:0xd7b27b30
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 50685 (umount)
trap number = 12
panic: page fault
Uptime: 10h24m57s
Dumping 510 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 /usr/src/sys/kern/kern_shutdown.c: No such file or directory.
in /usr/src/sys/kern/kern_shutdown.c
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc0242ed4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345
#2 0xc024310b in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#3 0xc03a86f3 in trap_fatal (frame=0x104, eva=0)
at /usr/src/sys/i386/i386/trap.c:846
#4 0xc03a83d2 in trap_pfault (frame=0xd7b27adc, usermode=0, eva=40)
at /usr/src/sys/i386/i386/trap.c:760
#5 0xc03a7efd in trap (frame=
{tf_fs = -676200424, tf_es = -1071120368, tf_ds = -977862640, tf_edi = 0, tf_esi
= -977815232, tf_ebp = -676168912, tf_isp = -676168952, tf_ebx = -676168792, tf_edx =
-1005847040, tf_ecx = 0, tf_eax = -676168792, tf_trapno = 12, tf_err = 0, tf_eip =
-1071639827, tf_cs = 8, tf_eflags = 66118, tf_esp = -676168792, tf_ss = 104})
at /usr/src/sys/i386/i386/trap.c:446
#6 0xc0399a48 in calltrap () at {standard input}:98
#7 0xc029198d in vflush (mp=0xc58d6c00, rootrefs=0, flags=2) at vnode_if.h:309
#8 0xc0200eaa in devfs_unmount (mp=0xc58d6c00, mntflags=524288, td=0xc41b2a80)
at /usr/src/sys/fs/devfs/devfs_vfsops.c:130
#9 0xc028d9b4 in dounmount
Re: Page faults from bento cluster (Re: Problems reading vmcores)
Another page fault in umount
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x28
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc02012ed
stack pointer = 0x10:0xda021b1c
frame pointer = 0x10:0xda021b30
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 40889 (umount)
trap number = 12
panic: page fault
Uptime: 1h54m17s
Dumping 510 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 /usr/src/sys/kern/kern_shutdown.c: No such file or directory.
in /usr/src/sys/kern/kern_shutdown.c
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc0242ed4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345
#2 0xc024310b in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#3 0xc03a86f3 in trap_fatal (frame=0x104, eva=0)
at /usr/src/sys/i386/i386/trap.c:846
#4 0xc03a83d2 in trap_pfault (frame=0xda021adc, usermode=0, eva=40)
at /usr/src/sys/i386/i386/trap.c:760
#5 0xc03a7efd in trap (frame=
{tf_fs = -637403112, tf_es = -1071120368, tf_ds = -989069296, tf_edi = 0, tf_esi
= -989006984, tf_ebp = -637396176, tf_isp = -637396216, tf_ebx = -637396056, tf_edx =
-1006065664, tf_ecx = 0, tf_eax = -637396056, tf_trapno = 12, tf_err = 0, tf_eip =
-1071639827, tf_cs = 8, tf_eflags = 66118, tf_esp = -637396056, tf_ss = 104})
at /usr/src/sys/i386/i386/trap.c:446
#6 0xc0399a48 in calltrap () at {standard input}:98
#7 0xc029198d in vflush (mp=0xc5e6, rootrefs=0, flags=2) at vnode_if.h:309
#8 0xc0200eaa in devfs_unmount (mp=0xc5e6, mntflags=524288, td=0xc5855000)
at /usr/src/sys/fs/devfs/devfs_vfsops.c:130
#9 0xc028d9b4 in dounmount (mp=0xc5e6, flags=-974782464, td=0xc5855000)
at /usr/src/sys/kern/vfs_mount.c:1296
#10 0xc028d79c in unmount (td=0xc5855000, uap=0xda021d10)
at /usr/src/sys/kern/vfs_mount.c:1239
#11 0xc03a8a31 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134845070, tf_esi = 134950973,
tf_ebp = -1077938936, tf_isp = -637395596, tf_ebx = 0, tf_edx = 1, tf_ecx = 3, tf_eax
= 22, tf_trapno = 12, tf_err = 2, tf_eip = 134524579, tf_cs = 31, tf_eflags = 514,
tf_esp = -1077939060, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1050
#12 0xc0399a9d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
msg42363/pgp0.pgp
Description: PGP signature
Re: Page faults from bento cluster (Re: Problems reading vmcores)
Another one. I have the cores if anyone needs to look at
them..otherwise I'll stop posting these for now.
Kris
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x4
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc021cd13
stack pointer = 0x10:0xda326a50
frame pointer = 0x10:0xda326a58
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 9298 (sh)
trap number = 12
panic: page fault
Uptime: 4h36m51s
Dumping 510 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 /usr/src/sys/kern/kern_shutdown.c: No such file or directory.
in /usr/src/sys/kern/kern_shutdown.c
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc0242ed4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345
#2 0xc024310b in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#3 0xc03a86f3 in trap_fatal (frame=0x104, eva=0)
at /usr/src/sys/i386/i386/trap.c:846
#4 0xc03a83d2 in trap_pfault (frame=0xda326a10, usermode=0, eva=4)
at /usr/src/sys/i386/i386/trap.c:760
#5 0xc03a7efd in trap (frame=
{tf_fs = 24, tf_es = -634257392, tf_ds = -1069219824, tf_edi = -634229836,
tf_esi = -1069110816, tf_ebp = -634230184, tf_isp = -634230212, tf_ebx = 40, tf_edx =
3, tf_ecx = -725475328, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071526637,
tf_cs = 8, tf_eflags = 66199, tf_esp = -725475328, tf_ss = 1})
at /usr/src/sys/i386/i386/trap.c:446
#6 0xc0399a48 in calltrap () at {standard input}:98
#7 0xc021d91f in exec_elf32_imgact (imgp=0xda326bb4) at imgact_elf.c:607
#8 0xc022a9a2 in execve (td=0xc484c240, uap=0xda326d10)
at /usr/src/sys/kern/kern_exec.c:280
#9 0xc03a8a31 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135022716, tf_esi = 0, tf_ebp =
-1077940704, tf_isp = -634229388, tf_ebx = 135022736, tf_edx = 135022736, tf_ecx =
135022895, tf_eax = 59, tf_trapno = 12, tf_err = 2, tf_eip = 134697908, tf_cs = 31,
tf_eflags = 659, tf_esp = -1077940748, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1050
#10 0xc0399a9d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
msg42364/pgp0.pgp
Description: PGP signature
why pay $35.00 when you can get better service for $14.95
LATEST NEWS: The new domain names are finally available to the general public at discount prices. Now you can register one of the exciting new .BIZ or .INFO domain names, as well as the original .COM and .NET names for just $14.95. These brand new domain extensions were recently approved by ICANN and have the same rights as the original .COM and .NET domain names. The biggest benefit is of-course that the .BIZ and .INFO domain names are currently more available. i.e. it will be much easier to register an attractive and easy-to-remember domain name for the same price. Visit: http://www.affordable-domains.com today for more info. Register your domain name today for just $14.95 at: http://www.affordable-domains.com/ Registration fees include full access to an easy-to-use control panel to manage your domain name in the future. Sincerely, Domain Administrator Affordable Domains To remove your email address from further promotional mailings from this company, click here: http://www.centralremovalservice.com/cgi-bin/domain-remove.cgi (e3)2546mEwQ5-744iAuM8195fXrJ4-346bVnF0707zRjD3-856vNfA9207sKbV8-757nFzR3106jDvN7-@73 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sat Aug 31 22:28:29 PDT 2002 -- === aic7xxx/ahc (null): Unable to malloc scope object *** Error code 70 Stop in /local0/scratch/des/src/sys/modules/aic7xxx/ahc. *** Error code 1 Stop in /local0/scratch/des/src/sys/modules/aic7xxx. *** Error code 1 Stop in /local0/scratch/des/src/sys/modules. *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
