Alexey, good day. Yes, 141 means that SIGPIPE was delivered. This in turn means that 'tar -xf -' exited before gunzip had finished its job and gunzip had tried to write more data to the pipe. Could I ask to do some debugging: 1. run 'gunzip -c ooo_crystal_images-1.tar.gz > crystal.tar' 2. run 'cat crystal.tar | (tar -xf -) && echo OK' and look for the results. 3. do 'md5 ooo_crystal_images-1.tar.gz' For the last point, I have ----- MD5 (ooo_crystal_images-1.tar.gz) = ...

TB --- 2009-05-05 15:59:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-05 15:59:20 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-05-05 15:59:20 - cleaning the object tree TB --- 2009-05-05 15:59:52 - cvsupping the source tree TB --- 2009-05-05 15:59:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-05-05 16:00:04 - building world TB --- 2009-05-05 16:00:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 ...

TB --- 2009-05-05 13:54:24 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-05 13:54:24 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-05-05 13:54:24 - cleaning the object tree TB --- 2009-05-05 13:54:55 - cvsupping the source tree TB --- 2009-05-05 13:54:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-05-05 13:55:05 - building world TB --- 2009-05-05 13:55:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 13:55:05 - ...

Hello, since the last portupgrade when dev/subversion-freebsd got updates, I realize a drastic slowdown since then on FreeBSD 8.0-CURRENT/amd64 boxes. Is there any known issue and if, how to circumvent ... Regards, Oliver _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

TB --- 2009-05-05 12:07:35 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-05 12:07:35 - starting HEAD tinderbox run for i386/i386 TB --- 2009-05-05 12:07:35 - cleaning the object tree TB --- 2009-05-05 12:08:13 - cvsupping the source tree TB --- 2009-05-05 12:08:13 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-05-05 12:08:23 - building world TB --- 2009-05-05 12:08:23 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-05 12:08:23 - ...

Hi there. As I'm slowly getting used to FreeBSD (again), I recently upgraded three boxes to 7.2-RELEASE. Two of them were running 7.1-RELEASE and one was running 7.2-RC2 .. Anyways, I used freebsd-update to upgrade - in my previous experiences I would have to do a "make world" etc. etc. Which method is most preferred - source or binary upgrading? I don't mind source upgrading but is it really necessary anymore if using freebsd-update on a regular basis? ...

Renato, In principle, you can run into some errors, like KVM size mismatches (and other ABI changes) if your kernel (that you build from sources) and updated base will differ. But you'll immediately notice it ;)) And for most cases such way should work fine. My two cents. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # ...

Why is this affecting 7.2-STABLE? Does anyone test anything before a release anymore? This doesn't apply to 7.2: atching file vga_pci.c using Plan A... Hunk #1 failed at 42. Hunk #2 succeeded at 118 (offset -20 lines). Hunk #3 succeeded at 146 (offset -20 lines). 1 out of 3 hunks failed--saving rejects to vga_pci.c.rej Hmm... Ignoring the trailing garbage. -- Over the years I've come to regard you as people I've ...

Hi Chao, Yes, it is going into -current soon. Final patch: Not yet. The problem is USB is multi threaded, while kdb requires single threaded operation. It is a little difficult. Also UKBD was Giant locked last time I checked due to some non-MPSAFE dependencies. This is another issue blocking USB keyboard in KDB. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, ...

If you type: ll /boot/kernel Do all the modules have the same date? There is a fuse4bsd module there which I suspect is out of date. --HPS _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

This has been committed, thanks for reporting and Hans for fixing. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

Then you need to build a kernel with debugging and get a backtrace: options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. When you get to the debugger prompt at boot, type "bt" for backtrace. --HPS _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To ...

Sorry, I'm mixing with another error report. Try this: 1) Boot without the USB mouse plugged in. 2) Run: sysctl hw.usb2.uhci.debug=15 3) Plug your USB mouse. 4) Unplug your USB mouse. Send dmesg. --HPS _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

Try the attached patch to uhci.c. =2D-HPS

Hi Hans, There is my modules' list as your guess, the fuse.ko is out of date, but is it can cause mouse defunction? I'll try to unload it. [root@currentpark] /usr/local/etc/rc.d# ll /usr/local/modules/fuse.ko -r-xr-xr-x 1 root wheel 83208 May 1 04:19 /usr/local/modules/fuse.ko* [root@currentpark] /usr/local/etc/rc.d# ll /boot/kernel/ total 159208 drwxr-xr-x 2 root wheel 27136 May 5 14:24 ./ drwxr-xr-x 9 root wheel 1024 May 5 14:24 ../ -r-xr-xr-x 1 root wheel 174856 ...

0n Tue, May 05, 2009 at 05:30:19PM -0400, Eitan Adler wrote: >Adam McDougall wrote: >> On Mon, May 04, 2009 at 01:18:14AM +0300, Alexander Motin wrote: >> >> I would like to summarize some of my knowledge on reducing FreeBSD power >> consumption and describe some new things I have recently implemented in >> 8-CURRENT. The main character of this story is my 12" Acer TravelMate >> 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, ...

Yes, but a tickless kernel will let the CPU stay asleep for longer since it doesn't need to wake up just to discover there's nothing I've recently (in the last few days) worked through minimising the write activity on the SSD in my laptop (I wrote a tool that monitors write transfers via devstat(3) and it would be possible to track down the actual modified files via kqueue(2) if necessary). I'm now down to about two chunks of about 13 transfers each per hour (due to entopy saving and ...

Is there any possibility to have it committed in to the tree? It seems useful, I have timeout problems [READ_DMA timed out] on few machines and this (tunable / longer timeout) should definitely fix it. Miroslav Lachman _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"