Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
On Thu, Jun 12, 2008 at 02:45:21PM +0930, Daniel O'Connor wrote: On Thu, 12 Jun 2008, Jim Pingle wrote: I need to see if I can improve the script any (suggestions are most welcome) then open a PR to see if it -- or logic like it -- can be included in the php-extensions meta port. Adding the script to the port seems like the way to go (baring an upstream fix but it seems like a difficult problem to solve). Unfortunately it doesn't help me :( If I disable everything except either pgsql or mhash (either separately or together) Apache crashes with.. #0 0x28ad6d40 in ?? () #1 0x281c6f2e in _pthread_main_np () from /lib/libc.so.7 #2 0x2819fa0c in puts () from /lib/libc.so.7 #3 0x281a0177 in gethostbyname () from /lib/libc.so.7 #4 0x08069a12 in ap_get_local_host () #5 0x08068b9c in ap_fini_vhost_config () #6 0x0805639c in ap_read_config () #7 0x0805f133 in standalone_main () #8 0x08060c1f in main () I don't understand why gethostbyname() would call puts() - and why that would then crash! I can't explain why it's calling puts() directly either. Bad RAM could cause something bizarre like this, or a corrupt/broken binary. The libc code I'm looking at (src/lib/libc/net/gethostnameadr.c and gethostbydns.c) don't call puts) don't appear to call puts() directly. Of course, there may be macros used which do this. There are some places in the resolver code where printing to stdout or stderr can occur. I'd expect to see a longer stack trace (meaning more functions between gethostbyname() and puts()) if that were the case, though. There's a decent document on how to debug httpd below. You'll need to start httpd with -X or with MaxClients 1, to keep it from forking. You can do that through gdb if you want, or (what I prefer, since I'm not very good with gdb) use truss. http://httpd.apache.org/dev/debugging.html If you go the truss route, be sure to use -a -s 4096. You'd be able to see what actual string is being output via puts(), assuming it gets as far as to start writing data to the fd. -- | 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: FreeBSD 7.0 Stable and the CP2101 driver
2008/6/11 Dennis Flynn [EMAIL PROTECTED]: [trim] I tried installing the update, e.g. freebsd-update -r 7.0-STABLE fetch, then freebsd-update -r 7.0-STABLE upgrade. Seemed to work. But I do not seem to have the device driver loaded when I plug in the USB device. I get the folowwing in the messages log: Jun 10 16:48:02 wx kernel: ugen0: Silicon Labs CP2102 USB to UART Bridge Controller, class 0/0, rev 1.10/1.00, addr 2 on uhub0 But I don't see a device that I think I should see, like /dev/ttyU0. If I do a uname -a I see the following: FreeBSD wx.dennis-flynn.net 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 That doesn't seem right to me. Shouldn't I see something like 7.0-RELEASE-p1 or 7.0-STABLE? Did I do something wrong in my update to RELEASE? How do I know if I'm running the STABLE kernel with the driver I want? How can I tell if the driver (uslcom) is there and/or loaded? uslcom(4) appeared somewhere in 7.0-STABLE in GENERIC, and you are running 7.0-RELEASE, that is older. freebsd-update works only with releases (plus sec.patches), and 7.0-STABLE is not a release (obviously because you cannot definitely say to what date it corresponds). So you should update it to STABLE manually or wait until 7.1 is out. wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: broken re(4)
On Thu, 12 Jun 2008 12:22:28 +0900 Pyun YongHyeon [EMAIL PROTECTED] wrote about Re: broken re(4): PY Before checking performance of network controller you had to rule PY out other factors like disk I/O. Use one of benchmark programs in PY ports/benchmark. I already did simple benchmarking by using dd if=/dev/zero of=file which gave me several 10s of MByte/s under all circumstances. Can you recommend one of the benchmarking programs for more detailed testing? 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: broken re(4)
On Thu, Jun 12, 2008 at 08:58:10AM +0200, Gerrit K?hn wrote: On Thu, 12 Jun 2008 12:22:28 +0900 Pyun YongHyeon [EMAIL PROTECTED] wrote about Re: broken re(4): PY Before checking performance of network controller you had to rule PY out other factors like disk I/O. Use one of benchmark programs in PY ports/benchmark. I already did simple benchmarking by using dd if=/dev/zero of=file which gave me several 10s of MByte/s under all circumstances. Can you recommend one of the benchmarking programs for more detailed testing? Try netperf or iperf in ports/benchmark. cu Gerrit -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
On Thu, 12 Jun 2008, Jeremy Chadwick wrote: I don't understand why gethostbyname() would call puts() - and why that would then crash! I can't explain why it's calling puts() directly either. Bad RAM could cause something bizarre like this, or a corrupt/broken binary. Yeah.. I have rebuilt lots of stuff, although not libc. This machine has build world, kernel, KDE, etc.. I am pretty sure the hardware is OK as none of the builds had an issue. The libc code I'm looking at (src/lib/libc/net/gethostnameadr.c and gethostbydns.c) don't call puts) don't appear to call puts() directly. Of course, there may be macros used which do this. I had a look - there certainly isn't anywhere obvious it's hapening. I guess the only thing now is to rebuild with debugging. There are some places in the resolver code where printing to stdout or stderr can occur. I'd expect to see a longer stack trace (meaning more functions between gethostbyname() and puts()) if that were the case, though. There's a decent document on how to debug httpd below. You'll need to start httpd with -X or with MaxClients 1, to keep it from forking. You can do that through gdb if you want, or (what I prefer, since I'm not very good with gdb) use truss. OK thanks. http://httpd.apache.org/dev/debugging.html If you go the truss route, be sure to use -a -s 4096. You'd be able to see what actual string is being output via puts(), assuming it gets as far as to start writing data to the fd. Hmm I had a go with gdb but it doesn't work properly.. I got this.. [midget 16:33] /tmp/work/usr/ports/www/apache13-modssl/work/apache_1.3.41 sudo gdb src/httpd Password: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... (gdb) run -X Starting program: /data/tmp/work/usr/ports/www/apache13-modssl/work/apache_1.3.41/src/httpd -X [New LWP 100212] [New Thread 0x819d300 (LWP 100212)] [New LWP 100212] suspend error: generic error [Switching to LWP 100212] Stopped due to shared library event (gdb) info thread Cannot find new threads: generic error (gdb) bt #0 0x2807fda0 in r_debug_state () from /libexec/ld-elf.so.1 #1 0x2808367d in dlclose () from /libexec/ld-elf.so.1 #2 0x28706164 in zend_hash_apply_deleter () from /usr/local/libexec/apache/libphp5.so #3 0x287063a8 in zend_hash_graceful_reverse_destroy () from /usr/local/libexec/apache/libphp5.so #4 0x286fc89e in zend_shutdown () from /usr/local/libexec/apache/libphp5.so #5 0x286bb5bf in php_module_shutdown () from /usr/local/libexec/apache/libphp5.so #6 0x286bb66b in php_module_shutdown_wrapper () from /usr/local/libexec/apache/libphp5.so #7 0x28776aaa in apache_php_module_shutdown_wrapper () from /usr/local/libexec/apache/libphp5.so #8 0x080524d9 in ap_clear_pool (a=0x8106010) at alloc.c:1937 #9 0x0805f0f6 in standalone_main (argc=Variable argc is not available. ) at http_main.c:5480 #10 0x08060c1f in main (argc=-716130182, argv=0x1) at http_main.c:5883 I tried truss and it seemed to be taking a long time (5-10 minutes) and generating a lot of seemingly identical logging :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
On Thu, Jun 12, 2008 at 04:35:26PM +0930, Daniel O'Connor wrote: On Thu, 12 Jun 2008, Jeremy Chadwick wrote: I don't understand why gethostbyname() would call puts() - and why that would then crash! I can't explain why it's calling puts() directly either. Bad RAM could cause something bizarre like this, or a corrupt/broken binary. Yeah.. I have rebuilt lots of stuff, although not libc. Huh? This machine has build world, kernel, KDE, etc.. I am pretty sure the hardware is OK as none of the builds had an issue. libc is part of world. *Every* program relies (is linked with) on libc. If you go the truss route, be sure to use -a -s 4096. You'd be able to see what actual string is being output via puts(), assuming it gets as far as to start writing data to the fd. Hmm I had a go with gdb but it doesn't work properly.. I got this.. [midget 16:33] /tmp/work/usr/ports/www/apache13-modssl/work/apache_1.3.41 sudo gdb src/httpd Password: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... (gdb) run -X Starting program: /data/tmp/work/usr/ports/www/apache13-modssl/work/apache_1.3.41/src/httpd -X [New LWP 100212] [New Thread 0x819d300 (LWP 100212)] [New LWP 100212] suspend error: generic error [Switching to LWP 100212] Stopped due to shared library event (gdb) info thread Cannot find new threads: generic error (gdb) bt #0 0x2807fda0 in r_debug_state () from /libexec/ld-elf.so.1 #1 0x2808367d in dlclose () from /libexec/ld-elf.so.1 #2 0x28706164 in zend_hash_apply_deleter () from /usr/local/libexec/apache/libphp5.so #3 0x287063a8 in zend_hash_graceful_reverse_destroy () from /usr/local/libexec/apache/libphp5.so #4 0x286fc89e in zend_shutdown () from /usr/local/libexec/apache/libphp5.so #5 0x286bb5bf in php_module_shutdown () from /usr/local/libexec/apache/libphp5.so #6 0x286bb66b in php_module_shutdown_wrapper () from /usr/local/libexec/apache/libphp5.so #7 0x28776aaa in apache_php_module_shutdown_wrapper () from /usr/local/libexec/apache/libphp5.so #8 0x080524d9 in ap_clear_pool (a=0x8106010) at alloc.c:1937 #9 0x0805f0f6 in standalone_main (argc=Variable argc is not available. ) at http_main.c:5480 #10 0x08060c1f in main (argc=-716130182, argv=0x1) at http_main.c:5883 I can't say much about this, but I'm willing to bet it's the result of some Apache + PHP weirdness. I've never known gdb on FreeBSD to be as reliable/useful as, say, on Linux or Solaris. Always odd/strange things happening with gdb on FreeBSD. I tried truss and it seemed to be taking a long time (5-10 minutes) and generating a lot of seemingly identical logging :( Okay, let's backtrack here. The OP states that he can induce a segfault of httpd when doing apachectl graceful. Is that the exact problem you're seeing, or are you seeing problems where PHP/Apache segfaults during operation? I just want to be clear. If the latter, then truss generating lots of seemingly identical logging is probably expected. I'm guessing it's select() or poll() or something related to kqueue/kevent, as it'd be waiting for I/O on the HTTP socket. You'd have to submit the HTTP request to the PHP script to get it to crash. In either case, you may have to resort to using ktrace + kdump, which may or may not help narrow this down. Use ktrace -i -t+ httpd -X (I hope that'll work; I'm not sure if ktrace allows you to pass arguments to a command), which will start populating a file called ktrace.out. You should then do the apachectl graceful in another window (or if the latter, submit the HTTP request), and ktrace may exit when the segfault happens (I'm not sure about this; it may sit there indefinitely). In the case it doesn't exit, and you've confirmed the core happened (check dmesg), you should ^C the ktrace and then do ktrace -C just to be sure nothing got wedged. You'll then have to use kdump to decode the contents of ktrace.out. -- | 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: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
On Thu, 12 Jun 2008, Jeremy Chadwick wrote: Yeah.. I have rebuilt lots of stuff, although not libc. Huh? Sorry, I meant that I have to explicitly rebuilt it since I did a buildworld to make sure it wasn't fubar'd somehow. I haven't done that mainly because I find it extremely unlikely it would only break Apache in this manner but nothing else. I might rebuild it to get debug symbols though.. This machine has build world, kernel, KDE, etc.. I am pretty sure the hardware is OK as none of the builds had an issue. libc is part of world. *Every* program relies (is linked with) on libc. Yes, sorry for my confusing turn of phrase! :) #10 0x08060c1f in main (argc=-716130182, argv=0x1) at http_main.c:5883 I can't say much about this, but I'm willing to bet it's the result of some Apache + PHP weirdness. I've never known gdb on FreeBSD to be as reliable/useful as, say, on Linux or Solaris. Always odd/strange things happening with gdb on FreeBSD. Yeah :( I tried truss and it seemed to be taking a long time (5-10 minutes) and generating a lot of seemingly identical logging :( Okay, let's backtrack here. The OP states that he can induce a segfault of httpd when doing apachectl graceful. Is that the exact problem you're seeing, or are you seeing problems where PHP/Apache segfaults during operation? I just want to be clear. If the latter, then truss generating lots of seemingly identical logging is probably expected. I'm guessing it's select() or poll() or something related to kqueue/kevent, as it'd be waiting for I/O on the HTTP socket. You'd have to submit the HTTP request to the PHP script to get it to crash. In either case, you may have to resort to using ktrace + kdump, which may or may not help narrow this down. Use ktrace -i -t+ httpd -X (I hope that'll work; I'm not sure if ktrace allows you to pass arguments to a command), which will start populating a file called ktrace.out. You should then do the apachectl graceful in another window (or if the latter, submit the HTTP request), and ktrace may exit when the segfault happens (I'm not sure about this; it may sit there indefinitely). In the case it doesn't exit, and you've confirmed the core happened (check dmesg), you should ^C the ktrace and then do ktrace -C just to be sure nothing got wedged. You'll then have to use kdump to decode the contents of ktrace.out. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
[This is a continuation of my last message, I accidentally mashed the send key] On Thu, 12 Jun 2008, Jeremy Chadwick wrote: I tried truss and it seemed to be taking a long time (5-10 minutes) and generating a lot of seemingly identical logging :( Okay, let's backtrack here. The OP states that he can induce a segfault of httpd when doing apachectl graceful. Is that the exact problem you're seeing, or are you seeing problems where PHP/Apache segfaults during operation? I just want to be clear. No, I don't see a problem with 'apachectl graceful' - it doesn't get that far. If the latter, then truss generating lots of seemingly identical logging is probably expected. I'm guessing it's select() or poll() or something related to kqueue/kevent, as it'd be waiting for I/O on the HTTP socket. You'd have to submit the HTTP request to the PHP script to get it to crash. I get a crash when Apache starts up. I wasn't sure if it was related to OPs problem or not, I should have been clearer though. In either case, you may have to resort to using ktrace + kdump, which may or may not help narrow this down. Use ktrace -i -t+ httpd -X (I hope that'll work; I'm not sure if ktrace allows you to pass arguments to a command), which will start Yes ktrace does allow that. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
Robert Watson wrote: On Wed, 11 Jun 2008, Anton - Valqk wrote: I fully agree with the lines below. As noticed below there is more attention to developing new features, than making releases rock solid stable. ... Ah, another thing, I'm waiting for virtualization networking layer for jails for quite long. I've tested it on a test server, worked perfect, but on production I don't want to patch my base. there are few other features to jals that never got commited in base, and as I said I don't want to patch it... The reason that the virtualization patches aren't in the tree is precisely *because* we care about stability and are willing to slow down feature development in order to accomplish it. Some features take years to stabilize, and just because a patch works OK in your environment doesn't mean it will work in everyone's. Moderating the rate at which we adopt agressive new features is part of an intentional strategy to avoid letting development trees destabilize to a point where it's unproductive. I totally agree with that point, just commented that it's been year(s) since its appearence an maybe not enought effort in it (just an outsider thought, can't know if it is) and the fueature is a really really great and nice one! Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Adesso AKB-430UG keyboard on 7.0
I'm using an AKB-430UG USB keyboard (Win-Touch Pro) on FreeBSD 7.0-release-p1, or trying to. The keyboard works fine in Windows, but with FreeBSD I get the same sort of problems people have described previous with the Genius SlimStar Pro: the keys behave as if CTRL is always pressed. I'd hate to have to switch to a different keyboard, because it took me years to find a good alternative to my old Cirque Input Center keyboard/glidepoint combo. -- http://www.velocityvector.com/ | http://www.classic-games.com/ I'd rather hunt with Dick Cheney than ride with Ted Kennedy. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is prematurewithbuggy 6.3
Thanks for the answer, so lets tell what I think :) Marian Hettwer wrote: On Wed, 11 Jun 2008 18:50:57 +0300, Anton - Valqk [EMAIL PROTECTED] wrote: Thanks for the answer! I'm glad someone answered me a human way, because two times before, I wasn't answered that way (well... my posts were angry and incomplete but...that's why i didn't continued to post...my bad). Well then, lets continue answering in a human way. Which is, funnily enough, usually the more productive way too ;-) now on topic: yeah! Thats unfortunatly true. But there is a way around. As soon as you have several FreeBSD boxes, I'd advise you to install your own FreeBSD box for packages building. So if you need to update your php installations, go to your build box (which has the very same versions of programs installed as your production boxes), update your ports tree and do a make package of your new php port. If the new php package works fine on your build box, roll it out via pkg_add -r $NEWPHPTHINGY and off you go. I do have a build server(well a jail but works for me), also I have test eviornment (jailed too). I use this jail to build all my pkgs and use pkg_add -r (sweeet!!). For most of the ports this works, but sometimes something in make package breaks and i get a port installed partially (last case - apache22 got installed but no /usr/local/etc/rc.d/apache22 rc script, previous - pg_ctl never got installed) and in +CONTENTS file the missing files claimed to be there. hm... sounds like a bug to me. On the other hand, you have to try to get it to be reproducable. If it's a one timer then yes, it's annoying, but really really hard to reproduce and therefor to fix. the problem is that I don't have enought time to setup a testing server and find out when the problem occurs, because it's random seen, on 10-15th build of the new port this happens, I've noticed that if I make # make deinstall distclean install pakcage-recursive the problem occurs much more rare compared to just # make deinstall ditsclean package-recursive I simply currently don't have time for test setup ;( I've had to rebuild that kind of port so I can install it again (after pkg_delete) to have the port working. yeah, annoying. This happens most often when I do make install package-recursive (so I can get all needed ports installed). If you can reproduce it step by step, it may be worth posting to ports@ again with what you did and what happened. Either you're doing something wrong, or something is broken. However, it needs to be reproducable. At least in your environment. As a starter, so to say :) The more detailed your steps are written down, the more likely someone will either follow those steps or give you a direct hint on humm, could be something bad over there... hm hm). I understand that, that's why I didn't posted again because, as I said i don't have time to sitdown and setup and try to reproduce it. Another strange thing is that when I use php-extensions to build all that I need (this takes most of my time when build/install new php) breaks because of the ?'bug'? described few lines above. as I said noone got interested in this problem... I can't say anything specific about the php problem you said. I'm not using php, or well, very rarely. I'll give it a try to update it the make package way next time. Unluckily this is a one-box only system. hmmm... If I find the time to test, I'll drop you mail. But time is rare (admin life vs. normal life). To cut that short: Yeah, I can understand that this is annoying. But I'm sure as hell: - if it's a bug it can be fixed - if it's a user error, it can be changed - and all this has happened to me when trying to build my own debian packages too ;) And it happened to me with Gentoo, too. Nothing new at all. Just the regular annoyances in sysadmins life. IMO :) agree with that, just my effort with debian is much smaller than fbsd ports. Another _very important_ thing is that there is no binary support to packages that has vulns, and you have to rebuild them from ports. Well, its one time doing a make package... Even debian has no plus point there (at least in our environment at work). We pretty much always need our Apache 2 custom build, not the way the Debian projects build it. Thus we have a Debian build box around and build our own Apache 2.2 package. This is, indeed, the same amount of effort you would have when using FreeBSD. IMO the overhead in Debian to build a package is higher than in FreeBSD, but YMMV. If you build packages from source then debian just sux (much more complex and long procedure), but there is a tell - if you do it with debian - do it THE DEBIAN WAY... :-). I am doing it the debian way. Using the debian source package and try to update from there. Still its a more complex procedure then upgrading a FreeBSD port. I just
Re: broken re(4)
On Thu, 12 Jun 2008 16:01:26 +0900 Pyun YongHyeon [EMAIL PROTECTED] wrote about Re: broken re(4): PY I already did simple benchmarking by using dd if=/dev/zero PY of=file which gave me several 10s of MByte/s under all PY circumstances. Can you recommend one of the benchmarking programs PY for more detailed testing? PY Try netperf or iperf in ports/benchmark. The machine in question as client: Client connecting to 130.75.117.1, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 130.75.117.112 port 56513 connected with 130.75.117.1 port 5001 [ 3] 0.0-10.0 sec211 MBytes177 Mbits/sec On the server side: Server listening on TCP port 5001 TCP window size: 64.0 KByte (default) [ 4] local 130.75.117.1 port 5001 connected with 130.75.117.112 port 56513 [ 4] 0.0-10.3 sec211 MBytes172 Mbits/sec As server: Server listening on TCP port 5001 TCP window size: 64.0 KByte (default) [ 4] local 130.75.117.112 port 5001 connected with 130.75.117.1 port 53843 [ 4] 0.0-10.1 sec399 MBytes331 Mbits/sec On the client side: Client connecting to 130.75.117.112, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 130.75.117.1 port 53843 connected with 130.75.117.112 port 5001 [ 3] 0.0-10.1 sec399 MBytes331 Mbits/sec Hm, being a server seems to work better? The machine on the other side is also having a re-interface and usually transfers data with 20-30MByte/s. The ITX machine I'm testing is using both of it's re-interfaces in a lagg-configuration right now (laggproto loadbalance). Is this the expected performance? 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: Adesso AKB-430UG keyboard on 7.0
On Thu, 2008-06-12 at 03:22 -0500, Greg Miller wrote:
I'm using an AKB-430UG USB keyboard (Win-Touch Pro) on FreeBSD
7.0-release-p1, or trying to. The keyboard works fine in Windows, but
with FreeBSD I get the same sort of problems people have described
previous with the Genius SlimStar Pro: the keys behave as if CTRL is
always pressed.
I'd hate to have to switch to a different keyboard, because it took me
years to find a good alternative to my old Cirque Input Center
keyboard/glidepoint combo.
Can you try the following patch please?
--- ukbd.c 2008-06-02 14:09:45.0 +0100
+++ ukbd.c 2008-06-12 10:44:16.0 +0100
@@ -1423,6 +1423,7 @@
init_keyboard(ukbd_state_t *state, int *type, int flags)
{
usb_endpoint_descriptor_t *ed;
+ usbd_status err;
*type = KB_OTHER;
@@ -1447,6 +1448,14 @@
printf(ukbd: unexpected endpoint\n);
return EINVAL;
}
+
+ err = usbd_set_protocol(state-ks_iface, 0);
+ if (err) {
+ printf(ukbd: set boot protocol failed\n);
+ return EIO;
+ } else {
+ DPRINTFN(5, (boot protocol set\n));
+ }
/* Ignore if SETIDLE fails since it is not crucial. */
usbd_set_idle(state-ks_iface, 0, 0);
Thanks,
Gavin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adesso AKB-430UG keyboard on 7.0
Gavin Atkinson wrote: On Thu, 2008-06-12 at 03:22 -0500, Greg Miller wrote: I'm using an AKB-430UG USB keyboard (Win-Touch Pro) on FreeBSD 7.0-release-p1, or trying to. The keyboard works fine in Windows, but with FreeBSD I get the same sort of problems people have described previous with the Genius SlimStar Pro: the keys behave as if CTRL is always pressed. Can you try the following patch please? With this patch, it works great as a keyboard. However, the GlidePoint touchpad isn't being detected as a USB mouse and the data is being interpreted as keystrokes. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adesso AKB-430UG keyboard on 7.0
On Thu, 2008-06-12 at 05:41 -0500, Greg Miller wrote: Gavin Atkinson wrote: On Thu, 2008-06-12 at 03:22 -0500, Greg Miller wrote: I'm using an AKB-430UG USB keyboard (Win-Touch Pro) on FreeBSD 7.0-release-p1, or trying to. The keyboard works fine in Windows, but with FreeBSD I get the same sort of problems people have described previous with the Genius SlimStar Pro: the keys behave as if CTRL is always pressed. Can you try the following patch please? With this patch, it works great as a keyboard. However, the GlidePoint touchpad isn't being detected as a USB mouse and the data is being interpreted as keystrokes. Can you confirm that the GlidePoint was working correctly before the patch? Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
PAE vs USB
Hi, Is anyone successfully using USB (particularly umass) under PAE on 7.0R? Or, can anyone say for sure that it's not safe? TIA -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAE vs USB
Bob Bishop wrote: Hi, Is anyone successfully using USB (particularly umass) under PAE on 7.0R? Or, can anyone say for sure that it's not safe? TIA I'm using it on 6-STABLE (PAE+SMP). No problems so far, but it's not very heavily used. signature.asc Description: OpenPGP digital signature
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
Daniel O'Connor wrote: On Thu, 12 Jun 2008, Jim Pingle wrote: I need to see if I can improve the script any (suggestions are most welcome) then open a PR to see if it -- or logic like it -- can be included in the php-extensions meta port. Adding the script to the port seems like the way to go (baring an upstream fix but it seems like a difficult problem to solve). Unfortunately it doesn't help me :( If I disable everything except either pgsql or mhash (either separately or together) Apache crashes with.. #0 0x28ad6d40 in ?? () #1 0x281c6f2e in _pthread_main_np () from /lib/libc.so.7 #2 0x2819fa0c in puts () from /lib/libc.so.7 #3 0x281a0177 in gethostbyname () from /lib/libc.so.7 #4 0x08069a12 in ap_get_local_host () #5 0x08068b9c in ap_fini_vhost_config () #6 0x0805639c in ap_read_config () #7 0x0805f133 in standalone_main () #8 0x08060c1f in main () I don't understand why gethostbyname() would call puts() - and why that would then crash! Seems like some threading related wrinkle though as pgsql mhash are the only extensions I have that are linked to libthr.so I'm afraid I wouldn't be much help with this one in that case. I have a vague recollection of gethostbyname() crashing for someone else, though. I thought it had something to do with the ServerName directive and/or an entry in /etc/hosts -- but unfortunately I don't recall the specifics and my Google-fu seems to be failing me this morning. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
Jim Pingle wrote: Daniel O'Connor wrote: On Thu, 12 Jun 2008, Jim Pingle wrote: I need to see if I can improve the script any (suggestions are most welcome) then open a PR to see if it -- or logic like it -- can be included in the php-extensions meta port. Adding the script to the port seems like the way to go (baring an upstream fix but it seems like a difficult problem to solve). Unfortunately it doesn't help me :( If I disable everything except either pgsql or mhash (either separately or together) Apache crashes with.. #0 0x28ad6d40 in ?? () #1 0x281c6f2e in _pthread_main_np () from /lib/libc.so.7 #2 0x2819fa0c in puts () from /lib/libc.so.7 #3 0x281a0177 in gethostbyname () from /lib/libc.so.7 #4 0x08069a12 in ap_get_local_host () #5 0x08068b9c in ap_fini_vhost_config () #6 0x0805639c in ap_read_config () #7 0x0805f133 in standalone_main () #8 0x08060c1f in main () I don't understand why gethostbyname() would call puts() - and why that would then crash! Seems like some threading related wrinkle though as pgsql mhash are the only extensions I have that are linked to libthr.so I'm afraid I wouldn't be much help with this one in that case. I have a vague recollection of gethostbyname() crashing for someone else, though. I thought it had something to do with the ServerName directive and/or an entry in /etc/hosts -- but unfortunately I don't recall the specifics and my Google-fu seems to be failing me this morning. I'm 99.5% sure that the ServerName Directive has to resolve. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [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: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
On Thu, 12 Jun 2008, Jim Pingle wrote: Seems like some threading related wrinkle though as pgsql mhash are the only extensions I have that are linked to libthr.so I'm afraid I wouldn't be much help with this one in that case. I have a vague recollection of gethostbyname() crashing for someone else, though. I thought it had something to do with the ServerName directive and/or an entry in /etc/hosts -- but unfortunately I don't recall the specifics and my Google-fu seems to be failing me this morning. I did some googling on the stack trace and found.. http://www.nabble.com/php5-and-postgresql-8.2-8.3-td16744979.html I think I'll try switching to Apache 2.. (Right after I upgrade my mail system so I can ditch any 6.x cruft shudder) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
Jim Pingle wrote: Seems like some threading related wrinkle though as pgsql mhash are the only extensions I have that are linked to libthr.so Do you really need threading in pgsql and mhash? Some years ago I had the same problem with apache crashing misterously (not on restart, though) which I've traced to having threading libraries hard-referenced in PHP libraries. If you're not absolutely sure you need it, remove threading libraries from your PHP libraries (for pgsql there's a make config option). signature.asc Description: OpenPGP digital signature
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
On Thu, 12 Jun 2008, Daniel O'Connor wrote: On Thu, 12 Jun 2008, Jeremy Chadwick wrote: I myself haven't ever run into extension ordering issues like those described (and we've done hosting for years), but I don't doubt those who have experienced such. I am currently experiencing this :( In the past I shuffled the order until it worked but that's not a real solution. Also if you have gone from 6.x to 7.x make sure that you don't have any old stuff linked against libc.so.6 loaded into a binary using libc.so.7. It mostly works except with threaded programs and then *kaboom* Also, please try rebuilding PHP5 that has this fix[1] (in ports tree after June 9th). It may or may not help your issue. Sean 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/123911 -- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?
Greetings list, Given recent EOL announcements, I'm trying to upgrade an ancient machine from 5.5 to 7. It has 80 Mb total in the root partition, /home/, /var/, /usr/, and /tmp/ on other partitions, and NFS mounts /usr/src, /usr/obj, and /usr/ports from a slightly newer/faster box. I've seen http://www.freebsd.org/releases/7.0R/relnotes.html and http://marc.info/?l=freebsd-stablem=121278826119286w=2 which seem to suggest that even with INSTALL_NODEBUG during buildkernel, 7 might not fit in an 80 Mb /. Must I partition a new disk to give more space to /, or can I find more space by deleting /stand/, /modules/, and possibly /rescue/ to shoehorn a custom 7.x kernel in the available space? TIA Alex __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?
On Thursday 12 June 2008, fbsd2 wrote: Greetings list, Given recent EOL announcements, I'm trying to upgrade an ancient machine from 5.5 to 7. It has 80 Mb total in the root partition, /home/, /var/, /usr/, and /tmp/ on other partitions, and NFS mounts /usr/src, /usr/obj, and /usr/ports from a slightly newer/faster box. I've seen http://www.freebsd.org/releases/7.0R/relnotes.html and http://marc.info/?l=freebsd-stablem=121278826119286w=2 which seem to suggest that even with INSTALL_NODEBUG during buildkernel, 7 might not fit in an 80 Mb /. Must I partition a new disk to give more space to /, or can I find more space by deleting /stand/, /modules/, and possibly /rescue/ to shoehorn a custom 7.x kernel in the available space? TIA It should fit, though you may have issues with kernel.old pushing you over the limit. -- Anish Mistry signature.asc Description: This is a digitally signed message part.
Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?
2008/6/12 fbsd2 [EMAIL PROTECTED]: Greetings list, Given recent EOL announcements, I'm trying to upgrade an ancient machine from 5.5 to 7. It has 80 Mb total in the root partition, /home/, /var/, /usr/, and /tmp/ on other partitions, and NFS mounts /usr/src, /usr/obj, and /usr/ports from a slightly newer/faster box. I've seen http://www.freebsd.org/releases/7.0R/relnotes.html and http://marc.info/?l=freebsd-stablem=121278826119286w=2 which seem to suggest that even with INSTALL_NODEBUG during buildkernel, 7 might not fit in an 80 Mb /. Must I partition a new disk to give more space to /, or can I find more space by deleting /stand/, /modules/, and possibly /rescue/ to shoehorn a custom 7.x kernel in the available space? TIA If you know you do not need the modules, by all means, to do away with them is space back to you. If you are building from source, you can use the: MODULES_OVERRIDE= variable in /etc/make.conf When you are at the # make installworld stage you can likely delete /stand (I believe it is not used on =6.x) (Though I am not sitting at the machine now) I believe that / on my 7.x box is about 46M. -- -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
How to upgrade openssl after upgrading from 6.2 to 7.0
Hello list, I just upgraded my workstation from 6.2 to 7.0 but I haven't been able to upgrade all the ports. OpenSSL is giving me problems when trying to upgrade (with portupgrade). The message I get is that the it's marked as ignore because it conflicts with the base: # portupgrade security/openssl-stable ** Port marked as IGNORE: security/openssl-stable: Conflicts with version in the base ** Listing the failed packages (-:ignored / *:skipped / !:failed) - security/openssl-stable (marked as IGNORE) How do I fix this? TIA -- Attos Janus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to upgrade openssl after upgrading from 6.2 to 7.0
Date: Thu, 12 Jun 2008 16:08:33 -0400 From: Attos [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hello list, I just upgraded my workstation from 6.2 to 7.0 but I haven't been able to upgrade all the ports. OpenSSL is giving me problems when trying to upgrade (with portupgrade). The message I get is that the it's marked as ignore because it conflicts with the base: # portupgrade security/openssl-stable ** Port marked as IGNORE: security/openssl-stable: Conflicts with version in the base ** Listing the failed packages (-:ignored / *:skipped / !:failed) - security/openssl-stable (marked as IGNORE) How do I fix this? You don't. openssl-stable is the same version of openssl that is already in the base system in 7.0, so you should remove the port (pkg_deinstall openssl-\*). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgp8SMNneq1ib.pgp Description: PGP signature
[7-STABLE] ping -s 4000 with ipsec panic
[FreeBSD 7-STABLE/i386] Hello, I've got a 100 % reproductible panic with ipsec when using a 'ping -s 4000'. It works without ipsec My ipsec setup is very simple, i just use setkey: /etc/ipsec.conf flush; spdflush; add 192.168.1.21 192.168.1.200 esp 1011 -E rijndael-cbc 0123456789012345; add 192.168.1.200 192.168.1.21 esp 1012 -E rijndael-cbc 0123456789012345; spdadd 192.168.1.200 192.168.1.21 any -P out ipsec esp/transport//require; spdadd 192.168.1.21 192.168.1.200 any -P in ipsec esp/transport//require; I tried to use des-cbc with the same panic. Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4100be00 fault code = supervisor read, page not present instruction pointer = 0x20:0xc079985e stack pointer = 0x28:0xd61a0744 frame pointer = 0x28:0xd61a076c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1175 (ping) trap number = 12 panic: page fault Uptime: 9m5s Physical memory: 503 MB Dumping 87 MB: 72 56 40 24 8 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0556273 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc055646f in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc079b91c in trap_fatal (frame=0xd61a0704, eva=1090567680) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc079bba0 in trap_pfault (frame=0xd61a0704, usermode=0, eva=1090567680) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc079c529 in trap (frame=0xd61a0704) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0789f2b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc079985e in generic_bcopy () at /usr/src/sys/i386/i386/support.s:498 #8 0xc1f7267e in ?? () #9 0x8fb82d87 in ?? () #10 0x361fe9de in ?? () #11 0x39402686 in ?? () #12 0x0fa0 in ?? () #13 0xc29cf380 in ?? () #14 0xc2ea9654 in ?? () #15 0x in ?? () #16 0xd61a095c in ?? () #17 0xc0700746 in crypto_invoke (cap=0x8, crp=0xd61a0950, hint=-1616994916) at cryptodev_if.h:53 Previous frame inner to this frame (corrupt stack?) (kgdb) - Thansk, regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [7-STABLE] ping -s 4000 with ipsec panic
Patrick Lamaizière wrote: generic_bcopy () at /usr/src/sys/i386/i386/support.s:498 #8 0xc1f7267e in ?? () #9 0x8fb82d87 in ?? () #10 0x361fe9de in ?? () #11 0x39402686 in ?? () #12 0x0fa0 in ?? () #13 0xc29cf380 in ?? () #14 0xc2ea9654 in ?? () #15 0x in ?? () #16 0xd61a095c in ?? () #17 0xc0700746 in crypto_invoke (cap=0x8, crp=0xd61a0950, hint=-1616994916) at cryptodev_if.h:53 Previous frame inner to this frame (corrupt stack?) (kgdb) Unfortunately the trace is bogus. Try to rebuild with -O instead of -O2 and reproduce the panic. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
