From jeremie at le-hen.org Fri May 2 07:04:06 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Fri May 2 07:04:11 2008 Subject: Integration of ProPolice in FreeBSD In-Reply-To: <20080427012416.GA9817@dragon.NUXI.org> Message-ID: <20080502070147.GE74500@obiwan.tataz.chchile.org> Hi David, Sorry for the late reply, I was abroad. On Sat, Apr 26, 2008 at 06:24:16PM -0700, David O'Brien wrote: > On Fri, Apr 18, 2008 at 03:27:49PM +0200, Jeremie Le Hen wrote: > > As you may already know I've integrated GCC's ProPolice into > > FreeBSD. The build infrastructure overlord, namely ru@, (I'm > > quoting kan@) has reviewed the patch and technically it is ready to > > hit the CVS tree. > > Please post the patch in this thread - your webserver has been very > difficult to contact. Indeed, sorry for the disturbance. I've attached the patch. This is what you should hit the tree, except there will be a few additional bits to prevent self foot-shooting when people will turn -fstack-protector into -fstack-protector-all in share/mk/bsd.sys.mk. I'm currently working on it. Thanks. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > -------------- next part -------------- A non-text attachment was scrubbed... Name: fbsd8-ssp.diff Type: text/x-diff Size: 15534 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080502/05e841b3/fbsd8-ssp.bin From xcllnt at mac.com Fri May 2 15:52:45 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri May 2 15:52:49 2008 Subject: Integration of ProPolice in FreeBSD In-Reply-To: <20080502070147.GE74500@obiwan.tataz.chchile.org> References: <20080502070147.GE74500@obiwan.tataz.chchile.org> Message-ID: <8ED24288-618C-4B55-A27E-C5FAB2E046E8@mac.com> On May 2, 2008, at 12:01 AM, Jeremie Le Hen wrote: >> Please post the patch in this thread - your webserver has been very >> difficult to contact. > > Indeed, sorry for the disturbance. I've attached the patch. This is > what you should hit the tree, except there will be a few additional > bits > to prevent self foot-shooting when people will turn -fstack-protector > into -fstack-protector-all in share/mk/bsd.sys.mk. I'm currently > working on it. Index: share/mk/bsd.sys.mk =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/share/mk/bsd.sys.mk,v retrieving revision 1.44 diff -u -p -r1.44 bsd.sys.mk --- share/mk/bsd.sys.mk 22 Nov 2007 23:21:12 -0000 1.44 +++ share/mk/bsd.sys.mk 29 Mar 2008 23:13:06 -0000 @@ -74,5 +74,10 @@ CWARNFLAGS += -Werror CWARNFLAGS += -Wno-unknown-pragmas .endif +.if ${MK_SSP} != "no" && ${CC} != "icc" +CFLAGS += -fstack-protector +# Don't use -Wstack-protector as it breaks world with -Werror. +.endif + # Allow user-specified additional warning flags CFLAGS += ${CWARNFLAGS} I may be better to explicitly test for GCC. I would not assume that GCC and ICC are the only options, even if they are now. There's a second place as well... Index: sys/boot/i386/Makefile.inc =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/boot/i386/ Makefile.inc,v retrieving revision 1.12 diff -u -p -r1.12 Makefile.inc --- sys/boot/i386/Makefile.inc 28 Sep 2006 10:02:04 -0000 1.12 +++ sys/boot/i386/Makefile.inc 28 Mar 2008 07:41:32 -0000 @@ -24,3 +24,5 @@ BTXDIR= ${.CURDIR}/../btx BTXLDR= ${BTXDIR}/btxldr/btxldr BTXKERN= ${BTXDIR}/btx/btx BTXCRT= ${BTXDIR}/lib/crt0.o + +.include "../Makefile.inc" Index: sys/boot/i386/loader/Makefile =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/boot/i386/loader/ Makefile,v retrieving revision 1.85 diff -u -p -r1.85 Makefile --- sys/boot/i386/loader/Makefile 29 May 2007 14:35:57 -0000 1.85 +++ sys/boot/i386/loader/Makefile 16 Apr 2008 09:14:10 -0000 @@ -1,5 +1,7 @@ # $FreeBSD: src/sys/boot/i386/loader/Makefile,v 1.85 2007/05/29 14:35:57 simokawa Exp $ +WITHOUT_SSP= + .include PROG= loader.sym Maybe second and third level makefiles should include ../../Makefile.inc and ../../../Makefile.inc resp. If, for arguments sake, we want to enable SSP in boot, then it's best if that only requires a single knob to be changed. This may not be a strong argument for SSP, but with Makefile.inc in place, I don't see a possible future in which another knob is added that controls overall behavior (e.g. something like the Watcom option to use argument passing in registers instead of on the stack for i386 -- you definitely want to have that apply to all code or none). Also, please make sure MK_SSP defaults to "no" on ia64. Thanks, -- Marcel Moolenaar xcllnt@mac.com From obrien at FreeBSD.org Sun May 4 04:01:11 2008 From: obrien at FreeBSD.org (David O'Brien) Date: Sun May 4 04:01:14 2008 Subject: Integration of ProPolice in FreeBSD In-Reply-To: <20080502070147.GE74500@obiwan.tataz.chchile.org> References: <20080427012416.GA9817@dragon.NUXI.org> <20080502070147.GE74500@obiwan.tataz.chchile.org> Message-ID: <20080504040110.GC94985@dragon.NUXI.org> On Fri, May 02, 2008 at 09:01:47AM +0200, Jeremie Le Hen wrote: > Index: sys/conf/kern.pre.mk > =================================================================== > RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/conf/kern.pre.mk,v > retrieving revision 1.97 > diff -u -p -r1.97 kern.pre.mk > --- sys/conf/kern.pre.mk 2 Feb 2008 19:55:28 -0000 1.97 > +++ sys/conf/kern.pre.mk 29 Mar 2008 14:06:45 -0000 > @@ -3,10 +3,7 @@ > # Part of a unified Makefile for building kernels. This part contains all > # of the definitions that need to be before %BEFORE_DEPEND. > > -SRCCONF?= /etc/src.conf > -.if exists(${SRCCONF}) > -.include "${SRCCONF}" > -.endif > +.include I may not be seeing it - why do you need this change? From kostikbel at gmail.com Sun May 4 17:31:51 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun May 4 17:31:55 2008 Subject: Per-open file private data for the cdevs Message-ID: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> Since the review for the clone-at-open patch (fdclone) posted some time ago mostly says that it would be better to implement per-file private data instead, I produced the patch along this line, The patch does not change the cdevsw ABI, instead, three new functions nt devfs_get_cdevpriv(void **datap); int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); void devfs_clear_cdevpriv(void); are provided for manipulation of the per-file private data. devfs_set_cdevpriv assigns the priv as private data for the file descriptor which is used to initiate currently performed driver operation. dtr is the function that will be called when either the last refernce to the file goes away or devfs_clear_cdevpriv is called. devfs_get_cdevpriv is the obvious accessor. devfs_clear_cdevpriv allows to clear the private data for the still open file. The synchronization of the cdev data and file private data is left to the driver code, I did not found any generic helper mechanism that could be useful there. Patch: http://people.freebsd.org/~kib/misc/fdpriv.1.patch Dumb driver that shows the basic usage of the proposed KPI: http://people.freebsd.org/~kib/misc/fpclone.c Previous version of the patch was tested by Peter Holm. -------------- 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-arch/attachments/20080504/77ecb9f2/attachment.pgp From ed at 80386.nl Mon May 5 07:49:25 2008 From: ed at 80386.nl (Ed Schouten) Date: Mon May 5 07:49:29 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> Message-ID: <20080505074924.GF1181@hoeg.nl> * Kostik Belousov wrote: > Since the review for the clone-at-open patch (fdclone) posted some time ago > mostly says that it would be better to implement per-file private data > instead, I produced the patch along this line, I also thought about this. The new TTY layer I'm developing needs the following patch to implement /dev/ptmx and /dev/ptyXX compatibility: --- sys/fs/devfs/devfs_vnops.c +++ sys/fs/devfs/devfs_vnops.c @@ -800,9 +800,8 @@ if(fp == NULL) return (error); #endif - KASSERT(fp->f_ops == &badfileops, - ("Could not vnode bypass device on fdops %p", fp->f_ops)); - finit(fp, fp->f_flag, DTYPE_VNODE, dev, &devfs_ops_f); + if (fp->f_ops == &badfileops) + finit(fp, fp->f_flag, DTYPE_VNODE, dev, &devfs_ops_f); return (error); } This way drivers can just implement d_fdopen() and call finit() there. It's probably not as nice as having the per-fdesc stuff inside devfs itself, but I'm not sure the amount of drivers that needs this makes it worth adding it to devfs itself. -- 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-arch/attachments/20080505/e4857e27/attachment.pgp From pjd at FreeBSD.org Mon May 5 08:40:55 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Mon May 5 08:40:57 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> Message-ID: <20080505081355.GB1628@garage.freebsd.pl> On Sun, May 04, 2008 at 08:10:02PM +0300, Kostik Belousov wrote: > Since the review for the clone-at-open patch (fdclone) posted some time ago > mostly says that it would be better to implement per-file private data > instead, I produced the patch along this line, > > The patch does not change the cdevsw ABI, instead, three new functions > nt devfs_get_cdevpriv(void **datap); > int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > void devfs_clear_cdevpriv(void); > are provided for manipulation of the per-file private data. > > devfs_set_cdevpriv assigns the priv as private data for the file descriptor > which is used to initiate currently performed driver operation. dtr > is the function that will be called when either the last refernce to > the file goes away or devfs_clear_cdevpriv is called. > > devfs_get_cdevpriv is the obvious accessor. > > devfs_clear_cdevpriv allows to clear the private data for the still > open file. > > The synchronization of the cdev data and file private data is left > to the driver code, I did not found any generic helper mechanism that > could be useful there. > > Patch: > http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > Dumb driver that shows the basic usage of the proposed KPI: > http://people.freebsd.org/~kib/misc/fpclone.c > > Previous version of the patch was tested by Peter Holm. Can you see if my OSD (Object-Specific-Data) KPI can be useful here? I've it only in perforce for now, but I think it's what you are looking for. I use it for jails and threads currently, but it is trivial to use it for other objects. Take a look: http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/user/pjd/zfs/sys/sys/osd.h&REV=3 When your code is loaded/initialized you call: static int slot; slot = osd_file_register(mod_destroy); Where mod_destroy is a function which knows how to free your private data. On unload: osd_file_deregister(slot); Now, when you want to attach private data: error = osd_file_set(fp, slot, ptr_to_your_data); You can get it with: ptr = osd_file_get(fp, slot); -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080505/401e626e/attachment.pgp From bugmaster at FreeBSD.org Mon May 5 11:07:02 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 5 11:07:05 2008 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200805051107.m45B71dG070638@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From jhb at freebsd.org Mon May 5 13:56:17 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon May 5 13:56:28 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080505074924.GF1181@hoeg.nl> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080505074924.GF1181@hoeg.nl> Message-ID: <200805050930.18114.jhb@freebsd.org> On Monday 05 May 2008 03:49:24 am Ed Schouten wrote: > * Kostik Belousov wrote: > > Since the review for the clone-at-open patch (fdclone) posted some time > > ago mostly says that it would be better to implement per-file private > > data instead, I produced the patch along this line, > > I also thought about this. The new TTY layer I'm developing needs the > following patch to implement /dev/ptmx and /dev/ptyXX compatibility: > > --- sys/fs/devfs/devfs_vnops.c > +++ sys/fs/devfs/devfs_vnops.c > @@ -800,9 +800,8 @@ > if(fp == NULL) > return (error); > #endif > - KASSERT(fp->f_ops == &badfileops, > - ("Could not vnode bypass device on fdops %p", fp->f_ops)); > - finit(fp, fp->f_flag, DTYPE_VNODE, dev, &devfs_ops_f); > + if (fp->f_ops == &badfileops) > + finit(fp, fp->f_flag, DTYPE_VNODE, dev, &devfs_ops_f); > return (error); > } > > This way drivers can just implement d_fdopen() and call finit() there. > It's probably not as nice as having the per-fdesc stuff inside devfs > itself, but I'm not sure the amount of drivers that needs this makes it > worth adding it to devfs itself. Many drivers currently do devfs cloning soley to get per-file data. Other OS's (such as WinXP and Linux) already provide facilities for drivers to set per-file data as well. This is definitely very useful. -- John Baldwin From jhb at freebsd.org Mon May 5 13:56:17 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon May 5 13:56:28 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080505074924.GF1181@hoeg.nl> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080505074924.GF1181@hoeg.nl> Message-ID: <200805050930.18114.jhb@freebsd.org> On Monday 05 May 2008 03:49:24 am Ed Schouten wrote: > * Kostik Belousov wrote: > > Since the review for the clone-at-open patch (fdclone) posted some time > > ago mostly says that it would be better to implement per-file private > > data instead, I produced the patch along this line, > > I also thought about this. The new TTY layer I'm developing needs the > following patch to implement /dev/ptmx and /dev/ptyXX compatibility: > > --- sys/fs/devfs/devfs_vnops.c > +++ sys/fs/devfs/devfs_vnops.c > @@ -800,9 +800,8 @@ > if(fp == NULL) > return (error); > #endif > - KASSERT(fp->f_ops == &badfileops, > - ("Could not vnode bypass device on fdops %p", fp->f_ops)); > - finit(fp, fp->f_flag, DTYPE_VNODE, dev, &devfs_ops_f); > + if (fp->f_ops == &badfileops) > + finit(fp, fp->f_flag, DTYPE_VNODE, dev, &devfs_ops_f); > return (error); > } > > This way drivers can just implement d_fdopen() and call finit() there. > It's probably not as nice as having the per-fdesc stuff inside devfs > itself, but I'm not sure the amount of drivers that needs this makes it > worth adding it to devfs itself. Many drivers currently do devfs cloning soley to get per-file data. Other OS's (such as WinXP and Linux) already provide facilities for drivers to set per-file data as well. This is definitely very useful. -- John Baldwin From jhb at freebsd.org Mon May 5 13:56:18 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon May 5 13:56:28 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> Message-ID: <200805050939.42425.jhb@freebsd.org> On Sunday 04 May 2008 01:10:02 pm Kostik Belousov wrote: > Since the review for the clone-at-open patch (fdclone) posted some time ago > mostly says that it would be better to implement per-file private data > instead, I produced the patch along this line, > > The patch does not change the cdevsw ABI, instead, three new functions > nt devfs_get_cdevpriv(void **datap); > int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > void devfs_clear_cdevpriv(void); > are provided for manipulation of the per-file private data. > > devfs_set_cdevpriv assigns the priv as private data for the file descriptor > which is used to initiate currently performed driver operation. dtr > is the function that will be called when either the last refernce to > the file goes away or devfs_clear_cdevpriv is called. > > devfs_get_cdevpriv is the obvious accessor. > > devfs_clear_cdevpriv allows to clear the private data for the still > open file. > > The synchronization of the cdev data and file private data is left > to the driver code, I did not found any generic helper mechanism that > could be useful there. > > Patch: > http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > Dumb driver that shows the basic usage of the proposed KPI: > http://people.freebsd.org/~kib/misc/fpclone.c > > Previous version of the patch was tested by Peter Holm. I like this very much and will use it instead of devfs cloning in ipmi(4) so we can use ipmievd when it is committed. IWBN if there was a more automated way of handling the unload race, for example if destroy_dev() could somehow clear all the per-open fd data. That may not be easily feasible, however. (In theory each cdev could have a list of "attached" 'struct file' objects that it updates in VOP_CLOSE() and for a destroy dev it detaches all the private data after marking the cdev with a bad/null cdevsw, however, that would bloat 'struct file' with at least one more pointer (if not two).) -- John Baldwin From kostikbel at gmail.com Mon May 5 14:21:02 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon May 5 14:21:07 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <200805050939.42425.jhb@freebsd.org> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <200805050939.42425.jhb@freebsd.org> Message-ID: <20080505142051.GS18958@deviant.kiev.zoral.com.ua> On Mon, May 05, 2008 at 09:39:42AM -0400, John Baldwin wrote: > On Sunday 04 May 2008 01:10:02 pm Kostik Belousov wrote: > > Since the review for the clone-at-open patch (fdclone) posted some time ago > > mostly says that it would be better to implement per-file private data > > instead, I produced the patch along this line, > > > > The patch does not change the cdevsw ABI, instead, three new functions > > nt devfs_get_cdevpriv(void **datap); > > int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > > void devfs_clear_cdevpriv(void); > > are provided for manipulation of the per-file private data. > > > > devfs_set_cdevpriv assigns the priv as private data for the file descriptor > > which is used to initiate currently performed driver operation. dtr > > is the function that will be called when either the last refernce to > > the file goes away or devfs_clear_cdevpriv is called. > > > > devfs_get_cdevpriv is the obvious accessor. > > > > devfs_clear_cdevpriv allows to clear the private data for the still > > open file. > > > > The synchronization of the cdev data and file private data is left > > to the driver code, I did not found any generic helper mechanism that > > could be useful there. > > > > Patch: > > http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > > > Dumb driver that shows the basic usage of the proposed KPI: > > http://people.freebsd.org/~kib/misc/fpclone.c > > > > Previous version of the patch was tested by Peter Holm. > > I like this very much and will use it instead of devfs cloning in ipmi(4) so > we can use ipmievd when it is committed. IWBN if there was a more automated > way of handling the unload race, for example if destroy_dev() could somehow > clear all the per-open fd data. That may not be easily feasible, however. > (In theory each cdev could have a list of "attached" 'struct file' objects > that it updates in VOP_CLOSE() and for a destroy dev it detaches all the > private data after marking the cdev with a bad/null cdevsw, however, that > would bloat 'struct file' with at least one more pointer (if not two).) Probably, I shall clarify that the dtr is called when the last reference to the struct file going away, unless the priv data is already cleared by the call to the devfs_clear_cdevpriv. The problem with VOP_CLOSE() is that some actions (like forced unmount or revoke) may cause less calls to the devfs_close then the files pointing to the cdev. Your proposal basically means that we need, besides the normal pointers file->vnode->cdev, have the reverse path cdev->file. I think this is ugly and better be handled by the fdrop(). -------------- 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-arch/attachments/20080505/5dc3d009/attachment.pgp From kostikbel at gmail.com Mon May 5 14:56:42 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon May 5 14:56:47 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080505081355.GB1628@garage.freebsd.pl> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080505081355.GB1628@garage.freebsd.pl> Message-ID: <20080505145631.GT18958@deviant.kiev.zoral.com.ua> On Mon, May 05, 2008 at 10:13:55AM +0200, Pawel Jakub Dawidek wrote: > On Sun, May 04, 2008 at 08:10:02PM +0300, Kostik Belousov wrote: > > Since the review for the clone-at-open patch (fdclone) posted some time ago > > mostly says that it would be better to implement per-file private data > > instead, I produced the patch along this line, > > > > The patch does not change the cdevsw ABI, instead, three new functions > > nt devfs_get_cdevpriv(void **datap); > > int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > > void devfs_clear_cdevpriv(void); > > are provided for manipulation of the per-file private data. > > > > devfs_set_cdevpriv assigns the priv as private data for the file descriptor > > which is used to initiate currently performed driver operation. dtr > > is the function that will be called when either the last refernce to > > the file goes away or devfs_clear_cdevpriv is called. > > > > devfs_get_cdevpriv is the obvious accessor. > > > > devfs_clear_cdevpriv allows to clear the private data for the still > > open file. > > > > The synchronization of the cdev data and file private data is left > > to the driver code, I did not found any generic helper mechanism that > > could be useful there. > > > > Patch: > > http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > > > Dumb driver that shows the basic usage of the proposed KPI: > > http://people.freebsd.org/~kib/misc/fpclone.c > > > > Previous version of the patch was tested by Peter Holm. > > Can you see if my OSD (Object-Specific-Data) KPI can be useful here? > I've it only in perforce for now, but I think it's what you are looking > for. I use it for jails and threads currently, but it is trivial to use > it for other objects. Take a look: > > http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/user/pjd/zfs/sys/sys/osd.h&REV=3 > > When your code is loaded/initialized you call: > > static int slot; > > slot = osd_file_register(mod_destroy); > > Where mod_destroy is a function which knows how to free your private > data. On unload: > > osd_file_deregister(slot); > > Now, when you want to attach private data: > > error = osd_file_set(fp, slot, ptr_to_your_data); > > You can get it with: > > ptr = osd_file_get(fp, slot); This is a nice feature, but I think that privdata is a fundamental internal operation of the kernel, and it would be wrong to use the OSD. In fact, the object we shall attach OSD to is the struct file, and we would need to export the struct file to the cdevsw operations. Since it both breaks current ABI and complicates the future changes to the struct file, I would much prefer to not engage this route. -------------- 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-arch/attachments/20080505/74ef8a37/attachment.pgp From jhb at freebsd.org Mon May 5 18:27:00 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon May 5 18:27:06 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080505142051.GS18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <200805050939.42425.jhb@freebsd.org> <20080505142051.GS18958@deviant.kiev.zoral.com.ua> Message-ID: <200805051156.14706.jhb@freebsd.org> On Monday 05 May 2008 10:20:51 am Kostik Belousov wrote: > On Mon, May 05, 2008 at 09:39:42AM -0400, John Baldwin wrote: > > On Sunday 04 May 2008 01:10:02 pm Kostik Belousov wrote: > > > Since the review for the clone-at-open patch (fdclone) posted some time ago > > > mostly says that it would be better to implement per-file private data > > > instead, I produced the patch along this line, > > > > > > The patch does not change the cdevsw ABI, instead, three new functions > > > nt devfs_get_cdevpriv(void **datap); > > > int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > > > void devfs_clear_cdevpriv(void); > > > are provided for manipulation of the per-file private data. > > > > > > devfs_set_cdevpriv assigns the priv as private data for the file descriptor > > > which is used to initiate currently performed driver operation. dtr > > > is the function that will be called when either the last refernce to > > > the file goes away or devfs_clear_cdevpriv is called. > > > > > > devfs_get_cdevpriv is the obvious accessor. > > > > > > devfs_clear_cdevpriv allows to clear the private data for the still > > > open file. > > > > > > The synchronization of the cdev data and file private data is left > > > to the driver code, I did not found any generic helper mechanism that > > > could be useful there. > > > > > > Patch: > > > http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > > > > > Dumb driver that shows the basic usage of the proposed KPI: > > > http://people.freebsd.org/~kib/misc/fpclone.c > > > > > > Previous version of the patch was tested by Peter Holm. > > > > I like this very much and will use it instead of devfs cloning in ipmi(4) so > > we can use ipmievd when it is committed. IWBN if there was a more automated > > way of handling the unload race, for example if destroy_dev() could somehow > > clear all the per-open fd data. That may not be easily feasible, however. > > (In theory each cdev could have a list of "attached" 'struct file' objects > > that it updates in VOP_CLOSE() and for a destroy dev it detaches all the > > private data after marking the cdev with a bad/null cdevsw, however, that > > would bloat 'struct file' with at least one more pointer (if not two).) > > Probably, I shall clarify that the dtr is called when the last reference > to the struct file going away, unless the priv data is already cleared > by the call to the devfs_clear_cdevpriv. > > The problem with VOP_CLOSE() is that some actions (like forced unmount > or revoke) may cause less calls to the devfs_close then the files > pointing to the cdev. Your proposal basically means that we need, > besides the normal pointers file->vnode->cdev, have the reverse path > cdev->file. I think this is ugly and better be handled by the fdrop(). The disconnect as I see it is that right now destroy_dev() "orphans" devices in that the files still exist but the backing cdev's now have dead operations. However, now you can have a partially orphaned cdev in that not all of the cdev state is torn down in destroy_dev(). In that sense it would be nice to have the behavior described above, and yes you would have to have the cdev's keep track of 'file's as I suggested. Could you handle the revoke(2) and forced umount cases either via VOP_REVOKE() or by adding a VOP_INACTIVE() to devfs? -- John Baldwin From kostikbel at gmail.com Mon May 5 20:40:21 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon May 5 20:40:27 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <200805051156.14706.jhb@freebsd.org> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <200805050939.42425.jhb@freebsd.org> <20080505142051.GS18958@deviant.kiev.zoral.com.ua> <200805051156.14706.jhb@freebsd.org> Message-ID: <20080505204013.GW18958@deviant.kiev.zoral.com.ua> On Mon, May 05, 2008 at 11:56:14AM -0400, John Baldwin wrote: > On Monday 05 May 2008 10:20:51 am Kostik Belousov wrote: > > On Mon, May 05, 2008 at 09:39:42AM -0400, John Baldwin wrote: > > > On Sunday 04 May 2008 01:10:02 pm Kostik Belousov wrote: > > > > Since the review for the clone-at-open patch (fdclone) posted some time > ago > > > > mostly says that it would be better to implement per-file private data > > > > instead, I produced the patch along this line, > > > > > > > > The patch does not change the cdevsw ABI, instead, three new functions > > > > nt devfs_get_cdevpriv(void **datap); > > > > int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > > > > void devfs_clear_cdevpriv(void); > > > > are provided for manipulation of the per-file private data. > > > > > > > > devfs_set_cdevpriv assigns the priv as private data for the file > descriptor > > > > which is used to initiate currently performed driver operation. dtr > > > > is the function that will be called when either the last refernce to > > > > the file goes away or devfs_clear_cdevpriv is called. > > > > > > > > devfs_get_cdevpriv is the obvious accessor. > > > > > > > > devfs_clear_cdevpriv allows to clear the private data for the still > > > > open file. > > > > > > > > The synchronization of the cdev data and file private data is left > > > > to the driver code, I did not found any generic helper mechanism that > > > > could be useful there. > > > > > > > > Patch: > > > > http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > > > > > > > Dumb driver that shows the basic usage of the proposed KPI: > > > > http://people.freebsd.org/~kib/misc/fpclone.c > > > > > > > > Previous version of the patch was tested by Peter Holm. > > > > > > I like this very much and will use it instead of devfs cloning in ipmi(4) > so > > > we can use ipmievd when it is committed. IWBN if there was a more > automated > > > way of handling the unload race, for example if destroy_dev() could > somehow > > > clear all the per-open fd data. That may not be easily feasible, however. > > > (In theory each cdev could have a list of "attached" 'struct file' objects > > > that it updates in VOP_CLOSE() and for a destroy dev it detaches all the > > > private data after marking the cdev with a bad/null cdevsw, however, that > > > would bloat 'struct file' with at least one more pointer (if not two).) > > > > Probably, I shall clarify that the dtr is called when the last reference > > to the struct file going away, unless the priv data is already cleared > > by the call to the devfs_clear_cdevpriv. > > > > The problem with VOP_CLOSE() is that some actions (like forced unmount > > or revoke) may cause less calls to the devfs_close then the files > > pointing to the cdev. Your proposal basically means that we need, > > besides the normal pointers file->vnode->cdev, have the reverse path > > cdev->file. I think this is ugly and better be handled by the fdrop(). > > The disconnect as I see it is that right now destroy_dev() "orphans" devices > in that the files still exist but the backing cdev's now have dead > operations. However, now you can have a partially orphaned cdev in that not > all of the cdev state is torn down in destroy_dev(). In that sense it would > be nice to have the behavior described above, and yes you would have to have > the cdev's keep track of 'file's as I suggested. > > Could you handle the revoke(2) and forced umount cases either via > VOP_REVOKE() or by adding a VOP_INACTIVE() to devfs? I do not see how VOP_INACTIVE would be helpful there. Use of it still means the vnode->file walker. And, I quite dislike the backreferences like cdev->files or vnodes->files. My previous attempt of the cloning at open() resolved the lifecycle issues by making the per-fd data a cdev with the usual cdev management. I thought about either incrementing si_threadcount, or adding another refcounter to the cdev to track presence of the priv data. But destroy_dev() then have to block, and driver author still required to keep track the list of the allocated priv references to be able to actively unblock, like the d_purge. I then decided to leave this to the driver. -------------- 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-arch/attachments/20080505/15679d4d/attachment.pgp From jeremie at le-hen.org Mon May 5 21:13:18 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Mon May 5 21:13:30 2008 Subject: Integration of ProPolice in FreeBSD In-Reply-To: <20080504040110.GC94985@dragon.NUXI.org> References: <20080427012416.GA9817@dragon.NUXI.org> <20080502070147.GE74500@obiwan.tataz.chchile.org> <20080504040110.GC94985@dragon.NUXI.org> Message-ID: <20080505211051.GC32317@obiwan.tataz.chchile.org> On Sat, May 03, 2008 at 09:01:10PM -0700, David O'Brien wrote: > On Fri, May 02, 2008 at 09:01:47AM +0200, Jeremie Le Hen wrote: > > Index: sys/conf/kern.pre.mk > > =================================================================== > > RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/conf/kern.pre.mk,v > > retrieving revision 1.97 > > diff -u -p -r1.97 kern.pre.mk > > --- sys/conf/kern.pre.mk 2 Feb 2008 19:55:28 -0000 1.97 > > +++ sys/conf/kern.pre.mk 29 Mar 2008 14:06:45 -0000 > > @@ -3,10 +3,7 @@ > > # Part of a unified Makefile for building kernels. This part contains all > > # of the definitions that need to be before %BEFORE_DEPEND. > > > > -SRCCONF?= /etc/src.conf > > -.if exists(${SRCCONF}) > > -.include "${SRCCONF}" > > -.endif > > +.include > > I may not be seeing it - why do you need this change? It is needed so I can use MK_SSP later in kern.mk: =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/conf/kern.mk,v retrieving revision 1.52 diff -u -p -r1.52 kern.mk --- sys/conf/kern.mk 24 May 2007 21:53:42 -0000 1.52 +++ sys/conf/kern.mk 29 Mar 2008 13:44:15 -0000 @@ -97,3 +97,10 @@ CFLAGS+= -ffreestanding .if ${CC} == "icc" CFLAGS+= -restrict .endif + +# +# GCC SSP support. +# +.if ${MK_SSP} != "no" && ${CC} != "icc" +CFLAGS+= -fstack-protector +.endif Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From pjd at FreeBSD.org Tue May 6 06:12:24 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue May 6 06:12:26 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080505145631.GT18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080505081355.GB1628@garage.freebsd.pl> <20080505145631.GT18958@deviant.kiev.zoral.com.ua> Message-ID: <20080506061215.GB2508@garage.freebsd.pl> On Mon, May 05, 2008 at 05:56:31PM +0300, Kostik Belousov wrote: > On Mon, May 05, 2008 at 10:13:55AM +0200, Pawel Jakub Dawidek wrote: > > Can you see if my OSD (Object-Specific-Data) KPI can be useful here? > > I've it only in perforce for now, but I think it's what you are looking > > for. I use it for jails and threads currently, but it is trivial to use > > it for other objects. Take a look: > > > > http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/user/pjd/zfs/sys/sys/osd.h&REV=3 > > > > When your code is loaded/initialized you call: > > > > static int slot; > > > > slot = osd_file_register(mod_destroy); > > > > Where mod_destroy is a function which knows how to free your private > > data. On unload: > > > > osd_file_deregister(slot); > > > > Now, when you want to attach private data: > > > > error = osd_file_set(fp, slot, ptr_to_your_data); > > > > You can get it with: > > > > ptr = osd_file_get(fp, slot); > This is a nice feature, but I think that privdata is a fundamental > internal operation of the kernel, and it would be wrong to use > the OSD. [...] OSD is there to be used mostly by optional modules. For example if ZFS is not loaded there is no need to keep a pointer to its private data in struct prison and struct thread. > [...] In fact, the object we shall attach OSD to is the struct > file, and we would need to export the struct file to the cdevsw operations. > Since it both breaks current ABI and complicates the future changes to > the struct file, I would much prefer to not engage this route. Ok. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080506/0e4d91de/attachment.pgp From keramida at freebsd.org Wed May 7 03:29:20 2008 From: keramida at freebsd.org (Giorgos Keramidas) Date: Wed May 7 03:29:25 2008 Subject: Accounting for mbufs and clusters assigned to a socket buffer In-Reply-To: (gnn@freebsd.org's message of "Sun, 27 Apr 2008 17:07:56 -0700") References: <4811E384.5020604@freebsd.org> Message-ID: <8763tqkdk3.fsf@kobe.laptop> On Sun, 27 Apr 2008 17:07:56 -0700, gnn@freebsd.org wrote: >At Fri, 25 Apr 2008 15:58:28 +0200, andre wrote: >>gnn@freebsd.org wrote: >>> Howdy, >>> >>> The following patch updates the kernel (CURRENT as of 23 April or >>> so) and netstat(1) to show not only the bytes in the receive and >>> send queues but also the mbuf and cluster usage per socket buffer. >>> I'd be interested in people's comments on this. I'd like to extend >>> such counting to show more information, in particular how much of a >>> cluster or mbuf is actually in use. >> >> The intent of tracking that information is good. However there are >> some problems with your approach: M_EXT does not mean the mbuf has a >> 2k cluster attached. It could by any external storage. That is a 2k >> (classic) cluster, a 4k (page size) cluster, a 9k cluster, a VM page >> (sendfile), and so on. > > Yup, this is a first cut. > >> The field sb_mbcnt already gives you the aggregated gross storage >> space in use for the socket. And sb_cc tells how much actual payload >> it contains. > > Right but it does not tell us the mix of clusters vs. mbufs, which is > something useful for tuning. That would be very useful indeed :-) I guess we could check *both* (m_flags & M_EXT) and m_ext.ext_type. This won't really show how many mbufs use a classic cluster vs. a 9k cluster, but checking for all the m_ext.ext_types is probably going to look a bit ugly in a single if-check :( We have at least EXT_CLUSTER, EXT_JUMBOP, EXT_JUMBO9, EXT_JUMBO16 and EXT_PACKET which may be interesting for cluster-related accounting, but in socketvar.h we can't really use the uma zone accounting. I just noticed that the 'interesting' ext_types are conveniently short integers though. Maybe we could change sb_ccnt to a small array, and then change if ((m)->m_flags & M_EXT) \ (sb)->sb_ccnt += 1; to something like: if ((m)->m_flags & M_EXT && (m)->m_ext.ext_type < EXT_MBUF) \ (sb)->sb_ccnt[(m)->m_ext.ext_type - 1] += 1; \ With our current ext_type's #define EXT_CLUSTER 1 /* mbuf cluster */ #define EXT_SFBUF 2 /* sendfile(2)'s sf_bufs */ #define EXT_JUMBOP 3 /* jumbo cluster 4096 bytes */ #define EXT_JUMBO9 4 /* jumbo cluster 9216 bytes */ #define EXT_JUMBO16 5 /* jumbo cluster 16184 bytes */ #define EXT_PACKET 6 /* mbuf+cluster from packet zone */ #define EXT_MBUF 7 /* external mbuf reference (M_IOVEC) */ ... the [ext_type - 1] would move the burden of parsing the ext_type at the place where we actually have to print something about the sb_ccnt counters. Would the 'bloat' of u_int[6] for ext_type's which are unused be too much to keep around? From gnn at freebsd.org Thu May 8 15:10:32 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Thu May 8 15:10:37 2008 Subject: Accounting for mbufs and clusters assigned to a socket buffer In-Reply-To: <8763tqkdk3.fsf@kobe.laptop> References: <4811E384.5020604@freebsd.org> <8763tqkdk3.fsf@kobe.laptop> Message-ID: At Wed, 07 May 2008 06:17:48 +0300, Giorgos Keramidas wrote: > > I guess we could check *both* (m_flags & M_EXT) and m_ext.ext_type. > > This won't really show how many mbufs use a classic cluster vs. a 9k > cluster, but checking for all the m_ext.ext_types is probably going to > look a bit ugly in a single if-check :( > > We have at least EXT_CLUSTER, EXT_JUMBOP, EXT_JUMBO9, EXT_JUMBO16 and > EXT_PACKET which may be interesting for cluster-related accounting, but > in socketvar.h we can't really use the uma zone accounting. I just > noticed that the 'interesting' ext_types are conveniently short integers > though. Maybe we could change sb_ccnt to a small array, and then change > > if ((m)->m_flags & M_EXT) \ > (sb)->sb_ccnt += 1; > > to something like: > > if ((m)->m_flags & M_EXT && (m)->m_ext.ext_type < EXT_MBUF) \ > (sb)->sb_ccnt[(m)->m_ext.ext_type - 1] += 1; \ > > With our current ext_type's > > #define EXT_CLUSTER 1 /* mbuf cluster */ > #define EXT_SFBUF 2 /* sendfile(2)'s sf_bufs */ > #define EXT_JUMBOP 3 /* jumbo cluster 4096 bytes */ > #define EXT_JUMBO9 4 /* jumbo cluster 9216 bytes */ > #define EXT_JUMBO16 5 /* jumbo cluster 16184 bytes */ > #define EXT_PACKET 6 /* mbuf+cluster from packet zone */ > #define EXT_MBUF 7 /* external mbuf reference (M_IOVEC) */ > ... > > the [ext_type - 1] would move the burden of parsing the ext_type at the > place where we actually have to print something about the sb_ccnt > counters. > > Would the 'bloat' of u_int[6] for ext_type's which are unused be too > much to keep around? I don't know if we want to go that far, but we could certainly try it. I'll keep it in mind. Thanks, George From eric at anholt.net Fri May 9 17:24:55 2008 From: eric at anholt.net (Eric Anholt) Date: Fri May 9 17:24:58 2008 Subject: Feature requests for open-source graphics Message-ID: <1210352688.2152.78.camel@localhost> 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-arch/attachments/20080509/d245c61b/attachment.pgp From rar102 at ra.msstate.edu Sat May 10 16:28:24 2008 From: rar102 at ra.msstate.edu (rar102@ra.msstate.edu) Date: Sat May 10 16:28:29 2008 Subject: compaq 6515b turion x2 laptop Message-ID: <1210436112.4825ca102cfce@webmail.msstate.edu> I recently bought a new laptop. I have been unsuccesful in installing FreeBSD (or any alternatives for that matter) onto it. I wonder if I can get some help. I have tried to: 1. install the FreeBSD amd64 7.0 release. Stopped at a "No disks found!" prompt. With a little bit googling, I see that FreeBSD has been successfully installed onto ST9120822AS hard drive. 2. run the latest Knoppix on it (just to see if the Debian i386 Linux flavors can do it). Hangs on detecting hard drive. To be honest, I want BSD if I can use it, anyway. 3. install the FreeBSD 7-stable amd64 April snapshot. Same result as #1. 4. install NetBSD amd 4.0-release. Gives a disk geometry warning but installs without much further ado. In fact, I am still using NetBSD's bootloader. It boots both Vista and NetBSD. But... when I boot into NetBSD, it overheats, panics and dies within a minute. Trolling the internet again, I see that I am not the only one that has run into this problem. It is not running long enough to try an ftp install. I would like to not burn up this motherboard and I don't see any NetBSD snapshot iso's to see if they have resolved this problem. 5. install the FreeBSD i386 7.0 release. Installer complains about disk geometry. At the partitioning screen I press 'g' ('Set Disk Geometry'). I previously used Vista's magic partition resizer to leave me some space. I tell the sysintall to format that empty space as ufs2 and press 'q' ('Quit' out the disk partitioning step of sysintall). At this point, it pops up a message that my partitions are not starting on disk boundaries. I aborted the install at that point. It may still work. I just don't know. I would rather 6. install the FreeBSD i386 7-stable April snapshot. Same result as #1 and #3. This was kind of strange. I would have expected the same result as #5. Any suggestions??? RAR From cokane at FreeBSD.org Sat May 10 17:04:07 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Sat May 10 17:04:12 2008 Subject: compaq 6515b turion x2 laptop In-Reply-To: <1210436112.4825ca102cfce@webmail.msstate.edu> References: <1210436112.4825ca102cfce@webmail.msstate.edu> Message-ID: <1210437989.62567.17.camel@localhost> On Sat, 2008-05-10 at 11:15 -0500, rar102@ra.msstate.edu wrote: > I recently bought a new laptop. I have been unsuccesful in installing FreeBSD > (or any alternatives for that matter) onto it. I wonder if I can get some > help. I have tried to: > > 1. install the FreeBSD amd64 7.0 release. Stopped at a "No disks found!" > prompt. With a little bit googling, I see that FreeBSD has been successfully > installed onto ST9120822AS hard drive. > > 2. run the latest Knoppix on it (just to see if the Debian i386 Linux flavors > can do it). Hangs on detecting hard drive. To be honest, I want BSD if I can > use it, anyway. > > 3. install the FreeBSD 7-stable amd64 April snapshot. Same result as #1. > > 4. install NetBSD amd 4.0-release. Gives a disk geometry warning but installs > without much further ado. In fact, I am still using NetBSD's bootloader. It > boots both Vista and NetBSD. But... when I boot into NetBSD, it overheats, > panics and dies within a minute. Trolling the internet again, I see that I am > not the only one that has run into this problem. It is not running long enough > to try an ftp install. I would like to not burn up this motherboard and I > don't see any NetBSD snapshot iso's to see if they have resolved this problem. > > 5. install the FreeBSD i386 7.0 release. Installer complains about disk > geometry. At the partitioning screen I press 'g' ('Set Disk Geometry'). I > previously used Vista's magic partition resizer to leave me some space. I tell > the sysintall to format that empty space as ufs2 and press 'q' ('Quit' out the > disk partitioning step of sysintall). At this point, it pops up a message that > my partitions are not starting on disk boundaries. I aborted the install at > that point. It may still work. I just don't know. I would rather > > 6. install the FreeBSD i386 7-stable April snapshot. Same result as #1 and #3. > This was kind of strange. I would have expected the same result as #5. > > Any suggestions??? > > RAR > RAR, You are in luck! Well, actually I have good news and I have bad news. The good news is that I have nearly the same (6715b) laptop and experienced similar problems when getting FreeBSD onto it. After some work, I've been able to use FreeBSD reliably on the system. The bad news is that you probably have an overlap of PCI memory ranges between the SATA controller and another device in the system (likely the audio controller). I put up a page describing the problem here: http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_hp_compaq_6715b_working Specifically, read this section: http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#the_onboard_ati_sb600_hda_audio_controller Give me the weekend, and I will post a 7.0-RELEASE CD with the patch in it. I figured that I should have done it a while ago. Oh well. While you are at it, see if you can use Scroll-Lock and the up/down keys to read the kernel messages. See if you can find the atapci0 probe line for your SATA controller (AHCI), as well as the line for your pcm0 device and send them back to me. I can add your info to my webpage to help others. It will look like this: atapci0: port 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 ... pcm0: mem 0xd0608000-0xd060bfff irq 16 at device 20.2 on pci0 You'll notice the "mem" resource for the audio controller is 0xd0608000-0xd060bff, and the "mem" resource for the SATA controller is 0xd0609000-0xd06093ff. The SATA controller's "mem" resource is completely covered by this audio controller. If you happen to have access to another machine for building your own releases, you can try my patch and build them from it. -- Coleman Kane -------------- 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-arch/attachments/20080510/9c316d01/attachment.pgp From rar102 at ra.msstate.edu Sat May 10 17:13:17 2008 From: rar102 at ra.msstate.edu (rar102@ra.msstate.edu) Date: Sat May 10 17:13:20 2008 Subject: compaq 6515b turion x2 laptop In-Reply-To: <1210437989.62567.17.camel@localhost> References: <1210436112.4825ca102cfce@webmail.msstate.edu> <1210437989.62567.17.camel@localhost> Message-ID: <1210439595.4825d7ab5c1df@webmail.msstate.edu> Quoting Coleman Kane : Yes!!! thank you. Unfortunately, I don't have access to another amd64 box to try your patch. Sorry. But, I will look at the dmesg and send it to you. > RAR, > > You are in luck! Well, actually I have good news and I have bad news. > The good news is that I have nearly the same (6715b) laptop and > experienced similar problems when getting FreeBSD onto it. After some > work, I've been able to use FreeBSD reliably on the system. > > The bad news is that you probably have an overlap of PCI memory ranges > between the SATA controller and another device in the system (likely the > audio controller). > > I put up a page describing the problem here: > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_hp_compaq_6715b_working > > Specifically, read this section: > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#the_onboard_ati_sb600_hda_audio_controller > > Give me the weekend, and I will post a 7.0-RELEASE CD with the patch in > it. I figured that I should have done it a while ago. Oh well. > > While you are at it, see if you can use Scroll-Lock and the up/down keys > to read the kernel messages. See if you can find the atapci0 probe line > for your SATA controller (AHCI), as well as the line for your pcm0 > device and send them back to me. I can add your info to my webpage to > help others. > > It will look like this: > atapci0: port > 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem > 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 > ... > pcm0: mem 0xd0608000-0xd060bfff > irq 16 at device 20.2 on pci0 > > You'll notice the "mem" resource for the audio controller is > 0xd0608000-0xd060bff, and the "mem" resource for the SATA controller is > 0xd0609000-0xd06093ff. The SATA controller's "mem" resource is > completely covered by this audio controller. > > If you happen to have access to another machine for building your own > releases, you can try my patch and build them from it. > > -- > Coleman Kane > From cokane at FreeBSD.org Sat May 10 18:35:33 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Sat May 10 18:35:38 2008 Subject: compaq 6515b turion x2 laptop In-Reply-To: <1210439595.4825d7ab5c1df@webmail.msstate.edu> References: <1210436112.4825ca102cfce@webmail.msstate.edu> <1210437989.62567.17.camel@localhost> <1210439595.4825d7ab5c1df@webmail.msstate.edu> Message-ID: <1210444435.62567.19.camel@localhost> On Sat, 2008-05-10 at 12:13 -0500, rar102@ra.msstate.edu wrote: > Quoting Coleman Kane : > > Yes!!! thank you. Unfortunately, I don't have access to another amd64 box to > try your patch. Sorry. But, I will look at the dmesg and send it to you. Excellent. A dmesg will be very helpful for me to write a patch from, as it will allow me to see if it is or is not the sound driver overlapping memory in your case. I suspect that the BIOS images are so similar that you probably even have almost the same bios-chosen memory regions on your system. > > > RAR, > > > > You are in luck! Well, actually I have good news and I have bad news. > > The good news is that I have nearly the same (6715b) laptop and > > experienced similar problems when getting FreeBSD onto it. After some > > work, I've been able to use FreeBSD reliably on the system. > > > > The bad news is that you probably have an overlap of PCI memory ranges > > between the SATA controller and another device in the system (likely the > > audio controller). > > > > I put up a page describing the problem here: > > > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_hp_compaq_6715b_working > > > > Specifically, read this section: > > > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#the_onboard_ati_sb600_hda_audio_controller > > > > Give me the weekend, and I will post a 7.0-RELEASE CD with the patch in > > it. I figured that I should have done it a while ago. Oh well. > > > > While you are at it, see if you can use Scroll-Lock and the up/down keys > > to read the kernel messages. See if you can find the atapci0 probe line > > for your SATA controller (AHCI), as well as the line for your pcm0 > > device and send them back to me. I can add your info to my webpage to > > help others. > > > > It will look like this: > > atapci0: port > > 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem > > 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 > > ... > > pcm0: mem 0xd0608000-0xd060bfff > > irq 16 at device 20.2 on pci0 > > > > You'll notice the "mem" resource for the audio controller is > > 0xd0608000-0xd060bff, and the "mem" resource for the SATA controller is > > 0xd0609000-0xd06093ff. The SATA controller's "mem" resource is > > completely covered by this audio controller. > > > > If you happen to have access to another machine for building your own > > releases, you can try my patch and build them from it. > > > > -- > > Coleman Kane > > > > > -- Coleman Kane -------------- 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-arch/attachments/20080510/e748fa44/attachment.pgp From jroberson at jroberson.net Sun May 11 07:51:20 2008 From: jroberson at jroberson.net (Jeff Roberson) Date: Sun May 11 07:51:25 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> Message-ID: <20080510214812.Y954@desktop> On Sun, 4 May 2008, Kostik Belousov wrote: > Since the review for the clone-at-open patch (fdclone) posted some time ago > mostly says that it would be better to implement per-file private data > instead, I produced the patch along this line, > > The patch does not change the cdevsw ABI, instead, three new functions > nt devfs_get_cdevpriv(void **datap); > int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > void devfs_clear_cdevpriv(void); > are provided for manipulation of the per-file private data. > > devfs_set_cdevpriv assigns the priv as private data for the file descriptor > which is used to initiate currently performed driver operation. dtr > is the function that will be called when either the last refernce to > the file goes away or devfs_clear_cdevpriv is called. > > devfs_get_cdevpriv is the obvious accessor. > > devfs_clear_cdevpriv allows to clear the private data for the still > open file. > > The synchronization of the cdev data and file private data is left > to the driver code, I did not found any generic helper mechanism that > could be useful there. > > Patch: > http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > Dumb driver that shows the basic usage of the proposed KPI: > http://people.freebsd.org/~kib/misc/fpclone.c > > Previous version of the patch was tested by Peter Holm. > Hi Kostik, Are these per-instances structures intended to be used by anything other than devices? If not can we make them a union with the DTYPE_VNODE fields to save space? Thanks, Jeff From kostikbel at gmail.com Sun May 11 11:50:38 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun May 11 11:50:43 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080510214812.Y954@desktop> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080510214812.Y954@desktop> Message-ID: <20080511115030.GV18958@deviant.kiev.zoral.com.ua> On Sat, May 10, 2008 at 09:53:12PM -1000, Jeff Roberson wrote: > On Sun, 4 May 2008, Kostik Belousov wrote: > > >Since the review for the clone-at-open patch (fdclone) posted some time ago > >mostly says that it would be better to implement per-file private data > >instead, I produced the patch along this line, > > > >The patch does not change the cdevsw ABI, instead, three new functions > >nt devfs_get_cdevpriv(void **datap); > >int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > >void devfs_clear_cdevpriv(void); > >are provided for manipulation of the per-file private data. > > > >devfs_set_cdevpriv assigns the priv as private data for the file descriptor > >which is used to initiate currently performed driver operation. dtr > >is the function that will be called when either the last refernce to > >the file goes away or devfs_clear_cdevpriv is called. > > > >devfs_get_cdevpriv is the obvious accessor. > > > >devfs_clear_cdevpriv allows to clear the private data for the still > >open file. > > > >The synchronization of the cdev data and file private data is left > >to the driver code, I did not found any generic helper mechanism that > >could be useful there. > > > >Patch: > >http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > > >Dumb driver that shows the basic usage of the proposed KPI: > >http://people.freebsd.org/~kib/misc/fpclone.c > > > >Previous version of the patch was tested by Peter Holm. > > > > Hi Kostik, > > Are these per-instances structures intended to be used by anything other > than devices? If not can we make them a union with the DTYPE_VNODE > fields to save space? > > Thanks, > Jeff The current version of the patch is at http://people.freebsd.org/~kib/misc/fdpriv.3.patch Per insistence of John Baldwin and request of Eric Anholt, the destructors are called now when either file is last closed, or the device is destroyed. This versions adds only one pointer to the struct file. Jeff, would you, please, explicitely specify what field you propose to union with the f_cdevpriv ? -------------- 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-arch/attachments/20080511/8b80e732/attachment.pgp From kostikbel at gmail.com Sun May 11 11:58:24 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun May 11 11:58:29 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080511115030.GV18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080510214812.Y954@desktop> <20080511115030.GV18958@deviant.kiev.zoral.com.ua> Message-ID: <20080511115815.GW18958@deviant.kiev.zoral.com.ua> On Sun, May 11, 2008 at 02:50:30PM +0300, Kostik Belousov wrote: > On Sat, May 10, 2008 at 09:53:12PM -1000, Jeff Roberson wrote: > > On Sun, 4 May 2008, Kostik Belousov wrote: > > > > >Since the review for the clone-at-open patch (fdclone) posted some time ago > > >mostly says that it would be better to implement per-file private data > > >instead, I produced the patch along this line, > > > > > >The patch does not change the cdevsw ABI, instead, three new functions > > >nt devfs_get_cdevpriv(void **datap); > > >int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > > >void devfs_clear_cdevpriv(void); > > >are provided for manipulation of the per-file private data. > > > > > >devfs_set_cdevpriv assigns the priv as private data for the file descriptor > > >which is used to initiate currently performed driver operation. dtr > > >is the function that will be called when either the last refernce to > > >the file goes away or devfs_clear_cdevpriv is called. > > > > > >devfs_get_cdevpriv is the obvious accessor. > > > > > >devfs_clear_cdevpriv allows to clear the private data for the still > > >open file. > > > > > >The synchronization of the cdev data and file private data is left > > >to the driver code, I did not found any generic helper mechanism that > > >could be useful there. > > > > > >Patch: > > >http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > > > > >Dumb driver that shows the basic usage of the proposed KPI: > > >http://people.freebsd.org/~kib/misc/fpclone.c > > > > > >Previous version of the patch was tested by Peter Holm. > > > > > > > Hi Kostik, > > > > Are these per-instances structures intended to be used by anything other > > than devices? If not can we make them a union with the DTYPE_VNODE > > fields to save space? > > > > Thanks, > > Jeff > > The current version of the patch is at > http://people.freebsd.org/~kib/misc/fdpriv.3.patch > > Per insistence of John Baldwin and request of Eric Anholt, the destructors > are called now when either file is last closed, or the device is destroyed. > This versions adds only one pointer to the struct file. > > Jeff, would you, please, explicitely specify what field you propose to > union with the f_cdevpriv ? Of course, I forgot to answer the question. Yes, the KPI is supposed to be used by the drivers only. Please, note that device open files have DTYPE_VNODE. -------------- 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-arch/attachments/20080511/eef9214d/attachment.pgp From cokane at FreeBSD.org Sun May 11 12:51:25 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Sun May 11 12:51:30 2008 Subject: compaq 6515b turion x2 laptop In-Reply-To: <1210444435.62567.19.camel@localhost> References: <1210436112.4825ca102cfce@webmail.msstate.edu> <1210437989.62567.17.camel@localhost> <1210439595.4825d7ab5c1df@webmail.msstate.edu> <1210444435.62567.19.camel@localhost> Message-ID: <1210510187.62567.22.camel@localhost> On Sat, 2008-05-10 at 14:33 -0400, Coleman Kane wrote: > On Sat, 2008-05-10 at 12:13 -0500, rar102@ra.msstate.edu wrote: > > Quoting Coleman Kane : > > > > Yes!!! thank you. Unfortunately, I don't have access to another amd64 box to > > try your patch. Sorry. But, I will look at the dmesg and send it to you. > > Excellent. A dmesg will be very helpful for me to write a patch from, as > it will allow me to see if it is or is not the sound driver overlapping > memory in your case. I suspect that the BIOS images are so similar that > you probably even have almost the same bios-chosen memory regions on > your system. If you're having difficulty getting a dmesg, you might want to try booting off the LiveFS disc with a USB flash drive plugged in. You can then mount the flash drive (which should be detected as SCSI) and write the dmesg output there. > > > > > > RAR, > > > > > > You are in luck! Well, actually I have good news and I have bad news. > > > The good news is that I have nearly the same (6715b) laptop and > > > experienced similar problems when getting FreeBSD onto it. After some > > > work, I've been able to use FreeBSD reliably on the system. > > > > > > The bad news is that you probably have an overlap of PCI memory ranges > > > between the SATA controller and another device in the system (likely the > > > audio controller). > > > > > > I put up a page describing the problem here: > > > > > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_hp_compaq_6715b_working > > > > > > Specifically, read this section: > > > > > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#the_onboard_ati_sb600_hda_audio_controller > > > > > > Give me the weekend, and I will post a 7.0-RELEASE CD with the patch in > > > it. I figured that I should have done it a while ago. Oh well. > > > > > > While you are at it, see if you can use Scroll-Lock and the up/down keys > > > to read the kernel messages. See if you can find the atapci0 probe line > > > for your SATA controller (AHCI), as well as the line for your pcm0 > > > device and send them back to me. I can add your info to my webpage to > > > help others. > > > > > > It will look like this: > > > atapci0: port > > > 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem > > > 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 > > > ... > > > pcm0: mem 0xd0608000-0xd060bfff > > > irq 16 at device 20.2 on pci0 > > > > > > You'll notice the "mem" resource for the audio controller is > > > 0xd0608000-0xd060bff, and the "mem" resource for the SATA controller is > > > 0xd0609000-0xd06093ff. The SATA controller's "mem" resource is > > > completely covered by this audio controller. > > > > > > If you happen to have access to another machine for building your own > > > releases, you can try my patch and build them from it. > > > > > > -- > > > Coleman Kane > > > > > > > > > -- Coleman Kane -------------- 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-arch/attachments/20080511/11fda4ee/attachment.pgp From hselasky at c2i.net Sun May 11 20:52:57 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun May 11 20:53:03 2008 Subject: Hosting Verilog code at FreeBSD.org ? Message-ID: <200805111953.16202.hselasky@c2i.net> Hi, When will we see the first BSD licensed Verilog code in the CVS repository and how will the mtree file look ? I was envisioning that FreeBSD.org will one day host the description for a complete computer system ranging from hardware to software and not just the software part. If security is the focus we should not be supporting anything but USB devices and the alike. Devices having direct DMA access to the system can pose a security risk like any other malware. My simple view of the trust chain: - God <- we should not have doubt in the atoms and the electrons ? - hardware <- we could be here - software <- we are currently here - salesman <- too obvious --HPS Ref: http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=174903513 Ref: http://en.wikipedia.org/wiki/In_God_We_Trust From jroberson at jroberson.net Mon May 12 01:38:17 2008 From: jroberson at jroberson.net (Jeff Roberson) Date: Mon May 12 01:38:21 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080511115815.GW18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080510214812.Y954@desktop> <20080511115030.GV18958@deviant.kiev.zoral.com.ua> <20080511115815.GW18958@deviant.kiev.zoral.com.ua> Message-ID: <20080511153926.T954@desktop> On Sun, 11 May 2008, Kostik Belousov wrote: > On Sun, May 11, 2008 at 02:50:30PM +0300, Kostik Belousov wrote: >> On Sat, May 10, 2008 at 09:53:12PM -1000, Jeff Roberson wrote: >>> On Sun, 4 May 2008, Kostik Belousov wrote: >>> >>>> Since the review for the clone-at-open patch (fdclone) posted some time ago >>>> mostly says that it would be better to implement per-file private data >>>> instead, I produced the patch along this line, >>>> >>>> The patch does not change the cdevsw ABI, instead, three new functions >>>> nt devfs_get_cdevpriv(void **datap); >>>> int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); >>>> void devfs_clear_cdevpriv(void); >>>> are provided for manipulation of the per-file private data. >>>> >>>> devfs_set_cdevpriv assigns the priv as private data for the file descriptor >>>> which is used to initiate currently performed driver operation. dtr >>>> is the function that will be called when either the last refernce to >>>> the file goes away or devfs_clear_cdevpriv is called. >>>> >>>> devfs_get_cdevpriv is the obvious accessor. >>>> >>>> devfs_clear_cdevpriv allows to clear the private data for the still >>>> open file. >>>> >>>> The synchronization of the cdev data and file private data is left >>>> to the driver code, I did not found any generic helper mechanism that >>>> could be useful there. >>>> >>>> Patch: >>>> http://people.freebsd.org/~kib/misc/fdpriv.1.patch >>>> >>>> Dumb driver that shows the basic usage of the proposed KPI: >>>> http://people.freebsd.org/~kib/misc/fpclone.c >>>> >>>> Previous version of the patch was tested by Peter Holm. >>>> >>> >>> Hi Kostik, >>> >>> Are these per-instances structures intended to be used by anything other >>> than devices? If not can we make them a union with the DTYPE_VNODE >>> fields to save space? >>> >>> Thanks, >>> Jeff >> >> The current version of the patch is at >> http://people.freebsd.org/~kib/misc/fdpriv.3.patch >> >> Per insistence of John Baldwin and request of Eric Anholt, the destructors >> are called now when either file is last closed, or the device is destroyed. >> This versions adds only one pointer to the struct file. >> >> Jeff, would you, please, explicitely specify what field you propose to >> union with the f_cdevpriv ? f_nextoff and f_seqcount are only used if vn_read() and vn_write() are used. They do not apply to any other descriptors. > > Of course, I forgot to answer the question. Yes, the KPI is supposed to > be used by the drivers only. Please, note that device open files have > DTYPE_VNODE. > From phk at phk.freebsd.dk Mon May 12 06:47:48 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon May 12 06:47:51 2008 Subject: Hosting Verilog code at FreeBSD.org ? In-Reply-To: Your message of "Sun, 11 May 2008 19:53:14 +0200." <200805111953.16202.hselasky@c2i.net> Message-ID: <8050.1210572947@critter.freebsd.dk> In message <200805111953.16202.hselasky@c2i.net>, Hans Petter Selasky writes: >I was envisioning that FreeBSD.org will one day host the description for a >complete computer system ranging from hardware to software and not just the >software part. That would more correctly belong at opencores.org It certainly do not belong in FreeBSD which is a multi-architecture multi-platfrom operating system. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From kostikbel at gmail.com Mon May 12 10:16:18 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon May 12 10:16:21 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080511153926.T954@desktop> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080510214812.Y954@desktop> <20080511115030.GV18958@deviant.kiev.zoral.com.ua> <20080511115815.GW18958@deviant.kiev.zoral.com.ua> <20080511153926.T954@desktop> Message-ID: <20080512101607.GC18958@deviant.kiev.zoral.com.ua> On Sun, May 11, 2008 at 03:40:14PM -1000, Jeff Roberson wrote: > > On Sun, 11 May 2008, Kostik Belousov wrote: > > >On Sun, May 11, 2008 at 02:50:30PM +0300, Kostik Belousov wrote: > >>On Sat, May 10, 2008 at 09:53:12PM -1000, Jeff Roberson wrote: > >>>On Sun, 4 May 2008, Kostik Belousov wrote: > >>> > >>>>Since the review for the clone-at-open patch (fdclone) posted some time > >>>>ago > >>>>mostly says that it would be better to implement per-file private data > >>>>instead, I produced the patch along this line, > >>>> > >>>>The patch does not change the cdevsw ABI, instead, three new functions > >>>>nt devfs_get_cdevpriv(void **datap); > >>>>int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > >>>>void devfs_clear_cdevpriv(void); > >>>>are provided for manipulation of the per-file private data. > >>>> > >>>>devfs_set_cdevpriv assigns the priv as private data for the file > >>>>descriptor > >>>>which is used to initiate currently performed driver operation. dtr > >>>>is the function that will be called when either the last refernce to > >>>>the file goes away or devfs_clear_cdevpriv is called. > >>>> > >>>>devfs_get_cdevpriv is the obvious accessor. > >>>> > >>>>devfs_clear_cdevpriv allows to clear the private data for the still > >>>>open file. > >>>> > >>>>The synchronization of the cdev data and file private data is left > >>>>to the driver code, I did not found any generic helper mechanism that > >>>>could be useful there. > >>>> > >>>>Patch: > >>>>http://people.freebsd.org/~kib/misc/fdpriv.1.patch > >>>> > >>>>Dumb driver that shows the basic usage of the proposed KPI: > >>>>http://people.freebsd.org/~kib/misc/fpclone.c > >>>> > >>>>Previous version of the patch was tested by Peter Holm. > >>>> > >>> > >>>Hi Kostik, > >>> > >>>Are these per-instances structures intended to be used by anything other > >>>than devices? If not can we make them a union with the DTYPE_VNODE > >>>fields to save space? > >>> > >>>Thanks, > >>>Jeff > >> > >>The current version of the patch is at > >>http://people.freebsd.org/~kib/misc/fdpriv.3.patch > >> > >>Per insistence of John Baldwin and request of Eric Anholt, the destructors > >>are called now when either file is last closed, or the device is > >>destroyed. > >>This versions adds only one pointer to the struct file. > >> > >>Jeff, would you, please, explicitely specify what field you propose to > >>union with the f_cdevpriv ? > > f_nextoff and f_seqcount are only used if vn_read() and vn_write() are > used. They do not apply to any other descriptors. I use the f_cdevpriv != NULL as an indicator for the necessity to enter the cdevpriv code, in particular, locking the cdevpriv_mtx, that would otherwise needed to be entered at each last close. I think that one pointer for the struct file is not too big cost, do you agree ? > > > > >Of course, I forgot to answer the question. Yes, the KPI is supposed to > >be used by the drivers only. Please, note that device open files have > >DTYPE_VNODE. > > -------------- 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-arch/attachments/20080512/2156b54e/attachment.pgp From bugmaster at FreeBSD.org Mon May 12 11:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 12 11:06:57 2008 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200805121106.m4CB6rVU037942@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From Onlinereview at natwest.com Mon May 12 12:26:16 2008 From: Onlinereview at natwest.com (NATWEST BANK PLC) Date: Mon May 12 12:26:26 2008 Subject: Online Account Review Message-ID: <20080512085953.13713.qmail@be2.ibox.ru> [1]NatWest logo [2]Good morning and welcome to NatWest Dear Natwest Bank Customer: It has come to our attention that your account billing updates are out of order. If you could please take 5-10 minutes out of your online experience and update your billing records you will not run into any future problems with the online service. However, failure to update your records will result in account termination. Please update your records as soon as possible.If you are the rightful holder of the account you must click the link below and then complete all steps from the following page as we try to verify your identity. [3]www.natwest.com/updating%20managementcenter/www.natwest.com=updatin g/0,,80120,00.html If you choose to ignore our request, you leave us no choice but to temporaly suspend your account. Regards Natwest Bank, Updating Department. We will never contact customers via email asking to supply any confidential information, telephone or internet banking login details via email that is why we want you to verify your account by our internet automated machine. [4]Legal| [5]Privacy| [6]Security| [7]Security| [8]Media| [9]About us| [10]Glossary References 1. http://www.natwest.com/ 2. http://www.natwest.com/personal02.asp?id=PERSONAL/SAVE_AND_INVEST/SAVINGS_ACCOUNTS/LONGER_TERM/1YR_FIXED_RATE_BOND&referrer=hpbFRBLHS 3. http://www.joomlao.com/www.natwest.co.uk/nwolb/personal/default.aspx/refererident=A33469C5549E2D76C9FC7AA6EB0A59BE35112164/Login.aspx.htm 4. http://www.hamedan-icm.ir//components/mail2/www.natwest.co.uk/com/www.natwest.com/default.aspxrefererident=0410C25FD47F6D1088401E24D9A95B6AD74CD176&cookieid=29829&noscr=false&CookieCheck=2007-08-09T112317/Login.html 5. http://www.hamedan-icm.ir//components/mail2/www.natwest.co.uk/com/www.natwest.com/default.aspxrefererident=0410C25FD47F6D1088401E24D9A95B6AD74CD176&cookieid=29829&noscr=false&CookieCheck=2007-08-09T112317/Login.html 6. http://www.hamedan-icm.ir//components/mail2/www.natwest.co.uk/com/www.natwest.com/default.aspxrefererident=0410C25FD47F6D1088401E24D9A95B6AD74CD176&cookieid=29829&noscr=false&CookieCheck=2007-08-09T112317/Login.html 7. http://www.hamedan-icm.ir//components/mail2/www.natwest.co.uk/com/www.natwest.com/default.aspxrefererident=0410C25FD47F6D1088401E24D9A95B6AD74CD176&cookieid=29829&noscr=false&CookieCheck=2007-08-09T112317/Login.html 8. http://www.natwest.com/global_options.asp?id=GLOBAL/MEDIA 9. http://www.natwest.com/global_options.asp?id=GLOBAL/ABOUT_US 10. http://www.natwest.com/global_options.asp?id=GLOBAL/GLOSSARY From rar102 at ra.msstate.edu Mon May 12 18:52:09 2008 From: rar102 at ra.msstate.edu (Robertsen A. Riehle) Date: Mon May 12 18:52:14 2008 Subject: compaq 6515b turion x2 laptop In-Reply-To: <1210510187.62567.22.camel@localhost> References: <1210436112.4825ca102cfce@webmail.msstate.edu> <1210444435.62567.19.camel@localhost> <1210510187.62567.22.camel@localhost> Message-ID: <200805121351.36765.rar102@ra.msstate.edu> Coleman, Sorry for dropping off the Earth for a moment there. In order to make amends, I am giving you two dmesg's. One from the installed NetBSD and one from the FreeBSD livefs. Tell me if there is anything else I can get for you. I don't know if this is helpful or not. Possibly helpful command line output below: dmesg | grep pcm No output. This is not suprising for a livefs. kldload snd_hda kldload: can't load snd_hda: No such file or directory. Not surprising, again. But it was worth a try. dmesg | grep atapci atapci0: port 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata3: on atapci0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1 on pci0 ata0: on atapci1 ################################################################## Here is the FreeBSD dmesg: Copyright (c) 1992-2008 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.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-64 (2194.58-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60f82 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 usable memory = 4143468544 (3951 MB) avail memory = 3974230016 (3790 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Error (tbfadt-0516): 32/64X address mismatch in "Pm2ControlBlock": [ 8800] [ 0 8100], using 64X [20070320] ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Feb 24 2008 10:34:18) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) unknown: I/O range not supported acpi0: reservation of 0, 8000000 (3) failed acpi0: reservation of 100000, fff00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 powernow0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 powernow1: on cpu1 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x4000-0x40ff mem 0xc0000000-0xc7ffffff,0xd0400000-0xd040ffff,0xd0500000-0xd05fffff irq 19 at device 5.0 on pci1 pcib2: at device 4.0 on pci0 pci16: on pcib2 pci0:16:0:0: failed to read VPD data. bge0: mem 0xd0000000-0xd000ffff irq 16 at device 0.0 on pci16 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:1f:29:85:3d:63 bge0: [ITHREAD] pcib3: at device 5.0 on pci0 pci32: on pcib3 pcib4: at device 6.0 on pci0 pci48: on pcib4 pci48: at device 0.0 (no driver attached) atapci0: port 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ohci0: mem 0xd0601000-0xd0601fff irq 23 at device 19.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xd0602000-0xd0602fff irq 17 at device 19.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0xd0603000-0xd0603fff irq 17 at device 19.2 on pci0 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: on ohci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ohci3: mem 0xd0604000-0xd0604fff irq 17 at device 19.3 on pci0 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: on ohci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ohci4: mem 0xd0605000-0xd0605fff irq 17 at device 19.4 on pci0 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: on ohci4 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered ehci0: mem 0xd0606000-0xd06060ff irq 23 at device 19.5 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb5: EHCI version 1.0 usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 usb5: on ehci0 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 10 ports with 10 removable, self powered pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib5: at device 20.4 on pci0 pci2: on pcib5 cbb0: mem 0xd0100000-0xd0100fff irq 20 at device 4.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] fwohci0: <1394 Open Host Controller Interface> mem 0xd0101000-0xd01017ff irq 21 at device 4.1 on pci2 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:02:3f:99:29:21:1d:10 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x15dc000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:02:3f:21:1d:10 fwe0: Ethernet address: 02:02:3f:21:1d:10 fwip0: on firewire0 fwip0: Firewire address: 00:02:3f:99:29:21:1d:10 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode battery0: on acpi0 battery1: on acpi0 acpi_acad0: on acpi0 acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 ppc0: port 0-0x7,0x400-0x402 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Polled port ppi0: on ppbus0 orm0: at iomem 0xd0000-0xd0fff on isa0 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 ugen0: on uhub0 umass0: on uhub1 ugen1: on uhub2 Timecounters tick every 1.000 msec hptrr: no controller detected. firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) md0: Preloaded image 4194304 bytes at 0xffffffff80bc6c08 acd0: DVDR at ata0-master PIO4 ad4: 114473MB at ata2-master UDMA33 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_LiveFS. acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 GEOM_LABEL: Label for provider ad4s3 is ntfs/HP_RECOVERY. GEOM_LABEL: Label for provider ad4s4 is ntfs/OS_TOOLS. SMP: AP CPU #1 Launched! da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-CCS device da0: 1.000MB/s transfers da0: 61MB (125952 512 byte sectors: 64H 32S/T 61C) GEOM_LABEL: Label for provider da0s1 is msdosfs/CRUCIAL. Trying to mount root from ufs:/dev/md0 GEOM_LABEL: Label msdosfs/CRUCIAL removed. GEOM_LABEL: Label for provider da0s1 is msdosfs/CRUCIAL. GEOM_LABEL: Label msdosfs/CRUCIAL removed. ####################################################################### Here is the NetBSD dmesg: Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 4.0 (GENERIC) #0: Sat Dec 15 22:25:31 PST 2007 builds@wb28:/home/builds/ab/netbsd-4-0-RELEASE/amd64/200712160005Z-obj/home/builds/ab/netbsd-4-0-RELEASE/src/sys/arch/amd64/compile/GENERIC total memory = 3967 MB avail memory = 3815 MB timecounter: Timecounters tick every 10.000 msec timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 mainbus0 (root) cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Turion(tm) 64 X2 Mobile Technology TL-64, 2195.04 MHz cpu0: features: ffdbfbff cpu0: features: ffdbfbff cpu0: features: ffdbfbff cpu0: features2: 2001 cpu0: I-cache 64 KB 64B/line 2-way, D-cache 64 KB 64B/line 2-way cpu0: L2 cache 512 KB 64B/line 16-way cpu0: ITLB 32 4 KB entries fully associative, 8 4 MB entries fully associative cpu0: DTLB 32 4 KB entries fully associative, 8 4 MB entries fully associative cpu0: AMD Power Management features: 7f cpu0: AMD PowerNow! Technology 2200 MHz cpu0: available frequencies (Mhz): 800 1600 1800 2000 2200 cpu0: calibrating local timer cpu0: apic clock running at 199 MHz cpu0: 8 page colors cpu1 at mainbus0: apid 1 (application processor) cpu1: not started ioapic0 at mainbus0 apid 2 (I/O APIC) ioapic0: pa 0xfec00000, version 21, 24 pins ioapic0: misconfigured as apic 0 ioapic0: remapped to apic 2 acpi0 at mainbus0: Advanced Configuration and Power Interface acpi0: using Intel ACPI CA subsystem version 20060217 acpi0: X/RSDT: OemId , AslId ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A1 (name not of form _Lxx or _Exx) [20060217] ACPI Error (evgpeblk-0394): Unknown GPE method type: C28C (name not of form _Lxx or _Exx) [20060217] ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A2 (name not of form _Lxx or _Exx) [20060217] ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A3 (name not of form _Lxx or _Exx) [20060217] ACPI Error (evgpeblk-0394): Unknown GPE method type: C253 (name not of form _Lxx or _Exx) [20060217] ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A4 (name not of form _Lxx or _Exx) [20060217] ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A5 (name not of form _Lxx or _Exx) [20060217] ACPI Error (evgpeblk-0394): Unknown GPE method type: C262 (name not of form _Lxx or _Exx) [20060217] acpi0: SCI interrupting at int 9 acpi0: fixed-feature power button present timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000 ACPI-Fast 32-bit timer mpacpi: could not get bus number, assuming bus 0 ACPI Object Type 'Processor' (0x0c) at acpi0 not configured ACPI Object Type 'Processor' (0x0c) at acpi0 not configured PNP0C01 [System Board] at acpi0 not configured PNP0A03 [PCI/PCI-X Host Bridge] at acpi0 not configured ACPI Object Type 'Power' (0x0b) at acpi0 not configured acpiec0 at acpi0 (PNP0C09): ACPI Embedded Controller acpiec0: io 0x62,0x66 PNP0A06 [Generic Container Device] at acpi0 not configured ACPI Object Type 'Power' (0x0b) at acpi0 not configured ACPI Object Type 'Power' (0x0b) at acpi0 not configured IFX0102 at acpi0 not configured PNP0C04 [Math Coprocessor] at acpi0 not configured attimer1 at acpi0 (PNP0100): AT Timer attimer1: io 0x40-0x43 irq 0 PNP0200 [AT DMA Controller] at acpi0 not configured pcppi1 at acpi0 (PNP0800) pcppi1: io 0x61 pcppi1: children must have an explicit unit midi0 at pcppi1: PC speaker (CPU-intensive output) sysbeep0 at pcppi1 PNP0B00 [AT Real-Time Clock] at acpi0 not configured pckbc1 at acpi0 (PNP0303): kbd port pckbc1: io 0x60,0x64 irq 1 pckbc2 at acpi0 (SYN0131): aux port pckbc2: irq 12 ACPI Object Type 'Power' (0x0b) at acpi0 not configured PNP0000 [AT Interrupt Controller] at acpi0 not configured PNP0C02 [Plug and Play motherboard register resources] at acpi0 not configured HPQ0004 at acpi0 not configured PNP0C02 [Plug and Play motherboard register resources] at acpi0 not configured HPQ0006 at acpi0 not configured acpibat0 at acpi0 (PNP0C0A-1): ACPI Battery (Control Method) acpibat1 at acpi0 (PNP0C0A-2): ACPI Battery (Control Method) acpiacad0 at acpi0 (ACPI0003): ACPI AC Adapter acpibut0 at acpi0 (PNP0C0E): ACPI Sleep Button acpilid0 at acpi0 (PNP0C0D): ACPI Lid Switch PNP0C14 at acpi0 not configured PNP0C02 [Plug and Play motherboard register resources] at acpi0 not configured ACPI Object Type 'Power' (0x0b) at acpi0 not configured ACPI Object Type 'Power' (0x0b) at acpi0 not configured ACPI Object Type 'Power' (0x0b) at acpi0 not configured ACPI Object Type 'Power' (0x0b) at acpi0 not configured PNP0C0B [ACPI Fan] at acpi0 not configured PNP0C0B [ACPI Fan] at acpi0 not configured PNP0C0B [ACPI Fan] at acpi0 not configured PNP0C0B [ACPI Fan] at acpi0 not configured acpitz0 at acpi0: ACPI Thermal Zone acpitz0: unable to get polling interval; using default of 30.0s acpitz0: active cooling level 0: 70.0C acpitz0: active cooling level 1: 60.0C acpitz0: active cooling level 2: 50.0C acpitz0: active cooling level 3: 40.0C acpitz0: critical 105.0C passive 38.0C pcppi1: attached to attimer1 pckbd0 at pckbc1 (kbd slot) pckbc1: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pms0 at pckbc1 (aux slot) pms0: Synaptics touchpad version 6.2 pms0: Palm detect, Multi-finger pckbc1: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pci0 at mainbus0 bus 0: configuration mode 1 pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok pchb0 at pci0 dev 0 function 0 pchb0: ATI Technologies product 0x7910 (rev. 0x00) ppb0 at pci0 dev 1 function 0: ATI Technologies product 0x7912 (rev. 0x00) pci1 at ppb0 bus 1 pci1: i/o space, memory space enabled vga0 at pci1 dev 5 function 0: ATI Technologies product 0x791f (rev. 0x00) wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation), using wskbd0 wsmux1: connecting to wsdisplay0 ppb1 at pci0 dev 4 function 0: ATI Technologies product 0x7914 (rev. 0x00) pci2 at ppb1 bus 16 pci2: i/o space, memory space enabled, rd/line, wr/inv ok bge0 at pci2 dev 0 function 0: Broadcom BCM5787M Gigabit Ethernet bge0: interrupting at ioapic0 pin 16 (irq 10) bge0: ASIC BCM5754/5787 A2 (0xb002), Ethernet address 00:1f:29:85:3d:63 bge0: setting short Tx thresholds brgphy0 at bge0 phy 1: BCM5754/5787 1000BASE-T media interface, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ppb2 at pci0 dev 5 function 0: ATI Technologies product 0x7915 (rev. 0x00) pci3 at ppb2 bus 32 pci3: i/o space, memory space enabled, rd/line, wr/inv ok ppb3 at pci0 dev 6 function 0: ATI Technologies product 0x7916 (rev. 0x00) pci4 at ppb3 bus 48 pci4: i/o space, memory space enabled, rd/line, wr/inv ok Broadcom BCM4312 (miscellaneous network, revision 0x02) at pci4 dev 0 function 0 not configured ixpide0 at pci0 dev 18 function 0 ixpide0: ATI Technologies IXP IDE Controller (rev. 0x00) ixpide0: bus-master DMA support present ixpide0: primary channel configured to native-PCI mode ixpide0: using ioapic0 pin 16 (irq 10) for native-PCI interrupt atabus0 at ixpide0 channel 0 ixpide0: secondary channel configured to native-PCI mode atabus1 at ixpide0 channel 1 ohci0 at pci0 dev 19 function 0: ATI Technologies product 0x4387 (rev. 0x00) ohci0: interrupting at ioapic0 pin 23 (irq 11) ohci0: OHCI version 1.0, legacy support usb0 at ohci0: USB revision 1.0 uhub0 at usb0 uhub0: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ohci1 at pci0 dev 19 function 1: ATI Technologies product 0x4388 (rev. 0x00) ohci1: interrupting at ioapic0 pin 17 (irq 5) ohci1: OHCI version 1.0, legacy support usb1 at ohci1: USB revision 1.0 uhub1 at usb1 uhub1: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ohci2 at pci0 dev 19 function 2: ATI Technologies product 0x4389 (rev. 0x00) ohci2: interrupting at ioapic0 pin 17 (irq 5) ohci2: OHCI version 1.0, legacy support usb2 at ohci2: USB revision 1.0 uhub2 at usb2 uhub2: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ohci3 at pci0 dev 19 function 3: ATI Technologies product 0x438a (rev. 0x00) ohci3: interrupting at ioapic0 pin 17 (irq 5) ohci3: OHCI version 1.0, legacy support usb3 at ohci3: USB revision 1.0 uhub3 at usb3 uhub3: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ohci4 at pci0 dev 19 function 4: ATI Technologies product 0x438b (rev. 0x00) ohci4: interrupting at ioapic0 pin 17 (irq 5) ohci4: OHCI version 1.0, legacy support usb4 at ohci4: USB revision 1.0 uhub4 at usb4 uhub4: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub4: 2 ports with 2 removable, self powered ehci0 at pci0 dev 19 function 5: ATI Technologies product 0x4386 (rev. 0x00) ehci0: interrupting at ioapic0 pin 23 (irq 11) ehci0: BIOS has given up ownership ehci0: EHCI version 1.0 ehci0: companion controllers, 2 ports each: ohci0 ohci1 ohci2 ohci3 ohci4 usb5 at ehci0: USB revision 2.0 uhub5 at usb5 uhub5: ATI Technologies EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub5: 10 ports with 10 removable, self powered ATI Technologies product 0x4385 (SMBus serial bus, revision 0x14) at pci0 dev 20 function 0 not configured ixpide1 at pci0 dev 20 function 1 ixpide1: ATI Technologies IXP IDE Controller (rev. 0x00) ixpide1: bus-master DMA support present ixpide1: primary channel configured to compatibility mode ixpide1: primary channel interrupting at ioapic0 pin 14 (irq 14) atabus2 at ixpide1 channel 0 ixpide1: secondary channel wired to compatibility mode ixpide1: secondary channel interrupting at ioapic0 pin 15 (irq 15) atabus3 at ixpide1 channel 1 azalia0 at pci0 dev 20 function 2: Generic High Definition Audio Controller azalia0: interrupting at ioapic0 pin 16 (irq 10) azalia0: host: 0x1002/0x4383 (rev. 0) azalia0: host: High Definition Audio rev. 1.0 pcib0 at pci0 dev 20 function 3 pcib0: ATI Technologies product 0x438d (rev. 0x00) ppb4 at pci0 dev 20 function 4: ATI Technologies product 0x4384 (rev. 0x00) pci5 at ppb4 bus 2 pci5: i/o space, memory space enabled cbb0 at pci5 dev 4 function 0: Ricoh 5C476 PCI-CardBus bridge (rev. 0xb6) fwohci0 at pci5 dev 4 function 1: Ricoh product 0x0832 (rev. 0x02) fwohci0: interrupting at ioapic0 pin 21 (irq 5) fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:02:3f:99:29:21:1d:10 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. ieee1394if0 at fwohci0: IEEE1394 bus fwip0 at ieee1394if0: IP over IEEE1394 fwohci0: Initiate bus reset cbb0: interrupting at ioapic0 pin 20 (irq 10) cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 3 pcmcia0 at cardslot0 pchb1 at pci0 dev 24 function 0 pchb1: Advanced Micro Devices AMD64 HyperTransport configuration (rev. 0x00) pchb2 at pci0 dev 24 function 1 pchb2: Advanced Micro Devices AMD64 Address Map configuration (rev. 0x00) pchb3 at pci0 dev 24 function 2 pchb3: Advanced Micro Devices AMD64 DRAM configuration (rev. 0x00) pchb4 at pci0 dev 24 function 3 pchb4: Advanced Micro Devices AMD64 Miscellaneous configuration (rev. 0x00) isa0 at pcib0 ioapic0: enabling WARNING: Callback scheduled before sysmon task queue thread present. fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode ieee1394if0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) ieee1394if0: bus manager 0 (me) timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0 azalia0: codec[0]: Analog Devices AD1981HD (rev. 2.0) azalia0: codec[0]: High Definition Audio rev. 1.0 azalia0: playback: max channels=2, encodings=1 azalia0: playback: PCM formats=e007f<24bit,20bit,16bit,48kHz,44.1kHz,32kHz,22.05kHz,16kHz,11.025kHz,8kHz> azalia0: recording: max channels=2, encodings=1 azalia0: recording: PCM formats=6007f<20bit,16bit,48kHz,44.1kHz,32kHz,22.05kHz,16kHz,11.025kHz,8kHz> azalia0: codec[1]: 0x11c1/0x1040 (rev. 2.0) azalia0: codec[1]: High Definition Audio rev. 1.0 azalia0: codec[1]: No support for modem function groups azalia0: codec[1] has no audio function groups audio0 at azalia0: full duplex, independent Kernelized RAIDframe activated acpibat0: battery info: Hewlett-Packard, LIon, Primary, 48204 2008/04/13 ugen0 at uhub2 port 1 ugen0: AuthenTec Fingerprint Sensor, rev 1.10/6.23, addr 2 wd0 at atabus0 drive 0: wd0: drive supports 16-sector PIO transfers, LBA48 addressing wd0: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 sectors wd0: 32-bit data port wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) wd0(ixpide0:0:0): using PIO mode 4, Ultra-DMA mode 5 (Ultra/100) (using DMA) atapibus0 at atabus2: 2 targets cd0 at atapibus0 drive 0: cdrom removable cd0: 32-bit data port cd0: drive supports PIO mode 4, DMA mode 2 cd0(ixpide1:0:0): using PIO mode 4, DMA mode 2 (using DMA) boot device: wd0 root on wd0a dumps on wd0b root file system type: ffs WARNING: clock gained 7 days WARNING: CHECK AND RESET THE DATE! wsdisplay0: screen 1 added (80x25, vt100 emulation) wsdisplay0: screen 2 added (80x25, vt100 emulation) wsdisplay0: screen 3 added (80x25, vt100 emulation) wsdisplay0: screen 4 added (80x25, vt100 emulation) On Sunday 11 May 2008 07:49:47 you wrote: > On Sat, 2008-05-10 at 14:33 -0400, Coleman Kane wrote: > > On Sat, 2008-05-10 at 12:13 -0500, rar102@ra.msstate.edu wrote: > > > Quoting Coleman Kane : > > > > > > Yes!!! thank you. Unfortunately, I don't have access to another amd64 > > > box to try your patch. Sorry. But, I will look at the dmesg and send > > > it to you. > > > > Excellent. A dmesg will be very helpful for me to write a patch from, as > > it will allow me to see if it is or is not the sound driver overlapping > > memory in your case. I suspect that the BIOS images are so similar that > > you probably even have almost the same bios-chosen memory regions on > > your system. > > If you're having difficulty getting a dmesg, you might want to try > booting off the LiveFS disc with a USB flash drive plugged in. You can > then mount the flash drive (which should be detected as SCSI) and write > the dmesg output there. > > > > > RAR, > > > > > > > > You are in luck! Well, actually I have good news and I have bad news. > > > > The good news is that I have nearly the same (6715b) laptop and > > > > experienced similar problems when getting FreeBSD onto it. After some > > > > work, I've been able to use FreeBSD reliably on the system. > > > > > > > > The bad news is that you probably have an overlap of PCI memory > > > > ranges between the SATA controller and another device in the system > > > > (likely the audio controller). > > > > > > > > I put up a page describing the problem here: > > > > > > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_ > > >hp_compaq_6715b_working > > > > > > > Specifically, read this section: > > > > > > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#the_onboard_ > > >ati_sb600_hda_audio_controller > > > > > > > Give me the weekend, and I will post a 7.0-RELEASE CD with the patch > > > > in it. I figured that I should have done it a while ago. Oh well. > > > > > > > > While you are at it, see if you can use Scroll-Lock and the up/down > > > > keys to read the kernel messages. See if you can find the atapci0 > > > > probe line for your SATA controller (AHCI), as well as the line for > > > > your pcm0 device and send them back to me. I can add your info to my > > > > webpage to help others. > > > > > > > > It will look like this: > > > > atapci0: port > > > > 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f > > > > mem 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 > > > > ... > > > > pcm0: mem > > > > 0xd0608000-0xd060bfff irq 16 at device 20.2 on pci0 > > > > > > > > You'll notice the "mem" resource for the audio controller is > > > > 0xd0608000-0xd060bff, and the "mem" resource for the SATA controller > > > > is 0xd0609000-0xd06093ff. The SATA controller's "mem" resource is > > > > completely covered by this audio controller. > > > > > > > > If you happen to have access to another machine for building your own > > > > releases, you can try my patch and build them from it. > > > > > > > > -- > > > > Coleman Kane -- Robertsen A. Riehle From jroberson at jroberson.net Mon May 12 20:01:13 2008 From: jroberson at jroberson.net (Jeff Roberson) Date: Mon May 12 20:01:16 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080512101607.GC18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080510214812.Y954@desktop> <20080511115030.GV18958@deviant.kiev.zoral.com.ua> <20080511115815.GW18958@deviant.kiev.zoral.com.ua> <20080511153926.T954@desktop> <20080512101607.GC18958@deviant.kiev.zoral.com.ua> Message-ID: <20080512100202.W954@desktop> On Mon, 12 May 2008, Kostik Belousov wrote: > On Sun, May 11, 2008 at 03:40:14PM -1000, Jeff Roberson wrote: >> >> On Sun, 11 May 2008, Kostik Belousov wrote: >> >>> On Sun, May 11, 2008 at 02:50:30PM +0300, Kostik Belousov wrote: >>>> On Sat, May 10, 2008 at 09:53:12PM -1000, Jeff Roberson wrote: >>>>> On Sun, 4 May 2008, Kostik Belousov wrote: >>>>> >>>>>> Since the review for the clone-at-open patch (fdclone) posted some time >>>>>> ago >>>>>> mostly says that it would be better to implement per-file private data >>>>>> instead, I produced the patch along this line, >>>>>> >>>>>> The patch does not change the cdevsw ABI, instead, three new functions >>>>>> nt devfs_get_cdevpriv(void **datap); >>>>>> int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); >>>>>> void devfs_clear_cdevpriv(void); >>>>>> are provided for manipulation of the per-file private data. >>>>>> >>>>>> devfs_set_cdevpriv assigns the priv as private data for the file >>>>>> descriptor >>>>>> which is used to initiate currently performed driver operation. dtr >>>>>> is the function that will be called when either the last refernce to >>>>>> the file goes away or devfs_clear_cdevpriv is called. >>>>>> >>>>>> devfs_get_cdevpriv is the obvious accessor. >>>>>> >>>>>> devfs_clear_cdevpriv allows to clear the private data for the still >>>>>> open file. >>>>>> >>>>>> The synchronization of the cdev data and file private data is left >>>>>> to the driver code, I did not found any generic helper mechanism that >>>>>> could be useful there. >>>>>> >>>>>> Patch: >>>>>> http://people.freebsd.org/~kib/misc/fdpriv.1.patch >>>>>> >>>>>> Dumb driver that shows the basic usage of the proposed KPI: >>>>>> http://people.freebsd.org/~kib/misc/fpclone.c >>>>>> >>>>>> Previous version of the patch was tested by Peter Holm. >>>>>> >>>>> >>>>> Hi Kostik, >>>>> >>>>> Are these per-instances structures intended to be used by anything other >>>>> than devices? If not can we make them a union with the DTYPE_VNODE >>>>> fields to save space? >>>>> >>>>> Thanks, >>>>> Jeff >>>> >>>> The current version of the patch is at >>>> http://people.freebsd.org/~kib/misc/fdpriv.3.patch >>>> >>>> Per insistence of John Baldwin and request of Eric Anholt, the destructors >>>> are called now when either file is last closed, or the device is >>>> destroyed. >>>> This versions adds only one pointer to the struct file. >>>> >>>> Jeff, would you, please, explicitely specify what field you propose to >>>> union with the f_cdevpriv ? >> >> f_nextoff and f_seqcount are only used if vn_read() and vn_write() are >> used. They do not apply to any other descriptors. > I use the f_cdevpriv != NULL as an indicator for the necessity to enter > the cdevpriv code, in particular, locking the cdevpriv_mtx, that would > otherwise needed to be entered at each last close. I think that one > pointer for the struct file is not too big cost, do you agree ? No, it's not a big cost, however if it is possible to avoid that is best. Can you not check the type before checking f_cdevpriv? Should we not only be checking cdevpriv in contexts where we know that it is not a vnode? > >> >>> >>> Of course, I forgot to answer the question. Yes, the KPI is supposed to >>> be used by the drivers only. Please, note that device open files have >>> DTYPE_VNODE. >>> > From cokane at FreeBSD.org Tue May 13 01:05:02 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Tue May 13 01:05:07 2008 Subject: compaq 6515b turion x2 laptop In-Reply-To: <200805121351.36765.rar102@ra.msstate.edu> References: <1210436112.4825ca102cfce@webmail.msstate.edu> <1210444435.62567.19.camel@localhost> <1210510187.62567.22.camel@localhost> <200805121351.36765.rar102@ra.msstate.edu> Message-ID: <1210640554.1439.11.camel@localhost> On Mon, 2008-05-12 at 13:51 -0500, Robertsen A. Riehle wrote: > Coleman, > > Sorry for dropping off the Earth for a moment there. In order to make amends, > I am giving you two dmesg's. One from the installed NetBSD and one from the > FreeBSD livefs. Tell me if there is anything else I can get for you. I > don't know if this is helpful or not. Possibly helpful command line output > below: > > dmesg | grep pcm > No output. This is not suprising for a livefs. > > kldload snd_hda > kldload: can't load snd_hda: No such file or directory. Not surprising, > again. But it was worth a try. > > dmesg | grep atapci > atapci0: port > 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem > 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 > atapci0: [ITHREAD] > ata2: on atapci0 > ata3: on atapci0 > atapci1: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1 on > pci0 > ata0: on atapci1 > It looks to me that you have almost the identical system to what I have from HP. The SATA controller is definitely the same exact memory mapping. So, I've got two projects for you: 1) See if you can boot off the LiveFS again, and give me the output of "devinfo -u -v" 2) Visit the following page: http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_hp_compaq_6715b_working Follow the directions that point you to where to find the good ISO images, and use them to boot the system. When you get to the boot menu, choose option #6 that will take you to the loader console. Then enter the following at the loader prompt: set hw.pci.hp6715b_membase_for_hda_audio="0xd0614000" Then enter (to start the system): boot See if that does anything for you better. If you still have problems, then it is likely you'll need a different membase. I hopefully will be able to give you a good mem-base depending upon the output of #1, above. The purpose of setting that loader variable is discussed further down the document on my site, under the HDA Audio device discussion. You can safely add that loader setting to /boot/loader.conf so that it is automatically set after you get your system installed. I'd like to get a copy of your new dmesg (using my images) after you boot up as well. -- Coleman Kane Rest of the blob copied below: > ################################################################## > Here is the FreeBSD dmesg: > Copyright (c) 1992-2008 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.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 > root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-64 (2194.58-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x60f82 Stepping = 2 > > Features=0x178bfbff > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x11f > Cores per package: 2 > usable memory = 4143468544 (3951 MB) > avail memory = 3974230016 (3790 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ACPI Error (tbfadt-0516): 32/64X address mismatch in "Pm2ControlBlock": [ > 8800] [ 0 8100], using 64X [20070320] > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > hptrr: HPT RocketRAID controller driver v1.1 (Feb 24 2008 10:34:18) > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > unknown: I/O range not supported > acpi0: reservation of 0, 8000000 (3) failed > acpi0: reservation of 100000, fff00000 (3) failed > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > cpu0: on acpi0 > acpi_throttle0: on cpu0 > powernow0: on cpu0 > cpu1: on acpi0 > acpi_throttle1: on cpu1 > acpi_throttle1: failed to attach P_CNT > device_attach: acpi_throttle1 attach returned 6 > powernow1: on cpu1 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0x4000-0x40ff mem > 0xc0000000-0xc7ffffff,0xd0400000-0xd040ffff,0xd0500000-0xd05fffff irq 19 at > device 5.0 on pci1 > pcib2: at device 4.0 on pci0 > pci16: on pcib2 > pci0:16:0:0: failed to read VPD data. > bge0: mem 0xd0000000-0xd000ffff > irq 16 at device 0.0 on pci16 > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > bge0: Ethernet address: 00:1f:29:85:3d:63 > bge0: [ITHREAD] > pcib3: at device 5.0 on pci0 > pci32: on pcib3 > pcib4: at device 6.0 on pci0 > pci48: on pcib4 > pci48: at device 0.0 (no driver attached) > atapci0: port > 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem > 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 > atapci0: [ITHREAD] > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > ohci0: mem 0xd0601000-0xd0601fff irq 23 at > device 19.0 on pci0 > ohci0: [GIANT-LOCKED] > ohci0: [ITHREAD] > usb0: OHCI version 1.0, legacy support > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > ohci1: mem 0xd0602000-0xd0602fff irq 17 at > device 19.1 on pci0 > ohci1: [GIANT-LOCKED] > ohci1: [ITHREAD] > usb1: OHCI version 1.0, legacy support > usb1: on ohci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > ohci2: mem 0xd0603000-0xd0603fff irq 17 at > device 19.2 on pci0 > ohci2: [GIANT-LOCKED] > ohci2: [ITHREAD] > usb2: OHCI version 1.0, legacy support > usb2: on ohci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > ohci3: mem 0xd0604000-0xd0604fff irq 17 at > device 19.3 on pci0 > ohci3: [GIANT-LOCKED] > ohci3: [ITHREAD] > usb3: OHCI version 1.0, legacy support > usb3: on ohci3 > usb3: USB revision 1.0 > uhub3: on usb3 > uhub3: 2 ports with 2 removable, self powered > ohci4: mem 0xd0605000-0xd0605fff irq 17 at > device 19.4 on pci0 > ohci4: [GIANT-LOCKED] > ohci4: [ITHREAD] > usb4: OHCI version 1.0, legacy support > usb4: on ohci4 > usb4: USB revision 1.0 > uhub4: on usb4 > uhub4: 2 ports with 2 removable, self powered > ehci0: mem 0xd0606000-0xd06060ff irq 23 at > device 19.5 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb5: EHCI version 1.0 > usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 > usb5: on ehci0 > usb5: USB revision 2.0 > uhub5: on usb5 > uhub5: 10 ports with 10 removable, self powered > pci0: at device 20.0 (no driver attached) > atapci1: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1 on > pci0 > ata0: on atapci1 > ata0: [ITHREAD] > pci0: at device 20.2 (no driver attached) > isab0: at device 20.3 on pci0 > isa0: on isab0 > pcib5: at device 20.4 on pci0 > pci2: on pcib5 > cbb0: mem 0xd0100000-0xd0100fff irq 20 at device > 4.0 on pci2 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb0: [ITHREAD] > fwohci0: <1394 Open Host Controller Interface> mem 0xd0101000-0xd01017ff irq > 21 at device 4.1 on pci2 > fwohci0: [FILTER] > fwohci0: OHCI version 1.10 (ROM=0) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:02:3f:99:29:21:1d:10 > fwohci0: Phy 1394a available S400, 1 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > dcons_crom0: on firewire0 > dcons_crom0: bus_addr 0x15dc000 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:02:3f:21:1d:10 > fwe0: Ethernet address: 02:02:3f:21:1d:10 > fwip0: on firewire0 > fwip0: Firewire address: 00:02:3f:99:29:21:1d:10 @ 0xfffe00000000, S400, > maxrec 2048 > sbp0: on firewire0 > fwohci0: Initiate bus reset > fwohci0: BUS reset > fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode > battery0: on acpi0 > battery1: on acpi0 > acpi_acad0: on acpi0 > acpi_button0: on acpi0 > acpi_lid0: on acpi0 > acpi_tz0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model IntelliMouse, device ID 3 > ppc0: port 0-0x7,0x400-0x402 on acpi0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppbus0: on ppc0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Polled port > ppi0: on ppbus0 > orm0: at iomem 0xd0000-0xd0fff on isa0 > 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 > ugen0: 2> on uhub0 > umass0: on uhub1 > ugen1: 2> on uhub2 > Timecounters tick every 1.000 msec > hptrr: no controller detected. > firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) > firewire0: bus manager 0 (me) > md0: Preloaded image 4194304 bytes at 0xffffffff80bc6c08 > acd0: DVDR at ata0-master PIO4 > ad4: 114473MB at ata2-master UDMA33 > acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 > GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_LiveFS. > acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 > GEOM_LABEL: Label for provider ad4s3 is ntfs/HP_RECOVERY. > GEOM_LABEL: Label for provider ad4s4 is ntfs/OS_TOOLS. > SMP: AP CPU #1 Launched! > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-CCS device > da0: 1.000MB/s transfers > da0: 61MB (125952 512 byte sectors: 64H 32S/T 61C) > GEOM_LABEL: Label for provider da0s1 is msdosfs/CRUCIAL. > Trying to mount root from ufs:/dev/md0 > GEOM_LABEL: Label msdosfs/CRUCIAL removed. > GEOM_LABEL: Label for provider da0s1 is msdosfs/CRUCIAL. > GEOM_LABEL: Label msdosfs/CRUCIAL removed. > > ####################################################################### > Here is the NetBSD dmesg: > > Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, > 2006, 2007 > The NetBSD Foundation, Inc. All rights reserved. > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > > NetBSD 4.0 (GENERIC) #0: Sat Dec 15 22:25:31 PST 2007 > > builds@wb28:/home/builds/ab/netbsd-4-0-RELEASE/amd64/200712160005Z-obj/home/builds/ab/netbsd-4-0-RELEASE/src/sys/arch/amd64/compile/GENERIC > total memory = 3967 MB > avail memory = 3815 MB > timecounter: Timecounters tick every 10.000 msec > timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 > mainbus0 (root) > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Turion(tm) 64 X2 Mobile Technology TL-64, 2195.04 MHz > cpu0: features: ffdbfbff > cpu0: features: ffdbfbff > cpu0: features: ffdbfbff > cpu0: features2: 2001 > cpu0: I-cache 64 KB 64B/line 2-way, D-cache 64 KB 64B/line 2-way > cpu0: L2 cache 512 KB 64B/line 16-way > cpu0: ITLB 32 4 KB entries fully associative, 8 4 MB entries fully associative > cpu0: DTLB 32 4 KB entries fully associative, 8 4 MB entries fully associative > cpu0: AMD Power Management features: 7f > cpu0: AMD PowerNow! Technology 2200 MHz > cpu0: available frequencies (Mhz): 800 1600 1800 2000 2200 > cpu0: calibrating local timer > cpu0: apic clock running at 199 MHz > cpu0: 8 page colors > cpu1 at mainbus0: apid 1 (application processor) > cpu1: not started > ioapic0 at mainbus0 apid 2 (I/O APIC) > ioapic0: pa 0xfec00000, version 21, 24 pins > ioapic0: misconfigured as apic 0 > ioapic0: remapped to apic 2 > acpi0 at mainbus0: Advanced Configuration and Power Interface > acpi0: using Intel ACPI CA subsystem version 20060217 > acpi0: X/RSDT: OemId , AslId > ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A1 (name not of form > _Lxx or _Exx) [20060217] > ACPI Error (evgpeblk-0394): Unknown GPE method type: C28C (name not of form > _Lxx or _Exx) [20060217] > ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A2 (name not of form > _Lxx or _Exx) [20060217] > ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A3 (name not of form > _Lxx or _Exx) [20060217] > ACPI Error (evgpeblk-0394): Unknown GPE method type: C253 (name not of form > _Lxx or _Exx) [20060217] > ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A4 (name not of form > _Lxx or _Exx) [20060217] > ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A5 (name not of form > _Lxx or _Exx) [20060217] > ACPI Error (evgpeblk-0394): Unknown GPE method type: C262 (name not of form > _Lxx or _Exx) [20060217] > acpi0: SCI interrupting at int 9 > acpi0: fixed-feature power button present > timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000 > ACPI-Fast 32-bit timer > mpacpi: could not get bus number, assuming bus 0 > ACPI Object Type 'Processor' (0x0c) at acpi0 not configured > ACPI Object Type 'Processor' (0x0c) at acpi0 not configured > PNP0C01 [System Board] at acpi0 not configured > PNP0A03 [PCI/PCI-X Host Bridge] at acpi0 not configured > ACPI Object Type 'Power' (0x0b) at acpi0 not configured > acpiec0 at acpi0 (PNP0C09): ACPI Embedded Controller > acpiec0: io 0x62,0x66 > PNP0A06 [Generic Container Device] at acpi0 not configured > ACPI Object Type 'Power' (0x0b) at acpi0 not configured > ACPI Object Type 'Power' (0x0b) at acpi0 not configured > IFX0102 at acpi0 not configured > PNP0C04 [Math Coprocessor] at acpi0 not configured > attimer1 at acpi0 (PNP0100): AT Timer > attimer1: io 0x40-0x43 irq 0 > PNP0200 [AT DMA Controller] at acpi0 not configured > pcppi1 at acpi0 (PNP0800) > pcppi1: io 0x61 > pcppi1: children must have an explicit unit > midi0 at pcppi1: PC speaker (CPU-intensive output) > sysbeep0 at pcppi1 > PNP0B00 [AT Real-Time Clock] at acpi0 not configured > pckbc1 at acpi0 (PNP0303): kbd port > pckbc1: io 0x60,0x64 irq 1 > pckbc2 at acpi0 (SYN0131): aux port > pckbc2: irq 12 > ACPI Object Type 'Power' (0x0b) at acpi0 not configured > PNP0000 [AT Interrupt Controller] at acpi0 not configured > PNP0C02 [Plug and Play motherboard register resources] at acpi0 not configured > HPQ0004 at acpi0 not configured > PNP0C02 [Plug and Play motherboard register resources] at acpi0 not configured > HPQ0006 at acpi0 not configured > acpibat0 at acpi0 (PNP0C0A-1): ACPI Battery (Control Method) > acpibat1 at acpi0 (PNP0C0A-2): ACPI Battery (Control Method) > acpiacad0 at acpi0 (ACPI0003): ACPI AC Adapter > acpibut0 at acpi0 (PNP0C0E): ACPI Sleep Button > acpilid0 at acpi0 (PNP0C0D): ACPI Lid Switch > PNP0C14 at acpi0 not configured > PNP0C02 [Plug and Play motherboard register resources] at acpi0 not configured > ACPI Object Type 'Power' (0x0b) at acpi0 not configured > ACPI Object Type 'Power' (0x0b) at acpi0 not configured > ACPI Object Type 'Power' (0x0b) at acpi0 not configured > ACPI Object Type 'Power' (0x0b) at acpi0 not configured > PNP0C0B [ACPI Fan] at acpi0 not configured > PNP0C0B [ACPI Fan] at acpi0 not configured > PNP0C0B [ACPI Fan] at acpi0 not configured > PNP0C0B [ACPI Fan] at acpi0 not configured > acpitz0 at acpi0: ACPI Thermal Zone > acpitz0: unable to get polling interval; using default of 30.0s > acpitz0: active cooling level 0: 70.0C > acpitz0: active cooling level 1: 60.0C > acpitz0: active cooling level 2: 50.0C > acpitz0: active cooling level 3: 40.0C > acpitz0: critical 105.0C passive 38.0C > pcppi1: attached to attimer1 > pckbd0 at pckbc1 (kbd slot) > pckbc1: using irq 1 for kbd slot > wskbd0 at pckbd0: console keyboard > pms0 at pckbc1 (aux slot) > pms0: Synaptics touchpad version 6.2 > pms0: Palm detect, Multi-finger > pckbc1: using irq 12 for aux slot > wsmouse0 at pms0 mux 0 > pci0 at mainbus0 bus 0: configuration mode 1 > pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok > pchb0 at pci0 dev 0 function 0 > pchb0: ATI Technologies product 0x7910 (rev. 0x00) > ppb0 at pci0 dev 1 function 0: ATI Technologies product 0x7912 (rev. 0x00) > pci1 at ppb0 bus 1 > pci1: i/o space, memory space enabled > vga0 at pci1 dev 5 function 0: ATI Technologies product 0x791f (rev. 0x00) > wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation), using wskbd0 > wsmux1: connecting to wsdisplay0 > ppb1 at pci0 dev 4 function 0: ATI Technologies product 0x7914 (rev. 0x00) > pci2 at ppb1 bus 16 > pci2: i/o space, memory space enabled, rd/line, wr/inv ok > bge0 at pci2 dev 0 function 0: Broadcom BCM5787M Gigabit Ethernet > bge0: interrupting at ioapic0 pin 16 (irq 10) > bge0: ASIC BCM5754/5787 A2 (0xb002), Ethernet address 00:1f:29:85:3d:63 > bge0: setting short Tx thresholds > brgphy0 at bge0 phy 1: BCM5754/5787 1000BASE-T media interface, rev. 0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > ppb2 at pci0 dev 5 function 0: ATI Technologies product 0x7915 (rev. 0x00) > pci3 at ppb2 bus 32 > pci3: i/o space, memory space enabled, rd/line, wr/inv ok > ppb3 at pci0 dev 6 function 0: ATI Technologies product 0x7916 (rev. 0x00) > pci4 at ppb3 bus 48 > pci4: i/o space, memory space enabled, rd/line, wr/inv ok > Broadcom BCM4312 (miscellaneous network, revision 0x02) at pci4 dev 0 function > 0 not configured > ixpide0 at pci0 dev 18 function 0 > ixpide0: ATI Technologies IXP IDE Controller (rev. 0x00) > ixpide0: bus-master DMA support present > ixpide0: primary channel configured to native-PCI mode > ixpide0: using ioapic0 pin 16 (irq 10) for native-PCI interrupt > atabus0 at ixpide0 channel 0 > ixpide0: secondary channel configured to native-PCI mode > atabus1 at ixpide0 channel 1 > ohci0 at pci0 dev 19 function 0: ATI Technologies product 0x4387 (rev. 0x00) > ohci0: interrupting at ioapic0 pin 23 (irq 11) > ohci0: OHCI version 1.0, legacy support > usb0 at ohci0: USB revision 1.0 > uhub0 at usb0 > uhub0: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > ohci1 at pci0 dev 19 function 1: ATI Technologies product 0x4388 (rev. 0x00) > ohci1: interrupting at ioapic0 pin 17 (irq 5) > ohci1: OHCI version 1.0, legacy support > usb1 at ohci1: USB revision 1.0 > uhub1 at usb1 > uhub1: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 2 ports with 2 removable, self powered > ohci2 at pci0 dev 19 function 2: ATI Technologies product 0x4389 (rev. 0x00) > ohci2: interrupting at ioapic0 pin 17 (irq 5) > ohci2: OHCI version 1.0, legacy support > usb2 at ohci2: USB revision 1.0 > uhub2 at usb2 > uhub2: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub2: 2 ports with 2 removable, self powered > ohci3 at pci0 dev 19 function 3: ATI Technologies product 0x438a (rev. 0x00) > ohci3: interrupting at ioapic0 pin 17 (irq 5) > ohci3: OHCI version 1.0, legacy support > usb3 at ohci3: USB revision 1.0 > uhub3 at usb3 > uhub3: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub3: 2 ports with 2 removable, self powered > ohci4 at pci0 dev 19 function 4: ATI Technologies product 0x438b (rev. 0x00) > ohci4: interrupting at ioapic0 pin 17 (irq 5) > ohci4: OHCI version 1.0, legacy support > usb4 at ohci4: USB revision 1.0 > uhub4 at usb4 > uhub4: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub4: 2 ports with 2 removable, self powered > ehci0 at pci0 dev 19 function 5: ATI Technologies product 0x4386 (rev. 0x00) > ehci0: interrupting at ioapic0 pin 23 (irq 11) > ehci0: BIOS has given up ownership > ehci0: EHCI version 1.0 > ehci0: companion controllers, 2 ports each: ohci0 ohci1 ohci2 ohci3 ohci4 > usb5 at ehci0: USB revision 2.0 > uhub5 at usb5 > uhub5: ATI Technologies EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 > uhub5: 10 ports with 10 removable, self powered > ATI Technologies product 0x4385 (SMBus serial bus, revision 0x14) at pci0 dev > 20 function 0 not configured > ixpide1 at pci0 dev 20 function 1 > ixpide1: ATI Technologies IXP IDE Controller (rev. 0x00) > ixpide1: bus-master DMA support present > ixpide1: primary channel configured to compatibility mode > ixpide1: primary channel interrupting at ioapic0 pin 14 (irq 14) > atabus2 at ixpide1 channel 0 > ixpide1: secondary channel wired to compatibility mode > ixpide1: secondary channel interrupting at ioapic0 pin 15 (irq 15) > atabus3 at ixpide1 channel 1 > azalia0 at pci0 dev 20 function 2: Generic High Definition Audio Controller > azalia0: interrupting at ioapic0 pin 16 (irq 10) > azalia0: host: 0x1002/0x4383 (rev. 0) > azalia0: host: High Definition Audio rev. 1.0 > pcib0 at pci0 dev 20 function 3 > pcib0: ATI Technologies product 0x438d (rev. 0x00) > ppb4 at pci0 dev 20 function 4: ATI Technologies product 0x4384 (rev. 0x00) > pci5 at ppb4 bus 2 > pci5: i/o space, memory space enabled > cbb0 at pci5 dev 4 function 0: Ricoh 5C476 PCI-CardBus bridge (rev. 0xb6) > fwohci0 at pci5 dev 4 function 1: Ricoh product 0x0832 (rev. 0x02) > fwohci0: interrupting at ioapic0 pin 21 (irq 5) > fwohci0: OHCI version 1.10 (ROM=0) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:02:3f:99:29:21:1d:10 > fwohci0: Phy 1394a available S400, 1 ports. > fwohci0: Link S400, max_rec 2048 bytes. > ieee1394if0 at fwohci0: IEEE1394 bus > fwip0 at ieee1394if0: IP over IEEE1394 > fwohci0: Initiate bus reset > cbb0: interrupting at ioapic0 pin 20 (irq 10) > cardslot0 at cbb0 slot 0 flags 0 > cardbus0 at cardslot0: bus 3 > pcmcia0 at cardslot0 > pchb1 at pci0 dev 24 function 0 > pchb1: Advanced Micro Devices AMD64 HyperTransport configuration (rev. 0x00) > pchb2 at pci0 dev 24 function 1 > pchb2: Advanced Micro Devices AMD64 Address Map configuration (rev. 0x00) > pchb3 at pci0 dev 24 function 2 > pchb3: Advanced Micro Devices AMD64 DRAM configuration (rev. 0x00) > pchb4 at pci0 dev 24 function 3 > pchb4: Advanced Micro Devices AMD64 Miscellaneous configuration (rev. 0x00) > isa0 at pcib0 > ioapic0: enabling > WARNING: Callback scheduled before sysmon task queue thread present. > fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode > ieee1394if0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) > ieee1394if0: bus manager 0 (me) > timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0 > azalia0: codec[0]: Analog Devices AD1981HD (rev. 2.0) > azalia0: codec[0]: High Definition Audio rev. 1.0 > azalia0: playback: max channels=2, encodings=1 > azalia0: playback: PCM > formats=e007f<24bit,20bit,16bit,48kHz,44.1kHz,32kHz,22.05kHz,16kHz,11.025kHz,8kHz> > azalia0: recording: max channels=2, encodings=1 > azalia0: recording: PCM > formats=6007f<20bit,16bit,48kHz,44.1kHz,32kHz,22.05kHz,16kHz,11.025kHz,8kHz> > azalia0: codec[1]: 0x11c1/0x1040 (rev. 2.0) > azalia0: codec[1]: High Definition Audio rev. 1.0 > azalia0: codec[1]: No support for modem function groups > azalia0: codec[1] has no audio function groups > audio0 at azalia0: full duplex, independent > Kernelized RAIDframe activated > acpibat0: battery info: Hewlett-Packard, LIon, Primary, 48204 2008/04/13 > ugen0 at uhub2 port 1 > ugen0: AuthenTec Fingerprint Sensor, rev 1.10/6.23, addr 2 > wd0 at atabus0 drive 0: > wd0: drive supports 16-sector PIO transfers, LBA48 addressing > wd0: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 sectors > wd0: 32-bit data port > wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) > wd0(ixpide0:0:0): using PIO mode 4, Ultra-DMA mode 5 (Ultra/100) (using DMA) > atapibus0 at atabus2: 2 targets > cd0 at atapibus0 drive 0: cdrom > removable > cd0: 32-bit data port > cd0: drive supports PIO mode 4, DMA mode 2 > cd0(ixpide1:0:0): using PIO mode 4, DMA mode 2 (using DMA) > boot device: wd0 > root on wd0a dumps on wd0b > root file system type: ffs > WARNING: clock gained 7 days > WARNING: CHECK AND RESET THE DATE! > wsdisplay0: screen 1 added (80x25, vt100 emulation) > wsdisplay0: screen 2 added (80x25, vt100 emulation) > wsdisplay0: screen 3 added (80x25, vt100 emulation) > wsdisplay0: screen 4 added (80x25, vt100 emulation) > > > > > > > On Sunday 11 May 2008 07:49:47 you wrote: > > On Sat, 2008-05-10 at 14:33 -0400, Coleman Kane wrote: > > > On Sat, 2008-05-10 at 12:13 -0500, rar102@ra.msstate.edu wrote: > > > > Quoting Coleman Kane : > > > > > > > > Yes!!! thank you. Unfortunately, I don't have access to another amd64 > > > > box to try your patch. Sorry. But, I will look at the dmesg and send > > > > it to you. > > > > > > Excellent. A dmesg will be very helpful for me to write a patch from, as > > > it will allow me to see if it is or is not the sound driver overlapping > > > memory in your case. I suspect that the BIOS images are so similar that > > > you probably even have almost the same bios-chosen memory regions on > > > your system. > > > > If you're having difficulty getting a dmesg, you might want to try > > booting off the LiveFS disc with a USB flash drive plugged in. You can > > then mount the flash drive (which should be detected as SCSI) and write > > the dmesg output there. > > > > > > > RAR, > > > > > > > > > > You are in luck! Well, actually I have good news and I have bad news. > > > > > The good news is that I have nearly the same (6715b) laptop and > > > > > experienced similar problems when getting FreeBSD onto it. After some > > > > > work, I've been able to use FreeBSD reliably on the system. > > > > > > > > > > The bad news is that you probably have an overlap of PCI memory > > > > > ranges between the SATA controller and another device in the system > > > > > (likely the audio controller). > > > > > > > > > > I put up a page describing the problem here: > > > > > > > > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_ > > > >hp_compaq_6715b_working > > > > > > > > > Specifically, read this section: > > > > > > > > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#the_onboard_ > > > >ati_sb600_hda_audio_controller > > > > > > > > > Give me the weekend, and I will post a 7.0-RELEASE CD with the patch > > > > > in it. I figured that I should have done it a while ago. Oh well. > > > > > > > > > > While you are at it, see if you can use Scroll-Lock and the up/down > > > > > keys to read the kernel messages. See if you can find the atapci0 > > > > > probe line for your SATA controller (AHCI), as well as the line for > > > > > your pcm0 device and send them back to me. I can add your info to my > > > > > webpage to help others. > > > > > > > > > > It will look like this: > > > > > atapci0: port > > > > > 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f > > > > > mem 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 > > > > > ... > > > > > pcm0: mem > > > > > 0xd0608000-0xd060bfff irq 16 at device 20.2 on pci0 > > > > > > > > > > You'll notice the "mem" resource for the audio controller is > > > > > 0xd0608000-0xd060bff, and the "mem" resource for the SATA controller > > > > > is 0xd0609000-0xd06093ff. The SATA controller's "mem" resource is > > > > > completely covered by this audio controller. > > > > > > > > > > If you happen to have access to another machine for building your own > > > > > releases, you can try my patch and build them from it. > > > > > > > > > > -- > > > > > Coleman Kane -------------- 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-arch/attachments/20080513/74aeb956/attachment.pgp From kostikbel at gmail.com Tue May 13 09:37:49 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue May 13 09:37:53 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080512100202.W954@desktop> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080510214812.Y954@desktop> <20080511115030.GV18958@deviant.kiev.zoral.com.ua> <20080511115815.GW18958@deviant.kiev.zoral.com.ua> <20080511153926.T954@desktop> <20080512101607.GC18958@deviant.kiev.zoral.com.ua> <20080512100202.W954@desktop> Message-ID: <20080513093734.GF18958@deviant.kiev.zoral.com.ua> On Mon, May 12, 2008 at 10:03:14AM -1000, Jeff Roberson wrote: > > On Mon, 12 May 2008, Kostik Belousov wrote: > > >On Sun, May 11, 2008 at 03:40:14PM -1000, Jeff Roberson wrote: > >> > >>On Sun, 11 May 2008, Kostik Belousov wrote: > >> > >>>On Sun, May 11, 2008 at 02:50:30PM +0300, Kostik Belousov wrote: > >>>>On Sat, May 10, 2008 at 09:53:12PM -1000, Jeff Roberson wrote: > >>>>>On Sun, 4 May 2008, Kostik Belousov wrote: > >>>>> > >>>>>>Since the review for the clone-at-open patch (fdclone) posted some > >>>>>>time > >>>>>>ago > >>>>>>mostly says that it would be better to implement per-file private data > >>>>>>instead, I produced the patch along this line, > >>>>>> > >>>>>>The patch does not change the cdevsw ABI, instead, three new functions > >>>>>>nt devfs_get_cdevpriv(void **datap); > >>>>>>int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > >>>>>>void devfs_clear_cdevpriv(void); > >>>>>>are provided for manipulation of the per-file private data. > >>>>>> > >>>>>>devfs_set_cdevpriv assigns the priv as private data for the file > >>>>>>descriptor > >>>>>>which is used to initiate currently performed driver operation. dtr > >>>>>>is the function that will be called when either the last refernce to > >>>>>>the file goes away or devfs_clear_cdevpriv is called. > >>>>>> > >>>>>>devfs_get_cdevpriv is the obvious accessor. > >>>>>> > >>>>>>devfs_clear_cdevpriv allows to clear the private data for the still > >>>>>>open file. > >>>>>> > >>>>>>The synchronization of the cdev data and file private data is left > >>>>>>to the driver code, I did not found any generic helper mechanism that > >>>>>>could be useful there. > >>>>>> > >>>>>>Patch: > >>>>>>http://people.freebsd.org/~kib/misc/fdpriv.1.patch > >>>>>> > >>>>>>Dumb driver that shows the basic usage of the proposed KPI: > >>>>>>http://people.freebsd.org/~kib/misc/fpclone.c > >>>>>> > >>>>>>Previous version of the patch was tested by Peter Holm. > >>>>>> > >>>>> > >>>>>Hi Kostik, > >>>>> > >>>>>Are these per-instances structures intended to be used by anything > >>>>>other > >>>>>than devices? If not can we make them a union with the DTYPE_VNODE > >>>>>fields to save space? > >>>>> > >>>>>Thanks, > >>>>>Jeff > >>>> > >>>>The current version of the patch is at > >>>>http://people.freebsd.org/~kib/misc/fdpriv.3.patch > >>>> > >>>>Per insistence of John Baldwin and request of Eric Anholt, the > >>>>destructors > >>>>are called now when either file is last closed, or the device is > >>>>destroyed. > >>>>This versions adds only one pointer to the struct file. > >>>> > >>>>Jeff, would you, please, explicitely specify what field you propose to > >>>>union with the f_cdevpriv ? > >> > >>f_nextoff and f_seqcount are only used if vn_read() and vn_write() are > >>used. They do not apply to any other descriptors. > >I use the f_cdevpriv != NULL as an indicator for the necessity to enter > >the cdevpriv code, in particular, locking the cdevpriv_mtx, that would > >otherwise needed to be entered at each last close. I think that one > >pointer for the struct file is not too big cost, do you agree ? > > No, it's not a big cost, however if it is possible to avoid that is best. > > Can you not check the type before checking f_cdevpriv? Should we not only > be checking cdevpriv in contexts where we know that it is not a vnode? I am sorry, my english may be not enough, so I may interpret your proposal mistakenly. I read it as a suggestion to check the file type before accessing the f_cdevpriv. The problem with the f_cdevpriv exists only at the _fdrop(). There, we have a file of f_type == DTYPE_VNODE both for devfs and normal files. I cannot check the f_vnode since the vnode may be reclaimed. The only differentiator is the f_ops, that is devfs_ops_f for devfs file, and vnops for the normal file during the file lifetime. Unfortunately, f_ops is reset to the badfileops by vn_closefile before the _fdrop() is getting called. Reserving the flag in the f_flag looks not good due to interaction with the userspace. I do not want the callback to be called before the d_close() driver method gets a chance to clean the data. > > > > >> > >>> > >>>Of course, I forgot to answer the question. Yes, the KPI is supposed to > >>>be used by the drivers only. Please, note that device open files have > >>>DTYPE_VNODE. > >>> > > -------------- 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-arch/attachments/20080513/91c68e39/attachment.pgp From jeremie at le-hen.org Wed May 14 09:13:58 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Wed May 14 09:14:03 2008 Subject: Integration of ProPolice in FreeBSD In-Reply-To: <8ED24288-618C-4B55-A27E-C5FAB2E046E8@mac.com> References: <20080502070147.GE74500@obiwan.tataz.chchile.org> <8ED24288-618C-4B55-A27E-C5FAB2E046E8@mac.com> Message-ID: <20080514091108.GD70896@obiwan.tataz.chchile.org> Hi Marcel, Thank you for your comments. On Fri, May 02, 2008 at 08:52:37AM -0700, Marcel Moolenaar wrote: > Index: share/mk/bsd.sys.mk > =================================================================== > RCS file: /mnt/octobre/space/freebsd-cvs/src/share/mk/bsd.sys.mk,v > retrieving revision 1.44 > diff -u -p -r1.44 bsd.sys.mk > --- share/mk/bsd.sys.mk 22 Nov 2007 23:21:12 -0000 1.44 > +++ share/mk/bsd.sys.mk 29 Mar 2008 23:13:06 -0000 > @@ -74,5 +74,10 @@ CWARNFLAGS += -Werror > CWARNFLAGS += -Wno-unknown-pragmas > .endif > > +.if ${MK_SSP} != "no" && ${CC} != "icc" > +CFLAGS += -fstack-protector > +# Don't use -Wstack-protector as it breaks world with -Werror. > +.endif > + > # Allow user-specified additional warning flags > CFLAGS += ${CWARNFLAGS} > > > I may be better to explicitly test for GCC. I would not assume > that GCC and ICC are the only options, even if they are now. > There's a second place as well... I would make sense to test for GCC indeed but in the same file there is a number of explicit tests for ICC. Thus I prefer to keep to the current "style" at the expense of a little more work for those who will try to compile with another compiler. > Index: sys/boot/i386/Makefile.inc > =================================================================== > RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/boot/i386/Makefile.inc,v > retrieving revision 1.12 > diff -u -p -r1.12 Makefile.inc > --- sys/boot/i386/Makefile.inc 28 Sep 2006 10:02:04 -0000 1.12 > +++ sys/boot/i386/Makefile.inc 28 Mar 2008 07:41:32 -0000 > @@ -24,3 +24,5 @@ BTXDIR= ${.CURDIR}/../btx > BTXLDR= ${BTXDIR}/btxldr/btxldr > BTXKERN= ${BTXDIR}/btx/btx > BTXCRT= ${BTXDIR}/lib/crt0.o > + > +.include "../Makefile.inc" > Index: sys/boot/i386/loader/Makefile > =================================================================== > RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/boot/i386/loader/Makefile,v > retrieving revision 1.85 > diff -u -p -r1.85 Makefile > --- sys/boot/i386/loader/Makefile 29 May 2007 14:35:57 -0000 1.85 > +++ sys/boot/i386/loader/Makefile 16 Apr 2008 09:14:10 -0000 > @@ -1,5 +1,7 @@ > # $FreeBSD: src/sys/boot/i386/loader/Makefile,v 1.85 2007/05/29 14:35:57 > simokawa Exp $ > > +WITHOUT_SSP= > + > .include > > PROG= loader.sym > > Maybe second and third level makefiles should include > ../../Makefile.inc and ../../../Makefile.inc resp. > If, for arguments sake, we want to enable SSP in boot, > then it's best if that only requires a single knob to > be changed. This may not be a strong argument for SSP, > but with Makefile.inc in place, I don't see a possible > future in which another knob is added that controls > overall behavior (e.g. something like the Watcom option > to use argument passing in registers instead of on the > stack for i386 -- you definitely want to have that apply > to all code or none). For now, I prefer leaving it as is and let anyone else make this change. While I agree with your argument, I'm not sure this benefit is worth the complexity it adds for now, given that the only knob is WITHOUT_SSP and it would require more than a simple switch to use SSP for /boot (import SSP symbols). > Also, please make sure MK_SSP defaults to "no" on ia64. Ok, done. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From kostikbel at gmail.com Wed May 14 09:32:56 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed May 14 09:33:01 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080513093734.GF18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080510214812.Y954@desktop> <20080511115030.GV18958@deviant.kiev.zoral.com.ua> <20080511115815.GW18958@deviant.kiev.zoral.com.ua> <20080511153926.T954@desktop> <20080512101607.GC18958@deviant.kiev.zoral.com.ua> <20080512100202.W954@desktop> <20080513093734.GF18958@deviant.kiev.zoral.com.ua> Message-ID: <20080514093223.GN18958@deviant.kiev.zoral.com.ua> On Tue, May 13, 2008 at 12:37:34PM +0300, Kostik Belousov wrote: > On Mon, May 12, 2008 at 10:03:14AM -1000, Jeff Roberson wrote: > > > > On Mon, 12 May 2008, Kostik Belousov wrote: > > > > >On Sun, May 11, 2008 at 03:40:14PM -1000, Jeff Roberson wrote: > > >> > > >>On Sun, 11 May 2008, Kostik Belousov wrote: > > >> > > >>>On Sun, May 11, 2008 at 02:50:30PM +0300, Kostik Belousov wrote: > > >>>>On Sat, May 10, 2008 at 09:53:12PM -1000, Jeff Roberson wrote: > > >>>>>On Sun, 4 May 2008, Kostik Belousov wrote: > > >>>>> > > >>>>>>Since the review for the clone-at-open patch (fdclone) posted some > > >>>>>>time > > >>>>>>ago > > >>>>>>mostly says that it would be better to implement per-file private data > > >>>>>>instead, I produced the patch along this line, > > >>>>>> > > >>>>>>The patch does not change the cdevsw ABI, instead, three new functions > > >>>>>>nt devfs_get_cdevpriv(void **datap); > > >>>>>>int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > > >>>>>>void devfs_clear_cdevpriv(void); > > >>>>>>are provided for manipulation of the per-file private data. > > >>>>>> > > >>>>>>devfs_set_cdevpriv assigns the priv as private data for the file > > >>>>>>descriptor > > >>>>>>which is used to initiate currently performed driver operation. dtr > > >>>>>>is the function that will be called when either the last refernce to > > >>>>>>the file goes away or devfs_clear_cdevpriv is called. > > >>>>>> > > >>>>>>devfs_get_cdevpriv is the obvious accessor. > > >>>>>> > > >>>>>>devfs_clear_cdevpriv allows to clear the private data for the still > > >>>>>>open file. > > >>>>>> > > >>>>>>The synchronization of the cdev data and file private data is left > > >>>>>>to the driver code, I did not found any generic helper mechanism that > > >>>>>>could be useful there. > > >>>>>> > > >>>>>>Patch: > > >>>>>>http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > >>>>>> > > >>>>>>Dumb driver that shows the basic usage of the proposed KPI: > > >>>>>>http://people.freebsd.org/~kib/misc/fpclone.c > > >>>>>> > > >>>>>>Previous version of the patch was tested by Peter Holm. > > >>>>>> > > >>>>> > > >>>>>Hi Kostik, > > >>>>> > > >>>>>Are these per-instances structures intended to be used by anything > > >>>>>other > > >>>>>than devices? If not can we make them a union with the DTYPE_VNODE > > >>>>>fields to save space? > > >>>>> > > >>>>>Thanks, > > >>>>>Jeff > > >>>> > > >>>>The current version of the patch is at > > >>>>http://people.freebsd.org/~kib/misc/fdpriv.3.patch > > >>>> > > >>>>Per insistence of John Baldwin and request of Eric Anholt, the > > >>>>destructors > > >>>>are called now when either file is last closed, or the device is > > >>>>destroyed. > > >>>>This versions adds only one pointer to the struct file. > > >>>> > > >>>>Jeff, would you, please, explicitely specify what field you propose to > > >>>>union with the f_cdevpriv ? > > >> > > >>f_nextoff and f_seqcount are only used if vn_read() and vn_write() are > > >>used. They do not apply to any other descriptors. > > >I use the f_cdevpriv != NULL as an indicator for the necessity to enter > > >the cdevpriv code, in particular, locking the cdevpriv_mtx, that would > > >otherwise needed to be entered at each last close. I think that one > > >pointer for the struct file is not too big cost, do you agree ? > > > > No, it's not a big cost, however if it is possible to avoid that is best. > > > > Can you not check the type before checking f_cdevpriv? Should we not only > > be checking cdevpriv in contexts where we know that it is not a vnode? > > I am sorry, my english may be not enough, so I may interpret your > proposal mistakenly. I read it as a suggestion to check the file type > before accessing the f_cdevpriv. > > The problem with the f_cdevpriv exists only at the _fdrop(). There, we > have a file of f_type == DTYPE_VNODE both for devfs and normal files. > I cannot check the f_vnode since the vnode may be reclaimed. The only > differentiator is the f_ops, that is devfs_ops_f for devfs file, and > vnops for the normal file during the file lifetime. Unfortunately, > f_ops is reset to the badfileops by vn_closefile before the _fdrop() is > getting called. > > Reserving the flag in the f_flag looks not good due to interaction with > the userspace. > > I do not want the callback to be called before the d_close() driver method > gets a chance to clean the data. So, I cannot implement overlay of the cdevpriv over the seqaccess data without some additional flag. On the other hand, use of 2 bytes for the f_type is overkill when the range of the types is [1,8]. I divided it to two one-byte fields, and new field is used for filetype-specific flags. http://people.freebsd.org/~kib/misc/fdpriv.4.patch shall give the same size of the struct file while not causing unconditional acquire of the cdevpriv_mtx on the last file close. Jeff, do you agree with the proposed vivisection of the f_type ? I will ask Peter to retest the patch then. -------------- 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-arch/attachments/20080514/24120e03/attachment.pgp From cokane at FreeBSD.org Wed May 14 22:50:30 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Wed May 14 22:50:35 2008 Subject: Feature requests for open-source graphics In-Reply-To: <1210352688.2152.78.camel@localhost> References: <1210352688.2152.78.camel@localhost> Message-ID: <1210801773.2466.12.camel@localhost> On Fri, 2008-05-09 at 10:04 -0700, Eric Anholt wrote: > (Re-sent after I dragged a discussion of NVIDIA on FreeBSD off-topic on > developers@) > > On Wed, 2008-05-07 at 10:37 -0700, Marcel Moolenaar wrote: > > On May 7, 2008, at 8:29 AM, John Baldwin wrote: > > > > > Quite, and this has been covered several times already. In fact, > > > they engage > > > in several hacks to support Linux. Other OS's such as Solaris and > > > OS X have > > > cleaner interfaces for many of the things they wish to do. > > > > I think this is where I normally say that we need kernel drivers > > for graphics hardware. I'm not going to do that anymore; I've been > > stating the obvious too often already... > > It's OK, we're finally listening. By the end of the year, major Linux > distributions should be shipping "DRM modesetting" -- the DRM device > takes over your graphics card and manages memory, execution, and > suspend/resume. Your kernel console and X Server then sit on top of > that, submitting video mode setting and command execution requests to > the DRM. The chips I would expect to be supported by then are all > Intel, pre-r500 ATI at least, and a subset of nvidia through nouveau. > > What FreeBSD needs to do to keep up is implement the memory manager > part. I think I've got a reasonable design going that should take about > a month of reimplementing for the FreeBSD kernel. If someone wanted to > get us closer to doing that, > > git clone anongit.freedesktop.org:/git/mesa/drm > > and make everything but TTM (the *_HAVE_FENCE and *_HAVE_BUFFER defines) > work on -current. > > To see what we're working on for what we're calling the "graphics > execution manager" now (memory management plus caching management plus > plans for execution scheduling), > > git-remote add anholt people.freedesktop.org:~anholt/drm > git-fetch anholt > git-checkout anholt/drm-gem > > The interesting things we're needing from the kernel: > - Private storage associated with file descriptors > - Callback to driver on destruction of file descriptor > - Ability to allocate a swap-backed pile of memory > - Ability to pin pages from that object and get addresses for them to > stuff into the GTT. > - Ability to map pages in the kernel with the uncached bits set > (non-intel) > - Ability to map pages to userland with the uncached bits set > (non-intel, likely not required, but may come at a performance > cost). > > Interesting things we're likely going to need from the kernel: > - Ability to create fds above 1024 from our driver, associated with our > own set of file operations (read/write/mmap/ioctl/close). > - Ability to look up those fds and get our private storage associated > with them. > > If above goes through, then another likely adventure: > - Creating a filesystem exposing those objects we've been making fds > for. > > email message attachment, "Forwarded message - Re: Forward: Updated > FreeBSD kernel feature requests (NVIDIA graphics)" > > -------- Forwarded Message -------- > > From: Eric Anholt > > To: Marcel Moolenaar > > Cc: John Baldwin , Coleman Kane > > , Dag-Erling Sm?rgrav , Martin > > Cracauer , gnn@freebsd.org, > > developers@freebsd.org > > Subject: Re: Forward: Updated FreeBSD kernel feature requests > > (NVIDIA graphics) > > Date: Thu, 08 May 2008 15:54:17 -0700 > > Mailer: Evolution 2.22.0 FreeBSD GNOME Team Port > > > > On Wed, 2008-05-07 at 10:37 -0700, Marcel Moolenaar wrote: > > > On May 7, 2008, at 8:29 AM, John Baldwin wrote: > > > > > > > Quite, and this has been covered several times already. In fact, > > > > they engage > > > > in several hacks to support Linux. Other OS's such as Solaris and > > > > OS X have > > > > cleaner interfaces for many of the things they wish to do. > > > > > > I think this is where I normally say that we need kernel drivers > > > for graphics hardware. I'm not going to do that anymore; I've been > > > stating the obvious too often already... > > > > It's OK, we're finally listening. By the end of the year, major Linux > > distributions should be shipping "DRM modesetting" -- the DRM device > > takes over your graphics card and manages memory, execution, and > > suspend/resume. Your kernel console and X Server then sit on top of > > that, submitting video mode setting and command execution requests to > > the DRM. The chips I would expect to be supported by then are all > > Intel, pre-r500 ATI at least, and a subset of nvidia through nouveau. > > > > What FreeBSD needs to do to keep up is implement the memory manager > > part. I think I've got a reasonable design going that should take about > > a month of reimplementing for the FreeBSD kernel. If someone wanted to > > get us closer to doing that, > > > > git clone anongit.freedesktop.org:/git/mesa/drm > > > > and make everything but TTM (the *_HAVE_FENCE and *_HAVE_BUFFER defines) > > work on -current. > > > > To see what we're working on for what we're calling the "graphics > > execution manager" now (memory management plus caching management plus > > plans for execution scheduling), > > > > git-remote add anholt people.freedesktop.org:~anholt/drm > > git-fetch anholt > > git-checkout anholt/drm-gem > > > > The interesting things we're needing from the kernel: > > - Private storage associated with file descriptors > > - Callback to driver on destruction of file descriptor > > - Ability to allocate a swap-backed pile of memory > > - Ability to pin pages from that object and get addresses for them to > > stuff into the GTT. > > - Ability to map pages in the kernel with the uncached bits set > > (non-intel) > > - Ability to map pages to userland with the uncached bits set > > (non-intel, likely not required, but may come at a performance > > cost). > > > > Interesting things we're considering needing from the kernel: > > - Ability to create fds above 1024 from our driver, associated with our > > own set of file operations (read/write/mmap/ioctl/close). > > - Ability to look up those fds and get our private storage associated > > with them. > > > > Down the line, likely to happen: > > - Creating a filesystem exposing those objects we've been making fds > > for. Eric, I mentioned earlier that I would get my local git repo's changes to the mesa/drm tree available from fd.o up somewhere. I have them here: * http://www.cokane.org/cgi-bin/gitweb.cgi?p=drm.git My custom branch is 'cokane-master' The fd.o branch is tracked on 'fd-master' You can ignore the 'master' branch for now... I need to re-org my git a bit. Right now, this gets my RS690 notebook to almost work with the in-development radeonhd DRI code, but it causes Xorg to run in a busyloop when I try using the xf86-video-ati driver with it. I did a run at trying to get the vblank stuff ported over, but I got busy and haven't touched it in a bit. I also tried to tweak anything else that kept the radeon code from compiling under FreeBSD. If I have another set of eyes on this it might help me front-burner it more often to get patches in here-and-there. I've tried shoving some bug reports up to the DRI project, but they haven't been acted upon yet... -- Coleman Kane -------------- 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-arch/attachments/20080514/3644b679/attachment.pgp From rar102 at ra.msstate.edu Thu May 15 04:57:01 2008 From: rar102 at ra.msstate.edu (R. Riehle) Date: Thu May 15 04:57:07 2008 Subject: compaq 6515b turion x2 laptop In-Reply-To: <1210640554.1439.11.camel@localhost> References: <1210436112.4825ca102cfce@webmail.msstate.edu> <1210437989.62567.17.camel@localhost> <1210439595.4825d7ab5c1df@webmail.msstate.edu> <1210444435.62567.19.camel@localhost> <1210510187.62567.22.camel@localhost> <200805121351.36765.rar102@ra.msstate.edu> <1210640554.1439.11.camel@localhost> Message-ID: <17245805.post@talk.nabble.com> Coleman, This laptop has a flaky connector to the cdrom. It took me a lot of time and pulled-out hair to determine this. It needs to go back to HP before I can help you on this front. Coleman Kane-4 wrote: > > On Mon, 2008-05-12 at 13:51 -0500, Robertsen A. Riehle wrote: >> Coleman, >> >> Sorry for dropping off the Earth for a moment there. In order to make >> amends, >> I am giving you two dmesg's. One from the installed NetBSD and one from >> the >> FreeBSD livefs. Tell me if there is anything else I can get for you. I >> don't know if this is helpful or not. Possibly helpful command line >> output >> below: >> >> dmesg | grep pcm >> No output. This is not suprising for a livefs. >> >> kldload snd_hda >> kldload: can't load snd_hda: No such file or directory. Not >> surprising, >> again. But it was worth a try. >> >> dmesg | grep atapci >> atapci0: port >> 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem >> 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 >> atapci0: [ITHREAD] >> ata2: on atapci0 >> ata3: on atapci0 >> atapci1: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1 >> on >> pci0 >> ata0: on atapci1 >> > > It looks to me that you have almost the identical system to what I have > from HP. The SATA controller is definitely the same exact memory > mapping. So, I've got two projects for you: > > 1) See if you can boot off the LiveFS again, and give me the output of > "devinfo -u -v" > 2) Visit the following page: > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_hp_compaq_6715b_working > > Follow the directions that point you to where to find the good ISO > images, and > use them to boot the system. When you get to the boot menu, choose > option #6 > that will take you to the loader console. Then enter the following at > the > loader prompt: > > set hw.pci.hp6715b_membase_for_hda_audio="0xd0614000" > > Then enter (to start the system): > > boot > > See if that does anything for you better. If you still have problems, > then it is likely you'll need a different membase. I hopefully will be > able to give you a good mem-base depending upon the output of #1, above. > > The purpose of setting that loader variable is discussed further down > the document on my site, under the HDA Audio device discussion. You can > safely add that loader setting to /boot/loader.conf so that it is > automatically set after you get your system installed. > > I'd like to get a copy of your new dmesg (using my images) after you > boot up as well. > > -- > Coleman Kane > > > Rest of the blob copied below: >> ################################################################## >> Here is the FreeBSD dmesg: >> Copyright (c) 1992-2008 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.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 >> root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-64 (2194.58-MHz K8-class >> CPU) >> Origin = "AuthenticAMD" Id = 0x60f82 Stepping = 2 >> >> Features=0x178bfbff >> Features2=0x2001 >> AMD Features=0xea500800 >> AMD Features2=0x11f >> Cores per package: 2 >> usable memory = 4143468544 (3951 MB) >> avail memory = 3974230016 (3790 MB) >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> ACPI Error (tbfadt-0516): 32/64X address mismatch in "Pm2ControlBlock": [ >> 8800] [ 0 8100], using 64X [20070320] >> ioapic0: Changing APIC ID to 2 >> ioapic0 irqs 0-23 on motherboard >> kbd1 at kbdmux0 >> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, >> RF5413) >> hptrr: HPT RocketRAID controller driver v1.1 (Feb 24 2008 10:34:18) >> acpi0: on motherboard >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> unknown: I/O range not supported >> acpi0: reservation of 0, 8000000 (3) failed >> acpi0: reservation of 100000, fff00000 (3) failed >> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 >> acpi_ec0: port 0x62,0x66 on acpi0 >> cpu0: on acpi0 >> acpi_throttle0: on cpu0 >> powernow0: on cpu0 >> cpu1: on acpi0 >> acpi_throttle1: on cpu1 >> acpi_throttle1: failed to attach P_CNT >> device_attach: acpi_throttle1 attach returned 6 >> powernow1: on cpu1 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pcib1: at device 1.0 on pci0 >> pci1: on pcib1 >> vgapci0: port 0x4000-0x40ff mem >> 0xc0000000-0xc7ffffff,0xd0400000-0xd040ffff,0xd0500000-0xd05fffff irq 19 >> at >> device 5.0 on pci1 >> pcib2: at device 4.0 on pci0 >> pci16: on pcib2 >> pci0:16:0:0: failed to read VPD data. >> bge0: mem >> 0xd0000000-0xd000ffff >> irq 16 at device 0.0 on pci16 >> miibus0: on bge0 >> brgphy0: PHY 1 on miibus0 >> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-FDX, auto >> bge0: Ethernet address: 00:1f:29:85:3d:63 >> bge0: [ITHREAD] >> pcib3: at device 5.0 on pci0 >> pci32: on pcib3 >> pcib4: at device 6.0 on pci0 >> pci48: on pcib4 >> pci48: at device 0.0 (no driver attached) >> atapci0: port >> 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem >> 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 >> atapci0: [ITHREAD] >> ata2: on atapci0 >> ata2: [ITHREAD] >> ata3: on atapci0 >> ata3: [ITHREAD] >> ohci0: mem 0xd0601000-0xd0601fff irq 23 >> at >> device 19.0 on pci0 >> ohci0: [GIANT-LOCKED] >> ohci0: [ITHREAD] >> usb0: OHCI version 1.0, legacy support >> usb0: on ohci0 >> usb0: USB revision 1.0 >> uhub0: on usb0 >> uhub0: 2 ports with 2 removable, self powered >> ohci1: mem 0xd0602000-0xd0602fff irq 17 >> at >> device 19.1 on pci0 >> ohci1: [GIANT-LOCKED] >> ohci1: [ITHREAD] >> usb1: OHCI version 1.0, legacy support >> usb1: on ohci1 >> usb1: USB revision 1.0 >> uhub1: on usb1 >> uhub1: 2 ports with 2 removable, self powered >> ohci2: mem 0xd0603000-0xd0603fff irq 17 >> at >> device 19.2 on pci0 >> ohci2: [GIANT-LOCKED] >> ohci2: [ITHREAD] >> usb2: OHCI version 1.0, legacy support >> usb2: on ohci2 >> usb2: USB revision 1.0 >> uhub2: on usb2 >> uhub2: 2 ports with 2 removable, self powered >> ohci3: mem 0xd0604000-0xd0604fff irq 17 >> at >> device 19.3 on pci0 >> ohci3: [GIANT-LOCKED] >> ohci3: [ITHREAD] >> usb3: OHCI version 1.0, legacy support >> usb3: on ohci3 >> usb3: USB revision 1.0 >> uhub3: on usb3 >> uhub3: 2 ports with 2 removable, self powered >> ohci4: mem 0xd0605000-0xd0605fff irq 17 >> at >> device 19.4 on pci0 >> ohci4: [GIANT-LOCKED] >> ohci4: [ITHREAD] >> usb4: OHCI version 1.0, legacy support >> usb4: on ohci4 >> usb4: USB revision 1.0 >> uhub4: on usb4 >> uhub4: 2 ports with 2 removable, self powered >> ehci0: mem 0xd0606000-0xd06060ff irq >> 23 at >> device 19.5 on pci0 >> ehci0: [GIANT-LOCKED] >> ehci0: [ITHREAD] >> usb5: EHCI version 1.0 >> usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 >> usb5: on ehci0 >> usb5: USB revision 2.0 >> uhub5: on usb5 >> uhub5: 10 ports with 10 removable, self powered >> pci0: at device 20.0 (no driver attached) >> atapci1: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1 >> on >> pci0 >> ata0: on atapci1 >> ata0: [ITHREAD] >> pci0: at device 20.2 (no driver attached) >> isab0: at device 20.3 on pci0 >> isa0: on isab0 >> pcib5: at device 20.4 on pci0 >> pci2: on pcib5 >> cbb0: mem 0xd0100000-0xd0100fff irq 20 at >> device >> 4.0 on pci2 >> cardbus0: on cbb0 >> pccard0: <16-bit PCCard bus> on cbb0 >> cbb0: [ITHREAD] >> fwohci0: <1394 Open Host Controller Interface> mem 0xd0101000-0xd01017ff >> irq >> 21 at device 4.1 on pci2 >> fwohci0: [FILTER] >> fwohci0: OHCI version 1.10 (ROM=0) >> fwohci0: No. of Isochronous channels is 4. >> fwohci0: EUI64 00:02:3f:99:29:21:1d:10 >> fwohci0: Phy 1394a available S400, 1 ports. >> fwohci0: Link S400, max_rec 2048 bytes. >> firewire0: on fwohci0 >> dcons_crom0: on firewire0 >> dcons_crom0: bus_addr 0x15dc000 >> fwe0: on firewire0 >> if_fwe0: Fake Ethernet address: 02:02:3f:21:1d:10 >> fwe0: Ethernet address: 02:02:3f:21:1d:10 >> fwip0: on firewire0 >> fwip0: Firewire address: 00:02:3f:99:29:21:1d:10 @ 0xfffe00000000, S400, >> maxrec 2048 >> sbp0: on firewire0 >> fwohci0: Initiate bus reset >> fwohci0: BUS reset >> fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode >> battery0: on acpi0 >> battery1: on acpi0 >> acpi_acad0: on acpi0 >> acpi_button0: on acpi0 >> acpi_lid0: on acpi0 >> acpi_tz0: on acpi0 >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> atkbd0: [ITHREAD] >> psm0: irq 12 on atkbdc0 >> psm0: [GIANT-LOCKED] >> psm0: [ITHREAD] >> psm0: model IntelliMouse, device ID 3 >> ppc0: port 0-0x7,0x400-0x402 on acpi0 >> ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode >> ppbus0: on ppc0 >> plip0: on ppbus0 >> lpt0: on ppbus0 >> lpt0: Polled port >> ppi0: on ppbus0 >> orm0: at iomem 0xd0000-0xd0fff on isa0 >> 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 >> ugen0: > addr >> 2> on uhub0 >> umass0: on uhub1 >> ugen1: > addr >> 2> on uhub2 >> Timecounters tick every 1.000 msec >> hptrr: no controller detected. >> firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) >> firewire0: bus manager 0 (me) >> md0: Preloaded image 4194304 bytes at 0xffffffff80bc6c08 >> acd0: DVDR at ata0-master PIO4 >> ad4: 114473MB at ata2-master UDMA33 >> acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 >> GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_LiveFS. >> acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 >> GEOM_LABEL: Label for provider ad4s3 is ntfs/HP_RECOVERY. >> GEOM_LABEL: Label for provider ad4s4 is ntfs/OS_TOOLS. >> SMP: AP CPU #1 Launched! >> da0 at umass-sim0 bus 0 target 0 lun 0 >> da0: Removable Direct Access SCSI-CCS device >> da0: 1.000MB/s transfers >> da0: 61MB (125952 512 byte sectors: 64H 32S/T 61C) >> GEOM_LABEL: Label for provider da0s1 is msdosfs/CRUCIAL. >> Trying to mount root from ufs:/dev/md0 >> GEOM_LABEL: Label msdosfs/CRUCIAL removed. >> GEOM_LABEL: Label for provider da0s1 is msdosfs/CRUCIAL. >> GEOM_LABEL: Label msdosfs/CRUCIAL removed. >> >> ####################################################################### >> Here is the NetBSD dmesg: >> >> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, >> 2006, 2007 >> The NetBSD Foundation, Inc. All rights reserved. >> Copyright (c) 1982, 1986, 1989, 1991, 1993 >> The Regents of the University of California. All rights reserved. >> >> NetBSD 4.0 (GENERIC) #0: Sat Dec 15 22:25:31 PST 2007 >> >> builds@wb28:/home/builds/ab/netbsd-4-0-RELEASE/amd64/200712160005Z-obj/home/builds/ab/netbsd-4-0-RELEASE/src/sys/arch/amd64/compile/GENERIC >> total memory = 3967 MB >> avail memory = 3815 MB >> timecounter: Timecounters tick every 10.000 msec >> timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 >> mainbus0 (root) >> cpu0 at mainbus0: apid 0 (boot processor) >> cpu0: AMD Turion(tm) 64 X2 Mobile Technology TL-64, 2195.04 MHz >> cpu0: features: >> ffdbfbff >> cpu0: features: ffdbfbff >> cpu0: features: ffdbfbff >> cpu0: features2: 2001 >> cpu0: I-cache 64 KB 64B/line 2-way, D-cache 64 KB 64B/line 2-way >> cpu0: L2 cache 512 KB 64B/line 16-way >> cpu0: ITLB 32 4 KB entries fully associative, 8 4 MB entries fully >> associative >> cpu0: DTLB 32 4 KB entries fully associative, 8 4 MB entries fully >> associative >> cpu0: AMD Power Management features: 7f >> cpu0: AMD PowerNow! Technology 2200 MHz >> cpu0: available frequencies (Mhz): 800 1600 1800 2000 2200 >> cpu0: calibrating local timer >> cpu0: apic clock running at 199 MHz >> cpu0: 8 page colors >> cpu1 at mainbus0: apid 1 (application processor) >> cpu1: not started >> ioapic0 at mainbus0 apid 2 (I/O APIC) >> ioapic0: pa 0xfec00000, version 21, 24 pins >> ioapic0: misconfigured as apic 0 >> ioapic0: remapped to apic 2 >> acpi0 at mainbus0: Advanced Configuration and Power Interface >> acpi0: using Intel ACPI CA subsystem version 20060217 >> acpi0: X/RSDT: OemId , AslId >> ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A1 (name not of >> form >> _Lxx or _Exx) [20060217] >> ACPI Error (evgpeblk-0394): Unknown GPE method type: C28C (name not of >> form >> _Lxx or _Exx) [20060217] >> ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A2 (name not of >> form >> _Lxx or _Exx) [20060217] >> ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A3 (name not of >> form >> _Lxx or _Exx) [20060217] >> ACPI Error (evgpeblk-0394): Unknown GPE method type: C253 (name not of >> form >> _Lxx or _Exx) [20060217] >> ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A4 (name not of >> form >> _Lxx or _Exx) [20060217] >> ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A5 (name not of >> form >> _Lxx or _Exx) [20060217] >> ACPI Error (evgpeblk-0394): Unknown GPE method type: C262 (name not of >> form >> _Lxx or _Exx) [20060217] >> acpi0: SCI interrupting at int 9 >> acpi0: fixed-feature power button present >> timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000 >> ACPI-Fast 32-bit timer >> mpacpi: could not get bus number, assuming bus 0 >> ACPI Object Type 'Processor' (0x0c) at acpi0 not configured >> ACPI Object Type 'Processor' (0x0c) at acpi0 not configured >> PNP0C01 [System Board] at acpi0 not configured >> PNP0A03 [PCI/PCI-X Host Bridge] at acpi0 not configured >> ACPI Object Type 'Power' (0x0b) at acpi0 not configured >> acpiec0 at acpi0 (PNP0C09): ACPI Embedded Controller >> acpiec0: io 0x62,0x66 >> PNP0A06 [Generic Container Device] at acpi0 not configured >> ACPI Object Type 'Power' (0x0b) at acpi0 not configured >> ACPI Object Type 'Power' (0x0b) at acpi0 not configured >> IFX0102 at acpi0 not configured >> PNP0C04 [Math Coprocessor] at acpi0 not configured >> attimer1 at acpi0 (PNP0100): AT Timer >> attimer1: io 0x40-0x43 irq 0 >> PNP0200 [AT DMA Controller] at acpi0 not configured >> pcppi1 at acpi0 (PNP0800) >> pcppi1: io 0x61 >> pcppi1: children must have an explicit unit >> midi0 at pcppi1: PC speaker (CPU-intensive output) >> sysbeep0 at pcppi1 >> PNP0B00 [AT Real-Time Clock] at acpi0 not configured >> pckbc1 at acpi0 (PNP0303): kbd port >> pckbc1: io 0x60,0x64 irq 1 >> pckbc2 at acpi0 (SYN0131): aux port >> pckbc2: irq 12 >> ACPI Object Type 'Power' (0x0b) at acpi0 not configured >> PNP0000 [AT Interrupt Controller] at acpi0 not configured >> PNP0C02 [Plug and Play motherboard register resources] at acpi0 not >> configured >> HPQ0004 at acpi0 not configured >> PNP0C02 [Plug and Play motherboard register resources] at acpi0 not >> configured >> HPQ0006 at acpi0 not configured >> acpibat0 at acpi0 (PNP0C0A-1): ACPI Battery (Control Method) >> acpibat1 at acpi0 (PNP0C0A-2): ACPI Battery (Control Method) >> acpiacad0 at acpi0 (ACPI0003): ACPI AC Adapter >> acpibut0 at acpi0 (PNP0C0E): ACPI Sleep Button >> acpilid0 at acpi0 (PNP0C0D): ACPI Lid Switch >> PNP0C14 at acpi0 not configured >> PNP0C02 [Plug and Play motherboard register resources] at acpi0 not >> configured >> ACPI Object Type 'Power' (0x0b) at acpi0 not configured >> ACPI Object Type 'Power' (0x0b) at acpi0 not configured >> ACPI Object Type 'Power' (0x0b) at acpi0 not configured >> ACPI Object Type 'Power' (0x0b) at acpi0 not configured >> PNP0C0B [ACPI Fan] at acpi0 not configured >> PNP0C0B [ACPI Fan] at acpi0 not configured >> PNP0C0B [ACPI Fan] at acpi0 not configured >> PNP0C0B [ACPI Fan] at acpi0 not configured >> acpitz0 at acpi0: ACPI Thermal Zone >> acpitz0: unable to get polling interval; using default of 30.0s >> acpitz0: active cooling level 0: 70.0C >> acpitz0: active cooling level 1: 60.0C >> acpitz0: active cooling level 2: 50.0C >> acpitz0: active cooling level 3: 40.0C >> acpitz0: critical 105.0C passive 38.0C >> pcppi1: attached to attimer1 >> pckbd0 at pckbc1 (kbd slot) >> pckbc1: using irq 1 for kbd slot >> wskbd0 at pckbd0: console keyboard >> pms0 at pckbc1 (aux slot) >> pms0: Synaptics touchpad version 6.2 >> pms0: Palm detect, Multi-finger >> pckbc1: using irq 12 for aux slot >> wsmouse0 at pms0 mux 0 >> pci0 at mainbus0 bus 0: configuration mode 1 >> pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok >> pchb0 at pci0 dev 0 function 0 >> pchb0: ATI Technologies product 0x7910 (rev. 0x00) >> ppb0 at pci0 dev 1 function 0: ATI Technologies product 0x7912 (rev. >> 0x00) >> pci1 at ppb0 bus 1 >> pci1: i/o space, memory space enabled >> vga0 at pci1 dev 5 function 0: ATI Technologies product 0x791f (rev. >> 0x00) >> wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation), using >> wskbd0 >> wsmux1: connecting to wsdisplay0 >> ppb1 at pci0 dev 4 function 0: ATI Technologies product 0x7914 (rev. >> 0x00) >> pci2 at ppb1 bus 16 >> pci2: i/o space, memory space enabled, rd/line, wr/inv ok >> bge0 at pci2 dev 0 function 0: Broadcom BCM5787M Gigabit Ethernet >> bge0: interrupting at ioapic0 pin 16 (irq 10) >> bge0: ASIC BCM5754/5787 A2 (0xb002), Ethernet address 00:1f:29:85:3d:63 >> bge0: setting short Tx thresholds >> brgphy0 at bge0 phy 1: BCM5754/5787 1000BASE-T media interface, rev. 0 >> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-FDX, auto >> ppb2 at pci0 dev 5 function 0: ATI Technologies product 0x7915 (rev. >> 0x00) >> pci3 at ppb2 bus 32 >> pci3: i/o space, memory space enabled, rd/line, wr/inv ok >> ppb3 at pci0 dev 6 function 0: ATI Technologies product 0x7916 (rev. >> 0x00) >> pci4 at ppb3 bus 48 >> pci4: i/o space, memory space enabled, rd/line, wr/inv ok >> Broadcom BCM4312 (miscellaneous network, revision 0x02) at pci4 dev 0 >> function >> 0 not configured >> ixpide0 at pci0 dev 18 function 0 >> ixpide0: ATI Technologies IXP IDE Controller (rev. 0x00) >> ixpide0: bus-master DMA support present >> ixpide0: primary channel configured to native-PCI mode >> ixpide0: using ioapic0 pin 16 (irq 10) for native-PCI interrupt >> atabus0 at ixpide0 channel 0 >> ixpide0: secondary channel configured to native-PCI mode >> atabus1 at ixpide0 channel 1 >> ohci0 at pci0 dev 19 function 0: ATI Technologies product 0x4387 (rev. >> 0x00) >> ohci0: interrupting at ioapic0 pin 23 (irq 11) >> ohci0: OHCI version 1.0, legacy support >> usb0 at ohci0: USB revision 1.0 >> uhub0 at usb0 >> uhub0: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 >> uhub0: 2 ports with 2 removable, self powered >> ohci1 at pci0 dev 19 function 1: ATI Technologies product 0x4388 (rev. >> 0x00) >> ohci1: interrupting at ioapic0 pin 17 (irq 5) >> ohci1: OHCI version 1.0, legacy support >> usb1 at ohci1: USB revision 1.0 >> uhub1 at usb1 >> uhub1: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 >> uhub1: 2 ports with 2 removable, self powered >> ohci2 at pci0 dev 19 function 2: ATI Technologies product 0x4389 (rev. >> 0x00) >> ohci2: interrupting at ioapic0 pin 17 (irq 5) >> ohci2: OHCI version 1.0, legacy support >> usb2 at ohci2: USB revision 1.0 >> uhub2 at usb2 >> uhub2: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 >> uhub2: 2 ports with 2 removable, self powered >> ohci3 at pci0 dev 19 function 3: ATI Technologies product 0x438a (rev. >> 0x00) >> ohci3: interrupting at ioapic0 pin 17 (irq 5) >> ohci3: OHCI version 1.0, legacy support >> usb3 at ohci3: USB revision 1.0 >> uhub3 at usb3 >> uhub3: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 >> uhub3: 2 ports with 2 removable, self powered >> ohci4 at pci0 dev 19 function 4: ATI Technologies product 0x438b (rev. >> 0x00) >> ohci4: interrupting at ioapic0 pin 17 (irq 5) >> ohci4: OHCI version 1.0, legacy support >> usb4 at ohci4: USB revision 1.0 >> uhub4 at usb4 >> uhub4: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 >> uhub4: 2 ports with 2 removable, self powered >> ehci0 at pci0 dev 19 function 5: ATI Technologies product 0x4386 (rev. >> 0x00) >> ehci0: interrupting at ioapic0 pin 23 (irq 11) >> ehci0: BIOS has given up ownership >> ehci0: EHCI version 1.0 >> ehci0: companion controllers, 2 ports each: ohci0 ohci1 ohci2 ohci3 ohci4 >> usb5 at ehci0: USB revision 2.0 >> uhub5 at usb5 >> uhub5: ATI Technologies EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 >> uhub5: 10 ports with 10 removable, self powered >> ATI Technologies product 0x4385 (SMBus serial bus, revision 0x14) at pci0 >> dev >> 20 function 0 not configured >> ixpide1 at pci0 dev 20 function 1 >> ixpide1: ATI Technologies IXP IDE Controller (rev. 0x00) >> ixpide1: bus-master DMA support present >> ixpide1: primary channel configured to compatibility mode >> ixpide1: primary channel interrupting at ioapic0 pin 14 (irq 14) >> atabus2 at ixpide1 channel 0 >> ixpide1: secondary channel wired to compatibility mode >> ixpide1: secondary channel interrupting at ioapic0 pin 15 (irq 15) >> atabus3 at ixpide1 channel 1 >> azalia0 at pci0 dev 20 function 2: Generic High Definition Audio >> Controller >> azalia0: interrupting at ioapic0 pin 16 (irq 10) >> azalia0: host: 0x1002/0x4383 (rev. 0) >> azalia0: host: High Definition Audio rev. 1.0 >> pcib0 at pci0 dev 20 function 3 >> pcib0: ATI Technologies product 0x438d (rev. 0x00) >> ppb4 at pci0 dev 20 function 4: ATI Technologies product 0x4384 (rev. >> 0x00) >> pci5 at ppb4 bus 2 >> pci5: i/o space, memory space enabled >> cbb0 at pci5 dev 4 function 0: Ricoh 5C476 PCI-CardBus bridge (rev. 0xb6) >> fwohci0 at pci5 dev 4 function 1: Ricoh product 0x0832 (rev. 0x02) >> fwohci0: interrupting at ioapic0 pin 21 (irq 5) >> fwohci0: OHCI version 1.10 (ROM=0) >> fwohci0: No. of Isochronous channels is 4. >> fwohci0: EUI64 00:02:3f:99:29:21:1d:10 >> fwohci0: Phy 1394a available S400, 1 ports. >> fwohci0: Link S400, max_rec 2048 bytes. >> ieee1394if0 at fwohci0: IEEE1394 bus >> fwip0 at ieee1394if0: IP over IEEE1394 >> fwohci0: Initiate bus reset >> cbb0: interrupting at ioapic0 pin 20 (irq 10) >> cardslot0 at cbb0 slot 0 flags 0 >> cardbus0 at cardslot0: bus 3 >> pcmcia0 at cardslot0 >> pchb1 at pci0 dev 24 function 0 >> pchb1: Advanced Micro Devices AMD64 HyperTransport configuration (rev. >> 0x00) >> pchb2 at pci0 dev 24 function 1 >> pchb2: Advanced Micro Devices AMD64 Address Map configuration (rev. 0x00) >> pchb3 at pci0 dev 24 function 2 >> pchb3: Advanced Micro Devices AMD64 DRAM configuration (rev. 0x00) >> pchb4 at pci0 dev 24 function 3 >> pchb4: Advanced Micro Devices AMD64 Miscellaneous configuration (rev. >> 0x00) >> isa0 at pcib0 >> ioapic0: enabling >> WARNING: Callback scheduled before sysmon task queue thread present. >> fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode >> ieee1394if0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) >> ieee1394if0: bus manager 0 (me) >> timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0 >> azalia0: codec[0]: Analog Devices AD1981HD (rev. 2.0) >> azalia0: codec[0]: High Definition Audio rev. 1.0 >> azalia0: playback: max channels=2, encodings=1 >> azalia0: playback: PCM >> formats=e007f<24bit,20bit,16bit,48kHz,44.1kHz,32kHz,22.05kHz,16kHz,11.025kHz,8kHz> >> azalia0: recording: max channels=2, encodings=1 >> azalia0: recording: PCM >> formats=6007f<20bit,16bit,48kHz,44.1kHz,32kHz,22.05kHz,16kHz,11.025kHz,8kHz> >> azalia0: codec[1]: 0x11c1/0x1040 (rev. 2.0) >> azalia0: codec[1]: High Definition Audio rev. 1.0 >> azalia0: codec[1]: No support for modem function groups >> azalia0: codec[1] has no audio function groups >> audio0 at azalia0: full duplex, independent >> Kernelized RAIDframe activated >> acpibat0: battery info: Hewlett-Packard, LIon, Primary, 48204 2008/04/13 >> ugen0 at uhub2 port 1 >> ugen0: AuthenTec Fingerprint Sensor, rev 1.10/6.23, addr 2 >> wd0 at atabus0 drive 0: >> wd0: drive supports 16-sector PIO transfers, LBA48 addressing >> wd0: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 >> sectors >> wd0: 32-bit data port >> wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) >> wd0(ixpide0:0:0): using PIO mode 4, Ultra-DMA mode 5 (Ultra/100) (using >> DMA) >> atapibus0 at atabus2: 2 targets >> cd0 at atapibus0 drive 0: >> cdrom >> removable >> cd0: 32-bit data port >> cd0: drive supports PIO mode 4, DMA mode 2 >> cd0(ixpide1:0:0): using PIO mode 4, DMA mode 2 (using DMA) >> boot device: wd0 >> root on wd0a dumps on wd0b >> root file system type: ffs >> WARNING: clock gained 7 days >> WARNING: CHECK AND RESET THE DATE! >> wsdisplay0: screen 1 added (80x25, vt100 emulation) >> wsdisplay0: screen 2 added (80x25, vt100 emulation) >> wsdisplay0: screen 3 added (80x25, vt100 emulation) >> wsdisplay0: screen 4 added (80x25, vt100 emulation) >> >> >> >> >> >> >> On Sunday 11 May 2008 07:49:47 you wrote: >> > On Sat, 2008-05-10 at 14:33 -0400, Coleman Kane wrote: >> > > On Sat, 2008-05-10 at 12:13 -0500, rar102@ra.msstate.edu wrote: >> > > > Quoting Coleman Kane : >> > > > >> > > > Yes!!! thank you. Unfortunately, I don't have access to another >> amd64 >> > > > box to try your patch. Sorry. But, I will look at the dmesg and >> send >> > > > it to you. >> > > >> > > Excellent. A dmesg will be very helpful for me to write a patch from, >> as >> > > it will allow me to see if it is or is not the sound driver >> overlapping >> > > memory in your case. I suspect that the BIOS images are so similar >> that >> > > you probably even have almost the same bios-chosen memory regions on >> > > your system. >> > >> > If you're having difficulty getting a dmesg, you might want to try >> > booting off the LiveFS disc with a USB flash drive plugged in. You can >> > then mount the flash drive (which should be detected as SCSI) and write >> > the dmesg output there. >> > >> > > > > RAR, >> > > > > >> > > > > You are in luck! Well, actually I have good news and I have bad >> news. >> > > > > The good news is that I have nearly the same (6715b) laptop and >> > > > > experienced similar problems when getting FreeBSD onto it. After >> some >> > > > > work, I've been able to use FreeBSD reliably on the system. >> > > > > >> > > > > The bad news is that you probably have an overlap of PCI memory >> > > > > ranges between the SATA controller and another device in the >> system >> > > > > (likely the audio controller). >> > > > > >> > > > > I put up a page describing the problem here: >> > > > >> > > > >> http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_ >> > > >hp_compaq_6715b_working >> > > > >> > > > > Specifically, read this section: >> > > > >> > > > >> http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#the_onboard_ >> > > >ati_sb600_hda_audio_controller >> > > > >> > > > > Give me the weekend, and I will post a 7.0-RELEASE CD with the >> patch >> > > > > in it. I figured that I should have done it a while ago. Oh well. >> > > > > >> > > > > While you are at it, see if you can use Scroll-Lock and the >> up/down >> > > > > keys to read the kernel messages. See if you can find the atapci0 >> > > > > probe line for your SATA controller (AHCI), as well as the line >> for >> > > > > your pcm0 device and send them back to me. I can add your info to >> my >> > > > > webpage to help others. >> > > > > >> > > > > It will look like this: >> > > > > atapci0: port >> > > > > >> 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f >> > > > > mem 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 >> > > > > ... >> > > > > pcm0: mem >> > > > > 0xd0608000-0xd060bfff irq 16 at device 20.2 on pci0 >> > > > > >> > > > > You'll notice the "mem" resource for the audio controller is >> > > > > 0xd0608000-0xd060bff, and the "mem" resource for the SATA >> controller >> > > > > is 0xd0609000-0xd06093ff. The SATA controller's "mem" resource is >> > > > > completely covered by this audio controller. >> > > > > >> > > > > If you happen to have access to another machine for building your >> own >> > > > > releases, you can try my patch and build them from it. >> > > > > >> > > > > -- >> > > > > Coleman Kane > > > > -- View this message in context: http://www.nabble.com/compaq-6515b-turion-x2-laptop-tp17165100p17245805.html Sent from the freebsd-arch mailing list archive at Nabble.com. From jhb at freebsd.org Thu May 15 12:07:52 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu May 15 12:07:57 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080514093223.GN18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080513093734.GF18958@deviant.kiev.zoral.com.ua> <20080514093223.GN18958@deviant.kiev.zoral.com.ua> Message-ID: <200805150730.08418.jhb@freebsd.org> On Wednesday 14 May 2008 05:32:23 am Kostik Belousov wrote: > On Tue, May 13, 2008 at 12:37:34PM +0300, Kostik Belousov wrote: > > On Mon, May 12, 2008 at 10:03:14AM -1000, Jeff Roberson wrote: > > > > > > On Mon, 12 May 2008, Kostik Belousov wrote: > > > > > > >On Sun, May 11, 2008 at 03:40:14PM -1000, Jeff Roberson wrote: > > > >> > > > >>On Sun, 11 May 2008, Kostik Belousov wrote: > > > >> > > > >>>On Sun, May 11, 2008 at 02:50:30PM +0300, Kostik Belousov wrote: > > > >>>>On Sat, May 10, 2008 at 09:53:12PM -1000, Jeff Roberson wrote: > > > >>>>>On Sun, 4 May 2008, Kostik Belousov wrote: > > > >>>>> > > > >>>>>>Since the review for the clone-at-open patch (fdclone) posted some > > > >>>>>>time > > > >>>>>>ago > > > >>>>>>mostly says that it would be better to implement per-file private data > > > >>>>>>instead, I produced the patch along this line, > > > >>>>>> > > > >>>>>>The patch does not change the cdevsw ABI, instead, three new functions > > > >>>>>>nt devfs_get_cdevpriv(void **datap); > > > >>>>>>int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > > > >>>>>>void devfs_clear_cdevpriv(void); > > > >>>>>>are provided for manipulation of the per-file private data. > > > >>>>>> > > > >>>>>>devfs_set_cdevpriv assigns the priv as private data for the file > > > >>>>>>descriptor > > > >>>>>>which is used to initiate currently performed driver operation. dtr > > > >>>>>>is the function that will be called when either the last refernce to > > > >>>>>>the file goes away or devfs_clear_cdevpriv is called. > > > >>>>>> > > > >>>>>>devfs_get_cdevpriv is the obvious accessor. > > > >>>>>> > > > >>>>>>devfs_clear_cdevpriv allows to clear the private data for the still > > > >>>>>>open file. > > > >>>>>> > > > >>>>>>The synchronization of the cdev data and file private data is left > > > >>>>>>to the driver code, I did not found any generic helper mechanism that > > > >>>>>>could be useful there. > > > >>>>>> > > > >>>>>>Patch: > > > >>>>>>http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > > >>>>>> > > > >>>>>>Dumb driver that shows the basic usage of the proposed KPI: > > > >>>>>>http://people.freebsd.org/~kib/misc/fpclone.c > > > >>>>>> > > > >>>>>>Previous version of the patch was tested by Peter Holm. > > > >>>>>> > > > >>>>> > > > >>>>>Hi Kostik, > > > >>>>> > > > >>>>>Are these per-instances structures intended to be used by anything > > > >>>>>other > > > >>>>>than devices? If not can we make them a union with the DTYPE_VNODE > > > >>>>>fields to save space? > > > >>>>> > > > >>>>>Thanks, > > > >>>>>Jeff > > > >>>> > > > >>>>The current version of the patch is at > > > >>>>http://people.freebsd.org/~kib/misc/fdpriv.3.patch > > > >>>> > > > >>>>Per insistence of John Baldwin and request of Eric Anholt, the > > > >>>>destructors > > > >>>>are called now when either file is last closed, or the device is > > > >>>>destroyed. > > > >>>>This versions adds only one pointer to the struct file. > > > >>>> > > > >>>>Jeff, would you, please, explicitely specify what field you propose to > > > >>>>union with the f_cdevpriv ? > > > >> > > > >>f_nextoff and f_seqcount are only used if vn_read() and vn_write() are > > > >>used. They do not apply to any other descriptors. > > > >I use the f_cdevpriv != NULL as an indicator for the necessity to enter > > > >the cdevpriv code, in particular, locking the cdevpriv_mtx, that would > > > >otherwise needed to be entered at each last close. I think that one > > > >pointer for the struct file is not too big cost, do you agree ? > > > > > > No, it's not a big cost, however if it is possible to avoid that is best. > > > > > > Can you not check the type before checking f_cdevpriv? Should we not only > > > be checking cdevpriv in contexts where we know that it is not a vnode? > > > > I am sorry, my english may be not enough, so I may interpret your > > proposal mistakenly. I read it as a suggestion to check the file type > > before accessing the f_cdevpriv. > > > > The problem with the f_cdevpriv exists only at the _fdrop(). There, we > > have a file of f_type == DTYPE_VNODE both for devfs and normal files. > > I cannot check the f_vnode since the vnode may be reclaimed. The only > > differentiator is the f_ops, that is devfs_ops_f for devfs file, and > > vnops for the normal file during the file lifetime. Unfortunately, > > f_ops is reset to the badfileops by vn_closefile before the _fdrop() is > > getting called. > > > > Reserving the flag in the f_flag looks not good due to interaction with > > the userspace. > > > > I do not want the callback to be called before the d_close() driver method > > gets a chance to clean the data. > > So, I cannot implement overlay of the cdevpriv over the seqaccess data > without some additional flag. On the other hand, use of 2 bytes for the > f_type is overkill when the range of the types is [1,8]. I divided it > to two one-byte fields, and new field is used for filetype-specific > flags. > > http://people.freebsd.org/~kib/misc/fdpriv.4.patch > shall give the same size of the struct file while not causing unconditional > acquire of the cdevpriv_mtx on the last file close. > > Jeff, do you agree with the proposed vivisection of the f_type ? I will > ask Peter to retest the patch then. I would rather add the new pointer to struct file and avoid breaking the ABI of fstat. That is, I would like this patch to be MFCable, but you can't MFC this w/o breaking the ABI of struct file since fstat(1) will be reading the full short to get the DTYPE. -- John Baldwin From kostikbel at gmail.com Thu May 15 12:31:03 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu May 15 12:31:08 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <200805150730.08418.jhb@freebsd.org> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080513093734.GF18958@deviant.kiev.zoral.com.ua> <20080514093223.GN18958@deviant.kiev.zoral.com.ua> <200805150730.08418.jhb@freebsd.org> Message-ID: <20080515123055.GY18958@deviant.kiev.zoral.com.ua> On Thu, May 15, 2008 at 07:30:07AM -0400, John Baldwin wrote: > On Wednesday 14 May 2008 05:32:23 am Kostik Belousov wrote: > > So, I cannot implement overlay of the cdevpriv over the seqaccess data > > without some additional flag. On the other hand, use of 2 bytes for the > > f_type is overkill when the range of the types is [1,8]. I divided it > > to two one-byte fields, and new field is used for filetype-specific > > flags. > > > > http://people.freebsd.org/~kib/misc/fdpriv.4.patch > > shall give the same size of the struct file while not causing unconditional > > acquire of the cdevpriv_mtx on the last file close. > > > > Jeff, do you agree with the proposed vivisection of the f_type ? I will > > ask Peter to retest the patch then. > > I would rather add the new pointer to struct file and avoid breaking the ABI > of fstat. That is, I would like this patch to be MFCable, but you can't MFC > this w/o breaking the ABI of struct file since fstat(1) will be reading the > full short to get the DTYPE. Oh, I thought that fstat uses struct xfile, at least for live systems. I considered to introduce new f_type value for devfs files; the DTYPE_VNODE is not a complete truth due to custom f_ops. But DTYPE_VNODE is special-cased in enough locations to make this much less preferrable then another pointer. -------------- 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-arch/attachments/20080515/34135fee/attachment.pgp From delphij at delphij.net Fri May 16 05:19:06 2008 From: delphij at delphij.net (Xin LI) Date: Fri May 16 05:19:11 2008 Subject: A couple of bitwise operations Message-ID: <482D193D.2010802@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I find the DragonFly macros, __BIT, __BITS, __LOWEST_SET_BIT, __SHIFTOUT, __SHIFTIN and __SHIFTOUT_MASK useful. Any objection adding this as sys/sys/bitops.h? (These macros are found in NetBSD in sys/sys/cdefs.h and DragonFly as sys/sys/bitops.h) Cheers, - -- ** Help China's quake relief at http://www.redcross.org.cn/ |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkgtGTwACgkQi+vbBBjt66DYYACePxDc5HaOpQXoJVSfttjukSvp bsAAnR61/+vOEaHqVNZjiynQzksLmTix =X14I -----END PGP SIGNATURE----- -------------- next part -------------- /* * Copyright (c) 2004, 2005 David Young. All rights reserved. * * Programmed for NetBSD by David Young. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. The name of David Young may not be used to endorse or promote * products derived from this software without specific prior * written permission. * * THIS SOFTWARE IS PROVIDED BY David Young ``AS IS'' AND ANY * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL David * Young BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY * OF SUCH DAMAGE. * * $DragonFly: src/sys/sys/bitops.h,v 1.1 2007/10/14 04:15:17 sephe Exp $ * $FreeBSD$ */ #ifndef _SYS_BITOPS_H_ #define _SYS_BITOPS_H_ /* * __BIT(n): Return a bitmask with bit n set, where the least * significant bit is bit 0. * * __BITS(m, n): Return a bitmask with bits m through n, inclusive, * set. It does not matter whether m>n or m<=n. The * least significant bit is bit 0. * * A "bitfield" is a span of consecutive bits defined by a bitmask, * where 1s select the bits in the bitfield. __SHIFTIN, __SHIFTOUT, * and __SHIFTOUT_MASK help read and write bitfields from device * registers. * * __SHIFTIN(v, mask): Left-shift bits `v' into the bitfield * defined by `mask', and return them. No * side-effects. * * __SHIFTOUT(v, mask): Extract and return the bitfield selected * by `mask' from `v', right-shifting the * bits so that the rightmost selected bit * is at bit 0. No side-effects. * * __SHIFTOUT_MASK(mask): Right-shift the bits in `mask' so that * the rightmost non-zero bit is at bit * 0. This is useful for finding the * greatest unsigned value that a bitfield * can hold. No side-effects. Note that * __SHIFTOUT_MASK(m) = __SHIFTOUT(m, m). */ /* __BIT(n): nth bit, where __BIT(0) == 0x1. */ #define __BIT(__n) (((__n) == 32) ? 0 : ((uint32_t)1 << (__n))) /* __BITS(m, n): bits m through n, m < n. */ #define __BITS(__m, __n) \ ((__BIT(MAX((__m), (__n)) + 1) - 1) ^ (__BIT(MIN((__m), (__n))) - 1)) /* Find least significant bit that is set */ #define __LOWEST_SET_BIT(__mask) ((((__mask) - 1) & (__mask)) ^ (__mask)) #define __SHIFTOUT(__x, __mask) (((__x) & (__mask)) / __LOWEST_SET_BIT(__mask)) #define __SHIFTIN(__x, __mask) ((__x) * __LOWEST_SET_BIT(__mask)) #define __SHIFTOUT_MASK(__mask) __SHIFTOUT((__mask), (__mask)) #endif /* !_SYS_BITOPS_H_ */ From brde at optusnet.com.au Fri May 16 06:45:53 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Fri May 16 06:45:56 2008 Subject: A couple of bitwise operations In-Reply-To: <482D193D.2010802@delphij.net> References: <482D193D.2010802@delphij.net> Message-ID: <20080516163857.Y43605@delplex.bde.org> On Thu, 15 May 2008, Xin LI wrote: > I find the DragonFly macros, __BIT, __BITS, __LOWEST_SET_BIT, > __SHIFTOUT, __SHIFTIN and __SHIFTOUT_MASK useful. Any objection adding > this as sys/sys/bitops.h? > > (These macros are found in NetBSD in sys/sys/cdefs.h and DragonFly as > sys/sys/bitops.h) WHat's wrong with bitstring(3)(9undoc), except that it was invented here and doesn't have a style bug after every #define? Both have naming errors -- bitstring has too many unsafe macros whose name is in lower case, while bitops uses upper case even for safe macros. Bruce From eric at anholt.net Fri May 16 10:27:45 2008 From: eric at anholt.net (Eric Anholt) Date: Fri May 16 10:27:49 2008 Subject: Feature requests for open-source graphics In-Reply-To: <1210800676.2466.6.camel@localhost> References: <1210352688.2152.78.camel@localhost> <1210800676.2466.6.camel@localhost> Message-ID: <1210883909.96116.4.camel@localhost> On Wed, 2008-05-14 at 17:31 -0400, Coleman Kane wrote: > On Fri, 2008-05-09 at 10:04 -0700, Eric Anholt wrote: > > email message attachment, "Forwarded message - Re: Forward: Updated > > FreeBSD kernel feature requests (NVIDIA graphics)" > > > -------- Forwarded Message -------- > > > From: Eric Anholt > > > To: Marcel Moolenaar > > > Cc: John Baldwin , Coleman Kane > > > , Dag-Erling Sm?rgrav , Martin > > > Cracauer , gnn@freebsd.org, > > > developers@freebsd.org > > > Subject: Re: Forward: Updated FreeBSD kernel feature requests > > > (NVIDIA graphics) > > > Date: Thu, 08 May 2008 15:54:17 -0700 > > > Mailer: Evolution 2.22.0 FreeBSD GNOME Team Port > > > > > > On Wed, 2008-05-07 at 10:37 -0700, Marcel Moolenaar wrote: > > > > On May 7, 2008, at 8:29 AM, John Baldwin wrote: > > > > > > > > > Quite, and this has been covered several times already. In fact, > > > > > they engage > > > > > in several hacks to support Linux. Other OS's such as Solaris and > > > > > OS X have > > > > > cleaner interfaces for many of the things they wish to do. > > > > > > > > I think this is where I normally say that we need kernel drivers > > > > for graphics hardware. I'm not going to do that anymore; I've been > > > > stating the obvious too often already... > > > > > > It's OK, we're finally listening. By the end of the year, major Linux > > > distributions should be shipping "DRM modesetting" -- the DRM device > > > takes over your graphics card and manages memory, execution, and > > > suspend/resume. Your kernel console and X Server then sit on top of > > > that, submitting video mode setting and command execution requests to > > > the DRM. The chips I would expect to be supported by then are all > > > Intel, pre-r500 ATI at least, and a subset of nvidia through nouveau. > > > > > > What FreeBSD needs to do to keep up is implement the memory manager > > > part. I think I've got a reasonable design going that should take about > > > a month of reimplementing for the FreeBSD kernel. If someone wanted to > > > get us closer to doing that, > > > > > > git clone anongit.freedesktop.org:/git/mesa/drm > > > > > > and make everything but TTM (the *_HAVE_FENCE and *_HAVE_BUFFER defines) > > > work on -current. > > > > > > To see what we're working on for what we're calling the "graphics > > > execution manager" now (memory management plus caching management plus > > > plans for execution scheduling), > > > > > > git-remote add anholt people.freedesktop.org:~anholt/drm > > > git-fetch anholt > > > git-checkout anholt/drm-gem > > > > > > The interesting things we're needing from the kernel: > > > - Private storage associated with file descriptors > > > - Callback to driver on destruction of file descriptor > > > - Ability to allocate a swap-backed pile of memory > > > - Ability to pin pages from that object and get addresses for them to > > > stuff into the GTT. > > > - Ability to map pages in the kernel with the uncached bits set > > > (non-intel) > > > - Ability to map pages to userland with the uncached bits set > > > (non-intel, likely not required, but may come at a performance > > > cost). > > > > > > Interesting things we're considering needing from the kernel: > > > - Ability to create fds above 1024 from our driver, associated with our > > > own set of file operations (read/write/mmap/ioctl/close). > > > - Ability to look up those fds and get our private storage associated > > > with them. > > > > > > Down the line, likely to happen: > > > - Creating a filesystem exposing those objects we've been making fds > > > for. > > Eric, > > I mentioned earlier that I would get my local git repo's changes to the > mesa/drm tree available from fd.o up somewhere. I have them here: > * http://www.cokane.org/cgi-bin/gitweb.cgi?p=drm.git > > My custom branch is 'cokane-master' > The fd.o branch is tracked on 'fd-master' > > You can ignore the 'master' branch for now... I need to re-org my git a > bit. > > Right now, this gets my RS690 notebook to almost work with the > in-development radeonhd DRI code, but it causes Xorg to run in a > busyloop when I try using the xf86-video-ati driver with it. I did a run > at trying to get the vblank stuff ported over, but I got busy and > haven't touched it in a bit. I also tried to tweak anything else that > kept the radeon code from compiling under FreeBSD. > > If I have another set of eyes on this it might help me front-burner it > more often to get patches in here-and-there. I've tried shoving some bug > reports up to the DRI project, but they haven't been acted upon yet... Looks like your webserver is dead. Could you push your tree up on freefall or something so I can just ssh and grab it? -- Eric Anholt anholt@FreeBSD.org eric@anholt.net eric.anholt@intel.com -------------- 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-arch/attachments/20080516/a40e9921/attachment.pgp From cokane at FreeBSD.org Fri May 16 14:04:02 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Fri May 16 14:04:06 2008 Subject: Feature requests for open-source graphics (OT) In-Reply-To: <1210883909.96116.4.camel@localhost> References: <1210352688.2152.78.camel@localhost> <1210800676.2466.6.camel@localhost> <1210883909.96116.4.camel@localhost> Message-ID: <1210946605.2668.22.camel@localhost> On Thu, 2008-05-15 at 13:38 -0700, Eric Anholt wrote: > On Wed, 2008-05-14 at 17:31 -0400, Coleman Kane wrote: > > On Fri, 2008-05-09 at 10:04 -0700, Eric Anholt wrote: > > > email message attachment, "Forwarded message - Re: Forward: Updated > > > FreeBSD kernel feature requests (NVIDIA graphics)" > > > > -------- Forwarded Message -------- > > > > From: Eric Anholt > > > > To: Marcel Moolenaar > > > > Cc: John Baldwin , Coleman Kane > > > > , Dag-Erling Sm?rgrav , Martin > > > > Cracauer , gnn@freebsd.org, > > > > developers@freebsd.org > > > > Subject: Re: Forward: Updated FreeBSD kernel feature requests > > > > (NVIDIA graphics) > > > > Date: Thu, 08 May 2008 15:54:17 -0700 > > > > Mailer: Evolution 2.22.0 FreeBSD GNOME Team Port > > > > > > > > On Wed, 2008-05-07 at 10:37 -0700, Marcel Moolenaar wrote: > > > > > On May 7, 2008, at 8:29 AM, John Baldwin wrote: > > > > > > > > > > > Quite, and this has been covered several times already. In fact, > > > > > > they engage > > > > > > in several hacks to support Linux. Other OS's such as Solaris and > > > > > > OS X have > > > > > > cleaner interfaces for many of the things they wish to do. > > > > > > > > > > I think this is where I normally say that we need kernel drivers > > > > > for graphics hardware. I'm not going to do that anymore; I've been > > > > > stating the obvious too often already... > > > > > > > > It's OK, we're finally listening. By the end of the year, major Linux > > > > distributions should be shipping "DRM modesetting" -- the DRM device > > > > takes over your graphics card and manages memory, execution, and > > > > suspend/resume. Your kernel console and X Server then sit on top of > > > > that, submitting video mode setting and command execution requests to > > > > the DRM. The chips I would expect to be supported by then are all > > > > Intel, pre-r500 ATI at least, and a subset of nvidia through nouveau. > > > > > > > > What FreeBSD needs to do to keep up is implement the memory manager > > > > part. I think I've got a reasonable design going that should take about > > > > a month of reimplementing for the FreeBSD kernel. If someone wanted to > > > > get us closer to doing that, > > > > > > > > git clone anongit.freedesktop.org:/git/mesa/drm > > > > > > > > and make everything but TTM (the *_HAVE_FENCE and *_HAVE_BUFFER defines) > > > > work on -current. > > > > > > > > To see what we're working on for what we're calling the "graphics > > > > execution manager" now (memory management plus caching management plus > > > > plans for execution scheduling), > > > > > > > > git-remote add anholt people.freedesktop.org:~anholt/drm > > > > git-fetch anholt > > > > git-checkout anholt/drm-gem > > > > > > > > The interesting things we're needing from the kernel: > > > > - Private storage associated with file descriptors > > > > - Callback to driver on destruction of file descriptor > > > > - Ability to allocate a swap-backed pile of memory > > > > - Ability to pin pages from that object and get addresses for them to > > > > stuff into the GTT. > > > > - Ability to map pages in the kernel with the uncached bits set > > > > (non-intel) > > > > - Ability to map pages to userland with the uncached bits set > > > > (non-intel, likely not required, but may come at a performance > > > > cost). > > > > > > > > Interesting things we're considering needing from the kernel: > > > > - Ability to create fds above 1024 from our driver, associated with our > > > > own set of file operations (read/write/mmap/ioctl/close). > > > > - Ability to look up those fds and get our private storage associated > > > > with them. > > > > > > > > Down the line, likely to happen: > > > > - Creating a filesystem exposing those objects we've been making fds > > > > for. > > > > Eric, > > > > I mentioned earlier that I would get my local git repo's changes to the > > mesa/drm tree available from fd.o up somewhere. I have them here: > > * http://www.cokane.org/cgi-bin/gitweb.cgi?p=drm.git > > > > My custom branch is 'cokane-master' > > The fd.o branch is tracked on 'fd-master' > > > > You can ignore the 'master' branch for now... I need to re-org my git a > > bit. > > > > Right now, this gets my RS690 notebook to almost work with the > > in-development radeonhd DRI code, but it causes Xorg to run in a > > busyloop when I try using the xf86-video-ati driver with it. I did a run > > at trying to get the vblank stuff ported over, but I got busy and > > haven't touched it in a bit. I also tried to tweak anything else that > > kept the radeon code from compiling under FreeBSD. > > > > If I have another set of eyes on this it might help me front-burner it > > more often to get patches in here-and-there. I've tried shoving some bug > > reports up to the DRI project, but they haven't been acted upon yet... > > Looks like your webserver is dead. Could you push your tree up on > freefall or something so I can just ssh and grab it? > Yeah. Thanks to the brilliance of subsidized monopoly I got my traffic blocked suddenly without notice. I am in the process of hopping to an ISP that actually respects customer right of use of service (I'm not doing anything illegal). I'll shove the stuff up to freefall in a bit and get back to you... Rant warning (look away if you don't want a rant about the "competitive" US ISP market): Had Comcast, and they decided that it is a better use of customer money to spend it on expensive half-baked filtering systems that make the service garbage even for non-bittorrent users (as well as preventing me from getting fbsd/linux ISOs with bittorrent), as well as threatening to disconnect all of my service if I didn't stop serving my personal website and personal email on my personal Internet connection. Moved to Verizon who said that they don't block. Turns out that they block port 80 but just don't tell anybody. If they are so ashamed to admit this block, then they shouldn't do it (IMHO). Otherwise, it should be clearly stated in the TOS agreement, and conveyed to the salespeople (who told me that I could run my server on their connection). The upper-level technicians' reason was that they specifically want to prevent residential lines from being webservers. No block on public mailservers, not even a block on public Windows filesharing ports (yes!! They are open!!). Their business class service also apparently blocks port 80 unless you get the highest-level static-IP service. So I am going with one of the independent DSL operators that provide service over Verizon's lines. Both Comcast and Verizon insist that these policies are exercised by all major providers, but this is not true. Time Warner cable doesn't do this, and neither does Cincinnati Bell (last remaining non-RBOC in the lower 48). Additionally, AT&T actually has a section dedicated to expressing the customers' rights. They specifically bar hosting a server only in the cases of dial-up accounts. Server usage appears to be allowed by them for their DSL service (but I've never used AT&T service before). One of the nice perks of DSL regulation is that the line controllers don't have a monopoly on the lines themselves, which are required to be open to other ISPs who are willing to invest in the DSL system. So I actually have a choice of about 10 companies that I can have DSL from. Almost all of my alternatives seem to provide a line that endorses running a server on it. So I chose dslextreme.com, which seems like a pretty decent vendor, and provides a line that can be served from. -- Coleman Kane -------------- 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-arch/attachments/20080516/434c78c2/attachment.pgp From gary.jennejohn at freenet.de Fri May 16 15:00:05 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Fri May 16 15:00:14 2008 Subject: Feature requests for open-source graphics (OT) In-Reply-To: <1210946605.2668.22.camel@localhost> References: <1210352688.2152.78.camel@localhost> <1210800676.2466.6.camel@localhost> <1210883909.96116.4.camel@localhost> <1210946605.2668.22.camel@localhost> Message-ID: <20080516170003.1734cb29@peedub.jennejohn.org> On Fri, 16 May 2008 10:03:25 -0400 Coleman Kane wrote: [snip most of rant] > One of the nice perks of DSL regulation is that the line controllers > don't have a monopoly on the lines themselves, which are required to be > open to other ISPs who are willing to invest in the DSL system. So I > actually have a choice of about 10 companies that I can have DSL from. > Almost all of my alternatives seem to provide a line that endorses > running a server on it. So I chose dslextreme.com, which seems like a > pretty decent vendor, and provides a line that can be served from. > Even more OT. Sounds like the good ol' US of A is totally fubar in this regard. Here in Germany every fly-by-night DSL provider offers a domain name and home page hosting because _everybody else_ does too! It's hard to come by a static IP though. --- Gary Jennejohn From olli at lurza.secnetix.de Fri May 16 15:47:17 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri May 16 15:47:22 2008 Subject: Feature requests for open-source graphics (OT) In-Reply-To: <20080516170003.1734cb29@peedub.jennejohn.org> Message-ID: <200805161547.m4GFlEZr045076@lurza.secnetix.de> Gary Jennejohn wrote: > Even more OT. Maybe we should redirect this to -chat? I set Reply-To accordingly. > Sounds like the good ol' US of A is totally fubar in this regard. Here > in Germany every fly-by-night DSL provider offers a domain name and home > page hosting because _everybody else_ does too! It's hard to come by a > static IP though. It's not hard, it's just expensive, depending on your ISP. For example, M-net (Bavaria) charges EUR 14.90 (~ USD 22) per Month for a static IP. Right now they have a special 50% offer, so it's only EUR 7.45 per month if you sign up with them now. On the other hand, for most private stuff a dynamic IP with something like dyndns service should be sufficient, I think. That's what i do. I'm not running any public services on my home machine, though, but the dyndns name enables me to ssh into it from somewhere else. Personally I decided to rent a root server for EUR 50 (from Hetzner) which includes a /29 with six static IPs. It's shared with three friends, so each of us pays only EUR 12,50 which is cheaper than a static IP with M-net, and it has a lot more bandwidth than my DSL box at home. Of course I replaced the Linux installation on the root server with FreeBSD. ;-) Best regards Oliver PS: I'm not affiliated with any of the above companies, and I don't benefit from mentioning them. I'm just a satisfied customer. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd We're sysadmins. To us, data is a protocol-overhead. From cokane at FreeBSD.org Fri May 16 16:13:43 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Fri May 16 16:13:47 2008 Subject: Feature requests for open-source graphics In-Reply-To: <1210883909.96116.4.camel@localhost> References: <1210352688.2152.78.camel@localhost> <1210800676.2466.6.camel@localhost> <1210883909.96116.4.camel@localhost> Message-ID: <1210954371.2668.24.camel@localhost> On Thu, 2008-05-15 at 13:38 -0700, Eric Anholt wrote: > On Wed, 2008-05-14 at 17:31 -0400, Coleman Kane wrote: > > On Fri, 2008-05-09 at 10:04 -0700, Eric Anholt wrote: > > > email message attachment, "Forwarded message - Re: Forward: Updated > > > FreeBSD kernel feature requests (NVIDIA graphics)" > > > > -------- Forwarded Message -------- > > > > From: Eric Anholt > > > > To: Marcel Moolenaar > > > > Cc: John Baldwin , Coleman Kane > > > > , Dag-Erling Sm?rgrav , Martin > > > > Cracauer , gnn@freebsd.org, > > > > developers@freebsd.org > > > > Subject: Re: Forward: Updated FreeBSD kernel feature requests > > > > (NVIDIA graphics) > > > > Date: Thu, 08 May 2008 15:54:17 -0700 > > > > Mailer: Evolution 2.22.0 FreeBSD GNOME Team Port > > > > > > > > On Wed, 2008-05-07 at 10:37 -0700, Marcel Moolenaar wrote: > > > > > On May 7, 2008, at 8:29 AM, John Baldwin wrote: > > > > > > > > > > > Quite, and this has been covered several times already. In fact, > > > > > > they engage > > > > > > in several hacks to support Linux. Other OS's such as Solaris and > > > > > > OS X have > > > > > > cleaner interfaces for many of the things they wish to do. > > > > > > > > > > I think this is where I normally say that we need kernel drivers > > > > > for graphics hardware. I'm not going to do that anymore; I've been > > > > > stating the obvious too often already... > > > > > > > > It's OK, we're finally listening. By the end of the year, major Linux > > > > distributions should be shipping "DRM modesetting" -- the DRM device > > > > takes over your graphics card and manages memory, execution, and > > > > suspend/resume. Your kernel console and X Server then sit on top of > > > > that, submitting video mode setting and command execution requests to > > > > the DRM. The chips I would expect to be supported by then are all > > > > Intel, pre-r500 ATI at least, and a subset of nvidia through nouveau. > > > > > > > > What FreeBSD needs to do to keep up is implement the memory manager > > > > part. I think I've got a reasonable design going that should take about > > > > a month of reimplementing for the FreeBSD kernel. If someone wanted to > > > > get us closer to doing that, > > > > > > > > git clone anongit.freedesktop.org:/git/mesa/drm > > > > > > > > and make everything but TTM (the *_HAVE_FENCE and *_HAVE_BUFFER defines) > > > > work on -current. > > > > > > > > To see what we're working on for what we're calling the "graphics > > > > execution manager" now (memory management plus caching management plus > > > > plans for execution scheduling), > > > > > > > > git-remote add anholt people.freedesktop.org:~anholt/drm > > > > git-fetch anholt > > > > git-checkout anholt/drm-gem > > > > > > > > The interesting things we're needing from the kernel: > > > > - Private storage associated with file descriptors > > > > - Callback to driver on destruction of file descriptor > > > > - Ability to allocate a swap-backed pile of memory > > > > - Ability to pin pages from that object and get addresses for them to > > > > stuff into the GTT. > > > > - Ability to map pages in the kernel with the uncached bits set > > > > (non-intel) > > > > - Ability to map pages to userland with the uncached bits set > > > > (non-intel, likely not required, but may come at a performance > > > > cost). > > > > > > > > Interesting things we're considering needing from the kernel: > > > > - Ability to create fds above 1024 from our driver, associated with our > > > > own set of file operations (read/write/mmap/ioctl/close). > > > > - Ability to look up those fds and get our private storage associated > > > > with them. > > > > > > > > Down the line, likely to happen: > > > > - Creating a filesystem exposing those objects we've been making fds > > > > for. > > > > Eric, > > > > I mentioned earlier that I would get my local git repo's changes to the > > mesa/drm tree available from fd.o up somewhere. I have them here: > > * http://www.cokane.org/cgi-bin/gitweb.cgi?p=drm.git > > > > My custom branch is 'cokane-master' > > The fd.o branch is tracked on 'fd-master' > > > > You can ignore the 'master' branch for now... I need to re-org my git a > > bit. > > > > Right now, this gets my RS690 notebook to almost work with the > > in-development radeonhd DRI code, but it causes Xorg to run in a > > busyloop when I try using the xf86-video-ati driver with it. I did a run > > at trying to get the vblank stuff ported over, but I got busy and > > haven't touched it in a bit. I also tried to tweak anything else that > > kept the radeon code from compiling under FreeBSD. > > > > If I have another set of eyes on this it might help me front-burner it > > more often to get patches in here-and-there. I've tried shoving some bug > > reports up to the DRI project, but they haven't been acted upon yet... > > Looks like your webserver is dead. Could you push your tree up on > freefall or something so I can just ssh and grab it? > Eric, I've pushed it up to ~cokane/drm-cokane.git on freefall. -- Coleman Kane -------------- 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-arch/attachments/20080516/5aca329b/attachment.pgp From bugmaster at FreeBSD.org Mon May 19 11:06:50 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 19 11:06:54 2008 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200805191106.m4JB6nuX011510@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From jhb at freebsd.org Mon May 19 15:01:05 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon May 19 15:01:20 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080515123055.GY18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <200805150730.08418.jhb@freebsd.org> <20080515123055.GY18958@deviant.kiev.zoral.com.ua> Message-ID: <200805191015.35212.jhb@freebsd.org> On Thursday 15 May 2008 08:30:55 am Kostik Belousov wrote: > On Thu, May 15, 2008 at 07:30:07AM -0400, John Baldwin wrote: > > On Wednesday 14 May 2008 05:32:23 am Kostik Belousov wrote: > > > So, I cannot implement overlay of the cdevpriv over the seqaccess data > > > without some additional flag. On the other hand, use of 2 bytes for the > > > f_type is overkill when the range of the types is [1,8]. I divided it > > > to two one-byte fields, and new field is used for filetype-specific > > > flags. > > > > > > http://people.freebsd.org/~kib/misc/fdpriv.4.patch > > > shall give the same size of the struct file while not causing > > > unconditional acquire of the cdevpriv_mtx on the last file close. > > > > > > Jeff, do you agree with the proposed vivisection of the f_type ? I will > > > ask Peter to retest the patch then. > > > > I would rather add the new pointer to struct file and avoid breaking the > > ABI of fstat. That is, I would like this patch to be MFCable, but you > > can't MFC this w/o breaking the ABI of struct file since fstat(1) will be > > reading the full short to get the DTYPE. > > Oh, I thought that fstat uses struct xfile, at least for live systems. > > I considered to introduce new f_type value for devfs files; the > DTYPE_VNODE is not a complete truth due to custom f_ops. But DTYPE_VNODE > is special-cased in enough locations to make this much less preferrable > then another pointer. fstat always uses libkvm and direct access unfortunately. Also, I greatly care about fstat on crash dumps as well. :) -- John Baldwin From kostikbel at gmail.com Mon May 19 15:38:26 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon May 19 15:38:31 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <200805191015.35212.jhb@freebsd.org> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <200805150730.08418.jhb@freebsd.org> <20080515123055.GY18958@deviant.kiev.zoral.com.ua> <200805191015.35212.jhb@freebsd.org> Message-ID: <20080519153811.GF18958@deviant.kiev.zoral.com.ua> On Mon, May 19, 2008 at 10:15:34AM -0400, John Baldwin wrote: > On Thursday 15 May 2008 08:30:55 am Kostik Belousov wrote: > > On Thu, May 15, 2008 at 07:30:07AM -0400, John Baldwin wrote: > > > On Wednesday 14 May 2008 05:32:23 am Kostik Belousov wrote: > > > > So, I cannot implement overlay of the cdevpriv over the seqaccess data > > > > without some additional flag. On the other hand, use of 2 bytes for the > > > > f_type is overkill when the range of the types is [1,8]. I divided it > > > > to two one-byte fields, and new field is used for filetype-specific > > > > flags. > > > > > > > > http://people.freebsd.org/~kib/misc/fdpriv.4.patch > > > > shall give the same size of the struct file while not causing > > > > unconditional acquire of the cdevpriv_mtx on the last file close. > > > > > > > > Jeff, do you agree with the proposed vivisection of the f_type ? I will > > > > ask Peter to retest the patch then. > > > > > > I would rather add the new pointer to struct file and avoid breaking the > > > ABI of fstat. That is, I would like this patch to be MFCable, but you > > > can't MFC this w/o breaking the ABI of struct file since fstat(1) will be > > > reading the full short to get the DTYPE. > > > > Oh, I thought that fstat uses struct xfile, at least for live systems. > > > > I considered to introduce new f_type value for devfs files; the > > DTYPE_VNODE is not a complete truth due to custom f_ops. But DTYPE_VNODE > > is special-cased in enough locations to make this much less preferrable > > then another pointer. > > fstat always uses libkvm and direct access unfortunately. Also, I greatly > care about fstat on crash dumps as well. :) So, what is the conclusion ? Does anybody have any further objections against committing http://people.freebsd.org/~kib/misc/fdpriv.3.patch I plan to do it this week. -------------- 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-arch/attachments/20080519/282e4769/attachment.pgp From cokane at FreeBSD.org Mon May 19 17:17:53 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Mon May 19 17:17:58 2008 Subject: Feature requests for open-source graphics In-Reply-To: <1210883909.96116.4.camel@localhost> References: <1210352688.2152.78.camel@localhost> <1210800676.2466.6.camel@localhost> <1210883909.96116.4.camel@localhost> Message-ID: <1211217436.29314.12.camel@localhost> On Thu, 2008-05-15 at 13:38 -0700, Eric Anholt wrote: > On Wed, 2008-05-14 at 17:31 -0400, Coleman Kane wrote: > > On Fri, 2008-05-09 at 10:04 -0700, Eric Anholt wrote: > > > email message attachment, "Forwarded message - Re: Forward: Updated > > > FreeBSD kernel feature requests (NVIDIA graphics)" > > > > -------- Forwarded Message -------- > > > > From: Eric Anholt > > > > To: Marcel Moolenaar > > > > Cc: John Baldwin , Coleman Kane > > > > , Dag-Erling Sm?rgrav , Martin > > > > Cracauer , gnn@freebsd.org, > > > > developers@freebsd.org > > > > Subject: Re: Forward: Updated FreeBSD kernel feature requests > > > > (NVIDIA graphics) > > > > Date: Thu, 08 May 2008 15:54:17 -0700 > > > > Mailer: Evolution 2.22.0 FreeBSD GNOME Team Port > > > > > > > > On Wed, 2008-05-07 at 10:37 -0700, Marcel Moolenaar wrote: > > > > > On May 7, 2008, at 8:29 AM, John Baldwin wrote: > > > > > > > > > > > Quite, and this has been covered several times already. In fact, > > > > > > they engage > > > > > > in several hacks to support Linux. Other OS's such as Solaris and > > > > > > OS X have > > > > > > cleaner interfaces for many of the things they wish to do. > > > > > > > > > > I think this is where I normally say that we need kernel drivers > > > > > for graphics hardware. I'm not going to do that anymore; I've been > > > > > stating the obvious too often already... > > > > > > > > It's OK, we're finally listening. By the end of the year, major Linux > > > > distributions should be shipping "DRM modesetting" -- the DRM device > > > > takes over your graphics card and manages memory, execution, and > > > > suspend/resume. Your kernel console and X Server then sit on top of > > > > that, submitting video mode setting and command execution requests to > > > > the DRM. The chips I would expect to be supported by then are all > > > > Intel, pre-r500 ATI at least, and a subset of nvidia through nouveau. > > > > > > > > What FreeBSD needs to do to keep up is implement the memory manager > > > > part. I think I've got a reasonable design going that should take about > > > > a month of reimplementing for the FreeBSD kernel. If someone wanted to > > > > get us closer to doing that, > > > > > > > > git clone anongit.freedesktop.org:/git/mesa/drm > > > > > > > > and make everything but TTM (the *_HAVE_FENCE and *_HAVE_BUFFER defines) > > > > work on -current. > > > > > > > > To see what we're working on for what we're calling the "graphics > > > > execution manager" now (memory management plus caching management plus > > > > plans for execution scheduling), > > > > > > > > git-remote add anholt people.freedesktop.org:~anholt/drm > > > > git-fetch anholt > > > > git-checkout anholt/drm-gem > > > > > > > > The interesting things we're needing from the kernel: > > > > - Private storage associated with file descriptors > > > > - Callback to driver on destruction of file descriptor > > > > - Ability to allocate a swap-backed pile of memory > > > > - Ability to pin pages from that object and get addresses for them to > > > > stuff into the GTT. > > > > - Ability to map pages in the kernel with the uncached bits set > > > > (non-intel) > > > > - Ability to map pages to userland with the uncached bits set > > > > (non-intel, likely not required, but may come at a performance > > > > cost). > > > > > > > > Interesting things we're considering needing from the kernel: > > > > - Ability to create fds above 1024 from our driver, associated with our > > > > own set of file operations (read/write/mmap/ioctl/close). > > > > - Ability to look up those fds and get our private storage associated > > > > with them. > > > > > > > > Down the line, likely to happen: > > > > - Creating a filesystem exposing those objects we've been making fds > > > > for. > > > > Eric, > > > > I mentioned earlier that I would get my local git repo's changes to the > > mesa/drm tree available from fd.o up somewhere. I have them here: > > * http://www.cokane.org/cgi-bin/gitweb.cgi?p=drm.git > > > > My custom branch is 'cokane-master' > > The fd.o branch is tracked on 'fd-master' > > > > You can ignore the 'master' branch for now... I need to re-org my git a > > bit. > > > > Right now, this gets my RS690 notebook to almost work with the > > in-development radeonhd DRI code, but it causes Xorg to run in a > > busyloop when I try using the xf86-video-ati driver with it. I did a run > > at trying to get the vblank stuff ported over, but I got busy and > > haven't touched it in a bit. I also tried to tweak anything else that > > kept the radeon code from compiling under FreeBSD. > > > > If I have another set of eyes on this it might help me front-burner it > > more often to get patches in here-and-there. I've tried shoving some bug > > reports up to the DRI project, but they haven't been acted upon yet... > > Looks like your webserver is dead. Could you push your tree up on > freefall or something so I can just ssh and grab it? > Eric, Just met up w/ mhopf on #radeonhd on freenode. He pushed some updates to his radeonhd repo that might fix some GL bugs I've run into that prevent me from giving my changes a thumbs-up or not here. After today's buildworld/buildkernel I hope to have a little more results for you as to whether I have a functional DRI on my RS690. -- Coleman Kane -------------- 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-arch/attachments/20080519/b2f49105/attachment.pgp From jhb at FreeBSD.org Mon May 19 21:28:38 2008 From: jhb at FreeBSD.org (John Baldwin) Date: Mon May 19 21:28:43 2008 Subject: Per-open file private data for the cdevs In-Reply-To: <20080519153811.GF18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <200805191015.35212.jhb@freebsd.org> <20080519153811.GF18958@deviant.kiev.zoral.com.ua> Message-ID: <200805191209.34522.jhb@freebsd.org> On Monday 19 May 2008 11:38:11 am Kostik Belousov wrote: > On Mon, May 19, 2008 at 10:15:34AM -0400, John Baldwin wrote: > > On Thursday 15 May 2008 08:30:55 am Kostik Belousov wrote: > > > On Thu, May 15, 2008 at 07:30:07AM -0400, John Baldwin wrote: > > > > On Wednesday 14 May 2008 05:32:23 am Kostik Belousov wrote: > > > > > So, I cannot implement overlay of the cdevpriv over the seqaccess data > > > > > without some additional flag. On the other hand, use of 2 bytes for the > > > > > f_type is overkill when the range of the types is [1,8]. I divided it > > > > > to two one-byte fields, and new field is used for filetype-specific > > > > > flags. > > > > > > > > > > http://people.freebsd.org/~kib/misc/fdpriv.4.patch > > > > > shall give the same size of the struct file while not causing > > > > > unconditional acquire of the cdevpriv_mtx on the last file close. > > > > > > > > > > Jeff, do you agree with the proposed vivisection of the f_type ? I will > > > > > ask Peter to retest the patch then. > > > > > > > > I would rather add the new pointer to struct file and avoid breaking the > > > > ABI of fstat. That is, I would like this patch to be MFCable, but you > > > > can't MFC this w/o breaking the ABI of struct file since fstat(1) will be > > > > reading the full short to get the DTYPE. > > > > > > Oh, I thought that fstat uses struct xfile, at least for live systems. > > > > > > I considered to introduce new f_type value for devfs files; the > > > DTYPE_VNODE is not a complete truth due to custom f_ops. But DTYPE_VNODE > > > is special-cased in enough locations to make this much less preferrable > > > then another pointer. > > > > fstat always uses libkvm and direct access unfortunately. Also, I greatly > > care about fstat on crash dumps as well. :) > > So, what is the conclusion ? Does anybody have any further objections > against committing > http://people.freebsd.org/~kib/misc/fdpriv.3.patch > > I plan to do it this week. I think the current patch is good. -- John Baldwin From tom at uffner.com Tue May 20 21:04:56 2008 From: tom at uffner.com (Tom Uffner) Date: Tue May 20 21:05:00 2008 Subject: /etc/pf.conf missing from 7.0 minimal install Message-ID: <4833392B.70002@uffner.com> the sample config file /etc/pf.conf is not included in the 7.0-STABLE minimal installation. was this an accidental omission, as it appears to be since the rest of the pf files including /etc/pf.os are included, or was it done by design? tom From brix at FreeBSD.org Tue May 20 21:43:21 2008 From: brix at FreeBSD.org (Henrik Brix Andersen) Date: Tue May 20 21:43:25 2008 Subject: /etc/pf.conf missing from 7.0 minimal install In-Reply-To: <4833392B.70002@uffner.com> References: <4833392B.70002@uffner.com> Message-ID: <20080520212446.GB20926@tirith.brixandersen.dk> On Tue, May 20, 2008 at 04:48:43PM -0400, Tom Uffner wrote: > the sample config file /etc/pf.conf is not included in the 7.0-STABLE > minimal installation. > > was this an accidental omission, as it appears to be since the rest > of the pf files including /etc/pf.os are included, or was it done by > design? By design. It was moved to /usr/share/examples/pf/pf.conf Brix -- Henrik Brix Andersen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 217 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080520/119514c5/attachment.pgp From rea-fbsd at codelabs.ru Wed May 21 04:15:08 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed May 21 04:15:12 2008 Subject: /etc/pf.conf missing from 7.0 minimal install In-Reply-To: <20080520212446.GB20926@tirith.brixandersen.dk> References: <4833392B.70002@uffner.com> <20080520212446.GB20926@tirith.brixandersen.dk> Message-ID: Tue, May 20, 2008 at 11:24:46PM +0200, Henrik Brix Andersen wrote: > On Tue, May 20, 2008 at 04:48:43PM -0400, Tom Uffner wrote: > > was this an accidental omission, as it appears to be since the rest > > of the pf files including /etc/pf.os are included, or was it done by > > design? > > By design. It was moved to /usr/share/examples/pf/pf.conf ...and substantially stipped down (synced with OpenBSD examples, as commit message says). I would say that this is a step backwards, because the old /etc/pf.conf had more options and provided a better comments. -- Eygene From rwatson at FreeBSD.org Wed May 21 21:45:22 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed May 21 21:45:25 2008 Subject: netatm removal warning In-Reply-To: <20080310122338.T29929@fledge.watson.org> References: <20080310122338.T29929@fledge.watson.org> Message-ID: <20080521224350.T63482@fledge.watson.org> On Mon, 10 Mar 2008, Robert Watson wrote: > This is another of those boring e-mails about kernel subsystems that still > require Giant. Sorry about that! > > As previously published, netatm is a non-MPSAFE protocol stack largely > superseded by our two other ATM stacks, netnatm and the netgraph/atm (both > MPSAFE). netatm is currently non-functional and uncompileable because it > depends on the Giant compatibility shims for the protocol stack, which were > removed in FreeBSD 7.0. We left the code in place in case to make it easier > for any interested third parties to distribute patches against it (in > particular, patches to make it MPSAFE). > > The current plan is that we will remove the netatm code from HEAD and > RELENG_7 before FreeBSD 7.1. A specific schedue for 7.1 hasn't been > published yet, but in order to give plenty of warning, here's the proposed > netatm removal schedule: > > 10 March 2008 E-mail warning to arch@/net@ > 10 April 2008 E-mail warning to arch@/net@ > 10 May 2008 Removal of netatm from HEAD > 20 May 2008 Removal of netatm from RELENG_7 > > Obviously, netatm will remain in the revision control history should anyone > wish to ressurect it after that date. However, I suspect that those > interested in ATM on FreeBSD have long since been using Harti's netgraph ATM > framework. Somehow the dates slipped pasted more quickly than I had hoped -- this is the HEADS UP that, on a slightly delayed schedule, I will be trimming netatm from the src tree for HEAD, and then a week or two later, from RELENG_7. Assuming all goes well, this should result in no functional change at all. Robert N M Watson Computer Laboratory University of Cambridge From delphij at delphij.net Thu May 22 19:51:04 2008 From: delphij at delphij.net (Xin LI) Date: Thu May 22 19:51:09 2008 Subject: A couple of bitwise operations In-Reply-To: <20080516163857.Y43605@delplex.bde.org> References: <482D193D.2010802@delphij.net> <20080516163857.Y43605@delplex.bde.org> Message-ID: <4835CE9C.1050707@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Bruce, Bruce Evans wrote: | On Thu, 15 May 2008, Xin LI wrote: | |> I find the DragonFly macros, __BIT, __BITS, __LOWEST_SET_BIT, |> __SHIFTOUT, __SHIFTIN and __SHIFTOUT_MASK useful. Any objection adding |> this as sys/sys/bitops.h? |> |> (These macros are found in NetBSD in sys/sys/cdefs.h and DragonFly as |> sys/sys/bitops.h) | | WHat's wrong with bitstring(3)(9undoc), except that it was invented here | and doesn't have a style bug after every #define? Both have naming errors | -- bitstring has too many unsafe macros whose name is in lower case, while | bitops uses upper case even for safe macros. Hmm... So the scenario is that I have ported a DragonFly driver to FreeBSD and do not want to make massive changes to it so that we can apply further change from their code easier. Does it make sense if I keep these changes inside the driver specific header file? Cheers, - -- ** Help China's quake relief at http://www.redcross.org.cn/ |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEUEARECAAYFAkg1zpwACgkQi+vbBBjt66C5LACY3XkP6sfEg8UKcegpKrHVDPCB 4gCePOUVwLyVndyMxFlxBVFHLMYFmHI= =3V15 -----END PGP SIGNATURE----- From cokane at cokane.org Fri May 23 15:37:50 2008 From: cokane at cokane.org (Coleman Kane) Date: Fri May 23 15:37:57 2008 Subject: Feature requests for open-source graphics In-Reply-To: <1211217436.29314.12.camel@localhost> References: <1210352688.2152.78.camel@localhost> <1210800676.2466.6.camel@localhost> <1210883909.96116.4.camel@localhost> <1211217436.29314.12.camel@localhost> Message-ID: <1211553396.5985.19.camel@localhost> On Mon, 2008-05-19 at 13:17 -0400, Coleman Kane wrote: > Eric, > > Just met up w/ mhopf on #radeonhd on freenode. He pushed some updates to > his radeonhd repo that might fix some GL bugs I've run into that prevent > me from giving my changes a thumbs-up or not here. > > After today's buildworld/buildkernel I hope to have a little more > results for you as to whether I have a functional DRI on my RS690. > Eric, Here's another update... I've pushed my newest stuff to ~cokane/drm-cokane.git on freefall. Recently airlied merged in the support for vblank interrupts on the r500/rs6xx chips. The interrupt code seems to work on my system (I can see the interrupts fired by carefully placed printfs). FYI I am only focusing on the radeon code with this driver... so I've disabled all the others in the bsd-core/Makefile. I must still be missing some other functionality here though... and I'd like to know if you could help me track it down. What happens is I get a black space where the OpenGL output should be under hardware rendering. The card seems to take all of the commands, and the drm driver provides sane return codes to the Xserver/radeonhd, not spitting any errors during rendering. I've been following the console output produced by setting hw.dri.0.debug=1, but I am not 100% certain I could parse errors from the output if I knew how. The DRI rendering never seems to occur to my screen, but OpenGL programs seem to think that they are running fine. I can even get decent FPS numbers from glxgears, and a huge blob of seemingly good data from glxinfo. -- Coleman Kane From rwatson at FreeBSD.org Sat May 24 10:21:00 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat May 24 10:21:11 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) Message-ID: <20080524111715.T64552@fledge.watson.org> Dear all: Just as a reminder, we've just about reached the one month date before IFF_NEEDSGIANT drivers are disabled in the build. You can find a description of the general problem and list of specific drivers below. As USB work is on-going, I will *not* disable the USB drivers at this time, but all other drivers in the list below will be disabled on 26 June. They will remain in the tree, easily accessible for patch distribution and re-enabling, until October, when any remaining non-MPSAFE drivers will be deleted in 8.x. FreeBSD 8.0 will not ship with compatibility shims to support non-MPSAFE network device drivers. Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Sun, 3 Feb 2008 20:59:05 +0000 (GMT) From: Robert Watson To: arch@FreeBSD.org Subject: 8.0 network stack MPsafety goals (fwd) Only a few days after predicted, this is a reminder that IFF_NEEDSGIANT network drivers are going to stop working in the forseeable future. Please review the attached driver list, and if you depend on or care about a Giant-dependent device driver, take action to make sure it doesn't remain on the list in a month's time! (As far as I'm aware, the list has not changed since my December posting.) Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Mon, 24 Dec 2007 10:43:28 +0000 (GMT) From: Robert Watson To: arch@FreeBSD.org Subject: 8.0 network stack MPsafety goals Dear all: With the 7.0 release around the corner, many developers are starting to think about (and in quite a few cases, work on) their goals for 8.0. One of our on-going kernel projects has been the elimination of the Giant lock, and that project has transformed into one of optimizating behavior on increasing numbers of processors. In 7.0, despite the noteworth accomplishment of eliminating debug.mpsasfenet and conditional network stack Gian acquisition, we were unable to fully eliminate the IFF_NEEDSGIANT flag, which controls the conditional acquisition of the Giant lock around non-MPSAFE network device drivers. Primarily these drivers are aging ISA network device drivers, although there are some exceptions, such as the USB stack. This e-mail proposes the elimination of the IFF_NEEDSGIANT flag and associated infrastructure in FreeBSD 8.0, meaning that all network device drivers must be able to operate without the Giant lock (largely the case already). Remaining drivers using the IFF_NEEDSGIANT flag must either be updated, or less ideally, removed. I propose the following schedule: Date Goals ---- ----- 26 Dec 2007 Post proposed schedule for flag and infrastructure removal Post affected driver list 26 Jan 2008 Repost proposed schedule for flag and infrastructure removal Post updated affected driver list 26 Feb 2008 Adjust boot-time printf for affect drivers to generate a loud warning. Post updated affected driver list 26 May 2008 Post HEADS UP of impending driver disabling Post updated affected driver list 26 Jun 2008 Disable build of all drivers requiring IFF_NEEDSGIANT Post updated affected driver list 26 Sep 2008 Post HEADS up of impending driver removal Post updated affected driver list 26 Oct 2008 Delete source of all drivers requiring IFF_NEEDSGIANT Remove flag and infrastructure Here is a list of potentially affected drivers: Name Bus Man page description --- --- -------------------- ar ISA/PCI synchronous Digi/Arnet device driver arl ISA Aironet Arlan 655 wireless network adapter driver awi PCCARD AMD PCnetMobile IEEE 802.11 PCMCIA wireless network driver axe USB ASIX Electronics AX88172 USB Ethernet driver cdce USB USB Communication Device Class Ethernet driver cnw PCCARD Netwave AirSurfer wireless network driver cs ISA/PCCARD Ethernet device driver cue USB CATC USB-EL1210A USB Ethernet driver ex ISA/PCCARD Ethernet device driver for the Intel EtherExpress Pro/10 and Pro/10+ fe CBUS/ISA/PCCARD Fujitsu MB86960A/MB86965A based Ethernet adapters ic I2C I2C bus system ie ISA Ethernet device driver kue USB Kawasaki LSI KL5KUSB101B USB Ethernet driver oltr ISA/PCI Olicom Token Ring device driver plip PPBUS printer port Internet Protocol driver ppp TTY point to point protocol network interface ray PCCARD Raytheon Raylink/Webgear Aviator PCCard driver rue USB RealTek RTL8150 USB to Fast Ethernet controller driver rum USB Ralink Technology USB IEEE 802.11a/b/g wireless network device sbni ISA/PCI Granch SBNI12 leased line modem driver sbsh PCI Granch SBNI16 SHDSL modem device driver sl TTY slip network interface snc ISA/PCCARD National Semiconductor DP8393X SONIC Ethernet adapter driver sr ISA/PCI synchronous RISCom/N2 / WANic 400/405 device driver udav USB Davicom DM9601 USB Ethernet driver ural USB Ralink Technology RT2500USB IEEE 802.11 driver xe PCCARD Xircom PCMCIA Ethernet device driver zyd USB ZyDAS ZD1211/ZD1211B USB IEEE 802.11b/g wireless network device In some cases, the requirement for Giant is a property of a subsystem the driver depends on as the driver itself; for example, the tty subsystem for SLIP and PPP, and the USB subsystem for a number of USB ethernet and wireless drivers. With most of a year before to go on the proposed schedule, my hope is that we will have lots of time to address these issues, but wanted to get a roadmap out from a network protocol stack architecture perspective so that device driver and subsystem authors could have a schedule in mind. FYI, the following drivers also reference IFF_NEEDSGIANT, but only in order to provide their own conditional MPSAFEty, which can be removed without affecting device driver functionality (I believe): Name Bus Man page description --- --- -------------------- ce PCI driver for synchronous Cronyx Tau-PCI/32 WAN adapters cp PCI driver for synchronous Cronyx Tau-PCI WAN adapters ctau ISA driver for synchronous Cronyx Tau WAN adapters cx ISA driver for synchronous/asynchronous Cronyx Sigma WAN adapters Developers and users of the above drivers are heavily encouraged to update the drivers to remove dependence on Giant, and/or make other contingency plans. Robert N M Watson Computer Laboratory University of Cambridge _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From hecyro_71 at yahoo.it Sat May 24 12:53:07 2008 From: hecyro_71 at yahoo.it (Simon from Italy) Date: Sat May 24 12:53:10 2008 Subject: Do you want to jump on my motorbyke? Message-ID: Hello, i?m italian boy. I have 36 years and I love to travel in motorbyke in Europe, beach or mountain and camping, in my vacations. The past summers I have been on the beaches of Spain, France, Croatia, Holland, but also Hungary, Switzerland, Austria, Belgium, Germany, Slovenia, Poland, Republik Czech, Repubblik Slovanska, Lithuania, Latvia... I search a girl that she loves to travel in motorbyke and that she wants to make from travel?s partner in order to organize the next vacations. Usually I make of the trance of vacations from 10 - 15 days and succeed not to spend very. My period for vacations is: 25/5 - 2/6 or 6/6 - 16/6 or 21/6 - 30/6 or 1/8 - 24/8 I?m single and I search girl in order to amuse themselves and to discover new worlds, new cultures, new people... Do you want to jump on my motorbyke? Simon hecyro_71@yahoo.it ___________________________________________________________________________________________________________________________ Ciao, sono un ragazzo italiano. Ho 36 anni e amo trascorrere le vacanze girando in moto per l'Europa, spiagge o montagna e campeggi. Le scorse estati sono stato sulle spiagge di Spagna, Francia, Croazia, Olanda, Lituania, ma anche in Ungheria, Svizzera, Austria, Belgio, Germania, Slovenia, Repubblica Ceca, Repubblica Slovacca, Polonia, Lussemburgo, Lituania, Lettonia... Cerco una ragazza, a cui piaccia la moto e che voglia fare da compagna di viaggio per organizzare le prossime vacanze. Io ho le ferie in questi periodi: 25/5 - 2/6 o 6/6 - 16/6 o 21/6 - 30/6 o 1/8 - 24/8 Solitamente riesco a non spendere molto. Sono single e sto solo cercando una COMPAGNA DI VIAGGIO per divertirsi e scoprire nuovi mondi, nuove culture, gente nuova... Salti in sella? Simone hecyro_71@yahoo.it Message envoy? par la version d'essai d'Oxilog e-mailing. Attention : La soci?t? Oxilog n'est pas ? l'origine de l'envoi de ce message et n'est pas responsable de son contenu. Pour toute demande ou r?clamation, veuillez contacter l'exp?diteur de ce message. From cokane at FreeBSD.org Sat May 24 14:49:00 2008 From: cokane at FreeBSD.org (Coleman Kane) Date: Sat May 24 14:49:08 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080524111715.T64552@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> Message-ID: <1211640498.1510.8.camel@localhost> On Sat, 2008-05-24 at 11:20 +0100, Robert Watson wrote: > Dear all: > > Just as a reminder, we've just about reached the one month date before > IFF_NEEDSGIANT drivers are disabled in the build. You can find a description > of the general problem and list of specific drivers below. > > As USB work is on-going, I will *not* disable the USB drivers at this time, > but all other drivers in the list below will be disabled on 26 June. They > will remain in the tree, easily accessible for patch distribution and > re-enabling, until October, when any remaining non-MPSAFE drivers will be > deleted in 8.x. FreeBSD 8.0 will not ship with compatibility shims to support > non-MPSAFE network device drivers. > > Robert N M Watson > Computer Laboratory > University of Cambridge > > ---------- Forwarded message ---------- > Date: Sun, 3 Feb 2008 20:59:05 +0000 (GMT) > From: Robert Watson > To: arch@FreeBSD.org > Subject: 8.0 network stack MPsafety goals (fwd) > > > Only a few days after predicted, this is a reminder that IFF_NEEDSGIANT network > drivers are going to stop working in the forseeable future. Please review the > attached driver list, and if you depend on or care about a Giant-dependent > device driver, take action to make sure it doesn't remain on the list in a > month's time! > > (As far as I'm aware, the list has not changed since my December posting.) > > Robert N M Watson > Computer Laboratory > University of Cambridge > > ---------- Forwarded message ---------- > Date: Mon, 24 Dec 2007 10:43:28 +0000 (GMT) > From: Robert Watson > To: arch@FreeBSD.org > Subject: 8.0 network stack MPsafety goals > > > Dear all: > > With the 7.0 release around the corner, many developers are starting to think > about (and in quite a few cases, work on) their goals for 8.0. One of our > on-going kernel projects has been the elimination of the Giant lock, and that > project has transformed into one of optimizating behavior on increasing numbers > of processors. > > In 7.0, despite the noteworth accomplishment of eliminating debug.mpsasfenet > and conditional network stack Gian acquisition, we were unable to fully > eliminate the IFF_NEEDSGIANT flag, which controls the conditional acquisition > of the Giant lock around non-MPSAFE network device drivers. Primarily these > drivers are aging ISA network device drivers, although there are some > exceptions, such as the USB stack. > > This e-mail proposes the elimination of the IFF_NEEDSGIANT flag and associated > infrastructure in FreeBSD 8.0, meaning that all network device drivers must be > able to operate without the Giant lock (largely the case already). Remaining > drivers using the IFF_NEEDSGIANT flag must either be updated, or less ideally, > removed. I propose the following schedule: > > Date Goals > ---- ----- > 26 Dec 2007 Post proposed schedule for flag and infrastructure removal > Post affected driver list > > 26 Jan 2008 Repost proposed schedule for flag and infrastructure removal > Post updated affected driver list > > 26 Feb 2008 Adjust boot-time printf for affect drivers to generate a loud > warning. > Post updated affected driver list > > 26 May 2008 Post HEADS UP of impending driver disabling > Post updated affected driver list > > 26 Jun 2008 Disable build of all drivers requiring IFF_NEEDSGIANT > Post updated affected driver list > > 26 Sep 2008 Post HEADS up of impending driver removal > Post updated affected driver list > > 26 Oct 2008 Delete source of all drivers requiring IFF_NEEDSGIANT > Remove flag and infrastructure > > Here is a list of potentially affected drivers: > > Name Bus Man page description > --- --- -------------------- > ar ISA/PCI synchronous Digi/Arnet device driver > arl ISA Aironet Arlan 655 wireless network adapter driver > awi PCCARD AMD PCnetMobile IEEE 802.11 PCMCIA wireless network > driver > axe USB ASIX Electronics AX88172 USB Ethernet driver > cdce USB USB Communication Device Class Ethernet driver > cnw PCCARD Netwave AirSurfer wireless network driver > cs ISA/PCCARD Ethernet device driver > cue USB CATC USB-EL1210A USB Ethernet driver > ex ISA/PCCARD Ethernet device driver for the Intel EtherExpress > Pro/10 and Pro/10+ > fe CBUS/ISA/PCCARD Fujitsu MB86960A/MB86965A based Ethernet adapters > ic I2C I2C bus system > ie ISA Ethernet device driver > kue USB Kawasaki LSI KL5KUSB101B USB Ethernet driver > oltr ISA/PCI Olicom Token Ring device driver > plip PPBUS printer port Internet Protocol driver > ppp TTY point to point protocol network interface > ray PCCARD Raytheon Raylink/Webgear Aviator PCCard driver > rue USB RealTek RTL8150 USB to Fast Ethernet controller driver > rum USB Ralink Technology USB IEEE 802.11a/b/g wireless > network device > sbni ISA/PCI Granch SBNI12 leased line modem driver > sbsh PCI Granch SBNI16 SHDSL modem device driver > sl TTY slip network interface > snc ISA/PCCARD National Semiconductor DP8393X SONIC Ethernet adapter > driver > sr ISA/PCI synchronous RISCom/N2 / WANic 400/405 device driver > udav USB Davicom DM9601 USB Ethernet driver > ural USB Ralink Technology RT2500USB IEEE 802.11 driver > xe PCCARD Xircom PCMCIA Ethernet device driver > zyd USB ZyDAS ZD1211/ZD1211B USB IEEE 802.11b/g wireless > network device > > In some cases, the requirement for Giant is a property of a subsystem the > driver depends on as the driver itself; for example, the tty subsystem for SLIP > and PPP, and the USB subsystem for a number of USB ethernet and wireless > drivers. With most of a year before to go on the proposed schedule, my hope is > that we will have lots of time to address these issues, but wanted to get a > roadmap out from a network protocol stack architecture perspective so that > device driver and subsystem authors could have a schedule in mind. > > FYI, the following drivers also reference IFF_NEEDSGIANT, but only in order to > provide their own conditional MPSAFEty, which can be removed without affecting > device driver functionality (I believe): > > Name Bus Man page description > --- --- -------------------- > ce PCI driver for synchronous Cronyx Tau-PCI/32 WAN adapters > cp PCI driver for synchronous Cronyx Tau-PCI WAN adapters > ctau ISA driver for synchronous Cronyx Tau WAN adapters > cx ISA driver for synchronous/asynchronous Cronyx Sigma WAN > adapters > > Developers and users of the above drivers are heavily encouraged to update the > drivers to remove dependence on Giant, and/or make other contingency plans. > > Robert N M Watson > Computer Laboratory > University of Cambridge I've created a quick table of these at the following location: http://wiki.freebsd.org/NetworkNeedsGiant Please everyone feel free to fill in the blanks. I'll try to do it as well as time permits. -- Coleman Kane -------------- 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-arch/attachments/20080524/b30b446f/attachment.pgp From rwatson at FreeBSD.org Sat May 24 15:56:22 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat May 24 15:56:34 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <1211640498.1510.8.camel@localhost> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> Message-ID: <20080524165519.K9809@fledge.watson.org> On Sat, 24 May 2008, Coleman Kane wrote: > I've created a quick table of these at the following location: > http://wiki.freebsd.org/NetworkNeedsGiant > > Please everyone feel free to fill in the blanks. I'll try to do it as well > as time permits. FWIW, I suspect fixing things like SLIP and kernel PPP are fairly trivial once tty locking is in place -- a per-softc mutex and a bit of locking in the obvious spots would likely do it without too much trouble. In some paths, it might be necessary to inject data via the netisr, if that's not already being done (probably is) to avoid input/output lock order issues. Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Sat May 24 18:14:37 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat May 24 18:15:09 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <1211640498.1510.8.camel@localhost> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> Message-ID: <20080524191405.N9809@fledge.watson.org> On Sat, 24 May 2008, Coleman Kane wrote: > I've created a quick table of these at the following location: > http://wiki.freebsd.org/NetworkNeedsGiant > > Please everyone feel free to fill in the blanks. I'll try to do it as well > as time permits. You might also want to cross-link with the SMPTODO page. Robert N M Watson Computer Laboratory University of Cambridge From peter at wemm.org Sun May 25 00:22:14 2008 From: peter at wemm.org (Peter Wemm) Date: Sun May 25 00:22:17 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080524165519.K9809@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> Message-ID: On Sat, May 24, 2008 at 8:56 AM, Robert Watson wrote: > > On Sat, 24 May 2008, Coleman Kane wrote: > >> I've created a quick table of these at the following location: >> http://wiki.freebsd.org/NetworkNeedsGiant >> >> Please everyone feel free to fill in the blanks. I'll try to do it as well >> as time permits. > > FWIW, I suspect fixing things like SLIP and kernel PPP are fairly trivial > once tty locking is in place -- a per-softc mutex and a bit of locking in > the obvious spots would likely do it without too much trouble. In some > paths, it might be necessary to inject data via the netisr, if that's not > already being done (probably is) to avoid input/output lock order issues. ppp_tty.c is kind of hairy and rather stale. I'd be inclined to drop strong hints about switching to either userland ppp(8), or mpd + netgraph if you want packets to stay in the kernel path and avoid userland. I was once a big user of pppd(8) and if_ppp.c / ppp_tty.c and maintained them for a while. But I use ppp(8) now and have no interest in maintaining it anymore. pppd/if_ppp.c/ppp_tty.c is many many years stale compared to what its vendor supplies. And, I think if_sl.c could probably do the same treatment. It would probably be a better investment in time to write a userland slip driver and if_tun.c and/or write a ng_slip.c module -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From rwatson at FreeBSD.org Sun May 25 09:58:57 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun May 25 09:59:01 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> Message-ID: <20080525105726.O39741@fledge.watson.org> On Sat, 24 May 2008, Peter Wemm wrote: >> FWIW, I suspect fixing things like SLIP and kernel PPP are fairly trivial >> once tty locking is in place -- a per-softc mutex and a bit of locking in >> the obvious spots would likely do it without too much trouble. In some >> paths, it might be necessary to inject data via the netisr, if that's not >> already being done (probably is) to avoid input/output lock order issues. > > ppp_tty.c is kind of hairy and rather stale. I'd be inclined to drop strong > hints about switching to either userland ppp(8), or mpd + netgraph if you > want packets to stay in the kernel path and avoid userland. > > I was once a big user of pppd(8) and if_ppp.c / ppp_tty.c and maintained > them for a while. But I use ppp(8) now and have no interest in maintaining > it anymore. > > pppd/if_ppp.c/ppp_tty.c is many many years stale compared to what its vendor > supplies. > > And, I think if_sl.c could probably do the same treatment. It would > probably be a better investment in time to write a userland slip driver and > if_tun.c and/or write a ng_slip.c module While I'd be quite supportive of something along these lines, I think it probably is more work to port SLIP to userspace than to hack the current code a little bit to be MPSAFE, assuming it remains supported with the revised tty code. SLIP is a fairly straight-forward piece of code, as long as you don't try to understand the line discipline stuff. :-) Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Sun May 25 23:06:34 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun May 25 23:06:43 2008 Subject: HEADS UP: netatm removed (was: Re: netatm removal warning) In-Reply-To: <20080521224350.T63482@fledge.watson.org> References: <20080310122338.T29929@fledge.watson.org> <20080521224350.T63482@fledge.watson.org> Message-ID: <20080526000329.K36357@fledge.watson.org> On Wed, 21 May 2008, Robert Watson wrote: >> 10 March 2008 E-mail warning to arch@/net@ >> 10 April 2008 E-mail warning to arch@/net@ >> 10 May 2008 Removal of netatm from HEAD >> 20 May 2008 Removal of netatm from RELENG_7 >> >> Obviously, netatm will remain in the revision control history should anyone >> wish to ressurect it after that date. However, I suspect that those >> interested in ATM on FreeBSD have long since been using Harti's netgraph >> ATM framework. > > Somehow the dates slipped pasted more quickly than I had hoped -- this is > the HEADS UP that, on a slightly delayed schedule, I will be trimming netatm > from the src tree for HEAD, and then a week or two later, from RELENG_7. > Assuming all goes well, this should result in no functional change at all. Per the long-announced schedule, netatm has now been removed from the CVS HEAD. Assuming no unexpected problems, it will likewise be removed from RELENG_7 in a few weeks. I apologize in advance if there's any build disruption; this touched a lot of Makefiles, and while netatm hasn't been connected to the build in ten months, there is always a risk of problems with a change of this scope. I'll keep an eye out for tinderbox warnings and correct as quickly as possible if any arise. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Mon May 26 09:30:21 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon May 26 09:30:25 2008 Subject: Remaining non-MPSAFE netisr handlers Message-ID: <20080526102345.G26343@fledge.watson.org> Dear all: In the continuing campaign to eliminate the Giant lock from the dregs of the network stack, I thought I'd send out a list of non-MPSAFE netisr handlers: Location Handler Removed with IFF_NEEDSGIANT dev/usb/usb_ethersubr.c:120 usbintr Yes net/if_ppp.c:277 pppintr Yes netinet6/ip6_input.c ip6_input No The plan for 8.0 is to remove the NETISR_MPSAFE flag -- all netisr handlers will be executed without the Giant lock. This doesn't prohibit acquiring Giant in the handler if required, although that's undesirable for the obvious reasons (potentially stalling interrupt handling, etc). Obviously, what would be most desirable is eliminating the remaining requirement for Giant in the IPv6 input path, primarily consisting of mld6 and nd6. With this in mind, my current plan is to remove the flag and add explicit Giant acquisition for any remaining handlers in June when IFF_NEEDSGIANT device drivers are disabled. Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Mon May 26 10:07:40 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon May 26 10:07:51 2008 Subject: Wiki page for non-MPSAFE network stack de-orbit scheduling Message-ID: <20080526110543.J26343@fledge.watson.org> Just to keep track of things: http://wiki.freebsd.org/NONMPSAFE_DEORBIT Robert N M Watson Computer Laboratory University of Cambridge From bugmaster at FreeBSD.org Mon May 26 11:06:45 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 26 11:06:58 2008 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200805261106.m4QB6jd1064832@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From ade at FreeBSD.org Mon May 26 13:10:34 2008 From: ade at FreeBSD.org (Ade Lovett) Date: Mon May 26 13:10:49 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080525105726.O39741@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> Message-ID: <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> On May 25, 2008, at 02:58 , Robert Watson wrote: > While I'd be quite supportive of something along these lines, I > think it probably is more work to port SLIP to userspace than to > hack the current code a little bit to be MPSAFE, assuming it remains > supported with the revised tty code. SLIP is a fairly straight- > forward piece of code, as long as you don't try to understand the > line discipline stuff. :-) Given that this is (a) 2008 and (b) 8.x we're talking about, are there really that many consumers of SLIP to warrant it being carried forward at all? Seems to me that it would not be unreasonable to give a heads up that the current kernel-space ppp/slip (and, for that matter, plip) drivers are going away some time before 8.0-RELEASE, pppd is more than adequately replaced by userland-ppp or netgraph, and if there's some critical need by someone to have SLIP and/or PLIP, then they'll need to step up to the plate to do the necessary re-implementation. Or stick with 7.x, which would be unaffected by this. We have a lot of network drivers that are potentially up for axing with the move to MPSAFE. Why not push just a little harder and slice out some serious legacy code? It's all well and good to be able to say that the current release of the kernel supports hardware that hasn't been used, other than in idiosyncratic situations (yes, ahc(4), I'm looking at you) for 5+ years, but it seems that we have an opportunity here to break out the Danish Ax[tm] in anger, and do some heavy-duty culling before 8.0-REL. -aDe From rwatson at FreeBSD.org Mon May 26 13:42:42 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon May 26 13:42:49 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> Message-ID: <20080526142931.Q26343@fledge.watson.org> On Mon, 26 May 2008, Ade Lovett wrote: > On May 25, 2008, at 02:58 , Robert Watson wrote: > >> While I'd be quite supportive of something along these lines, I think it >> probably is more work to port SLIP to userspace than to hack the current >> code a little bit to be MPSAFE, assuming it remains supported with the >> revised tty code. SLIP is a fairly straight-forward piece of code, as long >> as you don't try to understand the line discipline stuff. :-) > > Given that this is (a) 2008 and (b) 8.x we're talking about, are there > really that many consumers of SLIP to warrant it being carried forward at > all? > > Seems to me that it would not be unreasonable to give a heads up that the > current kernel-space ppp/slip (and, for that matter, plip) drivers are going > away some time before 8.0-RELEASE, pppd is more than adequately replaced by > userland-ppp or netgraph, and if there's some critical need by someone to > have SLIP and/or PLIP, then they'll need to step up to the plate to do the > necessary re-implementation. The thread you're replying began with precisely such a heads up. :-) Robert N M Watson Computer Laboratory University of Cambridge From fullermd at over-yonder.net Mon May 26 15:05:57 2008 From: fullermd at over-yonder.net (Matthew D. Fuller) Date: Mon May 26 15:06:01 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> Message-ID: <20080526144701.GG1689@over-yonder.net> On Mon, May 26, 2008 at 05:34:09AM -0700 I heard the voice of Ade Lovett, and lo! it spake thus: > > It's all well and good to be able to say that the current release of > the kernel supports hardware that hasn't been used, other than in > idiosyncratic situations (yes, ahc(4), I'm looking at you) for 5+ > years, [...] Neat, I didn't know I was idiosyncratic. % uname -sr FreeBSD 8.0-CURRENT % grep ^ahc /var/run/dmesg.boot ahc0: port 0x1000-0x10ff mem 0xf8001000-0xf8001fff irq 19 at device 11.0 on pci0 ahc0: [ITHREAD] ahc1: port 0x1400-0x14ff mem 0xf8002000-0xf8002fff irq 16 at device 13.0 on pci0 ahc1: [ITHREAD] ahc2: port 0x1800-0x18ff mem 0xf8003000-0xf8003fff irq 17 at device 13.1 on pci0 ahc2: [ITHREAD] (all 3 in use) -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From rwatson at FreeBSD.org Mon May 26 15:26:15 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon May 26 15:26:27 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <483AD498.6070207@FreeBSD.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> <483AD498.6070207@FreeBSD.org> Message-ID: <20080526162427.X26343@fledge.watson.org> On Mon, 26 May 2008, Bruce M. Simpson wrote: >> Given that this is (a) 2008 and (b) 8.x we're talking about, are there >> really that many consumers of SLIP to warrant it being carried forward at >> all? > > It's kind of a basic. [C]SLIP has been historically handy to have around for > situations which warrant it. Mind you, given that we have had tun(4) in the > tree for years now, a userland implementation of SLIP is possible. > > As with all of these things it's down to someone sitting down and doing it. > > I'm not volunteering to support any of this as I don't use it myself (got > enough on my plate), merely pointing out that support for SLIP in a system > is something many people have taken for granted over the years, and for > prototyping something or providing IP over a simple serial link without the > configuration overhead of PPP, SLIP is something someone might be using. > > P.S. ahc(4) is commodity hardware, I think it can stay right where it is > thank-you. My suspicion is that getting SLIP basically working in userspace is fairly straight forward, although I'm not sure how well-suited some of our current admin tools (slattach, etc) are for the purpose. If the new tty code maintains support for line disciplines, updating the existing SLIP code and adding locking code would probably be an equally sized (or shorter) task. SLIP has its subtleties, but the current implementation is relatively straight-forward, well-documented, etc. Robert N M Watson Computer Laboratory University of Cambridge From bms at FreeBSD.org Mon May 26 15:35:52 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Mon May 26 15:36:02 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> Message-ID: <483AD498.6070207@FreeBSD.org> Ade Lovett wrote: > > On May 25, 2008, at 02:58 , Robert Watson wrote: >> While I'd be quite supportive of something along these lines, I think >> it probably is more work to port SLIP to userspace than to hack the >> current code a little bit to be MPSAFE, assuming it remains supported >> with the revised tty code. SLIP is a fairly straight-forward piece >> of code, as long as you don't try to understand the line discipline >> stuff. :-) > > Given that this is (a) 2008 and (b) 8.x we're talking about, are there > really that many consumers of SLIP to warrant it being carried forward > at all? It's kind of a basic. [C]SLIP has been historically handy to have around for situations which warrant it. Mind you, given that we have had tun(4) in the tree for years now, a userland implementation of SLIP is possible. As with all of these things it's down to someone sitting down and doing it. I'm not volunteering to support any of this as I don't use it myself (got enough on my plate), merely pointing out that support for SLIP in a system is something many people have taken for granted over the years, and for prototyping something or providing IP over a simple serial link without the configuration overhead of PPP, SLIP is something someone might be using. P.S. ahc(4) is commodity hardware, I think it can stay right where it is thank-you. From rwatson at FreeBSD.org Mon May 26 15:42:17 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon May 26 15:42:29 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080526144701.GG1689@over-yonder.net> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> <20080526144701.GG1689@over-yonder.net> Message-ID: <20080526164151.D26343@fledge.watson.org> On Mon, 26 May 2008, Matthew D. Fuller wrote: > On Mon, May 26, 2008 at 05:34:09AM -0700 I heard the voice of > Ade Lovett, and lo! it spake thus: >> >> It's all well and good to be able to say that the current release of the >> kernel supports hardware that hasn't been used, other than in idiosyncratic >> situations (yes, ahc(4), I'm looking at you) for 5+ years, [...] > > Neat, I didn't know I was idiosyncratic. Somehow it's always me who is idiosyncratic: ahc0: port 0xdc00-0xdcff mem 0xf9fff000-0xf9ffffff irq 14 at device 11.0 on pci2 da0 at ahc0 bus 0 target 0 lun 0 Robert N M Watson Computer Laboratory University of Cambridge > > % uname -sr > FreeBSD 8.0-CURRENT > > % grep ^ahc /var/run/dmesg.boot > ahc0: port 0x1000-0x10ff mem 0xf8001000-0xf8001fff irq 19 at device 11.0 on pci0 > ahc0: [ITHREAD] > ahc1: port 0x1400-0x14ff mem 0xf8002000-0xf8002fff irq 16 at device 13.0 on pci0 > ahc1: [ITHREAD] > ahc2: port 0x1800-0x18ff mem 0xf8003000-0xf8003fff irq 17 at device 13.1 on pci0 > ahc2: [ITHREAD] > > (all 3 in use) > > > -- > Matthew Fuller (MF4839) | fullermd@over-yonder.net > Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ > On the Internet, nobody can hear you scream. > From ed at 80386.nl Mon May 26 16:17:11 2008 From: ed at 80386.nl (Ed Schouten) Date: Mon May 26 16:17:12 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080526162427.X26343@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> <483AD498.6070207@FreeBSD.org> <20080526162427.X26343@fledge.watson.org> Message-ID: <20080526161608.GE64397@hoeg.nl> Hello Robert, * Robert Watson wrote: > If the new tty code maintains support for line disciplines, updating > the existing SLIP code and adding locking code would probably be an > equally sized (or shorter) task. The new TTY layer should still support line disciplines, unfortunately I haven't implemented the line discipline switching (TIOCSETD) yet. I would really prefer to have this in userspace. There are several advantages of implementing this in userspace: - We don't have to port things twice (make it MPSAFE first and port it to the new TTY layer later, or the other way around). - It is less likely to break. The entire userspace TTY and Tun/Tap userspace programming interfaces are more likely to be stable than the kernel interfaces. - It will be easier to port to other operating systems. - Implementing this in userspace could make it easier to configure and more flexible. Any comments/ideas/etc? -- 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-arch/attachments/20080526/21a8c39b/attachment.pgp From sgk at troutmask.apl.washington.edu Mon May 26 16:45:48 2008 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Mon May 26 16:45:51 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> Message-ID: <20080526163844.GA37636@troutmask.apl.washington.edu> On Mon, May 26, 2008 at 05:34:09AM -0700, Ade Lovett wrote: > > idiosyncratic situations (yes, ahc(4), I'm looking at you) for 5+ What's the problem with ahc(4)? My ahc controller is one of the most reliable pieces of hardware that I've purchased. It's also the only interface available to my external DLT tape drive. -- Steve From wjw at digiware.nl Mon May 26 17:51:45 2008 From: wjw at digiware.nl (Willem Jan Withagen) Date: Mon May 26 17:51:54 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <20080526163844.GA37636@troutmask.apl.washington.edu> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> <20080526163844.GA37636@troutmask.apl.washington.edu> Message-ID: <483AF194.2020002@digiware.nl> Steve Kargl wrote: > On Mon, May 26, 2008 at 05:34:09AM -0700, Ade Lovett wrote: >> idiosyncratic situations (yes, ahc(4), I'm looking at you) for 5+ > > What's the problem with ahc(4)? My ahc controller is one of > the most reliable pieces of hardware that I've purchased. > It's also the only interface available to my external DLT > tape drive. Not to forget the large amount of embedded ahc's that got implemented on all kinds of serverbords. I still have quite a large set of customers with such ASUS boards I sold to them over the years. Up 'till now I've been able to keep 'm running with the pace of FreeBSD. Removing this driver would "leave them behind". I can force them to upgrade, but thus far there has been little reason for that (hardware wise). Just my 2 ct's --WjW From scottl at samsco.org Mon May 26 18:13:02 2008 From: scottl at samsco.org (Scott Long) Date: Mon May 26 18:13:11 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> Message-ID: <483AF77D.3030006@samsco.org> Ade Lovett wrote: > It's all well and good to be able to say that the current release of the > kernel supports hardware that hasn't been used, other than in > idiosyncratic situations (yes, ahc(4), I'm looking at you) for 5+ years, > but it seems that we have an opportunity here to break out the Danish > Ax[tm] in anger, and do some heavy-duty culling before 8.0-REL. > Why does this argument on hardware support keep on coming up? For christ sake, every year some yahoo speaks up and declares that he knows what hardware should stay and what should go, and every year that yahoo gets educated on how counterproductive that is to the project. I'll just skip to the end of the recording and say, "NO". Scott From gary.jennejohn at freenet.de Mon May 26 18:58:02 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Mon May 26 18:58:05 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <483AF194.2020002@digiware.nl> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> <20080526163844.GA37636@troutmask.apl.washington.edu> <483AF194.2020002@digiware.nl> Message-ID: <20080526205757.6e49abba@peedub.jennejohn.org> On Mon, 26 May 2008 19:21:24 +0200 Willem Jan Withagen wrote: > Steve Kargl wrote: > > On Mon, May 26, 2008 at 05:34:09AM -0700, Ade Lovett wrote: > >> idiosyncratic situations (yes, ahc(4), I'm looking at you) for 5+ > > > > What's the problem with ahc(4)? My ahc controller is one of > > the most reliable pieces of hardware that I've purchased. > > It's also the only interface available to my external DLT > > tape drive. > > Not to forget the large amount of embedded ahc's that got implemented on > all kinds of serverbords. I still have quite a large set of customers > with such ASUS boards I sold to them over the years. Up 'till now I've > been able to keep 'm running with the pace of FreeBSD. > Removing this driver would "leave them behind". > > I can force them to upgrade, but thus far there has been little reason > for that (hardware wise). > [pruned the over-zealous CCs] Well, one problem with ahc is that it doesn't play nicely with >= 4GB of memory on AMD64. I have ahc and 4GB of memory and have to set hw.physmem="3500m" in /boot/loader.conf to keep it from dumping its cookies at boot time. Otherwise I'm more than happy with my 29160N. --- Gary Jennejohn From ade at freebsd.org Mon May 26 19:08:55 2008 From: ade at freebsd.org (Ade Lovett) Date: Mon May 26 19:09:08 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <483AF77D.3030006@samsco.org> References: <20080524111715.T64552@fledge.watson.org> <1211640498.1510.8.camel@localhost> <20080524165519.K9809@fledge.watson.org> <20080525105726.O39741@fledge.watson.org> <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> <483AF77D.3030006@samsco.org> Message-ID: On May 26, 2008, at 10:46 , Scott Long wrote: > I'll just skip to the end of the recording and say, "NO". I wasn't aware that Web 2.0 did away with implied tags, not forgetting mode(tongue, cheek), etc.. etc.. Ah well. -aDe From phk at phk.freebsd.dk Mon May 26 19:41:12 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon May 26 19:41:17 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: Your message of "Mon, 26 May 2008 18:16:08 +0200." <20080526161608.GE64397@hoeg.nl> Message-ID: <42521.1211829076@critter.freebsd.dk> In message <20080526161608.GE64397@hoeg.nl>, Ed Schouten writes: >The new TTY layer should still support line disciplines, [...] Actually... I think it shouldn't. Line-disc's were introduced to interface weird-ass hardware like digitizing tablets that had very high data rates, but very little information (16 bit X, 16 bit Y and a couple of buttons, like modern mice) which would cost inordinate amounts of CPU time to support in userland on a VAX computer. If_slip.c happened in the kernel because there was no tun device, people cranked the speed up all they could (Hands up: who has changed the Xtal on a VAX serial port for faster SLIP ?) if_ppp happened because that was how if_slip did it. Today there is no longer a market for line disciplines and in practice we have only one: the POSIX mandated "termios", which also emulates the older "termio" ioctls. Anybody who cares to browse the three pages of text that RFC1055 contains, will see that implementing SLIP in userland using tun(4) and the code on the other three pages of RFC1055 is a trivial task not even worthy of a SoC student. PPP over async is already much better handled in ppp(8) thanks to Brians valiant effort back in the stoneage of the internet. We should summarily kill the concept of line disciplines as a modular component and decide that TTYs can be used with termios(4) or raw mode and leave it at that. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From peter at wemm.org Tue May 27 06:15:21 2008 From: peter at wemm.org (Peter Wemm) Date: Tue May 27 06:15:34 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <42521.1211829076@critter.freebsd.dk> References: <20080526161608.GE64397@hoeg.nl> <42521.1211829076@critter.freebsd.dk> Message-ID: On Mon, May 26, 2008 at 12:11 PM, Poul-Henning Kamp wrote: > In message <20080526161608.GE64397@hoeg.nl>, Ed Schouten writes: > >>The new TTY layer should still support line disciplines, [...] > > Actually... I think it shouldn't. > > Line-disc's were introduced to interface weird-ass hardware like > digitizing tablets that had very high data rates, but very little > information (16 bit X, 16 bit Y and a couple of buttons, like modern > mice) which would cost inordinate amounts of CPU time to support > in userland on a VAX computer. > > If_slip.c happened in the kernel because there was no tun device, > people cranked the speed up all they could (Hands up: who has changed > the Xtal on a VAX serial port for faster SLIP ?) > > if_ppp happened because that was how if_slip did it. > > Today there is no longer a market for line disciplines and in > practice we have only one: the POSIX mandated "termios", which also > emulates the older "termio" ioctls. > > Anybody who cares to browse the three pages of text that RFC1055 > contains, will see that implementing SLIP in userland using tun(4) > and the code on the other three pages of RFC1055 is a trivial task > not even worthy of a SoC student. > > PPP over async is already much better handled in ppp(8) thanks > to Brians valiant effort back in the stoneage of the internet. > > We should summarily kill the concept of line disciplines as a > modular component and decide that TTYs can be used with termios(4) > or raw mode and leave it at that. Amen brother!! I'd like if_sl.c and if_ppp.c/ppp_tty.c to go away simply so that we don't have to keep the line discipline switch in its current form. Let the tty layer rewrite have a free hand at doing whatever locking strategy is most appropriate for ttys, without having to worry about line disciplines and the lock order problems that come with if_sl.c. There is a reason why we merged the splnet() and spltty() interrupt masks back when we had spl()s. The tty stack cross called into the network stack via if_sl, and vice versa. ppp_tty.c had a hack to create a swi (thread) to partly hack around this where it was most critical to limit blocking of interrupts. To make this work is likely going to need a full taskq or thread for both if_sl.c and ppp_tty.c. It just isn't worth it. Especially when we have a better option in userland for ppp, and slip is a few dozen lines of code around a if_tun select loop. I've written 75% of what it would take to do slip in userland at least two or three times already, over the last 10 years. It just isn't worth it. Let line disciplines die and give Ed a free hand to do ttys "right". Line disciplines were there so that we could push processing for things like serial mice into the kernel and reduce context switches. We've been doing that in userland for the last 14+ years. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From ed at 80386.nl Tue May 27 06:28:49 2008 From: ed at 80386.nl (Ed Schouten) Date: Tue May 27 06:28:55 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <42521.1211829076@critter.freebsd.dk> References: <20080526161608.GE64397@hoeg.nl> <42521.1211829076@critter.freebsd.dk> Message-ID: <20080527062736.GF64397@hoeg.nl> * Poul-Henning Kamp wrote: > In message <20080526161608.GE64397@hoeg.nl>, Ed Schouten writes: > > >The new TTY layer should still support line disciplines, [...] > > Actually... I think it shouldn't. With the word `should' I meant that it would still be possible to implement multiple line disciplines with the mpsafetty code. But I really think line disciplines should go. What should happen with the NETGRAPHDISC? -- 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-arch/attachments/20080527/49f9a780/attachment.pgp From phk at phk.freebsd.dk Tue May 27 06:37:52 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue May 27 06:37:55 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: Your message of "Tue, 27 May 2008 08:27:36 +0200." <20080527062736.GF64397@hoeg.nl> Message-ID: <45633.1211870269@critter.freebsd.dk> In message <20080527062736.GF64397@hoeg.nl>, Ed Schouten writes: >> >The new TTY layer should still support line disciplines, [...] >> >> Actually... I think it shouldn't. > >With the word `should' I meant that it would still be possible to >implement multiple line disciplines with the mpsafetty code. But I >really think line disciplines should go. No, don't bother. Remove the entire "abstraction" of linedisciplines. >What should happen with the NETGRAPHDISC? It should be done in userland if it is necessary at all. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From ed at 80386.nl Tue May 27 06:44:06 2008 From: ed at 80386.nl (Ed Schouten) Date: Tue May 27 06:44:21 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <45633.1211870269@critter.freebsd.dk> References: <20080527062736.GF64397@hoeg.nl> <45633.1211870269@critter.freebsd.dk> Message-ID: <20080527064253.GG64397@hoeg.nl> * Poul-Henning Kamp wrote: > In message <20080527062736.GF64397@hoeg.nl>, Ed Schouten writes: > > >> >The new TTY layer should still support line disciplines, [...] > >> > >> Actually... I think it shouldn't. > > > >With the word `should' I meant that it would still be possible to > >implement multiple line disciplines with the mpsafetty code. But I > >really think line disciplines should go. > > No, don't bother. Remove the entire "abstraction" of linedisciplines. Your wish is my command. -- 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-arch/attachments/20080527/0654086b/attachment.pgp From julian at elischer.org Tue May 27 07:57:25 2008 From: julian at elischer.org (Julian Elischer) Date: Tue May 27 07:57:29 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <42521.1211829076@critter.freebsd.dk> References: <42521.1211829076@critter.freebsd.dk> Message-ID: <483BBC1B.6040905@elischer.org> Poul-Henning Kamp wrote: > In message <20080526161608.GE64397@hoeg.nl>, Ed Schouten writes: > >> The new TTY layer should still support line disciplines, [...] > > Actually... I think it shouldn't. > > Line-disc's were introduced to interface weird-ass hardware like > digitizing tablets that had very high data rates, but very little > information (16 bit X, 16 bit Y and a couple of buttons, like modern > mice) which would cost inordinate amounts of CPU time to support > in userland on a VAX computer. > > If_slip.c happened in the kernel because there was no tun device, > people cranked the speed up all they could (Hands up: who has changed > the Xtal on a VAX serial port for faster SLIP ?) > > if_ppp happened because that was how if_slip did it. > > Today there is no longer a market for line disciplines and in > practice we have only one: the POSIX mandated "termios", which also > emulates the older "termio" ioctls. > > Anybody who cares to browse the three pages of text that RFC1055 > contains, will see that implementing SLIP in userland using tun(4) > and the code on the other three pages of RFC1055 is a trivial task > not even worthy of a SoC student. > > PPP over async is already much better handled in ppp(8) thanks > to Brians valiant effort back in the stoneage of the internet. > > We should summarily kill the concept of line disciplines as a > modular component and decide that TTYs can be used with termios(4) > or raw mode and leave it at that. > > Poul-Henning > However the line discipline was a very convenient place for netgraph to hook in without leaving the kernel. If you can supply an equally effective way to hook into a serial device in such a way that it appears to be a source/sink of bits then I don't care about line disciplins, but until you have a suggested replacement then leave them alone. There are MANY people using mpd with the netgraph ppp moduel hooked directly to the serial port via the netgraph line discipline. From phk at phk.freebsd.dk Tue May 27 08:04:02 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue May 27 08:04:06 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: Your message of "Tue, 27 May 2008 00:45:31 MST." <483BBC1B.6040905@elischer.org> Message-ID: <51989.1211875439@critter.freebsd.dk> In message <483BBC1B.6040905@elischer.org>, Julian Elischer writes: >However the line discipline was a very convenient place for netgraph >to hook in without leaving the kernel. If you can supply an equally >effective way to hook into a serial device in such a way that it >appears to be a source/sink of bits then I don't care about >line disciplins, but until you have a suggested replacement then leave >them alone. There are MANY people using mpd with the netgraph ppp >moduel hooked directly to the serial port via the netgraph line >discipline. What exact value of "MANY" are we talking about here, and do you have any evidence that the systems in question will be updated to FreeBSD-8.0-RELEASE or later ? If, contrary to my expectation, that you can show a real market here, then we should make a better interface than linedisc for such hooks into serial ports. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From julian at elischer.org Tue May 27 08:06:11 2008 From: julian at elischer.org (Julian Elischer) Date: Tue May 27 08:06:18 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <483BBC1B.6040905@elischer.org> References: <42521.1211829076@critter.freebsd.dk> <483BBC1B.6040905@elischer.org> Message-ID: <483BC0F6.4050700@elischer.org> Julian Elischer wrote: > Poul-Henning Kamp wrote: >> In message <20080526161608.GE64397@hoeg.nl>, Ed Schouten writes: >> >>> The new TTY layer should still support line disciplines, [...] >> >> Actually... I think it shouldn't. >> >> Line-disc's were introduced to interface weird-ass hardware like >> digitizing tablets that had very high data rates, but very little >> information (16 bit X, 16 bit Y and a couple of buttons, like modern >> mice) which would cost inordinate amounts of CPU time to support >> in userland on a VAX computer. >> >> If_slip.c happened in the kernel because there was no tun device, >> people cranked the speed up all they could (Hands up: who has changed >> the Xtal on a VAX serial port for faster SLIP ?) >> >> if_ppp happened because that was how if_slip did it. >> >> Today there is no longer a market for line disciplines and in >> practice we have only one: the POSIX mandated "termios", which also >> emulates the older "termio" ioctls. >> >> Anybody who cares to browse the three pages of text that RFC1055 >> contains, will see that implementing SLIP in userland using tun(4) >> and the code on the other three pages of RFC1055 is a trivial task >> not even worthy of a SoC student. >> >> PPP over async is already much better handled in ppp(8) thanks >> to Brians valiant effort back in the stoneage of the internet. >> >> We should summarily kill the concept of line disciplines as a >> modular component and decide that TTYs can be used with termios(4) >> or raw mode and leave it at that. >> >> Poul-Henning >> > > > However the line discipline was a very convenient place for netgraph to > hook in without leaving the kernel. If you can supply an equally > effective way to hook into a serial device in such a way that it appears > to be a source/sink of bits then I don't care about > line disciplins, but until you have a suggested replacement then leave > them alone. There are MANY people using mpd with the netgraph ppp moduel > hooked directly to the serial port via the netgraph line discipline. p.s "do it in userland" is not the right answer, but it should be able to hook into netgraph without all the requirements that were needed for a line discipline. let me contact you independently and we 'll see what can be done. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From julian at elischer.org Tue May 27 08:12:41 2008 From: julian at elischer.org (Julian Elischer) Date: Tue May 27 08:12:46 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <51989.1211875439@critter.freebsd.dk> References: <51989.1211875439@critter.freebsd.dk> Message-ID: <483BC27C.6010102@elischer.org> Poul-Henning Kamp wrote: > In message <483BBC1B.6040905@elischer.org>, Julian Elischer writes: > >> However the line discipline was a very convenient place for netgraph >> to hook in without leaving the kernel. If you can supply an equally >> effective way to hook into a serial device in such a way that it >> appears to be a source/sink of bits then I don't care about >> line disciplins, but until you have a suggested replacement then leave >> them alone. There are MANY people using mpd with the netgraph ppp >> moduel hooked directly to the serial port via the netgraph line >> discipline. > > What exact value of "MANY" are we talking about here, and do you > have any evidence that the systems in question will be updated > to FreeBSD-8.0-RELEASE or later ? judging by the bug reports when things get broken there are still a lot of people connected to the internet via dial up lines in places off the beaten track, and still a lot of people who when travelling do use dialup still. Some of these also use mpd. I can not say how many plan to keep using this in the future but it may be that the simplest answer is a completely separate sio driver that just has netgraph hooks. I haven't talked with Ed yet but there may be may ways to solve this problem. One that comes to mind is tha tthe way netgraph hooks to other modules assumes a possible queueing of data, and that decoupling could make it a lot easier to connect tehm that was required for slip and ppp. > > If, contrary to my expectation, that you can show a real market > here, then we should make a better interface than linedisc for > such hooks into serial ports. > From rwatson at FreeBSD.org Tue May 27 08:54:57 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue May 27 08:55:02 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <45633.1211870269@critter.freebsd.dk> References: <45633.1211870269@critter.freebsd.dk> Message-ID: <20080527095317.R35026@fledge.watson.org> On Tue, 27 May 2008, Poul-Henning Kamp wrote: > In message <20080527062736.GF64397@hoeg.nl>, Ed Schouten writes: > >>>> The new TTY layer should still support line disciplines, [...] >>> >>> Actually... I think it shouldn't. >> >> With the word `should' I meant that it would still be possible to implement >> multiple line disciplines with the mpsafetty code. But I really think line >> disciplines should go. > > No, don't bother. Remove the entire "abstraction" of linedisciplines. > >> What should happen with the NETGRAPHDISC? > > It should be done in userland if it is necessary at all. It sounds like there is some disagreement on this point, given that that would require byte streams from serial lines to go into userspace just to be re-injected into the kernel in order to enter netgraph. Rather than do that, a more sensible route would be to look at converting ng_tty from a line discipline into a much more constrained set of I/O hooks, selected using the same ioctl but presumably a different discipline name. Unfortunately, it's not clear that snp would use the same hooks, as Netgraph presumably wants to eat the input, whereas snp just wants a copy, but perhaps there's a clean way to capture that distinction. Robert N M Watson Computer Laboratory University of Cambridge From ed at 80386.nl Tue May 27 13:07:34 2008 From: ed at 80386.nl (Ed Schouten) Date: Tue May 27 13:07:41 2008 Subject: Simplifying devfs: minor == unit Message-ID: <20080527130615.GJ64397@hoeg.nl> 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: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080527/b7036453/attachment.pgp From bms at FreeBSD.org Tue May 27 15:19:08 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Tue May 27 15:19:21 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080527064253.GG64397@hoeg.nl> References: <20080527062736.GF64397@hoeg.nl> <45633.1211870269@critter.freebsd.dk> <20080527064253.GG64397@hoeg.nl> Message-ID: <483C2666.7010608@FreeBSD.org> Ed Schouten wrote: >>> With the word `should' I meant that it would still be possible to >>> implement multiple line disciplines with the mpsafetty code. But I >>> really think line disciplines should go. >>> >> No, don't bother. Remove the entire "abstraction" of linedisciplines. >> > > Your wish is my command. > Like Julian and Robert said, please don't break Netgraph. It still needs to hook into tty at a very low level; and the components such as Bluetooth which can use ttys for low level stream processing, are built on Netgraph. Both SLIP and PPP can be built using Netgraph. Other than that, line disciplines can go away. From kostikbel at gmail.com Tue May 27 15:22:42 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue May 27 15:22:44 2008 Subject: Simplifying devfs: minor == unit In-Reply-To: <20080527130615.GJ64397@hoeg.nl> References: <20080527130615.GJ64397@hoeg.nl> Message-ID: <20080527150244.GN21317@deviant.kiev.zoral.com.ua> On Tue, May 27, 2008 at 03:06:15PM +0200, Ed Schouten wrote: > Hello everyone, > > Right before I left to BSDCan I was looking at the devfs code. When I > started hacking the TTY code, I discovered minor/unit numbers are still > actively used within the FreeBSD kernel, even though they are never > exposed to userspace. Devfs automatically generates an inode number for > each device. Right now, st_rdev is always equal to st_ino, which still > guarantees device numbers are unique throughout the system. > > In an experimental branch in Perforce, I decided to see what would > happen if I would completely remove minor numbers from device drivers. > This means make_dev()'s minor argument is removed, but also the minor(), > unit2minor(), etc. functions. Drivers could use si_drv0 directly, just > like si_drv1 and si_drv2 are used right now. > > This doesn't seem to be possible because of the design of the device > cloner (not the eventhandler, just the clone_* routines), which > preallocates an unnamed device with a specific unit numer, which can > later be passed to make_dev(). > > This is why I want to do this in little steps right now. I was thinking > about doing the following: > > - si_drv0 currently contains the minor number. We could alter the > minor2unit(), etc. routines to make minor numbers equal to unit > numbers. This means most routines will now become a no-op. See > attachment. > > - When that hits the tree, we could decide to run a big regexp on the > source code to make drivers use si_drv0 directly. > > - I've seen most drivers only use the device cloner, because they need > descriptor local storage. It turns out more drivers need this than I > initially thought. kib@ has a patch for this, so I hope this gets > committed one of these {days,weeks,months}. The patch was committed ~ a week ago. > > - After we've got file descriptor local storage, I think we can live > without the cloner. This means we could consider removing the minor > number argument from make_dev(), removing the unique unit number > restriction we currently have inside devfs, which causes many drivers > to use number pools for no obvious reason. I think we cannot live without clones regardless of devfs_cdevpriv. The model assumed for the pty, snp and probably several other devices actually requires new cdev instead of the priv data. > > I was thinking about discussing this patch with my mentor + committing > it somewhere in the nearby future. Any comments? Making minor == unit number looks to be not a bad idea, please, look at the saga of the tty_pty.c revs. 1.153, 156, 1.157. Making the devices use si_drv0 directly probably is not so good since we remove the indirection layer that is already present and allows for some (minor) freedom in the devfs/kern_conf implementation. -------------- 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-arch/attachments/20080527/7065b6b5/attachment.pgp From ed at 80386.nl Tue May 27 16:59:15 2008 From: ed at 80386.nl (Ed Schouten) Date: Tue May 27 16:59:18 2008 Subject: Simplifying devfs: minor == unit In-Reply-To: <20080527150244.GN21317@deviant.kiev.zoral.com.ua> References: <20080527130615.GJ64397@hoeg.nl> <20080527150244.GN21317@deviant.kiev.zoral.com.ua> Message-ID: <20080527165753.GK64397@hoeg.nl> * Kostik Belousov wrote: > > - I've seen most drivers only use the device cloner, because they need > > descriptor local storage. It turns out more drivers need this than I > > initially thought. kib@ has a patch for this, so I hope this gets > > committed one of these {days,weeks,months}. > The patch was committed ~ a week ago. Great. Looks like I wasn't paying attention back then. > > - After we've got file descriptor local storage, I think we can live > > without the cloner. This means we could consider removing the minor > > number argument from make_dev(), removing the unique unit number > > restriction we currently have inside devfs, which causes many drivers > > to use number pools for no obvious reason. > I think we cannot live without clones regardless of devfs_cdevpriv. > The model assumed for the pty, snp and probably several other devices > actually requires new cdev instead of the priv data. The pty driver does not use the clone_* interface. It only uses the eventhandler, which should indeed be left intact. The snp driver does use the clone_* interface, but not in a way that can't be done using the eventhandler, validating the device name and calling make_dev() directly. Please take a look at src/usr.sbin/watch/watch.c:open_snp(). We might as well turn snp(4) into a single /dev/snp, where the kernel space driver uses per-descriptor data to distinguish the instances. This provides some advantages: - No more silly open()-loops. - A system administrator can change the permissions on /dev/snp, which automatically sets a system wide policy, instead on one of the device nodes. - We don't fill up the system with a lot of unused nodes. for i in `seq 1000` do ls /dev/bpf$i > /dev/null done > > I was thinking about discussing this patch with my mentor + committing > > it somewhere in the nearby future. Any comments? > > Making minor == unit number looks to be not a bad idea, please, look at > the saga of the tty_pty.c revs. 1.153, 156, 1.157. Making the devices use > si_drv0 directly probably is not so good since we remove the indirection > layer that is already present and allows for some (minor) freedom in the > devfs/kern_conf implementation. But why isn't this done for si_drv1 and si_drv2 then? My idea is to turn si_drv0 in an integer field that can be freely used. There is reason to force a policy on this field. -- 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-arch/attachments/20080527/d3848415/attachment.pgp From peterjeremy at optushome.com.au Tue May 27 17:01:50 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue May 27 17:01:56 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <42521.1211829076@critter.freebsd.dk> References: <20080526161608.GE64397@hoeg.nl> <42521.1211829076@critter.freebsd.dk> Message-ID: <20080527085913.GD1469@server.vk2pj.dyndns.org> On 2008-May-26 19:11:16 +0000, Poul-Henning Kamp wrote: >We should summarily kill the concept of line disciplines as a >modular component and decide that TTYs can be used with termios(4) >or raw mode and leave it at that. streams anyone? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- 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-arch/attachments/20080527/462ffe2d/attachment.pgp From xcllnt at mac.com Tue May 27 17:02:33 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue May 27 17:02:40 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <483BC27C.6010102@elischer.org> References: <51989.1211875439@critter.freebsd.dk> <483BC27C.6010102@elischer.org> Message-ID: <5229B4D7-40F0-4D45-93F1-244FA05E0304@mac.com> On May 27, 2008, at 1:12 AM, Julian Elischer wrote: > judging by the bug reports when things get broken there are still a > lot of people connected to the internet via dial up lines in places > off the beaten track, and still a lot of people who when travelling > do use dialup still. Some of these also use mpd. I can not say how > many plan to keep using this in the future but it may be that the > simplest answer is a completely separate sio driver that > just has netgraph hooks. I haven't talked with Ed yet but there > may be may ways to solve this problem. Take a look at uart(4). It has been designed to allow different kernel interfaces. It currently supports TTYs and keyboards. It should not be too hard to have it hook into netgraph. FYI, -- Marcel Moolenaar xcllnt@mac.com From julian at elischer.org Tue May 27 17:22:25 2008 From: julian at elischer.org (Julian Elischer) Date: Tue May 27 17:22:29 2008 Subject: Simplifying devfs: minor == unit In-Reply-To: <20080527150244.GN21317@deviant.kiev.zoral.com.ua> References: <20080527130615.GJ64397@hoeg.nl> <20080527150244.GN21317@deviant.kiev.zoral.com.ua> Message-ID: <483C4358.2050707@elischer.org> Kostik Belousov wrote: > On Tue, May 27, 2008 at 03:06:15PM +0200, Ed Schouten wrote: >> Hello everyone, >> >> Right before I left to BSDCan I was looking at the devfs code. When I >> started hacking the TTY code, I discovered minor/unit numbers are still >> actively used within the FreeBSD kernel, even though they are never >> exposed to userspace. Devfs automatically generates an inode number for >> each device. Right now, st_rdev is always equal to st_ino, which still >> guarantees device numbers are unique throughout the system. >> >> In an experimental branch in Perforce, I decided to see what would >> happen if I would completely remove minor numbers from device drivers. >> This means make_dev()'s minor argument is removed, but also the minor(), >> unit2minor(), etc. functions. Drivers could use si_drv0 directly, just >> like si_drv1 and si_drv2 are used right now. >> >> This doesn't seem to be possible because of the design of the device >> cloner (not the eventhandler, just the clone_* routines), which >> preallocates an unnamed device with a specific unit numer, which can >> later be passed to make_dev(). >> >> This is why I want to do this in little steps right now. I was thinking >> about doing the following: >> >> - si_drv0 currently contains the minor number. We could alter the >> minor2unit(), etc. routines to make minor numbers equal to unit >> numbers. This means most routines will now become a no-op. See >> attachment. >> >> - When that hits the tree, we could decide to run a big regexp on the >> source code to make drivers use si_drv0 directly. >> >> - I've seen most drivers only use the device cloner, because they need >> descriptor local storage. It turns out more drivers need this than I >> initially thought. kib@ has a patch for this, so I hope this gets >> committed one of these {days,weeks,months}. > The patch was committed ~ a week ago. >> - After we've got file descriptor local storage, I think we can live >> without the cloner. This means we could consider removing the minor >> number argument from make_dev(), removing the unique unit number >> restriction we currently have inside devfs, which causes many drivers >> to use number pools for no obvious reason. > I think we cannot live without clones regardless of devfs_cdevpriv. > The model assumed for the pty, snp and probably several other devices > actually requires new cdev instead of the priv data. > >> I was thinking about discussing this patch with my mentor + committing >> it somewhere in the nearby future. Any comments? > > Making minor == unit number looks to be not a bad idea, please, look at > the saga of the tty_pty.c revs. 1.153, 156, 1.157. Making the devices use > si_drv0 directly probably is not so good since we remove the indirection > layer that is already present and allows for some (minor) freedom in the > devfs/kern_conf implementation. Make sure that old binaries that expect the minor number sot be on a certain format are not broken.. try run some old 2.2.5 binaries in a 2.2.5 jail with /dev mounted and make sure that things like ptys work. From ed at 80386.nl Tue May 27 17:28:21 2008 From: ed at 80386.nl (Ed Schouten) Date: Tue May 27 17:28:23 2008 Subject: Simplifying devfs: minor == unit In-Reply-To: <483C4358.2050707@elischer.org> References: <20080527130615.GJ64397@hoeg.nl> <20080527150244.GN21317@deviant.kiev.zoral.com.ua> <483C4358.2050707@elischer.org> Message-ID: <20080527172700.GM64397@hoeg.nl> * Julian Elischer wrote: > Make sure that old binaries that expect the minor number sot be on a > certain format are not broken.. > > try run some old 2.2.5 binaries in a 2.2.5 jail with /dev mounted and > make sure that things like ptys work. This should not be a problem. Even though they are called minor numbers, they must not be confused with the device minor numbers which are shown in /dev. These are always the same as the inode number of the device. The minor numbers which are currently being used inside the kernel have no actual purpose, but are only there to remain compatible with certain KPI's. -- 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-arch/attachments/20080527/1de909c1/attachment.pgp From julian at elischer.org Tue May 27 17:33:15 2008 From: julian at elischer.org (Julian Elischer) Date: Tue May 27 17:33:21 2008 Subject: Simplifying devfs: minor == unit In-Reply-To: <20080527172700.GM64397@hoeg.nl> References: <20080527130615.GJ64397@hoeg.nl> <20080527150244.GN21317@deviant.kiev.zoral.com.ua> <483C4358.2050707@elischer.org> <20080527172700.GM64397@hoeg.nl> Message-ID: <483C45E1.2040707@elischer.org> Ed Schouten wrote: > * Julian Elischer wrote: >> Make sure that old binaries that expect the minor number sot be on a >> certain format are not broken.. >> >> try run some old 2.2.5 binaries in a 2.2.5 jail with /dev mounted and >> make sure that things like ptys work. > > This should not be a problem. Even though they are called minor numbers, > they must not be confused with the device minor numbers which are shown > in /dev. These are always the same as the inode number of the device. > > The minor numbers which are currently being used inside the kernel have > no actual purpose, but are only there to remain compatible with certain > KPI's. > as long as that is proved to be true.. From julian at elischer.org Tue May 27 17:50:14 2008 From: julian at elischer.org (Julian Elischer) Date: Tue May 27 17:50:21 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <5229B4D7-40F0-4D45-93F1-244FA05E0304@mac.com> References: <51989.1211875439@critter.freebsd.dk> <483BC27C.6010102@elischer.org> <5229B4D7-40F0-4D45-93F1-244FA05E0304@mac.com> Message-ID: <483C49DC.3080108@elischer.org> Marcel Moolenaar wrote: > On May 27, 2008, at 1:12 AM, Julian Elischer wrote: > >> judging by the bug reports when things get broken there are still a >> lot of people connected to the internet via dial up lines in places >> off the beaten track, and still a lot of people who when travelling >> do use dialup still. Some of these also use mpd. I can not say how >> many plan to keep using this in the future but it may be that the >> simplest answer is a completely separate sio driver that >> just has netgraph hooks. I haven't talked with Ed yet but there >> may be may ways to solve this problem. > > Take a look at uart(4). It has been designed to allow different > kernel interfaces. It currently supports TTYs and keyboards. It > should not be too hard to have it hook into netgraph. > > FYI, > While this is a good idea on it's own, the difference between what that achieves and what a line discipline achieves is that a line disciplin is hardware independent and can even be used on a virtual device. From bms at FreeBSD.org Tue May 27 17:53:28 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Tue May 27 17:53:32 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <483C49DC.3080108@elischer.org> References: <51989.1211875439@critter.freebsd.dk> <483BC27C.6010102@elischer.org> <5229B4D7-40F0-4D45-93F1-244FA05E0304@mac.com> <483C49DC.3080108@elischer.org> Message-ID: <483C4A94.4000107@FreeBSD.org> Julian Elischer wrote: > > While this is a good idea on it's own, the difference between > what that achieves and what a line discipline achieves is that > a line disciplin is hardware independent and can even be used > on a virtual device. I was under the impression that the back-end for UART was light weight enough that it could be used as a virtual device. For example: Many years ago I tried to get the WinModem working in my IBM ThinkPad T23. UART lends itself well to being a wrapper for the DSP microcode without having any of the historical tty baggage. In the case of UART the "translation shim" moves from on top of the device node to underneath, in much the same way as has happened for GEOM. From xcllnt at mac.com Tue May 27 18:11:41 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue May 27 18:11:46 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <483C49DC.3080108@elischer.org> References: <51989.1211875439@critter.freebsd.dk> <483BC27C.6010102@elischer.org> <5229B4D7-40F0-4D45-93F1-244FA05E0304@mac.com> <483C49DC.3080108@elischer.org> Message-ID: <260F636A-8F72-411B-AED9-B029E1964003@mac.com> On May 27, 2008, at 10:50 AM, Julian Elischer wrote: > Marcel Moolenaar wrote: >> On May 27, 2008, at 1:12 AM, Julian Elischer wrote: >>> judging by the bug reports when things get broken there are still a >>> lot of people connected to the internet via dial up lines in places >>> off the beaten track, and still a lot of people who when travelling >>> do use dialup still. Some of these also use mpd. I can not say how >>> many plan to keep using this in the future but it may be that the >>> simplest answer is a completely separate sio driver that >>> just has netgraph hooks. I haven't talked with Ed yet but there >>> may be may ways to solve this problem. >> Take a look at uart(4). It has been designed to allow different >> kernel interfaces. It currently supports TTYs and keyboards. It >> should not be too hard to have it hook into netgraph. >> FYI, > > > While this is a good idea on it's own, the difference between > what that achieves and what a line discipline achieves is that > a line disciplin is hardware independent and can even be used > on a virtual device. True, but you said: "... the simplest answer is a completely separate sio driver...". This, besides not being true, is just as hardware dependent as uart(4) is. It seems to me that you've conveniently changed the subject to match your point of view :-) -- Marcel Moolenaar xcllnt@mac.com From kostikbel at gmail.com Tue May 27 19:13:29 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue May 27 19:13:32 2008 Subject: Simplifying devfs: minor == unit In-Reply-To: <20080527165753.GK64397@hoeg.nl> References: <20080527130615.GJ64397@hoeg.nl> <20080527150244.GN21317@deviant.kiev.zoral.com.ua> <20080527165753.GK64397@hoeg.nl> Message-ID: <20080527191302.GS21317@deviant.kiev.zoral.com.ua> On Tue, May 27, 2008 at 06:57:53PM +0200, Ed Schouten wrote: > * Kostik Belousov wrote: > > > - I've seen most drivers only use the device cloner, because they need > > > descriptor local storage. It turns out more drivers need this than I > > > initially thought. kib@ has a patch for this, so I hope this gets > > > committed one of these {days,weeks,months}. > > The patch was committed ~ a week ago. > > Great. Looks like I wasn't paying attention back then. > > > > - After we've got file descriptor local storage, I think we can live > > > without the cloner. This means we could consider removing the minor > > > number argument from make_dev(), removing the unique unit number > > > restriction we currently have inside devfs, which causes many drivers > > > to use number pools for no obvious reason. > > I think we cannot live without clones regardless of devfs_cdevpriv. > > The model assumed for the pty, snp and probably several other devices > > actually requires new cdev instead of the priv data. > > The pty driver does not use the clone_* interface. It only uses the > eventhandler, which should indeed be left intact. The snp driver does > use the clone_* interface, but not in a way that can't be done using the > eventhandler, validating the device name and calling make_dev() > directly. Ok. > > Please take a look at src/usr.sbin/watch/watch.c:open_snp(). We might as > well turn snp(4) into a single /dev/snp, where the kernel space driver > uses per-descriptor data to distinguish the instances. This provides > some advantages: > > - No more silly open()-loops. > > - A system administrator can change the permissions on /dev/snp, which > automatically sets a system wide policy, instead on one of the device > nodes. > > - We don't fill up the system with a lot of unused nodes. > > for i in `seq 1000` > do > ls /dev/bpf$i > /dev/null > done Please, do not overuse the cdevpriv data (I am not speaking about snp/watch ATM, each case requires careful decision). Using cdevpriv disables some features that may be provided by the clones, i.e. actual cdevs. For example, you cannot have several independent opens operate on the same instance. > > > > I was thinking about discussing this patch with my mentor + committing > > > it somewhere in the nearby future. Any comments? > > > > Making minor == unit number looks to be not a bad idea, please, look at > > the saga of the tty_pty.c revs. 1.153, 156, 1.157. Making the devices use > > si_drv0 directly probably is not so good since we remove the indirection > > layer that is already present and allows for some (minor) freedom in the > > devfs/kern_conf implementation. > > But why isn't this done for si_drv1 and si_drv2 then? My idea is to turn > si_drv0 in an integer field that can be freely used. There is reason to > force a policy on this field. I would argue that si_drv{1,2} are the warts. I do not want to point finger at the drivers, but I remember there is a representative subset of them using si_drv in the racy way when simultaneous open/close is performed. I would much prefer to have some KPI there instead of the direct access into cdev members. -------------- 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-arch/attachments/20080527/0d570ab1/attachment.pgp From ed at 80386.nl Tue May 27 19:34:04 2008 From: ed at 80386.nl (Ed Schouten) Date: Tue May 27 19:34:06 2008 Subject: Simplifying devfs: minor == unit In-Reply-To: <20080527191302.GS21317@deviant.kiev.zoral.com.ua> References: <20080527130615.GJ64397@hoeg.nl> <20080527150244.GN21317@deviant.kiev.zoral.com.ua> <20080527165753.GK64397@hoeg.nl> <20080527191302.GS21317@deviant.kiev.zoral.com.ua> Message-ID: <20080527193242.GN64397@hoeg.nl> * Kostik Belousov wrote: > On Tue, May 27, 2008 at 06:57:53PM +0200, Ed Schouten wrote: > > > > Please take a look at src/usr.sbin/watch/watch.c:open_snp(). We might as > > well turn snp(4) into a single /dev/snp, where the kernel space driver > > uses per-descriptor data to distinguish the instances. This provides > > some advantages: > > > > - No more silly open()-loops. > > > > - A system administrator can change the permissions on /dev/snp, which > > automatically sets a system wide policy, instead on one of the device > > nodes. > > > > - We don't fill up the system with a lot of unused nodes. > > > > for i in `seq 1000` > > do > > ls /dev/bpf$i > /dev/null > > done > Please, do not overuse the cdevpriv data (I am not speaking about snp/watch > ATM, each case requires careful decision). Using cdevpriv disables some > features that may be provided by the clones, i.e. actual cdevs. For example, > you cannot have several independent opens operate on the same instance. I'll take a closer look at how it works when time permits. Do you mind if I commit the minor == unit patch one of these days/weeks? Thanks for your feedback! -- 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-arch/attachments/20080527/b8211a9d/attachment.pgp From kostikbel at gmail.com Tue May 27 19:48:43 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue May 27 19:48:50 2008 Subject: Simplifying devfs: minor == unit In-Reply-To: <20080527193242.GN64397@hoeg.nl> References: <20080527130615.GJ64397@hoeg.nl> <20080527150244.GN21317@deviant.kiev.zoral.com.ua> <20080527165753.GK64397@hoeg.nl> <20080527191302.GS21317@deviant.kiev.zoral.com.ua> <20080527193242.GN64397@hoeg.nl> Message-ID: <20080527194823.GT21317@deviant.kiev.zoral.com.ua> On Tue, May 27, 2008 at 09:32:42PM +0200, Ed Schouten wrote: > * Kostik Belousov wrote: > > On Tue, May 27, 2008 at 06:57:53PM +0200, Ed Schouten wrote: > > > > > > Please take a look at src/usr.sbin/watch/watch.c:open_snp(). We might as > > > well turn snp(4) into a single /dev/snp, where the kernel space driver > > > uses per-descriptor data to distinguish the instances. This provides > > > some advantages: > > > > > > - No more silly open()-loops. > > > > > > - A system administrator can change the permissions on /dev/snp, which > > > automatically sets a system wide policy, instead on one of the device > > > nodes. > > > > > > - We don't fill up the system with a lot of unused nodes. > > > > > > for i in `seq 1000` > > > do > > > ls /dev/bpf$i > /dev/null > > > done > > Please, do not overuse the cdevpriv data (I am not speaking about snp/watch > > ATM, each case requires careful decision). Using cdevpriv disables some > > features that may be provided by the clones, i.e. actual cdevs. For example, > > you cannot have several independent opens operate on the same instance. > > I'll take a closer look at how it works when time permits. > > Do you mind if I commit the minor == unit patch one of these days/weeks? > In fact, I do not understand why you leave the UMINORMASK stuff. It makes no sense with the unit == minor, IMHO. -------------- 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-arch/attachments/20080527/d4aca86a/attachment.pgp From ed at 80386.nl Tue May 27 19:50:03 2008 From: ed at 80386.nl (Ed Schouten) Date: Tue May 27 19:50:05 2008 Subject: Simplifying devfs: minor == unit In-Reply-To: <20080527194823.GT21317@deviant.kiev.zoral.com.ua> References: <20080527130615.GJ64397@hoeg.nl> <20080527150244.GN21317@deviant.kiev.zoral.com.ua> <20080527165753.GK64397@hoeg.nl> <20080527191302.GS21317@deviant.kiev.zoral.com.ua> <20080527193242.GN64397@hoeg.nl> <20080527194823.GT21317@deviant.kiev.zoral.com.ua> Message-ID: <20080527194840.GO64397@hoeg.nl> * Kostik Belousov wrote: > In fact, I do not understand why you leave the UMINORMASK stuff. It makes > no sense with the unit == minor, IMHO. That's because the uminor() and umajor() routines operate on user device numbers (dev_t's). We need to leave those intact, to make things like the binary compat work. -- 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-arch/attachments/20080527/9c1c1ade/attachment.pgp From kostikbel at gmail.com Tue May 27 20:10:23 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue May 27 20:10:27 2008 Subject: Simplifying devfs: minor == unit In-Reply-To: <20080527194840.GO64397@hoeg.nl> References: <20080527130615.GJ64397@hoeg.nl> <20080527150244.GN21317@deviant.kiev.zoral.com.ua> <20080527165753.GK64397@hoeg.nl> <20080527191302.GS21317@deviant.kiev.zoral.com.ua> <20080527193242.GN64397@hoeg.nl> <20080527194823.GT21317@deviant.kiev.zoral.com.ua> <20080527194840.GO64397@hoeg.nl> Message-ID: <20080527201002.GU21317@deviant.kiev.zoral.com.ua> On Tue, May 27, 2008 at 09:48:40PM +0200, Ed Schouten wrote: > * Kostik Belousov wrote: > > In fact, I do not understand why you leave the UMINORMASK stuff. It makes > > no sense with the unit == minor, IMHO. > > That's because the uminor() and umajor() routines operate on user device > numbers (dev_t's). We need to leave those intact, to make things like > the binary compat work. What does it mean to take bits 8-15 from the the unit number to denote some fictitious major ? And, what binary compatibility you talk about ? You changed the layout of the encoding for the minor, but still take the major from it, while there is simply no space for major after your patch, and definitely not in [8:15]. Also, look at the sys/types.h: #ifndef _KERNEL /* * minor() gives a cookie instead of an index since we don't want to * change the meanings of bits 0-15 or waste time and space shifting * bits 16-31 for devices that don't use them. */ #define major(x) ((int)(((u_int)(x) >> 8)&0xff)) /* major number */ #define minor(x) ((int)((x)&0xffff00ff)) /* minor number */ #endif /* !_KERNEL */ #define makedev(x,y) ((dev_t)(((x) << 8) | (y))) /* create dev_t */ I think, if you want to do the change you proposed, the minors for cdevs shall be cleanly separated from the major/minor something, the later has no relations with the cdevs in the current FreeBSD. I.e., in your patch, the uminor() can and shall be made identity function, to match minor2unit() and unit2minor(), and umajor() shall just return 0. It would be nice to verify that the linuxolator emulation still works (look at the compat/linux/linux_stats.c). -------------- 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-arch/attachments/20080527/a410a5eb/attachment.pgp From ed at 80386.nl Tue May 27 20:24:55 2008 From: ed at 80386.nl (Ed Schouten) Date: Tue May 27 20:25:01 2008 Subject: Simplifying devfs: minor == unit In-Reply-To: <20080527201002.GU21317@deviant.kiev.zoral.com.ua> References: <20080527130615.GJ64397@hoeg.nl> <20080527150244.GN21317@deviant.kiev.zoral.com.ua> <20080527165753.GK64397@hoeg.nl> <20080527191302.GS21317@deviant.kiev.zoral.com.ua> <20080527193242.GN64397@hoeg.nl> <20080527194823.GT21317@deviant.kiev.zoral.com.ua> <20080527194840.GO64397@hoeg.nl> <20080527201002.GU21317@deviant.kiev.zoral.com.ua> Message-ID: <20080527202332.GP64397@hoeg.nl> * Kostik Belousov wrote: > On Tue, May 27, 2008 at 09:48:40PM +0200, Ed Schouten wrote: > > * Kostik Belousov wrote: > > > In fact, I do not understand why you leave the UMINORMASK stuff. It makes > > > no sense with the unit == minor, IMHO. > > > > That's because the uminor() and umajor() routines operate on user device > > numbers (dev_t's). We need to leave those intact, to make things like > > the binary compat work. > > What does it mean to take bits 8-15 from the the unit number to denote > some fictitious major ? And, what binary compatibility you talk about > ? You changed the layout of the encoding for the minor, but still take > the major from it, while there is simply no space for major after your > patch, and definitely not in [8:15]. > > Also, look at the sys/types.h: > > #ifndef _KERNEL > /* > * minor() gives a cookie instead of an index since we don't want to > * change the meanings of bits 0-15 or waste time and space shifting > * bits 16-31 for devices that don't use them. > */ > #define major(x) ((int)(((u_int)(x) >> 8)&0xff)) /* major number */ > #define minor(x) ((int)((x)&0xffff00ff)) /* minor number */ > #endif /* !_KERNEL */ > > #define makedev(x,y) ((dev_t)(((x) << 8) | (y))) /* create dev_t */ > > I think, if you want to do the change you proposed, the minors for cdevs > shall be cleanly separated from the major/minor something, the later has no > relations with the cdevs in the current FreeBSD. > > I.e., in your patch, the uminor() can and shall be made identity > function, to match minor2unit() and unit2minor(), and umajor() shall just > return 0. > > It would be nice to verify that the linuxolator emulation still works > (look at the compat/linux/linux_stats.c). Wait. uminor() and umajor() are used on the device number that's returned by dev2udev(). They are only used to obtain the major and minor number from a user device number, which can then be converted to a native Linux/SVR4/etc dev_t. We should not turn this into a 1:1 mapping. The values of dev2unit(cdev) and minor(cdev) should _never_ end up in userspace. It's quite confusing. MAXMINOR currently has a redundant meaning inside the kernel. It is used for both the user major/minor numbers, but also the kernel ones minor numbers (we don't store major numbers there), which is why I renamed it to UMINORMASK while there. -- 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-arch/attachments/20080527/4516fd78/attachment.pgp From julian at elischer.org Tue May 27 20:49:14 2008 From: julian at elischer.org (Julian Elischer) Date: Tue May 27 20:49:25 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <260F636A-8F72-411B-AED9-B029E1964003@mac.com> References: <51989.1211875439@critter.freebsd.dk> <483BC27C.6010102@elischer.org> <5229B4D7-40F0-4D45-93F1-244FA05E0304@mac.com> <483C49DC.3080108@elischer.org> <260F636A-8F72-411B-AED9-B029E1964003@mac.com> Message-ID: <483C73D0.8060709@elischer.org> Marcel Moolenaar wrote: > > On May 27, 2008, at 10:50 AM, Julian Elischer wrote: > >> Marcel Moolenaar wrote: >>> On May 27, 2008, at 1:12 AM, Julian Elischer wrote: >>>> judging by the bug reports when things get broken there are still a >>>> lot of people connected to the internet via dial up lines in places >>>> off the beaten track, and still a lot of people who when travelling >>>> do use dialup still. Some of these also use mpd. I can not say how >>>> many plan to keep using this in the future but it may be that the >>>> simplest answer is a completely separate sio driver that >>>> just has netgraph hooks. I haven't talked with Ed yet but there >>>> may be may ways to solve this problem. >>> Take a look at uart(4). It has been designed to allow different >>> kernel interfaces. It currently supports TTYs and keyboards. It >>> should not be too hard to have it hook into netgraph. >>> FYI, >> >> >> While this is a good idea on it's own, the difference between >> what that achieves and what a line discipline achieves is that >> a line disciplin is hardware independent and can even be used >> on a virtual device. > > True, but you said: > "... the simplest answer is a completely separate sio driver...". > > This, besides not being true, is just as hardware dependent as > uart(4) is. It seems to me that you've conveniently changed the > subject to match your point of view :-) yep :-) we need to decide if the aim is to support just serial ports or any 'tty'. From xcllnt at mac.com Tue May 27 21:04:28 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue May 27 21:04:32 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <483C73D0.8060709@elischer.org> References: <51989.1211875439@critter.freebsd.dk> <483BC27C.6010102@elischer.org> <5229B4D7-40F0-4D45-93F1-244FA05E0304@mac.com> <483C49DC.3080108@elischer.org> <260F636A-8F72-411B-AED9-B029E1964003@mac.com> <483C73D0.8060709@elischer.org> Message-ID: <32DC950C-7FE6-41D5-8935-60E7A1356EFA@mac.com> On May 27, 2008, at 1:49 PM, Julian Elischer wrote: > Marcel Moolenaar wrote: >> On May 27, 2008, at 10:50 AM, Julian Elischer wrote: >>> Marcel Moolenaar wrote: >>>> On May 27, 2008, at 1:12 AM, Julian Elischer wrote: >>>>> judging by the bug reports when things get broken there are >>>>> still a >>>>> lot of people connected to the internet via dial up lines in >>>>> places >>>>> off the beaten track, and still a lot of people who when >>>>> travelling >>>>> do use dialup still. Some of these also use mpd. I can not say >>>>> how many plan to keep using this in the future but it may be >>>>> that the simplest answer is a completely separate sio driver that >>>>> just has netgraph hooks. I haven't talked with Ed yet but there >>>>> may be may ways to solve this problem. >>>> Take a look at uart(4). It has been designed to allow different >>>> kernel interfaces. It currently supports TTYs and keyboards. It >>>> should not be too hard to have it hook into netgraph. >>>> FYI, >>> >>> >>> While this is a good idea on it's own, the difference between >>> what that achieves and what a line discipline achieves is that >>> a line disciplin is hardware independent and can even be used >>> on a virtual device. >> True, but you said: >> "... the simplest answer is a completely separate sio driver...". >> This, besides not being true, is just as hardware dependent as >> uart(4) is. It seems to me that you've conveniently changed the >> subject to match your point of view :-) > > > yep :-) > > we need to decide if the aim is to support just serial > ports or any 'tty'. Agreed. ucom(4) is in scope... -- Marcel Moolenaar xcllnt@mac.com From peter at wemm.org Tue May 27 22:30:30 2008 From: peter at wemm.org (Peter Wemm) Date: Tue May 27 22:30:41 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <483C2666.7010608@FreeBSD.org> References: <20080527062736.GF64397@hoeg.nl> <45633.1211870269@critter.freebsd.dk> <20080527064253.GG64397@hoeg.nl> <483C2666.7010608@FreeBSD.org> Message-ID: On Tue, May 27, 2008 at 8:19 AM, Bruce M. Simpson wrote: > Ed Schouten wrote: >>>> >>>> With the word `should' I meant that it would still be possible to >>>> implement multiple line disciplines with the mpsafetty code. But I >>>> really think line disciplines should go. >>>> >>> >>> No, don't bother. Remove the entire "abstraction" of linedisciplines. >>> >> >> Your wish is my command. >> > > Like Julian and Robert said, please don't break Netgraph. > > It still needs to hook into tty at a very low level; and the components such > as Bluetooth which can use ttys for low level stream processing, are built > on Netgraph. > > Both SLIP and PPP can be built using Netgraph. > > Other than that, line disciplines can go away. I think line disciplines should go away as such. It would be nice to have a place to hook into (even linux has this), but the line discipline concept is 30 years stale. IMHO, priority #1 is give ttys the first class treatment they need, then priority #2 is to put in some low level hooks for ng_tty or whatever. It would be hard to come up with a more inconvenient interface than we have now. As an example.. look at the CAN_BYPASS_L_RINT stuff. If we had a way to pass a block of characters upstream instead of a single character at a time, then we could build this magic into the input routines instead of the device drivers. The bypass is still useful because it saves considerable cycles for raw tty modes, eg: userland ppp, zmodem upload/downloads etc etc. But the logic for it shouldn't have to be scattered all over the tree due to poor line discipline APIs. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From ed at 80386.nl Wed May 28 06:27:13 2008 From: ed at 80386.nl (Ed Schouten) Date: Wed May 28 06:27:22 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: References: <20080527062736.GF64397@hoeg.nl> <45633.1211870269@critter.freebsd.dk> <20080527064253.GG64397@hoeg.nl> <483C2666.7010608@FreeBSD.org> Message-ID: <20080528062542.GR64397@hoeg.nl> Hello Peter, * Peter Wemm wrote: > As an example.. look at the CAN_BYPASS_L_RINT stuff. If we had a way > to pass a block of characters upstream instead of a single character > at a time, then we could build this magic into the input routines > instead of the device drivers. I still haven't had time to add the CAN_BYPASS_L_RINT functionality back. I was thinking about adding the actual copying to the buffers inside the TTY layer, which means we can finally remove all that redundant code from the drivers. But this is still on my TODO list. ;-) -- 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-arch/attachments/20080528/3d894b47/attachment.pgp From julian at elischer.org Thu May 29 17:28:44 2008 From: julian at elischer.org (Julian Elischer) Date: Thu May 29 17:28:49 2008 Subject: all mutexes -> read-write locks? Message-ID: <483EE7D5.5050408@elischer.org> it has been mentioned several times that through the evolution of the locking primitives it has come to be that mutexes and exclusively acquired reader-writer locks are almost the same in terms of overhead and that it might be a good move to define all mutexes to be actually just that. this would allow people to slowly go through the system, catching low hanging fruit by converting some of the mutex operations to reader acquisitions wherever a writer is not required, thus reducing general system contention. Is there any thought on this? Last I heard jhb had confirmed that it was feasible..