TB --- 2010-03-06 07:23:50 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-03-06 07:23:50 - starting RELENG_8_0 tinderbox run for amd64/amd64
TB --- 2010-03-06 07:23:50 - cleaning the object tree
TB --- 2010-03-06 07:24:21 - cvsupping the source tree
TB --- 2010-03-06 07:24:21 - /u
On 3/5/2010 1:44 AM, Matthias Gamsjager wrote:
> One thing is sure. the route won't survive a reboot. Guess you can add
> it to rc.conf but I have never tried it.
>
check /etc/defaults/rc.conf for static_routes and its usage. Maybe you
already know about this but I wanted to double check with you
On Mon, Feb 22, 2010 at 02:51:59PM -0800, Chris Knight wrote:
> This problem is caused by a big-endian, little-endian difference
> between the OSX implementation of UFS and the FreeBSD implementation.
> http://forums.macosxhints.com/showthread.php?t=86385
Yes, that's a good reason why both ufs1 an
Ok, a new development in this story.
Note that as of yet, I haven't change SATA cables or done anything else
with the hardware. However, I did upgrade to latest FreeBSD
8.0-stable / amd64 yesterday.
The machine is still up (it iahsn't crashed yet), and today I found this in
/var/log/messages:
Mar
hi,
I get
link_elf_obj: symbol lapic_cyclic_clock_func undefined
when trying
kldload dtraceall
this is with a fearly resent 8-stable
I'm trying to help Rick Maclem debug the NSF/UDP problem, and I
thought it would be a good chance to learn dtrace, but :-(
danny
___
On Sat, 6 Mar 2010, Daniel Braniss wrote:
link_elf_obj: symbol lapic_cyclic_clock_func undefined
when trying
kldload dtraceall this is with a fearly resent 8-stable
I'm trying to help Rick Maclem debug the NSF/UDP problem, and I thought it
would be a good chance to learn dtra
On Sat, 6 Mar 2010 15:09:51 + (GMT) Robert Watson
wrote:
>
> On Sat, 6 Mar 2010, Daniel Braniss wrote:
>
> > link_elf_obj: symbol lapic_cyclic_clock_func undefined
> >
> > when trying
> > kldload dtraceall this is with a fearly resent 8-stable
> >
> > I'm trying to help Rick Maclem
On Sat, 6 Mar 2010, Alexander Leidinger wrote:
Take a look at the DTrace configuration information here:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/dtrace.html
I've just reread it (despite the fact that I already used it). Some
comments:
Last time I tried, I didn't see any
On Sat, Mar 06, 2010 at 12:43:24PM +0100, Harald Weis wrote:
> > I solved this problem for myself by installing MacFuse
>
> MacFuse is not yet available for Snow Leopard (10.6).
Not entirely correct. MacFuse is not available for Snow Leopard when
booting a 64 bit kernel. Apparently it works fin
>
> On Sat, 6 Mar 2010, Daniel Braniss wrote:
>
> > link_elf_obj: symbol lapic_cyclic_clock_func undefined
> >
> > when trying
> > kldload dtraceall this is with a fearly resent 8-stable
> >
> > I'm trying to help Rick Maclem debug the NSF/UDP problem, and I thought it
> > would be a goo
Hi,
Recently I have updated my 8.0-STABLE i386 system and have learnt that
virtualbox begins to crash my box with the error
panic: vm_fault: fault on nofault entry, addr: c1608000
(kgdb) bt
#0 doadump () at pcpu.h:246
#1 0xc04ec379 in db_fncall (dummy1=-1064468854, dummy2=0, dummy3=-1,
dummy4
* Jack Vogel (jfvo...@gmail.com) wrote:
> Its using MSI? Given that its PCI-X I have no idea how robust MSI is,
> how bout you compile it with that disabled, use legacy IRQ and see
> if that makes any diff.
I'm seeing similar issues with a quad port 82546EB card, and they're not
using MSI as far
I need a bit more context Nick. Is this a card that has been non-problematic
on older releases and just showed a problem with 8.0 REL?
Regards,
Jack
On Sat, Mar 6, 2010 at 10:00 AM, Thomas Hurst wrote:
> * Jack Vogel (jfvo...@gmail.com) wrote:
>
> > Its using MSI? Given that its PCI-X I have
Yes, this was the first em(4) problem I ran into when upgrading from
7.2-RELEASE to 8.0-RELEASE. Yourself and others on another thread eventually
recommended turning off TSO and what not. I never had a chance to thoroughly
test this solution on this particular hardware because we had already
switch
On Sat, Mar 06, 2010 at 12:08:22PM -0800, Nick Rogers wrote:
> Yes, this was the first em(4) problem I ran into when upgrading from
> 7.2-RELEASE to 8.0-RELEASE. Yourself and others on another thread eventually
> recommended turning off TSO and what not. I never had a chance to thoroughly
> test th
If that's a supermicro then em3 is usually the IPMI shared card so perhaps
that's the cause?
- Original Message -
From: "Thomas Hurst"
Interestingly I can pull 30-60MB/s to/from em0 (LAN) without any
problems, but pulling 5MB/s from em3 has repeatedly led to the interface
just going si
ALTQ + RELENG_8 + em(4) will not work at the moment. It does not matter what
your PF ruleset looks like or how much traffic you are pushing. The packets
that transit the em interface simply never make it to the ALTQ queues (not
even the interface's root queue). Thus any kind of bandwidth rate limit
On Sat, Mar 06, 2010 at 02:56:07PM -0800, Nick Rogers wrote:
> ALTQ + RELENG_8 + em(4) will not work at the moment. It does not matter what
> your PF ruleset looks like or how much traffic you are pushing. The packets
> that transit the em interface simply never make it to the ALTQ queues (not
> ev
On Sat, 6 Mar 2010, Daniel Braniss wrote:
it works ok in 7.2, so it would be interesting to compare changes ...
The sys/rpc in FreeBSD8 is completely different code than what is used in
FreeBSD7, so I'm afraid thay're apples vs oranges.
rick
___
* Steven Hartland (kill...@multiplay.co.uk) wrote:
> If that's a supermicro then em3 is usually the IPMI shared card so perhaps
> that's the cause?
No, it's a Tyan K8WE:
http://www.tyan.com/archive/products/html/thunderk8we.html
With a quad port Intel NIC in one of the 133MHz PCI-X slots. The
On Sun, Mar 07, 2010 at 01:28:13AM +, Thomas Hurst wrote:
> * Steven Hartland (kill...@multiplay.co.uk) wrote:
>
> > If that's a supermicro then em3 is usually the IPMI shared card so perhaps
> > that's the cause?
>
> No, it's a Tyan K8WE:
>
> http://www.tyan.com/archive/products/html/thund
21 matches
Mail list logo
