Re: bash in /usr/local/bin?
I said I'd drop it, but apparently there are people that don't understand the dinosaur mentality of certain organizations such as DOD, DISA/DECC, OSD, DARPA, USA, USN, USAF, and USMC. If it's not in the base setup, on a production box, you can't use it. *Huh* This policy must have been implemented in the last 12 months, since the last big contract my previous company did with the USMC, we had a couple dozen Sun workstations, and I had all sorts of 'non-standard' software installed on it, including most of the GNU utilities, gzip, etc Prior to this contract, we did similar work for the Army and there were few restrictions to the software we wrote for them. Everything must be kept in it's ORIGINAL install location, It's wherever the installation tools installed them into. In the case of the Solaris boxes, I think the stuff was all in /usr/local/bin, which suprised me because I was used to 'optional' software going in /opt/*/bin due to the packaging details that most pre-packaged 3rd party software I've gotten for Solaris boxes. otherwise you MUST justify it and ask DISA/DECC for a waiver, which in itself, is a pain in the ass, and in many cases, not likely to happen due to dinosaur mentality. Again, as a former USMC/DOD contracter, this was *certainly* not the case. FreeBSD is getting military contracts now. FreeBSD has been used in military contracts for *years* now. Maybe it wasn't as high-profile as the TrustedBSD work, but it's been in use by the Government for quite a long time (and in a state where the people involved had direct knowledge that FreeBSD was being used). I'm sure there are equally restrictive environments for computers and operating systems in *EVERY* country, but I speak from my personal experience with the dinosaurs at DOD. At DOD, *EVERY* copy of FreeBSD will be subject to what I am saying. In the Sun environment in which I did my last DOD contract at, if tcsh wasn't in /bin, I wouldn't have been able to use it. That's how backwards they are. Again, my suspicion is that you're dealing with some very weird folks at your installation. My experience was quite different, and involved some machines that were running hardened versions of Solaris on secret networks, although I was never allowed to use those machines once they were installed there. :) :) Things aren't as bad as you're experience might suggest Nate ps. Amazingly enough, the software we had to integrate with (being used by both branches) was *riddled* with remote exploit and DoS bugs, but unfortunately they could not be fixed and still stay 'compliant'. The protocol was set in stone (gotta stay compatible), and some of the DoS bugs were due to the incredibly stupid protocol being used. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: _sigprocmask in malloc.c causes full file table?
On Sun, Aug 12, 2001 at 10:29:53AM -0400, Daniel Eischen wrote: sigprocmask() behaves the same as pthread_sigmask(). pthread_sigmask() needs to obtain the current thread. In obtaining the current thread, the threads library must be initialized. In initializing the threads library malloc() is called. Wash, rinse, repeat. We have a winner. This is the top of the (very long) call stack from the mozilla core file (which I admittedly should have examined earlier): #11913 0x2863ebda in _thread_init () from /usr/lib/libc_r.so.5 #11914 0x2863e7a3 in _get_curthread () from /usr/lib/libc_r.so.5 #11915 0x28633539 in pthread_sigmask () from /usr/lib/libc_r.so.5 #11916 0x2863f250 in sigprocmask () from /usr/lib/libc_r.so.5 #11917 0x286c9db5 in malloc () from /usr/lib/libc.so.5 #11918 0x2863a980 in _pq_alloc () from /usr/lib/libc_r.so.5 #11919 0x2863ebda in _thread_init () from /usr/lib/libc_r.so.5 #11920 0x2863e7a3 in _get_curthread () from /usr/lib/libc_r.so.5 #11921 0x28633539 in pthread_sigmask () from /usr/lib/libc_r.so.5 #11922 0x2863f250 in sigprocmask () from /usr/lib/libc_r.so.5 #11923 0x286c9db5 in malloc () from /usr/lib/libc.so.5 #11924 0x2863a980 in _pq_alloc () from /usr/lib/libc_r.so.5 #11925 0x2863ebda in _thread_init () from /usr/lib/libc_r.so.5 #11926 0x2863c063 in pthread_mutex_lock () from /usr/lib/libc_r.so.5 #11927 0x2861556d in __register_frame_info () from /usr/lib/libstdc++.so.3 #11928 0x28662fa2 in _init () from /usr/lib/libc.so.5 #11929 0x2866062d in _init () from /usr/lib/libc.so.5 #11930 0x2806de10 in _rtld () from /usr/libexec/ld-elf.so.1 So, in answer to the question, am I doing something boneheaded, or is this an undocumented subtle interaction, I'll give partial credit to both. Thank you very much for your assistance. -Michael Robinson To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
Jason Evans wrote: I had the same problems, and took my KVM switch apart, expecting to find the chips reversed. They were in fact installed correctly, so at least in my case, the problem exists regardless. If I'm careful to have the KVM switch on the same channel as a booting machine, and leave it on that channel until the probing is done, everything seems to work fine. Otherwise, the keyboard is not detected. See my other post; an upgrade to firmware version 1.9 will fix the problem. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
Nate Williams wrote: Umm, Terry. There was no 'free' tar. Back in the 386BSD days, when we were looking for a free tar, I contacted Andy Tanenbaum (of Minix) and got permission to use it, since we didn't have one. However, it was voted down as being 'too simple', so we opted for the GNU one. There isn't a BSD or public domain version of tar anywhere to be found, unless you consider 'pax' running in tar emulation mode acceptable. (I certainly don't.) I was just going to say pax... The tar program is really trivial to write: it's user space code, and you can run all sorts of fancy debug tools on it, and get a nice core dump to post mortem when it falls over, if you don't want to run it in a source level debugger, which will tell you the precise line of code the failure occurred on. In general, user space code is at least an order of magnitude easier to write. 8-). In any case, what don't you like about pax, other than it's not GNU tar? The same story exists with grep. That's actually not true; there are three different implemetnations of the Boyer-Moore algorithm based grep tools in the comp.unix.sources archives. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
The Anarcat wrote: [Foul-mouthed anti-gummint drivel deleted] Actually, it is up to us to resolve this. I don't think you understand how DOD operates. The vendor makes the changes, not DOD. Not the admin. And FreeBSD is the *vendor*? I don't think so. At least I don't hope so. If I'm mistaken, slap me Consider yourself slapped. The FreeBSD project is the only DOD-approved vendor of FreeBSD. Until the core team says otherwise. Moving the non-GPL shells to /bin is a trivial request that can solve problems that you obviously don't understand. Then we could also answer a trivial request such as making apache part of the base system! If the DOD need a webserver, they're screwed? They panic? What the heck is that? And why should we care about such d**kheads? No, they aren't screwed. They don't panic. They simply say screw FreeBSD and just call Sun, which does have Apache in the base distribution, as well as the shells where the admin is allowed to use them, and doesn't give them a bunch of anti-gummint drivel. Wasn't the DOD using NT? Not for anything serious. Key to this is an admin-friendly environment designed to get around the pre-cambrian attitudes that prevent DOD admins from using standard tools just because it's in the wrong place on the disk array or because it's considered a third-party option, or even worse: freeware [h! step away from the keyboard, son. you going to prison, boy!]. Bash standard? Funny. How many users of FreeBSD? How many users of Linux? How many people using csh? How many people using bash? Besides the fact that you don't reason well, you don't read too well. bash is GPL, it wouldn't qualify for the tree. zsh is open, and has the features of bash, and could probably be a good substitute. The proposition here doesn't involve any specific shell, it's a usability issue. I had very good comments on the easiness (sp?) ppl have installing third party apps in the install process. And the ports collection, and the packages, etc... FreeBSD is very admin friendly, IMHO. Only when the admin has the ability to install third-party standard tools. Try thinking outside the box sometime. If you want a traditional unix, I think there is still a PDP-11 emulator and DL01 image of V7 at gatekeeper.dec.com. Yeah. Let's go with the New Technology: NT. All these buzzwords and semantics are messing things up here. It's not a matter of tradition, it's a matter of license (bash is GPL, FBSD is BSD-licensed), and functionality (bash != sh). See also the comment about resistance to have perl in the base system. perl is in the base system. and again, you don't read too well, i haven't said a nice word in this entire thread about bash, and others have noted the GPL. Linux have bash in the base system simply because there's no other free close relative to sh around. that was a rather inane statement... ever read the BSD license? I'm more for an evolutionary unix where the idea of what's standard changes to reflect the needs of it's admins and users in diverse environments. As much as I appreciate evolution, I think this mentality is exactly the thing that makes us pull away from support from old hardware. That's a shame. how does moving defacto-standard userland items into the basic system effect the kernel? you lost me there. going nowhere due to outdated beliefs oh, but that belongs in /usr/local/bin. Again, it's not a belief. It's a philosophy that is behind FreeBSD. a belief that keeps freebsd out of some hardcore, high-dollar markets. Anyways, this has probably been burnt to death long time ago, I should not get into this. Yes, and I think you should close and wipe your mouth after your foul-mouthed anti-gummint spewing. Flys are gathering around your tooth. My argument for the trivial move of the non-GPL shells to /bin, so long as they are statically linked, is based on experience in a market in which FreeBSD just got it's foot inside of the door. We have already done this with tcsh. I don't see what the problem is getting the rest of the non-GPL shells into /bin is. I missed something here. Is tcsh GPLed? I don't think so... A quick look at /usr/src/contrib/tcsh gives me 2 matches for GNU, config.guess and config.sub. The rest looks like standard BSD license. Am I wrong? 2:19:01am wahoo(2): where tcsh /bin/tcsh Hey Jethro, who put that there? did you? wasn't me! Maybe it was one of dem damned gummint black heeleechoppers being piloted by ET and Bill Clinton... Please, jim, do not take my comments too harsh. I have a very strong... opinion of the military, and of progress, evolution or whatever you want to call that mad fuite en avant (I don't know the proper idiom in english (this was french)). I'm not taking the comments too harsh. I wouldn't have answered, or, if I had, it would have been far less tongue in cheek. FreeBSD is largely derived
Re: bash in /usr/local/bin?
Steve O'Hara-Smith wrote: On Sun, 12 Aug 2001 17:04:01 -0500 Jim Bryant [EMAIL PROTECTED] wrote: JB I said I'd drop it, but apparently there are people that don't understand the dinosaur mentality of certain organizations such as JB DOD, DISA/DECC, OSD, DARPA, USA, USN, USAF, and USMC. JB JB If it's not in the base setup, on a production box, you can't use it. Everything must be kept in it's ORIGINAL install location, Th obvious solution to this is a 'Military' switch in sysinstall that sets PREFIX to / for all ports. heheh... actually... i've seen military systems that do this... from what i've read here, not many undrestand the actual mindset of the military when it comes to computing. the closest would be the guy who mentioned that since ports are on the CD's that they should be acceptable, this is incorrect. it took me a while to figure out how backwards they really are. this is one of the many reasons that they cannot keep good unix talent around. remember, these are the same people that argued that C and C++ was evil and that only ADA was good for nearly 15 years, until they finally realized they were wrong. let's take a look at the failures of what was supposed to be ADA's swan-song project: the new FAA ATC system... you know... the one that keeps crashing everywhere it's installed. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
Mike Smith wrote: Here is the _precise_ problem with older firmware: The Belkin KVM switch uses the on-off-on or off-on-off of this LED to signal a port change character is coming next, and times out the port change request only after a little while. Ah, so the problem is actually a design defect in the Belkin switch. Nice to have that part confirmed. Toe-may-toe, Toe-mah-toe. Other vender's hacks are no better; if there's a design defect in the switch, it's that it doesn't take the double scroll-lock, instead of using the LED from the host, such that if it's wedged, you have to manually hit the next console button. On the other hand, I can force a console switch from software on a machine by toggling the scroll lock LED, and then forcing the keyboard to send me a key-down for a digit by priming its buffer, which is really handy if you want to do an automated rolling demo for a trade show, etc.. The fundamental problem here is that FreeBSD _resets_ a keyboard which has already been correctly reset by the BIOS, if it is present. You can't be sure of this. Just as we reset everything else we talk to, we reset the keyboard. Specific examples where *not* resetting things gets us into trouble can typically be found by looking for when I reboot from Windows XYZ doesn't work. I think that depowering the thing and repowering it at POST is enough to know its state... The only historical fly in this ointment is that some old systems didn't put a real flip-flop on the CPU reset line, and latch it as a result of getting the keyboard reset command from the keyboard controller. Most of these are using XT keyboards, though, which won't work with any KVM switches out there today, since the controller chip is on the wrong side of the keyboard connector cable. 8-). The FreeBSD keyboard detection is another matter; FreeBSD will assume that there is no keyboard, and try to helpfully drop you into serial console mode. No it won't, unless you explicitly configure it. This is the -P default case; most people are not running that recent a -current. Some of this _used_ to be mitigated by checking for the extended keyboard bit in the keyboard identify BIOS call, but this was a problem for people with antique keyboards. This is not the problem, as I have already mentioned in another message. BIOS vendors have *stopped* setting this bit. I've checked 5 machines, including the Tyan and SuperMicro (the latter is AMI BIOS), as well as my Sony VAIO... all set the bit. That said, I agree that it's not a very good way of detecting a keyboard being out there... 8-(. My suggestion for a probe in this case would be to set up a different handler for the reset signal, and then ask the keyboard to send the reset signal. If it does, then there is a keyboard present. Keyboard probing is a dead loss, which is why we don't do it by default. I wish we could avoid resetting, as well. I think that the BIOS you are seeing not setting the bit has decided to not do the probe, too. That's understandable, given that KVM switches are becoming more and more common: they probably saw the same thing FreeBSD is seeing with these boxes. More ideally, the FreeBSD box would detect whether or not the video card had been disabled, and use _that_ to decide whether or not to use a keyboard. It would become the job of the video driver -- be it a regular driver, or be it an LCD driver -- to make the distinction. There is no standardised way of detecting whether a display has been disabled. One gross way that I have never seen fail is to make an INT 10 call to set a standard (the default) video mode, and note that the registers indicate a failure. Absolutely ideally, FreeBSD would come up with the boot code on _both_ (this is an option), and then be told by the user to not use one of them -- or boot using _both_, until told to do otherwise. We've tried this already; people didn't like it. Well, I think the only option left here is explicit configuration. The boot loader doesn't reset the keyboard, does it? I've never seen the LEDs flash dance, between the PST and the FreeBSD keyboard probe, anyway. Perhaps we could elect to reset the keyboard from the boot loader, as an option, and not do it by default... This would _also_ solve the Alpha serial console dance. Actually, it wouldn't, since we use the SRM console for quite a ways, and SRM doesn't do multi-source console I/O. (And when you have a version of SRM that allows you to 'pull' the console by sending a few keystrokes, you can't work out where it's actually directed anyway.) Ugh. I was thinking more in terms of activating both drivers, and sinking both inputs to the same /dev/console... not pretty, either. Cheers, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
John Baldwin wrote: 1) Implement probing/detection for PS/2 keyboards post-boot. You can hack this by having the atkbd0 driver always attach to IRQ 1, but not create and export a kbd0 syscons keyboard driver until it gets an interrupt event from the keyboard. This would be pretty easy. 2) Rewrite the syscons keyboard layer so that we don't have a primary keyboard that is always the current keyboard, but instead make it accept input from all keyboards currently plugged into the system. With this you could go back to assuming a PS/2 keyboard is always around as a hack. This would be rather cool, since it would let me dock and undock my laptop or use an external USB keyboard at the same time... I'll have to find some time to go to Fry's some time in the next couple of weeks or so... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
John Baldwin wrote: My suggestion for a probe in this case would be to set up a different handler for the reset signal, and then ask the keyboard to send the reset signal. If it does, then there is a keyboard present. Yeah, and resetting the controller works fine on machines that don't have keyboards, so it returns false positives. I don't *want* the controller reset: that's what makes the LEDs flash and screw up the KVM's. More ideally, the FreeBSD box would detect whether or not the video card had been disabled, and use _that_ to decide whether or not to use a keyboard. It would become the job of the video driver -- be it a regular driver, or be it an LCD driver -- to make the distinction. This might be practical except that lots of motherboards ship with built-in video these days. I think that disabling this in AMI BIOS, at least, will result in the carry flag being set to indicate INT 10 call failures. What dance? Works great for me. If SRM uses serial console, so does FreeBSD. If SRM uses vidconsole, so does FreeBSD. In fact, this is the _only_ way it can work on the Alpha since SRM just gives you one console device handle and one boot device handle. Have you actually used an Alpha before? :-P Yes, I've used a Miata and a Multia with FreeBSD, and several others with DEC UNIX, and had a PC164 at one time. Surprisingly, setting vidconsole in the SRM didn't make my TGA work in FreeBSD. 8-p. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
Warner Losh wrote: In message [EMAIL PROTECTED] Joe Kelsey writes: : I also second Terry's comment about 0x800. There is no reason to add : yet more driver flags in order to do the right thing. The do the : right thing case should always be default and a flag (sysctl variable, : etc) should be used for those who want the wrong thing. The main reason that it wasn't added at the time was that it was expensive in terms of CPU utilization, so it shouldn't be on by default. There may be other reasons as well... ??? It was just recently added; I'd like to see it MFC'ed for 4.4, but certainly, Kazu hasn't been slacking on 0x8000. I personally don't see how it could be more costly in terms of CPU, since it only invokes in the case of a desynchronized mouse event coming in to the mouse driver: e.g. a failure case that only triggers when there's bot a failure, and a monkey on the other end of the mouse cable. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
Joe Kelsey wrote: [ ... 0x8000 ... ] Again, all I am asking is for someone to explain why they make a design decision. The comment in the psm.c file about a hack is extremely unhelpful. Why did the coder think it was a hack solution? What were the pros and cons that went into that decision. Was there a discussion on -current about it that I missed? If there was a discussion and a conclusion was reached, the proper thing to do is to insert documentation into the code to explain the design decisions that were made. If you don't document the design in the code, it will be forgotton, as there is no other place to document it in FreeBSD. Kazu stated that the reason he didn't enable this by default is that he wanted it tested before he committed to making it the default. It's a bit over the top conservative (since it can't make a broken mouse any more broken), but I understand his intent, if not his reasoning. It's a hack solution, since it should just work, but this makes an intrinsic assumption that you won't put something between you and the hardware to cause problems. It could be that he just hadn't thought of that -- but I doubt it, since the code came from him in the first place. All in all, I agree with the sentiment on design documentation: I'd like to see a lot more of it before code is thrown at a problem, and I'd like to see more literate programming, and most of all I'd like to see benchmarks froving that changes are not gratuitous, or if they are, they at don't injure performance (people have actually been much better about this lately, for the most part, though I still fear for the tcptmpl elimination, rather than merely a reduction in the allocation size). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Netiquette (Was: Re: FreeBSD's aggressive keyboard probe/attach)
Gordon Tetlow wrote: This is such a great example of how tone can come across poorly in a text medium. I doubt (hope) that Joe didn't mean to come across as that. But tone in email is so often inferred based on the readers own moods, that phrasing email becomes much more important so as to not give the reader the wrong impression. This should be required reading for anyone considering posting to a FreeBSD mailing list. My personal suggestion: it's nice to be nice, but it's better to be as nice as you can, and grow a thick skin. This isn't me being facetious: many of the people involved in FreeBSD are not coming to it as native speakers of English, and most of the discussions on these lists are in English. If you insist on taking offense at every opportunity, or even at half of them, then you will find yourself not getting along very well. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
Chris Dillon wrote: Occasionally I'll have mouse sync problems when I switch between FreeBSD and NT when the NT box has had difference mice (wheel vs. non-wheel MS mice, apparently) used on it via the dual-user KVM switch. NT seems to handle that case fairly well by resetting the PS/2 port and/or the mouse (not sure which) and redetecting the mouse type. There is actually a Cybex-specific Microsoft Knowledge Base article which discusses the registry setting you need to pound on to make NT not attempt to detect the mouse wheel (FWIW). FreeBSD doesn't like when NT has done that to the mouse, though, and spews sync errors when I switch back. Usually I can kill moused and restart it to fix the problem. The 0x8000 flag fixes exactly this problem! and the local wiring (non-ethernet version) of the Belkin OmniView switches work if the FreeBSD mouse/keyboard is selected at boot time, so that the aggressive probe/attach can satisfy itself. That is the KVM switch's fault, not FreeBSD's. On all but the most expensive KVM switches which offer true keyboard and mouse emulation on all ports, even NT (or actually the BIOS, I assume) can fail to enable keyboard and mouse support in that case. The dual-user Belkin OmniView seems to handle this correctly. I can't recall any problem booting FreeBSD on it even when its console isn't active. Yes, it has to to support the dual use case; we have one of those in the lab, as well... Belkin went out of its way to support FreeBSD specifically, actually: their firmware version 1.9 fixes the local wiring switches, so that they can pass FreeBSD's aggressive probe, even if the FreeBSD mouse/keyboard is _not_ selected. Hmm... I'll have to check, maybe thats why mine works. :-) Little square sticker with rounded corners on the bottom, about 1/2 by 1/4, with just the version, e.g. 1.9... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make release may be broken
Cahnges made between Friday morning and today may have broken make release. I just got the following error: /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/lib -I/usr/src/gnu/usr.bin/ cvs/cvs/../../../../contrib/cvs/diff -DHAVE_KERBEROS -DHAVE_KRB_GET_ERR_TEXT -DE NCRYPTION-c /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client. c /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c: In function ` start_tcp_server': /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c:4124: `client_ sai' undeclared (first use in this function) /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c:4124: (Each un declared identifier is reported only once /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c:4124: for each function it appears in.) Changes between Friday and today may have broken /usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src/client.c:4151: warning: passing arg 6 of `krb_sendauth' discards qualifiers from pointer target type *** Error code 1 Stop in /usr/src/gnu/usr.bin/cvs/cvs. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cvs. *** Error code 1 Stop in /usr/src/kerberosIV. *** Error code 1 Stop in /usr/src/release. *** Error code 1 Stop in /usr/src/release. Friday's cvsup built fine. ed --- The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn and relearn. --Alvin Toffler To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
src/kerberosIV/Makefile doesn't know that cvs is now temporarybroken
After importing a new cvs (located at src/gnu/usr.bin/cvs), src/gnu/usr.bin/Makefile was modified not to compile cvs, since cvs is temporary broken for bulid. However, there is yet another makefile which builds cvs also -- src/kerberosIV/Makefile. Since this file is left unchanged, we cannot build a release. Would you please also commented out cvs line from src/kerberosIV/Makefile? -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: builds failing in binutils...
With source moved back to /usr/src, this hasn't yet reproduced. On Thu, 9 Aug 2001, David O'Brien wrote: On Thu, Aug 09, 2001 at 09:02:50AM -0700, Matthew Jacob wrote: I put a fresh clean source tree off not in /usr/src- it seems to die on the alpha in binutils. Anyone seen this? Can you remove the -pipe and add -save-temps? I would like to see the preprocessed ldexp.i. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Sat, Aug 11, 2001 at 11:51:18AM -0700, Terry Lambert wrote: [...] If this is really a goal, then you should redesign the process and not put more and more tools into the build tools category to work around these problems. Take a look at sysinstall/Makefile to have a better idea of what a pure build tool is, rtermcap. It is just the first incident (with file(1)) that it's also a build-tool for its own .mgc files. Mark is right, here. The idea of build tools is intrinsically broken, given the goal (if it is a goal). The build-tools stage is responsible for creating tools that are to be used only during `buildworld', and are not used/installed otherwise. The file(1) is special in that it produces the MD format, hence it is not suitable for build-tools. (I did not know that.) Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin
On Fri, Aug 10, 2001 at 11:54:27AM -0700, John Baldwin wrote: On 10-Aug-01 Ruslan Ermilov wrote: On Fri, Aug 10, 2001 at 10:04:01AM -0700, Mark Peek wrote: At 7:14 PM +0300 8/10/01, Ruslan Ermilov wrote: On Fri, Aug 10, 2001 at 08:38:21AM -0700, Mark Peek wrote: At 5:37 PM +0300 8/10/01, Ruslan Ermilov wrote: I'm not sure I understand what you mean by cross-platform installworld. Do you mean build on a HOST platform and install on TARGET, or build on a HOST, install on HOST but using a TARGET disk? I meant the latter here. Has this ever worked? Is it really a goal of the project to have it work? Yes. Imagine that you are rolling an Alpha release on an i386 box. You don't do that. Cross releases need much more work before that is feasible. As Mark mentions, there are many thigns that would need to be fixed. Also, the release process would be hacked, and you still wouldn't have a true clean room release since you can't build a clean room to run a fresh world in. But this doesn't mean we should add more to this breakage, if we can avoid this. Otherwise, you more and more complicate the task for making this scenario possible. Your solution does not work. You're creating binary files in HOST format during the build phase and expecting things such as alignment and endianness to be the same as the TARGET format. Unless the tools are built to output for either the appropriate architecture or in a portable, binary format, you will have problems reading the file on the TARGET platform. It probably works for you since you're doing a 4.X-5.0 upgrade on the same platform. What? ``file -C'' produces different output on Alpha and on i386? Are you sure? (Haven't checked myself.) sparc64 is big endian. So what? There are utilities that produce MI binary output. Apparently, this one does not. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin
On 13-Aug-01 Ruslan Ermilov wrote: On Fri, Aug 10, 2001 at 11:54:27AM -0700, John Baldwin wrote: On 10-Aug-01 Ruslan Ermilov wrote: On Fri, Aug 10, 2001 at 10:04:01AM -0700, Mark Peek wrote: At 7:14 PM +0300 8/10/01, Ruslan Ermilov wrote: On Fri, Aug 10, 2001 at 08:38:21AM -0700, Mark Peek wrote: At 5:37 PM +0300 8/10/01, Ruslan Ermilov wrote: I'm not sure I understand what you mean by cross-platform installworld. Do you mean build on a HOST platform and install on TARGET, or build on a HOST, install on HOST but using a TARGET disk? I meant the latter here. Has this ever worked? Is it really a goal of the project to have it work? Yes. Imagine that you are rolling an Alpha release on an i386 box. You don't do that. Cross releases need much more work before that is feasible. As Mark mentions, there are many thigns that would need to be fixed. Also, the release process would be hacked, and you still wouldn't have a true clean room release since you can't build a clean room to run a fresh world in. But this doesn't mean we should add more to this breakage, if we can avoid this. Otherwise, you more and more complicate the task for making this scenario possible. You aren't going to be using a typical installworld to package up a cross release. The bits are actually packaged up directly from the /usr/obj tree via the distribute targets. The installworlds during release are only to generate the clean room. Your solution does not work. You're creating binary files in HOST format during the build phase and expecting things such as alignment and endianness to be the same as the TARGET format. Unless the tools are built to output for either the appropriate architecture or in a portable, binary format, you will have problems reading the file on the TARGET platform. It probably works for you since you're doing a 4.X-5.0 upgrade on the same platform. What? ``file -C'' produces different output on Alpha and on i386? Are you sure? (Haven't checked myself.) sparc64 is big endian. So what? There are utilities that produce MI binary output. Apparently, this one does not. That answers your question that your cross installworld isn't going to work. *sigh* He noted that your solution doesn't work because you are assuming that the TARGET and HOST file formats are the same. He's pointing out that that is not the case. You asked for an example, and I gave you one. :) -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On 13-Aug-01 Terry Lambert wrote: John Baldwin wrote: More ideally, the FreeBSD box would detect whether or not the video card had been disabled, and use _that_ to decide whether or not to use a keyboard. It would become the job of the video driver -- be it a regular driver, or be it an LCD driver -- to make the distinction. This might be practical except that lots of motherboards ship with built-in video these days. I think that disabling this in AMI BIOS, at least, will result in the carry flag being set to indicate INT 10 call failures. Unfortunately there are other BIOS vendors, and we need a solution that works across the board and doesn't trigger false positives. (Most BIOS's don't set the enhanced keyboard bit for USB keyboards, and some don't set it for PS/2 keyboards either, hence turning off -P.) What dance? Works great for me. If SRM uses serial console, so does FreeBSD. If SRM uses vidconsole, so does FreeBSD. In fact, this is the _only_ way it can work on the Alpha since SRM just gives you one console device handle and one boot device handle. Have you actually used an Alpha before? :-P Yes, I've used a Miata and a Multia with FreeBSD, and several others with DEC UNIX, and had a PC164 at one time. Surprisingly, setting vidconsole in the SRM didn't make my TGA work in FreeBSD. 8-p. Not all of those machines have TGA's, and you could be testing out the TGA driver. However, there is no song and dance, you set the console to serial for a TGA machine and it all works and fine. Not exactly a song and dance. :) -- Terry -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Last Words...(documentation)
OK already. I am sick and tired of this documentation discussion and it appears that it is too hot of a topic for this list. However, I have one last comment to make. TWO people have written to me and said that the reason THEY write documentation in their day jobs is that they get PAID for it. So, excuse me! I guess real programmers only write documentation when they are PAID! Obviously, working on a FREE product, you don't get paid so you don't document! After all, the meaning is obvious from the code! /Joe p.s. I don't really have to supply sarcasm markers here, do I? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: trap in vm_object_pip_add
On 11-Aug-01 Alexander Langer wrote: Hi! Under high network load together with high ata disk i/o, I can easily reprocude this trap. I think it happens when a fork() is done (I always got it when starting new programs...). E. I used to get this on my test SMP alpha machine a lot with the giant vm lock. I hadn't seen it before then and haven't seen it since. :( The problem is that vm_map_lookup() is returning RV_SUCCESS (or whatever the SUCCESS return value is) but the value it returns in fs.fs_object is NULL. :( I have no idea what the cause of this bug is. Script started on Sat Aug 11 16:12:07 2001 mobile# gdb -k kernel.debug vmcore.3 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd... IdlePTD 4931584 initial pcb at 3b5a20 panicstr: from debugger panic messages: --- ACPI debug layer 0x0 debug level 0x0 Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Fri Aug 10 13:45:01 CEST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MOBILE Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 647190237 Hz CPU: Pentium III/Pentium III Xeon/Celeron (647.19-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x387f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA T,PSE36,PN,MMX,FXSR,SSE real memory = 67043328 (65472K bytes) avail memory = 60137472 (58728K bytes) Preloaded elf kernel kernel at 0xc0495000. Preloaded elf module agp.ko at 0xc049509c. Preloaded elf module random.ko at 0xc0495138. Warning: module random already exists Pentium Pro MTRR support enabled WARNING: Driver mistake: repeat make_dev(random) Using $PIR table, 4 entries at 0xc00fdf80 acpi0: PTLTDRSDT on motherboard Timecounter ACPI frequency 3579545 Hz acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_pcib0: Host-PCI bridge on acpi0 pci0: PCI bus on acpi_pcib0 agp0: Intel 82443BX (440 BX) host to PCI bridge mem 0xf800-0xfbff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0x1050-0x105f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0x1060-0x107f irq 11 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at 7.3 (no driver attached) pci0: multimedia, audio at 9.0 (no driver attached) pci0: input device at 9.1 (no driver attached) pcic0: Ricoh RL5C475 PCI-CardBus Bridge mem 0x4400-0x44000fff irq 11 at device 12.0 on pci0 pccard0: PC Card bus (classic) on pcic0 acpi_ec0: embedded controller on acpi0 acpi_acad0: AC adapter on acpi0 acpi_cmbat0: Control method Battery on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Sleep Button on acpi0 acpi_button1: Power Button on acpi0 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 npx0: math processor on motherboard npx0: INT 16 interface too many dependant configs too many dependant configs too many dependant configs too many dependant configs too many dependant configs too many dependant configs too many dependant configs too many dependant configs orm0: Option ROM at iomem 0xc-0xc on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 pmtimer0 on isa0 ppc0: parallel port not found. sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0200 can't assign resources unknown: PNP0303 can't assign resources unknown: PNP0F13 can't assign resources unknown: PNP0700 can't assign resources sio0: 16550A-compatible COM port at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 IP packet filtering initialized, divert disabled, rule-based forwarding enabled, default
Re: bash in /usr/local/bin?
On Mon, Aug 13, 2001 at 04:13:52AM -0500, Jim Bryant wrote: from what i've read here, not many undrestand the actual mindset of the military when it comes to computing. the closest would be the guy who mentioned that since ports are on the CD's that they should be acceptable, this is incorrect. You are making sweeping generalizations. Please stop and be specific which parts of the military. It is correct for the CIA. The CIA[*] will not let you bring in any download bits off the net (or floppies containing them) to compile locally and install. HOWEVER, if the bits come on a CDROM from a commercial vendor, they are OK. So in the FreeBSD case, packages are on the commercial 4-disc set, and thus can be installed. In older days for Solaris, one had to find a CD offering from say Walnut Creek CDROM that contained precompiled versions of GNU bits for Solaris. Again, if it was something their purchasing could buy from a vendor an receive it was OK. -- -- David ([EMAIL PROTECTED]) [*] yes I did my time as a cleared Beltway Bandit To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
DOD/DFAS, as well as DOD/DISA. I find it amazing that the CIA has a more lax policy than DFAS and DISA. David O'Brien wrote: On Mon, Aug 13, 2001 at 04:13:52AM -0500, Jim Bryant wrote: from what i've read here, not many undrestand the actual mindset of the military when it comes to computing. the closest would be the guy who mentioned that since ports are on the CD's that they should be acceptable, this is incorrect. You are making sweeping generalizations. Please stop and be specific which parts of the military. It is correct for the CIA. The CIA[*] will not let you bring in any download bits off the net (or floppies containing them) to compile locally and install. HOWEVER, if the bits come on a CDROM from a commercial vendor, they are OK. So in the FreeBSD case, packages are on the commercial 4-disc set, and thus can be installed. In older days for Solaris, one had to find a CD offering from say Walnut Creek CDROM that contained precompiled versions of GNU bits for Solaris. Again, if it was something their purchasing could buy from a vendor an receive it was OK. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
On Mon, Aug 13, 2001 at 07:23:26PM -0500, Jim Bryant wrote: DOD/DFAS, as well as DOD/DISA. I find it amazing that the CIA has a more lax policy than DFAS and DISA. The only person I've ever talked to from the CIA was in charge of network security to some degree, and according to him they can't even use FreeBSD, OpenBSD, or NetBSD internally. Everything must come from a central vendor and be supported by a real company, not by mailing lists. I'd call that less lax. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash in /usr/local/bin?
Joseph Mallett wrote: On Mon, Aug 13, 2001 at 07:23:26PM -0500, Jim Bryant wrote: DOD/DFAS, as well as DOD/DISA. I find it amazing that the CIA has a more lax policy than DFAS and DISA. The only person I've ever talked to from the CIA was in charge of network security to some degree, and according to him they can't even use FreeBSD, OpenBSD, or NetBSD internally. Everything must come from a central vendor and be supported by a real company, not by mailing lists. I'd call that less lax. Then, I'd call it about the same. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: race-to-the-root, hello anyone out there?
On Mon, Aug 13, 2001 at 06:01:55PM -0400, Garrett Wollman wrote: On Mon, 13 Aug 2001 14:57:54 -0700, David O'Brien [EMAIL PROTECTED] said: I should have mentioned this. /tmp is on /, which is UFS, mounted noatime and with softupdates enabled. Plenty of freespace:/dev/da0s1a 1.3G 843M 361M 70% / Same thing happens to me, but it's when sending mail (!) so there's no necessary correlation to the particulars of the filesystem. Typically I am doing mail also -- but my editor+MTA writes temp files before sending the mail out. I note that it doesn't lock up all the way immediately, Same. I can do anything on the machine as long as it doesn't involve a disk access. Ctrl-Alt-F1 to get out of X works fine, but a C-A-D after that to reboot will hang. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Last Words...(documentation)
On Mon, Aug 13, 2001 at 11:23:12AM -0700, Joe Kelsey wrote: TWO people have written to me and said that the reason THEY write documentation in their day jobs is that they get PAID for it. So, excuse me! I guess real programmers only write documentation when they are PAID! Yes! Obviously, working on a FREE product, you don't get paid so you don't document! After all, the meaning is obvious from the code! No, documenting is drudgery. People don't do non-fun things for free. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Last Words...(documentation)
Some of us try documant our stuff so that others can use it and because we feel that it's better to do something right than shoddily. On Mon, 13 Aug 2001, David O'Brien wrote: On Mon, Aug 13, 2001 at 11:23:12AM -0700, Joe Kelsey wrote: TWO people have written to me and said that the reason THEY write documentation in their day jobs is that they get PAID for it. So, excuse me! I guess real programmers only write documentation when they are PAID! Yes! Obviously, working on a FREE product, you don't get paid so you don't document! After all, the meaning is obvious from the code! No, documenting is drudgery. People don't do non-fun things for free. 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: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Fri, Aug 10, 2001 at 08:23:00PM +0300, Ruslan Ermilov wrote: Your solution does not work. You're creating binary files in HOST format during the build phase and expecting things such as alignment and endianness to be the same as the TARGET format. Unless the tools are built to output for either the appropriate architecture or in a portable, binary format, you will have problems reading the file on the TARGET platform. It probably works for you since you're doing a 4.X-5.0 upgrade on the same platform. What? ``file -C'' produces different output on Alpha and on i386? Are you sure? (Haven't checked myself.) They produce the same output, but in the general case they do not need to. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
race-to-the-root, hello anyone out there?
Hello?? Those that have committed to /sys in the past 1.5mo, awake? I am continuing to suffer thru what appears to be inode deadlocks where the resulting race-to-the-root soon locks everything up solid. Tried to figure out how to reproduce it on demand. All I can characterize is the file activity that FUBARs the system is in /tmp. What ideas do people have to solve the problem? crashdump are an impossibility due to the locked up disk system. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: race-to-the-root, hello anyone out there?
I should have mentioned this. /tmp is on /, which is UFS, mounted noatime and with softupdates enabled. Plenty of freespace:/dev/da0s1a 1.3G 843M 361M 70% / To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: write.c patch (WARNS 2)
On Fri, 10 Aug 2001 23:06:49 -0400 David Hill [EMAIL PROTECTED] wrote: Hello - Here is my patch to make write.c work when WARNS=2. I also did some code cleanup 1. Constify 2. Changed a strncpy to strlcpy 3. Changed (S_IWRITE 3) to S_IWGRP 4. Cleaned up 2 pieces of code (declaration and unused variable) when WARNS=2 is set. - David Could someone please review this patch and comment on it? Thank you - David To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
