On Sep 2, 2006, at 9:33 PM, FreeBSD Tinderbox wrote:
:
cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -DFREEBSD_ELF -
DIN_RTLD -I/src/libexec/rtld-elf/alpha -I/src/libexec/rtld-elf -mno-
fp-regs -fpic -DPIC -Wformat=2 -Wno-format-extra-args -Werror -c /
src/libexec/rtld-elf/rtld.c
/src
TB --- 2006-09-03 03:45:59 - tinderbox 2.3 running on freebsd-current.sentex.ca
TB --- 2006-09-03 03:45:59 - starting RELENG_6 tinderbox run for alpha/alpha
TB --- 2006-09-03 03:45:59 - cleaning the object tree
TB --- 2006-09-03 03:46:30 - checking out the source tree
TB --- 2006-09-03 03:46:30 - c
On 9/2/06, Matthew Jacob <[EMAIL PROTECTED]> wrote:
> > As a workaround, I disabled the APICs (hint.apic.0.disabled),
> and that ~15 minutes delay at boot up, now was gone. Fine.
>
> (BTW, 7-CURRENT has the same problem, but without that huge delay)
Do you have APIC disabled for 7-CURRENT also?
Thank you :-) I am myself considering hardware from the same vendor
and I assume others are as well, so I appreciate the effort.
It's a Tier One vendor- you can rest assured that FreeBSD will support it.
___
freebsd-stable@freebsd.org mailing list
htt
> > Yup, sounds like a mess here.
> But is there a solution or workaround rather than just concluding?
Well, I've collected some info and am trying to sort through all of
the stories. There certainly is something wrong with recent mpt(4) and
I'm trying to figure out what. It affects some people's
>
> Yup, sounds like a mess here.
But is there a solution or workaround rather than just concluding?
Well, I've collected some info and am trying to sort through all of
the stories. There certainly is something wrong with recent mpt(4) and
I'm trying to figure out what. It affects some people'
> mpt0: Timedout requests already complete. Interrupts may not be functioning.
>
I've seen this on Supermicro EM64T in the past on 7-current, but that
went away about 3-4 weeks ago. It really seemed to me that this was
indeed an interrupt related problem.
Yup, sounds like a mess here.
But is th
The OS booted up and the SAS controller was now detected and supported by
the mpt(4) driver:
---
mpt0: port 0xec00-0xecff mem 0xfc4fc000-0xfc4f,
0xfc4e-0xfc4e irq 64 at device 8.0 on pci2
mpt0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xec00
mpt0: Reserved 0x4000 bytes for rid 0x1
> You can override the country code but the potential values
> depends on the regdomain. I thought hw.ath.countrycode was
> r/w but it appears you can only set via the tunable api (kenv
> hw.ath.countrycode=XXX). The dev.ath mib must be r/o since
> you cannot (yet) change this after attaching
Ok, I will upgrade my boxes and I will do simple ping tests again.
Did you see my sysctl.conf file ?
I mean these options:
kern.ipc.maxsockbuf=2097152
net.inet.ip.fastforwarding=1
net.inet.tcp.sendspace=65536
Could be this connected with increasing latency up to 500ms ?
I tested this issue on
On Wed, 16 Aug 2006, Robert Watson wrote:
Dear 6-STABLE users,
In the next 2-3 weeks, I plan to MFC support for CAPP security eventing
auditing from 7-CURRENT to 6-STABLE. The implementation has been running
quite nicely in -CURRENT for several months. Right now, I'm just waiting on
a con
Apologies for the long message, and thanks in advance for any response.
I've just bought one of those new generation Dell servers, specifically,
the PowerEdge 1950.
This is a dual Intel Dual Core Xeon 5050, 3.0 GHz, 667MHz FSB,
1GB 533MHz RAM, system.
This server has a LSI Logic SAS 5/i integra
12 matches
Mail list logo
