On Tue, Mar 29, 2011 at 10:27 AM, Michal Varga 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 desktop means many
On Tue, Dec 28, 2010 at 8:23 AM, John Baldwin 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 Miros
On Wed, Sep 15, 2010 at 5:53 PM, FreeBSD Tinderbox
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 tree
> TB --- 2010
> 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-
> > 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-sleepab
> -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 w
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
> 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
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
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 daemon
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:
db_trace_self_
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
