Re: how to avoid bullets in the feet (was Re: HEADS UP: sigset_t changescommitted)
Alfred Perlstein wrote: What's really needed is some warning sort of like what we did when the AOUT-ELF convertion happened, there has to be a simple way to test this as part of installworld. Yes, that's exactly what I had in mind. Details still need to be worked out, though. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
[cc list trimmed] John-Mark Gurney wrote: actually, no, I would like this fixed... I will be unable to develope FreeBSD if the tools target doesn't work!! I do all of my compiles on a 3.0-R box (yes, that's right, 3.0-R) and it will basicly stop me from doing any of that... I'm not sure how you are developing, but in general you don't depend on the tools target unless you are rebuilding the system. As long as you don't upgrade to -current for now, there's absolutely nothing to worry about. You can still develop on -stable. You binaries work on -current as well. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Marcel Moolenaar scribbled this message on Sep 30: [cc list trimmed] John-Mark Gurney wrote: actually, no, I would like this fixed... I will be unable to develope FreeBSD if the tools target doesn't work!! I do all of my compiles on a 3.0-R box (yes, that's right, 3.0-R) and it will basicly stop me from doing any of that... I'm not sure how you are developing, but in general you don't depend on the tools target unless you are rebuilding the system. As long as you don't upgrade to -current for now, there's absolutely nothing to worry about. You can still develop on -stable. You binaries work on -current as well. but I'm developing for -current... I do a buildworld on my 3.0-R box and move it over to the box after it's complete... I'm not sure about you, but doing a buildworld over nfs w/ a processor that is sub p133 is not something that really works to well... I am planning on upgrading my 3.0-R to 3.3-R, but that won't fix anything that allows me to build -current on it... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
I know this is not topic related, so appologies in advance ... Sometimes people deserve a pat on the back. This is the best thing since Chocolate Chip cookies :) We're running things like myth2_demo, and it opens the doors to a whole bunch of applications ... e.g. C++ Builder to follow next year (for Linux, but probably running in Linuxulator !!) thanks Reinier BTW: I think that what you are doing is really great !! Hmm... I wonder if the volume in the list will increase with cool apps such as IBM's ViaVoice which needs your mods to work. Tnks ! -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Without proper linux support we are dead . Now I have to get off my soap box and let the work continue 8) Best Regards -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Amancio Hasty wrote: BTW: I think that what you are doing is really great !! Thanks! Hmm... I wonder if the volume in the list will increase with cool apps such as IBM's ViaVoice which needs your mods to work. Already Linux binaries have been tested and confirmed working with the new sigset_t that weren't working before. Luoqi's work to support libvga is also a great thing, BTW. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Richard Wackerbarth wrote: There is nothing fundamental in the toolset which SHOULD care about the underlying kernel. Compilers, loaders, etc. are just programs that operate on the contents of files. Think of compiling the 4.0 system on a 3.3 system as a simpler case of cross compiling. I should be able to compile FreeBSD 4.0/alpha on a FreeBSD 3.3/i386 system. Sigh.. Yes, but if you need the tools you just compiled in your cross-compilation for cross-compilation itself, you'll have a big problem. And that's almost exacly what happens when building world... Using -DNOTOOLS should allow you to build a -current world without installing a new kernel. Stay focussed people! -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
John-Mark Gurney wrote: but I'm developing for -current... I do a buildworld on my 3.0-R box and move it over to the box after it's complete... I'm not sure about you, but doing a buildworld over nfs w/ a processor that is sub p133 is not something that really works to well... Ah, now I understand your use of development. I am planning on upgrading my 3.0-R to 3.3-R, but that won't fix anything that allows me to build -current on it... Try -DNOTOOLS. I don't know if the -current sources depend specifically on -current tools (such as egcs). -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Thu, Sep 30, 1999 at 01:41:41PM +1000, Peter Jeremy wrote: On Thu, Sep 30, 1999 at 01:29:40AM +1000, Marcel Moolenaar wrote: Before attempting to build world, you must make and install a new kernel. The new kernel will contain new syscalls that are needed during build world. doscmd is currently not being build because it needs fixing first. I'd like to voice my concerns with this change as well. The `normal' upgrade procedure has always been to build and install a new world before the new kernel. The only exception I'm aware of has been the aout-elf transition (where a special build procedure was provided). Isn't this backwards? The kernel's the place that can (and must) have the backwards-compatability hooks, for the simple reason that even if you build the world, your ports and third-party applications have to keep running. Kernels are built and updated without corresponding buildworlds all the time. If you change something fairly fundamental about the interface specification for the userland-kernel interaction (say, going to 64-bit file offsets, for an equivelant example), then it seems pretty obvious to me that a program or library compiled to the new spec _cannot_ run on a kernel that doesn't implement it. How could it be otherwise? This seems to be a different argument to the one John-Mark is makeing: he isn't trying to _run_ his new world on his old kernel, just compile it. I agree that there are probably some curly issues regarding building a build-only set of tools. These are obviously going to be _different_ from the equivelant tools that you want built as part of the buildworld, being cross-compilers and so on. I don't know how close the build target is to that ideal. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: my repository is broken (more)
At 9:10 pm +0100 29/9/99, Josef Karthauser wrote: On Wed, Sep 29, 1999 at 04:58:34PM +, Bob Bishop wrote: [...] I now suspect that cvsup.uk.freebsd.org isn't up-to-date. Anyone know anything? [...] In summary - sorry, try again. 'Tis working now :) Yup, looks like we're back in business - thanks! -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: my repository is broken
On Wed, 29 Sep 1999 14:20:25 GMT, Bob Bishop wrote: === usr.sbin/lpr/filters.ru === usr.sbin/lpr/filters.ru/koi2alt make: don't know how to make koi2alt.c. Stop Looks like you haven't updated in a while. Apparently because... moved to koi2alt ...never made it here. What's the easiest way to get back in step? TIA Update your sources, either with CVSup or with cvs update -A. :-) I got bitten by this myself, but the file "arrived" a few hours later. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: just found this
It wasn't a problem in -current due to a different way that things were done there. What things, exactly? I haven't noticed any differences in vfs_cache.c or vfs_subr.c that should affect the caching behavior, so it must just be that the system survives a large amount of wired down memory better. : Really large numbers of hardlinks are probably rare enough, but the : default limit of 4 seems a bit low, it should probably be at least as : high as the maximum link count encountered on a normal installation. : There are other ways to hold down at least as much memory per file you : can keep open as with the limit of 4. I think phk's idea in this area are likely the best way to deal. BTW: None of the solutions address this slower, but simpler attack, easily described using a Bourne Shell command line: $ while mkdir t; do cd t; done The shell version seems to waste lots of memory so it may die before it has wired down a significant amount of vnodes (I've also managed to create an unkillable process this way in 3.2, but I think this is something that was recently fixed), but the equivalent C program runs until the filesystem fills up, the user's quota is exeeded or, most commonly, until too many vnodes have been allocated and the machine locks up. It can take quite a while, though. Creating lots of directories seems slow, even with softupdates. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how to avoid bullets in the feet (was Re: HEADS UP: sigset_t changescommitted)
On Thu, Sep 30, 1999 at 09:19:47AM +0200, Marcel Moolenaar wrote:
Alfred Perlstein wrote:
What's really needed is some warning sort of like what we
did when the AOUT-ELF convertion happened, there has
to be a simple way to test this as part of installworld.
Yes, that's exactly what I had in mind. Details still need to be worked
out, though.
This is what I was thinking of when I mentioned "fixing things".
Going the "good old way" (make world, _then_ build a new kernel)
doesn't have to _work_, the problem right now is that it will
complete, but in the end you'll have a non-running system (and,
the way I understood, it would be non-repearable without a new
binary installation).
An interruption of the build-process at the beginning, displaying
a message ("Please build and install a new kernel first") in this
case would be suficient.
bye,
Harold
--
Shabby Sleep is an abstinence syndrome wich occurs due to lack of caffein.
Wed Mar 4 04:53:33 CET 1998 #unix, ircnet
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
At 10:17 PM + 1999/9/29, Adam Strohl wrote: Furthermore, for when 4.0 becomes a -R or -S, ftping in a compiled kernel shouldn't be that hard of a price to pay for going from 3.2. /stand/sysinstall based upgrades could easily seemlessly take care of this, too. I must confess ignorance (and I haven't exhaustively searched the mailing list archives, the Handbook, or the FAQ), but is this the recommended method of upgrading from a previous major release to the latest -STABLE major release (i.e., going from 2.x to 3.x today, or from 3.x to 4.x when the time comes)? I thought the official procedure was cvsup, or is that for updating only within a particular major release? Thanks! -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o| |o| Systems Architect, News FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new sigset_t and upgrading: a proposal
Hi, In the recent discussion about the breakage of the upgrade path from -stable to -current numerous suggestions and other kinds of remarks have been made. In this light I have the following proposal. Please share your thoughts... NOTE: This proposal only discusses upgrading from -stable to -current. Users already running -current are expected to be capable of building a kernel before doing a make world. The problem --- When doing a make world, tools are being built that are used by the build process. This is to make sure that the tools are appropriate for doing a make world. The problem we now face is that the sigset_t change causes this to break. The tools that are being built use new syscalls not present in a kernel. Not only that, the new tools expect a different sigframe in general. So, the problem can be split into: A) New syscalls using the new sigset_t (sigaction and so on) B) A new sigframe (new siginfo, no sigcontext but ucontext_t) The solution Sub-problem A (syscalls) can be easily handled if the syscalls are added to a -stable kernel. The new sigset_t and dependencies used by these syscalls are converted back and are handled by the kernel in the normal way. The assumption here is that the tools that are needed by the make world are not depended on the extra signals and/or RT signals. Sub-problem B (sigframe) doesn't need to be handled, because: 1. none of the tools required for doing a make world depends on siginfo_t. The only C sources where SA_SIGINFO can be found (not counting /sys) are: ./contrib/sendmail/src/conf.c ./gnu/usr.bin/rcs/lib/rcsutil.c 2. The only program that uses sigcontext (and therefore possibly sigreturn) is doscmd, which is not needed for anything other than DOS emulation. This simply means that the sigframe changes are not visible in general and that the old sigframe should work for the binaries al well. Pros o It's relatively easy. o It won't interfere with the normal operation of a -stable machine and thus won't stretch the meaning of "stable" as a complete backport would do. o It increases inoperability between -stable and -current. o It doesn't require to change the already complex build process. Cons o Upgrading from 3.3 and before to -current is only possible after an upgrade to post 3.3. o It's still hypothetical. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Opti931 Sound Card
Since the new sound code has been committed, my cheapo Opti931 sound card hasn't been working. Hopefully with the dmesg and pnpinfo output which is attached, somebody can add the proper vendor IDs. Much appreciated. Neal Checking for Plug-n-Play devices... Card assigned CSN #1 Vendor ID OPT0931 (0x3109143e), Serial Number 0x PnP Version 1.0, Vendor Version 0 Device Description: OPTi Audio 16 Logical Device ID: OPT 0x143e #0 Vendor register funcs 00 Device Description: AUX0 Logical Device ID: OPT9310 0x1093143e #1 Vendor register funcs 00 Device Description: OPTi Audio 16 TAG Start DF I/O Range 0x534 .. 0x608, alignment 0x4, len 0x4 [16-bit addr] I/O Range 0x380 .. 0x3f0, alignment 0x10, len 0xc [16-bit addr] I/O Range 0x220 .. 0x240, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0xe0c .. 0xffc, alignment 0x4, len 0x4 [16-bit addr] IRQ: 5 7 10 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F DMA: channel(s) 0 1 3 5 6 8/16-bit, not a bus master, count by byte, count by word, Type F TAG Start DF I/O Range 0x534 .. 0xff0, alignment 0x4, len 0x4 [16-bit addr] I/O Range 0x380 .. 0x3f0, alignment 0x10, len 0xc [16-bit addr] I/O Range 0x220 .. 0x240, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0xe0c .. 0xffc, alignment 0x4, len 0x4 [16-bit addr] IRQ: 5 7 9 10 11 - only one type (true/edge) DMA: channel(s) 0 1 3 5 6 8/16-bit, not a bus master, count by byte, count by word, Type F DMA: channel(s) 0 1 3 5 6 8/16-bit, not a bus master, count by byte, count by word, Type F TAG Start DF I/O Range 0x534 .. 0x608, alignment 0x4, len 0x4 [16-bit addr] I/O Range 0x380 .. 0x3f0, alignment 0x10, len 0xc [16-bit addr] I/O Range 0x220 .. 0x240, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0xe0c .. 0xffc, alignment 0x4, len 0x4 [16-bit addr] IRQ: 5 7 10 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F TAG Start DF I/O Range 0x534 .. 0xff0, alignment 0x4, len 0x4 [16-bit addr] I/O Range 0x380 .. 0x3f0, alignment 0x10, len 0xc [16-bit addr] I/O Range 0x220 .. 0x240, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0xe0c .. 0xffc, alignment 0x4, len 0x4 [16-bit addr] IRQ: 5 7 9 10 11 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F TAG Start DF I/O Range 0x534 .. 0xff0, alignment 0x4, len 0x4 [16-bit addr] I/O Range 0x380 .. 0x3f0, alignment 0x10, len 0xc [16-bit addr] I/O Range 0x220 .. 0x240, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0xe0c .. 0xffc, alignment 0x4, len 0x4 [16-bit addr] IRQ: 5 7 9 10 11 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F TAG End DF Logical Device ID: OPT0001 0x0100143e #2 Vendor register funcs 00 Device Description: Game Port I/O Range 0x200 .. 0x20f, alignment 0x1, len 0x1 [16-bit addr] Logical Device ID: OPT0002 0x0200143e #3 Vendor register funcs 00 Device Description: MPU401 I/O Range 0x300 .. 0x360, alignment 0x10, len 0x2 [16-bit addr] IRQ: 5 7 9 10 11 - only one type (true/edge) End Tag Successfully got 53 resources, 4 logical fdevs -- card select # 0x0001 CSN OPT0931 (0x3109143e), Serial Number 0x Logical device #0 IO: 0x 0x 0x 0x 0x 0x 0x 0x IRQ 0 0 DMA 4 4 IO range check 0x00 activate 0x01 Logical device #1 IO: 0x0380 0x0380 0x0380 0x0380 0x0380 0x0380 0x0380 0x0380 IRQ 5 0 DMA 0 1 IO range check 0x00 activate 0x01 Logical device #2 IO: 0x 0x 0x 0x 0x 0x 0x 0x IRQ 0 0 DMA 4 4 IO range check 0x00 activate 0x01 Logical device #3 IO: 0x 0x 0x 0x 0x 0x 0x 0x IRQ 10 0 DMA 4 4 IO range check 0x00 activate 0x01 Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #121: Tue Sep 28 19:34:04 PDT 1999 root@:/usr/src/sys/compile/MILLENNIUM Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 199310064 Hz CPU: Pentium Pro (199.31-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x617 Stepping = 7 Features=0xf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV real memory =
Re: new sigset_t and upgrading: a proposal
On Thu, Sep 30, 1999 at 12:13:32PM +0200, Marcel Moolenaar wrote: The problem --- When doing a make world, tools are being built that are used by the build process. This is to make sure that the tools are appropriate for doing a make world. The problem we now face is that the sigset_t change causes this to break. The tools that are being built use new syscalls not present in a kernel. Not only that, the new tools expect a different sigframe in general. As far as I can see, if this is the case, then this is the only problem. The tools built for a buildworld are tools that have to run on the _current_ platform, whatever that might be, with the new platform as a target. Therefore, they should be build against the existing system include files and libraries, and so should run on the existing system. With these tools, we build the world. As far as I can tell, the problem is installworld. Either: (a) The tools required to build the corresponding new kernel have to be secreted away in an "upgrade-bin" directory, so that they are still accessible after the install world (none of which will run on the existing kernel). (b) You build a new kernel before you do the install-world, reboot, and then installworld. I can't see any bennefit at all to (a), or any problem with (b). As I mentioned in a previous mail, why on earth should we expect user-land programs built to a new API to run on a kernel that doesn't support that API. The converse has always been true, though. Kernels usually support any new API and the previous one or more, so that old applications will still run. That said, I don't mind your idea of extending the stable kernel, but that is still really just a sneaky way of getting the user to build and install a kernel that supports the new API before they try to installworld. Isn't it? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
Marcel Moolenaar wrote: Pros o It increases inoperability between -stable and -current. I mean decreases inoperability or increases operability of course :-/ -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Thu, Sep 30, 1999 at 12:13:32PM +0200, Marcel Moolenaar wrote: So, the problem can be split into: A) New syscalls using the new sigset_t (sigaction and so on) B) A new sigframe (new siginfo, no sigcontext but ucontext_t) "I'm probably missing something, but..." (TM) The new syscall problem has been delt with before by catching the illegal signal and doing it by hand (getcwd works this way in 3.X anyway). Could the signal calls not do the following: 1) On first call use the osignal stuff to catch the illegal syscall signal, and set a have__newsigt if the signal is presnet and then use the new syscalls. 2) If they're not present settle for translating the calls. Once you know if you have the new sigframe or not you can decide if you have to translate. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Thu, 30 Sep 1999, Marcel Moolenaar wrote: Sub-problem B (sigframe) doesn't need to be handled, because: 1. none of the tools require ... Correct, this is a "non-problem". Sub-problem A (syscalls) can be easily handled if the syscalls are added to a -stable kernel. Wrong. I CANNOT rebuild the kernel that runs my build machine. What we need is to (effectively) remove these syscalls from the tools in question. This can be done with conditional compilation or a compatability library. Each tool should be evaluated for its functionality. If the host's tool has the required functionality, there is no reason to upgrade it in order to build the "foreign" (4.0) system. For example, "cat". If the host's tool is inappropriate, we MUST build a cross-build version. In many cases, this simply means that we compile the source of the tool with the host's headers. In others, it is more complex, but it can, and should, be done. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
As a fresh idea (probably stupid, but anyway): Why we can't load compile and small KLD with all necessary syscalls (even probably stubs) to build 4.0 world when someone trying to build it on top of 3.*? -Maxim -- "We believe in the Power and the Might!" (Manowar, 1996) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
Hi, In the recent discussion about the breakage of the upgrade path from -stable to -current numerous suggestions and other kinds of remarks have been made. In this light I have the following proposal. Please share your thoughts... NOTE: This proposal only discusses upgrading from -stable to -current. Users already running -current are expected to be capable of building a kernel before doing a make world. The problem --- When doing a make world, tools are being built that are used by the build process. This is to make sure that the tools are appropriate for doing a make world. The problem we now face is that the sigset_t change causes this to break. The tools that are being built use new syscalls not present in a kernel. Not only that, the new tools expect a different ^^^ Why are the tools being built using new syscalls? What causes this? I can't find it from a quick read of the Makefiles. Should not a proper adjustment to a -I flags on a cc command line some place fix this? Your changes have exposed a very serious short comming of the tools target, and as others have pointed out, if we ever even want to think about getting close to cross compiliation this target must work correctly. Please search mail archives about many various discussions about this over the 6 year history of FreeBSD. IMHO, the only ``correct'' fix for the latest incarnation of the problem is to finally once and for all fix the cross compilation environment instead of using a half cooked tools: target to deal with certain problems. sigframe in general. So, the problem can be split into: A) New syscalls using the new sigset_t (sigaction and so on) B) A new sigframe (new siginfo, no sigcontext but ucontext_t) The solution Sub-problem A (syscalls) can be easily handled if the syscalls are added to a -stable kernel. The new sigset_t and dependencies used by these syscalls are converted back and are handled by the kernel in the normal way. The assumption here is that the tools that are needed by the make world are not depended on the extra signals and/or RT signals. Or even easier to fix, never call them. What in the world is building in the tools target with new syscalls All of that stuff is suppose to be built using the currently installed library/kernel API. If not we are never going to get to cross-compilation. Sub-problem B (sigframe) doesn't need to be handled, because: 1. none of the tools required for doing a make world depends on siginfo_t. The only C sources where SA_SIGINFO can be found (not counting /sys) are: ./contrib/sendmail/src/conf.c ./gnu/usr.bin/rcs/lib/rcsutil.c 2. The only program that uses sigcontext (and therefore possibly sigreturn) is doscmd, which is not needed for anything other than DOS emulation. This simply means that the sigframe changes are not visible in general and that the old sigframe should work for the binaries al well. Good. Pros o It's relatively easy. o It won't interfere with the normal operation of a -stable machine and thus won't stretch the meaning of "stable" as a complete backport would do. o It increases inoperability between -stable and -current. o It doesn't require to change the already complex build process. Cons o Upgrading from 3.3 and before to -current is only possible after an upgrade to post 3.3. Not good. o It's still hypothetical. And in IMNSHO, should probably remain that way. I like real solutions, not fragile bandaids. I think your a pretty smart fellow, anyone who was able to do this with the signal code and have it come out working as well as it has (glenned from other posts about people who have made the jump in -current) should be able to solve yet another engineering problem that was not accounted for at the beginning of your change. You probably solved a dozen of them during this work, whats one more :-) I furthermore think that if you put your mindset in the frame that this is just another engineering problem you'll come up with the ``right solution'' that will make everyone happy. -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Maxim Sobolev wrote: Why we can't load compile and small KLD with all necessary syscalls (even ^^^ I mean ".load and compile small". Cut and paste technology sometimes plays bad jokes with us.;) -Max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Linksys LNE100TX
Fry´s was out of Intel 100/10 ethernet cards, so I bought a Linksys LNE100TX remembering that I there was a driver for it. I added device pn0 to my kernel configuration and compiled the kernel. It was not detected during boot. I added the mii_bus0 controller just in case. Recompiled and still not detected. Does anyone have the LNE100TX working in current? Thanks, ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-CURRENT: libkvm compile fault
Ilya Pekshev wrote: seems that something wrong went with last updates made to signal.h, param.h and user.h in 4.0-CURRENT after last cvsup can't compile ps, vmstat and libkvm. Any thoughs what's wrong? Do a make world. Make a new kernel before doing that. You need the new libraries and headers installed before you can make individual programs. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Marcel Moolenaar wrote: As for AMD, I don't use it. I'll dig into manpages, source code and whatsnot. If possible I'll reconfigure something here so that I can test it on a i386. Thanks. I'll try to get you a stack trace from it today if I can find time. BTW: I'm sorry, that a simple bug in the NFS code made your filesystem go south. I have been working hard to prevent that... I know you have, and there's absolutely no need to apologize. Your commit was a model of excellence in terms of the review process, the heads up message, the commit logs, etc. This machine is a scratch box and if I had to go all the way back to disklabel it wouldn't be much of a disaster. Besides, it appears I only lost files from "/usr/obj". :-) John --- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld dies on compat-43/sigcompat.c
I've installed -current on an x86 laptop, and ran cvsup to update all sources. I build and booted a new kernel (PCCARD). The buildworld dies at: cc -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include -D__DBINTERFACE_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DYP -c /usr/src/lib/libc/../libc/compat-43/sigcompat.c -o sigcompat.o /usr/src/lib/libc/../libc/compat-43/sigcompat.c: In function `sigsetmask': /usr/src/lib/libc/../libc/compat-43/sigcompat.c:66: request for member `__bits' in something not a structure or union /usr/src/lib/libc/../libc/compat-43/sigcompat.c:68: request for member `__bits' in something not a structure or union /usr/src/lib/libc/../libc/compat-43/sigcompat.c: In function `sigblock': /usr/src/lib/libc/../libc/compat-43/sigcompat.c:78: request for member `__bits' in something not a structure or union /usr/src/lib/libc/../libc/compat-43/sigcompat.c:81: request for member `__bits' in something not a structure or union /usr/src/lib/libc/../libc/compat-43/sigcompat.c: In function `sigpause': /usr/src/lib/libc/../libc/compat-43/sigcompat.c:91: request for member `__bits' in something not a structure or union *** Error code 1 Stop in /usr/src/lib/libc. *** Error code 1 ... Can someone shed some light on this? thanks ==Leonard (I'm on the list as [EMAIL PROTECTED] although I'm sending this from work right now...) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Kenneth Wayne Culver wrote: commit. But even then I still ran into problems, although I'm not sure how closely related they are to the changes made. My problems seem to be with the Soren's ata drivers. I'm using Soren's ATA drivers myself without problems. Admitted, I'm only using it to play audio CDs :-) -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linksys LNE100TX
Hmmm...I believe mine is s LNE100TX...I know it's a Linksys, and it's a 10/100 PCI..and it's runnin fine under Current (last make world was about a week ago), as pn0 in my config: device pn0 # Lite-On 82c168/82c169 (``PNIC'') and from dmesg | grep pn0 : pn0: 82c169 PNIC 10/100BaseTX irq 10 at device 12.0 on pci0 pn0: Ethernet address: 00:a0:cc:22:dd:4f pn0: autoneg complete, link status good (full-duplex, 100Mbps) Is it possible that the card you bought could be defective? (have you tried under a release or stable build?). Douglas Kuntz Systems Administrator PC Tech Reports http://www.pctechreports.com ---FreeBSD... The choice of the smart generation--- - Original Message - From: Edwin Culp [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 30, 1999 11:07 AM Subject: Linksys LNE100TX | Fry´s was out of Intel 100/10 ethernet cards, so I bought a Linksys | LNE100TX remembering that I there was a driver for it. | | I added | device pn0 | to my kernel configuration and compiled the kernel. It was not detected | during boot. I added the mii_bus0 controller just in case. Recompiled | and still not detected. | | Does anyone have the LNE100TX working in current? | | Thanks, | | ed | | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linksys LNE100TX
Bill Paul wrote: Of all the gin joints in all the towns in all the world, Edwin Culp had to walk into mine and say: Fry´s was out of Intel 100/10 ethernet cards, so I bought a Linksys LNE100TX remembering that I there was a driver for it. No, you bought an LNE100TX v2.0, forgetting that there's a different driver for it. :) (Isn't it great how the "v2.0" part is written in such tiny letters on the box?) You´re right, I would have never seen it. Thanks. I added device pn0 The v2.0 card uses a chip labeled 82C115 which is supposed to be a "PNIC II." It's really more like a new generation of the Macronix MX98715A: the EEPROM access mechanism is different, and it supports an internal SYM port, 10baseT port and NWAY as opposed to MII. (Actually, the Macronix chips are much closer to the actual DEC register interface than the PNIC.) Since it bears more resemblance to the Macronix chips than to the original PNIC, I added the support for it to the mx driver instead of the pn driver. Translation: try device mx0 instead. You don't need controller miibus0 for this driver as I haven't converted it yet (I still haven't figured out what to do with the internal NWAY support). Did it and got these messages: mx0: LC82C115 PNIC II 10/100BaseTX at device 16.0 on pci0 mx0: couldn't map ports/memory device_probe_and_attach: mx0 attach returned 6 I must be missing something else. Thanks, ed -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld dies on compat-43/sigcompat.c
Leonard Sitongia wrote: I've installed -current on an x86 laptop, and ran cvsup to update all sources. I build and booted a new kernel (PCCARD). The buildworld dies at: cc -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include -D__DBINTERFACE_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DYP -c /usr/src/lib/libc/../libc/compat-43/sigcompat.c -o sigcompat.o /usr/src/lib/libc/../libc/compat-43/sigcompat.c: In function `sigsetmask': /usr/src/lib/libc/../libc/compat-43/sigcompat.c:66: request for member `__bits' in something not a structure or union /usr/src/lib/libc/../libc/compat-43/sigcompat.c:68: request for member `__bits' in something not a structure or union /usr/src/lib/libc/../libc/compat-43/sigcompat.c: In function `sigblock': /usr/src/lib/libc/../libc/compat-43/sigcompat.c:78: request for member `__bits' in something not a structure or union /usr/src/lib/libc/../libc/compat-43/sigcompat.c:81: request for member `__bits' in something not a structure or union /usr/src/lib/libc/../libc/compat-43/sigcompat.c: In function `sigpause': /usr/src/lib/libc/../libc/compat-43/sigcompat.c:91: request for member `__bits' in something not a structure or union *** Error code 1 Stop in /usr/src/lib/libc. *** Error code 1 ... Can someone shed some light on this? You definitely have a header problem. What are your build options? -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
I would have to agree with that. I have never seen such a well documented commit. But even then I still ran into problems, although I'm not sure how closely related they are to the changes made. My problems seem to be with the Soren's ata drivers. The good old "lost contact with device" messages are back and with a vengence. It seems that now (through a mistake of my own, in addition to this problem with the ata drivers) I have to go back to a snapshot of current, and reinstall all the tools, as well as a generic kernel. However, the pnp controller as of the latest snapshot still causes me to lock up hard before I ever get booted. Isn't there some way to disable to pnp0 controller, like in the userconfig part off the boot floppy? = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: AgRSkaterq | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Thu, 30 Sep 1999, John Polstra wrote: Marcel Moolenaar wrote: As for AMD, I don't use it. I'll dig into manpages, source code and whatsnot. If possible I'll reconfigure something here so that I can test it on a i386. Thanks. I'll try to get you a stack trace from it today if I can find time. BTW: I'm sorry, that a simple bug in the NFS code made your filesystem go south. I have been working hard to prevent that... I know you have, and there's absolutely no need to apologize. Your commit was a model of excellence in terms of the review process, the heads up message, the commit logs, etc. This machine is a scratch box and if I had to go all the way back to disklabel it wouldn't be much of a disaster. Besides, it appears I only lost files from "/usr/obj". :-) John --- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Maxim Sobolev scribbled this message on Sep 30: [-- Warning: koi8-r is not compatible with your display.] Maxim Sobolev wrote: Why we can't load compile and small KLD with all necessary syscalls (even ^^^ I mean ".load and compile small". Cut and paste technology sometimes plays bad jokes with us.;) hmmm.. that might be an option of providing a kld that emulates the new syscalls on an older kernel... I would want the patch to be available for staticly linking into the kernel though.. I don't like LKM/KLD's on servers that are suppose to be rock solid... (at least not yet) -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ASSERT macros in the kernel....
I don't seem to see (after not looking very hard) any ASSERT macros for the kernel in FreeBSD. It'd be pretty easy to add them, and they're awfully useful. They're different from INVARIANT support in that they encapsulate (and panic if the assertion is triggered) more inline types of conditions. Any opinions? -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Marcel Moolenaar scribbled this message on Sep 30:
Try -DNOTOOLS. I don't know if the -current sources depend specifically
on -current tools (such as egcs).
well, this may work, but it still doesn't produce a "clean" system to
build with... I don't know the number of times that I've used the
following patch to Makefile.inc1:
+build-env:
+ @echo export PATH=${STRICTTMPPATH}
+ @echo export COMPILER_PATH=${WORLDTMP}/usr/libexec:${WORLDTMP}/usr/bin
+ @echo export GCC_EXEC_PREFIX=${WORLDTMP}/usr/lib/
+ @echo export LD_LIBRARY_PATH=${WORLDTMP}${SHLIBDIR}
+ @echo export LIBRARY_PATH=${WORLDTMP}${SHLIBDIR}:${WORLDTMP}/usr/lib
+ @echo export DESTDIR=${WORLDTMP}
+
.include bsd.subdir.mk
this allows me to do eval `make build-env`, and suddenly, my build
environment on my 3.0-R box becomes a standard -current world that allows
me to build kernels, programs and other things as if I WAS on a -current
box...
loosing this ability is a big problem for me... I'd even go w/ a simple
option that converts all the signal macros into functions which get
switched depending upon the kernel... and you only get the performance
penalty if you define the option, and it would allow everything to be
backwards compatible...
--
John-Mark Gurney Voice: +1 408 975 9651
Cu Networking
"The soul contains in itself the event that shall presently befall it.
The event is only the actualizing of its thought." -- Ralph Waldo Emerson
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Linksys LNE100TX
Douglas Kuntz wrote: Hmmm...I believe mine is s LNE100TX...I know it's a Linksys, and it's a 10/100 PCI..and it's runnin fine under Current (last make world was about a week ago), as pn0 in my config: device pn0 # Lite-On 82c168/82c169 (``PNIC'') and from dmesg | grep pn0 : pn0: 82c169 PNIC 10/100BaseTX irq 10 at device 12.0 on pci0 pn0: Ethernet address: 00:a0:cc:22:dd:4f pn0: autoneg complete, link status good (full-duplex, 100Mbps) Is it possible that the card you bought could be defective? (have you tried under a release or stable build?). Douglas Kuntz Systems Administrator PC Tech Reports http://www.pctechreports.com ---FreeBSD... The choice of the smart generation--- - Original Message - From: Edwin Culp [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 30, 1999 11:07 AM Subject: Linksys LNE100TX | Fry´s was out of Intel 100/10 ethernet cards, so I bought a Linksys | LNE100TX remembering that I there was a driver for it. | | I added | device pn0 | to my kernel configuration and compiled the kernel. It was not detected | during boot. I added the mii_bus0 controller just in case. Recompiled | and still not detected. | | Does anyone have the LNE100TX working in current? | | Thanks, | | ed | Thank you very much. I thought that was what I had, but it is an 82C115 that is the mx driver. Thanks again, ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
"Rodney W. Grimes" wrote: IMHO, the only ``correct'' fix for the latest incarnation of the problem is to finally once and for all fix the cross compilation environment instead of using a half cooked tools: target to deal with certain problems. brainstorm: Upgrading cannot be solved if it is approached as being nothing more than a cross-compilation. This can be easily seen by the following cross-compilation prerequisites: 1. A compiler C running on machine 1 and capable of generating code for machine 2 (the compiler includes headers and libraries), 2. Source code compatible with compiler C, but also with machine 2. The problem is that upgrading can violate the first part of rule 2 (source code compatible with the compiler), because you have new sources (say -current) which you want to compile with an old compiler (say -stable). Think of having ANSI C extensions without the proper support for it in the compiler. The current build-tools target tries to solve that by creating a compiler C' by using cross-compilation. The result violates rule 1: Compiler C' is build for machine 2 and not for machine 1 and therefore should not be used on machine 1. This is where the discussion is all about. So, as long as rule 2 is not violated, cross-compilation can be used to to build a -current system on -stable and thus also to handle upgrades. The problem is in the case where rule 2 is violated. What's needed is the ability to "port" the proper tools to machine 1. Well, the first thing that comes to mind is the ports collection... Example: If gcc on -stable can not be used to build a -current world, then egcs must be installed from the ports collection and build as part of the upgrade/cross-compilation. the egcs port does not violate rule 1 and since egcs is used on -current, rule 2 is also not violated. The build process uses egcs to do the cross-compilation. This implies that: 1. The ports collection must contain ports for all the tools that are needed for doing cross-compilations and/or upgrades from any supported source version to any supported target version. 2. An easy, yet flexible way must be used to be able to tell whether ports must be installed or not. Simple rules like ".if $source srcvers .and $target trgvers .then install egcs" where $source = `sysctl kern.osreldate` and so on, may be sufficient. Am I being clear? Do I make any sense? :-) Does this in fact cover it? Can it be done? BTW: I'm running a make buildworld on -stable with -current sources. I'm making assumptions I like to see verified... I furthermore think that if you put your mindset in the frame that this is just another engineering problem you'll come up with the ``right solution'' that will make everyone happy. You don't have to be a committer for long to know that you can't make everyone happy :-) -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Thu, 30 Sep 1999, Marcel Moolenaar wrote: The upgrading from -stable to -current is currently being tested by Bill Fumerola. I can imagine that some might be broken in that case. This I will attempt to fix, then... As others have mentioned 3.3-STABLE right now cannot build 4.0-CURRENT kernels. Without the 4.0-CURRENT kernel, I can't build the 4.0 world to build the 4.0 kernel, and so on. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sound etc,
Hi! I have bought the official version of FreeBSD 3.2 and tried to get the sound to work but it doesn't. I tried 4Front's software but that doesn't work either. I get messages that I can't configure /dev/dsp: device is busy all of the time. Somtimes I can't allocate 32768 M problems. After reading a how-to on AWE (I have a SoundBlaster AWE64 PnP) sound cards http://members.home.net/conrads/awepnp-freebsd.html, it still doesn't work. Then, 4Front said I should try FreeBSD 3.3 but it still doesn't work. I do get an error when I tried using awe0 at 0x620: device is not found when the computer boots. I wonder if that is hanging the computer. Also, your boot cdrom (3.3) doesn't boot. 3.2 does though. I don't know if you are aware of it. In addition, everytime I reboot, my master boot record gets erase to know which partition is made active. I have to boot into dos and fdisk to make the mbr active. These problems I didn't have with 3.2. Thanks in advance, Rick
Re: new sigset_t and upgrading: a proposal
"Rodney W. Grimes" wrote: 1. A compiler C running on machine 1 and capable of generating code for machine 2 (the compiler includes headers and libraries), 2. Source code compatible with compiler C, but also with machine 2. And also compatible with machine 1, that is the bugger right now it seems. Have the sources been modified such that they are now no longer portable :-(. I don't think that's necessary. If I have, say, MIPS assembler code, then I should be able to generate MIPS binaries on, say, Intel. MIPS assembler code is clearly not compatible with Intel. This is also true if I would make FreeBSD/Alpha on FreeBSD/i386. I'm speaking true cross-compilation here :-) The current build-tools target tries to solve that by creating a compiler C' by using cross-compilation. The result violates rule 1: Compiler C' is build for machine 2 and not for machine 1 and therefore should not be used on machine 1. This is where the discussion is all about. Then this is an error in the tools target, by design the tools are suppose to be capable of running on machine 1, and producing code for machine 2. But how do you know that you can build tools with sources for machine 2 to run on machine 1? You can't make i386 binaries with alpha assembler sources, for example. To put it differently, isn't this why we need to port software in the first place? Only later when you do the ``make all'' over the tree do you produce the compiler that runs on machine 2. Yes, you may end up building gcc/egcs twice. Just like you may end up building make twice. Yep. Unavoidable. So, as long as rule 2 is not violated, cross-compilation can be used to to build a -current system on -stable and thus also to handle upgrades. The problem is in the case where rule 2 is violated. What's needed is the ability to "port" the proper tools to machine 1. Well, the first thing that comes to mind is the ports collection... Why should ports have code that is any more portable than what is in the src tree? It's not that ports have code that is more portable, ports have patches that are applied as part of the build to make it work on FreeBSD. Also, ports generally still run configure and friends to avoid compatibility problems. This have been staticized (sp?) in the source tree. You should just be able to build egcs from the current sources with the correct options and achive any results you could with a port. But you'll be using -stable headers and libraries (at least, that should be case). This means that egcs, configured to build and run on -current may be improperly configured to build and run on -stable. If you can't, then the src tree has been rendered non-portable. That may as well be the case. I can't give a more definite statement right now. 2. An easy, yet flexible way must be used to be able to tell whether ports must be installed or not. Simple rules like ".if $source srcvers .and $target trgvers .then install egcs" where $source = `sysctl kern.osreldate` and so on, may be sufficient. Irrelivant, just always build the correct set of tools. Trying to maintain a list of the intertwinned dependicies can lead one to madness. Hmmm... Given the 2 cross-compilation prerequisites I gave, it follows that when the source machine has the proper tools for a cross-compilation, you don't need to build any tools as part of the build process itself. It could be advanteous to split a make world into a tools verification and installation phase, followed by the actual (cross)build. This can maybe also be used to handle bootstrapping problems on -current itself (compiling -current on a -current machine). It certainly minimizes unnecessary compilation and thus minimizes the time needed to do a make world. You may be right about going mad if you try to handle the interdependencies, though :-) -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Now that sigcontext is gone ...
I'm trying to digest the recent signal changes and get a handle on what I need to do to make Modula-3 work. There is code in the runtime currently which catches SIGBUS and uses the sigcontext's "sc_err" member to find out the faulting address. That should be replaced by the siginfo_t's "si_addr" member. But as far as I can tell from grepping the kernel sources, that functionality isn't implemented. Is that right? Any ideas regarding a work-around? John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Now that sigcontext is gone ...
I'm trying to digest the recent signal changes and get a handle on what I need to do to make Modula-3 work. There is code in the runtime currently which catches SIGBUS and uses the sigcontext's "sc_err" member to find out the faulting address. That should be replaced by the siginfo_t's "si_addr" member. But as far as I can tell from grepping the kernel sources, that functionality isn't implemented. Is that right? Any ideas regarding a work-around? I'm also very interested in this, so if you could post this information publically, it would be greatly appreciated Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sysinstall/dist.c sigaction update patch
hi,
we're working on a small mod to sysinstall, and we're seeing
the following with the unmodified source since the signal code
going in:
cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog
-I/usr/obj/usr/src/release/sysinstall -I/usr/src/release/sysinstall/../../sys -c
/usr/src/release/sysinstall/dist.c
/usr/src/release/sysinstall/dist.c: In function `distExtract':
/usr/src/release/sysinstall/dist.c:537: incompatible types in assignment
*** Error code 1
Patch for new signalling code is below:
Index: dist.c
===
RCS file: /mirror/ncvs/src/release/sysinstall/dist.c,v
retrieving revision 1.150
diff -u -r1.150 dist.c
--- dist.c 1999/09/19 22:30:38 1.150
+++ dist.c 1999/09/30 19:45:59
@@ -534,7 +534,7 @@
/* Make ^C fake a sudden timeout */
new.sa_handler = handle_intr;
new.sa_flags = 0;
-new.sa_mask = 0;
+(void)sigemptyset(new.sa_mask);
sigaction(SIGINT, new, old);
/* Loop through to see if we're in our parent's plans */
Index: media.c
===
RCS file: /mirror/ncvs/src/release/sysinstall/media.c,v
retrieving revision 1.102
diff -u -r1.102 media.c
--- media.c 1999/09/02 00:51:13 1.102
+++ media.c 1999/09/30 19:47:37
@@ -677,7 +677,7 @@
/* Make ^C abort the current transfer rather than the whole show */
new.sa_handler = handle_intr;
new.sa_flags = 0;
-new.sa_mask = 0;
+(void)sigemptyset(new.sa_mask);
sigaction(SIGINT, new, old);
while ((i = fread(buf, 1, BUFSIZ, fp)) 0) {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
John-Mark Gurney wrote: [..] might as well say goodbye to ever getting freebsd's userland running under NetBSD which is how our nice Alpha port got started... this NEEDS to be fixed... NetBSD have just done exactly the same sort of thing. And for that matter it makes no difference for that sort of thing as we used a different syscall set explicitly in that case. The only "problem" is that -current libc is tightly bound to the -current kernel. How about this as a cheap and robust "solution": - when building libc, have an option that allows sigaction etc to be *wrappers* that emulate their functionality through osigaction(). This means dropping sigaction etc from the assembler function list and use some C stubs instead. Call this (say) -DANCIENTTOOLS for the Makefiles. The objective would be to try not to generate a binary that requires syscalls that are not present on something like 2.2.x. - -DANCIENTTOOLS would be both a make define and a C define, so makefiles could use .if defined(ANCIENTTOOLS) ... to disable new stuff and C code could use #ifdef ANCIENTTOOLS or #ifndef etc. This would mean it would be a lot easier to build make(1) as well since it could avoid using stuff that is only in the latest systems. - this could be used on other libraries (eg: consumers of issetugid()) - what this buys us is we can build the static libraries and build tools with -DANCIENTTOOLS and they'll run on anything from 2.2 onwards. - this can also be used to do some workarounds for old gcc's etc for the build tools too. - this enables us to build the /usr/obj/tmp tree hosted for = 2.2.x but they are -current tools for compiling the *rest* of the system including the real build tools. I think this would solve a lot of chicken/egg problems and would solve the signal syscall issue thing completely. So far we've been lucky. None of the 40-50 odd new syscalls we've added over the last few years have been used in building the tree, so folks have had it easy for a while. Marcel has done *nothing* wrong. This was bound to blow up sooner or later when we added a new syscall that was used during the build. So how about folks get off Marcel's back and stop running around like it's the end of the world and lets do a proper workaround. Rest assured, this will be resolved with a workaround of some sort or other and will be a 4.0-RELEASE requirement that 3.x-stable can do a source upgrade to 4.0. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FICL breakage...
Anyway, all good to know. There are almost certainly more perl speakers than awk speakers these days, so it probably makes sense to do these things in perl rather than awk. I think that's sort of in the grey area. There are also many Hardened Traditionalists(tm) like myself who don't know perl and have no interest in learning it because everything they ever need to do can be handled by sh, awk and sed and they spent many years gaining that level of proficiency with them. We could color our ls and replace sh with bash too, but sometimes there's value in retaining the simpler traditions as you also go forward with the newer tools. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ASSERT macros in the kernel....
:I don't seem to see (after not looking very hard) any ASSERT macros for :the kernel in FreeBSD. It'd be pretty easy to add them, and they're :awfully useful. They're different from INVARIANT support in that they :encapsulate (and panic if the assertion is triggered) more inline types of :conditions. : :Any opinions? : :-matt I don't understand what you want to do. KASSERT() is the standard way to assert something in the kernel, but we do not want to bloat the code unnecessarily so KASSERT()s only do something if INVARIANT support has been turned on. If we need to panic on something whether or not invariant support has been turned on, we currently just use a conditional and a panic. How would ASSERT be different from KASSERT() ? -Matt I don't seem to see (after not looking very hard) any ASSERT macros for That's what it was- I grepped for ASSERT, but somehow missed KASSERT- that's sufficinet for me, I can live with INVARIANTS. Sorry- I'm a moron- never mind To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Now that sigcontext is gone ...
Actually, the last time I looked the Modula-3 run-time system determined the faulting address from the undocumented (except on SunOS 4) 4th argument that most BSD-derived systems passed to the signal handler. There was a time in fact when sc_err wasn't included in the sigcontext on FreeBSD and this was the only way to determine the faulting address. I guess this discussion means that the 4th argument is gone too... Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NFS mod for solaris committed
Oh, I forgot to email current on this...
I've #if 0'd out the NFSERR_BAD_COOKIE code that is partially responsible
for the solaris interoperability problems
I went through the code very carefully and determined that my previous
understanding was just plain wrong. As far as I can tell, the directory
blocks do not get renumbered by the server so it should be ok to not be
so strict when dealing with the cookies.
In anycase, I would like the people with solaris NFS clients who have
encountered this problem to test with this change before I MFC it from
current to stable. It's a very simple patch and you can patch it
into your -STABLE's (if you are using stable) to test it very easily.
I would like to know whether this fixes the problem w/ solaris clients.
It would also be nice if more extensive testing between FreeBSD clients
and servers were done, but that isn't as critical. It's very hard to
reproduce the problem with a FreeBSD client due to the way FreeBSD clients
scan directories.
So, synopsis: The patch has been committed to current but not yet
committed to stable.
-Matt
nfs/nfs_serv.c
revision 1.86
date: 1999/09/29 17:14:58; author: dillon; state: Exp; lines: +5 -1
Make FreeBSD less conservative in determining when to return a cookie
error for a directory. I have made this change after a great deal of
review although I cannot be absolutely sure that this meets the spec.
The issue devolves into whether changes in an underlying (UFS) directory
can cause NFS directory blocks to be renumbered. My read of the code
indicates that NFS directory blocks will not be renumbered, which means
that the cookies should still remain valid after a change is made to
the underlying directory. This being the case, a cookie error should
not be returned when a change is made to the underlying directory and,
instead, the NFS client should rely on mtime detection to invalidate and
reload the directory.
The use of mtime is problematic in of itself, due to insufficient
resolution, which is why I believe the original conservative error
handling was done. Still, there have been dozens of bug reports by
people needing solaris-FreeBSD interoperability and these have to
be accomodated.
Index: nfs_serv.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_serv.c,v
retrieving revision 1.85
retrieving revision 1.86
diff -u -r1.85 -r1.86
--- nfs_serv.c 1999/09/17 05:57:57 1.85
+++ nfs_serv.c 1999/09/29 17:14:58 1.86
@@ -34,7 +34,7 @@
* SUCH DAMAGE.
*
* @(#)nfs_serv.c 8.8 (Berkeley) 7/31/95
- * $FreeBSD: src/sys/nfs/nfs_serv.c,v 1.85 1999/09/17 05:57:57 dillon Exp $
+ * $FreeBSD: src/sys/nfs/nfs_serv.c,v 1.86 1999/09/29 17:14:58 dillon Exp $
*/
/*
@@ -3032,11 +3032,13 @@
nqsrv_getl(vp, ND_READ);
if (v3) {
error = getret = VOP_GETATTR(vp, at, cred, procp);
+#if 0
/*
* XXX This check may be too strict for Solaris 2.5 clients.
*/
if (!error toff verf verf != at.va_filerev)
error = NFSERR_BAD_COOKIE;
+#endif
}
if (!error)
error = nfsrv_access(vp, VEXEC, cred, rdonly, procp, 0);
@@ -3312,11 +3314,13 @@
goto nfsmout;
}
error = getret = VOP_GETATTR(vp, at, cred, procp);
+#if 0
/*
* XXX This check may be too strict for Solaris 2.5 clients.
*/
if (!error toff verf verf != at.va_filerev)
error = NFSERR_BAD_COOKIE;
+#endif
if (!error) {
nqsrv_getl(vp, ND_READ);
error = nfsrv_access(vp, VEXEC, cred, rdonly, procp, 0);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Now that sigcontext is gone ...
Marcel Moolenaar wrote:
That's right, it's not implemented yet. The work-around is to use
ucontext. uc_mcontext contains the trapframe which has tf_err
(uc.uc_mcontext.mc_tf.tf_err).
Thanks.
I haven't paid any attention to implement any of the fields in siginfo_t
because that may only have complicated matters. It may be required to do
some non-trivial rewriting to get all the information at the right
place. Since real-time signals are also in the pipeline and also may
have specific needs, both "problems" can best be considered at the same
time (IMO).
For this particular problem (getting the faulting address) it looks
like it will be easy to fix in "machdep.c:sendsig()". The correct
value should be in regs-tf_err on the i386. It's just a matter of
copying that into sf.sf_si.si_addr here (line 677):
if (SIGISMEMBER(p-p_sigacts-ps_siginfo, sig)) {
/* Signal handler installed with SA_SIGINFO. */
sf.sf_siginfo = (register_t)sfp-sf_si;
sf.sf_ahu.sf_action = (__siginfohandler_t *)catcher;
/* fill siginfo structure */
sf.sf_si.si_signo = sig;
sf.sf_si.si_code = code;
}
On the alpha the value should come from frame-tf_regs[FRAME_TRAPARG_A0].
I'll try it when I get time. (Feel free to beat me to the punch :-).
John
---
John Polstra [EMAIL PROTECTED]
John D. Polstra Co., Inc.Seattle, Washington USA
"No matter how cynical I get, I just can't keep up."-- Nora Ephron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Now that sigcontext is gone ...
Alan Cox wrote: Actually, the last time I looked the Modula-3 run-time system determined the faulting address from the undocumented (except on SunOS 4) 4th argument that most BSD-derived systems passed to the signal handler. Yep, I have fixed that in the PM3 release (which is the one that's actively maintained these days), but probably not in the SRC release on which our port is based. I have ports for PM3 in the wings, but I'm waiting for some necessary changes to bsd.port.mk to be committed. John --- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FICL breakage...
Jordan K. Hubbard wrote in list.freebsd-current: Anyway, all good to know. There are almost certainly more perl speakers than awk speakers these days, so it probably makes sense to do these things in perl rather than awk. I think that's sort of in the grey area. There are also many Hardened Traditionalists(tm) like myself who don't know perl and have no interest in learning it because everything they ever need to do can be handled by sh, awk and sed and they spent many years gaining that level of proficiency with them. We could color our ls and replace sh with bash too, but sometimes there's value in retaining the simpler traditions as you also go forward with the newer tools. :-) Not that anybody actually listens to me, but I have to say that I completely agree with Jordan. Knowing both perl and awk, I like awk a _lot_ better. It is definitely much easier to learn and to use. (You _have_ to learn it first, of course, but if you already know C, you know 90% of awk.) A lot of my scripts begin with #!/usr/bin/awk -f ;) In fact, I learned perl first and did quite a lot of things with it. However, when I became more familiar with awk, the deficiencies of perl became more and more obvious to me. So I started porting my old perl stuff: to sh, to awk, to C, or whatever seemed most appropriate. (I still have some perl scripts left, just because they work, and lack of time to convert, or because someone else wrote them without too much care, rendering them unreadable and unmaintainable -- a common problem with perl.) Just my 0.02 Euro... Regards Oliver PS: If you need something ported to awk or written in awk, just let me know. :) -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
Why are the tools being built using new syscalls? What causes this? Mainly historical bugs. Includes are installed too early and they only match the new syscalls. Tools are built using the new includes, so they need new libraries to be consistent. Therefore the new libraries are built before the new tools. These bugs were implemented in FreeBSD-1 by someone named rgrimes :-). I'll eat the crow, yes, I did implement that. It was the first step at even being able to ``make world''. Had to start some place. And technically the bug dates back to the patchkit, infact probably a 1.x version of the 386BSD PatchKit. Now, the addition of obj/tmp and the TOOLS thing was suppose to fix that by using the current headers/libraries to build a set of tools that didn't go smashing around on the system. If someone copied the earlier work that had a different purpose, and these nasty bugs, well... they would certainly still be there! -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Now that sigcontext is gone ...
Alan Cox wrote: I guess this discussion means that the 4th argument is gone too... Yes. ucontext_t (3rd argument) already contains that information and siginfo_t *should* contain that information. There's not need for a 4th argument anymore. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Thu, 30 Sep 1999, Brad Knowles wrote: At 10:17 PM + 1999/9/29, Adam Strohl wrote: Furthermore, for when 4.0 becomes a -R or -S, ftping in a compiled kernel shouldn't be that hard of a price to pay for going from 3.2. /stand/sysinstall based upgrades could easily seemlessly take care of this, too. I must confess ignorance (and I haven't exhaustively searched the mailing list archives, the Handbook, or the FAQ), For future reference you will get better results if you don't explicitly state your failure to educate yourself on the topic you are posting about. but is this the recommended method of upgrading from a previous major release to the latest -STABLE major release (i.e., going from 2.x to 3.x today, or from 3.x to 4.x when the time comes)? I thought the official procedure was cvsup, or is that for updating only within a particular major release? There is no "official procedure." Like everything else in unix the "best" solution varies on the problem domain. If you have console access it is generally always better to use sysinstall since that method is almost always guaranteed to work. Many of us don't have console access to the machines we maintain, and although this is not an "officially supported" method of upgrading preventing chicken and egg problems in the upgrade from source process is a matter of good design, as well as a matter of great importance to the "fringe cases" that don't involve "simply" doing an upgrade. Doug -- "Stop it, I'm gettin' misty." - Mel Gibson as Porter, "Payback" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
John-Mark Gurney wrote: the reason I was on Marcel's back was because of his statement that he WOULD NOT do ANYTHING to fix the problem, and that as far as he was considered, that's life and deal w/ it... if he had said, oh, I'll look for a solution to the problem, I wouldn't of been so hard on him... I said that for the -current case. I also said that an upgrade from -stable to -current will be fixed if it was broken. so, is Marcel going to do the work for this? or will this have to be passed to someone like you or myself? I'm not going to claim this. Everyone with a constructive opinions can join the club. It's so much easier for everyone if it's done by more than 1 person. Those that don't feel confortable solving this problem are encouraged to test solutions. As for me, I'm trying to define the problem as detailed and consise as possible. I already have some specific thoughts and ideas. I'm thinking large here: real cross-compilation capabilities and such (it may be handy for FreeBSD/IA64)... -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
Mainly historical bugs. Includes are installed too early and they only match the new syscalls. Tools are built using the new includes, so they need new libraries to be consistent. Therefore the new libraries are built before the new tools. These bugs were implemented in FreeBSD-1 by someone named rgrimes :-). I'll eat the crow, yes, I did implement that. It was the first step at even being able to ``make world''. Had to start some place. And technically the bug dates back to the patchkit, infact probably a 1.x version of the 386BSD PatchKit. Naw, 386BSD was never able to 'build itself' from scratch. That was a FreeBSD/rgrimes addition, bugs and all. :) :) :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS mod for solaris committed
Matthew Dillon wrote: Oh, I forgot to email current on this... I've #if 0'd out the NFSERR_BAD_COOKIE code that is partially responsible for the solaris interoperability problems I'd like to know if anyone has contacted Sun about this, which looks like a bug in their code. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] Rule 69: Do unto other's code as you'd have it do unto yours To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Now that sigcontext is gone ...
Alan Cox wrote: /* kludge to pass faulting virtual address to sendsig */ frame-tf_err = eva; return((rv == KERN_PROTECTION_FAILURE) ? SIGBUS : SIGSEGV); } Up until this point, frame-tf_err tells me details about the page fault, such as whether it was a read or a write access. I'd really like that information to make it out to user-level in addition to the faulting address. In other words, we should find another way to pass the faulting address to sendsig than by overwriting frame-tf_err. Sounds reasonable to me. P.S. This also reminds me that FreeBSD is non-standard relative to Linux and all of the major vender commercial Unices in that a disallowed access, such as a write to a read-only region of memory, generates a SIGBUS rather than a SIGSEGV. Yes, this even violates the 1996 POSIX spec. John --- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Sep 30, 11:24pm, Marcel Moolenaar wrote: } Subject: Re: HEADS UP: sigset_t changes committed } As for me, I'm trying to define the problem as detailed and consise as } possible. I already have some specific thoughts and ideas. I'm thinking } large here: real cross-compilation capabilities and such (it may be } handy for FreeBSD/IA64)... While proper cross-compilation would be really nice to have, it won't solve the "make world" problem. It would get you through "make buildworld", but "make installworld" will overwrite the system binaries with new versions that use the new signal syscalls that the currently running kernel doesn't support. It would even be possible to cross-compile a new kernel, but it still has to be installed and the system rebooted before installing userland. In this particular case, the only thing cross-compilation would buy us is the ability to build (but not install) 4.x binaries on a machine running 3.x. It sounds like some folks would be satisfied just having that. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: EGCS, or EGCS?
look at gcc's behaviour. This has left me somewhat confused. I
appear to have two complete copies of gcc - one in src/contrib/gcc and
another in src/contrib/egcs/gcc.
WIP. src/contrib/egcs is the current home. It is moving to
src/contrib/{gcc,libio,libstdc++,etc.}. After the move, it will be
upgraded to 2.95.1. School year has started, advisor been very
demanding, and I've been AWOL for 2-3 weeks now. :-(
--
-- David([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
At 03:14 PM 9/28/99 +0930, Greg Lehey wrote: And the preferred method is... a) /dev/da0 b) /dev/da0s1 c) /dev/da0s1e (-current and -stable I hope :) (b) or (c). (a) isn't a slice. Note that it won't take slice c, either. Thanks for the clarification. Was recalling a past dicussion on how Vinum determined what belonged to it . Not using "c" is just plain common sense. It's surprising. Good software shouldn't panic. But this input is valuable, because now I know where to look. Should have spoken up quite a while back. Figured it was pilot error and the panic was a self-inflicted gunshot wound. Read http://www.lemis.com/vinum/how-to-debug.html. It's also in vinum(4). Again? ;) May try some old pilot errors and see if I can panic it. Just need to recall what I was doing, since it happened when (almost) trying to break things. Forgot to mention that software should not panic, but if you are doing something wrong... Goes back to recent mention of sanity checking. You don't want to use vinum read. Just vinum start. And I've found the bug (thanks, Brad). I'll be committing a fix Real Soon Now. So then if only the module is loaded and rc does nothing further then doing a 'vinum read ...' is a Bad Thing. Use 'start' myself, but just to clarify for others. It's still in the pipeline. I can't give any time frame. There are some bugs I need to look at (http://www.lemis.com/vinum/bugs.html), and then I can start thinking about it. Perhaps I should have been more specific, but from what I understand there are some issues with the boot process (space limitations?) and possibly requiring other changes of a more significant nature beyond that, which you were waiting for to come about first. Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problems with Linux emulation
Hi!
I´ve updated to the latest 4.0-CURRENT on Monday and discovered
today, that my Linux emulation is broken. The emulation is loaded
as a kernel module alright, but when I start anything really using
the emulation (e.g. acroread4) my system hangs completely and requires
a reboot.
I deinstalled the linux_base port and tried to reinstall it, but while
installing, I get the following kernel panic:
Fatal trap 12: page fault while in kernel mode
mp_lock = 0002; cpuid = 0; lapic.id = 0100
fault virtual address = 0x50
fault code: supervisor read, page not present
processor eflags: interrupt enabled, resume, iopl = 0
current process = 1105 (ldconfig)
interrupt mask = none - SMP; XXX
trap number = 12
panic: page fault
This happens when the install script wants to call {PREFIX}/sbin/ldconfig
(the Linux-ldconfig).
I rebuilt and reinstalled the linux emulation module, but that didn´t help either.
Installing the above port will still cause a kernel panic.
I haven´t read this list for a while, so I might have missed something important.
Any hints or ideas what might be going wrong? What can I do to make it work again?
Ciao,
Thomas Schürger. http://www.menden.augustin.de
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Don Lewis scribbled this message on Sep 30:
On Sep 30, 11:24pm, Marcel Moolenaar wrote:
} Subject: Re: HEADS UP: sigset_t changes committed
} As for me, I'm trying to define the problem as detailed and consise as
} possible. I already have some specific thoughts and ideas. I'm thinking
} large here: real cross-compilation capabilities and such (it may be
} handy for FreeBSD/IA64)...
While proper cross-compilation would be really nice to have, it won't solve
the "make world" problem. It would get you through "make buildworld", but
"make installworld" will overwrite the system binaries with new versions that
use the new signal syscalls that the currently running kernel doesn't support.
It would even be possible to cross-compile a new kernel, but it still has
to be installed and the system rebooted before installing userland.
In this particular case, the only thing cross-compilation would buy us
is the ability to build (but not install) 4.x binaries on a machine
running 3.x. It sounds like some folks would be satisfied just having
that.
I'm sorry, this is easy to fix... have a set of tools you copy to /ibin
that are used for the install (all staticly compiled binaries hopefully)
and run the install world out of /ibin... maybe include some binaries
for system recovery to make sure...
if people are interested, I can take a look at it... it'd be interesting
to be able to do something like; make prep-installworld; rm -rf
/usr/{sbin,bin,lib} /{bin,sbin}; make installworld and have it
complete... :)
--
John-Mark Gurney Voice: +1 408 975 9651
Cu Networking
"The soul contains in itself the event that shall presently befall it.
The event is only the actualizing of its thought." -- Ralph Waldo Emerson
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Now that sigcontext is gone ...
I'm trying to digest the recent signal changes and get a handle on what I need to do to make Modula-3 work. There is code in the runtime Sigcontext will have to come back, since it is a standard BSD interface. Recent signal changes break even its source-level compatibility. Previous signal changes managed to preserve even its binary compatibility by keeping things the same for the !SA_SIGINFO case, but the next round of those changes might have broken binary compatibility by adding floating point context. BTW, struct sigcontext seems to be documented only in sigreturn.2, and that documentation is more than 3 stages behind reality. sigreturn() now uses ucontext_t, and the documented struct sigcontext is only for an old i386 version (Lite2 documents a "machine-independent" but inadequate version). It is missing sc_gs, sc_fs, sc_trapno and sc_err at the end. Adding these fields broke binary compatibility. currently which catches SIGBUS and uses the sigcontext's "sc_err" member to find out the faulting address. That should be replaced by the siginfo_t's "si_addr" member. But as far as I can tell from grepping the kernel sources, that functionality isn't implemented. Is that right? Any ideas regarding a work-around? The functionality of sc_trapno also seems to be unimplemented. These fields are not documented, so you shouldn't be using them :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with Linux emulation
Thomas Schuerger wrote:
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
This happens when the install script wants to call {PREFIX}/sbin/ldconfig
(the Linux-ldconfig).
I rebuilt and reinstalled the linux emulation module, but that
didn_t help either.
Installing the above port will still cause a kernel panic.
I haven_t read this list for a while, so I might have missed
something important.
Any hints or ideas what might be going wrong? What can I do to make
it work again?
rant
You should be reading this list if you run -current!
/rant
Cvsup up to date sources.
Build a new kernel.
Install kernel.
Edit /etc/rc.conf to *not* load the linux module at boot time.
Reboot.
make world
Edit /etc/rc.conf to load the linux module at boot time.
Either reboot or kldload the linux module.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Fri, Oct 01, 1999 at 08:48:34AM +1000, David O'Brien wrote:
On Thu, Sep 30, 1999 at 06:25:56AM -0700, Rodney W. Grimes wrote:
Cons
o Upgrading from 3.3 and before to -current is only possible after
an upgrade to post 3.3.
Not good.
We recommend that 2.2.x people upgrade to the latest 2.2-STABLE offering
before trying to jump to 3.x via `make {upgrade,world,aout-to-elf}.
I thought it was `2.2.8-RELEASE or later', not `the latest
2.2-STABLE'. (I know this has been stated regularly in various
mailing lists, but I can't find the exact wording in the FAQ or
handbook). AFAIK, this recommendation was more along the lines of
`it's known to work with 2.2.8 and isn't guaranteed to work with
earlier releases'. I'm fairly certain I've upgraded machines from
2.2.6 or 2.2.7 to 3.x without installing 2.2.8. If we implement this
change, it will be `the upgrade is guaranteed not to work unless you
are running 3.x from 1st October 1999 or later'.
I believe that the above also implies that there should be a
3.4-RELEASE before 4.0-RELEASE (I'm not sure what has been planned)
so that there's a -release that is upgradeable to -current.
In any case, I'm not sure that this is a particularly clean solution:
1) It is a specific work-around for this problem and does not solve
the general problem: Buildworld should not use be using tools
built for the new world with the current kernel.
2) It's not a change that can be applied to -current, tested and then
MFC'd. This increases the likelihood that it will break -stable.
Peter
--
Peter Jeremy (VK2PJ)[EMAIL PROTECTED]
Alcatel Australia Limited
41 Mandible St Phone: +61 2 9690 5019
ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Marcel Moolenaar scribbled this message on Sep 30: John-Mark Gurney wrote: the reason I was on Marcel's back was because of his statement that he WOULD NOT do ANYTHING to fix the problem, and that as far as he was considered, that's life and deal w/ it... if he had said, oh, I'll look for a solution to the problem, I wouldn't of been so hard on him... I said that for the -current case. I also said that an upgrade from -stable to -current will be fixed if it was broken. you don't under stand, we are NOT talking about upgrades, we are talking about how to make a buildable system on -stable... the make buildworld -DNOTOOLS does not work, and will not work for what I like to do.. I need tools from -current that RUN ON -stable... you completely cut the whole part of me agreeing w/ Peter about -DACIENTTOOLS... and so you know, (this is unrelated to the -current tools running on -stable), you can't do a buildworld w/ -DNOTOOLS and have it succeed: === libgcc echo '#include i386/xm-i386.h' config.h echo '#include xm-freebsd.h' config.h echo '#include "i386/xm-i386.h"' tconfig.h echo '#include "i386/i386.h"' tm.h echo '#include "i386/att.h"' tm.h echo '#include "i386/freebsd.h"' tm.h echo '#include "i386/perform.h"' tm.h cc -c -nostdinc -O -pipe -pipe -O -pipe -O -I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/a/home/johng/FreeBSD-checkout/40current/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c cc1: Invalid option `-fexceptions' *** Error code 1 it took me all of 21 minutes for the buildworld to fail.. considering I'm not running softupdates, it'd be even faster... so, is Marcel going to do the work for this? or will this have to be passed to someone like you or myself? I'm not going to claim this. Everyone with a constructive opinions can join the club. It's so much easier for everyone if it's done by more than 1 person. Those that don't feel confortable solving this problem are encouraged to test solutions. so, I take this that you are uninterested in trying to solve the problem at hand? I vote for Peter's idea, which is something that I was thinking about before he sent the idea out... just in a different way... As for me, I'm trying to define the problem as detailed and consise as possible. I already have some specific thoughts and ideas. I'm thinking large here: real cross-compilation capabilities and such (it may be handy for FreeBSD/IA64)... ok, the problem is: a) -current tools are built w/ -current libc and friends b) -current libc and friends are NOW (they used to not be this way) unable to run on anything but -current because of the signal changes.. c) the problem is that the signal changes do not provide a way to continue to function in the case that the kernel doesn't support the new syscalls... we have a catch-22 in the build environment.. the tools need a -current libc and friends, and libc and friends needs a -current kernel, and a -current kernel needs the tools to be built... the solution is to make libc and friends be able to operate on a non-current system by wrapping the signal stuff in #ifdef's that will provide fall back support when requested and use the o* syscalls in this case... what we may want to do, is to leave the old signal code in, and simply add in the ability to "select" what signal code we want to include.. and make it a general system so that it just doesn't apply to the signal system... this way we can say, we are building under NetBSD, and they don't have getcwd as a syscall so we need to compile getcwd as a function using this code, instead of using FreeBSD's syscall... and as Bruce will point out... the fact that -current's libc even builds on -stable and has run is completely by chance... our build of libc and tools should detect the system that we are on (or be told the type of system) and react accordingly... before this time we have been lucky that it hasn't been needed, but now we need it... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
On Fri, Oct 01, 1999 at 09:20:53AM +1000, Jeffrey J. Mountin wrote: At 12:59 PM 9/28/99 +1000, Peter Jeremy wrote: On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote: Good software shouldn't panic. I wish _I_ could convince some people of this :-(. It can be difficult to consider what a user can do and tends to bloat the code a bit. Frustrates my instructors, since it very much a habit when I script and carried over to C. 8-) I was thinking of some `production' code (written by a sister company) that I used to provide customer support for. It would regularly core dump (but was automatically restarted). After a few years they did manage to fix the core dump, but that exposed a memory leak which they never did manage to fix (fairly embarrasing in a supposedly permanently running process). Speaking of, why is (would) root filesystem support necessary for non root/swap automagical recovery. I gather that root support is the most-asked-for feature in Vinum (when I asked Greg about it some weeks ago, I got about as far as `when will Vinum' before he answered me). As long as recovery works, making it nicer to use is (should be) a lower priority. Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
you don't under stand, we are NOT talking about upgrades, we are talking about how to make a buildable system on -stable... There are essentially the same problem. In order to do an upgrade, you have to be able to build on -stable. :) === libgcc echo '#include i386/xm-i386.h' config.h echo '#include xm-freebsd.h' config.h echo '#include "i386/xm-i386.h"' tconfig.h echo '#include "i386/i386.h"' tm.h echo '#include "i386/att.h"' tm.h echo '#include "i386/freebsd.h"' tm.h echo '#include "i386/perform.h"' tm.h cc -c -nostdinc -O -pipe -pipe -O -pipe -O -I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/a/home/johng/FreeBSD-checkout/40current/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c cc1: Invalid option `-fexceptions' This is unrelated to the signal code. Why are you jumping on Marcel for this? In any case, I believe there is work in progress as well as interest in making *something* work. Let's all quit yelling at one another and start working towards a solution, instead of pointing fingers and screaming 'he broke it and won't fix it'. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Sep 30, 4:14pm, John-Mark Gurney wrote: } Subject: Re: HEADS UP: sigset_t changes committed } } In this particular case, the only thing cross-compilation would buy us } is the ability to build (but not install) 4.x binaries on a machine } running 3.x. It sounds like some folks would be satisfied just having } that. } } I'm sorry, this is easy to fix... have a set of tools you copy to /ibin } that are used for the install (all staticly compiled binaries hopefully) } and run the install world out of /ibin... maybe include some binaries } for system recovery to make sure... ... but as soon as you run the stuff in /ibin to install the new userland, you won't even be able to run a shell script, because the newly installed /bin/sh will be using the new signal syscalls. The install process will have to include installing a new kernel and will have to be followed by an immediate reboot. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Fri, Oct 01, 1999, you wrote: On Sep 30, 4:14pm, John-Mark Gurney wrote: } Subject: Re: HEADS UP: sigset_t changes committed } } In this particular case, the only thing cross-compilation would buy us } is the ability to build (but not install) 4.x binaries on a machine } running 3.x. It sounds like some folks would be satisfied just having } that. } } I'm sorry, this is easy to fix... have a set of tools you copy to /ibin } that are used for the install (all staticly compiled binaries hopefully) } and run the install world out of /ibin... maybe include some binaries } for system recovery to make sure... ... but as soon as you run the stuff in /ibin to install the new userland, you won't even be able to run a shell script, because the newly installed /bin/sh will be using the new signal syscalls. No, all it means is that the tools to install the new userland need to have special shellscripts with '#!/ibin/sh' or similar, or be explicitly invoked (eg /ibin/sh foo). I don't think this is a real problem. Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Don Lewis scribbled this message on Sep 30: On Sep 30, 4:14pm, John-Mark Gurney wrote: } Subject: Re: HEADS UP: sigset_t changes committed } } In this particular case, the only thing cross-compilation would buy us } is the ability to build (but not install) 4.x binaries on a machine } running 3.x. It sounds like some folks would be satisfied just having } that. } } I'm sorry, this is easy to fix... have a set of tools you copy to /ibin } that are used for the install (all staticly compiled binaries hopefully) } and run the install world out of /ibin... maybe include some binaries } for system recovery to make sure... ... but as soon as you run the stuff in /ibin to install the new userland, you won't even be able to run a shell script, because the newly installed /bin/sh will be using the new signal syscalls. The install process will have to include installing a new kernel and will have to be followed by an immediate reboot. why are you trying to run a shell script instead of rebooting your computer after the installworld? you need to install a kernel+userland as a COMPLETE set... and the kernel needs to be build w/ the tools that were used to make all... it's that simple.. the hard part is making the tools work/build properly... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Nate Williams scribbled this message on Sep 30: you don't under stand, we are NOT talking about upgrades, we are talking about how to make a buildable system on -stable... There are essentially the same problem. In order to do an upgrade, you have to be able to build on -stable. :) yes, they are the "same problem", but they are viewed differently.. w/ an upgrade, you can requre ANYTHING to happen, this includes having to install and reboot w/ 10 different kernels before you reach your destination... which makes the last part impossible... === libgcc echo '#include i386/xm-i386.h' config.h echo '#include xm-freebsd.h' config.h echo '#include "i386/xm-i386.h"' tconfig.h echo '#include "i386/i386.h"' tm.h echo '#include "i386/att.h"' tm.h echo '#include "i386/freebsd.h"' tm.h echo '#include "i386/perform.h"' tm.h cc -c -nostdinc -O -pipe -pipe -O -pipe -O -I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/a/home/johng/FreeBSD-checkout/40current/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /a/home/johng/FreeBSD-checkout/40current/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c cc1: Invalid option `-fexceptions' This is unrelated to the signal code. Why are you jumping on Marcel for this? this is what preceeded the above snip it in my original message that Nate deleted: and so you know, (this is unrelated to the -current tools running on -stable), you can't do a buildworld w/ -DNOTOOLS and have it succeed: he suggested that I try a make buildworld -DNOTOOLS to see if that would work, I was simply reporting that it failed to work... notice that I said: "this is unrelated to the -current tools running on -stable" part... In any case, I believe there is work in progress as well as interest in making *something* work. Let's all quit yelling at one another and start working towards a solution, instead of pointing fingers and screaming 'he broke it and won't fix it'. :) P.S. It is really hard for me to not make personal attacks against you after all of the above and completely ignoring the rest of my message. Simply pointing out behavior problems is not going to solve anything. So, why don't you read the last part of my message that you felt like ignoring, and provide input? The last part included a possible solution to the problem. since you seem to have completely ignored the last part of my message, here it is again: ok, the problem is: a) -current tools are built w/ -current libc and friends b) -current libc and friends are NOW (they used to not be this way) unable to run on anything but -current because of the signal changes.. c) the problem is that the signal changes do not provide a way to continue to function in the case that the kernel doesn't support the new syscalls... we have a catch-22 in the build environment.. the tools need a -current libc and friends, and libc and friends needs a -current kernel, and a -current kernel needs the tools to be built... the solution is to make libc and friends be able to operate on a non-current system by wrapping the signal stuff in #ifdef's that will provide fall back support when requested and use the o* syscalls in this case... what we may want to do, is to leave the old signal code in, and simply add in the ability to "select" what signal code we want to include.. and make it a general system so that it just doesn't apply to the signal system... this way we can say, we are building under NetBSD, and they don't have getcwd as a syscall so we need to compile getcwd as a function using this code, instead of using FreeBSD's syscall... and as Bruce will point out... the fact that -current's libc even builds on -stable and has run is completely by chance... our build of libc and tools should detect the system that we are on (or be told the type of system) and react accordingly... before this time we have been lucky that it hasn't been needed, but now we need it... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
At 09:44 AM 10/1/99 +1000, Peter Jeremy wrote: I was thinking of some `production' code (written by a sister company) that I used to provide customer support for. It would regularly core dump (but was automatically restarted). After a few years they did manage to fix the core dump, but that exposed a memory leak which they never did manage to fix (fairly embarrasing in a supposedly permanently running process). Eeew! Can see your point. Tracking down a sig11 problem in a custom program right now. Seems to be OS related, but think a bit of work around the problem code is in order first. Oh, the pain of learning. My first project fixing another's code. Or at least trying. At least it doesn't harm functionality, so has been bugging me for a while and decided enough is enough. I gather that root support is the most-asked-for feature in Vinum (when I asked Greg about it some weeks ago, I got about as far as `when will Vinum' before he answered me). As long as recovery works, making it nicer to use is (should be) a lower priority. This was more directed torwards Greg, but would guess that auto-recovery would be fairly requested. Growing plexes (any type) would be #1 on my list, auto-recovery #2, and root #3. Best not to bother him about desired features. Would be nice for a work status/todo list, but then *that* has to be updated. And yet might reduce questions of the "when will" type. Rather like the problem page he added. Otherwise should just stop here now. duck n cover "Is it done yet? Is it done yet?" 8-0 Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
On Thursday, 30 September 1999 at 18:20:53 -0500, Jeffrey J. Mountin wrote: At 12:59 PM 9/28/99 +1000, Peter Jeremy wrote: On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote: Good software shouldn't panic. I wish _I_ could convince some people of this :-(. It can be difficult to consider what a user can do and tends to bloat the code a bit. Frustrates my instructors, since it very much a habit when I script and carried over to C. 8-) It's all in the pipeline. But first we need Vinum on the root file system. And whilst we're discussing wish-lists... After several fights with Digital/Compaq's Logical Storage Manager, it would be _very_ nice if recovery could be done at the physical disk level (ie, "I've just replaced da3 - autorecover all vinum volumes that used that disk"), rather than having to recover each logical volume. It would also be nice if you could recover mirrored root/swap without needing to unmirror and re-mirror them. Haven't looked at the code for it, but "hotspare" appeared for the drive configuration recently. Bit a tease really. No offense to Greg of course. ;) This is -CURRENT. Expect work in progress. From the commit log: replaceobject: Add preliminary code. This is not yet complete. Add keyword 'hotspare'. Speaking of, why is (would) root filesystem support necessary for non root/swap automagical recovery. Or will this be part of other to-be-implemented functionalities. I'm not sure I understand the question. But if I parse it correctly, the answer is "no". 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-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
P.S. It is really hard for me to not make personal attacks against you after all of the above and completely ignoring the rest of my message. No, I didn't. My statement was that your 'confrontational' style of email wasn't making things any better. Mellow it out, and instead of attacking first (thus putting folks on the defense) and then providing content, skip the first step. This is the same as you've done with the response to me, attack first and ask questions later. :( Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
At 10:19 AM 10/1/99 +0930, Greg Lehey wrote: This is -CURRENT. Expect work in progress. From the commit log: replaceobject: Add preliminary code. This is not yet complete. Add keyword 'hotspare'. Yessir. Read -current, track commits, eat my veggies, get a bit of sun every other week, but am not running -current (for now). Willing to test before MFC, however. Speaking of, why is (would) root filesystem support necessary for non root/swap automagical recovery. Or will this be part of other to-be-implemented functionalities. I'm not sure I understand the question. But if I parse it correctly, the answer is "no". If you parsed as "auto-recovery || root support", then "Yes, great!" Thanks, Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Thu, Sep 30, 1999 at 06:25:56AM -0700, Rodney W. Grimes wrote:
Cons
o Upgrading from 3.3 and before to -current is only possible after
an upgrade to post 3.3.
Not good.
We recommend that 2.2.x people upgrade to the latest 2.2-STABLE offering
before trying to jump to 3.x via `make {upgrade,world,aout-to-elf}. So
we have precidence for this.
And failure to do this became a FAQ, so it's still ``not good''.
I think Marcel is on a good track here, he is getting a real grasp of
the problem and will probably solve some long standing issues if we
let him run with it... giving input when needed and support his efforts
by testing and/or contributing area of expertise information.
--
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
On Thursday, 30 September 1999 at 19:37:23 -0500, Jeffrey J. Mountin wrote: At 09:44 AM 10/1/99 +1000, Peter Jeremy wrote: I was thinking of some `production' code (written by a sister company) that I used to provide customer support for. It would regularly core dump (but was automatically restarted). After a few years they did manage to fix the core dump, but that exposed a memory leak which they never did manage to fix (fairly embarrasing in a supposedly permanently running process). Eeew! Can see your point. Tracking down a sig11 problem in a custom program right now. Seems to be OS related, but think a bit of work around the problem code is in order first. Oh, the pain of learning. My first project fixing another's code. Or at least trying. At least it doesn't harm functionality, so has been bugging me for a while and decided enough is enough. I gather that root support is the most-asked-for feature in Vinum (when I asked Greg about it some weeks ago, I got about as far as `when will Vinum' before he answered me). As long as recovery works, making it nicer to use is (should be) a lower priority. This was more directed torwards Greg, but would guess that auto-recovery would be fairly requested. Growing plexes (any type) would be #1 on my list, auto-recovery #2, and root #3. You're not typical. But you *can* grow concatenated plexes. You just can't expand UFS to use the space. That's not a Vinum issue, but somebody's working on it. Best not to bother him about desired features. Would be nice for a work status/todo list, but then *that* has to be updated. And yet might reduce questions of the "when will" type. Rather like the problem page he added. That's a good idea, I suppose. I'll do that. Done: http://www.lemis.com/vinum/wishlist.html. 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-current" in the body of the message
ata driver (again)
The ata driver seems to be having problems staying in contact with my disks again. Let me know what details are needed to fix the problem, and I'll get in touch with you. = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: AgRSkaterq | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
At 10:57 AM 10/1/99 +0930, Greg Lehey wrote: You're not typical. But you *can* grow concatenated plexes. You just can't expand UFS to use the space. That's not a Vinum issue, but somebody's working on it. Yes, I realized that and donned a pointy hat. Root (/) and OS specific files are of interest, but not as critical to me. There are other allowance one can make for redundancy. Beyond the scope of this discussion. That's a good idea, I suppose. I'll do that. Done: http://www.lemis.com/vinum/wishlist.html. Excellent! As for the root issue, #3 looks the most feasible, IMHO, and should eliminate the problems of #2 if the kernel's fs dies (unless it could try another drive) and yet would there not be an issue should the drive that does the bootstrapping die and the system rebooted. Small thing, not Vinum related, but at least things would keep going when a mirrored root fs lost a plex. The "snapshot" feature is interesting as well. Guess the logging changes is not a wish (yet) and is somewhat similar. Thanks, Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
the libc_r problem
I am still getting this error when trying to compile using libc_r.so.4: /usr/lib/libc_r.so: undefined reference to `_thread_sys_sigprocmask' Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Now that sigcontext is gone ...
Bruce Evans wrote: Sigcontext will have to come back, since it is a standard BSD interface. I think so too. I bet there are several ports besides Modula-3 that use it. Probably boehm-gc does. BTW, struct sigcontext seems to be documented only in sigreturn.2, and that documentation is more than 3 stages behind reality. I didn't even know about sigreturn.2. The sigcontext struct is also mentioned in sigaction.2, with a pointer to signal.h for the definition of the structure. currently which catches SIGBUS and uses the sigcontext's "sc_err" member to find out the faulting address. That should be replaced by the siginfo_t's "si_addr" member. But as far as I can tell from grepping the kernel sources, that functionality isn't implemented. Is that right? Any ideas regarding a work-around? The functionality of sc_trapno also seems to be unimplemented. These fields are not documented, so you shouldn't be using them :-). I'm not -- Modula-3 is. :-} John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
On Thursday, 30 September 1999 at 20:54:39 -0500, Jeffrey J. Mountin wrote: At 10:57 AM 10/1/99 +0930, Greg Lehey wrote: You're not typical. But you *can* grow concatenated plexes. You just can't expand UFS to use the space. That's not a Vinum issue, but somebody's working on it. Yes, I realized that and donned a pointy hat. Root (/) and OS specific files are of interest, but not as critical to me. There are other allowance one can make for redundancy. Beyond the scope of this discussion. That's a good idea, I suppose. I'll do that. Done: http://www.lemis.com/vinum/wishlist.html. Excellent! As for the root issue, #3 looks the most feasible, IMHO, and should eliminate the problems of #2 if the kernel's fs dies (unless it could try another drive) and yet would there not be an issue should the drive that does the bootstrapping die and the system rebooted. Once we've loaded the kernel, we don't need it again. You can delete the kernel on a running system without any problem. 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-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Nate Williams scribbled this message on Sep 30: P.S. It is really hard for me to not make personal attacks against you after all of the above and completely ignoring the rest of my message. No, I didn't. My statement was that your 'confrontational' style of email wasn't making things any better. Mellow it out, and instead of attacking first (thus putting folks on the defense) and then providing content, skip the first step. This is the same as you've done with the response to me, attack first and ask questions later. :( this is just a notice, I am going to be taking a break from FreeBSD for a couple weeks... I will not be reading my freebsd.org email while I am on the break, my other email addresses will continue to work... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: ata driver (again)
On Thu, 30 Sep 1999, Luke wrote: On 01-Oct-99 Kenneth Wayne Culver wrote: The ata driver seems to be having problems staying in contact with my disks again. Let me know what details are needed to fix the problem, and I'll get in touch with you. Hi I don't know if it is the same problem but I have a nagging problem with the ata driver as well. I am fairly sure my disk is ok but can't remove it and do any checking anytime soon. I see errors like this: /kernel: wd0: interrupt timeout (status59rdy,seekdone,drq,errerror40uncorr) /kernel: wd0: wdtimeout() DMA status 4 /kernel: swap_pager: indefinite wait buffer: device:0x20001, blkno: 22304, size: 8192 /kernel: wd0s1b: hard error reading fsbn 22304 of 22304- 22319 (wd0s1 bn 124704; cn 7 tn 194 sn 27) (status 59rdy,seekdone,drq,err erro r 40uncorr) --- what kind of errors do you see? I get this with 3.3R and many different -current's and with the wd and ata driver. it is always in a different location on the disk.. I get similar errors, but not with the wd driver, only the ata driver, and only the timeout error. sometimes the hard error. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Dump device
Hi. dumpon -v /dev/da0s1b is failing here with dumpon: sysctl: kern.dumpdev: No space left on device Alright, it doesn't have minor number 1 as it is supposed to have from the manpage, but using /dev/da0b (supposed to be the same device) brings me to the same error. What am I doing wrong ? -- German Tischler [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dump device
On Friday, 1 October 1999 at 8:27:20 +0200, German Tischler wrote: Hi. dumpon -v /dev/da0s1b is failing here with dumpon: sysctl: kern.dumpdev: No space left on device Alright, it doesn't have minor number 1 as it is supposed to have from the manpage, but using /dev/da0b (supposed to be the same device) brings me to the same error. What am I doing wrong ? I suspect you don't have enough space on the device. How big is it? How big is your memory? 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-current" in the body of the message
Re: ata driver (again)
It seems Kenneth Wayne Culver wrote: On Thu, 30 Sep 1999, Luke wrote: On 01-Oct-99 Kenneth Wayne Culver wrote: The ata driver seems to be having problems staying in contact with my disks again. Let me know what details are needed to fix the problem, and I'll get in touch with you. A dmesg to start with would be fine that way I may be able to reproduce it here pn semilar HW. Hi I don't know if it is the same problem but I have a nagging problem with the ata driver as well. I am fairly sure my disk is ok but can't remove it and do any checking anytime soon. I see errors like this: /kernel: wd0: interrupt timeout (status59rdy,seekdone,drq,errerror40uncorr) /kernel: wd0: wdtimeout() DMA status 4 /kernel: swap_pager: indefinite wait buffer: device:0x20001, blkno: 22304, size: 8192 /kernel: wd0s1b: hard error reading fsbn 22304 of 22304- 22319 (wd0s1 bn 124704; cn 7 tn 194 sn 27) (status 59rdy,seekdone,drq,err erro r 40uncorr) Thats not the ata driver thats the wd driver :) Looks like interrupt lossage to me... -Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
John-Mark Gurney wrote:
if people are interested, I can take a look at it... it'd be interesting
to be able to do something like; make prep-installworld; rm -rf
/usr/{sbin,bin,lib} /{bin,sbin}; make installworld and have it
complete... :)
Yes, please. Don't forget to install the newly built kernel as part of
an upgrade process. It may not be appropriate in a normal installworld,
though.
--
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking Databases http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
