Re: updated to August 5th kernel broke mozilla
On 14:06-0700, Aug 9, 2002, Brooks Davis wrote: > I recently updated my laptop's kernel to an August 5th version from an > July 23rd one and mozilla started getting connection refused from > everything. Lynx worked fine as did other network services like cvsup > and ssh. Upgrading mozilla from 1.0_rc? to the latest version corrected > the problem, but so did booting with an old kernel so something weird is > going on. Try sysctl net.inet6.ip6.v6only=0 or rebuild mozilla. -- Maxim Konovalov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sendfile(2) is broken (Was: ftpd problem: Input/output error)
On 03:37+0700, Aug 12, 2002, Semen A. Ustimenko wrote: > Hi! > > On Sun, 11 Aug 2002, Robert Watson wrote: > > > On Sun, 11 Aug 2002, Maxim Konovalov wrote: > > > > > This is sendfile(2) mis-behaviour arised after rev.1.109 > > > sys/kern/uipc_syscalls.c but I think the real problem in vn_rdwr(), > > > sys/kern/vfs_vnops.c. Here is my patch but I really need somebody with > > > vfs clue. I CC'ed Robert Watson as an author of sendfile(2) > > > modification and our vfs expert. > > > > Semen Ustimenko <[EMAIL PROTECTED]> ran into a similar problem, but his > > fix was to teach sendfile() to pass in a non-NULL resid and handle the > > failure mode better. I suspect this fix is more correct since it will > > both handle the failure mode and the data delivered, and probably is > > required for other consumers of vn_rdwr(). He was going to run the patch > > past dg, and then commit it assuming dg approved it, so hopefully it will > > go into the tree in the next day or so. > > > > David reviewed the patch and I have committed it few minutes ago. Looks like a hack BDE is speaking about: passing a storage for residue but never check it. Anyway I don't understand why VOP_READ in vn_rdwr() returns a residue in uio.uio_resid when all data trasferred actually? -- Maxim Konovalov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rcNG and dhcp
Hi
There is patch to teach rcNG do not try dhcp on not-connected ethernet.
simply put
ifconfig_fxp0="dhcp-if-carrier"
into rc.conf
It will be interested to somebody
Theoretically there are another solution for problem - add new key to
dhclient - check interface media before broadcasting.
--
Vladimir B. Grebenschikov
[EMAIL PROTECTED], SWsoft, Inc.
--- /usr/local/src/etc/rc.d/network1Mon Jul 29 15:09:46 2002
+++ /etc/rc.d/network1 Mon Aug 12 11:43:03 2002
@@ -157,6 +157,17 @@
case ${ifconfig_args} in
'')
;;
+ [Dd][Hh][Cc][Pp]-[Ii][Ff]-[Cc][Aa][Rr][Rr][Ii][Ee][Rr])
+ # Load interface .ko if need
+ ifconfig $ifn > /dev/null 2>&1
+ sleep 3
+ # Check media option of interface
+ media=`ifconfig $ifn | awk '($1 == "media:") { ok=1; print $4;
+} END { if (ok != 1) { print "(none)"; } }' 2> /dev/null`
+ if [ "$media" != "(none)" ]; then
+ dhcp_interfaces="$dhcp_interfaces $ifn"
+ eval showstat_$ifn=1
+ fi
+ ;;
[Dd][Hh][Cc][Pp])
# DHCP inits are done all in one go below
dhcp_interfaces="$dhcp_interfaces $ifn"
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Sun, Aug 11, 2002 at 06:54:42PM -0700, Julian Elischer wrote:
> I am forwarding this to -current as I think it needs more neurons on it..
> I am presently unable to spend any due to work commitments, and due to a sort-of
> personal confusion about tis stuff anyhow..
>
>
> David Xu wrote:
> >
> > does anyone believe that su behaviours correctly?
> > we are talking that kernel has bug to handle job control
> > but I found that the issue may not related to signal handling
> > problem, but related to su or csh's job control.
> > I see this piece of code in su.c:
> >
> > switch (child_pid) {
> > default:
> > while ((ret_pid = waitpid(child_pid, &statusp, WUNTRACED)) !=
>eca-1) {
> > if (WIFSTOPPED(statusp)) {
> > child_pgrp = tcgetpgrp(1);
> > kill(getpid(), SIGSTOP);
> > tcsetpgrp(1, child_pgrp);
> > kill(child_pid, SIGCONT);
> > statusp = 1;
> > continue;
> > }
> > break;
> > }
> >
> > I have traced down su. In my test, the su process forked a
> > child process, child process pid is 873 while parent pid is 872.
> > these code are in question, I found that tcgetpgrp(1) really
> > returns parent su pid, it is 872, parent su process
> > then suspends itself until login shell unsuspends it,
> > when it resumes, I have inserted another tcgetpgrp(1) after it resumes,
> > and found that it was 873, it was child su process pid! not 872,
> > because parent su was not in foreground group, when it called tcsetpgrp(1, 872),
> > it got a SIGTTOU and suspended there, the SIGCONT was not sent out.
> > so the code's behaviour is not what the author's want, and all job
> > control gets weird. I suguest this job control assumption should be removed,
> > strange thing is why su calls fork()? why doesn't call directly execvl()?
> > I don't see su calls fork() in OpenBSD.
I compiled GNU sh-utils 1.16 with Redhat's PAM patch on -current. It works
well and does not seem to have the bugs w/ csh's suspend or kill -STOP $$
that I complained about earlier.
This means that either our su is broken, or the different way Redhat
has implemented it is managing to avoid a kernel bug of ours.
I've extracted Redhat's patch from the RPM to make it easier to get:
http://people.freebsd.org/~tjr/sh-utils-1.16-pam.patch
The patch applies cleanly to sh-utils-1.16 (find it on a GNU mirror),
and su gets built - the build process dies at `test'.
The key differences with our implementation seem to be that they block
all allowed signals except SIGALRM and SIGTERM with sigprocmask() after the
fork on the parent side (race?), and they don't mess around with
tc[gs]etpgrp().
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
make warning at /usr/ports/Mk/bsd.port.mk
make warning "/usr/ports/Mk/bsd.port.mk", line 2580: warning: duplicate script for target "patch-message" ignored breaks portupgrade of several ports portupgrade says that Makefile broken on these ports (I'm not subscribed to freebsd-ports so reply direct, please) Sincerely, Maxim M. Kazachek mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Sun, Aug 11, 2002 at 22:53:15 -0700, David Xu wrote: > following is patch for su, I can type "suspend" and stop $$ without the > problem you described, I have tested it under tcsh and bash, all works > for me. > Thanx, committed. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
Tim Robbins wrote: > I compiled GNU sh-utils 1.16 with Redhat's PAM patch on -current. It works > well and does not seem to have the bugs w/ csh's suspend or kill -STOP $$ > that I complained about earlier. > > This means that either our su is broken, or the different way Redhat > has implemented it is managing to avoid a kernel bug of ours. Obviously it's different, if it behaves differently. The issue is whether or not a kernel change in signal handling means that the su code that has been in FreeBSD for many years is now "magically" no longer the right way to do things. The effects not only the su code itself, but any code out there that anyone has written, which is either derived from the old su code, or modelled on the way the old code has done things. It's all well and good to work around a kernel bug by changing user space code, but working around it by changing the user space code *hardly* fixes the underlying bug, which will just sit there waiting to bite the next poor unsuspecting slob on the arse. > The key differences with our implementation seem to be that they block > all allowed signals except SIGALRM and SIGTERM with sigprocmask() after the > fork on the parent side (race?), and they don't mess around with > tc[gs]etpgrp(). It should not be required that you do this. It's pretty obvious what is happening, if blocking the signals works around the problem: signal delivery requires a stall barrier until after the fork inheritance has been cleaned up. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
"Andrey A. Chernov" wrote: > On Sun, Aug 11, 2002 at 22:53:15 -0700, David Xu wrote: > > following is patch for su, I can type "suspend" and stop $$ without the > > problem you described, I have tested it under tcsh and bash, all works > > for me. > > Thanx, committed. UGH! #1 License on patch is GPL #2 I guess now that this irritant is gone, the signals code will remain screwed up, until some time later when you see the shark fin above water, just before it bites someone else? Saying "Don't walk there" doesn't dig up and disarm the landmine. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Mon, Aug 12, 2002 at 04:03:31 -0700, Terry Lambert wrote: > "Andrey A. Chernov" wrote: > > On Sun, Aug 11, 2002 at 22:53:15 -0700, David Xu wrote: > > > following is patch for su, I can type "suspend" and stop $$ without the > > > problem you described, I have tested it under tcsh and bash, all works > > > for me. > > > > Thanx, committed. > > UGH! > > #1License on patch is GPL Why not Microsoft? > #2I guess now that this irritant is gone, the signals code > will remain screwed up, until some time later when you > see the shark fin above water, just before it bites > someone else? > Read commit message 2 or 3 times. Meditate on each word. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is anyone else having trouble with dump(8) on -current?
On Sun, 11 Aug 2002, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Bruce Evans writes:
> >
> >I don't know how open() of a disk device can be interrupted by a signal
> >in practice. Most disk operations don't check for signals.
>
> Does the PCATCH tsleep in diskopen() that I mentioned seem a likely
> candidate?
Yikes. I didn't notice this or that you mentioned it.
> Anyway, below is a simple program that reproduces the
> EINTR error fairly reliably for me when run on disk devices.
>
> #include
> #include
> #include
> #include
> #include
>
> void
> handler(int sig) {
> }
>
> int
> main(int argc, char **argv)
> {
> int fd, i;
> if (argc < 2)
> errx(1, "Usage: %s device", argv[0]);
> fork();
> fork();
> fork();
> fork();
>
> signal(SIGUSR1, handler);
> sleep(1);
>
> for (i = 0; i < 200; i++) {
> killpg(0, SIGUSR1);
> if ((fd = open(argv[1], O_RDONLY)) < 0)
> err(1, "%s", argv[1]);
> close(fd);
> }
> return 0;
> }
This works reliably because the first open takes a relatively long time
to do physical i/o's to probe the MBR, etc. The other opens wait
interruptibly for the first, so there is a large window for killing them.
I just saw a reply from the original (?) author of the PR. Apparently
dump gets killed by amanda. Does amanda actually kill its children
enough to matter?
The primary bug seems to be that open() returns EINTR despite SA_RESTART
being set. POSIX.1-200x-draft7 seems to say that SA_RESTART affects
_all_ syscalls that can return EINTR except as explicitly noted.
This is not explicitly noted for open(), but there don't seem to be
enough explicit notes -- I could only find one for [p]select().
In POSIX, SA_RESTART's effect on select() and poll() is
implementation-defined and required, respectively, but in FreeBSD
SA_RESTART affects neither and many applications depend on this for
select() at least
POSIX's restarting of syscalls seems to be hard to implement. POSIX
requires restarting at the point where the interrupt was received, but
FreeBSD unwinds all the way back to syscall() for delivering the signal
and then restarts from there. The FreeBSD implementation only works
for simple syscalls. Note that the most important cases of read()
write are not easy to restart from syscall() in general, but we avoid
problems by only restarting them if they haven't done any i/o. This
is POSIX conformant since we don't return EINTR if they did any i/o,
and POSIX explicitly permits this behaviour although it is inconvienient
for applications (applications still have to deal with short i/o's).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
100% reproducable hang: serial related
Hi, [bde cc'd - it seems to be sio related] I have an i386 toshiba laptop, running FreeBSD 5.0-CURRENT #4: Sat Aug 10 13:27:55 BST 2002. I can get a 100% reproducible hang by doing the following: - Connect a serial cable between my laptop and a PC - run "tip -9600 com1" (where com1 in /etc/remote is the default: "com1:dv=/dev/cuaa0:br#9600:pa=none:") - power down the PC. My laptop hangs solid, and DDB cannot be entered from the keyboard. Note that if I close tip before powering down the PC, i don't get a hang. I am not using ACPI. Interestingly, if I type something and then power up the PC again, that character will echo on the screen before locking up again. By power-cycling the PC frequently, i could actually carry on using my laptop. Power cycling the PC (either on->off or off->on) seems to unlock the laptop for a fraction of a second. I can also hold ctrl-alt-escape on my laptop, and power up or down the PC, which will drop my laptop into DDB. From that point on, ddb works fine, continuing back to userspace works fine, and my laptop is no longer hung. Note however that often, from this point on until I quit tip, all characters I send seem to be sent as uppercase. Is it possible that the serial driver is getting confused, and the entry into DDB is causing the hardware and/or some lock to be reset? Can I get any other information to help diagnose this problem? while in DDB during the hang, a show locks gives: exclusive sleep mutex Giant r=0 (0xc0389d60) locked @ /usr/src/sys/kern/kern_intr.c:535 though I guess this is due to the keyboard event interrupt. As this is 100% reproducible, i am able to test anything people want testing. Thanks, Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
build picobsd bridge fail in locore.s
Can someone help me, I want to build a picobsd floppy. Command: release/picobsd/build/picobsd bridge Error: suffix or operands invalid for 'shr' I think the complain is about the fillkptphys(prot) macro in sys/i386/i386/locore.s I cvsuped current yesterday I havent build picobsd in 5.0 before -- Mauritz Sundell, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is anyone else having trouble with dump(8) on -current?
On Mon, Aug 12, 2002 at 10:16:56PM +1000, Bruce Evans wrote: [snip] > > I just saw a reply from the original (?) author of the PR. Apparently > dump gets killed by amanda. Does amanda actually kill its children > enough to matter? >From my experience/use with amanda I know that it _always_ kills the dumps that it starts when doing its estimates at the beginning (often several per file system, one for each dump level it's interested in). I don't think it deliberately kills the dumps when actually dumping the data. :-) [snip] Bob -- Bob WillcoxWe seem to have forgotten the simple truth that [EMAIL PROTECTED] reason is never perfect. Only non-sense attains Austin, TX perfection. -- Poul Henningsen [1894-1967] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 100% reproducable hang: serial related
On Mon, Aug 12, 2002 at 01:23:06PM +0100, Gavin Atkinson wrote: > > Hi, > [bde cc'd - it seems to be sio related] > > I have an i386 toshiba laptop, running FreeBSD 5.0-CURRENT #4: Sat Aug 10 > 13:27:55 BST 2002. I can get a 100% reproducible hang by doing the > following: > > - Connect a serial cable between my laptop and a PC > - run "tip -9600 com1" >(where com1 in /etc/remote is the default: > "com1:dv=/dev/cuaa0:br#9600:pa=none:") > - power down the PC. > > My laptop hangs solid, and DDB cannot be entered from the keyboard. Note > that if I close tip before powering down the PC, i don't get a hang. I am > not using ACPI. > > Interestingly, if I type something and then power up the PC again, that > character will echo on the screen before locking up again. By > power-cycling the PC frequently, i could actually carry on using my > laptop. Power cycling the PC (either on->off or off->on) seems to unlock > the laptop for a fraction of a second. > i have similar symptoms on my toshiba tecra 8000 under -stable ever since i installed fbsd on it (~4.1 i think), fbsd freezes when whatever terminal emulation (tip, cu , minicom) is still running when the remote side is powered down or the serial line is disconnected. but when the remote side (pc, router, ...) is powered on or the serial line is connected again fbsd unfreezes and continues to work. i had the "unlocks the laptop for a fraction of a second" just once when the remote side was an amiga 500... imho this is enirely related to (some) toshiba serial interfaces, at least i haven't seen this behaviour on other pcs running fbsd so far To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Interrupt vs. polling on -current
On Sun, 11 Aug 2002, Maksim Yevmenkin wrote: > On Fri, 9 Aug 2002, Maksim Yevmenkin wrote: > > > > OS: FreeBSD-current DP1 (dmesg attached) > > > Laptop: Toshiba Tecra 8100 (docked) > > > Hardware: 3Com Bluetooth USB dongle, 3Com Bluetooth PC-CARD > > > Xircom CBT PC-CARD (with 16550A UART) > > > > > > First of all, irq 11 gets shared between PC-CARD controller, > > > USB controller, NIC in docking station (see dmesg). Everything > > > This configuration should be expected to work poorly at best. > > hmmm... i have a couple of latops here at home, one made by > Toshiba and another by IBM and they both have similar configuration. > may be such configuration is normal for laptops? Unfortunately it seems to be fairly normal. Warner knows a lot more about this than me (see his reply). I don't even have a laptop. I expect this problem will be "fixed" by doing more polling for USB devices in a more automatic way. I hoped that more irqs would be standard by now, but instead they seem to be standard on xaly on big SMP systems that don't need them so much. It's systems with lots of interactive and/or real-time deives that need them more. > > > The Xircom card just does not work :( I' getting a lot of > > > "silo overflow" messages no matter what i try. I checked > > > list archives and source - not much look. Is "sio" driver > > > totally hopeless? > > > > No, but the 3Com driver apparently is. The sio driver wants to have > > fast interrupts. It can't have them with the irq is shared, so its > > worst-case interrupt latency for a single serial port is increased > > from about 50 usec to many msec, depending other interrupt activity > > in the system (not limited to that for the shared irq except in some > > configurations). Silo overflows occur at 115200 bps when the latency > > is more than about 1.5 msec. > > perhaps, i said it wrong. I only plug *one* PC-CARD at a time, so > it only 3com *or* Xircom. So irq11 gets shared between USB, NIC in > docking station, PC-CARD controller and Xircom card. That should help a bit. There is still the software problem that the irq wiring for attached devices doesn't change when some devices using the interrupt are detached, so the sio interrupt probably remains shared and non-fast so sio interrupt handling is often delayed by other interrupt activity (if any). Hmmm, there is always some interrupt activity for clocks. Perhaps the largest source of latency is that timeouts have (or not so temporarily borrow) too high a priority in -current. > BTW, i see "silo overflow" messages when i run ppp via null-modem > cable. in this configuration i'm using serial port 0 which is on > board and hase irq 4 with fast interrupts. What else is active when you get these? > > This points to bug(s) in the 3Com driver. Perhaps its interrupt > > handler just runs for too long to determine that irq11's for the > > serial device are not for it. Running in polled mode decreases > > yes, and that is what i was thinking too. but now i think it is > not only 3com driver's fault. The driver just reads one port and > check one bit, if it not set then interrupt is not for it. Yes, this shows that it is not primarily the 3Com driver's fault. > > > I just can't believe that > > > FreeBSD on my Pentium-III/600 can't handle lousy 500-700 > > > interrupts a second from PC-CARD. Can anyone point me > > > into right direction, because i'm obviously doing something > > > wrong here. > > > > FreeBSD on a 486/33 can handle about 4 serial interrupts per second > > to do one character of i/o per interrupt). Pessimizations in -current > > have only degraded this by a small factor (2?), provided the driver > > uses fast interrupts. Lose another small factor (2?) for normal interrupts > > (using normal interrupts only loses a large factor for latency). > > if my calculations are correct -current should handle about 10,000 > interrupt/sec from sio, right? i'm sorry, but it is not what i see > here. That's 1 on a 486/33 :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rmuser.c - Updated source
Hello, I sent a mail about this program with a source a couple of days ago, not really
pretty code, cleaned it up and gotten some help from #bsdcode@EFnet with some fixes.
So I send the source again so you could take another look at it and tell me if I am
missing something.
--
Eirik Nygaard <[EMAIL PROTECTED]>
Http://kverka.org/~eirik/
PGP Key: 83C55EDE
/*
* Copyright 2002 Eirik Nygaard.
* 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 as
*the first lines of this file unmodified.
* 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.
* 3. The name of the author may not be used to endorse or promote products
*derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY EIRIK NYGAARD ``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 GUY HELMER 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.
*
* rmuser - C programme to remove users
*
* Eirik Nygaard <[EMAIL PROTECTED]>, 08/08/02
*
*/
#include
__FBSDID("$FreeBSD$");
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
charpasswd_file[] = "/etc/master.passwd";
charpasswd_tmp[PATH_MAX] = "/etc/ptmp.X";
char*passwd_tmp2;
chargroup_file[] = "/etc/group";
charnew_group_file[] = "/etc/group.new";
charmail_dir[] = "/var/mail";
charcrontab_dir[] = "/var/cron/tabs";
charpath[] = "/bin:/sbin:/usr/bin:/usr/sbin";
int yes;/* Always yes? */
int removehomedir = 1;
char*user = NULL; /* User to delete */
charuser2[BUFSIZ];
charanswer[BUFSIZ];
int fp;
FILE*fp2;
charline[PATH_MAX + 50];
charhomedir[PATH_MAX];
struct passwd *password;
struct stat sb;
voidusage();
voidgetuser();
voidremove_files_from_dir(int uid, char *path);
int recvnl( char *buf, int fd);
voidupdate_passwd();
voidupdate_group();
voidkilluser(int uid, int gid);
voiddel_mail();
voidsighandle(int sig);
int main(int argc, char **argv)
{
int ch, numbuf = 0;
/* Check for root */
if (getuid() != 0) {
errx(EX_NOPERM, "You must be root to run this program.");
}
signal(SIGINT, sighandle);
signal(SIGTERM, sighandle);
signal(SIGHUP, sighandle);
signal(SIGQUIT, sighandle);
/* Set the path we need */
setenv("PATH", path, 1);
/* Set umode */
umask(022);
/* Get command line arguments */
while ((ch = getopt(argc, argv, "yu:")) != -1) {
switch (ch) {
case 'y':
yes = 1;
break;
case 'u':
user = optarg;
break;
case '?':
default:
usage();
}
}
if (user == NULL) {
getuser();
}
if ((password = getpwnam(user)) == NULL) {
errx(EX_NOUSER, "No user found by that name: %s.\n", user);
}
printf("\nMatching password entry: \n");
printf("\t%s:%s:%d:%d:%s:%s\n", password->pw_name, password->pw_passwd,
password->pw_uid, password->pw_gid, password->pw_dir, password->pw_shell);
if (yes == 0) {
printf("Is this the entry you wish to remove?(y/n) ");
fgets(answer, sizeof(answer), stdin);
if (strncmp(answer, "y", 1) != 0 && strncmp(answer, "Y", 1) != 0) {
printf("User %s not removed.\n", user);
exit(1);
}
}
if ((password =
Re: sendfile(2) is broken (Was: ftpd problem: Input/output error)
On Mon, 12 Aug 2002, Maxim Konovalov wrote:
> On 03:37+0700, Aug 12, 2002, Semen A. Ustimenko wrote:
> > David reviewed the patch and I have committed it few minutes ago.
>
> Looks like a hack BDE is speaking about: passing a storage for residue
> but never check it.
See another reply about this.
> Anyway I don't understand why VOP_READ in vn_rdwr() returns a residue
> in uio.uio_resid when all data trasferred actually?
It actually does this when only some (or none) of the data has been
transferred. The idea is that most layers don't interpret the residual;
they just pass it up to the caller and it hopefully makes it all the
way up to a top level which actually understands nonzero residuals.
>From vfs_vnops.c:
% if (aresid != NULL)
% *aresid = auio.uio_resid;
This is hopefully the usual case. We just return the residual without
looking at it if we can.
% else
% if (auio.uio_resid != 0 && error == 0)
% error = EIO;
Otherwise, we turn nonzero residuals into errors since there is no other
way to tell the caller that not all the data was transferred.
BTW, the residual handling code for the read() and write family seems to
have been broken since the beginning of history. From sys_generic.c:
% if ((error = fo_read(fp, &auio, fp->f_cred, flags, td))) {
% if (auio.uio_resid != cnt && (error == ERESTART ||
% error == EINTR || error == EWOULDBLOCK))
% error = 0;
% }
This is sort of the reverse of the conversion of `error' in vn_rdwr().
Some (most or all?) i/o routines return useful values in both uio_resid
and `error'. This only matters if there is both an error and a nonzero
residual (which is the usual case if an error occurs in the middle of
a transfer). Both of these values should be passed up as far as possible,
but there is no way to pass both across the kernel/userland boundary. We
must choose one, and I think it is best to pass the residual (inverted to
be a count) in all cases. POSIX requires this for read() and write() anyway.
The above only does this conversion if the error is one of ERESTART, EINTR
and EWOULDBLOCK. I think the correct code (modulo optimizations) is:
error = fo_read(...);
if (auio.uio_resid != cnt)
error = 0;
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Mon, 12 Aug 2002, Andrey A. Chernov wrote: > On Mon, Aug 12, 2002 at 04:03:31 -0700, Terry Lambert wrote: > > "Andrey A. Chernov" wrote: > > > On Sun, Aug 11, 2002 at 22:53:15 -0700, David Xu wrote: > > > > following is patch for su, I can type "suspend" and stop $$ without the > > > > problem you described, I have tested it under tcsh and bash, all works > > > > for me. > > > > > > Thanx, committed. > > > > UGH! > > > > #1 License on patch is GPL > > Why not Microsoft? > > > #2 I guess now that this irritant is gone, the signals code > > will remain screwed up, until some time later when you > > see the shark fin above water, just before it bites > > someone else? > > Read commit message 2 or 3 times. Meditate on each word. Anyway, it has one blatant style bug (not 1TBS) and no explanation of the bug, so it should not have been committed verbatim. See another reply for an analysis of the patch. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Tue, Aug 13, 2002 at 03:15:02 +1000, Bruce Evans wrote: > > Anyway, it has one blatant style bug (not 1TBS) and no explanation of > the bug, so it should not have been committed verbatim. See another > reply for an analysis of the patch. According to commit guide, explanations are not commited, only what is changed. For explanation (terminal group mismatch) read whole thread, especially David's analysis. What another reply you mean? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Interrupt vs. polling on -current
"M. Warner Losh" wrote: > > [[ I've read the rest of this thread ]] > > In message: <[EMAIL PROTECTED]> > Maksim Yevmenkin <[EMAIL PROTECTED]> writes: > : My tests are very simple. I plug USB dongle and one PC-CARD > : and try to pump data between them as fast as possible. The > : data blocks sizes are between 63 and 1500 bytes. > > I think that the issue here may be that the USB stack may be > interacting badly with the interrupt system. Since the pccard is > effectively forced into sharing the interrupt with the USB stack with > NEWCARD, that's going to interact very badly, I think. Worse even > than if you were multiplexing the xl0 driver and the sio0 driver. you may be right. i have "uhci" USB controller (i think it is Intel spec.). If i'm not mistaken this chip is not very smart, and every time interrupt happens software must scan queue of pending requests to find out which one has been completed. But of course "uhci" chip is very cheap :) On the other hand there is a "ohci" (Microsoft i think) and this chip is better because it does more processing, and, of course costs more. > The sio driver is extremely sensitive to the interrupt latency, since > the underlying hardware has only a few characters to react before the > fifo overflows. At 115200 baud, each character takes 1/11520 seconds > (or 86us), and the fifo is set to have only 8 bytes left when the > device interrupts. This means that the sio driver can only tolerate > about 700us of latency before there are issues. With 500 interrupts > per second, that's an interrupt every 2000us, which is about the same > "order" as the maximum latency tolerance. If these interrupts are > shared and are taking a while to allow the serial driver to run, then > you are almost certain to cause problems. Xircom card is a Bluetooth card with UART interface. Bluetooth link speed is about 700KB/s. I do not think that standard 16550A UART with 16 bytes FIFO can handle such speed. I also can not believe that Xircom would sell such low speed Bluetooth card (115200 bit/s). I think that Xircom card must have a much bigger FIFO in order to handle full speed. W2K, for example, has special driver for Xircom card. > For cardbus cards, we're forced to use the pci interrupt and share it. > For "r2" cards (aka 16-bit cards), we could use an unused ISA > interrupt on most (but not all) cardbus bridges, but currently there's > no support for that in NEWCARD. that is what i see in W2K. all cards i plug into slots get different irq. PC-CARD controller and USB controller are still share irq 11. > I'm also surprised you were able to make it work at all. I've had > lots of bad luck when trying to make modems work in recent -current > kernels. that is very sad :( thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
i386 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Mon Aug 12 09:36:17 PDT 2002 -- >>> Kernel build for GENERIC completed on Mon Aug 12 10:18:18 PDT 2002 -- >>> Kernel build for LINT started on Mon Aug 12 10:18:18 PDT 2002 -- ===> xe /local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:480: warning: no previous prototype for `AcpiDbDecodeNode' /local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:131: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbexec.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbhistry.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbinput.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbstats.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbxface.c:127: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/hwgpe.c:122: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/nsxfname.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/nsxfobj.c:126: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/rsdump.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utclib.c:129: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utdebug.c:122: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:489: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:527: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:604: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:607: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/acpica/acpi_acad.c:50: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_cmbat.c:56: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:274: warning: `acpi_pwr_deregister_consumer' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:212: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /local0/scratch/des/src/sys/dev/ata/atapi-cam.c: In function `cam_rescan': /local0/scratch/des/src/sys/dev/ata/atapi-cam.c:615: warning: passing arg 1 of `xpt_print_path' makes pointer from integer without a cast *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/LINT. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Interrupt vs. polling on -current
Bruce Evans wrote: > > On Sun, 11 Aug 2002, Maksim Yevmenkin wrote: > > > On Fri, 9 Aug 2002, Maksim Yevmenkin wrote: > > [...] > > BTW, i see "silo overflow" messages when i run ppp via null-modem > > cable. in this configuration i'm using serial port 0 which is on > > board and hase irq 4 with fast interrupts. > > What else is active when you get these? not much: X, user space ppp and i'm doing moderate size transfers via ftp between my current laptop and FreeBSD 4.5 desktop. i also see these errors while cvsup'ing my -current laptop. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Sun, 11 Aug 2002, David Xu wrote:
> following is patch for su, I can type "suspend" and stop $$ without the
> problem you described, I have tested it under tcsh and bash, all works
> for me.
>
> --- su.c Mon Aug 12 13:08:01 2002
> +++ su.c.new Mon Aug 12 13:16:14 2002
> @@ -329,10 +329,13 @@
> default:
> while ((ret_pid = waitpid(child_pid, &statusp, WUNTRACED)) != -1) {
> if (WIFSTOPPED(statusp)) {
> - child_pgrp = tcgetpgrp(1);
> kill(getpid(), SIGSTOP);
> - tcsetpgrp(1, child_pgrp);
> - kill(child_pid, SIGCONT);
> + child_pgrp = getpgid(child_pid);
> + if (tcgetpgrp(1) == getpgrp())
> + {
> + tcsetpgrp(1, child_pgrp);
> + kill(child_pid, SIGCONT);
> + }
> statusp = 1;
> continue;
> }
Explanation of this patch:
(1) su has shot itself in the foot using PAM. Normally the parent shell
waits for children and handles them when they stop. The extra process
for PAM is now in between the parent shell and the su shell, so the
parent shell can't do this directly. The above code attempts to
relay some aspects of job control back to the parent shell. It is
not clear that it can do this properly without duplicating lots of
shell specific job control, but I think it can do this in principle.
There are related problems for propagation of SIGHUP to indirect
descendants of login shells when the shell exits. Here there is
at least there is an intermediate process that can relay the signals
if necessary. I think propagation of SIGHUP is automatic if the
intermediate process doesn't exit first and it doesn't change its
job control stuff too much, so the SIGHUP problem doesn't affect
PAMmed applications.
(2) To relay SIGSTOP, the intermediate su just needs stop itself. To
relay SIGCONT, the intermediate su needs to switch to enough of
its child's job control environment before starting the child.
Switching only fd 1's process group seems to be sufficient, but
it is not easy to determine even that and the broken version got
it wrong.
The child's environment is very shell-dependent. Some of the following
may depend on the initial shell being bash:
(a) sh, csh and bash start a new process group (equal to their pid).
zsh stays in the process group of the intermediate su process.
(b) "kill -STOP $$ ... fg" worked in most (all?) cases because
fd 1's pgrp is still the child's pgid when the child is killed
in that way. For zsh the child's pgid is the same as the
intermediate shell's so the pgrps can't be different, and for
the other shells I think the pgrp hasn't been changed because
the child can'tcontrol it (SIGSTOP is uncatchable) and the
kernel doesn't. Later, switching fd 1's pgrp back to the
child's pgid works except possbly for zsh because it is correct
and different.
(c) "suspend ... fg" failed for several reasons. First, something
(presumably the child) sets fd 1's pgrp to the intermediate
su's pgid, so tcgetpgrp(1) gives a wrong pgrp for restoring
later. The patch fixes this by not getting the pgrp in this
way. It uses getpgid(child_pid) instead. I think this works
for at least normal shells. Second when the pgrp is restored,
something (presumably the shell above the intermediate su, or
the kernel) has already switched fd 1's pgrp to child's pgid
instead of to the intermediate su's pgid (despite the intermediate
su's being correct at SIGSTOP time for suspend but not for
kill -STOP). Setting fd 1's pgrp to the value that it alread
has is then fatal for reasons that I don't completely understand
yet. The patch avoids the problem by not doing apparently-null
tcsetpgrp()'s. Sending the SIGCONT seems to have no affect in
this case, so I think shell above the su's has already started
both the child su and the intermediate one and this isn't a
problem until the su's get in each other's way. Putting printfs
in the above code seems to make the problem easier to debug by
ensuring that they get in each other's way :-).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Mon, 12 Aug 2002, Andrey A. Chernov wrote: > On Tue, Aug 13, 2002 at 03:15:02 +1000, Bruce Evans wrote: > > > > Anyway, it has one blatant style bug (not 1TBS) and no explanation of > > the bug, so it should not have been committed verbatim. See another > > reply for an analysis of the patch. > > According to commit guide, explanations are not commited, only what is > changed. For explanation (terminal group mismatch) read whole thread, > especially David's analysis. The analysis in the thread seems to be incomplete. > What another reply you mean? I just wrote one :-). Rereading earlier analysis just gave me a hint about tcsetpgrp() to the same value causes problems: it causes an unexpected SIGTTOU because a background process attemps to do something (TIOCSPGRP) that can only be done in the foreground (the background process is forced to wait until it gets to the foreground, and it doesn't help for the change to be null since the process must be in the foreground to even check for null changes). Presumably the child su is in the foreground at that point. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Interrupt vs. polling on -current
On Mon, 12 Aug 2002, Maksim Yevmenkin wrote: > Bruce Evans wrote: > > > > On Sun, 11 Aug 2002, Maksim Yevmenkin wrote: > [...] > > > > BTW, i see "silo overflow" messages when i run ppp via null-modem > > > cable. in this configuration i'm using serial port 0 which is on > > > board and hase irq 4 with fast interrupts. > > > > What else is active when you get these? > > not much: X, user space ppp and i'm doing moderate size transfers > via ftp between my current laptop and FreeBSD 4.5 desktop. i also > see these errors while cvsup'ing my -current laptop. Some graphics cards can cause sio problems, by using too bus cycles so that sio doesn't get even an average of about 5 i/o cycles per character time that it needs to function. 5 might sound like not many, but it is 5 isa cycles so it takes 6 usec every 87 usec at 115200 bps. 20 devices wanting that much of the bus just won't work. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Mon, Aug 12, 2002 at 09:21:31PM +0400, Andrey A. Chernov wrote: > On Tue, Aug 13, 2002 at 03:15:02 +1000, Bruce Evans wrote: > > > > Anyway, it has one blatant style bug (not 1TBS) and no explanation of > > the bug, so it should not have been committed verbatim. See another > > reply for an analysis of the patch. > > According to commit guide, explanations are not commited, only what is > changed. For explanation (terminal group mismatch) read whole thread, > especially David's analysis. Wrong Andrey. For hairy code, there should be comments -- especially if one must realize someone obtuse to understand how the code works. 6mo. from now no one will be able to find the explanation in a mailing list. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pkg-comment
On Sun, Aug 11, 2002 at 12:23:19PM -0700, Eric Melville wrote: > > Since pkg-comment contains only a single line, wouldn't it be more subtile > > to put it in a COMMENT field as does NetBSD, instead of using a file? I think > > it would speed up updates. > > http://people.FreeBSD.org/~eric/ports-comment.diff > > Will Andrews said that portmgr would be going over this sometime soon, > hopefully they will commit it. That will certainly be a big help. When we got rid of the pkg/ and patches/ directories I begged Satoshi to go farther and put patches in main port directory and get rid of pkg/COMMENT. That was back when we hit 3000 ports -- I guess people didn't want to accept we would hit 8000 in only a few years. Of course why we don't just put "COMMENT=blah" in the ports's Makefile To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Hey, whats up?
My buddies and I were average people, just like you...Then we had our great idea...find young hot girls and proposition them to fool around on video tape.Armed with a camera, a smooth tongue, and a couple of bucks we have made quite a few interesting videos!BEST OF ALL... MY SITE IS 100% FREE!! If this sounds like something of interest to you, http:[EMAIL PROTECTED]";>click here You will be glad you did. If you never want to hear from me again, please click here and I will remove you from all future mailings. - Get your free WebMail account from Sympatico-Lycos at www.sympatico.ca - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weirdness trying -STABLE -> -CURRENT
On Sun, Aug 11, 2002 at 09:41:19PM +0200, Szilveszter Adam wrote: > This is known problem, straight updates by simply "make world" do not > work from -STABLE. Therefore, one has to very carefully follow the > procedure described in the UPDATING file even though normally not so > many steps would be needed. Uh... did you actually READ all that text you snipped out? David *DID* follow the correct steps -- please go back and read what he did: cvs up make buildworld make buildkernel create /boot/device.hints make install kernel *** reboot make install world. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Hey, whats up?
My buddies and I were average people, just like you...Then we had our great idea...find young hot girls and proposition them to fool around on video tape.Armed with a camera, a smooth tongue, and a couple of bucks we have made quite a few interesting videos!BEST OF ALL... MY SITE IS 100% FREE!! If this sounds like something of interest to you, http:[EMAIL PROTECTED]";>click here You will be glad you did. If you never want to hear from me again, please click here and I will remove you from all future mailings. - Get your free WebMail account from Sympatico-Lycos at www.sympatico.ca - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weirdness trying -STABLE -> -CURRENT
On Mon, Aug 12, 2002 at 12:41:19PM -0700, David O'Brien wrote: > On Sun, Aug 11, 2002 at 09:41:19PM +0200, Szilveszter Adam wrote: > > This is known problem, straight updates by simply "make world" do not > > work from -STABLE. Therefore, one has to very carefully follow the > > procedure described in the UPDATING file even though normally not so > > many steps would be needed. > > Uh... did you actually READ all that text you snipped out? David *DID* > follow the correct steps -- please go back and read what he did: Did you actually read my second message in this thread? It was sent only a short time after the first one. (and no need to shout I am sitting close to the monitor & keys) Since David has not yet gotten back to us I have no more ideas since that second posting. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
xdm-Problems with PAM
Hi, I set up xdm on my -current machine last Saturday and have the same problems still with todays (12.Aug) -current: When I try to login with 'xdm', the following errors come up: Aug 12 18:20:02 current : unable to dlopen(/usr/lib/pam_nologin.so) Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_nologin.so: Undefined \ symbol "_pam_verbose_error"] Aug 12 18:20:02 current : adding faulty module: /usr/lib/pam_nologin.so Aug 12 18:20:02 current : unable to dlopen(/usr/lib/pam_unix.so) Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_unix.so: Undefined \ symbol "_pam_verbose_error"] Aug 12 18:20:02 current : adding faulty module: /usr/lib/pam_unix.so Aug 12 18:20:02 current : unable to dlopen(/usr/lib/pam_opie.so) Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_opie.so: Undefined \ symbol "_openpam_log"] Aug 12 18:20:02 current : adding faulty module: /usr/lib/pam_opie.so Aug 12 18:20:02 current : unable to dlopen(/usr/lib/pam_opieaccess.so) Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_opieaccess.so: \ Undefined symbol "_pam_verbose_error"] Aug 12 18:20:02 current : adding faulty module: \ /usr/lib/pam_opieaccess.so Aug 12 18:20:02 current : unable to dlopen(/usr/lib/pam_lastlog.so) Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_lastlog.so: Undefined symbol "_openpam_log"] Aug 12 18:20:02 current : adding faulty module: /usr/lib/pam_lastlog.so 'Known behaviour' or real problems? -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) Powered by FreeBSD 4.6-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is anyone else having trouble with dump(8) on -current?
On Mon, 12 Aug 2002, Bob Willcox wrote: > On Mon, Aug 12, 2002 at 10:16:56PM +1000, Bruce Evans wrote: > > [snip] > > > I just saw a reply from the original (?) author of the PR. Apparently > > dump gets killed by amanda. Does amanda actually kill its children > > enough to matter? > > >From my experience/use with amanda I know that it _always_ kills the > dumps that it starts when doing its estimates at the beginning (often > several per file system, one for each dump level it's interested in). I > don't think it deliberately kills the dumps when actually dumping the > data. :-) So the problem seems to be mainly that dump expects all syscalls to be restarted after it catches these signals, and open() isn't restarted. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pkg-comment
hi, there!
On Mon, Aug 12, 2002 at 12:36:51PM -0700, David O'Brien wrote:
> > > Since pkg-comment contains only a single line, wouldn't it be more subtile
> > > to put it in a COMMENT field as does NetBSD, instead of using a file? I think
> > > it would speed up updates.
> >
> > http://people.FreeBSD.org/~eric/ports-comment.diff
> >
> > Will Andrews said that portmgr would be going over this sometime soon,
> > hopefully they will commit it.
>
> That will certainly be a big help. When we got rid of the pkg/ and
> patches/ directories I begged Satoshi to go farther and put patches in
> main port directory and get rid of pkg/COMMENT. That was back when we
> hit 3000 ports -- I guess people didn't want to accept we would hit 8000
> in only a few years.
>
> Of course why we don't just put "COMMENT=blah" in the ports's Makefile
Posted patch uses `head -1 ${DESCR}` however.
I'd prefer to go NetBSD way and use COMMENT=blah for ports comments
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Interrupt vs. polling on -current
On Mon, 12 Aug 2002, Maksim Yevmenkin wrote: > Xircom card is a Bluetooth card with UART interface. Bluetooth link > speed is about 700KB/s. I do not think that standard 16550A UART with > 16 bytes FIFO can handle such speed. I also can not believe that Xircom > would sell such low speed Bluetooth card (115200 bit/s). I think that > Xircom card must have a much bigger FIFO in order to handle full speed. > W2K, for example, has special driver for Xircom card. Big fifos for dumb hardware can also cause by problems by taking a long time to drain, thus increasing latency for other devices. "dumb hardware" here means almost anything that must be accessed in PIO mode. One of the main reasons why sio uses a fast interrupt handler was that such hardware was common 10-15 years ago (for pre-DMA IDE disks). In Linux the disk driver (sort of) used a fast interrupt handler too, and competition between these handlers caused many silo overflows. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Interrupt vs. polling on -current
Bruce Evans wrote: > > On Mon, 12 Aug 2002, Maksim Yevmenkin wrote: > > > Bruce Evans wrote: > > > > > > On Sun, 11 Aug 2002, Maksim Yevmenkin wrote: > > [...] > > > > > > BTW, i see "silo overflow" messages when i run ppp via null-modem > > > > cable. in this configuration i'm using serial port 0 which is on > > > > board and hase irq 4 with fast interrupts. > > > > > > What else is active when you get these? > > > > not much: X, user space ppp and i'm doing moderate size transfers > > via ftp between my current laptop and FreeBSD 4.5 desktop. i also > > see these errors while cvsup'ing my -current laptop. > > Some graphics cards can cause sio problems, by using too bus cycles so > that sio doesn't get even an average of about 5 i/o cycles per character > time that it needs to function. 5 might sound like not many, but it is > 5 isa cycles so it takes 6 usec every 87 usec at 115200 bps. 20 devices > wanting that much of the bus just won't work. WHOA! that scares the hell out of me. You sound like any hardware that uses interrupt/bus might hurt poor "sio" driver pretty badly. There is not much use in computer that has only CPU and serial port :) i'm not trying to blame anybody here, but rather understand what is wrong. BTW, i have s3 savage/mx and neomagic/av video cards in my laptops. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Dual AthlonMP and FreeBSD
Hi! Would FreeBSD (-current or -stable) work (in SMP mode) on a pair of Athlons, or is our SMP only for Intel chips? Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xdm-Problems with PAM
On Mon, Aug 12, 2002 at 10:19:00PM +0200, Matthias Schuendehuette wrote: > Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_lastlog.so: Undefined > symbol "_openpam_log"] > Aug 12 18:20:02 current : adding faulty module: /usr/lib/pam_lastlog.so > > 'Known behaviour' or real problems? I recompiled xdm and the problem went away - I'm not sure if I should have thought about the problem more carefully. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dual AthlonMP and FreeBSD
On Mon, Aug 12, 2002 at 04:55:03PM -0400, Mikhail Teterin wrote: > > Would FreeBSD (-current or -stable) work (in SMP mode) on a pair of > Athlons, or is our SMP only for Intel chips? Thanks! Dual Athlons work. They use the same programming interface as the Intel chips. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg41831/pgp0.pgp Description: PGP signature
Re: Is anyone else having trouble with dump(8) on -current?
Bruce Evans wrote: > > >From my experience/use with amanda I know that it _always_ kills the > > dumps that it starts when doing its estimates at the beginning (often > > several per file system, one for each dump level it's interested in). I > > don't think it deliberately kills the dumps when actually dumping the > > data. :-) > > So the problem seems to be mainly that dump expects all syscalls to be > restarted after it catches these signals, and open() isn't restarted. POSIX sucks... siginterrupt(3) is your friend, in this case. Unfortunately, someone broke it and added a "sig" parameter, and you have to call it once per signal now, which means enumerating signals on an unknown host system (brilliant engineering, that). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Tue, Aug 13, 2002 at 04:58:17 +1000, Bruce Evans wrote: > > Explanation of this patch: Thanx. Could you please commit this explanation, or some re-phrasing of it into su.c? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weirdness trying -STABLE -> -CURRENT
>Date: Sun, 11 Aug 2002 21:41:19 +0200
>From: Szilveszter Adam <[EMAIL PROTECTED]>
>First off, sorry for the lot of snippage but this mail was really
>long...
Yeah, it was; sorry. That's what I get for trying to be complete. :-)
I was able to re-do the steps, and evtually get to a point:
freebeast(5.0-C)[1] df
Filesystem 1K-blocks UsedAvail Capacity Mounted on
/dev/ad0s3a158767636208244644%/
devfs 110 100%/dev
/dev/ad0s3e 1873113 70 101326541%/usr
/dev/ad0s4h 27728233 11141233 1436874244%/common
/dev/ad0s4g 2032839 487508 138270426%/var
procfs 440 100%/proc
freebeast(5.0-C)[2] uname -a
FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Aug 12
15:34:30 PDT 2002
[EMAIL PROTECTED]:/common/S3/obj/usr/src/sys/FREEBEAST i386
freebeast(5.0-C)[3]
which I consider "success". (Well, assuming I can use the resulting
system to rebuild itself, anyway.)
In this last attempt, I still got shell dying a rather un-graceful
death, probably (still) as a result of a SIGSYS. The key difference
this time was that after this happened, I hit RESET on the machine, and
when it started to come up, I interrupted the process to boot
single-user mode, and inserted some extra steps (in pseudo-unidiff
format relative to present contents of the relevant section of UPDATING):
To upgrade from 4.x-stable to current
-
make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
cp src/sys/${MACHINE_ARCH}/conf/GENERIC.hints /boot/device.hints [2]
make installkernel KERNCONF=YOUR_KERNEL_HERE
reboot in single user [3]
mergemaster -p [5]
make installworld
+
+ reboot in single user [6]
+ make installworld
mergemaster [4]
[1]
...
+
+ [6] From the bootblocks, boot -s, and then do
+ fsck -p
+ reboot in single user [3]
I do not claim that this is optimal, or that the result will actually be
solid enough to survive a "make buildworld", but it seems to me that the
instructions in UPDATING for the "upgrade from 4.x-stable to current"
case are not adequate in and of themselves as they presently stand (at
least in soome cases, mine among them), so I offer the above as a
possible modification that might help some folks.
I will save my logs (typescripts, really) of what I did for a few days,
in case anyone would care to review them. Note that this amounts to
about 10 MB of data, before you ask to get a copy.
Thanks,
david (links to my resume at http://www.catwhisker.org/~david)
--
David H. Wolfskill [EMAIL PROTECTED]
To paraphrase David Hilbert, there can be no conflicts between Microsoft
and the discipline of systems administration, since they have nothing in
common.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
"Andrey A. Chernov" wrote: > > UGH! > > > > #1License on patch is GPL > > Why not Microsoft? I don't unserstand the question. Why not the same license that's areleady on the source code for "su"? > > #2I guess now that this irritant is gone, the signals code > > will remain screwed up, until some time later when you > > see the shark fin above water, just before it bites > > someone else? > > Read commit message 2 or 3 times. Meditate on each word. I did. It's still an order of operation problem in the kernel during fork(), as Bruce pointed out in a later posting (so me pointing it out here is probably redundant... 8-)). I still think other code is going to have the problem, too, so changing su alone doesn't fix things. Better to not deliver the tty output stopped signal. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
CAM-ATAPI status?
Hi, What's the status of the CAM/ATAPI integration? Is anyone thinking of working on it? When last mentioned, it was mooted that some work needed to be done to tidy things up. Since then, it's gone very quiet - specifically, I don't seem to recall seeing any specifics about what needed to be cleaned up. Some time later (what it is now, 6 months?), it's not in the tree, and I suspect that the happy ATAPI/CAM users are either applying patches locally to keep using this useful functionality, or bemoaning the fact that FreeBSD doesn't let them use cdrecord with ATAPI CD-Rs Whilst I appreciate the need for coding standards and good-quality code, (and indeed this is a large part of my personal reasons for choosing this OS), it seems to me that this has kind of slipped through the cracks. I've been using the CAM/ATAPI patches on -STABLE for some time now, and it Just Works - I've burned quite a lot of CD-R's and CD-RW's with my internal laptop drive and the latest 'cdrecord' from ports, and neither this nor anything else on the machine appears to suffer unduly. What I'd *really* like to see is for the CAM/ATAPI stuff to go into 4.7 - it seems to me that people choose the OS for stability, performance and, let's not forget, *features*, what you can actually /do/ with the machine. Regards, AS msg41836/pgp0.pgp Description: PGP signature
Re: CAM-ATAPI status?
On Mon, 12 Aug 2002, Andy Sparrow wrote: > Some time later (what it is now, 6 months?), it's not in the tree, and I > suspect that the happy ATAPI/CAM users are either applying patches > locally to keep using this useful functionality, or bemoaning the fact > that FreeBSD doesn't let them use cdrecord with ATAPI CD-Rs You'll be happy to tell them sys/dev/ata/atapi-cam.c: Revision 1.1 Fri Aug 9 20:51:53 2002 UTC (3 days, 3 hours ago) by sos Branch: MAIN Add the ability to use ATAPI devices via CAM. The CAM<>ATAPI layer was submitted by "Thomas Quinot <[EMAIL PROTECTED]>" changes form the version on the net by me (formatting, ability to be used alone without the ATAPI native device driver, proper speed reporting...) See /sys/conf/NOTES for usage. Submitted by: Thomas Quinot <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CAM-ATAPI status?
As I mentionned recently.. I think having it in the tree far outweighs having it NOT in the tree. THe first time this was brought up over a year ago it was said that the patches were not quite correct. It was also said they would be corrected "soon" or something.. Sonn has come an gone... if anyone can get me -current patches to do this I'll commit them now and they can be cleaned up later. that'll at least get them started on the path to 4.7... julian On Mon, 12 Aug 2002, Andy Sparrow wrote: > > Hi, > > What's the status of the CAM/ATAPI integration? Is anyone thinking of > working on it? > > When last mentioned, it was mooted that some work needed to be done to > tidy things up. Since then, it's gone very quiet - specifically, I don't > seem to recall seeing any specifics about what needed to be cleaned up. > > Some time later (what it is now, 6 months?), it's not in the tree, and I > suspect that the happy ATAPI/CAM users are either applying patches > locally to keep using this useful functionality, or bemoaning the fact > that FreeBSD doesn't let them use cdrecord with ATAPI CD-Rs > > Whilst I appreciate the need for coding standards and good-quality code, > (and indeed this is a large part of my personal reasons for choosing > this OS), it seems to me that this has kind of slipped through the > cracks. > > I've been using the CAM/ATAPI patches on -STABLE for some time now, and > it Just Works - I've burned quite a lot of CD-R's and CD-RW's with my > internal laptop drive and the latest 'cdrecord' from ports, and neither > this nor anything else on the machine appears to suffer unduly. > > What I'd *really* like to see is for the CAM/ATAPI stuff to go into 4.7 > - it seems to me that people choose the OS for stability, performance > and, let's not forget, *features*, what you can actually /do/ with the > machine. > > Regards, > > AS > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CAM-ATAPI status?
YIPE!!! I missed this message... On Mon, 12 Aug 2002, Nate Lawson wrote: > On Mon, 12 Aug 2002, Andy Sparrow wrote: > > Some time later (what it is now, 6 months?), it's not in the tree, and I > > suspect that the happy ATAPI/CAM users are either applying patches > > locally to keep using this useful functionality, or bemoaning the fact > > that FreeBSD doesn't let them use cdrecord with ATAPI CD-Rs > > You'll be happy to tell them sys/dev/ata/atapi-cam.c: > > Revision 1.1 > Fri Aug 9 20:51:53 2002 UTC (3 days, 3 hours ago) by sos > Branch: MAIN > > Add the ability to use ATAPI devices via CAM. > > The CAM<>ATAPI layer was submitted by "Thomas Quinot > <[EMAIL PROTECTED]>" > changes form the version on the net by me (formatting, ability to be used > alone without the ATAPI native device driver, proper speed reporting...) > > See /sys/conf/NOTES for usage. > > Submitted by: Thomas Quinot <[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: CAM-ATAPI status?
> You'll be happy to tell them sys/dev/ata/atapi-cam.c: > > Revision 1.1 > Fri Aug 9 20:51:53 2002 UTC (3 days, 3 hours ago) by sos > Branch: MAIN Well, golly... And with improvements too! In good time for an MFC for 4.7! Awesome, no, outstanding! Thanks to all concerned, I really am very happy to be wrong! :-) Regards, AS msg41840/pgp0.pgp Description: PGP signature
Re: usb MFC? [was: HEADS UP: FreeBSD 4.7 Code Freeze]
CC: -current since that's what I'm using, but keeping -stable as this was just MFC'd. On Mon, 2002-08-12 at 19:13, Bryan Liesner wrote: > > I would like to try the uvisor/ucom stuff just comitted, but don't have > a clue how to use it... Can you point me in the right direction? Has anyone managed to get ucom working with umodem? I have a USRobotics that works okay with umodem for dialing out, but I'd like to be able to dial in and get a shell (and getty isn't too happy with /dev/umodem0 it seems). So far all my attempts to get ucom to attach to it have been futile. Is this even possible? ucom(4) suggests it is, but the configuration examples seem to be using NetBSD syntax. Thanks, Craig To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
bremfree: bp 0xc77938f4 not locked (Most recently used by kqueue)
I get this all the time, and have for months now. On two different systems (both updated to -current about 2 times per month), both PCs (but with greatly differing HW). What would be my first step to resolve this? I sent in a PR, with lots of notes, things I tried, and stack dumps. I'm willing to do some more work on it, if someone can point me in the right direction. panic: bremfree: bp 0xc77938f4 not locked panic messages: --- panic: Most recently used by kqueue syncing disks... panic: bremfree: bp 0xc77938f4 not locked Uptime: 1d2h2m49s Dumping 256 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- #0 0xc02f9a9b in doadump () (kgdb) where #0 0xc02f9a9b in doadump () #1 0xc02f9f7d in boot () #2 0xc02fa1a8 in panic () #3 0xc033a477 in bremfree () #4 0xc033cc60 in getblk () #5 0xc033a5aa in breadn () #6 0xc033a55c in bread () #7 0xc03fd2e6 in ffs_update () #8 0xc0411802 in ffs_fsync () #9 0xc040f18f in ffs_sync () #10 0xc034c358 in sync () #11 0xc02f9b9c in boot () #12 0xc02fa1a8 in panic () #13 0xc0434a9d in mtrash_ctor () #14 0xc0433527 in uma_zalloc_arg () #15 0xc02ee735 in malloc () #16 0xc02dd0e5 in fdcopy () #17 0xc02e5711 in fork1 () #18 0xc02e4c0a in fork () #19 0xc04657a1 in syscall () #20 0xc0455e5d in Xint0x80_syscall () ---Can't read userspace from dump, or kernel process--- -Seth To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CAM-ATAPI status?
According to Julian Elischer: > Sonn has come an gone... if anyone can get me -current patches to do this > I'll commit them now and they can be cleaned up later. > that'll at least get them started on the path to 4.7... The path to 4.7 will be very easy as Thomas has been maintaining patches for both branches since the beginning. Cleanup patches by Scott Long (scottl) have already been committed too. Thomas will soon be able to maintain the whole thing himself :-) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CAM-ATAPI status?
I see that SOS has just committed to -current.. a Joyous day.. now to get a working SACk implementation :-) On Tue, 13 Aug 2002, Ollivier Robert wrote: > According to Julian Elischer: > > Sonn has come an gone... if anyone can get me -current patches to do this > > I'll commit them now and they can be cleaned up later. > > that'll at least get them started on the path to 4.7... > > The path to 4.7 will be very easy as Thomas has been maintaining patches for > both branches since the beginning. Cleanup patches by Scott Long (scottl) have > already been committed too. > > Thomas will soon be able to maintain the whole thing himself :-) > -- > Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] > FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 > > 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
WTF is going on? pipe breakage, patch(1) breakage??
Running `make clean patch' in a loop is randomly failing for me on an SMP machine: bash$ uname -a FreeBSD 5.0-CURRENT FreeBSD 5.0-CURRENT #273: Thu Aug 8 21:33:19 PDT 2002 bash$ cd /usr/ports/editors/vim bash$ PATCH_DEBUG=1 make clean patch ===> Applying distribution patch 6.1.012 patch: misordered hunks! output would be garbled *** Error code 1 bash$ !! ===> Applying distribution patch 6.1.014 1 out of 13 hunks failed--saving rejects to src/ops.c.rej *** Error code 1 bash$ !! ===> Applying distribution patch 6.1.090 1 out of 2 hunks failed--saving rejects to src/move.c.rej *** Error code 1 bash$ !! ===> Applying distribution patch 6.1.150 ===> Applying FreeBSD patches for vim-6.1.151 [ all patches cleanly applied ] bash$ !! ===> Applying distribution patch 6.1.150 ===> Applying FreeBSD patches for vim-6.1.151 [ all patches cleanly applied ] bash$ !! ===> Applying distribution patch 6.1.140 2 out of 2 hunks failed--saving rejects to src/os_unix.c.rej *** Error code 2 ===> Applying distribution patch 6.1.014 1 out of 13 hunks failed--saving rejects to src/ops.c.rej *** Error code 1 bash$ !! ===> Applying distribution patch 6.1.150 ===> Applying FreeBSD patches for vim-6.1.151 [ all patches cleanly applied ] ===> Applying distribution patch 6.1.013 1 out of 1 hunks failed--saving rejects to src/option.c.rej *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
