Re: dueling (s)printf()'s - what's the cure?
Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: On Fri, Feb 01, 2008 at 06:31:11PM -0800, Chris H. wrote: I mentioned a problem with this once before, and was referred to other threads that also talked about this. But I believe a recent problem I was experiencing, may have been related to this: [: -le: argument expected. So I'd like to bring it up again, in hopes that someone might have a cure. Specifically, two printf()'s are sent to the same line, which results in a /very/ hard line to decipher. The two problems you're discussing are entirely 100% unrelated to one another. Please do not try and relate them, it will just confuse readers of both threads. Good to know. relatedness stops here. :) The problem with [/test on your system is something that's specific to your system. I'm hoping the reinstall you're doing (see private mail) will alleviate this, and if it doesn't, something you're doing after the fresh install is causing it. That should be discussed in the other thread and not here. Understood. The problem with kernel printf()s being interwoven is documented in my "common issues" file, with numerous threads referenced -- see "Scrambled dmesg/kernel output" here: http://jdc.parodius.com/freebsd/common_issues.txt Yes, I read this already (thanks for sharing it when I originally asked about this). But was hoping something had been done that fixes this. There is no fix or workaround for this problem. Someone mentioned increasing PRINTF_BUFR_SIZE to 128, which does not fix the problem, nor diminish it in any way. It's very important that people understand the interwoven kernel output is specific to stuff printed to the console at the kernel level (e.g. a driver/module, a piece of the kernel, etc.), and will not happen when doing something that's output via printf(3) from libc (e.g. output from "make buildworld", "yes", "ls -FRal /", and so on). Good to know - even if it's not a cure. :) Thank you Jeremy, for taking the time to provide such an informative reply. Best wishes. --Chris H -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dueling (s)printf()'s - what's the cure?
On Fri, Feb 01, 2008 at 08:34:56PM -0800, Jeremy Chadwick wrote: > On Fri, Feb 01, 2008 at 06:31:11PM -0800, Chris H. wrote: > > I mentioned a problem with this once before, and was referred to > > other threads that also talked about this. But I believe a recent > > problem I was experiencing, may have been related to this: > > [: -le: argument expected. So I'd like to bring it up again, in > > hopes that someone might have a cure. Specifically, two printf()'s > > are sent to the same line, which results in a /very/ hard line to > > decipher. > > The two problems you're discussing are entirely 100% unrelated to one > another. Please do not try and relate them, it will just confuse > readers of both threads. > > The problem with [/test on your system is something that's specific to > your system. I'm hoping the reinstall you're doing (see private mail) > will alleviate this, and if it doesn't, something you're doing after the > fresh install is causing it. That should be discussed in the other > thread and not here. > > The problem with kernel printf()s being interwoven is documented in my > "common issues" file, with numerous threads referenced -- see "Scrambled > dmesg/kernel output" here: > > http://jdc.parodius.com/freebsd/common_issues.txt > > There is no fix or workaround for this problem. Someone mentioned > increasing PRINTF_BUFR_SIZE to 128, which does not fix the problem, > nor diminish it in any way. What X in the RELENG_X where PRINTF_BUFR_SIZE has no effect ? This feature is not in the RELENG_6. Some time ago I made a backport, see http://people.freebsd.org/~kib/misc/releng_6_printf_bufr.2.patch I was said that the patch introduces some strange packet corruption, that I cannot test. > > It's very important that people understand the interwoven kernel output > is specific to stuff printed to the console at the kernel level (e.g. a > driver/module, a piece of the kernel, etc.), and will not happen when > doing something that's output via printf(3) from libc (e.g. output from > "make buildworld", "yes", "ls -FRal /", and so on). > > -- > | Jeremy Chadwickjdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" pgpY4qRpsjegO.pgp Description: PGP signature
Re: dueling (s)printf()'s - what's the cure?
On Fri, Feb 01, 2008 at 06:31:11PM -0800, Chris H. wrote: > I mentioned a problem with this once before, and was referred to > other threads that also talked about this. But I believe a recent > problem I was experiencing, may have been related to this: > [: -le: argument expected. So I'd like to bring it up again, in > hopes that someone might have a cure. Specifically, two printf()'s > are sent to the same line, which results in a /very/ hard line to > decipher. The two problems you're discussing are entirely 100% unrelated to one another. Please do not try and relate them, it will just confuse readers of both threads. The problem with [/test on your system is something that's specific to your system. I'm hoping the reinstall you're doing (see private mail) will alleviate this, and if it doesn't, something you're doing after the fresh install is causing it. That should be discussed in the other thread and not here. The problem with kernel printf()s being interwoven is documented in my "common issues" file, with numerous threads referenced -- see "Scrambled dmesg/kernel output" here: http://jdc.parodius.com/freebsd/common_issues.txt There is no fix or workaround for this problem. Someone mentioned increasing PRINTF_BUFR_SIZE to 128, which does not fix the problem, nor diminish it in any way. It's very important that people understand the interwoven kernel output is specific to stuff printed to the console at the kernel level (e.g. a driver/module, a piece of the kernel, etc.), and will not happen when doing something that's output via printf(3) from libc (e.g. output from "make buildworld", "yes", "ls -FRal /", and so on). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Frequent USB mouse disconnections under load with RELENG_7
On Fri, 2008-02-01 at 12:26 -0700, Joe Peterson wrote: > Wayne Sierke wrote: > > On Fri, 2008-01-25 at 01:59 +1030, Wayne Sierke wrote: > >> I'm getting a lot of USB mouse disconnects on RELENG_7. I wondered > >> whether they might have been due to running with a KTR-enabled kernel > >> but in just the last 7 hours I've been running on stock GENERIC and > >> they're still happening. > > Hey Wayne, > > I'm not sure if you associating the disconnects with the "jerky mouse" > behavior, but as an added datapoint, I have a PS/2 mouse, I see *no* > disconnects in the system logs (well, it's PS/2...), and I still get the > jerky mouse... > Hi Joe, I've found the disconnects to be quite easily distinguishable from general mouse "jerkiness" as instances of the former are quite long, in the order of 2 seconds or so and also such a "complete" disabling compared to the shorter impairment of mouse cursor movement I experience during the latter. I have also at times set up a small terminal window tailing /var/log/messages so that I could monitor the disconnect messages in real time. I hold no doubts at all about being able to recognise when one of these disconnections occurs. Out of interest I just examined the messages written when I manually disconnect the mouse and they're identical to what's written during one of these events. As per my other message to Jeremy I'll see what transpires after I remove my moused configuration from /etc/rc.conf. Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dueling (s)printf()'s - what's the cure?
Hello All, I mentioned a problem with this once before, and was referred to other threads that also talked about this. But I believe a recent problem I was experiencing, may have been related to this: [: -le: argument expected. So I'd like to bring it up again, in hopes that someone might have a cure. Specifically, two printf()'s are sent to the same line, which results in a /very/ hard line to decipher. I'm afraid that that might have occurred during the build process of a port I was attempting to build. Which, while completed, and ran successfully. Seems might have caused me no end of grief building installing anything affected by it. Ultimately resulting in my having to do a /complete/ re-install of the system, and all related. :( To the point, I was dearly hoping that someone might have a suggestion - or better, a cure for this (s)printf issue. Thank you for all your time and consideration in this matter. --Chris H FWIW here is one of the related threads: http://lists.freebsd.org/pipermail/freebsd-current/2007-October/078145.html -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Frequent USB mouse disconnections under load with RELENG_7
On Fri, 2008-02-01 at 07:17 -0800, Jeremy Chadwick wrote: > On Fri, Feb 01, 2008 at 10:00:11PM +1030, Wayne Sierke wrote: > > - I've also just noticed that I'm getting these messages on startup > > under 7.x: > > > > kernel: Starting devd. > > kernel: Starting ums0 moused: > > kernel: Starting default moused: > > moused: unable to open /dev/ums0: Device busy > > > > but I can't now recall whether I was seeing those under 6.x. Has devd > > changed with 7.x? I've got a feeling that I'd tried to get devd in 6.x > > to handle the USB mouse on startup, but that I'd found it necessary to > > configure moused explicitly (i.e. with moused_port) in rc.conf as listed > > below. However my memory of it now is hazy at best. In any case, > > disconnections aside, I've not noticed any change in mouse behaviour > > since moving to 7.x either in console or xorg. > > > > moused_enable="YES" > > moused_port="/dev/ums0" > > I think this is what's happening here: > > * kernel starts > * usb stack loads, finds a USB mouse, attaches it to ums0 > * attachment tells devd "hey, theres a /dev/ums0 device that > just attached" > * /etc/devd.conf automatically spawns moused, which attaches to > the /dev/ums0 device > * rc scripts begin > * moused_enable="yes" is detected, thus moused is run manually > against /dev/ums0 > * moused is already running from when devd spawned it, which is > why /dev/ums0 is "Device busy" > > I would recommend removing the moused_* stuff in your rc.conf and > let devd take care of it, or, consider editing /etc/devd.conf and > removing the /dev/umsX detection which runs moused. Yes, well that's what I figured, but over the years getting the USB mouse to work with X has required manual configuration and I don't recall ever having any kind of automatic devd-style detection work previously. The handbook only appears to deal with setting up a mouse via sysinstall and it isn't apparent to me from the text what configuration settings would be made when installing a USB mouse. However this current behaviour looks encouraging so I shall "give it a whirl" and we'll see whether removing the manual moused config from rc.conf eliminates these disconnections. Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-RC1 - ZFS + UFS + io activity show a deadlock
Pawel Jakub Dawidek wrote: On Sun, Jan 27, 2008 at 02:47:02PM +0100, Henri Hennebert wrote: Hello, I encounter a deadlock while 1) cpio -p from a ZFS filesystem to a UFS filesystem 2) rsync from ZFS to ZFS I was running with this patch: http://people.freebsd.org/~pjd/patches/zgd_done.patch This patch is wrong, why do you use it in the first place? You advise it to me ... I will remove it. Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-RC1 - ZFS + UFS + io activity show a deadlock
On Sun, Jan 27, 2008 at 02:47:02PM +0100, Henri Hennebert wrote: > Hello, > > I encounter a deadlock while > > 1) cpio -p from a ZFS filesystem to a UFS filesystem > > 2) rsync from ZFS to ZFS > > I was running with this patch: > http://people.freebsd.org/~pjd/patches/zgd_done.patch This patch is wrong, why do you use it in the first place? -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpVkS6s6ba90.pgp Description: PGP signature
Re: SMP + polling on 7.0-RC1
Thanks. I'm testing a parallel computing algorithm which uses a huge number of communications. I think the 7.0+SMP+polling+ULE improved the performance very much. Ed Maste wrote: On Fri, Feb 01, 2008 at 11:15:56AM -0800, Hiroshi Nishida wrote: Does the 'polling' mode for network devices work with a 7.0-RC1's SMP kernel? According to http://info.iet.unipi.it/~luigi/polling/, it seems not on FreeBSD 4. What about 7.0? Polling works with SMP as of FreeBSD 6.x. -Ed -- Hiroshi Nishida [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP + polling on 7.0-RC1
On Fri, Feb 01, 2008 at 11:15:56AM -0800, Hiroshi Nishida wrote: > Does the 'polling' mode for network devices work with a 7.0-RC1's SMP > kernel? > > According to http://info.iet.unipi.it/~luigi/polling/, it seems not on > FreeBSD 4. > What about 7.0? Polling works with SMP as of FreeBSD 6.x. -Ed ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Frequent USB mouse disconnections under load with RELENG_7
Wayne Sierke wrote: > On Fri, 2008-01-25 at 01:59 +1030, Wayne Sierke wrote: >> I'm getting a lot of USB mouse disconnects on RELENG_7. I wondered >> whether they might have been due to running with a KTR-enabled kernel >> but in just the last 7 hours I've been running on stock GENERIC and >> they're still happening. Hey Wayne, I'm not sure if you associating the disconnects with the "jerky mouse" behavior, but as an added datapoint, I have a PS/2 mouse, I see *no* disconnects in the system logs (well, it's PS/2...), and I still get the jerky mouse... -Joe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SMP + polling on 7.0-RC1
Hi. Does the 'polling' mode for network devices work with a 7.0-RC1's SMP kernel? According to http://info.iet.unipi.it/~luigi/polling/, it seems not on FreeBSD 4. What about 7.0? -- Hiroshi Nishida nishida at asusa.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [: -le: argument expected
On Fri, Feb 01, 2008 at 10:18:14AM -0800, Chris H. wrote: > I wanted to sync up my ports database before hand. So ran a portsdb -uU. > This - interestingly enough, resulted in both [: -le: argument expected, > and [: -eq: argument expected being emitted /many/ times during the portsdb > process. So, now I'm stumped. It is clear that it is /not/ specific to the > php5-apache-module. But rather, something that is common to that, and other > ports. It's clear that /bin/[ is the command complaining. But my guess is > that something else is triggering it - perl perhaps? Don't know, and ATM > don't know how to find out, or what to try next. :( Some educational history and points: /bin/[ is the same thing as /bin/test (one might be a hardlink, I can't remember). If you've ever seen an sh script, you'll see a lot of this: if [ x"$o" = x"hello" ]; then ... fi Which is identical to: if test x"$o" = x"hello"; then ... fi There's some important things to note about this, though. Many shells (such as bash) include their own internal version of test, which is wise because it saves on having to fork a /bin/[ or /bin/test process every time something wanted to run a comparison operation. test(1) describes the applicable comparison operators (=, !=, -gt, -le, etc.). > [: -le: argument expected This means something somewhere is doing: if [ val1 -le $val2 ]; then ... fi I'm willing to bet val2 is a variable which isn't being set prior to the test conditional being run, which would mean the test conditional would be expanded by the shell into this: if [ val1 -le ]; then ... fi Which is going to emit the error in question. To confirm that the problem is coming from a /bin/sh script (or something that actually uses /bin/[ or /bin/test, versus, say, a bash shell script which uses bash's internal [/test), we can do this: icarus$ /bin/sh # if [ 123 -le ]; then echo hi; fi [: -le: argument expected # if test 123 -le; then echo hi; fi test: -le: argument expected Note the difference if [ or test is used within bash: bash# if [ 123 -le ]; then echo hi; fi -bash: [: 123: unary operator expected bash# if test 123 -le; then echo hi; fi -bash: test: 123: unary operator expected What all this means: the error is being induced by a /bin/sh script of somekind. That said, the added fact that "make extract" causes this for you means that the error is coming from something within the ports framework, which means something in ports/Mk. This sort-of thing has happened in the past, and has occasionally turned out to be caused someone having some very bad typos in /etc/make.conf which broke all sorts of things. > make emits the above, as well as the following: > > configure.in:152: warning: AC_PROG_LEX invoked multiple times > ../../lib/autoconf/programs.m4:779: AC_DECL_YYTEXT is expanded from... > aclocal.m4:2080: PHP_PROG_LEX is expanded from... > configure.in:152: the top level Second time someone's told you -- this is normal based on the current autoconf framework in ports. I've complained about this to ale@ in the past, but was told "if it bothers you that much, fix it; it's harmless otherwise". And being as I have dealt with similar autoconf warnings in ports that *I* maintain, I can tell you that getting them to not emit such warnings is a real pain in the ass. > config.status: executing default commands > ===> Building for php5-5.2.5_1 > "Makefile", line 592: warning: duplicate script for target > "main/internal_functions.lo" ignored Also "normal". > -I/usr/ports/lang/php5/work/php-5.2.5/Zend-O2 -fno-strict-aliasing > -pipe -prefer-non-pic -c > /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/sapi_apache.c -o > sapi/apache/sapi_apache.lo > /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/sapi_apache.c: In function > 'apache_php_module_main': > /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/sapi_apache.c:44: error: > 'NOT_FOUND' undeclared (first use in this function) > /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/sapi_apache.c:44: error: > (Each undeclared identifier is reported only once > /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/sapi_apache.c:44: error: > for each function it appears in.) > *** Error code 1 Hmm, this looks like there could be two versions of Apache APR on your machine (one from the www/apache20 port, and possibly some other port installing something similar to devel/apr on the same box). This could also be induced by something broken in /etc/make.conf, but it's hard to tell. It's getting to the point where for someone to help you with this, they're going to need access to the machine. I can't reproduce this behaviour on any of my personal FreeBSD boxes, nor any of our production machines (running RELENG_6 and RELENG_7), and I haven't seen anyone else on this list able to reproduce the symptom either. -- | Jeremy Chadwickjdc a
Re: [: -le: argument expected
Hello Tom, and thank you for your reply. Quoting Tom Evans <[EMAIL PROTECTED]>: On Fri, 2008-02-01 at 07:42 -0800, Chris H. wrote: Hello Tom, and thank you for your thoughtful reply. I would have to assert that in my case, your assertions are also a bit moot. Would make deinstall apache2.0 && make install apache2.2 && make install php5 -DWITH_CGI=TRUE -DWITH_CLI=true -DWITH_APACHE=true accomplish a successful build? In fact, no. As the real problem at hand, is getting php5 to build the apache module (libphp5.so). :) On the other hand. Assuming a successfully built apache module; How large is the difference between the same modules in 1.2 vs 2.0 vs 2.2? How large is the difference in apache' reaction to calls made to apache, where these modules are involved? Does Apache 2.2 offer the -DWITH_MPM=threadpool? I couldn't find it. Thank you for your informative, and thoughtful reply. --Chris H HTH. I'm afraid I can't help too much with PHP, as I don't myself use PHP anywhere. I know other guys in the office do have PHP 5 working nicely with apache22 from ports though - I'd assume that the problem is with a system library, I may have missed the email with the actual error logs in it. When using PHP, it is important to use the prefork MPM. The other MPMs are all threaded, and not very many PHP extensions are thread safe. I'm not sure what the 'threadpool' MPM is - in 2.2 there is prefork, worker (which implements itself through a multi-process multi-thread model), and event, which is a specialized version of worker that uses a single dedicated thread to handle listening sockets and keep-alive sockets. We use the event MPM on our front end proxies (also marked as 'experimental', but this is (according to the dev I asked) as it doesn't support accept filters (and hence cannot handle SSL). Our proxies handle a large amount of web traffic, serving static files locally and reverse proxying dynamic requests to the appropriate backend webservers, running anything from custom 1.3 apache modules, PHP 5 served from prefork MPM apache 2.2 servers, and, in one unfortunate incidence, hand-rolled web servers. The event model works incredibly well at this task, with load averages never peeking above 0.05. I just checked the 2.0 modules page [1], and there is a 'threadpool' MPM there, listed as 'This MPM is a developer playground and highly experimental'! I think that even if you do get PHP5 to build with that, you will be disappointed as soon as you get some significant load, and will have a hell of a time debugging it. prefork MPM isn't sexy, but it does work with PHP. From [2]: We do not recommend using a threaded MPM in production with Apache2. Use the prefork MPM instead, or use Apache1. For information on why, read the related FAQ entry on using Apache2 with a threaded MPM I greatly appreciate your /very/ informative reply. All points well taken. If you have some error messages (or pointers to the emails I missed!) I'll take a looksie at them. Well, I decided that perhaps something might have been added that to ports since my last cvsup. Hoping that any addition might cure my current delemna. I wanted to sync up my ports database before hand. So ran a portsdb -uU. This - interestingly enough, resulted in both [: -le: argument expected, and [: -eq: argument expected being emitted /many/ times during the portsdb process. So, now I'm stumped. It is clear that it is /not/ specific to the php5-apache-module. But rather, something that is common to that, and other ports. It's clear that /bin/[ is the command complaining. But my guess is that something else is triggering it - perl perhaps? Don't know, and ATM don't know how to find out, or what to try next. :( Thank you again for taking the time to provide such an informative response. FWIW make extract emits the following: [: -le: argument expected [: -le: argument expected ===> Cleaning for php5-5.2.5_1 [: -le: argument expected make emits the above, as well as the following: configure.in:152: warning: AC_PROG_LEX invoked multiple times ../../lib/autoconf/programs.m4:779: AC_DECL_YYTEXT is expanded from... aclocal.m4:2080: PHP_PROG_LEX is expanded from... configure.in:152: the top level Thank you for using PHP. config.status: creating php5.spec config.status: creating main/build-defs.h config.status: creating scripts/phpize config.status: creating scripts/man1/phpize.1 config.status: creating scripts/php-config config.status: creating scripts/man1/php-config.1 config.status: creating sapi/cli/php.1 config.status: creating main/php_config.h config.status: executing default commands ===> Building for php5-5.2.5_1 "Makefile", line 592: warning: duplicate script for target "main/internal_functions.lo" ignored -I/usr/ports/lang/php5/work/php-5.2.5/Zend-O2 -fno-strict-aliasing -pipe -prefer-non-pic -c /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/sapi_apache.c -o sapi/apache/sapi_apache.lo /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/
Re: [: -le: argument expected
On Fri, 2008-02-01 at 07:42 -0800, Chris H. wrote: > Hello Tom, and thank you for your thoughtful reply. > > I would have to assert that in my case, your assertions are also a bit > moot. Would make deinstall apache2.0 && make install apache2.2 && > make install php5 -DWITH_CGI=TRUE -DWITH_CLI=true -DWITH_APACHE=true > accomplish a successful build? In fact, no. As the real problem at > hand, is getting php5 to build the apache module (libphp5.so). :) > > On the other hand. Assuming a successfully built apache module; > How large is the difference between the same modules in > 1.2 vs 2.0 vs 2.2? > How large is the difference in apache' reaction to calls made to > apache, where these modules are involved? > Does Apache 2.2 offer the -DWITH_MPM=threadpool? I couldn't find it. > > Thank you for your informative, and thoughtful reply. > > --Chris H HTH. I'm afraid I can't help too much with PHP, as I don't myself use PHP anywhere. I know other guys in the office do have PHP 5 working nicely with apache22 from ports though - I'd assume that the problem is with a system library, I may have missed the email with the actual error logs in it. When using PHP, it is important to use the prefork MPM. The other MPMs are all threaded, and not very many PHP extensions are thread safe. I'm not sure what the 'threadpool' MPM is - in 2.2 there is prefork, worker (which implements itself through a multi-process multi-thread model), and event, which is a specialized version of worker that uses a single dedicated thread to handle listening sockets and keep-alive sockets. We use the event MPM on our front end proxies (also marked as 'experimental', but this is (according to the dev I asked) as it doesn't support accept filters (and hence cannot handle SSL). Our proxies handle a large amount of web traffic, serving static files locally and reverse proxying dynamic requests to the appropriate backend webservers, running anything from custom 1.3 apache modules, PHP 5 served from prefork MPM apache 2.2 servers, and, in one unfortunate incidence, hand-rolled web servers. The event model works incredibly well at this task, with load averages never peeking above 0.05. I just checked the 2.0 modules page [1], and there is a 'threadpool' MPM there, listed as 'This MPM is a developer playground and highly experimental'! I think that even if you do get PHP5 to build with that, you will be disappointed as soon as you get some significant load, and will have a hell of a time debugging it. prefork MPM isn't sexy, but it does work with PHP. From [2]: We do not recommend using a threaded MPM in production with Apache2. Use the prefork MPM instead, or use Apache1. For information on why, read the related FAQ entry on using Apache2 with a threaded MPM If you have some error messages (or pointers to the emails I missed!) I'll take a looksie at them. Cheers Tom [1] http://httpd.apache.org/docs/2.0/mod/ [2] http://uk.php.net/manual/en/install.unix.apache2.php signature.asc Description: This is a digitally signed message part
Re: Minidumps in -STABLE and "smaller than physical memory"
On Thu, Jan 31, 2008 at 01:35:39PM +0100, Peter Holm wrote: > On Wed, Jan 30, 2008 at 08:06:40PM +0300, Ruslan Ermilov wrote: > > On Thu, Sep 21, 2006 at 05:16:36PM +0200, Peter Holm wrote: > > > On Thu, Sep 21, 2006 at 05:15:47PM +0400, Ruslan Ermilov wrote: > > > > On Thu, Sep 21, 2006 at 11:14:33AM +0100, Gavin Atkinson wrote: > > > > > On Thu, 2006-09-21 at 11:44 +0300, Dmitry Pryanishnikov wrote: > > > > > > Hello! > > > > > > > > > > > >I've noticed (with the 2-day old RELENG_6) that I still can't > > > > > > configure my > > > > > > 256Mb swap partition as a dump device for i386 machine with 1Gb RAM > > > > > > despite > > > > > > having minidumps enabled: > > > > > > > > > > > > [EMAIL PROTECTED] sysctl debug.minidump > > > > > > debug.minidump: 1 > > > > > > [EMAIL PROTECTED] dumpon -v /dev/ad0s3b > > > > > > /dev/ad0s3b is smaller than physical memory > > > > > > > > > > > > Am I correctly understand that minidumps should lift the restriction > > > > > > > > > > > > sizeof(dumpdev) >= sizeof(RAM) > > > > > > > > > > Yes. > > > > > > > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/dumpon/dumpon.c.diff?r1=1.22&r2=1.23 > > > > > needs to be MFC'd. > > > > > > > > > I sent an MFC request to [EMAIL PROTECTED] > > > > > > > > > > >From time to time I've had problems with minidumps on HEAD. Calling > > > doadump() seems to work ok, but after a reset there's no dump. I > > > haven't had time to test this systematically. Has anybody else seen > > > this problem? > > > > > I think this was the same problem as was diagnosed (minidumps + amd64 + > > SMP). Though it's not fixed yet, it's understood and its damage is > > avoided. > > > No, this was and is i386. After changing "doadump;reset" to > doadump;continue" it would seem that the dumps has a higher chance > of making it to the disk. > "call doadump" and the "continue" renders my systems unusable due to a regression made in kern_shutdown.c,v 1.122. I'm now living with this patch: %%% Index: kern_shutdown.c === RCS file: /home/ncvs/src/sys/kern/kern_shutdown.c,v retrieving revision 1.189 diff -u -p -r1.189 kern_shutdown.c --- kern_shutdown.c 28 Jan 2008 19:04:07 - 1.189 +++ kern_shutdown.c 1 Feb 2008 15:40:38 - @@ -249,6 +249,7 @@ doadump(void) else #endif dumpsys(&dumper); + dumping--; } static int %%% Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [: -le: argument expected
Hello Tom, and thank you for your thoughtful reply.
Quoting Tom Evans <[EMAIL PROTECTED]>:
On Thu, 2008-01-31 at 18:41 -0800, Chris H. wrote:
The cause is in the file: lang/php5/files/patch-Zend_zend_list.c
It accounts for all /3/ errors emitted during the initial portion
of the make process. The lines are as follows:
--- Zend/zend_list.c.orig 2007-01-01 10:35:46.0 +0100
+++ Zend/zend_list.c2008-01-29 11:05:14.0 +0100
@@ -48,7 +48,7 @@
return index;
}
-ZEND_API int _zend_list_delete(int id TSRMLS_DC)
+ZEND_API int _zend_list_delete(ulong id TSRMLS_DC)
{
*** zend_rsrc_list_entry *le;
@@ -65,7 +65,7 @@
}
-ZEND_API void *_zend_list_find(int id, int *type TSRMLS_DC)
+ZEND_API void *_zend_list_find(ulong id, int *type TSRMLS_DC)
{
*** zend_rsrc_list_entry *le;
@@ -78,7 +78,7 @@
}
}
-ZEND_API int _zend_list_addref(int id TSRMLS_DC)
+ZEND_API int _zend_list_addref(ulong id TSRMLS_DC)
{
*** zend_rsrc_list_entry *le;
(highlighted with three asterisks for clarity).
While it's nice that I found them. I'm not sure what to do to
make them correct. Any thoughts? Should I simply send-pr -
php5-apache-module build failure (lang/php5/files/patch-Zend_zend_list.c)?
I doubt that patch is the issue. The error comes from a malformed call
to /bin/test (or /bin/[ ). The -le test tests two numbers to see if the
first is less than the second.
With correct usage:
/bin/[ 5 -le 10 ] && echo "first is less"
first is less
With incorrect usage
/bin/[ 5 -le ] && echo "first is less"
[: -le: argument expected
The patch you have shown changes the id of a zend_rsrc_list_entry to be
an unsigned long rather than an int, the fact that the variable name
(which does not get updated, modified or altered) is called 'le' for
'list element' is neither here nor there.
Quite so. I eventually figured that out. But by then had been up for far
too long, and decided to get some sleep, and reply in the morning. Good
morning. :)
I would thoroughly recommend using apache 2.2 with the prefork MPM if
you wish to run PHP. Your arguments for choosing 2.0 over 2.2 are
spurious, as there are virtually no difference in conf directives,
server layout or security, where as apache 2.2 is well maintained and
secure. Apache 2.2 has many notable improvements, especially in
performance and proxying. See [1].
The real hint is on apache.org [2] - 'We consider Apache 2.2 to be the
best available version at the time of this release. We offer Apache
2.0.63 as the best legacy version of Apache 2.0 available. Users should
first consider upgrading to the current release of Apache 2.2 instead.'
I would have to assert that in my case, your assertions are also a bit
moot. Would make deinstall apache2.0 && make install apache2.2 &&
make install php5 -DWITH_CGI=TRUE -DWITH_CLI=true -DWITH_APACHE=true
accomplish a successful build? In fact, no. As the real problem at
hand, is getting php5 to build the apache module (libphp5.so). :)
On the other hand. Assuming a successfully built apache module;
How large is the difference between the same modules in
1.2 vs 2.0 vs 2.2?
How large is the difference in apache' reaction to calls made to
apache, where these modules are involved?
Does Apache 2.2 offer the -DWITH_MPM=threadpool? I couldn't find it.
Thank you for your informative, and thoughtful reply.
--Chris H
On the other hand, your server, your rules. :)
Tom
[1] http://httpd.apache.org/docs/2.2/new_features_2_2.html
[2] http://www.apache.org/dist/httpd/Announcement2.0.html
--
panic: kernel trap (ignored)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Frequent USB mouse disconnections under load with RELENG_7
On Fri, Feb 01, 2008 at 10:00:11PM +1030, Wayne Sierke wrote: > - I've also just noticed that I'm getting these messages on startup > under 7.x: > > kernel: Starting devd. > kernel: Starting ums0 moused: > kernel: Starting default moused: > moused: unable to open /dev/ums0: Device busy > > but I can't now recall whether I was seeing those under 6.x. Has devd > changed with 7.x? I've got a feeling that I'd tried to get devd in 6.x > to handle the USB mouse on startup, but that I'd found it necessary to > configure moused explicitly (i.e. with moused_port) in rc.conf as listed > below. However my memory of it now is hazy at best. In any case, > disconnections aside, I've not noticed any change in mouse behaviour > since moving to 7.x either in console or xorg. > > moused_enable="YES" > moused_port="/dev/ums0" I think this is what's happening here: * kernel starts * usb stack loads, finds a USB mouse, attaches it to ums0 * attachment tells devd "hey, theres a /dev/ums0 device that just attached" * /etc/devd.conf automatically spawns moused, which attaches to the /dev/ums0 device * rc scripts begin * moused_enable="yes" is detected, thus moused is run manually against /dev/ums0 * moused is already running from when devd spawned it, which is why /dev/ums0 is "Device busy" I would recommend removing the moused_* stuff in your rc.conf and let devd take care of it, or, consider editing /etc/devd.conf and removing the /dev/umsX detection which runs moused. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kld regression
On Thursday 31 January 2008 16:05:57 Andriy Gapon wrote: > on 31/01/2008 14:39 Andriy Gapon said the following: > > on 31/01/2008 13:07 John Baldwin said the following: > >> On Wednesday 30 January 2008 12:39:14 pm Andriy Gapon wrote: > >>> The problem is as follows: > >>> 1. put udf_load="YES" in loader.conf > >>> 2. you can mount and unmount udf filesystems > >>> 3. you can kldunload udf if no udf filesystems are mounted > >>> 4. now mount udf fs while udf.ko is unloaded > >>> 5. udf is auto loaded and fs is mounted > >>> 6. unmount fs > >>> 7. try to kldunload udf > >>> kldunload: can't unload file: Device busy > >>> kernel message: kldunload: attempt to unload file that was loaded by > >>> the kernel > >>> > >>> Yeah, it was loaded by kernel indeed, but WTF - what is the difference > >>> from manual/loader.conf loading and why I can not manage my modules as > >>> I wish? > >> > >> Hmm, the relevant code (vfs_init.c) hasn't changed in 6.x since 6.0. > >> There were some changes in 7.0, but this should work in both branches. > >> What is the previous release that this worked on? > > > > Maybe I was wrong when I called this regression, but this was very > > surprising behavior for me. And in 5.X I did a lot of udf > > debugging/experimenting and never encountered such a problem. Maybe I > > always did kldload before mount, I can't tell now. > > Anyway, this seems like an annoyance at the very least, pinning a kernel > > module without any important reasons. > > Hmm, I found one difference with previous setups: in step 1 I also have > udf_iconv_load="YES" and udf_iconv.ko module is what seems to prevent > udf.ko from unloading in step 7. I can actually unload udf_iconv and > then I am able again to unload udf. > > Still don't understand what is a big difference here. > > And if I had UDF_ICONV built into kernel then I wouldn't have this > work-around. The way I understand it, there are two different things: 1. kldload will load "child" modules on demand, but kldunload does not attempt to unload any other modules than the one you ask for. I don't think it's material whether the kldload was done via the loader (before the kernel kmod gets loaded, kernel is also a kmod), or after. It's also possible to have modules who need to access the filesystem (other than /boot partition) when kldloaded, and such modules can obviously not be loaded via the loader at all. 2. There may be modules (such as bktr) that allocate memory in kernel space. These can not be unloaded, because that memory may not be deallocated while the kernel is up and running (the latter is my assumption). Anyhow, unless you're very tight on RAM, it hardly matters if you have some kmods loaded but left unused. Kmods are small, typically 10-100 kB. If all your kmods are built into the kernel, you have the footprint of all of them and you can't disable any at runtime. Feel free to correct me, anyone, if you think the above is not correct or complete. Dan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3 nfe: strange behavior after hand
on 01/02/2008 15:42 Andriy Gapon said the following: > on 01/02/2008 14:36 Pyun YongHyeon said the following: >> After applying attached patch and let me know the output of >> "devid : xxx, revid : xxx, pwr = xxx". It would be even better >> if you can show me the above message for working/non-working case. >> >> > > Applied the patch with correction to actually print rev instead of dev > for the second time :-) > This is in working case: > devid : 269, revid : a3, pwr = 0003 A clarification: I just applied the patch, recompiled and re-loaded the module. There was no reboot/poweroff/reset in between. > Will wait for the non-working situation. > -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Job Offer
LOL!
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Storistes de France
Sent: Friday, February 01, 2008 6:56 AM
To: [EMAIL PROTECTED]
Subject: Job Offer
Storistes de France is currently looking for English Corrections
Officer. We currently need three english corrections officer, someone
who can edit our customer service messages and correct errors in our
english customer service messages.
This is an opportunity is open to anyone who know how to write english
without errors and someone who can correct mistakes/errors in English
Language and we also need someone who will be working as our agent.
You are required to work for one hour daily by checking your email for
our customer service message and edit it because of correction and
other english errors.
WHAT WE EXPECT FROM A CANDIDATE:
- Applicants must be living in USA,Canada or Australia.
- Applicants must be high school or vocational high school graduates.
- Above 18 years old.
- Confident computer skills.
- Applicants must be avaliable to check his/her e-mail messages
between 7am - 12noon.
- Good working relationship with new people.
- Required to be online at least 1-3hours and 2 days per week.
WHAT WE OFFER
- Speedy career progress
- High earnings plus performance results bonus.
- A Personal Toshiba Laptop.
- Weekly payment of $250.00.
- Monthly Salary : Starting from $10,000 - $55,000.00.
To apply please send your CV/Resume to our email:
[EMAIL PROTECTED]
Milla Cole
Storistes de France
Website: http://www.storistes-de-france.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
__ NOD32 2842 (20080201) Information __
This message was checked by NOD32 antivirus system.
http://www.eset.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3 nfe: strange behavior after hand
on 01/02/2008 14:36 Pyun YongHyeon said the following: > > After applying attached patch and let me know the output of > "devid : xxx, revid : xxx, pwr = xxx". It would be even better > if you can show me the above message for working/non-working case. > > Applied the patch with correction to actually print rev instead of dev for the second time :-) This is in working case: devid : 269, revid : a3, pwr = 0003 Will wait for the non-working situation. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3 nfe: strange behavior after hand
On Fri, Feb 01, 2008 at 01:35:57PM +0200, Andriy Gapon wrote:
>
> I am using nfe on 6.3 amd63 system with the code from here:
> http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html
>
> Everything is OK except for one small, but annoying problem. Sometimes
> when my system hangs and I have to use reset button, nfe stops working
> after reboot. ifconfig shows proper status and medium, there are no
> kernel error/debug messages, on the surface everything seems good. But
> if I try to ping a machine connected to the same switch I get "host
> down" responses. So, no network at all. Unloading and reloading if_nfe
> module doesn't help, various ifconfig re-configurations do not help too.
> Although, if I do power off and then boot, everything is perfect again.
>
> Until a couple of weeks ago I used 6.2 amd64 and nve (patched to
> recognize pci id of this card) and I never had such a problem.
>
> To un-enlightened me it seems like some resetting/re-initialization of
> the card is not done properly by nfe.
>
> Additional info.
> dmesg:
> nfe0: port 0xc800-0xc807
> mem 0xfe02b000-0xfe02bfff irq 23 at device 20.0 on pci0
> miibus0: on nfe0
> e1000phy0: on miibus0
> e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
> 1000baseTX-FDX, auto
> nfe0: Ethernet address: 00:18:f3:d4:43:1e
> nfe0: [FAST]
>
> ifconfig (output is the same in both working and non-working cases):
> nfe0: flags=8843 mtu 1500
> options=8
> inet 10.2.1.87 netmask 0xfc00 broadcast 10.2.3.255
> ether 00:18:f3:d4:43:1e
> media: Ethernet autoselect (1000baseTX )
> status: active
>
> pciconf:
> [EMAIL PROTECTED]:20:0: class=0x068000 card=0x816a1043 chip=0x026910de
> rev=0xa3
> hdr=0x00
> vendor = 'Nvidia Corp'
> device = 'MCP51 Network Bus Enumerator'
> class = bridge
>
>
> P.S. as always with network issues, I understand that it may be not so
> simple, e.g. some interaction between the card and the switch, etc.
>
After applying attached patch and let me know the output of
"devid : xxx, revid : xxx, pwr = xxx". It would be even better
if you can show me the above message for working/non-working case.
--
Regards,
Pyun YongHyeon
--- if_nfe.c.orig 2008-01-18 10:50:48.0 +0900
+++ if_nfe.c2008-02-01 21:30:27.0 +0900
@@ -770,6 +770,10 @@
DELAY(100);
NFE_WRITE(sc, NFE_RXTX_CTL, NFE_RXTX_BIT2);
pwr = NFE_READ(sc, NFE_PWR2_CTL);
+#if 1
+ printf("devid : %x, revid : %x, pwr = %08x\n",
+ sc->nfe_devid, sc->nfe_devid, pwr);
+#endif
pwr &= ~NFE_PWR2_WAKEUP_MASK;
if (sc->nfe_revid >= 0xa3 &&
(sc->nfe_devid == PCI_PRODUCT_NVIDIA_NFORCE430_LAN1 ||
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Job Offer
Storistes de France is currently looking for English Corrections
Officer. We currently need three english corrections officer, someone
who can edit our customer service messages and correct errors in our
english customer service messages.
This is an opportunity is open to anyone who know how to write english
without errors and someone who can correct mistakes/errors in English
Language and we also need someone who will be working as our agent.
You are required to work for one hour daily by checking your email for
our customer service message and edit it because of correction and
other english errors.
WHAT WE EXPECT FROM A CANDIDATE:
- Applicants must be living in USA,Canada or Australia.
- Applicants must be high school or vocational high school graduates.
- Above 18 years old.
- Confident computer skills.
- Applicants must be avaliable to check his/her e-mail messages
between 7am - 12noon.
- Good working relationship with new people.
- Required to be online at least 1-3hours and 2 days per week.
WHAT WE OFFER
- Speedy career progress
- High earnings plus performance results bonus.
- A Personal Toshiba Laptop.
- Weekly payment of $250.00.
- Monthly Salary : Starting from $10,000 - $55,000.00.
To apply please send your CV/Resume to our email:
[EMAIL PROTECTED]
Milla Cole
Storistes de France
Website: http://www.storistes-de-france.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.3 nfe: strange behavior after hand
I am using nfe on 6.3 amd63 system with the code from here: http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html Everything is OK except for one small, but annoying problem. Sometimes when my system hangs and I have to use reset button, nfe stops working after reboot. ifconfig shows proper status and medium, there are no kernel error/debug messages, on the surface everything seems good. But if I try to ping a machine connected to the same switch I get "host down" responses. So, no network at all. Unloading and reloading if_nfe module doesn't help, various ifconfig re-configurations do not help too. Although, if I do power off and then boot, everything is perfect again. Until a couple of weeks ago I used 6.2 amd64 and nve (patched to recognize pci id of this card) and I never had such a problem. To un-enlightened me it seems like some resetting/re-initialization of the card is not done properly by nfe. Additional info. dmesg: nfe0: port 0xc800-0xc807 mem 0xfe02b000-0xfe02bfff irq 23 at device 20.0 on pci0 miibus0: on nfe0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe0: Ethernet address: 00:18:f3:d4:43:1e nfe0: [FAST] ifconfig (output is the same in both working and non-working cases): nfe0: flags=8843 mtu 1500 options=8 inet 10.2.1.87 netmask 0xfc00 broadcast 10.2.3.255 ether 00:18:f3:d4:43:1e media: Ethernet autoselect (1000baseTX ) status: active pciconf: [EMAIL PROTECTED]:20:0: class=0x068000 card=0x816a1043 chip=0x026910de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Network Bus Enumerator' class = bridge P.S. as always with network issues, I understand that it may be not so simple, e.g. some interaction between the card and the switch, etc. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Frequent USB mouse disconnections under load with RELENG_7
On Fri, 2008-01-25 at 01:59 +1030, Wayne Sierke wrote: > I'm getting a lot of USB mouse disconnects on RELENG_7. I wondered > whether they might have been due to running with a KTR-enabled kernel > but in just the last 7 hours I've been running on stock GENERIC and > they're still happening. > > I get this set of messages for each disconnect: > Jan 24 15:40:13 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) > disconnected > Jan 24 15:40:13 predator-ii kernel: ums0: detached > Jan 24 15:40:14 predator-ii root: Unknown USB device: vendor 0x046d product > 0xc025 bus uhub0 > Jan 24 15:40:14 predator-ii kernel: ums0: class 0/0, rev 2.00/98.02, addr 2> on uhub0 > Jan 24 15:40:14 predator-ii kernel: ums0: 8 buttons and Z dir. > > Rarely, twice that I can recall over the course of a couple of weeks, > the mouse fails to reconnect but comes good with a physical > disconnect/reconnect. > > Here's a recent (condensed) history running with stock GENERIC: > > Jan 24 15:47:04 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) > disconnected > Jan 24 16:15:53 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) > disconnected > Jan 24 16:21:46 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) > disconnected > Jan 24 16:25:42 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) > disconnected > Jan 24 16:26:17 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) > disconnected > Jan 24 16:37:01 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) > disconnected > Jan 24 16:39:22 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) > disconnected > Jan 24 16:56:28 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) > disconnected > Jan 24 17:06:36 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) > disconnected > Jan 24 19:20:58 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) > disconnected > Jan 24 21:17:30 predator-ii kernel: ums0: at uhub0 port 2 (addr 2) > disconnected > > Sometime during 16:00-17:00 I was running a couple of cpu-intensive > tasks (glxgears plus for brief periods a cpu-intensive script). I wasn't > at the computer much during the 17:30-21:00 interval. So it seems like > this gets exacerbated by high cpu load. I counted another 12 in the hour > following on from the above list. > > I don't recall seeing these at all under RELENG_6. If they ever did > occur they certainly weren't anywhere nearly as prolific. > > A copy of /var/log/messages from boot until the first disconnection is > attached. Any ideas? Just a follow-up and bump as I recently realised that the listserver rejected the attachment on the previous message because evolution set its MIME type to text/x-log. Some other information and observations that might help: - the mouse is a wired Logitech MX-500 - it's more prevalent under high cpu load - it happens when the computer is unattended, so it's not tied in with active use of the mouse - I've also just noticed that I'm getting these messages on startup under 7.x: kernel: Starting devd. kernel: Starting ums0 moused: kernel: Starting default moused: moused: unable to open /dev/ums0: Device busy but I can't now recall whether I was seeing those under 6.x. Has devd changed with 7.x? I've got a feeling that I'd tried to get devd in 6.x to handle the USB mouse on startup, but that I'd found it necessary to configure moused explicitly (i.e. with moused_port) in rc.conf as listed below. However my memory of it now is hazy at best. In any case, disconnections aside, I've not noticed any change in mouse behaviour since moving to 7.x either in console or xorg. moused_enable="YES" moused_port="/dev/ums0" I'm getting quite anxious for some pointers to resolving this as it's both highly annoying and is also frustrating my efforts in pursuing some of the other performance problems I've written about. Wayne kernel boot file is /boot/kernelktr0x2000/kernel Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-PRERELEASE #1: Fri Jan 25 01:08:47 CST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC-KTR-0x2000 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2411.61-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff Features2=0x4400 real memory = 1610547200 (1535 MB) avail memory = 1551495168 (1479 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Jan 25 2008 01:08:23) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 p4tcc
Re: [: -le: argument expected
On Thu, 2008-01-31 at 18:41 -0800, Chris H. wrote:
>
> The cause is in the file: lang/php5/files/patch-Zend_zend_list.c
>
> It accounts for all /3/ errors emitted during the initial portion
> of the make process. The lines are as follows:
>
> --- Zend/zend_list.c.orig 2007-01-01 10:35:46.0 +0100
> +++ Zend/zend_list.c 2008-01-29 11:05:14.0 +0100
> @@ -48,7 +48,7 @@
> return index;
> }
>
> -ZEND_API int _zend_list_delete(int id TSRMLS_DC)
> +ZEND_API int _zend_list_delete(ulong id TSRMLS_DC)
> {
> *** zend_rsrc_list_entry *le;
>
> @@ -65,7 +65,7 @@
> }
>
>
> -ZEND_API void *_zend_list_find(int id, int *type TSRMLS_DC)
> +ZEND_API void *_zend_list_find(ulong id, int *type TSRMLS_DC)
> {
> *** zend_rsrc_list_entry *le;
>
> @@ -78,7 +78,7 @@
> }
> }
>
> -ZEND_API int _zend_list_addref(int id TSRMLS_DC)
> +ZEND_API int _zend_list_addref(ulong id TSRMLS_DC)
> {
> *** zend_rsrc_list_entry *le;
>
> (highlighted with three asterisks for clarity).
>
> While it's nice that I found them. I'm not sure what to do to
> make them correct. Any thoughts? Should I simply send-pr -
> php5-apache-module build failure (lang/php5/files/patch-Zend_zend_list.c)?
I doubt that patch is the issue. The error comes from a malformed call
to /bin/test (or /bin/[ ). The -le test tests two numbers to see if the
first is less than the second.
With correct usage:
/bin/[ 5 -le 10 ] && echo "first is less"
first is less
With incorrect usage
/bin/[ 5 -le ] && echo "first is less"
[: -le: argument expected
The patch you have shown changes the id of a zend_rsrc_list_entry to be
an unsigned long rather than an int, the fact that the variable name
(which does not get updated, modified or altered) is called 'le' for
'list element' is neither here nor there.
I would thoroughly recommend using apache 2.2 with the prefork MPM if
you wish to run PHP. Your arguments for choosing 2.0 over 2.2 are
spurious, as there are virtually no difference in conf directives,
server layout or security, where as apache 2.2 is well maintained and
secure. Apache 2.2 has many notable improvements, especially in
performance and proxying. See [1].
The real hint is on apache.org [2] - 'We consider Apache 2.2 to be the
best available version at the time of this release. We offer Apache
2.0.63 as the best legacy version of Apache 2.0 available. Users should
first consider upgrading to the current release of Apache 2.2 instead.'
On the other hand, your server, your rules. :)
Tom
[1] http://httpd.apache.org/docs/2.2/new_features_2_2.html
[2] http://www.apache.org/dist/httpd/Announcement2.0.html
signature.asc
Description: This is a digitally signed message part
Re: mouse problems [A4 Tech OP-3D]
on 01/02/2008 11:38 Vojtech Pavlik said the following: > On Fri, Feb 01, 2008 at 11:35:33AM +0200, Andriy Gapon wrote: >> I did the same in FreeBSD psm.c, i.e., added a call to >> enable_msintelli() at the very start of enable_msexplorer(). And voilà - >> everything is perfect, correct ID is returned, probing succeeds, the >> mouse works great. >> >> I think that this change is quite safe to make in FreeBSD, because with >> Linux user-base we can be 99% percent sure that this change won't break >> anything. > > It is even correct: A mouse isn't required to be able to jump straight > into the Explorer mode, it is supposed to always go through the > IntelliMouse mode. > Vojtech, thank you for the help! -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
src.conf, WITHOUT-knobs and nanobsd
Hi folks, I have just noticed that the NO-knobs were renamed into WITHOUT-knobs and moved from make.conf into src.conf. Can anyone tell me if (and how) this interacts with nanobsd, which uses the following variables: --- # Options to put in make.conf during buildworld only CONF_BUILD=' ' # Options to put in make.conf during installworld only CONF_INSTALL=' ' # Options to put in make.conf during both build- & installworld. CONF_WORLD=' ' --- Can I put the new WITHOUT-knobs there like I used to do with the NO-knobs before, or is this broken, because the definitions will still go into make.conf instead of the new src.conf? cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mouse problems [A4 Tech OP-3D]
On Fri, Feb 01, 2008 at 11:35:33AM +0200, Andriy Gapon wrote:
> on 30/01/2008 18:45 Vojtech Pavlik said the following:
> > On Wed, Jan 30, 2008 at 05:30:02PM +0200, Andriy Gapon wrote:
> [snip]
> >> I see that Linux driver and FreeBSD driver are (mostly) equivalent in
> >> "IntelliMouse Explorer" detection. I wonder if Linux handles this mouse
> >> well, and if yes, then how.
> >
> > I don't know, honestly, I never tried this specific mouse. A4-Tech is
> > infamous of producing mice with all kinds of strange quirks and bugs.
>
> But not this time :)
> I tried to boot Knoppix live CD and it recognized the mouse as having
> ImExPS/2 protocol which the same as I found by try-and-error.
>
> I compared FreeBSD and Linux sources more thoroughly and found the
> following:
> http://lxr.linux.no/linux+v2.6.24/drivers/input/mouse/psmouse-base.c#L464
> static int im_explorer_detect(struct psmouse *psmouse, int set_properties)
> {
> struct ps2dev *ps2dev = &psmouse->ps2dev;
> unsigned char param[2];
>
> intellimouse_detect(psmouse, 0);
>
> I.e., first thing the explorer probe does is massaging a mouse with
> IntelliMouse magic commands.
>
> I did the same in FreeBSD psm.c, i.e., added a call to
> enable_msintelli() at the very start of enable_msexplorer(). And voilà -
> everything is perfect, correct ID is returned, probing succeeds, the
> mouse works great.
>
> I think that this change is quite safe to make in FreeBSD, because with
> Linux user-base we can be 99% percent sure that this change won't break
> anything.
It is even correct: A mouse isn't required to be able to jump straight
into the Explorer mode, it is supposed to always go through the
IntelliMouse mode.
--
Vojtech Pavlik
Director SuSE Labs
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mouse problems [A4 Tech OP-3D]
on 30/01/2008 18:45 Vojtech Pavlik said the following:
> On Wed, Jan 30, 2008 at 05:30:02PM +0200, Andriy Gapon wrote:
[snip]
>> I see that Linux driver and FreeBSD driver are (mostly) equivalent in
>> "IntelliMouse Explorer" detection. I wonder if Linux handles this mouse
>> well, and if yes, then how.
>
> I don't know, honestly, I never tried this specific mouse. A4-Tech is
> infamous of producing mice with all kinds of strange quirks and bugs.
But not this time :)
I tried to boot Knoppix live CD and it recognized the mouse as having
ImExPS/2 protocol which the same as I found by try-and-error.
I compared FreeBSD and Linux sources more thoroughly and found the
following:
http://lxr.linux.no/linux+v2.6.24/drivers/input/mouse/psmouse-base.c#L464
static int im_explorer_detect(struct psmouse *psmouse, int set_properties)
{
struct ps2dev *ps2dev = &psmouse->ps2dev;
unsigned char param[2];
intellimouse_detect(psmouse, 0);
I.e., first thing the explorer probe does is massaging a mouse with
IntelliMouse magic commands.
I did the same in FreeBSD psm.c, i.e., added a call to
enable_msintelli() at the very start of enable_msexplorer(). And voilà -
everything is perfect, correct ID is returned, probing succeeds, the
mouse works great.
I think that this change is quite safe to make in FreeBSD, because with
Linux user-base we can be 99% percent sure that this change won't break
anything.
>> on 25/01/2008 14:35 Andriy Gapon said the following:
>>> I've recently got a cheap PS/2 mouse A4 Tech OP-3D:
>>> http://www.a4tech.com/EN/product2.asp?CID=114&SCID=115&MNO=OP-3D
>>>
>>> It looks like your regular mouse with a combined
>>> middle-button/scroll-wheel. The only unusual feature is an additional
>>> button for "double-click" - I am not sure if it's simulated within the
>>> mouse itself or if it is reported to controller/driver.
>>>
>>> There is a problem with this mouse though: if I don't do anything
>>> special then this mouse acts very erratically and misbehaves all it can
>>> - movements are ignored or reported as button clicks, button clicks get
>>> reported as movements or clicks of different buttons, etc.
>>> One cure that I initially found was to kill moused, disconnect and
>>> reconnect the mouse and restart moused, after that moused worked well.
>>> Then, I found out that I could achieve the same if I specify 0x200 flag
>>> (no id probing).
>>> Judging from verbose dmesg the mouse is detected as a generic ps/2 mouse
>>> with or without this flag, there is no difference whatsoever. So it
>>> seems that probing for various mouse models somehow hoses this mouse.
>>>
>>> Question #1: maybe some kind of additional mouse reset should be
>>> performed after all probes failed and we settle on generic?
>>>
>>> Well, while flag 0x200 makes the mouse behave reasonably, it seems that
>>> the presence of the wheel is not detected (or mouse is configured to
>>> ignore it?), so I can not use it.
>>>
>>> Question #2: what are the further steps to debug this issue so that this
>>> mouse is properly recognized? I really would like to get the wheel working.
>>>
>>> I can provide any additional information needed.
>>> Thank you.
>>>
>>
>> --
>> Andriy Gapon
>>
>
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
