Re: upgrade from 4.5 to current fails
On Wed, Apr 24, 2002 at 01:29:49PM -0400, John Baldwin wrote: On 24-Apr-2002 Christian Flügel wrote: [snip] make buildworld: works ok. make buildkernel: works ok. copy GENERIC.hints to /boot/device.hints: works ok. make installkernel: stops with error: kldxref not found This is a bug in installkernel. Bug Peter Wemm [EMAIL PROTECTED] to fix it since he broke it. :) Or find somone else who groks the src/Makefile.inc1 stuff. It's already been pointed out that this is a non-fatal error in 'installworld.' However, I have (and think I posted somewhere?) some kludgey patches that build kldxref(8) as a cross-tool so that it works for 4.5 to 5.0 upgrades. But it's not really the right fix (since it is not a true cross-tool), so I haven't committed it. -- 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: upgrade from 4.5 to current fails
cjc However, I have (and think I posted somewhere?) some kludgey cjc patches that build kldxref(8) as a cross-tool so that it works cjc for 4.5 to 5.0 upgrades. But it's not really the right fix cjc (since it is not a true cross-tool), so I haven't committed it. Can we add kldxref(8) to bootstrap-tools, just like config(8)? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Uptime of 8909 days on 5-CURRENT
Lamont Granquist wrote: I just did a cvsup today to -current on a GENERIC+SMP kernel and my uptime is showing 8909 days. Motherboard is an ASUS A7M266D with the (possibly buggy) 1004 BIOS. I'm really surprised... I didn't realize ASUS made PDP-11 compatibles. 1977... I also didn't realize cvsup ran on 6th edithion UNIX... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Uptime of 8909 days on 5-CURRENT
On Sat, Apr 27, 2002 at 03:45:49PM -0700, Lamont Granquist wrote: I just did a cvsup today to -current on a GENERIC+SMP kernel and my uptime is showing 8909 days. Motherboard is an ASUS A7M266D with the (possibly buggy) 1004 BIOS. I'm seeing this too, but I expect it's probably caused by out of sync kernel and world. I haven't yet been able to test this hypothesis. Kris msg37791/pgp0.pgp Description: PGP signature
Re: Uptime of 8909 days on 5-CURRENT
--- Kris Kennaway [EMAIL PROTECTED] wrote: I'm seeing this too, but I expect it's probably caused by out of sync kernel and world. I haven't yet been able to test this hypothesis. Just wondering, could this be because of the recent changes made to the time code by phk? (uh oh, hiten.. you are in trouble!). Regards, -- Hiten __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Locking down a socket, milestone 1
On Wed, 24 Apr 2002 20:08:56 +0900, Seigo Tanimura [EMAIL PROTECTED] said: Seigo I am now working on locking down a socket. (I have heard that Jeffrey Seigo Hsu is also doing that, but I have never seen his patch. Has anyone Seigo seen that?) My first milestone patch is now available at: Seigo http://people.FreeBSD.org/~tanimura/patches/socket_milestone1.diff.gz I ripped off and committed the part of a sigio lock. The updated patch is found at: http://people.FreeBSD.org/~tanimura/patches/socket_milestone1a.diff.gz -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
%%% : iedowse 2002/04/28 03:24:38 PDT : : Modified files: :usr.sbin/pstat pstat.8 pstat.c : Log: : Oops, remove references to NLOCKED and NWANTED, now that they no : longer exist. %%% I beleive this unbreaks pstat. :-) -- Hiten __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Locking down a socket, milestone 1
On Sun, 28 Apr 2002, Seigo Tanimura wrote: On Wed, 24 Apr 2002 20:08:56 +0900, Seigo Tanimura [EMAIL PROTECTED] said: Seigo I am now working on locking down a socket. (I have heard that Jeffrey Seigo Hsu is also doing that, but I have never seen his patch. Has anyone Seigo seen that?) My first milestone patch is now available at: Seigo http://people.FreeBSD.org/~tanimura/patches/socket_milestone1.diff.gz I ripped off and committed the part of a sigio lock. The updated patch is found at: The committed part re-adds lots of namespace pollution to sys/filedesc.h and sys/socketvar.h. Please fix this. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
subscribe
Re: Uptime of 8909 days on 5-CURRENT
On Sun, 28 Apr 2002, Kris Kennaway wrote: On Sat, Apr 27, 2002 at 03:45:49PM -0700, Lamont Granquist wrote: I just did a cvsup today to -current on a GENERIC+SMP kernel and my uptime is showing 8909 days. Motherboard is an ASUS A7M266D with the (possibly buggy) 1004 BIOS. I'm seeing this too, but I expect it's probably caused by out of sync kernel and world. I haven't yet been able to test this hypothesis. Heh. I'm seeing this during the uptime announcement from the kernel after kernel shutdown, which means userland isn't involved: Uptime: 8909d8h59m52s Given that the uptime of the box was well less than a minute, that seems a little extreme. This was on -CURRENT from late last night. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Page fault in swp_pager_meta_build()
(Matt gets CC'd because he's just unlucky :-)
This system is (as always) a pxeboot'd nfsroot'd dual processor box. This
time, however, it's running straight GENERIC from the main tree instead of
the MAC branch. The box network boots, does a buildkernel -j 8, and then
reboots. It currently has no configured swap, suggesting that things
broke down when it tried to think about using some swap. Not sure how
many loops it took to get to this, but I've seen a couple of different
panics that I'll be posting about as they recur. I'm actually trying to
track an odd mbuf/nfs interaction...
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x20097479
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0337da8
stack pointer = 0x10:0xc8f22b2c
frame pointer = 0x10:0xc8f22b38
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 = 2 (pagedaemon)
kernel: type 12 trap, code=0
Stopped at swp_pager_meta_build+0xf0: cmpl%ebx,0x4(%eax)
db trace
swp_pager_meta_build(c97ff120,0,8000) at swp_pager_meta_build+0xf0
swap_pager_putpages(c97ff120,c8f22c34,4,0,c8f22bbc) at
swap_pager_putpages+0x57
default_pager_putpages(c97ff120,c8f22c34,4,0,c8f22bbc,c0428be0,1,c03ebb80,8e)
at default_pager_putpages+0x17
vm_pageout_flush(c8f22c34,4,0,c03d0c7a,246) at vm_pageout_flush+0xe5
vm_pageout_clean(c0a09204) at vm_pageout_clean+0x1ec
vm_pageout_scan(0,c034469c,c8f22d34,c023d838,0) at vm_pageout_scan+0x35a
vm_pageout(0,c8f22d48,c8e2c728,c034469c,0) at vm_pageout+0x231
fork_exit(c034469c,0,c8f22d48) at fork_exit+0x88
fork_trampoline() at fork_trampoline+0x37
(kgdb) l *swp_pager_meta_build+0xf0
0xc0337da8 is in swp_pager_meta_build (../../../vm/swap_pager.c:1654).
1649struct swblock *swap;
1650
1651index = ~SWAP_META_MASK;
1652pswap = swhash[(index ^ (int)(intptr_t)object) swhash_mask];
1653while ((swap = *pswap) != NULL) {
1654if (swap-swb_object == object
1655swap-swb_index == index
1656) {
1657break;
1658}
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Uptime of 8909 days on 5-CURRENT
On Sun, Apr 28, 2002 at 09:31:32AM -0400, Robert Watson wrote: On Sun, 28 Apr 2002, Kris Kennaway wrote: On Sat, Apr 27, 2002 at 03:45:49PM -0700, Lamont Granquist wrote: I just did a cvsup today to -current on a GENERIC+SMP kernel and my uptime is showing 8909 days. Motherboard is an ASUS A7M266D with the (possibly buggy) 1004 BIOS. I'm seeing this too, but I expect it's probably caused by out of sync kernel and world. I haven't yet been able to test this hypothesis. Heh. I'm seeing this during the uptime announcement from the kernel after kernel shutdown, which means userland isn't involved: Uptime: 8909d8h59m52s Given that the uptime of the box was well less than a minute, that seems a little extreme. This was on -CURRENT from late last night. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services @ uptime 3:36pm up 8909 days, 9:30, 2 users, load averages: 0,92 0,52 0,26 I love this ... I am _so_ proud :-) @ uname -a FreeBSD ole-guldberg.dk 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Apr 28 12:05:35 CEST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DYNAMIC i386 /ole -- see my pgp public key at http://home20.inet.tele.dk/ole_guldberg or at: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xEC74D4C5 I went to the museum where they had all the heads and arms from the statues that are in all the other museums. -- Steven Wright msg37800/pgp0.pgp Description: PGP signature
page fault in _mtx_lock_flags
As usual, GENERIC -CURRENT head from last night, from the main tree.
Dual-proc SMP box netbooted using PXE. System usually boots, does a
buildkernel -j 8 over NFS, then reboots and repeats. This time it didn't.
I actually have two boxes doing this, which does seem to double the rate
of panics I get.
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2
APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0
ad0: 19458MB ST320420A [39535/16/63] at ata0-master UDMA33
acd0: CDROM MATSHITA CR-176 at ata1-master PIO4
doSuMnPt:i nAgP rCoPoUt #f1r oLma unnfcsh:etsray irq 10
NFS ROOT: 192.168.50.1:/cboss/devel/nfsroot/crash1.cboss.tislabs.com
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x7974748b
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc02449b6
stack pointer = 0x10:0xc93dea14
frame pointer = 0x10:0xc93dea20
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 = 41 (sh)
kernel: type 12 trap, code=0
Stopped at _mtx_lock_flags+0x42: lock cmpxchgl %ecx,0x18(%ebx)
db trace
_mtx_lock_flags(79747473,0,c03cb862,e3) at _mtx_lock_flags+0x42
lockmgr(c93a8228,101,0,c8f27100) at lockmgr+0x42
vfs_busy(c93a8200,0,0,c8f27100) at vfs_busy+0x58
lookup(c93dec28,1a4,c8f03034,c93ded20,c8f27100) at lookup+0x3a2
namei(c93dec28,1a4,c8f03034,c93ded20,0) at namei+0x1c8
vn_open_cred(c93dec28,c93debf4,1a4,c3f80c80,c93dece8) at vn_open_cred+0x67
vn_open(c93dec28,c93debf4,1a4,c8f271dc,c8f27000) at vn_open+0x18
open(c8f27100,c93ded20,8125005,0,0) at open+0x158
syscall(2f,2f,2f,0,0) at syscall+0x223
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (5, FreeBSD ELF, open), eip = 0x808969b, esp = 0xbfbff8f0, ebp
= 0xbfbff91c ---
db
(kgdb) l *_mtx_lock_flags+0x42
0xc02449b6 is in _mtx_lock_flags (machine/atomic.h:139).
134 static __inline int
135 atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src)
136 {
137 int res = exp;
138
139 __asm __volatile (
140 __XSTRING(MPLOCKED)
141cmpxchgl %1,%2 ;
142setz%%al ;
143movzbl %%al,%0 ;
(gdb) l *lockmgr+0x42
0xc0242376 is in lockmgr (../../../kern/kern_lock.c:228).
223 pid = LK_KERNPROC;
224 else
225 pid = td-td_proc-p_pid;
226
227 mtx_lock(lkp-lk_interlock);
228 if (flags LK_INTERLOCK) {
229 mtx_assert(interlkp, MA_OWNED | MA_NOTRECURSED);
230 mtx_unlock(interlkp);
231 }
232
Attempts to get into serial gdb failed:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address = 0x6aa
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc93debf4
stack pointer = 0x10:0xc93debd4
frame pointer = 0x10:0xc93dec28
tokdke nselg trnatp 1=2 waith 0ixn0terlruptts 0dxisfablfed
cpan ic: bblo ck a=b leP Lsle,epp rlosc k1 ,(sdleefep2 m1ut egx)a
pro
ssroclescsor e../a.g./ .=. /ii38e6/iu386 /etnraapl.cd:,7 11e
pcmeu, I O=P L0 ;= l0
ccu.rrde =t 0p00os0
Deb1u g(gsehr)(
$T0b08:f4eb3dc9;05:28ec3dc9;04:d4eb3dc9;#01~
I'm guessing that I'm dealing with an smp/locking issue there, but
unfortunately I didn't get much further:
(kgdb) target remote /dev/cuaa0
Remote debugging using /dev/cuaa0
0xc93debf4 in ?? ()
(kgdb) bt
#0 0xc93debf4 in ?? ()
#1 0x0 in ?? ()
Normally getting into serial gdb works OK, perhaps there's an interaction
from the mutex code.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
vm_map_lookup_entry: Fatal trap 12: page fault while in kernel mode
It could be this was fixed by Alan's commit last night to fix locking in
VM. In any case, here's the panic anyway. This is from box2, again,
-current from last night, nfs root via pxeboot, GENERIC, spinning {boot,
buildkernel}. I'll update the two boxes when I get back from the hospital
later today.
NFS ROOT: 192.168.50.1:/cboss/devel/nfsroot/crash2.cboss.tislabs.com
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address = 0x676f6c3b
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc033b34b
stack pointer = 0x10:0xc93b6ba4
frame pointer = 0x10:0xc93b6bc0
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 = 8 (init)
kernel: type 12 trap, code=0
Stopped at vm_map_lookup_entry+0x57: cmpl%ebx,0xc(%eax)
db trace
vm_map_lookup_entry(c93b1190,80d6000,c93b6bec) at vm_map_lookup_entry+0x57
vm_map_lookup(c93b6c70,80d6000,2,c93b6c74,c93b6c68) at vm_map_lookup+0x5d
vm_fault1(c93b1190,80d6000,2,8,c93ae1dc) at vm_fault1+0x7e
vm_fault(c93b1190,80d6000,2,8,c) at vm_fault+0x17
trap_pfault(c93b6d48,1,80d6538,8048fe0,0) at trap_pfault+0xdd
trap(2f,2f,2f,0,0) at trap+0x1d3
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0x8056e36, esp = 0xbfbffc8c, ebp = 0xbfbffc94 ---
db
(kgdb) l *vm_map_lookup_entry+0x57
0xc033b34b is in vm_map_lookup_entry (../../../vm/vm_map.c:646).
641
642 /*
643 * Search linearly
644 */
645 while (cur != last) {
646 if (cur-end address) {
647 if (address = cur-start) {
648 /*
649 * Save this lookup for future
hints, and
650 * return
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
strange file
Hello, Yesterday installed current from a snapshot and instantly updated it via CVS. Today i noticed a strange file in /usr with the name @LongLink. # cat /usr/@LongLink ports/java/jdk13/files/patch-..::src::solaris::native::com::sun::media::sound::engine::HAE_API_BSDOS_Capture.c I containes a piece of logging from CVS. C ports/java/jdk13/files/patch-..::src::solaris::native::com::sun::media::sound::engine::HAE_API_BSDOS_Capture.c,v . . 2#871#110#10189856643#8663#444 1.1 2002.04.16.19.34.24 2#871#110#10189856643#5943#644 Anyone an idea how this is possible??? Greetings, Richard. An OS is like swiss cheese, the bigger it is, the more holes you get! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Uptime of 8909 days on 5-CURRENT
On Sun, 28 Apr 2002, Robert Watson wrote: Heh. I'm seeing this during the uptime announcement from the kernel after kernel shutdown, which means userland isn't involved: Uptime: 8909d8h59m52s Given that the uptime of the box was well less than a minute, that seems a little extreme. This was on -CURRENT from late last night. This seems to be a bug in a little joke kern_tc.c. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Page fault in swp_pager_meta_build()
--- Matthew Dillon [EMAIL PROTECTED] wrote: No idea, but the last time someone had a weird swap issue it turned out that they had swapon'd the same swap partition twice. The system's checks are not sufficient if you swapon the same device from different mounts. So check that first. Talking about doing something twice, it reminds me, that there is the same type of issue with the md devices, which when they are destroyed twice or thrice, they panic the kernel. I talked about this issue before but it didn't get discussed further, and the other thing is, I am not able to produce a kernel crash dump. Regards, -- Hiten __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
truss
Hello, On a fresh current i get this # truss /bin/echo hello truss: cannot open /proc/13245/mem: No such file or directory truss: cannot open /proc/curproc/mem: No such file or directory Greetings, Richard. An OS is like swiss cheese, the bigger it is, the more holes you get! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, 28 Apr 2002, Richard Arends wrote: RAHello, RA RAOn a fresh current i get this RA RA# truss /bin/echo hello RAtruss: cannot open /proc/13245/mem: No such file or directory RAtruss: cannot open /proc/curproc/mem: No such file or directory You need to mount procfs. harti RA RAGreetings, RA RARichard. RA RA RAAn OS is like swiss cheese, the bigger it is, the more holes you get! RA RA RATo Unsubscribe: send mail to [EMAIL PROTECTED] RAwith unsubscribe freebsd-current in the body of the message RA -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Page fault in swp_pager_meta_build()
On Sun, 28 Apr 2002, Hiten Pandya wrote: Talking about doing something twice, it reminds me, that there is the same type of issue with the md devices, which when they are destroyed twice or thrice, they panic the kernel. Re.v.108 of kern_conf.c fixes similar bugs. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On 28-Apr-2002 (17:56:47/GMT) Harti Brandt wrote: RAOn a fresh current i get this RA# truss /bin/echo hello RAtruss: cannot open /proc/13245/mem: No such file or directory RAtruss: cannot open /proc/curproc/mem: No such file or directory You need to mount procfs. Mee too message. I tryed same command, 1st time I got same error. I checked with df if /proc was mounted and than trussed again and it show me calls not failing any more. Some timeout of procfs ? # uname -v FreeBSD 5.0-CURRENT #32: Tue Apr 23 08:21:16 CEST 2002 [...] Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Uptime of 8909 days on 5-CURRENT
On Sat, 27 Apr 2002, Lamont Granquist wrote: I just did a cvsup today to -current on a GENERIC+SMP kernel and my uptime is showing 8909 days. cvsup again, this problem should be fixed now. -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfilter not broken for me
On Sat, 27 Apr 2002, Ruslan Ermilov wrote: That was probably a local problem on one of the Brian's fast machines where I initially attempted to finally test my patch (unsynched cvsup update?). Sorry for the false alarm, I can't check it right now anyway. You probably caught things in the middle of the update. -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Bochs panic on current
I asked for same problem some time ago to this list and to ports without answer, anyone out there running bochs on current? I have installed bochs from ports but I was unable to start any sample image from support site, all fails with same error: Event type: PANIC Device: [APIC0] Message: [APIC0] failed assertion irr[vector] == 1 at apic.cc:573 # uname -v FreeBSD 5.0-CURRENT #32: Tue Apr 23 08:21:16 CEST 2002 [...] Maybe something related to my dual proc mobo (asus P2B-DS) ? Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Uptime of 8909 days on 5-CURRENT
On Sun, Apr 28, 2002 at 03:05:47AM -0700, Hiten Pandya wrote: --- Kris Kennaway [EMAIL PROTECTED] wrote: I'm seeing this too, but I expect it's probably caused by out of sync kernel and world. I haven't yet been able to test this hypothesis. Just wondering, could this be because of the recent changes made to the time code by phk? (uh oh, hiten.. you are in trouble!). Yes, it is. Kris msg37814/pgp0.pgp Description: PGP signature
Re: truss
On Sun, 28 Apr 2002, Harti Brandt wrote: You need to mount procfs. Oops youre right... Why isn't it listed in /etc/fstab??? Greetings, Richard. An OS is like swiss cheese, the bigger it is, the more holes you get! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, Apr 28, 2002 at 07:46:27PM +0200, Richard Arends wrote: Hello, On a fresh current i get this # truss /bin/echo hello truss: cannot open /proc/13245/mem: No such file or directory truss: cannot open /proc/curproc/mem: No such file or directory procfs is not mounted by default. Kris msg37816/pgp0.pgp Description: PGP signature
Re: truss
On Sun, Apr 28, 2002 at 08:11:58PM +0200, Riccardo Torrini wrote: On 28-Apr-2002 (17:56:47/GMT) Harti Brandt wrote: RAOn a fresh current i get this RA# truss /bin/echo hello RAtruss: cannot open /proc/13245/mem: No such file or directory RAtruss: cannot open /proc/curproc/mem: No such file or directory You need to mount procfs. Mee too message. I tryed same command, 1st time I got same error. I checked with df if /proc was mounted and than trussed again and it show me calls not failing any more. Some timeout of procfs ? Probably some auto-loading of procfs.ko Kris msg37817/pgp0.pgp Description: PGP signature
Re: truss
On Sun, 28 Apr 2002, Kris Kennaway wrote: procfs is not mounted by default. New to current (one day old baby :-), so didn't know that. sorry() Why isn't it mounted by default?? Greetings, Richard. An OS is like swiss cheese, the bigger it is, the more holes you get! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, 28 Apr 2002, Richard Arends wrote: On Sun, 28 Apr 2002, Kris Kennaway wrote: procfs is not mounted by default. New to current (one day old baby :-), so didn't know that. sorry() Why isn't it mounted by default?? I believe DES has a largely rewritten version of truss that doesn't use procfs. When I disabled procfs in sysinstall, I did it thinking that had already been committed, but it turned out not to have been. Hopefully he'll get it finished and committed sometime soon. The rationale for disabling procfs is that its functionality is largely redundant to existing sysctls and debugging mechanisms, and that it has been, and will likely continue to be, an important source of system security holes. The very nature of procfs (mapping one kernel abstraction into another with different security properties) is part of what makes that likely. In fact, if it's not already on the how to harden your system list, unmounting procfs should be at the top of it :-). I think truss is one of the last stragglers that relies on it -- the other is 'ps -e', which gropes through the memory of each process to dig out the environmental variables. This requires that ps both have substantial privilege, and that procfs be present. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha 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 /tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Apr 28 11:39:49 PDT 2002 -- === drm/gamma ... *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, Apr 28, 2002 at 08:49:55PM +0200, Richard Arends wrote: On Sun, 28 Apr 2002, Kris Kennaway wrote: procfs is not mounted by default. New to current (one day old baby :-), so didn't know that. sorry() Why isn't it mounted by default?? Numerous and horrendous security vulnerabilities in the past. Kris msg37821/pgp0.pgp Description: PGP signature
Re: Page fault in swp_pager_meta_build()
On Sun, 28 Apr 2002, Matthew Dillon wrote: :(Matt gets CC'd because he's just unlucky :-) : :This system is (as always) a pxeboot'd nfsroot'd dual processor box. This :time, however, it's running straight GENERIC from the main tree instead of :the MAC branch. The box network boots, does a buildkernel -j 8, and then :reboots. It currently has no configured swap, suggesting that things :broke down when it tried to think about using some swap. Not sure how :many loops it took to get to this, but I've seen a couple of different :panics that I'll be posting about as they recur. I'm actually trying to :track an odd mbuf/nfs interaction... No idea, but the last time someone had a weird swap issue it turned out that they had swapon'd the same swap partition twice. The system's checks are not sufficient if you swapon the same device from different mounts. So check that first. It currently has no swap started at all, which is one reason I was rather puzzled to see this panic: 192.168.50.1:/cboss/devel/nfsroot/crash2.cboss.tislabs.com / nfs ro 0 0 proc/proc procfs rw 0 0 /dev/ad0s1e /mntufs rw 0 0 The swap code preallocates its bitmap space, the hash table array is malloc'd once at boot time, and the swblock is zalloc()'d. From the looks of it the hash chain either got corrupted somehow or part of the kernel's KVM space containing either the hash table or the swblock's got corrupted. Unless someone worked on the swap code recently I would focus on either the memory subsystem or on unrelated kernel subsystems blowing up KVK. Should it even be hitting this code if swap hasn't been enabled? I've run into a couple of other weird bugs and wouldn't be surprised if there is a memory allocation problem. The problem I was actually trying to reproduce with these two crash boxes was one where the socket used by NFS get zero'd, resulting in a null pointer dereference. The other one is in odd panic in the mutex code during an early VFS operation. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, 28 Apr 2002, Robert Watson wrote: The rationale for disabling procfs is that its functionality is largely redundant to existing sysctls and debugging mechanisms, and that it has been, and will likely continue to be, an important source of system security holes. Okay disable it :-) I think truss is one of the last stragglers that relies on it -- the other is 'ps -e', which gropes through the memory of each process to dig out the environmental variables. This requires that ps both have substantial privilege, and that procfs be present. Can't we take the privileges away, so that an user only can see his own procs and only root can see all?? Greetings, Richard. An OS is like swiss cheese, the bigger it is, the more holes you get! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, 28 Apr 2002, Richard Arends wrote: I think truss is one of the last stragglers that relies on it -- the other is 'ps -e', which gropes through the memory of each process to dig out the environmental variables. This requires that ps both have substantial privilege, and that procfs be present. Can't we take the privileges away, so that an user only can see his own procs and only root can see all?? It's a little more complicated than that. The problem was that procfs provided extremely broad access to the system, but without much granularity. Mostly this meant that if you had root privilege, you could do whatever you wanted, and otherwise, you got a reasonable view of the system (modulo the countless security holes in procfs). So the problem was that ps ran with a lot of privilege -- generally root or 'gid kmem' which amounts to much the same thing. This meant that gating of process information happened in the ps command, or at least, with the help of the ps command deciding not to get around the information gating. In FreeBSD 4.0, this responsibility happens both in userland and the kernel -- the kernel makes some effort to limit access via procfs, but largely allows privileged processes access to most things. So the ps command implemented the limit on what processes you could extract environmental information from. In FreeBSD 5.0, all this information is exported from the kernel using the sysctl() interface, which provides much more information gating, and flexibe policy controls. This exists in part in 4.x, but not completely. In 5.0, ps requires no special privilege, and access control is done entirely in the kernel. However, giving up the ability to grope through the memory of other processes by giving up procfs does limit that one capability -- listing environmental variables. For ps to display this information, either it has to extract it using a kernel facility (such as procfs), or the kernel has to extract it and provide it to ps. So far, we've had to rule out the first due to the security issues, but the second hasn't been implemented. It's not clear there's enough interest in it that someone has felt motivated to do so. Patches would be accepted here, but I think there's some concensus it's not really a necessary feature, and it also raises a lot of security issues of its own (you'd be surprised what ends up in environmental variables, and how hard it is to keep policy in sync between userland and kernel). BTW, 5.0 will also allow (once we commit the MAC framework from the TrustedBSD Project) kernel modules to tweak process visibility protections in the kernel at runtime. For example, you can kldload a mac_seeotheruids.ko policy module, which can limit what processes can view of other processes based on a number of factors, including uids, and information it tags onto the processes. It can also limit access to socket information listed in netstat, etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
unsuscribe freebsd-current
Re: truss
On Sun, 28 Apr 2002, Robert Watson wrote: BTW, 5.0 will also allow (once we commit the MAC framework from the TrustedBSD Project) kernel modules to tweak process visibility protections in the kernel at runtime. For example, you can kldload a mac_seeotheruids.ko policy module, which can limit what processes can view of other processes based on a number of factors, including uids, and information it tags onto the processes. It can also limit access to socket information listed in netstat, etc. When will the TrustedBSD modules commited to current?? Greetings, Richard. An OS is like swiss cheese, the bigger it is, the more holes you get! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, 28 Apr 2002, Richard Arends wrote: On Sun, 28 Apr 2002, Robert Watson wrote: BTW, 5.0 will also allow (once we commit the MAC framework from the TrustedBSD Project) kernel modules to tweak process visibility protections in the kernel at runtime. For example, you can kldload a mac_seeotheruids.ko policy module, which can limit what processes can view of other processes based on a number of factors, including uids, and information it tags onto the processes. It can also limit access to socket information listed in netstat, etc. When will the TrustedBSD modules commited to current?? The current (vague) plan is to commit them around mid-June, but that may slip a bit depending on development rate. Early access to the feature set is possible via Perforce, or from cvsup10.FreeBSD.org. I'm hoping to have the basic kernel feature set ready for integration by early June, so we might integrate back the changes back into the main tree in phases. I have to warn you that the stuff in the branch is moving pretty quickly, and there are some known poor interactions, especially with non-IP networking types, that we're still tracking down. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, Apr 28, 2002 at 03:59:44PM -0400, Robert Watson wrote:
[snip]
In FreeBSD 5.0, all this information is exported from the kernel using the
sysctl() interface, which provides much more information gating, and
flexibe policy controls. This exists in part in 4.x, but not completely.
In 5.0, ps requires no special privilege, and access control is done
entirely in the kernel.
I think I'm missing something here.
$ uname -r
4.5-RELEASE
$ ls -l /bin/ps
-r-xr-xr-x 1 root wheel 213796 Jan 30 14:30 /bin/ps
ps(1) has no special privileges in 4.x, but I may not understand what
you mean by special privileges? (To me it means s{u,g}id.)
--
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: Uptime of 8909 days on 5-CURRENT
On Sun, 28 Apr 2002, Kris Kennaway wrote: On Sat, Apr 27, 2002 at 03:45:49PM -0700, Lamont Granquist wrote: I just did a cvsup today to -current on a GENERIC+SMP kernel and my uptime is showing 8909 days. Motherboard is an ASUS A7M266D with the (possibly buggy) 1004 BIOS. I'm seeing this too, but I expect it's probably caused by out of sync kernel and world. I haven't yet been able to test this hypothesis. I don't think so, I did: 1. buildworld 2. buildkernel 3. installkernel 4. single user 5. installworld 6. mergemaster and then for good measure tried building the world again, and i've still got the problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, 28 Apr 2002, Crist J. Clark wrote:
On Sun, Apr 28, 2002 at 03:59:44PM -0400, Robert Watson wrote:
[snip]
In FreeBSD 5.0, all this information is exported from the kernel using the
sysctl() interface, which provides much more information gating, and
flexibe policy controls. This exists in part in 4.x, but not completely.
In 5.0, ps requires no special privilege, and access control is done
entirely in the kernel.
I think I'm missing something here.
$ uname -r
4.5-RELEASE
$ ls -l /bin/ps
-r-xr-xr-x 1 root wheel 213796 Jan 30 14:30 /bin/ps
ps(1) has no special privileges in 4.x, but I may not understand what
you mean by special privileges? (To me it means s{u,g}id.)
Hmm. I'd forgotten that the setgid kmem was removed in 4.x; I was
probably thinking of top, which still is setgid in -STABLE. You'll find
however, that -e won't work without setgid kmem being turned on. There
are a number of other tools in -CURRENT that aren't setgid kmem where they
are in -STABLE (top, iostat, etc).
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Uptime of 8909 days on 5-CURRENT
--- Lamont Granquist [EMAIL PROTECTED] wrote: I'm seeing this too, but I expect it's probably caused by out of sync kernel and world. I haven't yet been able to test this hypothesis. I don't think so, I did: [...] Just cvsup again and rebuild your kernel, and that will fix the problem. -- Hiten __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Uptime of 8909 days on 5-CURRENT
On Sun, 28 Apr 2002, Hiten Pandya wrote: --- Lamont Granquist [EMAIL PROTECTED] wrote: I'm seeing this too, but I expect it's probably caused by out of sync kernel and world. I haven't yet been able to test this hypothesis. I don't think so, I did: [...] Just cvsup again and rebuild your kernel, and that will fix the problem. Just finished, it did. Vmstat is fixed too. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
can't make release - don't know how to make maninstall inusr.bin/strip
I've been trying to do a 'make release' for a week or two and I keep getting the following error. I've cvsuped, make buildworld, make installworld, reboot, a number times hoping for it to work, but no go. Am I doing something wrong, or is there something that is yet to be fixed? su-2.05# make release CHROOTDIR=/disk2/r BUILDNAME=jmb-citrus-snap-20020428 CVSROOT=/home/ncvs . . . snip . . . === usr.bin/size install -c -s -o root -g wheel -m 555 size /disk2/r/usr/libexec/aout === usr.bin/smbutil install -c -s -o root -g wheel -m 555 smbutil /disk2/r/usr/bin === usr.bin/strings install -c -s -o root -g wheel -m 555 strings /disk2/r/usr/libexec/aout === usr.bin/strip make: don't know how to make maninstall. Stop *** Error code 2 Stop in /disk2/usr.src/usr.bin. *** Error code 1 Stop in /disk2/usr.src. *** Error code 1 Stop in /disk2/usr.src. *** Error code 1 Stop in /disk2/usr.src. *** Error code 1 Stop in /disk2/usr.src. *** Error code 1 Stop in /disk2/usr.src/release. su-2.05#cd /usr/src/sys/i386/conf su-2.05# cat citgate-smp machine i386 ident citgate-smp maxusers32 options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O cpu I686_CPU# aka Pentium Pro(tm) options CPU_FASTER_5X86_FPU options NO_F00F_HACK options COMPAT_43 options SYSVSHM options SYSVSEM options SYSVMSG options DIAGNOSTIC options PERFMON options INET#Internet communications protocols options INET6 #IPv6 communications protocols options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) device ether #Generic Ethernet device loop1 #Network loopback device device bpf #Berkeley packet filter device tun #Tunnel driver (ppp(8), nos-tun(8)) device gif 4 #IPv6 and IPv4 tunneling device faith 1 #for IPv6 and IPv4 translation device stf #6to4 IPv6 over IPv4 encapsulation options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #print information about # dropped packets options IPFIREWALL_FORWARD #enable transparent proxy support options IPFIREWALL_VERBOSE_LIMIT=100#limit verbosity options IPV6FIREWALL#firewall for IPv6 options IPV6FIREWALL_VERBOSE options IPV6FIREWALL_VERBOSE_LIMIT=100 options IPDIVERT#divert sockets options IPSTEALTH #support for stealth forwarding options FFS #Fast filesystem options NFSSERVER #Network File System options NFSCLIENT #Network File System options CD9660 #ISO 9660 filesystem options MSDOSFS #MS DOS File System (FAT, FAT32) options PROCFS #Process filesystem options PSEUDOFS#Pseudo-filesystem framework options SMBFS #SMB/CIFS filesystem options SOFTUPDATES device random options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L device scbus #base SCSI code device da #SCSI direct access devices (aka disks) device pass#CAM passthrough driver options SCSI_DELAY=3000 # Be pessimistic about Joe SCSI device device pty #Pseudo ttys device speaker #Play IBM BASIC-style noises out your speaker device gzip#Exec gzipped a.out's device md #Memory/malloc disk device snp #Snoop device - to look at pty/vty/etc.. device isa options AUTO_EOI_1 options AUTO_EOI_2 device pci device atkbdc 1 device atkbd device psm device vga device splash device sc 1 options SC_HISTORY_SIZE=500 # number of history buffer lines device npx options ACPI_DEBUG device ahc options AHC_ALLOW_MEMIO device ata device atadisk # ATA disk drives device atapicd device fdc device miibus # MII bus support device fxp # Intel EtherExpress PRO/100B (82557, 82558) # USB support # UHCI controller device uhci options UHCI_DEBUG # General USB code (mandatory for USB) device usb options USB_DEBUG # # Generic USB device driver device ugen options
Using laptop with lid closed
Is there any way to prevent the system from reacting to the lid being closed? At this time when I close the lid I get the following messages: ed1: detached pccard: card disabled, slot 0 Then after re-opening, I have to press the power button for the system to wake up. I'm using Thinkpad A22m. Krzysztof To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, Apr 28, 2002 at 05:11:14PM -0400, Robert Watson wrote:
On Sun, 28 Apr 2002, Crist J. Clark wrote:
On Sun, Apr 28, 2002 at 03:59:44PM -0400, Robert Watson wrote:
[snip]
In FreeBSD 5.0, all this information is exported from the kernel using the
sysctl() interface, which provides much more information gating, and
flexibe policy controls. This exists in part in 4.x, but not completely.
In 5.0, ps requires no special privilege, and access control is done
entirely in the kernel.
I think I'm missing something here.
$ uname -r
4.5-RELEASE
$ ls -l /bin/ps
-r-xr-xr-x 1 root wheel 213796 Jan 30 14:30 /bin/ps
ps(1) has no special privileges in 4.x, but I may not understand what
you mean by special privileges? (To me it means s{u,g}id.)
Hmm. I'd forgotten that the setgid kmem was removed in 4.x; I was
probably thinking of top, which still is setgid in -STABLE. You'll find
however, that -e won't work without setgid kmem being turned on.
'-e' for ps(1) seems to work fine on processes you own. You cannot see
the environments of other users' processes (of course root can see
everyone's). But you do need /proc for '-e' to work.
There
are a number of other tools in -CURRENT that aren't setgid kmem where they
are in -STABLE (top, iostat, etc).
You know, I'm not sure why top(1) needs it if ps(1) doesn't.
--
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: page fault in _mtx_lock_flags
I also get an almost identical fault on crash1 involving mdconfig as
opposed to sh:
ray irq 10
NFS ROOT: 192.168.50.1:/cboss/devel/nfsroot/crash1.cboss.tislabs.com
8.50.10 BroadcasP-Address 192.16
t 192.168.50.255
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address = 0x6b73697c
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc02449b6
stack pointer = 0x10:0xc93d8a14
frame pointer = 0x10:0xc93d8a20
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 = 44 (mdconfig)
kernel: type 12 trap, code=0
Stopped at _mtx_lock_flags+0x42: lock cmpxchgl %ecx,0x18(%ebx)
db trace
_mtx_lock_flags(6b736964,0,c03cb862,e3) at _mtx_lock_flags+0x42
lockmgr(c93a8228,101,0,c8f27100) at lockmgr+0x42
vfs_busy(c93a8200,0,0,c8f27100) at vfs_busy+0x58
lookup(c93d8c28,0,c93b9c34,c93d8d20,c8f27100) at lookup+0x3a2
namei(c93d8c28,0,c93b9c34,c93d8d20,0) at namei+0x1c8
vn_open_cred(c93d8c28,c93d8bf4,0,c3f80c80,c93d8ce8) at vn_open_cred+0x23b
vn_open(c93d8c28,c93d8bf4,0,c8f271dc,c8f27000) at vn_open+0x18
open(c8f27100,c93d8d20,0,0,0) at open+0x158
syscall(2f,2f,2f,0,0) at syscall+0x223
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (5, FreeBSD ELF, open), eip = 0x804950b, esp = 0xbfbffd14, ebp
= 0xbfbffd50 ---
db Context switches not allowed in the debugger.
db
Still not clear what the origin of this is -- possibly memory corruption
of the mutex..?
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
On Sun, 28 Apr 2002, Robert Watson wrote:
As usual, GENERIC -CURRENT head from last night, from the main tree.
Dual-proc SMP box netbooted using PXE. System usually boots, does a
buildkernel -j 8 over NFS, then reboots and repeats. This time it didn't.
I actually have two boxes doing this, which does seem to double the rate
of panics I get.
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2
APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0
ad0: 19458MB ST320420A [39535/16/63] at ata0-master UDMA33
acd0: CDROM MATSHITA CR-176 at ata1-master PIO4
doSuMnPt:i nAgP rCoPoUt #f1r oLma unnfcsh:etsray irq 10
NFS ROOT: 192.168.50.1:/cboss/devel/nfsroot/crash1.cboss.tislabs.com
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x7974748b
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc02449b6
stack pointer = 0x10:0xc93dea14
frame pointer = 0x10:0xc93dea20
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 = 41 (sh)
kernel: type 12 trap, code=0
Stopped at _mtx_lock_flags+0x42: lock cmpxchgl %ecx,0x18(%ebx)
db trace
_mtx_lock_flags(79747473,0,c03cb862,e3) at _mtx_lock_flags+0x42
lockmgr(c93a8228,101,0,c8f27100) at lockmgr+0x42
vfs_busy(c93a8200,0,0,c8f27100) at vfs_busy+0x58
lookup(c93dec28,1a4,c8f03034,c93ded20,c8f27100) at lookup+0x3a2
namei(c93dec28,1a4,c8f03034,c93ded20,0) at namei+0x1c8
vn_open_cred(c93dec28,c93debf4,1a4,c3f80c80,c93dece8) at vn_open_cred+0x67
vn_open(c93dec28,c93debf4,1a4,c8f271dc,c8f27000) at vn_open+0x18
open(c8f27100,c93ded20,8125005,0,0) at open+0x158
syscall(2f,2f,2f,0,0) at syscall+0x223
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (5, FreeBSD ELF, open), eip = 0x808969b, esp = 0xbfbff8f0, ebp
= 0xbfbff91c ---
db
(kgdb) l *_mtx_lock_flags+0x42
0xc02449b6 is in _mtx_lock_flags (machine/atomic.h:139).
134 static __inline int
135 atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src)
136 {
137 int res = exp;
138
139 __asm __volatile (
140 __XSTRING(MPLOCKED)
141cmpxchgl %1,%2 ;
142setz%%al ;
143movzbl %%al,%0 ;
(gdb) l *lockmgr+0x42
0xc0242376 is in lockmgr (../../../kern/kern_lock.c:228).
223 pid = LK_KERNPROC;
224 else
225 pid = td-td_proc-p_pid;
226
227 mtx_lock(lkp-lk_interlock);
228 if (flags LK_INTERLOCK) {
229 mtx_assert(interlkp, MA_OWNED | MA_NOTRECURSED);
230 mtx_unlock(interlkp);
231 }
232
Attempts to get into serial gdb failed:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address = 0x6aa
fault code = supervisor read, page not present
Re: Page fault in swp_pager_meta_build()
:It currently has no swap started at all, which is one reason I was rather :puzzled to see this panic: : :192.168.50.1:/cboss/devel/nfsroot/crash2.cboss.tislabs.com / nfs ro 0 : 0 :proc/proc procfs rw 0 0 :/dev/ad0s1e /mntufs rw 0 0 :... :Should it even be hitting this code if swap hasn't been enabled? I've run :into a couple of other weird bugs and wouldn't be surprised if there is a :memory allocation problem. The problem I was actually trying to reproduce :with these two crash boxes was one where the socket used by NFS get :zero'd, resulting in a null pointer dereference. The other one is in odd :panic in the mutex code during an early VFS operation. : :Robert N M Watson FreeBSD Core Team, TrustedBSD Project The case can be hit but it shouldn't have found any swap to free. Huh. Maybe there is a degenerate case in the swap code that blows up if swap is compiled in but no swap has been added. If the problem goes away when you add a tiny amount of swap that would confirm it. What is the 'swhash_mask' global contain? -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, 28 Apr 2002, Crist J. Clark wrote: Hmm. I'd forgotten that the setgid kmem was removed in 4.x; I was probably thinking of top, which still is setgid in -STABLE. You'll find however, that -e won't work without setgid kmem being turned on. '-e' for ps(1) seems to work fine on processes you own. You cannot see the environments of other users' processes (of course root can see everyone's). But you do need /proc for '-e' to work. There might be other criteria where you wish to protect environmental information, such as for setugid processes, in jail, etc. Having the policy in kernel means that you can change it in one place, rather that tracking through various user space programs (which may not even have all the information they need). There are a number of other tools in -CURRENT that aren't setgid kmem where they are in -STABLE (top, iostat, etc). You know, I'm not sure why top(1) needs it if ps(1) doesn't. My recollection is that Thomas Moestl had to add a number of sysctl's to return system information that top previously pulled out of /dev/kmem. There are two related campaigns here: (1) Eliminate the requirements for procfs due to the risks involved There have been a large number of serious vulnerabilities due to the procfs concept a number of operating systems. A high percentage of our local anyone-to-root vulnerabilities have come from procfs. This combined with a largely redundant feature set lead to the conclusion that we should try and phase out the requirement that it be mounted, since a common hardening technique is to unmount it. (2) Eliminate the requirements for kmem due to the risks involved As with procfs, there have been a number of vulnerabilities associated with kmem, and as with procfs, when a vulnerability is present, the level of privilege that can be attained is high -- usually root with a little bit of work. Eiminating the use of kmem and replacing it with better defined sysctl APIs also means that the tight userland/kernel dependencies that used to result in failures during upgrades could be partially eliminated. Likewise, policy implemented in userspace could be further migrated to kernel space (limiting netstat socket display, process listings, etc). In both cases, the actual services themselves are not being eliminated, since they have uses (especially kmem) in some restricted environments (such as development), but the general requirement that they be used for common place activities is being reduced. A number of utilities still use kmem, and if anyone wants to pick up the task of converting them over the sysctl or other mechanisms, they should feel free :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
elf_freebsd_fixup: panic freeing imgp-auxargs
The usual setup: dual process -CURRENT box (crash2) from an hour or two
ago, network booted using pxeboot, with an NFS root. System boots, builds
a kernel, and reboots, repeating until panic. Doesn't take long :-).
This one is weird, as with many of them I suppose, and could mean possible
memory corruption, or a malloc/free bug. In essence, it appears to be
freeing the imgp-auxargs argument, which as far as I can tell shouldn't
get NULL'd, and yet free() indicates that it's not allocated.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0
intpin 2
APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0
ad0: 19458MB ST320420A [39535/16/63] at ata0-master UDMA33
acd0: CDROM MATSHITA CR-176 at ata1-master PIO4
doSuMnPt:i nAgP rCoPoUt #f1r oLma unnfcsh:e
ts
ray irq 10
NFS ROOT: 192.168.50.1:/cboss/devel/nfsroot/crash2.cboss.tislabs.com
panic: free: address 0xc93a8a80(0xc93a8000) has not been allocated.
cpuid = 0; lapic.id =
Debugger(panic)
Stopped at Debugger+0x41: xorl%eax,%eax
db trace
Debugger(c03cda9a) at Debugger+0x41
panic(c03cbc80,c93a8a80,c93a8000,bfbffe64,c93a8a80) at panic+0xd8
free(c93a8a80,c04271a0,1,0,c8710ba4) at free+0x76
elf_freebsd_fixup(c8710b30,c8710ba4,bfbfffe4,bfb2,c042474a) at
elf_freebsd_fixup+0x12b
execve(c8709100,c8710d10,bfbfffe4,bfb2,bfbfffe8,bfbd,bfbfffec,0)
at execve+0x3de
start_init(0,c8710d48,c8709100,c0230e50,0) at start_init+0x349
fork_exit(c0230e50,0,c8710d48) at fork_exit+0x88
fork_trampoline() at fork_trampoline+0x37
Debugger (msg=0xc03cda9a panic) at machine/atomic.h:227
227 ATOMIC_STORE_LOAD(int, cmpxchgl %0,%1, xchgl %1,%0)
(kgdb) bt
#0 Debugger (msg=0xc03cda9a panic) at machine/atomic.h:227
#1 0xc024c094 in panic (
fmt=0xc03cbc80 free: address %p(%p) has not been allocated.\n)
at ../../../kern/kern_shutdown.c:477
#2 0xc0243472 in free (addr=0xc93a8a80, type=0xc04271a0)
at ../../../kern/kern_malloc.c:222
#3 0xc02300a3 in elf_freebsd_fixup (stack_base=0xc8710b30,
imgp=0xc8710ba4)
at ../../../kern/imgact_elf.c:711
#4 0xc0239fbe in execve (td=0xc8709100, uap=0xc8710d10)
at ../../../kern/kern_exec.c:278
#5 0xc0231199 in start_init (dummy=0x0) at ../../../kern/init_main.c:610
#6 0xc023d5d8 in fork_exit (callout=0xc0230e50 start_init, arg=0x0,
frame=0xc8710d48) at ../../../kern/kern_fork.c:808
(kgdb) up
#1 0xc024c094 in panic (
fmt=0xc03cbc80 free: address %p(%p) has not been allocated.\n)
at ../../../kern/kern_shutdown.c:477
477 Debugger (panic);
(kgdb) up
#2 0xc0243472 in free (addr=0xc93a8a80, type=0xc04271a0)
at ../../../kern/kern_malloc.c:222
222 panic(free: address %p(%p) has not been
allocated.\n,
(kgdb) up
#3 0xc02300a3 in elf_freebsd_fixup (stack_base=0xc8710b30,
imgp=0xc8710ba4)
at ../../../kern/imgact_elf.c:711
711 free(imgp-auxargs, M_TEMP);
(kgdb) inspect imgp
$1 = (struct image_params *) 0xc8710ba4
(kgdb) inspect *imgp
$2 = {proc = 0xc8709000, uap = 0xc8710d10, vp = 0xc93a51e0, attr =
0xc8710b44,
image_header = 0xc7f08000 \177ELF\001\001\001\t,
stringbase = 0xc7ef8000 /sbin/init, stringp = 0xc7ef800e ,
endargs = 0xc7ef800e , stringspace = 65522, argc = 2, envc = 0,
argv0 = 0x0, entry_addr = 134513216, vmspace_destroyed = 1 '\001',
interpreted = 0 '\000',
interpreter_name =
\000\000\xe9b?\xc0F\002\000\000\xdc\221p\xc8\xd2\002\000\0
00\xe9b?\xc0F\002\000\000(\fq\xc8\xe4G$\xc0\xdc\221p\xc8\b\000\000\000\xe9b?\xc0
\xd2\002\000\000\xdc\221p\xc8\001\000\000\000\xd7\xca\xc0K\001\000\000\xdc\221p
\xc8\000\220p\xc8\000\000\000\000X\fq\xc8\024\2037\xc0\xdc\221p\xc8\000\000\000\
000\xe9b?\xc0\xd2\002\000\000\f\000\000\000\000\000\000\000\002\000\000\000\000\
221p\xc8\002%$\xc0\000\xf0\xbf\xbf\214\f, auxargs = 0xc93a8a80, firstpage
= 0xc
0a2edc4,
fname = 0xbfb2 \xbf\xbf\002, ps_strings = 0, auxarg_size = 30}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: page fault in _mtx_lock_flags
If I apply the attached diff to the kern_malloc.c, backing out a portion
of kern_malloc.c:1.99, the rate of panics plummets. Previously, I could
have a box panic within five minutes of getting the crash boxes spinning.
Now I've been going for about 40 minutes without any perceived failures
(i.e., no panics). I have no idea why this fixes the problem, but David
Wolfskill pointed me at that particular revision as being a source of
related problems for him. I'm going to leave the boxes running overnight
and see what I bump into. It would be nice to know if this is masking the
problem, or fixing the problem, and if so, why.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
On Sun, 28 Apr 2002, Robert Watson wrote:
I also get an almost identical fault on crash1 involving mdconfig as
opposed to sh:
ray irq 10
NFS ROOT: 192.168.50.1:/cboss/devel/nfsroot/crash1.cboss.tislabs.com
8.50.10 BroadcasP-Address 192.16
t 192.168.50.255
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address = 0x6b73697c
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc02449b6
stack pointer = 0x10:0xc93d8a14
frame pointer = 0x10:0xc93d8a20
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 = 44 (mdconfig)
kernel: type 12 trap, code=0
Stopped at _mtx_lock_flags+0x42: lock cmpxchgl %ecx,0x18(%ebx)
db trace
_mtx_lock_flags(6b736964,0,c03cb862,e3) at _mtx_lock_flags+0x42
lockmgr(c93a8228,101,0,c8f27100) at lockmgr+0x42
vfs_busy(c93a8200,0,0,c8f27100) at vfs_busy+0x58
lookup(c93d8c28,0,c93b9c34,c93d8d20,c8f27100) at lookup+0x3a2
namei(c93d8c28,0,c93b9c34,c93d8d20,0) at namei+0x1c8
vn_open_cred(c93d8c28,c93d8bf4,0,c3f80c80,c93d8ce8) at vn_open_cred+0x23b
vn_open(c93d8c28,c93d8bf4,0,c8f271dc,c8f27000) at vn_open+0x18
open(c8f27100,c93d8d20,0,0,0) at open+0x158
syscall(2f,2f,2f,0,0) at syscall+0x223
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (5, FreeBSD ELF, open), eip = 0x804950b, esp = 0xbfbffd14, ebp
= 0xbfbffd50 ---
db Context switches not allowed in the debugger.
db
Still not clear what the origin of this is -- possibly memory corruption
of the mutex..?
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
On Sun, 28 Apr 2002, Robert Watson wrote:
As usual, GENERIC -CURRENT head from last night, from the main tree.
Dual-proc SMP box netbooted using PXE. System usually boots, does a
buildkernel -j 8 over NFS, then reboots and repeats. This time it didn't.
I actually have two boxes doing this, which does seem to double the rate
of panics I get.
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2
APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0
ad0: 19458MB ST320420A [39535/16/63] at ata0-master UDMA33
acd0: CDROM MATSHITA CR-176 at ata1-master PIO4
doSuMnPt:i nAgP rCoPoUt #f1r oLma unnfcsh:etsray irq 10
NFS ROOT: 192.168.50.1:/cboss/devel/nfsroot/crash1.cboss.tislabs.com
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x7974748b
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc02449b6
stack pointer = 0x10:0xc93dea14
frame pointer = 0x10:0xc93dea20
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 = 41 (sh)
kernel: type 12 trap, code=0
Stopped at _mtx_lock_flags+0x42: lock cmpxchgl %ecx,0x18(%ebx)
db trace
_mtx_lock_flags(79747473,0,c03cb862,e3) at _mtx_lock_flags+0x42
lockmgr(c93a8228,101,0,c8f27100) at lockmgr+0x42
vfs_busy(c93a8200,0,0,c8f27100) at vfs_busy+0x58
lookup(c93dec28,1a4,c8f03034,c93ded20,c8f27100) at lookup+0x3a2
namei(c93dec28,1a4,c8f03034,c93ded20,0) at namei+0x1c8
vn_open_cred(c93dec28,c93debf4,1a4,c3f80c80,c93dece8) at vn_open_cred+0x67
vn_open(c93dec28,c93debf4,1a4,c8f271dc,c8f27000) at vn_open+0x18
open(c8f27100,c93ded20,8125005,0,0) at open+0x158
syscall(2f,2f,2f,0,0) at syscall+0x223
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (5, FreeBSD ELF, open), eip = 0x808969b, esp = 0xbfbff8f0, ebp
= 0xbfbff91c ---
db
(kgdb) l *_mtx_lock_flags+0x42
0xc02449b6 is in _mtx_lock_flags (machine/atomic.h:139).
134 static __inline int
135 atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src)
136 {
137 int
building -current on -stable broken?
I'm trying to build -current from today (4/28/2002) on a -stable box with a kernel/world from April 25th. It blows up in xlint: == cc -O -pipe -I. -I/c/ken/perforce/FreeBSD-ken/src/usr.bin/xlint/lint1 -I/c/ken/perforce/FreeBSD-ken/src/usr.bin/xlint/lint1/../arch/i386 -I/c/ken/perforce/FreeBSD-ken/src/usr.bin/xlint/lint1/../common-D__FBSDID=__RCSID -static -o lint1 cgram.o scan.o mem1.o mem.o err.o main1.o decl.o tree.o func.o init.o emit.o emit1.o inittyp.o -ll -lm cgram.o: In function `yyparse': cgram.o(.text+0x10b8): undefined reference to `xcalloc' cgram.o(.text+0x10f0): undefined reference to `xcalloc' scan.o: In function `ccon': scan.o(.text+0x23f7): undefined reference to `xcalloc' func.o: In function `label': func.o(.text+0x6a8): undefined reference to `xcalloc' init.o: In function `prepinit': init.o(.text+0x78): undefined reference to `xcalloc' init.o(.text+0x214): more undefined references to `xcalloc' follow emit.o: In function `outopen': emit.o(.text+0x4f): undefined reference to `xmalloc' emit.o: In function `outxbuf': emit.o(.text+0xd4): undefined reference to `xrealloc' emit1.o: In function `ttos': emit1.o(.text+0x2d5): undefined reference to `xmalloc' *** Error code 1 Stop in /c/ken/perforce/FreeBSD-ken/src/usr.bin/xlint/lint1. *** Error code 1 Stop in /c/ken/perforce/FreeBSD-ken/src. *** Error code 1 Stop in /c/ken/perforce/FreeBSD-ken/src. *** Error code 1 Stop in /c/ken/perforce/FreeBSD-ken/src. == Am I doing something wrong here or is building -current on -stable broken? Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
