RE: (KAME-snap 3327) Re: Panic on current (12 Sept)
Hi ... Without starting the racoon daemon and doing a secure connect everything works fine without a problem. If I start racoon, do a tunnel connection and then run daily, the machine panics .. Reinier On 16-Sep-00 Shoichi 'Ne' Sakane wrote: >> I'm running a current machine of 12 Sept although this problem >> also occured on a current of a few days earlier ... >> >> This only happens when using the IPv6 IPSec code during the day, >> it is readily reproduceable. >> >> If during the day I load the racoon daemon and load keys and >> establish a IPSec tunnel connection everything works fine till >> 2:00 am when the daily script runs OR if I run the daily script >> by hand ... I generated the following dump and backtrace ... >> >> It seems to crash in a makedev routine using FOREACH list macro's. >> >> The problem doesn't seem to be with the list or the makedev function >> in kern_conf.c. It seems to me that something in the kernel >> corrupts the static list dev_hash when using the IPSec code. >> >> Summary - when ising IPSec ... machine panics during daily >> script execution. > > I think IPsec is not relative to this issue. To make sure, > does your machine run healthy without IPsec ? > Please try the following. > case 1) with option IPSEC, but no SPD entry. > case 2) without option IPSEC ### # # # R.N. Bezuidenhout NetSeq Firewall # # [EMAIL PROTECTED] http://www.nanoteq.co.za# # # ### -- Date: 18-Sep-00 Time: 10:04:59 This message was sent by XFMail -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: (KAME-snap 3327) Re: Panic on current (12 Sept)
As far as I recall ... the first kernel was before any of the SMP commits ... but in case it was not ... how do I go about going back to a "coarse grain lock" kernel ... can I set something in the config file or do I have to checkout old sources ?? Reinier On 17-Sep-00 [EMAIL PROTECTED] wrote: > >>> I'm running a current machine of 12 Sept although this problem >>> also occured on a current of a few days earlier ... > > "current machine" meaning FreeBSD-current? if so, are there any > locking behavior changes due to the introduction of fine grain locks? > what happens if you go back to coarse grain lock kernel? > > itojun > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message ### # # # R.N. Bezuidenhout NetSeq Firewall # # [EMAIL PROTECTED] http://www.nanoteq.co.za# # # ### -- Date: 18-Sep-00 Time: 09:59:11 This message was sent by XFMail -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Debugging -current SMPNG HANG on heavy disk-io
On Sun, 17 Sep 2000, John Baldwin wrote: ... > Hmm, could it be lockmgr() related? How can I proof? Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make world fails errors in libedit?
Updated around 3 am (CET) and tryed to build the world but if fails miserably on libedit. Script started on Mon Sep 18 06:18:48 2000 (root@worldclass:/usr/src) make world -- >>> elf make world started on Mon Sep 18 06:18:52 GMT 2000 -- -- >>> Rebuilding the temporary build tree -- rm -rf /usr/obj/usr/src/i386 ===> libedit cc -O2 -pipe -I. -I/usr/src/lib/libedit -I/usr/obj/usr/src/i386/usr/include -c editline.c -o editline.o In file included from /usr/src/lib/libedit/chared.h:130, from /usr/src/lib/libedit/el.h:97, from /usr/src/lib/libedit/chared.c:47, from editline.c:4: common.h:2: warning: garbage at end of `#ifndef' argument common.h:3: warning: missing white space after `#define _h_' In file included from /usr/src/lib/libedit/chared.h:131, from /usr/src/lib/libedit/el.h:97, from /usr/src/lib/libedit/chared.c:47, from editline.c:4: vi.h:2: warning: garbage at end of `#ifndef' argument In file included from /usr/src/lib/libedit/chared.h:132, from /usr/src/lib/libedit/el.h:97, from /usr/src/lib/libedit/chared.c:47, from editline.c:4: emacs.h:2: warning: garbage at end of `#ifndef' argument In file included from editline.c:8: fcns.c:32: `vi_add' undeclared here (not in a function) fcns.c:32: initializer element is not constant fcns.c:32: (near initialization for `el_func[54]') fcns.c:32: `vi_add_at_eol' undeclared here (not in a function) fcns.c:32: initializer element is not constant fcns.c:32: (near initialization for `el_func[55]') fcns.c:33: `vi_change_case' undeclared here (not in a function) fcns.c:33: initializer element is not constant fcns.c:33: (near initialization for `el_func[56]') fcns.c:33: `vi_change_meta' undeclared here (not in a function) fcns.c:33: initializer element is not constant fcns.c:33: (near initialization for `el_func[57]') fcns.c:34: `vi_change_to_eol' undeclared here (not in a function) fcns.c:34: initializer element is not constant fcns.c:34: (near initialization for `el_func[58]') fcns.c:34: `vi_command_mode' undeclared here (not in a function) fcns.c:34: initializer element is not constant fcns.c:34: (near initialization for `el_func[59]') fcns.c:35: `vi_delete_meta' undeclared here (not in a function) fcns.c:35: initializer element is not constant fcns.c:35: (near initialization for `el_func[60]') fcns.c:35: `vi_delete_prev_char' undeclared here (not in a function) fcns.c:35: initializer element is not constant fcns.c:35: (near initialization for `el_func[61]') fcns.c:36: `vi_end_word' undeclared here (not in a function) fcns.c:36: initializer element is not constant fcns.c:36: (near initialization for `el_func[62]') fcns.c:36: `vi_insert' undeclared here (not in a function) fcns.c:36: initializer element is not constant fcns.c:36: (near initialization for `el_func[63]') fcns.c:37: `vi_insert_at_bol' undeclared here (not in a function) fcns.c:37: initializer element is not constant fcns.c:37: (near initialization for `el_func[64]') fcns.c:37: `vi_kill_line_prev' undeclared here (not in a function) fcns.c:37: initializer element is not constant fcns.c:37: (near initialization for `el_func[65]') fcns.c:38: `vi_list_or_eof' undeclared here (not in a function) fcns.c:38: initializer element is not constant fcns.c:38: (near initialization for `el_func[66]') fcns.c:38: `vi_next_char' undeclared here (not in a function) fcns.c:38: initializer element is not constant fcns.c:38: (near initialization for `el_func[67]') fcns.c:39: `vi_next_space_word' undeclared here (not in a function) fcns.c:39: initializer element is not constant fcns.c:39: (near initialization for `el_func[68]') fcns.c:39: `vi_next_word' undeclared here (not in a function) fcns.c:39: initializer element is not constant fcns.c:39: (near initialization for `el_func[69]') fcns.c:40: `vi_paste_next' undeclared here (not in a function) fcns.c:40: initializer element is not constant fcns.c:40: (near initialization for `el_func[70]') fcns.c:40: `vi_paste_prev' undeclared here (not in a function) fcns.c:40: initializer element is not constant fcns.c:40: (near initialization for `el_func[71]') fcns.c:41: `vi_prev_char' undeclared here (not in a function) fcns.c:41: initializer element is not constant fcns.c:41: (near initialization for `el_func[72]') fcns.c:41: `vi_prev_space_word' undeclared here (not in a function) fcns.c:41: initializer element is not constant fcns.c:41: (near initialization for `el_func[73]') fcns.c:42: `vi_prev_word' und
Re: patch for openssh
On 17 Sep, John Polstra wrote: > What is the point of that change? Functionally it makes no difference > at all, since "*auth" is an AuthenticationConnection. It makes the I was a little bit confused at that time. Yes, it's more of a bikeshed decision, IMHO it makes it less difficult to read (you didn't have to search for the type). > code harder to maintain in case the type of "auth" is changed in the > future. This depends on the type of change someone makes. If you didn't change the typedef of "AuthenticationConnection" but the type of "auth", you normaly have to go through the code and ensure every invariant is still valid (I classify this as a major code change, but this is a bikeshed argument too). Bye, Alexander. -- The three Rs of Microsoft support: Retry, Reboot, Reinstall. 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
Re: Please review: small change in sys/i386/isa/clock.c andsys/alpha/alpha/clock.c for PC-Card melody beep code.
On Sun, 17 Sep 2000, Warner Losh wrote: > I've seen these patches many times and think that it is a good idea. > This interface needs to be exported so that the pccard system sounds > don't interfere with normal systme sounds. It needs locking changes to be exportable: 1) splhigh()/splx(), at least in RELENG_4 where there is no giant lock and spl*() has a non-null effect, so that callers don't need to know that it must be called at splsoftclock() or higher. 2) Honor the current locking protocol acquire_timer2()/release_timer2() -- don't do anything if (!beeping). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMWare on -current, how fast should I expect it to be?
On Tue, Sep 12, 2000 at 04:44:41PM +0200, Reinier Bezuidenhout wrote: > Let me first ask ... do you use the "suspend/resume" option?? Yep. > This caused the same "lockup" every few seconds on my machine too - > a much slower 400 PII. As soon as I "shutdown" Win9X and rebooted > it worked fine. I tried that. The pauses are still there :-( Thanks for the suggestion. N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
On Sun, 17 Sep 2000, Adrian Filipi-Martin wrote: > I recently ran into revelant problem with /dev/stdout, while > working on some software under linux that expected /dev/stdout as an > argument instead of using stdout. > > Using the device file breaks, if the process is suid to a non-root > user. This is because it cannot open /dev/stdout, which is owned by your > UID and not the EUID of the process to which the device was passed. My > solution was to add the "-" hack and use the existing open descriptor. Um, open on fdesc devices doesn't check either uid. It just checks the access mode. Perhaps the software expected /dev/stdout to for read-write like a tty would be. Then opening /dev/stdout would fail for normal shell output redirection which only opens for writing. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: updated OpenSSH & pam_ssh, the old bug is back
-On [2916 17:10], Alexander Leidinger ([EMAIL PROTECTED]) wrote: >after the update of OpenSSH xdm crashes if I enable pam_ssh in pam.conf. >I fixed this in the old version, but it seems the bug is back. > >I have a look at it and try to produce a patch again. You mean that bug which you reported and produced a patch and which I subsequently committed? The malloc.conf -> AJ resulted coredump one? -- Jeroen Ruigrok van der Werven Network- and systemadministrator <[EMAIL PROTECTED]>VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Grant me the serenity to accept the things I cannot change, courage to change the things I can, and wisdom to know the difference... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: (KAME-snap 3338) Re: Panic on current (12 Sept)
>> "current machine" meaning FreeBSD-current? if so, are there any >> locking behavior changes due to the introduction of fine grain locks? >> what happens if you go back to coarse grain lock kernel? >As far as I recall ... the first kernel was before any of the SMP >commits ... but in case it was not ... how do I go about >going back to a "coarse grain lock" kernel ... can I set >something in the config file or do I have to checkout old >sources ?? for this part (how to get a source before fine grain SMP) I'm totally unsure. sorry itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: (KAME-snap 3337) RE: Panic on current (12 Sept)
>Without starting the racoon daemon and doing a secure connect >everything works fine without a problem. If I start racoon, >do a tunnel connection and then run daily, the machine panics .. I bet you can panic the kernel with setkey(8) in that case. am I correct? if so, something is not friendly with fine grain SMP, under sys/netkey. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: updated OpenSSH & pam_ssh, the old bug is back
On 18 Sep, Jeroen Ruigrok van der Werven wrote: >>after the update of OpenSSH xdm crashes if I enable pam_ssh in pam.conf. >>I fixed this in the old version, but it seems the bug is back. >> >>I have a look at it and try to produce a patch again. > > You mean that bug which you reported and produced a patch and which I > subsequently committed? The malloc.conf -> AJ resulted coredump one? Initially yes, but at the moment I'm under the impression it's another bug (I don't know where it is and how to fix it), the old one seems to be fixed. Bye, Alexander. -- ...and that is how we know the Earth to be banana-shaped. 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
Re: updated OpenSSH & pam_ssh, the old bug is back
-On [2918 16:20], Alexander Leidinger ([EMAIL PROTECTED]) wrote: >On 18 Sep, Jeroen Ruigrok van der Werven wrote: > >> You mean that bug which you reported and produced a patch and which I >> subsequently committed? The malloc.conf -> AJ resulted coredump one? > >Initially yes, but at the moment I'm under the impression it's another >bug (I don't know where it is and how to fix it), the old one seems to >be fixed. Is it a malloc.conf -> AJ related bug again? =) Anyway, if you find it, don't hesitate to let me know, so I can apply it. Cheers, -- Jeroen Ruigrok van der Werven Network- and systemadministrator <[EMAIL PROTECTED]>VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Grant me the serenity to accept the things I cannot change, courage to change the things I can, and wisdom to know the difference... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
"No buffer space available" errors
Does anyone have any clue what could cause errors like this? I've been seeing this sort of stuff since the SMPng commit, IIRC. I'm sure there's more information I should be giving, so just let me know what to find. dmesg is at the end. Sep 18 07:56:01 lithium last message repeated 17 times Sep 18 07:56:10 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 07:56:11 lithium dhclient: send_packet: No buffer space available Sep 18 07:56:29 lithium dhclient: send_packet: No buffer space available Sep 18 07:57:55 lithium last message repeated 4 times Sep 18 08:06:30 lithium last message repeated 14 times Sep 18 08:09:16 lithium dhclient: send_packet: No buffer space available Sep 18 08:09:39 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 08:10:49 lithium dhclient: send_packet: No buffer space available Sep 18 08:11:26 lithium last message repeated 4 times Sep 18 08:13:32 lithium last message repeated 4 times Sep 18 08:18:13 lithium last message repeated 3 times Sep 18 08:23:08 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 08:23:09 lithium dhclient: send_packet: No buffer space available Sep 18 08:23:30 lithium last message repeated 2 times Sep 18 08:24:31 lithium last message repeated 2 times Sep 18 08:31:00 lithium last message repeated 2 times Sep 18 08:36:37 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 08:37:10 lithium dhclient: send_packet: No buffer space available Sep 18 08:39:00 lithium dhclient: send_packet: No buffer space available Sep 18 08:41:10 lithium last message repeated 2 times Sep 18 08:50:01 lithium last message repeated 15 times Sep 18 08:50:06 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 08:50:34 lithium dhclient: send_packet: No buffer space available Sep 18 08:51:12 lithium last message repeated 2 times Sep 18 08:53:00 lithium last message repeated 7 times Sep 18 09:03:03 lithium last message repeated 18 times Sep 18 09:03:35 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 09:04:27 lithium dhclient: send_packet: No buffer space available Sep 18 09:04:57 lithium last message repeated 3 times Sep 18 09:06:50 lithium last message repeated 4 times Sep 18 09:15:35 lithium last message repeated 4 times Sep 18 09:17:04 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 09:17:20 lithium dhclient: send_packet: No buffer space available Sep 18 09:19:14 lithium dhclient: send_packet: No buffer space available Sep 18 09:21:01 lithium last message repeated 3 times Sep 18 09:30:04 lithium last message repeated 8 times Sep 18 09:30:33 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 09:32:33 lithium dhclient: send_packet: No buffer space available Sep 18 09:34:36 lithium dhclient: send_packet: No buffer space available Sep 18 09:35:31 lithium dhclient: send_packet: No buffer space available Sep 18 09:42:40 lithium last message repeated 7 times Sep 18 09:44:02 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 09:45:57 lithium dhclient: send_packet: No buffer space available Sep 18 09:47:17 lithium dhclient: send_packet: No buffer space available Sep 18 09:48:24 lithium last message repeated 3 times Sep 18 09:57:31 lithium last message repeated 25 times Sep 18 09:57:31 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 09:57:51 lithium dhclient: send_packet: No buffer space available Sep 18 09:58:35 lithium last message repeated 2 times Sep 18 10:00:43 lithium last message repeated 3 times Sep 18 10:07:45 lithium last message repeated 4 times Sep 18 10:11:00 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 10:12:49 lithium dhclient: send_packet: No buffer space available Sep 18 10:21:14 lithium dhclient: send_packet: No buffer space available Sep 18 10:24:29 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 10:37:58 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.91.47: No buffer space available Sep 18 10:41:39 lithium dhclient: send_packet: No buffer space available Sep 18 10:46:54 lithium dhclient: send_packet: No buffer space available Sep 18 10:51:27 lithium timed[27809]: /current/src/usr.sbin/timed/timed/acksend.c 110: sendto 192.168.
Re: updated OpenSSH & pam_ssh, the old bug is back
On 18 Sep, Jeroen Ruigrok van der Werven wrote: >>> You mean that bug which you reported and produced a patch and which I >>> subsequently committed? The malloc.conf -> AJ resulted coredump one? >> >>Initially yes, but at the moment I'm under the impression it's another >>bug (I don't know where it is and how to fix it), the old one seems to >>be fixed. > > Is it a malloc.conf -> AJ related bug again? =) No, I'm at malloc.conf -> aj now. > Anyway, if you find it, don't hesitate to let me know, so I can apply > it. I don't know where to look. The only usefull information I have so far is: ---snip--(from /lib/X11/xdm/xdm-error)- xdm error (pid 2530): Unknown session exit code 2816 from process 2727 ---snip--- I assume (from looking at the openssh source) proc 2727 is ssh-agent. I'm not that familiar with the internals of xdm, pam or ssh to know where to look further. A helping hand would be fine. :) Bye, Alexander. -- The three Rs of Microsoft support: Retry, Reboot, Reinstall. 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
Re: (KAME-snap 3338) Re: Panic on current (12 Sept)
> On Mon, 18 Sep 2000 10:00:53 +0200 (SAST) > Reinier Bezuidenhout <[EMAIL PROTECTED]> said: rbezuide> As far as I recall ... the first kernel was before any of the SMP rbezuide> commits ... but in case it was not ... how do I go about rbezuide> going back to a "coarse grain lock" kernel ... can I set rbezuide> something in the config file or do I have to checkout old rbezuide> sources ?? There is a tag just before SMPNG merge. You can do cvsup with: src-all tag=PRE_SMPNG -- 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
Thread-safe version of fpathconf(2) syscall missed from libc_r [patch for review]
Hi,
It seems that due to unknown for me reasons, thread-safe wrapper for
fpathconf(2) syscall is missed from the libc_r, while fpathconf listed in the
list of syscalls for which thread-safe wrappers are to be provided
(src/lib/libc_r/Makefile:31). The following short example exposes the bug:
fpath.c:
#include
#include
int main()
{
return fpathconf(1, 3);
}
$ cc -pthread fpath.c
/tmp/ccF56334.o: In function `main':
/tmp/ccF56334.o(.text+0xe): undefined reference to `fpathconf'
Attached patch expected to fix the problem.
-Maxim
diff -druN libc_r.orig/uthread/Makefile.inc libc_r/uthread/Makefile.inc
--- libc_r.orig/uthread/Makefile.incFri Aug 11 14:49:15 2000
+++ libc_r/uthread/Makefile.inc Mon Sep 18 18:28:49 2000
@@ -49,6 +49,7 @@
uthread_find_thread.c \
uthread_flock.c \
uthread_fork.c \
+ uthread_fpathconf.c \
uthread_fstat.c \
uthread_fstatfs.c \
uthread_fsync.c \
diff -druN libc_r.orig/uthread/pthread_private.h libc_r/uthread/pthread_private.h
--- libc_r.orig/uthread/pthread_private.h Fri Aug 11 14:49:15 2000
+++ libc_r/uthread/pthread_private.hMon Sep 18 19:10:00 2000
@@ -1204,6 +1204,7 @@
int _thread_sys_pause(void);
int _thread_sys_pipe(int *);
int _thread_sys_select(int, fd_set *, fd_set *, fd_set *, struct timeval *);
+long_thread_sys_fpathconf(int, int);
off_t _thread_sys_lseek(int, off_t, int);
pid_t _thread_sys_fork(void);
pid_t _thread_sys_tcgetpgrp(int);
diff -druN libc_r.orig/uthread/uthread_fpathconf.c libc_r/uthread/uthread_fpathconf.c
--- libc_r.orig/uthread/uthread_fpathconf.c Thu Jan 1 03:00:00 1970
+++ libc_r/uthread/uthread_fpathconf.c Mon Sep 18 19:24:14 2000
@@ -0,0 +1,46 @@
+/*
+ * Copyright (c) 2000 Maxim Sobolev <[EMAIL PROTECTED]>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * $FreeBSD$
+ */
+#include
+#ifdef _THREAD_SAFE
+#include
+#include "pthread_private.h"
+
+long
+_fpathconf(int fd, int name)
+{
+ longret;
+
+ if ((ret = _FD_LOCK(fd, FD_READ, NULL)) == 0) {
+ ret = _thread_sys_fpathconf(fd, name);
+ _FD_UNLOCK(fd, FD_READ);
+ }
+ return ret;
+}
+
+__strong_reference(_fpathconf, fpathconf);
+#endif
Re: "No buffer space available" errors
On Mon, 18 Sep 2000, Ben Smithurst wrote: > Does anyone have any clue what could cause errors like this? I've > been seeing this sort of stuff since the SMPng commit, IIRC. I'm sure > there's more information I should be giving, so just let me know what to > find. dmesg is at the end. This looks an awful lot like something I was seeing during early testing while adding locking to the mbuf system. Try `netstat -m' to see how many mbuf clusters are allocated. I would guess that the system is unable to allocate clusters reliably. In my case, at the time, I had forgotten to change a pointer dereference to meet the new structure, and thus it just worked out that after allocating the initial amount of clusters, nothing more was possible to allocate. I haven't seen this problem after fixing my mistake, nor before introducing it. None of the work I mentionned has been committed at any point in time (yet), so the problem can only be similar, at best (in any case, a `netstat -m' should offer a clue). Regards, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "No buffer space available" errors
On Mon, 18 Sep 2000, Ben Smithurst wrote: > Does anyone have any clue what could cause errors like this? I've > been seeing this sort of stuff since the SMPng commit, IIRC. I'm sure > there's more information I should be giving, so just let me know what > to find. dmesg is at the end. ... > ep0: <3Com 3C509-Combo EtherLink III> at port 0x300-0x30f irq 10 on isa0 > ep0: Ethernet address 00:a0:24:eb:f4:a2 Run 'netstat -m' when you encounter the problem and email me the results. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Strange procfs bug(?) 3.2-RELEASE
Does anyone know if the patch indicated below was committed to fix this FreeBSD 3.2 bug? I can't upgrade to a later release yet, but if this patch is it, I can hack it in. On Mon, 11 Sep 2000, Alfred Perlstein wrote: > * David Kirchner <[EMAIL PROTECTED]> [000911 12:19] wrote: > > > > > Yes, there's a problem with procfs in 3.2 when you stress it heavily > > > like that, my suggestion is to get 4-stable running, or at least try > > > to get 3.5.1 up and running, but I'm unsure if it's fixed in 3.5.1. > > > > > > -Alfred > > > > Is this related? : > > > > "Don't call calcru() on a swapped-out process. calcru() access p_stats, > > which is in U-area." > > > > That's from CVSweb at file procfs_status.c, revision 1.14 > > I'm not really a procfs guru, I only know about your reported problem, > I've never heard of that message though. > > -- > -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] > "I have the heart of a child; I keep it in a jar on my desk." > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMPng feedback
Alright, I've been using -CURRENT with the SMPng changes for a few days and wanted to give some feedback. Overall everything works, although I have been experienceing a few problems which may or may not be related. 1) When I'm playing music (mp3), and I move the mouse or move a window in X, the sound stutters and I get a pcm0: hwptr went backwards x -> y (where x and y are different numbers). 2) the mouse is quite jumpy in X, especially while there is high cpu usage. I have tried to use both the usb mouse and the psm mouse (I have a usb to psm adapter) and the behaviour is the same with all mice I've tried. ( a logitec optical mouse, and a ms intellimouse with the ball, not optical) These have been the only noticable changes to my system since the update... I have built the world with the changes in the kernel without problems so they seem stable enough, just kinda slow. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
periodic no longer usable by users?
It seems that recent (the last two weeks?) changes to periodic have changed things so that non-root users of it no longer get any output. A simple fix would be to change the default output to $USER (not yet tested). However, having a user-specific periodic.conf would be a lot more useful. But I wanted to see what others thought of it before trying it.
Re: Fdescfs updates--coming to a devfs near you!
On Tue, 19 Sep 2000, Bruce Evans wrote: > On Sun, 17 Sep 2000, Adrian Filipi-Martin wrote: > > > I recently ran into revelant problem with /dev/stdout, while > > working on some software under linux that expected /dev/stdout as an > > argument instead of using stdout. > > > > Using the device file breaks, if the process is suid to a non-root > > user. This is because it cannot open /dev/stdout, which is owned by your > > UID and not the EUID of the process to which the device was passed. My > > solution was to add the "-" hack and use the existing open descriptor. > > Um, open on fdesc devices doesn't check either uid. It just checks > the access mode. > > Perhaps the software expected /dev/stdout to for read-write like a > tty would be. Then opening /dev/stdout would fail for normal shell > output redirection which only opens for writing. No, it wasn't a RW/W issue. I dug a little deeper. It looks like the BSD implmentation of /dev/stdout is smarter than the linux version. Linux's is a symlink into /proc and the device ownership is determined by the UID of the invoking user. I guess I wouldn't have have had a problem under BSD. no suprise here. Adrian -- [ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel breakage in aac.c (Was: Can't build a kernel)
On Sun, 17 Sep 2000, Doug Barton wrote: > If I use the buildkernel target I get the following: > > make: cannot open > /usr/amd/realmounts/slave/usr/current/src/sys/dev/aic7xxx/Makefile. > *** Error code 2 > > Stop in /usr/amd/realmounts/slave/usr/current/src. > *** Error code 1 This is fixed now. > If I use the old way, I get errors about a pointer with an incomplete > type in aac (whatever that is). This is still broken: ===> aac cc -O -pipe -DAAC_COMPAT_LINUX -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/../include -mpreferred-stack-boundary=2 -c /usr/amd/realmounts/slave/usr/current/src/sys/modules/aac/../../dev/aac/aac.c /usr/amd/realmounts/slave/usr/current/src/sys/modules/aac/../../dev/aac/aac.c: In function `aac_linux_ioctl': /usr/amd/realmounts/slave/usr/current/src/sys/modules/aac/../../dev/aac/aac.c:1815: dereferencing pointer to incomplete type Doug -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel breakage in aac.c (Was: Can't build a kernel)
> This is still broken: > >===> aac >cc -O -pipe -DAAC_COMPAT_LINUX -D_KERNEL -Wall -Wredundant-decls >-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith >-Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- >-I. -I@ -I@/../include -mpreferred-stack-boundary=2 -c >/usr/amd/realmounts/slave/usr/current/src/sys/modules/aac/../../dev/aac/aac.c >/usr/amd/realmounts/slave/usr/current/src/sys/modules/aac/../../dev/aac/aac.c: In >function `aac_linux_ioctl': >/usr/amd/realmounts/slave/usr/current/src/sys/modules/aac/../../dev/aac/aac.c:1815: >dereferencing >pointer to incomplete type Here is a fix. Hopefully Mike will commit it soon. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. Index: aac.c === RCS file: /home/ncvs/src/sys/dev/aac/aac.c,v retrieving revision 1.1 diff -c -r1.1 aac.c *** aac.c 2000/09/13 03:20:34 1.1 --- aac.c 2000/09/18 08:45:08 *** *** 35,40 --- 35,41 #include #include #include + #include #include To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel breakage in aac.c (Was: Can't build a kernel)
Et voila. Thanks, Doug On Mon, 18 Sep 2000, David Greenman wrote: >Here is a fix. Hopefully Mike will commit it soon. > > -DG > > David Greenman > Co-founder, The FreeBSD Project - http://www.freebsd.org > President, TeraSolutions, Inc. - http://www.terasolutions.com > Pave the road of life with opportunities. > > Index: aac.c > === > RCS file: /home/ncvs/src/sys/dev/aac/aac.c,v > retrieving revision 1.1 > diff -c -r1.1 aac.c > *** aac.c 2000/09/13 03:20:34 1.1 > --- aac.c 2000/09/18 08:45:08 > *** > *** 35,40 > --- 35,41 > #include > #include > #include > + #include > > #include > > -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please review: small change in sys/i386/isa/clock.c and sys/alpha/alpha/clock.c for PC-Card melody beep code.
>I've seen these patches many times and think that it is a good idea.
>This interface needs to be exported so that the pccard system sounds
>don't interfere with normal systme sounds.
Thanks for your response. OK, I will commit this patch the next
weekend.
--
By the way, we also need to change in sys/pc98/pc98/clock.c.
---
MIHIRA, Sanpei Yoshiro
Yokohama, Japan.
--- sys/pc98/pc98/clock.c.org Mon Sep 18 21:13:55 2000
+++ sys/pc98/pc98/clock.c Fri Sep 15 14:42:42 2000
@@ -583,7 +583,7 @@
#endif
}
-void
+static void
sysbeepstop(void *chan)
{
#ifdef PC98/* PC98 */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Please review: small change in sys/i386/isa/clock.c and sys/alpha/alpha/clock.c for PC-Card melody beep code.
In message <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: : >I've seen these patches many times and think that it is a good idea. : >This interface needs to be exported so that the pccard system sounds : >don't interfere with normal systme sounds. : : Thanks for your response. OK, I will commit this patch the next : weekend. : -- : By the way, we also need to change in sys/pc98/pc98/clock.c. mihira-san, Did you see bruce's commentso n the change? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please review: small change in sys/i386/isa/clock.c and sys/alpha/alpha/clock.c for PC-Card melody beep code.
Warner-san wrote: >In message <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >: >I've seen these patches many times and think that it is a good idea. >: >This interface needs to be exported so that the pccard system sounds >: >don't interfere with normal systme sounds. >: >: Thanks for your response. OK, I will commit this patch the next >: weekend. >: -- >: By the way, we also need to change in sys/pc98/pc98/clock.c. > >mihira-san, > Did you see bruce's commentso n the change? I wrote replay mail before I read Bruce's mail I will re-write code with bruce's suggestion. Thank you, Bruce and Warner. --- MIHIRA, Sanpei Yoshiro Yokohama, Japan. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMPng feedback
> 1) When I'm playing music (mp3), and I move the mouse or move a window in > X, the sound stutters and I get a pcm0: hwptr went backwards x -> y (where > x and y are different numbers). > > 2) the mouse is quite jumpy in X, especially while there is high cpu > usage. I have tried to use both the usb mouse and the psm mouse (I have a > usb to psm adapter) and the behaviour is the same with all mice I've > tried. ( a logitec optical mouse, and a ms intellimouse with the ball, > not optical) How old is your build? Do you have the kthreaded /dev/random driver? (do a top -S and look for a process called "random" when you wiggle your mouse). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
