Re: /bin/sh dumps core with here-document of 8bit text
#!/bin/sh cat EOF [8bit text which contains 0x82 character] EOF And, if I use 'EOF' instead of EOF, it works fine. Do you have any idea about this behavior? And I want to quote that we Japanese often meet 0x82 because it is contained in Shift_JIS encoding. :-( h.h. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/sh dumps core with here-document of 8bit text
On Fri, 28 Jul 2000 12:09:51 +0900
Jun Kuriyama [EMAIL PROTECTED] said:
kuriyama Shell script which contains here-document of 8bit text sometimes dumps
kuriyama core. For example, please test this script in 4.1 or -current.
I'm using this for workaround on IMASY's main server. 3.5-RELEASE or
later have this problem.
--- bin/sh/parser.c.origMon Mar 20 19:51:04 2000
+++ bin/sh/parser.c Fri Jun 30 17:15:38 2000
@@ -909,9 +909,11 @@
for (;;) { /* until end of line or end of word */
CHECKSTRSPACE(3, out); /* permit 3 calls to USTPUTC */
+#if 0
if (c 0 c != PEOF)
synentry = CWORD;
else
+#endif
synentry = syntax[c];
switch(synentry) {
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /bin/sh dumps core with here-document of 8bit text
In [EMAIL PROTECTED], Jun Kuriyama wrote: #!/bin/sh cat EOF [8bit text which contains 0x82 character] EOF I'm very short of time these days, but here are thoughts and a backtrace: 0x82 == \202 == CTLVAR in the parser. For real variable expansion, the parser inserts \202 into the input string. Furthermore, it is an error that the forking shell doesn't detect that its forked counterpart dumped core. I see two solutions: 1) It seems that you can work around the coredump by looking at the next char after \202. For real expansions of variables in here-documents that is \201. Once can probably determine all possible legal combinations and ignore others. However, that would just prevent this coredump and would not support processing the CTL* chars as literal chars in here-documents, at the very least they will be eaten. 2) move the CTL* stuff from expand.h to values outside the char domain. Do do this, all input strings must be converted from char* to int* in the first steps of the parser, all buffers must hold int*, which means that they cannot be displayed to the terminal or presented as input to external programs without converting them back. Of course, I will do the latter :-) However, I'm in the middle of preparation for a job interview, so that is not possible right now. Anyone trying to fix this, especially going the first path, keep in mind that you must not break variable expansion in here-documents: foo=42 cat EOF echo $foo EOF (gdb) bt #0 evalvar (p=0x80b998c "\na;sldk\n", flag=0) at expand.c:783 #1 0x804ce8e in argstr (p=0x80b9980 "jhsdd903kd\n\202\na;sldk\n", flag=0) at expand.c:245 #2 0x804cc26 in expandarg (arg=0x80b9998, arglist=0x0, flag=0) at expand.c:169 #3 0x804cbbb in expandhere (arg=0x80b9998, fd=3) at expand.c:144 #4 0x8056d22 in openhere (redir=0x80b994c) at redir.c:269 #5 0x8056bd5 in openredirect (redir=0x80b994c, memory=0xbfbff1f8 "") at redir.c:226 #6 0x8056a59 in redirect (redir=0x80b994c, flags=0) at redir.c:157 #7 0x804b9ae in evalcommand (cmd=0x80b9970, flags=1, backcmd=0x0) at eval.c:888 #8 0x804a920 in evaltree (n=0x80b9970, flags=0) at eval.c:269 #9 0x8051a47 in cmdloop (top=1) at main.c:253 #10 0x80519b5 in main (argc=2, argv=0xbfbff3f8) at main.c:202 #11 0x8048135 in _start () -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
Kazutaka YOKOTA wrote: Try the attached patch for /sys/isa/psm.c, and please report the result. Actually, I use the mse0 device, because I have an isa bus mouse. -- - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/sh dumps core with here-document of 8bit text
In [EMAIL PROTECTED], Hajimu UMEMOTO wrote:
On Fri, 28 Jul 2000 12:09:51 +0900
Jun Kuriyama [EMAIL PROTECTED] said:
kuriyama Shell script which contains here-document of 8bit text sometimes dumps
kuriyama core. For example, please test this script in 4.1 or -current.
I'm using this for workaround on IMASY's main server. 3.5-RELEASE or
later have this problem.
--- bin/sh/parser.c.orig Mon Mar 20 19:51:04 2000
+++ bin/sh/parser.c Fri Jun 30 17:15:38 2000
@@ -909,9 +909,11 @@
for (;;) { /* until end of line or end of word */
CHECKSTRSPACE(3, out); /* permit 3 calls to USTPUTC */
+#if 0
if (c 0 c != PEOF)
synentry = CWORD;
else
+#endif
synentry = syntax[c];
switch(synentry) {
Hm, looks like I broke that in my 8-bit fixes. This code is native in
that it passed control chars further down in the hope noone will
execute them anymore, just taking them for real chars. Nice try.
The problem is also not limited to here-documents:
echo \202 # A real \202
will also dump core.
Since literal strings cannot be made 8-bit clean without further
cleanup, I think we should make this official, although in the
following form, otherwise wrong characters are echoed.
Anyone for whom this fix doesn't work?
Martin
--
%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
BSD User Group Hamburg, Germany http://www.bsdhh.org/
? test2
? test1
? l
? Makefile.cra
? builtins.c
? builtins.h
? mknodes
? nodes.h
? nodes.c
? mksyntax
? syntax.c
? syntax.h
? token.h
? y.tab.h
? y.tab.c
? arith.c
? arith_lex.c
? sh
? l4
? mkinit
? init.c
? sh.1.gz
? .depend
? l3
? l2
? foo
? l5
Index: parser.c
===
RCS file: /home/CVS-FreeBSD/src/bin/sh/parser.c,v
retrieving revision 1.31
diff -c -r1.31 parser.c
*** parser.c2000/05/15 13:02:07 1.31
--- parser.c2000/07/28 07:46:22
***
*** 909,918
for (;;) { /* until end of line or end of word */
CHECKSTRSPACE(3, out); /* permit 3 calls to USTPUTC */
! if (c 0 c != PEOF)
synentry = CWORD;
! else
! synentry = syntax[c];
switch(synentry) {
case CNL: /* '\n' */
--- 909,923
for (;;) { /* until end of line or end of word */
CHECKSTRSPACE(3, out); /* permit 3 calls to USTPUTC */
! if (c = CTLESC c = CTLQUOTEMARK) {
synentry = CWORD;
! fprintf(stderr,
! "Warning: internal control character in "
! "literal text, using '?' instead\n");
! c = '?';
! }
!
! synentry = syntax[c];
switch(synentry) {
case CNL: /* '\n' */
Another minor mouse problem w/XFree86-4
I suppose there are several places that this difficulty may be located. I have a Logitech Trackball. I have tried it on the serial port and the PS/2 port and have the same problem in both places: 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Jul 27 06:00:20 EDT 2000 XFree86-3.3.6 and TkDesk-1.2 I right click on a directory or file in TkDesk, and a popup menu appears and *stays up* (thank goodness). Change to XFree86-4, and I need to hold the button down to keep the menu. Man I hate that. Any ideas. I'm RTFM moused and psm, but I don't see any obviously related adjustments. Oh. This is with moused_enable="YES" # Run the mouse daemon. moused_type="ps/2" # See man page for rc.conf(5) for available settings. moused_port="/dev/psm0" # Set to your mouse port. in rc.conf (for the ps/2 attempt obvously), and Identifier "Mouse1" Driver "mouse" Option "Protocol""auto" Option "Device" "/dev/sysmouse" in XF86Config. Thanks. Greg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
Kazutaka YOKOTA wrote: Try the attached patch for /sys/isa/psm.c, and please report the result. Actually, I use the mse0 device, because I have an isa bus mouse. -- - Donn Robert, I still want you to try my patch, as you are using the PS/2 mouse. Donn, would you please run moused at higher priority, (for example, "nice -5 moused..." or "nice -10 moused...",) in order to see if this is caused by moused somewhat not running in a timely manner. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another minor mouse problem w/XFree86-4
I have a Logitech Trackball. I have tried it on the serial port and the PS/2 port and have the same problem in both places: 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Jul 27 06:00:20 EDT 2000 XFree86-3.3.6 and TkDesk-1.2 I right click on a directory or file in TkDesk, and a popup menu appears and *stays up* (thank goodness). Change to XFree86-4, and I need to hold the button down to keep the menu. Man I hate that. Which is supposed to be the correct behavior of TkDesk? The popup menu should stay up as in XFree86 3.3.6? I have no experience on TkDesk. Any ideas. I'm RTFM moused and psm, but I don't see any obviously related adjustments. Run `xev' and click the button in the xev window and see what messages are generated. If you still have XFree86 3.3.6 around. Do the same and compare the results in two versions of XFree86. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UPS: loader.conf's null_load renamed
I've just renamed the nullfs kernel module from null to nullfs. The only impact that this may have on some people is as follows: If you have null_load="YES" in your /boot/loader.conf, you will need to change that to nullfs_load="YES". Apologies for the inconvenience to the folks who use the nullfs code in spite of the dire warnings in NOTES. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
Donn, would you please run moused at higher priority, (for example, "nice -5 moused..." or "nice -10 moused...",) in order to see if this Oh, I meant "nice --5 mouse..." and "nice --10 moused..." :-) Kazu is caused by moused somewhat not running in a timely manner. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic: lockmgr: pid 5, not exclusive lock holder 0 unlocking
On Wed, 26 Jul 2000 16:43:04 MST, Kirk McKusick wrote:
I have had a number of complaints of this sort which seem to be
somehow related to recursive buffer locks. Since the recursive
locks are only needed to prevent deadlock when mounting snapshots
I decided to back out the use of recursive locks for now. When I
have had a chance to investigate why they are causing problems,
I will try reenabling them. Let me know if this problem persists
once you have upgraded to version 1.107 of buf.h.
Just a quick note to let you two gentlement know that the problem
persists with rev 1.107 of buf.h.
Brian, these are realy easy for me to reproduce on my own box here. Do
you want to send me the stuff for maintaining the queues that you said
would help you figure out what's going on? Or are you able to reproduce
this yourself?
Ciao,
Sheldon.
Script started on Fri Jul 28 14:25:46 2000
[root@axl] ~AXL # gdb -k -c /var/crash/vmcore.3 kernel.debug
GNU gdb 4.18
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"...
IdlePTD 2826240
initial pcb at 244080
panicstr: lockmgr: pid 1, not exclusive lock holder 0 unlocking
panic messages:
---
---
#0 boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:303
303 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:303
#1 0xc01462c1 in panic (fmt=0xc02044a0 "lockmgr: pid %d, not %s %d unlocking")
at /usr/src/sys/kern/kern_shutdown.c:553
#2 0xc0140fdc in lockmgr (lkp=0xc0da4400, flags=6, interlkp=0xc8f08dec,
p=0xc84bfe00) at /usr/src/sys/kern/kern_lock.c:382
#3 0xc01747b3 in vop_stdunlock (ap=0xc84c5e48)
at /usr/src/sys/kern/vfs_default.c:255
#4 0xc01b4285 in ufs_vnoperate (ap=0xc84c5e48)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2285
#5 0xc01af163 in ufs_inactive (ap=0xc84c5e78) at vnode_if.h:865
#6 0xc01b4285 in ufs_vnoperate (ap=0xc84c5e78)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2285
#7 0xc017752e in vput (vp=0xc8f08d80) at vnode_if.h:794
#8 0xc01ac43f in ffs_sync (mp=0xc0c35a00, waitfor=2, cred=0xc0721780,
p=0xc02569e0) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:955
#9 0xc01794b1 in sync (p=0xc02569e0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:551
#10 0xc0145cf7 in boot (howto=0) at /usr/src/sys/kern/kern_shutdown.c:225
#11 0xc0145af8 in reboot (p=0xc84bfe00, uap=0xc84c5f80)
at /usr/src/sys/kern/kern_shutdown.c:146
#12 0xc01eb239 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077936612, tf_esi = -1077936624, tf_ebp = -1077936836,
tf_isp = -934518828, tf_ebx = -1077936732, tf_edx = -1, tf_ecx = 4,
---Type return to continue, or q return to quit---
tf_eax = 55, tf_trapno = 7, tf_err = 2, tf_eip = 134536452, tf_cs = 31,
tf_eflags = 643, tf_esp = -1077937056, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1128
#13 0xc01dff45 in Xint0x80_syscall ()
#14 0x80486ee in ?? ()
#15 0x8048478 in ?? ()
#16 0x8048139 in ?? ()
(kgdb) quit
[root@axl] ~AXL # exit
Script done on Fri Jul 28 14:26:19 2000
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
new libstdc++ works?
It seems new libstdc++ called libstdc++-v3 (http://gcc.gnu.org/) was released around this April. I tried to install it on FreeBSD to get better STL support, but it failed for me. Is there any plan to support it, or does someone succeed to port to FreeBSD? Any information is appreciated. -- Yasuhiko WATANABE Matsushita Research Institute Tokyo, Inc. Mobile Communication Research Laboratory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/sh dumps core with here-document of 8bit text
On Fri, Jul 28, 2000 at 09:47:08AM +0200, Martin Cracauer wrote:
! if (c = CTLESC c = CTLQUOTEMARK) {
synentry = CWORD;
! fprintf(stderr,
! "Warning: internal control character in "
! "literal text, using '?' instead\n");
! c = '?';
! }
I disagree. It is not the fix, just admitting the bug. Better try to fix it via
some escaping of control characters via some prefix char. Bash is 8bit clean
in that place, f.e.
--
Andrey A. Chernov
[EMAIL PROTECTED]
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /bin/sh dumps core with here-document of 8bit text
In [EMAIL PROTECTED], Andrey A. Chernov wrote:
On Fri, Jul 28, 2000 at 09:47:08AM +0200, Martin Cracauer wrote:
! if (c = CTLESC c = CTLQUOTEMARK) {
synentry = CWORD;
! fprintf(stderr,
! "Warning: internal control character in "
! "literal text, using '?' instead\n");
! c = '?';
! }
I disagree. It is not the fix, just admitting the bug. Better try to fix it via
some escaping of control characters via some prefix char. Bash is 8bit clean
in that place, f.e.
Please refer to my previous mail. I think it's better to extend the
internal character handling to int* instead of obfuscating it even
more with escape sequences (remember that they are processed multiple
times and such things as taking the length of something, see related
PR fix recently).
Until that is done, we should commit this diff, because it *fixes* the
breakage of coredumping and eating all input (not only th offending
chars), even when it does not solve the problem of not being 8-bit
clean.
Martin
--
%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
BSD User Group Hamburg, Germany http://www.bsdhh.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /bin/sh dumps core with here-document of 8bit text
On Fri, Jul 28, 2000 at 09:03:49AM +0200, Martin Cracauer wrote: 1) It seems that you can work around the coredump by looking at the next char after \202. For real expansions of variables in here-documents that is \201. Once can probably determine all possible legal combinations and ignore others. However, that The problem is that all combinations are legal, there can be binary data passed. It means that all control chars must be double-escaped first just after data reading. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/sh dumps core with here-document of 8bit text
On Fri, Jul 28, 2000 at 03:20:19PM +0200, Martin Cracauer wrote: Please refer to my previous mail. I think it's better to extend the internal character handling to int* instead of obfuscating it even more with escape sequences (remember that they are processed multiple times and such things as taking the length of something, see related PR fix recently). Yes, but it is really big change. Until that is done, we should commit this diff, because it *fixes* the breakage of coredumping and eating all input (not only th offending chars), even when it does not solve the problem of not being 8-bit clean. What about trying double-escape first instead? I.e. escape internal control chars just after reading them from input stream? It is less painful then converting to 16bit. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
Kazutaka YOKOTA wrote: Donn, would you please run moused at higher priority, (for example, "nice -5 moused..." or "nice -10 moused...",) in order to see if this Oh, I meant "nice --5 mouse..." and "nice --10 moused..." :-) Tried this. It doesn't fix the problem. The mouse is still jumpy no matter what the nice level. I believe it's a problem with syscons as a whole. For example, whenever I switch to a VC and do kbdcontrol -r 240.34 to get a very fast keyboard repeat rate, the rate at which the characters repeat is very jumpy as well, much like the mouse. It was never like this before. So, I don't think the problem is specific to the syscons mouse drivers, just syscons itself. This started happening after some commits to syscons a couple of weeks back. -- - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UPS: loader.conf's null_load renamed
That's groovy, Sheldon.. could you maybe fix nullfs while you're at it, too? :-) On Fri, 28 Jul 2000, Sheldon Hearn wrote: I've just renamed the nullfs kernel module from null to nullfs. The only impact that this may have on some people is as follows: If you have null_load="YES" in your /boot/loader.conf, you will need to change that to nullfs_load="YES". Apologies for the inconvenience to the folks who use the nullfs code in spite of the dire warnings in NOTES. Ciao, Sheldon. 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: HEADS UPS: loader.conf's null_load renamed
Tsk. Coward. I ran for at least a week mounting /usr/src/sys/compile on top an NFS mounted /usr/src/sys before I panic'd (and read the NOTES file) Tsk. It's too bad. This works in NetBSD :-) On Fri, 28 Jul 2000, Sheldon Hearn wrote: On Fri, 28 Jul 2000 06:44:17 MST, Matthew Jacob wrote: That's groovy, Sheldon.. could you maybe fix nullfs while you're at it, too? :-) I doubt it. I'm not brave enough to go past getting a file listing within a null mount. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
Oh, I meant "nice --5 mouse..." and "nice --10 moused..." :-) Tried this. It doesn't fix the problem. The mouse is still jumpy no matter what the nice level. I believe it's a problem with syscons as a whole. For example, whenever I switch to a VC and do kbdcontrol -r 240.34 to get a very fast keyboard repeat rate, the rate at which the characters repeat is very jumpy as well, much like the mouse. It was never like this before. So, I don't think the problem is specific to the syscons mouse drivers, just syscons itself. This started happening after some commits to syscons a couple of weeks back. I find quite hard to believe this was caused by recent syscons changes. Because these changes are about /dev/random thingie and color attribute handling in terminal emulator part of syscons. They have nothing to do with keyboard and mouse input. I am suspecting there may be something in tty interrupt handling in general in the kernel... Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
Kazutaka YOKOTA wrote: I find quite hard to believe this was caused by recent syscons changes. Because these changes are about /dev/random thingie and color attribute handling in terminal emulator part of syscons. They have nothing to do with keyboard and mouse input. I am suspecting there may be something in tty interrupt handling in general in the kernel... This sounds right. When I use X without /dev/sysmouse and moused, mouse motion is still pretty smooth. It's only when I use X with moused AND /dev/sysmouse that I see the jumpy mouse syndrome. This would be due to the fact that (AFAIK) moused relies on tty interrupt handling more so than the raw mouse driver without moused (/dev/mse0). -- - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
On 28 Jul, Donn Miller wrote: I am suspecting there may be something in tty interrupt handling in general in the kernel... This sounds right. When I use X without /dev/sysmouse and moused, mouse motion is still pretty smooth. It's only when I use X with moused AND /dev/sysmouse that I see the jumpy mouse syndrome. This would be due to the fact that (AFAIK) moused relies on tty interrupt handling more so than the raw mouse driver without moused (/dev/mse0). Just to give a datapoint: I'm using X 3.3.6 with "moused -p /dev/psm0" and /dev/sysmouse and I *didn't* see the jumpy mouse syndrome. I'm running a kernel from today (COPTFLAGS+=-Wall). Bye, Alexander. -- It is easier to fix Unix than to live with NT. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
3dfx driver
For those who have opted to test my 3dfx driver, I have debugging messages layered in the section that is causing problems. Define the DEBUG option in your kernel, you may have to add makeoptions -DDEBUG -g to the config file as well. Then add the device tdfx line. If you want to use the kld, the Makefile has directions on how to enable the debugging messages. you just uncomment a line in there, or add -DDEBUG to the make line. -- Coleman Kane President, UC Free O.S. Users Group - http://pohl.ececs.uc.edu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
Kazu,
Nope, it didn't appear to help. When I move the mouse around, it
intermitently pauses, perhaps once a second, for a short period of time.
Robert
On Fri, 28 Jul 2000, Kazutaka YOKOTA wrote:
Try the attached patch for /sys/isa/psm.c, and please report the
result.
Kazu
Robert Watson wrote:
I'm using a Micron P133 box with a PS/2 mouse. Up until this morning, I
was running 4.0-STABLE from a month or two back. I upgraded to
5.0-CURRENT, and since that time, my mouse has been responding slowly and
erratically, jumping as it moves, et al.
I'm using the default arguments to moused, with moused enabled in
/etc/rc.conf. I'm not sure what changed, but it would be nice if it
hadn't :-).
Yep. It's been that way in 5.0-current for about 2-3 weeks now. When
I use /dev/sysmouse in X, my mouse is really jumpy. It's so bad that
I don't use moused anymore in X. When I use my mouse normally, i.e.
without moused (/dev/mouse), in X, mouse movements are OK. Also,
cursor motion is jumpy as well. Must be the recent commits to
syscons.
--
- Donn
Index: psm.c
===
RCS file: /src/CVS/src/sys/isa/psm.c,v
retrieving revision 1.27
diff -u -r1.27 psm.c
--- psm.c 2000/07/22 04:08:12 1.27
+++ psm.c 2000/07/27 06:53:24
@@ -1827,9 +1827,11 @@
{
struct psm_softc *sc;
int unit;
+int s;
unit = (int)arg;
sc = devclass_get_softc(psm_devclass, unit);
+s = spltty();
if (sc-watchdog kbdc_lock(sc-kbdc, TRUE)) {
if (verbose = 4)
log(LOG_DEBUG, "psm%d: lost interrupt?\n", unit);
@@ -1837,6 +1839,7 @@
kbdc_lock(sc-kbdc, FALSE);
}
sc-watchdog = TRUE;
+splx(s);
sc-callout = timeout(psmtimeout, (void *)unit, hz);
}
Robert N M Watson
[EMAIL PROTECTED] http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Panic: lockmgr: pid 5, not exclusive lock holder 0 unlocking
I'm running with softupdates on /, and it has happened to me several times. On Fri, 28 Jul 2000, Brian Fundakowski Feldman wrote: On Fri, 28 Jul 2000, Sheldon Hearn wrote: Just a quick note to let you two gentlement know that the problem persists with rev 1.107 of buf.h. Brian, these are realy easy for me to reproduce on my own box here. Do you want to send me the stuff for maintaining the queues that you said would help you figure out what's going on? Or are you able to reproduce this yourself? I havne't been able to reproduce this, but this case is going to have more to do with analysis of the code than with "debugging", I think. By chance are you running with softupdates enabled on /? If I can reproduce it here, I will spend a while inspecting all the state to figure this one out as best as possible. Ciao, Sheldon. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' 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: Panic: lockmgr: pid 5, not exclusive lock holder 0 unlocking
On Fri, 28 Jul 2000, Brian Fundakowski Feldman wrote: I havne't been able to reproduce this, but this case is going to have more to do with analysis of the code than with "debugging", I think. By chance are you running with softupdates enabled on /? If I can reproduce it here, I will spend a while inspecting all the state to figure this one out as best as possible. I get the same panic 100% of the time upon reboot. So I can quite easily reproduce it. :) I tried turning off softupdates on all partitions. Same panic. It also caused umount to hang the machine. I don't have softupdates on / either way. I rebuilt a kernel today, about 1 hour ago. Still panics either way, with or without softupdates. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
On Fri, 28 Jul 2000, Robert Watson wrote: Kazu, Nope, it didn't appear to help. When I move the mouse around, it intermitently pauses, perhaps once a second, for a short period of time. Robert, how fast is the machine that it's pausing on? I have a feeling this could easily be Yarrow at work, since Yarrow runs right now most of the work done inside an interrupt handler (a taskqueue, at least). I'd like you to test the kthread version of Yarrow when Mark Murray and I are ready, which should be in a few days. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
a FS related patch to test please...
I'm in my beach-house and pretty offline right now, but I reviewed the
change Kirk did to addaliasu() and found at least one scenario where
it wouldn't do what he expected:
If bdevvp() is called more than once with the same dev_t we would
create more than one anonymous vnode for that dev_t and addaliasu()
would only get one of these in its yarn. This patch makes bdevvp()
only produce max one anonymous vnode per dev_t.
I don't know if the new rootfs-locating code calls bdevvp() more
than once, if it doesn't this patch is a harmless bit of overhead.
Please test, and if it doesn't do any harm I will commit it.
(This does not fix the panic everybody is talking about btw)
Poul-Henning
Index: vfs_subr.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.267
diff -u -r1.267 vfs_subr.c
--- vfs_subr.c 2000/07/24 05:28:29 1.267
+++ vfs_subr.c 2000/07/28 19:08:36
@@ -1276,6 +1276,8 @@
*vpp = NULLVP;
return (ENXIO);
}
+ if (vfinddev(dev, VCHR, vpp))
+ return (0);
error = getnewvnode(VT_NON, (struct mount *)0, spec_vnodeop_p, nvp);
if (error) {
*vpp = NULLVP;
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: new libstdc++ works?
On Fri, Jul 28, 2000 at 09:48:15PM +0900, [EMAIL PROTECTED] wrote: It seems new libstdc++ called libstdc++-v3 (http://gcc.gnu.org/) was released around this April. I don't know that I would call it in a released state yet. libstdc++ v2 is still the one that is offical part of GCC 2.96. Is there any plan to support it, or does someone succeed to port to FreeBSD? Any information is appreciated. From my point of view, I will bring it in when it is the stock libstdc++ for the compiler. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Netscape
Kris Kennaway [EMAIL PROTECTED] writes: Are the fixed in Netscape 4.74 bugs not critical for release? Who knows? I don't know of any changelog for Netscape. Netscape 4.74 contains a fix for security critical bug in handling of jpeg images. The bug was found and published on the 25th of July by Solar Designer. (as you all probably already know;) -- "I think there is a world market for maybe five computers." - Thomas Watson, chairman of IBM, 1943 * Suavek Zak / PGP: finger:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a FS related patch to test please...
FWIW, works for me
On Fri, 28 Jul 2000, Poul-Henning Kamp wrote:
I'm in my beach-house and pretty offline right now, but I reviewed the
change Kirk did to addaliasu() and found at least one scenario where
it wouldn't do what he expected:
If bdevvp() is called more than once with the same dev_t we would
create more than one anonymous vnode for that dev_t and addaliasu()
would only get one of these in its yarn. This patch makes bdevvp()
only produce max one anonymous vnode per dev_t.
I don't know if the new rootfs-locating code calls bdevvp() more
than once, if it doesn't this patch is a harmless bit of overhead.
Please test, and if it doesn't do any harm I will commit it.
(This does not fix the panic everybody is talking about btw)
Poul-Henning
Index: vfs_subr.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.267
diff -u -r1.267 vfs_subr.c
--- vfs_subr.c2000/07/24 05:28:29 1.267
+++ vfs_subr.c2000/07/28 19:08:36
@@ -1276,6 +1276,8 @@
*vpp = NULLVP;
return (ENXIO);
}
+ if (vfinddev(dev, VCHR, vpp))
+ return (0);
error = getnewvnode(VT_NON, (struct mount *)0, spec_vnodeop_p, nvp);
if (error) {
*vpp = NULLVP;
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
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
*** HEADS UP *** rc.conf changes (security)
After discussion with obrien, jhb, and dwithe (and non-protests from the other committers present), I'm changing the defaults for remote services in /etc/defaults/rc.conf to the least dangerous configuration, and making sysinstall write out overrides for the variables to their former default values in /etc/rc.conf upon install. This means that anybody upgrading /etc/defaults/rc.conf needs to add the following lines to rc.conf if they want to have the same setup afterwards (unless the variables already are set, of course): # Enable network daemons for user convenience. inetd_enable="YES" portmap_enable="YES" sendmail_enable="YES" (Heads up is over - more change detail below.) This change might seem a little counterintuitive (given that /etc/defaults/ are for defaults, after all) but seems to be the best compromise for both getting the functionality jkh wants (freshly installed boxes have active daemons, so users don't feel they have a lot of extra hassle to get things up and working like they are used to on other Unixen), and give FreeBSD a default secure config, meaning the insecurities stand out. I assume those of us that do new installs without using sysinstall know FreeBSD well enough to be able to handle turning those daemons on again if we want them ;) BTW: Keep me in the Cc: list, please - I am not subscribed to -current (or any other FreeBSD mailing list) at the moment. Eivind. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: *** HEADS UP *** rc.conf changes (security)
At 12:41 AM +0200 7/29/00, Eivind Eklund wrote: After discussion with obrien, jhb, and dwithe (and non-protests from the other committers present), I'm changing the defaults for remote services in /etc/defaults/rc.conf to the least dangerous configuration, and making sysinstall write out overrides for the variables to their former default values in /etc/rc.conf upon install. Hopefully sysinstall will be smarter about writing these overrides than it is about writing the "USA_RESIDENT=NO" override to /etc/make.conf. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: *** HEADS UP *** rc.conf changes (security)
Garance A Drosihn wrote: At 12:41 AM +0200 7/29/00, Eivind Eklund wrote: After discussion with obrien, jhb, and dwithe (and non-protests from the other committers present), I'm changing the defaults for remote services in /etc/defaults/rc.conf to the least dangerous configuration, and making sysinstall write out overrides for the variables to their former default values in /etc/rc.conf upon install. Hopefully sysinstall will be smarter about writing these overrides than it is about writing the "USA_RESIDENT=NO" override to /etc/make.conf. It is. It only writes these variables out when it creats an /etc/rc.conf file from scratch because one doesn't exist. Normally this only happens during the install. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: *** HEADS UP *** rc.conf changes (security)
Eivind Eklund wrote: This change might seem a little counterintuitive (given that /etc/defaults/ are for defaults, after all) but seems to be the best compromise for both getting the functionality jkh wants (freshly installed boxes have active daemons, so users don't feel they have a lot of extra hassle to get things up and working like they are used to on other Unixen), and give FreeBSD a default secure config, meaning the insecurities stand out. FWIW, I totally support this change. Personally, I think the default for everything should be "off," and the admin should be required to enable the services he needs. Eivind, it's good to see you, even semi-active. :) Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Compilation failure in current as of cvs-cur 6562
Anyone else seen this? chmod 755 /usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/auto/DynaLoader/DynaLoader .a cc -O -pipe -I/usr/src/gnu/usr.bin/perl/perl/../../../../contrib/perl5 -I/usr/obj/usr/src/gnu/usr.bin/perl/perl -DPERL_CORE -I/usr/obj/usr/src/i386/usr/include -Wl,-E -L/usr/obj/usr/src/gnu/usr.bin/perl/ perl/../libperl -o perl perlmain.o lib/auto/DynaLoader/DynaLoader.a -lperl -lm -lcrypt -lmd cc: Internal compiler error: program ld got fatal signal 11 *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Joining the mailing list
I am interested in joining the mailing list for freebsdcurrent. This can be e-mailed to: [EMAIL PROTECTED] or [EMAIL PROTECTED] Thanks, Aaron Pickett -- Scorch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fcntl and /dev/random
Setting status flags using F_SETFL command of fcntl(2) on the file
descriptor, which is returned by open(2)ing /dev/random, seems not to
be supported. For example, when I run following code;
#include stdio.h
#include errno.h
#include fcntl.h
main()
{
int fd;
fd = open("/dev/random", O_RDONLY);
if (fcntl(fd, F_SETFL, O_NONBLOCK) == -1) {
printf("%s\n", strerror(errno));
}
}
3.4-RELEASE(and possibly 3.5 and 3.5.1) and 4.1-RELEASE/4.1-STABLE say
`Inappropriate ioctl for device' and 5-current says `Operation not
supported by device'.
I've found above in BIND9's source and its `named' program complains
everytime it's invoked.
Should I fix BIND9's code? or wait for fcntl's F_SETFL being
supported on FreeBSD?
Actually, in BIND9, fd is already open(2)ed with `O_RDONLY | O_NONBLOCK'
and setting O_NONBLOCK status with fcntl(2) is not needed, which means
that fixing BIND9's code is very simple; just comment out the fcntl(2)ing line.
h.hanai
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Mouse behaving funny since 5.0-CURRENT upgrade
On Fri, 28 Jul 2000, Brian Fundakowski Feldman wrote: On Fri, 28 Jul 2000, Robert Watson wrote: Nope, it didn't appear to help. When I move the mouse around, it intermitently pauses, perhaps once a second, for a short period of time. Robert, how fast is the machine that it's pausing on? I have a feeling this could easily be Yarrow at work, since Yarrow runs right now most of the work done inside an interrupt handler (a taskqueue, at least). CPU: Pentium/P54C (119.75-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping = 5 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 real memory = 100663296 (98304K bytes) So not a big speed demon, but should be reasonable for most tasks, and perfectly decent as a file server, workstation, et al. I'd like you to test the kthread version of Yarrow when Mark Murray and I are ready, which should be in a few days. Sure. I'll be out of town at IETF next week, but once I get back I can look at that. I may upgrade my notebook to -CURRENT at some point soon also. Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
