Re: newsyslog(8) should wait(2) for children
Maxim Konovalov wrote: > > [ ... patch to wait for children, but do nothing with the result ... ] > > > > Why not just set the signal handler for the child process > > termination to "ignore", so that the child processes do > > not become zombied in the first place, so it's not ever > > necessary to do a useless loop whose only purpose is to > > reap zombies without examining their exit status? > > There are two purposes: > > a) reap zombies, > b) exit after all children have done only. > > In the current implementation newsyslog(8) forks and execs gzip(1) or > bzip2(1) and exits immediately. If a log file(s) is big enough the > compress_log() process(es) will work after newsyslog's death and there > is no clear way to get know when it(they)'s done. Your (a) is statisfied with either approach. I don't understand why you think (b) is a requirement. > OpenBSD: > > a) SIGCHLD signal handler: waitpid(2) loop, do not examine "status", > b) the same waitpid(2) loop before exit(2). > > I do not think we need a) at all. newsyslog forks/execs all his > children and enters into the reap loop like SIGCHLD signal handler > does. The point of this is to not reap until you have to; the default case will be no reaping necessary, so you are adding overhead unnecessarily by atttempting to reap non-existant children. > NetBSD: > > a) waitpid(2) for a child right after fork/exec, > b) examine "status" and print an exit code. > > As you see, NetBSD newsyslog serializes fork/exec and there is only > one gzip process at the same moment. We can take this way but IMHO it > will be a POLA violation. I think the reason NetBSD does this is that there is a sizeof(uncompressed) + sizeof(compressed) window during the operation itself. If you run out of disk space while this is going on, it's a bad thing. So serializing gets you: i. No contention for the remaining disk space between more than one process ii. The ability to not attempt things you know will fail (average compressability will remain constant over a given log file contents, statistically) iii.A reduction in the maximum instantaneous CPU load committed to the newsyslog operation (by serializing, the total load is spread over time) There are arguments for both approaches, but if you want to wait for the operation to complete, the OpenBSD approach is better than a reap-loop. If you are going to interlock, then interlock. If you aren't, then don't bother explicitly reaping. Realize also that the zombied processes shouldn't hang around forever: newsyslog isn't a daemon. And the zombied processes only take up 64 bytes of memory until they are reaped on the exit of newsyslog. Not that I'm arguing that the processes shouldn't be reaped, or at least ignored. -- 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_tc.c src/sys/sys timepps.h timetc.h
On Saturday 27 April 2002 4:51 am, Kris Kennaway wrote: > On Fri, Apr 26, 2002 at 02:51:08PM -0700, Poul-Henning Kamp wrote: > > phk 2002/04/26 14:51:08 PDT > > > > Modified files: > > sys/kern kern_tc.c > > sys/sys timepps.h timetc.h > > Log: > > This commit causes the bento package cluster to hang at boot time: > > [...] > Timecounters tick every 10.000 msec > ad0: 29314MB [59560/16/63] at ata0-master UDMA66 > Mounting root from nfs: > > And it hangs there forever. Backing out this commit fixes things. It hangs on my ia64 diskless box too. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3Com 3c905C-TX
On Wed, May 01, 2002 at 11:49:02PM +0200, Sten wrote: > The only way to use them reliably is to force > both the card and the switch. We came to the > conclusion that fxp's are a nicer option. I have exchanged the 3Com NIC for an Intel one. I'm using an Intel NIC at work and haven't had any problems with it under FreeBSD. What remains strange though is that the 3Com NIC used to work just fine. As said before the strange behaviour (full-duplex -> half-duplex) occurred about a month ago. Around the same time I performed a 'make world'. Was the xl driver changed somehow in the period before that? -- Guido msg37951/pgp0.pgp Description: PGP signature
Re: 3Com 3c905C-TX
--- Guido Kollerie <[EMAIL PROTECTED]> wrote: > I have exchanged the 3Com NIC for an Intel one. I'm using an > Intel NIC at work and haven't had any problems with it under > FreeBSD. What remains strange though is that the 3Com NIC used to > work just fine. As said before the strange behaviour > (full-duplex -> half-duplex) occurred about a month ago. Around > the same time I performed a 'make world'. Was the xl driver > changed somehow in the period before that? It doesnt look like, accept for the following two deltas: o rev. 1.103 by [EMAIL PROTECTED] CVS Log: Remove __P. Branch: MAIN CVS Tags: HEAD o rev. 1.104 by [EMAIL PROTECTED] CVS Log: Change callers of mtx_init() to pass in an appropriate lock type name. In most cases NULL is passed, but in some cases such as network driver locks (which use the MTX_NETWORK_LOCK macro) and UMA zone locks, a name is used. Branch: MAIN CVS Tags: HEAD Those are the only two revisions made to the if_xl.c driver in the timeframe you have provided; and I don't think they can cause the issue you have described, IMHO. -- Hiten Pandya __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
> >From the keyboard of M. Warner Losh: > > My take on this. We should remove perl from the base, and > > automatically install the port for most users in sysinstall, just like > > we do with XFree86. > > OK, fine and if then an option "FETCH_MAKE_AND_INSTALL_PERL_FROM_PORTS" > is added to make.conf and made working so that make buildworld/installworld > updates go transparenly without loosing perl (or any other component of the > current base system, which will for shure be removed taking the perl > removal as a precedent case) then i'm calmed down. This won't work - perl won't cross-build. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newsyslog(8) should wait(2) for children
On 01:04-0700, May 2, 2002, Terry Lambert wrote: > Maxim Konovalov wrote: > > > [ ... patch to wait for children, but do nothing with the result ... ] > > > > > > Why not just set the signal handler for the child process > > > termination to "ignore", so that the child processes do > > > not become zombied in the first place, so it's not ever > > > necessary to do a useless loop whose only purpose is to > > > reap zombies without examining their exit status? > > > > There are two purposes: > > > > a) reap zombies, > > b) exit after all children have done only. > > > > In the current implementation newsyslog(8) forks and execs gzip(1) or > > bzip2(1) and exits immediately. If a log file(s) is big enough the > > compress_log() process(es) will work after newsyslog's death and there > > is no clear way to get know when it(they)'s done. > > Your (a) is statisfied with either approach. > > I don't understand why you think (b) is a requirement. Let's imagine: # /usr/sbin/newsyslog && ./make_something_with_compressed_log newsyslog exited but there are several compress_log() processes are still running and make_something_with_compressed_log will get a half-compressed logs. > > OpenBSD: > > > > a) SIGCHLD signal handler: waitpid(2) loop, do not examine "status", > > b) the same waitpid(2) loop before exit(2). > > > > I do not think we need a) at all. newsyslog forks/execs all his > > children and enters into the reap loop like SIGCHLD signal handler > > does. > > The point of this is to not reap until you have to; the default > case will be no reaping necessary, so you are adding overhead > unnecessarily by atttempting to reap non-existant children. As you see, OpenBSD has (a) *and* (b). > > NetBSD: > > > > a) waitpid(2) for a child right after fork/exec, > > b) examine "status" and print an exit code. > > > > As you see, NetBSD newsyslog serializes fork/exec and there is only > > one gzip process at the same moment. We can take this way but IMHO it > > will be a POLA violation. [ NetBSD approach arguments ] > There are arguments for both approaches, but if you want to > wait for the operation to complete, the OpenBSD approach is > better than a reap-loop. Again, OpenBSD has a reap loop. [...] -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users?
> From: [EMAIL PROTECTED] ("M. Warner Losh")
> Date: Thu 2 May, 2002
> Subject: Re: Save a few hunderd kilobytes or a few hundred perl users?
> My take on this. We should remove perl from the base, and
> automatically install the port for most users in sysinstall, just like
> we do with XFree86.
XFree86 doesn't stomp on /usr/local (nor does the other port semi-
automatically installed via sysinstall, linux_base).
As part of the process of packaging the base system, I support the
idea of a new type of more tightly integrated package, installed in
/usr (for the core packages) or /usr/{opt,pkg,contrib}. "ports"
would remain as they are, though (seems too late to reclaim
/usr/local if you ever want to use those...).
Cheers,
Mark (sole member of the Reclaim /usr/local Campaign).
--
Mark Valentine, Thuvia Labs <[EMAIL PROTECTED]>
"Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses
"We're kind of stupid that way." *munch* *munch*and endorses FreeBSD
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
PAM doesn't allow to log-in when /var mounted ro
Hi, Subject says it all. I'm getting the following from the syslog: login: cannot open /var/log/lastlog: Read-only file system login: pam_open_session(): error in service module This violates POLA, therefore please fix ASAP. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAM doesn't allow to log-in when /var mounted ro
On Thu, May 02, 2002 at 04:24:16PM +0300, Maxim Sobolev wrote: /var mounted ro sounds like a truly bad idea to me BTW. > Hi, > > Subject says it all. I'm getting the following from the syslog: > > login: cannot open /var/log/lastlog: Read-only file system > login: pam_open_session(): error in service module > > This violates POLA, therefore please fix ASAP. > > -Maxim > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message ---end of quoted text--- -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAM doesn't allow to log-in when /var mounted ro
Wilko Bulte wrote: > > On Thu, May 02, 2002 at 04:24:16PM +0300, Maxim Sobolev wrote: > > /var mounted ro sounds like a truly bad idea to me BTW. This has nothing to do with the fact that PAM refuses authentification request when it's unable to open lastlog rw. -Maxim > > > Hi, > > > > Subject says it all. I'm getting the following from the syslog: > > > > login: cannot open /var/log/lastlog: Read-only file system > > login: pam_open_session(): error in service module > > > > This violates POLA, therefore please fix ASAP. > > > > -Maxim > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > ---end of quoted text--- > > -- > | / o / /_ _ [EMAIL PROTECTED] > |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Save a few hunderd kilobytes or a few hundred perl users
> The base will no longer depend on it before too much longer. The vnode > and kobj dependencies are already gone in current. Ahh, ok, if that's the case, then I agree with your original statement; not that it matters much :-) Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CD-Boot hangs on rootmounting MD (+DP1 crashes)
Am Do , 2002-05-02 um 17.44 schrieb John Baldwin: > > On 02-May-2002 Harald Schmalzbauer wrote: > > Am Do , 2002-05-02 um 13.29 schrieb Harald Schmalzbauer: > > > > PXEbooting the -stable kernel.gz and mfsroot results in the same system > > hang (mounting root from ufs:/dev/md0c). > > > > DP1 crashes with the following: > > unknown: can't assign resources (port) > > unknown: can't assign resources (memory) > > psmcpnp0: irq resource info is missing; assuming irq 12 > > > > Fatal trap12: page fault while in kernel mode > > fault virtual address = 0x0 > > fault code= supervisor read, page not present > > instruction pointer = 0x8:0xc164cac1 > > stack pointer = 0x10:0xcb931d00 > > frame pointer = 0x10:0xcb931d1c > > 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 = 27 (irq10: sn0) > > trap number = 12 > > panic: page fault > > Can you stick ddb in this kernel adn get a traceback? It's a NULL > pointer dereference bug. > > Actually, for DP1, isn't ddb already in the kernel? Of course, but somebody needs to tell me what to do (I wrote the last line of code 12 years ago in Pascal, and I've never used gdb) I think I can remember that there is some debuging FAQ but I can't read it NOW (perhaps at the weekend) If it isn't too complicated and understanding the things I'm typing is not needed, just tell me what to do (outside the list?) -Harry > > -- > > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > "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
Re: CD-Boot hangs on rootmounting MD (+DP1 crashes)
On 02-May-2002 Harald Schmalzbauer wrote: > Am Do , 2002-05-02 um 17.44 schrieb John Baldwin: >> >> On 02-May-2002 Harald Schmalzbauer wrote: >> > Am Do , 2002-05-02 um 13.29 schrieb Harald Schmalzbauer: >> > >> > PXEbooting the -stable kernel.gz and mfsroot results in the same system >> > hang (mounting root from ufs:/dev/md0c). >> > >> > DP1 crashes with the following: >> > unknown: can't assign resources (port) >> > unknown: can't assign resources (memory) >> > psmcpnp0: irq resource info is missing; assuming irq 12 >> > >> > Fatal trap12: page fault while in kernel mode >> > fault virtual address = 0x0 >> > fault code= supervisor read, page not present >> > instruction pointer = 0x8:0xc164cac1 >> > stack pointer = 0x10:0xcb931d00 >> > frame pointer = 0x10:0xcb931d1c >> > 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 = 27 (irq10: sn0) >> > trap number = 12 >> > panic: page fault >> >> Can you stick ddb in this kernel adn get a traceback? It's a NULL >> pointer dereference bug. >> >> Actually, for DP1, isn't ddb already in the kernel? > > Of course, but somebody needs to tell me what to do (I wrote the last > line of code 12 years ago in Pascal, and I've never used gdb) > > I think I can remember that there is some debuging FAQ but I can't read > it NOW (perhaps at the weekend) > > If it isn't too complicated and understanding the things I'm typing is > not needed, just tell me what to do (outside the list?) Well, when you boot dp1 you should get a 'db>' prompt after the panic. Just type 't' to get a backtrace, then mail the contents of that trace to the list. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "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
Re: cc1 crashes with SIGBUS while building XFree86-Server-4.2.0_2
Fluid <[EMAIL PROTECTED]> wrote: > How about signal 4? I was rebuilding my -current the other day and I > kept getting mostly signal 4 errors (in different places) with a couple > of signal 10's and 11's. I tried finding a run-down of what the various > errors meant, but I couldn't find a thing. The signal number mapping is in /usr/include/sys/signal.h. [ Um, if you don't know what the signals mean, you might not want to be running -current. ] SIGILL (signal 4) is usually not good (e.g., bad RAM, IDE data corruption, etc.). > The weird thing is that when > I switched terminals in KDE (i.e. opened a new Konsole window), my build > problems ceased. Possible bad RAM: the new window allocated enough memory such that a bad spot in memory was allocated to the new Konsole's process, and not randomly to the build processes. > Windows XP runs on the same box with no problems (i.e. > will run for weeks without a reboot) so I'm a little hesitant to blame > my hardware. This doesn't necessarily mean much. Windows will either not stress the hardware as much, or will use RAM in different ways. I seem to recall hearing rumors that Windows allocates memory from the top down. If so, and if FreeBSD allocates memory from the bottom up (I don't know), that could explain why you do not appear to be seeing the problem under xp. However, as other people are having mysterious problems with -current, it could be a software problem. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newsyslog(8) should wait(2) for children
Maxim Konovalov wrote: > > > b) exit after all children have done only. > > > > > > In the current implementation newsyslog(8) forks and execs gzip(1) or > > > bzip2(1) and exits immediately. If a log file(s) is big enough the > > > compress_log() process(es) will work after newsyslog's death and there > > > is no clear way to get know when it(they)'s done. > > > > Your (a) is statisfied with either approach. > > > > I don't understand why you think (b) is a requirement. > > Let's imagine: > > # /usr/sbin/newsyslog && ./make_something_with_compressed_log > > newsyslog exited but there are several compress_log() processes are > still running and make_something_with_compressed_log will get a > half-compressed logs. You probably meant to say "half the logs compressed", not "half-compressed logs". As far as "half-compressed logs", where a single log file can end up partially compressed -- that can't happen. If it fails to successfully compress, gzip will revert and not compress the file. Overall, allowing multiple processes, and waiting for them to finish still doesn't accomplish anything: "exited" != "exited successfully" If any process has failed to exit successfully, then you can end up with half your logs compressed and half not. If you do the NetBSD approach and serialize, you actually *do* accomplish something: you guarantee that the list of files will be processed in a specific order, and if one fails processing, no subsequent processing will be attempted. This is the most recoverable case, in terms of script based automatic recovery. > > > > OpenBSD: > > > > > > a) SIGCHLD signal handler: waitpid(2) loop, do not examine "status", > > > b) the same waitpid(2) loop before exit(2). > > > > > > I do not think we need a) at all. newsyslog forks/execs all his > > > children and enters into the reap loop like SIGCHLD signal handler > > > does. > > > > The point of this is to not reap until you have to; the default > > case will be no reaping necessary, so you are adding overhead > > unnecessarily by atttempting to reap non-existant children. > > As you see, OpenBSD has (a) *and* (b). You misunderstand. The reaping should be accomplished in the SIGCLD handler. > > There are arguments for both approaches, but if you want to > > wait for the operation to complete, the OpenBSD approach is > > better than a reap-loop. > > Again, OpenBSD has a reap loop. A reap-loop in a SIGCLD handler is a better idea. I still don't understand why you want to delay exiting of the parent until the child processes are finished. I also don't understand why you want a zombie to pile up for each process, until you hit your "reap loop", rather than handling them as you get SIGCLDs. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CD-Boot hangs on rootmounting MD (+DP1 crashes)
Am Do , 2002-05-02 um 17.44 schrieb John Baldwin: > > On 02-May-2002 Harald Schmalzbauer wrote: > > Am Do , 2002-05-02 um 13.29 schrieb Harald Schmalzbauer: > > > > PXEbooting the -stable kernel.gz and mfsroot results in the same system > > hang (mounting root from ufs:/dev/md0c). > > > > DP1 crashes with the following: > > unknown: can't assign resources (port) > > unknown: can't assign resources (memory) > > psmcpnp0: irq resource info is missing; assuming irq 12 > > > > Fatal trap12: page fault while in kernel mode > > fault virtual address = 0x0 > > fault code= supervisor read, page not present > > instruction pointer = 0x8:0xc164cac1 > > stack pointer = 0x10:0xcb931d00 > > frame pointer = 0x10:0xcb931d1c > > 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 = 27 (irq10: sn0) > > trap number = 12 > > panic: page fault > > Can you stick ddb in this kernel adn get a traceback? It's a NULL > pointer dereference bug. > > Actually, for DP1, isn't ddb already in the kernel? OK, I found kernel.debug on the CD which I pxebooted and after typing 't' it gives me the following: _end(c2521300,cdaf7d48,c2521300,c0232754,0) at 0xc252da80 fork_exit(c0232754,c2521300,cdaf7d48) at fork_exit+0x98 fork_trampoline() at fork_trampoline+0x8 Just for info: I forgot to mention the built-in Bluetooth. Hope this helps, -Harry > > -- > > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > "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
SMP: httpd stuck in "*Giant" state
I am running FreeBSD 5.0 on Alpha 7310. Apache httpd was running fine for a week and today after I've added mod_php4 I got after 30 min a condition when all httpd's were reported by top as "*Giant" not responding to TCP requests and "killall -9 httpd" didn't kill any of them. Anyone have any idea/clue how/why this might be happening? I removed mod_php4 from httpd and rebooted alpha -- now it seems to be ok. So I don't know was it related to mod_php4 or it's a coincidence. Also maybe anyone can suggest documentation for SMP? Thank you, Yuri. __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAM doesn't allow to log-in when /var mounted ro
Wilko Bulte wrote: > On Thu, May 02, 2002 at 04:24:16PM +0300, Maxim Sobolev wrote: > > /var mounted ro sounds like a truly bad idea to me BTW. You could rename it "/invar"... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAM doesn't allow to log-in when /var mounted ro
Maxim Sobolev wrote: > This has nothing to do with the fact that PAM refuses authentification > request when it's unable to open lastlog rw. man pam.conf /optional ...then compare "required", "requisite", "sufficient", and "optional". -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: SMP: httpd stuck in "*Giant" state
On 02-May-2002 Yuri Victorovich wrote: > I am running FreeBSD 5.0 on Alpha 7310. > > Apache httpd was running fine for a week and today > after I've added > mod_php4 I got after 30 min a condition when all > httpd's were reported > by top as "*Giant" not responding to TCP requests and > "killall -9 httpd" didn't kill any of them. Ok, so they are all blocked. Does the machine respond to other interrupts ok? I.e., can you ssh into the machine and what not? Or is the machine basically hung? -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "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
RE: SMP: httpd stuck in "*Giant" state
> Ok, so they are all blocked. Does the machine > respond to > other interrupts ok? I.e., can you ssh into the > machine > and what not? Or is the machine basically hung? Everything else was just fine. Actually I was runnning top through ssh. In /var/log/messages also nothing relevant. Yuri. __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: mount_std(8) consumers conversion to nmount
Hello, I am going to commit patches that convert all the mount_std consumers to the nmount framework; namely devfs, fdescfs, linprocfs and procfs. This results in an ABI breakage, so you need to update your mount_std(8) utility. I have changed mount_std(8) to try a mount() call first, and then a nmount() call in revision 1.13 of mount_std.c. If you rebuilt it since (this commit was done the 7th of April), you're safe. If you didn't, you will not be able to mount these filesystems anymore. Please note that even if you updated it, you will get some warnings from the kernel since it tries mount() before nmount(). Once these commits are done, I'll change the order of the calls to get rid of these warnings. I will still keep the mount() call for some time, in the case there are external filesystems using mount_std. Thanks for your attention, Maxime Henrion To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CD-Boot hangs on rootmounting MD (+DP1 crashes)
Am Do , 2002-05-02 um 13.29 schrieb Harald Schmalzbauer: PXEbooting the -stable kernel.gz and mfsroot results in the same system hang (mounting root from ufs:/dev/md0c). DP1 crashes with the following: unknown: can't assign resources (port) unknown: can't assign resources (memory) psmcpnp0: irq resource info is missing; assuming irq 12 Fatal trap12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc164cac1 stack pointer = 0x10:0xcb931d00 frame pointer = 0x10:0xcb931d1c 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 = 27 (irq10: sn0) trap number = 12 panic: page fault >From the console print I can't find a sn device nor any assigned irq10. Hardware description: PIII-M (LV) 800 256MB (2x 128MB mini DIMM) i815em VGA/Chipset, heavily Sony-modified Award BIOS (showing only one IDE while FreeBSD claims to find also secondary, almost no adjustments possible (except PNP-OS yes/no)) Orinoco mini-PCI WaveLAN USB-MemoryStick reader TexasInstruments IEEE-1394 TexasInstruments PCI-1410 CARDBUS CONTROLLER Ricoh RL5C475 CARDBUS CONTROLLER ICH Modem 80F2 82801BAM USB 2442 82801BAM USB 2444 Intel Pro100/VE Ethernet (I think only PHY for i815) I hope this helps helping me;-) Thanks, -Harry > Hello all, > > I'm trying to install FreeBSD 4.5-stable-iso from yesterday and I have > the same problem like with 4.5-release: After probing the sistem hangs > when trying to mount root from md. > > My box is a VAIO SRX41P with the PC-CARD CDROM. I have no Disk-Drive so > unfortunately I can't check floppy-boot. > > I think this has something to do with PC-Card. I can remember I had a > similar problem when PXE-booting a Soekris Net4501 (CF-Memory, no ATA). > > Right now I'm downloading DP1 to check it with 5.0. > > Just to mention: Booting OpenBSD is working but CD is not supported. > > Suggestions are welcome (BIOS doesn't boot USB-CD, no Floppy available, > no Firewire CD, PXE-Boot possible but first I'll try 5.0). > > Thanks, > > -Harry > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CD-Boot hangs on rootmounting MD (+DP1 crashes)
On 02-May-2002 Harald Schmalzbauer wrote: > Am Do , 2002-05-02 um 13.29 schrieb Harald Schmalzbauer: > > PXEbooting the -stable kernel.gz and mfsroot results in the same system > hang (mounting root from ufs:/dev/md0c). > > DP1 crashes with the following: > unknown: can't assign resources (port) > unknown: can't assign resources (memory) > psmcpnp0: irq resource info is missing; assuming irq 12 > > Fatal trap12: page fault while in kernel mode > fault virtual address = 0x0 > fault code= supervisor read, page not present > instruction pointer = 0x8:0xc164cac1 > stack pointer = 0x10:0xcb931d00 > frame pointer = 0x10:0xcb931d1c > 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 = 27 (irq10: sn0) > trap number = 12 > panic: page fault Can you stick ddb in this kernel adn get a traceback? It's a NULL pointer dereference bug. Actually, for DP1, isn't ddb already in the kernel? -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "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
Re: cvs commit: src/sys/kern kern_tc.c src/sys/sys timepps.h timetc.h
On Thu, May 02, 2002 at 09:18:17AM +0100, Doug Rabson wrote: > On Saturday 27 April 2002 4:51 am, Kris Kennaway wrote: > > On Fri, Apr 26, 2002 at 02:51:08PM -0700, Poul-Henning Kamp wrote: > > > phk 2002/04/26 14:51:08 PDT > > > > > > Modified files: > > > sys/kern kern_tc.c > > > sys/sys timepps.h timetc.h > > > Log: > > > > This commit causes the bento package cluster to hang at boot time: > > > > [...] > > Timecounters tick every 10.000 msec > > ad0: 29314MB [59560/16/63] at ata0-master UDMA66 > > Mounting root from nfs: > > > > And it hangs there forever. Backing out this commit fixes things. > > It hangs on my ia64 diskless box too. I haven't tryed backing the commits out yet, but I'm seeing similar behavior on my HP Omnibook 500. In my case, it's actually not quite hung. What appears to be happening is that nothing is causing the console buffer to actually flush. The system is up (sort of), but the only way to see the console output is to cause a kernel printf, say be breaking in to the debugger. The system is basicaly useless at that point and you can't shutdown cleanly. -- 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 msg37973/pgp0.pgp Description: PGP signature
Re: cvs commit: src/sys/kern kern_tc.c src/sys/sys timepps.h timetc.h
On Thu, May 02, 2002 at 03:30:40PM -0700, Brooks Davis wrote: > I haven't tryed backing the commits out yet, but I'm seeing similar behavior > on my HP Omnibook 500. In my case, it's actually not quite hung. What > appears to be happening is that nothing is causing the console buffer to > actually flush. The system is up (sort of), but the only way to see the > console output is to cause a kernel printf, say be breaking in to the > debugger. The system is basicaly useless at that point and you can't > shutdown cleanly. Similar behavior manifests itself on my -current laptop dated before April 27. I.O.W. it appears to freeze but will flush the console if you break to the debugger then hit 'c'. I believe this was caused by an earlier change to the timecounter code. Unfortunately I didn't have time to investigate further. Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
smmsp user check in Makefile.inc1
For those of us using NIS, it'd be nice if the check would be made against the passwd and group maps if the local passwd and group don't have these users. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Can't install ports/emulators/linux_base on -CURRENT
===> Registering installation for rpm-3.0.6_6 ===> Returning to build of linux_base-6.1_1 ===> Patching for linux_base-6.1_1 ===> Configuring for linux_base-6.1_1 ===> Installing for linux_base-6.1_1 setup-2.0.5-1.noarch.rpm filesystem-1.3.5-1.noarch.rpm unpacking of archive failed on file /proc: cpio: chown failed - Operation not supported *** Error code 1 Stop in /usr/ports/emulators/linux_base. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Can't install ports/emulators/linux_base on -CURRENT
On Fri, May 03, 2002 at 02:19:40PM +0930, Thyer, Matthew wrote: > ===> Registering installation for rpm-3.0.6_6 > ===> Returning to build of linux_base-6.1_1 > ===> Patching for linux_base-6.1_1 > ===> Configuring for linux_base-6.1_1 > ===> Installing for linux_base-6.1_1 > setup-2.0.5-1.noarch.rpm > filesystem-1.3.5-1.noarch.rpm > unpacking of archive failed on file /proc: cpio: chown failed - Operation > not supported > *** Error code 1 > > Stop in /usr/ports/emulators/linux_base. Unmount your linprocfs file system first. -- 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 msg37977/pgp0.pgp Description: PGP signature
Re: smmsp user check in Makefile.inc1
Stephen Hocking wrote: > > For those of us using NIS, it'd be nice if the check would be made against the > passwd and group maps if the local passwd and group don't have these users. Actually, the correct fix is to use the id command. It will automagically find it no matter what the passwd source is: peter@overcee[11:38pm]~src/tools/tools/vop_table-148> id -u smmsp 25 peter@overcee[11:38pm]~src/tools/tools/vop_table-149> echo $status 0 peter@overcee[11:38pm]~src/tools/tools/vop_table-150> id -u fake id: fake: no such user peter@overcee[11:38pm]~src/tools/tools/vop_table-151> echo $status 1 Care to whip up a patch? I'll commit it for you. (I'd do it but I'm working on something) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
