From kris at FreeBSD.org Sun Jun 1 00:36:34 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Sun Jun 1 00:36:38 2008 Subject: CFT: adding configuration file support to pkg_install In-Reply-To: <4841BDA9.5090007@p6m7g8.com> References: <4841BDA9.5090007@p6m7g8.com> Message-ID: <4841EF0D.8050201@FreeBSD.org> Philip M. Gollucci wrote: > Florent Thoumie wrote: >> This adds support for /etc/pkg.conf configuration file. >> Also, this adds support for naive multi-site package fetching. >> >> Any comment welcome (and appreciated). >> >> Patch is here: >> http://people.freebsd.org/~flz/local/ports/pkg-install-config.diff >> Tarball is here: >> http://people.freebsd.org/~flz/local/ports/pkg-install-0a553aac.tar.bz2 > Hi flz, > > I don't quite get what the end goal is. It looks like /etc/pkg.conf is > duplicating a lot of things already in /usr/ports/Mk/bsd.port.mk. > > Would not it be better to just have the pkg_install tools read that file > instead ? packages are usually built from the ports tree, but not always, and users may use packages without a ports tree present on the local system. Kris From pgollucci at p6m7g8.com Sun Jun 1 00:38:31 2008 From: pgollucci at p6m7g8.com (Philip M. Gollucci) Date: Sun Jun 1 00:38:36 2008 Subject: CFT: adding configuration file support to pkg_install In-Reply-To: <4841EF0D.8050201@FreeBSD.org> References: <4841BDA9.5090007@p6m7g8.com> <4841EF0D.8050201@FreeBSD.org> Message-ID: <4841EF83.3000407@p6m7g8.com> Kris Kennaway wrote: > packages are usually built from the ports tree, but not always, and > users may use packages without a ports tree present on the local system. short of doing pkg_delete -af then pkg_add /some/dir are there any ports-mgmt/* tools for upgrades that don't need the ports tree present. I know portupgrade does. Thats not an argument for or against, just commentary. From tzhuan at csie.org Sun Jun 1 08:43:56 2008 From: tzhuan at csie.org (Tz-Huan Huang) Date: Sun Jun 1 08:43:59 2008 Subject: Is there any way to increase the KVM? In-Reply-To: <319cceca0805311303o61729e0dta615c442b6bd03ce@mail.gmail.com> References: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> <319cceca0805311154w5f705b2cp771392cd86ba888@mail.gmail.com> <6a7033710805311201t4085edcpc2f1ac9fa554c000@mail.gmail.com> <319cceca0805311303o61729e0dta615c442b6bd03ce@mail.gmail.com> Message-ID: <6a7033710806010143y204341cepc43f7a14678f7736@mail.gmail.com> On Sun, Jun 1, 2008 at 4:03 AM, Maslan wrote: > Your are right PAE is for i386, i mean try running i386 freebsd with > PAE enabled rather than amd64. PAE will let you access 64GB which is > far than you got. The whole 8G physical memory is available in our system, the point we concerned is that the kernel cannot use more than 2G memory in kernel space. AFAIK there is still only 4G virtual memory available for one process in i386 even if the PAE is enabled, and the upper part of the 4G virtual memory is mapped to the kernel memory. For example, if the KVM size is 2G, then there is only 2G left for one process because the upper 2G is mapped to kernel space. So there is still a limitation of KVM size in i386 with PAE. The limitation should be 2~3G I think. Since the server is on line now, we cannot re-install it to i386 to check this. We'll try it if we have spare machines. Thanks, Tz-Huan From koitsu at FreeBSD.org Sun Jun 1 08:58:36 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Jun 1 08:58:41 2008 Subject: Is there any way to increase the KVM? In-Reply-To: <6a7033710806010143y204341cepc43f7a14678f7736@mail.gmail.com> References: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> <319cceca0805311154w5f705b2cp771392cd86ba888@mail.gmail.com> <6a7033710805311201t4085edcpc2f1ac9fa554c000@mail.gmail.com> <319cceca0805311303o61729e0dta615c442b6bd03ce@mail.gmail.com> <6a7033710806010143y204341cepc43f7a14678f7736@mail.gmail.com> Message-ID: <20080601085835.GA50415@eos.sc1.parodius.com> On Sun, Jun 01, 2008 at 04:43:48PM +0800, Tz-Huan Huang wrote: > On Sun, Jun 1, 2008 at 4:03 AM, Maslan wrote: > > Your are right PAE is for i386, i mean try running i386 freebsd with > > PAE enabled rather than amd64. PAE will let you access 64GB which is > > far than you got. > > The whole 8G physical memory is available in our system, the point we > concerned is that the kernel cannot use more than 2G memory in kernel > space. Your concern is justified; I don't think Maslan understands what it is you're describing. Yes, there is a 2GB limit for kmem_size. Yes, that limit applies to both i386 (with or without PAE) and amd64. Yes, it's a problem. And yes, it's absolutely a problem (especially when it comes to ZFS). > Since the server is on line now, we cannot re-install it to i386 to check this. > We'll try it if we have spare machines. Don't bother -- it won't fix the problem you're reporting. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From ender at enderzone.com Sun Jun 1 13:32:27 2008 From: ender at enderzone.com (Ender) Date: Sun Jun 1 13:32:32 2008 Subject: Is there any way to increase the KVM? In-Reply-To: <20080601085835.GA50415@eos.sc1.parodius.com> References: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> <319cceca0805311154w5f705b2cp771392cd86ba888@mail.gmail.com> <6a7033710805311201t4085edcpc2f1ac9fa554c000@mail.gmail.com> <319cceca0805311303o61729e0dta615c442b6bd03ce@mail.gmail.com> <6a7033710806010143y204341cepc43f7a14678f7736@mail.gmail.com> <20080601085835.GA50415@eos.sc1.parodius.com> Message-ID: <48429E7F.5000205@enderzone.com> Jeremy Chadwick wrote: > On Sun, Jun 01, 2008 at 04:43:48PM +0800, Tz-Huan Huang wrote: > >> On Sun, Jun 1, 2008 at 4:03 AM, Maslan wrote: >> >>> Your are right PAE is for i386, i mean try running i386 freebsd with >>> PAE enabled rather than amd64. PAE will let you access 64GB which is >>> far than you got. >>> >> The whole 8G physical memory is available in our system, the point we >> concerned is that the kernel cannot use more than 2G memory in kernel >> space. >> > > Your concern is justified; I don't think Maslan understands what it is > you're describing. Yes, there is a 2GB limit for kmem_size. Yes, that > limit applies to both i386 (with or without PAE) and amd64. Yes, it's a > problem. And yes, it's absolutely a problem (especially when it comes > to ZFS). > > Exactly. If you have to use ZFS in production I would suggest the new 2008.05 opensolaris.com live cd / installer >> Since the server is on line now, we cannot re-install it to i386 to check this. >> We'll try it if we have spare machines. >> > > Don't bother -- it won't fix the problem you're reporting. > > From jhb at freebsd.org Mon Jun 2 14:58:28 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Jun 2 14:58:43 2008 Subject: CFT: adding configuration file support to pkg_install In-Reply-To: <4841EF83.3000407@p6m7g8.com> References: <4841EF0D.8050201@FreeBSD.org> <4841EF83.3000407@p6m7g8.com> Message-ID: <200806021046.55794.jhb@freebsd.org> On Saturday 31 May 2008 08:38:27 pm Philip M. Gollucci wrote: > Kris Kennaway wrote: > > packages are usually built from the ports tree, but not always, and > > users may use packages without a ports tree present on the local system. > > short of doing pkg_delete -af then pkg_add /some/dir > are there any ports-mgmt/* tools for upgrades that don't need the ports > tree present. I know portupgrade does. > > Thats not an argument for or against, just commentary. There are proprietary tools that manage packages of proprietary software that run on FreeBSD embedded devices. -- John Baldwin From jhb at freebsd.org Mon Jun 2 14:58:28 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Jun 2 14:58:43 2008 Subject: CFT: adding configuration file support to pkg_install In-Reply-To: <4841EF83.3000407@p6m7g8.com> References: <4841EF0D.8050201@FreeBSD.org> <4841EF83.3000407@p6m7g8.com> Message-ID: <200806021046.55794.jhb@freebsd.org> On Saturday 31 May 2008 08:38:27 pm Philip M. Gollucci wrote: > Kris Kennaway wrote: > > packages are usually built from the ports tree, but not always, and > > users may use packages without a ports tree present on the local system. > > short of doing pkg_delete -af then pkg_add /some/dir > are there any ports-mgmt/* tools for upgrades that don't need the ports > tree present. I know portupgrade does. > > Thats not an argument for or against, just commentary. There are proprietary tools that manage packages of proprietary software that run on FreeBSD embedded devices. -- John Baldwin From ivoras at freebsd.org Mon Jun 2 21:37:10 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Jun 2 21:37:15 2008 Subject: Impact of having a large number of open file descriptors In-Reply-To: <64200F15-4444-44FE-B904-673543441F35@FreeBSD.org> References: <200805281446.m4SEkojn099133@lurza.secnetix.de> <64200F15-4444-44FE-B904-673543441F35@FreeBSD.org> Message-ID: Suleiman Souhlal wrote: > I have an old patch that makes kqueue monitor every file write on the > system and return the inode number in the knote's data field: > http://people.freebsd.org/~ssouhlal/testing/kqueue-anyvnode-20050503.diff . > > I'd think it shouldn't be too hard to make it per-mountpoint.. How was this intended to be used? Is there something that makes mapping inode# to filenames easier than I think it is? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080602/71f2fab0/signature.pgp From kris at FreeBSD.org Mon Jun 2 22:33:02 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Mon Jun 2 22:33:05 2008 Subject: Impact of having a large number of open file descriptors In-Reply-To: References: <200805281446.m4SEkojn099133@lurza.secnetix.de> <64200F15-4444-44FE-B904-673543441F35@FreeBSD.org> Message-ID: <4844751C.80704@FreeBSD.org> Ivan Voras wrote: > Suleiman Souhlal wrote: > >> I have an old patch that makes kqueue monitor every file write on the >> system and return the inode number in the knote's data field: >> http://people.freebsd.org/~ssouhlal/testing/kqueue-anyvnode-20050503.diff >> . >> >> I'd think it shouldn't be too hard to make it per-mountpoint.. FWIW, I would love to use this. I have situations where I have huge numbers of files and need to cheaply detect changes so I can resynchronize them to remote machines. Kris From drosih at rpi.edu Tue Jun 3 02:21:28 2008 From: drosih at rpi.edu (Garance A Drosihn) Date: Tue Jun 3 02:21:33 2008 Subject: Impact of having a large number of open file descriptors In-Reply-To: <4844751C.80704@FreeBSD.org> References: <200805281446.m4SEkojn099133@lurza.secnetix.de> <64200F15-4444-44FE-B904-673543441F35@FreeBSD.org> <4844751C.80704@FreeBSD.org> Message-ID: At 12:33 AM +0200 6/3/08, Kris Kennaway wrote: >Ivan Voras wrote: >>Suleiman Souhlal wrote: >> >>>I have an old patch that makes kqueue monitor every file write on >>>the system and return the inode number in the knote's data field: >>>http://people.freebsd.org/~ssouhlal/testing/kqueue-anyvnode-20050503.diff >>>. >>> >>>I'd think it shouldn't be too hard to make it per-mountpoint.. > >FWIW, I would love to use this. I have situations where I have huge >numbers of files and need to cheaply detect changes so I can >resynchronize them to remote machines. I remember a discussion of changes to MacOS10 in Leopard which made it easier to implement features such as Spotlight and TimeMachine. The description starts here, I think: http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/7 the section on file-system events. The idea I thought was interesting was to save the metadata on a directory basis, instead of saving it on the file. So, if file /some/dir/fname was changed, then they'd record that *some* file under /some/dir has changed. So when your userland process comes along later on, it still has to scan all files in that directory to see which file(s) actually changed. But that's a lot less work than scanning all files in the filesystem, and it also means there is much less data that has to be kept track of. I have no idea how easy it would be to implement something similar on FreeBSD, but the strategy seemed like a pretty neat idea. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From dinesh at alphaque.com Tue Jun 3 08:36:58 2008 From: dinesh at alphaque.com (Dinesh Nair) Date: Tue Jun 3 08:37:02 2008 Subject: Maximum memory allocation per process In-Reply-To: <200805301437.m4UEb0J8010462@lurza.secnetix.de> References: <20080530135814.390321ee@prophet.alphaque.com> <200805301437.m4UEb0J8010462@lurza.secnetix.de> Message-ID: <20080603163534.4b648fc2@prophet.alphaque.com> On Fri, 30 May 2008 16:37:00 +0200 (CEST), Oliver Fromme wrote: > Dinesh Nair wrote: > > for those of us who're booting off a stripped down freebsd and are not > > using the 4th routines, are the above to be set before 'load /kernel' > > or after 'load /kernel' ? > > It doesn't matter. The tunables are passed to the kernel > when it is booted. In fact, the standard beastie.4th > stuff loads the kernel before displaying the menu, so > the settings happen after the kernel is loaded. thanx for the tip. -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.openmalaysiablog.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From rwatson at FreeBSD.org Tue Jun 3 10:38:12 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Jun 3 10:38:17 2008 Subject: Impact of having a large number of open file descriptors In-Reply-To: References: <200805281446.m4SEkojn099133@lurza.secnetix.de> <64200F15-4444-44FE-B904-673543441F35@FreeBSD.org> <4844751C.80704@FreeBSD.org> Message-ID: <20080603111935.K426@fledge.watson.org> On Mon, 2 Jun 2008, Garance A Drosihn wrote: > I remember a discussion of changes to MacOS10 in Leopard which made it > easier to implement features such as Spotlight and TimeMachine. The > description starts here, I think: > > http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/7 > > the section on file-system events. > > The idea I thought was interesting was to save the metadata on a directory > basis, instead of saving it on the file. So, if file /some/dir/fname was > changed, then they'd record that *some* file under /some/dir has changed. > > So when your userland process comes along later on, it still has to scan all > files in that directory to see which file(s) actually changed. But that's a > lot less work than scanning all files in the filesystem, and it also means > there is much less data that has to be kept track of. > > I have no idea how easy it would be to implement something similar on > FreeBSD, but the strategy seemed like a pretty neat idea. fsevents allows user processes to subscribe, effectively on a per-filesystem basis, to namespace and file close operations. The implementation is split into two parts: a kernel component, which captures events with possible coalescing, and a user daemon, fseventsd, which listens on a special device and then provides scope narrowing and persistence for subscriptions. Applications talk to fseventsd, using Mach ports, I believe, and fseventsd is responsible for tracking subscriptions, filtering events, and so on. I'm aware of several limitations that should be considered very carefully before adopting this code: (1) The user<->kernel interface is essentially a firehose, and available only to privileged processes. fseventsd performs checks in user space to see whether each consumer is allowed access to each event, which can lead to confusing and potentially quite incorrect results. (2) The kernel code requires a reliable conversion from vnode to path, which we don't have, as events are with respect to paths, and especially coalescing. (3) The user daemon requires synchronous hooks into the file system umount event because fseventsd stores its events journal in the file system root, so must first close it before the file system can be unmounted. In Mac OS X, this is satisfied by having the disk arbitration daemon, which performs unmounts, first send a message to fseventsd and wait for it to finish up. I've seen a number of occasions where the disk unmount process has become non-trivially stalled due to fseventsd, so there's a potential robustness question. (4) As I understand it, events frequently come down to "file system X changed" in practice, which could be captured by a far simpler mechanism. I've not done any measurements to confirm whether this is the case, but it's not impossible to imagine on a busy system. I think there's also considerable overlap with other kernel event systems, such as audit, and we might benefit from thinking seriously about enhancing those event systems rather than introducing a new one. The design of fsevents is pretty much entirely dictated by the needs of Spotlight and later Time Machine. In particular, it's not clear to me that the persistency requirements, which are a large part of the fsevents design, are important to us... or are they? Robert N M Watson Computer Laboratory University of Cambridge From kris at FreeBSD.org Tue Jun 3 11:02:40 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Jun 3 11:02:49 2008 Subject: Impact of having a large number of open file descriptors In-Reply-To: <20080603111935.K426@fledge.watson.org> References: <200805281446.m4SEkojn099133@lurza.secnetix.de> <64200F15-4444-44FE-B904-673543441F35@FreeBSD.org> <4844751C.80704@FreeBSD.org> <20080603111935.K426@fledge.watson.org> Message-ID: <484524CF.2090709@FreeBSD.org> Robert Watson wrote: > fsevents allows user processes to subscribe, effectively on a > per-filesystem basis, to namespace and file close operations. ... > I think there's also considerable overlap with other kernel event > systems, such as audit, and we might benefit from thinking seriously > about enhancing those event systems rather than introducing a new one. > The design of fsevents is pretty much entirely dictated by the needs of > Spotlight and later Time Machine. In particular, it's not clear to me > that the persistency requirements, which are a large part of the > fsevents design, are important to us... or are they? Yes, I keep forgetting about audit for some reason :) It might be that this is already good enough for my use case, although having to maintain a path -> inode mapping for millions of files will be potentially onerous (same for kevent anyway though). Persistency across reboots for unread events would be nice but probably not essential (or worth the trouble). Kris From rwatson at FreeBSD.org Tue Jun 3 11:11:11 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Jun 3 11:11:15 2008 Subject: Impact of having a large number of open file descriptors In-Reply-To: <484524CF.2090709@FreeBSD.org> References: <200805281446.m4SEkojn099133@lurza.secnetix.de> <64200F15-4444-44FE-B904-673543441F35@FreeBSD.org> <4844751C.80704@FreeBSD.org> <20080603111935.K426@fledge.watson.org> <484524CF.2090709@FreeBSD.org> Message-ID: <20080603120818.K426@fledge.watson.org> On Tue, 3 Jun 2008, Kris Kennaway wrote: >> I think there's also considerable overlap with other kernel event systems, >> such as audit, and we might benefit from thinking seriously about enhancing >> those event systems rather than introducing a new one. The design of >> fsevents is pretty much entirely dictated by the needs of Spotlight and >> later Time Machine. In particular, it's not clear to me that the >> persistency requirements, which are a large part of the fsevents design, >> are important to us... or are they? > > Yes, I keep forgetting about audit for some reason :) It might be that this > is already good enough for my use case, although having to maintain a path > -> inode mapping for millions of files will be potentially onerous (same for > kevent anyway though). Persistency across reboots for unread events would > be nice but probably not essential (or worth the trouble). One interesting design choice in fsevents is that the event record is submitted on file close, rather than on file open. This doesn't properly handle writes due to memory mappings of the file, but does mean that you don't get the "Odd KDE PDF effect", in which KDE PDF viewer detects the open/write but not the close, so opens and refreshes the PDF before the file is completely rewritten, leading to a partial rendering. Audit captures open(2) and close(2), but only open(2) has a path on FreeBSD. This could be changed, however, to use a generated path on close(2), if available. Right now, there are quite a few file systems, especially synthetic ones such as procfs and devfs, which don't use the name cache, meaning that the path lookup doesn't work for them. Also, our name cache invalidation is pretty strict (to the point of being a performance problem in the NFS client), so path generation can be quite unreliable if it involves active directories. A mini-project in which someone improves the reliability of path generation is probably a prerequisite for any real work in this area. Robert N M Watson Computer Laboratory University of Cambridge From keramida at ceid.upatras.gr Tue Jun 3 11:55:25 2008 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Tue Jun 3 11:55:30 2008 Subject: Impact of having a large number of open file descriptors In-Reply-To: (Garance A. Drosihn's message of "Mon\, 2 Jun 2008 21\:07\:15 -0400") References: <200805281446.m4SEkojn099133@lurza.secnetix.de> <64200F15-4444-44FE-B904-673543441F35@FreeBSD.org> <4844751C.80704@FreeBSD.org> Message-ID: <87prqykfzw.fsf@kobe.laptop> On Mon, 2 Jun 2008 21:07:15 -0400, Garance A Drosihn wrote: > At 12:33 AM +0200 6/3/08, Kris Kennaway wrote: >>Ivan Voras wrote: >>>Suleiman Souhlal wrote: >>> >>>> I have an old patch that makes kqueue monitor every file write on >>>> the system and return the inode number in the knote's data field: >>>> http://people.freebsd.org/~ssouhlal/testing/kqueue-anyvnode-20050503.diff >>>> . >>>> >>>>I'd think it shouldn't be too hard to make it per-mountpoint.. >> >> FWIW, I would love to use this. I have situations where I have huge >> numbers of files and need to cheaply detect changes so I can >> resynchronize them to remote machines. > > I remember a discussion of changes to MacOS10 in Leopard which made it > easier to implement features such as Spotlight and TimeMachine. The > description starts here, I think: > > http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/7 > > the section on file-system events. > > The idea I thought was interesting was to save the metadata on a > directory basis, instead of saving it on the file. So, if file > /some/dir/fname was changed, then they'd record that *some* file under > /some/dir has changed. > > So when your userland process comes along later on, it still has to > scan all files in that directory to see which file(s) actually > changed. But that's a lot less work than scanning all files in the > filesystem, and it also means there is much less data that has to be > kept track of. > > I have no idea how easy it would be to implement something similar on > FreeBSD, but the strategy seemed like a pretty neat idea. It sounds like a useful compromise between the number of tracked entries and scanning the entire fs :) From det135 at psu.edu Tue Jun 3 13:43:25 2008 From: det135 at psu.edu (Derek Taylor) Date: Tue Jun 3 13:43:29 2008 Subject: Kerberized CIFS client? In-Reply-To: <483554FC.9040908@dlr.de> References: <20080521182722.GC40818@psu.edu> <483554FC.9040908@dlr.de> Message-ID: <20080603134307.GK76952@psu.edu> On Thu, 22 May 2008, Hartmut Brandt wrote: >Derek Taylor wrote: >> This question was previously posed of the freebsd-questions list, but >> with no response for a week, I'd like to try my luck here. If there's >> any more information I should include, please speak up: I would be glad >> to oblige. >> >> I would like to use smb/cifs with kerberos auth, but mount_smbfs doesn't >> seem to support this. >> >> Is anyone aware of an alternate means of performing a mount via smb/cifs >> or any patches to provide such functionality? >> >> I already have smbclient working with -k, but I am also interested in a >> mount. > >Try smbnetfs from ports. It's fuse based and seems to work very nice. If >you have a large amount of shares floating in your network you want to >restrict it to mount only the needed shares via the config file. >Otherwise it will mount what it can find... > >It plays nicely with kerberors. When your ticket expires you immediately >loose access; when you renew it you gain access again. All without the >need to unmount/mount. Just call smbnetfs once you have your ticket. You >may even do this from your .profile. > >harti Sorry for not replying sooner. Initial tests here are promising (I can see some mount paths being exported from the server), but it's not fully working (I don't see all of the mount paths that *should* be exported and I get permission denied errors). My thoughts are leaning towards an issue in negotiating auth with the server -- perhaps my krb creds aren't being used? Before trying to work out any issues over the list, there's a lot of things we need to check internally. The thing is that we're so crunched for time, I'm not sure when we'll have the chance to do this. Thanks for the heads up -- this is certainly closer than I was before. If we have the chance to work more on this, I'll follow up on this thread. Until then ... -Derek. From pjd at FreeBSD.org Tue Jun 3 14:19:59 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Jun 3 14:20:05 2008 Subject: Is there any way to increase the KVM? In-Reply-To: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> References: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> Message-ID: <20080603135308.GC3434@garage.freebsd.pl> On Sat, May 31, 2008 at 01:52:56PM +0800, Tz-Huan Huang wrote: > Hi, > > Our nfs server is running 7-stable/amd64 with 8G ram, the size of zfs > pool is 12T. We have set vm.kmem_size and vm.kmem_size_max to > 1.5G, but the kernel still panics by "kmem_map too small" often. Could you also try to decrease vfs.zfs.arc_max? -- 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-hackers/attachments/20080603/9abaa833/attachment.pgp From hartmut.brandt at dlr.de Tue Jun 3 15:37:36 2008 From: hartmut.brandt at dlr.de (Harti Brandt) Date: Tue Jun 3 15:37:40 2008 Subject: Kerberized CIFS client? In-Reply-To: <20080603134307.GK76952@psu.edu> References: <20080521182722.GC40818@psu.edu> <483554FC.9040908@dlr.de> <20080603134307.GK76952@psu.edu> Message-ID: <20080603173601.W41705@beagle.kn.op.dlr.de> On Tue, 3 Jun 2008, Derek Taylor wrote: DT>On Thu, 22 May 2008, Hartmut Brandt wrote: DT>>Derek Taylor wrote: DT>>> This question was previously posed of the freebsd-questions list, but DT>>> with no response for a week, I'd like to try my luck here. If there's DT>>> any more information I should include, please speak up: I would be glad DT>>> to oblige. DT>>> DT>>> I would like to use smb/cifs with kerberos auth, but mount_smbfs doesn't DT>>> seem to support this. DT>>> DT>>> Is anyone aware of an alternate means of performing a mount via smb/cifs DT>>> or any patches to provide such functionality? DT>>> DT>>> I already have smbclient working with -k, but I am also interested in a DT>>> mount. DT>> DT>>Try smbnetfs from ports. It's fuse based and seems to work very nice. If DT>>you have a large amount of shares floating in your network you want to DT>>restrict it to mount only the needed shares via the config file. DT>>Otherwise it will mount what it can find... DT>> DT>>It plays nicely with kerberors. When your ticket expires you immediately DT>>loose access; when you renew it you gain access again. All without the DT>>need to unmount/mount. Just call smbnetfs once you have your ticket. You DT>>may even do this from your .profile. DT>> DT>>harti DT> DT>Sorry for not replying sooner. DT> DT>Initial tests here are promising (I can see some mount paths being DT>exported from the server), but it's not fully working (I don't see all DT>of the mount paths that *should* be exported and I get permission denied DT>errors). My thoughts are leaning towards an issue in negotiating auth DT>with the server -- perhaps my krb creds aren't being used? You can test this easily: if your ticket expires you get permission denied errors when you try to look into the mounted directories. As soon as you renew the ticket you get access again. All without restarting smbnetfs. harti From pfgshield-freebsd at yahoo.com Tue Jun 3 15:17:09 2008 From: pfgshield-freebsd at yahoo.com (pfgshield-freebsd@yahoo.com) Date: Tue Jun 3 16:02:02 2008 Subject: Anyone interested in HDLC support for pppd ? Message-ID: <853261.35086.qm@web32707.mail.mud.yahoo.com> Hello; I started playing a bit with net/pppd23 and I noticed there are some patches for FreeBSD-3.0 that were never committed (NetBSD certainly has them). Our pppd(8) is derived from the "samba" pppd port and should have them if we want to continue updating it. I started adapting them but I am actually in a dead point due to my profound ignorance on FreeBSD and it's latest changes. I am stuck here: _____ ... ../../../net/ppp_tty.c: In function `pppsyncstart': ../../../net/ppp_tty.c:653: error: `cdevsw' undeclared (first use in this function) ../../../net/ppp_tty.c:653: error: (Each undeclared identifier is reported only once ../../../net/ppp_tty.c:653: error: for each function it appears in.) ../../../net/ppp_tty.c:653: warning: implicit declaration of function `major' ../../../net/ppp_tty.c:653: warning: nested extern declaration of `major' *** Error code 1 ______ the offending code is this: ______ /* call device driver IOCTL to transmit a frame */ if ((*cdevsw[major(tp->t_dev)]->d_ioctl) (tp->t_dev,TIOCXMTFRAME,(caddr_t)&m,0,0)) { /* busy or error, set as current packet */ sc->sc_outm = m; _____ If someone can give me (easy to follow) suggestions on how to fix it I'll be grateful. The changes I already did to the original patches are not huge but if someone wants to review them all just send me a private mail and I'll send them. cheers, Pedro. ___________________________________ Scopri il Blog di Yahoo! Mail: trucchi, novit?, consigli... e la tua opinione! http://www.ymailblogit.com/blog/ From det135 at psu.edu Tue Jun 3 16:06:26 2008 From: det135 at psu.edu (Derek Taylor) Date: Tue Jun 3 16:06:31 2008 Subject: Kerberized CIFS client? In-Reply-To: <20080603173601.W41705@beagle.kn.op.dlr.de> References: <20080521182722.GC40818@psu.edu> <483554FC.9040908@dlr.de> <20080603134307.GK76952@psu.edu> <20080603173601.W41705@beagle.kn.op.dlr.de> Message-ID: <20080603160608.GA56965@psu.edu> On Tue, 03 Jun 2008, Harti Brandt wrote: >On Tue, 3 Jun 2008, Derek Taylor wrote: > >DT>On Thu, 22 May 2008, Hartmut Brandt wrote: >DT>>Derek Taylor wrote: >DT>>> This question was previously posed of the freebsd-questions list, but >DT>>> with no response for a week, I'd like to try my luck here. If there's >DT>>> any more information I should include, please speak up: I would be glad >DT>>> to oblige. >DT>>> >DT>>> I would like to use smb/cifs with kerberos auth, but mount_smbfs doesn't >DT>>> seem to support this. >DT>>> >DT>>> Is anyone aware of an alternate means of performing a mount via smb/cifs >DT>>> or any patches to provide such functionality? >DT>>> >DT>>> I already have smbclient working with -k, but I am also interested in a >DT>>> mount. >DT>> >DT>>Try smbnetfs from ports. It's fuse based and seems to work very nice. If >DT>>you have a large amount of shares floating in your network you want to >DT>>restrict it to mount only the needed shares via the config file. >DT>>Otherwise it will mount what it can find... >DT>> >DT>>It plays nicely with kerberors. When your ticket expires you immediately >DT>>loose access; when you renew it you gain access again. All without the >DT>>need to unmount/mount. Just call smbnetfs once you have your ticket. You >DT>>may even do this from your .profile. >DT>> >DT>>harti >DT> >DT>Sorry for not replying sooner. >DT> >DT>Initial tests here are promising (I can see some mount paths being >DT>exported from the server), but it's not fully working (I don't see all >DT>of the mount paths that *should* be exported and I get permission denied >DT>errors). My thoughts are leaning towards an issue in negotiating auth >DT>with the server -- perhaps my krb creds aren't being used? > >You can test this easily: if your ticket expires you get permission denied >errors when you try to look into the mounted directories. As soon as you >renew the ticket you get access again. All without restarting smbnetfs. > >harti I replaced all server names below with "example.com" (and derivatives) where appropriate: From my FreeBSD machine, using smbnetfs: $ klist klist: No ticket file: /tmp/krb5cc_1001 $ kinit det135 det135@realm.example.com's Password: kinit: NOTICE: ticket renewable lifetime is 1 week $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: det135@realm.example.com Issued Expires Principal Jun 3 11:51:20 Jun 3 21:51:04 krbtgt/realm.example.com@realm.example.com $ cd ~/mount/cifs.example.com/dir1 $ ls ls: .: Permission denied $ cd .. $ ls dir1 dir2 $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: det135@realm.example.com Issued Expires Principal Jun 3 11:51:20 Jun 3 21:51:04 krbtgt/realm.example.com@realm.example.com From my Mac, using (from Finder) Go -> Connect to Server -> cifs://cifs.example.com/dir1 $ klist klist: No Kerberos 5 tickets in credentials cache $ kinit det135 Please enter the password for det135@realm.example.com: $ klist Kerberos 5 ticket cache: 'API:Initial default ccache' Default principal: det135@realm.example.com Valid Starting Expires Service Principal 06/03/08 11:59:41 06/03/08 21:59:41 krbtgt/realm.example.com@realm.example.com renew until 06/10/08 11:59:41 #### Here I mount via Finder before continuing with the commands below $ cd /Volumes/dir1/ $ ls subdir1 subdir2 file1 file2 $ klist Kerberos 5 ticket cache: 'API:Initial default ccache' Default principal: det135@realm.example.com Valid Starting Expires Service Principal 06/03/08 11:59:41 06/03/08 21:59:41 krbtgt/realm.example.com@realm.example.com renew until 06/10/08 11:59:41 06/03/08 12:00:31 06/03/08 21:59:41 cifs/cifs.example.com@realm.example.com renew until 06/10/08 11:59:41 It looks like my creds aren't being used on the FreeBSD machine. -Derek. From bms at FreeBSD.org Tue Jun 3 16:40:56 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Tue Jun 3 16:41:00 2008 Subject: Anyone interested in HDLC support for pppd ? In-Reply-To: <853261.35086.qm@web32707.mail.mud.yahoo.com> References: <853261.35086.qm@web32707.mail.mud.yahoo.com> Message-ID: <484571B7.1050004@FreeBSD.org> pfgshield-freebsd@yahoo.com wrote: > Hello; > > I started playing a bit with net/pppd23 and I noticed there are some patches for FreeBSD-3.0 that were never committed (NetBSD certainly has them). Our pppd(8) is derived from the "samba" pppd port and should have them if we want to continue updating it. > Ed Schouten is currently rewriting the tty code. It sounds like line disciplines are about to go away, so pppd23 will most likely stop working at that point. There's a Netgraph node ng_cisco which claims to support HDLC. Perhaps tweaking MPD to work with it is a better use of effort. From flz at xbsd.org Tue Jun 3 15:26:21 2008 From: flz at xbsd.org (Florent Thoumie) Date: Tue Jun 3 16:57:23 2008 Subject: CFT: adding configuration file support to pkg_install In-Reply-To: <4841BDA9.5090007@p6m7g8.com> References: <4841BDA9.5090007@p6m7g8.com> Message-ID: On Sat, May 31, 2008 at 10:05 PM, Philip M. Gollucci wrote: > Florent Thoumie wrote: >> >> This adds support for /etc/pkg.conf configuration file. >> Also, this adds support for naive multi-site package fetching. >> >> Any comment welcome (and appreciated). >> >> Patch is here: >> http://people.freebsd.org/~flz/local/ports/pkg-install-config.diff >> Tarball is here: >> http://people.freebsd.org/~flz/local/ports/pkg-install-0a553aac.tar.bz2 > > Hi flz, > > I don't quite get what the end goal is. It looks like /etc/pkg.conf is > duplicating a lot of things already in /usr/ports/Mk/bsd.port.mk. > > Would not it be better to just have the pkg_install tools read that file > instead ? > > I probably missed all the back story here, so feel free to put me in my > place. Packages can be used without a full tree (as Kris mentioned). It can be argued that using only pkg_install to maintain packages is a PITA, but it's still possible. The fact that there's no proper tool part of or on top of pkg_install to do it is irrelevant. > The multi-site package fetching is definitely something I'm interested it, > but I also figured it would just iterate over the values in PACKAGESITE > > PACKAGESITE=ftp://foo/stdpath/base/Latest/ ftp://foo/stdpath/www/Latest > > where base would have things like sudo, bash, vim, etc... and could be used > on multiple computers. > > www would have things like apache22 mod_X and would be used on 'www' class > machines. I'm not sure what behaviour you're describing there. -- Florent Thoumie flz@FreeBSD.org FreeBSD Committer From chuckr at telenix.org Tue Jun 3 21:17:58 2008 From: chuckr at telenix.org (Chuck Robey) Date: Tue Jun 3 21:18:03 2008 Subject: git problems Message-ID: <4845AC84.6040407@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am having problems with the git out of ports .... git-fetch keeps on dumping core when I try update of xorg (the initial checkout works ok). I'm running FreeBSD-current ... does anyone have any idea why this might be? When I try to do a gdb -c corefile on the resulting core image, all i get is a couple of thousand empty stack frames. Any idea why that might be, also? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRayEz62J6PPcoOkRAnjLAKCIhWPRyB/Ng17/RiUgkej+9qmp6gCcC2uM 2zxaevhQyF4C3vbsJtURSPQ= =4hoW -----END PGP SIGNATURE----- From ed at 80386.nl Tue Jun 3 21:23:56 2008 From: ed at 80386.nl (Ed Schouten) Date: Tue Jun 3 21:23:58 2008 Subject: git problems In-Reply-To: <4845AC84.6040407@telenix.org> References: <4845AC84.6040407@telenix.org> Message-ID: <20080603212355.GB64397@hoeg.nl> * Chuck Robey wrote: > I am having problems with the git out of ports .... git-fetch keeps on dumping > core when I try update of xorg (the initial checkout works ok). I'm running > FreeBSD-current ... does anyone have any idea why this might be? > > When I try to do a gdb -c corefile on the resulting core image, all i get is a > couple of thousand empty stack frames. Any idea why that might be, also? I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace nearby, but it seems to be crash inside free(). -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080603/aee7625b/attachment.pgp From chuckr at telenix.org Tue Jun 3 21:39:08 2008 From: chuckr at telenix.org (Chuck Robey) Date: Tue Jun 3 21:39:12 2008 Subject: git problems In-Reply-To: <20080603212355.GB64397@hoeg.nl> References: <4845AC84.6040407@telenix.org> <20080603212355.GB64397@hoeg.nl> Message-ID: <4845B7C0.7070805@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ed Schouten wrote: > * Chuck Robey wrote: >> I am having problems with the git out of ports .... git-fetch keeps on dumping >> core when I try update of xorg (the initial checkout works ok). I'm running >> FreeBSD-current ... does anyone have any idea why this might be? >> >> When I try to do a gdb -c corefile on the resulting core image, all i get is a >> couple of thousand empty stack frames. Any idea why that might be, also? > > I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace nearby, > but it seems to be crash inside free(). > My problem is, I can't even get a backtrace on core files, I get thousands of empty stack frames only. The only way I can debug is to do static images and debug the image, not a core file. I don't run anything but current so I can't do any other testing. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRbfAz62J6PPcoOkRAuPAAJ4k6en0g/YlAAUM22Qqj/Kwjx81TwCfR1bx cgq0ip67DuwPJWbfhM61kkA= =H1pB -----END PGP SIGNATURE----- From tzhuan at csie.org Wed Jun 4 06:17:54 2008 From: tzhuan at csie.org (Tz-Huan Huang) Date: Wed Jun 4 06:17:58 2008 Subject: Is there any way to increase the KVM? In-Reply-To: <20080603135308.GC3434@garage.freebsd.pl> References: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> <20080603135308.GC3434@garage.freebsd.pl> Message-ID: <6a7033710806032317g4dbe8845h26a1196016b9c440@mail.gmail.com> On Tue, Jun 3, 2008 at 9:53 PM, Pawel Jakub Dawidek wrote: > On Sat, May 31, 2008 at 01:52:56PM +0800, Tz-Huan Huang wrote: >> Hi, >> >> Our nfs server is running 7-stable/amd64 with 8G ram, the size of zfs >> pool is 12T. We have set vm.kmem_size and vm.kmem_size_max to >> 1.5G, but the kernel still panics by "kmem_map too small" often. > > Could you also try to decrease vfs.zfs.arc_max? The vfs.zfs.arc_max was set to 512M originally, the machine survived for 4 days and panicked this morning. Now the vfs.zfs.arc_max is set to 64M by Oliver's suggestion, let's see how long it will survive. :-) Thanks, Tz-Huan From rea-fbsd at codelabs.ru Wed Jun 4 09:06:19 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed Jun 4 09:13:55 2008 Subject: git problems In-Reply-To: <4845AC84.6040407@telenix.org> References: <4845AC84.6040407@telenix.org> Message-ID: Chuck, good day. Tue, Jun 03, 2008 at 04:41:40PM -0400, Chuck Robey wrote: > I am having problems with the git out of ports .... git-fetch keeps on dumping > core when I try update of xorg (the initial checkout works ok). I'm running > FreeBSD-current ... does anyone have any idea why this might be? What version of Git you're using and what protocol is used for updating, native git or http? Any possibility of using ElectricFence (devel/ElectricFence) for chasing memory-related troubles? -- Eygene From rwatson at FreeBSD.org Wed Jun 4 12:49:45 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Jun 4 12:49:48 2008 Subject: git problems In-Reply-To: <20080603212355.GB64397@hoeg.nl> References: <4845AC84.6040407@telenix.org> <20080603212355.GB64397@hoeg.nl> Message-ID: <20080604134830.D49920@fledge.watson.org> On Tue, 3 Jun 2008, Ed Schouten wrote: > * Chuck Robey wrote: >> I am having problems with the git out of ports .... git-fetch keeps on >> dumping core when I try update of xorg (the initial checkout works ok). >> I'm running FreeBSD-current ... does anyone have any idea why this might >> be? >> >> When I try to do a gdb -c corefile on the resulting core image, all i get >> is a couple of thousand empty stack frames. Any idea why that might be, >> also? > > I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace nearby, but > it seems to be crash inside free(). Application memory errors in HEAD but not in a RELENG_ branch are frequently a symptom of an application bug unmasked by malloc(3) debugging enabled in the development branch but not production branches. It might not hurt to ramp up debugging on your 6.x install to see if it starts crashing there was well -- see malloc(3) for details, you'll want to create an appropriate malloc.conf. Robert N M Watson Computer Laboratory University of Cambridge From chuckr at telenix.org Wed Jun 4 14:22:24 2008 From: chuckr at telenix.org (Chuck Robey) Date: Wed Jun 4 14:22:29 2008 Subject: git problems In-Reply-To: <20080604134830.D49920@fledge.watson.org> References: <4845AC84.6040407@telenix.org> <20080603212355.GB64397@hoeg.nl> <20080604134830.D49920@fledge.watson.org> Message-ID: <4846A2E7.2060003@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Watson wrote: > On Tue, 3 Jun 2008, Ed Schouten wrote: > >> * Chuck Robey wrote: >>> I am having problems with the git out of ports .... git-fetch keeps >>> on dumping core when I try update of xorg (the initial checkout works >>> ok). I'm running FreeBSD-current ... does anyone have any idea why >>> this might be? >>> >>> When I try to do a gdb -c corefile on the resulting core image, all i >>> get is a couple of thousand empty stack frames. Any idea why that >>> might be, also? >> >> I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace >> nearby, but it seems to be crash inside free(). > > Application memory errors in HEAD but not in a RELENG_ branch are > frequently a symptom of an application bug unmasked by malloc(3) > debugging enabled in the development branch but not production > branches. It might not hurt to ramp up debugging on your 6.x install to > see if it starts crashing there was well -- see malloc(3) for details, > you'll want to create an appropriate malloc.conf. I didn't see the email where Ed Schouten commented about seeing my problems of seeing no good stack frames, but Robert, I run only -current here, not RELENG_6, so I can't do the testing you speak of. I would want to see if maybe our gcc on - -current might have been made with a default of emitting no stack frames, which I would guess might have this effect. I guess I could test this, and if it's so, recompile all my libraries to undo that, because I abhor doing things that utterly block any troubleshooting at a minimal savings elsewhere. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRqLnz62J6PPcoOkRAlhFAJsHrHTMVaFCdPcUha+1yaFOYyMxuACfY+ms jZRd8WCy9PFcwYICmg636y4= =4PYv -----END PGP SIGNATURE----- From rea-fbsd at codelabs.ru Wed Jun 4 14:36:28 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed Jun 4 14:36:33 2008 Subject: git problems In-Reply-To: <4846A2E7.2060003@telenix.org> References: <4845AC84.6040407@telenix.org> <20080603212355.GB64397@hoeg.nl> <20080604134830.D49920@fledge.watson.org> <4846A2E7.2060003@telenix.org> Message-ID: <7tA3MvVpZ14HTFbKQUoucxMjR6I@XW7GVEPlMa2oCuO15y8lYU4QCgM> Chuck, Wed, Jun 04, 2008 at 10:12:55AM -0400, Chuck Robey wrote: > >> I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace > >> nearby, but it seems to be crash inside free(). > > > > Application memory errors in HEAD but not in a RELENG_ branch are > > frequently a symptom of an application bug unmasked by malloc(3) > > debugging enabled in the development branch but not production > > branches. It might not hurt to ramp up debugging on your 6.x install to > > see if it starts crashing there was well -- see malloc(3) for details, > > you'll want to create an appropriate malloc.conf. > > I didn't see the email where Ed Schouten commented about seeing my problems of > seeing no good stack frames, but Robert, I run only -current here, not RELENG_6, > so I can't do the testing you speak of. There is no need: I had tried this on -STABLE with environment variable MALLOC_OPTIONS set to 'J' -- it dumps core. The problem seems to be in the git-fetch: ----- $ MALLOC_OPTIONS=JA git-fetch --update-head-ok Segmentation fault: 11 (core dumped) ----- This happens inside git repository of xserver and 100% reproducible for my both -CURRENT and -STABLE. > I would want to see if maybe our gcc on > - -current might have been made with a default of emitting no stack frames, which > I would guess might have this effect. The stack seems to be smashed at the second call to 'transport_unlock_pack': the argument called 'transport' seems to carry the pointer to the area, filled by malloc() with byte 0x5a: ----- $ MALLOC_OPTIONS=JA gdb git-fetch GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) run --update-head-ok Starting program: /usr/local/bin/git-fetch --update-head-ok Program received signal SIGSEGV, Segmentation fault. 0x4841de8b in free () from /lib/libc.so.7 (gdb) bt #0 0x4841de8b in free () from /lib/libc.so.7 #1 0x080d8d04 in transport_unlock_pack (transport=0x820a0a0) at transport.c:811 #2 0x08066927 in unlock_pack () at builtin-fetch.c:56 #3 0x48468fe3 in __cxa_finalize () from /lib/libc.so.7 #4 0x4842199a in exit () from /lib/libc.so.7 #5 0x0804b15b in handle_internal_command (argc=2, argv=0xffffffff) at git.c:379 #6 0x0804b8be in main (argc=2, argv=Error accessing memory address 0x10: Bad address. ) at git.c:414 (gdb) fr 1 #1 0x080d8d04 in transport_unlock_pack (transport=0x820a0a0) at transport.c:811 811 free(transport->pack_lockfile); (gdb) print *transport $1 = {remote = 0x5a5a5a5a, url = 0x5a5a5a5a , data = 0x5a5a5a5a, remote_refs = 0x5a5a5a5a, set_option = 0x5a5a5a5a, get_refs_list = 0x5a5a5a5a, fetch = 0x5a5a5a5a, push = 0x5a5a5a5a, disconnect = 0x5a5a5a5a, pack_lockfile = 0x5a5a5a5a , verbose = -2} (gdb) ----- I don't believe that __cxa_finalize should call unlock_pack, so stack seems to be smashed somewhere before. > I guess I could test this, and if it's so, recompile all my libraries to undo > that, because I abhor doing things that utterly block any troubleshooting at a > minimal savings elsewhere. You don't need to recompile anything to enable malloc debugging. The easiest way is to set MALLOC_OPTIONS to the needed malloc flags. -- Eygene From chuckr at telenix.org Wed Jun 4 14:38:13 2008 From: chuckr at telenix.org (Chuck Robey) Date: Wed Jun 4 14:38:19 2008 Subject: git problems In-Reply-To: <20080604134830.D49920@fledge.watson.org> References: <4845AC84.6040407@telenix.org> <20080603212355.GB64397@hoeg.nl> <20080604134830.D49920@fledge.watson.org> Message-ID: <4846A69D.4000105@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Watson wrote: > On Tue, 3 Jun 2008, Ed Schouten wrote: > >> * Chuck Robey wrote: >>> I am having problems with the git out of ports .... git-fetch keeps >>> on dumping core when I try update of xorg (the initial checkout works >>> ok). I'm running FreeBSD-current ... does anyone have any idea why >>> this might be? >>> >>> When I try to do a gdb -c corefile on the resulting core image, all i >>> get is a couple of thousand empty stack frames. Any idea why that >>> might be, also? >> >> I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace >> nearby, but it seems to be crash inside free(). > > Application memory errors in HEAD but not in a RELENG_ branch are > frequently a symptom of an application bug unmasked by malloc(3) > debugging enabled in the development branch but not production > branches. It might not hurt to ramp up debugging on your 6.x install to > see if it starts crashing there was well -- see malloc(3) for details, > you'll want to create an appropriate malloc.conf. This is really replying to my own question, because I found what I was missing. I have'nt done any troubleshooting for a long while now (health, down for some years) and the last time I did it, if you had a core file in the same directory as the binary and the sources, gdb would know where to find the symbols on it's own, but it looks like that's changed. Once I explicitly gave the symbols, th8ings began to work ok, so you can stop worrying about my missing stack frames. Now that I have that, I have also the ability to find out where git-fetch died, and I will pretty quickly, that ought to help some. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRqVvz62J6PPcoOkRAoKcAJ9c5WFhKf0NkOCgfNFO53jEWpsPUwCdErw4 RY8Ry6WQpgwOKVAPoe+mOUs= =M+hX -----END PGP SIGNATURE----- From chuckr at telenix.org Wed Jun 4 14:41:56 2008 From: chuckr at telenix.org (Chuck Robey) Date: Wed Jun 4 14:42:00 2008 Subject: git problems In-Reply-To: References: <4845AC84.6040407@telenix.org> Message-ID: <4846A77B.9060603@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eygene Ryabinkin wrote: > Chuck, good day. > > Tue, Jun 03, 2008 at 04:41:40PM -0400, Chuck Robey wrote: >> I am having problems with the git out of ports .... git-fetch keeps on dumping >> core when I try update of xorg (the initial checkout works ok). I'm running >> FreeBSD-current ... does anyone have any idea why this might be? > > What version of Git you're using and what protocol is used for > updating, native git or http? > > Any possibility of using ElectricFence (devel/ElectricFence) > for chasing memory-related troubles? Now that I have gdb working with me again, I am checking the git-fetch image to see where it got lost. If I must bring a tool such as ElectricFence I, I guess I must, just I'm a bit irritated that the git build has one of those make "improvements" (NOT) that instead of telling you the buid line, just gives you "CC sourcename.c" which for anyone who knows code is just irritating, not any sort of help at all. Anyhow, I can do my own testing for a bit now. I can say that I have tried other git archives, and it's the git-fetch that seems to be doing it, not the archive. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRqd7z62J6PPcoOkRAg/9AJ9WwjsefME8DKmgIsxgtcAvH5tkIwCgiGrg 72CV1T72i5F4D22LiTY8JOI= =edbu -----END PGP SIGNATURE----- From chuckr at telenix.org Wed Jun 4 14:44:15 2008 From: chuckr at telenix.org (Chuck Robey) Date: Wed Jun 4 14:44:19 2008 Subject: git problems In-Reply-To: <7tA3MvVpZ14HTFbKQUoucxMjR6I@XW7GVEPlMa2oCuO15y8lYU4QCgM> References: <4845AC84.6040407@telenix.org> <20080603212355.GB64397@hoeg.nl> <20080604134830.D49920@fledge.watson.org> <4846A2E7.2060003@telenix.org> <7tA3MvVpZ14HTFbKQUoucxMjR6I@XW7GVEPlMa2oCuO15y8lYU4QCgM> Message-ID: <4846A806.9040204@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eygene Ryabinkin wrote: > Chuck, > > Wed, Jun 04, 2008 at 10:12:55AM -0400, Chuck Robey wrote: >>>> I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace >>>> nearby, but it seems to be crash inside free(). >>> Application memory errors in HEAD but not in a RELENG_ branch are >>> frequently a symptom of an application bug unmasked by malloc(3) >>> debugging enabled in the development branch but not production >>> branches. It might not hurt to ramp up debugging on your 6.x install to >>> see if it starts crashing there was well -- see malloc(3) for details, >>> you'll want to create an appropriate malloc.conf. >> I didn't see the email where Ed Schouten commented about seeing my problems of >> seeing no good stack frames, but Robert, I run only -current here, not RELENG_6, >> so I can't do the testing you speak of. > > There is no need: I had tried this on -STABLE with environment > variable MALLOC_OPTIONS set to 'J' -- it dumps core. The problem > seems to be in the git-fetch: > ----- > $ MALLOC_OPTIONS=JA git-fetch --update-head-ok > Segmentation fault: 11 (core dumped) > ----- > This happens inside git repository of xserver and 100% reproducible > for my both -CURRENT and -STABLE. > >> I would want to see if maybe our gcc on >> - -current might have been made with a default of emitting no stack frames, which >> I would guess might have this effect. > > The stack seems to be smashed at the second call to > 'transport_unlock_pack': the argument called 'transport' seems to > carry the pointer to the area, filled by malloc() with byte 0x5a: > ----- > $ MALLOC_OPTIONS=JA gdb git-fetch > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > (gdb) run --update-head-ok > Starting program: /usr/local/bin/git-fetch --update-head-ok > > Program received signal SIGSEGV, Segmentation fault. > 0x4841de8b in free () from /lib/libc.so.7 > (gdb) bt > #0 0x4841de8b in free () from /lib/libc.so.7 > #1 0x080d8d04 in transport_unlock_pack (transport=0x820a0a0) > at transport.c:811 > #2 0x08066927 in unlock_pack () at builtin-fetch.c:56 > #3 0x48468fe3 in __cxa_finalize () from /lib/libc.so.7 > #4 0x4842199a in exit () from /lib/libc.so.7 > #5 0x0804b15b in handle_internal_command (argc=2, argv=0xffffffff) > at git.c:379 > #6 0x0804b8be in main (argc=2, argv=Error accessing memory address 0x10: Bad address. > ) at git.c:414 > (gdb) fr 1 > #1 0x080d8d04 in transport_unlock_pack (transport=0x820a0a0) > at transport.c:811 > 811 free(transport->pack_lockfile); > (gdb) print *transport > $1 = {remote = 0x5a5a5a5a, > url = 0x5a5a5a5a , > data = 0x5a5a5a5a, remote_refs = 0x5a5a5a5a, set_option = 0x5a5a5a5a, > get_refs_list = 0x5a5a5a5a, fetch = 0x5a5a5a5a, push = 0x5a5a5a5a, > disconnect = 0x5a5a5a5a, > pack_lockfile = 0x5a5a5a5a , > verbose = -2} > (gdb) > ----- > I don't believe that __cxa_finalize should call unlock_pack, so > stack seems to be smashed somewhere before. > >> I guess I could test this, and if it's so, recompile all my libraries to undo >> that, because I abhor doing things that utterly block any troubleshooting at a >> minimal savings elsewhere. > > You don't need to recompile anything to enable malloc debugging. > The easiest way is to set MALLOC_OPTIONS to the needed malloc > flags. Good, that's what I'd figured on my own. I may be slow as mollasses, but I'm more than a little stubborn, I will track this down (if no one else beats me to it). I really need my git to work here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRqgGz62J6PPcoOkRAs0nAJ0YK0+z9uoUn4Ja97ZG/UECj1OLGgCfffBj NLCk9xbUINso5d+5QohpefQ= =slbH -----END PGP SIGNATURE----- From rea-fbsd at codelabs.ru Wed Jun 4 14:48:16 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed Jun 4 14:48:21 2008 Subject: git problems In-Reply-To: <4846A77B.9060603@telenix.org> References: <4845AC84.6040407@telenix.org> <4846A77B.9060603@telenix.org> Message-ID: Chuck, Wed, Jun 04, 2008 at 10:32:27AM -0400, Chuck Robey wrote: > > Any possibility of using ElectricFence (devel/ElectricFence) > > for chasing memory-related troubles? > > Now that I have gdb working with me again, I am checking the git-fetch image to > see where it got lost. If I must bring a tool such as ElectricFence I, I guess > I must, just I'm a bit irritated that the git build has one of those make > "improvements" (NOT) that instead of telling you the buid line, just gives you > "CC sourcename.c" which for anyone who knows code is just irritating, not any > sort of help at all. No problems, just issue 'make V=1' instead of just 'make' in the /devel/git -- it will give you all flags and will eliminate the fancies. And 'make V=1 CFLAGS="-O0 -g"' will produce unoptimized binary with debug symbols that can be directly traced by gdb with all symbols and right (unoptimized, as in the sources) code paths. For the ElectricFence -- it dumps core just after startup, I don't know why. So it is not very much usable now, at least for me. Thank you. -- Eygene From chuckr at telenix.org Wed Jun 4 14:57:43 2008 From: chuckr at telenix.org (Chuck Robey) Date: Wed Jun 4 14:57:48 2008 Subject: git problems In-Reply-To: References: <4845AC84.6040407@telenix.org> <4846A77B.9060603@telenix.org> Message-ID: <4846AB2F.7090900@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eygene Ryabinkin wrote: > Chuck, > > Wed, Jun 04, 2008 at 10:32:27AM -0400, Chuck Robey wrote: >>> Any possibility of using ElectricFence (devel/ElectricFence) >>> for chasing memory-related troubles? >> Now that I have gdb working with me again, I am checking the git-fetch image to >> see where it got lost. If I must bring a tool such as ElectricFence I, I guess >> I must, just I'm a bit irritated that the git build has one of those make >> "improvements" (NOT) that instead of telling you the buid line, just gives you >> "CC sourcename.c" which for anyone who knows code is just irritating, not any >> sort of help at all. > > No problems, just issue 'make V=1' instead of just 'make' in the > /devel/git -- it will give you all flags and will eliminate > the fancies. And 'make V=1 CFLAGS="-O0 -g"' will produce unoptimized > binary with debug symbols that can be directly traced by gdb with > all symbols and right (unoptimized, as in the sources) code paths. > > For the ElectricFence -- it dumps core just after startup, I don't > know why. So it is not very much usable now, at least for me Well, maybe this will be of help (sure does make me want to look more closely at malloc, doesn't it?) #0 0x284369f3 in malloc_usable_size () from /lib/libc.so.7 (gdb) bt #0 0x284369f3 in malloc_usable_size () from /lib/libc.so.7 #1 0x28437067 in free () from /lib/libc.so.7 #2 0x080d5dd4 in transport_unlock_pack (transport=0x284c1c98) at transport.c:811 #3 0x08066467 in unlock_pack () at builtin-fetch.c:56 #4 0x2848b5f3 in __cxa_finalize () from /lib/libc.so.7 #5 0x2843b1aa in exit () from /lib/libc.so.7 #6 0x0804b0e3 in handle_internal_command (argc=2, argv=0xffffffff) at git.c:379 #7 0x0804b7ed in main (argc=2, argv=Cannot access memory at address 0x12 ) at git.c:414 (gdb) Oh, I didn't say this was from a git-fetch.core and a freshly rebuilt image in ports, did I? It is, though. I'm not done here, yet, but maybe your better knowledge of our malloc may help us a bit? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRqsvz62J6PPcoOkRAsPfAJ4wlm9W5Z1wCvQsVgwkjBor7BMZ5ACgkTW+ F4ahNZpzhJuD2Uru1vsoMQo= =EXb0 -----END PGP SIGNATURE----- From chuckr at telenix.org Wed Jun 4 15:35:31 2008 From: chuckr at telenix.org (Chuck Robey) Date: Wed Jun 4 15:35:35 2008 Subject: git problems In-Reply-To: References: <4845AC84.6040407@telenix.org> <4846A77B.9060603@telenix.org> Message-ID: <4846B40A.4010309@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eygene Ryabinkin wrote: > Chuck, > > Wed, Jun 04, 2008 at 10:32:27AM -0400, Chuck Robey wrote: >>> Any possibility of using ElectricFence (devel/ElectricFence) >>> for chasing memory-related troubles? >> Now that I have gdb working with me again, I am checking the git-fetch image to >> see where it got lost. If I must bring a tool such as ElectricFence I, I guess >> I must, just I'm a bit irritated that the git build has one of those make >> "improvements" (NOT) that instead of telling you the buid line, just gives you >> "CC sourcename.c" which for anyone who knows code is just irritating, not any >> sort of help at all. > > No problems, just issue 'make V=1' instead of just 'make' in the > /devel/git -- it will give you all flags and will eliminate > the fancies. And 'make V=1 CFLAGS="-O0 -g"' will produce unoptimized > binary with debug symbols that can be directly traced by gdb with > all symbols and right (unoptimized, as in the sources) code paths. > > For the ElectricFence -- it dumps core just after startup, I don't > know why. So it is not very much usable now, at least for me. > > Thank you. I think I have it narrowed down to either a problemm in process creation (I don't believe this one) or, more likely, a problem in managing the crt0 stuff in managing a process's startup bars. Take a look below and tell me if you agree. Here's the stack dump: #0 0x284369f3 in malloc_usable_size () from /lib/libc.so.7 #1 0x28437067 in free () from /lib/libc.so.7 #2 0x080d5dd4 in transport_unlock_pack (transport=0x284c1c98) at transport.c:811 #3 0x08066467 in unlock_pack () at builtin-fetch.c:56 #4 0x2848b5f3 in __cxa_finalize () from /lib/libc.so.7 #5 0x2843b1aa in exit () from /lib/libc.so.7 #6 0x0804b0e3 in handle_internal_command (argc=2, argv=0xffffffff) at git.c:379 #7 0x0804b7ed in main (argc=2, argv=Cannot access memory at address 0x12 ) at git.c:414 and here's the lines from git.c, the loop where handle_internal_command gets called: /* Turn "git cmd --help" into "git help cmd" */ 370 if (argc > 1 && !strcmp(argv[1], "--help")) { 371 argv[1] = argv[0]; 372 argv[0] = cmd = "help"; 373 } 374 375 for (i = 0; i < ARRAY_SIZE(commands); i++) { 376 struct cmd_struct *p = commands+i; 377 if (strcmp(p->cmd, cmd)) 378 continue; 379 exit(run_command(p, argc, argv)); 380 } First I want to comment on that weird line 379, because while it might work, it sure seems to me to be a very strange and wasteful way to do a fork. I bet that's some sort of portability hack. Second, the second argument to handle_internal_command seems to have been a argv=0xffffffff, which is very obviously a bad string pointer Looking at the top stack frame (main), that frame and the next are deeply involved in inspecting argv 0 thru 2, and since it's full of garbage, that's what breaks things. That's NOT malloc, that seems to be either a problem in process creation or (I think more likely) a problem in the creation of a process's environment, the crt0 stuff. I'm getting out of my depth, here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRrQKz62J6PPcoOkRAnwFAJ9XXb0cy/Rowt+X2uLx1uaYWJdHdACglAe6 dThwRYHJ9f95Qyua/syFsV4= =yFZR -----END PGP SIGNATURE----- From des at des.no Wed Jun 4 16:46:52 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Jun 4 16:47:18 2008 Subject: Is there any way to increase the KVM? In-Reply-To: <6a7033710806032317g4dbe8845h26a1196016b9c440@mail.gmail.com> (Tz-Huan Huang's message of "Wed\, 4 Jun 2008 14\:17\:52 +0800") References: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> <20080603135308.GC3434@garage.freebsd.pl> <6a7033710806032317g4dbe8845h26a1196016b9c440@mail.gmail.com> Message-ID: <86zlq140x0.fsf@ds4.des.no> "Tz-Huan Huang" writes: > The vfs.zfs.arc_max was set to 512M originally, the machine survived for > 4 days and panicked this morning. Now the vfs.zfs.arc_max is set to 64M > by Oliver's suggestion, let's see how long it will survive. :-) des@ds4 ~% uname -a FreeBSD ds4.des.no 8.0-CURRENT FreeBSD 8.0-CURRENT #27: Sat Feb 23 01:24:32 CET 2008 des@ds4.des.no:/usr/obj/usr/src/sys/ds4 amd64 des@ds4 ~% sysctl -h vm.kmem_size_min vm.kmem_size_max vm.kmem_size vfs.zfs.arc_min vfs.zfs.arc_max vm.kmem_size_min: 1,073,741,824 vm.kmem_size_max: 1,073,741,824 vm.kmem_size: 1,073,741,824 vfs.zfs.arc_min: 67,108,864 vfs.zfs.arc_max: 536,870,912 des@ds4 ~% zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT raid 1.45T 435G 1.03T 29% ONLINE - des@ds4 ~% zfs list | wc -l 210 Haven't had a single panic in over six months. DES -- Dag-Erling Sm?rgrav - des@des.no From tzhuan at csie.org Wed Jun 4 17:53:39 2008 From: tzhuan at csie.org (Tz-Huan Huang) Date: Wed Jun 4 17:53:45 2008 Subject: Is there any way to increase the KVM? In-Reply-To: <86zlq140x0.fsf@ds4.des.no> References: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> <20080603135308.GC3434@garage.freebsd.pl> <6a7033710806032317g4dbe8845h26a1196016b9c440@mail.gmail.com> <86zlq140x0.fsf@ds4.des.no> Message-ID: <6a7033710806041053g4a5c2fdftd7202b708bff363c@mail.gmail.com> On Thu, Jun 5, 2008 at 12:31 AM, Dag-Erling Sm?rgrav wrote: > "Tz-Huan Huang" writes: >> The vfs.zfs.arc_max was set to 512M originally, the machine survived for >> 4 days and panicked this morning. Now the vfs.zfs.arc_max is set to 64M >> by Oliver's suggestion, let's see how long it will survive. :-) > > des@ds4 ~% uname -a > FreeBSD ds4.des.no 8.0-CURRENT FreeBSD 8.0-CURRENT #27: Sat Feb 23 01:24:32 CET 2008 des@ds4.des.no:/usr/obj/usr/src/sys/ds4 amd64 > des@ds4 ~% sysctl -h vm.kmem_size_min vm.kmem_size_max vm.kmem_size vfs.zfs.arc_min vfs.zfs.arc_max > vm.kmem_size_min: 1,073,741,824 > vm.kmem_size_max: 1,073,741,824 > vm.kmem_size: 1,073,741,824 > vfs.zfs.arc_min: 67,108,864 > vfs.zfs.arc_max: 536,870,912 > des@ds4 ~% zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > raid 1.45T 435G 1.03T 29% ONLINE - > des@ds4 ~% zfs list | wc -l > 210 > > Haven't had a single panic in over six months. Thanks for your information, the major difference is that we runs on 7-stable and the size of our zfs pool is much bigger. root@cml2$ uname -a FreeBSD cml2.csie.ntu.edu.tw 7.0-STABLE FreeBSD 7.0-STABLE #40: Sat May 31 10:29:16 CST 2008 root@cml2.csie.ntu.edu.tw:/usr/local/obj/usr/local/src/sys/CML2 amd64 root@cml2$ sysctl -h vm.kmem_size_min vm.kmem_size_max vm.kmem_size vfs.zfs.arc_min vfs.zfs.arc_max vm.kmem_size_min: 0 vm.kmem_size_max: 1,610,612,736 vm.kmem_size: 1,610,612,736 vfs.zfs.arc_min: 16,777,216 vfs.zfs.arc_max: 67,108,864 root@cml2$ zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT sun 11.3T 9.03T 2.30T 79% ONLINE - root@cml2$ zfs list | wc -l 295 Thanks, Tz-Huan From peterjeremy at optushome.com.au Wed Jun 4 19:11:41 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Wed Jun 4 19:11:46 2008 Subject: git problems In-Reply-To: <4846B40A.4010309@telenix.org> References: <4845AC84.6040407@telenix.org> <4846A77B.9060603@telenix.org> <4846B40A.4010309@telenix.org> Message-ID: <20080604191137.GC1028@server.vk2pj.dyndns.org> On 2008-Jun-04 11:26:02 -0400, Chuck Robey wrote: >#3 0x08066467 in unlock_pack () at builtin-fetch.c:56 >#4 0x2848b5f3 in __cxa_finalize () from /lib/libc.so.7 >#5 0x2843b1aa in exit () from /lib/libc.so.7 >#6 0x0804b0e3 in handle_internal_command (argc=2, argv=0xffffffff) at git.c:379 >#7 0x0804b7ed in main (argc=2, argv=Cannot access memory at address 0x12) at git.c:414 __cxa_finalise() is part of the atexit() processing - the source comments imply it handles shared object destructors. >379 exit(run_command(p, argc, argv)); >380 } > >First I want to comment on that weird line 379, because while it >might work, it sure seems to me to be a very strange and wasteful way >to do a fork. There's no fork involved. It's just shorthand for: return_code = run_command(p, argc, argv); exit(return_code); By the time exit() is invoked, run_command() has completed. > Second, the second argument to handle_internal_command seems to >have been a argv=0xffffffff, which is very obviously a bad string >pointer Note that argv in main is also corrupt. I suspect gdb is confused by the level of optimisation being done by gcc. In a later posting, you indicate that there's a double-free bug. Possibly unlock_pack() is being registered as a destructor (or similar) _and_ is being explicitly called. Without studying the code, the solution is probably to either skip the explicit cleanup (leaving just the destructor processing) and/or flag freed data (ie NULL pointers after freeing them). -- 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-hackers/attachments/20080604/90fd7db5/attachment.pgp From rea-fbsd at codelabs.ru Wed Jun 4 19:14:44 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed Jun 4 19:14:48 2008 Subject: git problems In-Reply-To: <4846B40A.4010309@telenix.org> References: <4845AC84.6040407@telenix.org> <4846A77B.9060603@telenix.org> <4846B40A.4010309@telenix.org> Message-ID: Chuck, Wed, Jun 04, 2008 at 11:26:02AM -0400, Chuck Robey wrote: [...] > Looking at the top stack frame (main), that frame and the next are deeply > involved in inspecting argv 0 thru 2, and since it's full of garbage, that's > what breaks things. That's NOT malloc, that seems to be either a problem in > process creation or (I think more likely) a problem in the creation of a > process's environment, the crt0 stuff. I'm getting out of my depth, here. Sorry, I had thought about stack smashing, but it isn't it, so I somewhat guided people to the wrong way (if they were listening to me ;)) The real problem was the doubled call to the transport_unlock_pack() in the builtin-fetch.c. And the stack frame with __cxa_finalize was perfectly correct -- as I learned half an hour ago, it is the function that calls all handlers, registered with atexit(). So, the problem was the following: static function unlock_pack() in the builtin-fetch.c is the cleanup routine for the static variable 'transport'. And it calls transport_unlock_pack() if the 'transport' variable isn't NULL. But do_fetch() calls free(transport), so atexit's unlock_pack() tries to use already freed memory. The below patch works for me, although I should think about it once more to see if it handles all cases. Please, try the patch. --- builtin-fetch.c.orig 2008-06-04 22:49:05.000000000 +0400 +++ builtin-fetch.c 2008-06-04 23:07:51.000000000 +0400 @@ -598,7 +598,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix) { struct remote *remote; - int i; + int i, retval; static const char **refs = NULL; int ref_nr = 0; @@ -654,6 +654,14 @@ signal(SIGINT, unlock_pack_on_signal); atexit(unlock_pack); - return do_fetch(transport, + retval = do_fetch(transport, parse_fetch_refspec(ref_nr, refs), ref_nr); + /* + * Set transport to NULL, because its contents are already + * freed in do_fetch(), so we mustn't deinitialize it in + * unlock_pack(). + */ + transport = NULL; + + return retval; } -- Eygene From chagin.dmitry at gmail.com Wed Jun 4 19:51:46 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Wed Jun 4 19:51:51 2008 Subject: git problems In-Reply-To: References: <4845AC84.6040407@telenix.org> <4846A77B.9060603@telenix.org> <4846B40A.4010309@telenix.org> Message-ID: On Wed, 4 Jun 2008, Eygene Ryabinkin wrote: hello! has just subscribed.... this problem with git is fixed in version 1.5.5.1, our port requires updating. -- Have fun! chd From ed at 80386.nl Wed Jun 4 19:54:09 2008 From: ed at 80386.nl (Ed Schouten) Date: Wed Jun 4 19:54:12 2008 Subject: git problems In-Reply-To: <20080604191137.GC1028@server.vk2pj.dyndns.org> References: <4845AC84.6040407@telenix.org> <4846A77B.9060603@telenix.org> <4846B40A.4010309@telenix.org> <20080604191137.GC1028@server.vk2pj.dyndns.org> Message-ID: <20080604195357.GD1176@hoeg.nl> * Peter Jeremy wrote: > On 2008-Jun-04 11:26:02 -0400, Chuck Robey wrote: > >#3 0x08066467 in unlock_pack () at builtin-fetch.c:56 > >#4 0x2848b5f3 in __cxa_finalize () from /lib/libc.so.7 > >#5 0x2843b1aa in exit () from /lib/libc.so.7 > >#6 0x0804b0e3 in handle_internal_command (argc=2, argv=0xffffffff) at git.c:379 > >#7 0x0804b7ed in main (argc=2, argv=Cannot access memory at address 0x12) at git.c:414 > > __cxa_finalise() is part of the atexit() processing - the source comments > imply it handles shared object destructors. > > >379 exit(run_command(p, argc, argv)); > >380 } > > > >First I want to comment on that weird line 379, because while it > >might work, it sure seems to me to be a very strange and wasteful way > >to do a fork. > > There's no fork involved. It's just shorthand for: > return_code = run_command(p, argc, argv); > exit(return_code); > By the time exit() is invoked, run_command() has completed. > > > Second, the second argument to handle_internal_command seems to > >have been a argv=0xffffffff, which is very obviously a bad string > >pointer > > Note that argv in main is also corrupt. I suspect gdb is confused by > the level of optimisation being done by gcc. > > In a later posting, you indicate that there's a double-free bug. > Possibly unlock_pack() is being registered as a destructor (or > similar) _and_ is being explicitly called. Without studying the > code, the solution is probably to either skip the explicit cleanup > (leaving just the destructor processing) and/or flag freed data (ie > NULL pointers after freeing them). I just solved this on my systems by removing the call to free(). I know, it's awful, but it was good enough for me to live with on short term. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080604/3f1ecb71/attachment.pgp From rea-fbsd at codelabs.ru Wed Jun 4 20:11:14 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed Jun 4 20:11:19 2008 Subject: git problems In-Reply-To: References: <4845AC84.6040407@telenix.org> <4846A77B.9060603@telenix.org> <4846B40A.4010309@telenix.org> Message-ID: Dmitry, good day. Wed, Jun 04, 2008 at 11:21:59PM +0400, Chagin Dmitry wrote: > this problem with git is fixed in version 1.5.5.1, Yeah, commit 7b7f39eae6ab0bbcc68d3c42a5b23595880e528f > our port requires updating. Care to test? The diff from 1.5.5 is below. Ed, Eric, anyone, any comments? I had tested packaging list -- it seems to be unchanged since 1.5.5, both for the cases of GUI and GUI-less git. And no new functionality was brought in, judging by ChangeLog contents and quick glance over commits. ----- diff -urN ./Makefile ../git/Makefile --- ./Makefile 2008-06-04 23:52:50.000000000 +0400 +++ ../git/Makefile 2008-06-04 23:53:38.000000000 +0400 @@ -6,7 +6,7 @@ # PORTNAME= git -PORTVERSION= 1.5.5 +PORTVERSION= 1.5.5.3 CATEGORIES= devel MASTER_SITES= http://www.kernel.org/pub/software/scm/git/ DISTFILES= ${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX} \ diff -urN ./distinfo ../git/distinfo --- ./distinfo 2008-06-04 23:52:50.000000000 +0400 +++ ../git/distinfo 2008-06-04 23:58:08.000000000 +0400 @@ -1,6 +1,6 @@ -MD5 (git-1.5.5.tar.bz2) = 09f15f0b0e330986d930746abf6962f4 -SHA256 (git-1.5.5.tar.bz2) = 27483890c598450d7d1b4583e40dd8ec6c8def08c7cec94b20eb7336bb83e65e -SIZE (git-1.5.5.tar.bz2) = 1673736 -MD5 (git-manpages-1.5.5.tar.bz2) = 62a82276856add1d2b310d1e0b5ad5db -SHA256 (git-manpages-1.5.5.tar.bz2) = cc7f16b72a228cafd6bcc41ea09fdc67f4c5d50a0bf4521b80d8ea75127bb802 -SIZE (git-manpages-1.5.5.tar.bz2) = 162609 +SIZE (git-1.5.5.tar.bz2) = 1677113 +MD5 (git-1.5.5.3.tar.bz2) = 022ce5772b900243ef5d289deb7a3667 +SHA256 (git-1.5.5.3.tar.bz2) = c0a5220e7c80dc791e2077ec238298c2ec30af4d8d0ed6d2fbd7ca808266dfc0 +MD5 (git-manpages-1.5.5.3.tar.bz2) = 374a62ddf37343a5130f3318eab1ce2b +SHA256 (git-manpages-1.5.5.3.tar.bz2) = 770543b0ca871f72829f810d51f9e4d8b27659cbf4e73534fd09dfb5833f99de +SIZE (git-manpages-1.5.5.tar.bz2) = 163895 ----- Perhaps this topic should now be moved out of -hackers. -- Eygene From nlcom_os at ii.nl Wed Jun 4 22:55:13 2008 From: nlcom_os at ii.nl (Nanno Langstraat) Date: Wed Jun 4 22:55:17 2008 Subject: Standard byteorder functions across BSD / Linux Message-ID: <4847182F.80105@ii.nl> Hello, I think it would be nice to have standard byteorder conversion functions for user applications across the BSDs and Linux. betoh64(), htobe64(), etc. (like OpenBSD's sys/endian.h) Just small convenience functions/macros, but useful because it's such a common requirement; applications currently have to roll their own over&over with an annoying tangle of #ifdefs. Summary of the story so far: * glibc added the basic macros to * OpenBSD already had the macros in . They are for both kernel and application use according to the manpage. OpenBSD didn't want my patch that made the standard include file for user applications. * FreeBSD has similar but incompatible macros in . They are for kernel use, not application use according to the manpage. Full details below. (pretty long story for such a tiny feature) ---- My original proposal to the GNU glibc maintainers: * glibc Bugzilla 6442 - Adding cross-Unix endianness functions: betoh() / htobe() 64,32,16 http://sources.redhat.com/bugzilla/show_bug.cgi?id=6442 * Pro/con: http://sourceware.org/ml/libc-alpha/2008-05/msg00022.html ---- I planned to have a little coordination between glibc/FreeBSD/OpenBSD before starting on patches. That didn't happen, the glibc maintainers gave zero response for a full month, then created the basic macros in /usr/include/endian.h without any discussion. * ('endian.h' pre-existed in glibc to define __LITTLE_ENDIAN etc. The file does not pre-exist on OpenBSD / FreeBSD) * (glibc didn't adopt the "swap64()" etc. functions. Glibc already contains variants with a different naming pattern: "bswap_64()" etc.) * (be32enc() and friends only got a small mention by me, not adopted by glibc) ---- The discussion on the OpenBSD mailinglist can be read here: http://thread.gmane.org/gmane.os.openbsd.tech/15161/focus=15161 Of particular interest to FreeBSD: this charmless but informative email by Theo de Raadt, which outlines the history of the BSD kernel byteorder functions: http://thread.gmane.org/gmane.os.openbsd.tech/15161/focus=15179 ============================================================ My question to FreeBSD: I don't use FreeBSD myself, but I'll prepare a patch if you like the idea and if you indicate what you'll accept: * or ? I maintain that it should be for user applications: IMHO is for the user-kernel API, and byteorder belongs to libc not the kernel API. glibc apparently agrees, OpenBSD disagreed. * You're OK with userspace applications standardizing on OpenBSD's original betoh64() instead of FreeBSD's derivate be64toh() ? Regards, Nanno From max at love2party.net Wed Jun 4 23:19:53 2008 From: max at love2party.net (Max Laier) Date: Wed Jun 4 23:19:57 2008 Subject: Standard byteorder functions across BSD / Linux In-Reply-To: <4847182F.80105@ii.nl> References: <4847182F.80105@ii.nl> Message-ID: <200806050119.24405.max@love2party.net> On Thursday 05 June 2008 00:33:19 Nanno Langstraat wrote: > My question to FreeBSD: > I don't use FreeBSD myself, but I'll prepare a patch if you like the > idea and if you indicate what you'll accept: > > * or ? > I maintain that it should be for user applications: > IMHO is for the user-kernel API, and byteorder belongs to > libc not the kernel API. > glibc apparently agrees, OpenBSD disagreed. Not sure about this. There might be namespace issues with this approach, though there probably shouldn't. It's obviously not a problem to have both, but getting rid of sys/endian.h now is too late for sure. > * You're OK with userspace applications standardizing on OpenBSD's > original betoh64() instead of FreeBSD's derivate be64toh() ? I'm all for this. We should keep the both for backward compatibility and it will probably take some fixing to hunt down all ported code that does define betoh64 on its own. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From pjd at FreeBSD.org Thu Jun 5 06:27:34 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Thu Jun 5 06:27:38 2008 Subject: Is there any way to increase the KVM? In-Reply-To: <6a7033710806041053g4a5c2fdftd7202b708bff363c@mail.gmail.com> References: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> <20080603135308.GC3434@garage.freebsd.pl> <6a7033710806032317g4dbe8845h26a1196016b9c440@mail.gmail.com> <86zlq140x0.fsf@ds4.des.no> <6a7033710806041053g4a5c2fdftd7202b708bff363c@mail.gmail.com> Message-ID: <20080605062728.GA4278@garage.freebsd.pl> On Thu, Jun 05, 2008 at 01:53:37AM +0800, Tz-Huan Huang wrote: > On Thu, Jun 5, 2008 at 12:31 AM, Dag-Erling Sm??rgrav wrote: > > "Tz-Huan Huang" writes: > >> The vfs.zfs.arc_max was set to 512M originally, the machine survived for > >> 4 days and panicked this morning. Now the vfs.zfs.arc_max is set to 64M > >> by Oliver's suggestion, let's see how long it will survive. :-) > > > > des@ds4 ~% uname -a > > FreeBSD ds4.des.no 8.0-CURRENT FreeBSD 8.0-CURRENT #27: Sat Feb 23 01:24:32 CET 2008 des@ds4.des.no:/usr/obj/usr/src/sys/ds4 amd64 > > des@ds4 ~% sysctl -h vm.kmem_size_min vm.kmem_size_max vm.kmem_size vfs.zfs.arc_min vfs.zfs.arc_max > > vm.kmem_size_min: 1,073,741,824 > > vm.kmem_size_max: 1,073,741,824 > > vm.kmem_size: 1,073,741,824 > > vfs.zfs.arc_min: 67,108,864 > > vfs.zfs.arc_max: 536,870,912 > > des@ds4 ~% zpool list > > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > > raid 1.45T 435G 1.03T 29% ONLINE - > > des@ds4 ~% zfs list | wc -l > > 210 > > > > Haven't had a single panic in over six months. > > Thanks for your information, the major difference is that we > runs on 7-stable and the size of our zfs pool is much bigger. I'm don't think the panics are related to pool size. More to the load and characteristics of your workload. > root@cml2$ uname -a > FreeBSD cml2.csie.ntu.edu.tw 7.0-STABLE FreeBSD 7.0-STABLE #40: Sat > May 31 10:29:16 CST 2008 > root@cml2.csie.ntu.edu.tw:/usr/local/obj/usr/local/src/sys/CML2 amd64 > root@cml2$ sysctl -h vm.kmem_size_min vm.kmem_size_max vm.kmem_size > vfs.zfs.arc_min vfs.zfs.arc_max > vm.kmem_size_min: 0 > vm.kmem_size_max: 1,610,612,736 > vm.kmem_size: 1,610,612,736 > vfs.zfs.arc_min: 16,777,216 > vfs.zfs.arc_max: 67,108,864 > root@cml2$ zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > sun 11.3T 9.03T 2.30T 79% ONLINE - > root@cml2$ zfs list | wc -l > 295 If we're comparing who has bigger... :) beast:root:~# zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank 732G 604G 128G 82% ONLINE - but: beast:root:~# zfs list | wc -l 1932 No panics. PS. I'm quite sure the ZFS version I've in perforce will fix most if not all 'kmem_map too small' panics. It's not yet committed, but I do want to MFC it into RELENG_7. -- 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-hackers/attachments/20080605/28aceb16/attachment.pgp From koitsu at FreeBSD.org Thu Jun 5 06:53:30 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Jun 5 06:53:34 2008 Subject: Is there any way to increase the KVM? In-Reply-To: <20080605062728.GA4278@garage.freebsd.pl> References: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> <20080603135308.GC3434@garage.freebsd.pl> <6a7033710806032317g4dbe8845h26a1196016b9c440@mail.gmail.com> <86zlq140x0.fsf@ds4.des.no> <6a7033710806041053g4a5c2fdftd7202b708bff363c@mail.gmail.com> <20080605062728.GA4278@garage.freebsd.pl> Message-ID: <20080605065330.GA62591@eos.sc1.parodius.com> On Thu, Jun 05, 2008 at 08:27:28AM +0200, Pawel Jakub Dawidek wrote: > On Thu, Jun 05, 2008 at 01:53:37AM +0800, Tz-Huan Huang wrote: > > On Thu, Jun 5, 2008 at 12:31 AM, Dag-Erling Sm??rgrav wrote: > > > "Tz-Huan Huang" writes: > > >> The vfs.zfs.arc_max was set to 512M originally, the machine survived for > > >> 4 days and panicked this morning. Now the vfs.zfs.arc_max is set to 64M > > >> by Oliver's suggestion, let's see how long it will survive. :-) > > > > > > des@ds4 ~% uname -a > > > FreeBSD ds4.des.no 8.0-CURRENT FreeBSD 8.0-CURRENT #27: Sat Feb 23 01:24:32 CET 2008 des@ds4.des.no:/usr/obj/usr/src/sys/ds4 amd64 > > > des@ds4 ~% sysctl -h vm.kmem_size_min vm.kmem_size_max vm.kmem_size vfs.zfs.arc_min vfs.zfs.arc_max > > > vm.kmem_size_min: 1,073,741,824 > > > vm.kmem_size_max: 1,073,741,824 > > > vm.kmem_size: 1,073,741,824 > > > vfs.zfs.arc_min: 67,108,864 > > > vfs.zfs.arc_max: 536,870,912 > > > des@ds4 ~% zpool list > > > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > > > raid 1.45T 435G 1.03T 29% ONLINE - > > > des@ds4 ~% zfs list | wc -l > > > 210 > > > > > > Haven't had a single panic in over six months. > > > > Thanks for your information, the major difference is that we > > runs on 7-stable and the size of our zfs pool is much bigger. > > I'm don't think the panics are related to pool size. More to the load > and characteristics of your workload. Not to add superfluous comments, but I agree. It has little to do with actual pool size, but more with I/O activity. However, multiple zpools will very likely result in the panic happening sooner, just based on the "nature of the beast" -- more zpools likely means more "overall" I/O because there's more things people will be utilising via ZFS, thus you'll exhaust kmem quicker. > beast:root:~# zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > tank 732G 604G 128G 82% ONLINE - > > but: > > beast:root:~# zfs list | wc -l > 1932 > > No panics. > > PS. I'm quite sure the ZFS version I've in perforce will fix most if not > all 'kmem_map too small' panics. It's not yet committed, but I do want > to MFC it into RELENG_7. That's great to hear, but the point I've made regarding kmem_size not being able to extend past 2GB (on i386 and amd64) still stands. I've looked at the code myself, in attempt to figure out where the actual limitation is, and the code is beyond my understanding. (It's somewhat abstracted, but only to those who are completely unfamiliar to the VM piece -- like me :-) ). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From redcrash at gmail.com Thu Jun 5 08:15:38 2008 From: redcrash at gmail.com (Harald Servat) Date: Thu Jun 5 08:15:43 2008 Subject: mplayer pauses when holding a window Message-ID: Hello, today I was running mplayer playing an streaming url (just audio). There was a moment that I holded a(ny) window (i.e., click to move) for a long time (about 10-15s) and mplayer paused. Have anyone experienced this issue? I'm running mplayer-0.99.11_4 (I configured it to use esound), gnome2-lite-2.22.0, xorg 7.3 on FreeBSD 7.0 (ULE)/ia32. Regards, -- _________________________________________________________________ Empty your memory, with a free()... like a pointer! If you cast a pointer to an integer, it becomes an integer, if you cast a pointer to a struct, it becomes a struct. The pointer can crash..., and can overflow. Be a pointer my friend... From nlcom_os at ii.nl Thu Jun 5 09:45:14 2008 From: nlcom_os at ii.nl (Nanno Langstraat) Date: Thu Jun 5 09:45:19 2008 Subject: Standard byteorder functions across BSD / Linux In-Reply-To: <200806050119.24405.max@love2party.net> References: <4847182F.80105@ii.nl> <200806050119.24405.max@love2party.net> Message-ID: <4847B552.9070807@ii.nl> Max Laier wrote: > On Thursday 05 June 2008 00:33:19 Nanno Langstraat wrote: > >> * or ? >> I maintain that it should be for user applications: >> IMHO is for the user-kernel API, and byteorder belongs to >> libc not the kernel API. >> glibc apparently agrees, OpenBSD disagreed. >> > > Not sure about this. There might be namespace issues with this approach, > though there probably shouldn't. True. However, glibc (i.e. Linux) has had the file for a long time. (That's probably why Ulrich Drepper simply added the new macros there) Since they're something of an "800 pound gorilla", I don't think it'll be an additional hazard for BSD to add that file to the top-level file namespace. In fact, glibc are taking an extra risk, because their pre-existing is automatically pulled in by common things like and . On FreeBSD, a newly introduced can sit there innocently, and only be pulled in by user applications that explicitly know about it. > It's obviously not a problem to have > both, but getting rid of sys/endian.h now is too late for sure. > Agree, won't disappear, even if only because the kernel uses it. Nanno From tzhuan at csie.org Thu Jun 5 10:09:13 2008 From: tzhuan at csie.org (Tz-Huan Huang) Date: Thu Jun 5 10:09:17 2008 Subject: Is there any way to increase the KVM? In-Reply-To: <20080605062728.GA4278@garage.freebsd.pl> References: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> <20080603135308.GC3434@garage.freebsd.pl> <6a7033710806032317g4dbe8845h26a1196016b9c440@mail.gmail.com> <86zlq140x0.fsf@ds4.des.no> <6a7033710806041053g4a5c2fdftd7202b708bff363c@mail.gmail.com> <20080605062728.GA4278@garage.freebsd.pl> Message-ID: <6a7033710806050309l7b994e96i6e4f2f6383444ab0@mail.gmail.com> On Thu, Jun 5, 2008 at 2:27 PM, Pawel Jakub Dawidek wrote: > On Thu, Jun 05, 2008 at 01:53:37AM +0800, Tz-Huan Huang wrote: >> On Thu, Jun 5, 2008 at 12:31 AM, Dag-Erling Sm??rgrav wrote: > I'm don't think the panics are related to pool size. More to the load > and characteristics of your workload. I see. Our server exports all zfs filesytem via nfs to other 10 machines, which run the svm (http://en.wikipedia.org/wiki/Support_vector_machine) day and night to classify the video data ... > If we're comparing who has bigger... :) > > beast:root:~# zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > tank 732G 604G 128G 82% ONLINE - > > but: > > beast:root:~# zfs list | wc -l > 1932 > > No panics. > > PS. I'm quite sure the ZFS version I've in perforce will fix most if not > all 'kmem_map too small' panics. It's not yet committed, but I do want > to MFC it into RELENG_7. That's great news! Thanks, Tz-Huan From hugo at barafranca.com Thu Jun 5 13:24:56 2008 From: hugo at barafranca.com (Hugo Silva) Date: Thu Jun 5 13:25:06 2008 Subject: Is there any way to increase the KVM? In-Reply-To: <20080605062728.GA4278@garage.freebsd.pl> References: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> <20080603135308.GC3434@garage.freebsd.pl> <6a7033710806032317g4dbe8845h26a1196016b9c440@mail.gmail.com> <86zlq140x0.fsf@ds4.des.no> <6a7033710806041053g4a5c2fdftd7202b708bff363c@mail.gmail.com> <20080605062728.GA4278@garage.freebsd.pl> Message-ID: <4847E5AA.5010109@barafranca.com> Pawel Jakub Dawidek wrote: > On Thu, Jun 05, 2008 at 01:53:37AM +0800, Tz-Huan Huang wrote: > >> On Thu, Jun 5, 2008 at 12:31 AM, Dag-Erling Sm??rgrav wrote: >> >>> "Tz-Huan Huang" writes: >>> >>>> The vfs.zfs.arc_max was set to 512M originally, the machine survived for >>>> 4 days and panicked this morning. Now the vfs.zfs.arc_max is set to 64M >>>> by Oliver's suggestion, let's see how long it will survive. :-) >>>> >>> des@ds4 ~% uname -a >>> FreeBSD ds4.des.no 8.0-CURRENT FreeBSD 8.0-CURRENT #27: Sat Feb 23 01:24:32 CET 2008 des@ds4.des.no:/usr/obj/usr/src/sys/ds4 amd64 >>> des@ds4 ~% sysctl -h vm.kmem_size_min vm.kmem_size_max vm.kmem_size vfs.zfs.arc_min vfs.zfs.arc_max >>> vm.kmem_size_min: 1,073,741,824 >>> vm.kmem_size_max: 1,073,741,824 >>> vm.kmem_size: 1,073,741,824 >>> vfs.zfs.arc_min: 67,108,864 >>> vfs.zfs.arc_max: 536,870,912 >>> des@ds4 ~% zpool list >>> NAME SIZE USED AVAIL CAP HEALTH ALTROOT >>> raid 1.45T 435G 1.03T 29% ONLINE - >>> des@ds4 ~% zfs list | wc -l >>> 210 >>> >>> Haven't had a single panic in over six months. >>> >> Thanks for your information, the major difference is that we >> runs on 7-stable and the size of our zfs pool is much bigger. >> > > I'm don't think the panics are related to pool size. More to the load > and characteristics of your workload. > > >> root@cml2$ uname -a >> FreeBSD cml2.csie.ntu.edu.tw 7.0-STABLE FreeBSD 7.0-STABLE #40: Sat >> May 31 10:29:16 CST 2008 >> root@cml2.csie.ntu.edu.tw:/usr/local/obj/usr/local/src/sys/CML2 amd64 >> root@cml2$ sysctl -h vm.kmem_size_min vm.kmem_size_max vm.kmem_size >> vfs.zfs.arc_min vfs.zfs.arc_max >> vm.kmem_size_min: 0 >> vm.kmem_size_max: 1,610,612,736 >> vm.kmem_size: 1,610,612,736 >> vfs.zfs.arc_min: 16,777,216 >> vfs.zfs.arc_max: 67,108,864 >> root@cml2$ zpool list >> NAME SIZE USED AVAIL CAP HEALTH ALTROOT >> sun 11.3T 9.03T 2.30T 79% ONLINE - >> root@cml2$ zfs list | wc -l >> 295 >> > > If we're comparing who has bigger... :) > > beast:root:~# zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > tank 732G 604G 128G 82% ONLINE - > > but: > > beast:root:~# zfs list | wc -l > 1932 > > No panics. > > PS. I'm quite sure the ZFS version I've in perforce will fix most if not > all 'kmem_map too small' panics. It's not yet committed, but I do want > to MFC it into RELENG_7. > > Any guesstimate as to when the MFC will happen ? From ivoras at freebsd.org Thu Jun 5 14:00:23 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Jun 5 14:00:31 2008 Subject: Is there any way to increase the KVM? In-Reply-To: <20080605062728.GA4278@garage.freebsd.pl> References: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> <20080603135308.GC3434@garage.freebsd.pl> <6a7033710806032317g4dbe8845h26a1196016b9c440@mail.gmail.com> <86zlq140x0.fsf@ds4.des.no> <6a7033710806041053g4a5c2fdftd7202b708bff363c@mail.gmail.com> <20080605062728.GA4278@garage.freebsd.pl> Message-ID: Pawel Jakub Dawidek wrote: > If we're comparing who has bigger... :) > > beast:root:~# zpool list > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > tank 732G 604G 128G 82% ONLINE - > > but: > > beast:root:~# zfs list | wc -l > 1932 > > No panics. > > PS. I'm quite sure the ZFS version I've in perforce will fix most if not > all 'kmem_map too small' panics. It's not yet committed, but I do want > to MFC it into RELENG_7. At the risk of sounding repetitive, can you try a simple test on your ZFS pools, to see if you can panic the kernel? Do this: * install blogbench and bonnie++ from ports/benchmarks * run: blogbench -c 100 -d . -i 30 -r 50 -W 10 -w 10 bonnie++ -d . -s 16G -n 80 in parallel, until completion or crash. It shouldn't take too long to complete the above benchmarks, so you probably won't invest too much time in it even if it doesn't crash. (note: in the above command lines, "." is the current working directory, which is on ZFS, and "16G" is "2*RAM size". Keep the "-s" argument high even if you don't have lots of RAM.) This assumes you have a multi-core machine on which ZFS is running. 4 would be nice, 2 is probably ok. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080605/68368741/signature.pgp From rpaulo at FreeBSD.org Thu Jun 5 14:33:07 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Thu Jun 5 14:33:12 2008 Subject: mplayer pauses when holding a window In-Reply-To: References: Message-ID: <20080605143227.GB6864@epsilon.local> On Thu, Jun 05, 2008 at 09:49:12AM +0200, Harald Servat wrote: > Hello, > > today I was running mplayer playing an streaming url (just audio). There > was a moment that I holded a(ny) window (i.e., click to move) for a long > time (about 10-15s) and mplayer paused. > Have anyone experienced this issue? > > I'm running mplayer-0.99.11_4 (I configured it to use esound), > gnome2-lite-2.22.0, xorg 7.3 on FreeBSD 7.0 (ULE)/ia32. This is normal behavior and I think this is a Window Manager issue, not a FreeBSD issue. Regards, -- Rui Paulo From fabonacci at yahoo.com Thu Jun 5 18:08:21 2008 From: fabonacci at yahoo.com (John Timony) Date: Thu Jun 5 18:08:44 2008 Subject: Matrix 2 Reload... Message-ID: <97039.54881.qm@web46312.mail.sp1.yahoo.com> HI,all Which operating system did the film used by Trinity? Thx,, Fabonacci. From amsibamsi at gmail.com Thu Jun 5 19:50:57 2008 From: amsibamsi at gmail.com (Anselm Strauss) Date: Thu Jun 5 19:51:00 2008 Subject: Introducing myself (better late than never) Message-ID: <09461409-746F-4BBE-BA76-5FE732977B7E@gmail.com> Hi, my name is Anselm Strauss and I'm working on FreeBSD's libarchive mentored by Tim Kientzle in this year's Google Summer of Code. If you want to know more about the project you should find enough information on: http://wiki.freebsd.org/AnselmStrauss/LibArchive I'm a computer science student at the University of Bern in Switzerland and in my final studies for graduating (hopefully) this autumn. I'm really looking forward to code on FreeBSD and work together with great people. Happy hacking to you hackers, Cheers. From onemda at gmail.com Thu Jun 5 21:19:11 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Jun 5 21:19:13 2008 Subject: mplayer pauses when holding a window In-Reply-To: <20080605143227.GB6864@epsilon.local> References: <20080605143227.GB6864@epsilon.local> Message-ID: <3a142e750806051354s7867708esb23ba4320037b5ba@mail.gmail.com> I could not reproduce this with fvwm and mplayer (without esoud). But I am aware of following (fv)wm/Xorg issue/bug/feature: if you configured your window manager to not display window when moving it (instead wm display frame) all Xorg windows will be put in suspend state (music will stop playing, and such ...) On 6/5/08, Rui Paulo wrote: > On Thu, Jun 05, 2008 at 09:49:12AM +0200, Harald Servat wrote: >> Hello, >> >> today I was running mplayer playing an streaming url (just audio). There >> was a moment that I holded a(ny) window (i.e., click to move) for a long >> time (about 10-15s) and mplayer paused. >> Have anyone experienced this issue? >> >> I'm running mplayer-0.99.11_4 (I configured it to use esound), >> gnome2-lite-2.22.0, xorg 7.3 on FreeBSD 7.0 (ULE)/ia32. > > This is normal behavior and I think this is a Window Manager issue, not > a FreeBSD issue. > > Regards, > -- > Rui Paulo > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From ges at wingfoot.org Thu Jun 5 19:48:47 2008 From: ges at wingfoot.org (Glenn Sieb) Date: Thu Jun 5 23:35:13 2008 Subject: Matrix 2 Reload... In-Reply-To: <97039.54881.qm@web46312.mail.sp1.yahoo.com> References: <97039.54881.qm@web46312.mail.sp1.yahoo.com> Message-ID: <48483ED5.2040800@wingfoot.org> John Timony wrote: > HI,all > Which operating system did the film used by Trinity? > Thx,, > Fabonacci. > MovieOS? (Starts here...) http://ars.userfriendly.org/cartoons/?id=20010111 ;-) Best, --Glenn -- ...destination is merely a byproduct of the journey --Eric Hansen From pjd at FreeBSD.org Fri Jun 6 06:09:53 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Fri Jun 6 06:09:57 2008 Subject: Is there any way to increase the KVM? In-Reply-To: <4847E5AA.5010109@barafranca.com> References: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> <20080603135308.GC3434@garage.freebsd.pl> <6a7033710806032317g4dbe8845h26a1196016b9c440@mail.gmail.com> <86zlq140x0.fsf@ds4.des.no> <6a7033710806041053g4a5c2fdftd7202b708bff363c@mail.gmail.com> <20080605062728.GA4278@garage.freebsd.pl> <4847E5AA.5010109@barafranca.com> Message-ID: <20080606060946.GA4090@garage.freebsd.pl> On Thu, Jun 05, 2008 at 02:10:02PM +0100, Hugo Silva wrote: > Pawel Jakub Dawidek wrote: > >PS. I'm quite sure the ZFS version I've in perforce will fix most if not > >all 'kmem_map too small' panics. It's not yet committed, but I do want > >to MFC it into RELENG_7. > > > > > > Any guesstimate as to when the MFC will happen ? Hard to tell, really. The number of changes is huge, so it's hard to predict how much I'd need to fix after commit to HEAD. Two months sounds possible. I'll provide patches for RELENG_7 probably earlier. -- 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-hackers/attachments/20080606/fbce48ee/attachment.pgp From redcrash at gmail.com Fri Jun 6 07:49:19 2008 From: redcrash at gmail.com (Harald Servat) Date: Fri Jun 6 07:49:30 2008 Subject: mplayer pauses when holding a window In-Reply-To: <3a142e750806051354s7867708esb23ba4320037b5ba@mail.gmail.com> References: <20080605143227.GB6864@epsilon.local> <3a142e750806051354s7867708esb23ba4320037b5ba@mail.gmail.com> Message-ID: Hi, 2008/6/5 Paul B. Mahol : > I could not reproduce this with fvwm and mplayer (without esoud). But > I am aware of following (fv)wm/Xorg issue/bug/feature: if you > configured your window manager to not display window when moving it > (instead wm display frame) all Xorg windows will be put in suspend > state (music will stop playing, and such ...) > Paul, you hit the nail on the head. I have "Metacity>Reduced resources" enabled in the Gnome Configurator. If I disable it, this issue disappear. Regards, > > On 6/5/08, Rui Paulo wrote: > > On Thu, Jun 05, 2008 at 09:49:12AM +0200, Harald Servat wrote: > >> Hello, > >> > >> today I was running mplayer playing an streaming url (just audio). > There > >> was a moment that I holded a(ny) window (i.e., click to move) for a long > >> time (about 10-15s) and mplayer paused. > >> Have anyone experienced this issue? > >> > >> I'm running mplayer-0.99.11_4 (I configured it to use esound), > >> gnome2-lite-2.22.0, xorg 7.3 on FreeBSD 7.0 (ULE)/ia32. > > > > This is normal behavior and I think this is a Window Manager issue, not > > a FreeBSD issue. > > > > Regards, > > -- > > Rui Paulo > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > > > -- _________________________________________________________________ Empty your memory, with a free()... like a pointer! If you cast a pointer to an integer, it becomes an integer, if you cast a pointer to a struct, it becomes a struct. The pointer can crash..., and can overflow. Be a pointer my friend... From gahr at FreeBSD.org Fri Jun 6 09:19:05 2008 From: gahr at FreeBSD.org (Pietro Cerutti) Date: Fri Jun 6 09:19:10 2008 Subject: Introducing myself (better late than never) In-Reply-To: <09461409-746F-4BBE-BA76-5FE732977B7E@gmail.com> References: <09461409-746F-4BBE-BA76-5FE732977B7E@gmail.com> Message-ID: <4848866D.3010706@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Anselm Strauss wrote: | Hi, Hi Anselm, ++CH !!! | I'm a computer science student at the University of Bern in Switzerland | and in my final studies for graduating (hopefully) this autumn. I'm | really looking forward to code on FreeBSD and work together with great | people. Uni^b or BFH? I've done my studies at BFH :) | Happy hacking to you hackers, Same to you! | Cheers. Gretz! - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkhIhm0ACgkQwMJqmJVx945NGQCgoYETvWWJGO6XgTRikst5oxfx GDEAn3ixzWeJG1An3oA9D4dVjCIwjKiz =vFX6 -----END PGP SIGNATURE----- From daniel.lannstrom at gmail.com Fri Jun 6 10:32:08 2008 From: daniel.lannstrom at gmail.com (=?ISO-8859-1?Q?Daniel_L=E4nnstr=F6m?=) Date: Fri Jun 6 10:32:16 2008 Subject: Matrix 2 Reload... In-Reply-To: <97039.54881.qm@web46312.mail.sp1.yahoo.com> References: <97039.54881.qm@web46312.mail.sp1.yahoo.com> Message-ID: John Timony wrote: > HI,all > Which operating system did the film used by Trinity? > Thx,, > Fabonacci. The story doesn't tell, if I remember correctly. However they are exploiting a vulnerability in an early version of OpenSSH using nmap. I think nmap had some more information on their homepage, not sure if it's there anymore though. From murilo.esplugues at gmail.com Fri Jun 6 12:05:14 2008 From: murilo.esplugues at gmail.com (Murilo R. Esplugues) Date: Fri Jun 6 12:05:21 2008 Subject: Matrix 2 Reload... In-Reply-To: References: <97039.54881.qm@web46312.mail.sp1.yahoo.com> Message-ID: <2e81840c0806060438k1390275ch29151d3f05ba6ded@mail.gmail.com> In the captured screen in nmap.org, the output is "no exact OS machs for host" http://nmap.org/images/matrix/nmap-matrix2log.jpg unix like OS -- Murilo R. Esplugues murilo.esplugues@gmail.com From des at des.no Fri Jun 6 12:18:38 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri Jun 6 12:18:44 2008 Subject: Is there any way to increase the KVM? In-Reply-To: <20080605065330.GA62591@eos.sc1.parodius.com> (Jeremy Chadwick's message of "Wed\, 4 Jun 2008 23\:53\:30 -0700") References: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> <20080603135308.GC3434@garage.freebsd.pl> <6a7033710806032317g4dbe8845h26a1196016b9c440@mail.gmail.com> <86zlq140x0.fsf@ds4.des.no> <6a7033710806041053g4a5c2fdftd7202b708bff363c@mail.gmail.com> <20080605062728.GA4278@garage.freebsd.pl> <20080605065330.GA62591@eos.sc1.parodius.com> Message-ID: <86y75iah9f.fsf@ds4.des.no> Jeremy Chadwick writes: > That's great to hear, but the point I've made regarding kmem_size not > being able to extend past 2GB (on i386 and amd64) still stands. I've > looked at the code myself, in attempt to figure out where the actual > limitation is, and the code is beyond my understanding. IIRC, it's a hardware limitation. Search the archives for "kmem_size" and my name for a full explanation. DES -- Dag-Erling Sm?rgrav - des@des.no From sylvain.desbureaux at gmail.com Fri Jun 6 12:53:21 2008 From: sylvain.desbureaux at gmail.com (Sylvain Desbureaux) Date: Fri Jun 6 12:53:27 2008 Subject: virtio drivers for freebsd Message-ID: <652bbbf50806060526j5956c518u6b7e81756f187c38@mail.gmail.com> Hi all, I'm currently using linux KVM as an hypervisor and I would like to use an old freebsd4 machine as a guest. The thing is that machine is very network consuming, so it would be great to have special drivers. KVM has now special drivers, based on the virtio specifications. These drivers are compiled for windows and linux but unfortunately not for BSD. I think that they are pretty simple in the guest side (75kb of code for linux for example, for network and block device) but I'm not very good in kernel driver compilation. Do you think it could be interesting to integrate them as a module into FreeBSD? I really think it could be interesting to have easily Freebsd paravirtualized guest on top of KVM. Anybody wanting to do that (I really would like to know how to do but I'm not skilled enough)? Thanks in advance for you answers :) Sylvain From mohacsi at niif.hu Fri Jun 6 17:02:41 2008 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri Jun 6 17:02:44 2008 Subject: openssl with zlib support Message-ID: <20080606185442.O7163@mignon.ki.iif.hu> Dear All, Are there any reason to not enabling zlib compression for TLS in openssl on FreeBSD ? My colleague tested with some different platforms: user@host:~$ openssl s_client -ssl3 -connect linuxmachine.hu:https /dev/null | grep Compression Compression: zlib compression Compression: 1 (zlib compression) user@host:~$ openssl s_client -ssl3 -connect freebsdmachine.hu:https /dev/null | grep Compression Compression: NONE Would it break ABI if I enable it by tweaking the openssl Makefile? Best Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 From uspoerlein at gmail.com Fri Jun 6 19:02:45 2008 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Fri Jun 6 19:02:51 2008 Subject: FreeBSD + LDAP + SAMBA + WINDOWS In-Reply-To: <5ce468b90805281511h2729be73l65dccdcfe13ad4db@mail.gmail.com> References: <5ce468b90805281511h2729be73l65dccdcfe13ad4db@mail.gmail.com> Message-ID: <20080606185326.GC1646@roadrunner.spoerlein.net> On Wed, 28.05.2008 at 19:11:06 -0300, Israel Lehnen Silva wrote: > Friends, > > I have the following scenario: > > Server FreeBSD 7.0 Stable authenticating in one basis LDAP through of the > PAM (pam_ldap and nss_ldap) > In same server, have running the SAMBA 3.0.28 authenticating too in > basis LDAP and using the scripts smbldap-tools. > Tool LDAPAdmin for administration of basis LDAP. > > THE PROBLEM: > > When chang the pass of user in basis LDAP trhough of LDAPAdmin, > select th cryptograpy "MD5 Crypt" for the atribuct userPassword > This way, I achieve log in the Windows and FreeBSD by terminal, ssh... > but when chang pass of user by Windows, the cryptograpy of password in > atribuct userPassword > is chanded for SSHA and so not conect in FreeBSD, also just conect in > windows. > > FreeBSD and SAMBA authenticating in LDAP, > and changing the password by own user, not interfering in auth of ssh in > FreeBSD... > Someone implemented??? Hi, I think you have this backwards. At our setup, with active samba password sync users can change their samba{LM,NT}passwords and have their userPassword updated accordingly. Samba will not change the used algorithm, though (we use {CRYPT}, don't ask ...) The other way round though will only update the userPassword and not change the samba{Lm,NT}passwords leading to the old password still being valid for Windows. We're using a small CGI script where our users can change (both) passwords in their browser. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From det135 at psu.edu Fri Jun 6 19:15:27 2008 From: det135 at psu.edu (Derek Taylor) Date: Fri Jun 6 19:15:35 2008 Subject: Kerberized CIFS client? In-Reply-To: References: <20080521182722.GC40818@psu.edu> <483554FC.9040908@dlr.de> <20080603134307.GK76952@psu.edu> <20080603173601.W41705@beagle.kn.op.dlr.de> <20080603160608.GA56965@psu.edu> Message-ID: <20080606191524.GQ56965@psu.edu> On Tue, 03 Jun 2008, Atte Peltomki wrote: >You will have to adjust your krb5.conf to map a given domain or hostname >to a kerberos realm, if you are doing cross-realm authentication. See MIT >kerberos admin guide for details. I'm pretty sure it's set up ok. I can use smbclient -k just fine: $ kinit det135@realm.example.com's Password: kinit: NOTICE: ticket renewable lifetime is 1 week $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: det135@realm.example.com Issued Expires Principal Jun 6 15:08:47 Jun 7 01:08:47 krbtgt/realm.example.com@realm.example.com $ smbclient -k -U det135 //cifs.example.com/dir1 OS=[Unix] Server=[Samba 3.0.30] smb: \> ls . D 0 Thu Feb 14 14:46:42 2008 .. D 0 Fri Jun 6 10:16:29 2008 [ other files/directories here ] smb: \> quit $ cd ~/mount/smbbeta.pass.psu.edu/pass $ ls ls: .: Permission denied $ klist Credentials cache: FILE:/tmp/krb5cc_1001 Principal: det135@dce.psu.edu Issued Expires Principal Jun 6 15:08:47 Jun 7 01:08:47 krbtgt/realm.example.com@realm.example.com Jun 6 15:09:17 Jun 7 01:08:47 cifs/cifs.example.com@realm.example.com $ -Derek. >On 6/3/08, Derek Taylor wrote: >> On Tue, 03 Jun 2008, Harti Brandt wrote: >>>On Tue, 3 Jun 2008, Derek Taylor wrote: >>> >>>DT>On Thu, 22 May 2008, Hartmut Brandt wrote: >>>DT>>Derek Taylor wrote: >>>DT>>> This question was previously posed of the freebsd-questions list, but >>>DT>>> with no response for a week, I'd like to try my luck here. If >>> there's >>>DT>>> any more information I should include, please speak up: I would be >>> glad >>>DT>>> to oblige. >>>DT>>> >>>DT>>> I would like to use smb/cifs with kerberos auth, but mount_smbfs >>> doesn't >>>DT>>> seem to support this. >>>DT>>> >>>DT>>> Is anyone aware of an alternate means of performing a mount via >>> smb/cifs >>>DT>>> or any patches to provide such functionality? >>>DT>>> >>>DT>>> I already have smbclient working with -k, but I am also interested in >>> a >>>DT>>> mount. >>>DT>> >>>DT>>Try smbnetfs from ports. It's fuse based and seems to work very nice. >>> If >>>DT>>you have a large amount of shares floating in your network you want to >>>DT>>restrict it to mount only the needed shares via the config file. >>>DT>>Otherwise it will mount what it can find... >>>DT>> >>>DT>>It plays nicely with kerberors. When your ticket expires you >>> immediately >>>DT>>loose access; when you renew it you gain access again. All without the >>>DT>>need to unmount/mount. Just call smbnetfs once you have your ticket. >>> You >>>DT>>may even do this from your .profile. >>>DT>> >>>DT>>harti >>>DT> >>>DT>Sorry for not replying sooner. >>>DT> >>>DT>Initial tests here are promising (I can see some mount paths being >>>DT>exported from the server), but it's not fully working (I don't see all >>>DT>of the mount paths that *should* be exported and I get permission denied >>>DT>errors). My thoughts are leaning towards an issue in negotiating auth >>>DT>with the server -- perhaps my krb creds aren't being used? >>> >>>You can test this easily: if your ticket expires you get permission denied >>>errors when you try to look into the mounted directories. As soon as you >>>renew the ticket you get access again. All without restarting smbnetfs. >>> >>>harti >> >> I replaced all server names below with "example.com" (and derivatives) >> where appropriate: >> >> From my FreeBSD machine, using smbnetfs: >> >> $ klist >> klist: No ticket file: /tmp/krb5cc_1001 >> $ kinit det135 >> det135@realm.example.com's Password: >> kinit: NOTICE: ticket renewable lifetime is 1 week >> $ klist >> Credentials cache: FILE:/tmp/krb5cc_1001 >> Principal: det135@realm.example.com >> >> Issued Expires Principal >> Jun 3 11:51:20 Jun 3 21:51:04 krbtgt/realm.example.com@realm.example.com >> $ cd ~/mount/cifs.example.com/dir1 >> $ ls >> ls: .: Permission denied >> $ cd .. >> $ ls >> dir1 dir2 >> $ klist >> Credentials cache: FILE:/tmp/krb5cc_1001 >> Principal: det135@realm.example.com >> >> Issued Expires Principal >> Jun 3 11:51:20 Jun 3 21:51:04 krbtgt/realm.example.com@realm.example.com >> >> >> From my Mac, using (from Finder) >> Go -> Connect to Server -> cifs://cifs.example.com/dir1 >> >> $ klist >> klist: No Kerberos 5 tickets in credentials cache >> $ kinit det135 >> Please enter the password for det135@realm.example.com: >> $ klist >> Kerberos 5 ticket cache: 'API:Initial default ccache' >> Default principal: det135@realm.example.com >> >> Valid Starting Expires Service Principal >> 06/03/08 11:59:41 06/03/08 21:59:41 >> krbtgt/realm.example.com@realm.example.com >> renew until 06/10/08 11:59:41 >> >> #### Here I mount via Finder before continuing with the commands below >> >> $ cd /Volumes/dir1/ >> $ ls >> subdir1 subdir2 file1 file2 >> $ klist >> Kerberos 5 ticket cache: 'API:Initial default ccache' >> Default principal: det135@realm.example.com >> >> Valid Starting Expires Service Principal >> 06/03/08 11:59:41 06/03/08 21:59:41 >> krbtgt/realm.example.com@realm.example.com >> renew until 06/10/08 11:59:41 >> 06/03/08 12:00:31 06/03/08 21:59:41 >> cifs/cifs.example.com@realm.example.com >> renew until 06/10/08 11:59:41 >> >> >> It looks like my creds aren't being used on the FreeBSD machine. >> >> -Derek. >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > From jhb at freebsd.org Fri Jun 6 20:57:03 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri Jun 6 20:57:05 2008 Subject: Is there any way to increase the KVM? In-Reply-To: <86y75iah9f.fsf@ds4.des.no> References: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> <20080605065330.GA62591@eos.sc1.parodius.com> <86y75iah9f.fsf@ds4.des.no> Message-ID: <200806061552.58205.jhb@freebsd.org> On Friday 06 June 2008 08:18:36 am Dag-Erling Sm?rgrav wrote: > Jeremy Chadwick writes: > > That's great to hear, but the point I've made regarding kmem_size not > > being able to extend past 2GB (on i386 and amd64) still stands. I've > > looked at the code myself, in attempt to figure out where the actual > > limitation is, and the code is beyond my understanding. > > IIRC, it's a hardware limitation. Search the archives for "kmem_size" > and my name for a full explanation. While global variables have to be within 2GB for %rip relative addressing, there's no reason malloc'd buffers can't be anywhere in the 64-bit address space since pointers are 64-bits. -- John Baldwin From det135 at psu.edu Fri Jun 6 20:57:14 2008 From: det135 at psu.edu (Derek Taylor) Date: Fri Jun 6 20:57:19 2008 Subject: Kerberos support in NFSv4 Message-ID: <20080606205713.GS56965@psu.edu> Is anyone aware of a project to add kerberos support to FreeBSD's NFSv4 implementation? Is there a better list to ask about development efforts and directions for HEAD? Thanks. -Derek. From peterjeremy at optushome.com.au Fri Jun 6 21:14:21 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Fri Jun 6 21:14:25 2008 Subject: virtio drivers for freebsd In-Reply-To: <652bbbf50806060526j5956c518u6b7e81756f187c38@mail.gmail.com> References: <652bbbf50806060526j5956c518u6b7e81756f187c38@mail.gmail.com> Message-ID: <20080606211406.GN67629@server.vk2pj.dyndns.org> On 2008-Jun-06 14:26:24 +0200, Sylvain Desbureaux wrote: >I'm currently using linux KVM as an hypervisor and I would like to use >an old freebsd4 machine as a guest. I agree that virtualising FreeBSD is useful but I suspect your chances of getting guest patches for FreeBSD 4.x are very low. FreeBSD 4.x is no longer supported by the FreeBSD project and there are significant changes in the kernel architecture between 4.x and later versions. For new features to be added to FreeBSD, they must be first added to the latest version and then back-ported to older versions - the backport to 4.x would probably require significant effort. >KVM has now special drivers, based on the virtio specifications. These >drivers are compiled for windows and linux but unfortunately not for >BSD. I think that they are pretty simple in the guest side (75kb of >code for linux for example, for network and block device) but I'm not >very good in kernel driver compilation. Note that FreeBSD does not have block-mode devices. -- 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-hackers/attachments/20080606/7230d1e1/attachment.pgp From patfbsd at davenulle.org Fri Jun 6 21:57:13 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Fri Jun 6 21:57:17 2008 Subject: AMD Geode LX crypto accelerator (glxsb) Message-ID: <20080606234135.46144207@baby-jane-lamaiziere-net.local> Dears, I'm trying to port the glxsb driver from OpenBSD to FreeBSD 7-STABLE (via the NetBSD port). " The glxsb driver supports the security block of the Geode LX series processors. The Geode LX is a member of the AMD Geode family of integrated x86 system chips. Driven by periodic checks for available data from the generator, glxsb supplies entropy to the random(4) driver for common usage. glxsb also supports acceleration of AES-128-CBC operations for crypto(4)." I think that most of the work is done, except the random generator. Source "in progress" for 7-STABLE: http://user.lamaiziere.net/patrick/glxsb.c http://user.lamaiziere.net/patrick/glxsb.tar.gz (c+Makefile) Credits to OpenBSD and NetBSD, Thanks! Well, it seems to work but i've got few problems to test the module : - How check the encryption/decryption ? Openssl seems ok, i've got quite the same results as NetBSD on a Soekris net5501 box. But i must use -engine cryptodev, why ? $ openssl speed -evp aes-128-cbc -engine cryptodev -elapsed engine "cryptodev" set. ...CUT... type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 1151.08k 4134.25k 11936.49k 22504.83k 25576.36k When i test ssh -c aes128-cbc hostname, ssh does not use the crypto device. I receive a crypto_newsession() followed by a crypto_freesession(), i mean i don't receive any crypto_process(). So how can I be sure that the datas are well encrypted ? Also, I've got some questions to finish the driver: - between arc4rand() and read_random(), witch function shall i use ? - Shall I lock the sessions ? The padlock driver uses a mutex to lock the sessions http://fxr.watson.org/fxr/source/crypto/via/padlock.c?v=FREEBSD7#L211 Is it usefull ? Drivers ubsec, safe and hifn don't lock the sessions at all. - during crypto_process() the driver uses "s = splnet();". I'm not sure about this ? - The driver does a busy wait to check the completion of the encryption. I think it would be beter to use the interrupt. I will look later. - Any comment is welcome, this is my first work on a driver. Thanks, regards. From zachary.loafman at isilon.com Sat Jun 7 02:45:17 2008 From: zachary.loafman at isilon.com (Zachary Loafman) Date: Sat Jun 7 02:45:21 2008 Subject: Kerberos support in NFSv4 In-Reply-To: <20080606205713.GS56965@psu.edu> References: <20080606205713.GS56965@psu.edu> Message-ID: <20080607023315.GD31784@zloafman.west.isilon.com> Isilon Systems is sponsoring RPCSEC_GSS work for FreeBSD soon. I expect that we'll have it CURRENT later this year. We don't really have any plans to glue it into the v4 client just yet, we're targeting Kerberized NFSv3 first. We are looking at NFSv4 longer term, though, at which point we will have to beat the v4 client into shape for internal testing purposes. ...Zach On Fri, Jun 06, 2008 at 04:57:13PM -0400, Derek Taylor wrote: > Is anyone aware of a project to add kerberos support to FreeBSD's NFSv4 > implementation? > > Is there a better list to ask about development efforts and directions > for HEAD? > > Thanks. > > -Derek. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Zach Loafman | Staff Engineer Isilon Systems D +1-206-315-7570 F +1-206-315-7485 www.isilon.com P +1-206-315-7500 M +1-206-422-3461 From pjd at FreeBSD.org Sat Jun 7 04:19:02 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Sat Jun 7 04:19:05 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <20080606234135.46144207@baby-jane-lamaiziere-net.local> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> Message-ID: <20080607041855.GA3462@garage.freebsd.pl> On Fri, Jun 06, 2008 at 11:41:35PM +0200, Patrick Lamaizi?re wrote: > Dears, > > I'm trying to port the glxsb driver from OpenBSD to FreeBSD 7-STABLE > (via the NetBSD port). Cool. > " The glxsb driver supports the security block of the Geode LX > series processors. The Geode LX is a member of the AMD Geode family > of integrated x86 system chips. > > Driven by periodic checks for available data from the generator, > glxsb supplies entropy to the random(4) driver for common usage. > > glxsb also supports acceleration of AES-128-CBC operations for > crypto(4)." > > I think that most of the work is done, except the random generator. > Source "in progress" for 7-STABLE: > http://user.lamaiziere.net/patrick/glxsb.c > http://user.lamaiziere.net/patrick/glxsb.tar.gz (c+Makefile) > > Credits to OpenBSD and NetBSD, Thanks! > > Well, it seems to work but i've got few problems to test the module : > > - How check the encryption/decryption ? > > Openssl seems ok, i've got quite the same results as NetBSD on a Soekris > net5501 box. But i must use -engine cryptodev, why ? This is ok, as you may not want to use it, right? > $ openssl speed -evp aes-128-cbc -engine cryptodev -elapsed > engine "cryptodev" set. > ...CUT... > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > aes-128-cbc 1151.08k 4134.25k 11936.49k 22504.83k 25576.36k > > When i test ssh -c aes128-cbc hostname, ssh does not use the crypto > device. I receive a crypto_newsession() followed by a > crypto_freesession(), i mean i don't receive any crypto_process(). Have you tried to put some debug to opencrypto? I believe openssh should use it automatically, at least this was the case some time ago, AFAIR. > So how can I be sure that the datas are well encrypted ? Try comparing result of openssl encryption with and without '-engine cryptodev'. Remember to use -nosalt (and maybe -raw) prevent openssl from putting salt in front of the ciphertext. > Also, I've got some questions to finish the driver: > > - between arc4rand() and read_random(), witch function shall i use ? arc4rand() is preferred. > - Shall I lock the sessions ? The padlock driver uses a mutex to lock > the sessions > http://fxr.watson.org/fxr/source/crypto/via/padlock.c?v=FREEBSD7#L211 > > Is it usefull ? Drivers ubsec, safe and hifn don't lock the sessions at > all. You should and they should as well. > - during crypto_process() the driver uses "s = splnet();". I'm not sure > about this ? Drop this one. > - The driver does a busy wait to check the completion of the > encryption. I think it would be beter to use the interrupt. I will > look later. I remember looking at that code sometime ago and that bit is really lame, so lame that I think they would do it in a different way if that was possible. Maybe it's worth contacting OpenBSD/NetBSD and ask? There might be a good reason for that. > - Any comment is welcome, this is my first work on a driver. Looks good:) I can do a final review and commit once you are done and if I'll be able to start my Soekris and test it. -- 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-hackers/attachments/20080607/a8e8bee8/attachment.pgp From pjd at FreeBSD.org Sat Jun 7 06:05:27 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Sat Jun 7 06:05:31 2008 Subject: Is there any way to increase the KVM? In-Reply-To: References: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> <20080603135308.GC3434@garage.freebsd.pl> <6a7033710806032317g4dbe8845h26a1196016b9c440@mail.gmail.com> <86zlq140x0.fsf@ds4.des.no> <6a7033710806041053g4a5c2fdftd7202b708bff363c@mail.gmail.com> <20080605062728.GA4278@garage.freebsd.pl> Message-ID: <20080607060521.GB3462@garage.freebsd.pl> On Thu, Jun 05, 2008 at 04:00:13PM +0200, Ivan Voras wrote: > Pawel Jakub Dawidek wrote: > > > If we're comparing who has bigger... :) > > > > beast:root:~# zpool list > > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > > tank 732G 604G 128G 82% ONLINE - > > > > but: > > > > beast:root:~# zfs list | wc -l > > 1932 > > > > No panics. > > > > PS. I'm quite sure the ZFS version I've in perforce will fix most if not > > all 'kmem_map too small' panics. It's not yet committed, but I do want > > to MFC it into RELENG_7. > > At the risk of sounding repetitive, can you try a simple test on your > ZFS pools, to see if you can panic the kernel? Do this: > > * install blogbench and bonnie++ from ports/benchmarks > * run: > blogbench -c 100 -d . -i 30 -r 50 -W 10 -w 10 > bonnie++ -d . -s 16G -n 80 > in parallel, until completion or crash. It shouldn't take too long to > complete the above benchmarks, so you probably won't invest too much > time in it even if it doesn't crash. Both completed successfully (i386, 1GB of RAM, dual core CPU). Can you now go and revert all the FUD you spread? You probably need to invest much more time than that. -- 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-hackers/attachments/20080607/51ca1efc/attachment.pgp From kris at FreeBSD.org Sat Jun 7 08:18:06 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Sat Jun 7 08:18:09 2008 Subject: CFT: CVSMode for csup with MD5 check In-Reply-To: <20080531143655.GA14020@nobby.studby.ntnu.no> References: <20080531143655.GA14020@nobby.studby.ntnu.no> Message-ID: <484A443D.8080900@FreeBSD.org> Ulf Lilleengen wrote: > Hello, > > As a followup to my previous patch on csup, I've tried to do some fixes to > RCS-files. However, instead of doing major workarounds in csup to handle > files which does not behave correctly to RCS, I implemented MD5 check of RCS > content. This means that the MD5 sum from cvsupd is checked against the > actual RCS content (which is different from a normal MD5 check, because > only the content is compared), and if it's not correct, a fixup of the file > will be sent, thus making sure that the contents are correct. I hope some of > you are able to test this. > > There are still a few issues with cvsmode: > - Not correct entries in status file. > - I get unnatural high memory usage. > > Patches here: > http://people.freebsd.org/~lulf/patches/csup/csup_2008-05-31_CURRENT.diff > and > http://people.freebsd.org/~lulf/patches/csup/csup_2008-05-31_RELENG_7.diff > This doesn't compile. There are a bunch of warnings, and rcsfile.c is missing from Makefile, but there is an undefined reference: rcsfile.o(.text+0x1d32): In function `rcsfile_frompath': : undefined reference to `rcsparse_run' *** Error code 1 Kris From ivoras at freebsd.org Sat Jun 7 10:03:47 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Sat Jun 7 10:03:52 2008 Subject: Is there any way to increase the KVM? In-Reply-To: <20080607060521.GB3462@garage.freebsd.pl> References: <6a7033710805302252v43a7b240x66ca3f5e3dd5fda4@mail.gmail.com> <20080603135308.GC3434@garage.freebsd.pl> <6a7033710806032317g4dbe8845h26a1196016b9c440@mail.gmail.com> <86zlq140x0.fsf@ds4.des.no> <6a7033710806041053g4a5c2fdftd7202b708bff363c@mail.gmail.com> <20080605062728.GA4278@garage.freebsd.pl> <20080607060521.GB3462@garage.freebsd.pl> Message-ID: Pawel Jakub Dawidek wrote: > On Thu, Jun 05, 2008 at 04:00:13PM +0200, Ivan Voras wrote: >> At the risk of sounding repetitive, can you try a simple test on your >> ZFS pools, to see if you can panic the kernel? Do this: >> >> * install blogbench and bonnie++ from ports/benchmarks >> * run: >> blogbench -c 100 -d . -i 30 -r 50 -W 10 -w 10 >> bonnie++ -d . -s 16G -n 80 >> in parallel, until completion or crash. It shouldn't take too long to >> complete the above benchmarks, so you probably won't invest too much >> time in it even if it doesn't crash. > > Both completed successfully (i386, 1GB of RAM, dual core CPU). Perfect! > Can you now go and revert all the FUD you spread? You probably need to > invest much more time than that. Right, I'm just an evil guy trying to badmouth the system that's a large chunk of my bread and butter because I'm bored. :) What should I say, "sorry for posting bug reports?" and "sorry for writing docs on which features of (current) ZFS to avoid to sidestep crashes?" Actually I have a suspicion it's the second one (in ZFS wiki pages) you'd like cleared up, but keep in mind you were off the lists for a time and you are the principal source of information on our ZFS implementation. At the time there was a lot of incorrect information floating about in the mailing lists, where people (me included) were doing voodoo computing - trying every knob there was to see if it made a difference - and I tried to document whatever seemed to work to avoid answering repetitive questions posted on the lists. I will be among the first to try the new patches (depending on the time zone, probably, and we're pretty close there) and, unfortunately, I will complain and ask guidance if things don't work. On the other hand, if they do work, I'll a) add big honking banners with bells and whistles proclaiming that it finally works in (HEAD | RELENG_7), optionally praising you to heaven for bringing it to completion[*], and b) buy you a BIGNUM of beers next time we meet. [*] really, no sarcasm intended. It *was* an enormous job and if it works, you'd earn it! In the time I spent trying to make it work I saw from first-hand experience how great the whole idea of ZFS is and how useful it is in daily operation. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080607/c58690e4/signature.pgp From lulf at stud.ntnu.no Sat Jun 7 11:18:48 2008 From: lulf at stud.ntnu.no (Ulf Lilleengen) Date: Sat Jun 7 11:18:50 2008 Subject: CFT: CVSMode for csup with MD5 check In-Reply-To: <484A443D.8080900@FreeBSD.org> References: <20080531143655.GA14020@nobby.studby.ntnu.no> <484A443D.8080900@FreeBSD.org> Message-ID: <20080607111837.GA1840@carrot.studby.ntnu.no> On l?r, jun 07, 2008 at 10:18:05am +0200, Kris Kennaway wrote: > Ulf Lilleengen wrote: > > Hello, > > > > As a followup to my previous patch on csup, I've tried to do some fixes to > > RCS-files. However, instead of doing major workarounds in csup to handle > > files which does not behave correctly to RCS, I implemented MD5 check of RCS > > content. This means that the MD5 sum from cvsupd is checked against the > > actual RCS content (which is different from a normal MD5 check, because > > only the content is compared), and if it's not correct, a fixup of the file > > will be sent, thus making sure that the contents are correct. I hope some of > > you are able to test this. > > > > There are still a few issues with cvsmode: > > - Not correct entries in status file. > > - I get unnatural high memory usage. > > > > Patches here: > > http://people.freebsd.org/~lulf/patches/csup/csup_2008-05-31_CURRENT.diff > > and > > http://people.freebsd.org/~lulf/patches/csup/csup_2008-05-31_RELENG_7.diff > > > > This doesn't compile. There are a bunch of warnings, and rcsfile.c is > missing from Makefile, but there is an undefined reference: > > rcsfile.o(.text+0x1d32): In function `rcsfile_frompath': > : undefined reference to `rcsparse_run' > *** Error code 1 > Sorry, I probably didn't test the patch correctly. These patches now works for me on a 7.0 and CURRENT tree at least: http://people.freebsd.org/~lulf/patches/csup/csup_2008-06-07_RELENG_7.diff http://people.freebsd.org/~lulf/patches/csup/csup_2008-06-07_CURRENT.diff -- Ulf Lilleengen From simon at FreeBSD.org Sat Jun 7 12:55:21 2008 From: simon at FreeBSD.org (Simon L. Nielsen) Date: Sat Jun 7 12:55:25 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <20080607041855.GA3462@garage.freebsd.pl> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080607041855.GA3462@garage.freebsd.pl> Message-ID: <20080607125623.GB979@zaphod.nitro.dk> On 2008.06.07 06:18:55 +0200, Pawel Jakub Dawidek wrote: > On Fri, Jun 06, 2008 at 11:41:35PM +0200, Patrick Lamaizi?re wrote: > > - How check the encryption/decryption ? > > > > Openssl seems ok, i've got quite the same results as NetBSD on a Soekris > > net5501 box. But i must use -engine cryptodev, why ? > > This is ok, as you may not want to use it, right? > > > $ openssl speed -evp aes-128-cbc -engine cryptodev -elapsed > > engine "cryptodev" set. > > ...CUT... > > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > > aes-128-cbc 1151.08k 4134.25k 11936.49k 22504.83k 25576.36k > > > > When i test ssh -c aes128-cbc hostname, ssh does not use the crypto > > device. I receive a crypto_newsession() followed by a > > crypto_freesession(), i mean i don't receive any crypto_process(). > > Have you tried to put some debug to opencrypto? I believe openssh should > use it automatically, at least this was the case some time ago, AFAIR. OpenSSL 0.9.7 (in FreeBSD 6 and older) enabled it by default. After the OpenSSL 0.9.8 import it was not enabled automatically anymore. I have yet to figure out why this changed. sam@ made a patch to enable it always but I was not entirely sure it was the correct way to do it so I haven't committed it. You can enable it per application in the openssl config file, if the application calls the correct openssl config init function, which OpenSSL AFAIR does not. I will try to look more into this, but no promises as to when I will get to it. If anyone can make / get a patch which is OK'ed by the OpenSSL people I will be more than happy to commit it. BTW. I think phk@ already worked on a patch for AES in the AMD Geode LX, but I can't remember details or have time to look it up right now. -- Simon L. Nielsen Hat: FreeBSD OpenSSL janitor From simon at FreeBSD.org Sat Jun 7 12:59:34 2008 From: simon at FreeBSD.org (Simon L. Nielsen) Date: Sat Jun 7 12:59:37 2008 Subject: openssl with zlib support In-Reply-To: <20080606185442.O7163@mignon.ki.iif.hu> References: <20080606185442.O7163@mignon.ki.iif.hu> Message-ID: <20080607124420.GA979@zaphod.nitro.dk> On 2008.06.06 19:02:36 +0200, Mohacsi Janos wrote: > Dear All, > Are there any reason to not enabling zlib compression for TLS in openssl > on FreeBSD ? No, that seems like a mistake. Which FreeBSD version are you using, and are you using OpenSSL from base or ports? > Would it break ABI if I enable it by tweaking the openssl Makefile? Probably not, but I'm not sure where it's enabled/disabled so I can't say for sure. I will try to look into this more, but it might not be until sometime next week. -- Simon L. Nielsen From chuckr at telenix.org Sat Jun 7 17:27:54 2008 From: chuckr at telenix.org (Chuck Robey) Date: Sat Jun 7 17:27:59 2008 Subject: number of /dev/usb nodes Message-ID: <484AC2F1.1000806@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I can't seem to find how many /dev/usbN bus devices there can be. I'm writing some code that scans them all looking for anything that has my device, but I while I know to start at usb0, just how high do I go? There seem to be 128 device minors, is that the number? (from dev/usb/usb.h) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFISsLxz62J6PPcoOkRAtSTAKCFC8NueSSuJ0yZcVNwdjQie3SZJgCfb0bL AMAwFSbFBySoSVCfqc7R0+M= =MwIo -----END PGP SIGNATURE----- From jeremie at le-hen.org Sat Jun 7 21:52:19 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Sat Jun 7 21:52:24 2008 Subject: network bitrate of a poll of processes In-Reply-To: <3e473cc60805260752o2f573cf2h12910a45cf6849e6@mail.gmail.com> References: <3e473cc60805260752o2f573cf2h12910a45cf6849e6@mail.gmail.com> Message-ID: <20080607212920.GN13704@obiwan.tataz.chchile.org> Hi Mathieu, On Mon, May 26, 2008 at 04:52:04PM +0200, Mathieu Prevot wrote: > I would like to know the bitrate of a pool of child processes that use > a network connection, how can I have something like netstat -w1 > provide but at the process level ? One way to do it is to create a dynamic library providing a wrapper for read/write/send/recv/whichever syscalls that counts the number of bytes. Use gettimeofday(2) in a construtor and destructor to print the average bitrage. At runtime, load the shared library with LD_PRELOAD. If you want real time bitrate, I think you need an external device or you may spoil the results. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From alc at cs.rice.edu Sun Jun 8 00:25:45 2008 From: alc at cs.rice.edu (Alan Cox) Date: Sun Jun 8 00:25:50 2008 Subject: Increasing KVM on amd64 Message-ID: <484B20E7.2040009@cs.rice.edu> You can download a patch from http://www.cs.rice.edu/~alc/amd64_kvm_6GB.patch that increases amd64's kernel virtual address space to 6GB. This patch also increases the default for the kmem map to almost 2GB. I believe that kernel loadable modules still work. However, I suspect that mini-dumps are broken. I don't plan on committing this patch in its current form. Some of the changes are done in a hackish way. I am, however, curious to hear whether or not it works for you. Alan From tzhuan at csie.org Sun Jun 8 04:59:25 2008 From: tzhuan at csie.org (Tz-Huan Huang) Date: Sun Jun 8 04:59:27 2008 Subject: Increasing KVM on amd64 In-Reply-To: <484B20E7.2040009@cs.rice.edu> References: <484B20E7.2040009@cs.rice.edu> Message-ID: <6a7033710806072132i5abe2368h3db3ba269951fac5@mail.gmail.com> On Sun, Jun 8, 2008 at 7:59 AM, Alan Cox wrote: > You can download a patch from > http://www.cs.rice.edu/~alc/amd64_kvm_6GB.patch that increases amd64's > kernel virtual address space to 6GB. This patch also increases the default > for the kmem map to almost 2GB. I believe that kernel loadable modules > still work. However, I suspect that mini-dumps are broken. > > I don't plan on committing this patch in its current form. Some of the > changes are done in a hackish way. I am, however, curious to hear whether > or not it works for you. Thanks for the patch. I applied it on 7-stable but got failed on pmap.c. Patching file amd64/amd64/pmap.c using Plan A... Hunk #1 succeeded at 429 (offset -12 lines). Hunk #2 failed at 442. Hunk #3 succeeded at 1505 (offset -168 lines). Hunk #4 succeeded at 1691 (offset -12 lines). amd64/amd64/pmap.c.rej: *************** *** 442,456 **** /* Map from zero to end of allocations under 2M pages */ /* This replaces some of the KPTphys entries above */ for (i = 0; (i << PDRSHIFT) < *firstaddr; i++) { - ((pd_entry_t *)KPDphys)[i] = i << PDRSHIFT; - ((pd_entry_t *)KPDphys)[i] |= PG_RW | PG_V | PG_PS | PG_G; } /* And connect up the PD to the PDP */ for (i = 0; i < NKPDPE; i++) { - ((pdp_entry_t *)KPDPphys)[i + KPDPI] = KPDphys + (i << PAGE_SHIFT); - ((pdp_entry_t *)KPDPphys)[i + KPDPI] |= PG_RW | PG_V | PG_U; } /* Now set up the direct map space using either 2MB or 1GB pages */ --- 442,456 ---- /* Map from zero to end of allocations under 2M pages */ /* This replaces some of the KPTphys entries above */ for (i = 0; (i << PDRSHIFT) < *firstaddr; i++) { + ((pd_entry_t *)KPDphys)[2048 + i] = i << PDRSHIFT; + ((pd_entry_t *)KPDphys)[2048 + i] |= PG_RW | PG_V | PG_PS | PG_G; } /* And connect up the PD to the PDP */ for (i = 0; i < NKPDPE; i++) { + ((pdp_entry_t *)KPDPphys)[i + KPDPI - 4] = KPDphys + (i << PAGE_SHIFT); + ((pdp_entry_t *)KPDPphys)[i + KPDPI - 4] |= PG_RW | PG_V | PG_U; } /* Now set up the direct map space using either 2MB or 1GB pages */ We have no machine running 8-current with more than 6G memory now... Thanks, Tz-Huan From jason.harmening at gmail.com Sun Jun 8 05:03:32 2008 From: jason.harmening at gmail.com (Jason Harmening) Date: Sun Jun 8 05:39:01 2008 Subject: bus_dmamem_alloc Message-ID: <200806072341.17041.jason.harmening@gmail.com> Hello, I've written a FreeBSD driver for Conexant CX2388x-based PCI TV capture cards. Of course the driver uses busdma to be as machine-independent as possible. One problem I've encountered is that bus_dmamem_alloc is inadequate for my needs. The CX2388x only understands 32-bit physical addreses, and the driver has two separate use cases for busdma: 1) Data buffers: These buffers may be relatively large (a 640x480 RGB32 video frame is ~1.2M), and therefore it is desirable that these buffers not be physically contiguous. 2) DMA program buffers: The DMA engine on the CX2388x is controlled by special-purpose RISC instructions, usually stored in host memory, that provide information on, among other things, the physical layout of the data buffers, which enables handling of non-contiguous data buffers. These programs are rarely more than a few pages in size, so for the sake of simplicity it is desirable that DMA program buffers be physically contiguous. For case 1), I malloc(9) the buffers and then feed them to busdma, since on most machines bus_dmamem_alloc just calls contigmalloc. Use of malloc(9) is suboptimal as it may result in bounce buffering for non-IOMMU machines with large amounts of RAM. For case 2), I contigmalloc the DMA program buffers in the 32-bit physical address range and then feed them to busdma. I don't use bus_dmamem_alloc here because it always allocates the maximum size specified in the bus_dma_tag_t. Since the driver supports dynamic data buffer allocation and DMA program generation, DMA program sizes may vary significantly. I therefore just create the bus_dma_tag_t with the maximum possible size for a DMA program buffer since I'd prefer not to have to re-create the tag every time the DMA program size changes. But always allocating the maximum buffer size would be a huge waste of contiguous memory, so bus_dmamem_alloc is out of the question here too. At the same time, use of contigmalloc is suboptimal as it may not be necessary to restrict the allocation to 32-bit physical addresses on IOMMU-equipped machines. This is something that bus_dmamem_alloc could take care of, if only it supported a size parameter (as I believe the NetBSD version does). So I have 3 questions: 1) Would it be possible to provide a bus_dmamem_alloc overload that takes a size parameter? We could call it bus_dmamem_alloc_size and have bus_dmamem_alloc just call bus_dmamem_alloc_size with dmat->maxsize to preserve source-level compatibility with existing drivers. 2) Are there currently any serious plans to have bus_dmamem_alloc perform multi-segment allocations on non-IOMMU machines? It looks like NetBSD does this by reserving the physical segments and then stitching them together into a virtually contiguous range. Is something like this feasible for FreeBSD? 3) Are there currently any serious plans to support IOMMUs on anything besides Sun machines? The AMD AGP GART, PowerPC 970 DART, and Intel VT-d and AMD IOMMU all come to mind. If any of these ideas sound feasible, I'd be more than willing to help research/implement/test them. Thanks, Jason From alc at cs.rice.edu Sun Jun 8 05:39:52 2008 From: alc at cs.rice.edu (Alan Cox) Date: Sun Jun 8 05:39:56 2008 Subject: Increasing KVM on amd64 In-Reply-To: <20080608052653.GS94309@deviant.kiev.zoral.com.ua> References: <484B20E7.2040009@cs.rice.edu> <20080608052653.GS94309@deviant.kiev.zoral.com.ua> Message-ID: <484B709F.1070503@cs.rice.edu> Kostik Belousov wrote: >On Sat, Jun 07, 2008 at 06:59:35PM -0500, Alan Cox wrote: > > >>You can download a patch from >>http://www.cs.rice.edu/~alc/amd64_kvm_6GB.patch that increases amd64's >>kernel virtual address space to 6GB. This patch also increases the >>default for the kmem map to almost 2GB. I believe that kernel loadable >>modules still work. However, I suspect that mini-dumps are broken. >> >> >The amd64 modules text/data/bss virtual addresses are allocated from the >kernel_map (link_elf_obj.c, link_elf_load_file). Now, the lower end >of the kernel_map is top-6Gb. > >Kernel code (both kernel proper and modules) is compiled for "kernel memory >model", according to the gcc info: >`-mcmodel=kernel' >Generate code for the kernel code model. The kernel runs in the >negative 2 GB of the address space. This model has to be used for >Linux kernel code. > >I suspect we have a problem there. > > > The change to link_elf_obj.c is supposed to ensure allocation of an address in the upper 2GB of the kernel map for the module. Alan From kostikbel at gmail.com Sun Jun 8 05:51:43 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Jun 8 05:51:47 2008 Subject: Increasing KVM on amd64 In-Reply-To: <484B709F.1070503@cs.rice.edu> References: <484B20E7.2040009@cs.rice.edu> <20080608052653.GS94309@deviant.kiev.zoral.com.ua> <484B709F.1070503@cs.rice.edu> Message-ID: <20080608055136.GT94309@deviant.kiev.zoral.com.ua> On Sun, Jun 08, 2008 at 12:39:43AM -0500, Alan Cox wrote: > Kostik Belousov wrote: > > >On Sat, Jun 07, 2008 at 06:59:35PM -0500, Alan Cox wrote: > > > > > >>You can download a patch from > >>http://www.cs.rice.edu/~alc/amd64_kvm_6GB.patch that increases amd64's > >>kernel virtual address space to 6GB. This patch also increases the > >>default for the kmem map to almost 2GB. I believe that kernel loadable > >>modules still work. However, I suspect that mini-dumps are broken. > >> > >> > >The amd64 modules text/data/bss virtual addresses are allocated from the > >kernel_map (link_elf_obj.c, link_elf_load_file). Now, the lower end > >of the kernel_map is top-6Gb. > > > >Kernel code (both kernel proper and modules) is compiled for "kernel memory > >model", according to the gcc info: > >`-mcmodel=kernel' > >Generate code for the kernel code model. The kernel runs in the > >negative 2 GB of the address space. This model has to be used for > >Linux kernel code. > > > >I suspect we have a problem there. > > > > > > > > The change to link_elf_obj.c is supposed to ensure allocation of an > address in the upper 2GB of the kernel map for the module. Ah, I overlooked it, sorry. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080608/5ed5dc83/attachment.pgp From kostikbel at gmail.com Sun Jun 8 05:58:41 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Jun 8 05:58:44 2008 Subject: Increasing KVM on amd64 In-Reply-To: <484B20E7.2040009@cs.rice.edu> References: <484B20E7.2040009@cs.rice.edu> Message-ID: <20080608052653.GS94309@deviant.kiev.zoral.com.ua> On Sat, Jun 07, 2008 at 06:59:35PM -0500, Alan Cox wrote: > You can download a patch from > http://www.cs.rice.edu/~alc/amd64_kvm_6GB.patch that increases amd64's > kernel virtual address space to 6GB. This patch also increases the > default for the kmem map to almost 2GB. I believe that kernel loadable > modules still work. However, I suspect that mini-dumps are broken. The amd64 modules text/data/bss virtual addresses are allocated from the kernel_map (link_elf_obj.c, link_elf_load_file). Now, the lower end of the kernel_map is top-6Gb. Kernel code (both kernel proper and modules) is compiled for "kernel memory model", according to the gcc info: `-mcmodel=kernel' Generate code for the kernel code model. The kernel runs in the negative 2 GB of the address space. This model has to be used for Linux kernel code. I suspect we have a problem there. > > I don't plan on committing this patch in its current form. Some of the > changes are done in a hackish way. I am, however, curious to hear > whether or not it works for you. > > Alan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080608/696757af/attachment.pgp From alc at cs.rice.edu Sun Jun 8 06:02:35 2008 From: alc at cs.rice.edu (Alan Cox) Date: Sun Jun 8 06:02:39 2008 Subject: Increasing KVM on amd64 In-Reply-To: <6a7033710806072132i5abe2368h3db3ba269951fac5@mail.gmail.com> References: <484B20E7.2040009@cs.rice.edu> <6a7033710806072132i5abe2368h3db3ba269951fac5@mail.gmail.com> Message-ID: <484B75F1.6010505@cs.rice.edu> Tz-Huan Huang wrote: >On Sun, Jun 8, 2008 at 7:59 AM, Alan Cox wrote: > > >>You can download a patch from >>http://www.cs.rice.edu/~alc/amd64_kvm_6GB.patch that increases amd64's >>kernel virtual address space to 6GB. This patch also increases the default >>for the kmem map to almost 2GB. I believe that kernel loadable modules >>still work. However, I suspect that mini-dumps are broken. >> >>I don't plan on committing this patch in its current form. Some of the >>changes are done in a hackish way. I am, however, curious to hear whether >>or not it works for you. >> >> > >Thanks for the patch. I applied it on 7-stable but got failed on pmap.c. > > > [snip] >We have no machine running 8-current with more than 6G memory now... > > > Sorry, at this point the patch is only applicable to HEAD. That said, the failed chunk is probably easily applied by hand to RELENG_7. Thanks, Alan From tzhuan at csie.org Sun Jun 8 08:56:39 2008 From: tzhuan at csie.org (Tz-Huan Huang) Date: Sun Jun 8 08:56:43 2008 Subject: Increasing KVM on amd64 In-Reply-To: <484B75F1.6010505@cs.rice.edu> References: <484B20E7.2040009@cs.rice.edu> <6a7033710806072132i5abe2368h3db3ba269951fac5@mail.gmail.com> <484B75F1.6010505@cs.rice.edu> Message-ID: <6a7033710806080156o76fb38cfsdf5dc0554105d50b@mail.gmail.com> On Sun, Jun 8, 2008 at 2:02 PM, Alan Cox wrote: > Tz-Huan Huang wrote: > >> On Sun, Jun 8, 2008 at 7:59 AM, Alan Cox wrote: >> >>> >>> You can download a patch from >>> http://www.cs.rice.edu/~alc/amd64_kvm_6GB.patch that increases amd64's >>> kernel virtual address space to 6GB. This patch also increases the >>> default >>> for the kmem map to almost 2GB. I believe that kernel loadable modules >>> still work. However, I suspect that mini-dumps are broken. >>> >>> I don't plan on committing this patch in its current form. Some of the >>> changes are done in a hackish way. I am, however, curious to hear >>> whether >>> or not it works for you. >> >> Thanks for the patch. I applied it on 7-stable but got failed on pmap.c. > > [snip] > >> We have no machine running 8-current with more than 6G memory now... > > Sorry, at this point the patch is only applicable to HEAD. That said, the > failed chunk is probably easily applied by hand to RELENG_7. Ok, I applied the patch and fixed the failed chunk by hand. I also modified the type of vm_kmem_size from u_int to u_long. Here is the diff: http://w.csie.org/~tzhuan/tmp/vm_kmem_size.diff The patched kernel is compiled and boots without problem. I set the vm.kmem_size/vm.kmem_size_max to 3G and vfs.zfs.arc_max to 2G, everything looks fine. Some stress tests are running now, I'll report if any problem. Thanks, Tz-Huan From xorquewasp at googlemail.com Sun Jun 8 10:33:05 2008 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sun Jun 8 10:33:10 2008 Subject: ntpd jail problem Message-ID: <20080608103254.GA99569@logik.internal.network> Anybody know why ntpd might not work in a jail? I'm running an openntpd instance on the host machine, which syncs the clock from the pool at pool.ntp.org. From the log output, ntpd claims to be synced and the time does seem to be correct. I'm then running another openntpd in a jail which doesn't set the time, just serves it to clients. Something appears to be wrong, however. Any client that tries to get the time from the jailed openntpd simply says: $ sudo /usr/local/sbin/ntpd -ds listening on 127.0.0.1 ntp engine ready reply from 192.168.3.21: not synced, next query 615s The ntpd *never* appears to sync. Am I doing something fundamentally wrong, here? Is there some problem with jailed openntpd (that doesn't attempt to set the time) that I'm not aware of? Any help would be appreciated. From ndenev at gmail.com Sun Jun 8 07:49:54 2008 From: ndenev at gmail.com (Niki Denev) Date: Sun Jun 8 11:10:20 2008 Subject: timestamping for kernel messages (like Solaris and Linux) Message-ID: <2e77fc10806080024s19951abbnf31913d5579f4535@mail.gmail.com> Hi, Has anyone thought about implementing an option to prepend all kernel console messages with timestamps, like Linux and Solaris do? Is it just a matter of hacking up the kernel printf() implementation? Any possible caveats? Regards, Niki From xorquewasp at googlemail.com Sun Jun 8 11:25:08 2008 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sun Jun 8 11:25:12 2008 Subject: ntpd jail problem In-Reply-To: <4D5B525988E448B4BB66F447AE53347A@multiplay.co.uk> References: <20080608103254.GA99569@logik.internal.network> <4D5B525988E448B4BB66F447AE53347A@multiplay.co.uk> Message-ID: <20080608112500.GA16328@logik.internal.network> On 20080608 12:19:23, Steven Hartland wrote: > I assume as it would effect the entire machine and hence should be run > on the base machine instead, not the jail? I think you might've misunderstood. The ntpd I'm running on the host syncs the clock (and therefore the whole machine), the ntpd in the jail just publishes the time for the network (doesn't affect the clock). The problem is that the ntpd in the jail seems to believe that the host clock is out of sync (from what I can gather), even though it isn't. From killing at multiplay.co.uk Sun Jun 8 11:31:13 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Sun Jun 8 11:31:17 2008 Subject: ntpd jail problem References: <20080608103254.GA99569@logik.internal.network> Message-ID: <4D5B525988E448B4BB66F447AE53347A@multiplay.co.uk> I assume as it would effect the entire machine and hence should be run on the base machine instead, not the jail? ----- Original Message ----- From: > Anybody know why ntpd might not work in a jail? ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From patfbsd at davenulle.org Sun Jun 8 11:58:50 2008 From: patfbsd at davenulle.org (Patrick Lamaiziere) Date: Sun Jun 8 11:58:56 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <20080607041855.GA3462@garage.freebsd.pl> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080607041855.GA3462@garage.freebsd.pl> Message-ID: <20080608135846.45799105@baby-jane-lamaiziere-net.local> Le Sat, 7 Jun 2008 06:18:55 +0200, Pawel Jakub Dawidek a ?crit : > > Well, it seems to work but i've got few problems to test the > > module : > > > > - How check the encryption/decryption ? > > > > Openssl seems ok, i've got quite the same results as NetBSD on a > > Soekris net5501 box. But i must use -engine cryptodev, why ? > > This is ok, as you may not want to use it, right? I think it should be automatic with an option to not use it. Simon replied for this problem. > Try comparing result of openssl encryption with and without '-engine > cryptodev'. Remember to use -nosalt (and maybe -raw) prevent openssl > from putting salt in front of the ciphertext. Thank you. I checked the encryption with and without 'engine cryptodev'. It works \o/ $ openssl enc -e -aes-128-cbc -in file -out file.enc -nosalt -k abcdefhij $ openssl enc -d -aes-128-cbc -in file.enc -out file.dec -nosalt -k abcdefhij $ md5 file file.dec Time to encode a 300 MB file soft : 1m29.72s real, 1m8.74s user, 8.68s sys hard : 42.98s real, 1.80s user, 22.94s sys > > - The driver does a busy wait to check the completion of the > > encryption. I think it would be beter to use the interrupt. I will > > look later. > > I remember looking at that code sometime ago and that bit is really > lame, so lame that I think they would do it in a different way if that > was possible. Maybe it's worth contacting OpenBSD/NetBSD and ask? > There might be a good reason for that. Yes it seems strange, i've sent a mail to the author about this. I've looked the Linux version of the driver and they use a busy wait too. [CUT] > > - Any comment is welcome, this is my first work on a driver. > > Looks good:) I can do a final review and commit once you are done and > if I'll be able to start my Soekris and test it. Thanks. I think it is ok for a review and test, i added the RNG stuff since the last time and a manual page 'glxsb.4' http://user.lamaiziere.net/patrick/glxsb.c http://user.lamaiziere.net/patrick/glxsb.tar.gz (all the module) Regards. From peterjeremy at optushome.com.au Sun Jun 8 11:59:23 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sun Jun 8 11:59:26 2008 Subject: timestamping for kernel messages (like Solaris and Linux) In-Reply-To: <2e77fc10806080024s19951abbnf31913d5579f4535@mail.gmail.com> References: <2e77fc10806080024s19951abbnf31913d5579f4535@mail.gmail.com> Message-ID: <20080608115919.GE67629@server.vk2pj.dyndns.org> On 2008-Jun-08 10:24:53 +0300, Niki Denev wrote: >Has anyone thought about implementing an option >to prepend all kernel console messages with timestamps, >like Linux and Solaris do? The only time I've seen Solaris do this is when the console message is syslog'd - which FreeBSD also does. >Is it just a matter of hacking up the kernel printf() implementation? Pretty much. >Any possible caveats? The kernel works in UTC only and has only a very restricted ability to translate between epoch seconds and a human-readable date/time (it's currently only used to talk to the RTC). -- 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-hackers/attachments/20080608/fa46fa52/attachment.pgp From peterjeremy at optushome.com.au Sun Jun 8 12:10:31 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sun Jun 8 12:10:34 2008 Subject: ntpd jail problem In-Reply-To: <20080608103254.GA99569@logik.internal.network> References: <20080608103254.GA99569@logik.internal.network> Message-ID: <20080608121027.GF67629@server.vk2pj.dyndns.org> On 2008-Jun-08 11:32:54 +0100, xorquewasp@googlemail.com wrote: >I'm running an openntpd instance on the host machine, which syncs the >clock from the pool at pool.ntp.org. From the log output, ntpd claims to >be synced and the time does seem to be correct. > >I'm then running another openntpd in a jail which doesn't set the time, >just serves it to clients. I've never used openntpd but for the base ntpd, you should be able to just use 'server 127.127.1.0' to make it trust (and not alter) the base system time. Note that this openntpd will not have access to the stratum information from the main ntpd but will have a fixed value and may need to be adjusted using a 'fudge' command (or equivalent). I'd be interested in knowing why you chose this approach rather than just syncing clients to the [open]ntpd instance in the host machine. -- 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-hackers/attachments/20080608/99bc301f/attachment.pgp From nike_d at cytexbg.com Sun Jun 8 12:13:19 2008 From: nike_d at cytexbg.com (Niki Denev) Date: Sun Jun 8 12:13:22 2008 Subject: timestamping for kernel messages (like Solaris and Linux) In-Reply-To: <20080608115919.GE67629@server.vk2pj.dyndns.org> References: <2e77fc10806080024s19951abbnf31913d5579f4535@mail.gmail.com> <20080608115919.GE67629@server.vk2pj.dyndns.org> Message-ID: <2e77fc10806080513wa73444ep50162e1d5f45f15@mail.gmail.com> On Sun, Jun 8, 2008 at 2:59 PM, Peter Jeremy wrote: > On 2008-Jun-08 10:24:53 +0300, Niki Denev wrote: >>Has anyone thought about implementing an option >>to prepend all kernel console messages with timestamps, >>like Linux and Solaris do? > > The only time I've seen Solaris do this is when the console message > is syslog'd - which FreeBSD also does. > >>Is it just a matter of hacking up the kernel printf() implementation? > > Pretty much. > >>Any possible caveats? > > The kernel works in UTC only and has only a very restricted ability > to translate between epoch seconds and a human-readable date/time > (it's currently only used to talk to the RTC). > I'm looking at a Linux machine right now, and it looks like they use the time since boot (actually uptime) for the timestamps. Anyways, does this sound like something that FreeBSD should have? It could be useful in some situations, like embedded applications without running syslog, full /var partitions, etc. -- Niki From xorquewasp at googlemail.com Sun Jun 8 12:14:54 2008 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sun Jun 8 12:14:57 2008 Subject: ntpd jail problem In-Reply-To: <20080608115603.GB23624@svzserv.kemerovo.su> References: <20080608103254.GA99569@logik.internal.network> <4D5B525988E448B4BB66F447AE53347A@multiplay.co.uk> <20080608112500.GA16328@logik.internal.network> <20080608115603.GB23624@svzserv.kemerovo.su> Message-ID: <20080608121446.GA83741@logik.internal.network> On 20080608 19:56:03, Eugene Grosbein wrote: > On Sun, Jun 08, 2008 at 12:25:00PM +0100, xorquewasp@googlemail.com wrote: > > > The problem is that the ntpd in the jail seems to believe that the host > > clock is out of sync (from what I can gather), even though it isn't. > > That's because ntpd won't blindly assume that your host has right time. > If you make client/server connection between your two copies of NTP daemons, > the server insures the client that time is right and client will serve > your network just right. > > Eugene Grosbein That would explain it... I'll make the adjustment now and see what happens. Thanks. From xorquewasp at googlemail.com Sun Jun 8 12:16:23 2008 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sun Jun 8 12:16:28 2008 Subject: ntpd jail problem In-Reply-To: <20080608121027.GF67629@server.vk2pj.dyndns.org> References: <20080608103254.GA99569@logik.internal.network> <20080608121027.GF67629@server.vk2pj.dyndns.org> Message-ID: <20080608121617.GB83741@logik.internal.network> On 20080608 22:10:27, Peter Jeremy wrote: > On 2008-Jun-08 11:32:54 +0100, xorquewasp@googlemail.com wrote: > >I'm running an openntpd instance on the host machine, which syncs the > >clock from the pool at pool.ntp.org. From the log output, ntpd claims to > >be synced and the time does seem to be correct. > > > >I'm then running another openntpd in a jail which doesn't set the time, > >just serves it to clients. > > I've never used openntpd but for the base ntpd, you should be able to > just use 'server 127.127.1.0' to make it trust (and not alter) the > base system time. Note that this openntpd will not have access to the > stratum information from the main ntpd but will have a fixed value and > may need to be adjusted using a 'fudge' command (or equivalent). Ok. Right. > I'd be interested in knowing why you chose this approach rather than > just syncing clients to the [open]ntpd instance in the host machine. Just basic paranoia really. Nothing on the host is network-visible, all the services are in jails. Thanks for the information. From eugen at kuzbass.ru Sun Jun 8 12:19:56 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sun Jun 8 12:25:20 2008 Subject: ntpd jail problem In-Reply-To: <20080608112500.GA16328@logik.internal.network> References: <20080608103254.GA99569@logik.internal.network> <4D5B525988E448B4BB66F447AE53347A@multiplay.co.uk> <20080608112500.GA16328@logik.internal.network> Message-ID: <20080608115603.GB23624@svzserv.kemerovo.su> On Sun, Jun 08, 2008 at 12:25:00PM +0100, xorquewasp@googlemail.com wrote: > The problem is that the ntpd in the jail seems to believe that the host > clock is out of sync (from what I can gather), even though it isn't. That's because ntpd won't blindly assume that your host has right time. If you make client/server connection between your two copies of NTP daemons, the server insures the client that time is right and client will serve your network just right. Eugene Grosbein From ticso at cicely7.cicely.de Sun Jun 8 13:42:39 2008 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Sun Jun 8 13:42:42 2008 Subject: number of /dev/usb nodes In-Reply-To: <484AC2F1.1000806@telenix.org> References: <484AC2F1.1000806@telenix.org> Message-ID: <20080608134227.GM71712@cicely7.cicely.de> On Sat, Jun 07, 2008 at 01:18:41PM -0400, Chuck Robey wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I can't seem to find how many /dev/usbN bus devices there can be. I'm writing > some code that scans them all looking for anything that has my device, but I > while I know to start at usb0, just how high do I go? There seem to be 128 > device minors, is that the number? (from dev/usb/usb.h) There shouldn't be a limit anymore. I can't see any definition of 128 in usb.h that limits the number of busses. The major/minor differenciation is long time ago. You must be looking at old code. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From chuckr at telenix.org Sun Jun 8 14:25:35 2008 From: chuckr at telenix.org (Chuck Robey) Date: Sun Jun 8 14:25:40 2008 Subject: number of /dev/usb nodes In-Reply-To: <20080608134227.GM71712@cicely7.cicely.de> References: <484AC2F1.1000806@telenix.org> <20080608134227.GM71712@cicely7.cicely.de> Message-ID: <484BE9BA.5040308@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bernd Walter wrote: > On Sat, Jun 07, 2008 at 01:18:41PM -0400, Chuck Robey wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I can't seem to find how many /dev/usbN bus devices there can be. I'm writing >> some code that scans them all looking for anything that has my device, but I >> while I know to start at usb0, just how high do I go? There seem to be 128 >> device minors, is that the number? (from dev/usb/usb.h) > > There shouldn't be a limit anymore. > I can't see any definition of 128 in usb.h that limits the number of > busses. > The major/minor differenciation is long time ago. > You must be looking at old code. > I was trying to find a good way to do scanning, whjen I create the files like /dev/usb0, how far to go in my loop? Does the lowest available device always get created? That would imply that as soon as I began to get "No such device" errors, I could stop iterating. If the rules for picking device filenames are pretty loose, then I could (for instance) stop scanning, say, 4 numbers past the first "No such device" returnee. Any idea on this? I didn't see this i nthe code, but I just need some sane limit on what filenames to scan about in. I look for item info, and if the usb vendor and prodict look friendly, I just snag the filename involved, and use that. Like, a scan of the usb1 bus might yield me a uhid0 which might be my meat, whereupon I coulld drop the usb1 open, and replace it with a uhid0 open. There's more than 1 place that my devices could show, depending on the user's kernel devices. I just want to have some sane limit on how many usb buses I open for my scanning. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIS+m6z62J6PPcoOkRAgBoAJ0XYYfUat/fJDChSybpNtFzCwUr9ACdGxNf UoCeHzvriXfQ+bj5LDxE8vA= =sTcT -----END PGP SIGNATURE----- From oranki at gmail.com Sun Jun 8 14:59:04 2008 From: oranki at gmail.com (=?UTF-8?Q?Atte_Peltom=C3=A4ki?=) Date: Sun Jun 8 15:03:31 2008 Subject: Kerberized CIFS client? In-Reply-To: <20080606191524.GQ56965@psu.edu> References: <20080521182722.GC40818@psu.edu> <483554FC.9040908@dlr.de> <20080603134307.GK76952@psu.edu> <20080603173601.W41705@beagle.kn.op.dlr.de> <20080603160608.GA56965@psu.edu> <20080606191524.GQ56965@psu.edu> Message-ID: smbclient (and other samba utilities) do not refer to krb5.conf when figuring out the kerberos realm. you will have to put to your krb5.conf on both client and server: [domain_realms] cifs.example.com = realm.example.com Otherwise it will just try to use example.com as the realm. On 6/6/08, Derek Taylor wrote: > On Tue, 03 Jun 2008, Atte Peltomki wrote: >>You will have to adjust your krb5.conf to map a given domain or hostname >>to a kerberos realm, if you are doing cross-realm authentication. See MIT >>kerberos admin guide for details. > > I'm pretty sure it's set up ok. I can use smbclient -k just fine: > $ kinit > det135@realm.example.com's Password: > kinit: NOTICE: ticket renewable lifetime is 1 week > $ klist > Credentials cache: FILE:/tmp/krb5cc_1001 > Principal: det135@realm.example.com > > Issued Expires Principal > Jun 6 15:08:47 Jun 7 01:08:47 krbtgt/realm.example.com@realm.example.com > $ smbclient -k -U det135 //cifs.example.com/dir1 > OS=[Unix] Server=[Samba 3.0.30] > smb: \> ls > . D 0 Thu Feb 14 14:46:42 2008 > .. D 0 Fri Jun 6 10:16:29 2008 > [ other files/directories here ] > > smb: \> quit > $ cd ~/mount/smbbeta.pass.psu.edu/pass > $ ls > ls: .: Permission denied > $ klist > Credentials cache: FILE:/tmp/krb5cc_1001 > Principal: det135@dce.psu.edu > > Issued Expires Principal > Jun 6 15:08:47 Jun 7 01:08:47 krbtgt/realm.example.com@realm.example.com > Jun 6 15:09:17 Jun 7 01:08:47 cifs/cifs.example.com@realm.example.com > $ > > -Derek. > >>On 6/3/08, Derek Taylor wrote: >>> On Tue, 03 Jun 2008, Harti Brandt wrote: >>>>On Tue, 3 Jun 2008, Derek Taylor wrote: >>>> >>>>DT>On Thu, 22 May 2008, Hartmut Brandt wrote: >>>>DT>>Derek Taylor wrote: >>>>DT>>> This question was previously posed of the freebsd-questions list, >>>> but >>>>DT>>> with no response for a week, I'd like to try my luck here. If >>>> there's >>>>DT>>> any more information I should include, please speak up: I would be >>>> glad >>>>DT>>> to oblige. >>>>DT>>> >>>>DT>>> I would like to use smb/cifs with kerberos auth, but mount_smbfs >>>> doesn't >>>>DT>>> seem to support this. >>>>DT>>> >>>>DT>>> Is anyone aware of an alternate means of performing a mount via >>>> smb/cifs >>>>DT>>> or any patches to provide such functionality? >>>>DT>>> >>>>DT>>> I already have smbclient working with -k, but I am also interested >>>> in >>>> a >>>>DT>>> mount. >>>>DT>> >>>>DT>>Try smbnetfs from ports. It's fuse based and seems to work very nice. >>>> If >>>>DT>>you have a large amount of shares floating in your network you want >>>> to >>>>DT>>restrict it to mount only the needed shares via the config file. >>>>DT>>Otherwise it will mount what it can find... >>>>DT>> >>>>DT>>It plays nicely with kerberors. When your ticket expires you >>>> immediately >>>>DT>>loose access; when you renew it you gain access again. All without >>>> the >>>>DT>>need to unmount/mount. Just call smbnetfs once you have your ticket. >>>> You >>>>DT>>may even do this from your .profile. >>>>DT>> >>>>DT>>harti >>>>DT> >>>>DT>Sorry for not replying sooner. >>>>DT> >>>>DT>Initial tests here are promising (I can see some mount paths being >>>>DT>exported from the server), but it's not fully working (I don't see all >>>>DT>of the mount paths that *should* be exported and I get permission >>>> denied >>>>DT>errors). My thoughts are leaning towards an issue in negotiating auth >>>>DT>with the server -- perhaps my krb creds aren't being used? >>>> >>>>You can test this easily: if your ticket expires you get permission >>>> denied >>>>errors when you try to look into the mounted directories. As soon as you >>>>renew the ticket you get access again. All without restarting smbnetfs. >>>> >>>>harti >>> >>> I replaced all server names below with "example.com" (and derivatives) >>> where appropriate: >>> >>> From my FreeBSD machine, using smbnetfs: >>> >>> $ klist >>> klist: No ticket file: /tmp/krb5cc_1001 >>> $ kinit det135 >>> det135@realm.example.com's Password: >>> kinit: NOTICE: ticket renewable lifetime is 1 week >>> $ klist >>> Credentials cache: FILE:/tmp/krb5cc_1001 >>> Principal: det135@realm.example.com >>> >>> Issued Expires Principal >>> Jun 3 11:51:20 Jun 3 21:51:04 >>> krbtgt/realm.example.com@realm.example.com >>> $ cd ~/mount/cifs.example.com/dir1 >>> $ ls >>> ls: .: Permission denied >>> $ cd .. >>> $ ls >>> dir1 dir2 >>> $ klist >>> Credentials cache: FILE:/tmp/krb5cc_1001 >>> Principal: det135@realm.example.com >>> >>> Issued Expires Principal >>> Jun 3 11:51:20 Jun 3 21:51:04 >>> krbtgt/realm.example.com@realm.example.com >>> >>> >>> From my Mac, using (from Finder) >>> Go -> Connect to Server -> cifs://cifs.example.com/dir1 >>> >>> $ klist >>> klist: No Kerberos 5 tickets in credentials cache >>> $ kinit det135 >>> Please enter the password for det135@realm.example.com: >>> $ klist >>> Kerberos 5 ticket cache: 'API:Initial default ccache' >>> Default principal: det135@realm.example.com >>> >>> Valid Starting Expires Service Principal >>> 06/03/08 11:59:41 06/03/08 21:59:41 >>> krbtgt/realm.example.com@realm.example.com >>> renew until 06/10/08 11:59:41 >>> >>> #### Here I mount via Finder before continuing with the commands below >>> >>> $ cd /Volumes/dir1/ >>> $ ls >>> subdir1 subdir2 file1 file2 >>> $ klist >>> Kerberos 5 ticket cache: 'API:Initial default ccache' >>> Default principal: det135@realm.example.com >>> >>> Valid Starting Expires Service Principal >>> 06/03/08 11:59:41 06/03/08 21:59:41 >>> krbtgt/realm.example.com@realm.example.com >>> renew until 06/10/08 11:59:41 >>> 06/03/08 12:00:31 06/03/08 21:59:41 >>> cifs/cifs.example.com@realm.example.com >>> renew until 06/10/08 11:59:41 >>> >>> >>> It looks like my creds aren't being used on the FreeBSD machine. >>> >>> -Derek. >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to >>> "freebsd-hackers-unsubscribe@freebsd.org" >>> >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From ticso at cicely7.cicely.de Sun Jun 8 15:50:28 2008 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Sun Jun 8 15:50:32 2008 Subject: number of /dev/usb nodes In-Reply-To: <484BE9BA.5040308@telenix.org> References: <484AC2F1.1000806@telenix.org> <20080608134227.GM71712@cicely7.cicely.de> <484BE9BA.5040308@telenix.org> Message-ID: <20080608155015.GO71712@cicely7.cicely.de> On Sun, Jun 08, 2008 at 10:16:26AM -0400, Chuck Robey wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Bernd Walter wrote: > > On Sat, Jun 07, 2008 at 01:18:41PM -0400, Chuck Robey wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> I can't seem to find how many /dev/usbN bus devices there can be. I'm writing > >> some code that scans them all looking for anything that has my device, but I > >> while I know to start at usb0, just how high do I go? There seem to be 128 > >> device minors, is that the number? (from dev/usb/usb.h) > > > > There shouldn't be a limit anymore. > > I can't see any definition of 128 in usb.h that limits the number of > > busses. > > The major/minor differenciation is long time ago. > > You must be looking at old code. > > > > I was trying to find a good way to do scanning, whjen I create the files like > /dev/usb0, how far to go in my loop? Does the lowest available device always > get created? That would imply that as soon as I began to get "No such device" > errors, I could stop iterating. If the rules for picking device filenames are > pretty loose, then I could (for instance) stop scanning, say, 4 numbers past the > first "No such device" returnee. This wouldn't work if a USB controller is remove - e.g. a pulling a cardbus card. > Any idea on this? I didn't see this i nthe code, but I just need some sane > limit on what filenames to scan about in. I look for item info, and if the usb > vendor and prodict look friendly, I just snag the filename involved, and use > that. Like, a scan of the usb1 bus might yield me a uhid0 which might be my > meat, whereupon I coulld drop the usb1 open, and replace it with a uhid0 open. > There's more than 1 place that my devices could show, depending on the user's > kernel devices. I just want to have some sane limit on how many usb buses I > open for my scanning. I never had to deal with this, since writing a USB driver is simple and as a driver you get informed for each new device. No need to scan the busses yourself. But I would say that the most reliable way is to just scan /dev/ for usb... -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From chuckr at telenix.org Sun Jun 8 17:02:08 2008 From: chuckr at telenix.org (Chuck Robey) Date: Sun Jun 8 17:02:13 2008 Subject: number of /dev/usb nodes In-Reply-To: <20080608155015.GO71712@cicely7.cicely.de> References: <484AC2F1.1000806@telenix.org> <20080608134227.GM71712@cicely7.cicely.de> <484BE9BA.5040308@telenix.org> <20080608155015.GO71712@cicely7.cicely.de> Message-ID: <484C0E6B.5020306@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bernd Walter wrote: > On Sun, Jun 08, 2008 at 10:16:26AM -0400, Chuck Robey wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Bernd Walter wrote: >>> On Sat, Jun 07, 2008 at 01:18:41PM -0400, Chuck Robey wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> I can't seem to find how many /dev/usbN bus devices there can be. I'm writing >>>> some code that scans them all looking for anything that has my device, but I >>>> while I know to start at usb0, just how high do I go? There seem to be 128 >>>> device minors, is that the number? (from dev/usb/usb.h) >>> There shouldn't be a limit anymore. >>> I can't see any definition of 128 in usb.h that limits the number of >>> busses. >>> The major/minor differenciation is long time ago. >>> You must be looking at old code. >>> >> I was trying to find a good way to do scanning, whjen I create the files like >> /dev/usb0, how far to go in my loop? Does the lowest available device always >> get created? That would imply that as soon as I began to get "No such device" >> errors, I could stop iterating. If the rules for picking device filenames are >> pretty loose, then I could (for instance) stop scanning, say, 4 numbers past the >> first "No such device" returnee. > > This wouldn't work if a USB controller is remove - e.g. a pulling a > cardbus card. > >> Any idea on this? I didn't see this i nthe code, but I just need some sane >> limit on what filenames to scan about in. I look for item info, and if the usb >> vendor and prodict look friendly, I just snag the filename involved, and use >> that. Like, a scan of the usb1 bus might yield me a uhid0 which might be my >> meat, whereupon I coulld drop the usb1 open, and replace it with a uhid0 open. >> There's more than 1 place that my devices could show, depending on the user's >> kernel devices. I just want to have some sane limit on how many usb buses I >> open for my scanning. > > I never had to deal with this, since writing a USB driver is simple and > as a driver you get informed for each new device. > No need to scan the busses yourself. > But I would say that the most reliable way is to just scan /dev/ for > usb... > Assumptions .... I never said I was writing a FreeBSD driver... I am writing what Xorg calls an input driver (Xinput). I could rely on the config file, I thought I would try to use a scan in case I can't find the dev the user passes me. I see no reason to write a FreeBSD driver when I can do everything I need within the uhid driver (at least so far, in my test prog). There IS one caveat: I've posted to the FreeBSD-USB list that there is a part of the libusbhid that I can't yet get working. Writing a FreeBSD driver would allow me to use other available data marshalling code, like what's in the ums driver. If I can't interest anyone to comment about the libusbhid, I might be forced down that path, but I don't want to. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFITA5rz62J6PPcoOkRArTGAJ938MKH9L1HRuIpaH3QCy38huJwkQCfUCeF dE0dyEG+GZUMhi8fAIXNfRk= =ddvg -----END PGP SIGNATURE----- From patfbsd at davenulle.org Sun Jun 8 17:26:53 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Sun Jun 8 17:26:57 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <20080608135846.45799105@baby-jane-lamaiziere-net.local> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080607041855.GA3462@garage.freebsd.pl> <20080608135846.45799105@baby-jane-lamaiziere-net.local> Message-ID: <20080608192649.0539d939@baby-jane-lamaiziere-net.local> Le Sun, 8 Jun 2008 13:58:46 +0200, Patrick Lamaiziere a ?crit : > Thanks. I think it is ok for a review and test, i added the RNG stuff > since the last time and a manual page 'glxsb.4' > > http://user.lamaiziere.net/patrick/glxsb.c > http://user.lamaiziere.net/patrick/glxsb.tar.gz (all the module) I think I shall add software HMAC algorithms, like the driver padlock(4) and the latest version of glxsb on OpenBSD. To be able to work with IPsec. Anyway comments are still welcome. Regards. From patfbsd at davenulle.org Sun Jun 8 17:59:15 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Sun Jun 8 17:59:20 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <20080608192649.0539d939@baby-jane-lamaiziere-net.local> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080607041855.GA3462@garage.freebsd.pl> <20080608135846.45799105@baby-jane-lamaiziere-net.local> <20080608192649.0539d939@baby-jane-lamaiziere-net.local> Message-ID: <20080608195911.13a8d65e@baby-jane-lamaiziere-net.local> Le Sun, 8 Jun 2008 19:26:49 +0200, Patrick Lamaizi?re a ?crit : > > http://user.lamaiziere.net/patrick/glxsb.c > > http://user.lamaiziere.net/patrick/glxsb.tar.gz (all the module) All my apologies : this is not the good version :-( I've made a 'tar xzf' instead a 'tar czf' and i've lost all my work since saturday. "et merde". Going to sleep. Sorry... From jeremie at le-hen.org Sun Jun 8 21:22:42 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Sun Jun 8 21:22:47 2008 Subject: Debugging rtld In-Reply-To: <20080517174637.GL18958@deviant.kiev.zoral.com.ua> References: <20080517091740.GI70896@obiwan.tataz.chchile.org> <20080517102653.GI18958@deviant.kiev.zoral.com.ua> <20080517173525.GJ70896@obiwan.tataz.chchile.org> <20080517174637.GL18958@deviant.kiev.zoral.com.ua> Message-ID: <20080608211851.GA52350@obiwan.tataz.chchile.org> Hi Kostik, hackers, On Sat, May 17, 2008 at 08:46:37PM +0300, Kostik Belousov wrote: > On Sat, May 17, 2008 at 07:35:25PM +0200, Jeremie Le Hen wrote: > > Hi, > > > > On Sat, May 17, 2008 at 01:26:53PM +0300, Kostik Belousov wrote: > > > On Sat, May 17, 2008 at 11:17:40AM +0200, Jeremie Le Hen wrote: > > > > I tried to compile my source tree with -fstack-protector-all, and it > > > > happens that rtld breaks with this: once the new rtld is installed every > > > > single problem coredumps. I tried to compile rtld-elf without SSP, but > > > > it didn't solve the problem. Then I had to compile libc_pic.a without > > > > SSP and it worked, but I don't understand the root of the problem. > > > > So I want to use the generated coredump for post-mortem analysis with > > > > gdb. > > > > > > > > I compiled world with DEBUG_FLAGS=-g. But GDB gives me a backtrace so > > > > long that it can't be real. Moreoever it doesn't seem to bring in the > > > > required symbols. I'm a GDB novice, so I'd like some help. > > > > > > > > chroot> ===> libexec/rtld-elf (install) > > > > chroot> chflags noschg /usr/libexec/ld-elf.so.1 > > > > chroot> install -s -o root -g wheel -m 555 -C -b -fschg -S ld-elf.so.1 /libexec > > > > chroot> install -o root -g wheel -m 444 rtld.1.gz /usr/share/man/man1 > > > > chroot> *** Signal 11 > > > > chroot> > > > > chroot> jarjarbinks# cd /root; ls > > > > chroot> Segmentation fault > > > > > > > > host> jarjarbinks:145# ls -l /space/chroot/root/ls.core > > > > host> -rw------- 1 root wheel 184320 May 17 10:19 /space/chroot/root/ls.core > > > > host> jarjarbinks:149# gdb -c /space/chroot/root/ls.core -e /space/chroot/bin/ls > > > > host> GNU gdb 6.1.1 [FreeBSD] > > > > host> [...] > > > > host> This GDB was configured as "i386-marcel-freebsd". > > > > host> Core was generated by `ls'. > > > > host> Program terminated with signal 11, Segmentation fault. > > > > host> #0 0x280583e4 in ?? () > > > > host> (gdb) bt > > > > host> #0 0x280583e4 in ?? () > > > > host> #1 0x00000000 in ?? () > > > > host> #2 0x00000000 in ?? () > > > > host> #3 0x00000000 in ?? () > > > > host> #4 0x00000000 in ?? () > > > > host> #5 0x00000000 in ?? () > > > > host> #6 0x00000000 in ?? () > > > > host> #7 0x00000000 in ?? () > > > > host> #8 0x00000000 in ?? () > > > > host> #9 0x00000000 in ?? () > > > > host> #10 0x00000000 in ?? () > > > > host> #11 0xffffffff in ?? () > > > > host> #12 0x00001000 in ?? () > > > > host> [...] > > > > host> #359 0x73763a68 in ?? () > > > > host> #360 0x5b455c3d in ?? () > > > > host> [...] > > > > host> #855 0x00000000 in ?? () > > > > host> [...] > > > > > > > > Any hint on how to proceed would be welcome. > > > > > > I usually add the CFLAGS+=-g to the rtld-elf/Makefile. Also, you do not > > > need to bring down the whole host by the broken ld.so.1. Do not install > > > it at all, and specify the path to the rtld by the --dynamic-linker switch, > > > see into ld. > Hmm, ^^^^ info > > > > Thank you for this tip. However the backtrace is still unusable. > > I've recompiled libc_pic.a with -g, then rtld-elf with -g and finally > > /bin/ls with you tip and -g. > > > > I'm really brought to a standstill here. > > Looks like you have a stack corruption, that is reasonable given the > matters you touching. The easiest, althought somewhat time-consuming way > of searching the point where the things break is to insert some break > into the code of the rtld, "int3" may be good, and moving it forward > until you start hitting the breakage instead of the breakpoint. I've naively added asm("int3;"); to the rtld-elf source, but I definitely can't debug rtld as an usual program. According to the rtld source, I'd say GDB needs some cooperation from rtld itself. Chicken and egg problem here. I've tested various methods to achieve debugging, such as explicitely use the "add-symbol-file" GDB command to load ld-elf.so.1 at its entry point. Given that the backtrace is unusable, I've tried to dump the stack starting from $ebp, and I think I could identify one or two pointers into the text, but GDB says there is nothing to disassemble at those address. I don't have enough {linker,loader,gdb}-fu to go on this way. FWIW, I succeded to understand where is the segmentation fault by dichotomy placing "assert(NULL)" in the code. Interestingly, when libc is compiled *with* -fstack-protector-all (but sys/stack_protector.c), rtld is compiled *without* stack protection, the call to mmap(2) in libexec/rtld-elf/i386/reloc.c:reloc_non_plt() triggers a SIGSEGV. Any hint from a rtld guru would be welcome... Thanks. -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From ivoras at freebsd.org Sun Jun 8 22:54:25 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Sun Jun 8 22:54:30 2008 Subject: Impact of having a large number of open file descriptors In-Reply-To: References: Message-ID: Ivan Voras wrote: > Hi, > > Im thinking again of the old idea of implementing poor man's file > replication system using kqueue to monitor changes on files. I made something with the idea, available here: http://ivoras.sharanet.org/stuff/adfs.tgz It was hacked up over the weekend and probably contains many bugs, and the whole idea has scalability problems because of the need to have all those files open. I think it's OK for what I want to do, YMMV. If there's interest I'll keep updating it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080608/dca91bbd/signature.pgp From mohacsi at niif.hu Mon Jun 9 07:53:28 2008 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon Jun 9 07:53:32 2008 Subject: openssl with zlib support In-Reply-To: <20080607124420.GA979@zaphod.nitro.dk> References: <20080606185442.O7163@mignon.ki.iif.hu> <20080607124420.GA979@zaphod.nitro.dk> Message-ID: <20080609095158.P27725@mignon.ki.iif.hu> On Sat, 7 Jun 2008, Simon L. Nielsen wrote: > On 2008.06.06 19:02:36 +0200, Mohacsi Janos wrote: >> Dear All, >> Are there any reason to not enabling zlib compression for TLS in openssl >> on FreeBSD ? > > No, that seems like a mistake. Which FreeBSD version are you using, > and are you using OpenSSL from base or ports? FreeBSD mignon.ki.iif.hu 6.3-STABLE FreeBSD 6.3-STABLE #12: Mon May 19 18:48:06 CEST 2008 root@mignon.ki.iif.hu:/usr/obj/usr/src/sys/MIGNON2 i386 I am using OpenSSL from base. > >> Would it break ABI if I enable it by tweaking the openssl Makefile? > > Probably not, but I'm not sure where it's enabled/disabled so I can't > say for sure. > > I will try to look into this more, but it might not be until sometime > next week. Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > > -- > Simon L. Nielsen > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From yanefbsd at gmail.com Mon Jun 9 08:34:21 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Mon Jun 9 08:34:24 2008 Subject: Bug by design in getfsfile(3) / needed sanity check for mountpoints Message-ID: <7d6fde3d0806090134u1c46c9f3gbeed3fb303876338@mail.gmail.com> Hi hackers, I have a question, pending a bug found in getfsfile(3) [1]. Is there any possibility where a mountpoint be any value other than a directory, a symlink, or "none", i.e. a flat file? Thanks, -Garrett References: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/124409 (not fully in PR database yet). From ivoras at freebsd.org Mon Jun 9 09:21:49 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Jun 9 09:21:54 2008 Subject: timestamping for kernel messages (like Solaris and Linux) In-Reply-To: <2e77fc10806080513wa73444ep50162e1d5f45f15@mail.gmail.com> References: <2e77fc10806080024s19951abbnf31913d5579f4535@mail.gmail.com> <20080608115919.GE67629@server.vk2pj.dyndns.org> <2e77fc10806080513wa73444ep50162e1d5f45f15@mail.gmail.com> Message-ID: Niki Denev wrote: > I'm looking at a Linux machine right now, and it looks like > they use the time since boot (actually uptime) for the timestamps. Debian or Ubuntu, right? I think RedHat uses absolute time (hh:mm:ss). > Anyways, does this sound like something that FreeBSD should have? > It could be useful in some situations, like embedded applications > without running syslog, > full /var partitions, etc. If it's only available when explicitly turned on, sure. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080609/2985a0bb/signature.pgp From det135 at psu.edu Mon Jun 9 17:25:10 2008 From: det135 at psu.edu (Derek Taylor) Date: Mon Jun 9 17:25:16 2008 Subject: Kerberos support in NFSv4 In-Reply-To: <20080607023315.GD31784@zloafman.west.isilon.com> References: <20080606205713.GS56965@psu.edu> <20080607023315.GD31784@zloafman.west.isilon.com> Message-ID: <20080609172502.GV56965@psu.edu> On Fri, 06 Jun 2008, Zachary Loafman wrote: >Isilon Systems is sponsoring RPCSEC_GSS work for FreeBSD soon. I expect >that we'll have it CURRENT later this year. We don't really have any >plans to glue it into the v4 client just yet, we're targeting Kerberized >NFSv3 first. We are looking at NFSv4 longer term, though, at which point >we will have to beat the v4 client into shape for internal testing >purposes. This is great news. Thank you -Derek. >...Zach > >On Fri, Jun 06, 2008 at 04:57:13PM -0400, Derek Taylor wrote: >> Is anyone aware of a project to add kerberos support to FreeBSD's NFSv4 >> implementation? >> >> Is there a better list to ask about development efforts and directions >> for HEAD? >> >> Thanks. >> >> -Derek. >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > >-- >Zach Loafman | Staff Engineer >Isilon Systems D +1-206-315-7570 F +1-206-315-7485 >www.isilon.com P +1-206-315-7500 M +1-206-422-3461 > From max at love2party.net Mon Jun 9 19:03:06 2008 From: max at love2party.net (Max Laier) Date: Mon Jun 9 19:03:13 2008 Subject: New Mailinglist: freebsd-wip-status@ Message-ID: <200806092102.16651.max@love2party.net> Hello everybody, SHORT SUMMARY: http://lists.freebsd.org/mailman/listinfo/freebsd-wip-status Subscribe today!! Tell all your friends, co-workers and everybody you know who's interested in FreeBSD. Post this on your blog! ;) LONG VERSION: if you've been around lately you might already know about our effort to provide periodical status reports about ongoing FreeBSD related WIPs. The past reports can be found at: http://www.freebsd.org/news/status This system has some shortcomings however. The biggest one is that due to the collection overhead and the high rate of exciting development under the FreeBSD umbrella most of the reports are somewhat outdated by the time they get to "print". Other projects never are announced in the status reports because they happen in-between and fall through the cracks. In order to improve this situation we have created a new mailing list that should receive status reports from now on. This list will be moderated in order to keep it close to the subject. The intend is to make this an inviting place for people with little time to still stay on top of the latest and greatest in and around FreeBSD, but where one can avoid the chatter that comes with the technical debates on the normal lists. For all developers, contributors, conference organizers, 3rd party distributions, SoC-students and whoeverelse has exciting news about their FreeBSD related project this means little work. Most of you already are sending out announcement- and update-emails to lists like current@, net@ or whichever fits your project in order to inform the world about the progress you've made. Now we would like to invite you to BCC: this email to freebsd-wip-status@ as well for maximum exposure. Emails with a lot of gory, technical details are probably not suited for this list, but the usual: "Hey, I've got these cool patches to test. Here is what they do: ..." most certainly is. So this is really like the status reports before, but everybody subscribed can get the news when they happen (and not three month later when the next status reports are due). I hope for your support in bootstrapping this idea. During the next few weeks I'll keep a close eye on the lists I'm subscribed to and will encourage people to forward matching posts to freebsd-wip-status@ You are welcome to do the same. We also plan to keep the status reports as is, but collecting the reports from this new list, too. This should give the best of both worlds, we hope. If you have any questions or would like to help with editing the status reports, please contact monthly@FreeBSD.org (reply-to set) or myself directly. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From keramida at ceid.upatras.gr Tue Jun 10 00:53:55 2008 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Tue Jun 10 00:54:01 2008 Subject: Bug by design in getfsfile(3) / needed sanity check for mountpoints In-Reply-To: <7d6fde3d0806090134u1c46c9f3gbeed3fb303876338@mail.gmail.com> (Garrett Cooper's message of "Mon, 9 Jun 2008 01:34:19 -0700") References: <7d6fde3d0806090134u1c46c9f3gbeed3fb303876338@mail.gmail.com> Message-ID: <87ej766rfu.fsf@kobe.laptop> On Mon, 9 Jun 2008 01:34:19 -0700, "Garrett Cooper" wrote: > Hi hackers, > I have a question, pending a bug found in getfsfile(3) [1]. > Is there any possibility where a mountpoint be any value other > than a directory, a symlink, or "none", i.e. a flat file? > Thanks, > -Garrett > > References: > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/124409 (not fully in PR > database yet). It looks like could be 'fixed' by using realpath() on its argument. Then this should work fine: # fsck /usr/ From keramida at ceid.upatras.gr Tue Jun 10 00:55:15 2008 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Tue Jun 10 00:55:20 2008 Subject: Bug by design in getfsfile(3) / needed sanity check for mountpoints In-Reply-To: <87ej766rfu.fsf@kobe.laptop> (Giorgos Keramidas's message of "Tue, 10 Jun 2008 03:53:41 +0300") References: <7d6fde3d0806090134u1c46c9f3gbeed3fb303876338@mail.gmail.com> <87ej766rfu.fsf@kobe.laptop> Message-ID: <87abhu6rdn.fsf@kobe.laptop> On Tue, 10 Jun 2008 03:53:41 +0300, Giorgos Keramidas wrote: > On Mon, 9 Jun 2008 01:34:19 -0700, "Garrett Cooper" wrote: >> Hi hackers, >> I have a question, pending a bug found in getfsfile(3) [1]. >> Is there any possibility where a mountpoint be any value other >> than a directory, a symlink, or "none", i.e. a flat file? >> Thanks, >> -Garrett >> >> References: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/124409 (not fully in PR >> database yet). > > It looks like could be 'fixed' by using realpath() on its argument. > Then this should work fine: > > # fsck /usr/ I meant to write "It looks like getfsfile() could be 'fixed'...", but the keyboard daemon ate a word there. From yanefbsd at gmail.com Tue Jun 10 09:25:36 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Tue Jun 10 09:26:03 2008 Subject: Bug by design in getfsfile(3) / needed sanity check for mountpoints Message-ID: <9C83A8B6-0C73-4A06-A60A-527D7B7BCCE5@gmail.com> Ok.... it appears I wasn't intelligent enough to post this in the right place last night. Comments please? > Hi hackers, > I have a question, pending a bug found in getfsfile(3) [1]. > Is there any possibility where a mountpoint be any value other > than a directory, a symlink, or "none", i.e. a flat file? > Thanks, > -Garrett > > References: > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/124409 (not fully in PR > database yet). From fernando.apesteguia at gmail.com Tue Jun 10 21:33:55 2008 From: fernando.apesteguia at gmail.com (=?ISO-8859-1?Q?Fernando_Apestegu=EDa?=) Date: Tue Jun 10 21:33:59 2008 Subject: RTL8168/8111 PCI express support Message-ID: <1bd550a00806101408xb9925b6wcc027d58f7fccf78@mail.gmail.com> Hi all, I sent this mail to freebsd-questions but I got no answer. I hope you can help me. I got a computer with an RTL8168/8111 PCI Express NIC. It is shown in pciconf but it is not seen by FreeBSD 7. I'm using i386 arch. I have re and rl drivers compiled in the kernel (stock GENERIC kernel, actually). What do I need to make the NIC work properly? I tried to compile the Realtek's modified driver but I got a bunch of errors when I tried to compile it (tested up to FreeBSD 6.0 only, they say) Does this[1] anything to do with my problem? Thanks in advance. [1]http://groups.google.com/group/mailing.freebsd.stable/browse_thread/thread/aa93c58a9353ea1c From koitsu at FreeBSD.org Tue Jun 10 22:11:22 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Jun 10 22:11:25 2008 Subject: RTL8168/8111 PCI express support In-Reply-To: <1bd550a00806101408xb9925b6wcc027d58f7fccf78@mail.gmail.com> References: <1bd550a00806101408xb9925b6wcc027d58f7fccf78@mail.gmail.com> Message-ID: <20080610221122.GA81166@eos.sc1.parodius.com> On Tue, Jun 10, 2008 at 11:08:05PM +0200, Fernando Apestegu?a wrote: > I sent this mail to freebsd-questions but I got no answer. I hope you > can help me. > > I got a computer with an RTL8168/8111 PCI Express NIC. It is shown in > pciconf but it is not seen by FreeBSD 7. I'm using i386 arch. > > I have re and rl drivers compiled in the kernel (stock GENERIC kernel, > actually). > > What do I need to make the NIC work properly? CC'ing PYUN YongHyeon, who should be able to help, since he helps maintain the driver. :-) I'd recommend you start by providing pciconf -lv output here. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From pyunyh at gmail.com Wed Jun 11 01:15:39 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Jun 11 01:15:44 2008 Subject: RTL8168/8111 PCI express support In-Reply-To: <20080610221122.GA81166@eos.sc1.parodius.com> References: <1bd550a00806101408xb9925b6wcc027d58f7fccf78@mail.gmail.com> <20080610221122.GA81166@eos.sc1.parodius.com> Message-ID: <20080611004650.GA3485@cdnetworks.co.kr> On Tue, Jun 10, 2008 at 03:11:22PM -0700, Jeremy Chadwick wrote: > On Tue, Jun 10, 2008 at 11:08:05PM +0200, Fernando Apestegu?a wrote: > > I sent this mail to freebsd-questions but I got no answer. I hope you > > can help me. > > > > I got a computer with an RTL8168/8111 PCI Express NIC. It is shown in > > pciconf but it is not seen by FreeBSD 7. I'm using i386 arch. > > > > I have re and rl drivers compiled in the kernel (stock GENERIC kernel, > > actually). > > > > What do I need to make the NIC work properly? > > CC'ing PYUN YongHyeon, who should be able to help, since he helps > maintain the driver. :-) I don't know which revision of RealTek controller you have. Just knowing "pciconf -lv" is not enough. Since 7.0 didn't recognize your controller I guess it could be newer revision from RealTek. There is a WIP version that try to add support for newer controllers. In order to try the WIP version you have to update to latest 7-stable first and apply the following patch. http://people.freebsd.org/~yongari/re/re.HEAD.20080610 The patch still have some issues but it should detect/recognize your controller. > > I'd recommend you start by providing pciconf -lv output here. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > -- Regards, Pyun YongHyeon From fernando.apesteguia at gmail.com Wed Jun 11 07:13:27 2008 From: fernando.apesteguia at gmail.com (=?ISO-8859-1?Q?Fernando_Apestegu=EDa?=) Date: Wed Jun 11 07:13:29 2008 Subject: RTL8168/8111 PCI express support In-Reply-To: <20080611004650.GA3485@cdnetworks.co.kr> References: <1bd550a00806101408xb9925b6wcc027d58f7fccf78@mail.gmail.com> <20080610221122.GA81166@eos.sc1.parodius.com> <20080611004650.GA3485@cdnetworks.co.kr> Message-ID: <1bd550a00806110013u7b5c3f40wf4114d06638705a4@mail.gmail.com> On 6/11/08, Pyun YongHyeon wrote: > On Tue, Jun 10, 2008 at 03:11:22PM -0700, Jeremy Chadwick wrote: > > On Tue, Jun 10, 2008 at 11:08:05PM +0200, Fernando Apestegu?a wrote: > > > I sent this mail to freebsd-questions but I got no answer. I hope you > > > can help me. > > > > > > I got a computer with an RTL8168/8111 PCI Express NIC. It is shown in > > > pciconf but it is not seen by FreeBSD 7. I'm using i386 arch. > > > > > > I have re and rl drivers compiled in the kernel (stock GENERIC kernel, > > > actually). > > > > > > What do I need to make the NIC work properly? > > > > CC'ing PYUN YongHyeon, who should be able to help, since he helps > > maintain the driver. :-) > > I don't know which revision of RealTek controller you have. Just > knowing "pciconf -lv" is not enough. Since 7.0 didn't recognize > your controller I guess it could be newer revision from RealTek. > There is a WIP version that try to add support for newer > controllers. In order to try the WIP version you have to update to > latest 7-stable first and apply the following patch. > > http://people.freebsd.org/~yongari/re/re.HEAD.20080610 > > The patch still have some issues but it should detect/recognize > your controller. It makes sense what you say about the new revision cause the whole computer is quite new. In any case I will paste the "pciconf -lv" output just to be sure of the controller I have. I already have the 7-stable system installed with the kernel sources installed from sysinstall. Do I need any update of the source code? Thanks in advance. > > > > > I'd recommend you start by providing pciconf -lv output here. > > > > -- > > | Jeremy Chadwick jdc at parodius.com | > > | Parodius Networking http://www.parodius.com/ | > > | UNIX Systems Administrator Mountain View, CA, USA | > > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > > > -- > Regards, > Pyun YongHyeon > From bu7cher at yandex.ru Wed Jun 11 07:30:14 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Wed Jun 11 07:30:18 2008 Subject: [RFC] patch to AHCI device detection code Message-ID: <484F7EF9.5080602@yandex.ru> Hi, Soren. I'm found solution for AHCI that solve ATAPI device detection for me. I just added waiting loop on PxTFD after reset and now my SATA DVD detected well. Waiting time (in my case) may vary from 1ms to 900 ms. Also AHCI spec says: 10.4.2 Port Reset ... When PxSCTL.DET is set to 0h, upon receiving a COMINIT from the attached device, PxTFD.STS.BSY shall be set to ?1? by the HBA. So we can wait until PxTFD.STS.BSY resets to zero and then read PxSIG. Any comments? -- WBR, Andrey V. Elsukov -------------- next part -------------- Index: src/sys/dev/ata/ata-chipset.c =================================================================== RCS file: /ncvs/src/sys/dev/ata/ata-chipset.c,v retrieving revision 1.219 diff -u -b -p -r1.219 ata-chipset.c --- src/sys/dev/ata/ata-chipset.c 21 Apr 2008 10:51:38 -0000 1.219 +++ src/sys/dev/ata/ata-chipset.c 11 Jun 2008 07:17:53 -0000 @@ -1059,10 +1059,10 @@ ata_ahci_softreset(device_t dev, int por struct ata_pci_controller *ctlr = device_get_softc(device_get_parent(dev)); struct ata_channel *ch = device_get_softc(dev); int offset = ch->unit << 7; + int timeout = 0; #ifdef AHCI_PM struct ata_ahci_cmd_tab *ctp = (struct ata_ahci_cmd_tab *)(ch->dma.work + ATA_AHCI_CT_OFFSET); - int timeout = 0; /* kick controller into sane state if needed */ ata_ahci_restart(dev); @@ -1091,6 +1091,7 @@ ata_ahci_softreset(device_t dev, int por ata_udelay(150000); +#endif timeout = 0; do { DELAY(1000); @@ -1101,7 +1102,6 @@ ata_ahci_softreset(device_t dev, int por } while (ATA_INL(ctlr->r_res2, ATA_AHCI_P_TFD + offset) & ATA_S_BUSY); if (bootverbose) device_printf(dev, "BUSY wait time=%dms\n", timeout); -#endif return ATA_INL(ctlr->r_res2, ATA_AHCI_P_SIG + offset); } From bu7cher at yandex.ru Wed Jun 11 07:49:07 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Wed Jun 11 07:49:12 2008 Subject: [RFC] patch to AHCI device detection code In-Reply-To: <484F7EF9.5080602@yandex.ru> References: <484F7EF9.5080602@yandex.ru> Message-ID: <484F8369.5030407@yandex.ru> Andrey V. Elsukov wrote: > Hi, Soren. Hi, All too :) Not so long Soren said that he is losing emails, so i added freebsd-hackers@ list to be heard. -- WBR, Andrey V. Elsukov From sos at FreeBSD.ORG Wed Jun 11 07:54:57 2008 From: sos at FreeBSD.ORG (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Wed Jun 11 07:55:23 2008 Subject: [RFC] patch to AHCI device detection code In-Reply-To: <484F7EF9.5080602@yandex.ru> References: <484F7EF9.5080602@yandex.ru> Message-ID: <5291278A-81B5-4665-B5FF-1A6B2EC9CD15@FreeBSD.ORG> Hi Well, as you can see I tried this when I added the PM code to AHCI, however one of the reasons I left it out again (for now) is that it doesn't work on more than about 50% of the AHCI chipsets out there.. Modern HW in a nutshell, you win some you loose some ;) -S?ren On 11Jun, 2008, at 9:30 , Andrey V. Elsukov wrote: > Hi, Soren. > > I'm found solution for AHCI that solve ATAPI device detection for me. > I just added waiting loop on PxTFD after reset and now my SATA DVD > detected well. Waiting time (in my case) may vary from 1ms to 900 ms. > > Also AHCI spec says: > > 10.4.2 Port Reset > ... > When PxSCTL.DET is set to 0h, upon receiving a COMINIT from > the attached device, PxTFD.STS.BSY shall be set to ?1? by the HBA. > > So we can wait until PxTFD.STS.BSY resets to zero and then > read PxSIG. > > Any comments? > > -- > WBR, Andrey V. Elsukov > Index: src/sys/dev/ata/ata-chipset.c > =================================================================== > RCS file: /ncvs/src/sys/dev/ata/ata-chipset.c,v > retrieving revision 1.219 > diff -u -b -p -r1.219 ata-chipset.c > --- src/sys/dev/ata/ata-chipset.c 21 Apr 2008 10:51:38 -0000 1.219 > +++ src/sys/dev/ata/ata-chipset.c 11 Jun 2008 07:17:53 -0000 > @@ -1059,10 +1059,10 @@ ata_ahci_softreset(device_t dev, int por > struct ata_pci_controller *ctlr = > device_get_softc(device_get_parent(dev)); > struct ata_channel *ch = device_get_softc(dev); > int offset = ch->unit << 7; > + int timeout = 0; > #ifdef AHCI_PM > struct ata_ahci_cmd_tab *ctp = > (struct ata_ahci_cmd_tab *)(ch->dma.work + ATA_AHCI_CT_OFFSET); > - int timeout = 0; > > /* kick controller into sane state if needed */ > ata_ahci_restart(dev); > @@ -1091,6 +1091,7 @@ ata_ahci_softreset(device_t dev, int por > > ata_udelay(150000); > > +#endif > timeout = 0; > do { > DELAY(1000); > @@ -1101,7 +1102,6 @@ ata_ahci_softreset(device_t dev, int por > } while (ATA_INL(ctlr->r_res2, ATA_AHCI_P_TFD + offset) & > ATA_S_BUSY); > if (bootverbose) > device_printf(dev, "BUSY wait time=%dms\n", timeout); > -#endif > return ATA_INL(ctlr->r_res2, ATA_AHCI_P_SIG + offset); > } > From bu7cher at yandex.ru Wed Jun 11 08:00:19 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Wed Jun 11 08:00:32 2008 Subject: [RFC] patch to AHCI device detection code In-Reply-To: <5291278A-81B5-4665-B5FF-1A6B2EC9CD15@FreeBSD.ORG> References: <484F7EF9.5080602@yandex.ru> <5291278A-81B5-4665-B5FF-1A6B2EC9CD15@FreeBSD.ORG> Message-ID: <484F8609.3090601@yandex.ru> S?ren Schmidt wrote: > Well, as you can see I tried this when I added the PM code to AHCI, > however one of the reasons I left it out again (for now) is that it > doesn't work on more than about 50% of the AHCI chipsets out there.. > > Modern HW in a nutshell, you win some you loose some ;) Hm.. I think it can't made regression. I don't see nothing dangerous in addition 1s waiting (it doesn't enable softreset code, only PxTFD reading loop).. -- WBR, Andrey V. Elsukov From sos at FreeBSD.ORG Wed Jun 11 08:42:53 2008 From: sos at FreeBSD.ORG (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Wed Jun 11 08:42:56 2008 Subject: [RFC] patch to AHCI device detection code In-Reply-To: <484F8609.3090601@yandex.ru> References: <484F7EF9.5080602@yandex.ru> <5291278A-81B5-4665-B5FF-1A6B2EC9CD15@FreeBSD.ORG> <484F8609.3090601@yandex.ru> Message-ID: Hi You are right on that one of course, from my quick eyeballing the patch I thought you enabled the reset sequence too, but on a closer look its only the extra timeout, my bad. However, the most usual problem is that the devices does not leave a signature behind due to the missing reset sequence. That problem is 50/50 as some controllers apparently doesn't like the resetting and will leave busy set and a hanging channel. I'll be getting some new HW here in the lab tomorrow if all goes well, that will let me play with this on one of the failing devices again. Maybe I'll find a generic solution this time around. I'll commit this patch for now, as you said, it doesn't hurt.. -S?ren On 11Jun, 2008, at 10:00 , Andrey V. Elsukov wrote: > S?ren Schmidt wrote: >> Well, as you can see I tried this when I added the PM code to AHCI, >> however one of the reasons I left it out again (for now) is that it >> doesn't work on more than about 50% of the AHCI chipsets out there.. >> Modern HW in a nutshell, you win some you loose some ;) > > Hm.. I think it can't made regression. I don't see nothing dangerous > in addition 1s waiting (it doesn't enable softreset code, only PxTFD > reading loop).. > > -- > WBR, Andrey V. Elsukov > From jmg at funkthat.com Wed Jun 11 18:49:32 2008 From: jmg at funkthat.com (John-Mark Gurney) Date: Wed Jun 11 20:21:33 2008 Subject: bus_dmamem_alloc In-Reply-To: <200806072341.17041.jason.harmening@gmail.com> References: <200806072341.17041.jason.harmening@gmail.com> Message-ID: <20080611182632.GT3767@funkthat.com> Jason Harmening wrote this message on Sat, Jun 07, 2008 at 23:41 -0500: > I've written a FreeBSD driver for Conexant CX2388x-based PCI TV capture cards. I have a partial one in P4 that seems to handle data transers fine, but as ATI never gave me the docs for programming the ATSC demodulator, I haven't worked on it in a long time.. > Of course the driver uses busdma to be as machine-independent as possible. > One problem I've encountered is that bus_dmamem_alloc is inadequate for my > needs. The CX2388x only understands 32-bit physical addreses, and the driver This restriction is set up by the dma tag... > has two separate use cases for busdma: > > 1) Data buffers: These buffers may be relatively large (a 640x480 RGB32 video > frame is ~1.2M), and therefore it is desirable that these buffers not be > physically contiguous. > > 2) DMA program buffers: The DMA engine on the CX2388x is controlled by > special-purpose RISC instructions, usually stored in host memory, that > provide information on, among other things, the physical layout of the data > buffers, which enables handling of non-contiguous data buffers. These > programs are rarely more than a few pages in size, so for the sake of > simplicity it is desirable that DMA program buffers be physically contiguous. Why not use the SRAM for this? That's what my driver does... w/ 32k SRAM, it's more than enough for more programs... > For case 1), I malloc(9) the buffers and then feed them to busdma, since on > most machines bus_dmamem_alloc just calls contigmalloc. Use of malloc(9) is > suboptimal as it may result in bounce buffering for non-IOMMU machines with > large amounts of RAM. I prefer to do direct to use DMA as it saves on allocating a buffer in the kernel, and then coping the data from that buffer... > For case 2), I contigmalloc the DMA program buffers in the 32-bit physical > address range and then feed them to busdma. I don't use bus_dmamem_alloc > here because it always allocates the maximum size specified in the > bus_dma_tag_t. Since the driver supports dynamic data buffer allocation and > DMA program generation, DMA program sizes may vary significantly. I > therefore just create the bus_dma_tag_t with the maximum possible size for a > DMA program buffer since I'd prefer not to have to re-create the tag every > time the DMA program size changes. But always allocating the maximum buffer > size would be a huge waste of contiguous memory, so bus_dmamem_alloc is out > of the question here too. At the same time, use of contigmalloc is > suboptimal as it may not be necessary to restrict the allocation to 32-bit > physical addresses on IOMMU-equipped machines. This is something that > bus_dmamem_alloc could take care of, if only it supported a size parameter > (as I believe the NetBSD version does). > > So I have 3 questions: > > 1) Would it be possible to provide a bus_dmamem_alloc overload that takes a > size parameter? We could call it bus_dmamem_alloc_size and have > bus_dmamem_alloc just call bus_dmamem_alloc_size with dmat->maxsize to > preserve source-level compatibility with existing drivers. It would be nice, but hasn't been something someone has gotten around to implementing yet... > 2) Are there currently any serious plans to have bus_dmamem_alloc perform > multi-segment allocations on non-IOMMU machines? It looks like NetBSD does > this by reserving the physical segments and then stitching them together into > a virtually contiguous range. Is something like this feasible for FreeBSD? This would be useful for large allocations, but for now our code works, and most IO isn't that large so it hasn't been a bit issue.. It would be nice though.. :) > 3) Are there currently any serious plans to support IOMMUs on anything besides > Sun machines? The AMD AGP GART, PowerPC 970 DART, and Intel VT-d and AMD > IOMMU all come to mind. I know that one person recently was working on Intel's VT IOMMU and I thought it was close to being committed, but I haven't been following the work... > If any of these ideas sound feasible, I'd be more than willing to help > research/implement/test them. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From det135 at psu.edu Wed Jun 11 23:38:43 2008 From: det135 at psu.edu (Derek Taylor) Date: Wed Jun 11 23:38:47 2008 Subject: Kerberized CIFS client? In-Reply-To: References: <20080521182722.GC40818@psu.edu> <483554FC.9040908@dlr.de> <20080603134307.GK76952@psu.edu> <20080603173601.W41705@beagle.kn.op.dlr.de> <20080603160608.GA56965@psu.edu> <20080606191524.GQ56965@psu.edu> Message-ID: <20080611233835.GJ1189@psu.edu> On Sun, 08 Jun 2008, Atte Peltomki wrote: >smbclient (and other samba utilities) do not refer to krb5.conf when >figuring out the kerberos realm. > >you will have to put to your krb5.conf on both client and server: > >[domain_realms] > cifs.example.com = realm.example.com I've done this step, but there seems to be no difference. When I did a tcpdump and viewed the results in wireshark there was no attempt to do anything kerberos related, the first thing related to auth mentioned was NTLM. I don't see anything with lsknobs or make config. Am I missing something? -Derek. >Otherwise it will just try to use example.com as the realm. > >On 6/6/08, Derek Taylor wrote: >> On Tue, 03 Jun 2008, Atte Peltomki wrote: >>>You will have to adjust your krb5.conf to map a given domain or hostname >>>to a kerberos realm, if you are doing cross-realm authentication. See MIT >>>kerberos admin guide for details. >> >> I'm pretty sure it's set up ok. I can use smbclient -k just fine: >> $ kinit >> det135@realm.example.com's Password: >> kinit: NOTICE: ticket renewable lifetime is 1 week >> $ klist >> Credentials cache: FILE:/tmp/krb5cc_1001 >> Principal: det135@realm.example.com >> >> Issued Expires Principal >> Jun 6 15:08:47 Jun 7 01:08:47 krbtgt/realm.example.com@realm.example.com >> $ smbclient -k -U det135 //cifs.example.com/dir1 >> OS=[Unix] Server=[Samba 3.0.30] >> smb: \> ls >> . D 0 Thu Feb 14 14:46:42 2008 >> .. D 0 Fri Jun 6 10:16:29 2008 >> [ other files/directories here ] >> >> smb: \> quit >> $ cd ~/mount/smbbeta.pass.psu.edu/pass >> $ ls >> ls: .: Permission denied >> $ klist >> Credentials cache: FILE:/tmp/krb5cc_1001 >> Principal: det135@dce.psu.edu >> >> Issued Expires Principal >> Jun 6 15:08:47 Jun 7 01:08:47 krbtgt/realm.example.com@realm.example.com >> Jun 6 15:09:17 Jun 7 01:08:47 cifs/cifs.example.com@realm.example.com >> $ >> >> -Derek. >> >>>On 6/3/08, Derek Taylor wrote: >>>> On Tue, 03 Jun 2008, Harti Brandt wrote: >>>>>On Tue, 3 Jun 2008, Derek Taylor wrote: >>>>> >>>>>DT>On Thu, 22 May 2008, Hartmut Brandt wrote: >>>>>DT>>Derek Taylor wrote: >>>>>DT>>> This question was previously posed of the freebsd-questions list, >>>>> but >>>>>DT>>> with no response for a week, I'd like to try my luck here. If >>>>> there's >>>>>DT>>> any more information I should include, please speak up: I would be >>>>> glad >>>>>DT>>> to oblige. >>>>>DT>>> >>>>>DT>>> I would like to use smb/cifs with kerberos auth, but mount_smbfs >>>>> doesn't >>>>>DT>>> seem to support this. >>>>>DT>>> >>>>>DT>>> Is anyone aware of an alternate means of performing a mount via >>>>> smb/cifs >>>>>DT>>> or any patches to provide such functionality? >>>>>DT>>> >>>>>DT>>> I already have smbclient working with -k, but I am also interested >>>>> in >>>>> a >>>>>DT>>> mount. >>>>>DT>> >>>>>DT>>Try smbnetfs from ports. It's fuse based and seems to work very nice. >>>>> If >>>>>DT>>you have a large amount of shares floating in your network you want >>>>> to >>>>>DT>>restrict it to mount only the needed shares via the config file. >>>>>DT>>Otherwise it will mount what it can find... >>>>>DT>> >>>>>DT>>It plays nicely with kerberors. When your ticket expires you >>>>> immediately >>>>>DT>>loose access; when you renew it you gain access again. All without >>>>> the >>>>>DT>>need to unmount/mount. Just call smbnetfs once you have your ticket. >>>>> You >>>>>DT>>may even do this from your .profile. >>>>>DT>> >>>>>DT>>harti >>>>>DT> >>>>>DT>Sorry for not replying sooner. >>>>>DT> >>>>>DT>Initial tests here are promising (I can see some mount paths being >>>>>DT>exported from the server), but it's not fully working (I don't see all >>>>>DT>of the mount paths that *should* be exported and I get permission >>>>> denied >>>>>DT>errors). My thoughts are leaning towards an issue in negotiating auth >>>>>DT>with the server -- perhaps my krb creds aren't being used? >>>>> >>>>>You can test this easily: if your ticket expires you get permission >>>>> denied >>>>>errors when you try to look into the mounted directories. As soon as you >>>>>renew the ticket you get access again. All without restarting smbnetfs. >>>>> >>>>>harti >>>> >>>> I replaced all server names below with "example.com" (and derivatives) >>>> where appropriate: >>>> >>>> From my FreeBSD machine, using smbnetfs: >>>> >>>> $ klist >>>> klist: No ticket file: /tmp/krb5cc_1001 >>>> $ kinit det135 >>>> det135@realm.example.com's Password: >>>> kinit: NOTICE: ticket renewable lifetime is 1 week >>>> $ klist >>>> Credentials cache: FILE:/tmp/krb5cc_1001 >>>> Principal: det135@realm.example.com >>>> >>>> Issued Expires Principal >>>> Jun 3 11:51:20 Jun 3 21:51:04 >>>> krbtgt/realm.example.com@realm.example.com >>>> $ cd ~/mount/cifs.example.com/dir1 >>>> $ ls >>>> ls: .: Permission denied >>>> $ cd .. >>>> $ ls >>>> dir1 dir2 >>>> $ klist >>>> Credentials cache: FILE:/tmp/krb5cc_1001 >>>> Principal: det135@realm.example.com >>>> >>>> Issued Expires Principal >>>> Jun 3 11:51:20 Jun 3 21:51:04 >>>> krbtgt/realm.example.com@realm.example.com >>>> >>>> >>>> From my Mac, using (from Finder) >>>> Go -> Connect to Server -> cifs://cifs.example.com/dir1 >>>> >>>> $ klist >>>> klist: No Kerberos 5 tickets in credentials cache >>>> $ kinit det135 >>>> Please enter the password for det135@realm.example.com: >>>> $ klist >>>> Kerberos 5 ticket cache: 'API:Initial default ccache' >>>> Default principal: det135@realm.example.com >>>> >>>> Valid Starting Expires Service Principal >>>> 06/03/08 11:59:41 06/03/08 21:59:41 >>>> krbtgt/realm.example.com@realm.example.com >>>> renew until 06/10/08 11:59:41 >>>> >>>> #### Here I mount via Finder before continuing with the commands below >>>> >>>> $ cd /Volumes/dir1/ >>>> $ ls >>>> subdir1 subdir2 file1 file2 >>>> $ klist >>>> Kerberos 5 ticket cache: 'API:Initial default ccache' >>>> Default principal: det135@realm.example.com >>>> >>>> Valid Starting Expires Service Principal >>>> 06/03/08 11:59:41 06/03/08 21:59:41 >>>> krbtgt/realm.example.com@realm.example.com >>>> renew until 06/10/08 11:59:41 >>>> 06/03/08 12:00:31 06/03/08 21:59:41 >>>> cifs/cifs.example.com@realm.example.com >>>> renew until 06/10/08 11:59:41 >>>> >>>> >>>> It looks like my creds aren't being used on the FreeBSD machine. >>>> >>>> -Derek. >>>> _______________________________________________ >>>> freebsd-hackers@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>> To unsubscribe, send any mail to >>>> "freebsd-hackers-unsubscribe@freebsd.org" >>>> >>> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > From jason.harmening at gmail.com Thu Jun 12 01:01:27 2008 From: jason.harmening at gmail.com (Jason Harmening) Date: Thu Jun 12 01:35:38 2008 Subject: bus_dmamem_alloc In-Reply-To: <20080611182632.GT3767@funkthat.com> References: <200806072341.17041.jason.harmening@gmail.com> <20080611182632.GT3767@funkthat.com> Message-ID: <200806112003.43326.jason.harmening@gmail.com> On Wednesday 11 June 2008, John-Mark Gurney wrote: > > Why not use the SRAM for this? That's what my driver does... w/ 32k > SRAM, it's more than enough for more programs... The DMA programs (or at least a significant chunk of them) will get stored in the SRAM, if there's enough room. That's often the case with just MPEG TS, but once you add analog video there's usually not enough room. > > > For case 1), I malloc(9) the buffers and then feed them to busdma, since > > on most machines bus_dmamem_alloc just calls contigmalloc. Use of > > malloc(9) is suboptimal as it may result in bounce buffering for > > non-IOMMU machines with large amounts of RAM. > > I prefer to do direct to use DMA as it saves on allocating a buffer in > the kernel, and then coping the data from that buffer... The driver actually supports both. Kernel-mode buffers are mmap'ed, so there shouldn't be a copy. Of course user-mode buffers can still bounce... > > 1) Would it be possible to provide a bus_dmamem_alloc overload that > > takes a size parameter? We could call it bus_dmamem_alloc_size and have > > bus_dmamem_alloc just call bus_dmamem_alloc_size with dmat->maxsize to > > preserve source-level compatibility with existing drivers. > > It would be nice, but hasn't been something someone has gotten around to > implementing yet... That's probably my only real complaint here--it seems like dmat->maxsize should just be a restriction, not an allocation unit. I don't want to sound ungrateful--busdma, at an API level at least, is great compared to what other OSes have to offer. > > I know that one person recently was working on Intel's VT IOMMU and I > thought it was close to being committed, but I haven't been following > the work... That'll be awesome when it's ready. From pyunyh at gmail.com Thu Jun 12 02:46:52 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Jun 12 02:46:59 2008 Subject: RTL8168/8111 PCI express support In-Reply-To: <1bd550a00806110013u7b5c3f40wf4114d06638705a4@mail.gmail.com> References: <1bd550a00806101408xb9925b6wcc027d58f7fccf78@mail.gmail.com> <20080610221122.GA81166@eos.sc1.parodius.com> <20080611004650.GA3485@cdnetworks.co.kr> <1bd550a00806110013u7b5c3f40wf4114d06638705a4@mail.gmail.com> Message-ID: <20080612024441.GC7250@cdnetworks.co.kr> On Wed, Jun 11, 2008 at 09:13:24AM +0200, Fernando Apestegu?a wrote: > On 6/11/08, Pyun YongHyeon wrote: > > On Tue, Jun 10, 2008 at 03:11:22PM -0700, Jeremy Chadwick wrote: > > > On Tue, Jun 10, 2008 at 11:08:05PM +0200, Fernando Apestegu?a wrote: > > > > I sent this mail to freebsd-questions but I got no answer. I hope you > > > > can help me. > > > > > > > > I got a computer with an RTL8168/8111 PCI Express NIC. It is shown in > > > > pciconf but it is not seen by FreeBSD 7. I'm using i386 arch. > > > > > > > > I have re and rl drivers compiled in the kernel (stock GENERIC kernel, > > > > actually). > > > > > > > > What do I need to make the NIC work properly? > > > > > > CC'ing PYUN YongHyeon, who should be able to help, since he helps > > > maintain the driver. :-) > > > > I don't know which revision of RealTek controller you have. Just > > knowing "pciconf -lv" is not enough. Since 7.0 didn't recognize > > your controller I guess it could be newer revision from RealTek. > > There is a WIP version that try to add support for newer > > controllers. In order to try the WIP version you have to update to > > latest 7-stable first and apply the following patch. > > > > http://people.freebsd.org/~yongari/re/re.HEAD.20080610 > > > > The patch still have some issues but it should detect/recognize > > your controller. > > > It makes sense what you say about the new revision cause the whole > computer is quite new. In any case I will paste the "pciconf -lv" > output just to be sure of the controller I have. > > I already have the 7-stable system installed with the kernel sources > installed from sysinstall. Do I need any update of the source code? > If you use 7-stable, you may not have to update again. Just apply patche above and let me know the result. > Thanks in advance. > > > > > > > > > I'd recommend you start by providing pciconf -lv output here. > > > > > > -- > > > | Jeremy Chadwick jdc at parodius.com | > > > | Parodius Networking http://www.parodius.com/ | > > > | UNIX Systems Administrator Mountain View, CA, USA | > > > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > > -- Regards, Pyun YongHyeon From fernando.apesteguia at gmail.com Thu Jun 12 17:56:41 2008 From: fernando.apesteguia at gmail.com (=?ISO-8859-1?Q?Fernando_Apestegu=EDa?=) Date: Thu Jun 12 17:56:44 2008 Subject: RTL8168/8111 PCI express support In-Reply-To: <20080612024441.GC7250@cdnetworks.co.kr> References: <1bd550a00806101408xb9925b6wcc027d58f7fccf78@mail.gmail.com> <20080610221122.GA81166@eos.sc1.parodius.com> <20080611004650.GA3485@cdnetworks.co.kr> <1bd550a00806110013u7b5c3f40wf4114d06638705a4@mail.gmail.com> <20080612024441.GC7250@cdnetworks.co.kr> Message-ID: <1bd550a00806121056n5ac49766mab68f015907f4a47@mail.gmail.com> On Thu, Jun 12, 2008 at 4:44 AM, Pyun YongHyeon wrote: > On Wed, Jun 11, 2008 at 09:13:24AM +0200, Fernando Apestegu?a wrote: > > On 6/11/08, Pyun YongHyeon wrote: > > > On Tue, Jun 10, 2008 at 03:11:22PM -0700, Jeremy Chadwick wrote: > > > > On Tue, Jun 10, 2008 at 11:08:05PM +0200, Fernando Apestegu?a wrote: > > > > > I sent this mail to freebsd-questions but I got no answer. I hope you > > > > > can help me. > > > > > > > > > > I got a computer with an RTL8168/8111 PCI Express NIC. It is shown in > > > > > pciconf but it is not seen by FreeBSD 7. I'm using i386 arch. > > > > > > > > > > I have re and rl drivers compiled in the kernel (stock GENERIC kernel, > > > > > actually). > > > > > > > > > > What do I need to make the NIC work properly? > > > > > > > > CC'ing PYUN YongHyeon, who should be able to help, since he helps > > > > maintain the driver. :-) > > > > > > I don't know which revision of RealTek controller you have. Just > > > knowing "pciconf -lv" is not enough. Since 7.0 didn't recognize > > > your controller I guess it could be newer revision from RealTek. > > > There is a WIP version that try to add support for newer > > > controllers. In order to try the WIP version you have to update to > > > latest 7-stable first and apply the following patch. > > > > > > http://people.freebsd.org/~yongari/re/re.HEAD.20080610 > > > > > > The patch still have some issues but it should detect/recognize > > > your controller. > > > > > > It makes sense what you say about the new revision cause the whole > > computer is quite new. In any case I will paste the "pciconf -lv" > > output just to be sure of the controller I have. > > > > I already have the 7-stable system installed with the kernel sources > > installed from sysinstall. Do I need any update of the source code? > > > > If you use 7-stable, you may not have to update again. > Just apply patche above and let me know the result. Sorry. I was wrong. I'm using 7.0 Release and my sources are those (taken from ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/7.0-RELEASE/src/) Since I don't have NIC, I can't update my system to 7.0 stable. If the changes involved are only on those two files (sys/dev/re/if_re.c and sys/pci/if_rlreg.h) and no more -stable changes are required, could it be possible to get the diff generated against the -release sources? I already tried to apply the patch against my sources, but I get a bunch of errors. Otherwise I think I am a bit stuck unless you tell me how to update my system without a working network. Thanks in advance > > > Thanks in advance. > > > > > > > > > > > > > I'd recommend you start by providing pciconf -lv output here. > > > > > > > > -- > > > > | Jeremy Chadwick jdc at parodius.com | > > > > | Parodius Networking http://www.parodius.com/ | > > > > | UNIX Systems Administrator Mountain View, CA, USA | > > > > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > > > > > -- > Regards, > Pyun YongHyeon > From jeremie at le-hen.org Thu Jun 12 18:46:41 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Thu Jun 12 18:46:44 2008 Subject: Integration of ProPolice in FreeBSD In-Reply-To: <20080423131720.GP92168@obiwan.tataz.chchile.org> Message-ID: <20080612184237.GC15774@obiwan.tataz.chchile.org> Hi Ruslan, all, (This mail has already been sent to -arch@. I'm sending it here now for a wider audience because I really need testers.) On Wed, Apr 23, 2008 at 03:17:20PM +0200, Jeremie Le Hen wrote: > Hi Antoine, > > On Fri, Apr 18, 2008 at 04:37:06PM +0200, Antoine Brodin wrote: > > Last time I looked at your patch, there was a problem when using > > -fstack-protector-all instead of -fstack-protector: > > when you compile lib/csu/*, gnu/lib/csu/*, or > > src/lib/libc/sys/stack_protector.c with this flag, there is a kind of > > chicken/egg problem and you end up with an unusable world. > > That said, it would be great to be able to compile world with SSP when > > an option is set in src.conf. > > You were right. I had a chance to test it this weekend. Thank you for > pointing this out. I have had little spare time lately, this is why my followup have taken so long. Since this report from Antoine, my goal has been to be able to use -fstack-protector-all when building world. I hoped it would be quite straightforward, IOW that preventing bootstrap functions from being protected would be enough. Unfortunately, it seems that building libc_pic.a/libc.so with -fstack-protector-all breaks rtld in a very twisted way that I'm unable to untangle for now. Nonetheless, I really want to see this patch hit the tree before 8.x is forked off. I have existed for more than two years and I would like to avoid delaying it futher. So I will go the easy path for now and prevent libc from being built with -fstack-protector-all. Here are what haved changed since the previous patch: - SSP is opt-out except for ia64; this is intended to trigger bugs. However this doesn't mean it will be enabled by default in stable releases. - Thanks to Antoine, SSP related symbols are now compiled without stack protection itself. This prevents a chicken and egg problem. - lib/csu, gnu/lib/csu and libexec/rtld-elf are built without stack protection. I'm looking forward for more review and testing of this patch in order to get it committed soon. Ruslan, would you mind reviewing the change in bsd.own.mk as well? Thank you very much. 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: 19938 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080612/d780c7ee/fbsd8-ssp.bin From stephen at math.missouri.edu Fri Jun 13 04:54:47 2008 From: stephen at math.missouri.edu (Stephen Montgomery-Smith) Date: Fri Jun 13 04:54:51 2008 Subject: Small change to top Message-ID: <4851F593.2030504@math.missouri.edu> top doesn't get TIME right for threaded processes. How about this small change: --- usr.bin/top/machine.c-orig 2008-06-12 23:06:08.000000000 -0500 +++ usr.bin/top/machine.c 2008-06-12 23:06:51.000000000 -0500 @@ -725,6 +725,7 @@ prev_pp = pp; } else { prev_pp->ki_pctcpu += pp->ki_pctcpu; + prev_pp->ki_runtime += pp->ki_runtime; } } (Sorry if the mail client messes up the patch, but it is so short that it can be easily entered by hand.) I do realize that this is not foolproof, because it won't measure any threads that have finished. But it is perhaps a bit better than the current state of affairs, which randomly picks a runtime of one of the threads. From m.walraven at terantula.com Fri Jun 13 10:53:31 2008 From: m.walraven at terantula.com (Marco Walraven) Date: Fri Jun 13 10:53:35 2008 Subject: RELENG_7 pxeboot fails on SuperMicro 6012 Message-ID: <20080613103000.GB27681@cotton.terantula.com> Hi All, I ran into the following problem trying to pxeboot RELENG_7 on a SuperMicro 6012 system. RELENG_6 just works fine and the same RELENG_7 release pxeboots fine when I use a VMware host. Can't work out which disk we are booting from. Guessed BIOS device 0xffffff not fund by probes, defaulting to disk0: can't load 'kernel' None of the setting I have specified in /boot/loader.conf especially vfs.root.mountfrom="ufs:/dev/md0c" pop up when asking for the configured variables. Any clues ? Marco -- Terantula - Industrial Strength Open Source phone:+31 64 3232 400 / www: http://www.terantula.com / pgpkey: E7EE7A46 pgp fingerprint: F2EE 122D 964C DE68 7380 6F95 3710 7719 E7EE 7A46 From koitsu at FreeBSD.org Fri Jun 13 11:12:49 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Jun 13 11:12:53 2008 Subject: RELENG_7 pxeboot fails on SuperMicro 6012 In-Reply-To: <20080613103000.GB27681@cotton.terantula.com> References: <20080613103000.GB27681@cotton.terantula.com> Message-ID: <20080613111249.GA51360@eos.sc1.parodius.com> On Fri, Jun 13, 2008 at 12:30:00PM +0200, Marco Walraven wrote: > I ran into the following problem trying to pxeboot RELENG_7 on a SuperMicro 6012 system. RELENG_6 just works fine and the same RELENG_7 release pxeboots fine when I use a VMware host. > > Can't work out which disk we are booting from. > Guessed BIOS device 0xffffff not fund by probes, defaulting to disk0: > > can't load 'kernel' > > None of the setting I have specified in /boot/loader.conf especially vfs.root.mountfrom="ufs:/dev/md0c" pop up when asking for the configured variables. > > Any clues ? http://jdc.parodius.com/freebsd/pxeboot_serial_install.html Be sure to read this, and see Item #10. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From oranki at gmail.com Fri Jun 13 11:09:03 2008 From: oranki at gmail.com (=?UTF-8?Q?Atte_Peltom=C3=A4ki?=) Date: Fri Jun 13 11:20:21 2008 Subject: Kerberized CIFS client? In-Reply-To: <20080611233835.GJ1189@psu.edu> References: <20080521182722.GC40818@psu.edu> <483554FC.9040908@dlr.de> <20080603134307.GK76952@psu.edu> <20080603173601.W41705@beagle.kn.op.dlr.de> <20080603160608.GA56965@psu.edu> <20080606191524.GQ56965@psu.edu> <20080611233835.GJ1189@psu.edu> Message-ID: I don't think I can be of much further help, since smbnetfs and fuse are unfamiliar to me (except at concept level). Anyway, here's a few more shots in the dark: - Make sure DNS reverse records are correct - Whatever runs the fs share needs to have access to the local /etc/krb5.keytab Debugging Kerberos can be a real PITA, as the MIT libs don't show too relevant info about failures, but instead mask failures behind more generic errors. I've tried stabbing the source a bit to circumvent this, but it's not such an easy task and would only be useful for debugging anyway, since revealing too much information about a failed authentication can easily lead to security issues. -Atte On 6/12/08, Derek Taylor wrote: > On Sun, 08 Jun 2008, Atte Peltomki wrote: >>smbclient (and other samba utilities) do not refer to krb5.conf when >>figuring out the kerberos realm. >> >>you will have to put to your krb5.conf on both client and server: >> >>[domain_realms] >> cifs.example.com = realm.example.com > > I've done this step, but there seems to be no difference. When I did a > tcpdump and viewed the results in wireshark there was no attempt to do > anything kerberos related, the first thing related to auth mentioned was > NTLM. > > I don't see anything with lsknobs or make config. Am I missing > something? > > -Derek. > >>Otherwise it will just try to use example.com as the realm. >> >>On 6/6/08, Derek Taylor wrote: >>> On Tue, 03 Jun 2008, Atte Peltomki wrote: >>>>You will have to adjust your krb5.conf to map a given domain or hostname >>>>to a kerberos realm, if you are doing cross-realm authentication. See MIT >>>>kerberos admin guide for details. >>> >>> I'm pretty sure it's set up ok. I can use smbclient -k just fine: >>> $ kinit >>> det135@realm.example.com's Password: >>> kinit: NOTICE: ticket renewable lifetime is 1 week >>> $ klist >>> Credentials cache: FILE:/tmp/krb5cc_1001 >>> Principal: det135@realm.example.com >>> >>> Issued Expires Principal >>> Jun 6 15:08:47 Jun 7 01:08:47 >>> krbtgt/realm.example.com@realm.example.com >>> $ smbclient -k -U det135 //cifs.example.com/dir1 >>> OS=[Unix] Server=[Samba 3.0.30] >>> smb: \> ls >>> . D 0 Thu Feb 14 14:46:42 >>> 2008 >>> .. D 0 Fri Jun 6 10:16:29 >>> 2008 >>> [ other files/directories here ] >>> >>> smb: \> quit >>> $ cd ~/mount/smbbeta.pass.psu.edu/pass >>> $ ls >>> ls: .: Permission denied >>> $ klist >>> Credentials cache: FILE:/tmp/krb5cc_1001 >>> Principal: det135@dce.psu.edu >>> >>> Issued Expires Principal >>> Jun 6 15:08:47 Jun 7 01:08:47 >>> krbtgt/realm.example.com@realm.example.com >>> Jun 6 15:09:17 Jun 7 01:08:47 cifs/cifs.example.com@realm.example.com >>> $ >>> >>> -Derek. >>> >>>>On 6/3/08, Derek Taylor wrote: >>>>> On Tue, 03 Jun 2008, Harti Brandt wrote: >>>>>>On Tue, 3 Jun 2008, Derek Taylor wrote: >>>>>> >>>>>>DT>On Thu, 22 May 2008, Hartmut Brandt wrote: >>>>>>DT>>Derek Taylor wrote: >>>>>>DT>>> This question was previously posed of the freebsd-questions list, >>>>>> but >>>>>>DT>>> with no response for a week, I'd like to try my luck here. If >>>>>> there's >>>>>>DT>>> any more information I should include, please speak up: I would >>>>>> be >>>>>> glad >>>>>>DT>>> to oblige. >>>>>>DT>>> >>>>>>DT>>> I would like to use smb/cifs with kerberos auth, but mount_smbfs >>>>>> doesn't >>>>>>DT>>> seem to support this. >>>>>>DT>>> >>>>>>DT>>> Is anyone aware of an alternate means of performing a mount via >>>>>> smb/cifs >>>>>>DT>>> or any patches to provide such functionality? >>>>>>DT>>> >>>>>>DT>>> I already have smbclient working with -k, but I am also >>>>>> interested >>>>>> in >>>>>> a >>>>>>DT>>> mount. >>>>>>DT>> >>>>>>DT>>Try smbnetfs from ports. It's fuse based and seems to work very >>>>>> nice. >>>>>> If >>>>>>DT>>you have a large amount of shares floating in your network you want >>>>>> to >>>>>>DT>>restrict it to mount only the needed shares via the config file. >>>>>>DT>>Otherwise it will mount what it can find... >>>>>>DT>> >>>>>>DT>>It plays nicely with kerberors. When your ticket expires you >>>>>> immediately >>>>>>DT>>loose access; when you renew it you gain access again. All without >>>>>> the >>>>>>DT>>need to unmount/mount. Just call smbnetfs once you have your >>>>>> ticket. >>>>>> You >>>>>>DT>>may even do this from your .profile. >>>>>>DT>> >>>>>>DT>>harti >>>>>>DT> >>>>>>DT>Sorry for not replying sooner. >>>>>>DT> >>>>>>DT>Initial tests here are promising (I can see some mount paths being >>>>>>DT>exported from the server), but it's not fully working (I don't see >>>>>> all >>>>>>DT>of the mount paths that *should* be exported and I get permission >>>>>> denied >>>>>>DT>errors). My thoughts are leaning towards an issue in negotiating >>>>>> auth >>>>>>DT>with the server -- perhaps my krb creds aren't being used? >>>>>> >>>>>>You can test this easily: if your ticket expires you get permission >>>>>> denied >>>>>>errors when you try to look into the mounted directories. As soon as >>>>>> you >>>>>>renew the ticket you get access again. All without restarting smbnetfs. >>>>>> >>>>>>harti >>>>> >>>>> I replaced all server names below with "example.com" (and derivatives) >>>>> where appropriate: >>>>> >>>>> From my FreeBSD machine, using smbnetfs: >>>>> >>>>> $ klist >>>>> klist: No ticket file: /tmp/krb5cc_1001 >>>>> $ kinit det135 >>>>> det135@realm.example.com's Password: >>>>> kinit: NOTICE: ticket renewable lifetime is 1 week >>>>> $ klist >>>>> Credentials cache: FILE:/tmp/krb5cc_1001 >>>>> Principal: det135@realm.example.com >>>>> >>>>> Issued Expires Principal >>>>> Jun 3 11:51:20 Jun 3 21:51:04 >>>>> krbtgt/realm.example.com@realm.example.com >>>>> $ cd ~/mount/cifs.example.com/dir1 >>>>> $ ls >>>>> ls: .: Permission denied >>>>> $ cd .. >>>>> $ ls >>>>> dir1 dir2 >>>>> $ klist >>>>> Credentials cache: FILE:/tmp/krb5cc_1001 >>>>> Principal: det135@realm.example.com >>>>> >>>>> Issued Expires Principal >>>>> Jun 3 11:51:20 Jun 3 21:51:04 >>>>> krbtgt/realm.example.com@realm.example.com >>>>> >>>>> >>>>> From my Mac, using (from Finder) >>>>> Go -> Connect to Server -> cifs://cifs.example.com/dir1 >>>>> >>>>> $ klist >>>>> klist: No Kerberos 5 tickets in credentials cache >>>>> $ kinit det135 >>>>> Please enter the password for det135@realm.example.com: >>>>> $ klist >>>>> Kerberos 5 ticket cache: 'API:Initial default ccache' >>>>> Default principal: det135@realm.example.com >>>>> >>>>> Valid Starting Expires Service Principal >>>>> 06/03/08 11:59:41 06/03/08 21:59:41 >>>>> krbtgt/realm.example.com@realm.example.com >>>>> renew until 06/10/08 11:59:41 >>>>> >>>>> #### Here I mount via Finder before continuing with the commands below >>>>> >>>>> $ cd /Volumes/dir1/ >>>>> $ ls >>>>> subdir1 subdir2 file1 file2 >>>>> $ klist >>>>> Kerberos 5 ticket cache: 'API:Initial default ccache' >>>>> Default principal: det135@realm.example.com >>>>> >>>>> Valid Starting Expires Service Principal >>>>> 06/03/08 11:59:41 06/03/08 21:59:41 >>>>> krbtgt/realm.example.com@realm.example.com >>>>> renew until 06/10/08 11:59:41 >>>>> 06/03/08 12:00:31 06/03/08 21:59:41 >>>>> cifs/cifs.example.com@realm.example.com >>>>> renew until 06/10/08 11:59:41 >>>>> >>>>> >>>>> It looks like my creds aren't being used on the FreeBSD machine. >>>>> >>>>> -Derek. >>>>> _______________________________________________ >>>>> freebsd-hackers@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>>> To unsubscribe, send any mail to >>>>> "freebsd-hackers-unsubscribe@freebsd.org" >>>>> >>>> >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to >>> "freebsd-hackers-unsubscribe@freebsd.org" >>> >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From chuckr at telenix.org Fri Jun 13 19:34:42 2008 From: chuckr at telenix.org (Chuck Robey) Date: Fri Jun 13 19:34:47 2008 Subject: FreeBSD hotplugging info Message-ID: <4852C94B.2090809@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have finished doing all the work and investigation (and test program writing) I need to do, for all of the usb aspects of my grapghic tablet Xorg Xinput driver (well, THEY call it a driver). Yes, I know I've been owrking on it for a while now, but I need to move slowly for personal reasons. I can see that, for very up to date modules, Xorg wants to have hotplugging to work in their input drivers. My work contemplates using the existing FreeBSD devices (my test program uses uhid very nicely). So, I was wondering if anyone knows of any sort of software working in FreeBSD that doesn hotplugging (using dbus would be the way that Xorg contemplates), then could you tell me what it is, so I can look at it? I've already read up on dbus; it seems to be a messaging thing, so I just want to see some example of how dbus would see use in FreeBSD. I figure, since the devices I'm working on are quite inexpensive (about 60 bucks for a 8" by 6" model), it might just turn out to be popular, if I do a really good job of this. That's why I want to cross every T, dot every I. I was going ahead and adapting my test program to the Xinput example I have, when I realized I need the hotplugging feature. Thanks for any help. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIUslLz62J6PPcoOkRAkKuAJ9NS9MEapIX00nbZqFe35bdUnhUNgCfQOKS yufGBK0gpMYXIiOux7HGjmk= =BgYv -----END PGP SIGNATURE----- From yuri at rawbw.com Fri Jun 13 19:52:10 2008 From: yuri at rawbw.com (Yuri) Date: Fri Jun 13 19:52:14 2008 Subject: How to probe what application does in kernel (with sound device)? Message-ID: <4852CFE8.8040003@rawbw.com> I have linux skype that complains that it can't use sound device without giving any details. 'truss -f' flag doesn't show any system calls related to sound device (/dev/dsp*). Maybe it's because of child processes aren't really monitored by truss for linux processes. But sound from another sound application gets some strange interruption and buzz every time I try to activate sound from skype. That's how I know that skype really does something with sound device. Is there a way to probe program's activity with devices in-kernel? Yuri From frase at frase.id.au Sat Jun 14 00:28:48 2008 From: frase at frase.id.au (Fraser Tweedale) Date: Sat Jun 14 00:28:52 2008 Subject: How to probe what application does in kernel (with sound device)? In-Reply-To: <4852CFE8.8040003@rawbw.com> References: <4852CFE8.8040003@rawbw.com> Message-ID: <20080613235531.GA91339@bacardi> On Fri, Jun 13, 2008 at 12:52:08PM -0700, Yuri wrote: > I have linux skype that complains that it can't use sound device without > giving any details. > 'truss -f' flag doesn't show any system calls related to sound device > (/dev/dsp*). Maybe it's because of child processes aren't really > monitored by truss for linux processes. > But sound from another sound application gets some strange interruption > and buzz every time I try to activate sound from skype. That's how I > know that skype really does something with sound device. > > Is there a way to probe program's activity with devices in-kernel? > > Yuri > ktrace(1) From man page: The ktrace utility enables kernel trace logging for the specified pro- cesses. Kernel trace data is logged to the file ktrace.out. The kernel operations that are traced include system calls, namei translations, sig- nal processing, and I/O. frase -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080614/3377ac8b/attachment.pgp From jeremie at le-hen.org Sat Jun 14 05:29:48 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Sat Jun 14 05:29:52 2008 Subject: fvwm (was: mplayer pauses when holding a window) In-Reply-To: <3a142e750806051354s7867708esb23ba4320037b5ba@mail.gmail.com> References: <20080605143227.GB6864@epsilon.local> <3a142e750806051354s7867708esb23ba4320037b5ba@mail.gmail.com> Message-ID: <20080614052544.GA63208@obiwan.tataz.chchile.org> Hi Paul, On Thu, Jun 05, 2008 at 10:54:35PM +0200, Paul B. Mahol wrote: > I could not reproduce this with fvwm and mplayer (without esoud). But > I am aware of following (fv)wm/Xorg issue/bug/feature: if you > configured your window manager to not display window when moving it > (instead wm display frame) all Xorg windows will be put in suspend > state (music will stop playing, and such ...) BTW, do you know if it is possible to configure this behaviour? Thanks. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From patfbsd at davenulle.org Sat Jun 14 17:03:55 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Sat Jun 14 17:04:00 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <20080606234135.46144207@baby-jane-lamaiziere-net.local> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> Message-ID: <20080614190351.4ec7660d@baby-jane-lamaiziere-net.local> Le Fri, 6 Jun 2008 23:41:35 +0200, Patrick Lamaizi?re a ?crit : Hello, > I'm trying to port the glxsb driver from OpenBSD to FreeBSD 7-STABLE > (via the NetBSD port). > " The glxsb driver supports the security block of the Geode LX > series processors. The Geode LX is a member of the AMD Geode family > of integrated x86 system chips. > > Driven by periodic checks for available data from the generator, > glxsb supplies entropy to the random(4) driver for common usage. > > glxsb also supports acceleration of AES-128-CBC operations for > crypto(4)." I'm still working on it. I think it is ok now : - The random number generator feeds random(4) with entropy via random_harvest(9) - I added hmac software encryptions to be able to use the driver with ipsec(4). Most of the code is stolen from padlock(4), it is not easy to use the same code as OpenBSD : they use some code from crytosoft but in FreeBSD this code is private to the module. And the code of padlock is more "human readable", I think. - I reworked the sessions to use a TAILQ like padlock. - I added few sysctl for debugging purposes. I tested with openssl, and ipsec with all hmac supported by the driver. Seems good, but i'm not able to benchmark ipsec. Sources (7-STABLE): http://user.lamaiziere.net/patrick/glxsb-140608.tar.gz (Yes this is the good version!) If you can test it and provide some review it would be nice. Thanks, regards. From rwatson at FreeBSD.org Sat Jun 14 17:26:09 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Jun 14 17:26:14 2008 Subject: Small change to top In-Reply-To: <4851F593.2030504@math.missouri.edu> References: <4851F593.2030504@math.missouri.edu> Message-ID: <20080614182550.C66582@fledge.watson.org> On Thu, 12 Jun 2008, Stephen Montgomery-Smith wrote: > top doesn't get TIME right for threaded processes. How about this small > change: Could you file a PR for this so that it doesn't get lost? Thanks! Robert N M Watson Computer Laboratory University of Cambridge > > --- usr.bin/top/machine.c-orig 2008-06-12 23:06:08.000000000 -0500 > +++ usr.bin/top/machine.c 2008-06-12 23:06:51.000000000 -0500 > @@ -725,6 +725,7 @@ > prev_pp = pp; > } else { > prev_pp->ki_pctcpu += pp->ki_pctcpu; > + prev_pp->ki_runtime += pp->ki_runtime; > } > } > > > (Sorry if the mail client messes up the patch, but it is so short that it can > be easily entered by hand.) > > I do realize that this is not foolproof, because it won't measure any threads > that have finished. But it is perhaps a bit better than the current state of > affairs, which randomly picks a runtime of one of the threads. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From rwatson at FreeBSD.org Sat Jun 14 17:27:31 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Jun 14 17:27:36 2008 Subject: Integration of ProPolice in FreeBSD In-Reply-To: <20080612184237.GC15774@obiwan.tataz.chchile.org> References: <20080612184237.GC15774@obiwan.tataz.chchile.org> Message-ID: <20080614182623.F66582@fledge.watson.org> On Thu, 12 Jun 2008, Jeremie Le Hen wrote: > (This mail has already been sent to -arch@. I'm sending it here now for a > wider audience because I really need testers.) Dear Jeremie, Unfortunately, I can't lend my hands to this project as they're currently full of other stuff. However, I would really be very pleased to see is [finally] ship a release with ProPolice enabled. We're definitely trailing the pack in this regard, and I think it's bad practice to not ship with what are considered industry-standard protections here. Thanks for your work on this! Robert N M Watson Computer Laboratory University of Cambridge > > On Wed, Apr 23, 2008 at 03:17:20PM +0200, Jeremie Le Hen wrote: >> Hi Antoine, >> >> On Fri, Apr 18, 2008 at 04:37:06PM +0200, Antoine Brodin wrote: >>> Last time I looked at your patch, there was a problem when using >>> -fstack-protector-all instead of -fstack-protector: >>> when you compile lib/csu/*, gnu/lib/csu/*, or >>> src/lib/libc/sys/stack_protector.c with this flag, there is a kind of >>> chicken/egg problem and you end up with an unusable world. >>> That said, it would be great to be able to compile world with SSP when >>> an option is set in src.conf. >> >> You were right. I had a chance to test it this weekend. Thank you for >> pointing this out. > > I have had little spare time lately, this is why my followup have taken > so long. > > Since this report from Antoine, my goal has been to be able to use > -fstack-protector-all when building world. I hoped it would be quite > straightforward, IOW that preventing bootstrap functions from being > protected would be enough. Unfortunately, it seems that building > libc_pic.a/libc.so with -fstack-protector-all breaks rtld in a very > twisted way that I'm unable to untangle for now. > > Nonetheless, I really want to see this patch hit the tree before 8.x is > forked off. I have existed for more than two years and I would like to > avoid delaying it futher. So I will go the easy path for now and > prevent libc from being built with -fstack-protector-all. > > Here are what haved changed since the previous patch: > - SSP is opt-out except for ia64; this is intended to trigger bugs. > However this doesn't mean it will be enabled by default in stable > releases. > - Thanks to Antoine, SSP related symbols are now compiled without stack > protection itself. This prevents a chicken and egg problem. > - lib/csu, gnu/lib/csu and libexec/rtld-elf are built without stack > protection. > > I'm looking forward for more review and testing of this patch in order > to get it committed soon. > > Ruslan, would you mind reviewing the change in bsd.own.mk as well? > > Thank you very much. > Best regards, > -- > Jeremie Le Hen > < jeremie at le-hen dot org >< ttz at chchile dot org > > From ken at mthelicon.com Sat Jun 14 18:02:23 2008 From: ken at mthelicon.com (Pegasus Mc cleaft) Date: Sat Jun 14 18:02:49 2008 Subject: Hifn 7955 doesn't work with Freebsd 7.0-release Message-ID: <200806141846.04025.ken@mthelicon.com> Hi all.. I found the same problem recently, but I also found someone's post on the Internet that suggested a change to the /usr/src/crypto/openssl/crypto/engine/eng_cryptodev.c file. I made the change to the file and it definitely does force openssl to use the crypto hardware. I am not sure if there is any backlash to this patch, but I have used it on 2 of my servers with the Hifn 7955 hardware and it seems to be fine. --- eng_cryptodev.c.orig 2008-02-05 18:10:31.000000000 +0000 +++ eng_cryptodev.c 2008-06-14 18:25:36.175353823 +0100 @@ -1127,6 +1127,7 @@ } ENGINE_add(engine); + ENGINE_set_default_ciphers(engine); ENGINE_free(engine); ERR_clear_error(); } >0n Wed, May 21, 2008 at 08:19:26PM -0700, Sam Leffler wrote: > > >Unfortunately openssl doesn't use the accelerator by default. This means > >all apps that use openssl likewise are not automatically accelerated. I > >suggested a patch but it was not accepted. I can't recall how you force > >openssl and/or consumers to use the device. > >How annoying is that. Why wasn't the patch accepted ? > > -aW > > >IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. Ifyou have received this email in error, you are requested to contact the sender and delete the email. From chuckr at telenix.org Sat Jun 14 18:16:28 2008 From: chuckr at telenix.org (Chuck Robey) Date: Sat Jun 14 18:16:33 2008 Subject: FreeBSD hotplugging (Hal) info In-Reply-To: <4852C94B.2090809@telenix.org> References: <4852C94B.2090809@telenix.org> Message-ID: <4854087F.90509@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck Robey wrote: > I have finished doing all the work and investigation (and test program writing) > I need to do, for all of the usb aspects of my grapghic tablet Xorg Xinput > driver (well, THEY call it a driver). Yes, I know I've been owrking on it for a > while now, but I need to move slowly for personal reasons. I can see that, for > very up to date modules, Xorg wants to have hotplugging to work in their input > drivers. My work contemplates using the existing FreeBSD devices (my test > program uses uhid very nicely). So, I was wondering if anyone knows of any sort > of software working in FreeBSD that doesn hotplugging (using dbus would be the > way that Xorg contemplates), then could you tell me what it is, so I can look at it? > > I've already read up on dbus; it seems to be a messaging thing, so I just want > to see some example of how dbus would see use in FreeBSD. I figure, since the > devices I'm working on are quite inexpensive (about 60 bucks for a 8" by 6" > model), it might just turn out to be popular, if I do a really good job of this. > That's why I want to cross every T, dot every I. I was going ahead and > adapting my test program to the Xinput example I have, when I realized I need > the hotplugging feature. Replying to my own mail, I realize I've worded this badly ... what I meant is, does any part of FreeBSD's base make any use of Hal's (the hardware abstraction layer) API? If it does, and you could tell me where that is (because I can't find it myself) then I could find the sourvce code and read it myself, so you don't need to give me some big tutorial, just point it out if you're aware of it. I said "where that it", I mean, just give me the name, I can find out where with the name in hand, obviously. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIVAh/z62J6PPcoOkRAkDdAJ46GT/AOpp36nGoYj7z7MLYFFOYGwCfQ1ir zjFfI55ekunrN6qWSCTFNQ4= =J/My -----END PGP SIGNATURE----- From patfbsd at davenulle.org Sat Jun 14 19:43:10 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Sat Jun 14 19:43:19 2008 Subject: padlock(4) bug or feature ? Message-ID: <20080614214306.079e279f@baby-jane-lamaiziere-net.local> Hello, I was looking the code of padlock(4). In padlock_newsession(), when there is an error we call padlock_freesession with dev == NULL by sample : error = padlock_cipher_setup(ses, encini); if (error != 0) { padlock_freesession(NULL, ses->ses_id); return (error); But padlock_freesession() uses dev to get the softc. static int padlock_freesession(device_t dev, uint64_t tid) { struct padlock_softc *sc = device_get_softc(dev) I'm asking how it can work with dev == NULL ? Regards. From gabor at FreeBSD.org Sat Jun 14 23:27:55 2008 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Sat Jun 14 23:28:22 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] Message-ID: <485453F2.60507@FreeBSD.org> Hello All, Today I've basically terminated te feature-completion of the BSD-licensed grep from OpenBSD. It means, that I've accomplished the following tasks: - Implement --label - Implement --null - Implement --color / --colour - Implement -D / --devices - Implement -H / --with-filename - Implement -J / --bz2decompress - Implement -d / --directories - Implement -m / --max-count - Implement -o / --only-matching - Add --help - Eliminate warnings - style(9) cleanup I've made some preliminary tests with the fgrep and normal grep behaviour and it seems that they can achieve the same speed: /usr/bin/time -h gnugrep -e ^\#define -r /usr/include/ 24.06s real 0.11s user 0.17s sys 24.46s real 0.11s user 0.16s sys 24.37s real 0.11s user 0.16s sys 23.73s real 0.09s user 0.19s sys 23.97s real 0.06s user 0.21s sys /usr/bin/time -h bsdgrep -e ^\#define -r /usr/include/ 23.56s real 0.27s user 0.23s sys 23.40s real 0.28s user 0.21s sys 23.64s real 0.30s user 0.18s sys 23.70s real 0.30s user 0.23s sys 23.92s real 0.28s user 0.22s sys /usr/bin/time -h gnugrep -e int -r /usr/include/ 18.44s real 0.10s user 0.14s sys 18.19s real 0.09s user 0.14s sys 18.01s real 0.09s user 0.15s sys 18.10s real 0.10s user 0.14s sys 18.91s real 0.06s user 0.18s sys /usr/bin/time -h bsdgrep -e int -r /usr/include/ 18.39s real 0.12s user 0.19s sys 18.33s real 0.14s user 0.17s sys 18.26s real 0.11s user 0.20s sys 18.07s real 0.10s user 0.21s sys 17.97s real 0.14s user 0.16s sys What remains is to do more test about the performance and the compatibility with the GNU version. You can test this version easily by installing the textproc/bsdgrep port, which creates two symlinks: bsdgrep points to this version and gnugrep points to the base grep. Any help and comments are welcome. Regards, G?bor K?ved?n P.S.: Acknowledgements are going to Max Khon, who is my mentor in this program, to Diomidis Spinellis due to the his useful comments and to Sean C. Farley who worked on this implementation of grep before and provided some preliminary comments and suggestions before I started working on this project, and of course, to Google for sponsoring this piece of work. -------------- next part -------------- An embedded message was scrubbed... From: Gabor Kovesdan Subject: cvs commit: ports/textproc/bsdgrep Makefile distinfo Date: Sat, 14 Jun 2008 23:06:19 +0000 (UTC) Size: 3095 Url: http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080614/986f8fa7/bsdgrepMakefiledistinfo.eml From peterjeremy at optushome.com.au Sun Jun 15 01:18:45 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sun Jun 15 01:18:49 2008 Subject: TCP not being proactive about recoving lost packets Message-ID: <20080615011841.GT13734@server.vk2pj.dyndns.org> I am trying to ftp mysql-5.1.25-rc.tar.gz from ftp.easynet.be and noticed that progress appeared to have ceased and the ETA increasing. Looking at a tcpdump of the FTP data socket showed: 10:31:17.273106 IP minx.ftp.be.easynet.net.57796 > myhost.mydomain.xxx.yyy.56432: . 4054413516:4054414976(1460) ack 635248902 win 92 10:31:17.372968 IP myhost.mydomain.xxx.yyy.56432 > minx.ftp.be.easynet.net.57796: . ack 1460 win 28692 10:31:17.709750 IP minx.ftp.be.easynet.net.57796 > myhost.mydomain.xxx.yyy.56432: . 118260:119720(1460) ack 1 win 92 10:31:17.709807 IP myhost.mydomain.xxx.yyy.56432 > minx.ftp.be.easynet.net.57796: . ack 1460 win 28692 10:31:17.713318 IP minx.ftp.be.easynet.net.57796 > myhost.mydomain.xxx.yyy.56432: . 119720:121180(1460) ack 1 win 92 10:31:17.713368 IP myhost.mydomain.xxx.yyy.56432 > minx.ftp.be.easynet.net.57796: . ack 1460 win 28692 10:33:17.717063 IP minx.ftp.be.easynet.net.57796 > myhost.mydomain.xxx.yyy.56432: . 1460:2920(1460) ack 1 win 92 10:33:17.816684 IP myhost.mydomain.xxx.yyy.56432 > minx.ftp.be.easynet.net.57796: . ack 2920 win 28692 10:33:18.126643 IP minx.ftp.be.easynet.net.57796 > myhost.mydomain.xxx.yyy.56432: . 121180:122640(1460) ack 1 win 92 10:33:18.126666 IP myhost.mydomain.xxx.yyy.56432 > minx.ftp.be.easynet.net.57796: . ack 2920 win 28692 10:33:18.128224 IP minx.ftp.be.easynet.net.57796 > myhost.mydomain.xxx.yyy.56432: . 122640:124100(1460) ack 1 win 92 10:33:18.128239 IP myhost.mydomain.xxx.yyy.56432 > minx.ftp.be.easynet.net.57796: . ack 2920 win 28692 10:35:18.130354 IP minx.ftp.be.easynet.net.57796 > myhost.mydomain.xxx.yyy.56432: . 2920:4380(1460) ack 1 win 92 10:35:18.229382 IP myhost.mydomain.xxx.yyy.56432 > minx.ftp.be.easynet.net.57796: . ack 4380 win 28692 10:35:18.549832 IP minx.ftp.be.easynet.net.57796 > myhost.mydomain.xxx.yyy.56432: . 124100:125560(1460) ack 1 win 92 10:35:18.549855 IP myhost.mydomain.xxx.yyy.56432 > minx.ftp.be.easynet.net.57796: . ack 4380 win 28692 10:35:18.552361 IP minx.ftp.be.easynet.net.57796 > myhost.mydomain.xxx.yyy.56432: . 125560:127020(1460) ack 1 win 92 10:35:18.552376 IP myhost.mydomain.xxx.yyy.56432 > minx.ftp.be.easynet.net.57796: . ack 4380 win 28692 The FTP server resends an old packet then 2 new packets. FreeBSD ACKs each packet with the next packet it wants. Then there's a 2 minute timeout before the FTP server responds. This ahs been going on for about 45 minutes now. The client is running 7-STABLE from mid-May. Shouldn't it continue to regularly send ACKs where it knows there is outstanding data? -- 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-hackers/attachments/20080615/580bf3b2/attachment.pgp From dougb at FreeBSD.org Sun Jun 15 07:19:08 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Jun 15 07:19:11 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <485453F2.60507@FreeBSD.org> References: <485453F2.60507@FreeBSD.org> Message-ID: <4854BC29.3060507@FreeBSD.org> I use the following construct in portmaster, where pdb=/var/db/pkg, origin is set to the origin of a given port, and ro_opd is usually empty, but can be another origin directory or the same one. To guarantee that you should get some kind of results you can test with origin=devel/gettext. egrep -l "DEPORIGIN:($origin|$ro_opd)$" $pdb/*/+CONTENTS Obviously this works in portmaster with the gnu grep, but if ro_opd is unset with the bsd grep I get: egrep: empty (sub)expression If I set ro_opd to something, it works. hth, Doug -- This .signature sanitized for your protection From dds at aueb.gr Sun Jun 15 08:10:01 2008 From: dds at aueb.gr (Diomidis Spinellis) Date: Sun Jun 15 11:17:35 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <4854BC29.3060507@FreeBSD.org> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> Message-ID: <4854C96A.1080603@aueb.gr> Doug Barton wrote: > I use the following construct in portmaster, where pdb=/var/db/pkg, > origin is set to the origin of a given port, and ro_opd is usually > empty, but can be another origin directory or the same one. To guarantee > that you should get some kind of results you can test with > origin=devel/gettext. > > egrep -l "DEPORIGIN:($origin|$ro_opd)$" $pdb/*/+CONTENTS > > Obviously this works in portmaster with the gnu grep, but if ro_opd is > unset with the bsd grep I get: > > egrep: empty (sub)expression To avoid these problems I had proposed to instrument getopt to write options passed through argv in a file, build all our ports, and look at the options used. From stef-list at memberwebs.com Sun Jun 15 11:23:20 2008 From: stef-list at memberwebs.com (Stef Walter) Date: Sun Jun 15 11:23:25 2008 Subject: FreeBSD 6.3 deadlock (vm_map?) with DDB output Message-ID: <20080615112318.146C1F18512@mx.npubs.com> I've been trying to track down a deadlock on some newish production servers running FreeBSD 6.3-RELEASE-p2. The deadlock occurs on a specific (although mundane) hardware configuration, and each of several servers running this hardware deadlock about once per week. Although I suspect that this is not hardware related, from a (naive) perusal of the attached stack traces. Forgive me if my interpretation of this is all wrong, but I'm pretty desperate for help. So here's my basic understanding of the deadlock: These processes seem to be waiting on the page queue mutex: sendmail (in vm_mmap > vm_map_find > vm_map_insert > vm_map_pmap_enter) bsnmpd (in malloc, uma_large_malloc > page_alloc > kmem_malloc) httpd (in trap > trap_pfault > vm_fault) [g_up] (in g_vfs_done > bufdone) The page queue mutex is held by rsync process: rsync (in trap > trap_pfault > vm_fault > pmap_enter) Rsync kernel process (in pmap_enter) was interrupted while holding the page queue lock? Giant is enabled in loader.conf due to the needs of the pf firewall when dealing with user credentials lookups. I do not believe that Giant plays into this deadlock. Kernel config attached. Any and all help or info is welcome. Thanks in advance. Stef Walter -------------- next part -------------- # -------------------------------------------------------------------- # FREEBSD BUILD FreeBSD m2.npubs.com 6.3-RELEASE-p2 FreeBSD 6.3-RELEASE-p2 #0: Tue Jun 10 02:06:41 UTC 2008 nate@m2.npubs.com:/usr/obj/usr/src/sys/RACK2DBG i386 # -------------------------------------------------------------------- # # -------------------------------------------------------------------- # PROCESS LIST db> ps pid ppid pgrp uid state wmesg wchan cmd 35638 35637 4448 80 LJ *vm page 0xc8d5f780 sendmail 35637 40546 4448 80 SJ wait 0xc9e79218 sh 35620 1801 1801 80 SJ lockf 0xcceb4d00 httpd 35593 1801 1801 80 SJ lockf 0xcce46900 httpd 35566 1801 1801 80 SJ kqread 0xc8f8e000 httpd 35438 15070 15063 70 SJ sbwait 0xd017220c postgres 35401 4527 4527 10219 SJ select 0xc080b7e4 cleanup 35337 4527 4527 10219 SJ select 0xc080b7e4 pickup 35144 4413 4413 80 SJ select 0xc080b7e4 httpd 34797 8611 8611 0 SJ select 0xc080b7e4 virtual 34784 8611 8611 125 SJ select 0xc080b7e4 smtpd 34781 8611 8611 125 SJ select 0xc080b7e4 smtp 34761 8611 8611 125 SJ select 0xc080b7e4 proxymap 34760 8611 8611 125 SJ select 0xc080b7e4 smtpd 34757 8611 8611 125 SJ select 0xc080b7e4 smtp 34750 8611 8611 125 SJ select 0xc080b7e4 cleanup 34087 6435 6435 125 SJ kqread 0xcae9f900 anvil 34075 6435 6435 125 SJ kqread 0xcfb5b600 smtpd 33801 15070 15063 70 SJ sbwait 0xd01a8bc8 postgres 33796 4527 4527 10219 SJ select 0xc080b7e4 bounce 33423 1801 1801 80 SJ select 0xc080b7e4 httpd 33417 15070 15063 70 SJ sbwait 0xd087f638 postgres 33392 1801 1801 80 SJ select 0xc080b7e4 httpd 33207 4527 4527 10219 SJ select 0xc080b7e4 flush 33200 4527 4527 10219 SJ select 0xc080b7e4 bounce 33125 4527 4527 10219 SJ kqread 0xcb2ff900 smtp 33118 4527 4527 10219 SJ select 0xc080b7e4 smtp 33113 4527 4527 10219 SJ select 0xc080b7e4 smtp 33108 4527 4527 10219 SJ select 0xc080b7e4 smtp 33101 4527 4527 10219 SJ select 0xc080b7e4 smtp 33094 4527 4527 10219 SJ select 0xc080b7e4 smtp 33090 4527 4527 10219 SJ select 0xc080b7e4 smtp 33070 33067 33067 0 LJ *Giant 0xcaaf97c0 lynx 33067 33066 33067 0 SsJ wait 0xc9fd9648 sh 33066 4564 4564 0 SJ piperd 0xd0ab7000 cron 33056 4527 4527 10219 SJ select 0xc080b7e4 smtp 33055 4527 4527 10219 SJ lockf 0xc992f480 bounce 32994 15070 15063 70 SJ sbwait 0xc9cdc370 postgres 32976 15070 15063 70 SJ sbwait 0xd0f8e4d4 postgres 32971 4527 4527 10219 SJ select 0xc080b7e4 proxymap 32970 4527 4527 10219 SJ select 0xc080b7e4 smtpd 32869 15070 15063 70 SJ sbwait 0xc8fcc370 postgres 32852 9298 9298 10102 SJ select 0xc080b7e4 cleanup 32837 32836 32836 0 S select 0xc080b7e4 rsync 32836 7802 32836 0 RLs rsync 32774 4527 4527 0 SJ select 0xc080b7e4 local 32754 1801 1801 80 LLJ *vm page 0xc8d5f780 httpd 32753 15070 15063 70 SJ sbwait 0xc9c8ce90 postgres 32747 15070 15063 70 SJ sbwait 0xd01a8370 postgres 32739 15070 15063 70 SJ sbwait 0xccdd3d2c postgres 32710 1 32710 0 Ss biord 0xdcb814d4 jail-measure 32633 1801 1801 80 SJ select 0xc080b7e4 httpd 32623 1801 1801 80 SJ select 0xc080b7e4 httpd 32599 1801 1801 80 SJ select 0xc080b7e4 httpd 32598 1801 1801 80 SJ select 0xc080b7e4 httpd 32597 1801 1801 80 SJ select 0xc080b7e4 httpd 32596 1801 1801 80 SJ lockf 0xcceb43c0 httpd 32595 1801 1801 80 SJ select 0xc080b7e4 httpd 32301 4413 4413 80 SJ lockf 0xcce44680 httpd 32255 4413 4413 80 SJ lockf 0xcce44340 httpd 32206 15070 15063 70 SJ sbwait 0xc9cdf638 postgres 32163 1801 1801 80 SJ select 0xc080b7e4 httpd 32147 4527 4527 10219 SJ select 0xc080b7e4 trivial-rewrite 31910 8611 8611 125 SJ select 0xc080b7e4 smtpd 31740 8611 8611 125 SJ select 0xc080b7e4 trivial-rewrite 30378 4413 4413 80 SJ lockf 0xcd551b40 httpd 30355 4413 4413 80 SJ lockf 0xcceb41c0 httpd 29801 4413 4413 80 SJ lockf 0xcb331340 httpd 29375 9298 9298 10102 SJ select 0xc080b7e4 pickup 28283 4413 4413 80 SJ lockf 0xcb3317c0 httpd 28247 4413 4413 80 SJ kqread 0xcb092200 httpd 28113 9298 9298 10102 SJ select 0xc080b7e4 smtpd 28067 4413 4413 80 SJ lockf 0xd0ff87c0 httpd 26846 4413 4413 80 SJ select 0xc080b7e4 httpd 26581 9298 9298 10102 SJ select 0xc080b7e4 smtpd 26529 26528 8216 125 SJ select 0xc080b7e4 imapd 26528 8216 8216 0 SJ select 0xc080b7e4 couriertls 26424 4413 4413 80 SJ lockf 0xc92fe900 httpd 23902 15070 15063 70 SJ sbwait 0xccdcb0a8 postgres 23891 1801 1801 80 SJ select 0xc080b7e4 httpd 23721 8611 8611 125 SJ select 0xc080b7e4 pickup 22472 6435 6435 125 SJ kqread 0xcfb0cb00 pickup 21951 8958 8958 125 SJ kqread 0xcfb5b200 pickup 19724 3711 3711 125 SJ kqread 0xcfbee800 pickup 17335 9298 9298 10102 SJ select 0xc080b7e4 proxymap 17334 9298 9298 10102 SJ select 0xc080b7e4 trivial-rewrite 11733 40103 40103 80 SJ accept 0xd087d03a httpd 11732 40103 40103 80 SJ accept 0xd087d03a httpd 11731 40103 40103 80 SJ accept 0xd087d03a httpd 11730 40103 40103 80 SJ accept 0xd087d03a httpd 11728 40103 40103 80 SJ accept 0xd087d03a httpd 11727 40103 40103 80 SJ accept 0xd087d03a httpd 11726 40103 40103 80 SJ accept 0xd087d03a httpd 2181 1 2181 181 SsJ (threaded) nagios 100858 S select 0xc080b7e4 nagios 100434 S nanslp 0xc07be46c nagios 87785 7530 7530 80 SJ accept 0xca004b5a httpd 61004 8697 8697 80 SJ accept 0xca96519e httpd 56340 1917 1917 80 SJ lockf 0xcb3311c0 httpd 53973 8611 8611 125 SJ select 0xc080b7e4 anvil 52531 17166 52531 0 R+J CPU 3 ee 45059 7530 7530 80 SJ accept 0xca004b5a httpd 41862 4448 4448 80 SJ accept 0xc9c7d5ca httpd 41181 4448 4448 80 SJ accept 0xc9c7d5ca httpd 41180 4448 4448 80 SJ accept 0xc9c7d5ca httpd 41179 4448 4448 80 SJ accept 0xc9c7d5ca httpd 41178 7530 7530 80 SJ accept 0xca004b5a httpd 41175 4448 4448 80 SJ accept 0xc9c7d5ca httpd 40748 9036 9036 80 SJ accept 0xca965466 httpd 40742 9036 9036 80 SJ accept 0xca965466 httpd 40739 9036 9036 80 SJ accept 0xca965466 httpd 40726 9036 9036 80 SJ accept 0xca965466 httpd 40546 4448 4448 80 SJ wait 0xd024c000 httpd 40444 1917 1917 80 SJ lockf 0xcaa00580 httpd 40443 1917 1917 80 SJ kqread 0xcf271100 httpd 40442 1917 1917 80 SJ lockf 0xcce44500 httpd 40441 1917 1917 80 SJ lockf 0xcd551480 httpd 40440 1917 1917 80 SJ lockf 0xc8dba6c0 httpd 40428 8697 8697 80 SJ accept 0xca96519e httpd 40427 8697 8697 80 SJ accept 0xca96519e httpd 40426 8697 8697 80 SJ accept 0xca96519e httpd 40425 8697 8697 80 SJ accept 0xca96519e httpd 40424 8697 8697 80 SJ accept 0xca96519e httpd 40384 9036 9036 80 SJ accept 0xca965466 httpd 40378 7530 7530 80 SJ accept 0xca004b5a httpd 40377 7530 7530 80 SJ accept 0xca004b5a httpd 40376 7530 7530 80 SJ accept 0xca004b5a httpd 40375 7530 7530 80 SJ accept 0xca004b5a httpd 40374 7530 7530 80 SJ accept 0xca004b5a httpd 40372 9036 9036 80 SJ accept 0xca965466 httpd 40371 9036 9036 80 SJ accept 0xca965466 httpd 40370 9036 9036 80 SJ accept 0xca965466 httpd 40369 9036 9036 80 SJ accept 0xca965466 httpd 40368 9036 9036 80 SJ accept 0xca965466 httpd 40334 40332 4448 0 SJ piperd 0xcca2e198 cronolog 40333 4448 4448 80 SJ accept 0xc9c7d5ca httpd 40332 4448 4448 0 SJ wait 0xcb2cf218 sh 40310 40309 40309 0 SJ piperd 0xc9257cc0 sockin 40309 8742 40309 0 SsJ wait 0xd0171430 sh 40294 40291 40291 0 SJ piperd 0xc8fe7cc0 sockin 40291 6919 40291 0 SsJ wait 0xcdccba78 sh 36263 1 36263 0 SsJ (threaded) rrdbotd 100452 S kserel 0xce155d54 rrdbotd 100188 S select 0xc080b7e4 rrdbotd 100984 S kserel 0xce155d54 rrdbotd 100311 S kserel 0xce155d54 rrdbotd 100271 S select 0xc080b7e4 rrdbotd 100268 S kserel 0xce155d54 rrdbotd 100624 S ksesigwa 0xcaa27780 rrdbotd 17166 17165 17166 0 S+J wait 0xc994d000 bash 17165 17155 17152 0 S+J wait 0xd0d11218 su 17155 17152 17152 0 S+ wait 0xc9ec0a78 sh 17152 1980 17152 0 S+ wait 0xc8a42648 sh 15079 15078 15063 70 S+J select 0xc080b7e4 postgres 15078 15070 15063 70 S+J select 0xc080b7e4 postgres 15077 15070 15063 70 S+J select 0xc080b7e4 postgres 15074 15070 15063 70 S+J select 0xc080b7e4 postgres 15070 1 15063 70 S+J select 0xc080b7e4 postgres 1980 1 1980 0 S+ wait 0xcaa27430 bash 31591 2354 2354 80 SJ lockf 0xc8c8ee80 httpd 31578 2354 2354 80 SJ lockf 0xc8c8e640 httpd 40103 1 40103 0 SsJ nanslp 0xc07be46c httpd 38293 1 38293 0 SsJ nanslp 0xc07be46c cron 38286 1 38286 0 SsJ select 0xc080b7e4 sshd 38224 1 38224 0 SsJ select 0xc080b7e4 syslogd 91887 1 91886 0 SJ select 0xc080b7e4 ruby18 91876 1 91875 0 SJ select 0xc080b7e4 ruby18 61971 61968 8645 65534 SJ piperd 0xcd2d3000 cat 61970 61967 8645 65534 SJ piperd 0xcca51cc0 cat 61968 1 8645 65534 SJ wait 0xce938c90 sh 61967 1 8645 65534 SJ wait 0xc9d2c860 sh 64190 2354 2354 80 SJ kqread 0xcbe8e500 httpd 19433 19430 8645 65534 SJ piperd 0xcffe74c8 cat 19432 19431 8645 65534 SJ piperd 0xcad1d000 cat 19431 1 8645 65534 SJ wait 0xca5b1860 sh 19430 1 8645 65534 SJ wait 0xd0195430 sh 72427 3606 3606 80 SJ select 0xc080b7e4 httpd 95713 3606 3606 80 SJ lockf 0xcd551800 httpd 79740 3606 3606 80 SJ lockf 0xc8c8e7c0 httpd 36833 1 36833 0 SsJ select 0xc080b7e4 ruby 15574 3606 3606 80 SJ lockf 0xcaa00680 httpd 13381 6677 6677 80 SJ accept 0xc9df4466 httpd 11234 9367 9367 80 SJ lockf 0xc8d16a80 httpd 10994 9367 9367 80 SJ lockf 0xd00c2900 httpd 7909 6752 6677 80 SJ select 0xc080b7e4 ruby 73129 6677 6677 80 SJ accept 0xc9df4466 httpd 58056 6752 6677 80 SJ select 0xc080b7e4 ruby 41698 3606 3606 80 SJ lockf 0xc8a53740 httpd 41694 8569 8569 80 SJ accept 0xca965b5a httpd 37070 3266 3266 80 SJ kqread 0xcadb3700 httpd 37069 3266 3266 80 SJ lockf 0xcb7f4280 httpd 37068 3266 3266 80 SJ lockf 0xcec83700 httpd 30486 9367 9367 80 SJ lockf 0xd0ff8800 httpd 30262 9367 9367 80 SJ lockf 0xca6e3d40 httpd 11692 8743 8743 80 SJ lockf 0xcb7f4b80 httpd 11690 8743 8743 80 SJ select 0xc080b7e4 httpd 11599 8743 8743 80 SJ lockf 0xcb331bc0 httpd 11214 8743 8743 80 SJ lockf 0xcb0df340 httpd 11169 8743 8743 80 SJ lockf 0xd0043c00 httpd 9660 6677 6677 80 SJ accept 0xc9df4466 httpd 9659 6752 6677 80 SJ select 0xc080b7e4 ruby 9445 3266 3266 80 SJ lockf 0xcb0df900 httpd 9407 8611 8611 125 SJ select 0xc080b7e4 tlsmgr 9404 2354 2354 80 SJ lockf 0xc95798c0 httpd 9401 9367 9367 80 SJ lockf 0xcb7f4ac0 httpd 9400 9367 9367 80 SJ lockf 0xc95628c0 httpd 9399 9367 9367 80 SJ lockf 0xd05bd080 httpd 9398 9367 9367 80 SJ kqread 0xca619400 httpd 9397 9367 9367 80 SJ lockf 0xc9b5b440 httpd 9382 1 9382 0 SsJ nanslp 0xc07be46c cron 9375 1 9375 0 SsJ select 0xc080b7e4 sshd 9367 1 9367 0 SsJ nanslp 0xc07be46c httpd 9359 3266 3266 80 SJ lockf 0xc957a0c0 httpd 9334 9333 8760 70 SJ select 0xc080b7e4 postgres 9333 8760 8760 70 SJ select 0xc080b7e4 postgres 9332 8760 8760 70 SJ select 0xc080b7e4 postgres 9328 1 9328 0 SsJ nanslp 0xc07be46c cron 9320 1 9320 0 SsJ select 0xc080b7e4 inetd 9315 1 9315 0 SsJ accept 0xcaec119e saslauthd1 9304 9298 9298 10102 SJ select 0xc080b7e4 qmgr 9298 1 9298 0 SsJ select 0xc080b7e4 master 9268 2354 2354 80 SJ lockf 0xcec83ac0 httpd 9241 1 9241 0 SsJ select 0xc080b7e4 bsnmpd 9214 1 9214 0 SsJ nanslp 0xc07be46c cron 9202 1 9202 0 SsJ select 0xc080b7e4 sshd 9139 9107 9090 88 SJ (threaded) mysqld 100427 S kserel 0xc9a0b4b4 mysqld 100308 S kserel 0xc9a0b4b4 mysqld 100276 S kserel 0xc9a0b4b4 mysqld 100582 S kserel 0xc9a0b4b4 mysqld 100572 S select 0xc080b7e4 mysqld 100568 S kserel 0xcadf8394 mysqld 100571 S sigwait 0xeca04c14 mysqld 100564 S ksesigwa 0xc9b7f780 mysqld 9107 1 9090 88 SJ wait 0xcac42a78 sh 9093 1 9093 225 SsJ select 0xc080b7e4 perl5.8.8 9068 1 9068 0 SsJ nanslp 0xc07be46c cron 9058 1 9058 0 SsJ select 0xc080b7e4 sshd 9042 1 41 0 SJ piperd 0xcad1dcc0 logger 9041 1 41 0 SJ fifoor 0xca9e6c58 tail 9036 1 9036 0 SsJ select 0xc080b7e4 httpd 9035 8996 8980 88 SJ (threaded) mysqld 100855 S kserel 0xc8cee394 mysqld 101020 S sbwait 0xc950fd2c mysqld 100994 S select 0xc080b7e4 mysqld 101012 S sbwait 0xcce6320c mysqld 101021 S sbwait 0xd08750a8 mysqld 100393 S kserel 0xc8cee394 mysqld 100999 S sbwait 0xd0eab370 mysqld 101189 S sbwait 0xd0aa1bc8 mysqld 100578 S kserel 0xc8cee394 mysqld 101017 S kserel 0xc8cee394 mysqld 100573 S kserel 0xcadf82d4 mysqld 100558 S sigwait 0xec83bc14 mysqld 100555 S ksesigwa 0xc97f4780 mysqld 8996 1 8980 88 SJ wait 0xca0c4860 sh 8963 8958 8958 125 SJ kqread 0xcabf6400 qmgr 8958 1 8958 0 SsJ kqread 0xc8d71500 master 8893 1 8893 0 SsJ nanslp 0xc07be46c cron 8874 1 8874 0 SsJ select 0xc080b7e4 sshd 8844 1 8844 0 SsJ select 0xc080b7e4 sshd 8811 1 8811 0 SsJ nanslp 0xc07be46c cron 8804 8569 8569 80 SJ accept 0xca965b5a httpd 8802 8569 8569 80 SJ accept 0xca965b5a httpd 8801 8569 8569 80 SJ accept 0xca965b5a httpd 8799 8569 8569 80 SJ accept 0xca965b5a httpd 8798 1 8798 0 SsJ select 0xc080b7e4 sshd 8797 8569 8569 80 SJ accept 0xca965b5a httpd 8791 1 8791 0 SsJ select 0xc080b7e4 proftpd 8769 8743 8743 80 SJ lockf 0xcd6aeb00 httpd 8768 8743 8743 80 SJ lockf 0xcb7f4880 httpd 8767 8743 8743 80 SJ lockf 0xcb06a580 httpd 8766 8743 8743 80 SJ lockf 0xcb0df140 httpd 8765 8743 8743 80 SJ lockf 0xc8fb1700 httpd 8760 1 8760 70 SsJ select 0xc080b7e4 postgres 8743 1 8743 0 SsJ select 0xc080b7e4 httpd 8742 1 8742 0 SsJ select 0xc080b7e4 syslogd 8715 1 8715 0 SsJ nanslp 0xc07be46c cron 8706 1 8706 0 SsJ select 0xc080b7e4 sshd 8697 1 8697 0 SsJ nanslp 0xc07be46c httpd 8645 1 8645 65534 SsJ (threaded) proxsmtpd 100309 S kserel 0xca663154 proxsmtpd 100975 S kserel 0xca663154 proxsmtpd 101018 S kserel 0xca663154 proxsmtpd 100649 S kserel 0xca663154 proxsmtpd 101013 S accept 0xca9655ca proxsmtpd 100581 S ksesigwa 0xcaaf7138 proxsmtpd 8617 8611 8611 125 SJ select 0xc080b7e4 qmgr 8611 1 8611 0 SsJ select 0xc080b7e4 master 8569 1 8569 0 SsJ nanslp 0xc07be46c httpd 8496 1 8496 0 SsJ select 0xc080b7e4 syslogd 8437 1 8437 0 SsJ select 0xc080b7e4 syslogd 8300 8170 8169 0 SJ select 0xc080b7e4 authdaemond 8299 8170 8169 0 SJ select 0xc080b7e4 authdaemond 8298 8170 8169 0 SJ select 0xc080b7e4 authdaemond 8295 1 8295 0 SsJ select 0xc080b7e4 syslogd 8272 8271 8272 0 SJ select 0xc080b7e4 couriertcpd 8271 1 8271 0 SJ piperd 0xca366b28 courierlogger 8253 8252 8253 0 SJ select 0xc080b7e4 couriertcpd 8252 1 8252 0 SJ piperd 0xc904f990 courierlogger 8229 8228 8229 0 SJ select 0xc080b7e4 couriertcpd 8228 1 8228 0 SJ piperd 0xc9e1cb28 courierlogger 8216 8215 8216 0 SJ select 0xc080b7e4 couriertcpd 8215 1 8215 0 SJ piperd 0xca610330 courierlogger 8170 8169 8169 0 SJ select 0xc080b7e4 authdaemond 8169 1 8169 0 SJ piperd 0xc9dc1cc0 courierlogger 8121 1 8121 0 SsJ nanslp 0xc07be46c cron 8105 1 8105 0 SsJ select 0xc080b7e4 sshd 8082 1 8082 0 SsJ select 0xc080b7e4 syslogd 8081 1 8081 0 SsJ select 0xc080b7e4 syslogd 7979 1 7979 0 SsJ nanslp 0xc07be46c cron 7972 1 7972 0 SsJ select 0xc080b7e4 sshd 7848 1 7848 0 Ss+ ttyin 0xc8a6e410 getty 7847 1 7847 0 Ss+ ttyin 0xc8a74810 getty 7846 1 7846 0 Ss+ ttyin 0xc8a73010 getty 7845 1 7845 0 Ss+ ttyin 0xc8a73410 getty 7844 1 7844 0 Ss+ ttyin 0xc8a70c10 getty 7843 1 7843 0 Ss+ ttyin 0xc8a73c10 getty 7842 1 7842 0 Ss+ ttyin 0xc8a76010 getty 7841 1 7841 0 Ss+ ttyin 0xc8a75010 getty 7840 1 7840 0 Ss+ ttyin 0xc8a74410 getty 7829 1 7829 0 Ls *vm page 0xc8d5f780 bsnmpd 7802 1 7802 0 Ss select 0xc080b7e4 inetd 7695 1 7695 0 SsJ select 0xc080b7e4 syslogd 7530 1 7530 0 SsJ nanslp 0xc07be46c httpd 7302 1 7302 0 SsJ select 0xc080b7e4 bsnmpd 6919 1 6919 0 SsJ select 0xc080b7e4 syslogd 6754 6677 6677 80 SJ accept 0xc9df4466 httpd 6753 6677 6677 80 SJ accept 0xc9df4466 httpd 6752 6677 6677 80 SJ select 0xc080b7e4 httpd 6694 1 6694 0 SsJ nanslp 0xc07be46c cron 6687 1 6687 0 SsJ select 0xc080b7e4 sshd 6677 1 6677 0 SsJ nanslp 0xc07be46c httpd 6639 6578 6577 88 S+J piperd 0xca3517f8 logger 6638 6578 6577 88 S+J (threaded) mysqld 100566 S kserel 0xc8e765d4 mysqld 100383 S kserel 0xc8e765d4 mysqld 100988 S kserel 0xc8e765d4 mysqld 101056 S kserel 0xc8e765d4 mysqld 101005 S select 0xc080b7e4 mysqld 100392 S sbwait 0xcceda370 mysqld 100387 S sigwait 0xec6adc14 mysqld 100381 S ksesigwa 0xc9a09568 mysqld 6578 1 6577 88 S+J wait 0xca0c6430 sh 6568 6567 6568 0 S+J select 0xc080b7e4 couriertcpd 6567 1 6567 0 S+J piperd 0xca365660 courierlogger 6509 6508 6509 0 S+J select 0xc080b7e4 couriertcpd 6508 1 6508 0 S+J piperd 0xc99fe990 courierlogger 6505 1 6505 0 SsJ select 0xc080b7e4 syslogd 6454 6435 6435 125 SJ kqread 0xca2a1400 qmgr 6435 1 6435 0 SsJ kqread 0xca122500 master 5653 5529 5521 0 S+J select 0xc080b7e4 authdaemond 5652 5529 5521 0 S+J select 0xc080b7e4 authdaemond 5651 5529 5521 0 S+J select 0xc080b7e4 authdaemond 5650 5529 5521 0 S+J select 0xc080b7e4 authdaemond 5649 5529 5521 0 S+J select 0xc080b7e4 authdaemond 5529 5521 5521 0 S+J select 0xc080b7e4 authdaemond 5521 1 5521 0 S+J piperd 0xc8ee7cc0 courierlogger 5337 1 5337 0 SsJ select 0xc080b7e4 syslogd 5166 1 5166 0 SsJ nanslp 0xc07be46c cron 5153 1 5153 0 SsJ select 0xc080b7e4 sshd 5117 1 5117 0 SsJ (threaded) httpauthd 100563 S kserel 0xc8cee2d4 httpauthd 100652 S kserel 0xc8cee2d4 httpauthd 100468 S kserel 0xc8cee2d4 httpauthd 100444 S kserel 0xc8cee2d4 httpauthd 100183 S sbwait 0xc9df4bc8 httpauthd 100277 S sbwait 0xcb305370 httpauthd 100382 S sbwait 0xcafa0638 httpauthd 100314 S sbwait 0xcb1054d4 httpauthd 100499 S sbwait 0xcae5aa64 httpauthd 100223 S sbwait 0xcae4d4d4 httpauthd 100310 S sbwait 0xcb0bfd2c httpauthd 100973 S sbwait 0xcebd34d4 httpauthd 100388 S sbwait 0xcae4d20c httpauthd 100646 S sbwait 0xd0aa0900 httpauthd 100658 S sbwait 0xc8d3779c httpauthd 100471 S sbwait 0xcae4ca64 httpauthd 100985 S sbwait 0xc9ce420c httpauthd 100175 S sbwait 0xd0cdae90 httpauthd 100317 S sbwait 0xcebce4d4 httpauthd 100580 S sbwait 0xcb105638 httpauthd 100587 S accept 0xc9e0319e httpauthd 100272 S sbwait 0xcb0aa0a8 httpauthd 100556 S sbwait 0xcae59e90 httpauthd 100562 S sbwait 0xcb154e90 httpauthd 100306 S sbwait 0xd0173e90 httpauthd 100221 S sbwait 0xcebc4370 httpauthd 100448 S sbwait 0xd01744d4 httpauthd 100380 S sbwait 0xca004638 httpauthd 100318 S sbwait 0xc9c7da64 httpauthd 100560 S sbwait 0xcaec0370 httpauthd 100205 S sbwait 0xc9dd9e90 httpauthd 100394 S sbwait 0xcb0aaa64 httpauthd 100251 S sbwait 0xcabc120c httpauthd 101072 S sbwait 0xd07560a8 httpauthd 100575 S sbwait 0xccdd7bc8 httpauthd 101207 S sbwait 0xcfd28370 httpauthd 101211 S sbwait 0xd087c370 httpauthd 100469 S sbwait 0xd0177d2c httpauthd 101004 S sbwait 0xc8fa0638 httpauthd 100253 S sbwait 0xc9e04d2c httpauthd 100585 S sbwait 0xca265a64 httpauthd 100270 S sbwait 0xcaf8f20c httpauthd 100313 S sbwait 0xd01780a8 httpauthd 100673 S sbwait 0xcaf8ce90 httpauthd 100651 S sbwait 0xcae6f638 httpauthd 100324 S sbwait 0xcfd27370 httpauthd 100259 S sbwait 0xc9ce0638 httpauthd 100391 S sbwait 0xc9dd9370 httpauthd 100321 S sbwait 0xd01a8900 httpauthd 100476 S sbwait 0xcafa0a64 httpauthd 101190 S sbwait 0xcaf8fbc8 httpauthd 100316 S sbwait 0xc9ce379c httpauthd 100657 S sbwait 0xcb090638 httpauthd 100594 S sbwait 0xd01720a8 httpauthd 100559 S sbwait 0xd01a9638 httpauthd 100583 S sbwait 0xcaf8b900 httpauthd 100574 S sbwait 0xcb154a64 httpauthd 100364 S sbwait 0xc9cd8bc8 httpauthd 100567 S sbwait 0xcf485e90 httpauthd 100971 S sbwait 0xca254900 httpauthd 101016 S sbwait 0xccdf2d2c httpauthd 100977 S sbwait 0xcb0aa638 httpauthd 100447 S sbwait 0xc9cd9d2c httpauthd 100856 S sbwait 0xd0176d2c httpauthd 100586 S sbwait 0xcebcfe90 httpauthd 100249 S sbwait 0xc8d3b370 httpauthd 100972 S sbwait 0xc8d3ba64 httpauthd 100450 S sbwait 0xcaa86370 httpauthd 100384 S sbwait 0xcebcebc8 httpauthd 100981 S sbwait 0xccdcba64 httpauthd 100591 S sbwait 0xd01760a8 httpauthd 100998 S sbwait 0xccdf279c httpauthd 100320 S sbwait 0xcab88d2c httpauthd 101031 S sbwait 0xcdb35a64 httpauthd 100349 S sbwait 0xcf4a7bc8 httpauthd 100589 S sbwait 0xcaf8b79c httpauthd 100386 S sbwait 0xd0cd60a8 httpauthd 100979 S sbwait 0xcae4de90 httpauthd 100590 S sbwait 0xccdcbd2c httpauthd 100569 S sbwait 0xcacd2bc8 httpauthd 101008 S sbwait 0xcebd3638 httpauthd 100672 S sbwait 0xcb153900 httpauthd 100557 S sbwait 0xcb153a64 httpauthd 100541 S sbwait 0xcae59bc8 httpauthd 100389 S sbwait 0xca265900 httpauthd 100415 S sbwait 0xcaf8e0a8 httpauthd 100577 S sbwait 0xce18cbc8 httpauthd 101025 S sbwait 0xcf4a7d2c httpauthd 100561 S sbwait 0xcebd0d2c httpauthd 100385 S sbwait 0xd01774d4 httpauthd 100256 S sbwait 0xcceb74d4 httpauthd 100284 S sbwait 0xcaf8cd2c httpauthd 101040 S sbwait 0xc9cdcbc8 httpauthd 100319 S sbwait 0xd0172d2c httpauthd 100274 S sbwait 0xcb0bfe90 httpauthd 100269 S sbwait 0xd0cd84d4 httpauthd 101011 S sbwait 0xcb3294d4 httpauthd 101069 S sbwait 0xd0cdb79c httpauthd 100449 S sbwait 0xcce6379c httpauthd 100970 S sbwait 0xc8f75a64 httpauthd 101002 S sbwait 0xcb2de0a8 httpauthd 100983 S sbwait 0xc8d3b638 httpauthd 100312 S ksesigwa 0xc97f4bb0 httpauthd 5000 1 5000 389 SsJ (threaded) slapd 100993 S kserel 0xc97f6c34 slapd 100445 S kserel 0xc97f6c34 slapd 100694 S kserel 0xc97f6c34 slapd 100247 S kserel 0xc97f6c34 slapd 100857 S select 0xc080b7e4 slapd 100305 S ksesigwa 0xc9e24138 slapd 4867 1 4867 0 SsJ select 0xc080b7e4 inetd 4847 1 4847 0 SsJ accept 0xc9c7de22 svnserve 4835 1 4834 0 SJ select 0xc080b7e4 ruby18 4796 1 4796 0 SsJ select 0xc080b7e4 syslogd 4712 1 4711 0 SJ select 0xc080b7e4 ruby18 4707 1 4706 0 SJ select 0xc080b7e4 ruby18 4701 1 4700 0 SJ select 0xc080b7e4 ruby18 4648 1 4647 0 SJ select 0xc080b7e4 ruby18 4564 1 4564 0 SsJ nanslp 0xc07be46c cron 4555 1 4555 0 SsJ select 0xc080b7e4 inetd 4550 1 4550 0 SsJ accept 0xc9c7dcbe saslauthd1 4542 1 4541 0 SJ select 0xc080b7e4 ruby18 4535 4527 4527 10219 SJ select 0xc080b7e4 qmgr 4527 1 4527 0 SsJ select 0xc080b7e4 master 4454 1 41 0 S+J piperd 0xc8ee07f8 logger 4453 1 41 0 S+J fifoor 0xc8d04a38 tail 4448 1 4448 0 SsJ select 0xc080b7e4 httpd 4428 1 4428 0 SsJ nanslp 0xc07be46c cron 4421 1 4421 0 SsJ select 0xc080b7e4 sshd 4413 1 4413 0 SsJ nanslp 0xc07be46c httpd 4396 1 4396 0 SsJ select 0xc080b7e4 sshd 4335 1 4335 0 SsJ select 0xc080b7e4 syslogd 4174 4106 4105 88 S+J (threaded) mysqld 100565 S kserel 0xc9a0b394 mysqld 100519 S kserel 0xc9a0b394 mysqld 100976 S kserel 0xc9a0b394 mysqld 100980 S kserel 0xc9a0b394 mysqld 100859 S select 0xc080b7e4 mysqld 101014 S sbwait 0xc950fe90 mysqld 100991 S sbwait 0xd0cd7638 mysqld 101003 S sbwait 0xcdb354d4 mysqld 101001 S sbwait 0xd074820c mysqld 100588 S sbwait 0xccdcb370 mysqld 100454 S sbwait 0xcaf8c79c mysqld 100273 S sigwait 0xec480c14 mysqld 100267 S ksesigwa 0xc9b7fdc8 mysqld 4106 1 4105 88 S+J wait 0xc97f4218 sh 4033 1 4033 0 SsJ select 0xc080b7e4 syslogd 3879 1 3879 0 SsJ select 0xc080b7e4 inetd 3865 1 3865 0 SsJ nanslp 0xc07be46c cron 3858 1 3858 0 SsJ select 0xc080b7e4 sshd 3857 3820 3817 88 S+J (threaded) mysqld 100252 S kserel 0xc8cee4b4 mysqld 100365 S kserel 0xc8cee4b4 mysqld 100245 S select 0xc080b7e4 mysqld 100323 S kserel 0xc8cee4b4 mysqld 100650 S kserel 0xc8cee4b4 mysqld 100250 S kserel 0xc9a0b634 mysqld 100244 S sigwait 0xe9ef5c14 mysqld 100242 S ksesigwa 0xc97f4138 mysqld 3820 1 3817 88 S+J wait 0xc994d430 sh 3818 3606 3606 80 SJ lockf 0xc97e7180 httpd 3816 3606 3606 80 SJ lockf 0xccecb780 httpd 3815 3606 3606 80 SJ lockf 0xc9579c80 httpd 3814 3606 3606 80 SJ lockf 0xcb06a880 httpd 3813 3606 3606 80 SJ lockf 0xc9ec7900 httpd 3729 3711 3711 125 SJ kqread 0xc9920300 qmgr 3711 1 3711 0 SsJ kqread 0xc9914200 master 3613 1 3613 0 SsJ select 0xc080b7e4 proftpd 3606 1 3606 0 SsJ select 0xc080b7e4 httpd 3472 1 3472 0 SsJ select 0xc080b7e4 syslogd 3436 3266 3266 80 SJ lockf 0xd00437c0 httpd 3435 3266 3266 80 SJ lockf 0xcec83d80 httpd 3434 3266 3266 80 SJ lockf 0xc8dba200 httpd 3433 3266 3266 80 SJ lockf 0xd0210540 httpd 3432 3266 3266 80 SJ lockf 0xc8fd8b80 httpd 3398 1 3398 0 SsJ select 0xc080b7e4 inetd 3379 1 3379 0 SsJ nanslp 0xc07be46c cron 3344 1 3344 0 SsJ select 0xc080b7e4 sshd 3288 3279 3266 0 SJ piperd 0xc927ab28 cronolog 3287 3276 3266 0 SJ piperd 0xc8d54330 cronolog 3284 3275 3266 0 SJ piperd 0xc927a990 cronolog 3283 3272 3266 0 SJ piperd 0xc8d55330 cronolog 3279 3266 3266 0 SJ wait 0xc90c7430 sh 3276 3266 3266 0 SJ wait 0xc95a5c90 sh 3275 3266 3266 0 SJ wait 0xc97ef000 sh 3272 3266 3266 0 SJ wait 0xc97ef218 sh 3266 1 3266 0 SsJ nanslp 0xc07be46c httpd 3128 3073 3072 88 S+J (threaded) mysqld 100198 S kserel 0xc8950e74 mysqld 100204 S kserel 0xc8950e74 mysqld 100206 S kserel 0xc8950e74 mysqld 100202 S select 0xc080b7e4 mysqld 100203 S kserel 0xc8950e74 mysqld 100200 S sigwait 0xec3dac14 mysqld 100197 S ksesigwa 0xc8cc0780 mysqld 3073 1 3072 88 S+J wait 0xc90c6a78 sh 3022 1 3022 0 SsJ select 0xc080b7e4 syslogd 2545 2354 2354 80 SJ lockf 0xc8c8e700 httpd 2542 2354 2354 80 SJ lockf 0xc8c8e340 httpd 2541 2354 2354 80 SJ lockf 0xccebf4c0 httpd 2539 2354 2354 80 SJ lockf 0xc8c8e740 httpd 2538 2354 2354 80 SJ lockf 0xc8c8eb40 httpd 2369 1 2369 0 SsJ nanslp 0xc07be46c cron 2362 1 2362 0 SsJ select 0xc080b7e4 sshd 2354 1 2354 0 SsJ nanslp 0xc07be46c httpd 2259 2258 2255 70 SJ select 0xc080b7e4 postgres 2258 2255 2255 70 SJ select 0xc080b7e4 postgres 2257 2255 2255 70 SJ select 0xc080b7e4 postgres 2255 1 2255 70 SsJ select 0xc080b7e4 postgres 2199 1 2199 0 SsJ select 0xc080b7e4 syslogd 1917 1 1917 0 SsJ nanslp 0xc07be46c httpd 1892 1 1892 0 SsJ nanslp 0xc07be46c cron 1885 1 1885 0 SsJ select 0xc080b7e4 sshd 1842 1 1842 0 SsJ nanslp 0xc07be46c cron 1833 1 1833 0 SsJ select 0xc080b7e4 sshd 1801 1 1801 0 SsJ nanslp 0xc07be46c httpd 1800 1 1800 0 SsJ select 0xc080b7e4 syslogd 1476 1 1476 0 SsJ select 0xc080b7e4 syslogd 1161 1 41 0 S+J piperd 0xc9257660 logger 1160 1 41 0 S+J fifoor 0xc8c9ca58 tail 1152 1 1152 0 SsJ nanslp 0xc07be46c cron 1090 1 1090 0 SsJ select 0xc080b7e4 syslogd 680 1 680 0 Ss nanslp 0xc07be46c cron 673 1 673 0 Ss select 0xc080b7e4 sshd 644 1 643 0 S nanslp 0xc07be46c python 613 1 613 0 Ss select 0xc080b7e4 ntpd 524 1 524 0 Ss select 0xc080b7e4 syslogd 469 1 469 0 Ss select 0xc080b7e4 devd 40 0 0 0 SL - 0xec126d04 [schedcpu] 39 0 0 0 SL sdflush 0xc081caf4 [softdepflush] 38 0 0 0 SL syncer 0xc07be1dc [syncer] 37 0 0 0 SL vlruwt 0xc8a58000 [vnlru] 36 0 0 0 SL psleep 0xc080bd60 [bufdaemon] 35 0 0 0 SL pgzero 0xc081dac4 [pagezero] 34 0 0 0 SL psleep 0xc081d5cc [vmdaemon] 33 0 0 0 SL psleep 0xc081d588 [pagedaemon] 32 0 0 0 WL [swi0: sio] 31 0 0 0 WL [irq1: atkbd0] 30 0 0 0 WL [irq19: atapci1] 29 0 0 0 WL [irq15: ata1] 28 0 0 0 WL [irq14: ata0] 27 0 0 0 LL *Giant 0xcaaf97c0 [irq17: em1] 26 0 0 0 LL *Giant 0xcaaf97c0 [irq16: em0] 25 0 0 0 WL [irq9: acpi0] 24 0 0 0 SL - 0xc89a3c80 [acpi_task_2] 23 0 0 0 SL - 0xc89a3c80 [acpi_task_1] 22 0 0 0 SL - 0xc89a3c80 [acpi_task_0] 21 0 0 0 WL [swi2: cambio] 9 0 0 0 SL ccb_scan 0xc07b8b84 [xpt_thrd] 8 0 0 0 SL - 0xc89a3e00 [kqueue taskq] 20 0 0 0 WL [swi5: +] 7 0 0 0 SL - 0xc89d7080 [thread taskq] 19 0 0 0 WL [swi6: Giant taskq] 18 0 0 0 WL [swi6: task queue] 17 0 0 0 SL - 0xc07bae00 [yarrow] 6 0 0 0 SL crypto_r 0xc081c7c4 [crypto returns] 5 0 0 0 SL crypto_w 0xc081c784 [crypto] 4 0 0 0 SL - 0xc07bb928 [g_down] 3 0 0 0 LL *vm page 0xc8d5f780 [g_up] 2 0 0 0 SL - 0xc07bb91c [g_event] 16 0 0 0 WL [swi1: net] 15 0 0 0 WL [swi3: vm] 14 0 0 0 LL *Giant 0xcaaf97c0 [swi4: clock sio] 13 0 0 0 RL CPU 0 [idle: cpu0] 12 0 0 0 RL CPU 1 [idle: cpu1] 11 0 0 0 RL CPU 2 [idle: cpu2] 10 0 0 0 RL [idle: cpu3] 1 0 1 0 SLs wait 0xc8951000 [init] 0 0 0 0 WLs [swapper] # -------------------------------------------------------------------- # CPU LISTING db> show pcpu cpuid = 1 curthread = 0xc894c900: pid 12 "idle: cpu1" curpcb = 0xe81f2d90 fpcurthread = none idlethread = 0xc894c900: pid 12 "idle: cpu1" APIC ID = 1 currentldt = 0x50 spin locks held: db> show allpcpu Current CPU: 1 cpuid = 0 curthread = 0xc894ca80: pid 13 "idle: cpu0" curpcb = 0xe81f5d90 fpcurthread = none idlethread = 0xc894ca80: pid 13 "idle: cpu0" APIC ID = 0 currentldt = 0x50 spin locks held: cpuid = 1 curthread = 0xc894c900: pid 12 "idle: cpu1" curpcb = 0xe81f2d90 fpcurthread = none idlethread = 0xc894c900: pid 12 "idle: cpu1" APIC ID = 1 currentldt = 0x50 spin locks held: cpuid = 2 curthread = 0xc894c780: pid 11 "idle: cpu2" curpcb = 0xe81efd90 fpcurthread = none idlethread = 0xc894c780: pid 11 "idle: cpu2" APIC ID = 2 currentldt = 0x50 spin locks held: cpuid = 3 curthread = 0xca268900: pid 52531 "ee" curpcb = 0xec710d90 fpcurthread = none idlethread = 0xc894c600: pid 10 "idle: cpu3" APIC ID = 3 currentldt = 0x50 spin locks held: # -------------------------------------------------------------------- # LOCK LISTING db> show locks db> show alllocks Process 35638 (sendmail) thread 0xd0530600 (101044) exclusive sleep mutex vm object (standard object) r = 0 (0xc9c01318) locked @ /usr/src/sys/vm/vm_map.c:1472 exclusive sx user map r = 0 (0xc8fb7734) locked @ /usr/src/sys/vm/vm_map.c:1208 Process 32836 (rsync) thread 0xc9ec1900 (100360) exclusive sleep mutex pmap r = 0 (0xca89f560) locked @ /usr/src/sys/i386/i386/pmap.c:2041 exclusive sleep mutex vm page queue mutex r = 0 (0xc081d540) locked @ /usr/src/sys/i386/i386/pmap.c:2040 exclusive sx user map r = 0 (0xca89f4e4) locked @ /usr/src/sys/vm/vm_map.c:3105 Process 32754 (httpd) thread 0xcfcc5600 (101170) exclusive sleep mutex vm object (standard object) r = 0 (0xcc8378c4) locked @ /usr/src/sys/vm/vm_fault.c:297 exclusive sx user map r = 0 (0xc984a4e4) locked @ /usr/src/sys/vm/vm_map.c:3105 Process 7829 (bsnmpd) thread 0xca196180 (100409) exclusive sleep mutex vm object (kmem object) r = 0 (0xc081d440) locked @ /usr/src/sys/vm/vm_kern.c:325 exclusive sleep mutex system map r = 0 (0xc1068144) locked @ /usr/src/sys/vm/vm_kern.c:295 exclusive sx sysctl lock r = 0 (0xc07be240) locked @ /usr/src/sys/kern/kern_sysctl.c:1375 exclusive sleep mutex Giant r = 0 (0xc07bdb80) locked @ /usr/src/sys/kern/kern_sysctl.c:1313 Process 3 (g_up) thread 0xc894ec00 (100015) exclusive sleep mutex vm object (standard object) r = 0 (0xcaf6e8c4) locked @ /usr/src/sys/kern/vfs_bio.c:3120 db> show lockedvnods Locked vnodes 0xcdcce6cc: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xcaf6e8c4 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc97f1000 (pid 32710)#0 0xc054d7f1 at lockmgr+0x4ed #1 0xc06a0f96 at ffs_lock+0x76 #2 0xc07170ab at VOP_LOCK_APV+0x87 #3 0xc05bd370 at vn_lock+0xac #4 0xc05b9f0b at getdirentries+0xff #5 0xc07046b3 at syscall+0x25b #6 0xc06efccf at Xint0x80_syscall+0x1f ino 20398955, on dev ad8s1e # -------------------------------------------------------------------- # PROCESS STACK TRACES # SENDMAIL db> trace 35638 Tracing pid 35638 tid 101044 td 0xd0530600 sched_switch(d0530600,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c081d540,c9ec1900,0,c081d540,2,c07497e6,233) at turnstile_wait+0x35a _mtx_lock_sleep(c081d540,d0530600,0,c0768214,5f8) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c081d540,0,c0768214,5f8) at _mtx_lock_flags+0xa2 vm_map_pmap_enter(c8fb76f0,28095000,5,c9c01318,0,0,a000,10) at vm_map_pmap_enter+0x1df vm_map_insert(c8fb76f0,c9c01318,0,0,28095000,2809f000,5,7,112) at vm_map_insert+0x28c vm_map_find(c8fb76f0,c9c01318,0,0,ed810cc8,a000,1,5,7,112) at vm_map_find+0x86 vm_mmap(c8fb76f0,ed810cc8,a000,5,7,20002,2,c9cd0ae0,0,0) at vm_mmap+0x266 mmap(d0530600,ed810d04) at mmap+0x31f syscall(2807003b,2806003b,bfbf003b,28082060,0,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (198, FreeBSD ELF32, nosys), eip = 0x2806cd63, esp = 0xbfbfea7c, ebp = 0xbfbfeab8 --- # RSYNC db> trace 32836 Tracing pid 32836 tid 100360 td 0xc9ec1900 sched_switch(c9ec1900,0,2) at sched_switch+0x177 mi_switch(2,0,c07bdb40,0,c074c42d,...) at mi_switch+0x270 critical_exit(1,c9ec1900,0,9d6f000,bfc275bc,...) at critical_exit+0x8b intr_execute_handlers(c893f6e4,ec552b6c,13,ec552bd4,c06f0033,...) at intr_execute_handlers+0x129 lapic_handle_intr(35) at lapic_handle_intr+0x2e Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc0700897, esp = 0xec552bb0, ebp = 0xec552bd4 --- pmap_enter(ca89f560,9d6f000,c332e380,7,0,ced476b4,0,c0767c8b,383) at pmap_enter+0x1bf vm_fault(ca89f4a0,9d6f000,2,8,c9ec1900,...) at vm_fault+0x10b8 trap_pfault(ec552d38,1,9d6ffb8,9d6ffb8,0,...) at trap_pfault+0xce trap(bfbf003b,3b,bfbf003b,9d6ffb8,0,...) at trap+0x1eb calltrap() at calltrap+0x5 --- trap 0xc, eip = 0x2818527f, esp = 0xbfbf9670, ebp = 0xbfbf9b08 --- # HTTPD db> trace 32754 Tracing pid 32754 tid 101170 td 0xcfcc5600 sched_switch(cfcc5600,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c081d540,c9ec1900,0,c081d540,2,c07497e6,233) at turnstile_wait+0x35a _mtx_lock_sleep(c081d540,cfcc5600,0,c0767c8b,356) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c081d540,0,c0767c8b,356,c07bdb40,...) at _mtx_lock_flags+0xa2 vm_fault(c984a4a0,88d1000,2,8,cfcc5600,...) at vm_fault+0xfa7 trap_pfault(ed840d38,1,88d1d90,88d1d90,0,...) at trap_pfault+0xce trap(80a003b,875003b,bfbf003b,2360,8382000,...) at trap+0x1eb calltrap() at calltrap+0x5 --- trap 0xc, eip = 0x286a34c1, esp = 0xbfbfb860, ebp = 0xbfbfb898 --- # BSNMPD db> trace 7829 Tracing pid 7829 tid 100409 td 0xca196180 sched_switch(ca196180,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c081d540,c9ec1900,0,c081d540,2,c07497e6,233) at turnstile_wait+0x35a _mtx_lock_sleep(c081d540,ca196180,0,c076806c,16f) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c081d540,0,c076806c,16f,10928000,...) at _mtx_lock_flags+0xa2 kmem_malloc(c10680c0,7000,102,ec649b64,c06b330f,...) at kmem_malloc+0x282 page_alloc(0,7000,ec649b57,102) at page_alloc+0x1a uma_large_malloc(7000,102,64f0,c05469d6,ec649bf4,...) at uma_large_malloc+0x3b malloc(64f0,c078fb40,102,c057de5a,ec649bf4,...) at malloc+0xf3 sysctl_jail_list(c078f220,0,0,ec649bf4,c078f220,...) at sysctl_jail_list+0x8e sysctl_root(0,ec649c74,3,ec649bf4) at sysctl_root+0x11b userland_sysctl(ca196180,ec649c74,3,0,bfbfc46c,0,0,0,ec649c70,0,c07bdb80,0,c074b5cd,521) at userland_sysctl+0xf4 __sysctl(ca196180,ec649d04) at __sysctl+0x77 syscall(bfbe003b,2818003b,bfbe003b,3,bfbfc46c,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x2814e77b, esp = 0xbfbfc34c, ebp = 0xbfbfc388 --- # G_UP db> trace 3 Tracing pid 3 tid 100015 td 0xc894ec00 sched_switch(c894ec00,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c081d540,c9ec1900,0,c081d540,2,c07497e6,233) at turnstile_wait+0x35a _mtx_lock_sleep(c081d540,c894ec00,0,c0752afd,c43) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c081d540,0,c0752afd,c43,c06b29a0,...) at _mtx_lock_flags+0xa2 bufdone(dcb814d4) at bufdone+0x176 g_vfs_done(cc0806b4) at g_vfs_done+0x8a biodone(cc0806b4) at biodone+0x58 g_io_schedule_up(c894ec00) at g_io_schedule_up+0xcb g_up_procbody(0,e8216d38,0,c0523700,0,...) at g_up_procbody+0x5a fork_exit(c0523700,0,e8216d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe8216d6c, ebp = 0 --- # EE db> trace 52531 Tracing pid 52531 tid 100453 td 0xca268900 sched_switch(3dc,c074f76f,ec710b90,c0550d8e,c080b7c0,...) at sched_switch+0x177 sellock(c055154c,c07497db,a,c055154c,0,...) at sellock (null)(786574,50414d4b,544e4520,75005952,20726573,...) at 0x9 # SWI4: CLOCK SIO db> trace 14 Tracing pid 14 tid 100002 td 0xc894cc00 sched_switch(c894cc00,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c07bdb80,ca196180,0,c07bdb80,2,c07497e6,233) at turnstile_wait+0x35a _mtx_lock_sleep(c07bdb80,c894cc00,0,c074bcf0,102) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c07bdb80,0,c074bcf0,102) at _mtx_lock_flags+0xa2 softclock(0) at softclock+0x18f ithread_execute_handlers(c894b430,c89a2b80) at ithread_execute_handlers+0xe6 ithread_loop(c89288e0,e81f8d38,c89288e0,c05456e0,0,...) at ithread_loop+0x67 fork_exit(c05456e0,c89288e0,e81f8d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe81f8d6c, ebp = 0 --- # EM0 db> trace 27 Tracing pid 27 tid 100017 td 0xc894e900 sched_switch(c894e900,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c07bdb80,ca196180,0,c07bdb80,2,c07497e6,233) at turnstile_wait+0x35a _mtx_lock_sleep(c07bdb80,c894e900,0,c0747942,2a9) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c07bdb80,0,c0747942,2a9) at _mtx_lock_flags+0xa2 ithread_execute_handlers(c89a4648,c89a1480) at ithread_execute_handlers+0xde ithread_loop(c8a438d0,e8210d38,c8a438d0,c05456e0,0,...) at ithread_loop+0x67 fork_exit(c05456e0,c8a438d0,e8210d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe8210d6c, ebp = 0 --- # em1 db> trace 26 Tracing pid 26 tid 100018 td 0xc894e780 sched_switch(c894e780,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c07bdb80,ca196180,0,c07bdb80,2,c07497e6,233) at turnstile_wait+0x35a _mtx_lock_sleep(c07bdb80,c894e780,0,c0747942,2a9) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c07bdb80,0,c0747942,2a9) at _mtx_lock_flags+0xa2 ithread_execute_handlers(c89a4860,c89a1500) at ithread_execute_handlers+0xde ithread_loop(c8a3f6a0,e820dd38,c8a3f6a0,c05456e0,0,...) at ithread_loop+0x67 fork_exit(c05456e0,c8a3f6a0,e820dd38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe820dd6c, ebp = 0 --- # LYNX db> trace 33070 Tracing pid 33070 tid 100668 td 0xca02f600 sched_switch(ca02f600,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c07bdb80,ca196180,0,c07bdb80,2,c07497e6,233) at turnstile_wait+0x35a _mtx_lock_sleep(c07bdb80,ca02f600,0,c074fb3c,ec) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c07bdb80,0,c074fb3c,ec) at _mtx_lock_flags+0xa2 soo_poll(d015b000,40,d06e1b80,ca02f600) at soo_poll+0x2a selscan(ca02f600,ec5d5b94,ec5d5b84,14,c080b7c0,0,c074f76f,300) at selscan+0x1a5 kern_select(ca02f600,14,bfbfe304,0,0,...) at kern_select+0x33b select(ca02f600,ec5d5d04) at select+0x44 syscall(3b,bfbf003b,bfbf003b,0,bfbfe304,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (93, FreeBSD ELF32, select), eip = 0x281e6be4, esp = 0xbfbfe2a8, ebp = 0xbfbfe384 --- -------------- next part -------------- # # RACK2 -- M2 config file # machine i386 cpu I686_CPU ident RACK2 # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options SMP options FAST_IPSEC options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options KDB options KDB_TRACE options KDB_UNATTENDED options DDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN options DIAGNOSTIC options BREAK_TO_DEBUGGER options DEBUG_LOCKS options DEBUG_VFS_LOCKS device crypto device apic # I/O APIC # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx devices #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device arcmsr # Areca SATA II RAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device hptmv # Highpoint RocketRAID 182x #device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx #device rr232x # Highpoint RocketRAID 232x #device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID #device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mfi # LSI MegaRAID SAS #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pccard # PC Card (16-bit) bus #device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port #device ppc #device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet #device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device lge # Level 1 LXT1001 gigabit Ethernet #device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet #device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking #device pcn # AMD Am79C97x PCI 10/100(precedence over 'lnc') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device stge # Sundance/Tamarack TC9021 gigabit Ethernet #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. device lnc # NE2100, NE32-VL Lance Ethernet cards #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # Wireless NIC cards #device wlan # 802.11 support #device wlan_wep # 802.11 WEP support #device wlan_ccmp # 802.11 CCMP support #device wlan_tkip # 802.11 TKIP support #device an # Aironet 4500/4800 802.11 wireless NICs. #device ath # Atheros pci/cardbus NIC's #device ath_hal # Atheros HAL (Hardware Access Layer) #device ath_rate_sample # SampleRate tx rate control for ath #device awi # BayStack 660 and others #device ral # Ralink Technology RT2500 wireless NICs. #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device ehci # EHCI PCI->USB interface (USB 2.0) #device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device ural # Ralink Technology RT2500USB wireless NICs #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Ethernet, requires miibus #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cdce # Generic USB over Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) From lev at FreeBSD.org Sun Jun 15 15:27:20 2008 From: lev at FreeBSD.org (Lev Serebryakov) Date: Sun Jun 15 15:27:27 2008 Subject: UPS shutdown with `sysutils/nut': where should I place "power off" command to UPS? Message-ID: <1283529703.20080615190810@serebryakov.spb.ru> Hello, freebsd-hackers. nut's documentation says[1], that UPS should be switched off from shutdown scripts in point, when FSes are synced and re-mounted as R/O. google shows thread[2], according to which, last line of `/etc/rc.shutdown' is too early, and if power will be switched off at this line, FSes will be dirty on boot. What is proper place for "power off" command on FreeBSD system? Please, note, that it is NOT `shutdown -p', but signal to UPS to switch off EXTERNAL power when battarey is almost dead, and no external power, and `shutdown -p' turns off only computer, not UPS. [1] http://www.networkupstools.org/doc/2.2.0/shutdown.html [2] http://lists.freebsd.org/pipermail/freebsd-questions/2006-May/122764.htm -- // Black Lion AKA Lev Serebryakov From ertr1013 at student.uu.se Sun Jun 15 16:37:59 2008 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Sun Jun 15 16:38:03 2008 Subject: UPS shutdown with `sysutils/nut': where should I place "power off" command to UPS? In-Reply-To: <1283529703.20080615190810@serebryakov.spb.ru> References: <1283529703.20080615190810@serebryakov.spb.ru> Message-ID: <20080615162247.GA50613@owl.midgard.homeip.net> On Sun, Jun 15, 2008 at 07:08:10PM +0400, Lev Serebryakov wrote: > Hello, freebsd-hackers. > > nut's documentation says[1], that UPS should be switched off from > shutdown scripts in point, when FSes are synced and re-mounted as R/O. Problem is, on FreeBSD the FSes are not re-mounted as R/O during shutdown. > > google shows thread[2], according to which, last line of > `/etc/rc.shutdown' is too early, and if power will be switched off at > this line, FSes will be dirty on boot. Correct. > > What is proper place for "power off" command on FreeBSD system? There isn't any. On FreeBSD the filesystems are synced and marked as clean by the kernel, *after* all the shutdown scripts have finished. (Unlike Linux where the shutdown scripts are responsible for syncing and umounting/re-mounting the file systems.) > > Please, note, that it is NOT `shutdown -p', but signal to UPS to > switch off EXTERNAL power when battarey is almost dead, and no > external power, and `shutdown -p' turns off only computer, not UPS. You need an UPS that can accept a signal that says 'shut down in 20 seconds time' (the value 20 may have to be adjusted) and send that as the last thing in the shutdown scripts, which should cause the UPS to shutdown shortly after 'shutdown -p' has turned off the computer. > > > [1] http://www.networkupstools.org/doc/2.2.0/shutdown.html > [2] http://lists.freebsd.org/pipermail/freebsd-questions/2006-May/122764.htm > -- Erik Trulsson ertr1013@student.uu.se From lev at serebryakov.spb.ru Sun Jun 15 17:07:20 2008 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Sun Jun 15 17:07:25 2008 Subject: UPS shutdown with `sysutils/nut': where should I place "power off" command to UPS? In-Reply-To: <20080615162247.GA50613@owl.midgard.homeip.net> References: <1283529703.20080615190810@serebryakov.spb.ru> <20080615162247.GA50613@owl.midgard.homeip.net> Message-ID: <31567013.20080615204738@serebryakov.spb.ru> Hello, Erik. You wrote 15 ???? 2008 ?., 20:22:47: > You need an UPS that can accept a signal that says 'shut down in 20 seconds > time' (the value 20 may have to be adjusted) and send that as the last thing > in the shutdown scripts, which should cause the UPS to shutdown shortly > after 'shutdown -p' has turned off the computer. It seems, that my Ippon Smart Power Pro/1000 understand such commands: it can turn off load after 2 minutes, and I'll try to change this value. Great. -- // Black Lion AKA Lev Serebryakov From gabor at FreeBSD.org Sun Jun 15 19:16:24 2008 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Sun Jun 15 19:16:29 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <4854BC29.3060507@FreeBSD.org> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> Message-ID: <48556A83.1080208@FreeBSD.org> Doug Barton escribi?: > I use the following construct in portmaster, where pdb=/var/db/pkg, > origin is set to the origin of a given port, and ro_opd is usually > empty, but can be another origin directory or the same one. To > guarantee that you should get some kind of results you can test with > origin=devel/gettext. > > egrep -l "DEPORIGIN:($origin|$ro_opd)$" $pdb/*/+CONTENTS > > Obviously this works in portmaster with the gnu grep, but if ro_opd is > unset with the bsd grep I get: > > egrep: empty (sub)expression > > If I set ro_opd to something, it works. Hello Doug, thanks a lot for you response! I'll look at this issue. Regards, -- Gabor Kovesdan EMAIL: gabor@FreeBSD.org WWW: http://www.kovesdan.org From stas at FreeBSD.org Sun Jun 15 19:20:00 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Sun Jun 15 19:20:03 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <20080614190351.4ec7660d@baby-jane-lamaiziere-net.local> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080614190351.4ec7660d@baby-jane-lamaiziere-net.local> Message-ID: <20080615231953.35a908e9.stas@FreeBSD.org> On Sat, 14 Jun 2008 19:03:51 +0200 Patrick Lamaizi?re mentioned: > > Sources (7-STABLE): > http://user.lamaiziere.net/patrick/glxsb-140608.tar.gz > > (Yes this is the good version!) > > If you can test it and provide some review it would be nice. > Small note about the manpage: I think we don't need the netbsd porting information in AUTHORS section, also you missed a dot in the end of last sentence in HISTORY section. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080615/2dd16fe3/attachment.pgp From gabor at t-hosting.hu Sun Jun 15 19:30:49 2008 From: gabor at t-hosting.hu (=?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?=) Date: Sun Jun 15 20:05:40 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <4854C96A.1080603@aueb.gr> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> Message-ID: <48556AAD.9010602@t-hosting.hu> Diomidis Spinellis escribi?: > Doug Barton wrote: >> I use the following construct in portmaster, where pdb=/var/db/pkg, >> origin is set to the origin of a given port, and ro_opd is usually >> empty, but can be another origin directory or the same one. To >> guarantee that you should get some kind of results you can test with >> origin=devel/gettext. >> >> egrep -l "DEPORIGIN:($origin|$ro_opd)$" $pdb/*/+CONTENTS >> >> Obviously this works in portmaster with the gnu grep, but if ro_opd >> is unset with the bsd grep I get: >> >> egrep: empty (sub)expression > > To avoid these problems I had proposed to instrument getopt to write > options passed through argv in a file, build all our ports, and look > at the options used. Yes, of course, I haven't forgotten about your suggestion. First, I'd like to process the trivial errors, which come up like this one and make some tests myself. Then I'll think about this idea and ask portmgr to do an exp-run with BSD grep. Regards, -- Gabor Kovesdan EMAIL: gabor@FreeBSD.org WWW: http://www.kovesdan.org From ache at nagual.pp.ru Sun Jun 15 21:41:53 2008 From: ache at nagual.pp.ru (Andrey Chernov) Date: Sun Jun 15 21:49:53 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <48556AAD.9010602@t-hosting.hu> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> Message-ID: <20080615212613.GA97326@nagual.pp.ru> On Sun, Jun 15, 2008 at 09:17:01PM +0200, K?vesd?n G?bor wrote: > > Yes, of course, I haven't forgotten about your suggestion. First, I'd > like to process the trivial errors, which come up like this one and make > some tests myself. Then I'll think about this idea and ask portmgr to do > an exp-run with BSD grep. Please note that BSD grep is not localized (and can't be per design) and works only with standard C locale. It may not affect ports system processing but shurely affects real texts handling. -- http://ache.pp.ru/ From yanefbsd at gmail.com Mon Jun 16 04:11:38 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Mon Jun 16 04:11:44 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <20080615212613.GA97326@nagual.pp.ru> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> Message-ID: <7d6fde3d0806152111t3306279dr841b90740141fcfb@mail.gmail.com> On Sun, Jun 15, 2008 at 2:26 PM, Andrey Chernov wrote: > On Sun, Jun 15, 2008 at 09:17:01PM +0200, K?vesd?n G?bor wrote: >> >> Yes, of course, I haven't forgotten about your suggestion. First, I'd >> like to process the trivial errors, which come up like this one and make >> some tests myself. Then I'll think about this idea and ask portmgr to do >> an exp-run with BSD grep. > > Please note that BSD grep is not localized (and can't be per design) and > works only with standard C locale. It may not affect ports system > processing but shurely affects real texts handling. Kudos on the hard work Gabor. Now all we need to do is write / import a BSD compatible less(1) into FreeBSD =). -Garrett From dougb at FreeBSD.org Mon Jun 16 04:37:23 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Jun 16 04:37:29 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <20080615212613.GA97326@nagual.pp.ru> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> Message-ID: <4855EDFE.3010708@FreeBSD.org> Andrey Chernov wrote: > On Sun, Jun 15, 2008 at 09:17:01PM +0200, K?vesd?n G?bor wrote: >> Yes, of course, I haven't forgotten about your suggestion. First, I'd >> like to process the trivial errors, which come up like this one and make >> some tests myself. Then I'll think about this idea and ask portmgr to do >> an exp-run with BSD grep. I think that would be very valuable. > Please note that BSD grep is not localized (and can't be per design) and > works only with standard C locale. It may not affect ports system > processing but shurely affects real texts handling. That is very troubling. In this day and age localization is a requirement. I cannot imagine being supportive of adding something to the base that does not have this capability. I also found another gratuitous difference in behavior tonight, again from portmaster (which uses grep a LOT, which is why I thought to try it out in the first place). I do this type of thing in lots of places: pkg=/var/db/pkg/p5-Net-DNS-0.63 if grep -ql '^@pkgdep ' $pkg/+CONTENTS 2>/dev/null; then fi With gnu grep I get no output, and if there is a match the if statement just runs as I'd expect. With bsd grep I'm getting the name of the file as output. That's 3 strikes and you're out as far as I'm concerned. I think this project needs to come a lot closer to feature compatibility with gnu grep (including the ability to be localized) before it's ready for a wider audience. Of course, that's just my opinion. Doug -- This .signature sanitized for your protection From lichave at gmail.com Mon Jun 16 07:44:27 2008 From: lichave at gmail.com (Konrad Jankowski) Date: Mon Jun 16 07:44:33 2008 Subject: FreeBSD hotplugging (Hal) info In-Reply-To: <4854087F.90509@telenix.org> References: <4852C94B.2090809@telenix.org> <4854087F.90509@telenix.org> Message-ID: <716a8d5f0806160017y23a29fd4r20190e8b8a198a6@mail.gmail.com> > Replying to my own mail, I realize I've worded this badly ... what I meant is, > does any part of FreeBSD's base make any use of Hal's (the hardware abstraction > layer) API? If it does, and you could tell me where that is (because I can't Base definitely doesn't use it. All you can find in base is devd. From stef-list at memberwebs.com Mon Jun 16 11:10:35 2008 From: stef-list at memberwebs.com (Stef Walter) Date: Mon Jun 16 11:10:44 2008 Subject: FreeBSD 6.3 deadlock (interrupted pmap_remove_pages) with DDB output References: <20080615112318.146C1F18512@mx.npubs.com> Message-ID: <20080616111032.E194BF181D4@mx.npubs.com> Stef Walter wrote: > I've been trying to track down a deadlock on some newish production > servers running FreeBSD 6.3-RELEASE-p2. The deadlock occurs on a > specific (although mundane) hardware configuration, and each of several > servers running this hardware deadlock about once per week. > > Although I suspect that this is not hardware related, from a (naive) > perusal of the attached stack traces. Here's another similar deadlock that occurred on an similar machine. Last time pmap_enter was preempted by an interrupt, this time pmap_remove_pages was preempted by a timer. I tried changing machdep.cpu_idle_hlt to zero, based on a hint [1], but that didn't seem to make a difference. Again in this case the processes are waiting on the page queue mutex: python (in trap > trap_pfault > vm_fault) rsync (in ... cluster_read > getblk > getnewbuf > vfs_vmio_release) And another rsync process is holding the vm page queue mutex: rsync (in exit1 > vmspace_exit > pmap_remove_pages) The rsync process in pmap_remove_pages was interrupted by a timer while holding the vm page queue lock and then was not scheduled again. Kernel config and full details attched. I may try building the kernel without PREEMPTION to see if it fixes this problem. Again, any and all advice or hints are welcome. I really appreciate any time spent on this. Stef Walter [1] http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2005-02/0508.html -------------- next part -------------- # # RACK1 # machine i386 cpu I686_CPU ident RACK1 # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic # I/O APIC options SMP options QUOTA options FAST_IPSEC options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE options IPFIREWALL_FORWARD options IPDIVERT options DUMMYNET options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options KDB options KDB_TRACE options KDB_UNATTENDED options DDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN options DIAGNOSTIC options BREAK_TO_DEBUGGER options DEBUG_LOCKS options DEBUG_VFS_LOCKS device crypto # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. #device ahd # AHA39320/29320 and onboard AIC79xx devices #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD #device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device arcmsr # Areca SATA II RAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device hptmv # Highpoint RocketRAID 182x #device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx #device rr232x # Highpoint RocketRAID 232x device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID #device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mfi # LSI MegaRAID SAS #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pccard # PC Card (16-bit) bus #device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port #device ppc #device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card #device ixgb # Intel PRO/10GbE Ethernet Card #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet #device bfe # Broadcom BCM440x 10/100 Ethernet #device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device lge # Level 1 LXT1001 gigabit Ethernet #device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet #device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking #device pcn # AMD Am79C97x PCI 10/100(precedence over 'lnc') #device re # RealTek 8139C+/8169/8169S/8110S #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device stge # Sundance/Tamarack TC9021 gigabit Ethernet #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vge # VIA VT612x gigabit Ethernet #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. #device lnc # NE2100, NE32-VL Lance Ethernet cards #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # Wireless NIC cards #device wlan # 802.11 support #device wlan_wep # 802.11 WEP support #device wlan_ccmp # 802.11 CCMP support #device wlan_tkip # 802.11 TKIP support #device an # Aironet 4500/4800 802.11 wireless NICs. #device ath # Atheros pci/cardbus NIC's #device ath_hal # Atheros HAL (Hardware Access Layer) #device ath_rate_sample # SampleRate tx rate control for ath #device awi # BayStack 660 and others #device ral # Ralink Technology RT2500 wireless NICs. #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support #device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device ehci # EHCI PCI->USB interface (USB 2.0) #device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device ural # Ralink Technology RT2500USB wireless NICs #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Ethernet, requires miibus #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cdce # Generic USB over Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) -------------- next part -------------- # -------------------------------------------------------------------- # FREEBSD BUILD FreeBSD m1.npubs.com 6.3-RELEASE-p2 FreeBSD 6.3-RELEASE-p2 #0: Tue Jun 10 02:07:06 UTC 2008 nate@m1.npubs.com:/usr/obj/usr/src/sys/RACK1DBG i386 # -------------------------------------------------------------------- # PROCESS LIST db> ps pid ppid pgrp uid state wmesg wchan cmd 69677 69671 4145 65534 LLJ *vm page 0xcf2cc140 python 69674 69654 69486 0 RE rsync 69671 69670 4145 65534 SJ piperd 0xca44a660 python 69670 4145 4145 65534 SJ wait 0xcf673430 sh 69669 4684 4684 125 SJ select 0xc07b7ce4 smtpd 69668 69664 69664 0 S select 0xc07b7ce4 rsync 69664 5663 69664 0 Ls *vm page 0xcf2cc140 rsync 69654 69511 69486 0 S wait 0xca033c90 sh 69561 45988 45982 70 SJ sbwait 0xcabb4bc8 postgres 69557 4141 4141 125 SJ select 0xc07b7ce4 smtp 69541 4141 4141 125 SJ select 0xc07b7ce4 cleanup 69540 4141 4141 125 SJ select 0xc07b7ce4 smtpd 69535 4141 4141 125 SJ select 0xc07b7ce4 trivial-rewrite 69533 4141 4141 125 SJ select 0xc07b7ce4 anvil 69523 4141 4141 125 SJ select 0xc07b7ce4 proxymap 69511 69498 69486 0 S wait 0xc92e7430 sh 69510 4141 4141 125 SJ select 0xc07b7ce4 smtpd 69504 69495 69495 0 SJ sbwait 0xcf2b1638 python 69498 69486 69486 0 S wait 0xca67b648 sh 69495 69492 69495 0 SsJ wait 0xcf6aa218 sh 69492 1374 1374 0 SJ piperd 0xc91c8198 cron 69486 69484 69486 0 Ss wait 0xc92e4c90 sh 69484 691 691 0 S piperd 0xc901b990 cron 69455 1 69455 0 Ls *Giant 0xcf52b6c0 jail-measure 69434 1940 1940 125 SJ kqread 0xc9987a00 trivial-rewrite 69415 1940 1940 0 SJ kqread 0xc9b21700 local 69414 1940 1940 125 SJ kqread 0xca77a600 smtpd 69413 1940 1940 125 SJ kqread 0xc988ee00 smtp 69412 1940 1940 125 SJ kqread 0xcf87b900 cleanup 69400 4684 4684 0 SJ select 0xc07b7ce4 virtual 69379 45988 45982 70 SJ sbwait 0xd0b004d4 postgres 69374 45988 45982 70 SJ sbwait 0xc8f7579c postgres 69372 45988 45982 70 SJ sbwait 0xd08a2d2c postgres 69361 2260 2260 80 SJ accept 0xc97fe5ca httpd 69352 1940 1940 125 SJ lockf 0xc94529c0 smtpd 69335 45988 45982 70 SJ sbwait 0xcf2d5900 postgres 69327 1940 1940 125 SJ lockf 0xc9452740 bounce 69326 1940 1940 125 SJ kqread 0xd0080100 bounce 69276 1940 1940 125 SJ lockf 0xcf5158c0 smtp 69274 1940 1940 125 SJ kqread 0xca333800 smtp 69256 45988 45982 70 SJ sbwait 0xc8ce5638 postgres 69245 45988 45982 70 SJ sbwait 0xc9e23bc8 postgres 69240 45988 45982 70 SJ sbwait 0xd0ad379c postgres 69208 4684 4684 125 SJ select 0xc07b7ce4 smtp 69184 4684 4684 125 SJ select 0xc07b7ce4 smtpd 69183 4684 4684 125 SJ select 0xc07b7ce4 smtp 69182 4684 4684 125 SJ select 0xc07b7ce4 cleanup 69175 1940 1940 125 SJ kqread 0xc993ba00 smtpd 69174 4684 4684 125 SJ select 0xc07b7ce4 trivial-rewrite 69141 45988 45982 70 SJ sbwait 0xd0b030a8 postgres 68996 45988 45982 70 SJ sbwait 0xcf2b1e90 postgres 68790 2260 2260 80 SJ accept 0xc97fe5ca httpd 68693 1940 1940 125 SJ kqread 0xcbf11a00 anvil 68338 4557 4557 125 SJ select 0xc07b7ce4 imapd 68262 45988 45982 70 SJ sbwait 0xc9f54900 postgres 68199 4557 4557 125 SJ select 0xc07b7ce4 imapd 68189 45988 45982 70 SJ sbwait 0xd0afd0a8 postgres 67971 4684 4684 125 SJ select 0xc07b7ce4 proxymap 67135 4684 4684 125 SJ select 0xc07b7ce4 pickup 67085 4557 4557 125 SJ select 0xc07b7ce4 imapd 66421 45988 45982 70 SJ sbwait 0xd0ac9900 postgres 64620 1940 1940 125 SJ kqread 0xcbfa9400 pickup 63268 45988 45982 70 SJ sbwait 0xd0af9d2c postgres 62647 45988 45982 70 SJ sbwait 0xc9f23370 postgres 62453 45988 45982 70 SJ sbwait 0xc8d6379c postgres 62324 4141 4141 125 SJ select 0xc07b7ce4 pickup 59910 2260 2260 80 SJ accept 0xc97fe5ca httpd 58656 3815 3815 80 SJ accept 0xc986d892 httpd 58655 3815 3815 80 SJ accept 0xc986d892 httpd 58641 3815 3815 80 SJ accept 0xc986d892 httpd 58523 2260 2260 80 SJ accept 0xc97fe5ca httpd 58520 2260 2260 80 SJ accept 0xc97fe5ca httpd 58398 2260 2260 80 SJ accept 0xc97fe5ca httpd 57936 2260 2260 80 SJ accept 0xc97fe5ca httpd 55518 2260 2260 80 SJ accept 0xc97fe5ca httpd 49914 2260 2260 80 SJ accept 0xc97fe5ca httpd 46007 1 46007 0 SsJ nanslp 0xc076a96c cron 45999 1 45999 0 SsJ select 0xc07b7ce4 inetd 45993 45992 45982 70 S+J select 0xc07b7ce4 postgres 45992 45988 45982 70 S+J select 0xc07b7ce4 postgres 45991 45988 45982 70 S+J select 0xc07b7ce4 postgres 45989 45988 45982 70 S+J select 0xc07b7ce4 postgres 45988 1 45982 70 S+J select 0xc07b7ce4 postgres 45983 45958 45957 88 S+J (threaded) mysqld 100467 S kserel 0xcf638694 mysqld 100473 S kserel 0xcf638694 mysqld 100358 S kserel 0xcf638694 mysqld 100362 S kserel 0xcf638694 mysqld 100355 S select 0xc07b7ce4 mysqld 100948 S kserel 0xd092cc94 mysqld 100949 S sigwait 0xec446c14 mysqld 100938 S ksesigwa 0xcf6aabb0 mysqld 45958 1 45957 88 S+J wait 0xcf644000 sh 45942 1 45942 0 SsJ select 0xc07b7ce4 sshd 45876 1 45876 0 SsJ select 0xc07b7ce4 syslogd 33626 2260 2260 80 SJ accept 0xc97fe5ca httpd 23070 1336 1336 80 SJ lockf 0xd0401e40 httpd 23069 1336 1336 80 SJ kqread 0xca0be100 httpd 23057 1336 1336 80 SJ lockf 0xcf515680 httpd 22000 1336 1336 80 SJ lockf 0xc9c80380 httpd 21992 1336 1336 80 SJ lockf 0xcf515dc0 httpd 20343 1336 1336 80 SJ lockf 0xc91dd200 httpd 20342 1336 1336 80 SJ lockf 0xd0458ac0 httpd 20341 3815 3815 80 SJ accept 0xc986d892 httpd 20340 1336 1336 80 SJ lockf 0xd0401140 httpd 20339 3815 3815 80 SJ accept 0xc986d892 httpd 20337 1336 1336 80 SJ lockf 0xd0458800 httpd 20336 3815 3815 80 SJ accept 0xc986d892 httpd 20335 3815 3815 80 SJ accept 0xc986d892 httpd 20334 1336 1336 80 SJ lockf 0xcf4eb280 httpd 20333 3815 3815 80 SJ accept 0xc986d892 httpd 20324 20323 20323 0 SJ piperd 0xd02164c8 sockin 20323 4456 20323 0 SsJ wait 0xd092e430 sh 78897 0 0 0 SL ipmireq 0xcf93bec0 [ipmi0: kcs] 65042 64222 64222 70 SJ sbwait 0xcf0f14d4 postgres 64780 64222 64222 70 SJ sbwait 0xcabb4900 postgres 64778 64222 64222 70 SJ sbwait 0xd0af10a8 postgres 64777 64222 64222 70 SJ sbwait 0xc8f96370 postgres 64769 64222 64222 70 SJ sbwait 0xca43e20c postgres 64768 64222 64222 70 SJ sbwait 0xc9a26900 postgres 64767 64222 64222 70 SJ sbwait 0xd0afd4d4 postgres 64742 64222 64222 70 SJ sbwait 0xd0afb638 postgres 64666 64222 64222 70 SJ sbwait 0xccb3579c postgres 64665 64222 64222 70 SJ sbwait 0xd0afc20c postgres 64664 64222 64222 70 SJ sbwait 0xc9e4979c postgres 64663 64222 64222 70 SJ sbwait 0xd05c0e90 postgres 64662 64222 64222 70 SJ sbwait 0xd0ad3d2c postgres 64661 64222 64222 70 SJ sbwait 0xca39a79c postgres 64484 64222 64222 70 SJ sbwait 0xc8d6a370 postgres 64414 64222 64222 70 SJ sbwait 0xc9f2379c postgres 64361 64222 64222 70 SJ sbwait 0xd08a1370 postgres 64349 64222 64222 70 SJ sbwait 0xd05c8370 postgres 64348 64222 64222 70 SJ sbwait 0xcc9b70a8 postgres 64332 64222 64222 70 SJ sbwait 0xd0509a64 postgres 64331 64222 64222 70 SJ sbwait 0xc9a2679c postgres 64227 64226 64222 70 SJ select 0xc07b7ce4 postgres 64226 64222 64222 70 SJ select 0xc07b7ce4 postgres 64225 64222 64222 70 SJ select 0xc07b7ce4 postgres 64223 64222 64222 70 SJ select 0xc07b7ce4 postgres 64222 1 64222 70 SsJ select 0xc07b7ce4 postgres 43040 1114 43040 70 SsJ sbwait 0xca50b370 postgres 75907 4167 4167 1003 RJ CPU 0 stunnel 46911 1 46911 0 SsJ nanslp 0xc076a96c cron 46904 1 46904 0 SsJ select 0xc07b7ce4 sshd 46880 1 46880 0 SsJ (threaded) pdns_server 100752 S kserel 0xcf45e0f4 pdns_server 100748 S kserel 0xcf45e0f4 pdns_server 100695 S kserel 0xcf45e0f4 pdns_server 100171 S kserel 0xcf45e0f4 pdns_server 100464 S sbwait 0xcf7be638 pdns_server 100572 S sbwait 0xca872370 pdns_server 100836 S accept 0xcac13e22 pdns_server 100834 S select 0xc07b7ce4 pdns_server 100784 S ksesigwa 0xcf564bb0 pdns_server 46845 1 46845 389 SsJ (threaded) slapd 100729 S kserel 0xcf638454 slapd 100750 S kserel 0xcf638454 slapd 100747 S select 0xc07b7ce4 slapd 100630 S kserel 0xcf638454 slapd 100512 S kserel 0xcf638454 slapd 100733 S ksesigwa 0xcf6ab998 slapd 46825 1 46825 0 SsJ select 0xc07b7ce4 syslogd 68366 5772 5772 70 SJ sbwait 0xcabb379c postgres 57454 5772 5772 70 SJ sbwait 0xca4124d4 postgres 94638 5772 5772 70 SJ sbwait 0xc9f22bc8 postgres 94626 5772 5772 70 SJ sbwait 0xd052ee90 postgres 85402 5800 5800 80 SJ accept 0xc9cf4892 httpd 85398 5772 5772 70 SJ sbwait 0xceb45e90 postgres 85396 5772 5772 70 SJ sbwait 0xca4b4638 postgres 71130 1114 71130 70 SsJ sbwait 0xc9eeaa64 postgres 71129 1114 71129 70 SsJ sbwait 0xcf2b0bc8 postgres 71128 1114 71128 70 SsJ sbwait 0xc9e484d4 postgres 71127 1114 71127 70 SsJ sbwait 0xcf7bd20c postgres 71126 1114 71126 70 SsJ sbwait 0xc8f76900 postgres 71115 1114 71115 70 SsJ sbwait 0xca50ce90 postgres 71081 71080 71080 89 SJ (threaded) java 100360 S kserel 0xcf5dbe74 java 100255 S kserel 0xcf5dbe74 java 100722 S select 0xc07b7ce4 java 100746 S kserel 0xcf5dbe74 java 100505 S kserel 0xcf5dbe74 java 100409 S sbwait 0xceb88bc8 java 100718 S sbwait 0xca609900 java 100163 S sbwait 0xcf7be79c java 100518 S sbwait 0xca6094d4 java 100778 S sbwait 0xca609370 java 100258 S sbwait 0xc93454d4 java 100506 S ksesigwa 0xcf6ad780 java 71080 1 71080 0 SsJ select 0xc07b7ce4 udb-server 18181 2388 2388 80 SJ accept 0xc986d19e httpd 16803 2388 2388 80 SJ accept 0xc986d19e httpd 16802 2388 2388 80 SJ accept 0xc986d19e httpd 16801 2388 2388 80 SJ accept 0xc986d19e httpd 16795 2388 2388 80 SJ accept 0xc986d19e httpd 7788 5772 5772 70 SJ sbwait 0xc9e240a8 postgres 7723 5772 5772 70 SJ sbwait 0xcabb620c postgres 7705 5772 5772 70 SJ sbwait 0xca8dc370 postgres 7703 5800 5800 80 SJ accept 0xc9cf4892 httpd 7700 5800 5800 80 SJ accept 0xc9cf4892 httpd 7699 5772 5772 70 SJ sbwait 0xca39aa64 postgres 7696 5772 5772 70 SJ sbwait 0xc9cf3638 postgres 7694 5800 5800 80 SJ accept 0xc9cf4892 httpd 6376 4141 4141 125 SJ select 0xc07b7ce4 tlsmgr 5969 3438 3438 80 SJ lockf 0xce4036c0 httpd 5968 3438 3438 80 SJ lockf 0xcaf5dcc0 httpd 5966 3438 3438 80 SJ select 0xc07b7ce4 httpd 5962 3438 3438 80 SJ lockf 0xc94524c0 httpd 5854 5772 5772 70 SJ sbwait 0xca314638 postgres 5852 5800 5800 80 SJ accept 0xc9cf4892 httpd 5851 5800 5800 80 SJ accept 0xc9cf4892 httpd 5850 5800 5800 80 SJ accept 0xc9cf4892 httpd 5849 5800 5800 80 SJ accept 0xc9cf4892 httpd 5848 5800 5800 80 SJ accept 0xc9cf4892 httpd 5827 5826 5826 1020 SJ (threaded) java 100390 S kserel 0xc8e0b034 java 100475 S kserel 0xc8e0b034 java 100418 S kserel 0xc8e0b034 java 100389 S select 0xc07b7ce4 java 100180 S kserel 0xc8e0b034 java 100400 S sbwait 0xc9e49a64 java 100812 S sbwait 0xc9f5420c java 100382 S sbwait 0xc9f54e90 java 100394 S sbwait 0xc9cf3900 java 100388 S sbwait 0xca314370 java 100398 S sbwait 0xca02f370 java 100386 S ksesigwa 0xc8e0d138 java 5826 1 5826 0 SsJ select 0xc07b7ce4 udb-server 5819 1 5819 0 SsJ nanslp 0xc076a96c cron 5812 1 5812 0 SsJ select 0xc07b7ce4 sshd 5809 5805 5800 0 SJ piperd 0xc9cfb7f8 cronolog 5808 5803 5800 0 SJ piperd 0xc9e44b28 cronolog 5805 5800 5800 0 SJ wait 0xc969aa78 sh 5803 5800 5800 0 SJ wait 0xca033648 sh 5800 1 5800 0 SsJ nanslp 0xc076a96c httpd 5788 5787 5772 70 SJ select 0xc07b7ce4 postgres 5787 5772 5772 70 SJ select 0xc07b7ce4 postgres 5786 5772 5772 70 SJ select 0xc07b7ce4 postgres 5772 1 5772 70 SsJ select 0xc07b7ce4 postgres 5713 1 5713 0 SsJ select 0xc07b7ce4 syslogd 5704 1 5704 0 Ss+ ttyin 0xc8a61410 getty 5703 1 5703 0 Ss+ ttyin 0xc8a69c10 getty 5702 1 5702 0 Ss+ ttyin 0xc8a6c010 getty 5701 1 5701 0 Ss+ ttyin 0xc8a6b010 getty 5700 1 5700 0 Ss+ ttyin 0xc8a6a410 getty 5699 1 5699 0 Ss+ ttyin 0xc8a6a810 getty 5698 1 5698 0 Ss+ ttyin 0xc8a60810 getty 5697 1 5697 0 Ss+ ttyin 0xc8a6c410 getty 5696 1 5696 0 Ss+ ttyin 0xc8a6b410 getty 5675 1 5675 0 Ss select 0xc07b7ce4 bsnmpd 5663 1 5663 0 Ss select 0xc07b7ce4 inetd 5443 5442 5442 1020 SJ (threaded) java 100223 S kserel 0xc998b874 java 100095 S kserel 0xc998b874 java 100385 S sbwait 0xd0509978 java 100414 S sbwait 0xd089e814 java 100699 S kserel 0xc998b874 java 100187 S kserel 0xc998b874 java 100229 S select 0xc07b7ce4 java 100736 S sbwait 0xd025379c java 100157 S sbwait 0xc9644f08 java 100338 S ksesigwa 0xc998abb0 java 5442 1 5442 0 SsJ select 0xc07b7ce4 udb-server 5435 1 5435 0 SsJ nanslp 0xc076a96c cron 5419 1 5419 0 SsJ select 0xc07b7ce4 sshd 5265 1 5265 0 SsJ select 0xc07b7ce4 syslogd 4960 1 4960 0 SsJ nanslp 0xc076a96c cron 4953 1 4953 0 SsJ select 0xc07b7ce4 sshd 4906 1 4906 53 SsJ select 0xc07b7ce4 named 4891 1 4891 0 SsJ select 0xc07b7ce4 syslogd 4834 4684 4684 125 SJ select 0xc07b7ce4 anvil 4789 4684 4684 125 SJ select 0xc07b7ce4 tlsmgr 4709 1 4709 0 SsJ nanslp 0xc076a96c cron 4699 1 4699 0 SsJ accept 0xc9dfae22 saslauthd1 4691 4684 4684 125 SJ select 0xc07b7ce4 qmgr 4684 1 4684 0 SsJ select 0xc07b7ce4 master 4598 1 4598 0 SsJ select 0xc07b7ce4 rpc.dracd 4585 4584 4585 0 S+J select 0xc07b7ce4 couriertcpd 4584 1 4584 0 S+J piperd 0xc9cb6b28 courierlogger 4581 4532 4531 0 S+J select 0xc07b7ce4 authdaemond 4579 4532 4531 0 S+J select 0xc07b7ce4 authdaemond 4578 4532 4531 0 S+J select 0xc07b7ce4 authdaemond 4577 4532 4531 0 S+J select 0xc07b7ce4 authdaemond 4576 4532 4531 0 S+J select 0xc07b7ce4 authdaemond 4569 4568 4569 0 S+J select 0xc07b7ce4 couriertcpd 4568 1 4568 0 S+J piperd 0xc8e04330 courierlogger 4557 4556 4557 0 S+J select 0xc07b7ce4 couriertcpd 4556 1 4556 0 S+J piperd 0xc8f6e000 courierlogger 4544 4543 4544 0 S+J select 0xc07b7ce4 couriertcpd 4543 1 4543 0 S+J piperd 0xc9cb64c8 courierlogger 4532 4531 4531 0 S+J select 0xc07b7ce4 authdaemond 4531 1 4531 0 S+J piperd 0xc94917f8 courierlogger 4517 1 4517 0 SsJ select 0xc07b7ce4 sshd 4500 1 4500 0 SsJ select 0xc07b7ce4 bsnmpd 4467 1 4467 0 SsJ select 0xc07b7ce4 rpcbind 4456 1 4456 0 SsJ select 0xc07b7ce4 syslogd 4180 1 4180 0 SsJ nanslp 0xc076a96c cron 4172 1 4172 0 SsJ select 0xc07b7ce4 inetd 4167 1 4167 1003 SsJ (threaded) stunnel 100735 S kserel 0xc8e0b454 stunnel 100532 S kserel 0xc8e0b454 stunnel 100189 S kserel 0xc8e0b454 stunnel 100749 S kserel 0xc8e0b454 stunnel 100412 S select 0xc07b7ce4 stunnel 100080 S ksesigwa 0xc8e05780 stunnel 4160 1 4160 0 SsJ accept 0xc986d302 saslauthd1 4149 4141 4141 125 SJ select 0xc07b7ce4 qmgr 4145 1 4145 65534 SsJ (threaded) proxsmtpd 100762 S kserel 0xc8e0b9f4 proxsmtpd 100383 S kserel 0xc8e0b9f4 proxsmtpd 100761 S kserel 0xc8e0b9f4 proxsmtpd 100765 S kserel 0xc8e0b9f4 proxsmtpd 100740 S select 0xc07b7ce4 proxsmtpd 100783 S accept 0xc9a97892 proxsmtpd 100516 S ksesigwa 0xc9b99dc8 proxsmtpd 4141 1 4141 0 SsJ select 0xc07b7ce4 master 4077 1 4077 0 SsJ select 0xc07b7ce4 sshd 4021 1 4021 0 SsJ select 0xc07b7ce4 syslogd 3844 1 3844 0 SsJ select 0xc07b7ce4 inetd 3830 1 3830 0 SsJ nanslp 0xc076a96c cron 3823 1 3823 0 SsJ select 0xc07b7ce4 sshd 3815 1 3815 0 SsJ nanslp 0xc076a96c httpd 3680 1 3680 0 SsJ select 0xc07b7ce4 syslogd 3538 3534 3438 0 SJ piperd 0xc8f69660 cronolog 3537 3531 3438 0 SJ piperd 0xc9311cc0 cronolog 3536 3532 3438 0 SJ piperd 0xc9491b28 cronolog 3535 3438 3438 80 SJ lockf 0xcdedd2c0 httpd 3534 3438 3438 0 SJ wait 0xc8d95a78 sh 3532 3438 3438 0 SJ wait 0xc969a648 sh 3531 3438 3438 0 SJ wait 0xc9828430 sh 3486 3450 3449 88 S+J (threaded) mysqld 100165 S kserel 0xc894d0f4 mysqld 100256 S kserel 0xc894d0f4 mysqld 100176 S kserel 0xc894d0f4 mysqld 100181 S select 0xc07b7ce4 mysqld 100166 S kserel 0xc894d0f4 mysqld 100252 S kserel 0xc894ea54 mysqld 100253 S sigwait 0xec476c14 mysqld 100172 S ksesigwa 0xc8a4d780 mysqld 3479 1 3479 0 SsJ nanslp 0xc076a96c cron 3460 1 3460 0 SsJ select 0xc07b7ce4 inetd 3450 1 3449 88 S+J wait 0xc92e4000 sh 3448 3438 3438 80 SJ select 0xc07b7ce4 httpd 3438 1 3438 0 SsJ select 0xc07b7ce4 httpd 3326 1 3326 0 SsJ select 0xc07b7ce4 sshd 3265 1 3265 0 SsJ select 0xc07b7ce4 syslogd 2983 1 2983 0 SsJ nanslp 0xc076a96c cron 2976 1 2976 0 SsJ select 0xc07b7ce4 sshd 2968 1 2968 0 SsJ (threaded) httpauthd 100179 S kserel 0xc93a0454 httpauthd 100741 S kserel 0xc93a0454 httpauthd 100760 S kserel 0xc93a0454 httpauthd 100730 S kserel 0xc93a0454 httpauthd 100185 S sbwait 0xca02fd2c httpauthd 100593 S sbwait 0xceb5c79c httpauthd 100404 S sbwait 0xd05c8a64 httpauthd 100191 S sbwait 0xca43fd2c httpauthd 100393 S sbwait 0xca8dc20c httpauthd 100417 S sbwait 0xca41c638 httpauthd 100359 S sbwait 0xd05c04d4 httpauthd 100468 S sbwait 0xc9f224d4 httpauthd 100273 S sbwait 0xca50b638 httpauthd 100408 S sbwait 0xca50b0a8 httpauthd 100357 S sbwait 0xcabb7a64 httpauthd 100254 S sbwait 0xcf2b3900 httpauthd 100173 S sbwait 0xcf0f2900 httpauthd 100251 S sbwait 0xca50cbc8 httpauthd 100226 S sbwait 0xd0af00a8 httpauthd 100221 S sbwait 0xc9eeabc8 httpauthd 100391 S sbwait 0xca41c900 httpauthd 100162 S sbwait 0xcca28a64 httpauthd 100352 S sbwait 0xd0b01900 httpauthd 100421 S sbwait 0xc97a64d4 httpauthd 100411 S sbwait 0xd0b0120c httpauthd 100479 S accept 0xc9800892 httpauthd 100169 S sbwait 0xca41c370 httpauthd 100396 S sbwait 0xca4110a8 httpauthd 100265 S sbwait 0xcf2d5d2c httpauthd 100402 S sbwait 0xca411e90 httpauthd 100781 S sbwait 0xcf0f2bc8 httpauthd 100183 S sbwait 0xc95b7bc8 httpauthd 100356 S sbwait 0xd0afc638 httpauthd 100502 S sbwait 0xc9df8370 httpauthd 100751 S sbwait 0xc97ff0a8 httpauthd 100500 S sbwait 0xc900b0a8 httpauthd 100513 S sbwait 0xc9a794d4 httpauthd 100170 S sbwait 0xcabaf20c httpauthd 100476 S sbwait 0xc8d6a900 httpauthd 100851 S sbwait 0xca39b79c httpauthd 100274 S sbwait 0xceb44900 httpauthd 100510 S sbwait 0xca8dc79c httpauthd 100936 S sbwait 0xc986d4d4 httpauthd 100419 S sbwait 0xcabaf900 httpauthd 100711 S sbwait 0xd05aca64 httpauthd 100533 S sbwait 0xcefa7a64 httpauthd 100250 S sbwait 0xd0aef0a8 httpauthd 100422 S sbwait 0xcabb3a64 httpauthd 100405 S sbwait 0xc91dfd2c httpauthd 100514 S sbwait 0xd0ad34d4 httpauthd 100482 S sbwait 0xc9f23bc8 httpauthd 100470 S sbwait 0xc9e4879c httpauthd 100410 S sbwait 0xc96af4d4 httpauthd 100614 S sbwait 0xca50c20c httpauthd 100801 S sbwait 0xc9eea370 httpauthd 100175 S sbwait 0xd0ac9638 httpauthd 100737 S sbwait 0xd089ee90 httpauthd 100403 S ksesigwa 0xc93a1bb0 httpauthd 2920 1 2920 389 SsJ (threaded) slapd 100186 S kserel 0xc8ddedb4 slapd 100497 S kserel 0xc8ddedb4 slapd 100763 S kserel 0xc8ddedb4 slapd 100469 S kserel 0xc8ddedb4 slapd 100471 S select 0xc07b7ce4 slapd 100136 S ksesigwa 0xc8e0d998 slapd 2900 1 2900 0 SsJ select 0xc07b7ce4 syslogd 2668 1 2668 0 SsJ select 0xc07b7ce4 slapd 2661 1 2661 0 SsJ nanslp 0xc076a96c cron 2654 1 2654 0 SsJ select 0xc07b7ce4 sshd 2599 1 2599 0 SsJ select 0xc07b7ce4 syslogd 2547 2388 2388 80 SJ accept 0xc986d19e httpd 2546 2388 2388 80 SJ accept 0xc986d19e httpd 2545 2388 2388 80 SJ accept 0xc986d19e httpd 2544 2388 2388 80 SJ accept 0xc986d19e httpd 2543 2388 2388 80 SJ accept 0xc986d19e httpd 2403 1 2403 0 SsJ nanslp 0xc076a96c cron 2396 1 2396 0 SsJ select 0xc07b7ce4 sshd 2388 1 2388 0 SsJ nanslp 0xc076a96c httpd 2289 1 2289 0 SsJ select 0xc07b7ce4 inetd 2275 1 2275 0 SsJ nanslp 0xc076a96c cron 2268 1 2268 0 SsJ select 0xc07b7ce4 sshd 2260 1 2260 0 SsJ nanslp 0xc076a96c httpd 2206 1 2206 0 SsJ select 0xc07b7ce4 syslogd 2006 1951 1950 88 S+J (threaded) mysqld 100161 S kserel 0xc93a0514 mysqld 100038 S kserel 0xc93a0514 mysqld 100167 S kserel 0xc93a0514 mysqld 100225 S select 0xc07b7ce4 mysqld 100091 S kserel 0xc93a0514 mysqld 100222 S sigwait 0xec3e1c14 mysqld 100219 S ksesigwa 0xc93a1780 mysqld 1951 1 1950 88 S+J wait 0xc939f430 sh 1949 1940 1940 125 SJ kqread 0xc97a9b00 qmgr 1940 1 1940 0 SsJ kqread 0xc969eb00 master 1800 1795 1800 70 SsJ select 0xc07b7ce4 postgres 1799 1795 1799 70 SsJ nanslp 0xc076a96c postgres 1798 1795 1798 70 SsJ nanslp 0xc076a96c postgres 1797 1795 1797 70 SsJ nanslp 0xc076a96c postgres 1795 1 1791 70 S+J select 0xc07b7ce4 postgres 1765 1760 1760 0 SJ lockf 0xcca4ed00 saslauthd 1763 1760 1760 0 SJ lockf 0xca55b240 saslauthd 1762 1760 1760 0 SJ lockf 0xcf50de40 saslauthd 1761 1760 1760 0 SJ accept 0xc8f76cbe saslauthd 1760 1 1760 0 SsJ lockf 0xcff97c00 saslauthd 1731 1 1731 0 SsJ select 0xc07b7ce4 syslogd 1374 1 1374 0 SsJ nanslp 0xc076a96c cron 1364 1 1364 0 SsJ select 0xc07b7ce4 sshd 1336 1 1336 0 SsJ nanslp 0xc076a96c httpd 1117 1114 1117 70 SsJ select 0xc07b7ce4 postgres 1116 1114 1116 70 SsJ select 0xc07b7ce4 postgres 1114 1 1114 70 SsJ select 0xc07b7ce4 postgres 1057 1 1057 0 SsJ select 0xc07b7ce4 syslogd 691 1 691 0 Ss nanslp 0xc076a96c cron 685 1 685 25 Ss pause 0xc8cf0894 sendmail 681 1 681 0 Ss select 0xc07b7ce4 sendmail 675 1 675 0 Ss select 0xc07b7ce4 sshd 655 1 654 0 S nanslp 0xc076a96c python 615 1 615 0 Ss select 0xc07b7ce4 ntpd 525 1 525 0 Ss select 0xc07b7ce4 syslogd 470 1 470 0 Ss select 0xc07b7ce4 devd 41 0 0 0 SL - 0xe9c77d04 [schedcpu] 40 0 0 0 SL sdflush 0xc07c9294 [softdepflush] 39 0 0 0 SL syncer 0xc076a6dc [syncer] 38 0 0 0 SL vlruwt 0xc8a07c90 [vnlru] 37 0 0 0 SL psleep 0xc07b8260 [bufdaemon] 36 0 0 0 SL pgzero 0xc07ca264 [pagezero] 35 0 0 0 SL psleep 0xc07c9d6c [vmdaemon] 34 0 0 0 SL psleep 0xc07c9d28 [pagedaemon] 33 0 0 0 SL - 0xc8bee580 [dummynet] 32 0 0 0 WL [swi0: sio] 31 0 0 0 WL [irq1: atkbd0] 30 0 0 0 WL [irq19: atapci1] 29 0 0 0 WL [irq15: ata1] 28 0 0 0 WL [irq14: ata0] 27 0 0 0 LL *Giant 0xcf52b6c0 [irq17: em1] 26 0 0 0 LL *Giant 0xcf52b6c0 [irq16: em0] 25 0 0 0 WL [irq9: acpi0] 24 0 0 0 SL - 0xc89a2c00 [thread taskq] 23 0 0 0 SL - 0xc89a2c80 [acpi_task_2] 22 0 0 0 SL - 0xc89a2c80 [acpi_task_1] 9 0 0 0 SL - 0xc89a2c80 [acpi_task_0] 21 0 0 0 WL [swi6: Giant taskq] 20 0 0 0 WL [swi6: task queue] 19 0 0 0 WL [swi2: cambio] 8 0 0 0 SL ccb_scan 0xc0752ae4 [xpt_thrd] 7 0 0 0 SL - 0xc89ef180 [kqueue taskq] 18 0 0 0 WL [swi5: +] 17 0 0 0 SL - 0xc0767320 [yarrow] 6 0 0 0 SL crypto_r 0xc07c8ec4 [crypto returns] 5 0 0 0 SL crypto_w 0xc07c8e84 [crypto] 4 0 0 0 SL - 0xc0767e28 [g_down] 3 0 0 0 SL - 0xc0767e24 [g_up] 2 0 0 0 SL - 0xc0767e1c [g_event] 16 0 0 0 WL [swi3: vm] 15 0 0 0 LL *Giant 0xcf52b6c0 [swi4: clock sio] 14 0 0 0 WL [swi1: net] 13 0 0 0 RL [idle: cpu0] 12 0 0 0 RL CPU 1 [idle: cpu1] 11 0 0 0 RL CPU 2 [idle: cpu2] 10 0 0 0 RL CPU 3 [idle: cpu3] 1 0 1 0 SLs wait 0xc894f000 [init] 0 0 0 0 WLs [swapper] # -------------------------------------------------------------------- # CPU INFO db> show pcpu cpuid = 1 curthread = 0xc894a900: pid 12 "idle: cpu1" curpcb = 0xe81f2d90 fpcurthread = none idlethread = 0xc894a900: pid 12 "idle: cpu1" APIC ID = 1 currentldt = 0x50 spin locks held: db> show allpcpu Current CPU: 1 cpuid = 0 curthread = 0xcf2ba780: pid 75907 "stunnel" curpcb = 0xed1b1d90 fpcurthread = none idlethread = 0xc894aa80: pid 13 "idle: cpu0" APIC ID = 0 currentldt = 0x58 spin locks held: cpuid = 1 curthread = 0xc894a900: pid 12 "idle: cpu1" curpcb = 0xe81f2d90 fpcurthread = none idlethread = 0xc894a900: pid 12 "idle: cpu1" APIC ID = 1 currentldt = 0x50 spin locks held: cpuid = 2 curthread = 0xc894a780: pid 11 "idle: cpu2" curpcb = 0xe81efd90 fpcurthread = none idlethread = 0xc894a780: pid 11 "idle: cpu2" APIC ID = 2 currentldt = 0x50 spin locks held: cpuid = 3 curthread = 0xc894a600: pid 10 "idle: cpu3" curpcb = 0xe81ecd90 fpcurthread = none idlethread = 0xc894a600: pid 10 "idle: cpu3" APIC ID = 3 currentldt = 0x50 spin locks held: # -------------------------------------------------------------------- # LOCK INFO db> show locks db> show alllocks Process 69677 (python) thread 0xca239900 (100432) exclusive sleep mutex vm object (standard object) r = 0 (0xce1f3420) locked @ /usr/src/sys/vm/vm_fault.c:688 exclusive sx user map r = 0 (0xcf67f4e4) locked @ /usr/src/sys/vm/vm_map.c:3105 Process 69674 (rsync) thread 0xc8cf5a80 (100132) exclusive sleep mutex pmap r = 0 (0xcf5b87b0) locked @ /usr/src/sys/i386/i386/pmap.c:2749 exclusive sleep mutex vm page queue mutex r = 0 (0xc07c9ce0) locked @ /usr/src/sys/i386/i386/pmap.c:2748 Process 69664 (rsync) thread 0xca239480 (100485) exclusive sleep mutex vm object (standard object) r = 0 (0xcc3ad528) locked @ /usr/src/sys/kern/vfs_bio.c:1480 exclusive sleep mutex Giant r = 0 (0xc076a080) locked @ /usr/src/sys/kern/vfs_vnops.c:492 db> show lockedvnods Locked vnodes 0xccc2e414: tag ufs, type VREG usecount 1, writecount 0, refcount 5965 mountedhere 0 flags () v_object 0xcc3ad528 ref 0 pages 81936 lock type ufs: SHARED (count 1)#0 0xc04fa690 at lockmgr+0x160 #1 0xc0649d8a at ffs_lock+0x76 #2 0xc06bf8bb at VOP_LOCK_APV+0x87 #3 0xc056a59c at vn_lock+0xac #4 0xc0569c72 at vn_read+0x132 #5 0xc052c741 at dofileread+0x85 #6 0xc052c5da at kern_readv+0x36 #7 0xc052c505 at read+0x45 #8 0xc06acec3 at syscall+0x25b #9 0xc06984df at Xint0x80_syscall+0x1f ino 13262597, on dev ad8s1e # -------------------------------------------------------------------- # PROCESS STACK TRACES # PYTHON db> trace 69677 Tracing pid 69677 tid 100432 td 0xca239900 sched_switch(ca239900,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c07c9ce0,c8cf5a80,0,c07c9ce0,2,c06e8e2b,233) at turnstile_wait+0x35a _mtx_lock_sleep(c07c9ce0,ca239900,0,c07075e5,15a) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c07c9ce0,0,c07075e5,15a,c06eba6d,...) at _mtx_lock_flags+0xa2 vm_fault(cf67f4a0,8147000,2,8,ca239900,...) at vm_fault+0x311 trap_pfault(ec755d38,1,8147f20,8147f20,0,...) at trap_pfault+0xce trap(812003b,811003b,bfbf003b,812511c,8147f20,...) at trap+0x1eb calltrap() at calltrap+0x5 --- trap 0xc, eip = 0x8073f3c, esp = 0xbfbfda00, ebp = 0xbfbfda28 --- # RSYNC db> trace 69664 Tracing pid 69664 tid 100485 td 0xca239480 sched_switch(ca239480,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c07c9ce0,c8cf5a80,0,c07c9ce0,2,c06e8e2b,233) at turnstile_wait+0x35a _mtx_lock_sleep(c07c9ce0,ca239480,0,c06f2142,5c9) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c07c9ce0,0,c06f2142,5c9,cc3ad528,...) at _mtx_lock_flags+0xa2 vfs_vmio_release(dcc09838) at vfs_vmio_release+0x35 getnewbuf(0,0,4000,4000) at getnewbuf+0x276 getblk(ccc2e414,236e,0,4000,0,...) at getblk+0x3b3 cluster_read(ccc2e414,14002000,0,236e,0,...) at cluster_read+0xde ffs_read(ec74cbf4) at ffs_read+0x2d6 VOP_READ_APV(c0741260,ec74cbf4) at VOP_READ_APV+0x9b vn_read(cb7676c0,ec74ccbc,c94d6a00,0,ca239480) at vn_read+0x1fb dofileread(ca239480,5,cb7676c0,ec74ccbc,ffffffff,...) at dofileread+0x85 kern_readv(ca239480,5,ec74ccbc,85063e8,42d10,...) at kern_readv+0x36 read(ca239480,ec74cd04) at read+0x45 syscall(3b,3b,3b,0,430f8,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (3, FreeBSD ELF32, read), eip = 0x28185a63, esp = 0xbfbf987c, ebp = 0xbfbf98c8 --- # RSYNC db> trace 69674 Tracing pid 69674 tid 100132 td 0xc8cf5a80 sched_switch(c8cf5a80,0,2) at sched_switch+0x177 mi_switch(2,0,c076a040,0,c06eba6d,...) at mi_switch+0x270 critical_exit(c5e1bd38,e9f25c30,c0698a70,0,e9f20008,...) at critical_exit+0x8b lapic_handle_timer(0) at lapic_handle_timer+0xe1 Xtimerint(c5e1bd38,cf5b87b0,28120000,e9f25c48) at Xtimerint+0x30 pmap_remove_pages(cf5b87b0,0,bfc00000) at pmap_remove_pages+0x1c2 vmspace_exit(c8cf5a80,c076a240,0,c06e6c7d,125,...) at vmspace_exit+0x97 exit1(c8cf5a80,0,e9f25d30,c06acec3,c8cf5a80,...) at exit1+0x496 exit1(c8cf5a80,e9f25d04) at exit1 syscall(3b,3b,3b,8088eda,407,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x2818520b, esp = 0xbfbfd82c, ebp = 0xbfbfd848 --- # JAIL-MEASURE db> trace 69455 Tracing pid 69455 tid 100839 td 0xc9a5d780 sched_switch(c9a5d780,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c076a080,ca239480,0,c076a080,2,c06e8e2b,233) at turnstile_wait+0x35a _mtx_lock_sleep(c076a080,c9a5d780,0,c06f3435,c1) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c076a080,0,c06f3435,c1) at _mtx_lock_flags+0xa2 namei(ece75ba0) at namei+0x227 kern_lstat(c9a5d780,80637a8,0,ece75c74) at kern_lstat+0x47 lstat(c9a5d780,ece75d04) at lstat+0x1b syscall(805003b,805003b,bfbf003b,8063748,8063700,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (190, FreeBSD ELF32, lstat), eip = 0x28159b47, esp = 0xbfbfeafc, ebp = 0xbfbfeb98 --- # EM1 db> trace 27 Tracing pid 27 tid 100017 td 0xc894c900 sched_switch(c894c900,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c076a080,ca239480,0,c076a080,2,c06e8e2b,233) at turnstile_wait+0x35a _mtx_lock_sleep(c076a080,c894c900,0,c06e6f85,2a9) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c076a080,0,c06e6f85,2a9) at _mtx_lock_flags+0xa2 ithread_execute_handlers(c89a3648,c89a0480) at ithread_execute_handlers+0xde ithread_loop(c8a2cae0,e8210d38,c8a2cae0,c04f290c,0,...) at ithread_loop+0x67 fork_exit(c04f290c,c8a2cae0,e8210d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe8210d6c, ebp = 0 --- # EM0 db> trace 26 Tracing pid 26 tid 100018 td 0xc894c780 sched_switch(c894c780,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c076a080,ca239480,0,c076a080,2,c06e8e2b,233) at turnstile_wait+0x35a _mtx_lock_sleep(c076a080,c894c780,0,c06e6f85,2a9) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c076a080,0,c06e6f85,2a9) at _mtx_lock_flags+0xa2 ithread_execute_handlers(c89a3860,c89a0500) at ithread_execute_handlers+0xde ithread_loop(c8a2cc40,e820dd38,c8a2cc40,c04f290c,0,...) at ithread_loop+0x67 fork_exit(c04f290c,c8a2cc40,e820dd38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe820dd6c, ebp = 0 --- # -------------------------------------------------------------------- # OTHER INFO db> x cpu_idle_hlt cpu_idle_hlt: 0 From Alexander at Leidinger.net Mon Jun 16 10:21:45 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Mon Jun 16 11:25:56 2008 Subject: How to probe what application does in kernel (with sound device)? In-Reply-To: <20080613235531.GA91339@bacardi> References: <4852CFE8.8040003@rawbw.com> <20080613235531.GA91339@bacardi> Message-ID: <20080616120352.72872r6gafuop5yc@webmail.leidinger.net> Quoting Fraser Tweedale (from Sat, 14 Jun 2008 09:55:32 +1000): > ktrace(1) > > From man page: > The ktrace utility enables kernel trace logging for the specified pro- > cesses. Kernel trace data is logged to the file ktrace.out. The kernel > operations that are traced include system calls, namei > translations, sig- > nal processing, and I/O. To work with linux programs, linux_kdump (ports) has to be used. Regarding the problem at hand, have a look at vchans (sysctl -a | grep vchan). Enable them if they aren't already and test again. If there are still problems, I suggest to come over to multimedia@, post the OS version, the content of /dev/sndstat, the output of "sysctl -a | grep linux" and what you tried so far. Bye, Alexander. -- Eat drink and be merry! Tomorrow you may be in Utah. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From sigtrm at gmail.com Mon Jun 16 12:43:44 2008 From: sigtrm at gmail.com (Lukasz Jaroszewski) Date: Mon Jun 16 12:43:48 2008 Subject: KLM - Fatal trap 12 on kldunload mod - sc replace Message-ID: Hi, I am trying to master kernel, first thought was to do simple replace of system call(read), tho i have some issues which I cant figure. My read_hack is supposed to log keystrokes, and it does.. tho only login and password typed from console but without 1st char(typed root appears as oot.), next after kldunload and changing tty system does ``fatal trap''. Here is the code i use: ---------------------------cut-------------------------- read_hack(struct thread *td, void *syscall_args) { struct read_args *uap; uap = (struct read_args *)syscall_args; int error; char buf[1]; int done; error = read(td, syscall_args); if (error || (!uap->nbyte) || (uap->nbyte > 1) || (uap->fd != 0)) return(error); copyinstr(uap->buf, buf, 1, &done); log(LOG_INFO, "mex: %c\n", buf[0]); return(error); } ---------------------------cut--------------------- And in load() i do: ---------------------------cut--------------------- load(struct module *module, int cmd, void *arg) { int error = 0; switch (cmd) { case MOD_LOAD: oldsy = sysent[SYS_read].sy_call; sysent[SYS_read].sy_call = (sy_call_t *)read_hack; break; case MOD_UNLOAD: sysent[SYS_read].sy_call = (sy_call_t *)oldsy; break; default: error = EOPNOTSUPP; break; } return(error); } ---------------------------cut------------------- After changing to other tty i get: -------------------------------------------------------------------- # kgdb kernel.debug /var/crash/vmcore.5 [GDB will not be able to debug user-mode threads: /usr/lib/ libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc23f656e fault code = supervisor read, page not present instruction pointer = 0x20:0xc23f656e stack pointer = 0x28:0xcd63bc60 frame pointer = 0x28:0xcd63bc80 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1139 (csh) panic: from debugger cpuid = 0 Uptime: 34m47s Physical memory: 234 MB Dumping 37 MB: 22 6 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) wh ;;------below reformatted text, tr'ed escape chars which made frame around it------- pcpu.h 177 : "=m" (*(struct __s *) (__pcpu_offset(name))) \ 178 : "r" (__s)); \ 179 } else { \ 180 *__PCPU_PTR(name) = __val; \ 181 } \ 182 } 183 184 #define PCPU_GET(member) __PCPU_GET(pc_ ## member) 185 #define PCPU_ADD(member, val) __PCPU_ADD(pc_ ## member, val) 186 #define PCPU_INC(member) __PCPU_INC(pc_ ## member) 187 #define PCPU_PTR(member) __PCPU_PTR(pc_ ## member) 188 #define PCPU_SET(member, val) __PCPU_SET(pc_ ## member, val) 189 190 static __inline struct thread * 191 __curthread(void) 192 { 193 struct thread *td; 194 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); 196 return (td); 197 } 198 #define curthread (__curthread()) 199 200 #else /* !lint || defined(__GNUCLIKE_ASM) && defined(__GNUCLIKE___TYPEOF) */ 201 202 #error "this file needs to be ported to your compiler" 203 204 #endif /* lint, etc. */ 205 206 #endif /* _KERNEL */ 207 208 #endif /* !_MACHINE_PCPU_H_ */ 209 210 211 212 213 214 ;;-----------------------------------end of tr'ed frame--------------------------------- kernel Thread 100076 In: doadump Line: 195 PC: 0xc074f42c Segmentation fault (core dumped) # # uname -a FreeBSD 7.0-BETA3 FreeBSD 7.0-BETA3 #1: Sat Nov 24 11:19:31 UTC 2007 root@:/usr/obj/usr/src/sys/BSDKITCHEN i386 I know its BETA, but i don't think its an issue, i guess i am doing something wrong. I would like to know as much as one can/have will/ time to explain me, where is layer 8 error. :) Best regards LVJ From joerg at britannica.bec.de Mon Jun 16 12:44:41 2008 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Mon Jun 16 12:44:45 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <7d6fde3d0806152111t3306279dr841b90740141fcfb@mail.gmail.com> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> <7d6fde3d0806152111t3306279dr841b90740141fcfb@mail.gmail.com> Message-ID: <20080616123429.GA2189@britannica.bec.de> On Sun, Jun 15, 2008 at 09:11:36PM -0700, Garrett Cooper wrote: > Now all we need to do is write / import a BSD compatible less(1) into > FreeBSD =). less is dual licensed. Joerg From des at des.no Mon Jun 16 12:51:52 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Jun 16 12:51:58 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <4855EDFE.3010708@FreeBSD.org> (Doug Barton's message of "Sun\, 15 Jun 2008 21\:37\:18 -0700") References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> <4855EDFE.3010708@FreeBSD.org> Message-ID: <86bq211rqw.fsf@ds4.des.no> Doug Barton writes: > Andrey Chernov writes: > > Please note that BSD grep is not localized (and can't be per design) > > and works only with standard C locale. It may not affect ports > > system processing but shurely affects real texts handling. > That is very troubling. In this day and age localization is a > requirement. I cannot imagine being supportive of adding something to > the base that does not have this capability. We don't have a locale-aware regex implementation. Henry Spencer wrote one for Tcl 8, and it seems to be under an MIT-equivalent license, but I'm not sure how hard it would be to extirpate. It might be easier to lift it from PostgreSQL, which also uses it. DES -- Dag-Erling Sm?rgrav - des@des.no From joerg at britannica.bec.de Mon Jun 16 13:09:29 2008 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Mon Jun 16 13:09:33 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <7d6fde3d0806152111t3306279dr841b90740141fcfb@mail.gmail.com> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> <7d6fde3d0806152111t3306279dr841b90740141fcfb@mail.gmail.com> Message-ID: <20080616123429.GA2189@britannica.bec.de> On Sun, Jun 15, 2008 at 09:11:36PM -0700, Garrett Cooper wrote: > Now all we need to do is write / import a BSD compatible less(1) into > FreeBSD =). less is dual licensed. Joerg From m.walraven at terantula.com Mon Jun 16 13:33:24 2008 From: m.walraven at terantula.com (Marco Walraven) Date: Mon Jun 16 13:33:28 2008 Subject: RELENG_7 pxeboot fails on SuperMicro 6012 In-Reply-To: <20080613111249.GA51360@eos.sc1.parodius.com> References: <20080613103000.GB27681@cotton.terantula.com> <20080613111249.GA51360@eos.sc1.parodius.com> Message-ID: <20080616133313.GE27681@cotton.terantula.com> On Fri, Jun 13, 2008 at 04:12:49AM -0700, Jeremy Chadwick wrote: > On Fri, Jun 13, 2008 at 12:30:00PM +0200, Marco Walraven wrote: > > I ran into the following problem trying to pxeboot RELENG_7 on a SuperMicro 6012 system. RELENG_6 just works fine and the same RELENG_7 release pxeboots fine when I use a VMware host. > > > > Can't work out which disk we are booting from. > > Guessed BIOS device 0xffffff not fund by probes, defaulting to disk0: > > > > can't load 'kernel' > > > > None of the setting I have specified in /boot/loader.conf especially vfs.root.mountfrom="ufs:/dev/md0c" pop up when asking for the configured variables. > > > > Any clues ? > > http://jdc.parodius.com/freebsd/pxeboot_serial_install.html > > Be sure to read this, and see Item #10. Thanks for the quick hint Jeremy; booting on that old piece of hardware did indeed succeed using an uncompressed mfsroot. Marco -- Terantula - Industrial Strength Open Source phone:+31 64 3232 400 / www: http://www.terantula.com / pgpkey: E7EE7A46 pgp fingerprint: F2EE 122D 964C DE68 7380 6F95 3710 7719 E7EE 7A46 From chuckr at telenix.org Mon Jun 16 13:51:42 2008 From: chuckr at telenix.org (Chuck Robey) Date: Mon Jun 16 13:51:46 2008 Subject: FreeBSD hotplugging (Hal) info In-Reply-To: <716a8d5f0806160017y23a29fd4r20190e8b8a198a6@mail.gmail.com> References: <4852C94B.2090809@telenix.org> <4854087F.90509@telenix.org> <716a8d5f0806160017y23a29fd4r20190e8b8a198a6@mail.gmail.com> Message-ID: <48566D63.3090509@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Konrad Jankowski wrote: >> Replying to my own mail, I realize I've worded this badly ... what I meant is, >> does any part of FreeBSD's base make any use of Hal's (the hardware abstraction >> layer) API? If it does, and you could tell me where that is (because I can't > > Base definitely doesn't use it. > All you can find in base is devd. Well, good news and bad. Dropping the bad news first, I can't grep for hal or dbus anywhere in the devd src dir, which I think might mean it's not a direct user or propagator of hal. OTOH, devd's man page lists devctl, which seems mightily interesting, and could extremely likely be adapted into reporting to hal directly. My immediate worry is something I picked up from the devctl man page, that it is meant for a single reader. Does that mean that I am somehow prevented from sharing it to both devd (or devfs) AND hal, both? Or, do I manually (well, via script) create an extra devctl node? Or, maybe, am I knocking on the door of the wrong mailing list? Please let me know, my stubborn streak has seen me too close to the ending of this driver of mine to consider stopping now, I just MUST answer this last feature worry of mine. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIVm1jz62J6PPcoOkRArQbAJ9G+Ql78K7LWJ1vbKB7TWqAfRtBwgCgjQgw z+AP1pYbvAgmBrdqBXvMRbg= =7eon -----END PGP SIGNATURE----- From dudu at dudu.ro Mon Jun 16 14:13:14 2008 From: dudu at dudu.ro (Vlad GALU) Date: Mon Jun 16 14:13:18 2008 Subject: g++ associative containers Message-ID: Hello list, I didn't have a clue where else to post this so I figured this place was the right one. I also CCed Alex Kabaev, who did the gcc 4 import. I'd like to use a Patricia container in the new libstdc++. The issue is that /usr/include/c++/4.2/ext/pb_ds/assoc_container.hpp has two erroneous #include directive on lines 52 and 53. Are there any plans to cover that part of the new libstdc++, or is there any workaround? Thanks, Vlad -- ~/.signature: no such file or directory From Alexander at Leidinger.net Mon Jun 16 14:14:31 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Mon Jun 16 14:19:33 2008 Subject: FreeBSD hotplugging (Hal) info In-Reply-To: <48566D63.3090509@telenix.org> References: <4852C94B.2090809@telenix.org> <4854087F.90509@telenix.org> <716a8d5f0806160017y23a29fd4r20190e8b8a198a6@mail.gmail.com> <48566D63.3090509@telenix.org> Message-ID: <20080616161421.39263060wa8p0f28@webmail.leidinger.net> Quoting Chuck Robey (from Mon, 16 Jun 2008 09:40:51 -0400): > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Konrad Jankowski wrote: >>> Replying to my own mail, I realize I've worded this badly ... what >>> I meant is, >>> does any part of FreeBSD's base make any use of Hal's (the >>> hardware abstraction >>> layer) API? If it does, and you could tell me where that is >>> (because I can't >> >> Base definitely doesn't use it. >> All you can find in base is devd. > > Well, good news and bad. Dropping the bad news first, I can't grep > for hal or > dbus anywhere in the devd src dir, which I think might mean it's not a direct > user or propagator of hal. OTOH, devd's man page lists devctl, which seems > mightily interesting, and could extremely likely be adapted into reporting to > hal directly. devctl is reporting to devd. There's no relationship to HAL. > My immediate worry is something I picked up from the devctl man > page, that it is > meant for a single reader. Does that mean that I am somehow prevented from > sharing it to both devd (or devfs) AND hal, both? Or, do I manually > (well, via > script) create an extra devctl node? Or, maybe, am I knocking on the door of > the wrong mailing list? You can let devd issue commands in arrival/departure. > Please let me know, my stubborn streak has seen me too close to the ending of > this driver of mine to consider stopping now, I just MUST answer this last > feature worry of mine. Ask on gnome@ about dbus, and on x11@ about the X11 HAL stuff. Bye, Alexander. -- "Fantasies are free." "NO!! NO!! It's the thought police!!!!" http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From dougb at FreeBSD.org Mon Jun 16 15:29:06 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Jun 16 15:29:13 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <86bq211rqw.fsf@ds4.des.no> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> Message-ID: <485686BE.6070800@FreeBSD.org> Dag-Erling Sm?rgrav wrote: > Doug Barton writes: >> Andrey Chernov writes: >>> Please note that BSD grep is not localized (and can't be per design) >>> and works only with standard C locale. It may not affect ports >>> system processing but shurely affects real texts handling. >> That is very troubling. In this day and age localization is a >> requirement. I cannot imagine being supportive of adding something to >> the base that does not have this capability. > > We don't have a locale-aware regex implementation. Henry Spencer wrote > one for Tcl 8, and it seems to be under an MIT-equivalent license, but > I'm not sure how hard it would be to extirpate. It might be easier to > lift it from PostgreSQL, which also uses it. Ok, that's a slightly different situation, thanks for clarifying that. Sounds like that would be a good project for GSOC next year. :) Meanwhile, for those who didn't notice last night (*cough*) I added the WITHOUT_GNU_GREP knob for src.conf to make it easier for folks to test this in HEAD. hth, Doug -- This .signature sanitized for your protection From dudu at dudu.ro Mon Jun 16 17:13:03 2008 From: dudu at dudu.ro (Vlad GALU) Date: Mon Jun 16 17:13:10 2008 Subject: g++ associative containers In-Reply-To: <20080616125738.554db60e@kan.dnsalias.net> References: <20080616125738.554db60e@kan.dnsalias.net> Message-ID: On 6/16/08, Alexander Kabaev wrote: > On Mon, 16 Jun 2008 16:58:10 +0300 > "Vlad GALU" wrote: > > > Hello list, I didn't have a clue where else to post this so I > > figured this place was the right one. I also CCed Alex Kabaev, who did > > the gcc 4 import. > > I'd like to use a Patricia container in the new libstdc++. The issue > > is that /usr/include/c++/4.2/ext/pb_ds/assoc_container.hpp has two > > erroneous #include directive on lines 52 and 53. Are there any plans > > to cover that part of the new libstdc++, or is there any workaround? > > Thanks, > > Vlad > > > > File a PR plaase and assign it to me. Hi Alexander, I submitted the PR, but I've no clue how to assign it to you. Neither send-pr or the web interface (which I ended up using) seemed to allow me to do that. This is probably a PEBKAC :) > -- > > Alexander Kabaev > > -- ~/.signature: no such file or directory From kabaev at gmail.com Mon Jun 16 17:22:22 2008 From: kabaev at gmail.com (Alexander Kabaev) Date: Mon Jun 16 17:22:27 2008 Subject: g++ associative containers In-Reply-To: References: <20080616125738.554db60e@kan.dnsalias.net> Message-ID: <20080616132215.51eb87e6@kan.dnsalias.net> On Mon, 16 Jun 2008 20:13:01 +0300 "Vlad GALU" wrote: > On 6/16/08, Alexander Kabaev wrote: > > On Mon, 16 Jun 2008 16:58:10 +0300 > > "Vlad GALU" wrote: > > > > > Hello list, I didn't have a clue where else to post this so I > > > figured this place was the right one. I also CCed Alex Kabaev, > > > who did the gcc 4 import. > > > I'd like to use a Patricia container in the new libstdc++. The > > > issue is that /usr/include/c++/4.2/ext/pb_ds/assoc_container.hpp > > > has two erroneous #include directive on lines 52 and 53. Are > > > there any plans to cover that part of the new libstdc++, or is > > > there any workaround? Thanks, > > > Vlad > > > > > > > File a PR plaase and assign it to me. > > Hi Alexander, > I submitted the PR, but I've no clue how to assign it to you. > Neither send-pr or the web interface (which I ended up using) seemed > to allow me to do that. This is probably a PEBKAC :) > Never mind then Just mail me the PR number. -- Alexander Kabaev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080616/d1af1088/signature.pgp From kabaev at gmail.com Mon Jun 16 17:26:58 2008 From: kabaev at gmail.com (Alexander Kabaev) Date: Mon Jun 16 17:27:05 2008 Subject: g++ associative containers In-Reply-To: References: Message-ID: <20080616125738.554db60e@kan.dnsalias.net> On Mon, 16 Jun 2008 16:58:10 +0300 "Vlad GALU" wrote: > Hello list, I didn't have a clue where else to post this so I > figured this place was the right one. I also CCed Alex Kabaev, who did > the gcc 4 import. > I'd like to use a Patricia container in the new libstdc++. The issue > is that /usr/include/c++/4.2/ext/pb_ds/assoc_container.hpp has two > erroneous #include directive on lines 52 and 53. Are there any plans > to cover that part of the new libstdc++, or is there any workaround? > Thanks, > Vlad > File a PR plaase and assign it to me. -- Alexander Kabaev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080616/afc5ac6a/signature.pgp From ravi.murty at intel.com Mon Jun 16 18:17:41 2008 From: ravi.murty at intel.com (Murty, Ravi) Date: Mon Jun 16 18:17:44 2008 Subject: TD_ON_RUNQ() Message-ID: Hello Everybody, This is a basic question - I've noticed this code in the kernel and sched_4bsd.c which basically says assert that I am running on that I am not on the runq. For instance, in mi_switch() (kern_sync.c) there is an assert KASSERT(!TD_ON_RUNQ(td), ("mi_switch: called by old code")). I guess if mi_switch is being called for curthread, it must be running which means it can't be on the runq, but I don't understand the assert string. Similarly in sched_4bsd.c in function sched_bind, the assertion says "assert that this thread is running" - and I've seen this assert happen. Thanks Ravi From chuckr at telenix.org Mon Jun 16 18:20:38 2008 From: chuckr at telenix.org (Chuck Robey) Date: Mon Jun 16 18:20:43 2008 Subject: FreeBSD hotplugging (Hal) info In-Reply-To: <20080616161421.39263060wa8p0f28@webmail.leidinger.net> References: <4852C94B.2090809@telenix.org> <4854087F.90509@telenix.org> <716a8d5f0806160017y23a29fd4r20190e8b8a198a6@mail.gmail.com> <48566D63.3090509@telenix.org> <20080616161421.39263060wa8p0f28@webmail.leidinger.net> Message-ID: <4856AC6C.3050106@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexander Leidinger wrote: > Quoting Chuck Robey (from Mon, 16 Jun 2008 09:40:51 > -0400): > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Konrad Jankowski wrote: >>>> Replying to my own mail, I realize I've worded this badly ... what I >>>> meant is, >>>> does any part of FreeBSD's base make any use of Hal's (the hardware >>>> abstraction >>>> layer) API? If it does, and you could tell me where that is >>>> (because I can't >>> >>> Base definitely doesn't use it. >>> All you can find in base is devd. >> >> Well, good news and bad. Dropping the bad news first, I can't grep >> for hal or >> dbus anywhere in the devd src dir, which I think might mean it's not a >> direct >> user or propagator of hal. OTOH, devd's man page lists devctl, which >> seems >> mightily interesting, and could extremely likely be adapted into >> reporting to >> hal directly. > > devctl is reporting to devd. There's no relationship to HAL. > >> My immediate worry is something I picked up from the devctl man page, >> that it is >> meant for a single reader. Does that mean that I am somehow prevented >> from >> sharing it to both devd (or devfs) AND hal, both? Or, do I manually >> (well, via >> script) create an extra devctl node? Or, maybe, am I knocking on the >> door of >> the wrong mailing list? > > You can let devd issue commands in arrival/departure. You missed the point, which is, because I am writing an Xorg Xinput driver, I MUST use hal. I *can* use devd or devfs, if and only if I also use the hal interface. I just found out about lshal, so I was able to prove that hal is aware of all the usb devices, I just need some way to prove that hal knows this info in real-time. So far, using a dbus tool, I can't see where hal is broadcasting about new usb devices, even things that show up in /var/log/messages on time. I need to see how hal finds out about it's devices, and either prove to myself that it knows this in realtime, or add it. That's why I was interested in devctl, because it seems like the ideal method to find out about new devices, and use that info to give it to dbus. Maybe I could write some devfs or devd script, maybe one in python (there's a Python interface to dbus) to tell hal about new devices, but that would be doing it secondhand, I'd far rather get it directly from devctl. That's why I asked about the man p[age comment about devctl talking only to devd, I'd like to change that. Maybe I'll find out who wrote that, and grill that guy. > >> Please let me know, my stubborn streak has seen me too close to the >> ending of >> this driver of mine to consider stopping now, I just MUST answer this >> last >> feature worry of mine. > > Ask on gnome@ about dbus, and on x11@ about the X11 HAL stuff. > > Bye, > Alexander. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIVqxsz62J6PPcoOkRAukvAJ9pmTL3Q0rKiCyEC57MclDDEUFVlQCgkfto KJbQORD0H/ZGuipQCm4jdT8= =4hI6 -----END PGP SIGNATURE----- From ache at nagual.pp.ru Tue Jun 17 00:22:47 2008 From: ache at nagual.pp.ru (Andrey Chernov) Date: Tue Jun 17 01:59:26 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <86bq211rqw.fsf@ds4.des.no> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> Message-ID: <20080617002224.GA16122@nagual.pp.ru> On Mon, Jun 16, 2008 at 02:36:23PM +0200, Dag-Erling Sm??rgrav wrote: > > > Please note that BSD grep is not localized (and can't be per design) > > > and works only with standard C locale. It may not affect ports > > > system processing but shurely affects real texts handling. > > That is very troubling. In this day and age localization is a > > requirement. I cannot imagine being supportive of adding something to > > the base that does not have this capability. > > We don't have a locale-aware regex implementation. Henry Spencer wrote > one for Tcl 8, and it seems to be under an MIT-equivalent license, but > I'm not sure how hard it would be to extirpate. It might be easier to > lift it from PostgreSQL, which also uses it. No, we have it already for many years (libc/regexec). BSD grep problem is different one, they use upper half of 256 char table on their own. -- http://ache.pp.ru/ From ache at nagual.pp.ru Tue Jun 17 00:28:30 2008 From: ache at nagual.pp.ru (Andrey Chernov) Date: Tue Jun 17 01:59:34 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <20080617002224.GA16122@nagual.pp.ru> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> <20080617002224.GA16122@nagual.pp.ru> Message-ID: <20080617002808.GB16122@nagual.pp.ru> On Tue, Jun 17, 2008 at 04:22:25AM +0400, Andrey Chernov wrote: > On Mon, Jun 16, 2008 at 02:36:23PM +0200, Dag-Erling Sm??rgrav wrote: > > > > Please note that BSD grep is not localized (and can't be per design) > > > > and works only with standard C locale. It may not affect ports > > > > system processing but shurely affects real texts handling. > > > That is very troubling. In this day and age localization is a > > > requirement. I cannot imagine being supportive of adding something to > > > the base that does not have this capability. > > > > We don't have a locale-aware regex implementation. Henry Spencer wrote > > one for Tcl 8, and it seems to be under an MIT-equivalent license, but > > I'm not sure how hard it would be to extirpate. It might be easier to > > lift it from PostgreSQL, which also uses it. > > No, we have it already for many years (libc/regexec). > BSD grep problem is different one, they use upper half of 256 char table > on their own. Oops, sorry I am thinking about BSD _sort_ when writing last statement. BSD grep is even not bothering to call setlocale(). I can't say is it can be simple healed by adding that call, some test suite run is needed. -- http://ache.pp.ru/ From ache at nagual.pp.ru Tue Jun 17 00:47:08 2008 From: ache at nagual.pp.ru (Andrey Chernov) Date: Tue Jun 17 01:59:42 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <20080617002808.GB16122@nagual.pp.ru> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> <20080617002224.GA16122@nagual.pp.ru> <20080617002808.GB16122@nagual.pp.ru> Message-ID: <20080617004647.GA16546@nagual.pp.ru> On Tue, Jun 17, 2008 at 04:28:10AM +0400, Andrey Chernov wrote: > BSD grep is even not bothering to call setlocale(). I can't say is it can > be simple healed by adding that call, some test suite run is needed. Quick source inspection reveals that BSD grep operates with single bytes only (util.c) so big rewriting with mbrtowc() is needed. Adding setlocale() only will makes it only useable with single byte locales, in success case. -- http://ache.pp.ru/ From yanefbsd at gmail.com Tue Jun 17 03:28:15 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Tue Jun 17 03:28:19 2008 Subject: Bug by design in getfsfile(3) / needed sanity check for mountpoints In-Reply-To: <9C83A8B6-0C73-4A06-A60A-527D7B7BCCE5@gmail.com> References: <9C83A8B6-0C73-4A06-A60A-527D7B7BCCE5@gmail.com> Message-ID: <7d6fde3d0806162028l74172922t4ea47250e7634130@mail.gmail.com> On Tue, Jun 10, 2008 at 2:27 AM, Garrett Cooper wrote: > Ok.... it appears I wasn't intelligent enough to post this in the right > place last night. Comments please? > > Hi hackers, > > I have a question, pending a bug found in getfsfile(3) [1]. > > Is there any possibility where a mountpoint be any value other > > than a directory, a symlink, or "none", i.e. a flat file? > > Thanks, > > -Garrett > > References: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/124409 (not fully in PR > > database yet). Going once, going twice... -Garrett From gabor at FreeBSD.org Tue Jun 17 07:21:57 2008 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Tue Jun 17 07:22:04 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <20080617004647.GA16546@nagual.pp.ru> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> <20080617002224.GA16122@nagual.pp.ru> <20080617002808.GB16122@nagual.pp.ru> <20080617004647.GA16546@nagual.pp.ru> Message-ID: <48576610.9080808@FreeBSD.org> Andrey Chernov escribi?: > On Tue, Jun 17, 2008 at 04:28:10AM +0400, Andrey Chernov wrote: > >> BSD grep is even not bothering to call setlocale(). I can't say is it can >> be simple healed by adding that call, some test suite run is needed. >> > > Quick source inspection reveals that BSD grep operates with single bytes > only (util.c) so big rewriting with mbrtowc() is needed. Adding > setlocale() only will makes it only useable with single byte locales, in > success case. > Sorry for the possibly silly question, but what we mean localization here in the case of grep? As far as I see, it works with wide chars, because the regex library is aware of those. What other aspect needs to be taken into account? In case of sort, I understarnd that it should explicitly handle wide characters due to the different alphabet of the different languages and yes, that seems to be a difficult task... G?bor From des at des.no Tue Jun 17 10:08:41 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Jun 17 10:08:49 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <20080617002224.GA16122@nagual.pp.ru> (Andrey Chernov's message of "Tue\, 17 Jun 2008 04\:22\:25 +0400") References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> <20080617002224.GA16122@nagual.pp.ru> Message-ID: <861w2wgyqh.fsf@ds4.des.no> Andrey Chernov writes: > "Dag-Erling Sm?rgrav" writes: > > We don't have a locale-aware regex implementation. Henry Spencer > > wrote one for Tcl 8, and it seems to be under an MIT-equivalent > > license, but I'm not sure how hard it would be to extirpate. It > > might be easier to lift it from PostgreSQL, which also uses it. > No, we have it already for many years (libc/regexec). I hadn't noticed... ISTR it was an issue back when jphoward wrote his BSD-licensed grep. However, it's not the same engine - it's Spencer's old engine with multibyte support added. IIRC, it performs very poorly compared to the GNU regexp engine; it would be interesting to see how well the Tcl engine performs in comparison. DES -- Dag-Erling Sm?rgrav - des@des.no From ache at nagual.pp.ru Tue Jun 17 07:46:29 2008 From: ache at nagual.pp.ru (Andrey Chernov) Date: Tue Jun 17 11:15:00 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <48576610.9080808@FreeBSD.org> References: <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> <20080617002224.GA16122@nagual.pp.ru> <20080617002808.GB16122@nagual.pp.ru> <20080617004647.GA16546@nagual.pp.ru> <48576610.9080808@FreeBSD.org> Message-ID: <20080617074607.GA42047@nagual.pp.ru> On Tue, Jun 17, 2008 at 09:21:52AM +0200, Gabor Kovesdan wrote: > Sorry for the possibly silly question, but what we mean localization > here in the case of grep? As far as I see, it works with wide chars, > because the regex library is aware of those. What other aspect needs to > be taken into account? See how word boundary handled in util.c there for example. They treat buffer as single chars only. wctype should be used instead ctype in all places in the code with corresponding mbrtowc conversion. -- http://ache.pp.ru/ From ache at nagual.pp.ru Tue Jun 17 07:48:25 2008 From: ache at nagual.pp.ru (Andrey Chernov) Date: Tue Jun 17 11:23:25 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <20080617074607.GA42047@nagual.pp.ru> References: <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> <20080617002224.GA16122@nagual.pp.ru> <20080617002808.GB16122@nagual.pp.ru> <20080617004647.GA16546@nagual.pp.ru> <48576610.9080808@FreeBSD.org> <20080617074607.GA42047@nagual.pp.ru> Message-ID: <20080617074821.GB42047@nagual.pp.ru> On Tue, Jun 17, 2008 at 11:46:07AM +0400, Andrey Chernov wrote: > On Tue, Jun 17, 2008 at 09:21:52AM +0200, Gabor Kovesdan wrote: > > Sorry for the possibly silly question, but what we mean localization > > here in the case of grep? As far as I see, it works with wide chars, > > because the regex library is aware of those. What other aspect needs to > > be taken into account? > > See how word boundary handled in util.c there for example. They treat > buffer as single chars only. wctype should be used instead ctype in all > places in the code with corresponding mbrtowc conversion. Moreover, ignore case matching there is single byte only too and needs the same. -- http://ache.pp.ru/ From dds at aueb.gr Tue Jun 17 08:26:12 2008 From: dds at aueb.gr (Diomidis Spinellis) Date: Tue Jun 17 11:23:32 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <48576610.9080808@FreeBSD.org> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> <20080617002224.GA16122@nagual.pp.ru> <20080617002808.GB16122@nagual.pp.ru> <20080617004647.GA16546@nagual.pp.ru> <48576610.9080808@FreeBSD.org> Message-ID: <48577510.4020007@aueb.gr> Gabor Kovesdan wrote: > In case of sort, I understarnd that it should > explicitly handle wide characters due to the different alphabet of the > different languages and yes, that seems to be a difficult task... Note that Konrad Jankowski in another SoC project is adding to our C library support for the Unicode collation algorithm, and importing the corresponding language-specific collation tables. From konrad.jankowski at bluemedia.pl Tue Jun 17 09:22:37 2008 From: konrad.jankowski at bluemedia.pl (Konrad Jankowski) Date: Tue Jun 17 11:23:40 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <48577510.4020007@aueb.gr> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> <20080617002224.GA16122@nagual.pp.ru> <20080617002808.GB16122@nagual.pp.ru> <20080617004647.GA16546@nagual.pp.ru> <48576610.9080808@FreeBSD.org> <48577510.4020007@aueb.gr> Message-ID: <48577BD2.4070205@bluemedia.pl> Diomidis Spinellis wrote: > Gabor Kovesdan wrote: >> In case of sort, I understarnd that it should explicitly handle wide >> characters due to the different alphabet of the different languages >> and yes, that seems to be a difficult task... > > Note that Konrad Jankowski in another SoC project is adding to our C > library support for the Unicode collation algorithm, and importing the > corresponding language-specific collation tables. > > Yes, and once this is done, sort will work out of he box, if it uses strcoll. Already tried on a prototype. -- Konrad Jankowski System Network Administrator Blue Media Sp. z o. o. +48 58 5555 312 http://www.bluemedia.pl Niniejsza wiadomo?? zosta?a przekazana w imieniu Blue Media sp. z o. o. z siedzib? w Sopocie, ul. Haffnera 6, 81-717 Sopot, zarejestrowana w S?dzie Rejonowym Gda?sk-P??noc VIII Wydzia? Gospodarczy KRS pod nr 0000127636, NIP 585-13-51-185, REGON 191781561. Je?eli nie jest Pan/Pani zamierzonym i wskazanym adresatem niniejszej wiadomo?ci, nie mo?e Pan/Pani jej ujawnia?, kopiowa?, dystrybuowa? ani tez w ?aden inny spos?b udost?pnia? lub wykorzystywa?. Je?eli otrzyma?/a Pan/Pani t? wiadomo?? przez pomy?k? prosimy o niezw?oczne poinformowanie nas o tym i o usuni?cie wiadomo?ci. From ache at nagual.pp.ru Tue Jun 17 10:29:29 2008 From: ache at nagual.pp.ru (Andrey Chernov) Date: Tue Jun 17 11:23:49 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <48577BD2.4070205@bluemedia.pl> References: <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> <20080617002224.GA16122@nagual.pp.ru> <20080617002808.GB16122@nagual.pp.ru> <20080617004647.GA16546@nagual.pp.ru> <48576610.9080808@FreeBSD.org> <48577510.4020007@aueb.gr> <48577BD2.4070205@bluemedia.pl> Message-ID: <20080617102900.GA46479@nagual.pp.ru> On Tue, Jun 17, 2008 at 10:54:42AM +0200, Konrad Jankowski wrote: > Diomidis Spinellis wrote: > > Gabor Kovesdan wrote: > >> In case of sort, I understarnd that it should explicitly handle wide > >> characters due to the different alphabet of the different languages > >> and yes, that seems to be a difficult task... > > > > Note that Konrad Jankowski in another SoC project is adding to our C > > library support for the Unicode collation algorithm, and importing the > > corresponding language-specific collation tables. > > > > > Yes, and once this is done, sort will work out of he box, if it uses > strcoll. Already tried on a prototype. Only GNU sort for multibyte chars. BSD sort is programmed too badly and can't be fixed even for single byte sorting. -- http://ache.pp.ru/ From ache at nagual.pp.ru Tue Jun 17 10:37:29 2008 From: ache at nagual.pp.ru (Andrey Chernov) Date: Tue Jun 17 11:24:00 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <861w2wgyqh.fsf@ds4.des.no> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> <20080617002224.GA16122@nagual.pp.ru> <861w2wgyqh.fsf@ds4.des.no> Message-ID: <20080617103708.GB46479@nagual.pp.ru> On Tue, Jun 17, 2008 at 12:08:38PM +0200, Dag-Erling Sm??rgrav wrote: > I hadn't noticed... ISTR it was an issue back when jphoward wrote his > BSD-licensed grep. BSD grep have enough (but not fatal, as BSD sort) problems even with single byte locales we support initially in our regex (old pre-multibyte versions), so lack of multibyte support there is too far seeing issue. > However, it's not the same engine - it's Spencer's old engine with > multibyte support added. IIRC, it performs very poorly compared to the > GNU regexp engine; it would be interesting to see how well the Tcl > engine performs in comparison. Yes. Upgrading to most recent engine will be nice. -- http://ache.pp.ru/ From gabor at FreeBSD.org Tue Jun 17 10:58:16 2008 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Tue Jun 17 11:24:07 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <20080617102900.GA46479@nagual.pp.ru> References: <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> <20080617002224.GA16122@nagual.pp.ru> <20080617002808.GB16122@nagual.pp.ru> <20080617004647.GA16546@nagual.pp.ru> <48576610.9080808@FreeBSD.org> <48577510.4020007@aueb.gr> <48577BD2.4070205@bluemedia.pl> <20080617102900.GA46479@nagual.pp.ru> Message-ID: <485798C4.2050605@FreeBSD.org> Andrey Chernov escribi?: > On Tue, Jun 17, 2008 at 10:54:42AM +0200, Konrad Jankowski wrote: > >> Diomidis Spinellis wrote: >> >>> Gabor Kovesdan wrote: >>> >>>> In case of sort, I understarnd that it should explicitly handle wide >>>> characters due to the different alphabet of the different languages >>>> and yes, that seems to be a difficult task... >>>> >>> Note that Konrad Jankowski in another SoC project is adding to our C >>> library support for the Unicode collation algorithm, and importing the >>> corresponding language-specific collation tables. >>> >>> >>> >> Yes, and once this is done, sort will work out of he box, if it uses >> strcoll. Already tried on a prototype. >> > > Only GNU sort for multibyte chars. BSD sort is programmed too badly and > can't be fixed even for single byte sorting. > BSD sort was going to be the next item of my SoC project. As it is so badly constructed would it be reasonable to give more priority to BSD diff and continue with that one? G?bor From gabor at FreeBSD.org Tue Jun 17 18:52:03 2008 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Tue Jun 17 18:52:10 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <4854BC29.3060507@FreeBSD.org> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> Message-ID: <485807CD.1030601@FreeBSD.org> Doug Barton escribi?: > I use the following construct in portmaster, where pdb=/var/db/pkg, > origin is set to the origin of a given port, and ro_opd is usually > empty, but can be another origin directory or the same one. To > guarantee that you should get some kind of results you can test with > origin=devel/gettext. > > egrep -l "DEPORIGIN:($origin|$ro_opd)$" $pdb/*/+CONTENTS > > Obviously this works in portmaster with the gnu grep, but if ro_opd is > unset with the bsd grep I get: > > egrep: empty (sub)expression > I've looked at this and I have a patch with a workaround: http://kovesdan.org/patches/grep.dougb.diff Could you please try it if you have some time? I suppose that it will fix your case as it has fixed the 77th Spencer test of the GNU regression test suite, which comes with GNU grep. I'm afraid there isn't a better solution as this regression is coming from the different regex interpretations between the GNU regex library and our libc regex library. regex(3) says that the RE standard has some ambiguities and the particular implementation should make a decision how to handle these cases. Regards, G?bor P.S.: Thanks for the WITHOUT_GNU_GREP knob, I hope we will make use of it soon, I'm trying to eliminate the remaining regressions. From gabor at FreeBSD.org Tue Jun 17 18:52:40 2008 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Tue Jun 17 18:52:45 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <4854BC29.3060507@FreeBSD.org> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> Message-ID: <485807F3.5000608@FreeBSD.org> Doug Barton escribi?: > I use the following construct in portmaster, where pdb=/var/db/pkg, > origin is set to the origin of a given port, and ro_opd is usually > empty, but can be another origin directory or the same one. To > guarantee that you should get some kind of results you can test with > origin=devel/gettext. > > egrep -l "DEPORIGIN:($origin|$ro_opd)$" $pdb/*/+CONTENTS > > Obviously this works in portmaster with the gnu grep, but if ro_opd is > unset with the bsd grep I get: > > egrep: empty (sub)expression > I've looked at this and I have a patch with a workaround: http://kovesdan.org/patches/grep.dougb.diff Could you please try it if you have some time? I suppose that it will fix your case as it has fixed the 77th Spencer test of the GNU regression test suite, which comes with GNU grep. I'm afraid there isn't a better solution as this regression is coming from the different regex interpretations between the GNU regex library and our libc regex library. regex(3) says that the RE standard has some ambiguities and the particular implementation should make a decision how to handle these cases. Regards, G?bor P.S.: Thanks for the WITHOUT_GNU_GREP knob, I hope we will make use of it soon, I've already eliminated some more regressions and I'm fighting with the remaining ones. From jh at saunalahti.fi Wed Jun 18 05:43:40 2008 From: jh at saunalahti.fi (Jaakko Heinonen) Date: Wed Jun 18 05:43:50 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <485807CD.1030601@FreeBSD.org> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <485807CD.1030601@FreeBSD.org> Message-ID: <20080618052347.GA1877@a91-153-120-204.elisa-laajakaista.fi> On 2008-06-17, Gabor Kovesdan wrote: > > egrep: empty (sub)expression > > > I've looked at this and I have a patch with a workaround: > http://kovesdan.org/patches/grep.dougb.diff Unfortunately this breaks things. For example: $ grep -E '(test||test)' /dev/null grep: parentheses not balanced $ grep -E '(test|\|)' /dev/null grep: parentheses not balanced $ grep -E '\(|test)' /dev/null (should give an error but it hangs) -- Jaakko From ache at nagual.pp.ru Wed Jun 18 05:59:21 2008 From: ache at nagual.pp.ru (Andrey Chernov) Date: Wed Jun 18 10:29:44 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <485798C4.2050605@FreeBSD.org> References: <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> <20080617002224.GA16122@nagual.pp.ru> <20080617002808.GB16122@nagual.pp.ru> <20080617004647.GA16546@nagual.pp.ru> <48576610.9080808@FreeBSD.org> <48577510.4020007@aueb.gr> <48577BD2.4070205@bluemedia.pl> <20080617102900.GA46479@nagual.pp.ru> <485798C4.2050605@FreeBSD.org> Message-ID: <20080618055851.GA85018@nagual.pp.ru> On Tue, Jun 17, 2008 at 12:58:12PM +0200, Gabor Kovesdan wrote: > >> Yes, and once this is done, sort will work out of he box, if it uses > >> strcoll. Already tried on a prototype. > >> > > > > Only GNU sort for multibyte chars. BSD sort is programmed too badly and > > can't be fixed even for single byte sorting. > > > BSD sort was going to be the next item of my SoC project. As it is so > badly constructed would it be reasonable to give more priority to BSD > diff and continue with that one? "BSD sort" as an idea will be a good project indeed, but "BSD sort" implementation we currently have at hand is totally misleading and should be rewritten from the scratch, I realize it when long time ago I try to localize it for single byte locales. The next nice idea in that area will be updating our regexp engine to most recent public code, both for speed and minor compatibility reasons, as des@ mentions. I don't have an opinion for BSD diff. -- http://ache.pp.ru/ From des at des.no Wed Jun 18 08:22:35 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Jun 18 10:29:52 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <20080618055851.GA85018@nagual.pp.ru> (Andrey Chernov's message of "Wed\, 18 Jun 2008 09\:58\:51 +0400") References: <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> <20080617002224.GA16122@nagual.pp.ru> <20080617002808.GB16122@nagual.pp.ru> <20080617004647.GA16546@nagual.pp.ru> <48576610.9080808@FreeBSD.org> <48577510.4020007@aueb.gr> <48577BD2.4070205@bluemedia.pl> <20080617102900.GA46479@nagual.pp.ru> <485798C4.2050605@FreeBSD.org> <20080618055851.GA85018@nagual.pp.ru> Message-ID: <86zlpjduew.fsf@ds4.des.no> Andrey Chernov writes: > "BSD sort" as an idea will be a good project indeed, but "BSD sort" > implementation we currently have at hand is totally misleading and should > be rewritten from the scratch, I realize it when long time ago I try to > localize it for single byte locales. I think part of the problem is that there aren't enough people who truly understand localization. I think I understand most of it, but I'm pretty sure I *don't* understand how collation works, or is supposed to work. Amongst other things, I don't understand how (or whether) it handles cases like "aa" and "?", which are considered the same letter in Norwegian. Perhaps you could create a Localization page on wiki.freebsd.org which addresses these issues, or at least points to relevant resources? DES -- Dag-Erling Sm?rgrav - des@des.no From ache at nagual.pp.ru Wed Jun 18 08:38:10 2008 From: ache at nagual.pp.ru (Andrey Chernov) Date: Wed Jun 18 10:30:01 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <86zlpjduew.fsf@ds4.des.no> References: <20080617002224.GA16122@nagual.pp.ru> <20080617002808.GB16122@nagual.pp.ru> <20080617004647.GA16546@nagual.pp.ru> <48576610.9080808@FreeBSD.org> <48577510.4020007@aueb.gr> <48577BD2.4070205@bluemedia.pl> <20080617102900.GA46479@nagual.pp.ru> <485798C4.2050605@FreeBSD.org> <20080618055851.GA85018@nagual.pp.ru> <86zlpjduew.fsf@ds4.des.no> Message-ID: <20080618083739.GA87100@nagual.pp.ru> On Wed, Jun 18, 2008 at 10:22:31AM +0200, Dag-Erling Sm??rgrav wrote: > I think part of the problem is that there aren't enough people who truly > understand localization. I think I understand most of it, but I'm > pretty sure I *don't* understand how collation works, or is supposed to > work. Amongst other things, I don't understand how (or whether) it > handles cases like "aa" and "??", which are considered the same letter in > Norwegian. Single byte locales collation works through strcoll() via chains, i.e. seek all chains starting with given letter. Multibyte locales collation currently is not implemented and can't be properly implemented under existen single byte framework (it will consume resourses badly in that case). I know semi-hacking attempts to implement multibyte collattion via single byte one, but all they are only for small ASCII + national alphabet subset, rest of Unicode left unsorted. > Perhaps you could create a Localization page on wiki.freebsd.org which > addresses these issues, or at least points to relevant resources? IMHO single byte collating will be obsolete soon when Unicode collation will be implemented as SoC project, we needs something like ICU library which performs as described below, i.e. unified sorting for all possible chars: http://unicode.org/reports/tr10/ -- http://ache.pp.ru/ From des at des.no Wed Jun 18 09:39:14 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Jun 18 10:30:06 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <20080618083739.GA87100@nagual.pp.ru> (Andrey Chernov's message of "Wed\, 18 Jun 2008 12\:37\:39 +0400") References: <20080617002224.GA16122@nagual.pp.ru> <20080617002808.GB16122@nagual.pp.ru> <20080617004647.GA16546@nagual.pp.ru> <48576610.9080808@FreeBSD.org> <48577510.4020007@aueb.gr> <48577BD2.4070205@bluemedia.pl> <20080617102900.GA46479@nagual.pp.ru> <485798C4.2050605@FreeBSD.org> <20080618055851.GA85018@nagual.pp.ru> <86zlpjduew.fsf@ds4.des.no> <20080618083739.GA87100@nagual.pp.ru> Message-ID: <867icndqv5.fsf@ds4.des.no> Andrey Chernov writes: > Single byte locales collation works through strcoll() via chains, i.e. > seek all chains starting with given letter. Multibyte locales collation > currently is not implemented and can't be properly implemented under > existen single byte framework (it will consume resourses badly in that > case). I know semi-hacking attempts to implement multibyte collattion via > single byte one, but all they are only for small ASCII + national alphabet > subset, rest of Unicode left unsorted. Does that mean our wcsxfrm() doesn't work? IIUC, it should convert wide strings to strings that can be compared directly with strcmp()? In any case, this is a libc issue, right? As long as sort / grep uses the API correctly, they will work fine once libc is fixed? DES -- Dag-Erling Sm?rgrav - des@des.no From des at des.no Wed Jun 18 10:40:27 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Jun 18 10:47:08 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <4858DBF6.5070001@bluemedia.pl> (Konrad Jankowski's message of "Wed\, 18 Jun 2008 11\:57\:10 +0200") References: <20080617002224.GA16122@nagual.pp.ru> <20080617002808.GB16122@nagual.pp.ru> <20080617004647.GA16546@nagual.pp.ru> <48576610.9080808@FreeBSD.org> <48577510.4020007@aueb.gr> <48577BD2.4070205@bluemedia.pl> <20080617102900.GA46479@nagual.pp.ru> <485798C4.2050605@FreeBSD.org> <20080618055851.GA85018@nagual.pp.ru> <86zlpjduew.fsf@ds4.des.no> <20080618083739.GA87100@nagual.pp.ru> <867icndqv5.fsf@ds4.des.no> <4858DBF6.5070001@bluemedia.pl> Message-ID: <86skvbc9gn.fsf@ds4.des.no> Konrad Jankowski writes: > Dag-Erling Sm?rgrav writes: > > In any case, this is a libc issue, right? As long as sort / grep > > uses the API correctly, they will work fine once libc is fixed? > Correct. Given sort uses strcoll()/wcscoll()/strxfrm()/wcsxfrm() and > call setlocale(). I don't know about grep. For grep, I believe it should simply be a matter of calling setlocale(), using wide strings, and using a multibyte regex engine (for appropriate values of "simply"). Another thing I'm unsure about is the matter of input and output. Do mbstowcs() / mbtowc() simply trust the input to conform to LC_CTYPE and convert accordingly? When reading UTF, do they recognize and handle BOMs, or simply treat them as zero-width non-breaking space? In the absence of a BOM, do they assume that the input follows the system's native byte order? (IMHO, the API is broken, since there is no way for the same program to simultaneously handle streams with different encodings, but I guess it's too late to fix that) DES -- Dag-Erling Sm?rgrav - des@des.no From ache at nagual.pp.ru Wed Jun 18 11:44:59 2008 From: ache at nagual.pp.ru (Andrey Chernov) Date: Wed Jun 18 12:15:08 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <867icndqv5.fsf@ds4.des.no> References: <20080617004647.GA16546@nagual.pp.ru> <48576610.9080808@FreeBSD.org> <48577510.4020007@aueb.gr> <48577BD2.4070205@bluemedia.pl> <20080617102900.GA46479@nagual.pp.ru> <485798C4.2050605@FreeBSD.org> <20080618055851.GA85018@nagual.pp.ru> <86zlpjduew.fsf@ds4.des.no> <20080618083739.GA87100@nagual.pp.ru> <867icndqv5.fsf@ds4.des.no> Message-ID: <20080618114428.GA89383@nagual.pp.ru> On Wed, Jun 18, 2008 at 11:39:10AM +0200, Dag-Erling Sm??rgrav wrote: > Does that mean our wcsxfrm() doesn't work? IIUC, it should convert > wide strings to strings that can be compared directly with strcmp()? (directly with wcscmp()) For single byte locales wcsxfrm() and wcscoll() works, but for multibyte they do just raw binary. > In any case, this is a libc issue, right? As long as sort / grep uses > the API correctly, they will work fine once libc is fixed? GNU grep and sort will work just fine. BSD grep not calls setlocale() but even it will be added, BSD grep have other places where multibyte is not handled proberly. I already notice two of them: ignore case comparison and word boundary sensing, perhaps other places exists, I not study the code enough to cach them all. BSD sort uses upper half of 256 char table on its own purposes so badly damage both single byte and multibyte locales and of couse not use wcscoll() at all etc. -- http://ache.pp.ru/ From ache at nagual.pp.ru Wed Jun 18 11:49:43 2008 From: ache at nagual.pp.ru (Andrey Chernov) Date: Wed Jun 18 12:25:56 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <86skvbc9gn.fsf@ds4.des.no> References: <48577510.4020007@aueb.gr> <48577BD2.4070205@bluemedia.pl> <20080617102900.GA46479@nagual.pp.ru> <485798C4.2050605@FreeBSD.org> <20080618055851.GA85018@nagual.pp.ru> <86zlpjduew.fsf@ds4.des.no> <20080618083739.GA87100@nagual.pp.ru> <867icndqv5.fsf@ds4.des.no> <4858DBF6.5070001@bluemedia.pl> <86skvbc9gn.fsf@ds4.des.no> Message-ID: <20080618114917.GB89383@nagual.pp.ru> On Wed, Jun 18, 2008 at 12:40:24PM +0200, Dag-Erling Sm??rgrav wrote: > For grep, I believe it should simply be a matter of calling setlocale(), > using wide strings, and using a multibyte regex engine (for appropriate > values of "simply"). See my prev reply telling more details. Using wide strings is not so easy, f.e. all ctype BSD grep now uses should be converted to wctype, input conversion added, etc. > Another thing I'm unsure about is the matter of input and output. Do > mbstowcs() / mbtowc() simply trust the input to conform to LC_CTYPE and > convert accordingly? When reading UTF, do they recognize and handle They return EILSEQ on wrong sequence. -- http://ache.pp.ru/ From ache at nagual.pp.ru Wed Jun 18 11:52:18 2008 From: ache at nagual.pp.ru (Andrey Chernov) Date: Wed Jun 18 12:25:56 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <4858D1E8.3050104@bluemedia.pl> References: <20080617002808.GB16122@nagual.pp.ru> <20080617004647.GA16546@nagual.pp.ru> <48576610.9080808@FreeBSD.org> <48577510.4020007@aueb.gr> <48577BD2.4070205@bluemedia.pl> <20080617102900.GA46479@nagual.pp.ru> <485798C4.2050605@FreeBSD.org> <20080618055851.GA85018@nagual.pp.ru> <86zlpjduew.fsf@ds4.des.no> <4858D1E8.3050104@bluemedia.pl> Message-ID: <20080618115152.GC89383@nagual.pp.ru> On Wed, Jun 18, 2008 at 11:14:16AM +0200, Konrad Jankowski wrote: > I think the best place for this type of information is currently my SoC > wiki. > http://wiki.freebsd.org/KonradJankowski/Collation > I know currently it has very little information, however. > I can also create another page dedicated to explaining the workings of > collation in UCA, given enough interest. Please look at ICU library. Almong other thing they implement Unicode collation: http://icu-project.org/userguide/Collate_Intro.html -- http://ache.pp.ru/ From stephen.hocking at gmail.com Wed Jun 18 12:40:13 2008 From: stephen.hocking at gmail.com (Stephen Hocking) Date: Wed Jun 18 12:40:18 2008 Subject: Decent 3D acceleration in 64bit mode? Message-ID: <6300771b0806180513l469d6915y378400d728c12475@mail.gmail.com> Hi, Given that Nvidia aren't offering a driver for their cards for 64bit FreeBSD, is anyone else having success using another (preferably PCI-E) card with 3D acceleration? Stephen From jhb at freebsd.org Wed Jun 18 13:19:41 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Jun 18 13:19:54 2008 Subject: FreeBSD 6.3 deadlock (vm_map?) with DDB output In-Reply-To: <20080615112318.146C1F18512@mx.npubs.com> References: <20080615112318.146C1F18512@mx.npubs.com> Message-ID: <200806180917.05689.jhb@freebsd.org> On Sunday 15 June 2008 07:23:19 am Stef Walter wrote: > I've been trying to track down a deadlock on some newish production > servers running FreeBSD 6.3-RELEASE-p2. The deadlock occurs on a > specific (although mundane) hardware configuration, and each of several > servers running this hardware deadlock about once per week. > > Although I suspect that this is not hardware related, from a (naive) > perusal of the attached stack traces. > > Forgive me if my interpretation of this is all wrong, but I'm pretty > desperate for help. So here's my basic understanding of the deadlock: > > These processes seem to be waiting on the page queue mutex: > sendmail (in vm_mmap > vm_map_find > vm_map_insert > vm_map_pmap_enter) > bsnmpd (in malloc, uma_large_malloc > page_alloc > kmem_malloc) > httpd (in trap > trap_pfault > vm_fault) > [g_up] (in g_vfs_done > bufdone) > > The page queue mutex is held by rsync process: > rsync (in trap > trap_pfault > vm_fault > pmap_enter) > > Rsync kernel process (in pmap_enter) was interrupted while holding the > page queue lock? > > > Giant is enabled in loader.conf due to the needs of the pf firewall when > dealing with user credentials lookups. I do not believe that Giant plays > into this deadlock. Kernel config attached. > > Any and all help or info is welcome. Thanks in advance. Try this change: jhb 2007-10-27 22:07:40 UTC FreeBSD src repository Modified files: sys/kern sched_4bsd.c Log: Change the roundrobin implementation in the 4BSD scheduler to trigger a userland preemption directly from hardclock() via sched_clock() when a thread uses up a full quantum instead of using a periodic timeout to cause a userland preemption every so often. This fixes a potential deadlock when IPI_PREEMPTION isn't enabled where softclock blocks on a lock held by a thread pinned or bound to another CPU. The current thread on that CPU will never be preempted while softclock is blocked. Note that ULE already drives its round-robin userland preemption from sched_clock() as well and always enables IPI_PREEMPT. MFC after: 1 week Revision Changes Path 1.108 +8 -29 src/sys/kern/sched_4bsd.c We use it at work on 6.x. W/o this fix, round-robin stops working on 4BSD when softclock() (swi4: clock) blocks on a lock like Giant. -- John Baldwin From pisymbol at gmail.com Wed Jun 18 14:19:00 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Wed Jun 18 14:19:06 2008 Subject: How do I list what CPU core is on what package? Message-ID: <3c0b01820806180651i509a223dy7d50d3cb2a0a2b68@mail.gmail.com> Hi Everybody: Simple question, if I want to know if a cpu X is on a particular package is there an easy way to list this? Normally my understanding is on most machines, every other LAPIC id is on the same package. So 0,2,4,6 would be on one package and 1,3,5,7 would be on another (say in a 2-way quad-core) and I am assuming (I haven't checked source) that the OS lists them in LAPIC order. Thanks! -aps From stef at memberwebs.com Wed Jun 18 17:25:56 2008 From: stef at memberwebs.com (Stef) Date: Wed Jun 18 18:21:56 2008 Subject: FreeBSD 6.3 deadlock (vm_map?) with DDB output References: <20080615112318.146C1F18512@mx.npubs.com> <200806180917.05689.jhb@freebsd.org> Message-ID: <20080618172554.CCAB4F18047@mx.npubs.com> John Baldwin wrote: > Try this change: > > jhb 2007-10-27 22:07:40 UTC > We use it at work on 6.x. W/o this fix, round-robin stops working on 4BSD > when softclock() (swi4: clock) blocks on a lock like Giant. Awesome. Thanks. That looks like it'll do the trick. I'll deploy it and keep the list posted. Stef From scf at FreeBSD.org Wed Jun 18 21:46:48 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Wed Jun 18 21:46:56 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <86bq211rqw.fsf@ds4.des.no> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <4854C96A.1080603@aueb.gr> <48556AAD.9010602@t-hosting.hu> <20080615212613.GA97326@nagual.pp.ru> <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> Message-ID: On Mon, 16 Jun 2008, Dag-Erling Sm?rgrav wrote: > Doug Barton writes: >> Andrey Chernov writes: >>> Please note that BSD grep is not localized (and can't be per design) >>> and works only with standard C locale. It may not affect ports >>> system processing but shurely affects real texts handling. >> That is very troubling. In this day and age localization is a >> requirement. I cannot imagine being supportive of adding something to >> the base that does not have this capability. > > We don't have a locale-aware regex implementation. Henry Spencer wrote > one for Tcl 8, and it seems to be under an MIT-equivalent license, but > I'm not sure how hard it would be to extirpate. It might be easier to > lift it from PostgreSQL, which also uses it. Other BSD-license-friendly regex libraries: 1. PCRE (http://www.pcre.org/) (has a POSIX compliant interface too) 2. Oniguruma (http://www.geocities.jp/kosako3/oniguruma/) (from Ruby) 3. Lrexlib (http://lrexlib.luaforge.net/) (no apparent POSIX interface) Sean -- scf@FreeBSD.org From sobomax at FreeBSD.ORG Wed Jun 18 23:07:38 2008 From: sobomax at FreeBSD.ORG (Maxim Sobolev) Date: Wed Jun 18 23:21:50 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <86zlpjduew.fsf@ds4.des.no> References: <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> <20080617002224.GA16122@nagual.pp.ru> <20080617002808.GB16122@nagual.pp.ru> <20080617004647.GA16546@nagual.pp.ru> <48576610.9080808@FreeBSD.org> <48577510.4020007@aueb.gr> <48577BD2.4070205@bluemedia.pl> <20080617102900.GA46479@nagual.pp.ru> <485798C4.2050605@FreeBSD.org> <20080618055851.GA85018@nagual.pp.ru> <86zlpjduew.fsf@ds4.des.no> Message-ID: <48598C6D.4040102@FreeBSD.org> Dag-Erling Sm?rgrav wrote: > Andrey Chernov writes: >> "BSD sort" as an idea will be a good project indeed, but "BSD sort" >> implementation we currently have at hand is totally misleading and should >> be rewritten from the scratch, I realize it when long time ago I try to >> localize it for single byte locales. > > I think part of the problem is that there aren't enough people who truly > understand localization. I think I understand most of it, but I'm > pretty sure I *don't* understand how collation works, or is supposed to > work. Amongst other things, I don't understand how (or whether) it > handles cases like "aa" and "?", which are considered the same letter in > Norwegian. > > Perhaps you could create a Localization page on wiki.freebsd.org which > addresses these issues, or at least points to relevant resources? Good regression test suite which would include cases in different single and multi-byte locates for grep/sort/etc could also be a big help. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com From vvelox at vvelox.net Thu Jun 19 00:17:07 2008 From: vvelox at vvelox.net (Zane C.B.) Date: Thu Jun 19 02:31:48 2008 Subject: adding sysctls Message-ID: <20080618185810.5c121531@vixen42> Any one know of any recent documentation for adding a sysctl to a kernel module for FreeBSD 6 and 7? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080619/5e4db1f9/signature.pgp From dnelson at allantgroup.com Thu Jun 19 03:37:50 2008 From: dnelson at allantgroup.com (Dan Nelson) Date: Thu Jun 19 03:38:05 2008 Subject: adding sysctls In-Reply-To: <20080618185810.5c121531@vixen42> References: <20080618185810.5c121531@vixen42> Message-ID: <20080619030355.GA9700@dan.emsphone.com> In the last episode (Jun 18), Zane C.B. said: > Any one know of any recent documentation for adding a sysctl to a > kernel module for FreeBSD 6 and 7? man 9 sysctl -- Dan Nelson dnelson@allantgroup.com From lstewart at room52.net Thu Jun 19 03:45:07 2008 From: lstewart at room52.net (Lawrence Stewart) Date: Thu Jun 19 03:45:16 2008 Subject: adding sysctls In-Reply-To: <20080618185810.5c121531@vixen42> References: <20080618185810.5c121531@vixen42> Message-ID: <4859CF6C.80201@room52.net> Zane C.B. wrote: > Any one know of any recent documentation for adding a sysctl to a > kernel module for FreeBSD 6 and 7? This might help: Title: "An Introduction to FreeBSD 6 Kernel Hacking" URL: http://caia.swin.edu.au/reports/070622A/CAIA-TR-070622A.pdf Disclaimer: I co-wrote it. Cheers, Lawrence From contact at doostang.com Thu Jun 19 06:09:59 2008 From: contact at doostang.com (Huy Ton-That) Date: Thu Jun 19 06:10:03 2008 Subject: I've added you as a friend on Doostang Message-ID: <4859f47f8a305_1356155555588f08166839e0@70955-30.70955.com.tmail> Hi, I?ve requested to add you as a friend on Doostang, an invite-only career community started at Harvard, Stanford, and MIT. You can use Doostang to find a job or internship, network, and access valuable career information from peers and industry professionals. Regards, Huy To accept this invitation, please visit: http://www.doostang.com/s/u?s=GPWsZraXuW ----------------------------------------------------------- If you don't want to receive future invitations or emails from Doostang, click here: http://www.doostang.com/logins/noemail?arg=200d26c9721196d0d5ca76a9d231b0fc4a6c2d98 From guru at unixarea.de Thu Jun 19 08:27:44 2008 From: guru at unixarea.de (Matthias Apitz) Date: Thu Jun 19 08:27:48 2008 Subject: moving FreeBSD installation disk1 to an USB stick Message-ID: <20080619082740.GA3700@rebelion.Sisis.de> Hello, I'm preparing the installation of FreeBSD 7.0 on an Asus eeePC which has no CD/DVD drive for the installation (and I have no external CD driver with USB): http://www.laptoppen.nl/product-260-Asus-EEE-PC-900-Zwart.html My idea is to 'copy' somehow the FreeBSD 7.0 installation disk1 to an USB stick of 1 GByte; there is some kind of recipe how to put a boot-able system onto such an USB stick, like; http://groups.google.com/group/lucky.freebsd.questions/msg/5c759b1c87376b22 but this is not what I want; I want to boot the stick (of course) and run the 'sysinstall' having the complete disk1 on the stick; maybe it is an option making only the file system on the stick and the boot sector and fill in a dump of the file system of disk1, with some minor changes that after booting it uses the USB as CD device? any other ideas? Thx in advance matthias -- Matthias Apitz e - w http://www.UnixArea.de/ Irland - EU 1:0 From gahr at FreeBSD.org Thu Jun 19 08:50:34 2008 From: gahr at FreeBSD.org (Pietro Cerutti) Date: Thu Jun 19 08:50:41 2008 Subject: adding sysctls In-Reply-To: <20080618185810.5c121531@vixen42> References: <20080618185810.5c121531@vixen42> Message-ID: <485A1DCE.7030904@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Zane C.B. wrote: | Any one know of any recent documentation for adding a sysctl to a | kernel module for FreeBSD 6 and 7? In addition to the what pointed out by others, I would recommend to look into /usr/share/examples/kld/dyn_sysctl for an example. - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkhaHc0ACgkQwMJqmJVx946RYgCfcSCxyJKnHwVOAnoVv2E1i7PX g7cAoN9FohQIJZSd0TclD4Sd2ApKrwyP =CbOs -----END PGP SIGNATURE----- From ed at 80386.nl Thu Jun 19 09:14:33 2008 From: ed at 80386.nl (Ed Schouten) Date: Thu Jun 19 09:14:37 2008 Subject: moving FreeBSD installation disk1 to an USB stick In-Reply-To: <20080619082740.GA3700@rebelion.Sisis.de> References: <20080619082740.GA3700@rebelion.Sisis.de> Message-ID: <20080619091432.GG93496@hoeg.nl> Hello Matthias, * Matthias Apitz wrote: > > Hello, > > I'm preparing the installation of FreeBSD 7.0 on an Asus eeePC which has > no CD/DVD drive for the installation (and I have no external CD driver > with USB): > http://www.laptoppen.nl/product-260-Asus-EEE-PC-900-Zwart.html > > My idea is to 'copy' somehow the FreeBSD 7.0 installation disk1 to an > USB stick of 1 GByte; there is some kind of recipe how to put a boot-able > system onto such an USB stick, like; > http://groups.google.com/group/lucky.freebsd.questions/msg/5c759b1c87376b22 > but this is not what I want; I want to boot the stick (of course) and > run the 'sysinstall' having the complete disk1 on the stick; > > maybe it is an option making only the file system on the stick and the > boot sector and fill in a dump of the file system of disk1, with some > minor changes that after booting it uses the USB as CD device? > > any other ideas? You could consider installing FreeBSD by hand. Just make sure you get a bootable FreeBSD system on that USB stick and do this: bsdlabel -w -B /dev/ad0 # assuming ad0 is the eeepc flash # just do bsdlabel -e /dev/ad0 if you want to add multiple slices for i in a d e f g ... # any partitions you have do newfs -U -O 2 /dev/ad0$i done # mount all your partitions in /new mkdir /new mount /dev/ad0a /new mkdir /new/var mount /dev/ad0d /var # make sure you have the `base' and `kernels' directories on # your USB stick and do this: cd /X.Y-RELEASE/base DESTDIR=/new sh install.sh cd ../kernels DESTDIR=/new sh install.sh generic mv /boot/GENERIC/* /boot/kernel/ # create a /etc/fstab file vi /etc/fstab Good luck! -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080619/5bbd44f5/attachment.pgp From guru at unixarea.de Thu Jun 19 09:26:45 2008 From: guru at unixarea.de (Matthias Apitz) Date: Thu Jun 19 09:26:51 2008 Subject: moving FreeBSD installation disk1 to an USB stick In-Reply-To: <20080619091432.GG93496@hoeg.nl> References: <20080619082740.GA3700@rebelion.Sisis.de> <20080619091432.GG93496@hoeg.nl> Message-ID: <20080619092640.GA5246@rebelion.Sisis.de> El d?a Thursday, June 19, 2008 a las 11:14:32AM +0200, Ed Schouten escribi?: > You could consider installing FreeBSD by hand. Just make sure you > get a bootable FreeBSD system on that USB stick and do this: > > bsdlabel -w -B /dev/ad0 # assuming ad0 is the eeepc flash > # just do bsdlabel -e /dev/ad0 if you want to add multiple slices > for i in a d e f g ... # any partitions you have > do > newfs -U -O 2 /dev/ad0$i > done > > # mount all your partitions in /new > mkdir /new > mount /dev/ad0a /new > mkdir /new/var > mount /dev/ad0d /var > > # make sure you have the `base' and `kernels' directories on > # your USB stick and do this: > cd /X.Y-RELEASE/base > DESTDIR=/new sh install.sh > cd ../kernels > DESTDIR=/new sh install.sh generic > mv /boot/GENERIC/* /boot/kernel/ > > # create a /etc/fstab file > vi /etc/fstab > > Good luck! Thanks, Ed, for this hint; this is also more or less how the recipe is to make that boot-able USB stick; I've just played around with /usr/sbin/sysinstall and realised (what I've never used before) that you can choose as installation source also any point in the file system; so if I put /packages from disk1 to the USB stick as well I could perhaps mount it after booting it and run /usr/sbin/sysinstall and point it to that directory. Will let you know once the beast arrives here. Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ ?...una sola vez, que es cuanto basta si se trata de verdades definitivas.? ?...only once, which is enough if it has todo with definite truth.? Jos? Saramago, Historia del Cerca de Lisboa From konrad.jankowski at bluemedia.pl Thu Jun 19 10:37:51 2008 From: konrad.jankowski at bluemedia.pl (Konrad Jankowski) Date: Thu Jun 19 11:29:17 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <48598C6D.4040102@FreeBSD.org> References: <4855EDFE.3010708@FreeBSD.org> <86bq211rqw.fsf@ds4.des.no> <20080617002224.GA16122@nagual.pp.ru> <20080617002808.GB16122@nagual.pp.ru> <20080617004647.GA16546@nagual.pp.ru> <48576610.9080808@FreeBSD.org> <48577510.4020007@aueb.gr> <48577BD2.4070205@bluemedia.pl> <20080617102900.GA46479@nagual.pp.ru> <485798C4.2050605@FreeBSD.org> <20080618055851.GA85018@nagual.pp.ru> <86zlpjduew.fsf@ds4.des.no> <48598C6D.4040102@FreeBSD.org> Message-ID: <485A36F6.9020100@bluemedia.pl> Maxim Sobolev wrote: > Good regression test suite which would include cases in different > single and multi-byte locates for grep/sort/etc could also be a big help. I will implement test cases for sort in UTF-8 as part of my project. From des at des.no Thu Jun 19 11:43:18 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Jun 19 11:47:33 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] References: <20080617002224.GA16122@nagual.pp.ru> <20080617002808.GB16122@nagual.pp.ru> <20080617004647.GA16546@nagual.pp.ru> <48576610.9080808@FreeBSD.org> <48577510.4020007@aueb.gr> <48577BD2.4070205@bluemedia.pl> <20080617102900.GA46479@nagual.pp.ru> <485798C4.2050605@FreeBSD.org> <20080618055851.GA85018@nagual.pp.ru> <86zlpjduew.fsf@ds4.des.no> <20080618083739.GA87100@nagual.pp.ru> <867icndqv5.fsf@ds4.des.no> <4858DBF6.5070001@bluemedia.pl> <86skvbc9gn.fsf@ds4.des.no> <485A35EB.7000004@bluemedia.pl> Message-ID: <86hcbphcqi.fsf@ds4.des.no> Konrad Jankowski writes: > BOM's should be handled at the program level. Yeah, that makes sense; libc has no way of knowing whether the start of the string you're processing is actually the start of the file. DES -- Dag-Erling Sm?rgrav - des@des.no From olli at lurza.secnetix.de Thu Jun 19 13:07:45 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Jun 19 13:07:49 2008 Subject: moving FreeBSD installation disk1 to an USB stick In-Reply-To: <20080619082740.GA3700@rebelion.Sisis.de> Message-ID: <200806191236.m5JCa3Fo078445@lurza.secnetix.de> Matthias Apitz wrote: > I'm preparing the installation of FreeBSD 7.0 on an Asus eeePC which has > no CD/DVD drive for the installation (and I have no external CD driver > with USB): > http://www.laptoppen.nl/product-260-Asus-EEE-PC-900-Zwart.html > > My idea is to 'copy' somehow the FreeBSD 7.0 installation disk1 to an > USB stick of 1 GByte; there is some kind of recipe how to put a boot-able > system onto such an USB stick, like; > http://groups.google.com/group/lucky.freebsd.questions/msg/5c759b1c87376b22 > but this is not what I want; I want to boot the stick (of course) and > run the 'sysinstall' having the complete disk1 on the stick; > > maybe it is an option making only the file system on the stick and the > boot sector and fill in a dump of the file system of disk1, Yes, that should work. Just prepare the USB stick so it is bootable (fdisk(1), bsdlabel(8)), put a UFS file system on it (newfs(8)), then extract the contents of the "disk1" ISO image onto the file system. You can use tar for that: # cd /mnt ; tar xf /tmp/disk1.iso > with some minor changes that after booting it uses the USB as CD device? No, I don't think that's possible. And it's not necessary. sysinstall can install from a normal UFS partition. Best regards Oliver -- 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 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From pisymbol at gmail.com Thu Jun 19 13:29:39 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Thu Jun 19 13:29:43 2008 Subject: Cross platform building best practices (building 6 on 7) Message-ID: <3c0b01820806190629o7264cfaeg6fa6a08a6822047e@mail.gmail.com> Hello Folks: I've done a lot of Googling and scouring the lists about this particular subject so I apologize for rehashing it. However, I'm still confused on what's the best way to perform BSD cross platform builds. Ideally what I want to have is an environment whereby I can build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I could check out a 6.1 release version, perform make world, and then use the output of that build as either a basis for a jail or a toolchain. However, as noted by previous threads, 6.x doesn't build on a 7.x due to gcc4/binutils compatibility issues (please correct me if I'm wrong). I then thought I could potentially download a patched binutils, copy it into src/contrib/binutils and that would potentially fix it. No dice (and I'm still debugging why since this binutils package DOES build outside of the make world infrastructure without issue, this very well could be pilot error on my part since I didn't update the VERSION string and didn't trim the source files as per the FreeBSD-deleteList etc.). I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could complie a 6.x on a 7.x machine. Well I haven't done that yet since at this point I believe I'm diverged from the path of FreeBSD build enlightenment! Moreover, if would be NICE if I could bootstrap the normal dev tools from the exiting make world build tree. I'm not yet ready for a lot of hackery on the build tree without asking around. :D! Does anyone due cross-platform builds (without host virtualization)? Thanks! -aps From sebastian.tymkow at gmail.com Thu Jun 19 13:55:58 2008 From: sebastian.tymkow at gmail.com (=?ISO-8859-1?Q?Sebastian_Tymk=F3w?=) Date: Thu Jun 19 13:56:03 2008 Subject: FreeBSD 7.0 own installation Message-ID: <692660060806190627l6c3eb6e8oaff08dac0281997@mail.gmail.com> Hi, I need to create my own installation disk. Is there any solution to create own release without in example sendmail. I made some scripts and included them in /usr/src/release/Makefile to install some ports to iso ( I know I can do post-install but for some reasons I'd like to do it). Maybe there is better solution to create bootable iso than using make release which creates chroot environment and recreate world once again ? Another question, is there any possibility to simply add gjournal to sysinstall to use it during installation? I wan't to create as easy installation as is possible ( I don't want to play with fixit mode). Best regards, Sebastian Tymkow From yanefbsd at gmail.com Thu Jun 19 15:15:16 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Jun 19 15:15:19 2008 Subject: FreeBSD 7.0 own installation In-Reply-To: <692660060806190627l6c3eb6e8oaff08dac0281997@mail.gmail.com> References: <692660060806190627l6c3eb6e8oaff08dac0281997@mail.gmail.com> Message-ID: <7d6fde3d0806190815g984c8f7k37322cf14d93d3bd@mail.gmail.com> On Thu, Jun 19, 2008 at 6:27 AM, Sebastian Tymk?w wrote: > Hi, > > I need to create my own installation disk. > Is there any solution to create own release without in example sendmail. > I made some scripts and included them in /usr/src/release/Makefile > to install some ports to iso ( I know I can do post-install but for some > reasons > I'd like to do it). > Maybe there is better solution to create bootable iso than using make > release > which creates chroot environment and recreate world once again ? > Another question, is there any possibility to simply add gjournal to > sysinstall to use it during installation? > I wan't to create as easy installation as is possible ( I don't want to play > with fixit mode). > > > Best regards, > > Sebastian Tymkow I'd read `man src.conf' (note the WITHOUT_* variables), and you probably should ask this type of a question on questions@ next time (it's a bit more fitting to be discussed there). Apart from that you should be able to grab whatever binaries you want with custom scripts, similar to what NanoBSD [1] does... Good luck though, -Garrett 1. http://www.freebsd.org/doc/en/articles/nanobsd/index.html From yanefbsd at gmail.com Thu Jun 19 15:22:51 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Jun 19 15:22:57 2008 Subject: Cross platform building best practices (building 6 on 7) In-Reply-To: <3c0b01820806190629o7264cfaeg6fa6a08a6822047e@mail.gmail.com> References: <3c0b01820806190629o7264cfaeg6fa6a08a6822047e@mail.gmail.com> Message-ID: <7d6fde3d0806190822s1420dcake3a38be7189b8ab0@mail.gmail.com> On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack wrote: > Hello Folks: > > I've done a lot of Googling and scouring the lists about this > particular subject so I apologize for rehashing it. However, I'm > still confused on what's the best way to perform BSD cross platform > builds. Ideally what I want to have is an environment whereby I can > build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I > could check out a 6.1 release version, perform make world, and then > use the output of that build as either a basis for a jail or a > toolchain. However, as noted by previous threads, 6.x doesn't build > on a 7.x due to gcc4/binutils compatibility issues (please correct me > if I'm wrong). I then thought I could potentially download a patched > binutils, copy it into src/contrib/binutils and that would potentially > fix it. No dice (and I'm still debugging why since this binutils > package DOES build outside of the make world infrastructure without > issue, this very well could be pilot error on my part since I didn't > update the VERSION string and didn't trim the source files as per the > FreeBSD-deleteList etc.). > > I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could > complie a 6.x on a 7.x machine. Well I haven't done that yet since at > this point I believe I'm diverged from the path of FreeBSD build > enlightenment! Moreover, if would be NICE if I could bootstrap the > normal dev tools from the exiting make world build tree. I'm not yet > ready for a lot of hackery on the build tree without asking around. > :D! > > Does anyone due cross-platform builds (without host virtualization)? > > Thanks! > > -aps (I'll stick to just hackers@ because I don't want to pollute questions@ unnecessarily) You touched on an important point. There were some code quality issues (I think) with 6.x that were resolved moving to 7.x, which caused gcc-4.2.x to barf. gcc-4.2.x requires a newer version of binutils, just because (for API / usage compatibility). What you should probably do is create a jail then do your development for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...) do 8.x development in yet a third. Jail's are a much better way to isolate things such that you don't have to worry about toolchain issues like these and are able to setup a sourcebase as the devs intended it (for the most part; you may run into issues with sysctls and virtual kernel stuff like that, but cest la vie... there isn't a better way I know of than that outside of running a VM). -Garrett From jeremie at le-hen.org Thu Jun 19 15:35:21 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Thu Jun 19 15:35:26 2008 Subject: Integration of ProPolice in FreeBSD In-Reply-To: <20080614182623.F66582@fledge.watson.org> References: <20080612184237.GC15774@obiwan.tataz.chchile.org> <20080614182623.F66582@fledge.watson.org> Message-ID: <20080619153105.GL46885@obiwan.tataz.chchile.org> Hi Robert, hi all, On Sat, Jun 14, 2008 at 06:27:30PM +0100, Robert Watson wrote: > > On Thu, 12 Jun 2008, Jeremie Le Hen wrote: > > > (This mail has already been sent to -arch@. I'm sending it here now for a > > wider audience because I really need testers.) > > Dear Jeremie, > > Unfortunately, I can't lend my hands to this project as they're currently > full of other stuff. However, I would really be very pleased to see is > [finally] ship a release with ProPolice enabled. We're definitely trailing > the pack in this regard, and I think it's bad practice to not ship with what > are considered industry-standard protections here. Thanks for your work on > this! Thank you for those words or cheer. I inquired some of my friends to get some testing, and in most of case the answer was ? I'm running RELENG_7 ?. So I've made a patch against RELENG_7. There are only minor changes in src/Makefile.inc1 because -DNO_CTR has been sown all over the file :). So to make it clear for casual glancers: !!! !!! !!! This patch is against RELENG_7. If you can afford a reboot, please test! I need some feedback before it gets committed to -CURRENT. The patch is very stable on my laptop. !!! !!! !!! Thanks you every one. 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: fbsd7-ssp.diff Type: text/x-diff Size: 19530 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080619/56d50eac/fbsd7-ssp.bin From jamie at gritton.org Thu Jun 19 16:18:34 2008 From: jamie at gritton.org (James Gritton) Date: Thu Jun 19 16:18:44 2008 Subject: FreeBSD 6.3 deadlock (vm_map?) with DDB output In-Reply-To: <200806180917.05689.jhb@freebsd.org> References: <20080615112318.146C1F18512@mx.npubs.com> <200806180917.05689.jhb@freebsd.org> Message-ID: <485A81FF.1000000@gritton.org> John Baldwin wrote: > On Sunday 15 June 2008 07:23:19 am Stef Walter wrote: > >> I've been trying to track down a deadlock on some newish production >> servers running FreeBSD 6.3-RELEASE-p2. The deadlock occurs on a >> specific (although mundane) hardware configuration, and each of several >> servers running this hardware deadlock about once per week. >> >> Although I suspect that this is not hardware related, from a (naive) >> perusal of the attached stack traces. >> >> Forgive me if my interpretation of this is all wrong, but I'm pretty >> desperate for help. So here's my basic understanding of the deadlock: >> >> These processes seem to be waiting on the page queue mutex: >> sendmail (in vm_mmap > vm_map_find > vm_map_insert > vm_map_pmap_enter) >> bsnmpd (in malloc, uma_large_malloc > page_alloc > kmem_malloc) >> httpd (in trap > trap_pfault > vm_fault) >> [g_up] (in g_vfs_done > bufdone) >> >> The page queue mutex is held by rsync process: >> rsync (in trap > trap_pfault > vm_fault > pmap_enter) >> >> Rsync kernel process (in pmap_enter) was interrupted while holding the >> page queue lock? >> >> >> Giant is enabled in loader.conf due to the needs of the pf firewall when >> dealing with user credentials lookups. I do not believe that Giant plays >> into this deadlock. Kernel config attached. >> >> Any and all help or info is welcome. Thanks in advance. >> > > Try this change: > > jhb 2007-10-27 22:07:40 UTC > > FreeBSD src repository > > Modified files: > sys/kern sched_4bsd.c > Log: > Change the roundrobin implementation in the 4BSD scheduler to trigger a > userland preemption directly from hardclock() via sched_clock() when a > thread uses up a full quantum instead of using a periodic timeout to cause > a userland preemption every so often. This fixes a potential deadlock > when IPI_PREEMPTION isn't enabled where softclock blocks on a lock held > by a thread pinned or bound to another CPU. The current thread on that > CPU will never be preempted while softclock is blocked. > > Note that ULE already drives its round-robin userland preemption from > sched_clock() as well and always enables IPI_PREEMPT. > > MFC after: 1 week > > Revision Changes Path > 1.108 +8 -29 src/sys/kern/sched_4bsd.c > > We use it at work on 6.x. W/o this fix, round-robin stops working on 4BSD > when softclock() (swi4: clock) blocks on a lock like Giant. > I've been seeing similar troubles on 6.2 and I'll have to give this a try as we upgrade to 6.3. I notice "MFC after: 1 week" in the log; it's been a week - any chance of seeing this fix rolled into 6.x? - Jamie From sigtrm at gmail.com Thu Jun 19 17:41:45 2008 From: sigtrm at gmail.com (Lukasz Jaroszewski) Date: Thu Jun 19 17:41:48 2008 Subject: Accessing char device from inside the kernel Message-ID: Hi, as described in topic. How one should access cdev for writing from kernel-level. What is the proper way to do that ? I will be thankful for any tips and few lines of example code would be just great. Best regards LVJ From zbeeble at gmail.com Thu Jun 19 18:28:31 2008 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Thu Jun 19 18:28:34 2008 Subject: Decent 3D acceleration in 64bit mode? In-Reply-To: <6300771b0806180513l469d6915y378400d728c12475@mail.gmail.com> References: <6300771b0806180513l469d6915y378400d728c12475@mail.gmail.com> Message-ID: <5f67a8c40806191100w7fca5e73icbac58e2beeeae44@mail.gmail.com> On Wed, Jun 18, 2008 at 8:13 AM, Stephen Hocking wrote: > Hi, > > Given that Nvidia aren't offering a driver for their cards for 64bit > FreeBSD, is anyone else having success using another (preferably > PCI-E) card with 3D acceleration? > I'd love to be told I'm wrong, but my understanding is that the issues blocking the nvidia driver would also effectively block a driver for which we had the source. From mwm at mired.org Thu Jun 19 18:57:17 2008 From: mwm at mired.org (Mike Meyer) Date: Thu Jun 19 21:28:25 2008 Subject: Decent 3D acceleration in 64bit mode? In-Reply-To: <5f67a8c40806191100w7fca5e73icbac58e2beeeae44@mail.gmail.com> References: <6300771b0806180513l469d6915y378400d728c12475@mail.gmail.com> <5f67a8c40806191100w7fca5e73icbac58e2beeeae44@mail.gmail.com> Message-ID: <20080619145714.113c3065@mbook.local> On Thu, 19 Jun 2008 14:00:42 -0400 "Zaphod Beeblebrox" wrote: > On Wed, Jun 18, 2008 at 8:13 AM, Stephen Hocking > wrote: > > Given that Nvidia aren't offering a driver for their cards for 64bit > > FreeBSD, is anyone else having success using another (preferably > > PCI-E) card with 3D acceleration? > I'd love to be told I'm wrong, but my understanding is that the issues > blocking the nvidia driver would also effectively block a driver for which > we had the source. Is there an open source driver with good 3D acceleration? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From chuckr at telenix.org Thu Jun 19 21:47:40 2008 From: chuckr at telenix.org (Chuck Robey) Date: Thu Jun 19 21:47:45 2008 Subject: Decent 3D acceleration in 64bit mode? In-Reply-To: <20080619145714.113c3065@mbook.local> References: <6300771b0806180513l469d6915y378400d728c12475@mail.gmail.com> <5f67a8c40806191100w7fca5e73icbac58e2beeeae44@mail.gmail.com> <20080619145714.113c3065@mbook.local> Message-ID: <485AD16C.4000807@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike Meyer wrote: > On Thu, 19 Jun 2008 14:00:42 -0400 "Zaphod Beeblebrox" wrote: > >> On Wed, Jun 18, 2008 at 8:13 AM, Stephen Hocking >> wrote: >>> Given that Nvidia aren't offering a driver for their cards for 64bit >>> FreeBSD, is anyone else having success using another (preferably >>> PCI-E) card with 3D acceleration? >> I'd love to be told I'm wrong, but my understanding is that the issues >> blocking the nvidia driver would also effectively block a driver for which >> we had the source. > > Is there an open source driver with good 3D acceleration? > > References: <6300771b0806180513l469d6915y378400d728c12475@mail.gmail.com> <5f67a8c40806191100w7fca5e73icbac58e2beeeae44@mail.gmail.com> <20080619145714.113c3065@mbook.local> <485AD16C.4000807@telenix.org> Message-ID: <485AD280.4060609@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck Robey wrote: > Mike Meyer wrote: >> On Thu, 19 Jun 2008 14:00:42 -0400 "Zaphod Beeblebrox" wrote: > >>> On Wed, Jun 18, 2008 at 8:13 AM, Stephen Hocking >>> wrote: >>>> Given that Nvidia aren't offering a driver for their cards for 64bit >>>> FreeBSD, is anyone else having success using another (preferably >>>> PCI-E) card with 3D acceleration? >>> I'd love to be told I'm wrong, but my understanding is that the issues >>> blocking the nvidia driver would also effectively block a driver for which >>> we had the source. >> Is there an open source driver with good 3D acceleration? > >> > Could I ask, does anyone here know the reason (even in general) that the Nvidia > driver isn't working on the i386? CRAP I meant AMD64. I'm beyond hope. > > I mean, I was wondering what might be my next project ... I have the machinery, > and the source code is totally available, it's not a matter of Nvidia giving out > a binary-only module, right? So, is anything more known? _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIWtKAz62J6PPcoOkRAqs5AJ9dR9oVygdQwhbTfi9Zn15HmTnvkwCeNWuY oD74ln11Ryu6Ebr4mubBwfA= =h7p6 -----END PGP SIGNATURE----- From john at kozubik.com Thu Jun 19 21:54:16 2008 From: john at kozubik.com (John Kozubik) Date: Thu Jun 19 21:54:20 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... Message-ID: <20080619135114.Y1807@kozubik.com> Don't shoot the messenger: FreeBSD is not useful as a desktop environment without the ability to support Flash in a stable, well-performing fashion. Running IE in Wine is not a solution. Running another OS in vmware to simply browse the web is not a solution. Free flash alternatives and flash movie players, etc., are, unfortunately, not a solution. ports/linux-flashplayer9 _is_ a solution, however it (currently) fails badly. Solution: First, a bounty has been posted here: http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html We aren't even asking for new code, per se - anyone merely posting a recipe that allows linux-flashplayer9 to run, without crashing and with reasonable performance, with a generic browser (opera, firefox, konqueror) can claim the bounty. In fact, a recipe that is entirely inside the Linux Binary Compatibility layer would be just fine - running the linux version of a browser through binary compat is reasonable[1]. Second, I am calling on the FreeBSD Foundation to commit time and money to ensuring that flash functionality is recognized as a high priority for FreeBSD desktop use. I am willing to donate funds for this purpose. Flash 9 will not be the baseline forever, and it is inefficient to ramp up a grass roots bounty effort each time Adobe releases a new product. For this reason I believe it is reasonable for the project itself to ensure that Flash support is delivered and maintained in a timely fashion. [1] Since we're all probably already running Linux Binary Compat anyway... ----- John Kozubik - john@kozubik.com - http://www.kozubik.com From gahr at FreeBSD.org Thu Jun 19 22:01:46 2008 From: gahr at FreeBSD.org (Pietro Cerutti) Date: Thu Jun 19 22:01:50 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <20080619135114.Y1807@kozubik.com> References: <20080619135114.Y1807@kozubik.com> Message-ID: <485AD73C.4080605@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 John Kozubik wrote: | | Don't shoot the messenger: | | | FreeBSD is not useful as a desktop environment without the ability to | support Flash in a stable, well-performing fashion. gnash-devel provides flash 9 and works pretty well... | | | Running IE in Wine is not a solution. | | Running another OS in vmware to simply browse the web is not a solution. | | Free flash alternatives and flash movie players, etc., are, unfortunately, | not a solution. | | ports/linux-flashplayer9 _is_ a solution, however it (currently) fails | badly. | | | Solution: | | | First, a bounty has been posted here: | | http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html | | We aren't even asking for new code, per se - anyone merely posting a | recipe that allows linux-flashplayer9 to run, without crashing and with | reasonable performance, with a generic browser (opera, firefox, konqueror) | can claim the bounty. In fact, a recipe that is entirely inside the Linux | Binary Compatibility layer would be just fine - running the linux version | of a browser through binary compat is reasonable[1]. | | Second, I am calling on the FreeBSD Foundation to commit time and money to | ensuring that flash functionality is recognized as a high priority for | FreeBSD desktop use. I am willing to donate funds for this purpose. | Flash 9 will not be the baseline forever, and it is inefficient to ramp up | a grass roots bounty effort each time Adobe releases a new product. For | this reason I believe it is reasonable for the project itself to ensure | that Flash support is delivered and maintained in a timely fashion. | | | | [1] Since we're all probably already running Linux Binary | Compat anyway... | | | ----- | John Kozubik - john@kozubik.com - http://www.kozubik.com - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkha1zsACgkQwMJqmJVx9470WgCg4APA6m3khgf4iIsrNAXcPbM/ Pr4An10QgMMM/Oalne+GGUzO/wha1HaX =2CKx -----END PGP SIGNATURE----- From fbsd06 at mlists.homeunix.com Thu Jun 19 22:06:33 2008 From: fbsd06 at mlists.homeunix.com (RW) Date: Thu Jun 19 22:06:38 2008 Subject: Decent 3D acceleration in 64bit mode? In-Reply-To: <485AD16C.4000807@telenix.org> References: <6300771b0806180513l469d6915y378400d728c12475@mail.gmail.com> <5f67a8c40806191100w7fca5e73icbac58e2beeeae44@mail.gmail.com> <20080619145714.113c3065@mbook.local> <485AD16C.4000807@telenix.org> Message-ID: <20080619225505.7fb505e4@gumby.homeunix.com.> On Thu, 19 Jun 2008 17:36:44 -0400 Chuck Robey wrote: > Could I ask, does anyone here know the reason (even in general) that > the Nvidia driver isn't working on the i386? I presume you mean on amd64, since it does work on i386. http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html From mwm-keyword-freebsdhackers2.e313df at mired.org Thu Jun 19 22:19:23 2008 From: mwm-keyword-freebsdhackers2.e313df at mired.org (Mike Meyer) Date: Thu Jun 19 22:19:26 2008 Subject: Decent 3D acceleration in 64bit mode? In-Reply-To: <485AD280.4060609@telenix.org> References: <6300771b0806180513l469d6915y378400d728c12475@mail.gmail.com> <5f67a8c40806191100w7fca5e73icbac58e2beeeae44@mail.gmail.com> <20080619145714.113c3065@mbook.local> <485AD16C.4000807@telenix.org> <485AD280.4060609@telenix.org> Message-ID: <20080619181919.6efb3d13@bhuda.mired.org> On Thu, 19 Jun 2008 17:41:20 -0400 Chuck Robey wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Chuck Robey wrote: > > Mike Meyer wrote: > >> On Thu, 19 Jun 2008 14:00:42 -0400 "Zaphod Beeblebrox" wrote: > > > >>> On Wed, Jun 18, 2008 at 8:13 AM, Stephen Hocking > >>> wrote: > >>>> Given that Nvidia aren't offering a driver for their cards for 64bit > >>>> FreeBSD, is anyone else having success using another (preferably > >>>> PCI-E) card with 3D acceleration? > >>> I'd love to be told I'm wrong, but my understanding is that the issues > >>> blocking the nvidia driver would also effectively block a driver for which > >>> we had the source. > >> Is there an open source driver with good 3D acceleration? > > > >> > > > Could I ask, does anyone here know the reason (even in general) that the Nvidia > > driver isn't working on the i386? > > CRAP I meant AMD64. I'm beyond hope. This seems to be the most detailed explanation, though I have no idea about accuracy. http://marc.info/?l=freebsd-hackers&m=115157983106569&w=2 http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From yanefbsd at gmail.com Fri Jun 20 01:14:49 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jun 20 01:14:52 2008 Subject: Decent 3D acceleration in 64bit mode? In-Reply-To: <20080619181919.6efb3d13@bhuda.mired.org> References: <6300771b0806180513l469d6915y378400d728c12475@mail.gmail.com> <5f67a8c40806191100w7fca5e73icbac58e2beeeae44@mail.gmail.com> <20080619145714.113c3065@mbook.local> <485AD16C.4000807@telenix.org> <485AD280.4060609@telenix.org> <20080619181919.6efb3d13@bhuda.mired.org> Message-ID: <7d6fde3d0806191814u639ec539xfb2adef0c0d26037@mail.gmail.com> On Thu, Jun 19, 2008 at 3:19 PM, Mike Meyer wrote: > On Thu, 19 Jun 2008 17:41:20 -0400 > Chuck Robey wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Chuck Robey wrote: >> > Mike Meyer wrote: >> >> On Thu, 19 Jun 2008 14:00:42 -0400 "Zaphod Beeblebrox" wrote: >> > >> >>> On Wed, Jun 18, 2008 at 8:13 AM, Stephen Hocking >> >>> wrote: >> >>>> Given that Nvidia aren't offering a driver for their cards for 64bit >> >>>> FreeBSD, is anyone else having success using another (preferably >> >>>> PCI-E) card with 3D acceleration? >> >>> I'd love to be told I'm wrong, but my understanding is that the issues >> >>> blocking the nvidia driver would also effectively block a driver for which >> >>> we had the source. >> >> Is there an open source driver with good 3D acceleration? >> > >> >> > > >> > Could I ask, does anyone here know the reason (even in general) that the Nvidia >> > driver isn't working on the i386? >> >> CRAP I meant AMD64. I'm beyond hope. > > > This seems to be the most detailed explanation, though I have no idea > about accuracy. > > http://marc.info/?l=freebsd-hackers&m=115157983106569&w=2 > > References: <20080619135114.Y1807@kozubik.com> Message-ID: <20080620045912.GI22907@redundancy.redundancy.org> On Thu, Jun 19, 2008 at 02:37:48PM -0700, John Kozubik wrote: > FreeBSD is not useful as a desktop environment without the ability to > support Flash in a stable, well-performing fashion. Nonsense. This presumes anything "useful" has ever been written in flash. > Free flash alternatives and flash movie players, etc., are, unfortunately, > not a solution. While they certainly don't support everything perfectly, swfdec works fairly well for a large number of sites - notably YouTube and similar FLV wrappers, which is what most people ultimately use Flash for. Even if someone got Flash 9 working, we'll just be playing catch-up when Flash 10 is released and everything starts requiring it. While I honestly wish you the best of luck, I do think that developer effort is much better spent improving free implementations of Flash, as the spec is fairly open. If there are some particular things that don't work well for you with swfdec/gnash, why not offer a bounty to have those fixed? This would be more helpful to more people, like those not running FreeBSD, and those of us who don't use Linux binary compat - of which I suspect there are more than you assume. From ed at 80386.nl Fri Jun 20 06:48:21 2008 From: ed at 80386.nl (Ed Schouten) Date: Fri Jun 20 06:48:23 2008 Subject: Accessing char device from inside the kernel In-Reply-To: References: Message-ID: <20080620064819.GQ93496@hoeg.nl> Hello Lukasz, * Lukasz Jaroszewski wrote: > Hi, as described in topic. How one should access cdev for writing from > kernel-level. What is the proper way to do that ? > I will be thankful for any tips and few lines of example code would be > just great. I think the code in sys/kern/tty_cons.c should be a good example of that. Search for '->d_write'. Yours, -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080620/b0ec91a1/attachment.pgp From murray at FreeBSD.org Fri Jun 20 07:01:14 2008 From: murray at FreeBSD.org (Murray Stokely) Date: Fri Jun 20 07:01:17 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <20080620045912.GI22907@redundancy.redundancy.org> References: <20080619135114.Y1807@kozubik.com> <20080620045912.GI22907@redundancy.redundancy.org> Message-ID: <2a7894eb0806200001wd8da70dh20441d9504259ce4@mail.gmail.com> On Thu, Jun 19, 2008 at 9:59 PM, David E. Thiel wrote: > On Thu, Jun 19, 2008 at 02:37:48PM -0700, John Kozubik wrote: >> FreeBSD is not useful as a desktop environment without the ability to >> support Flash in a stable, well-performing fashion. > > Nonsense. This presumes anything "useful" has ever been written in > flash. Believe it or not, there is useful content on the web in Flash : Google [Flash filetype:swf site:nasa.gov] (without the brackets). - Murray From matt at ixsystems.com Fri Jun 20 07:30:23 2008 From: matt at ixsystems.com (Matt Olander) Date: Fri Jun 20 07:30:29 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <2a7894eb0806200001wd8da70dh20441d9504259ce4@mail.gmail.com> References: <20080619135114.Y1807@kozubik.com> <20080620045912.GI22907@redundancy.redundancy.org> <2a7894eb0806200001wd8da70dh20441d9504259ce4@mail.gmail.com> Message-ID: <7E111F3D-4C41-4584-A0B0-62CDD4F3A0F2@ixsystems.com> On Jun 20, 2008, at 12:01 AM, Murray Stokely wrote: > On Thu, Jun 19, 2008 at 9:59 PM, David E. Thiel > wrote: >> On Thu, Jun 19, 2008 at 02:37:48PM -0700, John Kozubik wrote: >>> FreeBSD is not useful as a desktop environment without the ability >>> to >>> support Flash in a stable, well-performing fashion. >> >> Nonsense. This presumes anything "useful" has ever been written in >> flash. > > Believe it or not, there is useful content on the web in Flash : > > Google [Flash filetype:swf site:nasa.gov] > (without the brackets). Yeah, seriously! Never mind all the video content I am desperate to view on Hulu! ;-) I think my latest Rosetta Stone is Flash9 now too :'( -matt -- Matt Olander CTO, iXsystems - "Servers for Open Source" http://www.iXsystems.com Public Relations, The FreeBSD Project http://www.FreeBSD.org BSD on the Desktop! http://www.pcbsd.org Phone: (408)943-4100 ext. 113 Fax: (408)943-4101 From rdivacky at freebsd.org Fri Jun 20 07:59:04 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Fri Jun 20 07:59:09 2008 Subject: Decent 3D acceleration in 64bit mode? In-Reply-To: <485AD16C.4000807@telenix.org> References: <6300771b0806180513l469d6915y378400d728c12475@mail.gmail.com> <5f67a8c40806191100w7fca5e73icbac58e2beeeae44@mail.gmail.com> <20080619145714.113c3065@mbook.local> <485AD16C.4000807@telenix.org> Message-ID: <20080620075803.GA12112@freebsd.org> On Thu, Jun 19, 2008 at 05:36:44PM -0400, Chuck Robey wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mike Meyer wrote: > > On Thu, 19 Jun 2008 14:00:42 -0400 "Zaphod Beeblebrox" wrote: > > > >> On Wed, Jun 18, 2008 at 8:13 AM, Stephen Hocking > >> wrote: > >>> Given that Nvidia aren't offering a driver for their cards for 64bit > >>> FreeBSD, is anyone else having success using another (preferably > >>> PCI-E) card with 3D acceleration? > >> I'd love to be told I'm wrong, but my understanding is that the issues > >> blocking the nvidia driver would also effectively block a driver for which > >> we had the source. > > > > Is there an open source driver with good 3D acceleration? > > > > > Could I ask, does anyone here know the reason (even in general) that the Nvidia > driver isn't working on the i386? > > I mean, I was wondering what might be my next project ... I have the machinery, > and the source code is totally available, it's not a matter of Nvidia giving out > a binary-only module, right? So, is anything more known? you might want to port nouveau (http://nouveau.freedesktop.org/wiki/) to FreeBSD. that would be a great thing to have From rdivacky at freebsd.org Fri Jun 20 08:05:14 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Fri Jun 20 08:05:19 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <20080620083906.71332251xw1ckmu8@webmail.leidinger.net> References: <20080619135114.Y1807@kozubik.com> <20080620083906.71332251xw1ckmu8@webmail.leidinger.net> Message-ID: <20080620080416.GB12112@freebsd.org> On Fri, Jun 20, 2008 at 08:39:06AM +0200, Alexander Leidinger wrote: > Quoting John Kozubik (from Thu, 19 Jun 2008 > 14:38:11 -0700 (PDT)): > > >First, a bounty has been posted here: > > > >http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html > > > > From the site: > ---snip--- > I will pay $200 to whoever can compose a working and stable recipe for > running Adobe Flash 9 inside of the FreeBSD native version of Opera 9 > on FreeBSD 6.x. This shouldn't be that hard - in fact, there is > already a linux-flashplugin9 port. > ---snip--- > > Comments from other people with some more money not included here... > > And now the sad reality check: linux-flashplugin9 will _never_ work on > 6.x (lack of linux 2.6 emulation, and this is not a MFC candidate). > > Getting it to work on 7.x is possible. "All what you need" is > nspluginwrapper to get it running in the native > firefox/opera/whatever, and someone who is willing to debug the > linuxulator (on -current, as there is a more complete 2.6 > compatibility there, and this can be MFCed to 7.x) and find the > bug/problem which is causing the crashes. Whoever is willing to tackle > this: head over to emulation@ (CCed) and ask what debugging > possibilities we have in the linuxulator. I tried to debug the flash9 and failed badly. It might be that I overlooked something trivial but... the flash9 is a big binary-only monster and basically the only trace of what its doing you can get is a syscall-trace. Which is not that much useful. I didnt find any missing syscalls or something like that and the fail is a complete mystery for me.... otoh I looked at this a LOONG time ago. I might want to look at it again (after some other things settle) anyway... I dont think that flash9 crashes are related to 2.6 emulation in any way. iirc it runs (and crashes) on 2.4 as well. I remember it crashes in $the_thing_that_ff_uses_to_report_bugs which was some proprietary app which got replaced in ff3.0, you might want to check what happened. anyway - if someone wants to debug this, feel free to contact me, I am willing to help roman _ From outbackdingo at gmail.com Fri Jun 20 09:07:47 2008 From: outbackdingo at gmail.com (OutBackDingo) Date: Fri Jun 20 09:07:51 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <2a7894eb0806200001wd8da70dh20441d9504259ce4@mail.gmail.com> References: <20080619135114.Y1807@kozubik.com> <20080620045912.GI22907@redundancy.redundancy.org> <2a7894eb0806200001wd8da70dh20441d9504259ce4@mail.gmail.com> Message-ID: <1213946265.20035.40.camel@dingo-laptop> Believe it or not, there is useful content on the web in Flash : > > Google [Flash filetype:swf site:nasa.gov] > (without the brackets). There might be useful content, but that surely doesnt mean FreeBSD itself as a desktop isnt usable, I think saying using firefox/flash for flash based websites is difficult at best. but FreeBSD as a desktop is plainly very usable From gabor at FreeBSD.org Fri Jun 20 11:14:47 2008 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Fri Jun 20 11:14:58 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <20080618052347.GA1877@a91-153-120-204.elisa-laajakaista.fi> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org> <485807CD.1030601@FreeBSD.org> <20080618052347.GA1877@a91-153-120-204.elisa-laajakaista.fi> Message-ID: <485B9125.1000307@FreeBSD.org> Jaakko Heinonen escribi?: > On 2008-06-17, Gabor Kovesdan wrote: > >>> egrep: empty (sub)expression >>> >>> >> I've looked at this and I have a patch with a workaround: >> http://kovesdan.org/patches/grep.dougb.diff >> > > Unfortunately this breaks things. For example: > > $ grep -E '(test||test)' /dev/null > grep: parentheses not balanced > $ grep -E '(test|\|)' /dev/null > grep: parentheses not balanced > $ grep -E '\(|test)' /dev/null > (should give an error but it hangs) > Ugly enough, but seems to be fixed in my working copy. Thanks for the report. Gabor From Alexander at Leidinger.net Fri Jun 20 06:39:15 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Fri Jun 20 11:26:11 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <20080619135114.Y1807@kozubik.com> References: <20080619135114.Y1807@kozubik.com> Message-ID: <20080620083906.71332251xw1ckmu8@webmail.leidinger.net> Quoting John Kozubik (from Thu, 19 Jun 2008 14:38:11 -0700 (PDT)): > First, a bounty has been posted here: > > http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html > From the site: ---snip--- I will pay $200 to whoever can compose a working and stable recipe for running Adobe Flash 9 inside of the FreeBSD native version of Opera 9 on FreeBSD 6.x. This shouldn't be that hard - in fact, there is already a linux-flashplugin9 port. ---snip--- Comments from other people with some more money not included here... And now the sad reality check: linux-flashplugin9 will _never_ work on 6.x (lack of linux 2.6 emulation, and this is not a MFC candidate). Getting it to work on 7.x is possible. "All what you need" is nspluginwrapper to get it running in the native firefox/opera/whatever, and someone who is willing to debug the linuxulator (on -current, as there is a more complete 2.6 compatibility there, and this can be MFCed to 7.x) and find the bug/problem which is causing the crashes. Whoever is willing to tackle this: head over to emulation@ (CCed) and ask what debugging possibilities we have in the linuxulator. Note: AFAIK linux-flashplugin9 is not completely stable on linux either... Bye, Alexander. -- Leela: Well, goodnight. I'm gonna go make my dinners for the next month and freeze them. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From Alexander at Leidinger.net Fri Jun 20 08:41:17 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Fri Jun 20 11:26:25 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <20080620080416.GB12112@freebsd.org> References: <20080619135114.Y1807@kozubik.com> <20080620083906.71332251xw1ckmu8@webmail.leidinger.net> <20080620080416.GB12112@freebsd.org> Message-ID: <20080620104106.18826n68s55lwlc0@webmail.leidinger.net> Quoting Roman Divacky (from Fri, 20 Jun 2008 10:04:16 +0200): > On Fri, Jun 20, 2008 at 08:39:06AM +0200, Alexander Leidinger wrote: >> Quoting John Kozubik (from Thu, 19 Jun 2008 >> 14:38:11 -0700 (PDT)): >> >> >First, a bounty has been posted here: >> > >> >http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html >> > >> >> From the site: >> ---snip--- >> I will pay $200 to whoever can compose a working and stable recipe for >> running Adobe Flash 9 inside of the FreeBSD native version of Opera 9 >> on FreeBSD 6.x. This shouldn't be that hard - in fact, there is >> already a linux-flashplugin9 port. >> ---snip--- >> >> Comments from other people with some more money not included here... >> >> And now the sad reality check: linux-flashplugin9 will _never_ work on >> 6.x (lack of linux 2.6 emulation, and this is not a MFC candidate). >> >> Getting it to work on 7.x is possible. "All what you need" is >> nspluginwrapper to get it running in the native >> firefox/opera/whatever, and someone who is willing to debug the >> linuxulator (on -current, as there is a more complete 2.6 >> compatibility there, and this can be MFCed to 7.x) and find the >> bug/problem which is causing the crashes. Whoever is willing to tackle >> this: head over to emulation@ (CCed) and ask what debugging >> possibilities we have in the linuxulator. > > I tried to debug the flash9 and failed badly. It might be that I overlooked > something trivial but... > > the flash9 is a big binary-only monster and basically the only trace > of what its doing you can get is a syscall-trace. Which is not that much I think enabling the the linuxulator debug stuff and maybe adding some more printfs at some places can reveal some more stuff... with some in-deep reviewing of what happens. > useful. I didnt find any missing syscalls or something like that and the > fail is a complete mystery for me.... otoh I looked at this a LOONG time ago. Which is in indication that there are some (subtle) differences between the linuxulator and the real linux we have to track down. > I might want to look at it again (after some other things settle) > > > anyway... I dont think that flash9 crashes are related to 2.6 > emulation in any > way. iirc it runs (and crashes) on 2.4 as well. I remember it crashes in Hmmm... now I'm not sure anymore, but I thought we had reports that it runs better with 2.6... Bye, Alexander. -- I wish I was a sex-starved manicurist found dead in the Bronx!! http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From freebsd-hackers at transip.nl Fri Jun 20 11:46:16 2008 From: freebsd-hackers at transip.nl (Ali Niknam) Date: Fri Jun 20 11:46:25 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... Message-ID: <485B94E7.3060105@transip.nl> Dear All, Recently i've been upgrading some of my machines from FreeBSD 6.x amd64 to FreeBSD 7.0 amd64. After upgrading I noticed a weird error/bug. It seems that after several thousand TCP connections some seem to hang in 'CLOSED' state. netstat -n gives: ... tcp4 0 0 1.2.3.4.* 4.5.6.7.42149 CLOSED tcp4 39 0 1.2.3.4.* 4.5.6.7.54103 CLOSED tcp4 35 0 1.2.3.4.* 4.5.6.7.41718 CLOSED tcp4 38 0 1.2.3.4.* 4.5.6.7.55618 CLOSED tcp4 41 0 1.2.3.4.* 4.5.6.7.44230 CLOSED tcp4 39 0 1.2.3.4.* 4.5.6.7.49439 CLOSED ... These never go away; they gradually increase and increase until the application starts giving errors (probably because some socket or filedescriptor limit is reached). When the application is killed these entries disappear. The application in question is a self written DNS server, multithreaded, and running fine for years without any troubles on both BSD 5.x as well as 6.x. Also 32bits as well as 64bits on 6.x. Ofcourse that doesn't mean that the application is error free, however, after doing extensive testing I really can not find anything wrong with the application itself, so I'm thinking maybe there's a change somewhere that causes this? I know that tcp/network has been completely redone... What basically happens in the application is this: - one main tcp thread runs an infinite while loop waiting for new connections to arrive - as soon as one arrives a new thread is spawned that handles the newly created stream - it reads some bytes, writes some bytes, then closes it - thread exits What appears to happen is this: after the new thread is spawned it tries to read 2 bytes (DNS tcp length information). It gets back 0 bytes (EOF) and therefore closes the sockets and calls pthread_exit. However in netstat that same stream oftenly appears to have bytes 'stuck' in the in queue... I really can't see how this can cause hanging sockets in 'CLOSED' state. Even if the incoming queue isnt read entirely a call to close should close it. Also I really can't find any documentation in netstat, or elsewhere, about the 'CLOSED' state... Any help would greatly be appreciated! Kind Regards, Ali Niknam From shildret at scotth.emsphone.com Fri Jun 20 14:49:15 2008 From: shildret at scotth.emsphone.com (Scott T. Hildreth) Date: Fri Jun 20 15:41:35 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <20080620083906.71332251xw1ckmu8@webmail.leidinger.net> References: <20080619135114.Y1807@kozubik.com> <20080620083906.71332251xw1ckmu8@webmail.leidinger.net> Message-ID: <1213972236.1505.14.camel@scotth.emsphone.com> On Fri, 2008-06-20 at 08:39 +0200, Alexander Leidinger wrote: > Quoting John Kozubik (from Thu, 19 Jun 2008 > 14:38:11 -0700 (PDT)): > > > First, a bounty has been posted here: > > > > http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html > > > Maybe the bounty would be better spent here, This was from an email on the gnome list from Joe Marcus Clarke "As to the point about Flash, Kris also mentioned that he has the ear of someone at Adobe who was hinting that a capable developer willing to sign an NDA could be given code to work on a native Flash plug-in port. This could bode well for PC-BSD and FreeBSD should someone step up to do this work." > From the site: > ---snip--- > I will pay $200 to whoever can compose a working and stable recipe for > running Adobe Flash 9 inside of the FreeBSD native version of Opera 9 > on FreeBSD 6.x. This shouldn't be that hard - in fact, there is > already a linux-flashplugin9 port. > ---snip--- > > Comments from other people with some more money not included here... > > And now the sad reality check: linux-flashplugin9 will _never_ work on > 6.x (lack of linux 2.6 emulation, and this is not a MFC candidate). > > Getting it to work on 7.x is possible. "All what you need" is > nspluginwrapper to get it running in the native > firefox/opera/whatever, and someone who is willing to debug the > linuxulator (on -current, as there is a more complete 2.6 > compatibility there, and this can be MFCed to 7.x) and find the > bug/problem which is causing the crashes. Whoever is willing to tackle > this: head over to emulation@ (CCed) and ask what debugging > possibilities we have in the linuxulator. > > Note: AFAIK linux-flashplugin9 is not completely stable on linux either... > > Bye, > Alexander. > From pisymbol at gmail.com Fri Jun 20 20:52:34 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Fri Jun 20 20:52:38 2008 Subject: Cross platform building best practices (building 6 on 7) In-Reply-To: <7d6fde3d0806190822s1420dcake3a38be7189b8ab0@mail.gmail.com> References: <3c0b01820806190629o7264cfaeg6fa6a08a6822047e@mail.gmail.com> <7d6fde3d0806190822s1420dcake3a38be7189b8ab0@mail.gmail.com> Message-ID: <3c0b01820806201352n54b846cas612a6923531ef04@mail.gmail.com> On Thu, Jun 19, 2008 at 11:22 AM, Garrett Cooper wrote: > On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack wrote: >> Hello Folks: >> >> I've done a lot of Googling and scouring the lists about this >> particular subject so I apologize for rehashing it. However, I'm >> still confused on what's the best way to perform BSD cross platform >> builds. Ideally what I want to have is an environment whereby I can >> build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I >> could check out a 6.1 release version, perform make world, and then >> use the output of that build as either a basis for a jail or a >> toolchain. However, as noted by previous threads, 6.x doesn't build >> on a 7.x due to gcc4/binutils compatibility issues (please correct me >> if I'm wrong). I then thought I could potentially download a patched >> binutils, copy it into src/contrib/binutils and that would potentially >> fix it. No dice (and I'm still debugging why since this binutils >> package DOES build outside of the make world infrastructure without >> issue, this very well could be pilot error on my part since I didn't >> update the VERSION string and didn't trim the source files as per the >> FreeBSD-deleteList etc.). >> >> I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could >> complie a 6.x on a 7.x machine. Well I haven't done that yet since at >> this point I believe I'm diverged from the path of FreeBSD build >> enlightenment! Moreover, if would be NICE if I could bootstrap the >> normal dev tools from the exiting make world build tree. I'm not yet >> ready for a lot of hackery on the build tree without asking around. >> :D! >> >> Does anyone due cross-platform builds (without host virtualization)? >> >> Thanks! >> >> -aps > > (I'll stick to just hackers@ because I don't want to pollute > questions@ unnecessarily) Sorry I felt really bad actually cc'ing questions its just that my last groking produced many threads in freebsd-questions as opposed to hackers. I'll try to be more attentive to my posts (I have a habit cc'ing multiple forums because sometimes they apply but questions is for normal troubleshooting, not cross-platform build issues!). > You touched on an important point. There were some code quality issues > (I think) with 6.x that were resolved moving to 7.x, which caused > gcc-4.2.x to barf. Probably but I'm not trying to point fingers! :D! > gcc-4.2.x requires a newer version of binutils, just because (for API > / usage compatibility). Yea understood. To be honest, this isn't documented very readily. I first thought it was pilot error on me, then I decided to take a look at what failed to compile (I believe it was an innocent extern). And then got lost in gcc/binutils hell. Luckily I've smelled this problem before and after some research confirmed by suspicion. > What you should probably do is create a jail then do your development > for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...) > do 8.x development in yet a third. Jail's are a much better way to > isolate things such that you don't have to worry about toolchain > issues like these and are able to setup a sourcebase as the devs > intended it (for the most part; you may run into issues with sysctls > and virtual kernel stuff like that, but cest la vie... there isn't a > better way I know of than that outside of running a VM). I figured you were going ot say that Garrett. Well OK, but I still need to bootstrap my dev environment for 6.x development on 7.x. Since binutils compatibility makes my 6.x make world barf on 7.x, where should I go? I HAVE not parsed through a lot of the build infrastructure yet but it would seem to be IF make world bootstraps the world including the development tools, why can't I update binutils/gcc inplace and then compile (or is this a regression issue which I failed to grasp). Or do I need to update binutils on my *host* system itself? i.e. what I'm really asking is does make world bootstrap the right bintuils/gcc etc. and then use THAT to compile the rest or does it just perform a host build of everything and plops it in DESTDIR? Hope I make some sense here (still a n00b).... -aps From julian at elischer.org Fri Jun 20 21:14:38 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Jun 20 21:14:43 2008 Subject: Cross platform building best practices (building 6 on 7) In-Reply-To: <3c0b01820806201352n54b846cas612a6923531ef04@mail.gmail.com> References: <3c0b01820806190629o7264cfaeg6fa6a08a6822047e@mail.gmail.com> <7d6fde3d0806190822s1420dcake3a38be7189b8ab0@mail.gmail.com> <3c0b01820806201352n54b846cas612a6923531ef04@mail.gmail.com> Message-ID: <485C1DC5.8090007@elischer.org> Alexander Sack wrote: > On Thu, Jun 19, 2008 at 11:22 AM, Garrett Cooper wrote: >> On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack wrote: >>> Hello Folks: >>> >>> I've done a lot of Googling and scouring the lists about this >>> particular subject so I apologize for rehashing it. However, I'm >>> still confused on what's the best way to perform BSD cross platform >>> builds. Ideally what I want to have is an environment whereby I can >>> build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I >>> could check out a 6.1 release version, perform make world, and then >>> use the output of that build as either a basis for a jail or a >>> toolchain. However, as noted by previous threads, 6.x doesn't build >>> on a 7.x due to gcc4/binutils compatibility issues (please correct me >>> if I'm wrong). I then thought I could potentially download a patched >>> binutils, copy it into src/contrib/binutils and that would potentially >>> fix it. No dice (and I'm still debugging why since this binutils >>> package DOES build outside of the make world infrastructure without >>> issue, this very well could be pilot error on my part since I didn't >>> update the VERSION string and didn't trim the source files as per the >>> FreeBSD-deleteList etc.). >>> >>> I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could >>> complie a 6.x on a 7.x machine. Well I haven't done that yet since at >>> this point I believe I'm diverged from the path of FreeBSD build >>> enlightenment! Moreover, if would be NICE if I could bootstrap the >>> normal dev tools from the exiting make world build tree. I'm not yet >>> ready for a lot of hackery on the build tree without asking around. >>> :D! >>> >>> Does anyone due cross-platform builds (without host virtualization)? >>> >>> Thanks! >>> >>> -aps >> (I'll stick to just hackers@ because I don't want to pollute >> questions@ unnecessarily) > > Sorry I felt really bad actually cc'ing questions its just that my > last groking produced many threads in freebsd-questions as opposed to > hackers. I'll try to be more attentive to my posts (I have a habit > cc'ing multiple forums because sometimes they apply but questions is > for normal troubleshooting, not cross-platform build issues!). > >> You touched on an important point. There were some code quality issues >> (I think) with 6.x that were resolved moving to 7.x, which caused >> gcc-4.2.x to barf. > > Probably but I'm not trying to point fingers! :D! > >> gcc-4.2.x requires a newer version of binutils, just because (for API >> / usage compatibility). > > Yea understood. To be honest, this isn't documented very readily. I > first thought it was pilot error on me, then I decided to take a look > at what failed to compile (I believe it was an innocent extern). And > then got lost in gcc/binutils hell. Luckily I've smelled this problem > before and after some research confirmed by suspicion. > >> What you should probably do is create a jail then do your development >> for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...) >> do 8.x development in yet a third. Jail's are a much better way to >> isolate things such that you don't have to worry about toolchain >> issues like these and are able to setup a sourcebase as the devs >> intended it (for the most part; you may run into issues with sysctls >> and virtual kernel stuff like that, but cest la vie... there isn't a >> better way I know of than that outside of running a VM). > > I figured you were going ot say that Garrett. Well OK, but I still > need to bootstrap my dev environment for 6.x development on 7.x. > Since binutils compatibility makes my 6.x make world barf on 7.x, > where should I go? I HAVE not parsed through a lot of the build > infrastructure yet but it would seem to be IF make world bootstraps > the world including the development tools, why can't I update > binutils/gcc inplace and then compile (or is this a regression issue > which I failed to grasp). Or do I need to update binutils on my > *host* system itself? i.e. what I'm really asking is does make world > bootstrap the right bintuils/gcc etc. and then use THAT to compile the > rest or does it just perform a host build of everything and plops it > in DESTDIR? > > Hope I make some sense here (still a n00b).... One thing we always strive for in FreeBSD is an upgrade path. As a general rule, a newer system should be able to run a jail populated with an earlier system. There are some small exceptions, for example you may need a new version of netstat, ps and libkvm in your jail. possibly grab them from the /rescue on the new system so they are statically linked. also 8.x systems will require that threaded programs from 6.x be dynamically linked so that they can be remapped to use libthr instead of libkse as libkse is not supported in 8. asside from those I think that just about every thing else should be fine.. I've run a FreeBSD 1.1 chroot on a freeBSD 7 system (I had to make 1 very small fix). At Ironport we build 4.x binaries on 6.x systems by spinning off a 4.x chroot as prart of the build process. (they need to link with 4.x third party binaries) so it's very esay to do. > > -aps > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From pisymbol at gmail.com Fri Jun 20 21:24:14 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Fri Jun 20 21:24:18 2008 Subject: Cross platform building best practices (building 6 on 7) In-Reply-To: <485C1DC5.8090007@elischer.org> References: <3c0b01820806190629o7264cfaeg6fa6a08a6822047e@mail.gmail.com> <7d6fde3d0806190822s1420dcake3a38be7189b8ab0@mail.gmail.com> <3c0b01820806201352n54b846cas612a6923531ef04@mail.gmail.com> <485C1DC5.8090007@elischer.org> Message-ID: <3c0b01820806201424n53371437m8e9af5507416926e@mail.gmail.com> On Fri, Jun 20, 2008 at 5:14 PM, Julian Elischer wrote: > Alexander Sack wrote: >> >> On Thu, Jun 19, 2008 at 11:22 AM, Garrett Cooper >> wrote: >>> >>> On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack >>> wrote: >>>> >>>> Hello Folks: >>>> >>>> I've done a lot of Googling and scouring the lists about this >>>> particular subject so I apologize for rehashing it. However, I'm >>>> still confused on what's the best way to perform BSD cross platform >>>> builds. Ideally what I want to have is an environment whereby I can >>>> build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I >>>> could check out a 6.1 release version, perform make world, and then >>>> use the output of that build as either a basis for a jail or a >>>> toolchain. However, as noted by previous threads, 6.x doesn't build >>>> on a 7.x due to gcc4/binutils compatibility issues (please correct me >>>> if I'm wrong). I then thought I could potentially download a patched >>>> binutils, copy it into src/contrib/binutils and that would potentially >>>> fix it. No dice (and I'm still debugging why since this binutils >>>> package DOES build outside of the make world infrastructure without >>>> issue, this very well could be pilot error on my part since I didn't >>>> update the VERSION string and didn't trim the source files as per the >>>> FreeBSD-deleteList etc.). >>>> >>>> I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could >>>> complie a 6.x on a 7.x machine. Well I haven't done that yet since at >>>> this point I believe I'm diverged from the path of FreeBSD build >>>> enlightenment! Moreover, if would be NICE if I could bootstrap the >>>> normal dev tools from the exiting make world build tree. I'm not yet >>>> ready for a lot of hackery on the build tree without asking around. >>>> :D! >>>> >>>> Does anyone due cross-platform builds (without host virtualization)? >>>> >>>> Thanks! >>>> >>>> -aps >>> >>> (I'll stick to just hackers@ because I don't want to pollute >>> questions@ unnecessarily) >> >> Sorry I felt really bad actually cc'ing questions its just that my >> last groking produced many threads in freebsd-questions as opposed to >> hackers. I'll try to be more attentive to my posts (I have a habit >> cc'ing multiple forums because sometimes they apply but questions is >> for normal troubleshooting, not cross-platform build issues!). >> >>> You touched on an important point. There were some code quality issues >>> (I think) with 6.x that were resolved moving to 7.x, which caused >>> gcc-4.2.x to barf. >> >> Probably but I'm not trying to point fingers! :D! >> >>> gcc-4.2.x requires a newer version of binutils, just because (for API >>> / usage compatibility). >> >> Yea understood. To be honest, this isn't documented very readily. I >> first thought it was pilot error on me, then I decided to take a look >> at what failed to compile (I believe it was an innocent extern). And >> then got lost in gcc/binutils hell. Luckily I've smelled this problem >> before and after some research confirmed by suspicion. >> >>> What you should probably do is create a jail then do your development >>> for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...) >>> do 8.x development in yet a third. Jail's are a much better way to >>> isolate things such that you don't have to worry about toolchain >>> issues like these and are able to setup a sourcebase as the devs >>> intended it (for the most part; you may run into issues with sysctls >>> and virtual kernel stuff like that, but cest la vie... there isn't a >>> better way I know of than that outside of running a VM). >> >> I figured you were going ot say that Garrett. Well OK, but I still >> need to bootstrap my dev environment for 6.x development on 7.x. >> Since binutils compatibility makes my 6.x make world barf on 7.x, >> where should I go? I HAVE not parsed through a lot of the build >> infrastructure yet but it would seem to be IF make world bootstraps >> the world including the development tools, why can't I update >> binutils/gcc inplace and then compile (or is this a regression issue >> which I failed to grasp). Or do I need to update binutils on my >> *host* system itself? i.e. what I'm really asking is does make world >> bootstrap the right bintuils/gcc etc. and then use THAT to compile the >> rest or does it just perform a host build of everything and plops it >> in DESTDIR? >> >> Hope I make some sense here (still a n00b).... > > One thing we always strive for in FreeBSD is an upgrade path. > > As a general rule, a newer system should be able to run a jail > populated with an earlier system. There are some small exceptions, > for example you may need a new version of netstat, ps and libkvm > in your jail. possibly grab them from the /rescue on the new system > so they are statically linked. > also 8.x systems will require that threaded programs from 6.x be dynamically > linked so that they can be remapped to use libthr instead of libkse as > libkse is not supported in 8. So you are talking about binary/ABI compatibility yes? So I would assume what you are saying is I can take a 6.x system, create a filesystem tarball, drop it on a 7.x system and then create a jail out of it. > asside from those I think that just about every thing else should be fine.. > I've run a FreeBSD 1.1 chroot on a freeBSD 7 system > (I had to make 1 very small fix). > > At Ironport we build 4.x binaries on 6.x systems by spinning off > a 4.x chroot as prart of the build process. (they need to link with 4.x > third party binaries) so it's very esay to do. I believe this answers my question but I want to confirm. I THOUGHT about this but I wanted a more *cleanroom* approach. That's all. -aps From julian at elischer.org Fri Jun 20 21:58:57 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Jun 20 21:59:04 2008 Subject: Cross platform building best practices (building 6 on 7) In-Reply-To: <3c0b01820806201424n53371437m8e9af5507416926e@mail.gmail.com> References: <3c0b01820806190629o7264cfaeg6fa6a08a6822047e@mail.gmail.com> <7d6fde3d0806190822s1420dcake3a38be7189b8ab0@mail.gmail.com> <3c0b01820806201352n54b846cas612a6923531ef04@mail.gmail.com> <485C1DC5.8090007@elischer.org> <3c0b01820806201424n53371437m8e9af5507416926e@mail.gmail.com> Message-ID: <485C2828.4050500@elischer.org> Alexander Sack wrote: > On Fri, Jun 20, 2008 at 5:14 PM, Julian Elischer wrote: >> Alexander Sack wrote: >>> On Thu, Jun 19, 2008 at 11:22 AM, Garrett Cooper >>> wrote: >>>> On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack >>>> wrote: >>>>> Hello Folks: >>>>> >>>>> I've done a lot of Googling and scouring the lists about this >>>>> particular subject so I apologize for rehashing it. However, I'm >>>>> still confused on what's the best way to perform BSD cross platform >>>>> builds. Ideally what I want to have is an environment whereby I can >>>>> build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I >>>>> could check out a 6.1 release version, perform make world, and then >>>>> use the output of that build as either a basis for a jail or a >>>>> toolchain. However, as noted by previous threads, 6.x doesn't build >>>>> on a 7.x due to gcc4/binutils compatibility issues (please correct me >>>>> if I'm wrong). I then thought I could potentially download a patched >>>>> binutils, copy it into src/contrib/binutils and that would potentially >>>>> fix it. No dice (and I'm still debugging why since this binutils >>>>> package DOES build outside of the make world infrastructure without >>>>> issue, this very well could be pilot error on my part since I didn't >>>>> update the VERSION string and didn't trim the source files as per the >>>>> FreeBSD-deleteList etc.). >>>>> >>>>> I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could >>>>> complie a 6.x on a 7.x machine. Well I haven't done that yet since at >>>>> this point I believe I'm diverged from the path of FreeBSD build >>>>> enlightenment! Moreover, if would be NICE if I could bootstrap the >>>>> normal dev tools from the exiting make world build tree. I'm not yet >>>>> ready for a lot of hackery on the build tree without asking around. >>>>> :D! >>>>> >>>>> Does anyone due cross-platform builds (without host virtualization)? >>>>> >>>>> Thanks! >>>>> >>>>> -aps >>>> (I'll stick to just hackers@ because I don't want to pollute >>>> questions@ unnecessarily) >>> Sorry I felt really bad actually cc'ing questions its just that my >>> last groking produced many threads in freebsd-questions as opposed to >>> hackers. I'll try to be more attentive to my posts (I have a habit >>> cc'ing multiple forums because sometimes they apply but questions is >>> for normal troubleshooting, not cross-platform build issues!). >>> >>>> You touched on an important point. There were some code quality issues >>>> (I think) with 6.x that were resolved moving to 7.x, which caused >>>> gcc-4.2.x to barf. >>> Probably but I'm not trying to point fingers! :D! >>> >>>> gcc-4.2.x requires a newer version of binutils, just because (for API >>>> / usage compatibility). >>> Yea understood. To be honest, this isn't documented very readily. I >>> first thought it was pilot error on me, then I decided to take a look >>> at what failed to compile (I believe it was an innocent extern). And >>> then got lost in gcc/binutils hell. Luckily I've smelled this problem >>> before and after some research confirmed by suspicion. >>> >>>> What you should probably do is create a jail then do your development >>>> for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...) >>>> do 8.x development in yet a third. Jail's are a much better way to >>>> isolate things such that you don't have to worry about toolchain >>>> issues like these and are able to setup a sourcebase as the devs >>>> intended it (for the most part; you may run into issues with sysctls >>>> and virtual kernel stuff like that, but cest la vie... there isn't a >>>> better way I know of than that outside of running a VM). >>> I figured you were going ot say that Garrett. Well OK, but I still >>> need to bootstrap my dev environment for 6.x development on 7.x. >>> Since binutils compatibility makes my 6.x make world barf on 7.x, >>> where should I go? I HAVE not parsed through a lot of the build >>> infrastructure yet but it would seem to be IF make world bootstraps >>> the world including the development tools, why can't I update >>> binutils/gcc inplace and then compile (or is this a regression issue >>> which I failed to grasp). Or do I need to update binutils on my >>> *host* system itself? i.e. what I'm really asking is does make world >>> bootstrap the right bintuils/gcc etc. and then use THAT to compile the >>> rest or does it just perform a host build of everything and plops it >>> in DESTDIR? >>> >>> Hope I make some sense here (still a n00b).... >> One thing we always strive for in FreeBSD is an upgrade path. >> >> As a general rule, a newer system should be able to run a jail >> populated with an earlier system. There are some small exceptions, >> for example you may need a new version of netstat, ps and libkvm >> in your jail. possibly grab them from the /rescue on the new system >> so they are statically linked. >> also 8.x systems will require that threaded programs from 6.x be dynamically >> linked so that they can be remapped to use libthr instead of libkse as >> libkse is not supported in 8. > > So you are talking about binary/ABI compatibility yes? So I would > assume what you are saying is I can take a 6.x system, create a > filesystem tarball, drop it on a 7.x system and then create a jail out > of it. exactly > >> asside from those I think that just about every thing else should be fine.. >> I've run a FreeBSD 1.1 chroot on a freeBSD 7 system >> (I had to make 1 very small fix). >> >> At Ironport we build 4.x binaries on 6.x systems by spinning off >> a 4.x chroot as prart of the build process. (they need to link with 4.x >> third party binaries) so it's very esay to do. > > I believe this answers my question but I want to confirm. I THOUGHT > about this but I wanted a more *cleanroom* approach. That's all. > > -aps From julian at elischer.org Fri Jun 20 22:02:06 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Jun 20 22:02:11 2008 Subject: Cross platform building best practices (building 6 on 7) In-Reply-To: <3c0b01820806201424n53371437m8e9af5507416926e@mail.gmail.com> References: <3c0b01820806190629o7264cfaeg6fa6a08a6822047e@mail.gmail.com> <7d6fde3d0806190822s1420dcake3a38be7189b8ab0@mail.gmail.com> <3c0b01820806201352n54b846cas612a6923531ef04@mail.gmail.com> <485C1DC5.8090007@elischer.org> <3c0b01820806201424n53371437m8e9af5507416926e@mail.gmail.com> Message-ID: <485C28E5.3070909@elischer.org> Alexander Sack wrote: > On Fri, Jun 20, 2008 at 5:14 PM, Julian Elischer wrote: >> Alexander Sack wrote: >>> On Thu, Jun 19, 2008 at 11:22 AM, Garrett Cooper >>> wrote: >>>> On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack >>>> wrote: >>>>> Hello Folks: >>>>> >>>>> I've done a lot of Googling and scouring the lists about this >>>>> particular subject so I apologize for rehashing it. However, I'm >>>>> still confused on what's the best way to perform BSD cross platform >>>>> builds. Ideally what I want to have is an environment whereby I can >>>>> build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I >>>>> could check out a 6.1 release version, perform make world, and then >>>>> use the output of that build as either a basis for a jail or a >>>>> toolchain. However, as noted by previous threads, 6.x doesn't build >>>>> on a 7.x due to gcc4/binutils compatibility issues (please correct me >>>>> if I'm wrong). I then thought I could potentially download a patched >>>>> binutils, copy it into src/contrib/binutils and that would potentially >>>>> fix it. No dice (and I'm still debugging why since this binutils >>>>> package DOES build outside of the make world infrastructure without >>>>> issue, this very well could be pilot error on my part since I didn't >>>>> update the VERSION string and didn't trim the source files as per the >>>>> FreeBSD-deleteList etc.). >>>>> >>>>> I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could >>>>> complie a 6.x on a 7.x machine. Well I haven't done that yet since at >>>>> this point I believe I'm diverged from the path of FreeBSD build >>>>> enlightenment! Moreover, if would be NICE if I could bootstrap the >>>>> normal dev tools from the exiting make world build tree. I'm not yet >>>>> ready for a lot of hackery on the build tree without asking around. >>>>> :D! >>>>> >>>>> Does anyone due cross-platform builds (without host virtualization)? >>>>> >>>>> Thanks! >>>>> >>>>> -aps >>>> (I'll stick to just hackers@ because I don't want to pollute >>>> questions@ unnecessarily) >>> Sorry I felt really bad actually cc'ing questions its just that my >>> last groking produced many threads in freebsd-questions as opposed to >>> hackers. I'll try to be more attentive to my posts (I have a habit >>> cc'ing multiple forums because sometimes they apply but questions is >>> for normal troubleshooting, not cross-platform build issues!). >>> >>>> You touched on an important point. There were some code quality issues >>>> (I think) with 6.x that were resolved moving to 7.x, which caused >>>> gcc-4.2.x to barf. >>> Probably but I'm not trying to point fingers! :D! >>> >>>> gcc-4.2.x requires a newer version of binutils, just because (for API >>>> / usage compatibility). >>> Yea understood. To be honest, this isn't documented very readily. I >>> first thought it was pilot error on me, then I decided to take a look >>> at what failed to compile (I believe it was an innocent extern). And >>> then got lost in gcc/binutils hell. Luckily I've smelled this problem >>> before and after some research confirmed by suspicion. >>> >>>> What you should probably do is create a jail then do your development >>>> for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...) >>>> do 8.x development in yet a third. Jail's are a much better way to >>>> isolate things such that you don't have to worry about toolchain >>>> issues like these and are able to setup a sourcebase as the devs >>>> intended it (for the most part; you may run into issues with sysctls >>>> and virtual kernel stuff like that, but cest la vie... there isn't a >>>> better way I know of than that outside of running a VM). >>> I figured you were going ot say that Garrett. Well OK, but I still >>> need to bootstrap my dev environment for 6.x development on 7.x. >>> Since binutils compatibility makes my 6.x make world barf on 7.x, >>> where should I go? I HAVE not parsed through a lot of the build >>> infrastructure yet but it would seem to be IF make world bootstraps >>> the world including the development tools, why can't I update >>> binutils/gcc inplace and then compile (or is this a regression issue >>> which I failed to grasp). Or do I need to update binutils on my >>> *host* system itself? i.e. what I'm really asking is does make world >>> bootstrap the right bintuils/gcc etc. and then use THAT to compile the >>> rest or does it just perform a host build of everything and plops it >>> in DESTDIR? >>> >>> Hope I make some sense here (still a n00b).... >> One thing we always strive for in FreeBSD is an upgrade path. >> >> As a general rule, a newer system should be able to run a jail >> populated with an earlier system. There are some small exceptions, >> for example you may need a new version of netstat, ps and libkvm >> in your jail. possibly grab them from the /rescue on the new system >> so they are statically linked. >> also 8.x systems will require that threaded programs from 6.x be dynamically >> linked so that they can be remapped to use libthr instead of libkse as >> libkse is not supported in 8. > > So you are talking about binary/ABI compatibility yes? So I would > assume what you are saying is I can take a 6.x system, create a > filesystem tarball, drop it on a 7.x system and then create a jail out > of it. > >> asside from those I think that just about every thing else should be fine.. >> I've run a FreeBSD 1.1 chroot on a freeBSD 7 system >> (I had to make 1 very small fix). >> >> At Ironport we build 4.x binaries on 6.x systems by spinning off >> a 4.x chroot as prart of the build process. (they need to link with 4.x >> third party binaries) so it's very esay to do. > > I believe this answers my question but I want to confirm. I THOUGHT > about this but I wanted a more *cleanroom* approach. That's all. this is about as cleanroom as you can get.. you create a tarball of a virgin 6.x distribution including virgin stuff you need, and then every time you need to do a new 6.x jail, you just drop it in and hook it up. it doesn't even need to be a jail if you are just building.. a chroot should be good enough. (with a /dev mounted in it usually) (for /dev/null and such). > > -aps From pisymbol at gmail.com Fri Jun 20 23:51:59 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Fri Jun 20 23:52:04 2008 Subject: Cross platform building best practices (building 6 on 7) In-Reply-To: <485C28E5.3070909@elischer.org> References: <3c0b01820806190629o7264cfaeg6fa6a08a6822047e@mail.gmail.com> <7d6fde3d0806190822s1420dcake3a38be7189b8ab0@mail.gmail.com> <3c0b01820806201352n54b846cas612a6923531ef04@mail.gmail.com> <485C1DC5.8090007@elischer.org> <3c0b01820806201424n53371437m8e9af5507416926e@mail.gmail.com> <485C28E5.3070909@elischer.org> Message-ID: <3c0b01820806201651n70d0c903kae17298eefe152ec@mail.gmail.com> On Fri, Jun 20, 2008 at 6:02 PM, Julian Elischer wrote: > Alexander Sack wrote: >> >> On Fri, Jun 20, 2008 at 5:14 PM, Julian Elischer >> wrote: >>> >>> Alexander Sack wrote: >>>> >>>> On Thu, Jun 19, 2008 at 11:22 AM, Garrett Cooper >>>> wrote: >>>>> >>>>> On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack >>>>> wrote: >>>>>> >>>>>> Hello Folks: >>>>>> >>>>>> I've done a lot of Googling and scouring the lists about this >>>>>> particular subject so I apologize for rehashing it. However, I'm >>>>>> still confused on what's the best way to perform BSD cross platform >>>>>> builds. Ideally what I want to have is an environment whereby I can >>>>>> build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I >>>>>> could check out a 6.1 release version, perform make world, and then >>>>>> use the output of that build as either a basis for a jail or a >>>>>> toolchain. However, as noted by previous threads, 6.x doesn't build >>>>>> on a 7.x due to gcc4/binutils compatibility issues (please correct me >>>>>> if I'm wrong). I then thought I could potentially download a patched >>>>>> binutils, copy it into src/contrib/binutils and that would potentially >>>>>> fix it. No dice (and I'm still debugging why since this binutils >>>>>> package DOES build outside of the make world infrastructure without >>>>>> issue, this very well could be pilot error on my part since I didn't >>>>>> update the VERSION string and didn't trim the source files as per the >>>>>> FreeBSD-deleteList etc.). >>>>>> >>>>>> I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could >>>>>> complie a 6.x on a 7.x machine. Well I haven't done that yet since at >>>>>> this point I believe I'm diverged from the path of FreeBSD build >>>>>> enlightenment! Moreover, if would be NICE if I could bootstrap the >>>>>> normal dev tools from the exiting make world build tree. I'm not yet >>>>>> ready for a lot of hackery on the build tree without asking around. >>>>>> :D! >>>>>> >>>>>> Does anyone due cross-platform builds (without host virtualization)? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> -aps >>>>> >>>>> (I'll stick to just hackers@ because I don't want to pollute >>>>> questions@ unnecessarily) >>>> >>>> Sorry I felt really bad actually cc'ing questions its just that my >>>> last groking produced many threads in freebsd-questions as opposed to >>>> hackers. I'll try to be more attentive to my posts (I have a habit >>>> cc'ing multiple forums because sometimes they apply but questions is >>>> for normal troubleshooting, not cross-platform build issues!). >>>> >>>>> You touched on an important point. There were some code quality issues >>>>> (I think) with 6.x that were resolved moving to 7.x, which caused >>>>> gcc-4.2.x to barf. >>>> >>>> Probably but I'm not trying to point fingers! :D! >>>> >>>>> gcc-4.2.x requires a newer version of binutils, just because (for API >>>>> / usage compatibility). >>>> >>>> Yea understood. To be honest, this isn't documented very readily. I >>>> first thought it was pilot error on me, then I decided to take a look >>>> at what failed to compile (I believe it was an innocent extern). And >>>> then got lost in gcc/binutils hell. Luckily I've smelled this problem >>>> before and after some research confirmed by suspicion. >>>> >>>>> What you should probably do is create a jail then do your development >>>>> for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...) >>>>> do 8.x development in yet a third. Jail's are a much better way to >>>>> isolate things such that you don't have to worry about toolchain >>>>> issues like these and are able to setup a sourcebase as the devs >>>>> intended it (for the most part; you may run into issues with sysctls >>>>> and virtual kernel stuff like that, but cest la vie... there isn't a >>>>> better way I know of than that outside of running a VM). >>>> >>>> I figured you were going ot say that Garrett. Well OK, but I still >>>> need to bootstrap my dev environment for 6.x development on 7.x. >>>> Since binutils compatibility makes my 6.x make world barf on 7.x, >>>> where should I go? I HAVE not parsed through a lot of the build >>>> infrastructure yet but it would seem to be IF make world bootstraps >>>> the world including the development tools, why can't I update >>>> binutils/gcc inplace and then compile (or is this a regression issue >>>> which I failed to grasp). Or do I need to update binutils on my >>>> *host* system itself? i.e. what I'm really asking is does make world >>>> bootstrap the right bintuils/gcc etc. and then use THAT to compile the >>>> rest or does it just perform a host build of everything and plops it >>>> in DESTDIR? >>>> >>>> Hope I make some sense here (still a n00b).... >>> >>> One thing we always strive for in FreeBSD is an upgrade path. >>> >>> As a general rule, a newer system should be able to run a jail >>> populated with an earlier system. There are some small exceptions, >>> for example you may need a new version of netstat, ps and libkvm >>> in your jail. possibly grab them from the /rescue on the new system >>> so they are statically linked. >>> also 8.x systems will require that threaded programs from 6.x be >>> dynamically >>> linked so that they can be remapped to use libthr instead of libkse as >>> libkse is not supported in 8. >> >> So you are talking about binary/ABI compatibility yes? So I would >> assume what you are saying is I can take a 6.x system, create a >> filesystem tarball, drop it on a 7.x system and then create a jail out >> of it. >> >>> asside from those I think that just about every thing else should be >>> fine.. >>> I've run a FreeBSD 1.1 chroot on a freeBSD 7 system >>> (I had to make 1 very small fix). >>> >>> At Ironport we build 4.x binaries on 6.x systems by spinning off >>> a 4.x chroot as prart of the build process. (they need to link with 4.x >>> third party binaries) so it's very esay to do. >> >> I believe this answers my question but I want to confirm. I THOUGHT >> about this but I wanted a more *cleanroom* approach. That's all. > > this is about as cleanroom as you can get.. > you create a tarball of a virgin 6.x distribution including > virgin stuff you need, and then every time you need to do a > new 6.x jail, you just drop it in and hook it up. > > it doesn't even need to be a jail if you are just building.. > a chroot should be good enough. (with a /dev mounted in it usually) > (for /dev/null and such). Alright Julian, sounds reasonable. I just wanted to confirm on the list that this is really acceptable and I won't (generally speaking) run into any ABI issues (clearly on other platforms, this is NOT always the case!). Thanks again guys, -aps From joe at via.net Sat Jun 21 03:31:03 2008 From: joe at via.net (joe mcguckin) Date: Sat Jun 21 03:31:07 2008 Subject: Looking for *cheap* embedded platform w- 2 ethernets Message-ID: <7A966B3C-044F-4794-949B-F92B60E8F674@via.net> I'm looking for a cheap and small embedded platform to use as a portable vpn endpoint. It doesn't have to be fast, it just has to run *BSD. Any suggestions?? Thanks, Joe Joe McGuckin ViaNet Communications joe@via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax From patfbsd at davenulle.org Sat Jun 21 10:02:21 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Sat Jun 21 10:02:25 2008 Subject: Looking for *cheap* embedded platform w- 2 ethernets In-Reply-To: <7A966B3C-044F-4794-949B-F92B60E8F674@via.net> References: <7A966B3C-044F-4794-949B-F92B60E8F674@via.net> Message-ID: <20080621120216.7ac08502@baby-jane-lamaiziere-net.local> Le Fri, 20 Jun 2008 20:07:46 -0700, joe mcguckin a ?crit : > I'm looking for a cheap and small embedded platform to use as a > portable vpn endpoint. It doesn't have to be fast, it just has to > run *BSD. > > Any suggestions?? May be a Soekris box. http://www.soekris.com/ From ap at bnc.net Sat Jun 21 11:19:55 2008 From: ap at bnc.net (Achim Patzner) Date: Sat Jun 21 11:20:00 2008 Subject: Looking for *cheap* embedded platform w- 2 ethernets In-Reply-To: <7A966B3C-044F-4794-949B-F92B60E8F674@via.net> References: <7A966B3C-044F-4794-949B-F92B60E8F674@via.net> Message-ID: Am 21.06.2008 um 05:07 schrieb joe mcguckin: > Any suggestions?? Fit-PC Achim From patfbsd at davenulle.org Sat Jun 21 13:27:58 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Sat Jun 21 13:28:03 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <20080607041855.GA3462@garage.freebsd.pl> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080607041855.GA3462@garage.freebsd.pl> Message-ID: <20080621152751.4aebc9e9@baby-jane-lamaiziere-net.local> Le Sat, 7 Jun 2008 06:18:55 +0200, Pawel Jakub Dawidek a ?crit : Hello, > On Fri, Jun 06, 2008 at 11:41:35PM +0200, Patrick Lamaizi?re wrote: > > Dears, > > > > I'm trying to port the glxsb driver from OpenBSD to FreeBSD 7-STABLE > > (via the NetBSD port). > > Cool. > > > " The glxsb driver supports the security block of the Geode LX > > series processors. The Geode LX is a member of the AMD Geode family > > of integrated x86 system chips. > > > > Driven by periodic checks for available data from the generator, > > glxsb supplies entropy to the random(4) driver for common usage. > > > > glxsb also supports acceleration of AES-128-CBC operations for > > crypto(4)." [cut] > > - The driver does a busy wait to check the completion of the > > encryption. I think it would be beter to use the interrupt. I will > > look later. > > I remember looking at that code sometime ago and that bit is really > lame, so lame that I think they would do it in a different way if that > was possible. Maybe it's worth contacting OpenBSD/NetBSD and ask? > There might be a good reason for that. I've made some tests that use the interrupt for completion. It is far slower than the "busy wait" in "real time". Tests to encrypt a file (361Mbytes) with openssl /usr/bin/time -h openssl enc -e -aes-128-cbc -in file -out /dev/null -k abcdefghijk -nosalt - Without the hardware : 1m11.57s real 1m7.69s user 3.34s sys - With cryptodev and interrupt 1m27.08s real 1.58s user 6.85s sys - With cryptodev and a busy wait in crypto_process() (the actual version of the driver) 18.41s real 1.51s user 16.75s sys - With cryptodev and a busy wait, but instead of blocking in crypto_process() (i think it's really bad), I use a taskqueue(9) to process the encryption. 21.11s real 1.57s user 6.41s sys So with a taskqueue, it seems less agressive for the kernel but it takes a litle more amount of time to complete. Anyway i can't uses a busy wait in crypto_process(), the man of crypto(9) says: "The process() routine is invoked with a request to perform crypto processing. This routine must not block, but should queue the request and return immediately." I would like your comments about the use of the task queue. I am not sure if i used the Good Way To Do(TM). - I use a private taskqueue with priority PI_NET. Is it Ok for the priority ? Shall I use a predefined system taskqueue instead ? - Only one task can be enqueued at a time, so i have to block the Open crypto framework, i use a counter (int) protected by a mutex. If a task is being processing, crypto_process() return ERESTART to block the crypto engine. static int crypto_process() { ... mtx_lock(&sc->sc_crypto_mtx); if (sc->sc_busy != 0) { mtx_unlock(&sc->sc_crypto_mtx); return (ERESTART); } sc->sc_busy++; mtx_unlock(&sc->sc_crypto_mtx); taskqueue_enqueue(sc->sc_tq, &sc->sc_crypto_task); return(0); } /* the task */ void crypto_task(void *arg, int pending) { [perform encryption] mtx_lock(&sc->sc_crypto_mtx); sc->sc_busy--; mtx_unlock(&sc->sc_crypto_mtx); /* shall i check that we are blocked ?*/ crypto_unblock(sc->sc_cid, CRYPTO_SYMQ); crypto_done(crp); } Does it look good ? > Looks good:) I can do a final review and commit once you are done and > if I'll be able to start my Soekris and test it. Thank you. I have to cleanup the code and check the taskqueue stuff i added. After I will ask on the soekris mailing list if someone can help to test, I don't have any feed back for the moment. I'm asking what stuff i shall provide for a review and commit ? A patch againt CURRENT ? Regards. From mistry.7 at osu.edu Sat Jun 21 14:02:33 2008 From: mistry.7 at osu.edu (Anish Mistry) Date: Sat Jun 21 14:02:38 2008 Subject: Looking for *cheap* embedded platform w- 2 ethernets In-Reply-To: <7A966B3C-044F-4794-949B-F92B60E8F674@via.net> References: <7A966B3C-044F-4794-949B-F92B60E8F674@via.net> Message-ID: <200806210944.11843.mistry.7@osu.edu> On Friday 20 June 2008, joe mcguckin wrote: > I'm looking for a cheap and small embedded platform to use as a > portable vpn endpoint. It doesn't have to be fast, it just has to > run *BSD. > > Any suggestions?? www.pcengines.ch -- Anish Mistry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080621/20b8d4d5/attachment.pgp From ken at mthelicon.com Sun Jun 22 00:00:26 2008 From: ken at mthelicon.com (Pegasus Mc cleaft) Date: Sun Jun 22 00:00:31 2008 Subject: Looking for *cheap* embedded platform w- 2 ethernets In-Reply-To: <200806210944.11843.mistry.7@osu.edu> References: <7A966B3C-044F-4794-949B-F92B60E8F674@via.net> <200806210944.11843.mistry.7@osu.edu> Message-ID: <200806220100.22645.ken@mthelicon.com> On Saturday 21 June 2008 14:44:02 Anish Mistry wrote: > On Friday 20 June 2008, joe mcguckin wrote: > > I'm looking for a cheap and small embedded platform to use as a > > portable vpn endpoint. It doesn't have to be fast, it just has to > > run *BSD. > > > > Any suggestions?? > > www.pcengines.ch Take a look at the sokeris pcb's. I have had good luck making embedded routers out of them. www.sokeris.com ~peg From keramida at freebsd.org Sun Jun 22 03:26:52 2008 From: keramida at freebsd.org (Giorgos Keramidas) Date: Sun Jun 22 03:26:56 2008 Subject: bin/124409: fsck(8) requires exact entry for mountpoints when executing / bug by design in getfsfile(3) in .../lib/libc/gen/fstab.c In-Reply-To: <7d6fde3d0806162028l74172922t4ea47250e7634130@mail.gmail.com> (Garrett Cooper's message of "Mon, 16 Jun 2008 20:28:08 -0700") References: <9C83A8B6-0C73-4A06-A60A-527D7B7BCCE5@gmail.com> <7d6fde3d0806162028l74172922t4ea47250e7634130@mail.gmail.com> Message-ID: <87lk0y416u.fsf_-_@kobe.laptop> On Mon, 16 Jun 2008 20:28:08 -0700, "Garrett Cooper" wrote: > On Tue, Jun 10, 2008 at 2:27 AM, Garrett Cooper wrote: >> Ok.... it appears I wasn't intelligent enough to post this in the right >> place last night. Comments please? >> >> Hi hackers, >> >> I have a question, pending a bug found in getfsfile(3) [1]. >> >> Is there any possibility where a mountpoint be any value other >> >> than a directory, a symlink, or "none", i.e. a flat file? >> >> Thanks, >> >> -Garrett >> >> References: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/124409 (not fully in PR >> >> database yet). > > Going once, going twice... Hi Garrett :-) When I wrote the original comment in that PR I had something like this in mind: %%% *** src.7789d2851415/lib/libc/gen/fstab.c Sun Jun 22 05:57:09 2008 --- /home/build/src/lib/libc/gen/fstab.c Sun Jun 22 05:56:48 2008 *************** struct fstab * *** 236,245 **** getfsfile(name) const char *name; { if (setfsent()) ! while (fstabscan()) ! if (!strcmp(_fs_fstab.fs_file, name)) return(&_fs_fstab); return((struct fstab *)NULL); } --- 236,256 ---- getfsfile(name) const char *name; { + char name_path[PATH_MAX]; + char fstab_path[PATH_MAX]; + + if (realpath(name, name_path) == NULL) + return((struct fstab *)NULL); if (setfsent()) ! while (fstabscan()) { ! if (strcmp(_fs_fstab.fs_file, name) == 0 || ! strcmp(_fs_fstab.fs_file, name_path) == 0) ! return(&_fs_fstab); ! if (realpath(_fs_fstab.fs_file, fstab_path) == NULL) ! return((struct fstab *)NULL); ! if (strcmp(fstab_path, name_path) == 0) return(&_fs_fstab); + } return((struct fstab *)NULL); } %%% I tried to avoid unnecessary realpath(3) calls as much as possible, but there is still the possibility for at least N+1 calls, where N is the number of entries in fstab... Can you test the above patch, and let me know if it looks ok, if you have a better fix in the works, etc.? It seems to pass the bug you originally reported when I run: % env LD_PRELOAD=/home/build/obj/home/build/src/lib/libc/libc.so.7 \ fsck ///cdrom/// fsck: exec fsck_cd9660 for /dev/acd0 in /sbin:/usr/sbin: No such file or directory The failure later is ok, because we don't have fsck_cd9660 for CD-ROMs. From ticso at cicely7.cicely.de Sun Jun 22 09:58:43 2008 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Sun Jun 22 09:58:46 2008 Subject: Looking for *cheap* embedded platform w- 2 ethernets In-Reply-To: <7A966B3C-044F-4794-949B-F92B60E8F674@via.net> References: <7A966B3C-044F-4794-949B-F92B60E8F674@via.net> Message-ID: <20080622095827.GF29053@cicely7.cicely.de> On Fri, Jun 20, 2008 at 08:07:46PM -0700, joe mcguckin wrote: > I'm looking for a cheap and small embedded platform to use as a > portable vpn endpoint. It doesn't have to be fast, it just has to > run *BSD. > > Any suggestions?? We build our own ARM9 based board: http://www.small-control.de/FSB-A920-1.html http://www.small-control.de/FSB-A920-1-APG.html -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From gary.jennejohn at freenet.de Sun Jun 22 10:24:08 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sun Jun 22 10:24:11 2008 Subject: Looking for *cheap* embedded platform w- 2 ethernets In-Reply-To: <20080622095827.GF29053@cicely7.cicely.de> References: <7A966B3C-044F-4794-949B-F92B60E8F674@via.net> <20080622095827.GF29053@cicely7.cicely.de> Message-ID: <20080622122406.59e65588@peedub.jennejohn.org> On Sun, 22 Jun 2008 11:58:32 +0200 Bernd Walter wrote: > On Fri, Jun 20, 2008 at 08:07:46PM -0700, joe mcguckin wrote: > > I'm looking for a cheap and small embedded platform to use as a > > portable vpn endpoint. It doesn't have to be fast, it just has to > > run *BSD. > > > > Any suggestions?? > > We build our own ARM9 based board: > http://www.small-control.de/FSB-A920-1.html > http://www.small-control.de/FSB-A920-1-APG.html > Looks like it's soldered by hand. Is it? --- Gary Jennejohn From gabor at FreeBSD.org Sun Jun 22 12:58:21 2008 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Sun Jun 22 12:58:28 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <20080618114917.GB89383@nagual.pp.ru> References: <48577510.4020007@aueb.gr> <48577BD2.4070205@bluemedia.pl> <20080617102900.GA46479@nagual.pp.ru> <485798C4.2050605@FreeBSD.org> <20080618055851.GA85018@nagual.pp.ru> <86zlpjduew.fsf@ds4.des.no> <20080618083739.GA87100@nagual.pp.ru> <867icndqv5.fsf@ds4.des.no> <4858DBF6.5070001@bluemedia.pl> <86skvbc9gn.fsf@ds4.des.no> <20080618114917.GB89383@nagual.pp.ru> Message-ID: <485E4C69.1080805@FreeBSD.org> Andrey Chernov escribi?: > On Wed, Jun 18, 2008 at 12:40:24PM +0200, Dag-Erling Sm??rgrav wrote: > >> For grep, I believe it should simply be a matter of calling setlocale(), >> using wide strings, and using a multibyte regex engine (for appropriate >> values of "simply"). >> > > See my prev reply telling more details. Using wide strings is not so easy, > f.e. all ctype BSD grep now uses should be converted to wctype, input > conversion added, etc. > I've started to work on doing this big change, the first step: http://kovesdan.org/patches/grep-i18n.diff It doesn't work though, each file is recognized as binary with this change. Do you have any idea, why this happens? What am I doing wrong? Regards, Gabor From ache at nagual.pp.ru Sun Jun 22 13:53:55 2008 From: ache at nagual.pp.ru (Andrey Chernov) Date: Sun Jun 22 14:04:56 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <485E4C69.1080805@FreeBSD.org> References: <20080617102900.GA46479@nagual.pp.ru> <485798C4.2050605@FreeBSD.org> <20080618055851.GA85018@nagual.pp.ru> <86zlpjduew.fsf@ds4.des.no> <20080618083739.GA87100@nagual.pp.ru> <867icndqv5.fsf@ds4.des.no> <4858DBF6.5070001@bluemedia.pl> <86skvbc9gn.fsf@ds4.des.no> <20080618114917.GB89383@nagual.pp.ru> <485E4C69.1080805@FreeBSD.org> Message-ID: <20080622135343.GA72068@nagual.pp.ru> On Sun, Jun 22, 2008 at 02:58:17PM +0200, Gabor Kovesdan wrote: > Andrey Chernov escribi?: > > On Wed, Jun 18, 2008 at 12:40:24PM +0200, Dag-Erling Sm??rgrav wrote: > > > >> For grep, I believe it should simply be a matter of calling setlocale(), > >> using wide strings, and using a multibyte regex engine (for appropriate > >> values of "simply"). > >> > > > > See my prev reply telling more details. Using wide strings is not so easy, > > f.e. all ctype BSD grep now uses should be converted to wctype, input > > conversion added, etc. > > > I've started to work on doing this big change, the first step: > http://kovesdan.org/patches/grep-i18n.diff 1) You can't convert just whole buffer after fread() since it can be ended in the middle of multibyte sequence on BUFSIZ edge. Look how GNU utils do it. 2) Better use iswspace and iswcntrl instead of iswctype. 3) util.c needs to be fixed in several places too. -- http://ache.pp.ru/ From patfbsd at davenulle.org Sun Jun 22 15:05:12 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Sun Jun 22 15:05:21 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <20080606234135.46144207@baby-jane-lamaiziere-net.local> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> Message-ID: <20080622170507.5ac469d2@baby-jane-lamaiziere-net.local> Le Fri, 6 Jun 2008 23:41:35 +0200, Patrick Lamaizi?re a ?crit : Hello, > I'm trying to port the glxsb driver from OpenBSD to FreeBSD 7-STABLE > (via the NetBSD port). > " The glxsb driver supports the security block of the Geode LX > series processors. The Geode LX is a member of the AMD Geode family > of integrated x86 system chips. > > Driven by periodic checks for available data from the generator, > glxsb supplies entropy to the random(4) driver for common usage. > > glxsb also supports acceleration of AES-128-CBC operations for > crypto(4)." Well, I hope this is the final version. http://user.lamaiziere.net/patrick/glxsb-220608.tar.gz I added a patch for FreeBSD 6 but i'am not able to test it. On 7-STABLE, I've tested with hundred openssl encryptions and some flood pings under ipsec in the background. Looks good for me. If someone can test and review it, it would be cool. Thanks, Regards. From ivoras at freebsd.org Sun Jun 22 17:35:07 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Sun Jun 22 17:35:11 2008 Subject: Looking for *cheap* embedded platform w- 2 ethernets In-Reply-To: <7A966B3C-044F-4794-949B-F92B60E8F674@via.net> References: <7A966B3C-044F-4794-949B-F92B60E8F674@via.net> Message-ID: joe mcguckin wrote: > I'm looking for a cheap and small embedded platform to use as a portable > vpn endpoint. It doesn't have to be fast, it just has to > run *BSD. > > Any suggestions?? You'll probably have to define what "cheap" means to you. I don't have much experience with small / embedded equipment but this product: http://www.fit-pc.com/new/specifications.html works for me ($300). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080622/24fdc773/signature.pgp From ndenev at gmail.com Sun Jun 22 18:02:08 2008 From: ndenev at gmail.com (Niki Denev) Date: Sun Jun 22 18:17:59 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <20080622170507.5ac469d2@baby-jane-lamaiziere-net.local> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080622170507.5ac469d2@baby-jane-lamaiziere-net.local> Message-ID: <2e77fc10806221101q684baf47r9ee7208a676f59e@mail.gmail.com> On Sun, Jun 22, 2008 at 6:05 PM, Patrick Lamaizi?re wrote: > Le Fri, 6 Jun 2008 23:41:35 +0200, > Patrick Lamaizi?re a ?crit : > > Hello, > >> I'm trying to port the glxsb driver from OpenBSD to FreeBSD 7-STABLE >> (via the NetBSD port). >> " The glxsb driver supports the security block of the Geode LX >> series processors. The Geode LX is a member of the AMD Geode family >> of integrated x86 system chips. >> >> Driven by periodic checks for available data from the generator, >> glxsb supplies entropy to the random(4) driver for common usage. >> >> glxsb also supports acceleration of AES-128-CBC operations for >> crypto(4)." > > Well, I hope this is the final version. > > http://user.lamaiziere.net/patrick/glxsb-220608.tar.gz > > I added a patch for FreeBSD 6 but i'am not able to test it. > > On 7-STABLE, I've tested with hundred openssl encryptions and some flood > pings under ipsec in the background. Looks good for me. > > If someone can test and review it, it would be cool. > > Thanks, Regards. It compiles on without a problem on 6.2 and loads on my Soekris Net5501-70 running pfSense (6.2-RELEASE-p11) glxsb0: mem 0xa0000000-0xa0003fff irq 10 at device 1.2 on pci0 Thanks!, Niki From patfbsd at davenulle.org Sun Jun 22 18:20:44 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Sun Jun 22 18:20:47 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080622170507.5ac469d2@baby-jane-lamaiziere-net.local> Message-ID: <20080622202041.07f85145@baby-jane-lamaiziere-net.local> Le Sun, 22 Jun 2008 19:40:04 +0200, Ivan Voras a ?crit : > Ivan Voras wrote: > > > The results are practically the same. > > On the other hand: > > ursaminor:~/admin/glxsb> dd if=/dev/zero bs=4k count=100000 | openssl > enc -aes-128-cbc -e -out /dev/null -nosalt -k abcdefhij > 100000+0 records in > 100000+0 records out > 409600000 bytes transferred in 77.653939 secs (5274684 bytes/sec) > > ursaminor:~/admin/glxsb> dd if=/dev/zero bs=4k count=100000 | openssl > enc -aes-128-cbc -e -out /dev/null -nosalt -k abcdefhij -engine > cryptodev engine "cryptodev" set. > 100000+0 records in > 100000+0 records out > 409600000 bytes transferred in 21.486846 secs (19062826 bytes/sec) > > So I guess it works. Any idea why "openssl speed" doesn't show it? On FreeBSD 7, OpenSSL does not use the cryptodev engine by default. This is a known problem. See http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2008-06/msg00076.html openssl speed -evp aes-128-cbc -elapsed -engine cryptodev From ivoras at freebsd.org Sun Jun 22 19:20:03 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Sun Jun 22 19:20:10 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <20080622202041.07f85145@baby-jane-lamaiziere-net.local> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080622170507.5ac469d2@baby-jane-lamaiziere-net.local> <20080622202041.07f85145@baby-jane-lamaiziere-net.local> Message-ID: <9bbcef730806221220u4f8a3f45q305a927efdf5e16f@mail.gmail.com> 2008/6/22 Patrick Lamaizi?re : > openssl speed -evp aes-128-cbc -elapsed -engine cryptodev I see the "-evp" parameter makes the difference in "openssl speed": > openssl speed -engine cryptodev -elapsed -evp aes-128-cbc aes-128-cbc engine "cryptodev" set. You have chosen to measure elapsed time instead of user CPU time. To get the most accurate results, try to run this program when this computer is idle. Doing aes-128 cbc for 3s on 16 size blocks: 1005992 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 262256 aes-128 cbc's in 3.01s Doing aes-128 cbc for 3s on 256 size blocks: 66470 aes-128 cbc's in 3.01s Doing aes-128 cbc for 3s on 1024 size blocks: 16575 aes-128 cbc's in 3.01s Doing aes-128 cbc for 3s on 8192 size blocks: 2087 aes-128 cbc's in 3.01s Doing aes-128-cbc for 3s on 16 size blocks: 74195 aes-128-cbc's in 3.01s Doing aes-128-cbc for 3s on 64 size blocks: 69208 aes-128-cbc's in 3.01s Doing aes-128-cbc for 3s on 256 size blocks: 64154 aes-128-cbc's in 3.01s Doing aes-128-cbc for 3s on 1024 size blocks: 44369 aes-128-cbc's in 3.01s Doing aes-128-cbc for 3s on 8192 size blocks: 9512 aes-128-cbc's in 3.01s OpenSSL 0.9.8e 23 Feb 2007 built on: Tue Apr 15 19:40:37 CEST 2008 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx) compiler: cc available timing options: USE_TOD HZ=128 [sysconf value] timing function used: gettimeofday The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 5359.57k 5577.49k 5654.53k 5639.81k 5679.65k aes-128-cbc 394.62k 1471.97k 5457.89k 15097.21k 25895.72k From ken at mthelicon.com Sun Jun 22 21:12:50 2008 From: ken at mthelicon.com (Pegasus Mc cleaft) Date: Sun Jun 22 21:12:54 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <20080622202041.07f85145@baby-jane-lamaiziere-net.local> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080622202041.07f85145@baby-jane-lamaiziere-net.local> Message-ID: <200806222212.45861.ken@mthelicon.com> On Sunday 22 June 2008 19:20:41 Patrick Lamaizi?re wrote: > On FreeBSD 7, OpenSSL does not use the cryptodev engine by default. This > is a known problem. See > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2008-06/msg00076.ht >ml > > openssl speed -evp aes-128-cbc -elapsed -engine cryptodev Try patching openssl to force the use of the crypto hardware by default (like ssh, etc) ~Peg --- eng_cryptodev.c.orig 2008-02-05 18:10:31.000000000 +0000 +++ eng_cryptodev.c 2008-06-14 18:25:36.175353823 +0100 @@ -1127,6 +1127,7 @@ } ENGINE_add(engine); + ENGINE_set_default_ciphers(engine); ENGINE_free(engine); ERR_clear_error(); } From gerryw at compvia.com Mon Jun 23 03:14:11 2008 From: gerryw at compvia.com (Gerry Weaver) Date: Mon Jun 23 03:14:14 2008 Subject: Kernel module advice for bandwidth monitor Message-ID: <20080623010203.9a1561c9@mail01> Hello All, I am just starting to dig into FreeBSD kernel development and the pfil interface in particular. I am in need of some advice and possibly some pointers to relevant documentation. I want to develop a bandwidth control driver and the associated monitoring code. It seems that the bandwidth control part of the equation is fairly straight forward with regard to the pfil framework. However, my current dilemma centers around the best way to implement monitoring. There seem to be several approaches to doing this. There is the bandwidth control driver itself, the bpf interface and the pcap library. My question concerns performance and network latency. It would be a given that any approach to monitoring is going to add some overhead in these areas, but I'm interested in minimizing this as much as possible. This is precisely where I was hoping to get some advice from the kernel gurus out there. I assume that it is possible for a kernel driver to communicate over the network. If, so it would seem that no context switch to user space would be necessary to transmit stats to another monitor machine. If the bpf or pcap mechanisms were employed, user space would become involved. Given the various methods of accessing packet data, and the fact that I want to send stats to another machine, which approach would require the least overhead? Also, are there any good docs or possibly some code that I could look at that would illustrate the requirements/details of network communication from within a kernel driver? I searched the relevant lists for this, but was not able to find anything that looked like what I needed. I apologize if I have missed something. Please forgive my newbness as I'm just starting out. Hopefully my questions are not too foolish ;) Thanks, Gerry From kamikaze at bsdforen.de Mon Jun 23 07:06:06 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Mon Jun 23 11:16:01 2008 Subject: FreeBSD fusefs-kmod shutdown problem workaround In-Reply-To: <200806221615.50498.amistry@am-productions.biz> References: <485EAE11.2050808@bsdforen.de> <200806221615.50498.amistry@am-productions.biz> Message-ID: <485F4593.9050807@bsdforen.de> Anish Mistry wrote: > On Sunday 22 June 2008, Dominic Fandrey wrote: >> I know these are desperate mesures, but the problem that fusefs >> doesn't write everything back to the disk before a shutdown is >> completed remains, because the rc script is often shot down by >> the shutdown watchdog. >> >> Hence I have extended my workaround to force stop the watchdog >> until everything is written to the media. >> >> Regards, >> Dominic >> >> diff -Pur ports/sysutils/fusefs-kmod.orig/files/fusefs.in >> ports/sysutils/fusefs-kmod/files/fusefs.in --- >> ports/sysutils/fusefs-kmod.orig/files/fusefs.in 2008-06-22 >> 21:35:27.000000000 +0200 +++ >> ports/sysutils/fusefs-kmod/files/fusefs.in 2008-06-22 >> 21:44:34.000000000 +0200 @@ -50,9 +50,18 @@ >> ;; >> esac >> done >> + >> + # This is an evil yet necessary hack to give fuse the time to >> + # write all data to the media before the system is shut down. >> + if [ -n "$rcshutdown_timeout" -a -n "$_rcshutdown_watchdog" ]; then >> + /bin/kill -STOP "$_rcshutdown_watchdog" >> + fi >> until kldunload $kmod; do >> /bin/sleep 0.25 >> done >> + if [ -n "$rcshutdown_timeout" -a -n "$_rcshutdown_watchdog" ]; then >> + /bin/kill -CONT "$_rcshutdown_watchdog" >> + fi >> } >> load_rc_config $name > Please open a PR, this is out of my comfort zone by doing "evil" stuff > during shutdown. It would probably be helpful to bring up this on > hackers/current by showing your patch. Hopefully we can get some > attention and get the necessary changes in the base/kernel to do > this "right". It does look like there is a solution in Csaba's > development version. > Did you take a look at Csaba's message on hackers at the beginning of > January? > Thanks for the pointer. Unfortunately it seems that Csaba's patch only allows you to stall shutdown for 10 seconds. After heavy writing more than a minute can be necessary to prevent data loss. I have created a problem report: ports/124901 http://www.freebsd.org/cgi/query-pr.cgi?pr=124901 I hope this will make it. To me data loss and file system corruption are the worst case scenario and to me it's worth stalling shutdown for as long as it takes to write the data. Regards, Dominic From patfbsd at davenulle.org Mon Jun 23 17:48:03 2008 From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=) Date: Mon Jun 23 17:48:07 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <9bbcef730806221220u4f8a3f45q305a927efdf5e16f@mail.gmail.com> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080622170507.5ac469d2@baby-jane-lamaiziere-net.local> <20080622202041.07f85145@baby-jane-lamaiziere-net.local> <9bbcef730806221220u4f8a3f45q305a927efdf5e16f@mail.gmail.com> Message-ID: <20080623194758.6df9cafc@baby-jane-lamaiziere-net.local> Le Sun, 22 Jun 2008 21:20:02 +0200, "Ivan Voras" a ?crit : Hi, > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes > 8192 bytes aes-128 cbc 5359.57k 5577.49k 5654.53k > 5639.81k 5679.65k aes-128-cbc 394.62k 1471.97k > 5457.89k 15097.21k 25895.72k I've got the same results. The encryption of a file of 360 MBytes takes around 20s with the hardware and 1m10s by software. I am playing to overload my box (a soekris net5501) with ping floods on ipsec (hmac-md5 and rijndael) by a modern computer. With four 'ping -f -s 3000', 'top' reports CPU "0.4% user 0.0 nice 1.6% system, 90.3% interrupt, 7.8% idle". With five 'ping', top does not run, and the kernel does not display the message 'limiting icmp ping response to 300 to 200' anymore too (on the serial console). With the hardware, i can use 8 flood pings without any problem. Top shows CPU: 0.0% user, 0.0% nice, 33.5% system, 12.5% interrupt, 54.1% idle And the kernel displays "limiting icmp ping response from 900 to 200 packets/s.", instead '300 to 200'. So it seems there is a real improvement. Regards. From jhb at freebsd.org Mon Jun 23 18:52:32 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Jun 23 18:52:36 2008 Subject: FreeBSD 6.3 deadlock (vm_map?) with DDB output In-Reply-To: <485A81FF.1000000@gritton.org> References: <20080615112318.146C1F18512@mx.npubs.com> <200806180917.05689.jhb@freebsd.org> <485A81FF.1000000@gritton.org> Message-ID: <200806231451.52340.jhb@freebsd.org> On Thursday 19 June 2008 11:57:51 am James Gritton wrote: > John Baldwin wrote: > > On Sunday 15 June 2008 07:23:19 am Stef Walter wrote: > > > >> I've been trying to track down a deadlock on some newish production > >> servers running FreeBSD 6.3-RELEASE-p2. The deadlock occurs on a > >> specific (although mundane) hardware configuration, and each of several > >> servers running this hardware deadlock about once per week. > >> > >> Although I suspect that this is not hardware related, from a (naive) > >> perusal of the attached stack traces. > >> > >> Forgive me if my interpretation of this is all wrong, but I'm pretty > >> desperate for help. So here's my basic understanding of the deadlock: > >> > >> These processes seem to be waiting on the page queue mutex: > >> sendmail (in vm_mmap > vm_map_find > vm_map_insert > vm_map_pmap_enter) > >> bsnmpd (in malloc, uma_large_malloc > page_alloc > kmem_malloc) > >> httpd (in trap > trap_pfault > vm_fault) > >> [g_up] (in g_vfs_done > bufdone) > >> > >> The page queue mutex is held by rsync process: > >> rsync (in trap > trap_pfault > vm_fault > pmap_enter) > >> > >> Rsync kernel process (in pmap_enter) was interrupted while holding the > >> page queue lock? > >> > >> > >> Giant is enabled in loader.conf due to the needs of the pf firewall when > >> dealing with user credentials lookups. I do not believe that Giant plays > >> into this deadlock. Kernel config attached. > >> > >> Any and all help or info is welcome. Thanks in advance. > >> > > > > Try this change: > > > > jhb 2007-10-27 22:07:40 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/kern sched_4bsd.c > > Log: > > Change the roundrobin implementation in the 4BSD scheduler to trigger a > > userland preemption directly from hardclock() via sched_clock() when a > > thread uses up a full quantum instead of using a periodic timeout to cause > > a userland preemption every so often. This fixes a potential deadlock > > when IPI_PREEMPTION isn't enabled where softclock blocks on a lock held > > by a thread pinned or bound to another CPU. The current thread on that > > CPU will never be preempted while softclock is blocked. > > > > Note that ULE already drives its round-robin userland preemption from > > sched_clock() as well and always enables IPI_PREEMPT. > > > > MFC after: 1 week > > > > Revision Changes Path > > 1.108 +8 -29 src/sys/kern/sched_4bsd.c > > > > We use it at work on 6.x. W/o this fix, round-robin stops working on 4BSD > > when softclock() (swi4: clock) blocks on a lock like Giant. > > > > I've been seeing similar troubles on 6.2 and I'll have to give this a > try as we upgrade to 6.3. I notice "MFC after: 1 week" in the log; it's > been a week - any chance of seeing this fix rolled into 6.x? If people confirm it fixes issues I will MFC it. There was some pushback when I first committed it so I waited on the MFC. -- John Baldwin From zbeeble at gmail.com Mon Jun 23 19:09:51 2008 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Mon Jun 23 19:10:04 2008 Subject: FreeBSD fusefs-kmod shutdown problem workaround In-Reply-To: <485F4593.9050807@bsdforen.de> References: <485EAE11.2050808@bsdforen.de> <200806221615.50498.amistry@am-productions.biz> <485F4593.9050807@bsdforen.de> Message-ID: <5f67a8c40806231141vf7b9567mdf75e81f32169211@mail.gmail.com> On Mon, Jun 23, 2008 at 2:41 AM, Dominic Fandrey wrote: > Thanks for the pointer. Unfortunately it seems that Csaba's patch only > allows you to stall shutdown for 10 seconds. After heavy writing > more than a minute can be necessary to prevent data loss. > > I have created a problem report: ports/124901 > http://www.freebsd.org/cgi/query-pr.cgi?pr=124901 > > I hope this will make it. To me data loss and file system corruption > are the worst case scenario and to me it's worth stalling shutdown > for as long as it takes to write the data. > The shutdown watchdog timer is something I've had to adjust many times for many different ports. Given this; I propose we have (at least) a new rcorder script variable. Something like "SHUTTIME" encoding the expected number of seconds required for the daemon to shutdown in the worst case. Ideally, you'd want an overall watchdog and a per-script watchdog (so that you're not waiting the sum of all these times in most cases). From jamie at gritton.org Mon Jun 23 19:16:47 2008 From: jamie at gritton.org (James Gritton) Date: Mon Jun 23 19:16:56 2008 Subject: FreeBSD 6.3 deadlock (vm_map?) with DDB output In-Reply-To: <200806231451.52340.jhb@freebsd.org> References: <20080615112318.146C1F18512@mx.npubs.com> <200806180917.05689.jhb@freebsd.org> <485A81FF.1000000@gritton.org> <200806231451.52340.jhb@freebsd.org> Message-ID: <485FF698.103@gritton.org> John Baldwin wrote: > On Thursday 19 June 2008 11:57:51 am James Gritton wrote: > >> John Baldwin wrote: >> >>> On Sunday 15 June 2008 07:23:19 am Stef Walter wrote: >>> >>> >>>> I've been trying to track down a deadlock on some newish production >>>> servers running FreeBSD 6.3-RELEASE-p2. The deadlock occurs on a >>>> specific (although mundane) hardware configuration, and each of several >>>> servers running this hardware deadlock about once per week. >>>> >>>> Although I suspect that this is not hardware related, from a (naive) >>>> perusal of the attached stack traces. >>>> >>>> Forgive me if my interpretation of this is all wrong, but I'm pretty >>>> desperate for help. So here's my basic understanding of the deadlock: >>>> >>>> These processes seem to be waiting on the page queue mutex: >>>> sendmail (in vm_mmap > vm_map_find > vm_map_insert > vm_map_pmap_enter) >>>> bsnmpd (in malloc, uma_large_malloc > page_alloc > kmem_malloc) >>>> httpd (in trap > trap_pfault > vm_fault) >>>> [g_up] (in g_vfs_done > bufdone) >>>> >>>> The page queue mutex is held by rsync process: >>>> rsync (in trap > trap_pfault > vm_fault > pmap_enter) >>>> >>>> Rsync kernel process (in pmap_enter) was interrupted while holding the >>>> page queue lock? >>>> >>>> >>>> Giant is enabled in loader.conf due to the needs of the pf firewall when >>>> dealing with user credentials lookups. I do not believe that Giant plays >>>> into this deadlock. Kernel config attached. >>>> >>>> Any and all help or info is welcome. Thanks in advance. >>>> >>>> >>> Try this change: >>> >>> jhb 2007-10-27 22:07:40 UTC >>> >>> FreeBSD src repository >>> >>> Modified files: >>> sys/kern sched_4bsd.c >>> Log: >>> Change the roundrobin implementation in the 4BSD scheduler to trigger a >>> userland preemption directly from hardclock() via sched_clock() when a >>> thread uses up a full quantum instead of using a periodic timeout to >>> > cause > >>> a userland preemption every so often. This fixes a potential deadlock >>> when IPI_PREEMPTION isn't enabled where softclock blocks on a lock held >>> by a thread pinned or bound to another CPU. The current thread on that >>> CPU will never be preempted while softclock is blocked. >>> >>> Note that ULE already drives its round-robin userland preemption from >>> sched_clock() as well and always enables IPI_PREEMPT. >>> >>> MFC after: 1 week >>> >>> Revision Changes Path >>> 1.108 +8 -29 src/sys/kern/sched_4bsd.c >>> >>> We use it at work on 6.x. W/o this fix, round-robin stops working on 4BSD >>> when softclock() (swi4: clock) blocks on a lock like Giant. >>> >>> >> I've been seeing similar troubles on 6.2 and I'll have to give this a >> try as we upgrade to 6.3. I notice "MFC after: 1 week" in the log; it's >> been a week - any chance of seeing this fix rolled into 6.x? >> > > If people confirm it fixes issues I will MFC it. There was some pushback when > I first committed it so I waited on the MFC. I can confirm that on 6.3 I can recreate the deadlock without the patch, and can't recreate it with the patch. From kostikbel at gmail.com Mon Jun 23 19:26:46 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon Jun 23 19:26:50 2008 Subject: FreeBSD fusefs-kmod shutdown problem workaround In-Reply-To: <5f67a8c40806231141vf7b9567mdf75e81f32169211@mail.gmail.com> References: <485EAE11.2050808@bsdforen.de> <200806221615.50498.amistry@am-productions.biz> <485F4593.9050807@bsdforen.de> <5f67a8c40806231141vf7b9567mdf75e81f32169211@mail.gmail.com> Message-ID: <20080623192622.GD17123@deviant.kiev.zoral.com.ua> On Mon, Jun 23, 2008 at 02:41:29PM -0400, Zaphod Beeblebrox wrote: > On Mon, Jun 23, 2008 at 2:41 AM, Dominic Fandrey > wrote: > > > > Thanks for the pointer. Unfortunately it seems that Csaba's patch only > > allows you to stall shutdown for 10 seconds. After heavy writing > > more than a minute can be necessary to prevent data loss. > > > > I have created a problem report: ports/124901 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=124901 > > > > I hope this will make it. To me data loss and file system corruption > > are the worst case scenario and to me it's worth stalling shutdown > > for as long as it takes to write the data. > > > > The shutdown watchdog timer is something I've had to adjust many times for > many different ports. Given this; > > I propose we have (at least) a new rcorder script variable. Something like > "SHUTTIME" encoding the expected number of seconds required for the daemon > to shutdown in the worst case. > > Ideally, you'd want an overall watchdog and a per-script watchdog (so that > you're not waiting the sum of all these times in most cases). We already have rcshutdown_timeout, see the rc.conf(5) and description of the sysctl kern.init_shutdown_timeout. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080623/2981cdde/attachment.pgp From fluxboxtremist at gmail.com Tue Jun 24 05:06:22 2008 From: fluxboxtremist at gmail.com (Andres Chavez) Date: Tue Jun 24 05:06:25 2008 Subject: 3 connections as one Message-ID: <2de331130806232137h18453fd5hf53296fba3033859@mail.gmail.com> Hi, a friend is challenge me to make use of 3 different connections (one adsl, one cable, and one Evdo) as one single connection to internet, i believe for make faster downloads or something such, its that can be possible ?, if so, can anybody help me with this?, this sounds interesting for know tricks on the FreeBSD operating system, he need to use this box as the network manager and firewall as well, but the connection thing its killing me i dont know how. -- From kamikaze at bsdforen.de Tue Jun 24 07:23:21 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Tue Jun 24 07:23:24 2008 Subject: FreeBSD fusefs-kmod shutdown problem workaround In-Reply-To: <20080623192622.GD17123@deviant.kiev.zoral.com.ua> References: <485EAE11.2050808@bsdforen.de> <200806221615.50498.amistry@am-productions.biz> <485F4593.9050807@bsdforen.de> <5f67a8c40806231141vf7b9567mdf75e81f32169211@mail.gmail.com> <20080623192622.GD17123@deviant.kiev.zoral.com.ua> Message-ID: <4860A0DB.8000100@bsdforen.de> Kostik Belousov wrote: > On Mon, Jun 23, 2008 at 02:41:29PM -0400, Zaphod Beeblebrox wrote: >> On Mon, Jun 23, 2008 at 2:41 AM, Dominic Fandrey >> wrote: >> >> >>> Thanks for the pointer. Unfortunately it seems that Csaba's patch only >>> allows you to stall shutdown for 10 seconds. After heavy writing >>> more than a minute can be necessary to prevent data loss. >>> >>> I have created a problem report: ports/124901 >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=124901 >>> >>> I hope this will make it. To me data loss and file system corruption >>> are the worst case scenario and to me it's worth stalling shutdown >>> for as long as it takes to write the data. >>> >> The shutdown watchdog timer is something I've had to adjust many times for >> many different ports. Given this; >> >> I propose we have (at least) a new rcorder script variable. Something like >> "SHUTTIME" encoding the expected number of seconds required for the daemon >> to shutdown in the worst case. >> >> Ideally, you'd want an overall watchdog and a per-script watchdog (so that >> you're not waiting the sum of all these times in most cases). > > We already have rcshutdown_timeout, see the rc.conf(5) and description > of the sysctl kern.init_shutdown_timeout. He knows that. He just wants something more fine-grained. And rcshutdown_timeout has to be set by the user. Following Zaphod's suggestion I'd like to have a more generous watchdog default (maybe 3 minutes) and a per script watchdog that defaults to something around 30 seconds, but can be changed in the rc script. I'll give that a try tonight. From julian at elischer.org Tue Jun 24 07:26:23 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Jun 24 07:26:30 2008 Subject: 3 connections as one In-Reply-To: <2de331130806232137h18453fd5hf53296fba3033859@mail.gmail.com> References: <2de331130806232137h18453fd5hf53296fba3033859@mail.gmail.com> Message-ID: <4860A1AA.4000709@elischer.org> Andres Chavez wrote: > Hi, a friend is challenge me to make use of 3 different connections (one > adsl, one cable, and one Evdo) as one single connection to internet, i > believe for make faster downloads or something such, its that can be > possible ?, if so, can anybody help me with this?, this sounds interesting > for know tricks on the FreeBSD operating system, he need to use this box as > the network manager and firewall as well, but the connection thing its > killing me i dont know how. > -- > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" do you have a place ountside in the internet that can be used to recobine these three streams? generally if you want to trunk multiple pipes you need to control both ends, if not immediatly, then at least some palce a few hops where tunnels can be terminated and recombined.. I have used mpd for this, but it really dpends on what EXACTLY you consider to be "success". From guru at unixarea.de Tue Jun 24 13:11:54 2008 From: guru at unixarea.de (Matthias Apitz) Date: Tue Jun 24 13:11:58 2008 Subject: eeePC 900 with SSD && reducing writes Message-ID: <20080624131150.GA21185@rebelion.Sisis.de> Hello, I have installed FreeBSD 7.0R on that eeePC 900 and because of the limited life time of the SSD (see http://en.wikipedia.org/wiki/Wear_levelling ) I disabled some logging stuff which I don't need on that tiny laptop, for example: syslogd_enable="NO" sendmail_enable="NONE" cron_enable="NO" newsyslog_enable="NO" as well I have: - not created any swap partition (the box runs fine with 1 GByte RAM) - mount the file systems with 'noatime' - put /tmp into memory file system with 128 MByte any other ideas how to reduces unnecessary often-writes? I'd also like to get rid of 'lastlog' and 'wtmp' but even if the man page claims that they will not be created if they don't exist, they come up again and again; another candidate of not needed log is /var/log/Xorg.n.log ... thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ ?...una sola vez, que es cuanto basta si se trata de verdades definitivas.? ?...only once, which is enough if it has todo with definite truth.? Jos? Saramago, Historia del Cerca de Lisboa From koitsu at FreeBSD.org Tue Jun 24 13:24:12 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Jun 24 13:24:18 2008 Subject: eeePC 900 with SSD && reducing writes In-Reply-To: <20080624131150.GA21185@rebelion.Sisis.de> References: <20080624131150.GA21185@rebelion.Sisis.de> Message-ID: <20080624132412.GA77678@eos.sc1.parodius.com> On Tue, Jun 24, 2008 at 03:11:50PM +0200, Matthias Apitz wrote: > Hello, > > I have installed FreeBSD 7.0R on that eeePC 900 and because of the > limited life time of the SSD (see > http://en.wikipedia.org/wiki/Wear_levelling ) > I disabled some logging stuff which I don't need on that tiny laptop, > ... > any other ideas how to reduces unnecessary often-writes? Why bother? http://www.storagesearch.com/ssdmyths-endurance.html -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From mike at jellydonut.org Tue Jun 24 13:12:22 2008 From: mike at jellydonut.org (Michael Proto) Date: Tue Jun 24 13:29:04 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <20080622170507.5ac469d2@baby-jane-lamaiziere-net.local> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080622170507.5ac469d2@baby-jane-lamaiziere-net.local> Message-ID: <4860EE49.1080706@jellydonut.org> Patrick Lamaizi?re wrote: > Le Fri, 6 Jun 2008 23:41:35 +0200, > Patrick Lamaizi?re a ?crit : > > Hello, > >> I'm trying to port the glxsb driver from OpenBSD to FreeBSD 7-STABLE >> (via the NetBSD port). >> " The glxsb driver supports the security block of the Geode LX >> series processors. The Geode LX is a member of the AMD Geode family >> of integrated x86 system chips. >> >> Driven by periodic checks for available data from the generator, >> glxsb supplies entropy to the random(4) driver for common usage. >> >> glxsb also supports acceleration of AES-128-CBC operations for >> crypto(4)." > > Well, I hope this is the final version. > > http://user.lamaiziere.net/patrick/glxsb-220608.tar.gz > > I added a patch for FreeBSD 6 but i'am not able to test it. > > On 7-STABLE, I've tested with hundred openssl encryptions and some flood > pings under ipsec in the background. Looks good for me. > > If someone can test and review it, it would be cool. I don't know if you built it for this or not, but I just tested your module on 8-CURRENT (last supped May 19) and its working beautifully on an ALIX.3c1 (GeodeLX 700): 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 8.0-CURRENT #0: Thu Jun 5 22:44:20 EDT 2008 root@minibsd8-dev.localnet:/usr/obj/usr/src/sys/MINIBSD8 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Geode(TM) Integrated Processor by AMD PCS (431.65-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2 Features=0x88a93d AMD Features=0xc0400000 real memory = 134217728 (128 MB) avail memory = 126152704 (120 MB) pnpbios: Bad PnP BIOS data checksum wlan: mac acl policy registered K6-family MTRR support enabled (2 registers) ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) cryptosoft0: on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 Geode LX: PC Engines ALIX.2 v0.98 tinyBIOS V1.4a (C)1997-2007 glxsb0: mem 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 Output from "openssl speed -engine cryptodev -elapsed -evp aes-128-cbc aes-128-cbc" engine "cryptodev" set. You have chosen to measure elapsed time instead of user CPU time. To get the most accurate results, try to run this program when this computer is idle. Doing aes-128 cbc for 3s on 16 size blocks: 668161 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 178842 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 256 size blocks: 45510 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 1024 size blocks: 11435 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 8192 size blocks: 1429 aes-128 cbc's in 3.00s Doing aes-128-cbc for 3s on 16 size blocks: 61055 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 59430 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 53475 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 37812 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 9323 aes-128-cbc's in 3.00s OpenSSL 0.9.8e 23 Feb 2007 built on: Thu Jun 5 21:15:55 EDT 2008 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx) compiler: cc available timing options: USE_TOD HZ=128 [sysconf value] timing function used: gettimeofday The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 3563.35k 3815.11k 3883.37k 3901.80k 3900.02k aes-128-cbc 325.65k 1267.73k 4562.72k 12904.84k 25453.89k Thanks for that, hopefully it can/will be committed soon! -Proto From freebsd-jobs at bebik.net Tue Jun 24 15:00:28 2008 From: freebsd-jobs at bebik.net (Rodrigo OSORIO (ros)) Date: Tue Jun 24 15:00:34 2008 Subject: eeePC 900 with SSD && reducing writes In-Reply-To: <20080624131150.GA21185@rebelion.Sisis.de> References: <20080624131150.GA21185@rebelion.Sisis.de> Message-ID: <20080624142811.GA89376@hodja.bebik.net> On 24/06/08 15:11 +0200, Matthias Apitz wrote: > > Hello, > > I have installed FreeBSD 7.0R on that eeePC 900 and because of the > limited life time of the SSD (see > http://en.wikipedia.org/wiki/Wear_levelling ) > I disabled some logging stuff which I don't need on that tiny laptop, > for example: > > syslogd_enable="NO" > sendmail_enable="NONE" > cron_enable="NO" > newsyslog_enable="NO" > > as well I have: > > - not created any swap partition (the box runs fine with 1 GByte RAM) > - mount the file systems with 'noatime' > - put /tmp into memory file system with 128 MByte > > any other ideas how to reduces unnecessary often-writes? > > I'd also like to get rid of 'lastlog' and 'wtmp' but even if the man > page claims that they will not be created if they don't exist, they > come up again and again; > > another candidate of not needed log is > /var/log/Xorg.n.log ... > > thx > > matthias > -- > Matthias Apitz > Manager Technical Support - OCLC GmbH > Gruenwalder Weg 28g - 82041 Oberhaching - Germany > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.oclc.org/ http://www.UnixArea.de/ > b http://gurucubano.blogspot.com/ > ?...una sola vez, que es cuanto basta si se trata de verdades definitivas.? > ?...only once, which is enough if it has todo with definite truth.? > Jos? Saramago, Historia del Cerca de Lisboa > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Hi, Yes, you also can disable the file access time with the 'noatime' option in the fstab. See man mount(8). Regards Rodrigo OSORIO From gary.jennejohn at freenet.de Tue Jun 24 15:15:40 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Tue Jun 24 15:15:44 2008 Subject: eeePC 900 with SSD && reducing writes In-Reply-To: <20080624132412.GA77678@eos.sc1.parodius.com> References: <20080624131150.GA21185@rebelion.Sisis.de> <20080624132412.GA77678@eos.sc1.parodius.com> Message-ID: <20080624171536.24ca2d28@peedub.jennejohn.org> On Tue, 24 Jun 2008 06:24:12 -0700 Jeremy Chadwick wrote: > On Tue, Jun 24, 2008 at 03:11:50PM +0200, Matthias Apitz wrote: > > Hello, > > > > I have installed FreeBSD 7.0R on that eeePC 900 and because of the > > limited life time of the SSD (see > > http://en.wikipedia.org/wiki/Wear_levelling ) > > I disabled some logging stuff which I don't need on that tiny laptop, > > ... > > any other ideas how to reduces unnecessary often-writes? > > Why bother? http://www.storagesearch.com/ssdmyths-endurance.html > I've also seen test results in c't magazine where they did millions of writes to the same physical sector and never saw any errors. The manufacturers have really good internal wear leveling algorithms which are totally transparent to the user. --- Gary Jennejohn From john at kozubik.com Tue Jun 24 15:17:33 2008 From: john at kozubik.com (John Kozubik) Date: Tue Jun 24 15:17:38 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <1213972236.1505.14.camel@scotth.emsphone.com> References: <20080619135114.Y1807@kozubik.com> <20080620083906.71332251xw1ckmu8@webmail.leidinger.net> <1213972236.1505.14.camel@scotth.emsphone.com> Message-ID: <20080624083829.T1807@kozubik.com> On Fri, 20 Jun 2008, Scott T. Hildreth wrote: > > > On Fri, 2008-06-20 at 08:39 +0200, Alexander Leidinger wrote: > > Quoting John Kozubik (from Thu, 19 Jun 2008 > > 14:38:11 -0700 (PDT)): > > > > > First, a bounty has been posted here: > > > > > > http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html > > > > > > > Maybe the bounty would be better spent here, > > This was from an email on the gnome list from Joe Marcus Clarke > > "As to the point about Flash, Kris also mentioned that he has the ear of > someone at Adobe who was hinting that a capable developer willing to > sign an NDA could be given code to work on a native Flash plug-in port. > This could bode well for PC-BSD and FreeBSD should someone step up to > do this work." Perfect. This is exactly what the bounty: http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html is for. I suggest that if you think this is important (as I do) to post a commitment to the bounty, and presumably someone will step forward to speak with Kris, sign an NDA, and get the FreeBSD desktop back to a reasonable level of utility. From xistence at 0x58.com Tue Jun 24 16:13:59 2008 From: xistence at 0x58.com (Bert JW Regeer) Date: Tue Jun 24 16:14:04 2008 Subject: 3 connections as one In-Reply-To: <2de331130806232137h18453fd5hf53296fba3033859@mail.gmail.com> References: <2de331130806232137h18453fd5hf53296fba3033859@mail.gmail.com> Message-ID: <28A84EAA-C3F4-4A9D-A4E4-3B4E58754F3E@0x58.com> On Jun 25, 2008, at 00:07 , Andres Chavez wrote: > Hi, a friend is challenge me to make use of 3 different connections > (one > adsl, one cable, and one Evdo) as one single connection to internet, i > believe for make faster downloads or something such, its that can be > possible ?, if so, can anybody help me with this?, this sounds > interesting > for know tricks on the FreeBSD operating system, he need to use this > box as > the network manager and firewall as well, but the connection thing its > killing me i dont know how. > -- You could use PF's round-robin balancing to pick an outgoing connection: See: http://www.openbsd.org/faq/pf/pools.html#outgoing It contains examples and should help you get everything set up and working as you are asking for. One thing it won't do is make downloads faster, since it is not trunking, but if you have three downloads going, they might all use different paths, thus allowing you to utilise all connections, and thus have an over all faster connection. Bert JW Regeer From shildreth at allantgroup.com Tue Jun 24 16:19:10 2008 From: shildreth at allantgroup.com (Scott T. Hildreth) Date: Tue Jun 24 16:28:25 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <20080624083829.T1807@kozubik.com> References: <20080619135114.Y1807@kozubik.com> <20080620083906.71332251xw1ckmu8@webmail.leidinger.net> <1213972236.1505.14.camel@scotth.emsphone.com> <20080624083829.T1807@kozubik.com> Message-ID: <1214322926.1505.65.camel@scotth.emsphone.com> On Tue, 2008-06-24 at 08:41 -0700, John Kozubik wrote: > > On Fri, 20 Jun 2008, Scott T. Hildreth wrote: > > > > > > > On Fri, 2008-06-20 at 08:39 +0200, Alexander Leidinger wrote: > > > Quoting John Kozubik (from Thu, 19 Jun 2008 > > > 14:38:11 -0700 (PDT)): > > > > > > > First, a bounty has been posted here: > > > > > > > > http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html > > > > > > > > > > > Maybe the bounty would be better spent here, > > > > This was from an email on the gnome list from Joe Marcus Clarke > > > > "As to the point about Flash, Kris also mentioned that he has the ear of > > someone at Adobe who was hinting that a capable developer willing to > > sign an NDA could be given code to work on a native Flash plug-in port. > > This could bode well for PC-BSD and FreeBSD should someone step up to > > do this work." > > > Perfect. This is exactly what the bounty: > > http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html > > is for. I suggest that if you think this is important (as I do) to post a > commitment to the bounty, and presumably someone will step forward to > speak with Kris, sign an NDA, and get the FreeBSD desktop back to a > reasonable level of utility. I wonder how much of a task it would be? Does anyone have any idea what language the clients are written in? From carlsonmark at gmail.com Tue Jun 24 17:29:14 2008 From: carlsonmark at gmail.com (Mark Carlson) Date: Tue Jun 24 17:29:17 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <20080619135114.Y1807@kozubik.com> References: <20080619135114.Y1807@kozubik.com> Message-ID: On 6/19/08, John Kozubik wrote: > > > Don't shoot the messenger: > > > FreeBSD is not useful as a desktop environment without the ability to > support Flash in a stable, well-performing fashion. > > > Running IE in Wine is not a solution. > > Running another OS in vmware to simply browse the web is not a solution. > > Free flash alternatives and flash movie players, etc., are, unfortunately, > not a solution. > > ports/linux-flashplayer9 _is_ a solution, however it (currently) fails > badly. > > > Solution: > > > First, a bounty has been posted here: > > http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html > > We aren't even asking for new code, per se - anyone merely posting a > recipe that allows linux-flashplayer9 to run, without crashing and with > reasonable performance, with a generic browser (opera, firefox, konqueror) > can claim the bounty. In fact, a recipe that is entirely inside the Linux > Binary Compatibility layer would be just fine - running the linux version > of a browser through binary compat is reasonable[1]. > > Second, I am calling on the FreeBSD Foundation to commit time and money to > ensuring that flash functionality is recognized as a high priority for > FreeBSD desktop use. I am willing to donate funds for this purpose. > Flash 9 will not be the baseline forever, and it is inefficient to ramp up > a grass roots bounty effort each time Adobe releases a new product. For > this reason I believe it is reasonable for the project itself to ensure > that Flash support is delivered and maintained in a timely fashion. > > > > [1] Since we're all probably already running Linux Binary > Compat anyway... I've found wine + firefox + flash to work for everything I've tried so far (youtube, various websites with flash ads, one or two flash-only sites.) It did crash on me once, but I'm not sure it was related to flash. Wine is pretty good, but not perfect. If all you need is to visit flash sites, it's a decent workaround in the mean time. Also, I was very surprised how easy it was to set up (not having used wine before.) -Mark C. P.S. That's some ugly cross-posting you've started there... From yanefbsd at gmail.com Tue Jun 24 17:40:29 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Tue Jun 24 17:40:33 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <1214322926.1505.65.camel@scotth.emsphone.com> References: <20080619135114.Y1807@kozubik.com> <20080620083906.71332251xw1ckmu8@webmail.leidinger.net> <1213972236.1505.14.camel@scotth.emsphone.com> <20080624083829.T1807@kozubik.com> <1214322926.1505.65.camel@scotth.emsphone.com> Message-ID: <7d6fde3d0806241040x6ed9dea6y79d2c2d62ff1b30f@mail.gmail.com> On Tue, Jun 24, 2008 at 8:55 AM, Scott T. Hildreth wrote: > > On Tue, 2008-06-24 at 08:41 -0700, John Kozubik wrote: >> >> On Fri, 20 Jun 2008, Scott T. Hildreth wrote: >> >> > >> > >> > On Fri, 2008-06-20 at 08:39 +0200, Alexander Leidinger wrote: >> > > Quoting John Kozubik (from Thu, 19 Jun 2008 >> > > 14:38:11 -0700 (PDT)): >> > > >> > > > First, a bounty has been posted here: >> > > > >> > > > http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html >> > > > >> > > >> > >> > Maybe the bounty would be better spent here, >> > >> > This was from an email on the gnome list from Joe Marcus Clarke >> > >> > "As to the point about Flash, Kris also mentioned that he has the ear of >> > someone at Adobe who was hinting that a capable developer willing to >> > sign an NDA could be given code to work on a native Flash plug-in port. >> > This could bode well for PC-BSD and FreeBSD should someone step up to >> > do this work." >> >> >> Perfect. This is exactly what the bounty: >> >> http://blog.kozubik.com/john_kozubik/2007/12/bounty-posted-f.html >> >> is for. I suggest that if you think this is important (as I do) to post a >> commitment to the bounty, and presumably someone will step forward to >> speak with Kris, sign an NDA, and get the FreeBSD desktop back to a >> reasonable level of utility. > > I wonder how much of a task it would be? Does anyone have any idea what > language the clients are written in? Look into Spidermonkey for more details: http://www.mozilla.org/js/spidermonkey/ It was designed to be the bridge between ActiveScript and Mozilla, allowing the Adobe folks to code Flash in terms of ActiveScript, instead of completely in C, thus making things more portable. I offered to work with the Mozilla group to get ActiveScript ported over to FreeBSD but I haven't received a reply in a year of having posted my "bug report". (not designed to be troll-bait, just my personal opinion on the matter -- don't comment on it please) FWIW, Personally I don't think that Flash support is as critical as getting working x64 compatible OpenGL enabled video drivers, but then again my opinion differs from your's most likely. -Garrett From jhs at berklix.org Tue Jun 24 18:17:43 2008 From: jhs at berklix.org (Julian Stacey) Date: Tue Jun 24 18:17:47 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: Your message "Tue, 24 Jun 2008 11:03:08 MDT." Message-ID: <200806241817.m5OIHLYU086621@fire.js.berklix.net> "Mark Carlson" wrote: > On 6/19/08, John Kozubik wrote: ..... Elided ... > > [1] Since we're all probably already running Linux Binary > > Compat anyway... > > I've found wine + firefox + flash to work for everything I've tried so Do you have a "How To" RTFM Cook book / script URL please ? > -Mark C. > > P.S. That's some ugly cross-posting you've started there... Agreed. IMO Not conformant with freebsd.org cross posting guidelines. I dropped a list + various individuals inc. original John "Don't shoot the messenger" Kozubik, as I don't want his system's auto responder challengin me again. Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From cyberbotx at cyberbotx.com Tue Jun 24 18:46:49 2008 From: cyberbotx at cyberbotx.com (Naram Qashat) Date: Tue Jun 24 18:46:56 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <200806241817.m5OIHLYU086621@fire.js.berklix.net> References: <200806241817.m5OIHLYU086621@fire.js.berklix.net> Message-ID: <48613EBA.507@cyberbotx.com> Julian Stacey wrote: > "Mark Carlson" wrote: >> On 6/19/08, John Kozubik wrote: > ..... Elided ... >>> [1] Since we're all probably already running Linux Binary >>> Compat anyway... >> I've found wine + firefox + flash to work for everything I've tried so > > Do you have a "How To" RTFM Cook book / script URL please ? I'd like to chime in here and say there is nothing special to get this configuration to work. Download the Windows version of Firefox and install it via Wine, then download the Windows version of Flash for Firefox and install that with Wine. Once you do that, you have Flash in Firefox using Wine. Like has been said, Wine is far from perfect, but this works great until a native Flash can be made for FreeBSD. Naram Qashat > >> -Mark C. >> >> P.S. That's some ugly cross-posting you've started there... > > Agreed. IMO Not conformant with freebsd.org cross posting guidelines. > I dropped a list + various individuals inc. original John "Don't > shoot the messenger" Kozubik, as I don't want his system's > auto responder challengin me again. > > Julian From carlsonmark at gmail.com Tue Jun 24 19:41:08 2008 From: carlsonmark at gmail.com (Mark Carlson) Date: Tue Jun 24 19:41:12 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <48613EBA.507@cyberbotx.com> References: <200806241817.m5OIHLYU086621@fire.js.berklix.net> <48613EBA.507@cyberbotx.com> Message-ID: On 6/24/08, Naram Qashat wrote: > Julian Stacey wrote: > > Do you have a "How To" RTFM Cook book / script URL please ? > > > > I'd like to chime in here and say there is nothing special to get this > configuration to work. Download the Windows version of Firefox and install > it via Wine, then download the Windows version of Flash for Firefox and > install that with Wine. Once you do that, you have Flash in Firefox using > Wine. Like has been said, Wine is far from perfect, but this works great > until a native Flash can be made for FreeBSD. > > Naram Qashat I'm not at my box right now, but it went something like this: 0. Install wine ( emulators/wine ) 1. Download firefox for windows ( http://www.mozilla.com/en-US/firefox/all.html ) 2. Run: wine "Firefox Setup 3.0.exe" 3. Complete the installer 4. To run firefox you need to do something like: wine "C:/Program Files/Mozilla Firefox/firefox.exe" (I forget the exact path / command name) 5. Navigate to the adobe flash download page ( use goole or something ) and download the flash installer for windows. 6. When the download is complete, run it ( should be able to do this from the download manager in firefox ) 7. Complete the flash installer ( this will require you to close firefox, so do that ) 8. Start firefox again (see the wine firefox.exe command from above) 9. Create a script to start firefox under wine since the command is so ugly. I might write up some better instructions when I have the time, but I really don't have a good place to put them. -Mark C. From gabor at FreeBSD.org Tue Jun 24 20:32:21 2008 From: gabor at FreeBSD.org (Gabor Kovesdan) Date: Tue Jun 24 20:32:30 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <20080622135343.GA72068@nagual.pp.ru> References: <20080617102900.GA46479@nagual.pp.ru> <485798C4.2050605@FreeBSD.org> <20080618055851.GA85018@nagual.pp.ru> <86zlpjduew.fsf@ds4.des.no> <20080618083739.GA87100@nagual.pp.ru> <867icndqv5.fsf@ds4.des.no> <4858DBF6.5070001@bluemedia.pl> <86skvbc9gn.fsf@ds4.des.no> <20080618114917.GB89383@nagual.pp.ru> <485E4C69.1080805@FreeBSD.org> <20080622135343.GA72068@nagual.pp.ru> Message-ID: <486159D1.3060704@FreeBSD.org> > > 1) You can't convert just whole buffer after fread() since it can be > ended in the middle of multibyte sequence on BUFSIZ edge. Look how GNU > utils do it. > OK, now I haven't thought of this aspect. What about this? #define iswbinary(ch) (!iswspace((ch)) && iswcntrl((ch))) int bin_file(FILE *f) { wint_t ch = L'\0'; size_t i; int ret = 0; if (fseek(f, 0L, SEEK_SET) == -1) return (0); for (i = 0; (i <= BUFSIZ) && (ch != WEOF); i++) { ch = fgetwc(f); if (iswbinary(ch)) { ret = 1; break; } } rewind(f); return (ret); } int mmbin_file(struct mmfile *f) { int i; wchar_t *wbuf; size_t s; if ((s = mbstowcs(NULL, f->base, 0)) == -1) return (0); wbuf = grep_malloc((s + 1) * sizeof(wchar_t)); if (mbstowcs(wbuf, f->base, s) == -1) return (0); /* XXX knows too much about mmf internals */ for (i = 0; i < BUFSIZ && i < f->len; i++) if (iswbinary(wbuf[i])) { free(wbuf); return (1); } free(wbuf); return (0); } This should be ok, right? > 2) Better use iswspace and iswcntrl instead of iswctype. > Ok, changed, thanks. I've also been looking for such functions, but man wctype doesn't mention them. > 3) util.c needs to be fixed in several places too. > Yes, I know, I'm just advancing step by step. The next item will be to fix that word boundary handling. Regards, Gabor From ache at nagual.pp.ru Tue Jun 24 21:04:24 2008 From: ache at nagual.pp.ru (Andrey Chernov) Date: Tue Jun 24 21:09:59 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <486159D1.3060704@FreeBSD.org> References: <20080618055851.GA85018@nagual.pp.ru> <86zlpjduew.fsf@ds4.des.no> <20080618083739.GA87100@nagual.pp.ru> <867icndqv5.fsf@ds4.des.no> <4858DBF6.5070001@bluemedia.pl> <86skvbc9gn.fsf@ds4.des.no> <20080618114917.GB89383@nagual.pp.ru> <485E4C69.1080805@FreeBSD.org> <20080622135343.GA72068@nagual.pp.ru> <486159D1.3060704@FreeBSD.org> Message-ID: <20080624210420.GA43007@nagual.pp.ru> On Tue, Jun 24, 2008 at 10:32:17PM +0200, Gabor Kovesdan wrote: > ch = fgetwc(f); You must clear errno before and handle EILSEQ possible coming after fgetwc() somehow. Perhaps by return ret = 1 (binary), I am not sure. fgetwc() returns WEOF in that case which is not true end of file. > if ((s = mbstowcs(NULL, f->base, 0)) == -1) > return (0); The same here. Check EILSEQ and return 1 -- http://ache.pp.ru/ From ache at nagual.pp.ru Tue Jun 24 21:30:22 2008 From: ache at nagual.pp.ru (Andrey Chernov) Date: Tue Jun 24 21:36:18 2008 Subject: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] In-Reply-To: <20080624210420.GA43007@nagual.pp.ru> References: <86zlpjduew.fsf@ds4.des.no> <20080618083739.GA87100@nagual.pp.ru> <867icndqv5.fsf@ds4.des.no> <4858DBF6.5070001@bluemedia.pl> <86skvbc9gn.fsf@ds4.des.no> <20080618114917.GB89383@nagual.pp.ru> <485E4C69.1080805@FreeBSD.org> <20080622135343.GA72068@nagual.pp.ru> <486159D1.3060704@FreeBSD.org> <20080624210420.GA43007@nagual.pp.ru> Message-ID: <20080624213018.GA71334@nagual.pp.ru> On Wed, Jun 25, 2008 at 01:04:20AM +0400, Andrey Chernov wrote: > > if ((s = mbstowcs(NULL, f->base, 0)) == -1) > > return (0); > > The same here. Check EILSEQ and return 1 BTW, do you realyze that this code malloc()s _whole_file_ into memory (which not fits for very big files)? Non-localized old code use mmap, so don't actually malloc() it. Doe to that perhaps whole mmfile.c should be not used and removed. -- http://ache.pp.ru/ From jhb at freebsd.org Tue Jun 24 21:53:51 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Jun 24 21:53:56 2008 Subject: FreeBSD 6.3 deadlock (vm_map?) with DDB output In-Reply-To: <485FF698.103@gritton.org> References: <20080615112318.146C1F18512@mx.npubs.com> <200806231451.52340.jhb@freebsd.org> <485FF698.103@gritton.org> Message-ID: <200806241555.48280.jhb@freebsd.org> On Monday 23 June 2008 03:16:40 pm James Gritton wrote: > John Baldwin wrote: > > On Thursday 19 June 2008 11:57:51 am James Gritton wrote: > > > >> John Baldwin wrote: > >> > >>> On Sunday 15 June 2008 07:23:19 am Stef Walter wrote: > >>> > >>> > >>>> I've been trying to track down a deadlock on some newish production > >>>> servers running FreeBSD 6.3-RELEASE-p2. The deadlock occurs on a > >>>> specific (although mundane) hardware configuration, and each of several > >>>> servers running this hardware deadlock about once per week. > >>>> > >>>> Although I suspect that this is not hardware related, from a (naive) > >>>> perusal of the attached stack traces. > >>>> > >>>> Forgive me if my interpretation of this is all wrong, but I'm pretty > >>>> desperate for help. So here's my basic understanding of the deadlock: > >>>> > >>>> These processes seem to be waiting on the page queue mutex: > >>>> sendmail (in vm_mmap > vm_map_find > vm_map_insert > vm_map_pmap_enter) > >>>> bsnmpd (in malloc, uma_large_malloc > page_alloc > kmem_malloc) > >>>> httpd (in trap > trap_pfault > vm_fault) > >>>> [g_up] (in g_vfs_done > bufdone) > >>>> > >>>> The page queue mutex is held by rsync process: > >>>> rsync (in trap > trap_pfault > vm_fault > pmap_enter) > >>>> > >>>> Rsync kernel process (in pmap_enter) was interrupted while holding the > >>>> page queue lock? > >>>> > >>>> > >>>> Giant is enabled in loader.conf due to the needs of the pf firewall when > >>>> dealing with user credentials lookups. I do not believe that Giant plays > >>>> into this deadlock. Kernel config attached. > >>>> > >>>> Any and all help or info is welcome. Thanks in advance. > >>>> > >>>> > >>> Try this change: > >>> > >>> jhb 2007-10-27 22:07:40 UTC > >>> > >>> FreeBSD src repository > >>> > >>> Modified files: > >>> sys/kern sched_4bsd.c > >>> Log: > >>> Change the roundrobin implementation in the 4BSD scheduler to trigger a > >>> userland preemption directly from hardclock() via sched_clock() when a > >>> thread uses up a full quantum instead of using a periodic timeout to > >>> > > cause > > > >>> a userland preemption every so often. This fixes a potential deadlock > >>> when IPI_PREEMPTION isn't enabled where softclock blocks on a lock held > >>> by a thread pinned or bound to another CPU. The current thread on that > >>> CPU will never be preempted while softclock is blocked. > >>> > >>> Note that ULE already drives its round-robin userland preemption from > >>> sched_clock() as well and always enables IPI_PREEMPT. > >>> > >>> MFC after: 1 week > >>> > >>> Revision Changes Path > >>> 1.108 +8 -29 src/sys/kern/sched_4bsd.c > >>> > >>> We use it at work on 6.x. W/o this fix, round-robin stops working on 4BSD > >>> when softclock() (swi4: clock) blocks on a lock like Giant. > >>> > >>> > >> I've been seeing similar troubles on 6.2 and I'll have to give this a > >> try as we upgrade to 6.3. I notice "MFC after: 1 week" in the log; it's > >> been a week - any chance of seeing this fix rolled into 6.x? > >> > > > > If people confirm it fixes issues I will MFC it. There was some pushback when > > I first committed it so I waited on the MFC. > > I can confirm that on 6.3 I can recreate the deadlock without the patch, > and can't recreate it with the patch. Ok, I've merged it to RELENG_[67]. -- John Baldwin From mwm-keyword-freebsdhackers2.e313df at mired.org Tue Jun 24 22:18:29 2008 From: mwm-keyword-freebsdhackers2.e313df at mired.org (Mike Meyer) Date: Tue Jun 24 22:18:32 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <48613EBA.507@cyberbotx.com> References: <200806241817.m5OIHLYU086621@fire.js.berklix.net> <48613EBA.507@cyberbotx.com> Message-ID: <20080624181754.6af765d8@bhuda.mired.org> On Tue, 24 Jun 2008 14:36:42 -0400 Naram Qashat wrote: > Julian Stacey wrote: > > "Mark Carlson" wrote: > >> On 6/19/08, John Kozubik wrote: > > ..... Elided ... > >>> [1] Since we're all probably already running Linux Binary > >>> Compat anyway... > >> I've found wine + firefox + flash to work for everything I've tried so > > > > Do you have a "How To" RTFM Cook book / script URL please ? > > I'd like to chime in here and say there is nothing special to get this > configuration to work. Download the Windows version of Firefox and install it > via Wine, then download the Windows version of Flash for Firefox and install > that with Wine. Once you do that, you have Flash in Firefox using Wine. Like > has been said, Wine is far from perfect, but this works great until a native > Flash can be made for FreeBSD. Not only that, but you've restricted Flash's access to your Wine environment. Give that it - by design - loads and executes code from unknown and hence untrustworthy individuals, this is a good thing in and of itself. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From thierry at herbelot.com Tue Jun 24 22:27:58 2008 From: thierry at herbelot.com (Thierry Herbelot) Date: Tue Jun 24 22:33:42 2008 Subject: 3D for AMD64 (was Re: Lack of Flash support is no longer acceptable. Bounty established...) In-Reply-To: <7d6fde3d0806241040x6ed9dea6y79d2c2d62ff1b30f@mail.gmail.com> References: <20080619135114.Y1807@kozubik.com> <1214322926.1505.65.camel@scotth.emsphone.com> <7d6fde3d0806241040x6ed9dea6y79d2c2d62ff1b30f@mail.gmail.com> Message-ID: <200806250006.06789.thierry@herbelot.com> [CC trimmed] Le Tuesday 24 June 2008, Garrett Cooper a ?crit : > On Tue, Jun 24, 2008 at 8:55 AM, Scott T. Hildreth > [SNIP] > > (not designed to be troll-bait, just my personal opinion on the matter > -- don't comment on it please) FWIW, Personally I don't think that > Flash support is as critical as getting working x64 compatible OpenGL > enabled video drivers, but then again my opinion differs from your's > most likely. is there any hope for having the newly open-sourced radeon/radeon-hd AMD drivers (and the related 3D acceleration) to work under FreeBSD-AMD64 ? TfH From lx at FreeBSD.org Tue Jun 24 22:56:14 2008 From: lx at FreeBSD.org (David E. Thiel) Date: Tue Jun 24 22:56:18 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: References: <200806241817.m5OIHLYU086621@fire.js.berklix.net> <48613EBA.507@cyberbotx.com> Message-ID: <20080624225613.GA70561@redundancy.redundancy.org> On Tue, Jun 24, 2008 at 01:40:44PM -0600, Mark Carlson wrote: > 0. Install wine ( emulators/wine ) > 1. Download firefox for windows ( > http://www.mozilla.com/en-US/firefox/all.html ) > 2. Run: wine "Firefox Setup 3.0.exe" > 3. Complete the installer > 4. To run firefox you need to do something like: wine "C:/Program > Files/Mozilla Firefox/firefox.exe" (I forget the exact path / command > name) > 5. Navigate to the adobe flash download page ( use goole or something > ) and download the flash installer for windows. > 6. When the download is complete, run it ( should be able to do this > from the download manager in firefox ) > 7. Complete the flash installer ( this will require you to close > firefox, so do that ) > 8. Start firefox again (see the wine firefox.exe command from above) > 9. Create a script to start firefox under wine since the command is so ugly. This works surprisingly well. One note - you may want to undefine LC_CTYPE if you have it set to a non-standard value, as FF seems to crash otherwise. From alex-goncharov at comcast.net Wed Jun 25 02:31:43 2008 From: alex-goncharov at comcast.net (Alex Goncharov) Date: Wed Jun 25 02:31:48 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: (carlsonmark@gmail.com) References: <200806241817.m5OIHLYU086621@fire.js.berklix.net> <48613EBA.507@cyberbotx.com> Message-ID: ,--- You/Mark (Tue, 24 Jun 2008 13:41:07 -0600) ----* | I'm not at my box right now, but it went something like this: | ... | I might write up some better instructions when I have the time, but | I really don't have a good place to put them. `---------------------------------------------------* The instructions you've given are quite adequate and VERY helpful: I've never used Wine, and didn't imagine I could resolve the Flash pains so quickly and cheaply. ,--- David E. Thiel (Tue, 24 Jun 2008 15:56:14 -0700) ----* | This works surprisingly well. One note - you may want to undefine | LC_CTYPE if you have it set to a non-standard value, as FF seems to | crash otherwise. `---------------------------------------------------------* I should add that I am now running Windows Opera on my FreeBSD 7.0 system -- and here, too, everything works surprisingly well, although the non-native character of the browser can't be not noticed, and the fonts' looks are much inferior to the ones in `linux-opera'. Thank you very much for the valuable advice! -- Alex -- alex-goncharov@comcast.net -- /* * To invent, you need a good imagination and a pile of junk. * * -- Thomas Edison */ From artis.caune at gmail.com Wed Jun 25 08:46:11 2008 From: artis.caune at gmail.com (Artis Caune) Date: Wed Jun 25 08:46:14 2008 Subject: build stamps Message-ID: <9e20d71e0806250121i33bbdf07y2a5ce910e79a7b57@mail.gmail.com> If you are making world or release twice from one source, you will get some binaries and lot of libraries which differ because of time stamps: # make buildworld # make installworld DESTDIR=/home/build1 # rm -r /usr/obj/usr # make buildworld # make installworld DESTDIR=/home/build2 # diff -r /home/build1 /home/build2 freebsd-update-server also make world twice to find out where those build stamps are. I tried to freeze clock on build box while repeating build process: # while true; do date -n 0000; sleep 0.5; done and there were no differences between two builds. Is there any harm if I build releases with frozen clock? or maybe load kld module which replace gettimeofday syscall at build time? thanks, Artis From ticso at cicely7.cicely.de Wed Jun 25 09:07:11 2008 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Wed Jun 25 09:07:13 2008 Subject: Looking for *cheap* embedded platform w- 2 ethernets In-Reply-To: <20080622122406.59e65588@peedub.jennejohn.org> References: <7A966B3C-044F-4794-949B-F92B60E8F674@via.net> <20080622095827.GF29053@cicely7.cicely.de> <20080622122406.59e65588@peedub.jennejohn.org> Message-ID: <20080625090659.GF40860@cicely7.cicely.de> On Sun, Jun 22, 2008 at 12:24:06PM +0200, Gary Jennejohn wrote: > On Sun, 22 Jun 2008 11:58:32 +0200 > Bernd Walter wrote: > > > On Fri, Jun 20, 2008 at 08:07:46PM -0700, joe mcguckin wrote: > > > I'm looking for a cheap and small embedded platform to use as a > > > portable vpn endpoint. It doesn't have to be fast, it just has to > > > run *BSD. > > > > > > Any suggestions?? > > > > We build our own ARM9 based board: > > http://www.small-control.de/FSB-A920-1.html > > http://www.small-control.de/FSB-A920-1-APG.html > > > > Looks like it's soldered by hand. Is it? Yes it is. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From stefan.lambrev at moneybookers.com Wed Jun 25 09:10:08 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Wed Jun 25 09:10:11 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: References: <200806241817.m5OIHLYU086621@fire.js.berklix.net> <48613EBA.507@cyberbotx.com> Message-ID: <4862074E.1000704@moneybookers.com> Greetings, Mark Carlson wrote: > On 6/24/08, Naram Qashat wrote: > >> Julian Stacey wrote: >> >>> Do you have a "How To" RTFM Cook book / script URL please ? >>> >>> >> I'd like to chime in here and say there is nothing special to get this >> configuration to work. Download the Windows version of Firefox and install >> it via Wine, then download the Windows version of Flash for Firefox and >> install that with Wine. Once you do that, you have Flash in Firefox using >> Wine. Like has been said, Wine is far from perfect, but this works great >> until a native Flash can be made for FreeBSD. >> >> Naram Qashat >> > > I'm not at my box right now, but it went something like this: > > 0. Install wine ( emulators/wine ) > 1. Download firefox for windows ( > http://www.mozilla.com/en-US/firefox/all.html ) > 2. Run: wine "Firefox Setup 3.0.exe" > 3. Complete the installer > 4. To run firefox you need to do something like: wine "C:/Program > Files/Mozilla Firefox/firefox.exe" (I forget the exact path / command > name) > 5. Navigate to the adobe flash download page ( use goole or something > ) and download the flash installer for windows. > 6. When the download is complete, run it ( should be able to do this > from the download manager in firefox ) > 7. Complete the flash installer ( this will require you to close > firefox, so do that ) > 8. Start firefox again (see the wine firefox.exe command from above) > 9. Create a script to start firefox under wine since the command is so ugly. > > I might write up some better instructions when I have the time, but I > really don't have a good place to put them. > I tried this before and have a bad luck of not having working audio on flash, but today with new wine and FF3 it works. Btw there is a small nasty problem copy/paste from wine app to native apps does not work. Ideas how to workaround this? > -Mark C. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From thavinci at thavinci.za.net Wed Jun 25 12:01:36 2008 From: thavinci at thavinci.za.net (Marcel Grandemange) Date: Wed Jun 25 12:05:25 2008 Subject: Looking for *cheap* embedded platform w- 2 ethernets In-Reply-To: <20080625090659.GF40860@cicely7.cicely.de> References: <7A966B3C-044F-4794-949B-F92B60E8F674@via.net> <20080622095827.GF29053@cicely7.cicely.de> <20080622122406.59e65588@peedub.jennejohn.org> <20080625090659.GF40860@cicely7.cicely.de> Message-ID: <003801c8d6b8$be5a13c0$3b0e3b40$@za.net> http://www.routerboard.com/ Theres my suggestion. -----Original Message----- From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of Bernd Walter Sent: Wednesday, June 25, 2008 11:07 AM To: Gary Jennejohn Cc: freebsd-hackers@freebsd.org Subject: Re: Looking for *cheap* embedded platform w- 2 ethernets On Sun, Jun 22, 2008 at 12:24:06PM +0200, Gary Jennejohn wrote: > On Sun, 22 Jun 2008 11:58:32 +0200 > Bernd Walter wrote: > > > On Fri, Jun 20, 2008 at 08:07:46PM -0700, joe mcguckin wrote: > > > I'm looking for a cheap and small embedded platform to use as a > > > portable vpn endpoint. It doesn't have to be fast, it just has to > > > run *BSD. > > > > > > Any suggestions?? > > > > We build our own ARM9 based board: > > http://www.small-control.de/FSB-A920-1.html > > http://www.small-control.de/FSB-A920-1-APG.html > > > > Looks like it's soldered by hand. Is it? Yes it is. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" __________ NOD32 3205 (20080621) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com From koitsu at FreeBSD.org Wed Jun 25 12:37:33 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Jun 25 12:37:37 2008 Subject: Looking for *cheap* embedded platform w- 2 ethernets In-Reply-To: <003801c8d6b8$be5a13c0$3b0e3b40$@za.net> References: <7A966B3C-044F-4794-949B-F92B60E8F674@via.net> <20080622095827.GF29053@cicely7.cicely.de> <20080622122406.59e65588@peedub.jennejohn.org> <20080625090659.GF40860@cicely7.cicely.de> <003801c8d6b8$be5a13c0$3b0e3b40$@za.net> Message-ID: <20080625123732.GA28561@eos.sc1.parodius.com> On Wed, Jun 25, 2008 at 01:43:52PM +0200, Marcel Grandemange wrote: > http://www.routerboard.com/ > > Theres my suggestion. Those are really, *really* nice. It's about time such vendors started using gigE PHY/NICs; it's the main reason why I don't invest in devices like these. The RB/1000 is quite awesome. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From thavinci at thavinci.za.net Wed Jun 25 13:10:57 2008 From: thavinci at thavinci.za.net (Marcel Grandemange) Date: Wed Jun 25 13:19:32 2008 Subject: Looking for *cheap* embedded platform w- 2 ethernets In-Reply-To: <20080625123732.GA28561@eos.sc1.parodius.com> References: <7A966B3C-044F-4794-949B-F92B60E8F674@via.net> <20080622095827.GF29053@cicely7.cicely.de> <20080622122406.59e65588@peedub.jennejohn.org> <20080625090659.GF40860@cicely7.cicely.de> <003801c8d6b8$be5a13c0$3b0e3b40$@za.net> <20080625123732.GA28561@eos.sc1.parodius.com> Message-ID: <003c01c8d6c4$d007b800$70172800$@za.net> http://www.mikrotik.com/ , That's the software they normally use on these boards, linux based with client software to configure it, very easy and EXTREMELY easy to do full VPN client/server, full OSPF/RIP/BGP, well pretty much anything network related. I agree on the gigabit statement although interface bonding will have to do for now. -----Original Message----- From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of Jeremy Chadwick Sent: Wednesday, June 25, 2008 2:38 PM To: Marcel Grandemange Cc: freebsd-hackers@freebsd.org; ticso@cicely.de Subject: Re: Looking for *cheap* embedded platform w- 2 ethernets On Wed, Jun 25, 2008 at 01:43:52PM +0200, Marcel Grandemange wrote: > http://www.routerboard.com/ > > Theres my suggestion. Those are really, *really* nice. It's about time such vendors started using gigE PHY/NICs; it's the main reason why I don't invest in devices like these. The RB/1000 is quite awesome. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" __________ NOD32 3205 (20080621) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com From fernando.apesteguia at gmail.com Wed Jun 25 15:27:49 2008 From: fernando.apesteguia at gmail.com (=?ISO-8859-1?Q?Fernando_Apestegu=EDa?=) Date: Wed Jun 25 15:27:55 2008 Subject: Can't load firmware Message-ID: <1bd550a00806250827ga4607b2g412d3e7c673f71cb@mail.gmail.com> Hi all, I'm facing some problems with my IPW2200 NIC. It seems I can't load the firmware (from system log): firmware_get: failed to load firmware image iwi_bss Both if_ipw and ipw_bss modules are loaded. This very same computer works fine with linux, including loading the firmware. I post this question here cause I didn't get any answer in the freebsd-questions@ list and because I read in the iwi man page that this shouldn't happen :). Any help is appreciated. Thanks in advance. From thompsa at FreeBSD.org Wed Jun 25 16:17:55 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Wed Jun 25 16:18:00 2008 Subject: Can't load firmware In-Reply-To: <1bd550a00806250827ga4607b2g412d3e7c673f71cb@mail.gmail.com> References: <1bd550a00806250827ga4607b2g412d3e7c673f71cb@mail.gmail.com> Message-ID: <20080625155617.GB98532@citylink.fud.org.nz> On Wed, Jun 25, 2008 at 05:27:47PM +0200, Fernando Apestegu?a wrote: > Hi all, > > I'm facing some problems with my IPW2200 NIC. It seems I can't load > the firmware (from system log): > > firmware_get: failed to load firmware image iwi_bss > > Both if_ipw and ipw_bss modules are loaded. > > This very same computer works fine with linux, including loading the firmware. Have you set legal.intel_iwi.license_ack=1 in /boot/loader.conf? Andrew From fernando.apesteguia at gmail.com Wed Jun 25 17:10:41 2008 From: fernando.apesteguia at gmail.com (=?ISO-8859-1?Q?Fernando_Apestegu=EDa?=) Date: Wed Jun 25 17:10:45 2008 Subject: Can't load firmware In-Reply-To: <20080625155617.GB98532@citylink.fud.org.nz> References: <1bd550a00806250827ga4607b2g412d3e7c673f71cb@mail.gmail.com> <20080625155617.GB98532@citylink.fud.org.nz> Message-ID: <1bd550a00806251010w40a32967gf3d7cb6a8c876dc3@mail.gmail.com> On Wed, Jun 25, 2008 at 5:56 PM, Andrew Thompson wrote: > On Wed, Jun 25, 2008 at 05:27:47PM +0200, Fernando Apestegu?a wrote: >> Hi all, >> >> I'm facing some problems with my IPW2200 NIC. It seems I can't load >> the firmware (from system log): >> >> firmware_get: failed to load firmware image iwi_bss >> >> Both if_ipw and ipw_bss modules are loaded. >> >> This very same computer works fine with linux, including loading the firmware. > > Have you set legal.intel_iwi.license_ack=1 in /boot/loader.conf? No. I'm aware of the iwi man page, but after I did that I got a message in /var/log/messages complaining about the legal.intel_ipw.license_ack variable, not the one specified in the iwi man page. I set the last one to 1 but I got the firmware loading problem. If this has changed, I suppose it should be fixed in the documentation IMHO. Any more ideas? Any debugging hints? Thanks in advance > > > Andrew > From fernando.apesteguia at gmail.com Wed Jun 25 17:11:26 2008 From: fernando.apesteguia at gmail.com (=?ISO-8859-1?Q?Fernando_Apestegu=EDa?=) Date: Wed Jun 25 17:11:29 2008 Subject: Can't load firmware In-Reply-To: <1bd550a00806251010w40a32967gf3d7cb6a8c876dc3@mail.gmail.com> References: <1bd550a00806250827ga4607b2g412d3e7c673f71cb@mail.gmail.com> <20080625155617.GB98532@citylink.fud.org.nz> <1bd550a00806251010w40a32967gf3d7cb6a8c876dc3@mail.gmail.com> Message-ID: <1bd550a00806251011j15a98818ke2c688ddc7f6d9ce@mail.gmail.com> On Wed, Jun 25, 2008 at 7:10 PM, Fernando Apestegu?a wrote: > On Wed, Jun 25, 2008 at 5:56 PM, Andrew Thompson wrote: >> On Wed, Jun 25, 2008 at 05:27:47PM +0200, Fernando Apestegu?a wrote: >>> Hi all, >>> >>> I'm facing some problems with my IPW2200 NIC. It seems I can't load >>> the firmware (from system log): >>> >>> firmware_get: failed to load firmware image iwi_bss >>> >>> Both if_ipw and ipw_bss modules are loaded. >>> >>> This very same computer works fine with linux, including loading the firmware. >> >> Have you set legal.intel_iwi.license_ack=1 in /boot/loader.conf? > > No. I'm aware of the iwi man page, but after I did that I got a > message in /var/log/messages complaining about the > legal.intel_ipw.license_ack variable, not the one specified in the iwi > man page. > > I set the last one to 1 but I got the firmware loading problem. If > this has changed, I suppose it should be fixed in the documentation > IMHO. > > Any more ideas? Any debugging hints? > > Thanks in advance Oops, sorry I forgot: I'm using 7.0 RELEASE. Thanks > >> >> >> Andrew >> > From minimarmot at gmail.com Wed Jun 25 17:27:04 2008 From: minimarmot at gmail.com (Ben Kaduk) Date: Wed Jun 25 17:27:29 2008 Subject: 3D for AMD64 (was Re: Lack of Flash support is no longer acceptable. Bounty established...) In-Reply-To: <200806250006.06789.thierry@herbelot.com> References: <20080619135114.Y1807@kozubik.com> <1214322926.1505.65.camel@scotth.emsphone.com> <7d6fde3d0806241040x6ed9dea6y79d2c2d62ff1b30f@mail.gmail.com> <200806250006.06789.thierry@herbelot.com> Message-ID: <47d0403c0806251000q66162234nac5c0b1f7bf9b64c@mail.gmail.com> On Tue, Jun 24, 2008 at 6:06 PM, Thierry Herbelot wrote: > > is there any hope for having the newly open-sourced radeon/radeon-hd AMD > drivers (and the related 3D acceleration) to work under FreeBSD-AMD64 ? > Well, I'm using radeonhd right now on a [kaduk@periphrasis /usr/src/sys/contrib/dev/ath/public]$ uname -a FreeBSD periphrasis.mit.edu 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed May 14 00:27:26 EDT 2008 root@periphrasis.mit.edu:/usr/obj/usr/src/sys/PERIPHRASIS amd64 I don't think I have anything that uses 3d installed at the moment, but the 2d seems like it's getting accelerated (non-accelerated dual-monitors can be painfully slow). -Ben Kaduk From thierry at herbelot.com Wed Jun 25 17:59:32 2008 From: thierry at herbelot.com (Thierry Herbelot) Date: Wed Jun 25 18:09:32 2008 Subject: 3D for AMD64 (was Re: Lack of Flash support is no longer acceptable. Bounty established...) In-Reply-To: <47d0403c0806251000q66162234nac5c0b1f7bf9b64c@mail.gmail.com> References: <20080619135114.Y1807@kozubik.com> <200806250006.06789.thierry@herbelot.com> <47d0403c0806251000q66162234nac5c0b1f7bf9b64c@mail.gmail.com> Message-ID: <200806251959.16817.thierry@herbelot.com> Le Wednesday 25 June 2008, Ben Kaduk a ?crit : > On Tue, Jun 24, 2008 at 6:06 PM, Thierry Herbelot wrote: > > is there any hope for having the newly open-sourced radeon/radeon-hd AMD > > drivers (and the related 3D acceleration) to work under FreeBSD-AMD64 ? > > Well, I'm using radeonhd right now on a > [kaduk@periphrasis /usr/src/sys/contrib/dev/ath/public]$ uname -a > FreeBSD periphrasis.mit.edu 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed May > 14 00:27:26 EDT 2008 > root@periphrasis.mit.edu:/usr/obj/usr/src/sys/PERIPHRASIS amd64 good news ! > > I don't think I have anything that uses 3d installed at the moment, but > the 2d seems like it's getting accelerated (non-accelerated dual-monitors > can be painfully slow). what are the details for your machine ? (graphics board make, motherboard chipset etc) I was thinking of buying a new machine with AMD 780G or 790GX chipsets, whose integrated graphics board is supposed to be driven by radeonhd. TfH From minimarmot at gmail.com Wed Jun 25 19:09:45 2008 From: minimarmot at gmail.com (Ben Kaduk) Date: Wed Jun 25 19:09:49 2008 Subject: 3D for AMD64 (was Re: Lack of Flash support is no longer acceptable. Bounty established...) In-Reply-To: <200806251959.16817.thierry@herbelot.com> References: <20080619135114.Y1807@kozubik.com> <200806250006.06789.thierry@herbelot.com> <47d0403c0806251000q66162234nac5c0b1f7bf9b64c@mail.gmail.com> <200806251959.16817.thierry@herbelot.com> Message-ID: <47d0403c0806251209t2065e2b7o8f71606378d55e65@mail.gmail.com> On Wed, Jun 25, 2008 at 1:59 PM, Thierry Herbelot wrote: > Le Wednesday 25 June 2008, Ben Kaduk a ?crit : >> On Tue, Jun 24, 2008 at 6:06 PM, Thierry Herbelot > wrote: >> > is there any hope for having the newly open-sourced radeon/radeon-hd AMD >> > drivers (and the related 3D acceleration) to work under FreeBSD-AMD64 ? >> >> Well, I'm using radeonhd right now on a >> [kaduk@periphrasis /usr/src/sys/contrib/dev/ath/public]$ uname -a >> FreeBSD periphrasis.mit.edu 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed May >> 14 00:27:26 EDT 2008 >> root@periphrasis.mit.edu:/usr/obj/usr/src/sys/PERIPHRASIS amd64 > > good news ! >> >> I don't think I have anything that uses 3d installed at the moment, but >> the 2d seems like it's getting accelerated (non-accelerated dual-monitors >> can be painfully slow). > > what are the details for your machine ? (graphics board make, motherboard > chipset etc) > > I was thinking of buying a new machine with AMD 780G or 790GX chipsets, whose > integrated graphics board is supposed to be driven by radeonhd. > There's a dmesg and pciconf at http://stuff.mit.edu/afs/sipb.mit.edu/user/kaduk/freebsd/periphrasis/ The motherboard is a Gigabyte GA-P35-DS3L, so Intel P35 northbridge and Intel ICH9 southbridge; the actual video card came with very little documentation, but purpots to be a Radeon B2 256 HD2400PRO PCIe by VisionTek. The HD2400Pro part certainly seems accurate, at least. When setting up radeonhd for the card, I did need to toggle the hotplug detection bit in xorg.conf to get dual-monitor support; I haven't updated xorg since I filed that report, so I don't know if's been fixed already. -Ben Kaduk From mwm at mired.org Wed Jun 25 19:17:09 2008 From: mwm at mired.org (Mike Meyer) Date: Wed Jun 25 19:21:00 2008 Subject: 3D for AMD64 (was Re: Lack of Flash support is no longer acceptable. Bounty established...) In-Reply-To: <47d0403c0806251000q66162234nac5c0b1f7bf9b64c@mail.gmail.com> References: <20080619135114.Y1807@kozubik.com> <1214322926.1505.65.camel@scotth.emsphone.com> <7d6fde3d0806241040x6ed9dea6y79d2c2d62ff1b30f@mail.gmail.com> <200806250006.06789.thierry@herbelot.com> <47d0403c0806251000q66162234nac5c0b1f7bf9b64c@mail.gmail.com> Message-ID: <20080625151706.1de6e32d@mbook.local> On Wed, 25 Jun 2008 13:00:09 -0400 "Ben Kaduk" wrote: > On Tue, Jun 24, 2008 at 6:06 PM, Thierry Herbelot wrote: > > > > is there any hope for having the newly open-sourced radeon/radeon-hd AMD > > drivers (and the related 3D acceleration) to work under FreeBSD-AMD64 ? > > > > Well, I'm using radeonhd right now on a > [kaduk@periphrasis /usr/src/sys/contrib/dev/ath/public]$ uname -a > FreeBSD periphrasis.mit.edu 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed May > 14 00:27:26 EDT 2008 > root@periphrasis.mit.edu:/usr/obj/usr/src/sys/PERIPHRASIS amd64 I'm not sure those are the drivers Theierry wants. The proprietary driver was called fglrx, not "radeon" or "radeonhd". Those two drivers have been in the X open source trees for quite a while now. I first started using the radeon driver on amd64 in late 2006. The versions I have checked out for FreeBSD are documented as Radeonhd has no 2d or 3d acceleration. Radeon has both, but only works for older cards. That is also on 7-stable, but I haven't updated the sources in a while. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From fbsd06 at mlists.homeunix.com Wed Jun 25 20:39:34 2008 From: fbsd06 at mlists.homeunix.com (RW) Date: Wed Jun 25 20:39:41 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <4862074E.1000704@moneybookers.com> References: <200806241817.m5OIHLYU086621@fire.js.berklix.net> <48613EBA.507@cyberbotx.com> <4862074E.1000704@moneybookers.com> Message-ID: <20080625212216.4f1597a4@gumby.homeunix.com.> On Wed, 25 Jun 2008 11:52:30 +0300 Stefan Lambrev wrote: > I tried this before and have a bad luck of not having working audio > on flash, but today with new wine and FF3 it works. > > Btw there is a small nasty problem copy/paste from wine app to native > apps does not work. Ideas how to workaround this? It's only the traditional X, select and middle-click, that doesn't work in my experience The windows-style explicit cut/copy/paste works for me with KDE in both directions. From lx at FreeBSD.org Wed Jun 25 20:40:43 2008 From: lx at FreeBSD.org (David E. Thiel) Date: Wed Jun 25 20:40:48 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <20080625212216.4f1597a4@gumby.homeunix.com.> References: <200806241817.m5OIHLYU086621@fire.js.berklix.net> <48613EBA.507@cyberbotx.com> <4862074E.1000704@moneybookers.com> <20080625212216.4f1597a4@gumby.homeunix.com.> Message-ID: <20080625204042.GB70561@redundancy.redundancy.org> On Wed, Jun 25, 2008 at 09:21:53PM +0100, RW wrote: > > Btw there is a small nasty problem copy/paste from wine app to native > > apps does not work. Ideas how to workaround this? > > It's only the traditional X, select and middle-click, that > doesn't work in my experience > > The windows-style explicit cut/copy/paste works for me with KDE in > both directions. You could also use deskutils/autocutsel to help with this. From martes at mgwigglesworth.com Wed Jun 25 22:29:24 2008 From: martes at mgwigglesworth.com (Martes Wigglesworth) Date: Wed Jun 25 22:29:31 2008 Subject: [Fwd: Re: 3 connections as one] Message-ID: <1214430974.26401.0.camel@devstation> -------- Forwarded Message -------- From: Martes Wigglesworth Reply-To: martes@mgwigglesworth.com To: Andres Chavez Subject: Re: 3 connections as one Date: Tue, 24 Jun 2008 16:34:04 -0400 I have been researching this issue for almost a month now, and what I have found is that you can bind the ports together for outbound traffic, and the same can be done for inbound traffic, the problem comes when you try to get the inbound packets, or sessions to dispurse across the load-balanced ports. I.E.: Who is on the other side of the multiple DSL/Cable links to filter the traffic across the associated pipes so as to "balance the load," so to speak? It can be done, however, without an upstream, or maybe a vps that is being used as an external gateway, you will not be able to get the different session traffic to load balance across the multiple links, when downloading. At least that seems to be the situation, without some nifty DNS tricks. I have not seen how the "appliances" get around this, however, it took me this long for either list that I was on, to even admitt that the theory was not stupid, and to engage me in productive inquiry. If you find anything else out on this topic, please let me know. On Wed, 2008-06-25 at 00:07 +0000, Andres Chavez wrote: > Hi, a friend is challenge me to make use of 3 different connections (one > adsl, one cable, and one Evdo) as one single connection to internet, i > believe for make faster downloads or something such, its that can be > possible ?, if so, can anybody help me with this?, this sounds interesting > for know tricks on the FreeBSD operating system, he need to use this box as > the network manager and firewall as well, but the connection thing its > killing me i dont know how. > -- > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From julian at elischer.org Thu Jun 26 00:02:48 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Jun 26 00:02:53 2008 Subject: [Fwd: Re: 3 connections as one] In-Reply-To: <1214430974.26401.0.camel@devstation> References: <1214430974.26401.0.camel@devstation> Message-ID: <4862DCB5.6080005@elischer.org> Martes Wigglesworth wrote: > -------- Forwarded Message -------- > From: Martes Wigglesworth > Reply-To: martes@mgwigglesworth.com > To: Andres Chavez > Subject: Re: 3 connections as one > Date: Tue, 24 Jun 2008 16:34:04 -0400 > > I have been researching this issue for almost a month now, and what I > have found is that you can bind the ports together for outbound traffic, > and the same can be done for inbound traffic, the problem comes when you > try to get the inbound packets, or sessions to dispurse across the > load-balanced ports. I.E.: Who is on the other side of the multiple > DSL/Cable links to filter the traffic across the associated pipes so as > to "balance the load," so to speak? > > It can be done, however, without an upstream, or maybe a vps that is > being used as an external gateway, you will not be able to get the > different session traffic to load balance across the multiple links, > when downloading. > > At least that seems to be the situation, without some nifty DNS tricks. > I have not seen how the "appliances" get around this, however, it took > me this long for either list that I was on, to even admitt that the > theory was not stupid, and to engage me in productive inquiry. the usual way is to NAT traffic out though each interface so that the internet is not aware that sessions from apparently different places are actually the same.. you can do the same with multiple NAT instances and some way to divide up the load between interfaces.. > > If you find anything else out on this topic, please let me know. > > > On Wed, 2008-06-25 at 00:07 +0000, Andres Chavez wrote: >> Hi, a friend is challenge me to make use of 3 different connections (one >> adsl, one cable, and one Evdo) as one single connection to internet, i >> believe for make faster downloads or something such, its that can be >> possible ?, if so, can anybody help me with this?, this sounds interesting >> for know tricks on the FreeBSD operating system, he need to use this box as >> the network manager and firewall as well, but the connection thing its >> killing me i dont know how. >> -- >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From guru at unixarea.de Thu Jun 26 07:55:48 2008 From: guru at unixarea.de (Matthias Apitz) Date: Thu Jun 26 07:55:53 2008 Subject: eeePC 900 && turning off wireless (ath0) Message-ID: <20080626075545.GA2964@rebelion.Sisis.de> Hello, Yesterday I did some tests with my eeePC 900 to see how long it would work with the 4400 mAh battery ... it seems that turning of the wireless card (ath0), which can be turned of from the BIOS, has big effect and let work the eeePC for more then 2hours 15minutes; in the Xandros Linux you can turn off the NIC as well with Fn+F2 which in FreeBSD does not work at boot stage, i.e. when you may defer the booting in the boot loader countdown; is there any way to switch this off without going into the BIOS? thx in advance matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ ?...una sola vez, que es cuanto basta si se trata de verdades definitivas.? ?...only once, which is enough if it has todo with definite truth.? Jos? Saramago, Historia del Cerca de Lisboa From luiz at aonet.com.br Thu Jun 26 13:33:36 2008 From: luiz at aonet.com.br (Luiz Otavio O Souza) Date: Thu Jun 26 13:33:40 2008 Subject: [Fwd: Re: 3 connections as one] References: <1214430974.26401.0.camel@devstation> <4862DCB5.6080005@elischer.org> Message-ID: <001901c8d78d$8180c680$5e00a8c0@note4c47> ----- Original Message ----- Subject: Re: [Fwd: Re: 3 connections as one] : Martes Wigglesworth wrote: : > -------- Forwarded Message -------- : > From: Martes Wigglesworth : > Reply-To: martes@mgwigglesworth.com : > To: Andres Chavez : > Subject: Re: 3 connections as one : > Date: Tue, 24 Jun 2008 16:34:04 -0400 : > : > I have been researching this issue for almost a month now, and what I : > have found is that you can bind the ports together for outbound traffic, : > and the same can be done for inbound traffic, the problem comes when you : > try to get the inbound packets, or sessions to dispurse across the : > load-balanced ports. I.E.: Who is on the other side of the multiple : > DSL/Cable links to filter the traffic across the associated pipes so as : > to "balance the load," so to speak? : > : > It can be done, however, without an upstream, or maybe a vps that is : > being used as an external gateway, you will not be able to get the : > different session traffic to load balance across the multiple links, : > when downloading. : > : > At least that seems to be the situation, without some nifty DNS tricks. : > I have not seen how the "appliances" get around this, however, it took : > me this long for either list that I was on, to even admitt that the : > theory was not stupid, and to engage me in productive inquiry. : : : the usual way is to NAT traffic out though each interface : so that the internet is not aware that sessions from apparently : different places are actually the same.. : : : you can do the same with multiple NAT instances and some way to divide : up the load between interfaces.. I had write a patch, a long time before (probably in 4.x days - before libnat get the kernel bits) wich you can set two (fixed by patch at that time) alias address on natd. Another option has been added to natd, a number wich can be set from 0 to 100 to determine the use of the second alias address. This is intended to be used as "%", so 50 should be read as 50/50% balanced link. So when a connection has to be established for the first time, the patch use the value of balance option to determine what alias address should be used for this new connection. The natd will use the default alias address or the optional alias address based on the "balance" set. So natd is generating new connections in two diferent IPs (for two diferent connections) based on a "%" value, wich allow the use of unequal bandwidth links. At that time the patch work like a charm and is very usefull (as set 0/100 disable the use of one link and 100/0 disable the use of the other link without change any other configuration). Ipfw should be configured to deliver each IP/network to the proper gateway. Due to the number of changes in recent libalias/natd the patch need to be rewrite and the only thing i am not happy (and IMHO should be revised is the number of connections that should be from 1 to any and not limited to two). This should be a simple task for a natd/libalias developer (not enough time for me). -luiz From yanefbsd at gmail.com Thu Jun 26 14:32:15 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Jun 26 14:32:21 2008 Subject: 3D for AMD64 (was Re: Lack of Flash support is no longer acceptable. Bounty established...) In-Reply-To: <20080625151706.1de6e32d@mbook.local> References: <20080619135114.Y1807@kozubik.com> <1214322926.1505.65.camel@scotth.emsphone.com> <7d6fde3d0806241040x6ed9dea6y79d2c2d62ff1b30f@mail.gmail.com> <200806250006.06789.thierry@herbelot.com> <47d0403c0806251000q66162234nac5c0b1f7bf9b64c@mail.gmail.com> <20080625151706.1de6e32d@mbook.local> Message-ID: <7d6fde3d0806260732w588ed266ve519449f132f90b6@mail.gmail.com> On Wed, Jun 25, 2008 at 12:17 PM, Mike Meyer wrote: > On Wed, 25 Jun 2008 13:00:09 -0400 "Ben Kaduk" wrote: > >> On Tue, Jun 24, 2008 at 6:06 PM, Thierry Herbelot wrote: >> > >> > is there any hope for having the newly open-sourced radeon/radeon-hd AMD >> > drivers (and the related 3D acceleration) to work under FreeBSD-AMD64 ? >> > >> >> Well, I'm using radeonhd right now on a >> [kaduk@periphrasis /usr/src/sys/contrib/dev/ath/public]$ uname -a >> FreeBSD periphrasis.mit.edu 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed May >> 14 00:27:26 EDT 2008 >> root@periphrasis.mit.edu:/usr/obj/usr/src/sys/PERIPHRASIS amd64 > > I'm not sure those are the drivers Theierry wants. The proprietary > driver was called fglrx, not "radeon" or "radeonhd". Those two drivers > have been in the X open source trees for quite a while now. I first > started using the radeon driver on amd64 in late 2006. The versions I > have checked out for FreeBSD are documented as > > Radeonhd has no 2d or 3d acceleration. > Radeon has both, but only works for older cards. > > That is also on 7-stable, but I haven't updated the sources in a > while. fglrx is the only way that anyone's going to get true 3D OpenGL support, and the last time I checked that wasn't available except for ancient cards on FreeBSD. AMD was supposed to be helping ATI, but it appears that after the merger all that's happened is a website change and ATI's drivers have gotten worse... last time I tried x64 support with Linux I was sadly shocked by the poor programming that went into the driver and the difficulty I had trying to get it to work with X11. Then again things may have changed since that time too... My 2 cents, -Garrett From millenia2000 at hotmail.com Thu Jun 26 15:09:20 2008 From: millenia2000 at hotmail.com (Sean Cavanaugh) Date: Thu Jun 26 15:09:25 2008 Subject: 3D for AMD64 (was Re: Lack of Flash support is no longer acceptable. Bounty established...) In-Reply-To: <7d6fde3d0806260732w588ed266ve519449f132f90b6@mail.gmail.com> References: <20080619135114.Y1807@kozubik.com> <1214322926.1505.65.camel@scotth.emsphone.com> <7d6fde3d0806241040x6ed9dea6y79d2c2d62ff1b30f@mail.gmail.com> <200806250006.06789.thierry@herbelot.com> <47d0403c0806251000q66162234nac5c0b1f7bf9b64c@mail.gmail.com> <20080625151706.1de6e32d@mbook.local> <7d6fde3d0806260732w588ed266ve519449f132f90b6@mail.gmail.com> Message-ID: > fglrx is the only way that anyone's going to get true 3D OpenGL> support, and the last time I checked that wasn't available except for> ancient cards on FreeBSD.> > AMD was supposed to be helping ATI, but it appears that after the> merger all that's happened is a website change and ATI's drivers have> gotten worse... last time I tried x64 support with Linux I was sadly> shocked by the poor programming that went into the driver and the> difficulty I had trying to get it to work with X11.> > Then again things may have changed since that time too...> > My 2 cents,> -Garrett AMD is actively working to opensource the *nic drivers for the ATI cards starting with the most recent. From a news article iI came across they were actually hiring a whole new department whose sole purpose was to add more of the older cards to the open sorce drivers as well as eventually having 3d acceleration. As for the NEW 4000 series, the card will come with full drivers for windows and Linux on the install CD. granted there is still some coding to get BSD drivers, but AMD is making life better for *nix user with ATI cards. From dillon at apollo.backplane.com Thu Jun 26 16:53:41 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Thu Jun 26 16:53:45 2008 Subject: [Fwd: Re: 3 connections as one] References: <1214430974.26401.0.camel@devstation> <4862DCB5.6080005@elischer.org> <001901c8d78d$8180c680$5e00a8c0@note4c47> Message-ID: <200806261653.m5QGrasG020325@apollo.backplane.com> You can do it for outgoing connections fairly easily using the NAT trick (with PF), but you can't really load balance multiple links without support from some outside entity. If one of the tunnels goes down you can fail-over but any pre-existing connections will die and have to be re-established on the remaining link(s). That generally works ok for TCP but is total hell for UDP (because the source address will suddenly 'change' on an existing 'connection' and often trigger security blocks or simply break the program in question when it does). I've got a DSL connection and a Cable internet connection at home now, having replaced the T1 I had had for many years. I tried using the NAT trick using PF for outgoing but was never happy with the results under max load (and my links are typically running at 100% 24x7). I wasn't able to get fail-over to work properly with PF at all... the network was actually less reliable instead of more reliable and using NAT meant I had very little control over port selection or reverse-IP. I eventually gave up and now just use my DSL line for all my normal traffic, and my cable link for my off-site backup traffic. -- I'm planning out a new solution, one that a friend of mine implemented with a portable class C he owns at a colo with a single link which I want to extend to multiple links. The idea is to chop off a subnet from the colo-routed class C and run it to the home box over multiple tunnels (one over COMCAST, one over DSL). I am going to run all the tunnels through a single user program on my router box and backhaul it into a TUN interface (using PF on the TUN interface for QOS), and have the user program do all the load balancing and fail-over. Since the whole mess is routing a single subnet, no NAT tricks are needed and packets can be routed 100% dynamically. There would be no disconnections or UDP IP address changes. The only caveat is that the colo adds another 10ms to the round-trip time verses a direct connection. But on the plus side the home network can operate uninterrupted over however many discrete internet links I have access to, including modem dial backup or a directional WIFI link between friend's houses. -- I still gotta find time to write that program but there's nothing fancy about the concept. Maintain multiple links, route packets over the links that are up... simple stuff really. DragonFly has a number of utilities that make the job easy which FreeBSD folks might want to look into: http://www.dragonflybsd.org/cvsweb/src/usr.sbin/vknetd/ (vknetd is a packet switch, complete with a MAC cache & forwarding). + SOCK_SEQPACKET support in the kernel for unix domain sockets. (it wouldn't be too hard for FreeBSD to implement SOCK_SEQPACKET and stream connection support via unix domain sockets, it took less then a day to get it into DFly). Having a packetized stream socket connection to a user program (vknetd) which implements a packet switch takes all the effort out of messing around with network routing, literally. -Matt From hartzell at alerce.com Thu Jun 26 16:40:25 2008 From: hartzell at alerce.com (George Hartzell) Date: Thu Jun 26 16:57:22 2008 Subject: 3D for AMD64 (was Re: Lack of Flash support is no longer acceptable. Bounty established...) In-Reply-To: <20080625151706.1de6e32d@mbook.local> References: <20080619135114.Y1807@kozubik.com> <1214322926.1505.65.camel@scotth.emsphone.com> <7d6fde3d0806241040x6ed9dea6y79d2c2d62ff1b30f@mail.gmail.com> <200806250006.06789.thierry@herbelot.com> <47d0403c0806251000q66162234nac5c0b1f7bf9b64c@mail.gmail.com> <20080625151706.1de6e32d@mbook.local> Message-ID: <18531.49553.276614.955953@almost.alerce.com> Mike Meyer writes: > [...] > I'm not sure those are the drivers Theierry wants. The proprietary > driver was called fglrx, not "radeon" or "radeonhd". Those two drivers > have been in the X open source trees for quite a while now. I first > started using the radeon driver on amd64 in late 2006. The versions I > have checked out for FreeBSD are documented as > > Radeonhd has no 2d or 3d acceleration. > Radeon has both, but only works for older cards. > > That is also on 7-stable, but I haven't updated the sources in a > while. radeonhd does offer 2d acceleration, and 3-d is a work-in-progress, with existing support for some of the newish cards. You can get more info here: http://www.x.org/wiki/radeonhd Actually, the entire thing is still a work-in-progress, but the community is supportive. If you try to build from the git sources, you'll need to have the devel/xorg-macros port/package installed for the autogen.sh step to work. g. From julian at elischer.org Thu Jun 26 17:07:52 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Jun 26 17:07:55 2008 Subject: [Fwd: Re: 3 connections as one] In-Reply-To: <200806261653.m5QGrasG020325@apollo.backplane.com> References: <1214430974.26401.0.camel@devstation> <4862DCB5.6080005@elischer.org> <001901c8d78d$8180c680$5e00a8c0@note4c47> <200806261653.m5QGrasG020325@apollo.backplane.com> Message-ID: <4863CCF4.3000200@elischer.org> Matthew Dillon wrote: > You can do it for outgoing connections fairly easily using the NAT > trick (with PF), but you can't really load balance multiple links > without support from some outside entity. If one of the tunnels goes > down you can fail-over but any pre-existing connections will die and > have to be re-established on the remaining link(s). That generally > works ok for TCP but is total hell for UDP (because the source address > will suddenly 'change' on an existing 'connection' and often trigger > security blocks or simply break the program in question when it does). > > I've got a DSL connection and a Cable internet connection at home now, > having replaced the T1 I had had for many years. > > I tried using the NAT trick using PF for outgoing but was never happy > with the results under max load (and my links are typically running > at 100% 24x7). I wasn't able to get fail-over to work properly with > PF at all... the network was actually less reliable instead of more > reliable and using NAT meant I had very little control over port > selection or reverse-IP. > > I eventually gave up and now just use my DSL line for all my normal > traffic, and my cable link for my off-site backup traffic. > > -- > > I'm planning out a new solution, one that a friend of mine implemented > with a portable class C he owns at a colo with a single link which I > want to extend to multiple links. The idea is to chop off a subnet from > the colo-routed class C and run it to the home box over multiple tunnels > (one over COMCAST, one over DSL). > > I am going to run all the tunnels through a single user program on my > router box and backhaul it into a TUN interface (using PF on the TUN > interface for QOS), and have the user program do all the load balancing > and fail-over. Since the whole mess is routing a single subnet, no > NAT tricks are needed and packets can be routed 100% dynamically. > There would be no disconnections or UDP IP address changes. > > The only caveat is that the colo adds another 10ms to the round-trip > time verses a direct connection. But on the plus side the home network > can operate uninterrupted over however many discrete internet links I > have access to, including modem dial backup or a directional WIFI link > between friend's houses. I've done that running mpd to split the load over the tunnels from the colo. if either tunnel goes down mpd hickups nd hten everything keeps going.. > > -- > > I still gotta find time to write that program but there's nothing > fancy about the concept. Maintain multiple links, route packets over > the links that are up... simple stuff really. DragonFly has a number > of utilities that make the job easy which FreeBSD folks might want to > look into: > > http://www.dragonflybsd.org/cvsweb/src/usr.sbin/vknetd/ > > (vknetd is a packet switch, complete with a MAC cache & forwarding). ng_bridge.. > > + SOCK_SEQPACKET support in the kernel for unix domain sockets. > (it wouldn't be too hard for FreeBSD to implement SOCK_SEQPACKET > and stream connection support via unix domain sockets, it took > less then a day to get it into DFly). > > Having a packetized stream socket connection to a user program (vknetd) > which implements a packet switch takes all the effort out of messing > around with network routing, literally. mpd does this for me.. > > -Matt From marck at rinet.ru Thu Jun 26 17:35:18 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Thu Jun 26 17:35:24 2008 Subject: i386 jail undex amd64: libkvm Message-ID: <20080626211352.M77682@woozle.rinet.ru> Dear colleagues, it seems this question had been arised several times, but I failed to find any solution (yet). What is (and is there?) the proper way to compile libkvm-related binaries (and libkvm itself) to assure 32bit binaries work with amd64 kernel structures? Straight way with installing i386 world, or cross-compile with TARGET=i386 leads to empty result with ps and kvm_open: kinfo_proc size mismatch (expected 768, got 1088) top: Out of memory. with top. I tried to play with lib32 libraries and different system headers, but did not succeed. Any clues? Thank you in advance. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From dillon at apollo.backplane.com Thu Jun 26 17:42:49 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Thu Jun 26 17:42:52 2008 Subject: [Fwd: Re: 3 connections as one] References: <1214430974.26401.0.camel@devstation> <4862DCB5.6080005@elischer.org> <001901c8d78d$8180c680$5e00a8c0@note4c47> <200806261653.m5QGrasG020325@apollo.backplane.com> <4863CCF4.3000200@elischer.org> Message-ID: <200806261742.m5QHgbWo020788@apollo.backplane.com> :I've done that running mpd to split the load over the tunnels from the :colo. : :if either tunnel goes down mpd hickups nd hten everything keeps going.. :.. :mpd does this for me.. That looks almost perfect for the colo idea. I see how the links are set up and I see the bundle directive, but how do I configure a common subnet? Do I specify the same subnet for all the links and make them part of the same bundle (on both ends)? Is there a way to backhaul the bundle onto a single TUN interface? Or is that what ng_eiface is for? I need a tie-in for PF's QOS. There's no choice about that, my network is 100% saturated 24x7 and if I don't use PF's QOS with fair-share scheduling it becomes unusable. Looks like I might have to update netgraph on DFly to use mpd, but it doesn't look too difficult. But, gods, all those M_NOWAIT kernel mallocs... how can that possibly be reliable? -Matt Matthew Dillon From julian at elischer.org Thu Jun 26 19:54:19 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Jun 26 19:54:23 2008 Subject: [Fwd: Re: 3 connections as one] In-Reply-To: <200806261742.m5QHgbWo020788@apollo.backplane.com> References: <1214430974.26401.0.camel@devstation> <4862DCB5.6080005@elischer.org> <001901c8d78d$8180c680$5e00a8c0@note4c47> <200806261653.m5QGrasG020325@apollo.backplane.com> <4863CCF4.3000200@elischer.org> <200806261742.m5QHgbWo020788@apollo.backplane.com> Message-ID: <4863F3F9.6020206@elischer.org> Matthew Dillon wrote: > :I've done that running mpd to split the load over the tunnels from the > :colo. > : > :if either tunnel goes down mpd hickups nd hten everything keeps going.. > :.. > :mpd does this for me.. > > That looks almost perfect for the colo idea. I see how the links are > set up and I see the bundle directive, but how do I configure a common > subnet? Do I specify the same subnet for all the links and make them > part of the same bundle (on both ends)? > > Is there a way to backhaul the bundle onto a single TUN interface? > Or is that what ng_eiface is for? I need a tie-in for PF's QOS. > There's no choice about that, my network is 100% saturated 24x7 and > if I don't use PF's QOS with fair-share scheduling it becomes unusable. the ng_iface that is created (ng0 or whatever) is the virtual connection back to the colo. now that we have multiple routing tables we can make the tunnel and its contents use different routing tables which can simplify things. mpd allows you to backhaul through udp or tcp transport 'tunnels' to the remote poitn of your choice. > > Looks like I might have to update netgraph on DFly to use mpd, but it > doesn't look too difficult. But, gods, all those M_NOWAIT kernel > mallocs... how can that possibly be reliable? what can I say without degenerating into a dogfight? The code is designed to copy with failure to allocate.. the error will propogate up.. not much is allocated once you have it set up. > > -Matt > Matthew Dillon > From julian at elischer.org Thu Jun 26 20:02:52 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Jun 26 20:02:56 2008 Subject: i386 jail undex amd64: libkvm In-Reply-To: <20080626211352.M77682@woozle.rinet.ru> References: <20080626211352.M77682@woozle.rinet.ru> Message-ID: <4863F2CE.30902@elischer.org> Dmitry Morozovsky wrote: > Dear colleagues, > > it seems this question had been arised several times, but I failed to find any > solution (yet). > > What is (and is there?) the proper way to compile libkvm-related binaries (and > libkvm itself) to assure 32bit binaries work with amd64 kernel structures? > > Straight way with installing i386 world, or cross-compile with TARGET=i386 > leads to empty result with ps and > you can not do this. there are a small number of system utilities that can not be run across the 386/amd64 chasm. Anything that uses libkvm on the riunning system is one of them. teh asnwer is to have a small numebr of 64 bit utilities in your "32 bit" jail. Netstat, ps and some others are examples (top, systat). you could put the 64 bit shared libs in your jail, or you could grab static versions from /rescue. It's just the way it has to be.. (unless we have special code to translate proc structure fields. which probably wouldn't make sense anyhow). > kvm_open: kinfo_proc size mismatch (expected 768, got 1088) > top: Out of memory. > > with top. > > I tried to play with lib32 libraries and different system headers, but did not > succeed. > > Any clues? > > Thank you in advance. > > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck@FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------ > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From dillon at apollo.backplane.com Thu Jun 26 20:12:48 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Thu Jun 26 20:12:51 2008 Subject: [Fwd: Re: 3 connections as one] References: <1214430974.26401.0.camel@devstation> <4862DCB5.6080005@elischer.org> <001901c8d78d$8180c680$5e00a8c0@note4c47> <200806261653.m5QGrasG020325@apollo.backplane.com> <4863CCF4.3000200@elischer.org> <200806261742.m5QHgbWo020788@apollo.backplane.com> <4863F3F9.6020206@elischer.org> Message-ID: <200806262012.m5QKCfgl022095@apollo.backplane.com> :what can I say without degenerating into a dogfight? :The code is designed to copy with failure to allocate.. the error will :propogate up.. : :not much is allocated once you have it set up. Well, not really trying to start a fight but unless the initialization code that sets this stuff up retries on ENOMEM, don't you risk load on the machine creating a situation where M_NOWAIT can return NULL under normal operation and cause a one-time initialization to basically fail? That doesn't sound good to me. I've noticed the same thing with many driver's softc allocations. A lot of them use M_NOWAIT but clearly do not handle a temporary allocation failure. They may not crash, but they won't initialize either. The user expectation is for the driver to only fail to initialize if something serious has occured. DragonFly is a bit more sensitive then FreeBSD. Maybe M_NOWAIT allocations on FreeBSD have no chance of failing unless the system is actually out of memory. But on DFly anything that would cause a thread switch during the allocation will fail if M_NOWAIT is specified. -Matt Matthew Dillon From kris at FreeBSD.org Thu Jun 26 23:14:56 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu Jun 26 23:14:59 2008 Subject: command-line bittorrent utility Message-ID: <486422EF.3070501@FreeBSD.org> I am looking for a command-line utility that can fetch via bittorrent that a) doesn't use curses. It must be usable in a script and without a tty! b) doesn't use X11. Must be a command-line utility! c) Must be able to inform the script when the transfer is complete. A callback mechanism of some kind is fine as long as it doesn't require polling. This is for distribution of files within a LAN and WAN: I have some large files that I need to distribute to many machines, and pushing them all out multiple times from the server is inefficient. Things that come close: * The python implementation, but it doesn't seem to work very reliably. I get errors and exceptions from both the client and server when transferring a file with only two machines participating. * http://www.murmeldjur.se/btpd/ is a daemon with command line client. It doesn't provide for c), and it also doesn't work reliably. * Not much else. Surely I am not the first person to want to use bittorrent in a script? Kris From rpaulo at FreeBSD.org Thu Jun 26 23:17:53 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Thu Jun 26 23:17:57 2008 Subject: eeePC 900 && turning off wireless (ath0) In-Reply-To: <20080626075545.GA2964@rebelion.Sisis.de> References: <20080626075545.GA2964@rebelion.Sisis.de> Message-ID: <20080626231603.GC6875@phi.local> On Thu, Jun 26, 2008 at 09:55:45AM +0200, Matthias Apitz wrote: > > Hello, > > Yesterday I did some tests with my eeePC 900 to see how long it would > work with the 4400 mAh battery ... it seems that turning of the wireless > card (ath0), which can be turned of from the BIOS, has big effect and > let work the eeePC for more then 2hours 15minutes; > > in the Xandros Linux you can turn off the NIC as well with Fn+F2 which > in FreeBSD does not work at boot stage, i.e. when you may defer the > booting in the boot loader countdown; Yes, this only works after booting. At least on the 701. > is there any way to switch this off without going into the BIOS? After booting you can unload ath module and press Fn+F2. It should turn off wireless. The problem is that you can't turn it back on. For that, we need PCIe hotplug support. (That's what Fn+F2 does, it ejects the wireless card). Regards, -- Rui Paulo From kris at FreeBSD.org Thu Jun 26 23:51:21 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Thu Jun 26 23:51:24 2008 Subject: command-line bittorrent utility In-Reply-To: <4864239F.1050308@hexon.cx> References: <486422EF.3070501@FreeBSD.org> <4864239F.1050308@hexon.cx> Message-ID: <48642B77.90104@FreeBSD.org> Jille Timmermans wrote: > (enhanced) ctorrent Seems to fail requirement a). Am I wrong? Kris > > Kris Kennaway schreef: >> I am looking for a command-line utility that can fetch via bittorrent >> that >> >> a) doesn't use curses. It must be usable in a script and without a tty! >> >> b) doesn't use X11. Must be a command-line utility! >> >> c) Must be able to inform the script when the transfer is complete. A >> callback mechanism of some kind is fine as long as it doesn't require >> polling. >> >> This is for distribution of files within a LAN and WAN: I have some >> large files that I need to distribute to many machines, and pushing >> them all out multiple times from the server is inefficient. >> >> Things that come close: >> >> * The python implementation, but it doesn't seem to work very >> reliably. I get errors and exceptions from both the client and server >> when transferring a file with only two machines participating. >> >> * http://www.murmeldjur.se/btpd/ is a daemon with command line client. >> It doesn't provide for c), and it also doesn't work reliably. >> >> * Not much else. >> >> Surely I am not the first person to want to use bittorrent in a script? >> >> Kris >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" > > From kris at FreeBSD.org Fri Jun 27 00:13:00 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Fri Jun 27 00:13:02 2008 Subject: command-line bittorrent utility In-Reply-To: <486422EF.3070501@FreeBSD.org> References: <486422EF.3070501@FreeBSD.org> Message-ID: <4864308B.8030202@FreeBSD.org> Kris Kennaway wrote: > I am looking for a command-line utility that can fetch via bittorrent [...] OK folks, you can stop telling me to use ctorrent now :) I had looked at that but assumed it was using curses (it's not). Thanks! Kris From jille at hexon.cx Thu Jun 26 23:47:13 2008 From: jille at hexon.cx (Jille Timmermans) Date: Fri Jun 27 01:02:51 2008 Subject: command-line bittorrent utility In-Reply-To: <486422EF.3070501@FreeBSD.org> References: <486422EF.3070501@FreeBSD.org> Message-ID: <4864239F.1050308@hexon.cx> (enhanced) ctorrent Kris Kennaway schreef: > I am looking for a command-line utility that can fetch via bittorrent > that > > a) doesn't use curses. It must be usable in a script and without a tty! > > b) doesn't use X11. Must be a command-line utility! > > c) Must be able to inform the script when the transfer is complete. A > callback mechanism of some kind is fine as long as it doesn't require > polling. > > This is for distribution of files within a LAN and WAN: I have some > large files that I need to distribute to many machines, and pushing > them all out multiple times from the server is inefficient. > > Things that come close: > > * The python implementation, but it doesn't seem to work very > reliably. I get errors and exceptions from both the client and server > when transferring a file with only two machines participating. > > * http://www.murmeldjur.se/btpd/ is a daemon with command line client. > It doesn't provide for c), and it also doesn't work reliably. > > * Not much else. > > Surely I am not the first person to want to use bittorrent in a script? > > Kris > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From scf at FreeBSD.org Fri Jun 27 01:03:10 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Fri Jun 27 01:03:13 2008 Subject: command-line bittorrent utility In-Reply-To: <486422EF.3070501@FreeBSD.org> References: <486422EF.3070501@FreeBSD.org> Message-ID: On Fri, 27 Jun 2008, Kris Kennaway wrote: > I am looking for a command-line utility that can fetch via bittorrent > that > > a) doesn't use curses. It must be usable in a script and without a > tty! > > b) doesn't use X11. Must be a command-line utility! > > c) Must be able to inform the script when the transfer is complete. A > callback mechanism of some kind is fine as long as it doesn't require > polling. > > This is for distribution of files within a LAN and WAN: I have some > large files that I need to distribute to many machines, and pushing > them all out multiple times from the server is inefficient. More choices: 1. /usr/ports/net-p2p/transmission 2. /usr/ports/net-p2p/transmission-daemon Sean -- scf@FreeBSD.org From bbs at mail.ie Thu Jun 26 23:58:16 2008 From: bbs at mail.ie (bbs@mail.ie) Date: Fri Jun 27 01:08:22 2008 Subject: command-line bittorrent utility In-Reply-To: <486422EF.3070501@FreeBSD.org> References: <486422EF.3070501@FreeBSD.org> Message-ID: <9f8af95f0806261630l4c30db6dw58d771aa697ce63b@mail.gmail.com> Kris, just at a first glance i noticed wikipedia had a pretty good breakdown of some clients available -- this isn't meant to be rude RTFM at all -- :) -- i just thought it might be helpful -- maybe not. http://en.wikipedia.org/wiki/BitTorrent_client respectfully, jt On Thu, Jun 26, 2008 at 7:14 PM, Kris Kennaway wrote: > I am looking for a command-line utility that can fetch via bittorrent that > > a) doesn't use curses. It must be usable in a script and without a tty! > > b) doesn't use X11. Must be a command-line utility! > > c) Must be able to inform the script when the transfer is complete. A > callback mechanism of some kind is fine as long as it doesn't require > polling. > > This is for distribution of files within a LAN and WAN: I have some large > files that I need to distribute to many machines, and pushing them all out > multiple times from the server is inefficient. > > Things that come close: > > * The python implementation, but it doesn't seem to work very reliably. I > get errors and exceptions from both the client and server when transferring > a file with only two machines participating. > > * http://www.murmeldjur.se/btpd/ is a daemon with command line client. It > doesn't provide for c), and it also doesn't work reliably. > > * Not much else. > > Surely I am not the first person to want to use bittorrent in a script? > > Kris > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- jt From tim at clewlow.org Fri Jun 27 03:00:50 2008 From: tim at clewlow.org (Tim Clewlow) Date: Fri Jun 27 03:00:54 2008 Subject: ICANN votes to expand domain name character set Message-ID: <52484.192.168.1.10.1214534665.squirrel@192.168.1.100> Hi there, In case you haven't heard yet, ICANN have unanimously voted their approval to expand the domain name character set to include Asian, Middle Eastern, Eastern European and Russian character sets in domain names. In addition, top level domains will have their restrictions removed, ie any non-offensive top level domains will now be allowed. I'm guessing the inclusion of the new character sets will mean a fair amount of alteration to code that processes domain names. http://www.icann.org/en/announcements/announcement-4-26jun08-en.htm Cheers, Tim. We are BSD ... resistance is futile. http://www.freebsd.org/ - http://www.openbsd.org/ - http://www.netbsd.org/ From dougb at FreeBSD.org Fri Jun 27 05:41:34 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Jun 27 05:41:38 2008 Subject: ICANN votes to expand domain name character set In-Reply-To: <52484.192.168.1.10.1214534665.squirrel@192.168.1.100> References: <52484.192.168.1.10.1214534665.squirrel@192.168.1.100> Message-ID: <4864774A.4080601@FreeBSD.org> Tim Clewlow wrote: > Hi there, > > In case you haven't heard yet, ICANN have unanimously voted their > approval to expand the domain name character set to include Asian, > Middle Eastern, Eastern European and Russian character sets in domain > names. That's already possible at the second level and above through IDN. Check out ftp://ftp.rfc-editor.org/in-notes/rfc3491.txt and ftp://ftp.rfc-editor.org/in-notes/rfc3492.txt. In short, the client software that deals with IDNs is required to make the translation from "International" characters to punycode strings before sending the dns request, so in an ideal world nothing below the client layer will have to change. So far the world has been more or less ideal, depending on where you sit. :) The actual change that's being announced now is the approval of IDN strings at the top level. Conceptually this is the same mechanism. But the "layer 9" stuff make this really interesting/complicated/annoying, once again depending on where you sit. I was involved in a lot of IDN stuff when I was at ICANN running the IANA, so if anyone wants more details let me know, I can go on for hours. > In addition, top level domains will have their restrictions removed, > ie any non-offensive top level domains will now be allowed. That's not _quite_ true. The restriction of two-letter domains for country codes will still be in place, and there is some protection for trademark holders, etc. > I'm guessing the inclusion of the new character sets will mean a fair > amount of alteration to code that processes domain names. Client code, yes. In a lot of ways FreeBSD is behind the curve on this, since we really should have been building (more) punycode translation capability into our client software already. The good news is that on the software level if you can do that for the second level and above it's pretty easy to do it for TLDs. The more interesting problem there is a lot of ancient software, web scripts, etc. with hard-coded rules about how TLDs only have 3 characters .... hth, Doug -- This .signature sanitized for your protection From karimulla at krify.com Fri Jun 27 06:28:34 2008 From: karimulla at krify.com (karim sk) Date: Fri Jun 27 06:28:39 2008 Subject: Modifying the loaded kernel image Message-ID: <20080626230421.BD605429@resin17.mta.everyone.net>
Hi,

I need to modify one of the kernel hardware module ( which is part of kernel image) and i have to load that module instead of the old one.
So what i am doing now is
During boot up step into loader prompt and i am typing the following commands.
load kernel (Load the kernel )
load module ( To load my customized module)
boot ( To start the normal boot).

Now i am facing some problem here. Loading of my module is successful but my module registration is not getting successful. i.e. OS is reporting that module_register got failed as there exists already a module with that name. Now the problem is i cant do unload of the old component as it is not a module.  Can any body tell me how to remove the component from the kernel image with out recompiling the kernel.


Thanks in advance.
Karim.


 
I use Krify Mail - http://mail.krify.com  Get  yourmail at  Krify today!
From koitsu at FreeBSD.org Fri Jun 27 07:37:41 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Jun 27 07:37:44 2008 Subject: Modifying the loaded kernel image In-Reply-To: <20080626230421.BD605429@resin17.mta.everyone.net> References: <20080626230421.BD605429@resin17.mta.everyone.net> Message-ID: <20080627073740.GA29727@eos.sc1.parodius.com> On Thu, Jun 26, 2008 at 11:04:21PM -0700, karim sk wrote: >
Hi,

I need to modify one of the kernel hardware module ( which is part of kernel image) and i have to load that module instead of the old one.
So what i am doing now is
During boot up step into loader prompt and i am typing the following commands.
load kernel (Load the kernel )
load module ( To load my customized module)
boot ( To start the normal boot).

Now i am facing some problem here. Loading of my module is successful but my module registration is not getting successful. i.e. OS is reporting that module_register got failed as there exists already a module with that name. Now the problem is i cant do unload of the old component as it is not a module.  Can any body tell me how to remove the component from the kernel image with out recompiling the kernel.


Thanks in advance.
Karim.


 
I use Krify Mail - http://mail.krify.com  Get  yourmail at  Krify today!
Short answer: you can't. Also, HTML Email is incredibly annoying. And you know what's even *more* annoying? HTML Email that is sent with a text/plain MIME type, indicating it's not HTML. Fix your mail client, it's very rude. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From guru at unixarea.de Fri Jun 27 08:02:09 2008 From: guru at unixarea.de (Matthias Apitz) Date: Fri Jun 27 08:02:51 2008 Subject: eeePC 900 && turning off wireless (ath0) In-Reply-To: <20080626231603.GC6875@phi.local> References: <20080626075545.GA2964@rebelion.Sisis.de> <20080626231603.GC6875@phi.local> Message-ID: <20080627080203.GA19602@rebelion.Sisis.de> El d?a Friday, June 27, 2008 a las 12:16:03AM +0100, Rui Paulo escribi?: > On Thu, Jun 26, 2008 at 09:55:45AM +0200, Matthias Apitz wrote: > > > > Hello, > > > > Yesterday I did some tests with my eeePC 900 to see how long it would > > work with the 4400 mAh battery ... it seems that turning of the wireless > > card (ath0), which can be turned of from the BIOS, has big effect and > > let work the eeePC for more then 2hours 15minutes; > > > > in the Xandros Linux you can turn off the NIC as well with Fn+F2 which > > in FreeBSD does not work at boot stage, i.e. when you may defer the > > booting in the boot loader countdown; > > Yes, this only works after booting. At least on the 701. > > > is there any way to switch this off without going into the BIOS? > > After booting you can unload ath module and press Fn+F2. It should turn > off wireless. > > The problem is that you can't turn it back on. For that, we need PCIe > hotplug support. (That's what Fn+F2 does, it ejects the wireless card). Hello Rui, I recompiled the kernel to have if_ath out of the kernel, but as a loaded module at boot: $ kldstat Id Refs Address Size Name 1 14 0xc0400000 8c7098 kernel 2 1 0xc0cc8000 1242c if_ath.ko 3 3 0xc0cdb000 46324 ath_hal.ko 4 2 0xc0d22000 4218 ath_rate.ko 5 1 0xc0d27000 14324 snd_hda.ko 6 2 0xc0d3c000 4a5ac sound.ko 7 1 0xc0d87000 6a32c acpi.ko 8 1 0xc4394000 22000 linux.ko I can unload if_ath, ath_hal and ath_rate which drops the interface ath0, but even in this case Fn+F2 has no affect at all; any idea? I've had a look into the Xandros Linux and they do it with ACPI events, dropping the modules and others; I could provide their script /etc/acpi/wlan.sh if someone wants to have a look into; Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ ?...una sola vez, que es cuanto basta si se trata de verdades definitivas.? ?...only once, which is enough if it has todo with definite truth.? Jos? Saramago, Historia del Cerca de Lisboa From rdivacky at freebsd.org Fri Jun 27 09:02:20 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Fri Jun 27 09:02:24 2008 Subject: kmem_alloc_wait and memory pools questions Message-ID: <20080627084328.GA39337@freebsd.org> hi I have two questions: 1) is kmem_alloc_wait() expensive operation? I believe it's not very cheap looking at the code but I want confirmation 2) is there a support for memory pools in FreeBSD? to give you a little background why I am asking this. In NetBSD Andrew Doran claims that replacing allocation from a memory submap with an allocation from a memory pool for exec*() args he can speedup exec*() by ~25% I wonder if this applies to FreeBSD too so I am investigating it a little. thnx! roman From max at love2party.net Fri Jun 27 11:50:15 2008 From: max at love2party.net (Max Laier) Date: Fri Jun 27 11:50:21 2008 Subject: kmem_alloc_wait and memory pools questions In-Reply-To: <20080627084328.GA39337@freebsd.org> References: <20080627084328.GA39337@freebsd.org> Message-ID: <200806271348.20172.max@love2party.net> On Friday 27 June 2008 10:43:29 Roman Divacky wrote: > hi > > I have two questions: > > 1) is kmem_alloc_wait() expensive operation? I believe it's not > very cheap looking at the code but I want confirmation > > 2) is there a support for memory pools in FreeBSD? > > to give you a little background why I am asking this. In NetBSD Andrew > Doran claims that replacing allocation from a memory submap with an > allocation from a memory pool for exec*() args he can speedup exec*() > by ~25% I think what is called a "memory pool" in NetBSD refers to their pool(9) API. This is more or less the same as our uma(9). Whether or not this is what you are looking for - I don't know. > I wonder if this applies to FreeBSD too so I am investigating it a > little. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From jeremie at le-hen.org Fri Jun 27 11:58:40 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Fri Jun 27 11:58:44 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: References: <20080619135114.Y1807@kozubik.com> Message-ID: <20080627115403.GK15815@obiwan.tataz.chchile.org> Hi, On Tue, Jun 24, 2008 at 11:03:08AM -0600, Mark Carlson wrote: > I've found wine + firefox + flash to work for everything I've tried so > far (youtube, various websites with flash ads, one or two flash-only > sites.) It did crash on me once, but I'm not sure it was related to > flash. Wine is pretty good, but not perfect. If all you need is to > visit flash sites, it's a decent workaround in the mean time. Also, I > was very surprised how easy it was to set up (not having used wine > before.) The sake of completeness, I think it's worth mentionning that when using nspluginwrapper, it is theorically possible to run the Flash plugin (and other ones too) inside QEMU. I've read this on nspluginwrapper author's website [1]: this trick is used to execute binary plugins for i386 on other platforms but this could obviously work for our problem. Unfortunately, I've never seen any documentation or instruction to set up this. I've Cc'ed the author, in case he has some time to provide additional details. [1] http://gwenole.beauchesne.info/en/projects/nspluginwrapper/help#usage Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From fbsd06 at mlists.homeunix.com Fri Jun 27 12:30:35 2008 From: fbsd06 at mlists.homeunix.com (RW) Date: Fri Jun 27 12:30:40 2008 Subject: Modifying the loaded kernel image In-Reply-To: <20080627073740.GA29727@eos.sc1.parodius.com> References: <20080626230421.BD605429@resin17.mta.everyone.net> <20080627073740.GA29727@eos.sc1.parodius.com> Message-ID: <20080627131822.28b1dcff@gumby.homeunix.com.> On Fri, 27 Jun 2008 00:37:40 -0700 Jeremy Chadwick wrote: > Also, HTML Email is incredibly annoying. And you know what's even > *more* annoying? HTML Email that is sent with a text/plain MIME type, > indicating it's not HTML. There was also a problem with the base64 encoding, claws-mail couldn't display the message at all From onemda at gmail.com Fri Jun 27 13:50:51 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Fri Jun 27 13:50:58 2008 Subject: command-line bittorrent utility In-Reply-To: <48642B77.90104@FreeBSD.org> References: <486422EF.3070501@FreeBSD.org> <4864239F.1050308@hexon.cx> <48642B77.90104@FreeBSD.org> Message-ID: <3a142e750806270650x338e7c49oaf2fab603fb636b@mail.gmail.com> On 6/27/08, Kris Kennaway wrote: > Jille Timmermans wrote: >> (enhanced) ctorrent > > Seems to fail requirement a). Am I wrong? > > Kris > enhanced ctorrent is actual ctorrent from ports. it doesnt use ncurses. ldd /usr/local/bin/ctorrent /usr/local/bin/ctorrent: libssl.so.5 => /usr/lib/libssl.so.5 (0x280a7000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x280e8000) libm.so.5 => /lib/libm.so.5 (0x281db000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x281f4000) libc.so.7 => /lib/libc.so.7 (0x281ff000) libcrypto.so.5 => /lib/libcrypto.so.5 (0x28306000) transmission also doesnt use ncurses. the only one I'm aware of that use ncurses is rtorrent. >> >> Kris Kennaway schreef: >>> I am looking for a command-line utility that can fetch via bittorrent >>> that >>> >>> a) doesn't use curses. It must be usable in a script and without a tty! >>> >>> b) doesn't use X11. Must be a command-line utility! >>> >>> c) Must be able to inform the script when the transfer is complete. A >>> callback mechanism of some kind is fine as long as it doesn't require >>> polling. >>> >>> This is for distribution of files within a LAN and WAN: I have some >>> large files that I need to distribute to many machines, and pushing >>> them all out multiple times from the server is inefficient. >>> >>> Things that come close: >>> >>> * The python implementation, but it doesn't seem to work very >>> reliably. I get errors and exceptions from both the client and server >>> when transferring a file with only two machines participating. >>> >>> * http://www.murmeldjur.se/btpd/ is a daemon with command line client. >>> It doesn't provide for c), and it also doesn't work reliably. >>> >>> * Not much else. >>> >>> Surely I am not the first person to want to use bittorrent in a script? >>> >>> Kris >>> >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to >>> "freebsd-hackers-unsubscribe@freebsd.org" >> >> > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From gb.public at free.fr Fri Jun 27 13:38:39 2008 From: gb.public at free.fr (gb.public@free.fr) Date: Fri Jun 27 13:51:58 2008 Subject: Lack of Flash support is no longer acceptable. Bounty established... In-Reply-To: <29921993.2869251214572837043.JavaMail.root@spooler5-g27.priv.proxad.net> Message-ID: <12511256.2869421214572902697.JavaMail.root@spooler5-g27.priv.proxad.net> Hi, > The sake of completeness, I think it's worth mentionning that when > using > nspluginwrapper, it is theorically possible to run the Flash plugin > (and > other ones too) inside QEMU. This is possible but slow and I used a very old version of QEMU. IIRC, the OpenSUSE wiki mentions how to do that with a more recent version of QEMU. However, if you run on i386, you don't need QEMU, simply use nspluginwrapper as is. I use FreeBSD 6.1 and tested FlashPlayer 9 lately, it works. Though not in a browser yet but with a standalone plugins viewer I wrote for testing and another project. I don't mean it won't work in a browser, I only mean I haven't got time to fully test with Firefox on *BSD yet. You can get trunk, which represents the upcoming nspluginwrapper 1.2.0, through: $ svn co http://svn.beauchesne.info/svn/gwenole/projects/nspluginwrapper/trunk nspluginwrapper nspluginwrapper 1.0.0 (targetted to be released this weekend) is available in a separate branch: $ svn co http://svn.beauchesne.info/svn/gwenole/projects/nspluginwrapper/branches/nspluginwrapper-1.0-branch I have not written docs for the standalone player yet (npplayer) but its usage is rather simple: npplayer src=uri/to/flash/content.swf npplayer can be useful to you so that to test whether your problems are related to your Linux emulator or the browser, or even nspluginwrapper. BTW, I would appreciate if people could test nspluginwrapper 1.0 on recent FreeBSD versions before I release it since I only have FreeBSD 6.1 and FreeBSD 5.3 at home. Thanks. Regards, Gwenole Beauchesne. From roberthuff at rcn.com Fri Jun 27 14:27:29 2008 From: roberthuff at rcn.com (Robert Huff) Date: Fri Jun 27 14:27:34 2008 Subject: 3D for AMD64 (was Re: Lack of Flash support is no longer acceptable. Bounty established...) In-Reply-To: References: Message-ID: <18532.61969.358948.2956@jerusalem.litteratus.org> Sean Cavanaugh writes: > AMD is actively working to opensource the *nic drivers for the > ATI cards starting with the most recent. From a news article iI > came across they were actually hiring a whole new department > whose sole purpose was to add more of the older cards to the open > sorce drivers as well as eventually having 3d acceleration. As > for the NEW 4000 series, the card will come with full drivers for > windows and Linux on the install CD. granted there is still some > coding to get BSD drivers, but AMD is making life better for *nix > user with ATI cards. Is there any place (web site, wiki, blog) where the public can track this effort? Robert Huff From ken at mthelicon.com Fri Jun 27 14:49:24 2008 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Fri Jun 27 14:49:28 2008 Subject: 3D for AMD64 (was Re: Lack of Flash support is no longer acceptable. Bounty established...) In-Reply-To: <18532.61969.358948.2956@jerusalem.litteratus.org> References: <18532.61969.358948.2956@jerusalem.litteratus.org> Message-ID: <001e01c8d864$fcbd6920$f6383b60$@com> http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-radeonhd;a=summary > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- > hackers@freebsd.org] On Behalf Of Robert Huff > Sent: 27 June 2008 14:59 > To: Sean Cavanaugh > Cc: freebsd-hackers@freebsd.org > Subject: RE: 3D for AMD64 (was Re: Lack of Flash support is no longer > acceptable. Bounty established...) > > > Sean Cavanaugh writes: > > > AMD is actively working to opensource the *nic drivers for the > > ATI cards starting with the most recent. From a news article iI > > came across they were actually hiring a whole new department > > whose sole purpose was to add more of the older cards to the open > > sorce drivers as well as eventually having 3d acceleration. As > > for the NEW 4000 series, the card will come with full drivers for > > windows and Linux on the install CD. granted there is still some > > coding to get BSD drivers, but AMD is making life better for *nix > > user with ATI cards. > > Is there any place (web site, wiki, blog) where the public can > track this effort? > > > Robert Huff > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers- > unsubscribe@freebsd.org" From dillon at apollo.backplane.com Fri Jun 27 16:51:32 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Fri Jun 27 16:51:38 2008 Subject: kmem_alloc_wait and memory pools questions References: <20080627084328.GA39337@freebsd.org> <200806271348.20172.max@love2party.net> Message-ID: <200806271651.m5RGpW8C030680@apollo.backplane.com> :On Friday 27 June 2008 10:43:29 Roman Divacky wrote: :> hi :> :> I have two questions: :> :> 1) is kmem_alloc_wait() expensive operation? I believe it's not :> very cheap looking at the code but I want confirmation :> :> 2) is there a support for memory pools in FreeBSD? :> :> to give you a little background why I am asking this. In NetBSD Andrew :> Doran claims that replacing allocation from a memory submap with an :> allocation from a memory pool for exec*() args he can speedup exec*() :> by ~25% : :I think what is called a "memory pool" in NetBSD refers to their pool(9) :API. This is more or less the same as our uma(9). Whether or not this :is what you are looking for - I don't know. : :> I wonder if this applies to FreeBSD too so I am investigating it a :> little. : :-- :/"\ Best regards, | mlaier@freebsd.org :\ / Max Laier | ICQ #67774661 Yes, and yes. The key issue here is that kmem_alloc*() futzes with the kernel page tables every single time, and on a SMP box that is extremely expensive due to the cpu synchronization required. A memory pool, on the other hand, tends to simply reuse kernel memory which has already been mapped. Much less page table futzing goes on. I don't know if UMA is exactly equivalent for allocations that large (exec-args is 64-128K), but someone else can answer that. The key issue with regards to converting exec args is that you still must limit the pool size and block if too many processes are trying to exec at once, or you will really unbalance physical (and on i386 KVM) memory use. A pool able to hold 8-16 allocations, and hence handle 8-16 simultanious exec()s, is plenty big enough. (DragonFly did this about a year ago, it is definitely worth doing). -Matt From sbruno at miralink.com Fri Jun 27 19:42:01 2008 From: sbruno at miralink.com (Sean Bruno) Date: Fri Jun 27 19:42:04 2008 Subject: Error from systinstall while trying to install man page packages Message-ID: <48654287.4000508@miralink.com> I am attempting to install the man page distribution from sysinstall on my RELENG_7 box and getting errors that my distribution doesn't exist. I assume that it is due to the fact that I have recompiled my kernel and sysinstall is using something from my "uname" output to figure out what directories it should look in for packages. Can anyone give me some guidance on how to get sysinstall to know what it's version acutally is? uname output: FreeBSD ophelia 7.0-STABLE FreeBSD 7.0-STABLE #7: Fri Jun 27 12:11:52 UTC 2008 sbruno@ophelia:/usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/i386/compile/GENERIC i386 -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 From rpaulo at FreeBSD.org Fri Jun 27 19:46:36 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Fri Jun 27 19:46:41 2008 Subject: eeePC 900 && turning off wireless (ath0) In-Reply-To: <20080627080203.GA19602@rebelion.Sisis.de> References: <20080626075545.GA2964@rebelion.Sisis.de> <20080626231603.GC6875@phi.local> <20080627080203.GA19602@rebelion.Sisis.de> Message-ID: <20080627194447.GA34524@phi.local> On Fri, Jun 27, 2008 at 10:02:03AM +0200, Matthias Apitz wrote: > Hello Rui, > > I recompiled the kernel to have if_ath out of the kernel, but as a > loaded module at boot: > > $ kldstat > Id Refs Address Size Name > 1 14 0xc0400000 8c7098 kernel > 2 1 0xc0cc8000 1242c if_ath.ko > 3 3 0xc0cdb000 46324 ath_hal.ko > 4 2 0xc0d22000 4218 ath_rate.ko > 5 1 0xc0d27000 14324 snd_hda.ko > 6 2 0xc0d3c000 4a5ac sound.ko > 7 1 0xc0d87000 6a32c acpi.ko > 8 1 0xc4394000 22000 linux.ko > > I can unload if_ath, ath_hal and ath_rate which drops the interface > ath0, but even in this case Fn+F2 has no affect at all; any idea? Oh, then I guess the 900 is different. > I've had a look into the Xandros Linux and they do it with ACPI events, > dropping the modules and others; I could provide their script > /etc/acpi/wlan.sh if someone wants to have a look into; If turning off WLAN is now done via ACPI events, then the patch I committed to HEAD will probably help. I'll MFC it in a week, but if you can give it a try, that would be great. Please contact me off-list if you need assistance. Regards, -- Rui Paulo From sbruno at miralink.com Fri Jun 27 20:45:09 2008 From: sbruno at miralink.com (Sean Bruno) Date: Fri Jun 27 20:45:12 2008 Subject: Error from systinstall while trying to install man page packages In-Reply-To: <692660060806271325n45a863admbf037c50de9cf266@mail.gmail.com> References: <48654287.4000508@miralink.com> <692660060806271325n45a863admbf037c50de9cf266@mail.gmail.com> Message-ID: <48655154.20709@miralink.com> Sebastian Tymk?w wrote: > Hi, > > You can set information in sysinstall using "Options" and setting > "Release name" > > Best regards, > > Sebastian Tymkow Thanks. What should I set the Release name to? -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Phone 503-621-5143 Fax 503-621-5199 From sclark46 at earthlink.net Fri Jun 27 20:48:20 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Fri Jun 27 21:20:34 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <2e77fc10806221101q684baf47r9ee7208a676f59e@mail.gmail.com> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080622170507.5ac469d2@baby-jane-lamaiziere-net.local> <2e77fc10806221101q684baf47r9ee7208a676f59e@mail.gmail.com> Message-ID: <48654F81.6010500@earthlink.net> Niki Denev wrote: > On Sun, Jun 22, 2008 at 6:05 PM, Patrick Lamaizi?re > wrote: >> Le Fri, 6 Jun 2008 23:41:35 +0200, >> Patrick Lamaizi?re a ?crit : >> >> Hello, >> >>> I'm trying to port the glxsb driver from OpenBSD to FreeBSD 7-STABLE >>> (via the NetBSD port). >>> " The glxsb driver supports the security block of the Geode LX >>> series processors. The Geode LX is a member of the AMD Geode family >>> of integrated x86 system chips. >>> >>> Driven by periodic checks for available data from the generator, >>> glxsb supplies entropy to the random(4) driver for common usage. >>> >>> glxsb also supports acceleration of AES-128-CBC operations for >>> crypto(4)." >> Well, I hope this is the final version. >> >> http://user.lamaiziere.net/patrick/glxsb-220608.tar.gz >> >> I added a patch for FreeBSD 6 but i'am not able to test it. >> >> On 7-STABLE, I've tested with hundred openssl encryptions and some flood >> pings under ipsec in the background. Looks good for me. >> >> If someone can test and review it, it would be cool. >> >> Thanks, Regards. > > It compiles on without a problem on 6.2 and loads on my Soekris > Net5501-70 running pfSense (6.2-RELEASE-p11) > > glxsb0: mem > 0xa0000000-0xa0003fff irq 10 at device 1.2 on pci0 > > Thanks!, > Niki > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > Hi, I am trying to compile it on 6.2 and get make: don't know how to make cryptodev_if.h. Stop ??? where is this file? Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From ndenev at gmail.com Fri Jun 27 21:11:01 2008 From: ndenev at gmail.com (Niki Denev) Date: Fri Jun 27 21:30:53 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <48654F81.6010500@earthlink.net> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080622170507.5ac469d2@baby-jane-lamaiziere-net.local> <2e77fc10806221101q684baf47r9ee7208a676f59e@mail.gmail.com> <48654F81.6010500@earthlink.net> Message-ID: <2e77fc10806271410q3205fb21r9aed15ec8b035401@mail.gmail.com> On Fri, Jun 27, 2008 at 11:37 PM, Stephen Clark wrote: > Hi, > > I am trying to compile it on 6.2 and get > make: don't know how to make cryptodev_if.h. Stop > > ??? > where is this file? > > Thanks, > Steve > Have you applied the 6.2 patch included in the latest tgz that Patrick posted? Regards, Niki From martes at mgwigglesworth.com Fri Jun 27 23:29:37 2008 From: martes at mgwigglesworth.com (Martes Wigglesworth) Date: Fri Jun 27 23:29:42 2008 Subject: Problems with ieee80211 dependencies... Message-ID: <1214609369.15425.19.camel@devstation> I am having a hard time compiling a new kernel when I remove the wireless aspects of the config file. I have removed all options/devices that seem to still require ieee80211 however, I still find that the network section of the compile do not work. I.E. that is where the compile stops, and indicates that an unknown reference to ieee80211 functions... What in the GENERIC config file requires ieee80211? I have included my config file below: cpu I686_CPU ident DATASERVER # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates options UFS_ACL # Support for access control options UFS_DIRHASH # Improve performance on big options UFS_GJOURNAL # options MD_ROOT # MD is a potential root device options PROCFS # Process filesystem options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY options SCSI_DELAY=5000 options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI options AUDIT # Security event auditing # To make an SMP kernel, the next two lines are needed # CPU frequency control device cpufreq # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicam # ATAPI emulation? device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. device ahd options AHD_REG_PRETTY_PRINT # output. Adds ~215k to driver. device amd # AMD 53C974 (Tekram DC-390(T)) device hptiop # Highpoint RocketRaid 3xxx series device isp # Qlogic family #device ispfw device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters device bt # Buslogic/Mylex MultiMaster SCSI adapters device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services # RAID controllers interfaced to the SCSI subsystem # RAID controllers # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. # PCI Ethernet NICs that use the common MII bus controller code. device miibus # MII bus support device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B device xl # 3Com 3c90x # 'device ed' requires 'device miibus' # Wireless NIC cards # Pseudo devices. device loop # Network loopback device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Serial devices device ucom # Generic com ttys device uark # Technologies ARK3116 based serial device ubsa # Belkin F5U103 and compatible serial device ubser # BWCT console serial adapters device uftdi # For FTDI usb serial adapters device uipaq # Some WinCE based devices device uplcom # Prolific PL-2303 serial adapters device uslcom # SI Labs CP2101/CP2102 serial adapters device uvisor # Visor and Palm devices device uvscom # USB serial support for DDI pocket's PHS # USB Ethernet, requires miibus #--------------------------Firewall-Options---------------------------------# options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE options DUMMYNET From yanefbsd at gmail.com Fri Jun 27 23:34:56 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jun 27 23:34:59 2008 Subject: Error from systinstall while trying to install man page packages In-Reply-To: <48655154.20709@miralink.com> References: <48654287.4000508@miralink.com> <692660060806271325n45a863admbf037c50de9cf266@mail.gmail.com> <48655154.20709@miralink.com> Message-ID: <7d6fde3d0806271634r2d3d0ebbmfc791509fbcf01b9@mail.gmail.com> On Fri, Jun 27, 2008 at 1:45 PM, Sean Bruno wrote: > Sebastian Tymk?w wrote: >> >> Hi, >> >> You can set information in sysinstall using "Options" and setting >> "Release name" >> >> Best regards, >> >> Sebastian Tymkow > > Thanks. What should I set the Release name to? According to uname above, 7.0-STABLE (IIRC). Maybe uname -r would show the appropriate value? -Garrett From sbruno at miralink.com Sat Jun 28 00:07:43 2008 From: sbruno at miralink.com (Sean Bruno) Date: Sat Jun 28 00:07:46 2008 Subject: Error from systinstall while trying to install man page packages In-Reply-To: <7d6fde3d0806271634r2d3d0ebbmfc791509fbcf01b9@mail.gmail.com> References: <48654287.4000508@miralink.com> <692660060806271325n45a863admbf037c50de9cf266@mail.gmail.com> <48655154.20709@miralink.com> <7d6fde3d0806271634r2d3d0ebbmfc791509fbcf01b9@mail.gmail.com> Message-ID: <486580CC.8040802@miralink.com> Garrett Cooper wrote: > On Fri, Jun 27, 2008 at 1:45 PM, Sean Bruno wrote: > >> Sebastian Tymk?w wrote: >> >>> Hi, >>> >>> You can set information in sysinstall using "Options" and setting >>> "Release name" >>> >>> Best regards, >>> >>> Sebastian Tymkow >>> >> Thanks. What should I set the Release name to? >> > > According to uname above, 7.0-STABLE (IIRC). Maybe uname -r would show > the appropriate value? > -Garrett > Everything looks fine here as far as I can tell. I still get an error from sysinstall stating that 7.0-STABLE can't be found. Since I rebuilt the kernel from src, should I buildworld on the box and see if that resolves the issue? [sbruno@ophelia ~]$ uname -r 7.0-STABLE [sbruno@ophelia ~]$ uname -a FreeBSD ophelia 7.0-STABLE FreeBSD 7.0-STABLE #9: Fri Jun 27 15:49:54 UTC 2008 sbruno@ophelia:/usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/i386/compile/GENERIC i386 Sean From kip.macy at gmail.com Sat Jun 28 00:08:39 2008 From: kip.macy at gmail.com (Kip Macy) Date: Sat Jun 28 00:08:42 2008 Subject: Problems with ieee80211 dependencies... In-Reply-To: <1214609369.15425.19.camel@devstation> References: <1214609369.15425.19.camel@devstation> Message-ID: Nothing jumps out at me, can you send the output of the build failure? -Kip On Fri, Jun 27, 2008 at 4:29 PM, Martes Wigglesworth wrote: > I am having a hard time compiling a new kernel when I remove the > wireless aspects of the config file. I have removed all options/devices > that seem to still require ieee80211 however, I still find that the > network section of the compile do not work. I.E. that is where the > compile stops, and indicates that an unknown reference to ieee80211 > functions... > > What in the GENERIC config file requires ieee80211? I have included my > config file below: > > cpu I686_CPU > ident DATASERVER > > # To statically compile in device wiring instead of /boot/device.hints > #hints "GENERIC.hints" # Default places to look for > devices. > > makeoptions DEBUG=-g # Build kernel with gdb(1) > > options SCHED_ULE # ULE scheduler > options PREEMPTION # Enable kernel thread > preemption > options INET # InterNETworking > options INET6 # IPv6 communications protocols > options SCTP # Stream Control Transmission > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates > options UFS_ACL # Support for access control > options UFS_DIRHASH # Improve performance on big > options UFS_GJOURNAL # > options MD_ROOT # MD is a potential root device > options PROCFS # Process filesystem > options PSEUDOFS # Pseudo-filesystem framework > options GEOM_PART_GPT # GUID Partition Tables. > options GEOM_LABEL # Provides labelization > options COMPAT_43TTY > options SCSI_DELAY=5000 > options KTRACE # ktrace(1) support > options STACK # stack(9) support > options SYSVSHM # SYSV-style shared memory > options SYSVMSG # SYSV-style message queues > options SYSVSEM # SYSV-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > options ADAPTIVE_GIANT # Giant mutex is adaptive. > options STOP_NMI > options AUDIT # Security event auditing > > # To make an SMP kernel, the next two lines are needed > > # CPU frequency control > device cpufreq > > # Bus support. > device eisa > device pci > > # Floppy drives > device fdc > > # ATA and ATAPI devices > device ata > device atadisk # ATA disk drives > device ataraid # ATA RAID drives > device atapicam # ATAPI emulation? > device atapicd # ATAPI CDROM drives > device atapifd # ATAPI floppy drives > device atapist # ATAPI tape drives > options ATA_STATIC_ID # Static device numbering > > # SCSI Controllers > device ahb # EISA AHA1742 family > device ahc # AHA2940 and onboard AIC7xxx devices > options AHC_REG_PRETTY_PRINT # Print register bitfields in > debug > # output. Adds ~128k to driver. > device ahd > options AHD_REG_PRETTY_PRINT > # output. Adds ~215k to driver. > device amd # AMD 53C974 (Tekram DC-390(T)) > device hptiop # Highpoint RocketRaid 3xxx series > device isp # Qlogic family > #device ispfw > device mpt # LSI-Logic MPT-Fusion > #device ncr # NCR/Symbios Logic > device sym # NCR/Symbios Logic > device trm # Tekram DC395U/UW/F DC315U adapters > > device adv # Advansys SCSI adapters > device adw # Advansys wide SCSI adapters > device aha # Adaptec 154x SCSI adapters > device aic # Adaptec 15[012]x SCSI adapters > device bt # Buslogic/Mylex MultiMaster SCSI > adapters > > device ncv # NCR 53C500 > device nsp # Workbit Ninja SCSI-3 > device stg # TMC 18C30/18C50 > > # SCSI peripherals > device scbus # SCSI bus (required for SCSI) > device ch # SCSI media changers > device da # Direct Access (disks) > device sa # Sequential Access (tape etc) > device cd # CD > device pass # Passthrough device (direct SCSI > access) > device ses # SCSI Environmental Services > > # RAID controllers interfaced to the SCSI subsystem > > # RAID controllers > > # atkbdc0 controls both the keyboard and the PS/2 mouse > device atkbdc # AT keyboard controller > device atkbd # AT keyboard > device psm # PS/2 mouse > > device kbdmux # keyboard multiplexer > > device vga # VGA video card driver > > > # syscons is the default console driver, resembling an SCO console > device sc > > device agp # support several AGP chipsets > > # Add suspend/resume support for the i8254. > device pmtimer > > # PCCARD (PCMCIA) support > # PCMCIA and cardbus bridge support > > # Serial (COM) ports > device sio # 8250, 16[45]50 based serial ports > device uart # Generic UART driver > > # Parallel port > device ppc > device ppbus # Parallel port bus (required) > device lpt # Printer > device plip # TCP/IP over parallel > device ppi # Parallel port interface device > #device vpo # Requires scbus and da > > # If you've got a "dumb" serial or parallel PCI card that is > # supported by the puc(4) glue driver, uncomment the following > # line to enable it (connects to sio, uart and/or ppc drivers): > #device puc > > # PCI Ethernet NICs. > > # PCI Ethernet NICs that use the common MII bus controller code. > device miibus # MII bus support > device dc # DEC/Intel 21143 and various workalikes > device fxp # Intel EtherExpress PRO/100B > device xl # 3Com 3c90x > > # 'device ed' requires 'device miibus' > > # Wireless NIC cards > > # Pseudo devices. > device loop # Network loopback > device sl # Kernel SLIP > device ppp # Kernel PPP > device tun # Packet tunnel. > device pty # Pseudo-ttys (telnet etc) > device md # Memory "disks" > device gif # IPv6 and IPv4 tunneling > device faith # IPv6-to-IPv4 relaying (translation) > device firmware # firmware assist module > > # The `bpf' device enables the Berkeley Packet Filter. > # Be aware of the administrative consequences of enabling this! > # Note that 'bpf' is required for DHCP. > device bpf # Berkeley packet filter > > # USB support > device uhci # UHCI PCI->USB interface > device ohci # OHCI PCI->USB interface > device ehci # EHCI PCI->USB interface (USB 2.0) > device usb # USB Bus (required) > #device udbp # USB Double Bulk Pipe devices > device ugen # Generic > device uhid # "Human Interface Devices" > device ukbd # Keyboard > device ulpt # Printer > device umass # Disks/Mass storage - Requires scbus > and da > device ums # Mouse > device urio # Diamond Rio 500 MP3 player > device uscanner # Scanners > # USB Serial devices > device ucom # Generic com ttys > device uark # Technologies ARK3116 based serial > device ubsa # Belkin F5U103 and compatible serial > device ubser # BWCT console serial adapters > device uftdi # For FTDI usb serial adapters > device uipaq # Some WinCE based devices > device uplcom # Prolific PL-2303 serial adapters > device uslcom # SI Labs CP2101/CP2102 serial adapters > device uvisor # Visor and Palm devices > device uvscom # USB serial support for DDI pocket's > PHS > # USB Ethernet, requires miibus > > #--------------------------Firewall-Options---------------------------------# > options IPFIREWALL > options IPFIREWALL_DEFAULT_TO_ACCEPT > options IPFIREWALL_VERBOSE > options DUMMYNET > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From yanefbsd at gmail.com Sat Jun 28 04:48:13 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Sat Jun 28 04:48:17 2008 Subject: Error from systinstall while trying to install man page packages In-Reply-To: <486580CC.8040802@miralink.com> References: <48654287.4000508@miralink.com> <692660060806271325n45a863admbf037c50de9cf266@mail.gmail.com> <48655154.20709@miralink.com> <7d6fde3d0806271634r2d3d0ebbmfc791509fbcf01b9@mail.gmail.com> <486580CC.8040802@miralink.com> Message-ID: <7d6fde3d0806272148p37bed7acmbbefe82c460b9deb@mail.gmail.com> On Fri, Jun 27, 2008 at 5:07 PM, Sean Bruno wrote: > Garrett Cooper wrote: >> >> On Fri, Jun 27, 2008 at 1:45 PM, Sean Bruno wrote: >> >>> >>> Sebastian Tymk?w wrote: >>> >>>> >>>> Hi, >>>> >>>> You can set information in sysinstall using "Options" and setting >>>> "Release name" >>>> >>>> Best regards, >>>> >>>> Sebastian Tymkow >>>> >>> >>> Thanks. What should I set the Release name to? >>> >> >> According to uname above, 7.0-STABLE (IIRC). Maybe uname -r would show >> the appropriate value? >> -Garrett >> > > Everything looks fine here as far as I can tell. I still get an error from > sysinstall stating that 7.0-STABLE can't be found. Since I rebuilt the > kernel from src, should I buildworld on the box and see if that resolves the > issue? > > > [sbruno@ophelia ~]$ uname -r > 7.0-STABLE > [sbruno@ophelia ~]$ uname -a > FreeBSD ophelia 7.0-STABLE FreeBSD 7.0-STABLE #9: Fri Jun 27 15:49:54 UTC > 2008 > sbruno@ophelia:/usr/home/sbruno/FreeBSD_RELENG_7_15APR08/src/sys/i386/compile/GENERIC > i386 If you're installing from the net, and don't already have the manpages, I'd do 7.0-RELEASE (or whatever it's labeled as for the release copy). If you already have the manpages and you have the source, cd /usr/src && make maninstall should do the trick. Cheers, -Garrett From yanefbsd at gmail.com Sat Jun 28 05:40:12 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Sat Jun 28 05:40:16 2008 Subject: Debugging kernel issue with bus code Message-ID: <7d6fde3d0806272240qdb16e5fh557ed9896b60920e@mail.gmail.com> Hi all, Due to my RAID5 array failing and my poking around trying to get stuff to work, I've come up with a deterministic means of getting the kernel to panic when it attempts to use generic_bcopy in device_attach. Unfortunately my x86 ASM is non-existent and while I'm a passable gdb user, I have not the faintest clue about how to debug the issue in ddb. So, I was wondering if anyone was willing to help me debug the issue... Thanks, -Garrett From martes at mgwigglesworth.com Sat Jun 28 10:22:05 2008 From: martes at mgwigglesworth.com (Martes Wigglesworth) Date: Sat Jun 28 10:22:09 2008 Subject: [Fwd: Re: Problems with ieee80211 dependencies...] Message-ID: <1214648519.15425.40.camel@devstation> I had to wait for the rebuild process to error out again, however, here is the resulting segment of output. I included the parts that begin to indicates an error. kdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/src/sys/i386/compile/DATASERVER /usr/src/sys/modules/zyd/../../dev/usb/if_zyd.c linking kernel.debug if_dc.o(.text+0x955): In function `dc_mchash_le': ../../../dev/dc/if_dc.c:1019: undefined reference to `ether_crc32_le' if_dc.o(.text+0x9f2): In function `dc_mchash_be': ../../../dev/dc/if_dc.c:1054: undefined reference to `ether_crc32_be' if_dc.o(.text+0x1df5): In function `dc_detach': ../../../dev/dc/if_dc.c:2320: undefined reference to `ether_ifdetach' if_dc.o(.text+0x42d7): In function `dc_ioctl': ../../../dev/dc/if_dc.c:3632: undefined reference to `ether_ioctl' if_dc.o(.text+0x65a5): In function `dc_attach': ../../../dev/dc/if_dc.c:2270: undefined reference to `ether_ifattach' if_dc.o(.text+0x65fc):../../../dev/dc/if_dc.c:2278: undefined reference to `ether_ifdetach' if_fxp.o(.text+0x2086): In function `fxp_detach': ../../../dev/fxp/if_fxp.c:919: undefined reference to `ether_ifdetach' if_fxp.o(.text+0x2402): In function `fxp_ioctl': ../../../dev/fxp/if_fxp.c:2467: undefined reference to `ether_ioctl' if_fxp.o(.text+0x429f): In function `fxp_attach': ../../../dev/fxp/if_fxp.c:789: undefined reference to `ether_ifattach' if_fxp.o(.text+0x431b):../../../dev/fxp/if_fxp.c:815: undefined reference to `ether_ifdetach' if.o(.text+0x1027): In function `if_setlladdr': ../../../net/if.c:2646: undefined reference to `arp_ifinit' if_gif.o(.text+0x941): In function `gif_input': ../../../net/if_gif.c:560: undefined reference to `bridge_input_p' if_gif.o(.text+0x95b):../../../net/if_gif.c:567: undefined reference to `ether_demux' ip_dummynet.o(.text+0x14db): In function `dummynet_send': ../../../netinet/ip_dummynet.c:908: undefined reference to `bridge_dn_p' ip_dummynet.o(.text+0x153b):../../../netinet/ip_dummynet.c:926: undefined reference to `ether_demux' ip_dummynet.o(.text+0x154c):../../../netinet/ip_dummynet.c:929: undefined reference to `ether_output_frame' if_xl.o(.text+0x2078): In function `xl_setmulti_hash': ../../../pci/if_xl.c:789: undefined reference to `ether_crc32_be' if_xl.o(.text+0x38f6): In function `xl_detach': ../../../pci/if_xl.c:1674: undefined reference to `ether_ifdetach' if_xl.o(.text+0x4712): In function `xl_ioctl': ../../../pci/if_xl.c:3203: undefined reference to `ether_ioctl' if_xl.o(.text+0x591d): In function `xl_attach': ../../../pci/if_xl.c:1564: undefined reference to `ether_ifattach' if_xl.o(.text+0x5970):../../../pci/if_xl.c:1570: undefined reference to `ether_ifdetach' *** Error code 1 Stop in /usr/src/sys/i386/compile/DATASERVER. >Nothing jumps out at me, can you send the output of the build failure? > >-Kip > >On Fri, Jun 27, 2008 at 4:29 PM, Martes Wigglesworth > wrote: > I am having a hard time compiling a new kernel when I remove the > wireless aspects of the config file. I have removed all options/devices > that seem to still require ieee80211 however, I still find that the > network section of the compile do not work. I.E. that is where the > compile stops, and indicates that an unknown reference to ieee80211 > functions... > > What in the GENERIC config file requires ieee80211? I have included my > config file below: > > cpu I686_CPU > ident DATASERVER > > # To statically compile in device wiring instead of /boot/device.hints > #hints "GENERIC.hints" # Default places to look for > devices. > > makeoptions DEBUG=-g # Build kernel with gdb(1) > > options SCHED_ULE # ULE scheduler > options PREEMPTION # Enable kernel thread > preemption > options INET # InterNETworking > options INET6 # IPv6 communications protocols > options SCTP # Stream Control Transmission > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates > options UFS_ACL # Support for access control > options UFS_DIRHASH # Improve performance on big > options UFS_GJOURNAL # > options MD_ROOT # MD is a potential root device > options PROCFS # Process filesystem > options PSEUDOFS # Pseudo-filesystem framework > options GEOM_PART_GPT # GUID Partition Tables. > options GEOM_LABEL # Provides labelization > options COMPAT_43TTY > options SCSI_DELAY=5000 > options KTRACE # ktrace(1) support > options STACK # stack(9) support > options SYSVSHM # SYSV-style shared memory > options SYSVMSG # SYSV-style message queues > options SYSVSEM # SYSV-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > options ADAPTIVE_GIANT # Giant mutex is adaptive. > options STOP_NMI > options AUDIT # Security event auditing > > # To make an SMP kernel, the next two lines are needed > > # CPU frequency control > device cpufreq > > # Bus support. > device eisa > device pci > > # Floppy drives > device fdc > > # ATA and ATAPI devices > device ata > device atadisk # ATA disk drives > device ataraid # ATA RAID drives > device atapicam # ATAPI emulation? > device atapicd # ATAPI CDROM drives > device atapifd # ATAPI floppy drives > device atapist # ATAPI tape drives > options ATA_STATIC_ID # Static device numbering > > # SCSI Controllers > device ahb # EISA AHA1742 family > device ahc # AHA2940 and onboard AIC7xxx devices > options AHC_REG_PRETTY_PRINT # Print register bitfields in > debug > # output. Adds ~128k to driver. > device ahd > options AHD_REG_PRETTY_PRINT > # output. Adds ~215k to driver. > device amd # AMD 53C974 (Tekram DC-390(T)) > device hptiop # Highpoint RocketRaid 3xxx series > device isp # Qlogic family > #device ispfw > device mpt # LSI-Logic MPT-Fusion > #device ncr # NCR/Symbios Logic > device sym # NCR/Symbios Logic > device trm # Tekram DC395U/UW/F DC315U adapters > > device adv # Advansys SCSI adapters > device adw # Advansys wide SCSI adapters > device aha # Adaptec 154x SCSI adapters > device aic # Adaptec 15[012]x SCSI adapters > device bt # Buslogic/Mylex MultiMaster SCSI > adapters > > device ncv # NCR 53C500 > device nsp # Workbit Ninja SCSI-3 > device stg # TMC 18C30/18C50 > > # SCSI peripherals > device scbus # SCSI bus (required for SCSI) > device ch # SCSI media changers > device da # Direct Access (disks) > device sa # Sequential Access (tape etc) > device cd # CD > device pass # Passthrough device (direct SCSI > access) > device ses # SCSI Environmental Services > > # RAID controllers interfaced to the SCSI subsystem > > # RAID controllers > > # atkbdc0 controls both the keyboard and the PS/2 mouse > device atkbdc # AT keyboard controller > device atkbd # AT keyboard > device psm # PS/2 mouse > > device kbdmux # keyboard multiplexer > > device vga # VGA video card driver > > > # syscons is the default console driver, resembling an SCO console > device sc > > device agp # support several AGP chipsets > > # Add suspend/resume support for the i8254. > device pmtimer > > # PCCARD (PCMCIA) support > # PCMCIA and cardbus bridge support > > # Serial (COM) ports > device sio # 8250, 16[45]50 based serial ports > device uart # Generic UART driver > > # Parallel port > device ppc > device ppbus # Parallel port bus (required) > device lpt # Printer > device plip # TCP/IP over parallel > device ppi # Parallel port interface device > #device vpo # Requires scbus and da > > # If you've got a "dumb" serial or parallel PCI card that is > # supported by the puc(4) glue driver, uncomment the following > # line to enable it (connects to sio, uart and/or ppc drivers): > #device puc > > # PCI Ethernet NICs. > > # PCI Ethernet NICs that use the common MII bus controller code. > device miibus # MII bus support > device dc # DEC/Intel 21143 > device fxp # Intel EtherExpress PRO/100B > device xl # 3Com 3c90x > > # 'device ed' requires 'device miibus' > > # Wireless NIC cards > > # Pseudo devices. > device loop # Network loopback > device sl # Kernel SLIP > device ppp # Kernel PPP > device tun # Packet tunnel. > device pty # Pseudo-ttys (telnet etc) > device md # Memory "disks" > device gif # IPv6 and IPv4 tunneling > device faith # IPv6-to-IPv4 relaying (translation) > device firmware # firmware assist module > > # The `bpf' device enables the Berkeley Packet Filter. > # Be aware of the administrative consequences of enabling this! > # Note that 'bpf' is required for DHCP. > device bpf # Berkeley packet filter > > # USB support > device uhci # UHCI PCI->USB interface > device ohci # OHCI PCI->USB interface > device ehci # EHCI PCI->USB interface (USB 2.0) > device usb # USB Bus (required) > #device udbp # USB Double Bulk Pipe devices > device ugen # Generic > device uhid # "Human Interface Devices" > device ukbd # Keyboard > device ulpt # Printer > device umass # Disks/Mass storage - Requires scbus > and da > device ums # Mouse > device urio # Diamond Rio 500 MP3 player > device uscanner # Scanners > # USB Serial devices > device ucom # Generic com ttys > device uark # Technologies ARK3116 based serial > device ubsa # Belkin F5U103 and compatible serial > device ubser # BWCT console serial adapters > device uftdi # For FTDI usb serial adapters > device uipaq # Some WinCE based devices > device uplcom # Prolific PL-2303 serial adapters > device uslcom # SI Labs CP2101/CP2102 serial adapters > device uvisor # Visor and Palm devices > device uvscom # USB serial support for DDI pocket's > PHS > # USB Ethernet, requires miibus > > #--------------------------Firewall-Options---------------------------------# > options IPFIREWALL > options IPFIREWALL_DEFAULT_TO_ACCEPT > options IPFIREWALL_VERBOSE > options DUMMYNET From onemda at gmail.com Sat Jun 28 14:23:04 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Sat Jun 28 14:23:27 2008 Subject: [Fwd: Re: Problems with ieee80211 dependencies...] In-Reply-To: <1214648519.15425.40.camel@devstation> References: <1214648519.15425.40.camel@devstation> Message-ID: <3a142e750806280723u34e3ed7fid24c5086e9c15a9a@mail.gmail.com> I dont have such problem with CURRENT; all ieee80211 stuff are build as modules for me, but my conf is different, firewalls and dummynet are build as modules. But I was able to reproduce problem with your config file. Probably conflict arise somewhere within your last 4 lines in conf file. On 6/28/08, Martes Wigglesworth wrote: > > I had to wait for the rebuild process to error out again, however, here > is the resulting segment of output. > > I included the parts that begin to indicates an error. > > > kdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE > -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq > -I/usr/src/sys/i386/compile/DATASERVER > /usr/src/sys/modules/zyd/../../dev/usb/if_zyd.c > linking kernel.debug > if_dc.o(.text+0x955): In function `dc_mchash_le': > ../../../dev/dc/if_dc.c:1019: undefined reference to `ether_crc32_le' > if_dc.o(.text+0x9f2): In function `dc_mchash_be': > ../../../dev/dc/if_dc.c:1054: undefined reference to `ether_crc32_be' > if_dc.o(.text+0x1df5): In function `dc_detach': > ../../../dev/dc/if_dc.c:2320: undefined reference to `ether_ifdetach' > if_dc.o(.text+0x42d7): In function `dc_ioctl': > ../../../dev/dc/if_dc.c:3632: undefined reference to `ether_ioctl' > if_dc.o(.text+0x65a5): In function `dc_attach': > ../../../dev/dc/if_dc.c:2270: undefined reference to `ether_ifattach' > if_dc.o(.text+0x65fc):../../../dev/dc/if_dc.c:2278: undefined reference > to `ether_ifdetach' > if_fxp.o(.text+0x2086): In function `fxp_detach': > ../../../dev/fxp/if_fxp.c:919: undefined reference to `ether_ifdetach' > if_fxp.o(.text+0x2402): In function `fxp_ioctl': > ../../../dev/fxp/if_fxp.c:2467: undefined reference to `ether_ioctl' > if_fxp.o(.text+0x429f): In function `fxp_attach': > ../../../dev/fxp/if_fxp.c:789: undefined reference to `ether_ifattach' > if_fxp.o(.text+0x431b):../../../dev/fxp/if_fxp.c:815: undefined > reference to `ether_ifdetach' > if.o(.text+0x1027): In function `if_setlladdr': > ../../../net/if.c:2646: undefined reference to `arp_ifinit' > if_gif.o(.text+0x941): In function `gif_input': > ../../../net/if_gif.c:560: undefined reference to `bridge_input_p' > if_gif.o(.text+0x95b):../../../net/if_gif.c:567: undefined reference to > `ether_demux' > ip_dummynet.o(.text+0x14db): In function `dummynet_send': > ../../../netinet/ip_dummynet.c:908: undefined reference to `bridge_dn_p' > ip_dummynet.o(.text+0x153b):../../../netinet/ip_dummynet.c:926: > undefined reference to `ether_demux' > ip_dummynet.o(.text+0x154c):../../../netinet/ip_dummynet.c:929: > undefined reference to `ether_output_frame' > if_xl.o(.text+0x2078): In function `xl_setmulti_hash': > ../../../pci/if_xl.c:789: undefined reference to `ether_crc32_be' > if_xl.o(.text+0x38f6): In function `xl_detach': > ../../../pci/if_xl.c:1674: undefined reference to `ether_ifdetach' > if_xl.o(.text+0x4712): In function `xl_ioctl': > ../../../pci/if_xl.c:3203: undefined reference to `ether_ioctl' > if_xl.o(.text+0x591d): In function `xl_attach': > ../../../pci/if_xl.c:1564: undefined reference to `ether_ifattach' > if_xl.o(.text+0x5970):../../../pci/if_xl.c:1570: undefined reference to > `ether_ifdetach' > *** Error code 1 > > Stop in /usr/src/sys/i386/compile/DATASERVER. > > >>Nothing jumps out at me, can you send the output of the build failure? >> >>-Kip >> >>On Fri, Jun 27, 2008 at 4:29 PM, Martes Wigglesworth >> wrote: >> I am having a hard time compiling a new kernel when I remove the >> wireless aspects of the config file. I have removed all > options/devices >> that seem to still require ieee80211 however, I still find that the >> network section of the compile do not work. I.E. that is where the >> compile stops, and indicates that an unknown reference to ieee80211 >> functions... >> >> What in the GENERIC config file requires ieee80211? I have included my >> config file below: >> >> cpu I686_CPU >> ident DATASERVER >> >> # To statically compile in device wiring instead of /boot/device.hints >> #hints "GENERIC.hints" # Default places to look for >> devices. >> >> makeoptions DEBUG=-g # Build kernel with gdb(1) >> >> options SCHED_ULE # ULE scheduler >> options PREEMPTION # Enable kernel thread >> preemption >> options INET # InterNETworking >> options INET6 # IPv6 communications > protocols >> options SCTP # Stream Control Transmission >> options FFS # Berkeley Fast Filesystem >> options SOFTUPDATES # Enable FFS soft updates >> options UFS_ACL # Support for access control >> options UFS_DIRHASH # Improve performance on big >> options UFS_GJOURNAL # >> options MD_ROOT # MD is a potential root > device >> options PROCFS # Process filesystem >> options PSEUDOFS # Pseudo-filesystem framework >> options GEOM_PART_GPT # GUID Partition Tables. >> options GEOM_LABEL # Provides labelization >> options COMPAT_43TTY >> options SCSI_DELAY=5000 >> options KTRACE # ktrace(1) support >> options STACK # stack(9) support >> options SYSVSHM # SYSV-style shared memory >> options SYSVMSG # SYSV-style message queues >> options SYSVSEM # SYSV-style semaphores >> options _KPOSIX_PRIORITY_SCHEDULING >> options KBD_INSTALL_CDEV # install a CDEV entry in /dev >> options ADAPTIVE_GIANT # Giant mutex is adaptive. >> options STOP_NMI >> options AUDIT # Security event auditing >> >> # To make an SMP kernel, the next two lines are needed >> >> # CPU frequency control >> device cpufreq >> >> # Bus support. >> device eisa >> device pci >> >> # Floppy drives >> device fdc >> >> # ATA and ATAPI devices >> device ata >> device atadisk # ATA disk drives >> device ataraid # ATA RAID drives >> device atapicam # ATAPI emulation? >> device atapicd # ATAPI CDROM drives >> device atapifd # ATAPI floppy drives >> device atapist # ATAPI tape drives >> options ATA_STATIC_ID # Static device numbering >> >> # SCSI Controllers >> device ahb # EISA AHA1742 family >> device ahc # AHA2940 and onboard AIC7xxx devices >> options AHC_REG_PRETTY_PRINT # Print register bitfields in >> debug >> # output. Adds ~128k to > driver. >> device ahd >> options AHD_REG_PRETTY_PRINT >> # output. Adds ~215k to > driver. >> device amd # AMD 53C974 (Tekram DC-390(T)) >> device hptiop # Highpoint RocketRaid 3xxx series >> device isp # Qlogic family >> #device ispfw >> device mpt # LSI-Logic MPT-Fusion >> #device ncr # NCR/Symbios Logic >> device sym # NCR/Symbios Logic >> device trm # Tekram DC395U/UW/F DC315U adapters >> >> device adv # Advansys SCSI adapters >> device adw # Advansys wide SCSI adapters >> device aha # Adaptec 154x SCSI adapters >> device aic # Adaptec 15[012]x SCSI adapters >> device bt # Buslogic/Mylex MultiMaster SCSI >> adapters >> >> device ncv # NCR 53C500 >> device nsp # Workbit Ninja SCSI-3 >> device stg # TMC 18C30/18C50 >> >> # SCSI peripherals >> device scbus # SCSI bus (required for SCSI) >> device ch # SCSI media changers >> device da # Direct Access (disks) >> device sa # Sequential Access (tape etc) >> device cd # CD >> device pass # Passthrough device (direct SCSI >> access) >> device ses # SCSI Environmental Services >> >> # RAID controllers interfaced to the SCSI subsystem >> >> # RAID controllers >> >> # atkbdc0 controls both the keyboard and the PS/2 mouse >> device atkbdc # AT keyboard controller >> device atkbd # AT keyboard >> device psm # PS/2 mouse >> >> device kbdmux # keyboard multiplexer >> >> device vga # VGA video card driver >> >> >> # syscons is the default console driver, resembling an SCO console >> device sc >> >> device agp # support several AGP chipsets >> >> # Add suspend/resume support for the i8254. >> device pmtimer >> >> # PCCARD (PCMCIA) support >> # PCMCIA and cardbus bridge support >> >> # Serial (COM) ports >> device sio # 8250, 16[45]50 based serial ports >> device uart # Generic UART driver >> >> # Parallel port >> device ppc >> device ppbus # Parallel port bus (required) >> device lpt # Printer >> device plip # TCP/IP over parallel >> device ppi # Parallel port interface device >> #device vpo # Requires scbus and da >> >> # If you've got a "dumb" serial or parallel PCI card that is >> # supported by the puc(4) glue driver, uncomment the following >> # line to enable it (connects to sio, uart and/or ppc drivers): >> #device puc >> >> # PCI Ethernet NICs. >> >> # PCI Ethernet NICs that use the common MII bus controller code. >> device miibus # MII bus support >> device dc # DEC/Intel 21143 >> device fxp # Intel EtherExpress PRO/100B >> device xl # 3Com 3c90x >> >> # 'device ed' requires 'device miibus' >> >> # Wireless NIC cards >> >> # Pseudo devices. >> device loop # Network loopback >> device sl # Kernel SLIP >> device ppp # Kernel PPP >> device tun # Packet tunnel. >> device pty # Pseudo-ttys (telnet etc) >> device md # Memory "disks" >> device gif # IPv6 and IPv4 tunneling >> device faith # IPv6-to-IPv4 relaying (translation) >> device firmware # firmware assist module >> >> # The `bpf' device enables the Berkeley Packet Filter. >> # Be aware of the administrative consequences of enabling this! >> # Note that 'bpf' is required for DHCP. >> device bpf # Berkeley packet filter >> >> # USB support >> device uhci # UHCI PCI->USB interface >> device ohci # OHCI PCI->USB interface >> device ehci # EHCI PCI->USB interface (USB 2.0) >> device usb # USB Bus (required) >> #device udbp # USB Double Bulk Pipe devices >> device ugen # Generic >> device uhid # "Human Interface Devices" >> device ukbd # Keyboard >> device ulpt # Printer >> device umass # Disks/Mass storage - Requires scbus >> and da >> device ums # Mouse >> device urio # Diamond Rio 500 MP3 player >> device uscanner # Scanners >> # USB Serial devices >> device ucom # Generic com ttys >> device uark # Technologies ARK3116 based serial >> device ubsa # Belkin F5U103 and compatible serial >> device ubser # BWCT console serial adapters >> device uftdi # For FTDI usb serial adapters >> device uipaq # Some WinCE based devices >> device uplcom # Prolific PL-2303 serial adapters >> device uslcom # SI Labs CP2101/CP2102 serial > adapters >> device uvisor # Visor and Palm devices >> device uvscom # USB serial support for DDI pocket's >> PHS >> # USB Ethernet, requires miibus >> >> > #--------------------------Firewall-Options---------------------------------# >> options IPFIREWALL >> options IPFIREWALL_DEFAULT_TO_ACCEPT >> options IPFIREWALL_VERBOSE >> options DUMMYNET > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From ivoras at freebsd.org Sat Jun 28 17:02:28 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Sat Jun 28 17:02:32 2008 Subject: Software floating point library? In-Reply-To: <9bbcef730806280643h7c77d9bbo644a42752e1f59a5@mail.gmail.com> References: <9bbcef730806280643h7c77d9bbo644a42752e1f59a5@mail.gmail.com> Message-ID: <9bbcef730806280936y1e669a91t2817ba7ca1de22f3@mail.gmail.com> Does anyone know of a simple, BSD (or compatible) licensed software math library that emulates floating point numbers? Ideally, it should be a single .c file library that implements basic operations (+, -, *, /, negation, comparisons, convert to/from machine integers and strings), that uses a standard C type (int or long long) to store the value, and is usable in the kernel. Alternatively, how about a fixed-point library with the same properties? (I know it's easy to do, but don't want to reinvent the wheel again if I don't have to). Please disregard my earlier message on this subject, if you received it. From dfeustel at mindspring.com Sat Jun 28 18:04:37 2008 From: dfeustel at mindspring.com (dfeustel@mindspring.com) Date: Sat Jun 28 18:04:40 2008 Subject: Software floating point library? In-Reply-To: <9bbcef730806280936y1e669a91t2817ba7ca1de22f3@mail.gmail.com> Message-ID: <20080628180436.AB2158FC12@mx1.freebsd.org> On Sat, Jun 28, 2008 at 06:36:34PM +0200, Ivan Voras wrote: > Does anyone know of a simple, BSD (or compatible) licensed software > math library that emulates floating point numbers? Ideally, it should > be a single .c file library that implements basic operations (+, -, *, > /, negation, comparisons, convert to/from machine integers and > strings), that uses a standard C type (int or long long) to store the > value, and is usable in the kernel. > > Alternatively, how about a fixed-point library with the same > properties? (I know it's easy to do, but don't want to reinvent the > wheel again if I don't have to). > If you don't mind having unlimited precision, check out the math library used in the calc program from isthe.com. USING THE ARBITRARY PRECISION ROUTINES IN A C PROGRAM Part of the calc release consists of an arbitrary precision math link library. This link library is used by the calc program to perform its own calculations. If you wish, you can ignore the calc program entirely and call the arbitrary precision math routines from your own C programs. The link library is called libcalc.a, and provides routines to handle arbitrary precision arithmetic with integers, rational numbers, or complex numbers. There are also many numeric functions such as factorial and gcd, along with some transcendental functions such as sin and exp. Take a look at the sample sub-directory. It contains a few simple examples of how to use libcalc.a that might be helpful to look at after you have read this file. From pfgshield-freebsd at yahoo.com Sat Jun 28 18:01:31 2008 From: pfgshield-freebsd at yahoo.com (pfgshield-freebsd@yahoo.com) Date: Sat Jun 28 19:34:39 2008 Subject: Software floating point library? Message-ID: <367728.80150.qm@web32701.mail.mud.yahoo.com> Hi; I am sure NetBSD ported some variant of it but here is softfloat: http://www.jhauser.us/arithmetic/SoftFloat.html cheers, Pedro. Hai un indirizzo email difficile da ricordare? Scegli quello che hai sempre desiderato su Yahoo! Mail http://it.docs.yahoo.com/nuovo_indirizzo.html From mwm-keyword-freebsdhackers2.e313df at mired.org Sat Jun 28 23:42:45 2008 From: mwm-keyword-freebsdhackers2.e313df at mired.org (Mike Meyer) Date: Sat Jun 28 23:42:48 2008 Subject: Custom VESA modes on FreeBSD 7? Message-ID: <20080628191533.367ad223@bhuda.mired.org> I'm trying to get FreeBSD 7-RELEASE running in a VirtualBox VM to use all of my LCD panel in X. The running X is using the vesa driver, which should be cool for this, as VirtualBox has provisions for creating custom vesa modes. And in fact, the Xorg.0.log file shows that it sees the new mode - but it doesn't use it. The VirtualBox docs note that for Linux to use such a mode, you have to provide a "vga" command line option with the new mode # in it to the linux kernel. None of the FreeBSD boot parameters seem applicable here. Basically, the question is - what do I have to do to get the X.org vesa driver to use a non-standard vesa mode on FreeBSD? Is there any other information I can attach that might help with this? thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From mateev at cns-consulting.org Sun Jun 29 01:14:35 2008 From: mateev at cns-consulting.org (Ivaylo Mateev) Date: Sun Jun 29 01:14:40 2008 Subject: Securelevels Message-ID: <200806290313.21720.mateev@cns-consulting.org> Hi, I think I found a bug. [strato@darkstar /usr/home/strato]$ sudo sysctl kern.securelevel kern.securelevel: 2 [strato@darkstar /usr/home/strato]$ kgdb kgdb: /dev/mem: Permission denied [strato@darkstar /usr/home/strato]$ sudo kgdb [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] I am running in securelevel 2. That means nithing can have direct access to /dev/mem, acording to man security: 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted file systems, /dev/mem and /dev/kmem may not be opened for writing; /dev/io (if your platform has it) may not be opened at all; kernel modules (see kld(4)) may not be loaded or unloaded. 2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with file systems by unmounting them, but also inhibits running newfs(8) while the system is multi- user. So is this a bug or I am just to stupid? From yanefbsd at gmail.com Sun Jun 29 03:06:19 2008 From: yanefbsd at gmail.com (Garrett Cooper) Date: Sun Jun 29 03:06:24 2008 Subject: Securelevels In-Reply-To: <200806290313.21720.mateev@cns-consulting.org> References: <200806290313.21720.mateev@cns-consulting.org> Message-ID: <7d6fde3d0806282006i215be603m5ec90709c2921037@mail.gmail.com> On Sat, Jun 28, 2008 at 6:13 PM, Ivaylo Mateev wrote: > Hi, > > I think I found a bug. > > [strato@darkstar /usr/home/strato]$ sudo sysctl kern.securelevel > kern.securelevel: 2 > [strato@darkstar /usr/home/strato]$ kgdb > kgdb: /dev/mem: Permission denied > [strato@darkstar /usr/home/strato]$ sudo kgdb > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: > Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > > I am running in securelevel 2. That means nithing can have direct access > to /dev/mem, acording to man security: > > 1 Secure mode - the system immutable and system append-only flags may > not be turned off; disks for mounted file systems, /dev/mem and > /dev/kmem may not be opened for writing; /dev/io (if your platform > has it) may not be opened at all; kernel modules (see kld(4)) may > not be loaded or unloaded. > > 2 Highly secure mode - same as secure mode, plus disks may not be > opened for writing (except by mount(2)) whether mounted or not. > This level precludes tampering with file systems by unmounting > them, but also inhibits running newfs(8) while the system is multi- > user. > > So is this a bug or I am just to stupid? Same thing with su? In some situations sudo doesn't operate under 100% root-credentials. -Garrett From dnelson at allantgroup.com Sun Jun 29 04:47:10 2008 From: dnelson at allantgroup.com (Dan Nelson) Date: Sun Jun 29 04:47:13 2008 Subject: Securelevels In-Reply-To: <200806290313.21720.mateev@cns-consulting.org> References: <200806290313.21720.mateev@cns-consulting.org> Message-ID: <20080629044709.GA76555@dan.emsphone.com> In the last episode (Jun 29), Ivaylo Mateev said: > I think I found a bug. > > [strato@darkstar /usr/home/strato]$ sudo sysctl kern.securelevel > kern.securelevel: 2 > [strato@darkstar /usr/home/strato]$ kgdb > kgdb: /dev/mem: Permission denied > [strato@darkstar /usr/home/strato]$ sudo kgdb > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: > Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > > I am running in securelevel 2. That means nithing can have direct access > to /dev/mem, acording to man security: > > 1 Secure mode - the system immutable and system append-only flags may > not be turned off; disks for mounted file systems, /dev/mem and > /dev/kmem may not be opened for writing; /dev/io (if your platform > has it) may not be opened at all; kernel modules (see kld(4)) may > not be loaded or unloaded. > > 2 Highly secure mode - same as secure mode, plus disks may not be > opened for writing (except by mount(2)) whether mounted or not. > This level precludes tampering with file systems by unmounting > them, but also inhibits running newfs(8) while the system is multi- > user. # truss kgdb < /dev/null |& grep /dev/mem open("/dev/mem",O_RDONLY,00) = 4 (0x4) # Read-only opens of /dev/mem are allowed. "kgdb -w" should fail, however. -- Dan Nelson dnelson@allantgroup.com From perryh at pluto.rain.com Sun Jun 29 05:29:35 2008 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Sun Jun 29 05:29:53 2008 Subject: Securelevels In-Reply-To: <200806290313.21720.mateev@cns-consulting.org> References: <200806290313.21720.mateev@cns-consulting.org> Message-ID: <48671600./haUiSgeAdIdCnzZ%perryh@pluto.rain.com> > [strato@darkstar /usr/home/strato]$ sudo sysctl kern.securelevel > kern.securelevel: 2 > [strato@darkstar /usr/home/strato]$ kgdb > kgdb: /dev/mem: Permission denied > [strato@darkstar /usr/home/strato]$ sudo kgdb > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: > Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > > I am running in securelevel 2. That means nithing can have direct > access to /dev/mem, acording to man security: > > 1 Secure mode - ... /dev/mem and /dev/kmem may not be opened > for writing; ... ^^^^^^^^^^^ > > 2 Highly secure mode - same as secure mode, plus disks may not > be opened for writing (except by mount(2)) whether mounted > or not ... > > So is this a bug I don't think so, because kgdb does not ordinarily need to open /dev/kmem for writing. Presumably you'd get an error if you tried to patch the running kernel. From danny at cs.huji.ac.il Sun Jun 29 07:18:41 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Sun Jun 29 07:18:46 2008 Subject: WITHOUT_INSTALLLIB blues Message-ID: hi, when setting WITHOUT_INSTALLLIB, make buildworld breaks with make: don't know how to make /r+d/obj/sunfire/alix/i386/r+d/7.0/src/tmp/legacy/ usr/lib/libegacy.a. Stop danny From imp at bsdimp.com Sun Jun 29 07:44:57 2008 From: imp at bsdimp.com (Warner Losh) Date: Sun Jun 29 07:45:01 2008 Subject: WITHOUT_INSTALLLIB blues In-Reply-To: References: Message-ID: <20080629.014211.74670684.imp@bsdimp.com> > when setting WITHOUT_INSTALLLIB, make buildworld breaks with > make: don't know how to make /r+d/obj/sunfire/alix/i386/r+d/7.0/src/tmp/legacy/ > usr/lib/libegacy.a. Stop Only set it for installworld. Warner From danny at cs.huji.ac.il Sun Jun 29 08:45:33 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Sun Jun 29 08:45:38 2008 Subject: WITHOUT_INSTALLLIB blues In-Reply-To: Your message of Sun, 29 Jun 2008 01:42:11 -0600 (MDT) . Message-ID: > > when setting WITHOUT_INSTALLLIB, make buildworld breaks with > > make: don't know how to make /r+d/obj/sunfire/alix/i386/r+d/7.0/src/tmp/legacy/ > > usr/lib/libegacy.a. Stop > > Only set it for installworld. > thanks, I noticed that, but was wondering if I could save some compile time, but at 13min. I shouldn't be so pedantic :-) cheers, danny From ru at freebsd.org Sun Jun 29 10:25:10 2008 From: ru at freebsd.org (Ruslan Ermilov) Date: Sun Jun 29 10:25:15 2008 Subject: WITHOUT_INSTALLLIB blues In-Reply-To: <20080629.014211.74670684.imp@bsdimp.com> References: <20080629.014211.74670684.imp@bsdimp.com> Message-ID: <20080629100414.GB57827@edoofus.dev.vega.ru> On Sun, Jun 29, 2008 at 01:42:11AM -0600, Warner Losh wrote: > > when setting WITHOUT_INSTALLLIB, make buildworld breaks with > > make: don't know how to make /r+d/obj/sunfire/alix/i386/r+d/7.0/src/tmp/legacy/ > > usr/lib/libegacy.a. Stop > > Only set it for installworld. > *nods* -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From guru at unixarea.de Sun Jun 29 16:09:08 2008 From: guru at unixarea.de (Matthias Apitz) Date: Sun Jun 29 16:09:11 2008 Subject: eeePC 900 && turning off wireless (ath0) In-Reply-To: <20080627194447.GA34524@phi.local> References: <20080626075545.GA2964@rebelion.Sisis.de> <20080626231603.GC6875@phi.local> <20080627080203.GA19602@rebelion.Sisis.de> <20080627194447.GA34524@phi.local> Message-ID: <20080629160527.GA17075@rebelion.Sisis.de> El d?a Friday, June 27, 2008 a las 08:44:47PM +0100, Rui Paulo escribi?: > On Fri, Jun 27, 2008 at 10:02:03AM +0200, Matthias Apitz wrote: > > Hello Rui, > > > > I recompiled the kernel to have if_ath out of the kernel, but as a > > loaded module at boot: > > > > $ kldstat > > Id Refs Address Size Name > > 1 14 0xc0400000 8c7098 kernel > > 2 1 0xc0cc8000 1242c if_ath.ko > > 3 3 0xc0cdb000 46324 ath_hal.ko > > 4 2 0xc0d22000 4218 ath_rate.ko > > 5 1 0xc0d27000 14324 snd_hda.ko > > 6 2 0xc0d3c000 4a5ac sound.ko > > 7 1 0xc0d87000 6a32c acpi.ko > > 8 1 0xc4394000 22000 linux.ko > > > > I can unload if_ath, ath_hal and ath_rate which drops the interface > > ath0, but even in this case Fn+F2 has no affect at all; any idea? > > Oh, then I guess the 900 is different. > > > I've had a look into the Xandros Linux and they do it with ACPI events, > > dropping the modules and others; I could provide their script > > /etc/acpi/wlan.sh if someone wants to have a look into; > > If turning off WLAN is now done via ACPI events, then the patch I > committed to HEAD will probably help. I'll MFC it in a week, but if you > can give it a try, that would be great. Please contact me off-list if > you need assistance. Hola Rui, I've found your very usefull pages in http://wiki.freebsd.org/AsusEee I CVS'uped the kernel to RELENG_7, built it and moved it to the eeePC; now Fn+F2 works as it should and I can even kldunload if_ath, power-off and power-on the wireless card, and after kldload if_ath the interface comes up fine again and my devd(8) hook assigns IP again; now it works as it should; will have a look into the events seen by devd(8) to make the kldunload and kldload perhaps there; thanks for your work and help; matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ ?...una sola vez, que es cuanto basta si se trata de verdades definitivas.? ?...only once, which is enough if it has todo with definite truth.? Jos? Saramago, Historia del Cerca de Lisboa From rpaulo at FreeBSD.org Sun Jun 29 16:24:15 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Sun Jun 29 16:24:23 2008 Subject: eeePC 900 && turning off wireless (ath0) In-Reply-To: <20080629160527.GA17075@rebelion.Sisis.de> References: <20080626075545.GA2964@rebelion.Sisis.de> <20080626231603.GC6875@phi.local> <20080627080203.GA19602@rebelion.Sisis.de> <20080627194447.GA34524@phi.local> <20080629160527.GA17075@rebelion.Sisis.de> Message-ID: <20080629162234.GB1261@phi.local> On Sun, Jun 29, 2008 at 06:05:27PM +0200, Matthias Apitz wrote: > Hola Rui, > > I've found your very usefull pages in http://wiki.freebsd.org/AsusEee > > I CVS'uped the kernel to RELENG_7, built it and moved it to the eeePC; > now Fn+F2 works as it should and I can even kldunload if_ath, power-off > and power-on the wireless card, and after kldload if_ath the interface > comes up fine again and my devd(8) hook assigns IP again; now it works as > it should; will have a look into the events seen by devd(8) to make the > kldunload and kldload perhaps there; > > thanks for your work and help; Cool, no problem. -- Rui Paulo From sullrich at gmail.com Sun Jun 29 19:22:39 2008 From: sullrich at gmail.com (Scott Ullrich) Date: Sun Jun 29 19:22:42 2008 Subject: WITHOUT_INSTALLLIB blues In-Reply-To: <20080629.014211.74670684.imp@bsdimp.com> References: <20080629.014211.74670684.imp@bsdimp.com> Message-ID: On Sun, Jun 29, 2008 at 3:42 AM, Warner Losh wrote: >> when setting WITHOUT_INSTALLLIB, make buildworld breaks with >> make: don't know how to make /r+d/obj/sunfire/alix/i386/r+d/7.0/src/tmp/legacy/ >> usr/lib/libegacy.a. Stop > > Only set it for installworld. Was this documented somewhere after the change? This bit me some time ago and I could not find it documented anywhere. If not can someone add it to /usr/src/UPDATING? Scott From ru at FreeBSD.org Sun Jun 29 21:55:52 2008 From: ru at FreeBSD.org (Ruslan Ermilov) Date: Sun Jun 29 21:55:56 2008 Subject: WITHOUT_INSTALLLIB blues In-Reply-To: References: <20080629.014211.74670684.imp@bsdimp.com> Message-ID: <20080629215531.GC21018@edoofus.dev.vega.ru> On Sun, Jun 29, 2008 at 02:54:03PM -0400, Scott Ullrich wrote: > On Sun, Jun 29, 2008 at 3:42 AM, Warner Losh wrote: > >> when setting WITHOUT_INSTALLLIB, make buildworld breaks with > >> make: don't know how to make /r+d/obj/sunfire/alix/i386/r+d/7.0/src/tmp/legacy/ > >> usr/lib/libegacy.a. Stop > > > > Only set it for installworld. > > Was this documented somewhere after the change? This bit me some time > ago and I could not find it documented anywhere. If not can someone > add it to /usr/src/UPDATING? > It follows from the description of WITHOUT_INSTALLLIB in src.conf(5), but perhaps it's not very obvious. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From thespin at gmail.com Mon Jun 30 06:04:40 2008 From: thespin at gmail.com (Evan Geller) Date: Mon Jun 30 06:04:44 2008 Subject: Recursive case in uma? Message-ID: <4f1862640806292237g4797a9b4y33a2d70a009639b@mail.gmail.com> Hey, I'm writing a small hobby operating system and I'm looking to the UMA for inspiration. The part I don't understand is the recursive case in uma_zone_slab(). I'm curious where the memory for vm_map_entries actually come from if the slabs are all full. It would appear that the null returned by uma_zone_slab() just carries all the way up and there's a fixed upper limit of vm_map_entries... or that I don't understand the way the uma works. Would someone mind clearing this up for me? Thanks a ton for the help! Evan From danny at cs.huji.ac.il Mon Jun 30 09:07:59 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Mon Jun 30 09:08:04 2008 Subject: WITHOUT_INSTALLLIB blues In-Reply-To: <20080629215531.GC21018@edoofus.dev.vega.ru> References: <20080629.014211.74670684.imp@bsdimp.com> <20080629215531.GC21018@edoofus.dev.vega.ru> Message-ID: > On Sun, Jun 29, 2008 at 02:54:03PM -0400, Scott Ullrich wrote: > > On Sun, Jun 29, 2008 at 3:42 AM, Warner Losh wrote: > > >> when setting WITHOUT_INSTALLLIB, make buildworld breaks with > > >> make: don't know how to make /r+d/obj/sunfire/alix/i386/r+d/7.0/src/tmp/legacy/ > > >> usr/lib/libegacy.a. Stop > > > > > > Only set it for installworld. > > > > Was this documented somewhere after the change? This bit me some time > > ago and I could not find it documented anywhere. If not can someone > > add it to /usr/src/UPDATING? > > > It follows from the description of WITHOUT_INSTALLLIB in src.conf(5), > but perhaps it's not very obvious. understatement :-) but if it only applies to 'install' why does it break 'build'? I have one file src.conf, now i need 2? cheers, danny From sepherosa at gmail.com Mon Jun 30 10:06:37 2008 From: sepherosa at gmail.com (Sepherosa Ziehau) Date: Mon Jun 30 10:06:40 2008 Subject: [Fwd: Re: Problems with ieee80211 dependencies...] In-Reply-To: <1214648519.15425.40.camel@devstation> References: <1214648519.15425.40.camel@devstation> Message-ID: On 6/28/08, Martes Wigglesworth wrote: > > I had to wait for the rebuild process to error out again, however, here > is the resulting segment of output. > > I included the parts that begin to indicates an error. > > > kdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE > -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq > -I/usr/src/sys/i386/compile/DATASERVER /usr/src/sys/modules/zyd/../../dev/usb/if_zyd.c > linking kernel.debug Add device ether to you kernel config. Your linking error has _nothing_ to do with 802.11 stuffs. Best Regards, sephe -- Live Free or Die From ru at freebsd.org Mon Jun 30 10:08:39 2008 From: ru at freebsd.org (Ruslan Ermilov) Date: Mon Jun 30 10:08:45 2008 Subject: WITHOUT_INSTALLLIB blues In-Reply-To: References: <20080629.014211.74670684.imp@bsdimp.com> <20080629215531.GC21018@edoofus.dev.vega.ru> Message-ID: <20080630100816.GB99247@edoofus.dev.vega.ru> On Mon, Jun 30, 2008 at 12:07:57PM +0300, Danny Braniss wrote: > > On Sun, Jun 29, 2008 at 02:54:03PM -0400, Scott Ullrich wrote: > > > On Sun, Jun 29, 2008 at 3:42 AM, Warner Losh wrote: > > > >> when setting WITHOUT_INSTALLLIB, make buildworld breaks with > > > >> make: don't know how to make /r+d/obj/sunfire/alix/i386/r+d/7.0/src/tmp/legacy/ > > > >> usr/lib/libegacy.a. Stop > > > > > > > > Only set it for installworld. > > > > > > Was this documented somewhere after the change? This bit me some time > > > ago and I could not find it documented anywhere. If not can someone > > > add it to /usr/src/UPDATING? > > > > > It follows from the description of WITHOUT_INSTALLLIB in src.conf(5), > > but perhaps it's not very obvious. > > understatement :-) > but if it only applies to 'install' why does it break 'build'? I have one file src.conf, now i need 2? > It can be applied only to the "install" stage. If applied to the "build" stage, it will break it because "build" internally uses "install" to install libraries to a temporary place (${WORLDTMP}) so the other programs/libraries can link against them. See your /usr/obj/usr/src/tmp{,/usr}/lib for details (for a canonical mix of /usr/src and /usr/obj). Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From sclark46 at earthlink.net Mon Jun 30 12:38:23 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Mon Jun 30 13:22:02 2008 Subject: AMD Geode LX crypto accelerator (glxsb) In-Reply-To: <2e77fc10806271410q3205fb21r9aed15ec8b035401@mail.gmail.com> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080622170507.5ac469d2@baby-jane-lamaiziere-net.local> <2e77fc10806221101q684baf47r9ee7208a676f59e@mail.gmail.com> <48654F81.6010500@earthlink.net> <2e77fc10806271410q3205fb21r9aed15ec8b035401@mail.gmail.com> Message-ID: <4868D3BD.8000200@earthlink.net> Niki Denev wrote: > On Fri, Jun 27, 2008 at 11:37 PM, Stephen Clark wrote: >> Hi, >> >> I am trying to compile it on 6.2 and get >> make: don't know how to make cryptodev_if.h. Stop >> >> ??? >> where is this file? >> >> Thanks, >> Steve >> > > Have you applied the 6.2 patch included in the latest tgz that Patrick posted? > > Regards, > Niki > Uh.. no -wasn't sure what to apply it to - now that I look at it a bit closer I SEE! Thanks, and sorry for the noise. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From kamikaze at bsdforen.de Mon Jun 30 17:54:50 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Mon Jun 30 17:54:55 2008 Subject: deflate and gzip support for libfetch over http Message-ID: <48691DD6.9000306@bsdforen.de> I wanted to benchmark a http-connection using fetch in a shell-script. I came to realize that fetch doesn't support compressed streams when I force-fed it the compressed stream by ignoring the absence of Accept-Encoding. This doesn't influence my benchmarking, but I think fetch should have this feature. I hacked together deflate support for the http part of libfetch. Next on my todo list is proper error handling, gzip support, code clean up and general code clean up in http.c (in order of priority). I'd love to get some feedback, do you consider this useful? Does it work on your system? Would there be a chance of getting the finalized version into SVN? The attached patch applies to RELENG_7. Probably everywhere else, too. Because I think libfetch development has been at a halt for some time. Regards, Dominic -------------- next part -------------- --- src/lib/libfetch/http.c.orig 2008-06-29 15:28:58.000000000 +0200 +++ src/lib/libfetch/http.c 2008-06-30 19:38:57.000000000 +0200 @@ -75,6 +75,7 @@ #include #include #include +#include #include #include @@ -105,7 +106,6 @@ #define HTTP_ERROR(xyz) ((xyz) > 400 && (xyz) < 599) - /***************************************************************************** * I/O functions for decoding chunked streams */ @@ -126,6 +126,16 @@ #endif }; +struct zlibio +{ + FILE *source; /* the http connection to read from */ + z_stream *stream; /* the zlib stream to read the */ + /* uncompressed data from */ + char in[65536]; /* read buffer */ +}; + +typedef FILE * (*funopen_function)(conn_t *, int); + /* * Get next chunk header */ @@ -302,10 +312,50 @@ } /* + * Read function for deflate compressed data. + */ +static int +http_inflate_readfn(void *v, char *buf, int len) +{ + struct zlibio *io = (struct zlibio *)v; + int status; + + /* Only read if the last read chunk has completely been flushed. */ + if (io->stream->avail_in == 0) { + io->stream->avail_in = fread(io->in, sizeof(char), sizeof(io->in), io->source); + + /* Forward errors and eof */ + if (io->stream->avail_in <= 0) + return io->stream->avail_in; + + io->stream->next_in = io->in; + } + + io->stream->avail_out = len; + io->stream->next_out = buf; + status = inflate(io->stream, Z_SYNC_FLUSH); + + return (len - io->stream->avail_out); +} + +/* + * Close function for deflate compressed data + */ +static int +http_inflate_closefn(void *v) +{ + struct zlibio *io = (struct zlibio *)v; + + (void)inflateEnd(io->stream); + free(io->stream); + return (fclose(io->source)); +} + +/* * Wrap a file descriptor up */ static FILE * -http_funopen(conn_t *conn, int chunked) +http_funopen_raw(conn_t *conn, int chunked) { struct httpio *io; FILE *f; @@ -316,7 +366,7 @@ } io->conn = conn; io->chunked = chunked; - f = funopen(io, http_readfn, http_writefn, NULL, http_closefn); + f = funopen(io, &http_readfn, &http_writefn, NULL, &http_closefn); if (f == NULL) { fetch_syserr(); free(io); @@ -325,6 +375,50 @@ return (f); } +/* + * Wrap a file descriptor up around the zlip inflate command + */ +static FILE * +http_funopen_inflate(conn_t *conn, int chunked) +{ + struct zlibio *io; + FILE *f; + + if ((io = calloc(1, sizeof(*io))) == NULL) { + fetch_syserr(); + return (NULL); + } + + io->source = http_funopen_raw(conn, chunked); + + if ((io->stream = calloc(1, sizeof(*(io->stream)))) == NULL) { + fetch_syserr(); + free(io); + return (NULL); + } + + io->stream->zalloc = Z_NULL; + io->stream->zfree = Z_NULL; + io->stream->opaque = Z_NULL; + io->stream->avail_in = 0; + io->stream->next_in = Z_NULL; + if (inflateInit2(io->stream, -MAX_WBITS) != Z_OK) { + fetch_syserr(); + free(io->source); + free(io); + return (NULL); + } + + f = funopen(io, &http_inflate_readfn, NULL, NULL, &http_inflate_closefn); + + if (f == NULL) { + fetch_syserr(); + free(io->source); + free(io); + return (NULL); + } + return f; +} /***************************************************************************** * Helper functions for talking to the server and parsing its replies @@ -336,6 +430,7 @@ hdr_error = -1, hdr_end = 0, hdr_unknown = 1, + hdr_content_encoding, hdr_content_length, hdr_content_range, hdr_last_modified, @@ -349,6 +444,7 @@ hdr_t num; const char *name; } hdr_names[] = { + { hdr_content_encoding, "Content-Encoding" }, { hdr_content_length, "Content-Length" }, { hdr_content_range, "Content-Range" }, { hdr_last_modified, "Last-Modified" }, @@ -496,6 +592,24 @@ } /* + * Parse a content-encoding header + */ +funopen_function +http_parse_encoding(const char *p, off_t *length) +{ + off_t len = sizeof("gzip"); + /* not yet supported + if (strncmp(p, "gzip", len) == 0) + return &http _funopen_gunzip; */ + + len = sizeof("deflate"); + if (strncmp(p, "deflate", len) == 0) + return &http_funopen_inflate; + + return &http_funopen_raw; +} + +/* * Parse a content-length header */ static int @@ -800,6 +914,7 @@ conn_t *conn; struct url *url, *new; int chunked, direct, need_auth, noredirect, verbose; + funopen_function funopenfn; int e, i, n, val; off_t offset, clength, length, size; time_t mtime; @@ -834,6 +949,7 @@ length = -1; size = -1; mtime = 0; + funopenfn = &http_funopen_raw; /* check port */ if (!url->port) @@ -919,6 +1035,7 @@ http_cmd(conn, "User-Agent: %s " _LIBFETCH_VER, getprogname()); if (url->offset > 0) http_cmd(conn, "Range: bytes=%lld-", (long long)url->offset); + http_cmd(conn, "Accept-Encoding: deflate"); http_cmd(conn, "Connection: close"); http_cmd(conn, ""); @@ -999,6 +1116,9 @@ case hdr_error: http_seterr(HTTP_PROTOCOL_ERROR); goto ouch; + case hdr_content_encoding: + funopenfn = http_parse_encoding(p, &length); + break; case hdr_content_length: http_parse_length(p, &clength); break; @@ -1119,7 +1239,9 @@ /* fill in stats */ if (us) { - us->size = size; + /* We only know the real output size for uncompressed data. */ + if (funopenfn == &http_funopen_raw) + us->size = size; us->atime = us->mtime = mtime; } @@ -1134,7 +1256,7 @@ URL->length = clength; /* wrap it up in a FILE */ - if ((f = http_funopen(conn, chunked)) == NULL) { + if ((f = (*funopenfn)(conn, chunked)) == NULL) { fetch_syserr(); goto ouch; } --- src/lib/libfetch/Makefile.orig 2008-06-29 23:45:32.000000000 +0200 +++ src/lib/libfetch/Makefile 2008-06-29 23:43:11.000000000 +0200 @@ -20,6 +20,8 @@ LDADD= -lssl -lcrypto .endif +LDADD+= -lz + CFLAGS+= -DFTP_COMBINE_CWDS -l CSTD?= c99 From stef at memberwebs.com Mon Jun 30 23:16:15 2008 From: stef at memberwebs.com (Stef) Date: Tue Jul 1 04:15:24 2008 Subject: FreeBSD 6.3 deadlock (vm_map?) with DDB output References: <20080615112318.146C1F18512@mx.npubs.com> <200806180917.05689.jhb@freebsd.org> Message-ID: <20080630231611.F0245F1817C@mx.npubs.com> John Baldwin wrote: > On Sunday 15 June 2008 07:23:19 am Stef Walter wrote: >> I've been trying to track down a deadlock on some newish production >> servers running FreeBSD 6.3-RELEASE-p2. The deadlock occurs on a >> specific (although mundane) hardware configuration, and each of several >> servers running this hardware deadlock about once per week. > > Try this change: > > We use it at work on 6.x. W/o this fix, round-robin stops working on 4BSD > when softclock() (swi4: clock) blocks on a lock like Giant. Just wanted to confirm: That patch did the trick. All the SMP machines that had this problem have been stable for 11 days now, longer than any of them were up previously. I changed the patch slightly to work with FreeBSD 6.3-RELEASE. That's attached, in case anyone needs this later. Cheers, Stef -------------- next part -------------- A non-text attachment was scrubbed... Name: kern_sched4bsd_deadlock.patch Type: text/x-patch Size: 2036 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080630/6e566563/kern_sched4bsd_deadlock.bin