Re: PThreads problem
On Mon, 21 Oct 2002, Peter Pentchev wrote: Okay, I can see what the problem is; however, I have absolutely no idea how it is to be solved :( The DNS resolution routines of libcurl use alarm() as a timeout mechanism for the system DNS resolving functions. To enforce the timeout even when the resolver functions are automatically restarted after the SIGALRM signal, libcurl attempts to set a jump buffer in the thread doing the DNS lookup, and to siglongjmp() to it from the SIGALRM handler. This works just fine on Linux, where each thread executes as a separate process; the signal is correctly delivered to the thread which invoked alarm(), and, consequently, exactly the one that set the jump buffer in the first place. This demonstrates one of the evils of LinuxThreads. Now there's code that is seemingly dependent on non-portable thread behaviour. Well, perhaps it's not an evil of LinuxThreads, but of an evil library/application ;-) On FreeBSD, however, the signal is delivered merely to the currently executing thread; if the resolver routines are currently in the process of sending or receiving data on a network socket, the currently executing thread may very well not be the one that has requested the resolving, and so siglongjmp() may be called from a thread which is NOT the one the jump buffer has been set in. As the abort error message states, this is behavior not covered by any standards, and, I dare say, not very easy to implement at all, so it is currently unimplemented in FreeBSD. For a standards reference, the SUSv2 siglongjmp() manpage at http://www.opengroup.org/onlinepubs/007908799/xsh/siglongjmp.html explicitly states at the end of the DESCRIPTION section: The effect of a call to siglongjmp() where initialisation of the jmp_buf structure was not performed in the calling thread is undefined. Right, and I think there's a little stronger wording than that in the '96 POSIX spec. It doesn't make sense regardless because you'd be trying to jump to a context that uses another thread's stack. Blocking all signals resulted in an application which executed but still I got problems with slow responses from libcurl As I understand it, the only reason for SIGALRM to make a difference would be a situation where a DNS query times out, at least by libcurl's standards. Is your application trying to do such lookups? If anybody is interested, I am attaching a short proof-of-concept program which starts up two threads, then waits for a signal handler to hit. If the longjmp() call is commented out, it displays the thread ID of the thread which received the signal - almost always the main thread, the one listed as 'me' in the list output at the program start, and most definitely not the last thread to call setjmp(), as that would be 't2'. If the longjmp() call is uncommented, the signal handler executing in the 'me' thread will longjmp() to a buffer initialized in the 't2' thread, and the program will abort with your error message with a 100% failure (or would that be success in proving the concept?) rate. You shouldn't be calling pthread_mutex_lock and friends from a signal handler. People knowledgeable about threads: would there be a way to fix that problem? I don't know.. something like examining the jump buffer, then activating the thread that is stored there, and resuming the currently executing thread at the point where it was interrupted by the signal? Without looking at the code, I can guess that most probably the answer would be a short burst of hysterical laughter :) Still.. one may hope.. :) No, this can't be easily fixed nor would we want to fix it ;-) There are other ways to wait for events. If multiple threads need to have timeouts then you can always create a server thread to process timeouts. You can use mutexes and condition variables to add and remove timeout events to the server thread, and the server thread can use sigalarm() and sigwait() or sigsuspend() to wait for the alarm. When the sigwait()/sigsuspend() wakeup, the server thread can pull event timeouts off its list and signal the timedout threads using pthread_kill() or whatever. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Scheduling a recurring task in a device driver
A device driver I'm porting from Linux uses tasklets to schedule a recurring event to work around a hardware bug. What would be the equivalent in FreeBSD? David Christensen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Ati Rage 128: Dpms suspend failes
Hello, I have two hosts connected to one monitor. My idea is attach the display to the other host by issuing `xset dpms force suspend'. This works on one host with a Matrox Millenium. On the host with an Ati Rage 128 Pro TF it works with Netbsd, but it doesn't work with FreeBSD 4.7-Release. The screen only turns blank but the LED remains green. This is the same when issuing `xset s activate'. What could be the reason on FreeBSD 4.7 that dpms force suspend doesn't work? Installed are XFree86-Server-4.2.1_3 and XFree86-libraries-4.2.1_1.) -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PThreads problem
mån 2002-10-21 klockan 21.44 skrev Peter Pentchev: On Mon, Oct 21, 2002 at 06:33:46PM +0200, Linus Kendall wrote: Answer inline below. m?n 2002-10-21 klockan 15.50 skrev Peter Pentchev: On Mon, Oct 21, 2002 at 04:48:34PM +0300, Peter Pentchev wrote: On Mon, Oct 21, 2002 at 03:24:08PM +0200, Linus Kendall wrote: m?n 2002-10-21 klockan 14.45 skrev Peter Pentchev: On Mon, Oct 21, 2002 at 01:35:59PM +0200, Linus Kendall wrote: Hi, I'm trying to port a heavily threaded application from Linux (Debian 3.0, 2.4.19) to FreeBSD (4.6-RELEASE). The program compiles successfully using gcc with -pthreads. But, when I try to run the application I get the following error after a while (after spawning 11 threads): Fatal error 'siglongjmp()ing between thread contexts is undefined by POSIX 1003.1' at line ? in file /usr/src/lib/libc_r/uthread/uthread_jmp.c (errno = ?) Abort trap - core dumped [snip] This is interesting; can you produce a simple testcase? If not, I will be able to take a look at it some time later today or tomorrow, but not right now :( I'm not sure if I've really got time to produce a testcase. As I've understood the main cause of the crash was that in *BSD the signals are sent to each thread but in Linux they're sent to the process. Okay, I can see what the problem is; however, I have absolutely no idea how it is to be solved :( The DNS resolution routines of libcurl use alarm() as a timeout mechanism for the system DNS resolving functions. To enforce the timeout even when the resolver functions are automatically restarted after the SIGALRM signal, libcurl attempts to set a jump buffer in the thread doing the DNS lookup, and to siglongjmp() to it from the SIGALRM handler. This works just fine on Linux, where each thread executes as a separate process; the signal is correctly delivered to the thread which invoked alarm(), and, consequently, exactly the one that set the jump buffer in the first place. On FreeBSD, however, the signal is delivered merely to the currently executing thread; if the resolver routines are currently in the process of sending or receiving data on a network socket, the currently executing thread may very well not be the one that has requested the resolving, and so siglongjmp() may be called from a thread which is NOT the one the jump buffer has been set in. As the abort error message states, this is behavior not covered by any standards, and, I dare say, not very easy to implement at all, so it is currently unimplemented in FreeBSD. For a standards reference, the SUSv2 siglongjmp() manpage at http://www.opengroup.org/onlinepubs/007908799/xsh/siglongjmp.html explicitly states at the end of the DESCRIPTION section: The effect of a call to siglongjmp() where initialisation of the jmp_buf structure was not performed in the calling thread is undefined. Blocking all signals resulted in an application which executed but still I got problems with slow responses from libcurl As I understand it, the only reason for SIGALRM to make a difference would be a situation where a DNS query times out, at least by libcurl's standards. Is your application trying to do such lookups? If anybody is interested, I am attaching a short proof-of-concept program which starts up two threads, then waits for a signal handler to hit. If the longjmp() call is commented out, it displays the thread ID of the thread which received the signal - almost always the main thread, the one listed as 'me' in the list output at the program start, and most definitely not the last thread to call setjmp(), as that would be 't2'. If the longjmp() call is uncommented, the signal handler executing in the 'me' thread will longjmp() to a buffer initialized in the 't2' thread, and the program will abort with your error message with a 100% failure (or would that be success in proving the concept?) rate. People knowledgeable about threads: would there be a way to fix that problem? I don't know.. something like examining the jump buffer, then activating the thread that is stored there, and resuming the currently executing thread at the point where it was interrupted by the signal? Without looking at the code, I can guess that most probably the answer would be a short burst of hysterical laughter :) Still.. one may hope.. :) That was very thorough, thanks! Now I at least have a notion of what is going on. Since this is slightly urgent I guess a hack into the libcurl source code to try to remove the sigalarms would do the trick (in my case). In the general case it seems like there's a rather big problem here as libcurl's behavior cannot really work together with the FreeBSD implementation of threads. /Linus. G'luck, Peter -- Peter Pentchev[EMAIL PROTECTED][EMAIL PROTECTED] PGP key:
Re: Kernel Panic Problems
Sorry for that.
Diego Wentz Antunes wrote:
I have been experiencing several kernel panics from differents
situations, since a ls to just boot the kernel.
I configured all the options in rc.conf to save the core dump from
memory to HD and some of the results are
here in the file panics. Above all I search at internet some information
to try to explain this recursive panics
and found that it could be some memory problem. Is there a way to make a
hard test with memory?
I'm uncertainty if it is the memory because the PC stayed turned on
for 6 days without any problem!
Any comments will be welcome!
| Content-Type: application/x-java-applet; name=panics
| Content-Transfer-Encoding: base64
| Content-Disposition: inline; filename=panics
Do you have a version of your panic messages which are not
represented as a JAva applet with inline disposition, so that
people's mail clients would try to run it as Java bytecode
when they tried to open the attachment?
-- Terry
FreeBSD 4.6.2-RELEASE FreeBSD 4.6.2-RELEASE #1: Mon Oct 21 01:37:44 BRST 2002
root:/usr/src/sys/compile/KERNEL i386
### Panic 1 ###
GNU gdb 4.18 (FreeBSD)
Copyright 1998 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-unknown-freebsd.
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file kernle\ e el.1
(kgdb) core-file vmcore.1
IdlePTD at phsyical address 0x003a5000
initial pcb at physical address 0x002f2bc0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0x0
stack pointer = 0x10:0xc3e8be8c
frame pointer = 0x10:0x0
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 = 91 (savecore)
interrupt mask = none
trap number = 12
panic: page fault
syncing disks... 8 2 1
done
Uptime: 50s
dumping to dev #ad/0x20001, offset 460256
dump ata0: resetting devices .. done
32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 dumpsys () at ../../kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:487
#1 0xc0164d4b in boot (howto=256) at ../../kern/kern_shutdown.c:316
#2 0xc0165189 in panic (fmt=0xc02ae96c %s) at ../../kern/kern_shutdown.c:595
#3 0xc02623ab in trap_fatal (frame=0xc3e8be4c, eva=0) at ../../i386/i386/trap.c:966
#4 0xc0262059 in trap_pfault (frame=0xc3e8be4c, usermode=0, eva=0) at
../../i386/i386/trap.c:859
#5 0xc0261bff in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 671703040,
tf_esi = 0,
tf_ebp = 0, tf_isp = -1008157064, tf_ebx = -1008183320, tf_edx = -1087061161,
tf_ecx = -1008183320,
tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = 0, tf_cs = 8, tf_eflags =
66118,
tf_esp = -1071632535, tf_ss = 8}) at ../../i386/i386/trap.c:458
(kgdb) quit
### Panic 2 ###
GNU gdb 4.18 (FreeBSD)
Copyright 1998 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-unknown-freebsd.
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
IdlePTD at phsyical address 0x003a5000
initial pcb at physical address 0x002f2bc0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x3a
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc01f5f82
stack pointer = 0x10:0xc3ee1b28
frame pointer = 0x10:0xc3ee1bc8
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 = 256 (ls)
interrupt mask = tty
trap number = 12
panic: page fault
syncing disks... 17
done
Uptime: 8m59s
dumping to dev #ad/0x20001, offset 460256
dump ata0: resetting devices .. done
32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 dumpsys () at ../../kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:487
#1 0xc0164d4b in boot (howto=256) at
Re: Ati Rage 128: Dpms suspend failes
On Oct 21 at 15:10, Andrew Gallatin spoke: Eric Anholt writes: You need XFree86-Server-4.2.1_4 or later (it's at _5 now). I'm running 4.2.1_4 and dpms does not work for me. I just grabbed some diffs from the Xfree86 cvs to bring drivers/ati/r128_driver.c up to 1.57.2.1 and drivers/ati/r128_reg.h up to 1.14 and rebuilt the my r128_drv.o module. I'll see if it works the next time X crashes.. (I'm running current, so X crashes once/day or so..) I'm usually running RELEASE. I cvsuped ports-x11 and portupgraded XFree86-Servers. Now suspend works. I haven't encountered other problems so far. -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: IP resolving
On Mon, Oct 21, 2002 at 12:19:03AM -0600, Scott Carmichael wrote: Netstat reports properly... I think the issue is that an 'nslookup [ip]' will resolve to a host where an 'nslookup [host]' will not resolve to [ip]. Its the way the DNS on the other end is set up, but I can't exactly change that... I'd just like a 'w' to be able to report properly (ie. if [host] doesn't resolve to [ip], then just report [ip] with a 'w').. or something. =\ You never said if you are using TCP wrappers. Can you show us the actual output from the machine? What do, $ w $ w -n $ who $ last | head $ netstat -an Show? Do you get identical results with rlogin and ssh? Can we see both? On Fri, 18 Oct 2002, Crist J. Clark wrote: On Sun, Oct 13, 2002 at 11:00:26PM -0600, Scott Carmichael wrote: Can someone help me here? Is there a code change I can make somewhere? Please CC me on any replies, as I am not subscribed to -net or -hackers. -net removed. -hackers left (although this might be more of a -questions thread). -- Forwarded message -- Date: Fri, 11 Oct 2002 14:14:08 -0600 (MDT) From: Scott Carmichael [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: IP resolving I would like to know two things... Why FreeBSD acts in the following way while OpenBSD does not, and if it's possible to fix this? It seems that if anyone connects to my FreeBSD server wish a hostname that does not match their IP, Hostname does not match their IP? What exactly does that mean? All the OS knows is the remote IP address. It doesn't know what hostname the remote claims to have. The application server might receive a hostname though, but then I would expect the behavior to vary according to the application used to connect. I get a console message about the mismatch, and Something is generating a message to syslogd(8). Figure out what it is and edit syslog.conf(5) appropriately. Are you using TCP wrappers or something? then if they connect via rlogin or ssh, 'who', 'w', 'last', etc. all report that they are connected _from_ MY box, which they aren't. Strange. What does 'netstat -a' or 'sockstat' report? 'w' works fine for me. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Kernel Panic Problems
Diego Wentz Antunes wrote:
I have been experiencing several kernel panics from differents
situations, since a ls to just boot the kernel.
I configured all the options in rc.conf to save the core dump from
memory to HD and some of the results are
here in the file panics. Above all I search at internet some information
to try to explain this recursive panics
and found that it could be some memory problem. Is there a way to make a
hard test with memory?
I'm uncertainty if it is the memory because the PC stayed turned on
for 6 days without any problem!
Any comments will be welcome!
Panic #1:
---
#0 dumpsys () at ../../kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:487
#1 0xc0164d4b in boot (howto=256) at ../../kern/kern_shutdown.c:316
#2 0xc0165189 in panic (fmt=0xc02ae96c %s) at ../../kern/kern_shutdown.c:595
#3 0xc02623ab in trap_fatal (frame=0xc3e8be4c, eva=0) at
../../i386/i386/trap.c:966
#4 0xc0262059 in trap_pfault (frame=0xc3e8be4c, usermode=0, eva=0) at
../../i386/i386/trap.c:859
#5 0xc0261bff in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi =
671703040, tf_esi = 0,
tf_ebp = 0, tf_isp = -1008157064, tf_ebx = -1008183320, tf_edx =
-1087061161, tf_ecx = -1008183320,
tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = 0, tf_cs = 8, tf_eflags
= 66118,
tf_esp = -1071632535, tf_ss = 8}) at ../../i386/i386/trap.c:458
(kgdb) quit
---
Is this a full backtrace? I don't see any way that the stack
could have started with trap_pfault... it had to be running
something to cause a page fault.
Panic #2:
---
...
#8 0xc0261bff in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi =
-1064400440, tf_esi = -1007800320,
tf_ebp = -1007805296, tf_isp = -1007805336, tf_ebx = 47288, tf_edx =
-1690778642, tf_ecx = 821789308,
tf_eax = -56600120, tf_trapno = 12, tf_err = 0, tf_eip = -1071249494,
tf_cs = 8, tf_eflags = 66070,
tf_esp = -1064405504, tf_ss = 2606062}) at ../../i386/i386/trap.c:458
#9 0xc02607aa in generic_bcopy ()
#10 0xc0247c30 in scstart (tp=0xc0879b00) at ../../dev/syscons/syscons.c:1285
#11 0xc017c1e4 in ttstart (tp=0xc0879b00) at ../../kern/tty.c:1401
#12 0xc017ccb9 in ttwrite (tp=0xc0879b00, uio=0xc3ee1ed4, flag=8323073) at
../../kern/tty.c:1957
...
---
This one stops being possible at #9; specifically, there is no
version of syscons.c that, in scstart, calls generic_bcopy()
directly. The only functions it calls directly are q_to_b(),
which is a copy, but the function which does it is not static,
and has a global definition, and therefore should show up in
the stack trace. Similarly, the sc_puts() is also called.
None of this really matches 4.4, 4.6, or -current syscons.c,
so more information is needed, but it's unlikely that syscons
has changed and changed back, so significantly. You need to
look at the code at dev/syscons/syscons.c:1285 in your own
source tree, which seems to differ significantly from the source
tree the rest of us are using.
Panic #3:
---
#4 0xc0262059 in trap_pfault (frame=0xc3e6ce60, usermode=0, eva=198) at
../../i386/i386/trap.c:859
#5 0xc0261bff in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi =
135077888, tf_esi = -25115817,
tf_ebp = -1008283996, tf_isp = -1008284020, tf_ebx = 158, tf_edx =
1153435399, tf_ecx = -1008314576, tf_eax = 0,
tf_trapno = 12, tf_err = 2, tf_eip = -1071660533, tf_cs = 8, tf_eflags =
66050, tf_esp = 16560, tf_ss = -1008283852})
at ../../i386/i386/trap.c:458
#6 0xc01fc20b in vm_object_reference (object=0x9e) at ../../vm/vm_object.c:243
#7 0xc01f5f6c in vm_fault (map=0xc357fe80, vaddr=135077888, fault_type=3
'\003', fault_flags=8) at ../../vm/vm_fault.c:254
#8 0xc0261fee in trap_pfault (frame=0xc3e6cfa8, usermode=1, eva=135077892) at
../../i386/i386/trap.c:839
#9 0xc0261ab3 in trap (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0,
tf_esi = 135055736, tf_ebp = -1077939980,
tf_isp = -1008283692, tf_ebx = 135077880, tf_edx = 15, tf_ecx = 135055786,
tf_eax = 0, tf_trapno = 12, tf_err = 6,
tf_eip = 134584827, tf_cs = 31, tf_eflags = 66118, tf_esp = -1077940020,
tf_ss = 47}) at ../../i386/i386/trap.c:369
#10 0x80599fb in ?? ()
#11 0x80599d5 in ?? ()
---
You should run ps in the kernel debugger, to determine what
program was active at the time, and then debug that program to
find out what source code was being referenced at 0x80599fb that
caused the trap in the first place.
The trap in this case is a page fault on a user space address,
which, during lookup, caused an attempt to call vm_obect_reference(),
which then caused an unexpected page fault.
Most likely this is a page dirty of a memory mapped object, for
which there is no remaining memory in the system to handle the
page being dirtied.
Again, your source code does not match 4.4, 4.6, or -current,
since the line number is way off in vm_object.c. You will need
to list the source
Re: PThreads problem
Linus Kendall wrote: That was very thorough, thanks! Now I at least have a notion of what is going on. Since this is slightly urgent I guess a hack into the libcurl source code to try to remove the sigalarms would do the trick (in my case). In the general case it seems like there's a rather big problem here as libcurl's behavior cannot really work together with the FreeBSD implementation of threads. It is more correct to say that libcurl makes an assumption about signal delivery which is not guaranteed by POSIX, and therefore libcurl will not work with *any* POSIX compliant threads implementation which does not *happen* to work this way. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
SMP and race conditions.
Hello hackers... We got for example a kld module and we have catched some syscall. Now we want to change effective uid of process, but not curproc. How to lock this process? struct proc *proc; uid_t olduid; [...] if ((proc = pfind(123)) == NULL) return (ESRCH); olduid = pc-pc_ucred-cr_uid; change_euid(proc, 0); /* now some simple action */ change_euid(proc, olduid); How to be sure that process 'proc' arn't running on other CPU? Function lockmgr() is used for problems like this one? Where I could find some more information about it? For now I've wrote only comments in /sys/sys/lock.h, etc. There are any papers about programming in SMP? -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. msg37494/pgp0.pgp Description: PGP signature
Re: malloc
On Mon, Oct 21, 2002 at 11:25:43AM +0200, Danny Braniss wrote: comments? That code is a REALLY inefficient use of malloc(). You can always write bizarre code that exaggerates the differences between different algorithms (e.g. Linux malloc vs FreeBSD malloc). Kris msg37495/pgp0.pgp Description: PGP signature
Re: Ati Rage 128: Dpms suspend failes
Eric Anholt writes: On Mon, 2002-10-21 at 08:16, Hanspeter Roth wrote: Hello, I have two hosts connected to one monitor. My idea is attach the display to the other host by issuing `xset dpms force suspend'. This works on one host with a Matrox Millenium. On the host with an Ati Rage 128 Pro TF it works with Netbsd, but it doesn't work with FreeBSD 4.7-Release. The screen only turns blank but the LED remains green. This is the same when issuing `xset s activate'. What could be the reason on FreeBSD 4.7 that dpms force suspend doesn't work? Installed are XFree86-Server-4.2.1_3 and XFree86-libraries-4.2.1_1.) You need XFree86-Server-4.2.1_4 or later (it's at _5 now). I'm running 4.2.1_4 and dpms does not work for me. I just grabbed some diffs from the Xfree86 cvs to bring drivers/ati/r128_driver.c up to 1.57.2.1 and drivers/ati/r128_reg.h up to 1.14 and rebuilt the my r128_drv.o module. I'll see if it works the next time X crashes.. (I'm running current, so X crashes once/day or so..) Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PThreads problem
On Mon, Oct 21, 2002 at 04:48:34PM +0300, Peter Pentchev wrote: On Mon, Oct 21, 2002 at 03:24:08PM +0200, Linus Kendall wrote: m?n 2002-10-21 klockan 14.45 skrev Peter Pentchev: On Mon, Oct 21, 2002 at 01:35:59PM +0200, Linus Kendall wrote: Hi, I'm trying to port a heavily threaded application from Linux (Debian 3.0, 2.4.19) to FreeBSD (4.6-RELEASE). The program compiles successfully using gcc with -pthreads. But, when I try to run the application I get the following error after a while (after spawning 11 threads): Fatal error 'siglongjmp()ing between thread contexts is undefined by POSIX 1003.1' at line ? in file /usr/src/lib/libc_r/uthread/uthread_jmp.c (errno = ?) Abort trap - core dumped It always crashes at the same point. Under Linux it works perfectly fine. I also tried to compile with linuxthreads only to get a segfault directly when the program tries to spawn the first thread. GCC version on Linux: 2.95.4 20011002 GCC version on FreeBSD: 2.95.3 20010315 GCC/G++ command-line: g++ -g -Wall -I. `curl-config --cflags` -fsjlj-exceptions -D_THREAD_SAFE -D_REENTRANT -pthread `curl-config --libs` Just for the record: what exactly do 'curl-config --cflags' and 'curl-config --libs' output? Libcurl is an HTTP-library which is said to be threadsafe (and also works normally under Linux). I know what libcurl is; as a matter of fact, I happen to be the maintainer of the ftp/curl port :) That's partly the reason why I am interested in your problem, especially given what you report below.. I was asking about the specific output of the compiler flags and the libraries that cURL reports as needed, to see if there were any conflicts there with any of the other compiler flags. I've been looking at it and it seems that the problem was based on the fact that libcurl triggers an SIGALARM which in Linux isn't a problem but for which I needed to define a signal handler (ie. block) in *BSD. This is interesting; can you produce a simple testcase? If not, I will be able to take a look at it some time later today or tomorrow, but not right now :( Oh BTW.. libcurl is indeed threadsafe, with a single exception, mentioned in the THREADS section of the libcurl(3) manual page.. is there any chance that this is related to the problem you are having? G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If this sentence were in Chinese, it would say something else. msg37497/pgp0.pgp Description: PGP signature
Re: vmware3, any one got even sorta working?
what the requirements for the people to do the work? Josef Karthauser wrote: On Fri, Oct 18, 2002 at 09:41:58PM -0400, wolf wrote: I have search the web trying to find info on vmware3 and FreeBSD as the host os. I noticed a post where someone said they got the modules working, but were having problems with the binary part. Any progress? Looking for beta testers? No, looking for people to do the work. I've had several people interested in working on it, but they've gone quiet as soon as I've given them the resources to do it! Go figure. Joe -- Michael Joyner FreeBSD System Administrator http://manhattan.hq.dyns.cx/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Kernel Panic Problems
Hi Guys, I have been experiencing several kernel panics from differents situations, since a ls to just boot the kernel. I configured all the options in rc.conf to save the core dump from memory to HD and some of the results are here in the file panics. Above all I search at internet some information to try to explain this recursive panics and found that it could be some memory problem. Is there a way to make a hard test with memory? I'm uncertainty if it is the memory because the PC stayed turned on for 6 days without any problem! Any comments will be welcome! Thanks in Advance, Diego panics Description: application/java-applet
Re: vmware2 and simd instructions
From what I have gathered doing web seaches, the cpuid opcode is *not* trappable. :( What's the problem then? The guest OS should get proper info from the CPUID instruction. Can you test that? What does CPU info program show about the CPU in a guest OS? The problem is in VMWare - it has some weird reaction to P6 instructions. Oct 16 23:44:47: F(140) line=1893 0x10:0xc02660bc fault=13 can you disassemble 0xc02660bc? Seems like there should be a way to trap the fault 13 to not have the guest os panic or blue screen. don't think so Programs with P6 instructions won't start working from this anyway... 21.10.2002; 22:07:56 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Scheduling a recurring task in a device driver
In message: [EMAIL PROTECTED] Luigi Rizzo [EMAIL PROTECTED] writes: : On Mon, Oct 21, 2002 at 09:20:52AM -0700, David Christensen wrote: : A device driver I'm porting from Linux uses tasklets to schedule a : recurring : event to work around a hardware bug. What would be the equivalent in : FreeBSD? : : a timeout() call will do (at most once per tick). grep for timeout( : in most of device drivers to see how to use it. Also, A software interrupt would be good too, depending on the nature of the recurring event. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PThreads problem
On Mon, Oct 21, 2002 at 10:31:48PM +0200, Linus Kendall wrote: [snip] That was very thorough, thanks! Now I at least have a notion of what is going on. Since this is slightly urgent I guess a hack into the libcurl source code to try to remove the sigalarms would do the trick (in my case). In the general case it seems like there's a rather big problem here as libcurl's behavior cannot really work together with the FreeBSD implementation of threads. I wonder, though.. If libcurl depends on Linux-specific threads library behavior, what would the effects be if it were to be compiled against the devel/linuxthreads port? Maybe I will try building curl with linuxthreads later today.. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false. msg37502/pgp0.pgp Description: PGP signature
Re: IP resolving
You never said if you are using TCP wrappers. Can you show us the actual output from the machine? What do, Yes, I guess I am now, but the problem existed before as well. The TCP wrapper is just whatever is enabled by configuring /etc/hosts.allow. In the following, 'andrew' is the account that shows he's logged in from samwise, which is actually my box, and he's a few hundred miles away from an IP that netstat will show later on. $ w 11:35PM up 7 days, 17 mins, 3 users, load averages: 1.02, 1.02, 1.01 USER TTY FROM LOGIN@ IDLE WHAT andrew p1 samwise 8:24PM 3:11 -tcsh (tcsh) jobe p2 moria11:31PM - pine -zi $ w -n 11:36PM up 7 days, 18 mins, 3 users, load averages: 1.01, 1.02, 1.00 USER TTY FROM LOGIN@ IDLE WHAT andrew p1 205.206.125.238 8:24PM 3:12 -tcsh (tcsh) jobe p2 205.206.125.235 11:31PM - pine -zi (here, it's displaying MY ip as well) $ who 23:36 (1603) jobe@samwise:[~] who andrew ttyp1Oct 21 20:24 (205.206.125.238) jobe ttyp2Oct 21 23:31 (moria) $ last | head 23:36 (1604) jobe@samwise:[~] last | head jobe ttyp2 moriaMon Oct 21 23:31 still logged in [deletia] andrew ttyp1 205.206.125.238 Mon Oct 21 20:24 still logged in $ netstat -an Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address(state) tcp4 0 0 205.206.125.238.139148.240.10.206.3568TIME_WAIT tcp4 0 20 205.206.125.238.22 205.206.125.235.3919 ESTABLISHED tcp4 0 0 205.206.125.238.22 205.206.125.235.3916 ESTABLISHED tcp4 0 0 205.206.125.238.139205.206.125.235.3201 ESTABLISHED tcp4 0 0 205.206.125.238.22 24.157.160.165.60145 ESTABLISHED tcp4 0 0 205.206.125.238.139205.206.125.236.37858 ESTABLISHED tcp6 0 0 ::1.953*.*LISTEN tcp4 0 0 127.0.0.1.953 *.*LISTEN tcp4 0 0 127.0.0.1.53 *.*LISTEN tcp4 0 0 205.206.125.238.53 *.*LISTEN udp4 0 0 127.0.0.1.3724 *.* udp4 0 0 127.0.0.1.3397 *.* udp4 0 0 205.206.125.238.138*.* udp4 0 0 205.206.125.238.137*.* udp4 0 0 127.0.0.1.53 *.* udp4 0 0 205.206.125.238.53 *.* Active UNIX domain sockets Address Type Recv-Q Send-QInode Conn Refs Nextref Addr d4029aa0 stream 0 0 d4567740000 /tmp/screens/S-root/25091.ttyp1.samwise d4029be0 stream 0 0 d410f200000 /tmp/mysql.sock d4029a00 dgram 0 00 d4029f000 d4029d20 d4029d20 dgram 0 00 d4029f000 d4029dc0 d4029dc0 dgram 0 00 d4029f000 d4029e60 d4029e60 dgram 0 00 d4029f0000 d4029f00 dgram 0 0 d40245000 d4029a000 /var/run/log NOTE: here his IP shows properly: 24.157.160.165 Show? Do you get identical results with rlogin and ssh? Can we see both? rlogin is completely identical, though I can't contact the guy to try it out... but I've seen it in the past as the same results. Thanks, Scott On Fri, 18 Oct 2002, Crist J. Clark wrote: On Sun, Oct 13, 2002 at 11:00:26PM -0600, Scott Carmichael wrote: Can someone help me here? Is there a code change I can make somewhere? Please CC me on any replies, as I am not subscribed to -net or -hackers. -net removed. -hackers left (although this might be more of a -questions thread). -- Forwarded message -- Date: Fri, 11 Oct 2002 14:14:08 -0600 (MDT) From: Scott Carmichael [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: IP resolving I would like to know two things... Why FreeBSD acts in the following way while OpenBSD does not, and if it's possible to fix this? It seems that if anyone connects to my FreeBSD server wish a hostname that does not match their IP, Hostname does not match their IP? What exactly does that mean? All the OS knows is the remote IP address. It doesn't know what hostname the remote claims to have. The application server might receive a hostname though, but then I would expect the behavior to vary according to the application used to connect. I get a console message about the mismatch, and Something is generating a message to syslogd(8). Figure out what it is and edit syslog.conf(5) appropriately. Are you using TCP wrappers or something? then if they connect via rlogin or ssh, 'who', 'w', 'last', etc. all report that they are connected _from_ MY box, which they aren't.
