A tiny Perl bug?
I was trying to get FreeBSD 4.2-BETA to compile under FreeBSD 3.4 when I found that the use of the new setresgid() and setresuid() system calls were causing the perl5 compile to fail. I got around this using NOPERL=yup but while investigating I noticed an apparent bug in the use of setresgid() and propose this patch: Index: mg.c === RCS file: /cvs/src/contrib/perl5/mg.c,v retrieving revision 1.1.1.4 diff -u -r1.1.1.4 mg.c --- mg.c2000/08/20 08:42:14 1.1.1.4 +++ mg.c2000/11/22 12:01:32 @@ -1926,7 +1926,7 @@ (void)setregid((Gid_t)PL_gid, (Gid_t)-1); #else #ifdef HAS_SETRESGID - (void)setresgid((Gid_t)PL_gid, (Gid_t)-1, (Gid_t) 1); + (void)setresgid((Gid_t)PL_gid, (Gid_t)-1, (Gid_t)-1); #else if (PL_gid == PL_egid) /* special case $( = $) */ (void)PerlProc_setgid(PL_gid); I assume this was just a typo. I can't think of any reason to try to set the saved uid to daemon. I'd whip in and commit this myself, but I'm sure there are "vendor branch considerations", and I've never found out what's involved with that. And piggybacking a slightly wider issue: The cross-tools section of Makefile.inc1 is supposed to address the use of new system calls and such in build tools, right? Can we forget about the old "try to use the new syscall and do something else if it isn't there" code? And all we need to do to fix my migration problem is to MFC marcel's miniperl cross-build fix? Right? Otherwise I have all this blather I was going to say about using fancy new syscalls in perl just to emulate old syscalls we already have, and the way that makes upgrading harder. But I don't have to go on about that, it seems. :-) Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: No console on AlphaServer 2000 4/233 4.2-RC2
John W. De Boskey writes: Hi, Console, console, where's the console? The SRM console is using a TGA video card as the console output device. TGA is not supported by syscons. So FreeBSD is forced to use the serial console instead... You can "fix" this by using just about any $10 pci vga card you happen to have laying around in place of the TGA card. Or hook up a 9600 8,n,1 connection to the 1st serial port and tell the srm to use it as a console ( set console serial) and dmesg: (Yes, the 1st 2 lines are from dmesg, and I cannot find where they are coming from yet). Unrecognized boot flag '0'. Unrecognized boot flag ','. They're coming from the kernel, I think. You probably have 'boot_osflags' set to something like '0,a' in the srm console. Clear that variable, or set it to "a" and those messages will go away. pci0: unknown card (vendor=0x1011, dev=0x0004) at 6.0 irq 32 FWIW, this is the TGA card. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Laptops and sc0/vt0 consoles
Hi, Apologies upfront if anything I ask/say has already been covered, I'm somwhat limited in my resources at present. In my past experience, FreeBSD hasn't agreed very well with IBM thinkpad laptops, unless you were using the vt0 console driver. This makes me ask a couple of questions: 1) Does vt0 work for everything? Or only laptops? (my understanding is that it works for "everything" 2) If 1) is true, why doesn't the kernel on install floppies/cd's use vt0 instead of sc0. I haven't been able to test with anything post 3.4, so again, apologies if sc0 has been fixed to work with thinkpads etc. Just thought this could be worth raising, would be curious of peoples thoughts. Regards, sjh. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Laptops and sc0/vt0 consoles
Apologies upfront if anything I ask/say has already been covered, I'm somwhat limited in my resources at present. In my past experience, FreeBSD hasn't agreed very well with IBM thinkpad laptops, unless you were using the vt0 console driver. This is *VERY* old information. When Pentium's were introduced (755/560) series, it has no longer been a necessity. The old 486 laptops need vt0, but anything newer works fine with sc0. (I speak from experience, having had an IBM laptop for 7-8 years, and being responsible for writing or integrating the code in FreeBSD to support IBM Thinkpads.) I'm also typing on a ThinkPad right now, which is my 'main' platform, and it's doing fine with syscons, as have my previous 3 ThinkPads. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: No console on AlphaServer 2000 4/233 4.2-RC2
On Wed, Nov 22, 2000 at 09:31:50AM -0500, Andrew Gallatin wrote: John W. De Boskey writes: and dmesg: (Yes, the 1st 2 lines are from dmesg, and I cannot find where they are coming from yet). Unrecognized boot flag '0'. Unrecognized boot flag ','. They're coming from the kernel, I think. You probably have 'boot_osflags' set to something like '0,a' in the srm console. Probably a leftover from a previous VMS life: 0,0 is for VMS. -- Wilko Bulte Arnhem, the Netherlands [EMAIL PROTECTED] http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RFC: /dev/console - /var/log/messages idea/patch
The attached patch is a "proof-of-concept" on which I would like
to get some comments:
It bugs me big time that the output from /etc/rc and all other output
to /dev/console is volatile and lost once it scrolls of your console.
It particular bugs me for systems which are configured with a modem
on a serial port as console, if something choked badly in /etc/rc
I will never know.
(Don't tell me to use a SilentWriter or DecWriter as console, OK ?
Been There, Done That, Got The Piles Of Paper To Prove It. :-)
Ideally our console would be much more functional, but that is a project
which would fall sideways off my todo list if I tried to balance it there.
(If anybody is looking for a medium complex kernel task, a new console
system is a place to look. Enquire within).
So I though about it from a "how little can we get away with" and realized
that by simply grabbing a copy of everything written to /dev/console and
feeding it to syslogd would gain us a lot of mileage.
Now, there are several issues to understand here, so please read on before
you apply paint to this bikeshed:
By "/dev/console" output I mean just and only that. Characters
which arrive by write(2)/writev(2) on a fd opened to "/dev/console".
Kernel printfs are not /dev/console output in this context.
Characters written directly to your console device ("/dev/ttyd0",
"/dev/ttyv0" or "/dev/cuaa0") are *not* /dev/console output either.
Input from /dev/console are not part of this. You will not be able
to see the answers people give fsck.
The output do of course still also arrive on your console device.
Obviously, if syslogd were to write these messages back to /dev/console
bad things would happen. Syslogd may need to gain a tabu there.
The formatting cannot be preserved. If somebody were to:
echo -n "You're screwed now --- " /dev/console
we would never see the message in syslogd if the code waited
for the final '\n' to arrive. (I guess a timeout based solution
could be feasible, what do people think ?)
In this patch I have deliberatly output a '"' in front of all
messages, this is merely for debugging right now.
The patch probably has all sorts of issues, style, locking, you name
it. It is only intended as a proof-of-concept patch.
Sample output from /var/log/messages attached below.
Comments, volounteers, ideas most welcome...
Poul-Henning
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "swapon: adding /dev/ad1s1b as
swap device
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "swapon: adding /dev/ad0s1b as
swap device
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "Automatic boot in progress...
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "/dev/ad0s1a:
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "FILESYSTEM CLEAN; SKIPPING
CHECKS
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "/dev/ad0s1a:
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "clean, 134807 free
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "(823 frags, 16748 blocks,
0.4% fragmentation)
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "/dev/ad1s1e:
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "FILESYSTEM CLEAN; SKIPPING
CHECKS
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "/dev/ad1s1e:
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "clean, 184706 free
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "(138 frags, 23071 blocks,
0.1% fragmentation)
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "/dev/ad1s1f:
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "FILESYSTEM CLEAN; SKIPPING
CHECKS
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "/dev/ad1s1f:
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "clean, 1775231 free
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "(13343 frags, 220236 blocks,
0.7% fragmentation)
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "/dev/ad0s1e:
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "FILESYSTEM CLEAN; SKIPPING
CHECKS
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "/dev/ad0s1e:
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "clean, 2032838 free
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "(14 frags, 254103 blocks,
0.0% fragmentation)
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "/dev/ccd0c:
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "FILESYSTEM CLEAN; SKIPPING
CHECKS
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "/dev/ccd0c:
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "clean, 3464429 free
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "(3245 frags, 865296 blocks,
0.1% fragmentation)
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "Can't use /entropy as an
entropy file, trying other sources
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "cat:
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: "malloc.conf
Nov 22 21:16:38 console.info syv /boot/kernel/kernel: ":
Nov 22
Re: RFC: /dev/console - /var/log/messages idea/patch
On Wed, Nov 22, 2000 at 09:40:41PM +0100, Poul-Henning Kamp said: The attached patch is a "proof-of-concept" on which I would like to get some comments: I'm only a moronic user, but this would make my life easier. My machine switches into 132x43 on startup, and I always lose the output. So this is just me saying "Yay for phk." -- Pine vs Mutt : trolld It's like the difference between playing with yourself and getting head from a hot girl. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: /dev/console - /var/log/messages idea/patch
In the last episode (Nov 22), Poul-Henning Kamp said:
The attached patch is a "proof-of-concept" on which I would like to
get some comments:
It bugs me big time that the output from /etc/rc and all other output
to /dev/console is volatile and lost once it scrolls of your console.
SCO logs its startup by simply piping the output of its rc scripts
through "21 | tee -a /usr/adm/rc#.log". We could do something
similar by wrapping everything after the "mount -a -t nonfs" command on
like 174 with
{
} 21 | tee -a /var/log/boot.log
--
Dan Nelson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: RFC: /dev/console - /var/log/messages idea/patch
In message [EMAIL PROTECTED], Dan Nelson writes: In the last episode (Nov 22), Poul-Henning Kamp said: The attached patch is a "proof-of-concept" on which I would like to get some comments: It bugs me big time that the output from /etc/rc and all other output to /dev/console is volatile and lost once it scrolls of your console. SCO logs its startup by simply piping the output of its rc scripts through "21 | tee -a /usr/adm/rc#.log". We could do something similar by wrapping everything after the "mount -a -t nonfs" command on like 174 with I've tried stuff like that and I didn't particularly like the result, for one thing many programs (or maybe it was tee(1) itself) changed buffering because of the pipe, which meant that the partial lines like "starting standard daemons: inetd cron sendmail sshd." would only arrive on the real console when the final \n arrived. Another particular thing I remember was that some syslog-challenged daemons whine on /dev/console long after /etc/rc has finished. Dump(8) will do something similar if you don't flip the tapes in finite time. So while it goes a long way, I think we need to provide more coverage of "/dev/console" as a concept. Poul-Henning PS: As I said, a decently functional console subsystem would be a nice thing. At the very least I would want to be able to specify: console output to /dev/ttyd0, /dev/ttyv0 and /var/log/console console input from /dev/ttyd0 or /dev/ttyv0. and preferably with a scrollback buffer too. Network consoles would be nice as well. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sound card errors in -current ?
This is on a -current system when loading snd_maestro some time after boot. pcm0: ESS Technology Maestro-2E port 0x1400-0x14ff irq 5 at device 8.0 on pci0 pcm0: chn_init() for (play:0) failed pcm0: offset 0xfef7a000 exceeds limit. pcm0: chn_init() for (play:1) failed pcm0: offset 0xfefa9000 exceeds limit. pcm0: chn_init() for (play:2) failed pcm0: offset 0xfefb5000 exceeds limit. pcm0: chn_init() for (play:3) failed -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: /dev/console - /var/log/messages idea/patch
On Wed, 22 Nov 2000 22:22:39 +0100, Poul-Henning Kamp [EMAIL PROTECTED] said: Another particular thing I remember was that some syslog-challenged daemons whine on /dev/console long after /etc/rc has finished. They can try, but by the time they do the console has already been revoke()d, so they no longer have access to the real console. I've thought about writing daemon(8) which will put these turkeys in their place. Just a Small Matter of Programming -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: /dev/console - /var/log/messages idea/patch
In message [EMAIL PROTECTED], Garrett Wollman write s: On Wed, 22 Nov 2000 22:22:39 +0100, Poul-Henning Kamp [EMAIL PROTECTED] said: Another particular thing I remember was that some syslog-challenged daemons whine on /dev/console long after /etc/rc has finished. They can try, but by the time they do the console has already been revoke()d, so they no longer have access to the real console. I don't know what you consider "the real console", but opening "/dev/console" and barfing on it works all the time. (Well, *almost* all the time, not if you have foobar'ed your serial console but...) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel panic with ipfw pipes
The attached kernel panic occurs when a connection is made that
would pass through an ipfw pipe configured as:
ipfw add 1000 pipe 1 tcp from any 119 to any out
ipfw add 1001 pipe 2 tcp from any to any 119 in
ipfw pipe 1 config bw 64Kbit/s
ipfw pipe 2 config bw 64Kbit/s
I can reproduce this at will (and have the vmcore), so if anyone needs
more details, just let me know.
This is -current of a few days ago (18th Nov 2000, if I recall correctly).
-Russell
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 4771840
initial pcb at 3de1e0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x7f7b1028
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc0248899
stack pointer = 0x10:0xc7098be4
frame pointer = 0x10:0xc7098c30
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (swi6: clock)
trap number = 12
panic: page fault
syncing disks... 5 5
done
Uptime: 1m27s
dumping to dev #ad/1, offset 131072
dump ata0: resetting devices .. done
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36
35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6
5 4 3 2 1
---
#0 dumpsys () at /b/src/sys/kern/kern_shutdown.c:477
477 if (dumping++) {
(kgdb) where
#0 dumpsys () at /b/src/sys/kern/kern_shutdown.c:477
#1 0xc01e26b3 in boot (howto=256) at /b/src/sys/kern/kern_shutdown.c:320
#2 0xc01e2ad8 in poweroff_wait (junk=0xc039e68f, howto=-966215744)
at /b/src/sys/kern/kern_shutdown.c:568
#3 0xc03386b8 in trap_fatal (frame=0xc7098ba4, eva=2138771496)
at /b/src/sys/i386/i386/trap.c:941
#4 0xc033843d in trap_pfault (frame=0xc7098ba4, usermode=0, eva=2138771496)
at /b/src/sys/i386/i386/trap.c:855
#5 0xc0337ef7 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0,
tf_esi = 0, tf_ebp = -955675600, tf_isp = -955675696, tf_ebx = 1,
tf_edx = 2138771456, tf_ecx = -24083, tf_eax = -1063531204,
tf_trapno = 12, tf_err = 2, tf_eip = -1071347559, tf_cs = 8,
tf_eflags = 66118, tf_esp = -1054004288, tf_ss = -1054027776})
at /b/src/sys/i386/i386/trap.c:438
#6 0xc0248899 in ip_output (m0=0xc09bcd00, opt=0x0, ro=0xc12d2be4, flags=0,
imo=0x0) at /b/src/sys/netinet/ip_output.c:806
#7 0xc023e526 in transmit_event (pipe=0xc12cd000)
at /b/src/sys/netinet/ip_dummynet.c:394
#8 0xc023e72b in ready_event (q=0xc12c2100)
at /b/src/sys/netinet/ip_dummynet.c:525
#9 0xc023f467 in dummynet_io (pipe_nr=1, dir=1, m=0xc09bcd00, ifp=0xc09ae400,
ro=0xc7098d98, dst=0xc12729d0, rule=0xc123a3a0, flags=0)
at /b/src/sys/netinet/ip_dummynet.c:1062
#10 0xc024858b in ip_output (m0=0xc09bcd00, opt=0x0, ro=0xc7098d98, flags=0,
imo=0x0) at /b/src/sys/netinet/ip_output.c:497
#11 0xc024f00c in tcp_respond (tp=0x0, ipgen=0xc09bcd3c, th=0xc09bcd50,
m=0xc09bcd00, ack=2736966641, seq=0, flags=20)
at /b/src/sys/netinet/tcp_subr.c:458
#12 0xc024cfc3 in tcp_input (m=0xc09bcd00, off0=20, proto=6)
at /b/src/sys/netinet/tcp_input.c:2303
#13 0xc0244dd8 in ip_input (m=0xc09bcd00) at /b/src/sys/netinet/ip_input.c:729
#14 0xc023e53a in transmit_event (pipe=0xc12cef00)
at /b/src/sys/netinet/ip_dummynet.c:399
#15 0xc023e72b in ready_event (q=0xc12c2180)
at /b/src/sys/netinet/ip_dummynet.c:525
#16 0xc023eb63 in dummynet (unused=0x0) at /b/src/sys/netinet/ip_dummynet.c:660
#17 0xc01e9ad4 in softclock (dummy=0x0) at /b/src/sys/kern/kern_timeout.c:134
#18 0xc01d95cd in sithd_loop (dummy=0x0) at /b/src/sys/kern/kern_intr.c:227
(kgdb) quit
#
# GENERIC -- Generic kernel configuration file for FreeBSD/i386
#
# For more information on this file, please read the handbook section on
# Kernel Configuration Files:
#
#http://www.FreeBSD.org/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the NOTES configuration file. If you are
# in doubt as to the purpose or necessity of a line, check first in NOTES.
#
# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.278 2000/09/20 17:30:20 wpaul Exp $
machine i386
cpu I586_CPU
cpu I686_CPU
ident RV
how to mutex'ify a device driver
As a relatively simple exercise in -current kernel programming, I'm planning to mutex'ify the ichsmb(4) device driver (this is a relatively simple driver that currently uses splhigh()). I'd appreciate some feedback if what I'm doing is the right thing. The plan is to give each instance of the device a mutex. This mutex will be grabbed by both the top level code (when programming the chip to do something or reading the results) and the interrupt code (when servicing an interrupt). So far so good.. but what I don't understand is what happens if the interrupt thread has to block on the mutex? It seems like all other devices sharing the same interrupt (and therefore thread) could be indefinitely blocked from servicing their IRQ's. Or is it just assumed that the top half will never hold the mutex for a "long" time? Thanks, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: how to mutex'ify a device driver
On 23-Nov-00 Archie Cobbs wrote: As a relatively simple exercise in -current kernel programming, I'm planning to mutex'ify the ichsmb(4) device driver (this is a relatively simple driver that currently uses splhigh()). I'd appreciate some feedback if what I'm doing is the right thing. The plan is to give each instance of the device a mutex. This mutex will be grabbed by both the top level code (when programming the chip to do something or reading the results) and the interrupt code (when servicing an interrupt). This should work. Sort of. You probably want to wait a bit until I commit my cdevsw wrapper patches and an MP safe version of the psm(4) driver which will help detail what has to happen. So far so good.. but what I don't understand is what happens if the interrupt thread has to block on the mutex? It seems like all other devices sharing the same interrupt (and therefore thread) could be indefinitely blocked from servicing their IRQ's. Or is it just assumed that the top half will never hold the mutex for a "long" time? It the interrupt thread blocks on the mutex, then yes, that IRQ will be blocked. However, mutexes are intended to be held for relatively short periods of time. For example, you can't sleep (SSLEEP) with a mutex, so if you are blocked, you won't be blocked for very long. Also, since interrupt threads run at a very high priority, it will run again as soon as the top half releases the mutex. Thanks, -Archie -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rtc-2000.09.22.tgz can't load on my system
My system is FreeBSD 5.0(src-cur.4612) , I want to run vmware2 , so I pkg_add rtc-2000.09.22.tgz. But when My computer starting, it say can't load rtc.ko, Execute error, Why? ¡Iì¹» ®Þ±éݨ¥¶Ý¢jçH:+éì¹» ®Þ~·nÇ\ººÞا¶¡Ü¨~Ø^ë,j
Re: Kernel panic with ipfw pipes
Hi, Please try this patch and report: http://people.freebsd.org/~bmilekic/ip_pipe.diff joe, it appears that this commit: Revision 1.114 / (download) - annotate - [select for diffs], Sun Oct 29 01:05:07 2000 UTC (3 weeks, 4 days ago) by joe Changes since 1.113: +7 -3 lines Diff to previous 1.113 (colored) Count per-address statistics for IP fragments. Requested by: ru Obtained from: BSD/OS is the cause of the crashes... joe, please verify that this is the correct fix and let me know so that I can commit. On Wed, 22 Nov 2000, Russell Vincent wrote: The attached kernel panic occurs when a connection is made that would pass through an ipfw pipe configured as: ipfw add 1000 pipe 1 tcp from any 119 to any out ipfw add 1001 pipe 2 tcp from any to any 119 in ipfw pipe 1 config bw 64Kbit/s ipfw pipe 2 config bw 64Kbit/s I can reproduce this at will (and have the vmcore), so if anyone needs more details, just let me know. This is -current of a few days ago (18th Nov 2000, if I recall correctly). -Russell Thanks, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: /dev/console - /var/log/messages idea/patch
On Wed, 22 Nov 2000 23:44:12 +0100, Poul-Henning Kamp [EMAIL PROTECTED] said: In message [EMAIL PROTECTED], Garrett Wollman write They can try, but by the time they do the console has already been revoke()d, so they no longer have access to the real console. I don't know what you consider "the real console", but opening "/dev/console" and barfing on it works all the time. We are talking at cross purposes. I am talking about programs which don't properly detach from their controlling terminal (the console, in this case) and then periodically warble things to standard error. Luckily, such programs never seem to bother to check the error returns. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
COMPAT_SVR4 broken after uipc_syscalls commit (1.77)
The recent renaming of getsock() to holdsock() broke COMPAT_SVR4 (and
MISC_FS).
I have made a quick stab at fixing it up in
src/sys/compat/svr4/svr4_stream.c,
but I'm a little hesitent to figure out what is going on in
src/sys/miscfs/portal/portal_vfsops.c.
Note: I don't actually use COMPAT_SVR4 for anything, it just happened to
be in my
config and broke.
Any way, here is a possible fix.
-- Danny J. Zerkel
[EMAIL PROTECTED]
--- svr4_stream.c.orig Thu Aug 31 18:54:05 2000
+++ svr4_stream.c Wed Nov 22 22:39:00 2000
@@ -162,7 +162,7 @@
struct uio ktruio;
#endif
- error = getsock(p-p_fd, s, fp);
+ error = holdsock(p-p_fd, s, fp);
if (error)
return (error);
auio.uio_iov = mp-msg_iov;
@@ -174,13 +174,17 @@
auio.uio_resid = 0;
iov = mp-msg_iov;
for (i = 0; i mp-msg_iovlen; i++, iov++) {
- if ((auio.uio_resid += iov-iov_len) 0)
+ if ((auio.uio_resid += iov-iov_len) 0) {
+ fdrop(fp, p);
return (EINVAL);
+ }
}
if (mp-msg_name) {
error = getsockaddr(to, mp-msg_name, mp-msg_namelen);
- if (error)
+ if (error) {
+ fdrop(fp, p);
return (error);
+ }
} else
to = 0;
if (mp-msg_control) {
@@ -229,6 +233,7 @@
bad:
if (to)
FREE(to, M_SONAME);
+ fdrop(fp, p);
return (error);
}
@@ -253,7 +258,7 @@
struct uio ktruio;
#endif
- error = getsock(p-p_fd, s, fp);
+ error = holdsock(p-p_fd, s, fp);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: COMPAT_SVR4 broken after uipc_syscalls commit (1.77)
Okay, this time I'll even include the entire patch...
-- Danny J. Zerkel
[EMAIL PROTECTED]
--- svr4_stream.c.orig Thu Aug 31 18:54:05 2000
+++ svr4_stream.c Wed Nov 22 22:39:00 2000
@@ -162,7 +162,7 @@
struct uio ktruio;
#endif
- error = getsock(p-p_fd, s, fp);
+ error = holdsock(p-p_fd, s, fp);
if (error)
return (error);
auio.uio_iov = mp-msg_iov;
@@ -174,13 +174,17 @@
auio.uio_resid = 0;
iov = mp-msg_iov;
for (i = 0; i mp-msg_iovlen; i++, iov++) {
- if ((auio.uio_resid += iov-iov_len) 0)
+ if ((auio.uio_resid += iov-iov_len) 0) {
+ fdrop(fp, p);
return (EINVAL);
+ }
}
if (mp-msg_name) {
error = getsockaddr(to, mp-msg_name, mp-msg_namelen);
- if (error)
+ if (error) {
+ fdrop(fp, p);
return (error);
+ }
} else
to = 0;
if (mp-msg_control) {
@@ -229,6 +233,7 @@
bad:
if (to)
FREE(to, M_SONAME);
+ fdrop(fp, p);
return (error);
}
@@ -253,7 +258,7 @@
struct uio ktruio;
#endif
- error = getsock(p-p_fd, s, fp);
+ error = holdsock(p-p_fd, s, fp);
if (error)
return (error);
auio.uio_iov = mp-msg_iov;
@@ -265,8 +270,10 @@
auio.uio_resid = 0;
iov = mp-msg_iov;
for (i = 0; i mp-msg_iovlen; i++, iov++) {
- if ((auio.uio_resid += iov-iov_len) 0)
+ if ((auio.uio_resid += iov-iov_len) 0) {
+ fdrop(fp, p);
return (EINVAL);
+ }
}
#ifdef KTRACE
if (KTRPOINT(p, KTR_GENIO)) {
@@ -352,6 +359,7 @@
FREE(fromsa, M_SONAME);
if (control)
m_freem(control);
+ fdrop(fp, p);
return (error);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Laptops and sc0/vt0 consoles
On Wed, 22 Nov 2000, Nate Williams wrote: In my past experience, FreeBSD hasn't agreed very well with IBM thinkpad laptops, unless you were using the vt0 console driver. This is *VERY* old information. When Pentium's were introduced (755/560) series, it has no longer been a necessity. The old 486 laptops need vt0, but anything newer works fine with sc0. Hmm, then I'm the lucky one :). There is an old ThinkPad 340 (486/4MB/120MB) which runs heavily trimmed down preSMPNG -current with sc driver. The only caveat is that one should specify a flag which disables keyboard reset, because without it machine will silently reboot. Besides that this ThinkPad works as gateway (even with PCMCIA ethernet card) without any problems. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Confusing error messages from shell image activation
Could I get some feedback on URL: http://www.freebsd.org/cgi/query-pr.cgi?pr=22755 ? It's just a one-line kernel patch with some attendant updates in the kernel and libc, but it makes dealing with broken #! scripts *much* saner, and no one has even seen fit to comment on it yet :-(. Thanx, mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Accept credit cards on-line THE EASY WAY!
No set up fees No monthly interest No minimum transaction fees The only charge is a small percentage of the cost of the transaction. You can not lose money! You only pay fees if you sell your product. Get in the act and launch your online bussiness which will work for you 24hrs a day, seven days a week and it is worldwide. Want to find out more? Go to: http://www.cyberturf.com/creditcard If this Email has reached you by mistake, we apologize. To remove your Email from the mailing list please send: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
