From linda.messerschmidt at gmail.com Sat Aug 1 16:06:46 2009 From: linda.messerschmidt at gmail.com (Linda Messerschmidt) Date: Sat Aug 1 16:06:52 2009 Subject: Where have all the vnodes gone? Message-ID: <237c27100908010841g5abd3183w479121b2ba7b0c91@mail.gmail.com> (Reposted from freebsd-questions due to no replies.) With the last few releases, I've noticed a distinct trend toward disappearing vnodes on one of the machines I look after. This machine isn't doing a whole lot. It runs a couple of small web sites, and once an hour it rsync's some files from one NFS mount to another, but the rsync doesn't stay running; it restarts every hour and runs for 10-15 minutes. I set it to log the number of vnodes every ten minutes and this is what I got: 00:47:59 vfs.numvnodes: 39337 00:57:59 vfs.numvnodes: 40568 01:07:59 vfs.numvnodes: 44554 01:17:59 vfs.numvnodes: 52141 01:27:59 vfs.numvnodes: 55713 01:37:59 vfs.numvnodes: 58643 01:47:59 vfs.numvnodes: 60792 01:57:59 vfs.numvnodes: 67130 02:07:59 vfs.numvnodes: 76035 02:17:59 vfs.numvnodes: 84349 02:27:59 vfs.numvnodes: 92187 02:37:59 vfs.numvnodes: 98114 02:47:59 vfs.numvnodes: 116854 02:57:59 vfs.numvnodes: 124842 03:07:59 vfs.numvnodes: 164173 03:17:59 vfs.numvnodes: 172257 03:27:59 vfs.numvnodes: 178388 03:37:59 vfs.numvnodes: 183066 03:47:59 vfs.numvnodes: 190092 03:57:59 vfs.numvnodes: 198322 04:07:59 vfs.numvnodes: 204598 04:17:59 vfs.numvnodes: 208311 04:27:59 vfs.numvnodes: 214207 04:37:59 vfs.numvnodes: 221028 04:47:59 vfs.numvnodes: 227792 04:57:59 vfs.numvnodes: 233214 05:07:59 vfs.numvnodes: 240112 05:17:59 vfs.numvnodes: 247572 05:27:59 vfs.numvnodes: 256090 05:37:59 vfs.numvnodes: 262720 05:47:59 vfs.numvnodes: 269755 05:57:59 vfs.numvnodes: 274986 06:07:59 vfs.numvnodes: 279879 06:17:59 vfs.numvnodes: 287039 06:27:59 vfs.numvnodes: 291984 06:37:59 vfs.numvnodes: 294267 06:47:59 vfs.numvnodes: 296658 06:57:59 vfs.numvnodes: 299086 07:07:59 vfs.numvnodes: 301825 07:17:59 vfs.numvnodes: 309060 07:27:59 vfs.numvnodes: 312955 07:37:59 vfs.numvnodes: 317400 07:47:59 vfs.numvnodes: 320047 At that point the machine crashed with: panic: kmem_malloc(16384): kmem_map too small: 334745600 total allocated If I don't tune kern.maxvnodes up to the point where it panics, then eventually it runs out of vnodes and all sorts of stuff gets stuck in vlruwk. The machine in question is running 7.2-RELEASE-p3, but I already upgraded it from 7.1 trying to get this to go away, so it's a problem that's been around for awhile. My guess is that they're leaking in the kernel somewhere because of the rsync, because there's just not much else going on, but unless I can figure out how many vnodes are being used on a per-process basis, I can't make any headway on proving or disproving that. I do know that according to fstat, there are only 1000-1500 descriptors open at any given time, and kern.openfiles ranges 250-500. So I'm just mystified what the other 300000+ could be. Is there any way to figure out where all these vnodes are going? TIA for any advice! From attilio at freebsd.org Sat Aug 1 17:37:24 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sat Aug 1 17:37:31 2009 Subject: Where have all the vnodes gone? In-Reply-To: <237c27100908010841g5abd3183w479121b2ba7b0c91@mail.gmail.com> References: <237c27100908010841g5abd3183w479121b2ba7b0c91@mail.gmail.com> Message-ID: <3bbf2fe10908011014r2fda9245xc7c5f71fcc544d10@mail.gmail.com> 2009/8/1 Linda Messerschmidt : > (Reposted from freebsd-questions due to no replies.) > > With the last few releases, I've noticed a distinct trend toward > disappearing vnodes on one of the machines I look after. > > This machine isn't doing a whole lot. It runs a couple of small web > sites, and once an hour it rsync's some files from one NFS mount to > another, but the rsync doesn't stay running; it restarts every hour > and runs for 10-15 minutes. > > I set it to log the number of vnodes every ten minutes and this is what I got: > > 00:47:59 vfs.numvnodes: 39337 > 00:57:59 vfs.numvnodes: 40568 > 01:07:59 vfs.numvnodes: 44554 > 01:17:59 vfs.numvnodes: 52141 > 01:27:59 vfs.numvnodes: 55713 > 01:37:59 vfs.numvnodes: 58643 > 01:47:59 vfs.numvnodes: 60792 > 01:57:59 vfs.numvnodes: 67130 > 02:07:59 vfs.numvnodes: 76035 > 02:17:59 vfs.numvnodes: 84349 > 02:27:59 vfs.numvnodes: 92187 > 02:37:59 vfs.numvnodes: 98114 > 02:47:59 vfs.numvnodes: 116854 > 02:57:59 vfs.numvnodes: 124842 > 03:07:59 vfs.numvnodes: 164173 > 03:17:59 vfs.numvnodes: 172257 > 03:27:59 vfs.numvnodes: 178388 > 03:37:59 vfs.numvnodes: 183066 > 03:47:59 vfs.numvnodes: 190092 > 03:57:59 vfs.numvnodes: 198322 > 04:07:59 vfs.numvnodes: 204598 > 04:17:59 vfs.numvnodes: 208311 > 04:27:59 vfs.numvnodes: 214207 > 04:37:59 vfs.numvnodes: 221028 > 04:47:59 vfs.numvnodes: 227792 > 04:57:59 vfs.numvnodes: 233214 > 05:07:59 vfs.numvnodes: 240112 > 05:17:59 vfs.numvnodes: 247572 > 05:27:59 vfs.numvnodes: 256090 > 05:37:59 vfs.numvnodes: 262720 > 05:47:59 vfs.numvnodes: 269755 > 05:57:59 vfs.numvnodes: 274986 > 06:07:59 vfs.numvnodes: 279879 > 06:17:59 vfs.numvnodes: 287039 > 06:27:59 vfs.numvnodes: 291984 > 06:37:59 vfs.numvnodes: 294267 > 06:47:59 vfs.numvnodes: 296658 > 06:57:59 vfs.numvnodes: 299086 > 07:07:59 vfs.numvnodes: 301825 > 07:17:59 vfs.numvnodes: 309060 > 07:27:59 vfs.numvnodes: 312955 > 07:37:59 vfs.numvnodes: 317400 > 07:47:59 vfs.numvnodes: 320047 > > At that point the machine crashed with: > > panic: kmem_malloc(16384): kmem_map too small: 334745600 total allocated > > If I don't tune kern.maxvnodes up to the point where it panics, then > eventually it runs out of vnodes and all sorts of stuff gets stuck in > vlruwk. > > The machine in question is running 7.2-RELEASE-p3, but I already > upgraded it from 7.1 trying to get this to go away, so it's a problem > that's been around for awhile. > > My guess is that they're leaking in the kernel somewhere because of > the rsync, because there's just not much else going on, but unless I > can figure out how many vnodes are being used on a per-process basis, > I can't make any headway on proving or disproving that. I do know > that according to fstat, there are only 1000-1500 descriptors open at > any given time, and kern.openfiles ranges 250-500. So I'm just > mystified what the other 300000+ could be. > > Is there any way to figure out where all these vnodes are going? It seems you can reproduce it easilly. Can you please provide KTR traces of KTR_VFS? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From attilio at freebsd.org Sat Aug 1 17:44:54 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sat Aug 1 17:45:01 2009 Subject: Where have all the vnodes gone? In-Reply-To: <237c27100908010841g5abd3183w479121b2ba7b0c91@mail.gmail.com> References: <237c27100908010841g5abd3183w479121b2ba7b0c91@mail.gmail.com> Message-ID: <3bbf2fe10908011013g2ba221c1raa07698886b4413c@mail.gmail.com> 2009/8/1 Linda Messerschmidt : > (Reposted from freebsd-questions due to no replies.) > > With the last few releases, I've noticed a distinct trend toward > disappearing vnodes on one of the machines I look after. > > This machine isn't doing a whole lot. It runs a couple of small web > sites, and once an hour it rsync's some files from one NFS mount to > another, but the rsync doesn't stay running; it restarts every hour > and runs for 10-15 minutes. > > I set it to log the number of vnodes every ten minutes and this is what I got: > > 00:47:59 vfs.numvnodes: 39337 > 00:57:59 vfs.numvnodes: 40568 > 01:07:59 vfs.numvnodes: 44554 > 01:17:59 vfs.numvnodes: 52141 > 01:27:59 vfs.numvnodes: 55713 > 01:37:59 vfs.numvnodes: 58643 > 01:47:59 vfs.numvnodes: 60792 > 01:57:59 vfs.numvnodes: 67130 > 02:07:59 vfs.numvnodes: 76035 > 02:17:59 vfs.numvnodes: 84349 > 02:27:59 vfs.numvnodes: 92187 > 02:37:59 vfs.numvnodes: 98114 > 02:47:59 vfs.numvnodes: 116854 > 02:57:59 vfs.numvnodes: 124842 > 03:07:59 vfs.numvnodes: 164173 > 03:17:59 vfs.numvnodes: 172257 > 03:27:59 vfs.numvnodes: 178388 > 03:37:59 vfs.numvnodes: 183066 > 03:47:59 vfs.numvnodes: 190092 > 03:57:59 vfs.numvnodes: 198322 > 04:07:59 vfs.numvnodes: 204598 > 04:17:59 vfs.numvnodes: 208311 > 04:27:59 vfs.numvnodes: 214207 > 04:37:59 vfs.numvnodes: 221028 > 04:47:59 vfs.numvnodes: 227792 > 04:57:59 vfs.numvnodes: 233214 > 05:07:59 vfs.numvnodes: 240112 > 05:17:59 vfs.numvnodes: 247572 > 05:27:59 vfs.numvnodes: 256090 > 05:37:59 vfs.numvnodes: 262720 > 05:47:59 vfs.numvnodes: 269755 > 05:57:59 vfs.numvnodes: 274986 > 06:07:59 vfs.numvnodes: 279879 > 06:17:59 vfs.numvnodes: 287039 > 06:27:59 vfs.numvnodes: 291984 > 06:37:59 vfs.numvnodes: 294267 > 06:47:59 vfs.numvnodes: 296658 > 06:57:59 vfs.numvnodes: 299086 > 07:07:59 vfs.numvnodes: 301825 > 07:17:59 vfs.numvnodes: 309060 > 07:27:59 vfs.numvnodes: 312955 > 07:37:59 vfs.numvnodes: 317400 > 07:47:59 vfs.numvnodes: 320047 > > At that point the machine crashed with: > > panic: kmem_malloc(16384): kmem_map too small: 334745600 total allocated > > If I don't tune kern.maxvnodes up to the point where it panics, then > eventually it runs out of vnodes and all sorts of stuff gets stuck in > vlruwk. > > The machine in question is running 7.2-RELEASE-p3, but I already > upgraded it from 7.1 trying to get this to go away, so it's a problem > that's been around for awhile. > > My guess is that they're leaking in the kernel somewhere because of > the rsync, because there's just not much else going on, but unless I > can figure out how many vnodes are being used on a per-process basis, > I can't make any headway on proving or disproving that. I do know > that according to fstat, there are only 1000-1500 descriptors open at > any given time, and kern.openfiles ranges 250-500. So I'm just > mystified what the other 300000+ could be. > > Is there any way to figure out where all these vnodes are going? > > TIA for any advice! > _______________________________________________ > 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" > -- Peace can only be achieved by understanding - A. Einstein From keramida at ceid.upatras.gr Sun Aug 2 23:43:19 2009 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Sun Aug 2 23:43:26 2009 Subject: llvm/clang a tool chain or just a compiler for FreeBSD? In-Reply-To: <20090722160547.GU55190@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Wed, 22 Jul 2009 19:05:47 +0300") References: <2e566b9e0907202134h5568a06bl33a8d95ac9c7f845@mail.gmail.com> <20090721131735.GA18929@freebsd.org> <2e566b9e0907211818k1a52ef7am5c681a6f4ffc868c@mail.gmail.com> <864ot5jy3f.fsf@ds4.des.no> <20090722141756.GQ55190@deviant.kiev.zoral.com.ua> <3cb459ed0907220823q2376f545x44c0972a989a4b72@mail.gmail.com> <20090722160547.GU55190@deviant.kiev.zoral.com.ua> Message-ID: <877hxlx0l6.fsf@kobe.laptop> On Wed, 22 Jul 2009 19:05:47 +0300, Kostik Belousov wrote: >> I know some ports using "USE_GCC" knob of /usr/ports/Mk/bsd.gcc.mk . >> Is this the same as you suggest? > > No. And this was actually not my idea. > > The proposal is to have portmgr-selected and approved version of gcc, > installed from port and used to build ports. The base (g)cc is used > only to build base. > > Such divorce seems to be beneficial both to base compiler, and for > ports. ISTR this is what pkgsrc does. It isn't a very bad idea, and it may give ports/ a bit of freedom about the version of the compiler they can use for special OPTIONS= items like SSE instruction optimizations and so on. -------------- 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/20090802/cf82871d/attachment.pgp From keramida at freebsd.org Mon Aug 3 01:56:39 2009 From: keramida at freebsd.org (Giorgos Keramidas) Date: Mon Aug 3 01:56:47 2009 Subject: distributed scm+freebsd svn? References: <20090726231534.GI21885@elvis.mu.org> Message-ID: <87vdl5vg14.fsf@kobe.laptop> On Sun, 26 Jul 2009 16:15:34 -0700, Alfred Perlstein wrote: > Hello hackers, > > Does anyone here use one of the distributed SCMs to manage > contributions to FreeBSD in an easy manner? Hi Alfred, Yes, I do that. > Any pointers to a setup you have? > > I thought "git" was supposed to make this easy, but going over the > docs leaves me with a lot of questions. Git is a wonderful system but it's "UI" and documentation often make me want to scream bad things. My own suggestion is to go with Mercurial, because it's command set looks a *lot* like CVS or Subversion, it's often as fast or even faster than Git, and it doesn't seem as 'confusing' as Git. More details below... > I'm hoping to be able to basically: > sync into my "distributed repo". > allow a third party access to it. > easily commit upstream back into svn from a branch > in my distributed scm. I use a local Mercurial repository for my own patches. It seems to support most of the things I want to do, i.e.: * Keep a clean `/hg/bsd/head' workspace and pull full changesets into that from our svn repository * Support incremental updates of `/hg/bsd/head'. * Easily clone my `/hg/bsd/head' to one or more `feature' branches. * Allow others to pull from `head' as a read-only source over http or ssh. The /head branch has a huge history that I don't really want to keep around in every clone. So I started my conversion from 2007-12-31 and I keep updating it with the `hg convert ...' command wrapped in a small shell script: $ cat -n /hg/bsd/pull-head.sh 1 #!/bin/sh 2 3 set -e 4 hg convert \ 5 --config convert.svn.startrev='175021' \ 6 --config convert.svn.trunk='head' \ 7 --config convert.svn.branches='' \ 8 --config convert.svn.tags='' \ 9 file:///home/svn/base/ \ 10 /hg/bsd/head You can use the webdav http://svn.freebsd.org/base/ or an SSH tunneled URI to access to Subversion repository, but I keep a local mirror of the Subversion repository too, so I prefer that. Typical Mercurial-based Workflow ================================ 1. Pull subversion commits into the 'head' workspace. 2. Pull these changes from 'head' to my working tree. 3. Merge the changes with the local patches of the working tree. 4. Extract one or more patches for committing to Subversion 5. Rinse, leather, repeat... Pulling the latest commits from Subversion ------------------------------------------ The first step is the easiest bit. I just run `/hg/bsd/pull-head.sh'. This requires an installed copy of the Python bindings of Subversion [devel/py-subversion] and the `convert' extension enabled in my ~/.hgrc file with: [extensions] convert = A sample run of `pull-head.sh' looks like this: keramida@kobe:/hg/bsd$ time ./pull-head.sh scanning source... sorting... converting... 1 Many network stack subsystems use a single global data structure to hold 0 Add padding to struct inpcb, missed during our padding sweep earlier in 3.306 real 1.809 user 0.619 sys keramida@kobe:/hg/bsd$ This is reasonably fast, but it does come with an important caveat. It's not terribly important for my own work, but it *may* be for yours: The Python bindings of Subversion do not support svn:keywords, so all our manually configured '$FreeBSD$' stuff is unexpanded in the converted tree. Mergemaster may cause various levels of "fun" and "amusement" if you mix, match and alternate between svn-based and mercurial-based workspaces often! At this point, after "pull-head.sh" has finished running, the most recent commit in the head/.hg/ workspace state is the last commit by rwatson: keramida@kobe:/hg/bsd/head$ hg log --limit 1 changeset: 12589:8ce7c7a0b804 branch: head tag: tip user: rwatson date: Sun Aug 02 22:47:08 2009 +0000 summary: Add padding to struct inpcb, missed during our padding sweep earlier in keramida@kobe:/hg/bsd/head$ This clone/workspace is my 'clean' slate, and it only contains an `.hg' data store. No checkout or other workspace contents: keramida@kobe:/hg/bsd/head$ ls -la total 6 drwxr-xr-x 3 keramida users - 512 Nov 10 2008 . drwxr-xr-x 8 keramida users - 512 Aug 3 02:36 .. drwxr-xr-x 3 keramida users - 512 Aug 3 02:36 .hg keramida@kobe:/hg/bsd/head$ du -sh . 243M . keramida@kobe:/hg/bsd/head$ It does however contains separate changesets for each subversion commit, so I can browse the (local only now) history with a fair amount of speed. Pulling these changes in my personal workspace ---------------------------------------------- The second step is to pull the latest versions in my personal workspace at `/hg/bsd/src': keramida@kobe:/home/keramida$ cd /hg/bsd/src 1) keramida@kobe:/hg/bsd/src$ hg incoming --style compact ../head comparing with /hg/bsd/head searching for changes 12588 6b04ed36e454 2009-08-02 19:43 +0000 rwatson Many network stack subsystems use a single global data structure to hold 12589[tip] 8ce7c7a0b804 2009-08-02 22:47 +0000 rwatson Add padding to struct inpcb, missed during our padding sweep earlier in 2) keramida@kobe:/hg/bsd/src$ hg pull ../head pulling from /hg/bsd/head searching for changes adding changesets adding manifests adding file changes added 2 changesets with 16 changes to 16 files (+1 heads) (run 'hg heads' to see heads, 'hg merge' to merge) keramida@kobe:/hg/bsd/src$ Comments: --------- (1) Just look at what would be pulled from 'head' but don't actually make any changes to the local workspace or branch/data store. (2) Pull the changes, creating a 'fork' in the history of the local workspace at the place where the changes were grafted on top of the previous svn-based changeset. At this point the history of my personal workspace has "forked". The subversion changesets have been grafted on top of the previous svn commit. This is easier to show with a picture/graph of the local history, so here it is (from the 'graphlog' extension of Mercurial): keramida@kobe:/hg/bsd/src$ hg glog --limit 5 o 12785[tip] 8ce7c7a0b804 2009-08-02 22:47 +0000 rwatson | Add padding to struct inpcb, missed during our padding sweep earlier in | o 12784:12782 6b04ed36e454 2009-08-02 19:43 +0000 rwatson | Many network stack subsystems use a single global data structure to hold | | @ 12783:12762,12782 c50060fec1db 2009-08-02 21:06 +0300 keramida |/| Merge from head | | o | 12782 8e4fc85e5aa3 2009-08-02 16:59 +0000 julian | | Stop uuidgen(2) from crashing in vimage kerenels. | | o | 12781 bf9c3383d680 2009-08-02 14:28 +0000 attilio | | Make the newbus subsystem Giant free by adding the new newbus sxlock. | | keramida@kobe:/hg/bsd/src$ The last time I pulled from Subversion was after 16:59 UTC (this is the buildworld I am still running in the background). My current workspace contains a checkout of revision 12783/c50060fec1db (hence the '@' in the relevant node of the history graph). Merging the New Changesets -------------------------- To prepare for my next `merge with head', I first look at the two 'heads' of the history. My last successful merge and the new 'head' created by importing from Subversion: keramida@kobe:/hg/bsd/src$ hg heads --style compact 12785[tip] 8ce7c7a0b804 2009-08-02 22:47 +0000 rwatson Add padding to struct inpcb, missed during our padding sweep earlier in 12783:12762,12782 c50060fec1db 2009-08-02 21:06 +0300 keramida Merge from head keramida@kobe:/hg/bsd/src$ Then I verify that I do *not* have local uncommitted stuff: keramida@kobe:/hg/bsd/src$ hg status keramida@kobe:/hg/bsd/src$ This takes a few seconds, but I don't want to throw away any changes I may have been working on without noticing. Since this is a clean checkout of revision 12783:c50060fec1db, I don't necessarily need the next step, but it's safe to do it. I check out a clean copy of the local merge head: keramida@kobe:/hg/bsd/src$ time hg update --clean c50060fec1db 0 files updated, 0 files merged, 0 files removed, 0 files unresolved 4.684 real 1.691 user 2.558 sys Being a clean checkout already and having the filesystem cache 'hot' from the last pull I just did, this is often fast enough. Finally a merge of the 'remote' Subversion based commits I just pulled: keramida@kobe:/hg/bsd/src$ hg merge merging sys/netinet/in_gif.c merging sys/netinet/ip_var.h 14 files updated, 2 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) You have new mail in /home/keramida/Mailbox keramida@kobe:/hg/bsd/src$ hg commit -m 'Merge from head' keramida@kobe:/hg/bsd/src$ That's all. Now I have my own local changes 'merged' with the latest changeset from Subversion. There are no conflicts to resolve manually, because the subversion changesets I pulled do not affect any of the files with local-only changes, so this merge was relatively pain-free, quite fast and most importantly required no manual input at all :) Looking at the history with graphlog again, shows something like this: keramida@kobe:/hg/bsd/src$ hg glog --limit 5 @ 12786[tip]:12783,12785 368efb2b98b9 2009-08-03 03:00 +0300 keramida |\ Merge from head | | | o 12785 8ce7c7a0b804 2009-08-02 22:47 +0000 rwatson | | Add padding to struct inpcb, missed during our padding sweep earlier in | | | o 12784:12782 6b04ed36e454 2009-08-02 19:43 +0000 rwatson | | Many network stack subsystems use a single global data structure to hold | | o | 12783:12762,12782 c50060fec1db 2009-08-02 21:06 +0300 keramida |\| Merge from head | | | o 12782 8e4fc85e5aa3 2009-08-02 16:59 +0000 julian | | Stop uuidgen(2) from crashing in vimage kerenels. | | keramida@kobe:/hg/bsd/src$ Merging with 'head' often means that you can then publish this workspace so others can pull from it, and publish their own patches for the same workspace. How often you merge with each other is up to you. In the Greek documentation project we often merge after many days or several weeks. With projects that have a higher local change rate merging every day might be nicer (and result in far fewer conflicts). Extracting Patches from the Local Workspace =========================================== Keeping local changes means you may eventually want to push those changes towards the /head of Subversion. You'll have to extract patches for one or more file then. Since you have the tools to look at the local history, you can use "hg diff" with the last subversion commit, i.e. with the history shown above: keramida@kobe:/hg/bsd/src$ hg glog --limit 5 @ 12786[tip]:12783,12785 368efb2b98b9 2009-08-03 03:00 +0300 keramida |\ Merge from head | | | o 12785 8ce7c7a0b804 2009-08-02 22:47 +0000 rwatson | | Add padding to struct inpcb, missed during our padding sweep earlier in | | | o 12784:12782 6b04ed36e454 2009-08-02 19:43 +0000 rwatson | | Many network stack subsystems use a single global data structure to hold | | o | 12783:12762,12782 c50060fec1db 2009-08-02 21:06 +0300 keramida |\| Merge from head : : You can run "hg diff" between changesets 12785 and 12786 (tip): keramida@kobe:/hg/bsd/src$ hg diff -r 12785:tip | diffstat -p1 contrib/mg/Makefile | 29 + contrib/mg/README | 74 ++ contrib/mg/autoexec.c | 111 ++++ ... snip ... usr.bin/yacc/reader.c | 2 usr.sbin/chown/chgrp.1 | 10 usr.sbin/chown/chown.8 | 12 usr.sbin/chown/chown.c | 17 76 files changed, 18355 insertions(+), 44 deletions(-) keramida@kobe:/hg/bsd/src$ My own local workspace includes an import of OpenBSD's mg(1) editor. This shows as a single patch in the diff command I used above, along with *every* other file that differs in my local 'branch' of FreeBSD head. Let's assume, for example's sake, that you don't really care about mg(1) patches, and you want to look at everything else. The --include and --exclude options of "hg diff" help a lot there (short names -I and -X): keramida@kobe:/hg/bsd/src$ hg diff -r 12785:tip -X contrib/mg -X usr.bin/mg | diffstat -p1 contrib/top/top.X | 5 - contrib/top/top.c | 2 etc/Makefile | 6 + etc/mtree/BSD.games.dist | 16 +++ etc/mtree/BSD.usr.dist | 2 etc/mtree/BSD.var.dist | 2 libexec/rtld-elf/rtld.c | 2 share/mk/bsd.own.mk | 2 sys/amd64/conf/KOBE | 185 ++++++++++++++++++++++++++++++++++++++ sys/boot/common/interp.c | 2 sys/boot/common/interp_forth.c | 2 sys/conf/newvers.sh | 26 +++++ sys/i386/conf/KOBE | 195 +++++++++++++++++++++++++++++++++++++++++ usr.bin/Makefile | 5 + usr.bin/truss/amd64-fbsd.c | 4 usr.bin/truss/amd64-fbsd32.c | 3 usr.bin/truss/amd64-linux32.c | 4 usr.bin/truss/i386-fbsd.c | 4 usr.bin/truss/i386-linux.c | 4 usr.bin/truss/ia64-fbsd.c | 4 usr.bin/truss/powerpc-fbsd.c | 4 usr.bin/truss/sparc64-fbsd.c | 4 usr.bin/yacc/reader.c | 2 usr.sbin/chown/chgrp.1 | 10 +- usr.sbin/chown/chown.8 | 12 +- usr.sbin/chown/chown.c | 17 ++- 26 files changed, 480 insertions(+), 44 deletions(-) keramida@kobe:/hg/bsd/src$ If you want to commit *all* the local changes as a single patch to Subversion, you can keep refining the --exclude/--include patterns until the final patch looks and smells "right". If you know the directories that you want to diff, i.e. you want to commit all the local `usr.sbin/chown' changes in one subversion changeset, you can use a directory with "hg diff" too (which works quite unsurprisingly like "svn diff"): keramida@kobe:/hg/bsd/src$ hg diff -r 12785:tip usr.sbin/chown | diffstat -p1 usr.sbin/chown/chgrp.1 | 10 +++++++--- usr.sbin/chown/chown.8 | 12 ++++++++---- usr.sbin/chown/chown.c | 17 +++++++++++------ 3 files changed, 26 insertions(+), 13 deletions(-) keramida@kobe:/hg/bsd/src$ Extracting Local Changesets as Patches ====================================== Another option is to extract only the very specific local commit that affected a file, i.e. my local `usr.sbin/chown/chown.c' changes. First you'd have to look at the local history of the file: keramida@kobe:/hg/bsd/src$ hg log --style compact usr.sbin/chown/chown.c 12010:11998,12009 7f4fa839afed 2009-06-20 00:50 +0300 keramida Merge from head 12002 96e04082ef3f 2009-06-19 15:58 +0000 brooks In preparation for raising NGROUPS and NGROUPS_MAX, change base 7782 141cd5ffef80 2009-01-22 07:18 +0200 keramida Add a new -x option to chown and chgrp, to inhibit file system 0 dd5ed0412a8b 2007-12-31 22:03 +0000 jhb Actually declare the kern.features sysctl node. keramida@kobe:/hg/bsd/src$ >From this output it's obvious my local changes were made on 2009-01-22 07:18 +0200, and they are available as changeset 7782:141cd5ffef80. You can extract this changeset only with "hg export": keramida@kobe:/hg/bsd/src$ hg export 141cd5ffef80 # HG changeset patch # User Giorgos Keramidas # Date 1232601528 -7200 # Branch head # Node ID 141cd5ffef80ff979627d8898500c92984287426 # Parent e8506b2ac7aefbfb875f0def0de8dd6441885a40 Add a new -x option to chown and chgrp, to inhibit file system mount point traversal. The -x option is documented, like -v, as a non-standard option in the COMPATIBILITY manpage sections. diff -r e8506b2ac7ae -r 141cd5ffef80 usr.sbin/chown/chgrp.1 --- a/usr.sbin/chown/chgrp.1 Wed Jan 21 21:31:33 2009 +0200 +++ b/usr.sbin/chown/chgrp.1 Thu Jan 22 07:18:48 2009 +0200 @@ -31,7 +31,7 @@ .\" @(#)chgrp.1 8.3 (Berkeley) 3/31/94 .\" $FreeBSD$ .\" -.Dd April 25, 2003 +.Dd January 22, 2009 .Dt CHGRP 1 .Os .Sh NAME @@ -39,7 +39,7 @@ .Nd change group .Sh SYNOPSIS .Nm -.Op Fl fhv +.Op Fl fhvx .Oo .Fl R ... snip ... This patch is _directly_ usable with `patch -p1' in a checkout of /head from Subversion, but it *may* require a bit of `svn merge' work if you have fast-forwarded chown/chgrp to its latest 'head' version. It is not a diff of the *latest* chown/chgrp from /head but a _precise_ copy of the past changeset, as it was committed. More... ======= * You can browse the 'clean' head/ copy I am using at http://hg.hellug.gr/freebsd/head/ Note: this only has the head history since 2007-12-31. For older head commits, you will have to use a new "convert" run and it will change all the commit/changeset hashes even if their patch data is identical. * You can find a compressed 'bundle' file called 'head.hg' in my home directory at freefall. This can be used to 'seed' the initial copy of your local 'head', eg. by pulling directly from the bundle: % cd /var/tmp % scp freefall.freebsd.org:'~keramida/head.hg' . % cd ~ % mkdir -p ~/work/freebsd/head % hg init ~/work/freebsd/head % cd ~/work/freebsd/head % hg pull /var/tmp/head.hg * If you plan to use the incremental conversion script I described earlier in this message, you will also need a "SHA map" file that maps Subversion changesets to Mercurial changeset hashes. This is also available at freefall as `~keramida/head.shamap' and you have to copy it to your `head/.hg/shamap' file. Then either run the "hg convert" extension manually or use a small shell wrapper like the one I pasted here. * For more information about some of the extensions I've mentioned it is always a good idea to check the Mercurial Wiki at: http://www.selenic.com/mercurial/ I hope all this helps a bit... If you need more help with publishing local workspaces over http and/or extracting patches (these are often two of the points where help is necessary and welcome), please feel free to ask. I've been using this sort of workflow for local changesets quite some time and I know enough about Mercurial to help where needed. From maslanbsd at gmail.com Mon Aug 3 08:44:45 2009 From: maslanbsd at gmail.com (Maslan) Date: Mon Aug 3 08:44:51 2009 Subject: sosend() and mbuf Message-ID: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> Hello Guys, I can't find useful information on sosend(), I would like to send some plain text through sosend() Here is what i got so far, I don't know how to use mbuf with sosend() to achieve this. ret = socreate(PF_INET, &s, SOCK_STREAM, IPPROTO_TCP, curthread->td_ucred, curthread); printf("socreate -> %d\n", ret); bzero(&sa, sizeof(sa)); sa.sin_len = sizeof(sa); sa.sin_family = AF_INET; sa.sin_port = htons(8888); sa.sin_addr.s_addr = INADDR_ANY; sobind(s, (struct sockaddr *)&sa, curthread); printf("sobind -> %d\n", ret); ret = solisten(s, 4, curthread); printf("solisten -> %d\n", ret); ret = soaccept(s, (struct sockaddr**)&psa); printf("soaccept -> %d\n", ret); tsleep(curthread, PDROP, "kHTTP tsleep", 10*hz); /* iovec */ aiov.iov_base = buf; aiov.iov_len = strlen(buf); /* auio */ auio.uio_iov = &aiov; auio.uio_iovcnt = 1; auio.uio_offset = 0; auio.uio_resid = strlen(buf); auio.uio_rw = UIO_WRITE; auio.uio_segflg = UIO_SYSSPACE; auio.uio_td = curthread; --------> ret = sosend(s, (struct sockaddr*)&sa, &auio, 0, 0, 0, curthread); printf("sosend -> %d\n", ret); ret = soclose(s); printf("soclose -> %d\n", ret); Thanks a lot From des at des.no Mon Aug 3 14:08:34 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Aug 3 14:08:40 2009 Subject: sosend() and mbuf In-Reply-To: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> (Maslan's message of "Mon, 3 Aug 2009 08:19:26 +0000") References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> Message-ID: <864ospvvkv.fsf@ds4.des.no> Maslan writes: > I can't find useful information on sosend(), I would like to send some > plain text through sosend() > Here is what i got so far, I don't know how to use mbuf with sosend() > to achieve this. You need to stick your "plain text" in an mbuf. See 'man 9 socket' and 'man 9 mbuf' for details. DES -- Dag-Erling Sm?rgrav - des@des.no From linda.messerschmidt at gmail.com Mon Aug 3 14:28:39 2009 From: linda.messerschmidt at gmail.com (Linda Messerschmidt) Date: Mon Aug 3 14:28:45 2009 Subject: Where have all the vnodes gone? In-Reply-To: <3bbf2fe10908011834j68045a32wd84f52a8321932e6@mail.gmail.com> References: <237c27100908010841g5abd3183w479121b2ba7b0c91@mail.gmail.com> <3bbf2fe10908011014r2fda9245xc7c5f71fcc544d10@mail.gmail.com> <237c27100908011427j587a6c94lc3762d7ce73c3f31@mail.gmail.com> <3bbf2fe10908011834j68045a32wd84f52a8321932e6@mail.gmail.com> Message-ID: <237c27100908030728x78d50667g864fb7fc6fed7e43@mail.gmail.com> Sorry, I did not mean to reply off-list. (I had asked if the kernel options suggested were appropriate for a production system.) On Sat, Aug 1, 2009 at 9:34 PM, Attilio Rao wrote: > Penalties in term of overhead are pretty huge. That would probably mean not putting it on that box. Don't get me in trouble! :) > Did it happen in a production kernel? Yes, very much so. > For what I know, somebody could reproduce a vnodes leak randomly, you > seem to be the only one who can reproduce it easilly and it would be > very important to analyze the situation. I will see if I can reproduce the behavior on a test box with these options. If it really is the rsync stuff we're doing, that should be possible. From des at des.no Mon Aug 3 19:52:06 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Aug 3 19:52:14 2009 Subject: sosend() and mbuf In-Reply-To: <319cceca0908031043x6bfe5771wa73553dce922756a@mail.gmail.com> (Maslan's message of "Mon, 3 Aug 2009 17:43:14 +0000") References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <864ospvvkv.fsf@ds4.des.no> <319cceca0908031043x6bfe5771wa73553dce922756a@mail.gmail.com> Message-ID: <86eirs65gb.fsf@ds4.des.no> [please cc: the list] Maslan writes: > man 9 sosend: > Data may be sent directly from kernel or user memory via the uio > argument, or as an mbuf chain via top, avoid- ing a data copy. > Only one of the uio or top pointers may be non-NULL Hmm, I missed that part. It never occurred to me to *not* use mbufs. I guess the question is: what is your question? Does your code work? If it doesn't, where and how does it fail? If it does, why are you asking? In any case, 'man 9 sosend' answers the "I can't find useful information on sosend()" part of your email. If you still have questions after reading that, try looking at existing kernel code that uses sosend(9) with iovecs (or with mbufs, if you decide to go that route). DES -- Dag-Erling Sm?rgrav - des@des.no From aavzz at yandex.ru Mon Aug 3 20:25:13 2009 From: aavzz at yandex.ru (Alex Zimnitsky) Date: Mon Aug 3 20:25:20 2009 Subject: sys/cdefs.h not included automatically Message-ID: <1249329403.2928.11.camel@localhost.localdomain> Hello, freebsd-hackers my system is 7.2-RELEASE there is a which is included in a lot of headers, but a few of them instead of including it, generate "#error this file needs sys/cdefs.h". seems like an omission, but if it's intentional I'm curious why it is so. thanks a lot, Alex From maslanbsd at gmail.com Mon Aug 3 21:25:30 2009 From: maslanbsd at gmail.com (Maslan) Date: Mon Aug 3 21:25:36 2009 Subject: sosend() and mbuf In-Reply-To: <86eirs65gb.fsf@ds4.des.no> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <864ospvvkv.fsf@ds4.des.no> <319cceca0908031043x6bfe5771wa73553dce922756a@mail.gmail.com> <86eirs65gb.fsf@ds4.des.no> Message-ID: <319cceca0908031425r3516de29q34807cdf2c7489ed@mail.gmail.com> No my code doesn't work, I thought it may be because that soaccept() -which is not found in man 9- is non-blocking, so i've to put my code in a thread. Now i got another problem, when I open a text file from this thread, the kernel crashes, I'm sure that its the thread. kthread_create((void *)thread_main, NULL, NULL, RFNOWAIT, 0, "thread"); void thread_main(){ struct thread *td = curthread; int ret; int fd; ret = f_open("/path/to/file.txt", &fd); printf("%d\n", ret); tsleep(td, PDROP, "test tsleep", 10*hz); f_close(fd); kthread_exit(0); } int f_open(char *filename, int *fd){ struct thread *td = curthread; int ret = kern_open(td, filename, UIO_SYSSPACE, O_RDONLY, FREAD); if(!ret){ *fd = td->td_retval[0]; return 1; } return 0; } I've to finish up this problem to go back for the first one. Can you figure out what's wrong with this code, it works when I call thread_main() rather than kthread_create((void *)thread_main, ..... Thanks a lot 2009/8/3 Dag-Erling Sm?rgrav : > [please cc: the list] > > Maslan writes: >> man 9 sosend: >> Data may be sent directly from kernel or user memory via the uio >> argument, or as an mbuf chain via top, avoid- ing a data copy. >> Only one of the uio or top pointers may be non-NULL > > Hmm, I missed that part. It never occurred to me to *not* use mbufs. > > I guess the question is: what is your question? Does your code work? > If it doesn't, where and how does it fail? If it does, why are you > asking? > > In any case, 'man 9 sosend' answers the "I can't find useful information > on sosend()" part of your email. If you still have questions after > reading that, try looking at existing kernel code that uses sosend(9) > with iovecs (or with mbufs, if you decide to go that route). > > DES > -- > Dag-Erling Sm?rgrav - des@des.no > From des at des.no Mon Aug 3 22:01:52 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Aug 3 22:01:59 2009 Subject: sosend() and mbuf In-Reply-To: <319cceca0908031425r3516de29q34807cdf2c7489ed@mail.gmail.com> (Maslan's message of "Mon, 3 Aug 2009 21:25:27 +0000") References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <864ospvvkv.fsf@ds4.des.no> <319cceca0908031043x6bfe5771wa73553dce922756a@mail.gmail.com> <86eirs65gb.fsf@ds4.des.no> <319cceca0908031425r3516de29q34807cdf2c7489ed@mail.gmail.com> Message-ID: <86k51k4kvl.fsf@ds4.des.no> Maslan writes: > Now i got another problem, when I open a text file from this thread, > the kernel crashes, I'm sure that its the thread. If the kernel crashed, I assume you have a dump and a backtrace and can tell us *where* it crashed? One thing that springs to mind is that kern_open() will dereference td->td_proc, and AFAIK kthread_create() does not associate the thread with a process. > kthread_create((void *)thread_main, NULL, NULL, RFNOWAIT, 0, > "thread"); There is no kthread_create() in head. I assume you're working on 7? You shouldn't. The cast is incorrect. I assume you put it there to silence the warning telling you that your code was wrong. This will create a new thread in process 0, which is probably not what you want (although it should work). It would be better to create a separate process for your code and create the thread there. You can do both in a single function call using kproc_kthread_add(). You don't show the part of your code where you call sched_add() to actually start the thread. > void thread_main(){ There are at least two problems here: 1) thread_main() is supposed to take a void * argument, and 2) you disabled or ignored the compiler warnings that told you this was wrong. > f_close(fd); You didn't include the definition of f_close(), so I can't tell if there's anything wrong with it. > int f_open(char *filename, int *fd){ > struct thread *td = curthread; > int ret = kern_open(td, filename, UIO_SYSSPACE, O_RDONLY, FREAD); > if(!ret){ > *fd = td->td_retval[0]; > return 1; > } > return 0; > } This is overly complicated. There is no reason to conditionalize the assignment to *fd; just do it and return ret. FREAD is not a valid argument to kern_open(). Well, technically, it's with the expected range, but it doesn't do what you think it does. This doesn't really matter, though, because the mode argument is not used when opening an existing file. That's all the help I can give until you provide a stack trace from the crash and the complete code, not just selected excerpts. DES -- Dag-Erling Sm?rgrav - des@des.no From des at des.no Mon Aug 3 22:03:42 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Aug 3 22:03:48 2009 Subject: sosend() and mbuf In-Reply-To: <86k51k4kvl.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Tue, 04 Aug 2009 00:01:50 +0200") References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <864ospvvkv.fsf@ds4.des.no> <319cceca0908031043x6bfe5771wa73553dce922756a@mail.gmail.com> <86eirs65gb.fsf@ds4.des.no> <319cceca0908031425r3516de29q34807cdf2c7489ed@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> Message-ID: <86fxc84ksj.fsf@ds4.des.no> Dag-Erling Sm?rgrav writes: > One thing that springs to mind is that kern_open() will dereference > td->td_proc, and AFAIK kthread_create() does not associate the thread > with a process. This is wrong, and contradicts what I wrote further down. Just ignore it. DES -- Dag-Erling Sm?rgrav - des@des.no From maslanbsd at gmail.com Mon Aug 3 23:05:08 2009 From: maslanbsd at gmail.com (Maslan) Date: Mon Aug 3 23:05:14 2009 Subject: sosend() and mbuf In-Reply-To: <86fxc84ksj.fsf@ds4.des.no> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <864ospvvkv.fsf@ds4.des.no> <319cceca0908031043x6bfe5771wa73553dce922756a@mail.gmail.com> <86eirs65gb.fsf@ds4.des.no> <319cceca0908031425r3516de29q34807cdf2c7489ed@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> Message-ID: <319cceca0908031558h1bd779b1pac3c9454986f5488@mail.gmail.com> I'm running out 7.2-RELEASE-p2 Here is my bt 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: loaded. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x20:0xc085935b stack pointer = 0x28:0xe6cd3a28 frame pointer = 0x28:0xe6cd3aa4 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 = 1354 (test) trap number = 12 panic: page fault cpuid = 1 Uptime: 4m45s Physical memory: 1001 MB Dumping 119 MB: 104 88 72 56 40 24 8 Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/if_wpi.ko...Reading symbols from /boot/kernel/if_wpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_wpi.ko Reading symbols from /boot/kernel/wpifw.ko...Reading symbols from /boot/kernel/wpifw.ko.symbols...done. done. Loaded symbols for /boot/kernel/wpifw.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/i915.ko...Reading symbols from /boot/kernel/i915.ko.symbols...done. done. Loaded symbols for /boot/kernel/i915.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko Reading symbols from ./test.ko...done. Loaded symbols for ./test.ko #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07e25c7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e2899 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0ae3efc in trap_fatal (frame=0xe6cd39e8, eva=16) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0ae4180 in trap_pfault (frame=0xe6cd39e8, usermode=0, eva=16) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0ae4b2c in trap (frame=0xe6cd39e8) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc0ac923b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc085935b in namei (ndp=0xe6cd3bc8) at /usr/src/sys/kern/vfs_lookup.c:191 #8 0xc08706d7 in vn_open_cred (ndp=0xe6cd3bc8, flagp=0xe6cd3cc4, cmode=1, cred=0xc408fc00, fp=0xc4b5b344) at /usr/src/sys/kern/vfs_vnops.c:188 #9 0xc08709a3 in vn_open (ndp=0xe6cd3bc8, flagp=0xe6cd3cc4, cmode=1, fp=0xc4b5b344) at /usr/src/sys/kern/vfs_vnops.c:94 #10 0xc086e0d3 in kern_open (td=0xc499dd20, path=0xc4c7a978 "/root/test.txt", pathseg=UIO_SYSSPACE, flags=1, mode=1) at /usr/src/sys/kern/vfs_syscalls.c:1042 #11 0xc4c7a805 in f_open () from ./test.ko #12 0xc4c7a8a1 in thread_main () from ./test.ko #13 0xc07bd079 in fork_exit (callout=0xc4c7a880 , arg=0x0, frame=0xe6cd3d38) at /usr/src/sys/kern/kern_fork.c:810 #14 0xc0ac92b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 On Mon, Aug 3, 2009 at 10:03 PM, Dag-Erling Sm?rgrav wrote: > Dag-Erling Sm?rgrav writes: >> One thing that springs to mind is that kern_open() will dereference >> td->td_proc, and AFAIK kthread_create() does not associate the thread >> with a process. > > This is wrong, and contradicts what I wrote further down. Just ignore > it. > > DES > -- > Dag-Erling Sm?rgrav - des@des.no > From max at love2party.net Mon Aug 3 23:50:58 2009 From: max at love2party.net (Max Laier) Date: Mon Aug 3 23:51:06 2009 Subject: sosend() and mbuf In-Reply-To: <86fxc84ksj.fsf@ds4.des.no> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> Message-ID: <200908040138.14743.max@love2party.net> On Tuesday 04 August 2009 00:03:40 Dag-Erling Sm?rgrav wrote: > Dag-Erling Sm?rgrav writes: > > One thing that springs to mind is that kern_open() will dereference > > td->td_proc, and AFAIK kthread_create() does not associate the thread > > with a process. > > This is wrong, and contradicts what I wrote further down. Just ignore > it. IIRC, kernel threads don't have root. -- /"\ 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 unixmania at gmail.com Tue Aug 4 05:26:36 2009 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Tue Aug 4 05:26:43 2009 Subject: sys/cdefs.h not included automatically In-Reply-To: <1249329403.2928.11.camel@localhost.localdomain> References: <1249329403.2928.11.camel@localhost.localdomain> Message-ID: On Mon, Aug 3, 2009 at 4:56 PM, Alex Zimnitsky wrote: > Hello, freebsd-hackers > > my system is 7.2-RELEASE > > there is a which is included in a lot of headers, but a > few of them instead of including it, generate "#error this file needs > sys/cdefs.h". > > seems like an omission, but if it's intentional I'm curious why it is > so. Those files are not intended to be directly included by user programs. You usually include them indirectly. See, for instance, pthread.h and stddef.h. -- My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. From maslanbsd at gmail.com Tue Aug 4 09:27:08 2009 From: maslanbsd at gmail.com (Maslan) Date: Tue Aug 4 09:27:15 2009 Subject: sosend() and mbuf In-Reply-To: <200908040138.14743.max@love2party.net> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> Message-ID: <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> man kthread says: The kthread_create() function is used to create a kernel thread. The new thread shares its address space with process 0, the swapper process, and runs in kernel mode only. However, when i checked the pid & tid of the new created thread it was not the same as the parent nor as the proc0 & thread0 simple printf() gives: swap procid=0, threadid=0 procid=1680, threadid=100089 procid=1681, threadid=100090 <--- created by kthread_create() 2009/8/3 Max Laier : > On Tuesday 04 August 2009 00:03:40 Dag-Erling Sm?rgrav wrote: >> Dag-Erling Sm?rgrav writes: >> > One thing that springs to mind is that kern_open() will dereference >> > td->td_proc, and AFAIK kthread_create() does not associate the thread >> > with a process. >> >> This is wrong, and contradicts what I wrote further down. Just ignore >> it. > > IIRC, kernel threads don't have root. > > -- > /"\ 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 ed at 80386.nl Tue Aug 4 09:30:37 2009 From: ed at 80386.nl (Ed Schouten) Date: Tue Aug 4 09:30:44 2009 Subject: sosend() and mbuf In-Reply-To: <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> Message-ID: <20090804093036.GN1292@hoeg.nl> Hi, * Maslan wrote: > man kthread says: > The kthread_create() function is used to create a kernel thread. The new > thread shares its address space with process 0, the swapper process, and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > runs in kernel mode only. > > However, when i checked the pid & tid of the new created thread it was > not the same as the parent nor as the proc0 & thread0 I am not sure, but sharing another process's address space doesn't have to imply it shares the same pid, right? -- 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/20090804/36068bcd/attachment.pgp From maslanbsd at gmail.com Tue Aug 4 09:40:02 2009 From: maslanbsd at gmail.com (Maslan) Date: Tue Aug 4 09:40:09 2009 Subject: sosend() and mbuf In-Reply-To: <20090804093036.GN1292@hoeg.nl> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> Message-ID: <319cceca0908040239k2accd7fen402db4c91687a267@mail.gmail.com> I'm getting crazy, I don't know why kern_open() works in the module's main thread, but when I use it in another thread created by kthread_create() it crashes the kernel ??? On Tue, Aug 4, 2009 at 9:30 AM, Ed Schouten wrote: > Hi, > > * Maslan wrote: >> man kthread says: >> The kthread_create() function is used to create a kernel thread. The new >> thread shares its address space with process 0, the swapper process, and > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> runs in kernel mode only. >> >> However, when i checked the pid & tid of the new created thread it was >> not the same as the parent nor as the proc0 & thread0 > > I am not sure, but sharing another process's address space doesn't have > to imply it shares the same pid, right? > > -- > Ed Schouten > WWW: http://80386.nl/ > From ed at 80386.nl Tue Aug 4 09:41:43 2009 From: ed at 80386.nl (Ed Schouten) Date: Tue Aug 4 09:41:50 2009 Subject: sosend() and mbuf In-Reply-To: <319cceca0908040239k2accd7fen402db4c91687a267@mail.gmail.com> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> <319cceca0908040239k2accd7fen402db4c91687a267@mail.gmail.com> Message-ID: <20090804094142.GO1292@hoeg.nl> * Maslan wrote: > I'm getting crazy, > > I don't know why kern_open() works in the module's main thread, but > when I use it in another thread created by kthread_create() it crashes > the kernel ??? Is it possible to call kern_open() from within a kernel thread anyway? kern_open() depends on a file descriptor table, right? -- 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/20090804/c48a99a5/attachment.pgp From maslanbsd at gmail.com Tue Aug 4 09:52:53 2009 From: maslanbsd at gmail.com (Maslan) Date: Tue Aug 4 09:53:00 2009 Subject: sosend() and mbuf In-Reply-To: <20090804094142.GO1292@hoeg.nl> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> <319cceca0908040239k2accd7fen402db4c91687a267@mail.gmail.com> <20090804094142.GO1292@hoeg.nl> Message-ID: <319cceca0908040252w105d3dfdge9dec3c8b6d28607@mail.gmail.com> > Is it possible to call kern_open() from within a kernel thread anyway? I think yes, It worked on the parent thread before creating a new kthread. See OpenKETA source, its using the same approach. > kern_open() depends on a file descriptor table, right? Yes, it returns a fd in the curthread->td_retval[0], which i should use within the same thread to deal with this file. From ed at 80386.nl Tue Aug 4 09:56:51 2009 From: ed at 80386.nl (Ed Schouten) Date: Tue Aug 4 09:57:08 2009 Subject: sosend() and mbuf In-Reply-To: <319cceca0908040252w105d3dfdge9dec3c8b6d28607@mail.gmail.com> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> <319cceca0908040239k2accd7fen402db4c91687a267@mail.gmail.com> <20090804094142.GO1292@hoeg.nl> <319cceca0908040252w105d3dfdge9dec3c8b6d28607@mail.gmail.com> Message-ID: <20090804095650.GP1292@hoeg.nl> * Maslan wrote: > > Is it possible to call kern_open() from within a kernel thread anyway? > I think yes, It worked on the parent thread before creating a new kthread. > See OpenKETA source, its using the same approach. > > kern_open() depends on a file descriptor table, right? > Yes, it returns a fd in the curthread->td_retval[0], which i should > use within the same thread to deal with this file. Didn't someone (Jeff Roberson?) develop some nice in-kernel API for accessing files some years ago? Why not use that? -- 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/20090804/5123693f/attachment.pgp From maslanbsd at gmail.com Tue Aug 4 09:59:04 2009 From: maslanbsd at gmail.com (Maslan) Date: Tue Aug 4 09:59:11 2009 Subject: sosend() and mbuf In-Reply-To: <20090804095650.GP1292@hoeg.nl> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> <319cceca0908040239k2accd7fen402db4c91687a267@mail.gmail.com> <20090804094142.GO1292@hoeg.nl> <319cceca0908040252w105d3dfdge9dec3c8b6d28607@mail.gmail.com> <20090804095650.GP1292@hoeg.nl> Message-ID: <319cceca0908040259q4537db80uc2ce9696f30bfc12@mail.gmail.com> yes kio http://people.freebsd.org/~pjd/misc/kernio/ However, It's outdated. On Tue, Aug 4, 2009 at 9:56 AM, Ed Schouten wrote: > * Maslan wrote: >> > Is it possible to call kern_open() from within a kernel thread anyway? >> I think yes, It worked on the parent thread before creating a new kthread. >> See OpenKETA source, its using the same approach. >> > kern_open() depends on a file descriptor table, right? >> Yes, it returns a fd in the curthread->td_retval[0], which i should >> use within the same thread to deal with this file. > > Didn't someone (Jeff Roberson?) develop some nice in-kernel API for > accessing files some years ago? Why not use that? > > -- > Ed Schouten > WWW: http://80386.nl/ > From maslanbsd at gmail.com Tue Aug 4 10:19:15 2009 From: maslanbsd at gmail.com (Maslan) Date: Tue Aug 4 10:19:22 2009 Subject: sosend() and mbuf In-Reply-To: <319cceca0908040259q4537db80uc2ce9696f30bfc12@mail.gmail.com> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> <319cceca0908040239k2accd7fen402db4c91687a267@mail.gmail.com> <20090804094142.GO1292@hoeg.nl> <319cceca0908040252w105d3dfdge9dec3c8b6d28607@mail.gmail.com> <20090804095650.GP1292@hoeg.nl> <319cceca0908040259q4537db80uc2ce9696f30bfc12@mail.gmail.com> Message-ID: <319cceca0908040319x35bc8bcy7a869dd230419a50@mail.gmail.com> OpenKETA has its own kthread_create() with a little modification from kthread_create(), it associates the new thread with curthread not with the thread0. See /usr/sys/kern/kern_kthread.c: kthread_create() error = fork1(&thread0, RFMEM | RFFDG | RFPROC | RFSTOPPED | flags, pages, &p2); OpenKETA:kthread_create() error = fork1(curthread, RFFDG | RFPROC | RFSTOPPED | flags, pages, &p2); I'll give it a try and see if it works. BUT i still can't understand why kern_open() don't work, except in the original thread. On Tue, Aug 4, 2009 at 9:59 AM, Maslan wrote: > yes kio http://people.freebsd.org/~pjd/misc/kernio/ > However, It's outdated. > > On Tue, Aug 4, 2009 at 9:56 AM, Ed Schouten wrote: >> * Maslan wrote: >>> > Is it possible to call kern_open() from within a kernel thread anyway? >>> I think yes, It worked on the parent thread before creating a new kthread. >>> See OpenKETA source, its using the same approach. >>> > kern_open() depends on a file descriptor table, right? >>> Yes, it returns a fd in the curthread->td_retval[0], which i should >>> use within the same thread to deal with this file. >> >> Didn't someone (Jeff Roberson?) develop some nice in-kernel API for >> accessing files some years ago? Why not use that? >> >> -- >> Ed Schouten >> WWW: http://80386.nl/ >> > From aavzz at yandex.ru Tue Aug 4 11:37:02 2009 From: aavzz at yandex.ru (Alex Zimnitsky) Date: Tue Aug 4 11:37:09 2009 Subject: sys/cdefs.h not included automatically In-Reply-To: References: <1249329403.2928.11.camel@localhost.localdomain> Message-ID: <1249384820.2928.22.camel@localhost.localdomain> 04/08/2009 ? 02:26 -0300, Carlos A. M. dos Santos: > On Mon, Aug 3, 2009 at 4:56 PM, Alex Zimnitsky wrote: > > Hello, freebsd-hackers > > > > my system is 7.2-RELEASE > > > > there is a which is included in a lot of headers, but a > > few of them instead of including it, generate "#error this file needs > > sys/cdefs.h". > > > > seems like an omission, but if it's intentional I'm curious why it is > > so. > > Those files are not intended to be directly included by user programs. > You usually include them indirectly. See, for instance, pthread.h and > stddef.h. > OK, the reason of my asking was configure script in a 3rd party application (namely apr-1.3.6) that generated strange warning about sys/syslimits.h being good enoung for gcc but not for gcc -E. it seems, they have a bug in checking for the presence of limits.h and sys/syslimits.h and include them in a non-uniform manner later. going to send them a patch Alex From alfred at freebsd.org Tue Aug 4 11:38:30 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue Aug 4 11:38:37 2009 Subject: distributed scm+freebsd svn? In-Reply-To: <87vdl5vg14.fsf@kobe.laptop> References: <20090726231534.GI21885@elvis.mu.org> <87vdl5vg14.fsf@kobe.laptop> Message-ID: <20090804113829.GL47463@elvis.mu.org> This is amazing! Have you considered an article for publication based on your experiences? Perhaps a handbook article? This will be very helpful going forward. (Although, I do kind of wish it was a "instructions fits on the back of a napkin" kind of operation.) :) thanks again! -Alfred * Giorgos Keramidas [090802 18:32] wrote: > On Sun, 26 Jul 2009 16:15:34 -0700, Alfred Perlstein wrote: > > Hello hackers, > > > > Does anyone here use one of the distributed SCMs to manage > > contributions to FreeBSD in an easy manner? > > Hi Alfred, > Yes, I do that. > > > Any pointers to a setup you have? > > > > I thought "git" was supposed to make this easy, but going over the > > docs leaves me with a lot of questions. > > Git is a wonderful system but it's "UI" and documentation often make me > want to scream bad things. My own suggestion is to go with Mercurial, > because it's command set looks a *lot* like CVS or Subversion, it's often > as fast or even faster than Git, and it doesn't seem as 'confusing' as Git. > > More details below... > > > I'm hoping to be able to basically: > > sync into my "distributed repo". > > allow a third party access to it. > > easily commit upstream back into svn from a branch > > in my distributed scm. > > I use a local Mercurial repository for my own patches. It seems to > support most of the things I want to do, i.e.: > > * Keep a clean `/hg/bsd/head' workspace and pull full changesets into > that from our svn repository > > * Support incremental updates of `/hg/bsd/head'. > > * Easily clone my `/hg/bsd/head' to one or more `feature' branches. > > * Allow others to pull from `head' as a read-only source over http or > ssh. > > The /head branch has a huge history that I don't really want to keep > around in every clone. So I started my conversion from 2007-12-31 and I > keep updating it with the `hg convert ...' command wrapped in a small > shell script: > > $ cat -n /hg/bsd/pull-head.sh > 1 #!/bin/sh > 2 > 3 set -e > 4 hg convert \ > 5 --config convert.svn.startrev='175021' \ > 6 --config convert.svn.trunk='head' \ > 7 --config convert.svn.branches='' \ > 8 --config convert.svn.tags='' \ > 9 file:///home/svn/base/ \ > 10 /hg/bsd/head > > You can use the webdav http://svn.freebsd.org/base/ or an SSH tunneled > URI to access to Subversion repository, but I keep a local mirror of the > Subversion repository too, so I prefer that. > > > Typical Mercurial-based Workflow > ================================ > > 1. Pull subversion commits into the 'head' workspace. > > 2. Pull these changes from 'head' to my working tree. > > 3. Merge the changes with the local patches of the working tree. > > 4. Extract one or more patches for committing to Subversion > > 5. Rinse, leather, repeat... > > Pulling the latest commits from Subversion > ------------------------------------------ > > The first step is the easiest bit. I just run `/hg/bsd/pull-head.sh'. > > This requires an installed copy of the Python bindings of Subversion > [devel/py-subversion] and the `convert' extension enabled in my ~/.hgrc > file with: > > [extensions] > convert = > > A sample run of `pull-head.sh' looks like this: > > keramida@kobe:/hg/bsd$ time ./pull-head.sh > scanning source... > sorting... > converting... > 1 Many network stack subsystems use a single global data structure to hold > 0 Add padding to struct inpcb, missed during our padding sweep earlier in > 3.306 real 1.809 user 0.619 sys > keramida@kobe:/hg/bsd$ > > This is reasonably fast, but it does come with an important caveat. > It's not terribly important for my own work, but it *may* be for yours: > > The Python bindings of Subversion do not support svn:keywords, so > all our manually configured '$FreeBSD$' stuff is unexpanded in the > converted tree. Mergemaster may cause various levels of "fun" and > "amusement" if you mix, match and alternate between svn-based and > mercurial-based workspaces often! > > At this point, after "pull-head.sh" has finished running, the most > recent commit in the head/.hg/ workspace state is the last commit by > rwatson: > > keramida@kobe:/hg/bsd/head$ hg log --limit 1 > changeset: 12589:8ce7c7a0b804 > branch: head > tag: tip > user: rwatson > date: Sun Aug 02 22:47:08 2009 +0000 > summary: Add padding to struct inpcb, missed during our padding sweep earlier in > > keramida@kobe:/hg/bsd/head$ > > This clone/workspace is my 'clean' slate, and it only contains an `.hg' > data store. No checkout or other workspace contents: > > keramida@kobe:/hg/bsd/head$ ls -la > total 6 > drwxr-xr-x 3 keramida users - 512 Nov 10 2008 . > drwxr-xr-x 8 keramida users - 512 Aug 3 02:36 .. > drwxr-xr-x 3 keramida users - 512 Aug 3 02:36 .hg > keramida@kobe:/hg/bsd/head$ du -sh . > 243M . > keramida@kobe:/hg/bsd/head$ > > It does however contains separate changesets for each subversion commit, > so I can browse the (local only now) history with a fair amount of speed. > > > Pulling these changes in my personal workspace > ---------------------------------------------- > > The second step is to pull the latest versions in my personal workspace > at `/hg/bsd/src': > > keramida@kobe:/home/keramida$ cd /hg/bsd/src > 1) keramida@kobe:/hg/bsd/src$ hg incoming --style compact ../head > comparing with /hg/bsd/head > searching for changes > 12588 6b04ed36e454 2009-08-02 19:43 +0000 rwatson > Many network stack subsystems use a single global data structure to > hold > > 12589[tip] 8ce7c7a0b804 2009-08-02 22:47 +0000 rwatson > Add padding to struct inpcb, missed during our padding sweep earlier > in > > 2) keramida@kobe:/hg/bsd/src$ hg pull ../head > pulling from /hg/bsd/head > searching for changes > adding changesets > adding manifests > adding file changes > added 2 changesets with 16 changes to 16 files (+1 heads) > (run 'hg heads' to see heads, 'hg merge' to merge) > keramida@kobe:/hg/bsd/src$ > > Comments: > --------- > > (1) Just look at what would be pulled from 'head' but don't actually > make any changes to the local workspace or branch/data store. > > (2) Pull the changes, creating a 'fork' in the history of the local > workspace at the place where the changes were grafted on top of > the previous svn-based changeset. > > At this point the history of my personal workspace has "forked". The > subversion changesets have been grafted on top of the previous svn > commit. This is easier to show with a picture/graph of the local > history, so here it is (from the 'graphlog' extension of Mercurial): > > keramida@kobe:/hg/bsd/src$ hg glog --limit 5 > o 12785[tip] 8ce7c7a0b804 2009-08-02 22:47 +0000 rwatson > | Add padding to struct inpcb, missed during our padding sweep earlier in > | > o 12784:12782 6b04ed36e454 2009-08-02 19:43 +0000 rwatson > | Many network stack subsystems use a single global data structure to hold > | > | @ 12783:12762,12782 c50060fec1db 2009-08-02 21:06 +0300 keramida > |/| Merge from head > | | > o | 12782 8e4fc85e5aa3 2009-08-02 16:59 +0000 julian > | | Stop uuidgen(2) from crashing in vimage kerenels. > | | > o | 12781 bf9c3383d680 2009-08-02 14:28 +0000 attilio > | | Make the newbus subsystem Giant free by adding the new newbus sxlock. > | | > keramida@kobe:/hg/bsd/src$ > > The last time I pulled from Subversion was after 16:59 UTC (this is the > buildworld I am still running in the background). My current workspace > contains a checkout of revision 12783/c50060fec1db (hence the '@' in the > relevant node of the history graph). > > Merging the New Changesets > -------------------------- > > To prepare for my next `merge with head', I first look at the two > 'heads' of the history. My last successful merge and the new 'head' > created by importing from Subversion: > > keramida@kobe:/hg/bsd/src$ hg heads --style compact > 12785[tip] 8ce7c7a0b804 2009-08-02 22:47 +0000 rwatson > Add padding to struct inpcb, missed during our padding sweep earlier in > > 12783:12762,12782 c50060fec1db 2009-08-02 21:06 +0300 keramida > Merge from head > > keramida@kobe:/hg/bsd/src$ > > Then I verify that I do *not* have local uncommitted stuff: > > keramida@kobe:/hg/bsd/src$ hg status > keramida@kobe:/hg/bsd/src$ > > This takes a few seconds, but I don't want to throw away any changes I > may have been working on without noticing. > > Since this is a clean checkout of revision 12783:c50060fec1db, I don't > necessarily need the next step, but it's safe to do it. I check out a > clean copy of the local merge head: > > keramida@kobe:/hg/bsd/src$ time hg update --clean c50060fec1db > 0 files updated, 0 files merged, 0 files removed, 0 files unresolved > 4.684 real 1.691 user 2.558 sys > > Being a clean checkout already and having the filesystem cache 'hot' > from the last pull I just did, this is often fast enough. > > Finally a merge of the 'remote' Subversion based commits I just pulled: > > keramida@kobe:/hg/bsd/src$ hg merge > merging sys/netinet/in_gif.c > merging sys/netinet/ip_var.h > 14 files updated, 2 files merged, 0 files removed, 0 files unresolved > (branch merge, don't forget to commit) > You have new mail in /home/keramida/Mailbox > keramida@kobe:/hg/bsd/src$ hg commit -m 'Merge from head' > keramida@kobe:/hg/bsd/src$ > > That's all. Now I have my own local changes 'merged' with the latest > changeset from Subversion. There are no conflicts to resolve manually, > because the subversion changesets I pulled do not affect any of the > files with local-only changes, so this merge was relatively pain-free, > quite fast and most importantly required no manual input at all :) > > Looking at the history with graphlog again, shows something like this: > > keramida@kobe:/hg/bsd/src$ hg glog --limit 5 > @ 12786[tip]:12783,12785 368efb2b98b9 2009-08-03 03:00 +0300 keramida > |\ Merge from head > | | > | o 12785 8ce7c7a0b804 2009-08-02 22:47 +0000 rwatson > | | Add padding to struct inpcb, missed during our padding sweep earlier in > | | > | o 12784:12782 6b04ed36e454 2009-08-02 19:43 +0000 rwatson > | | Many network stack subsystems use a single global data structure to hold > | | > o | 12783:12762,12782 c50060fec1db 2009-08-02 21:06 +0300 keramida > |\| Merge from head > | | > | o 12782 8e4fc85e5aa3 2009-08-02 16:59 +0000 julian > | | Stop uuidgen(2) from crashing in vimage kerenels. > | | > keramida@kobe:/hg/bsd/src$ > > Merging with 'head' often means that you can then publish this workspace > so others can pull from it, and publish their own patches for the same > workspace. How often you merge with each other is up to you. In the > Greek documentation project we often merge after many days or several > weeks. With projects that have a higher local change rate merging every > day might be nicer (and result in far fewer conflicts). > > > Extracting Patches from the Local Workspace > =========================================== > > Keeping local changes means you may eventually want to push those > changes towards the /head of Subversion. You'll have to extract patches > for one or more file then. Since you have the tools to look at the > local history, you can use "hg diff" with the last subversion commit, > i.e. with the history shown above: > > keramida@kobe:/hg/bsd/src$ hg glog --limit 5 > @ 12786[tip]:12783,12785 368efb2b98b9 2009-08-03 03:00 +0300 keramida > |\ Merge from head > | | > | o 12785 8ce7c7a0b804 2009-08-02 22:47 +0000 rwatson > | | Add padding to struct inpcb, missed during our padding sweep earlier in > | | > | o 12784:12782 6b04ed36e454 2009-08-02 19:43 +0000 rwatson > | | Many network stack subsystems use a single global data structure to hold > | | > o | 12783:12762,12782 c50060fec1db 2009-08-02 21:06 +0300 keramida > |\| Merge from head > : : > > You can run "hg diff" between changesets 12785 and 12786 (tip): > > keramida@kobe:/hg/bsd/src$ hg diff -r 12785:tip | diffstat -p1 > contrib/mg/Makefile | 29 + > contrib/mg/README | 74 ++ > contrib/mg/autoexec.c | 111 ++++ > ... snip ... > usr.bin/yacc/reader.c | 2 > usr.sbin/chown/chgrp.1 | 10 > usr.sbin/chown/chown.8 | 12 > usr.sbin/chown/chown.c | 17 > 76 files changed, 18355 insertions(+), 44 deletions(-) > keramida@kobe:/hg/bsd/src$ > > My own local workspace includes an import of OpenBSD's mg(1) editor. > This shows as a single patch in the diff command I used above, along > with *every* other file that differs in my local 'branch' of FreeBSD > head. Let's assume, for example's sake, that you don't really care > about mg(1) patches, and you want to look at everything else. The > --include and --exclude options of "hg diff" help a lot there (short > names -I and -X): > > keramida@kobe:/hg/bsd/src$ hg diff -r 12785:tip -X contrib/mg -X usr.bin/mg | diffstat -p1 > contrib/top/top.X | 5 - > contrib/top/top.c | 2 > etc/Makefile | 6 + > etc/mtree/BSD.games.dist | 16 +++ > etc/mtree/BSD.usr.dist | 2 > etc/mtree/BSD.var.dist | 2 > libexec/rtld-elf/rtld.c | 2 > share/mk/bsd.own.mk | 2 > sys/amd64/conf/KOBE | 185 ++++++++++++++++++++++++++++++++++++++ > sys/boot/common/interp.c | 2 > sys/boot/common/interp_forth.c | 2 > sys/conf/newvers.sh | 26 +++++ > sys/i386/conf/KOBE | 195 +++++++++++++++++++++++++++++++++++++++++ > usr.bin/Makefile | 5 + > usr.bin/truss/amd64-fbsd.c | 4 > usr.bin/truss/amd64-fbsd32.c | 3 > usr.bin/truss/amd64-linux32.c | 4 > usr.bin/truss/i386-fbsd.c | 4 > usr.bin/truss/i386-linux.c | 4 > usr.bin/truss/ia64-fbsd.c | 4 > usr.bin/truss/powerpc-fbsd.c | 4 > usr.bin/truss/sparc64-fbsd.c | 4 > usr.bin/yacc/reader.c | 2 > usr.sbin/chown/chgrp.1 | 10 +- > usr.sbin/chown/chown.8 | 12 +- > usr.sbin/chown/chown.c | 17 ++- > 26 files changed, 480 insertions(+), 44 deletions(-) > keramida@kobe:/hg/bsd/src$ > > If you want to commit *all* the local changes as a single patch to > Subversion, you can keep refining the --exclude/--include patterns until > the final patch looks and smells "right". > > If you know the directories that you want to diff, i.e. you want to > commit all the local `usr.sbin/chown' changes in one subversion > changeset, you can use a directory with "hg diff" too (which works quite > unsurprisingly like "svn diff"): > > keramida@kobe:/hg/bsd/src$ hg diff -r 12785:tip usr.sbin/chown | diffstat -p1 > usr.sbin/chown/chgrp.1 | 10 +++++++--- > usr.sbin/chown/chown.8 | 12 ++++++++---- > usr.sbin/chown/chown.c | 17 +++++++++++------ > 3 files changed, 26 insertions(+), 13 deletions(-) > keramida@kobe:/hg/bsd/src$ > > Extracting Local Changesets as Patches > ====================================== > > Another option is to extract only the very specific local commit that > affected a file, i.e. my local `usr.sbin/chown/chown.c' changes. First > you'd have to look at the local history of the file: > > keramida@kobe:/hg/bsd/src$ hg log --style compact usr.sbin/chown/chown.c > 12010:11998,12009 7f4fa839afed 2009-06-20 00:50 +0300 keramida > Merge from head > > 12002 96e04082ef3f 2009-06-19 15:58 +0000 brooks > In preparation for raising NGROUPS and NGROUPS_MAX, change base > > 7782 141cd5ffef80 2009-01-22 07:18 +0200 keramida > Add a new -x option to chown and chgrp, to inhibit file system > > 0 dd5ed0412a8b 2007-12-31 22:03 +0000 jhb > Actually declare the kern.features sysctl node. > > keramida@kobe:/hg/bsd/src$ > > >From this output it's obvious my local changes were made on 2009-01-22 > 07:18 +0200, and they are available as changeset 7782:141cd5ffef80. You > can extract this changeset only with "hg export": > > keramida@kobe:/hg/bsd/src$ hg export 141cd5ffef80 > # HG changeset patch > # User Giorgos Keramidas > # Date 1232601528 -7200 > # Branch head > # Node ID 141cd5ffef80ff979627d8898500c92984287426 > # Parent e8506b2ac7aefbfb875f0def0de8dd6441885a40 > Add a new -x option to chown and chgrp, to inhibit file system > mount point traversal. The -x option is documented, like -v, as > a non-standard option in the COMPATIBILITY manpage sections. > > diff -r e8506b2ac7ae -r 141cd5ffef80 usr.sbin/chown/chgrp.1 > --- a/usr.sbin/chown/chgrp.1 Wed Jan 21 21:31:33 2009 +0200 > +++ b/usr.sbin/chown/chgrp.1 Thu Jan 22 07:18:48 2009 +0200 > @@ -31,7 +31,7 @@ > .\" @(#)chgrp.1 8.3 (Berkeley) 3/31/94 > .\" $FreeBSD$ > .\" > -.Dd April 25, 2003 > +.Dd January 22, 2009 > .Dt CHGRP 1 > .Os > .Sh NAME > @@ -39,7 +39,7 @@ > .Nd change group > .Sh SYNOPSIS > .Nm > -.Op Fl fhv > +.Op Fl fhvx > .Oo > .Fl R > ... snip ... > > This patch is _directly_ usable with `patch -p1' in a checkout of /head > from Subversion, but it *may* require a bit of `svn merge' work if you > have fast-forwarded chown/chgrp to its latest 'head' version. It is not > a diff of the *latest* chown/chgrp from /head but a _precise_ copy of > the past changeset, as it was committed. > > More... > ======= > > * You can browse the 'clean' head/ copy I am using at > > http://hg.hellug.gr/freebsd/head/ > > Note: this only has the head history since 2007-12-31. For older head > commits, you will have to use a new "convert" run and it will change > all the commit/changeset hashes even if their patch data is identical. > > * You can find a compressed 'bundle' file called 'head.hg' in my home > directory at freefall. This can be used to 'seed' the initial copy > of your local 'head', eg. by pulling directly from the bundle: > > % cd /var/tmp > % scp freefall.freebsd.org:'~keramida/head.hg' . > > % cd ~ > % mkdir -p ~/work/freebsd/head > % hg init ~/work/freebsd/head > % cd ~/work/freebsd/head > % hg pull /var/tmp/head.hg > > * If you plan to use the incremental conversion script I described > earlier in this message, you will also need a "SHA map" file that > maps Subversion changesets to Mercurial changeset hashes. This is > also available at freefall as `~keramida/head.shamap' and you have > to copy it to your `head/.hg/shamap' file. Then either run the "hg > convert" extension manually or use a small shell wrapper like the > one I pasted here. > > * For more information about some of the extensions I've mentioned it > is always a good idea to check the Mercurial Wiki at: > > http://www.selenic.com/mercurial/ > > I hope all this helps a bit... > > If you need more help with publishing local workspaces over http and/or > extracting patches (these are often two of the points where help is > necessary and welcome), please feel free to ask. I've been using this > sort of workflow for local changesets quite some time and I know enough > about Mercurial to help where needed. -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer From lstewart at freebsd.org Tue Aug 4 12:13:44 2009 From: lstewart at freebsd.org (Lawrence Stewart) Date: Tue Aug 4 12:14:17 2009 Subject: sosend() and mbuf In-Reply-To: <319cceca0908040259q4537db80uc2ce9696f30bfc12@mail.gmail.com> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> <319cceca0908040239k2accd7fen402db4c91687a267@mail.gmail.com> <20090804094142.GO1292@hoeg.nl> <319cceca0908040252w105d3dfdge9dec3c8b6d28607@mail.gmail.com> <20090804095650.GP1292@hoeg.nl> <319cceca0908040259q4537db80uc2ce9696f30bfc12@mail.gmail.com> Message-ID: <4A78206B.9010500@freebsd.org> Maslan wrote: > yes kio http://people.freebsd.org/~pjd/misc/kernio/ > However, It's outdated. No, man 9 ALQ is your friend. Works a treat. Cheers, Lawrence From des at des.no Tue Aug 4 16:36:50 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Aug 4 16:36:57 2009 Subject: sosend() and mbuf In-Reply-To: <319cceca0908031558h1bd779b1pac3c9454986f5488@mail.gmail.com> (Maslan's message of "Mon, 3 Aug 2009 22:58:37 +0000") References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <864ospvvkv.fsf@ds4.des.no> <319cceca0908031043x6bfe5771wa73553dce922756a@mail.gmail.com> <86eirs65gb.fsf@ds4.des.no> <319cceca0908031425r3516de29q34807cdf2c7489ed@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <319cceca0908031558h1bd779b1pac3c9454986f5488@mail.gmail.com> Message-ID: <86y6pz359b.fsf@ds4.des.no> Maslan writes: > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x10 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc085935b > [...] > #7 0xc085935b in namei (ndp=0xe6cd3bc8) at /usr/src/sys/kern/vfs_lookup.c:191 > #8 0xc08706d7 in vn_open_cred (ndp=0xe6cd3bc8, flagp=0xe6cd3cc4, cmode=1, > cred=0xc408fc00, fp=0xc4b5b344) at /usr/src/sys/kern/vfs_vnops.c:188 > #9 0xc08709a3 in vn_open (ndp=0xe6cd3bc8, flagp=0xe6cd3cc4, cmode=1, > fp=0xc4b5b344) at /usr/src/sys/kern/vfs_vnops.c:94 > #10 0xc086e0d3 in kern_open (td=0xc499dd20, path=0xc4c7a978 "/root/test.txt", > pathseg=UIO_SYSSPACE, flags=1, mode=1) > at /usr/src/sys/kern/vfs_syscalls.c:1042 > #11 0xc4c7a805 in f_open () from ./test.ko > #12 0xc4c7a8a1 in thread_main () from ./test.ko > #13 0xc07bd079 in fork_exit (callout=0xc4c7a880 , arg=0x0, > frame=0xe6cd3d38) at /usr/src/sys/kern/kern_fork.c:810 > #14 0xc0ac92b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 Depending on the exact FreeBSD version you're working on, line 191 in sys/kern/vfs_lookup.c is either 188 /* 189 * Get starting point for the translation. 190 */ * 191 FILEDESC_SLOCK(fdp); 192 ndp->ni_rootdir = fdp->fd_rdir; 193 ndp->ni_topdir = fdp->fd_jdir; or 187 /* 188 * Get starting point for the translation. 189 */ 190 FILEDESC_SLOCK(fdp); * 191 ndp->ni_rootdir = fdp->fd_rdir; 192 ndp->ni_topdir = fdp->fd_jdir; Either way, the problem is not ndp (which we know is valid), but fdp, which is dereferenced either by FILEDESC_SLOCK(), which evaluates to sx_slock(&fdp->fd_sx), or in the assignment. You're calling namei() (indirectly) from a thread assigned to proc0, and I'm pretty sure proc0 has a valid filedesc table (see proc0_init() in sys/kern/init_main.c), but all the same, I suspect that creating a separate process as I suggested earlier will fix the panic. DES -- Dag-Erling Sm?rgrav - des@des.no From julian at elischer.org Tue Aug 4 16:37:22 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 4 16:37:29 2009 Subject: sosend() and mbuf In-Reply-To: <319cceca0908040252w105d3dfdge9dec3c8b6d28607@mail.gmail.com> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> <319cceca0908040239k2accd7fen402db4c91687a267@mail.gmail.com> <20090804094142.GO1292@hoeg.nl> <319cceca0908040252w105d3dfdge9dec3c8b6d28607@mail.gmail.com> Message-ID: <4A7863D5.3000701@elischer.org> Maslan wrote: >> Is it possible to call kern_open() from within a kernel thread anyway? > I think yes, It worked on the parent thread before creating a new kthread. > See OpenKETA source, its using the same approach. I wouldn't count on that.. >> kern_open() depends on a file descriptor table, right? > Yes, it returns a fd in the curthread->td_retval[0], which i should > use within the same thread to deal with this file. and kernel threads have not file descriptors (I think) so.... it would crash... isn't that what you are seeing? > _______________________________________________ > 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 des at des.no Tue Aug 4 16:37:55 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Aug 4 16:38:02 2009 Subject: sosend() and mbuf In-Reply-To: <200908040138.14743.max@love2party.net> (Max Laier's message of "Tue, 4 Aug 2009 01:38:13 +0200") References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> Message-ID: <86tz0n357i.fsf@ds4.des.no> Max Laier writes: > IIRC, kernel threads don't have root. You mean proc0->fdp->fd_rdir is NULL? That shouldn't make any difference, the kernel panics before it dereferences fd_rdir. DES -- Dag-Erling Sm?rgrav - des@des.no From julian at elischer.org Tue Aug 4 16:40:16 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 4 16:40:25 2009 Subject: sosend() and mbuf In-Reply-To: <319cceca0908040319x35bc8bcy7a869dd230419a50@mail.gmail.com> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> <319cceca0908040239k2accd7fen402db4c91687a267@mail.gmail.com> <20090804094142.GO1292@hoeg.nl> <319cceca0908040252w105d3dfdge9dec3c8b6d28607@mail.gmail.com> <20090804095650.GP1292@hoeg.nl> <319cceca0908040259q4537db80uc2ce9696f30bfc12@mail.gmail.com> <319cceca0908040319x35bc8bcy7a869dd230419a50@mail.gmail.com> Message-ID: <4A786482.4060609@elischer.org> Maslan wrote: > OpenKETA has its own kthread_create() with a little modification from > kthread_create(), it associates the new thread with curthread not with > the thread0. hey that's horrible... (overiding a kernel symbol) > > See /usr/sys/kern/kern_kthread.c: kthread_create() > error = fork1(&thread0, RFMEM | RFFDG | RFPROC | RFSTOPPED | flags, > pages, &p2); > OpenKETA:kthread_create() > error = fork1(curthread, RFFDG | RFPROC | RFSTOPPED | flags, > pages, &p2); in 8.0 you can do this.. (see man kthread) > > I'll give it a try and see if it works. > BUT i still can't understand why kern_open() don't work, except in the > original thread. > > On Tue, Aug 4, 2009 at 9:59 AM, Maslan wrote: >> yes kio http://people.freebsd.org/~pjd/misc/kernio/ >> However, It's outdated. >> >> On Tue, Aug 4, 2009 at 9:56 AM, Ed Schouten wrote: >>> * Maslan wrote: >>>>> Is it possible to call kern_open() from within a kernel thread anyway? >>>> I think yes, It worked on the parent thread before creating a new kthread. >>>> See OpenKETA source, its using the same approach. >>>>> kern_open() depends on a file descriptor table, right? >>>> Yes, it returns a fd in the curthread->td_retval[0], which i should >>>> use within the same thread to deal with this file. >>> Didn't someone (Jeff Roberson?) develop some nice in-kernel API for >>> accessing files some years ago? Why not use that? >>> >>> -- >>> Ed Schouten >>> WWW: http://80386.nl/ >>> > _______________________________________________ > 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 Tue Aug 4 16:46:38 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 4 16:46:51 2009 Subject: sosend() and mbuf In-Reply-To: <319cceca0908040239k2accd7fen402db4c91687a267@mail.gmail.com> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> <319cceca0908040239k2accd7fen402db4c91687a267@mail.gmail.com> Message-ID: <4A786302.3090709@elischer.org> Maslan wrote: > I'm getting crazy, > > I don't know why kern_open() works in the module's main thread, but > when I use it in another thread created by kthread_create() it crashes > the kernel ??? > kernel threads may not have a file descriptor table. so kern_open may not work on kernel processes.. (just speculating) > > On Tue, Aug 4, 2009 at 9:30 AM, Ed Schouten wrote: >> Hi, >> >> * Maslan wrote: >>> man kthread says: >>> The kthread_create() function is used to create a kernel thread. The new >>> thread shares its address space with process 0, the swapper process, and >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> runs in kernel mode only. >>> >>> However, when i checked the pid & tid of the new created thread it was >>> not the same as the parent nor as the proc0 & thread0 >> I am not sure, but sharing another process's address space doesn't have >> to imply it shares the same pid, right? >> >> -- >> Ed Schouten >> WWW: http://80386.nl/ >> > _______________________________________________ > 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 Tue Aug 4 16:46:38 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 4 16:46:52 2009 Subject: sosend() and mbuf In-Reply-To: <20090804093036.GN1292@hoeg.nl> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> Message-ID: <4A786289.8010400@elischer.org> Ed Schouten wrote: > Hi, > > * Maslan wrote: >> man kthread says: >> The kthread_create() function is used to create a kernel thread. The new >> thread shares its address space with process 0, the swapper process, and > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> runs in kernel mode only. >> >> However, when i checked the pid & tid of the new created thread it was >> not the same as the parent nor as the proc0 & thread0 > > I am not sure, but sharing another process's address space doesn't have > to imply it shares the same pid, right? > there was a change where kthread_create now actually produces new THREADS in 8.0 but prior to that it produced new processes.. I THOUGHT that change happenned between 6 and 7 but maybe it was between 7 and 8.. do you have a kproc man page? on 8.0, see: man kproc man kthread on 7.0 I think these will show nothing and you should do: man kthread_create From des at des.no Tue Aug 4 16:57:27 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Aug 4 16:57:35 2009 Subject: sosend() and mbuf In-Reply-To: <20090804093036.GN1292@hoeg.nl> (Ed Schouten's message of "Tue, 4 Aug 2009 11:30:36 +0200") References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> Message-ID: <86ab2f34ay.fsf@ds4.des.no> Ed Schouten writes: > Maslan writes: > > However, when i checked the pid & tid of the new created thread it > > was not the same as the parent nor as the proc0 & thread0 > I am not sure, but sharing another process's address space doesn't have > to imply it shares the same pid, right? The man page explicitly states that if no process is specified, the new thread is assigned to proc0, which has a valid filedesc table, valid creds etc., so this shouldn't be a problem. However, he's getting a different PID, which shouldn't happen. Either the man page is wrong, or things were different in 7. DES -- Dag-Erling Sm?rgrav - des@des.no From des at des.no Tue Aug 4 17:00:27 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Aug 4 17:00:36 2009 Subject: sosend() and mbuf In-Reply-To: <4A7863D5.3000701@elischer.org> (Julian Elischer's message of "Tue, 04 Aug 2009 09:37:41 -0700") References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> <319cceca0908040239k2accd7fen402db4c91687a267@mail.gmail.com> <20090804094142.GO1292@hoeg.nl> <319cceca0908040252w105d3dfdge9dec3c8b6d28607@mail.gmail.com> <4A7863D5.3000701@elischer.org> Message-ID: <8663d3345x.fsf@ds4.des.no> Julian Elischer writes: > and kernel threads have not file descriptors (I think) so.... it > would crash... Threads don't have filedesc tables. Processes have filedesc tables. In theory, his thread is associated with proc0, which *does* have a properly initialized filedesc table. DES -- Dag-Erling Sm?rgrav - des@des.no From maslanbsd at gmail.com Tue Aug 4 17:03:57 2009 From: maslanbsd at gmail.com (Maslan) Date: Tue Aug 4 17:04:04 2009 Subject: sosend() and mbuf In-Reply-To: <4A786302.3090709@elischer.org> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> <319cceca0908040239k2accd7fen402db4c91687a267@mail.gmail.com> <4A786302.3090709@elischer.org> Message-ID: <319cceca0908041003o4c313bf6qff57a1f0b752b537@mail.gmail.com> > kernel threads may not have a file descriptor table. > so kern_open may not work on kernel processes.. > (just speculating) But the module's main thread belogs to proc, why this process could use kern_open() and proc0 don't From maslanbsd at gmail.com Tue Aug 4 17:09:06 2009 From: maslanbsd at gmail.com (Maslan) Date: Tue Aug 4 17:09:12 2009 Subject: sosend() and mbuf In-Reply-To: <319cceca0908041003o4c313bf6qff57a1f0b752b537@mail.gmail.com> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> <319cceca0908040239k2accd7fen402db4c91687a267@mail.gmail.com> <4A786302.3090709@elischer.org> <319cceca0908041003o4c313bf6qff57a1f0b752b537@mail.gmail.com> Message-ID: <319cceca0908041008p2de4452duc55467abbb121e16@mail.gmail.com> Guys, Here is the code, just scroll down and change kthread_create2() to kthread_create() and it will crash NOTE: i'm still working on the socket part, u can commend it. Something wrong with proc0, and I can't figure it out -------------- next part -------------- A non-text attachment was scrubbed... Name: khttp.c Type: application/octet-stream Size: 5863 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090804/d780c96b/khttp.obj From julian at elischer.org Tue Aug 4 17:09:35 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 4 17:09:41 2009 Subject: sosend() and mbuf In-Reply-To: <8663d3345x.fsf@ds4.des.no> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> <319cceca0908040239k2accd7fen402db4c91687a267@mail.gmail.com> <20090804094142.GO1292@hoeg.nl> <319cceca0908040252w105d3dfdge9dec3c8b6d28607@mail.gmail.com> <4A7863D5.3000701@elischer.org> <8663d3345x.fsf@ds4.des.no> Message-ID: <4A786B61.6060702@elischer.org> Dag-Erling Sm?rgrav wrote: > Julian Elischer writes: >> and kernel threads have not file descriptors (I think) so.... it >> would crash... > > Threads don't have filedesc tables. Processes have filedesc tables. In > theory, his thread is associated with proc0, which *does* have a > properly initialized filedesc table. > > DES unless he is in 7.x in which case he's getting a separate process to boot, which has no file descriptor table. From julian at elischer.org Tue Aug 4 17:20:58 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 4 17:21:05 2009 Subject: sosend() and mbuf In-Reply-To: <319cceca0908041008p2de4452duc55467abbb121e16@mail.gmail.com> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86k51k4kvl.fsf@ds4.des.no> <86fxc84ksj.fsf@ds4.des.no> <200908040138.14743.max@love2party.net> <319cceca0908040227hf9a0f92jbf05b11e9f974994@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> <319cceca0908040239k2accd7fen402db4c91687a267@mail.gmail.com> <4A786302.3090709@elischer.org> <319cceca0908041003o4c313bf6qff57a1f0b752b537@mail.gmail.com> <319cceca0908041008p2de4452duc55467abbb121e16@mail.gmail.com> Message-ID: <4A786E0C.8020201@elischer.org> Maslan wrote: > Guys, > > Here is the code, just scroll down and change kthread_create2() to > kthread_create() and it will crash > > NOTE: i'm still working on the socket part, u can commend it. > > Something wrong with proc0, and I can't figure it out > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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" The problem is that you are NOT on proc0 You have created your own kernel process and is DOES NOT have a file descriptor table. in 8.x this is all changed. using kthread_create2 creates a kernel thread attached to YOUR USER PROCESS. and YOU DO have a file descriptor table, as does proc0 as a special case of kernel process. From mel.flynn+fbsd.hackers at mailing.thruhere.net Tue Aug 4 20:45:38 2009 From: mel.flynn+fbsd.hackers at mailing.thruhere.net (Mel Flynn) Date: Tue Aug 4 20:45:45 2009 Subject: Spot the error Message-ID: <200908041245.35926.mel.flynn+fbsd.hackers@mailing.thruhere.net> Hi, granted it took me less then a minute to figure it out, but the error is kind of not helping: % mount -t msdofs /dev/label/camera ~/camera mount: /dev/label/camera : Operation not supported by device I would expect something along the lines of "unknown file system type". Is this fixable? -- Mel From jhb at freebsd.org Tue Aug 4 21:01:57 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Aug 4 21:02:04 2009 Subject: sosend() and mbuf In-Reply-To: <319cceca0908031425r3516de29q34807cdf2c7489ed@mail.gmail.com> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <86eirs65gb.fsf@ds4.des.no> <319cceca0908031425r3516de29q34807cdf2c7489ed@mail.gmail.com> Message-ID: <200908040808.05074.jhb@freebsd.org> On Monday 03 August 2009 5:25:27 pm Maslan wrote: > No my code doesn't work, I thought it may be because that soaccept() > -which is not found in man 9- is non-blocking, so i've to put my code > in a thread. > Now i got another problem, when I open a text file from this thread, > the kernel crashes, I'm sure that its the thread. > > kthread_create((void *)thread_main, NULL, NULL, RFNOWAIT, 0, "thread"); > > void thread_main(){ > struct thread *td = curthread; > int ret; > int fd; > ret = f_open("/path/to/file.txt", &fd); > printf("%d\n", ret); > tsleep(td, PDROP, "test tsleep", 10*hz); > f_close(fd); > kthread_exit(0); > } > > int f_open(char *filename, int *fd){ > struct thread *td = curthread; > int ret = kern_open(td, filename, UIO_SYSSPACE, O_RDONLY, FREAD); > if(!ret){ > *fd = td->td_retval[0]; > return 1; > } > return 0; > } kthread's / kproc's do not have a valid file descriptor table. I think you are probably not going to be happy trying to stuff a full httpd in the kernel, btw. I think instead you should look at creative ways of exposing certain bits of what you need to userland instead where possible. Alternatively, you could use a caching accelerator of some sort that maps known URLs to specific vnodes so you can reply to those directly, but when you miss in your cache you wake up a userland process which processes the URL and opens a file and you can then save the vnode from that file handle in your cache. However, stuffing httpd into the kernel may not buy you an appreciable amount of gain relative to the expense of making it work. BTW, kern_open() "works" in your module handler because the module handler runs in the kernel half of the thread from the kldload command. And when you do "kern_open()" you are actually opening a new file descriptor in the kldload process. This is quite a bad, bad idea to be indiscriminately screwing with user process' file descriptors behind their back. A brief search in the archives should cover how to initalize the necessary vnode references for a kproc's file descriptor table so that namei() works (and then you can use vn_open(), but _not_ kern_open()). I answered that question just last week in another thread ("Driver development question" on drivers@). However, in general the kernel is not nearly as friendly an environment as userland, and it can be quite saner and easier to debug if you export certain bits of the kernel to userland to accelerate portions of your application than moving the application into the kernel in my experience. -- John Baldwin From pjd at FreeBSD.org Tue Aug 4 21:37:30 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Aug 4 21:37:38 2009 Subject: sosend() and mbuf In-Reply-To: <319cceca0908031425r3516de29q34807cdf2c7489ed@mail.gmail.com> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <864ospvvkv.fsf@ds4.des.no> <319cceca0908031043x6bfe5771wa73553dce922756a@mail.gmail.com> <86eirs65gb.fsf@ds4.des.no> <319cceca0908031425r3516de29q34807cdf2c7489ed@mail.gmail.com> Message-ID: <20090804210457.GF2181@garage.freebsd.pl> On Mon, Aug 03, 2009 at 09:25:27PM +0000, Maslan wrote: > No my code doesn't work, I thought it may be because that soaccept() > -which is not found in man 9- is non-blocking, so i've to put my code > in a thread. > Now i got another problem, when I open a text file from this thread, > the kernel crashes, I'm sure that its the thread. > > kthread_create((void *)thread_main, NULL, NULL, RFNOWAIT, 0, "thread"); > > void thread_main(){ > struct thread *td = curthread; > int ret; > int fd; > ret = f_open("/path/to/file.txt", &fd); > printf("%d\n", ret); > tsleep(td, PDROP, "test tsleep", 10*hz); > f_close(fd); > kthread_exit(0); > } > > int f_open(char *filename, int *fd){ > struct thread *td = curthread; > int ret = kern_open(td, filename, UIO_SYSSPACE, O_RDONLY, FREAD); > if(!ret){ > *fd = td->td_retval[0]; > return 1; > } > return 0; > } > > I've to finish up this problem to go back for the first one. > Can you figure out what's wrong with this code, it works when I call > thread_main() rather than kthread_create((void *)thread_main, ..... When you did kern_open() without creating kernel thread, it worked, because kern_open() used file descriptor table from your current (userland) process. In FreeBSD 7.x kthread_create() creates a process without file descriptor table, so you can't use kern_open() and actually you shouldn't do this either. Take a look at sys/cddl/compat/opensolaris/kern/opensolaris_kobj.c, where you can find functions to do what you want. I guess you already considered doing all this in userland?:) -- 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/20090804/e6d41dcd/attachment.pgp From dimitry at andric.com Tue Aug 4 21:43:26 2009 From: dimitry at andric.com (Dimitry Andric) Date: Tue Aug 4 21:43:32 2009 Subject: Spot the error In-Reply-To: <200908041245.35926.mel.flynn+fbsd.hackers@mailing.thruhere.net> References: <200908041245.35926.mel.flynn+fbsd.hackers@mailing.thruhere.net> Message-ID: <4A78AB7C.3040406@andric.com> On 2009-08-04 22:45, Mel Flynn wrote: > % mount -t msdofs /dev/label/camera ~/camera > mount: /dev/label/camera : Operation not supported by device > > I would expect something along the lines of "unknown file system type". Is > this fixable? Yes, just use "msdosfs" instead. ;) That said, it looks like ENODEV is returned by vfs_domount(), whenever the fs type is not found in the list of supported filesystems: [...] if (fsflags & MNT_ROOTFS) vfsp = vfs_byname(fstype); else vfsp = vfs_byname_kld(fstype, td, &error); if (vfsp == NULL) return (ENODEV); [...] Note that in the case when vfs_byname_kld() gets called, the error it returns is silently thrown away. What a pity. :) In any case, you could paint a lot of bikesheds about which error code from errno.h would be most suited for this situation, unfortunately. And there isn't a special "unknown file system" error code, either... From maslanbsd at gmail.com Tue Aug 4 22:37:00 2009 From: maslanbsd at gmail.com (Maslan) Date: Tue Aug 4 22:37:07 2009 Subject: sosend() and mbuf In-Reply-To: <20090804210457.GF2181@garage.freebsd.pl> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <864ospvvkv.fsf@ds4.des.no> <319cceca0908031043x6bfe5771wa73553dce922756a@mail.gmail.com> <86eirs65gb.fsf@ds4.des.no> <319cceca0908031425r3516de29q34807cdf2c7489ed@mail.gmail.com> <20090804210457.GF2181@garage.freebsd.pl> Message-ID: <319cceca0908041536g71e416dao13864b7b220fb89a@mail.gmail.com> > When you did kern_open() without creating kernel thread, it worked, > because kern_open() used file descriptor table from your current > (userland) process. In FreeBSD 7.x kthread_create() creates a process > without file descriptor table, so you can't use kern_open() and actually > you shouldn't do this either. I understood now. Thanks > Take a look at sys/cddl/compat/opensolaris/kern/opensolaris_kobj.c, > where you can find functions to do what you want. > > I guess you already considered doing all this in userland?:) I'm not deploying this http server for any production, i just want to study its performance compared to a userland http server. And to experience FreeBSD kernel hacking. I'm still trying to figure out, how to play with soreceive() now. But Thanks a lot, It's now clearer for me. From julian at elischer.org Tue Aug 4 23:04:10 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 4 23:04:17 2009 Subject: sosend() and mbuf In-Reply-To: <319cceca0908041536g71e416dao13864b7b220fb89a@mail.gmail.com> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <864ospvvkv.fsf@ds4.des.no> <319cceca0908031043x6bfe5771wa73553dce922756a@mail.gmail.com> <86eirs65gb.fsf@ds4.des.no> <319cceca0908031425r3516de29q34807cdf2c7489ed@mail.gmail.com> <20090804210457.GF2181@garage.freebsd.pl> <319cceca0908041536g71e416dao13864b7b220fb89a@mail.gmail.com> Message-ID: <4A78BE7D.1010902@elischer.org> Maslan wrote: >> When you did kern_open() without creating kernel thread, it worked, >> because kern_open() used file descriptor table from your current >> (userland) process. In FreeBSD 7.x kthread_create() creates a process >> without file descriptor table, so you can't use kern_open() and actually >> you shouldn't do this either. > I understood now. Thanks > >> Take a look at sys/cddl/compat/opensolaris/kern/opensolaris_kobj.c, >> where you can find functions to do what you want. >> >> I guess you already considered doing all this in userland?:) > > I'm not deploying this http server for any production, i just want to > study its performance compared to a userland http server. > And to experience FreeBSD kernel hacking. > > I'm still trying to figure out, how to play with soreceive() now. > But Thanks a lot, It's now clearer for me. > _______________________________________________ > 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" have a look at the netgraph modules. There is a module called ksocket that allows other netgraph modules to use sockets. more than one person has implemented an in-kernel http server in a netgraph module. From mel.flynn+fbsd.hackers at mailing.thruhere.net Wed Aug 5 00:15:51 2009 From: mel.flynn+fbsd.hackers at mailing.thruhere.net (Mel Flynn) Date: Wed Aug 5 00:15:58 2009 Subject: Spot the error In-Reply-To: <4A78AB7C.3040406@andric.com> References: <200908041245.35926.mel.flynn+fbsd.hackers@mailing.thruhere.net> <4A78AB7C.3040406@andric.com> Message-ID: <200908041615.49128.mel.flynn+fbsd.hackers@mailing.thruhere.net> On Tuesday 04 August 2009 13:43:24 Dimitry Andric wrote: > On 2009-08-04 22:45, Mel Flynn wrote: > > % mount -t msdofs /dev/label/camera ~/camera > > mount: /dev/label/camera : Operation not supported by device > > > > I would expect something along the lines of "unknown file system type". > > Is this fixable? > > Yes, just use "msdosfs" instead. ;) That said, it looks like ENODEV is > returned by vfs_domount(), whenever the fs type is not found in the > list of supported filesystems: > > [...] > if (fsflags & MNT_ROOTFS) > vfsp = vfs_byname(fstype); > else > vfsp = vfs_byname_kld(fstype, td, &error); > if (vfsp == NULL) > return (ENODEV); > [...] > > Note that in the case when vfs_byname_kld() gets called, the error it > returns is silently thrown away. What a pity. :) > > In any case, you could paint a lot of bikesheds about which error code > from errno.h would be most suited for this situation, unfortunately. I would expect "Unable to load fs: " + ENOENT. I was asking if this was fixable, cause it looked like the code has been abstracted to the point that specific errors were hard, but maybe I missed something. -- Mel From dimitry at andric.com Wed Aug 5 13:50:20 2009 From: dimitry at andric.com (Dimitry Andric) Date: Wed Aug 5 13:50:27 2009 Subject: Spot the error In-Reply-To: <200908041615.49128.mel.flynn+fbsd.hackers@mailing.thruhere.net> References: <200908041245.35926.mel.flynn+fbsd.hackers@mailing.thruhere.net> <4A78AB7C.3040406@andric.com> <200908041615.49128.mel.flynn+fbsd.hackers@mailing.thruhere.net> Message-ID: <4A798E1B.9010109@andric.com> On 2009-08-05 02:15, Mel Flynn wrote: > I would expect "Unable to load fs: " + ENOENT. I was asking if this was > fixable, cause it looked like the code has been abstracted to the point that > specific errors were hard, but maybe I missed something. It does not seem easily fixable. The problem is that the mount command simply prints out the error of the system call, and doesn't have any idea which of the (many) parameters was wrong. You could change the returned error in this particular case to ENOENT, of course, but that might be considered even more confusing. Like, "What do you mean, that SCSI disk doesn't exist? It's right there in /dev!" One could also argue for EINVAL, but there's the bikeshed again... :) From alfred at freebsd.org Wed Aug 5 20:36:48 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Wed Aug 5 20:36:54 2009 Subject: Spot the error In-Reply-To: <4A798E1B.9010109@andric.com> References: <200908041245.35926.mel.flynn+fbsd.hackers@mailing.thruhere.net> <4A78AB7C.3040406@andric.com> <200908041615.49128.mel.flynn+fbsd.hackers@mailing.thruhere.net> <4A798E1B.9010109@andric.com> Message-ID: <20090805203647.GX47463@elvis.mu.org> * Dimitry Andric [090805 06:51] wrote: > On 2009-08-05 02:15, Mel Flynn wrote: > > I would expect "Unable to load fs: " + ENOENT. I was asking if this was > > fixable, cause it looked like the code has been abstracted to the point that > > specific errors were hard, but maybe I missed something. > > It does not seem easily fixable. The problem is that the mount command > simply prints out the error of the system call, and doesn't have any > idea which of the (many) parameters was wrong. > > You could change the returned error in this particular case to ENOENT, > of course, but that might be considered even more confusing. Like, > "What do you mean, that SCSI disk doesn't exist? It's right there in > /dev!" > > One could also argue for EINVAL, but there's the bikeshed again... :) mount 9 could be augmented to preflight/postflight the vfs type name through the provide a better error. -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer From jhb at freebsd.org Thu Aug 6 12:38:24 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Aug 6 12:38:31 2009 Subject: sosend() and mbuf In-Reply-To: <86ab2f34ay.fsf@ds4.des.no> References: <319cceca0908030119i3432a495ya60aa431dab0e1b1@mail.gmail.com> <20090804093036.GN1292@hoeg.nl> <86ab2f34ay.fsf@ds4.des.no> Message-ID: <200908060818.23158.jhb@freebsd.org> On Tuesday 04 August 2009 12:57:25 pm Dag-Erling Sm?rgrav wrote: > Ed Schouten writes: > > Maslan writes: > > > However, when i checked the pid & tid of the new created thread it > > > was not the same as the parent nor as the proc0 & thread0 > > I am not sure, but sharing another process's address space doesn't have > > to imply it shares the same pid, right? > > The man page explicitly states that if no process is specified, the new > thread is assigned to proc0, which has a valid filedesc table, valid > creds etc., so this shouldn't be a problem. However, he's getting a > different PID, which shouldn't happen. Either the man page is wrong, or > things were different in 7. proc0 does not have a fully valid file descriptor table. It has a structure, but fd_[cjr]dir are not initialized to point at anything. File descriptors are a property of userland processes, not of kernel processes. However, fd_[cjr]dir need to be valid to perform any namei() lookup even if one is simply going to do a vn_open() on the resulting vnode (which is more approprate for kernel code to do, if it is to open a file at all). -- John Baldwin From dougb at FreeBSD.org Thu Aug 6 18:15:20 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Thu Aug 6 18:15:27 2009 Subject: Problem in bin/sh stripping the * character through ${expansion%} Message-ID: <4A7B1DB0.1040602@FreeBSD.org> Howdy, I came across this problem during a recent portmaster update. When trying to strip off the * character using variable expansion in bin/sh it doesn't work. Other "special" characters do work if they are properly escaped. The attached mini-script clearly shows the problem: $ sh sh-strip-problem var before stripping: foo\* var after stripping: foo\* var before stripping: foo\$ var after stripping: foo\ In contrast, bash does the right thing: bash sh-strip-problem var before stripping: foo\* var after stripping: foo\ var before stripping: foo\$ var after stripping: foo\ Should I go ahead and file a PR on this? Doug -- This .signature sanitized for your protection -------------- next part -------------- var='foo\*' echo "var before stripping: $var" var=${var%\*} echo "var after stripping: $var" echo '' var='foo\$' echo "var before stripping: $var" var=${var%\$} echo "var after stripping: $var" exit 0 From johans at stack.nl Thu Aug 6 18:38:50 2009 From: johans at stack.nl (Johan van Selst) Date: Thu Aug 6 18:38:56 2009 Subject: Problem in bin/sh stripping the * character through ${expansion%} In-Reply-To: <4A7B1DB0.1040602@FreeBSD.org> References: <4A7B1DB0.1040602@FreeBSD.org> Message-ID: <20090806183846.GA68029@mud.stack.nl> Doug Barton wrote: > I came across this problem during a recent portmaster update. When > trying to strip off the * character using variable expansion in bin/sh > it doesn't work. Other "special" characters do work if they are > properly escaped. Your script does var=${var%\*} When I tried it myself, I automatically typed quotes, which does work var="${var%\*}" Alternatively you could use (with or without quotes) var="${var%[*]}" Still, I don't see a reason why your variant shouldn't work as well.. Regards, Johan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 163 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090806/11e937fb/attachment.pgp From johans at stack.nl Thu Aug 6 18:45:57 2009 From: johans at stack.nl (Johan van Selst) Date: Thu Aug 6 18:46:05 2009 Subject: Problem in bin/sh stripping the * character through ${expansion%} In-Reply-To: <20090806183846.GA68029@mud.stack.nl> References: <4A7B1DB0.1040602@FreeBSD.org> <20090806183846.GA68029@mud.stack.nl> Message-ID: <20090806184553.GA68649@mud.stack.nl> Johan van Selst wrote: > When I tried it myself, I automatically typed quotes, which does work > var="${var%\*}" Really should learn to read better: this in fact procudes 'foo' rather than 'foo\' in the given example case. Again, not like bash. Johan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 163 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090806/5a03652e/attachment.pgp From rea-fbsd at codelabs.ru Thu Aug 6 19:46:17 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Aug 6 19:46:25 2009 Subject: Problem in bin/sh stripping the * character through ${expansion%} In-Reply-To: <4A7B1DB0.1040602@FreeBSD.org> References: <4A7B1DB0.1040602@FreeBSD.org> Message-ID: Doug, good day. Thu, Aug 06, 2009 at 11:15:12AM -0700, Doug Barton wrote: > I came across this problem during a recent portmaster update. When > trying to strip off the * character using variable expansion in bin/sh > it doesn't work. Other "special" characters do work if they are > properly escaped. > > The attached mini-script clearly shows the problem: > > $ sh sh-strip-problem > var before stripping: foo\* > var after stripping: foo\* > > var before stripping: foo\$ > var after stripping: foo\ According to the sh(1), it is not a problem. Namely, - \* being unquoted at all will produce a lone '*'; - '*' when treated as the smallest pattern, will result in a stripping of a zero-length string -- it is the smallest pattern in the case of '*' that matches anything. In order to strip the trailing star you should use ----- var=${var%[*]} ----- This gives you the pattern of '[*]' that is properly treated as the single star -- it's a weird way to escape the star in the patterns. Other characters work, but only because they produce no patterns. In principle, you can try \? that will remove any trailing character no matter what, since it is the second character that will produce the pattern. > In contrast, bash does the right thing: > > bash sh-strip-problem > var before stripping: foo\* > var after stripping: foo\ > > var before stripping: foo\$ > var after stripping: foo\ I will try to look at the XCU to understand what is the POSIX way of doing the things. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From cronfy at sprinthost.ru Fri Aug 7 17:36:58 2009 From: cronfy at sprinthost.ru (cronfy) Date: Fri Aug 7 17:37:15 2009 Subject: Was system rebooted by power fail or by kernel panic? Message-ID: <4A7C6229.2040600@sprinthost.ru> Hello! Is there a way to find out was system rebooted by power fail or by kernel panic? The problem is that there is no free space on devices to store kernel core dump (swap is smaller than physical memory, no more dump devices exist). Will FreeBSD report about panic somehow if it cannot create core dump? Thanks in advance. From max at love2party.net Fri Aug 7 17:57:42 2009 From: max at love2party.net (Max Laier) Date: Fri Aug 7 17:57:50 2009 Subject: Was system rebooted by power fail or by kernel panic? In-Reply-To: <4A7C6229.2040600@sprinthost.ru> References: <4A7C6229.2040600@sprinthost.ru> Message-ID: <200908071957.39199.max@love2party.net> On Friday 07 August 2009 19:19:37 cronfy wrote: > Hello! > > Is there a way to find out was system rebooted by power fail or by > kernel panic? > > The problem is that there is no free space on devices to store kernel > core dump (swap is smaller than physical memory, no more dump devices > exist). Will FreeBSD report about panic somehow if it cannot create core > dump? You can try textdumps: http://www.freebsd.org/cgi/man.cgi?query=textdump&manpath=FreeBSD+8-current -- /"\ 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 psteele at webmail.maxiscale.com Fri Aug 7 20:56:52 2009 From: psteele at webmail.maxiscale.com (Peter Steele) Date: Fri Aug 7 21:01:46 2009 Subject: How to signal a time zone change? Message-ID: We have a suite of applications with a Java GUI controlling everything. One of the actions the user can perform is to set the time zone. We do this through our Java application and update the /etc/localtime as required. We also make an API call to tell the JVM that the time zone as changed, and from the perspective of the Java app, the time zone is changed correctly (the timestamps for example in our log files reflect the change). Likewise, after the user performs this action, running "date" on one of our systems shows that the time zone has been changed as requested. The problem is with our C applications. They continue to operate with the old time zone, so things like timestamps in log files are not in sync with the timestamps in the Java app log files. If we stop and restart the C apps they pick up the time zone change. However, we don't want to take this extreme approach. We want the Java app to signal to the C applications that the time zone has changed. However, I've experimented with the various time zone related calls and I cannot figure out what call is needed to make the C applications pick up the time zone change. I've tried setting the environment variable TZ to the new time zone and this doesn't seem to work, and I've tried calling tzset() and tzsetwall(). In each case after I make these calls the function "localtime()" does not return the same time base as the Java application. Based on what I've read, I would think that the following steps would do the trick on the C side after the Java app changes time zone and updates /etc/localtime: time_t date = time(NULL); unsetenv("TZ"); tzset(); printf("time zone is %s/%s", tzname[0], tzname[1]); struct tm* locTime = localtime(&date); printf("%02d:%02d:%02d", locTime->tm_hour, locTime->tm_min, locTime->tm_sec); The time printed in this example however is still based on the old time zone. The tzname variable that is set by tzset() still shows for example EDT even if I have just changed the time zone to PDT. If I stop and restart the C app, the time is correct, and tzname is then PDT instead of EDT. I'm very puzzled on what I'm supposed to do to kick start the time zone change in C. We do not want to have to restart our C apps for something as trivial as this. I posted this originally to the questions list but didn't get much traction. I'm hoping someone on this list can point me in the right direction. From julian at elischer.org Fri Aug 7 21:06:03 2009 From: julian at elischer.org (Julian Elischer) Date: Fri Aug 7 21:06:09 2009 Subject: How to signal a time zone change? In-Reply-To: References: Message-ID: <4A7C9738.10103@elischer.org> Peter Steele wrote: > We have a suite of applications with a Java GUI controlling everything. > One of the actions the user can perform is to set the time zone. We do > this through our Java application and update the /etc/localtime as > required. We also make an API call to tell the JVM that the time zone as > changed, and from the perspective of the Java app, the time zone is > changed correctly (the timestamps for example in our log files reflect > the change). Likewise, after the user performs this action, running > "date" on one of our systems shows that the time zone has been changed > as requested. > > > > The problem is with our C applications. They continue to operate with > the old time zone, so things like timestamps in log files are not in > sync with the timestamps in the Java app log files. If we stop and > restart the C apps they pick up the time zone change. However, we don't > want to take this extreme approach. We want the Java app to signal to > the C applications that the time zone has changed. However, I've > experimented with the various time zone related calls and I cannot > figure out what call is needed to make the C applications pick up the > time zone change. I've tried setting the environment variable TZ to the > new time zone and this doesn't seem to work, and I've tried calling You need to signal your app in some way.. Assuming you have source for the app then you can monitor /etc/localtime (or /etc) for change with kevent. > > > _______________________________________________ > 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 psteele at webmail.maxiscale.com Fri Aug 7 21:14:42 2009 From: psteele at webmail.maxiscale.com (Peter Steele) Date: Fri Aug 7 21:17:01 2009 Subject: How to signal a time zone change? References: <4A7C9738.10103@elischer.org> Message-ID: >You need to signal your app in some way.. Assuming you have source for the app then you can monitor /etc/localtime (or /etc) for change with kevent. Signaling our C apps aren't the problem. We have an IPC framework in place and we can easily tell the C apps when the user has changed the time zone via the GUI. The problem is I can't figure out what C calls are needed to instantiate the time zone change. Based on the documentation, I would think that tzset() would do the trick once /etc/localtime has been updated by the Java app, but this does not work. The only way I've discovered that works is to restart our C apps and we want to avoid that. From psteele at webmail.maxiscale.com Fri Aug 7 22:02:41 2009 From: psteele at webmail.maxiscale.com (Peter Steele) Date: Fri Aug 7 22:07:36 2009 Subject: How to signal a time zone change? References: <4A7C9738.10103@elischer.org> Message-ID: >What's the value of the TZ environment variable for the C apps? You may need to have them read the new value from somewhere, and then rerun tzset(). The default value of the TZ environment variable is null. I just tried passing the explicitly time zone value to the C app and setting TZ to that value and that seemed to work. I would think that that I should be able to retrieve that value from /etc/localtime as the docs imply. Guess not. If I have to pass the time zone to the C app, then I guess that's what I'll do... From danny at cs.huji.ac.il Sat Aug 8 10:52:48 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Sat Aug 8 10:53:06 2009 Subject: request test drivers for iscsi_initiator 2.2.3 Message-ID: This new version: o - has some bug fixes. o - has full header/data digest support, thanks to Daisuke Aoyama . o - the limit for the number of sessions is now 64, but can be raised - eventually via a sysctl call. o - the number of LUNs is unlimited, but things might get hairy over 128. o - now compiles & works under -current (8.0). The tag option is supported, but by default is set very low (0), if someone knows of a way to figure the optimal value I'll gladly add it. If it works for you, please let me know the model/make of the target so I can update the list. cheers, danny From danny at cs.huji.ac.il Sat Aug 8 10:52:50 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Sat Aug 8 10:53:07 2009 Subject: request test drivers for iscsi_initiator 2.2.3 Message-ID: wups, forgot a small little detail: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.3.tar.gz danny From mav at FreeBSD.org Sat Aug 8 15:46:08 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sat Aug 8 15:46:16 2009 Subject: request test drivers for iscsi_initiator 2.2.3 In-Reply-To: <4A7D8D7A.5030303@mavhome.dp.ua> References: <1249741381.00149226.1249729205@10.7.7.3> <4A7D8D7A.5030303@mavhome.dp.ua> Message-ID: <4A7D8F72.8090905@FreeBSD.org> Alexander Motin wrote: > Danny Braniss wrote: >> wups, forgot a small little detail: >> ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.3.tar.gz > > Is there reason why > cpi->transport = XPORT_ISCSI; > covered by > #if defined(KNOB_VALID_ADDRESS) > ? Sorry, wrong question. But those who will test on CURRENT should take care about it. -- Alexander Motin From mav at mavhome.dp.ua Sat Aug 8 15:37:38 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Sat Aug 8 17:16:49 2009 Subject: request test drivers for iscsi_initiator 2.2.3 In-Reply-To: <1249741381.00149226.1249729205@10.7.7.3> References: <1249741381.00149226.1249729205@10.7.7.3> Message-ID: <4A7D8D7A.5030303@mavhome.dp.ua> Hi. Danny Braniss wrote: > wups, forgot a small little detail: > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.3.tar.gz Is there reason why cpi->transport = XPORT_ISCSI; covered by #if defined(KNOB_VALID_ADDRESS) ? -- Alexander Motin From dougb at FreeBSD.org Sat Aug 8 18:42:06 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Aug 8 18:42:12 2009 Subject: Problem in bin/sh stripping the * character through ${expansion%} In-Reply-To: References: <4A7B1DB0.1040602@FreeBSD.org> Message-ID: <4A7DC6F6.4010802@FreeBSD.org> Eygene Ryabinkin wrote: > Doug, good day. > > Thu, Aug 06, 2009 at 11:15:12AM -0700, Doug Barton wrote: >> I came across this problem during a recent portmaster update. When >> trying to strip off the * character using variable expansion in bin/sh >> it doesn't work. Other "special" characters do work if they are >> properly escaped. >> >> The attached mini-script clearly shows the problem: >> >> $ sh sh-strip-problem >> var before stripping: foo\* >> var after stripping: foo\* >> >> var before stripping: foo\$ >> var after stripping: foo\ > > According to the sh(1), it is not a problem. Namely, > - \* being unquoted at all will produce a lone '*'; Bzzzt! :) Backslash A backslash preserves the literal meaning of the following char- acter, with the exception of the newline character (`\n'). A backslash preceding a newline is treated as a line continuation. > - '*' when treated as the smallest pattern, will result in a stripping > of a zero-length string -- it is the smallest pattern in the case of > '*' that matches anything. I agree with you if I had done ${var%*}, but the backslash should be preventing the * from being interpreted as part of the variable expansion. > In order to strip the trailing star you should use > ----- > var=${var%[*]} > ----- > This gives you the pattern of '[*]' that is properly treated as the > single star -- it's a weird way to escape the star in the patterns. That's creative, and better than the kludge I worked up for portmaster, thanks. > I will try to look at the XCU to understand what is the POSIX > way of doing the things. Great, thanks. Doug -- This .signature sanitized for your protection From danny at cs.huji.ac.il Sun Aug 9 07:00:55 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Sun Aug 9 07:01:04 2009 Subject: request test drivers for iscsi_initiator 2.2.3 In-Reply-To: <4A7D8F72.8090905@FreeBSD.org> References: <1249741381.00149226.1249729205@10.7.7.3> <4A7D8D7A.5030303@mavhome.dp.ua> <4A7D8F72.8090905@FreeBSD.org> Message-ID: > Alexander Motin wrote: > > Danny Braniss wrote: > >> wups, forgot a small little detail: > >> ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.3.tar.gz > > > > Is there reason why > > cpi->transport = XPORT_ISCSI; > > covered by > > #if defined(KNOB_VALID_ADDRESS) > > ? > I needed something to differentiate between the new CAM changes and the old (in <= 7.2), so if you have a better knob ... > Sorry, wrong question. But those who will test on CURRENT should take > care about it. why? it compiles - and works - ok under 8.0, at least till the last svn update :-) cheers, danny From krassi at bulinfo.net Mon Aug 10 11:59:02 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Mon Aug 10 11:59:09 2009 Subject: Help with device drivers Message-ID: <4A8006F3.5020800@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, Looking at sys/dev/usb/misc/ufm.c ... static int ufm_open(struct usb_fifo *dev, int fflags) { if ((fflags & (FWRITE | FREAD)) != (FWRITE | FREAD)) { return (EACCES); } return (0); } ... and sys/dev/usb/storage/urio.c ... static int urio_open(struct usb_fifo *fifo, int fflags) { struct urio_softc *sc = usb_fifo_softc(fifo); if ((fflags & (FWRITE | FREAD)) != (FWRITE | FREAD)) { return (EACCES); } ... If I try to open the device from userland with: fd = open("/dev/xxx0", O_RDWR) it fails because open() tries to open the device for reading first and then for writing. Do I use the wrong function to open such devices? Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFKgAbyxJBWvpalMpkRAt2ZAKCWfTWtaCu+1Xcf70Z9RM3+peZJ/ACgof4q ybg2Mu3tDnz6Jwc1MA/Zwzs= =Usso -----END PGP SIGNATURE----- From hselasky at c2i.net Mon Aug 10 14:27:34 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Aug 10 14:27:41 2009 Subject: Help with device drivers In-Reply-To: <4A8006F3.5020800@bulinfo.net> References: <4A8006F3.5020800@bulinfo.net> Message-ID: <200908101527.32952.hselasky@c2i.net> On Monday 10 August 2009 13:39:31 Krassimir Slavchev wrote: > If I try to open the device from userland with: > fd = open("/dev/xxx0", O_RDWR) it fails because open() tries to open the > device for reading first and then for writing. There is a bug in the code. If you open using read+write flags, then the FIFO open routine is called two times. The RD+WR check should be moved to the ioctl routine. http://perforce.freebsd.org/chv.cgi?CH=167171 --HPS From brian at FreeBSD.org Mon Aug 10 19:17:34 2009 From: brian at FreeBSD.org (Brian Somers) Date: Mon Aug 10 19:18:00 2009 Subject: How to signal a time zone change? In-Reply-To: References: <4A7C9738.10103@elischer.org> Message-ID: <20090810114913.74c0cb42@dev.lan.Awfulhak.org> On Fri, 7 Aug 2009 15:08:16 -0700 "Peter Steele" wrote: > >What's the value of the TZ environment variable for the C apps? You may > need to have them read the new value from somewhere, and then rerun > tzset(). > > The default value of the TZ environment variable is null. I just tried > passing the explicitly time zone value to the C app and setting TZ to > that value and that seemed to work. I would think that that I should be > able to retrieve that value from /etc/localtime as the docs imply. Guess > not. If I have to pass the time zone to the C app, then I guess that's > what I'll do... This doesn't work because of two bugs in localtime.c. The first is what you're hitting where tzset() calls tzset_basic() which calls tzsetwall_basic() which says: if (lcl_is_set < 0) { if (!rdlocked) _RWLOCK_UNLOCK(&lcl_rwlock); return; } If you were to have your own TZ setting and wanted to modify the file referred to by that, you'd bump into this bug in tzset_basic(): if (lcl_is_set > 0 && strcmp(lcl_TZname, name) == 0) { if (!rdlocked) _RWLOCK_UNLOCK(&lcl_rwlock); return; } Roughly translated, localtime.c goes out of its way to never re-read the same zone file twice in a row. This is just a mistake. As you discovered, altering TZ before calling tzset() is the best way to make it work right now. If you really want to ensure that you're reading /etc/localtime, this bit of hackery works too: putenv("TZ=/dev/null"); tzset(); unsetenv("TZ"); tzset(); If you raise a PR and let me know the number, I'd be happy to fix this. -- Brian Somers Don't _EVER_ lose your sense of humour ! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090810/87598d20/signature.pgp From michelle_li_001 at yahoo.com Tue Aug 11 01:36:18 2009 From: michelle_li_001 at yahoo.com (Michelle Li) Date: Tue Aug 11 01:36:25 2009 Subject: device drivers (Krassimir Slavchev) REPLY fd = open("/dev/xxx0", O_RDWR) In-Reply-To: <20090810120020.1A75610656BC@hub.freebsd.org> Message-ID: <884424.91640.qm@web65411.mail.ac4.yahoo.com> Hello Krassimir~ open() fails with [ENXIO]...or other? Please advise~ Regards m_li --- On Mon, 8/10/09, freebsd-hackers-request@freebsd.org wrote: From: freebsd-hackers-request@freebsd.org Subject: freebsd-hackers Digest, Vol 333, Issue 1 To: freebsd-hackers@freebsd.org Date: Monday, August 10, 2009, 8:00 AM Send freebsd-hackers mailing list submissions to ??? freebsd-hackers@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit ??? http://lists.freebsd.org/mailman/listinfo/freebsd-hackers or, via email, send a message with subject or body 'help' to ??? freebsd-hackers-request@freebsd.org You can reach the person managing the list at ??? freebsd-hackers-owner@freebsd.org When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-hackers digest..." Today's Topics: ???1. Help with device drivers (Krassimir Slavchev) ---------------------------------------------------------------------- Message: 1 Date: Mon, 10 Aug 2009 14:39:31 +0300 From: Krassimir Slavchev Subject: Help with device drivers To: freebsd-hackers@freebsd.org Message-ID: <4A8006F3.5020800@bulinfo.net> Content-Type: text/plain; charset=ISO-8859-1 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, Looking at sys/dev/usb/misc/ufm.c ... static int ufm_open(struct usb_fifo *dev, int fflags) { ? ? ? ? if ((fflags & (FWRITE | FREAD)) != (FWRITE | FREAD)) { ? ? ? ? ? ? ? ? return (EACCES); ? ? ? ? } ? ? ? ? return (0); } ... and sys/dev/usb/storage/urio.c ... static int urio_open(struct usb_fifo *fifo, int fflags) { ? ? ? ? struct urio_softc *sc = usb_fifo_softc(fifo); ? ? ? ? if ((fflags & (FWRITE | FREAD)) != (FWRITE | FREAD)) { ? ? ? ? ? ? ? ? return (EACCES); ? ? ? ? } ... If I try to open the device from userland with: fd = open("/dev/xxx0", O_RDWR) it fails because open() tries to open the device for reading first and then for writing. Do I use the wrong function to open such devices? Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFKgAbyxJBWvpalMpkRAt2ZAKCWfTWtaCu+1Xcf70Z9RM3+peZJ/ACgof4q ybg2Mu3tDnz6Jwc1MA/Zwzs= =Usso -----END PGP SIGNATURE----- ------------------------------ _______________________________________________ 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" End of freebsd-hackers Digest, Vol 333, Issue 1 *********************************************** From matthew at digitalstratum.com Tue Aug 11 04:25:00 2009 From: matthew at digitalstratum.com (Matthew Hagerty) Date: Tue Aug 11 04:25:07 2009 Subject: Tracing Wake on Lan problem? Message-ID: <4A80EBA6.40908@digitalstratum.com> Greetings, I'm trying to get the Wake on Lan feature working on a 7.2-release box. I have two Intel NIC's, a Pro/100 and Pro/1000 (82541PI). The Pro/100 worked great right from the start using the generic kernel and was detected by the fxp driver. Using the wol (from ports) on another box fired the WoL box right up. However, I would like to use the gigabit card in the WoL box, which is detected by the em driver, and according to the WoL wiki and some posts to hackers a few months ago, the em driver does not have WoL support yet. I went digging and actually found FreeBSD specific drivers (in source code form) on Intel's site (would never have guessed that in a million years) and the code provided builds an if_em kernel load module. So I built a custom kernel removing all network card drivers. Then I built and installed the Intel provided if_em module. The system starts fine and configures the NIC, but I still do not have WoL ability. What can I do to track down where the problem might be? Here are some details: # dmesg . . . em0: port 0x14c0-0x14ff mem 0x40200000-0x4021ffff,0x40300000-0x4031ffff irq 18 at device 9.0 on pci2 . . . 6.9.12 is the version in the source code provided by Intel. The em driver that comes with 7.2R is 6.9.6 I believe. Device 0x107c matches my NIC in the e1000_hw.h file: #define E1000_DEV_ID_82541GI_LF 0x107C # sysctl -a | grep em.0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.12 dev.em.0.%driver: em dev.em.0.%location: slot=9 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x107c subvendor=0x8086 subdevice=0x1376 class=0x020000 dev.em.0.%parent: pci2 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 # ifconfig -m em0 em0: flags=8843 metric 0 mtu 1500 options=9b capabilities=19b ether 00:1b:21:3a:32:ed inet 10.0.81.6 netmask 0xffffff00 broadcast 10.0.81.255 media: Ethernet autoselect (1000baseTX ) status: active supported media: media autoselect media 1000baseTX media 1000baseTX mediaopt full-duplex media 100baseTX mediaopt full-duplex media 100baseTX media 10baseT/UTP mediaopt full-duplex media 10baseT/UTP The card does not report WoL in its capabilities, however the datasheet (http://download.intel.com/design/network/datashts/318138.pdf) indicates WoL support. # kldstat Id Refs Address Size Name 1 8 0xc0400000 536ef8 kernel 2 1 0xc0937000 31eec if_em.ko 3 1 0xc0969000 6a45c acpi.ko 4 1 0xc238b000 3000 daemon_saver.ko # kldstat -v . . . 2 1 0xc0937000 31eec if_em.ko Contains modules: Id Name 1 pci/em . . . The if_em.c code from Intel also have functions for dealing with WoL: /* Management and WOL Support */ static void em_init_manageability(struct adapter *); static void em_release_manageability(struct adapter *); static void em_get_hw_control(struct adapter *); static void em_release_hw_control(struct adapter *); static void em_enable_wakeup(device_t); I've been reading through the code to see if there is any reason why my specific chipset would be ignored or have special #ifdefs, etc., but I don't see anything. Only the multi-port fiber cards seem to have special code (only port A supports the WoL it seems). I'm pretty good with C but have no device driver programming experience (but I would like to learn some). Any tips or pointers on how I can proceeded to solving this would be greatly appreciated. Also, is there any reason Intel's source is not provided with FreeBSD, since it seems they have taken the time to write the driver? Probably a copyright thing right? Either way, I'd like to get this working if possible. Thanks, Matthew From krassi at bulinfo.net Tue Aug 11 06:06:32 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Tue Aug 11 06:06:38 2009 Subject: Help with device drivers In-Reply-To: <200908101527.32952.hselasky@c2i.net> References: <4A8006F3.5020800@bulinfo.net> <200908101527.32952.hselasky@c2i.net> Message-ID: <4A810A62.1070408@bulinfo.net> Hans Petter Selasky wrote: > On Monday 10 August 2009 13:39:31 Krassimir Slavchev wrote: >> If I try to open the device from userland with: >> fd = open("/dev/xxx0", O_RDWR) it fails because open() tries to open the >> device for reading first and then for writing. > > There is a bug in the code. If you open using read+write flags, then the FIFO > open routine is called two times. The RD+WR check should be moved to the ioctl > routine. > > http://perforce.freebsd.org/chv.cgi?CH=167171 Thanks! It seems that sys/dev/usb/storage/urio.c should be fixed too? Best Regards > > --HPS > > _______________________________________________ > 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 hselasky at c2i.net Tue Aug 11 07:58:37 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Aug 11 07:58:44 2009 Subject: Help with device drivers In-Reply-To: <4A810A62.1070408@bulinfo.net> References: <4A8006F3.5020800@bulinfo.net> <200908101527.32952.hselasky@c2i.net> <4A810A62.1070408@bulinfo.net> Message-ID: <200908110858.41835.hselasky@c2i.net> On Tuesday 11 August 2009 08:06:26 Krassimir Slavchev wrote: > Hans Petter Selasky wrote: > > On Monday 10 August 2009 13:39:31 Krassimir Slavchev wrote: > >> If I try to open the device from userland with: > >> fd = open("/dev/xxx0", O_RDWR) it fails because open() tries to open the > >> device for reading first and then for writing. > > > > There is a bug in the code. If you open using read+write flags, then the > > FIFO open routine is called two times. The RD+WR check should be moved to > > the ioctl routine. > > > > http://perforce.freebsd.org/chv.cgi?CH=167171 > > Thanks! > > It seems that sys/dev/usb/storage/urio.c should be fixed too? > > Best Regards > > > --HPS You are right! http://perforce.freebsd.org/chv.cgi?CH=167199 --HPS From rb at gid.co.uk Tue Aug 11 08:37:23 2009 From: rb at gid.co.uk (Bob Bishop) Date: Tue Aug 11 08:37:32 2009 Subject: Tracing Wake on Lan problem? In-Reply-To: <4A80EBA6.40908@digitalstratum.com> References: <4A80EBA6.40908@digitalstratum.com> Message-ID: <06A3B5AF-D3DA-4446-84EF-93314B2EA636@gid.co.uk> Hi, On 11 Aug 2009, at 04:55, Matthew Hagerty wrote: > I'm trying to get the Wake on Lan feature working on a 7.2-release > box. [etc] You may need to turn WoL on in the BIOS, have a look in the same place as the LAN boot settings. -- Bob Bishop rb@gid.co.uk From matthew at digitalstratum.com Tue Aug 11 15:15:37 2009 From: matthew at digitalstratum.com (Matthew Hagerty) Date: Tue Aug 11 15:15:44 2009 Subject: Tracing Wake on Lan problem? In-Reply-To: <06A3B5AF-D3DA-4446-84EF-93314B2EA636@gid.co.uk> References: <4A80EBA6.40908@digitalstratum.com> <06A3B5AF-D3DA-4446-84EF-93314B2EA636@gid.co.uk> Message-ID: <4A818B0E.7090609@digitalstratum.com> Bob Bishop wrote: > Hi, > > On 11 Aug 2009, at 04:55, Matthew Hagerty wrote: > >> I'm trying to get the Wake on Lan feature working on a 7.2-release >> box. [etc] > > You may need to turn WoL on in the BIOS, have a look in the same place > as the LAN boot settings. > > -- > Bob Bishop > rb@gid.co.uk I guess I assumed that, since the WoL works with my Intel Pro/100 NIC, that the APCI and wake-up settings in the BIOS were set correctly. It is only when I try the Pro/1000 that I'm having problems; and it seems to be a driver or config issue. Matthew From vince at unsane.co.uk Tue Aug 11 15:37:50 2009 From: vince at unsane.co.uk (Vincent Hoffman) Date: Tue Aug 11 15:37:57 2009 Subject: Tracing Wake on Lan problem? In-Reply-To: <4A818B0E.7090609@digitalstratum.com> References: <4A80EBA6.40908@digitalstratum.com> <06A3B5AF-D3DA-4446-84EF-93314B2EA636@gid.co.uk> <4A818B0E.7090609@digitalstratum.com> Message-ID: <4A819049.6030806@unsane.co.uk> Matthew Hagerty wrote: > Bob Bishop wrote: >> Hi, >> >> On 11 Aug 2009, at 04:55, Matthew Hagerty wrote: >> >>> I'm trying to get the Wake on Lan feature working on a 7.2-release >>> box. [etc] >> >> You may need to turn WoL on in the BIOS, have a look in the same >> place as the LAN boot settings. >> >> -- >> Bob Bishop >> rb@gid.co.uk > I guess I assumed that, since the WoL works with my Intel Pro/100 NIC, > that the APCI and wake-up settings in the BIOS were set correctly. It > is only when I try the Pro/1000 that I'm having problems; and it seems > to be a driver or config issue. > > Matthew I think you are out of luck as yet. according to http://wiki.freebsd.org/WakeOnLan grep -l IFCAP_WOL /usr/src/sys/dev/*/*.c should get a list of drivers that support WOL. 16:28:19 <~>) [jhary@crab] 0 $ grep -l IFCAP_WOL /usr/src/sys/dev/*/*.c /usr/src/sys/dev/ae/if_ae.c /usr/src/sys/dev/age/if_age.c /usr/src/sys/dev/alc/if_alc.c /usr/src/sys/dev/ale/if_ale.c /usr/src/sys/dev/fxp/if_fxp.c /usr/src/sys/dev/jme/if_jme.c /usr/src/sys/dev/nge/if_nge.c /usr/src/sys/dev/re/if_re.c /usr/src/sys/dev/stge/if_stge.c /usr/src/sys/dev/txp/if_txp.c /usr/src/sys/dev/vr/if_vr.c (16:28:21 <~>) [jhary@crab] 0 $ uname -r 7.2-STABLE The Pro/1000 driver is if_em (or if_igb) So i think you are out of luck on 7.x Vince > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From matthew at digitalstratum.com Tue Aug 11 16:03:04 2009 From: matthew at digitalstratum.com (Matthew Hagerty) Date: Tue Aug 11 16:03:10 2009 Subject: Tracing Wake on Lan problem? In-Reply-To: <4A819049.6030806@unsane.co.uk> References: <4A80EBA6.40908@digitalstratum.com> <06A3B5AF-D3DA-4446-84EF-93314B2EA636@gid.co.uk> <4A818B0E.7090609@digitalstratum.com> <4A819049.6030806@unsane.co.uk> Message-ID: <4A819634.5050503@digitalstratum.com> Vincent Hoffman wrote: > Matthew Hagerty wrote: > >> Bob Bishop wrote: >> >>> Hi, >>> >>> On 11 Aug 2009, at 04:55, Matthew Hagerty wrote: >>> >>> >>>> I'm trying to get the Wake on Lan feature working on a 7.2-release >>>> box. [etc] >>>> >>> You may need to turn WoL on in the BIOS, have a look in the same >>> place as the LAN boot settings. >>> >>> -- >>> Bob Bishop >>> rb@gid.co.uk >>> >> I guess I assumed that, since the WoL works with my Intel Pro/100 NIC, >> that the APCI and wake-up settings in the BIOS were set correctly. It >> is only when I try the Pro/1000 that I'm having problems; and it seems >> to be a driver or config issue. >> >> Matthew >> > > > I think you are out of luck as yet. according to > http://wiki.freebsd.org/WakeOnLan > grep -l IFCAP_WOL /usr/src/sys/dev/*/*.c > should get a list of drivers that support WOL. > > 16:28:19 <~>) > [jhary@crab] 0 $ grep -l IFCAP_WOL /usr/src/sys/dev/*/*.c > /usr/src/sys/dev/ae/if_ae.c > /usr/src/sys/dev/age/if_age.c > /usr/src/sys/dev/alc/if_alc.c > /usr/src/sys/dev/ale/if_ale.c > /usr/src/sys/dev/fxp/if_fxp.c > /usr/src/sys/dev/jme/if_jme.c > /usr/src/sys/dev/nge/if_nge.c > /usr/src/sys/dev/re/if_re.c > /usr/src/sys/dev/stge/if_stge.c > /usr/src/sys/dev/txp/if_txp.c > /usr/src/sys/dev/vr/if_vr.c > (16:28:21 <~>) > [jhary@crab] 0 $ uname -r > 7.2-STABLE > > The Pro/1000 driver is if_em (or if_igb) So i think you are out of luck > on 7.x > > > Vince > Correct, the stock if_em.c code that comes with 7.2R does not have the WoL support. However, I'm using the the source code driver from Intel that does seem to support WoL (see my original post for details). The Intel provided em driver compiles into a kernel load module, and as far as I can tell it is being loaded and working just fine; other than the WoL part. I was hoping to get some tips on how I might trace through the driver, add some debug info, run some elite commands that only kernel hackers know about, etc., to determine why my NIC is not reporting support for WoL even though the Intel em driver supports it. Matthew From matthew at digitalstratum.com Tue Aug 11 16:17:59 2009 From: matthew at digitalstratum.com (Matthew Hagerty) Date: Tue Aug 11 16:18:06 2009 Subject: Tracing Wake on Lan problem? In-Reply-To: <58c737d70908110858l3548e91cnddb5fa1b85a29533@mail.gmail.com> References: <4A80EBA6.40908@digitalstratum.com> <06A3B5AF-D3DA-4446-84EF-93314B2EA636@gid.co.uk> <4A818B0E.7090609@digitalstratum.com> <4A819049.6030806@unsane.co.uk> <58c737d70908110858l3548e91cnddb5fa1b85a29533@mail.gmail.com> Message-ID: <4A8199B2.30403@digitalstratum.com> Chris Ruiz wrote: > On Tue, Aug 11, 2009 at 10:37 AM, Vincent Hoffman wrote: > >> Matthew Hagerty wrote: >> >>> Bob Bishop wrote: >>> >>>> Hi, >>>> >>>> On 11 Aug 2009, at 04:55, Matthew Hagerty wrote: >>>> >>>> >>>>> I'm trying to get the Wake on Lan feature working on a 7.2-release >>>>> box. [etc] >>>>> >>>> You may need to turn WoL on in the BIOS, have a look in the same >>>> place as the LAN boot settings. >>>> >>>> -- >>>> Bob Bishop >>>> rb@gid.co.uk >>>> >>> I guess I assumed that, since the WoL works with my Intel Pro/100 NIC, >>> that the APCI and wake-up settings in the BIOS were set correctly. It >>> is only when I try the Pro/1000 that I'm having problems; and it seems >>> to be a driver or config issue. >>> >>> Matthew >>> >> I think you are out of luck as yet. according to >> http://wiki.freebsd.org/WakeOnLan >> grep -l IFCAP_WOL /usr/src/sys/dev/*/*.c >> should get a list of drivers that support WOL. >> >> 16:28:19 <~>) >> [jhary@crab] 0 $ grep -l IFCAP_WOL /usr/src/sys/dev/*/*.c >> /usr/src/sys/dev/ae/if_ae.c >> /usr/src/sys/dev/age/if_age.c >> /usr/src/sys/dev/alc/if_alc.c >> /usr/src/sys/dev/ale/if_ale.c >> /usr/src/sys/dev/fxp/if_fxp.c >> /usr/src/sys/dev/jme/if_jme.c >> /usr/src/sys/dev/nge/if_nge.c >> /usr/src/sys/dev/re/if_re.c >> /usr/src/sys/dev/stge/if_stge.c >> /usr/src/sys/dev/txp/if_txp.c >> /usr/src/sys/dev/vr/if_vr.c >> (16:28:21 <~>) >> [jhary@crab] 0 $ uname -r >> 7.2-STABLE >> >> The Pro/1000 driver is if_em (or if_igb) So i think you are out of luck >> on 7.x >> > > Vince is correct, the e1000 (if_em/igb) driver does not support WOL, yet. > > Chris > Yes, but I'm trying to use Intel's driver at this point (since the stock 7.2R em driver, as stated, does not support WoL yet): http://downloadcenter.intel.com/filter_results.aspx?strTypes=all&ProductID=1938&OSFullName=FreeBSD*&lang=eng&strOSs=52&submit=Go! And it does appear to offer support for WoL. They (Intel) have functions in their if_em.c source file that sets up the WoL. However, there is no IFCAP_WOL define in Intel's code, so maybe it does not interface with ifconfig correctly at this point? I don't know. I was hoping to get some pointers on where to look or how to tell. Also, I'm not opposed to adding the WoL support - I'm not too bad in C - I've just never written a FreeBSD device driver and the excellent post by Stefan Sperling (referenced from the WoL wiki) seems to be too far out of date. The wiki itself states: "Note that the obsolete ioctl-based configuration approach is discussed there, but ifcaps should be used instead." So, not knowing anything about either ioctl-based or ifcaps config, I can't find any resources on how to get started in the right direction (hence my post to hackers). Also, if Intel's driver code works, it seems to me that it makes more sense to use their code for em devices, no? Is there a copyright problem with that? Matthew From yr.retarded at gmail.com Tue Aug 11 16:23:57 2009 From: yr.retarded at gmail.com (Chris Ruiz) Date: Tue Aug 11 16:24:04 2009 Subject: Tracing Wake on Lan problem? In-Reply-To: <4A819049.6030806@unsane.co.uk> References: <4A80EBA6.40908@digitalstratum.com> <06A3B5AF-D3DA-4446-84EF-93314B2EA636@gid.co.uk> <4A818B0E.7090609@digitalstratum.com> <4A819049.6030806@unsane.co.uk> Message-ID: <58c737d70908110858l3548e91cnddb5fa1b85a29533@mail.gmail.com> On Tue, Aug 11, 2009 at 10:37 AM, Vincent Hoffman wrote: > Matthew Hagerty wrote: >> Bob Bishop wrote: >>> Hi, >>> >>> On 11 Aug 2009, at 04:55, Matthew Hagerty wrote: >>> >>>> I'm trying to get the Wake on Lan feature working on a 7.2-release >>>> box. [etc] >>> >>> You may need to turn WoL on in the BIOS, have a look in the same >>> place as the LAN boot settings. >>> >>> -- >>> Bob Bishop >>> rb@gid.co.uk >> I guess I assumed that, since the WoL works with my Intel Pro/100 NIC, >> that the APCI and wake-up settings in the BIOS were set correctly. ?It >> is only when I try the Pro/1000 that I'm having problems; and it seems >> to be a driver or config issue. >> >> Matthew > > > I think ?you are out of luck as yet. according to > http://wiki.freebsd.org/WakeOnLan > grep -l IFCAP_WOL /usr/src/sys/dev/*/*.c > should get a list of drivers that support WOL. > > 16:28:19 <~>) > [jhary@crab] 0 $ grep -l IFCAP_WOL /usr/src/sys/dev/*/*.c > /usr/src/sys/dev/ae/if_ae.c > /usr/src/sys/dev/age/if_age.c > /usr/src/sys/dev/alc/if_alc.c > /usr/src/sys/dev/ale/if_ale.c > /usr/src/sys/dev/fxp/if_fxp.c > /usr/src/sys/dev/jme/if_jme.c > /usr/src/sys/dev/nge/if_nge.c > /usr/src/sys/dev/re/if_re.c > /usr/src/sys/dev/stge/if_stge.c > /usr/src/sys/dev/txp/if_txp.c > /usr/src/sys/dev/vr/if_vr.c > (16:28:21 <~>) > [jhary@crab] 0 $ uname -r > 7.2-STABLE > > The Pro/1000 driver is if_em (or if_igb) So i think you are out of luck > on 7.x Vince is correct, the e1000 (if_em/igb) driver does not support WOL, yet. Chris From vince at unsane.co.uk Wed Aug 12 10:13:24 2009 From: vince at unsane.co.uk (Vincent Hoffman) Date: Wed Aug 12 10:13:30 2009 Subject: Tracing Wake on Lan problem? In-Reply-To: <4A8199B2.30403@digitalstratum.com> References: <4A80EBA6.40908@digitalstratum.com> <06A3B5AF-D3DA-4446-84EF-93314B2EA636@gid.co.uk> <4A818B0E.7090609@digitalstratum.com> <4A819049.6030806@unsane.co.uk> <58c737d70908110858l3548e91cnddb5fa1b85a29533@mail.gmail.com> <4A8199B2.30403@digitalstratum.com> Message-ID: <4A8295BA.5030206@unsane.co.uk> Matthew Hagerty wrote: > >> > Yes, but I'm trying to use Intel's driver at this point (since the > stock 7.2R em driver, as stated, does not support WoL yet): > > http://downloadcenter.intel.com/filter_results.aspx?strTypes=all&ProductID=1938&OSFullName=FreeBSD*&lang=eng&strOSs=52&submit=Go! > > > And it does appear to offer support for WoL. They (Intel) have > functions in their if_em.c source file that sets up the WoL. However, > there is no IFCAP_WOL define in Intel's code, so maybe it does not > interface with ifconfig correctly at this point? I don't know. I was > hoping to get some pointers on where to look or how to tell. Also, > I'm not opposed to adding the WoL support - I'm not too bad in C - > I've just never written a FreeBSD device driver and the excellent post > by Stefan Sperling (referenced from the WoL wiki) seems to be too far > out of date. > > The wiki itself states: "Note that the obsolete ioctl-based > configuration approach is discussed there, but ifcaps should be used > instead." > > So, not knowing anything about either ioctl-based or ifcaps config, I > can't find any resources on how to get started in the right direction > (hence my post to hackers). > > Also, if Intel's driver code works, it seems to me that it makes more > sense to use their code for em devices, no? Is there a copyright > problem with that? Sorry I missed the first email or two and didnt realise you were trying the latest from the intel site. Intel (well an intel employee but as part of his day job from what I understand from his posts,) maintains the driver in the source tree. The last I remember him saying about wake on lan for em was http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009461.html As to why FreeBSD isnt using the one currently on the intel site, not certain but it may just be a case of it needing updating/committing, as an email from the maintainer http://markmail.org/message/u4crubkss3354nlt indicates from a previous similar enquiry. hope that helps, Vince > > Matthew > > _______________________________________________ > 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 pyunyh at gmail.com Wed Aug 12 19:24:50 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Aug 12 19:25:23 2009 Subject: Tracing Wake on Lan problem? In-Reply-To: <4A818B0E.7090609@digitalstratum.com> References: <4A80EBA6.40908@digitalstratum.com> <06A3B5AF-D3DA-4446-84EF-93314B2EA636@gid.co.uk> <4A818B0E.7090609@digitalstratum.com> Message-ID: <20090812190314.GA55129@michelle.cdnetworks.com> On Tue, Aug 11, 2009 at 11:15:26AM -0400, Matthew Hagerty wrote: > Bob Bishop wrote: > >Hi, > > > >On 11 Aug 2009, at 04:55, Matthew Hagerty wrote: > > > >>I'm trying to get the Wake on Lan feature working on a 7.2-release > >>box. [etc] > > > >You may need to turn WoL on in the BIOS, have a look in the same place > >as the LAN boot settings. > > > >-- > >Bob Bishop > >rb@gid.co.uk > I guess I assumed that, since the WoL works with my Intel Pro/100 NIC, > that the APCI and wake-up settings in the BIOS were set correctly. It > is only when I try the Pro/1000 that I'm having problems; and it seems > to be a driver or config issue. > em(4) implemented WOL in its own way so it may work on some models. Last time I tried it on my T400 it didn't work. Quick reading the code shows a couple of required things are still missing in em(4). Probably Jack knows when it could be done.(CCed) From lgj at usenix.org Thu Aug 13 21:58:03 2009 From: lgj at usenix.org (Lionel Garth Jones) Date: Thu Aug 13 22:39:57 2009 Subject: USENIX HotPar '10 Call For Papers Now Available Message-ID: The Program Committee for the 2nd USENIX Workshop on Hot Topics in Parallelism (HotPar '10) invites you to submit position papers. HotPar '10 will bring together researchers and practitioners doing innovative work in the area of parallel computing. HotPar recognizes the broad impact of multicore computing and seeks relevant contributions in all fields, including application design, languages and compilers, systems, and architecture. We request submissions of position papers that propose new directions for research of products in these areas, advocate non-traditional approaches to the problems engendered by parallelism, or potentially generate controversy and discussion. Submissions are due January 24, 2010. More information and submission guidelines are available at http://www.usenix.org/hotpar10/cfpa We look forward to receiving your submissions! Sincerely, Geoff Lowney, Intel David Patterson, University of California, Berkeley HotPar '10 Program Co-Chairs hotpar10chairs@usenix.org From bertwiley at gmail.com Fri Aug 14 03:58:44 2009 From: bertwiley at gmail.com (bert wiley) Date: Fri Aug 14 03:58:51 2009 Subject: Need help trying to to use the ntohl() call with in_addr Message-ID: <9527461a0908132029xb2c6149r9f51c775d22ae670@mail.gmail.com> Hi everyone Im new to list and this question may be out of place. This is my first post. Im new to freebsd and trying to understand how to create a jail from some system calls. I followed the jail subsystem description from the handbook and im having a problem or may be using the call incorrectly. But here is what im trying to do. int main() { struct in_addr ipaddr; struct jail myjail; char path[PATH_MAX]; realpath("/tmp", path); myjail.version = 1; myjail.path = path; myjail.hostname = "testjail"; const char *ip; ip = "192.168.1.142"; inet_aton(ip, &ipaddr); myjail.ip4 = ntohl(ipaddr.s_addr); // I get and error here, invalid conversion from _uint32_t' to in_addr* myjail.ip4 = ipaddr.s_addr; // and and error here, invlid conversion from in_addr_t to in_addr* } I know that there is more that needs to be done but this just a test stub as im trying to work thru the calls and understand whats going on. Any would be appreciated thanks. From max at love2party.net Fri Aug 14 07:44:46 2009 From: max at love2party.net (Max Laier) Date: Fri Aug 14 07:44:53 2009 Subject: Need help trying to to use the ntohl() call with in_addr In-Reply-To: <9527461a0908132029xb2c6149r9f51c775d22ae670@mail.gmail.com> References: <9527461a0908132029xb2c6149r9f51c775d22ae670@mail.gmail.com> Message-ID: <200908140944.44141.max@love2party.net> On Friday 14 August 2009 05:29:19 bert wiley wrote: > Hi everyone > > Im new to list and this question may be out of place. This is my first > post. Im new to freebsd and trying to understand how to create a jail from > some system calls. I followed the jail subsystem description from the > handbook and im having a problem or may be using the call incorrectly. But > here is what im trying to do. > > > int main() > { > struct in_addr ipaddr; > struct jail myjail; > > char path[PATH_MAX]; > > realpath("/tmp", path); > > myjail.version = 1; > myjail.path = path; > myjail.hostname = "testjail"; > > const char *ip; > ip = "192.168.1.142"; > > inet_aton(ip, &ipaddr); > myjail.ip4 = ntohl(ipaddr.s_addr); // I get and error here, invalid > conversion from _uint32_t' to in_addr* > myjail.ip4 = ipaddr.s_addr; // and and error here, invlid > conversion from in_addr_t to in_addr* > } > > > I know that there is more that needs to be done but this just a test stub > as im trying to work thru the calls and understand whats going on. > Any would be appreciated thanks. Take a look at the jail(2) man page: The ``ip4s'' and ``ip6s'' give the numbers of IPv4 and IPv6 addresses that will be passed via their respective pointers. The ``ip4'' and ``ip6'' pointers can be set to an arrays of IPv4 and IPv6 addresses to be assigned to the prison, or NULL if none. IPv4 addresses must be in network byte order. So you'd do something like the following: myjail.ip4s = 1; inet_aton(ip, &ipaddr); myjail.ip4 = &ipaddr; You don't have to switch byte order. -- /"\ 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 bzeeb-lists at lists.zabbadoz.net Fri Aug 14 08:30:32 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri Aug 14 08:30:39 2009 Subject: Need help trying to to use the ntohl() call with in_addr In-Reply-To: <200908140944.44141.max@love2party.net> References: <9527461a0908132029xb2c6149r9f51c775d22ae670@mail.gmail.com> <200908140944.44141.max@love2party.net> Message-ID: <20090814080915.J93661@maildrop.int.zabbadoz.net> On Fri, 14 Aug 2009, Max Laier wrote: > On Friday 14 August 2009 05:29:19 bert wiley wrote: >> Hi everyone >> >> Im new to list and this question may be out of place. This is my first >> post. Im new to freebsd and trying to understand how to create a jail from >> some system calls. I followed the jail subsystem description from the >> handbook and im having a problem or may be using the call incorrectly. But >> here is what im trying to do. >> >> >> int main() >> { >> struct in_addr ipaddr; >> struct jail myjail; >> >> char path[PATH_MAX]; >> >> realpath("/tmp", path); >> >> myjail.version = 1; >> myjail.path = path; >> myjail.hostname = "testjail"; >> >> const char *ip; >> ip = "192.168.1.142"; >> >> inet_aton(ip, &ipaddr); >> myjail.ip4 = ntohl(ipaddr.s_addr); // I get and error here, invalid >> conversion from _uint32_t' to in_addr* >> myjail.ip4 = ipaddr.s_addr; // and and error here, invlid >> conversion from in_addr_t to in_addr* >> } >> >> >> I know that there is more that needs to be done but this just a test stub >> as im trying to work thru the calls and understand whats going on. >> Any would be appreciated thanks. > > Take a look at the jail(2) man page: > > The ``ip4s'' and ``ip6s'' give the numbers of IPv4 and IPv6 addresses > that will be passed via their respective pointers. > > The ``ip4'' and ``ip6'' pointers can be set to an arrays of IPv4 and IPv6 > addresses to be assigned to the prison, or NULL if none. IPv4 addresses > must be in network byte order. > > So you'd do something like the following: > > myjail.ip4s = 1; > inet_aton(ip, &ipaddr); > myjail.ip4 = &ipaddr; > > You don't have to switch byte order. and in that case of 7.2-R or later multi-IP jails the version should not be 1 either. I fixed tools/regressions/priv the other day; maybe this helps a bit as well: http://svn.freebsd.org/viewvc/base/head/tools/regression/priv/main.c?r1=173679&r2=196172 /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From bertwiley at gmail.com Fri Aug 14 19:01:43 2009 From: bertwiley at gmail.com (bertwiley@gmail.com) Date: Fri Aug 14 19:01:50 2009 Subject: Need help trying to to use the ntohl() call with in_addr In-Reply-To: <20090814080915.J93661@maildrop.int.zabbadoz.net> Message-ID: <0016e640d1e0ca8bd304711eaeb7@google.com> Thanks guys On Aug 14, 2009 4:11am, "Bjoern A. Zeeb" wrote: > On Fri, 14 Aug 2009, Max Laier wrote: > On Friday 14 August 2009 05:29:19 bert wiley wrote: > Hi everyone > Im new to list and this question may be out of place. This is my first > post. Im new to freebsd and trying to understand how to create a jail from > some system calls. I followed the jail subsystem description from the > handbook and im having a problem or may be using the call incorrectly. But > here is what im trying to do. > int main() > { > struct in_addr ipaddr; > struct jail myjail; > char path[PATH_MAX]; > realpath("/tmp", path); > myjail.version = 1; > myjail.path = path; > myjail.hostname = "testjail"; > const char *ip; > ip = "192.168.1.142"; > inet_aton(ip, &ipaddr); > myjail.ip4 = ntohl(ipaddr.s_addr); // I get and error here, invalid > conversion from _uint32_t' to in_addr* > myjail.ip4 = ipaddr.s_addr; // and and error here, invlid > conversion from in_addr_t to in_addr* > } > I know that there is more that needs to be done but this just a test stub > as im trying to work thru the calls and understand whats going on. > Any would be appreciated thanks. > Take a look at the jail(2) man page: > The ``ip4s'' and ``ip6s'' give the numbers of IPv4 and IPv6 addresses > that will be passed via their respective pointers. > The ``ip4'' and ``ip6'' pointers can be set to an arrays of IPv4 and IPv6 > addresses to be assigned to the prison, or NULL if none. IPv4 addresses > must be in network byte order. > So you'd do something like the following: > myjail.ip4s = 1; > inet_aton(ip, &ipaddr); > myjail.ip4 = &ipaddr; > You don't have to switch byte order. > and in that case of 7.2-R or later multi-IP jails the version should > not be 1 either. > I fixed tools/regressions/priv the other day; maybe this helps a bit > as well: > http://svn.freebsd.org/viewvc/base/head/tools/regression/priv/main.c?r1=173679&r2=196172 > /bz > -- > Bjoern A. Zeeb What was I talking about and who are you again? From bu7cher at yandex.ru Fri Aug 14 21:19:32 2009 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Fri Aug 14 21:19:39 2009 Subject: Howto setup multiboot with GPT? Message-ID: <147751250284069@webmail117.yandex.ru> Hi, I have installed 8.0-BETA2 amd64 on ZFS root with GPT. I made addition partition and made new ZFS pool, builded and installed i386 world and kernel to this pool. So, is there some way to select from which partition i want to boot? My configuration: > gpart show ad10 => 34 1250263661 ad10 GPT (596G) 34 256 1 freebsd-boot (128K) 290 8388608 2 freebsd-swap (4.0G) 8388898 209715200 3 freebsd-zfs (100G) 218104098 209715200 4 freebsd-zfs (100G) 427819298 822444397 - free - (392G) > zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT amd64 99,5G 10,5G 89,0G 10% ONLINE - x86 99,5G 346M 99,2G 0% ONLINE /mnt > cat /boot/loader.conf zfs_load="YES" vfs.root.mountfrom="zfs:amd64" > zfs list -r amd64 NAME USED AVAIL REFER MOUNTPOINT amd64 10,5G 87,5G 511M legacy amd64/distfiles 1,10G 87,5G 1,10G /usr/ports/distfiles amd64/home 4,29G 87,5G 4,26G /usr/home amd64/local 1,91G 87,5G 1,91G /usr/local amd64/obj 1,29G 87,5G 1,29G /usr/obj amd64/ports 162M 87,5G 162M /usr/ports amd64/src 405M 87,5G 405M /usr/src amd64/tmp 26,7M 87,5G 4,96M /tmp amd64/usr 263M 87,5G 263M /usr amd64/var 532M 87,5G 524K /var amd64/var/crash 411M 87,5G 411M /var/crash amd64/var/db 120M 87,5G 120M /var/db amd64/var/tmp 112K 87,5G 79K /var/tmp > zfs list -r x86 NAME USED AVAIL REFER MOUNTPOINT x86 346M 97,6G 170M legacy x86/local 18K 97,6G 18K /mnt/usr/local x86/tmp 23K 97,6G 23K /mnt/tmp x86/usr 175M 97,6G 175M /mnt/usr x86/var 241K 97,6G 178K /mnt/var x86/var/crash 18,5K 97,6G 18,5K /mnt/var/crash x86/var/db 25K 97,6G 25K /mnt/var/db x86/var/tmp 19K 97,6G 19K /mnt/var/tmp -- WBR, Andrey V. Elsukov From oliver.pntr at gmail.com Sat Aug 15 23:25:30 2009 From: oliver.pntr at gmail.com (Oliver Pinter) Date: Sat Aug 15 23:25:37 2009 Subject: Security: information leaks in /proc enable keystroke recovery In-Reply-To: <200908152221.n7FMLRuw005799@taverner.cs.berkeley.edu> References: <200908152221.n7FMLRuw005799@taverner.cs.berkeley.edu> Message-ID: <6101e8c40908151625s52ad9b83ue061de3fab97fbf8@mail.gmail.com> On 8/16/09, David Wagner wrote: > At Usenix Security 2009, two researchers announced last week a new > security vulnerability in multi-user Linux systems. They demonstrated > that one user can, in many cases, recover partial information about > the keystrokes that another user types into applications running on > that system. For instance, they demonstrate how a malicious user can > recover partial information about SSH passwords typed by other users, > reducing the password search space by a factor of 250-2000x in > their experiments. Thus, this could facilitate password recovery. > > Question: Are there any plans to modify the Linux kernel to defend > against this kind of attack? > > The paper is here: > > http://www.usenix.org/events/sec09/tech/full_papers/zhang.pdf > > In a nutshell, they exploit the fact that many files in /proc are > world-readable yet contain sensitive information that can leak information > about inter-keystroke timings. For instance, /proc/$PID/stat reveals the > ESP and EIP registers of the associated process, and is world-readable. > /proc/pid/status is also mentioned as revealing information that could > be exploited in these attacks. > > Based on my understanding of their work, it sounds like some of > the information on those files should perhaps not be world-readable. > It's not clear to me that it's reasonable for the kernel to reveal ESP, > EIP, and other sensitive information about process behavior to everyone > on the same system. > > Are folks already aware of these vulnerabilities? Is there any work > underway to try to address the issues identified in the Usenix Security > paper? > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > [snip] 6.2 Information Leaks in the Procfs of Other UNIX-like Systems Besides Linux, most other UNIX-like systems also im- plement procfs. These implementations vary from case to case, and as a result, their susceptibilities to side- channel attacks also differ. Here we discuss such privacy risks on two systems, FreeBSD and OpenSolaris. FreeBSD manages its process ?les more cautiously than Linux12 : it puts all register values into the ?le /proc/pid/regs that can only be read by the owner of a process, which blocks the information used by our attack. However, we found that other informa- tion released by the procfs can lead to similar attacks. A prominent example is the system time reported by /proc/pid/status, a ?le open to every user. Fig- ure 11 shows the correlations between the time con- sumed by vim and the keystrokes it received, as ob- served in our research. This demonstrates that keystroke events within the process can be identi?ed from the change of its system time, which makes keystroke eaves- dropping possible. A problem here is that we may not be able to detect special keys a user enters, for example, ?MOV CURSOR?, which is determined from ESP/EIP in- formation on Linux. A possible solution is using the dis- crepancies of system-time increments triggered by dif- ferent keys being entered to ?ngerprint these individual keys. Further study of this technique is left to our future research. [/snip] From rwatson at FreeBSD.org Sun Aug 16 20:06:42 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Aug 16 20:06:50 2009 Subject: Security: information leaks in /proc enable keystroke recovery In-Reply-To: <6101e8c40908151625s52ad9b83ue061de3fab97fbf8@mail.gmail.com> References: <200908152221.n7FMLRuw005799@taverner.cs.berkeley.edu> <6101e8c40908151625s52ad9b83ue061de3fab97fbf8@mail.gmail.com> Message-ID: On Sun, 16 Aug 2009, Oliver Pinter wrote: > FreeBSD manages its process ?les more cautiously than Linux12 : it puts all > register values into the ?le /proc/pid/regs that can only be read by the > owner of a process, which blocks the information used by This is inaccurate, but largely in an academic sense. The FreeBSD kernels computes debug permissions between two processes from a number of factors, including: - Comparison of uids (effective, real, saved) - Comparison of gids (effective, real, saved) - Subset check on the additional group set - Jail information - Mandatory access control policies There are some other checks that fit the pattern of credential comparison less well: - We deny debugger activity during execve(2) as a robustness protection against possible race conditions. - We have global policy controls, security.bsd.see_other_gids and security.bsd.see_other_uids, which allow administrators to scope not just debugging facilities, but also monitoring facilities. - We have a global policy control, security.bsd.unprivileged_proc_debug, to disable debugging facilities for unprivileged users, on the grounds that (a) this is sometimes a desirable system policy, and (b) all UNIX systems have historically suffered from significant debugger security vulnerabilities and this provides an easy work-around to use if that happens in the future. Which is to say: the UNIX file system permissions appearing in procfs are purely decorative -- they roughly summarize, but do not implement, the above checks. procfs is also deprecated in FreeBSD, and has not been mounted by default for several major releases. Instead, the system call interfaces ktrace(2), ptrace(2), and sysctl(2) provide access to trace data, process debugging, and process state (such as address space layout and file descriptor information). Some legacy setgid kvm tools exist that use libkvm and /dev/kmem, but we are eliminating these as quickly as we can; they may not follow the same policies as those implemented in the kernel. The see_other_uids and see_other_gids policy sysctls narrow the policy on inter-process visibility via monitoring controls -- however, additional hardening is required to enforce this policy universally. For example, administrators will also need to limit access to logs, accounting data, and so on, for this to be fully effective. Beyond this, and assuming the correct implementation of the above, we're into the grounds of classic trusted OS covert channel analysis, against which no COTS UNIX OSes I'm aware of are hardened. This isn't to dismiss these attacks as purely hypothetical -- we've seen some rather compelling examples of covert channels being exploited in unexpected and remarkably practical ways in the last few years (Steven Murdoch's "Hot or Not" paper takes the cake in that regard, I think). However, this next step up from "the kernel doesn't reveal information on processes from other users" involves scheduler hardening, consideration of inter-CPU/core/thread cache interactions, and so on -- things that we don't have a good research, let alone production, OS understanding of. There are tools in FreeBSD that can help with some of these issues -- for example, you can use login classes to pin different users to different CPU threads, cores, or packages. However, this leaves the implementation of policy up to the administrator, rather than simply allowing the administator to specify the policy that mutually untrusting processes can't share CPUs with each other in some window. Robert N M Watson Computer Laboratory University of Cambridge From daw at cs.berkeley.edu Sun Aug 16 21:53:36 2009 From: daw at cs.berkeley.edu (David Wagner) Date: Sun Aug 16 22:28:46 2009 Subject: Security: information leaks in /proc enable keystroke recovery In-Reply-To: from "Robert Watson" at Aug 16, 2009 09:06:41 PM Message-ID: <200908162109.n7GL9JNK029605@taverner.cs.berkeley.edu> Thanks for the comments. > Beyond this, and assuming the correct implementation of the above, > we're into the grounds of classic trusted OS covert channel analysis, > against which no COTS UNIX OSes I'm aware of are hardened. This isn't to > dismiss these attacks as purely hypothetical -- we've seen some rather > compelling examples of covert channels being exploited in unexpected > and remarkably practical ways in the last few years (Steven Murdoch's > "Hot or Not" paper takes the cake in that regard, I think). To be pedantic, I'd say that the Usenix Security paper describes a side channel, not a covert channel. The paper shows how a malicious attacker can attack an unsuspecting victim application. Covert channels are when both the sender and the receiver are malicious and cooperating to transmit information from the sender to the receiver. In contrast, side channels arise when the "sender" is unintentionally and inadvertently leaking information that can be decoded by a malicious receiver, against the interests of the "sender". The attack in the paper is a side channel, not a covert channel. When it comes to covert channels, it is indeed reasonable to throw up your hands and say that defending against covert channels is basically impossible, so why bother? For side channels, though, it's less clear that this is a persuasive argument. I agree we certainly shouldn't discuss the keystroke recovery attack as hypothetical, because it is clearly not hypothetical: the authors implemented it and found that it works. > However, this next step up from "the kernel doesn't reveal information on > processes from other users" involves scheduler hardening, consideration > of inter-CPU/core/thread cache interactions, and so on -- things that we > don't have a good research, let alone production, OS understanding of. Indeed. A major challenge. Good to hear that, in its default configuration, FreeBSD does eliminate the attack vector described in the Usenix Security paper (the EIP/ESP leak). It seems a good starting point would be to limit access to information that we know can enable keystroke recovery -- as FreeBSD apparently already does, but Linux apparently does not. From rwatson at FreeBSD.org Sun Aug 16 23:25:11 2009 From: rwatson at FreeBSD.org (Robert N. M. Watson) Date: Sun Aug 16 23:25:44 2009 Subject: Security: information leaks in /proc enable keystroke recovery In-Reply-To: <200908162109.n7GL9JNK029605@taverner.cs.berkeley.edu> References: <200908162109.n7GL9JNK029605@taverner.cs.berkeley.edu> Message-ID: <7F29E9E1-AB92-45E3-9DF3-C8455533BA19@FreeBSD.org> On 16 Aug 2009, at 22:09, David Wagner wrote: >> Beyond this, and assuming the correct implementation of the above, >> we're into the grounds of classic trusted OS covert channel analysis, >> against which no COTS UNIX OSes I'm aware of are hardened. This >> isn't to >> dismiss these attacks as purely hypothetical -- we've seen some >> rather >> compelling examples of covert channels being exploited in unexpected >> and remarkably practical ways in the last few years (Steven Murdoch's >> "Hot or Not" paper takes the cake in that regard, I think). > > To be pedantic, I'd say that the Usenix Security paper describes a > side > channel, not a covert channel. The paper shows how a malicious > attacker > can attack an unsuspecting victim application. > > Covert channels are when both the sender and the receiver are > malicious > and cooperating to transmit information from the sender to the > receiver. > In contrast, side channels arise when the "sender" is unintentionally > and inadvertently leaking information that can be decoded by a > malicious > receiver, against the interests of the "sender". The attack in the > paper is a side channel, not a covert channel. When it comes to > covert > channels, it is indeed reasonable to throw up your hands and say that > defending against covert channels is basically impossible, so why > bother? > For side channels, though, it's less clear that this is a persuasive > argument. Hi David-- I see what you're saying, but I'm not sure I entirely agree on the pedantic definitions front ("two can play at this game"). Historically interesting definitions in DoD 5200.28-STD ("The Orange Book") and NCSC-TG-030 ("A Guide to Understanding Covert Channel Analysis of Trusted Systems") are decidedly hazy on the concept of intention, with some portions specific on its involvement and others entirely disregarding it. These definitions come out of trusted OS research/ development, and might be considered historically anachronistic by some. To my mind, the OS timing issue we're discussing meet two of the definitions of "covert channel" presented in NCSC-TG-030: Definition 4: Covert channels are those that "use entities not normally viewed as data objects to transfer information from one subject to another." Definition 5: Given a non-discretionary (e.g., mandatory) security policy model M and its interpretation I(M) in an operating system, any potential communication between two subjects I(Sh) and I(Si) of I(m) is covert if and only if any communication between the corresponding subject Sh and Si of the model M is illegal in M. Which is to say: what makes something a "covert channel" is not the intention to communicate in violation of a policy, but the *possibility* of communication in violation of system design or security policy. Both documents are concerned primarily with intentional leakage/corruption of information in confidentiality and integrity policies, but their definitions appear more general. The use of the word "mandatory" here is certainly one that also bears consideration: I would argue that the system integrity constraints of historic UNIX, such as those on inter-process control vectors (debugging, signals, ...) do in fact constitute a mandatory policy, albeit not based on information flow control or a particularly clean or well-documented model. As an example: unprivileged users are permitted only limited scope under the discretionary access control policy to delegate rights for objects they own. They can delegate to another user write access to a file via open(2), but not the right to chown the file using chown(2), signal a process using kill(2), etc, making the protections that prevent these operations "mandatory". I would argue that undesired information leakage via I/O timing across process monitoring interfaces qualifies as a covert channel under both definitions above: it's not an intended communication channel provided by the OS design, and that the OS security policy is not intended to allow unintentional communication of I/O data without explicit delegation. The historic covert channel analysis of the timing problem, drawn out in somewhat painful detail in NCSC-TG-030, seems pretty much to apply to this problem. I wouldn't argue that EIP leakage in procfs counted, on the other hand, as it appears to be an intentional, if in retrospect unfortunate, part of the design and policy. I wouldn't doubt that countless other similar "oh, perhaps not" cases of information leakage exist across countless variations on the UNIX theme due to monitoring and debugging interfaces -- for example, netstat's reporting of TCP pending send/receive queues seems likely subject to quite similar problems, as with timestamps on device nodes in /dev, even network interface or protocol statistics from netstat. Coming down on the other side of pedantic, BTW, the Orange Book's definition of "Covert storage channels" seems to ignore intention, "Covert timing channels" seems to require it. >> However, this next step up from "the kernel doesn't reveal >> information on >> processes from other users" involves scheduler hardening, >> consideration >> of inter-CPU/core/thread cache interactions, and so on -- things >> that we >> don't have a good research, let alone production, OS understanding >> of. > > Indeed. A major challenge. Good to hear that, in its default > configuration, FreeBSD does eliminate the attack vector described in > the Usenix Security paper (the EIP/ESP leak). It seems a good > starting > point would be to limit access to information that we know can enable > keystroke recovery -- as FreeBSD apparently already does, but Linux > apparently does not. NCSC-TG-030 has quite a bit to say on the topic of these sorts of things, albeit addressed at a different context and in a different time. I find myself skeptical that the sorts of protections we are waving our hands at apply all that well to UNIX-like systems due to their origin as time-sharing systems. However, I think a more interesting place to direct this analysis would be the current flush of hypervisors, which appear (possibly even claim) to offer much stronger separation in a less time-sharesque way. Robert From daw at cs.berkeley.edu Mon Aug 17 00:58:37 2009 From: daw at cs.berkeley.edu (David Wagner) Date: Mon Aug 17 01:12:43 2009 Subject: Security: information leaks in /proc enable keystroke recovery In-Reply-To: <7F29E9E1-AB92-45E3-9DF3-C8455533BA19@FreeBSD.org> from "Robert N. M. Watson" at Aug 17, 2009 12:25:07 AM Message-ID: <200908170058.n7H0wahu005383@taverner.cs.berkeley.edu> I still think my definitions of "covert channel" vs "side channel" better reflect accepted usage these days, but whatever. I don't have any great desire to debate the definitions. That doesn't seem like a good use of everyone's time. I was trying to define some shorthand to more concisely make my point. Since it appears my preferred shorthand turned out to be a barrier to communication, rather than an aid, I'll try to make my point again, this time spelling it out without using the problematic shorthand. I care more about the ultimate point than the language we use to communicate it. My broader point is this: I accept your argument that there is no point trying to defend against deliberate communication of information between two cooperating processes via some sneaky channel; there is no hope of stopping that in general-purpose commodity OS's. If process X and Y are both colluding to send information from X to Y, they will succeed, no matter how hard we try. We have no hope of closing all such channels, for general-purpose commodity OS's (like FreeBSD or Linux). However I do not accept that this argument means we should throw up our hands and ignore cases where the kernel allows malicious process Y to spy on process X, against X's will. If the kernel has a leak that lets process Y eavesdrop on keystrokes typed into process X, that's arguably worth fixing. Trying to prevent that is not clearly hopeless. There is a significant difference in threat model between "both X and Y are malicious and colluding with each other to facilitate some joint purpose shared by both X and Y" vs "Y is malicious and is attempting to subvert the security of process X, against X's will". If the designers deliberately intended to allow process Y to snoop on the ESP and EIP of process X, even when there is no relationship between X and Y (e.g., they don't have the same uid, and Y isn't root), well, I would claim that was a design error. Facilitating keystroke recovery does not seem like a good design goal. It's possible that the impact could be broader than discussed in the Usenix Security paper. Imagine if process X is doing crypto, say an RSA decryption, and process Y is running on the same machine and is malicious. If process Y is allowed to observe the EIP of process X, then process Y may be able to observe which path process X has taken through the code. In some cases, such as a naive implementation of RSA decryption, this may reveal X's private key. Leaking EIP and ESP to every other user on the same system strikes me as pretty dubious. From rwatson at FreeBSD.org Mon Aug 17 10:11:19 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Aug 17 10:11:25 2009 Subject: Security: information leaks in /proc enable keystroke recovery In-Reply-To: <200908170058.n7H0wahu005383@taverner.cs.berkeley.edu> References: <200908170058.n7H0wahu005383@taverner.cs.berkeley.edu> Message-ID: On Sun, 16 Aug 2009, David Wagner wrote: > I accept your argument that there is no point trying to defend against > deliberate communication of information between two cooperating processes > via some sneaky channel; there is no hope of stopping that in > general-purpose commodity OS's. If process X and Y are both colluding to > send information from X to Y, they will succeed, no matter how hard we try. > We have no hope of closing all such channels, for general-purpose commodity > OS's (like FreeBSD or Linux). Moving beyind EIP/ESP, which are clearly a bad idea: The OS community has not engaged well with the concerns raised by past cache-based crypto side channels, in part because it seemed the least complex solution was hardening crypto against having key-driven footprints in the cache. However, the problem they represent (avoiding the use of shared resources between mutually untrusting processes, and then mitigating efects that remain) definitely sounds like the covert channel problem, with very similar concerns extensively discussed in the documents I referred to. In an interactive system, the scheduling of threads in a process reflect the completion of various events: user I/O, network I/O, disk I/O, or perhaps the expiration of a timer associated with application-internal events (animations, statistics, etc). Monitoring these from another process is intentionally easy on commodity OS's -- there are a variety of monitoring statistics, from the already mentioned process/thread execution time, to context switch counters, wait channels/addresses, lock states, timestamps on special devices, etc, not to mention having CPU sink processes that nice themselves appropriately and hang around monitoring execution of other processes/threads/the kernel through gaps in its own scheduling. Some of the intentional mechanisms are specific to processes, and easy to block by policy. Others are global, and begin the sliding down the slope of "making the system and applications a lot harder to analyze and debug", something that sites frequently hosting large numbers of mutually untrusting users (web farms) may not be willing to deal do. Into the area of techniques that annoy people: my guess is that you may also be able to measure the context switching of processes on other CPUs through very careful timing of events in the kernel on your local CPU. For example, it's a reasonable bet that using the TSC and carefully selected system calls/arguments, you can measure cache line behavior associated with kernel scheduler/statistic lines that will be pulled to another CPU when a context switch takes place. For example, consider per-CPU run queue locks or context switch statistics, which may in edge cases be pulled to another CPU, such as when monitoring takes place. If they are already local to the attacking CPU, no context switch has taken place on the other CPU since you last checked; if they're non-local, a context switch has taken place. Following Colin Percival's paper on cache side channels for RSA, there was a lot of discussion about how the OS could help mitigate these problems: do you provide "security critical sections" around cryptography which introduce temporary but performance-degrading mutual exclusion of caches based on knowledge of the CPU topology, for example. Identifying and offering similar trade-offs between performance and security, avoiding excess complexity, and in particular, limiting the scope of those performance losses to only critical moments will be key if the security community wants to engage the OS community here. Otherwise I suspect these concerns will pass by, unaddressed, again. Robert N M Watson Computer Laboratory University of Cambridge From jhb at freebsd.org Mon Aug 17 14:11:50 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Aug 17 14:12:11 2009 Subject: Howto setup multiboot with GPT? In-Reply-To: <147751250284069@webmail117.yandex.ru> References: <147751250284069@webmail117.yandex.ru> Message-ID: <200908170932.54700.jhb@freebsd.org> On Friday 14 August 2009 5:07:49 pm Andrey V. Elsukov wrote: > Hi, > > I have installed 8.0-BETA2 amd64 on ZFS root with GPT. I made addition partition and > made new ZFS pool, builded and installed i386 world and kernel to this pool. > So, is there some way to select from which partition i want to boot? Not currently unless you hardcode a specific partition in /boot.config. (You may need a patch from jhay@ to fix the parsing of that file though.) I believe someone (can't recall who) has some changes in a p4 branch to extend gptboot to support a fancier interface with a menu of possible partitions, etc. -- John Baldwin From artis.caune at gmail.com Mon Aug 17 15:14:43 2009 From: artis.caune at gmail.com (Artis Caune) Date: Mon Aug 17 15:14:50 2009 Subject: Howto setup multiboot with GPT? In-Reply-To: <147751250284069@webmail117.yandex.ru> References: <147751250284069@webmail117.yandex.ru> Message-ID: <9e20d71e0908170743v49cad8f6le715524ce93331b7@mail.gmail.com> 2009/8/15 Andrey V. Elsukov : > Hi, > > I have installed 8.0-BETA2 amd64 on ZFS root with GPT. I made addition partition and > made new ZFS pool, builded and installed i386 world and kernel to this pool. > So, is there some way to select from which partition i want to boot? > > My configuration: >> gpart show ad10 > => ? ? ? ?34 ?1250263661 ?ad10 ?GPT ?(596G) > ? ? ? ? ?34 ? ? ? ? 256 ? ? 1 ?freebsd-boot ?(128K) > ? ? ? ? 290 ? ? 8388608 ? ? 2 ?freebsd-swap ?(4.0G) > ? ? 8388898 ? 209715200 ? ? 3 ?freebsd-zfs ?(100G) > ? 218104098 ? 209715200 ? ? 4 ?freebsd-zfs ?(100G) > ? 427819298 ? 822444397 ? ? ? ?- free - ?(392G) > >> zpool list > NAME ? ?SIZE ? USED ?AVAIL ? ?CAP ?HEALTH ?ALTROOT > amd64 ?99,5G ?10,5G ?89,0G ? ?10% ?ONLINE ?- > x86 ? ?99,5G ? 346M ?99,2G ? ? 0% ?ONLINE ?/mnt > >> cat /boot/loader.conf > zfs_load="YES" > vfs.root.mountfrom="zfs:amd64" You can try using one freebsd-zfs partition, one pool and just change bootfs zpool property: # zpool create rpool ad10p3 # zfs create rpool/ROOT/amd64 # zfs create rpool/ROOT/x86 # zpool set bootfs=rpool/amd64 rpool echo 'vfs.root.mountfrom="zfs:rpool/amd64"' >> /ROOT/amd64/boot/loader.conf echo 'vfs.root.mountfrom="zfs:rpool/x86"' >> /ROOT/x86/boot/loader.conf and then change bootfs on the fly: amd64# zpool set bootfs=rpool/x86 rpool amd64# reboot x86# zpool set bootfs=rpool/amd64 rpool x86# reboot -- Artis Caune Everything should be made as simple as possible, but not simpler. From jhay at meraka.org.za Mon Aug 17 16:51:37 2009 From: jhay at meraka.org.za (John Hay) Date: Mon Aug 17 16:52:11 2009 Subject: Howto setup multiboot with GPT? In-Reply-To: <200908170932.54700.jhb@freebsd.org> References: <147751250284069@webmail117.yandex.ru> <200908170932.54700.jhb@freebsd.org> Message-ID: <20090817163230.GA68166@zibbi.meraka.csir.co.za> On Mon, Aug 17, 2009 at 09:32:54AM -0400, John Baldwin wrote: > On Friday 14 August 2009 5:07:49 pm Andrey V. Elsukov wrote: > > Hi, > > > > I have installed 8.0-BETA2 amd64 on ZFS root with GPT. I made addition partition and > > made new ZFS pool, builded and installed i386 world and kernel to this pool. > > So, is there some way to select from which partition i want to boot? > > Not currently unless you hardcode a specific partition in /boot.config. (You > may need a patch from jhay@ to fix the parsing of that file though.) I > believe someone (can't recall who) has some changes in a p4 branch to extend > gptboot to support a fancier interface with a menu of possible partitions, > etc. My patch is only for gptboot (ufs partitions). From what I looked at gptzfsboot, it only looks at the first pool. You can boot from different filesystems inside a pool though. You can set that with zpool set bootfs=pool/dataset John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From doconnor at gsoft.com.au Wed Aug 19 03:39:08 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Wed Aug 19 03:39:15 2009 Subject: PCI IRQ latency Message-ID: <200908191253.27951.doconnor@gsoft.com.au> Hi, We have a custom PCI (slave only, very slow) card to do data transfer, and on some systems we are seeing problems with the data source FIFO filling up. The data rate is 1.7Mb/sec and the FIFO is 96k in size, however it only generates an IRQ when it has 16k of data in it, so it should have ~4.5msec of buffer available once an IRQ is issued. The systems are Supermicro C2SBA+ with Core 2 Duos of varying speeds (~1.5GHz) running FreeBSD 6.2 amd64. The kernel conf is basically GENERIC, although I have also tried compiling out SMP but the problem still persists. The card is not sharing an IRQ with any other card I can see (it has irq 20 and nothing else uses that). Due to the legacy nature of the card the interrupt handler for it is pretty horrible - it reads 16k worth of data out 32 bits at a time doing slave transactions. I can't do bursting because it is reading from a FIFO, and due to the speed of the FIFO & cable runs each read takes several PCI cycles. I did some googling and found http://www.mail-archive.com/freebsd-usb%40freebsd.org/msg04576.html which would seem to indicate we would be OK. Unfortunately it seems that _something_ blocks interrupts for >4 milliseconds, however I have no real idea how to go about finding what it is.. Does anyone have any suggestions? (apart from get a new DAQ card, I know this one already :) Thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090819/5c6d6de2/attachment.pgp From zbeeble at gmail.com Wed Aug 19 07:08:14 2009 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Wed Aug 19 07:08:21 2009 Subject: PCI IRQ latency In-Reply-To: <200908191253.27951.doconnor@gsoft.com.au> References: <200908191253.27951.doconnor@gsoft.com.au> Message-ID: <5f67a8c40908182335y59679131u373e8a3b27856909@mail.gmail.com> On Tue, Aug 18, 2009 at 11:23 PM, Daniel O'Connor wrote: > Unfortunately it seems that _something_ blocks interrupts for >4 > milliseconds, however I have no real idea how to go about finding what > it is.. Does anyone have any suggestions? (apart from get a new DAQ > card, I know this one already :) This is a huge shot-in-the-dark, but could this be something like ACPI or some other motherboard legacy cpu-using evil? Would it be possible to test on something opposite-ish of what you're using (ie: amd vs. intel) just to cycle out all the potential goo? From doconnor at gsoft.com.au Wed Aug 19 07:18:37 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Wed Aug 19 07:18:43 2009 Subject: PCI IRQ latency In-Reply-To: <5f67a8c40908182335y59679131u373e8a3b27856909@mail.gmail.com> References: <200908191253.27951.doconnor@gsoft.com.au> <5f67a8c40908182335y59679131u373e8a3b27856909@mail.gmail.com> Message-ID: <200908191648.28262.doconnor@gsoft.com.au> On Wed, 19 Aug 2009, Zaphod Beeblebrox wrote: > On Tue, Aug 18, 2009 at 11:23 PM, Daniel O'Connor wrote: > > Unfortunately it seems that _something_ blocks interrupts for >4 > > milliseconds, however I have no real idea how to go about finding > > what it is.. Does anyone have any suggestions? (apart from get a > > new DAQ card, I know this one already :) > > This is a huge shot-in-the-dark, but could this be something like > ACPI or some other motherboard legacy cpu-using evil? Would it be > possible to test on something opposite-ish of what you're using (ie: > amd vs. intel) just to cycle out all the potential goo? It's worth a shot, I'll see if I can dig up some other hardware, thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090819/44aa0d22/attachment.pgp From doconnor at gsoft.com.au Wed Aug 19 07:22:21 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Wed Aug 19 07:22:28 2009 Subject: PCI IRQ latency In-Reply-To: <200908191253.27951.doconnor@gsoft.com.au> References: <200908191253.27951.doconnor@gsoft.com.au> Message-ID: <200908191652.11825.doconnor@gsoft.com.au> On Wed, 19 Aug 2009, Daniel O'Connor wrote: > Unfortunately it seems that _something_ blocks interrupts for >4 > milliseconds, however I have no real idea how to go about finding > what it is.. Does anyone have any suggestions? (apart from get a new > DAQ card, I know this one already :) Actually it appears I have misread my diagnostics and it's not a lack of interrupts, rather the reading process gets stalled (by up to 5 seconds at a time). Sorry for the noise :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090819/f9c3040a/attachment.pgp From des at des.no Wed Aug 19 09:11:30 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Aug 19 09:11:39 2009 Subject: Security: information leaks in /proc enable keystroke recovery In-Reply-To: <200908162109.n7GL9JNK029605@taverner.cs.berkeley.edu> (David Wagner's message of "Sun, 16 Aug 2009 14:09:19 -0700 (PDT)") References: <200908162109.n7GL9JNK029605@taverner.cs.berkeley.edu> Message-ID: <861vn85zvr.fsf@ds4.des.no> David Wagner writes: > I agree we certainly shouldn't discuss the keystroke recovery attack > as hypothetical, because it is clearly not hypothetical: the authors > implemented it and found that it works. It *is* hypothetical. They were able to collect some keystrokes (but not all) in Linux, but IIUC, all they could do in FreeBSD was figure out whether or not a key was pressed at a certain time (or during a certain interval). They *hypothesize* that the interval between keystrokes can be used to identify the keys being pressed, but they haven't actually done it. I can imagine - purely hypothetically - that it would be possible, but only while the user was typing running text; the parameters would vary greatly from typist to typist, and between keyboard layouts, and you could probably defeat it pretty easily (at least some of the time) by deliberately typing slowly and arythmically, e.g. typing in your password with only one finger. DES -- Dag-Erling Sm?rgrav - des@des.no From doconnor at gsoft.com.au Wed Aug 19 14:01:39 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Wed Aug 19 14:01:46 2009 Subject: DTrace probes & klds Message-ID: <200908192331.34507.doconnor@gsoft.com.au> Is it possible? the handbook implies not and I can't get it to work, but i could be doing it wrong.. I get fbt traces listed for KLDs (I get new entries for each load of the KLD which seems like a potential problem) but I can't specify an SDT_PROBE and have it work. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090819/ee31d450/attachment.pgp From doconnor at gsoft.com.au Thu Aug 20 07:43:13 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Aug 20 07:43:20 2009 Subject: DTrace probes & klds In-Reply-To: <20090820081740.436656fu6d4fxoso@webmail.leidinger.net> References: <200908192331.34507.doconnor@gsoft.com.au> <20090820081740.436656fu6d4fxoso@webmail.leidinger.net> Message-ID: <200908201713.08368.doconnor@gsoft.com.au> On Thu, 20 Aug 2009, Alexander Leidinger wrote: > Quoting Daniel O'Connor (from Wed, 19 Aug > 2009 > > 23:31:33 +0930): > > Content-Type: text/plain; > > charset="utf-8" > > Content-Transfer-Encoding: quoted-printable > > Content-Disposition: inline > > > > Is it possible? the handbook implies not and I can't get it to > > work, but i could be doing it wrong.. > > > > I get fbt traces listed for KLDs (I get new entries for each load > > of the KLD which seems like a potential problem) but I can't > > specify an SDT_PROBE and have it work. > > Can you show us some example code? /* Recycle fbt as SDT_PROVIDER_DEFINE is said not to work */ SDT_PROBE_DEFINE(fbt, gsio, gsio_intr, test); SDT_PROBE_ARGTYPE(fbt, gsio, gsio_intr, test, 0, "int"); SDT_PROBE_ARGTYPE(fbt, gsio, gsio_intr, test, 1, "int"); ... static void gsio_intr(void *varg) { ... istat = g_lcr_inl(sc, PLX_INTCSR); ... SDT_PROBE(fbt, gsio, gsio_intr, test, istat, 0, 0, 0, 0); > In > http://svn.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/s >rc/sys/compat/linux/linux_emul.c?revision=185383&view=markup I have > code which worked at least at some point in time when loaded as a > KLD. Hmm OK, this is on a 7.x system which doesn't have any SDT* stuff in the linuxlator (except for FBT probes) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090820/71650b39/attachment.pgp From Alexander at Leidinger.net Thu Aug 20 06:37:43 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Thu Aug 20 12:03:18 2009 Subject: DTrace probes & klds In-Reply-To: <200908192331.34507.doconnor@gsoft.com.au> References: <200908192331.34507.doconnor@gsoft.com.au> Message-ID: <20090820081740.436656fu6d4fxoso@webmail.leidinger.net> Quoting Daniel O'Connor (from Wed, 19 Aug 2009 23:31:33 +0930): > Content-Type: text/plain; > charset="utf-8" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline > > Is it possible? the handbook implies not and I can't get it to work, but > i could be doing it wrong.. > > I get fbt traces listed for KLDs (I get new entries for each load of the > KLD which seems like a potential problem) but I can't specify an > SDT_PROBE and have it work. Can you show us some example code? In http://svn.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/src/sys/compat/linux/linux_emul.c?revision=185383&view=markup I have code which worked at least at some point in time when loaded as a KLD. Bye, Alexander. -- A vacuum is a hell of a lot better than some of the stuff that nature replaces it with. -- Tennessee Williams http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From lgj at usenix.org Thu Aug 20 15:30:39 2009 From: lgj at usenix.org (Lionel Garth Jones) Date: Thu Aug 20 15:38:19 2009 Subject: USENIX SustainIT '10 Call For Papers Now Available Message-ID: <3A4FB166-BF5E-48A4-A654-D330CA111192@usenix.org> The Program Committee for the the First USENIX Workshop on Sustainable Information Technology (SustainIT '10) invites you to submit your papers. Increasingly, designers of computer systems ranging from small mobile devices to massive datacenters are concerned with sustainable design, including both power and life-cycle costs; these costs should include manufacturing, operation, and disposal of IT systems. We seek papers that evaluate energy-related issues and their aforementioned trade-offs, present novel new ideas, challenge and/or debunk past and present practices, and more. We especially encourage papers that discuss not just energy issues but also how they interact with other dimensions in a sustainable manner. The scope of this workshop is broad, covering research, theory, hardware, software, applications, techniques, etc.--all related to making computing systems greener. Topics of interest related to energy-sustainable computing include but are not limited to: * Energy vs. performance, cost, reliability, usability, security, etc. * Evaluations of long-term total costs of ownership (TCOs, e-waste, growth rates, recycling, etc.) * Total Impact of Ownership (TIO) in the long run (even decades-long) * Workload reduction techniques (e.g., compression, dedup) * Application of virtualization, cloud computing, clustering, and workload management * Hardware-based techniques (e.g., new electronics, clock-gating, disaggregation) * Firmware-based techniques (e.g., APM, ACPI) * Right-sizing techniques (e.g., DVFS, DRPM) * Use of FLASH and other novel storage media * Impact of storage hardware and software stacks * Application-optimization techniques (e.g., compiler-based) * Theory, algorithms, and simulated results * Energy and energy-related metrics (e.g., $$$, Energy-Delay, PUE) * IT services and techniques to manage energy and reduce costs * Sustainability and life-cycle analysis * Practical energy technologies for the developing world * Datacenter techniques (e.g., blade servers, low-power CPUs) * Software-based techniques at all levels, from OS/kernel to applications * Evaluation and modification of business processes to reduce the environmental impact * Economics of energy-efficienct software and hardware design * New datacenter cooling and energy-management issues and designs, including use of renewable energy sources * Thermal and computational fluid dynamics (CFD) models for software and hardware co-design Please submit your work by November 9, 2009. More information and submission guidelines are available at http://www.usenix.org/sustainit10/cfpa SustainIT '10 will take place February 22, 2010, in San Jose, CA. It will be co-located with the 8th USENIX Conference on File and Storage Technologies (FAST '10), which will take place February 23-26, 2010. We look forward to receiving your submissions! Sincerely, Ethan L. Miller, University of California, Santa Cruz Erez Zadok, Stony Brook University SustainIT '10 Program Co-Chairs sustainit10chairs@usenix.org From simon at FreeBSD.org Thu Aug 20 18:06:45 2009 From: simon at FreeBSD.org (Simon L. Nielsen) Date: Thu Aug 20 18:06:54 2009 Subject: Howto setup multiboot with GPT? In-Reply-To: <200908170932.54700.jhb@freebsd.org> References: <147751250284069@webmail117.yandex.ru> <200908170932.54700.jhb@freebsd.org> Message-ID: <20090820180643.GA1243@arthur.nitro.dk> On 2009.08.17 09:32:54 -0400, John Baldwin wrote: > On Friday 14 August 2009 5:07:49 pm Andrey V. Elsukov wrote: > > Hi, > > > > I have installed 8.0-BETA2 amd64 on ZFS root with GPT. I made addition partition and > > made new ZFS pool, builded and installed i386 world and kernel to this pool. > > So, is there some way to select from which partition i want to boot? > > Not currently unless you hardcode a specific partition in /boot.config. (You > may need a patch from jhay@ to fix the parsing of that file though.) I > believe someone (can't recall who) has some changes in a p4 branch to extend > gptboot to support a fancier interface with a menu of possible partitions, > etc. I have been playing around with gptboot, but it's not ready for any kind of general use yet. So far I parse and print the complete partition table and has the start of a framework to configure gptboot directly similar to boot0cfg. One of the first features I plan to have working is to be able to select which partition to boot, but it's not the main goal - that's nextboot like functionality. The WIP can be find in FreeBSD.org perforce at //depot/user/simon/gptboot/... AKA http://p4web.freebsd.org/@md=d&cd=//depot/user/simon/gptboot/&c=2qs@//depot/user/simon/gptboot/?ac=83 -- Simon L. Nielsen From Alexander at Leidinger.net Fri Aug 21 12:42:09 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Fri Aug 21 13:43:32 2009 Subject: DTrace probes & klds In-Reply-To: <200908201713.08368.doconnor@gsoft.com.au> References: <200908192331.34507.doconnor@gsoft.com.au> <20090820081740.436656fu6d4fxoso@webmail.leidinger.net> <200908201713.08368.doconnor@gsoft.com.au> Message-ID: <20090821144157.645117jxvao9rmzk@webmail.leidinger.net> Quoting Daniel O'Connor (from Thu, 20 Aug 2009 17:13:07 +0930): > On Thu, 20 Aug 2009, Alexander Leidinger wrote: >> Quoting Daniel O'Connor (from Wed, 19 Aug >> 2009 >> >> 23:31:33 +0930): >> > Content-Type: text/plain; >> > charset="utf-8" >> > Content-Transfer-Encoding: quoted-printable >> > Content-Disposition: inline >> > >> > Is it possible? the handbook implies not and I can't get it to >> > work, but i could be doing it wrong.. >> > >> > I get fbt traces listed for KLDs (I get new entries for each load >> > of the KLD which seems like a potential problem) but I can't >> > specify an SDT_PROBE and have it work. >> >> Can you show us some example code? > > /* Recycle fbt as SDT_PROVIDER_DEFINE is said not to work */ > SDT_PROBE_DEFINE(fbt, gsio, gsio_intr, test); > SDT_PROBE_ARGTYPE(fbt, gsio, gsio_intr, test, 0, "int"); > SDT_PROBE_ARGTYPE(fbt, gsio, gsio_intr, test, 1, "int"); I don't think you can define a fbt probe by hand. You can define a provider on your own via SDT_PROVIDER_DEFINE (in only one place/file), and then use this provider instead of fbt above. Let's assume you defined a gsio provider, then the SDT_PROBE_DEFINE could be SDT_PROBE_DEFINE(gsio, , gsio_intr, test); If there's only one file, it does not make much sense to add an unique part of the name of the file, but if you have multiple files it can be helpful. But this is just an example, for example in GEOM it would make sense to name the provider "geom", and instead of the file name use the module name, e.g. mirror, raid3, core/whatever, ... instead. Bye, Alexander. -- Fry: Where's Captain Bender? Off catastrophizing some other planet? http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From brampton+freebsd-hackers at gmail.com Fri Aug 21 17:10:12 2009 From: brampton+freebsd-hackers at gmail.com (Andrew Brampton) Date: Fri Aug 21 17:10:19 2009 Subject: DTrace lockup on a dual processor VMWare Message-ID: Hi, I am running a amd64 FreeBSD 7.2 inside a VMWare, and DTrace has been working great. However, I have just changed my VMWare to use two processors instead of one, and things have started to break. I can load the dtraceall module but when I run hotkernel the machine hangs. I have DDB compiled into the kernel, but I was unable to break into it, instead I used a remote GDB (on the host machine) to give me the follow backtraces: CPU 0 #0 rdtsc (n=) at ./machine/cpufunc.h:379 #1 DELAY (n=) at /usr/7.2/sys/amd64/isa/clock.c:290 #2 0xffffffff80512d2a in _mtx_lock_spin (m=0xffffff00018b4128, tid=18446742974215591648, opts=, file=, line=) at /usr/7.2/sys/kern/kern_mutex.c:480 #3 0xffffffff80513304 in _mtx_lock_spin_flags (m=0xffffff00018b4128, opts=0, file=0xffffffff80f31600 "/usr/7.2/sys/modules/cyclic/../../cddl/dev/cyclic/cyclic.c", line=574) at /usr/7.2/sys/kern/kern_mutex.c:229 #4 0xffffffff80f30ca0 in cyclic_fire (frame=0xfffffffe89ce7ae0) at /usr/7.2/sys/modules/cyclic/../../cddl/dev/cyclic/cyclic.c:574 #5 cyclic_clock (frame=0xfffffffe89ce7ae0) at /usr/7.2/sys/modules/cyclic/../../cddl/dev/cyclic/amd64/cyclic_machdep.c:99 #6 0xffffffff807cf7bb in lapic_handle_timer (frame=0xfffffffe89ce7ae0) at /usr/7.2/sys/amd64/amd64/local_apic.c:695 #7 0xffffffff807c9db7 in Xtimerint () at /usr/7.2/sys/amd64/amd64/apic_vector.S:103 CPU 1 #0 smp_rendezvous_cpus (map=2, setup_func=0, action_func=0xffffffff80f301a0 , teardown_func=0xffffffff80558b00 , arg=0xfffffffe8a8e94e0) at /usr/7.2/sys/kern/subr_smp.c:388 #1 0xffffffff80f3055e in xcall (arg=, c=, func=0, param=0x46) at /usr/7.2/sys/modules/cyclic/../../cddl/dev/cyclic/amd64/cyclic_machdep.c:131 #2 0xffffffff80f301ed in cyclic_reprogram (cpu=, exp=) at /usr/7.2/sys/modules/cyclic/../../cddl/dev/cyclic/cyclic.c:540 #3 0xffffffff80f31194 in cyclic_add_here (cpu=0xffffff00018b4100, hdlr=0xfffffffe8a8e95a0, when=0xfffffffe8a8e9590, flags=0) at /usr/7.2/sys/modules/cyclic/../../cddl/dev/cyclic/cyclic.c:765 #4 0xffffffff80f314ea in cyclic_omni_start (omni=) at /usr/7.2/sys/modules/cyclic/../../cddl/dev/cyclic/cyclic.c:956 #5 cyclic_add_omni (omni=) at /usr/7.2/sys/modules/cyclic/../../cddl/dev/cyclic/cyclic.c:1226 #6 0xffffffff80f21665 in profile_enable (arg=, id=2149531648, parg=0x0) at /usr/7.2/sys/modules/dtrace/profile/../../../cddl/dev/profile/profile.c:450 #7 0xffffffff80f3c6cf in dtrace_ecb_enable (probe=0x1, arg=) at /usr/7.2/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:9656 #8 dtrace_ecb_create_enable (probe=0x1, arg=) at /usr/7.2/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:10471 #9 0xffffffff80f40142 in dtrace_match (pkp=0xfffffffe8a8e9800, priv=31, uid=27929688, zoneid=0, matched=0xffffffff80f3c130 , arg=0xffffff000db1f840) at /usr/7.2/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:7212 #10 0xffffffff80f40346 in dtrace_probe_enable (desc=0xffffff0001a9d218, enab=0xffffff000db1f840) at /usr/7.2/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:7992 #11 0xffffffff80f40434 in dtrace_enabling_match (enab=0xffffff000db1f840, nmatched=0xffffff000db83528) at /usr/7.2/sys/modules/dtrace/dtrace/../../../cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:11366 #12 0xffffffff80f4c19a in dtrace_ioctl (dev=, cmd=, addr=0xffffff000db83520 "", flags=, td=0xffffff0001ab7370) at /usr/7.2/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/dtrace_ioctl.c:380 #13 0xffffffff804b14e6 in devfs_ioctl_f (fp=0xffffff00014db780, com=3222304774, data=0xffffff000db83520, cred=, td=0xffffff0001ab7370) at /usr/7.2/sys/fs/devfs/devfs_vnops.c:602 #14 0xffffffff80562063 in fo_ioctl (td=0xffffff0001ab7370, fd=7, com=3222304774, data=0xffffff000db83520 "") at /usr/7.2/sys/sys/file.h:269 #15 kern_ioctl (td=0xffffff0001ab7370, fd=7, com=3222304774, data=0xffffff000db83520 "") at /usr/7.2/sys/kern/sys_generic.c:627 #16 0xffffffff805622c9 in ioctl (td=0xffffff0001ab7370, uap=0xfffffffe8a8e9bf0) at /usr/7.2/sys/kern/sys_generic.c:571 #17 0xffffffff807e54fc in syscall (frame=0xfffffffe8a8e9c80) at /usr/7.2/sys/amd64/amd64/trap.c:900 #18 0xffffffff807c971b in Xfast_syscall () at /usr/7.2/sys/amd64/amd64/exception.S:330 It seems that CPU 0 is doing nothing, permanently stuck on line 379 of cpufunc.h, whereas CPU 1 is spinning inside the loop on line 388 of subr_smp.c. On thing I notice that when I run hotkernel on a single processor VMWare it prints out: > hotkernel Sampling... Hit Ctrl+C to end dtrace: buffer size lowered to 1m dtrace: aggregation size lowered to 1m When I run it on the dual-processor VMWare it only prints > hotkernel Sampling... Hit Ctrl+C to end So I suspect it is locking up before it gets to the code that prints "buffer size lowered". Additionally, I have built my own kernel, using all the standard options and sources, with just the following extra options: options KDTRACE_FRAME # Ensure frames are compiled in options KDTRACE_HOOKS # Kernel DTrace hooks options DDB_CTF options DEVICE_POLLING options KDB options KDB_UNATTENDED options DDB options GDB options BREAK_TO_DEBUGGER options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN options DEBUG_MEMGUARD options HWPMC_HOOKS device hwpmc Can anyone suggest anything to try and debug/fix this problem. I'm happy to hack the kernel sources if need be. thanks Andrew From brian at FreeBSD.org Sat Aug 22 00:11:44 2009 From: brian at FreeBSD.org (Brian Somers) Date: Sat Aug 22 00:11:50 2009 Subject: kernel panics in in_lltable_lookup (with INVARIANTS) Message-ID: <20090821164312.641fe2bd@dev.lan.Awfulhak.org> Hi, I've been working on a fix to address an issue that came up with our update of openssh-5. The issue is that openssh-5 now uses pipe() to create stdin/stdout channels between sshd and the server side program where it used to use socketpair(). Because it uses pipe(), stdin is no longer bi-directional and cannot be used for both input and output by a child process. This breaks the use of ssh as a tunnel with ppp on either end (set device "!ssh -e none host ppp -direct label") I talked with des@ for a while and then with the openssh folks and have not been able to resolve the issues in openssh that made them choose to enforce the use of pipe() over socketpair(). I now have a patch to ppp that makes ppp detect that it's connected via pipe() and causes it to use stdin for input and stdout for output (usually it expects just one descriptor). Although I'm happy with the patch and planned on requesting permission to commit, I've bumped into a show-stopper that seems unrelated, so I thought I'd ask here if anyone has seen this or has any suggestions as to what the problem might be. The issue.... I'm seeing a panic when I send traffic through a ppp link: panic string is: sin_family 18 Stack trace starts: in_lltable_lookup() llentry_update() flowtable_lookup() ip_output() .... The panic is due to a KASSERT in in_lltable_lookup() that expects the sockaddr to be AF_INET. Number 18 is AF_LINK. AFAICT this is happening while setting up a temporary route for the first outbound packet. I haven't been able to do much investigation yet due to other patches in my tree that seem to have broken all my kernel symbols, but once I get a clean rebuild I should be back in business. If anyone has any suggestions, I'm all ears! Cheers. -- Brian Somers Don't _EVER_ lose your sense of humour ! From kmacy at freebsd.org Sat Aug 22 00:44:39 2009 From: kmacy at freebsd.org (Kip Macy) Date: Sat Aug 22 00:44:46 2009 Subject: kernel panics in in_lltable_lookup (with INVARIANTS) In-Reply-To: <20090821164312.641fe2bd@dev.lan.Awfulhak.org> References: <20090821164312.641fe2bd@dev.lan.Awfulhak.org> Message-ID: <3c1674c90908211713j36415b96q58b0ed66cc82713f@mail.gmail.com> Try this: Index: sys/net/flowtable.c =================================================================== --- sys/net/flowtable.c (revision 196382) +++ sys/net/flowtable.c (working copy) @@ -688,6 +688,12 @@ struct rtentry *rt = ro->ro_rt; struct ifnet *ifp = rt->rt_ifp; + if (ifp->if_flags & IFF_POINTOPOINT) { + RTFREE(rt); + ro->ro_rt = NULL; + return (ENOENT); + } + if (rt->rt_flags & RTF_GATEWAY) l3addr = rt->rt_gateway; else You'll need to apply this by hand as gmail munges the formatting. -Kip On Fri, Aug 21, 2009 at 16:43, Brian Somers wrote: > Hi, > > I've been working on a fix to address an issue that came up with > our update of openssh-5. ?The issue is that openssh-5 now uses > pipe() to create stdin/stdout channels between sshd and the server > side program where it used to use socketpair(). ?Because it uses > pipe(), stdin is no longer bi-directional and cannot be used for both > input and output by a child process. ?This breaks the use of ssh > as a tunnel with ppp on either end (set device "!ssh -e none host > ppp -direct label") > > I talked with des@ for a while and then with the openssh folks and > have not been able to resolve the issues in openssh that made them > choose to enforce the use of pipe() over socketpair(). ?I now have a > patch to ppp that makes ppp detect that it's connected via pipe() and > causes it to use stdin for input and stdout for output (usually it expects > just one descriptor). ?Although I'm happy with the patch and planned on > requesting permission to commit, I've bumped into a show-stopper > that seems unrelated, so I thought I'd ask here if anyone has seen > this or has any suggestions as to what the problem might be. > > The issue.... > > I'm seeing a panic when I send traffic through a ppp link: > > panic string is: sin_family 18 > Stack trace starts: > ? ?in_lltable_lookup() > ? ?llentry_update() > ? ?flowtable_lookup() > ? ?ip_output() > ? ?.... > > The panic is due to a KASSERT in in_lltable_lookup() that expects the > sockaddr to be AF_INET. ?Number 18 is AF_LINK. > > AFAICT this is happening while setting up a temporary route for the > first outbound packet. ?I haven't been able to do much investigation > yet due to other patches in my tree that seem to have broken all my > kernel symbols, but once I get a clean rebuild I should be back in > business. > > If anyone has any suggestions, I'm all ears! > > Cheers. > > -- > Brian Somers ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > Don't _EVER_ lose your sense of humour ! ? ? ? ? ? ? ? > _______________________________________________ > 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" > -- When harsh accusations depart too far from the truth, they leave bitter consequences. --Tacitus From kindman at amc-os.com Sat Aug 22 01:36:59 2009 From: kindman at amc-os.com (Aurélien Méré) Date: Sat Aug 22 01:37:05 2009 Subject: Common interface for sensors/health monitoring Message-ID: Hi, I've been using FreeBSD for years in all my servers, but I'm facing a big problem today. All servers are under monitoring using a couple of applications and scripts. Monitored items for each server especially are CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UPS voltages, HDD/RAID status&usage, network connectivity, UPS load, battery status & runtime, ... My concern today, excepted that there is no way to gather all the data through a unique interface and that consequently we have to change the scripts depending on hardware, is that some information are no longer available at all, especially concerning the MB IC, ie. temperatures, voltages & fan speed. Actually, some SMBus controllers (like from 2006 or so) are not supported by any driver and I didn't find any port updated to access the IC directly (if even possible). Currently, I sometimes have to use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes healthd and sometimes nothing works (PR 137668 or 136762 as examples in my case). Besides that, I was quite surprised that these information are available in OpenBSD through a very simple and unique sysctl interface, with up-to-date drivers, working on all my servers with a generic install. I know that below this presentation layer, this may be much less perfect, and by digging in, I found that a 2007 GSoC project for porting the OpenBSD sensor framework was realised and planned to be put in HEAD. I also read hundreds of mails concerning this project, and why finally it was not commited. As developer, I fully understand some of the concerns in these threads and that there are probably lots of things to change and work on, integrate it in a cleaner repository like snmp or whatever; and I'd be glad to help in any possible way to improve this. But in the meantime, as netadmin, this kind of information can be very important to prevent or diagnose major problems; so I'd like to know what is being planned/done on this subject, as I didn't find any more information related to this than a discussion during bsdcan 2008. Thanks for your help and time, Aurélien From oliver.pntr at gmail.com Sat Aug 22 02:17:32 2009 From: oliver.pntr at gmail.com (Oliver Pinter) Date: Sat Aug 22 02:17:44 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: References: Message-ID: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> Hello! When I good know, no common interface exisit in current freebsd kernel, but some other sysctl interfece exisit: coretemp, aiboost ... ~> sysctl dev.coretemp dev.coretemp.0.%desc: CPU On-Die Thermal Sensors dev.coretemp.0.%driver: coretemp dev.coretemp.0.%parent: cpu0 dev.coretemp.1.%desc: CPU On-Die Thermal Sensors dev.coretemp.1.%driver: coretemp dev.coretemp.1.%parent: cpu1 dev.coretemp.2.%desc: CPU On-Die Thermal Sensors dev.coretemp.2.%driver: coretemp dev.coretemp.2.%parent: cpu2 dev.coretemp.3.%desc: CPU On-Die Thermal Sensors dev.coretemp.3.%driver: coretemp dev.coretemp.3.%parent: cpu3 ~> sysctl dev.acpi_aiboost dev.acpi_aiboost.0.%desc: ASUStek AIBOOSTER dev.acpi_aiboost.0.%driver: acpi_aiboost dev.acpi_aiboost.0.%location: handle=\_SB_.PCI0.SBRG.ASOC dev.acpi_aiboost.0.%pnpinfo: _HID=ATK0110 _UID=16843024 dev.acpi_aiboost.0.%parent: acpi0 dev.acpi_aiboost.0.temp0: 190 dev.acpi_aiboost.0.temp1: 300 dev.acpi_aiboost.0.volt0: 1144 dev.acpi_aiboost.0.volt1: 3328 dev.acpi_aiboost.0.volt2: 5064 dev.acpi_aiboost.0.volt3: 12096 dev.acpi_aiboost.0.fan0: 1962 dev.acpi_aiboost.0.fan1: 1180 dev.acpi_aiboost.0.fan2: 1278 dev.acpi_aiboost.0.fan3: 0 dev.acpi_aiboost.0.fan4: 0 but no common if.. On 8/22/09, Aur?lien M?r? wrote: > Hi, > > I've been using FreeBSD for years in all my servers, but I'm facing a big > problem today. All servers are under monitoring using a couple of > applications and scripts. Monitored items for each server especially are > CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UPS > voltages, HDD/RAID status&usage, network connectivity, UPS load, battery > status & runtime, ... > > My concern today, excepted that there is no way to gather all the data > through a unique interface and that consequently we have to change the > scripts depending on hardware, is that some information are no longer > available at all, especially concerning the MB IC, ie. temperatures, > voltages & fan speed. Actually, some SMBus controllers (like from 2006 or > so) are not supported by any driver and I didn't find any port updated to > access the IC directly (if even possible). Currently, I sometimes have to > use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes healthd and > sometimes nothing works (PR 137668 or 136762 as examples in my case). > > Besides that, I was quite surprised that these information are available in > OpenBSD through a very simple and unique sysctl interface, with up-to-date > drivers, working on all my servers with a generic install. I know that below > this presentation layer, this may be much less perfect, and by digging in, I > found that a 2007 GSoC project for porting the OpenBSD sensor framework was > realised and planned to be put in HEAD. I also read hundreds of mails > concerning this project, and why finally it was not commited. > > As developer, I fully understand some of the concerns in these threads and > that there are probably lots of things to change and work on, integrate it > in a cleaner repository like snmp or whatever; and I'd be glad to help in > any > possible way to improve this. But in the meantime, as netadmin, this kind of > information can be very important to prevent or diagnose major problems; so > I'd like to know what is being planned/done on this subject, as I didn't > find any > more information related to this than a discussion during bsdcan 2008. > > Thanks for your help and time, > Aur?lien > > > > > _______________________________________________ > 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 brian at FreeBSD.org Sat Aug 22 05:23:07 2009 From: brian at FreeBSD.org (Brian Somers) Date: Sat Aug 22 05:23:14 2009 Subject: kernel panics in in_lltable_lookup (with INVARIANTS) In-Reply-To: <3c1674c90908211713j36415b96q58b0ed66cc82713f@mail.gmail.com> References: <20090821164312.641fe2bd@dev.lan.Awfulhak.org> <3c1674c90908211713j36415b96q58b0ed66cc82713f@mail.gmail.com> Message-ID: <20090821215503.3eec9a15@dev.lan.Awfulhak.org> On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy wrote: > Try this: > > Index: sys/net/flowtable.c > =================================================================== > --- sys/net/flowtable.c (revision 196382) > +++ sys/net/flowtable.c (working copy) > @@ -688,6 +688,12 @@ > struct rtentry *rt = ro->ro_rt; > struct ifnet *ifp = rt->rt_ifp; > > + if (ifp->if_flags & IFF_POINTOPOINT) { > + RTFREE(rt); > + ro->ro_rt = NULL; > + return (ENOENT); > + } > + > if (rt->rt_flags & RTF_GATEWAY) > l3addr = rt->rt_gateway; > else > > You'll need to apply this by hand as gmail munges the formatting. > > -Kip Hi, That certainly stops the panic, however data routed to the tun interface doesn't come out the back end and data written to the back end doesn't come out the tun interface. After connecting a 7-stable and a -current box, I get this sending a ping packet from the stable box: -stable: TCP/IP: OUT ICMP: 172.16.1.22:8 ---> 172.16.1.20 (36/84) Physical: write Physical: 7e 3d c0 1c fd 00 12 02 1b 3a c1 1c 64 e8 04 75 ~=.......:..d..u Physical: 84 a1 93 62 d5 e2 c1 86 1e 63 60 9a f4 82 54 43 ...b.....c`...TC Physical: 01 00 70 7c 7e ..p|~ meaning that ppp sees the ICMP when it reads the back of the tun interface, and writes the encapsulated data to its physical link (the "other end"). -current: Physical: read Physical: 7e 3d c0 1c fd 00 12 02 1b 3a c1 1c 64 e8 04 75 ~=.......:..d..u Physical: 84 a1 93 62 d5 e2 c1 86 1e 63 60 9a f4 82 54 43 ...b.....c`...TC Physical: 01 00 70 7c 7e ..p|~ TCP/IP: IN ICMP: 172.16.1.22:8 ---> 172.16.1.20 (36/84) meaning that ppp reads data from the physical link, decapsulates it and writes an ICMP to the back of the tun interface. Then nothing (no ICMP reply). Sending an icmp from the -current box doesn't wake ppp at all. On the -stable box: brian@gw ~ $ ifconfig tun0 tun0: flags=8051 metric 0 mtu 1540 inet6 fe80::240:f4ff:feb1:1c85%tun0 prefixlen 64 scopeid 0x6 inet 172.16.1.22 --> 172.16.1.20 netmask 0xffffffff Opened by PID 89468 brian@gw ~ $ route get 172.16.1.20 route to: 172.16.1.20 destination: 172.16.1.20 gateway: 172.16.1.22 interface: tun0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1540 0 and on the -current box: brian@dev ~ $ ifconfig tun0 tun0: flags=8051 metric 0 mtu 1540 inet 172.16.1.20 --> 172.16.1.22 netmask 0xffffffff inet6 fe80::240:f4ff:feb1:10da%tun0 prefixlen 64 scopeid 0x7 Opened by PID 1647 brian@dev ~ $ route get 172.16.1.22 route to: 172.16.1.22 destination: 172.16.1.22 gateway: interface: tun0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1540 1 0 According to ``netstat -I tun0'', Opkts is increasing when I send from the -current box, although netstat -s doesn't seem to see any more icmps. Maybe this problem isn't a routing problem. I'll look into it further and figure out if the packet is getting to the tun driver and if so, what it thinks it's doing with it. Thanks. > On Fri, Aug 21, 2009 at 16:43, Brian Somers wrote: > > Hi, > > > > I've been working on a fix to address an issue that came up with > > our update of openssh-5. ?The issue is that openssh-5 now uses > > pipe() to create stdin/stdout channels between sshd and the server > > side program where it used to use socketpair(). ?Because it uses > > pipe(), stdin is no longer bi-directional and cannot be used for both > > input and output by a child process. ?This breaks the use of ssh > > as a tunnel with ppp on either end (set device "!ssh -e none host > > ppp -direct label") > > > > I talked with des@ for a while and then with the openssh folks and > > have not been able to resolve the issues in openssh that made them > > choose to enforce the use of pipe() over socketpair(). ?I now have a > > patch to ppp that makes ppp detect that it's connected via pipe() and > > causes it to use stdin for input and stdout for output (usually it expects > > just one descriptor). ?Although I'm happy with the patch and planned on > > requesting permission to commit, I've bumped into a show-stopper > > that seems unrelated, so I thought I'd ask here if anyone has seen > > this or has any suggestions as to what the problem might be. > > > > The issue.... > > > > I'm seeing a panic when I send traffic through a ppp link: > > > > panic string is: sin_family 18 > > Stack trace starts: > > ? ?in_lltable_lookup() > > ? ?llentry_update() > > ? ?flowtable_lookup() > > ? ?ip_output() > > ? ?.... > > > > The panic is due to a KASSERT in in_lltable_lookup() that expects the > > sockaddr to be AF_INET. ?Number 18 is AF_LINK. > > > > AFAICT this is happening while setting up a temporary route for the > > first outbound packet. ?I haven't been able to do much investigation > > yet due to other patches in my tree that seem to have broken all my > > kernel symbols, but once I get a clean rebuild I should be back in > > business. > > > > If anyone has any suggestions, I'm all ears! > > > > Cheers. -- Brian Somers Don't _EVER_ lose your sense of humour ! From brian at FreeBSD.org Sat Aug 22 06:23:24 2009 From: brian at FreeBSD.org (Brian Somers) Date: Sat Aug 22 06:23:31 2009 Subject: kernel panics in in_lltable_lookup (with INVARIANTS) In-Reply-To: <20090821224134.11d9a2a1@dev.lan.Awfulhak.org> References: <20090821164312.641fe2bd@dev.lan.Awfulhak.org> <3c1674c90908211713j36415b96q58b0ed66cc82713f@mail.gmail.com> <20090821215503.3eec9a15@dev.lan.Awfulhak.org> <20090821224134.11d9a2a1@dev.lan.Awfulhak.org> Message-ID: <20090821232313.21a9a7f9@dev.lan.Awfulhak.org> On Fri, 21 Aug 2009 22:41:34 -0700 Brian Somers wrote: > On Fri, 21 Aug 2009 21:55:03 -0700 Brian Somers wrote: > > On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy wrote: > > > Try this: > > > > > > Index: sys/net/flowtable.c > > > =================================================================== > > > --- sys/net/flowtable.c (revision 196382) > > > +++ sys/net/flowtable.c (working copy) > > > @@ -688,6 +688,12 @@ > > > struct rtentry *rt = ro->ro_rt; > > > struct ifnet *ifp = rt->rt_ifp; > > > > > > + if (ifp->if_flags & IFF_POINTOPOINT) { > > > + RTFREE(rt); > > > + ro->ro_rt = NULL; > > > + return (ENOENT); > > > + } > > > + > > > if (rt->rt_flags & RTF_GATEWAY) > > > l3addr = rt->rt_gateway; > > > else > > > > > > You'll need to apply this by hand as gmail munges the formatting. > > > > > > -Kip > > > > Hi, > > > > That certainly stops the panic, however data routed to the tun > > interface doesn't come out the back end and data written > > to the back end doesn't come out the tun interface. > [.....] > > Maybe this problem isn't a routing problem. I'll > > look into it further and figure out if the packet is getting to the tun > > driver and if so, what it thinks it's doing with it. > > I wasn't correct - the data *IS* being read out of the back of > the tunnel device. When I send the ICMP, it goes into the tun > device and comes out the back end as an AF_LINK packet. ppp > silently discards this (ironically I have a comment noting > that I should really track unidentified packet counts). > > I'll try to figure out what in if_tun.c is corrupting the family next... if_tun.c is fine. The data passed from if_output() has family AF_LINK - hence the original panic from flowtable_lookup(). So the question is "why is ip_output() sending AF_LINK traffic instead of AF_INET traffic?". Still looking.... > > > On Fri, Aug 21, 2009 at 16:43, Brian Somers wrote: > > > > Hi, > > > > > > > > I've been working on a fix to address an issue that came up with > > > > our update of openssh-5. ?The issue is that openssh-5 now uses > > > > pipe() to create stdin/stdout channels between sshd and the server > > > > side program where it used to use socketpair(). ?Because it uses > > > > pipe(), stdin is no longer bi-directional and cannot be used for both > > > > input and output by a child process. ?This breaks the use of ssh > > > > as a tunnel with ppp on either end (set device "!ssh -e none host > > > > ppp -direct label") > > > > > > > > I talked with des@ for a while and then with the openssh folks and > > > > have not been able to resolve the issues in openssh that made them > > > > choose to enforce the use of pipe() over socketpair(). ?I now have a > > > > patch to ppp that makes ppp detect that it's connected via pipe() and > > > > causes it to use stdin for input and stdout for output (usually it expects > > > > just one descriptor). ?Although I'm happy with the patch and planned on > > > > requesting permission to commit, I've bumped into a show-stopper > > > > that seems unrelated, so I thought I'd ask here if anyone has seen > > > > this or has any suggestions as to what the problem might be. > > > > > > > > The issue.... > > > > > > > > I'm seeing a panic when I send traffic through a ppp link: > > > > > > > > panic string is: sin_family 18 > > > > Stack trace starts: > > > > ? ?in_lltable_lookup() > > > > ? ?llentry_update() > > > > ? ?flowtable_lookup() > > > > ? ?ip_output() > > > > ? ?.... > > > > > > > > The panic is due to a KASSERT in in_lltable_lookup() that expects the > > > > sockaddr to be AF_INET. ?Number 18 is AF_LINK. > > > > > > > > AFAICT this is happening while setting up a temporary route for the > > > > first outbound packet. ?I haven't been able to do much investigation > > > > yet due to other patches in my tree that seem to have broken all my > > > > kernel symbols, but once I get a clean rebuild I should be back in > > > > business. > > > > > > > > If anyone has any suggestions, I'm all ears! > > > > > > > > Cheers. -- Brian Somers Don't _EVER_ lose your sense of humour ! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090822/0a1d81d6/signature.pgp From gnemmi at gmail.com Sat Aug 22 06:35:44 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Sat Aug 22 06:35:52 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> Message-ID: <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> On Fri, Aug 21, 2009 at 11:17 PM, Oliver Pinter wrote: > Hello! > > When I good know, no common interface exisit in current freebsd > kernel, but some other sysctl interfece exisit: coretemp, aiboost ... > > ~> sysctl dev.coretemp > dev.coretemp.0.%desc: CPU On-Die Thermal Sensors > dev.coretemp.0.%driver: coretemp > dev.coretemp.0.%parent: cpu0 > dev.coretemp.1.%desc: CPU On-Die Thermal Sensors > dev.coretemp.1.%driver: coretemp > dev.coretemp.1.%parent: cpu1 > dev.coretemp.2.%desc: CPU On-Die Thermal Sensors > dev.coretemp.2.%driver: coretemp > dev.coretemp.2.%parent: cpu2 > dev.coretemp.3.%desc: CPU On-Die Thermal Sensors > dev.coretemp.3.%driver: coretemp > dev.coretemp.3.%parent: cpu3 > > ~> sysctl dev.acpi_aiboost > dev.acpi_aiboost.0.%desc: ASUStek AIBOOSTER > dev.acpi_aiboost.0.%driver: acpi_aiboost > dev.acpi_aiboost.0.%location: handle=\_SB_.PCI0.SBRG.ASOC > dev.acpi_aiboost.0.%pnpinfo: _HID=ATK0110 _UID=16843024 > dev.acpi_aiboost.0.%parent: acpi0 > dev.acpi_aiboost.0.temp0: 190 > dev.acpi_aiboost.0.temp1: 300 > dev.acpi_aiboost.0.volt0: 1144 > dev.acpi_aiboost.0.volt1: 3328 > dev.acpi_aiboost.0.volt2: 5064 > dev.acpi_aiboost.0.volt3: 12096 > dev.acpi_aiboost.0.fan0: 1962 > dev.acpi_aiboost.0.fan1: 1180 > dev.acpi_aiboost.0.fan2: 1278 > dev.acpi_aiboost.0.fan3: 0 > dev.acpi_aiboost.0.fan4: 0 > > but no common if.. > Is there an acpi_dell or something like that? > > On 8/22/09, Aur?lien M?r? wrote: > > Hi, > > > > I've been using FreeBSD for years in all my servers, but I'm facing a big > > problem today. All servers are under monitoring using a couple of > > applications and scripts. Monitored items for each server especially are > > CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UPS > > voltages, HDD/RAID status&usage, network connectivity, UPS load, battery > > status & runtime, ... > > > > My concern today, excepted that there is no way to gather all the data > > through a unique interface and that consequently we have to change the > > scripts depending on hardware, is that some information are no longer > > available at all, especially concerning the MB IC, ie. temperatures, > > voltages & fan speed. Actually, some SMBus controllers (like from 2006 or > > so) are not supported by any driver and I didn't find any port updated to > > access the IC directly (if even possible). Currently, I sometimes have to > > use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes healthd > and > > sometimes nothing works (PR 137668 or 136762 as examples in my case). > > > > Besides that, I was quite surprised that these information are available > in > > OpenBSD through a very simple and unique sysctl interface, with > up-to-date > > drivers, working on all my servers with a generic install. I know that > below > > this presentation layer, this may be much less perfect, and by digging > in, I > > found that a 2007 GSoC project for porting the OpenBSD sensor framework > was > > realised and planned to be put in HEAD. I also read hundreds of mails > > concerning this project, and why finally it was not commited. > > > > As developer, I fully understand some of the concerns in these threads > and > > that there are probably lots of things to change and work on, integrate > it > > in a cleaner repository like snmp or whatever; and I'd be glad to help in > > any > > possible way to improve this. But in the meantime, as netadmin, this kind > of > > information can be very important to prevent or diagnose major problems; > so > > I'd like to know what is being planned/done on this subject, as I didn't > > find any > > more information related to this than a discussion during bsdcan 2008. > > > > Thanks for your help and time, > > Aur?lien > +10 I was looking for the same info a time ago .. something that would allow me to gather all the info from the same place, but the only thing I came up with was the very same discussion about the sensors framework port and nothing else. Any info on any such proyect will be greatly apreciated Regards From julian at elischer.org Sat Aug 22 07:04:17 2009 From: julian at elischer.org (Julian Elischer) Date: Sat Aug 22 07:04:25 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: References: Message-ID: <4A8F986A.3040405@elischer.org> Aur?lien M?r? wrote: > Hi, > > I've been using FreeBSD for years in all my servers, but I'm facing a big > problem today. All servers are under monitoring using a couple of > applications and scripts. Monitored items for each server especially are > CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UPS > voltages, HDD/RAID status&usage, network connectivity, UPS load, battery > status & runtime, ... > > My concern today, excepted that there is no way to gather all the data > through a unique interface and that consequently we have to change the > scripts depending on hardware, is that some information are no longer > available at all, especially concerning the MB IC, ie. temperatures, > voltages & fan speed. Actually, some SMBus controllers (like from 2006 or > so) are not supported by any driver and I didn't find any port updated to > access the IC directly (if even possible). Currently, I sometimes have to > use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes healthd and > sometimes nothing works (PR 137668 or 136762 as examples in my case). > > Besides that, I was quite surprised that these information are available in > OpenBSD through a very simple and unique sysctl interface, with up-to-date > drivers, working on all my servers with a generic install. I know that below > this presentation layer, this may be much less perfect, and by digging in, I > found that a 2007 GSoC project for porting the OpenBSD sensor framework was > realised and planned to be put in HEAD. I also read hundreds of mails > concerning this project, and why finally it was not commited. > > As developer, I fully understand some of the concerns in these threads and > that there are probably lots of things to change and work on, integrate it > in a cleaner repository like snmp or whatever; and I'd be glad to help in > any > possible way to improve this. But in the meantime, as netadmin, this kind of > information can be very important to prevent or diagnose major problems; so > I'd like to know what is being planned/done on this subject, as I didn't > find any > more information related to this than a discussion during bsdcan 2008. The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices. > > Thanks for your help and time, > Aur?lien > > > > > _______________________________________________ > 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 marc at msys.ch Sat Aug 22 07:05:57 2009 From: marc at msys.ch (Marc Balmer) Date: Sat Aug 22 07:06:08 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> Message-ID: <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> Am 22.08.2009 um 08:03 schrieb Gonzalo Nemmi: > On Fri, Aug 21, 2009 at 11:17 PM, Oliver Pinter > wrote: > >> Hello! >> >> When I good know, no common interface exisit in current freebsd >> kernel, but some other sysctl interfece exisit: coretemp, aiboost ... >> >> ~> sysctl dev.coretemp >> dev.coretemp.0.%desc: CPU On-Die Thermal Sensors >> dev.coretemp.0.%driver: coretemp >> dev.coretemp.0.%parent: cpu0 >> dev.coretemp.1.%desc: CPU On-Die Thermal Sensors >> dev.coretemp.1.%driver: coretemp >> dev.coretemp.1.%parent: cpu1 >> dev.coretemp.2.%desc: CPU On-Die Thermal Sensors >> dev.coretemp.2.%driver: coretemp >> dev.coretemp.2.%parent: cpu2 >> dev.coretemp.3.%desc: CPU On-Die Thermal Sensors >> dev.coretemp.3.%driver: coretemp >> dev.coretemp.3.%parent: cpu3 >> >> ~> sysctl dev.acpi_aiboost >> dev.acpi_aiboost.0.%desc: ASUStek AIBOOSTER >> dev.acpi_aiboost.0.%driver: acpi_aiboost >> dev.acpi_aiboost.0.%location: handle=\_SB_.PCI0.SBRG.ASOC >> dev.acpi_aiboost.0.%pnpinfo: _HID=ATK0110 _UID=16843024 >> dev.acpi_aiboost.0.%parent: acpi0 >> dev.acpi_aiboost.0.temp0: 190 >> dev.acpi_aiboost.0.temp1: 300 >> dev.acpi_aiboost.0.volt0: 1144 >> dev.acpi_aiboost.0.volt1: 3328 >> dev.acpi_aiboost.0.volt2: 5064 >> dev.acpi_aiboost.0.volt3: 12096 >> dev.acpi_aiboost.0.fan0: 1962 >> dev.acpi_aiboost.0.fan1: 1180 >> dev.acpi_aiboost.0.fan2: 1278 >> dev.acpi_aiboost.0.fan3: 0 >> dev.acpi_aiboost.0.fan4: 0 >> >> but no common if.. >> > > Is there an acpi_dell or something like that? > > >> >> On 8/22/09, Aur?lien M?r? wrote: >>> Hi, >>> >>> I've been using FreeBSD for years in all my servers, but I'm >>> facing a big >>> problem today. All servers are under monitoring using a couple of >>> applications and scripts. Monitored items for each server >>> especially are >>> CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, >>> PSU/UPS >>> voltages, HDD/RAID status&usage, network connectivity, UPS load, >>> battery >>> status & runtime, ... >>> >>> My concern today, excepted that there is no way to gather all the >>> data >>> through a unique interface and that consequently we have to change >>> the >>> scripts depending on hardware, is that some information are no >>> longer >>> available at all, especially concerning the MB IC, ie. temperatures, >>> voltages & fan speed. Actually, some SMBus controllers (like from >>> 2006 or >>> so) are not supported by any driver and I didn't find any port >>> updated to >>> access the IC directly (if even possible). Currently, I sometimes >>> have to >>> use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes >>> healthd >> and >>> sometimes nothing works (PR 137668 or 136762 as examples in my >>> case). >>> >>> Besides that, I was quite surprised that these information are >>> available >> in >>> OpenBSD through a very simple and unique sysctl interface, with >> up-to-date >>> drivers, working on all my servers with a generic install. I know >>> that >> below >>> this presentation layer, this may be much less perfect, and by >>> digging >> in, I >>> found that a 2007 GSoC project for porting the OpenBSD sensor >>> framework >> was >>> realised and planned to be put in HEAD. I also read hundreds of >>> mails >>> concerning this project, and why finally it was not commited. >>> >>> As developer, I fully understand some of the concerns in these >>> threads >> and >>> that there are probably lots of things to change and work on, >>> integrate >> it >>> in a cleaner repository like snmp or whatever; and I'd be glad to >>> help in >>> any >>> possible way to improve this. But in the meantime, as netadmin, >>> this kind >> of >>> information can be very important to prevent or diagnose major >>> problems; >> so >>> I'd like to know what is being planned/done on this subject, as I >>> didn't >>> find any >>> more information related to this than a discussion during bsdcan >>> 2008. >>> >>> Thanks for your help and time, >>> Aur?lien >> > > +10 > > I was looking for the same info a time ago .. something that would > allow me > to gather all the info from the same place, but the only thing I > came up > with was the very same discussion about the sensors framework port and > nothing else. > > Any info on any such proyect will be greatly apreciated The OpenBSD sensors framework lacks some desireable features, e.g. event capabilities like getting an event if a certain threshold is exceeded. And it propbably was used for things that it better had not (yes, I am culprit for on of these (ab)uses...). I am sure these features could be added if only the code was in the tree to hack on... - Marc Balmer From brian at FreeBSD.org Sat Aug 22 10:45:56 2009 From: brian at FreeBSD.org (Brian Somers) Date: Sat Aug 22 10:46:03 2009 Subject: kernel panics in in_lltable_lookup (with INVARIANTS) In-Reply-To: <20090821232313.21a9a7f9@dev.lan.Awfulhak.org> References: <20090821164312.641fe2bd@dev.lan.Awfulhak.org> <3c1674c90908211713j36415b96q58b0ed66cc82713f@mail.gmail.com> <20090821215503.3eec9a15@dev.lan.Awfulhak.org> <20090821224134.11d9a2a1@dev.lan.Awfulhak.org> <20090821232313.21a9a7f9@dev.lan.Awfulhak.org> Message-ID: <20090822034537.76b16271@dev.lan.Awfulhak.org> On Fri, 21 Aug 2009 23:23:13 -0700 Brian Somers wrote: > On Fri, 21 Aug 2009 22:41:34 -0700 Brian Somers wrote: > > On Fri, 21 Aug 2009 21:55:03 -0700 Brian Somers wrote: > > > On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy wrote: > > > > Try this: > > > > > > > > Index: sys/net/flowtable.c > > > > =================================================================== > > > > --- sys/net/flowtable.c (revision 196382) > > > > +++ sys/net/flowtable.c (working copy) > > > > @@ -688,6 +688,12 @@ > > > > struct rtentry *rt = ro->ro_rt; > > > > struct ifnet *ifp = rt->rt_ifp; > > > > > > > > + if (ifp->if_flags & IFF_POINTOPOINT) { > > > > + RTFREE(rt); > > > > + ro->ro_rt = NULL; > > > > + return (ENOENT); > > > > + } > > > > + > > > > if (rt->rt_flags & RTF_GATEWAY) > > > > l3addr = rt->rt_gateway; > > > > else > > > > > > > > You'll need to apply this by hand as gmail munges the formatting. > > > > > > > > -Kip > > > > > > Hi, > > > > > > That certainly stops the panic, however data routed to the tun > > > interface doesn't come out the back end and data written > > > to the back end doesn't come out the tun interface. > > [.....] > > > Maybe this problem isn't a routing problem. I'll > > > look into it further and figure out if the packet is getting to the tun > > > driver and if so, what it thinks it's doing with it. > > > > I wasn't correct - the data *IS* being read out of the back of > > the tunnel device. When I send the ICMP, it goes into the tun > > device and comes out the back end as an AF_LINK packet. ppp > > silently discards this (ironically I have a comment noting > > that I should really track unidentified packet counts). > > > > I'll try to figure out what in if_tun.c is corrupting the family next... > > if_tun.c is fine. The data passed from if_output() has family > AF_LINK - hence the original panic from flowtable_lookup(). > > So the question is "why is ip_output() sending AF_LINK traffic > instead of AF_INET traffic?". > > Still looking.... From what I can tell, this is what is happening: ip_output() is called with ro == NULL. ip_output() calls flowtable_lookup() with a zeroed 'ro'. flowtable_lookup() calls ft->ft_rtalloc() (really rtalloc1_fib()) to initialise 'ro' and ends up with ro->ro_rt->rt_gateway->sa_family set to AF_LINK. Your original patch frees ro->ro_rt and fails before calling llentry_update() with ro->ro_rt->rt_gateway->sa_family != AF_INET. Now, when flowtable_lookup() fails, ro->ro_rt is NULL and ip_output()s 'dst' gets set up with family AF_INET. Unfortunately, right after this, after checking for IP_SENDONES, IP_ROUTETOIF and IN_MULTICAST, the ip_output() code decides to call in_rtalloc_ign() (which eventually just calls rtalloc1_fib()) to initialise ro->ro_rt and then sets dst to be ro->ro_rt->rt_gateway -- which is *still* an AF_LINK address! Finally ip_output() calls ifp->if_output() (really tunoutput()) with dst's family set to AF_LINK, tunoutput() queues it to the tun character device, ppp reads it and drops it on the floor 'cos it doesn't know what to do with AF_LINK. The tun driver is more or less the same as the -stable version, so it seems that ip_output() is to blame. The only relevant part that seems substantially different is rtalloc1_fib(), so right now I'm guessing that the RTF_CLONING code in -stable always clones the route with a gw family of AF_INET and expectations are met after that. I'll look some more on the weekend... > > > > On Fri, Aug 21, 2009 at 16:43, Brian Somers wrote: > > > > > Hi, > > > > > > > > > > I've been working on a fix to address an issue that came up with > > > > > our update of openssh-5. ?The issue is that openssh-5 now uses > > > > > pipe() to create stdin/stdout channels between sshd and the server > > > > > side program where it used to use socketpair(). ?Because it uses > > > > > pipe(), stdin is no longer bi-directional and cannot be used for both > > > > > input and output by a child process. ?This breaks the use of ssh > > > > > as a tunnel with ppp on either end (set device "!ssh -e none host > > > > > ppp -direct label") > > > > > > > > > > I talked with des@ for a while and then with the openssh folks and > > > > > have not been able to resolve the issues in openssh that made them > > > > > choose to enforce the use of pipe() over socketpair(). ?I now have a > > > > > patch to ppp that makes ppp detect that it's connected via pipe() and > > > > > causes it to use stdin for input and stdout for output (usually it expects > > > > > just one descriptor). ?Although I'm happy with the patch and planned on > > > > > requesting permission to commit, I've bumped into a show-stopper > > > > > that seems unrelated, so I thought I'd ask here if anyone has seen > > > > > this or has any suggestions as to what the problem might be. > > > > > > > > > > The issue.... > > > > > > > > > > I'm seeing a panic when I send traffic through a ppp link: > > > > > > > > > > panic string is: sin_family 18 > > > > > Stack trace starts: > > > > > ? ?in_lltable_lookup() > > > > > ? ?llentry_update() > > > > > ? ?flowtable_lookup() > > > > > ? ?ip_output() > > > > > ? ?.... > > > > > > > > > > The panic is due to a KASSERT in in_lltable_lookup() that expects the > > > > > sockaddr to be AF_INET. ?Number 18 is AF_LINK. > > > > > > > > > > AFAICT this is happening while setting up a temporary route for the > > > > > first outbound packet. ?I haven't been able to do much investigation > > > > > yet due to other patches in my tree that seem to have broken all my > > > > > kernel symbols, but once I get a clean rebuild I should be back in > > > > > business. > > > > > > > > > > If anyone has any suggestions, I'm all ears! > > > > > > > > > > Cheers. -- Brian Somers Don't _EVER_ lose your sense of humour ! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090822/563bdfca/signature.pgp From doconnor at gsoft.com.au Sat Aug 22 13:13:42 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Sat Aug 22 13:13:48 2009 Subject: DTrace probes & klds In-Reply-To: <20090821144157.645117jxvao9rmzk@webmail.leidinger.net> References: <200908192331.34507.doconnor@gsoft.com.au> <200908201713.08368.doconnor@gsoft.com.au> <20090821144157.645117jxvao9rmzk@webmail.leidinger.net> Message-ID: <200908222243.35466.doconnor@gsoft.com.au> On Fri, 21 Aug 2009, Alexander Leidinger wrote: > Quoting Daniel O'Connor (from Thu, 20 Aug > 2009 > > 17:13:07 +0930): > > On Thu, 20 Aug 2009, Alexander Leidinger wrote: > >> Quoting Daniel O'Connor (from Wed, 19 Aug > >> 2009 > >> > >> 23:31:33 +0930): > >> > Content-Type: text/plain; > >> > charset="utf-8" > >> > Content-Transfer-Encoding: quoted-printable > >> > Content-Disposition: inline > >> > > >> > Is it possible? the handbook implies not and I can't get it to > >> > work, but i could be doing it wrong.. > >> > > >> > I get fbt traces listed for KLDs (I get new entries for each > >> > load of the KLD which seems like a potential problem) but I > >> > can't specify an SDT_PROBE and have it work. > >> > >> Can you show us some example code? > > > > /* Recycle fbt as SDT_PROVIDER_DEFINE is said not to work */ > > SDT_PROBE_DEFINE(fbt, gsio, gsio_intr, test); > > SDT_PROBE_ARGTYPE(fbt, gsio, gsio_intr, test, 0, "int"); > > SDT_PROBE_ARGTYPE(fbt, gsio, gsio_intr, test, 1, "int"); > > I don't think you can define a fbt probe by hand. You can define a > provider on your own via SDT_PROVIDER_DEFINE (in only one > place/file), and then use this provider instead of fbt above. Let's > assume you defined a gsio provider, then the SDT_PROBE_DEFINE could > be > SDT_PROBE_DEFINE(gsio, , gsio_intr, > test); Yes, I only wanted to reuse fbt because the handbook says SDT_PROBE_DEFINE doesn't work as a KLD. > If there's only one file, it does not make much sense to add an > unique part of the name of the file, but if you have multiple files > it can be helpful. But this is just an example, for example in GEOM > it would make sense to name the provider "geom", and instead of the > file name use the module name, e.g. mirror, raid3, core/whatever, ... > instead. Hmmm. I have tried that, but not joy :( SDT_PROVIDER_DEFINE(gsio); SDT_PROBE_DEFINE(gsio, main, gsio_intr, test); SDT_PROBE_ARGTYPE(gsio, main, gsio_intr, test, 0, "int"); SDT_PROBE_ARGTYPE(gsio, main, gsio_intr, test, 1, "int"); ... SDT_PROBE(gsio, main, gsio_intr, test, istat, 0, 0, 0, 0); I built my module with WITH_CTF=1 and I see that ctfconvert is run, however when I load it the Dtrace providers/providers aren't there. Building it into the kernel works but isn't ideal. Hmm, initially I was building my KLD outside of the tree, however when I build it with buildkernel & load it dtrace -l crashes the system and I can't get a crashdump at the moment.. I'll try again when I can get to the console. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090822/83c5bad7/attachment.pgp From brian at Awfulhak.org Sat Aug 22 06:09:49 2009 From: brian at Awfulhak.org (Brian Somers) Date: Sat Aug 22 13:43:39 2009 Subject: kernel panics in in_lltable_lookup (with INVARIANTS) In-Reply-To: <20090821215503.3eec9a15@dev.lan.Awfulhak.org> References: <20090821164312.641fe2bd@dev.lan.Awfulhak.org> <3c1674c90908211713j36415b96q58b0ed66cc82713f@mail.gmail.com> <20090821215503.3eec9a15@dev.lan.Awfulhak.org> Message-ID: <20090821224134.11d9a2a1@dev.lan.Awfulhak.org> On Fri, 21 Aug 2009 21:55:03 -0700 Brian Somers wrote: > On Fri, 21 Aug 2009 17:13:45 -0700 Kip Macy wrote: > > Try this: > > > > Index: sys/net/flowtable.c > > =================================================================== > > --- sys/net/flowtable.c (revision 196382) > > +++ sys/net/flowtable.c (working copy) > > @@ -688,6 +688,12 @@ > > struct rtentry *rt = ro->ro_rt; > > struct ifnet *ifp = rt->rt_ifp; > > > > + if (ifp->if_flags & IFF_POINTOPOINT) { > > + RTFREE(rt); > > + ro->ro_rt = NULL; > > + return (ENOENT); > > + } > > + > > if (rt->rt_flags & RTF_GATEWAY) > > l3addr = rt->rt_gateway; > > else > > > > You'll need to apply this by hand as gmail munges the formatting. > > > > -Kip > > Hi, > > That certainly stops the panic, however data routed to the tun > interface doesn't come out the back end and data written > to the back end doesn't come out the tun interface. [.....] > Maybe this problem isn't a routing problem. I'll > look into it further and figure out if the packet is getting to the tun > driver and if so, what it thinks it's doing with it. I wasn't correct - the data *IS* being read out of the back of the tunnel device. When I send the ICMP, it goes into the tun device and comes out the back end as an AF_LINK packet. ppp silently discards this (ironically I have a comment noting that I should really track unidentified packet counts). I'll try to figure out what in if_tun.c is corrupting the family next... Cheers. > > On Fri, Aug 21, 2009 at 16:43, Brian Somers wrote: > > > Hi, > > > > > > I've been working on a fix to address an issue that came up with > > > our update of openssh-5. ?The issue is that openssh-5 now uses > > > pipe() to create stdin/stdout channels between sshd and the server > > > side program where it used to use socketpair(). ?Because it uses > > > pipe(), stdin is no longer bi-directional and cannot be used for both > > > input and output by a child process. ?This breaks the use of ssh > > > as a tunnel with ppp on either end (set device "!ssh -e none host > > > ppp -direct label") > > > > > > I talked with des@ for a while and then with the openssh folks and > > > have not been able to resolve the issues in openssh that made them > > > choose to enforce the use of pipe() over socketpair(). ?I now have a > > > patch to ppp that makes ppp detect that it's connected via pipe() and > > > causes it to use stdin for input and stdout for output (usually it expects > > > just one descriptor). ?Although I'm happy with the patch and planned on > > > requesting permission to commit, I've bumped into a show-stopper > > > that seems unrelated, so I thought I'd ask here if anyone has seen > > > this or has any suggestions as to what the problem might be. > > > > > > The issue.... > > > > > > I'm seeing a panic when I send traffic through a ppp link: > > > > > > panic string is: sin_family 18 > > > Stack trace starts: > > > ? ?in_lltable_lookup() > > > ? ?llentry_update() > > > ? ?flowtable_lookup() > > > ? ?ip_output() > > > ? ?.... > > > > > > The panic is due to a KASSERT in in_lltable_lookup() that expects the > > > sockaddr to be AF_INET. ?Number 18 is AF_LINK. > > > > > > AFAICT this is happening while setting up a temporary route for the > > > first outbound packet. ?I haven't been able to do much investigation > > > yet due to other patches in my tree that seem to have broken all my > > > kernel symbols, but once I get a clean rebuild I should be back in > > > business. > > > > > > If anyone has any suggestions, I'm all ears! > > > > > > Cheers. -- Brian Somers Don't _EVER_ lose your sense of humour ! From rwatson at FreeBSD.org Sat Aug 22 14:29:38 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Aug 22 14:29:45 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> Message-ID: On Sat, 22 Aug 2009, Marc Balmer wrote: >> I was looking for the same info a time ago .. something that would allow me >> to gather all the info from the same place, but the only thing I came up >> with was the very same discussion about the sensors framework port and >> nothing else. >> >> Any info on any such proyect will be greatly apreciated > > The OpenBSD sensors framework lacks some desireable features, e.g. event > capabilities like getting an event if a certain threshold is exceeded. And > it propbably was used for things that it better had not (yes, I am culprit > for on of these (ab)uses...). > > I am sure these features could be added if only the code was in the tree to > hack on... One of the things I'd particularly like to see is an alignment between kernel/user level monitoring frameworks and the SNMP model (especially relating to traps). The SNMP information model (MIBs, agents, traps, etc) has its limitations, but having a compatible model at all layers of the system will make it easier to store, manipulate, manage, and report this information consistently throughout the OS and larger distributed systems. Robert From Alexander at Leidinger.net Sat Aug 22 16:29:36 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat Aug 22 17:43:40 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> Message-ID: <20090822182923.000064e0@unknown> On Sat, 22 Aug 2009 08:50:23 +0200 Marc Balmer wrote: > The OpenBSD sensors framework lacks some desireable features, e.g. > event capabilities like getting an event if a certain threshold is > exceeded. And it propbably was used for things that it better had This assumes the kernel is monitoring the device periodically (in the general case, as there are a lot of dump sensors which do not send events on their own). The framework as in the SoC did not provide this feature to keep the kernel part simple. You want to see a value, you poll the kernel for it, and the userland would have been responsible to fire up an event. For smart sensors which trigger an event on their own (interrupt), you can use the exiting kernel event framework (and the idea in the SoC was to use it for such sensors). The devd is the userland side of it. > not (yes, I am culprit for on of these (ab)uses...). > > I am sure these features could be added if only the code was in the > tree to hack on... The event stuff is in the kernel, go ahead and write a driver for your smart sensor which fires events on its own. Bye, Alexander. From Alexander at Leidinger.net Sat Aug 22 16:31:18 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat Aug 22 17:43:51 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: <4A8F986A.3040405@elischer.org> References: <4A8F986A.3040405@elischer.org> Message-ID: <20090822183105.00007262@unknown> On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer wrote: > The purists won out in that one by shouting loudly and screaming > about socialized healthware. Consequently we have 47 million > unsupported devices. You forgot to tell that now nobody wants to touch this subject anymore, as he may be the target of similar shouting then. Bye, Alexander. From marc at msys.ch Sat Aug 22 18:00:25 2009 From: marc at msys.ch (Marc Balmer) Date: Sat Aug 22 18:00:32 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: <20090822182923.000064e0@unknown> References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> <20090822182923.000064e0@unknown> Message-ID: <5A17DFEE-F618-4027-92C5-6EA339B78BF1@msys.ch> Am 22.08.2009 um 18:29 schrieb Alexander Leidinger: > On Sat, 22 Aug 2009 08:50:23 +0200 Marc Balmer wrote: > >> The OpenBSD sensors framework lacks some desireable features, e.g. >> event capabilities like getting an event if a certain threshold is >> exceeded. And it propbably was used for things that it better had > > This assumes the kernel is monitoring the device periodically (in the > general case, as there are a lot of dump sensors which do not send > events on their own). The framework as in the SoC did not provide this > feature to keep the kernel part simple. You want to see a value, you > poll the kernel for it, and the userland would have been responsible > to > fire up an event. > > For smart sensors which trigger an event on their own (interrupt), you > can use the exiting kernel event framework (and the idea in the SoC > was to use it for such sensors). The devd is the userland side of it. > >> not (yes, I am culprit for on of these (ab)uses...). >> >> I am sure these features could be added if only the code was in the >> tree to hack on... > > The event stuff is in the kernel, go ahead and write a driver for your > smart sensor which fires events on its own. Well, most of the sensors are likely I2C or 1-Wire devices and these can only be polled. From alfred at freebsd.org Sat Aug 22 18:48:58 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Sat Aug 22 18:49:05 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: <20090822183105.00007262@unknown> References: <4A8F986A.3040405@elischer.org> <20090822183105.00007262@unknown> Message-ID: <20090822184858.GC21946@elvis.mu.org> * Alexander Leidinger [090822 10:44] wrote: > On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer > wrote: > > > The purists won out in that one by shouting loudly and screaming > > about socialized healthware. Consequently we have 47 million > > unsupported devices. > > You forgot to tell that now nobody wants to touch this subject anymore, > as he may be the target of similar shouting then. I say good riddence, if someone wants thier hardware not to melt then each machine should be personally responsible and enroll in a private monitoring service we don't need project sponsored health monitoring. (ron paul!) -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer From stephen at missouri.edu Sat Aug 22 18:57:15 2009 From: stephen at missouri.edu (Stephen Montgomery-Smith) Date: Sat Aug 22 18:57:22 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: <20090822184858.GC21946@elvis.mu.org> References: <4A8F986A.3040405@elischer.org> <20090822183105.00007262@unknown> <20090822184858.GC21946@elvis.mu.org> Message-ID: <4A903F8A.3010303@missouri.edu> Alfred Perlstein wrote: > * Alexander Leidinger [090822 10:44] wrote: >> On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer >> wrote: >> >>> The purists won out in that one by shouting loudly and screaming >>> about socialized healthware. Consequently we have 47 million >>> unsupported devices. >> You forgot to tell that now nobody wants to touch this subject anymore, >> as he may be the target of similar shouting then. > > I say good riddence, if someone wants thier hardware not to melt > then each machine should be personally responsible and enroll in > a private monitoring service we don't need project sponsored health > monitoring. > > (ron paul!) > I think that this kind of talk calls for boycotting certain device drivers! From ed at 80386.nl Sat Aug 22 19:12:08 2009 From: ed at 80386.nl (Ed Schouten) Date: Sat Aug 22 19:12:15 2009 Subject: CFT: Patch for the Xen console driver Message-ID: <20090822191207.GP1292@hoeg.nl> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090822/2f9f8629/attachment.pgp From julian at elischer.org Sat Aug 22 19:59:48 2009 From: julian at elischer.org (Julian Elischer) Date: Sat Aug 22 19:59:56 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: <4A903F8A.3010303@missouri.edu> References: <4A8F986A.3040405@elischer.org> <20090822183105.00007262@unknown> <20090822184858.GC21946@elvis.mu.org> <4A903F8A.3010303@missouri.edu> Message-ID: <4A904E32.2010609@elischer.org> Stephen Montgomery-Smith wrote: > Alfred Perlstein wrote: >> * Alexander Leidinger [090822 10:44] wrote: >>> On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer >>> wrote: >>> >>>> The purists won out in that one by shouting loudly and screaming >>>> about socialized healthware. Consequently we have 47 million >>>> unsupported devices. >>> You forgot to tell that now nobody wants to touch this subject anymore, >>> as he may be the target of similar shouting then. >> >> I say good riddence, if someone wants thier hardware not to melt >> then each machine should be personally responsible and enroll in >> a private monitoring service we don't need project sponsored health >> monitoring. >> >> (ron paul!) >> > > I think that this kind of talk calls for boycotting certain device drivers! In OpenBSD they have project sponsored healthware and sometimes you have to wait in a queue to get you notifications, and sometimes the queue is so long events have to get merged! Not for me! I want all my individual events to be lost After I get them. It's my right! > > > _______________________________________________ > 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 aurelien.mere at amc-os.com Sat Aug 22 19:21:06 2009 From: aurelien.mere at amc-os.com (Aurélien Méré) Date: Sat Aug 22 20:44:48 2009 Subject: Common interface for sensors/health monitoring References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com><19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com><2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> <20090822182923.000064e0@unknown> Message-ID: >> The OpenBSD sensors framework lacks some desireable features, e.g. >> event capabilities like getting an event if a certain threshold is >> exceeded. And it propbably was used for things that it better had > > This assumes the kernel is monitoring the device periodically (in the > general case, as there are a lot of dump sensors which do not send > events on their own). The framework as in the SoC did not provide this > feature to keep the kernel part simple. You want to see a value, you > poll the kernel for it, and the userland would have been responsible to > fire up an event. In my pratical case, this is perfectly satisfying. Probably most of the controllers I work with don't even support event triggering, and we already have the scripts to trigger events depending on the polled values. I'm worried that today drivers don't exist or don't seem to be maintained to provide these values. So, I would be satisfied just by getting the values. I would be very satisfied if it was in a common interface. Heaven with triggers... I'm just afraid by reading your email that the situation doesn't seem to have evolved since the discussion regarding the SoC, maybe even more taboo, and that I'll have to keep writing my own software and drivers to get the data I want in the future if I want to get this data under FreeBSD.. Is it the case ? Thx Aurélien From stephen at missouri.edu Sun Aug 23 02:52:49 2009 From: stephen at missouri.edu (Stephen Montgomery-Smith) Date: Sun Aug 23 02:52:56 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: <4A904E32.2010609@elischer.org> References: <4A8F986A.3040405@elischer.org> <20090822183105.00007262@unknown> <20090822184858.GC21946@elvis.mu.org> <4A903F8A.3010303@missouri.edu> <4A904E32.2010609@elischer.org> Message-ID: On Sat, 22 Aug 2009, Julian Elischer wrote: > Stephen Montgomery-Smith wrote: >> Alfred Perlstein wrote: >>> * Alexander Leidinger [090822 10:44] wrote: >>>> On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer >>>> wrote: >>>> >>>>> The purists won out in that one by shouting loudly and screaming >>>>> about socialized healthware. Consequently we have 47 million >>>>> unsupported devices. >>>> You forgot to tell that now nobody wants to touch this subject anymore, >>>> as he may be the target of similar shouting then. >>> >>> I say good riddence, if someone wants thier hardware not to melt >>> then each machine should be personally responsible and enroll in >>> a private monitoring service we don't need project sponsored health >>> monitoring. >>> >>> (ron paul!) >>> >> >> I think that this kind of talk calls for boycotting certain device drivers! > > In OpenBSD they have project sponsored healthware and sometimes you have to > wait in a queue to get you notifications, and sometimes > the queue is so long events have to get merged! Not for me! > I want all my individual events to be lost After I get them. > It's my right! Perhaps you are getting too much information through the cable network. Your system might be getting all "wee weed." From dougb at FreeBSD.org Sun Aug 23 04:12:07 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Aug 23 04:12:15 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: References: <4A8F986A.3040405@elischer.org> <20090822183105.00007262@unknown> <20090822184858.GC21946@elvis.mu.org> <4A903F8A.3010303@missouri.edu> <4A904E32.2010609@elischer.org> Message-ID: <4A90C18C.7040907@FreeBSD.org> As terribly clever as you all are, can you please restrict the political commentary/humor/whatever to -chat? Thanks, Doug -- This .signature sanitized for your protection From marc at msys.ch Sun Aug 23 15:15:07 2009 From: marc at msys.ch (Marc Balmer) Date: Sun Aug 23 15:15:14 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: <20090823170849.00000fdb@unknown> References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> <20090822182923.000064e0@unknown> <20090823170849.00000fdb@unknown> Message-ID: <7306B4ED-D9AF-4946-9FCE-BD1CE7685AC2@msys.ch> Am 23.08.2009 um 17:08 schrieb Alexander Leidinger: > On Sat, 22 Aug 2009 21:02:32 +0200 "Aur?lien M?r?" > wrote: > >> I'm just afraid by reading your email that the situation doesn't seem >> to have evolved since the discussion regarding the SoC, maybe even >> more taboo, and that I'll have to keep writing my own software and >> drivers to get the data I want in the future if I want to get this >> data under FreeBSD.. Is it the case ? > > It is not "taboo", it is just that nobody wants to spend his spare > time > with something like this now. > > And yes, as far as I know you have to keep writting our own stuff. But > maybe we can set up a wiki page where people can share their > FreeBSD specific stuff. Someone just has to be willing to invest some > time to add stuff. I have a little script which adds 24 values to > ganglia, and it's extensible (4 lines for wach value), e.g.: > ---snip--- > metrics="${metrics} HD3_Temp" > HD3_Temp_value="$(smartctl -A ad3 |awk '/Temperature_Celsius/ { print > $10 }')" HD3_Temp_type="uint8" > HD3_Temp_unit="Celsius" > > metrics="${metrics} logins" > logins_value="$(who -q | grep users | cut -d ' ' -f 4)" > logins_type="uint8" > logins_unit="Users" > > metrics="${metrics} SwapIn" > SwapIn_value="$(sysctl vm.stats.vm.v_swapin | cut -d ' ' -f 2)" > SwapIn_type="uint32" > SwapIn_unit="Units" > ---snip--- > > I would add my script to such a wiki page, if some else is willing to > start such a page. such a script would indeed be much nicer than a well crafted framework for the job. > If someone not @FreeBSD.org wants to maintain such a page, feel free > to > register in the wiki and tell me (or another committer), I will hand > out > write permission then. I hope people spend their time on thinking what was bad with the sensor framework last time and improve on that, instead. > > Bye, > Alexander. From marc at msys.ch Sun Aug 23 16:39:36 2009 From: marc at msys.ch (Marc Balmer) Date: Sun Aug 23 16:39:43 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: <20090823182454.00006387@unknown> References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> <20090822182923.000064e0@unknown> <20090823170849.00000fdb@unknown> <7306B4ED-D9AF-4946-9FCE-BD1CE7685AC2@msys.ch> <20090823182454.00006387@unknown> Message-ID: <843B14C2-D6D0-4910-B1B4-C7A8CB37635D@msys.ch> Am 23.08.2009 um 18:24 schrieb Alexander Leidinger: > On Sun, 23 Aug 2009 17:13:42 +0200 Marc Balmer wrote: > > >> >> Am 23.08.2009 um 17:08 schrieb Alexander Leidinger: >> >>> On Sat, 22 Aug 2009 21:02:32 +0200 "Aur?lien M?r?" >>> wrote: >>> >>>> I'm just afraid by reading your email that the situation doesn't >>>> seem to have evolved since the discussion regarding the SoC, maybe >>>> even more taboo, and that I'll have to keep writing my own >>>> software and drivers to get the data I want in the future if I >>>> want to get this data under FreeBSD.. Is it the case ? >>> >>> It is not "taboo", it is just that nobody wants to spend his spare >>> time >>> with something like this now. >>> >>> And yes, as far as I know you have to keep writting our own stuff. >>> But maybe we can set up a wiki page where people can share their >>> FreeBSD specific stuff. Someone just has to be willing to invest >>> some time to add stuff. I have a little script which adds 24 values >>> to ganglia, and it's extensible (4 lines for wach value), e.g.: >>> ---snip--- >>> metrics="${metrics} HD3_Temp" >>> HD3_Temp_value="$(smartctl -A ad3 |awk '/Temperature_Celsius/ >>> { print $10 }')" HD3_Temp_type="uint8" >>> HD3_Temp_unit="Celsius" >>> >>> metrics="${metrics} logins" >>> logins_value="$(who -q | grep users | cut -d ' ' -f 4)" >>> logins_type="uint8" >>> logins_unit="Users" >>> >>> metrics="${metrics} SwapIn" >>> SwapIn_value="$(sysctl vm.stats.vm.v_swapin | cut -d ' ' -f 2)" >>> SwapIn_type="uint32" >>> SwapIn_unit="Units" >>> ---snip--- >>> >>> I would add my script to such a wiki page, if some else is willing >>> to start such a page. >> >> >> such a script would indeed be much nicer than a well crafted >> framework for the job. >> > > Indeed... > >>> If someone not @FreeBSD.org wants to maintain such a page, feel >>> free to >>> register in the wiki and tell me (or another committer), I will >>> hand out >>> write permission then. >> >> I hope people spend their time on thinking what was bad with the >> sensor framework last time and improve on that, instead. > > Go and read in the archives about it, maybe you understand why > there's not much motivation to spend spare time on such a topic. Everyone should have the right to come back with a subject, if work is put into it. Or is the stanza that once there has been a heated discussion about a topic, there is no possibility to come back to it, maybe making it better a seccond time? And no, I have no plans to do so... I am just a bit astonished about the attitude... From Alexander at Leidinger.net Sun Aug 23 15:09:01 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sun Aug 23 16:47:29 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> <20090822182923.000064e0@unknown> Message-ID: <20090823170849.00000fdb@unknown> On Sat, 22 Aug 2009 21:02:32 +0200 "Aur?lien M?r?" wrote: > I'm just afraid by reading your email that the situation doesn't seem > to have evolved since the discussion regarding the SoC, maybe even > more taboo, and that I'll have to keep writing my own software and > drivers to get the data I want in the future if I want to get this > data under FreeBSD.. Is it the case ? It is not "taboo", it is just that nobody wants to spend his spare time with something like this now. And yes, as far as I know you have to keep writting our own stuff. But maybe we can set up a wiki page where people can share their FreeBSD specific stuff. Someone just has to be willing to invest some time to add stuff. I have a little script which adds 24 values to ganglia, and it's extensible (4 lines for wach value), e.g.: ---snip--- metrics="${metrics} HD3_Temp" HD3_Temp_value="$(smartctl -A ad3 |awk '/Temperature_Celsius/ { print $10 }')" HD3_Temp_type="uint8" HD3_Temp_unit="Celsius" metrics="${metrics} logins" logins_value="$(who -q | grep users | cut -d ' ' -f 4)" logins_type="uint8" logins_unit="Users" metrics="${metrics} SwapIn" SwapIn_value="$(sysctl vm.stats.vm.v_swapin | cut -d ' ' -f 2)" SwapIn_type="uint32" SwapIn_unit="Units" ---snip--- I would add my script to such a wiki page, if some else is willing to start such a page. If someone not @FreeBSD.org wants to maintain such a page, feel free to register in the wiki and tell me (or another committer), I will hand out write permission then. Bye, Alexander. From Alexander at Leidinger.net Sun Aug 23 16:25:07 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sun Aug 23 16:47:41 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: <7306B4ED-D9AF-4946-9FCE-BD1CE7685AC2@msys.ch> References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> <20090822182923.000064e0@unknown> <20090823170849.00000fdb@unknown> <7306B4ED-D9AF-4946-9FCE-BD1CE7685AC2@msys.ch> Message-ID: <20090823182454.00006387@unknown> On Sun, 23 Aug 2009 17:13:42 +0200 Marc Balmer wrote: > > Am 23.08.2009 um 17:08 schrieb Alexander Leidinger: > > > On Sat, 22 Aug 2009 21:02:32 +0200 "Aur?lien M?r?" > > wrote: > > > >> I'm just afraid by reading your email that the situation doesn't > >> seem to have evolved since the discussion regarding the SoC, maybe > >> even more taboo, and that I'll have to keep writing my own > >> software and drivers to get the data I want in the future if I > >> want to get this data under FreeBSD.. Is it the case ? > > > > It is not "taboo", it is just that nobody wants to spend his spare > > time > > with something like this now. > > > > And yes, as far as I know you have to keep writting our own stuff. > > But maybe we can set up a wiki page where people can share their > > FreeBSD specific stuff. Someone just has to be willing to invest > > some time to add stuff. I have a little script which adds 24 values > > to ganglia, and it's extensible (4 lines for wach value), e.g.: > > ---snip--- > > metrics="${metrics} HD3_Temp" > > HD3_Temp_value="$(smartctl -A ad3 |awk '/Temperature_Celsius/ > > { print $10 }')" HD3_Temp_type="uint8" > > HD3_Temp_unit="Celsius" > > > > metrics="${metrics} logins" > > logins_value="$(who -q | grep users | cut -d ' ' -f 4)" > > logins_type="uint8" > > logins_unit="Users" > > > > metrics="${metrics} SwapIn" > > SwapIn_value="$(sysctl vm.stats.vm.v_swapin | cut -d ' ' -f 2)" > > SwapIn_type="uint32" > > SwapIn_unit="Units" > > ---snip--- > > > > I would add my script to such a wiki page, if some else is willing > > to start such a page. > > > such a script would indeed be much nicer than a well crafted > framework for the job. > Indeed... > > If someone not @FreeBSD.org wants to maintain such a page, feel > > free to > > register in the wiki and tell me (or another committer), I will > > hand out > > write permission then. > > I hope people spend their time on thinking what was bad with the > sensor framework last time and improve on that, instead. Go and read in the archives about it, maybe you understand why there's not much motivation to spend spare time on such a topic. Bye, Alexander. From rpaulo at FreeBSD.org Sun Aug 23 17:11:16 2009 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Sun Aug 23 17:11:22 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: <843B14C2-D6D0-4910-B1B4-C7A8CB37635D@msys.ch> References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> <20090822182923.000064e0@unknown> <20090823170849.00000fdb@unknown> <7306B4ED-D9AF-4946-9FCE-BD1CE7685AC2@msys.ch> <20090823182454.00006387@unknown> <843B14C2-D6D0-4910-B1B4-C7A8CB37635D@msys.ch> Message-ID: <20090823171112.GB2390@mac-mini.lan> On Sun, Aug 23, 2009 at 06:38:12PM +0200, Marc Balmer wrote: > Everyone should have the right to come back with a subject, if work > is put into it. Or is the stanza that once there has been a heated > discussion about a topic, there is no possibility to come back to > it, maybe making it better a seccond time? And no, I have no plans > to do so... I am just a bit astonished about the attitude... I think what Alexander was trying to say was that, given the heated discussion last time, people are now reluctant to restart another discussion. From what I remember, it was very hard to understand why such a large number of messages was being created for such a small detail. Topics, such as these, pose a high risk of making your FreeBSD developer experience more painful than it should be. And since I believe a lot of people here like to work on FreeBSD, sometimes these types of discussions are avoided for a long time just because the developer(s) doesn't(don't) want to make their FreeBSD development experience any more painful. I believe that if we keep insisting on the same bikesheds for a long time, developers will defintely go away. So, there's no ``stanza'' or whatever, just human nature. Regardless of what I just said, the topic keeps coming back and that's a clear sign that a framework should be developed and, possibly, in a way that appeals to both parties. -- Rui Paulo From lists at mawer.org Mon Aug 24 01:01:15 2009 From: lists at mawer.org (Antony Mawer) Date: Mon Aug 24 01:01:23 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: <843B14C2-D6D0-4910-B1B4-C7A8CB37635D@msys.ch> References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> <20090822182923.000064e0@unknown> <20090823170849.00000fdb@unknown> <7306B4ED-D9AF-4946-9FCE-BD1CE7685AC2@msys.ch> <20090823182454.00006387@unknown> <843B14C2-D6D0-4910-B1B4-C7A8CB37635D@msys.ch> Message-ID: On Mon, Aug 24, 2009 at 2:38 AM, Marc Balmer wrote: > Am 23.08.2009 um 18:24 schrieb Alexander Leidinger: >> On Sun, 23 Aug 2009 17:13:42 +0200 Marc Balmer wrote: >>> Am 23.08.2009 um 17:08 schrieb Alexander Leidinger: >>>> On Sat, 22 Aug 2009 21:02:32 +0200 "Aur?lien M?r?" >>>> wrote: >>>> >>>>> I'm just afraid by reading your email that the situation doesn't >>>>> seem to have evolved since the discussion regarding the SoC, maybe >>>>> even more taboo, and that I'll have to keep writing my own >>>>> software and drivers to get the data I want in the future if I >>>>> want to get this data under FreeBSD.. Is it the case ? >>>> >>>> It is not "taboo", it is just that nobody wants to spend his spare >>>> time >>>> with something like this now. >>>> >>> >>> I hope people spend their time on thinking what was bad with the >>> sensor framework last time and improve on that, instead. >> >> Go and read in the archives about it, maybe you understand why >> there's not much motivation to spend spare time on such a topic. > > Everyone should have the right to come back with a subject, if work is put > into it. ?Or is the stanza that once there has been a heated discussion > about a topic, there is no possibility to come back to it, maybe making it > better a seccond time? ?And no, I have no plans to do so... I am just a bit > astonished about the attitude... I for one would be quite happy to contribute towards such an effort. I would much rather contribute towards a project-wide monitoring solution rather than continuing to extend/maintain my own ad-hoc monitoring scripts. I am sure many others are in a similar position... it seems crazy that we are all re-inventing the wheel instead of contributing to a common effort. Is there a summary (perhaps something suitable to go on the Project Ideas page) that outlines: - An outline of what such a system should provide - What it should NOT provide (ie. what would be "out of scope") - What lessons should be learned from the SoC effort (ie. both good points and what NOT to do) - Suggested starting points Maybe that would go a long way to ensuring anyone wanting to start such an effort without getting to the end and having their efforts rejected... Yes, bits of this can be found in the past mailing list posts, but it would nice to have an clear "official" summary of this so that any volunteer effort has the best chance of being accepted... -- Antony From to.my.trociny at gmail.com Mon Aug 24 07:46:04 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Mon Aug 24 07:46:14 2009 Subject: Partial kvm dumps Message-ID: <86ws4tejt5.fsf@kopusha.onet> Hi, I would like to discuss the idea of partial kvm dumps -- the possibility of creating dumps of some parts of the kernel memory from the live system, which later could be read via KVM interface. Why this could be useful. I suppose many people here happened to set up scripts to run utilies like ps, vmstat, top etc periodically to collect system statistics and analyse system behaviour when problems happened. I did this so often that eventually wrote perl script -- wrapper around these utilities to make the setup and later data analysis easier. http://code.google.com/p/gatherit/wiki/README Currently I run this script on most of my servers collecting various statistics about a system. But I feel some discomfort from the fact that this is rather inefficient. Here is typical list of commands I use to collect data: $ ./gather show utils -------------------------------------------------------------------------------- name cmd desc -------------------------------------------------------------------------------- devstat /usr/local/bin/devstat devstat output df /bin/df df output fstat /usr/bin/fstat fstat output netstat-La /usr/bin/netstat -nLa netstat listening socket statistics netstat-a /usr/bin/netstat -na netstat socket statistics netstat-i /usr/bin/netstat -ni netstat interface statistics netstat-m /usr/bin/netstat -m netstat mbuf statistics netstat-r /usr/bin/netstat -nr netstat routing tables netstat-rs /usr/bin/netstat -rs netstat routing statistics netstat-s /usr/bin/netstat -s netstat system wide statistics nfsstat /usr/bin/nfsstat nfsstat output ps /bin/ps auxww processes statistics (-u flag) ps-l /bin/ps alxww processes statistics (-l flag) sockstat /usr/bin/sockstat sockstat output sysctl /sbin/sysctl -a sysctl variables top /usr/bin/top -d1 -S -b 1000 top output (cpu mode) top-mio /usr/bin/top -d1 -S -mio -b 1000 top output (io mode) uptime /usr/bin/uptime system uptime vmstat /usr/bin/vmstat vmstat output vmstat-i /usr/bin/vmstat -ai vmstat interupts statistics Note, many utilities are run several times but with different parameters, also there are comands that do almost the same (e.g. netstat -a and sockstat), processing the same kernel structures. I want them all to run because I don't know in advance what output will turn out more usefull in certain circumstances. It would be more efficient to have some one utility that whould traverse kernel structures extracting all necessary data and later on need this data would be converted to human readable output. And actually we have almost everything for this to work. Many of the system utilities can output data not only from live system but from core dumps too. So if we created dumps from live systems periodically then later we would use them to extract system statistics. Of course there is a little sense in dumping the whole kernel memory. We could extend our KVM interface to have the possibility of creating and then later reading dumps that would contain only necessary parts of kernel memory. As proof of the concept I have written pkvmdump utility that creates partial dumps with some kernel statistics, which can be later exctracted by vmstat and ps utilities. The details of the current implementation: Generated dump has simple format: dump header (struct minidumphdr is used with PKVMDUMP_MAGIC) and data entries. Each data entry has header (address of extracted data in kvm and its lenth) + data itself. So the generation of a dump is very simple -- kvm_open(3) /dev/mem, read necessary regions of memory and write to dump prepending with [addr, len] header. To read the dump the libkvm interface has been extended. The following trick (hack? :-) is used: On kvm_open(): 1) create temporary (unlinked) file; 2) for every data entry from the dump do in tempfile: lseek(addr, SEEK_SET), write(data, len); 3) close dump file and set kd->pmfd to point to tempfile. On kvm_read() the request is translated to direct read from the tempfile. This format/algorithm has been chosen becase of simplicity of implementation, just to start experimenting with this. You can find the source here: http://code.google.com/p/trociny/downloads/list I would like to hear what other people think about this. It looks very useful for me. At least as a first step it would be nice to extend KVM to work with partial dumps so the users could try this and see if it turned out to be useful. P.S. The final goal I would like to achive is to make snapshots of system state, which could be used for later analysis if necessary. May be the approach I try here is wrong. E.g. SNMP looks like more proper alternative solution -- this is standard, also snmpd is actually that program which "traverse kernel structures extracting all necessary data". But SNMP has its own limitations, statistics provided via SNMP are rather limited and currently I don't see how I could use it effectively to echieve my goal, althogh I haven't think much in this direction yet... -- Mikolaj Golub From ed at 80386.nl Mon Aug 24 08:23:14 2009 From: ed at 80386.nl (Ed Schouten) Date: Mon Aug 24 08:23:20 2009 Subject: CFT: Patch for the Xen console driver In-Reply-To: <20090822191207.GP1292@hoeg.nl> References: <20090822191207.GP1292@hoeg.nl> Message-ID: <20090824082312.GD2829@hoeg.nl> * Ed Schouten wrote: > Are there any (8.0-)users here who can test the attached patch for me? No, there aren't. Well, I'll commit it to HEAD. If it turns out that it breaks stuff, I'll give the person who reports it a glass of beer if we ever meet in person. ;-) -- 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/20090824/96cad8d9/attachment.pgp From yuri at rawbw.com Mon Aug 24 08:54:41 2009 From: yuri at rawbw.com (Yuri) Date: Mon Aug 24 08:54:47 2009 Subject: ral0 interface hangs with the message "No buffer space available" Message-ID: <4A92554F.1040506@rawbw.com> Almost every time when I leave system to download a large file I get ral device inoperable after a while. Pinging the other peer causes these messages: > ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available I don't believe that TCP buffer is legitimately filled up to the max because after I bring it down and back up it works fine for a long while. So why didn't this data go through before down/up? If TCP connections are slow buffers shouldn't just fill up: system can and should be preventing this letting apps to hold data streams. Something isn't quite right. Why would network device hang in a steady download scenaio? 7.2-STABLE Yuri From gary.jennejohn at freenet.de Mon Aug 24 11:08:01 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Mon Aug 24 11:10:28 2009 Subject: ral0 interface hangs with the message "No buffer space available" In-Reply-To: <4A92554F.1040506@rawbw.com> References: <4A92554F.1040506@rawbw.com> Message-ID: <20090824130757.560757fa@ernst.jennejohn.org> On Mon, 24 Aug 2009 01:54:39 -0700 Yuri wrote: > Almost every time when I leave system to download a large file I get ral > device inoperable after a while. > Pinging the other peer causes these messages: > > > ping 192.168.0.1 > PING 192.168.0.1 (192.168.0.1): 56 data bytes > ping: sendto: No buffer space available > ping: sendto: No buffer space available > > I don't believe that TCP buffer is legitimately filled up to the max > because after I bring it down and back up it works fine for a long > while. So why didn't this data go through before down/up? > > If TCP connections are slow buffers shouldn't just fill up: system can > and should be preventing this letting apps to hold data streams. > > Something isn't quite right. > > Why would network device hang in a steady download scenaio? > > 7.2-STABLE > The buffers aren't full, it's the send queue used by whichever driver it is which you are using. The down/up frees it up because all queued transmits are discarded. This should never happen in normal operation. You haven't really provided any useful information to allow further analysis. --- Gary Jennejohn From Alexander at Leidinger.net Mon Aug 24 05:35:34 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Mon Aug 24 11:39:01 2009 Subject: Common interface for sensors/health monitoring In-Reply-To: References: <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> <20090822182923.000064e0@unknown> <20090823170849.00000fdb@unknown> <7306B4ED-D9AF-4946-9FCE-BD1CE7685AC2@msys.ch> <20090823182454.00006387@unknown> <843B14C2-D6D0-4910-B1B4-C7A8CB37635D@msys.ch> Message-ID: <20090824073520.642366ipfkqbers4@webmail.leidinger.net> Quoting Antony Mawer (from Mon, 24 Aug 2009 10:34:46 +1000): > On Mon, Aug 24, 2009 at 2:38 AM, Marc Balmer wrote: > Is there a summary (perhaps something suitable to go on the Project > Ideas page) that outlines: > > - An outline of what such a system should provide > - What it should NOT provide (ie. what would be "out of scope") > - What lessons should be learned from the SoC effort (ie. both good > points and what NOT to do) > - Suggested starting points There's nothing like this. The big controversy in the discussion is, that one party wants to put a lot of processing and logic into the kernel (IMO over-engineered), and the GSoC-party wants to keep this complexity out of the kernel (why doing stuff in the kernel when it can be done in the userland, there's no need to get the last few % of performance out of this). Other things discussed there (providing the data via sysctl or via a binary interface in /dev/) are minor implementation details which do not really matter that much (the argument of the GSoC-party was that we already have the sysctl interface and use it already for similar things like process monitoring (kern.proc.*), and it also usable in single-user mode without the need to write another decoding utility for this new binary data). Bye, Alexander. -- Computers are not intelligent. They only think they are. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From cwf-ml at arcor.de Mon Aug 24 12:30:43 2009 From: cwf-ml at arcor.de (Christoph Weber-Fahr) Date: Mon Aug 24 12:30:50 2009 Subject: is there any chance to get HP blade servers supported again? In-Reply-To: <4A92554F.1040506@rawbw.com> References: <4A92554F.1040506@rawbw.com> Message-ID: <4A92836B.2010206@arcor.de> Hello, is there any chance to get HP blade servers (BL460, BL465) supported again? They used to be supported until G5, but the most recent generation doesn't work with FrreeBSD (no support for the network controllers). Does anbody have more information on this? (I asked on .hardware a few weeks ago, but got no information). Regards Christoph Weber-Fahr From marc at msys.ch Mon Aug 24 12:43:51 2009 From: marc at msys.ch (Marc Balmer) Date: Mon Aug 24 12:43:58 2009 Subject: is there any chance to get HP blade servers supported again? In-Reply-To: <4A92836B.2010206@arcor.de> References: <4A92554F.1040506@rawbw.com> <4A92836B.2010206@arcor.de> Message-ID: > is there any chance to get HP blade servers (BL460, BL465) supported > again? > > They used to be supported until G5, but the most recent generation > doesn't work with FrreeBSD (no support for the network controllers). > > Does anbody have more information on this? > > (I asked on .hardware a few weeks ago, but got no information). We just installed FreeBSD 8.0BETA3 (i386) on two HP BL460C, quad Xeon, with HP smart Array200i and QLogic QMH2462 4Gb FC HBA and networking works. At least that's what my colleague, who is onsite, just told me on the phone. - Marc Balmer From ticso at cicely7.cicely.de Mon Aug 24 13:37:24 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Mon Aug 24 13:37:32 2009 Subject: is there any chance to get HP blade servers supported again? In-Reply-To: <4A92836B.2010206@arcor.de> References: <4A92554F.1040506@rawbw.com> <4A92836B.2010206@arcor.de> Message-ID: <20090824131941.GL20020@cicely7.cicely.de> On Mon, Aug 24, 2009 at 02:11:23PM +0200, Christoph Weber-Fahr wrote: > Hello, > > is there any chance to get HP blade servers (BL460, BL465) supported again? > > They used to be supported until G5, but the most recent generation > doesn't work with FrreeBSD (no support for the network controllers). So they've never worked and there is no regression at all. This is always the problem with new hardware - someone needs to write the drivers and before doing that someone need to beg vendors for specs. Unless someone with time and hardwarespecs come up there is no chance. Use another NIC as temporary workaround. > Does anbody have more information on this? > > (I asked on .hardware a few weeks ago, but got no information). Probably because noone has informations? -network list would be an option to get in touch with network people. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From yuri at rawbw.com Mon Aug 24 18:46:59 2009 From: yuri at rawbw.com (Yuri) Date: Mon Aug 24 18:47:05 2009 Subject: ral0 interface hangs with the message "No buffer space available" In-Reply-To: <20090824130757.560757fa@ernst.jennejohn.org> References: <4A92554F.1040506@rawbw.com> <20090824130757.560757fa@ernst.jennejohn.org> Message-ID: <4A92E020.9020502@rawbw.com> Gary Jennejohn wrote: > You haven't really provided any useful information to allow further analysis What would be "useful information"? 'netstat -m' is one. Anything else? Yuri From ivoras at freebsd.org Mon Aug 24 21:27:42 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Aug 24 21:27:49 2009 Subject: Parallel port headers Message-ID: Hi, At least one on-line tutorial about parallel port hacking (http://www.excamera.com/articles/21/parallel.html) uses these header files: #include #include They are actually present in /sys, but not in the normal userland include paths. Is this intentional, or was it removed sometimes in the past? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090824/1a112963/signature.pgp From yuri at rawbw.com Tue Aug 25 03:22:05 2009 From: yuri at rawbw.com (Yuri) Date: Tue Aug 25 03:22:12 2009 Subject: ral0 interface hangs with the message "No buffer space available" In-Reply-To: <4A92554F.1040506@rawbw.com> References: <4A92554F.1040506@rawbw.com> Message-ID: <4A9358DA.9080509@rawbw.com> Here's additional information: 'netstat -m' output: 174/2931/3105 mbufs in use (current/cache/total) 68/1892/1960/25600 mbuf clusters in use (current/cache/total/max) 68/1114 mbuf+clusters out of packet secondary zone in use (current/cache) 0/1327/1327/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 179K/9824K/10004K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/14/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 25 requests for I/O initiated by sendfile 0 calls to protocol drain routines ifconfig ral0: ral0: flags=8c43 metric 0 mtu 1500 ether 00:18:f8:2e:40:25 inet 192.168.0.10 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/48Mbps) status: associated ssid "xxx xxx xxx" channel 6 (2437 Mhz 11g) bssid 00:0c:41:53:e6:71 authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit txpower 50 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS From doconnor at gsoft.com.au Tue Aug 25 03:41:21 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Tue Aug 25 03:41:27 2009 Subject: Parallel port headers In-Reply-To: References: Message-ID: <200908251311.12503.doconnor@gsoft.com.au> On Tue, 25 Aug 2009, Ivan Voras wrote: > Hi, > > At least one on-line tutorial about parallel port hacking > (http://www.excamera.com/articles/21/parallel.html) uses these header > files: > > #include > #include > > They are actually present in /sys, but not in the normal userland > include paths. Is this intentional, or was it removed sometimes in > the past? According to the ppi man page it's.. #include #include #include #include #include int main(int argc, char **argv) { int fd; if ((fd = open("/dev/ppi0", O_RDWR)) == -1) { printf("Can't open /dev/ppi0\n"); exit(1); } exit(0); } Those includes are present on my 7.2 box (upgraded with the last week) and my (oldish) -current box. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090825/637c488a/attachment.pgp From brian at FreeBSD.org Tue Aug 25 11:09:37 2009 From: brian at FreeBSD.org (Brian Somers) Date: Tue Aug 25 11:09:43 2009 Subject: Deprecating ps(1)s -w switch Message-ID: <20090825034054.2d57e733@dev.lan.Awfulhak.org> I recently closed bin/137647 and had second thoughts after Ivan (the originator) challenged my reason for closing it. The suggestion is that ps's -w switch is a strange artifact that can be safely deprecated. ps goes to great lengths to implement width limitations, and any time I've seen people not using -ww has either been a mistake or doesn't matter. Using 'cut -c1-N' is also a great way of limiting widths if people really want that... I'd like to propose changing ps so that width limits are removed and '-w' is deprecated - ignored for now with a note in the man page saying that it will be removed in a future release. Does anyone have any objections to doing this? I don't propose merging this back into stable/8. -- Brian Somers Don't _EVER_ lose your sense of humour ! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090825/0a25d1e2/signature.pgp From marc at msys.ch Tue Aug 25 11:23:49 2009 From: marc at msys.ch (Marc Balmer) Date: Tue Aug 25 11:23:56 2009 Subject: tree doesnt compile Message-ID: <131A8E29-4A35-4CA7-9297-5360B5A8DB19@msys.ch> /usr/src/sys/modules/vesa/../../i386/isa/vesa.c: In function 'vesa_set_mode': /usr/src/sys/modules/vesa/../../i386/isa/vesa.c:1117: error: duplicate case value anyone seeing this as well or is this a local f***up ? From marc at msys.ch Tue Aug 25 12:18:33 2009 From: marc at msys.ch (Marc Balmer) Date: Tue Aug 25 12:18:40 2009 Subject: tree doesnt compile In-Reply-To: <131A8E29-4A35-4CA7-9297-5360B5A8DB19@msys.ch> References: <131A8E29-4A35-4CA7-9297-5360B5A8DB19@msys.ch> Message-ID: <3BF61938-F1E7-43ED-BC9E-C1A180595E90@msys.ch> Am 25.08.2009 um 13:23 schrieb Marc Balmer: > /usr/src/sys/modules/vesa/../../i386/isa/vesa.c: In function > 'vesa_set_mode': > /usr/src/sys/modules/vesa/../../i386/isa/vesa.c:1117: error: > duplicate case value > > anyone seeing this as well or is this a local f***up ? fwiw, problem is still there after 'make clean && make kernel' From shuvaev at physik.uni-wuerzburg.de Tue Aug 25 12:42:21 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Tue Aug 25 12:42:27 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <20090825034054.2d57e733@dev.lan.Awfulhak.org> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> Message-ID: <20090825124215.GA80035@wep4035.physik.uni-wuerzburg.de> On Tue, Aug 25, 2009 at 03:40:54AM -0700, Brian Somers wrote: > I recently closed bin/137647 and had second thoughts after Ivan (the > originator) challenged my reason for closing it. > > The suggestion is that ps's -w switch is a strange artifact that can > be safely deprecated. ps goes to great lengths to implement width > limitations, and any time I've seen people not using -ww has either > been a mistake or doesn't matter. Using 'cut -c1-N' is also a great > way of limiting widths if people really want that... > > I'd like to propose changing ps so that width limits are removed and > '-w' is deprecated - ignored for now with a note in the man page > saying that it will be removed in a future release. > Do you want to remove '-w' switch preserving '-ww' one? IMO this seems awkward. Also, by ignoring it for now do you mean that behavior of ps with '-w' switch would be the same as without it? I would prefer that '-w' == '-ww'. One can remove all references to multiple 'w' switches from the man page but leave ps itself insensitive to any number of 'w' switches (so '-w' == '-ww' == '-www' == ...). This also would be consistent with (for example) http://www.freebsd.org/cgi/man.cgi?query=ps&apropos=0&sektion=0&manpath=Red+Hat+Linux%2Fi386+9&format=html > Does anyone have any objections to doing this? I don't propose > merging this back into stable/8. > 0.02$, Alexey. From ed at 80386.nl Tue Aug 25 13:44:48 2009 From: ed at 80386.nl (Ed Schouten) Date: Tue Aug 25 13:44:55 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <20090825034054.2d57e733@dev.lan.Awfulhak.org> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> Message-ID: <20090825134447.GM2829@hoeg.nl> * Brian Somers wrote: > I recently closed bin/137647 and had second thoughts after Ivan (the > originator) challenged my reason for closing it. > > The suggestion is that ps's -w switch is a strange artifact that can > be safely deprecated. ps goes to great lengths to implement width > limitations, and any time I've seen people not using -ww has either > been a mistake or doesn't matter. Using 'cut -c1-N' is also a great > way of limiting widths if people really want that... > > I'd like to propose changing ps so that width limits are removed and > '-w' is deprecated - ignored for now with a note in the man page > saying that it will be removed in a future release. > > Does anyone have any objections to doing this? I don't propose > merging this back into stable/8. So ps(1) output can never be limited to the screen width? -- 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/20090825/c62292a6/attachment.pgp From j.mckeown at ru.ac.za Tue Aug 25 14:09:12 2009 From: j.mckeown at ru.ac.za (Jonathan McKeown) Date: Tue Aug 25 14:09:19 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <20090825134447.GM2829@hoeg.nl> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <20090825134447.GM2829@hoeg.nl> Message-ID: <200908251609.09302.j.mckeown@ru.ac.za> On Tuesday 25 August 2009 15:44:47 Ed Schouten wrote: > * Brian Somers wrote: > > I recently closed bin/137647 and had second thoughts after Ivan (the > > originator) challenged my reason for closing it. > > > > The suggestion is that ps's -w switch is a strange artifact that can > > be safely deprecated. ps goes to great lengths to implement width > > limitations, and any time I've seen people not using -ww has either > > been a mistake or doesn't matter. Using 'cut -c1-N' is also a great > > way of limiting widths if people really want that... > > > > I'd like to propose changing ps so that width limits are removed and > > '-w' is deprecated - ignored for now with a note in the man page > > saying that it will be removed in a future release. > > > > Does anyone have any objections to doing this? I don't propose > > merging this back into stable/8. > > So ps(1) output can never be limited to the screen width? I usually want to see ps(1) output in easily-read columns. Without width limits, this can't be guaranteed. I would strongly object to the complete removal of any option to limit the output width of ps(1) and make it easily human-readable. I'm also astonished at the suggestion that not using -ww is ``a mistake''. I very seldom need to see the whole commandline for every process. Jonathan From ed at 80386.nl Tue Aug 25 14:10:44 2009 From: ed at 80386.nl (Ed Schouten) Date: Tue Aug 25 14:10:51 2009 Subject: tree doesnt compile In-Reply-To: <3BF61938-F1E7-43ED-BC9E-C1A180595E90@msys.ch> References: <131A8E29-4A35-4CA7-9297-5360B5A8DB19@msys.ch> <3BF61938-F1E7-43ED-BC9E-C1A180595E90@msys.ch> Message-ID: <20090825141042.GN2829@hoeg.nl> * Marc Balmer wrote: > > Am 25.08.2009 um 13:23 schrieb Marc Balmer: > > >/usr/src/sys/modules/vesa/../../i386/isa/vesa.c: In function > >'vesa_set_mode': > >/usr/src/sys/modules/vesa/../../i386/isa/vesa.c:1117: error: > >duplicate case value > > > >anyone seeing this as well or is this a local f***up ? > > fwiw, problem is still there after 'make clean && make kernel' svn up ;-) -- 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/20090825/ffd05758/attachment.pgp From rivanr at gmail.com Tue Aug 25 14:24:31 2009 From: rivanr at gmail.com (Ivan Radovanovic) Date: Tue Aug 25 14:24:38 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <20090825134447.GM2829@hoeg.nl> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <20090825134447.GM2829@hoeg.nl> Message-ID: <4A93EE5B.8000300@gmail.com> Ed Schouten napisa: > * Brian Somers wrote: > >> I recently closed bin/137647 and had second thoughts after Ivan (the >> originator) challenged my reason for closing it. >> >> The suggestion is that ps's -w switch is a strange artifact that can >> be safely deprecated. ps goes to great lengths to implement width >> limitations, and any time I've seen people not using -ww has either >> been a mistake or doesn't matter. Using 'cut -c1-N' is also a great >> way of limiting widths if people really want that... >> >> I'd like to propose changing ps so that width limits are removed and >> '-w' is deprecated - ignored for now with a note in the man page >> saying that it will be removed in a future release. >> >> Does anyone have any objections to doing this? I don't propose >> merging this back into stable/8. >> > > So ps(1) output can never be limited to the screen width? > I think it would be smart not to limit width by default (ie default behavior to be like with -ww), but to have some switch (like -w) to limit width if someone really needs to do that, although with "cut -c 1-80" could be achieved limiting... From ed at 80386.nl Tue Aug 25 14:43:46 2009 From: ed at 80386.nl (Ed Schouten) Date: Tue Aug 25 14:43:53 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <78cb3d3f0908250736g2ef52068pb84896eac5a2c45d@mail.gmail.com> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <20090825134447.GM2829@hoeg.nl> <4A93EE5B.8000300@gmail.com> <78cb3d3f0908250736g2ef52068pb84896eac5a2c45d@mail.gmail.com> Message-ID: <20090825144344.GO2829@hoeg.nl> * Adrian Penisoara wrote: > Maybe we should also think about compatibility with System V Unix / Linux > -- I have encountered quite a lot of scripts expecting "ps -ef" to give an > "all processes" output. It would not hurt to review what the Linux folks did > with their ps(1) -- it supports 3 kinds of options for UNIX/BSD/GNU flavors. In my opinion we should just implement ps(1) as documented in the POSIX Onlinepubs. If it turns out it lacks certain features we want, we could consider adding this to procstat(1) instead. I am of course too lazy to work on this. ;-) -- 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/20090825/61d7e26d/attachment.pgp From ady at freebsd.ady.ro Tue Aug 25 15:03:32 2009 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Tue Aug 25 15:03:39 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <4A93EE5B.8000300@gmail.com> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <20090825134447.GM2829@hoeg.nl> <4A93EE5B.8000300@gmail.com> Message-ID: <78cb3d3f0908250736g2ef52068pb84896eac5a2c45d@mail.gmail.com> Hi, On Tue, Aug 25, 2009 at 3:59 PM, Ivan Radovanovic wrote: > Ed Schouten napisa: > > * Brian Somers wrote: >> >> >>> I recently closed bin/137647 and had second thoughts after Ivan (the >>> originator) challenged my reason for closing it. >>> >>> The suggestion is that ps's -w switch is a strange artifact that can >>> be safely deprecated. ps goes to great lengths to implement width >>> limitations, and any time I've seen people not using -ww has either >>> been a mistake or doesn't matter. Using 'cut -c1-N' is also a great >>> way of limiting widths if people really want that... >>> >>> I'd like to propose changing ps so that width limits are removed and >>> '-w' is deprecated - ignored for now with a note in the man page >>> saying that it will be removed in a future release. >>> >>> Does anyone have any objections to doing this? I don't propose >>> merging this back into stable/8. >>> >>> >> >> So ps(1) output can never be limited to the screen width? >> >> > I think it would be smart not to limit width by default (ie default > behavior to be like with -ww), but to have some switch (like -w) to limit > width if someone really needs to do that, although with "cut -c 1-80" could > be achieved limiting... Let's not reverse the meaning of switches, for the sake of compatibility with (older) existent scripts... Maybe we should also think about compatibility with System V Unix / Linux -- I have encountered quite a lot of scripts expecting "ps -ef" to give an "all processes" output. It would not hurt to review what the Linux folks did with their ps(1) -- it supports 3 kinds of options for UNIX/BSD/GNU flavors. Regards, Adrian Penisoara EnterpriseBSD From kientzle at freebsd.org Tue Aug 25 16:11:15 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Tue Aug 25 16:11:22 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <200908251609.09302.j.mckeown@ru.ac.za> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <20090825134447.GM2829@hoeg.nl> <200908251609.09302.j.mckeown@ru.ac.za> Message-ID: <4A9407D3.60006@freebsd.org> Jonathan McKeown wrote: > On Tuesday 25 August 2009 15:44:47 Ed Schouten wrote: >> * Brian Somers wrote: >>> I recently closed bin/137647 and had second thoughts after Ivan (the >>> originator) challenged my reason for closing it. >>> >>> The suggestion is that ps's -w switch is a strange artifact that can >>> be safely deprecated. ps goes to great lengths to implement width >>> limitations, and any time I've seen people not using -ww has either >>> been a mistake or doesn't matter. The difference between "ps", "ps -w", and "ps -ww" is pretty significant for Java, in particular. Java command lines are typically enormous (thank you, CLASSPATH) which makes "ps -ww" often more annoying than it's worth. I concur with another poster that the GNU ps approach for supporting multiple argument styles deserves consideration. Tim From frank at exit.com Tue Aug 25 16:23:18 2009 From: frank at exit.com (Frank Mayhar) Date: Tue Aug 25 16:23:26 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <4A9407D3.60006@freebsd.org> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <20090825134447.GM2829@hoeg.nl> <200908251609.09302.j.mckeown@ru.ac.za> <4A9407D3.60006@freebsd.org> Message-ID: <1251217395.83189.1.camel@jill.exit.com> On Tue, 2009-08-25 at 08:48 -0700, Tim Kientzle wrote: > Jonathan McKeown wrote: > > On Tuesday 25 August 2009 15:44:47 Ed Schouten wrote: > >> * Brian Somers wrote: > >>> I recently closed bin/137647 and had second thoughts after Ivan (the > >>> originator) challenged my reason for closing it. > >>> > >>> The suggestion is that ps's -w switch is a strange artifact that can > >>> be safely deprecated. ps goes to great lengths to implement width > >>> limitations, and any time I've seen people not using -ww has either > >>> been a mistake or doesn't matter. > > The difference between "ps", "ps -w", and "ps -ww" is pretty > significant for Java, in particular. Java command lines > are typically enormous (thank you, CLASSPATH) which makes > "ps -ww" often more annoying than it's worth. > > I concur with another poster that the GNU ps approach for > supporting multiple argument styles deserves consideration. I realized that nobody asked me, but IMHO it ain't broke so don't fix it. I use -w and -ww a lot, and yes, I do distinguish them. Sometimes -w is enough; if it isn't, then I'll use -ww but otherwise I avoid it because it gives just too much output in many cases. -- Frank Mayhar frank@exit.com http://www.exit.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* From avg at freebsd.org Tue Aug 25 16:54:42 2009 From: avg at freebsd.org (Andriy Gapon) Date: Tue Aug 25 16:54:49 2009 Subject: GA-MA780G-UD3H motherboard Message-ID: <4A9412ED.6080309@freebsd.org> I have become to own Gigabyte GA-MA780G-UD3H motherboard: http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ClassValue=Motherboard&ProductID=3004&ProductName=GA-MA780G-UD3H It is based on AMD 780G + SB700. BTW, CPU I am using is Athlon II X2 250. Sorry for the broadcast announcement, but this is my first AMD-based system in many years, so I eagerly started exploring it and hacking for it. For this reason please expect a number of questions from me as well as some reports and hopefully code related to this motherboard. I am going to post them as follow-ups to this email. Meanwhile, if you interested in any information about this motherboard - data dumps, outputs from tools, etc - please let me know, I will try my best to provide that. -- Andriy Gapon From avg at freebsd.org Tue Aug 25 17:34:12 2009 From: avg at freebsd.org (Andriy Gapon) Date: Tue Aug 25 17:34:19 2009 Subject: AMD SB700 watchdog driver? In-Reply-To: <4A9412ED.6080309@freebsd.org> References: <4A9412ED.6080309@freebsd.org> Message-ID: <4A942091.6000909@freebsd.org> Anybody has any code for AMD SB700 watchdog driver? I see that there is none in FreeBSD and I'd like to write one. So I could re-use anything that you have for a faster start. In any case, I expect the driver to be rather simple. -- Andriy Gapon From avg at freebsd.org Tue Aug 25 17:49:34 2009 From: avg at freebsd.org (Andriy Gapon) Date: Tue Aug 25 17:49:44 2009 Subject: AMD SB700 SMBus controller driver In-Reply-To: <4A9412ED.6080309@freebsd.org> References: <4A9412ED.6080309@freebsd.org> Message-ID: <4A94242B.7090806@freebsd.org> According to SB700 specifications its SMBus controller is very similar to one in PIIX4. The differences that I see so far: 1. Interrupt Line/Interrupt Pin PCI configuration registers (0x3c, 0x3d) do not specify interrupt number that the controller could use: > This register specifies which interrupt pin the device issue > This module does not generate interrupt but contains the > actual interrupt controller. This register is hardcoded to 0. 2. I2CbusConfig register (0xd2) uses bit #1 to indicate whether SMI or regular interrupt is used in interrupt mode; PIIX4 uses bit 3. I couldn't get our intpm driver to work with this hardware by simply adding PCI id and tweaking 0xd2 bits meaning. I could get it to work by forcing polling mode. It appears that Linux driver for this HW always uses polling mode, and OpenBSD and NetBSD drivers would use it with this HW too. I am still trying to get interrupt mode to work. I set 0xd2 to enable regular interrupt generation (it is set to SMI after boot). SB700 specifications say at one place that SMB interrupt is connected to INTIN20 pin of IO-APIC in APIC mode. I tried setting up IRQ20 in the driver but no interrupts are generated. And there are no stray interrupts either. So I am not sure - either this HW doesn't generate normal interrupts at all, or they to a different pin, or additional setup is required, or I am doing something wrong. Anyway, I plan to produce an updated version of intpm driver with possibility of forced or auto-detected polling mode and support for PCI id of SB700 SMBus controller and its peculiarities. -- Andriy Gapon From avg at freebsd.org Tue Aug 25 18:00:50 2009 From: avg at freebsd.org (Andriy Gapon) Date: Tue Aug 25 18:01:02 2009 Subject: GA-MA780G-UD3H hardware monitoring In-Reply-To: <4A9412ED.6080309@freebsd.org> References: <4A9412ED.6080309@freebsd.org> Message-ID: <4A9426CF.1030205@freebsd.org> Does anybody know if Gigabyte provides special ACPI interfaces for HWM on their motherboards? Maybe something like ASUS does (acpi_aiboost)? Or do they access HWM chip directly? They have this EasyTune software, so they must be doing something. DSDT of GA-MA780G-UD3H doesn't even provide TZ. This motherboard has iTE IT8718 Super I/O + HWM chip. Thanks to superiotool from coreboot project I determined that base address (port actually) for HWM logical device is at 0x228 (as opposed to more typical 0x290). Slightly modified version of mbmon is even able to recognize the chip and get some data. I am not sure if the data is entirely correct, but it looks sane/reasonable. Still I would like to not only monitor temperatures, voltages and fan speeds, but even to be able to control fan speed. Any links, pointers, ideas, code would be very appreciated! -- Andriy Gapon From julian at elischer.org Tue Aug 25 18:06:57 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 25 18:07:04 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <20090825034054.2d57e733@dev.lan.Awfulhak.org> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> Message-ID: <4A942531.6000702@elischer.org> Brian Somers wrote: > I recently closed bin/137647 and had second thoughts after Ivan (the > originator) challenged my reason for closing it. > > The suggestion is that ps's -w switch is a strange artifact that can > be safely deprecated. ps goes to great lengths to implement width > limitations, and any time I've seen people not using -ww has either > been a mistake or doesn't matter. Using 'cut -c1-N' is also a great > way of limiting widths if people really want that... > > I'd like to propose changing ps so that width limits are removed and > '-w' is deprecated - ignored for now with a note in the man page > saying that it will be removed in a future release. > > Does anyone have any objections to doing this? I don't propose > merging this back into stable/8. > my fingers would object as ps auxw is my standard command. From dougb at FreeBSD.org Tue Aug 25 18:50:16 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Aug 25 18:50:22 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <20090825034054.2d57e733@dev.lan.Awfulhak.org> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> Message-ID: <4A94325D.6070201@FreeBSD.org> Brian Somers wrote: > I recently closed bin/137647 and had second thoughts after Ivan (the > originator) challenged my reason for closing it. > > The suggestion is that ps's -w switch is a strange artifact that can > be safely deprecated. ps goes to great lengths to implement width > limitations, and any time I've seen people not using -ww has either > been a mistake or doesn't matter. Using 'cut -c1-N' is also a great > way of limiting widths if people really want that... > > I'd like to propose changing ps so that width limits are removed and > '-w' is deprecated - ignored for now with a note in the man page > saying that it will be removed in a future release. > > Does anyone have any objections to doing this? I don't propose > merging this back into stable/8. Short version, yes, I object to changing the defaults. Longer version, I don't see anything wrong with the defaults the way that they are, and the fact that there is a teeny-tiny learning curve for people who need to see the full output isn't really an issue that deserves the time already spent on it. Bruce pointed out in the PR that most users would be surprised if 'ps -ax | grep foo' suddenly sprouted a lot more stuff that 'ps -ax' didn't have, and I agree. As a matter of personal preference I find the current defaults to be just lovely, and occasionally use -w or -ww if I need to see more. If you want the default to be something different, that's what aliases are for. Doug -- This .signature sanitized for your protection From sfourman at gmail.com Tue Aug 25 19:00:38 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Tue Aug 25 19:00:45 2009 Subject: GA-MA780G-UD3H motherboard In-Reply-To: <4A9412ED.6080309@freebsd.org> References: <4A9412ED.6080309@freebsd.org> Message-ID: <11167f520908251134u7454267fl7a4e1e4657405a6f@mail.gmail.com> > Meanwhile, if you interested in any information about this motherboard - data > dumps, outputs from tools, etc - please let me know, I will try my best to provide > that. it would be interesting to see a dmesg as a starting point. Sam Fourman Jr. From rivanr at gmail.com Tue Aug 25 19:08:27 2009 From: rivanr at gmail.com (Ivan Radovanovic) Date: Tue Aug 25 19:08:33 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <4A94325D.6070201@FreeBSD.org> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <4A94325D.6070201@FreeBSD.org> Message-ID: <4A9436A7.2020108@gmail.com> Doug Barton napisa: > Brian Somers wrote: > >> I recently closed bin/137647 and had second thoughts after Ivan (the >> originator) challenged my reason for closing it. >> >> The suggestion is that ps's -w switch is a strange artifact that can >> be safely deprecated. ps goes to great lengths to implement width >> limitations, and any time I've seen people not using -ww has either >> been a mistake or doesn't matter. Using 'cut -c1-N' is also a great >> way of limiting widths if people really want that... >> >> I'd like to propose changing ps so that width limits are removed and >> '-w' is deprecated - ignored for now with a note in the man page >> saying that it will be removed in a future release. >> >> Does anyone have any objections to doing this? I don't propose >> merging this back into stable/8. >> > > Short version, yes, I object to changing the defaults. > > Longer version, I don't see anything wrong with the defaults the way > that they are, and the fact that there is a teeny-tiny learning curve > for people who need to see the full output isn't really an issue that > deserves the time already spent on it. Bruce pointed out in the PR > that most users would be surprised if 'ps -ax | grep foo' suddenly > sprouted a lot more stuff that 'ps -ax' didn't have, and I agree. As a > matter of personal preference I find the current defaults to be just > lovely, and occasionally use -w or -ww if I need to see more. If you > want the default to be something different, that's what aliases are for. > > > Doug > So, if the developer is presented with a task of developing utility to list running processes on the machine the right way to solve this problem is to implement it exactly the way the ps is implemented (ie, to please some aesthetic criteria (ie to format output to some width) rather than to focus on functionality)? I think software should evolve to be better rather then to stick with something done the wrong way, even that has been done maybe 30 years ago - that is why behavior should be changed. It is never too late to do the right thing ;-) Best regards, Ivan From dougb at FreeBSD.org Tue Aug 25 19:15:47 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Aug 25 19:15:55 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <4A9436A7.2020108@gmail.com> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <4A94325D.6070201@FreeBSD.org> <4A9436A7.2020108@gmail.com> Message-ID: <4A94385A.1000405@FreeBSD.org> Ivan Radovanovic wrote: > So, if the developer is presented with a task of developing utility to > list running processes on the machine the right way to solve this > problem is to implement it exactly the way the ps is implemented (ie, to > please some aesthetic criteria (ie to format output to some width) > rather than to focus on functionality)? If you're developing your own app to display running processes implement it any way you wish. That's totally unrelated to the question at hand. Doug -- This .signature sanitized for your protection From rivanr at gmail.com Tue Aug 25 19:31:40 2009 From: rivanr at gmail.com (Ivan Radovanovic) Date: Tue Aug 25 19:31:47 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <4A94385A.1000405@FreeBSD.org> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <4A94325D.6070201@FreeBSD.org> <4A9436A7.2020108@gmail.com> <4A94385A.1000405@FreeBSD.org> Message-ID: <4A943C18.2050103@gmail.com> Doug Barton napisa: > If you're developing your own app to display running processes > implement it any way you wish. That's totally unrelated to the > question at hand. > > Doug > I totally disagree with you - being against change means that you believe it is done the best way it could be done. Although there is another way to solve this "problem" - manual can be changed to state in the first row "process status formated for terminal output" instead of "process status" which is now title for ps. That way it would be obvious at the first look that ps is tightly coupled with terminal it is running on and nobody would need to learn this harder way. Regards, Ivan From dougb at FreeBSD.org Tue Aug 25 19:35:47 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Aug 25 19:35:54 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <4A943C18.2050103@gmail.com> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <4A94325D.6070201@FreeBSD.org> <4A9436A7.2020108@gmail.com> <4A94385A.1000405@FreeBSD.org> <4A943C18.2050103@gmail.com> Message-ID: <4A943D06.405@FreeBSD.org> Ivan Radovanovic wrote: > Doug Barton napisa: >> If you're developing your own app to display running processes >> implement it any way you wish. That's totally unrelated to the >> question at hand. >> >> Doug >> > I totally disagree with you - being against change means that you > believe it is done the best way it could be done. This argument is so non-sequitur that I'm tempted not to respond, but no, that's not what I'm saying at all. What I'm saying is that there are valid reasons to leave the defaults as they are, AND if you don't like the defaults there are easy ways to manipulate that in your own environment. > Although there is another way to solve this "problem" - manual can be > changed to state in the first row "process status formated for terminal > output" instead of "process status" which is now title for ps. That way > it would be obvious at the first look that ps is tightly coupled with > terminal it is running on and nobody would need to learn this harder way. Feel free to take a crack at this and send the results to the list for review. Improving the documentation is always a worthy goal. Doug -- This .signature sanitized for your protection From rivanr at gmail.com Tue Aug 25 20:03:01 2009 From: rivanr at gmail.com (Ivan Radovanovic) Date: Tue Aug 25 20:03:07 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <4A943D06.405@FreeBSD.org> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <4A94325D.6070201@FreeBSD.org> <4A9436A7.2020108@gmail.com> <4A94385A.1000405@FreeBSD.org> <4A943C18.2050103@gmail.com> <4A943D06.405@FreeBSD.org> Message-ID: <4A944370.2000306@gmail.com> Doug Barton napisa: > Ivan Radovanovic wrote: > >> I totally disagree with you - being against change means that you >> believe it is done the best way it could be done. >> > This argument is so non-sequitur that I'm tempted not to respond, but > no, that's not what I'm saying at all. What I'm saying is that there > are valid reasons to leave the defaults as they are, AND if you don't > like the defaults there are easy ways to manipulate that in your own > environment. > You wrote : Longer version, I don't see anything wrong with the defaults the way that they are, and the fact that there is a teeny-tiny learning curve for people who need to see the full output isn't really an issue that deserves the time already spent on it. Bruce pointed out in the PR that most users would be surprised if 'ps -ax | grep foo' suddenly sprouted a lot more stuff that 'ps -ax' didn't have, and I agree. As a matter of personal preference I find the current defaults to be just lovely, and occasionally use -w or -ww if I need to see more. If you want the default to be something different, that's what aliases are for. So, valid arguments against change should be: 1. users will be surprised if ps starts displaying more stuff no matter if that stuff is correct and less stuff (current state) is incorrect 2. your personal preference is that current defaults are lovely Sorry, I don't find these arguments valid >> Although there is another way to solve this "problem" - manual can be >> changed to state in the first row "process status formated for terminal >> output" instead of "process status" which is now title for ps. That way >> it would be obvious at the first look that ps is tightly coupled with >> terminal it is running on and nobody would need to learn this harder way. >> > Feel free to take a crack at this and send the results to the list for > review. Improving the documentation is always a worthy goal. > I would do that for sure if everyone thinks this ps behavior is something that should be kept at current state even if it could be made better Ivan From rnoland at FreeBSD.org Tue Aug 25 20:08:54 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Aug 25 20:09:01 2009 Subject: GA-MA780G-UD3H motherboard In-Reply-To: <200908252127.48214.thierry.herbelot@free.fr> References: <4A9412ED.6080309@freebsd.org> <11167f520908251134u7454267fl7a4e1e4657405a6f@mail.gmail.com> <200908252127.48214.thierry.herbelot@free.fr> Message-ID: <1251230025.45706.280.camel@balrog.2hip.net> On Tue, 2009-08-25 at 21:27 +0200, Thierry Herbelot wrote: > Le Tuesday 25 August 2009, Sam Fourman Jr. a ?crit : > > > Meanwhile, if you interested in any information about this motherboard - > > > data dumps, outputs from tools, etc - please let me know, I will try my > > > best to provide that. > > > > it would be interesting to see a dmesg as a starting point. > > > here you are ;-) > > I have plugged a PCI sound board in the machine, but it does seem to be > detected (there could be some issue with PCI bus enumeration : I also include > a pciconf log) I'm curious why you would plug in a pci sound card? You already have both a standard hda codec as well as the hda codec for the hdmi port of the video. If you are discovering that it isn't working... set hw.snd.default_unit=1 which is typcially your normal analog audio port. The hdmi port on radeon chips tends to be enumerated before the normal system codecs, so people tend to think that sound isn't working. robert. > TfH > > > > Sam Fourman Jr. > > _______________________________________________ > > 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" > > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.2-STABLE #12: Mon Jul 6 09:37:34 CEST 2009 > XXX@YYY:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (3106.64-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 > > Features=0x178bfbff > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x11f > TSC: P-state invariant > Cores per package: 2 > usable memory = 4008947712 (3823 MB) > avail memory = 3836862464 (3659 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > This module (opensolaris) contains code covered by the > Common Development and Distribution License (CDDL) > see http://opensolaris.org/os/licensing/opensolaris_license/ > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, bfce0000 (3) failed > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0xee00-0xeeff mem > 0xd0000000-0xdfffffff,0xfdfe0000-0xfdfeffff,0xfde00000-0xfdefffff irq 18 at > device 5.0 on pci1 > hdac0: mem 0xfdffc000-0xfdffffff > irq 19 at device 5.1 on pci1 > hdac0: HDA Driver Revision: 20090329_0131 > hdac0: [ITHREAD] > pcib2: irq 18 at device 10.0 on pci0 > pci2: on pcib2 > re0: Ethernet> port 0xde00-0xdeff mem 0xfdaff000-0xfdafffff,0xfdae0000-0xfdaeffff > irq 18 at device 0.0 on pci2 > re0: Using 1 MSI messages > re0: Chip rev. 0x3c000000 > re0: MAC rev. 0x00400000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > re0: Ethernet address: 00:1f:d0:56:75:23 > re0: [FILTER] > atapci0: port > 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem > 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0 > atapci0: [ITHREAD] > atapci0: AHCI Version 01.10 controller with 6 ports detected > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > ata4: on atapci0 > ata4: [ITHREAD] > ata5: on atapci0 > ata5: [ITHREAD] > ata6: on atapci0 > ata6: [ITHREAD] > ata7: on atapci0 > ata7: [ITHREAD] > ohci0: mem 0xfe02e000-0xfe02efff irq 16 at > device 18.0 on pci0 > ohci0: [GIANT-LOCKED] > ohci0: [ITHREAD] > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 3 ports with 3 removable, self powered > ohci1: mem 0xfe02d000-0xfe02dfff irq 16 at > device 18.1 on pci0 > ohci1: [GIANT-LOCKED] > ohci1: [ITHREAD] > usb1: OHCI version 1.0, legacy support > usb1: SMM does not respond, resetting > usb1: on ohci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 3 ports with 3 removable, self powered > ehci0: mem 0xfe02c000-0xfe02c0ff irq 17 at > device 18.2 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb2: EHCI version 1.0 > usb2: companion controllers, 3 ports each: usb0 usb1 > usb2: on ehci0 > usb2: USB revision 2.0 > uhub2: on usb2 > uhub2: 6 ports with 6 removable, self powered > ohci2: mem 0xfe02b000-0xfe02bfff irq 18 at > device 19.0 on pci0 > ohci2: [GIANT-LOCKED] > ohci2: [ITHREAD] > usb3: OHCI version 1.0, legacy support > usb3: on ohci2 > usb3: USB revision 1.0 > uhub3: on usb3 > uhub3: 3 ports with 3 removable, self powered > ohci3: mem 0xfe02a000-0xfe02afff irq 18 at > device 19.1 on pci0 > ohci3: [GIANT-LOCKED] > ohci3: [ITHREAD] > usb4: OHCI version 1.0, legacy support > usb4: SMM does not respond, resetting > usb4: on ohci3 > usb4: USB revision 1.0 > uhub4: on usb4 > uhub4: 3 ports with 3 removable, self powered > ehci1: mem 0xfe029000-0xfe0290ff irq 19 at > device 19.2 on pci0 > ehci1: [GIANT-LOCKED] > ehci1: [ITHREAD] > usb5: EHCI version 1.0 > usb5: companion controllers, 3 ports each: usb3 usb4 > usb5: on ehci1 > usb5: USB revision 2.0 > uhub5: on usb5 > uhub5: 6 ports with 6 removable, self powered > pci0: at device 20.0 (no driver attached) > atapci1: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 20.1 on pci0 > ata0: on atapci1 > ata0: [ITHREAD] > hdac1: mem 0xfe024000-0xfe027fff > irq 16 at device 20.2 on pci0 > hdac1: HDA Driver Revision: 20090329_0131 > hdac1: [ITHREAD] > isab0: at device 20.3 on pci0 > isa0: on isab0 > pcib3: at device 20.4 on pci0 > pci3: on pcib3 > fwohci0: mem > 0xfdcff000-0xfdcff7ff,0xfdcf8000-0xfdcfbfff irq 22 at device 14.0 on pci3 > fwohci0: [FILTER] > fwohci0: OHCI version 1.10 (ROM=0) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:70:c0:59:00:00:1f:d0 > fwohci0: Phy 1394a available S400, 3 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:70:c0:00:1f:d0 > fwe0: Ethernet address: 02:70:c0:00:1f:d0 > fwip0: on firewire0 > fwip0: Firewire address: 00:70:c0:59:00:00:1f:d0 @ 0xfffe00000000, S400, > maxrec 2048 > sbp0: on firewire0 > dcons_crom0: on firewire0 > dcons_crom0: bus_addr 0xb6e80000 > fwohci0: Initiate bus reset > fwohci0: BUS reset > fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode > ohci4: mem 0xfe028000-0xfe028fff irq 18 at > device 20.5 on pci0 > ohci4: [GIANT-LOCKED] > ohci4: [ITHREAD] > usb6: OHCI version 1.0, legacy support > usb6: SMM does not respond, resetting > usb6: on ohci4 > usb6: USB revision 1.0 > uhub6: on usb6 > uhub6: 2 ports with 2 removable, self powered > amdtemp0: on hostb4 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FILTER] > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > sio0: [FILTER] > ppc0: port 0x378-0x37f irq 7 on acpi0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppbus0: on ppc0 > ppbus0: [ITHREAD] > plip0: on ppbus0 > plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model Generic PS/2 mouse, device ID 0 > cpu0: on acpi0 > powernow0: on cpu0 > cpu1: on acpi0 > powernow1: on cpu1 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio2: configured irq 5 not in bitmap of probed irqs 0 > sio2: port may not be enabled > sio3: configured irq 9 not in bitmap of probed irqs 0 > sio3: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > WARNING: ZFS is considered to be an experimental feature in FreeBSD. > Timecounters tick every 1.000 msec > firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) > firewire0: bus manager 0 (me) > ad4: 238474MB at ata2-master SATA150 > ZFS filesystem version 13 > ZFS storage pool version 13 > ad6: 238475MB at ata3-master SATA150 > ad8: 238475MB at ata4-master SATA150 > acd0: DVDR at ata7-master SATA150 > hdac0: HDA Codec #0: ATI RS690/780 HDMI > pcm0: at cad 0 nid 1 on hdac0 > hdac1: HDA Codec #0: Realtek ALC885 > pcm1: at cad 0 nid 1 on hdac1 > pcm2: at cad 0 nid 1 on hdac1 > pcm3: at cad 0 nid 1 on hdac1 > GEOM_LABEL: Label for provider ad4s1a is ufsid/4895a4a721182022. > GEOM_LABEL: Label for provider ad4s1d is ufsid/4895a4b3b6d4e02e. > GEOM_LABEL: Label for provider ad4s1e is ufsid/4895a4b54799f68b. > GEOM_LABEL: Label for provider ad4s1f is ufsid/4895a4b724bcb48f. > GEOM_LABEL: Label for provider ad4s2a is ufsid/49185b60bbfa4d50. > GEOM_LABEL: Label for provider ad6s1 is ext2fs//. > GEOM_LABEL: Label for provider ad6s2 is ext2fs//1. > GEOM_LABEL: Label for provider ad8s1a is ufsid/4895a498589c3d5f. > GEOM_LABEL: Label for provider ad8s1d is ufsid/4895a48d5fd2f14b. > GEOM_LABEL: Label for provider ad8s1e is ufsid/4895a48489eb6120. > GEOM_LABEL: Label for provider ad8s1f is ufsid/4895a48a019d7151. > GEOM_LABEL: Label for provider ad8s2a is ufsid/4729b57b020c7526. > GEOM_LABEL: Label for provider ad8s2d is ufsid/4729b587458f5554. > GEOM_LABEL: Label for provider ad8s2e is ufsid/4729b58af29c6330. > SMP: AP CPU #1 Launched! > Trying to mount root from ufs:/dev/ad4s2a > GEOM_LABEL: Label ufsid/49185b60bbfa4d50 removed. > > > > machine# pciconf -lv > hostb0@pci0:0:0:0: class=0x060000 card=0x96001022 chip=0x96001022 > rev=0x00 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > class = bridge > subclass = HOST-PCI > pcib1@pci0:0:1:0: class=0x060400 card=0x96021022 chip=0x96021022 > rev=0x00 hdr=0x01 > vendor = 'Advanced Micro Devices (AMD)' > class = bridge > subclass = PCI-PCI > pcib2@pci0:0:10:0: class=0x060400 card=0x96001022 chip=0x96091022 > rev=0x00 hdr=0x01 > vendor = 'Advanced Micro Devices (AMD)' > class = bridge > subclass = PCI-PCI > atapci0@pci0:0:17:0: class=0x010601 card=0xb0021458 chip=0x43911002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'SB700 SATA Controller [AHCI mode]' > class = mass storage > subclass = SATA > ohci0@pci0:0:18:0: class=0x0c0310 card=0x50041458 chip=0x43971002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'SB700 USB OHCI0 Controller' > class = serial bus > subclass = USB > ohci1@pci0:0:18:1: class=0x0c0310 card=0x50041458 chip=0x43981002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'SB700 USB OHCI1 Controller' > class = serial bus > subclass = USB > ehci0@pci0:0:18:2: class=0x0c0320 card=0x50041458 chip=0x43961002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'SB700 USB EHCI Controller' > class = serial bus > subclass = USB > ohci2@pci0:0:19:0: class=0x0c0310 card=0x50041458 chip=0x43971002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'SB700 USB OHCI0 Controller' > class = serial bus > subclass = USB > ohci3@pci0:0:19:1: class=0x0c0310 card=0x50041458 chip=0x43981002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'SB700 USB OHCI1 Controller' > class = serial bus > subclass = USB > ehci1@pci0:0:19:2: class=0x0c0320 card=0x50041458 chip=0x43961002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'SB700 USB EHCI Controller' > class = serial bus > subclass = USB > none0@pci0:0:20:0: class=0x0c0500 card=0x43851458 chip=0x43851002 > rev=0x3a hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'ATI SMBus (ATI RD600/RS600)' > class = serial bus > subclass = SMBus > atapci1@pci0:0:20:1: class=0x01018a card=0x50021458 chip=0x439c1002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'PATA 133 Controller (SB7xx)' > class = mass storage > subclass = ATA > hdac1@pci0:0:20:2: class=0x040300 card=0xa0021458 chip=0x43831002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'IXP SB600 High Definition Audio Controller' > class = multimedia > subclass = HDA > isab0@pci0:0:20:3: class=0x060100 card=0x43831002 chip=0x439d1002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'SB700 LPC host controller' > class = bridge > subclass = PCI-ISA > pcib3@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 > rev=0x00 hdr=0x01 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'IXP SB600 PCI to PCI Bridge' > class = bridge > subclass = PCI-PCI > ohci4@pci0:0:20:5: class=0x0c0310 card=0x50041458 chip=0x43991002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'SB700 USB OHCI2 Controller' > class = serial bus > subclass = USB > hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 > rev=0x00 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = 'Athlon64/Opteron/Sempron (K8 Family) HyperTransport > Technology Configuration' > class = bridge > subclass = HOST-PCI > hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 > rev=0x00 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = 'Athlon64/Opteron/Sempron (K8 Family) Address Map' > class = bridge > subclass = HOST-PCI > hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 > rev=0x00 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = 'Athlon64/Opteron/Sempron (K8 Family) DRAM Controller' > class = bridge > subclass = HOST-PCI > hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 > rev=0x00 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = 'Athlon64/Opteron/Sempron (K8 Family) Miscellaneous Control' > class = bridge > subclass = HOST-PCI > vgapci0@pci0:1:5:0: class=0x030000 card=0xd0001458 chip=0x96101002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'Radeon HD 3200 Integrated Graphics Processor (780G)' > class = display > subclass = VGA > hdac0@pci0:1:5:1: class=0x040300 card=0x960f1002 chip=0x960f1002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > class = multimedia > subclass = HDA > re0@pci0:2:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x02 > hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111)' > class = network > subclass = ethernet > fwohci0@pci0:3:14:0: class=0x0c0010 card=0x10001458 chip=0x8024104c > rev=0x00 hdr=0x00 > vendor = 'Texas Instruments (TI)' > device = 'TSB43AB23 1394a-2000 OHCI PHY/link-layer Controller' > class = serial bus > subclass = FireWire > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From alex-goncharov at comcast.net Tue Aug 25 20:39:37 2009 From: alex-goncharov at comcast.net (Alex Goncharov) Date: Tue Aug 25 20:39:43 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <4A944370.2000306@gmail.com> (message from Ivan Radovanovic on Tue, 25 Aug 2009 22:02:56 +0200) References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <4A94325D.6070201@FreeBSD.org> <4A9436A7.2020108@gmail.com> <4A94385A.1000405@FreeBSD.org> <4A943C18.2050103@gmail.com> <4A943D06.405@FreeBSD.org> <4A944370.2000306@gmail.com> Message-ID: ,--- You/Ivan (Tue, 25 Aug 2009 22:02:56 +0200) ----* | > Feel free to take a crack at this and send the results to the list for | > review. Improving the documentation is always a worthy goal. | > | I would do that for sure if everyone thinks this ps behavior is | something that should be kept at current state even if it could be made | better `---------------------------------------------------* Don't know how you are going to find about "everyone", but I, for one, think that modifying the established tool's behavior in the proposed manner is an utterly bad idea. Use shell aliases, functions and scripts wrapped around the primary tool to get the behavior you like -- let others stick with their established habits and wrappers. Improving the documentation would be good, OTOH. Thanks, -- Alex -- alex-goncharov@comcast.net -- From jhb at freebsd.org Tue Aug 25 20:48:55 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Aug 25 20:49:02 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <4A944370.2000306@gmail.com> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <4A943D06.405@FreeBSD.org> <4A944370.2000306@gmail.com> Message-ID: <200908251647.36679.jhb@freebsd.org> On Tuesday 25 August 2009 4:02:56 pm Ivan Radovanovic wrote: > Doug Barton napisa: > > Ivan Radovanovic wrote: > > > >> I totally disagree with you - being against change means that you > >> believe it is done the best way it could be done. > >> > > This argument is so non-sequitur that I'm tempted not to respond, but > > no, that's not what I'm saying at all. What I'm saying is that there > > are valid reasons to leave the defaults as they are, AND if you don't > > like the defaults there are easy ways to manipulate that in your own > > environment. > > > You wrote : > > Longer version, I don't see anything wrong with the defaults the way > that they are, and the fact that there is a teeny-tiny learning curve > for people who need to see the full output isn't really an issue that > deserves the time already spent on it. Bruce pointed out in the PR > that most users would be surprised if 'ps -ax | grep foo' suddenly > sprouted a lot more stuff that 'ps -ax' didn't have, and I agree. As a > matter of personal preference I find the current defaults to be just > lovely, and occasionally use -w or -ww if I need to see more. If you > want the default to be something different, that's what aliases are for. > > So, valid arguments against change should be: > 1. users will be surprised if ps starts displaying more stuff no matter if that stuff is correct and less stuff (current state) is incorrect > 2. your personal preference is that current defaults are lovely POLA -- John Baldwin From rick-freebsd2008 at kiwi-computer.com Tue Aug 25 20:51:46 2009 From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty) Date: Tue Aug 25 20:51:53 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <200908251609.09302.j.mckeown@ru.ac.za> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <20090825134447.GM2829@hoeg.nl> <200908251609.09302.j.mckeown@ru.ac.za> Message-ID: <20090825205143.GA46753@keira.kiwi-computer.com> On Tue, Aug 25, 2009 at 04:09:09PM +0200, Jonathan McKeown wrote: > > I usually want to see ps(1) output in easily-read columns. Without width > limits, this can't be guaranteed. > > I would strongly object to the complete removal of any option to limit the > output width of ps(1) and make it easily human-readable. > > I'm also astonished at the suggestion that not using -ww is ``a mistake''. I > very seldom need to see the whole commandline for every process. Then you must not use Java much. I almost always need the -ww option. I'm fine with the default being "fit into my terminal width", but I'd be for one option to specify limited width and another option (-w) to specify "as wide as possible". -- Rick C. Petty From thierry.herbelot at free.fr Tue Aug 25 19:46:21 2009 From: thierry.herbelot at free.fr (Thierry Herbelot) Date: Tue Aug 25 21:02:50 2009 Subject: GA-MA780G-UD3H motherboard In-Reply-To: <11167f520908251134u7454267fl7a4e1e4657405a6f@mail.gmail.com> References: <4A9412ED.6080309@freebsd.org> <11167f520908251134u7454267fl7a4e1e4657405a6f@mail.gmail.com> Message-ID: <200908252127.48214.thierry.herbelot@free.fr> Le Tuesday 25 August 2009, Sam Fourman Jr. a ?crit : > > Meanwhile, if you interested in any information about this motherboard - > > data dumps, outputs from tools, etc - please let me know, I will try my > > best to provide that. > > it would be interesting to see a dmesg as a starting point. > here you are ;-) I have plugged a PCI sound board in the machine, but it does seem to be detected (there could be some issue with PCI bus enumeration : I also include a pciconf log) TfH > > Sam Fourman Jr. > _______________________________________________ > 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" Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-STABLE #12: Mon Jul 6 09:37:34 CEST 2009 XXX@YYY:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (3106.64-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f TSC: P-state invariant Cores per package: 2 usable memory = 4008947712 (3823 MB) avail memory = 3836862464 (3659 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bfce0000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xee00-0xeeff mem 0xd0000000-0xdfffffff,0xfdfe0000-0xfdfeffff,0xfde00000-0xfdefffff irq 18 at device 5.0 on pci1 hdac0: mem 0xfdffc000-0xfdffffff irq 19 at device 5.1 on pci1 hdac0: HDA Driver Revision: 20090329_0131 hdac0: [ITHREAD] pcib2: irq 18 at device 10.0 on pci0 pci2: on pcib2 re0: port 0xde00-0xdeff mem 0xfdaff000-0xfdafffff,0xfdae0000-0xfdaeffff irq 18 at device 0.0 on pci2 re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1f:d0:56:75:23 re0: [FILTER] atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 6 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ata6: on atapci0 ata6: [ITHREAD] ata7: on atapci0 ata7: [ITHREAD] ohci0: mem 0xfe02e000-0xfe02efff irq 16 at device 18.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xfe02d000-0xfe02dfff irq 16 at device 18.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xfe02c000-0xfe02c0ff irq 17 at device 18.2 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 3 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 6 ports with 6 removable, self powered ohci2: mem 0xfe02b000-0xfe02bfff irq 18 at device 19.0 on pci0 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: on ohci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 3 ports with 3 removable, self powered ohci3: mem 0xfe02a000-0xfe02afff irq 18 at device 19.1 on pci0 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: SMM does not respond, resetting usb4: on ohci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 3 ports with 3 removable, self powered ehci1: mem 0xfe029000-0xfe0290ff irq 19 at device 19.2 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb5: EHCI version 1.0 usb5: companion controllers, 3 ports each: usb3 usb4 usb5: on ehci1 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 6 ports with 6 removable, self powered pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] hdac1: mem 0xfe024000-0xfe027fff irq 16 at device 20.2 on pci0 hdac1: HDA Driver Revision: 20090329_0131 hdac1: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pci3: on pcib3 fwohci0: mem 0xfdcff000-0xfdcff7ff,0xfdcf8000-0xfdcfbfff irq 22 at device 14.0 on pci3 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:70:c0:59:00:00:1f:d0 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:70:c0:00:1f:d0 fwe0: Ethernet address: 02:70:c0:00:1f:d0 fwip0: on firewire0 fwip0: Firewire address: 00:70:c0:59:00:00:1f:d0 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xb6e80000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode ohci4: mem 0xfe028000-0xfe028fff irq 18 at device 20.5 on pci0 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb6: OHCI version 1.0, legacy support usb6: SMM does not respond, resetting usb6: on ohci4 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered amdtemp0: on hostb4 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio2: configured irq 5 not in bitmap of probed irqs 0 sio2: port may not be enabled sio3: configured irq 9 not in bitmap of probed irqs 0 sio3: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ad4: 238474MB at ata2-master SATA150 ZFS filesystem version 13 ZFS storage pool version 13 ad6: 238475MB at ata3-master SATA150 ad8: 238475MB at ata4-master SATA150 acd0: DVDR at ata7-master SATA150 hdac0: HDA Codec #0: ATI RS690/780 HDMI pcm0: at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: Realtek ALC885 pcm1: at cad 0 nid 1 on hdac1 pcm2: at cad 0 nid 1 on hdac1 pcm3: at cad 0 nid 1 on hdac1 GEOM_LABEL: Label for provider ad4s1a is ufsid/4895a4a721182022. GEOM_LABEL: Label for provider ad4s1d is ufsid/4895a4b3b6d4e02e. GEOM_LABEL: Label for provider ad4s1e is ufsid/4895a4b54799f68b. GEOM_LABEL: Label for provider ad4s1f is ufsid/4895a4b724bcb48f. GEOM_LABEL: Label for provider ad4s2a is ufsid/49185b60bbfa4d50. GEOM_LABEL: Label for provider ad6s1 is ext2fs//. GEOM_LABEL: Label for provider ad6s2 is ext2fs//1. GEOM_LABEL: Label for provider ad8s1a is ufsid/4895a498589c3d5f. GEOM_LABEL: Label for provider ad8s1d is ufsid/4895a48d5fd2f14b. GEOM_LABEL: Label for provider ad8s1e is ufsid/4895a48489eb6120. GEOM_LABEL: Label for provider ad8s1f is ufsid/4895a48a019d7151. GEOM_LABEL: Label for provider ad8s2a is ufsid/4729b57b020c7526. GEOM_LABEL: Label for provider ad8s2d is ufsid/4729b587458f5554. GEOM_LABEL: Label for provider ad8s2e is ufsid/4729b58af29c6330. SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s2a GEOM_LABEL: Label ufsid/49185b60bbfa4d50 removed. machine# pciconf -lv hostb0@pci0:0:0:0: class=0x060000 card=0x96001022 chip=0x96001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x96021022 chip=0x96021022 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices (AMD)' class = bridge subclass = PCI-PCI pcib2@pci0:0:10:0: class=0x060400 card=0x96001022 chip=0x96091022 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices (AMD)' class = bridge subclass = PCI-PCI atapci0@pci0:0:17:0: class=0x010601 card=0xb0021458 chip=0x43911002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 SATA Controller [AHCI mode]' class = mass storage subclass = SATA ohci0@pci0:0:18:0: class=0x0c0310 card=0x50041458 chip=0x43971002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB OHCI0 Controller' class = serial bus subclass = USB ohci1@pci0:0:18:1: class=0x0c0310 card=0x50041458 chip=0x43981002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB OHCI1 Controller' class = serial bus subclass = USB ehci0@pci0:0:18:2: class=0x0c0320 card=0x50041458 chip=0x43961002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB EHCI Controller' class = serial bus subclass = USB ohci2@pci0:0:19:0: class=0x0c0310 card=0x50041458 chip=0x43971002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB OHCI0 Controller' class = serial bus subclass = USB ohci3@pci0:0:19:1: class=0x0c0310 card=0x50041458 chip=0x43981002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB OHCI1 Controller' class = serial bus subclass = USB ehci1@pci0:0:19:2: class=0x0c0320 card=0x50041458 chip=0x43961002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB EHCI Controller' class = serial bus subclass = USB none0@pci0:0:20:0: class=0x0c0500 card=0x43851458 chip=0x43851002 rev=0x3a hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI SMBus (ATI RD600/RS600)' class = serial bus subclass = SMBus atapci1@pci0:0:20:1: class=0x01018a card=0x50021458 chip=0x439c1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'PATA 133 Controller (SB7xx)' class = mass storage subclass = ATA hdac1@pci0:0:20:2: class=0x040300 card=0xa0021458 chip=0x43831002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'IXP SB600 High Definition Audio Controller' class = multimedia subclass = HDA isab0@pci0:0:20:3: class=0x060100 card=0x43831002 chip=0x439d1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 LPC host controller' class = bridge subclass = PCI-ISA pcib3@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'IXP SB600 PCI to PCI Bridge' class = bridge subclass = PCI-PCI ohci4@pci0:0:20:5: class=0x0c0310 card=0x50041458 chip=0x43991002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB OHCI2 Controller' class = serial bus subclass = USB hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) Address Map' class = bridge subclass = HOST-PCI hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) DRAM Controller' class = bridge subclass = HOST-PCI hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon64/Opteron/Sempron (K8 Family) Miscellaneous Control' class = bridge subclass = HOST-PCI vgapci0@pci0:1:5:0: class=0x030000 card=0xd0001458 chip=0x96101002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'Radeon HD 3200 Integrated Graphics Processor (780G)' class = display subclass = VGA hdac0@pci0:1:5:1: class=0x040300 card=0x960f1002 chip=0x960f1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' class = multimedia subclass = HDA re0@pci0:2:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111)' class = network subclass = ethernet fwohci0@pci0:3:14:0: class=0x0c0010 card=0x10001458 chip=0x8024104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'TSB43AB23 1394a-2000 OHCI PHY/link-layer Controller' class = serial bus subclass = FireWire From thierry at herbelot.com Tue Aug 25 20:31:19 2009 From: thierry at herbelot.com (Thierry Herbelot) Date: Tue Aug 25 21:16:13 2009 Subject: GA-MA780G-UD3H motherboard In-Reply-To: <1251230025.45706.280.camel@balrog.2hip.net> References: <4A9412ED.6080309@freebsd.org> <200908252127.48214.thierry.herbelot@free.fr> <1251230025.45706.280.camel@balrog.2hip.net> Message-ID: <200908252214.22667.thierry@herbelot.com> Le Tuesday 25 August 2009, Robert Noland a ?crit : > On Tue, 2009-08-25 at 21:27 +0200, Thierry Herbelot wrote: > > Le Tuesday 25 August 2009, Sam Fourman Jr. a ?crit : > > > > Meanwhile, if you interested in any information about this > > > > motherboard - data dumps, outputs from tools, etc - please let me > > > > know, I will try my best to provide that. > > > > > > it would be interesting to see a dmesg as a starting point. > > > > here you are ;-) > > > > I have plugged a PCI sound board in the machine, but it does seem to be > > detected (there could be some issue with PCI bus enumeration : I also > > include a pciconf log) > > I'm curious why you would plug in a pci sound card? You already have > both a standard hda codec as well as the hda codec for the hdmi port of > the video. If you are discovering that it isn't working... set Initially, this was the issue, before other people sent various howtos around the probe of the hdmi hda port (which by the way sounds *much* better than my previous cmi board). Afterwards, the PCI board remained in the machine (leftover from a previous box), but it is still *not* seen by the PCI enumeration (I'm a bit too lazy to find another spare PCI board and plug it in see what happens : is it also ignored by the BIOS/ACPI/whatever and/or the kernel ?). It seems that it is not either detected by a Linux kernel. TfH > hw.snd.default_unit=1 which is typcially your normal analog audio port. > The hdmi port on radeon chips tends to be enumerated before the normal > system codecs, so people tend to think that sound isn't working. > > robert. > From rivanr at gmail.com Tue Aug 25 21:24:06 2009 From: rivanr at gmail.com (Ivan Radovanovic) Date: Tue Aug 25 21:24:12 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <4A94325D.6070201@FreeBSD.org> <4A9436A7.2020108@gmail.com> <4A94385A.1000405@FreeBSD.org> <4A943C18.2050103@gmail.com> <4A943D06.405@FreeBSD.org> <4A944370.2000306@gmail.com> Message-ID: <4A945672.6010901@gmail.com> Alex Goncharov napisa: > ,--- You/Ivan (Tue, 25 Aug 2009 22:02:56 +0200) ----* > | > Feel free to take a crack at this and send the results to the list for > | > review. Improving the documentation is always a worthy goal. > | > > | I would do that for sure if everyone thinks this ps behavior is > | something that should be kept at current state even if it could be made > | better > `---------------------------------------------------* > > Don't know how you are going to find about "everyone", but I, for one, > think that modifying the established tool's behavior in the proposed > manner is an utterly bad idea. > > Use shell aliases, functions and scripts wrapped around the primary > tool to get the behavior you like -- let others stick with their > established habits and wrappers. > > Improving the documentation would be good, OTOH. > > Thanks, > > -- Alex -- alex-goncharov@comcast.net -- > I guess voting is going against me, so I would probably need to update that documentation :-) Please understand that my idea is to make tool behave as expected from its description - for example ls also formats its output according to terminal, but when you redirect it then it doesn't care about terminal (try "ls" and "ls | less"), that is what in the first place made me think that ps would behave in the same way (and btw, I still think that all non-interactive tools behave that way). And I also think that if we can make learning FreeBSD even little less difficult then we should do that. My point is if you are making tool for listing processes what you want is to LIST process (first, and most important), and later (if at all) to make that pretty formatted, after all it is unix philosophy to have small programs that do exactly one thing and that do it right - I think that philosophy is broken (because of historical reasons) with current implementation of ps On the other hand fixing ps's behavior in the proposed manner will for sure brake some scripts that depend on it, but if scripts depend on formatting behavior then those scripts are used only to display some information on the terminal and they would be easily spotted and corrected (are there scripts like that in the system - can someone point out and say "Hey XXX will be broken, and that will further brake YYY and so on"? Because I am beginning to think that maybe there is far less things depending on this behavior than expected... ) Ivan P.S. I am giving up of trying to explain my reasoning any more, I think I gave enough reasons for everyone to understand my motivation (although of course everyone has the right not to agree with me). I didn't want to offend anyone in this short discussion and if someone feels that way then I am truly sorry. Any pointers on how to update manual page for ps would be greatly appreciated, as well as some mail agreeing with my standpoint :-) From rnoland at FreeBSD.org Tue Aug 25 21:28:23 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Aug 25 21:28:35 2009 Subject: GA-MA780G-UD3H motherboard In-Reply-To: <200908252214.22667.thierry@herbelot.com> References: <4A9412ED.6080309@freebsd.org> <200908252127.48214.thierry.herbelot@free.fr> <1251230025.45706.280.camel@balrog.2hip.net> <200908252214.22667.thierry@herbelot.com> Message-ID: <1251235695.45706.375.camel@balrog.2hip.net> On Tue, 2009-08-25 at 22:14 +0200, Thierry Herbelot wrote: > Le Tuesday 25 August 2009, Robert Noland a ?crit : > > On Tue, 2009-08-25 at 21:27 +0200, Thierry Herbelot wrote: > > > Le Tuesday 25 August 2009, Sam Fourman Jr. a ?crit : > > > > > Meanwhile, if you interested in any information about this > > > > > motherboard - data dumps, outputs from tools, etc - please let me > > > > > know, I will try my best to provide that. > > > > > > > > it would be interesting to see a dmesg as a starting point. > > > > > > here you are ;-) > > > > > > I have plugged a PCI sound board in the machine, but it does seem to be > > > detected (there could be some issue with PCI bus enumeration : I also > > > include a pciconf log) > > > > I'm curious why you would plug in a pci sound card? You already have > > both a standard hda codec as well as the hda codec for the hdmi port of > > the video. If you are discovering that it isn't working... set > > Initially, this was the issue, before other people sent various howtos around > the probe of the hdmi hda port (which by the way sounds *much* better than my > previous cmi board). > > Afterwards, the PCI board remained in the machine (leftover from a previous > box), but it is still *not* seen by the PCI enumeration (I'm a bit too lazy > to find another spare PCI board and plug it in see what happens : is it also > ignored by the BIOS/ACPI/whatever and/or the kernel ?). > > It seems that it is not either detected by a Linux kernel. Perhaps it isn't seated properly? Or possibly a different slot might help. robert. > TfH > > > hw.snd.default_unit=1 which is typcially your normal analog audio port. > > The hdmi port on radeon chips tends to be enumerated before the normal > > system codecs, so people tend to think that sound isn't working. > > > > robert. > > -- Robert Noland FreeBSD From sfourman at gmail.com Tue Aug 25 21:59:20 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Tue Aug 25 21:59:32 2009 Subject: GA-MA780G-UD3H motherboard In-Reply-To: <4A9412ED.6080309@freebsd.org> References: <4A9412ED.6080309@freebsd.org> Message-ID: <11167f520908251459r7477fac3kdf3ff6e603a313dd@mail.gmail.com> On Tue, Aug 25, 2009 at 11:35 AM, Andriy Gapon wrote: > > I have become to own Gigabyte GA-MA780G-UD3H motherboard: > http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ClassValue=Motherboard&ProductID=3004&ProductName=GA-MA780G-UD3H > It is based on AMD 780G + SB700. > BTW, CPU I am using is Athlon II X2 250. are you using a i386 or AMD64 kernel? maybe I am blind but I didnt see it in your dmesg Sam Fourman Jr. From bernt at bah.homeip.net Tue Aug 25 22:06:15 2009 From: bernt at bah.homeip.net (Bernt Hansson) Date: Tue Aug 25 22:08:50 2009 Subject: GA-MA780G-UD3H motherboard In-Reply-To: <4A9412ED.6080309@freebsd.org> References: <4A9412ED.6080309@freebsd.org> Message-ID: <4A945DC1.8070202@bah.homeip.net> Andriy Gapon said the following on 2009-08-25 18:35: > I have become to own Gigabyte GA-MA780G-UD3H motherboard: > http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ClassValue=Motherboard&ProductID=3004&ProductName=GA-MA780G-UD3H > It is based on AMD 780G + SB700. > BTW, CPU I am using is Athlon II X2 250. > > Sorry for the broadcast announcement, but this is my first AMD-based system in > many years, so I eagerly started exploring it and hacking for it. > > For this reason please expect a number of questions from me as well as some > reports and hopefully code related to this motherboard. I am going to post them as > follow-ups to this email. > > Meanwhile, if you interested in any information about this motherboard - data > dumps, outputs from tools, etc - please let me know, I will try my best to provide > that. > It would be interesting to know if you can have usb devices connected and detected during boot. With SB600 you can not. From kindman at amc-os.com Tue Aug 25 22:27:58 2009 From: kindman at amc-os.com (Aurélien Méré) Date: Tue Aug 25 22:28:05 2009 Subject: AMD SB700 SMBus controller driver References: <4A9412ED.6080309@freebsd.org> <4A94242B.7090806@freebsd.org> Message-ID: <604B96C6CF22447EACE5BD9719DDE1F5@kindman> Could you please forward me the patch to make it work in polling mode ? I'd like to test it as I've been trying to make intpm work with a SB400 (which should be quite the same as yours) but system hangs when I try to force polling mode (didn't have the specs nor all the differences you just presented). And btw, I didn't find any implementation using interrupt neither but I'm ready to test your updated version. Thanks, Aurélien ----- Original Message ----- From: "Andriy Gapon" To: ; Sent: Tuesday, August 25, 2009 7:49 PM Subject: AMD SB700 SMBus controller driver > > According to SB700 specifications its SMBus controller is very similar to > one in > PIIX4. > The differences that I see so far: > > 1. Interrupt Line/Interrupt Pin PCI configuration registers (0x3c, 0x3d) > do not > specify interrupt number that the controller could use: >> This register specifies which interrupt pin the device issue >> This module does not generate interrupt but contains the >> actual interrupt controller. This register is hardcoded to 0. > > 2. I2CbusConfig register (0xd2) uses bit #1 to indicate whether SMI or > regular > interrupt is used in interrupt mode; PIIX4 uses bit 3. > > I couldn't get our intpm driver to work with this hardware by simply > adding PCI id > and tweaking 0xd2 bits meaning. > > I could get it to work by forcing polling mode. It appears that Linux > driver for > this HW always uses polling mode, and OpenBSD and NetBSD drivers would use > it with > this HW too. > > I am still trying to get interrupt mode to work. > I set 0xd2 to enable regular interrupt generation (it is set to SMI after > boot). > SB700 specifications say at one place that SMB interrupt is connected to > INTIN20 > pin of IO-APIC in APIC mode. I tried setting up IRQ20 in the driver but no > interrupts are generated. And there are no stray interrupts either. > So I am not sure - either this HW doesn't generate normal interrupts at > all, or > they to a different pin, or additional setup is required, or I am doing > something > wrong. > > Anyway, I plan to produce an updated version of intpm driver with > possibility of > forced or auto-detected polling mode and support for PCI id of SB700 SMBus > controller and its peculiarities. > > -- > Andriy Gapon > _______________________________________________ > 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 Tue Aug 25 22:57:46 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 25 22:57:53 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <4A944370.2000306@gmail.com> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <4A94325D.6070201@FreeBSD.org> <4A9436A7.2020108@gmail.com> <4A94385A.1000405@FreeBSD.org> <4A943C18.2050103@gmail.com> <4A943D06.405@FreeBSD.org> <4A944370.2000306@gmail.com> Message-ID: <4A946C68.40302@elischer.org> Ivan Radovanovic wrote: > Doug Barton napisa: >> Ivan Radovanovic wrote: >> >>> I totally disagree with you - being against change means that you >>> believe it is done the best way it could be done. >>> >> This argument is so non-sequitur that I'm tempted not to respond, but >> no, that's not what I'm saying at all. What I'm saying is that there >> are valid reasons to leave the defaults as they are, AND if you don't >> like the defaults there are easy ways to manipulate that in your own >> environment. >> > > I would do that for sure if everyone thinks this ps behavior is > something that should be kept at current state even if it could be made > better -w was added to show more information, and -ww for "all" information. I find no problem understanding this and see no reason to change it. "blue please" p.s. -ww can get "big" > > Ivan > _______________________________________________ > 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 thierry at herbelot.com Wed Aug 26 04:11:08 2009 From: thierry at herbelot.com (Thierry Herbelot) Date: Wed Aug 26 05:01:47 2009 Subject: GA-MA780G-UD3H motherboard In-Reply-To: <4A945DC1.8070202@bah.homeip.net> References: <4A9412ED.6080309@freebsd.org> <4A945DC1.8070202@bah.homeip.net> Message-ID: <200908260610.45849.thierry@herbelot.com> Le Tuesday 25 August 2009, Bernt Hansson a ?crit : > Andriy Gapon said the following on 2009-08-25 18:35: > > I have become to own Gigabyte GA-MA780G-UD3H motherboard: > > http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ClassV > >alue=Motherboard&ProductID=3004&ProductName=GA-MA780G-UD3H It is based on > > AMD 780G + SB700. > > BTW, CPU I am using is Athlon II X2 250. > > > > Sorry for the broadcast announcement, but this is my first AMD-based > > system in many years, so I eagerly started exploring it and hacking for > > it. > > > > For this reason please expect a number of questions from me as well as > > some reports and hopefully code related to this motherboard. I am going > > to post them as follow-ups to this email. > > > > Meanwhile, if you interested in any information about this motherboard - > > data dumps, outputs from tools, etc - please let me know, I will try my > > best to provide that. > > It would be interesting to know if you can have usb devices connected > and detected during boot. With SB600 you can not. This maybe the explanation why I have to re-plug the USB mouse each time the machine is restarted ;-) (with an SB700) TfH From gad at FreeBSD.org Wed Aug 26 05:26:45 2009 From: gad at FreeBSD.org (Garance A Drosehn) Date: Wed Aug 26 05:26:52 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <4A94325D.6070201@FreeBSD.org> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <4A94325D.6070201@FreeBSD.org> Message-ID: At 11:50 AM -0700 8/25/09, Doug Barton wrote: >Brian Somers wrote: >> I recently closed bin/137647 and had second thoughts after Ivan (the >> originator) challenged my reason for closing it. >> >> The suggestion is that ps's -w switch is a strange artifact that can >> be safely deprecated. ps goes to great lengths to implement width >> limitations, and any time I've seen people not using -ww has either >> been a mistake or doesn't matter. Using 'cut -c1-N' is also a great >> way of limiting widths if people really want that... >> >> I'd like to propose changing ps so that width limits are removed and >> '-w' is deprecated - ignored for now with a note in the man page >> saying that it will be removed in a future release. >> >> Does anyone have any objections to doing this? I don't propose >> merging this back into stable/8. > >Short version, yes, I object to changing the defaults. Speaking as someone who has worked on 'ps' in the past, I recommend that you go slow in making arbitrary changes. 'ps' is already a minefield of craziness between various versions of unix, and adding this new variant will just make matters worse. You certainly can not go back to older releases and change the formatting there, so all programmers who write for a variety of machines/platforms will just end up with one extra way for things to break. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From j.mckeown at ru.ac.za Wed Aug 26 07:06:31 2009 From: j.mckeown at ru.ac.za (Jonathan McKeown) Date: Wed Aug 26 07:06:38 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <20090825205143.GA46753@keira.kiwi-computer.com> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <200908251609.09302.j.mckeown@ru.ac.za> <20090825205143.GA46753@keira.kiwi-computer.com> Message-ID: <200908260906.21411.j.mckeown@ru.ac.za> On Tuesday 25 August 2009 22:51:43 Rick C. Petty wrote: > On Tue, Aug 25, 2009 at 04:09:09PM +0200, Jonathan McKeown wrote: > > I usually want to see ps(1) output in easily-read columns. Without width > > limits, this can't be guaranteed. > > > > I would strongly object to the complete removal of any option to limit > > the output width of ps(1) and make it easily human-readable. > > > > I'm also astonished at the suggestion that not using -ww is ``a > > mistake''. I very seldom need to see the whole commandline for every > > process. > > Then you must not use Java much. I almost always need the -ww option. > I'm fine with the default being "fit into my terminal width", but I'd be > for one option to specify limited width and another option (-w) to > specify "as wide as possible". As it happens, you're right: I don't use Java at all. Neither do I object (much) to a change in the default behaviour such that wide output is the norm and restricted-width an option. In the original message, Brian Somers wrote: > The suggestion is that ps's -w switch is a strange artifact that can > be safely deprecated. ?ps goes to great lengths to implement width > limitations, and any time I've seen people not using -ww has either > been a mistake or doesn't matter. ?Using 'cut -c1-N' is also a great > way of limiting widths if people really want that... > > I'd like to propose changing ps so that width limits are removed and > '-w' is deprecated - ignored for now with a note in the man page > saying that it will be removed in a future release. The suggestion seems to be to remove the width-limiting code altogether, and make people who want width-restricted output (for example to keep it in columns which are easily scanned by eye) pipe the output through another command. That I do object to. From bruce at cran.org.uk Wed Aug 26 07:59:33 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Wed Aug 26 07:59:40 2009 Subject: Partial kvm dumps In-Reply-To: <86ws4tejt5.fsf@kopusha.onet> References: <86ws4tejt5.fsf@kopusha.onet> Message-ID: <20090826084300.484c4b6e@gluon.draftnet> On Mon, 24 Aug 2009 10:45:58 +0300 Mikolaj Golub wrote: > http://code.google.com/p/trociny/downloads/list > > I would like to hear what other people think about this. It looks > very useful for me. At least as a first step it would be nice to > extend KVM to work with partial dumps so the users could try this and > see if it turned out to be useful. Having recently been debugging core dump support in the base system utilities I spotted what looks like a bug in your code: the 'execfile' parameter to kvm_open or kvm_openfiles should be NULL if you want to use the kernel from the running system; some people may not be running a kernel from "/boot/kernel/kernel" by default. -- Bruce From avg at freebsd.org Wed Aug 26 08:53:42 2009 From: avg at freebsd.org (Andriy Gapon) Date: Wed Aug 26 08:53:49 2009 Subject: GA-MA780G-UD3H motherboard In-Reply-To: <11167f520908251134u7454267fl7a4e1e4657405a6f@mail.gmail.com> References: <4A9412ED.6080309@freebsd.org> <11167f520908251134u7454267fl7a4e1e4657405a6f@mail.gmail.com> Message-ID: <4A94F811.8020705@freebsd.org> on 25/08/2009 21:34 Sam Fourman Jr. said the following: >> Meanwhile, if you interested in any information about this motherboard - data >> dumps, outputs from tools, etc - please let me know, I will try my best to provide >> that. > > it would be interesting to see a dmesg as a starting point. Please see http://people.freebsd.org/~avg/ga-ma780g-ud3h/ Replying to the other email - I use amd64 arch. -- Andriy Gapon From avg at freebsd.org Wed Aug 26 09:00:51 2009 From: avg at freebsd.org (Andriy Gapon) Date: Wed Aug 26 09:01:04 2009 Subject: AMD SB700 SMBus controller driver In-Reply-To: <604B96C6CF22447EACE5BD9719DDE1F5@kindman> References: <4A9412ED.6080309@freebsd.org> <4A94242B.7090806@freebsd.org> <604B96C6CF22447EACE5BD9719DDE1F5@kindman> Message-ID: <4A94F9BD.70907@freebsd.org> on 26/08/2009 01:27 said the following: > Could you please forward me the patch to make it work in polling mode ? I'd > like to test it as I've been trying to make intpm work with a SB400 (which > should be quite the same as yours) but system hangs when I try to force > polling mode (didn't have the specs nor all the differences you just > presented). And btw, I didn't find any implementation using interrupt > neither but I'm ready to test your updated version. [what charset/encoding was your email?] Please see: http://people.freebsd.org/~avg/ga-ma780g-ud3h/intpm.diff The patch is work-in-progress and is not clean for this reason (style violations, experimental hacks) What the patch does: 1. redefine PCI_INTR_SMB_IRQ9 to 2 (bit 1) 2. disable writing to PCIR_INTLINE 3. add PCI id of my hardware 4. attempt to use IRQ mode with interrupt 20 - doesn't work 5. force polling mode - seems to work -- Andriy Gapon From ivan.anyukov at googlemail.com Wed Aug 26 12:00:53 2009 From: ivan.anyukov at googlemail.com (ivan anyukov) Date: Wed Aug 26 12:04:07 2009 Subject: NMI running X with dual-monitor Message-ID: <962bea8e0908260431j7f683cf4tcb3806cbcb723ae7@mail.gmail.com> Hi guys, I'm running 7.2-STABLE on a Thinkpad T60. When connecting a second monitor to my docking station sometimes my FreeBSD freezes. kgdb on the vmcore-file says "non-maskable interrupt trap" Some details: X.Org 1.5.3 using the radeon-Driver I think the problem appears when moving xterms from the first to the second monitor (or back). The mouse cursor looks _very_ strange then and after some minutes the whole system freezes. Does anyone know about the problem? Is it a hardware-failure for sure? Thanks a lot! From bertwiley at gmail.com Wed Aug 26 13:56:53 2009 From: bertwiley at gmail.com (bert wiley) Date: Wed Aug 26 13:57:00 2009 Subject: Need some help understanding a jail system call. Message-ID: <9527461a0908260656w570f6cdha72e92b267e5354f@mail.gmail.com> Hello I found this code under a project called jailNG which has some system calls for doing jail stuff. Im still new to freebsd and im stumped on what this code is actually doing. In the source from the project there are few function calls that look like it creates and access the jail layer. Here is an example #define JAIL_CREATE 1 #define JAIL_DESTROY 2 #define JAIL_JOIN 3 extern char *environ[]; static void usage(void) { fprintf(stderr, "usage:\n"); fprintf(stderr, " jailctl create [jailname]\n"); fprintf(stderr, " jailctl destroy [jailname]\n"); fprintf(stderr, " jailctl join [jailname] [-c chrootpath] [path] " "[cmd] [args...]\n"); exit(-1); } static int jail_create(int argc, char *argv[]) { int error; if (argc < 2) usage(); error = syscall(375, JAIL_CREATE, argv[1]); if (error) perror("jailconf().create"); return (error); } No where in the code do i ever see any access to the jail.h type systems calls, so does the syscall(375, JAIL_CREATE, argv[1]); actually access the jail subsystem and create a jail? Here is the link i used to find this code http://www.watson.org/~robert/freebsd/jailng/ Any help on this question is appreciated thanks. From des at des.no Wed Aug 26 14:21:01 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Aug 26 14:21:08 2009 Subject: Deprecating ps(1)s -w switch References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <20090825134447.GM2829@hoeg.nl> <200908251609.09302.j.mckeown@ru.ac.za> <4A9407D3.60006@freebsd.org> Message-ID: <86hbvu64hg.fsf@ds4.des.no> Tim Kientzle writes: > The difference between "ps", "ps -w", and "ps -ww" is pretty > significant for Java, in particular. Java command lines > are typically enormous (thank you, CLASSPATH) which makes > "ps -ww" often more annoying than it's worth. Java command lines aren't necessarily enormous. If they are, it is because whoever invoked Java didn't know that it respects the CLASSPATH environment variable, and that setting -classpath on the command line f*s up the user's preferences (e.g. the user may want to replace a particular set of classes with an alternative implementation). DES -- Dag-Erling Sm?rgrav - des@des.no From des at des.no Wed Aug 26 14:23:16 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Aug 26 14:23:23 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <4A9436A7.2020108@gmail.com> (Ivan Radovanovic's message of "Tue, 25 Aug 2009 21:08:23 +0200") References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <4A94325D.6070201@FreeBSD.org> <4A9436A7.2020108@gmail.com> Message-ID: <86d46i64dq.fsf@ds4.des.no> Ivan Radovanovic writes: > I think software should evolve to be better rather then to stick with > something done the wrong way, even that has been done maybe 30 years > ago - that is why behavior should be changed. It is never too late to > do the right thing ;-) Are you also going to rewrite 30 years' worth of scripts that expect ps(1) to have a -w option which behaves in a particular manner? DES -- Dag-Erling Sm?rgrav - des@des.no From des at des.no Wed Aug 26 14:34:11 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Aug 26 14:34:25 2009 Subject: Need some help understanding a jail system call. In-Reply-To: <9527461a0908260656w570f6cdha72e92b267e5354f@mail.gmail.com> (bert wiley's message of "Wed, 26 Aug 2009 09:56:50 -0400") References: <9527461a0908260656w570f6cdha72e92b267e5354f@mail.gmail.com> Message-ID: <868wh663vi.fsf@ds4.des.no> bert wiley writes: > No where in the code do i ever see any access to the jail.h type systems > calls Because at that stage in the development process, the system calls in belong to the old implementation. > so does the syscall(375, JAIL_CREATE, argv[1]); actually access the > jail subsystem and create a jail? It calls the new system call, which at that stage hasn't been added to libc yet, because it would conflict with the existing system calls. > Here is the link i used to find this code > http://www.watson.org/~robert/freebsd/jailng/ You realize that this is eight years old, right? And that the jail infrastructure has been extensively modified since then, and is currently being rewritten again? DES -- Dag-Erling Sm?rgrav - des@des.no From avg at icyb.net.ua Wed Aug 26 14:44:08 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Aug 26 14:44:15 2009 Subject: enable ECC in OS code? Message-ID: <4A954A35.4030207@icyb.net.ua> Here is a question that I am afraid I know an answer for. I have some ECC capable hardware: 1) Athlon II with embedded memory controller that can do ECC 2) DRAM modules with ECC Assuming that ECC data lanes are connected between the two on motherboard, and given that BIOS doesn't perform any ECC setup (nor there is any option to control that) - would it be possible to turn on ECC from OS code? Or is it too late in the game already? -- Andriy Gapon From alex-goncharov at comcast.net Wed Aug 26 16:24:12 2009 From: alex-goncharov at comcast.net (Alex Goncharov) Date: Wed Aug 26 16:24:19 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <86hbvu64hg.fsf@ds4.des.no> (message from Dag-Erling Smørgrav on Wed, 26 Aug 2009 16:20:59 +0200) References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <20090825134447.GM2829@hoeg.nl> <200908251609.09302.j.mckeown@ru.ac.za> <4A9407D3.60006@freebsd.org> <86hbvu64hg.fsf@ds4.des.no> Message-ID: ,--- You/Dag-Erling (Wed, 26 Aug 2009 16:20:59 +0200) ----* | Tim Kientzle writes: | > The difference between "ps", "ps -w", and "ps -ww" is pretty | > significant for Java, in particular. Java command lines | > are typically enormous (thank you, CLASSPATH) which makes | > "ps -ww" often more annoying than it's worth. | | Java command lines aren't necessarily enormous. If they are, it is | because whoever invoked Java didn't know that it respects the CLASSPATH | environment variable, and that setting -classpath on the command line | f*s up the user's preferences (e.g. the user may want to replace a | particular set of classes with an alternative implementation). Using either the `-classpath' option to `java' or `CLASSPATH' environment variable is a pretty obsolete practice (whoever does either these days, should stop and re-think, IMHO.) The deficiency of the above, in either variation, is the need to list every `jar' file used, which gets ugly with more than a few files. A persons who keeps up with modern Java will call it with one or several of the options: -Djava.ext.dirs -Djava.library.path -Djava.endorsed.dirs Java Virtual Machine will internally list the files in each of the directories (specified on the command line or default ones), saving a user the effort to mention them explicitly in `CLASSPATH'. This cuts on the length of the command line dramatically, but still `java' processes' command lines are typically enormously long: even the lists of the directories, with their absolute paths are significant; on top of it, `java' is usually invoked with a gazillion of options modifying JVM's runtime behaviour. It's a fact of life that for real-life applications, `java' command lines are *long* -- you can't change that by moving from `-classpath' to `CLASSPATH'. (This said, I am not in favor of modifying `ps' in the manner proposed, as my previous message indicated.) -- Alex -- alex-goncharov@comcast.net -- From linda.messerschmidt at gmail.com Wed Aug 26 19:03:15 2009 From: linda.messerschmidt at gmail.com (Linda Messerschmidt) Date: Wed Aug 26 19:03:22 2009 Subject: Intermittent system hangs on 7.2-RELEASE-p1 Message-ID: <237c27100908261203g7e771400o2d9603220d1f1e0b@mail.gmail.com> I'm trying to troubleshoot an intermittent Apache performance problem, and I've narrowed it down using to what appears to be a brief whole-system hang that last from 0.5 - 3 seconds. They occur every few minutes. I took the rather extreme step of doing "ktrace -t cnisuwt -i -d -p 1" and then I waited for the hang. This is what I got: 54937 httpd 1251302859.375313 CALL shutdown(0x3,) 54937 httpd 1251302859.375333 RET shutdown 0 54937 httpd 1251302859.375348 CALL select(0x4,0xbfbfe92c,0,0,0xbfbfe9ac) 54937 httpd 1251302859.375363 CSW stop kernel 54937 httpd 1251302859.376402 CSW resume kernel 54937 httpd 1251302859.376439 RET select 1 54937 httpd 1251302859.376453 CALL read(0x3,0xbfbfe9b4,0x200) 54937 httpd 1251302859.376470 GIO fd 3 read 0 bytes 54937 httpd 1251302859.376482 RET read 0 54937 httpd 1251302859.376495 CALL close(0x3) 54937 httpd 1251302859.376511 RET close 0 54937 httpd 1251302859.376525 CALL sigaction(SIGUSR1,0xbfbfebb0,0xbfbfeb98) 54937 httpd 1251302859.376538 RET sigaction 0 54937 httpd 1251302859.376552 CALL munmap(0x282ff000,0x11) 54937 httpd 1251302859.376607 RET munmap 0 54937 httpd 1251302859.376633 CALL accept(0x11,0xbfbfebf0,0xbfbfec10) 54937 httpd 1251302859.376649 CSW stop kernel 796 svscan 1251302859.481064 CSW resume kernel 54937 httpd 1251302859.489374 CSW resume kernel 54937 httpd 1251302859.489391 STRU struct sockaddr { AF_INET, 172.17.0.143:61610 } 98229 httpd 1251302859.601850 CSW resume kernel 46517 httpd 1251302859.601900 CSW resume kernel 98202 httpd 1251302859.611661 CSW resume kernel 837 nrpe2 1251302859.622681 CSW resume kernel 54454 httpd 1251302859.655422 CSW resume kernel 54454 httpd 1251302859.655443 STRU struct sockaddr { AF_INET, 172.17.0.131:59011 } 7182 httpd 1251302859.722381 CSW resume kernel 98178 httpd 1251302859.722438 CSW resume kernel 858 gmond 1251302859.794996 CSW resume kernel 858 gmond 1251302859.794998 GIO fd 5 wrote 0 bytes 770 ntpd 1251302860.076501 CSW resume kernel 98346 httpd 1251302860.086261 CSW resume kernel 65277 httpd 1251302860.086300 CSW resume kernel 98514 httpd 1251302860.106849 CSW resume kernel 7191 httpd 1251302860.106894 CSW resume kernel 796 svscan 1251302861.403335 RET nanosleep 0 796 svscan 1251302861.403370 CALL wait4(0xffffffff,0xbfbfee18,WNOHANG,0) 796 svscan 1251302861.403405 RET wait4 0 54454 httpd 1251302861.403481 RET accept 3 98229 httpd 1251302861.403532 RET select 0 796 svscan 1251302861.403553 CALL stat(0x804a3bb,0xbfbfed6c) 858 gmond 1251302861.403601 GIO fd 5 read 20 bytes 54454 httpd 1251302861.403619 CSW stop user 46517 httpd 1251302861.403647 RET select 0 858 gmond 1251302861.403674 RET kevent 1 858 gmond 1251302861.403710 CALL socket(PF_INET,SOCK_DGRAM,IPPROTO_IP) 98202 httpd 1251302861.403714 RET select 0 858 gmond 1251302861.403752 RET socket 9 837 nrpe2 1251302861.403756 RET select 0 There is a gap between 1251302860.106894 and 1251302861.403335 of over one second, and the "effective gap" starts around 1251302859.376649 and thus lasts for about two seconds. This machine runs Apache and during this sample it was being hit every 0.1 seconds with a test request for a simple static file (in addition to production traffic). It is a 2-processor machine that is 85-95% idle; there's nothing in userspace that runs that long without yielding. According to systat, it handles 5000+ syscalls every second. But according to ktrace, nothing happens at all during the hang. This matches user experience. (The static file request, which usually completes in <0.01s suddenly takes 2 seconds as observed from the remote machine issuing the requests.) Here's the relevant snip from the httpd process handling that static file at the time of the hang: 54937 httpd 1251302859.376633 CALL accept(0x11,0xbfbfebf0,0xbfbfec10) 54937 httpd 1251302859.376649 CSW stop kernel 54937 httpd 1251302859.489374 CSW resume kernel 54937 httpd 1251302859.489391 STRU struct sockaddr { AF_INET, 172.17.0.143:61610 } 54937 httpd 1251302861.403862 RET accept 3 It's stuck in accept, but does *not* get context-switched away from during the delay. (The earlier context switch corresponds to the 0.1 seconds between requests; there is an Apache instance configured to handle just the test requests with one child process; that process has nothing else to do or block on.) I'll include some other processes below. I think it's weird that all these processes get context-switched-into before/during the hang, and I wonder if it's a clue. The kernel is obviously still running, since it wakes these processes up, but nothing is happening. That and the fact that it happens on multiple machines (though we've only tested this one) leads me away from suspecting the hardware. Are we out of a kernel resource or is something getting garbage collected / stuck / temporarily locked inside the kernel somewhere? This is a production server, so our debugging options are very limited. We also can't recreate the problem on a test server. So KTR and/or the kernel debugger are probably out. There's nothing in syslog or dmesg or on the console. Could anyone suggest away to gather more information about this, given our constraints? More samples: Here's an Apache "parent" process; its hang is in select(). The immediately following select() call demonstrates what the middle one should also have done: 98178 httpd 1251302858.703733 CALL select(0,0,0,0,0xbfbfed3c) 98178 httpd 1251302858.703789 CSW stop kernel 98178 httpd 1251302859.722438 CSW resume kernel 98178 httpd 1251302861.403908 RET select 0 98178 httpd 1251302861.404118 CALL gettimeofday(0xbfbfec58,0) 98178 httpd 1251302861.404453 RET gettimeofday 0 98178 httpd 1251302861.404478 CALL wait4(0xffffffff,0xbfbfed80,WNOHANG,0) 98178 httpd 1251302861.405288 RET wait4 0 98178 httpd 1251302861.405576 CALL select(0,0,0,0,0xbfbfed3c) 98178 httpd 1251302861.405603 CSW stop kernel 98178 httpd 1251302862.417549 CSW resume kernel 98178 httpd 1251302862.417581 RET select 0 Same behavior from nrpe2: 837 nrpe2 1251302859.107587 CALL select(0x5,0xbfbfe16c,0,0xbfbfe16c,0xbfbfe20c) 837 nrpe2 1251302859.107607 CSW stop kernel 837 nrpe2 1251302859.622681 CSW resume kernel 837 nrpe2 1251302861.403756 RET select 0 Here's a production Apache child process. Also hangs in accept(), but the delay does happen inside the context switch: 55062 httpd 1251302859.044661 CALL accept(0x12,0xbfbfec00,0xbfbfec20) 55062 httpd 1251302859.044681 CSW stop kernel 55062 httpd 1251302861.792647 CSW resume kernel 55062 httpd 1251302861.792662 STRU struct sockaddr { AF_INET, 172.17.0.131:59093 } 55062 httpd 1251302861.792880 RET accept 3 gmond hangs in kevent() on some kind of I/O: 858 gmond 1251302859.233805 CALL kevent(0x5,0,0,0x2833d960,0x2,0xbfbfe344) 858 gmond 1251302859.233820 CSW stop kernel 858 gmond 1251302859.794996 CSW resume kernel 858 gmond 1251302859.794998 GIO fd 5 wrote 0 bytes 858 gmond 1251302861.403601 GIO fd 5 read 20 bytes 858 gmond 1251302861.403674 RET kevent 1 svscan hangs in nanosleep(). It sleeps for 5 seconds, not 7. 796 svscan 1251302854.429189 CALL lseek(0x3,0,SEEK_SET,0) 796 svscan 1251302854.429269 RET lseek 0 796 svscan 1251302854.429346 CALL close(0x3) 796 svscan 1251302854.429709 RET close 0 796 svscan 1251302854.429894 CALL nanosleep(0xbfbfee18,0xbfbfee10) 796 svscan 1251302854.430033 CSW stop kernel 796 svscan 1251302859.481064 CSW resume kernel 796 svscan 1251302861.403335 RET nanosleep 0 796 svscan 1251302861.403370 CALL wait4(0xffffffff,0xbfbfee18,WNOHANG,0) 796 svscan 1251302861.403405 RET wait4 0 796 svscan 1251302861.403553 CALL stat(0x804a3bb,0xbfbfed6c) 796 svscan 1251302861.404027 NAMI "." ntpd shows the same behavior, except it wakes up by alarm. Again, the normal behavior (no gap between CSW and RET) is shown right after: 770 ntpd 1251302859.078305 CALL select(0x3b,0xbfbfed7c,0,0,0) 770 ntpd 1251302859.078312 CSW stop kernel 770 ntpd 1251302860.076501 CSW resume kernel 770 ntpd 1251302861.403952 RET select -1 errno 4 Interrupted system call 770 ntpd 1251302861.404168 PSIG SIGALRM caught handler=0x806ad90 mask=0x0 code=0x0 770 ntpd 1251302861.404191 CALL sigreturn(0xbfbfea50) 770 ntpd 1251302861.404553 RET sigreturn JUSTRETURN 770 ntpd 1251302861.404890 CALL select(0x3b,0xbfbfed7c,0,0,0) 770 ntpd 1251302861.405955 CSW stop kernel 770 ntpd 1251302862.077114 CSW resume kernel 770 ntpd 1251302862.077171 RET select -1 errno 4 Interrupted system call There were other processes running, mainly more httpds, but I went through each and every one of them and I don't see anything that I haven't already shown an example of. Thanks very much for any advice! From jhb at freebsd.org Wed Aug 26 20:43:54 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Aug 26 20:44:01 2009 Subject: Intermittent system hangs on 7.2-RELEASE-p1 In-Reply-To: <237c27100908261203g7e771400o2d9603220d1f1e0b@mail.gmail.com> References: <237c27100908261203g7e771400o2d9603220d1f1e0b@mail.gmail.com> Message-ID: <200908261642.59419.jhb@freebsd.org> On Wednesday 26 August 2009 3:03:13 pm Linda Messerschmidt wrote: > I'm trying to troubleshoot an intermittent Apache performance problem, > and I've narrowed it down using to what appears to be a brief > whole-system hang that last from 0.5 - 3 seconds. They occur every > few minutes. One thing to note is that ktrace only logs voluntary context switches (i.e. call to tsleep or waiting on a condition variable). It specifically does not log preemptions or blocking on a mutex, so in theory if your machine was livelocked temporarily that might explain this. -- John Baldwin From remodeler at alentogroup.org Wed Aug 26 21:16:59 2009 From: remodeler at alentogroup.org (remodeler) Date: Wed Aug 26 21:17:07 2009 Subject: MBR hack for serial console Message-ID: <20090826204513.M28384@alentogroup.org> I am hoping for input on a patch I want to apply to the MBR of a FreeBSD 8-BETA3 AMD64 server. I need a serial console on this server. The ASUS motherboard (amibios) has PCI and PCI-e expansion slots, and a Moschip MCS9820 UART (serial board) is installed at pci0:3:5:0. The amibios can be configured to do the plug-and-play enumeration, or this feature turned off, but there is no way to assign a particular i/o port to a PCI device in the BIOS, and I cannot get source for the BIOS to change this behavior. The serial board has a single Base Address Register at 10h in its pci configuration space. Whether the PCI bus is probed by the BIOS or FreeBSD, the UART BAR is assigned the i386 I/O port address of 0xe800. It must be COM1-COM4 (i.e. 0x3F8) to work in the boot sequence. I need access to the serial console before loader. I do not expect the hardware configuration to change so a hack is ok. My plan is to patch the MBR to override the serial card's BAR with 0x3F8. My reasoning is that the CPU is still in Real mode (allowing direct hardware access) until loader executes, and the serial console would work for the boot0 and boot2 calls to the terminal. I have experimented with using pciconf to change the BAR from a command line; curiously the command: pciconf -w pci0:3:5:0 16 1016 loads 0x3F9 into the serial card's PCI configuration space instead of 0x3F8, and I don't understand why. I've worked up this patch and hope someone can tell me why this would or wouldn't work: /usr/src/sys/boot/i386/mbr/mbr.s 41,57d40 < # Patch to reconfigure PCI UART's Base Address to COM1 < # I count 40 bytes in opcode < # < startcon: .set PCIADD_PORT,0xcf8 # Load pci config port addy < .set PCIDATA_PORT,0xcfc # Load pci data port addy < .set PCIADD,0x8003e810 # Load pci register identifier < .set PCIDATA,0x3f8 # Load pci register data < < pushad # save double registers < mov %ax,$PCIADD # put pci reg to access in ax < mov %dx,$PCIADD_PORT # put pci config port in dx < out %dx,%ax # send to cpu i/o space < mov %ax,$PCIDATA # put pci data in ax < mov %dx,$PCIDATA_PORT # put pci data port in dx < out %dx,%ax # send data to cpu i/o space < popad # pop saved registers < # 166,171c149,151 < # < # Instruction messages reduced to numbers, saves 60 bytes < # < msg_pt: .asciz "1" # "Invalid partition table" < msg_rd: .asciz "2" # "Error loading operating system" < msg_os: .asciz "3" # "Missing operating system" --- > msg_pt: .asciz "Invalid partition table" > msg_rd: .asciz "Error loading operating system" > msg_os: .asciz "Missing operating system" Thanks in advance for any help. I am not an assembly coder so am really uncertain about my patch. From neldredge at math.ucsd.edu Wed Aug 26 21:36:58 2009 From: neldredge at math.ucsd.edu (Nate Eldredge) Date: Wed Aug 26 21:37:14 2009 Subject: Intermittent system hangs on 7.2-RELEASE-p1 In-Reply-To: <237c27100908261203g7e771400o2d9603220d1f1e0b@mail.gmail.com> References: <237c27100908261203g7e771400o2d9603220d1f1e0b@mail.gmail.com> Message-ID: On Wed, 26 Aug 2009, Linda Messerschmidt wrote: > I'm trying to troubleshoot an intermittent Apache performance problem, > and I've narrowed it down using to what appears to be a brief > whole-system hang that last from 0.5 - 3 seconds. They occur every > few minutes. One thought would be to use "ps" to try to determine which process, if any, is charged with CPU time during the hang. If you could afford a little downtime, it would be worth seeing if the hang occurs in single-user mode (perhaps with a simple program that loops calling gettimeofday() and warns when the time between successive iterations is large). I once had a problem like this that I eventually traced to a power management problem. (Specifically, the machine had a modem, and would hang for a few seconds whenever the line would ring. It was apparently related to the Wake-On-Ring feature.) If I remember correctly, disabling ACPI made it go away. So that might be something to try, if rebooting is an option. What are the similarities and differences in hardware and software among the affected machines (you mentioned there were several)? -- Nate Eldredge neldredge@math.ucsd.edu From steve at Watt.COM Wed Aug 26 23:20:44 2009 From: steve at Watt.COM (Steve Watt) Date: Wed Aug 26 23:20:54 2009 Subject: enable ECC in OS code? In-Reply-To: <4A954A35.4030207@icyb.net.ua> Message-ID: <200908262253.n7QMrauP063683@wattres.watt.com> In <4A954A35.4030207@icyb.net.ua>, avg@icyb.net.ua wrote: > >Here is a question that I am afraid I know an answer for. >I have some ECC capable hardware: >1) Athlon II with embedded memory controller that can do ECC >2) DRAM modules with ECC >Assuming that ECC data lanes are connected between the two on motherboard, and >given that BIOS doesn't perform any ECC setup (nor there is any option to control >that) - would it be possible to turn on ECC from OS code? >Or is it too late in the game already? It's about 100 times easier to have the BIOS do this. First off, it's usually quite specific to the chip set exactly how to do it. Next, if ECC wasn't enabled previously, the ECC bytes will all be wrong, which means that you'll have to rewrite all of memory after you've turned it on. Oh, and you have to fetch the code that rewrites the ECC from the memory with incorrect ECC to do that. If the BIOS is broken to the extent that it doesn't enable ECC on a system that it should be available, whine at the vendor. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... From brian at FreeBSD.org Thu Aug 27 07:09:15 2009 From: brian at FreeBSD.org (Brian Somers) Date: Thu Aug 27 07:09:21 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <20090825034054.2d57e733@dev.lan.Awfulhak.org> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> Message-ID: <20090826234009.13b90734@dev.lan.Awfulhak.org> On Tue, 25 Aug 2009 03:40:54 -0700 Brian Somers wrote: > I recently closed bin/137647 and had second thoughts after Ivan (the > originator) challenged my reason for closing it. > > The suggestion is that ps's -w switch is a strange artifact that can > be safely deprecated. ps goes to great lengths to implement width > limitations, and any time I've seen people not using -ww has either > been a mistake or doesn't matter. Using 'cut -c1-N' is also a great > way of limiting widths if people really want that... > > I'd like to propose changing ps so that width limits are removed and > '-w' is deprecated - ignored for now with a note in the man page > saying that it will be removed in a future release. > > Does anyone have any objections to doing this? I don't propose > merging this back into stable/8. To clarify, my proposal is to silently ignore the -w switch (any/all of them) and to remove the code that reads the terminal width and truncates some columns based on the result (or based on "132"). The pros: - ps's code becomes simpler. It was mentioned that the ps code is a minefield. This would remove a few mines. - ps IMHO has no business knowing about terminal widths (and where did the 132 column -w idea come from again?). Some programs such as iostat have similar (but way more broken) behaviour however whilst others such as ls do not. - We remove the sizing bugs (only some columns are truncation victims). The cons: - people with visual expectations would have to learn to use less -S or some similar tool. This breaks POLA. - Scripts may exist that depend on the behaviour without -w. Furthermore having to handle ps from both before and after such a change in one script can be painful. It was also suggested that rather than changing the behaviour of one flavour of ps it would be better to adopt an approach more like linux's or even implementing POSIXs suggestions. AFAIK the linux suggestion has been on the table for more time than I care to remember (wasn't Brett Glass going to provide a patch soon?). Although I haven't read the linux code, I'm pretty sure it's a scary place - perhaps this is the reason that we don't have those patches yet. Unless others have more to say on the subject, I think it's clear that the most popular vote is to do nothing. I think this is a shame as I find the pros more compelling than the cons, and I'm sure there are more than a few supporters out there on hackers@ that will stay silent. -- Brian Somers Don't _EVER_ lose your sense of humour ! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 306 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090827/3754496e/signature.pgp From julian at elischer.org Thu Aug 27 07:18:18 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Aug 27 07:18:26 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <20090826234009.13b90734@dev.lan.Awfulhak.org> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <20090826234009.13b90734@dev.lan.Awfulhak.org> Message-ID: <4A963338.7080908@elischer.org> Brian Somers wrote: > On Tue, 25 Aug 2009 03:40:54 -0700 Brian Somers wrote: >> I recently closed bin/137647 and had second thoughts after Ivan (the >> originator) challenged my reason for closing it. >> >> The suggestion is that ps's -w switch is a strange artifact that can >> be safely deprecated. ps goes to great lengths to implement width >> limitations, and any time I've seen people not using -ww has either >> been a mistake or doesn't matter. Using 'cut -c1-N' is also a great >> way of limiting widths if people really want that... >> >> I'd like to propose changing ps so that width limits are removed and >> '-w' is deprecated - ignored for now with a note in the man page >> saying that it will be removed in a future release. >> >> Does anyone have any objections to doing this? I don't propose >> merging this back into stable/8. > > To clarify, my proposal is to silently ignore the -w switch (any/all of them) > and to remove the code that reads the terminal width and truncates some > columns based on the result (or based on "132"). > > The pros: > > - ps's code becomes simpler. It was mentioned that the ps code is > a minefield. This would remove a few mines. > - ps IMHO has no business knowing about terminal widths (and where > did the 132 column -w idea come from again?). back in the day terminals came in two widths... 80 and 132. the teletype printers were 132 and the few video terminals there were were 80. later some of the video terminals had a wide 132 mode you could switch to. Some programs such > as iostat have similar (but way more broken) behaviour however whilst > others such as ls do not. > - We remove the sizing bugs (only some columns are truncation victims). > > The cons: > > - people with visual expectations would have to learn to use less -S or some > similar tool. This breaks POLA. > - Scripts may exist that depend on the behaviour without -w. Furthermore > having to handle ps from both before and after such a change in one > script can be painful. > > It was also suggested that rather than changing the behaviour of one > flavour of ps it would be better to adopt an approach more like linux's > or even implementing POSIXs suggestions. AFAIK the linux suggestion > has been on the table for more time than I care to remember (wasn't > Brett Glass going to provide a patch soon?). Although I haven't read > the linux code, I'm pretty sure it's a scary place - perhaps this is the > reason that we don't have those patches yet. > > > Unless others have more to say on the subject, I think it's clear that > the most popular vote is to do nothing. I think this is a shame as I > find the pros more compelling than the cons, and I'm sure there are > more than a few supporters out there on hackers@ that will stay > silent. > From des at des.no Thu Aug 27 10:28:32 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Aug 27 10:28:39 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <20090826234009.13b90734@dev.lan.Awfulhak.org> (Brian Somers's message of "Wed, 26 Aug 2009 23:40:09 -0700") References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <20090826234009.13b90734@dev.lan.Awfulhak.org> Message-ID: <86fxbd1rg1.fsf@ds4.des.no> Brian Somers writes: > To clarify, my proposal is to silently ignore the -w switch (any/all of them) > and to remove the code that reads the terminal width and truncates some > columns based on the result (or based on "132"). > > The pros: > > - ps's code becomes simpler. It was mentioned that the ps code is > a minefield. This would remove a few mines. Frankly, the width limiting code is the least of ps's problems. > - ps IMHO has no business knowing about terminal widths (and where > did the 132 column -w idea come from again?). Some programs such > as iostat have similar (but way more broken) behaviour however whilst > others such as ls do not. Actually, ls does pretty much the same thing (use a different layout when run on a tty), and it's far from the only Unix utility to do so. Usually, the tty layout is "pretty" while the non-tty layout is easier to work with in scripts. > The cons: > [...] > - Scripts may exist that depend on the behaviour without -w. Furthermore > having to handle ps from both before and after such a change in one > script can be painful. Breaking existing scripts would be an *extremely* unwise and unpopular move. The only part of your proposal I support is removing the 132-column limit on 'ps -w' (which I believe would make the output from 'ps -w' identical to that from 'ps -ww') DES -- Dag-Erling Sm?rgrav - des@des.no From fullermd at over-yonder.net Thu Aug 27 10:29:13 2009 From: fullermd at over-yonder.net (Matthew D. Fuller) Date: Thu Aug 27 10:29:20 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <20090826234009.13b90734@dev.lan.Awfulhak.org> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <20090826234009.13b90734@dev.lan.Awfulhak.org> Message-ID: <20090827101204.GI10667@over-yonder.net> On Wed, Aug 26, 2009 at 11:40:09PM -0700 I heard the voice of Brian Somers, and lo! it spake thus: > > I think this is a shame as I find the pros more compelling than the > cons, and I'm sure there are more than a few supporters out there on > hackers@ that will stay silent. FWIW, I'm in favor of at least carefully examining whether the cons really disqualify the change. My uses of ps pretty well fall into three categories: 1) The times I use -ww 2) The times it doesn't matter whether I did or not 3) The times I wish I'd used -ww, sometimes way later in the game when a script *DOESN'T* do what it's supposed to because ps isn't actually giving me the command. Thanks, ps. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From rivanr at gmail.com Thu Aug 27 10:36:38 2009 From: rivanr at gmail.com (Ivan Radovanovic) Date: Thu Aug 27 10:36:44 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <86fxbd1rg1.fsf@ds4.des.no> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <20090826234009.13b90734@dev.lan.Awfulhak.org> <86fxbd1rg1.fsf@ds4.des.no> Message-ID: <4A9661AF.3040800@gmail.com> Dag-Erling Sm?rgrav napisa: > Actually, ls does pretty much the same thing (use a different layout > when run on a tty), and it's far from the only Unix utility to do so. > Usually, the tty layout is "pretty" while the non-tty layout is easier > to work with in scripts. > Actually ls doesn't work the same - ls tries to format its output according to terminal but if it can't it won't just chop off any piece of information, and if you pipe ls into other command's input ls behaves as not running on tty - ps behaves in the opposite way in both cases From des at des.no Thu Aug 27 10:45:19 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Aug 27 10:45:25 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <20090827101204.GI10667@over-yonder.net> (Matthew D. Fuller's message of "Thu, 27 Aug 2009 05:12:04 -0500") References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <20090826234009.13b90734@dev.lan.Awfulhak.org> <20090827101204.GI10667@over-yonder.net> Message-ID: <868wh51qo1.fsf@ds4.des.no> "Matthew D. Fuller" writes: > FWIW, I'm in favor of at least carefully examining whether the cons > really disqualify the change. They do. Breaking scripts is not acceptable under any circumstances. DES -- Dag-Erling Sm?rgrav - des@des.no From erich at apsara.com.sg Thu Aug 27 05:35:25 2009 From: erich at apsara.com.sg (Erich Dollansky) Date: Thu Aug 27 11:15:01 2009 Subject: enable ECC in OS code? In-Reply-To: <200908262253.n7QMrauP063683@wattres.watt.com> References: <200908262253.n7QMrauP063683@wattres.watt.com> Message-ID: <200908271130.18073.erich@apsara.com.sg> Hi, On 27 August 2009 am 06:53:36 Steve Watt wrote: > In <4A954A35.4030207@icyb.net.ua>, avg@icyb.net.ua wrote: > >Assuming that ECC data lanes are connected between the two on > > motherboard, and given that BIOS doesn't perform any ECC > > setup (nor there is any option to control that) - would it be > > possible to turn on ECC from OS code? Or is it too late in > > the game already? > > It's about 100 times easier to have the BIOS do this. First > off, it's usually quite specific to the chip set exactly how to how should it be done at OS level at all when the OS is loaded into RAM? I do not thing that normal PC hardware is capable of handling this. Only code running in a ROM can do this. Erich From erich at apsara.com.sg Thu Aug 27 05:35:25 2009 From: erich at apsara.com.sg (Erich Dollansky) Date: Thu Aug 27 11:15:09 2009 Subject: enable ECC in OS code? In-Reply-To: <200908262253.n7QMrauP063683@wattres.watt.com> References: <200908262253.n7QMrauP063683@wattres.watt.com> Message-ID: <200908271130.18073.erich@apsara.com.sg> Hi, On 27 August 2009 am 06:53:36 Steve Watt wrote: > In <4A954A35.4030207@icyb.net.ua>, avg@icyb.net.ua wrote: > >Assuming that ECC data lanes are connected between the two on > > motherboard, and given that BIOS doesn't perform any ECC > > setup (nor there is any option to control that) - would it be > > possible to turn on ECC from OS code? Or is it too late in > > the game already? > > It's about 100 times easier to have the BIOS do this. First > off, it's usually quite specific to the chip set exactly how to how should it be done at OS level at all when the OS is loaded into RAM? I do not thing that normal PC hardware is capable of handling this. Only code running in a ROM can do this. Erich From joerg at britannica.bec.de Thu Aug 27 11:42:15 2009 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Thu Aug 27 11:42:28 2009 Subject: enable ECC in OS code? In-Reply-To: <200908271130.18073.erich@apsara.com.sg> References: <200908262253.n7QMrauP063683@wattres.watt.com> <200908271130.18073.erich@apsara.com.sg> Message-ID: <20090827112229.GB14987@britannica.bec.de> On Thu, Aug 27, 2009 at 11:30:15AM +0800, Erich Dollansky wrote: > how should it be done at OS level at all when the OS is loaded > into RAM? Copy the kernel to the video RAM, jump to it, enable ECC, copy back. Joerg From joerg at britannica.bec.de Thu Aug 27 11:42:15 2009 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Thu Aug 27 11:42:29 2009 Subject: enable ECC in OS code? In-Reply-To: <200908271130.18073.erich@apsara.com.sg> References: <200908262253.n7QMrauP063683@wattres.watt.com> <200908271130.18073.erich@apsara.com.sg> Message-ID: <20090827112229.GB14987@britannica.bec.de> On Thu, Aug 27, 2009 at 11:30:15AM +0800, Erich Dollansky wrote: > how should it be done at OS level at all when the OS is loaded > into RAM? Copy the kernel to the video RAM, jump to it, enable ECC, copy back. Joerg From des at des.no Thu Aug 27 12:28:33 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Aug 27 12:28:39 2009 Subject: enable ECC in OS code? In-Reply-To: <20090827112229.GB14987@britannica.bec.de> (Joerg Sonnenberger's message of "Thu, 27 Aug 2009 13:22:29 +0200") References: <200908262253.n7QMrauP063683@wattres.watt.com> <200908271130.18073.erich@apsara.com.sg> <20090827112229.GB14987@britannica.bec.de> Message-ID: <864ort1lw0.fsf@ds4.des.no> Joerg Sonnenberger writes: > Erich Dollansky writes: > > how should it be done at OS level at all when the OS is loaded > > into RAM? > Copy the kernel to the video RAM, jump to it, enable ECC, copy back. Not just the kernel - you have to copy all the memory that is currently in use, including interrupt tables, the BIOS configuration space, shadow copies of various ROMs... The CPU will probably not look too kindly on having interrupt descriptors, segment descriptors, page tables etc. in memory accessed through the I/O controller instead of the memory controller. The machine might not even have video RAM! On systems that support ECC, I suspect that the BIOS enables it at the same time as it configures the memory controller, which is one of the very first things it does - literally within a few dozen (or perhaps a few hundred) instructions from CPU reset - using only CPU registers, ROM code, and configuration variables loaded from NVRAM. DES -- Dag-Erling Sm?rgrav - des@des.no From jhb at freebsd.org Thu Aug 27 14:16:44 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Aug 27 14:16:51 2009 Subject: MBR hack for serial console In-Reply-To: <20090826204513.M28384@alentogroup.org> References: <20090826204513.M28384@alentogroup.org> Message-ID: <200908270808.09790.jhb@freebsd.org> On Wednesday 26 August 2009 5:07:16 pm remodeler wrote: > I am hoping for input on a patch I want to apply to the MBR of a FreeBSD > 8-BETA3 AMD64 server. I need a serial console on this server. The ASUS > motherboard (amibios) has PCI and PCI-e expansion slots, and a Moschip MCS9820 > UART (serial board) is installed at pci0:3:5:0. The amibios can be configured > to do the plug-and-play enumeration, or this feature turned off, but there is > no way to assign a particular i/o port to a PCI device in the BIOS, and I > cannot get source for the BIOS to change this behavior. The serial board has a > single Base Address Register at 10h in its pci configuration space. Whether > the PCI bus is probed by the BIOS or FreeBSD, the UART BAR is assigned the > i386 I/O port address of 0xe800. It must be COM1-COM4 (i.e. 0x3F8) to work in > the boot sequence. I need access to the serial console before loader. Hmm, is 60 bytes enough to read the current value of the BAR instead and use that address? Writing 0x3f8 will not work if the BAR has a length > 8, though it sounds like that isn't the case. Still, if the device is behind a PCI-PCI bridge (which it probably is if it is on bus 3) you have the problem that 0x3f8 is probably not in the IO range decoded by the parent bridge. Given that I really think reading the current value and using that instead of 0x3f8 is probably more reliable. > I do not expect the hardware configuration to change so a hack is ok. My plan > is to patch the MBR to override the serial card's BAR with 0x3F8. My reasoning > is that the CPU is still in Real mode (allowing direct hardware access) until > loader executes, and the serial console would work for the boot0 and boot2 > calls to the terminal. I have experimented with using pciconf to change the > BAR from a command line; curiously the command: > > pciconf -w pci0:3:5:0 16 1016 > > loads 0x3F9 into the serial card's PCI configuration space instead of 0x3F8, > and I don't understand why. I've worked up this patch and hope someone can > tell me why this would or wouldn't work: You would read back 0x3f9 because the lower 3 bits of a BAR are various flags. bit 0 indicates if a BAR is for I/O (1) or memory (0) hence why you read back 0x3f8 | 0x1. -- John Baldwin From steve at Watt.COM Thu Aug 27 17:45:28 2009 From: steve at Watt.COM (Steve Watt) Date: Thu Aug 27 17:45:35 2009 Subject: enable ECC in OS code? In-Reply-To: <200908271130.18073.erich@apsara.com.sg> References: <200908262253.n7QMrauP063683@wattres.watt.com> Message-ID: <200908271745.n7RHjR7J036945@wattres.watt.com> In <200908271130.18073.erich@apsara.com.sg>, erich@apsara.com.sg wrote: >Hi, > >On 27 August 2009 am 06:53:36 Steve Watt wrote: >> In <4A954A35.4030207@icyb.net.ua>, avg@icyb.net.ua wrote: >> >Assuming that ECC data lanes are connected between the two on >> > motherboard, and given that BIOS doesn't perform any ECC >> > setup (nor there is any option to control that) - would it be >> > possible to turn on ECC from OS code? Or is it too late in >> > the game already? >> >> It's about 100 times easier to have the BIOS do this. First >> off, it's usually quite specific to the chip set exactly how to > >how should it be done at OS level at all when the OS is loaded >into RAM? > >I do not thing that normal PC hardware is capable of handling >this. > >Only code running in a ROM can do this. Disable the ECC error reporting and copy memory back to itself? Again, quite controller-specific. That said, the BIOS should do it, and any that doesn't is broken. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... From linda.messerschmidt at gmail.com Thu Aug 27 20:14:40 2009 From: linda.messerschmidt at gmail.com (Linda Messerschmidt) Date: Thu Aug 27 20:14:47 2009 Subject: Intermittent system hangs on 7.2-RELEASE-p1 In-Reply-To: <200908261642.59419.jhb@freebsd.org> References: <237c27100908261203g7e771400o2d9603220d1f1e0b@mail.gmail.com> <200908261642.59419.jhb@freebsd.org> Message-ID: <237c27100908271314v28e6c710s8a278064333d1d20@mail.gmail.com> On Wed, Aug 26, 2009 at 4:42 PM, John Baldwin wrote: > One thing to note is that ktrace only logs voluntary context switches (i.e. > call to tsleep or waiting on a condition variable). It specifically does not > log preemptions or blocking on a mutex, I was not aware, thanks. > so in theory if your machine was > livelocked temporarily that might explain this. How would we determine that? We are now able to reproduce this on a test machine, even after slipping in a 7.2-STABLE kernel with KTR enabled. So we have a lot more options now. Unfortunately, I don't really "get" KTR yet. It looks like it has relevant info, but I was unable to correlate its huge timestamps (e.g. 6795522404430562) to ktrace output times (e.g. 1251387606.225544) showing problem areas. What's my best bet from here? From kostikbel at gmail.com Thu Aug 27 20:20:07 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Aug 27 20:20:19 2009 Subject: Intermittent system hangs on 7.2-RELEASE-p1 In-Reply-To: <237c27100908271314v28e6c710s8a278064333d1d20@mail.gmail.com> References: <237c27100908261203g7e771400o2d9603220d1f1e0b@mail.gmail.com> <200908261642.59419.jhb@freebsd.org> <237c27100908271314v28e6c710s8a278064333d1d20@mail.gmail.com> Message-ID: <20090827202000.GQ9623@deviant.kiev.zoral.com.ua> On Thu, Aug 27, 2009 at 04:14:39PM -0400, Linda Messerschmidt wrote: > On Wed, Aug 26, 2009 at 4:42 PM, John Baldwin wrote: > > One thing to note is that ktrace only logs voluntary context switches (i.e. > > call to tsleep or waiting on a condition variable). It specifically does not > > log preemptions or blocking on a mutex, > > I was not aware, thanks. > > > so in theory if your machine was > > livelocked temporarily that might explain this. > > How would we determine that? > > We are now able to reproduce this on a test machine, even after > slipping in a 7.2-STABLE kernel with KTR enabled. So we have a lot > more options now. > > Unfortunately, I don't really "get" KTR yet. It looks like it has > relevant info, but I was unable to correlate its huge timestamps (e.g. > 6795522404430562) to ktrace output times (e.g. 1251387606.225544) > showing problem areas. > > What's my best bet from here? How much memory is installed ? -------------- 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/20090827/517cf916/attachment.pgp From kientzle at freebsd.org Fri Aug 28 07:33:34 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Fri Aug 28 08:28:13 2009 Subject: Deprecating ps(1)s -w switch In-Reply-To: <20090826234009.13b90734@dev.lan.Awfulhak.org> References: <20090825034054.2d57e733@dev.lan.Awfulhak.org> <20090826234009.13b90734@dev.lan.Awfulhak.org> Message-ID: <4A97368C.9000405@freebsd.org> Brian Somers wrote: > > To clarify, my proposal is to silently ignore the -w switch (any/all of them) > and to remove the code that reads the terminal width and truncates some > columns based on the result (or based on "132"). If you're going to change something that, whether you agree with it or not, a lot of other code depends on, you may as well change the name at the same time and call it "myps". Tim From remodeler at alentogroup.org Fri Aug 28 07:33:56 2009 From: remodeler at alentogroup.org (remodeler) Date: Fri Aug 28 08:28:57 2009 Subject: MBR hack for serial console In-Reply-To: <200908270808.09790.jhb@freebsd.org> References: <20090826204513.M28384@alentogroup.org> <200908270808.09790.jhb@freebsd.org> Message-ID: <20090828033609.M34898@alentogroup.org> This is in response to John Baldwin's response to my question about using a non-legacy IO port for an i386 serial console. I notice that src/sys/boot/i386/boot0/boot0.S uses a call to the PC BIOS int 14h routine to access the serial console, if SIO is defined. I believe SIO is defined if make.conf specifies a port for BOOT_COMCONSOLE_PORT (though I'm probably wrong), in which case the boot0 executable would be made from src/sys/boot/i386/boot0/boot0sio when recompiling the boot blocks with: # cd /sys/boot # make clean # make # make install The 14h pc bios routine is definitely limited to 0x3F8, 0x2F8, 0x3E8, or 0x2E8 because it is called with the DX register set to specify COM1-COM4 (dx set to 0, 1, 2, or 3). boot2 looks like I might be able to specify the 0xe800 address for the serial console. src/sys/boot/i386/boot2/sio.S has this definition: .set SIO_PRT,SIOPRT but I am not sure where SIOPRT is set. I don't see if in any makefile. I would guess it is being set by BOOT_COMCONSOLE_PORT also? > if the device is behind a PCI-PCI bridge (which it probably is > if it is on bus 3) you have the problem that 0x3f8 is probably not > in the IO range decoded by the parent bridge The device is behind a bridge: pcib0 --> pci0 --> pcib3 --> pci3, but AMD doesn't have a data sheet available on the 'net to tell me what IO range is decoded by the parent bridge (750SB southbridge chip). I also notice in the PCI specification this ("I/O Space Address Decoding for Legacy Devices"): A function that supports a PC legacy function (IDE, VGA, etc.) is allowed to claim those addresses associated with the specific function when the I/O Space (see Figure 6-2) [the configuration space's Command Register layout, bit 0] enable bit is set. These addresses are not requested using a Base Address register but are assigned by initialization software. If a device identifies itself as a legacy function (class code), the initialization software grants the device permission to claim the I/O legacy addresses by setting the device?s I/O Space enable bit. > read the current value of the BAR instead and use that address? If I can set the serial console to a non-legacy port in boot2, that would be ideal. I don't think the boot0 routine would cause problems; it is just looking for keystrokes AFAIK. In this approach, I would guess it would make sense to read the value and set SIOPRT to it in boot2? I think from this point on, the serial console calls use sio.S, and these functions (sio_init, etc.) access the hardware directly with assembler out commands rather than using the PC BIOS routines like boot0. Would something as simple as: .set SIO_PRT,0xe800 in src/sys/boot/i386/boot2/sio.S work? If it does, I can develop code to read and set it to the current port instead of hard-coding it. Thanks again for your help. From jhb at freebsd.org Fri Aug 28 13:44:29 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Aug 28 13:44:40 2009 Subject: MBR hack for serial console In-Reply-To: <20090828033609.M34898@alentogroup.org> References: <20090826204513.M28384@alentogroup.org> <200908270808.09790.jhb@freebsd.org> <20090828033609.M34898@alentogroup.org> Message-ID: <200908280832.19782.jhb@freebsd.org> On Thursday 27 August 2009 11:36:09 pm remodeler wrote: > This is in response to John Baldwin's response to my question about using a > non-legacy IO port for an i386 serial console. > > I notice that src/sys/boot/i386/boot0/boot0.S uses a call to the PC BIOS int > 14h routine to access the serial console, if SIO is defined. I believe SIO is > defined if make.conf specifies a port for BOOT_COMCONSOLE_PORT (though I'm > probably wrong), in which case the boot0 executable would be made from > src/sys/boot/i386/boot0/boot0sio when recompiling the boot blocks with: > > # cd /sys/boot > # make clean > # make > # make install > > The 14h pc bios routine is definitely limited to 0x3F8, 0x2F8, 0x3E8, or 0x2E8 > because it is called with the DX register set to specify COM1-COM4 (dx set to > 0, 1, 2, or 3). That's probably true that the BIOS routines likely do not handle a serial port in an add-on card. However, just setting the I/O address to 03xf8 may not make the BIOS routines work either since the BIOS may know that there isn't a COM1 on the motherboard so it may just fail I/O w/o trying. > boot2 looks like I might be able to specify the 0xe800 address for the serial > console. src/sys/boot/i386/boot2/sio.S has this definition: .set > SIO_PRT,SIOPRT but I am not sure where SIOPRT is set. I don't see if in any > makefile. I would guess it is being set by BOOT_COMCONSOLE_PORT also? Correct. It's set via 'CFLAGS' in boot2's Makefile. > > if the device is behind a PCI-PCI bridge (which it probably is > > if it is on bus 3) you have the problem that 0x3f8 is probably not > > in the IO range decoded by the parent bridge > > The device is behind a bridge: pcib0 --> pci0 --> pcib3 --> pci3, but AMD > doesn't have a data sheet available on the 'net to tell me what IO range is > decoded by the parent bridge (750SB southbridge chip). A verbose dmesg will tell you as it isn't a fixed range but it assigned by the BIOS just like a BAR. > I also notice in the PCI specification this ("I/O Space Address Decoding for > Legacy Devices"): > > A function that supports a PC legacy function (IDE, VGA, etc.) is allowed to > claim those addresses associated with the specific function when the I/O Space > (see Figure 6-2) [the configuration space's Command Register layout, bit 0] > enable bit is set. > > These addresses are not requested using a Base Address register but are > assigned by initialization software. If a device identifies itself as a legacy > function (class code), the initialization software grants the device > permission to claim the I/O legacy addresses by setting the device?s I/O Space > enable bit. Note the 'not requested using a BAR' part of the quote. :-/ The way these transactions are handled by PCI-PCI bridges is there is a bit that effectively instructs the bridge to claim legacy I/O or VGA ranges. However, the PCI-ISA/LPC bridge device probably is already setup that way so that I/O accesses to the RTC, keyboard controller, etc. all work. > > read the current value of the BAR instead and use that address? > > If I can set the serial console to a non-legacy port in boot2, that would be > ideal. I don't think the boot0 routine would cause problems; it is just > looking for keystrokes AFAIK. In this approach, I would guess it would make > sense to read the value and set SIOPRT to it in boot2? I think from this point > on, the serial console calls use sio.S, and these functions (sio_init, etc.) > access the hardware directly with assembler out commands rather than using the > PC BIOS routines like boot0. Would something as simple as: > > .set SIO_PRT,0xe800 > > in src/sys/boot/i386/boot2/sio.S work? If it does, I can develop code to read > and set it to the current port instead of hard-coding it. Yes, I would try that. You can also just do 'BOOT_COMCONSOLE_PORT=0xe800' to see if that will work as a test w/o having to modify any of the boot2 code directly. -- John Baldwin From junichi at junichi.org Sun Aug 30 15:40:19 2009 From: junichi at junichi.org (Junichi Satoh) Date: Sun Aug 30 15:40:26 2009 Subject: Frequency and core voltage adjustment for AMD CPUs. Message-ID: <20090831.004015.74756379.junichi@junichi.org> Hello, I did functionality expansion of cpufreq driver for AMD CPUs, "powernow.c" and "hwpstate.c". It can change frequency and core voltage from default in each P-states by definition of device.hints. Patch file against cpufreq driver: http://configure.sh/FreeBSD/cpufreq.html http://configure.sh/FreeBSD/cpufreq-j.html (Japanese) At least, it works well with my FreeBSD box, HP ProLiant ML115 G5. But, I don't know whether it works with other hardwares. Can anyone test this patch? Any comments and suggestions are welcome. - How to change frequency or core voltage. Define difference value from default in /boot/device.hints as follows. hint.{drivername}.0.adjfreq=XXX CPU frequency(MHz) of difference from default in all P-states. hint.{drivername}.0.adjfreqN=XXX CPU frequency(MHz) of difference from default in P-state N. hint.{drivername}.0.adjvcore=XXX CPU core voltage(mV) of difference from default in all P-states. hint.{drivername}.0.adjvcoreN=XXX CPU core voltage(mV) of difference from default in P-state N. *{drivername} is "powernow" or "hwpstate". Frequency and core voltage can be defined by an arbitrary value, but it is adjusted automatically by the nearest value that CPU allows. For example, the driver sets +100MHz if you define "adjfreq=110" when frequency step that specified by CPU is 100MHz. - Example 1 OS : FreeBSD 8.0-BETA2 H/W: HP ProLiant ML115 G5 CPU: Athlon 1640B (2.7GHz) /boot/device.hints: ======================================================================== hint.powernow.0.adjvcore="-200" -> Core voltage is set to -200mV from default in all P-states. hint.powernow.0.adjfreq="-100" -> Frequency is set to -100MHz from default in all P-states. hint.powernow.0.adjfreq0="0 -> Frequency is set to default in P-state0. ======================================================================== dmesg: ======================================================================== Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-BETA2 #56: Sun Aug 23 10:34:37 JST 2009 junichi@shiga.pn.junichi.org:/usr/src/sys/amd64/compile/SHIGA WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor 1640B (2700.02-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x70ff2 Stepping = 2 Features=0x78bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11d real memory = 2147483648 (2048 MB) avail memory = 4105457664 (3915 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fec00000, 1000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x2008-0x200b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 .... cpu0: on acpi0 powernow0: on cpu0 powernow0: P-state0: 2700MHz->2700MHz, 1350mV->1150mV powernow0: P-state1: 2600MHz->2500MHz, 1325mV->1125mV powernow0: P-state2: 2400MHz->2300MHz, 1275mV->1075mV powernow0: P-state3: 2200MHz->2100MHz, 1225mV->1025mV powernow0: P-state4: 2000MHz->1900MHz, 1175mV->975mV powernow0: P-state5: 1800MHz->1700MHz, 1125mV->925mV powernow0: P-state6: 1000MHz->900MHz, 1100mV->900mV ... ======================================================================== Result of "sysctl dev.cpu.0.freq_levels": ======================================================================== dev.cpu.0.freq_levels: 2700/50000 2500/46381 2300/39643 2100/33545 1900/28057 1700/23148 900/12249 ======================================================================== - Example 2 OS: FreeBSD 8.0-BETA3 H/W: HP ProLiant ML115 G5 CPU: Phenom 9850 Black Edition (2.5GHz) /boot/device.hints: ======================================================================== hint.hwpstate.0.adjfreq0="200" -> Frequency is set to +200MHz(over clock) from default in P-state0. hint.hwpstate.0.adjfreq1="-350" -> Frequency is set to -350MHz from default in P-state1. hint.hwpstate.0.adjvcore1="-175" -> Core voltage is set to -175mV from default in P-state1. ======================================================================== dmesg: ======================================================================== Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-BETA3 #0: Mon Aug 24 23:29:36 JST 2009 junichi@shiga.pn.junichi.org:/usr/src/sys/amd64/compile/SHIGA WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Phenom(tm) 9850 Quad-Core Processor (2500.02-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f23 Stepping = 3 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x7ff TSC: P-state invariant real memory = 5100273664 (4864 MB) avail memory = 4105482240 (3915 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fec00000, 1000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x2008-0x200b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 ... cpu0: on acpi0 hwpstate0: P-state0: 2500MHz->2700MHz, 1300mV->1300mV hwpstate0: P-state1: 1250MHz->900MHz, 1050mV->875mV hwpstate0: on cpu0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 ... ======================================================================== Result of "sysctl dev.cpu.0.freq_levels": ======================================================================== dev.cpu.0.freq_levels: 2700/30940 900/1848 ======================================================================== --- Junichi Satoh From brampton+freebsd-hackers at gmail.com Mon Aug 31 10:18:58 2009 From: brampton+freebsd-hackers at gmail.com (Andrew Brampton) Date: Mon Aug 31 10:19:04 2009 Subject: netstat -i Ierrs column, Is it total, or per second? Message-ID: Hi FreeBSD-Hackers, netstat -i will print out statistics for each interface, including input/output packets, input/output bytes, and input/output errors. Now packets and bytes columns seem to be absolute counts, whereas the errors column seems to be a count over the last second. For example, when I am filling a link (and then stop), I get output like so: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ix0 9000 00:1b:21:20:f9:07 12687951213 432913 1 0 0 ix0 9000 00:1b:21:20:f9:07 12691545431 435439 1 0 0 ix0 9000 00:1b:21:20:f9:07 12692054413 434735 1 0 0 ix0 9000 00:1b:21:20:f9:07 12696499228 300785 1 0 0 ix0 9000 00:1b:21:20:f9:07 12696499228 0 1 0 0 As you can see the "Ipkts" value continues to rise, but the "Ierrs" goes up and down, eventually falling to zero. So my question is, should this "Ierrs" count be per second?, if so how can I change this behaviour. I looked at the source code for the driver (ixgbe) and the OS, looking for every reference to ifp->if_ierrors, but I didn't find anything that reset this value over time. I also tried a similar experiment with the e1000 driver but I couldn't get that interface to list any errors. I'm running these tests on FreeBSD 8.0-Beta3, but I observed the same behaviour on FreeBSD 7.2. Thanks Andrew From rwatson at FreeBSD.org Mon Aug 31 10:40:57 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Aug 31 10:41:04 2009 Subject: Need some help understanding a jail system call. In-Reply-To: <868wh663vi.fsf@ds4.des.no> References: <9527461a0908260656w570f6cdha72e92b267e5354f@mail.gmail.com> <868wh663vi.fsf@ds4.des.no> Message-ID: On Wed, 26 Aug 2009, Dag-Erling Sm?rgrav wrote: >> Here is the link i used to find this code >> http://www.watson.org/~robert/freebsd/jailng/ > > You realize that this is eight years old, right? And that the jail > infrastructure has been extensively modified since then, and is currently > being rewritten again? As DES points out, that jail work has been superceded by other, more interesting, work in the base tree. My suggestion would be to read the jail(2) man page, both the current 7.x version, and the forthcoming 8.x version which has been substantially enhanced, and disregard the jailng page. I should more clearly mark it as being of historic interest only. Robert N M Watson Computer Laboratory University of Cambridge From ivoras at freebsd.org Mon Aug 31 11:18:27 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Aug 31 11:18:38 2009 Subject: UFS block writing Message-ID: Does UFS do full-block writes? Always or only in specific circumstances? For example, if a UFS file system is created with the 16/2 block/fragment size, and a small random write (e.g. 512 bytes) comes in the middle of a larger file, will UFS read in the whole 16k block, modify it and write it out? What about fragments? From jhb at freebsd.org Mon Aug 31 12:23:57 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Aug 31 12:24:04 2009 Subject: netstat -i Ierrs column, Is it total, or per second? In-Reply-To: References: Message-ID: <200908310804.27417.jhb@freebsd.org> On Monday 31 August 2009 6:18:56 am Andrew Brampton wrote: > Hi FreeBSD-Hackers, > > netstat -i will print out statistics for each interface, including > input/output packets, input/output bytes, and input/output errors. Now > packets and bytes columns seem to be absolute counts, whereas the > errors column seems to be a count over the last second. For example, > when I am filling a link (and then stop), I get output like so: > > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > ix0 9000 00:1b:21:20:f9:07 12687951213 432913 > 1 0 0 > > ix0 9000 00:1b:21:20:f9:07 12691545431 435439 > 1 0 0 > > ix0 9000 00:1b:21:20:f9:07 12692054413 434735 > 1 0 0 > > ix0 9000 00:1b:21:20:f9:07 12696499228 300785 > 1 0 0 > > ix0 9000 00:1b:21:20:f9:07 12696499228 0 1 > 0 0 > > As you can see the "Ipkts" value continues to rise, but the "Ierrs" > goes up and down, eventually falling to zero. So my question is, > should this "Ierrs" count be per second?, if so how can I change this > behaviour. I looked at the source code for the driver (ixgbe) and the > OS, looking for every reference to ifp->if_ierrors, but I didn't find > anything that reset this value over time. I also tried a similar > experiment with the e1000 driver but I couldn't get that interface to > list any errors. > > I'm running these tests on FreeBSD 8.0-Beta3, but I observed the same > behaviour on FreeBSD 7.2. It should be total and it sounds like a bug in the device driver. It looks like ixgbe_update_stats_counters() overwrites the accumulated value of if_ierrors: /* Rx Errors */ ifp->if_ierrors = total_missed_rx + adapter->stats.crcerrs + adapter->stats.rlec; It also increments if_ierrors in ixgbe_rxeof(). The driver should only do one or the other, but probably not both. -- John Baldwin From brampton+freebsd-hackers at gmail.com Mon Aug 31 19:15:56 2009 From: brampton+freebsd-hackers at gmail.com (Andrew Brampton) Date: Mon Aug 31 19:16:03 2009 Subject: netstat -i Ierrs column, Is it total, or per second? In-Reply-To: <200908310804.27417.jhb@freebsd.org> References: <200908310804.27417.jhb@freebsd.org> Message-ID: 2009/8/31 John Baldwin : > It should be total and it sounds like a bug in the device driver. ?It looks > like ixgbe_update_stats_counters() overwrites the accumulated value of > if_ierrors: > > ? ? ? ?/* Rx Errors */ > ? ? ? ?ifp->if_ierrors = total_missed_rx + adapter->stats.crcerrs + > ? ? ? ? ? ? ? ?adapter->stats.rlec; > > It also increments if_ierrors in ixgbe_rxeof(). ?The driver should only do one > or the other, but probably not both. > > -- > John Baldwin > Thanks for your reply. I had wondered that, but looking at e1000/if_em.c it does a similar thing. However, a quick look at non-intel drivers and it seems others don't. So perhaps this is a problem across the intel drivers? So anyway I spent my afternoon reading the ixgbe spec sheet and creating the attached patch, which hopefully fixes this problem. I will forward this patch to freebsd intel.com unless someone can point me toward the maintainers email address, or should I just create a PR? thanks Andrew -------------- next part -------------- diff -u ixgbe.old/ixgbe.c ixgbe/ixgbe.c --- ixgbe.old/ixgbe.c 2009-08-31 18:15:05.000000000 +0100 +++ ixgbe/ixgbe.c 2009-08-31 19:52:14.000000000 +0100 @@ -3978,7 +3978,6 @@ if (eop) { rxr->fmp->m_pkthdr.rcvif = ifp; - ifp->if_ipackets++; rxr->rx_packets++; /* capture data for AIM */ rxr->bytes += rxr->fmp->m_pkthdr.len; @@ -4000,8 +3999,9 @@ rxr->lmp = NULL; } } else { - ifp->if_ierrors++; discard: + adapter->dropped_pkts++; + /* Reuse loaded DMA map and just update mbuf chain */ if (hlen) { mh = rxr->rx_buffers[i].m_head; @@ -4459,12 +4459,15 @@ u32 missed_rx = 0, bprc, lxon, lxoff, total; adapter->stats.crcerrs += IXGBE_READ_REG(hw, IXGBE_CRCERRS); + adapter->stats.illerrc += IXGBE_READ_REG(hw, IXGBE_ILLERRC); + adapter->stats.errbc += IXGBE_READ_REG(hw, IXGBE_ERRBC); for (int i = 0; i < 8; i++) { int mp; mp = IXGBE_READ_REG(hw, IXGBE_MPC(i)); missed_rx += mp; adapter->stats.mpc[i] += mp; + adapter->stats.mpctotal += mp; adapter->stats.rnbc[i] += IXGBE_READ_REG(hw, IXGBE_RNBC(i)); } @@ -4532,8 +4535,11 @@ ifp->if_collisions = 0; /* Rx Errors */ - ifp->if_ierrors = missed_rx + adapter->stats.crcerrs + - adapter->stats.rlec; + ifp->if_ierrors = adapter->stats.mpctotal + + adapter->stats.crcerrs + + adapter->stats.illerrc + + adapter->stats.errbc + + adapter->stats.rlec; } From jhb at freebsd.org Mon Aug 31 21:49:47 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Aug 31 21:49:55 2009 Subject: netstat -i Ierrs column, Is it total, or per second? In-Reply-To: References: <200908310804.27417.jhb@freebsd.org> Message-ID: <200908311642.50866.jhb@freebsd.org> On Monday 31 August 2009 3:15:53 pm Andrew Brampton wrote: > 2009/8/31 John Baldwin : > > It should be total and it sounds like a bug in the device driver. ?It looks > > like ixgbe_update_stats_counters() overwrites the accumulated value of > > if_ierrors: > > > > ? ? ? ?/* Rx Errors */ > > ? ? ? ?ifp->if_ierrors = total_missed_rx + adapter->stats.crcerrs + > > ? ? ? ? ? ? ? ?adapter->stats.rlec; > > > > It also increments if_ierrors in ixgbe_rxeof(). ?The driver should only do one > > or the other, but probably not both. > > > > -- > > John Baldwin > > > > Thanks for your reply. I had wondered that, but looking at > e1000/if_em.c it does a similar thing. However, a quick look at > non-intel drivers and it seems others don't. So perhaps this is a > problem across the intel drivers? > > So anyway I spent my afternoon reading the ixgbe spec sheet and > creating the attached patch, which hopefully fixes this problem. I > will forward this patch to freebsd intel.com unless someone can > point me toward the maintainers email address, or should I just create > a PR? I cc'd him on my earlier reply (jfv@) so he should have seen your patch already. -- John Baldwin