TB --- 2010-05-09 06:18:34 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-05-09 06:18:34 - starting RELENG_8 tinderbox run for i386/i386
TB --- 2010-05-09 06:18:34 - cleaning the object tree
TB --- 2010-05-09 06:18:49 - cvsupping the source tree
TB --- 2010-05-09 06:18:49 - /usr/b
TB --- 2010-05-09 06:10:56 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-05-09 06:10:56 - starting RELENG_8 tinderbox run for amd64/amd64
TB --- 2010-05-09 06:10:56 - cleaning the object tree
TB --- 2010-05-09 06:11:22 - cvsupping the source tree
TB --- 2010-05-09 06:11:22 - /usr
TB --- 2010-05-09 06:10:43 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-05-09 06:10:43 - starting RELENG_8_0 tinderbox run for
sparc64/sparc64
TB --- 2010-05-09 06:10:43 - cleaning the object tree
TB --- 2010-05-09 06:10:55 - cvsupping the source tree
TB --- 2010-05-09 06:10:55
TB --- 2010-05-09 06:12:33 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-05-09 06:12:33 - starting RELENG_8 tinderbox run for arm/arm
TB --- 2010-05-09 06:12:33 - cleaning the object tree
TB --- 2010-05-09 06:12:41 - cvsupping the source tree
TB --- 2010-05-09 06:12:41 - /usr/bin
On 05/08/10 23:07, jhell wrote:
> The following two commits to stable/7 may be responsible for dirtying
> the console with messages pertaining to setting values in rc.conf.
I appreciate the problem report, but pasting the commit logs from
commits that I actually did doesn't provide me any useful i
TB --- 2010-05-09 05:27:41 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-05-09 05:27:41 - starting RELENG_8_0 tinderbox run for mips/mips
TB --- 2010-05-09 05:27:41 - cleaning the object tree
TB --- 2010-05-09 05:27:47 - cvsupping the source tree
TB --- 2010-05-09 05:27:47 - /usr
TB --- 2010-05-09 05:26:52 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-05-09 05:26:52 - starting RELENG_8_0 tinderbox run for ia64/ia64
TB --- 2010-05-09 05:26:52 - cleaning the object tree
TB --- 2010-05-09 05:27:05 - cvsupping the source tree
TB --- 2010-05-09 05:27:05 - /usr
TB --- 2010-05-09 05:30:31 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-05-09 05:30:31 - starting RELENG_8_0 tinderbox run for
powerpc/powerpc
TB --- 2010-05-09 05:30:31 - cleaning the object tree
TB --- 2010-05-09 05:30:45 - cvsupping the source tree
TB --- 2010-05-09 05:30:45
The following two commits to stable/7 may be responsible for dirtying
the console with messages pertaining to setting values in rc.conf.
Though these messages are harmless and daemons will continue to run as
normal; they should be looked into & fixed.
reverting to revision 201272 of rc.subr reliev
TB --- 2010-05-09 04:47:53 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-05-09 04:47:53 - starting RELENG_8_0 tinderbox run for i386/i386
TB --- 2010-05-09 04:47:53 - cleaning the object tree
TB --- 2010-05-09 04:48:24 - cvsupping the source tree
TB --- 2010-05-09 04:48:24 - /usr
TB --- 2010-05-09 04:47:53 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-05-09 04:47:53 - starting RELENG_8_0 tinderbox run for amd64/amd64
TB --- 2010-05-09 04:47:53 - cleaning the object tree
TB --- 2010-05-09 04:48:26 - cvsupping the source tree
TB --- 2010-05-09 04:48:26 - /u
I'm having issues getting my wireless card working. It was working with
8.0-RELEASE
I created wlan0 manually for debug
ifconfig wlan0 create wlandev ath0 wlanmode station country GB
wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf
ifconfig wlan0 10.0.0.1/25
if I then ping a known reachable
Hi,
I had an experienced in FreeBSD 8.0 (not with FreeBSD 7.3), that if we
removed any vlan in any interfaces it makes sessions in openbgpd with
connect but never get established.
The logs only said like this, ``received notification: HoldTimer
expired, unknown subcode 0'' and ``socket error: Conn
On Monday 03 May 2010 22:34:57 Emil Mikulic wrote:
> On Mon, May 03, 2010 at 10:16:57PM -0400, Charles Sprickman wrote:
> > Just some random data. I know when I was reading about ZFS I did
> > come across some vague notion that zfs wanted the entire drive to
> > better deal with queueing, not sure
On Sat, May 8, 2010 at 2:06 PM, rihad wrote:
> Hi, I'm thinking of enabling the watchdog on our Dell PowerEdge 2950 /
> FreeBSD 8.0 amd64, so that it reboots the machine in case of lockups.
> Right now it doesn't work:
>
I installed watchdogd on a few 8-core Dell PowerEdge 1950, which I
assume ar
Thanks Matt most appreciated!
- Original Message -
From: "Matt Reimer"
Steve,
The patch for PR 144061 works for us.
http://lists.freebsd.org/pipermail/freebsd-hackers/2010-February/030741.html
http://www.freebsd.org/cgi/query-pr.cgi?pr=144061
=
As you may have guessed by my last reply no we didn't we had to revert to
apache + passenger, but seems you've found a fix anyway. Out of interest
what lead you to the close race condition PR as a potential fix?
- Original Message -
From: "Matt Reimer"
Steve,
Did you figure this out?
Hi,
I'm having trouble with some C++ binaries. They coredumps with Bus
error. backtraces always end up with:
Cannot access memory at address 0x8000
An example of those binaries is pkgdata. A binary used as a part
of building icu4c.
I rebuilt gcc45, world and kernel with debugging symbol
On Sat, May 08, 2010 at 06:06:15PM +0500, rihad wrote:
> Hi, I'm thinking of enabling the watchdog on our Dell PowerEdge 2950
> / FreeBSD 8.0 amd64, so that it reboots the machine in case of
> lockups.
> Right now it doesn't work:
>
> # watchdog
> watchdog: patting the dog: Operation not supported
Hi, I'm thinking of enabling the watchdog on our Dell PowerEdge 2950 /
FreeBSD 8.0 amd64, so that it reboots the machine in case of lockups.
Right now it doesn't work:
# watchdog
watchdog: patting the dog: Operation not supported
#
Looking through the kernel configuration I found two relevant s
20 matches
Mail list logo
