From killing at multiplay.co.uk Wed Apr 1 11:05:22 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Wed Apr 1 11:05:29 2009 Subject: How to increase the max pty's on Freebsd 7.0? Message-ID: How can I increase the maximum number or ptys available on FreeBSD 7.0? It seems that currently the machine is maxing out at 512 but there is still loads of capacity left on the machine. Ideally would like to double at least the number of ttys available, any help would be most appreciated. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From killing at multiplay.co.uk Wed Apr 1 11:29:26 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Wed Apr 1 11:29:33 2009 Subject: How to increase the max pty's on Freebsd 7.0? References: Message-ID: <57E2F83B3290402281CDBA24485427AE@multiplay.co.uk> I knew his sounded very familiar, seems I asked the same question back in 2007 for 5.4 just it was capped at 256: http://lists.freebsd.org/mailman/htdig/freebsd-hackers/2007-October/021852.html I'm sure I also remember saying this limit had been removed in 7.x but looking in the source for pqrsPQRS it seems there are several places where this still hard coded:- contrib/telnet/telnetd/sys_term.c: for (cp = "pqrsPQRS"; *cp; cp++) { lib/libc/stdlib/grantpt.c:#define PTY_DEV1 "pqrsPQRSlmnoLMNO" lib/libutil/pty.c: for (cp1 = "pqrsPQRSlmnoLMNO"; *cp1; cp1++) { sys/kern/tty_pty.c:static const char names[] = "pqrsPQRSlmnoLMNOtuvwTUVWxyzXYZ"; sys/kern/tty_pty.c: * pts == /dev/tty[pqrsPQRSlmnoLMNO][0123456789abcdefghijklmnopqrstuv] sys/kern/tty_pty.c: * ptc == /dev/pty[pqrsPQRSlmnoLMNO][0123456789abcdefghijklmnopqrstuv] usr.sbin/ac/ac.c: strchr("pqrsPQRS", usr.ut_line[3]) != 0 || So the questions are:- 1. Is the fix to this still to just to update these settings? 2. Is there any significance to the upper case lower case thing? 3. Are there any other restrictions on the letters that can be used? ----- Original Message ----- From: "Steven Hartland" > How can I increase the maximum number or ptys available on FreeBSD 7.0? > > It seems that currently the machine is maxing out at 512 but there is > still loads of capacity left on the machine. > > Ideally would like to double at least the number of ttys available, > any help would be most appreciated. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From trasz at FreeBSD.org Wed Apr 1 11:38:47 2009 From: trasz at FreeBSD.org (Edward Tomasz Napierala) Date: Wed Apr 1 11:38:54 2009 Subject: Filesystem orphaning. Message-ID: <20090401182502.GA13651@pin.if.uz.zgora.pl> Attached is a patch that adds filesystem orphaning. What it means, from the user point of view, is that when a disk device containing mounted filesystem gets removed from the system, all filesystem operations return immediately with an error, contents of the filesystem become invisible and inaccessible, and the filesystem gets marked as 'orphaned' in the mount(8) output. The only thing you can do after that is to unmount the filesystem. There are two problems. First, there is a race condition between registering the callback from the mount routine and device disappearing, causing the callback to be called. I'm not sure how serious it is; vfs_orphan() routine contains code to prevent it from messing things up when called against a filesystem that hasn't been fully mounted yet. Second problem is that vflush(9) with FORCECLOSE isn't quite safe. Right now the only situation it's being called is "umount -f"; this patch would add a second case. I'm little short of time, so I won't be able to work on it anytime soon. If you like the idea - please do whatever is needed to get it to commitable state. This patch was developed during project sponsored by FreeBSD Foundation. Index: sbin/mount/mount.c =================================================================== --- sbin/mount/mount.c (revision 190561) +++ sbin/mount/mount.c (working copy) @@ -112,6 +112,7 @@ static struct opt { { MNT_MULTILABEL, "multilabel" }, { MNT_ACLS, "acls" }, { MNT_GJOURNAL, "gjournal" }, + { MNT_ORPHANED, "orphaned" }, { 0, NULL } }; Index: sys/ufs/ffs/ffs_vfsops.c =================================================================== --- sys/ufs/ffs/ffs_vfsops.c (revision 190561) +++ sys/ufs/ffs/ffs_vfsops.c (working copy) @@ -601,6 +601,15 @@ loop: */ static int sblock_try[] = SBLOCKSEARCH; +static void +ffs_orphan_callback(struct g_consumer *cp, void *user) +{ + struct mount *mp; + + mp = (struct mount *)user; + vfs_orphan(mp); +} + /* * Common code for mount and mountroot */ @@ -629,9 +638,13 @@ ffs_mountfs(devvp, mp, td) dev = devvp->v_rdev; dev_ref(dev); + vfs_ref(mp); DROP_GIANT(); g_topology_lock(); error = g_vfs_open(devvp, &cp, "ffs", ronly ? 0 : 1); + if (error == 0) + g_vfs_register_callback(cp, ffs_orphan_callback, + mp, G_CB_ORPHAN); /* * If we are a root mount, drop the E flag so fsck can do its magic. @@ -923,6 +936,7 @@ out: free(ump, M_UFSMNT); mp->mnt_data = NULL; } + vfs_rel(mp); dev_rel(dev); return (error); } @@ -1110,6 +1124,7 @@ ffs_unmount(mp, mntflags, td) g_topology_unlock(); PICKUP_GIANT(); vrele(ump->um_devvp); + vfs_rel(mp); dev_rel(ump->um_dev); mtx_destroy(UFS_MTX(ump)); if (mp->mnt_gjprovider != NULL) { Index: sys/kern/vfs_syscalls.c =================================================================== --- sys/kern/vfs_syscalls.c (revision 190561) +++ sys/kern/vfs_syscalls.c (working copy) @@ -326,6 +326,8 @@ kern_statfs(struct thread *td, char *path, enum ui sp->f_version = STATFS_VERSION; sp->f_namemax = NAME_MAX; sp->f_flags = mp->mnt_flag & MNT_VISFLAGMASK; + if (mp->mnt_kern_flag & MNTK_ORPHANED) + sp->f_flags |= MNT_ORPHANED; error = VFS_STATFS(mp, sp, td); if (error) goto out; @@ -415,6 +417,8 @@ kern_fstatfs(struct thread *td, int fd, struct sta sp->f_version = STATFS_VERSION; sp->f_namemax = NAME_MAX; sp->f_flags = mp->mnt_flag & MNT_VISFLAGMASK; + if (mp->mnt_kern_flag & MNTK_ORPHANED) + sp->f_flags |= MNT_ORPHANED; error = VFS_STATFS(mp, sp, td); if (error) goto out; @@ -515,6 +519,8 @@ kern_getfsstat(struct thread *td, struct statfs ** sp->f_version = STATFS_VERSION; sp->f_namemax = NAME_MAX; sp->f_flags = mp->mnt_flag & MNT_VISFLAGMASK; + if (mp->mnt_kern_flag & MNTK_ORPHANED) + sp->f_flags |= MNT_ORPHANED; /* * If MNT_NOWAIT or MNT_LAZY is specified, do not * refresh the fsstat cache. MNT_NOWAIT or MNT_LAZY @@ -4662,6 +4668,8 @@ kern_fhstatfs(struct thread *td, fhandle_t fh, str sp->f_version = STATFS_VERSION; sp->f_namemax = NAME_MAX; sp->f_flags = mp->mnt_flag & MNT_VISFLAGMASK; + if (mp->mnt_kern_flag & MNTK_ORPHANED) + sp->f_flags |= MNT_ORPHANED; error = VFS_STATFS(mp, sp, td); if (error == 0) *buf = *sp; Index: sys/kern/vfs_subr.c =================================================================== --- sys/kern/vfs_subr.c (revision 190561) +++ sys/kern/vfs_subr.c (working copy) @@ -1084,7 +1084,7 @@ insmntque1(struct vnode *vp, struct mount *mp, #endif MNT_ILOCK(mp); if ((mp->mnt_kern_flag & MNTK_NOINSMNTQ) != 0 && - ((mp->mnt_kern_flag & MNTK_UNMOUNTF) != 0 || + ((mp->mnt_kern_flag & (MNTK_UNMOUNTF | MNTK_ORPHANED)) != 0 || mp->mnt_nvnodelistsize == 0)) { locked = VOP_ISLOCKED(vp); if (!locked || (locked == LK_EXCLUSIVE && @@ -1092,6 +1092,8 @@ insmntque1(struct vnode *vp, struct mount *mp, MNT_IUNLOCK(mp); if (dtr != NULL) dtr(vp, dtr_arg); + if ((mp->mnt_kern_flag & MNTK_ORPHANED) != 0) + return (ENXIO); return (EBUSY); } } @@ -2875,6 +2877,7 @@ DB_SHOW_COMMAND(mount, db_show_mount) MNT_KERN_FLAG(MNTK_MPSAFE); MNT_KERN_FLAG(MNTK_NOKNOTE); MNT_KERN_FLAG(MNTK_LOOKUP_SHARED); + MNT_KERN_FLAG(MNTK_ORPHANED); #undef MNT_KERN_FLAG if (flags != 0) { if (buf[0] != '\0') @@ -4249,6 +4252,45 @@ vfs_read_dirent(struct vop_readdir_args *ap, struc } /* + * Mark the filesystem as orphaned. Usually called when the device + * that contained the filesystem goes away. + */ +void +vfs_orphan(struct mount *mp) +{ + int error; + struct mount *tmp; + + error = vfs_busy(mp, MBF_NOWAIT); + /* If the filesystem is being unmounted, do nothing. */ + if (error) + return; + + /* Prevent all future vnode operations from succeeding. */ + MNT_ILOCK(mp); + mp->mnt_kern_flag |= (MNTK_ORPHANED | MNTK_NOINSMNTQ); + MNT_IUNLOCK(mp); + + /* + * Don't try to call vflush on a mount structure that is not + * fully initialized yet. Assume that the mount is initialized + * if it can be found on the mountlist. + */ + mtx_lock(&mountlist_mtx); + TAILQ_FOREACH(tmp, &mountlist, mnt_list) { + if (tmp == mp) + break; + } + mtx_unlock(&mountlist_mtx); + if (tmp == NULL) { + vfs_unbusy(mp); + return; + } + vflush(mp, 0, FORCECLOSE, curthread); + vfs_unbusy(mp); +} + +/* * Mark for update the access time of the file if the filesystem * supports VOP_MARKATIME. This functionality is used by execve and * mmap, so we want to avoid the I/O implied by directly setting Index: sys/fs/msdosfs/msdosfs_vfsops.c =================================================================== --- sys/fs/msdosfs/msdosfs_vfsops.c (revision 190561) +++ sys/fs/msdosfs/msdosfs_vfsops.c (working copy) @@ -403,6 +403,15 @@ msdosfs_mount(struct mount *mp, struct thread *td) return (0); } +static void +msdosfs_orphan_callback(struct g_consumer *cp, void *user) +{ + struct mount *mp; + + mp = (struct mount *)user; + vfs_orphan(mp); +} + static int mountmsdosfs(struct vnode *devvp, struct mount *mp) { @@ -425,9 +434,13 @@ mountmsdosfs(struct vnode *devvp, struct mount *mp dev = devvp->v_rdev; dev_ref(dev); + vfs_ref(mp); DROP_GIANT(); g_topology_lock(); error = g_vfs_open(devvp, &cp, "msdosfs", ronly ? 0 : 1); + if (error == 0) + g_vfs_register_callback(cp, msdosfs_orphan_callback, + mp, G_CB_ORPHAN); g_topology_unlock(); PICKUP_GIANT(); VOP_UNLOCK(devvp, 0); @@ -766,6 +779,7 @@ error_exit: free(pmp, M_MSDOSFSMNT); mp->mnt_data = NULL; } + vfs_rel(mp); dev_rel(dev); return (error); } @@ -831,6 +845,7 @@ msdosfs_unmount(struct mount *mp, int mntflags, st g_topology_unlock(); PICKUP_GIANT(); vrele(pmp->pm_devvp); + vfs_rel(mp); dev_rel(pmp->pm_dev); free(pmp->pm_inusemap, M_MSDOSFSFAT); if (pmp->pm_flags & MSDOSFS_LARGEFS) Index: sys/geom/geom_vfs.c =================================================================== --- sys/geom/geom_vfs.c (revision 190561) +++ sys/geom/geom_vfs.c (working copy) @@ -34,6 +34,8 @@ __FBSDID("$FreeBSD$"); #include #include #include /* XXX Temporary for VFS_LOCK_GIANT */ +#include +#include #include #include @@ -130,17 +132,78 @@ g_vfs_strategy(struct bufobj *bo, struct buf *bp) g_io_request(bip, cp); } +struct g_vfs_cb { + struct g_consumer *cb_consumer; + int cb_event; + void (*cb_callback)(struct g_consumer *, void *); + void *cb_userptr; + struct task cb_task; +}; + +/* + * When registering the callback from the mount routine, the topology lock + * is being taken while holding devvp vnode lock. The callback routine + * would probably try to grab devvp vnode lock, and executing it from + * g_event context, while holding topology lock, would cause LOR. To make + * sure this doesn't happen, we call the callback from taskqueue. + */ static void +g_vfs_cb_func(void *context, int pending) +{ + struct g_vfs_cb *cb; + + cb = context; + + KASSERT(cb->cb_event == G_CB_ORPHAN, + ("found callback for unknown event")); + + (cb->cb_callback)(cb->cb_consumer, cb->cb_userptr); +} + +void +g_vfs_register_callback(struct g_consumer *cp, + void (callback)(struct g_consumer *, void *), void *userptr, int event) +{ + struct g_vfs_cb *cb; + + g_topology_assert(); + + KASSERT(event >= 0 && event <= G_CB_LAST, + ("invalid callback event flag")); + cb = cp->private; + KASSERT(cb[event].cb_callback == NULL, + ("callback already registered")); + + cb[event].cb_callback = callback; + cb[event].cb_userptr = userptr; + cb[event].cb_consumer = cp; + cb[event].cb_event = event; + TASK_INIT(&(cb[event].cb_task), 0, g_vfs_cb_func, &(cb[event])); +} + +static void g_vfs_orphan(struct g_consumer *cp) { struct g_geom *gp; struct bufobj *bo; + struct g_vfs_cb *cb; + int error; g_topology_assert(); gp = cp->geom; bo = gp->softc; + cb = cp->private; + g_trace(G_T_TOPOLOGY, "g_vfs_orphan(%p(%s))", cp, gp->name); + + if (cb != NULL && cb[G_CB_ORPHAN].cb_callback != NULL) { + error = taskqueue_enqueue(taskqueue_thread, + &(cb[G_CB_ORPHAN].cb_task)); + KASSERT(error == 0, ("taskqueue_enqueue(9) failed.")); + taskqueue_drain(taskqueue_thread, &(cb[G_CB_ORPHAN].cb_task)); + } + if (cp->acr > 0 || cp->acw > 0 || cp->ace > 0) g_access(cp, -cp->acr, -cp->acw, -cp->ace); g_detach(cp); @@ -169,6 +232,8 @@ g_vfs_open(struct vnode *vp, struct g_consumer **c gp = g_new_geomf(&g_vfs_class, "%s.%s", fsname, pp->name); cp = g_new_consumer(gp); g_attach(cp, pp); + cp->private = g_malloc(sizeof(struct g_vfs_cb[G_CB_LAST + 1]), + M_WAITOK | M_ZERO); error = g_access(cp, 1, wr, 1); if (error) { g_wither_geom(gp, ENXIO); @@ -195,6 +260,8 @@ g_vfs_close(struct g_consumer *cp) g_topology_assert(); + g_free(cp->private); + cp->private = NULL; gp = cp->geom; bo = gp->softc; bufobj_invalbuf(bo, V_SAVE, 0, 0); Index: sys/geom/geom_vfs.h =================================================================== --- sys/geom/geom_vfs.h (revision 190561) +++ sys/geom/geom_vfs.h (working copy) @@ -35,8 +35,13 @@ struct buf; extern struct buf_ops *g_vfs_bufops; +#define G_CB_ORPHAN 1 +#define G_CB_LAST G_CB_ORPHAN + void g_vfs_strategy(struct bufobj *bo, struct buf *bp); int g_vfs_open(struct vnode *vp, struct g_consumer **cpp, const char *fsname, int wr); void g_vfs_close(struct g_consumer *cp); +void g_vfs_register_callback(struct g_consumer *cp, + void (callback)(struct g_consumer *, void *), void *user, int event); #endif /* _GEOM_GEOM_VFS_H_ */ Index: sys/sys/mount.h =================================================================== --- sys/sys/mount.h (revision 190561) +++ sys/sys/mount.h (working copy) @@ -250,14 +250,17 @@ void __mnt_vnode_markerfree(struct vnode #define MNT_EXPUBLIC 0x20000000 /* public export (WebNFS) */ /* - * Flags set by internal operations, - * but visible to the user. - * XXX some of these are not quite right.. (I've never seen the root flag set) + * Flags set by internal operations, but visible to the user. + * Note that MNT_ORPHANED flag is never actually set on mnt_flag field + * in struct mount; it's only set on f_flags in struct statfs when + * MNTK_ORPHANED is set. We cannot use MNT_ORPHANED instead of MNTK_ORPHANED + * due to missing locking of mnt_flag. */ #define MNT_LOCAL 0x00001000 /* filesystem is stored locally */ #define MNT_QUOTA 0x00002000 /* quotas are enabled on filesystem */ #define MNT_ROOTFS 0x00004000 /* identifies the root filesystem */ #define MNT_USER 0x00008000 /* mounted by a user */ +#define MNT_ORPHANED 0x00020000 /* MNTK_ORPHANED is set */ #define MNT_IGNORE 0x00800000 /* do not show entry in df */ /* @@ -273,7 +276,8 @@ void __mnt_vnode_markerfree(struct vnode MNT_ROOTFS | MNT_NOATIME | MNT_NOCLUSTERR| \ MNT_NOCLUSTERW | MNT_SUIDDIR | MNT_SOFTDEP | \ MNT_IGNORE | MNT_EXPUBLIC | MNT_NOSYMFOLLOW | \ - MNT_GJOURNAL | MNT_MULTILABEL | MNT_ACLS) + MNT_GJOURNAL | MNT_MULTILABEL | MNT_ACLS | \ + MNT_ORPHANED) /* Mask of flags that can be updated. */ #define MNT_UPDATEMASK (MNT_NOSUID | MNT_NOEXEC | \ @@ -289,6 +293,8 @@ void __mnt_vnode_markerfree(struct vnode * XXX: These are not STATES and really should be somewhere else. * XXX: MNT_BYFSID collides with MNT_ACLS, but because MNT_ACLS is only used for * mount(2) and MNT_BYFSID is only used for unmount(2) it's harmless. + * XXX: MNT_DELEXPORT collides with MNT_ORPHANED, but MNT_DELEXPORT is never + * used in mnt_flag, only for ex_flags. */ #define MNT_UPDATE 0x00010000 /* not a real mount, just an update */ #define MNT_DELEXPORT 0x00020000 /* delete export host lists */ @@ -325,6 +331,7 @@ void __mnt_vnode_markerfree(struct vnode #define MNTK_DRAINING 0x00000010 /* lock draining is happening */ #define MNTK_REFEXPIRE 0x00000020 /* refcount expiring is happening */ #define MNTK_EXTENDED_SHARED 0x00000040 /* Allow shared locking for more ops */ +#define MNTK_ORPHANED 0x00000080 /* device is gone */ #define MNTK_UNMOUNT 0x01000000 /* unmount in progress */ #define MNTK_MWAIT 0x02000000 /* waiting for unmount to finish */ #define MNTK_SUSPEND 0x08000000 /* request write suspension */ @@ -747,6 +754,7 @@ struct mount *vfs_mount_alloc(struct vnode *, stru int vfs_suser(struct mount *, struct thread *); void vfs_unbusy(struct mount *); void vfs_unmountall(void); +void vfs_orphan(struct mount *); extern TAILQ_HEAD(mntlist, mount) mountlist; /* mounted filesystem list */ extern struct mtx mountlist_mtx; extern struct nfs_public nfs_pub; -- If you cut off my head, what would I say? Me and my head, or me and my body? From ed at 80386.nl Wed Apr 1 13:52:02 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Apr 1 13:52:09 2009 Subject: How to increase the max pty's on Freebsd 7.0? In-Reply-To: References: Message-ID: <20090401205306.GO13393@hoeg.nl> Hi Steven, * Steven Hartland wrote: > How can I increase the maximum number or ptys available on FreeBSD 7.0? > > It seems that currently the machine is maxing out at 512 but there is > still loads of capacity left on the machine. > > Ideally would like to double at least the number of ttys available, > any help would be most appreciated. You can increase the maximum amount of PTYs by editing a lot of source files on your system. There is some good news: in -CURRENT we switched to Unix98-style PTYs (/dev/pts/%u). Right now the maximum amount of PTYs is limited to 1000 (0 to 999). We're currently limited to 7 characters (pts/999) because our utmp/ wtmp/lastlog files only reserve 8 bytes for the TTY name. If you're brave enough, you can increase UT_LINESIZE in include/utmp.h and MAXPTSDEVS in sys/kern/tty_pts.c. Be sure to recompile everything and to remove your utmp/wtmp/lastlog files. -- Ed Schouten WWW: http://80386.nl/ From kostikbel at gmail.com Wed Apr 1 13:57:10 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Apr 1 13:57:17 2009 Subject: How to increase the max pty's on Freebsd 7.0? In-Reply-To: <20090401205306.GO13393@hoeg.nl> References: <20090401205306.GO13393@hoeg.nl> Message-ID: <20090401205703.GX31897@deviant.kiev.zoral.com.ua> On Wed, Apr 01, 2009 at 10:53:06PM +0200, Ed Schouten wrote: > Hi Steven, > > * Steven Hartland wrote: > > How can I increase the maximum number or ptys available on FreeBSD 7.0? > > > > It seems that currently the machine is maxing out at 512 but there is > > still loads of capacity left on the machine. > > > > Ideally would like to double at least the number of ttys available, > > any help would be most appreciated. > > You can increase the maximum amount of PTYs by editing a lot of source > files on your system. There is some good news: in -CURRENT we switched > to Unix98-style PTYs (/dev/pts/%u). Right now the maximum amount of PTYs > is limited to 1000 (0 to 999). > > We're currently limited to 7 characters (pts/999) because our utmp/ > wtmp/lastlog files only reserve 8 bytes for the TTY name. If you're > brave enough, you can increase UT_LINESIZE in include/utmp.h and > MAXPTSDEVS in sys/kern/tty_pts.c. Be sure to recompile everything and to > remove your utmp/wtmp/lastlog files. Can we switch to %x ? Or even, use some radix encoding of the number, to allow alphabetical symbols too ? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090401/675293a0/attachment.pgp From ed at 80386.nl Wed Apr 1 14:07:31 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Apr 1 14:07:37 2009 Subject: How to increase the max pty's on Freebsd 7.0? In-Reply-To: <20090401205703.GX31897@deviant.kiev.zoral.com.ua> References: <20090401205306.GO13393@hoeg.nl> <20090401205703.GX31897@deviant.kiev.zoral.com.ua> Message-ID: <20090401210835.GP13393@hoeg.nl> Hi Kostik, * Kostik Belousov wrote: > Can we switch to %x ? Or even, use some radix encoding of the number, > to allow alphabetical symbols too ? I guess that would break a lot of existing libraries. For example: older RELENG_7/CURRENT libcs might still use TIOCGPTN. This ioctl just returns a number that is just printed into a device name using "/dev/pts/%u" as a format. I also suspect a lot of Linux/Solaris-minded software expects the names to be in decimal form. I also thought about that, but the risks are probably too high. I think it's better to just redesign our utmp/wtmp/lastlog system. I guess we could do something like this: - Implement utmpx. At first utmpx should just be a set of wrappers around utmp/wtmp/lastlog. - Migrate all applications to utmpx. - Change the utmpx code to use some new fancy file format. I think I can finish the first step before 8.0 if I start working on this one of these weeks. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090401/2fee4135/attachment.pgp From ed at 80386.nl Wed Apr 1 14:17:36 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Apr 1 14:17:42 2009 Subject: How to increase the max pty's on Freebsd 7.0? In-Reply-To: <20090401210835.GP13393@hoeg.nl> References: <20090401205306.GO13393@hoeg.nl> <20090401205703.GX31897@deviant.kiev.zoral.com.ua> <20090401210835.GP13393@hoeg.nl> Message-ID: <20090401211840.GQ13393@hoeg.nl> * Ed Schouten wrote: > I also thought about that, but the risks are probably too high. I think > it's better to just redesign our utmp/wtmp/lastlog system. I guess we > could do something like this: I forgot one step: > - Implement utmpx. At first utmpx should just be a set of wrappers > around utmp/wtmp/lastlog. > - Migrate all applications to utmpx. - Remove ttyslot() and . > - Change the utmpx code to use some new fancy file format. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090401/311312a7/attachment.pgp From daamn.m at gmail.com Wed Apr 1 14:53:53 2009 From: daamn.m at gmail.com (Daamn M) Date: Wed Apr 1 14:56:06 2009 Subject: Compilation of hostapd Message-ID: <2f0131d50904011424l5f2e87aeu5cd48960e5dc98b8@mail.gmail.com> Hi! I'm trying to set up wifi access point using my FreeBSD box and hostapd deamon. My goal is running EAP-TTLS server. It seems that the version shipped with base system isn't compiled with options allowing to use EAP server (I'm using 7.0 version but the same is with the latest 8.0 snapshot). I was suprised that some part of base system requires nonstandard tool (gmake) (I changed it to be able to use standard FreeBSD make). Besides, trying to compile it I get the following error: preauth.o(.text+0x1b2): In function `rsn_preauth_send': /usr/src/contrib/hostapd/preauth.c:263: undefined reference to `l2_packet_send' preauth.o(.text+0x55c): In function `rsn_preauth_iface_deinit': /usr/src/contrib/hostapd/preauth.c:148: undefined reference to `l2_packet_deinit' preauth.o(.text+0x660): In function `rsn_preauth_iface_init': /usr/src/contrib/hostapd/preauth.c:119: undefined reference to `l2_packet_init' gmake: *** [hostapd] Error 1 This is ,,.config'' file I used (after this I pasted error I get if I modify a bit config file): # Example hostapd build time configuration # # This file lists the configuration options that are used when building the # hostapd binary. All lines starting with # are ignored. Configuration option # lines must be commented out complete, if they are not to be included, i.e., # just setting VARIABLE=n is not disabling that variable. # # This file is included in Makefile, so variables like CFLAGS and LIBS can also # be modified from here. In most cass, these lines should use += in order not # to override previous values of the variables. # Driver interface for Host AP driver #CONFIG_DRIVER_HOSTAP=y # Driver interface for wired authenticator #CONFIG_DRIVER_WIRED=y # Driver interface for madwifi driver #CONFIG_DRIVER_MADWIFI=y #CFLAGS += -I../head # change to reflect local setup; directory for madwifi src CONFIG_L2_PACKET=y #CONFIG_DNET_PCAP=y #CONFIG_L2_FREEBSD=y # Driver interface for Prism54 driver #CONFIG_DRIVER_PRISM54=y # Driver interface for drivers using Devicescape IEEE 802.11 stack #CONFIG_DRIVER_DEVICESCAPE=y # Currently, driver_devicescape.c build requires some additional parameters # to be able to include some of the kernel header files. Following lines can # be used to set these (WIRELESS_DEV must point to the root directory of the # wireless-dev.git tree). #WIRELESS_DEV=/usr/src/wireless-dev #CFLAGS += -I$(WIRELESS_DEV)/net/mac80211 # Driver interface for FreeBSD net80211 layer (e.g., Atheros driver) #CONFIG_DRIVER_BSD=y #CFLAGS += -I/usr/local/include #LIBS += -L/usr/local/lib # IEEE 802.11F/IAPP #CONFIG_IAPP=y # WPA2/IEEE 802.11i RSN pre-authentication CONFIG_RSN_PREAUTH=y # PeerKey handshake for Station to Station Link (IEEE 802.11e DLS) CONFIG_PEERKEY=y # IEEE 802.11w (management frame protection) # This version is an experimental implementation based on IEEE 802.11w/D1.0 # draft and is subject to change since the standard has not yet been finalized. # Driver support is also needed for IEEE 802.11w. #CONFIG_IEEE80211W=y # Integrated EAP server CONFIG_EAP=y # EAP-MD5 for the integrated EAP server CONFIG_EAP_MD5=y # EAP-TLS for the integrated EAP server CONFIG_EAP_TLS=y # EAP-MSCHAPv2 for the integrated EAP server CONFIG_EAP_MSCHAPV2=y # EAP-PEAP for the integrated EAP server CONFIG_EAP_PEAP=y # EAP-GTC for the integrated EAP server CONFIG_EAP_GTC=y # EAP-TTLS for the integrated EAP server CONFIG_EAP_TTLS=y # EAP-SIM for the integrated EAP server #CONFIG_EAP_SIM=y # EAP-AKA for the integrated EAP server #CONFIG_EAP_AKA=y # EAP-PAX for the integrated EAP server #CONFIG_EAP_PAX=y # EAP-PSK for the integrated EAP server (this is _not_ needed for WPA-PSK) #CONFIG_EAP_PSK=y # EAP-SAKE for the integrated EAP server #CONFIG_EAP_SAKE=y # EAP-GPSK for the integrated EAP server #CONFIG_EAP_GPSK=y # Include support for optional SHA256 cipher suite in EAP-GPSK #CONFIG_EAP_GPSK_SHA256=y # PKCS#12 (PFX) support (used to read private key and certificate file from # a file that usually has extension .p12 or .pfx) CONFIG_PKCS12=y # RADIUS authentication server. This provides access to the integrated EAP # server from external hosts using RADIUS. #CONFIG_RADIUS_SERVER=y # Build IPv6 support for RADIUS operations #CONFIG_IPV6=y If I uncomment line #CONFIG_IAPP=y then I get: cc -MMD -O2 -Wall -g -DHOSTAPD_DUMP_STATE -I../src -I../src/crypto -I../src/utils -I../src/common -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -DCONFIG_IAPP -DCONFIG_RSN_PREAUTH -DCONFIG_PEERKEY -DEAP_MD5 -DEAP_TLS -DEAP_PEAP -DEAP_TTLS -DEAP_MSCHAPv2 -DEAP_GTC -DEAP_SERVER -DEAP_TLS_FUNCS -DPKCS12_FUNCS -DINTERNAL_SHA256 -DCONFIG_NO_FIPS186_2_PRF -DCONFIG_NO_T_PRF -c -o iapp.o iapp.c iapp.c:46:30: warning: netpacket/packet.h: No such file or directory iapp.c: In function 'iapp_init': iapp.c:394: error: storage size of 'addr' isn't known iapp.c:424: error: 'struct ifreq' has no member named 'ifr_ifindex' iapp.c:468: error: 'SOL_IP' undeclared (first use in this function) iapp.c:468: error: (Each undeclared identifier is reported only once iapp.c:468: error: for each function it appears in.) iapp.c:475: error: 'PF_PACKET' undeclared (first use in this function) iapp.c:483: error: 'AF_PACKET' undeclared (first use in this function) iapp.c:394: warning: unused variable 'addr' iapp.c: In function 'iapp_deinit': iapp.c:522: error: 'SOL_IP' undeclared (first use in this function) gmake: *** [iapp.o] Error 1 thanks in advance From kientzle at freebsd.org Wed Apr 1 15:13:52 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Wed Apr 1 15:14:07 2009 Subject: Filesystem orphaning. In-Reply-To: <20090401182502.GA13651@pin.if.uz.zgora.pl> References: <20090401182502.GA13651@pin.if.uz.zgora.pl> Message-ID: <49D3DC85.7070007@freebsd.org> Edward Tomasz Napierala wrote: > Attached is a patch that adds filesystem orphaning. ... > > I'm little short of time, so I won't be able to work on it anytime soon. > If you like the idea - please do whatever is needed to get it to commitable > state. This is funny: the "filesystem orphaning" patch is being orphaned! Tim From fb-hackers at psconsult.nl Wed Apr 1 15:15:04 2009 From: fb-hackers at psconsult.nl (Paul Schenkeveld) Date: Wed Apr 1 15:15:11 2009 Subject: How to increase the max pty's on Freebsd 7.0? In-Reply-To: <20090401210835.GP13393@hoeg.nl> References: <20090401205306.GO13393@hoeg.nl> <20090401205703.GX31897@deviant.kiev.zoral.com.ua> <20090401210835.GP13393@hoeg.nl> Message-ID: <20090401215308.GA91493@psconsult.nl> On Wed, Apr 01, 2009 at 11:08:35PM +0200, Ed Schouten wrote: > Hi Kostik, > > * Kostik Belousov wrote: > > Can we switch to %x ? Or even, use some radix encoding of the number, > > to allow alphabetical symbols too ? > > I guess that would break a lot of existing libraries. For example: older > RELENG_7/CURRENT libcs might still use TIOCGPTN. This ioctl just returns > a number that is just printed into a device name using "/dev/pts/%u" as > a format. I also suspect a lot of Linux/Solaris-minded software expects > the names to be in decimal form. Or change 'pts' to, for example, 'pt' so without changing utmp and related stuff we'll have space for a four digit pty number. -- Paul Schenkeveld From sam at freebsd.org Wed Apr 1 16:00:56 2009 From: sam at freebsd.org (Sam Leffler) Date: Wed Apr 1 16:01:03 2009 Subject: Compilation of hostapd In-Reply-To: <2f0131d50904011424l5f2e87aeu5cd48960e5dc98b8@mail.gmail.com> References: <2f0131d50904011424l5f2e87aeu5cd48960e5dc98b8@mail.gmail.com> Message-ID: <49D3F227.90606@freebsd.org> Daamn M wrote: > Hi! > > I'm trying to set up wifi access point using my FreeBSD box and > hostapd deamon. My goal is running EAP-TTLS server. It seems that the > version shipped with base system isn't compiled with options allowing > to use EAP server (I'm using 7.0 version but the same is with the > latest 8.0 snapshot). I was suprised that some part of base system > requires nonstandard tool (gmake) (I changed it to be able to use > standard FreeBSD make). Besides, trying to compile it I get the > following error: > > preauth.o(.text+0x1b2): In function `rsn_preauth_send': > /usr/src/contrib/hostapd/preauth.c:263: undefined reference to `l2_packet_send' > preauth.o(.text+0x55c): In function `rsn_preauth_iface_deinit': > /usr/src/contrib/hostapd/preauth.c:148: undefined reference to > `l2_packet_deinit' > preauth.o(.text+0x660): In function `rsn_preauth_iface_init': > /usr/src/contrib/hostapd/preauth.c:119: undefined reference to `l2_packet_init' > gmake: *** [hostapd] Error 1 > > > This is ,,.config'' file I used (after this I pasted error I get if I > modify a bit config file): > cd /usr/src/usr.sbin/wpa/hostapd; make To enable functionality already supported by the Makefile you can add HOSTAPD_* options to your src.conf (or for testing just add them to make cmd line). Otherwise you might need to mod the Makefile in which case you can file a PR w/ the needed changes to get them included in svn. Sam From amdmi3 at amdmi3.ru Wed Apr 1 16:44:41 2009 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Wed Apr 1 16:44:49 2009 Subject: -pthread propagation Message-ID: <20090401231831.GS1964@hades.panopticon> Hi! I have a question about -pthread. Imagine the situation where one port installs shared library that uses threads, and other port links with this library. A question: should the second port explicitely add -pthread to linker flags? For example, graphics/ilmbase is built with pthread support by default, but it's shared libraries are not linked with -pthread: % ldd /usr/local/lib/libIlmThread.so /usr/local/lib/libIlmThread.so: libIex.so.6 => /usr/local/lib/libIex.so.6 (0x2819c000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x28300000) libm.so.5 => /lib/libm.so.5 (0x281ad000) libc.so.7 => /lib/libc.so.7 (0x2808b000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x281c6000) no libthr.so mention. Thus, % gcc helloworld.cc -lIlmThread -L/usr/local/lib /usr/local/lib/libIlmThread.so: undefined reference to `pthread_create' I assume this should be fixed in ilmbase instead of all dependent ports (for example, graphics/nvidia-texture-tools and graphics/devil, which supports the former), am I right? Btw, libIlmThread.la _does_ have -pthread in dependency_libs. However, I've encountered situations where linking with library linked with -pthread will succeed, but the resulting binary will not be broken. Example is games/battletanks: When built as is (note that it has ${PTHREAD_LIBS} explicitely added to LDFLAGS), it runs without problems. However, if you remove ${PTHREAD_LIBS}, it'll still build successfully, but won't run: % bt [03:04:45.449][src/main.cpp:44] [notice] starting up... version: 5800 beta [03:04:45.449][src/main.cpp:46] [notice] mem avail: -1 mb terminate called after throwing an instance of '__gnu_cxx::__concurrence_lock_error' what(): __gnu_cxx::__concurrence_lock_error [1] 58620 abort (core dumped) bt I think that's linked with static variable initialization - it should be protected with a mutex in threaded environment, but it doesn't happen correctly when linking without -pthread, even if with -lthr. I'll be really grateful if someone explains what really happens when using -lpthread, and what happens in the above mentioned error case (cc'ing hackers@). So should -pthread be forced in ldflags 1) Only in ports that explicitely use threads 2) In all ports that link with -lthr implicitely, including through other ports? -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From trasz at freebsd.org Wed Apr 1 16:48:19 2009 From: trasz at freebsd.org (Edward Tomasz Napierala) Date: Wed Apr 1 16:48:26 2009 Subject: Filesystem orphaning. In-Reply-To: <49D3DC85.7070007@freebsd.org> References: <20090401182502.GA13651@pin.if.uz.zgora.pl> <49D3DC85.7070007@freebsd.org> Message-ID: <20090401234935.GA16020@pin.if.uz.zgora.pl> On 0401T1428, Tim Kientzle wrote: > > Attached is a patch that adds filesystem orphaning. ... > > > > I'm little short of time, so I won't be able to work on it anytime soon. > > If you like the idea - please do whatever is needed to get it to commitable > > state. > > This is funny: the "filesystem orphaning" patch is being orphaned! Postponed. I'm not dying anytime soon. ;-) -- If you cut off my head, what would I say? Me and my head, or me and my body? From aryeh.friedman at gmail.com Wed Apr 1 17:03:30 2009 From: aryeh.friedman at gmail.com (Aryeh M. Friedman) Date: Wed Apr 1 17:03:37 2009 Subject: configuring dns/sendmail for two different servers Message-ID: <49D400C9.30707@gmail.com> I have a domain that I just transfered from dreamhost and there are already some email accounts set up on it that are forwarded to gmail but there are also other accounts that are local accounts.... my question is there a easy way to say if it is not a local account forward/use as MX gmail? From deischen at freebsd.org Wed Apr 1 17:12:13 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Wed Apr 1 17:12:22 2009 Subject: -pthread propagation In-Reply-To: <20090401231831.GS1964@hades.panopticon> References: <20090401231831.GS1964@hades.panopticon> Message-ID: On Thu, 2 Apr 2009, Dmitry Marakasov wrote: > Hi! > > I have a question about -pthread. Imagine the situation where one port > installs shared library that uses threads, and other port links with > this library. A question: should the second port explicitely add > -pthread to linker flags? Yes. > For example, graphics/ilmbase is built with pthread support by default, > but it's shared libraries are not linked with -pthread: > > % ldd /usr/local/lib/libIlmThread.so > /usr/local/lib/libIlmThread.so: > libIex.so.6 => /usr/local/lib/libIex.so.6 (0x2819c000) > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x28300000) > libm.so.5 => /lib/libm.so.5 (0x281ad000) > libc.so.7 => /lib/libc.so.7 (0x2808b000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x281c6000) > > no libthr.so mention. Thus, > > % gcc helloworld.cc -lIlmThread -L/usr/local/lib > /usr/local/lib/libIlmThread.so: undefined reference to `pthread_create' > > I assume this should be fixed in ilmbase instead of all dependent ports > (for example, graphics/nvidia-texture-tools and graphics/devil, which > supports the former), am I right? Btw, libIlmThread.la _does_ have > -pthread in dependency_libs. Yes, all ports that use libraries that create threads on their behalf should use -pthread. > However, I've encountered situations where linking with library > linked with -pthread will succeed, but the resulting binary will not > be broken. Example is games/battletanks: This is probably because libc contains some simple thread wrappers (mostly lock related stuff). They go unused unless a thread is created (and libthr is explicitly brought in), in which case those wrappers are overridden by libthr. > When built as is (note that it has ${PTHREAD_LIBS} explicitely added to > LDFLAGS), it runs without problems. However, if you remove > ${PTHREAD_LIBS}, it'll still build successfully, but won't run: > > % bt > [03:04:45.449][src/main.cpp:44] [notice] starting up... version: 5800 beta > [03:04:45.449][src/main.cpp:46] [notice] mem avail: -1 mb > terminate called after throwing an instance of '__gnu_cxx::__concurrence_lock_error' > what(): __gnu_cxx::__concurrence_lock_error > [1] 58620 abort (core dumped) bt > > I think that's linked with static variable initialization - it should > be protected with a mutex in threaded environment, but it doesn't happen > correctly when linking without -pthread, even if with -lthr. It is possible for a library to be thread-aware and thread-safe. In this case it can play pragma weak games with "pthread_create" and only use locks if pthread_create resolves to a non-null pointer. > I'll be really grateful if someone explains what really happens when > using -lpthread, and what happens in the above mentioned error case > (cc'ing hackers@). > > So should -pthread be forced in ldflags > 1) Only in ports that explicitely use threads > 2) In all ports that link with -lthr implicitely, including through > other ports? It depends, libraries can be made thread-safe/aware as above, and both threaded and non-threaded applications can link with them just fine. Assuming those libraries are smart about how they use the locking mechanisms, and never use them unless they know that "pthread_create" is present (or some other symbol not present in libc, but present in libthr). But for libraries that create threads, applications must also link with -pthread (or -lpthread). If you can understand it, you can see src/contrib/gcc/gthr-posix.h for how libgcc is thread-aware. A comment from that file: /* On Solaris 2.6 up to 9, the libc exposes a POSIX threads interface even if -pthreads is not specified. The functions are dummies and most return an error value. However pthread_once returns 0 without invoking the routine it is passed so we cannot pretend that the interface is active if -pthreads is not specified. On Solaris 2.5.1, the interface is not exposed at all so we need to play the usual game with weak symbols. On Solaris 10 and up, a working interface is always exposed. On FreeBSD 6 and later, libc also exposes a dummy POSIX threads interface, similar to what Solaris 2.6 up to 9 does. FreeBSD >= 700014 even provides a pthread_cancel stub in libc, which means the alternate __gthread_active_p below cannot be used there. */ -- DE From aryeh.friedman at gmail.com Wed Apr 1 18:00:59 2009 From: aryeh.friedman at gmail.com (Aryeh M. Friedman) Date: Wed Apr 1 18:01:05 2009 Subject: configuring dns/sendmail for two different servers In-Reply-To: <20090402005607.GB28987@rugsucker.smi.sendmail.com> References: <49D400C9.30707@gmail.com> <20090402005607.GB28987@rugsucker.smi.sendmail.com> Message-ID: <49D40E48.7000202@gmail.com> Gregory Shapiro wrote: >> I have a domain that I just transfered from dreamhost and there are >> already some email accounts set up on it that are forwarded to gmail but >> there are also other accounts that are local accounts.... my question is >> there a easy way to say if it is not a local account forward/use as MX >> gmail? >> > > You can use aliases: > > man aliases > > > I was aware of that but wanted a "default" alias for any addr/alias that does not exist to send to gmail and alias(5) does not allow for wild cards and/or defaults it seems From gshapiro at freebsd.org Wed Apr 1 18:18:24 2009 From: gshapiro at freebsd.org (Gregory Shapiro) Date: Wed Apr 1 18:18:54 2009 Subject: configuring dns/sendmail for two different servers In-Reply-To: <49D40E48.7000202@gmail.com> References: <49D400C9.30707@gmail.com> <20090402005607.GB28987@rugsucker.smi.sendmail.com> <49D40E48.7000202@gmail.com> Message-ID: <20090402011820.GC28987@rugsucker.smi.sendmail.com> > I was aware of that but wanted a "default" alias for any addr/alias that > does not exist to send to gmail and alias(5) does not allow for wild > cards and/or defaults it seems You can add this to your .mc file: define(`LUSER_RELAY', `local:unknownuser') and then alias 'unknownuser' to the address you wish. Alternatively, you can use FEATURE(`virtusertable') for your domain. From aryeh.friedman at gmail.com Wed Apr 1 18:21:24 2009 From: aryeh.friedman at gmail.com (Aryeh M. Friedman) Date: Wed Apr 1 18:21:32 2009 Subject: configuring dns/sendmail for two different servers In-Reply-To: <20090402011820.GC28987@rugsucker.smi.sendmail.com> References: <49D400C9.30707@gmail.com> <20090402005607.GB28987@rugsucker.smi.sendmail.com> <49D40E48.7000202@gmail.com> <20090402011820.GC28987@rugsucker.smi.sendmail.com> Message-ID: <49D4130F.6060501@gmail.com> Gregory Shapiro wrote: >> I was aware of that but wanted a "default" alias for any addr/alias that >> does not exist to send to gmail and alias(5) does not allow for wild >> cards and/or defaults it seems >> > > You can add this to your .mc file: > > define(`LUSER_RELAY', `local:unknownuser') > > and then alias 'unknownuser' to the address you wish. > > Alternatively, you can use FEATURE(`virtusertable') for your domain. > > > Maybe I misread but both of those features (I have used the second but not the first) seem to be all or nothing forwarders (i.e. xxx@domain is forwarded for all xxx not just some xxx) From gshapiro at freebsd.org Wed Apr 1 18:23:51 2009 From: gshapiro at freebsd.org (Gregory Shapiro) Date: Wed Apr 1 18:23:57 2009 Subject: configuring dns/sendmail for two different servers In-Reply-To: <49D400C9.30707@gmail.com> References: <49D400C9.30707@gmail.com> Message-ID: <20090402005607.GB28987@rugsucker.smi.sendmail.com> > I have a domain that I just transfered from dreamhost and there are > already some email accounts set up on it that are forwarded to gmail but > there are also other accounts that are local accounts.... my question is > there a easy way to say if it is not a local account forward/use as MX > gmail? You can use aliases: man aliases From gshapiro at freebsd.org Wed Apr 1 18:25:22 2009 From: gshapiro at freebsd.org (Gregory Shapiro) Date: Wed Apr 1 18:25:28 2009 Subject: configuring dns/sendmail for two different servers In-Reply-To: <49D4130F.6060501@gmail.com> References: <49D400C9.30707@gmail.com> <20090402005607.GB28987@rugsucker.smi.sendmail.com> <49D40E48.7000202@gmail.com> <20090402011820.GC28987@rugsucker.smi.sendmail.com> <49D4130F.6060501@gmail.com> Message-ID: <20090402012518.GD28987@rugsucker.smi.sendmail.com> > Maybe I misread but both of those features (I have used the second but > not the first) seem to be all or nothing forwarders (i.e. xxx@domain is > forwarded for all xxx not just some xxx) LUSER_RELAY is only for unknown users. If you user virtusertable, you'll need to list out all valid users and then add a catchall @domain map entry. From alex.wilkinson at dsto.defence.gov.au Wed Apr 1 22:49:29 2009 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Wed Apr 1 22:49:35 2009 Subject: How to increase the max pty's on Freebsd 7.0? In-Reply-To: <20090401205306.GO13393@hoeg.nl> References: <20090401205306.GO13393@hoeg.nl> Message-ID: <20090402052900.GL2351@stlux503.dsto.defence.gov.au> 0n Wed, Apr 01, 2009 at 10:53:06PM +0200, Ed Schouten wrote: >You can increase the maximum amount of PTYs by editing a lot of source >files on your system. There is some good news: in -CURRENT we switched >to Unix98-style PTYs (/dev/pts/%u). Right now the maximum amount of PTYs >is limited to 1000 (0 to 999). What are "Unix98-style PTYs" ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From ed at 80386.nl Wed Apr 1 23:09:17 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Apr 1 23:09:23 2009 Subject: How to increase the max pty's on Freebsd 7.0? In-Reply-To: <20090401215308.GA91493@psconsult.nl> References: <20090401205306.GO13393@hoeg.nl> <20090401205703.GX31897@deviant.kiev.zoral.com.ua> <20090401210835.GP13393@hoeg.nl> <20090401215308.GA91493@psconsult.nl> Message-ID: <20090402061003.GR13393@hoeg.nl> * Paul Schenkeveld wrote: > Or change 'pts' to, for example, 'pt' so without changing utmp and > related stuff we'll have space for a four digit pty number. I've noticed lots of apps already misbehave because of the pty(4) -> pts(4) migration. I guess using a new naming scheme would totally break stuff. There are lots of apps that do things like: if (strncmp(tty, "tty", 3) != 0 && strncmp(tty, "pts/", 4) != 0) printf("Not a valid pseudo-terminal!\n"); But those are just workarounds. Our utmp format is broken anyway. It's not just UT_LINESIZE that's too small. I think we received many complaints from people who want to increase UT_HOSTSIZE as well. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090402/69b3457d/attachment.pgp From ed at 80386.nl Wed Apr 1 23:23:25 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Apr 1 23:23:32 2009 Subject: How to increase the max pty's on Freebsd 7.0? In-Reply-To: <20090402052900.GL2351@stlux503.dsto.defence.gov.au> References: <20090401205306.GO13393@hoeg.nl> <20090402052900.GL2351@stlux503.dsto.defence.gov.au> Message-ID: <20090402062410.GS13393@hoeg.nl> Hi Alex, * Wilkinson, Alex wrote: > > 0n Wed, Apr 01, 2009 at 10:53:06PM +0200, Ed Schouten wrote: > > >You can increase the maximum amount of PTYs by editing a lot of source > >files on your system. There is some good news: in -CURRENT we switched > >to Unix98-style PTYs (/dev/pts/%u). Right now the maximum amount of PTYs > >is limited to 1000 (0 to 999). > > What are "Unix98-style PTYs" ? Unix98-style PTYS is a name often given to implementations of pseudo-terminals that use a character device called /dev/ptmx to allocate a new pseudo-terminal. After /dev/ptmx has been opened, it will expose a new TTY in /dev/pts. The name of the TTY can be obtained using routines like ptsname(). Operating systems like Linux and Solaris use this as well. FreeBSD's pts(4) driver also has a /dev/ptmx character device, but it's just there for compatibility (Linux binary emulation, older -CURRENT libcs). The preferred way to allocate pseudo-terminals is to call posix_openpt(2). An advantage of the current design is that allocating pseudo-terminals can be done a lot more easily. On RELENG_[67] posix_openpt(3) is a libc routine that has to loop through devfs to search for the first unused pseudo-terminal. It also requires a set-uid utility (pt_chown) to change the ownership of the TTY: http://svn.freebsd.org/viewvc/base/stable/7/lib/libc/stdlib/grantpt.c?view=markup In -CURRENT the TTYs are allocated on demand with the proper permissions in place. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090402/2ad52013/attachment.pgp From guru at unixarea.de Thu Apr 2 01:44:02 2009 From: guru at unixarea.de (Matthias Apitz) Date: Thu Apr 2 01:44:09 2009 Subject: CURRENT sees only /dev/ad2s1a, but not /dev/ad3s1a In-Reply-To: <3a142e750903270952h3ba5e28fp72b39283b2a46d97@mail.gmail.com> References: <20090327151052.GA13243@rebelion.Sisis.de> <3a142e750903270952h3ba5e28fp72b39283b2a46d97@mail.gmail.com> Message-ID: <20090402084357.GA5825@rebelion.Sisis.de> El d?a Friday, March 27, 2009 a las 05:52:40PM +0100, Paul B. Mahol escribi?: > On 3/27/09, Matthias Apitz wrote: > > > > Hello, > > > > When I boot my EeePC from USB key (/dev/da0s1a) -CURRENT it sees the two SSD > > only > > as > > > > $ ls -l /dev/ad* > > /dev/ad2 > > /dev/ad2s1 > > /dev/ad2s1a > > /dev/ad3 > > /dev/ad3a > > > > I can mount /dev/ad2s1a but ofc not /dev/ad3s1a; > > > > when I'm booting the RELENG_7 from /dev/ad2s1a itself it looks like this: > > > > $ mount > > /dev/ad2s1a on / (ufs, local, noatime) > > /dev/ad3s1a on /usr/home (ufs, local, noatime) > > CURRENT have replaced geom_bsd with geom_part_bsd > and that can cause various problems, search current archives for more info. When I will update the EeePC from USB key (/dev/da0s1a) to CURRENT I will install into /dev/ad2s1a (with make installworld/installkernel ...) and I want to keep the partition /dev/ad3s1a as it is; would it be enough to just do: # bsdlabel -w ad3s1 auto from CURRENT booted? Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From samflanker at gmail.com Thu Apr 2 03:29:48 2009 From: samflanker at gmail.com (Vladimir Ermakov) Date: Thu Apr 2 03:29:55 2009 Subject: [problem] aac0 does not respond In-Reply-To: <20090324141136.GA46558@jem.dhs.org> References: <49C8AD9B.7000500@gmail.com> <3bbf2fe10903240324t6616cc9dx6ae28028ac971be6@mail.gmail.com> <49C8B5E3.2000104@gmail.com> <49C8D6AD.7050501@gmail.com> <20090324141136.GA46558@jem.dhs.org> Message-ID: <49D49396.1090507@gmail.com> Ed Maste wrote: > 2009/3/24 Vladimir Ermakov : > >> Hello, All >> >> Describe my problem: >> have volume RAID-10 (SAS-HDD x 6) on Adaptec RAID 5805 >> 2 HHD of 6 have errors in smart data (damaged) >> i am try read file /var/db/mysql/ibdata1 from this volume >> system does not respond ( lost access to ssh ) after read 6GB data >> > >from this > >> file >> and print debug messages on ttyv0 >> > > If the messages you see are the same as in the message to which you > provided a link ("COMMAND xxx TIMED OUT AFTER xxx SECONDS") it typically > means that the RAID controller has crashed. My initial suggestion is to > check the firmware version installed on your card, and update to the > latest from Adaptec's website if you're not running that one already. > > Attilio also has some driver updates (ported from Adaptec's latest > vendor driver) that you can try. The plan is to commit them sometime > soon, but he can forward those on for testing before that happens. > > -Ed > > after update to FreeBSD 7-STABLE amd64 Adaptec 5805 firmware build: 16501 # uname -a FreeBSD 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #1: Thu Apr 2 11:03:45 CEST 2009 root@sys3:/usr/obj/usr/src/sys/GENERIC amd64 # tar -cf - ibdata1 | pv -brt > /dev/null 5.98GB 0:30:23 [ 0B/s ] ---------/var/log/messages-------------------------------- Apr 2 09:13:51 kernel: SMP: AP CPU #4 Launched! Apr 2 09:13:51 kernel: lapic5: Forcing LINT1 to edge trigger Apr 2 09:13:51 kernel: SMP: AP CPU #5 Launched! Apr 2 09:13:51 kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Apr 2 09:13:51 kernel: da0: Removable Direct Access SCSI-2 device Apr 2 09:13:51 kernel: da0: 40.000MB/s transfers Apr 2 09:13:51 kernel: da0: 15424MB (31588352 512 byte sectors: 255H 63S/T 1966C) Apr 2 09:13:51 kernel: aac0: EventNotify(0) Apr 2 09:13:51 kernel: aac0: (22) Apr 2 09:13:51 kernel: Trying to mount root from ufs:/dev/da0s1a Apr 2 09:13:51 kernel: aac0: EventNotify(0) Apr 2 09:13:51 kernel: aac0: (22) Apr 2 09:13:52 savecore: no dumps found Apr 2 09:13:53 kernel: aac0: EventNotify(0) Apr 2 09:13:53 kernel: aac0: (22) Apr 2 09:14:07 kernel: aac0: EventNotify(0) Apr 2 09:14:07 kernel: aac0: (22) Apr 2 09:55:07 kernel: aac0: COMMAND 0xfffffffe80244060 TIMEOUT AFTER 41 SECONDS Apr 2 09:55:07 kernel: aac0: aac_timeout: FIB @ 0xffffffff4cd37000 Apr 2 09:55:07 kernel: aac0: XferState 830ad Apr 2 09:55:07 kernel: aac0: Command 502 Apr 2 09:55:07 kernel: aac0: StructType 1 Apr 2 09:55:07 kernel: aac0: Flags 0x0 Apr 2 09:55:07 kernel: aac0: Size 80 Apr 2 09:55:07 kernel: aac0: SenderSize 2048 Apr 2 09:55:07 kernel: aac0: SenderAddress 0x528 Apr 2 09:55:07 kernel: aac0: RcvrAddress 0x3e53000 Apr 2 09:55:07 kernel: aac0: SenderData 0x14a Apr 2 09:55:07 kernel: aac0: 7f 3e c2 10 00 00 00 00 00 00 01 00 00 00 01 00 Apr 2 09:55:07 kernel: aac0: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 Apr 2 09:55:07 kernel: aac0: COMMAND 0xfffffffe80240080 TIMEOUT AFTER 41 SECONDS Apr 2 09:55:07 kernel: aac0: aac_timeout: FIB @ 0xffffffff4ccee000 Apr 2 09:55:07 kernel: aac0: XferState 830ad Apr 2 09:55:07 kernel: aac0: Command 502 Apr 2 09:55:07 kernel: aac0: StructType 1 Apr 2 09:55:07 kernel: aac0: Flags 0x0 Apr 2 09:55:07 kernel: aac0: Size 80 Apr 2 09:55:07 kernel: aac0: SenderSize 2048 Apr 2 09:55:07 kernel: aac0: SenderAddress 0x2e0 Apr 2 09:55:07 kernel: aac0: RcvrAddress 0x3956000 Apr 2 09:55:07 kernel: aac0: SenderData 0xb8 Apr 2 09:55:07 kernel: aac0: ff 3e c2 10 00 00 00 00 00 00 01 00 00 00 01 00 Apr 2 09:55:07 kernel: aac0: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 Apr 2 09:55:07 kernel: aac0: WARNING! Controller is no longer running! code= 0xbc620100 Apr 2 09:55:27 kernel: aac0: COMMAND 0xfffffffe80244060 TIMEOUT AFTER 61 SECONDS Apr 2 09:55:27 kernel: aac0: aac_timeout: FIB @ 0xffffffff4cd37000 Apr 2 09:55:27 kernel: aac0: XferState 830ad Apr 2 09:55:27 kernel: aac0: Command 502 Apr 2 09:55:27 kernel: aac0: StructType 1 Apr 2 09:55:27 kernel: aac0: Flags 0x0 Apr 2 09:55:27 kernel: aac0: Size 80 Apr 2 09:55:27 kernel: aac0: SenderSize 2048 Apr 2 09:55:27 kernel: aac0: SenderAddress 0x528 Apr 2 09:55:27 kernel: aac0: RcvrAddress 0x3e53000 Apr 2 09:55:27 kernel: aac0: SenderData 0x14a Apr 2 09:55:27 kernel: aac0: 7f 3e c2 10 00 00 00 00 00 00 01 00 00 00 01 00 Apr 2 09:55:27 kernel: aac0: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 Apr 2 09:55:27 kernel: aac0: COMMAND 0xfffffffe80240080 TIMEOUT AFTER 61 SECONDS Apr 2 09:55:27 kernel: aac0: aac_timeout: FIB @ 0xffffffff4ccee000 Apr 2 09:55:27 kernel: aac0: XferState 830ad Apr 2 09:55:27 kernel: aac0: Command 502 Apr 2 09:55:27 kernel: aac0: StructType 1 Apr 2 09:55:27 kernel: aac0: Flags 0x0 Apr 2 09:55:27 kernel: aac0: Size 80 Apr 2 09:55:27 kernel: aac0: SenderSize 2048 Apr 2 09:55:27 kernel: aac0: SenderAddress 0x2e0 Apr 2 09:55:27 kernel: aac0: RcvrAddress 0x3956000 Apr 2 09:55:27 kernel: aac0: SenderData 0xb8 Apr 2 09:55:27 kernel: aac0: ff 3e c2 10 00 00 00 00 00 00 01 00 00 00 01 00 Apr 2 09:55:27 kernel: aac0: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 *** --------------------------------------------------------------------- /Vladimir Ermakov From avg at icyb.net.ua Thu Apr 2 04:28:51 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Apr 2 04:28:58 2009 Subject: watchdog: hw+sw? Message-ID: <49D4A16F.6020906@icyb.net.ua> I have some vague thoughts on using SW_WATCHDOG and a hardware watchdog together. I think this could be useful but I am not sure how to implement this. The idea is this: timeout for SW_WATCHDOG is smaller than timeout for hw wd; when some freeze happens sw wd logic kicks in first, stops hw wd and produces either panic or ddb prompt; if the freeze is so severe that sw wd can't run (e.g. hardware is messed up badly) then hw wd performs its duty. I am mostly interested in having this in unattended mode where kernel dump could be useful for later analysis but the system should recover in reasonable time. Suggestions, opinions? Thank you! -- Andriy Gapon From lists.br at gmail.com Thu Apr 2 05:33:34 2009 From: lists.br at gmail.com (Luiz Otavio O Souza) Date: Thu Apr 2 05:43:40 2009 Subject: Setting the mss for socket Message-ID: <3FD46C21A487490FB15B89E890790121@adnote989> Hello hackers, Is there a way to set the mss for a socket ? Like you can do in linux with setsockopt(TCP_MAXSEG) ? So i can set the maximum size of packets (or sort of) from a simple userland program. I've read the code and i cannot find by myself (at least from a 30minute reading) a single point to change this. It looks like it is dynamic calculated with interface/path mtu. Someone has a simple approach to deal with this ? Any ideas ? Thanks in advance, Luiz From won.derick at yahoo.com Thu Apr 2 06:46:00 2009 From: won.derick at yahoo.com (Won De Erick) Date: Thu Apr 2 06:46:06 2009 Subject: watchdog: hw+sw? Message-ID: <630898.7304.qm@web45805.mail.sp1.yahoo.com> --- On Thu, 4/2/09, Andriy Gapon wrote: > > I have some vague thoughts on using SW_WATCHDOG and a > hardware watchdog together. > I think this could be useful but I am not sure how to > implement this. > The idea is this: timeout for SW_WATCHDOG is smaller than > timeout for hw wd; when > some freeze happens sw wd logic kicks in first, stops hw wd > and produces either > panic or ddb prompt; if the freeze is so severe that sw wd > can't run (e.g. > hardware is messed up badly) then hw wd performs its duty. > I am mostly interested in having this in unattended mode > where kernel dump could > be useful for later analysis but the system should recover > in reasonable time. > > Suggestions, opinions? That is interesting! I've been longing for that kind of tool that works with FreeBSD. You might as well want to see/try how the 'bmc-panic' mentioned in the following link is related to your project. http://ipmiutil.sourceforge.net/ Good luck. From eksffa at freebsdbrasil.com.br Thu Apr 2 07:47:04 2009 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Thu Apr 2 07:47:12 2009 Subject: Setting the mss for socket In-Reply-To: <3FD46C21A487490FB15B89E890790121@adnote989> References: <3FD46C21A487490FB15B89E890790121@adnote989> Message-ID: <49D4C9A0.9000804@freebsdbrasil.com.br> Luiz Otavio O Souza escreveu: > Hello hackers, > > Is there a way to set the mss for a socket ? Like you can do in linux > with setsockopt(TCP_MAXSEG) ? > > So i can set the maximum size of packets (or sort of) from a simple > userland program. > > I've read the code and i cannot find by myself (at least from a 30minute > reading) a single point to change this. It looks like it is dynamic > calculated with interface/path mtu. Someone has a simple approach to > deal with this ? Any ideas ? > > Thanks in advance, > Luiz Good point. With something like that it could be possible to make --mss switch from iperf work properly on FreeBSD. -- Patrick Tracanelli From onemda at gmail.com Thu Apr 2 08:06:55 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Apr 2 08:07:02 2009 Subject: CURRENT sees only /dev/ad2s1a, but not /dev/ad3s1a In-Reply-To: <20090402084357.GA5825@rebelion.Sisis.de> References: <20090327151052.GA13243@rebelion.Sisis.de> <3a142e750903270952h3ba5e28fp72b39283b2a46d97@mail.gmail.com> <20090402084357.GA5825@rebelion.Sisis.de> Message-ID: <3a142e750904020806m4e7726d5w77bd34cb9eb3e5c4@mail.gmail.com> On 4/2/09, Matthias Apitz wrote: > El d?a Friday, March 27, 2009 a las 05:52:40PM +0100, Paul B. Mahol > escribi?: > >> On 3/27/09, Matthias Apitz wrote: >> > >> > Hello, >> > >> > When I boot my EeePC from USB key (/dev/da0s1a) -CURRENT it sees the two >> > SSD >> > only >> > as >> > >> > $ ls -l /dev/ad* >> > /dev/ad2 >> > /dev/ad2s1 >> > /dev/ad2s1a >> > /dev/ad3 >> > /dev/ad3a >> > >> > I can mount /dev/ad2s1a but ofc not /dev/ad3s1a; >> > >> > when I'm booting the RELENG_7 from /dev/ad2s1a itself it looks like >> > this: >> > >> > $ mount >> > /dev/ad2s1a on / (ufs, local, noatime) >> > /dev/ad3s1a on /usr/home (ufs, local, noatime) >> >> CURRENT have replaced geom_bsd with geom_part_bsd >> and that can cause various problems, search current archives for more >> info. > > When I will update the EeePC from USB key (/dev/da0s1a) to CURRENT I > will install into /dev/ad2s1a (with make installworld/installkernel ...) > and I want to keep the partition /dev/ad3s1a as it is; would it be > enough to just do: > > # bsdlabel -w ad3s1 auto > > from CURRENT booted? When you do that, make backups anyway. I dont use bsdlabel/fdisk/sade any more, I use gpart(8) instead. I actually wiped completely old crappy parttion table and replaced it with gpart one, and now I'm using more than 8 labels. -- Paul From gabriele.modena at gmail.com Thu Apr 2 09:04:26 2009 From: gabriele.modena at gmail.com (Gabriele Modena) Date: Thu Apr 2 09:04:34 2009 Subject: GSoC: Semantic File System In-Reply-To: References: <1fe1d5d60903210422g70efef15hdd685695cdf8df3c@mail.gmail.com> Message-ID: <1fe1d5d60904020904ya6dcb00h54a54d6a00e2bd0@mail.gmail.com> On Sun, Mar 22, 2009 at 6:52 PM, Robert Watson wrote: > We are certainly not uninterested in projects along these lines, but I think > the trick will be creating a convincing proposal that argues that (a) you > can do the work in a summer, (b) there's a compelling usage case for > including the results in FreeBSD, and (c) find a mentor who can supervise > you in this project. Thanks, I will keep it on mind when writing the proposal. How do you suggest to proceed for finding a mentor? By the way, this is a project that I'm very probably going to carry on even without GSoC support (even though that would be very useful). > What sort of semantic file system do you have in mind? > ?How would you feel about a middle-ground project along the lines of Mac OS > X Spotlight or similar efficient userspace indexing of a file system based > on feedback from the file system about what has changed, or something > BeOS-like, in which indexing takes place for extended attributes rather than > for contents? In this moment I am considering also an userspace approach similar to Spotlight/Beagles, but I don't know how I could propose this as a FreeBSD GSoC project. What I have in mind at the moment would be an indexing based on contents rather than extended fs attributes. I did not know about the BeOS semantics capabilities, I will surely have a look at that. From rwatson at FreeBSD.org Thu Apr 2 10:26:10 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Apr 2 10:26:18 2009 Subject: GSoC: Semantic File System In-Reply-To: <1fe1d5d60904020904ya6dcb00h54a54d6a00e2bd0@mail.gmail.com> References: <1fe1d5d60903210422g70efef15hdd685695cdf8df3c@mail.gmail.com> <1fe1d5d60904020904ya6dcb00h54a54d6a00e2bd0@mail.gmail.com> Message-ID: On Thu, 2 Apr 2009, Gabriele Modena wrote: > On Sun, Mar 22, 2009 at 6:52 PM, Robert Watson wrote: >> We are certainly not uninterested in projects along these lines, but I >> think the trick will be creating a convincing proposal that argues that (a) >> you can do the work in a summer, (b) there's a compelling usage case for >> including the results in FreeBSD, and (c) find a mentor who can supervise >> you in this project. > > Thanks, I will keep it on mind when writing the proposal. How do you suggest > to proceed for finding a mentor? > > By the way, this is a project that I'm very probably going to carry on even > without GSoC support (even though that would be very useful). Well, I think the first step is to write the proposal, and we can see about shopping it around for a potential mentor. >> What sort of semantic file system do you have in mind? ?How would you feel >> about a middle-ground project along the lines of Mac OS X Spotlight or >> similar efficient userspace indexing of a file system based on feedback >> from the file system about what has changed, or something BeOS-like, in >> which indexing takes place for extended attributes rather than for >> contents? > > In this moment I am considering also an userspace approach similar to > Spotlight/Beagles, but I don't know how I could propose this as a FreeBSD > GSoC project. I think that would make a fine GSoC proposal. Keep in mind that one of the premises of Spotlight is the fsevents kernel feature, and fseventsd, which allow Spotlight to subscribe to changes in trees and kick off reindexing as required. Porting the fsevents API to FreeBSD is fairly straight forward, with one exception: HFS+ offers a much more reliable notion of vnode->path mapping, but it would be interesting to see how well our current vnode->path mapping mechanisms would suffice in practice (since a lot of the edge cases that don't work well with our mapping system are exactly that -- edge cases). Between kernel and userspace parts there's quite a bit to do, but one possibility would be to borrow parts from Mac OS X/etc that we need. For example, do a literal port of the fsevents mechanism from XNU, provide our own implementation that provides a similar API, or provide a new mechanism that meets fseventd's semantic requirements for monitoring. > What I have in mind at the moment would be an indexing based on contents > rather than extended fs attributes. I did not know about the BeOS semantics > capabilities, I will surely have a look at that. I'm probably blending reality with imagination here, but my vague recollection is that the model was a slightly different blend of user vs. application involvement in indexing. For systems like Spotlight, there are no kernel-maintained indexes, the kernel simply provides a change list so that the userspace indexer can go through and apply file type-specific indexes to all files that have changed. So, for example, there are indexers for word files, plain text files, pdf's, and so on. In the BeOS model, or my reinterpretation based on something I read a long time ago and then presumably had dreams about, the split is a bit different: the file system maintains indexes of extended attributes, which are written by applications in order to expose searchable material. For example, a mail application might write out each message as a file, and attach a series of extended attributes, such as subject line, date, author, etc. These extended attributes are then indexed automatically by the file system in order to allow queries to be evaluated. I don't recall how queries and results are expressed, and in particular, whether the queries are processed by the file system (possibly exposed via special APIs or the name space) or userspace (accessing special files maintained by the kernel that are the indexes). It's also worth observing that one of the authors of BFS was Dominic Giampaolo, who now works on Apple's HFS+, and implemented fsevents there as part of their Spotlight project. Robert N M Watson Computer Laboratory University of Cambridge From babkin at verizon.net Thu Apr 2 11:48:28 2009 From: babkin at verizon.net (Sergey Babkin) Date: Thu Apr 2 12:08:19 2009 Subject: Improving the kernel/i386 timecounter performance (GSoC proposal) Message-ID: <6547642.196222.1238698084570.JavaMail.root@vms062.mailsrvcs.net> Apr 2, 2009 01:03:48 AM, [1]peterjeremy@optushome.com.au wrot >On 2009-Mar-30 18:45:30 -0700, Maxim Sobolev <[2]sobomax@freebsd.org> wrote: >>You don't really need to It >>could be done on de certain >>threshold, its >>open/ > >Th >appro some >inf deemed > >A not > in & Does it make sense to even bother with lazy mapping? is a very minor activity compared to mapping and linking the overhead won't be even noticeable. If you more should not make much difference. -SB References 1. 3D"mailto:peterjeremy@optushome.com.au" 2. file://localhost/tmp/3D"m From julian at elischer.org Thu Apr 2 12:18:38 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Apr 2 12:18:50 2009 Subject: Improving the kernel/i386 timecounter performance (GSoC proposal) In-Reply-To: <6547642.196222.1238698084570.JavaMail.root@vms062.mailsrvcs.net> References: <6547642.196222.1238698084570.JavaMail.root@vms062.mailsrvcs.net> Message-ID: <49D50FA6.1020202@elischer.org> Hey Sergey, whatever you are using for a mail client SUCKS real bad at the moment.. it's really messing up your outgoing mails.. note the mail below.... Sergey Babkin wrote: > Apr 2, 2009 01:03:48 AM, [1]peterjeremy@optushome.com.au wrot= : > >On 2009-Mar-30 18:45:30 -0700, Maxim Sobolev <[2]sobomax@freebsd.org> > wrote: > >>You don't really need to =o it on every execve() unconditionally. > It > >>could be done on de=and in libc, so that only when thread pass > certain > >>threshold, =he "common page optimization code" kicks in and does > its > >>open/=map/etc magic. Otherwise, "normal" syscall is performed. > > > >Th=s "optimisation" is premature. First step is to implement an > >appro=ch that always maps (or whatever) the data and then gather > some > >inf=rmation about its overheads in the real world. If they are > deemed > >=xcessive, only then do we start looking at how to improve things. > >A=d IMO, the first step would be to lazily map the page - so it's > not > >=mapped by default but mapped the first time any of the information > in > &=t;it is used. > Does it make sense to even bother with lazy mapping? =fter all, this > is a very minor > activity compared to mapping and linking=he dynamic libc. I think > the overhead > won't be even noticeable. If you=lready map 200 pages, adding one > more should not > make much difference. -SB > > References > > 1. 3D"mailto:peterjeremy@optushome.com.au" > 2. file://localhost/tmp/3D"m_______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From killing at multiplay.co.uk Thu Apr 2 14:13:32 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Thu Apr 2 14:13:39 2009 Subject: How to increase the max pty's on Freebsd 7.0? References: <20090401205306.GO13393@hoeg.nl> <20090402052900.GL2351@stlux503.dsto.defence.gov.au> Message-ID: <33896E239BB44BB98FD2643D8FE5F58C@multiplay.co.uk> 0n Wed, Apr 01, 2009 at 10:53:06PM +0200, Ed Schouten wrote: >You can increase the maximum amount of PTYs by editing a lot of source >files on your system. There is some good news: in -CURRENT we switched >to Unix98-style PTYs (/dev/pts/%u). Right now the maximum amount of PTYs >is limited to 1000 (0 to 999). Thanks for the confirmation I've managed to patch our local source tree to increase this to 1024. Seems the last patch to raise to 512 has one bug so fixed that while I was there. If anyone wants the patch set shout. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From jhb at freebsd.org Thu Apr 2 15:08:47 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Apr 2 15:09:02 2009 Subject: How to increase the max pty's on Freebsd 7.0? In-Reply-To: References: Message-ID: <200904021808.00971.jhb@freebsd.org> On Wednesday 01 April 2009 1:55:12 pm Steven Hartland wrote: > How can I increase the maximum number or ptys available on FreeBSD 7.0? > > It seems that currently the machine is maxing out at 512 but there is > still loads of capacity left on the machine. > > Ideally would like to double at least the number of ttys available, > any help would be most appreciated. http://people.freebsd.org/~jhb/patches/pty_1152.patch This might require 7.1 instead of 7.0 as I simplified the pty allocation code in <= 7.x so that it was easier to add new ones. -- John Baldwin From killing at multiplay.co.uk Thu Apr 2 16:03:08 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Thu Apr 2 16:03:15 2009 Subject: How to increase the max pty's on Freebsd 7.0? References: <200904021808.00971.jhb@freebsd.org> Message-ID: <0D74F409AFDA459696183345C0454DFC@multiplay.co.uk> Yep that's what I came up with after looking though the code thanks for the link though, always good to get confirmation that I didn't miss something. Regards Steve ----- Original Message ----- From: "John Baldwin" > On Wednesday 01 April 2009 1:55:12 pm Steven Hartland wrote: >> How can I increase the maximum number or ptys available on FreeBSD 7.0? >> >> It seems that currently the machine is maxing out at 512 but there is >> still loads of capacity left on the machine. >> >> Ideally would like to double at least the number of ttys available, >> any help would be most appreciated. > > http://people.freebsd.org/~jhb/patches/pty_1152.patch > > This might require 7.1 instead of 7.0 as I simplified the pty allocation code > in <= 7.x so that it was easier to add new ones. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From ambrisko at ambrisko.com Thu Apr 2 16:44:45 2009 From: ambrisko at ambrisko.com (Doug Ambrisko) Date: Thu Apr 2 16:44:56 2009 Subject: watchdog: hw+sw? In-Reply-To: <49D4A16F.6020906@icyb.net.ua> Message-ID: <200904022316.n32NGYWK015340@ambrisko.com> Andriy Gapon writes: | I have some vague thoughts on using SW_WATCHDOG and a hardware watchdog | together. | I think this could be useful but I am not sure how to implement this. | The idea is this: timeout for SW_WATCHDOG is smaller than timeout for hw | wd; when some freeze happens sw wd logic kicks in first, stops hw wd and | produces either panic or ddb prompt; if the freeze is so severe that sw | wd can't run (e.g. hardware is messed up badly) then hw wd performs its | duty. I am mostly interested in having this in unattended mode where kernel | dump could be useful for later analysis but the system should recover in | reasonable time. | | Suggestions, opinions? At prior company I implemented a watchdog before watchdog(4) that did this. I used the HW watchdog to register with the SW watchdog. Then our SW watchdog was ticked via a syctl count down. This way we could implement a fairly arbitrary range of time-outs since most HW is very limited in the time duration and then we didn't really have to worry about it. If the SW watchdog didn't tick in a 10 seconds or so then the machine is probably dead. So we used the HW watchdog to enforce the SW watchdog. It's really nice getting the panic and dump. This worked well for us so I think it is a good idea. Also some HW watchdogs can be told to generate an NMI which can also produce a kernel dump/ddb prompt. I've also implemented some rough code to put an simplified back-trace into the IPMI event log in-case a disk or disk I/O sub-system died. Doug A. From thomas at sanbe-farma.com Thu Apr 2 18:30:04 2009 From: thomas at sanbe-farma.com (Thomas Wahyudi) Date: Thu Apr 2 18:30:11 2009 Subject: Setting the mss for socket In-Reply-To: <49D4C9A0.9000804@freebsdbrasil.com.br> References: <3FD46C21A487490FB15B89E890790121@adnote989> <49D4C9A0.9000804@freebsdbrasil.com.br> Message-ID: <49D56212.1000702@sanbe-farma.com> Patrick Tracanelli wrote: > Luiz Otavio O Souza escreveu: >> Hello hackers, >> >> Is there a way to set the mss for a socket ? Like you can do in linux >> with setsockopt(TCP_MAXSEG) ? >> >> So i can set the maximum size of packets (or sort of) from a simple >> userland program. >> you mean sysctl -w net.inet.tcp.mssdflt=512 ? From perryh at pluto.rain.com Fri Apr 3 01:00:22 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Fri Apr 3 01:05:09 2009 Subject: Setting the mss for socket In-Reply-To: <3FD46C21A487490FB15B89E890790121@adnote989> References: <3FD46C21A487490FB15B89E890790121@adnote989> Message-ID: <49d5c0de.E5bkeKr+p+fg4K00%perryh@pluto.rain.com> "Luiz Otavio O Souza" wrote: > Is there a way to set the mss for a socket ? Like you can do > in linux with setsockopt(TCP_MAXSEG) ? > > So i can set the maximum size of packets (or sort of) from a > simple userland program. Depending on exactly what you need to accomplish, you may find something useful in this thread from last August in freebsd-questions@ setting the other end's TCP segment size From Alexander at Leidinger.net Thu Apr 2 23:46:12 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Fri Apr 3 04:20:57 2009 Subject: watchdog: hw+sw? In-Reply-To: <200904022316.n32NGYWK015340@ambrisko.com> References: <200904022316.n32NGYWK015340@ambrisko.com> Message-ID: <20090403084601.108111xg6o3b49ms@webmail.leidinger.net> Quoting Doug Ambrisko (from Thu, 2 Apr 2009 16:16:34 -0700 (PDT)): > This worked well for us so I think it is a good idea. Also some HW > watchdogs can be told to generate an NMI which can also produce a kernel > dump/ddb prompt. I've also implemented some rough code to put an > simplified back-trace into the IPMI event log in-case a disk or disk > I/O sub-system died. Somewhat related... I have 2 32bit systems with zfs which lock up after a while. The lockup is strictly related to the disks. I can still ping the system just fine, and the HW watchdog seems to still work as intended (or it does not work at all anymore, as there's not automatic reset), but as soon as I want to do something which involves disks (access a webpage located on the zfs disks), I'm lost. The only way to get some useful work done again is to reset manually. Your paragraph above implies that the WD notices that there's a problem with disks. While I know how to teach our watchdogd how to detect this (-e option), we do not have support for this in the basesystem yet. Do you have a patch for /etc/rc.d/watchdogd which allows to specify commands to run via rc.conf or some patch which tells watchdogd to check a file? Bye, Alexander. -- Whatever you want to do, you have to do something else first. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From lists.br at gmail.com Fri Apr 3 04:25:36 2009 From: lists.br at gmail.com (Luiz Otavio O Souza) Date: Fri Apr 3 04:26:09 2009 Subject: Setting the mss for socket References: <3FD46C21A487490FB15B89E890790121@adnote989> <49d5c0de.E5bkeKr+p+fg4K00%perryh@pluto.rain.com> Message-ID: <64D5D9E633734200A603D067ED5A81E9@adnote989> >> Is there a way to set the mss for a socket ? Like you can do >> in linux with setsockopt(TCP_MAXSEG) ? >> >> So i can set the maximum size of packets (or sort of) from a >> simple userland program. > > Depending on exactly what you need to accomplish, you may > find something useful in this thread from last August in > freebsd-questions@ > > setting the other end's TCP segment size Very informative thread, thanks. This thread show me that TCP_MAXSEG is implemented in freebsd but don't work. You can set the setsockopt(IPPROTO_TCP, TCP_MAXSEG), wich will set the tp->t_maxseg, but this value is recalculated at tcp_input, so in short, you cannot set the max segment size for a socket. I've posted a completly wrong patch (from style point-of-view - and using SOL_SOCKET instead of IPPROTO_TCP), but with that patch i'm able to set the mss in iperf. Many thanks, Luiz From redcrash at gmail.com Fri Apr 3 04:36:20 2009 From: redcrash at gmail.com (Harald Servat) Date: Fri Apr 3 04:36:27 2009 Subject: some questions about 32 bit / 64 bit Message-ID: Hello everybody, I have a laptop with a Centrino 2 Duo processor with 4GB of RAM and a dual VGA (one integrated in the mobo and an ATI Radeon). Now it uses the ATI Radeon, but if I set it to use the integrated VGA, the total free RAM drops to 3.X GB. I understand that this is due to sharing memory with the VGA. My first issue is, I'm currently working with Linux and I'm planning to switch to FreeBSD 7.1, but I don't know if switch to 32 or 64 bit (i.e., i386 or amd64). If I switch to the 32 bit version, which is the memory limit of a single user process? Will the entire system (kernel + user processes) be able to use the whole 4GB (or 3.XGB, if I switch to the integrated VGA)? Please note, avoid a war between 32bit vs 64bit benefits/cons. The second issue is about ports, if I install the 64 bit version I would need some libraries in 32 bit mode too. Is the ports system adapted to control these two different ABIs? If not, how do you manage this? Maybe installing FreeBSD twice (one for x86 and another for amd64)? Thank you. -- _________________________________________________________________ Empty your memory, with a free()... like a pointer! If you cast a pointer to an integer, it becomes an integer, if you cast a pointer to a struct, it becomes a struct. The pointer can crash..., and can overflow. Be a pointer my friend... From ivoras at freebsd.org Fri Apr 3 05:45:35 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Fri Apr 3 05:45:42 2009 Subject: some questions about 32 bit / 64 bit In-Reply-To: References: Message-ID: Harald Servat wrote: > My first issue is, I'm currently working with Linux and I'm planning to > switch to FreeBSD 7.1, but I don't know if switch to 32 or 64 bit (i.e., > i386 or amd64). If I switch to the 32 bit version, which is the memory limit On a server, switch to 64 bit. On a desktop machime, go with 32-bit. You will only be able to address slightly over 3 GB no matter which graphics card you use but on the other hand you'll have better supported drivers and 3rd party software. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090403/1b640739/signature.pgp From redcrash at gmail.com Fri Apr 3 06:27:55 2009 From: redcrash at gmail.com (Harald Servat) Date: Fri Apr 3 06:28:02 2009 Subject: some questions about 32 bit / 64 bit In-Reply-To: References: Message-ID: Hi again, 2009/4/3 Ivan Voras > Harald Servat wrote: > > > My first issue is, I'm currently working with Linux and I'm planning to > > switch to FreeBSD 7.1, but I don't know if switch to 32 or 64 bit (i.e., > > i386 or amd64). If I switch to the 32 bit version, which is the memory > limit > > > On a server, switch to 64 bit. > > On a desktop machime, go with 32-bit. You will only be able to address > slightly over 3 GB no matter which graphics card you use but on the > other hand you'll have better supported drivers and 3rd party software. > > I've just seen this topic also being mentioned in http://www.freebsd.org/doc/en/books/faq/compatibility-memory.html And what about the second issue? Thank you very much. -- _________________________________________________________________ Empty your memory, with a free()... like a pointer! If you cast a pointer to an integer, it becomes an integer, if you cast a pointer to a struct, it becomes a struct. The pointer can crash..., and can overflow. Be a pointer my friend... From ambrisko at ambrisko.com Fri Apr 3 07:19:37 2009 From: ambrisko at ambrisko.com (Doug Ambrisko) Date: Fri Apr 3 07:19:44 2009 Subject: watchdog: hw+sw? In-Reply-To: <20090403084601.108111xg6o3b49ms@webmail.leidinger.net> Message-ID: <200904031419.n33EJYb8069855@ambrisko.com> Alexander Leidinger writes: | Quoting Doug Ambrisko (from Thu, 2 Apr 2009 | 16:16:34 -0700 (PDT)): | | > This worked well for us so I think it is a good idea. Also some HW | > watchdogs can be told to generate an NMI which can also produce a kernel | > dump/ddb prompt. I've also implemented some rough code to put an | > simplified back-trace into the IPMI event log in-case a disk or disk | > I/O sub-system died. | | Somewhat related... I have 2 32bit systems with zfs which lock up | after a while. The lockup is strictly related to the disks. I can | still ping the system just fine, and the HW watchdog seems to still | work as intended (or it does not work at all anymore, as there's not | automatic reset), but as soon as I want to do something which involves | disks (access a webpage located on the zfs disks), I'm lost. The only | way to get some useful work done again is to reset manually. Your | paragraph above implies that the WD notices that there's a problem | with disks. Yep, isn't that fun :-( | While I know how to teach our watchdogd how to detect this (-e | option), we do not have support for this in the basesystem yet. Do you | have a patch for /etc/rc.d/watchdogd which allows to specify commands | to run via rc.conf or some patch which tells watchdogd to check a file? We start watchdogd manually with our own rc.d script mainly since I noticed Dell pe2650's do false triggers :-( Also I wanted to check that our app. is functioning so we'd need to start after that. It would be good to add flags option to the stock start-up scripts. Just having watchdogd running without checking on anything real tends to be useless since it is usually swapped in and can run just fine without depending on much of the system. Doug A. From gary.jennejohn at freenet.de Fri Apr 3 07:46:33 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Fri Apr 3 07:47:10 2009 Subject: some questions about 32 bit / 64 bit In-Reply-To: References: Message-ID: <20090403164630.75aa203d@ernst.jennejohn.org> On Fri, 3 Apr 2009 15:27:53 +0200 Harald Servat wrote: > Hi again, > > 2009/4/3 Ivan Voras > > > Harald Servat wrote: > > > > > My first issue is, I'm currently working with Linux and I'm planning to > > > switch to FreeBSD 7.1, but I don't know if switch to 32 or 64 bit (i.e., > > > i386 or amd64). If I switch to the 32 bit version, which is the memory > > limit > > > > > > On a server, switch to 64 bit. > > > > On a desktop machime, go with 32-bit. You will only be able to address > > slightly over 3 GB no matter which graphics card you use but on the > > other hand you'll have better supported drivers and 3rd party software. > > > > > I've just seen this topic also being mentioned in > http://www.freebsd.org/doc/en/books/faq/compatibility-memory.html > > And what about the second issue? > > Thank you very much. > All I can say is that I've been using 64-bit FreeBSD as my desktop for years and never had any real problems. Of course, this is _not_ a laptop, so YMMV. But several people have reported in various MLs that they're using their laptops in 64-bit mode with success. Try it in 64-bit mode. If you have problems, then consider 32-bit mode. --- Gary Jennejohn From julian at elischer.org Fri Apr 3 09:02:02 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Apr 3 09:02:10 2009 Subject: Setting the mss for socket In-Reply-To: <64D5D9E633734200A603D067ED5A81E9@adnote989> References: <3FD46C21A487490FB15B89E890790121@adnote989> <49d5c0de.E5bkeKr+p+fg4K00%perryh@pluto.rain.com> <64D5D9E633734200A603D067ED5A81E9@adnote989> Message-ID: <49D63315.6050108@elischer.org> Luiz Otavio O Souza wrote: >>> Is there a way to set the mss for a socket ? Like you can do >>> in linux with setsockopt(TCP_MAXSEG) ? >>> >>> So i can set the maximum size of packets (or sort of) from a >>> simple userland program. >> >> Depending on exactly what you need to accomplish, you may >> find something useful in this thread from last August in >> freebsd-questions@ >> >> setting the other end's TCP segment size > > Very informative thread, thanks. > > This thread show me that TCP_MAXSEG is implemented in freebsd but don't > work. You can set the setsockopt(IPPROTO_TCP, TCP_MAXSEG), wich will set > the > tp->t_maxseg, but this value is recalculated at tcp_input, so in short, you > cannot set the max segment size for a socket. > > I've posted a completly wrong patch (from style point-of-view - and using > SOL_SOCKET instead of IPPROTO_TCP), but with that patch i'm able to set the > mss in iperf. this thread shoud be in FreeBSD-net@ so tha the right people see it many developers do not read hackers every day as it tends to overload them. > > Many thanks, > Luiz > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From rnoland at FreeBSD.org Fri Apr 3 10:29:17 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Fri Apr 3 10:31:33 2009 Subject: some questions about 32 bit / 64 bit In-Reply-To: References: Message-ID: <1238778425.65025.35.camel@balrog.2hip.net> On Fri, 2009-04-03 at 14:45 +0200, Ivan Voras wrote: > Harald Servat wrote: > > > My first issue is, I'm currently working with Linux and I'm planning to > > switch to FreeBSD 7.1, but I don't know if switch to 32 or 64 bit (i.e., > > i386 or amd64). If I switch to the 32 bit version, which is the memory limit > > > On a server, switch to 64 bit. > > On a desktop machime, go with 32-bit. You will only be able to address > slightly over 3 GB no matter which graphics card you use but on the > other hand you'll have better supported drivers and 3rd party software. All of our drm drivers are safe on amd64. The only thing you get from 32bit is the ability to run the Nvidia blob. If you are trying to do emmulated things like play linux/windows games, then 32bit might be needed, but for normal use graphics isn't a reason not to use amd64. FreeBSD balrog.2hip.net 8.0-CURRENT FreeBSD 8.0-CURRENT #13 r190402M: Tue Mar 24 22:41:47 CDT 2009 rnoland@balrog.2hip.net:/usr/obj/usr/src/sys/BALROG amd64 robert. -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090403/8d2d70b1/attachment.pgp From kostikbel at gmail.com Fri Apr 3 11:46:04 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Apr 3 11:46:11 2009 Subject: some questions about 32 bit / 64 bit In-Reply-To: <1238778425.65025.35.camel@balrog.2hip.net> References: <1238778425.65025.35.camel@balrog.2hip.net> Message-ID: <20090403184554.GZ31897@deviant.kiev.zoral.com.ua> On Fri, Apr 03, 2009 at 12:07:05PM -0500, Robert Noland wrote: > On Fri, 2009-04-03 at 14:45 +0200, Ivan Voras wrote: > > Harald Servat wrote: > > > > > My first issue is, I'm currently working with Linux and I'm planning to > > > switch to FreeBSD 7.1, but I don't know if switch to 32 or 64 bit (i.e., > > > i386 or amd64). If I switch to the 32 bit version, which is the memory limit > > > > > > On a server, switch to 64 bit. > > > > On a desktop machime, go with 32-bit. You will only be able to address > > slightly over 3 GB no matter which graphics card you use but on the > > other hand you'll have better supported drivers and 3rd party software. > > All of our drm drivers are safe on amd64. The only thing you get from > 32bit is the ability to run the Nvidia blob. If you are trying to do > emmulated things like play linux/windows games, then 32bit might be > needed, but for normal use graphics isn't a reason not to use amd64. In fact, I committed the missed bits required for wine/i386 on amd64, several days ago. We did tested that wine and mplayer+win32 codecs work. > > FreeBSD balrog.2hip.net 8.0-CURRENT FreeBSD 8.0-CURRENT #13 r190402M: > Tue Mar 24 22:41:47 CDT 2009 > rnoland@balrog.2hip.net:/usr/obj/usr/src/sys/BALROG amd64 > > robert. > > -- > Robert Noland > FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090403/ec15b469/attachment.pgp From yuri at rawbw.com Fri Apr 3 14:32:50 2009 From: yuri at rawbw.com (Yuri) Date: Fri Apr 3 14:32:57 2009 Subject: Is international support broken is msdosfs file system driver? Message-ID: <49D6807D.1040902@rawbw.com> I have a FAT disk written in Windows that has Chinese characters in file names. When I mount this disk without any special options I see question marks in place of Chinese characters. When I mount with options -D=CP950,-L=zh_TW.Big5 there are still some question marks and garbage characters. When I mount with options -D=CP936,-L=zh_CN.GBK there are also some question marks and garbage characters in place of Chinese. I read the contents with 'ls' command from x-terminal in kde4. Normally Chinese characters are shown ok this way. My question is how to read proper file names from FAT disk in FreeBSD? Also the concept of even having the options like -D=CP950,-L=zh_TW.Big5 seems questionable. What if there are files with names in many encodings are on the same FS? Which options should be used? Shouldn't msdosfs driver just show international characters without any special options like ufs driver normally does? Yuri From jilles at stack.nl Fri Apr 3 14:39:20 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Fri Apr 3 14:39:27 2009 Subject: bin/113860: sh(1): shell is still running when using `sh -c' Message-ID: <20090403213905.GA21297@stack.nl> I think this can be improved. Given that I've been digging in /bin/sh already... Note first that sh already has some of this functionality: % sh -c '{ echo a; sleep 10;}&'; sleep 1; ps T a PID TT STAT TIME COMMAND 94682 p9 Ss 0:00.07 zsh 94702 p9 S 0:00.00 sleep 10 94704 p9 R+ 0:00.00 ps T % This is the EV_EXIT flag to evaltree() and friends, in eval.c. To make this work for '-c', evalstring() needs some flag like EV_EXIT, and parsecmd() needs to tell evalstring() that the command it read is the last (currently, parsecmd() only reports that there is no command anymore; due to the stack-like memory management it is not really possible to read ahead a command). Putting "{\n" and "\n}" around the string could be an alternative for the latter, as any valid string would consist of one (compound) command only. The new mode for evalstring() would only be used for '-c' commands when '-s' is not given. Apart from bash, ksh93 and Solaris /usr/xpg4/bin/sh (which is basically ksh88) also treat simple commands in '-c' this way. So I think the idea is ok. I'm also slightly annoyed by seeing silly 'sh -c blah' processes hanging around, and it is not always possible or desirable to add 'exec'. On another note, the EV_EXIT mode is erroneously still used if a trap on EXIT has been set (or, maybe, any trap at all; particularly if -T is in effect). This means that such traps may not be executed. Most other shells seem to do this right. -- Jilles Tjoelker From ivoras at freebsd.org Sat Apr 4 04:44:03 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sat Apr 4 04:44:10 2009 Subject: Patch for MS Hyper V (virtualization) Message-ID: <9bbcef730904040412h53d58295rf28812be9345529b@mail.gmail.com> Can someone please review and commit (if appropriate) the tweak for Hyper-V shutdown issue at http://shell.peach.ne.jp/aoyama/archives/40 ? The problem is: the VM appears to hang on shutdown without it (hanging the Hyper-V VM with it so the host also can't shutdown or reboot reliably - someone at MS skipped the part where an error in the VM isn't supposed to bring the host down with it) From anti_spamsys at yahoo.com Sat Apr 4 13:18:56 2009 From: anti_spamsys at yahoo.com (Travis Daygale) Date: Sat Apr 4 13:35:27 2009 Subject: compiling root filesystem into kernel (preferably tmpfs root filesystem) Message-ID: <313500.27821.qm@web37106.mail.mud.yahoo.com> In both the loader and kernel compiling doc, I see snippets of information like this: #Make space in the kernel for a root filesystem on a md device.options MD_ROOT_SIZE=10 boot_dfltrootInstructs the kernel to mount the statically compiled-in root file system. My question is, how does one compile a root filesystem into the FreeBSD kernel? ?When mounted, I want this root filesystem to run entirely in memory with no other backing store (not even a readonly flash disc nor other backing media such as DVD/CD). The standard FreeBSD DVD install disc uses just such a root? ?(Though seems to rely heavily on the rescue binaries being on a read only filesystem backed by the install DVD?) I'm still trying to reverse engineer how that was done, without much luck. ? Is there a place/documentation I should be finding? ?PicoBSD, NanoBSD, NFS root diskless systems... all tantalizing close, but not the same thing (read only roots backed by media other than memory). The root filesystem I'm wanting would presumably be in some conceptual sense similar to initramfs in Linux land, if that helps explain what I'm trying to achieve. ?In fact I have a Linux distribution which consists of a single giant kernel image and when boot, runs entirely in memory, the kernel in fact can't read filesystems other than tmpfs because no filesystems are compiled in. ?It appears all of this won't be possible in FreeBSD (looks like ufs is required) but it appears I can get close to this. Indeed, I'd love a way for the root filesystem in FreeBSD to be of type tmpfs, again similar to what is possible on the Linux side, though I'm much less concerned with the type of filesystem (it just needs to be compiled into the FreeBSD kernel and needs to be a memory backed filesystem when it mounts, no other backing store). Thanks in advance! Trever From killing at multiplay.co.uk Sat Apr 4 15:42:16 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Sat Apr 4 15:42:23 2009 Subject: Looking for someone to commit hptmv driver fixes Message-ID: <1783A36C3DCC44D78488093A4984DC16@multiplay.co.uk> Hi guys I'm looking for someone to commit the hptmv v1.16 driver to the main source? Currently this driver in FreeBSD core is at 1.12 which it totally unusable under 7.+, panics on install, as well as being totally unstable on Seagate drives on previous versions. I can provide a full patch which is essentially v1.16 from highpoint + one minor fix for multi card support. If anyone who can do this would let me know, that would be most appreciated as getting a machine working with this card is currently a major PITA involving building a custom install CD which is a very lengthy process :( Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From hansot at iae.nl Sun Apr 5 05:12:02 2009 From: hansot at iae.nl (Hans Ottevanger) Date: Sun Apr 5 05:12:09 2009 Subject: mlockall() failure and direction for possible solution Message-ID: <49D89B50.3000304@iae.nl> Hi folks, As has been noted before, there is an issue with the mlockall() system call always failing on (at least) the amd64 architecture. This is quite evident by the automounter (as configured out-of-the-box) printing error messages on startup like: Couldn't lock process pages in memory using mlockall() I have verified the occurrence of this issue on the amd64 platform on 7.1-STABLE and 8.0-CURRENT. On the i386 platform this problem does not occur. To investigate this issue a bit further I ran the following trivial program: #include #include #include #include int main(int argc, char *argv[]) { if (mlockall(MCL_CURRENT|MCL_FUTURE) == -1) perror(argv[0]); char command[80]; snprintf(command, 80, "procstat -v %d", getpid()); system(command); exit(0); } which yields (using CURRENT-8.0 as of today, on an Intel DP965LT board with a Q6600 and 8 Gbyte RAM, GENERIC kernel stripped of unused devices, output folded to 72 characters per line): /mltest: Resource temporarily unavailable PID START END PRT RES PRES REF SHD FL TP PATH 1064 0x400000 0x401000 r-x 1 0 1 0 CN vn /root/mlockall/mltest 1064 0x500000 0x501000 rw- 1 0 1 0 CN df 1064 0x501000 0x600000 rwx 255 0 1 0 -- df 1064 0x800500000 0x80052c000 r-x 44 0 64 31 CN vn /libexec/ld-elf.so.1 1064 0x80052c000 0x800534000 rw- 8 0 1 0 C- df 1064 0x80062b000 0x800633000 rw- 8 0 1 0 CN vn /libexec/ld-elf.so.1 1064 0x800633000 0x80063f000 rw- 12 0 1 0 C- df 1064 0x80063f000 0x80072e000 r-x 239 0 128 62 CN vn /lib/libc.so.7 1064 0x80072e000 0x80072f000 r-x 1 0 1 0 CN vn /lib/libc.so.7 1064 0x80072f000 0x80082f000 r-x 51 0 128 62 CN vn /lib/libc.so.7 1064 0x80082f000 0x80084f000 rw- 32 0 1 0 C- vn /lib/libc.so.7 1064 0x80084f000 0x800865000 rw- 6 0 1 0 CN df 1064 0x800900000 0x800965000 rw- 101 0 1 0 -- df 1064 0x800965000 0x800a00000 rw- 155 0 1 0 -- df 1064 0x7ffffffe0000 0x800000000000 rwx 3 0 1 0 C- df I have hunted down the exact location in the kernel where the call to mlockall() returns an error (just using printf's, debugging using Firewire proved not to be as trivial to set up as it was just a few years ago). It appears that while wiring the memory, finally vm_fault() is called and it bails out at line 412 of vm_fault.c. The virtual address of the page that the system is attempting to wire (argument vaddr of vm_fault()) is 0x800762000. From the procstat output above it appears that this in the third region backed by /lib/libc.so.7. This made me think that the issue might be somehow related to the way in which dynamic libraries are linked on runtime. Indeed, if above program is linked -statically- it does not fail. Also if the program in compiled and linked -dynamically- on a i386 platform and run on an amd64, it runs successfully. To make a long story at least a bit shorter, I found that the problem is in /usr/src/libexec/rtld_elf/map_object.c at line 156. Here a contiguous region is staked out for the code and data. For the amd64, where the required alignment of the segments is 1 Mbytes, this causes a region to be mapped that is far larger than the library file by which it is backed. Addresses that are not backed by the file cannot be resident and hence the region cannot be locked into memory. On the i386 architecture this problem does not occur since the alignment of the segments is just 4 Kbytes. I suspect that the problem also occurs at least on the sparc64 architecture. As a first step to a possible solution you can apply the attached (provisional) patch, that uses an anonymous, read-only mapping to create the required region. The output of the above program then becomes: PID START END PRT RES PRES REF SHD FL TP PATH 1302 0x400000 0x401000 r-x 1 0 1 0 CN vn /root/mlockall/mltest 1302 0x500000 0x501000 rw- 1 0 1 0 -- df 1302 0x800500000 0x80052c000 r-x 44 0 8 4 CN vn /libexec/ld-elf.so.1 1302 0x80052c000 0x800534000 rw- 8 0 1 0 -- df 1302 0x80062b000 0x800633000 rw- 8 0 1 0 C- vn /libexec/ld-elf.so.1 1302 0x800633000 0x80063f000 rw- 12 0 1 0 -- df 1302 0x80063f000 0x80072e000 r-x 239 0 124 62 CN vn /lib/libc.so.7 1302 0x80072e000 0x80072f000 r-x 1 0 1 0 C- vn /lib/libc.so.7 1302 0x80072f000 0x80082f000 r-- 256 0 1 0 -- df 1302 0x80082f000 0x80084f000 rw- 32 0 1 0 C- vn /lib/libc.so.7 1302 0x80084f000 0x800865000 rw- 22 0 1 0 -- df 1302 0x7ffffffe0000 0x800000000000 rwx 32 0 1 0 -- df i.e. mlockall() does not return an error anymore. I still have the following questions: 1. Is worth the trouble to solve the mlockall() problem at all ? Should I file a PR ? 2. Can someone confirm that it also occurs on the other 64 bit architectures ? 3. It might be more elegant to use PROT_NONE instead of PROT_READ when just staking out the address space. Currently mlockall() returns an error when attempting that, so most likely mlockall() would need to be changed to ignore regions mapped with PROT_NONE. On the other hand, the pthread implementation uses PROT_NONE to create red zones on the stack and mlockall() apparently succeeds with threaded applications (using the provided patch). Any opinions/ideas/hints ? Kind regards, Hans -------------- next part -------------- Index: map_object.c =================================================================== RCS file: /home/ncvs/src/libexec/rtld-elf/map_object.c,v retrieving revision 1.19 diff -u -r1.19 map_object.c --- map_object.c 18 Mar 2009 13:40:37 -0000 1.19 +++ map_object.c 5 Apr 2009 10:53:31 -0000 @@ -153,8 +153,8 @@ mapsize = base_vlimit - base_vaddr; base_addr = hdr->e_type == ET_EXEC ? (caddr_t) base_vaddr : NULL; - mapbase = mmap(base_addr, mapsize, convert_prot(segs[0]->p_flags), - convert_flags(segs[0]->p_flags), fd, base_offset); + mapbase = mmap(base_addr, mapsize, PROT_READ, + MAP_NOCORE|MAP_ANON, -1, 0); if (mapbase == (caddr_t) -1) { _rtld_error("%s: mmap of entire address space failed: %s", path, strerror(errno)); @@ -175,8 +175,7 @@ data_addr = mapbase + (data_vaddr - base_vaddr); data_prot = convert_prot(segs[i]->p_flags); data_flags = convert_flags(segs[i]->p_flags) | MAP_FIXED; - /* Do not call mmap on the first segment - this is redundant */ - if (i && mmap(data_addr, data_vlimit - data_vaddr, data_prot, + if (mmap(data_addr, data_vlimit - data_vaddr, data_prot, data_flags, fd, data_offset) == (caddr_t) -1) { _rtld_error("%s: mmap of data failed: %s", path, strerror(errno)); return NULL; From kostikbel at gmail.com Sun Apr 5 08:59:24 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Apr 5 08:59:32 2009 Subject: mlockall() failure and direction for possible solution In-Reply-To: <49D89B50.3000304@iae.nl> References: <49D89B50.3000304@iae.nl> Message-ID: <20090405155918.GO31897@deviant.kiev.zoral.com.ua> On Sun, Apr 05, 2009 at 01:51:44PM +0200, Hans Ottevanger wrote: > Hi folks, > > As has been noted before, there is an issue with the mlockall() system > call always failing on (at least) the amd64 architecture. This is quite > evident by the automounter (as configured out-of-the-box) printing error > messages on startup like: > > Couldn't lock process pages in memory using mlockall() > > I have verified the occurrence of this issue on the amd64 platform on > 7.1-STABLE and 8.0-CURRENT. On the i386 platform this problem does not > occur. > > To investigate this issue a bit further I ran the following trivial program: > > #include > #include > #include > #include > > int main(int argc, char *argv[]) > { > if (mlockall(MCL_CURRENT|MCL_FUTURE) == -1) > perror(argv[0]); > > char command[80]; > snprintf(command, 80, "procstat -v %d", getpid()); > system(command); > > exit(0); > } > > which yields (using CURRENT-8.0 as of today, on an Intel DP965LT board > with a Q6600 and 8 Gbyte RAM, GENERIC kernel stripped of unused devices, > output folded to 72 characters per line): > > /mltest: Resource temporarily unavailable > PID START END PRT RES PRES REF SHD FL TP > PATH > 1064 0x400000 0x401000 r-x 1 0 1 0 CN vn > /root/mlockall/mltest > 1064 0x500000 0x501000 rw- 1 0 1 0 CN df > 1064 0x501000 0x600000 rwx 255 0 1 0 -- df > 1064 0x800500000 0x80052c000 r-x 44 0 64 31 CN vn > /libexec/ld-elf.so.1 > 1064 0x80052c000 0x800534000 rw- 8 0 1 0 C- df > 1064 0x80062b000 0x800633000 rw- 8 0 1 0 CN vn > /libexec/ld-elf.so.1 > 1064 0x800633000 0x80063f000 rw- 12 0 1 0 C- df > 1064 0x80063f000 0x80072e000 r-x 239 0 128 62 CN vn > /lib/libc.so.7 > 1064 0x80072e000 0x80072f000 r-x 1 0 1 0 CN vn > /lib/libc.so.7 > 1064 0x80072f000 0x80082f000 r-x 51 0 128 62 CN vn > /lib/libc.so.7 > 1064 0x80082f000 0x80084f000 rw- 32 0 1 0 C- vn > /lib/libc.so.7 > 1064 0x80084f000 0x800865000 rw- 6 0 1 0 CN df > 1064 0x800900000 0x800965000 rw- 101 0 1 0 -- df > 1064 0x800965000 0x800a00000 rw- 155 0 1 0 -- df > 1064 0x7ffffffe0000 0x800000000000 rwx 3 0 1 0 C- df > > I have hunted down the exact location in the kernel where the call to > mlockall() returns an error (just using printf's, debugging using > Firewire proved not to be as trivial to set up as it was just a few > years ago). It appears that while wiring the memory, finally vm_fault() > is called and it bails out at line 412 of vm_fault.c. The virtual > address of the page that the system is attempting to wire (argument > vaddr of vm_fault()) is 0x800762000. From the procstat output above it > appears that this in the third region backed by /lib/libc.so.7. > > This made me think that the issue might be somehow related to the way in > which dynamic libraries are linked on runtime. Indeed, if above program > is linked -statically- it does not fail. Also if the program in compiled > and linked -dynamically- on a i386 platform and run on an amd64, it runs > successfully. > > To make a long story at least a bit shorter, I found that the problem is > in /usr/src/libexec/rtld_elf/map_object.c at line 156. Here a contiguous > region is staked out for the code and data. For the amd64, where the > required alignment of the segments is 1 Mbytes, this causes a region to > be mapped that is far larger than the library file by which it is > backed. Addresses that are not backed by the file cannot be resident and > hence the region cannot be locked into memory. On the i386 architecture > this problem does not occur since the alignment of the segments is just > 4 Kbytes. I suspect that the problem also occurs at least on the sparc64 > architecture. > > As a first step to a possible solution you can apply the attached > (provisional) patch, that uses an anonymous, read-only mapping to create > the required region. > > The output of the above program then becomes: > > PID START END PRT RES PRES REF SHD FL TP > PATH > 1302 0x400000 0x401000 r-x 1 0 1 0 CN vn > /root/mlockall/mltest > 1302 0x500000 0x501000 rw- 1 0 1 0 -- df > 1302 0x800500000 0x80052c000 r-x 44 0 8 4 CN vn > /libexec/ld-elf.so.1 > 1302 0x80052c000 0x800534000 rw- 8 0 1 0 -- df > 1302 0x80062b000 0x800633000 rw- 8 0 1 0 C- vn > /libexec/ld-elf.so.1 > 1302 0x800633000 0x80063f000 rw- 12 0 1 0 -- df > 1302 0x80063f000 0x80072e000 r-x 239 0 124 62 CN vn > /lib/libc.so.7 > 1302 0x80072e000 0x80072f000 r-x 1 0 1 0 C- vn > /lib/libc.so.7 > 1302 0x80072f000 0x80082f000 r-- 256 0 1 0 -- df > 1302 0x80082f000 0x80084f000 rw- 32 0 1 0 C- vn > /lib/libc.so.7 > 1302 0x80084f000 0x800865000 rw- 22 0 1 0 -- df > 1302 0x7ffffffe0000 0x800000000000 rwx 32 0 1 0 -- df > > i.e. mlockall() does not return an error anymore. > > I still have the following questions: > > 1. Is worth the trouble to solve the mlockall() problem at all ? Should > I file a PR ? Yes. Do as you want, but I see no reason. Your analisys looks correct and useful. > > 2. Can someone confirm that it also occurs on the other 64 bit > architectures ? > > 3. It might be more elegant to use PROT_NONE instead of PROT_READ when > just staking out the address space. Currently mlockall() returns an > error when attempting that, so most likely mlockall() would need to be > changed to ignore regions mapped with PROT_NONE. On the other hand, the > pthread implementation uses PROT_NONE to create red zones on the stack > and mlockall() apparently succeeds with threaded applications (using the > provided patch). Any opinions/ideas/hints ? I think that it is better to unmap the holes, instead of making some mapping. Please, try this patch instead. diff --git a/libexec/rtld-elf/map_object.c b/libexec/rtld-elf/map_object.c index 2d06074..3266af0 100644 --- a/libexec/rtld-elf/map_object.c +++ b/libexec/rtld-elf/map_object.c @@ -83,6 +83,7 @@ map_object(int fd, const char *path, const struct stat *sb) Elf_Addr bss_vaddr; Elf_Addr bss_vlimit; caddr_t bss_addr; + size_t hole; hdr = get_elf_header(fd, path); if (hdr == NULL) @@ -91,8 +92,7 @@ map_object(int fd, const char *path, const struct stat *sb) /* * Scan the program header entries, and save key information. * - * We rely on there being exactly two load segments, text and data, - * in that order. + * We expect that the loadable segments are ordered by load address. */ phdr = (Elf_Phdr *) ((char *)hdr + hdr->e_phoff); phsize = hdr->e_phnum * sizeof (phdr[0]); @@ -214,6 +214,17 @@ map_object(int fd, const char *path, const struct stat *sb) return NULL; } } + + /* Unmap the region between two non-adjusted ELF segments */ + if (i < nsegs) { + hole = trunc_page(segs[i + 1]->p_vaddr) - bss_vlimit; + if (hole > 0 && munmap(mapbase + bss_vlimit, hole) == -1) { + _rtld_error("%s: munmap hole failed: %s", path, + strerror(errno)); + return NULL; + } + } + if (phdr_vaddr == 0 && data_offset <= hdr->e_phoff && (data_vlimit - data_vaddr + data_offset) >= (hdr->e_phoff + hdr->e_phnum * sizeof (Elf_Phdr))) { -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090405/d2dbd338/attachment.pgp From babkin at verizon.net Sun Apr 5 09:24:26 2009 From: babkin at verizon.net (Sergey Babkin) Date: Sun Apr 5 10:05:30 2009 Subject: Patch for MS Hyper V (virtualization) Message-ID: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> Apr 4, 2009 02:10:23 PM, ivoras@freebsd.org wrote: >Can someo >Hyper-V shu http://shell.peach.ne.jp/aoyama/archives/40 >? > (hanging >the Hyper-V VM with it so the host also can't shutdown or reboot >re >isn't I don't have the commit Yes, Hyper-V does not like th Very specifically, writing the base screws up something tha and writi back the same value has this effect. So the patch is valid. and I' if if would break some real 21140 chip out there. If the dri the same as another one I've seen, the driver tries to align t 0x80, and in the simulated 21140 it's already ali couldn't say it for sure. I'd do it dif the same that was read, Let me see, maybe I'll make a dif -SB From fbsdhackers at beasties.demon.nl Sun Apr 5 11:43:01 2009 From: fbsdhackers at beasties.demon.nl (Hans Ottevanger) Date: Sun Apr 5 11:43:08 2009 Subject: mlockall() failure and direction for possible solution In-Reply-To: <20090405155918.GO31897@deviant.kiev.zoral.com.ua> References: <49D89B50.3000304@iae.nl> <20090405155918.GO31897@deviant.kiev.zoral.com.ua> Message-ID: <49D8F7E6.8010105@beasties.demon.nl> Kostik Belousov wrote: > On Sun, Apr 05, 2009 at 01:51:44PM +0200, Hans Ottevanger wrote: >> Hi folks, >> >> As has been noted before, there is an issue with the mlockall() system >> call always failing on (at least) the amd64 architecture. This is quite >> evident by the automounter (as configured out-of-the-box) printing error >> messages on startup like: >> >> Couldn't lock process pages in memory using mlockall() >> >> I have verified the occurrence of this issue on the amd64 platform on >> 7.1-STABLE and 8.0-CURRENT. On the i386 platform this problem does not >> occur. >> >> To investigate this issue a bit further I ran the following trivial program: >> >> #include >> #include >> #include >> #include >> >> int main(int argc, char *argv[]) >> { >> if (mlockall(MCL_CURRENT|MCL_FUTURE) == -1) >> perror(argv[0]); >> >> char command[80]; >> snprintf(command, 80, "procstat -v %d", getpid()); >> system(command); >> >> exit(0); >> } >> >> which yields (using CURRENT-8.0 as of today, on an Intel DP965LT board >> with a Q6600 and 8 Gbyte RAM, GENERIC kernel stripped of unused devices, >> output folded to 72 characters per line): >> >> /mltest: Resource temporarily unavailable >> PID START END PRT RES PRES REF SHD FL TP >> PATH >> 1064 0x400000 0x401000 r-x 1 0 1 0 CN vn >> /root/mlockall/mltest >> 1064 0x500000 0x501000 rw- 1 0 1 0 CN df >> 1064 0x501000 0x600000 rwx 255 0 1 0 -- df >> 1064 0x800500000 0x80052c000 r-x 44 0 64 31 CN vn >> /libexec/ld-elf.so.1 >> 1064 0x80052c000 0x800534000 rw- 8 0 1 0 C- df >> 1064 0x80062b000 0x800633000 rw- 8 0 1 0 CN vn >> /libexec/ld-elf.so.1 >> 1064 0x800633000 0x80063f000 rw- 12 0 1 0 C- df >> 1064 0x80063f000 0x80072e000 r-x 239 0 128 62 CN vn >> /lib/libc.so.7 >> 1064 0x80072e000 0x80072f000 r-x 1 0 1 0 CN vn >> /lib/libc.so.7 >> 1064 0x80072f000 0x80082f000 r-x 51 0 128 62 CN vn >> /lib/libc.so.7 >> 1064 0x80082f000 0x80084f000 rw- 32 0 1 0 C- vn >> /lib/libc.so.7 >> 1064 0x80084f000 0x800865000 rw- 6 0 1 0 CN df >> 1064 0x800900000 0x800965000 rw- 101 0 1 0 -- df >> 1064 0x800965000 0x800a00000 rw- 155 0 1 0 -- df >> 1064 0x7ffffffe0000 0x800000000000 rwx 3 0 1 0 C- df >> >> I have hunted down the exact location in the kernel where the call to >> mlockall() returns an error (just using printf's, debugging using >> Firewire proved not to be as trivial to set up as it was just a few >> years ago). It appears that while wiring the memory, finally vm_fault() >> is called and it bails out at line 412 of vm_fault.c. The virtual >> address of the page that the system is attempting to wire (argument >> vaddr of vm_fault()) is 0x800762000. From the procstat output above it >> appears that this in the third region backed by /lib/libc.so.7. >> >> This made me think that the issue might be somehow related to the way in >> which dynamic libraries are linked on runtime. Indeed, if above program >> is linked -statically- it does not fail. Also if the program in compiled >> and linked -dynamically- on a i386 platform and run on an amd64, it runs >> successfully. >> >> To make a long story at least a bit shorter, I found that the problem is >> in /usr/src/libexec/rtld_elf/map_object.c at line 156. Here a contiguous >> region is staked out for the code and data. For the amd64, where the >> required alignment of the segments is 1 Mbytes, this causes a region to >> be mapped that is far larger than the library file by which it is >> backed. Addresses that are not backed by the file cannot be resident and >> hence the region cannot be locked into memory. On the i386 architecture >> this problem does not occur since the alignment of the segments is just >> 4 Kbytes. I suspect that the problem also occurs at least on the sparc64 >> architecture. >> >> As a first step to a possible solution you can apply the attached >> (provisional) patch, that uses an anonymous, read-only mapping to create >> the required region. >> >> The output of the above program then becomes: >> >> PID START END PRT RES PRES REF SHD FL TP >> PATH >> 1302 0x400000 0x401000 r-x 1 0 1 0 CN vn >> /root/mlockall/mltest >> 1302 0x500000 0x501000 rw- 1 0 1 0 -- df >> 1302 0x800500000 0x80052c000 r-x 44 0 8 4 CN vn >> /libexec/ld-elf.so.1 >> 1302 0x80052c000 0x800534000 rw- 8 0 1 0 -- df >> 1302 0x80062b000 0x800633000 rw- 8 0 1 0 C- vn >> /libexec/ld-elf.so.1 >> 1302 0x800633000 0x80063f000 rw- 12 0 1 0 -- df >> 1302 0x80063f000 0x80072e000 r-x 239 0 124 62 CN vn >> /lib/libc.so.7 >> 1302 0x80072e000 0x80072f000 r-x 1 0 1 0 C- vn >> /lib/libc.so.7 >> 1302 0x80072f000 0x80082f000 r-- 256 0 1 0 -- df >> 1302 0x80082f000 0x80084f000 rw- 32 0 1 0 C- vn >> /lib/libc.so.7 >> 1302 0x80084f000 0x800865000 rw- 22 0 1 0 -- df >> 1302 0x7ffffffe0000 0x800000000000 rwx 32 0 1 0 -- df >> >> i.e. mlockall() does not return an error anymore. >> >> I still have the following questions: >> >> 1. Is worth the trouble to solve the mlockall() problem at all ? Should >> I file a PR ? > Yes. Do as you want, but I see no reason. > > Your analisys looks correct and useful. > >> 2. Can someone confirm that it also occurs on the other 64 bit >> architectures ? >> >> 3. It might be more elegant to use PROT_NONE instead of PROT_READ when >> just staking out the address space. Currently mlockall() returns an >> error when attempting that, so most likely mlockall() would need to be >> changed to ignore regions mapped with PROT_NONE. On the other hand, the >> pthread implementation uses PROT_NONE to create red zones on the stack >> and mlockall() apparently succeeds with threaded applications (using the >> provided patch). Any opinions/ideas/hints ? > I think that it is better to unmap the holes, instead of making some > mapping. > In that way you free up virtual address space and make it available to the next call to mmap() with the first argument set to zero (i.e. where the caller does not care about the exact location), if the requested space fits in the hole you left. In this way unrelated mappings could end up between the regions of you dynamic libraries. I don't think that would be desirable. Using PROT_NONE would prevent such a mix up: the address space is still there, but not accessible. BTW: Note that even in the current implementation there is a hole available between the regions for /libexec/ld-elf.so.1 itself, starting at 0x800534000 in the above examples. > Please, try this patch instead. > I have tried your patch on my amd64 8.0-CURRENT system and it works perfectly with the described test program. I will stress test it later by running a "make buildworld". In can easily be demonstrated however, that allocations using mmap() as described above may end up in "strange" locations. > diff --git a/libexec/rtld-elf/map_object.c b/libexec/rtld-elf/map_object.c > index 2d06074..3266af0 100644 > --- a/libexec/rtld-elf/map_object.c > +++ b/libexec/rtld-elf/map_object.c > @@ -83,6 +83,7 @@ map_object(int fd, const char *path, const struct stat *sb) > Elf_Addr bss_vaddr; > Elf_Addr bss_vlimit; > caddr_t bss_addr; > + size_t hole; > > hdr = get_elf_header(fd, path); > if (hdr == NULL) > @@ -91,8 +92,7 @@ map_object(int fd, const char *path, const struct stat *sb) > /* > * Scan the program header entries, and save key information. > * > - * We rely on there being exactly two load segments, text and data, > - * in that order. > + * We expect that the loadable segments are ordered by load address. > */ > phdr = (Elf_Phdr *) ((char *)hdr + hdr->e_phoff); > phsize = hdr->e_phnum * sizeof (phdr[0]); > @@ -214,6 +214,17 @@ map_object(int fd, const char *path, const struct stat *sb) > return NULL; > } > } > + > + /* Unmap the region between two non-adjusted ELF segments */ > + if (i < nsegs) { > + hole = trunc_page(segs[i + 1]->p_vaddr) - bss_vlimit; > + if (hole > 0 && munmap(mapbase + bss_vlimit, hole) == -1) { > + _rtld_error("%s: munmap hole failed: %s", path, > + strerror(errno)); > + return NULL; > + } > + } > + > if (phdr_vaddr == 0 && data_offset <= hdr->e_phoff && > (data_vlimit - data_vaddr + data_offset) >= > (hdr->e_phoff + hdr->e_phnum * sizeof (Elf_Phdr))) { From Alexander at Leidinger.net Sun Apr 5 11:40:42 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sun Apr 5 11:44:15 2009 Subject: watchdog: hw+sw? In-Reply-To: <200904031419.n33EJYb8069855@ambrisko.com> References: <20090403084601.108111xg6o3b49ms@webmail.leidinger.net> <200904031419.n33EJYb8069855@ambrisko.com> Message-ID: <20090405204028.0000654f@unknown> On Fri, 3 Apr 2009 07:19:34 -0700 (PDT) Doug Ambrisko wrote: > We start watchdogd manually with our own rc.d script mainly since > I noticed Dell pe2650's do false triggers :-( Also I wanted to check > that our app. is functioning so we'd need to start after that. It > would be good to add flags option to the stock start-up scripts. > Just having watchdogd running without checking on anything real tends > to be useless since it is usually swapped in and can run just fine > without depending on much of the system. In the mean time I noticed that the watchdogd can be started with flags just by adding watchdogd_flags="..." to rc.conf. So I just needed to write a shell script which checks the disks which cause problems sometimes, and add a line to rc.conf and now I'm satisfied (... but this should be documented somewhere more obvious). For your app watching stuff, why not write a shell script which checks for a file in a mfs which the app-start creates (if the file is there and the pid not, the app died), and let the WD run this script. This way you can use the default start script. Bye, Alexander. From brd at FreeBSD.org Sun Apr 5 13:23:52 2009 From: brd at FreeBSD.org (Brad Davis) Date: Sun Apr 5 13:23:59 2009 Subject: FreeBSD Status Reports due April 20th, 2009 Message-ID: <20090405195109.GB25817@valentine.liquidneon.com> Hi Everyone, We would like to remind everybody who has exciting news to share to write a report about their project. This is a good way to improve exposure of your work, receive feedback and help. We are looking forward to your reports. As always you can either use the template or the CGI generator and mail the output to monthly@ by Wednesday April 20th, 2009. http://www.freebsd.org/news/status/ http://www.freebsd.org/cgi/monthly.cgi http://www.freebsd.org/news/status/report-sample.xml Regards, Brad Davis From naylor.b.david at gmail.com Sun Apr 5 13:39:22 2009 From: naylor.b.david at gmail.com (David Naylor) Date: Sun Apr 5 15:25:14 2009 Subject: compiling root filesystem into kernel (preferably tmpfs root filesystem) In-Reply-To: <313500.27821.qm@web37106.mail.mud.yahoo.com> References: <313500.27821.qm@web37106.mail.mud.yahoo.com> Message-ID: <200904052214.08866.naylor.b.david@gmail.com> On Saturday 04 April 2009 21:52:14 Travis Daygale wrote: > In both the loader and kernel compiling doc, I see snippets of information > like this: #Make space in the kernel for a root filesystem on a md > device.options MD_ROOT_SIZE=10 boot_dfltrootInstructs the kernel to mount > the statically compiled-in root file system. Yes, you can compile a fs image into the kernel. This however will be static and if you want editing then will need to use unionfs with mdmfs. tmpfs cannot be used for this as it does not yet (to my knowledge) support unionfs. > My question is, how does one compile a root filesystem into the FreeBSD > kernel? ? Personally I wouldn't recommend taking the approach you want to do. There is simply an easier way. Just load the fs image as a kernel module (sort of). You get the same effect with more flexibility. (I'll explain below). > When mounted, I want this root filesystem to run entirely in > memory with no other backing store (not even a readonly flash disc nor > other backing media such as DVD/CD). This is do-able. I've created a CD that ejects it self when loaded completely. (I thought it was cool :-)) > The standard FreeBSD DVD install disc > uses just such a root? ?(Though seems to rely heavily on the rescue > binaries being on a read only filesystem backed by the install DVD?) Can't comment, haven't used the FreeBSD CD/DVD's for years (since 6.0) > I'm > still trying to reverse engineer how that was done, without much luck. Is > there a place/documentation I should be finding? ?PicoBSD, NanoBSD, NFS > root diskless systems... all tantalizing close, but not the same thing > (read only roots backed by media other than memory). The root filesystem > I'm wanting would presumably be in some conceptual sense similar to > initramfs in Linux land, if that helps explain what I'm trying to achieve. I'll give you a quick tutorial below (if you need further help please let me know). > ?In fact I have a Linux distribution which consists of a single giant > kernel image and when boot, runs entirely in memory, the kernel in fact > can't read filesystems other than tmpfs because no filesystems are compiled > in. ? I think you are getting some concepts confused here. > It appears all of this won't be possible in FreeBSD (looks like ufs is > required) but it appears I can get close to this. Indeed, I'd love a way > for the root filesystem in FreeBSD to be of type tmpfs, again similar to > what is possible on the Linux side, though I'm much less concerned with the > type of filesystem (it just needs to be compiled into the FreeBSD kernel > and needs to be a memory backed filesystem when it mounts, no other backing > store). Thanks in advance! Ok, onto my explanation: my understanding is that you want to have some type of FreeBSD based system that is loaded completely into RAM. Once loaded (at boot time) this system should have no reliance on any medium (other than RAM). This system, once loaded, should behave the same as if it were backed by a hard drive (except the statefullness after reboots). i.e. the filesystem should be editable. This is of course very possible. STAGE 1: The filesystem In order to have the system in memory one needs a delivery method. As mentioned before this is achieved using a MD device. MD's can have three types of backing, a vnode (aka file, on a CD/DVD or hard drive), or memory (purely in memory, AFAIK no swapping out) and swap (same as memory except my get swapped out). Ignoring the subtle difference between memory and swap, swap is better. Technically the forth is preload but this is the same as memory but done by the loader. See md(4) for further details. Now, MD just imitates a hard drive, one still needs the data to put there. Any filesystem will suite this purpose. My preference is UFS but ISO9660 works just as easily (other options are not so easy but still do-able). Now, to create the filesystem, just install your system into a folder. e.g. # su - # mkdir /tmp/world # cd src; make world kernel distribution DESTDIR=/tmp/world # cp /path/to/packages /tmp/world/tmp # chroot /tmp/world sh -c 'cd /tmp ; pkg_add *' # rm -rf /tmp/world/tmp/* # cat > /tmp/world/etc/fstab < _EOF proc /proc procfs rw 0 0 tmpfs /tmp tmpfs rw 0 0 _EOF * Now, edit /tmp/world as you require to make it work as you want (the easiest way is to create a Flash stick [as per my script], edit the system live and then copy all changes across). * STAGE 2: The filesystem image *** For UFS *** # makefs /tmp/world.ufs /tmp/world # MDDEV=$(mdconfig -a -t vnode /tmp/world.ufs) # tunefs -L ROOTFS /dev/$MDDEV # mdconfig -d -u $MDDEV *** For CD9660 *** # mkisofs -quiet -sysid FREEBSD -rock -untranslated-filenames -max-iso9660-filenames -iso-level 4 -volid DragonBSD -o $WORKDIR/DragonBSD.iso -volid DragonBSD -o /tmp/world.iso /tmp/world Now, since these images are often much larger then required I prefer to compress them. This allows more programs to be added to the image and it takes up less memory during runtime (not to mention faster load times). [I assume UFS option, do the appropriate for CD9660 option] # mkuzip -s 8192 -o /tmp/world.uzip /tmp/world.ufs STAGE 3: Loading the filesystem image Now you have an image that can be loaded on boot, to do so add the following to loader.conf # cd /path/to/boot/system/image # cat >> boot/loader.conf < _EOF rootfs_load="YES" rootfs_type="mfs_root" rootfs_name="/boot/world.uzip" _EOF # cp /tmp/world.uzip boot/ Now, to inform the system that you want it to boot off the memory system # cat >> boot/loader.conf < _EOF vfs.root.mountfrom="ufs:/dev/ufs/ROOTFS" _EOF STAGE 4: Making the Live System editable Now, to make the whole system editable (everything) is quite the challenge and requires a change in the way the previous stages are done. The concept is simple though. First: Because the filesystem was compressed (using mkuzip), it cannot be written to. If the system were not compressed and extra space was allocated to the UFS image then it can be editable. Even the extra size at load time can be compensated for (since loader supports compressed modules [both gzip and bzip2] however you will be running the full image uncompressed in memory. It is faster but much more expensive. Just to give you an idea, I have gotten a 700MB system to boot and run off a mini CD (210MB) and a system with 512MB of RAM, using the compressed approach with everything editable :-). To do this approach requires some changes to stage 2. Basically, after completing the approach for UFS image do the following # EXTRA_SIZE=32 # SIZE=$(($(du -m /tmp/world.ufs) + EXTRA_SIZE)) # dd if=/dev/zero of=/tmp/world.ufs count=$SIZE bs=1m # NB, use zero to allow for compression # MDDEV=$(mdconfig -a -t vnode /tmp/world.ufs) # newfs -L ROOTFS -o space /dev/$MDDEV # mkdir /tmp/btstrp # mount /dev/$MDDEV /tmp/btstrp # (cd /tmp/world; tar -cf - .) | (cd /tmp/btstrp; tar -xf -) # umount /tmp/btstrp # mdconfig -d -u $MDDEV Next, DO NOT compress the image with mkuzip, instead do: # gzip -9 /tmp/world.ufs This requires either geom_uzip loaded or compiled into the kernel. and, instead of the first part of stage 3 do # cd /path/to/boot/system/image # cat >> boot/loader.conf < _EOF rootfs_load="YES" rootfs_type="mfs_root" rootfs_name="/boot/world.ufs" _EOF # cp /tmp/world.ufs.gz boot/ NOTE: this approach cannot be done using cd9660. The second approach, the one I prefer requires a double boot image (one inside the other), where the one acts as a boot strap, mdconfig and mount's the embedded second image, creates a editable fs using mdmfs and unionfs it over the second image. This is done through using # cat >> boot/loader.conf < _EOF init_script="/chroot.sh" init_chroot="/base" where /chroot.sh basically does: mount -o ro /dev/$(mdconfig -a -t vnode -o readonly -f /world.uzip).uzip /base mdmfs -s 32m md /tmp mount -t unionfs -o noatime -o copymode=transparent /tmp/base It would be very nice to add unionfs support to tmpfs but not yet :-(. The second approach I have not described fully, it is quite a bit more involved than the first but has great benefits, memory wise. If you want more details about this approach please let me know. I've created a set of scripts that are designed to create LiveCD/DVD/Flash of FreeBSD. There are three cd9660 images that it produces: 1) CD backed live system (using compressed ufs image) 2) Memory backed live system (using compressed ufs image) 3) CD backed live system (no compression). And one Flash memory based image: 1) Flash based memory (using compressed ufs image and perpetual state overlay) [similar to option 1 above except the changes are permanent). If you would like access to these scripts please let me know and I will gladly forward them to you. Also if you have any questions or want further clarification please ask. Regards, David Disclaimer: The commands may be incorrect but the procedure has been tried and tested. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090405/de5cd97c/attachment.pgp From ed at 80386.nl Mon Apr 6 04:25:45 2009 From: ed at 80386.nl (Ed Schouten) Date: Mon Apr 6 04:25:55 2009 Subject: Decreasiong default dcons poll hz Message-ID: <20090406112438.GA13393@hoeg.nl> Hi all, I was just discussing with rwatson on IRC that the default polling frequency used by dcons may be a little too high. It's currently set to 100 Hz. I guess it should probably use 25 Hz at most. My question is if anyone using dcons could try decreasing kern.dcons.poll_hz to 25 and let me know whether that's still usable. Thanks! -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090406/bdd574b5/attachment.pgp From gabriele.modena at gmail.com Mon Apr 6 06:18:56 2009 From: gabriele.modena at gmail.com (Gabriele Modena) Date: Mon Apr 6 06:19:04 2009 Subject: GSoC: Semantic File System In-Reply-To: References: <1fe1d5d60903210422g70efef15hdd685695cdf8df3c@mail.gmail.com> <1fe1d5d60904020904ya6dcb00h54a54d6a00e2bd0@mail.gmail.com> Message-ID: <1fe1d5d60904060618j1f68b45fl7810169d66890fd6@mail.gmail.com> On Thu, Apr 2, 2009 at 7:26 PM, Robert Watson wrote: >> In this moment I am considering also an userspace approach similar to >> Spotlight/Beagles, but I don't know how I could propose this as a FreeBSD >> GSoC project. > > I think that would make a fine GSoC proposal. Keep in mind that one of the > premises of Spotlight is the fsevents kernel feature, and fseventsd, which > allow Spotlight to subscribe to changes in trees and kick off reindexing as > required. Porting the fsevents API to FreeBSD is fairly straight forward, > with one exception: HFS+ offers a much more reliable notion of vnode->path > mapping, but it would be interesting to see how well our current vnode->path > mapping mechanisms would suffice in practice (since a lot of the edge cases > that don't work well with our mapping system are exactly that -- edge > cases). This is in case of using UFS/FFS as the base fs or is a more general VFS issue? And what about ZFS? Since apple has not (partially) started to support it, IMHO it may be an interesting fs to investigate. > Between kernel and userspace parts there's quite a bit to do, but one > possibility would be to borrow parts from Mac OS X/etc that we need. For > example, do a literal port of the fsevents mechanism from XNU, provide our > own implementation that provides a similar API, or provide a new mechanism > that meets fseventd's semantic requirements for monitoring. This would definitely be an interesting approach. One of my original ideas was to have a look at how inotify has been implemented in linux, but probably fsevents would be a better choice (also license wise). > I'm probably blending reality with imagination here, but my vague > recollection is that the model was a slightly different blend of user vs. > application involvement in indexing. For how I see it now the steps for my work could be: 1) port/implement an event notification feature; 2) build a userspace indexer; 3) write a gui/search tool on top of it. > In the BeOS model, or my reinterpretation based on something I read a long > time ago and then presumably had dreams about, the split is a bit different: > the file system maintains indexes of extended attributes, which are written > by applications in order to expose searchable material. This sounds to me like adding another layer/proxy between the applications and the actual data. I found some material about node watch and extended attributes that I'm going to study in these days. > It's also worth observing that one of the authors of BFS was Dominic > Giampaolo, who now works on Apple's HFS+, and implemented fsevents there as > part of their Spotlight project. Thanks a lot for you feedback, you provided me a with lot of very interesting material to look up! Cheers. From decado at gmail.com Mon Apr 6 06:22:21 2009 From: decado at gmail.com (k) Date: Mon Apr 6 06:22:28 2009 Subject: [PATCH] Support for thresholds in du(1) In-Reply-To: <20090311130557.GJ31961@hoeg.nl> References: <200902251724.40212.fbsd.hackers@rachie.is-a-geek.net> <20090311130557.GJ31961@hoeg.nl> Message-ID: <49DB4C20.5010107@gmail.com> Ed Schouten wrote: > * Mel wrote: >> Example usage: >> # du -xht 20m . >> 29M ./contrib/binutils >> 52M ./contrib/gcc >> 237M ./contrib >> 35M ./crypto >> 28M ./lib >> 20M ./share >> 55M ./sys/dev >> 139M ./sys >> 545M . > > Ooh! That looks awesome! > Would this option benefit from perhaps swinging both ways? As in: du -t +20m (show >20mb) du -t -20m (show <20mb) Or something along those lines From babkin at verizon.net Mon Apr 6 08:35:42 2009 From: babkin at verizon.net (Sergey Babkin) Date: Mon Apr 6 08:51:06 2009 Subject: Improving the kernel/i386 timecounter performance (GSoC proposal) Message-ID: <13591482.311321.1239032116786.JavaMail.root@vms068.mailsrvcs.net> Apr 4, 2009 02:02:07 PM, julian@elischer.org wrote: >Hey Sergey, whatever you are using for a mail client SUCKS >real bad at the moment.. > > it's really messing up your outgoing mails.. > >note the mail below.... Looks like using the text mode didn't help :-( Oh, well, I guess I should not write replies from the web interface. -SB From jhb at freebsd.org Mon Apr 6 09:10:27 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Apr 6 09:11:00 2009 Subject: Patch for MS Hyper V (virtualization) In-Reply-To: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> Message-ID: <200904061154.19601.jhb@freebsd.org> On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: > > Apr 4, 2009 02:10:23 PM, ivoras@freebsd.org wrote: > >Can someo=ne please review and commit (if appropriate) the tweak for > >Hyper-V shu=tdown issue at > http://shell.peach.ne.jp/aoyama/archives/40 > >? > > > =>>The problem is: the VM appears to hang on shutdown without it > (hanging > >the Hyper-V VM with it so the host also can't shutdown or reboot > >re=liably - someone at MS skipped the part where an error in the VM > >isn't=supposed to bring the host down with it) > I don't have the commit =permission any more but I can review :-) > Yes, Hyper-V does not like th=e writes into the PCI config space. > Very specifically, > writing the base=register window address of the simulated 21140 > screws up something > tha=t prevents the VM from shutting down. Interestingly, even reading > and writi=ng > back the same value has this effect. So the patch is valid. > =>I don't particularly like the hackish checking for the 21140 chip, > and I'=m not sure > if if would break some real 21140 chip out there. If the dri=ver does > the same as another > one I've seen, the driver tries to align t=he register window to > 0x80, and in the > simulated 21140 it's already ali=gned. I've had a quick look but > couldn't say it > for sure. I'd do it dif=ferently: check if the value being written is > the same that was read, > =and skip the write in this case. > Let me see, maybe I'll make a dif=ferent patch. Hmm, the problem is we need to be able to write to BARs to size them. Any OS needs to be able to do this to know what address space regions are being decoded by devices. We can't avoid writing to BARs. -- John Baldwin From ivoras at freebsd.org Mon Apr 6 10:07:55 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Apr 6 10:08:01 2009 Subject: Patch for MS Hyper V (virtualization) In-Reply-To: <200904061154.19601.jhb@freebsd.org> References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904061154.19601.jhb@freebsd.org> Message-ID: <9bbcef730904061007y66a8440al3c43a6a6b6cd6ed6@mail.gmail.com> 2009/4/6 John Baldwin : > On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: > Hmm, the problem is we need to be able to write to BARs to size them. ?Any OS > needs to be able to do this to know what address space regions are being > decoded by devices. ?We can't avoid writing to BARs. I have only vague idea what BARs are and if it's the correct diagnosis in this case, but the fact is that other operating systems (Windows, Linux tested) work, so either there is a way around it or the original premise is wrong-ish. From imp at bsdimp.com Mon Apr 6 10:23:13 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Mon Apr 6 10:23:21 2009 Subject: Patch for MS Hyper V (virtualization) In-Reply-To: <200904061154.19601.jhb@freebsd.org> References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904061154.19601.jhb@freebsd.org> Message-ID: <20090406.111755.1973602189.imp@bsdimp.com> In message: <200904061154.19601.jhb@freebsd.org> John Baldwin writes: : On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: : > : > Apr 4, 2009 02:10:23 PM, ivoras@freebsd.org wrote: : > >Can someo=ne please review and commit (if appropriate) the tweak for : > >Hyper-V shu=tdown issue at : > http://shell.peach.ne.jp/aoyama/archives/40 : > >? : > > : > =>>The problem is: the VM appears to hang on shutdown without it : > (hanging : > >the Hyper-V VM with it so the host also can't shutdown or reboot : > >re=liably - someone at MS skipped the part where an error in the VM : > >isn't=supposed to bring the host down with it) : > I don't have the commit =permission any more but I can review :-) : > Yes, Hyper-V does not like th=e writes into the PCI config space. Why not? We need to understand exactly what it doesn't like because this is non-standard compliant behavior. : > Very specifically, : > writing the base=register window address of the simulated 21140 : > screws up something : > tha=t prevents the VM from shutting down. Interestingly, even reading : > and writi=ng : > back the same value has this effect. So the patch is valid. Then the Hyper-V is broken. This is bog-standard PCI behavior. The OS must be able to write to the BARs to size the resource being decoded. In addition, the OS is allowed to move the location of an allocation for a BAR, so avoiding writes to it is bad. Finally, some BIOSes don't allocate resources for a card, and this would totally prevent 21140's from being usable on those machines. : > =>I don't particularly like the hackish checking for the 21140 chip, : > and I'=m not sure : > if if would break some real 21140 chip out there. If the dri=ver does : > the same as another : > one I've seen, the driver tries to align t=he register window to : > 0x80, and in the : > simulated 21140 it's already ali=gned. I've had a quick look but : > couldn't say it : > for sure. I'd do it dif=ferently: check if the value being written is : > the same that was read, : > =and skip the write in this case. : > Let me see, maybe I'll make a dif=ferent patch. : : Hmm, the problem is we need to be able to write to BARs to size them. Any OS : needs to be able to do this to know what address space regions are being : decoded by devices. We can't avoid writing to BARs. Exactly. Not only do we have to read/write them to size the BAR resource, but as I indicated above, one must write to them when the BIOS doesn't assign resources to the BAR and the driver requests that resource. Warner From jhb at freebsd.org Mon Apr 6 10:44:23 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Apr 6 10:52:08 2009 Subject: Patch for MS Hyper V (virtualization) In-Reply-To: <9bbcef730904061007y66a8440al3c43a6a6b6cd6ed6@mail.gmail.com> References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904061154.19601.jhb@freebsd.org> <9bbcef730904061007y66a8440al3c43a6a6b6cd6ed6@mail.gmail.com> Message-ID: <200904061342.22000.jhb@freebsd.org> On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote: > 2009/4/6 John Baldwin : > > On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: > > > Hmm, the problem is we need to be able to write to BARs to size them. ?Any OS > > needs to be able to do this to know what address space regions are being > > decoded by devices. ?We can't avoid writing to BARs. > > I have only vague idea what BARs are and if it's the correct diagnosis > in this case, but the fact is that other operating systems (Windows, > Linux tested) work, so either there is a way around it or the original > premise is wrong-ish. Every OS writes to BARs to size them during boot. It's the defined procedure for sizing them. A BAR is a base address register, and it is how a PCI device gets memory and I/O port resources. OS (or BIOS) writes a starting address into the register to tell the PCI device where a given resource "starts". -- John Baldwin From yuri at rawbw.com Mon Apr 6 16:29:57 2009 From: yuri at rawbw.com (Yuri) Date: Mon Apr 6 16:30:04 2009 Subject: Is international support broken is msdosfs file system driver? In-Reply-To: <49D6807D.1040902@rawbw.com> References: <49D6807D.1040902@rawbw.com> Message-ID: <49DA9073.9030401@rawbw.com> Nobody replied and I still have the problem. I extracted the area of the disk where long file names are stored. And can see that all characters are in UTF-8. So how to correctly read UTF-8 encoded VFAT? Yuri From kitchetech at gmail.com Mon Apr 6 18:42:23 2009 From: kitchetech at gmail.com (matt donovan) Date: Mon Apr 6 18:42:31 2009 Subject: Is international support broken is msdosfs file system driver? In-Reply-To: <49DA9073.9030401@rawbw.com> References: <49D6807D.1040902@rawbw.com> <49DA9073.9030401@rawbw.com> Message-ID: <28283d910904061819v13653du8734215a16029eee@mail.gmail.com> On Mon, Apr 6, 2009 at 7:29 PM, Yuri wrote: > Nobody replied and I still have the problem. > > I extracted the area of the disk where long file names are stored. And can > see that all characters are in UTF-8. > > So how to correctly read UTF-8 encoded VFAT? > > > Yuri > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > >From what I can see FreeBSD can not read UTf-8 on the console but can in X From keramida at ceid.upatras.gr Mon Apr 6 20:50:07 2009 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Mon Apr 6 20:50:15 2009 Subject: Is international support broken is msdosfs file system driver? In-Reply-To: <49DA9073.9030401@rawbw.com> (yuri@rawbw.com's message of "Mon, 06 Apr 2009 16:29:55 -0700") References: <49D6807D.1040902@rawbw.com> <49DA9073.9030401@rawbw.com> Message-ID: <87skkl16ro.fsf@kobe.laptop> On Mon, 06 Apr 2009 16:29:55 -0700, Yuri wrote: > Nobody replied and I still have the problem. > > I extracted the area of the disk where long file names are stored. And > can see that all characters are in UTF-8. > > So how to correctly read UTF-8 encoded VFAT? Remap the locale to something you *can* read? I regularly use mount options like -L el_GR.ISO8859-7 to browse FAT filesystems frm non-UTF8 sessions. Can you try mounting with something like this? # mount -o -L=el_GR.ISO8859-7 /dev/msdosfs/FOO /mnt BTW, this should probably be in -questions not -hackers. From wsw1wsw2 at gmail.com Mon Apr 6 21:29:44 2009 From: wsw1wsw2 at gmail.com (Shaowei Wang (wsw)) Date: Mon Apr 6 21:29:51 2009 Subject: Fwd: Is international support broken is msdosfs file system driver? In-Reply-To: <2e566b9e0904062128id1c3312r9389c77b2a039c6a@mail.gmail.com> References: <49D6807D.1040902@rawbw.com> <2e566b9e0904062128id1c3312r9389c77b2a039c6a@mail.gmail.com> Message-ID: <2e566b9e0904062129k6e028f94w952dbaf40673dfca@mail.gmail.com> ---------- Forwarded message ---------- From: Shaowei Wang (wsw) Date: Tue, Apr 7, 2009 at 12:28 PM Subject: Re: Is international support broken is msdosfs file system driver? To: yuri@rawbw.com On Sat, Apr 4, 2009 at 5:32 AM, Yuri wrote: > I have a FAT disk written in Windows that has Chinese characters in file > names. > > When I mount this disk without any special options I see question marks in > place of Chinese characters. > When I mount with options -D=CP950,-L=zh_TW.Big5 there are still some > question marks and garbage characters. > When I mount with options -D=CP936,-L=zh_CN.GBK there are also some > question marks and garbage characters in place of Chinese. > > I read the contents with 'ls' command from x-terminal in kde4. Normally > Chinese characters are shown ok this way. > > My question is how to read proper file names from FAT disk in FreeBSD? try -L zh_CN.euc . FreeBSD-current don't have UTF-8 support for FAT filesystem. > > Also the concept of even having the options like -D=CP950,-L=zh_TW.Big5 > seems questionable. > What if there are files with names in many encodings are on the same FS? > Which options should be used? > Shouldn't msdosfs driver just show international characters without any > special options like ufs driver normally does? Windows file system use a different way to encode i18n chars, like code page. There is a hacked version of msdosfs which can support UTF-8 locale. http://groups.google.com/group/btload/web/msdosfs.tar.bz2 and for using: mount_msdosfs -L zh_CN.UTF-8 /dev/ad?s? /path/to/mount I've tried it and it's work. > > Yuri > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From wsw1wsw2 at gmail.com Mon Apr 6 21:30:06 2009 From: wsw1wsw2 at gmail.com (Shaowei Wang (wsw)) Date: Mon Apr 6 21:30:14 2009 Subject: Shaowei Wang (wsw) has invited you to open a Google mail account Message-ID: <2e566b9e0904062130i5f470dd6r@mail.gmail.com> I've been using Gmail and thought you might like to try it out. Here's an invitation to create an account. ----------------------------------------------------------------------- Shaowei Wang (wsw) has invited you to open a free Gmail account. To accept this invitation and register for your account, visit http://mail.google.com/mail/a-4edf8f191f-12b39a4ad0-ce26dbdf4e Once you create your account, Shaowei Wang (wsw) will be notified with your new email address so you can stay in touch with Gmail! If you haven't already heard about Gmail, it's a new search-based webmail service that offers: - Over 2,700 megabytes (two gigabytes) of free storage - Built-in Google search that instantly finds any message you want - Automatic arrangement of messages and related replies into "conversations" - Powerful spam protection using innovative Google technology - No large, annoying ads--just small text ads and related pages that are relevant to the content of your messages To learn more about Gmail before registering, visit: http://mail.google.com/mail/help/benefits.html And, to see how easy it can be to switch to a new email service, check out our new switch guide: http://mail.google.com/mail/help/switch/ We're still working every day to improve Gmail, so we might ask for your comments and suggestions periodically. We hope you'll like Gmail. We do. And, it's only going to get better. Thanks, The Gmail Team (If clicking the URLs in this message does not work, copy and paste them into the address bar of your browser). From babkin at verizon.net Mon Apr 6 20:03:43 2009 From: babkin at verizon.net (Sergey Babkin) Date: Mon Apr 6 21:49:10 2009 Subject: Patch for MS Hyper V (virtualization) References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904061154.19601.jhb@freebsd.org> <9bbcef730904061007y66a8440al3c43a6a6b6cd6ed6@mail.gmail.com> <200904061342.22000.jhb@freebsd.org> Message-ID: <49DAC4A1.589A5FE@verizon.net> John Baldwin wrote: > > On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote: > > 2009/4/6 John Baldwin : > > > On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: > > > > > Hmm, the problem is we need to be able to write to BARs to size them. ? Any > OS > > > needs to be able to do this to know what address space regions are being > > > decoded by devices. ? We can't avoid writing to BARs. > > > > I have only vague idea what BARs are and if it's the correct diagnosis > > in this case, but the fact is that other operating systems (Windows, > > Linux tested) work, so either there is a way around it or the original > > premise is wrong-ish. > > Every OS writes to BARs to size them during boot. It's the defined procedure > for sizing them. A BAR is a base address register, and it is how a PCI > device gets memory and I/O port resources. OS (or BIOS) writes a starting > address into the register to tell the PCI device where a given > resource "starts". The OS doesn't have to write to the BAR if BIOS has already done it. And the BIOS in the Hyper-V VM is obviously special, so it doesn't trip on iself. Anyway, as far as I can tell, it's only the base register of the simulated DEC21140 device that has this issue, so it's quite possible that the bug is in that device's simulator. I've attached a modified patch that checks conservatively for this precise situation, so it should not break compatibility with anything else. I've tested it on Hyper-V. -SB -------------- next part -------------- --- dev/pci/pci.c.0 2009-04-06 21:35:26.000000000 +0000 +++ dev/pci/pci.c 2009-04-06 22:43:08.000000000 +0000 @@ -3590,6 +3590,18 @@ struct pci_devinfo *dinfo = device_get_ivars(child); pcicfgregs *cfg = &dinfo->cfg; + /* A workaround for Hyper-V that hangs on VM stop + * if the base address register of the 21140 simulator is written; + * since on Hyper-V the value written is the same as the one + * already in the register, it can be simply skipped. + * 0x1011: DEC, 0x0009: 21140 */ + if (dinfo->cfg.vendor == 0x1011 && dinfo->cfg.device == 0x0009) { + if (reg == PCIR_BARS + && (val & ~3) == (PCIB_READ_CONFIG(device_get_parent(dev), + cfg->bus, cfg->slot, cfg->func, reg, width) & ~3) ) + return; + } + PCIB_WRITE_CONFIG(device_get_parent(dev), cfg->bus, cfg->slot, cfg->func, reg, val, width); } From yuri at rawbw.com Mon Apr 6 23:00:37 2009 From: yuri at rawbw.com (Yuri) Date: Mon Apr 6 23:00:44 2009 Subject: Is international support broken is msdosfs file system driver? In-Reply-To: <2e566b9e0904062128id1c3312r9389c77b2a039c6a@mail.gmail.com> References: <49D6807D.1040902@rawbw.com> <2e566b9e0904062128id1c3312r9389c77b2a039c6a@mail.gmail.com> Message-ID: <49DAEBFF.9020502@rawbw.com> Shaowei Wang (wsw) wrote: > > try -L zh_CN.euc . zh_CN.euc doesn't exist, I tried zh_CN.eucCN instead. Didn't work. I tried all zh_CN* and zh_TW* ones from /usr/share/locale/ -- none of them worked. Nut the garbage displayed by 'ls' changes depending on the one used. > > Windows file system use a different way to encode i18n chars, like > code page. > > There is a hacked version of msdosfs which can support UTF-8 locale. > http://groups.google.com/group/btload/web/msdosfs.tar.bz2 > and for using: > mount_msdosfs -L zh_CN.UTF-8 /dev/ad?s? /path/to/mount > > I've tried it and it's work. http://groups.google.com/group/btload/web/msdosfs.tar.bz2 doesn't exist. Somehow in Windows the disk is read correctly without specifying any additional options. So I guess this is a serious defect that msdosfs driver can't do the same. Yuri From wsw1wsw2 at gmail.com Mon Apr 6 23:35:24 2009 From: wsw1wsw2 at gmail.com (Shaowei Wang (wsw)) Date: Mon Apr 6 23:35:36 2009 Subject: Is international support broken is msdosfs file system driver? In-Reply-To: <49DAEBFF.9020502@rawbw.com> References: <49D6807D.1040902@rawbw.com> <2e566b9e0904062128id1c3312r9389c77b2a039c6a@mail.gmail.com> <49DAEBFF.9020502@rawbw.com> Message-ID: <2e566b9e0904062335w19eecca5h8f30ee26ded6ac10@mail.gmail.com> On Tue, Apr 7, 2009 at 2:00 PM, Yuri wrote: > Shaowei Wang (wsw) wrote: > >> >> try -L zh_CN.euc . >> > zh_CN.euc doesn't exist, I tried zh_CN.eucCN instead. Didn't work. > I tried all zh_CN* and zh_TW* ones from /usr/share/locale/ -- none of them > worked. > Nut the garbage displayed by 'ls' changes depending on the one used. > You locale should be same as the param which passed to the -L option and make sure your xterm(rxvt) can display chinese chars. > > >> Windows file system use a different way to encode i18n chars, like code >> page. >> >> There is a hacked version of msdosfs which can support UTF-8 locale. >> http://groups.google.com/group/btload/web/msdosfs.tar.bz2 >> and for using: >> mount_msdosfs -L zh_CN.UTF-8 /dev/ad?s? /path/to/mount >> >> I've tried it and it's work. >> > > http://groups.google.com/group/btload/web/msdosfs.tar.bz2 doesn't exist. Please try the attached file. > > > Somehow in Windows the disk is read correctly without specifying any > additional options. > So I guess this is a serious defect that msdosfs driver can't do the same. > I think so. > > > Yuri > > From avg at icyb.net.ua Tue Apr 7 05:37:30 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Apr 7 05:37:38 2009 Subject: watchdog: hw+sw? In-Reply-To: <49D4A16F.6020906@icyb.net.ua> References: <49D4A16F.6020906@icyb.net.ua> Message-ID: <49DB4906.7080407@icyb.net.ua> I've been thinking about this some more. So, clearly, sw watchdog is different from all the hw watchdogs (that I know about) in that it tries to take a debugging action as opposed to a straightforward recovery action. As such it currently doesn't make much sense to mix sw and hw watchdogs together, because in the case of a problem they would fire at close times and a (typical) hw watchdog would override sw watchdog. This is fine as it is, maybe a small warning in a case of such mix would be nice too. However, I think that it should be possible to use sw watchdog as a special "primary" watchdog and hw watchdog(s) as "failsafe" watchdogs for the primary one. I see two general approaches at the moment: 1. hw watchdog has only "slightly" longer timeout than the sw watchdog (by a configurable delta), the watchdogs gets patted at the same time; if the sw wd fires and is able to proceed, it first disables hw watchdog(s) and the performs its duty (panic, ddb); 2. hw watchdog has "substantially" longer timeout that the sw watchdog (by a configurable delta), the watchdogs gets patted at the same time; if the sw wd fires it has a limited amount of time to do its action before the hw wd fires too; in this case it would also be nice to have a short ddb command for stopping hw watchdog. Each approach has its own advantages and disadvantages. The first approach guarantees that sw wd would not be interrupted by hw wd. On the other hand, there is no protection e.g. from a system getting stuck during a dump. Also, hw watchdogs would have to provide a method for "emergency stop" that should be safe from locking issues. The second approach is more robust. Its problems: (a) it can interrupt sw wd action too early; (b) it wastes more time if sw wd is not able to fire. Since using sw and hw watchdogs together makes more sense in unattended scenarios, I think that approach #2 may be better. IMO, attended scenarios should use sw wd exclusively. -- Andriy Gapon From fbsdlists at honeyguide.net Tue Apr 7 06:08:26 2009 From: fbsdlists at honeyguide.net (Stephan Lichtenauer) Date: Tue Apr 7 06:08:33 2009 Subject: GSoC: Semantic File System In-Reply-To: References: <1fe1d5d60903210422g70efef15hdd685695cdf8df3c@mail.gmail.com> <1fe1d5d60904020904ya6dcb00h54a54d6a00e2bd0@mail.gmail.com> Message-ID: Gabriele, Robert, Am 02.04.2009 um 19:26 schrieb Robert Watson: > > In the BeOS model, or my reinterpretation based on something I read > a long time ago and then presumably had dreams about, the split is a > bit different: the file system maintains indexes of extended > attributes, which are written by applications in order to expose > searchable material. For example, a mail application might write > out each message as a file, and attach a series of extended > attributes, such as subject line, date, author, etc. These extended > attributes are then indexed automatically by the file system in > order to allow queries to be evaluated. I don't recall how queries > and results are expressed, and in particular, whether the queries > are processed by the file system (possibly exposed via special APIs > or the name space) or userspace (accessing special files maintained > by the kernel that are the indexes). > > It's also worth observing that one of the authors of BFS was Dominic > Giampaolo, who now works on Apple's HFS+, and implemented fsevents > there as part of their Spotlight project. > Maybe you also might be interested that there is a PDF document (formerly book) from Dominic available describing the BeOS file system in great detail: http://www.haiku-os.org/legacy-docs/practical-file-system-design.pdf Additionally, there seems to be a GSoC project to create something like Spotlight for Haiku, the open source BeOS clone. You could browse through the haiku-developer mailing list archives at http://www.freelists.org/archive/haiku-development , the thread where this has been discussed is titled "Need Some GSoC Advice" with the first mail from 21 March. Stephan From rwatson at FreeBSD.org Tue Apr 7 06:16:15 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Apr 7 06:16:22 2009 Subject: GSoC: Semantic File System In-Reply-To: References: <1fe1d5d60903210422g70efef15hdd685695cdf8df3c@mail.gmail.com> <1fe1d5d60904020904ya6dcb00h54a54d6a00e2bd0@mail.gmail.com> Message-ID: On Tue, 7 Apr 2009, Stephan Lichtenauer wrote: > Am 02.04.2009 um 19:26 schrieb Robert Watson: > >> In the BeOS model, or my reinterpretation based on something I read a long >> time ago and then presumably had dreams about, the split is a bit >> different: the file system maintains indexes of extended attributes, which >> are written by applications in order to expose searchable material. For >> example, a mail application might write out each message as a file, and >> attach a series of extended attributes, such as subject line, date, author, >> etc. These extended attributes are then indexed automatically by the file >> system in order to allow queries to be evaluated. I don't recall how >> queries and results are expressed, and in particular, whether the queries >> are processed by the file system (possibly exposed via special APIs or the >> name space) or userspace (accessing special files maintained by the kernel >> that are the indexes). >> >> It's also worth observing that one of the authors of BFS was Dominic >> Giampaolo, who now works on Apple's HFS+, and implemented fsevents there as >> part of their Spotlight project. > > Maybe you also might be interested that there is a PDF document (formerly > book) from Dominic available describing the BeOS file system in great > detail: http://www.haiku-os.org/legacy-docs/practical-file-system-design.pdf > > Additionally, there seems to be a GSoC project to create something like > Spotlight for Haiku, the open source BeOS clone. You could browse through > the haiku-developer mailing list archives at > http://www.freelists.org/archive/haiku-development, the thread where this > has been discussed is titled "Need Some GSoC Advice" with the first mail > from 21 March. Actually, I have a original copy of the book on the bookshelf behind me. :-) Robert N M Watson Computer Laboratory University of Cambridge From jhb at freebsd.org Tue Apr 7 07:28:50 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Apr 7 07:29:00 2009 Subject: Patch for MS Hyper V (virtualization) In-Reply-To: <49DAC4A1.589A5FE@verizon.net> References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904061342.22000.jhb@freebsd.org> <49DAC4A1.589A5FE@verizon.net> Message-ID: <200904070921.14294.jhb@freebsd.org> On Monday 06 April 2009 11:12:33 pm Sergey Babkin wrote: > John Baldwin wrote: > > > > On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote: > > > 2009/4/6 John Baldwin : > > > > On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: > > > > > > > Hmm, the problem is we need to be able to write to BARs to size them. ? Any > > OS > > > > needs to be able to do this to know what address space regions are being > > > > decoded by devices. ? We can't avoid writing to BARs. > > > > > > I have only vague idea what BARs are and if it's the correct diagnosis > > > in this case, but the fact is that other operating systems (Windows, > > > Linux tested) work, so either there is a way around it or the original > > > premise is wrong-ish. > > > > Every OS writes to BARs to size them during boot. It's the defined procedure > > for sizing them. A BAR is a base address register, and it is how a PCI > > device gets memory and I/O port resources. OS (or BIOS) writes a starting > > address into the register to tell the PCI device where a given > > resource "starts". > > The OS doesn't have to write to the BAR if BIOS has already > done it. And the BIOS in the Hyper-V VM is obviously special, > so it doesn't trip on iself. Yes it does because we don't know how _big_ the BAR is. The OS has to know if the device is decoding 1MB or 64KB because we need to reserve the entire window to prevent any other devices from using it. We don't just write the existing value, we write all 1's to it and read it back. The lower N bits "stick" at zero and we use that to figure out the BAR's size. See pci_add_map() in sys/dev/pci/pci.c > Anyway, as far as I can tell, it's only the base register of > the simulated DEC21140 device that has this issue, so it's > quite possible that the bug is in that device's simulator. > > I've attached a modified patch that checks conservatively for this > precise situation, so it should not break compatibility with > anything else. I've tested it on Hyper-V. Can you test unmodified FreeBSD 8 on Hyper-V? It has an extra fix relative to 7 to disable decoding via the PCI command register while sizing BARs that may address this. -- John Baldwin From pisymbol at gmail.com Tue Apr 7 08:04:26 2009 From: pisymbol at gmail.com (Alexander Sack) Date: Tue Apr 7 08:04:33 2009 Subject: Patch for MS Hyper V (virtualization) In-Reply-To: <200904070921.14294.jhb@freebsd.org> References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904061342.22000.jhb@freebsd.org> <49DAC4A1.589A5FE@verizon.net> <200904070921.14294.jhb@freebsd.org> Message-ID: <3c0b01820904070804s1aa63cc3ife542e7001f5497c@mail.gmail.com> On Tue, Apr 7, 2009 at 9:21 AM, John Baldwin wrote: > On Monday 06 April 2009 11:12:33 pm Sergey Babkin wrote: >> John Baldwin wrote: >> > >> > On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote: >> > > 2009/4/6 John Baldwin : >> > > > On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: >> > > >> > > > Hmm, the problem is we need to be able to write to BARs to size them. > ? Any >> > OS >> > > > needs to be able to do this to know what address space regions are > being >> > > > decoded by devices. ? We can't avoid writing to BARs. >> > > >> > > I have only vague idea what BARs are and if it's the correct diagnosis >> > > in this case, but the fact is that other operating systems (Windows, >> > > Linux tested) work, so either there is a way around it or the original >> > > premise is wrong-ish. >> > >> > Every OS writes to BARs to size them during boot. ?It's the defined > procedure >> > for sizing them. ?A BAR is a base address register, and it is how a PCI >> > device gets memory and I/O port resources. ?OS (or BIOS) writes a starting >> > address into the register to tell the PCI device where a given >> > resource "starts". >> >> The OS doesn't have to write to the BAR if BIOS has already >> done it. And the BIOS in the Hyper-V VM is obviously special, >> so it doesn't trip on iself. > > Yes it does because we don't know how _big_ the BAR is. ?The OS has to know if > the device is decoding 1MB or 64KB because we need to reserve the entire > window to prevent any other devices from using it. ?We don't just write the > existing value, we write all 1's to it and read it back. ?The lower N > bits "stick" at zero and we use that to figure out the BAR's size. ?See > pci_add_map() in sys/dev/pci/pci.c John is 100% correct. Every kernel PCI driver has to figure out how big the BAR is and IN FACT typically the BIOS assigns more address space than the register set you are mapping. This is straight out of the PCI spec. -aps From babkin at verizon.net Tue Apr 7 08:12:55 2009 From: babkin at verizon.net (Sergey Babkin) Date: Tue Apr 7 09:08:05 2009 Subject: Patch for MS Hyper V (virtualization) Message-ID: <365687070.340074.1239117164323.JavaMail.root@vms124.mailsrvcs.net> (Let's see if I've figured yet another workaround for the web interface The address space used by the card I think is actually 0x80 bytes in the I/O port space. The card has it located at the port 0xEC00. Yester card's registers all ones written to this (1 is the I/O space indicator), not the missing bit 0 (which should be I've tried adding it back, and it made no diffe I'll try FreeBSD 8 and see what happens. -SB Ap On Monday 06 April 2009 11:12:33 > John Baldwin wrote: > > > > > > > > > > > > > Hmm, the problem is we need to be able t to size them. ? Any > > OS > > & regions are being > > > > decoded by devices. ? We can't avoid > > > > > > I have only vague ide correct diagnosis > > > in this (Windows, > > the original > > > premise is wrong-ish. > > > > Every O defined procedure< register, and it is > > device gets memory and I/O port resources. OS (or B writes a starting > > address into the register to tell the P given > > resource "starts". > > Th > done it. > so it doesn't Yes it does because we don't know how _big_ the BAR has to know if the device is decoding 1MB or 64KB because w entire window to prevent any other devices from u write the existing value, we write all 1's to i lower N bits "stick" at zero and we use that t size. See pci_add_map() in sys/dev/pci/pci.c > Anyway, as far as I can tell, it's only the base register of > qu > > this > > anythi Can you test unmodified FreeBSD relative to 7 to disable decoding vi BARs that may address this. -- John Baldwin References 1. 3D"mailto:jhb@freebsd.org" 2. 3D"mailto:jhb@freebsd.org" From aryeh.friedman at gmail.com Tue Apr 7 11:35:34 2009 From: aryeh.friedman at gmail.com (Aryeh M. Friedman) Date: Tue Apr 7 11:35:42 2009 Subject: DNS problems Message-ID: <49DB9CED.2030603@gmail.com> I have registered and pointed to my name server the following domains: istudentunion.com (.net and .org) They resolve locally but do not resolve remotely.... it has been 24 hrs so some propagation should of occured... I tested resolving remotely with hardcoding the nameserver to be me and that works... what else should I look at... I am using the named in base 7.2-PREREALSE (i386) and used the guidelines in O'reilly's DNS and BIND.... what other tests configs should I try? (I double checked the zone type and that I have all the trailing dots) Note I have also transfered registers in the last 24 hrs (but whois has all the right data) From delphij at delphij.net Tue Apr 7 12:01:40 2009 From: delphij at delphij.net (Xin LI) Date: Tue Apr 7 12:01:54 2009 Subject: DNS problems In-Reply-To: <49DB9CED.2030603@gmail.com> References: <49DB9CED.2030603@gmail.com> Message-ID: <49DBA307.30307@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aryeh M. Friedman wrote: > I have registered and pointed to my name server the following domains: > > istudentunion.com (.net and .org) > > They resolve locally but do not resolve remotely.... it has been 24 hrs > so some propagation should of occured... I tested resolving remotely > with hardcoding the nameserver to be me and that works... what else > should I look at... I am using the named in base 7.2-PREREALSE (i386) > and used the guidelines in O'reilly's DNS and BIND.... what other tests > configs should I try? (I double checked the zone type and that I have > all the trailing dots) > > Note I have also transfered registers in the last 24 hrs (but whois has > all the right data) BIND by default listen on lo0 only. Check your /etc/namedb/named.conf. - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknbowcACgkQi+vbBBjt66BPRwCdE3cAE8U+3687Dl9ICDx5PIsv 6pEAn1ZCCPmEJiFw7UkM2E7ErTLvG2S5 =k1/J -----END PGP SIGNATURE----- From aryeh.friedman at gmail.com Tue Apr 7 12:05:02 2009 From: aryeh.friedman at gmail.com (Aryeh M. Friedman) Date: Tue Apr 7 12:05:17 2009 Subject: DNS problems In-Reply-To: <49DBA307.30307@delphij.net> References: <49DB9CED.2030603@gmail.com> <49DBA307.30307@delphij.net> Message-ID: <49DBA3D1.6060904@gmail.com> Already did (went a step farther had my machine at home -CURRENT use the one at work [the one with the probldem] as it's /etc/resolv.conf and as a forwarder in my named.conf and both worked fine) Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Aryeh M. Friedman wrote: > >> I have registered and pointed to my name server the following domains: >> >> istudentunion.com (.net and .org) >> >> They resolve locally but do not resolve remotely.... it has been 24 hrs >> so some propagation should of occured... I tested resolving remotely >> with hardcoding the nameserver to be me and that works... what else >> should I look at... I am using the named in base 7.2-PREREALSE (i386) >> and used the guidelines in O'reilly's DNS and BIND.... what other tests >> configs should I try? (I double checked the zone type and that I have >> all the trailing dots) >> >> Note I have also transfered registers in the last 24 hrs (but whois has >> all the right data) >> > > BIND by default listen on lo0 only. Check your /etc/namedb/named.conf. > > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (FreeBSD) > > iEYEARECAAYFAknbowcACgkQi+vbBBjt66BPRwCdE3cAE8U+3687Dl9ICDx5PIsv > 6pEAn1ZCCPmEJiFw7UkM2E7ErTLvG2S5 > =k1/J > -----END PGP SIGNATURE----- > > From aryeh.friedman at gmail.com Tue Apr 7 12:06:58 2009 From: aryeh.friedman at gmail.com (Aryeh M. Friedman) Date: Tue Apr 7 12:07:18 2009 Subject: DNS problems In-Reply-To: <49DBA3D1.6060904@gmail.com> References: <49DB9CED.2030603@gmail.com> <49DBA307.30307@delphij.net> <49DBA3D1.6060904@gmail.com> Message-ID: <49DBA44B.2070308@gmail.com> Aryeh M. Friedman wrote: > Already did (went a step farther had my machine at home -CURRENT use > the one at work [the one with the probldem] as it's /etc/resolv.conf > and as a forwarder in my named.conf and both worked fine) > Forgot to mention that different ISP's so it is not a port blocking problem > > Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Aryeh M. Friedman wrote: >> >>> I have registered and pointed to my name server the following domains: >>> >>> istudentunion.com (.net and .org) >>> >>> They resolve locally but do not resolve remotely.... it has been 24 hrs >>> so some propagation should of occured... I tested resolving remotely >>> with hardcoding the nameserver to be me and that works... what else >>> should I look at... I am using the named in base 7.2-PREREALSE >>> (i386) and used the guidelines in O'reilly's DNS and BIND.... what >>> other tests >>> configs should I try? (I double checked the zone type and that I have >>> all the trailing dots) >>> >>> Note I have also transfered registers in the last 24 hrs (but whois has >>> all the right data) >>> >> >> BIND by default listen on lo0 only. Check your /etc/namedb/named.conf. >> >> - -- >> Xin LI http://www.delphij.net/ >> FreeBSD - The Power to Serve! >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.11 (FreeBSD) >> >> iEYEARECAAYFAknbowcACgkQi+vbBBjt66BPRwCdE3cAE8U+3687Dl9ICDx5PIsv >> 6pEAn1ZCCPmEJiFw7UkM2E7ErTLvG2S5 >> =k1/J >> -----END PGP SIGNATURE----- >> >> > > From nparhar at gmail.com Tue Apr 7 12:16:34 2009 From: nparhar at gmail.com (Navdeep Parhar) Date: Tue Apr 7 12:18:22 2009 Subject: KLDs missing CTF information (patch attached) Message-ID: It appears that the KLD build process is missing a ctfmerge at the end, and this results in KLDs with incomplete CTF information. Here is a patch that fixes this. I verified it on amd64 with various KLDs. Before: # ctfdump /boot/kernel/if_cxgb.ko | wc -l 2269 # ctfdump /boot/kernel/zfs.ko | wc -l 430 After: # ctfdump /boot/kernel/if_cxgb.ko | wc -l 6568 # ctfdump /boot/kernel/zfs.ko | wc -l 15032 It is wasteful to have CTF information in both the .ko and the .ko.symbols file but this is what the kernel does too. Regards, Navdeep -------------- next part -------------- A non-text attachment was scrubbed... Name: ctf-kld.patch Type: application/octet-stream Size: 602 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090407/00546bf8/ctf-kld.obj From george+freebsd at m5p.com Tue Apr 7 12:36:24 2009 From: george+freebsd at m5p.com (george+freebsd@m5p.com) Date: Tue Apr 7 12:36:41 2009 Subject: DNS problems In-Reply-To: <49DB9CED.2030603@gmail.com> Message-ID: <200904071936.n37JaGGp032845@m5p.com> > I have registered and pointed to my name server the following domains: > > istudentunion.com (.net and .org) > > They resolve locally but do not resolve remotely.... it has been 24 hrs > so some propagation should of occured... I tested resolving remotely > with hardcoding the nameserver to be me and that works... what else > should I look at... I am using the named in base 7.2-PREREALSE (i386) > and used the guidelines in O'reilly's DNS and BIND.... what other tests > configs should I try? (I double checked the zone type and that I have > all the trailing dots) > > Note I have also transfered registers in the last 24 hrs (but whois has > all the right data) Your registrar has not inserted the glue records for your name servers into the root zone. Try a different registrar. -- George Mitchell From babkin at verizon.net Tue Apr 7 18:03:48 2009 From: babkin at verizon.net (Sergey Babkin) Date: Tue Apr 7 18:49:17 2009 Subject: Patch for MS Hyper V (virtualization) References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904061342.22000.jhb@freebsd.org> <49DAC4A1.589A5FE@verizon.net> <200904070921.14294.jhb@freebsd.org> Message-ID: <49DBFA72.9E64AB4F@verizon.net> John Baldwin wrote: > > On Monday 06 April 2009 11:12:33 pm Sergey Babkin wrote: > > Anyway, as far as I can tell, it's only the base register of > > the simulated DEC21140 device that has this issue, so it's > > quite possible that the bug is in that device's simulator. > > > > I've attached a modified patch that checks conservatively for this > > precise situation, so it should not break compatibility with > > anything else. I've tested it on Hyper-V. > > Can you test unmodified FreeBSD 8 on Hyper-V? It has an extra fix relative to > 7 to disable decoding via the PCI command register while sizing BARs that may > address this. 8.0 (February snapshot) seems to have the same issue. I've also saved the log of writes that 7.1 does for this device: reg 10 val ec01 reg 14 val febff000 reg 18 val 0 reg 1c val 0 reg 20 val 0 reg 24 val 0 reg 30 val febe0000 reg 4 val 117 reg 3c val b reg 3d val 1 reg 3e val 14 reg 3f val 28 reg c val 8 reg d val 40 reg 9 val 0 reg 8 val 20 reg 10 val ec00 reg 14 val febff000 reg 4 val 117 reg 4 val 117 I don't see any ffffffff values. -SB From rb at gid.co.uk Wed Apr 8 01:57:22 2009 From: rb at gid.co.uk (Bob Bishop) Date: Wed Apr 8 01:57:31 2009 Subject: DNS problems In-Reply-To: <49DB9CED.2030603@gmail.com> References: <49DB9CED.2030603@gmail.com> Message-ID: <953481EE-1A58-4852-BA23-8CB571939537@gid.co.uk> Hi, On 7 Apr 2009, at 19:35, Aryeh M. Friedman wrote: > I have registered and pointed to my name server the following domains: > > istudentunion.com (.net and .org) [etc] Actually, the registrar only seems to have delegated istudentunion.net I'm not sure that using a CNAME for the server(s) is a good idea either. -- Bob Bishop rb@gid.co.uk From aryeh.friedman at gmail.com Wed Apr 8 02:00:14 2009 From: aryeh.friedman at gmail.com (Aryeh M. Friedman) Date: Wed Apr 8 02:00:38 2009 Subject: DNS problems In-Reply-To: <953481EE-1A58-4852-BA23-8CB571939537@gid.co.uk> References: <49DB9CED.2030603@gmail.com> <953481EE-1A58-4852-BA23-8CB571939537@gid.co.uk> Message-ID: <49DC678C.7070403@gmail.com> Bob Bishop wrote: > Hi, > > On 7 Apr 2009, at 19:35, Aryeh M. Friedman wrote: > >> I have registered and pointed to my name server the following domains: >> >> istudentunion.com (.net and .org) [etc] > > Actually, the registrar only seems to have delegated istudentunion.net > > I'm not sure that using a CNAME for the server(s) is a good idea either. it is a huge ball of wax... they claimed they delegated everything but our nameservers are on .org and org is not delegated (according to dig)... what I did tempurarly was make the registers nameserver be the master but since it refuses to do a zone transfer all the internal IP;s and stuff are lost (as well as the MX since they do not offer MX [extra fee actually])... as to the CNAME issue I have used that for years (used to be a hosting ISP head sys/netadmin) and it is the recommended method in O'reilly... the only issue seems to be I have not done dns work in so long that I was used to bind 4 (but once I got used to the 8/9 semantics it seems to be working fine localy) From ticso at cicely7.cicely.de Wed Apr 8 04:26:04 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Wed Apr 8 04:26:12 2009 Subject: How to increase the max pty's on Freebsd 7.0? In-Reply-To: <20090402061003.GR13393@hoeg.nl> References: <20090401205306.GO13393@hoeg.nl> <20090401205703.GX31897@deviant.kiev.zoral.com.ua> <20090401210835.GP13393@hoeg.nl> <20090401215308.GA91493@psconsult.nl> <20090402061003.GR13393@hoeg.nl> Message-ID: <20090408112538.GA68699@cicely7.cicely.de> On Thu, Apr 02, 2009 at 08:10:03AM +0200, Ed Schouten wrote: > * Paul Schenkeveld wrote: > > Or change 'pts' to, for example, 'pt' so without changing utmp and > > related stuff we'll have space for a four digit pty number. > > I've noticed lots of apps already misbehave because of the pty(4) -> > pts(4) migration. I guess using a new naming scheme would totally break > stuff. There are lots of apps that do things like: > > if (strncmp(tty, "tty", 3) != 0 && strncmp(tty, "pts/", 4) != 0) > printf("Not a valid pseudo-terminal!\n"); > > But those are just workarounds. Our utmp format is broken anyway. It's > not just UT_LINESIZE that's too small. I think we received many > complaints from people who want to increase UT_HOSTSIZE as well. Well, UT_HOSTSIZE can't hold a full sized IPv6 address. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From max at love2party.net Wed Apr 8 04:56:41 2009 From: max at love2party.net (Max Laier) Date: Wed Apr 8 04:56:48 2009 Subject: How to increase the max pty's on Freebsd 7.0? In-Reply-To: <20090408112538.GA68699@cicely7.cicely.de> References: <20090402061003.GR13393@hoeg.nl> <20090408112538.GA68699@cicely7.cicely.de> Message-ID: <200904081343.53600.max@love2party.net> On Wednesday 08 April 2009 13:25:39 Bernd Walter wrote: > On Thu, Apr 02, 2009 at 08:10:03AM +0200, Ed Schouten wrote: > > * Paul Schenkeveld wrote: > > > Or change 'pts' to, for example, 'pt' so without changing utmp and > > > related stuff we'll have space for a four digit pty number. > > > > I've noticed lots of apps already misbehave because of the pty(4) -> > > pts(4) migration. I guess using a new naming scheme would totally break > > stuff. There are lots of apps that do things like: > > > > if (strncmp(tty, "tty", 3) != 0 && strncmp(tty, "pts/", 4) != 0) > > printf("Not a valid pseudo-terminal!\n"); > > > > But those are just workarounds. Our utmp format is broken anyway. It's > > not just UT_LINESIZE that's too small. I think we received many > > complaints from people who want to increase UT_HOSTSIZE as well. > > Well, UT_HOSTSIZE can't hold a full sized IPv6 address. RFC 1924 (still needs four more, but avoids ridiculously large UT_HOSTSIZE ;) -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From ticso at cicely7.cicely.de Wed Apr 8 05:09:03 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Wed Apr 8 05:09:14 2009 Subject: How to increase the max pty's on Freebsd 7.0? In-Reply-To: <200904081343.53600.max@love2party.net> References: <20090402061003.GR13393@hoeg.nl> <20090408112538.GA68699@cicely7.cicely.de> <200904081343.53600.max@love2party.net> Message-ID: <20090408120841.GC68699@cicely7.cicely.de> On Wed, Apr 08, 2009 at 12:43:53PM +0100, Max Laier wrote: > On Wednesday 08 April 2009 13:25:39 Bernd Walter wrote: > > On Thu, Apr 02, 2009 at 08:10:03AM +0200, Ed Schouten wrote: > > > * Paul Schenkeveld wrote: > > > > Or change 'pts' to, for example, 'pt' so without changing utmp and > > > > related stuff we'll have space for a four digit pty number. > > > > > > I've noticed lots of apps already misbehave because of the pty(4) -> > > > pts(4) migration. I guess using a new naming scheme would totally break > > > stuff. There are lots of apps that do things like: > > > > > > if (strncmp(tty, "tty", 3) != 0 && strncmp(tty, "pts/", 4) != 0) > > > printf("Not a valid pseudo-terminal!\n"); > > > > > > But those are just workarounds. Our utmp format is broken anyway. It's > > > not just UT_LINESIZE that's too small. I think we received many > > > complaints from people who want to increase UT_HOSTSIZE as well. > > > > Well, UT_HOSTSIZE can't hold a full sized IPv6 address. > > RFC 1924 (still needs four more, but avoids ridiculously large UT_HOSTSIZE ;) It doesn't handle scope information ;-) -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From mehulc87 at gmail.com Wed Apr 8 07:04:10 2009 From: mehulc87 at gmail.com (Mehul Chadha) Date: Wed Apr 8 07:04:16 2009 Subject: working of syscall handling Message-ID: <251d650c0904080643o8789860w87c8cca070a16489@mail.gmail.com> Hello all, I have a doubt in understanding the working of the freebsd OS. In the program given below the function readlink gets called up when printf is executed and the program ends without any output. readlink is a system call (syscall number = 58) which is being made by the printf function, but according to my understanding of system call, it is made by putting the handler number in eax register and then interrupting the processor, so that it can enter the kernel mode and execute the required function, but in this case(dont know why) my readlink function gets called up which should not have happened. I will be very thankful if you can help me with it. #include int readlink(void *a, void *b) { exit(0); } int main(int argc, char **argv) { printf("Hello World"); } From dnelson at allantgroup.com Wed Apr 8 07:55:19 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Wed Apr 8 07:55:26 2009 Subject: working of syscall handling In-Reply-To: <251d650c0904080643o8789860w87c8cca070a16489@mail.gmail.com> References: <251d650c0904080643o8789860w87c8cca070a16489@mail.gmail.com> Message-ID: <20090408145515.GB90152@dan.emsphone.com> In the last episode (Apr 08), Mehul Chadha said: > In the program given below the function readlink gets called up when > printf is executed and the program ends without any output. > > readlink is a system call (syscall number = 58) which is being made by the > printf function, but according to my understanding of system call, it is > made by putting the handler number in eax register and then interrupting > the processor, so that it can enter the kernel mode and execute the > required function, but in this case(dont know why) my readlink function > gets called up which should not have happened. Readlink is not only a syscall, but a POSIX library function. You are overriding that, and FreeBSD's malloc function uses readlink to read the /etc/malloc.conf settings file. printf calls malloc, so that's why your program exits. http://www.opengroup.org/onlinepubs/9699919799/functions/readlink.html > I will be very thankful if you can help me with it. > > #include > > int readlink(void *a, void *b) > { > exit(0); > } > > int main(int argc, char **argv) > { > printf("Hello World"); > } -- Dan Nelson dnelson@allantgroup.com From joseph.koshy at gmail.com Wed Apr 8 08:02:33 2009 From: joseph.koshy at gmail.com (Joseph Koshy) Date: Wed Apr 8 08:02:39 2009 Subject: working of syscall handling In-Reply-To: <251d650c0904080643o8789860w87c8cca070a16489@mail.gmail.com> References: <251d650c0904080643o8789860w87c8cca070a16489@mail.gmail.com> Message-ID: <84dead720904080739q1d98662ch219899990f66767@mail.gmail.com> > In the program given below the function readlink gets called up when > printf is executed and the program ends without any output. > > readlink is a system call (syscall number = 58) which is being made by > the printf function, but according to my understanding of system call, > it is made by putting the handler number in eax register and then > interrupting the processor, so that it can enter the kernel mode and > execute the required function, but in this case(dont know why) my > readlink function gets called up which should not have happened. > > I will be very thankful if you can help me with it. > > > #include > > int readlink(void *a, void *b) > { > exit(0); > } > > int main(int argc, char **argv) > { > printf("Hello World"); > } Since you have defined 'readlink' to be a global symbol, the run time linker will satisfy references to the symbol 'readlink' from within libc using the definition you provided. % cc a.c % nm a.out | grep readlink 00000000004006d0 T readlink % gdb a.out ... startup messages snipped ... Breakpoint 1, main (argc=1, argv=0x7fffffffe020) at a.c:11 11 printf("Hello World"); (gdb) b readlink Breakpoint 2 at 0x4006e0: file a.c, line 6. (gdb) c Continuing. Breakpoint 2, readlink (a=0x8007082a9, b=0x7fffffffd660) at a.c:6 6 exit(0); (gdb) bt #0 readlink (a=0x8007082a9, b=0x7fffffffd660) at a.c:6 #1 0x000000080069b87c in _UTF8_init () from /lib/libc.so.6 #2 0x0000000800703343 in __smakebuf () from /lib/libc.so.6 #3 0x00000008007031e8 in __swsetup () from /lib/libc.so.6 #4 0x00000008006f872e in __vfprintf () from /lib/libc.so.6 #5 0x00000008006fbeae in vfprintf () from /lib/libc.so.6 #6 0x00000008006e8eca in printf () from /lib/libc.so.6 #7 0x000000000040070e in main (argc=1, argv=0x7fffffffe020) at a.c:11 (gdb) Regards, Koshy From chuckr at telenix.org Wed Apr 8 18:30:01 2009 From: chuckr at telenix.org (Chuck Robey) Date: Wed Apr 8 18:30:08 2009 Subject: building a gcc crosscompiler Message-ID: <49DD4FA6.7090805@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Since the last time I built a gcc crosscompiler, the gcc folks have added in dependencies on mpfr and gmp libraries. When I first read this, I was worried that I had a chicken/egg problem, but I found that you can do with the host's version of those libraries. I found a port of gnu libmpfr, but I notice here that FreeBSD has it's own libmp, and I don't know if the 4.3.1 version of gnu gcc can use our libmp, or if I need to install the port "libgmp4" and tell the gnu gcc configure about which mp I'm using. So, if you know if I can use FreeBSD's libmp, or if I need to build the ports libgmp4, please let me know. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkndT6YACgkQz62J6PPcoOmsiQCff6qjZ46dxn8P+5c19gAP2dip 3YsAnj2/sy3nhZzk1TWz1Rfv7PQ2Uw5f =5iqj -----END PGP SIGNATURE----- From bruce at cran.org.uk Thu Apr 9 01:38:46 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Thu Apr 9 01:38:52 2009 Subject: building a gcc crosscompiler In-Reply-To: <49DD4FA6.7090805@telenix.org> References: <49DD4FA6.7090805@telenix.org> Message-ID: <20090409093837.5f6e8628@gluon.draftnet> On Wed, 08 Apr 2009 21:30:14 -0400 Chuck Robey wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Since the last time I built a gcc crosscompiler, the gcc folks have > added in dependencies on mpfr and gmp libraries. When I first read > this, I was worried that I had a chicken/egg problem, but I found > that you can do with the host's version of those libraries. I found > a port of gnu libmpfr, but I notice here that FreeBSD has it's own > libmp, and I don't know if the 4.3.1 version of gnu gcc can use our > libmp, or if I need to install the port "libgmp4" and tell the gnu > gcc configure about which mp I'm using. > > So, if you know if I can use FreeBSD's libmp, or if I need to build > the ports libgmp4, please let me know. I don't know if it's required, but devel/cross-gcc does depend on math/libgmp4 . -- Bruce Cran From anti_spamsys at yahoo.com Wed Apr 8 23:34:24 2009 From: anti_spamsys at yahoo.com (Travis Daygale) Date: Thu Apr 9 04:53:41 2009 Subject: compiling root filesystem into kernel (preferably tmpfs root filesystem) Message-ID: <104771.62272.qm@web37103.mail.mud.yahoo.com> David, thank you for the great information! ?Yes, I would appreciate seeing the scripts and hearing about the other method you outline. ? Yes, you understand what I want to achieve exactly. I see what you're saying about not needing to put it in the kernel file, though for a variety of reasons, I do prefer a single file in the end. And I did find this after posting (didn't see it on previous searches, though I invested a lot of time looking before I posted):http://lists.freebsd.org/pipermail/freebsd-hackers/2006-November/018662.html I have built a root image that I put in the kernel as described in the Nov 2006 post. ?My UFS root image consists of /sbin/init, where init is a statically compiled C program that just spits out "Hello world" and sleeps, this binary runs fine under FBSD. ?At this point, I have the kernel booting but it panics because it says it can't find init.... ?Hmmm... ?I believe (haven't had time to test) that it is finding root? ?Not sure though what loader args I might need to be providing? ?Could it be a /dev issue (though I'm not needing sh, etc., since my init is not a real init)? ?Still figuring this out. Trever --- On Sun, 4/5/09, David Naylor wrote: From: David Naylor Subject: Re: compiling root filesystem into kernel (preferably tmpfs root filesystem) To: "Travis Daygale" Cc: freebsd-hackers@freebsd.org Date: Sunday, April 5, 2009, 1:14 PM On Saturday 04 April 2009 21:52:14 Travis Daygale wrote: > In both the loader and kernel compiling doc, I see snippets of information > like this: #Make space in the kernel for a root filesystem on a md > device.options MD_ROOT_SIZE=10 boot_dfltrootInstructs the kernel to mount > the statically compiled-in root file system. Yes, you can compile a fs image into the kernel.? This however will be static and if you want editing then will need to use unionfs with mdmfs.? tmpfs cannot be used for this as it does not yet (to my knowledge) support unionfs.? > My question is, how does one compile a root filesystem into the FreeBSD > kernel? ? Personally I wouldn't recommend taking the approach you want to do.? There is simply an easier way.? Just load the fs image as a kernel module (sort of).? You get the same effect with more flexibility.? (I'll explain below). > When mounted, I want this root filesystem to run entirely in > memory with no other backing store (not even a readonly flash disc nor > other backing media such as DVD/CD). This is do-able.? I've created a CD that ejects it self when loaded completely.? (I thought it was cool :-)) > The standard FreeBSD DVD install disc > uses just such a root? ?(Though seems to rely heavily on the rescue > binaries being on a read only filesystem backed by the install DVD?) Can't comment, haven't used the FreeBSD CD/DVD's for years (since 6.0) > I'm > still trying to reverse engineer how that was done, without much luck. Is > there a place/documentation I should be finding? ?PicoBSD, NanoBSD, NFS > root diskless systems... all tantalizing close, but not the same thing > (read only roots backed by media other than memory). The root filesystem > I'm wanting would presumably be in some conceptual sense similar to > initramfs in Linux land, if that helps explain what I'm trying to achieve.? I'll give you a quick tutorial below (if you need further help please let me know). > ?In fact I have a Linux distribution which consists of a single giant > kernel image and when boot, runs entirely in memory, the kernel in fact > can't read filesystems other than tmpfs because no filesystems are compiled > in. ? I think you are getting some concepts confused here.? > It appears all of this won't be possible in FreeBSD (looks like ufs is > required) but it appears I can get close to this. Indeed, I'd love a way > for the root filesystem in FreeBSD to be of type tmpfs, again similar to > what is possible on the Linux side, though I'm much less concerned with the > type of filesystem (it just needs to be compiled into the FreeBSD kernel > and needs to be a memory backed filesystem when it mounts, no other backing > store). Thanks in advance! Ok, onto my explanation: my understanding is that you want to have some type of FreeBSD based system that is loaded completely into RAM.? Once loaded (at boot time) this system should have no reliance on any medium (other than RAM).? This system, once loaded, should behave the same as if it were backed by a hard drive (except the statefullness after reboots).? i.e. the filesystem should be editable.? This is of course very possible.? STAGE 1: The filesystem In order to have the system in memory one needs a delivery method.? As mentioned before this is achieved using a MD device.? MD's can have three types of backing, a vnode (aka file, on a CD/DVD or hard drive), or memory (purely in memory, AFAIK no swapping out) and swap (same as memory except my get swapped out).? Ignoring the subtle difference between memory and swap, swap is better.? Technically the forth is preload but this is the same as memory but done by the loader.? See md(4) for further details.? Now, MD just imitates a hard drive, one still needs the data to put there.? Any filesystem will suite this purpose.? My preference is UFS but ISO9660 works just as easily (other options are not so easy but still do-able).? Now, to create the filesystem, just install your system into a folder.? e.g. # su - # mkdir /tmp/world # cd src; make world kernel distribution DESTDIR=/tmp/world # cp /path/to/packages /tmp/world/tmp # chroot /tmp/world sh -c 'cd? /tmp ; pkg_add *' # rm -rf /tmp/world/tmp/* # cat > /tmp/world/etc/fstab < _EOF proc? ? ? ? ? ? ? ? ? ? /proc? ? ? ? ???procfs? rw? ? ? ? ? ? ? 0? ? ???0 tmpfs? ? ? ? ? ? ? ? ???/tmp? ? ? ? ? ? tmpfs???rw? ? ? ? ? ? ? 0? ? ???0 _EOF * Now, edit /tmp/world as you require to make it work as you want (the easiest way is to create a Flash stick [as per my script], edit the system live and then copy all changes across).? * STAGE 2: The filesystem image *** For UFS *** # makefs /tmp/world.ufs /tmp/world # MDDEV=$(mdconfig -a -t vnode /tmp/world.ufs) # tunefs -L ROOTFS /dev/$MDDEV # mdconfig -d -u $MDDEV *** For CD9660 *** # mkisofs -quiet -sysid FREEBSD -rock -untranslated-filenames -max-iso9660-filenames -iso-level 4 -volid DragonBSD -o $WORKDIR/DragonBSD.iso -volid DragonBSD -o /tmp/world.iso /tmp/world Now, since these images are often much larger then required I prefer to compress them.? This allows more programs to be added to the image and it takes up less memory during runtime (not to mention faster load times).? [I assume UFS option, do the appropriate for CD9660 option] # mkuzip -s 8192 -o /tmp/world.uzip /tmp/world.ufs STAGE 3: Loading the filesystem image Now you have an image that can be loaded on boot, to do so add the following to loader.conf # cd /path/to/boot/system/image # cat >> boot/loader.conf < _EOF rootfs_load="YES" rootfs_type="mfs_root" rootfs_name="/boot/world.uzip" _EOF # cp /tmp/world.uzip boot/ Now, to inform the system that you want it to boot off the memory system # cat >> boot/loader.conf < _EOF vfs.root.mountfrom="ufs:/dev/ufs/ROOTFS" _EOF STAGE 4: Making the Live System editable Now, to make the whole system editable (everything) is quite the challenge and requires a change in the way the previous stages are done.? The concept is simple though.? First: Because the filesystem was compressed (using mkuzip), it cannot be written to.? If the system were not compressed and extra space was allocated to the UFS image then it can be editable.? Even the extra size at load time can be compensated for (since loader supports compressed modules [both gzip and bzip2] however you will be running the full image uncompressed in memory.? It is faster but much more expensive.? Just to give you an idea, I have gotten a 700MB system to boot and run off a mini CD (210MB) and a system with 512MB of RAM, using the compressed approach with everything editable :-).? To do this approach requires some changes to stage 2.? Basically, after completing the approach for UFS image do the following # EXTRA_SIZE=32 # SIZE=$(($(du -m /tmp/world.ufs) + EXTRA_SIZE)) # dd if=/dev/zero of=/tmp/world.ufs count=$SIZE bs=1m? # NB, use zero to allow for compression # MDDEV=$(mdconfig -a -t vnode /tmp/world.ufs) # newfs -L ROOTFS -o space /dev/$MDDEV # mkdir /tmp/btstrp # mount /dev/$MDDEV /tmp/btstrp # (cd /tmp/world; tar -cf - .) | (cd /tmp/btstrp; tar -xf -) # umount /tmp/btstrp # mdconfig -d -u $MDDEV Next, DO NOT compress the image with mkuzip, instead do: # gzip -9 /tmp/world.ufs This requires either geom_uzip loaded or compiled into the kernel. and, instead of the first part of stage 3 do # cd /path/to/boot/system/image # cat >> boot/loader.conf < _EOF rootfs_load="YES" rootfs_type="mfs_root" rootfs_name="/boot/world.ufs" _EOF # cp /tmp/world.ufs.gz boot/ NOTE: this approach cannot be done using cd9660. The second approach, the one I prefer requires a double boot image (one inside the other), where the one acts as a boot strap, mdconfig and mount's the embedded second image, creates a editable fs using mdmfs and unionfs it over the second image.? This is done through using # cat >> boot/loader.conf < _EOF init_script="/chroot.sh" init_chroot="/base" where /chroot.sh basically does: mount -o ro /dev/$(mdconfig -a -t vnode -o readonly -f /world.uzip).uzip /base mdmfs -s 32m md /tmp mount -t unionfs -o noatime -o copymode=transparent /tmp/base It would be very nice to add unionfs support to tmpfs but not yet :-(.? The second approach I have not described fully, it is quite a bit more involved than the first but has great benefits, memory wise.? If you want more details about this approach please let me know.? I've created a set of scripts that are designed to create LiveCD/DVD/Flash of FreeBSD.? There are three cd9660 images that it produces: 1) CD backed live system (using compressed ufs image) 2) Memory backed live system (using compressed ufs image) 3) CD backed live system (no compression). And one Flash memory based image: 1) Flash based memory (using compressed ufs image and perpetual state overlay) [similar to option 1 above except the changes are permanent).? If you would like access to these scripts please let me know and I will gladly forward them to you.? Also if you have any questions or want further clarification please ask.? Regards, David Disclaimer: The commands may be incorrect but the procedure has been tried and tested.? From avg at icyb.net.ua Thu Apr 9 06:24:36 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Apr 9 06:24:43 2009 Subject: smart self-test vs 7200.12/ich9r/ahci Message-ID: <49DDF710.4050004@icyb.net.ua> I wonder if anybody has an issue like I do: http://thread.gmane.org/gmane.linux.utilities.smartmontools/6354 Does anybody has guesses/clues about what might be happening? -- Andriy Gapon From perryh at pluto.rain.com Thu Apr 9 13:13:32 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Thu Apr 9 13:13:39 2009 Subject: compiling root filesystem into kernel (preferably tmpfs root filesystem) In-Reply-To: <104771.62272.qm@web37103.mail.mud.yahoo.com> References: <104771.62272.qm@web37103.mail.mud.yahoo.com> Message-ID: <49de529c.UkvqMSxncVbt/6KA%perryh@pluto.rain.com> Travis Daygale wrote: > I have built a root image that I put in the kernel as described in > the Nov 2006 post. ?My UFS root image consists of /sbin/init, > where init is a statically compiled C program that just spits out > "Hello world" and sleeps, this binary runs fine under FBSD. ?At > this point, I have the kernel booting but it panics because it > says it can't find init.... ?Hmmm... ?I believe (haven't had time > to test) that it is finding root? Yes, if it gets to the point of "can't find init" it has already successfully mounted the root filesystem (although, perhaps, not the *intended* root filesystem). From anti_spamsys at yahoo.com Thu Apr 9 13:52:45 2009 From: anti_spamsys at yahoo.com (Travis Daygale) Date: Thu Apr 9 13:57:53 2009 Subject: compiling root filesystem into kernel (preferably tmpfs root filesystem) Message-ID: <449148.74528.qm@web37103.mail.mud.yahoo.com> I wonder if there is a sequence of loader commands and/or configuration (both at kernel compile and at boot) that can assure the kernel mounts the root filesystem installed into itself? Trever --- On Thu, 4/9/09, perryh@pluto.rain.com wrote: From: perryh@pluto.rain.com Subject: Re: compiling root filesystem into kernel (preferably tmpfs root filesystem) To: anti_spamsys@yahoo.com Cc: freebsd-hackers@freebsd.org Date: Thursday, April 9, 2009, 12:55 PM Travis Daygale wrote: > I have built a root image that I put in the kernel as described in > the Nov 2006 post. ?My UFS root image consists of /sbin/init, > where init is a statically compiled C program that just spits out > "Hello world" and sleeps, this binary runs fine under FBSD. ?At > this point, I have the kernel booting but it panics because it > says it can't find init.... ?Hmmm... ?I believe (haven't had time > to test) that it is finding root? Yes, if it gets to the point of "can't find init" it has already successfully mounted the root filesystem (although, perhaps, not the *intended* root filesystem). From naylor.b.david at gmail.com Thu Apr 9 22:42:52 2009 From: naylor.b.david at gmail.com (David Naylor) Date: Fri Apr 10 04:26:23 2009 Subject: compiling root filesystem into kernel (preferably tmpfs root filesystem) In-Reply-To: <104771.62272.qm@web37103.mail.mud.yahoo.com> References: <104771.62272.qm@web37103.mail.mud.yahoo.com> Message-ID: <200904100743.28140.naylor.b.david@gmail.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090410/113327df/attachment.pgp From xorquewasp at googlemail.com Fri Apr 10 09:08:01 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Fri Apr 10 09:08:09 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <20090410132354.GA20721@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> Message-ID: <20090410154251.GA49384@logik.internal.network> Hello. Recently bought a new system and am experiencing problems with system freezes. I think the most likely culprit is DRI. The freezes occur apparently at random. I've disabled drm.ko and radeon.ko and the system doesn't appear to have frozen yet. I'm running 7.2-PRERELEASE (STABLE as of yesterday). Machine's dmesg: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-PRERELEASE #0: Fri Apr 10 00:09:48 BST 2009 root@viper.internal.network:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (2665.04-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106a4 Stepping = 4 Features=0xbfebfbff Features2=0x98e3bd,,> AMD Features=0x28100800 AMD Features2=0x1 Cores per package: 8 Logical CPUs per core: 2 usable memory = 12862480384 (12266 MB) avail memory = 12424323072 (11848 MB) ACPI APIC Table: <121008 APIC1726> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <121008 RSDT1726> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci7: on pcib1 pcib2: at device 3.0 on pci0 pci6: on pcib2 vgapci0: port 0xe000-0xe0ff mem 0xd0000000-0xdfffffff,0xfbee0000-0xfbeeffff irq 16 at device 0.0 on pci6 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 vgapci1: mem 0xfbef0000-0xfbefffff at device 0.1 on pci6 pcib3: at device 7.0 on pci0 pci5: on pcib3 pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) uhci0: port 0x9080-0x909f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x9400-0x941f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x9480-0x949f irq 19 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfb9f6000-0xfb9f63ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered uhub4: on uhub3 uhub4: single transaction translator uhub4: 4 ports with 4 removable, self powered ukbd0: on uhub4 kbd2 at ukbd0 ums0: on uhub4 ums0: 3 buttons. ums1: on uhub4 ums1: 3 buttons and Z dir. uhub5: on uhub4 uhub5: 3 ports with 2 removable, bus powered ugen0: on uhub5 ukbd1: on uhub5 kbd3 at ukbd1 uhid0: on uhub5 pci0: at device 27.0 (no driver attached) pcib4: irq 17 at device 28.0 on pci0 pci4: on pcib4 atapci0: port 0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfbdfe000-0xfbdfffff irq 16 at device 0.0 on pci4 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI Version 01.00 controller with 2 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] pcib5: irq 16 at device 28.1 on pci0 pci3: on pcib5 re0: port 0xc800-0xc8ff mem 0xfbcff000-0xfbcfffff,0xcfff0000-0xcfffffff irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:e0:4d:b3:5b:bd re0: [FILTER] pcib6: irq 18 at device 28.2 on pci0 pci2: on pcib6 re1: port 0xb800-0xb8ff mem 0xfbbff000-0xfbbfffff,0xcfef0000-0xcfefffff irq 18 at device 0.0 on pci2 re1: Using 1 MSI messages re1: Chip rev. 0x3c000000 re1: MAC rev. 0x00400000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re1: Ethernet address: 00:e0:4d:b3:5b:be re1: [FILTER] uhci3: port 0x9800-0x981f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub6: on usb4 uhub6: 2 ports with 2 removable, self powered uhci4: port 0x9880-0x989f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub7: on usb5 uhub7: 2 ports with 2 removable, self powered uhci5: port 0x9c00-0x9c1f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub8: on usb6 uhub8: 2 ports with 2 removable, self powered ehci1: mem 0xfb9fc000-0xfb9fc3ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub9: on usb7 uhub9: 6 ports with 6 removable, self powered pcib7: at device 30.0 on pci0 pci1: on pcib7 fwohci0: mem 0xfbaff800-0xfbafffff,0xfbaf8000-0xfbafbfff irq 19 at device 7.0 on pci1 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:00:00:00:07:7b:3d fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x199c000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:00:07:7b:3d fwe0: Ethernet address: 02:00:00:07:7b:3d fwip0: on firewire0 fwip0: Firewire address: 00:00:00:00:00:07:7b:3d @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff90-0xff9f,0xffa0-0xffaf at device 31.2 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa40f,0xa080-0xa08f irq 19 at device 31.5 on pci0 atapci2: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] acpi_button0: on acpi0 acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] cpu0: on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - 6, should be FE [20070320] est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 device_attach: est3 attach returned 6 p4tcc3: on cpu3 cpu4: on acpi0 est4: on cpu4 p4tcc4: on cpu4 cpu5: on acpi0 est5: on cpu5 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 device_attach: est5 attach returned 6 p4tcc5: on cpu5 cpu6: on acpi0 est6: on cpu6 p4tcc6: on cpu6 cpu7: on acpi0 est7: on cpu7 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 device_attach: est7 attach returned 6 p4tcc7: on cpu7 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ad0: 76319MB at ata0-master SATA300 ad2: 953869MB at ata1-master SATA300 GEOM_LABEL: Label for provider ad0s1a is ufsid/49dd1626d599346c. GEOM_LABEL: Label for provider ad0s1d is ufsid/49dd1626c888923e. GEOM_LABEL: Label for provider ad0s1e is ufsid/49dd16280e8a20d0. GEOM_LABEL: Label for provider ad0s1f is ufsid/49dd1626ed87573c. acd0: DVDR at ata4-master UDMA66 SMP: AP CPU #1 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #7 Launched! Trying to mount root from ufs:/dev/ad0s1a cryptosoft0: on motherboard GEOM_ELI: Device ad0s1b.eli created. GEOM_ELI: Encryption: AES-CBC 256 GEOM_ELI: Crypto: software GEOM_LABEL: Label ufsid/49dd1626d599346c removed. GEOM_LABEL: Label for provider ad0s1a is ufsid/49dd1626d599346c. GEOM_LABEL: Label ufsid/49dd1626c888923e removed. GEOM_LABEL: Label for provider ad0s1d is ufsid/49dd1626c888923e. GEOM_LABEL: Label ufsid/49dd1626ed87573c removed. GEOM_LABEL: Label for provider ad0s1f is ufsid/49dd1626ed87573c. GEOM_LABEL: Label ufsid/49dd16280e8a20d0 removed. GEOM_LABEL: Label for provider ad0s1e is ufsid/49dd16280e8a20d0. GEOM_LABEL: Label ufsid/49dd1626d599346c removed. GEOM_LABEL: Label ufsid/49dd1626c888923e removed. GEOM_LABEL: Label ufsid/49dd1626ed87573c removed. GEOM_LABEL: Label ufsid/49dd16280e8a20d0 removed. re0: link state changed to UP I've not been able to obtain anything in the way of crash logs. The system just freezes and doesn't respond to keyboard, mouse, network activity, shouting and/or threats. I've run memtest86+ for hours with no errors, tested the CPU with various utilities and run WD's hard disk diagnostic tools. As I said, DRI seems the likely culprit. Unfortunately I can't do without DRI as this machine's intended for OpenGL development and video editing. Any advice would be much appreciated. I'm under slight time pressure to get this system up and running. thanks, xw From rnoland at FreeBSD.org Fri Apr 10 10:43:43 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Fri Apr 10 10:43:51 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <20090410154251.GA49384@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> Message-ID: <1239385368.1922.74.camel@balrog.2hip.net> On Fri, 2009-04-10 at 16:42 +0100, xorquewasp@googlemail.com wrote: > Hello. > > Recently bought a new system and am experiencing problems with system freezes. > I think the most likely culprit is DRI. The freezes occur apparently at random. > I've disabled drm.ko and radeon.ko and the system doesn't appear to have frozen > yet. > > I'm running 7.2-PRERELEASE (STABLE as of yesterday). > > Machine's dmesg: > > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.2-PRERELEASE #0: Fri Apr 10 00:09:48 BST 2009 > root@viper.internal.network:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (2665.04-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0x106a4 Stepping = 4 > Features=0xbfebfbff > Features2=0x98e3bd,,> > AMD Features=0x28100800 > AMD Features2=0x1 > Cores per package: 8 > Logical CPUs per core: 2 > usable memory = 12862480384 (12266 MB) > avail memory = 12424323072 (11848 MB) > ACPI APIC Table: <121008 APIC1726> > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > cpu4 (AP): APIC ID: 4 > cpu5 (AP): APIC ID: 5 > cpu6 (AP): APIC ID: 6 > cpu7 (AP): APIC ID: 7 > ioapic0: Changing APIC ID to 8 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: <121008 RSDT1726> on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, bff00000 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci7: on pcib1 > pcib2: at device 3.0 on pci0 > pci6: on pcib2 > vgapci0: port 0xe000-0xe0ff mem 0xd0000000-0xdfffffff,0xfbee0000-0xfbeeffff irq 16 at device 0.0 on pci6 > drm0: on vgapci0 > vgapci0: child drm0 requested pci_enable_busmaster > info: [drm] Initialized radeon 1.29.0 20080528 > vgapci1: mem 0xfbef0000-0xfbefffff at device 0.1 on pci6 > pcib3: at device 7.0 on pci0 > pci5: on pcib3 > pci0: at device 16.0 (no driver attached) > pci0: at device 16.1 (no driver attached) > pci0: at device 20.0 (no driver attached) > pci0: at device 20.1 (no driver attached) > pci0: at device 20.2 (no driver attached) > pci0: at device 20.3 (no driver attached) > uhci0: port 0x9080-0x909f irq 16 at device 26.0 on pci0 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0x9400-0x941f irq 21 at device 26.1 on pci0 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0x9480-0x949f irq 19 at device 26.2 on pci0 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > ehci0: mem 0xfb9f6000-0xfb9f63ff irq 18 at device 26.7 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb3: EHCI version 1.0 > usb3: companion controllers, 2 ports each: usb0 usb1 usb2 > usb3: on ehci0 > usb3: USB revision 2.0 > uhub3: on usb3 > uhub3: 6 ports with 6 removable, self powered > uhub4: on uhub3 > uhub4: single transaction translator > uhub4: 4 ports with 4 removable, self powered > ukbd0: on uhub4 > kbd2 at ukbd0 > ums0: on uhub4 > ums0: 3 buttons. > ums1: on uhub4 > ums1: 3 buttons and Z dir. > uhub5: on uhub4 > uhub5: 3 ports with 2 removable, bus powered > ugen0: on uhub5 > ukbd1: on uhub5 > kbd3 at ukbd1 > uhid0: on uhub5 > pci0: at device 27.0 (no driver attached) > pcib4: irq 17 at device 28.0 on pci0 > pci4: on pcib4 > atapci0: port 0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfbdfe000-0xfbdfffff irq 16 at device 0.0 on pci4 > atapci0: [ITHREAD] > atapci0: AHCI called from vendor specific driver > atapci0: AHCI Version 01.00 controller with 2 ports detected > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > ata4: on atapci0 > ata4: [ITHREAD] > pcib5: irq 16 at device 28.1 on pci0 > pci3: on pcib5 > re0: port 0xc800-0xc8ff mem 0xfbcff000-0xfbcfffff,0xcfff0000-0xcfffffff irq 17 at device 0.0 on pci3 > re0: Using 1 MSI messages > re0: Chip rev. 0x3c000000 > re0: MAC rev. 0x00400000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > re0: Ethernet address: 00:e0:4d:b3:5b:bd > re0: [FILTER] > pcib6: irq 18 at device 28.2 on pci0 > pci2: on pcib6 > re1: port 0xb800-0xb8ff mem 0xfbbff000-0xfbbfffff,0xcfef0000-0xcfefffff irq 18 at device 0.0 on pci2 > re1: Using 1 MSI messages > re1: Chip rev. 0x3c000000 > re1: MAC rev. 0x00400000 > miibus1: on re1 > rgephy1: PHY 1 on miibus1 > rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > re1: Ethernet address: 00:e0:4d:b3:5b:be > re1: [FILTER] > uhci3: port 0x9800-0x981f irq 23 at device 29.0 on pci0 > uhci3: [GIANT-LOCKED] > uhci3: [ITHREAD] > usb4: on uhci3 > usb4: USB revision 1.0 > uhub6: on usb4 > uhub6: 2 ports with 2 removable, self powered > uhci4: port 0x9880-0x989f irq 19 at device 29.1 on pci0 > uhci4: [GIANT-LOCKED] > uhci4: [ITHREAD] > usb5: on uhci4 > usb5: USB revision 1.0 > uhub7: on usb5 > uhub7: 2 ports with 2 removable, self powered > uhci5: port 0x9c00-0x9c1f irq 18 at device 29.2 on pci0 > uhci5: [GIANT-LOCKED] > uhci5: [ITHREAD] > usb6: on uhci5 > usb6: USB revision 1.0 > uhub8: on usb6 > uhub8: 2 ports with 2 removable, self powered > ehci1: mem 0xfb9fc000-0xfb9fc3ff irq 23 at device 29.7 on pci0 > ehci1: [GIANT-LOCKED] > ehci1: [ITHREAD] > usb7: EHCI version 1.0 > usb7: companion controllers, 2 ports each: usb4 usb5 usb6 > usb7: on ehci1 > usb7: USB revision 2.0 > uhub9: on usb7 > uhub9: 6 ports with 6 removable, self powered > pcib7: at device 30.0 on pci0 > pci1: on pcib7 > fwohci0: mem 0xfbaff800-0xfbafffff,0xfbaf8000-0xfbafbfff irq 19 at device 7.0 on pci1 > fwohci0: [FILTER] > fwohci0: OHCI version 1.10 (ROM=1) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:00:00:00:00:07:7b:3d > fwohci0: Phy 1394a available S400, 2 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > dcons_crom0: on firewire0 > dcons_crom0: bus_addr 0x199c000 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:00:00:07:7b:3d > fwe0: Ethernet address: 02:00:00:07:7b:3d > fwip0: on firewire0 > fwip0: Firewire address: 00:00:00:00:00:07:7b:3d @ 0xfffe00000000, S400, maxrec 2048 > sbp0: on firewire0 > fwohci0: Initiate bus reset > fwohci0: BUS reset > fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff90-0xff9f,0xffa0-0xffaf at device 31.2 on pci0 > ata0: on atapci1 > ata0: [ITHREAD] > ata1: on atapci1 > ata1: [ITHREAD] > pci0: at device 31.3 (no driver attached) > atapci2: port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa40f,0xa080-0xa08f irq 19 at device 31.5 on pci0 > atapci2: [ITHREAD] > ata5: on atapci2 > ata5: [ITHREAD] > ata6: on atapci2 > ata6: [ITHREAD] > acpi_button0: on acpi0 > acpi_tz0: on acpi0 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FILTER] > cpu0: on acpi0 > ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - 6, should be FE [20070320] > est0: on cpu0 > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 14 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > cpu2: on acpi0 > est2: on cpu2 > p4tcc2: on cpu2 > cpu3: on acpi0 > est3: on cpu3 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 14 > device_attach: est3 attach returned 6 > p4tcc3: on cpu3 > cpu4: on acpi0 > est4: on cpu4 > p4tcc4: on cpu4 > cpu5: on acpi0 > est5: on cpu5 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 14 > device_attach: est5 attach returned 6 > p4tcc5: on cpu5 > cpu6: on acpi0 > est6: on cpu6 > p4tcc6: on cpu6 > cpu7: on acpi0 > est7: on cpu7 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 14 > device_attach: est7 attach returned 6 > p4tcc7: on cpu7 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > ppc0: cannot reserve I/O port range > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 8250 or not responding > sio0: [FILTER] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounters tick every 1.000 msec > firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) > firewire0: bus manager 0 (me) > ad0: 76319MB at ata0-master SATA300 > ad2: 953869MB at ata1-master SATA300 > GEOM_LABEL: Label for provider ad0s1a is ufsid/49dd1626d599346c. > GEOM_LABEL: Label for provider ad0s1d is ufsid/49dd1626c888923e. > GEOM_LABEL: Label for provider ad0s1e is ufsid/49dd16280e8a20d0. > GEOM_LABEL: Label for provider ad0s1f is ufsid/49dd1626ed87573c. > acd0: DVDR at ata4-master UDMA66 > SMP: AP CPU #1 Launched! > SMP: AP CPU #4 Launched! > SMP: AP CPU #6 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #5 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #7 Launched! > Trying to mount root from ufs:/dev/ad0s1a > cryptosoft0: on motherboard > GEOM_ELI: Device ad0s1b.eli created. > GEOM_ELI: Encryption: AES-CBC 256 > GEOM_ELI: Crypto: software > GEOM_LABEL: Label ufsid/49dd1626d599346c removed. > GEOM_LABEL: Label for provider ad0s1a is ufsid/49dd1626d599346c. > GEOM_LABEL: Label ufsid/49dd1626c888923e removed. > GEOM_LABEL: Label for provider ad0s1d is ufsid/49dd1626c888923e. > GEOM_LABEL: Label ufsid/49dd1626ed87573c removed. > GEOM_LABEL: Label for provider ad0s1f is ufsid/49dd1626ed87573c. > GEOM_LABEL: Label ufsid/49dd16280e8a20d0 removed. > GEOM_LABEL: Label for provider ad0s1e is ufsid/49dd16280e8a20d0. > GEOM_LABEL: Label ufsid/49dd1626d599346c removed. > GEOM_LABEL: Label ufsid/49dd1626c888923e removed. > GEOM_LABEL: Label ufsid/49dd1626ed87573c removed. > GEOM_LABEL: Label ufsid/49dd16280e8a20d0 removed. > re0: link state changed to UP > > I've not been able to obtain anything in the way of crash logs. The system > just freezes and doesn't respond to keyboard, mouse, network activity, > shouting and/or threats. > > I've run memtest86+ for hours with no errors, tested the CPU with various > utilities and run WD's hard disk diagnostic tools. As I said, DRI seems > the likely culprit. Unfortunately I can't do without DRI as this machine's > intended for OpenGL development and video editing. > > Any advice would be much appreciated. I'm under slight time pressure to > get this system up and running. Are you running powerd by chance? I was seeing an issue that seemed to be related to powerd. Since I've disabled it on that box, it hasn't hung up any more. As far as drm is concerned, I've been running on an x1650 for probably a week now while working mostly on port stuff and I haven't seen any issues. This is with full 3d and compiz running, etc... So, if it is drm related... we are going to have to dig up some debugging info somehow... robert. > thanks, > xw > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090410/40485452/attachment.pgp From xorquewasp at googlemail.com Fri Apr 10 10:58:28 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Fri Apr 10 10:58:43 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <1239385368.1922.74.camel@balrog.2hip.net> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> Message-ID: <20090410175922.GA50520@logik.internal.network> Hello. On 2009-04-10 12:42:48, Robert Noland wrote: > > Are you running powerd by chance? I was seeing an issue that seemed to > be related to powerd. Since I've disabled it on that box, it hasn't > hung up any more. I'm not running powerd, no. > > As far as drm is concerned, I've been running on an x1650 for probably a > week now while working mostly on port stuff and I haven't seen any > issues. This is with full 3d and compiz running, etc... So, if it is > drm related... we are going to have to dig up some debugging info > somehow... > > robert. > The system doesn't seem to have frozen since DRI/DRM was disabled. I did have one crash/reboot whilst building a large number of packages with tinderbox. I've currently got both tinderbox and a make -j 16 buildworld going on a loop in the hope that I can trigger it again. Being the idiot I am, I had encrypted swap enabled and so savecore didn't save anything. Won't make that mistake twice. I'm currently using a world compiled WITH_DEBUG but is there anything else I can do? thanks, xw From rnoland at FreeBSD.org Fri Apr 10 11:32:28 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Fri Apr 10 11:33:00 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <20090410175922.GA50520@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> Message-ID: <1239388293.1922.80.camel@balrog.2hip.net> On Fri, 2009-04-10 at 18:59 +0100, xorquewasp@googlemail.com wrote: > Hello. > > On 2009-04-10 12:42:48, Robert Noland wrote: > > > > Are you running powerd by chance? I was seeing an issue that seemed to > > be related to powerd. Since I've disabled it on that box, it hasn't > > hung up any more. > > I'm not running powerd, no. > > > > > As far as drm is concerned, I've been running on an x1650 for probably a > > week now while working mostly on port stuff and I haven't seen any > > issues. This is with full 3d and compiz running, etc... So, if it is > > drm related... we are going to have to dig up some debugging info > > somehow... > > > > robert. > > > > The system doesn't seem to have frozen since DRI/DRM was disabled. > > I did have one crash/reboot whilst building a large number of packages > with tinderbox. I've currently got both tinderbox and a make -j 16 > buildworld going on a loop in the hope that I can trigger it again. > > Being the idiot I am, I had encrypted swap enabled and so savecore > didn't save anything. Won't make that mistake twice. > > I'm currently using a world compiled WITH_DEBUG but is there anything > else I can do? If it is locking the whole system, then a core is really our best shot. If you can extract anything useful from xorg.log or setting hw.dri.0.debug that also might be of use. I'm running on 2 cores, but it is possible that some locking issue exists. All of the driver specific ioctls are run under a lock though. robert. > thanks, > xw > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090410/1409b0cc/attachment.pgp From xorquewasp at googlemail.com Fri Apr 10 14:13:11 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Fri Apr 10 14:13:25 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <1239388293.1922.80.camel@balrog.2hip.net> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> Message-ID: <20090410211307.GA83697@logik.internal.network> On 2009-04-10 13:31:33, Robert Noland wrote: > > If it is locking the whole system, then a core is really our best shot. > If you can extract anything useful from xorg.log or setting > hw.dri.0.debug that also might be of use. > > I'm running on 2 cores, but it is possible that some locking issue > exists. All of the driver specific ioctls are run under a lock though. > > robert. Ok. I've re-enabled drm.ko and radeon.ko and am running X. I'll leave the system under load and let you know when it inevitably locks up... cheers, xw From brampton+freebsd-hackers at gmail.com Fri Apr 10 16:37:47 2009 From: brampton+freebsd-hackers at gmail.com (Andrew Brampton) Date: Fri Apr 10 16:37:56 2009 Subject: FreeBSD memguard + spinlocks Message-ID: Hi, I'm having a problem with memguard(9) on FreeBSD 7.1 but before I ask about that I just need to check my facts about malloc. When in interrupt context malloc must be called with M_NOWAIT, this is because I can't sleep inside a interrupt. Now when I hold a spinlock (MTX_SPIN) I am also not allowed to sleep or obtain a sleepable mutex (such as MTX_DEF). So I assume while holding a spin lock any mallocs I do must have the M_NOWAIT flag? This was not clear from the manual pages, but at least makes sense to me. So my problem with memguard stems from the fact that I am locking a spinlock, and then I'm calling malloc with M_NOWAIT. But inside memguard_alloc a MTX_DEF is acquired causing WITNESS to panic. So I think fundamental memguard is flawed and should be using MTX_SPIN instead of MTX_DEF otherwise it can't be called from inside a interrupt or when a spin lock is held. But maybe I'm missing something? Also on a related note, I see that MTX_SPIN disables interrupts, making it a rather "heavy" spinlock. Is there a lighter spin lock that literally just spins? I read that MTX_DEF are far quicker to acquire , but surely a light spinlock would be easier to acquire than sleeping? I think for the moment I will fix my code by not using a MTX_SPIN (since the code is not in a interrupt), however, I think memguard should change its lock. thanks Andrew From onemda at gmail.com Fri Apr 10 17:30:42 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Fri Apr 10 17:30:48 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <20090410211307.GA83697@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090410211307.GA83697@logik.internal.network> Message-ID: <3a142e750904101730k53b7fbabn6e801ac36f1182e0@mail.gmail.com> On 4/10/09, xorquewasp@googlemail.com wrote: > On 2009-04-10 13:31:33, Robert Noland wrote: >> >> If it is locking the whole system, then a core is really our best shot. >> If you can extract anything useful from xorg.log or setting >> hw.dri.0.debug that also might be of use. >> >> I'm running on 2 cores, but it is possible that some locking issue >> exists. All of the driver specific ioctls are run under a lock though. >> >> robert. > > Ok. I've re-enabled drm.ko and radeon.ko and am running X. I'll leave > the system under load and let you know when it inevitably locks up... > > cheers, If it locks under X11 then use debug.debugger_on_panic=0 sysctl. Not doing this will increase drasticaly chances of locking whole system and not providing any debug data. -- Paul From xorquewasp at googlemail.com Sat Apr 11 03:30:37 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sat Apr 11 03:30:50 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <3a142e750904101730k53b7fbabn6e801ac36f1182e0@mail.gmail.com> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090410211307.GA83697@logik.internal.network> <3a142e750904101730k53b7fbabn6e801ac36f1182e0@mail.gmail.com> Message-ID: <20090411101559.GC83697@logik.internal.network> On 2009-04-11 02:30:40, Paul B. Mahol wrote: > > If it locks under X11 then use debug.debugger_on_panic=0 sysctl. > Not doing this will increase drasticaly chances of locking whole system > and not providing any debug data. I don't seem to have that sysctl. You sure that's the correct name? xw From xorquewasp at googlemail.com Sat Apr 11 03:30:39 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sat Apr 11 03:30:51 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <1239388293.1922.80.camel@balrog.2hip.net> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> Message-ID: <20090411102300.GD83697@logik.internal.network> The machine ran for hours, apparently. I ended up going to bed and leaving it running. Woke up to find it on display sleep, frozen. It didn't panic, apparently. I've included Xorg.0.log and the last few lines of /var/log/messages but I don't believe they show anything very interesting. I should point out that this card is the dual-DVI version. I'm not sure if that's relevant (I think it's just less common). I'm only using one screen, currently. /var/log/Xorg.0.log: X.Org X Server 1.6.0 Release Date: 2009-2-25 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.2-PRERELEASE amd64 Current Operating System: FreeBSD viper.internal.network 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Fri Apr 10 00:09:48 BST 2009 root@viper.internal.network:/usr/obj/usr/src/sys/GENERIC amd64 Build Date: 11 April 2009 04:34:30AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sat Apr 11 06:16:46 2009 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (==) Not automatically adding devices (==) Not automatically enabling devices (WW) The directory "/usr/local/lib/X11/fonts/TTF/" does not exist. Entry deleted from font path. (WW) The directory "/usr/local/lib/X11/fonts/OTF" does not exist. Entry deleted from font path. (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. Entry deleted from font path. (WW) The directory "/usr/local/lib/X11/fonts/TTF/" does not exist. Entry deleted from font path. (WW) The directory "/usr/local/lib/X11/fonts/OTF" does not exist. Entry deleted from font path. (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. Entry deleted from font path. (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, built-ins (**) ModulePath set to "/usr/local/lib/xorg/modules" (II) Loader magic: 0xd20 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on freebsd (--) Using syscons driver with X support (version 134217730.0) (--) using VT number 9 (--) PCI:*(0@6:0:0) ATI Technologies Inc RV570 [Radeon X1950 Pro] rev 154, Mem @ 0xd0000000/268435456, 0xfbee0000/65536, I/O @ 0x0000e000/256, BIOS @ 0x????????/65536 (--) PCI: (0@6:0:1) ATI Technologies Inc RV570 [Radeon X1950 Pro] (secondary) rev 154, Mem @ 0xfbef0000/65536 (II) System resource ranges: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. (II) "dbe" will be loaded. This was enabled by default and also specified in the config file. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "record" will be loaded. This was enabled by default and also specified in the config file. (II) "dri" will be loaded. This was enabled by default and also specified in the config file. (II) "dri2" will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (==) AIGLX disabled (II) Loading extension GLX (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dri2" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "radeon" (II) Loading /usr/local/lib/xorg/modules/drivers//radeon_drv.so (II) Module radeon: vendor="X.Org Foundation" compiled for 1.6.0, module version = 6.12.2 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) LoadModule: "mouse" (II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.4.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (II) LoadModule: "kbd" (II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.3.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI FireMV 2400 (PCI), ATI Radeon Mobility X300 (M24) 3152 (PCIE), ATI FireGL M24 GL 3154 (PCIE), ATI Radeon X600 (RV380) 3E50 (PCIE), ATI FireGL V3200 (RV380) 3E54 (PCIE), ATI Radeon IGP320 (A3) 4136, ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon 9500 AD (AGP), ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP), ATI FireGL Z1 AG (AGP), ATI Radeon 9800SE AH (AGP), ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP), ATI FireGL X2 AK (AGP), ATI Radeon 9600 AP (AGP), ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP), ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP), ATI Radeon 9650, ATI FireGL RV360 AV (AGP), ATI Radeon 7000 IGP (A4+) 4237, ATI Radeon 8500 AIW BB (AGP), ATI Radeon 8500 AIW BC (AGP), ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330M/340M/350M (U2) 4337, ATI Radeon Mobility 7000 IGP 4437, ATI Radeon 9000/PRO If (AGP/PCI), ATI Radeon 9000 Ig (AGP/PCI), ATI Radeon X800 (R420) JH (AGP), ATI Radeon X800PRO (R420) JI (AGP), ATI Radeon X800SE (R420) JJ (AGP), ATI Radeon X800 (R420) JK (AGP), ATI Radeon X800 (R420) JL (AGP), ATI FireGL X3 (R420) JM (AGP), ATI Radeon Mobility 9800 (M18) JN (AGP), ATI Radeon X800 SE (R420) (AGP), ATI Radeon X800XT (R420) JP (AGP), ATI Radeon X850 XT (R480) (AGP), ATI Radeon X850 SE (R480) (AGP), ATI Radeon X850 PRO (R480) (AGP), ATI Radeon X850 XT PE (R480) (AGP), ATI Radeon Mobility M7 LW (AGP), ATI Mobility FireGL 7800 M7 LX (AGP), ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP), ATI FireGL Mobility 9000 (M9) Ld (AGP), ATI Radeon Mobility 9000 (M9) Lf (AGP), ATI Radeon Mobility 9000 (M9) Lg (AGP), ATI Radeon 9700 Pro ND (AGP), ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9600TX NF (AGP), ATI FireGL X1 NG (AGP), ATI Radeon 9800PRO NH (AGP), ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP), ATI Radeon 9800XT NJ (AGP), ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP), ATI Radeon Mobility 9600 (M10) NQ (AGP), ATI Radeon Mobility 9600 (M11) NR (AGP), ATI Radeon Mobility 9600 (M10) NS (AGP), ATI FireGL Mobility T2 (M10) NT (AGP), ATI FireGL Mobility T2e (M11) NV (AGP), ATI Radeon QD (AGP), ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP), ATI Radeon 9100 QM (AGP), ATI Radeon 7500 QW (AGP/PCI), ATI Radeon 7500 QX (AGP/PCI), ATI Radeon VE/7000 QY (AGP/PCI), ATI Radeon VE/7000 QZ (AGP/PCI), ATI ES1000 515E (PCI), ATI Radeon Mobility X300 (M22) 5460 (PCIE), ATI Radeon Mobility X600 SE (M24C) 5462 (PCIE), ATI FireGL M22 GL 5464 (PCIE), ATI Radeon X800 (R423) UH (PCIE), ATI Radeon X800PRO (R423) UI (PCIE), ATI Radeon X800LE (R423) UJ (PCIE), ATI Radeon X800SE (R423) UK (PCIE), ATI Radeon X800 XTP (R430) (PCIE), ATI Radeon X800 XL (R430) (PCIE), ATI Radeon X800 SE (R430) (PCIE), ATI Radeon X800 (R430) (PCIE), ATI FireGL V7100 (R423) (PCIE), ATI FireGL V5100 (R423) UQ (PCIE), ATI FireGL unknown (R423) UR (PCIE), ATI FireGL unknown (R423) UT (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility Radeon X700 XL (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Radeon X550XTX 5657 (PCIE), ATI Radeon 9100 IGP (A5) 5834, ATI Radeon Mobility 9100 IGP (U3) 5835, ATI Radeon XPRESS 200 5954 (PCIE), ATI Radeon XPRESS 200M 5955 (PCIE), ATI Radeon 9250 5960 (AGP), ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP), ATI Radeon 9200SE 5964 (AGP), ATI FireMV 2200 (PCI), ATI ES1000 5969 (PCI), ATI Radeon XPRESS 200 5974 (PCIE), ATI Radeon XPRESS 200M 5975 (PCIE), ATI Radeon XPRESS 200 5A41 (PCIE), ATI Radeon XPRESS 200M 5A42 (PCIE), ATI Radeon XPRESS 200 5A61 (PCIE), ATI Radeon XPRESS 200M 5A62 (PCIE), ATI Radeon X300 (RV370) 5B60 (PCIE), ATI Radeon X600 (RV370) 5B62 (PCIE), ATI Radeon X550 (RV370) 5B63 (PCIE), ATI FireGL V3100 (RV370) 5B64 (PCIE), ATI FireMV 2200 PCIE (RV370) 5B65 (PCIE), ATI Radeon Mobility 9200 (M9+) 5C61 (AGP), ATI Radeon Mobility 9200 (M9+) 5C63 (AGP), ATI Mobility Radeon X800 XT (M28) (PCIE), ATI Mobility FireGL V5100 (M28) (PCIE), ATI Mobility Radeon X800 (M28) (PCIE), ATI Radeon X850 5D4C (PCIE), ATI Radeon X850 XT PE (R480) (PCIE), ATI Radeon X850 SE (R480) (PCIE), ATI Radeon X850 PRO (R480) (PCIE), ATI unknown Radeon / FireGL (R480) 5D50 (PCIE), ATI Radeon X850 XT (R480) (PCIE), ATI Radeon X800XT (R423) 5D57 (PCIE), ATI FireGL V5000 (RV410) (PCIE), ATI Radeon X700 XT (RV410) (PCIE), ATI Radeon X700 PRO (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X700 (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X1800, ATI Mobility Radeon X1800 XT, ATI Mobility Radeon X1800, ATI Mobility FireGL V7200, ATI FireGL V7200, ATI FireGL V5300, ATI Mobility FireGL V7100, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI FireGL V7300, ATI FireGL V7350, ATI Radeon X1600, ATI RV505, ATI Radeon X1300/X1550, ATI Radeon X1550, ATI M54-GL, ATI Mobility Radeon X1400, ATI Radeon X1300/X1550, ATI Radeon X1550 64-bit, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Radeon X1300, ATI Radeon X1300, ATI RV505, ATI RV505, ATI FireGL V3300, ATI FireGL V3350, ATI Radeon X1300, ATI Radeon X1550 64-bit, ATI Radeon X1300/X1550, ATI Radeon X1600, ATI Radeon X1300/X1550, ATI Mobility Radeon X1450, ATI Radeon X1300/X1550, ATI Mobility Radeon X2300, ATI Mobility Radeon X2300, ATI Mobility Radeon X1350, ATI Mobility Radeon X1350, ATI Mobility Radeon X1450, ATI Radeon X1300, ATI Radeon X1550, ATI Mobility Radeon X1350, ATI FireMV 2250, ATI Radeon X1550 64-bit, ATI Radeon X1600, ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1600, ATI Mobility FireGL V5200, ATI Mobility Radeon X1600, ATI Radeon X1650, ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1300 XT/X1600 Pro, ATI FireGL V3400, ATI Mobility FireGL V5250, ATI Mobility Radeon X1700, ATI Mobility Radeon X1700 XT, ATI FireGL V5200, ATI Mobility Radeon X1700, ATI Radeon X2300HD, ATI Mobility Radeon HD 2300, ATI Mobility Radeon HD 2300, ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI AMD Stream Processor, ATI Radeon X1900, ATI Radeon X1950, ATI RV560, ATI RV560, ATI Mobility Radeon X1900, ATI RV560, ATI Radeon X1950 GT, ATI RV570, ATI RV570, ATI FireGL V7400, ATI RV560, ATI Radeon X1650, ATI Radeon X1650, ATI RV560, ATI Radeon 9100 PRO IGP 7834, ATI Radeon Mobility 9200 IGP 7835, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI RS740, ATI RS740M, ATI RS740, ATI RS740M, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 Pro, ATI Radeon HD 2900 GT, ATI FireGL V8650, ATI FireGL V8600, ATI FireGL V7600, ATI Radeon 4800 Series, ATI Radeon HD 4870 x2, ATI Radeon 4800 Series, ATI FirePro V8750 (FireGL), ATI FirePro V7760 (FireGL), ATI Mobility RADEON HD 4850, ATI Mobility RADEON HD 4850 X2, ATI Radeon 4800 Series, ATI FirePro RV770, AMD FireStream 9270, AMD FireStream 9250, ATI FirePro V8700 (FireGL), ATI Mobility RADEON HD 4870, ATI Mobility RADEON M98, ATI Radeon 4800 Series, ATI Radeon 4800 Series, ATI FirePro M7750, ATI M98, ATI M98, ATI M98, ATI Radeon RV730 (AGP), ATI FirePro M5750, ATI Radeon RV730 (AGP), ATI RV730XT [Radeon HD 4670], ATI RADEON E4600, ATI RV730 PRO [Radeon HD 4650], ATI FirePro V7750 (FireGL), ATI FirePro V5700 (FireGL), ATI FirePro V3750 (FireGL), ATI RV610, ATI Radeon HD 2400 XT, ATI Radeon HD 2400 Pro, ATI Radeon HD 2400 PRO AGP, ATI FireGL V4000, ATI RV610, ATI Radeon HD 2350, ATI Mobility Radeon HD 2400 XT, ATI Mobility Radeon HD 2400, ATI RADEON E2400, ATI RV610, ATI FireMV 2260, ATI RV670, ATI Radeon HD3870, ATI Mobility Radeon HD 3850, ATI Radeon HD3850, ATI Mobility Radeon HD 3850 X2, ATI RV670, ATI Mobility Radeon HD 3870, ATI Mobility Radeon HD 3870 X2, ATI Radeon HD3870 X2, ATI FireGL V7700, ATI Radeon HD3850, ATI Radeon HD3690, AMD Firestream 9170, ATI Radeon HD 4550, ATI Radeon RV710, ATI Radeon RV710, ATI Radeon HD 4350, ATI Mobility Radeon 4300 Series, ATI Mobility Radeon 4500 Series, ATI Mobility Radeon 4500 Series, ATI RV630, ATI Mobility Radeon HD 2600, ATI Mobility Radeon HD 2600 XT, ATI Radeon HD 2600 XT AGP, ATI Radeon HD 2600 Pro AGP, ATI Radeon HD 2600 XT, ATI Radeon HD 2600 Pro, ATI Gemini RV630, ATI Gemini Mobility Radeon HD 2600 XT, ATI FireGL V5600, ATI FireGL V3600, ATI Radeon HD 2600 LE, ATI Mobility FireGL Graphics Processor, ATI Radeon RV710, ATI Radeon HD 3470, ATI Mobility Radeon HD 3430, ATI Mobility Radeon HD 3400 Series, ATI Radeon HD 3450, ATI Radeon HD 3450, ATI Radeon HD 3430, ATI Radeon HD 3450, ATI FirePro V3700, ATI FireMV 2450, ATI FireMV 2260, ATI FireMV 2260, ATI Radeon HD 3600 Series, ATI Radeon HD 3650 AGP, ATI Radeon HD 3600 PRO, ATI Radeon HD 3600 XT, ATI Radeon HD 3600 PRO, ATI Mobility Radeon HD 3650, ATI Mobility Radeon HD 3670, ATI Mobility FireGL V5700, ATI Mobility FireGL V5725, ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics, ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics, ATI Radeon HD 3300 Graphics, ATI Radeon HD 3200 Graphics, ATI Radeon 3000 Graphics, ATI Radeon HD Graphics, ATI Radeon Graphics, ATI Mobility Radeon HD Graphics, ATI Mobility Radeon Graphics, ATI Radeon Graphics (II) Primary Device is: PCI 06@00:00:0 (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) resource ranges after probing: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [4] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [5] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [6] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [7] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [8] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [9] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) RADEON(0): TOTO SAYS 00000000fbee0000 (II) RADEON(0): MMIO registers at 0x00000000fbee0000: size 64KB (II) RADEON(0): PCI bus 6 card 0 func 0 (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) (==) RADEON(0): Default visual is TrueColor (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/local/lib/xorg/modules//libvgahw.so (II) Module vgahw: vendor="X.Org Foundation" compiled for 1.6.0, module version = 0.1.0 ABI class: X.Org Video Driver, version 5.0 (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (==) RADEON(0): RGB weight 888 (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) (--) RADEON(0): Chipset: "ATI Radeon X1950" (ChipID = 0x7280) (WW) RADEON(0): R500 support is under development. Please report any issues to xorg-driver-ati@lists.x.org (--) RADEON(0): Linear framebuffer at 0x00000000d0000000 (II) RADEON(0): PCIE card detected (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/local/lib/xorg/modules//libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (II) RADEON(0): initializing int10 (==) RADEON(0): Write-combining range (0xa0000,0x20000) was already clear (==) RADEON(0): Write-combining range (0xc0000,0x40000) was already clear (II) RADEON(0): Primary V_BIOS segment is: 0xc000 (==) RADEON(0): Write-combining range (0x0,0x1000) was already clear (II) RADEON(0): ATOM BIOS detected (II) RADEON(0): ATOM BIOS Rom: SubsystemVendorID: 0x148c SubsystemID: 0x2204 IOBaseAddress: 0xe000 Filename: 64125LAB.SEF BIOS Bootup Message: RV570XT DDR3 256MB 64125LAB.SEF V9.13.1.12 (II) RADEON(0): Framebuffer space used by Firmware (kb): 20 (II) RADEON(0): Start of VRAM area used by Firmware: 0xfffb000 (II) RADEON(0): AtomBIOS requests 20kB of VRAM scratch space (II) RADEON(0): AtomBIOS VRAM scratch base: 0xfffb000 (II) RADEON(0): Cannot get VRAM scratch space. Allocating in main memory instead (II) RADEON(0): Default Engine Clock: 600000 (II) RADEON(0): Default Memory Clock: 700000 (II) RADEON(0): Maximum Pixel ClockPLL Frequency Output: 1100000 (II) RADEON(0): Minimum Pixel ClockPLL Frequency Output: 0 (II) RADEON(0): Maximum Pixel ClockPLL Frequency Input: 13500 (II) RADEON(0): Minimum Pixel ClockPLL Frequency Input: 1000 (II) RADEON(0): Maximum Pixel Clock: 400000 (II) RADEON(0): Reference Clock: 27000 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: Searching for BusID pci:0000:06:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci:0000:06:00.0 (II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.29.0 (==) RADEON(0): Page Flipping disabled on r5xx and newer chips. (II) RADEON(0): Will try to use DMA for Xv image transfers (II) RADEON(0): Generation 2 PCI interface, using max accessible memory (II) RADEON(0): Detected total video RAM=262144K, accessible=262144K (PCI BAR=262144K) (--) RADEON(0): Mapped VideoRAM: 262144 kByte (256 bit DDR SDRAM) (II) RADEON(0): Color tiling enabled by default (II) RADEON(0): Max desktop size set to 2560x1600 (II) RADEON(0): For a larger or smaller max desktop size, add a Virtual line to your xorg.conf (II) RADEON(0): If you are having trouble with 3D, reduce the desktop size by adjusting the Virtual line to your xorg.conf (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Module "ddc" already built-in (II) Loading sub module "i2c" (II) LoadModule: "i2c" (II) Module "i2c" already built-in (II) RADEON(0): ref_freq: 2700, min_out_pll: 64800, max_out_pll: 110000, min_in_pll: 100, max_in_pll: 1350, xclk: 40000, sclk: 600.000000, mclk: 700.000000 (II) RADEON(0): PLL parameters: rf=2700 rd=13 min=64800 max=110000; xclk=40000 (II) RADEON(0): Skipping TV-Out (II) RADEON(0): Skipping Component Video encoder: 0x15 encoder: 0x13 encoder: 0x16 encoder: 0xf (II) RADEON(0): Output DVI-1 using monitor section Monitor0 (II) RADEON(0): I2C bus "DVI-1" initialized. (II) RADEON(0): Output DVI-0 has no monitor section (II) RADEON(0): I2C bus "DVI-0" initialized. (II) RADEON(0): Port0: XRANDR name: DVI-1 Connector: DVI-I CRT2: INTERNAL_KLDSCP_DAC2 DFP1: INTERNAL_KLDSCP_TMDS1 DDC reg: 0x7e50 (II) RADEON(0): Port1: XRANDR name: DVI-0 Connector: DVI-I CRT1: INTERNAL_KLDSCP_DAC1 DFP3: INTERNAL_LVTM1 DDC reg: 0x7e40 (II) RADEON(0): I2C device "DVI-1:E-EDID segment register" registered at address 0x60. (II) RADEON(0): I2C device "DVI-1:ddc2" registered at address 0xA0. (II) RADEON(0): EDID vendor "SAM", prod id 628 (II) RADEON(0): Using hsync ranges from config file (II) RADEON(0): Using vrefresh ranges from config file (II) RADEON(0): Printing DDC gathered Modelines: (II) RADEON(0): Modeline "1440x900"x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1440x900"x0.0 88.75 1440 1488 1520 1600 900 903 909 926 +hsync -vsync (55.5 kHz) (II) RADEON(0): Modeline "1440x900"x0.0 136.75 1440 1536 1688 1936 900 903 909 942 -hsync +vsync (70.6 kHz) (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) RADEON(0): Modeline "1280x960"x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz) (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Output: DVI-1, Detected Monitor Type: 3 (II) RADEON(0): EDID data from the display on output: DVI-1 ---------------------- (II) RADEON(0): Manufacturer: SAM Model: 274 Serial#: 1296380217 (II) RADEON(0): Year: 2007 Week: 28 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Digital Display Input (II) RADEON(0): Max Image Size [cm]: horiz.: 41 vert.: 26 (II) RADEON(0): Gamma: 2.35 (II) RADEON(0): DPMS capabilities: Off (II) RADEON(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.329 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400@70Hz (II) RADEON(0): 640x480@60Hz (II) RADEON(0): 640x480@67Hz (II) RADEON(0): 640x480@72Hz (II) RADEON(0): 640x480@75Hz (II) RADEON(0): 800x600@56Hz (II) RADEON(0): 800x600@60Hz (II) RADEON(0): 800x600@72Hz (II) RADEON(0): 800x600@75Hz (II) RADEON(0): 832x624@75Hz (II) RADEON(0): 1024x768@60Hz (II) RADEON(0): 1024x768@70Hz (II) RADEON(0): 1024x768@75Hz (II) RADEON(0): 1280x1024@75Hz (II) RADEON(0): 1152x870@75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1440 vsize 900 refresh: 60 vid: 149 (II) RADEON(0): #1: hsize: 1440 vsize 900 refresh: 75 vid: 3989 (II) RADEON(0): #2: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #3: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #4: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 106.5 MHz Image Size: 410 x 257 mm (II) RADEON(0): h_active: 1440 h_sync: 1520 h_sync_end 1672 h_blank_end 1904 h_border: 0 (II) RADEON(0): v_active: 900 v_sync: 903 v_sync_end 909 v_blanking: 934 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 140 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: H9XP701904 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2d74023931454d (II) RADEON(0): 1c11010380291a872ade95a3544c9926 (II) RADEON(0): 0f5054bfef809500950f81808140714f (II) RADEON(0): 0101010101019a29a0d0518422305098 (II) RADEON(0): 36009a011100001c000000fd00384b1e (II) RADEON(0): 510e000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 00483958503730313930340a20200062 finished output detect: 0 (II) RADEON(0): I2C device "DVI-0:E-EDID segment register" registered at address 0x60. (II) RADEON(0): I2C device "DVI-0:ddc2" registered at address 0xA0. (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 Dac detection success Unhandled monitor type 0 finished output detect: 1 finished all detect before xf86InitialConfiguration (II) RADEON(0): EDID vendor "SAM", prod id 628 (II) RADEON(0): Using hsync ranges from config file (II) RADEON(0): Using vrefresh ranges from config file (II) RADEON(0): Printing DDC gathered Modelines: (II) RADEON(0): Modeline "1440x900"x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1440x900"x0.0 88.75 1440 1488 1520 1600 900 903 909 926 +hsync -vsync (55.5 kHz) (II) RADEON(0): Modeline "1440x900"x0.0 136.75 1440 1536 1688 1936 900 903 909 942 -hsync +vsync (70.6 kHz) (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) RADEON(0): Modeline "1280x960"x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz) (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Output: DVI-1, Detected Monitor Type: 3 (II) RADEON(0): EDID data from the display on output: DVI-1 ---------------------- (II) RADEON(0): Manufacturer: SAM Model: 274 Serial#: 1296380217 (II) RADEON(0): Year: 2007 Week: 28 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Digital Display Input (II) RADEON(0): Max Image Size [cm]: horiz.: 41 vert.: 26 (II) RADEON(0): Gamma: 2.35 (II) RADEON(0): DPMS capabilities: Off (II) RADEON(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.329 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400@70Hz (II) RADEON(0): 640x480@60Hz (II) RADEON(0): 640x480@67Hz (II) RADEON(0): 640x480@72Hz (II) RADEON(0): 640x480@75Hz (II) RADEON(0): 800x600@56Hz (II) RADEON(0): 800x600@60Hz (II) RADEON(0): 800x600@72Hz (II) RADEON(0): 800x600@75Hz (II) RADEON(0): 832x624@75Hz (II) RADEON(0): 1024x768@60Hz (II) RADEON(0): 1024x768@70Hz (II) RADEON(0): 1024x768@75Hz (II) RADEON(0): 1280x1024@75Hz (II) RADEON(0): 1152x870@75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1440 vsize 900 refresh: 60 vid: 149 (II) RADEON(0): #1: hsize: 1440 vsize 900 refresh: 75 vid: 3989 (II) RADEON(0): #2: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #3: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #4: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 106.5 MHz Image Size: 410 x 257 mm (II) RADEON(0): h_active: 1440 h_sync: 1520 h_sync_end 1672 h_blank_end 1904 h_border: 0 (II) RADEON(0): v_active: 900 v_sync: 903 v_sync_end 909 v_blanking: 934 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 140 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: H9XP701904 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2d74023931454d (II) RADEON(0): 1c11010380291a872ade95a3544c9926 (II) RADEON(0): 0f5054bfef809500950f81808140714f (II) RADEON(0): 0101010101019a29a0d0518422305098 (II) RADEON(0): 36009a011100001c000000fd00384b1e (II) RADEON(0): 510e000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 00483958503730313930340a20200062 (II) RADEON(0): Panel infos found from DDC detailed: 1440x900 (II) RADEON(0): EDID vendor "SAM", prod id 628 (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 Dac detection success Unhandled monitor type 0 (II) RADEON(0): Output DVI-1 connected (II) RADEON(0): Output DVI-0 disconnected (II) RADEON(0): Using exact sizes for initial modes (II) RADEON(0): Output DVI-1 using initial mode 1440x900 after xf86InitialConfiguration (**) RADEON(0): Display dimensions: (410, 260) mm (**) RADEON(0): DPI set to (89, 140) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/local/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (==) RADEON(0): Using gamma correction (1.0, 1.0, 1.0) (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Module "ramdac" already built-in (==) RADEON(0): Using XAA acceleration architecture (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/local/lib/xorg/modules//libxaa.so (II) Module xaa: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.2.1 ABI class: X.Org Video Driver, version 5.0 (==) RADEON(0): Write-combining range (0x0,0x1000) was already clear (!!) RADEON(0): For information on using the multimedia capabilities of this adapter, please see http://gatos.sf.net. (!!) RADEON(0): MergedFB support has been removed and replaced with xrandr 1.2 support (--) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprU) [4] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprU) [5] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprU) [6] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [7] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [8] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [9] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (II) RADEON(0): RADEONScreenInit d0000000 0 0 (==) RADEON(0): Write-combining range (0xa0000,0x10000) was already clear Output DFP1 disable success Blank CRTC 0 success Disable CRTC 0 success Blank CRTC 1 success Disable CRTC 1 success (==) RADEON(0): Using 24 bit depth buffer (II) RADEON(0): RADEONInitMemoryMap() : (II) RADEON(0): mem_size : 0x10000000 (II) RADEON(0): MC_FB_LOCATION : 0xdfffd000 (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 (II) RADEON(0): Depth moves disabled by default (II) RADEON(0): Using 32 MB GART aperture (II) RADEON(0): Using 1 MB for the ring buffer (II) RADEON(0): Using 2 MB for vertex/indirect buffers (II) RADEON(0): Using 29 MB for GART textures (II) RADEON(0): Memory manager initialized to (0,0) (1472,8191) (II) RADEON(0): Reserved area from (0,1440) to (1472,1442) (II) RADEON(0): Largest offscreen area available: 1472 x 6749 (II) RADEON(0): Will use front buffer at offset 0x0 (II) RADEON(0): Will use back buffer at offset 0x23c2000 (II) RADEON(0): Will use depth buffer at offset 0x2bd8000 (II) RADEON(0): Will use 32 kb for PCI GART table at offset 0xfff8000 (II) RADEON(0): Will use 208896 kb for textures at offset 0x33ee000 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: Searching for BusID pci:0000:06:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci:0000:06:00.0 (II) [drm] DRM interface version 1.2 (II) [drm] DRM open master succeeded. (II) RADEON(0): [drm] Using the DRM lock SAREA also for drawables. (II) RADEON(0): [drm] framebuffer handle = 0xd0000000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle = 0x1 (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [pci] 32768 kB allocated with handle 0x7a2cb000 (II) RADEON(0): [pci] ring handle = 0x7a2cb000 (II) RADEON(0): [pci] Ring mapped at 0x812e00000 (II) RADEON(0): [pci] Ring contents 0x00000000 (II) RADEON(0): [pci] ring read ptr handle = 0x7a3cc000 (II) RADEON(0): [pci] Ring read ptr mapped at 0x80076b000 (II) RADEON(0): [pci] Ring read ptr contents 0x00000000 (II) RADEON(0): [pci] vertex/indirect buffers handle = 0x7a3cd000 (II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812f01000 (II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000 (II) RADEON(0): [pci] GART texture map handle = 0x7a5cd000 (II) RADEON(0): [pci] GART Texture map mapped at 0x8131cd000 (II) RADEON(0): [drm] register handle = 0xfbee0000 (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0xdfffd000 0xfffff000 (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 (==) RADEON(0): Backing store disabled (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] dma control initialized, using IRQ 16 (II) RADEON(0): [drm] Initialized kernel GART heap manager, 29884416 (WW) RADEON(0): DRI init changed memory map, adjusting ... (WW) RADEON(0): MC_FB_LOCATION was: 0xdfffd000 is: 0xdfffd000 (WW) RADEON(0): MC_AGP_LOCATION was: 0x003f0000 is: 0xffffffc0 (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0xdfffd000 0xdfffd000 (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (II) RADEON(0): Direct rendering enabled (II) RADEON(0): XAA Render acceleration unsupported on Radeon 9500/9700 and newer. Please use EXA instead. (II) RADEON(0): Render acceleration disabled (II) RADEON(0): num quad-pipes is 3 (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Scanline Image Writes Setting up tile and stipple cache: 32 128x128 slots 32 256x256 slots 16 512x512 slots (II) RADEON(0): Acceleration enabled (**) Option "dpms" (**) RADEON(0): DPMS enabled (==) RADEON(0): Silken mouse enabled (II) RADEON(0): Will use 32 kb for hardware cursor 0 at offset 0x00819000 (II) RADEON(0): Will use 32 kb for hardware cursor 1 at offset 0x0081f000 (II) RADEON(0): Largest offscreen area available: 1472 x 6741 (II) RADEON(0): Set up textured video Output DFP1 disable success Blank CRTC 0 success Disable CRTC 0 success Blank CRTC 1 success Disable CRTC 1 success Output DFP1 disable success Mode 1440x900 - 1904 934 6 (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0xdfffd000 0xdfffd000 (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 freq: 106500000 best_freq: 106500000 best_feedback_div: 71 best_ref_div: 2 best_post_div: 9 (II) RADEON(0): crtc(0) Clock: mode 106500, PLL 106500 (II) RADEON(0): crtc(0) PLL : refdiv 2, fbdiv 0x47(71), pdiv 9 Set CRTC 0 PLL success Set CRTC Timing success Set CRTC 0 Overscan success Not using RMX scaler 0 setup success Set CRTC 0 Source success crtc 0 YUV disable setup success Output digital setup success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Blank CRTC 1 success Disable CRTC 1 success (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled message. Lock CRTC 0 success Unlock CRTC 0 success (--) RandR disabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so (II) GLX: Initialized DRISWRAST GL provider for screen 0 (II) RADEON(0): Setting screen physical size to 410 x 257 (**) Option "Protocol" "auto" (**) Mouse0: Device: "/dev/sysmouse" (**) Mouse0: Protocol: "auto" (**) Option "CorePointer" (**) Mouse0: always reports core events (**) Option "Device" "/dev/sysmouse" (==) Mouse0: Emulate3Buttons, Emulate3Timeout: 50 (**) Option "ZAxisMapping" "4 5 6 7" (**) Mouse0: ZAxisMapping: buttons 4, 5, 6 and 7 (**) Mouse0: Buttons: 11 (**) Mouse0: Sensitivity: 1 (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) (**) Mouse0: (accel) keeping acceleration scheme 1 (**) Mouse0: (accel) filter chain progression: 2.00 (**) Mouse0: (accel) filter stage 0: 20.00 ms (**) Mouse0: (accel) set acceleration profile 0 (II) Mouse0: SetupAuto: hw.iftype is 4, hw.model is 0 (II) Mouse0: SetupAuto: protocol is SysMouse (**) Option "CoreKeyboard" (**) Keyboard0: always reports core events (**) Option "Protocol" "standard" (**) Keyboard0: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) Keyboard0: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) Keyboard0: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) Keyboard0: XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) Keyboard0: CustomKeycodes disabled (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD) Output DFP1 disable success Blank CRTC 0 success Disable CRTC 0 success Blank CRTC 1 success Disable CRTC 1 success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 disable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Output DFP1 disable success Blank CRTC 0 success Disable CRTC 0 success Blank CRTC 1 success Disable CRTC 1 success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 disable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Output DFP1 disable success Blank CRTC 0 success Disable CRTC 0 success Blank CRTC 1 success Disable CRTC 1 success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 disable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Output DFP1 disable success Blank CRTC 0 success Disable CRTC 0 success Blank CRTC 1 success Disable CRTC 1 success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Output DFP1 disable success Blank CRTC 0 success Disable CRTC 0 success Blank CRTC 1 success Disable CRTC 1 success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Output DFP1 disable success Blank CRTC 0 success Disable CRTC 0 success Blank CRTC 1 success Disable CRTC 1 success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 disable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 disable success /var/log/messages: Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=30 s=0 e=3288 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=30 s=0x0 e=0xcd8 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941502 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=31 s=0 e=1684 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=31 s=0x0 e=0x694 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0x20006444, nr=0x44, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_idle] Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_do_cp_idle] Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0x20006444, nr=0x44, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_idle] Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_do_cp_idle] Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941503 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=0 s=0 e=13260 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=0 s=0x0 e=0x33cc Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941504 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=1 s=0 e=6084 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=1 s=0x0 e=0x17c4 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941505 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=2 s=0 e=1840 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=2 s=0x0 e=0x730 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941506 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=3 s=0 e=5152 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=3 s=0x0 e=0x1420 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941506 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=4 s=0 e=3288 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=4 s=0x0 e=0xcd8 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941508 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=5 s=0 e=3236 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=5 s=0x0 e=0xca4 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941509 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=6 s=0 e=1684 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=6 s=0x0 e=0x694 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941510 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=7 s=0 e=1736 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=7 s=0x0 e=0x6c8 From gary.jennejohn at freenet.de Sat Apr 11 05:06:49 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sat Apr 11 05:06:56 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <20090411101559.GC83697@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090410211307.GA83697@logik.internal.network> <3a142e750904101730k53b7fbabn6e801ac36f1182e0@mail.gmail.com> <20090411101559.GC83697@logik.internal.network> Message-ID: <20090411140643.35cc82ae@ernst.jennejohn.org> On Sat, 11 Apr 2009 11:15:59 +0100 xorquewasp@googlemail.com wrote: > On 2009-04-11 02:30:40, Paul B. Mahol wrote: > > > > If it locks under X11 then use debug.debugger_on_panic=0 sysctl. > > Not doing this will increase drasticaly chances of locking whole system > > and not providing any debug data. > > I don't seem to have that sysctl. > > You sure that's the correct name? > It's definitely in 8-current. Seems to be set to 0 as default. --- Gary Jennejohn From to.my.trociny at gmail.com Sat Apr 11 06:38:32 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Sat Apr 11 06:39:04 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <20090411101559.GC83697@logik.internal.network> (xorquewasp@googlemail.com's message of "Sat\, 11 Apr 2009 11\:15\:59 +0100") References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090410211307.GA83697@logik.internal.network> <3a142e750904101730k53b7fbabn6e801ac36f1182e0@mail.gmail.com> <20090411101559.GC83697@logik.internal.network> Message-ID: <86zlen9vw2.fsf@kopusha.onet> On Sat, 11 Apr 2009 11:15:59 +0100 xorquewasp@googlemail.com wrote: x> On 2009-04-11 02:30:40, Paul B. Mahol wrote: >> >> If it locks under X11 then use debug.debugger_on_panic=0 sysctl. >> Not doing this will increase drasticaly chances of locking whole system >> and not providing any debug data. x> I don't seem to have that sysctl. You will see this sysctl only if you build your kernel with ddb(4) support. If you are interested in providing useful information about your freezes, please read the following: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html You need to build your kernel with options described in http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html and http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html As you run X, you need to have debug.debugger_on_panic=0 set (as Paul has suggested). Otherwise ddb would enter on panic but you wouldn't be able to access it due to X. After panic you will be able to get useful information from generated core dump using kgdb. Another option is to set debug.debugger_on_panic=1 but also set some ddb script that will run when the kernel debugger is entered as a result of a panic. This script will enable output capture, dump some useful debugging info to capture buffer, and then force a kernel dump to be written out followed by a reboot. E.g. running something like this will do the trick: ddb script 'kdb.enter.panic=capture on; show pcpu; show allpcpu; bt; ps; show locks; show alllocks; show lockedvnods; alltrace; call doadump; reset' After reboot you can extract captured information from the capture buffer information using the command: ddb capture -M /var/crash/vmcore.X print > ddb.out You need to increase the value of debug.ddb.capture.bufsize sysctl variable to make sure all ddb output will be captured. You can read more about this in ddb(4), ddb(8), textdump(4). -- Mikolaj Golub From rwatson at FreeBSD.org Sat Apr 11 08:21:53 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Apr 11 08:24:57 2009 Subject: FreeBSD memguard + spinlocks In-Reply-To: References: Message-ID: On Sat, 11 Apr 2009, Andrew Brampton wrote: > I'm having a problem with memguard(9) on FreeBSD 7.1 but before I ask about > that I just need to check my facts about malloc. > > When in interrupt context malloc must be called with M_NOWAIT, this is > because I can't sleep inside a interrupt. Now when I hold a spinlock > (MTX_SPIN) I am also not allowed to sleep or obtain a sleepable mutex (such > as MTX_DEF). So I assume while holding a spin lock any mallocs I do must > have the M_NOWAIT flag? This was not clear from the manual pages, but at > least makes sense to me. > > So my problem with memguard stems from the fact that I am locking a > spinlock, and then I'm calling malloc with M_NOWAIT. But inside > memguard_alloc a MTX_DEF is acquired causing WITNESS to panic. > > So I think fundamental memguard is flawed and should be using MTX_SPIN > instead of MTX_DEF otherwise it can't be called from inside a interrupt or > when a spin lock is held. But maybe I'm missing something? > > Also on a related note, I see that MTX_SPIN disables interrupts, making it a > rather "heavy" spinlock. Is there a lighter spin lock that literally just > spins? I read that MTX_DEF are far quicker to acquire , but surely a light > spinlock would be easier to acquire than sleeping? > > I think for the moment I will fix my code by not using a MTX_SPIN (since the > code is not in a interrupt), however, I think memguard should change its > lock. Your understanding is mostly right. The missing bit is this: there are two kinds of interrupt contexts -- fast/filter interrupt handlers, which borrow the stack and execution context of the kernel thread they preempt, and interrupt threads, which get their own complete thread context. Fast interrupt handlers are allowed unlock to acquire spinlocks so as to avoid deadlock because of the borrowed context. This means they can't perform any sort of sleep, or acquire any locks that might sleep, since the thread they've preempted may hold conflicting locks, or be the one that would have woken up the sleep that the handler performed. Almost no code will run in fast handlers -- perhaps checking some device registers, doing work on a lockless or spinlock-protected queue, and waking up a worker thread. This is why, BTW, spin locks disable interrupt: they need to control preemption by other interrupt handlers to avoid deadlock, but they are not intended for use except when either in the scheduler, in a few related IPI contexts, or when synchronizing between normal kernel code and a fast handler. Full interrupt thread contexts are permitted to perform short lock sleeps, such as those performed when contending default mutexes, rwlocks, and rmlocks. They are permitted to invoke kernel services such as malloc(9), UMA(9), the network stack, etc, as long as they use M_NOWAIT and don't invoke msleep(9) or similar unbounded sleeps -- again to avoid the possibility of deadlocks, since you don't want an interrupt thread sleeping waiting for an event that only it can satisfy. So the first question, really, is whether you are or mean to be using fast/filter interrupt handler. Device drivers will never call memory allocation, free, etc, from there, but will defer it to an ithread using the filter mechanism in 8.x, or to a task queue or other worker in 7.x and earlier. If you're using a regular INTR_MPSAFE ithread, you should be able to use only default mutexes (a single atomic operation if uncontended) without disabling interrupts, etc. Robert N M Watson Computer Laboratory University of Cambridge From rnoland at FreeBSD.org Sat Apr 11 12:12:14 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Sat Apr 11 12:12:23 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <20090411102300.GD83697@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090411102300.GD83697@logik.internal.network> Message-ID: <1239477075.1932.5.camel@balrog.2hip.net> On Sat, 2009-04-11 at 11:23 +0100, xorquewasp@googlemail.com wrote: > The machine ran for hours, apparently. I ended up going to > bed and leaving it running. Woke up to find it on display > sleep, frozen. Are you running the 7.2-PRE or -STABLE? There are a few relevant fixes in -STABLE that didn't make it into the pre-release. robert. > It didn't panic, apparently. > > I've included Xorg.0.log and the last few lines of /var/log/messages > but I don't believe they show anything very interesting. > > I should point out that this card is the dual-DVI version. I'm not > sure if that's relevant (I think it's just less common). I'm only > using one screen, currently. > > /var/log/Xorg.0.log: > > X.Org X Server 1.6.0 > Release Date: 2009-2-25 > X Protocol Version 11, Revision 0 > Build Operating System: FreeBSD 7.2-PRERELEASE amd64 > Current Operating System: FreeBSD viper.internal.network 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Fri Apr 10 00:09:48 BST 2009 root@viper.internal.network:/usr/obj/usr/src/sys/GENERIC amd64 > Build Date: 11 April 2009 04:34:30AM > > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Markers: (--) probed, (**) from config file, (==) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (==) Log file: "/var/log/Xorg.0.log", Time: Sat Apr 11 06:16:46 2009 > (==) Using config file: "/etc/X11/xorg.conf" > (==) ServerLayout "X.org Configured" > (**) |-->Screen "Screen0" (0) > (**) | |-->Monitor "Monitor0" > (**) | |-->Device "Card0" > (**) |-->Input Device "Mouse0" > (**) |-->Input Device "Keyboard0" > (==) Not automatically adding devices > (==) Not automatically enabling devices > (WW) The directory "/usr/local/lib/X11/fonts/TTF/" does not exist. > Entry deleted from font path. > (WW) The directory "/usr/local/lib/X11/fonts/OTF" does not exist. > Entry deleted from font path. > (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. > Entry deleted from font path. > (WW) The directory "/usr/local/lib/X11/fonts/TTF/" does not exist. > Entry deleted from font path. > (WW) The directory "/usr/local/lib/X11/fonts/OTF" does not exist. > Entry deleted from font path. > (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. > Entry deleted from font path. > (**) FontPath set to: > /usr/local/lib/X11/fonts/misc/, > /usr/local/lib/X11/fonts/100dpi/, > /usr/local/lib/X11/fonts/75dpi/, > /usr/local/lib/X11/fonts/misc/, > /usr/local/lib/X11/fonts/100dpi/, > /usr/local/lib/X11/fonts/75dpi/, > built-ins > (**) ModulePath set to "/usr/local/lib/xorg/modules" > (II) Loader magic: 0xd20 > (II) Module ABI versions: > X.Org ANSI C Emulation: 0.4 > X.Org Video Driver: 5.0 > X.Org XInput driver : 4.0 > X.Org Server Extension : 2.0 > (II) Loader running on freebsd > (--) Using syscons driver with X support (version 134217730.0) > (--) using VT number 9 > > (--) PCI:*(0@6:0:0) ATI Technologies Inc RV570 [Radeon X1950 Pro] rev 154, Mem @ 0xd0000000/268435456, 0xfbee0000/65536, I/O @ 0x0000e000/256, BIOS @ 0x????????/65536 > (--) PCI: (0@6:0:1) ATI Technologies Inc RV570 [Radeon X1950 Pro] (secondary) rev 154, Mem @ 0xfbef0000/65536 > (II) System resource ranges: > [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. > (II) "dbe" will be loaded. This was enabled by default and also specified in the config file. > (II) "glx" will be loaded. This was enabled by default and also specified in the config file. > (II) "record" will be loaded. This was enabled by default and also specified in the config file. > (II) "dri" will be loaded. This was enabled by default and also specified in the config file. > (II) "dri2" will be loaded. This was enabled by default and also specified in the config file. > (II) LoadModule: "extmod" > (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so > (II) Module extmod: vendor="X.Org Foundation" > compiled for 1.6.0, module version = 1.0.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension MIT-SCREEN-SAVER > (II) Loading extension XFree86-VidModeExtension > (II) Loading extension XFree86-DGA > (II) Loading extension DPMS > (II) Loading extension XVideo > (II) Loading extension XVideo-MotionCompensation > (II) Loading extension X-Resource > (II) LoadModule: "record" > (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so > (II) Module record: vendor="X.Org Foundation" > compiled for 1.6.0, module version = 1.13.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension RECORD > (II) LoadModule: "dbe" > (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so > (II) Module dbe: vendor="X.Org Foundation" > compiled for 1.6.0, module version = 1.0.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension DOUBLE-BUFFER > (II) LoadModule: "glx" > (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so > (II) Module glx: vendor="X.Org Foundation" > compiled for 1.6.0, module version = 1.0.0 > ABI class: X.Org Server Extension, version 2.0 > (==) AIGLX disabled > (II) Loading extension GLX > (II) LoadModule: "dri" > (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so > (II) Module dri: vendor="X.Org Foundation" > compiled for 1.6.0, module version = 1.0.0 > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension XFree86-DRI > (II) LoadModule: "dri2" > (II) Loading /usr/local/lib/xorg/modules/extensions//libdri2.so > (II) Module dri2: vendor="X.Org Foundation" > compiled for 1.6.0, module version = 1.0.0 > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension DRI2 > (II) LoadModule: "radeon" > (II) Loading /usr/local/lib/xorg/modules/drivers//radeon_drv.so > (II) Module radeon: vendor="X.Org Foundation" > compiled for 1.6.0, module version = 6.12.2 > Module class: X.Org Video Driver > ABI class: X.Org Video Driver, version 5.0 > (II) LoadModule: "mouse" > (II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so > (II) Module mouse: vendor="X.Org Foundation" > compiled for 1.6.0, module version = 1.4.0 > Module class: X.Org XInput Driver > ABI class: X.Org XInput driver, version 4.0 > (II) LoadModule: "kbd" > (II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so > (II) Module kbd: vendor="X.Org Foundation" > compiled for 1.6.0, module version = 1.3.2 > Module class: X.Org XInput Driver > ABI class: X.Org XInput driver, version 4.0 > (II) RADEON: Driver for ATI Radeon chipsets: > ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI FireMV 2400 (PCI), > ATI Radeon Mobility X300 (M24) 3152 (PCIE), > ATI FireGL M24 GL 3154 (PCIE), ATI Radeon X600 (RV380) 3E50 (PCIE), > ATI FireGL V3200 (RV380) 3E54 (PCIE), ATI Radeon IGP320 (A3) 4136, > ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon 9500 AD (AGP), > ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP), > ATI FireGL Z1 AG (AGP), ATI Radeon 9800SE AH (AGP), > ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP), > ATI FireGL X2 AK (AGP), ATI Radeon 9600 AP (AGP), > ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP), > ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP), ATI Radeon 9650, > ATI FireGL RV360 AV (AGP), ATI Radeon 7000 IGP (A4+) 4237, > ATI Radeon 8500 AIW BB (AGP), ATI Radeon 8500 AIW BC (AGP), > ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330M/340M/350M (U2) 4337, > ATI Radeon Mobility 7000 IGP 4437, ATI Radeon 9000/PRO If (AGP/PCI), > ATI Radeon 9000 Ig (AGP/PCI), ATI Radeon X800 (R420) JH (AGP), > ATI Radeon X800PRO (R420) JI (AGP), > ATI Radeon X800SE (R420) JJ (AGP), ATI Radeon X800 (R420) JK (AGP), > ATI Radeon X800 (R420) JL (AGP), ATI FireGL X3 (R420) JM (AGP), > ATI Radeon Mobility 9800 (M18) JN (AGP), > ATI Radeon X800 SE (R420) (AGP), ATI Radeon X800XT (R420) JP (AGP), > ATI Radeon X850 XT (R480) (AGP), ATI Radeon X850 SE (R480) (AGP), > ATI Radeon X850 PRO (R480) (AGP), ATI Radeon X850 XT PE (R480) (AGP), > ATI Radeon Mobility M7 LW (AGP), > ATI Mobility FireGL 7800 M7 LX (AGP), > ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP), > ATI FireGL Mobility 9000 (M9) Ld (AGP), > ATI Radeon Mobility 9000 (M9) Lf (AGP), > ATI Radeon Mobility 9000 (M9) Lg (AGP), ATI Radeon 9700 Pro ND (AGP), > ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9600TX NF (AGP), > ATI FireGL X1 NG (AGP), ATI Radeon 9800PRO NH (AGP), > ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP), > ATI Radeon 9800XT NJ (AGP), > ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP), > ATI Radeon Mobility 9600 (M10) NQ (AGP), > ATI Radeon Mobility 9600 (M11) NR (AGP), > ATI Radeon Mobility 9600 (M10) NS (AGP), > ATI FireGL Mobility T2 (M10) NT (AGP), > ATI FireGL Mobility T2e (M11) NV (AGP), ATI Radeon QD (AGP), > ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), > ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP), > ATI Radeon 9100 QM (AGP), ATI Radeon 7500 QW (AGP/PCI), > ATI Radeon 7500 QX (AGP/PCI), ATI Radeon VE/7000 QY (AGP/PCI), > ATI Radeon VE/7000 QZ (AGP/PCI), ATI ES1000 515E (PCI), > ATI Radeon Mobility X300 (M22) 5460 (PCIE), > ATI Radeon Mobility X600 SE (M24C) 5462 (PCIE), > ATI FireGL M22 GL 5464 (PCIE), ATI Radeon X800 (R423) UH (PCIE), > ATI Radeon X800PRO (R423) UI (PCIE), > ATI Radeon X800LE (R423) UJ (PCIE), > ATI Radeon X800SE (R423) UK (PCIE), > ATI Radeon X800 XTP (R430) (PCIE), ATI Radeon X800 XL (R430) (PCIE), > ATI Radeon X800 SE (R430) (PCIE), ATI Radeon X800 (R430) (PCIE), > ATI FireGL V7100 (R423) (PCIE), ATI FireGL V5100 (R423) UQ (PCIE), > ATI FireGL unknown (R423) UR (PCIE), > ATI FireGL unknown (R423) UT (PCIE), > ATI Mobility FireGL V5000 (M26) (PCIE), > ATI Mobility FireGL V5000 (M26) (PCIE), > ATI Mobility Radeon X700 XL (M26) (PCIE), > ATI Mobility Radeon X700 (M26) (PCIE), > ATI Mobility Radeon X700 (M26) (PCIE), > ATI Radeon X550XTX 5657 (PCIE), ATI Radeon 9100 IGP (A5) 5834, > ATI Radeon Mobility 9100 IGP (U3) 5835, > ATI Radeon XPRESS 200 5954 (PCIE), > ATI Radeon XPRESS 200M 5955 (PCIE), ATI Radeon 9250 5960 (AGP), > ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP), > ATI Radeon 9200SE 5964 (AGP), ATI FireMV 2200 (PCI), > ATI ES1000 5969 (PCI), ATI Radeon XPRESS 200 5974 (PCIE), > ATI Radeon XPRESS 200M 5975 (PCIE), > ATI Radeon XPRESS 200 5A41 (PCIE), > ATI Radeon XPRESS 200M 5A42 (PCIE), > ATI Radeon XPRESS 200 5A61 (PCIE), > ATI Radeon XPRESS 200M 5A62 (PCIE), > ATI Radeon X300 (RV370) 5B60 (PCIE), > ATI Radeon X600 (RV370) 5B62 (PCIE), > ATI Radeon X550 (RV370) 5B63 (PCIE), > ATI FireGL V3100 (RV370) 5B64 (PCIE), > ATI FireMV 2200 PCIE (RV370) 5B65 (PCIE), > ATI Radeon Mobility 9200 (M9+) 5C61 (AGP), > ATI Radeon Mobility 9200 (M9+) 5C63 (AGP), > ATI Mobility Radeon X800 XT (M28) (PCIE), > ATI Mobility FireGL V5100 (M28) (PCIE), > ATI Mobility Radeon X800 (M28) (PCIE), ATI Radeon X850 5D4C (PCIE), > ATI Radeon X850 XT PE (R480) (PCIE), > ATI Radeon X850 SE (R480) (PCIE), ATI Radeon X850 PRO (R480) (PCIE), > ATI unknown Radeon / FireGL (R480) 5D50 (PCIE), > ATI Radeon X850 XT (R480) (PCIE), > ATI Radeon X800XT (R423) 5D57 (PCIE), > ATI FireGL V5000 (RV410) (PCIE), ATI Radeon X700 XT (RV410) (PCIE), > ATI Radeon X700 PRO (RV410) (PCIE), > ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X700 (RV410) (PCIE), > ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X1800, > ATI Mobility Radeon X1800 XT, ATI Mobility Radeon X1800, > ATI Mobility FireGL V7200, ATI FireGL V7200, ATI FireGL V5300, > ATI Mobility FireGL V7100, ATI Radeon X1800, ATI Radeon X1800, > ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, > ATI FireGL V7300, ATI FireGL V7350, ATI Radeon X1600, ATI RV505, > ATI Radeon X1300/X1550, ATI Radeon X1550, ATI M54-GL, > ATI Mobility Radeon X1400, ATI Radeon X1300/X1550, > ATI Radeon X1550 64-bit, ATI Mobility Radeon X1300, > ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, > ATI Mobility Radeon X1300, ATI Radeon X1300, ATI Radeon X1300, > ATI RV505, ATI RV505, ATI FireGL V3300, ATI FireGL V3350, > ATI Radeon X1300, ATI Radeon X1550 64-bit, ATI Radeon X1300/X1550, > ATI Radeon X1600, ATI Radeon X1300/X1550, ATI Mobility Radeon X1450, > ATI Radeon X1300/X1550, ATI Mobility Radeon X2300, > ATI Mobility Radeon X2300, ATI Mobility Radeon X1350, > ATI Mobility Radeon X1350, ATI Mobility Radeon X1450, > ATI Radeon X1300, ATI Radeon X1550, ATI Mobility Radeon X1350, > ATI FireMV 2250, ATI Radeon X1550 64-bit, ATI Radeon X1600, > ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1600, > ATI Mobility FireGL V5200, ATI Mobility Radeon X1600, > ATI Radeon X1650, ATI Radeon X1650, ATI Radeon X1600, > ATI Radeon X1300 XT/X1600 Pro, ATI FireGL V3400, > ATI Mobility FireGL V5250, ATI Mobility Radeon X1700, > ATI Mobility Radeon X1700 XT, ATI FireGL V5200, > ATI Mobility Radeon X1700, ATI Radeon X2300HD, > ATI Mobility Radeon HD 2300, ATI Mobility Radeon HD 2300, > ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1950, > ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, > ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, > ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, > ATI AMD Stream Processor, ATI Radeon X1900, ATI Radeon X1950, > ATI RV560, ATI RV560, ATI Mobility Radeon X1900, ATI RV560, > ATI Radeon X1950 GT, ATI RV570, ATI RV570, ATI FireGL V7400, > ATI RV560, ATI Radeon X1650, ATI Radeon X1650, ATI RV560, > ATI Radeon 9100 PRO IGP 7834, ATI Radeon Mobility 9200 IGP 7835, > ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, > ATI Radeon X1200, ATI Radeon X1200, ATI RS740, ATI RS740M, ATI RS740, > ATI RS740M, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT, > ATI Radeon HD 2900 XT, ATI Radeon HD 2900 Pro, ATI Radeon HD 2900 GT, > ATI FireGL V8650, ATI FireGL V8600, ATI FireGL V7600, > ATI Radeon 4800 Series, ATI Radeon HD 4870 x2, > ATI Radeon 4800 Series, ATI FirePro V8750 (FireGL), > ATI FirePro V7760 (FireGL), ATI Mobility RADEON HD 4850, > ATI Mobility RADEON HD 4850 X2, ATI Radeon 4800 Series, > ATI FirePro RV770, AMD FireStream 9270, AMD FireStream 9250, > ATI FirePro V8700 (FireGL), ATI Mobility RADEON HD 4870, > ATI Mobility RADEON M98, ATI Radeon 4800 Series, > ATI Radeon 4800 Series, ATI FirePro M7750, ATI M98, ATI M98, ATI M98, > ATI Radeon RV730 (AGP), ATI FirePro M5750, ATI Radeon RV730 (AGP), > ATI RV730XT [Radeon HD 4670], ATI RADEON E4600, > ATI RV730 PRO [Radeon HD 4650], ATI FirePro V7750 (FireGL), > ATI FirePro V5700 (FireGL), ATI FirePro V3750 (FireGL), ATI RV610, > ATI Radeon HD 2400 XT, ATI Radeon HD 2400 Pro, > ATI Radeon HD 2400 PRO AGP, ATI FireGL V4000, ATI RV610, > ATI Radeon HD 2350, ATI Mobility Radeon HD 2400 XT, > ATI Mobility Radeon HD 2400, ATI RADEON E2400, ATI RV610, > ATI FireMV 2260, ATI RV670, ATI Radeon HD3870, > ATI Mobility Radeon HD 3850, ATI Radeon HD3850, > ATI Mobility Radeon HD 3850 X2, ATI RV670, > ATI Mobility Radeon HD 3870, ATI Mobility Radeon HD 3870 X2, > ATI Radeon HD3870 X2, ATI FireGL V7700, ATI Radeon HD3850, > ATI Radeon HD3690, AMD Firestream 9170, ATI Radeon HD 4550, > ATI Radeon RV710, ATI Radeon RV710, ATI Radeon HD 4350, > ATI Mobility Radeon 4300 Series, ATI Mobility Radeon 4500 Series, > ATI Mobility Radeon 4500 Series, ATI RV630, > ATI Mobility Radeon HD 2600, ATI Mobility Radeon HD 2600 XT, > ATI Radeon HD 2600 XT AGP, ATI Radeon HD 2600 Pro AGP, > ATI Radeon HD 2600 XT, ATI Radeon HD 2600 Pro, ATI Gemini RV630, > ATI Gemini Mobility Radeon HD 2600 XT, ATI FireGL V5600, > ATI FireGL V3600, ATI Radeon HD 2600 LE, > ATI Mobility FireGL Graphics Processor, ATI Radeon RV710, > ATI Radeon HD 3470, ATI Mobility Radeon HD 3430, > ATI Mobility Radeon HD 3400 Series, ATI Radeon HD 3450, > ATI Radeon HD 3450, ATI Radeon HD 3430, ATI Radeon HD 3450, > ATI FirePro V3700, ATI FireMV 2450, ATI FireMV 2260, ATI FireMV 2260, > ATI Radeon HD 3600 Series, ATI Radeon HD 3650 AGP, > ATI Radeon HD 3600 PRO, ATI Radeon HD 3600 XT, > ATI Radeon HD 3600 PRO, ATI Mobility Radeon HD 3650, > ATI Mobility Radeon HD 3670, ATI Mobility FireGL V5700, > ATI Mobility FireGL V5725, ATI Radeon HD 3200 Graphics, > ATI Radeon 3100 Graphics, ATI Radeon HD 3200 Graphics, > ATI Radeon 3100 Graphics, ATI Radeon HD 3300 Graphics, > ATI Radeon HD 3200 Graphics, ATI Radeon 3000 Graphics, > ATI Radeon HD Graphics, ATI Radeon Graphics, > ATI Mobility Radeon HD Graphics, ATI Mobility Radeon Graphics, > ATI Radeon Graphics > (II) Primary Device is: PCI 06@00:00:0 > (II) resource ranges after xf86ClaimFixedResources() call: > [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > (II) resource ranges after probing: > [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [3] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] > [4] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] > [5] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] > [6] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [7] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > [8] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] > [9] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] > (II) Setting vga for screen 0. > (II) RADEON(0): TOTO SAYS 00000000fbee0000 > (II) RADEON(0): MMIO registers at 0x00000000fbee0000: size 64KB > (II) RADEON(0): PCI bus 6 card 0 func 0 > (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 > (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) > (==) RADEON(0): Default visual is TrueColor > (II) Loading sub module "vgahw" > (II) LoadModule: "vgahw" > (II) Loading /usr/local/lib/xorg/modules//libvgahw.so > (II) Module vgahw: vendor="X.Org Foundation" > compiled for 1.6.0, module version = 0.1.0 > ABI class: X.Org Video Driver, version 5.0 > (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 > (==) RADEON(0): RGB weight 888 > (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) > (--) RADEON(0): Chipset: "ATI Radeon X1950" (ChipID = 0x7280) > (WW) RADEON(0): R500 support is under development. Please report any issues to xorg-driver-ati@lists.x.org > (--) RADEON(0): Linear framebuffer at 0x00000000d0000000 > (II) RADEON(0): PCIE card detected > (II) Loading sub module "int10" > (II) LoadModule: "int10" > (II) Loading /usr/local/lib/xorg/modules//libint10.so > (II) Module int10: vendor="X.Org Foundation" > compiled for 1.6.0, module version = 1.0.0 > ABI class: X.Org Video Driver, version 5.0 > (II) RADEON(0): initializing int10 > (==) RADEON(0): Write-combining range (0xa0000,0x20000) was already clear > (==) RADEON(0): Write-combining range (0xc0000,0x40000) was already clear > (II) RADEON(0): Primary V_BIOS segment is: 0xc000 > (==) RADEON(0): Write-combining range (0x0,0x1000) was already clear > (II) RADEON(0): ATOM BIOS detected > (II) RADEON(0): ATOM BIOS Rom: > SubsystemVendorID: 0x148c SubsystemID: 0x2204 > IOBaseAddress: 0xe000 > Filename: 64125LAB.SEF > BIOS Bootup Message: > RV570XT DDR3 256MB 64125LAB.SEF V9.13.1.12 > > (II) RADEON(0): Framebuffer space used by Firmware (kb): 20 > (II) RADEON(0): Start of VRAM area used by Firmware: 0xfffb000 > (II) RADEON(0): AtomBIOS requests 20kB of VRAM scratch space > (II) RADEON(0): AtomBIOS VRAM scratch base: 0xfffb000 > (II) RADEON(0): Cannot get VRAM scratch space. Allocating in main memory instead > (II) RADEON(0): Default Engine Clock: 600000 > (II) RADEON(0): Default Memory Clock: 700000 > (II) RADEON(0): Maximum Pixel ClockPLL Frequency Output: 1100000 > (II) RADEON(0): Minimum Pixel ClockPLL Frequency Output: 0 > (II) RADEON(0): Maximum Pixel ClockPLL Frequency Input: 13500 > (II) RADEON(0): Minimum Pixel ClockPLL Frequency Input: 1000 > (II) RADEON(0): Maximum Pixel Clock: 400000 > (II) RADEON(0): Reference Clock: 27000 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: Searching for BusID pci:0000:06:00.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: drmOpenMinor returns 10 > drmOpenByBusid: drmGetBusid reports pci:0000:06:00.0 > (II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.29.0 > (==) RADEON(0): Page Flipping disabled on r5xx and newer chips. > > (II) RADEON(0): Will try to use DMA for Xv image transfers > (II) RADEON(0): Generation 2 PCI interface, using max accessible memory > (II) RADEON(0): Detected total video RAM=262144K, accessible=262144K (PCI BAR=262144K) > (--) RADEON(0): Mapped VideoRAM: 262144 kByte (256 bit DDR SDRAM) > (II) RADEON(0): Color tiling enabled by default > (II) RADEON(0): Max desktop size set to 2560x1600 > (II) RADEON(0): For a larger or smaller max desktop size, add a Virtual line to your xorg.conf > (II) RADEON(0): If you are having trouble with 3D, reduce the desktop size by adjusting the Virtual line to your xorg.conf > (II) Loading sub module "ddc" > (II) LoadModule: "ddc" > (II) Module "ddc" already built-in > (II) Loading sub module "i2c" > (II) LoadModule: "i2c" > (II) Module "i2c" already built-in > (II) RADEON(0): ref_freq: 2700, min_out_pll: 64800, max_out_pll: 110000, min_in_pll: 100, max_in_pll: 1350, xclk: 40000, sclk: 600.000000, mclk: 700.000000 > (II) RADEON(0): PLL parameters: rf=2700 rd=13 min=64800 max=110000; xclk=40000 > (II) RADEON(0): Skipping TV-Out > (II) RADEON(0): Skipping Component Video > encoder: 0x15 > encoder: 0x13 > encoder: 0x16 > encoder: 0xf > (II) RADEON(0): Output DVI-1 using monitor section Monitor0 > (II) RADEON(0): I2C bus "DVI-1" initialized. > (II) RADEON(0): Output DVI-0 has no monitor section > (II) RADEON(0): I2C bus "DVI-0" initialized. > (II) RADEON(0): Port0: > XRANDR name: DVI-1 > Connector: DVI-I > CRT2: INTERNAL_KLDSCP_DAC2 > DFP1: INTERNAL_KLDSCP_TMDS1 > DDC reg: 0x7e50 > (II) RADEON(0): Port1: > XRANDR name: DVI-0 > Connector: DVI-I > CRT1: INTERNAL_KLDSCP_DAC1 > DFP3: INTERNAL_LVTM1 > DDC reg: 0x7e40 > (II) RADEON(0): I2C device "DVI-1:E-EDID segment register" registered at address 0x60. > (II) RADEON(0): I2C device "DVI-1:ddc2" registered at address 0xA0. > (II) RADEON(0): EDID vendor "SAM", prod id 628 > (II) RADEON(0): Using hsync ranges from config file > (II) RADEON(0): Using vrefresh ranges from config file > (II) RADEON(0): Printing DDC gathered Modelines: > (II) RADEON(0): Modeline "1440x900"x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) > (II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) > (II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) > (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) > (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) > (II) RADEON(0): Modeline "1440x900"x0.0 88.75 1440 1488 1520 1600 900 903 909 926 +hsync -vsync (55.5 kHz) > (II) RADEON(0): Modeline "1440x900"x0.0 136.75 1440 1536 1688 1936 900 903 909 942 -hsync +vsync (70.6 kHz) > (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) > (II) RADEON(0): Modeline "1280x960"x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz) > (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) > (II) RADEON(0): Output: DVI-1, Detected Monitor Type: 3 > (II) RADEON(0): EDID data from the display on output: DVI-1 ---------------------- > (II) RADEON(0): Manufacturer: SAM Model: 274 Serial#: 1296380217 > (II) RADEON(0): Year: 2007 Week: 28 > (II) RADEON(0): EDID Version: 1.3 > (II) RADEON(0): Digital Display Input > (II) RADEON(0): Max Image Size [cm]: horiz.: 41 vert.: 26 > (II) RADEON(0): Gamma: 2.35 > (II) RADEON(0): DPMS capabilities: Off > (II) RADEON(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 > (II) RADEON(0): First detailed timing is preferred mode > (II) RADEON(0): redX: 0.640 redY: 0.329 greenX: 0.300 greenY: 0.600 > (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 > (II) RADEON(0): Supported VESA Video Modes: > (II) RADEON(0): 720x400@70Hz > (II) RADEON(0): 640x480@60Hz > (II) RADEON(0): 640x480@67Hz > (II) RADEON(0): 640x480@72Hz > (II) RADEON(0): 640x480@75Hz > (II) RADEON(0): 800x600@56Hz > (II) RADEON(0): 800x600@60Hz > (II) RADEON(0): 800x600@72Hz > (II) RADEON(0): 800x600@75Hz > (II) RADEON(0): 832x624@75Hz > (II) RADEON(0): 1024x768@60Hz > (II) RADEON(0): 1024x768@70Hz > (II) RADEON(0): 1024x768@75Hz > (II) RADEON(0): 1280x1024@75Hz > (II) RADEON(0): 1152x870@75Hz > (II) RADEON(0): Manufacturer's mask: 0 > (II) RADEON(0): Supported Future Video Modes: > (II) RADEON(0): #0: hsize: 1440 vsize 900 refresh: 60 vid: 149 > (II) RADEON(0): #1: hsize: 1440 vsize 900 refresh: 75 vid: 3989 > (II) RADEON(0): #2: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 > (II) RADEON(0): #3: hsize: 1280 vsize 960 refresh: 60 vid: 16513 > (II) RADEON(0): #4: hsize: 1152 vsize 864 refresh: 75 vid: 20337 > (II) RADEON(0): Supported additional Video Mode: > (II) RADEON(0): clock: 106.5 MHz Image Size: 410 x 257 mm > (II) RADEON(0): h_active: 1440 h_sync: 1520 h_sync_end 1672 h_blank_end 1904 h_border: 0 > (II) RADEON(0): v_active: 900 v_sync: 903 v_sync_end 909 v_blanking: 934 v_border: 0 > (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 140 MHz > (II) RADEON(0): Monitor name: SyncMaster > (II) RADEON(0): Serial No: H9XP701904 > (II) RADEON(0): EDID (in hex): > (II) RADEON(0): 00ffffffffffff004c2d74023931454d > (II) RADEON(0): 1c11010380291a872ade95a3544c9926 > (II) RADEON(0): 0f5054bfef809500950f81808140714f > (II) RADEON(0): 0101010101019a29a0d0518422305098 > (II) RADEON(0): 36009a011100001c000000fd00384b1e > (II) RADEON(0): 510e000a202020202020000000fc0053 > (II) RADEON(0): 796e634d61737465720a2020000000ff > (II) RADEON(0): 00483958503730313930340a20200062 > finished output detect: 0 > (II) RADEON(0): I2C device "DVI-0:E-EDID segment register" registered at address 0x60. > (II) RADEON(0): I2C device "DVI-0:ddc2" registered at address 0xA0. > (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 > Dac detection success > Unhandled monitor type 0 > finished output detect: 1 > finished all detect > before xf86InitialConfiguration > (II) RADEON(0): EDID vendor "SAM", prod id 628 > (II) RADEON(0): Using hsync ranges from config file > (II) RADEON(0): Using vrefresh ranges from config file > (II) RADEON(0): Printing DDC gathered Modelines: > (II) RADEON(0): Modeline "1440x900"x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) > (II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) > (II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) > (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) > (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) > (II) RADEON(0): Modeline "1440x900"x0.0 88.75 1440 1488 1520 1600 900 903 909 926 +hsync -vsync (55.5 kHz) > (II) RADEON(0): Modeline "1440x900"x0.0 136.75 1440 1536 1688 1936 900 903 909 942 -hsync +vsync (70.6 kHz) > (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) > (II) RADEON(0): Modeline "1280x960"x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz) > (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) > (II) RADEON(0): Output: DVI-1, Detected Monitor Type: 3 > (II) RADEON(0): EDID data from the display on output: DVI-1 ---------------------- > (II) RADEON(0): Manufacturer: SAM Model: 274 Serial#: 1296380217 > (II) RADEON(0): Year: 2007 Week: 28 > (II) RADEON(0): EDID Version: 1.3 > (II) RADEON(0): Digital Display Input > (II) RADEON(0): Max Image Size [cm]: horiz.: 41 vert.: 26 > (II) RADEON(0): Gamma: 2.35 > (II) RADEON(0): DPMS capabilities: Off > (II) RADEON(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 > (II) RADEON(0): First detailed timing is preferred mode > (II) RADEON(0): redX: 0.640 redY: 0.329 greenX: 0.300 greenY: 0.600 > (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 > (II) RADEON(0): Supported VESA Video Modes: > (II) RADEON(0): 720x400@70Hz > (II) RADEON(0): 640x480@60Hz > (II) RADEON(0): 640x480@67Hz > (II) RADEON(0): 640x480@72Hz > (II) RADEON(0): 640x480@75Hz > (II) RADEON(0): 800x600@56Hz > (II) RADEON(0): 800x600@60Hz > (II) RADEON(0): 800x600@72Hz > (II) RADEON(0): 800x600@75Hz > (II) RADEON(0): 832x624@75Hz > (II) RADEON(0): 1024x768@60Hz > (II) RADEON(0): 1024x768@70Hz > (II) RADEON(0): 1024x768@75Hz > (II) RADEON(0): 1280x1024@75Hz > (II) RADEON(0): 1152x870@75Hz > (II) RADEON(0): Manufacturer's mask: 0 > (II) RADEON(0): Supported Future Video Modes: > (II) RADEON(0): #0: hsize: 1440 vsize 900 refresh: 60 vid: 149 > (II) RADEON(0): #1: hsize: 1440 vsize 900 refresh: 75 vid: 3989 > (II) RADEON(0): #2: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 > (II) RADEON(0): #3: hsize: 1280 vsize 960 refresh: 60 vid: 16513 > (II) RADEON(0): #4: hsize: 1152 vsize 864 refresh: 75 vid: 20337 > (II) RADEON(0): Supported additional Video Mode: > (II) RADEON(0): clock: 106.5 MHz Image Size: 410 x 257 mm > (II) RADEON(0): h_active: 1440 h_sync: 1520 h_sync_end 1672 h_blank_end 1904 h_border: 0 > (II) RADEON(0): v_active: 900 v_sync: 903 v_sync_end 909 v_blanking: 934 v_border: 0 > (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 140 MHz > (II) RADEON(0): Monitor name: SyncMaster > (II) RADEON(0): Serial No: H9XP701904 > (II) RADEON(0): EDID (in hex): > (II) RADEON(0): 00ffffffffffff004c2d74023931454d > (II) RADEON(0): 1c11010380291a872ade95a3544c9926 > (II) RADEON(0): 0f5054bfef809500950f81808140714f > (II) RADEON(0): 0101010101019a29a0d0518422305098 > (II) RADEON(0): 36009a011100001c000000fd00384b1e > (II) RADEON(0): 510e000a202020202020000000fc0053 > (II) RADEON(0): 796e634d61737465720a2020000000ff > (II) RADEON(0): 00483958503730313930340a20200062 > (II) RADEON(0): Panel infos found from DDC detailed: 1440x900 > (II) RADEON(0): EDID vendor "SAM", prod id 628 > (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 > Dac detection success > Unhandled monitor type 0 > (II) RADEON(0): Output DVI-1 connected > (II) RADEON(0): Output DVI-0 disconnected > (II) RADEON(0): Using exact sizes for initial modes > (II) RADEON(0): Output DVI-1 using initial mode 1440x900 > after xf86InitialConfiguration > (**) RADEON(0): Display dimensions: (410, 260) mm > (**) RADEON(0): DPI set to (89, 140) > (II) Loading sub module "fb" > (II) LoadModule: "fb" > (II) Loading /usr/local/lib/xorg/modules//libfb.so > (II) Module fb: vendor="X.Org Foundation" > compiled for 1.6.0, module version = 1.0.0 > ABI class: X.Org ANSI C Emulation, version 0.4 > (==) RADEON(0): Using gamma correction (1.0, 1.0, 1.0) > (II) Loading sub module "ramdac" > (II) LoadModule: "ramdac" > (II) Module "ramdac" already built-in > (==) RADEON(0): Using XAA acceleration architecture > (II) Loading sub module "xaa" > (II) LoadModule: "xaa" > (II) Loading /usr/local/lib/xorg/modules//libxaa.so > (II) Module xaa: vendor="X.Org Foundation" > compiled for 1.6.0, module version = 1.2.1 > ABI class: X.Org Video Driver, version 5.0 > (==) RADEON(0): Write-combining range (0x0,0x1000) was already clear > (!!) RADEON(0): For information on using the multimedia capabilities > of this adapter, please see http://gatos.sf.net. > (!!) RADEON(0): MergedFB support has been removed and replaced with xrandr 1.2 support > (--) Depth 24 pixmap format is 32 bpp > (II) do I need RAC? No, I don't. > (II) resource ranges after preInit: > [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [3] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprU) > [4] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprU) > [5] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprU) > [6] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [7] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > [8] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) > [9] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) > (II) RADEON(0): RADEONScreenInit d0000000 0 0 > (==) RADEON(0): Write-combining range (0xa0000,0x10000) was already clear > Output DFP1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Blank CRTC 1 success > Disable CRTC 1 success > (==) RADEON(0): Using 24 bit depth buffer > (II) RADEON(0): RADEONInitMemoryMap() : > (II) RADEON(0): mem_size : 0x10000000 > (II) RADEON(0): MC_FB_LOCATION : 0xdfffd000 > (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 > (II) RADEON(0): Depth moves disabled by default > (II) RADEON(0): Using 32 MB GART aperture > (II) RADEON(0): Using 1 MB for the ring buffer > (II) RADEON(0): Using 2 MB for vertex/indirect buffers > (II) RADEON(0): Using 29 MB for GART textures > (II) RADEON(0): Memory manager initialized to (0,0) (1472,8191) > (II) RADEON(0): Reserved area from (0,1440) to (1472,1442) > (II) RADEON(0): Largest offscreen area available: 1472 x 6749 > (II) RADEON(0): Will use front buffer at offset 0x0 > (II) RADEON(0): Will use back buffer at offset 0x23c2000 > (II) RADEON(0): Will use depth buffer at offset 0x2bd8000 > (II) RADEON(0): Will use 32 kb for PCI GART table at offset 0xfff8000 > (II) RADEON(0): Will use 208896 kb for textures at offset 0x33ee000 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: Searching for BusID pci:0000:06:00.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: drmOpenMinor returns 10 > drmOpenByBusid: drmGetBusid reports pci:0000:06:00.0 > (II) [drm] DRM interface version 1.2 > (II) [drm] DRM open master succeeded. > (II) RADEON(0): [drm] Using the DRM lock SAREA also for drawables. > (II) RADEON(0): [drm] framebuffer handle = 0xd0000000 > (II) RADEON(0): [drm] added 1 reserved context for kernel > (II) RADEON(0): X context handle = 0x1 > (II) RADEON(0): [drm] installed DRM signal handler > (II) RADEON(0): [pci] 32768 kB allocated with handle 0x7a2cb000 > (II) RADEON(0): [pci] ring handle = 0x7a2cb000 > (II) RADEON(0): [pci] Ring mapped at 0x812e00000 > (II) RADEON(0): [pci] Ring contents 0x00000000 > (II) RADEON(0): [pci] ring read ptr handle = 0x7a3cc000 > (II) RADEON(0): [pci] Ring read ptr mapped at 0x80076b000 > (II) RADEON(0): [pci] Ring read ptr contents 0x00000000 > (II) RADEON(0): [pci] vertex/indirect buffers handle = 0x7a3cd000 > (II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812f01000 > (II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000 > (II) RADEON(0): [pci] GART texture map handle = 0x7a5cd000 > (II) RADEON(0): [pci] GART Texture map mapped at 0x8131cd000 > (II) RADEON(0): [drm] register handle = 0xfbee0000 > (II) RADEON(0): [dri] Visual configs initialized > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > (II) RADEON(0): MC_FB_LOCATION : 0xdfffd000 0xfffff000 > (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 > (==) RADEON(0): Backing store disabled > (II) RADEON(0): [DRI] installation complete > (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers > (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers > (II) RADEON(0): [drm] dma control initialized, using IRQ 16 > (II) RADEON(0): [drm] Initialized kernel GART heap manager, 29884416 > (WW) RADEON(0): DRI init changed memory map, adjusting ... > (WW) RADEON(0): MC_FB_LOCATION was: 0xdfffd000 is: 0xdfffd000 > (WW) RADEON(0): MC_AGP_LOCATION was: 0x003f0000 is: 0xffffffc0 > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > (II) RADEON(0): MC_FB_LOCATION : 0xdfffd000 0xdfffd000 > (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 > (II) RADEON(0): Direct rendering enabled > (II) RADEON(0): XAA Render acceleration unsupported on Radeon 9500/9700 and newer. Please use EXA instead. > (II) RADEON(0): Render acceleration disabled > (II) RADEON(0): num quad-pipes is 3 > (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) > Screen to screen bit blits > Solid filled rectangles > 8x8 mono pattern filled rectangles > Indirect CPU to Screen color expansion > Solid Lines > Scanline Image Writes > Setting up tile and stipple cache: > 32 128x128 slots > 32 256x256 slots > 16 512x512 slots > (II) RADEON(0): Acceleration enabled > (**) Option "dpms" > (**) RADEON(0): DPMS enabled > (==) RADEON(0): Silken mouse enabled > (II) RADEON(0): Will use 32 kb for hardware cursor 0 at offset 0x00819000 > (II) RADEON(0): Will use 32 kb for hardware cursor 1 at offset 0x0081f000 > (II) RADEON(0): Largest offscreen area available: 1472 x 6741 > (II) RADEON(0): Set up textured video > Output DFP1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Output DFP1 disable success > Mode 1440x900 - 1904 934 6 > (II) RADEON(0): RADEONRestoreMemMapRegisters() : > (II) RADEON(0): MC_FB_LOCATION : 0xdfffd000 0xdfffd000 > (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 > freq: 106500000 > best_freq: 106500000 > best_feedback_div: 71 > best_ref_div: 2 > best_post_div: 9 > (II) RADEON(0): crtc(0) Clock: mode 106500, PLL 106500 > (II) RADEON(0): crtc(0) PLL : refdiv 2, fbdiv 0x47(71), pdiv 9 > Set CRTC 0 PLL success > Set CRTC Timing success > Set CRTC 0 Overscan success > Not using RMX > scaler 0 setup success > Set CRTC 0 Source success > crtc 0 YUV disable setup success > Output digital setup success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Blank CRTC 1 success > Disable CRTC 1 success > (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled message. > Lock CRTC 0 success > Unlock CRTC 0 success > (--) RandR disabled > (II) Initializing built-in extension Generic Event Extension > (II) Initializing built-in extension SHAPE > (II) Initializing built-in extension MIT-SHM > (II) Initializing built-in extension XInputExtension > (II) Initializing built-in extension XTEST > (II) Initializing built-in extension BIG-REQUESTS > (II) Initializing built-in extension SYNC > (II) Initializing built-in extension XKEYBOARD > (II) Initializing built-in extension XC-MISC > (II) Initializing built-in extension XINERAMA > (II) Initializing built-in extension XFIXES > (II) Initializing built-in extension RENDER > (II) Initializing built-in extension RANDR > (II) Initializing built-in extension COMPOSITE > (II) Initializing built-in extension DAMAGE > (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so > (II) GLX: Initialized DRISWRAST GL provider for screen 0 > (II) RADEON(0): Setting screen physical size to 410 x 257 > (**) Option "Protocol" "auto" > (**) Mouse0: Device: "/dev/sysmouse" > (**) Mouse0: Protocol: "auto" > (**) Option "CorePointer" > (**) Mouse0: always reports core events > (**) Option "Device" "/dev/sysmouse" > (==) Mouse0: Emulate3Buttons, Emulate3Timeout: 50 > (**) Option "ZAxisMapping" "4 5 6 7" > (**) Mouse0: ZAxisMapping: buttons 4, 5, 6 and 7 > (**) Mouse0: Buttons: 11 > (**) Mouse0: Sensitivity: 1 > (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) > (**) Mouse0: (accel) keeping acceleration scheme 1 > (**) Mouse0: (accel) filter chain progression: 2.00 > (**) Mouse0: (accel) filter stage 0: 20.00 ms > (**) Mouse0: (accel) set acceleration profile 0 > (II) Mouse0: SetupAuto: hw.iftype is 4, hw.model is 0 > (II) Mouse0: SetupAuto: protocol is SysMouse > (**) Option "CoreKeyboard" > (**) Keyboard0: always reports core events > (**) Option "Protocol" "standard" > (**) Keyboard0: Protocol: standard > (**) Option "AutoRepeat" "500 30" > (**) Option "XkbRules" "xorg" > (**) Keyboard0: XkbRules: "xorg" > (**) Option "XkbModel" "pc105" > (**) Keyboard0: XkbModel: "pc105" > (**) Option "XkbLayout" "us" > (**) Keyboard0: XkbLayout: "us" > (**) Option "CustomKeycodes" "off" > (**) Keyboard0: CustomKeycodes disabled > (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD) > Output DFP1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 disable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Output DFP1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 disable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Output DFP1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 disable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Output DFP1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Output DFP1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Output DFP1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 disable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 disable success > > /var/log/messages: > > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=30 s=0 e=3288 d=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=30 s=0x0 e=0xcd8 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941502 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=31 s=0 e=1684 d=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=31 s=0x0 e=0x694 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0x20006444, nr=0x44, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_idle] > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_do_cp_idle] > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0x20006444, nr=0x44, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_idle] > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_do_cp_idle] > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941503 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=0 s=0 e=13260 d=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=0 s=0x0 e=0x33cc > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941504 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=1 s=0 e=6084 d=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=1 s=0x0 e=0x17c4 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941505 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=2 s=0 e=1840 d=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=2 s=0x0 e=0x730 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941506 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=3 s=0 e=5152 d=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=3 s=0x0 e=0x1420 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941506 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=4 s=0 e=3288 d=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=4 s=0x0 e=0xcd8 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941508 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=5 s=0 e=3236 d=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=5 s=0x0 e=0xca4 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941509 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=6 s=0 e=1684 d=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=6 s=0x0 e=0x694 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941510 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=7 s=0 e=1736 d=1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=7 s=0x0 e=0x6c8 -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090411/92c138a1/attachment.pgp From xorquewasp at googlemail.com Sat Apr 11 12:28:38 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sat Apr 11 12:28:44 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <86zlen9vw2.fsf@kopusha.onet> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090410211307.GA83697@logik.internal.network> <3a142e750904101730k53b7fbabn6e801ac36f1182e0@mail.gmail.com> <20090411101559.GC83697@logik.internal.network> <86zlen9vw2.fsf@kopusha.onet> Message-ID: <20090411192834.GE83697@logik.internal.network> On 2009-04-11 16:12:45, Mikolaj Golub wrote: > > If you are interested in providing useful information about your freezes, > please read the following: Thanks very much. Will be doing all of the above. From xorquewasp at googlemail.com Sat Apr 11 12:30:58 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sat Apr 11 12:31:05 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <1239477075.1932.5.camel@balrog.2hip.net> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090411102300.GD83697@logik.internal.network> <1239477075.1932.5.camel@balrog.2hip.net> Message-ID: <20090411193054.GF83697@logik.internal.network> On 2009-04-11 14:11:15, Robert Noland wrote: > > Are you running the 7.2-PRE or -STABLE? There are a few relevant fixes > in -STABLE that didn't make it into the pre-release. Sorry, should've made that clear. It was meant to be -STABLE but it seems to be calling itself -PRE. Just to clarify, my uname says 7.2-PRERELEASE but I used the 'stable-supfile'. This is expected, yes? I'm about to update the machine's BIOS and then enable all the possible debugging options from the kernel dev handbook. xw From rnoland at FreeBSD.org Sat Apr 11 12:37:54 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Sat Apr 11 12:38:03 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <20090411193054.GF83697@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090411102300.GD83697@logik.internal.network> <1239477075.1932.5.camel@balrog.2hip.net> <20090411193054.GF83697@logik.internal.network> Message-ID: <1239478606.1932.13.camel@balrog.2hip.net> On Sat, 2009-04-11 at 20:30 +0100, xorquewasp@googlemail.com wrote: > On 2009-04-11 14:11:15, Robert Noland wrote: > > > > Are you running the 7.2-PRE or -STABLE? There are a few relevant fixes > > in -STABLE that didn't make it into the pre-release. > > Sorry, should've made that clear. It was meant to be -STABLE but it > seems to be calling itself -PRE. Just to clarify, my uname > says 7.2-PRERELEASE but I used the 'stable-supfile'. This is expected, > yes? > > I'm about to update the machine's BIOS and then enable all the possible > debugging options from the kernel dev handbook. Yes, just make sure that your -STABLE is at least: r190653 | rnoland | 2009-04-02 13:21:41 -0500 (Thu, 02 Apr 2009) | 7 lines robert. > xw -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090411/6e96f6d3/attachment.pgp From rnoland at FreeBSD.org Sat Apr 11 12:45:29 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Sat Apr 11 12:45:35 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <20090411140643.35cc82ae@ernst.jennejohn.org> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090410211307.GA83697@logik.internal.network> <3a142e750904101730k53b7fbabn6e801ac36f1182e0@mail.gmail.com> <20090411101559.GC83697@logik.internal.network> <20090411140643.35cc82ae@ernst.jennejohn.org> Message-ID: <1239479071.1932.16.camel@balrog.2hip.net> On Sat, 2009-04-11 at 14:06 +0200, Gary Jennejohn wrote: > On Sat, 11 Apr 2009 11:15:59 +0100 > xorquewasp@googlemail.com wrote: > > > On 2009-04-11 02:30:40, Paul B. Mahol wrote: > > > > > > If it locks under X11 then use debug.debugger_on_panic=0 sysctl. > > > Not doing this will increase drasticaly chances of locking whole system > > > and not providing any debug data. > > > > I don't seem to have that sysctl. > > > > You sure that's the correct name? > > > > It's definitely in 8-current. Seems to be set to 0 as default. This may only exist if you have DDB enabled... robert. > --- > Gary Jennejohn > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090411/bf51a6ee/attachment.pgp From aryeh.friedman at gmail.com Sat Apr 11 13:56:49 2009 From: aryeh.friedman at gmail.com (Aryeh M. Friedman) Date: Sat Apr 11 13:56:57 2009 Subject: setting up local authorative name server with a no-ip.com registered domain Message-ID: <49E10406.7060006@gmail.com> I have 3 domains that are registered with no-ip.com (istudentunion.com, org and net). All three are also using their "no-ip plus" service which provides both static and dynamic resolution via their nameservers. When I configure the domains nameservers to be theirs everything works great (for the most part), but when I change the nameservers to my own sites BIND (base 7.3-RELEASE) I can get everything to resolve locally and via dig/host/nslookup remotely (if and only if I specify the nameserver by IP). What appears to be happing is this: ~/Desktop:aryeh@flosoft% !d dig ns istudentunion.org +trace ; <<>> DiG 9.4.3-P2 <<>> ns istudentunion.org +trace ;; global options: printcmd . 463753 IN NS I.ROOT-SERVERS.NET. . 463753 IN NS C.ROOT-SERVERS.NET. . 463753 IN NS L.ROOT-SERVERS.NET. . 463753 IN NS K.ROOT-SERVERS.NET. . 463753 IN NS M.ROOT-SERVERS.NET. . 463753 IN NS A.ROOT-SERVERS.NET. . 463753 IN NS E.ROOT-SERVERS.NET. . 463753 IN NS B.ROOT-SERVERS.NET. . 463753 IN NS H.ROOT-SERVERS.NET. . 463753 IN NS D.ROOT-SERVERS.NET. . 463753 IN NS G.ROOT-SERVERS.NET. . 463753 IN NS F.ROOT-SERVERS.NET. . 463753 IN NS J.ROOT-SERVERS.NET. ;; Received 500 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms org. 172800 IN NS B2.ORG.AFILIAS-NST.org. org. 172800 IN NS A2.ORG.AFILIAS-NST.INFO. org. 172800 IN NS C0.ORG.AFILIAS-NST.INFO. org. 172800 IN NS B0.ORG.AFILIAS-NST.org. org. 172800 IN NS A0.ORG.AFILIAS-NST.INFO. org. 172800 IN NS D0.ORG.AFILIAS-NST.org. ;; Received 437 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 86 ms istudentunion.org. 86400 IN NS ns2.istudentunion.org. istudentunion.org. 86400 IN NS ns1.istudentunion.org. ;; Received 103 bytes from 199.19.54.1#53(B0.ORG.AFILIAS-NST.org) in 88 ms ;; connection timed out; no servers could be reached From brampton+freebsd-hackers at gmail.com Sat Apr 11 14:04:00 2009 From: brampton+freebsd-hackers at gmail.com (Andrew Brampton) Date: Sat Apr 11 14:04:07 2009 Subject: FreeBSD memguard + spinlocks In-Reply-To: References: Message-ID: 2009/4/11 Robert Watson : > On Sat, 11 Apr 2009, Andrew Brampton wrote: > > Your understanding is mostly right. ?The missing bit is this: there are two > kinds of interrupt contexts -- fast/filter interrupt handlers, which borrow > the stack and execution context of the kernel thread they preempt, and > interrupt threads, which get their own complete thread context. > > Fast interrupt handlers are allowed unlock to acquire spinlocks so as to > avoid deadlock because of the borrowed context. ?This means they can't > perform any sort of sleep, or acquire any locks that might sleep, since the > thread they've preempted may hold conflicting locks, or be the one that > would have woken up the sleep that the handler performed. ?Almost no code > will run in fast handlers -- perhaps checking some device registers, doing > work on a lockless or spinlock-protected queue, and waking up a worker > thread. > > This is why, BTW, spin locks disable interrupt: they need to control > preemption by other interrupt handlers to avoid deadlock, but they are not > intended for use except when either in the scheduler, in a few related IPI > contexts, or when synchronizing between normal kernel code and a fast > handler. > > Full interrupt thread contexts are permitted to perform short lock sleeps, > such as those performed when contending default mutexes, rwlocks, and > rmlocks. They are permitted to invoke kernel services such as malloc(9), > UMA(9), the network stack, etc, as long as they use M_NOWAIT and don't > invoke msleep(9) or similar unbounded sleeps -- again to avoid the > possibility of deadlocks, since you don't want an interrupt thread sleeping > waiting for an event that only it can satisfy. > > So the first question, really, is whether you are or mean to be using > fast/filter interrupt handler. ?Device drivers will never call memory > allocation, free, etc, from there, but will defer it to an ithread using the > filter mechanism in 8.x, or to a task queue or other worker in 7.x and > earlier. ?If you're using a regular INTR_MPSAFE ithread, you should be able > to use only default mutexes (a single atomic operation if uncontended) > without disabling interrupts, etc. > > Robert N M Watson > Computer Laboratory > University of Cambridge > Thanks very much for your detailed reply. I'm slowly understanding how everything in FreeBSD fits together, and I appreciate your help. I've been given a project to take over, and all of the design decisions were made before I started working on it, thus I'm playing catch up. One of the decisions was to implement their own version of a spin lock, which literally looks something like this: lock_aquire() { critical_enter(); while (! lockHeld ) {} lockHeld++; } This was actually the code tripping up MemGuard, as it is inside a critical section, which MemGuard is unable to sleep within. This is all running inside a kthread_create thread (I'm unsure of the proper name of this type of thread). Anyway, that is why I also asked about a lighter weight spin lock (perhaps similar to this one). I tempted to replace this custom spinlock with the standard MTX_DEF, however I'm unsure of its impact. The custom spin lock seems quick and light to acquire, and it does not concern me that a interrupt can potentially interrupt the code. On a related note, if you change the lock in memguard to a MTX_SPIN, it panics the kernel during boot. So that is not an option :) I was only using memguard because I suspected memory being used after it was freed. However, I think I will either change my locks to MTX_DEF or live without memguard. I realise I've not really asked any questions, but I would be grateful for any insights anyone may have. Andrew From aryeh.friedman at gmail.com Sat Apr 11 14:10:26 2009 From: aryeh.friedman at gmail.com (Aryeh M. Friedman) Date: Sat Apr 11 14:10:34 2009 Subject: setting up local authorative name server with a no-ip.com registered domain In-Reply-To: <49E10406.7060006@gmail.com> References: <49E10406.7060006@gmail.com> Message-ID: <49E1073D.2090303@gmail.com> Aryeh M. Friedman wrote: > I have 3 domains that are registered with no-ip.com > (istudentunion.com, org and net). All three are also using their > "no-ip plus" service which provides both static and dynamic resolution > via their nameservers. When I configure the domains nameservers to > be theirs everything works great (for the most part), but when I > change the nameservers to my own sites BIND (base 7.3-RELEASE) I can > get everything to resolve locally and via dig/host/nslookup remotely > (if and only if I specify the nameserver by IP). What appears to be > happing is this: > > ~/Desktop:aryeh@flosoft% !d > dig ns istudentunion.org +trace > > ; <<>> DiG 9.4.3-P2 <<>> ns istudentunion.org +trace > ;; global options: printcmd > . 463753 IN NS I.ROOT-SERVERS.NET. > . 463753 IN NS C.ROOT-SERVERS.NET. > . 463753 IN NS L.ROOT-SERVERS.NET. > . 463753 IN NS K.ROOT-SERVERS.NET. > . 463753 IN NS M.ROOT-SERVERS.NET. > . 463753 IN NS A.ROOT-SERVERS.NET. > . 463753 IN NS E.ROOT-SERVERS.NET. > . 463753 IN NS B.ROOT-SERVERS.NET. > . 463753 IN NS H.ROOT-SERVERS.NET. > . 463753 IN NS D.ROOT-SERVERS.NET. > . 463753 IN NS G.ROOT-SERVERS.NET. > . 463753 IN NS F.ROOT-SERVERS.NET. > . 463753 IN NS J.ROOT-SERVERS.NET. > ;; Received 500 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms > > org. 172800 IN NS B2.ORG.AFILIAS-NST.org. > org. 172800 IN NS A2.ORG.AFILIAS-NST.INFO. > org. 172800 IN NS C0.ORG.AFILIAS-NST.INFO. > org. 172800 IN NS B0.ORG.AFILIAS-NST.org. > org. 172800 IN NS A0.ORG.AFILIAS-NST.INFO. > org. 172800 IN NS D0.ORG.AFILIAS-NST.org. > ;; Received 437 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 86 ms > > istudentunion.org. 86400 IN NS ns2.istudentunion.org. > istudentunion.org. 86400 IN NS ns1.istudentunion.org. > ;; Received 103 bytes from 199.19.54.1#53(B0.ORG.AFILIAS-NST.org) in > 88 ms > > ;; connection timed out; no servers could be reached > > Quick additional note we upgraded all 3 domains to no-ip plus because they assured us that we could run our own dns From onemda at gmail.com Sat Apr 11 14:26:45 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Sat Apr 11 14:26:58 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <20090411101559.GC83697@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090410211307.GA83697@logik.internal.network> <3a142e750904101730k53b7fbabn6e801ac36f1182e0@mail.gmail.com> <20090411101559.GC83697@logik.internal.network> Message-ID: <3a142e750904111426u43c11a38wc6b385d3ff215673@mail.gmail.com> On 4/11/09, xorquewasp@googlemail.com wrote: > On 2009-04-11 02:30:40, Paul B. Mahol wrote: >> >> If it locks under X11 then use debug.debugger_on_panic=0 sysctl. >> Not doing this will increase drasticaly chances of locking whole system >> and not providing any debug data. > > I don't seem to have that sysctl. > > You sure that's the correct name? Well if you dont have it, capturing cores should generaly still work. But in this case some kind of serial console is only remaining option. -- Paul From rwatson at FreeBSD.org Sat Apr 11 14:39:01 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Apr 11 14:39:07 2009 Subject: FreeBSD memguard + spinlocks In-Reply-To: References: Message-ID: On Sat, 11 Apr 2009, Andrew Brampton wrote: > Thanks very much for your detailed reply. I'm slowly understanding how > everything in FreeBSD fits together, and I appreciate your help. > > I've been given a project to take over, and all of the design decisions were > made before I started working on it, thus I'm playing catch up. One of the > decisions was to implement their own version of a spin lock, which literally > looks something like this: > > lock_aquire() { > critical_enter(); > while (! lockHeld ) {} > lockHeld++; > } > > This was actually the code tripping up MemGuard, as it is inside a critical > section, which MemGuard is unable to sleep within. This is all running > inside a kthread_create thread (I'm unsure of the proper name of this type > of thread). > > Anyway, that is why I also asked about a lighter weight spin lock (perhaps > similar to this one). I tempted to replace this custom spinlock with the > standard MTX_DEF, however I'm unsure of its impact. The custom spin lock > seems quick and light to acquire, and it does not concern me that a > interrupt can potentially interrupt the code. > > On a related note, if you change the lock in memguard to a MTX_SPIN, it > panics the kernel during boot. So that is not an option :) I was only using > memguard because I suspected memory being used after it was freed. However, > I think I will either change my locks to MTX_DEF or live without memguard. > > I realise I've not really asked any questions, but I would be grateful for > any insights anyone may have. Andrew My advice, unless you're definitely executing code in fast interrupt contexts, is to simply use the FreeBSD default mutex primitive instead of either a custom-build spinlock or a FreeBSD MTX_SPIN mutex. The default mutex is adaptive, and will spin when contending the lock unless the thread holding the lock isn't executing, in which case it will fall back on a context switch. Our mutexes also make correct use of memory barriers, which the above example code doesn't appear to, so will work on systems that have weaker memory ordering properties. Using the default mutex scheme also allows you to take advantage of WITNESS, our lock order verifier, which proves a really useful tool when a lot of locks are in flight. The critical sections you're using above may not have the effect you intend: they prevent preemption by another thread, and they prevent migration to another CPU, but they don't prevent fast interrupt handlers from executing. Any synchronization with a fast interrupt handler needs to be done either using spinlocks, or other atomic operations. Robert N M Watson Computer Laboratory University of Cambridge From vince at unsane.co.uk Sun Apr 12 02:24:49 2009 From: vince at unsane.co.uk (Vincent Hoffman) Date: Sun Apr 12 02:24:56 2009 Subject: setting up local authorative name server with a no-ip.com registered domain In-Reply-To: <49E10406.7060006@gmail.com> References: <49E10406.7060006@gmail.com> Message-ID: <49E1B35C.9040106@unsane.co.uk> On 11/4/09 21:56, Aryeh M. Friedman wrote: > I have 3 domains that are registered with no-ip.com > (istudentunion.com, org and net). All three are also using their > "no-ip plus" service which provides both static and dynamic resolution > via their nameservers. When I configure the domains nameservers to > be theirs everything works great (for the most part), but when I > change the nameservers to my own sites BIND (base 7.3-RELEASE) I can > get everything to resolve locally and via dig/host/nslookup remotely > (if and only if I specify the nameserver by IP). What appears to be > happing is this: > > ~/Desktop:aryeh@flosoft% !d > dig ns istudentunion.org +trace > > ; <<>> DiG 9.4.3-P2 <<>> ns istudentunion.org +trace > ;; global options: printcmd > . 463753 IN NS I.ROOT-SERVERS.NET. > . 463753 IN NS C.ROOT-SERVERS.NET. > . 463753 IN NS L.ROOT-SERVERS.NET. > . 463753 IN NS K.ROOT-SERVERS.NET. > . 463753 IN NS M.ROOT-SERVERS.NET. > . 463753 IN NS A.ROOT-SERVERS.NET. > . 463753 IN NS E.ROOT-SERVERS.NET. > . 463753 IN NS B.ROOT-SERVERS.NET. > . 463753 IN NS H.ROOT-SERVERS.NET. > . 463753 IN NS D.ROOT-SERVERS.NET. > . 463753 IN NS G.ROOT-SERVERS.NET. > . 463753 IN NS F.ROOT-SERVERS.NET. > . 463753 IN NS J.ROOT-SERVERS.NET. > ;; Received 500 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms > > org. 172800 IN NS B2.ORG.AFILIAS-NST.org. > org. 172800 IN NS A2.ORG.AFILIAS-NST.INFO. > org. 172800 IN NS C0.ORG.AFILIAS-NST.INFO. > org. 172800 IN NS B0.ORG.AFILIAS-NST.org. > org. 172800 IN NS A0.ORG.AFILIAS-NST.INFO. > org. 172800 IN NS D0.ORG.AFILIAS-NST.org. > ;; Received 437 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 86 ms > > istudentunion.org. 86400 IN NS ns2.istudentunion.org. > istudentunion.org. 86400 IN NS ns1.istudentunion.org. > ;; Received 103 bytes from 199.19.54.1#53(B0.ORG.AFILIAS-NST.org) in > 88 ms > > ;; connection timed out; no servers could be reached > Since your nameservers for istudentunion.org are in the istudentunion.org domain, you will need glue at the parent nameservers to prevent a chicken and egg problem. Exactly how you tell no-ip this i'm not sure but its not a terribly unusual request. Once the have added it you will need to wait for the .org tld zone to update (not sure of their schedule but better than the once or twice a day of 10 years ago :) The other way around this is to have the nameservers for the domain to be in an already resolving domain, that way you dont need to worry about glue. This is very common. Vince > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From aryeh.friedman at gmail.com Sun Apr 12 02:45:29 2009 From: aryeh.friedman at gmail.com (Aryeh M. Friedman) Date: Sun Apr 12 02:45:36 2009 Subject: setting up local authorative name server with a no-ip.com registered domain In-Reply-To: <49E1B35C.9040106@unsane.co.uk> References: <49E10406.7060006@gmail.com> <49E1B35C.9040106@unsane.co.uk> Message-ID: <49E1B834.2080604@gmail.com> Vincent Hoffman wrote: > On 11/4/09 21:56, Aryeh M. Friedman wrote: > >> I have 3 domains that are registered with no-ip.com >> (istudentunion.com, org and net). All three are also using their >> "no-ip plus" service which provides both static and dynamic resolution >> via their nameservers. When I configure the domains nameservers to >> be theirs everything works great (for the most part), but when I >> change the nameservers to my own sites BIND (base 7.3-RELEASE) I can >> get everything to resolve locally and via dig/host/nslookup remotely >> (if and only if I specify the nameserver by IP). What appears to be >> happing is this: >> >> ~/Desktop:aryeh@flosoft% !d >> dig ns istudentunion.org +trace >> >> ; <<>> DiG 9.4.3-P2 <<>> ns istudentunion.org +trace >> ;; global options: printcmd >> . 463753 IN NS I.ROOT-SERVERS.NET. >> . 463753 IN NS C.ROOT-SERVERS.NET. >> . 463753 IN NS L.ROOT-SERVERS.NET. >> . 463753 IN NS K.ROOT-SERVERS.NET. >> . 463753 IN NS M.ROOT-SERVERS.NET. >> . 463753 IN NS A.ROOT-SERVERS.NET. >> . 463753 IN NS E.ROOT-SERVERS.NET. >> . 463753 IN NS B.ROOT-SERVERS.NET. >> . 463753 IN NS H.ROOT-SERVERS.NET. >> . 463753 IN NS D.ROOT-SERVERS.NET. >> . 463753 IN NS G.ROOT-SERVERS.NET. >> . 463753 IN NS F.ROOT-SERVERS.NET. >> . 463753 IN NS J.ROOT-SERVERS.NET. >> ;; Received 500 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms >> >> org. 172800 IN NS B2.ORG.AFILIAS-NST.org. >> org. 172800 IN NS A2.ORG.AFILIAS-NST.INFO. >> org. 172800 IN NS C0.ORG.AFILIAS-NST.INFO. >> org. 172800 IN NS B0.ORG.AFILIAS-NST.org. >> org. 172800 IN NS A0.ORG.AFILIAS-NST.INFO. >> org. 172800 IN NS D0.ORG.AFILIAS-NST.org. >> ;; Received 437 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 86 ms >> >> istudentunion.org. 86400 IN NS ns2.istudentunion.org. >> istudentunion.org. 86400 IN NS ns1.istudentunion.org. >> ;; Received 103 bytes from 199.19.54.1#53(B0.ORG.AFILIAS-NST.org) in >> 88 ms >> >> ;; connection timed out; no servers could be reached >> >> > Since your nameservers for istudentunion.org are in the > istudentunion.org domain, you will need glue at the parent nameservers > to prevent a chicken and egg problem. > Exactly how you tell no-ip this i'm not sure but its not a terribly > unusual request. Once the have added it you will need to wait for the > .org tld zone to update (not sure of their schedule but better than the > once or twice a day of 10 years ago :) > The other way around this is to have the nameservers for the domain > to be in an already resolving domain, that way you dont need to worry > about glue. This is very common. > > I had already used the second trick earlier today (after posting the message) and what I did is pointed a "dead" domain I personally had at the right IP (the other register correctly lets you register/change nameservers [which no-ip has a form for but it seems to do absulutly nothing])... now I am stuck with a corporate domain depending on a domain owned by a single employee (me [even though I am the CTO/COO I personally think it is inapporiate to do it this way]).... the other crazy thing is no-ip puts a 30 day lock on transfers from them when you transfer a domain to them [we transfered from dreamhost]). > > Vince > > > >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> > > > From kientzle at freebsd.org Sun Apr 12 12:30:49 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Sun Apr 12 13:22:15 2009 Subject: setting up local authorative name server with a no-ip.com registered domain In-Reply-To: <49E1B834.2080604@gmail.com> References: <49E10406.7060006@gmail.com> <49E1B35C.9040106@unsane.co.uk> <49E1B834.2080604@gmail.com> Message-ID: <49E24167.4010109@freebsd.org> >> The other way around this is to have the nameservers for the domain >> to be in an already resolving domain, that way you dont need to worry >> about glue. This is very common. >> >> > > I had already used the second trick earlier today (after posting the > message) and what I did is pointed a "dead" domain I personally had at > the right IP (the other register correctly lets you register/change > nameservers [which no-ip has a form for but it seems to do absulutly > nothing])... now I am stuck with a corporate domain depending on a > domain owned by a single employee (me [even though I am the CTO/COO I > personally think it is inapporiate to do it this way]).... You could, of course, register yet another domain ("ns-istudentunion.org"?) for your corporation. Tim From sean.bruno at dsl-only.net Sun Apr 12 14:26:01 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Sun Apr 12 14:47:10 2009 Subject: smart self-test vs 7200.12/ich9r/ahci In-Reply-To: <49DDF710.4050004@icyb.net.ua> References: <49DDF710.4050004@icyb.net.ua> Message-ID: <1239562968.11309.1.camel@localhost.localdomain> On Thu, 2009-04-09 at 16:24 +0300, Andriy Gapon wrote: > I wonder if anybody has an issue like I do: > http://thread.gmane.org/gmane.linux.utilities.smartmontools/6354 > > Does anybody has guesses/clues about what might be happening? > I couldn't see anything specifically wrong with the output. Is there something wrong with the drive? Sean From jilles at stack.nl Sun Apr 12 14:33:36 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Sun Apr 12 14:58:03 2009 Subject: bin/113860: sh(1): shell is still running when using `sh -c' In-Reply-To: <20090403213905.GA21297@stack.nl> References: <20090403213905.GA21297@stack.nl> Message-ID: <20090412213314.GA57862@stack.nl> On Fri, Apr 03, 2009 at 11:39:05PM +0200, Jilles Tjoelker wrote: > I think this can be improved. I have a patch now; it does not handle all cases but the effect on the code is minimal. I decided to go with the readahead but only do it for the first line. To avoid problems with traps not being executed, http://www.stack.nl/~jilles/unix/sh-forkiftrapped.patch is needed. This fixes a bug in EV_EXIT handling, which would be triggered more often with the change to -c. The patch is also needed for bin/74404. Example: sh -c '(trap "echo trapped" EXIT; sleep 3)' http://www.stack.nl/~jilles/unix/sh-minusc-exec.patch the change itself -- Jilles Tjoelker -------------- next part -------------- A non-text attachment was scrubbed... Name: sh-forkiftrapped.patch Type: text/x-diff Size: 1371 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090412/26cf81be/sh-forkiftrapped.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: sh-minusc-exec.patch Type: text/x-diff Size: 2310 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090412/26cf81be/sh-minusc-exec.bin From avg at icyb.net.ua Mon Apr 13 00:06:53 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Apr 13 00:40:10 2009 Subject: smart self-test vs 7200.12/ich9r/ahci In-Reply-To: <1239562968.11309.1.camel@localhost.localdomain> References: <49DDF710.4050004@icyb.net.ua> <1239562968.11309.1.camel@localhost.localdomain> Message-ID: <49E2E47D.5070402@icyb.net.ua> on 12/04/2009 22:02 Sean Bruno said the following: > On Thu, 2009-04-09 at 16:24 +0300, Andriy Gapon wrote: >> I wonder if anybody has an issue like I do: >> http://thread.gmane.org/gmane.linux.utilities.smartmontools/6354 >> >> Does anybody has guesses/clues about what might be happening? >> > > I couldn't see anything specifically wrong with the output. Smart self test never completing. -- Andriy Gapon From sean.bruno at dsl-only.net Mon Apr 13 08:48:56 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Mon Apr 13 09:45:04 2009 Subject: smart self-test vs 7200.12/ich9r/ahci In-Reply-To: <49E2E47D.5070402@icyb.net.ua> References: <49DDF710.4050004@icyb.net.ua> <1239562968.11309.1.camel@localhost.localdomain> <49E2E47D.5070402@icyb.net.ua> Message-ID: <1239637734.24831.56.camel@localhost.localdomain> On Mon, 2009-04-13 at 10:06 +0300, Andriy Gapon wrote: > Smart self test never completing. The "self-test" never goes beyond "90%" complete? Sean From avg at icyb.net.ua Mon Apr 13 08:52:00 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Apr 13 09:48:34 2009 Subject: smart self-test vs 7200.12/ich9r/ahci In-Reply-To: <1239637734.24831.56.camel@localhost.localdomain> References: <49DDF710.4050004@icyb.net.ua> <1239562968.11309.1.camel@localhost.localdomain> <49E2E47D.5070402@icyb.net.ua> <1239637734.24831.56.camel@localhost.localdomain> Message-ID: <49E35F92.6080400@icyb.net.ua> on 13/04/2009 18:48 Sean Bruno said the following: > On Mon, 2009-04-13 at 10:06 +0300, Andriy Gapon wrote: >> Smart self test never completing. > > The "self-test" never goes beyond "90%" complete? Yes, exactly. Even for the short one, which is supposed to complete in 1 minute: $ smartctl -t short /dev/ad16 smartctl version 5.38 [amd64-portbld-freebsd7.1] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION === Sending command: "Execute SMART Short self-test routine immediately in off-line mode". Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful. Testing has begun. Please wait 1 minutes for test to complete. Test will complete after Mon Apr 13 18:51:57 2009 Use smartctl -X to abort test. -- Andriy Gapon From jhb at freebsd.org Mon Apr 13 10:55:12 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Apr 13 11:17:00 2009 Subject: Patch for MS Hyper V (virtualization) In-Reply-To: <49DBFA72.9E64AB4F@verizon.net> References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904070921.14294.jhb@freebsd.org> <49DBFA72.9E64AB4F@verizon.net> Message-ID: <200904131256.44692.jhb@freebsd.org> On Tuesday 07 April 2009 9:14:26 pm Sergey Babkin wrote: > John Baldwin wrote: > > > > On Monday 06 April 2009 11:12:33 pm Sergey Babkin wrote: > > > > Anyway, as far as I can tell, it's only the base register of > > > the simulated DEC21140 device that has this issue, so it's > > > quite possible that the bug is in that device's simulator. > > > > > > I've attached a modified patch that checks conservatively for this > > > precise situation, so it should not break compatibility with > > > anything else. I've tested it on Hyper-V. > > > > Can you test unmodified FreeBSD 8 on Hyper-V? It has an extra fix relative to > > 7 to disable decoding via the PCI command register while sizing BARs that may > > address this. > > 8.0 (February snapshot) seems to have the same issue. Ok. > I've also saved the log of writes that 7.1 does for this device: > > reg 10 val ec01 > reg 14 val febff000 > reg 18 val 0 > reg 1c val 0 > reg 20 val 0 > reg 24 val 0 > reg 30 val febe0000 > reg 4 val 117 > reg 3c val b > reg 3d val 1 > reg 3e val 14 > reg 3f val 28 > reg c val 8 > reg d val 40 > reg 9 val 0 > reg 8 val 20 > reg 10 val ec00 > reg 14 val febff000 > reg 4 val 117 > reg 4 val 117 > > I don't see any ffffffff values. Your printf() probably isn't in the right place. pci_add_map() uses PCIB_READ_CONFIG() directly and doesn't use pci_read_config(), so if your printf is in pci_read_config_method() in pci.c it won't see them. Try hooking the cfg operations in sys/amd64/pci/pci_cfgreg.c instead. -- John Baldwin From jhb at freebsd.org Mon Apr 13 10:55:26 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Apr 13 11:17:30 2009 Subject: FreeBSD memguard + spinlocks In-Reply-To: References: Message-ID: <200904131253.37019.jhb@freebsd.org> On Saturday 11 April 2009 5:03:58 pm Andrew Brampton wrote: > 2009/4/11 Robert Watson : > > On Sat, 11 Apr 2009, Andrew Brampton wrote: > > > > Your understanding is mostly right. ?The missing bit is this: there are two > > kinds of interrupt contexts -- fast/filter interrupt handlers, which borrow > > the stack and execution context of the kernel thread they preempt, and > > interrupt threads, which get their own complete thread context. > > > > Fast interrupt handlers are allowed unlock to acquire spinlocks so as to > > avoid deadlock because of the borrowed context. ?This means they can't > > perform any sort of sleep, or acquire any locks that might sleep, since the > > thread they've preempted may hold conflicting locks, or be the one that > > would have woken up the sleep that the handler performed. ?Almost no code > > will run in fast handlers -- perhaps checking some device registers, doing > > work on a lockless or spinlock-protected queue, and waking up a worker > > thread. > > > > This is why, BTW, spin locks disable interrupt: they need to control > > preemption by other interrupt handlers to avoid deadlock, but they are not > > intended for use except when either in the scheduler, in a few related IPI > > contexts, or when synchronizing between normal kernel code and a fast > > handler. > > > > Full interrupt thread contexts are permitted to perform short lock sleeps, > > such as those performed when contending default mutexes, rwlocks, and > > rmlocks. They are permitted to invoke kernel services such as malloc(9), > > UMA(9), the network stack, etc, as long as they use M_NOWAIT and don't > > invoke msleep(9) or similar unbounded sleeps -- again to avoid the > > possibility of deadlocks, since you don't want an interrupt thread sleeping > > waiting for an event that only it can satisfy. > > > > So the first question, really, is whether you are or mean to be using > > fast/filter interrupt handler. ?Device drivers will never call memory > > allocation, free, etc, from there, but will defer it to an ithread using the > > filter mechanism in 8.x, or to a task queue or other worker in 7.x and > > earlier. ?If you're using a regular INTR_MPSAFE ithread, you should be able > > to use only default mutexes (a single atomic operation if uncontended) > > without disabling interrupts, etc. > > > > Robert N M Watson > > Computer Laboratory > > University of Cambridge > > > > Anyway, that is why I also asked about a lighter weight spin lock > (perhaps similar to this one). I tempted to replace this custom > spinlock with the standard MTX_DEF, however I'm unsure of its impact. > The custom spin lock seems quick and light to acquire, and it does not > concern me that a interrupt can potentially interrupt the code. You should just use a MTX_DEF mutex. Also, if you use M_NOWAIT, you will need to handle malloc() returning NULL. In general I try to allocate things while not holding any locks when possible and only acquire the lock to initialize the memory returned from malloc(). -- John Baldwin From avg at icyb.net.ua Tue Apr 14 03:23:47 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Apr 14 04:02:03 2009 Subject: smart self-test vs 7200.12/ich9r/ahci In-Reply-To: <49E35F92.6080400@icyb.net.ua> References: <49DDF710.4050004@icyb.net.ua> <1239562968.11309.1.camel@localhost.localdomain> <49E2E47D.5070402@icyb.net.ua> <1239637734.24831.56.camel@localhost.localdomain> <49E35F92.6080400@icyb.net.ua> Message-ID: <49E46425.9070205@icyb.net.ua> on 13/04/2009 18:51 Andriy Gapon said the following: > on 13/04/2009 18:48 Sean Bruno said the following: >> The "self-test" never goes beyond "90%" complete? > > Yes, exactly. Even for the short one, which is supposed to complete in 1 > minute: Another data point. This disk was in an experimental 3-way mirror zpool, two other devices were Hitachi HDP725050GLA360 and WDC WD5000AAKS-00A7B2. Self-tests were scheduled at the same time for all 3 disks in smartd.conf. The Hitachi and Western Digital disks were able to complete the tests before start of a work day, but the Seagate disk was stuck at 90%. Now I removed it from the mirror (designated it as a hot-spare) and now the self-tests work as expected for it. Makes me wonder: what was that access pattern that prevented self-test progress of the Seagate disk but did not affect the other two. -- Andriy Gapon From tijl at ulyssis.org Tue Apr 14 08:28:40 2009 From: tijl at ulyssis.org (Tijl Coosemans) Date: Tue Apr 14 09:04:51 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <1239388293.1922.80.camel@balrog.2hip.net> References: <20090410132354.GA20721@logik.internal.network> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> Message-ID: <200904141728.36178.tijl@ulyssis.org> On Friday 10 April 2009 20:31:33 Robert Noland wrote: > On Fri, 2009-04-10 at 18:59 +0100, xorquewasp@googlemail.com wrote: >> The system doesn't seem to have frozen since DRI/DRM was disabled. >> >> I did have one crash/reboot whilst building a large number of >> packages with tinderbox. I've currently got both tinderbox and a >> make -j 16 buildworld going on a loop in the hope that I can trigger >> it again. >> >> Being the idiot I am, I had encrypted swap enabled and so savecore >> didn't save anything. Won't make that mistake twice. >> >> I'm currently using a world compiled WITH_DEBUG but is there >> anything else I can do? > > If it is locking the whole system, then a core is really our best > shot. If you can extract anything useful from xorg.log or setting > hw.dri.0.debug that also might be of use. > > I'm running on 2 cores, but it is possible that some locking issue > exists. All of the driver specific ioctls are run under a lock > though. I have the same problem with a Radeon Mobility 9700 (r300) on 7-STABLE. The entire system freezes, but it happens very rarely. I took a quick look at the drm code for locking issues and found one thing that seems suspicious. Patch attached. I'm not familiar with the code, so I don't know if it's correct or even related this problem. -------------- next part -------------- --- sys/dev/drm/drm_bufs.c.orig 2009-04-11 15:10:56.000000000 +0200 +++ sys/dev/drm/drm_bufs.c 2009-04-11 15:11:33.000000000 +0200 @@ -173,7 +173,6 @@ /* Prevent a 2nd X Server from creating a 2nd lock */ DRM_LOCK(); if (dev->lock.hw_lock != NULL) { - DRM_UNLOCK(); free(map->handle, DRM_MEM_MAPS); free(map, DRM_MEM_MAPS); return EBUSY; From Gabor at Zahemszky.HU Tue Apr 14 11:05:29 2009 From: Gabor at Zahemszky.HU (Zahemszky =?ISO-8859-2?Q?G=E1bor?=) Date: Tue Apr 14 12:41:17 2009 Subject: Linux setpci equivalent in FreeBSD? Message-ID: <20090414192250.5b66db8c@Picasso.Zahemszky.HU> Hi! I'v found (well, mav@ found it) on a wiki page (*) a trick to use some TI sdhci cards. They use the setpci command, to set some bits in the HW. Are there any tool under FreeBSD to do the same? Thanks, G?bor at Zahemszky dot HU (*) http://www.gentoo-wiki.info/Acer_Ferrari_4005WLMi#SDHCI -- #!/bin/ksh Z='21N16I25C25E30, 40M30E33E25T15U!'; IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ '; set -- $Z;for i;{ [[ $i = ? ]]&&print $i&&break; [[ $i = ??? ]]&&j=$i&&i=${i%?}; typeset -i40 i=8#$i;print -n ${i#???}; [[ "$j" = ??? ]]&&print -n "${j#??} "&&j=;typeset +i i;}; IFS=' 0123456789 ';set -- $Z;for i;{ [[ $i = , ]]&&i=2; [[ $i = ?? ]]||typeset -l i;j="$j $i";typeset +l i;};print "$j" From bruce at cran.org.uk Tue Apr 14 12:46:11 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Tue Apr 14 13:20:35 2009 Subject: Linux setpci equivalent in FreeBSD? In-Reply-To: <20090414192250.5b66db8c@Picasso.Zahemszky.HU> References: <20090414192250.5b66db8c@Picasso.Zahemszky.HU> Message-ID: <20090414204605.641bb3a8@gluon.draftnet> On Tue, 14 Apr 2009 19:22:50 +0200 Zahemszky G?bor wrote: > Hi! > > I'v found (well, mav@ found it) on a wiki page (*) a trick to use > some TI sdhci cards. They use the setpci command, to set some bits in > the HW. Are there any tool under FreeBSD to do the same? pciconf(8) ? -- Bruce Cran From kmacy at freebsd.org Tue Apr 14 13:28:23 2009 From: kmacy at freebsd.org (Kip Macy) Date: Tue Apr 14 14:11:56 2009 Subject: Linux setpci equivalent in FreeBSD? In-Reply-To: <20090414192250.5b66db8c@Picasso.Zahemszky.HU> References: <20090414192250.5b66db8c@Picasso.Zahemszky.HU> Message-ID: <3c1674c90904141302l7dc5b77fub7db44f01f690f5d@mail.gmail.com> man pciconf(8) - it lets you set config space bits -Kip 2009/4/14 Zahemszky G?bor : > Hi! > > I'v found (well, mav@ found it) on a wiki page ?(*) a trick to use some > TI sdhci cards. They use the setpci command, to set some bits in the HW. > Are there any tool under FreeBSD to do the same? > > Thanks, > > G?bor at Zahemszky dot HU > > (*) http://www.gentoo-wiki.info/Acer_Ferrari_4005WLMi#SDHCI > > -- > #!/bin/ksh > Z='21N16I25C25E30, 40M30E33E25T15U!'; > IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ '; > set -- $Z;for i;{ [[ $i = ? ]]&&print $i&&break; > [[ $i = ??? ]]&&j=$i&&i=${i%?}; > typeset -i40 i=8#$i;print -n ${i#???}; > [[ "$j" = ??? ]]&&print -n "${j#??} "&&j=;typeset +i i;}; > IFS=' 0123456789 ';set -- $Z;for i;{ [[ $i = , ]]&&i=2; > [[ $i = ?? ]]||typeset -l i;j="$j $i";typeset +l i;};print "$j" > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke From julian at elischer.org Tue Apr 14 15:23:33 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Apr 14 15:52:52 2009 Subject: Linux setpci equivalent in FreeBSD? In-Reply-To: <20090414192250.5b66db8c@Picasso.Zahemszky.HU> References: <20090414192250.5b66db8c@Picasso.Zahemszky.HU> Message-ID: <49E50A30.8090403@elischer.org> Zahemszky G?bor wrote: > Hi! > > I'v found (well, mav@ found it) on a wiki page (*) a trick to use some > TI sdhci cards. They use the setpci command, to set some bits in the HW. > Are there any tool under FreeBSD to do the same? I think pciconf can do that.. > > Thanks, > > G?bor at Zahemszky dot HU > > (*) http://www.gentoo-wiki.info/Acer_Ferrari_4005WLMi#SDHCI > CONFIDENTIAL This document and attachments contain information from Fusion-io, Inc. which is confidential and/or legally privileged. The information is intended only for the use of the individual or entity named on this transmission. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking of any action in reliance on the contents of this emailed information is strictly prohibited, and that the documents should be returned to Fusion-io, Inc. immediately. In this regard, if you have received this email in error, please notify us by return email immediately. From babkin at verizon.net Tue Apr 14 17:36:52 2009 From: babkin at verizon.net (Sergey Babkin) Date: Tue Apr 14 18:56:35 2009 Subject: Patch for MS Hyper V (virtualization) References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904070921.14294.jhb@freebsd.org> <49DBFA72.9E64AB4F@verizon.net> <200904131256.44692.jhb@freebsd.org> Message-ID: <49E52E7B.34792757@verizon.net> John Baldwin wrote: > > On Tuesday 07 April 2009 9:14:26 pm Sergey Babkin wrote: > > John Baldwin wrote: > > > > > > On Monday 06 April 2009 11:12:33 pm Sergey Babkin wrote: > > > > > > Anyway, as far as I can tell, it's only the base register of > > > > the simulated DEC21140 device that has this issue, so it's > > > > quite possible that the bug is in that device's simulator. > > > > > > > > I've attached a modified patch that checks conservatively for this > > > > precise situation, so it should not break compatibility with > > > > anything else. I've tested it on Hyper-V. > > > > > > Can you test unmodified FreeBSD 8 on Hyper-V? It has an extra fix > relative to > > > 7 to disable decoding via the PCI command register while sizing BARs that > may > > > address this. > > > > 8.0 (February snapshot) seems to have the same issue. > > Ok. > > > I've also saved the log of writes that 7.1 does for this device: > > > > reg 10 val ec01 > > reg 14 val febff000 > > reg 18 val 0 > > reg 1c val 0 > > reg 20 val 0 > > reg 24 val 0 > > reg 30 val febe0000 > > reg 4 val 117 > > reg 3c val b > > reg 3d val 1 > > reg 3e val 14 > > reg 3f val 28 > > reg c val 8 > > reg d val 40 > > reg 9 val 0 > > reg 8 val 20 > > reg 10 val ec00 > > reg 14 val febff000 > > reg 4 val 117 > > reg 4 val 117 > > > > I don't see any ffffffff values. > > Your printf() probably isn't in the right place. pci_add_map() uses > PCIB_READ_CONFIG() directly and doesn't use pci_read_config(), so if your > printf is in pci_read_config_method() in pci.c it won't see them. Try > hooking the cfg operations in sys/amd64/pci/pci_cfgreg.c instead. The printf was in pci_write_config(). -SB From kheuer2 at gwdg.de Wed Apr 15 02:42:29 2009 From: kheuer2 at gwdg.de (Konrad Heuer) Date: Wed Apr 15 03:03:04 2009 Subject: Problem: FreeBSD 7.x && ssh v2 && nss_ldap Message-ID: <20090415102209.T34961@gwdu60.gwdg.de> I see a problem on two systems running FreeBSD 7.0 or 7.1 which are configured as OpenLDAP clients using the nss_ldap module. When someone logs on using ssh protocol version 2 the session will not be initialized correctly. The user will only get his primary group affiliation but no affiliation to other groups (memberUid attribute in LDAP group entries). On 7.1 the ssh login process hangs forever with open ldap queries, on 7.0 the group list is incomplete. On several 6.x systems, all works correctly. I have used the configuration for years now. There are some workarounds I found: a) use ssh protocol version 1 b) set UseLogin to yes in sshd_config c) avoid ssl encryption in communication to ldap server (ldap://... uri instead of ldaps://... in ldap.conf) Does anybody see similar problems? Does anybody have an idea what may couse the problem? Best regards Konrad Heuer GWDG, Am Fassberg, 37077 Goettingen, Germany, kheuer2@gwdg.de From jhb at freebsd.org Wed Apr 15 05:38:51 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Apr 15 05:57:39 2009 Subject: Patch for MS Hyper V (virtualization) In-Reply-To: <49E52E7B.34792757@verizon.net> References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904131256.44692.jhb@freebsd.org> <49E52E7B.34792757@verizon.net> Message-ID: <200904150834.35880.jhb@freebsd.org> On Tuesday 14 April 2009 8:46:51 pm Sergey Babkin wrote: > John Baldwin wrote: > > Your printf() probably isn't in the right place. pci_add_map() uses > > PCIB_READ_CONFIG() directly and doesn't use pci_read_config(), so if your > > printf is in pci_read_config_method() in pci.c it won't see them. Try > > hooking the cfg operations in sys/amd64/pci/pci_cfgreg.c instead. > > The printf was in pci_write_config(). Yes, that won't catch the PCIB_WRITE_CONFIG()'s in pci_add_map(). -- John Baldwin From avg at icyb.net.ua Wed Apr 15 07:17:45 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Apr 15 08:02:31 2009 Subject: ac97 interface q Message-ID: <49E5EC84.1080800@icyb.net.ua> ac97_if.m defines 'read' method to return int and 'write' method to take u_int32_t data and return int. Calls to AC97_READ and AC97_WRITE are present only in ac97.c and from those calls it is evident that the calling code expects u_int16_t from 'read' and it also passes u_int16_t to 'write', return value of 'write' is discarded. Seems like the interface is richer than what its caller actually uses. And it seems that implementations of the interface do not always have the exact signature - they have the same number of parameters, but the types are varying. Some implementations are closer to the interface contract, e.g. returning -1 from 'read' in case of error. Some are closer to the caller's expectations, e.g. having void return type in 'write'. What are your opinions - should the calling code be enhanced to use the interface properly (i.e. attempt to detect error conditions) or should the interface be dumbed down to its caller's expectations? My ultimate goal is to make all implementations have exactly the signature mandated by the interface. -- Andriy Gapon From xorquewasp at googlemail.com Wed Apr 15 11:29:05 2009 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Wed Apr 15 12:00:57 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <1239478606.1932.13.camel@balrog.2hip.net> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090411102300.GD83697@logik.internal.network> <1239477075.1932.5.camel@balrog.2hip.net> <20090411193054.GF83697@logik.internal.network> <1239478606.1932.13.camel@balrog.2hip.net> Message-ID: <20090415182859.GE82338@logik.internal.network> Hello. Just to let everyone know, I'm now coming to the conclusion that I may be suffering from hardware/thermal problems and that the DRI driver wasn't actually at fault (but highlighted the problem by pushing the hardware... harder). Thanks for the assistance, though. xw From ben at b1c1l1.com Wed Apr 15 12:32:54 2009 From: ben at b1c1l1.com (Benjamin Lee) Date: Wed Apr 15 13:54:57 2009 Subject: Problem: FreeBSD 7.x && ssh v2 && nss_ldap In-Reply-To: <20090415102209.T34961@gwdu60.gwdg.de> References: <20090415102209.T34961@gwdu60.gwdg.de> Message-ID: <49E63228.3090409@b1c1l1.com> On 04/15/2009 01:33 AM, Konrad Heuer wrote: > > I see a problem on two systems running FreeBSD 7.0 or 7.1 which are > configured as OpenLDAP clients using the nss_ldap module. > > When someone logs on using ssh protocol version 2 the session will not > be initialized correctly. The user will only get his primary group > affiliation but no affiliation to other groups (memberUid attribute in > LDAP group entries). > > On 7.1 the ssh login process hangs forever with open ldap queries, on > 7.0 the group list is incomplete. On several 6.x systems, all works > correctly. > I have used the configuration for years now. > > There are some workarounds I found: > > a) use ssh protocol version 1 > b) set UseLogin to yes in sshd_config > c) avoid ssl encryption in communication to ldap server > (ldap://... uri instead of ldaps://... in ldap.conf) > > Does anybody see similar problems? Does anybody have an idea what may > couse the problem? I recently submitted ports/133501 regarding this issue, but I have not yet received a response. My workaround was to disable pthread_atfork support, so the problem might be related to the change from libkse to libthr in RELENG_7. -- Benjamin Lee http://www.b1c1l1.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090415/a056767e/signature.pgp From uspoerlein at gmail.com Thu Apr 16 08:23:11 2009 From: uspoerlein at gmail.com (Ulrich =?utf-8?B?U3DDtnJsZWlu?=) Date: Thu Apr 16 09:12:42 2009 Subject: Problem: FreeBSD 7.x && ssh v2 && nss_ldap In-Reply-To: <49E63228.3090409@b1c1l1.com> References: <20090415102209.T34961@gwdu60.gwdg.de> <49E63228.3090409@b1c1l1.com> Message-ID: <20090416151740.GB5002@roadrunner.spoerlein.net> On Wed, 15.04.2009 at 12:14:48 -0700, Benjamin Lee wrote: > On 04/15/2009 01:33 AM, Konrad Heuer wrote: > > > > I see a problem on two systems running FreeBSD 7.0 or 7.1 which are > > configured as OpenLDAP clients using the nss_ldap module. > > > > When someone logs on using ssh protocol version 2 the session will not > > be initialized correctly. The user will only get his primary group > > affiliation but no affiliation to other groups (memberUid attribute in > > LDAP group entries). > > > > On 7.1 the ssh login process hangs forever with open ldap queries, on > > 7.0 the group list is incomplete. On several 6.x systems, all works > > correctly. > > I have used the configuration for years now. > > > > There are some workarounds I found: > > > > a) use ssh protocol version 1 > > b) set UseLogin to yes in sshd_config > > c) avoid ssl encryption in communication to ldap server > > (ldap://... uri instead of ldaps://... in ldap.conf) > > > > Does anybody see similar problems? Does anybody have an idea what may > > couse the problem? > > I recently submitted ports/133501 regarding this issue, but I have not > yet received a response. > > My workaround was to disable pthread_atfork support, so the problem > might be related to the change from libkse to libthr in RELENG_7. I tried your patch to see if it made any change for the nss_ldap UNIX socket leak, but sadly no change. I never observed the SSH2 problems you guys mention, but then again I'm usually using key authentication. I'll run with the patch anyway and see if it makes any change to the problem where login(1) is only able to authenticate me after 30s of idling. Cheers, Ulrich Sp?rlein -- None are more hopelessly enslaved than those who falsely believe they are free -- Johann Wolfgang von Goethe From deeptech71 at gmail.com Thu Apr 16 08:33:41 2009 From: deeptech71 at gmail.com (deeptech71@gmail.com) Date: Thu Apr 16 09:23:35 2009 Subject: diagnosing freezes (DRI?) Message-ID: <49E74917.808@gmail.com> I can reliably (~40%) reproduce a freeze, which I think is related. Using the GENERIC debug kernel built from SVN HEAD: # cd /usr/obj/usr/src/sys/GENERIC/ # kgdb kernel.debug /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: <118>Apr 16 04:22:24 syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Wai tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o cess `syncer' to stop...0 done All buffers synced. Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0 r191101: Wed Apr 15 17:29:58 UTC 2009 devhc@:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.67-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400 Logical CPUs per core: 2 real memory = 536870912 (512 MB) avail memory = 506023936 (482 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 1fef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xd000-0xd0ff mem 0xd0000000-0xdfffffff,0xfbee0000-0xfbeeffff irq 16 at device 0.0 on pci1 vgapci1: mem 0xe0000000-0xefffffff,0xfbef0000-0xfbefffff at device 0.1 on pci1 uhci0: port 0xc880-0xc89f irq 16 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2030 usbus0: on uhci0 uhci1: port 0xcc00-0xcc1f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2030 usbus1: on uhci1 ehci0: mem 0xfbdffc00-0xfbdfffff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 pcib2: at device 30.0 on pci0 pci2: on pcib2 skc0: <3Com 3C940 Gigabit Ethernet> port 0xe800-0xe8ff mem 0xfbffc000-0xfbffffff irq 22 at device 5.0 on pci2 skc0: 3Com Gigabit LOM (3C940) rev. (0x1) sk0: on skc0 sk0: Ethernet address: 00:0e:a6:35:15:91 miibus0: on sk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto skc0: [ITHREAD] pcm0: port 0xec00-0xec3f irq 20 at device 12.0 on pci2 pcm0: pcm0: [ITHREAD] pcm0: isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 cpu0: on acpi0 p4tcc0: on cpu0 cpu1: on acpi0 p4tcc1: on cpu1 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xccfff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ad0: 78167MB at ata0-master UDMA100 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 acd0: DMA limited to UDMA33, controller found non-ATA66 cable GEOM: ad0s1: geometry does not match label (255h,63s != 16h,63s). acd0: DVDR at ata1-master UDMA33 SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. GEOM_LABEL: Label for provider ad0s2 is msdosfs/WINXP. GEOM_LABEL: Label for provider ad0s3 is ntfs/STORAGE. GEOM_LABEL: Label for provider ad0s1a is ufsid/49cf0dead38cbdfd. Root mount waiting for: usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 uhub2: 4 ports with 4 removable, self powered Root mount waiting for: usbus2 Trying to mount root from ufs:/dev/ad0s1a <118>Entropy harvesting: <118> interrupts <118> ethernet <118> point_to_point <118> kickstart <118>. GEOM_LABEL: Label ufsid/49cf0dead38cbdfd removed. <118>/dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ad0s1a: clean, 576271 free (53999 frags, 65284 blocks, 1.3% fragmentation) GEOM_LABEL: Label for provider ad0s1a is ufsid/49cf0dead38cbdfd. ugen0.2: at usbus0 GEOM_LABEL: Label ufsid/49cf0dead38cbdfd removed. ums0: on usbus0 ums0: 5 buttons and [XYZ] coordinates ID=1 GEOM_LABEL: Label msdosfs/WINXP removed. <118>/etc/rc: WARNING: $hostname is not set -- see rc.conf(5). <118>Starting Network: sk0. <118>Starting Network: lo0. <118>Apr 16 04:23:08 syslogd: bind: Can't assign requested address <118>Apr 16 04:23:08 syslogd: bind: Can't assign requested address <118>syslogd: <118>child pid 546 exited with return code 1 <118> <118>/etc/rc: WARNING: failed to start syslogd <118>moused: <118>unable to open /dev/psm0: No such file or directory <118> <118>/etc/rc: WARNING: $dbus_enable is not set properly - see rc.conf(5). <118>Starting dbus. <118>Starting hald. <118>Configuring syscons: <118> blanktime <118>. <118> <118>Thu Apr 16 04:23:10 UTC 2009 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xf0000000 128MB info: [drm] Initialized radeon 1.29.0 20080528 info: [drm] Setting GART location based on new memory map info: [drm] Loading R300 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] lock order reversal: 1st 0xc31a5270 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2549 2nd 0xc39a3400 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:275 KDB: stack backtrace: db_trace_self_wrapper(c0c2ebcc,d644b860,c0896895,c088879b,c0c319b1,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c088879b,c0c319b1,c3524a80,c3527e18,d644b8bc,...) at kdb_backtrace+0x29 _witness_debugger(c0c319b1,c39a3400,c0c50e61,c3527e18,c0c50afa,...) at _witness_debugger+0x25 witness_checkorder(c39a3400,9,c0c50afa,113,0,...) at witness_checkorder+0x839 _sx_xlock(c39a3400,0,c0c50afa,113,c3b4c7c0,...) at _sx_xlock+0x85 ufsdirhash_acquire(c31a5210,d644b9d4,128,cec0baf0,d644b98c,...) at ufsdirhash_acquire+0x35 ufsdirhash_add(c3b4c7c0,d644b9d4,af0,d644b978,d644b97c,...) at ufsdirhash_add+0x13 ufs_direnter(c3b5ca78,c3df4860,d644b9d4,d644bbe0,0,...) at ufs_direnter+0x729 ufs_makeinode(d644bbe0,d644bb4c,d644bc04,d644bb1c,c0b70e35,...) at ufs_makeinode+0x519 ufs_create(d644bc04,d644bc18,0,d644bb4c,d644bbb4,...) at ufs_create+0x30 VOP_CREATE_APV(c0d2fc20,d644bc04,68,1a4,c39a1aac,...) at VOP_CREATE_APV+0xa5 uipc_bind(c3dc3000,c3741b00,c3c80230,d644bc60,c08c0049,...) at uipc_bind+0x30e sobind(c3dc3000,c3741b00,c3c80230,1a,c38d5658,...) at sobind+0x23 kern_bind(c3c80230,3,c3741b00,c3741b00,80906a4,...) at kern_bind+0x79 bind(c3c80230,d644bcf8,c,c0c321f2,c0d0ed20,...) at bind+0x46 syscall(d644bd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (104, FreeBSD ELF32, bind), eip = 0x2818a983, esp = 0xbfbfe96c, ebp = 0xbfbfea68 --- <118>Apr 16 04:24:28 su: devhc to root on /dev/pts/1 Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex drmdev (drmdev) r = 0 (0xc373f860) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:777 KDB: stack backtrace: db_trace_self_wrapper(c0c2ebcc,d67d4980,c0896895,c3d40457,309,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c3d40457,309,ffffffff,c0eba8c4,d67d49b8,...) at kdb_backtrace+0x29 _witness_debugger(c0c30f5d,d67d49cc,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0c62807,0,c42087ec,...) at witness_warn+0x1fd trap(d67d4a58) at trap+0x152 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc0b611b6, esp = 0xd67d4a98, ebp = 0xd67d4b48 --- slow_copyin(c373f800,c4103300,c42e64e0,d67d4b64,0,...) at slow_copyin+0x6 radeon_cp_texture(c373f800,c42e64e0,c4103300,309,c0c26218,...) at radeon_cp_texture+0x199 drm_ioctl(c39d4e00,c018644e,c42e64e0,3,c40afaf0,...) at drm_ioctl+0x356 devfs_ioctl_f(c38c7150,c018644e,c42e64e0,c38d4700,c40afaf0,...) at devfs_ioctl_f+0xf8 kern_ioctl(c40afaf0,24,c018644e,c42e64e0,18901f0,...) at kern_ioctl+0x1dd ioctl(c40afaf0,d67d4cf8,c,c0c65279,c0d0e870,...) at ioctl+0x134 syscall(d67d4d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2834ec67, esp = 0xbfbf944c, ebp = 0xbfbf9468 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x3f561000 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0b611b6 stack pointer = 0x28:0xd67d4a98 frame pointer = 0x28:0xd67d4b48 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1094 (initial thread) trap number = 12 panic: page fault cpuid = 0 Uptime: 4m53s Physical memory: 494 MB Dumping 107 MB: 92 76 60 44 28 12 Reading symbols from /boot/kernel.GENERIC.r191101.debug/snd_es137x.ko...Reading symbols from /boot/kernel.GENERIC.r191101.debug/snd_es137x.ko.symbols...done. done. Loaded symbols for /boot/kernel.GENERIC.r191101.debug/snd_es137x.ko Reading symbols from /boot/kernel.GENERIC.r191101.debug/sound.ko...Reading symbols from /boot/kernel.GENERIC.r191101.debug/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel.GENERIC.r191101.debug/sound.ko Reading symbols from /boot/kernel.GENERIC.r191101.debug/radeon.ko...Reading symbols from /boot/kernel.GENERIC.r191101.debug/radeon.ko.symbols...done. done. Loaded symbols for /boot/kernel.GENERIC.r191101.debug/radeon.ko Reading symbols from /boot/kernel.GENERIC.r191101.debug/drm.ko...Reading symbols from /boot/kernel.GENERIC.r191101.debug/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel.GENERIC.r191101.debug/drm.ko #0 doadump () at pcpu.h:246 246 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:246 #1 0xc085712e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xc0857402 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc0b63323 in trap_fatal (frame=0xd67d4a58, eva=1062604800) at /usr/src/sys/i386/i386/trap.c:926 #4 0xc0b63c20 in trap (frame=0xd67d4a58) at /usr/src/sys/i386/i386/trap.c:318 #5 0xc0b47b5b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #6 0xc0b611b6 in slow_copyin () at /usr/src/sys/i386/i386/support.s:887 Previous frame inner to this frame (corrupt stack?) (kgdb) list *0xc0b611b6 0xc0b611b6 is at /usr/src/sys/i386/i386/support.s:888. 883 slow_copyin: 884 #endif 885 movb %cl,%al 886 shrl $2,%ecx /* copy longword-wise */ 887 cld 888 rep 889 movsl 890 movb %al,%cl 891 andb $3,%cl /* copy remaining bytes*/ 892 rep (kgdb) OMG, ASM! I don't what this assembly code means or how to debug it. So what now? I can run commands on request. Or should I package the whole vmcore & kernel and upload/send it somewhere for inspection (tell me exactly which files)? 3 more things: The command ddb capture -M /var/crash/vmcore.0 print printed only a few ugly characters. This kernel output really looks bad: Wai tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o cess `syncer' to stop...0 done What's the explanation to: Previous frame inner to this frame (corrupt stack?) ? From gary.jennejohn at freenet.de Thu Apr 16 09:53:59 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Thu Apr 16 10:38:57 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <49E74917.808@gmail.com> References: <49E74917.808@gmail.com> Message-ID: <20090416185354.4fa01e02@ernst.jennejohn.org> On Thu, 16 Apr 2009 17:04:55 +0200 deeptech71@gmail.com wrote: [snip a whole bunch of stuff] > This kernel output really looks bad: > Wai > tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o > cess `syncer' to stop...0 done > I can't speak to the rest, but this is probably because you have SMP and don't have `options PRINTF_BUFR_SIZE=128' in your kernel config. --- Gary Jennejohn From kientzle at freebsd.org Thu Apr 16 10:47:57 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Thu Apr 16 11:26:40 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <20090416185354.4fa01e02@ernst.jennejohn.org> References: <49E74917.808@gmail.com> <20090416185354.4fa01e02@ernst.jennejohn.org> Message-ID: <49E76F4B.8010006@freebsd.org> Gary Jennejohn wrote: > deeptech71@gmail.com wrote: > >> This kernel output really looks bad: >> Wai >> tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o >> cess `syncer' to stop...0 done > > I can't speak to the rest, but this is probably because you have SMP and > don't have `options PRINTF_BUFR_SIZE=128' in your kernel config. Is there any reason this shouldn't be the default? This is becoming an increasingly common FAQ. Tim From dgerow at afflictions.org Thu Apr 16 12:04:51 2009 From: dgerow at afflictions.org (Damian Gerow) Date: Thu Apr 16 12:48:07 2009 Subject: Garbled kernel messages on shutdown In-Reply-To: <20090416185354.4fa01e02@ernst.jennejohn.org> References: <49E74917.808@gmail.com> <20090416185354.4fa01e02@ernst.jennejohn.org> Message-ID: <20090416181418.GA1186@plebeian.afflictions.org> Gary Jennejohn wrote: : [snip a whole bunch of stuff] : > This kernel output really looks bad: : > Wai : > tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o : > cess `syncer' to stop...0 done : > : : I can't speak to the rest, but this is probably because you have SMP and : don't have `options PRINTF_BUFR_SIZE=128' in your kernel config. Ah, so that's what causes that. Any particular reason GENERIC has SMP, but doesn't set PRINTF_BUFR_SIZE=128? From kostikbel at gmail.com Thu Apr 16 12:18:42 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Apr 16 13:05:11 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <49E76F4B.8010006@freebsd.org> References: <49E74917.808@gmail.com> <20090416185354.4fa01e02@ernst.jennejohn.org> <49E76F4B.8010006@freebsd.org> Message-ID: <20090416191836.GW3014@deviant.kiev.zoral.com.ua> On Thu, Apr 16, 2009 at 10:47:55AM -0700, Tim Kientzle wrote: > Gary Jennejohn wrote: > >deeptech71@gmail.com wrote: > > > >>This kernel output really looks bad: > >>Wai > >>tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o > >>cess `syncer' to stop...0 done > > > >I can't speak to the rest, but this is probably because you have SMP and > >don't have `options PRINTF_BUFR_SIZE=128' in your kernel config. > > Is there any reason this shouldn't be the default? > > This is becoming an increasingly common FAQ. The only reason I am aware of is that the buffer is allocated on the stack. 128 bytes is not so small for our kernel stacks. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090416/63bf2567/attachment.pgp From lars.engels at 0x20.net Thu Apr 16 06:11:18 2009 From: lars.engels at 0x20.net (Lars Engels) Date: Thu Apr 16 14:28:58 2009 Subject: Linux setpci equivalent in FreeBSD? In-Reply-To: <20090414192250.5b66db8c@Picasso.Zahemszky.HU> References: <20090414192250.5b66db8c@Picasso.Zahemszky.HU> Message-ID: <20090416151115.lx6i8g4dw8oscgww@0x20.net> Quoting Zahemszky G?bor : > Hi! > > I'v found (well, mav@ found it) on a wiki page (*) a trick to use some > TI sdhci cards. They use the setpci command, to set some bits in the HW. > Are there any tool under FreeBSD to do the same? > > Thanks, > > G?bor at Zahemszky dot HU > > (*) http://www.gentoo-wiki.info/Acer_Ferrari_4005WLMi#SDHCI You can use pciconf like this: pciconf -wb pci0:30:0 0x1a 9 (but don't just copy & paste this, it might hurt your hardware ;-) ) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: PGP Digital Signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090416/8b4fe5cb/attachment.pgp From kientzle at freebsd.org Thu Apr 16 14:38:49 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Thu Apr 16 15:24:07 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <20090416191836.GW3014@deviant.kiev.zoral.com.ua> References: <49E74917.808@gmail.com> <20090416185354.4fa01e02@ernst.jennejohn.org> <49E76F4B.8010006@freebsd.org> <20090416191836.GW3014@deviant.kiev.zoral.com.ua> Message-ID: <49E7A567.8050102@freebsd.org> Kostik Belousov wrote: > On Thu, Apr 16, 2009 at 10:47:55AM -0700, Tim Kientzle wrote: >> Gary Jennejohn wrote: >>> deeptech71@gmail.com wrote: >>> >>>> This kernel output really looks bad: >>>> Wai >>>> tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o >>>> cess `syncer' to stop...0 done >>> I can't speak to the rest, but this is probably because you have SMP and >>> don't have `options PRINTF_BUFR_SIZE=128' in your kernel config. >> Is there any reason this shouldn't be the default? > > The only reason I am aware of is that the buffer is allocated on the > stack. 128 bytes is not so small for our kernel stacks. How about 32? Anything larger than 1 would make it much easier to read these messages. Tim From guru at unixarea.de Fri Apr 17 01:13:33 2009 From: guru at unixarea.de (Matthias Apitz) Date: Fri Apr 17 01:51:28 2009 Subject: CURRENT sees only /dev/ad2s1a, but not /dev/ad3s1a In-Reply-To: <3a142e750904020806m4e7726d5w77bd34cb9eb3e5c4@mail.gmail.com> References: <20090327151052.GA13243@rebelion.Sisis.de> <3a142e750903270952h3ba5e28fp72b39283b2a46d97@mail.gmail.com> <20090402084357.GA5825@rebelion.Sisis.de> <3a142e750904020806m4e7726d5w77bd34cb9eb3e5c4@mail.gmail.com> Message-ID: <20090417081314.GA3094@rebelion.Sisis.de> El d?a Thursday, April 02, 2009 a las 05:06:53PM +0200, Paul B. Mahol escribi?: > On 4/2/09, Matthias Apitz wrote: > > El d?a Friday, March 27, 2009 a las 05:52:40PM +0100, Paul B. Mahol > > escribi?: > > > >> On 3/27/09, Matthias Apitz wrote: > >> > > >> > Hello, > >> > > >> > When I boot my EeePC from USB key (/dev/da0s1a) -CURRENT it sees the two > >> > SSD > >> > only > >> > as > >> > > >> > $ ls -l /dev/ad* > >> > /dev/ad2 > >> > /dev/ad2s1 > >> > /dev/ad2s1a > >> > /dev/ad3 > >> > /dev/ad3a > >> > > >> > I can mount /dev/ad2s1a but ofc not /dev/ad3s1a; > >> > > >> > when I'm booting the RELENG_7 from /dev/ad2s1a itself it looks like > >> > this: > >> > > >> > $ mount > >> > /dev/ad2s1a on / (ufs, local, noatime) > >> > /dev/ad3s1a on /usr/home (ufs, local, noatime) > >> > >> CURRENT have replaced geom_bsd with geom_part_bsd > >> and that can cause various problems, search current archives for more > >> info. > > > > When I will update the EeePC from USB key (/dev/da0s1a) to CURRENT I > > will install into /dev/ad2s1a (with make installworld/installkernel ...) > > and I want to keep the partition /dev/ad3s1a as it is; would it be > > enough to just do: > > > > # bsdlabel -w ad3s1 auto > > > > from CURRENT booted? > > When you do that, make backups anyway. > > I dont use bsdlabel/fdisk/sade any more, I use gpart(8) instead. I > actually wiped completely old crappy parttion table and replaced it > with gpart one, and now I'm using more than 8 labels. This is only to close this thread: Today morning I installed CURRENT into /dev/ad2s1a (without problems) and I've found no way to re-use the other old (RELENG_7) partition in the 2nd SSD /dev/ad3; I had to wipe it out to make fdisk happy: # dd if=/dev/zero of=/dev/ad3 count=2 # fdisk -I /dev/ad3 # newfs -m 0 -o space /dev/ad3s1a # echo "/dev/ad3s1a /usr/local ufs rw,noatime 1 1" >> /etc/fstab # mount /usr/local matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. From gary.jennejohn at freenet.de Fri Apr 17 04:02:48 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Fri Apr 17 04:48:02 2009 Subject: diagnosing freezes (DRI?) In-Reply-To: <20090416191836.GW3014@deviant.kiev.zoral.com.ua> References: <49E74917.808@gmail.com> <20090416185354.4fa01e02@ernst.jennejohn.org> <49E76F4B.8010006@freebsd.org> <20090416191836.GW3014@deviant.kiev.zoral.com.ua> Message-ID: <20090417130245.47c8fbe7@ernst.jennejohn.org> On Thu, 16 Apr 2009 22:18:36 +0300 Kostik Belousov wrote: > On Thu, Apr 16, 2009 at 10:47:55AM -0700, Tim Kientzle wrote: > > Gary Jennejohn wrote: > > >deeptech71@gmail.com wrote: > > > > > >>This kernel output really looks bad: > > >>Wai > > >>tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o > > >>cess `syncer' to stop...0 done > > > > > >I can't speak to the rest, but this is probably because you have SMP and > > >don't have `options PRINTF_BUFR_SIZE=128' in your kernel config. > > > > Is there any reason this shouldn't be the default? > > > > This is becoming an increasingly common FAQ. > > The only reason I am aware of is that the buffer is allocated on the > stack. 128 bytes is not so small for our kernel stacks. True, but it still seems like this could be put into GENERIC, commented out, with a good comment about stack size, so that users have a reasonable chance of finding out about it. --- Gary Jennejohn From bruce at cran.org.uk Fri Apr 17 05:04:33 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Fri Apr 17 05:45:32 2009 Subject: Garbled kernel messages on shutdown In-Reply-To: <20090416181418.GA1186@plebeian.afflictions.org> References: <49E74917.808@gmail.com> <20090416185354.4fa01e02@ernst.jennejohn.org> <20090416181418.GA1186@plebeian.afflictions.org> Message-ID: <20090417130426.68c41313@gluon.draftnet> On Thu, 16 Apr 2009 14:14:19 -0400 Damian Gerow wrote: > Gary Jennejohn wrote: > : [snip a whole bunch of stuff] > : > This kernel output really looks bad: > : > Wai > : > tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra > isnyisntge.m. .pr0o : > cess `syncer' to stop...0 done > : > > : > : I can't speak to the rest, but this is probably because you have > SMP and : don't have `options PRINTF_BUFR_SIZE=128' in your kernel > config. > > Ah, so that's what causes that. > > Any particular reason GENERIC has SMP, but doesn't set > PRINTF_BUFR_SIZE=128? I think from previous discussions there might be some concern about stack usage when it's enabled. -- Bruce Cran From dnelson at allantgroup.com Fri Apr 17 07:41:22 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Fri Apr 17 08:26:34 2009 Subject: Garbled kernel messages on shutdown In-Reply-To: <20090417130426.68c41313@gluon.draftnet> References: <49E74917.808@gmail.com> <20090416185354.4fa01e02@ernst.jennejohn.org> <20090416181418.GA1186@plebeian.afflictions.org> <20090417130426.68c41313@gluon.draftnet> Message-ID: <20090417144114.GI90152@dan.emsphone.com> In the last episode (Apr 17), Bruce Cran said: > On Thu, 16 Apr 2009 14:14:19 -0400 Damian Gerow wrote: > > Gary Jennejohn wrote: > > > [snip a whole bunch of stuff] > > > > This kernel output really looks bad: > > > > Wai > > > > tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomraisnyisntge.m. .pr0ocess `syncer' to stop...0 done > > > > > > I can't speak to the rest, but this is probably because you have SMP > > > and don't have `options PRINTF_BUFR_SIZE=128' in your kernel config. > > > > Ah, so that's what causes that. > > > > Any particular reason GENERIC has SMP, but doesn't set > > PRINTF_BUFR_SIZE=128? > > I think from previous discussions there might be some concern about > stack usage when it's enabled. I was going to ask if a mutex or other method could be used in the console driver somewhere to prevent interleaved writes (the same way two userland writes to a single fd aren't interleaved), but I looked at the kernel's kvprintf function, and it really does send a character at a time to its output callback function. Maybe a mutex can be added inside kvprintf if TOCONS is set in pca.flags? So instead of malloc'ing a buffer, just make the 2nd kvprintf call wait for the first to finish. -- Dan Nelson dnelson@allantgroup.com From manolis at FreeBSD.org Sat Apr 18 22:54:12 2009 From: manolis at FreeBSD.org (Manolis Kiagias) Date: Sat Apr 18 22:54:19 2009 Subject: Some questions on 'make release' Message-ID: <49EA549E.2060001@FreeBSD.org> Hey all, I've been experimenting recently with 'make release' and I have a couple of questions. A little background first: - I've read the releng, releng-packages articles (probably out of date) and the release man page - I've been able to successfully run a make release without packages using the following: # make release CHROOTDIR=/data/release BUILDNAME=7.2-PRERELEASE CVSROOT=/data/ncvs EXTSRCDIR=/usr/src -DNODOC -DNOPORTS -DNO_FLOPPIES -DMAKE_ISOS Currently /data/ncvs does not exist, I am using EXTSRCDIR to build the sources of my current system. This all works fine. Lately, I've been running builds of packages using ports-mgmt/tinderbox and I thought it would be nice to create complete customs CDs. But I can't seem to be able to convince make release to include these packages in the final ISOs. Now, according to the release man page, I have to set CD_PACKAGE_TREE to a directory with the packages, and I have to create this using make package-split. I have edited /usr/src/release/scripts/package-split.py to contain my list of packages. I have copied the ready packages from the build server to /data/allpackages and also copied the INDEX file (in sync with the packages). It also seems one has to run the mkpkgindex.sh which will trim the INDEX to only include the present packages. (Not sure whether I need to run mkpkghier - I already have the directories with the symbolic links). I would then run make package-split as follows: make package-split PKG_TREE=/data/allpackages PKG_DEST=/data/packages which works fine (BTW, PKG_TREE and PKG_DEST are not documented in man release). Packages are split according to spec. I tried with three discs and a single disc. I am currently trying a build with few packages that all fit on disc1. I would then run the build: # make release CHROOTDIR=/data/release BUILDNAME=7.2-PRERELEASE CVSROOT=/data/ncvs EXTSRCDIR=/usr/src CD_PACKAGE_TREE=/data/packages -DNODOC -DNOPORTS -DNO_FLOPPIES -DMAKE_ISOS which completes, without errors but without adding the packages to any CD or the DVD. I found out that I can add the packages after the build by running manually /usr/src/release/i386/mkisoimage.sh with appropriate arguments (and the resulting CD seems to work fine). But I can't seem to convince make release to do this. What am I doing wrong? Any pointers would be greatly appreciated. FWIW, I will also attempt to patch the releng or releng-packages article if I can get the right steps for this. Thanks for your time and apologies for the long post! From rdivacky at freebsd.org Mon Apr 20 08:59:57 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Mon Apr 20 09:00:04 2009 Subject: [PATCH]: today highlighting in [n]cal Message-ID: <20090420084118.GA16337@freebsd.org> hi I made this patch that highlights today in cal/ncal just like gnu cal does.. www.vlakno.cz/~rdivacky/cal.patch unless objected I plan to commit this soon (with fixes to style(9)) roman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090420/f878806f/attachment.pgp From corecode at fs.ei.tum.de Mon Apr 20 09:21:30 2009 From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert) Date: Mon Apr 20 09:21:38 2009 Subject: [PATCH]: today highlighting in [n]cal In-Reply-To: <20090420084118.GA16337@freebsd.org> References: <20090420084118.GA16337@freebsd.org> Message-ID: <49EC3E96.50208@fs.ei.tum.de> Hey Roman, Roman Divacky wrote: > I made this patch that highlights today in cal/ncal just like gnu > cal does.. > > www.vlakno.cz/~rdivacky/cal.patch Thanks for this patch, I've been meaning to hack one up properly, but never got to it. They problems I was facing seem to exist also with your patch: - only works for wide (cal) mode, not ncal mode - probably won't work properly with year displays: the year printing parts of the code use a length argument to printf ("%*s"), which will confuse escape sequences with actual printed characters cheers simon -- <3 the future +++ RENT this banner advert +++ ASCII Ribbon /"\ rock the past +++ space for low ??? NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ From rdivacky at freebsd.org Mon Apr 20 10:25:58 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Mon Apr 20 10:26:05 2009 Subject: [PATCH]: today highlighting in [n]cal In-Reply-To: <49EC3E96.50208@fs.ei.tum.de> References: <20090420084118.GA16337@freebsd.org> <49EC3E96.50208@fs.ei.tum.de> Message-ID: <20090420102432.GA29688@freebsd.org> On Mon, Apr 20, 2009 at 11:21:26AM +0200, Simon 'corecode' Schubert wrote: > Hey Roman, > > Roman Divacky wrote: > >I made this patch that highlights today in cal/ncal just like gnu > >cal does.. > > > > www.vlakno.cz/~rdivacky/cal.patch > > Thanks for this patch, I've been meaning to hack one up properly, but > never got to it. They problems I was facing seem to exist also with your > patch: > > - only works for wide (cal) mode, not ncal mode it works for ncal > - probably won't work properly with year displays: the year printing > parts of the code use a length argument to printf ("%*s"), which will > confuse escape sequences with actual printed characters I am not sure what you mean by year printing.... can you give me the exact command line? From rdivacky at freebsd.org Mon Apr 20 10:47:54 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Mon Apr 20 10:48:00 2009 Subject: [PATCH]: today highlighting in [n]cal In-Reply-To: <20090420102432.GA29688@freebsd.org> References: <20090420084118.GA16337@freebsd.org> <49EC3E96.50208@fs.ei.tum.de> <20090420102432.GA29688@freebsd.org> Message-ID: <20090420104629.GA32678@freebsd.org> On Mon, Apr 20, 2009 at 12:24:32PM +0200, Roman Divacky wrote: > On Mon, Apr 20, 2009 at 11:21:26AM +0200, Simon 'corecode' Schubert wrote: > > Hey Roman, > > > > Roman Divacky wrote: > > >I made this patch that highlights today in cal/ncal just like gnu > > >cal does.. > > > > > > www.vlakno.cz/~rdivacky/cal.patch > > > > Thanks for this patch, I've been meaning to hack one up properly, but > > never got to it. They problems I was facing seem to exist also with your > > patch: > > > > - only works for wide (cal) mode, not ncal mode > > it works for ncal oh.. it doesnt... I was under the impression that it does... I'll take a look at it From corecode at fs.ei.tum.de Mon Apr 20 11:54:00 2009 From: corecode at fs.ei.tum.de (Simon 'corecode' Schubert) Date: Mon Apr 20 11:54:07 2009 Subject: [PATCH]: today highlighting in [n]cal In-Reply-To: <20090420102432.GA29688@freebsd.org> References: <20090420084118.GA16337@freebsd.org> <49EC3E96.50208@fs.ei.tum.de> <20090420102432.GA29688@freebsd.org> Message-ID: <49EC6254.5050705@fs.ei.tum.de> Roman Divacky wrote: > On Mon, Apr 20, 2009 at 11:21:26AM +0200, Simon 'corecode' Schubert wrote: >> Hey Roman, >> >> Roman Divacky wrote: >>> I made this patch that highlights today in cal/ncal just like gnu >>> cal does.. >>> >>> www.vlakno.cz/~rdivacky/cal.patch >> Thanks for this patch, I've been meaning to hack one up properly, but >> never got to it. They problems I was facing seem to exist also with your >> patch: >> >> - only works for wide (cal) mode, not ncal mode > > it works for ncal I didn't try it on FreeBSD, but from inspecting the code, you only modified mkmonthb(), which is called for the cal-style layout, but not for the ncal-style layout (then mkmonth() is called). >> - probably won't work properly with year displays: the year printing >> parts of the code use a length argument to printf ("%*s"), which will >> confuse escape sequences with actual printed characters > > I am not sure what you mean by year printing.... can you give me the > exact command line? just try "cal 2009" or so, basically use printyear[b]. cheers simon -- <3 the future +++ RENT this banner advert +++ ASCII Ribbon /"\ rock the past +++ space for low ??? NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ From rdivacky at freebsd.org Mon Apr 20 11:55:34 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Mon Apr 20 11:55:41 2009 Subject: [PATCH]: today highlighting in [n]cal In-Reply-To: <49EC6254.5050705@fs.ei.tum.de> References: <20090420084118.GA16337@freebsd.org> <49EC3E96.50208@fs.ei.tum.de> <20090420102432.GA29688@freebsd.org> <49EC6254.5050705@fs.ei.tum.de> Message-ID: <20090420115417.GA41159@freebsd.org> On Mon, Apr 20, 2009 at 01:53:56PM +0200, Simon 'corecode' Schubert wrote: > Roman Divacky wrote: > >On Mon, Apr 20, 2009 at 11:21:26AM +0200, Simon 'corecode' Schubert wrote: > >>Hey Roman, > >> > >>Roman Divacky wrote: > >>>I made this patch that highlights today in cal/ncal just like gnu > >>>cal does.. > >>> > >>> www.vlakno.cz/~rdivacky/cal.patch > >>Thanks for this patch, I've been meaning to hack one up properly, but > >>never got to it. They problems I was facing seem to exist also with your > >>patch: > >> > >>- only works for wide (cal) mode, not ncal mode > > > >it works for ncal > > I didn't try it on FreeBSD, but from inspecting the code, you only > modified mkmonthb(), which is called for the cal-style layout, but not for > the ncal-style layout (then mkmonth() is called). yes... and if I read the code correctly the very same approach should work for the mkmonth() as well.. it should be copy'n'paste > >>- probably won't work properly with year displays: the year printing > >>parts of the code use a length argument to printf ("%*s"), which will > >>confuse escape sequences with actual printed characters > > > >I am not sure what you mean by year printing.... can you give me the > >exact command line? > > just try "cal 2009" or so, basically use printyear[b]. this works From rdivacky at freebsd.org Mon Apr 20 14:03:36 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Mon Apr 20 14:03:43 2009 Subject: [PATCH]: today highlighting in [n]cal In-Reply-To: <49EC3E96.50208@fs.ei.tum.de> References: <20090420084118.GA16337@freebsd.org> <49EC3E96.50208@fs.ei.tum.de> Message-ID: <20090420140219.GA74839@freebsd.org> On Mon, Apr 20, 2009 at 11:21:26AM +0200, Simon 'corecode' Schubert wrote: > Hey Roman, > > Roman Divacky wrote: > >I made this patch that highlights today in cal/ncal just like gnu > >cal does.. > > > > www.vlakno.cz/~rdivacky/cal.patch > > Thanks for this patch, I've been meaning to hack one up properly, but > never got to it. They problems I was facing seem to exist also with your > patch: > > - only works for wide (cal) mode, not ncal mode > - probably won't work properly with year displays: the year printing > parts of the code use a length argument to printf ("%*s"), which will > confuse escape sequences with actual printed characters after addressing Simon's concerns here's a new patch: www.vlakno.cz/~rdivacky/cal2.patch this disables the highlighting for year printing because it's broken and introduces the highlighting to ncal as well... From jhb at freebsd.org Mon Apr 20 15:02:34 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Apr 20 15:02:40 2009 Subject: Some questions on 'make release' In-Reply-To: <49EA549E.2060001@FreeBSD.org> References: <49EA549E.2060001@FreeBSD.org> Message-ID: <200904200950.16371.jhb@freebsd.org> On Saturday 18 April 2009 6:30:54 pm Manolis Kiagias wrote: > # make release CHROOTDIR=/data/release BUILDNAME=7.2-PRERELEASE > CVSROOT=/data/ncvs EXTSRCDIR=/usr/src CD_PACKAGE_TREE=/data/packages > -DNODOC -DNOPORTS -DNO_FLOPPIES -DMAKE_ISOS > > which completes, without errors but without adding the packages to any > CD or the DVD. I found out that I can add the packages after the build > by running manually /usr/src/release/i386/mkisoimage.sh with appropriate > arguments (and the resulting CD seems to work fine). But I can't seem > to convince make release to do this. This should work. I would maybe hack on src/release/Makefile and remove the '@' from the lines in the iso.1 target to make sure it is doing things the way you expect. You could make mkisoimages.sh echo the mkisofs command line as well perhaps. -- John Baldwin From shuvaev at physik.uni-wuerzburg.de Mon Apr 20 16:45:15 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Mon Apr 20 16:45:22 2009 Subject: [PATCH]: today highlighting in [n]cal In-Reply-To: <20090420140219.GA74839@freebsd.org> References: <20090420084118.GA16337@freebsd.org> <49EC3E96.50208@fs.ei.tum.de> <20090420140219.GA74839@freebsd.org> Message-ID: <20090420162411.GA50951@wep4035.physik.uni-wuerzburg.de> On Mon, Apr 20, 2009 at 04:02:19PM +0200, Roman Divacky wrote: > On Mon, Apr 20, 2009 at 11:21:26AM +0200, Simon 'corecode' Schubert wrote: > > Hey Roman, > > > > Roman Divacky wrote: > > >I made this patch that highlights today in cal/ncal just like gnu > > >cal does.. > > > > > > www.vlakno.cz/~rdivacky/cal.patch > > > > Thanks for this patch, I've been meaning to hack one up properly, but > > never got to it. They problems I was facing seem to exist also with your > > patch: > > > > - only works for wide (cal) mode, not ncal mode > > - probably won't work properly with year displays: the year printing > > parts of the code use a length argument to printf ("%*s"), which will > > confuse escape sequences with actual printed characters > > after addressing Simon's concerns here's a new patch: > > www.vlakno.cz/~rdivacky/cal2.patch > > this disables the highlighting for year printing because it's broken > and introduces the highlighting to ncal as well... > Nice! It depends on one more lib now: Modified: ~> ldd /usr/bin/ncal /usr/bin/ncal: libcalendar.so.4 => /usr/lib/libcalendar.so.4 (0x800643000) libncurses.so.7 => /lib/libncurses.so.7 (0x800745000) libc.so.7 => /lib/libc.so.7 (0x80088f000) Old: ~> ldd /home/jails/kde4/usr/bin/ncal /home/jails/kde4/usr/bin/ncal: libcalendar.so.4 => /usr/lib/libcalendar.so.4 (0x800642000) libc.so.7 => /lib/libc.so.7 (0x800744000) Does it work good in single user mode? (Don't want to go to it right now myself). OTOH, who needs cal/ncal in single user mode? :) Just my 0.02$, Alexey. From stas at deglitch.com Mon Apr 20 17:02:05 2009 From: stas at deglitch.com (Stanislav Sedov) Date: Mon Apr 20 17:02:12 2009 Subject: building a gcc crosscompiler In-Reply-To: <20090409093837.5f6e8628@gluon.draftnet> References: <49DD4FA6.7090805@telenix.org> <20090409093837.5f6e8628@gluon.draftnet> Message-ID: <20090420210201.951cc772.stas@deglitch.com> On Thu, 9 Apr 2009 09:38:37 +0100 Bruce Cran wrote: > On Wed, 08 Apr 2009 21:30:14 -0400 > Chuck Robey wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Since the last time I built a gcc crosscompiler, the gcc folks have > > added in dependencies on mpfr and gmp libraries. When I first read > > this, I was worried that I had a chicken/egg problem, but I found > > that you can do with the host's version of those libraries. I found > > a port of gnu libmpfr, but I notice here that FreeBSD has it's own > > libmp, and I don't know if the 4.3.1 version of gnu gcc can use our > > libmp, or if I need to install the port "libgmp4" and tell the gnu > > gcc configure about which mp I'm using. > > > > So, if you know if I can use FreeBSD's libmp, or if I need to build > > the ports libgmp4, please let me know. > > I don't know if it's required, but devel/cross-gcc does depend on > math/libgmp4 . > Yeah, it wants it (at least on my system). I will check if it can be replaced with the system libmp. -- Stanislav Sedov ST4096-RIPE !DSPAM:49ecaa8b967002118561090! From rdivacky at freebsd.org Mon Apr 20 17:48:14 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Mon Apr 20 17:48:21 2009 Subject: [PATCH]: today highlighting in [n]cal In-Reply-To: <20090420162411.GA50951@wep4035.physik.uni-wuerzburg.de> References: <20090420084118.GA16337@freebsd.org> <49EC3E96.50208@fs.ei.tum.de> <20090420140219.GA74839@freebsd.org> <20090420162411.GA50951@wep4035.physik.uni-wuerzburg.de> Message-ID: <20090420174655.GA3708@freebsd.org> On Mon, Apr 20, 2009 at 06:24:11PM +0200, Alexey Shuvaev wrote: > On Mon, Apr 20, 2009 at 04:02:19PM +0200, Roman Divacky wrote: > > On Mon, Apr 20, 2009 at 11:21:26AM +0200, Simon 'corecode' Schubert wrote: > > > Hey Roman, > > > > > > Roman Divacky wrote: > > > >I made this patch that highlights today in cal/ncal just like gnu > > > >cal does.. > > > > > > > > www.vlakno.cz/~rdivacky/cal.patch > > > > > > Thanks for this patch, I've been meaning to hack one up properly, but > > > never got to it. They problems I was facing seem to exist also with your > > > patch: > > > > > > - only works for wide (cal) mode, not ncal mode > > > - probably won't work properly with year displays: the year printing > > > parts of the code use a length argument to printf ("%*s"), which will > > > confuse escape sequences with actual printed characters > > > > after addressing Simon's concerns here's a new patch: > > > > www.vlakno.cz/~rdivacky/cal2.patch > > > > this disables the highlighting for year printing because it's broken > > and introduces the highlighting to ncal as well... > > > Nice! > It depends on one more lib now: > > Modified: > ~> ldd /usr/bin/ncal > /usr/bin/ncal: > libcalendar.so.4 => /usr/lib/libcalendar.so.4 (0x800643000) > libncurses.so.7 => /lib/libncurses.so.7 (0x800745000) > libc.so.7 => /lib/libc.so.7 (0x80088f000) > > Old: > ~> ldd /home/jails/kde4/usr/bin/ncal > /home/jails/kde4/usr/bin/ncal: > libcalendar.so.4 => /usr/lib/libcalendar.so.4 (0x800642000) > libc.so.7 => /lib/libc.so.7 (0x800744000) yes.... so? > Does it work good in single user mode? > (Don't want to go to it right now myself). > OTOH, who needs cal/ncal in single user mode? :) I guess it should.. it depends strictly on terminal, didnt test it though From shuvaev at physik.uni-wuerzburg.de Mon Apr 20 18:12:24 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Mon Apr 20 18:12:33 2009 Subject: [PATCH]: today highlighting in [n]cal In-Reply-To: <20090420174655.GA3708@freebsd.org> References: <20090420084118.GA16337@freebsd.org> <49EC3E96.50208@fs.ei.tum.de> <20090420140219.GA74839@freebsd.org> <20090420162411.GA50951@wep4035.physik.uni-wuerzburg.de> <20090420174655.GA3708@freebsd.org> Message-ID: <20090420181222.GB64113@wep4035.physik.uni-wuerzburg.de> On Mon, Apr 20, 2009 at 07:46:55PM +0200, Roman Divacky wrote: > On Mon, Apr 20, 2009 at 06:24:11PM +0200, Alexey Shuvaev wrote: > > On Mon, Apr 20, 2009 at 04:02:19PM +0200, Roman Divacky wrote: > > > > > > after addressing Simon's concerns here's a new patch: > > > > > > www.vlakno.cz/~rdivacky/cal2.patch > > > > > > this disables the highlighting for year printing because it's broken > > > and introduces the highlighting to ncal as well... > > > > > Nice! > > It depends on one more lib now: > > > > Modified: > > ~> ldd /usr/bin/ncal > > /usr/bin/ncal: > > libcalendar.so.4 => /usr/lib/libcalendar.so.4 (0x800643000) > > libncurses.so.7 => /lib/libncurses.so.7 (0x800745000) > > libc.so.7 => /lib/libc.so.7 (0x80088f000) > > > > Old: > > ~> ldd /home/jails/kde4/usr/bin/ncal > > /home/jails/kde4/usr/bin/ncal: > > libcalendar.so.4 => /usr/lib/libcalendar.so.4 (0x800642000) > > libc.so.7 => /lib/libc.so.7 (0x800744000) > > yes.... so? > Well... Just an observation. I have nothing against. > > Does it work good in single user mode? > > (Don't want to go to it right now myself). > > OTOH, who needs cal/ncal in single user mode? :) > > I guess it should.. it depends strictly on terminal, didnt test it though Alexey. From naddy at mips.inka.de Mon Apr 20 23:33:50 2009 From: naddy at mips.inka.de (Christian Weisgerber) Date: Mon Apr 20 23:33:57 2009 Subject: [PATCH]: today highlighting in [n]cal References: <20090420084118.GA16337@freebsd.org> <49EC3E96.50208@fs.ei.tum.de> <20090420140219.GA74839@freebsd.org> Message-ID: Roman Divacky wrote: > after addressing Simon's concerns here's a new patch: > > www.vlakno.cz/~rdivacky/cal2.patch I'd simply use the so/se ("standout") capability rather than specifically asking for reverse video. If you somehow end up on an 1980s terminal where the two aren't synonymous, standout is what you want. -- Christian "naddy" Weisgerber naddy@mips.inka.de From manolis at FreeBSD.org Tue Apr 21 08:17:56 2009 From: manolis at FreeBSD.org (Manolis Kiagias) Date: Tue Apr 21 08:18:02 2009 Subject: Some questions on 'make release' In-Reply-To: <200904200950.16371.jhb@freebsd.org> References: <49EA549E.2060001@FreeBSD.org> <200904200950.16371.jhb@freebsd.org> Message-ID: <49ED8131.40603@FreeBSD.org> John Baldwin wrote: > On Saturday 18 April 2009 6:30:54 pm Manolis Kiagias wrote: > >> # make release CHROOTDIR=/data/release BUILDNAME=7.2-PRERELEASE >> CVSROOT=/data/ncvs EXTSRCDIR=/usr/src CD_PACKAGE_TREE=/data/packages >> -DNODOC -DNOPORTS -DNO_FLOPPIES -DMAKE_ISOS >> >> which completes, without errors but without adding the packages to any >> CD or the DVD. I found out that I can add the packages after the build >> by running manually /usr/src/release/i386/mkisoimage.sh with appropriate >> arguments (and the resulting CD seems to work fine). But I can't seem >> to convince make release to do this. >> > > This should work. I would maybe hack on src/release/Makefile and remove the > '@' from the lines in the iso.1 target to make sure it is doing things the way > you expect. You could make mkisoimages.sh echo the mkisofs command line as > well perhaps. > > Thank you John. I followed your suggestions, but I am still baffled. I removed the '@' from the Makefile and added an echo of my own after the echo "Creating iso images..." in the iso.1 target to print the values of CD and CD_DISC1_PKGS variables: echo "CD is ${CD}" echo "CD_DISC1_PKGS is ${CD_DISC1_PKGS}" Running the make release I can see the "Creating iso images..." but not any of my messages. It is as if another copy of the Makefile is executed (without the changes). (Note I switched from EXTSRCDIR to a real CVSROOT, so it is not my /usr/src that is copied to the release work area) I have tried running the iso.1 target directly (after deleting the /usr/src/release/iso.1 file) and it seems to try to find the files in the wrong directory. For example, it attempts to create the disc images in /R/cdrom/ instead of what would normally be /usr/area/release/R/cdrom (my CHROOTDIR=/usr/area/release) I can work around this by creating a symbolic link /usr/area/release/R => /R or by changing the CD variable in the Makefile from CD=${_R}/cdrom to CD=${CHROOTDIR}${_R}/cdrom but I feel these are just hacks and I am really missing something. (make iso.1 works fine afterwards though) Any more suggestions are welcome, as my trial and error approach takes about 3 hours in the machine used for the build ;) Thanks, manolis@ From k.menshikov at peterhost.ru Tue Apr 21 05:27:25 2009 From: k.menshikov at peterhost.ru (=?UTF-8?B?0JzQtdC90YzRiNC40LrQvtCyINCa0L7QvdGB0YLQsNC90YLQuNC9?=) Date: Tue Apr 21 11:33:08 2009 Subject: CPU limit for Jails(patch for ULE scheduler) Message-ID: <49ED55FF.5080306@peterhost.ru> Hello all! Many users want have limits on resourse for jail, for examle cpu and memory limit. I`m rewrire original cdjones patch for cpu limit for jail under ULE scheduler. So, this work simple. We count cpu usage for all jails, and if jail use cpu more than have shared cpu, we move his threads to IDLE queue and return to TIMESHARE in reverse case. Jailed thread can use all avaliable cpu time, if system has avaliable cpu. If system under heavy load, jailed thread can`t use cpu long as ratio (shared cpu for jail/ all shared cpu) < (estimate usage cpu for jail / all usage cpu) . Unjailed thread and interactive thread are not subject to this regime. Add 2 sysctl kern.sched.total_sched_shares - total count shares cpu in system, increase if we have more cpu kern.sched.flush_estcpu_interval - flush estcpu interval in ticks, default is 2560 = 2 * 128 * 10, NCPU*stathz*sec, increase if we have more cpu For use cpu limit, you need use flag -S NSharedCPU in /usr/sbin/jail program. My example jail -S100 /usr/jails/root/ root.kostjn.pht 192.168.0.245 /bin/csh I`m tested this under 10 simultaneous process in jail and in main system. test program is infinity cycle an 8 core xeon, use RELENG_7. First run process in jail, and after in main system. This one process tracking cpu usage Jail root 1052 0.0 0.0 3692 784 p1 RJ 7:38PM 0:00.39 /test.o root 1052 21.2 0.0 3692 784 p1 RJ 7:38PM 0:02.40 /test.o root 1052 35.6 0.0 3692 784 p1 RJ 7:38PM 0:04.40 /test.o root 1052 47.5 0.0 3692 784 p1 RJ 7:38PM 0:06.41 /test.o root 1052 39.9 0.0 3692 784 p1 RJ 7:38PM 0:06.62 /test.o root 1052 33.2 0.0 3692 784 p1 RJ 7:38PM 0:06.62 /test.o root 1052 27.6 0.0 3692 784 p1 RJ 7:38PM 0:06.62 /test.o root 1052 22.9 0.0 3692 784 p1 RJ 7:38PM 0:06.62 /test.o root 1052 19.0 0.0 3692 784 p1 RJ 7:38PM 0:06.62 /test.o root 1052 15.8 0.0 3692 784 p1 RJ 7:38PM 0:06.62 /test.o root 1052 13.0 0.0 3692 784 p1 RJ 7:38PM 0:06.62 /test.o root 1052 10.8 0.0 3692 784 p1 RJ 7:38PM 0:06.62 /test.o root 1052 8.9 0.0 3692 784 p1 RJ 7:38PM 0:06.62 /tes Main system root 1088 14.9 0.0 3692 780 p0 R 7:38PM 0:01.57 /root/test.o root 1088 30.8 0.0 3692 780 p0 R 7:38PM 0:03.60 /root/test.o root 1088 43.8 0.0 3692 780 p0 R 7:38PM 0:05.60 /root/test.o root 1088 51.0 0.0 3692 780 p0 R 7:38PM 0:07.25 /root/test.o root 1088 50.8 0.0 3692 780 p0 R 7:38PM 0:08.28 /root/test.o root 1088 49.1 0.0 3692 780 p0 R 7:38PM 0:09.21 /root/test.o root 1088 48.1 0.0 3692 780 p0 R 7:38PM 0:10.24 /root/test.o root 1088 46.2 0.0 3692 780 p0 R 7:38PM 0:11.17 /root/test.o root 1088 42.9 0.0 3692 780 p0 R 7:38PM 0:11.95 /root/test.o So we see, that after run in main system, jailed process can`t usage cpu. Please communicate me about all problem in this patch. This is initial version, without tune jail parameter in runtime. So, this work. But i`m not sure, that is best way. Attempt increase priority for jailed thread not work, because non interactive thread (that utilize many cpu) already have small prioriry(numerical high). Attempt decrease number ticks in cpu time slice, also not good idea, because, this increase number context switching on high load. May be you see other way for do this? Share you idea. Thank. Original cdjones cpu and memory limit patch http://wiki.freebsd.org/JailResourceLimits -------------- next part -------------- diff -U3 -r --show-c-function --ignore-all-space --ignore-tab-expansion --ignore-blank-lines sys/kern/kern_jail.c sys.new/kern/kern_jail.c --- sys/kern/kern_jail.c 2009-03-10 22:33:50.000000000 +0300 +++ sys.new/kern/kern_jail.c 2009-04-17 18:51:34.000000000 +0400 @@ -531,6 +532,7 @@ kern_jail(struct thread *td, struct jail } #endif pr->pr_linux = NULL; + pr->pr_sched_shares = j->sched_shares; pr->pr_securelevel = securelevel; if (prison_service_slots == 0) pr->pr_slots = NULL; diff -U3 -r --show-c-function --ignore-all-space --ignore-tab-expansion --ignore-blank-lines sys/kern/sched_ule.c sys.new/kern/sched_ule.c --- sys/kern/sched_ule.c 2009-03-30 23:20:56.000000000 +0400 +++ sys.new/kern/sched_ule.c 2009-04-17 19:10:07.000000000 +0400 @@ -61,6 +61,7 @@ __FBSDID("$FreeBSD: src/sys/kern/sched_u #include #include #include +#include #ifdef KTRACE #include #include @@ -186,6 +187,22 @@ static int sched_interact = SCHED_INTERA static int realstathz; static int tickincr; static int sched_slice; + +#define ESTCPU_SHIFT 10 +/* + * estcpu: Global counter ticks from stat timer + * flush_estcpu_interval: Number ticks, after that we to zero estcpu, + * flush_estcpu_interval = mp_ncpus*stathz*10, + * default 2*128*10 = 2560 + * total_sched_shares: Total count shares cpu, 1000 per core, + * default 2*1000 = 2000 +*/ + + +static int estcpu; +static int flush_estcpu_interval = 2560; +static int total_sched_shares = 2000; + #ifdef PREEMPTION #ifdef FULL_PREEMPTION static int preempt_thresh = PRI_MAX_IDLE; @@ -2200,6 +2219,7 @@ sched_clock(struct thread *td) { struct tdq *tdq; struct td_sched *ts; + struct prison *pr = td->td_proc->p_ucred->cr_prison; THREAD_LOCK_ASSERT(td, MA_OWNED); tdq = TDQ_SELF(); @@ -2234,6 +2254,20 @@ sched_clock(struct thread *td) td->td_sched->ts_runtime += tickincr; sched_interact_update(td); } + + /* Increase counter and flush if need */ + estcpu++; + if (pr != NULL) + pr->pr_estcpu++; + + if (estcpu > flush_estcpu_interval){ + estcpu = 0; + LIST_FOREACH(pr, &allprison, pr_list) { + pr->pr_estcpu = 0; + } + CTR0(KTR_SCHED,"Flush estcpu and pr_estcpu for all jails"); + } + /* * We used up one time slice. */ @@ -2375,6 +2409,8 @@ tdq_add(struct tdq *tdq, struct thread * int cpumask; #endif + struct prison *pr = td->td_proc->p_ucred->cr_prison; + TDQ_LOCK_ASSERT(tdq, MA_OWNED); KASSERT((td->td_inhibitors == 0), ("sched_add: trying to run inhibited thread")); @@ -2383,6 +2419,32 @@ tdq_add(struct tdq *tdq, struct thread * KASSERT(td->td_flags & TDF_INMEM, ("sched_add: thread swapped out")); + /* We move thread in IDLE queue if prison estimate cpu more than shares + * cpu and thread is not interactive. Use ESTCPU_SHIFT to avoid + * rounding away results */ + if(pr != NULL) + CTR6(KTR_SCHED,"pid %i, prison %i, pr_estcpu %i,\ + estcpu %i shares %i interact %i", + td->td_proc->p_pid,pr->pr_id,pr->pr_estcpu, + estcpu, pr->pr_sched_shares, sched_interact_score(td)); + if (pr != NULL && pr->pr_sched_shares != 0 && + sched_interact_score(td) > sched_interact && + estcpu != 0 && total_sched_shares != 0){ + + if ((pr->pr_estcpu << ESTCPU_SHIFT) / (estcpu) > + (pr->pr_sched_shares << ESTCPU_SHIFT) / (total_sched_shares)) + { + td->td_priority = PRI_MIN_IDLE; + td->td_pri_class = PRI_IDLE; + CTR2(KTR_SCHED,"prison %i excess cpu limit!!! new pri = %i ",pr->pr_id,td->td_priority); + + } else { + CTR1(KTR_SCHED,"prison %i use cpu less limit",pr->pr_id); + sched_priority(td); + td->td_pri_class = PRI_TIMESHARE; + } + } + ts = td->td_sched; class = PRI_BASE(td->td_pri_class); TD_SET_RUNQ(td); @@ -2746,6 +2808,10 @@ SYSCTL_INT(_kern_sched, OID_AUTO, intera "Interactivity score threshold"); SYSCTL_INT(_kern_sched, OID_AUTO, preempt_thresh, CTLFLAG_RW, &preempt_thresh, 0,"Min priority for preemption, lower priorities have greater precedence"); +SYSCTL_INT(_kern_sched, OID_AUTO, flush_estcpu_interval, CTLFLAG_RW, &flush_estcpu_interval, + 0,"Number ticks stat timer after thar we zero estcpu counter"); +SYSCTL_INT(_kern_sched, OID_AUTO, total_sched_shares, CTLFLAG_RW, &total_sched_shares, + 0,"Total number shared cpu for system"); #ifdef SMP SYSCTL_INT(_kern_sched, OID_AUTO, pick_pri, CTLFLAG_RW, &pick_pri, 0, "Pick the target cpu based on priority rather than load."); diff -U3 -r --show-c-function --ignore-all-space --ignore-tab-expansion --ignore-blank-lines sys/sys/jail.h sys.new/sys/jail.h --- sys/sys/jail.h 2009-02-18 23:12:08.000000000 +0300 +++ sys.new/sys/jail.h 2009-04-17 18:53:43.000000000 +0400 @@ -31,6 +31,7 @@ struct jail { uint32_t ip6s; struct in_addr *ip4; struct in6_addr *ip6; + uint32_t sched_shares; }; #define JAIL_API_VERSION 2 @@ -132,6 +133,9 @@ struct prison { struct task pr_task; /* (d) destroy task */ struct mtx pr_mtx; void **pr_slots; /* (p) additional data */ + uint32_t pr_estcpu; /* (p) cpu usage */ + uint32_t pr_sched_shares; /* (c) number virtual cpu */ + int pr_ip4s; /* (c) number of v4 IPs */ struct in_addr *pr_ip4; /* (c) v4 IPs of jail */ int pr_ip6s; /* (c) number of v6 IPs */ diff -U3 -r --show-c-function --ignore-all-space --ignore-tab-expansion --ignore-blank-lines usr.sbin/jail/jail.c usr.sbin.new/jail/jail.c --- usr.sbin/jail/jail.c 2009-02-07 16:19:08.000000000 +0300 +++ usr.sbin.new/jail/jail.c 2009-04-17 18:57:15.000000000 +0400 @@ -83,6 +83,7 @@ main(int argc, char **argv) int ch, error, i, ngroups, securelevel; int hflag, iflag, Jflag, lflag, uflag, Uflag; char path[PATH_MAX], *jailname, *ep, *username, *JidFile, *ip; + uint32_t sched_shares = 0; static char *cleanenv; const char *shell, *p = NULL; long ltmp; @@ -94,7 +95,7 @@ main(int argc, char **argv) jailname = username = JidFile = cleanenv = NULL; fp = NULL; - while ((ch = getopt(argc, argv, "hiln:s:u:U:J:")) != -1) { + while ((ch = getopt(argc, argv, "hilS:n:s:u:U:J:")) != -1) { switch (ch) { case 'h': hflag = 1; @@ -115,6 +116,9 @@ main(int argc, char **argv) errx(1, "invalid securelevel: `%s'", optarg); securelevel = ltmp; break; + case 'S': + sched_shares = (uint32_t)strtol(optarg,NULL,10); + break; case 'u': username = optarg; uflag = 1; @@ -152,6 +156,8 @@ main(int argc, char **argv) if (jailname != NULL) j.jailname = jailname; + j.sched_shares = sched_shares; + /* Handle IP addresses. If requested resolve hostname too. */ bzero(&hints, sizeof(struct addrinfo)); hints.ai_protocol = IPPROTO_TCP; @@ -264,9 +270,10 @@ static void usage(void) { - (void)fprintf(stderr, "%s%s%s\n", + (void)fprintf(stderr, "%s%s%s%s\n", "usage: jail [-hi] [-n jailname] [-J jid_file] ", "[-s securelevel] [-l -u username | -U username] ", + "[-S number shared cpu] ", "path hostname [ip[,..]] command ..."); exit(1); } -------------- next part -------------- diff -U3 -r --show-c-function --ignore-all-space --ignore-tab-expansion --ignore-blank-lines sys/kern/kern_jail.c sys.new/kern/kern_jail.c --- sys/kern/kern_jail.c 2008-11-25 05:59:29.000000000 +0300 +++ sys.new/kern/kern_jail.c 2009-04-17 20:23:40.000000000 +0400 @@ -156,6 +156,7 @@ jail(struct thread *td, struct jail_args goto e_dropvnref; pr->pr_ip = j.ip_number; pr->pr_linux = NULL; + pr->pr_sched_shares = j->sched_shares; pr->pr_securelevel = securelevel; if (prison_service_slots == 0) pr->pr_slots = NULL; diff -U3 -r --show-c-function --ignore-all-space --ignore-tab-expansion --ignore-blank-lines sys/kern/sched_ule.c sys.new/kern/sched_ule.c --- sys/kern/sched_ule.c 2008-11-25 05:59:29.000000000 +0300 +++ sys.new/kern/sched_ule.c 2009-04-17 20:23:40.000000000 +0400 @@ -61,6 +61,7 @@ __FBSDID("$FreeBSD: src/sys/kern/sched_u #include #include #include +#include #ifdef KTRACE #include #include @@ -186,6 +187,22 @@ static int sched_interact = SCHED_INTERA static int realstathz; static int tickincr; static int sched_slice; + +#define ESTCPU_SHIFT 10 +/* + * estcpu: Global counter ticks from stat timer + * flush_estcpu_interval: Number ticks, after that we to zero estcpu, + * flush_estcpu_interval = mp_ncpus*stathz*10, + * default 2*128*10 = 2560 + * total_sched_shares: Total count shares cpu, 1000 per core, + * default 2*1000 = 2000 +*/ + + +static int estcpu; +static int flush_estcpu_interval = 2560; +static int total_sched_shares = 2000; + #ifdef PREEMPTION #ifdef FULL_PREEMPTION static int preempt_thresh = PRI_MAX_IDLE; @@ -2200,6 +2217,7 @@ sched_clock(struct thread *td) { struct tdq *tdq; struct td_sched *ts; + struct prison *pr = td->td_proc->p_ucred->cr_prison; THREAD_LOCK_ASSERT(td, MA_OWNED); tdq = TDQ_SELF(); @@ -2234,6 +2252,20 @@ sched_clock(struct thread *td) td->td_sched->ts_runtime += tickincr; sched_interact_update(td); } + + /* Increase counter and flush if need */ + estcpu++; + if (pr != NULL) + pr->pr_estcpu++; + + if (estcpu > flush_estcpu_interval){ + estcpu = 0; + LIST_FOREACH(pr, &allprison, pr_list) { + pr->pr_estcpu = 0; + } + CTR0(KTR_SCHED,"Flush estcpu and pr_estcpu for all jails"); + } + /* * We used up one time slice. */ @@ -2375,6 +2407,8 @@ tdq_add(struct tdq *tdq, struct thread * int cpumask; #endif + struct prison *pr = td->td_proc->p_ucred->cr_prison; + TDQ_LOCK_ASSERT(tdq, MA_OWNED); KASSERT((td->td_inhibitors == 0), ("sched_add: trying to run inhibited thread")); @@ -2383,6 +2417,32 @@ tdq_add(struct tdq *tdq, struct thread * KASSERT(td->td_flags & TDF_INMEM, ("sched_add: thread swapped out")); + /* We move thread in IDLE queue if prison estimate cpu more than shares + * cpu and thread is not interactive. Use ESTCPU_SHIFT to avoid + * rounding away results */ + if(pr != NULL) + CTR6(KTR_SCHED,"pid %i, prison %i, pr_estcpu %i,\ + estcpu %i shares %i interact %i", + td->td_proc->p_pid,pr->pr_id,pr->pr_estcpu, + estcpu, pr->pr_sched_shares, sched_interact_score(td)); + if (pr != NULL && pr->pr_sched_shares != 0 && + sched_interact_score(td) > sched_interact && + estcpu != 0 && total_sched_shares != 0){ + + if ((pr->pr_estcpu << ESTCPU_SHIFT) / (estcpu) > + (pr->pr_sched_shares << ESTCPU_SHIFT) / (total_sched_shares)) + { + td->td_priority = PRI_MIN_IDLE; + td->td_pri_class = PRI_IDLE; + CTR2(KTR_SCHED,"prison %i excess cpu limit!!! new pri = %i ",pr->pr_id,td->td_priority); + + } else { + CTR1(KTR_SCHED,"prison %i use cpu less limit",pr->pr_id); + sched_priority(td); + td->td_pri_class = PRI_TIMESHARE; + } + } + ts = td->td_sched; class = PRI_BASE(td->td_pri_class); TD_SET_RUNQ(td); @@ -2741,6 +2801,10 @@ SYSCTL_INT(_kern_sched, OID_AUTO, intera "Interactivity score threshold"); SYSCTL_INT(_kern_sched, OID_AUTO, preempt_thresh, CTLFLAG_RW, &preempt_thresh, 0,"Min priority for preemption, lower priorities have greater precedence"); +SYSCTL_INT(_kern_sched, OID_AUTO, flush_estcpu_interval, CTLFLAG_RW, &flush_estcpu_interval, + 0,"Number ticks stat timer after thar we zero estcpu counter"); +SYSCTL_INT(_kern_sched, OID_AUTO, total_sched_shares, CTLFLAG_RW, &total_sched_shares, + 0,"Total number shared cpu for system"); #ifdef SMP SYSCTL_INT(_kern_sched, OID_AUTO, pick_pri, CTLFLAG_RW, &pick_pri, 0, "Pick the target cpu based on priority rather than load."); diff -U3 -r --show-c-function --ignore-all-space --ignore-tab-expansion --ignore-blank-lines sys/sys/jail.h sys.new/sys/jail.h --- sys/sys/jail.h 2008-11-25 05:59:29.000000000 +0300 +++ sys.new/sys/jail.h 2009-04-17 20:26:54.000000000 +0400 @@ -18,6 +18,7 @@ struct jail { char *path; char *hostname; u_int32_t ip_number; + uint32_t sched_shares; }; struct xprison { @@ -74,6 +75,8 @@ struct prison { struct task pr_task; /* (d) destroy task */ struct mtx pr_mtx; void **pr_slots; /* (p) additional data */ + uint32_t pr_estcpu; /* (p) cpu usage */ + uint32_t pr_sched_shares; /* (c) number virtual cpu */ }; #endif /* _KERNEL || _WANT_PRISON */ diff -U3 -r --show-c-function --ignore-all-space --ignore-tab-expansion --ignore-blank-lines usr.sbin/jail/jail.c usr.sbin.new/jail/jail.c --- usr.sbin/jail/jail.c 2008-11-25 05:59:29.000000000 +0300 +++ usr.sbin.new/jail/jail.c 2009-04-17 20:31:17.000000000 +0400 @@ -57,6 +57,7 @@ main(int argc, char **argv) gid_t groups[NGROUPS]; int ch, i, iflag, Jflag, lflag, ngroups, securelevel, uflag, Uflag; char path[PATH_MAX], *ep, *username, *JidFile; + uint32_t sched_shares = 0; static char *cleanenv; const char *shell, *p = NULL; long ltmp; @@ -67,7 +68,7 @@ main(int argc, char **argv) username = JidFile = cleanenv = NULL; fp = NULL; - while ((ch = getopt(argc, argv, "ils:u:U:J:")) != -1) { + while ((ch = getopt(argc, argv, "ilS:s:u:U:J:")) != -1) { switch (ch) { case 'i': iflag = 1; @@ -82,6 +83,9 @@ main(int argc, char **argv) errx(1, "invalid securelevel: `%s'", optarg); securelevel = ltmp; break; + case 'S': + sched_shares = (uint32_t)strtol(optarg,NULL,10); + break; case 'u': username = optarg; uflag = 1; @@ -115,6 +119,7 @@ main(int argc, char **argv) j.version = 0; j.path = path; j.hostname = argv[1]; + j.sched_shares = sched_shares; if (inet_aton(argv[2], &in) == 0) errx(1, "Could not make sense of ip-number: %s", argv[2]); j.ip_number = ntohl(in.s_addr); @@ -182,9 +187,10 @@ static void usage(void) { - (void)fprintf(stderr, "%s%s%s\n", + (void)fprintf(stderr, "%s%s%s%s\n", "usage: jail [-i] [-J jid_file] [-s securelevel] [-l -u ", "username | -U username]", + "[-S number shared cpu] ", " path hostname ip-number command ..."); exit(1); } From aryeh.friedman at gmail.com Tue Apr 21 23:09:41 2009 From: aryeh.friedman at gmail.com (Aryeh Friedman) Date: Tue Apr 21 23:09:48 2009 Subject: figuring out my subnet Message-ID: My boss ordered a new subnet from our ISP and wrote down the subnet incorrectly is there anyway to deduce what it is? From julian at elischer.org Wed Apr 22 00:25:28 2009 From: julian at elischer.org (Julian Elischer) Date: Wed Apr 22 00:25:35 2009 Subject: figuring out my subnet In-Reply-To: References: Message-ID: <49EE63F7.20809@elischer.org> Aryeh Friedman wrote: > My boss ordered a new subnet from our ISP and wrote down the subnet > incorrectly is there anyway to deduce what it is? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" allocate a bigger one then from each address ping you isp's mail server when it stops responding you've reached the end of what he's routing to you :-) From glen.j.barber at gmail.com Wed Apr 22 00:29:22 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Wed Apr 22 00:29:29 2009 Subject: figuring out my subnet In-Reply-To: References: Message-ID: <4ad871310904211702s36384c24ke4a1e0f2ee0d273b@mail.gmail.com> On Tue, Apr 21, 2009 at 6:36 PM, Aryeh Friedman wrote: > My boss ordered a new subnet from our ISP and wrote down the subnet > incorrectly is there anyway to deduce what it is? Short of calling the ISP, not really. Calling the ISP would probably be less time consuming anyway. -- Glen Barber From alfred at freebsd.org Wed Apr 22 00:50:31 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Wed Apr 22 00:50:41 2009 Subject: question about dev/md/md.c out of swap? Message-ID: <20090422003229.GL98432@elvis.mu.org> Hello, a developer here at work asked me to go over some of the swapper code with him. We came across something we both couldn't understand, so I was wondering if anyone had looked at this. in dev/md/md.c mdstart_swap() there is the following code, it seems that in the case of VM_PAGER_ERROR most of the state is unwound, however the page is not freed. Is this a bug or are we missing something? How is the page released? rv = VM_PAGER_OK; VM_OBJECT_LOCK(sc->object); vm_object_pip_add(sc->object, 1); for (i = bp->bio_offset / PAGE_SIZE; i <= lastp; i++) { len = ((i == lastp) ? lastend : PAGE_SIZE) - offs; m = vm_page_grab(sc->object, i, VM_ALLOC_NORMAL|VM_ALLOC_RETRY); VM_OBJECT_UNLOCK(sc->object); sched_pin(); sf = sf_buf_alloc(m, SFB_CPUPRIVATE); VM_OBJECT_LOCK(sc->object); if (bp->bio_cmd == BIO_READ) { if (m->valid != VM_PAGE_BITS_ALL) rv = vm_pager_get_pages(sc->object, &m, 1, 0); if (rv == VM_PAGER_ERROR) { sf_buf_free(sf); sched_unpin(); vm_page_lock_queues(); vm_page_wakeup(m); vm_page_unlock_queues(); break; } bcopy((void *)(sf_buf_kva(sf) + offs), p, len); } else if (bp->bio_cmd == BIO_WRITE) { if (len != PAGE_SIZE && m->valid != VM_PAGE_BITS_ALL) rv = vm_pager_get_pages(sc->object, &m, 1, 0); if (rv == VM_PAGER_ERROR) { sf_buf_free(sf); sched_unpin(); vm_page_lock_queues(); vm_page_wakeup(m); vm_page_unlock_queues(); break; } -- - Alfred Perlstein From James.McPherson at Sun.COM Wed Apr 22 00:20:29 2009 From: James.McPherson at Sun.COM (James C. McPherson) Date: Wed Apr 22 01:11:58 2009 Subject: Kernel Conference Australia - Call for Papers deadline approaching Message-ID: <20090422102010.000013c6@blinder> Greetings! I am organising a Kernel-focused conference for July 2009 - Kernel Conference Australia. The conference will be held at the Queensland Brain Institute, which is a part of the University of Queensland here in Brisbane. We've got some outstanding speakers committed to coming and talking about what they're working on right now: * Jeff Bonwick and Bill Moore (team ZFS) * Sherry Moore (our x64 project lead) * Gavin Maltby (FMA project lead) * Max Alt from Intel (OpenSolaris relationship manager) The Call for Papers closes on 1 May 2009 and registrations will open on 4 May. It's not just a conference about Sun's technologies, it's for any and all Open Source technologies - and focused on the kernel. So OpenSolaris, Linux, the BSD family, Minix, Microkernels are all fair game for discussion. The conference event website is http://au.sun.com/sunnews/events/2009/kernel/index.jsp which has a link to the Call for Papers and info about who to contact for more information - or you could contact me directly :-) For the web2.0-inclined, joining the KCA2009 Facebook event http://www.facebook.com/home.php#/event.php?eid=55116884131&ref=mf would be a good thing. We also have a conference flyer which you can print out, available from http://blogs.sun.com/jmcp/resource/KCA2009_flyer.pdf I look forward to seeing you at the conference. Best regards, James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog Kernel Conference Australia - http://au.sun.com/sunnews/events/2009/kernel From kostikbel at gmail.com Wed Apr 22 11:25:33 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Apr 22 11:25:40 2009 Subject: question about dev/md/md.c out of swap? In-Reply-To: <20090422003229.GL98432@elvis.mu.org> References: <20090422003229.GL98432@elvis.mu.org> Message-ID: <20090422112525.GM3014@deviant.kiev.zoral.com.ua> On Tue, Apr 21, 2009 at 05:32:29PM -0700, Alfred Perlstein wrote: > Hello, a developer here at work asked me to go over > some of the swapper code with him. > > We came across something we both couldn't understand, > so I was wondering if anyone had looked at this. > > in dev/md/md.c mdstart_swap() there is the following code, > it seems that in the case of VM_PAGER_ERROR most of the state > is unwound, however the page is not freed. Is this a bug or > are we missing something? How is the page released? The page belongs to the object. It will be freed when the object is deallocated. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090422/486c0b6d/attachment.pgp From jhb at freebsd.org Wed Apr 22 15:30:55 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Apr 22 15:31:02 2009 Subject: Some questions on 'make release' In-Reply-To: <49ED8131.40603@FreeBSD.org> References: <49EA549E.2060001@FreeBSD.org> <200904200950.16371.jhb@freebsd.org> <49ED8131.40603@FreeBSD.org> Message-ID: <200904220957.43717.jhb@freebsd.org> On Tuesday 21 April 2009 4:17:53 am Manolis Kiagias wrote: > John Baldwin wrote: > > On Saturday 18 April 2009 6:30:54 pm Manolis Kiagias wrote: > > > >> # make release CHROOTDIR=/data/release BUILDNAME=7.2-PRERELEASE > >> CVSROOT=/data/ncvs EXTSRCDIR=/usr/src CD_PACKAGE_TREE=/data/packages > >> -DNODOC -DNOPORTS -DNO_FLOPPIES -DMAKE_ISOS > >> > >> which completes, without errors but without adding the packages to any > >> CD or the DVD. I found out that I can add the packages after the build > >> by running manually /usr/src/release/i386/mkisoimage.sh with appropriate > >> arguments (and the resulting CD seems to work fine). But I can't seem > >> to convince make release to do this. > >> > > > > This should work. I would maybe hack on src/release/Makefile and remove the > > '@' from the lines in the iso.1 target to make sure it is doing things the way > > you expect. You could make mkisoimages.sh echo the mkisofs command line as > > well perhaps. > > > > > Thank you John. I followed your suggestions, but I am still baffled. > I removed the '@' from the Makefile and added an echo of my own after the > > echo "Creating iso images..." > > in the iso.1 target to print the values of CD and CD_DISC1_PKGS variables: > > echo "CD is ${CD}" > echo "CD_DISC1_PKGS is ${CD_DISC1_PKGS}" > > Running the make release I can see the "Creating iso images..." but not > any of my messages. It is as if another copy of the Makefile is executed > (without the changes). > (Note I switched from EXTSRCDIR to a real CVSROOT, so it is not my > /usr/src that is copied to the release work area) Right, the release process chroot's into your release area and then uses that /usr/src/release/Makefile for the extra targets. You can build the release once and then just update the release Makefile in the chroot area and use 'make rerelease' for testing. > Any more suggestions are welcome, as my trial and error approach takes > about 3 hours in the machine used for the build ;) Use 'make rerelease'. It will simply pick up where the last one stopped. If you need to force it to rebuild just the ISO's you can delete the iso cookie file created by the iso.1 target after it finishes before using 'rerelease'. This should dramatically lower your build time (a few seconds vs 3 hours). -- John Baldwin From manolis at FreeBSD.org Wed Apr 22 20:58:18 2009 From: manolis at FreeBSD.org (Manolis Kiagias) Date: Wed Apr 22 20:58:24 2009 Subject: Some questions on 'make release' In-Reply-To: <200904220957.43717.jhb@freebsd.org> References: <49EA549E.2060001@FreeBSD.org> <200904200950.16371.jhb@freebsd.org> <49ED8131.40603@FreeBSD.org> <200904220957.43717.jhb@freebsd.org> Message-ID: <49EF84E6.5060205@FreeBSD.org> John Baldwin wrote: > On Tuesday 21 April 2009 4:17:53 am Manolis Kiagias wrote: > >> in the iso.1 target to print the values of CD and CD_DISC1_PKGS variables: >> >> echo "CD is ${CD}" >> echo "CD_DISC1_PKGS is ${CD_DISC1_PKGS}" >> >> Running the make release I can see the "Creating iso images..." but not >> any of my messages. It is as if another copy of the Makefile is executed >> (without the changes). >> (Note I switched from EXTSRCDIR to a real CVSROOT, so it is not my >> /usr/src that is copied to the release work area) >> > > Right, the release process chroot's into your release area and then uses > that /usr/src/release/Makefile for the extra targets. You can build the > release once and then just update the release Makefile in the chroot area and > use 'make rerelease' for testing. > > Thank you John. You were right of course, the Makefile that continues to execute is the one inside the CHROOTDIR. And in fact my original problem is exactly that: I was not thinking in terms of the chroot. Reading the Makefile, CD_DISC1_PKGS = ${CD_PACKAGE_TREE}/disc1 but CD_PACKAGE_TREE refers to a chroot directory, just like every other CD_* variable in there. I was using CD_PACKAGE_TREE=/usr/area/packages, a completely unrelated path. As for make rerelease, I tried it with the RELEASENOUPDATE option, but apparently the CD_DISC*_PKGS do not get defined. It would be trivial to hack a solution though. From gabor at kovesdan.org Thu Apr 23 13:30:37 2009 From: gabor at kovesdan.org (=?iso-8859-2?Q?G=E1bor_K=F6vesd=E1n?=) Date: Thu Apr 23 14:00:11 2009 Subject: SoC 2009: BSD-licensed libiconv in base system Message-ID: Hello all, my name is G?bor K?vesd?n. I'm a Hungarian student and I'll be working on a BSD-licensed libiconv implementation for FreeBSD during this year's Summer of Code program. It'll be based on NetBSD's Citrus iconv but there is a lot to do besides porting. My mentor is Xin Li. So far, I've worked on the Ports Collection, the Documentation Project and the Hungarian translation in particular and last year, on a BSD-licensed grep and sort. These are also in progress, grep is ready for a portbuild test and sort is quite mature, as well. You can read my full proposal at http://kovesdan.org/doc/en_US.ISO8859-1/soc2009/soc2009.html Regards, -- G?bor K?vesd?n From ccna.syl at gmail.com Thu Apr 23 14:47:26 2009 From: ccna.syl at gmail.com (Sylvestre Gallon) Date: Thu Apr 23 14:47:33 2009 Subject: SoC 2009: USB improvements under FreeBSD Message-ID: <164b4c9c0904230717g6e5a4332idb41434b67736d28@mail.gmail.com> Hi guys, I am a French student interested in FreeBSD and *BSD in general. I am really interested in kernel stuff, device driver development, arm System On Chip and hardware protocols (like USB). I have worked two years @ Adeneo on embedded BSP (Board support package) development. I have done some Atmel card BSP while I?ve been doing this job and developed USB drivers and USB device firmware. I am also the leader of R&D in the rathaxes project (a DSL/Driver http://www.rathaxes.org) . The aim of my Summer of Code project would be to improve the usb into FreeBSD. To do it I will add support for libusb v1.0 api, improve the usb function subsystem, write some manpages and implement some USB function drivers. My mentor is Philip Paeps. You can read my full proposal at : http://wiki.freebsd.org/SOC2009SylvestreGallon Cheers, -- Sylvestre Gallon (http://devsyl.blogspot.com) Fifth Grade Student @ Epitech & Researcher @ LSE R&D @ Rathaxes (http://www.rathaxes.org) From peterjeremy at optushome.com.au Thu Apr 23 19:59:33 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Thu Apr 23 19:59:41 2009 Subject: Using bus_dma(9) Message-ID: <20090423195928.GB8531@server.vk2pj.dyndns.org> I'm currently trying to port some code that uses bus_dma(9) from OpenBSD to FreeBSD and am having some difficulties in following the way bus_dma is intended to be used on FreeBSD (and how it differs from Net/OpenBSD). Other than the man page and existing FreeBSD drivers, I am unable to locate any information on bus_dma care and feeding. Has anyone written any tutorial guide to using bus_dma? The OpenBSD man page provides pseudo-code showing the basic cycle. Unfortunately, FreeBSD doesn't provide any similar pseudo-code and the functionality is distributed somewhat differently amongst the functions (and the drivers I've looked at tend to use a different order of calls). So far, I've hit a number of issues that I'd like some advice on: Firstly, the OpenBSD model only provides a single DMA tag for the device at attach() time, whereas FreeBSD provides the parent's DMA tag at attach time and allows the driver to create multiple tags. Rather than just creating a single tag for a device, many drivers create a device tag which is only used as the parent for additional tags to handle receive, transmit etc. Whilst the need for multiple tags is probably a consequence of moving much of the dmamap information from OpenBSD bus_dmamap_create() into FreeBSD bus_dma_tag_create(), the rationale behind multiple levels of tags is unclear. Is this solely to provide a single point where overall device DMA characteristics & limitations can be specified or is there another reason? Secondly, bus_dma_tag_create() supports a BUS_DMA_ALLOCNOW flag that "pre-allocates enough resources to handle at least one map load operation on this tag". However it also states "[t]his should not be used for tags that only describe buffers that will be allocated with bus_dmamem_alloc()" - does this mean that only one of bus_dmamap_load() or bus_dmamap_alloc() should be used on a tag/mapping? Or is the sense backwards (ie "don't specify BUS_DMA_ALLOCNOW for tags that are only used as the parent for other tags and never mapped themselves")? Or is there some other explanation. Thirdly, bus_dmamap_load() has a uses a callback function to return the actual mapping details. According to the man page, there is no way to ensure that the callback occurs synchronously - a caller can only request that bus_dmamap_load() fail if resources are not immediately available. Despite this, many drivers pass 0 for flags (allowing an asynchronous invocation of the callback) and then fail (and cleanup) if bus_dmamap_load() returns EINPROGRESS. This appears to open a race condition where the callback and cleanup could occur simultaneously. Mitigating the race condition seems to rely on one of the following two behaviours: a) The system is implicitly single-threaded when bus_dmamap_load() is called (generally as part of the device attach() function). Whilst this is true at boot time, it would not be true for a dynamically loaded module. b) Passing BUS_DMA_ALLOCNOW to bus_dma_tag_create() guarantees that the first bus_dmamap_load() on that tag will be synchronous. Is this true? Whilst it appears to be implied, it's not explicitly stated. Finally, what are the ordering requirements between the alloc, create, load and sync functions? OpenBSD implies that the normal ordering is create, alloc, load, sync whilst several FreeBSD drivers use tag_create, alloc, load and then create. As a side-note, the manpage does not document the behaviour when bus_dmamap_destroy() or bus_dma_tag_destroy() are called whilst a bus_dmamap_load() callback is queued. Is the callback cancelled or do one or both destroy operations fail? -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090423/f888a0d4/attachment.pgp From sarawgi.aditya at gmail.com Thu Apr 23 20:32:14 2009 From: sarawgi.aditya at gmail.com (Aditya Sarawgi) Date: Thu Apr 23 20:32:46 2009 Subject: SoC 2009: Improving ext2fs and making it GPL free Message-ID: <20090424013250.GA3672@pcbsd> Hi, I'm Aditya Sarawgi from India. I will be working on FreeBSD's ext2fs as a part of this year's summer of code program. I will be improving the current implementation and I will also rewrite parts of ext2fs under GPL. My mentor is Ulf Lilleengen. For more details you can visit http://wiki.freebsd.org/SOC2009AdityaSarawgi Cheers, Aditya Sarawgi From wangfangcs at gmail.com Fri Apr 24 14:32:13 2009 From: wangfangcs at gmail.com (wangfangcs) Date: Fri Apr 24 14:32:19 2009 Subject: SoC 2009: Implement TCP UTO Message-ID: <200904242210350930408@gmail.com> Hi, everyone! My name is Fang Wang, a undergrad student from China. This is my first participating in google summer of code and this is my first time get involved in an open source community. I have some experience with linux but I am a newbie to FreeBSD. I have great interests in kernel and network stuff. The aim of my project is implement TCP UTO in freeBSD tcp stack and write some test program to test the TCP performance. The TCP UTO(user timeout controls) how long transmitted data may remain unacknowledged before a connection is forcefully closed and it is a local, per-connection parameter. And it's described in RFC 5482. For more details, you can visit my wiki page:http://wiki.freebsd.org/FangWang Regards, Fang Wang 2009-04-24 From jhb at freebsd.org Fri Apr 24 17:11:40 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Apr 24 17:11:52 2009 Subject: Using bus_dma(9) In-Reply-To: <20090423195928.GB8531@server.vk2pj.dyndns.org> References: <20090423195928.GB8531@server.vk2pj.dyndns.org> Message-ID: <200904241059.30788.jhb@freebsd.org> On Thursday 23 April 2009 3:59:28 pm Peter Jeremy wrote: > I'm currently trying to port some code that uses bus_dma(9) from > OpenBSD to FreeBSD and am having some difficulties in following the > way bus_dma is intended to be used on FreeBSD (and how it differs from > Net/OpenBSD). Other than the man page and existing FreeBSD drivers, I > am unable to locate any information on bus_dma care and feeding. Has > anyone written any tutorial guide to using bus_dma? > > The OpenBSD man page provides pseudo-code showing the basic cycle. > Unfortunately, FreeBSD doesn't provide any similar pseudo-code and > the functionality is distributed somewhat differently amongst the > functions (and the drivers I've looked at tend to use a different > order of calls). > > So far, I've hit a number of issues that I'd like some advice on: > > Firstly, the OpenBSD model only provides a single DMA tag for the > device at attach() time, whereas FreeBSD provides the parent's DMA tag > at attach time and allows the driver to create multiple tags. Rather > than just creating a single tag for a device, many drivers create a > device tag which is only used as the parent for additional tags to > handle receive, transmit etc. Whilst the need for multiple tags is > probably a consequence of moving much of the dmamap information from > OpenBSD bus_dmamap_create() into FreeBSD bus_dma_tag_create(), the > rationale behind multiple levels of tags is unclear. Is this solely > to provide a single point where overall device DMA characteristics & > limitations can be specified or is there another reason? Many drivers provide a parent "driver" tag specifically to have a single point, yes. > Secondly, bus_dma_tag_create() supports a BUS_DMA_ALLOCNOW flag that > "pre-allocates enough resources to handle at least one map load > operation on this tag". However it also states "[t]his should not be > used for tags that only describe buffers that will be allocated with > bus_dmamem_alloc()" - does this mean that only one of bus_dmamap_load() > or bus_dmamap_alloc() should be used on a tag/mapping? Or is the > sense backwards (ie "don't specify BUS_DMA_ALLOCNOW for tags that are > only used as the parent for other tags and never mapped themselves")? > Or is there some other explanation. What happens usually now is that each thing you want to pre-alloc memory for using bus_dmamem_alloc() (such as descriptor rings) uses its own tag. This is somewhat mandated by the fact that bus_dmamem_alloc() doesn't take a size but gets the size to allocate from the tag. So usually a NIC driver will have 3 tags: 1 for the RX ring, 1 for packet data, and 1 for the TX ring. Some drivers have 2 tags for packet data, 1 for TX buffers and 1 for RX buffers. > Thirdly, bus_dmamap_load() has a uses a callback function to return > the actual mapping details. According to the man page, there is no > way to ensure that the callback occurs synchronously - a caller can > only request that bus_dmamap_load() fail if resources are not > immediately available. Despite this, many drivers pass 0 for flags > (allowing an asynchronous invocation of the callback) and then fail > (and cleanup) if bus_dmamap_load() returns EINPROGRESS. This appears > to open a race condition where the callback and cleanup could occur > simultaneously. Mitigating the race condition seems to rely on one of > the following two behaviours: > > a) The system is implicitly single-threaded when bus_dmamap_load() is > called (generally as part of the device attach() function). Whilst > this is true at boot time, it would not be true for a dynamically > loaded module. > > b) Passing BUS_DMA_ALLOCNOW to bus_dma_tag_create() guarantees that > the first bus_dmamap_load() on that tag will be synchronous. Is this > true? Whilst it appears to be implied, it's not explicitly stated. That doesn't really guarantee that either as the pool of bounce pages can be shared across multiple tags. I think what you might be missing is this: c) bus_dmamap_load() of a map returned from bus_dmamem_alloc() will always succeed synchronously. That is the only case other than BUS_DMA_NOWAIT where one can assume synchronous calls to the callback. Also, some bus_dma calls basically assumes BUS_DMA_NOWAIT such as bus_dmamap_load_mbuf() and bus_dmamap_load_mbuf_sg(). > Finally, what are the ordering requirements between the alloc, create, > load and sync functions? OpenBSD implies that the normal ordering is > create, alloc, load, sync whilst several FreeBSD drivers use > tag_create, alloc, load and then create. FreeBSD uses the same ordering as OpenBSD. I think you might be confused by the bus_dmamem_alloc() case. There are basically two cases, the first is preallocating a block of RAM to use for a descriptor or command ring: alloc_ring: bus_dma_tag_create(..., &ring_tag); /* Creates a map internally. */ bus_dmamem_alloc(ring_tag, &p, ..., &ring_map); /* Will not fail with EINPROGRESS. */ bus_dmamap_load(ring_tag, ring_map, p, ...); free_ring: bus_dmamap_unload(ring_tag, ring_map); bus_dmamem_free(ring_tag, p, ring_map); bus_dma_tag_destroy(ring_tag); The second case is when you want to handle data transfer requests (queue a packet or disk I/O request, etc.). For this the typical model in FreeBSD is to create a single tag and then pre-create a map for each descriptor or command: setup_data_maps: bus_dma_tag_create(..., &tag); for (i = 0; i < NUM_RXD; i++) bus_dmamap_create(tag, ..., &rxdata[i].map); for (i = 0; i < NUM_TXD; i++) bus_dmamap_create(tag, ..., &txdata[i].map); queue_a_rx_buffer: i = index_of_first_free_RX_descriptor; m = m_getcl(...); rxdata[i].mbuf = m; bus_dmamap_load_mbuf_sg(tag, rxdata[i].map, m, ...); /* populate s/g list in i'th RX descriptor ring */ bus_dmamap_sync(rx_ring_tag, rx_ring_map, ...); dequeue_an_rx_buffer_on_rx_completion: i = index_of_completed_receive_descriptor; bus_dmamap_sync(tag, rxdata[i].map, ...); bus_dmamap_unload(tag, rxdata[i].map); m = rxdata[i].mbuf; rxdata[i].mbuf = NULL; ifp->if_input(m); free_data_maps: for (i = 0; i < NUM_RXD; i++) bus_dmamap_destroy(tag, ..., rxdata[i].map); for (i = 0; i < NUM_TXD; i++_ bus_dmamap_destroy(tag, ..., txdata[i].map); bus_dma_tag_destroy(tag); In a typical NIC driver you will probably be doing alloc_ring and setup_data_maps at the same time during your attach routine. Similarly for free_ring and free_data_maps during detach. > As a side-note, the manpage does not document the behaviour when > bus_dmamap_destroy() or bus_dma_tag_destroy() are called whilst a > bus_dmamap_load() callback is queued. Is the callback cancelled > or do one or both destroy operations fail? Looking at amd64, if a tag has created maps it will fail with EBUSY on HEAD (this may not be in 7.x yet). If a map is destroyed that has bounce buffers in use it will fail with EBUSY as well. -- John Baldwin From pgj at FreeBSD.org Sat Apr 25 01:20:10 2009 From: pgj at FreeBSD.org (Gabor PALI) Date: Sat Apr 25 01:20:24 2009 Subject: SoC2009: Design and Implementation of Subsystem Support Libraries for Monitoring and Management Message-ID: <49F260E5.3080505@FreeBSD.org> Hi there, I am Gabor Pali from Hungary, a PhD student at Eotvos Lorand University, Budapest and Babes-Bolyai University, Cluj-Napoca. Offically, I have been working on FreeBSD for a year, and I got a doc commit bit for my Hungarian translations and documentation work, and now I also received a ports commit bit for my further contributions to the ports tree. I have been using FreeBSD for almost eight years now, and I am interested in development of operating systems. During Summer of Code 2009, I will be working on wrapper libraries for the network and process functions to support monitoring and management applications to avoid direct use of the FreeBSD kernel memory interface. This approach would allow the kernel implementation to change and monitoring applications to be extended without breaking applications and requiring them to be recompiled. For this project, my mentor will be Oleksandr Tymoshenko (gonzo@). A more detailed version of my Summer of Code 2009 proposal can be found on the FreeBSD Wiki: http://wiki.freebsd.org/PGJSoC2009 Feel free to review and comment on it. Cheers, :g From dforsyth at FreeBSD.org Sat Apr 25 19:52:12 2009 From: dforsyth at FreeBSD.org (David Forsythe) Date: Sat Apr 25 19:52:19 2009 Subject: SoC2009: libpkg, pkg tools rewrite Message-ID: Hi, I'm David Forsythe, 3rd year student at the University of Maryland, College Park. For SoC2008 I worked on added parallel build support and database locks to ports. I've been using FreeBSD for a while, and have taken particular interest in ports and packages. This summer I'll be working on creating a package library and using that library to rewrite the pkg tools. A package library has been discussed and even started before, but FreeBSD still does not have one. This summer I'd like to get enough of the library done to atleast have a new set of pkg tools completed with the current features, but ideally I'd like to get far enough to splice in some of the ideas I have for new features. Here's the wiki page: http://wiki.freebsd.org/SoC2009DavidForsythe Dave -- David Forsythe From zachriggle at gmail.com Sun Apr 26 00:36:20 2009 From: zachriggle at gmail.com (Zach Riggle) Date: Sun Apr 26 01:01:25 2009 Subject: GSoC introduction Message-ID: <91EAF988-F10A-48DA-B021-6C6D755CB300@gmail.com> Hello all! My name is Zach Righle, and I'm a sophomore at Michigan State University. I'll be working with George Neville-Neil this summer on TCP regression testing, to provide a suite of tests that FreeBSD can use to... prevent regression errors. Http://wiki.freebsd.org/ZachRiggle for more info Zach Riggle From perryh at pluto.rain.com Sun Apr 26 02:24:35 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Sun Apr 26 02:26:02 2009 Subject: SoC2009: libpkg, pkg tools rewrite In-Reply-To: References: Message-ID: <49f3c4b7.zX/ozx/uX5tTDhXT%perryh@pluto.rain.com> David Forsythe wrote: > This summer I'll be working on creating a package library and > using that library to rewrite the pkg tools ... As of last July there seemed to be no way to specify a mixture of local and remote repositories for pkg_add (discussion here): http://lists.freebsd.org/pipermail/freebsd-questions/2008-July/178710.html It would be good to get that capability added if it has not already been done. From christoph.mallon at gmx.de Sun Apr 26 07:29:20 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Sun Apr 26 07:29:27 2009 Subject: C99: Suggestions for style(9) Message-ID: <49F4070C.2000108@gmx.de> Hi hackers@, as some of you may have noticed, several years ago a new millenium started and a decade ago there was a new C standard. HEAD recently switched to C99 as default (actually gnu99, but that's rather close). So it's finally time to re-examine wether style(9) needs to be accomodated. The diff with the proposed changes is attached. Below are the changes with some further explanations. They are in the order as they appear in style(9). Maybe using all of these changes is a bit too big change at once, but I'd like some of them applied to style(9). So, please consider the proposed changes individually and not a as a all-or-nothing package. > -Do not put declarations > -inside blocks unless the routine is unusually complicated. > +Prefer declaring loop iterators in the for-statement to limit their scope. > .Bd -literal > - for (; cnt < 15; cnt++) { > + for (int cnt = 0; cnt < 15; cnt++) { [...] > -When declaring variables in functions declare them sorted by size, > -then in alphabetical order; multiple ones per line are okay. > +When declaring variables in functions declare them sorted in alphabetical order; > +prefer one declaration per line, especially when pointer declarators or > +initializations are involved. > If a line overflows reuse the type keyword. > .Pp > -Be careful to not obfuscate the code by initializing variables in > -the declarations. > -Use this feature only thoughtfully. > -DO NOT use function calls in initializers. > +Prefer initializing variables right at their declaration. > +When the value is not supposed to change in the function, make the variable > +const. > +This makes it easier for a reader to identify the where the value of a variable > +originates. > +Do not reuse the same variable in a different context, declare a new variable. > .Bd -literal > - struct foo one, *two; > - double three; > - int *four, five; > - char *six, seven, eight, nine, ten, eleven, twelve; > + struct foo *bar; > + struct foo baz = { 42, "qux" }; > > - four = myfunction(); > + FILE *const f = fopen("name", "r"); > + if (f == NULL) > + err("Failed to open file"); > + /* We can safely assume that f is not changed anymore, even if the > + * function is a hundred lines long */ This change is to reduce the scope of local variables. For reasons why this does not cost anything in terms of stack space, please see the last change, which adds explanations about local variables. Smaller scopes and distinct variables for distinct contexts make it easier for readers of the code to identify the def-use-chains of variables, because there are less places with assignments to a variable and the scope is smaller. Also, when a variable is initialised right at its declaration and is not supposed to change, you can emphasize this by making it const. I looked at older discussions regarding this topic and identified several concerns, which were raised. I'll address them below: - It does not add anything to the language. Well, yes, just like if, do, for, goto, the comma operator, compound assignment (+=, ...), ++/-- and many other things. All you need to be Turing complete is lambda calculus - there hardly can be less syntax. But, like all mentioned constructs, it makes the code more concise. - It leads to sloppy code. You could reuse another variable or should think again whether you really need this variable. Reusing variables in different contexts is error prone and bad for maintainability. You could reuse a variable, which is not as dead as you thought. More local variables cost nothing, especially no stack space, see the last proposed changed below. It is good to use more local variables, because it gives the reader a name, which carries information. Also it makes it easier for a reader (and the compiler!) to identify, which expressions are the same. You could repeat foo->long_name->even_longer_name[2 * i + 1] five times or just declare a local variable and cache the value to make it easier to read. It also enables the compiler to produce better warnings: If you declare a new variable, it is not initialised and if you do not initialise it on all paths before a use, the compiler will warn you. But if you reuse an older variable, it is already initialised by its former uses and so you get no warning, but operate on garbage values (the old value from the previous use). So it does not lead to slopyy code, but better code, which is easier to comprehend, the compiler can better help you to prevent bugs, and as a side effect the compiler can produce better code (aliasing is a major problem for common subexpression elimination). - You can determine the stack usage with all the variable declarations at the top. This is not true. There is no relation between the declared variables and the stack used. Especially, more stack than suggested by the declarations can be used due to various optimisations - less space can be used, too, of course. - It is harder to find the declaration of a variable. Every editor, which is more advanced than ed, has facilities to jump to the declaration of a variable (e.g. in vim it's "gd"). And most often this is not necessary, because the declaration is just a few lines above instead of all the way up at the top of the function, so no jumping around is required at all. - You could accidently shadow a variable. All modern compilers have warnings for this. FreeBSD uses -Wshadow for GCC (and all relevant compilers understand this very option). > -Values in > -.Ic return > -statements should be enclosed in parentheses. > -.Pp return with parentheses: Removed, because it does not improve maintainability in any way. There is no source for confusion here, so the rule even contradicts the rule, which states not to use redundant parentheses. Maybe, decades ago it was just a workaround for a broken compiler, which does not exist anymore. > -Old-style function declarations look like this: > -.Bd -literal > -static char * > -function(a1, a2, fl, a4) > - int a1, a2; /* Declare ints, too, don't default them. */ > - float fl; /* Beware double vs. float prototype differences. */ > - int a4; /* List in order declared. */ > -{ > -.Ed > -.Pp > -Use ANSI function declarations unless you explicitly need K&R compatibility. > +Use ANSI function declarations. Old-style function declarations: Removed, because there is no need to use them anymore. The C99 standard considers them obsolescent[1], too. All headers use prototype declarations, there's no reason to handle the function definitions different. Also they are a source of bugs - or did you know that the following is wrong: void wrong(char /* sic! */); void wrong(x) char x; {} And this is correct[2]: void right(int /* sic! */); void right(x) char x; {} (It's a bug in GCC that it does not complain about the former.) > - > -static void > -usage() > -{ > - /* Insert an empty line if the function has no local variables. */ Empty line when there are no local variables: Removed, because it does not improve readability and it actually hinders readability for very short functions, e.g. static inline functions, which just consist of one or two lines of code without any local variables except for parameters. Further, it makes even less sense with the changed recommendations for declarations. > +.Sh LOCAL VARIABLES > +Unaliased local variables are for free on modern compilers. > +They do not unconditionally use stack space. > +In fact there is no relation between their number and the used stack space. > +A local variable is guaranteed to be unaliased, if its address has not been > +taken (e.g. &i). > +Do not use the same local variable in different context just because it happens > +that the same type is needed. > +It does not improve the generated code in any way, but it makes it harder for a > +reader to determine all definitions and uses which belong together. > +Further, a new variable can be given a meaningful name (even if it is very > +short), which automatically serves as documentation and so improves > +comprehensibility. > +Especially avoid re-using variables, whose address has been taken: > +.Bd -literal > + int i; > + foo(&i); > + printf("%d\\n", i); > + for (i = 0; i != 10; ++i) { > + /* BAD: i will be needlessly moved to and from memory in > + * the loop, because its address was taken before. This > + * results in larger and slower code. > + * Declare a new variable for the loop instead. */ > + printf("%d\\n", i); > + } > +.Ed > + Last, but definitely not least, I added this paragraph about the use of local variables. This is to clarify, how today's compilers handle unaliased local variables. There is absolutely no need to reuse them in different contexts. Trying to optimise stack usage in this way is misguided and is a source of bugs, when a reused variable is not as dead as thought. For more reasons, please read the quoted diff. Maxim, you requested this paragraph: Does this addition suit you? Hopefully at least some of these suggestions are considered improvements and are applied to style(9). Regards Christoph [1] ISO/IEC 9899:1999 (E) ?6.11.6 and ?6.11.7 [2] ISO/IEC 9899:1999 (E) ?6.7.5.3:15 From kimelto at gmail.com Sun Apr 26 11:17:38 2009 From: kimelto at gmail.com (Julien Laffaye) Date: Sun Apr 26 11:17:44 2009 Subject: SoC2009: libpkg, pkg tools rewrite In-Reply-To: References: Message-ID: On Sat, Apr 25, 2009 at 9:20 PM, David Forsythe wrote: > Hi, > I'm David Forsythe, 3rd year student at the University of Maryland, College > Park. ?For SoC2008 I worked on added parallel build support and database > locks to ports. ?I've been using FreeBSD for a while, and have taken > particular interest in ports and packages. > This summer I'll be working on creating a package library and using that > library to rewrite the pkg tools. ?A package library has been discussed and > even started before, but FreeBSD still does not have one. ?This summer I'd > like to get enough of the library done to atleast have a new set of pkg > tools completed with the current features, but ideally I'd like to get far > enough to splice in some of the ideas I have for new features. > Here's the wiki page: http://wiki.freebsd.org/SoC2009DavidForsythe > Dave Hi, It'll be nice if libpkg can deal with all the infos in the INDEX with an elegant API. You have to read the packages names in the INDEX for `pkg_version -I` but maybe other tools will enjoy to get other infos (especially the one line description, the categories and the run time dependencies). So basically, an API which understand "give me all the packages names you have in the INDEX", "give me the description for _this_ package", "give me all the names plus the categories", "give me..." Regards, Julien Laffaye From anchie at fer.hr Sun Apr 26 12:38:49 2009 From: anchie at fer.hr (Ana Kukec) Date: Sun Apr 26 12:38:56 2009 Subject: GSoC - SeND Message-ID: <49F4517E.5080005@fer.hr> Hi all, I am Ana Kukec, a research assistant and a PhD student at University of Zagreb. I will be working on the IPv6 Secure Neighbor Discovery (SeND - rfc3971, rfc4861) - the implementation of native kernel APIs for FreeBSD, within GSoC, with my mentor Bjoern Zeeb. More informations will be provided on http://wiki.freebsd.org/SOC2009AnaKukec. Regards, Ana From mitchell at wyatt672earp.force9.co.uk Sun Apr 26 17:01:00 2009 From: mitchell at wyatt672earp.force9.co.uk (Frank Mitchell) Date: Sun Apr 26 17:01:07 2009 Subject: Ext2fs & DVD+RW Message-ID: <200904261526.32528.mitchell@wyatt672earp.force9.co.uk> Improved Ext2fs: What a great idea. I like trying different Unix flavours, and Ext2fs is the only filesystem they all understand. I put all my data on a separate Partition formatted Ext2, and every so often I'm glad: Like the recent occasion when the NetBSD Boot Selector altered something and prevented FreeBSD from starting, leaving me with no alternative but to reinstall. Also, under Linux, you can use Ext2fs on DVD+RW. Plain DVD-RW is unsuitable because it uses Superblocks of 16*2048 bytes, but CD-RW should be okay. Currently you can't do this under FreeBSD, probably because CD and DVD use 2048-byte Sectors, and FreeBSD wants 512-byte. Somebody said you can put UFS on DVD+RW, but I couldn't get that to work. So possibly Ext2fs would be a viable alternative to UDF, though I don't know enough about Filesystems myself to tell whether this idea has some enormous drawback. Yours truly: Frank Mitchell ======================================================================== From: Aditya Sarawgi I'm Aditya Sarawgi from India. I will be working on FreeBSD's ext2fs as a part of this year's summer of code program. I will be improving the current implementation and I will also rewrite parts of ext2fs under GPL. My mentor is Ulf Lilleengen. For more details you can visit http://wiki.freebsd.org/SOC2009AdityaSarawgi Cheers, Aditya Sarawgi From mitchell at wyatt672earp.force9.co.uk Sun Apr 26 17:01:10 2009 From: mitchell at wyatt672earp.force9.co.uk (Frank Mitchell) Date: Sun Apr 26 17:01:17 2009 Subject: cd9660 Lowercasing Message-ID: <200904261455.26952.mitchell@wyatt672earp.force9.co.uk> I've developed a CD/DVD Backup Utility using the Enhanced Volume Descriptor specified in ISO9660:1999. It doesn't have Rock Ridge yet, so the first thing you notice on mounting is the automatic Lowercase, which interferes with Backup Verification using "diff -qr". There's a simple solution using the "gens" mount option, which has Case Preservation as a side-effect, but it's still annoying. There must be some reason behind it, because NetBSD and Linux have a similar feature, with options to disable it like: "nomaplcase" and "map=off". But their manpages make it look like a throwback to MS-DOS, and a time when all filenames were accessed from the Primary Volume Descriptor. By default you can't have filenames in ASCII using the Supplementary or Enhanced Volume Descriptors either. I think I tracked this feature down to cd9660_util.c, in Function isofntrans, around Line 200: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< for (; infn != infnend; ) { infn += isochar(infn, infnend, joliet_level, &c, &clen, flags, handle); if (!original && !joliet_level && c >= 'A' && c <= 'Z') c += ('a' - 'A'); else if (!original && c == ';') { outp -= (d == '.'); break; } d = c; while(clen--) *outp++ = c >> (clen << 3); } >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This only alters ASCII characters. Accented uppercase letters from the top half of ISO8859-1 are unaffected. And it doesn't apply to Joliet either. I don't see the point. Why not just zap it away? Yours Truly: Frank Mitchell From pvaibhav at freebsd.org Sun Apr 26 18:13:45 2009 From: pvaibhav at freebsd.org (Prashant Vaibhav) Date: Sun Apr 26 18:14:17 2009 Subject: SoC 2009: Redesign the callout API Message-ID: <66b068eb0904261052q678320bcm63618c65bba2c429@mail.gmail.com> Hello, I am Prashant Vaibhav, a 22 year old Indian guy (undergrad from Germany) and I'm a Google Summer of Code participant for 2009. My work will be focused on improving the callout/timeout API in the kernel. It was inspired by the tickless kernel feature present in XNU and Linux (since recent releases), and discussions made on the mailing lists a few years back about problems with the current implementation. Basically, the callout API will be redesigned to use opaque 'ticks' instead of explicitly x/HZ, and provide for certain additional features (like specifying a time range while arming). Beneath the hood, the implementation will be completely redesigned to use more efficient method of storing the callout list, and using any available timer in a hardware-independent way. It will then be extended to support deadline mode on capable systems (ie. dynamic HZ). This means for machines having an HPET or similar deadline-capable timer with a long range, the kernel will be completely tickless. On other machines with only a PIT, the 'ticks' could be as infrequent as a few times a second to once every 2 seconds, instead of 100 Hz. The major advantages are that the usage of hardware-dependent ticks and abstracting out timer hardware will make higher-resolution callouts possible, and in turn, making the kernel tickless will allow for better power savings, more efficient usage of CPU clock cycles, and better performance in virtual machines. More details can be found at the wiki page: http://wiki.freebsd.org/SOC2009PrashantVaibhav Best regards, Prashant Vaibhav From marinosi at ceid.upatras.gr Sun Apr 26 19:07:19 2009 From: marinosi at ceid.upatras.gr (Ilias Marinos) Date: Sun Apr 26 19:07:26 2009 Subject: SoC 2009: Application-Specific Audit Trails Message-ID: <20090426184404.GA97073@marinos.ceid.upatras.gr> Hi people, my name is Ilias Marinos and I am an undergraduate student at Computer Engineering & Informatics Department at University of Patras, Greece. I was accepted to work this summer with my mentor Robert Watson, on designing and impelementing an application-specific audit system, as part of the TrustedBSD project. More information about me and my project can be found at: http://wiki.freebsd.org/IliasMarinos Regards, Ilias Marinos -- echo "Sysadmin know better bash than english." | sed s/min/mins/ \ | sed 's/better bash/bash better/' From pieter at degoeje.nl Mon Apr 27 00:02:49 2009 From: pieter at degoeje.nl (Pieter de Goeje) Date: Mon Apr 27 00:03:02 2009 Subject: ACPI-fast default timecounter, but HPET 83% faster Message-ID: <200904270150.31912.pieter@degoeje.nl> Dear hackers, While fiddling with the sysctl kern.timecounter.hardware, I found out that on my system HPET is significantly faster than ACPI-fast. Using the program below I measured the number of clock_gettime() calls the system can execute per second. I ran the program 10 times for each configuration and here are the results: x ACPI-fast + HPET +-------------------------------------------------------------------------+ |x +| |x +| |x ++| |x ++| |x ++| |x ++| |A |A| +-------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 822032 823752 823551 823397.8 509.43254 + 10 1498348 1506862 1502830 1503267.4 2842.9779 Difference at 95.0% confidence 679870 +/- 1918.94 82.5688% +/- 0.233052% (Student's t, pooled s = 2042.31) System details: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz (3200.02-MHz 686-class CPU), Gigabyte P35-DS3R motherboard running i386 -CURRENT updated today. Unfortunately I only have one system with a HPET timecounter, so I cannot verify these results on another system. If similar results are obtained on other machines, I think the HPET timecounter quality needs to be increased beyond that of ACPI-fast. Regards, Pieter de Goeje ----- 8< ----- clock_gettime.c ----- 8< ------ #include #include #include #define COUNT 1000000 int main() { struct timespec ts_start, ts_stop, ts_read; double time; int i; clock_gettime(CLOCK_MONOTONIC, &ts_start); for(i = 0; i < COUNT; i++) { clock_gettime(CLOCK_MONOTONIC, &ts_read); } clock_gettime(CLOCK_MONOTONIC, &ts_stop); time = (ts_stop.tv_sec - ts_start.tv_sec) + (ts_stop.tv_nsec - ts_start.tv_nsec) * 1E-9; printf("%.0f\n", COUNT / time); } From yanefbsd at gmail.com Mon Apr 27 03:00:32 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Mon Apr 27 03:00:44 2009 Subject: ACPI-fast default timecounter, but HPET 83% faster In-Reply-To: <200904270150.31912.pieter@degoeje.nl> References: <200904270150.31912.pieter@degoeje.nl> Message-ID: <7d6fde3d0904261927s1a67cf85jc982c1a68e30e081@mail.gmail.com> On Sun, Apr 26, 2009 at 4:50 PM, Pieter de Goeje wrote: > Dear hackers, > > While fiddling with the sysctl kern.timecounter.hardware, I found out that on > my system HPET is significantly faster than ACPI-fast. Using the program > below I measured the number of clock_gettime() calls the system can execute > per second. I ran the program 10 times for each configuration and here are > the results: > > x ACPI-fast > + HPET > +-------------------------------------------------------------------------+ > |x ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? +| > |x ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? +| > |x ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?++| > |x ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?++| > |x ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?++| > |x ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?++| > |A ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|A| > +-------------------------------------------------------------------------+ > ? ?N ? ? ? ? ? Min ? ? ? ? ? Max ? ? ? ?Median ? ? ? ? ? Avg ? ? ? ?Stddev > x ?10 ? ? ? ?822032 ? ? ? ?823752 ? ? ? ?823551 ? ? ?823397.8 ? ? 509.43254 > + ?10 ? ? ? 1498348 ? ? ? 1506862 ? ? ? 1502830 ? ? 1503267.4 ? ? 2842.9779 > Difference at 95.0% confidence > ? ? ? ?679870 +/- 1918.94 > ? ? ? ?82.5688% +/- 0.233052% > ? ? ? ?(Student's t, pooled s = 2042.31) > > System details: Intel(R) Core(TM)2 Duo CPU E6750 ?@ 2.66GHz (3200.02-MHz > 686-class CPU), Gigabyte P35-DS3R motherboard running i386 -CURRENT updated > today. > > Unfortunately I only have one system with a HPET timecounter, so I cannot > verify these results on another system. If similar results are obtained on > other machines, I think the HPET timecounter quality needs to be increased > beyond that of ACPI-fast. > > Regards, > > Pieter de Goeje > > ----- 8< ----- clock_gettime.c ----- 8< ------ > #include > #include > #include > > #define COUNT 1000000 > > int main() { > ? ? ? ?struct timespec ts_start, ts_stop, ts_read; > ? ? ? ?double time; > ? ? ? ?int i; > > ? ? ? ?clock_gettime(CLOCK_MONOTONIC, &ts_start); > ? ? ? ?for(i = 0; i < COUNT; i++) { > ? ? ? ? ? ? ? ?clock_gettime(CLOCK_MONOTONIC, &ts_read); > ? ? ? ?} > ? ? ? ?clock_gettime(CLOCK_MONOTONIC, &ts_stop); > > ? ? ? ?time = (ts_stop.tv_sec - ts_start.tv_sec) + (ts_stop.tv_nsec - > ts_start.tv_nsec) * 1E-9; > ? ? ? ?printf("%.0f\n", COUNT / time); > } I'm seeing similar results. [root@orangebox /usr/home/gcooper]# dmesg | grep 'Timecounter "' Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Timecounter "HPET" frequency 14318180 Hz quality 900 [root@orangebox /usr/home/gcooper]# ./cgt 1369355 [root@orangebox /usr/home/gcooper]# sysctl kern.timecounter.hardware="ACPI-fast" kern.timecounter.hardware: HPET -> ACPI-fast [root@orangebox /usr/home/gcooper]# ./cgt 772289 Why's the default ACPI-fast? For power-saving functionality or because of the `quality' factor? What is the criteria that determines the `quality' of a clock as what's being reported above (I know what determines the quality of a clock visually from a oscilloscope =])? Thanks, -Garrett From yanefbsd at gmail.com Mon Apr 27 03:13:00 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Mon Apr 27 03:13:08 2009 Subject: SoC2009: Design and Implementation of Subsystem Support Libraries for Monitoring and Management In-Reply-To: <49F260E5.3080505@FreeBSD.org> References: <49F260E5.3080505@FreeBSD.org> Message-ID: <7d6fde3d0904262012r7a0e176coc5d0cbcdbfbfec01@mail.gmail.com> On Fri, Apr 24, 2009 at 6:01 PM, Gabor PALI wrote: > Hi there, > > I am Gabor Pali from Hungary, a PhD student at Eotvos Lorand University, > Budapest and Babes-Bolyai University, Cluj-Napoca. ?Offically, I have > been working on FreeBSD for a year, and I got a doc commit bit for my > Hungarian translations and documentation work, and now I also received a > ports commit bit for my further contributions to the ports tree. ?I have > been using FreeBSD for almost eight years now, and I am interested in > development of operating systems. > > During Summer of Code 2009, I will be working on wrapper libraries for > the network and process functions to support monitoring and management > applications to avoid direct use of the FreeBSD kernel memory interface. > This approach would allow the kernel implementation to change and > monitoring applications to be extended without breaking applications and > requiring them to be recompiled. ?For this project, my mentor will be > Oleksandr Tymoshenko (gonzo@). > > A more detailed version of my Summer of Code 2009 proposal can be found > on the FreeBSD Wiki: > > http://wiki.freebsd.org/PGJSoC2009 > > > Feel free to review and comment on it. > > > Cheers, > :g Sounds like good work to do Gabor. Good luck on the project :). Cheers, -Garrett From zhaoshuai at freebsd.org Mon Apr 27 03:29:50 2009 From: zhaoshuai at freebsd.org (Zhao Shuai) Date: Mon Apr 27 03:30:21 2009 Subject: GSoC - FIFO Optimizations Message-ID: <8126ef5c0904262002p58b9a494l29fa20ef0fc34547@mail.gmail.com> Hi there, My name is Zhao Shuai and I am a postgraduate from China. This summer I will work on FIFO optimization project with my mentor John Baldwin. More details on my project, visit the wiki page: http://wiki.freebsd.org/SOC2009ZhaoShuai -- Regards, Zhao From joerg at britannica.bec.de Mon Apr 27 13:46:31 2009 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Mon Apr 27 13:46:48 2009 Subject: ACPI-fast default timecounter, but HPET 83% faster In-Reply-To: <200904270150.31912.pieter@degoeje.nl> References: <200904270150.31912.pieter@degoeje.nl> Message-ID: <20090427134617.GA688@britannica.bec.de> On Mon, Apr 27, 2009 at 01:50:31AM +0200, Pieter de Goeje wrote: > While fiddling with the sysctl kern.timecounter.hardware, I found out > that on my system HPET is significantly faster than ACPI-fast. I did some extensive testing on a variety of AMD and Intel boards and never found a system where HPET is slower than ACPI-fast. In addition, HPET provides a higher resolution. Joerg From jan at melen.org Mon Apr 27 13:45:32 2009 From: jan at melen.org (Jan Melen) Date: Mon Apr 27 13:53:45 2009 Subject: IPsec in GENERIC kernel config Message-ID: <49F5B6F8.4040808@melen.org> Hi, Again when I compiled a custom kernel just to enable IPsec in the FreeBSD kernel it came to my mind why is it so that the IPsec is not enabled by default in the GENERIC kernel configuration file? At least for me the GENERIC kernel configuration would do just fine if the IPsec would be enabled in it by default. Now I have to build a custom kernel just for IPsec btw IPsec is even mandatory for a host supporting IPv6. Regards, Jan From amdmi3 at amdmi3.ru Mon Apr 27 16:10:17 2009 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Mon Apr 27 16:10:25 2009 Subject: [patch] kernel iconv improvements Message-ID: <20090427160930.GB48365@hades.panopticon> Hi! Here's a little improvement for kernel iconv. It makes kiconv ignore case of character set names (and also store them in uppercase for consistency), so mount_cd9660 -C koi8-r /dev/acd0 /mnt mount_cd9660 -C KOI8-r /dev/acd0 /mnt mount_cd9660 -C KOI8-R /dev/acd0 /mnt mount_cd9660 -C Koi8-r /dev/acd0 /mnt will no longer lead to loading four similar charset conversion tables instead of one. See also ports/sysutils/kiconvtool - can it be integrated into the base system? The purpose of all this is more convenient and effective handling of filesystem charset conversion (especially for usermounts). --- iconv.c.patch begins here --- Index: sys/libkern/iconv.c =================================================================== --- sys/libkern/iconv.c (revision 191469) +++ sys/libkern/iconv.c (working copy) @@ -33,6 +33,7 @@ #include __FBSDID("$FreeBSD$"); +#include #include #include #include @@ -171,8 +172,8 @@ struct iconv_cspair *csp; TAILQ_FOREACH(csp, &iconv_cslist, cp_link) { - if (strcmp(csp->cp_to, to) == 0 && - strcmp(csp->cp_from, from) == 0) { + if (strcasecmp(csp->cp_to, to) == 0 && + strcasecmp(csp->cp_from, from) == 0) { if (cspp) *cspp = csp; return 0; @@ -207,12 +208,16 @@ if (!ucsto) { strcpy(cp, to); csp->cp_to = cp; - cp += strlen(cp) + 1; + for (; *cp; cp++) + *cp = toupper(*cp); + cp++; } else csp->cp_to = iconv_unicode_string; if (!ucsfrom) { strcpy(cp, from); csp->cp_from = cp; + for (; *cp; cp++) + *cp = toupper(*cp); } else csp->cp_from = iconv_unicode_string; csp->cp_data = data; --- iconv.c.patch ends here --- -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From sam at freebsd.org Mon Apr 27 18:08:40 2009 From: sam at freebsd.org (Sam Leffler) Date: Mon Apr 27 18:08:47 2009 Subject: IPsec in GENERIC kernel config In-Reply-To: <49F5B6F8.4040808@melen.org> References: <49F5B6F8.4040808@melen.org> Message-ID: <49F5F4A6.8050902@freebsd.org> Jan Melen wrote: > Hi, > > Again when I compiled a custom kernel just to enable IPsec in the > FreeBSD kernel it came to my mind why is it so that the IPsec is not > enabled by default in the GENERIC kernel configuration file? At least > for me the GENERIC kernel configuration would do just fine if the > IPsec would be enabled in it by default. Now I have to build a custom > kernel just for IPsec btw IPsec is even mandatory for a host > supporting IPv6. IPsec incurs a performance hit. Fix that and it can be enabled in GENERIC. Sam From das at FreeBSD.ORG Mon Apr 27 18:38:17 2009 From: das at FreeBSD.ORG (David Schultz) Date: Mon Apr 27 18:38:24 2009 Subject: SoC 2009: BSD-licensed libiconv in base system In-Reply-To: References: Message-ID: <20090427183836.GA10793@zim.MIT.EDU> On Thu, Apr 23, 2009, G?bor K?vesd?n wrote: > Hello all, > > my name is G?bor K?vesd?n. I'm a Hungarian student and I'll be working on > a BSD-licensed libiconv implementation for FreeBSD during this year's > Summer of Code program. It'll be based on NetBSD's Citrus iconv but there > is a lot to do besides porting. My mentor is Xin Li. Nice. I'm sure many people will thank you for this. One complaint I've heard about both our wide character implementation and Citrus iconv is that the internal (wchar_t) encoding depends on the current locale. (Basically it uses a packed binary version of whatever the external representation is.) The relevant standards allow this, but it can be a pain for application and library writers. One thing to think about is whether it would make more sense to standardize on something like UCS-4 for the internal representation. From bzeeb-lists at lists.zabbadoz.net Mon Apr 27 18:46:55 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Apr 27 18:47:03 2009 Subject: IPsec in GENERIC kernel config In-Reply-To: <49F5F4A6.8050902@freebsd.org> References: <49F5B6F8.4040808@melen.org> <49F5F4A6.8050902@freebsd.org> Message-ID: <20090427182917.W15361@maildrop.int.zabbadoz.net> On Mon, 27 Apr 2009, Sam Leffler wrote: Hi, > Jan Melen wrote: >> Hi, >> >> Again when I compiled a custom kernel just to enable IPsec in the FreeBSD >> kernel it came to my mind why is it so that the IPsec is not enabled by >> default in the GENERIC kernel configuration file? At least for me the >> GENERIC kernel configuration would do just fine if the IPsec would be >> enabled in it by default. Now I have to build a custom kernel just for >> IPsec btw IPsec is even mandatory for a host supporting IPv6. > IPsec incurs a performance hit. Fix that and it can be enabled in GENERIC. There is even a PR for this: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/128030 -- Bjoern A. Zeeb The greatest risk is not taking one. From kientzle at freebsd.org Mon Apr 27 19:13:57 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Mon Apr 27 19:14:27 2009 Subject: SoC 2009: BSD-licensed libiconv in base system In-Reply-To: <20090427183836.GA10793@zim.MIT.EDU> References: <20090427183836.GA10793@zim.MIT.EDU> Message-ID: <49F5FE45.2090101@freebsd.org> David Schultz wrote: > ... whether it would make more sense to standardize on something like > UCS-4 for the internal representation. YES. Without this, wchar_t is useless. Tim From joerg at britannica.bec.de Mon Apr 27 19:33:24 2009 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Mon Apr 27 19:33:31 2009 Subject: SoC 2009: BSD-licensed libiconv in base system In-Reply-To: <49F5FE45.2090101@freebsd.org> References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> Message-ID: <20090427193326.GA7654@britannica.bec.de> On Mon, Apr 27, 2009 at 11:49:41AM -0700, Tim Kientzle wrote: > David Schultz wrote: >> ... whether it would make more sense to standardize on something like >> UCS-4 for the internal representation. > > YES. Without this, wchar_t is useless. I strongly disagree. Everything can be represented as UCS-4 is a bad assumption, but something Americans and Europeans naturally don't have to care about. Joerg From das at FreeBSD.ORG Mon Apr 27 19:48:43 2009 From: das at FreeBSD.ORG (David Schultz) Date: Mon Apr 27 19:48:49 2009 Subject: SoC 2009: BSD-licensed libiconv in base system In-Reply-To: <20090427193326.GA7654@britannica.bec.de> References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> Message-ID: <20090427194904.GA11137@zim.MIT.EDU> On Mon, Apr 27, 2009, Joerg Sonnenberger wrote: > On Mon, Apr 27, 2009 at 11:49:41AM -0700, Tim Kientzle wrote: > > David Schultz wrote: > >> ... whether it would make more sense to standardize on something like > >> UCS-4 for the internal representation. > > > > YES. Without this, wchar_t is useless. > > I strongly disagree. Everything can be represented as UCS-4 is a bad > assumption, but something Americans and Europeans naturally don't have > to care about. ...but isn't this moot at present because there are no widely-accepted encodings that include characters that aren't supported by UCS-4? Citrus doesn't seem to support any such encodings in any case. If this ever really becomes an issue, we could always stuff locale-dependent encodings into unused UCS-4 code pages. However, it doesn't seem worthwhile to deliberately burden programmers over concerns that are presently, and for the foreseeable future, hypothetical. From joerg at britannica.bec.de Mon Apr 27 19:49:44 2009 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Mon Apr 27 19:49:51 2009 Subject: SoC 2009: BSD-licensed libiconv in base system In-Reply-To: <49F5FE45.2090101@freebsd.org> References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> Message-ID: <20090427193326.GA7654@britannica.bec.de> On Mon, Apr 27, 2009 at 11:49:41AM -0700, Tim Kientzle wrote: > David Schultz wrote: >> ... whether it would make more sense to standardize on something like >> UCS-4 for the internal representation. > > YES. Without this, wchar_t is useless. I strongly disagree. Everything can be represented as UCS-4 is a bad assumption, but something Americans and Europeans naturally don't have to care about. Joerg From joerg at britannica.bec.de Mon Apr 27 20:08:18 2009 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Mon Apr 27 20:08:25 2009 Subject: SoC 2009: BSD-licensed libiconv in base system In-Reply-To: <20090427194904.GA11137@zim.MIT.EDU> References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> Message-ID: <20090427200821.GA6665@britannica.bec.de> On Mon, Apr 27, 2009 at 03:49:04PM -0400, David Schultz wrote: > ...but isn't this moot at present because there are no > widely-accepted encodings that include characters that > aren't supported by UCS-4? Citrus doesn't seem to support > any such encodings in any case. "Just" using UCS-4 not necessarily buys you the desired affect. Keep in mind that UCS-4 is still a variable width encoding, as soon as you factor combining characters and some other interesting parts in. Joerg From das at FreeBSD.ORG Tue Apr 28 02:42:21 2009 From: das at FreeBSD.ORG (David Schultz) Date: Tue Apr 28 02:42:27 2009 Subject: SoC 2009: BSD-licensed libiconv in base system In-Reply-To: <20090427200821.GA6665@britannica.bec.de> References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> <20090427200821.GA6665@britannica.bec.de> Message-ID: <20090428024246.GA12887@zim.MIT.EDU> On Mon, Apr 27, 2009, Joerg Sonnenberger wrote: > On Mon, Apr 27, 2009 at 03:49:04PM -0400, David Schultz wrote: > > ...but isn't this moot at present because there are no > > widely-accepted encodings that include characters that > > aren't supported by UCS-4? Citrus doesn't seem to support > > any such encodings in any case. > > "Just" using UCS-4 not necessarily buys you the desired affect. > Keep in mind that UCS-4 is still a variable width encoding, as soon as > you factor combining characters and some other interesting parts in. This is true, but unfortunately C99 wasn't really designed to support combining characters. I don't understand how this relates to the present discussion. From nike_d at cytexbg.com Tue Apr 28 06:58:22 2009 From: nike_d at cytexbg.com (Niki Denev) Date: Tue Apr 28 06:58:29 2009 Subject: IPsec in GENERIC kernel config In-Reply-To: <20090427182917.W15361@maildrop.int.zabbadoz.net> References: <49F5B6F8.4040808@melen.org> <49F5F4A6.8050902@freebsd.org> <20090427182917.W15361@maildrop.int.zabbadoz.net> Message-ID: <2e77fc10904272333j60151a0au2682ae39e201c015@mail.gmail.com> On Mon, Apr 27, 2009 at 9:29 PM, Bjoern A. Zeeb wrote: > On Mon, 27 Apr 2009, Sam Leffler wrote: > > Hi, > >> Jan Melen wrote: >>> >>> Hi, >>> >>> Again when I compiled a custom kernel just to enable IPsec in the FreeBSD >>> kernel it came to my mind why is it so that the IPsec is not enabled by >>> default in the GENERIC kernel configuration file? At least for me the >>> GENERIC kernel configuration would do just fine if the IPsec would be >>> enabled in it by default. Now I have to build a custom kernel just for IPsec >>> btw IPsec is even mandatory for a host supporting IPv6. >> >> IPsec incurs a performance hit. ?Fix that and it can be enabled in >> GENERIC. > > There is even a PR for this: > http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/128030 > > -- > Bjoern A. Zeeb ? ? ? ? ? ? ? ? ? ? ?The greatest risk is not taking one. Hello, Does anyone have any numbers on how much the performance degrades with IPSEC enabled? I'm just curious. Regards, Niki From gabor at FreeBSD.org Tue Apr 28 08:50:38 2009 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Tue Apr 28 08:50:45 2009 Subject: SoC 2009: BSD-licensed libiconv in base system In-Reply-To: <20090427183836.GA10793@zim.MIT.EDU> References: <20090427183836.GA10793@zim.MIT.EDU> Message-ID: <49F6BF6C.1050903@FreeBSD.org> David Schultz escribi?: > On Thu, Apr 23, 2009, G?bor K?vesd?n wrote: > >> Hello all, >> >> my name is G?bor K?vesd?n. I'm a Hungarian student and I'll be working on >> a BSD-licensed libiconv implementation for FreeBSD during this year's >> Summer of Code program. It'll be based on NetBSD's Citrus iconv but there >> is a lot to do besides porting. My mentor is Xin Li. >> > > Nice. I'm sure many people will thank you for this. > I hope my work will be useful for the community. Btw, I suspected that you might be interested in this and I wrote a mail personally to you when I was looking for a mentor. Then I didn't resend it because delphij@ volunteered to be my mentor. Have you ever got that mail? If you find this an interesting project your comments, review, etc. are still highly welcome. > One complaint I've heard about both our wide character > implementation and Citrus iconv is that the internal (wchar_t) > encoding depends on the current locale. (Basically it uses a > packed binary version of whatever the external representation is.) > The relevant standards allow this, but it can be a pain for > application and library writers. One thing to think about is > whether it would make more sense to standardize on something like > UCS-4 for the internal representation. > I haven't got to such details yet, so I didn't know this. But UCS-4 seems to be reasonable for me. Cheers, -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From gabor at FreeBSD.org Tue Apr 28 09:25:38 2009 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Tue Apr 28 09:25:46 2009 Subject: SoC 2009: BSD-licensed libiconv in base system In-Reply-To: <20090427194904.GA11137@zim.MIT.EDU> References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> Message-ID: <49F6C7A1.6070708@FreeBSD.org> David Schultz escribi?: > On Mon, Apr 27, 2009, Joerg Sonnenberger wrote: > >> On Mon, Apr 27, 2009 at 11:49:41AM -0700, Tim Kientzle wrote: >> >>> David Schultz wrote: >>> >>>> ... whether it would make more sense to standardize on something like >>>> UCS-4 for the internal representation. >>>> >>> YES. Without this, wchar_t is useless. >>> >> I strongly disagree. Everything can be represented as UCS-4 is a bad >> assumption, but something Americans and Europeans naturally don't have >> to care about. >> > > ...but isn't this moot at present because there are no > widely-accepted encodings that include characters that > aren't supported by UCS-4? Citrus doesn't seem to support > any such encodings in any case. > Citrus is based on UCS-4 as an internal encoding, just like the another BSD-licensed iconv library. This is a barrier to support encodings that aren't supported by UCS-4. > If this ever really becomes an issue, we could always stuff > locale-dependent encodings into unused UCS-4 code pages. > However, it doesn't seem worthwhile to deliberately burden > programmers over concerns that are presently, and for the > foreseeable future, hypothetical. > I'm not a Unicode expert, but isn't the reason of periodical standard reviews and changes to cover more and more human languages? We could just support the latest Unicode standard and let the Unicode workgroups map those new characters into unused code points. The Latin-based, Cyrillic, Devanagari and CJK encodings are well-supported, I think. I don't know too much about CJK encondings, though, if the thousands of ideographs are all supported or not. But I'd say the most significant languages that are used on the Internet are supported, the rest might have another problems... [OFF] It's possible that there are little poor countries with an own writing system but probably their writing system is unsupported because the starvation, poorness and lack of water and electricity are more serious problems there. My ex-girlfriend is working in Nepal in a cooperation program (it's kinda scholarship) and she told me that they only have electricity in 8 hours a day, 4 during the night and 4 during the day. There are no sidewalks for pedestrians, they go along with the cars on the street and the pollution is extremely high. Even this country's encoding is supported. What I am trying to say is that countries with unsupported languages probably won't really care about character encodings if they rarely have computers... I can just hope that their living conditions will get better and their language will be supported. I can also hope that the Unicode people will focus more on these countries instead of fucking up the time with fictionary languages from fairy tales... [1] Probably I'll go to visit her in Nepal in January, it will be an interesting experience. I'll check if I can help the IT world there with anything. [ON] Another idea to consider. Are all of our utilities wchar-clean? What about library functions? (regex is surely not) Do we lack any important utility or library? (we still do lack iconv and gettext and what else...?) What about standards, like C99 wchar functions? Is there something missing? What about POSIX if it has something related? Personally, I think that these are more important questions than support of some extremely rare languages. It's worth to consider how to deal with them later but the basic problems need a higher priority. [1] http://en.wikipedia.org/wiki/Tengwar#Unicode Cheers, -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From joerg at britannica.bec.de Tue Apr 28 10:19:16 2009 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Tue Apr 28 10:19:23 2009 Subject: SoC 2009: BSD-licensed libiconv in base system In-Reply-To: <20090428024246.GA12887@zim.MIT.EDU> References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> <20090427200821.GA6665@britannica.bec.de> <20090428024246.GA12887@zim.MIT.EDU> Message-ID: <20090428101919.GA552@britannica.bec.de> On Mon, Apr 27, 2009 at 10:42:46PM -0400, David Schultz wrote: > On Mon, Apr 27, 2009, Joerg Sonnenberger wrote: > > On Mon, Apr 27, 2009 at 03:49:04PM -0400, David Schultz wrote: > > > ...but isn't this moot at present because there are no > > > widely-accepted encodings that include characters that > > > aren't supported by UCS-4? Citrus doesn't seem to support > > > any such encodings in any case. > > > > "Just" using UCS-4 not necessarily buys you the desired affect. > > Keep in mind that UCS-4 is still a variable width encoding, as soon as > > you factor combining characters and some other interesting parts in. > > This is true, but unfortunately C99 wasn't really designed to > support combining characters. I don't understand how this relates > to the present discussion. The main reason people want to use wchar_t is because they want to use a fixed width presentation of characters. Just using UCS-4 doesn't give you that if you ever want to support Level 2 and higher. It also highlights UCS-4 is not that state independent as it is often thought to be. That is again something undesirable. Joerg From sobomax at FreeBSD.org Tue Apr 28 10:45:55 2009 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Tue Apr 28 10:46:02 2009 Subject: Improving geom_mirror(4)'s read balancing In-Reply-To: References: <49F6CA67.6030302@FreeBSD.org> Message-ID: <49F6DA03.2010404@FreeBSD.org> Ivan Voras wrote: > Maxim Sobolev wrote: > >> The patch is available here: >> http://sobomax.sippysoft.com/~sobomax/geom_mirror.diff. I would like to >> get input on the functionality/code itself, as well on what is the best >> way to add this functionality. Right now, it's part of the round-robin >> balancing code. Technically, it could be added as a separate new >> balancing method, but for the reasons outlined above I really doubt >> having "pure" round-robin has any practical value now. The only case >> where previous behavior might be beneficial is with solid-state/RAM >> disks where there is virtually no seek time, so that by reading close >> sectors from two separate disks one could actually get a better speed. >> At the very least, the new method should become default, while "old >> round-robin" be another option with clearly documented shortcomings. I >> would really like to hear what people think about that. > > Have you perhaps seen this: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/113885 > > I'm using the patch in the PR and it helps a bit, similar to what you > have seen. Pawel is silent about the issue so I guess it can also be > taken as silent approval :) Oh, great! I am curious as to if there is any background behind "distance to use delay" metric? To me it seems the current number of outstanding requests is much more important when selecting between disk X and disk Y. I am not a storage expert, so that I could be wrong though. One way or another the load-balancing has be improved and the new more intelligent scheduling IMHO should be the default one. -Maxim From jan at melen.org Tue Apr 28 06:36:29 2009 From: jan at melen.org (Jan Melen) Date: Tue Apr 28 11:37:36 2009 Subject: IPsec in GENERIC kernel config In-Reply-To: <20090427182917.W15361@maildrop.int.zabbadoz.net> References: <49F5B6F8.4040808@melen.org> <49F5F4A6.8050902@freebsd.org> <20090427182917.W15361@maildrop.int.zabbadoz.net> Message-ID: <49F6A3EA.3090905@melen.org> Hi, Bjoern A. Zeeb wrote: > On Mon, 27 Apr 2009, Sam Leffler wrote: > > Hi, > >> Jan Melen wrote: >>> Hi, >>> >>> Again when I compiled a custom kernel just to enable IPsec in the >>> FreeBSD kernel it came to my mind why is it so that the IPsec is not >>> enabled by default in the GENERIC kernel configuration file? At >>> least for me the GENERIC kernel configuration would do just fine if >>> the IPsec would be enabled in it by default. Now I have to build a >>> custom kernel just for IPsec btw IPsec is even mandatory for a host >>> supporting IPv6. >> IPsec incurs a performance hit. Fix that and it can be enabled in >> GENERIC. > > There is even a PR for this: > http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/128030 > Just to understand the problem correctly I guess you are talking about performance hit on outgoing packets as the IPsec tries to find a security policy even for packets that should not be encrypted? For incoming traffic I don't see any reason for performance hit. Has anyone done any measurements on magnitude of performance loss we get from trying to match the outgoing packets for non-existent IPsec policies? I would guess that if you have zero SPD entries in your system it can't be a lot as it a matter of calling: ip_ipsec_output -> ipsec4_checkpolicy -> ipsec_getpolicybyaddr/sock -> key_allocsp which in turn searches through an empty list. Jan From peterjeremy at optushome.com.au Tue Apr 28 11:48:00 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue Apr 28 11:48:08 2009 Subject: C99: Suggestions for style(9) In-Reply-To: <49F4070C.2000108@gmx.de> References: <49F4070C.2000108@gmx.de> Message-ID: <20090428114754.GB89235@server.vk2pj.dyndns.org> On 2009-Apr-26 09:02:36 +0200, Christoph Mallon wrote: >as some of you may have noticed, several years ago a new millenium >started and a decade ago there was a new C standard. Your implication that FreeBSD is therefore a decade behind the times is unfair. Whilst the C99 standard was published a decade ago, compilers implementing that standard are still not ubiquitous. > HEAD recently >switched to C99 as default (actually gnu99, but that's rather close). Note that gcc 4.2 (the FreeBSD base compiler) states that it is not C99 compliant. >Maybe using all of these changes is a bit too big change at once, but >I'd like some of them applied to style(9). So, please consider the >proposed changes individually and not a as a all-or-nothing package. One area you do not address is code consistency. Currently, the FreeBSD kernel (and, to a lesser extent, userland) are mostly style(9) compliant - ie the entire codebase is mostly written in the same style. Whilst you may not like it (and I don't know that anyone completely agrees with everything in style(9)), it does mean that the code is consistent. Changing style(9) in a way that is not consistent with current code means that either existing code must be brought into line with the new standard - which incurs a one-off cost - or the code base becomes split into "old" and "new" style - incurring an ongoing maintenance cost as maintainers switch between styles. Both approaches incur a risk of introducing new bugs. Note that I'm not saying that style(9) can never be changed, I'm just saying that any change _will_ incur a cost and the cost as well as the potential benefits need to be considered. [Reduce declaration scope as far as possible, initialise variables where they are declared, sort by name] Whilst my personal preference is for the style suggested by Christoph (and I generally agree with the points he makes), this is also the change that incurs the biggest stylistic change. This is not a change that can be practically retrofitted to existing code and therefore its implementation would result in a mixture of code styles - increasing the risk of bugs due to confusion as to which style was being used. I am not yet sure whether the benefits outweigh the costs, [Don't parenthesize return values] >Removed, because it does not improve maintainability in any way. This change could be made and tested mechanically. But there is no justification for making it - stating that the existing rule is no better than the proposed rule is no reason to change. [No K&R declarations] >Removed, because there is no need to use them anymore. Whilst this is a change that could be performed mechanically, there are some gotchas relating to type promotion (as you point out). The kernel already contains a mixture of ANSI & K&R declarations and style(9) recommends using ANSI. IMHO, there is no need to make this change until all K&R code is removed from FreeBSD. [ Don't insert an empty line if the function has no local variables.] This change could be made and tested mechanically. IMHO, this change has neglible risk and could be safely implemented. >> +.Sh LOCAL VARIABLES >Last, but definitely not least, I added this paragraph about the use of >local variables. This is to clarify, how today's compilers handle >unaliased local variables. Every version of gcc that FreeBSD has ever used would do this for primitive types when optimisation was enabled. This approach can become expensive in stack (and this is an issue for kernel code) when using non-primitive types or when optimisation is not enabled (though I'm not sure if this is supported). Assuming that gcc (and icc and clang) behaves as stated in all supported optimisation modes, this change would appear to be quite safe to make. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090428/603bbc1b/attachment.pgp From pvaibhav at freebsd.org Tue Apr 28 12:10:38 2009 From: pvaibhav at freebsd.org (Prashant Vaibhav) Date: Tue Apr 28 12:11:45 2009 Subject: SoC 2009: BSD-licensed libiconv in base system In-Reply-To: <49F6C7A1.6070708@FreeBSD.org> References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> <49F6C7A1.6070708@FreeBSD.org> Message-ID: <66b068eb0904280510g7a1e50dfm455d96fd49c6eae@mail.gmail.com> > > My ex-girlfriend is working in Nepal [...] Even this country's encoding is > supported. Probably because Nepali language doesn't have a separate script, they use Devanagari! :-) On Tue, Apr 28, 2009 at 2:38 PM, Gabor Kovesdan wrote: > David Schultz escribi?: > >> On Mon, Apr 27, 2009, Joerg Sonnenberger wrote: >> >> >>> On Mon, Apr 27, 2009 at 11:49:41AM -0700, Tim Kientzle wrote: >>> >>> >>>> David Schultz wrote: >>>> >>>> >>>>> ... whether it would make more sense to standardize on something like >>>>> UCS-4 for the internal representation. >>>>> >>>>> >>>> YES. Without this, wchar_t is useless. >>>> >>>> >>> I strongly disagree. Everything can be represented as UCS-4 is a bad >>> assumption, but something Americans and Europeans naturally don't have >>> to care about. >>> >>> >> >> ...but isn't this moot at present because there are no >> widely-accepted encodings that include characters that >> aren't supported by UCS-4? Citrus doesn't seem to support >> any such encodings in any case. >> >> > Citrus is based on UCS-4 as an internal encoding, just like the another > BSD-licensed iconv library. This is a barrier to support encodings that > aren't supported by UCS-4. > >> If this ever really becomes an issue, we could always stuff >> locale-dependent encodings into unused UCS-4 code pages. >> However, it doesn't seem worthwhile to deliberately burden >> programmers over concerns that are presently, and for the >> foreseeable future, hypothetical. >> >> > I'm not a Unicode expert, but isn't the reason of periodical standard > reviews and changes to cover more and more human languages? We could just > support the latest Unicode standard and let the Unicode workgroups map those > new characters into unused code points. The Latin-based, Cyrillic, > Devanagari and CJK encodings are well-supported, I think. I don't know too > much about CJK encondings, though, if the thousands of ideographs are all > supported or not. But I'd say the most significant languages that are used > on the Internet are supported, the rest might have another problems... > > [OFF] > It's possible that there are little poor countries with an own writing > system but probably their writing system is unsupported because the > starvation, poorness and lack of water and electricity are more serious > problems there. My ex-girlfriend is working in Nepal in a cooperation > program (it's kinda scholarship) and she told me that they only have > electricity in 8 hours a day, 4 during the night and 4 during the day. There > are no sidewalks for pedestrians, they go along with the cars on the street > and the pollution is extremely high. Even this country's encoding is > supported. What I am trying to say is that countries with unsupported > languages probably won't really care about character encodings if they > rarely have computers... I can just hope that their living conditions will > get better and their language will be supported. I can also hope that the > Unicode people will focus more on these countries instead of fucking up the > time with fictionary languages from fairy tales... [1] > Probably I'll go to visit her in Nepal in January, it will be an > interesting experience. I'll check if I can help the IT world there with > anything. > [ON] > > Another idea to consider. Are all of our utilities wchar-clean? What about > library functions? (regex is surely not) Do we lack any important utility or > library? (we still do lack iconv and gettext and what else...?) What about > standards, like C99 wchar functions? Is there something missing? What about > POSIX if it has something related? Personally, I think that these are more > important questions than support of some extremely rare languages. It's > worth to consider how to deal with them later but the basic problems need a > higher priority. > > > [1] http://en.wikipedia.org/wiki/Tengwar#Unicode > > > Cheers, > > -- > Gabor Kovesdan > FreeBSD Volunteer > > EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org > WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From vanhu at FreeBSD.org Tue Apr 28 12:14:06 2009 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Tue Apr 28 12:14:13 2009 Subject: IPsec in GENERIC kernel config In-Reply-To: <49F6A3EA.3090905@melen.org> References: <49F5B6F8.4040808@melen.org> <49F5F4A6.8050902@freebsd.org> <20090427182917.W15361@maildrop.int.zabbadoz.net> <49F6A3EA.3090905@melen.org> Message-ID: <20090428120311.GA68397@zeninc.net> On Tue, Apr 28, 2009 at 09:36:26AM +0300, Jan Melen wrote: > Hi, [...] > Just to understand the problem correctly I guess you are talking about > performance hit on outgoing packets as the IPsec tries to find a > security policy even for packets that should not be encrypted? For > incoming traffic I don't see any reason for performance hit. The (more or less) same check is done for incoming packets, because we NEED to ensure that IPsec traffic comes from the appropriate IPsec tunnel, and non IPsec traffic comes without IPsec.... > Has anyone done any measurements on magnitude of performance loss we get > from trying to match the outgoing packets for non-existent IPsec > policies? I would guess that if you have zero SPD entries in your system > it can't be a lot as it a matter of calling: > ip_ipsec_output -> ipsec4_checkpolicy -> ipsec_getpolicybyaddr/sock -> > key_allocsp which in turn searches through an empty list. We (my company) already tried such a hack, which completely skips IPsec process if we know that SPD (both in and out) is empty. It works, and has the expected impact on performance loss. Yvan. From joerg at britannica.bec.de Tue Apr 28 12:22:25 2009 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Tue Apr 28 12:22:31 2009 Subject: SoC 2009: BSD-licensed libiconv in base system In-Reply-To: <49F6C7A1.6070708@FreeBSD.org> References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> <49F6C7A1.6070708@FreeBSD.org> Message-ID: <20090428122225.GA2862@britannica.bec.de> On Tue, Apr 28, 2009 at 11:08:49AM +0200, Gabor Kovesdan wrote: > Citrus is based on UCS-4 as an internal encoding, just like the another > BSD-licensed iconv library. This is a barrier to support encodings that > aren't supported by UCS-4. More precisely is that Citrus can and will use UCS-4 as appropiate. It does not enforce it. Which is an important difference. One reason that it is often used is that it helps to avoid exponential growth of the translation tables. It just isn't worth the time to write ISO-8859-1 to ISO-8859-15 (trivial), if the translation to and from UCS4 gives the same result with marginally more work. > It's possible that there are little poor countries with an own writing > system but probably their writing system is unsupported because the > starvation, poorness and lack of water and electricity are more serious > problems there. I wouldn't call all both parts of Korea little poor countries and it is a wonderful example for why UCS 4 Level 1 can be problematic. Joerg From rdivacky at freebsd.org Tue Apr 28 12:32:03 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Tue Apr 28 12:32:12 2009 Subject: C99: Suggestions for style(9) In-Reply-To: <49F4070C.2000108@gmx.de> References: <49F4070C.2000108@gmx.de> Message-ID: <20090428121327.GA41168@freebsd.org> I like the part about using as many variables as possible because of documentation and performance enhancements. I tend to like the other changes as well.. On Sun, Apr 26, 2009 at 09:02:36AM +0200, Christoph Mallon wrote: > Hi hackers@, > > as some of you may have noticed, several years ago a new millenium > started and a decade ago there was a new C standard. HEAD recently > switched to C99 as default (actually gnu99, but that's rather close). So > it's finally time to re-examine wether style(9) needs to be accomodated. > The diff with the proposed changes is attached. Below are the changes > with some further explanations. They are in the order as they appear in > style(9). > Maybe using all of these changes is a bit too big change at once, but > I'd like some of them applied to style(9). So, please consider the > proposed changes individually and not a as a all-or-nothing package. > > >-Do not put declarations > >-inside blocks unless the routine is unusually complicated. > >+Prefer declaring loop iterators in the for-statement to limit their scope. > > .Bd -literal > >- for (; cnt < 15; cnt++) { > >+ for (int cnt = 0; cnt < 15; cnt++) { > [...] > >-When declaring variables in functions declare them sorted by size, > >-then in alphabetical order; multiple ones per line are okay. > >+When declaring variables in functions declare them sorted in alphabetical > >order; > >+prefer one declaration per line, especially when pointer declarators or > >+initializations are involved. > > If a line overflows reuse the type keyword. > > .Pp > >-Be careful to not obfuscate the code by initializing variables in > >-the declarations. > >-Use this feature only thoughtfully. > >-DO NOT use function calls in initializers. > >+Prefer initializing variables right at their declaration. > >+When the value is not supposed to change in the function, make the > >variable > >+const. > >+This makes it easier for a reader to identify the where the value of a > >variable > >+originates. > >+Do not reuse the same variable in a different context, declare a new > >variable. > > .Bd -literal > >- struct foo one, *two; > >- double three; > >- int *four, five; > >- char *six, seven, eight, nine, ten, eleven, twelve; > >+ struct foo *bar; > >+ struct foo baz = { 42, "qux" }; > > > >- four = myfunction(); > >+ FILE *const f = fopen("name", "r"); > >+ if (f == NULL) > >+ err("Failed to open file"); > >+ /* We can safely assume that f is not changed anymore, even if the > >+ * function is a hundred lines long */ > > This change is to reduce the scope of local variables. For reasons why > this does not cost anything in terms of stack space, please see the last > change, which adds explanations about local variables. > Smaller scopes and distinct variables for distinct contexts make it > easier for readers of the code to identify the def-use-chains of > variables, because there are less places with assignments to a variable > and the scope is smaller. Also, when a variable is initialised right at > its declaration and is not supposed to change, you can emphasize this by > making it const. > I looked at older discussions regarding this topic and identified > several concerns, which were raised. I'll address them below: > > - It does not add anything to the language. > Well, yes, just like if, do, for, goto, the comma operator, compound > assignment (+=, ...), ++/-- and many other things. All you need to be > Turing complete is lambda calculus - there hardly can be less syntax. > But, like all mentioned constructs, it makes the code more concise. > > - It leads to sloppy code. You could reuse another variable or should > think again whether you really need this variable. > Reusing variables in different contexts is error prone and bad for > maintainability. You could reuse a variable, which is not as dead as you > thought. More local variables cost nothing, especially no stack space, > see the last proposed changed below. It is good to use more local > variables, because it gives the reader a name, which carries > information. Also it makes it easier for a reader (and the compiler!) to > identify, which expressions are the same. You could repeat > foo->long_name->even_longer_name[2 * i + 1] five times or just declare a > local variable and cache the value to make it easier to read. > It also enables the compiler to produce better warnings: If you declare > a new variable, it is not initialised and if you do not initialise it on > all paths before a use, the compiler will warn you. But if you reuse an > older variable, it is already initialised by its former uses and so you > get no warning, but operate on garbage values (the old value from the > previous use). > So it does not lead to slopyy code, but better code, which is easier to > comprehend, the compiler can better help you to prevent bugs, and as a > side effect the compiler can produce better code (aliasing is a major > problem for common subexpression elimination). > > - You can determine the stack usage with all the variable declarations > at the top. > This is not true. There is no relation between the declared variables > and the stack used. Especially, more stack than suggested by the > declarations can be used due to various optimisations - less space can > be used, too, of course. > > - It is harder to find the declaration of a variable. > Every editor, which is more advanced than ed, has facilities to jump to > the declaration of a variable (e.g. in vim it's "gd"). And most often > this is not necessary, because the declaration is just a few lines above > instead of all the way up at the top of the function, so no jumping > around is required at all. > > - You could accidently shadow a variable. > All modern compilers have warnings for this. FreeBSD uses -Wshadow for > GCC (and all relevant compilers understand this very option). > > > >-Values in > >-.Ic return > >-statements should be enclosed in parentheses. > >-.Pp > > return with parentheses: > Removed, because it does not improve maintainability in any way. There > is no source for confusion here, so the rule even contradicts the rule, > which states not to use redundant parentheses. Maybe, decades ago it was > just a workaround for a broken compiler, which does not exist anymore. > > > >-Old-style function declarations look like this: > >-.Bd -literal > >-static char * > >-function(a1, a2, fl, a4) > >- int a1, a2; /* Declare ints, too, don't default them. */ > >- float fl; /* Beware double vs. float prototype differences. */ > >- int a4; /* List in order declared. */ > >-{ > >-.Ed > >-.Pp > >-Use ANSI function declarations unless you explicitly need K&R > >compatibility. > >+Use ANSI function declarations. > > Old-style function declarations: > Removed, because there is no need to use them anymore. The C99 standard > considers them obsolescent[1], too. All headers use prototype > declarations, there's no reason to handle the function definitions > different. Also they are a source of bugs - or did you know that the > following is wrong: > void wrong(char /* sic! */); > void wrong(x) char x; {} > And this is correct[2]: > void right(int /* sic! */); > void right(x) char x; {} > (It's a bug in GCC that it does not complain about the former.) > > > >- > >-static void > >-usage() > >-{ > >- /* Insert an empty line if the function has no local variables. */ > > Empty line when there are no local variables: > Removed, because it does not improve readability and it actually hinders > readability for very short functions, e.g. static inline functions, > which just consist of one or two lines of code without any local > variables except for parameters. Further, it makes even less sense with > the changed recommendations for declarations. > > > >+.Sh LOCAL VARIABLES > >+Unaliased local variables are for free on modern compilers. > >+They do not unconditionally use stack space. > >+In fact there is no relation between their number and the used stack > >space. > >+A local variable is guaranteed to be unaliased, if its address has not > >been > >+taken (e.g. &i). > >+Do not use the same local variable in different context just because it > >happens > >+that the same type is needed. > >+It does not improve the generated code in any way, but it makes it harder > >for a > >+reader to determine all definitions and uses which belong together. > >+Further, a new variable can be given a meaningful name (even if it is very > >+short), which automatically serves as documentation and so improves > >+comprehensibility. > >+Especially avoid re-using variables, whose address has been taken: > >+.Bd -literal > >+ int i; > >+ foo(&i); > >+ printf("%d\\n", i); > >+ for (i = 0; i != 10; ++i) { > >+ /* BAD: i will be needlessly moved to and from memory in > >+ * the loop, because its address was taken before. This > >+ * results in larger and slower code. > >+ * Declare a new variable for the loop instead. */ > >+ printf("%d\\n", i); > >+ } > >+.Ed > >+ > > Last, but definitely not least, I added this paragraph about the use of > local variables. This is to clarify, how today's compilers handle > unaliased local variables. There is absolutely no need to reuse them in > different contexts. Trying to optimise stack usage in this way is > misguided and is a source of bugs, when a reused variable is not as dead > as thought. For more reasons, please read the quoted diff. > Maxim, you requested this paragraph: Does this addition suit you? > > > Hopefully at least some of these suggestions are considered improvements > and are applied to style(9). > > Regards > Christoph > > > [1] ISO/IEC 9899:1999 (E) ?6.11.6 and ?6.11.7 > [2] ISO/IEC 9899:1999 (E) ?6.7.5.3:15 From gabor at kovesdan.org Tue Apr 28 14:10:38 2009 From: gabor at kovesdan.org (=?iso-8859-2?Q?G=E1bor_K=F6vesd=E1n?=) Date: Tue Apr 28 15:20:22 2009 Subject: SoC 2009: BSD-licensed libiconv in base system In-Reply-To: <66b068eb0904280510g7a1e50dfm455d96fd49c6eae@mail.gmail.com> References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> <49F6C7A1.6070708@FreeBSD.org> <66b068eb0904280510g7a1e50dfm455d96fd49c6eae@mail.gmail.com> Message-ID: <5b541e6fbf41b780b8eb99ac00b4d16c.squirrel@webmail.kovesdan.org> >> >> My ex-girlfriend is working in Nepal [...] Even this country's encoding >> is >> supported. > > > Probably because Nepali language doesn't have a separate script, they use > Devanagari! :-) I know, what I wanted to say was that even Nepali is covered by the supported scripts. -- G?bor K?vesd?n From gabor at kovesdan.org Tue Apr 28 14:10:38 2009 From: gabor at kovesdan.org (=?iso-8859-2?Q?G=E1bor_K=F6vesd=E1n?=) Date: Tue Apr 28 15:29:35 2009 Subject: SoC 2009: BSD-licensed libiconv in base system In-Reply-To: <20090428122225.GA2862@britannica.bec.de> References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> <49F6C7A1.6070708@FreeBSD.org> <20090428122225.GA2862@britannica.bec.de> Message-ID: <24e9a86bf5995ba551db8f27aa204191.squirrel@webmail.kovesdan.org> >> It's possible that there are little poor countries with an own writing >> system but probably their writing system is unsupported because the >> starvation, poorness and lack of water and electricity are more serious >> problems there. > > I wouldn't call all both parts of Korea little poor countries and it is > a wonderful example for why UCS 4 Level 1 can be problematic. > I didn't know about Korea. Then I insist even more on that Unicode should be extended to cover them instead of making implementation-specific solutions. -- G?bor K?vesd?n From neldredge at math.ucsd.edu Tue Apr 28 17:00:27 2009 From: neldredge at math.ucsd.edu (Nate Eldredge) Date: Tue Apr 28 17:00:36 2009 Subject: C99: Suggestions for style(9) In-Reply-To: <20090428114754.GB89235@server.vk2pj.dyndns.org> References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> Message-ID: On Tue, 28 Apr 2009, Peter Jeremy wrote: > On 2009-Apr-26 09:02:36 +0200, Christoph Mallon wrote: >> as some of you may have noticed, several years ago a new millenium >> started and a decade ago there was a new C standard. > > Your implication that FreeBSD is therefore a decade behind the times > is unfair. Whilst the C99 standard was published a decade ago, > compilers implementing that standard are still not ubiquitous. > >> HEAD recently >> switched to C99 as default (actually gnu99, but that's rather close). > > Note that gcc 4.2 (the FreeBSD base compiler) states that it is not > C99 compliant. However, if you take a look at http://gcc.gnu.org/gcc-4.2/c99status.html , you will see that it is very close. The vast majority of C99 features are implemented and working correctly. Even those which are marked as "broken" generally work in most cases, and fail only in rather obscure corner cases that real programs are unlikely to encounter. In particular, the features Christoph proposes to use work fine. -- Nate Eldredge neldredge@math.ucsd.edu From joerg at britannica.bec.de Tue Apr 28 18:06:26 2009 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Tue Apr 28 18:06:33 2009 Subject: SoC 2009: BSD-licensed libiconv in base system In-Reply-To: <24e9a86bf5995ba551db8f27aa204191.squirrel@webmail.kovesdan.org> References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> <49F6C7A1.6070708@FreeBSD.org> <20090428122225.GA2862@britannica.bec.de> <24e9a86bf5995ba551db8f27aa204191.squirrel@webmail.kovesdan.org> Message-ID: <20090428180624.GA2223@britannica.bec.de> On Tue, Apr 28, 2009 at 03:53:10PM +0200, G?bor K?vesd?n wrote: > >> It's possible that there are little poor countries with an own writing > >> system but probably their writing system is unsupported because the > >> starvation, poorness and lack of water and electricity are more serious > >> problems there. > > > > I wouldn't call all both parts of Korea little poor countries and it is > > a wonderful example for why UCS 4 Level 1 can be problematic. > > > > > I didn't know about Korea. Then I insist even more on that Unicode should > be extended to cover them instead of making implementation-specific > solutions. Unicode covers Korean. It just violates the "one logic character equals one UCS-4 character" or however you want to put. More trivial example can be obtained when looking at both your and my name. Diacrets have historically been part of the character, but it is possible to use combining characters in unicode for the cleaner description. Joerg From julidaoc at online.de Tue Apr 28 20:32:13 2009 From: julidaoc at online.de (Julian Bangert) Date: Tue Apr 28 20:47:07 2009 Subject: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation Message-ID: Hello, I am currently trying to work a bit on the remaining "missing feature" that NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRequests or a back post in this ML) - the improved mmap system call. For now, I am trying to extend the current system call and implementation to add cache control ( the type of memory caching used) . This feature inherently is very architecture specific- but it can lead to enormous performance improvements for memmapped devices ( useful for drivers, etc). I would do this at the user site by adding 3 flags to the mmap system call (MEM_CACHE__ATTR1 to MEM_CACHE__ATTR3 ) which are a single octal digit corresponding to the various caching options ( like Uncacheable,Write Combining, etc... ) with the same numbers as the PAT_* macros from i386/include/specialreg.h except that the value 0 ( PAT_UNCACHEABLE ) is replaced with value 2 ( undefined), whereas value 0 ( all 3 flags cleared) is assigned the meaning "feature not used, use default cache control". For each cache behaviour there would of course also be a macro expanding to the rigth combination of these flags for enhanced useability. The mmap system call would, if any of these flags are set, decode them and get a corresponding PAT_* value, perform the mapping and then call into the pmap module to modify the cache attributes for every page. My first question is if there is a more elegant way of solving that - the 3 flags would be architecture specific ( they could be used for other things on other architectures though if need be ) and I do not know the policy on architecture specific syscall flags, therefore I appreciate any input. The second question goes to all those great VM/pmap gurus out there: As far as I understand, at the moment the pmap_change_attr can only cange the cache flags for kernel pages. Is there a particular reason why this function might not be adapted/extended to userspace mappings? If not, I would either add a new function to iterate over all pages and set cache flags for a particular region or add a new member (possibly just add the 3 flags again ? ) to the md part of vm_page_t. Or one could just keep track and return errors as soon as someone tries to map a memory region ( cache-customized mapping is usually done to device memory ) already mapped with different cache behaviour. I thank you for your assistance & happy coding, --Julian Bangert From marius at nuenneri.ch Tue Apr 28 21:43:19 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Tue Apr 28 21:43:26 2009 Subject: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation In-Reply-To: References: Message-ID: On Tue, Apr 28, 2009 at 22:19, Julian Bangert wrote: > Hello, > > I am currently trying to work a bit on the remaining "missing feature" that > NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRequests ?or a back > post in this ML) - ?the improved mmap system call. > ?For now, I am trying to extend the current system call and implementation > to add cache control ( the type of memory caching used) . This feature > inherently is very architecture specific- but it can lead to enormous > performance improvements for memmapped devices ( useful for drivers, etc). I > would do this at the user site by adding 3 flags to the mmap system call > (MEM_CACHE__ATTR1 to MEM_CACHE__ATTR3 ) which are a single octal digit > corresponding to the various caching options ( like Uncacheable,Write > Combining, etc... ) with the same numbers as the PAT_* macros from > i386/include/specialreg.h except that the value 0 ( PAT_UNCACHEABLE ) is > replaced with value 2 ( undefined), whereas value 0 ( all 3 flags cleared) > is assigned the meaning "feature not used, use default cache control". > For each cache behaviour there would of course also be a macro expanding to > the rigth combination of these flags for enhanced useability. Hmm, I don't like that. What about using something like PAT_WC directly for the userland? Afaik a userland app that uses stuff like this is md anyway. > ?The mmap system call would, if any of these flags are set, decode them and > get a corresponding PAT_* value, perform the mapping and then call into the > pmap module to modify the cache attributes for every page. > > ?My first question is if there is a more elegant way of solving that - the 3 > flags would be architecture specific ( they could be used for other things > on other architectures though if need be ) and I do not know the policy on > architecture specific syscall flags, therefore I appreciate any input. > > The second question goes to all those great VM/pmap gurus out there: As far > as I understand, at the moment the pmap_change_attr can only cange the cache > flags for kernel pages. Is there a particular reason why this function might > not be adapted/extended to userspace mappings? If not, I would either add a > new function to iterate over all pages and set cache flags for a particular > region or add a new member (possibly just add the 3 flags again ? ) to the > md part of vm_page_t. Or one could just keep track and return errors as soon > as someone tries to map a memory region ( cache-customized mapping is > usually done to device memory ) already mapped with ?different cache > behaviour. Do you know how other OS handle this stuff? Maybe there is some inspiration there for a clean interface. I'm not sure if I remember correctly but there is something in my mind that we must take care that no virtual pages have different PAT settings for the same physical page. Maybe I read something like this in the AMD's documentation of PAT. Sorry I don't remember exactly but perhaps someone else can explain it better. From das at FreeBSD.ORG Tue Apr 28 22:25:55 2009 From: das at FreeBSD.ORG (David Schultz) Date: Tue Apr 28 22:26:01 2009 Subject: SoC 2009: BSD-licensed libiconv in base system In-Reply-To: <49F6C7A1.6070708@FreeBSD.org> References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> <49F6C7A1.6070708@FreeBSD.org> Message-ID: <20090428222629.GA17881@zim.MIT.EDU> On Tue, Apr 28, 2009, Gabor Kovesdan wrote: > Another idea to consider. Are all of our utilities wchar-clean? What > about library functions? (regex is surely not) Do we lack any important > utility or library? (we still do lack iconv and gettext and what > else...?) What about standards, like C99 wchar functions? Is there > something missing? What about POSIX if it has something related? > Personally, I think that these are more important questions than support > of some extremely rare languages. It's worth to consider how to deal > with them later but the basic problems need a higher priority. There's a fair number of utilities that are not locale-aware, and we don't have any of the *_l() functions in POSIX.1-2008. There are also some second-order issues in libraries, e.g., they assume multibyte encodings don't contain embedded low ASCII characters, or they are far less efficient than they could be. > I hope my work will be useful for the community. Btw, I suspected that > you might be interested in this and I wrote a mail personally to you > when I was looking for a mentor. Then I didn't resend it because > delphij@ volunteered to be my mentor. Have you ever got that mail? If > you find this an interesting project your comments, review, etc. are > still highly welcome. I did reply on 3/19, basically to say that I'd be happy to offer advice, but it's not really my area. From toasty at dragondata.com Tue Apr 28 22:06:09 2009 From: toasty at dragondata.com (Kevin Day) Date: Tue Apr 28 22:30:03 2009 Subject: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation In-Reply-To: References: Message-ID: On Apr 28, 2009, at 3:19 PM, Julian Bangert wrote: > Hello, > > I am currently trying to work a bit on the remaining "missing > feature" that NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRequests > or a back post in this ML) - the improved mmap system call. > For now, I am trying to extend the current system call and > implementation to add cache control ( the type of memory caching > used) . This feature inherently is very architecture specific- but > it can lead to enormous performance improvements for memmapped > devices ( useful for drivers, etc). I would do this at the user site > by adding 3 flags to the mmap system call (MEM_CACHE__ATTR1 to > MEM_CACHE__ATTR3 ) which are a single octal digit corresponding to > the various caching options ( like Uncacheable,Write Combining, > etc... ) with the same numbers as the PAT_* macros from i386/include/ > specialreg.h except that the value 0 ( PAT_UNCACHEABLE ) is replaced > with value 2 ( undefined), whereas value 0 ( all 3 flags cleared) is > assigned the meaning "feature not used, use default cache control". > For each cache behaviour there would of course also be a macro > expanding to the rigth combination of these flags for enhanced > useability. > > The mmap system call would, if any of these flags are set, decode > them and get a corresponding PAT_* value, perform the mapping and > then call into the pmap module to modify the cache attributes for > every page. Have you looked at mem(4) yet? Several architectures allow attributes to be associated with ranges of physical memory. These attributes can be manipulated via ioctl() calls performed on /dev/mem. Declarations and data types are to be found in . The specific attributes, and number of programmable ranges may vary between architectures. The full set of supported attributes is: MDF_UNCACHEABLE The region is not cached. MDF_WRITECOMBINE Writes to the region may be combined or performed out of order. MDF_WRITETHROUGH Writes to the region are committed synchronously. MDF_WRITEBACK Writes to the region are committed asynchronously. MDF_WRITEPROTECT The region cannot be written to. This requires knowledge of the physical addresses, but I believe that's probably already necessary for what it sounds like you're trying to accomplish. Back in the FreeBSD-3.0 days, I was writing a custom driver for an AGP graphics controller, and setting the MTRR flags for the exposed buffer was a definite improvement (200-1200% faster in most cases). -- Kevin From rnoland at FreeBSD.org Tue Apr 28 23:45:43 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Apr 28 23:46:15 2009 Subject: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation In-Reply-To: References: Message-ID: <1240962328.2021.10.camel@wombat.2hip.net> On Tue, 2009-04-28 at 16:48 -0500, Kevin Day wrote: > On Apr 28, 2009, at 3:19 PM, Julian Bangert wrote: > > > Hello, > > > > I am currently trying to work a bit on the remaining "missing > > feature" that NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRequests > > or a back post in this ML) - the improved mmap system call. > > For now, I am trying to extend the current system call and > > implementation to add cache control ( the type of memory caching > > used) . This feature inherently is very architecture specific- but > > it can lead to enormous performance improvements for memmapped > > devices ( useful for drivers, etc). I would do this at the user site > > by adding 3 flags to the mmap system call (MEM_CACHE__ATTR1 to > > MEM_CACHE__ATTR3 ) which are a single octal digit corresponding to > > the various caching options ( like Uncacheable,Write Combining, > > etc... ) with the same numbers as the PAT_* macros from i386/include/ > > specialreg.h except that the value 0 ( PAT_UNCACHEABLE ) is replaced > > with value 2 ( undefined), whereas value 0 ( all 3 flags cleared) is > > assigned the meaning "feature not used, use default cache control". > > For each cache behaviour there would of course also be a macro > > expanding to the rigth combination of these flags for enhanced > > useability. > > > > The mmap system call would, if any of these flags are set, decode > > them and get a corresponding PAT_* value, perform the mapping and > > then call into the pmap module to modify the cache attributes for > > every page. > > Have you looked at mem(4) yet? > > Several architectures allow attributes to be associated with > ranges of > physical memory. These attributes can be manipulated via > ioctl() calls > performed on /dev/mem. Declarations and data types are to be > found in > . > > The specific attributes, and number of programmable ranges may > vary > between architectures. The full set of supported attributes is: > > MDF_UNCACHEABLE > The region is not cached. > > MDF_WRITECOMBINE > Writes to the region may be combined or performed out of > order. > > MDF_WRITETHROUGH > Writes to the region are committed synchronously. > > MDF_WRITEBACK > Writes to the region are committed asynchronously. > > MDF_WRITEPROTECT > The region cannot be written to. > > This requires knowledge of the physical addresses, but I believe > that's probably already necessary for what it sounds like you're > trying to accomplish. > > Back in the FreeBSD-3.0 days, I was writing a custom driver for an AGP > graphics controller, and setting the MTRR flags for the exposed buffer > was a definite improvement (200-1200% faster in most cases). This is MTRR, which is what we currently do, when we can. The issue is that often times the BIOS maps ranges in a way that prevents us from using MTRR. This is generally ideal for things like agp and framebuffers when it works, since they have a specific physical range that you want to work with. With PCI(E) cards it isn't as cut and dry... In the ATI and Nouveau cases, we map scatter gather pages into the GART, which generally are allocated using contigmalloc behind the scenes, so it is also possible for it to work in that case. Moving forward, we may actually be mapping random pages into and out of the GART (GEM / TTM). In those cases we really don't have a large contiguous range that we could set MTRR on. Intel CPUs are limited to 8 MTRR registers for the entire system also, so that can become an issue quickly if you are trying to manipulate several areas of memory. With PAT we can manipulate the caching properties on a page level. PAT also allows for some overlap conditions that MTRR won't, such as mapping a page write-combining on top on an UNCACHEABLE MTRR. jhb@ has started some work on this, since I've been badgering him about this recently as well. robert. > -- Kevin > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090428/9c70e1f7/attachment.pgp From julian at elischer.org Tue Apr 28 23:58:51 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Apr 28 23:58:58 2009 Subject: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation In-Reply-To: <1240962328.2021.10.camel@wombat.2hip.net> References: <1240962328.2021.10.camel@wombat.2hip.net> Message-ID: <49F79841.9030702@elischer.org> Robert Noland wrote: > On Tue, 2009-04-28 at 16:48 -0500, Kevin Day wrote: >> On Apr 28, 2009, at 3:19 PM, Julian Bangert wrote: >> >>> Hello, >>> >>> I am currently trying to work a bit on the remaining "missing >>> feature" that NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRequests >>> or a back post in this ML) - the improved mmap system call. you might check with jhb (john Baldwin) as I think (from his p4 work) that he may be doing something in this area in p4. >>> For now, I am trying to extend the current system call and >>> implementation to add cache control ( the type of memory caching >>> used) . This feature inherently is very architecture specific- but >>> it can lead to enormous performance improvements for memmapped >>> devices ( useful for drivers, etc). I would do this at the user site >>> by adding 3 flags to the mmap system call (MEM_CACHE__ATTR1 to >>> MEM_CACHE__ATTR3 ) which are a single octal digit corresponding to >>> the various caching options ( like Uncacheable,Write Combining, >>> etc... ) with the same numbers as the PAT_* macros from i386/include/ >>> specialreg.h except that the value 0 ( PAT_UNCACHEABLE ) is replaced >>> with value 2 ( undefined), whereas value 0 ( all 3 flags cleared) is >>> assigned the meaning "feature not used, use default cache control". >>> For each cache behaviour there would of course also be a macro >>> expanding to the rigth combination of these flags for enhanced >>> useability. >>> >>> The mmap system call would, if any of these flags are set, decode >>> them and get a corresponding PAT_* value, perform the mapping and >>> then call into the pmap module to modify the cache attributes for >>> every page. >> Have you looked at mem(4) yet? >> >> Several architectures allow attributes to be associated with >> ranges of >> physical memory. These attributes can be manipulated via >> ioctl() calls >> performed on /dev/mem. Declarations and data types are to be >> found in >> . >> >> The specific attributes, and number of programmable ranges may >> vary >> between architectures. The full set of supported attributes is: >> >> MDF_UNCACHEABLE >> The region is not cached. >> >> MDF_WRITECOMBINE >> Writes to the region may be combined or performed out of >> order. >> >> MDF_WRITETHROUGH >> Writes to the region are committed synchronously. >> >> MDF_WRITEBACK >> Writes to the region are committed asynchronously. >> >> MDF_WRITEPROTECT >> The region cannot be written to. >> >> This requires knowledge of the physical addresses, but I believe >> that's probably already necessary for what it sounds like you're >> trying to accomplish. >> >> Back in the FreeBSD-3.0 days, I was writing a custom driver for an AGP >> graphics controller, and setting the MTRR flags for the exposed buffer >> was a definite improvement (200-1200% faster in most cases). > > This is MTRR, which is what we currently do, when we can. The issue is > that often times the BIOS maps ranges in a way that prevents us from > using MTRR. This is generally ideal for things like agp and > framebuffers when it works, since they have a specific physical range > that you want to work with. > > With PCI(E) cards it isn't as cut and dry... In the ATI and Nouveau > cases, we map scatter gather pages into the GART, which generally are > allocated using contigmalloc behind the scenes, so it is also possible > for it to work in that case. Moving forward, we may actually be mapping > random pages into and out of the GART (GEM / TTM). In those cases we > really don't have a large contiguous range that we could set MTRR on. > Intel CPUs are limited to 8 MTRR registers for the entire system also, > so that can become an issue quickly if you are trying to manipulate > several areas of memory. With PAT we can manipulate the caching > properties on a page level. PAT also allows for some overlap conditions > that MTRR won't, such as mapping a page write-combining on top on an > UNCACHEABLE MTRR. > > jhb@ has started some work on this, since I've been badgering him about > this recently as well. > > robert. > >> -- Kevin >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From deeptech71 at gmail.com Wed Apr 29 18:22:47 2009 From: deeptech71 at gmail.com (deeptech71@gmail.com) Date: Wed Apr 29 18:22:57 2009 Subject: C99: Suggestions for style(9) In-Reply-To: <49F4070C.2000108@gmx.de> References: <49F4070C.2000108@gmx.de> Message-ID: <49F89B6E.7030303@gmail.com> Christoph Mallon wrote: >> -When declaring variables in functions declare them sorted by size, >> -then in alphabetical order; multiple ones per line are okay. >> +When declaring variables in functions declare them sorted in >> alphabetical order; What's wrong with logical grouping, especially when the new localized declaration style is used (so tons of variables are not declared at a time anymore)? From john.gemignani at isilon.com Wed Apr 29 19:22:59 2009 From: john.gemignani at isilon.com (John Gemignani) Date: Wed Apr 29 19:23:06 2009 Subject: C99: Suggestions for style(9) Message-ID: <108501c9c8fe$3a30ab0e$72020a0a@desktop.isilon.com> Because the logical grouping makes the most sense to the author of the code, not the person who has to learn or maintain it. Are local variables allocated on-the-fly on the stack or does the compiler preallocate the space on entry? If I have to delve into a crashdump, having the variables on the big entry allocation has been very helpful in the past. John -----Original Message----- From: deeptech71@gmail.com Sent: Wednesday, April 29, 2009 11:23 AM To: freebsd-hackers@freebsd.org Subject: Re: C99: Suggestions for style(9) Christoph Mallon wrote: >> -When declaring variables in functions declare them sorted by size, >> -then in alphabetical order; multiple ones per line are okay. >> +When declaring variables in functions declare them sorted in >> alphabetical order; What's wrong with logical grouping, especially when the new localized declaration style is used (so tons of variables are not declared at a time anymore)? _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From bsd.quest at googlemail.com Thu Apr 30 11:45:13 2009 From: bsd.quest at googlemail.com (Alexej Sokolov) Date: Thu Apr 30 11:45:22 2009 Subject: killing process from interrupt Message-ID: <671bb5fc0904300445n73edcf95pf2139250fc8ff68d@mail.gmail.com> Hello, I have in my interrupt function the pointer to structure of some process. What is the safe way to kill the process? psignal (p, 9); ? Thanx Alexej From imp at bsdimp.com Thu Apr 30 15:07:13 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Apr 30 15:07:19 2009 Subject: C99: Suggestions for style(9) In-Reply-To: <20090428114754.GB89235@server.vk2pj.dyndns.org> References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> Message-ID: <20090430.090226.1569754707.imp@bsdimp.com> In message: <20090428114754.GB89235@server.vk2pj.dyndns.org> Peter Jeremy writes: : >Maybe using all of these changes is a bit too big change at once, but : >I'd like some of them applied to style(9). So, please consider the : >proposed changes individually and not a as a all-or-nothing package. : : One area you do not address is code consistency. Currently, the : FreeBSD kernel (and, to a lesser extent, userland) are mostly style(9) : compliant - ie the entire codebase is mostly written in the same : style. Whilst you may not like it (and I don't know that anyone : completely agrees with everything in style(9)), it does mean that : the code is consistent. : : Changing style(9) in a way that is not consistent with current code : means that either existing code must be brought into line with the : new standard - which incurs a one-off cost - or the code base becomes : split into "old" and "new" style - incurring an ongoing maintenance : cost as maintainers switch between styles. Both approaches incur a : risk of introducing new bugs. : : Note that I'm not saying that style(9) can never be changed, I'm just : saying that any change _will_ incur a cost and the cost as well as : the potential benefits need to be considered. This is my biggest worry about changing style(9) quickly. We don't want needless churn in the tree for just style changes since it makes it harder to track bug fixes into the past. : [Reduce declaration scope as far as possible, initialise variables where : they are declared, sort by name] : : Whilst my personal preference is for the style suggested by Christoph : (and I generally agree with the points he makes), this is also the : change that incurs the biggest stylistic change. This is not a change : that can be practically retrofitted to existing code and therefore its : implementation would result in a mixture of code styles - increasing : the risk of bugs due to confusion as to which style was being used. I : am not yet sure whether the benefits outweigh the costs, This is the biggest one, and I think it may be too soon. Also, we need to be careful on the initialization side of things because we currently have a lot of code that looks like: struct foo *fp; struct bar *bp; fp = get_foo(); if (!fp) return; bp = fp->bp; this can't easily be translated to the more natural: struct foo *fp = get_foo(); struct bar *bp = fp->bp; since really you'd want to write: struct foo *fp = get_foo(); if (!fp) return; struct bar *bp = fp->bp; which isn't legal in 'C'. However, we have enough where this isn't the case that it should be allowed. We should separate the initialization part of this from the scope part of this too. The initialization part is already leaking into the code, while instances of the scope restriction is rarer. : [Don't parenthesize return values] : >Removed, because it does not improve maintainability in any way. : : This change could be made and tested mechanically. But there is : no justification for making it - stating that the existing rule : is no better than the proposed rule is no reason to change. I'm fine with this. : [No K&R declarations] : >Removed, because there is no need to use them anymore. : : Whilst this is a change that could be performed mechanically, there : are some gotchas relating to type promotion (as you point out). : The kernel already contains a mixture of ANSI & K&R declarations and : style(9) recommends using ANSI. IMHO, there is no need to make this : change until all K&R code is removed from FreeBSD. I'm fine with this change. : [ Don't insert an empty line if the function has no local variables.] : : This change could be made and tested mechanically. IMHO, this change : has neglible risk and could be safely implemented. I'm fine with this change. : >> +.Sh LOCAL VARIABLES : : >Last, but definitely not least, I added this paragraph about the use of : >local variables. This is to clarify, how today's compilers handle : >unaliased local variables. : : Every version of gcc that FreeBSD has ever used would do this for : primitive types when optimisation was enabled. This approach can : become expensive in stack (and this is an issue for kernel code) when : using non-primitive types or when optimisation is not enabled (though : I'm not sure if this is supported). Assuming that gcc (and icc and : clang) behaves as stated in all supported optimisation modes, this : change would appear to be quite safe to make. Agreed, in general. We don't want to optimize our code style based on what one compiler does, perhaps on x86. Warner From oliver.pntr at gmail.com Thu Apr 30 15:17:57 2009 From: oliver.pntr at gmail.com (Oliver Pinter) Date: Thu Apr 30 15:18:04 2009 Subject: NetBSD 5.0 statistics Message-ID: <6101e8c40904300750i3e86fc0cnef09b0d4533627f7@mail.gmail.com> Is the FreeBSD's FS management so slow? http://www.netbsd.org/~ad/50/img15.html Or so big is the difference between the two cpu scheduler? http://www.netbsd.org/~ad/50/img0.html From kmacy at freebsd.org Thu Apr 30 18:33:39 2009 From: kmacy at freebsd.org (Kip Macy) Date: Thu Apr 30 18:33:46 2009 Subject: NetBSD 5.0 statistics In-Reply-To: <6101e8c40904300750i3e86fc0cnef09b0d4533627f7@mail.gmail.com> References: <6101e8c40904300750i3e86fc0cnef09b0d4533627f7@mail.gmail.com> Message-ID: <3c1674c90904301133w702d98feh88457677388a0a61@mail.gmail.com> On Thu, Apr 30, 2009 at 7:50 AM, Oliver Pinter wrote: > Is the FreeBSD's FS management so slow? > > http://www.netbsd.org/~ad/50/img15.html > > Or so big is the difference between the two cpu scheduler? > > > http://www.netbsd.org/~ad/50/img0.html We would need more information about the disk hardware, amount of memory etc. to really provide an answer. We've had a lot of difficulties testing against NetBSD in the past because NetBSD wouldn't boot on recent hardware (ACPI issues IIRC). Looking at the processor he is using it would appear that that has probably been fixed. -Kip From rwatson at FreeBSD.org Thu Apr 30 19:32:02 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Apr 30 19:32:09 2009 Subject: NetBSD 5.0 statistics In-Reply-To: <6101e8c40904300750i3e86fc0cnef09b0d4533627f7@mail.gmail.com> References: <6101e8c40904300750i3e86fc0cnef09b0d4533627f7@mail.gmail.com> Message-ID: On Thu, 30 Apr 2009, Oliver Pinter wrote: > Is the FreeBSD's FS management so slow? > > http://www.netbsd.org/~ad/50/img15.html > > Or so big is the difference between the two cpu scheduler? Also, there's a known and serious performance regression in CAM relating to tgged queueing, and the generic disk sort routine, introduced 7.1, which will be fixed in 7.2. I can't speak more generally to the benchmarks -- we'll need to run them in a controlled environment and see if we can reproduce the results. Robert N M Watson Computer Laboratory University of Cambridge From jhb at freebsd.org Thu Apr 30 21:41:24 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Apr 30 21:41:39 2009 Subject: ACPI-fast default timecounter, but HPET 83% faster In-Reply-To: <7d6fde3d0904261927s1a67cf85jc982c1a68e30e081@mail.gmail.com> References: <200904270150.31912.pieter@degoeje.nl> <7d6fde3d0904261927s1a67cf85jc982c1a68e30e081@mail.gmail.com> Message-ID: <200904300846.41576.jhb@freebsd.org> On Sunday 26 April 2009 10:27:42 pm Garrett Cooper wrote: > I'm seeing similar results. > > [root@orangebox /usr/home/gcooper]# dmesg | grep 'Timecounter "' > Timecounter "i8254" frequency 1193182 Hz quality 0 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > Timecounter "HPET" frequency 14318180 Hz quality 900 > [root@orangebox /usr/home/gcooper]# ./cgt > 1369355 > [root@orangebox /usr/home/gcooper]# sysctl > kern.timecounter.hardware="ACPI-fast" > kern.timecounter.hardware: HPET -> ACPI-fast > [root@orangebox /usr/home/gcooper]# ./cgt > 772289 > > Why's the default ACPI-fast? For power-saving functionality or because > of the `quality' factor? What is the criteria that determines the > `quality' of a clock as what's being reported above (I know what > determines the quality of a clock visually from a oscilloscope =])? I suspect that the quality of the HPET driver is lower simply because no one had measured it previously and HPET is newer and less "proven". -- John Baldwin From jhb at freebsd.org Thu Apr 30 21:41:32 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Apr 30 21:42:16 2009 Subject: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation In-Reply-To: <49F79841.9030702@elischer.org> References: <1240962328.2021.10.camel@wombat.2hip.net> <49F79841.9030702@elischer.org> Message-ID: <200904301736.52325.jhb@freebsd.org> On Tuesday 28 April 2009 7:58:57 pm Julian Elischer wrote: > Robert Noland wrote: > > On Tue, 2009-04-28 at 16:48 -0500, Kevin Day wrote: > >> On Apr 28, 2009, at 3:19 PM, Julian Bangert wrote: > >> > >>> Hello, > >>> > >>> I am currently trying to work a bit on the remaining "missing > >>> feature" that NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRequests > >>> or a back post in this ML) - the improved mmap system call. > > > you might check with jhb (john Baldwin) as I think (from his > p4 work) that he may be doing something in this area in p4. After some promptings from Robert and his needs for Xorg recently I did start hacking on this again. However, I haven't tested it yet. What I have done so far is in //depot/user/jhb/pat/... and it does the following: 1) Adds a vm_cache_mode_t. Each arch defines the valid values for this (I've only done the MD portions of this work for amd64 so far). Every arch must at least define a value for VM_CACHE_DEFAULT. 2) Stores a cache mode in each vm_map_entry struct. This cache mode is then passed down to a few pmap functions: pmap_object_init_pt(), pmap_enter_object(), and pmap_enter_quick(). Several vm_map routines such as vm_map_insert() and vm_map_find() now take a cache mode to use when adding a new mapping. 3) Each VM object stores a cache mode as well (defaults to VM_CACHE_DEFAULT). When a VM_CACHE_DEFAULT mapping is made of an object, the cache mode of the object is used. 4) A new VM object type: OBJT_SG. This object type has its own pager that is sort of like the device pager. However, instead of invoking d_mmap() to determine the physaddr for a given page, it consults a pre-created scatter/gather list (an ADT from my branch for working on unmapped buffer I/O) to determine the backing physical address for a given virtual address. 5) A new callback for device mmap: d_mmap_single(). One of the features of this is that it can return a vm_object_t to be used to satisfy the mmap() request instead of using the device's device pager VM object. 6) A new mcache() system call similar to mprotect(), except that it changes the cache mode of an address range rather than the protection. This may not be all that useful really. Given all this, a driver could do the following to map a "thing" as WC in both userland and the kernel: 1) When it learns about a "thing" it creates a SG list to describe it. If the "thing" consists of userland pages, it has to wire the pages first. The driver can use vm_allocate_pager() to create a OBJT_SG VM object. It sets the object's cache mode to VM_CACHE_WC (if the arch supports that). 2) When userland wants to map the "thing" it does a device mmap() with a proper length and a file offset that is a cookie for the "thing". The device driver's d_mmap_single() recognizes the magic file offset and returns the "thing"'s VM object. Since the mapping info is now part of a normal object mapping, it will go away via munmap(), etc. The driver no longer has to do weird gymnastics to invalidate mappings from its device pager as "transient" mappings are no longer stored in the device pager. 3) When the driver wants to map the "thing" into the kernel, it can use vm_map_find() to insert the "thing"'s VM object into kernel map. And I think that is all there is to it. I need to test this somehow to make sure though, and make sure this meets the needs of Robert and Nvidia. -- John Baldwin From rnoland at FreeBSD.org Thu Apr 30 21:52:23 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Apr 30 21:52:29 2009 Subject: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation In-Reply-To: <200904301736.52325.jhb@freebsd.org> References: <1240962328.2021.10.camel@wombat.2hip.net> <49F79841.9030702@elischer.org> <200904301736.52325.jhb@freebsd.org> Message-ID: <1241128325.1848.0.camel@balrog.2hip.net> On Thu, 2009-04-30 at 17:36 -0400, John Baldwin wrote: > On Tuesday 28 April 2009 7:58:57 pm Julian Elischer wrote: > > Robert Noland wrote: > > > On Tue, 2009-04-28 at 16:48 -0500, Kevin Day wrote: > > >> On Apr 28, 2009, at 3:19 PM, Julian Bangert wrote: > > >> > > >>> Hello, > > >>> > > >>> I am currently trying to work a bit on the remaining "missing > > >>> feature" that NVIDIA requires ( > http://wiki.freebsd.org/NvidiaFeatureRequests > > >>> or a back post in this ML) - the improved mmap system call. > > > > > > you might check with jhb (john Baldwin) as I think (from his > > p4 work) that he may be doing something in this area in p4. > > After some promptings from Robert and his needs for Xorg recently I did start > hacking on this again. However, I haven't tested it yet. What I have done > so far is in //depot/user/jhb/pat/... and it does the following: > > 1) Adds a vm_cache_mode_t. Each arch defines the valid values for this (I've > only done the MD portions of this work for amd64 so far). Every arch must at > least define a value for VM_CACHE_DEFAULT. > > 2) Stores a cache mode in each vm_map_entry struct. This cache mode is then > passed down to a few pmap functions: pmap_object_init_pt(), > pmap_enter_object(), and pmap_enter_quick(). Several vm_map routines such as > vm_map_insert() and vm_map_find() now take a cache mode to use when adding a > new mapping. > > 3) Each VM object stores a cache mode as well (defaults to VM_CACHE_DEFAULT). > When a VM_CACHE_DEFAULT mapping is made of an object, the cache mode of the > object is used. > > 4) A new VM object type: OBJT_SG. This object type has its own pager that is > sort of like the device pager. However, instead of invoking d_mmap() to > determine the physaddr for a given page, it consults a pre-created > scatter/gather list (an ADT from my branch for working on unmapped buffer > I/O) to determine the backing physical address for a given virtual address. > > 5) A new callback for device mmap: d_mmap_single(). One of the features of > this is that it can return a vm_object_t to be used to satisfy the mmap() > request instead of using the device's device pager VM object. > > 6) A new mcache() system call similar to mprotect(), except that it changes > the cache mode of an address range rather than the protection. This may not > be all that useful really. > > Given all this, a driver could do the following to map a "thing" as WC in both > userland and the kernel: > > 1) When it learns about a "thing" it creates a SG list to describe it. If > the "thing" consists of userland pages, it has to wire the pages first. The > driver can use vm_allocate_pager() to create a OBJT_SG VM object. It sets > the object's cache mode to VM_CACHE_WC (if the arch supports that). > > 2) When userland wants to map the "thing" it does a device mmap() with a > proper length and a file offset that is a cookie for the "thing". The device > driver's d_mmap_single() recognizes the magic file offset and returns > the "thing"'s VM object. Since the mapping info is now part of a normal > object mapping, it will go away via munmap(), etc. The driver no longer has > to do weird gymnastics to invalidate mappings from its device pager > as "transient" mappings are no longer stored in the device pager. > > 3) When the driver wants to map the "thing" into the kernel, it can use > vm_map_find() to insert the "thing"'s VM object into kernel map. > > And I think that is all there is to it. I need to test this somehow to make > sure though, and make sure this meets the needs of Robert and Nvidia. I think this sounds pretty good... I need to get my perforce foo up to speed so I can try it out... robert. -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090430/a6f1d7b3/attachment.pgp From bruce at cran.org.uk Thu Apr 30 21:52:52 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Thu Apr 30 21:52:59 2009 Subject: ACPI-fast default timecounter, but HPET 83% faster In-Reply-To: <200904300846.41576.jhb@freebsd.org> References: <200904270150.31912.pieter@degoeje.nl> <7d6fde3d0904261927s1a67cf85jc982c1a68e30e081@mail.gmail.com> <200904300846.41576.jhb@freebsd.org> Message-ID: <20090430225245.538d073e@gluon.draftnet> On Thu, 30 Apr 2009 08:46:41 -0400 John Baldwin wrote: > On Sunday 26 April 2009 10:27:42 pm Garrett Cooper wrote: > > Why's the default ACPI-fast? For power-saving functionality or > > because of the `quality' factor? What is the criteria that > > determines the `quality' of a clock as what's being reported above > > (I know what determines the quality of a clock visually from a > > oscilloscope =])? > > I suspect that the quality of the HPET driver is lower simply because > no one had measured it previously and HPET is newer and less "proven". > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_hpet.c shows some of the history behind the decision. Apparently it used to be slower but it was hoped it would get faster as systems supported it better. I guess that's happening now. -- Bruce Cran From reg at FreeBSD.ORG Thu Apr 30 22:08:10 2009 From: reg at FreeBSD.ORG (Jeremy Lea) Date: Thu Apr 30 22:08:17 2009 Subject: SoC2009: libpkg, pkg tools rewrite In-Reply-To: References: Message-ID: <20090430214520.GA37974@flint.openpave.org> Hi, On Sat, Apr 25, 2009 at 03:20:59PM -0400, David Forsythe wrote: > This summer I'll be working on creating a package library and using > that library to rewrite the pkg tools. A package library has been > discussed and even started before, but FreeBSD still does not have > one. This summer I'd like to get enough of the library done to atle > ast have a new set of pkg tools completed with the current features, > but ideally I'd like to get far enough to splice in some of the ideas > I have for new features. Since I've already done most of the work on this already, please, please, please, don't ignore what I have done. I know that it is not perfect, and that it is now five plus years out of date. But I have covered half of the bullet points on your to-do list already. The code is at http://sourceforge.net/projects/fpkg and some README stuff is at http://fpkg.sourceforge.net/ Some things which I think are critical: 1. The library needs a global "package manager". This needs to perform all of the tasks, and it should ideally do this through a task queue (which I didn't implement). See the lib/lib.h header in FreePKG. 2. The package manager must be able to separate out a structure of variables which can be determined without opening the +CONTENTS file. This must also include a package state, and the package manager must move these package headers from state to state. 3. There needs to be proper depends handling in the packages, so that we can maintain the correct dependency graph. This is vital for upgrading. This means adding @libdep and @filedep types to the package file. 4. bsd.port.mk should do everything through the tools. It should have no knowledge of the contents of /var/db/pkg. These are all done, to some degree in the code. The mistakes I made: 1. I made the file->pkg database to sensitive. If there is a miss it rebuilds the database for scratch - it should do a search through the +CONTENTS files and only rebuild it if there was a hit (meaning the database was wrong). 2. There needs to be a pkgname and origin database, which can be loaded at startup to prime the package manager. The dependency graph should also be stored in a database. These should be rebuilt if any directory in /var/db/pkg has a mtime later than the database (so could the file database). 3. There needs to be a set of flags which indicate how a package got installed (as a dependency or by the user), and if it has been upgraded in-place and might have old leftover libraries. These could go in +CONTENTS. In addition I also began the design of a new on disk package format. This was back when there was a group called openpackages which was trying to standardize ports/packages between the BSDs. In particular it has some ideas on package signing, which is an often requested feature. http://people.freebsd.org/~reg/opdesign.html Regards, -Jeremy -- FreeBSD - Because the best things in life are free... http://www.freebsd.org/ From xcllnt at mac.com Thu Apr 30 22:50:03 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Apr 30 22:50:10 2009 Subject: NetBSD 5.0 statistics In-Reply-To: References: <6101e8c40904300750i3e86fc0cnef09b0d4533627f7@mail.gmail.com> Message-ID: <78367CB5-7DAD-4DB1-99DA-2618CFACF376@mac.com> On Apr 30, 2009, at 12:32 PM, Robert Watson wrote: > > On Thu, 30 Apr 2009, Oliver Pinter wrote: > >> Is the FreeBSD's FS management so slow? >> >> http://www.netbsd.org/~ad/50/img15.html >> >> Or so big is the difference between the two cpu scheduler? > > Also, there's a known and serious performance regression in CAM > relating to tgged queueing, and the generic disk sort routine, > introduced 7.1, which will be fixed in 7.2. I can't speak more > generally to the benchmarks -- we'll need to run them in a > controlled environment and see if we can reproduce the results. Also :-) I recall that our "make -j X" actually limits the number of make processes/jobs to X. I don't know anything about build.sh, so I don't know if our make is at all being involved, but it would be good to know how the load varies per OS. We may simply have less parallelism in the build. -- Marcel Moolenaar xcllnt@mac.com