[head tinderbox] failure on mips/mips

TB --- 2011-01-28 08:35:22 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-28 08:35:22 - starting HEAD tinderbox run for mips/mips TB --- 2011-01-28 08:35:22 - cleaning the object tree TB --- 2011-01-28 08:35:24 - cvsupping the source tree TB --- 2011-01-28 08:35:24 -

[ath] ath_rate_sample changes; please test

Hi, I've just committed some changes to the ath_rate_sample module which teach it the bare minimum to transmit MCS frames when in 11n mode. No, this doesn't mean 11n mode is yet available or ready (there's some further work in the TX path first.) I'd appreciate some testing of this just to

unbounded sleep on [fifoow] while open a named pipe: is it a feature?

Hi. That's FreeBSD 8.1-RELEASE i386 (w/o debug). It's observed for bash processes which end up in unbounded sleep in [fifoow] wchan while executing the next script: %%% #!/usr/local/bin/bash LOG_FACILITY=local7.notice LOG_TOPIC_OUT=$TAG-output[$$] LOG_TOPIC_ERR=$TAG-error[$$] cd $WORK_DIR

Re: unbounded sleep on [fifoow] while open a named pipe: is it a feature?

On Fri, Jan 28, 2011 at 12:43:38PM +0300, Sergey Kandaurov wrote: Hi. That's FreeBSD 8.1-RELEASE i386 (w/o debug). It's observed for bash processes which end up in unbounded sleep in [fifoow] wchan while executing the next script: %%% #!/usr/local/bin/bash LOG_FACILITY=local7.notice

[head tinderbox] failure on mips/mips

TB --- 2011-01-28 13:39:49 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-28 13:39:49 - starting HEAD tinderbox run for mips/mips TB --- 2011-01-28 13:39:49 - cleaning the object tree TB --- 2011-01-28 13:39:51 - cvsupping the source tree TB --- 2011-01-28 13:39:51 -

[head tinderbox] failure on mips/mips

TB --- 2011-01-28 18:45:09 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-28 18:45:09 - starting HEAD tinderbox run for mips/mips TB --- 2011-01-28 18:45:09 - cleaning the object tree TB --- 2011-01-28 18:45:13 - cvsupping the source tree TB --- 2011-01-28 18:45:13 -

missing us.dvorakr.kbd

us.dvorakr.kbd is missing from /usr/share/syscons/keymaps/ I found one on the web; but wonder if it's been fixed. $ uname -a FreeBSD carmen.opera 8.1-STABLE FreeBSD 8.1-STABLE #2: Wed Oct 13 20:48:24 MST 2010 neshort@carmen:/usr/obj/usr/src/sys/CARMEN amd64

[head tinderbox] failure on mips/mips

TB --- 2011-01-28 23:45:12 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-28 23:45:12 - starting HEAD tinderbox run for mips/mips TB --- 2011-01-28 23:45:12 - cleaning the object tree TB --- 2011-01-28 23:45:14 - cvsupping the source tree TB --- 2011-01-28 23:45:14 -

[WORKAROUND] www/seamonkey2 on CURRENT

Hello! It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1]. Examining build log and reproducing it locally, the problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to produce libxpcom_core.so although -L/usr/local/lib and -liconv are specified

[head tinderbox] failure on mips/mips

TB --- 2011-01-29 04:49:52 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-29 04:49:52 - starting HEAD tinderbox run for mips/mips TB --- 2011-01-29 04:49:52 - cleaning the object tree TB --- 2011-01-29 04:49:54 - cvsupping the source tree TB --- 2011-01-29 04:49:54 -

cpufreq not working as module on i386/amd64

Hi all, I found that cpufreq driver failed to attach when compiled as module and loaded, but it works fine when compiled into kernel. I am wondering if this is due to some kind of limitation, or can be fixed? Tested on a Pentium E5200 desktop (i386) and a Pentium T4200 laptop (amd64). Both got