Patch for Alpha/AXP
Does this look right? Without this patch, my AXP was memory faulting every time it booted, in the dev2udev routine. Thanks Index: alpha/alpha/cons.c === RCS file: /home/ncvs/src/sys/alpha/alpha/cons.c,v retrieving revision 1.11 diff -u -r1.11 cons.c --- cons.c 1999/06/22 14:13:16 1.11 +++ cons.c 1999/07/24 07:18:25 @@ -88,9 +88,8 @@ }; static dev_t cn_dev_t; /* seems to be never really used */ -static udev_t cn_udev_t; SYSCTL_OPAQUE(_machdep, CPU_CONSDEV, consdev, CTLFLAG_RD, - cn_udev_t, sizeof cn_udev_t, "T,dev_t", ""); + cn_dev_t, sizeof cn_dev_t, "T,dev_t", ""); static int cn_mute; @@ -185,7 +184,6 @@ cdp-d_open = cnopen; cn_tp = (*cdp-d_devtotty)(cn_tab-cn_dev); cn_dev_t = cn_tp-t_dev; - cn_udev_t = dev2udev(cn_dev_t); } static void @@ -206,7 +204,6 @@ cn_phys_open = NULL; cn_tp = NULL; cn_dev_t = 0; - cn_udev_t = dev2udev(cn_dev_t); } /* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for Alpha/AXP
Yes, looks right. In message [EMAIL PROTECTED], "Gary Palmer" writes: Does this look right? Without this patch, my AXP was memory faulting every time it booted, in the dev2udev routine. Thanks Index: alpha/alpha/cons.c === RCS file: /home/ncvs/src/sys/alpha/alpha/cons.c,v retrieving revision 1.11 diff -u -r1.11 cons.c --- cons.c 1999/06/22 14:13:16 1.11 +++ cons.c 1999/07/24 07:18:25 @@ -88,9 +88,8 @@ }; static dev_t cn_dev_t; /* seems to be never really used */ -static udev_t cn_udev_t; SYSCTL_OPAQUE(_machdep, CPU_CONSDEV, consdev, CTLFLAG_RD, - cn_udev_t, sizeof cn_udev_t, "T,dev_t", ""); + cn_dev_t, sizeof cn_dev_t, "T,dev_t", ""); static int cn_mute; @@ -185,7 +184,6 @@ cdp-d_open = cnopen; cn_tp = (*cdp-d_devtotty)(cn_tab-cn_dev); cn_dev_t = cn_tp-t_dev; - cn_udev_t = dev2udev(cn_dev_t); } static void @@ -206,7 +204,6 @@ cn_phys_open = NULL; cn_tp = NULL; cn_dev_t = 0; - cn_udev_t = dev2udev(cn_dev_t); } /* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PLIP is still broken :(
Possible quick fix (hack): change all the spltty()'s in lpt.c to splnet()'s. lpt isn't a tty driver; it just abuses spltty(). Abusing splnet() instead should work OK for lpt and fix if_plip. This seems good until the intr stuff handle dynamic update of a interrupt spl. Is there some work in progress on that? Not much. ppc needs to do most of the work by registering its interrupt with the correct interrupt maskptr for the currently attached device. This may involve unregistering the interrupt when the device changes. The generic code could help here by supporting atomic changing of interrupt maskptrs without unregistering the interrupt. Otherwise, the generic code is missing mainly update of the interrupt masks when an interrupt is unregistered. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FreeBSD-current and Netscape Java
Are there any tricks to getting Java in Netscape running with FreeBSD --current. I've suddenly noticed it's not working (tried 4.08 and 4.6 with Fortify 1.4.4 applied and it's no-go even with the classpath set correctly...) Bill --- [EMAIL PROTECTED]|[EMAIL PROTECTED] Three things never anger: First, the one who runs your DEC, The one who does Field Service and the one who signs your check. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PMAP_SHPGPERPROC: related to pagedaemon?
Tony Finch wrote: Doug [EMAIL PROTECTED] wrote: *Nod* well, we do a lot of "unusual" things around here. :) Given your explanation I think that the culprit is probably apache. The virtual host file has approximately 16k hosts. *ouch* Yeah, tell me about it. You should take a gander at http://www.apache.org/docs/vhosts/mass.html Thank you for the suggestion, but I think that this would not be an acceptable option on the basis of the logging requirements. Also, this setup presupposes some things about the directory structure(s) that wouldn't be compatible with our setup. Thanks again, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unkillable processes
On Sat, 24 Jul 1999, Kevin Day wrote: For one, do another 'ps' with the 'l' option, so you can see what it's stuck on. UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 1000 1103 1086 29 75 20 5740 384 - TWN ??0:00.00 (kvt) 1000 1109 1103 0 4 0 15040 ttywri IWs+ p10:00.00 (tcsh) 1000 92724 1086 279 105 20 5736 356 - RN?? 139:40.13 kvt -T Termi 1000 92743 92724 2 18 0 15760 pause IWs p80:00.00 (tcsh) The second process is a zombie, which isn't killable until the parent tells it to go away. (Which could very possibly be the first kvt) Both still present empty terminal windows on my desktop and were spawned from the KDE panel. The second one was running a copy of pine and was in the same state as the other initially, until I kill -KILL'ed the pine process, at which point it changed to what it is now. Kris Well, since the CPU time in the active process (92724) went up since your last e-mail, and it's in the RUN state (a - in the WCHAN and a R in the STAT), it looks like the process is just spinning, eating CPU. The tcsh listed below that is a zombie of the running kvt. If you can somehow kill that kvt, the tcsh will go away. The top kvt (1103) is also a zombie, waiting for it's parent to reap it. Whatever process 1086 is decided not to clean it up, you may want to see what it's doing. Will process 92724 die if you kill -9 it? This seems to be more of a kvt bug than a freebsd bug. :) Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unkillable processes
On Sat, 24 Jul 1999, Kevin Day wrote: For one, do another 'ps' with the 'l' option, so you can see what it's stuck on. UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 1000 1103 1086 29 75 20 5740 384 - TWN ??0:00.00 (kvt) 1000 1109 1103 0 4 0 15040 ttywri IWs+ p10:00.00 (tcsh) 1000 92724 1086 279 105 20 5736 356 - RN?? 139:40.13 kvt -T Termi 1000 92743 92724 2 18 0 15760 pause IWs p80:00.00 (tcsh) The second process is a zombie, which isn't killable until the parent tells it to go away. (Which could very possibly be the first kvt) Both still present empty terminal windows on my desktop and were spawned from the KDE panel. The second one was running a copy of pine and was in the same state as the other initially, until I kill -KILL'ed the pine process, at which point it changed to what it is now. Kris Well, since the CPU time in the active process (92724) went up since your last e-mail, and it's in the RUN state (a - in the WCHAN and a R in the STAT), it looks like the process is just spinning, eating CPU. Correct. Yet I cannot kill -9 it. The tcsh listed below that is a zombie of the running kvt. If you can somehow kill that kvt, the tcsh will go away. I can't kill -9 any of the processes listed above. The top kvt (1103) is also a zombie, waiting for it's parent to reap it. Whatever process 1086 is decided not to clean it up, you may want to see what it's doing. That's kfm. Will process 92724 die if you kill -9 it? No. Yet it continues to run and chew up CPU.. This seems to be more of a kvt bug than a freebsd bug. :) I don't doubt it's mediated by KDE in some way, but I didn't think it was possible for processes to trap or ignore SIGKILLs and continue to run (chew up CPU). Zombie processes I can deal with, even if the window manager continues to present a window for them :-) Kris Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unkillable processes
On Saturday, 24 July 1999 at 20:51:37 -0500, Kevin Day wrote: On Sat, 24 Jul 1999, Kevin Day wrote: For one, do another 'ps' with the 'l' option, so you can see what it's stuck on. UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 1000 1103 1086 29 75 20 5740 384 - TWN ??0:00.00 (kvt) 1000 1109 1103 0 4 0 15040 ttywri IWs+ p10:00.00 (tcsh) 1000 92724 1086 279 105 20 5736 356 - RN?? 139:40.13 kvt -T Termi 1000 92743 92724 2 18 0 15760 pause IWs p80:00.00 (tcsh) Well, since the CPU time in the active process (92724) went up since your last e-mail, and it's in the RUN state (a - in the WCHAN and a R in the STAT), it looks like the process is just spinning, eating CPU. Right. The tcsh listed below that is a zombie of the running kvt. There aren't any zombies here. It's a child of the kvt. It's not a zombie. Take a look at the STAT field (and ps(1)): process Good point, i didn't notice that, i saw the ()'s from his first message, Process 92724 is runnable, nice and running (no WCHAN). I really don't understand why you can't stop this one. The only time I've seen this is when my console is getting flooded with 'vm_fault: pager error' messages for that process. Otherwise, there's no reason why a running process can't be killed, correct? Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
