Re: Port of Niels Provos's file descriptor allocation code
On Wed, Dec 03, 2003 at 11:54:45PM -0800, David Schultz wrote: On Thu, Nov 27, 2003, Tim Robbins wrote: I've ported Niels Provos's file descriptor allocation code to FreeBSD in case anyone wants to try it out run some benchmarks. If the performance boost turns out to be worth the added complexity, I might clean it up a bit and commit it. I've used a similar data structure for a special-purpose allocator before, and it had extremely low allocation time overhead--- basically a few memory references for every level of the tree in the common case. Unless for some strange reason it pessimizes processes with a small number of file descriptors significantly, it would be really great to have this in the tree! It doesn't seem to make a noticeable impact on execution time for processes with small numbers of descriptors. It's probably swamped by the overhead of mode switches, locking, and filesystem operations. What makes uneasy is the amount of extra memory it consumes when processes have a small number of descriptors: (32**2)/8 = 128 bytes (when int is 32 bits), or (64**2)/8 = 512 bytes (when int is 64 bits). I've been thinking of switching to a flat bitmap for small fd tables, possibly just using a single int, or falling back to the old way of scanning fd_ofiles directly. Once I decide what to do about that and find someone to test my latest patch on a 64-bit machine, I'll commit it. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Port of Niels Provos's file descriptor allocation code
On Sat, Nov 29, 2003 at 01:32:01AM +0100, Dag-Erling Sm?rgrav wrote: Tim Robbins [EMAIL PROTECTED] writes: I've ported Niels Provos's file descriptor allocation code to FreeBSD in case anyone wants to try it out run some benchmarks. If the performance boost turns out to be worth the added complexity, I might clean it up a bit and commit it. What exactly would be the point? If this is the OpenBSD fdalloc code, recent widely-publicized benchmarks have shown it to be inferior to ours. Perhaps you should concentrate on improving vm_map_find() and vm_map_findspace() performance instead? It's also the NetBSD fdalloc code. They started with code similar to ours, in that it did a linear search of the file descriptor array to find an empty slot and used hints to speed up some common allocation patterns, then recently switched over to using the multi-level bitmap allocator. I can't think of any reason why we wouldn't see improvements similar to what they saw: http://www.citi.umich.edu/u/provos/benchmark/netbsd-fdalloc.jpg ... but I'm still working on benchmarking FreeBSD with without the new allocator; I just posted the patch so that other people could experiment with it if they were interested. I don't plan on committing it until I have good evidence that it's an improvement over the current code. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Port of Niels Provos's file descriptor allocation code
I've ported Niels Provos's file descriptor allocation code to FreeBSD
in case anyone wants to try it out run some benchmarks. If the performance
boost turns out to be worth the added complexity, I might clean it up a
bit and commit it.
See http://mail-index.netbsd.org/tech-perform/2003/10/28/0001.html and
Banga Mogul's USENIX paper (linked to from the other URL) for the details.
http://perforce.freebsd.org/chv.cgi?CH=43066
--- //depot/user/tjr/freebsd-tjr/src/sys/kern/init_main.c 2003/10/05 17:21:48
+++ //depot/user/tjr/freebsd-tjr/src/sys/kern/init_main.c 2003/11/26 19:42:24
@@ -415,6 +415,8 @@
fdp-fd_fd.fd_ofiles = fdp-fd_dfiles;
fdp-fd_fd.fd_ofileflags = fdp-fd_dfileflags;
fdp-fd_fd.fd_nfiles = NDFILE;
+ fdp-fd_fd.fd_himap = fdp-fd_dhimap;
+ fdp-fd_fd.fd_lomap = fdp-fd_dlomap;
/* Create the limits structures. */
p-p_limit = limit0;
--- //depot/user/tjr/freebsd-tjr/src/sys/kern/kern_descrip.c2003/10/27 00:31:20
+++ //depot/user/tjr/freebsd-tjr/src/sys/kern/kern_descrip.c2003/11/26 19:42:24
@@ -96,6 +96,7 @@
static int do_dup(struct thread *td, enum dup_type type, int old, int new,
register_t *retval);
+static __inline intfind_next_zero(uint32_t *, int, u_int);
/*
* Descriptor management.
@@ -105,6 +106,62 @@
struct sx filelist_lock; /* sx to protect filelist */
struct mtx sigio_lock; /* mtx to protect pointers to sigio */
+static __inline int
+find_next_zero(uint32_t *bitmap, int want, u_int bits)
+{
+ int i, off, maxoff;
+ uint32_t sub;
+
+ if (want bits)
+ return -1;
+
+ off = want NDENTRYSHIFT;
+ i = want NDENTRYMASK;
+ if (i) {
+ sub = bitmap[off] | ((u_int)~0 (NDENTRIES - i));
+ if (sub != ~0)
+ goto found;
+ off++;
+ }
+
+ maxoff = NDLOSLOTS(bits);
+ while (off maxoff) {
+ if ((sub = bitmap[off]) != ~0)
+ goto found;
+ off++;
+ }
+
+ return (-1);
+
+found:
+ return (off NDENTRYSHIFT) + ffs(~sub) - 1;
+}
+
+int
+fd_find_last_set(struct filedesc *fd, int last)
+{
+ int off, i;
+ struct file **ofiles = fd-fd_ofiles;
+ uint32_t *bitmap = fd-fd_lomap;
+
+ off = (last - 1) NDENTRYSHIFT;
+
+ while (!bitmap[off] off = 0)
+ off--;
+
+ if (off 0)
+ return (0);
+
+ i = ((off + 1) NDENTRYSHIFT) - 1;
+ if (i = last)
+ i = last - 1;
+
+ while (i 0 ofiles[i] == NULL)
+ i--;
+
+ return (i);
+}
+
/*
* System calls on descriptors.
*/
@@ -505,13 +562,8 @@
* avoid this case.
*/
if (fdp-fd_ofiles[old] != fp) {
- if (fdp-fd_ofiles[new] == NULL) {
- if (new fdp-fd_freefile)
- fdp-fd_freefile = new;
- while (fdp-fd_lastfile 0
- fdp-fd_ofiles[fdp-fd_lastfile] == NULL)
- fdp-fd_lastfile--;
- }
+ if (fdp-fd_ofiles[new] == NULL)
+ fd_unused(fdp, new);
FILEDESC_UNLOCK(fdp);
fdrop(fp, td);
return (EBADF);
@@ -545,8 +597,7 @@
*/
fdp-fd_ofiles[new] = fp;
fdp-fd_ofileflags[new] = fdp-fd_ofileflags[old] ~ UF_EXCLOSE;
- if (new fdp-fd_lastfile)
- fdp-fd_lastfile = new;
+ fd_used(fdp, new);
FILEDESC_UNLOCK(fdp);
*retval = new;
@@ -836,6 +887,7 @@
#endif
fdp-fd_ofiles[fd] = NULL;
fdp-fd_ofileflags[fd] = 0;
+ fd_unused(fdp, fd);
if (td-td_proc-p_fdtol != NULL) {
/*
* Ask fdfree() to sleep to ensure that all relevant
@@ -849,10 +901,6 @@
* we now hold the fp reference that used to be owned by the descriptor
* array.
*/
- while (fdp-fd_lastfile 0 fdp-fd_ofiles[fdp-fd_lastfile] == NULL)
- fdp-fd_lastfile--;
- if (fd fdp-fd_freefile)
- fdp-fd_freefile = fd;
if (fd fdp-fd_knlistsize) {
FILEDESC_UNLOCK(fdp);
knote_fdclose(td, fd);
@@ -1052,9 +1100,11 @@
struct proc *p = td-td_proc;
struct filedesc *fdp = td-td_proc-p_fd;
int i;
- int lim, last, nfiles;
+ int lim, last, nfiles, oldnfiles;
struct file **newofile, **oldofile;
char *newofileflags;
+ uint32_t *newhimap, *newlomap, *oldhimap, *oldlomap;
+ u_int off, new;
FILEDESC_LOCK_ASSERT(fdp, MA_OWNED);
@@ -1066,12 +1116,28 @@
lim = min((int)p-p_rlimit[RLIMIT_NOFILE].rlim_cur, maxfilesperproc);
for (;;) {
last = min(fdp-fd_nfiles, lim);
+again:
i = max(want, fdp-fd_freefile);
- for (; i last; i++) {
-
Re: recent current panic
On Wed, Nov 26, 2003 at 03:00:35PM +0300, ?? ? ?? wrote: i got a panic on recent -CURRENT: # tcpdump -i lo0 port 23 [1] 507 listening on lo0 This is a known bug; silby@ is working to fix lo and the rest of the affected network drivers. See PR kern/59576. Here's the local patch to if_loop.c I'm using until this gets fixed. I've patched if_tun.c similarly. Index: if_loop.c === RCS file: /home/ncvs/src/sys/net/if_loop.c,v retrieving revision 1.92 diff -u -r1.92 if_loop.c --- if_loop.c 20 Nov 2003 20:07:37 - 1.92 +++ if_loop.c 27 Nov 2003 08:18:33 - @@ -262,6 +262,7 @@ * will only read from the mbuf (i.e., it won't * try to free it or keep a pointer a to it). */ + bzero(m0, sizeof(m0)); m0.m_next = m; m0.m_len = 4; m0.m_data = (char *)af; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
tun + bpf = busted
With INVARIANTS enabled, I get a kernel panic when I run tcpdump on a tun interface. The message is tunoutput: attempted use of a free mbuf!. This occurs because tun creates temporary mbufs on the stack and does not initialize m_flags, so it may or may not have the M_FREELIST bit set depending on what junk is on the stack. This seems to affect a whole bunch of other network drivers too. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: Most recently used by mount
On Sun, Nov 09, 2003 at 01:30:52PM -0800, Kris Kennaway wrote:
On Sun, Nov 09, 2003 at 06:05:06PM +0100, Lukas Ertl wrote:
---
panic: Most recently used by mount
I reported this the other day..tjr has a fix in his p4 branch.
Here's the patch:
(http://perforce.freebsd.org/chv.cgi?CH=41739)
--- kern/vfs_mount.c.oldMon Nov 10 10:30:14 2003
+++ kern/vfs_mount.cSun Nov 9 00:26:03 2003
@@ -700,6 +700,8 @@
mac_destroy_mount(mp);
#endif
crfree(mp-mnt_cred);
+ lockdestroy(mp-mnt_lock);
+ mtx_destroy(mp-mnt_mtx);
free(mp, M_MOUNT);
}
vrele(vp);
@@ -794,6 +796,8 @@
mac_destroy_mount(mp);
#endif
crfree(mp-mnt_cred);
+ lockdestroy(mp-mnt_lock);
+ mtx_destroy(mp-mnt_mtx);
free(mp, M_MOUNT);
vput(vp);
goto bad;
@@ -1066,6 +1070,8 @@
mac_destroy_mount(mp);
#endif
crfree(mp-mnt_cred);
+ lockdestroy(mp-mnt_lock);
+ mtx_destroy(mp-mnt_mtx);
free(mp, M_MOUNT);
}
vrele(vp);
@@ -1147,6 +1153,8 @@
mac_destroy_mount(mp);
#endif
crfree(mp-mnt_cred);
+ lockdestroy(mp-mnt_lock);
+ mtx_destroy(mp-mnt_mtx);
free(mp, M_MOUNT);
vput(vp);
}
@@ -1587,11 +1595,14 @@
free(path, M_MOUNT);
if (error != 0) {
if (mp != NULL) {
+ mp-mnt_vfc-vfc_refcount--;
vfs_unbusy(mp, curthread);
#ifdef MAC
mac_destroy_mount(mp);
#endif
crfree(mp-mnt_cred);
+ lockdestroy(mp-mnt_lock);
+ mtx_destroy(mp-mnt_mtx);
free(mp, M_MOUNT);
}
printf(Root mount failed: %d\n, error);
--- nfsclient/nfs_vfsops.c.old Mon Nov 10 10:31:08 2003
+++ nfsclient/nfs_vfsops.c Sun Nov 9 00:26:03 2003
@@ -510,8 +510,15 @@
printf(nfs_mountroot: mount %s on %s: %d, path, which, error);
mp-mnt_vfc-vfc_refcount--;
vfs_unbusy(mp, td);
- if (didalloc)
+ if (didalloc) {
+#ifdef MAC
+ mac_destroy_mount(mp);
+#endif
+ crfree(mp-mnt_cred);
+ lockdestroy(mp-mnt_lock);
+ mtx_destroy(mp-mnt_mtx);
free(mp, M_MOUNT);
+ }
FREE(nam, M_SONAME);
return (error);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Experimental patch to support large MS-DOS filesystems
If you're feeling adventurous and have access to a relatively large MS-DOS formatted disk that gives a disk too big, sorry error when you try to mount it, please try out this patch and let me know how it goes: http://people.freebsd.org/~tjr/fileno32.diff (http://perforce.freebsd.org/chv.cgi?CH=40907) I don't have access to disks big enough to cause the error message, so don't be surprised if it doesn't work. Although there is very little chance of it causing data loss, it'd be best to try it on a read-only filesystem first, and to make sure that you have backups. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Syncer giving up on buffers
On Tue, Sep 02, 2003 at 05:10:48AM +1000, Bruce Evans wrote: Apparently the bug fixed in ext2fs/fs.h revs 1.3, 1.4 and 1.6 (etc.) was restored in rev.1.14. I think this is because B_LOCKED buffers were ignored in the sync() in boot() and flushed later when vfs_unmountall() calls ext2fs_unmount(), but they are now seen in the sync() so vfs_unmountall() is not called. Rev.1.3 of ext2fs/fs.h (etc.) abuses B_LOCKED to do little more than make the sync() ignore ext2fs's private buffers (its complications are mainly to handle the resulting B_LOCKED buffers). It wants to brelse() the buffers so that their BUF_REFCOUNT() is 0 and the sync() in boot() is happy to handle them. In the original fix, I think the buffers could be B_DELWRI and then the sync() would fulush them, but setting B_DELWRI was wrong and was changed (in rev.1.4) to setting the private flag B_DIRTY instead. Rev.1.13 esssentially removes the brelse() and adds a new complication (BUF_KERNPROC()) and keeps the old ones. I think the BUF_KERNPROC() is less than useful -- without the brelse()'s, the buffers are completely private to the file system. Is there any particular reason why ext2fs keeps these buffers locked instead of reading/writing them in when it needs to, or storing them in malloc'd memory and reading/writing them at mount/unmount time? Do we need to ensure that group descriptors inode/block bitmaps are not written to disk until the filesystem gets unmounted, or is it merely to improve performance and simplify the code? Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: su in free(): warning: chunk is already free
On Sat, Aug 30, 2003 at 06:38:02PM +0200, Christoph Kukulies wrote: On my 5.1-current I logged in from outside and tried su getting: $ su su in free(): warning: chunk is already free su: pam_start: system error I'm not sure whether my system is absolutely in sync but I'd think with make buildworld, installworld, buildkernel, installkernel reboot it should be. Are you using the defaults for /etc/pam.d/* or have they changed? Are you using YP or Kerberos? Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: bundirty: buffer 0xc776e118 still on queue 2
On Thu, Aug 21, 2003 at 08:14:45AM +0200, Christian Brueffer wrote: On Thu, Aug 21, 2003 at 01:40:54PM +1000, Tim Robbins wrote: On Thu, Aug 21, 2003 at 12:26:07AM +0200, Christian Brueffer wrote: Hi, just got a panic on following 5.1-CURRENT machine: FreeBSD gondor.middleearth 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Thu Aug 7 21:32:39 CEST 2003 [EMAIL PROTECTED] konia.hitnet.rwth-aachen.de:/usr/obj/usr/src/sys/GONDOR i386 A dump is available if anyone needs specific information. [...] panic: bundirty: buffer 0xc776e118 still on queue 2^M [...] #2 0xc0254007 in panic (fmt=0xc03cc0ef bundirty: buffer %p still on queue %d)^M at /usr/src/sys/kern/kern_shutdown.c:550^M #3 0xc029b291 in bundirty (bp=0xc776e118) at /usr/src/sys/kern/vfs_bio.c:1121^M #4 0xc029bde1 in brelse (bp=0xc776e118) at /usr/src/sys/kern/vfs_bio.c:1436^M #5 0xc02efcb8 in nfs_writebp (bp=0xc776e118, force=1, td=0xc2c17e40)^M at /usr/src/sys/nfsclient/nfs_vnops.c:2987^M #6 0xc02e02c3 in nfs_bwrite (bp=0x0) at /usr/src/sys/nfsclient/nfs_bio.c:76^M #7 0xc029dd41 in getblk (vp=0xc2c77b68, blkno=400, size=15360, slpflag=256, slptimeo=0, flags=0)^M at /usr/src/sys/kern/vfs_bio.c:2512^M #8 0xc02e21e5 in nfs_getcacheblk (vp=0xc2c77b68, bn=400, size=15360, td=0xc2c17e40)^M at /usr/src/sys/nfsclient/nfs_bio.c:1037^M I think I recognise this backtrace. Did you have a read-only NFS mount active at the time of the crash? In any case, a copy of your NFS entries from /etc/fstab (with any private data removed) would be helpful in tracking this problem down. No, all mounts were read-write. Did one of the servers go down shortly before the panic, then? The last few lines of dmesg might be useful. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: bundirty: buffer 0xc776e118 still on queue 2
On Thu, Aug 21, 2003 at 10:26:08AM +0200, Christian Brueffer wrote: On Thu, Aug 21, 2003 at 05:57:28PM +1000, Tim Robbins wrote: Did one of the servers go down shortly before the panic, then? The last few lines of dmesg might be useful. No indication for that in the logs. I would have noticed anyway, as I was playing music from one of the shares. One of the shared file systems was full (besides the reserved space) at the time of the panic. Could that have to do something with it? Perhaps. On closer examination, the backtrace doesn't match exactly the problem I'd seen and worked around in NTFS, but it seems to be related to it. Bad things happen when the cache can't write a dirty buffer back to disk -- in the NTFS case, this was triggered by another buffer cache bug that caused it to try to write a non-dirty buffer back to a read-only disk[*]. I would have thought that disk space on the server would have already been allocated for the buffer, so I'm not sure whether the filesystem being full could have caused a write error. But in any case, I'm not sure how to fix the bug you encountered, even if my speculations turn out to be correct. At one stage I thought I had found a logic error in brelse()'s handling of write errors, but I don't remember the specifics anymore. Tim [*] vfs_bio.c:getblk():gbincore(...) != NULL bp-b_bcount != size !(bp-b_flags B_VMIO) !(bp-b_flags B_DELWRI) - write non-dirty buffer to disk. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: bundirty: buffer 0xc776e118 still on queue 2
On Thu, Aug 21, 2003 at 12:26:07AM +0200, Christian Brueffer wrote: Hi, just got a panic on following 5.1-CURRENT machine: FreeBSD gondor.middleearth 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Thu Aug 7 21:32:39 CEST 2003 [EMAIL PROTECTED] konia.hitnet.rwth-aachen.de:/usr/obj/usr/src/sys/GONDOR i386 A dump is available if anyone needs specific information. [...] panic: bundirty: buffer 0xc776e118 still on queue 2^M [...] #2 0xc0254007 in panic (fmt=0xc03cc0ef bundirty: buffer %p still on queue %d)^M at /usr/src/sys/kern/kern_shutdown.c:550^M #3 0xc029b291 in bundirty (bp=0xc776e118) at /usr/src/sys/kern/vfs_bio.c:1121^M #4 0xc029bde1 in brelse (bp=0xc776e118) at /usr/src/sys/kern/vfs_bio.c:1436^M #5 0xc02efcb8 in nfs_writebp (bp=0xc776e118, force=1, td=0xc2c17e40)^M at /usr/src/sys/nfsclient/nfs_vnops.c:2987^M #6 0xc02e02c3 in nfs_bwrite (bp=0x0) at /usr/src/sys/nfsclient/nfs_bio.c:76^M #7 0xc029dd41 in getblk (vp=0xc2c77b68, blkno=400, size=15360, slpflag=256, slptimeo=0, flags=0)^M at /usr/src/sys/kern/vfs_bio.c:2512^M #8 0xc02e21e5 in nfs_getcacheblk (vp=0xc2c77b68, bn=400, size=15360, td=0xc2c17e40)^M at /usr/src/sys/nfsclient/nfs_bio.c:1037^M I think I recognise this backtrace. Did you have a read-only NFS mount active at the time of the crash? In any case, a copy of your NFS entries from /etc/fstab (with any private data removed) would be helpful in tracking this problem down. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MSDOSFS woes
On Sat, Aug 02, 2003 at 06:08:50PM +0300, Ruslan Ermilov wrote: Gang, :-) While working with Marcel on a bootable CD-ROM for IA64 issue, I've stumbled upon the following problem. I needed to increase the size of the EFI partition (which is an MS-DOS file system) to 64M, and that made two of my machines stuck solidly -- a lot of process are waiting on the wdrain event. Interesting. Were you running with INVARIANTS on? I got a completely reproducible kernel panic when running your script, regardless of whether I used -F 12 or -F 16; it was trying to write file data past the end of the disk, and causing kernel memory pool to become corrupted. I was seeing Memory modified after free errors, with blocks most recently used by GEOM and file desc. Were you running the script with INVARIANTS on? Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Memory modified after free / most recently used by GEOM
While trying to reproduce the wdrain problems ru@ reported in the MSDOSFS
woes thread, I kept running into this panic. I've also seen a similar one
but didn't keep the vmcore for it where a LOR is detected between Giant and
filedesc, then a page fault occurs. The backtrace for that one shows that the
fault occurred in the file desc code, and traces down to an ioctl() syscall
issued by the shell (ksh).
Kernel is trimmed down -current as of ~13:30 GMT on Aug 5 w/ obsolete drivers
(pcvt, gsc, etc.) deleted, but with no other significant changes.
Memory modified after free 0xc13f7600(252)
panic: Most recently used by GEOM
panic: from debugger
Uptime: 5m33s
Dumping 64 MB
ata0: resetting devices ..
done
16 32 48
---
#0 doadump () at /home/tim/p4/freebsd/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /home/tim/p4/freebsd/sys/kern/kern_shutdown.c:240
#1 0xc01a19ac in boot (howto=260) at
/home/tim/p4/freebsd/sys/kern/kern_shutdown.c:372
#2 0xc01a1d37 in panic () at
/home/tim/p4/freebsd/sys/kern/kern_shutdown.c:550
#3 0xc0127042 in db_panic () at /home/tim/p4/freebsd/sys/ddb/db_command.c:450
#4 0xc0126fa2 in db_command (last_cmdp=0xc031f780, cmd_table=0x0,
aux_cmd_tablep=0xc02fadc0, aux_cmd_tablep_end=0xc02fadc4)
at /home/tim/p4/freebsd/sys/ddb/db_command.c:346
#5 0xc01270e5 in db_command_loop () at
/home/tim/p4/freebsd/sys/ddb/db_command.c:472
#6 0xc012a0e5 in db_trap (type=3, code=0) at
/home/tim/p4/freebsd/sys/ddb/db_trap.c:73
#7 0xc02b23ec in kdb_trap (type=3, code=0, regs=0xc5f69b68) at
/home/tim/p4/freebsd/sys/i386/i386/db_interface.c:172
#8 0xc02c2eda in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 1, tf_esi = -1070640529,
tf_ebp = -973694028, tf_isp = -973694060, tf_ebx = 0, tf_edx = 0, tf_ecx = 32,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1070913874, tf_cs = 8,
tf_eflags = 646, tf_esp = -1070632808, tf_ss = -1070709550}) at
/home/tim/p4/freebsd/sys/i386/i386/trap.c:580
#9 0xc02b3de8 in calltrap () at {standard input}:102
#10 0xc01a1cc5 in panic (fmt=0xc02f526f Most recently used by %s\n) at
/home/tim/p4/freebsd/sys/kern/kern_shutdown.c:534
#11 0xc0292c5d in mtrash_ctor (mem=0xc13f7600, size=0, arg=0x0) at
/home/tim/p4/freebsd/sys/vm/uma_dbg.c:137
#12 0xc0291434 in uma_zalloc_arg (zone=0xc083ab60, udata=0x0, flags=2) at
/home/tim/p4/freebsd/sys/vm/uma_core.c:1385
#13 0xc0196463 in malloc (size=3229854560, type=0xc0305560, flags=2) at
/home/tim/p4/freebsd/sys/vm/uma.h:229
#14 0xc0184cea in fdcopy (fdp=0xc1218200) at
/home/tim/p4/freebsd/sys/kern/kern_descrip.c:1309
#15 0xc018de0e in fork1 (td=0xc0a0d390, flags=20, pages=0, procp=0xc5f69cd8)
at /home/tim/p4/freebsd/sys/kern/kern_fork.c:424
#16 0xc018d61b in fork (td=0xc0a0d390, uap=0xc5f69d10) at
/home/tim/p4/freebsd/sys/kern/kern_fork.c:102
#17 0xc02c37c3 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 135299072,
tf_ebp = -1077937224, tf_isp = -973693580, tf_ebx = 0, tf_edx = 135295016,
tf_ecx = -1, tf_eax = 2, tf_trapno = 12, tf_err = 2, tf_eip = 134725423, tf_cs
= 31, tf_eflags = 582, tf_esp = -1077937268, tf_ss = 47}) at
/home/tim/p4/freebsd/sys/i386/i386/trap.c:1008
#18 0xc02b3e3d in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Serious 'tr' bug, patch for review included
On Fri, Aug 01, 2003 at 06:12:13AM +0400, Andrey Chernov wrote: On Fri, Aug 01, 2003 at 12:02:04 +1000, Tim Robbins wrote: 8 bits by casting to char. Using charcoll() to sort char arrays may work on little endian machines, but may not on big endian machines. s-set is array of ints, not array of chars. In any case thanx for looking. Sorry, I must be going blind. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Serious 'tr' bug, patch for review included
On Fri, Aug 01, 2003 at 04:44:08AM +0400, Andrey Chernov wrote:
@@ -208,10 +210,18 @@
if ((func)(cnt))
*p++ = cnt;
*p = OOBCH;
+ n = p - cp-set;
s-cnt = 0;
- s-state = SET;
s-set = cp-set;
+ if (strcmp(s-str, upper) == 0)
+ s-state = SET_UPPER;
+ else if (strcmp(s-str, lower) == 0) {
+ s-state = SET_LOWER;
+ } else
+ s-state = SET;
+ if ((s-state == SET_LOWER || s-state == SET_UPPER) n 1)
+ mergesort(s-set, n, sizeof(*(s-set)), charcoll);
}
static int
I haven't tested the patch yet, but I don't think it's safe to use
charcoll() to sort set, which is a char array; charcoll() casts its
arguments to int *, dereferences them, then discards all but the low
8 bits by casting to char. Using charcoll() to sort char arrays may
work on little endian machines, but may not on big endian machines.
Also, watch out for this warning in qsort(3):
The qsort() and heapsort() functions sort an array of nmemb objects, the
initial member of which is pointed to by base. The size of each object
is specified by size. Mergesort() behaves similarly, but requires that
size be greater than ``sizeof(void *) / 2''.
^^^
Tim
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic while reading ntfs partition
On Thu, Jul 24, 2003 at 02:14:20PM +0200, Karel J. Bosschaart wrote:
Not sure if this is useful, but I'm getting a perfectly reproducible
panic when doing 'grep -R foo .' (as normal user) in a read-only
mounted ntfs partition on a -current as of ~3 weeks ago:
[...]
Panicstring: bundirty: buffer 0xc72d9868 still on queue 2
[...]
Thanks for the report - I thought I'd already fixed this problem. Would you
mind trying the attached patch? It seems to fix the problem for me, but
grep uses an awful lot of memory in the process (perhaps it's trying to
read a line from the pagefile containing mostly zeroes.)
See these two for more info on the bug:
http://perforce.freebsd.org/chv.cgi?CH=34967
http://perforce.freebsd.org/chv.cgi?CH=33434
diff -ru sys/fs/ntfs.old/ntfs_subr.c sys/fs/ntfs/ntfs_subr.c
--- sys/fs/ntfs.old/ntfs_subr.c Fri Jul 25 12:26:18 2003
+++ sys/fs/ntfs/ntfs_subr.c Fri Jul 25 12:18:09 2003
@@ -1442,9 +1442,16 @@
off = ntfs_btocnoff(off);
while (left ccl) {
- tocopy = min(left,
- min(ntfs_cntob(ccl) - off, MAXBSIZE - off));
+ /*
+* Always read and write single clusters at a time -
+* we need to avoid requesting differently-sized
+* blocks at the same disk offsets to avoid
+* confusing the buffer cache.
+*/
+ tocopy = min(left, ntfs_cntob(1) - off);
cl = ntfs_btocl(tocopy + off);
+ KASSERT(cl == 1 tocopy = ntfs_cntob(1),
+ (single cluster limit mistake));
ddprintf((ntfs_writentvattr_plain: write: \
cn: 0x%x cl: %d, off: %d len: %d, left: %d\n,
(u_int32_t) cn, (u_int32_t) cl,
@@ -1540,23 +1547,19 @@
off = ntfs_btocnoff(off);
while (left ccl) {
- tocopy = min(left,
- min(ntfs_cntob(ccl) - off,
- MAXBSIZE - off));
- cl = ntfs_btocl(tocopy + off);
-
/*
-* If 'off' pushes us to next
-* block, don't attempt to read whole
-* 'tocopy' at once. This is to avoid
-* bread() with varying 'size' for
-* same 'blkno', which is not good.
+* Always read single clusters at a
+* time - we need to avoid reading
+* differently-sized blocks at the
+* same disk offsets to avoid
+* confusing the buffer cache.
*/
- if (cl ntfs_btocl(tocopy)) {
- tocopy -=
- ntfs_btocnoff(tocopy + off);
- cl--;
- }
+ tocopy = min(left,
+ ntfs_cntob(1) - off);
+ cl = ntfs_btocl(tocopy + off);
+ KASSERT(cl == 1
+ tocopy = ntfs_cntob(1),
+ (single cluster limit mistake));
ddprintf((ntfs_readntvattr_plain: \
read: cn: 0x%x cl: %d, \
diff -ru sys/fs/ntfs.old/ntfs_vfsops.c sys/fs/ntfs/ntfs_vfsops.c
--- sys/fs/ntfs.old/ntfs_vfsops.c Fri Jul 25 12:26:18 2003
+++ sys/fs/ntfs/ntfs_vfsops.c Fri Jul 25 12:18:09 2003
@@ -311,6 +311,14 @@
goto out;
ntmp = malloc( sizeof *ntmp, M_NTFSMNT, M_WAITOK | M_ZERO);
bcopy( bp-b_data, ntmp-ntm_bootfile, sizeof(struct bootfile) );
+ /*
+* We must not cache the boot block if its size is not exactly
+* one cluster in order to avoid confusing the buffer cache when
+* the boot file is read later by ntfs_readntvattr_plain(), which
+* reads a cluster at a time.
+*/
+ if (ntfs_cntob(1) != BBSIZE)
+ bp-b_flags |= B_NOCACHE;
brelse( bp );
bp = NULL;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL
Re: 5.2-RELEASE TODO
On Sun, Jun 29, 2003 at 10:00:15AM -0400, Robert Watson wrote: |+---++---| | || || Kris Kennaway | | || || reports | | || || deadlocks | | || || involving the | | || || use of nullfs | | || || in the bento | | || || environment: | | || || buildworld| | || || -j4 with src | | || || and obj | | || || mounted via | | || || nullfs; the | | | nullfs | --| -- | gcc processes | | | deadlocks | || eventually| | || || deadlocked in | | || || the ufs | | || || state. DDB| | || || traceback | | || || showed two| | || || different | | || || codepaths.| | || || I've just | | || || repeated | | || || this, so the | | || || bug still | | || || exists. | | |+---++---| | This has already been fixed. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mount_ntfs causes panic
On Fri, Jun 20, 2003 at 11:41:57PM +0900, NAKAJI Hiroyuki wrote: In [EMAIL PROTECTED] Tim Robbins [EMAIL PROTECTED] wrote: /etc/fstab: /dev/ad0s2 /mnt/winnt ntfsro,noauto 0 0 When mount /mnt/winnt, the system falls into DDB. This looks like a bug in the buffer cache code. I'm working on trying to fix it. Mounting read-write instead of read-only ought to work around the problem, but it's probably not very safe. Thanks for support. I updated the kernel on another PC from yesterday's source (cvsup-ed about Jun 19 14:00 JST) and, what a miracle, mount_ntfs did not get system panic. I'll try the latest kernel on the PC on which I found this problem. I've committed a fix for this bug to CVS. Thanks for reporting it! Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mount_ntfs causes panic
On Tue, Jun 17, 2003 at 09:16:51PM +0900, NAKAJI Hiroyuki wrote: I updated my laptop kernel to 5.1-CURRENT and got into trouble. FreeBSD mebius 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Tue Jun 17 09:36:21 JST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 This laptop also runs Windows 2000 whose filesystem is NTFS and this NTFS part is mounted from FreeBSD with read-only. /etc/fstab: /dev/ad0s2 /mnt/winnt ntfsro,noauto 0 0 When mount /mnt/winnt, the system falls into DDB. This looks like a bug in the buffer cache code. I'm working on trying to fix it. Mounting read-write instead of read-only ought to work around the problem, but it's probably not very safe. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On Sun, Jun 15, 2003 at 08:43:15PM -0400, Chris Shenton wrote: I've been running qmail for years and like it, installed pretty much per www.LifeWithQmail.org. My main system was running FreeBSD 5.0-RELEASE and -CURRENT and qmail was fine. When I just upgraded to 5.1-CURRENT a couple days back, the qmail-send process started using all CPU. This looks like a bug in the named pipe code. Reverting sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go away. I haven't tracked down exactly what change between RELENG_5_0 and RELENG_5_1 caused the problem. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On Mon, Jun 16, 2003 at 04:09:51PM +1000, Tim Robbins wrote: On Sun, Jun 15, 2003 at 08:43:15PM -0400, Chris Shenton wrote: I've been running qmail for years and like it, installed pretty much per www.LifeWithQmail.org. My main system was running FreeBSD 5.0-RELEASE and -CURRENT and qmail was fine. When I just upgraded to 5.1-CURRENT a couple days back, the qmail-send process started using all CPU. This looks like a bug in the named pipe code. Reverting sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go away. I haven't tracked down exactly what change between RELENG_5_0 and RELENG_5_1 caused the problem. Looks like revision 1.86 works, but it stops working with 1.87. Moving the soclose() calls to fifo_inactive() may have caused it. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Apparent i386 alloca.S bug (was: adsl/pppoe no longer connecting on5.1)
Here's a test program for the i386 alloca() bug. Compile with -std=gnu89 (or
no -std option) and it works fine. Compile with -std=c99 or -std=c89 and it
breaks like this:
corruption: 05 should be 0xcc at offset 0
corruption: 00 should be 0xcc at offset 1
corruption: 00 should be 0xcc at offset 2
corruption: 00 should be 0xcc at offset 3
Interestingly, gcc -std=c89 on FreeBSD 4.8 doesn't trigger the bug.
#include assert.h
#include stdio.h
#include stdlib.h
#include string.h
#define NUMBYTES511
static void
somefunc(int a, int b, int c, int d, int e)
{
}
int
main(int argc, char *argv[])
{
char *s;
int i;
int failed;
s = alloca(NUMBYTES);
memset(s, 0xcc, NUMBYTES);
somefunc(1, 2, 3, 4, 5);
failed = 0;
for (i = 0; i NUMBYTES; i++) {
if ((unsigned char)s[i] != 0xcc) {
printf(corruption: %02x should be 0xcc at offset %d\n,
(unsigned char)s[i], i);
failed = 1;
}
}
exit(failed);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Apparent i386 alloca.S bug (was: adsl/pppoe no longerconnecting on 5.1)
On Thu, Jun 12, 2003 at 06:29:44PM +1000, Tim Robbins wrote: Here's a test program for the i386 alloca() bug. Compile with -std=gnu89 (or no -std option) and it works fine. Compile with -std=c99 or -std=c89 and it breaks like this: corruption: 05 should be 0xcc at offset 0 corruption: 00 should be 0xcc at offset 1 corruption: 00 should be 0xcc at offset 2 corruption: 00 should be 0xcc at offset 3 Interestingly, gcc -std=c89 on FreeBSD 4.8 doesn't trigger the bug. I should mention that you need to compile with -march=pentiumpro to trigger the bug. It's related to the way gcc 3 uses movl x,y(%esp) instead of pushl x when passing arguments to a function. I suggest backing out the commit that made CSTD=c99 the default, so that we go back to using gcc's builtin alloca() until we figure out how to fix the one in libc. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CSTD=c99 breaks package creation
On Wed, Jun 11, 2003 at 07:37:01PM -0700, Kris Kennaway wrote:
It's possible that there's either a bug in gcc or there is C code in
the system that has a different meaning when interpreted to C99
standards.
I think I may have found the problem, and I think it's in GNU tar.
GNU tar does this:
#ifndef __attribute__
/* This feature is available in gcc versions 2.5 and later. */
# if __GNUC__ 2 || (__GNUC__ == 2 __GNUC_MINOR__ 5) || __STRICT_ANSI__
# define __attribute__(Spec) /* empty */
# endif
#endif
machine/_types.h does this:
typedef int __attribute__((__mode__(__DI__))) __int64_t;
typedef unsigned int __attribute__((__mode__(__DI__))) __uint64_t;
If __attribute__ is empty, __int64_t becomes a synonym for int. Bad.
Attached is a test program. Compile it w/o a -std option and see that the
output, which is sizeof(int64_t), is 8 as expected. Compile with -std=c99 and
see that sizeof(int64_t) is 4.
Tim
#ifndef __attribute__
/* This feature is available in gcc versions 2.5 and later. */
# if __GNUC__ 2 || (__GNUC__ == 2 __GNUC_MINOR__ 5) || __STRICT_ANSI__
# define __attribute__(Spec) /* empty */
# endif
#endif
#include sys/types.h
#include stdio.h
#include stdint.h
#include stdlib.h
int
main(int argc, char *argv[])
{
(void)__bswap64((uint64_t)3);
printf(%d\n, (int)sizeof(uint64_t));
exit(0);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
On Thu, Jun 12, 2003 at 07:18:12AM +0200, Wiktor Niesiobedzki wrote: On Wed, Jun 11, 2003 at 09:50:22PM -0700, Kris Kennaway wrote: On Wed, Jun 11, 2003 at 10:48:32PM -0600, Andrew Lankford wrote: Can you try backing out bsd.sys.mk to r1.26 and rebuild your world and kernel? Later versions of this file are causing strange problems with package builds. I was a little lazy and just backed out bsd.sys.mk to 1.26 as you suggested, rebuilt /usr/lib/ , /usr/include/, and ppp. My kernel is the same as last time. As a result, ppp's now up and running again. Thanks, that's actually more useful because it isolates the problem. It's probably something in ppp that is misbehaving with CSTD=c99. alloca(3) function is misbehaving in ppp (namely ether.c). Is this a compiler bug? Misbehaving in what way? CSTD=c99 causes gcc to use alloca() from libc instead of its builtin version. Perhaps alloca() in libc is broken -- any bugs in it would have been covered up by gcc until now. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mdconfig on an iso file mounted on smbfs
On Mon, Jun 09, 2003 at 10:34:10AM -0400, Donn Miller wrote: Thanks, that worked. But I'm seeing the same thing as you. i.e., panic if I reboot without running mdconfig -d first. Here is the backtrace of the ensuing panic: http://users.zoominternet.net/~dmmiller/freebsd/panic-2 Here's a patch that should fix the panic. Let me know whether it does, and also whether it causes any new problems (I'm not very confident in the patch's correctness). --- sys/fs/smbfs/smbfs_subr.c.orig Tue Jun 10 21:09:50 2003 +++ sys/fs/smbfs/smbfs_subr.c Tue Jun 10 21:06:23 2003 @@ -270,6 +270,8 @@ return ENAMETOOLONG; } *npp++ = np; + if ((np-n_flag NREFPARENT) == 0) + break; np = VTOSMB(np-n_parent); } /* if (i == 0) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mdconfig on an iso file mounted on smbfs
On Mon, Jun 09, 2003 at 03:13:24AM -0400, Donn Miller wrote:
Please see the attached gdb file. I get this panic if I have a samba
filesystem mounted via mount_smbfs, where an iso file resides. When I
try to use mdconfig on the file, I get an immediate panic. The exact
mdconfig command issued is:
mount -a -t vnode -f /smbfs/sol-9-u3-x86-v1.iso -u 0
Try this patch and let me know whether it works. It seems to fix the problem
for me, but it still panics if I try to reboot the machine without running
mdconfig -d first.
--- sys/netsmb/smb_iod.c.orig Mon Jun 9 20:36:56 2003
+++ sys/netsmb/smb_iod.cMon Jun 9 20:36:27 2003
@@ -400,7 +400,8 @@
int error;
SMBIODEBUG(\n);
- if (rqp-sr_cred-scr_td-td_proc == iod-iod_p) {
+ if (rqp-sr_cred-scr_td != NULL
+ rqp-sr_cred-scr_td-td_proc == iod-iod_p) {
rqp-sr_flags |= SMBR_INTERNAL;
SMB_IOD_RQLOCK(iod);
TAILQ_INSERT_HEAD(iod-iod_rqlist, rqp, sr_link);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
On Sun, Jun 01, 2003 at 02:51:07PM +0300, Petri Helenius wrote: Is there anyone actually successfully using raidframe and if yes, what kind of hardware? RAIDframe is non-functional in 5.1 and -current [kern/50541] and it would be unwise to use it in 5.0 for anything other than experimentation. Hopefully it will be fixed before 5.2. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-RELEASE TODO
On Thu, May 29, 2003 at 10:00:13AM -0400, Robert Watson wrote: |-+--+-+-| | | | | Almost all process | | | | | debugging tools | | | | | have been updated | | | | | to use non-procfs | | | | | kernel primitives, | | | | | with the exception | | | | | of truss(1). As | | | | | procfs is | | | | | considered | | | | | deprecated due to | | truss support for | In | | its inherent| | ptrace | progress | Robert Drehmel | security risks, it | | | | | is highly desirable | | | | | to update truss to | | | | | operate in a| | | | | post-procfs world. | | | | | Dag-Erling Smorgrav | | | | | had prototype | | | | | patches;| | | | | Robert Drehmel is | | | | | developing and | | | | | testing patches | | | | | now.| |-+--+-+-| gcore also uses procfs. Converting it to use something else (libkvm or perhaps ptrace) won't be straightforward. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel/bsdlabel and md(4) devices
On Wed, May 28, 2003 at 09:54:37PM +1000, Tim Robbins wrote: [...] # disklabel -r -w md0 auto disklabel: Geom not specified Hmm. Ignore this, rebuilding bsdlabel seems to fix the problem. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
disklabel/bsdlabel and md(4) devices
This used to work but does not work any more: # mdconfig -a -t swap -s 16m md0 # disklabel -r -w md0 auto disklabel: Geom not specified # disklabel -w md0 auto disklabel: Geom not specified # disklabel md0 disklabel: Geom not specified # /dev/md0: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 40960unused0 0 # raw part, don't edit How do I write a standard label to a md(4) device with bsdlabel? Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic in wait4()
On Tue, Mar 25, 2003 at 02:22:04PM -0800, Kris Kennaway wrote:
I just got this on bento (running a kernel from Mar 17). It was under
heavy disk load at the time, which may or may not be relevant.
[...]
#12 0xc01b86b5 in panic (fmt=0xe35e9bbc Y\2179) at ../../../kern/kern_shutdown.c:509
#13 0xc01aeae3 in _mtx_lock_flags (m=0x0, opts=0,
file=0xc03375e7 ../../../kern/kern_resource.c, line=989) at
../../../kern/kern_mutex.c:333
#14 0xc01b75bb in chgproccnt (uip=0x3dd, diff=-1070369305, max=0)
at ../../../kern/kern_resource.c:989
#15 0xc01a2e48 in wait1 (td=0xc7b122d0, uap=0x0, compat=0) at
../../../kern/kern_exit.c:694
#16 0xc01a2970 in wait4 (td=0x0, uap=0x0) at ../../../kern/kern_exit.c:552
#17 0xc0306bfe in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = -1078001617, tf_edi = 134714784, tf_esi =
-1077939108, tf_ebp = -1077939144, tf_isp = -480338572, tf_ebx = 674575164, tf_edx =
0, tf_ecx = 19, tf_eax = 7, tf_trapno = 12, tf_err = 2, tf_eip = 674109043, tf_cs =
31, tf_eflags = 534, tf_esp = -1077939172, tf_ss = 47}) at
../../../i386/i386/trap.c:1030
#18 0xc02ef01d in Xint0x80_syscall () at {standard input}:139
---Can't read userspace from dump, or kernel process---
Would you mind doing these commands from kgdb?
frame 15
print p-p_ucred
print *p-p_ucred
print p-p_ucred-cr_ruidinfo
print *p-p_ucred-cr_ruidinfo
Thanks,
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Port breakage (isnan undeclared)
On Thu, Mar 20, 2003 at 12:55:22AM -0800, Kris Kennaway wrote: Several ports have become broken recently with the following error: ../../../include/osg/Math:149: `isnan' undeclared (first use this function) http://bento.freebsd.org/errorlogs/i386-5-latest/osg-0.9.3.log http://bento.freebsd.org/errorlogs/i386-5-latest/gnucap-0.31.log http://bento.freebsd.org/errorlogs/i386-5-latest/fractorama-1.6.4.log Can someone please investigate? The prototypes for isnan() c. need to be put back into math.h, and their source files need to be un-deprecated. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: crash: lockmgr: locking against myself
On Sat, Mar 15, 2003 at 08:27:27PM +0900, FUJITA Kazutoshi wrote: Hi, My -CURRENT(2003/03/14) box crashes when I tried to mount UDF(DVD-RAM). # mount -t udf -o ro /dev/acd0 /dvdram [...] panic: lockmgr: locking against myself [...] (kgdb) bt [...] #10 0xc039bcbb in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:528 #11 0xc038e141 in lockmgr (lkp=0xc4bce1e0, flags=16973826, interlkp=0x100, td=0xc4a023c0) at ../../../kern/kern_lock.c:447 #12 0xc03e93dc in vop_stdlock (ap=0x0) at ../../../kern/vfs_default.c:304 #13 0xc03e9228 in vop_defaultop (ap=0x0) at ../../../kern/vfs_default.c:163 #14 0xc03ffbde in vn_lock (vp=0xc4bce124, flags=131074, td=0xc4a023c0) at vnode_if.h:990 #15 0xc034e45c in udf_hashins (node=0xc4bd1000) at ../../../fs/udf/udf_vnops.c:133 #16 0xc034dea4 in udf_vget (mp=0xc4ae6c00, ino=139, flags=0, vpp=0xdd0c7af4) at ../../../fs/udf/udf_vfsops.c:617 #17 0xc034db7e in udf_root (mp=0xc4b44000, vpp=0x8b) at ../../../fs/udf/udf_vfsops.c:505 It seems that udf_vget() calls udf_allocv(), which returns a locked vnode. udf_vget() then calls udf_hashins(), which tries to lock the vnode again, causing the locking against myself panic. Here's a simple untested patch to try which makes udf_allocv() return an unlocked vnode. I'm not sure whether the locking in udf_hashins() is right. Index: sys/fs/udf/udf_vnops.c === RCS file: /home/ncvs/src/sys/fs/udf/udf_vnops.c,v retrieving revision 1.24 diff -u -r1.24 udf_vnops.c --- sys/fs/udf/udf_vnops.c 3 Mar 2003 19:15:39 - 1.24 +++ sys/fs/udf/udf_vnops.c 15 Mar 2003 12:12:13 - @@ -127,10 +127,10 @@ udfmp = node-udfmp; + vn_lock(node-i_vnode, LK_EXCLUSIVE | LK_RETRY, curthread); mtx_lock(udfmp-hash_mtx); TAILQ_INSERT_TAIL(udfmp-udf_tqh, node, tq); mtx_unlock(udfmp-hash_mtx); - vn_lock(node-i_vnode, LK_EXCLUSIVE | LK_RETRY, curthread); return (0); } @@ -161,7 +161,6 @@ return (error); } - vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td); *vpp = vp; return (0); } Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDF: bad file descriptor
On Sun, Mar 16, 2003 at 06:06:50AM +0900, FUJITA Kazutoshi wrote:
I could mount DVD-RAM successfully.
(This media was formatted by TOSHIBA HDDDVD video recorder;-p)
But, some files can't be read.
How can I solve this?
[...]
# /bin/ls -l
ls: VR_MOVIE.VRO: Bad file descriptor
total 111
drw-rw-rw- 1 root wheel 2048 Mar 12 13:33 .
drw-rw-rw- 4 root wheel 2048 Mar 16 18:00 ..
-rw-rw-rw- 1 root wheel 56980 Mar 16 18:01 VR_MANGR.BUP
-rw-rw-rw- 1 root wheel 56980 Mar 16 18:01 VR_MANGR.IFO
The most likely explanation I can think of for this problem is that
VR_MOVIE.VRO is a real-time file:
6.11 Real-Time Files
A Real-Time file is a file that requires a minimum data-transfer rate when
writing or reading, for example, audio and video data. For these files
special read and write commands are needed. For example for CD and DVD
devices these special commands can be found in the Mount Fuji 4 specification.
A Real-Time file shall be identified by file type 249 in the File Type field
of the file's ICB Tag.
(from OSTA UDF spec, revision 2.01, March 15, 2000)
If the file is a real-time file, then the bad file descriptor errors
are occuring because FreeBSD's UDF filesystem doesn't supports this
type of file. Here's a patch that mimics the logic the Linux UDF code
uses to decide which UDF file types map to the UNIX regular file type:
Index: sys/fs/udf/udf_vfsops.c
===
RCS file: /home/ncvs/src/sys/fs/udf/udf_vfsops.c,v
retrieving revision 1.10
diff -u -r1.10 udf_vfsops.c
--- sys/fs/udf/udf_vfsops.c 11 Mar 2003 22:15:09 - 1.10
+++ sys/fs/udf/udf_vfsops.c 16 Mar 2003 03:01:28 -
@@ -618,12 +618,16 @@
switch (unode-fentry-icbtag.file_type) {
default:
+ printf(unrecognised file type %d\n,
+ (int)unode-fentry-icbtag.file_type);
vp-v_type = VBAD;
break;
case 4:
vp-v_type = VDIR;
break;
+ case 0:
case 5:
+ case 249:
vp-v_type = VREG;
break;
case 6:
The Linux driver doesn't seem to issue the special read and write commands
that the quote from the UDF spec. mentions, so I'm not sure whether
it will work. Let me know how it goes.
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
failed to set signal flags properly for ast()
Compile, run under gdb, then type print test() when the program receives
SIGABRT. Seems to work incorrectly on 4.7 too.
#include stdio.h
#include stdlib.h
void
test(void)
{
puts(hello);
}
int
main(int argc, char *argv[])
{
abort();
exit(0);
}
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: NULL pointer problem in pid selection ?
On Mon, Mar 10, 2003 at 01:00:15PM -0500, John Baldwin wrote: On 08-Mar-2003 Kris Kennaway wrote: On Sat, Mar 08, 2003 at 11:46:34AM +0100, Poul-Henning Kamp wrote: Just got this crash on -current, and I belive I have seen similar before. addr2line(1) reports the faulting address to be ../../../kern/kern_fork.c:395 which is in the inner loop of pid collision avoidance. I've been running this patch from Alfred for the past month or so on bento, which has fixed a similar panic I was seeing regularly. Using just a shared lock instead of an xlock should be ok there. You aren't modifying the process tree, just looking at it. OTOH, the proc lock is supposed to protect p_grp and p_session, so they shouldn't be NULL. :( I have a suspiscion that the bug is actually in wait1(): sx_xlock(proctree_lock); [...] /* * Remove other references to this process to ensure * we have an exclusive reference. */ leavepgrp(p); sx_xlock(allproc_lock); LIST_REMOVE(p, p_list); /* off zombproc */ sx_xunlock(allproc_lock); LIST_REMOVE(p, p_sibling); sx_xunlock(proctree_lock); Shouldn't we be removing the process from zombproc before setting p_pgrp to NULL via leavepgrp()? Does this even matter at all when both fork1() and wait1() are still protected by Giant? Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Removal of netns
Is there a compelling reason why I shouldn't remove netns? That is, does it serve a purpose now that it could not serve if it was moved to the Attic? Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns
On Tue, Mar 04, 2003 at 02:53:56PM -0800, Julian Elischer wrote: I thought nwfs used it? nwfs uses netipx. From what I can tell, netipx was based on netns. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs crashes
On Thu, Feb 27, 2003 at 09:01:26PM -, Patrick Stinson wrote: whenever I move a file from a node mounted with mount_smbfs to a local fs, the system crashes with a kernel page fault. is this a known problem? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/48381 Are you still experiencing this problem with a kernel/smbfs module built after Feb 19 (PST)? Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
TCP is still broken
This program, based on one from the Apache 2 configure script, still causes
-current to lock up solid despite the recent bug fixes to the tcptw code.
Explicitly closing connected_s before returning from main() seems to avoid
the problem.
#include stdio.h
#include unistd.h
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include netinet/tcp.h
int main(void) {
int listen_s, connected_s, client_s;
int listen_port, rc;
struct sockaddr_in sa;
socklen_t sa_len;
socklen_t option_len;
int option;
listen_s = socket(AF_INET, SOCK_STREAM, 0);
if (listen_s 0) {
perror(socket);
exit(1);
}
memset(sa, 0, sizeof sa);
sa.sin_family = AF_INET;
/* leave port 0 to get ephemeral */
rc = bind(listen_s, (struct sockaddr *)sa, sizeof sa);
if (rc 0) {
perror(bind for ephemeral port);
exit(1);
}
/* find ephemeral port */
sa_len = sizeof(sa);
rc = getsockname(listen_s, (struct sockaddr *)sa, sa_len);
if (rc 0) {
perror(getsockname);
exit(1);
}
listen_port = sa.sin_port;
rc = listen(listen_s, 5);
if (rc 0) {
perror(listen);
exit(1);
}
client_s = socket(AF_INET, SOCK_STREAM, 0);
if (client_s 0) {
perror(socket);
exit(1);
}
memset(sa, 0, sizeof sa);
sa.sin_family = AF_INET;
sa.sin_port = listen_port;
/* leave sin_addr all zeros to use loopback */
rc = connect(client_s, (struct sockaddr *)sa, sizeof sa);
if (rc 0) {
perror(connect);
exit(1);
}
sa_len = sizeof sa;
connected_s = accept(listen_s, (struct sockaddr *)sa, sa_len);
if (connected_s 0) {
perror(accept);
exit(1);
}
return 0;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: signals still broken ?
On Wed, Feb 26, 2003 at 06:25:39AM -0500, Mike Makonnen wrote:
The following program is stuck in pause(3) forever. I have reproduced the bug in
5.0-RELEASE, but 4.7-STABLE behaves as expected: the child resumes upon
receiving SIGCONT.
I spent a while trying to decipher the 5.x signal code and I think I have
spotted the code responsible for the difference in behaviour between
5.x and 4.7. The difference is that 5.x drops SIGCONT when the process
is already active even when a handler is installed for that signal.
Here is a patch to try:
Do not drop SIGCONT signals when a process is not stopped and has
installed a handler for that signal.
Index: kern_sig.c
===
RCS file: /x/freebsd/src/sys/kern/kern_sig.c,v
retrieving revision 1.210
diff -u -r1.210 kern_sig.c
--- kern_sig.c 17 Feb 2003 09:58:11 - 1.210
+++ kern_sig.c 26 Feb 2003 13:41:01 -
@@ -1483,10 +1483,7 @@
* eventually hit thread_suspend_check().
*/
} else if (p-p_state == PRS_NORMAL) {
- if (prop SA_CONT) {
- /*
-* Already active, don't need to start again.
-*/
+ if ((prop SA_CONT) action == SIG_DFL) {
SIGDELSET(p-p_siglist, sig);
goto out;
}
With this patch applied, your test program seems to work properly except
that wait() is called incorrectly (1st arg should be a pointer):
$ ./a.out
sleeping 3s
waiting
a.out: wait(): Bad address
Let me know whether it works for you.
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: signals still broken ?
On Thu, Feb 27, 2003 at 01:10:03AM +1100, Tim Robbins wrote: On Wed, Feb 26, 2003 at 06:25:39AM -0500, Mike Makonnen wrote: The following program is stuck in pause(3) forever. I have reproduced the bug in 5.0-RELEASE, but 4.7-STABLE behaves as expected: the child resumes upon receiving SIGCONT. I spent a while trying to decipher the 5.x signal code and I think I have spotted the code responsible for the difference in behaviour between 5.x and 4.7. The difference is that 5.x drops SIGCONT when the process is already active even when a handler is installed for that signal. Here is a patch to try: [...] Never mind, I guess David beat me to it (kern_sig.c 1.211). Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: netncp/nwfs is rotting...
On Tue, Feb 25, 2003 at 02:33:19PM +0600, Max Khon wrote: I have a patch that makes nwfs work to some extent (i.e. I was able to mount and use netware shares from mars_nwe server). Great. Care I have a copy of it? I've got it to the stage where it will say Connection refused when trying to mount a volume off a machine that isn't running any netware server software, and am in the middle of trying to figure out how to set up mars_nwe... Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: today's 5-current hang hard when building apache2 port
On Fri, Feb 21, 2003 at 12:41:52PM -0800, Shizuka Kudo wrote: I cvsup today and build/install world kernel. The machine was working fine until I tried to build apache2 port. When configuring apache2, my PC hanged at the following line and need hard reset (i.e. cannot break into debugger and need pressing reset button). checking if TCP_NODELAY setting is inherited from listening sockets... I traced the conftest program under gdb and received the following error on the rc = connect(client_s, (struct sockaddr *)sa, sizeof sa) call. Program received signal SIGSEGV, Segmentation fault. 0x280fdaf0 in _longjmp () from /usr/lib/libc.so.5 Anyone has the same problem or idea what's happening? Attached are the confdefs.h and conftest.c extracted from srclib/apr/configure that gave the above problem. P.S. When building the apache2 port, I had CPUTYPE=p3 in make.conf and used make configure WITH_THREADS=yes I've had this same problem. Here's the test program I was using, extracted from the latest Apache 2 source, with puts() calls added: http://people.freebsd.org/~tjr/nodel.c . It seems to be locking up after the getsockopt() call has returned, presumably when crt0 calls exit(). Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Sun, Feb 16, 2003 at 08:57:29PM -0800, Kris Kennaway wrote: On Sun, Feb 16, 2003 at 07:52:35PM -0800, Andrey A. Chernov wrote: So, monotonically increased seed-first value correlation problem remains... I think we should commit this patch (to -current) and fix all the problems that pop up. For example, it's used in awk (which started this set of changes), and in some of the XFree86 libraries. Kris Index: stdlib/rand.c === RCS file: /mnt2/ncvs/src/lib/libc/stdlib/rand.c,v retrieving revision 1.14 diff -u -r1.14 rand.c --- stdlib/rand.c 5 Feb 2003 21:25:50 - 1.14 +++ stdlib/rand.c 8 Feb 2003 06:07:55 - @@ -86,6 +86,8 @@ #endif /* !USE_WEAK_SEEDING */ } +__warn_references(rand_r, + warning: rand_r() does not produce high-quality random numbers and should not generally be used); int rand_r(unsigned int *ctx) @@ -99,6 +101,9 @@ static u_long next = 892053144; /* after srand(1), NSHUFF counted */ + +__warn_references(rand, + warning: rand() does not produce high-quality random numbers and should not generally be used); int rand() I disagree. It's safe to use rand() in games and in certain kinds of simulations when you don't care that the distribution isn't quite uniform, or when you prefer speed over quality. I don't think rand() needs a warning message like gets() c. because it's not as dangerous. What I suggest instead is to remove the pathetic insults in rand(3) (bad random number generator, obsoleted) and add a BUGS section which describes the problem. I'd much prefer that rand() generated higher quality numbers, though. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Mon, Feb 17, 2003 at 08:53:09AM +0300, Andrey A. Chernov wrote: On Mon, Feb 17, 2003 at 16:40:48 +1100, Tim Robbins wrote: I don't think rand() needs a warning message like gets() c. because it's not as dangerous. Wait, what kind of warning __warn_references() produce? I was under impression that it is compile-time only. I was referring to the __warn_references() warning in gets(), not the annoying message written to standard error. What I suggest instead is to remove the pathetic insults in rand(3) (bad random number generator, obsoleted) and add a BUGS section which describes the problem. I agree. It can be done not instead only but in addition to compile time warning. I'd much prefer that rand() generated higher quality numbers, though. Current formulae generates acceptable quality numbers. Unlike in old variant (which generates bad quality ones), the only problem remains is first value monotonically increased with the seed. Here's an interesting picture of that: http://people.freebsd.org/~tjr/rand.gif Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sh broken on sparc64 (Re: cvs commit: src/bin/sh machdep.h memalloc.c nodes.c.pat)
On Sat, Feb 15, 2003 at 07:28:11PM -0800, Tim J. Robbins wrote: tjr 2003/02/15 19:28:11 PST Modified files: bin/sh memalloc.c nodes.c.pat Added files: bin/sh machdep.h Log: Temporarily back out machdep.h/ALIGN changes. It seems that on sparc64, using the alignment from sys/param.h (16) instead of the alignment from machdep.h (8) tickled a nasty bug in the memory allocator that I haven't been able to track down yet. The change before this one broke sparc64 pretty spectacularly. If you built world in the past 24 hours, you'll need to manually build and reinstall a new /bin/sh before trying to build again. I did test the change on alpha, ia64 and sparc64 before committing it, but obviously did not prod it hard enough... Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MSDOSFS wastes 256k when nothing is mounted!
On Sun, Feb 09, 2003 at 06:08:47PM -0500, Mike Makonnen wrote:
How about the attached?
It's only partially tested since it seems I can't mount any msdos floppies (both
on this _and_ my previous kernel).
Index: sys/fs/msdosfs/msdosfs_denode.c
===
RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_denode.c,v
retrieving revision 1.67
diff -u -r1.67 msdosfs_denode.c
--- sys/fs/msdosfs/msdosfs_denode.c 21 Jan 2003 08:55:46 - 1.67
+++ sys/fs/msdosfs/msdosfs_denode.c 9 Feb 2003 22:14:41 -
@@ -73,6 +73,12 @@
static u_long dehash;/* size of hash table - 1 */
#define DEHASH(dev, dcl, doff) (dehashtbl[(minor(dev) + (dcl) + (doff) /
\ sizeof(struct direntry)) dehash])
+#define DEHASH_INIT do {\
+ if (dehashtbl == NULL) {\
+ dehashtbl = hashinit(desiredvnodes/2, M_MSDOSFSMNT, dehash);\
+ KASSERT(dehashtbl != NULL, msdosfs dehashtbl == NULL);\
+ }\
+ } while (0)
static struct mtx dehash_mtx;
union _qcvt {
[...]
@@ -130,6 +138,7 @@
loop:
mtx_lock(dehash_mtx);
+ DEHASH_INIT;
for (dep = DEHASH(dev, dirclust, diroff); dep; dep = dep-de_next) {
if (dirclust == dep-de_dirclust
diroff == dep-de_diroffset
hashinit() can sleep, and I don't think it's safe to sleep here
(msdosfs_hashget() and msdosfs_hashins()) with dehash_mtx and
sometimes a vnode lock held.
It might be better to initialise the table the first time an
msdosfs filesystem is mounted.
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Panic in fork()
On Sat, Feb 08, 2003 at 02:04:56PM -0800, Kris Kennaway wrote:
On Sat, Feb 08, 2003 at 04:12:26PM +0100, Thomas Moestl wrote:
addr2line will usually point to the first line of a statement if it
spans multiple lines; in this case, the full guard is:
while (p2-p_pid == trypid ||
p2-p_pgrp-pg_id == trypid ||
p2-p_session-s_sid == trypid) {
OK, I suspected that.
tjr was looking into this last night and proposed the following patch:
Alfred was the one who pointed out that holding proctree was probably
necessary, though :-)
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: 5.0 cron problem
On Wed, Feb 05, 2003 at 05:57:30PM +0900, CHOI Junho wrote: [...] -- CVSUP=/usr/local/bin/cvsup -g -L2 -h localhost CVSUPDIR=/b/FreeBSD/cvsup # source sync 0 */1 * * * $CVSUP $CVSUPDIR/4_7-supfile /dev/null 20*/1 * * * $CVSUP $CVSUPDIR/5_0-supfile /dev/null 40*/1 * * * $CVSUP $CVSUPDIR/current-supfile /dev/null -- When I install this crontab: # crontab my-crontab my-crontab:0: bad minute crontab: errors in crontab file, can't install 0 means line number. It means variable setting doesn't work... I used this crontab over years on 4.[4567]-RELEASE happily. What happen to cron? I suspected updating procedure(/usr/src/UPDATING) because my -current desktop(starting from -current snapshot a year ago) doesn't have such problem. Since revision 1.11 of src/usr.sbin/cron/lib/env.c, you need to put the value of the environment variable inside quotes if it contains any spaces. I suspect that this change of behaviour was unintentional given that the implementation differs from the manual page. I'll investigate and fix it if it's a bug. In the mean time, use something like this instead: CVSUP=/usr/local/bin/cvsup -g -L2 -h localhost Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sun, Feb 02, 2003 at 03:30:35PM +0300, Andrey A. Chernov wrote: On Sun, Feb 02, 2003 at 13:26:21 +0300, Andrey A. Chernov wrote: Workaround I find so far is something like that #define MASK 123459876 I found nothing better. Here is fix for 0 problem I plan to commit: --- stdlib/rand.c.old Sat Jan 4 20:39:19 2003 +++ stdlib/rand.c Sun Feb 2 14:43:42 2003 @@ -70,14 +70,18 @@ * Park and Miller, Communications of the ACM, vol. 31, no. 10, * October 1988, p. 1195. */ +#define SHIFT_MASK 123459876 long hi, lo, x; - hi = *ctx / 127773; - lo = *ctx % 127773; + /* Can't be initialized with 0, so use shifting mask. */ + x = *ctx ^ SHIFT_MASK; + hi = x / 127773; + lo = x % 127773; x = 16807 * lo - 2836 * hi; - if (x = 0) + if (x 0) x += 0x7fff; - return ((*ctx = x) % ((u_long)RAND_MAX + 1)); + *ctx = x ^ SHIFT_MASK; + return (x % ((u_long)RAND_MAX + 1)); #endif /* !USE_WEAK_SEEDING */ } I believe that this change just moves the bad seed to 123459876; after calling srand() with that seed, each call to rand() returns 0. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: appending files on smbfs
On Thu, Jan 30, 2003 at 07:37:04PM -, Patrick Stinson wrote:
has anyone every had problems with appending existing files on volumes
mounted by smbfs or shlight?
$ echo sdsad hey
$ echo sdsad hey
cannot create hey: Permission denied
Please try this patch and let me know whether it solves the problem.
Index: src/sys/fs/smbfs/smbfs_vnops.c
===
RCS file: /x/freebsd/src/sys/fs/smbfs/smbfs_vnops.c,v
retrieving revision 1.28
diff -u -r1.28 smbfs_vnops.c
--- src/sys/fs/smbfs/smbfs_vnops.c 29 Jan 2003 13:41:52 - 1.28
+++ src/sys/fs/smbfs/smbfs_vnops.c 3 Feb 2003 05:51:45 -
@@ -139,10 +139,9 @@
} */ *ap;
{
struct vnode *vp = ap-a_vp;
- struct ucred *cred = ap-a_cred;
- u_int mode = ap-a_mode;
+ mode_t mode = ap-a_mode;
+ mode_t smbmode;
struct smbmount *smp = VTOSMBFS(vp);
- int error = 0;
SMBVDEBUG(\n);
if ((mode VWRITE) (vp-v_mount-mnt_flag MNT_RDONLY)) {
@@ -153,15 +152,10 @@
break;
}
}
- if (cred-cr_uid == 0)
- return 0;
- if (cred-cr_uid != smp-sm_args.uid) {
- mode = 3;
- if (!groupmember(smp-sm_args.gid, cred))
- mode = 3;
- }
- error = (((vp-v_type == VREG) ? smp-sm_args.file_mode :
smp-sm_args.dir_mode) mode) == mode ? 0 : EACCES;
- return error;
+ smbmode = vp-v_type == VREG ? smp-sm_args.file_mode :
+ smp-sm_args.dir_mode;
+ return (vaccess(vp-v_type, smbmode, smp-sm_args.uid,
+ smp-sm_args.gid, ap-a_mode, ap-a_cred, NULL));
}
/* ARGSUSED */
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Profiling kills -current?
On Thu, Jan 30, 2003 at 04:17:39PM -0500, Robert Watson wrote: Looks like recent commits may have broken profiling of user applications; or rather, it's also causing the kernel to crash. I suspect (but have not confirmed) it was the recent KSE commit. This commit should have fixed the problem causing the system to lock up when profiling was used. A quick check shows that it's generating reasonable results now, but I believe that there are other profiling bugs in -current. == tjr 2003/01/31 03:22:32 PST Modified files: sys/kern subr_trap.c Log: Use a local variable to store the number of ticks that elapsed in kernel mode instead of (unintentionally) using the global `ticks'. This error completely broke profiling. Revision ChangesPath 1.241 +3 -2 src/sys/kern/subr_trap.c == Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serious issues with kqueue on sockets on CURRENT.
On Fri, Jan 10, 2003 at 01:30:16AM -0800, Juli Mallett wrote: Lately, the data field for sockets, which holds bytes ready (in the EVFILT_ READ case) to be read, is computed to be zero. This means that if you have a low watermark which is 0 per the kq, THE EVENT WILL NEVER HAPPEN. Not to mention that this means when the event IS triggered properly (if you can call it that), it is always said to have =ZERO= bytes ready. [...] I can definitely reproduce this here and also fairly angry about it. In addition to what you mentioned, fstat() gives an incorrect st_size result now and it's likely that non-NOTE_LOWAT low watermarks are firing too early as well. Ugly test program @ http://people.freebsd.org/~tjr/kq.c Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serious issues with kqueue on sockets on CURRENT.
On Fri, Jan 10, 2003 at 09:57:36PM +1100, Tim Robbins wrote:
On Fri, Jan 10, 2003 at 01:30:16AM -0800, Juli Mallett wrote:
Lately, the data field for sockets, which holds bytes ready (in the EVFILT_
READ case) to be read, is computed to be zero. This means that if you have
a low watermark which is 0 per the kq, THE EVENT WILL NEVER HAPPEN. Not to
mention that this means when the event IS triggered properly (if you can
call it that), it is always said to have =ZERO= bytes ready.
[...]
I can definitely reproduce this here and also fairly angry about it.
In addition to what you mentioned, fstat() gives an incorrect st_size
result now and it's likely that non-NOTE_LOWAT low watermarks are
firing too early as well.
Ugly test program @ http://people.freebsd.org/~tjr/kq.c
From what I can tell, mbufs with m_type == MT_HEADER can store data
as well as those with m_type == MT_DATA. This patch corrects the
tests in sbcompress(), sbdrop(), sballoc() and sbfree() so that data
stored in MT_HEADER mbufs is not included in sb_ctl. I'd appreciate
comments from people who have a good understanding of this code.
Index: sys/kern/uipc_socket2.c
===
RCS file: /x/freebsd/src/sys/kern/uipc_socket2.c,v
retrieving revision 1.106
diff -u -r1.106 uipc_socket2.c
--- sys/kern/uipc_socket2.c 5 Nov 2002 18:52:25 - 1.106
+++ sys/kern/uipc_socket2.c 10 Jan 2003 13:33:11 -
@@ -705,7 +705,8 @@
(unsigned)m-m_len);
n-m_len += m-m_len;
sb-sb_cc += m-m_len;
- if (m-m_type != MT_DATA) /* XXX: Probably don't need.*/
+ if (m-m_type != MT_DATA m-m_type != MT_HEADER)
+ /* XXX: Probably don't need.*/
sb-sb_ctl += m-m_len;
m = m_free(m);
continue;
@@ -776,7 +777,7 @@
m-m_len -= len;
m-m_data += len;
sb-sb_cc -= len;
- if (m-m_type != MT_DATA)
+ if (m-m_type != MT_DATA m-m_type != MT_HEADER)
sb-sb_ctl -= len;
break;
}
Index: sys/sys/socketvar.h
===
RCS file: /x/freebsd/src/sys/sys/socketvar.h,v
retrieving revision 1.98
diff -u -r1.98 socketvar.h
--- sys/sys/socketvar.h 23 Dec 2002 22:46:47 - 1.98
+++ sys/sys/socketvar.h 10 Jan 2003 01:53:51 -
@@ -228,7 +228,7 @@
/* adjust counters in sb reflecting allocation of m */
#definesballoc(sb, m) { \
(sb)-sb_cc += (m)-m_len; \
- if ((m)-m_type != MT_DATA) \
+ if ((m)-m_type != MT_DATA (m)-m_type != MT_HEADER) \
(sb)-sb_ctl += (m)-m_len; \
(sb)-sb_mbcnt += MSIZE; \
if ((m)-m_flags M_EXT) \
@@ -238,7 +238,7 @@
/* adjust counters in sb reflecting freeing of m */
#definesbfree(sb, m) { \
(sb)-sb_cc -= (m)-m_len; \
- if ((m)-m_type != MT_DATA) \
+ if ((m)-m_type != MT_DATA (m)-m_type != MT_HEADER) \
(sb)-sb_ctl -= (m)-m_len; \
(sb)-sb_mbcnt -= MSIZE; \
if ((m)-m_flags M_EXT) \
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: mount_portalfs broken in 5.0-RC2
On Mon, Dec 30, 2002 at 10:51:20PM +0100, Michael Ranner wrote: After mounting the portalfs, # cat /p/tcp or # cat /p/telnet or # cat /p/http portalfs hangs instead of expected cat: /p/telnet: No such file or directory I tried but failed to fix this. I think that the vnode locking in portalfs is hosed. From memory, I think that portal_lookup() was part of the problem. Try building a kernel with DEBUG_VFS_LOCKS and watch for the warnings from portalfs. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
failed to set signal flags properly for ast()
I noticed a bunch of these messages in my logs from today: kernel: failed to set signal flags properly for ast() last message repeated 24 times I don't remember what I was doing at the time, but it wasn't anything unusual; just hacking on wordexp() or something. Kernel is GENERIC from 24th December. I don't recall ever seeing this message before today. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sa_handler and sigaction...
On Thu, Dec 26, 2002 at 12:27:43PM -0600, Dan Nelson wrote: In the last episode (Dec 26), Donn Miller said: Just tried compiling the mgv port on current. It bombs out with the following error message: Making all in toolbar cc -DPACKAGE=\mgv\ -DVERSION=\3.1.5\ -DHAVE_PUTENV=0 -DUSE_DMALLOC=0 -DHAVE_XPM=1 -DHAVE_X11_XPM_H=1 -DHAVE_MOTIF=1 -DHAVE_LIBHELP=0 -DHAVE_EDITRES=1 -I. -I. -I. -Iwlib -I/usr/X11R6/include -O2 -Os -pipe -march=pentium3 -D_POSIX_SOURCE -I/usr/X11R6/include -c Ghostview.c Ghostview.c: In function `Input': Ghostview.c:487: structure has no member named `sa_handler' Ghostview.c: In function `StopInterpreter': Ghostview.c:1529: structure has no member named `sa_handler' *** Error code 1 Stop in /usr/ports/print/mgv/work/mgv-3.1.5. *** Error code 1 Stop in /usr/ports/print/mgv. It looks like it should compile, but it doesn't. I mean, sys/signal.h does have a #define for sa_handler. But not in the -D_POSIX_SOURCE case. Could someone with the POSIX spec see whether sa_handler is supposed to be visible or not? From the SUSv3 System Interfaces volume (excuse the bad formatting): 41429 The structure sigaction, used to describe an action to be taken, is defined in the signal.h 41430 header to include at least the following members: 41431 41432 Member Type Member Name Description 41433 void(*) (int) sa_handler SIG_DFL, SIG_IGN, or pointer to a function. 43434 sigset_t sa_mask Additional set of signals to be blocked during execution of signal-catching function. 41437 int sa_flagsSpecial flags to affect behavior of signal. 41438 void(*) (int, 41439 siginfo_t *, void *) sa_sigaction Signal-catching function. 41440 The storage occupied by sa_handler and sa_sigaction may overlap, and a conforming application 41441 shall not use both simultaneously. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: WEIRD! div() broken on -CURRENT?
On Fri, Dec 20, 2002 at 09:24:39PM -0500, Joe Marcus Clarke wrote:
Okay, I must be losing my mind. Does anyone know why the following
program compiled with stock gcc-3.2.1, stock CFLAGS, and no CPUTYPE
produces:
ddy.quot = 1
ddy.rem = -1077937744
on -CURRENT, and:
ddy.quot = 8
ddy.rem = 0
On -stable?
#include stdlib.h
#include stdio.h
main(void) {
div_t ddy;
int dy, dy_frac;
ddy = div (768, 96);
dy = ddy.quot;
dy_frac = ddy.rem;
printf(ddy.quot = %d\n, dy);
printf(ddy.rem = %d\n, dy_frac);
return 0;
}
cc -O -pipe -o xxx xxx.c
I'm doing something wrong, right? I mean, this can't be right. I've
verified this now on a P4 running:
[...]
I can reproduce it here. It looks like gcc is using a strange calling
convention that the i386 div.S does not understand (MI div.c seems to, though).
It's generating the following code:
0x8048541 main+9: mov$0x0,%eax
0x8048546 main+14:sub%eax,%esp
0x8048548 main+16:lea0xfff8(%ebp),%eax
0x804854b main+19:sub$0x4,%esp
0x804854e main+22:push $0x60
0x8048550 main+24:push $0x300
0x8048555 main+29:push %eax
0x8048556 main+30:call 0x80483ec div
0x804855b main+35:add$0xc,%esp
At the time of the call to div():
(gdb) x/4w $esp
0xbfbffbbc: 0x0804855b 0xbfbffbe8 0x0300 0x0060
It looks like gcc might be pushing the address of ddy and expecting div()
to put the result in there.
Microsoft C 12 generates this code:
sub esp, 8
push96 ; 0060H
push768 ; 0300H
call_div
add esp, 8
mov DWORD PTR [ebp], eax
mov DWORD PTR [ebp+4], edx
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: WEIRD! div() broken on -CURRENT?
On Fri, Dec 20, 2002 at 08:43:25PM -0800, Juli Mallett wrote: * De: Tim Robbins [EMAIL PROTECTED] [ Data: 2002-12-20 ] [ Subjecte: Re: WEIRD! div() broken on -CURRENT? ] On Fri, Dec 20, 2002 at 09:24:39PM -0500, Joe Marcus Clarke wrote: I'm doing something wrong, right? I mean, this can't be right. I've verified this now on a P4 running: [...] I can reproduce it here. It looks like gcc is using a strange calling convention that the i386 div.S does not understand (MI div.c seems to, though). TenDRA and GCC3 use a different struct return format than we used to use (see http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01783.html) and we never had a flag day for the old format, and there's no UPDATING or whatnot notes about this AFAIK. This means at least div has to change to use the new calling convention. [...] I've imported the versions of div.S and ldiv.S from NetBSD HEAD which work properly with the new calling convention. Thanks for mentioning (on IRC) that the pcc struct return convention had something to do with it. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unrar doesn't work under current
On Tue, Dec 17, 2002 at 01:44:44AM +0100, Riccardo Torrini wrote: Trying to extract a single or multi volume archive doesn't work. Same archive can be extracted fine with unrar under 4.7-STABLE. My -CURRENT from 10 day ago. Tryed to remove and rebuild unrar without luck. rar on -CURRENT also works. Any idea? [...] # uname -v FreeBSD 5.0-RC #47: Sun Dec 8 18:09:42 CET 2002 ... # unrar t sample.rar UNRAR 3.10 beta 1 freeware Copyright (c) 1993-2002 Eugene Roshal Cannot open sample.rar No files to extract [...] I tried to reproduce this but could not with these two versions of unrar: UNRAR 3.00 freeware (from source) UNRAR 3.10 beta 1 freeware (from ports) The output of ktrace/kdump or truss would be useful in investigating this. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __BSD_VISIBLE and u_int
On Fri, Dec 13, 2002 at 11:48:23PM +0100, Marc Recht wrote: Hmm, which of these defines claims posix src? -D_ANSI_SOURCE ? cc -O -c -O -pipe -mcpu=pentiumpro -mcpu=pentiumpro -I./../include [...] u_int is undocumented and unportable, so it probably shouldn't be used. It's only 3 characters shorter than `unsigned' anyway. It's for ports. And this is once a again a good example why we _really_ need a define (like Solaris'__EXTENSIONS__ ) that sets __BSD_VISIBLE (no matter what) and could be set in CONFIBURE_ENV. No, it's a good example of why Linux programmers shouldn't ask for an ANSI C environment then complain when sys/file.h does not work. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fincore.c strikes again (panic bremfree: bp not locked)
On Thu, Dec 12, 2002 at 07:20:15PM -0500, Brian Fundakowski Feldman wrote:
I don't have any more info since for some reason the kernel wasn't saved
when my system dumped core, but yet again fincore.c causes evidence that
-CURRENT has regressed again. I can't find the old thread I'm thinking of,
but from a slightly different thread, bde knew what was going on.
[...]
I can reproduce the panic here. This is the message backtrace, for anyone
who wants to help track it down:
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: from debugger
panic messages:
---
panic: mutex vm page queue mutex not owned at /usr/src/sys/i386/i386/pmap.c:3141
panic: from debugger
Uptime: 2h37m31s
Dumping 64 MB
ata0: resetting devices ..
done
16 32 48
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1 0xc0197bfc in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2 0xc0197e43 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc01318d2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc0131852 in db_command (last_cmdp=0xc02d73c0, cmd_table=0x0,
aux_cmd_tablep=0xc02d20e4, aux_cmd_tablep_end=0xc02d20e8)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc0131966 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc013465a in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc0287862 in kdb_trap (type=3, code=0, regs=0xc6279ba8)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc0298eef in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1058181856, tf_esi = 256, tf_ebp
= -970482700, tf_isp = -970482732, tf_ebx = 0, tf_edx = 0, tf_ecx = 32, tf_eax = 18,
tf_trapno = 3, tf_err = 0, tf_eip = -107102, tf_cs = 8, tf_eflags = 646, tf_esp =
-1070805470, tf_ss = -1070875346})
at /usr/src/sys/i386/i386/trap.c:603
#9 0xc0289048 in calltrap () at {standard input}:98
#10 0xc0197e2b in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:503
#11 0xc018eb3c in _mtx_assert (m=0xc02ef400, what=0,
file=0xc02ce210 /usr/src/sys/i386/i386/pmap.c, line=3141)
at /usr/src/sys/kern/kern_mutex.c:838
#12 0xc0296b24 in pmap_ts_referenced (m=0xc45)
at /usr/src/sys/i386/i386/pmap.c:3141
---Type return to continue, or q return to quit---
#13 0xc0296ec3 in pmap_mincore (pmap=0x0, addr=0)
at /usr/src/sys/i386/i386/pmap.c:3340
#14 0xc025d51c in mincore (td=0x3ab0405, uap=0x0)
at /usr/src/sys/vm/vm_mmap.c:874
#15 0xc02997f7 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077937044, tf_esi = -1077937032,
tf_ebp = -1077937084, tf_isp = -970482316, tf_ebx = 2, tf_edx = 134524928, tf_ecx = 8,
tf_eax = 78, tf_trapno = 12, tf_err = 2, tf_eip = 671813747, tf_cs = 31, tf_eflags =
658, tf_esp = -1077937300, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#16 0xc028909d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
(kgdb) frame 12
#12 0xc0296b24 in pmap_ts_referenced (m=0xc45)
at /usr/src/sys/i386/i386/pmap.c:3141
3141mtx_assert(vm_page_queue_mtx, MA_OWNED);
(kgdb) print vm_page_queue_mtx
$1 = {mtx_object = {lo_class = 0xc02df5c0,
lo_name = 0xc02ca52a vm page queue mutex,
lo_type = 0xc02ca52a vm page queue mutex, lo_flags = 196608, lo_list = {
tqe_next = 0xc02ef3a0, tqe_prev = 0xc030d10c}, lo_witness = 0xc0310148},
mtx_lock = 4, mtx_recurse = 0, mtx_blocked = {tqh_first = 0x0,
tqh_last = 0xc02ef424}, mtx_contested = {le_next = 0x0, le_prev = 0x0},
mtx_acqtime = 0, mtx_filename = 0x0, mtx_lineno = 0}
This stuff probably is not useful:
(kgdb) frame 14
#14 0xc025d51c in mincore (td=0x3ab0405, uap=0x0)
at /usr/src/sys/vm/vm_mmap.c:874
874 mincoreinfo = pmap_mincore(pmap, addr);
(kgdb) print pmap
$2 = (struct pmap *) 0xc0609bdc
(kgdb) print addr
$3 = 672395264
(kgdb) print *pmap
$4 = {pm_pdir = 0xc62b7000, pm_pteobj = 0xc1048410, pm_pvlist = {
tqh_first = 0xc05c5188, tqh_last = 0xc05a8be0}, pm_active = 1, pm_stats = {
resident_count = 173, wired_count = 0}, pm_ptphint = 0xc0484368,
pm_list = {le_next = 0xc060962c, le_prev = 0xc02f56fc}}
(kgdb) frame 13
#13 0xc0296ec3 in pmap_mincore (pmap=0x0, addr=0)
at /usr/src/sys/i386/i386/pmap.c:3340
(kgdb) print m
$5 = (struct vm_page *) 0xc0543138
(kgdb) print *m
$6 = {pageq = {tqe_next = 0xc054a6c8, tqe_prev = 0xc04967a0}, listq = {
tqe_next = 0xc04fd580, tqe_prev = 0xc04806f8}, left = 0xc053df60,
right = 0xc04afc10, object = 0xc0435958, pindex = 6, phys_addr = 61538304,
md =
Re: fincore.c strikes again (panic bremfree: bp not locked)
Here's a proposed patch for this problem:
Index: src/sys/i386/i386/pmap.c
===
RCS file: /x/freebsd/src/sys/i386/i386/pmap.c,v
retrieving revision 1.376
diff -u -r1.376 pmap.c
--- src/sys/i386/i386/pmap.c3 Dec 2002 04:00:42 - 1.376
+++ src/sys/i386/i386/pmap.c13 Dec 2002 02:54:44 -
@@ -3300,7 +3300,7 @@
{
pt_entry_t *ptep, pte;
vm_page_t m;
- int val = 0;
+ int refd, val = 0;
ptep = pmap_pte(pmap, addr);
if (ptep == 0) {
@@ -3337,9 +3337,17 @@
/*
* Referenced by someone
*/
- else if ((m-flags PG_REFERENCED) || pmap_ts_referenced(m)) {
+ else if (m-flags PG_REFERENCED) {
val |= MINCORE_REFERENCED_OTHER;
vm_page_flag_set(m, PG_REFERENCED);
+ } else {
+ vm_page_lock_queues();
+ refd = pmap_ts_referenced(m);
+ vm_page_unlock_queues();
+ if (refd) {
+ val |= MINCORE_REFERENCED_OTHER;
+ vm_page_flag_set(m, PG_REFERENCED);
+ }
}
}
return val;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: SED regression
On Thu, Dec 05, 2002 at 11:49:01PM +0900, FUJISHIMA Satsuki wrote: Does anyone see this? both -CURRENT and -STABLE fail at the same place. note: GNU sed 3.02 from ports passed this test. /usr/src/tools/regression/usr.bin/sed$ make Running test G PASS: Test G detected no regression. (in /usr/src/tools/regression/usr.bin/sed) Running test P PASS: Test P detected no regression. (in /usr/src/tools/regression/usr.bin/sed) Running test psl PASS: Test psl detected no regression. (in /usr/src/tools/regression/usr.bin/sed) Running test bcb PASS: Test bcb detected no regression. (in /usr/src/tools/regression/usr.bin/sed) Running test y --- regress.y.out Fri Jun 28 01:07:51 2002 +++ - Thu Dec 5 23:26:19 2002 @@ -1 +1 @@ -fOO \ No newline at end of file +fOO FAIL: Test y failed: regression detected. See above. (in /usr/src/tools/regression/usr.bin/sed) *** Error code 1 Stop in /usr/src/tools/regression/usr.bin/sed. Our current behaviour is correct according to the relevant standards, but it is not what a user might expect. The problem was that sed previously stored the last newline of a space (pattern/hold), but now it is implicit. This makes it easier to implement many of the commands that were wrong in earlier releases of FreeBSD and were hacked around (see process.c revision 1.4, for example). We do need to restore support for missing newlines at EOF, though, but it's not a very high priority. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
smbfs workaround
I'd appreciate it if the people who were experiencing problems with
smbfs could try this patch and let me know how it goes.
The patch adds two sysctls, net.smb.readwritex and net.smb.reqdatasize.
readwritex controls whether LARGE_READX and LARGE_WRITEX requests are
used, and is off by default. reqdatasize controls the maximum number of
bytes of data to request from the user with each read request, and it
defaults to a fairly conservative value of 4096.
Setting readwritex to 0 makes smbfs work when the server OS is Windows XP.
Setting reqdatasize to 4096 makes it work when the server OS is
FreeBSD 4.7-RELEASE-p2 w/ Samba 2.2.3a.
This patch is just a temporary workaround, of course. I have not been
able to track down the real problem.
Tim
Index: src/sys/netsmb/smb_smb.c
===
RCS file: /x/freebsd/src/sys/netsmb/smb_smb.c,v
retrieving revision 1.7
diff -u -r1.7 smb_smb.c
--- src/sys/netsmb/smb_smb.c16 Sep 2002 10:50:38 - 1.7
+++ src/sys/netsmb/smb_smb.c24 Nov 2002 02:50:14 -
@@ -71,6 +71,22 @@
#defineSMB_DIALECT_MAX (sizeof(smb_dialects) / sizeof(struct smb_dialect) - 2)
+SYSCTL_DECL(_net_smb);
+
+/*
+ * XXX Something is causing requests for more than about 4 kbytes of data
+ * to fail. LARGE_READX and LARGE_WRITEX requests are disabled by default,
+ * and data is requested in 4 kbyte (or smaller) chunks.
+ */
+
+static int smb_rwx = 0;
+SYSCTL_INT(_net_smb, OID_AUTO, readwritex, CTLFLAG_RW, smb_rwx, 0,
+Controls whether LARGE_READX and LARGE_WRITEX requests will be used);
+
+static int smb_reqdatasize = 4096;
+SYSCTL_INT(_net_smb, OID_AUTO, reqdatasize, CTLFLAG_RW, smb_reqdatasize, 0,
+Maximum number of bytes of data to request at a time);
+
static u_int32_t
smb_vc_maxread(struct smb_vc *vcp)
{
@@ -78,7 +94,7 @@
* Specs say up to 64k data bytes, but Windows traffic
* uses 60k... no doubt for some good reason.
*/
- if (vcp-vc_sopt.sv_caps SMB_CAP_LARGE_READX)
+ if (smb_rwx vcp-vc_sopt.sv_caps SMB_CAP_LARGE_READX)
return (60*1024);
else
return (vcp-vc_sopt.sv_maxtx);
@@ -91,7 +107,7 @@
* Specs say up to 64k data bytes, but Windows traffic
* uses 60k... probably for some good reason.
*/
- if (vcp-vc_sopt.sv_caps SMB_CAP_LARGE_WRITEX)
+ if (smb_rwx vcp-vc_sopt.sv_caps SMB_CAP_LARGE_WRITEX)
return (60*1024);
else
return (vcp-vc_sopt.sv_maxtx);
@@ -239,7 +255,7 @@
sp-sv_maxtx = 1024;
else
sp-sv_maxtx = min(sp-sv_maxtx,
- 63*1024 + SMB_HDRLEN + 16);
+ smb_reqdatasize + SMB_HDRLEN + 16);
SMB_TRAN_GETPARAM(vcp, SMBTP_RCVSZ, maxqsz);
vcp-vc_rxmax = min(smb_vc_maxread(vcp), maxqsz - 1024);
SMB_TRAN_GETPARAM(vcp, SMBTP_SNDSZ, maxqsz);
@@ -735,7 +751,7 @@
u_int8_t wc;
int error, rlen, blksz;
- if (SSTOVC(ssp)-vc_sopt.sv_caps SMB_CAP_LARGE_READX)
+ if (smb_rwx SSTOVC(ssp)-vc_sopt.sv_caps SMB_CAP_LARGE_READX)
return (smb_smb_readx(ssp, fid, len, rresid, uio, scred));
error = smb_rq_alloc(SSTOCP(ssp), SMB_COM_READ, scred, rqp);
@@ -813,7 +829,8 @@
u_int8_t wc;
int error, blksz;
- if (*len SSTOVC(ssp)-vc_sopt.sv_caps SMB_CAP_LARGE_WRITEX)
+ if (smb_rwx *len
+ SSTOVC(ssp)-vc_sopt.sv_caps SMB_CAP_LARGE_WRITEX)
return (smb_smb_writex(ssp, fid, len, rresid, uio, scred));
blksz = SSTOVC(ssp)-vc_txmax - SMB_HDRLEN - 16;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: smbfs workaround
On Sun, Nov 24, 2002 at 02:34:40PM +1100, Tim Robbins wrote: I'd appreciate it if the people who were experiencing problems with smbfs could try this patch and let me know how it goes. The patch adds two sysctls, net.smb.readwritex and net.smb.reqdatasize. readwritex controls whether LARGE_READX and LARGE_WRITEX requests are used, and is off by default. reqdatasize controls the maximum number of bytes of data to request from the user with each read request, and it defaults to a fairly conservative value of 4096. Setting readwritex to 0 makes smbfs work when the server OS is Windows XP. Setting reqdatasize to 4096 makes it work when the server OS is FreeBSD 4.7-RELEASE-p2 w/ Samba 2.2.3a. This patch is just a temporary workaround, of course. I have not been able to track down the real problem. I should note that reqdatasize=4096 works for reading files, but not writing them. reqdatasize=1024 allows files to be written, but it looks like they are getting corrupted. Could this be a bug in the mbuf or mchain code or a change in semantics that netsmb has not been updated for? Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
smbfs panic
Here's a backtrace of a smbfs panic. Looks like it does not correctly handle the smbfs_getpages error it is encountering and leaves garbage vnodes lying around. The panic probably comes from the VI_LOCK macro call on smbfs_node.c line 321. # cp blah.tar.gz ~tim cp: /home/tim/blah.tar.gz: Bad address in dmesg: smbfs_getpages: error 60 vm_fault: pager read error, pid 433 (cp) Upon trying to halt: syncing disks, buffers remaining... done Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc0de fault code = supervisor read, page not present instruction pointer = 0x8:0xc0171e23 stack pointer = 0x10:0xc5bd2a1c frame pointer = 0x10:0xc5bd2a3c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 process eflags = interrupt enabled, IOPL = 0 current process = halt kernel: type 12 trap, code=0 Stopped at_mtx_lock_flags+0x43: cmpl $0xc02afd80,0(%ebx) db trace _mtx_lock_flags(deadc0de,0,c0f280b7,141,c0f05000) at _mtx_lock_flags+0x43 smbfs_reclaim(c5bd2a94,12,c0602540,c0602540,0) at smbfs_reclaim+0x11a vclean(c0f53a68,8,c0602540,6,c0f53a68) at vclean+0x229 vgonel(c0f53a68,c0602540,c02903f2,94a,0) at vgonel+0x5c smbfs_umount(c0ea8400,8,c0602540,c0602540,0) at smbfs_umount+0x3c dounmount(c0ea8400,8,c0602540,,c216304c) at dounmount+0x204 vfs_unmountall(...) boot(...) reboot(...) syscall(...) Xint0x80_syscall(...) --- syscall (55, FreeBSD ELF32, reboot), eip = 0x8048e9f, esp = 0xbfbffb1c, ebp = 0xbfbffb60 --- Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: smbfs panic
On Thu, Nov 21, 2002 at 02:02:39AM -0800, Terry Lambert wrote: Tim Robbins wrote: Here's a backtrace of a smbfs panic. Looks like it does not correctly handle the smbfs_getpages error it is encountering and leaves garbage vnodes lying around. The panic probably comes from the VI_LOCK macro call on smbfs_node.c line 321. # cp blah.tar.gz ~tim cp: /home/tim/blah.tar.gz: Bad address Read the list archives. We discussed this to death. The correct thing to do is to back off and retry -- that's decimal 60, which is hex 0x3c, which, according to /sys/netsmb/smb_rq.h is: I am aware that the Bad address errors have been discussed before, but I had not seen the panic on unmount/halt mentioned. Thanks for the workaround and suggested correct fix, I'll have a go at implementing that next week. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Asking for tester (small patch to chown(8)/chgrp(1))
On Wed, Nov 20, 2002 at 01:27:43PM +0100, Alexander Leidinger wrote: On Tue, 19 Nov 2002 10:27:00 -0800 David Schultz [EMAIL PROTECTED] wrote: I'm concerned about the used character: -r is similiar to -R Yes, `-r' would be a very poor choice for the reason you state. Agreed, but the precedent has already been set by touch(1) and truncate(1). If we're going to get it wrong some of the time, we might as well be consistent about it. When we don't look at the fact that neither touch nor truncate operate recursivly... what about changing touch and truncate to allow the proposed -c (or -i) too and mark -r as deprecated (if it isn't covered by a standard)? I'd really rather that we didn't change this at all, even if it seems inconsistent. Changing it would just lead to more confusion. I am also against adding new options to chown to copy ownership from existing files. Copy ownership: chown `stat -f%Su file1` file2 Copy group: chgrp `stat -f%Sg file1` file2 Copy both: chown `stat -f%Su:%Sg file1` file2 These could easily be made into shell functions or whatever... Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: awk(1) is locale unaware (was: Re: buildworld breakage during make depend at usr.bin/kdump)
On Wed, Nov 20, 2002 at 04:38:38AM +0300, Andrey A. Chernov wrote:
On Tue, Nov 19, 2002 at 14:52:02 +0200, Ruslan Ermilov wrote:
It seems that this patch has never been committed. This is a critical
bug that should be fixed before 5.0-RELEASE is out.
I agree. There is no locale yet and I never see that patch.
This patch seems to work, I used the logic from regcomp.c in libc.
Long lines make it ugly, but it was like that when I got here ;)
Tim
Index: src/usr.bin/awk/Makefile
===
RCS file: /x/freebsd/src/usr.bin/awk/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
--- src/usr.bin/awk/Makefile10 May 2002 20:36:21 - 1.9
+++ src/usr.bin/awk/Makefile20 Nov 2002 03:13:50 -
@@ -6,7 +6,7 @@
PROG= nawk
SRCS= awkgram.y b.c lex.c lib.c main.c parse.c proctab.c run.c tran.c ytab.h
-CFLAGS+= -I. -I${AWKSRC}
+CFLAGS+= -I. -I${AWKSRC} -I${.CURDIR}/../../lib/libc/locale
DPADD= ${LIBM}
LDADD= -lm
Index: src/contrib/one-true-awk/b.c
===
RCS file: /x/freebsd/src/contrib/one-true-awk/b.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 b.c
--- src/contrib/one-true-awk/b.c19 Feb 2002 09:35:24 - 1.1.1.2
+++ src/contrib/one-true-awk/b.c20 Nov 2002 03:16:10 -
@@ -32,6 +32,7 @@
#include stdlib.h
#include awk.h
#include ytab.h
+#include collate.h
#defineHAT (NCHARS-2) /* matches ^ in regular expr */
/* NCHARS is 2**n */
@@ -284,7 +285,7 @@
char *cclenter(char *argp) /* add a character class */
{
- int i, c, c2;
+ int i, j, c, c2;
uschar *p = (uschar *) argp;
uschar *op, *bp;
static uschar *buf = 0;
@@ -308,12 +309,24 @@
i--;
continue;
}
- while (c c2) {
- if (!adjbuf((char **) buf, bufsz, bp-buf+2,
100, (char **) bp, 0))
- FATAL(out of space for character
class [%.10s...] 2, p);
- *bp++ = ++c;
- i++;
- }
+ if (__collate_load_error) {
+ while (c c2) {
+ if (!adjbuf((char **) buf, bufsz,
+bp-buf+2, 100, (char **) bp, 0))
+ FATAL(out of space for
+character class [%.10s...] 2, p);
+ *bp++ = ++c;
+ i++;
+ }
+ } else {
+ for (j = CHAR_MIN; j = CHAR_MAX; j++) {
+ if (!adjbuf((char **) buf, bufsz,
+bp-buf+2, 100, (char **) bp, 0))
+ FATAL(out of space for
+character class [%.10s...] 2, p);
+ if (__collate_range_cmp(c, j) = 0
+__collate_range_cmp(j, c2) =
+0) {
+ *bp++ = j;
+ i++;
+ }
+ }
+}
continue;
}
}
Index: src/contrib/one-true-awk/main.c
===
RCS file: /x/freebsd/src/contrib/one-true-awk/main.c,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 main.c
--- src/contrib/one-true-awk/main.c 16 Mar 2002 16:50:56 - 1.1.1.3
+++ src/contrib/one-true-awk/main.c 20 Nov 2002 03:03:38 -
@@ -27,6 +27,7 @@
#define DEBUG
#include stdio.h
#include ctype.h
+#include locale.h
#include stdlib.h
#include string.h
#include signal.h
@@ -55,6 +56,7 @@
char *fs = NULL;
cmdname = argv[0];
+ setlocale(LC_ALL, );
if (argc == 1) {
fprintf(stderr, Usage: %s [-f programfile | 'program'] [-Ffieldsep]
[-v var=value] [files]\n, cmdname);
exit(1);
Index: src/contrib/one-true-awk/run.c
===
RCS file: /x/freebsd/src/contrib/one-true-awk/run.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 run.c
--- src/contrib/one-true-awk/run.c 19 Feb 2002 09:35:25 - 1.1.1.2
+++ src/contrib/one-true-awk/run.c 20 Nov 2002 03:02:29 -
@@ -1504,11 +1504,11 @@
if (t == FTOUPPER) {
for (p = buf; *p; p++)
Re: icecast broken by signal changes
On Mon, Nov 18, 2002 at 02:43:28AM -0800, Kris Kennaway wrote: http://bento.freebsd.org/errorlogs/5-latest/icecast-1.3.12_1.log cc -DHAVE_CONFIG_H -I. -I. -I.. -D_REENTRANT -I/usr/include/readline -pthread threads.c: In function `thread_block_signals': threads.c:467: `SIGBUS' undeclared (first use in this function) threads.c:467: (Each undeclared identifier is reported only once threads.c:467: for each function it appears in.) *** Error code 1 Anyone care to fix? :) The _POSIX_C_SOURCE #define in src/definitions.h was asking for a POSIX environment that was inconsistent with what the code was actually using. This patch makes it compile successfully, but I haven't tried running it. Another way of fixing it might be to #define _POSIX_C_SOURCE to 200112. --- src/definitions.h.old Mon Nov 18 23:13:13 2002 +++ src/definitions.h Mon Nov 18 23:10:41 2002 @@ -51,8 +51,10 @@ # define __USE_POSIX #endif +#if 0 #ifndef _POSIX_C_SOURCE #define _POSIX_C_SOURCE 199506L +#endif #endif /* This for freebsd (needed on 3.2 at least) */ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device permissions with DEVFS
On Mon, Nov 18, 2002 at 09:03:06PM -0800, Kris Kennaway wrote:
Something that needs to be addressed before 5.0 is the insecure
default permissions on many devices. For example, on my system, the
following devices have insecure permissions on 5.0 (but not on 4.x
with the default MAKEDEV settings):
crw-r--r-- 1 root operator 117, 0 Nov 18 14:49 acd0
crw-rw-rw- 1 root wheel 21, 1 Nov 18 14:49 psm0
crw-rw-rw- 1 root wheel 180, 0 Nov 18 14:49 nvidia0
(This one isn't part of FreeBSD, but I might as well report it now)
crw-rw-rw- 1 root wheel 30, 3 Nov 14 21:30 dsp0.0
crw-rw-rw- 1 root wheel 30, 0x00010003 Nov 8 23:38 dsp0.1
crw-rw-rw- 1 root wheel 30, 5 Nov 8 23:38 dspW0.0
crw-rw-rw- 1 root wheel 30, 0x00010005 Nov 8 23:38 dspW0.1
crw-rw-rw- 1 root wheel 30, 11 Nov 8 23:38 dspr0.0
These have the same permissions on 4.x, but they're still insecure
(unprivileged users can read from a microphone).
I'm sure there are others I have missed. Could everyone please check
their /dev (better, check the kernel source)?
I'm glad you brought this up... I'd like to see /dev/devctl made mode 600
instead of 644 because it does not look very robust and because only one
devctl can be open at a time.
The two other security/reliability bugs I can see are that the async
(ioctl FIOASYNC) and non-blocking (ioctl FIONBIO) flags are not cleared
between when one process closes the device and another opens it. Leaving
the non-blocking flag set confuses devd(8) causing it to exit immediately.
Leaving the async I/O flag set could cause the kernel to try to send
SIGIO with a stale thread pointer, possibly leading to a panic or the
wrong thread getting the signal.
I suggest this patch...
o More restrictive permissions on /dev/devctl (was 644, now 600)
o Clear nonblock and async flags across open/close
Index: subr_bus.c
===
RCS file: /x/freebsd/src/sys/kern/subr_bus.c,v
retrieving revision 1.116
diff -u -r1.116 subr_bus.c
--- subr_bus.c 7 Nov 2002 22:38:04 - 1.116
+++ subr_bus.c 19 Nov 2002 06:14:06 -
@@ -248,7 +248,7 @@
static void
devinit(void)
{
- devctl_dev = make_dev(dev_cdevsw, 0, 0, 0, 0644, devctl);
+ devctl_dev = make_dev(dev_cdevsw, 0, 0, 0, 0600, devctl);
mtx_init(devsoftc.mtx, dev mtx, devd, MTX_DEF);
cv_init(devsoftc.cv, dev cv);
TAILQ_INIT(devsoftc.devq);
@@ -261,6 +261,9 @@
return (EBUSY);
/* move to init */
devsoftc.inuse = 1;
+ devsoftc.nonblock = 0;
+ devsoftc.async = 0;
+ devsoftc.async_td = NULL;
return (0);
}
It looks like there are some races involving devsoftc, the softc mutex
should probably be locked around checking the inuse flag in devopen(),
around clearing it in devclose(), around setting async and async_td in
devioctl() FIOASYNC case, around checking inuse and async_td in
devaddq().
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Sign fixes for disklabel(8)
On Fri, Nov 15, 2002 at 03:59:25PM -0800, Julian Elischer wrote:
Here are the diffs to allow disklabel to correctly create partitions
1TB (up to 2TB is useful with UFS2) pending a different partitionning
scheme. It also allows you to correctly make smaller partitions beyond
1TB which is nice if you don't want to waste 800GB on an array :-)
permission to commit please?
(pending comments by others)
(also the sysinstall changes posted before)
(also the bluetooth code)
[...]
- int v, lineno = 0, errors = 0;
+ unsigned int v;
+ int lineno = 0, errors = 0;
int i;
[...]
- v = atoi(tp);
+ v = strtoul(tp, NULL, 0);
if ((unsigned)v = DKMAXTYPES)
fprintf(stderr, line %d:%s %d\n, lineno,
Warning, unknown disk type, v);
This cast is redundant since v is already unsigned. The fprintf() format
string needs to use %u instead of %d. Use 10 as the base argument to
stroul(), not 0 otherwise numbers with leading zeros will be interpreted
as octal.
[...]
- v = atoi(tp);
+ v = strtoul(tp, NULL, 0);
if (v = 0 || (v % DEV_BSIZE) != 0) {
fprintf(stderr,
line %d: %s: bad sector size\n,
Should be == 0, not = 0 since v is unsigned.
[...]
- v = atoi(tp);
+ v = strtoul(tp, NULL, 0);
if (v 0) {
fprintf(stderr, line %d: %s: bad %s\n,
lineno, tp, cp);
v 0 is impossible.
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
truss and KSE
While experimenting with the new libpthread, I found that if you run `truss' on a KSE process, both truss and its victim get into a weird state and don't respond to TERM, INT or QUIT signals. The truss proc dies if you send it the KILL signal, but the victim process cannot be killed. Stranger still, it's in the run state but not actually performing any work. I understand that KSE is still an experimental feature but I thought this was worth pointing out because it could be used as a local DoS and we are nearing 5.0-RELEASE. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss and KSE
On Thu, Nov 14, 2002 at 05:39:12AM -0800, David Xu wrote: What is your revision of kern_thread.c? revision 1.58 should fix this problem. I believe it was 1.57. I'll try with 1.58 and let you know if the problem is still there. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Upgrade of port audio/id3lib - stdc++ wchar support missing
On Thu, Nov 07, 2002 at 12:32:18AM +0100, Jens Rehsack wrote:
Hi,
there two open PR's (PR 44423 and PR 9) related to a problem with
audio/id3lib. I downloaded the new version (3.8.1) and made patches for
some files, so they should work fine with FreeBSD 5.0 (4.7 not tested, I
think gcc3 is required).
But I found out, that the libstdc++ which is installed by `make world`
doesn't have wchar-support enabled. I do not have expirience in changing
modules within freebsd world, so what do I have to do to add wchar-support?
Any help would be nice - I didn't had so much time for C/C++ programming
last year and I missed it. So I could do some more, too.
You could try the patch I've attached:
cd /usr/src
zcat c++-wchar.diff.gz | patch
cd gnu/lib/libstdc++
make
make install
It appears to work for simple programs like this:
#include fstream
#include iostream
#include string
using namespace std;
int
main()
{
wstring test(Lhello);
wofstream strm(test.txt);
strm test endl;
return (0);
}
... but I haven't tested much else; I haven't tried to build id3lib.
Tim
c++-wchar.diff.gz
Description: application/gunzip
Re: libc size
On Wed, Oct 30, 2002 at 12:46:15PM -0800, Nate Lawson wrote: After a discussion on cvs-all regarding size of our libc, I wrote a quick script to see where the problems are. A cursory glance at its output shows there are numerous things we can improve, including: * setproctitle(3) uses 4k of static scratch buffers when it could allocate these on the stack (let alone reducing the length of the proc title to something more reasonable than 2k). * vfwprintf and vfprintf are near duplicates of each other (in fact, the former is derived from the latter). Each uses 14k of text so this could be split in half by combining them and selecting different behavior with a flag. They are similar enough at the C source level to be merged into a single source file (in fact, Microsoft's C library does this), but they are probably not similar enough at the machine code level to merge and save text space. I have no idea how you could merge them in C to save a significant amount of text space given that sizeof(char) != sizeof(wchar_t). Basically, if you don't want wide character printf/scanf support in libc for some kind of embedded system, remove them from stdio/Makefile.inc. Nothing in the base system uses them, and few programs in the ports collection do either. You could also replace the locale stuff with the dummy versions from 4.4BSD if you don't want it (see OpenBSD's src/lib/libc/stdlib/multibyte.c, etc.). Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
groff -ms breakage
It seems groff is failing to format most of the roff documentation in src/share/doc, for example psd/15.yacc. Here is the output that groff -Tascii -ms produces on -current: ss..:44: warning: number register `0:LL' not defined ss..:44: warning: number register `0:ri' not defined ss..:44: warning: number register `0:pri' not defined ss..:44: warning: number register `0:LT' not defined ss..:44: warning: number register `0:li' not defined ss..:44: warning: number register `0:pli' not defined ss..:44: warning: `FAM' not defined ss..:44: warning: number register `0:PS' not defined ss..:44: warning: number register `0:VS' not defined [etc.] ss..:55: warning [p 1, 0.0i, div `cov*ab-div', 0.3i]: can't break line ss..:55: warning [p 1, 0.0i, div `cov*ab-div', 0.5i]: can't break line ss..:55: warning [p 1, 0.0i, div `cov*ab-div', 0.7i]: can't break line [etc.] Com- puter pro- gram input gen- er- ally has some struc- here is the output from the same command on 4.7-RELEASE: Computer program input generally has some structure; in fact, every computer program that does input can be thought of as defining an ``input language'' which it accepts. An input Reverting s.tmac to an earlier version does not seem to fix the problem. Also, postscript and html output formats seem much less broken than text. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: X problems 5.0... -RELEASE?
On Mon, Oct 14, 2002 at 01:00:46PM -0700, Kris Kennaway wrote: [...] Did anyone test -current with the various FP test suites people posted about last week? Yes. I ran paranoia from http://cm.bell-labs.com/netlib/paranoia/ and found that FP arithmethic is satisfactory when -O is not used, and no -march or -mcpu options are used. However, compiling with -O causes a lot of failures. Here are the messages: Seeking Underflow thresholds UfThold and E0. DEFECT: Difference underflows at a higher threshold than products. ... Can `Z = -Y' overflow? Trying it on Y = -inf . finds a FLAW: -(-Y) differs from Y. ... FAILURE: Comparisons involving +--inf, +-inf and +-4.94066e-324 are confused by Overflow. ... DEFECT: Badly unbalanced range; UfThold * V = -inf is too far from 1. SERIOUS DEFECT:X / X differs from 1 when X = -inf instead, X / X - 1/2 - 1/2 = nan . The summary message: The number of FAILUREs encountered = 1. The number of SERIOUS DEFECTs discovered = 1. The number of DEFECTs discovered = 2. The number of FLAWs discovered = 1. The arithmetic diagnosed has unacceptable Serious Defects. Potentially fatal FAILURE may have spoiled this program's subsequent diagnoses. It's worth noting that 4.7-RELEASE (w/ gcc 2.95.4) fails *more* test cases than -CURRENT when -O is used to compile paranoia. f77 -O seems to also generate bad code for dpara.f, the FORTRAN version of paranoia. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: src/games bikeshed time.
On Wed, Oct 09, 2002 at 11:29:08AM +0100, Mark Murray wrote: What remains? All the games that dm(6) oversees. Things like adventure(6), trek(6), battlestar(6) and so on. These are good candidates for ports IMO. Folks may want to play them, but there is no point in wasting time and space on them _by_default_. In some cases, better upgrades are already available in ports (hack -- nethack). I would like to make a port out of these and remove them from the base distribution. I'd like to see these removed only if nobody is willing to maintain them. Check lines 70-75 of src/games/larn/main.c for an example of how out of touch they are with what's considered to be good practice (5 buffer overflows in 6 lines of code). Merging in NetBSD and/or OpenBSD's changes would be a good place to start. I think rogue, hack, primes, fortune and worm are worth keeping, but I don't have the time or patience to maintain them. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tar problems with --fast-read
On Tue, Oct 08, 2002 at 10:01:09AM -0700, Gordon Tetlow wrote: I was trying out the fast-read feature of tar and got the following: gtetlow@roark:~$ touch testa testb gtetlow@roark:~$ tar cf test.tar testa testb gtetlow@roark:~$ tar tf test.tar --fast-read testa testa Terminated gtetlow@roark:~$ Further investigtion shows that there is a SIGPIPE being delivered. Any ideas? Looks like it's doing kill(0, SIGTERM) and killing itself when fast-read is used and there is no child process (gzip). This is consistent with the fact that if you add gzip test.tar between your second and third command, and change the third to tar tfz ..., it doesn't seem to terminate itself. Try this patch: Index: buffer.c === RCS file: /home/tim/freebsd/src/contrib/tar/src/buffer.c,v retrieving revision 1.4 diff -u -r1.4 buffer.c --- buffer.c2 Oct 2002 08:42:06 - 1.4 +++ buffer.c9 Oct 2002 01:36:48 - @@ -1339,7 +1339,7 @@ might become clever enough to just stop working, once there is no more work to do, we might have to revise this area in such time. */ - if (fast_read_option namelist_freed) + if (fast_read_option namelist_freed child_pid 0) kill(child_pid, SIGTERM); if (access_mode == ACCESS_READ Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Tool make ordering, or something
On Tue, Oct 01, 2002 at 10:37:26PM -0700, Pete Carah wrote: There is a 't' modifier to a format in bin/sh that just crept in; it prevents a cross buildworld under stable without NO_WERROR. Perhaps the compiler+libc needs to be built first? (and does sh need to be a build tool; I'd hope the make scripts stuck to a fairly least-common-denominator shell syntax?) The best we can do to src/bin/sh is to do something like this: #ifndef BOOTSTRAPPING fmtstr(s, 64, [%td] , jp - jobtab + 1); #else fmtstr(s, 64, [%lld] , (long long)(jp - jobtab + 1)); #endif This isn't a particularly good example, because jp - jobtab + 1 is almost always less than 1000. I think there are only 3 places that use new printf format specifiers that aren't in -stable: miscbltin.c lines 429,455, jobs.c line 224. I don't know why sh needs to be a build tool anymore, but I'll probably just add the #ifdef's for the moment. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Tue, Oct 01, 2002 at 01:11:04AM -0700, Dag-Erling Smorgrav wrote: === bin/sh cc1: warnings being treated as errors /h/des/src/bin/sh/mksyntax.c: In function `digit_convert': /h/des/src/bin/sh/mksyntax.c:396: warning: int format, different type arg (arg 3) *** Error code 1 Stop in /h/des/src/bin/sh. *** Error code 1 Already fixed. This gives me a good excuse to axe the printf() clone in output.c, too. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: need current kernel
On Mon, Sep 23, 2002 at 11:38:01AM +0200, Christoph Kukulies wrote: I have the signal 12 hen-egg problem. cannot install a newly built kernel because of sh ../../conf/newvers.sh GENERIC *** Signal 12 I tried with the 4.7 mini iso CD image, I also could boot the CD and do the upgrade but the syscall kernel change seems to bee more recent. Could someone send me a -current GENERIC kernel? Or does anybody have a better idea how to get around this? Try this one: http://snapshots.jp.freebsd.org:8021/pub/FreeBSD/snapshots/i386/livetree/5-LATEST/boot/kernel/ Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc error question answered (partly)
On Sat, Sep 21, 2002 at 08:21:15PM -0700, walt wrote: walt wrote: My guess is that the syntax of 'sort' has changed since lorder was modified in March of 2001(?) David Wolfskill just pointed out to me that the behavior of 'sort' is completely different in -STABLE, which I've just confirmed. Does anyone else see this behavior in -CURRENT? What happens if you type 'sort +1' on your -CURRENT machine? The +POS1 -POS2 syntax for specifying sort keys was (from memory) marked as obsolescent in IEEE Std. 1003.2-1992 and removed (and disallowed) in 1003.1-2001. Many applications (like lorder) use the old syntax, so by default GNU sort does not conform to the 2001 standard and accepts the old syntax. If you set _POSIX2_VERSION=200112 in the environment before running GNU sort, it will try to conform to the newer standard and treat +pos as a filename instead of a sort key. The version of sort in -stable was written before the 2001 standard and doesn't disable the obsolescent sort key syntax. So the only explanation that I can think of is that you've got _POSIX2_VERSION set in the environment: $ _POSIX2_VERSION=200112 sort +1 sort: open failed: +1: No such file or directory lorder should probably get changed to use the new syntax some time too. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Who broke sort(1) ?
On Sun, Sep 22, 2002 at 01:43:38PM -0700, Steve Kargl wrote: On Sun, Sep 22, 2002 at 10:17:41PM +0200, Poul-Henning Kamp wrote: flat# date | sort +5n sort: open failed: +5n: No such file or directory This breaks the build in libncurses... POSIX via wollman. See revision 1.58 of /usr/include/unistd.h, i.e., /* Define the versions we target for compliance. */ #define _POSIX_VERSION 200112L #define _POSIX2_VERSION 200112L See email in the last 24 hours from walt about problems building libc and Tim Robbins response to the problem. I didn't read src/contrib/gnu-sort/lib/posixver.c carefully enough to notice that it uses the the _POSIX2_VERSION macro, I thought it only used the environment variable by that same name. A workaround might be to #undef _POSIX2_VERSION after #include'ing unistd.h in posixver.c but I don't think that would be correct. It's probably better to either change all the scripts that use the obsolescent +pos -pos syntax to use the new -k syntax or to change _POSIX2_VERSION back to whatever it was before. I think the second is more realistic. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: missing 'wcscoll'.
On Fri, Sep 13, 2002 at 10:22:09AM +0100, Josef Karthauser wrote: I've not looked too deeply as to the cause, but I'm hoping someone here can shed some light on it for me. I'm having trouble building openjade from the ports on -current. The build bombs out with: LangObj.cxx: In member function `virtual bool RefLangObj::areEquivalent(const StringC, const StringC, short unsigned int) const': LangObj.cxx:122: `wcsxfrm' undeclared (first use this function) wcsxfrm() is not implemented. LangObj.cxx:122: (Each undeclared identifier is reported only once for each function it appears in.) LangObj.cxx: In member function `virtual bool RefLangObj::isLess(const StringC, const StringC) const': LangObj.cxx:146: `wcscoll' undeclared (first use this function) wcscoll() is not implemented. gmake[2]: *** [LangObj.lo] Error 1 gmake[2]: Leaving directory `/data/ports/workdirs/usr/ports/textproc/openjade/work/openjade-1.3.1/style' gmake[1]: *** [style] Error 2 gmake[1]: Leaving directory `/data/ports/workdirs/usr/ports/textproc/openjade/work/openjade-1.3.1' gmake: *** [all] Error 2 *** Error code 2 Is this a known problem (it builds find under -stable), or is something spammed at my end? Some GNU (and GNU-style) programs assume that the presence of the restartable multibyte/wide character functions (mbsrtowcs(), wcsrtombs()) means that all of the other ISO C90 Amd.1 wide character functions exist. The restartable mb/wc functions were added recently and do not exist in -stable. Making blind assumptions like this defeats the purpose of using autoconf at all.. a hack solution is probably to tell it not to use wcscoll/wcsxfrm by editing config.h. The real solution is for us to implement these functions, and for whoever wrote the autoconf gunk to be more careful. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel from latest cvsup refuses to boot. - hangs
On Thu, Sep 12, 2002 at 02:46:12AM +0530, Sid Carter wrote: Hi Folks, I am still unable to boot into the kernel from the latest cvsup. [...] System Info -- [...] CPU: Pentium III/Pentium III Xeon/Celeron (996n77-MHz 686-class CPU) ^ Origin } GenuineIntel` Id = 0868a Stepping = 10 ^ ^ Check your optimisation flags -- it looks like the code that's been generated for kvprintf() (?) is incorrect, although I've only seen this happen in userland with vfprintf() and CFLAGS=-O2 before. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
openssh and lastlog
I've been seeing these messages for months.. Aug 31 20:19:29 cinq sshd[2342]: /var/log/lastlog: Permission denied .. because sshd has dropped root privileges by the time pam_lastlog tries to log the message. I realise this was discussed on this list about 2 months ago, but it hasn't been fixed yet. Why not just go back to using openssh's built-in lastlog code until pam_lastlog can be made to work from within openssh? Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Signal handling changes
It looks like there are still problems with SIGSTOP/SIGCONT signal handling.
With a kernel/world from August 24 and using csh or sh (choice of shell
is probably not relevant), running sleep 30 then suspending it with ^Z
then continuing it with fg causes the sleep process to exit as soon
as it's continued, instead of sleeping for the remainder of the interval
as it does on 4.6.2.
Here's a test program that demonstrates what I mean.. the sleep(1) call in
the parent process is just to avoid a race and isn't part of the bug.
4.6.2-RELEASE i386
5.0-CURRENT i386 built July 1
5.0-CURRENT alpha built July 19
OpenBSD 2.9 i386
SunOS 5.7 sparc
$ ./a.out
30.00 seconds elapsed
5.0-CURRENT i386 built August 24:
$ ./a.out
1.00 seconds elapsed
(wish I had more datapoints for the `broken' case)
#include err.h
#include signal.h
#include time.h
#include unistd.h
int
main(int argc, char *argv[])
{
pid_t pid;
int status;
time_t before, after;
time(before);
if ((pid = fork()) == -1)
err(1, fork);
else if (pid == 0) {
sleep(30);
_exit(0);
}
sleep(1);
kill(pid, SIGSTOP);
kill(pid, SIGCONT);
while (wait(status) != pid)
;
time(after);
printf(%f seconds elapsed\n, difftime(after, before));
exit(0);
}
My first idea was that it had something to do with siginterrupt(), but
errno == 0 after the sleep(3) returns prematurely.
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: WTF is going on? pipe breakage, patch(1) breakage??
FWIW, the pipe breakage seems to have been caused by /bin/sh freeing the job table (jobs.c lines 744-746) then later using a value in the freed region as an argument to setpgid() and tcsetpgrp() (jobs.c lines 753-760) when the job had more than one process in it (a pipeline). phkmalloc was overwriting the freed memory with garbage, causing tcsetpgrp() and setpgid() to be called with bogus process group ID's. I'm going to commit the fix for this tomorrow after I've tested it some more. In the meantime, ln -sf j /etc/malloc.conf will work around the error. The bug seems to have been there since at least 4.4BSD-Lite. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: world broken
On Thu, Aug 15, 2002 at 03:18:59PM -0700, Alfred Perlstein wrote: /usr/obj/vol/share/src/i386/usr/include/stdbool.h:41: warning: useless keyword o r type name in empty declaration /usr/obj/vol/share/src/i386/usr/include/stdbool.h:41: warning: empty declaration I get those a lot now... please fix. This happens because GCC 3 doesn't define __STDC_VERSION__ unless you specify -std=something, whereas 2.95 defines it to 199409L if no -std option is given. I'm not quite sure how to check for this. Perhaps this would work: #if __STDC_VERSION__ 199901L __GNUC__ 3 typedef int _Bool; #endif GCC 3 appears to declare _Bool regardless of any -std option. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Tue, Aug 13, 2002 at 11:54:06PM -0700, Terry Lambert wrote:
Tim Robbins wrote:
On Tue, Aug 13, 2002 at 05:04:20PM -0700, Terry Lambert wrote:
Both different reports have been from Tim Robbins. It may
be that he has a local problem, and that his local problem
is greatly confusing this discussion.
Unfortunately, this is not a local problem -- I can reproduce it locally
(i386, world/kernel from yesterday), on panther.freebsd.org (sparc64, kernel
built July 19), and beast.freebsd.org (alpha, also built July 19). I cannot
reproduce it on ref5 (i386, built July 1).
If you update to the very most recent current, do the problems
occur? It's currently August 13th, which means that you are a
month behind on the machines with the problem, and a month and
a half behind on the other.
The kernel/world I am running locally is less than 24 hours old.
If both problems still occur with the most recent current, do
they go away if you back out *just* the PAM changes?
This has nothing to do with PAM. Here is a simple program which behaves
differently between 4.6-RELEASE and 5.0-CURRENT. I don't know which
of the two behaviours is correct.
#include sys/types.h
#include sys/wait.h
#include err.h
#include stdio.h
#include signal.h
#include string.h
#include unistd.h
int
main(int argc, char *argv[])
{
pid_t pid;
int status;
switch (pid = vfork()) {
case -1:
err(1, fork);
case 0:
execl(/bin/csh, csh, NULL);
err(1, csh);
default:
fprintf(stderr, (waiter) waiting\n);
while (waitpid(pid, status, WUNTRACED) != -1 WIFSTOPPED(status)) {
fprintf(stderr, (waiter) stopping ourself\n);
killpg(0, SIGSTOP);
fprintf(stderr, (waiter) continuing child\n);
killpg(pid, SIGCONT);
fprintf(stderr, (waiter) waiting\n);
}
}
return (0);
}
%%
4.6.1-RELEASE-p10, OpenBSD 3.0:
%set prompt=root%
root% ./waiter
(waiter) waiting
%suspend
Suspended
root% fg
./waiter
%
5.0-CURRENT built August 14 (today):
%set prompt=root%
root% ./waiter
(waiter) waiting
%suspend
Suspended
root% fg
./waiter
%(waiter) stopping ourself
Suspended (signal)
root%
Linux behaves differently to both, but the change in behaviour does not
seem to make it stop working.
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: WTF is going on? pipe breakage, patch(1) breakage??
I'm definitely seeing problems with pipes, and major problems with the tty process group/session/job control/etc. code. I've had commands like: cvs diff -Nu | less terminate after showing one screenful with cvs recieving SIGPIPE; the same command sometimes causes my login shell to get sent SIGTTOU (which causes sshd to disconnect me). Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Tue, Aug 13, 2002 at 06:14:38AM -0700, David Xu wrote: --- Terry Lambert [EMAIL PROTECTED] wrote: I did. It's still an order of operation problem in the kernel during fork(), as Bruce pointed out in a later posting (so me pointing it out here is probably redundant... 8-)). I still think other code is going to have the problem, too, so changing su alone doesn't fix things. Better to not deliver the tty output stopped signal. -- Terry Don't touch tty code, if you change, you'll break more code, current problem is just because su forks a child process and want to take over some job control work from shell, it is of course not a easy job. the problem does not exist in STABLE branch because su does not fork. What about chpass, vipw, and the other pw_edit() consumers? vipw works correctly wrt suspending with ^Z on 4.6-RELEASE, but does not on -CURRENT. As far as I can see, pw_edit()'s logic has not been changed. This is a slightly different case to that of the shell suspending _itself_, but I think it's similar enough that the solution may be the same. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Tue, Aug 13, 2002 at 05:04:20PM -0700, Terry Lambert wrote: Both different reports have been from Tim Robbins. It may be that he has a local problem, and that his local problem is greatly confusing this discussion. Unfortunately, this is not a local problem -- I can reproduce it locally (i386, world/kernel from yesterday), on panther.freebsd.org (sparc64, kernel built July 19), and beast.freebsd.org (alpha, also built July 19). I cannot reproduce it on ref5 (i386, built July 1). Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Sun, Aug 11, 2002 at 06:54:42PM -0700, Julian Elischer wrote:
I am forwarding this to -current as I think it needs more neurons on it..
I am presently unable to spend any due to work commitments, and due to a sort-of
personal confusion about tis stuff anyhow..
David Xu wrote:
does anyone believe that su behaviours correctly?
we are talking that kernel has bug to handle job control
but I found that the issue may not related to signal handling
problem, but related to su or csh's job control.
I see this piece of code in su.c:
switch (child_pid) {
default:
while ((ret_pid = waitpid(child_pid, statusp, WUNTRACED)) !=
eca-1) {
if (WIFSTOPPED(statusp)) {
child_pgrp = tcgetpgrp(1);
kill(getpid(), SIGSTOP);
tcsetpgrp(1, child_pgrp);
kill(child_pid, SIGCONT);
statusp = 1;
continue;
}
break;
}
I have traced down su. In my test, the su process forked a
child process, child process pid is 873 while parent pid is 872.
these code are in question, I found that tcgetpgrp(1) really
returns parent su pid, it is 872, parent su process
then suspends itself until login shell unsuspends it,
when it resumes, I have inserted another tcgetpgrp(1) after it resumes,
and found that it was 873, it was child su process pid! not 872,
because parent su was not in foreground group, when it called tcsetpgrp(1, 872),
it got a SIGTTOU and suspended there, the SIGCONT was not sent out.
so the code's behaviour is not what the author's want, and all job
control gets weird. I suguest this job control assumption should be removed,
strange thing is why su calls fork()? why doesn't call directly execvl()?
I don't see su calls fork() in OpenBSD.
I compiled GNU sh-utils 1.16 with Redhat's PAM patch on -current. It works
well and does not seem to have the bugs w/ csh's suspend or kill -STOP $$
that I complained about earlier.
This means that either our su is broken, or the different way Redhat
has implemented it is managing to avoid a kernel bug of ours.
I've extracted Redhat's patch from the RPM to make it easier to get:
http://people.freebsd.org/~tjr/sh-utils-1.16-pam.patch
The patch applies cleanly to sh-utils-1.16 (find it on a GNU mirror),
and su gets built - the build process dies at `test'.
The key differences with our implementation seem to be that they block
all allowed signals except SIGALRM and SIGTERM with sigprocmask() after the
fork on the parent side (race?), and they don't mess around with
tc[gs]etpgrp().
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
