Single character errors in source files, stop kernel compile!
Hi I'm running FreebSD 3.3 on a AMD-K6 box thats totally SCSI. The controller is Adaptec 2940 and the drive in question is a 40MB/sec IBM 9GB (SCSI 3?).. In the process of attempting to make a new kernel I follow the usual procedure. %cd /sys/i386/conf/ %config KERNEL %cd ../../compile/KERNEL %make depend Everything to this point completes and reports no errors. %make This is where I start to get failures. The compiler will stop with code 1 and will claim that the reason is a single character error in the source code. A typical example would be the word "struct" spelt "strwct". Clearly there is a problem which I doubt is the source code. To work around this I just repeat the make command again and again until the job is done. then I install the kernel and reboot sucessfully. Any ideas? I'm tempted to think it's some kind of a problem with the drive, but I haven't had any real hard failures. The /etc/make.conf has -O2 optimization for the kernel. Ta! Tom Brown = __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mrtg, user-ppp
I'd like to plot uptime and number of calls from ppp to mrtg. Any 'easy' way to ask ppp for these values, getting the answer for number of seconds online since last asked? Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mrtg, user-ppp
On Sun, 10 Oct 1999, Leif Neland wrote: I'd like to plot uptime and number of calls from ppp to mrtg. Any 'easy' way to ask ppp for these values, getting the answer for number of seconds online since last asked? Store the time from the previous call after each call, as with a (non-thread-safe) "static" variable in C. You can accomplish reading the time up pretty reasonably using either pppctl or just working directly with the ppp socket in the program. Leif -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CAM-ification - documentation
Ick. Polling == bad. Interrupts == good. This isn't a single- tasking OS ala Win9x. This goes double for SCSI drivers, which are inherently async and overlapped. I never said polling was good. Nick just asked about polling, and I commented on how it could be done. I have no idea why he wanted to know about polling, though. Well, I am not sure whether I need polling, but there are some problems related to the fact that multiple USB transactions are needed for one SCSI transaction. Combined with the fact that some requests are done asynchronously (clear endpoint halt at the end of a transaction if the transaction failed) it might be useful to do polling to avoid massively complex code. Nick -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
buildworld on alpha hangs
Looking at buildworld of -current on a NoName Alpha: 0 26262 26135 255 10 0 576 128 wait I+p00:00.18 /usr/obj/usr 0 26263 26262 172 10 0 880 112 wait I+p00:00.15 /bin/sh -ec 0 27444 26263 152 10 0 752 216 wait I+p00:00.63 /usr/obj/usr 0 27505 27444 175 10 0 872 112 wait I+p00:00.03 /bin/sh -ec 0 27506 27505 171 10 0 1352 336 wait I+p00:00.10 cc -O -pipe 0 27507 27506 9 -18 0 10000 objtrm DE+ p00:03.49 (cpp) 0 27999 27998 11 10 0 888 536 wait Ssp10:00.42 -sh (sh) 0 28003 27999 36 37 0 600 424 - R+p10:00.03 ps -axl 0 204 1 49 3 0 1320 128 ttyin Is+ v00:00.10 /usr/libexec 0 205 1 52 3 0 1320 128 ttyin Is+ v10:00.10 /usr/libexec The build hangs, the offending process is I think 27507. This has proven to be a repeatable hangup. There are always objtrm processes around. My other Alpha machine using the same source (which is on a local disk on each machine, so no NFS BTW) has no problems building world. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Single character errors in source files, stop kernel compile!
tom brown wrote: Hi I'm running FreebSD 3.3 on a AMD-K6 box thats totally SCSI. The controller is Adaptec 2940 and the drive in question is a 40MB/sec IBM 9GB (SCSI 3?).. In the process of attempting to make a new kernel I follow the usual procedure. %cd /sys/i386/conf/ %config KERNEL %cd ../../compile/KERNEL %make depend Everything to this point completes and reports no errors. %make This is where I start to get failures. The compiler will stop with code 1 and will claim that the reason is a single character error in the source code. A typical example would be the word "struct" spelt "strwct". Clearly there is a problem which I doubt is the source code. 'u' is ascii code 0x75. 'w' is ascii code 0x77. You're seeing a classic undetected single bit error from cheap parity-less ram. Bit 1 (0x2) in some particular cell is turning on all by itself. To work around this I just repeat the make command again and again until the job is done. then I install the kernel and reboot sucessfully. Any ideas? I'm tempted to think it's some kind of a problem with the drive, but I haven't had any real hard failures. Either look out for a decent memory tester to locate the bad SIMM, or get the memory tested by a simm tester, or swap it out and start again. That's easier said than done with today's memory prices though. It's not overclocked is it? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
Sorry, this is somewhat late. On Wed, 6 Oct 1999, Wilfredo Sanchez wrote: | Have you given consideration to systems where the user/group database is | kept for (possibly a large) number of computers in a centralised manner by | say hesiod or nys (nis+). It would be nice if there was an easy interface | with these so that distributing the local system id numbers need not be | done by hand. It's complicated. We do have a distributed database (NetInfo) and we considered perhaps using the name of the NetInfo domain to determine local vs. foreign. The problem is that distributed databases are sometimes hierarchical, and can be mixed. For example: Well, people for some reason miss the point. What I was talking about is the 'interface', and that it be easy to attach things to it. Site A will want to distribute the ids via hesiod. Site B will want to distribute the ids via nis+. Site C wants to do it via Netinfo Site D wantd to use LDAP. There may be others (SNMP?). One way to do this is for example to have: a) a parameter (by default null) that specifies which program to run to get a list of local system ids b) a parameters (by default null) that specifies which program to run if we want to verify if a certain id has been added to the set of local ids since the startup. As the program can be anything (inc. a shell script) almost any way of distributing the local systems ids can be accomodated. This is of course just one way to achieve it (think of PAM). [snip] -Fred -- Wilfredo Sanchez, [EMAIL PROTECTED] Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How to prevent a system call from restart?
I modify the day time client program from the Stevens' book and run it on both a Sun workstation and a FreeBSD machine. In the program, I use signal() and alarm() to set a 5 seconds timeout. The program works as expected on Sun (after I comment out the daytime line in the file /etc/inetd.conf) but not on the FreeBSD machine. Later I find out that the reason maybe the recvfrom() restarts *automatically* in FreeBSD. Why the default behaviour is different from SunOS? If I am correct about the reason, can anyone tell me how to prevent the recvfrom() from restart after receiving the SIGALRM signal? By the way, I also try the socket timeout option. It works immediately. Any help is appreciated. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to prevent a system call from restart?
On Sun, Oct 10, 1999 at 03:16:43PM -0400, Zhihui Zhang wrote: Later I find out that the reason maybe the recvfrom() restarts *automatically* in FreeBSD. Maybe because of the following in /usr/src/lib/libc/gen/signal.c? sig_t signal(s, a) int s; sig_t a; [...] if (!sigismember(_sigintr, s)) sa.sa_flags |= SA_RESTART; ? -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Hello boot cylinder 1024 suggestion
I was recently annoyed to find that I cannot install/boot FreeBSD from a hard drive partition extending beyond cylinder 1024 (not a problem unique to FreeBSD by any means...). Even with LBA support, this translates to an 8-gig limit (i.e. the boot partition must be completely within the first 8 gigs of the hard drive). Actually, LBA support exists, unfortunately enabling it is still a little bit magic. So, questions: has anybody thought of this before? I couldn't find any reference to such a project anywhere, but it seems relatively obvious. Does this sound like a idea worth pursuing? And assuming that the previous answers are no and yes respectively, is there anyone who can/would assist with the install integration/testing portion of this (I am confident of my ability to code the MBR/BTX changes, but much less confident of my understanding on the install process). It's been looked at and basically rejected as "too bloody hard". If you have a convincing argument that this path should be followed over using the BIOS 'packet mode/EDD3' interface, and are willing to put the code together to do it, then we'll certainly look at it and see what can be done to take advantage of it. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLDs
On Slashdot, in a discussion regarding QNX, someone described it with the following: Under QNX, if your driver crashes, the kernel just restarts it. After reading it, I became more interested in KLDs. My only prior experiece was installing the Linux KLD and that was done by a port. You should note that neither QNX nor FreeBSD exhibit the above behaviour. KLD is a linker; it allows you to link more stuff into the kernel after it's been started. It doesn't implement a coprocess model of any sort. Anyway, in an effort to learn, I decided to KLD-ify EXT2FS support. It took about 20 minutes and works great, but I still do not know how KLDs work. :) I think the general idea is that you're not meant to worry about it. 8) If you're in need of more information, I can really only direct you to the sources. (I submitted the patch in kern/14217, if someone could look at it, that would be swell. I've been able to mount, read, write and umount without any problems) (noted) Anyway, back to the point, if it is this so simple (is it?), how much of the kernel can be KLDs? It would be interesting to see a kernel so small that all it had was KLD support in it and everything else was a module. Indeed it would. There's some fairly strong resistance to this being the _only_ way that FreeBSD works, but the level of modularity you describe is certainly a goal we are working towards. Has anyone else thought about this? Is this a good idea? Is this a bad idea? Yes, Yes, Yes. How fundamentally different would this be from a microkernel? Very. There is only one protection domain in the FreeBSD kernel, and KLDs live inside it. Could things be done in such a way that like QNX, it can kill and restart a misbehaving driver? What other cool things can be done? QNX doesn't do that. We can't either, unfortunately. The limits on "cool things" are so wide that listing them here would be extremely tiring. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFD: bogomips CPU performance metric
I like the idea as an optional LINT parameter that is NOT in the generic kernel. Might make some linux people feel comfortable with the switch, or might prove useful under some odd circumstances, but I agree it'd be silly to include it by default (kindof on the level of a splash screen) Robert Sexton wrote: On Thu, Sep 02, 1999 at 10:40:30AM -0700, Nick Sayer wrote: Linux generates a meric of CPU performance as a byproduct of calibrating a delay loop. We don't require doing any such thing, and so adding it would be purely cosmetic. However, I allege that cosmetic things aren't in and of themselves evil, so long as they don't break anything in the process. I'd have to agree with the "Lets be more professional" crowd. How about as a LINT option? "If you need something so banal, you can turn it on yourself" -- Robert Sexton, [EMAIL PROTECTED] "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining." -- Jeff Raskin, interviewed in Doctor Dobb's Journal To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Laurence Berland, Stuyvesant HS Debate Windows 98: n. useless extension to a minor patch release for 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition. http://stuy.debate.net icq #7434346aol imer E1101 The above email Copyright (C) 1999 Laurence Berland All rights reserved To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to prevent a system call from restart?
Zhihui Zhang wrote: I modify the day time client program from the Stevens' book and run it on both a Sun workstation and a FreeBSD machine. In the program, I use signal() and alarm() to set a 5 seconds timeout. The program works as expected on Sun (after I comment out the daytime line in the file /etc/inetd.conf) but not on the FreeBSD machine. Steven's book (I assume ``Advanced Programming in the Unix Environment'') also tells you about the sigaction() system call. If you use sigaction without SA_RESTART, the signal will not restart slow system calls, causing them to flag EINTR. mkb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFD: bogomips CPU performance metric
On Sun, Oct 10, 1999, Laurence Berland wrote: I like the idea as an optional LINT parameter that is NOT in the generic kernel. Might make some linux people feel comfortable with the switch, or might prove useful under some odd circumstances, but I agree it'd be silly to include it by default (kindof on the level of a splash screen) I disagree. BogoMIPS is a completely meaningless measurement and does not belong in our source tree as it will only produce repository bloat. -- |Chris Costello [EMAIL PROTECTED] |A bug in the code is worth two in the documentation. ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
aio_read kills machine
I am working on a small threaded program that uses aio_read(). In my first attempt to run the program it killed my machine instantly. The second time it only locked it solid. I get no messages, warnings, or errors. I am certain that my program is not correct (besides the obvious consiquence of running it :) ), but I would also like to determine why it kills the machine. I was not root either time I ran the code. I could provide additional debugging information, and the source to anybody who cares about this. I am not sure up front what would be helpful. The machine is a dual 400 with 512Mg ram, running 3.3-stable as of Sept 28 with SMP enabled. Thanks in advance. Chad [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aio_read kills machine
On Wed, Jan 01, 1997, Chad David wrote: I am certain that my program is not correct (besides the obvious consiquence of running it :) ), but I would also like to determine why it kills the machine. I was not root either time I ran the code. Then FreeBSD does have a problem. Please file a PR using the ``send-pr'' command or http://www.freebsd.org/send-pr.html and supply the source to your program and whatever other information you think will help us in figuring out the problem. -- |Chris Costello [EMAIL PROTECTED] |Field tested: Manufacturing doesn't have a test system. `--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
file system system calls
May anyone here point me where in the source tree i can see file system API implemented, like open, write, close, etc. Thanks a lot. -- "Security is not a state, but a process." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLDs
Could things be done in such a way that like QNX, it can kill and restart a misbehaving driver? What other cool things can be done? QNX doesn't do that. Actually, in many cases it does. There are numerous advantages in a well-designed/optimized micro-kernel that FreeBSD will never have. [ However, as has been shown by the plethora of poor micro-kernel implementations (QNX not withstanding), it's hard to implement a well-designed/optimized micro-kernel, especially one that is not architecture dependant. ] Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLDs
Could things be done in such a way that like QNX, it can kill and restart a misbehaving driver? What other cool things can be done? QNX doesn't do that. Actually, in many cases it does. There are numerous advantages in a well-designed/optimized micro-kernel that FreeBSD will never have. Well, the implication was that QNX implements this as a kernel policy and that it's done automatically. A handful of drivers can be stopped and restarted, notably the network devices. The QNX filesystem resource managers and disk device drivers are notoriously finicky and aren't restartable in the general sense. Still, I like QNX a lot and have a major telecomm app widely deployed on it, going on five years in the field now. However, as has been shown by the plethora of poor micro-kernel implementations (QNX not withstanding), it's hard to implement a well-designed/optimized micro-kernel, especially one that is not architecture dependent. Amen! :-) Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLDs
On Sun, 10 Oct 1999, Mike Smith wrote: You should note that neither QNX nor FreeBSD exhibit the above behaviour. KLD is a linker; it allows you to link more stuff into the kernel after it's been started. It doesn't implement a coprocess model of any sort. Yes, I knew this for FreeBSD, and for QNX, well, Slashdot again proves to be totally unreliable. :) Indeed it would. There's some fairly strong resistance to this being the _only_ way that FreeBSD works, but the level of modularity you I don't think this is a good idea but it would certainly be a swank thing to see. Is it possible to compile a kernel with no filesystems supported and have the boot loader load FFS? I have built an FFS module but I have not yet had time to test it. Frankly, I am kind of afraid to for fear of trashing my system. Has anyone else thought about this? Is this a good idea? Is this a bad idea? Yes, Yes, Yes. Could you claify this? :) Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file system system calls
On Mon, 11 Oct 1999, Gustavo V G C Rios wrote:
May anyone here point me where in the source tree i can see file system
API implemented, like open, write, close, etc.
src/sys/kern/vfs_syscalls.c
because freebsd follows (for the most part) style(9) you can usually
find where a function is implemented by just going to the sys source
directory and doing a simple:
grep ^somefuncname */*
this is because the concention is to write functions like so:
int
somefunctioname(foo) {
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: How to prevent a system call from restart?
On Sun, 10 Oct 1999, Zhihui Zhang wrote: I modify the day time client program from the Stevens' book and run it on both a Sun workstation and a FreeBSD machine. In the program, I use signal() and alarm() to set a 5 seconds timeout. The program works as expected on Sun (after I comment out the daytime line in the file /etc/inetd.conf) but not on the FreeBSD machine. Later I find out that the reason maybe the recvfrom() restarts *automatically* in FreeBSD. Why the default behaviour is different from SunOS? If I am correct about the reason, can anyone tell me how to prevent the recvfrom() from restart after receiving the SIGALRM signal? By the way, I also try the socket timeout option. It works immediately. Any help is appreciated. from sigaction's manpage: If a signal is caught during the system calls listed below, the call may be forced to terminate with the error EINTR, the call may return with a data transfer shorter than requested, or the call may be restarted. Restart of pending calls is requested by setting the SA_RESTART bit in sa_flags. The affected system calls include open(2), read(2), write(2), sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on a communications channel or a slow device (such as a terminal, but not a regular file) and during a wait(2) or ioctl(2). However, calls that have already committed are not restarted, but instead return a partial success (for example, a short read count). you want to turn off SA_RESTART. -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file system system calls
On Sun, Oct 10, 1999, Alfred Perlstein wrote:
grep ^somefuncname */*
this is because the concention is to write functions like so:
int
somefunctioname(foo) {
You mean
int
somefuncname(char *foo)
{
--
|Chris Costello [EMAIL PROTECTED]
|Death is a nonmaskable interrupt.
`--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Fun with vinum
On Mon, 11 Oct 1999, Greg Lehey wrote: On Sunday, 10 October 1999 at 19:33:44 +0300, Narvi wrote: Should you decide to use vinum keep in mind that you: a) reboot to make sure that whatever you just set up can automatically start itself This is always a good idea. You don't have to do it immediately, of course. b) alternatively vinum l vinum makedev vinum create -f configfile vinum start is your friend and avoids most of the problem I don't understand why you would want to do this. You certainly don't want vinum create followed by vinum start. Well, maybe 'vinum start' is not needed. vinum l - load vinum, but not teh disk conf vinum makedev - clean the /dev/vinum directory vinum create ... - tell vinum what the setup is. IMHO it should not panick the kernel when it doesn't like the disk setup. IMO it shouldn't panic. Could it be there's more to this message than you're divulging? Well, that happens if you post too late. The problem is (see a)) that it does not automatically start, or rather, it tries but immediately panicks. And vinum read panicks the system, as does vinum start. The system is 3.3-STABLE, less than a week old. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
