Re: [acpi-jp 2106] RE: ACPI-CA import/new diff?
It seems Takanori Watanabe wrote: Would you try it? http://people.freebsd.org/~takawata/acpi-20030321.diff http://people.freebsd.org/~takawata/acpica-freebsd-20030321.tar.gz Just did here, ASUS P4S8X board, With the CVS version power off doesnt work, it prints the power system off using ACPI waits a couble seconds, prints that the ACPI poweroff function timed out and reboots :( With the above applied it is even worse, it prints the power system off using ACPI and then hangs the system without powering off :( :( Besides this both seems to work, except they both find dual CPU's which I dont have :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
installworld - /usr/share/info/dir problems
Hello, I'm having diffculties performing an installworld of the newest sources. *** === lib/libcom_err/doc install-info --quiet --defsection=Programming development tools. --defentry=* libcom_err: (com_err).A Common Error Description Library for UNIX. com_err.info /usr/share/info/dir install-info: /usr/share/info/dir: empty file *** Error code 1 *** After some minor investigation I can complete an installworld if I put some junk into the /usr/share/info/dir file. I may have lost the contents of the file because of a power cut the other day, but I can't seem to find a new one in the src-tree, nor anywhere else. Thanks! Best regards, Rasmus Skaarup To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Port breakage (isnan undeclared)
Thus spake Tim Robbins [EMAIL PROTECTED]: On Thu, Mar 20, 2003 at 12:55:22AM -0800, Kris Kennaway wrote: Several ports have become broken recently with the following error: ../../../include/osg/Math:149: `isnan' undeclared (first use this function) http://bento.freebsd.org/errorlogs/i386-5-latest/osg-0.9.3.log http://bento.freebsd.org/errorlogs/i386-5-latest/gnucap-0.31.log http://bento.freebsd.org/errorlogs/i386-5-latest/fractorama-1.6.4.log Can someone please investigate? The prototypes for isnan() c. need to be put back into math.h, and their source files need to be un-deprecated. C99 requires that isnan() be a macro, since it can take arguments of multiple types and C doesn't support templates or overloading. Technically, redundant function and macro implementations can coexist, but that's gross. A better solution may be to define _GLIBCPP_USE_C99 to 1 in libstdc++. Among other things, this tells the C++ library to capture standard C99 macros such as isnan() in a wrapper in the std namespace before undefing them as it does now. The appropriate configure option is --enable-c99, BTW. If a real C++ guru could make sure this doesn't break anything else I would be grateful. What I don't understand is why the libstdc++ all-your-macros-are-belong-to-us magic gets pulled in when you say '#include math.h' instead of cmath. That's going to break programs (such as fractorama) that expect isnan() and friends to be in the global namespace. Again, comments from someone with C++ fu would be appreciated. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: installworld - /usr/share/info/dir problems
On Fri, Mar 21, 2003 at 09:39:44AM +0100, Rasmus Skaarup wrote: Hello, I'm having diffculties performing an installworld of the newest sources. *** === lib/libcom_err/doc install-info --quiet --defsection=Programming development tools. --defentry=* libcom_err: (com_err).A Common Error Description Library for UNIX. com_err.info /usr/share/info/dir install-info: /usr/share/info/dir: empty file *** Error code 1 *** After some minor investigation I can complete an installworld if I put some junk into the /usr/share/info/dir file. I may have lost the contents of the file because of a power cut the other day, but I can't seem to find a new one in the src-tree, nor anywhere else. src/share/info/Makefile installs one if the target doesn't exist. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
ÊËÃÑ° ú¡ÑºÍÔÃÑ¡ àÈÃÉ°¡Ô¨Ð´Õ¢Ö鹨ÃÔ§ ¤ÇÒÁÁÑ蹤§ã¹§Ò¹ÁÕ¨ÃÔ§ËÃ×Í?
ÊÀÒ¾¤ÇÒÁà»ç¹¨ÃÔ§¢Í§§Ò¹»ÃШӤ×ÍäÁèÁÕ¤ÇÒÁÁÑ蹤§ ã¤Ã¡ÅéÒÂ×¹Âѹ áÁéÇèÒ ÊËÃÑ° ú¡ÑºÍÔÃÑ¡ àÈÃÉ°¡Ô¨Ð´Õ¢Ö鹨ÃÔ§ ¤ÇÒÁÁÑ蹤§ã¹§Ò¹ÁÕ¨ÃÔ§ËÃ×Í? - â´ÂÊÀÒÇзÑèÇ仹Ñé¹ §Ò¹»ÃШӨж١¨Ó¡Ñ´´éÇ¢ÑèÇâÁ§·Ó§Ò¹·ÕèÂÒÇ - ·Ñ駹ÕéÂѧ¨Ó¡Ñ´ÃÒÂä´é·ÕèµèÓàÁ×èÍà·Õº¡Ñº¤ÇÒÁ·ØèÁà··ÕèàÃÒãËéá¡è§Ò¹ - ÍÕ¡·Ñ駼ŧҹ¡ç¶Ù¡ÇÔ¹Ô¨©ÑÂâ´Âà¨éÒ¹Ò ËÃ×Íà¨éҢͧ¡Ô¨¡Òà - ·ÕèÊӤѡç¤×Í ¼Å§Ò¹â´¹àºÕ´ºÑ§ËÃ×ÍÅ´¤ÇÒÁÊÓ¤Ñâ´Âà¾×è͹ ÃèÇÁ§Ò¹¼Ùé«Ö觪èÒ§»ÃШºà¨éÒ¹Ò ÍÕ¡à¨éÒ¹Ò¡çÁÑ¡ªÍºàÊÕ´éÇ - ÀÒ¾¤ÇÒÁà»ç¹¨ÃÔ§´Ñ§¡ÅèÒÇÊÃéÒ§¤ÇÒÁà¤ÃÕ´ áÅÐźÅéÒ§ÍÔÊÃÀÒ¾ - ÊÀÒ¾¤ÇÒÁÁÑ蹤§äÁèÁÕ ÁÕà¾Õ§¤ÇÒÁÁÑ蹤§¢Í§ºÃÔÉÑ·áÅкҧ¤¹¶Ù¡ ¤Ñ´àÅ×Í¡ãËéà»ç¹¼ÙéàÊÕÂÊÅÐ㹪ÑèÇâÁ§·ÕèºÃÔÉÑ·ÍÂÙèã¹°Ò¹ÐÂèÓáÂè - ÅͧàÃÔèÁ§Ò¹¾ÔàÈÉà¼×èÍÇèÒÊÑ¡Çѹ¨Ðä´éËÅØ´¾é¹ÊÀÒÇдѧ¡ÅèÒǤ×Í ÁÕÍÔÊÃÀÒ¾·Ò§´éÒ¹ÃÒÂä´é µÅÍ´¨¹¶Ö§ÍÔÊÃÀÒ¾·Ò§àÇÅÒ - ÊÒÁÒöÊÃéÒ§ÃÒÂä´éà¾ÔèÁÍÕ¡à´×͹ÅÐ 10,000-20,000 ºÒ·à»ç¹ ¢Ñé¹µèÓâ´ÂãªéàÇÅÒÊÑ»´ÒËìÅÐ 10-12 ªÑèÇâÁ§ - ÊÒÁÒöá»Ãà»ç¹§Ò¹»ÃШÓäÇéÃͧÃѺ㹡óթءà©Ô¹ä´éà»ç¹ÍÂèÒ§´Õ - ·Ó§Ò¹â´Âã¢éÃкº internet,fax ËÃ×ÍÊ×èÍÍÕàÅ礷Ã͹ԤÊìÍ×è¹ áÅÐÊ×èͪ¹Ô´Í×è¹æµÒÁ¤ÇÒÁ¶¹Ñ´áµèÅкؤ¤Å ·ÕèÊÓ¤ÑÁÒ¡ÁÒ¡ ¤×ÍÍÔÊÃÀÒ¾·Ò§¨Ôµã¨ ÊÒÁÒö·Ó§Ò¹´éǤÇÒÁ àºÔ¡ºÒ¹ ËÒ¡¤Ø³á¹èã¨ÇèÒ¤Ô´àªè¹¹Ñé¹ áÁéÇèҤسÂѧÈÖ¡ÉÒÍÂÙè¡çµÒÁ ÊÒÁÒöàÃÔèÁàµÃÕÂÁµÑÇËÅÕ¡ÊÀÒ¾´Ñ§¡ÅèÒÇ ¼Ùé·Õè»ÃÐʺÍÂÙèáÅéÇ¡ç ÊÒÁÒö·Õè¨ÐàÃÔèÁËÅÕ¡àÅÕè§ à¾×èÍ¡ÒÃà¡çºÍÍÁ ËÒ¡ÁÕ¤ÇÒÁʹã¨ãËé´ÙÃÒÂÅÐàÍÕ´áÅСÃÍ¡ÃÒÂÅÐàÍÕ´·Õè www.geocities.com/thaigetrich/easywork __ ËÒ¡·èÒ¹äÁè»ÃÐʧ¤ìÃѺÇÒÃÊÒèҡàÃÒÍÕ¡µèÍä» ¡ÃسÒÊè§ E-Mail Addressä»·Õè : [EMAIL PROTECTED] Ãкº¨Ð·Ó¡ÒõÃǨÊͺáÅÐźª×èͧ͢·èÒ¹ÍÍ¡¨Ò¡°Ò¹¢éÍÁÙŷѹ·Õ (¡ÃسÒÊè§à»ç¹ mail address äÁèãªè display name) _ You can unsubscibe by submit your E-mail address at [EMAIL PROTECTED] Please give specific address not your display name.
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- === usr.sbin/gstat make: don't know how to make subr_sbuf.c. Stop *** Error code 2 Stop in /tinderbox/sparc64/src/usr.sbin. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
what's the sitch on pccardd, if adaptors on, /dev/pccard* on 5.0-R? I've got an intel anypoint 2 wireless pcmcia card that is detected as pccard1 by the kernel, but where is the missing link that tells the kernel or rc that it's an ehternet adaptor? As I understand it, pccardd and pccard.conf are all old a/o 5.0. if they are, how is this supposed to work? many thanks and good fishing, -P To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI-CA import/new diff?
Hello, Do you have option MAXMEM set in your kernel config file? No. --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
devd_enable=yes would be a good start. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated if_* attach/detach patches
On Wed, 19 Mar 2003, Nate Lawson wrote: Patches are at: http://www.root.org/~nate/freebsd/if_pci/ I'd like to see calls to mtx_destroy() protected by a test for mtx_initialized(). In most cases this isn't strictly necessary but its not bad practice. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problem with fsck on -current and ufs1
I try make fsck under -current for ufs1 file system (created under -stable) and fsck print out this: fsck -y /dev/ad0s1a fsck: exec /usr/sbin/fsck_4.2BSD for /dev/ad0s1a: No such file or directory fsck search /usr/sbin/fsck_4.2BSD , but system has only /sbin/fsck_4.2bsd Need change pathnames.h:#define _PATH_USRSBIN /usr/sbin or need install fsck's to /usr/sbin and need fsck_4.2BSD instead fsck_4.2bsd (or may be both) --- Zherdev Anatoly. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problem with fsck on -current and ufs1
On Fri, Mar 21, 2003 at 06:06:53PM +0300, Zherdev Anatoly wrote: I try make fsck under -current for ufs1 file system (created under -stable) and fsck print out this: fsck -y /dev/ad0s1a fsck: exec /usr/sbin/fsck_4.2BSD for /dev/ad0s1a: No such file or directory fsck search /usr/sbin/fsck_4.2BSD , but system has only /sbin/fsck_4.2bsd Need change pathnames.h:#define _PATH_USRSBIN /usr/sbin or need install fsck's to /usr/sbin and need fsck_4.2BSD instead fsck_4.2bsd (or may be both) Simply make link by: ln -s /sbin/fsck_4.2bsd /usr/sbin/fsck_4.2BSD I don't think that you must think why fsck search other or why it compiled with name in lower case. If you want this then you must compare sources of fsck and fsck_4.2bsd. -- With best wishes Nikolay mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ᨡ¿ÃÕ ! ˹ѧÊ×ͤÙèÁ×ͤ¹à¤Â¨¹ ÊÓËÃѺ¼Ùéʹã¨....
·Ó§Ò¹·ÕèÂÒ¡·ÕèÊØ´¡è͹ ¼ÁÂÔè§ÁÕªÕÇÔµÍÂÙè¹Ò¹à·èÒäËÃè ¼ÁÂÔè§ÁÑè¹ã¨ÁÒ¡¢Öé¹à·èÒ¹Ñé¹ ÇèÒ¤ÇÒÁᵡµèÒ§ÍѹÂÔè§ãËèÃÐËÇèÒ§Á¹ØÉÂì... ÃÐËÇèÒ¤¹·ÕèÍè͹áÍáÅФ¹·ÕÍÓ¹Ò¨... ÃÐËÇèÒ§¤¹·ÕèÂÔè§ãËèáÅФ¹·ÕèäÁèÊÓ¤Ñ ¡ç¤×Í àÃÕèÂÇáç¢Í§¤ÇÒÁµÑé§ã¨á¹èÇá¹è·ÕèäÁèÍÒ¨·ÓÅÒÂä´é ¨Ø´»ÃÐʧ¤ì·ÕèàÁ×è͵Ñ駢Öé¹áÅéÇ ¶éÒäÁèµÒ¡çµéͧª¹Ð -à«ÍÃìâ¸ÁÑÊ ¿ÒÇàÇÅ ºÑê¡«ìµÑ¹ ˹Öè§ã¹à·¤¹Ô¤·Õè´Õ·ÕèÊش㹡ÒÃàÍÒª¹Ð¹ÔÊѼѴÇѹ»ÃСѹ¾ÃØè§ áÅзӧҹä´éÁÒ¡¢Öé¹áÅÐàÃçÇ¢Ö鹡ç¤×ÍŧÁ×Í·Ó§Ò¹·ÕèÂÒ¡·ÕèÊØ´¢Í§¤Ø³¡è͹ ¹Õè¤×Í¡Òà ¡Ô¹¡º¢Í§¤Ø³ ·Õèá·é¨ÃÔ§ Áѹà»ç¹·Ñ¡ÉÐÊèǹºØ¤¤Å㹡ÒúÃÔËÒà ·ÕèÂÒ¡·ÕèÊØ´áÅÐÊӤѷÕèÊØ´àÃÔèÁµé¹µÍ¹àªéÒ´éǧҹ·ÕèãËè·ÕèÊØ´áÅÐÊӤѷÕèÊØ´ ¤×Í ÊÔ觵ç¢éÒÁ¡Ñº·Õ褹ÊèǹãËè·Ó ÃÐàºÕºÇԹѹÕé¨Ð·ÓãËé¤Ø³àÅÔ¡¹ÔÊÑ ¼Ñ´Çѹ »ÃСѹ¾ÃØè§áÅзÓãËé͹ҤµÍÂÙè㹡ÓÁ×ͤس ¡ÒÃàÃÔèÁµé¹áµèÅÐÇѹ´éǧҹ·ÕèÂÒ¡·ÕèÊØ´à»ç¹¡ÒÃàÃÔèÁµé¹áºº¡éÒÇ¡ÃÐâ´´ ·Õè´Õ ¤Ø³¨ÐÁÕä¿ÁÒ¡¢Öé¹ áÅШзӧҹä´é¼Å´ÕÁÒ¡¢Öé¹ ã¹Çѹ·Õè¤Ø³àÃÔèÁŧÁ×Í·Ó§Ò¹ÊÓ¤Ñâ´Â·Ñ¹·Õ·Ñ¹¤Çѹ ¤Ø³¨ÐÃÙéÊÖ¡´Õ¡ÑºµÑÇ ¤Ø³àͧáÅСѺ§Ò¹¢Í§¤Ø³ÁÒ¡¡ÇèÒ¤¹Í×è¹æ ¤Ø³¨ÐÃÙéÊÖ¡ÁÕÍÓ¹Ò¨ÁÒ¡¢Öé¹ ¤Çº¤ØÁ µÑÇàͧä´éÁÒ¡¢Öé¹áÅÐÃѺ¼Ô´ªÍº´ÙáŪÕÇÔµµÑÇàͧä´éÁÒ¡¡ÇèÒàÇÅÒÍ×è¹ ÊÃéÒ§¹ÔÊÑÂàÃÔèÁ·Ó§Ò¹·ÕèÂÒ¡·ÕèÊØ´¡è͹áÅéǤس¨ÐäÁèµéͧÁͧÂé͹¡ÅѺ ¤Ø³¨Ð¡ÅÒÂà»ç¹ ˹Öè§ã¹¤¹·ÕèÁÕ»ÃÐÊÔ·¸ÔÀÒ¾ÁÒ¡·ÕèÊش㹤¹ÃØ蹤س... ¡Ô¹¡ºµÑǹÑ鹫Ð!!! ¨§ÁͧµÑÇàͧÇèÒà»ç¹§Ò¹·Õè¡ÓÅѧ¤×ºË¹éÒ ¨§à·ã¨ãËé¡Ñº¡ÒÃà¾ÒйÔÊÑ à»ç¹¤¹ÁռŧҹÊÙ§´éÇ¡Òý֡«éÓáÅéÇ«éÓàÅèÒ¨¹¡ÃзÑè§Áѹ¡ÅÒÂà»ç¹àÃ×èͧÍѵâ¹ÁѵÔáÅÐ ¡ÅÒÂà»ç¹àÃ×èͧ§èÒ ˹Öè§ã¹ÇÅÕ·ÕèÁÕ͹ØÀÒ¾ÁÒ¡·ÕèÊØ´«Ö觤سÊÒÁÒöàÃÕ¹ÃÙéáÅйÓÁÒãªéä´é¡ç¤×Í à¾×èÍÇѹ¹Õéà·èÒ¹Ñé¹! ÍÂèÒÇÔµ¡àÃ×èͧ¡ÒÃà»ÅÕè¹á»Å§ªÕÇÔµµÑÇàͧ ¶éÒÁѹ¿Ñ§àËÁ×͹à»ç¹ ¤ÇÒÁ¤Ô´·Õè´Õ ¨§·ÓÁѹ à¾×èÍÇѹ¹Õéà·èÒ¹Ñé¹ ºÍ¡¡ÑºµÑÇàͧÇèÒ à¾×èÍÇѹ¹Õéà·èÒ¹Ñé¹ ©Ñ¹¨ÐÇҧἹàµÃÕÂÁ¡Òà áÅÐàÃÔèÁµé¹§Ò¹ ·ÕèÂÒ¡·ÕèÊØ´¡è͹¨Ð·ÓÍÂèÒ§Í×è¹ áÅéǤس¨Ðµéͧ·Ö觡Ѻ¤ÇÒÁᵡµèÒ§·Õèà¡Ô´¢Öé¹ã¹ªÕÇÔµ¤Ø³ -- ¤Ø³ ¾ÃéÍÁáÅéÇÃÖÂѧ ¡ÑºÃٻẺ¡Ò÷ӧҹ§èÒÂæ¨Ò¡·ÕèºéÒ¹ Click Here! www.geocities.com/thaigetrich/easywork , ËÃ×Í Tel. 0-2277-7850 ¡´ 25 --- ¢ÍÍÀÑÂËÒ¡à»ç¹¡ÒÃú¡Ç¹ áÅÐËÒ¡äÁèµéͧ¡ÒÃãËéÊ觢èÒÇÊÒÃÁÒÂѧ·èÒ¹ÍÕ¡ ¡ÃسÒàÁÅÅìÁÒ·Õè [EMAIL PROTECTED] ËÑÇ¢éÍ unsub
Re: Updated if_* attach/detach patches
On Fri, 21 Mar 2003, Matthew N. Dodd wrote: On Wed, 19 Mar 2003, Nate Lawson wrote: Patches are at: http://www.root.org/~nate/freebsd/if_pci/ I'd like to see calls to mtx_destroy() protected by a test for mtx_initialized(). In most cases this isn't strictly necessary but its not bad practice. Perhaps I should add a comment mentioning my assumption: mtx_init is one of the first things called and since detach unconditionally locks the mtx, it should never be called unless the mutex is initialized. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated if_* attach/detach patches
On Fri, 21 Mar 2003, Nate Lawson wrote: Perhaps I should add a comment mentioning my assumption: mtx_init is one of the first things called and since detach unconditionally locks the mtx, it should never be called unless the mutex is initialized. This isn't the case for all drivers and the test would set a good example for people reading the code. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
IPDIVERT problem?
The system is running FreeBSD 5-current, cvsup'd yesterday.
dmesg:
Mar 19 13:05:23 hades kernel: ipfw2 initialized, divert enabled,
rule-based forwarding enabled, default to accept, logging limited to 100
packets/entry by default
Mar 19 13:05:23 hades kernel: DUMMYNET initialized (011031)
Mar 19 13:05:23 hades kernel: IPv6 packet filtering initialized, default
to accept, logging limited to 100 packets/entry
rc.firewall:
${fwcmd} add 50 divert natd all from any to any via ${natd_interface}
error:
ipfw: opcode 50 size 1 wrong
getsockopt(IP_FWD_ADD): something something
kernel conf:
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_FORWARD
options IPFIREWALL_VERBOSE_LIMIT=100
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL_FORWARD
options IPV6FIREWALL
options IPV6FIREWALL_VERBOSE
options IPV6FIREWALL_VERBOSE_LIMIT=100
options IPV6FIREWALL_DEFAULT_TO_ACCEPT
options DUMMYNET
options IPDIVERT
any ideas?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
MIDI on SB Live! ?
Hello, just out of curiosity: Is someone working in MIDI support for Creative EMU10K1 based sound cards (aka Soundblaster Live!) ? Regards, Julian Stecklina To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IPDIVERT problem?
On Friday, March 21, 2003, at 11:51 AM, Kevin S. Brackett wrote:
Mar 19 13:05:23 hades kernel: ipfw2 initialized, divert enabled,
rule-based forwarding enabled, default to accept, logging limited to
100
packets/entry by default
Mar 19 13:05:23 hades kernel: DUMMYNET initialized (011031)
Mar 19 13:05:23 hades kernel: IPv6 packet filtering initialized,
default
to accept, logging limited to 100 packets/entry
It's been working fine for me although I'm not using DUMMYNET or IPv6
firewall, and my default is to deny. Last cvsup was a couple days ago.
${fwcmd} add 50 divert natd all from any to any via ${natd_interface}
Same here. Was it working before or is this a new setup? Have you
verified natd is running, natd_interface is defined to your public
interface and all that?
ipfw: opcode 50 size 1 wrong
getsockopt(IP_FWD_ADD): something something
Maybe try without IPv6 firewall and DUMMYNET to help narrow the problem
down.
--
Tod Oace [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: IPDIVERT problem?
On Fri, 21 Mar 2003, Tod Oace wrote: Same here. Was it working before or is this a new setup? Have you verified natd is running, natd_interface is defined to your public interface and all that? Everything was working fine a few weeks ago, and the system has been running 5 about a month prior -release... i'll try removing the ipv6 and dummynet options since i'm not using either right now, and let you know. - kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IPDIVERT problem?
On 2003.03.21 14:51:18 -0500, Kevin S. Brackett wrote: ipfw: opcode 50 size 1 wrong getsockopt(IP_FWD_ADD): something something Are you really sure that your kernel/world is in sync? This is the kind of error you can get if they are not in sync. -- Simon L. Nielsen pgp0.pgp Description: PGP signature
Re: question on profiling code
Long ago, On Mon, 17 Feb 2003, Jake Burkholder wrote:
[I quoted everything since this thread is so old. My main point is at
the end. It restarts and older part of this thread.]
Can you explain how fuswintr() and suswintr() work on sparc64's? They
seem to cause traps if the user counter is not mapped, and I can't see
where the traps are handled. ia64/trap.c has a comment about where these
traps are handled, but has dummies for fuswintr() and suswintr() so the
traps never occur. Depending on traps in fast interrupt handlers is
a bug IMO. It extends the scope of the fast interrupt handler to the
trap handler, and it is difficult to limit this scope and verify the
locking for it.
Ok. Sparc64 uses lazy trap handling, similar to how I saw you'd done
in your sys.dif. The functions that access user space are delimited by
labels, and in trap and trap_pfault we check to see if the pc is inside
of the labels. fuswintr and suswintr and bracketed by fs_nofault_intr_begin
and fs_nofault_intr_end, which trap_pfault checks for specifically before
doing much of anything:
if (ctx != TLB_CTX_KERNEL) {
if ((tf-tf_tstate TSTATE_PRIV) != 0
(tf-tf_tpc = (u_long)fs_nofault_intr_begin
tf-tf_tpc = (u_long)fs_nofault_intr_end)) {
tf-tf_tpc = (u_long)fs_fault;
tf-tf_tnpc = tf-tf_tpc + 4;
return (0);
}
... handle fault
ctx != TLB_CTX_KERNEL is akin to va VM_MAXUSER_ADDRESS (the address spaces
overlap on sparc64 so we can only rely on tlb context numbers). Note that
the range bracketed by the fs_nofault_intr_* is included in the fs_nofault
range, which handles alignment or data access exception faults.
I see. This is much cleaner than my version, since I use lots of equality
checks instead of the range check, and need labels for them all.
It does take some special care in trap() and trap_pfault() not to access
important data, or acquire any locks before this test. Non-trivial
interrupts are still masked here, which buys us something. Probably the
vmspace pointer should not be counted on in this context, but I don't think
it will ever be invalid for the current process, especially since the original
interrupt occured in usermode.
The i386 trap() wants to enable interrupts early since this reduces its
complications, but this is wrong even for its existing lazy trap handling.
My version has even more complications in an attempt to only mask interrupts
earlier in the non-lazy trap handling cases.
The only locking that's required that I can see is that PS_PROFIL not be
set when the profiling buffer is invalid. But all that will happen is that
attempts to update the profiling buffer will be ignored. Technically the
process should get a signal but addupc_task doesn't check the return value
of copyin/out (oops).
addupc_task still doesn't check. It wouldn't hurt for profil() to
check the buffer up front using useracc(). But silly processes could
still unmap the buffer, so copyin/out should check too. Strictly, we
need enough locking to prevent invalid profiling buffers being used
once the process has seen that they have been invalidated. Even silly
processes can reasonably expect to use their profiling buffers for
something else after they have turned off profiling.
Back to an older part of this thread:
On Mon, 17 Feb 2003, Jake Burkholder wrote:
Apparently, On Mon, Feb 17, 2003 at 05:35:09PM +1100,
Now there is a stronger reason: clock interrupt handling is fast,
so it normally returns to user mode without going near ast(), and the
counter is not updated until the next non-fast interrupt or syscall.
In freebsd fast interrupts do handle asts, on i386 they return through
doreti
Oops.
Actually, this doesn't always help. ast() is only called on return to user
mode. doreti doesn't check TDF_NEEDRESCHED on return to kernel mode. Thus
the following code in ithread_schedule() only works right if the interrupt
occurred in user mode:
% if (TD_AWAITING_INTR(td)) {
% CTR2(KTR_INTR, %s: setrunqueue %d, __func__, p-p_pid);
% TD_CLR_IWAIT(td);
% setrunqueue(td);
% if (do_switch
% (ctd-td_critnest == 1) ) {
% KASSERT((TD_IS_RUNNING(ctd)),
% (ithread_schedule: Bad state for curthread.));
% ctd-td_proc-p_stats-p_ru.ru_nivcsw++;
% if (ctd-td_kse-ke_flags KEF_IDLEKSE)
% ctd-td_state = TDS_CAN_RUN; /* XXXKSE */
% mi_switch();
% } else {
% curthread-td_flags |= TDF_NEEDRESCHED;
^^^
% }
% } else {
There is only a problem when we didn't switch immediately
Re: IPDIVERT problem?
ipfw: opcode 50 size 1 wrong getsockopt(IP_FWD_ADD): something something I had this experience a few days ago too. It turned out as being an outdated /sbin/ipfw. cvsup'ing and then `cd /usr/src/sbin/ipfw make all install clean` solved it. Notice that if you did NOT run a make world _after_ compiling the kernel that gave you that error, you will need to update /usr/include/netinet/ip_fw*.h. Fred -- Show your affection, which will probably meet with pleasant response. pgp0.pgp Description: PGP signature
Re: IPDIVERT problem?
On Fri, 21 Mar 2003, Fred Souza wrote: ipfw: opcode 50 size 1 wrong getsockopt(IP_FWD_ADD): something something I had this experience a few days ago too. It turned out as being an outdated /sbin/ipfw. cvsup'ing and then `cd /usr/src/sbin/ipfw make all install clean` solved it. Notice that if you did NOT run a make world _after_ compiling the kernel that gave you that error, you will need to update /usr/include/netinet/ip_fw*.h. ah, I should of known this. Making world now. thanks all :) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
freebsd 5.0 on hp netserver lf
Folks, I posted a question earlier on freebsd-questions concerning this, and have since discovered a bit more. Sorry about the cross posting. I'm trying to get 5.0 running on an old hp netserver lf. quoting some random website: How come FreeBSD does not detect my HP Netserver's SCSI controller? This is basically a known problem. The EISA on-board SCSI controller in the HP Netserver machines occupies EISA slot number 11, so all the true EISA slots are in front of it. Alas, the address space for EISA slots = 10 collides with the address space assigned to PCI, and FreeBSD's auto-configuration currently cannot handle this situation very well. So now, the best you can do is to pretend there is no address range clash :), by bumping the kernel option EISA_SLOTS to a value of 12... Of course, this does present you with a chicken-and-egg problem when installing on such a machine. In order to work around this problem, a special hack is available inside UserConfig. Do not use the visual interface, but +the plain command-line interface there. Simply type eisa 12 quit at the prompt, and install your system as usual. While it is recommended you compile and install a custom kernel anyway. The above quoted instructions worked fine when booting with 4.7 floppies, but 5.0 seems to lack the option to boot into UserConfig with a boot -c command. Looking at the device.hints options, which seem to be replacing the UserConfig command, I don't see anything listed for eisa slots. With 5.0's boot loader, I've used set EISA_SLOTS=12 set EISA=12 but the dmesg and installer still don't list the scsi controller, and hence no drives. Interestingly, an lsdev at the boot prompt correctly lists the floppy and two drives, including the partition information. Any suggestions would be greatly appreciated. thanks, Brian -- Brian Kirk primuul.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Apache Portable Runtime testcase hangs -current
Hi,
I am using a system which I cvsup'd a few weeks ago:
FreeBSD 5.0-CURRENT FreeBSD 5.0-CURRENT #18: Mon Feb 24 06:06:47 EST 2003 [EMAIL
PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL1 i386
I tried to compile the latest beta version of the Apache Portable Runtime
library. As part of the configure process, the attached testcase
is run. When the testcase runs, my machine locks up *HARD*.
- keyboard is totally unresponsive
- network connectivity to machine is lost and I cannot telnet or ssh into
the box
Does anyone have any idea what the problem could be?
How stable is -current to work with if I cvsup and rebuild?
Thanks.
--
Craig Rodrigues
http://home.attbi.com/~rodrigc
[EMAIL PROTECTED]
#if 0
dnl
dnl see if TCP_NODELAY setting is inherited from listening sockets
dnl
AC_DEFUN(APR_CHECK_TCP_NODELAY_INHERITED,[
AC_CACHE_CHECK(if TCP_NODELAY setting is inherited from listening sockets,
ac_cv_tcp_nodelay_inherited,[
AC_TRY_RUN( [
#endif /* if 0 */
#define HAVE_SYS_TYPES_H 1
#define HAVE_SYS_SOCKET_H 1
#define HAVE_NETINET_IN_H 1
#define HAVE_NETINET_TCP_H 1
#define HAVE_SOCKLEN_T 1
#include stdio.h
#ifdef HAVE_SYS_TYPES_H
#include sys/types.h
#endif
#ifdef HAVE_SYS_SOCKET_H
#include sys/socket.h
#endif
#ifdef HAVE_NETINET_IN_H
#include netinet/in.h
#endif
#ifdef HAVE_NETINET_TCP_H
#include netinet/tcp.h
#endif
#ifndef HAVE_SOCKLEN_T
typedef int socklen_t;
#endif
int main(void) {
int listen_s, connected_s, client_s;
int listen_port, rc;
struct sockaddr_in sa;
socklen_t sa_len;
socklen_t option_len;
int option;
listen_s = socket(AF_INET, SOCK_STREAM, 0);
if (listen_s 0) {
perror(socket);
exit(1);
}
option = 1;
rc = setsockopt(listen_s, IPPROTO_TCP, TCP_NODELAY, option, sizeof option);
if (rc 0) {
perror(setsockopt TCP_NODELAY);
exit(1);
}
memset(sa, 0, sizeof sa);
sa.sin_family = AF_INET;
#ifdef BEOS
sa.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
#endif
/* leave port 0 to get ephemeral */
rc = bind(listen_s, (struct sockaddr *)sa, sizeof sa);
if (rc 0) {
perror(bind for ephemeral port);
exit(1);
}
/* find ephemeral port */
sa_len = sizeof(sa);
rc = getsockname(listen_s, (struct sockaddr *)sa, sa_len);
if (rc 0) {
perror(getsockname);
exit(1);
}
listen_port = sa.sin_port;
rc = listen(listen_s, 5);
if (rc 0) {
perror(listen);
exit(1);
}
client_s = socket(AF_INET, SOCK_STREAM, 0);
if (client_s 0) {
perror(socket);
exit(1);
}
memset(sa, 0, sizeof sa);
sa.sin_family = AF_INET;
sa.sin_port = listen_port;
#ifdef BEOS
sa.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
#endif
/* leave sin_addr all zeros to use loopback */
rc = connect(client_s, (struct sockaddr *)sa, sizeof sa);
if (rc 0) {
perror(connect);
exit(1);
}
sa_len = sizeof sa;
connected_s = accept(listen_s, (struct sockaddr *)sa, sa_len);
if (connected_s 0) {
perror(accept);
exit(1);
}
option_len = sizeof option;
rc = getsockopt(connected_s, IPPROTO_TCP, TCP_NODELAY, option, option_len);
if (rc 0) {
perror(getsockopt);
exit(1);
}
if (!option) {
fprintf(stderr, TCP_NODELAY is not set in the child.\n);
exit(1);
}
return 0;
}
#if 0
],[
ac_cv_tcp_nodelay_inherited=yes
],[
ac_cv_tcp_nodelay_inherited=no
],[
ac_cv_tcp_nodelay_inherited=yes
])])
if test $ac_cv_tcp_nodelay_inherited = yes; then
tcp_nodelay_inherited=1
else
tcp_nodelay_inherited=0
fi
])
#endif
Re: freebsd 5.0 on hp netserver lf
- Original Message - From: Brian J. Kirk [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 21, 2003 5:45 PM Subject: freebsd 5.0 on hp netserver lf Folks, I posted a question earlier on freebsd-questions concerning this, and have since discovered a bit more. Sorry about the cross posting. I'm trying to get 5.0 running on an old hp netserver lf. quoting some random website: How come FreeBSD does not detect my HP Netserver's SCSI controller? This is basically a known problem. The EISA on-board SCSI controller in the HP Netserver machines occupies EISA slot number 11, so all the true EISA slots are in front of it. Alas, the address space for EISA slots = 10 collides with the address space assigned to PCI, and FreeBSD's auto-configuration currently cannot handle this situation very well. So now, the best you can do is to pretend there is no address range clash :), by bumping the kernel option EISA_SLOTS to a value of 12... Of course, this does present you with a chicken-and-egg problem when installing on such a machine. In order to work around this problem, a special hack is available inside UserConfig. Do not use the visual interface, but +the plain command-line interface there. Simply type eisa 12 quit at the prompt, and install your system as usual. While it is recommended you compile and install a custom kernel anyway. The above quoted instructions worked fine when booting with 4.7 floppies, but 5.0 seems to lack the option to boot into UserConfig with a boot -c command. Looking at the device.hints options, which seem to be replacing the UserConfig command, I don't see anything listed for eisa slots. With 5.0's boot loader, I've used set EISA_SLOTS=12 set EISA=12 but the dmesg and installer still don't list the scsi controller, and hence no drives. Interestingly, an lsdev at the boot prompt correctly lists the floppy and two drives, including the partition information. Any suggestions would be greatly appreciated. thanks, Brian -- Brian Kirk primuul.com Try using hw.eisa_slots = 12. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Apache Portable Runtime testcase hangs -current
On Fri, Mar 21, 2003 at 06:00:35PM -0500, Craig Rodrigues wrote: I am using a system which I cvsup'd a few weeks ago: FreeBSD 5.0-CURRENT FreeBSD 5.0-CURRENT #18: Mon Feb 24 06:06:47 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL1 i386 I tried to compile the latest beta version of the Apache Portable Runtime library. As part of the configure process, the attached testcase is run. When the testcase runs, my machine locks up *HARD*. - keyboard is totally unresponsive - network connectivity to machine is lost and I cannot telnet or ssh into the box Does anyone have any idea what the problem could be? How stable is -current to work with if I cvsup and rebuild? -CURRENT still isn't for production, but more bugs fixed and now it more stable, then one month ago. Please update your system and try to reproduce your bug. -- Rgdz,/\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
On 21 Mar 2003, Chris Fowler wrote: I'm not sure I understand the motivations of running IP over firewire vs. ethernet. Sure I think its cool but will the speed be there with firewire2? On Windows, It is P-t-P is it not? I would prefer a real live network. Hi, I don't know about the Mac's implementation, but yes, Windows has IP over Firewire, like NetBSD. The good reason for IP over Firewire: because it's a standard, you can connect Macs, Win Boxes and BSDs! :) Rossam. On Wed, 2003-03-05 at 08:25, David Leimbach wrote: Interesting... I didn't even know we had Ethernet over firewire :). Mac OS X and Windows XP both have IP over firewire either working or in the works and somewhat usable. The only one I can claim any experience with is Mac OS X. It's somewhat flaky though and you get unreliable spikes in some basic performance tests I have done with it. It would be a really interesting value added feature for FreeBSD 5.x and could potentially open FBSD up even more to the cluster market which is somewhere its not as proliferated as linux. With the advent of firewire2 on the horizon it may be even more impressive. I believe there is even an Oracle product for linux which can cluster databases over firewire now. [I don't know if its IP though] Dave On Wednesday, March 5, 2003, at 01:43 AM, Rossam Souza Silva wrote: Hi, there is some plan to port NetBSD's implementation of IP over Firewire? I know, we have Ethernet over Firewire, but like the Linux one, isn't a standard... Just curious. --- --- (_ ) Contrary to popular belief, UNIX is user friendly. It just happens \\\'',) ^ to be very selective about who it decides to make friends with. \/ \( .\._/_) Rossam Souza Silva ([EMAIL PROTECTED]) --- -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: freebsd 5.0 on hp netserver lf
set hw.eisa_slots=12 works, it recognizes the controller and drives, then panics. I think I'll settle for 4.7 on here fow now. thanks for your help, Brian On Fri, Mar 21, 2003 at 06:00:29PM -0500, Matthew Emmerton wrote: - Original Message - From: Brian J. Kirk [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 21, 2003 5:45 PM Subject: freebsd 5.0 on hp netserver lf Folks, I posted a question earlier on freebsd-questions concerning this, and have since discovered a bit more. Sorry about the cross posting. I'm trying to get 5.0 running on an old hp netserver lf. quoting some random website: How come FreeBSD does not detect my HP Netserver's SCSI controller? This is basically a known problem. The EISA on-board SCSI controller in the HP Netserver machines occupies EISA slot number 11, so all the true EISA slots are in front of it. Alas, the address space for EISA slots = 10 collides with the address space assigned to PCI, and FreeBSD's auto-configuration currently cannot handle this situation very well. So now, the best you can do is to pretend there is no address range clash :), by bumping the kernel option EISA_SLOTS to a value of 12... Of course, this does present you with a chicken-and-egg problem when installing on such a machine. In order to work around this problem, a special hack is available inside UserConfig. Do not use the visual interface, but +the plain command-line interface there. Simply type eisa 12 quit at the prompt, and install your system as usual. While it is recommended you compile and install a custom kernel anyway. The above quoted instructions worked fine when booting with 4.7 floppies, but 5.0 seems to lack the option to boot into UserConfig with a boot -c command. Looking at the device.hints options, which seem to be replacing the UserConfig command, I don't see anything listed for eisa slots. With 5.0's boot loader, I've used set EISA_SLOTS=12 set EISA=12 but the dmesg and installer still don't list the scsi controller, and hence no drives. Interestingly, an lsdev at the boot prompt correctly lists the floppy and two drives, including the partition information. Any suggestions would be greatly appreciated. thanks, Brian -- Brian Kirk primuul.com Try using hw.eisa_slots = 12. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Brian Kirk primuul.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: freebsd 5.0 on hp netserver lf
On Fri, Mar 21, 2003 at 06:15:01PM -0500, Brian J. Kirk wrote: set hw.eisa_slots=12 works, it recognizes the controller and drives, then panics. I think I'll settle for 4.7 on here fow now. Try disable ACPI with unset acpi_load at boot prompt. Maybe its help you. On Fri, Mar 21, 2003 at 06:00:29PM -0500, Matthew Emmerton wrote: I posted a question earlier on freebsd-questions concerning this, and have since discovered a bit more. Sorry about the cross posting. I'm trying to get 5.0 running on an old hp netserver lf. quoting some random website: How come FreeBSD does not detect my HP Netserver's SCSI controller? This is basically a known problem. The EISA on-board SCSI controller in the HP Netserver machines occupies EISA slot number 11, so all the true EISA slots are in front of it. Alas, the address space for EISA slots = 10 collides with the address space assigned to PCI, and FreeBSD's auto-configuration currently cannot handle this situation very well. So now, the best you can do is to pretend there is no address range clash :), by bumping the kernel option EISA_SLOTS to a value of 12... Of course, this does present you with a chicken-and-egg problem when installing on such a machine. In order to work around this problem, a special hack is available inside UserConfig. Do not use the visual interface, but +the plain command-line interface there. Simply type eisa 12 quit at the prompt, and install your system as usual. While it is recommended you compile and install a custom kernel anyway. The above quoted instructions worked fine when booting with 4.7 floppies, but 5.0 seems to lack the option to boot into UserConfig with a boot -c command. Looking at the device.hints options, which seem to be replacing the UserConfig command, I don't see anything listed for eisa slots. With 5.0's boot loader, I've used set EISA_SLOTS=12 set EISA=12 but the dmesg and installer still don't list the scsi controller, and hence no drives. Interestingly, an lsdev at the boot prompt correctly lists the floppy and two drives, including the partition information. Try using hw.eisa_slots = 12. -- Rgdz,/\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: freebsd 5.0 on hp netserver lf
On Fri, 21 Mar 2003, Brian J. Kirk wrote: but the dmesg and installer still don't list the scsi controller, and hence no drives. set hw.eisa_slots=12 from the loader. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libm problem
res=pow((float)base,(float)dim);
this is actually not a smart thing. it was cut and paste from libvorbis.
pow is a function for doubles. if you i use powf everything works fine.
res=pow((double)base,(double)dim) however still gives 1
the output of 'print/x {int}res' right after the call to pow().
that means 0x0 if i use double for res (, or 0x3f80 if i stay with the
float example.)
till
ps: i am pretty sure that my -O2 is turned off in my world, because that
was my first guess as well. However, i will recompile tomorrow ... and
hopefully all trouble is gone. At least after using powf i can listen to my
music again :-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: libm problem
On Sat, 22 Mar 2003, Till Riedel wrote: res=pow((float)base,(float)dim); this is actually not a smart thing. it was cut and paste from libvorbis. pow is a function for doubles. if you i use powf everything works fine. This should work OK. The casts to float should have no effect except to lose precision is the operands don't fit in about 24 bits. OTOH, powf() is known to be broken. I haven't committed a fix like the following for too long: %%% Index: e_powf.c === RCS file: /home/ncvs/src/lib/msun/src/e_powf.c,v retrieving revision 1.9 diff -u -2 -r1.9 e_powf.c --- e_powf.c17 Jun 2002 15:28:59 - 1.9 +++ e_powf.c17 Jun 2002 15:41:06 - @@ -45,5 +45,9 @@ lg2 = 6.9314718246e-01, /* 0x3f317218 */ lg2_h = 6.93145752e-01, /* 0x3f317200 */ +#if 0 +lg2_l = 1.42860677e-06, /* 0x35bfbe8e */ +#else lg2_l = 1.42860654e-06, /* 0x35bfbe8c */ +#endif ovt = 4.2995665694e-08, /* -(128-log2(ovfl+.5ulp)) */ cp= 9.6179670095e-01, /* 0x3f76384f =2/(3ln2) */ @@ -160,7 +164,7 @@ s_h = s; GET_FLOAT_WORD(is,s_h); - SET_FLOAT_WORD(s_h,is0xf000); + SET_FLOAT_WORD(s_h,is0xfffc); /* t_h=ax+bp[k] High */ - SET_FLOAT_WORD(t_h,((ix1)|0x2000)+0x004+(k21)); + SET_FLOAT_WORD(t_h,((ix1)|0x2000)+0x0040+(k21)); t_l = ax - (t_h-bp[k]); s_l = v*((u-s_h*t_h)-s_h*t_l); @@ -229,5 +233,5 @@ t = p_l+p_h; GET_FLOAT_WORD(is,t); - SET_FLOAT_WORD(t,is0xf000); + SET_FLOAT_WORD(t,is0xfff8); u = t*lg2_h; v = (p_l-(t-p_h))*lg2+t*lg2_l; %%% The change to lg2_l just fixes a tiny error. We gain precision by representing log(2) as approximately (lg2_h + lg2_l) in infinite precision. The bits in lg2_l are relatively uncritical since most of them are to give more than float precision. But they sometimes matter. The Cygnus extensions to support float precision have a number of off by 1 or 2 bit errors converting the low values. I fixed a couple of these, but IIRC there was only one that caused an error that was reported by ucbtest (not this one). The changes in the magic numbers are too fix larger errors. I don't rememebr anything else about them except that the errors were reported by ucbtest and the changes made ucbtest happy. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libm problem
I now know the thing that makes it break. cc -O2 -pipe -mcpu=pentiumpro -c /usr/src/lib/msun/src/e_pow.c works fine! cc -O0 -pipe -march=pentium4 -c /usr/src/lib/msun/src/e_pow.c ... works but... cc -O -pipe -march=pentium4 -c /usr/src/lib/msun/src/e_pow.c breaks it. Hey its only gcc :-), nothing to worry about. I think that 0 is nice number: so why don't optimize everithing to down it. -O seems to minimize numbers not calculation time. Does anyone know the flag to turn that off. till To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libm problem
On Sat, Mar 22, 2003 at 01:54:35AM +0100, Till Riedel wrote: cc -O -pipe -march=pentium4 -c /usr/src/lib/msun/src/e_pow.c OK, I found PR 43299. Why do I never find them in first place. till To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 2106] RE: ACPI-CA import/new diff?
I tested it in my laptop. Everything works however just as the previous version. I didn't see any bug in my machine fixed. Anyway I think it is worth to check in. Jun Su _ Do You Yahoo!? NetVista A30 http://ad.cn.doubleclick.net/clk;5313999;7930402;p?http://www.ibm.com/cn/promotion/pc/netvista_a30/index.shtml To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: mdconfig/mdmfs problems - kernel panic
Ok, I tried to recompile with the max users set to 256 to see if that would help things and while I was copying over the /src/sys tree to /mnt (the md0 device, 512MB) I got: panic: kmem_malloc(4096): kmem_map too small: 296222720 total allocated cpuid = 3; lapic.id = 07000 Debugger(panic) Any suggestions? -Original Message- From: John Stockdale [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 11:41 AM To: '[EMAIL PROTECTED]' Subject: RE: mdconfig/mdmfs problems - kernel panic Ahh, that explains why the multiple /dev/md* didn't help the problem. I'm looking into the vmstat options, but can't figure out how to extract the malloc-per-bucket-quota limit for the system (I've read man vmstat, and tried vmstat -z and vmstat -m, but the only Limit listed is under vmstat -z, and nothing indicates if any displayed limits are relavent to this discussion). Additionally, if I am hitting this limit, how can I increase the limit/what kind of impact would increasing the impact have on the system except in allowing me to user larger /dev/md*? Thanks. -John -Original Message- From: Poul-Henning Kamp [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 11:27 AM To: John Stockdale Cc: [EMAIL PROTECTED] Subject: Re: mdconfig/mdmfs problems - kernel panic In message [EMAIL PROTECTED], John Stockdale writes: OS: FreeBSD 5.0-CURRENT, JPSNAP20030314 I'm running a Dual Xeon system with 1GB DDRRAM, and trying to create a ram disk to compile under, specifically to compile the kernel. I've tried several methods, involving either creating one 512MB disk with mdconfig or mdmfs. No matter what options I specify, the mounted mfs works fine until I start filling it up more. For instance, I can usually copy the entire /usr/src/sys to /mnt and make depend, but a while after I make the kernel panics as a result of the ram disk. (specifically citing malloc errors, one time it speicifically spat out a number in the order of 251XX and indicated a malloc bucket limit exceeded or something like that) quote from md(4): malloc Backing store is allocated using malloc(9). Only one malloc- bucket is used, which means that all md devices with malloc backing must share the malloc-per-bucket-quota. The exact size of this quota varies, in particular with the amount of RAM in the system. The exact value can be determined with vmstat(8). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libm problem
Thus spake Till Riedel [EMAIL PROTECTED]: I now know the thing that makes it break. cc -O2 -pipe -mcpu=pentiumpro -c /usr/src/lib/msun/src/e_pow.c works fine! cc -O0 -pipe -march=pentium4 -c /usr/src/lib/msun/src/e_pow.c ... works but... cc -O -pipe -march=pentium4 -c /usr/src/lib/msun/src/e_pow.c breaks it. Hey its only gcc :-), nothing to worry about. I think that 0 is nice number: so why don't optimize everithing to down it. -O seems to minimize numbers not calculation time. Does anyone know the flag to turn that off. If you have the time and inclination, I suggest reporting this problem to the gcc folks. For now, don't use Pentium 4 optimizations. Not only are they apparently broken, they also generate slower code than you get by optimizing for a PPro, or even a 386. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
IRQs' Dispatch problem
Hi All, Since the sound in my lap (SONY R505) doesn't work, I did some troubleshooting. This problem was reported several times in the -mobile. The sound has delay normally. Most interesting thing is when the I move usb mouse fast or has a high network load, the sound become better. I think the problem is related to the IRQ dispatch. When I use systat-vmstat, I found the interrupt number for pcm0 is large when I move mouse fast. Who can give me some advice? Or produce a path I can try. BTW: I can not find the usb driver and fxp0 in the list of the systat-vmstat. In my machine, IRQ 9 is shared with several devices, as listed in the following dmesg. agp0: Intel 82830M (830M GMCH) SVGA controller mem 0xe000-0xe007,0xe800-0xefff irq 9 at device 2.0 on pci0 uhci0: Intel 82801CA/CAM (ICH3) USB controller USB-A port 0x1800-0x181f irq 9 at device 29.0 on pci0 uhci1: Intel 82801CA/CAM (ICH3) USB controller USB-B port 0x1820-0x183f irq 9 at device 29.1 on pci0 uhci2: Intel 82801CA/CAM (ICH3) USB controller USB-C port 0x1840-0x185f at device 29.2 on pci0 pcib0: possible interrupts: 9 fxp0: Intel 82801CAM (ICH3) Pro/100 VE Ethernet port 0x3000-0x303f mem 0xe0204000-0xe0204fff irq 9 at device 8.0 on pci2 pcm0: Intel 82801CA (ICH3) port 0x18c0-0x18ff,0x1c00-0x1cff irq 9 at device 31.5 on pci0 uname -v FreeBSD 5.0-CURRENT #14: Sat Mar 15 18:28:01 CST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/VAIO Jun Su _ Do You Yahoo!? NetVista A30 http://ad.cn.doubleclick.net/clk;5313999;7930402;p?http://www.ibm.com/cn/promotion/pc/netvista_a30/index.shtml To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
Rossam Souza Silva [EMAIL PROTECTED] writes: Hi, I don't know about the Mac's implementation, but yes, Windows has IP over Firewire, like NetBSD. The good reason for IP over Firewire: because it's a standard, you can connect Macs, Win Boxes and BSDs! :) Gee, well, I guess we can all get rid of that nasty non-standard Ethernet hardware now! DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
On Sat, 22 Mar 2003, Dag-Erling Smørgrav wrote: Rossam Souza Silva [EMAIL PROTECTED] writes: Hi, I don't know about the Mac's implementation, but yes, Windows has IP over Firewire, like NetBSD. The good reason for IP over Firewire: because it's a standard, you can connect Macs, Win Boxes and BSDs! :) Gee, well, I guess we can all get rid of that nasty non-standard Ethernet hardware now! No one asks for removing, if we can have both. Rossam. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
