similar to: FreeBSD-SA-99:01: BSD File Flags and Programming Techniques

>Submitter-Id: current-users >Originator: Joao Carlos Mendes Luis >Organization: >Confidential: no >Synopsis: FreeBSD mknod refuses to create pipes and fifos >Severity: non-critical >Priority: low >Category: kern >Class: change-request >Release: FreeBSD 4.9-RC i386 >Environment: System: FreeBSD zeus.faperj.br 4.9-RC FreeBSD 4.9-RC #3: Sat Oct 25 17:54:52 BRST

-----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-98:02 Security Advisory FreeBSD, Inc. Topic: security compromise via mmap Category: core Module: kernel Announced: 1998-03-12 Affects:

-----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-99:04 Security Advisory FreeBSD, Inc. Topic: Coredumps and symbolic links Category: core Module: kernel Announced: 1999-09-15 Affects:

Hi Ian and others, umount(8) -f does crash here on several just updated 4.8STABLE boxes for nfs volumes. Server is an IRIX server. All clients are FreeBSD. Here is a backtrace: #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 #1 0xc021f1c0 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:316 #2 0xc021f60d in panic (fmt=0xc03bd664 "from debugger") at

In zfs_mount() function, when we process a mount by a regular user through the delegated administration, the comment states: /* * Make sure user is the owner of the mount point * or has sufficient privileges. */ This makes sense, but the code doesn''t match the comment. The code ensures that user is the owner of the mount point _and_ can write to the directory. Or does "has

Here's a patch against 4.8-RELEASE kernel that allows disk writes on softupdates-enabled filesystems to be delayed for (theoretically) arbitrarily long periods of time. The motivation for such updating policy is surprisingly not purely suicidal - it can allow disks on laptops to spin down immediately after I/O operations and stay idle for longer periods of time, thus saving considerable amount

After about a day and a half or so of uptime, I'm getting the aforementioned panic on the server ... better then having it hang solid, but right now I'm not sure if this is replacing it, or just one being triggered earlier then the other ... First scan through Google, I came across some posts talking about NMBCLUSTERS ... since its at the same settings as my other server (the default)

neptune# ps -M vmcore.1 -N kernel.debug -axl | grep inode | wc -l 961 and I have a vmcore to work on here !! :) (kgdb) proc 99643 (kgdb) bt #0 mi_switch () at machine/globals.h:119 #1 0x8014a1f9 in tsleep (ident=0x8a4ef600, priority=8, wmesg=0x80263d4a "inode", timo=0) at /usr/src/sys/kern/kern_synch.c:479 #2 0x80141507 in acquire (lkp=0x8a4ef600, extflags=16777280,

There is a rather serious race with copyout() and process termination in -stable. sysctl_kern_proc() loops through the allproc list writing the results to user memory. If it stalls during the copyout (e.g. the user memory has to take a vm_fault) and the process is ripped out from under it it will go looping into never never land. The solution is very simple, simply

grep union /var/log/messages Jul 2 12:53:01 jupiter savecore: reboot after panic: union_lookup returning . (0xc68e9e90) not same as startdir (0xc5e062c0) Jul 2 14:35:07 jupiter savecore: reboot after panic: union_lookup returning . (0xbf6fee90) not same as startdir (0xbb6d58c0) had two of them today, dumping nice cores ... I'm suspecting its someone trying to remove a file that is

For FreeBSD 4.7 I've discovered the cause of the deadlock, but I can't figure out how to fix it. See below for traces. If the vnode limit has been reached, the vnlru process is kicked and the requestor goes to sleep to wait for the vnlru process to signal that vnodes are available (10% of the vnodes need to be freed). Under our test, none of the nodes meet the criteria for freeing,

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- This syncs it up with what's in envytools. Some of the names are a bit different, but I'm inclined to trust envytools as the correct thing. drivers/gpu/drm/nouveau/core/engine/graph/nv50.c | 29 ++++++++++++------------ 1 file changed, 15 insertions(+), 14 deletions(-) diff --git

After booting from a 10-alpha2 disk I am seeing "lock order reversal" messages show up from time to time. Current logs have 35 entries. The machine normally is running 9.1 from zfs root and I have setup a separate disk (eSATA case connected through backplane port to onboard SATA port) that I have installed 10-alpha amd64 onto a ufs partition to test port building with. I started by

Hello folks, I have a panic at shutdown related to FUSE. #0 doadump (textdump=<value optimized out>) at pcpu.h:234 234 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt full #0 doadump (textdump=<value optimized out>) at pcpu.h:234 No locals. #1 0xffffffff8090d9a6 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 _ep = (struct

Some more crashes of 4.8-RELEASE. Lets see what do I have today: # ls -l /var/crash total 1576676 -rw-r--r-- 1 root wheel 2 Jul 30 13:31 bounds -rw-r--r-- 1 root wheel 2193252 Jun 25 17:30 kernel.0 -rw-r--r-- 1 root wheel 2193252 Jul 4 00:08 kernel.1 -rw-r--r-- 1 root wheel 2193252 Jul 15 19:28 kernel.2 -rw-r--r-- 1 root wheel 2193252 Jul 16 17:50 kernel.3

[ Normally I'd have replied to the original email but I couldn't figure out a way to subscribe to a list, and then reply to an email already posted to the list.] I have this very problem (with a different card): http://lists.freebsd.org/pipermail/freebsd-stable/2009-April/049618.html It looks like drm_open_helper() gets a NULL dev parameter and a panic occurs when it attempts to set

Getting the following panic on a new Dell Poweredge 1650. This machine is going to be a VPN server and has a large number of pptp links configured. The machine is stable if mpd is not running. (kgdb) where #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 #1 0xc0229a0f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:316 #2 0xc0229e4d in panic (fmt=0xc042876c "%s") at

Not sure what all to do, but doing a 'gdb -k kernel.debug /dev/mem', a backtrack on one of the processes shows ... server has been up 12 days now, and running a June 8th kernel ... #0 0x20f4f0 in ?? () (kgdb) proc 67258 (kgdb) bt #0 mi_switch () at machine/globals.h:119 #1 0x8014a1f9 in tsleep (ident=0x8a3d2200, priority=8, wmesg=0x80263d4a "inode", timo=0) at

Hello list, I have been fighting this problem for a few days now. I have changed memory and opened the case and monitored for heat. I have been getting the same panic about every 12 to 24 hours. I can let the system sit idle, or run it under a heavy load (cpu and disk), but the panics dont seem to be related to system load. It looks to me like a dangling pointer in softdep_update_inodeblock,

Hi stable, nice you see you again. I was one of those guys who was seeing constand panics on 24 hour boundaries but couldn't provide a backtrace due to the ar device not taking a dump. I installed a dedicated drive just to take the dump, and then didn't have a panic for a couple weeks. Now, I am back with, and I have traces to share. The first two, from 2003-09-27 and 2003-09-28