On Tue, Mar 29, 2011 at 10:27 AM, Michal Varga varga.mic...@gmail.com wrote:
On Tue, 2011-03-29 at 11:43 -0500, Paul Schmehl wrote:
Desktop support is lacking when compared to the other major OSes
(Windows, Mac and Linux).
Here too. How is desktop support on FreeBSD lacking?
I realize a
On Tue, Dec 28, 2010 at 8:23 AM, John Baldwin j...@freebsd.org wrote:
On Saturday, December 25, 2010 6:43:25 am Miroslav Lachman wrote:
John Baldwin wrote:
On Saturday, December 11, 2010 11:51:41 am Miroslav Lachman wrote:
Miroslav Lachman wrote:
Garrett Cooper wrote:
2010/4/20 Miroslav
On Wed, Sep 15, 2010 at 5:53 PM, FreeBSD Tinderbox
tinder...@freebsd.org wrote:
TB --- 2010-09-15 23:27:59 - tinderbox 2.6 running on
freebsd-current.sentex.ca
TB --- 2010-09-15 23:27:59 - starting RELENG_8 tinderbox run for
powerpc/powerpc
TB --- 2010-09-15 23:27:59 - cleaning the object
The crash was a page fault while in kernel mode with the current process
being the interrupt service routine for the bce0 GigE. Things progressed
reasonably until partway through the dump, when the system locked up with a
Sleeping thread (tid 100028, pid 12) owns a non-sleepable lock.
As an aside, this is a quad-core in one package CPU (an X3363). On both
this box and a similar one with an X5470, console messages continue to
print out after the system has been halted - press any key to reboot -
in particular, the shutdown makes a bunch of the behind the scenes man-
I'm looking at this panic in vget() on stable/7:
if (vp-v_iflag VI_DOOMED (flags LK_RETRY) == 0)
panic(vget: vn_lock failed to return ENOENT\n);
It seems to me that this is not a correct assertion, because if the
caller passed in no lock flags (i.e. just checking the
-Original Message-
From: Kostik Belousov [mailto:kostik...@gmail.com]
Sent: Friday, April 16, 2010 1:41 PM
To: Matthew Fleming
Cc: freebsd-stable@freebsd.org
Subject: Re: panic in vget()
On Fri, Apr 16, 2010 at 01:23:17PM -0700, Matthew Fleming wrote:
I'm looking at this panic
Since the last update and make world on Friday, 12th March I get a
crash
on one of my FreeBSD SMP boxes (it is always the same core message),
saying something about
Fatal trap 12: page fault while in kernel mode [...] current process:
12
(swi2: cambio)
Can you show the stack traceback from
r193754 to stable/7 appears to have unintended code. The MFC note
indicates it is a backport of 190206, 190330, 192537, 192540, 192584 and
192933. I looked over all of them and none have the offending snippet:
#ifndef LRO_SUPPORTED
#ifdef IFCAP_LRO
#undef IFCAP_LRO
#endif
#define IFCAP_LRO 0x0
[snip]
Load average and %CPU user are right, as are other global
statistics.
The load is produced by the 7z process (archivers/p7zip) which
compresses some data in two threads but is credited with 0% CPU,
though
its runtime is correct (increments every second as it should in a
I am interested in using uart(4) instead of sio(4) on stable/7, to ease
our eventual transition to stable/8 or CURRENT. I added device uart and
changed up /boot/device.hints (there were no entries in /etc/ttys that
mentioned sio), and I get something that boots and has messages on the
console, up
2) why would fork resolve to the one in libc (presumably, I'm not sure
how
to prove this) instead of the one in libthr?
Well, I'm not sure how the application plus libraries linked, but there
was no explicit -lthr or -lpthread in the Makefile. So the resulting
binary used the fork() in libc.
I have some code that tries to use pthread_cond_wait() and it's getting
back EPERM. Upon further investigation, here's what I've found:
When the app starts, libthr's _libpthread_init calls init_main_thread()
to set the thread id in struct pthread's tid.
The app opens a log file then calls
We got a cxgb LOR report of:
1st 0xff8001e37be0 vlan_global (vlan_global) @
/build/mnt/src/sys/modules/if_vlan/../../net/if_vlan.c:1310
2nd 0xff80010892f0 cxgb port lock (cxgb port lock) @
/build/mnt/src/sys/modules/cxgb/../../dev/cxgb/cxgb_main.c:1956
KDB: stack backtrace:
I'm doing a migration from releng/6.1 to stable/7, and one of the many
new things is that I get a warning when doing things with ng_socket that
didn't used to happen.
WARNING: attempt to net_add_domain(netgraph) after domainfinalize()
The MOD_LOAD code in ng_socket.c is doing a net_add_domain in
15 matches
Mail list logo
