Re: race condition in kern_descrip.c and fix
* David Xu [EMAIL PROTECTED] [020715 22:31] wrote:
I found a race condition in kern_descrip.c, the race is in function falloc(),
it opens a race window at line 1147:
You're right, however I'd appreciate it if you'd look deeper into the
possiblity of races in this code before committing this patch to make
sure we don't want to do this another way.
FILEDESC_UNLOCK(p-p_fd);
sx_xlock(filelist_lock);
FILEDESC_LOCK(p-p_fd);
fix:
--- kern_descrip.cTue Jul 16 12:29:44 2002
+++ kern_descrip.c.newTue Jul 16 12:26:50 2002
@@ -1107,6 +1107,7 @@
register struct file *fp, *fq;
int error, i;
+retry:
sx_xlock(filelist_lock);
if (nfiles = maxfiles) {
sx_xunlock(filelist_lock);
@@ -1151,6 +1152,13 @@
LIST_INSERT_AFTER(fq, fp, f_list);
} else {
LIST_INSERT_HEAD(filehead, fp, f_list);
+ }
+ if (p-p_fd-fd_ofiles[i] != NULL) {
+ fp-f_count = 0;
+ FILEDESC_UNLOCK(p-p_fd);
+ sx_xunlock(filelist_lock);
+ ffree(fp);
+ goto retry;
}
p-p_fd-fd_ofiles[i] = fp;
FILEDESC_UNLOCK(p-p_fd);
---
David Xu
--
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using 1970s technology,
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: NEWCARD
: Now I ofcourse have two additional questions : : 1) When trying to insert a Cisco Aironet 340 adapter, I get thrown to the : db prompt after it has found the card (which it seems to do nicely). If I : boot with it inserted, I only get to the detection, then the boot stops. At : boot up dmesg says the following on the bridge : : : cardbus0: CardBus bus on pccbb0 : pccard0: 16-bit PCCard bus on pccbb0 : pccbb1: TI1450 PCI-CardBus Bridge mem 0x4118-0x41180fff irq 11 at : device 4 : .1 on pci0 : cardbus1: CardBus bus on pccbb1 : pccard1: 16-bit PCCard bus on pccbb1 Traceback for the panic? Uhm, I am kinda new to this, so I have no idea how to get that to disk from the debugger...:( However, the error I get is Fatal trap 19: non-maskable interrupt trap while in kernel mode. If someone could help point me to how to write the traceback to disk I will mail it... - kurtis - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: make: don't know how to make GENERIC. Stop Damn, my bad. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
buildworld failure in libstdc++
Hi, a make depend in /usr/src/gnu/lib/libstdc++ breaks with: ... /usr/include/g++/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the X header for the X.h header for C++ includes, or sstream instead of the deprecated header strstream.h. To disable this warning use -Wno-deprecated. In file included from /usr/src/contrib/libstdc++/libsupc++/eh_alloc.cc:37: /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/contrib/libstdc++/libsupc++/eh_aux_runtime.cc:34: Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld failure in libstdc++
On Tue, 16 Jul 2002, Michael Reifenberger wrote: ... /usr/include/g++/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the X header for the X.h header for C++ includes, or sstream instead of the deprecated header strstream.h. To disable this warning use -Wno-deprecated. In file included from /usr/src/contrib/libstdc++/libsupc++/eh_alloc.cc:37: /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/contrib/libstdc++/libsupc++/eh_aux_runtime.cc:34: Just after writing I started thinking :-( I was missing the + in /etc/make.conf's CFLAGS += ... and CXXFLAGS += ... Sorry for the false alarm. Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 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/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === gnu/lib/libobjc === gnu/lib/libg2c === gnu/usr.bin === gnu/usr.bin/bc === gnu/usr.bin/binutils === gnu/usr.bin/binutils/libiberty === gnu/usr.bin/binutils/libbfd cc1: warnings being treated as errors /usr/home/des/tinderbox/sparc64/src/contrib/binutils/bfd/elf-eh-frame.c: In function `_bfd_elf_discard_section_eh_frame': /usr/home/des/tinderbox/sparc64/src/contrib/binutils/bfd/elf-eh-frame.c:417: warning: comparison between signed and unsigned *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/gnu/usr.bin/binutils/libbfd. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/gnu/usr.bin/binutils. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/gnu/usr.bin. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/gnu. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Still no XFree86-4?
Hello I erased my /usr/ports just to be sure that all the diffrent patches out, then cvsuped to get the latest version, to my disepointment XFree86-4 Still dosn't build under Current, I still got the same perl error in fonts, the perl port is installed. Does anyone have a working patch? /John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: openoffice is compiling again!...but won't run.
On Fri, Jul 12, 2002 at 10:02:35AM +0200, Martin Blapp wrote: sjlj and dwarf2 work. But the problem with CURRENT is that this patch seems to be needed. (Patch from Alexander Kabaev) This patch is wrong. I committed a correct one from Alxander. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Still no XFree86-4?
John, On Tue, Jul 16, 2002 at 12:04:53PM +0200, John Angelmo wrote: I erased my /usr/ports just to be sure that all the diffrent patches out, then cvsuped to get the latest version, to my disepointment XFree86-4 Still dosn't build under Current, I still got the same perl error in fonts, the perl port is installed. Try to say as root use.perl port. Does anyone have a working patch? It doesn't seem to me that moving perl executable from /usr/bin to /usr/local/bin can affect executing of perl scripts. Andrew. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_GETATTR panic on Alpha
Dag-Erling Smorgrav writes: Andrew Gallatin [EMAIL PROTECTED] writes: Welcome to hell. Thanks, it sure looks cozy in here :) If you clear panicstr, you have a chance of getting a dump. How do I do that? Just clear panicstr (w panicstr 0) when you drop into the debugger on a panic. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_GETATTR panic on Alpha
Andrew Gallatin [EMAIL PROTECTED] writes:
Just clear panicstr (w panicstr 0) when you drop into
the debugger on a panic.
No luck. However, I added an ASSERT_VOP_LOCKED() to vn_statfile(),
and confirmed that vn_lock() fails to lock the vnode. Unfortunately,
without a dump it's hard to tell exactly what kind of vnode we're
dealing with.
I thought the problem might be an incorrect vop_lock implementation in
devfs (the only synthetic filesystem mounted on the box), but devfs
uses std_{islocked,lock,unlock}, and visual inspection didn't uncover
any obvious flaws in any of those.
Any other suggestions before I just turn off DEBUG_VFS_LOCKS?
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: buildworld failure in libstdc++
On Tue, Jul 16, 2002 at 11:54:02AM +0200, Michael Reifenberger wrote: On Tue, 16 Jul 2002, Michael Reifenberger wrote: ... /usr/include/g++/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the X header for the X.h header for C++ includes, or sstream instead of the deprecated header strstream.h. To disable this warning use -Wno-deprecated. In file included from /usr/src/contrib/libstdc++/libsupc++/eh_alloc.cc:37: /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/contrib/libstdc++/libsupc++/eh_aux_runtime.cc:34: Just after writing I started thinking :-( I was missing the + in /etc/make.conf's CFLAGS += ... and CXXFLAGS += ... Sorry for the false alarm. You don't need a + in CFLAGS in /etc/make.conf. You need a += in CXXFLAGS if you want CXXFLAGS to contain the contents of CFLAGS. See /usr/share/examples/etc/make.conf. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_GETATTR panic on Alpha
Hi! On Tue, Jul 16, 2002 at 02:45:11PM +0200, Dag-Erling Smorgrav wrote: The following panic is 100% reproducable - it happens whenever I boot a recent kernel on Alpha, just before init(8) starts getty(8) on the console: sorry, kernel from today's sources at 17:38 works just fine. Yet another question about kernel core dumps: what should I do to get one?-) Why panic from debugger on i386 gives core dump and reboots the system and panic from debugger on Alpha does not? Andrew. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Still no XFree86-4?
This was posted on 11 July: http://people.freebsd.org/~anholt/files/x420diff-1 I did have to manually copy Wraphelp.c somewhere in the font-server port, but things built fine after that. -- abcjr On Tue, Jul 16, 2002 at 12:04:53PM +0200, John Angelmo wrote: Hello I erased my /usr/ports just to be sure that all the diffrent patches out, then cvsuped to get the latest version, to my disepointment XFree86-4 Still dosn't build under Current, I still got the same perl error in fonts, the perl port is installed. Does anyone have a working patch? /John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_GETATTR panic on Alpha
On 16 Jul, Dag-Erling Smorgrav wrote:
Andrew Gallatin [EMAIL PROTECTED] writes:
Just clear panicstr (w panicstr 0) when you drop into
the debugger on a panic.
No luck. However, I added an ASSERT_VOP_LOCKED() to vn_statfile(),
and confirmed that vn_lock() fails to lock the vnode. Unfortunately,
without a dump it's hard to tell exactly what kind of vnode we're
dealing with.
I thought the problem might be an incorrect vop_lock implementation in
devfs (the only synthetic filesystem mounted on the box), but devfs
uses std_{islocked,lock,unlock}, and visual inspection didn't uncover
any obvious flaws in any of those.
Any other suggestions before I just turn off DEBUG_VFS_LOCKS?
Turn it off. I ran into similar problems about a week ago and the
author told me that this option was broken because only part of the
stuff in his private source tree was committed. I haven't heard
anything since then to make me think that this option has been fixed.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
integer devide fault in dummynet_io
Hello. I have the following rules in my ipfw.rules:
pipe 1 config bw 3kbit/s
add 1000 pipe 1 log logamount 0 tcp from any to me 80 setup in
add 1010 pipe 1 log logamount 0 tcp from any to me 25 setup in
so that I can log and slow down incoming Nimda/open-relay probes.
After new ipfw code came into the tree, my machine started to panic
occasionally after thirty minutes or so connected to the Internet.
After a few panics, I managed to get the backtrace. Unfortunately the
line number seems to be screwed, but it's still enough to spot where
it panicked (attached).
In the frame 15 in dummynet_io(), fs-weight was holding zero at line 1182,
which leads to a zero-division. Suprisingly, 'action' was O_LOG rather than
O_PIPE or O_QUEUE, even though the function is assuming only one of them.
I'm running current as of 2002-06-29(UTC) with the following files
updated to more recent revisions:
/sys/netinet/ip_fw.h1.70
/sys/netinet/ip_fw2.c 1.3
/usr/src/sbin/ipfw/ipfw2.c 1.3
Any idea to fix this?
GNU gdb 4.18 (FreeBSD)
Copyright 1998 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-unknown-freebsd...
IdlePTD at physical address 0x004cc000
initial pcb at physical address 0x0034fe40
panicstr: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 18: integer divide fault while in kernel mode
instruction pointer = 0x8:0xc02d198b
stack pointer = 0x10:0xc6251b08
frame pointer = 0x10:0xc6251b8c
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 = 12 (swi1: net)
trap number = 18
panic: integer divide fault
syncing disks... panic: bwrite: buffer is not busy???
Uptime: 1h4m54s
Dumping 63 MB
ata0: resetting devices .. ata0: mask=03 ostat0=50 ostat2=00
ad0: ATAPI 00 00
ata0-slave: ATAPI 00 00
ata0: mask=03 stat0=50 stat1=00
ad0: ATA 01 a5
ata0: devices=01
ad0: success setting PIO4 on generic chip
done
16 32 48
---
b#0 0xc018b4c1 in doadump () at /usr/src/sys/kern/kern_shutdown.c:353
353 }
(kgdb) bt
#0 0xc018b4c1 in doadump () at /usr/src/sys/kern/kern_shutdown.c:353
#1 0xc018b94b in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:353
#2 0xc018bb2d in panic (fmt=0xc02eb9cb bwrite: buffer is not busy???)
at /usr/src/sys/kern/kern_shutdown.c:353
#3 0xc01c4ea2 in bwrite (bp=0xc2523120) at /usr/src/sys/kern/vfs_bio.c:1368
#4 0xc01c642e in vfs_bio_awrite (bp=0xc2523120)
at /usr/src/sys/kern/vfs_bio.c:1368
#5 0xc0160b4b in spec_fsync (ap=0xc6251950)
at /usr/src/sys/fs/specfs/spec_vnops.c:837
#6 0xc016068c in spec_vnoperate (ap=0xc6251950)
at /usr/src/sys/fs/specfs/spec_vnops.c:837
#7 0xc026e743 in ffs_sync (mp=0xc1275000, waitfor=2, cred=0xc09dcd80,
td=0xc031eb20) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:813
#8 0xc01d65bb in sync (td=0xc031eb20, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:584
#9 0xc018b5bc in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:353
#10 0xc018bb2d in panic (fmt=0xc030ccde %s)
at /usr/src/sys/kern/kern_shutdown.c:353
#11 0xc02c0683 in trap_fatal (frame=0xc6251ac8, eva=0)
at /usr/src/sys/i386/i386/trap.c:655
#12 0xc02c00c2 in trap (frame={tf_fs = 24, tf_es = -1070727152, tf_ds = 16,
tf_edi = 1, tf_esi = 0, tf_ebp = -970646644, tf_isp = -970646796,
tf_ebx = 3145728, tf_edx = 0, tf_ecx = 0, tf_eax = 1, tf_trapno = 18,
tf_err = 0, tf_eip = -1070786165, tf_cs = 8, tf_eflags = 66118,
tf_esp = 0, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:655
#13 0xc02d198b in __qdivrem (uq=3145728, vq=0, arq=0x0)
at /usr/src/sys/libkern/qdivrem.c:277
#14 0xc02d1e2e in __udivdi3 (a=3145728, b=0)
at /usr/src/sys/libkern/udivdi3.c:51
#15 0xc01f9c69 in dummynet_io (m=0xc0a10d00, pipe_nr=1, dir=2, fwa=0xc6251c44)
at /usr/src/sys/netinet/ip_dummynet.c:1227
#16 0xc01ffcf2 in ip_input (m=0xc0a10d00)
at /usr/src/sys/netinet/ip_input.c:843
#17 0xc0200452 in ipintr () at /usr/src/sys/netinet/ip_input.c:843
#18 0xc0178ed7 in swi_net (dummy=0x0) at /usr/src/sys/kern/kern_intr.c:561
#19 0xc0178bf6 in ithread_loop (arg=0xc09f8100)
at /usr/src/sys/kern/kern_intr.c:561
#20 0xc0177ec6 in fork_exit (callout=0xc0178a34 ithread_loop,
arg=0xc09f8100, frame=0xc6251d48) at /usr/src/sys/kern/kern_fork.c:734
(kgdb) frame 15
#15 0xc01f9c69 in dummynet_io (m=0xc0a10d00, pipe_nr=1, dir=2, fwa=0xc6251c44)
at /usr/src/sys/netinet/ip_dummynet.c:1227
1227}
(kgdb) list
1222splx(s);
1223if (q)
1224q-drops++ ;
1225m_freem(m);
1226return ENOBUFS ;
1227}
1228
1229/*
1230 *
Re: sparc64 tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: -- stage 4: building everything.. -- === gnu/lib/libobjc === gnu/lib/libg2c === gnu/usr.bin === gnu/usr.bin/bc === gnu/usr.bin/binutils === gnu/usr.bin/binutils/libiberty === gnu/usr.bin/binutils/libbfd cc1: warnings being treated as errors /usr/home/des/tinderbox/sparc64/src/contrib/binutils/bfd/elf-eh-frame.c: In function `_bfd_elf_discard_section_eh_frame': /usr/home/des/tinderbox/sparc64/src/contrib/binutils/bfd/elf-eh-frame.c:417: warning: comparison between signed and unsigned *** Error code 1 I've reduced the WARNS level in the sparc64 case until David has a chance to look at my patch which fixes this warning. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: integer devide fault in dummynet_io
thanks for the report, i am going to commit a fix for this soon.
It is funny that i remember to have hit exactly this bug myself
some time ago, and i thought i had fixed it already, presumably
the change got lost at some point...
cheers
luigi
Hello. I have the following rules in my ipfw.rules:
pipe 1 config bw 3kbit/s
add 1000 pipe 1 log logamount 0 tcp from any to me 80 setup in
add 1010 pipe 1 log logamount 0 tcp from any to me 25 setup in
so that I can log and slow down incoming Nimda/open-relay probes.
After new ipfw code came into the tree, my machine started to panic
occasionally after thirty minutes or so connected to the Internet.
After a few panics, I managed to get the backtrace. Unfortunately the
line number seems to be screwed, but it's still enough to spot where
it panicked (attached).
In the frame 15 in dummynet_io(), fs-weight was holding zero at line 1182,
which leads to a zero-division. Suprisingly, 'action' was O_LOG rather than
O_PIPE or O_QUEUE, even though the function is assuming only one of them.
I'm running current as of 2002-06-29(UTC) with the following files
updated to more recent revisions:
/sys/netinet/ip_fw.h1.70
/sys/netinet/ip_fw2.c 1.3
/usr/src/sbin/ipfw/ipfw2.c 1.3
Any idea to fix this?
GNU gdb 4.18 (FreeBSD)
Copyright 1998 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-unknown-freebsd...
IdlePTD at physical address 0x004cc000
initial pcb at physical address 0x0034fe40
panicstr: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 18: integer divide fault while in kernel mode
instruction pointer = 0x8:0xc02d198b
stack pointer = 0x10:0xc6251b08
frame pointer = 0x10:0xc6251b8c
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 = 12 (swi1: net)
trap number = 18
panic: integer divide fault
syncing disks... panic: bwrite: buffer is not busy???
Uptime: 1h4m54s
Dumping 63 MB
ata0: resetting devices .. ata0: mask=03 ostat0=50 ostat2=00
ad0: ATAPI 00 00
ata0-slave: ATAPI 00 00
ata0: mask=03 stat0=50 stat1=00
ad0: ATA 01 a5
ata0: devices=01
ad0: success setting PIO4 on generic chip
done
16 32 48
---
b#0 0xc018b4c1 in doadump () at /usr/src/sys/kern/kern_shutdown.c:353
353 }
(kgdb) bt
#0 0xc018b4c1 in doadump () at /usr/src/sys/kern/kern_shutdown.c:353
#1 0xc018b94b in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:353
#2 0xc018bb2d in panic (fmt=0xc02eb9cb bwrite: buffer is not busy???)
at /usr/src/sys/kern/kern_shutdown.c:353
#3 0xc01c4ea2 in bwrite (bp=0xc2523120) at /usr/src/sys/kern/vfs_bio.c:1368
#4 0xc01c642e in vfs_bio_awrite (bp=0xc2523120)
at /usr/src/sys/kern/vfs_bio.c:1368
#5 0xc0160b4b in spec_fsync (ap=0xc6251950)
at /usr/src/sys/fs/specfs/spec_vnops.c:837
#6 0xc016068c in spec_vnoperate (ap=0xc6251950)
at /usr/src/sys/fs/specfs/spec_vnops.c:837
#7 0xc026e743 in ffs_sync (mp=0xc1275000, waitfor=2, cred=0xc09dcd80,
td=0xc031eb20) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:813
#8 0xc01d65bb in sync (td=0xc031eb20, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:584
#9 0xc018b5bc in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:353
#10 0xc018bb2d in panic (fmt=0xc030ccde %s)
at /usr/src/sys/kern/kern_shutdown.c:353
#11 0xc02c0683 in trap_fatal (frame=0xc6251ac8, eva=0)
at /usr/src/sys/i386/i386/trap.c:655
#12 0xc02c00c2 in trap (frame={tf_fs = 24, tf_es = -1070727152, tf_ds = 16,
tf_edi = 1, tf_esi = 0, tf_ebp = -970646644, tf_isp = -970646796,
tf_ebx = 3145728, tf_edx = 0, tf_ecx = 0, tf_eax = 1, tf_trapno = 18,
tf_err = 0, tf_eip = -1070786165, tf_cs = 8, tf_eflags = 66118,
tf_esp = 0, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:655
#13 0xc02d198b in __qdivrem (uq=3145728, vq=0, arq=0x0)
at /usr/src/sys/libkern/qdivrem.c:277
#14 0xc02d1e2e in __udivdi3 (a=3145728, b=0)
at /usr/src/sys/libkern/udivdi3.c:51
#15 0xc01f9c69 in dummynet_io (m=0xc0a10d00, pipe_nr=1, dir=2, fwa=0xc6251c44)
at /usr/src/sys/netinet/ip_dummynet.c:1227
#16 0xc01ffcf2 in ip_input (m=0xc0a10d00)
at /usr/src/sys/netinet/ip_input.c:843
#17 0xc0200452 in ipintr () at /usr/src/sys/netinet/ip_input.c:843
#18 0xc0178ed7 in swi_net (dummy=0x0) at /usr/src/sys/kern/kern_intr.c:561
#19 0xc0178bf6 in ithread_loop (arg=0xc09f8100)
at /usr/src/sys/kern/kern_intr.c:561
#20 0xc0177ec6 in fork_exit (callout=0xc0178a34 ithread_loop,
arg=0xc09f8100, frame=0xc6251d48) at
/usr/src/dev/md error (?)
Hello, I got error on step make buildkernel KERNCONF=MANDIRI : cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -W missing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -n ostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/ac pica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/../include -D_KERNEL -includ e opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/md/md.c cc1: warnings being treated as errors /usr/src/sys/dev/md/md.c: In function `md_kthread': /usr/src/sys/dev/md/md.c:570: warning: `error' might be used uninitialized in th is function *** Error code 1 Stop in /usr/obj/usr/src/sys/MANDIRI. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. mandiri# did I miss something ? thanks ! -dikshie- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_GETATTR panic on Alpha
Andrew Kolchoogin [EMAIL PROTECTED] writes: sorry, kernel from today's sources at 17:38 works just fine. Try with DEBUG_VFS_LOCKS. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_GETATTR panic on Alpha
Andrew Kolchoogin writes:
Hi!
On Tue, Jul 16, 2002 at 02:45:11PM +0200, Dag-Erling Smorgrav wrote:
The following panic is 100% reproducable - it happens whenever I boot
a recent kernel on Alpha, just before init(8) starts getty(8) on the
console:
sorry, kernel from today's sources at 17:38 works just fine.
Yet another question about kernel core dumps: what should I do to get one?-)
Why panic from debugger on i386 gives core dump and reboots the system
and panic from debugger on Alpha does not?
Because, as BDE says, that crashdumps work at all is mosty accidental.
On alpha, a random kernel thread is waking up, and is unable to go
back to sleep because of the panicstr hack msleep:
mtx_lock_spin(sched_lock);
if (cold || panicstr) {
/*
* After a panic, or during autoconfiguration,
* just give interrupts a chance, then just return;
* don't run any other procs or panic below,
* in case this is the idle process and already asleep.
*/
if (mtx != NULL priority PDROP)
mtx_unlock(mtx);
mtx_unlock_spin(sched_lock);
return (0);
}
We need to somehow let only interrupt threads and the panic'ed process
run after a panic. I have no idea how to do this in a clean,
low-impact way.
Drew
PS: I was trying to make crashdumps fail on x86 by increasing HZ. But
I cannot. I have no idea why this only happens on alpha.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: VOP_GETATTR panic on Alpha
Hi! On Tue, Jul 16, 2002 at 05:59:16PM +0200, Dag-Erling Smorgrav wrote: sorry, kernel from today's sources at 17:38 works just fine. Try with DEBUG_VFS_LOCKS. Well. Say that me is the lamest programmer at the world. :) My Alpha DOESN'T go to debugger. Instead it hungs in the internals of the kernel. Break on serial console brings me to debugger. Instead of that it doesn't respond neither to the network nor the serial console. Andrew. P.S. Well, I'll try to get kernel core dump and analyse it using debugger. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_GETATTR panic on Alpha
Andrew, On Tue, Jul 16, 2002 at 01:46:16PM -0400, Andrew Gallatin wrote: PS: I was trying to make crashdumps fail on x86 by increasing HZ. But I cannot. I have no idea why this only happens on alpha. have you any ideas what we should to test?-) Andrew. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_GETATTR panic on Alpha
On 16-Jul-2002 Andrew Gallatin wrote:
Andrew Kolchoogin writes:
Hi!
On Tue, Jul 16, 2002 at 02:45:11PM +0200, Dag-Erling Smorgrav wrote:
The following panic is 100% reproducable - it happens whenever I boot
a recent kernel on Alpha, just before init(8) starts getty(8) on the
console:
sorry, kernel from today's sources at 17:38 works just fine.
Yet another question about kernel core dumps: what should I do to get one?-)
Why panic from debugger on i386 gives core dump and reboots the system
and panic from debugger on Alpha does not?
Because, as BDE says, that crashdumps work at all is mosty accidental.
On alpha, a random kernel thread is waking up, and is unable to go
back to sleep because of the panicstr hack msleep:
mtx_lock_spin(sched_lock);
if (cold || panicstr) {
/*
* After a panic, or during autoconfiguration,
* just give interrupts a chance, then just return;
* don't run any other procs or panic below,
* in case this is the idle process and already asleep.
*/
if (mtx != NULL priority PDROP)
mtx_unlock(mtx);
mtx_unlock_spin(sched_lock);
return (0);
}
We need to somehow let only interrupt threads and the panic'ed process
run after a panic. I have no idea how to do this in a clean,
low-impact way.
It's probably preemption. However, the problem may be that you can't
switch to the ithread if you just turn preemption on for panics because
the ithread may already be on the run queue, thus why your earlier patch
may not have worked. Try to see if it works ok if you turn on preemption
fully by making the second arg to ithread_schedule() be !cold. FWIW, I
only have problems with preemption on alphas if I use SMP.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: VOP_GETATTR panic on Alpha
On 16-Jul-2002 Andrew Gallatin wrote:
Alfred Perlstein writes:
We need to somehow let only interrupt threads and the panic'ed process
run after a panic. I have no idea how to do this in a clean,
low-impact way.
Drew
PS: I was trying to make crashdumps fail on x86 by increasing HZ. But
I cannot. I have no idea why this only happens on alpha.
um, psuedocode...
for ithreads, td-td_flags |= TD_ITHREAD
for panicing thread, td-td_flags |= TD_INPANIC
if ((cold || panicstr) (td-td_flags (TD_ITHREAD|TD_INPANIC)) != 0) {
I have no idea what's planned for td_flags. Is stealing 2 values for
this use acceptable? I didn't consider touching the flags to be
lightweight..
If so, I was thinking more like
#define TDF_PANICSCHED 0x02 /* may be scheduled during/after a panic */
You can already do if (td-td_ithd != NULL) to do the TD_ITHREAD test.
The problem is that this won't work if there is a process on the run queue with
a higher priority than the currently running process.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: buildworld failure in libstdc++
On Tue, 16 Jul 2002, Steve Kargl wrote: Date: Tue, 16 Jul 2002 07:30:01 -0700 From: Steve Kargl [EMAIL PROTECTED] To: Michael Reifenberger [EMAIL PROTECTED] Cc: FreeBSD-Current [EMAIL PROTECTED] Subject: Re: buildworld failure in libstdc++ ... You don't need a + in CFLAGS in /etc/make.conf. You need a += in CXXFLAGS if you want CXXFLAGS to contain the contents of CFLAGS. See /usr/share/examples/etc/make.conf. Ah, I see. Thanks! BTW: I need NO_WARNS=YES to get /usr/src/libexec/rtld-elf compiled. Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_GETATTR panic on Alpha
John Baldwin writes: We need to somehow let only interrupt threads and the panic'ed process run after a panic. I have no idea how to do this in a clean, low-impact way. It's probably preemption. However, the problem may be that you can't switch to the ithread if you just turn preemption on for panics because the ithread may already be on the run queue, thus why your earlier patch may not have worked. Try to see if it works ok if you turn on preemption fully by making the second arg to ithread_schedule() be !cold. FWIW, I only have problems with preemption on alphas if I use SMP. I think its more than this. I tried unconditionally enabling premption, and I see no improvement. After a panic, it wedges, and I see this : db c syncing disks... done Uptime: 4m26s [halt sent] Stopped at siointr1+0x198: br zero,siointr1+0x330 zero=0x0 db tr siointr1() at siointr1+0x198 siointr() at siointr+0x40 isa_handle_fast_intr() at isa_handle_fast_intr+0x24 alpha_dispatch_intr() at alpha_dispatch_intr+0xd0 interrupt() at interrupt+0x110 XentInt() at XentInt+0x28 --- interrupt (from ipl 0) --- critical_exit() at critical_exit+0x20 _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0xc4 msleep() at msleep+0x2b0 buf_daemon() at buf_daemon+0x1f4 fork_exit() at fork_exit+0xe0 exception_return() at exception_return --- root of call graph --- So its still stuck in msleep. How is it supposed to get back to the panic'ed thread if a system thread wakes up and is not allowed to go back to sleep??? Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_GETATTR panic on Alpha
On 16-Jul-2002 Andrew Gallatin wrote: John Baldwin writes: We need to somehow let only interrupt threads and the panic'ed process run after a panic. I have no idea how to do this in a clean, low-impact way. It's probably preemption. However, the problem may be that you can't switch to the ithread if you just turn preemption on for panics because the ithread may already be on the run queue, thus why your earlier patch may not have worked. Try to see if it works ok if you turn on preemption fully by making the second arg to ithread_schedule() be !cold. FWIW, I only have problems with preemption on alphas if I use SMP. I think its more than this. I tried unconditionally enabling premption, and I see no improvement. After a panic, it wedges, and I see this : db c syncing disks... done Uptime: 4m26s [halt sent] Stopped at siointr1+0x198: br zero,siointr1+0x330 zero=0x0 db tr siointr1() at siointr1+0x198 siointr() at siointr+0x40 isa_handle_fast_intr() at isa_handle_fast_intr+0x24 alpha_dispatch_intr() at alpha_dispatch_intr+0xd0 interrupt() at interrupt+0x110 XentInt() at XentInt+0x28 --- interrupt (from ipl 0) --- critical_exit() at critical_exit+0x20 _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0xc4 msleep() at msleep+0x2b0 buf_daemon() at buf_daemon+0x1f4 fork_exit() at fork_exit+0xe0 exception_return() at exception_return --- root of call graph --- So its still stuck in msleep. How is it supposed to get back to the panic'ed thread if a system thread wakes up and is not allowed to go back to sleep??? Hm. Surprised we don't see this on other archs then (or maybe we do...). Probably when we have panic'd (and after we leave the debugger and go into boot() or some such) we should take any non-P_SYSTEM processes off the run queues and then remove the panicstr checks from msleep() and the condition variable wait functions. Perhaps better is to dink around in choosethread() so that if panicstr is set, we throw away any threads get that aren't P_SYSTEM or have the TDF_INPANIC flag set. By throw away, I mean that we just ignore any such threads and loop if we get one we want to throw away. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_GETATTR panic on Alpha
John Baldwin writes:
So its still stuck in msleep. How is it supposed to get back to
the panic'ed thread if a system thread wakes up and is not allowed to
go back to sleep???
Hm. Surprised we don't see this on other archs then (or maybe
we do...). Probably when we have panic'd (and after we leave the
debugger and go into boot() or some such) we should take any non-P_SYSTEM
processes off the run queues and then remove the panicstr checks from
msleep() and the condition variable wait functions.
Do you have something like the following psuedo code in mind?
Perhaps placed just prior to the call to boot() in panic()?
foreach p in (all procs in system) {
if (p == curproc)
continue
if (p-p_flag P_SYSTEM)
continue;
foreach td in (all threads in p)
if (td-td_state == TDS_RUNQ)
remrunqueue(td);
}
I assume a panic will IPI other processors and halt them in their
tracks so we don't need to worry too much about locking?
Perhaps better is to dink around in choosethread() so that if panicstr
is set, we throw away any threads get that aren't P_SYSTEM or have the
TDF_INPANIC flag set. By throw away, I mean that we just ignore any such
threads and loop if we get one we want to throw away.
I think that I like your first idea better..
Drew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Current (DP1) on Toshiba 5005
Rob Hughes wrote: All, I have a Toshiba 5005-S504 laptop (a wonderful legacy-free box that's I've cussed to no end) that I'm trying to get DP1 to boot on so I can cvsup and take a look (and hopefully contribute something). I was able to install, but after installation the system soft hangs after displaying a message about CPU power states (sorry, going off memory for now). I'm able to break to the debugger, so what information from dbg would be helpful at this point? Also, I'm pretty sure it's acpi that's causing the problem, so would someone point me to the syntax for disabling a module preload? Thanks, Rob I was tracking down a similar hang and had to disable acpi (turns out I'm an idiot and the apparent hang at boot was because I forgot console was redirected to the serial port of the machine next to it), but I had to jump through hoops to do it it seems. I believe all you have to do is 'unset acpi_load' at the boot loader prompt. I had tried 'set acpi_load=NO', and finally 'unset module_path' to keep the kernel from finding /boot/kernel/acpi.ko. Hope this helps, Anthony Jenkins To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_GETATTR panic on Alpha
On 16-Jul-2002 Andrew Gallatin wrote:
John Baldwin writes:
So its still stuck in msleep. How is it supposed to get back to
the panic'ed thread if a system thread wakes up and is not allowed to
go back to sleep???
Hm. Surprised we don't see this on other archs then (or maybe
we do...). Probably when we have panic'd (and after we leave the
debugger and go into boot() or some such) we should take any non-P_SYSTEM
processes off the run queues and then remove the panicstr checks from
msleep() and the condition variable wait functions.
Do you have something like the following psuedo code in mind?
Perhaps placed just prior to the call to boot() in panic()?
foreach p in (all procs in system) {
if (p == curproc)
continue
if (p-p_flag P_SYSTEM)
continue;
foreach td in (all threads in p)
if (td-td_state == TDS_RUNQ)
remrunqueue(td);
}
I assume a panic will IPI other processors and halt them in their
tracks so we don't need to worry too much about locking?
Hmm, it doesn't atm. Debugger() does, but panic doesn't.
Perhaps better is to dink around in choosethread() so that if panicstr
is set, we throw away any threads get that aren't P_SYSTEM or have the
TDF_INPANIC flag set. By throw away, I mean that we just ignore any such
threads and loop if we get one we want to throw away.
I think that I like your first idea better..
I like my second, it is easier, just add this to choosethread:
if (panicstr
((td-td_proc-p_flag P_SYSTEM) == 0
(td-td_flags TDF_INPANIC) == 0))
goto top;
(Do this just before the td_state change and return()).
You of couse need to set TDF_INPANIC when setting panicstr. This
might mean that we break the restartable panics case. In that
case you would just change this so that runq_choose() actually does
the work to ignore threads on the run queue instead which eliminates
the loop and ugly goto and preserves the runqueue state in the core
dump.
Drew
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Still no XFree86-4?
Wasn't this added in this commit? http://freshports.org/commit.php?[EMAIL PROTECTED] /John Arnold Cavazos Jr. wrote: This was posted on 11 July: http://people.freebsd.org/~anholt/files/x420diff-1 I did have to manually copy Wraphelp.c somewhere in the font-server port, but things built fine after that. -- abcjr On Tue, Jul 16, 2002 at 12:04:53PM +0200, John Angelmo wrote: Hello I erased my /usr/ports just to be sure that all the diffrent patches out, then cvsuped to get the latest version, to my disepointment XFree86-4 Still dosn't build under Current, I still got the same perl error in fonts, the perl port is installed. Does anyone have a working patch? /John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_GETATTR panic on Alpha
John Baldwin writes: I like my second, it is easier, just add this to choosethread: Don't all these compares in the critical path add up? if (panicstr ((td-td_proc-p_flag P_SYSTEM) == 0 (td-td_flags TDF_INPANIC) == 0)) goto top; (Do this just before the td_state change and return()). You of couse need to set TDF_INPANIC when setting panicstr. This might mean that we break the restartable panics case. In that case you would just change this so that runq_choose() actually does the work to ignore threads on the run queue instead which eliminates the loop and ugly goto and preserves the runqueue state in the core dump. I assume I also need to remove the panicstr check in at least msleep. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Still no XFree86-4?
At 12:04 PM +0200 7/16/02, John Angelmo wrote: Hello I erased my /usr/ports just to be sure that all the different patches out, then cvsuped to get the latest version, to my disappointment XFree86-4 Still dosn't build under Current, I still got the same perl error in fonts, the perl port is installed. Does anyone have a working patch? I rebuilt all of XFree86-4 on current from scratch this past weekend (probably Sunday night). I ran into some minor problems because I still had some left-over temporary patches in the 'files' directory of one of the ports, but after I blew those away and re-cvsup'ed then everything seemed to work okay. The only place I ran into a problem was that the Wraphelp.c file did not automatically show up in whatever directory it has to show up in, so I had to do that by hand, and finish building that port by hand. But I did end up with all of XFree86-4 built, and working. I did have the perl port already built (and 'use.perl port' done), and I do have: XFREE86_VERSION=4 in my /etc/make.conf file. I do not know if that is necessary. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /usr/src/dev/md error (?)
Following patch should silence it. Cheers, Jerry Hicks [EMAIL PROTECTED] Index: src/sys/dev/md/md.c === RCS file: /home/ncvs/src/sys/dev/md/md.c,v retrieving revision 1.66 diff -u -r1.66 md.c --- src/sys/dev/md/md.c 24 Jun 2002 12:07:02 - 1.66 +++ src/sys/dev/md/md.c 16 Jul 2002 21:32:44 - @@ -606,6 +606,7 @@ error = mdstart_swap(sc, bp); break; default: + error = -1; panic(Impossible md(type)); break; } On Tuesday, July 16, 2002, at 09:00 AM, Dikshie wrote: Hello, I got error on step make buildkernel KERNCONF=MANDIRI : cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -W missing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -n ostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/ac pica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/../include -D_KERNEL -includ e opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/md/md.c cc1: warnings being treated as errors /usr/src/sys/dev/md/md.c: In function `md_kthread': /usr/src/sys/dev/md/md.c:570: warning: `error' might be used uninitialized in th is function *** Error code 1 Stop in /usr/obj/usr/src/sys/MANDIRI. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. mandiri# did I miss something ? thanks ! -dikshie- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bug in awk implementation?
On Mon, Jul 15, 2002 at 04:00:29PM -0400, Garrett Wollman wrote: On Mon, 15 Jul 2002 21:47:09 +0200, Robert Drehmel [EMAIL PROTECTED] said: You are right. However, I still consider it a bug. :-) The standard says that the behavior is ``undefined''. That means that you computer is allowed to turn into a frog. Actually doing something useful is also permitted. And since it is clearly documented, awk(1) says, Records Normally, records are separated by newline characters. You can control how records are separated by assigning values to the built-in variable RS. If RS is any single character, that character separates records. Otherwise, RS is a regular expression. Text in the input that matches this regular expression will separate the record. However, in compatibility mode, only the first character of its string value is used for separating records. If RS is set to the null string, then records are separated by blank lines. When RS is set to the null string, the new- line character always acts as a field separator, in addi- tion to whatever value FS may have. It is not a bug. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld failure in libstdc++
On Tue, 16 Jul 2002, Steve Kargl wrote: ... Is this an alpha based system? I just completed a buildworld without setting anything special. i386 Sigh. It must have been a relict of using the ports gcc31 for buildworld. Another make (using the base 3.1 compiler - in /usr/src/libexec/rtld-elf after make installworld succeeded too. Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On Thu, Jul 11, 2002 at 12:33:27PM +0100, Josef Karthauser wrote: On Thu, Jul 11, 2002 at 04:01:08AM -0700, Don Lewis wrote: [stuff about could sleep with inp locked from /usr/src/sys/netinet/tcp_usrreq.c:647 could sleep with tcp locked from /usr/src/sys/netinet/tcp_usrreq.c:630 cut] I saw the recent changes to -current to try and fix this, but I'm still seeing it. Here's a typical stack trace: Debugger(c0374e00,c0389851,534,c0374e47,c037d8c8) at Debugger+0x54 witness_sleep(1,0,c0389851,534,c021bf24) at witness_sleep+0x135 uma_zalloc_arg(c1564000,0,4,c021bf24,c1564000) at uma_zalloc_arg+0x39 malloc(50,c03c1060,4,c40e5000,c40e5000) at malloc+0x55 uhci_allocm(c40e5000,c40edc40,a4,c024a000,c160e72e) at uhci_allocm+0x3d usbd_transfer(c40edc00,c434b600,c4126174,c42b1000,a4) at usbd_transfer+0xba aue_encap(c4126000,c160e700,0,49c,c41260dc) at aue_encap+0xa2 aue_start(c4126000,0,c0379f81,134,0) at aue_start+0xcc if_handoff(c41260c8,c160e700,c4126000,0,de0259e4) at if_handoff+0x107 ether_output_frame(c4126000,c160e700,6,c4336ba8,de0259e4) at ether_output_frame+0x241 ether_output(c4126000,c160e700,c4336ba8,c4ace200,0) at ether_output+0x4a2 ip_output(c160e700,0,c4336ba4,0,0) at ip_output+0xa75 tcp_output(c4336c68,c160ed00,c037de40,287,0) at tcp_output+0xc60 tcp_usr_send(c4ce1320,0,c160ed00,0,0) at tcp_usr_send+0x1be sosend(c4ce1320,0,de025c7c,c160ed00,0) at sosend+0x4c3 soo_write(c4d62078,de025c7c,c4d5cc80,0 Is anyone anywhere near this code at the moment? Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 msg41117/pgp0.pgp Description: PGP signature
Re: What to do with witness verbiage (is this new?)?
On 16-Jul-2002 Josef Karthauser wrote: On Thu, Jul 11, 2002 at 12:33:27PM +0100, Josef Karthauser wrote: On Thu, Jul 11, 2002 at 04:01:08AM -0700, Don Lewis wrote: [stuff about could sleep with inp locked from /usr/src/sys/netinet/tcp_usrreq.c:647 could sleep with tcp locked from /usr/src/sys/netinet/tcp_usrreq.c:630 cut] I saw the recent changes to -current to try and fix this, but I'm still seeing it. Here's a typical stack trace: Debugger(c0374e00,c0389851,534,c0374e47,c037d8c8) at Debugger+0x54 witness_sleep(1,0,c0389851,534,c021bf24) at witness_sleep+0x135 uma_zalloc_arg(c1564000,0,4,c021bf24,c1564000) at uma_zalloc_arg+0x39 malloc(50,c03c1060,4,c40e5000,c40e5000) at malloc+0x55 uhci_allocm(c40e5000,c40edc40,a4,c024a000,c160e72e) at uhci_allocm+0x3d usbd_transfer(c40edc00,c434b600,c4126174,c42b1000,a4) at usbd_transfer+0xba aue_encap(c4126000,c160e700,0,49c,c41260dc) at aue_encap+0xa2 aue_start(c4126000,0,c0379f81,134,0) at aue_start+0xcc if_handoff(c41260c8,c160e700,c4126000,0,de0259e4) at if_handoff+0x107 ether_output_frame(c4126000,c160e700,6,c4336ba8,de0259e4) at ether_output_frame+0x241 ether_output(c4126000,c160e700,c4336ba8,c4ace200,0) at ether_output+0x4a2 ip_output(c160e700,0,c4336ba4,0,0) at ip_output+0xa75 tcp_output(c4336c68,c160ed00,c037de40,287,0) at tcp_output+0xc60 tcp_usr_send(c4ce1320,0,c160ed00,0,0) at tcp_usr_send+0x1be sosend(c4ce1320,0,de025c7c,c160ed00,0) at sosend+0x4c3 soo_write(c4d62078,de025c7c,c4d5cc80,0 Is anyone anywhere near this code at the moment? This is because USB network drivers are possibly doing bad things. Either that or the network locking is making bogus assumptions about what device driver routines will and will not do. Probably the network stack should not hold locks across a driver's start method. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Still no XFree86-4?
On Tue, 2002-07-16 at 04:04, John Angelmo wrote: Hello I erased my /usr/ports just to be sure that all the diffrent patches out, then cvsuped to get the latest version, to my disepointment XFree86-4 Still dosn't build under Current, I still got the same perl error in fonts, the perl port is installed. Does anyone have a working patch? http://people.freebsd.org/~anholt/files/imake4diff Could you apply this patch and rebuild imake-4 and see if it picks up the perl dependency? If it doesn't pick it up, does adding: http://people.freebsd.org/~anholt/files/bsdportmk.diff make perl get picked up? If you've already installed perl, ignore this. As far as the Wraphelp.c issues, I'm working on cleaning that mess up right now (testing the patch on a full XFree86-4 build on clean -current). /John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/dri/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FFS namei panic
This was also reported a little earlier in thread
[EMAIL PROTECTED] but the reporter was not able to
give msgbuf details. This panic occurred on an i386 UP box while rsyncing
from another box. Let me know if you need other info.
Here is what I could find:
panic: from debugger
panic messages:
---
panic: Most recently used by devbuf
panic: from debugger
Uptime: 39m12s
Dumping 126 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc01ebc15 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc01ebdc9 in panic () at ../../../kern/kern_shutdown.c:491
#3 0xc01402cd in db_panic () at ../../../ddb/db_command.c:449
#4 0xc014026c in db_command (last_cmdp=0xc0336320, cmd_table=0x0,
aux_cmd_tablep=0xc032f738, aux_cmd_tablep_end=0xc032f73c)
at ../../../ddb/db_command.c:345
#5 0xc014033b in db_command_loop () at ../../../ddb/db_command.c:471
#6 0xc014276a in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc02c0374 in kdb_trap (type=3, code=0, regs=0xcce2d74c)
at ../../../i386/i386/db_interface.c:161
#8 0xc02cdaec in trap (frame=
{tf_fs = -1070268392, tf_es = 16, tf_ds = 16, tf_edi = -1061681920,
tf_esi = 256, tf_ebp = -857548912, tf_isp = -857548936, tf_ebx = 0, tf_edx
= 0, tf_ecx = 32, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip =
-1070856731, tf_cs = 8, tf_eflags = 642, tf_esp = -1070457944, tf_ss =
-857548892})
at ../../../i386/i386/trap.c:604
#9 0xc02c1748 in calltrap () at {standard input}:98
#10 0xc01ebdb4 in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:478
[--- begin relevant part ---]
#11 0xc02a1acc in mtrash_ctor (mem=0xc19bf800, size=0, arg=0x0)
at ../../../vm/uma_dbg.c:135
#12 0xc02a0a27 in uma_zalloc_arg (zone=0xc0b80500, udata=0x0, flags=0)
at ../../../vm/uma_core.c:1358
#13 0xc01e2dcc in malloc (size=7, type=0xc035c420, flags=0)
at ../../../kern/kern_malloc.c:171
#14 0xc0221c63 in allocbuf (bp=0xc405fb88, size=2048)
at ../../../kern/vfs_bio.c:2585
#15 0xc0221a34 in getblk (vp=0xc19a3b58, blkno=0, size=2048, slpflag=0,
slptimeo=0) at ../../../kern/vfs_bio.c:2477
#16 0xc021f577 in breadn (vp=0xc19a3b58, blkno=0, size=2048, rablkno=0x0,
rabsize=0x0, cnt=0, cred=0x0, bpp=0x0) at ../../../kern/vfs_bio.c:691
#17 0xc021f544 in bread (vp=0xc19a3b58, blkno=0, size=2048, cred=0x0,
bpp=0xcce2d954) at ../../../kern/vfs_bio.c:673
#18 0xc0281b0e in ffs_blkatoff (vp=0xc19a3b58, offset=0, res=0x0,
bpp=0xcce2d9c8) at ../../../ufs/ffs/ffs_subr.c:91
#19 0xc028856e in ufs_lookup (ap=0xcce2daf0)
at ../../../ufs/ufs/ufs_lookup.c:266
#20 0xc028e51f in ufs_vnoperate (ap=0x0) at
../../../ufs/ufs/ufs_vnops.c:2724
#21 0xc0223bc1 in vfs_cache_lookup (ap=0x0) at vnode_if.h:73
#22 0xc028e51f in ufs_vnoperate (ap=0x0) at
../../../ufs/ufs/ufs_vnops.c:2724
#23 0xc02274d4 in lookup (ndp=0xcce2dc30) at vnode_if.h:48
#24 0xc0226f74 in namei (ndp=0xcce2dc30) at ../../../kern/vfs_lookup.c:175
#25 0xc023033a in lstat (td=0xc18da780, uap=0xcce2dd14)
at ../../../kern/vfs_syscalls.c:1536
#26 0xc02ce27c in syscall (frame=
{tf_fs = -1078001617, tf_es = 47, tf_ds = -1078001617, tf_edi =
16877, tf_esi = 135189760, tf_ebp = -1077939860, tf_isp = -857547404, tf_ebx =
135189760, tf_edx = 134674144, tf_ecx = 134674186, tf_eax = 190, tf_trapno
= 12, tf_err = 2, tf_eip = 671886820, tf_cs = 31, tf_eflags = 647, tf_esp
= -1077939888, tf_ss = 47}) at ../../../i386/i386/trap.c:1049
#27 0xc02c177d in syscall_with_err_pushed () at {standard input}:128
---Can't read userspace from dump, or kernel process---
---
Dmesg output:
ahc0: Someone reset channel A
../../../vm/uma_core.c:1332: could sleep with kernel linker locked from
../../../kern/kern_linker.c:1797
Memory modified after free 0xc19bf800(2044)
panic: Most recently used by devbuf
panic: from debugger
Uptime: 39m12s
Dumping 126 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112
---
FreeBSD moe 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Jul 15 13:29:04 PDT
2002 root@moe:/usr/src/sys/i386/compile/MOE i386
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: bug in awk implementation?
On Tue, 16 Jul 2002, Crist J. Clark wrote: And since it is clearly documented, awk(1) says, Records Normally, records are separated by newline characters. You can control how records are separated by assigning values to the built-in variable RS. If RS is any single character, that character separates records. Otherwise, RS is a regular expression. Text in the input that matches this regular expression will separate the record. However, in compatibility mode, only the first character of its string value is used for separating records. If RS is set to the null string, then records are separated by blank lines. When RS is set to the null string, the new- line character always acts as a field separator, in addi- tion to whatever value FS may have. It is not a bug. No, you are quoting from the gawk(1) man page. The awk(1) man page makes no such statement. -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ast() assert failed ?
On Mon, 15 Jul 2002, Alexander Kabaev wrote: I am reliably get these messages while using gdb on user processes. This started long before KSEIII. I haven't managed to duplicate these problems for small user processes and suspect that they have something to do with threaded applications. Can you provide an example with an easy to debug process? Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_GETATTR panic on Alpha
On Tue, 16 Jul 2002, Andrew Gallatin wrote:
Andrew Kolchoogin writes:
Why panic from debugger on i386 gives core dump and reboots the system
and panic from debugger on Alpha does not?
Because, as BDE says, that crashdumps work at all is mosty accidental.
Er, I meant that working of syncs in panic() is mostly accidental.
Panic dumps should not be affected, since they should involve little
more than the driver's dump routine which should not depend on interrupts
or context switching working. Dump routines must use polling only, and
run with some sort of lock to prevent context switching. splhigh() is
used in RELENG_4. sched_lock should probably be used in -current, but
there seems to be only a (null) splhigh().
This could also be just a driver problem. I know the old wddump routine
worked right but am not sure about any of the current ones. Maybe dumps
are broken on the alpha only due to driver problems. Note that the
splhigh() didn't actually lock out interrupts in RELENG_4 for drivers
broken enough to call tsleep(). The [un]safepri hack in tsleep() may
permit broken dump routines that call tsleep() to work. This hack
has been lost in -current except for rotted comments which still say that
it is done.
On alpha, a random kernel thread is waking up, and is unable to go
back to sleep because of the panicstr hack msleep:
mtx_lock_spin(sched_lock);
if (cold || panicstr) {
/*
* After a panic, or during autoconfiguration,
* just give interrupts a chance, then just return;
This is the rotted comment. No chance is given here.
* don't run any other procs or panic below,
* in case this is the idle process and already asleep.
Looks like more bitrot. We've learned that the idle process can't call here.
*/
if (mtx != NULL priority PDROP)
mtx_unlock(mtx);
mtx_unlock_spin(sched_lock);
The safepri hack (splx(safepri); splx(origpri);) was here instead of these
mtx operations.
return (0);
}
We need to somehow let only interrupt threads and the panic'ed process
run after a panic. I have no idea how to do this in a clean,
low-impact way.
I don't want to do this since I think there is no clean way to do it.
But crash dumps must work without using interrupt threads, etc. I
think the right way to do the sync is to always do a crash dump and
have fsck_*fs recover buffers from it rather than let the panicing
kernel possibly create further damage. But changing fsck_*fs to do
this would be a lot of work.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: bug in awk implementation?
[Since you insisted on CC'ing me...] On Tue, 16 Jul 2002 16:57:42 -0700 (PDT), Gordon Tetlow [EMAIL PROTECTED] said: No, you are quoting from the gawk(1) man page. The awk(1) man page makes no such statement. The awk(1) manual page does not define the correct behavior of gawk(1). IEEE Std. 1003.1-2001 defines the correct behavior of both awk(1) and gawk(1), and as I have already demonstrated, it leaves the behavior in question clearly unspecified. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Still no XFree86-4?
On Tue, 2002-07-16 at 17:25, Eric Anholt wrote: As far as the Wraphelp.c issues, I'm working on cleaning that mess up right now (testing the patch on a full XFree86-4 build on clean -current). I've put the patch up at http://people.freebsd.org/~anholt/files/x420diff2-1 It does the following: - Make me maintainer of imake-4 port. It's very much a part of the X-4 build, and was supposed to be in the take-over-maintainership commit. - Make the X-4 miniports use imake-4's HasXdmAuth setting (the use-Wraphelp.c option) and copy Wraphelp.c (unconditionally). - Adds USE_PERL5 to imake-4 because perl's required for the install of it. This will also cover perl dependencies for the rest of the X-4. - Rewords some of the comments in XFree86-4-*/scripts/configure. It notably doesn't include md5summing of Wraphelp.c. If I can find what's the 'best' Wraphelp.c (and most legal? What's the status of wraphelp importing/exporting?), I'll switch it. Is there any circumstance when someone wouldn't have access to Wraphelp.c? If this works for other people, I'll work on getting it committed. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/dri/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Still no XFree86-4?
At 7:27 PM -0600 7/16/02, Eric Anholt wrote: It notably doesn't include md5summing of Wraphelp.c. If I can find what's the 'best' Wraphelp.c (and most legal? What's the status of wraphelp importing/exporting?), I'll switch it. Is there any circumstance when someone wouldn't have access to Wraphelp.c? I thought the whole point of Wraphelp.c was that the person who runs the machine (whatever machine X is being installed on) has to obtain that file, so they would have to explicitly verify that they -- personally -- have the right to use it. Mind you, I did that once about seven years ago, and I just keep copying that Wraphelp.c around to wherever I need it. I have no idea what the current requirement is... :-) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
DEVFS rule subsystem (was: cvs commit: src/sbin Makefile src/sbin/devfs Makefile devfs.8 devfs.c extern.h rule.c src/sys/conf files src/sys/fs/devfs devfs.h devfs_devs.c devfs_rule.c devfs_vfsops.c devfs_vnops.c )
I wrote: Log: Introduce the DEVFS rule subsystem. DEVFS rules permit the administrator to define certain properties of new devfs nodes before they become visible to the userland. Both static (e.g., /dev/speaker) and dynamic (e.g., /dev/bpf*, some removable devices) nodes are supported. Each DEVFS mount may have a different ruleset assigned to it, permitting different policies to be implemented for things like jails. This isn't entirely complete (e.g., globbing isn't implemented), but I think it works well enough for most purposes. I would appreciate it if people would try it and see whether it does what they want it to do (especially all of those people that have been asking for something like this since DEVFS became standard!). The devfs(8) manual page is a pretty good reference of the existing features and semantics, but it lacks polish needed to be able to serve as an introduction. As a starting point, try the following (you need to be root to do this stuff, of course): devfs rule -s 10 add path 'bpf*' group wheel mode 660 devfs ruleset 10 This should permit users in the wheel group to use the bpf devices (generally this probably isn't a good idea, but it's a good example, and easy to test). To test it, just run tcpdump as a non-root user in wheel; it should work unless you already have bpf devices with old permissions (rules are applied when the node is created (make_dev(9)), or if explicitly requested); in that case, you can do: devfs rule applyset to make your rules take effect on all current nodes. Some things to note about the above (this is all described in devfs(8)): if a mount-point isn't specified, /dev is assumed; if a ruleset isn't explicitly specified (command 3), the one associated with the mount-point you're using is assumed; globbing for the path argument isn't working yet (only a trailing asterisk is supported right now). At the moment, I'm not sure where people should be putting devfs commands to be run at boot time. I think hijacking /etc/rc.devfs for this purpose (a la rc.firewall) is probably the best idea, but if some of the rc hackers have better ideas, please let us (me) know. Questions and comments are most welcome. In particular, if you use this with removable devices (e.g., USB), I'd like to hear about it. I haven't had much of an opportunity to test this with different removable devices, and I'd like to know how well it works in such an environment. Thanks, Dima. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_GETATTR panic on Alpha
On 17-Jul-2002 Bruce Evans wrote:
This could also be just a driver problem. I know the old wddump routine
worked right but am not sure about any of the current ones. Maybe dumps
are broken on the alpha only due to driver problems. Note that the
splhigh() didn't actually lock out interrupts in RELENG_4 for drivers
broken enough to call tsleep(). The [un]safepri hack in tsleep() may
permit broken dump routines that call tsleep() to work. This hack
has been lost in -current except for rotted comments which still say that
it is done.
Agreed, if drivers depend on interrupts to work for dumps that is a Bug (tm).
On alpha, a random kernel thread is waking up, and is unable to go
back to sleep because of the panicstr hack msleep:
mtx_lock_spin(sched_lock);
if (cold || panicstr) {
/*
* After a panic, or during autoconfiguration,
* just give interrupts a chance, then just return;
This is the rotted comment. No chance is given here.
Well, when you unlock sched_lock you give ithreads a chance to run. (This
is only true in a fully preemptive kernel though.)
* don't run any other procs or panic below,
* in case this is the idle process and already asleep.
Looks like more bitrot. We've learned that the idle process can't call here.
Yes.
*/
if (mtx != NULL priority PDROP)
mtx_unlock(mtx);
mtx_unlock_spin(sched_lock);
The safepri hack (splx(safepri); splx(origpri);) was here instead of these
mtx operations.
Probably to truly emulate this we should always release the 'mtx' mutex and
then reacquire it if PDROP isn't specified.
return (0);
}
We need to somehow let only interrupt threads and the panic'ed process
run after a panic. I have no idea how to do this in a clean,
low-impact way.
I don't want to do this since I think there is no clean way to do it.
But crash dumps must work without using interrupt threads, etc. I
think the right way to do the sync is to always do a crash dump and
have fsck_*fs recover buffers from it rather than let the panicing
kernel possibly create further damage. But changing fsck_*fs to do
this would be a lot of work.
I agree that this would be the best solution for the long term if we can
have it.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: /usr/src/dev/md error (?)
On Tue, 16 Jul 2002, W Gerald Hicks wrote: Following patch should silence it. ... Index: src/sys/dev/md/md.c === RCS file: /home/ncvs/src/sys/dev/md/md.c,v retrieving revision 1.66 diff -u -r1.66 md.c --- src/sys/dev/md/md.c 24 Jun 2002 12:07:02 - 1.66 +++ src/sys/dev/md/md.c 16 Jul 2002 21:32:44 - @@ -606,6 +606,7 @@ error = mdstart_swap(sc, bp); break; default: + error = -1; panic(Impossible md(type)); break; } This change and the break after the panic() are bogus. panic() never returns, and the compiler knows this. Unfortunately, the RESTARTABLE_PANICS option subverts the semantics of panic(), so panic() sometimes returns. This breaks compilation of md.c and 28 other files in NOTES. The fix shouldn't be to disturb the usual flow of control in those 29 files. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /usr/src/dev/md error (?)
On 17-Jul-2002 Bruce Evans wrote: On Tue, 16 Jul 2002, W Gerald Hicks wrote: Following patch should silence it. ... Index: src/sys/dev/md/md.c === RCS file: /home/ncvs/src/sys/dev/md/md.c,v retrieving revision 1.66 diff -u -r1.66 md.c --- src/sys/dev/md/md.c 24 Jun 2002 12:07:02 - 1.66 +++ src/sys/dev/md/md.c 16 Jul 2002 21:32:44 - @@ -606,6 +606,7 @@ error = mdstart_swap(sc, bp); break; default: + error = -1; panic(Impossible md(type)); break; } This change and the break after the panic() are bogus. panic() never returns, and the compiler knows this. Unfortunately, the RESTARTABLE_PANICS option subverts the semantics of panic(), so panic() sometimes returns. This breaks compilation of md.c and 28 other files in NOTES. The fix shouldn't be to disturb the usual flow of control in those 29 files. We should probably turn RESTARTABLE_PANICS off in NOTES. Bruce -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /usr/src/dev/md error (?)
On Tuesday, July 16, 2002, at 10:13 PM, Bruce Evans wrote: On Tue, 16 Jul 2002, W Gerald Hicks wrote: Following patch should silence it. ... Index: src/sys/dev/md/md.c === RCS file: /home/ncvs/src/sys/dev/md/md.c,v retrieving revision 1.66 diff -u -r1.66 md.c --- src/sys/dev/md/md.c 24 Jun 2002 12:07:02 - 1.66 +++ src/sys/dev/md/md.c 16 Jul 2002 21:32:44 - @@ -606,6 +606,7 @@ error = mdstart_swap(sc, bp); break; default: + error = -1; panic(Impossible md(type)); break; } This change and the break after the panic() are bogus. panic() never returns, and the compiler knows this. Unfortunately, the RESTARTABLE_PANICS option subverts the semantics of panic(), so panic() sometimes returns. This breaks compilation of md.c and 28 other files in NOTES. The fix shouldn't be to disturb the usual flow of control in those 29 files. Bruce Ouch. My naive assumption was that panic() really did the deed. Agree, my suggestion is bogus. Thanks, Jerry Hicks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld failure in libstdc++
On Tue, 2002-07-16 at 17:11, Michael Reifenberger wrote: On Tue, 16 Jul 2002, Steve Kargl wrote: ... Is this an alpha based system? I just completed a buildworld without setting anything special. i386 Sigh. It must have been a relict of using the ports gcc31 for buildworld. Another make (using the base 3.1 compiler - in /usr/src/libexec/rtld-elf after make installworld succeeded too. Broken here, using a nothing from ports, base system only. -- Remember: the only difference between being the champ and the chump is u. signature.asc Description: This is a digitally signed message part
Re: Current (DP1) on Toshiba 5005
On Tue, 2002-07-16 at 15:04, Anthony Jenkins wrote: Rob Hughes wrote: All, I have a Toshiba 5005-S504 laptop (a wonderful legacy-free box that's I've cussed to no end) that I'm trying to get DP1 to boot on so I can cvsup and take a look (and hopefully contribute something). I was able to install, but after installation the system soft hangs after displaying a message about CPU power states (sorry, going off memory for now). I'm able to break to the debugger, so what information from dbg would be helpful at this point? Also, I'm pretty sure it's acpi that's causing the problem, so would someone point me to the syntax for disabling a module preload? Thanks, Rob I was tracking down a similar hang and had to disable acpi (turns out I'm an idiot and the apparent hang at boot was because I forgot console was redirected to the serial port of the machine next to it), but I had to jump through hoops to do it it seems. I believe all you have to do is 'unset acpi_load' at the boot loader prompt. I had tried 'set acpi_load=NO', and finally 'unset module_path' to keep the kernel from finding /boot/kernel/acpi.ko. Hope this helps, Anthony Jenkins Yes, the machine boots. Now I need to get acpi working on it so I can use something besides the kb and nic. -- Remember: the only difference between being the champ and the chump is u. signature.asc Description: This is a digitally signed message part
Re: panic: bdwrite: buffer is not busy
After rebuilding world/kernel/debug today I get some better info (I fear
my debug kernel was out of synch with my running kernel before, but
because of my inexperience with debugging I didn't figure that out right
away):
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...
panic: bdwrite: buffer is not busy
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc227e6f4
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc01db660
stack pointer = 0x10:0xd1f9ba7c
frame pointer = 0x10:0xd1f9ba94
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 = 55992 (smtpd)
trap number = 12
panic: page fault
syncing disks... panic: bdwrite: buffer is not busy
Uptime: 3h49m4s
Dumping 256 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc01bb513 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc01bb71b in panic () at ../../../kern/kern_shutdown.c:491
#3 0xc01f8bdd in bdwrite (bp=0x104) at ../../../kern/vfs_bio.c:947
#4 0xc026b28d in ffs_update (vp=0xc1de5b58, waitfor=0) at
../../../ufs/ffs/ffs_inode.c:125
#5 0xc027df77 in ffs_fsync (ap=0xd1f9b8f4) at ../../../ufs/ffs/ffs_vnops.c:272
#6 0xc027c308 in ffs_sync (mp=0xc1c1ce00, waitfor=2, cred=0xc0ef6f00, td=0xc032e080)
at vnode_if.h:463
#7 0xc0209e43 in sync (td=0xc032e080, uap=0x0) at ../../../kern/vfs_syscalls.c:127
#8 0xc01bb19c in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#9 0xc01bb71b in panic () at ../../../kern/kern_shutdown.c:491
#10 0xc02c596e in trap_fatal (frame=0x100, eva=0) at ../../../i386/i386/trap.c:845
#11 0xc02c565c in trap_pfault (frame=0xd1f9ba3c, usermode=0, eva=3257394932)
at ../../../i386/i386/trap.c:759
#12 0xc02c50b7 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -1042227796, tf_ebp =
-772162924, tf_isp = -772162968, tf_ebx = -1037572416, tf_edx = 180, tf_ecx =
-1040183148, tf_eax = -1037572368, tf_trapno = 12, tf_err = 2, tf_eip = -1071794592,
tf_cs = 8, tf_eflags = 66118, tf_esp = -1070377308, tf_ss = -772162904})
at ../../../i386/i386/trap.c:445
#13 0xc02b73a8 in calltrap () at {standard input}:98
#14 0xc01f1269 in sowakeup (so=0xc1e0ddac, sb=0xc227e6c0) at
../../../kern/uipc_socket2.c:300
#15 0xc01f0e51 in soisconnected (so=0xc2096640) at ../../../kern/uipc_socket2.c:132
#16 0xc01f6c1d in unp_connect2 (so=0x0, so2=0xc1e0dd48) at
../../../kern/uipc_usrreq.c:769
#17 0xc01f6b7b in unp_connect (so=0xc24a6578, nam=0xc25bb300, td=0x0) at
../../../kern/uipc_usrreq.c:737
#18 0xc01f5c7e in uipc_connect (so=0x0, nam=0x0, td=0xc204d9c0) at
../../../kern/uipc_usrreq.c:161
#19 0xc01eee21 in soconnect (so=0xc2096640, nam=0x0, td=0x0) at
../../../kern/uipc_socket.c:429
#20 0xc01f2bcb in connect (td=0x0, uap=0xc1e0dd48) at ../../../kern/uipc_syscalls.c:441
#21 0xc02c5c70 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 11, tf_esi = 0, tf_ebp =
-1077938120, tf_isp = -772162188, tf_ebx = 134704296, tf_edx = 2, tf_ecx = 0, tf_eax =
98, tf_trapno = 22, tf_err = 2, tf_eip = 671913163, tf_cs = 31, tf_eflags = 582,
tf_esp = -1077938276, tf_ss = 47}) at ../../../i386/i386/trap.c:1049
#22 0xc02b73dd in syscall_with_err_pushed () at {standard input}:128
---Can't read userspace from dump, or kernel process---
If there's anything else than this I can provide, pleas let me know.
--
Munish Chopra
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.. -- === sbin/disklabel === sbin/dmesg === sbin/dump /local0/scratch/des/src/sbin/dump/dumprmt.c: In function `rmtgetconn': /local0/scratch/des/src/sbin/dump/dumprmt.c:170: warning: passing arg 4 of `krcmd' discards qualifiers from pointer target type /local0/scratch/des/src/sbin/dump/traverse.c: In function `dumpino': /local0/scratch/des/src/sbin/dump/traverse.c:410: structure has no member named `c_birthtime' /local0/scratch/des/src/sbin/dump/traverse.c:411: structure has no member named `c_birthtimensec' /local0/scratch/des/src/sbin/dump/traverse.c:423: structure has no member named `c_birthtime' /local0/scratch/des/src/sbin/dump/traverse.c:424: structure has no member named `c_birthtimensec' *** Error code 1 Stop in /local0/scratch/des/src/sbin/dump. *** Error code 1 Stop in /local0/scratch/des/src/sbin. *** Error code 1 Stop in /local0/scratch/des/src. *** 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
[] current .
Title: ¿ì¸®Ä«µå ¼º¸í Áֹεî·Ï ¹øÈ£ Á÷Àå ÀüÈ ÈÞ´ëÆù ±ÍÇÏÀÇ ¸ÞÀÏÁÖ¼Ò´Â À¥¼ÇÎÀ» ÅëÇØ ¼öÁýÇÑ °ÍÀ̸ç, ±×¿Ü¿¡ ¾î¶°ÇÑ Á¤º¸µµ °®°í ÀÖÁö ¾ÊÀ½À» ¹àÈü´Ï´Ù. ÀÌ E-mailÀº ¹ß½ÅÀü¿ëÀ̸ç, ¿øÄ¡ ¾ÊÀ¸½Ç °æ¿ì ¾Æ·¡ â¿¡ ¸ÞÀÏÁÖ¼Ò¸¦ ÀÔ·ÂÇÏ¿© ÁÖ½Ã¸é µÎ ¹ø ´Ù½Ã ¸ÞÀÏ ÀÌ °¡Áö ¾Êµµ·Ï ÇÏ°Ú½À´Ï´Ù. ¼ö½Å°ÅºÎ / refusal of receipt
Re: Still no XFree86-4?
On Tue, 2002-07-16 at 19:38, Garance A Drosihn wrote: At 7:27 PM -0600 7/16/02, Eric Anholt wrote: It notably doesn't include md5summing of Wraphelp.c. If I can find what's the 'best' Wraphelp.c (and most legal? What's the status of wraphelp importing/exporting?), I'll switch it. Is there any circumstance when someone wouldn't have access to Wraphelp.c? I thought the whole point of Wraphelp.c was that the person who runs the machine (whatever machine X is being installed on) has to obtain that file, so they would have to explicitly verify that they -- personally -- have the right to use it. Mind you, I did that once about seven years ago, and I just keep copying that Wraphelp.c around to wherever I need it. I have no idea what the current requirement is... :-) It used to be that way. Then within the last year (iirc) our ports changed to auto-downloading Wraphelp.c and defaulting to HasXdmAuth YES. I don't know what exactly changed legally. I noted that at least NetBSD has a Wraphelp.c in their CVS repos of X-3 and X-4. My changes do make the file required by all of the miniports that could use it, though it only gets used if HasXdmAuth is set to YES by imake-4 (it's default). -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/dri/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Interesting panic very early in the boot
I've run into a very similar bug -- the kernel panics almost
right after it is started by the loader. With remote gdb
I've traced it to this point so far:
(kgdb) target remote /dev/cuaa0
Remote debugging using /dev/cuaa0
pmap_set_opt () at /usr/src/sys/i386/i386/pmap.c:449
449 if (*pte)
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
warning: shared library handler failed to enable breakpoint
(kgdb) where
#0 pmap_set_opt () at /usr/src/sys/i386/i386/pmap.c:449
#1 0xc0307c64 in pmap_bootstrap (firstaddr=3146924, loadaddr=0)
at /usr/src/sys/i386/i386/pmap.c:403
#2 0xc03056b2 in getmemsize (first=4947968)
at /usr/src/sys/i386/i386/machdep.c:1473
#3 0xc0305e2f in init386 (first=4947968)
at /usr/src/sys/i386/i386/machdep.c:1817
(kgdbl
444 /* Turn on PG_G for text, data, bss pages. */
445 va = (vm_offset_t)btext;
446 endva = KERNBASE + KERNend;
447 while (va endva) {
448 pte = vtopte(va);
449 if (*pte)
450 *pte |= pgeflag;
451 va += PAGE_SIZE;
452 }
453 invltlb(); /* Insurance */
(kgdb) p/x va
$2 = 0xc012be70
I can't get to pte for some reason. So hand computing vtopte(va) we get
(kgdb) p/x btext
$3 = 0xc012be70
(kgdb) p PTmap
$7 = 0xbfc0
(kgdb) p/x PTmap+0xc012b
$8 = 0xbff004ac
This address matches the page fault address. It is a
supervisor read, protection violation fault.
More details:
This is with today's (July 16) kernel (synced at about 5PM
PDT) on a Ppro system. This system can take two PPros but
I've plugged in just one Pentium Pro. It has 64MB ECC
memory. I'll continue investigating but I haven't been in
this part of code for ages hence the call for help!
If it matters, a kernel built from sources before the KSE
changes works fine on this machine.
Thanks for any hints.
-- bakul
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Interesting panic very early in the boot
Bakul Shah wrote: I've run into a very similar bug -- the kernel panics almost right after it is started by the loader. With remote gdb I've traced it to this point so far: I believe setting DISABLE_PSE in the config file and rebuilding will make this go away. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
