Re: /dev/dsp* & /dev/audio* devices not present
"Rick C. Petty" wrote: > On Sat, Jan 10, 2009 at 04:20:58AM -0800, per...@pluto.rain.com wrote: > > "Rick C. Petty" wrote: > > > > > > That's not how devfs works. It's actually a feature > > > that devfs doesn't list everything ever possible > > > > http://storage9.myopera.com/freejerk/files/bug-feature.jpg > > Funny. But this isn't a bug disguised as a feature. > It's a feature that you believe is a bug. I would call it a bug that you believe is a feature. > > > I'd rather be able to list to see things that are in use, > > > although at first glance I didn't like devfs hidden nodes. > > > Otherwise you'd be stuck printing tunXXX through infinity > > > instead of this: > > > > > > % ls /dev/tun* > > > /dev/tun0 /dev/tun115 /dev/tun194 > > > > In any other part of the directory tree we expect ls to provide > > a list of names that are available to be opened (subject to > > permissions). Why should /dev be any different? > > Because it's a special filesystem. I think that constitutes an admission that it violates POLA, and it's not much of a justification IMO. > > Since you aren't supposed to open (say) /dev/tun85, but only > > /dev/tun0, correspondence between readdir and open would not > > demand > > What? Why aren't you supposed to open tun85? I use this behavior > all the time and have for years. It helps keep track of things. > Otherwise I would have to keep my natd configuration, firewall > rules, and openvpn configuration all in sync. Please provide a > reference describing you're not "supposed to" open any arbitrary > tunnelling device. The manpage for tun(4) says: tun does for network interfaces what the pty(4) driver does for terminals ... The network interfaces are named ``tun0'', ``tun1'', etc., one for each control device that has been opened ... The tun interface permits opens on the special control device /dev/tun. When this device is opened, tun will return a handle for the **lowest** unused tun device ... (emphasis added). The whole point of cloning devices is to avoid the need for the application to loop through a sequence of possible names to find one that is not in use; it simply opens the generic name and gets a (pseudo) device. BTW I was slightly off -- it is /dev/tun rather than /dev/tun0 that's supposed to be opened -- but if anything this strengthens my point (see below). > > that readdir return the (large, if not infinite) list of > > potential instances. It would however seem reasonable for > > that ls command to show /dev/tun0 if its driver is loaded, > > even if the device has not been instantiated because the > > node has never been opened. > > I don't buy that argument at all. If anything it should show > "/dev/tun", Agreed it should be /dev/tun -- see above. > but why create device nodes when they aren't necessary, as you > have to clone the nodes (or create new ones) when an actual > open(2) occurs? As I stated earlier in this thread: * It doesn't necessarily need to actually create them, but the * results from readdir(2) should be as if they had been created. > > > This is not a bug, it is designed behavior. It was > > > intentionally written to dynamically create device > > > nodes when needed. > > > > That the code faithfully adheres to the design does not > > guarantee that the design is flawless. IMO it violates > > POLA, if not POSIX, > > Please provide the reference where it violates POSIX. I am not familiar with POSIX in detail, which is why I only suggest that it *may* violate POSIX. You're welcome to research the matter. I would *expect* that research to find that there is supposed to be a correspondence between what readdir reports as the contents of a directory, and the results of attempting to open a filename in the directory whose contents were read; if not, what would be the point of having readdir in the first place? > > for open(2) to succeed when applied to a name which, according > > to readdir(2), does not exist; > > What? This can happen already-- there is no atomicity between > a readdir and an open. Of course not, but we are not dealing here with a case in which process A reads the directory, then process B creates a file in it, and thus that file becomes visible to process A. Instead we have a magical side-effect, wherein process A opens a file which (per readdir) does not exist, and thereby calls into existence a new file, while the name that process A opened *still* does not exist. > And what about msdosfs and case-insensitivity? You can > certainly open files that weren't a part of your readdir. The semantics of msdosfs are driven by the need to maintain compatibility with a certain other operating system -- the one which defined that filesystem representation in the first place. I hardly think it should be considered a good precedent. > Also no one in their right mind would be coding a readdir/open > solution against a filesystem known to be completely dynamic and > especially against devfs.
Re: extattr problems?
I think this one is a bug. It appears that extattr_set_fd()
obeys the permissions on the file, not the permissions
of the descriptor. In particular, I see this on
FreeBSD 6.3:
[...@dark /tmp]$ ./extattr_test
fd=3
extattr_set_fd() = -1
errno = 13 (Permission denied)
[...@dark /tmp]$ cat extattr_test.c
#include
#include
#include
#include
#include
int
main(int argc, char **argv)
{
int n, fd;
fd = open("/tmp/test12345", O_RDWR | O_CREAT | O_EXCL, );
printf("fd=%d\n", fd);
n = extattr_set_fd(fd, EXTATTR_NAMESPACE_USER,
"testattr", "1234", 4);
printf("extattr_set_fd() = %d\n", n);
if (n != 0)
printf("errno = %d (%s)\n",
errno, strerror(errno));
exit(0);
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: extattr problems?
pluknet wrote: It's strange.. FreeBSD jaw.ripn.net 6.3-RELEASE-p5. works for me (tm), extattr_set_fd() returns 4 as expected. Thank you! *That* was my mistake; I thought extattr_set_fd() returned 0 on success, non-zero on error. I re-read the man page and now everything makes sense. Thank you again! Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Question about panic in brelse()
Hi,
I observe a failed assertion in the VFS regarding a buffer. I
investigated a bit and now I want to present my findings and I have a
question:
Assume I have a buffer with
b_iocmd = BIO_WRITE
b_ioflags = BIO_ERROR
b_error = EIO
b_flags = B_NOCACHE
passed to brelse() in kern/vfs_bio.c[0].
- This particular combination of values (line 1144) causes BIO_ERROR to
be cleared (line 1152) and B_DELWRI is set in bdirty() (line 1031,
called in line 1153).
- Because of B_NOCACHE (line 1343) this buffer gets moved to QUEUE_CLEAN
(line 1349). Also B_INVAL gets set here (line 1345).
- A few lines down (line 1375) bundirty() gets called because of B_INVAL
and B_DELWRI.
- bundirty() instantly panics because the buffer is not in QUEUE_NONE
(line 1075).
My question is: Is this a bug in brelse() or was the combination of flag
B_NOCACHE with a failed write attempt (BIO_WRITE, BIO_ERROR, EIO)
invalid when the buffer was passed to brelse()?
Below is a dump of the buffer right when the assertion is triggered. If
you want any further information about this issue, please tell me.
Hopefully somebody can shed some light on this
Christoph
{
b_bufobj = 0xff0030005e00,
b_bcount = 16384,
b_caller1 = 0x0,
b_data = 0xfffea2c57000 "",
b_error = 5, (EIO)
b_iocmd = 2 '\002', (BIO_WRITE)
b_ioflags = 2 '\002', (BIO_DONE)
b_iooffset = 98304,
b_resid = 16384,
b_iodone = 0,
b_blkno = 192,
b_offset = 98304,
b_bobufs = { tqe_next = 0x0, tqe_prev = 0xff0030005e40},
b_left = 0x0,
b_right = 0x0,
b_vflags = 0,
b_freelist = {
tqe_next = 0xfffe92d747c8,
tqe_prev = 0x80d340f0
},
b_qindex = 1, (QUEUE_CLEAN)
b_flags = 41092, (B_NOCACHE | b_INVAL | B_DELWRI | B_ASYNC)
b_xflags = 33 '!',
b_lock = {
lock_object = {
lo_name = 0x808d01b6 "bufwait",
lo_flags = 91947008,
lo_data = 0,
lo_witness = 0xfffe40206180
},
lk_lock = 18446744073709551608,
lk_timo = 0,
lk_pri = 80
},
b_bufsize = 16384,
b_runningbufspace = 0,
b_kvabase = 0xfffea2c57000 "",
b_kvasize = 16384,
b_lblkno = 192,
b_vp = 0xff0030005ce8,
b_dirtyoff = 0,
b_dirtyend = 0,
b_rcred = 0x0,
b_wcred = 0x0,
b_saveaddr = 0xfffea2c57000,
b_pager = {pg_reqpage = 0},
b_cluster = {
cluster_head = {
tqh_first = 0xfffe92d747c8,
tqh_last = 0xfffe92d73ad0
},
cluster_entry = {
tqe_next = 0xfffe92d747c8,
tqe_prev = 0xfffe92d73ad0
}
},
b_pages = {
0xff00de3ce5a0, 0xff00de3ce610,
0xff00de3ce680, 0xff00de3ce6f0,
$0x0
},
b_npages = 4,
b_dep = { lh_first = 0x0 },
b_fsprivate1 = 0x0,
b_fsprivate2 = 0x0,
b_fsprivate3 = 0x0,
b_pin_count = 0
}
[0] r183754 in head/, which is the latest version of kern/vfs_bio.c.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Small change to 'ps'
At 1:51 AM -0500 1/9/09, Mike Meyer wrote: On Wed, 7 Jan 2009 "Sheldon Givens" wrote: > And I guess I just feel like running a second command to do what should be possible to do with the first command (and is, on many platforms. ps --no-headers on linux for example) is a problem and presents opportunity for continued refinement of the utility. I agree. However, [...] So `--no-headers' is ok. However, `-n' has lots of different meanings in different commands. How about borrowing from existing commands that already implement this functionality (zfs and zpool) and using `-H', which is relatively rarely used elsewhere? I recommend against adding any single-letter option to the `ps' command. This command is already an absolute minefield of headaches when it comes to portability across operating systems (and POSIX). Trying to sneak in some single-letter option is bound to give us headaches in the long run. Adding something like '--no-headers' is pretty safe, although that opens up a different set of arguments (heh) when it comes to `ps' on freebsd. Namely, we don't have any long-options in our `ps'. Yet another tactic might be to add another accepted keyword to '-o', since it already uses words as its acceptable values. We'd be bending the definition of `-o' a bit to do that, but we could at least do that in a way which would be very unlikely to conflict with an option in any other version of `ps'. -- Garance Alistair Drosehn = dros...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kernel dump with 7.1-RELEASE
Hi Kostik,
I will try that patch and will return to -hackers if that solves semid not
allocated problem. Thanks for prompt action.
Best Regards.
On Sun, Jan 11, 2009 at 5:58 PM, Kostik Belousov wrote:
> On Fri, Jan 09, 2009 at 06:39:53PM +0200, Omer Faruk Sen wrote:
> > Hi,
> >
> > I am having kernel dump with FreeBSD 7.1:
> >
> > Here is crashinfo output of it (Actually i don't know the state of
> > crashinfo in Fbsd 7.1)
> >
> > 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 08:58:24 UTC 2009
> > r...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
> >
> >
> >
> > panic: semexit - semid not allocated
> >
> > GNU gdb 6.1.1 [FreeBSD]
> > Copyright 2004 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 "amd64-marcel-freebsd"...
> >
> > Unread portion of the kernel message buffer:
> > Physical memory: 8173 MB
> > Dumping 437 MB: 422 406 390 374 358 342 326 310 294 278 262 246 230
> > 214 198 182 166 150 134 118 102 86 70 54 38 22 6
> >
> > #0 doadump () at pcpu.h:195
> > 195 pcpu.h: No such file or directory.
> > in pcpu.h
> > (kgdb) #0 doadump () at pcpu.h:195
> > #1 0x0004 in ?? ()
> > #2 0x804b4ce9 in boot (howto=260)
> > at /usr/src/sys/kern/kern_shutdown.c:418
> > #3 0x804b50f2 in panic (fmt=0x104 )
> > at /usr/src/sys/kern/kern_shutdown.c:574
> > #4 0x804f846d in semexit_myhook (arg=Variable "arg" is not
> available.
> > )
> > at /usr/src/sys/kern/sysv_sem.c:1328
> > #5 0x80490dbc in exit1 (td=0xff000995f370, rv=0)
> > at /usr/src/sys/kern/kern_exit.c:244
> > #6 0x8049239e in sys_exit (td=Variable "td" is not available.
> > ) at /usr/src/sys/kern/kern_exit.c:109
> > #7 0x8078a7c7 in syscall (frame=0xb0d4ac80)
> > at /usr/src/sys/amd64/amd64/trap.c:907
> > #8 0x8077088b in Xfast_syscall ()
> > at /usr/src/sys/amd64/amd64/exception.S:330
> > #9 0x000800a2a30c in ?? ()
> > Previous frame inner to this frame (corrupt stack?)
> > (kgdb)
>
> It seems that there are at least two issues with IPC_RMID operation
> on SysV semaphores.
> 1. The squeeze of the semaphore array in the kern_semctl() modifies
> sem_base for the semaphores, as well as the values of the
> semaphores, without locking their mutex. This can lead to
> (killable) hangs or unexpected behaviour of the processes
> performing any sem operations while other process does IPC_RMID.
> 2. The semexit_myhook() eventhandler does not lock SEMUNDO_LOCK()
> while accessing *suptr. I think that this allows for IPC_RMID
> to be performed in parallel with the sem id referenced by the
> current undo structure.
>
> Patch below is the backport of the patch I developed and lightly
> tested on CURRENT, that shuffle locking to solve the listed issues.
> Testing consisted of running several instances of
> tools/regression/sysvsem.
>
> diff --git a/sys/kern/sysv_sem.c b/sys/kern/sysv_sem.c
> index 80d07ba..6bc4cce 100644
> --- a/sys/kern/sysv_sem.c
> +++ b/sys/kern/sysv_sem.c
> @@ -88,7 +88,7 @@ int semop(struct thread *td, struct semop_args *uap);
>
> static struct sem_undo *semu_alloc(struct thread *td);
> static int semundo_adjust(struct thread *td, struct sem_undo **supptr,
> - int semid, int semnum, int adjval);
> +int semid, int semseq, int semnum, int adjval);
> static void semundo_clear(int semid, int semnum);
>
> /* XXX casting to (sy_call_t *) is bogus, as usual. */
> @@ -98,15 +98,17 @@ static sy_call_t *semcalls[] = {
> };
>
> static struct mtx sem_mtx;/* semaphore global lock */
> +static struct mtx sem_undo_mtx;
> static int semtot = 0;
> static struct semid_kernel *sema; /* semaphore id pool */
> static struct mtx *sema_mtx; /* semaphore id pool mutexes*/
> static struct sem *sem;/* semaphore pool */
> -SLIST_HEAD(, sem_undo) semu_list; /* list of active undo structures
> */
> +LIST_HEAD(, sem_undo) semu_list; /* list of active undo structures
> */
> +LIST_HEAD(, sem_undo) semu_free_list; /* list of free undo structures */
> static int *semu; /* undo structure pool */
> static eventhandler_tag semexit_tag;
>
> -#define SEMUNDO_MTXsem_mtx
> +#define SEMUNDO_MTXsem_undo_mtx
> #define SEMUNDO_LOCK() mtx_lock(&SEMUNDO_MTX);
> #define SEMUNDO_UNLOCK() mtx_unlock(&SEMUNDO_MTX);
> #define SEMUNDO_LOCKASSERT(how)mtx_assert(&SEMUNDO_MTX, (how));
> @@ -122,13 +124,15 @@ struct sem {
> * Undo structure (one per process)
> */
> struct sem_undo {
> - SLIST_ENTRY(sem_undo) un_next; /* ptr to next active undo
> structure */
> + LIST_ENTRY(sem_undo)
Re: /dev/dsp* & /dev/audio* devices not present
On Sat, Jan 10, 2009 at 04:20:58AM -0800, per...@pluto.rain.com wrote: > "Rick C. Petty" wrote: > > > > That's not how devfs works. It's actually a feature > > that devfs doesn't list everything ever possible > > http://storage9.myopera.com/freejerk/files/bug-feature.jpg Funny. But this isn't a bug disguised as a feature. It's a feature that you believe is a bug. > > I'd rather be able to list to see things that are in use, although > > at first glance I didn't like devfs hidden nodes. Otherwise you'd > > be stuck printing tunXXX through infinity instead of this: > > > > % ls /dev/tun* > > /dev/tun0 /dev/tun115 /dev/tun194 > > In any other part of the directory tree we expect ls to provide > a list of names that are available to be opened (subject to > permissions). Why should /dev be any different? Because it's a special filesystem. > Since you aren't supposed to open (say) /dev/tun85, but only > /dev/tun0, correspondence between readdir and open would not demand What? Why aren't you supposed to open tun85? I use this behavior all the time and have for years. It helps keep track of things. Otherwise I would have to keep my natd configuration, firewall rules, and openvpn configuration all in sync. Please provide a reference describing you're not "supposed to" open any arbitrary tunnelling device. > that readdir return the (large, if not infinite) list of potential > instances. It would however seem reasonable for that ls command to > show /dev/tun0 if its driver is loaded, even if the device has not > been instantiated because the node has never been opened. I don't buy that argument at all. If anything it should show "/dev/tun", but why create device nodes when they aren't necessary, as you have to clone the nodes (or create new ones) when an actual open(2) occurs? > > This is not a bug, it is designed behavior. It was intentionally > > written to dynamically create device nodes when needed. > > That the code faithfully adheres to the design does not guarantee > that the design is flawless. IMO it violates POLA, if not POSIX, Please provide the reference where it violates POSIX. > for open(2) to succeed when applied to a name which, according to > readdir(2), does not exist; What? This can happen already-- there is no atomicity between a readdir and an open. And what about msdosfs and case-insensitivity? You can certainly open files that weren't a part of your readdir. Also no one in their right mind would be coding a readdir/open solution against a filesystem known to be completely dynamic and especially against devfs. You would want to tie in directly to devctl, sysctl, or syscall. > and it is suboptimal to have "stealth" > drivers whose availability for use cannot be discovered by examining > /dev. Why is it suboptimal? I think you have that backwards-- it's more optimal not to have to create superfluous device nodes when they are not needed, at least from the kernel efficiency perspective. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kernel dump with 7.1-RELEASE
On Fri, Jan 09, 2009 at 06:39:53PM +0200, Omer Faruk Sen wrote:
> Hi,
>
> I am having kernel dump with FreeBSD 7.1:
>
> Here is crashinfo output of it (Actually i don't know the state of
> crashinfo in Fbsd 7.1)
>
> 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 08:58:24 UTC 2009
> r...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
>
>
>
> panic: semexit - semid not allocated
>
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 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 "amd64-marcel-freebsd"...
>
> Unread portion of the kernel message buffer:
> Physical memory: 8173 MB
> Dumping 437 MB: 422 406 390 374 358 342 326 310 294 278 262 246 230
> 214 198 182 166 150 134 118 102 86 70 54 38 22 6
>
> #0 doadump () at pcpu.h:195
> 195 pcpu.h: No such file or directory.
> in pcpu.h
> (kgdb) #0 doadump () at pcpu.h:195
> #1 0x0004 in ?? ()
> #2 0x804b4ce9 in boot (howto=260)
> at /usr/src/sys/kern/kern_shutdown.c:418
> #3 0x804b50f2 in panic (fmt=0x104 )
> at /usr/src/sys/kern/kern_shutdown.c:574
> #4 0x804f846d in semexit_myhook (arg=Variable "arg" is not available.
> )
> at /usr/src/sys/kern/sysv_sem.c:1328
> #5 0x80490dbc in exit1 (td=0xff000995f370, rv=0)
> at /usr/src/sys/kern/kern_exit.c:244
> #6 0x8049239e in sys_exit (td=Variable "td" is not available.
> ) at /usr/src/sys/kern/kern_exit.c:109
> #7 0x8078a7c7 in syscall (frame=0xb0d4ac80)
> at /usr/src/sys/amd64/amd64/trap.c:907
> #8 0x8077088b in Xfast_syscall ()
> at /usr/src/sys/amd64/amd64/exception.S:330
> #9 0x000800a2a30c in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb)
It seems that there are at least two issues with IPC_RMID operation
on SysV semaphores.
1. The squeeze of the semaphore array in the kern_semctl() modifies
sem_base for the semaphores, as well as the values of the
semaphores, without locking their mutex. This can lead to
(killable) hangs or unexpected behaviour of the processes
performing any sem operations while other process does IPC_RMID.
2. The semexit_myhook() eventhandler does not lock SEMUNDO_LOCK()
while accessing *suptr. I think that this allows for IPC_RMID
to be performed in parallel with the sem id referenced by the
current undo structure.
Patch below is the backport of the patch I developed and lightly
tested on CURRENT, that shuffle locking to solve the listed issues.
Testing consisted of running several instances of
tools/regression/sysvsem.
diff --git a/sys/kern/sysv_sem.c b/sys/kern/sysv_sem.c
index 80d07ba..6bc4cce 100644
--- a/sys/kern/sysv_sem.c
+++ b/sys/kern/sysv_sem.c
@@ -88,7 +88,7 @@ int semop(struct thread *td, struct semop_args *uap);
static struct sem_undo *semu_alloc(struct thread *td);
static int semundo_adjust(struct thread *td, struct sem_undo **supptr,
- int semid, int semnum, int adjval);
+int semid, int semseq, int semnum, int adjval);
static void semundo_clear(int semid, int semnum);
/* XXX casting to (sy_call_t *) is bogus, as usual. */
@@ -98,15 +98,17 @@ static sy_call_t *semcalls[] = {
};
static struct mtx sem_mtx;/* semaphore global lock */
+static struct mtx sem_undo_mtx;
static int semtot = 0;
static struct semid_kernel *sema; /* semaphore id pool */
static struct mtx *sema_mtx; /* semaphore id pool mutexes*/
static struct sem *sem;/* semaphore pool */
-SLIST_HEAD(, sem_undo) semu_list; /* list of active undo structures */
+LIST_HEAD(, sem_undo) semu_list; /* list of active undo structures */
+LIST_HEAD(, sem_undo) semu_free_list; /* list of free undo structures */
static int *semu; /* undo structure pool */
static eventhandler_tag semexit_tag;
-#define SEMUNDO_MTXsem_mtx
+#define SEMUNDO_MTXsem_undo_mtx
#define SEMUNDO_LOCK() mtx_lock(&SEMUNDO_MTX);
#define SEMUNDO_UNLOCK() mtx_unlock(&SEMUNDO_MTX);
#define SEMUNDO_LOCKASSERT(how)mtx_assert(&SEMUNDO_MTX, (how));
@@ -122,13 +124,15 @@ struct sem {
* Undo structure (one per process)
*/
struct sem_undo {
- SLIST_ENTRY(sem_undo) un_next; /* ptr to next active undo structure */
+ LIST_ENTRY(sem_undo) un_next; /* ptr to next active undo structure */
struct proc *un_proc; /* owner of this structure */
short un_cnt; /* # of active entries */
struct undo {
short un_adjval; /* adjust on exit values */
short un_num; /* semaphore # */
int un_id; /* semid */
+ un
Re: kernel panic
On 2009-Jan-09 00:05:47 -0800, Kamlesh Patel wrote: >How do i recover the system from this error. I can't reload the loader.old If you press any key during the first spinner, you should get a prompt similar to the following: >> FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: You can then enter the name of the program you wish to run - eg /boot/loader.old (or directly load /boot/kernel/kernel) See the following for a more complete description: http://www.freebsd.org/cgi/man.cgi?query=boot&apropos=0&sektion=0&manpath=FreeBSD+7.1-RELEASE&format=html -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgplWQBOkyzAN.pgp Description: PGP signature
Re: extattr problems?
2009/1/11 Tim Kientzle :
> pluknet wrote:
>>
>> 2009/1/11 Tim Kientzle :
>>
>>> FreeBSD 6.3:
>>>
>>> fd = open("test", O_WRONLY | O_CREAT | O_EXCL, 0777);
>>> n = extattr_set_fd(fd, EXTATTR_NAMESPACE_USER, "testattr", "1234", 4);
>>>
>>> After this, fd=3, n is non-zero, errno = 9 (EBADF)
>>>
>>> Huh? I would have expected EOPNOTSUPP if
>>> extended attributes weren't supported on this
>>> filesystem. The file descriptor is clearly
>>> valid.
>>
>> Simple guess.
>> Don't hit me if I'm wrong. :)
>>
>> You call open() with (O_CREAT | O_EXCL) on an already existing file.
>
> Nope. As you can see from my earlier summary,
> fd=3 immediately after this, so the open did
> succeed normally.
Ah, I'm sorry. My inadvertency.
>
> Oh, but that gives me an idea ...
> ... darn. Still no joy. I tried changing the open to
> open("test", O_RDWR | O_CREATE, 0777) and it still
> fails in exactly the same way. The open still succeeds
> and the extattr_set_fd() still fails with a nonsensical
> errno value.
It's strange..
FreeBSD jaw.ripn.net 6.3-RELEASE-p5.
works for me (tm), extattr_set_fd() returns 4 as expected.
Also works on 7.1 at home.
>
> Time to dig through kernel sources
>
> Tim
>
--
wbr,
pluknet
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
