Re: sem_wait(3) is not always a cancellation point
On 2014/03/13 04:33, Eric van Gyzen wrote: -current: From my understand of POSIX, sem_wait(3) should always be a cancellation point. However, when the semaphore's count is positive and the caller successfully decrements the count, sem_wait(3) does not call _pthread_testcancel(), so it's not a cancellation point. See this totally contrived test case: http://www.vangyzen.net/FreeBSD/patches/sem_wait_cancel.c This patch seems like an appropriate fix: http://www.vangyzen.net/FreeBSD/patches/sem_wait_cancel.diff It adds a call to _pthread_testcancel() in the same location as _libc_sem_timedwait_compat() in libc/gen/sem.c. Is this a real bug, or am I missing something? Eric You are right, the _pthread_testcancel() call should be added. Thanks, David Xu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
When I am using mercurial to initialize a freebsd repository, it prints warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.' it seems filename ended with a dot is illegal on Windows, if someone wants to check out freebsd source code on Windows, it will be a problem. Regards, David Xu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
how to know atomic_cmpset_64 is defined
Hi, I want to use atomic_cmpset_64, but some arch may not support it, Is there a way to figure out that atomic_cmpset_64 is defined when compiling ? Regards, David Xu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: hacking - aio_sendfile()
On 2013/07/11 14:17, Konstantin Belousov wrote: On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote: Hiya, I've started writing an aio_sendfile() syscall. http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff Yes, the diff is against -HEAD and not stable/9. It's totally horrible, hackish and likely bad. I've only done some very, very basic testing to ensure it actually works; i haven't at all stress tested it out yet. It's also very naive - I'm not at all doing any checks to see whether I can short-cut to do the aio there and then; I'm always queuing the sendfile() op through the worker threads. That's likely stupid and inefficient in a lot of cases, but it at least gets the syscall up and working. Yes, it is naive, but for different reason. The kern_sendfile() is synchronous function, it only completes after the other end of the network communication allows it. This means that calling kern_sendfile() from the aio thread blocks the thread indefinitely by unbounded sleep. Your implementation easily causes exhaustion of the aio thread pool, blocking the whole aio subsystem. It is known that our aio does not work for sockets for the same reason. I object against adding more code with the same defect. Proper route seems to rewrite aio for sockets using the upcalls. The same should be done for sendfile, if sendfile is given aio flavor. Yes, current aio implementation is horrible, it only works for fast disk I/O, I think the thread pool size is enough to saturate disks, but for socket or pipe I/O, it does not work well, the thread pool is too easy to be exhausted. I even think the support for socket and pipe in aio code should be cut and thrown away, because you can always use kqueue + non-blocking I/O. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: swapcontext rewrite broke some software
On 2013/04/16 21:24, Oliver Pinter wrote: Hi! After this commit: commit ac0cfc7fcb1b51ee6aeacfd676fa6dfbe11eefb5 Author: davidxu davi...@freebsd.org Date: Wed Apr 10 02:40:03 2013 + swapcontext wrapper can not be implemented in C, the stack pointer saved in the context becomes invalid when the function returns, same as setjmp, it must be implemented in assemble language, see discussions in PR misc/177624. Some* software not found the swapcontext functions after this commit. Please add a sentence to UPDATING file and/or bump the __FreeBSD_version to reflect this change. * qemu Hi, The change is reverted. Regards, David Xu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Is this a typo in if_tap.c?
When I was trying to create a second tap device, kernel crashed.
Is this patch correct ?
Index: sys/net/if_tap.c
===
--- sys/net/if_tap.c(revision 243397)
+++ sys/net/if_tap.c(working copy)
@@ -186,7 +186,7 @@
/* Find any existing device, or allocate new unit number. */
i = clone_create(tapclones, tap_cdevsw, unit, dev, 0);
if (i) {
- dev = make_dev(tap_cdevsw, 0, UID_ROOT, GID_WHEEL, 0600,
+ dev = make_dev(tap_cdevsw, unit, UID_ROOT, GID_WHEEL, 0600,
%s%d, tapname, unit);
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ULE patch, call for testers
On 2012/11/05 17:13, Andriy Gapon wrote:
on 05/11/2012 04:41 David Xu said the following:
Another problem I remembered is that a thread on runqueue may be starved
because ULE treats a sleeping thread and a thread waiting on runqueue
differently. If a thread has slept for a while, after it is woken up,
its priority is boosted, but for a thread on runqueue, its priority
will never be boosted. In essential, they should be same becase both of
them are waiting for cpu. If I am a thread, I'd like to wait on sleep
queue rather than on runqueue, since in former case, I will get
bonus, while in later case, I'll get nothing. Under heavy load,
there are many runnable threads, this unfair can cause a very low priority
thread on runqueue to be starved. 4BSD seems not suffer from
this problem, because it also decay cpu time of thread on runqueue.
I think ULE needs some anti-starvation code to give thread a shot
if it is waiting on runqueue too long time.
I also noticed this issue and I've been playing with the following patch.
Two points:
o I am not sure if it is ideologically correct
o it didn't improve much the behavior of my workloads
In any case, here it is:
- extend accounted interactive sleep time to a point where a thread runs
(as opposed to be added to runq)
--- a/sys/kern/sched_ule.c
+++ b/sys/kern/sched_ule.c
@@ -1898,8 +1899,21 @@ sched_switch(struct thread *td, struct thread *newtd, int
flags)
SDT_PROBE2(sched, , , off_cpu, td, td-td_proc);
lock_profile_release_lock(TDQ_LOCKPTR(tdq)-lock_object);
TDQ_LOCKPTR(tdq)-mtx_lock = (uintptr_t)newtd;
+#if 1
+ /*
+* If we slept for more than a tick update our interactivity and
+* priority.
+*/
+ int slptick;
+ slptick = newtd-td_slptick;
+ newtd-td_slptick = 0;
+ if (slptick slptick != ticks) {
+ newtd-td_sched-ts_slptime +=
+ (ticks - slptick) SCHED_TICK_SHIFT;
+ sched_interact_update(newtd);
+ }
+#endif
sched_pctcpu_update(newtd-td_sched, 0);
-
#ifdef KDTRACE_HOOKS
/*
* If DTrace has set the active vtime enum to anything
@@ -1990,6 +2004,7 @@ sched_wakeup(struct thread *td)
THREAD_LOCK_ASSERT(td, MA_OWNED);
ts = td-td_sched;
td-td_flags = ~TDF_CANSWAP;
+#if 0
/*
* If we slept for more than a tick update our interactivity and
* priority.
@@ -2001,6 +2016,7 @@ sched_wakeup(struct thread *td)
sched_interact_update(td);
sched_pctcpu_update(ts, 0);
}
+#endif
/* Reset the slice value after we sleep. */
ts-ts_slice = sched_slice;
sched_add(td, SRQ_BORING);
What I want is fairness between waiting on runqueue and waiting on
sleepqueue. Supports you have N threads on runqueue:
T1,T2,T3...Tn.
and a thread T(n+1) on sleepqueue.
If CPU runs threads T1...Tn in round-robin fashion, and suppose at
time n, the thread Tn is run, this means total time of n-1 is passed,
and at the time, thread T(n+1) is woken up, and scheduler's
sched_interact_score() will give it higher priority over Tn, this is
unfair because both threads have spent same total time to waiting for
cpu. Do your patch fix the problem ?
Regards,
David Xu
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ULE patch, call for testers
On 2012/11/03 02:26, Jeff Roberson wrote: I have a small patch to the ULE scheduler that makes a fairly large change to the way timeshare threads are handled. http://people.freebsd.org/~jeff/schedslice.diff Previously ULE used a fixed slice size for all timeshare threads. Now it scales the slice size down based on load. This should reduce latency for timeshare threads as load increases. It is important to note that this does not impact interactive threads. But when a thread transitions to interactive from timeshare it should see some improvement. This happens when something like Xorg chews up a lot of CPU. If anyone has perf tests they'd like to run please report back. I have done a handful of validation. Thanks, Jeff Another problem I remembered is that a thread on runqueue may be starved because ULE treats a sleeping thread and a thread waiting on runqueue differently. If a thread has slept for a while, after it is woken up, its priority is boosted, but for a thread on runqueue, its priority will never be boosted. In essential, they should be same becase both of them are waiting for cpu. If I am a thread, I'd like to wait on sleep queue rather than on runqueue, since in former case, I will get bonus, while in later case, I'll get nothing. Under heavy load, there are many runnable threads, this unfair can cause a very low priority thread on runqueue to be starved. 4BSD seems not suffer from this problem, because it also decay cpu time of thread on runqueue. I think ULE needs some anti-starvation code to give thread a shot if it is waiting on runqueue too long time. Regards, David Xu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10-CURRENT clock_getcpuclockid() usage
On 2012/09/08 23:31, Kim Culhan wrote: clock_getcpuclockid() was added a few weeks ago according to the man page and I'm seeing this error while building the port net/freeswith-core-devel. The function is used in the Sofia-sip stack, courtesy Nokia Research Center, incorporated into FreeSWITCH. The build system tests for the presence of clock_getcpuclockid() and finds it but in the error messages 'clock_getcpuclockid2' is mentioned. Any thoughts on the clock_getcpuclockid() usage would be very greatly appreciated. LTCOMPILE su_time.lo su_time.c:410:14: error: implicit declaration of function 'clock_getcpuclockid' is invalid in C99 [-Werror,-Wimplicit-function-declaration] else if (clock_getcpuclockid(0, cpu) != -1 ^ su_time.c:410:14: note: did you mean 'clock_getcpuclockid2'? else if (clock_getcpuclockid(0, cpu) != -1 ^~~ clock_getcpuclockid2 /usr/include/sys/time.h:352:5: note: 'clock_getcpuclockid2' declared here int clock_getcpuclockid2(id_t, int, clockid_t *); ^ 1 error generated. gmake[9]: *** [su_time.lo] Error 1 thanks -kim I have committed a patch, please try it. http://svnweb.freebsd.org/base/head/include/time.h?r1=233600r2=240295 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: jemalloc: qdbus sigsegv in malloc_init
On 2012/4/30 22:13, Gustau Pérez i Querol wrote:
Hi,
the kde team is seeing some strange problems with the new version
(4.8.1) of devel/dbus-qt4 with current. It does work with stable. I
also suspect that the problem described below is affecting the
experimental cinnamon port (an alternative to gnome3, possible
replacement of gnome2).
The problem happens with both i386 and amd64 with empty
/etc/malloc.conf and simple /etc/make.conf. Everything compiled with
base gcc (no clang). The kernel was compiled with no debug support,
but it can enable if needed. There are reports from avi...@freebsd.org
of the same behavior with clang compiled world and kernel and with
MALLOC_PRODUCTION=yes.
When qdbus starts, it segfauts. The backtrace of the problem with
r234769 can be found here: http://pastebin.com/ryBXtqGF. When starting
the qdbus daemon by hand in a X+twm session, we see it calls calloc
many times and after a fixed number of times segfaults. We see it
segfaults at rb_gen (a quite large macro defined at
$SRC_BASE/contrib/jemalloc/include/jemalloc/internal/rb.h).
If the daemon is started by hand, I'm able to skip all the calls
qdbus makes to calloc till the one causing the segfault. At that
point, at rb_gen, we don't exactly know what is going on or how to
debug the macro. Ktrace are available, but we were unable to find
anything new from them.
With old versions of current before the jemalloc imports (as of
March 30th) the daemon segfaulted at malloc.c:2426. With revisions
during April 20 to 24th (can be more precise, it was during the
jemalloc imports) the daemon segfaulted at malloc_init. Bts are
available if needed, and if necessary I can go back to those revision
and recompile world+kernel to see its behavior.
Any help from freebsd-current@ (perhaps Jason Evans can help us)
will be appreciated. Any additional info, like source revisions, can
be provided. I would like to stress that the experimental
devel/dbus-qt4 works fine with recent stable.
qdbus segfaults on my machine too, I tracked it down, and found the
problem is in QT,
it deleted current_thread_data_key, but it still uses it in some cxa
hooks, I applied the
following patch, and it works fine.
--- qthread_unix.cpp2012-05-20 13:23:09.0 +0800
+++ qthread_unix_new.cpp2012-05-20 13:22:45.0 +0800
@@ -156,7 +156,7 @@
{
pthread_key_delete(current_thread_data_key);
}
-Q_DESTRUCTOR_FUNCTION(destroy_current_thread_data_key)
+//Q_DESTRUCTOR_FUNCTION(destroy_current_thread_data_key)
// Utility functions for getting, setting and clearing thread specific
data.
---
the Q_DESTRUCTOR_FUNCTION defined global a C++ object, and in its
destructor,
it deletes the current_thread_data_key, but in other cxa hooks, the key
is still needed.
So, finally the QT library crashed.
I think the bug depends on linking order in QT library ? if the
qthread_unix.cpp is linked
as lastest module, the key will be deleted after all cxa hooks run, then
it will be fine,
otherwise, it would crash. This sounds like a bug in QT.
Regards,
David Xu
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: jemalloc: qdbus sigsegv in malloc_init
On 2012/5/21 1:24, Konstantin Belousov wrote:
On Sun, May 20, 2012 at 06:42:35PM +0200, Alberto Villa wrote:
On Sun, May 20, 2012 at 8:03 AM, David Xulistlog2...@gmail.com wrote:
qdbus segfaults on my machine too, I tracked it down, and found the problem
is in QT,
it deleted current_thread_data_key, but it still uses it in some cxa hooks,
I applied the
following patch, and it works fine.
Thanks for the analysis David!
I think the bug depends on linking order in QT library ? if the
qthread_unix.cpp is linked
as lastest module, the key will be deleted after all cxa hooks run, then it
will be fine,
otherwise, it would crash.
Is this really possible?
No, I do not think it is possible.
The only possibility for something weird happen is for atexit/__cxa_atexit
functions to be registered from another atexit function, and then we
indeed could call the newly registered function too late.
I wonder if the following hack makes any change in the observed behaviour.
diff --git a/lib/libc/stdlib/atexit.c b/lib/libc/stdlib/atexit.c
index 511172a..bab850c 100644
--- a/lib/libc/stdlib/atexit.c
+++ b/lib/libc/stdlib/atexit.c
@@ -72,6 +72,7 @@ struct atexit {
};
static struct atexit *__atexit; /* points to head of LIFO stack
*/
+static int atexit_gen;
/*
* Register the function described by 'fptr' to be called at application
@@ -107,6 +108,7 @@ atexit_register(struct atexit_fn *fptr)
__atexit = p;
}
p-fns[p-ind++] = *fptr;
+ atexit_gen++;
_MUTEX_UNLOCK(atexit_mutex);
return 0;
}
@@ -162,7 +164,7 @@ __cxa_finalize(void *dso)
struct dl_phdr_info phdr_info;
struct atexit *p;
struct atexit_fn fn;
- int n, has_phdr;
+ int atexit_gen_prev, n, has_phdr;
if (dso != NULL)
has_phdr = _rtld_addr_phdr(dso,phdr_info);
@@ -170,6 +172,8 @@ __cxa_finalize(void *dso)
has_phdr = 0;
_MUTEX_LOCK(atexit_mutex);
+retry:
+ atexit_gen_prev = atexit_gen;
for (p = __atexit; p; p = p-next) {
for (n = p-ind; --n= 0;) {
if (p-fns[n].fn_type == ATEXIT_FN_EMPTY)
@@ -196,6 +200,8 @@ __cxa_finalize(void *dso)
_MUTEX_LOCK(atexit_mutex);
}
}
+ if (atexit_gen_prev != atexit_gen)
+ goto retry;
_MUTEX_UNLOCK(atexit_mutex);
if (dso == NULL)
_MUTEX_DESTROY(atexit_mutex);
I have tried your patch, it does not fix the problem. As I said, it is
a bug in QT,
the bug is pthread key current_thread_data_key is deleted by a global
C++ object
too early, other C++ global objects still need this pthread key. The
following procedure
shows how I found the problem:
davidxu@xyf:~%gdb qdbus
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...(no debugging symbols
found)...
(gdb) break __cxa_finalize
Function __cxa_finalize not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (__cxa_finalize) pending.
(gdb) run
Starting program: /usr/local/bin/qdbus
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...(no debugging symbols
found)...[New LWP 100077]
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...Breakpoint 2 at 0x2864ac26
Pending breakpoint __cxa_finalize resolved
(no debugging symbols found)...[New Thread 29007300 (LWP 100077/qdbus)]
(no debugging symbols found)...:1.0
org.gnome.SessionManager
:1.11
:1.111
:1.12
:1.13
org.gtk.vfs.Daemon
:1.143
:1.15
org.pulseaudio.Server
:1.17
org.gnome.Panel
:1.18
:1.19
:1.20
org.gtk.Private.HalVolumeMonitor
:1.21
org.gtk.Private.GPhoto2VolumeMonitor
:1.22
:1.24
org.gnome.ScreenSaver
:1.25
:1.27
:1.28
:1.29
:1.30
:1.31
org.gnome.panel.applet.WnckletFactory
:1.32
:1.33
:1.34
:1.35
org.gnome.panel.applet.CPUFreqAppletFactory
:1.36
org.gnome.panel.applet.NotificationAreaAppletFactory
:1.37
org.gnome.panel.applet.MultiLoadAppletFactory
:1.38
:1.39
:1.4
org.gnome.GConf
:1.41
org.gnome.panel.applet.ClockAppletFactory
:1.49
:1.5
org.gnome.SettingsDaemon
:1.50
:1.53
:1.64
:1.7
org.freedesktop.secrets
org.gnome.keyring
:1.75
org.gtk.vfs.Metadata
:1.76
org.gnome.Terminal.Display_0_0
:1.77
org.freedesktop.DBus
[Switching to Thread 29007300 (LWP 100077/qdbus)]
Breakpoint 2, 0x2864ac26 in
Re: RFC: jemalloc: qdbus sigsegv in malloc_init
On 2012/5/21 10:54, David Xu wrote:
On 2012/5/21 1:24, Konstantin Belousov wrote:
On Sun, May 20, 2012 at 06:42:35PM +0200, Alberto Villa wrote:
On Sun, May 20, 2012 at 8:03 AM, David Xulistlog2...@gmail.com
wrote:
qdbus segfaults on my machine too, I tracked it down, and found the
problem
is in QT,
it deleted current_thread_data_key, but it still uses it in some
cxa hooks,
I applied the
following patch, and it works fine.
Thanks for the analysis David!
I think the bug depends on linking order in QT library ? if the
qthread_unix.cpp is linked
as lastest module, the key will be deleted after all cxa hooks run,
then it
will be fine,
otherwise, it would crash.
Is this really possible?
No, I do not think it is possible.
The only possibility for something weird happen is for
atexit/__cxa_atexit
functions to be registered from another atexit function, and then we
indeed could call the newly registered function too late.
I wonder if the following hack makes any change in the observed
behaviour.
diff --git a/lib/libc/stdlib/atexit.c b/lib/libc/stdlib/atexit.c
index 511172a..bab850c 100644
--- a/lib/libc/stdlib/atexit.c
+++ b/lib/libc/stdlib/atexit.c
@@ -72,6 +72,7 @@ struct atexit {
};
static struct atexit *__atexit;/* points to head of LIFO
stack */
+static int atexit_gen;
/*
* Register the function described by 'fptr' to be called at
application
@@ -107,6 +108,7 @@ atexit_register(struct atexit_fn *fptr)
__atexit = p;
}
p-fns[p-ind++] = *fptr;
+atexit_gen++;
_MUTEX_UNLOCK(atexit_mutex);
return 0;
}
@@ -162,7 +164,7 @@ __cxa_finalize(void *dso)
struct dl_phdr_info phdr_info;
struct atexit *p;
struct atexit_fn fn;
-int n, has_phdr;
+int atexit_gen_prev, n, has_phdr;
if (dso != NULL)
has_phdr = _rtld_addr_phdr(dso,phdr_info);
@@ -170,6 +172,8 @@ __cxa_finalize(void *dso)
has_phdr = 0;
_MUTEX_LOCK(atexit_mutex);
+retry:
+atexit_gen_prev = atexit_gen;
for (p = __atexit; p; p = p-next) {
for (n = p-ind; --n= 0;) {
if (p-fns[n].fn_type == ATEXIT_FN_EMPTY)
@@ -196,6 +200,8 @@ __cxa_finalize(void *dso)
_MUTEX_LOCK(atexit_mutex);
}
}
+if (atexit_gen_prev != atexit_gen)
+goto retry;
_MUTEX_UNLOCK(atexit_mutex);
if (dso == NULL)
_MUTEX_DESTROY(atexit_mutex);
I have tried your patch, it does not fix the problem. As I said, it
is a bug in QT,
the bug is pthread key current_thread_data_key is deleted by a global
C++ object
too early, other C++ global objects still need this pthread key. The
following procedure
shows how I found the problem:
davidxu@xyf:~%gdb qdbus
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-marcel-freebsd...(no debugging
symbols found)...
(gdb) break __cxa_finalize
Function __cxa_finalize not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (__cxa_finalize) pending.
(gdb) run
Starting program: /usr/local/bin/qdbus
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...[New LWP 100077]
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...Breakpoint 2
at 0x2864ac26
Pending breakpoint __cxa_finalize resolved
(no debugging symbols found)...[New Thread 29007300 (LWP 100077/qdbus)]
(no debugging symbols found)...:1.0
org.gnome.SessionManager
:1.11
:1.111
:1.12
:1.13
org.gtk.vfs.Daemon
:1.143
:1.15
org.pulseaudio.Server
:1.17
org.gnome.Panel
:1.18
:1.19
:1.20
org.gtk.Private.HalVolumeMonitor
:1.21
org.gtk.Private.GPhoto2VolumeMonitor
:1.22
:1.24
org.gnome.ScreenSaver
:1.25
:1.27
:1.28
:1.29
:1.30
:1.31
org.gnome.panel.applet.WnckletFactory
:1.32
:1.33
:1.34
:1.35
org.gnome.panel.applet.CPUFreqAppletFactory
:1.36
org.gnome.panel.applet.NotificationAreaAppletFactory
:1.37
org.gnome.panel.applet.MultiLoadAppletFactory
:1.38
:1.39
:1.4
org.gnome.GConf
:1.41
org.gnome.panel.applet.ClockAppletFactory
:1.49
:1.5
org.gnome.SettingsDaemon
:1.50
:1.53
:1.64
:1.7
org.freedesktop.secrets
org.gnome.keyring
:1.75
org.gtk.vfs.Metadata
:1.76
org.gnome.Terminal.Display_0_0
:1.77
org.freedesktop.DBus
[Switching to Thread 29007300 (LWP 100077/qdbus)]
Breakpoint 2, 0x2864ac26 in __cxa_finalize () from /lib/libc.so.7
(gdb) print
Re: ctfmerge core dump
On 2012/5/6 5:08, b. f. wrote: On 5/5/12, Steve Willsswi...@freebsd.org wrote: On 05/05/12 15:43, b. f. wrote: Steve Wills wrote: After updating from -CURRENT as of April 5 to one built today, I now get a core dump running ctfmerge on libc: ctfmerge -L VERSION -g -o libc.so.7 syscall.So fork.So.. Bus error (core dumped) *** [libc.so.7] Error code 138 Anyone else seeing this or have any idea how to avoid it? Yes, I'm also seeing such problems when attempting to build a r235052 amd64 kernel on r235035 amd64. (This problem did not occur when building a r235035 amd64 world and kernel on r234854 amd64.) ctfmerge succeeds for several kernel modules but fails with kgssapi.ko.debug, linux.ko.debug, or kernel.debug. I'm not yet sure which change has caused this, or how to avoid it. Thanks for the info. I took a look at the dump and see this: % sudo gdb /usr/bin/ctfmerge ctfmerge.core [GDB will not be able to debug user-mode threads: Undefined symbol td_thr_getxmmregs] Hmm, is the thread debugging broken on amd64 now ? td_thr_getxmmregs resides in libthread_db and /usr/src/gnu/usr.bin/gdb/libgdb is complaining about the missing symbol. GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Core was generated by `ctfmerge'. Program terminated with signal 10, Bus error. Reading symbols from /lib/libctf.so.2...done. Loaded symbols for /lib/libctf.so.2 Reading symbols from /usr/lib/libdwarf.so.3...done. Loaded symbols for /usr/lib/libdwarf.so.3 Reading symbols from /usr/lib/libelf.so.1...done. Loaded symbols for /usr/lib/libelf.so.1 Reading symbols from /lib/libz.so.6...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 128 for (i = 0, fn = f-f_head; fn; fn = fn-fn_next, i++); (gdb) bt #0 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 #1 0x0040622c in worker_thread (wq=0x610ee0) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c:329 #2 0x000801078da9 in thread_start (curthread=0x801c0f800) at /usr/src/lib/libthr/thread/thr_create.c:284 #3 0x in ?? () Cannot access memory at address 0x7f5fb000 (gdb) After reverting the recent libthr changes in r234947, I am no longer encountering this problem. b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ctfmerge core dump
On 2012/5/6 5:08, b. f. wrote: On 5/5/12, Steve Willsswi...@freebsd.org wrote: On 05/05/12 15:43, b. f. wrote: Steve Wills wrote: After updating from -CURRENT as of April 5 to one built today, I now get a core dump running ctfmerge on libc: ctfmerge -L VERSION -g -o libc.so.7 syscall.So fork.So.. Bus error (core dumped) *** [libc.so.7] Error code 138 Anyone else seeing this or have any idea how to avoid it? Yes, I'm also seeing such problems when attempting to build a r235052 amd64 kernel on r235035 amd64. (This problem did not occur when building a r235035 amd64 world and kernel on r234854 amd64.) ctfmerge succeeds for several kernel modules but fails with kgssapi.ko.debug, linux.ko.debug, or kernel.debug. I'm not yet sure which change has caused this, or how to avoid it. Thanks for the info. I took a look at the dump and see this: % sudo gdb /usr/bin/ctfmerge ctfmerge.core [GDB will not be able to debug user-mode threads: Undefined symbol td_thr_getxmmregs] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Core was generated by `ctfmerge'. Program terminated with signal 10, Bus error. Reading symbols from /lib/libctf.so.2...done. Loaded symbols for /lib/libctf.so.2 Reading symbols from /usr/lib/libdwarf.so.3...done. Loaded symbols for /usr/lib/libdwarf.so.3 Reading symbols from /usr/lib/libelf.so.1...done. Loaded symbols for /usr/lib/libelf.so.1 Reading symbols from /lib/libz.so.6...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 128 for (i = 0, fn = f-f_head; fn; fn = fn-fn_next, i++); (gdb) bt #0 0x004064b0 in fifo_len (f=0x801c29070) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/fifo.c:128 #1 0x0040622c in worker_thread (wq=0x610ee0) at /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfmerge.c:329 #2 0x000801078da9 in thread_start (curthread=0x801c0f800) at /usr/src/lib/libthr/thread/thr_create.c:284 #3 0x in ?? () Cannot access memory at address 0x7f5fb000 (gdb) After reverting the recent libthr changes in r234947, I am no longer encountering this problem. b. I have fixed it in r235068. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SeaMonkey eats the CPU as of r232144
On 2012/3/3 1:01, Adrian Chadd wrote: Ok. So it's that exact commit? david, what did you break? :) Adrian I am also running the seamonkey and can not reproduce the problem. maybe he did hit the race window when I was committing the patches ? can he update and install the world and kernel again to see if the problem is still existing ? Regards, David Xu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SeaMonkey eats the CPU as of r232144
On 2012/3/3 4:24, deeptec...@gmail.com wrote:
A truss snippet from running with an older-than-r232144 kernel:
clock_gettime(4,{29653.159790037 }) = 0 (0x0)
write(12,\M-z,1) = 1 (0x1)
clock_gettime(4,{29653.160165225 }) = 0 (0x0)
gettimeofday({1330716922.220648 },0x0) = 0 (0x0)
read(11,\M-z,1) = 1 (0x1)
clock_gettime(4,{29653.160696018 }) = 0 (0x0)
clock_gettime(4,{29653.160836819 }) = 0 (0x0)
clock_gettime(4,{29653.160983765 }) = 0 (0x0)
clock_gettime(4,{29653.161112552 }) = 0 (0x0)
_umtx_op(0x2b115068,0x10,0x7fff,0x0,0x0,0x29d37dd4) = 0 (0x0)
clock_gettime(4,{29653.161450863 }) = 0 (0x0)
gettimeofday({1330716922.221944 },0x0) = 0 (0x0)
gettimeofday({1330716922.222150 },0x0) = 0 (0x0)
read(4,0x2c940018,4096) ERR#35 'Resource temporarily
unavailable'
poll({5/POLLIN 4/POLLIN 20/POLLIN|POLLPRI 22/POLLIN|POLLPRI
23/POLLIN|POLLPRI 24/POLLIN|POLLPRI 11/POLLIN},7,0) = 0 (0x0)
gettimeofday({1330716922.222624 },0x0) = 0 (0x0)
read(4,0x2c940018,4096) ERR#35 'Resource temporarily
unavailable'
poll({5/POLLIN 4/POLLIN 20/POLLIN|POLLPRI 22/POLLIN|POLLPRI
23/POLLIN|POLLPRI 24/POLLIN|POLLPRI 11/POLLIN},7,0) = 0 (0x0)
gettimeofday({1330716922.223087 },0x0) = 0 (0x0)
read(4,0x2c940018,4096) ERR#35 'Resource temporarily
unavailable'
poll({5/POLLIN 4/POLLIN 20/POLLIN|POLLPRI 22/POLLIN|POLLPRI
23/POLLIN|POLLPRI 24/POLLIN|POLLPRI 11/POLLIN},7,0) = 0 (0x0)
gettimeofday({1330716922.223537 },0x0) = 0 (0x0)
read(4,0x2c940018,4096) ERR#35 'Resource temporarily
unavailable'
A truss snippet from running with an r232144 kernel:
_umtx_op(0x2b115068,0xf,0x0,0x1,0xbf4f9e2c,0x0) ERR#60 'Operation
timed out'
clock_gettime(4,{111.526717958 }) = 0 (0x0)
gettimeofday({1330717178.580346 },0x0) = 0 (0x0)
_umtx_op(0x2b115068,0xf,0x0,0x1,0xbf4f9e2c,0x0) = 0 (0x0)
clock_gettime(4,{111.527204892 }) = 0 (0x0)
gettimeofday({1330717178.580840 },0x0) = 0 (0x0)
_umtx_op(0x2b115068,0xf,0x0,0x1,0xbf4f9e2c,0x0) ERR#60 'Operation
timed out'
clock_gettime(4,{111.527649362 }) = 0 (0x0)
gettimeofday({1330717178.581284 },0x0) = 0 (0x0)
_umtx_op(0x2b115068,0xf,0x0,0x1,0xbf4f9e2c,0x0) ERR#60 'Operation
timed out'
clock_gettime(4,{111.528068968 }) = 0 (0x0)
gettimeofday({1330717178.581696 },0x0) = 0 (0x0)
gettimeofday({1330717178.581816 },0x0) = 0 (0x0)
_umtx_op(0x2b115068,0xf,0x0,0x1,0xbf4f9e2c,0x0) ERR#60 'Operation
timed out'
clock_gettime(4,{111.528613451 }) = 0 (0x0)
read(4,0x2c940018,4096) ERR#35 'Resource temporarily
unavailable'
gettimeofday({1330717178.582380 },0x0) = 0 (0x0)
_umtx_op(0x2b115068,0xf,0x0,0x1,0xbf4f9e2c,0x0) ERR#60 'Operation
timed out'
clock_gettime(4,{111.529161565 }) = 0 (0x0)
poll({5/POLLIN 4/POLLIN 20/POLLIN|POLLPRI 22/POLLIN|POLLPRI
23/POLLIN|POLLPRI 24/POLLIN|POLLPRI 11/POLLIN},7,0) = 0 (0x0)
gettimeofday({1330717178.582956 },0x0) = 0 (0x0)
gettimeofday({1330717178.583142 },0x0) = 0 (0x0)
clock_gettime(4,{111.529783432 }) = 0 (0x0)
read(4,0x2c940018,4096) ERR#35 'Resource temporarily
unavailable'
gettimeofday({1330717178.583550 },0x0) = 0 (0x0)
poll({5/POLLIN 4/POLLIN 20/POLLIN|POLLPRI 22/POLLIN|POLLPRI
23/POLLIN|POLLPRI 24/POLLIN|POLLPRI 11/POLLIN},7,0) = 0 (0x0)
gettimeofday({1330717178.590610 },0x0) = 0 (0x0)
read(4,0x2c940018,4096) ERR#35 'Resource temporarily
unavailable'
poll({5/POLLIN 4/POLLIN 20/POLLIN|POLLPRI 22/POLLIN|POLLPRI
23/POLLIN|POLLPRI 24/POLLIN|POLLPRI 11/POLLIN},7,0) = 0 (0x0)
gettimeofday({1330717178.591162 },0x0) = 0 (0x0)
read(4,0x2c940018,4096) ERR#35 'Resource temporarily
unavailable'
_umtx_op(0x2b115068,0xf,0x0,0x1,0xbf4f9e2c,0x0) ERR#60 'Operation
timed out'
clock_gettime(4,{111.538268868 }) = 0 (0x0)
gettimeofday({1330717178.591910 },0x0) = 0 (0x0)
_umtx_op(0x2b115068,0xf,0x0,0x1,0xbf4f9e2c,0x0) ERR#60 'Operation
timed out'
clock_gettime(4,{111.538700487 }) = 0 (0x0)
gettimeofday({1330717178.592328 },0x0) = 0 (0x0)
_umtx_op(0x2b115068,0xf,0x0,0x1,0xbf4f9e2c,0x0) ERR#60 'Operation
timed out'
I suspect that your kernel and libthr are out of sync. You have
installed only new version of kernel
or libthr and forgotten to install another ? With -CURRENT, it is better
to update whole tree and
install whole tree includes kernel.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [ptrace] please review follow fork/exec changes
On 2012/1/26 7:48, Dmitry Mikulin wrote: snip The debugger needs to intercept fork() in both parent and child so it can detach from the old process and attach to the new one. Maybe it'll make more sense in the context of gdb changes. Should I send them too? Don't think Marcel included that patch... Does the orphan list change intended to not lost the child after fork ? But the child shall be traced, so debugger would get the SIGTRAP on the attach on fork returning to usermode. I remember that I explicitely tested this when adding followfork changes. Yes, the debugger gets SIGTRAPs. The problem arises when the real parent of the forked process has the code to collect termination status. Since attaching to a process changes the parent/child relationships, we need to keep track of the children lost due to re-parenting so we can properly attribute their exit status to the real parent. I recall that someone brought a topic in the list said that this should be fixed, debugging a process should not change parent-child relation, instead a new link list data structure should be added to struct proc to trace debugged process, this will make code clean with a small memory overhead. Regards, David Xu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: atkbdc broken on current ?
On 2011/05/05 21:21, Damjan Marion wrote: Hi, I have issue with old HP DL380G3 server. When I use ILO virtual console to manage server. Seems that 9-CURRENT fails to detect atkbdc. When I boot 8.2-RELEASE it works well. 8.2 dmesg shows: atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 9.0: atkbdc0: Keyboard controller (i8042) failed to probe at port 0x60 on isa0 Is this a known issue? Should I enable some additional outputs, like KBDIO_DEBUG? Thanks, Damjan One problem I found is if I remove PS/2 keyboard and use a USB keyboard, I can not use PS/2 mouse, it will not be detected. David Xu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: svn commit: r214611 - head/sys/kern
On 2011/06/15 15:39, Kostik Belousov wrote: This patch accomodates the userland to the changed ABI. Why it was changed at all ? I would argue that keeping the stable ABI there is more important then using a 'clean' type. At least, the stable branches usermode is broken on the current kernel. Does stable/8 support _SC_CPUSET_SIZE ? I have not looked code in stable. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: svn commit: r214611 - head/sys/kern
On 2011/06/14 20:02, Sergey Kandaurov wrote:
On 1 November 2010 03:42, David Xu davi...@freebsd.org wrote:
Author: davidxu
Date: Mon Nov 1 00:42:25 2010
New Revision: 214611
URL: http://svn.freebsd.org/changeset/base/214611
Log:
Use integer for size of cpuset, as it won't be bigger than INT_MAX,
This is requested by bge.
Also move the sysctl into file kern_cpuset.c, because it should
always be there, it is independent of thread scheduler.
Hi.
This breaks for me fetching a cpusetsize value with sysconf(3) interface,
as after this change sysconf(3) consumers expect a long return type, while
sysctl kern.sched.cpusetsize has switched from long to int type in kernel.
That makes for me sizeof(cpusize_t) from 8 to incorrect 34359738376.
In particular, kvm_getpcpu(3) uses sysconf(3) to fetch cpusetsize on
live kernel. That gives me a broken result:
kvm_open: kcpusetsize: 8
pcpu[0] = 0x801072300
kvm_open: kcpusetsize: 34359738376
pcpu[1] = 0x
kvm_open: kcpusetsize: 8
pcpu[2] = 0x801072600
kvm_open: kcpusetsize: 34359738376
pcpu[3] = 0x
This small test indicates that that's due to int-long type conversion:
long lvalue;
size_t len;
len = sizeof(lvalue);
if (sysctlbyname(kern.sched.cpusetsize, lvalue, len, NULL, 0) 0)
err(1, sysctlbyname);
printf(sysctl: %ld\n, lvalue);
printf(sysctl: %d -- explicitly casted to (int)\n, (int)lvalue);
printf(sysconf: %ld\n, sysconf(_SC_CPUSET_SIZE));
printf(sysconf: %d -- explicitly casted to (int)\n,
(int)sysconf(_SC_CPUSET_SIZE));
That prints:
sysctl: 34359738376
sysctl: 8 -- explicitly casted to (int)
sysconf: 34359738376
sysconf: 8 -- explicitly casted to (int)
The other way to solve this other than reverting is to fix all cpusetsize
consumers in userland. Now sysconf() saves long returned value to int:
Index: lib/libkvm/kvm_pcpu.c
===
--- lib/libkvm/kvm_pcpu.c (revision 223073)
+++ lib/libkvm/kvm_pcpu.c (working copy)
@@ -120,7 +120,7 @@
void *
kvm_getpcpu(kvm_t *kd, int cpu)
{
- long kcpusetsize;
+ int kcpusetsize;
ssize_t nbytes;
uintptr_t readptr;
char *buf;
So, after applying the above change all is ok:
kvm_open: kcpusetsize: 8
pcpu[0] = 0x801072300
kvm_open: kcpusetsize: 8
pcpu[1] = 0x801072600
kvm_open: kcpusetsize: 8
pcpu[2] = 0x801072900
kvm_open: kcpusetsize: 8
pcpu[3] = 0x801072c00
Try this patch, I think it should fix it.
Index: lib/libc/gen/sysconf.c
===
--- lib/libc/gen/sysconf.c (revision 221356)
+++ lib/libc/gen/sysconf.c (working copy)
@@ -599,11 +599,11 @@
#ifdef _SC_CPUSET_SIZE
case _SC_CPUSET_SIZE:
- len = sizeof(lvalue);
- if (sysctlbyname(kern.sched.cpusetsize, lvalue, len, NULL,
+ len = sizeof(value);
+ if (sysctlbyname(kern.sched.cpusetsize, value, len, NULL,
0) == -1)
return (-1);
- return (lvalue);
+ return ((long)(value));
#endif
default:
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Call _thr_check_init() from _pthread_once
On 2011/04/20 00:53, Ryan Stone wrote:
In r179417 the implementation of pthread_once in libthr was changed
from using a global pthread_mutex_t for synchronization to rolling its
own synchronization mechanism. Unfortunately, this introduced a bug.
Calling _pthread_mutex_lock implicitly ensured that _thr_check_init()
had been called. In the current version, there is no such guarantee.
This means that if your first call into libthr is pthread_once, your
executable will segfault when it tries to access curthread. This
patch resolves the issue for me:
Index: lib/libthr/thread/thr_once.c
===
--- lib/libthr/thread/thr_once.c(revision 220603)
+++ lib/libthr/thread/thr_once.c(working copy)
@@ -64,6 +64,8 @@
struct pthread *curthread;
int state;
+ _thr_check_init();
+
for (;;) {
state = once_control-state;
if (state == ONCE_DONE)
If there are no objections I'll commit this soon.
Have you tested that current code causes segfault ?
anyway, I can not reproduce it on my machne.
Regards,
David Xu
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Call _thr_check_init() from _pthread_once
On 2011/04/20 10:48, Ryan Stone wrote: On Tue, Apr 19, 2011 at 10:13 PM, David Xu davi...@freebsd.org wrote: Have you tested that current code causes segfault ? anyway, I can not reproduce it on my machne. Regards, David Xu Yes, I had an application where libstdc++ was calling pthread_once while constructing a static object. As near as I can tell it's pure luck as to whether you'll hit this crash or not. If the linker happens to place a static initializer that calls pthread_once first in the list of static initializers, you crash. If instead something far more likely like pthread_mutex_lock is called first, you're fine. The backtrace for my executable was something like: #0 0x684dadd4 in _pthread_once (once_control=0x6887fdcc, init_routine=0x6883d740 __gthread_trigger()) at /usr/src/lib/libthr/thread/thr_once.c:84 #1 0x6883d992 in __gthread_active_p () at /tmp/buildutils.x86/x86-i686-pc-freebsd8/i686-pc-freebsd8/libstdc++-v3/include/i686-pc-freebsd8/bits/gthr-default.h:221 #2 __eh_globals_init () at gcc/libstdc++-v3/libsupc++/eh_globals.cc:98 #3 __static_initialization_and_destruction_0 () at gcc/libstdc++-v3/libsupc++/eh_globals.cc:110 #4 global constructors keyed to eh_globals.cc(void) () at gcc/libstdc++-v3/libsupc++/eh_globals.cc:146 #5 0x68848d06 in __do_global_ctors_aux () from /usr/local/mumble/lib/libstdc++.so.6 But I don't touch curthread unless it is blocked by another thread. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Call _thr_check_init() from _pthread_once
On 2011/04/20 10:48, Ryan Stone wrote: On Tue, Apr 19, 2011 at 10:13 PM, David Xu davi...@freebsd.org wrote: Have you tested that current code causes segfault ? anyway, I can not reproduce it on my machne. Regards, David Xu Yes, I had an application where libstdc++ was calling pthread_once while constructing a static object. As near as I can tell it's pure luck as to whether you'll hit this crash or not. If the linker happens to place a static initializer that calls pthread_once first in the list of static initializers, you crash. If instead something far more likely like pthread_mutex_lock is called first, you're fine. The backtrace for my executable was something like: #0 0x684dadd4 in _pthread_once (once_control=0x6887fdcc, init_routine=0x6883d740 __gthread_trigger()) at /usr/src/lib/libthr/thread/thr_once.c:84 #1 0x6883d992 in __gthread_active_p () at /tmp/buildutils.x86/x86-i686-pc-freebsd8/i686-pc-freebsd8/libstdc++-v3/include/i686-pc-freebsd8/bits/gthr-default.h:221 #2 __eh_globals_init () at gcc/libstdc++-v3/libsupc++/eh_globals.cc:98 #3 __static_initialization_and_destruction_0 () at gcc/libstdc++-v3/libsupc++/eh_globals.cc:110 #4 global constructors keyed to eh_globals.cc(void) () at gcc/libstdc++-v3/libsupc++/eh_globals.cc:146 #5 0x68848d06 in __do_global_ctors_aux () from /usr/local/mumble/lib/libstdc++.so.6 OK, I understand, that current INPROGRESS will push cleanup routine, so the curthread is used, your patch is right. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CFT(2): patch for process shared pthread objects
David Xu wrote: David Xu wrote: Hi, I finally have worked out first patch to make our pthread library support process shared pthread objects: http://people.freebsd.org/~davidxu/pshared/patch1.diff Patch is updated: http://people.freebsd.org/~davidxu/pshared/patch2.diff Changes: 1) Macro _POSIX_THREAD_PROCESS_SHARED in unistd.h is changed, now its value is 200112L. 2) Version of libgcc is bumped. 3) Thread cancellation is fixed in pthread_cond_wait(), this should make csup run again. I have updated patch again: http://people.freebsd.org/~davidxu/pshared/patch6.diff This time, process shared priority-inherit mutex is supported. Now my machine is running with various threaded applications and a gnome desktop, I have not found any problem. I wish the patch can be committed before 9.0 release. :-) Regards, David Xu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CFT(2): patch for process shared pthread objects
I have updated patch again: http://people.freebsd.org/~davidxu/pshared/patch6.diff This time, process shared priority-inherit mutex is supported. Now my machine is running with various threaded applications and a gnome desktop, I have not found any problem. I wish the patch can be committed before 9.0 release. :-) Regards, David Xu Note that you should update source tree before applying this patch. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
John Baldwin wrote: On Tuesday, December 07, 2010 9:54:05 pm David Xu wrote: John Baldwin wrote: On Monday, December 06, 2010 7:11:28 pm David Xu wrote: John Baldwin wrote: On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: Sometime in the last 7-10 days, some one made a change that has broken process accounting/timing. laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) foreach? time ./testf foreach? end Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.55 real38.39 user30.94 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.82 real40.95 user27.60 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.14 real38.90 user30.02 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.79 real40.59 user27.99 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.93 real39.76 user28.96 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.71 real41.21 user27.29 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.05 real39.68 user29.15 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.99 real39.98 user28.80 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.02 real39.64 user29.16 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.38 real37.49 user31.67 sys testf is a numerically intensive program that tests the accuracy of expf() in a tight loop. User time varies by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. I'm fairly certain that the code does not suddenly grow/loose 6 GFLOP of operations. The user/sys thing is a hack (and has been). We sample the PC at stathz (~128 hz) to figure out a user vs sys split and use that to divide up the total runtime (which actually is fairly accurate). All you need is for the clock ticks to fire just a bit differently between runs to get a swing in user vs system time. What I would like is to keep separate raw bintime's for user vs system time in the raw data instead, but that would involve checking the CPU ticker more often (e.g. twice for each syscall, interrupt, and trap in addition to the current once per context switch). So far folks seem to be more worried about the extra overhead rather than the loss of accuracy. Adding any instruction into global syscall path should be cautioned, it is worse then before, thinking about a threaded application, a userland thread may have locked a mutex and calls a system call, the overhead added to system call path can directly affect a threaded application's performance now, because the time window the mutex is held is longer than before, I have seen some people likes to fiddle with system call path, it should be cautioned. OTOH, the current getrusage(2) stats cannot be trusted. The only meaningful thing you can do is to sum them since the total is known to be accurate at least. If it wouldn't make things so messy I'd consider a new kernel option 'ACCURATE_RUSAGE' or some such. Our getrusage is already very slow, everytime, it needs to iterate the threads list with a process SLOCK held. I saw some mysql versions heavily use getrusage, and a horribly slow. I think a ACCURATE_RUSAGE will make it worse ? Using 'time foo' only retrieves the usage once at the end via wait(). However, FWIW, I think ACCURATE_RUSAGE would simplify calcru1() quite a bit since you would just sum up the thread's usage (as we do know), but then do a direct conversion from bintime to timeval for user and system without ever having to worry about time going backwards, etc. All the hacks to enforce monotonicity that are currently in place would go away since we would have the real measurements and not be inferring them from statclock ticks. I don't worry getrusage, though it is not necessary that it is used with wait(), I saw mysql used it to measure its internal code's performance, it did not use it with wait(), it is questionable if this usage is correct. However, I worry anyone who adds overhead to system call path. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
John Baldwin wrote: On Monday, December 06, 2010 7:11:28 pm David Xu wrote: John Baldwin wrote: On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: Sometime in the last 7-10 days, some one made a change that has broken process accounting/timing. laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) foreach? time ./testf foreach? end Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.55 real38.39 user30.94 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.82 real40.95 user27.60 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.14 real38.90 user30.02 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.79 real40.59 user27.99 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.93 real39.76 user28.96 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.71 real41.21 user27.29 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.05 real39.68 user29.15 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.99 real39.98 user28.80 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.02 real39.64 user29.16 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.38 real37.49 user31.67 sys testf is a numerically intensive program that tests the accuracy of expf() in a tight loop. User time varies by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. I'm fairly certain that the code does not suddenly grow/loose 6 GFLOP of operations. The user/sys thing is a hack (and has been). We sample the PC at stathz (~128 hz) to figure out a user vs sys split and use that to divide up the total runtime (which actually is fairly accurate). All you need is for the clock ticks to fire just a bit differently between runs to get a swing in user vs system time. What I would like is to keep separate raw bintime's for user vs system time in the raw data instead, but that would involve checking the CPU ticker more often (e.g. twice for each syscall, interrupt, and trap in addition to the current once per context switch). So far folks seem to be more worried about the extra overhead rather than the loss of accuracy. Adding any instruction into global syscall path should be cautioned, it is worse then before, thinking about a threaded application, a userland thread may have locked a mutex and calls a system call, the overhead added to system call path can directly affect a threaded application's performance now, because the time window the mutex is held is longer than before, I have seen some people likes to fiddle with system call path, it should be cautioned. OTOH, the current getrusage(2) stats cannot be trusted. The only meaningful thing you can do is to sum them since the total is known to be accurate at least. If it wouldn't make things so messy I'd consider a new kernel option 'ACCURATE_RUSAGE' or some such. Our getrusage is already very slow, everytime, it needs to iterate the threads list with a process SLOCK held. I saw some mysql versions heavily use getrusage, and a horribly slow. I think a ACCURATE_RUSAGE will make it worse ? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
John Baldwin wrote: On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: Sometime in the last 7-10 days, some one made a change that has broken process accounting/timing. laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) foreach? time ./testf foreach? end Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.55 real38.39 user30.94 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.82 real40.95 user27.60 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.14 real38.90 user30.02 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.79 real40.59 user27.99 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.93 real39.76 user28.96 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.71 real41.21 user27.29 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.05 real39.68 user29.15 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.99 real39.98 user28.80 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.02 real39.64 user29.16 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.38 real37.49 user31.67 sys testf is a numerically intensive program that tests the accuracy of expf() in a tight loop. User time varies by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. I'm fairly certain that the code does not suddenly grow/loose 6 GFLOP of operations. The user/sys thing is a hack (and has been). We sample the PC at stathz (~128 hz) to figure out a user vs sys split and use that to divide up the total runtime (which actually is fairly accurate). All you need is for the clock ticks to fire just a bit differently between runs to get a swing in user vs system time. What I would like is to keep separate raw bintime's for user vs system time in the raw data instead, but that would involve checking the CPU ticker more often (e.g. twice for each syscall, interrupt, and trap in addition to the current once per context switch). So far folks seem to be more worried about the extra overhead rather than the loss of accuracy. Adding any instruction into global syscall path should be cautioned, it is worse then before, thinking about a threaded application, a userland thread may have locked a mutex and calls a system call, the overhead added to system call path can directly affect a threaded application's performance now, because the time window the mutex is held is longer than before, I have seen some people likes to fiddle with system call path, it should be cautioned. Regards, David Xu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: non-invariant tsc and cputicker
Jung-uk Kim wrote: On Friday 03 December 2010 01:14 pm, Andriy Gapon wrote: on 03/12/2010 20:05 Jung-uk Kim said the following: On Friday 03 December 2010 12:26 pm, Andriy Gapon wrote: FreeBSD uses cpu_ticks [function pointer] in a few places for a few things like process CPU time accounting. On x86 cpu_ticks always points to rdtsc. If TSC is not invariant that leads to incorrect accounting of CPU ticks. The code pretends to try to handle changing cpufreq levels, but does that incorrectly. Arg... Probably it is my fault. :-( I think that we could use a selected timecounter instead of raw TSC if the latter is not invariant. In this case cpu_ticks calls would be slightly costlier, but always correct. The change is quite trivial: http://people.freebsd.org/~avg/tsc-cputicker.diff What do you think? Why don't we just fix it properly? Patch? :-) Attached. It seems that it is not too trivial to do and is prone to error accumulation given how the ticks are added up. Besides, why using a timecounter would not be a proper fix? Well, it is not that simple, unfortunately. Because init_TSC() is called very early, your patch will select dummy timecounter as a CPU ticker if my memory serves. It is very hard to implement right on x86 arch. :-( So many years, they can not make a simple counter work correctly, I have seen so many failed technologies in the tech world, and will still happen frequently. :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CFT: patch for process shared pthread objects
Alberto Villa wrote: On Tuesday 30 November 2010 06:48:11 David Xu wrote: I finally have worked out first patch to make our pthread library support process shared pthread objects: yay! http://people.freebsd.org/~davidxu/pshared/patch1.diff wouldn't it require activation of #define _POSIX_THREAD_PROCESS_SHARED in include/unistd.h? Yes. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CFT: patch for process shared pthread objects
David Xu wrote: Hi, I finally have worked out first patch to make our pthread library support process shared pthread objects: http://people.freebsd.org/~davidxu/pshared/patch1.diff Patch is updated: http://people.freebsd.org/~davidxu/pshared/patch2.diff Changes: 1) Macro _POSIX_THREAD_PROCESS_SHARED in unistd.h is changed, now its value is 200112L. 2) Version of libgcc is bumped. 3) Thread cancellation is fixed in pthread_cond_wait(), this should make csup run again. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
CFT: patch for process shared pthread objects
Hi, I finally have worked out first patch to make our pthread library support process shared pthread objects: http://people.freebsd.org/~davidxu/pshared/patch1.diff Many changes are related to redesigned pthread condition variable, these changes try to eliminate extra context switch when pthread_cond_signal is called which could reduce performance. There are two parts in the condition variable implementation. A pure usermode condition variable and kernel-based condition variable. All priority protected, inherited mutexs and process shared mutex will use kernel base condition variable, for a normal mutex, the usermode condition variable is used. Both user-mode and kernel-based try to migrate a thread from condition variable wait queue to mutex wait queue. Another added feature is robust mutex support, http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_setrobust.html Which I think is mostly used for process-shared mutex. In the patch, if mutex attribute is robust, the thread library also uses kernel base condition variable which does not have internal lock in userland. Regards, David Xu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CFT: patch for process shared pthread objects
Garrett Cooper wrote: Doesn't build :/...: === lib/libthr (obj,depend,all,install) make: don't know how to make thr_sleepq.c. Stop *** Error code 2 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Thanks, -Garrett Sorry, I have updated it, please download it again, or just download file: http://people.freebsd.org/~davidxu/pshared/thr_sleepq.c and put it in directory src/lib/libthr/thread/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sysctl -a is slow
Jaakko Heinonen wrote:
On 2010-09-20, David Xu wrote:
I redirect all output to a disk file, and it still needs 1 second to
complete, this machine is dual-core pentium E5500, faster than previous
one which is a dual-core AMD 5000+ machine, the 5000+ needs 2
seconds to complete.
$/usr/bin/time sysctl -b kern.geom.confdot sysctl_geom_confdot.txt
1.00 real 0.00 user 0.00 sys
I couldn't reproduce the problem myself but I bet that it's a lost
wakeup in g_waitfor_event(). Can you try this patch?
%%%
Index: sys/geom/geom_event.c
===
--- sys/geom/geom_event.c (revision 214048)
+++ sys/geom/geom_event.c (working copy)
@@ -220,11 +220,12 @@ one_event(void)
mtx_lock(g_eventlock);
TAILQ_REMOVE(g_events, ep, events);
ep-flag = ~EV_INPROGRESS;
- mtx_unlock(g_eventlock);
if (ep-flag EV_WAKEUP) {
ep-flag |= EV_DONE;
wakeup(ep);
+ mtx_unlock(g_eventlock);
} else {
+ mtx_unlock(g_eventlock);
g_free(ep);
}
g_topology_unlock();
@@ -365,11 +366,14 @@ g_waitfor_event(g_event_t *func, void *a
va_end(ap);
if (error)
return (error);
- do
- tsleep(ep, PRIBIO, g_waitfor_event, hz);
- while (!(ep-flag EV_DONE));
+
+ mtx_lock(g_eventlock);
+ while (!(ep-flag EV_DONE))
+ msleep(ep, g_eventlock, PRIBIO, g_waitfor_event, hz);
if (ep-flag EV_CANCELED)
error = EAGAIN;
+ mtx_unlock(g_eventlock);
+
g_free(ep);
return (error);
}
%%%
Yes, the patch seems fixed the problem, I can not reproduce it.
Thanks!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic on kthread_exit under INVARIANTS
Paul B Mahol wrote: Hi, If kernel threads were created via kproc_kthread_add() when last kernel thread exits it will trigger panic. It panics in queue.h probably introduced with rec I have committed a patch, can you try it ? http://svn.freebsd.org/changeset/base/213714 Regards, David Xu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sysctl -a is slow
jhell wrote: On 09/19/2010 09:28, David Xu wrote: just typed sysctl -a on keyboard, and found it is slow, sometimes it has been stuck for a few seconds, further studied,I found it is stucked at sysctl kern.geom: %/usr/bin/time sysctl -a kern.geom kern.geom.collectstats: 1 kern.geom.debugflags: 0 kern.geom.label.debug: 0 kern.geom.label.ext2fs.enable: 1 kern.geom.label.iso9660.enable: 1 kern.geom.label.msdosfs.enable: 1 kern.geom.label.ntfs.enable: 1 kern.geom.label.reiserfs.enable: 1 kern.geom.label.ufs.enable: 1 kern.geom.label.ufsid.enable: 1 kern.geom.label.gptid.enable: 1 kern.geom.label.gpt.enable: 1 2.01 real 0.00 user 0.00 sys it seems it needs more than 2 seconds to complete. A ktrace(1) and a kdump(1) of the resulting ktrace.out file would probably help here along with uname -a. Ive seen this happen once before but do not recall what caused it. Regards good luck, Result is dumped here. http://people.freebsd.org/~davidxu/sysctl_slow.txt I think the culprit is sysctl kern.geom.confdot, which does not appear in normal output, until I check the kdump result. I tried five times, and it was blocked three times. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sysctl -a is slow
jhell wrote: On Mon, 20 Sep 2010 10:26, David Xu wrote: In Message-Id: 4c976f14.8000...@freebsd.org jhell wrote: On 09/19/2010 09:28, David Xu wrote: just typed sysctl -a on keyboard, and found it is slow, sometimes it has been stuck for a few seconds, further studied,I found it is stucked at sysctl kern.geom: %/usr/bin/time sysctl -a kern.geom kern.geom.collectstats: 1 kern.geom.debugflags: 0 kern.geom.label.debug: 0 kern.geom.label.ext2fs.enable: 1 kern.geom.label.iso9660.enable: 1 kern.geom.label.msdosfs.enable: 1 kern.geom.label.ntfs.enable: 1 kern.geom.label.reiserfs.enable: 1 kern.geom.label.ufs.enable: 1 kern.geom.label.ufsid.enable: 1 kern.geom.label.gptid.enable: 1 kern.geom.label.gpt.enable: 1 2.01 real 0.00 user 0.00 sys it seems it needs more than 2 seconds to complete. A ktrace(1) and a kdump(1) of the resulting ktrace.out file would probably help here along with uname -a. Ive seen this happen once before but do not recall what caused it. Regards good luck, Result is dumped here. http://people.freebsd.org/~davidxu/sysctl_slow.txt I think the culprit is sysctl kern.geom.confdot, which does not appear in normal output, until I check the kdump result. I tried five times, and it was blocked three times. Inspecting the output of sysctl -b kern.geom.confdot will give you what you currently have configured in the system as disks and what not through geom. If this seems to be bailing at that point, which is an opaque MIB/OID which doesn't come up other than when you use the -o switch to sysctl(1) then could you check your labels for your disks for any weird characters in the labels ? ( sysctl -bo kern.geom ) Also does this have the same effect when run in a xterm, cons25 terminal ? And same for the above but with the C, *_COUNTRY.UTF-8 or your normal locale ? ( env LANG=C sysctl kern.geom ) Looking at the output from mine there are quite a few unprintable characters present. Maybe these are having an impact with one of your labels. I redirect all output to a disk file, and it still needs 1 second to complete, this machine is dual-core pentium E5500, faster than previous one which is a dual-core AMD 5000+ machine, the 5000+ needs 2 seconds to complete. $/usr/bin/time sysctl -b kern.geom.confdot sysctl_geom_confdot.txt 1.00 real 0.00 user 0.00 sys the file is here: http://people.freebsd.org/~davidxu/sysctl_geom_confdot.txt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sysctl -a is slow
Lawrence Stewart wrote: On 09/21/10 02:21, David Xu wrote: jhell wrote: On Mon, 20 Sep 2010 10:26, David Xu wrote: In Message-Id: 4c976f14.8000...@freebsd.org jhell wrote: On 09/19/2010 09:28, David Xu wrote: just typed sysctl -a on keyboard, and found it is slow, sometimes it has been stuck for a few seconds, further studied,I found it is stucked at sysctl kern.geom: %/usr/bin/time sysctl -a kern.geom kern.geom.collectstats: 1 kern.geom.debugflags: 0 kern.geom.label.debug: 0 kern.geom.label.ext2fs.enable: 1 kern.geom.label.iso9660.enable: 1 kern.geom.label.msdosfs.enable: 1 kern.geom.label.ntfs.enable: 1 kern.geom.label.reiserfs.enable: 1 kern.geom.label.ufs.enable: 1 kern.geom.label.ufsid.enable: 1 kern.geom.label.gptid.enable: 1 kern.geom.label.gpt.enable: 1 2.01 real 0.00 user 0.00 sys it seems it needs more than 2 seconds to complete. A ktrace(1) and a kdump(1) of the resulting ktrace.out file would probably help here along with uname -a. Ive seen this happen once before but do not recall what caused it. Regards good luck, Result is dumped here. http://people.freebsd.org/~davidxu/sysctl_slow.txt I think the culprit is sysctl kern.geom.confdot, which does not appear in normal output, until I check the kdump result. I tried five times, and it was blocked three times. Inspecting the output of sysctl -b kern.geom.confdot will give you what you currently have configured in the system as disks and what not through geom. If this seems to be bailing at that point, which is an opaque MIB/OID which doesn't come up other than when you use the -o switch to sysctl(1) then could you check your labels for your disks for any weird characters in the labels ? ( sysctl -bo kern.geom ) Also does this have the same effect when run in a xterm, cons25 terminal ? And same for the above but with the C, *_COUNTRY.UTF-8 or your normal locale ? ( env LANG=C sysctl kern.geom ) Looking at the output from mine there are quite a few unprintable characters present. Maybe these are having an impact with one of your labels. I redirect all output to a disk file, and it still needs 1 second to complete, this machine is dual-core pentium E5500, faster than previous one which is a dual-core AMD 5000+ machine, the 5000+ needs 2 seconds to complete. $/usr/bin/time sysctl -b kern.geom.confdot sysctl_geom_confdot.txt 1.00 real 0.00 user 0.00 sys the file is here: http://people.freebsd.org/~davidxu/sysctl_geom_confdot.txt As an extra data point, running /usr/bin/time sysctl -b kern.geom.confdot repeatedly on my amd64 8.1-STABLE desktop varies between 0s and 2s. It reports 0 majority of the time but every 5 or so runs it'll stall for 1 or 2 seconds. So the problem isn't isolated to head. Cheers, Lawrence I happened to set kern.sched.preempt_thresh=200, so the kernel is more aggressive than default on thread preemption. it is easier than default to reproduce the problem, my desktop machine is idle, but it still stalls 1 or 2 seconds on the sysctl. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
sysctl -a is slow
just typed sysctl -a on keyboard, and found it is slow, sometimes it has been stuck for a few seconds, further studied,I found it is stucked at sysctl kern.geom: %/usr/bin/time sysctl -a kern.geom kern.geom.collectstats: 1 kern.geom.debugflags: 0 kern.geom.label.debug: 0 kern.geom.label.ext2fs.enable: 1 kern.geom.label.iso9660.enable: 1 kern.geom.label.msdosfs.enable: 1 kern.geom.label.ntfs.enable: 1 kern.geom.label.reiserfs.enable: 1 kern.geom.label.ufs.enable: 1 kern.geom.label.ufsid.enable: 1 kern.geom.label.gptid.enable: 1 kern.geom.label.gpt.enable: 1 2.01 real 0.00 user 0.00 sys it seems it needs more than 2 seconds to complete. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official request: Please make GNU grep the default
Gabor Kovesdan wrote:
Yes, I'm sorry for my slow reaction, I got a flu some time ago and that
prevented me from fixing the bugs earlier. I have several fixes in my
working copy, which are being discussed with my mentor. Probably, today
or tomorrow they will be committed.
Gabor
When will the grep -H print file name for me ? it is rather painful
that the feature is missing. :-(
So I can not use it with find:
find . -exec grep -H {} world \;
I don't know which file contains the word world.
Regards,
David Xu
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official request: Please make GNU grep the default
But I think BSD grep should be compatible with GNU grep,
because almost all scripts are written for GNU grep before
BSD grep appears, it is not practical to rewrite all existing
scripts. Anyway, thanks for your help.
David Xu
Stein Morten Sandbech wrote:
Hi,
GNU grep is OK. However standard BSD grep also work:
find . -exec grep -i world {} /dev/null \;
or even:
find . -exec grep -in world {} /dev/null \;
if you want linenumbers ...
hth
Stein Morten
On Aug 19, 2010, at 11:29, freebsd-current-requ...@freebsd.org wrote:
Date: Thu, 19 Aug 2010 16:42:26 +
From: David Xu davi...@freebsd.org
Subject: Re: Official request: Please make GNU grep the default
To: Gabor Kovesdan ga...@freebsd.org
Cc: delp...@freebsd.org, Andrey Chernov a...@nagual.pp.ru, Doug
Barton do...@freebsd.org, c...@freebsd.org, curr...@freebsd.org
Message-ID: 4c6d5ef2.2040...@freebsd.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Gabor Kovesdan wrote:
Yes, I'm sorry for my slow reaction, I got a flu some time ago and that
prevented me from fixing the bugs earlier. I have several fixes in my
working copy, which are being discussed with my mentor. Probably, today
or tomorrow they will be committed.
Gabor
When will the grep -H print file name for me ? it is rather painful
that the feature is missing. :-(
So I can not use it with find:
find . -exec grep -H {} world \;
I don't know which file contains the word world.
Regards,
David Xu
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: firefox is stuck in getbuf()
Kostik Belousov wrote: Can you, please, do the following: show the backtraces for the system processes, in particular, syncer, bufdaemon, softdepflush daemon, pagedaemon and vm ? for the stuck firefox thread, find the address of the buffer supplied as an argument to getdirtybuf, and print the *(struct buf *)addr ? This can be done on the live/stuck system using kgdb on /dev/mem. Unfortunately, I can not always reproduce it. :-( ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
firefox is stuck in getbuf()
With newest -HEAD code, firefox is stuck in getbuf(). top last pid: 1814; load averages: 0.00, 0.05, 0.07 up 0+00:37:11 10:54:01 135 processes: 1 running, 134 sleeping CPU: 3.7% user, 0.0% nice, 0.6% system, 0.0% interrupt, 95.7% idle Mem: 259M Active, 393M Inact, 151M Wired, 1484K Cache, 111M Buf, 186M Free Swap: 2020M Total, 2020M Free PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 1427 davidxu 1 450 114M 101M select 0 1:24 0.29% Xorg 1588 davidxu 10 440 279M 145M getbuf 0 2:15 0.00% firefox-bin procstat -k 1588 PIDTID COMM TDNAME KSTACK 1588 100200 firefox-bin initial thread mi_switch sleepq_switch sleepq_wait _sleep getdirtybuf flush_deplist softdep_sync_metadata ffs_syncvnode ffs_fsync VOP_FSYNC_APV fsync syscallenter syscall Xint0x80_syscall 1588 100207 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait poll syscallenter syscall Xint0x80_syscall 1588 100208 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100209 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_timedwait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100210 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_timedwait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100216 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100220 firefox-bin -mi_switch sleepq_switch sleepq_wait _sleep getdirtybuf flush_deplist softdep_sync_metadata ffs_syncvnode ffs_fsync VOP_FSYNC_APV fsync syscallenter syscall Xint0x80_syscall 1588 100238 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100239 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100240 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: licq KSE
Daniel Eischen wrote: It is not libkse that is causing the messages. It is some library or driver that licq is using. The kernel spews these messages whenever something uses static LDT allocation. We know that nvidia drivers and/or their OpenGL library do this, and they have been notified of it (by me). If there is another library or application that is also using static LDT allocation, please help us find it so it can be fixed also. Some multimedia player using Win32 codecs will encounter same problem if these Win32 codec are activated during media playing. They use WINE's some core components, one of is libw32dll, which uses static LDT allocation too. David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: licq KSE
Daniel Eischen wrote: Do you know what port this belongs to and if it is built from source? mplayer also used static ldt allocations, but I fixed that port. Hmm, I found multimedia/libxine that might be the culprit. I'll look into submitting a patch for that. Search word win32 in page http://www.freebsd.org/ports/multimedia.html if you hit anyone, it is very doubtful. David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.1-p10 reproducible crash with Apache2
Branko F. Grac(nar wrote: Thanks. I already sent pr at 29.10.2003, which is identified by id 'kern/58677'. PR can be viewed at the following url address: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/58677 I think, that this really serious issue, concerning operating system stability. best regards, Brane Please tell us your Apache configuration, are you using prefork or worker or perchild mode ? If you are using worker mode, which thread library are you using ? this would help us to narrow down problem scope. --- David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SYSENTER in FreeBSD
Jun Su wrote: I noticed that Jeff Roberson implement this already. Is whi will be commit? http://kerneltrap.org/node/view/1531 I google this because I found this feature is listed in the list of Kernel Improvement of WindowsXP. :-) Thanks, Jun Su I have almost done this experiment about 10 months ago. http://people.freebsd.org/~davidxu/fastsyscall/ The patch is out of date and still not complete. Also it can give you some performance improve, but I think too many things need to be changed, and this really makes user ret code very dirty, some syscalls, for example, pipe() can not use this fast syscall, becaues pipe() seems using two registers to return file handle, the performance gain is immediately lost when the assemble code becomes more complex. I don't think this hack is worth to do on IA32, I heard AMD has different way to support fast syscall, that may already in FreeBSD AMD 64 branch. David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libkse process stats breakage (Re: cvs commit: src/sys/amd64/ amd64 exception.S trap.c src/sys/amd64/include frame.h signal.h ucontext. h)
Kris Kennaway wrote: On Tue, Oct 14, 2003 at 08:17:27PM -0700, Kris Kennaway wrote: On Wed, Oct 15, 2003 at 11:10:43AM +0800, David Xu wrote: The change you made to ucontext.h breaks libkse. :-( Speaking of libkse breakage: 10427 root 200 10500K 8380K kserel 6:44 0.00% 0.00% python2.3 10424 root 200 9292K 7280K kserel 4:43 0.00% 0.00% python2.3 3523 kris 200 50924K 40996K kserel 2:32 0.00% 0.00% MozillaFirebird-bin Those are threaded processes using libkse via libmap.conf, which are using CPU but do not have any CPU% listed. Scheduler is 4BSD, kernel was built yesterday. Any progress on fixing this? Following patch should give you a number to display. Since a kse can move from a thread to another, you will see all threads using same kse have same pctcpu number. Index: sched_4bsd.c === RCS file: /home/ncvs/src/sys/kern/sched_4bsd.c,v retrieving revision 1.25 diff -u -r1.25 sched_4bsd.c --- sched_4bsd.c16 Oct 2003 21:13:14 -1.25 +++ sched_4bsd.c19 Oct 2003 02:10:53 - @@ -726,6 +726,8 @@ struct kse *ke; ke = td-td_kse; +if (ke == NULL) +ke = td-td_last_kse; if (ke) return (ke-ke_pctcpu); Kris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: KSE MySQL rc.d
Alexander Motin wrote: Hi. This patch did not fix the problem. On the 4th boot system hang with same symptoms. Daniel Eischen wrote: I have P4 system with SMP kernel and HyperThreading enabled. I have one strange problem with mysql 4.1.0 when using KSE on 5.1-CURRENT. I have been running MySQL 4.1.0 on my SMP machine for monthes, it is not P4 HyperThreading, but a dual P3 machine, it just works fine for me. After building mysql server with libkse as thread library and adding its start script into /usr/local/etc/rc.d, system hangs on boot without any error message when mysql trying to start. Did kernel lock up or can you press ctrl+c to see if you can interrupt it ? If I trying to start mysql by hands after system completely boot then everything works just fine. If I add delay into mysql start script and run it in backgroud from rc.d - everything is fine If you build mysql from ports, it should install script mysql-server.sh under /usr/local/etc/rc.d, the default script will run mysqld_safe in background, I am confused that you need to manually turn it into background, the work should be done atomically by the script. If I build mysql without KSE it works fine. I'm not sure, but try this patch; it duplicates what libc_r does. Index: thread/thr_init.c === RCS file: /opt/FreeBSD/cvs/src/lib/libpthread/thread/thr_init.c,v retrieving revision 1.60 diff -u -r1.60 thr_init.c --- thread/thr_init.c18 Aug 2003 03:58:29 -1.60 +++ thread/thr_init.c7 Oct 2003 13:30:54 - @@ -251,6 +251,10 @@ PANIC(Can't set login to root); if (__sys_ioctl(fd, TIOCSCTTY, (char *) NULL) == -1) PANIC(Can't set controlling terminal); +if (__sys_dup2(fd, 0) == -1 || +__sys_dup2(fd, 1) == -1 || +__sys_dup2(fd, 2) == -1) +PANIC(Can't dup2); } /* Initialize pthread private data. */ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
David Schwartz wrote: David Xu wrote: I definitly agree with Dan, -pthread is too ugly, it really really is nothing to do with compiler and should be removed. Really? What if invoking the threading library required the compiler to compile code differently? Surely it might require that on some platforms, say certain optimizations weren't thread safe. You're looking at this from the FreeBSD perspective rather than the GCC perspective. If you worry about that GCC should generate thread safe code, then they should have another switch not -pthread, think about we want GCC to generate thread safe code for our kernel, then what switch is needed ? if you think -pthread forces GCC to generate thread safe code, then for our kernel, we need -freebsd-kernel switch ? If someone thinks -pthread should be kept, then think about Microsoft, you are doing Microsoft way and cause lots of trouble when I am programmming on Windows, Microsoft has two version of c library, threaded library and non-threaded library, it need a compiler flag -MT to link a thread library, then lots of library conflict with this flag at linking time because some were compiled with -MT some were not, this is rather annoying. This is a bit OT, but I hope we can avoid such decision bug. You can't avoid this. Suppose that some optimizations have to be disabled to make code thread safe and say these optimizations are significant. Then what would you do? Compile all code with the optimizations disabled and lose performance for all the apps that aren't threaded? You can't change the fact that threaded code and non-threaded code are incompatible on some platforms. Many software use autoconf, autconf prefers -lpthread than -pthread, it even prefers -lc_r then -pthread (if I remembered it right ). And then autconf breaks when what you need to do to make pthreads works changes. What happens if the next threading library requires compiler flags? Or generates incompatible object code? Break what ? I don't think we are forcing GCC to add another switch for our special threading library. All we want to do is resolving conflict between several thread libraries. We now have libc_r, libkse 1:1, libkse M:N, libthr, what library should be default for -pthread switch ? if system has a libpthread there, it will generate Makefile to use -lpthread not -pthread, obviously -pthread is not suggested to use. Not suggested by whom? The whole point of '-pthread' was to have a way to say, I want to use this standard. If '-pthread' is wrong, so is '-ansi'. So is '-std=whatever'. pthread is not a language, -ansi is a language switch. One word, just let -pthread die. Only if you thing standards are a bad thing. I'm sorry, I told myself I'd stay out of this now. I really appreciate the concern being shown and the direction that things are going. However, I think '-pthread' is a good thing. It's nice to have a portable way to say that I want to compile POSIX code. What good is a standard if there's no standard way to get to it? If you are really programming according POSIX standard, then you should use _POSIX_SOURCE_XXX etc macros in your source code, not a magic compiler switch, it is not portable. Regards, David Xu DS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Wednesday 24 September 2003 23:11, Daniel Eischen wrote: On Wed, 24 Sep 2003, John Baldwin wrote: On 23-Sep-2003 Dan Naumov wrote: On Tue, 2003-09-23 at 23:25, Dan Naumov wrote: On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote: I understand that folks want to wave their hands and say just make -pthread work and do whatever it needs to. I am one of those folks as well. As an end-user, I am not interested in hacking around the source of 3rd-party applications that use -pthread when compiling them from source myself. Not in the slightest. This is BAD BAD BAD for usability. Sincerely, Dan Naumov I also believe that a question has to be asked, what do the -core and -arch people think of all this ? I think that they should have the final say in the matter. I think having a magic option to gcc that translates to 'link with the foo library' is rediculous. What's next, a gcc -math to get the math functions in libm? The fact that functions live in libraries and that to get access to said functions you link with said libraries has been the practice on Un*x for longer than I've been alive. Please, people, let the -pthread hack die and just use -lmumble thread library. I think any FreeBSD-specific -pthread bits should just be removed and have the compiler complain about a bogus option. If gcc chooses to have a machine independent -pthread (or -thread) to turn on TLS or some such, that's great and all, but that would be gcc code, not FreeBSD-specific code. Where were you a few days ago! I definitly agree with Dan, -pthread is too ugly, it really really is nothing to do with compiler and should be removed. If someone thinks -pthread should be kept, then think about Microsoft, you are doing Microsoft way and cause lots of trouble when I am programmming on Windows, Microsoft has two version of c library, threaded library and non-threaded library, it need a compiler flag -MT to link a thread library, then lots of library conflict with this flag at linking time because some were compiled with -MT some were not, this is rather annoying. This is a bit OT, but I hope we can avoid such decision bug. Many software use autoconf, autconf prefers -lpthread than -pthread, it even prefers -lc_r then -pthread (if I remembered it right ). if system has a libpthread there, it will generate Makefile to use -lpthread not -pthread, obviously -pthread is not suggested to use. One word, just let -pthread die. David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Various problems after latest -CURRENT build. (USB, WI, KSE)
Daniel Eischen wrote: On Fri, 5 Sep 2003, Mark Sergeant wrote: Hi Guys, I've noticed a bunch of problems with my latest current build... 1. With device wi in my kernel I was unable to compile at all, had to take it out and then use a module to get it to work. 2. My USB mouse no longer works, Works fine on my 5.1-RELEASE machine but nothing as of last nights kernel and world. 3. libkse seems to be causing hangs in various processes including evolution, once I changed libmap to libc_r everything has run smoothly. You can try this patch to src/lib/libpthread/support/Makefile.inc. That should get libkse working again. We don't know why this is needed yet, but someone (kan?) is working on it. Last time, I tested the patch, MySQL was still crashed. Try revert to: src/lib/libpthread/Makefile revision 1.47 src/lib/libpthread/support/Makefile.inc revision 1.5 David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent sound change still broken?
David Xu wrote: | | I tried to backout ac97.c revision 1.43, now my sound card works again, | If someone wants more information, please tell me. David Could you revert to head and check that the mixer ogain is non-zero (say 100 :-)? On some codecs ogain provides the traditional functionality of vol. I appreciate this is not ideal. Thanks - Orion I found that reading AC97_MIX_AUXOUT register in ac97_fix_auxout() has side effect on my sound card, although it has 0x8000 bit set, it might be a driver bug or hw bug. The following patch avoids the problem, but is a bit ugly. :-( David Xu Index: ac97.c === RCS file: /home/ncvs/src/sys/dev/sound/pcm/ac97.c,v retrieving revision 1.46 diff -u -r1.46 ac97.c --- ac97.c 29 Aug 2003 03:24:08 - 1.46 +++ ac97.c 29 Aug 2003 14:28:03 - @@ -454,7 +454,12 @@ * We first check whether aux_out is a valid register. If not * we may not want to keep ogain. */ - keep_ogain = ac97_rdcd(codec, AC97_MIX_AUXOUT) 0x8000; + + /* Creative EV1938 codec read has side effect ? */ + if (codec-id == 0x1408384) + keep_ogain = 1; + else + keep_ogain = ac97_rdcd(codec, AC97_MIX_AUXOUT) 0x8000; /* * Determine what AUX_OUT really means, it can be: ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Recent sound change still broken?
My patch http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/54810 ever worked well for my old Creative sound card, the device is probed, but now no sound at all. :-( dmesg: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Thu Aug 28 06:44:25 CST 2003 [EMAIL PROTECTED]:/home/davidxu/src/sys/i386/compile/mpnw Preloaded elf kernel /boot/kernel/kernel at 0xc04a7000. Preloaded elf module /boot/kernel/snd_es137x.ko at 0xc04a71f4. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04a72a4. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (999.67-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 805240832 (767 MB) avail memory = 776982528 (740 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec0 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00fdda0 pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 IOAPIC #0 intpin 11 - irq 2 IOAPIC #0 intpin 10 - irq 5 agp0: VIA 82C691 (Apollo Pro) host to PCI bridge mem 0xf000-0xf3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686B UDMA100 controller port 0xa000-0xa00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xa400-0xa41f irq 2 at device 7.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ugen0: OmniVision OV511+ Camera, rev 1.00/1.00, addr 2 uhci1: VIA 83C572 USB controller port 0xa800-0xa81f irq 2 at device 7.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at device 7.4 (no driver attached) fxp0: Intel 82557 Pro/100 Ethernet port 0xb800-0xb81f mem 0xf700-0xf70f,0xf710-0xf7100fff irq 2 at device 11.0 on pci0 fxp0: Ethernet address 00:a0:c9:5a:41:98 miibus0: MII bus on fxp0 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: Creative SB AudioPCI CT4730 port 0xc000-0xc01f,0xbc00-0xbc3f irq 5 at device 12.0 on pci0 pcm0: Creative EV1938 AC97 Codec orm0: Option ROM at iomem 0xc-0xc8fff on isa0 pmtimer0 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: Parallel port bus on ppc0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources (port) unknown: PNP0f13 can't assign resources (irq) unknown: PNP0700 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0400 can't assign resources (port) APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Timecounters tick every 10.000 msec ad0: 57241MB ST360021A [116301/16/63] at ata0-master UDMA100 ata1-slave: FAILURE - ATA_IDENTIFY status=51READY,DSC,ERROR error=4ABORTED acd0: CDROM ATAPI-CD ROM-DRIVE-52MAX at ata1-master PIO4 SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/ad0s3a drm0: ATI Radeon QM R200 9100 port 0x9000-0x90ff mem 0xf500-0xf500,0xe800-0xefff irq 2 at device 0.0 on pci1 info: [drm] AGP at 0xf000 64MB info: [drm] Initialized radeon 1.9.0 20020828 on minor 0 info: [drm] Loading R200 Microcode -- David Xu ___ [EMAIL
Re: Recent sound change still broken?
I use es137x module: [EMAIL PROTECTED]:/home/davidxu kldstat Id Refs AddressSize Name 15 0xc010 37fc28 kernel 21 0xc048 6964 snd_es137x.ko 32 0xc0487000 1e554snd_pcm.ko 41 0xc5f0e000 16000radeon.ko David Xu On Thursday 28 August 2003 07:37, David Xu wrote: My patch http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/54810 ever worked well for my old Creative sound card, the device is probed, but now no sound at all. :-( dmesg: ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recent sound change still broken?
On Thursday 28 August 2003 07:37, David Xu wrote: My patch http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/54810 ever worked well for my old Creative sound card, the device is probed, but now no sound at all. :-( I tried to backout ac97.c revision 1.43, now my sound card works again, If someone wants more information, please tell me. David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
On Wednesday 20 August 2003 02:49, John Baldwin wrote: Here's how it works: The BIOS/hardware monitor the power button. When an OS tells the BIOS that it is ACPI, then the BIOS doesn't do an instant turn off when the power button is pressed, but waits to do so until the power button has been held down for 4 seconds. If the power button after 4 seconds doesn't work, it's still a hardware problem. FreeBSD can not fix your hardware problem. When you press the power button with an ACPI OS running, the hardware sends an interrupt to the OS. The OS then shuts down and asks the BIOS (via ACPI) to power off the machine. If the machine doesn't physically turn off, it's because your BIOS is screwed up and didn't handle the power down command properly. The fact that the 4 second trick (which as above bypasses FreeBSD completely and has the BIOS call that power down method itself) produces the same broken results means that this bug is in your hardware. FreeBSD sleeps for a bit when it does a halt -p as a workaround for broken IDE disks which claim that writes have hit the media when they are still in the disks cache, so that is a separate issue. If you want more info on ACPI and how it works, feel free to head on over to www.acpi.info and read the spec for yourself. Windows 2000 can shutdown my Tiger 230T in very short time, while FreeBSD is always timeouted with halt -p. I dont't think it is hardware or BIOS problem, FreeBSD must be wrong in something, just like FreeBSD ATA bug for my Tiger 230T, all OS I have in hand work fine, only FreeBSD does not. David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
I have similar problem, FreeBSD ACPI never work for my Tyan Tiger 230T, halt -p does not work after I have run the machine for about 10 minutes, it works if I just power on FreeBSD and then type halt -p immediately, after power off, NUM LOCK LED on keyboard is still light, it seems it is not fully shutdown. David Xu - Original Message - From: Stephen Montgomery-Smith [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 10:13 AM Subject: ACPI on Tyan Motherboard I have a Tyan S2462 Thunder K7 motherboard. I was hoping to get power-down to work. So I installed FreeBSD current with ACPI enabled. When I typed shutdown -p now the computer halted, and then the video card switched off, and the fans kept running. The computer was frozen - even the power-off power-on button wouldn't work. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Saturday 02 August 2003 06:24, Munish Chopra wrote: On 2003-08-02 00:20 +0200, Thorsten Greiner wrote: * Daniel Eischen [EMAIL PROTECTED] [2003-08-02 00:06]: I think the bug was in the old code allowing this to happen... Well, than someone should tell that to NVidia. Their driver is closed source and comes without user servicable parts. Regards -Thorsten That's going to be a lot easier to get through if someone can confirm whether 0-16 are reserved, or whether (like julian says), 6-15 are actually safe and something else is being clobbered. #define LSYS5CALLS_SEL 0 /* forced by intel BCS */ #define LSYS5SIGR_SEL 1 #define L43BSDCALLS_SEL 2 /* notyet */ #define LUCODE_SEL 3 #define LSOL26CALLS_SEL 4 /* Solaris = 2.6 system call gate */ #define LUDATA_SEL 5 /* separate stack, es,fs,gs sels ? */ /* #define LPOSIXCALLS_SEL 5*/ /* notyet */ #define LBSDICALLS_SEL 16 /* BSDI system call gate */ #define NLDT(LBSDICALLS_SEL + 1) LUCODE_SEL is used by kernel to load _ucodesel to user %cs LUDATA_SEL is used by kernel to load _udatasel to user %ds, %es, %fs, %gs. I didn't check other ABIs, but setting to a fixed location of LDT in userland is also a bad idea, I think it will conflict with thread library soon, it is better to use dynamic allocating facility newly added in i386_set_ldt. David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildkernel fails on -CURRENT
Fixed! sorry. - Original Message - From: Greg J. [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 10:55 AM Subject: buildkernel fails on -CURRENT -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here's the error message... cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding vers.c linking kernel kern_sig.o: In function `trapsignal': kern_sig.o(.text+0x2d44): undefined reference to `thread_siginfo' kern_thread.o: In function `thread_signal_add': kern_thread.o(.text+0x2d86): undefined reference to `thread_siginfo' *** Error code 1 Stop in /usr/obj/usr/src/sys/KADAFI. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iQEVAwUBPxNtIsVlXGSZ3LVMAQLxjAf/UbCSxkcy/X9S2h0EMqwcFoOTlth9h5jj sdbdq3GfcRNaoxpepaX8zbVKnhIP1f+FJMcmGvEIpwN2y6Jhg1S+dE4e+MRgjYYe 8cK9VLzR18uQsX9OM4ttwauUNQZNFviZ9tZacRs6qs6L4a0fkc/+MmiW9iXVxeEi awQ9jOPK/8olwhEI+UEAf2bsFDF9fNAKYu5IKNJ8m2zzlO4X//M9ejMoM5labfKi C4rDzw3APYIsaowoHuwEyBLcYS0vmHvpLRUszFmTMocetOO0Y/U9PrzjAE3+6Bsq Nw8Vi7obXY/1obBQQWX8K5cGg/0OAaeuRChixoMZ6XQg61RWmurn6A== =Lrsj -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: new KSE signal code
I begin to commit KSE signal code, libkse will be broken for a while. David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: new KSE signal code
Finished! - Original Message - From: David Xu [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, June 28, 2003 2:56 PM Subject: HEADS UP: new KSE signal code I begin to commit KSE signal code, libkse will be broken for a while. David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: new KSE signal code
David Leimbach, Thank you for your reply and explain the reason for me, I normally won't reply such complain. At that time, I was very tire and sick, after one week of hardwork and sleep late at night for KSE signal code, I think nothing is important than committing the code and let it be tested widely. Thank you again, David Xu - Original Message - From: David Leimbach [EMAIL PROTECTED] To: David Schultz [EMAIL PROTECTED] Cc: David Xu [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, June 28, 2003 8:42 PM Subject: Re: HEADS UP: new KSE signal code I don't think you understand what I believe he was trying to say. Commits to CVS are NOT atomic therefore getting a copy of FBSD in between David's start and finish of commits would be broken. When he says he is finished.. I bet it will work again. Now if we were all using Perforce this would be different as commits are atomic I think :). Its free to use for open source projects too but the practicality of making everyone learn something new is not necessarily a good idea :). Dave On Saturday, June 28, 2003, at 04:47 AM, David Schultz wrote: On Sat, Jun 28, 2003, David Xu wrote: I begin to commit KSE signal code, libkse will be broken for a while. Umm...if it's known to be broken, then why did you commit it? If you want people to test KSE and report bugs, the version in the tree needs to be of consistently good quality. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
I have another problem different with Bill Paul's. I have a Tyan Tiger 230T dual CPU MB. On second IDE, there are MITSUBISHI 52X CDROM as master and a SONY CD-RW CRX140E 8X/4X/32X as slave. FreeBSD never got them to work, while MS Windows and Linux and NetBSD and OpenBSD all work well with these devices. FreeBSD always stuck at MODE SENSE BIG, this sucks, I must disable second IDE in BIOS before booting into FreeBSD and reenable it before booting into another OS. I changed configuration several times, both DMA and PIO mode don't work, it works only when CR-RW is pulled. David Xu - Original Message - From: Soeren Schmidt [EMAIL PROTECTED] To: Bill Paul [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, June 27, 2003 3:03 AM Subject: Re: Heads up: checking in change to ata-card.c I do have problems with the wording you use in the comments in that patch mentioned below, I will even say that I will remove that as soon as it appears *and* shoot the committer so it doesn't happen again to use your choice of wording.. Now, I dont think this way is productive at all, and would appreciate if we could have a civilized way of doing this instead... This is exactly the crap that makes one wonder if the time used on the project is well spent... -Søren It seems Bill Paul wrote: A long time ago, circa FreeBSD 4.3, my Sony PCMCIA CD-ROM drive with brain-damaged Teac ATA controller drive worked, and the people were content and all was right with the land. Then my 4.4 CD set arrived, and I was disappointed to find the install kernel would lock up after the driver was probed. Complaints were made and epithets were hurled, and lo, in 4.5-RELEASE, all was well once again. Then came 4.6-RELEASE, and it was broken again. Then came 4.6.2, and it was still broken. And in 4.7. And 4.8. And 5.0. (Yeah yeah, shut up.) I just got my 5.1-RELEASE CDs and guess what? My CD-ROM drive STILL doesn't work!!! Guys, there's nothing more frustrating than getting a brand new CD set in the mail and not being able to install via CD. So I'm not leaving it up to chance anymore. I have a patch to make my drive work here: http://www.freebsd.org/~wpaul/ata-card.c.diff-5.1 I have no idea what the altio port remapping goop in ata_pccard_probe() is supposed to accomplish, but I'm telling you all right now, it doesn't work with my drive. I have specifically added to code to skip the remapping for drives with the product string of NinjaATA- (the problem with the Teac controller is that its vendor/product ID is 0x/0x, so there's really no better way to indentify it). This patch changes this: ata2: NinjaATA- at port 0x180-0x187,0x386-0x387 irq 9 function 0 config 33 on pccard0 device_probe_and_attach: ata2 attach returned 6 Into this: ata2: NinjaATA- at port 0x180-0x187,0x386-0x387 irq 9 function 0 config 33 on pccard0 acd0: CDROM CD-224E at ata2-master PIO4 Now, I'm sending out this notification that I _WILL_ check this patch in before I leave the office today. I'm not asking for permission. I've been waiting for half a dozen releases for this to get fixed. When 5.2-RELEASE arrives in my mailbox, it _WILL_ install from CD-ROM on my laptop or so help me I will find the responsible parties and force them to listen to RMS sing Free The Software -- _live_ -- until their ears bleed. I have tested this patch. It compiles. It works. I can mount CDs successfully and transfer stuff from them to my heart's content. I've reduced the change down to the absolute minimum and insured that it won't affect any other drives except mine. It's going in. Period. I am not leaving it up for debate, because if I do, all that will happen is that people will argue over what the more correct fix should be, and at this point I _just_ _don't_ _care_. I want my drive to work, and this does it. Understand? Good. This concludes my announcement. Thank you all for your attention. Don't forget to tip the waitress. -Bill P.S.: Be sure to join us next time when I ream out whoever it was that broke support for my 3Com 3c575C cardbus ethernet NIC. -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = If stupidity were a handicap, you'd have the best parking spot. = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED
Re: [Fwd: Re: libkse now running quite well on smp]
I am still working on it. it is a very alpha patch. :( - Original Message - From: Huang wen hui [EMAIL PROTECTED] To: Huang wen hui [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 23, 2003 8:28 AM Subject: Re: [Fwd: Re: libkse now running quite well on smp] Huang wen hui ??: ??: Re: libkse now running quite well on smp ???: Huang wen hui [EMAIL PROTECTED] ??: Mon, 23 Jun 2003 08:13:54 +0800 ???: Khairil Yusof [EMAIL PROTECTED] Khairil Yusof ??: First of all thanks to Julian Elisher who gave hints on what might be wrong (userland/kernel), even though I was a blockhead for not enabling debugging options in the kernel before posting. It help me track down broken stuff in userland first. I hope I can give proper helpful debug info next time I get problems. Tested everything else throughly, before enabling kse one app at a time. Current uptime of 23hrs with these apps running with libkse.so.1, basically a usable Gnome 2.2 desktop environment: jdk1.4.1 (tomcat/netbeans) openoffice 1.03 evolution 1.4 mozilla-firebird 0.6 metacity xmms gnome-terminal nautilus vte dia gnome-panel gkrellm mysql40 (not heavilly tested yet) Wow.. with recent updates, you can now see the threads with top(8): Mozilla-Firebird 826 kaeru 96 0 40508K 32172K select 1 0:07 0.00% 0.00% MozillaFire 826 kaeru 96 0 40508K 32172K select 1 0:07 0.00% 0.00% MozillaFire 826 kaeru 20 0 40508K 32172K kserel 1 0:07 0.00% 0.00% MozillaFire 826 kaeru 20 0 40508K 32172K kserel 1 0:07 0.00% 0.00% MozillaFire Great work by the KSE team! Looks like we might get libpthreads as default on 5.2. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] just for a notes, with David Xu patch http://people.freebsd.org/~davidxu/kse_sig/, I can JBuilder9 with JDK1.4.1-p3. Before JBuilder9 always coredump with without :( the patch. --hwh ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange 'su' problem
Can you try the patch ? http://people.freebsd.org/~davidxu/su.c.diff David Xu - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, May 31, 2003 1:03 AM Subject: strange 'su' problem Hello, just another, /me too : -current still works like a charm on my Toshiba Notebook, but for two details : - I regot those: psmintr: out of sync (0080 != ). psmintr: re-enable the mouse since today's upgrade but they seem to be harmless (this time ^_^) - I still have: M ~/tmp [16096] su - toor [1]+ Stopped su - toor M ~/tmp [16097] fg su - toor -su-2.05b# M ~/tmp [16081] su - root [1]+ Stopped su - root M ~/tmp [16082] fg su - root M# I use bash as my login-shell. Regards, Arno ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kern/52718
- Original Message - From: Terry Lambert [EMAIL PROTECTED] To: Bryan Liesner [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, May 30, 2003 5:02 PM Subject: Re: panic: kern/52718 Bryan Liesner wrote: Is anyone going to look at this before the next release? Of course, if more info is needed, I'll send it along. No dump is available - it panics during boot. http://www.freebsd.org/cgi/query-pr.cgi?pr=52718 This was caused by rev. 1.3 of a commit by Jeff Robertson to kern_utmx.c. The problem is that the proc struct is not locked for: FOREACH_THREAD_IN_PROC(td-td_proc, td0) in the lock and unlock. Either lock the proc before and unlock it after this, in both _utmx_lock() and _utmx_unlock(), or revert the code to 1.2. It's pretty simple. No one needs t look at it, all they need to do is act on information already present. kern_sig.c has same issue in several places. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kern/52718
- Original Message - From: Terry Lambert [EMAIL PROTECTED] To: David Xu [EMAIL PROTECTED] Cc: Bryan Liesner [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, May 30, 2003 5:27 PM Subject: Re: panic: kern/52718 David Xu wrote: This was caused by rev. 1.3 of a commit by Jeff Robertson to kern_utmx.c. The problem is that the proc struct is not locked for: FOREACH_THREAD_IN_PROC(td-td_proc, td0) in the lock and unlock. Either lock the proc before and unlock it after this, in both _utmx_lock() and _utmx_unlock(), or revert the code to 1.2. kern_sig.c has same issue in several places. Just looked... YUCK! The Process group code and the code in the filt_sigdetach() have got to be what you are talking about, right? Yes. :( I'm constantly surprised at some of the race windows I find in production code (not just FreeBSD), that are just waiting there to chew someone's leg off the first chance they get... 8-(. Welcome to fix it. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
witness needs DDB
subr_witness.c now needs DDB option enabled, otherwise can not be compiled. please fix it. David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA MODE_SENSE_BIG timeout
- Original Message - From: Luoqi Chen [EMAIL PROTECTED] To: David Xu [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 8:44 AM Subject: RE: ATA MODE_SENSE_BIG timeout For those want to fix ATA code, I have another problem with CURRENT. I have a Tyan Tiger 230T which is based on VIA Apollo 133T, south bridge is VIA 686B. On second IDE, I have a Mitsubishi 52X cdrom as master, and a Sony 16X CD R/W as slave, when startup, kernel is always stuck at MODE_SENSE_BIG timeout. I fortunately catched the dmesg text since ATA code past the probing stage. In most case, it will be stuck there forever. BTW, both Linux (2.2.14, Redhat) and MS Windows can probe these devices in few seconds without any problem. I had more than a few machines behaved this way. I believe the problem is with the probe and attach sequence of our ata driver. After an ATA reset, according to spec, an ATAPI device is supposed to present the ATAPI signature and deassert the ready bit, until it receives its first packet command. However when the ata driver issues the first mode sense command, it polls first for the ready bit which never becomes set and the operation times out. The most obviously solution is sending the first command without checking for the ready bit. My solution is a little different, but works equally well, instead I issue an ATAPI reset (what now called a device reset?), because I don't want to write another or alter the current ata_command function and we need an atapi_reset function anyway. According spec, atapi devices SHOULD ONLY be reset via the atapi reset command (our ata driver doesn't follow this rule). The patch is for -stable. I hope it's not too difficult to port to -current. I have applied the patch manually to CURRENT, it helps nothing. :( Then I booted kernel without the patch, waited for a very long time to let ata code retry, finally it found the Sony 16X CD RW, but I can not mount it. It is always timeout. David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA MODE_SENSE_BIG timeout
- Original Message - From: Soeren Schmidt [EMAIL PROTECTED] To: David Xu [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 3:56 PM Subject: Re: ATA MODE_SENSE_BIG timeout It seems David Xu wrote: (snip snap) acd1: read data overrun 34/0 acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd1: CD-RW SONY CD-RW CRX140E at ata1-slave PIO4 Hmm, can you use the acd1 device normally or does it fail (how) ? -Søren It is very rare that the CD-RW will be found now, kernel is always stuck there, so I must pull the device off or disable Second IDE in BIOS, I can not use it. David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ATA MODE_SENSE_BIG timeout
(100% to 50.0%), currently 100.0% ad0: 57241MB ST360021A [116301/16/63] at ata0-master UDMA100 acd0: CDROM ATAPI-CD ROM-DRIVE-52MAX at ata1-master PIO4 acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd1: read data overrun 34/0 acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd1: read data overrun 34/0 acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd1: read data overrun 34/0 acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd1: read data overrun 34/0 acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd1: read data overrun 34/0 acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd1: read data overrun 34/0 acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd1: CD-RW SONY CD-RW CRX140E at ata1-slave PIO4 SMP: AP CPU #1 Launched! MBREXT Slice 5 on ad0s2: [0] f:00 typ:7 s(CHS):5/1/65 e(CHS):255/254/255 s:63 l:20964762 [1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:20964825 l:20964825 MBREXT Slice 6 on ad0s2: [0] f:00 typ:7 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:20964762 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Mounting root from ufs:/dev/ad0s3a -- David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
reproducable kernel crash
:20964825 MBREXT Slice 6 on ad0s2: [0] f:00 typ:7 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:20964762 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Mounting root from ufs:/dev/ad0s3a --- David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
SMP kernel crashed at reboot
Did anyone experience SMP kernel crashed at reboot? On my Tyan Tiger 230T motherboard, when I type reboot, it crashed very often, typically after it printed Waiting (max 60 seconds) for system process `vnlru' to stop David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
vm panic
panic: lockmgr: locking against myself Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 dbtrace Debugger(c0381630,c03e4ee0,c037fd14,da447c28,1) at Debugger+0x54 panic(c037fd14,0,c037fc88,eb,1fb) at panic+0xab lockmgr(c138e85c,2,0,c3c150e0,c3c1514) at lockmgr+0x512 _vm_map_lock_read(c138e280,c039bc27,896,238d3c,527) at _vm_map_lock_read+0x5a vm_map_check_protection(c138e80,826400,826500,2,c03b1980) at vm_map_check_protection+0x31 useracc(8264fc4,8,2,1,c038b1f) at useracc+0x7d nanosleep(c3c150e0,da447d10,c039f3e,407,2) at nonosleep+0x53 syscall(bfbf002f,804002f,826002f,bfbffbe0,804a420) at syscall+0x28e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (240, FreeBSD ELF32, nanosleep), eip = 0x280b0853, esp = 0x8264fb8, ebp = 0x8264fd4 At the time, I am running ksetest, a kse based threaded program. Is the vm still not safe to run threaded program? David Xu ¡Iì¹» ®Þ±éݨ¥¶Ý¢jçH:+éì¹» ®Þ~·nÇ\ººÞا¶¡Ü¨~Ø^ë,j
Re: ACPI warnings: ACPI-1287: *** Error: Method execution failed, AE_AML_BUFFER_LIMIT
This is not surprising, ACPI also fails on my FIC motherboard, I lost floppy drive when I enable ACPI, fdc0 can not allocate resources, sigh. David Xu -- Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #26: Wed Jan 15 11:40:50 CST 2003 [EMAIL PROTECTED]:/usr/home/davidxu/src/sys/i386/compile/xu Preloaded elf kernel /boot/kernel/kernel at 0xc06c5000. Preloaded elf module /boot/kernel/vesa.ko at 0xc06c50a8. Preloaded elf module /boot/kernel/acpi.ko at 0xc06c5154. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 501139221 Hz CPU: Pentium II/Pentium II Xeon/Celeron (501.14-MHz 686-class CPU) Origin = GenuineIntel Id = 0x665 Stepping = 5 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 469696512 (447 MB) avail memory = 448995328 (428 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled VESA: v3.0, 4096k memory, flags:0x1, mode table:0xc0678ca2 (122) VESA: NVidia npx0: math processor on motherboard npx0: INT 16 interface acpi0: FICFB11 on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 Using $PIR table, 7 entries at 0xc00fddc0 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz ACPI-1287: *** Error: Method execution failed, AE_AML_UNINITIALIZED_LOCAL can't fetch resources for \\_SB_.PCI0.FDC0 - AE_AML_UNINITIALIZED_LOCAL acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x5000-0x500f,0x4000-0x4041,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82443BX (440 BX) host to PCI bridge mem 0xd000-0xd3ff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xe000-0xe01f irq 10 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at device 7.3 (no driver attached) rl0: RealTek 8139 10/100BaseTX port 0xe400-0xe4ff mem 0xd900-0xd9ff irq 5 at device 10.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:e0:4c:6b:dc:5e miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: cannot reserve I/O port range (1 ports) sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model 4D+ Mouse, device ID 8 fdc0: cannot reserve I/O port range (1 ports) orm0: Option ROM at iomem 0xc-0xc on isa0 fdc0: cannot reserve I/O port range (6 ports) pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% ad0: 14655MB Maxtor 31536H2 [29777/16/63] at ata0-master UDMA33 ad2: 14655MB Maxtor 31536U2 [29777/16/63] at ata1-master UDMA33 acd0: CDROM SAMSUNG CD-ROM SC-140H at ata1-slave PIO4 MBREXT Slice 5 on ad0s2: 00 01 81 0b 83 fe ff ff 3f 00 00 00 f1 45 89 00 |?E..| [0] f:00 typ:131 s(CHS):11/1/129 e(CHS):255/254/255 s:63 l:8996337 00 fe ff ff 05 fe ff ff 30 46 89 00 be 32 0f 00 |0F...2..| [1] f:00 typ:5 s(CHS):255/254/255 e(CHS):255/254/255 s:8996400 l:996030 MBREXT Slice 6 on ad0s2: 00 fe ff ff 82 fe ff ff 3f 00 00 00 7f 32 0f 00 |?2..| [0] f:00 typ:130 s(CHS):255/254/255 e(CHS):255/254/255 s:63 l:995967 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Mounting root from ufs:/dev/ad0s3a lock order reversal 1st 0xc3a0dce0 process lock (process lock
usb hid device timeout
I have a CD Tower device (a USB HID device) which always failed to be identified
under CURRENT source without following patch, it is always timeout, could anyone
look the following patch:
Index: usb_subr.c
===
RCS file: /home/ncvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.52
diff -u -u -r1.52 usb_subr.c
--- usb_subr.c 17 Jun 2002 20:52:26 - 1.52
+++ usb_subr.c 6 Jan 2003 07:48:51 -
@@ -1106,9 +1106,15 @@
usbd_reload_device_desc(usbd_device_handle dev)
{
usbd_status err;
-
+ int i;
+
/* Get the full device descriptor. */
- err = usbd_get_device_desc(dev, dev-ddesc);
+ for (i = 0; i 3; ++i) {
+ err = usbd_get_device_desc(dev, dev-ddesc);
+ if (!err)
+ break;
+ usbd_delay_ms(dev, 200);
+ }
if (err)
return (err);
--
After patched, I can use usbhidctl to dump some informaton:
Report descriptor:
Collection page=0xffa0 usage=0x0001
Collection page=0xffa0 usage=0x0002
Input size=8 count=1 page=0xffa1 usage=0x0003, logical range -128..127, physical
range 0..-1
Input size=8 count=1 page=0xffa1 usage=0x0004, logical range -128..127, physical
range 0..-1
Input size=8 count=1 page=0xffa1 usage=0x0004, logical range -128..127, physical
range 0..-1
Input size=8 count=1 page=0xffa1 usage=0x0004, logical range -128..127, physical
range 0..-1
Input size=8 count=1 page=0xffa1 usage=0x0004, logical range -128..127, physical
range 0..-1
Input size=8 count=1 page=0xffa1 usage=0x0004, logical range -128..127, physical
range 0..-1
Input size=8 count=1 page=0xffa1 usage=0x0004, logical range -128..127, physical
range 0..-1
Input size=8 count=1 page=0xffa1 usage=0x0004, logical range -128..127, physical
range 0..-1
Output size=8 count=1 page=0xffa1 usage=0x0005, logical range -128..127, physical
range 0..-1
Output size=8 count=1 page=0xffa1 usage=0x0006, logical range -128..127, physical
range 0..-1
Output size=8 count=1 page=0xffa1 usage=0x0006, logical range -128..127, physical
range 0..-1
Output size=8 count=1 page=0xffa1 usage=0x0006, logical range -128..127, physical
range 0..-1
Output size=8 count=1 page=0xffa1 usage=0x0006, logical range -128..127, physical
range 0..-1
Output size=8 count=1 page=0xffa1 usage=0x0006, logical range -128..127, physical
range 0..-1
Output size=8 count=1 page=0xffa1 usage=0x0006, logical range -128..127, physical
range 0..-1
Output size=8 count=1 page=0xffa1 usage=0x0006, logical range -128..127, physical
range 0..-1
End collection
End collection
Total input size 8 bytes
Total output size 8 bytes
Total feature size 0 bytes
N
'²æìr¸zǧvf¢Új:+v¨· è® ¶§²æìr¸yúÞy» rêëz{bØ^nr¡ûazg¬±¨
Re: truss and KSE
What is your revision of kern_thread.c? revision 1.58 should fix this problem. - Original Message - From: Tim Robbins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 14, 2002 9:06 PM Subject: truss and KSE While experimenting with the new libpthread, I found that if you run `truss' on a KSE process, both truss and its victim get into a weird state and don't respond to TERM, INT or QUIT signals. The truss proc dies if you send it the KILL signal, but the victim process cannot be killed. Stranger still, it's in the run state but not actually performing any work. I understand that KSE is still an experimental feature but I thought this was worth pointing out because it could be used as a local DoS and we are nearing 5.0-RELEASE. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
rl driver lock order reversal
rl0: RealTek 8139 10/100BaseTX port 0xe800-0xe8ff mem 0xd900-0xd9ff irq 11 at device 12.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode ../../../vm/uma_core.c:1307: could sleep with rl0 locked from ../../../pci/if_rl.c:872 ../../../vm/uma_core.c:1307: could sleep with rl0 locked from ../../../pci/if_rl.c:872 lock order reversal 1st 0xc0f3b1c0 rl0 (network driver) @ ../../../pci/if_rl.c:872 2nd 0xc038a0e0 allproc (allproc) @ ../../../kern/kern_fork.c:316 ../../../vm/uma_core.c:1307: could sleep with rl0 locked from ../../../pci/if_rl.c:872 ../../../vm/uma_core.c:1307: could sleep with rl0 locked from ../../../pci/if_rl.c:872 ../../../vm/uma_core.c:1307: could sleep with rl0 locked from ../../../pci/if_rl.c:872 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rl driver lock order reversal
today's source code David - Original Message - From: M. Warner Losh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, October 22, 2002 10:20 AM Subject: Re: rl driver lock order reversal How recent is your kernel? I thought I'd fixed this in recent current (at least the could sleep with rl0 part). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rl driver lock order reversal
- Original Message -
From: M. Warner Losh [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, October 22, 2002 10:40 AM
Subject: Re: rl driver lock order reversal
In message: 00bd01c27972$5eea20f0$ef01a8c0@davidwnt
David Xu [EMAIL PROTECTED] writes:
: today's source code
Looks like I've not committed it. :-(. Also looks like p4 told me
there were no diffs for reasons unknown...
This removes the lock around the attach routine. It isn't needed,
since we can't possibly be reentered until after we register an ISR.
Warner
--- /dell/imp/FreeBSD/src/sys/pci/if_rl.c Mon Oct 7 00:15:08 2002
+++ /dell/imp/p4/newcard/src/sys/pci/if_rl.c Fri Oct 18 00:33:53 2002
@@ -869,7 +869,6 @@
mtx_init(sc-rl_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK,
MTX_DEF | MTX_RECURSE);
- RL_LOCK(sc);
/*
* Handle power management nonsense.
@@ -952,18 +951,6 @@
goto fail;
}
- error = bus_setup_intr(dev, sc-rl_irq, INTR_TYPE_NET,
- rl_intr, sc, sc-rl_intrhand);
-
- if (error) {
- bus_release_resource(dev, SYS_RES_IRQ, 0, sc-rl_irq);
- bus_release_resource(dev, RL_RES, RL_RID, sc-rl_res);
- printf(rl%d: couldn't set up irq\n, unit);
- goto fail;
- }
-
- callout_handle_init(sc-rl_stat_ch);
-
/* Reset the adapter. */
rl_reset(sc);
sc-rl_eecmd_read = RL_EECMD_READ_6BIT;
@@ -999,7 +986,6 @@
sc-rl_type = RL_8129;
else {
printf(rl%d: unknown device ID: %x\n, unit, rl_did);
- bus_teardown_intr(dev, sc-rl_irq, sc-rl_intrhand);
bus_release_resource(dev, SYS_RES_IRQ, 0, sc-rl_irq);
bus_release_resource(dev, RL_RES, RL_RID, sc-rl_res);
error = ENXIO;
@@ -1045,7 +1031,6 @@
if (sc-rl_cdata.rl_rx_buf == NULL) {
printf(rl%d: no memory for list buffers!\n, unit);
- bus_teardown_intr(dev, sc-rl_irq, sc-rl_intrhand);
bus_release_resource(dev, SYS_RES_IRQ, 0, sc-rl_irq);
bus_release_resource(dev, RL_RES, RL_RID, sc-rl_res);
bus_dma_tag_destroy(sc-rl_tag);
@@ -1061,7 +1046,6 @@
if (mii_phy_probe(dev, sc-rl_miibus,
rl_ifmedia_upd, rl_ifmedia_sts)) {
printf(rl%d: MII without any phy!\n, sc-rl_unit);
- bus_teardown_intr(dev, sc-rl_irq, sc-rl_intrhand);
bus_release_resource(dev, SYS_RES_IRQ, 0, sc-rl_irq);
bus_release_resource(dev, RL_RES, RL_RID, sc-rl_res);
bus_dmamem_free(sc-rl_tag,
@@ -1089,11 +1073,23 @@
* Call MI attach routine.
*/
ether_ifattach(ifp, ETHER_BPF_SUPPORTED);
- RL_UNLOCK(sc);
- return(0);
+ error = bus_setup_intr(dev, sc-rl_irq, INTR_TYPE_NET,
+ rl_intr, sc, sc-rl_intrhand);
+
+ if (error) {
+ printf(rl%d: couldn't set up irq\n, unit);
+ bus_release_resource(dev, SYS_RES_IRQ, 0, sc-rl_irq);
+ bus_release_resource(dev, RL_RES, RL_RID, sc-rl_res);
+ bus_dmamem_free(sc-rl_tag,
+ sc-rl_cdata.rl_rx_buf, sc-rl_cdata.rl_rx_dmamap);
+ bus_dma_tag_destroy(sc-rl_tag);
+ goto fail;
+ }
+
+ callout_handle_init(sc-rl_stat_ch);
+ return(0);
fail:
- RL_UNLOCK(sc);
mtx_destroy(sc-rl_mtx);
return(error);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Thanks, it works fine.
David
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: VESA 800x600 console not working
I have two patches: http://people.freebsd.org/~davidxu/vm86.diff http://people.freebsd.org/~davidxu/vm86_2.diff the first patch is to keep vm86lock as a sleep lock, and allow the thread calling vm86 bios could be preempted, but still only one thread can call vm86 bios. so if we want a sleep mutex in trap() code execute path, it hasn't problem. the second patch try to keep source code modification minimal, change vm86lock to spin lock, don't allow to be preempted when calling vm86 bios, but if someday someone wants a sleep mutex in trap() code execute path, it would have trouble. you can select one of them to apply. I am not maintainer of VM86 code, so I have trouble to commit this patch unless someone allow me to do. David Xu On Sunday 22 September 2002 06:09, Gavin Atkinson wrote: On Fri, 26 Jul 2002, David Xu wrote: Yes, this is a known problem. I have a patch for this, you may download it from here: http://opensource.zjonline.com.cn/freebsd/vm86patch.tgz Is there any chance of geting these committed? With them, my laptop is happy to give a 100x37 screen on VESA_800x600. Gavin - Original Message - From: Rob [EMAIL PROTECTED] To: Current [EMAIL PROTECTED] Sent: Saturday, July 27, 2002 6:46 AM Having a laptop here, I wanted to get the same 800x600 console that I have in -stable. I built my kernel with OPTIONS VESA and OPTIONS SC_PIXEL_MODE. I have tried two methods. The first was to put 0x0080 in the device.hints file for SC. That gave me a blank screen upon startup. I also tried putting into /usr/local/etc/rc.d the vidcontrol command vidcontrol -g 100x37 VESA_800x600. That gave me a blank screen at the end of the bootup. Is this functionality broken in -current, or am I doing something wrong? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel crash at boot time
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x10
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0227c89
stack pointer = 0x10:0xcd3029c4
frame pointer = 0x10:0xcd3029c4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 182 (route)
panic: from debugger
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc01f0819 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc01f0a48 in panic () at ../../../kern/kern_shutdown.c:493
#3 0xc0142692 in db_panic () at ../../../ddb/db_command.c:449
#4 0xc0142612 in db_command (last_cmdp=0xc0373820, cmd_table=0xc03299a8,
aux_cmd_tablep=0x104,
aux_cmd_tablep_end=0xc0f04840) at ../../../ddb/db_command.c:345
#5 0xc0142726 in db_command_loop () at ../../../ddb/db_command.c:471
#6 0xc014538a in db_trap (type=12, code=0) at ../../../ddb/db_trap.c:72
#7 0xc02fb2f2 in kdb_trap (type=12, code=0, regs=0xcd302984) at
../../../i386/i386/db_interface.c:160
#8 0xc030b982 in trap_fatal (frame=0xcd302984, eva=0) at ../../../i386/i386/trap.c:837
#9 0xc030b692 in trap_pfault (frame=0xcd302984, usermode=0, eva=16) at
../../../i386/i386/trap.c:756
#10 0xc030b20d in trap (frame=
{tf_fs = -1070333928, tf_es = 16, tf_ds = -1057947632, tf_edi = -1057927680,
tf_esi = -1032651796, tf_ebp = -852481596, tf_isp = -852481616, tf_ebx = 238, tf_edx =
0, tf_ecx = -852481576, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071481719,
tf_cs = 8, tf_eflags = 66054, tf_esp = -852481560, tf_ss = -1071466855}) at
../../../i386/i386/trap.c:444
#11 0xc02fca38 in calltrap () at {standard input}:98
#12 0xc022b699 in sbappendaddr (sb=0xc272fbec, asa=0xc038c9f8, m0=0xc0f14e00,
control=0x0)
at ../../../kern/uipc_socket2.c:624
#13 0xc025de6f in raw_input (m0=0xc0f14e00, proto=0xc038ca18, src=0xc038c9f8,
dst=0xc038c9e8)
at ../../../net/raw_usrreq.c:116
#14 0xc026032b in rt_missmsg (type=0, rtinfo=0xcd302a58, flags=132101, error=0) at
../../../net/rtsock.c:735
#15 0xc025e3eb in rtalloc1 (dst=0xc272c900, report=1, ignflags=0) at
../../../net/route.c:196
#16 0xc025f228 in rt_setgate (rt0=0xc2729500, dst=0xc272c9dc, gate=0xc272c9ec) at
../../../net/route.c:998
#17 0xc025ec45 in rtrequest1 (req=1, info=0xcd302b44, ret_nrt=0xcd302b3c) at
../../../net/route.c:659
#18 0xc025f9d6 in route_output (m=0xc0f14d00, so=0xc272fba0) at
../../../net/rtsock.c:344
#19 0xc025e0cd in raw_usend (so=0x0, flags=0, m=0x0, nam=0x0, control=0x0,
td=0xc0f04840) at ../../../net/raw_usrreq.c:260
#20 0xc025f745 in rts_send (so=0x0, flags=0, m=0x0, nam=0x0, control=0x0, td=0x0) at
../../../net/rtsock.c:239
#21 0xc0228fe3 in sosend (so=0xc272fba0, addr=0x0, uio=0xcd302c7c, top=0xc0f14d00,
control=0x0, flags=0, td=0xc0f04840)
at ../../../kern/uipc_socket.c:707
#22 0xc0219300 in soo_write (fp=0x0, uio=0xcd302c7c, active_cred=0xc0f01200, flags=0,
td=0xc0f04840)
at ../../../kern/sys_socket.c:89
#23 0xc0213455 in dofilewrite (td=0xc0f04840, fp=0xc26b1d5c, fd=0, buf=0x80aa300,
nbyte=0, offset=0, flags=0) at file.h:214
#24 0xc0213299 in write (td=0xc0f04840, uap=0xcd302d10) at
../../../kern/sys_generic.c:332
#25 0xc030bcee in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134914908, tf_esi = 128, tf_ebp =
-1077936872, tf_isp = -852480652, tf_ebx = 134914944, tf_edx = 134915680, tf_ecx = 0,
tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = 134526191, tf_cs = 31, tf_eflags =
662, tf_esp = -1077936916, tf_ss = 47}) at ../../../i386/i386/trap.c:1046
#26 0xc02fca8d in Xint0x80_syscall () at {standard input}:140
note that when kernel ran into DDB, the fault instruction was at m_length+9,
but core dump did not record the fact.
David Xu
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: kernel crash at boot time
Thanks, it works again. :) - Original Message - From: Julian Elischer [EMAIL PROTECTED] To: David Xu [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 4:35 PM Subject: Re: kernel crash at boot time try now On Thu, 19 Sep 2002, David Xu wrote: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0227c89 stack pointer = 0x10:0xcd3029c4 frame pointer = 0x10:0xcd3029c4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 182 (route) panic: from debugger To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel crash at boot time
On Thursday 19 September 2002 17:03, Poul-Henning Kamp wrote:
Can you try with rev. 1.101 of sys/kern/uipc_mbuf.c please ? The
1.102... is wrong and could easily cause this.
Poul-Henning
In message 01be01c25fb1$8b92a990$ef01a8c0@davidwnt, David Xu writes:
#11 0xc02fca38 in calltrap () at {standard input}:98
#12 0xc022b699 in sbappendaddr (sb=0xc272fbec, asa=0xc038c9f8,
m0=0xc0f14e00, control=0x0) at ../../../kern/uipc_socket2.c:624
rev. 1.101 works fine.
David Xu
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
can not compile kernel
I have just updated kernel from freefall and compiling failed: c -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../kern/uipc_mbuf.c cc1: warnings being treated as errors ../../../kern/uipc_mbuf.c: In function `m_length': ../../../kern/uipc_mbuf.c:727: warning: `m' might be used uninitialized in this function *** Error code 1 # gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20020916 (prerelease) -- David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
--- Terry Lambert [EMAIL PROTECTED] wrote: I did. It's still an order of operation problem in the kernel during fork(), as Bruce pointed out in a later posting (so me pointing it out here is probably redundant... 8-)). I still think other code is going to have the problem, too, so changing su alone doesn't fix things. Better to not deliver the tty output stopped signal. -- Terry Don't touch tty code, if you change, you'll break more code, current problem is just because su forks a child process and want to take over some job control work from shell, it is of course not a easy job. the problem does not exist in STABLE branch because su does not fork. David Xu __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
--- Tim Robbins [EMAIL PROTECTED] wrote: On Tue, Aug 13, 2002 at 06:14:38AM -0700, David Xu wrote: --- Terry Lambert [EMAIL PROTECTED] wrote: I did. It's still an order of operation problem in the kernel during fork(), as Bruce pointed out in a later posting (so me pointing it out here is probably redundant... 8-)). I still think other code is going to have the problem, too, so changing su alone doesn't fix things. Better to not deliver the tty output stopped signal. -- Terry Don't touch tty code, if you change, you'll break more code, current problem is just because su forks a child process and want to take over some job control work from shell, it is of course not a easy job. the problem does not exist in STABLE branch because su does not fork. What about chpass, vipw, and the other pw_edit() consumers? vipw works correctly wrt suspending with ^Z on 4.6-RELEASE, but does not on -CURRENT. As far as I can see, pw_edit()'s logic has not been changed. This is a slightly different case to that of the shell suspending _itself_, but I think it's similar enough that the solution may be the same. Tim I have very current source, and don't have any problem you have encountered. I can not reproduced it. David Xu __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
--- Terry Lambert [EMAIL PROTECTED] wrote: David Xu wrote: What about chpass, vipw, and the other pw_edit() consumers? vipw works correctly wrt suspending with ^Z on 4.6-RELEASE, but does not on -CURRENT. As far as I can see, pw_edit()'s logic has not been changed. This is a slightly different case to that of the shell suspending _itself_, but I think it's similar enough that the solution may be the same. I have very current source, and don't have any problem you have encountered. I can not reproduced it. Both different reports have been from Tim Robbins. It may be that he has a local problem, and that his local problem is greatly confusing this discussion. If you can not repeat his second problem on -current locally, I would be tempted to dismiss it as being a local problem, and not a general one. Tim was also the person who posted the GPL'ed path that I was worried that Andrey was using against su; not to disparage anyone, but most of my personal confusion has been coming from things Tim said... 8-). -- Terry My machine may be different with Tim's, it is a P4 1.5G CPU, its speed maybe fast enough to skip the problem. BTW, bde has also reported the problem, so this is serious, wouldn't kernel send out SIGTTOU when null change a foreground group is enough to fix the problem?. but why don't they block SIGTTOU when calling tcsetpgrp()? David __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
--- Terry Lambert [EMAIL PROTECTED] wrote: My machine may be different with Tim's, it is a P4 1.5G CPU, its speed maybe fast enough to skip the problem. BTW, bde has also reported the problem, so this is serious, wouldn't kernel send out SIGTTOU when null change a foreground group is enough to fix the problem?. but why don't they block SIGTTOU when calling tcsetpgrp()? Bruce reported the first problem, with su, which arose from DES changing the code to support PAM, and to have an extra fork, where it didn't before. Bruce reported that he *didn't* have the second problem reported by Tim Robbins, which appears to be local to his site (a search of the archives indicates that he is the only one reporting it). The patch that Tim posted, which is GPL'ed because of its origin, and therefore unusable exacept as a model, fixes the problem by blocking the signal delivery before the fork. Note that merely blocking the delivery means that the signal will be delivered later, since block sugnals are accumulated, not discarded (see what the patch does, for details). -- Terry Sorry, I mean ignore SIGTTOU. David Xu __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
--- Andrey A. Chernov [EMAIL PROTECTED] wrote:
On Sun, Aug 11, 2002 at 17:41:20 +0400, Andrey A. Chernov wrote:
On Sun, Aug 11, 2002 at 06:28:54 -0700, David Xu wrote:
does anyone believe that su behaviours correctly?
I not believe in that first, so why I remove tcsetpgrg() in my initial
commit. It fix suspend/fg, but break stop $$/fg those times. I not test,
is it break stop $$/fg now too (I'll do it a bit later and send result).
fork/wait seems to be needed here just for PAM_END.
Yes, still there. If tcsetpgrp() removed, suspend/fg fixed, but stop
$$/fg kills login shell. It means that neither variant is correct, unless
there is a kernel bug. To be 100% sure, we need to test su with old
-current kernel without KSE. Anybody have that thing? I can cvsup early
kernel sources and build from them, but I don't know exact KSE changes
data. Other way is to build su statically and test on -stable. I don't
have any -stable machines around.
--
Andrey A. Chernov
http://ache.pp.ru/
Sorry, Andrey, current su's job control mode does not work under STABLE too,
I have tested, it has same result as under CURRENT. the following piece of
code does not work under STABLE, it mimics what su is doing in CURRENT
source tree.
#include err.h
#include errno.h
#include signal.h
#include stdio.h
#include sys/wait.h
#include unistd.h
int main()
{
pid_t ret_pid, statusp, child_pid, child_pgrp;
struct sigaction sa, sa_int, sa_quit, sa_tstp;
char buf[64];
char* sargv[3];
sa.sa_flags = SA_RESTART;
sa.__sigaction_u.__sa_handler = SIG_IGN;
sigemptyset(sa.sa_mask);
sigaction(SIGINT, sa, sa_int);
sigaction(SIGQUIT, sa, sa_quit);
sigaction(SIGTSTP, sa, sa_tstp);
child_pid = fork();
switch (child_pid) {
default:
while ((ret_pid = waitpid(child_pid, statusp, WUNTRACED)) != -1) {
if (WIFSTOPPED(statusp)) {
child_pgrp = tcgetpgrp(1);
kill(getpid(), SIGSTOP);
tcsetpgrp(1, child_pgrp);
kill(child_pid, SIGCONT);
statusp = 1;
continue;
}
break;
}
if (ret_pid == -1)
err(1, waitpid);
exit(statusp);
case -1:
err(1, fork);
exit(1);
case 0:
sigaction(SIGINT, sa_int, NULL);
sigaction(SIGQUIT, sa_quit, NULL);
sigaction(SIGTSTP, sa_tstp, NULL);
sargv[0] = csh;
sargv[1] = NULL;
execv(/bin/csh, sargv);
printf(hi, there!\n);
break;
}
return 0;
}
David
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
--- David Xu [EMAIL PROTECTED] wrote:
--- Andrey A. Chernov [EMAIL PROTECTED] wrote:
On Sun, Aug 11, 2002 at 17:41:20 +0400, Andrey A. Chernov wrote:
On Sun, Aug 11, 2002 at 06:28:54 -0700, David Xu wrote:
does anyone believe that su behaviours correctly?
I not believe in that first, so why I remove tcsetpgrg() in my initial
commit. It fix suspend/fg, but break stop $$/fg those times. I not test,
is it break stop $$/fg now too (I'll do it a bit later and send result).
fork/wait seems to be needed here just for PAM_END.
Yes, still there. If tcsetpgrp() removed, suspend/fg fixed, but stop
$$/fg kills login shell. It means that neither variant is correct, unless
there is a kernel bug. To be 100% sure, we need to test su with old
-current kernel without KSE. Anybody have that thing? I can cvsup early
kernel sources and build from them, but I don't know exact KSE changes
data. Other way is to build su statically and test on -stable. I don't
have any -stable machines around.
--
Andrey A. Chernov
http://ache.pp.ru/
Sorry, Andrey, current su's job control mode does not work under STABLE too,
I have tested, it has same result as under CURRENT. the following piece of
code does not work under STABLE, it mimics what su is doing in CURRENT
source tree.
#include err.h
#include errno.h
#include signal.h
#include stdio.h
#include sys/wait.h
#include unistd.h
int main()
{
pid_t ret_pid, statusp, child_pid, child_pgrp;
struct sigaction sa, sa_int, sa_quit, sa_tstp;
char buf[64];
char* sargv[3];
sa.sa_flags = SA_RESTART;
sa.__sigaction_u.__sa_handler = SIG_IGN;
sigemptyset(sa.sa_mask);
sigaction(SIGINT, sa, sa_int);
sigaction(SIGQUIT, sa, sa_quit);
sigaction(SIGTSTP, sa, sa_tstp);
child_pid = fork();
switch (child_pid) {
default:
while ((ret_pid = waitpid(child_pid, statusp, WUNTRACED)) != -1) {
if (WIFSTOPPED(statusp)) {
child_pgrp = tcgetpgrp(1);
kill(getpid(), SIGSTOP);
tcsetpgrp(1, child_pgrp);
kill(child_pid, SIGCONT);
statusp = 1;
continue;
}
break;
}
if (ret_pid == -1)
err(1, waitpid);
exit(statusp);
case -1:
err(1, fork);
exit(1);
case 0:
sigaction(SIGINT, sa_int, NULL);
sigaction(SIGQUIT, sa_quit, NULL);
sigaction(SIGTSTP, sa_tstp, NULL);
sargv[0] = csh;
sargv[1] = NULL;
execv(/bin/csh, sargv);
printf(hi, there!\n);
break;
}
return 0;
}
following is patch for su, I can type suspend and stop $$ without the
problem you described, I have tested it under tcsh and bash, all works
for me.
--- su.cMon Aug 12 13:08:01 2002
+++ su.c.newMon Aug 12 13:16:14 2002
@@ -329,10 +329,13 @@
default:
while ((ret_pid = waitpid(child_pid, statusp, WUNTRACED)) != -1) {
if (WIFSTOPPED(statusp)) {
- child_pgrp = tcgetpgrp(1);
kill(getpid(), SIGSTOP);
- tcsetpgrp(1, child_pgrp);
- kill(child_pid, SIGCONT);
+ child_pgrp = getpgid(child_pid);
+ if (tcgetpgrp(1) == getpgrp())
+ {
+ tcsetpgrp(1, child_pgrp);
+ kill(child_pid, SIGCONT);
+ }
statusp = 1;
continue;
}
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: VESA 800x600 console not working
Yes, this is a known problem. I have a patch for this, you may download it from here: http://opensource.zjonline.com.cn/freebsd/vm86patch.tgz David Xu - Original Message - From: Rob [EMAIL PROTECTED] To: Current [EMAIL PROTECTED] Sent: Saturday, July 27, 2002 6:46 AM Subject: VESA 800x600 console not working Having a laptop here, I wanted to get the same 800x600 console that I have in -stable. I built my kernel with OPTIONS VESA and OPTIONS SC_PIXEL_MODE. I have tried two methods. The first was to put 0x0080 in the device.hints file for SC. That gave me a blank screen upon startup. I also tried putting into /usr/local/etc/rc.d the vidcontrol command vidcontrol -g 100x37 VESA_800x600. That gave me a blank screen at the end of the bootup. Is this functionality broken in -current, or am I doing something wrong? Thanks, Rob. -- - The Numeric Python EM Project www.pythonemproject.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: signal handling bug in KSE MIII
Good, but I see no problem there, cursig() does not suspend thread because
as I said issignal() just sets a P_STOPPED_SGNL flag, not stops. msleep()
calls thread_suspend_check() with return_instead flag set, so msleep does not
suspend, too condvar. it is just interrupted by any signal if PCATCH set in
priority argument. thread suspending does already happen at user boundary.
The problem is that if you send a suspend signal (STOP) to a process, all
the threads must be accounted for before we can say that the
process is 'stopped'.
this can be done in thread_suspend_check(), if last suspended thread finds
that it is stopped by P_STOPPED_SGNL or traced flag, it can send SIGCHLD
with stopped status to parent process.
David Xu
--- Julian Elischer [EMAIL PROTECTED] wrote:
On Sun, 21 Jul 2002, David Xu wrote:
--- David Xu [EMAIL PROTECTED] wrote:
I found signal handling is still broken in CURRENT source.
the following program demostrates the bug is still in kernel:
#include stdio.h
#include signal.h
void handler(int sig)
{
signal(SIGTSTP, SIG_DFL);
kill(getpid(), SIGTSTP);
}
int main()
{
char buf[64];
signal(SIGTSTP, handler);
kill(getpid(), SIGTSTP);
printf(input foo:);
scanf(%63s, buf);
printf(you input:%s\n, buf);
return 0;
}
when I press CTRL+Z, the program does not suspend and directly exits.
ktrace indicates that the program directly exits in kernel without
calling exit() from program.
I found SA_STOP handling is disabled in issignal(), delayed SIGTSTP
is forgotten by kernel, this is the reason why SIGTSTP signal handling
is broken. at least, one program is affected --- ftp, run ftp
client program, when 'ftp' prompt appears, pressing CTRL+Z, causes ftp
to exit and do not suspend. patch:
Ok, I see it.. now there is a problem when we start to consider a multi
threaded process. This is why I defined out the code (and forgot that
fact in teh 6 months following).
The problem is that if you send a suspend signal (STOP) to a process, all
the threads must be accounted for before we can say that the
process is 'stopped'. There are three basic sources of STOP conditions
being asserted, one of which is new.
1/ Signals
2/ Ptrace
3/ a single-threading funnel.
The third is new and is also where the problem is.
A single threading funnel is needed when a process does some system calls.
for example, if it calls fork(). The thread calling fork() needs to know
that all the other threads are in a safe suspended state before it can
proceed into fork1(). To do this, it suspends itself, and sets a
STOPPED condition on the process. When the last thread is suspended, then
the initial thread is allowed to proceed, safe in teh knowledge that
no other thread is doing anything in userland that would produce an
inconsistant state for the child. (or in the kernel for
that matter). Once the fork has been completed, the STOPPED
condition is lefted and the other threads are allowed to continue.
Teh question is whether it is safe to suspend the other threads
at palces other than the user boundary.. e.g. most of the calls
to issignal() are in msleep and the condvar code.
The picture gets more messy when we realise that SOMETIMES the funnel
doesn't want the other threads to be suspended, but rather, to EXIT.
this happens at the moment at the start of exit1(), and in exec().
In both of these cases, threads other than that doing the exit() or exec()
calls must be trapped in a safe place and aborted. The only safe place
to do this is at the user boundary. You have to force any such threads
that may be about to sleep, to abort and return to the user boundary.
The thread doing the exit() can not proceed until
all other threads have been accounted for. Because these two cases are
similar, I combined them into a single facility. Thread_single()
and friends.. (it's a posibility that this was a mistake but
I'm not convinced of that yet. Basically if the STOPPED_SNGLE
flag is set in the process, any thread trying to go to userland
will drop into the funnel code. If it gets there and discovers that the
SNGLE_EXIT flag is also set it will abort rather than suspending.
The difficulty is that issignal is catching suspensions and stopping the
threads at the point of the sleep(), in teh middle of whatever operation
it is doing. As a result of this a suspended thread cannot proceed to
the user boundary, and we are deadlocked as teh exiting process is
waiting for all the other threads to exit and the STOPPED
threads a re waiting for the STOP state to be lifted.
My theory was that we need to allow the restarting thread
(from the msleep() to contiue on to the user boundary and stop it THERE.)
rather than stopping it in the middle of whatever calculations it was
doing, holding whatever resources it holds (vnodes etc
Re: signal handling bug in KSE MIII
--- David Xu [EMAIL PROTECTED] wrote:
I found signal handling is still broken in CURRENT source.
the following program demostrates the bug is still in kernel:
#include stdio.h
#include signal.h
void handler(int sig)
{
signal(SIGTSTP, SIG_DFL);
kill(getpid(), SIGTSTP);
}
int main()
{
char buf[64];
signal(SIGTSTP, handler);
kill(getpid(), SIGTSTP);
printf(input foo:);
scanf(%63s, buf);
printf(you input:%s\n, buf);
return 0;
}
when I press CTRL+Z, the program does not suspend and directly exits.
ktrace indicates that the program directly exits in kernel without
calling exit() from program.
I found SA_STOP handling is disabled in issignal(), delayed SIGTSTP
is forgotten by kernel, this is the reason why SIGTSTP signal handling
is broken. at least, one program is affected --- ftp, run ftp
client program, when 'ftp' prompt appears, pressing CTRL+Z, causes ftp
to exit and do not suspend. patch:
--- kern_sig.c.oldSun Jul 21 15:38:00 2002
+++ kern_sig.cSun Jul 21 16:31:02 2002
@@ -1657,7 +1657,7 @@
#endif
break; /* == ignore */
}
-#if 0
+
/*
* If there is a pending stop signal to process
* with default action, stop here,
@@ -1679,16 +1679,10 @@
PROC_UNLOCK(p-p_pptr);
mtx_lock_spin(sched_lock);
stop(p);
- PROC_UNLOCK(p);
- DROP_GIANT();
- p-p_stats-p_ru.ru_nivcsw++;
- mi_switch();
mtx_unlock_spin(sched_lock);
- PICKUP_GIANT();
- PROC_LOCK(p);
break;
} else
-#endif
+
if (prop SA_IGNORE) {
/*
* Except for SIGCONT, shouldn't get here.
David Xu
OOPS, the extra kill() calling in main() should be removed
in demo program, correct source code is:
#include stdio.h
#include signal.h
void handler(int sig)
{
signal(SIGTSTP, SIG_DFL);
kill(getpid(), SIGTSTP);
}
int main()
{
char buf[64];
signal(SIGTSTP, handler);
printf(input foo:);
scanf(%63s, buf);
printf(you input:%s\n, buf);
return 0;
}
David Xu
__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
race condition in kern_descrip.c and fix
I found a race condition in kern_descrip.c, the race is in function falloc(),
it opens a race window at line 1147:
FILEDESC_UNLOCK(p-p_fd);
sx_xlock(filelist_lock);
FILEDESC_LOCK(p-p_fd);
fix:
--- kern_descrip.c Tue Jul 16 12:29:44 2002
+++ kern_descrip.c.new Tue Jul 16 12:26:50 2002
-1107,6 +1107,7
register struct file *fp, *fq;
int error, i;
+retry:
sx_xlock(filelist_lock);
if (nfiles = maxfiles) {
sx_xunlock(filelist_lock);
-1151,6 +1152,13
LIST_INSERT_AFTER(fq, fp, f_list);
} else {
LIST_INSERT_HEAD(filehead, fp, f_list);
+ }
+ if (p-p_fd-fd_ofiles[i] != NULL) {
+ fp-f_count = 0;
+ FILEDESC_UNLOCK(p-p_fd);
+ sx_xunlock(filelist_lock);
+ ffree(fp);
+ goto retry;
}
p-p_fd-fd_ofiles[i] = fp;
FILEDESC_UNLOCK(p-p_fd);
---
David Xu
¡Iì¹» ®Þ±éݨ¥¶Ý¢jçH:+éì¹» ®Þ~·nÇ\ººÞا¶¡Ü¨~Ø^ë,j
Re: i386 trap code
--- John Baldwin [EMAIL PROTECTED] wrote: On 07-Jul-2002 Jonathan Lemon wrote: On Sat, Jul 06, 2002 at 11:59:50PM -0700, David Xu wrote: Jonthan, I just use DOS program as an example, for any program, if it wants to go into VM86 mode, it is very easy, just calls i386_vm86() to initailize its VM86 pcb extension, setups some memory area, then call sigreturn() to turn into VM86 mode. I think global in_vm86call flags is a bug under SMP, it creates a race condition. suppose this scenario: CPU A is running a simple VM86 code program. CPU B is running vm86_intcall() by some kernel driver (vesa module ?) CPU B set in_vm86call = 1 CPU A gets a fault trap. CPU A runs trap(), and find that in_vm86call is set and handles the trap as it is running vm86_intcall(), but it is not true and make a mess. Yes, as I mentioned earlier, the way the original vm86 bioscall worked was to prevent an AST until the BIOS was done. This relied on the giant lock for correctness, since we only allowed one CPU into the kernel at once. There probably needs to be some work done for -current in this area. Since vm86_lock is a spin lock, you could possibly make in_vm86call per-cpu or you could just check the lock instead of the variable to fix this. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ when did the vm86_lock become spin lock ? I havn't seen changes in cvs, it is still a MTX_DEF. I had tried changing it to spin lock and got a panic. :( David Xu __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Timeout and SMP race
--- Justin T. Gibbs [EMAIL PROTECTED] wrote: I believe I had this conversation with Justin Gibbs earlier; he told me that the callout consumers (network, cam) had to be aware of the race and handle this if it matters. I don't particularly like complicating the callout handlers as illustrated above, though, so if a better scheme is possible, that would be nice. If callout_stop() is always called from a context that can block and we desire the semantics that upon return from callout_stop(), you are not in the callout handler, it seems that this should be quite easy to achieve. Just track the state of the callout from commit and return, via some flags locked by a global mutex. If a callout_stop is called between commit and return (just look at a global indicating the currently running callout protected by this mutex), put the thread on a list to be woken by the thread issuing the callout. To handle the case of a reschedule performed by the callout itself, the woken up caller to callout_stop() will have to loop through the test again. In all cases, the global mutex is only held for very short operations as a leaf mutex. tsleep() is only called from process context With interrupt threads, isn't process context a bit of a misnomer? Would it be acceptable for the interrupt threads that perform callout_stops to block waiting for them to take effect? -- Justin I have a patch which is very like what you said here. I set a flag between commit and return, and blocking callout_stop() caller if it is not in softclock() context, the patch still has some problems, for example lock oder reversal which is pointed out by jhb. but Archie Cobbs and others are talking about another resolution, I will set back. David Xu __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: userret() , ast() and the end of syscalls
I found the problem two weeks ago, but I can not find a better way to avoid userret() to be called twice. so I keep silence. :( David Xu Gartner: Apache is vulnerable, we recommend switching back to IIS to protect yourselves - Original Message - From: Julian Elischer [EMAIL PROTECTED] To: FreeBSD current users [EMAIL PROTECTED] Sent: Tuesday, July 09, 2002 2:40 PM Subject: userret() , ast() and the end of syscalls A question to those who know.. why is userret() called both at the end of trap() or syscall() and also almost immediatly again (often) at the end of ast(). It seems that really there is no one place that one can put code that will be called ONCE and ONLY ONCE as a thread progresses to userland. There is no one place where you can say after this point we are in userland right up until that iret instruction. There is always the danger that FTER ny insruction that decides that we are now definitly going to user space, there could occur an interrupt that causes a reschedule so that some OTHER thread goes to user land. Is it possible to clear interrupts and have the iret instruction itself re-enable them? (that would give a few instructions 'atomically' with the iret which may be all I need). is this possible in other architectures? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: userret() , ast() and the end of syscalls
- Original Message - From: John Baldwin [EMAIL PROTECTED] To: John Baldwin [EMAIL PROTECTED] Cc: FreeBSD current users [EMAIL PROTECTED]; FreeBSD current users [EMAIL PROTECTED]; Julian Elischer [EMAIL PROTECTED] Sent: Tuesday, July 09, 2002 8:40 PM Subject: RE: userret() , ast() and the end of syscalls On 09-Jul-2002 John Baldwin wrote: On 09-Jul-2002 Julian Elischer wrote: A question to those who know.. why is userret() called both at the end of trap() or syscall() and also almost immediatly again (often) at the end of ast(). ast() is really a special form of a trap that is triggered by doing a last-minute type check on return to userland to see if we still have work to do. It seems that really there is no one place that one can put code that will be called ONCE and ONLY ONCE as a thread progresses to userland. Sure there is. When you want an action done, set a thread flag marking the request and set TDF_ASTPENDING. Then handle it in ast() if the flag is set. Or, if this needs to happen on every return and not conditionally, then do it in userret() and use the state of a variable or some flag to note when you've already done it. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ hope this won't increase per-thread memory requirement, I would like to create more threads using same memory size. :) David Xu __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
