USB detach crashes possibly fixed
Please try this change (already committed to -CURRENT) and let me know if crashes due to detaching USB devices specifically have been eliminated. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/usb.c.diff?r1=1.54r2=1.55f=h -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Newbie ddb question
I've been poking around in ddb in an attempt to work on some forkbomb/low memory problems, and I've found it extremely useful. There's one thing I can't figure out how to do that would be useful, though. Say that I have a process of interest tsleeping. Is there some way for me to get a backtrace of that process at the time it entered tsleep? In the case I'm creating, many processes are tsleeping on vmwait. As there are multiple places where such a wait can occur, I'd really like to see which codepaths are causing processes to enter that state. The trace command doesn't seem to have the necessary functionality to do this, so I was thinking that I might be able to simulate such an effect by putting a null pointer reference right before such calls, thereby creating a panic. Is this the best way to go, or is there some easier way to accomplish a similar effect? Thanks, Mike Silby' Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rdr 127.0.0.1 and blocking 127/8 in ip_output()
On Wed, Feb 13, 2002 at 03:57:33PM -0800, Terry Lambert wrote: Ruslan Ermilov wrote: On Wed, Feb 13, 2002 at 10:50:13AM -0500, Garrett Wollman wrote: On Wed, 13 Feb 2002 11:03:47 +0200, Ruslan Ermilov [EMAIL PROTECTED] said: Please test with and without this patch. I continue to believe that this should be done by fixing the routing, not by adding additional hacks to the already-bloated ip_output() path. BSD always had these hacks (rfc1122 requirements) in in_canforward(). RFC1122 requires the host to not send 127/8 addresses out of loopback, whether or not its routes are set up correctly. I pretty much agree with Garrett on this one. Loopback is a special critter; it has all sorts of requirements, like not ARP'ing for addresses configured on it (otherwise FreeBSD is not usable for DSR, which I think it currently is not), etc.. Heh? Without my patch: # ifconfig rl0 inet rl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.4.115 netmask 0xff00 broadcast 192.168.4.255 inet 127.0.0.2 netmask 0xff00 broadcast 127.255.255.255 # ping 127.0.0.3 # tcpdump -n net 127 tcpdump: listening on rl0 10:29:12.685957 arp who-has 127.0.0.3 tell 127.0.0.2 ^C 2480 packets received by filter 0 packets dropped by kernel It looks to me that this should be handled some place other than ip_output(). Perhaps you don't realize that we can't fix this with just routing because we are also not allowed to send out packets originated from loopback network, like: ping -s 127.1 1.2.3.4 telnet -S 127.1 1.2.3.4 Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Newbie ddb question
On Thu, 14 Feb 2002, Mike Silbersack wrote: I've been poking around in ddb in an attempt to work on some forkbomb/low memory problems, and I've found it extremely useful. There's one thing I can't figure out how to do that would be useful, though. Say that I have a process of interest tsleeping. Is there some way for me to get a backtrace of that process at the time it entered tsleep? In the case I'm Try t pid. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rdr 127.0.0.1 and blocking 127/8 in ip_output()
On Thu, 14 Feb 2002 11:09:41 +0200, Ruslan Ermilov [EMAIL PROTECTED] said: ping -s 127.1 1.2.3.4 telnet -S 127.1 1.2.3.4 If someone explicitly overrides source-address selection, they are presumed to know WTF they are doing, and the kernel should not be trying to second-guess them. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rdr 127.0.0.1 and blocking 127/8 in ip_output()
[Redirected to -net] On Thu, Feb 14, 2002 at 11:39:37AM -0500, Garrett Wollman wrote: On Thu, 14 Feb 2002 11:09:41 +0200, Ruslan Ermilov [EMAIL PROTECTED] said: ping -s 127.1 1.2.3.4 telnet -S 127.1 1.2.3.4 If someone explicitly overrides source-address selection, they are presumed to know WTF they are doing, and the kernel should not be trying to second-guess them. That someone could be a bad guy playing dirty games with your box and certainly knowing what he's doing. :-) So far, noone gave me a real example where using of net 127 outside loopback would be useful. If there such an example exists, we should wrap all three checks into a sysctl, including ip_input(), ip_output(), and in_canforward() parts, where ip_input() exists for almost a year, and in_canforward() existed since 1987. -- Ruslan, who just wants a consistency here. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Newbie ddb question
On Thu, 14 Feb 2002, Bruce Evans wrote: On Thu, 14 Feb 2002, Mike Silbersack wrote: I've been poking around in ddb in an attempt to work on some forkbomb/low memory problems, and I've found it extremely useful. There's one thing I can't figure out how to do that would be useful, though. Say that I have a process of interest tsleeping. Is there some way for me to get a backtrace of that process at the time it entered tsleep? In the case I'm Try t pid. Bruce Ah, I see now. That never got MFC'd to -stable. I'll see if it's easily MFCable, or just move my testing over to -current. Thanks, Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Workaround: Re: ports/34908: libpng port makes bad dynamic libraryon -CURRENT
On Wed, 13 Feb 2002, Terry Lambert wrote: David O'Brien wrote: On Wed, Feb 13, 2002 at 06:14:42PM +0300, Vladimir B. Grebenschikov wrote: building programm with -g gives no more information at all, I have tried Linking aginst static library - works. This suggests a problem with the runtime-linker (rtld), not binutils. Works with the old binutils on 4.5, though... that suggests that it's *not* a problem with the rtld, rather a problem with what has changed. Not sure if this has anything to do with thread safety (rather with as) but least with an additional -DPNG_THREAD_UNSAFE_OK flag everything seems to be OK (-CURRENT, with new binutils). Regards, Vladimir -- Vladimir Kushnir - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ports/34908: libpng port makes bad dynamic library on -CURRENT
This suggests a problem with the runtime-linker (rtld), not binutils. Actually, the bug is somewhere in the new binutils code, and I am very close to finding where it is exactly. The new liker fails to set DT_TEXTREL property in the shared library header even though its relocation table contains several entries which refer to the code segment. As a result, ld-elf.so.1 fails to enable writes on the text segment when relocating the binary and crashes with SIGBUS while processing the very first relocation record. I still need some time in debugger to find a proper way to fix this. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ports/34908: libpng port makes bad dynamic library on -CURRENT
Alexander N. Kabaev wrote: This suggests a problem with the runtime-linker (rtld), not binutils. Actually, the bug is somewhere in the new binutils code, and I am very close to finding where it is exactly. The new liker fails to set DT_TEXTREL property in the shared library header even though its relocation table contains several entries which refer to the code segment. As a result, ld-elf.so.1 fails to enable writes on the text segment when relocating the binary and crashes with SIGBUS while processing the very first relocation record. Woohoo! He shoots, he scores! I still need some time in debugger to find a proper way to fix this. My binutils-foo is rusty. Personally, I just reverted to the old binutils and called it a day. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ports/34908: libpng port makes bad dynamic library on -CURRENT
On Thu, Feb 14, 2002 at 07:22:59PM -0500, Alexander N. Kabaev wrote:
This suggests a problem with the runtime-linker (rtld), not binutils.
Actually, the bug is somewhere in the new binutils code, and I am very
close to finding where it is exactly. The new liker fails to set
DT_TEXTREL property in the shared library header even though its relocation
table contains several entries which refer to the code segment. As a result,
ld-elf.so.1 fails to enable writes on the text segment when relocating the
binary and crashes with SIGBUS while processing the very first relocation
record.
I still need some time in debugger to find a proper way to fix this.
Interesting. Is the DF_TEXTREL flag set in DT_FLAGS instead? Is the
library linked w/ -enable-new-dtags? Are the new dtags enabled by
default in the new binutils? Someting in elf32.em?
Currently I'm experimenting with some code that enhances the FreeBSD
runtime linker to handle some newer ELF features, such as DT_RUNPATH,
DT_FLAGS and ${ORIGIN} substitution sequences
-Björn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Current/XFree86 w/gnome or kde coredumps.
I just realized that current/XFree86-4.1.0_12,1 core dumps with either kde or gnome. I seems to work fine with twm. It dumps at the same place when starting x with both. (II) XINPUT: Adding extended input device Mouse1 (type: MOUSE) Could not init font path element /usr/X11R6/lib/X11/fonts/Speedo/, removing from list! Bus error - core dumped Any suggestions would be appreciated. I haven't rebooted for several days so I don't know when it started. thanks, ed --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB detach crashes possibly fixed
I CVSuped kernel src tree to recompile, and uhub detach problem I've reported seems to be solved. With new kernel, I confirmed I could safely attach/detach all USB devices I have. Brian Fundakowski Feldman wrote: Please try this change (already committed to -CURRENT) and let me know if crashes due to detaching USB devices specifically have been eliminated. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/usb.c.diff?r1=1.54r2=1.55f=h -- FUJIMOTO Kou, Dept. of Information Sciences, Tokyo Denki Univ. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: function name collision on getcontext with ports/editors/joe
On Mon, 11 Feb 2002, Bruce Evans wrote: On Sun, 10 Feb 2002, Daniel Eischen wrote: What do you recommend we do? Should we not include sys/ucontext.h from sys/signal.h, or do what Solaris does, or just leave everything as is? Don't include sys/ucontext.h from sys/signal.h, and fix whatever breaks. I think applications that use the new sigreturn can be required to include both signal.h and ucontext.h. There should be fewer of them than there used to be -- they can now use setcontext(). The old sigcontext/sigreturn stuff should be cleaned up too (don't export it to userland). Finally getting buildworld to work again... More problems in the kernel though. ucontext_t is used as a parameter to sigreturn (and getsetcontext soon), so it is referenced in sys/sysproto.h. Lots of stuff includes sys/sysproto.h. Do we, a) Include sys/ucontext.h conditionally from sys/signal.h based on _KERNEL, or b) Change makesyscalls.sh to emit #include\tsys/ucontext.h when generating sysproto.h, or, c) Add includes for sys/ucontext.h to all files that include sys/sysproto.h -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: function name collision on getcontext with ports/editors/joe
On Fri, 15 Feb 2002, Daniel Eischen wrote: Finally getting buildworld to work again... More problems in the kernel though. ucontext_t is used as a parameter to sigreturn (and getsetcontext soon), so it is referenced in sys/sysproto.h. Lots of stuff includes sys/sysproto.h. Do we, a) Include sys/ucontext.h conditionally from sys/signal.h based on _KERNEL, or b) Change makesyscalls.sh to emit #include\tsys/ucontext.h when generating sysproto.h, or, c) Add includes for sys/ucontext.h to all files that include sys/sysproto.h None of the above) Change syscalls.master in the same way as signal.h to use struct __ucontext * instead of ucontext_t *, and maybe forward-declare struct __ucontext in sys/signal.h so that sysproto.h can see it (sysproto.h really shouldn't include sys/signal.h, but it doesn, and I think the forward declaration isn't be automatically generated [yet?]). If you change the sigreturn line in syscalls.master, please fix the name of the parameter there and in the functions (it is still sigcntxp, but should have been scp and should now be ucp). Also try adding `const'. Almost all of the pointers to input parameters in syscalls.master are missing `const' and adding them tends to require const poisoning all over the kernel, but `const' should be used for at least syscalls newer than C90. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
