Re: Official request: Please make GNU grep the default
On Thu, Aug 19, 2010 at 09:42:01PM +, b. f. wrote: Gabor: One more thing to look into, in addition to the context problems, ndisgen breakage, and problems on certain file systems: At r211506, 'grep -wq' does not seem to work properly (in the very least, it is not the same as with GNU grep), and has broken the 'check-categories' target (and hence builds) of all ports with 'lisp' in CATEGORIES. Seconded. This also breaks the ports using bsd.apache.mk, and what's worse, it does so silently. I have been bitten by this myself with www/apache22, several core modules have not been built resulting in a useless apache installation. So, I believe there is more to do here than just performance optimisation. -- Regards: Szilveszter ADAM Budapest Hungary ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: k3b causing system freeze/panic
On Wed, Jul 28, 2010 at 01:42:30PM +0200, Dag-Erling Sm??rgrav wrote: Sorry, I misparsed ATA_CAM as ahci. Why on earth would anyone want to use ATA_CAM these days? Well, I am not sure if you really meant ATA_CAM and not ATAPICAM? But in case you meant it, for people who do not use SATA-capable hardware, ATA_CAM is useful. This laptop may be no longer be the most recent model these days, but runs -CURRENT just fine most of the time. Also, if I remember correctly, for people with a bit more recent controllers ATA_CAM offers other advantages, but those do not affect me. So, for me ATA_CAM is just a better version of the ata(4) driver... -- Regards: Szilveszter ADAM Budapest Hungary ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Switchover to CAM ATA?
On Fri, Apr 23, 2010 at 09:40:59AM +0300, Andriy Gapon wrote: on 23/04/2010 07:48 Szilveszter Adam said the following: There is one interesting tidbit though: previously it used to be possible to run cdda2wav also as non-root, provided the user running it had read access to the /dev/cd0 device. This seems to no longer work. Probably you also need access to the corresponding passX device, which you can find from output of 'camcontrol devlist'. You didn't need that with *a*cd0. That seems to be it, the perms on pass1 needed fixing. Thanks for the tip! -- Regards: Szilveszter ADAM Budapest Hungary ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Switchover to CAM ATA?
Dear Alexander, dear collegaues, On Thu, Apr 22, 2010 at 06:31:37PM +0300, Alexander Motin wrote: Can we do switchover now, or some more reasons preventing this? I have been using ATA_CAM with legacy support for ata(4) for some time, and have found it to be stable and very useable. I have even removed atapicam from the kernel, since it is no longer needed, I have the /dev/cd0 device also without. So, in my opinion it is ready for prime-time also on legacy hw. There is one interesting tidbit though: previously it used to be possible to run cdda2wav also as non-root, provided the user running it had read access to the /dev/cd0 device. This seems to no longer work. Has anybody else noticed this? -- Regards: Szilveszter ADAM Budapest Hungary ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dumb question 'Bad system call' after make world
Hello, On Fri, Nov 21, 2003 at 09:44:17PM -0500, Barney Wolff wrote: Does make world build a kernel? I didn't think so, and OP's message indicates that make world is all he did. I suspect re-install is the best answer now. Yes, make world does not build or install kernels. I'd also go for reinstall, provided the OP has not yet put a lot of work into customising the install... Will somebody please tell me when make world is ever correct in the environment of the last several years? I've been unable to understand its continued existence as a target. One of it's last hideouts seems to be the make release target... -- Regards: Szilveszter ADAM Budapest Hungary ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question on freeBSD (5.1-CURRENT) portupgrade of Perl 5.8 andlibiconv 1.9.1_3
Hello, On Wed, Oct 22, 2003 at 01:21:10AM -0400, Joe Marcus Clarke wrote: On Wed, 2003-10-22 at 01:14, Scott W wrote: Also, is there a way to pass configure options to portupgrade, or should I run make clean ./configure for each port in an 'upgrade chain' and then force portupgrade to not make clean prior to building/installing? Configure arguments? No. However, you can use the -m option to pass make arguments (e.g. -DWITH_FOO). To pass configure arguments, you'd have to edit the port Makefiles directly. There is an easier way: you can use CONFIGURE_* variables, which can also be defined on the command line. For documentation on these and on the Makefile format for ports, see the Porters Handbook. There is also pkgtools.conf, as has been noted. Hope this helps. -- Regards: Szilveszter ADAM Budapest Hungary ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh terminated abnormally
On Sat, Oct 04, 2003 at 09:19:45PM -0700, Mike Hunter wrote: when I boot into the FreeBSD 5.1 I am getting this error message : WARNING: Userland calling deprecated sysctl, please rebuild world. I tried to world rebuild the but I can't It's failing at /usr/src/gnu/usr.bin/gperf I re-cvsuped the src this time I can't buildworld Stop in /usr/src/include/sys/_type.h : 80 i dont know what to do now I'm cc'ing current because I'm not sure what the best thing to do is at this point. You could try rm -rf'ing /usr/srclil help? No need to do that. You have done the following: buildworld on old system. Worked. buildkernel on old system. Worked. installkernel on old system. Worked, but now your kernel is not in sync with your userland any more. reboot with new kernel (with manual intervention). Seems it worked. But now you need to make installworld, to get back in sync. (from single user mode, of course) But best would be, for future reference, to first update the src files to the 5.x you are upgrading to, *then* reading /usr/src/UPDATING, there is a lenghty section on upgrading from 4.x to 5.x, and following it to minute detail, because this operation is rather complicated. The section is titled To upgrade in-place from 4.x-stable to current. It is not late to read it even now. There are a few things worth noting in there. -- Regards: Szilveszter ADAM Budapest Hungary ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sound card woes
Hello, On Fri, Aug 22, 2003 at 11:30:45AM -0400, Matt Gostick wrote: On Wed, 2003-08-20 at 17:04, Szilveszter Adam wrote: What does 'cat /dev/sndstat' say? # cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: SB16 DSP 4.16 (ViBRA16X) at io 0x220 irq 7 drq 0 bufsz 4096d (1p/1r/0v channels duplex default) So it's a Vibra. It seems to be detected mostly ok. cat test.wav /dev/dsp makes a sound... but it isn't exactly what test.wav should sound like. You mean the sound is distorted? The issue is probably some resource conflict. Since you have an SB 16, I'll have to ask: is it ISA? Or ISAPnP? Or PCI? PCI should just work but if it is ISA, you will need some tweaking. It is an ISA card... very old. Should I try and dig up a PCI card, or is it going to fairly 'painless' tweaking? Where should I start tweaking? My previous assumption seems to be reinforced, it is probably a resource conflict. If the card is ISAPnP (I think it is) you could try to extract a correct configuration from it using the pnpinfo command. Do not be very surprised if you will see many possible configs. (My old SB 64 AWE card had at least 6 or something) Pick one that is marked best or similar and check that the kernel uses that. You should also try and avoid IRQ sharing for the slot that the card is in if possible. If the card does not find the proper setting by itself, you may need to use hints. See them in /usr/src/sys/conf/NOTES, like this: hints.sbc.0.at=isa hints.sbc.0.port=0x220 hints.sbc.0.irq=5 hints.sbc.0.drq=1 hints.sbc.0.flags=0x15 Please do not copy these simply, but find the settings that your card supports and use those! If the card is not even ISAPnP, then you need its docs to find the real config. Possibly there is also a DOS program to set them on the card or jumpers. For your first question, yes, it should be easier to get a PCI card to work (even an SB 16) and it will cause less problems in any case. ISA cards can impact the system performance very badly. Hope this helps somewhat. -- Regards: Szilveszter ADAM Budapest Hungary ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sound card woes
Hello, On Wed, Aug 20, 2003 at 03:20:55PM -0400, Matt Gostick wrote: I have a SND Blaster 16 in my computer. I was using FreeBSD 4.8 and 'device pcm' in my kernel config file, worked great. I've completely re-installed with 5.1R and recompiled my kernel with 'device pcm'. Unfortunately sound doesn't work. You also could add 'device sbc' to your kernel config since that is the SB bridge driver. But the card should work with PCM only. What does 'cat /dev/sndstat' say? The issue is probably some resource conflict. Since you have an SB 16, I'll have to ask: is it ISA? Or ISAPnP? Or PCI? PCI should just work but if it is ISA, you will need some tweaking. I no longer have a /dev/snd0 device - I think I had one before... how do I make devices in 5.1R??? MAKEDEV is no longer available... and section 9.5 of the FreeBSD manual says: If you are running FreeBSD 5.0 or later you can safely skip this section. These versions use devfs(5) to allocate device nodes transparently for the user You do not need this, devfs will create the device for you when needed. -- Regards: Szilveszter ADAM Budapest Hungary ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: XFree86 4.2.99.3 on -CURRENT
Hello, On Tue, Dec 31, 2002 at 11:09:28AM +0100, Frode Nordahl wrote: Hello, Has anyone had any success with this combo? Yes. Apart from the known problem with my S3 Virge GX2 graphics adapter, which causes random freezes under X when only the reset button helps. But this has been happening since at least X version 4.2.0. Unfortunately, there seems to be no easy fix for the problem, apart from buying a new video card. It compiles fine, but the X server aborts due to bus error (SIGBUS) generated by something in xf86GetPciBridgeInfo() (xc/programs/Xserver/hw/xfree86/common/xf86pciBus.c) Running -CURRENT (World/kernel) as of December 29. XFree86 sources as of December 30, cvsup'ed with tag xf-4_2_99_3 Hmmm. I have the same version of X as you (roughly, the tag was already in place by the time I built although I always use HEAD, I built on 23rd December) and FreeBSD is from 25th December. My hardware deatils: (they may be relevant) - 440LX chipset (yes, from '98) - PII 233 - S3 Virge GX2 in AGP slot - BIOS is still the original from spring 1998. I have AGP in the kernel, but I cannot say if X uses it or not, there is no word of it in the X log. I used the CVS to build X, but tweaked the config to use the expat, the freetype2 and libxml2 from the system (ports) instead of the packaged ones that are in the X repo. Additional info is available on request, including details of my build environment. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: XFree86 4.2.99.3 on -CURRENT
On Tue, Dec 31, 2002 at 11:51:34AM +0100, Frode Nordahl wrote: On Tue, 2002-12-31 at 11:30, Szilveszter Adam wrote: Hmmm. I have the same version of X as you (roughly, the tag was already in place by the time I built although I always use HEAD, I built on 23rd December) and FreeBSD is from 25th December. I just updated the sources to HEAD, and I see changes was made in FreeBSD related configfiles and other related .c files around December 23. I would like to add, that at present, no source patches were required to compile X on -CURRENT. This should ease the upgrade of the port when 4.3.0 comes out. (Although I still have gripes with the way the XFree86-4 metaport works right now: it is very inefficient) Wish you good luck. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs permissions after reboot
Hello, On Fri, Dec 27, 2002 at 12:11:27AM +0100, Gernot A. Weber wrote: Hi, I know how to change file permissions on devfs. But which file do I have to edit that these changes are no lost after a reboot? E.g. I altered my scanner dev: You would need to edit /etc/rc.devfs. Another thing: I often need a symlink /dev/cdrom to /dev/cd0. What's the best way to do this... In rc.devfs, put this: ln -s /dev/cdrom /dev/cd0. Easy enough:-) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd problem - solved (?)
On Wed, Dec 11, 2002 at 03:34:57PM +0200, Vasyl S. Smirnov wrote: Hi, I suppose I've found the reason for such a strange sshd behaviour - the problem is I was using login classes in my master.passwd. Man for master.passwd says that login classes aren't implemented yet - strange, in 4-STABLE they seem to be working fine. Can someone explain this? (or give some URL). Although not strictly related to your sshd problem, I would like to say that login classes are implemented, only not all of the knobs that the manpage describes used to work at the time the page was written. (I do not know how about now) The warning is there because some of the knobs are used to restrict users' resource usage, and it was not advisable for admins to rely on these for functionality. I do not know, maybe the situation has changed since, somebody should try. But other aspects of login classes work Just Fine(TM): for example I use them to give my users a Hungarian-locale environment independent of the shell they use. This has been in use for months (if not years) and has always worked (also through ssh). This must be something else. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /usr/ports/graphics/lcms fails test on current with P4
On Fri, Dec 06, 2002 at 10:59:16AM -0800, James Satterfield wrote: lcms still fails build tests when compiled with CPUTYPE?=i686 and no CFLAGS set. James. Worked just fine yesterday on PII-233, albeit with the previous (prerelease) 3.2.1 system compiler. (20021009) I use -march=pentium2. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Weirdness trying -STABLE - -CURRENT
Hello David, Thanks for getting back with the results. This points to the fatc that the instructions in UPDATING should updated. The method is almost what you did, only a tad more efficient: - make buildworld - make buildkernel KERNCONF=you_know_what - cp GENERIC.hints to device.hints or create your own if you need (because you have ISA devices eg) - make installkernel KERNCONF=you_know_what - reboot in single user (do the bootblocks if needed) (At this point you are running on the -CURRENT kernel but with the old userland: be aware of this because things like ipfw will now stop working until you are back in sync!) - mergemaster -p - make -k installworld (this will install as much of the new userland as possible, but will proceed in spite of errors.) - rm -rf /usr/include/* - make installworld (this now should go through without problems, you are now back in sync, your /usr/include is also repopulated with the new headers) - mergemaster (with the new mergemaster script) - reboot for the changes to take effect. Done. Hope this helps. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Weirdness trying -STABLE - -CURRENT
On Tue, Aug 13, 2002 at 01:43:44PM -0600, Kyle Butt wrote: Szilveszter Adam wrote: (At this point you are running on the -CURRENT kernel but with the old userland: be aware of this because things like ipfw will now stop working until you are back in sync!) The trick here is that a new loader isn't installed yet. the old kernel lives in /kernel and the new one in /boot/kernel/kernel you have to be sure and boot the new one. make -k installworld accomplishes the same thing (By installing a new loader) I was not merely thinking of this. For ipfw to work, the kernel and the /sbin/ipfw binary have to match, or else adding or otherwise manipulating rules will likely fail. This will either result in a wide-open firewall or a tightly closed one, depending on the kernel config. This happens even when the ipfw support is not loaded from a module. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Weirdness trying -STABLE - -CURRENT
On Mon, Aug 12, 2002 at 12:41:19PM -0700, David O'Brien wrote: On Sun, Aug 11, 2002 at 09:41:19PM +0200, Szilveszter Adam wrote: This is known problem, straight updates by simply make world do not work from -STABLE. Therefore, one has to very carefully follow the procedure described in the UPDATING file even though normally not so many steps would be needed. Uh... did you actually READ all that text you snipped out? David *DID* follow the correct steps -- please go back and read what he did: Did you actually read my second message in this thread? It was sent only a short time after the first one. (and no need to shout I am sitting close to the monitor keys) Since David has not yet gotten back to us I have no more ideas since that second posting. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Weirdness trying -STABLE - -CURRENT
Hello David, First off, sorry for the lot of snippage but this mail was really long... On Sun, Aug 11, 2002 at 11:37:06AM -0700, David Wolfskill wrote: ... OK; I brought it back up under today's -STABLE, and looking at the typescript file, I see that it ends thusly: ... === usr.bin/checknr install -s -o root -g wheel -m 555 checknr /usr/bin install -o root -g wheel -m 444 checknr.1.gz /usr/share/man/man1 === usr.bin/chflags install -s -o root -g wheel -m 555 chflags /bin install -o root -g wheel -m 444 chflags.1.gz /usr/share/man/man1 === usr.bin/chpass [ ! -e /usr/bin/chpass ] || chflags noschg /usr/bin/chpass || true *** Signal 12 ... So I get the impression that folks who are complaining about the shell getting a SIGSYS probably aren't hallucinating (about that, anyway), and to the extent that there's a (non-recovered) mistake in the procedure I followed, perhaps the effected folks are doing something similar. This is known problem, straight updates by simply make world do not work from -STABLE. Therefore, one has to very carefully follow the procedure described in the UPDATING file even though normally not so many steps would be needed. To get of this situatio, the person(s) affected should do a make -k installworld now and then a make installworld again anf this way get all the new userland installed. Also, one should not use the -j when upgrading (as stated in UPDATING) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Weirdness trying -STABLE - -CURRENT
It's me again... On Sun, Aug 11, 2002 at 11:37:06AM -0700, David Wolfskill wrote: * reboot (single-user mode) Now, at this step, I see something a bit odd: Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/523200kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Sun Aug 11 09:29:25 PDT 2002) Loading /boot/defaults/loader.conf Warning: syntax error on file /boot/device.hints machine i386 ^ Warning: syntax error on file /boot/loader.conf $ ^ /boot/kernel/kernel text=0x237e0c data=0x35db4+0x6f72c syms=[0x4+0x36820+0x4+0x421d1] As for this part: Are you *really* sure that the files were what you believed them to be? The first appears to me to be a kernel config file instead of the device.hints. I have no idea about the second, it could be any file with a $FreeBSD$ tag in it, which was not commented properly or something. BTW: I looked over the suggested order of steps in UPDATING just now, you did things pretty much according to that (with the exception of the -j for the buildworld but that one cannot be that dramatic, I assume you did not use the -j for the installworld. So, I still have no real explanation for your hanging of the machine. Perhaps someone else. The first failure is memory corruption in any event but the reason is not known to me. I have not seen it reported here yet. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: firewall support?
On Mon, Jul 29, 2002 at 02:44:50PM +0200, Sheldon Hearn wrote: On (2002/07/28 09:49), Szilveszter Adam wrote: is firewall support built into the -current kernel or does it need to be compiled in? It is not in GENERIC, but you can always either compile it in, or load it from a module by editing /boot/loader.conf. Beware! AFAIK, the kernel-loadable version of IPFW (ipfw.ko) defaults to deny! Correct. But we also have ipfilter, which is also loadable... but I did not want to be specific. If there are other questions, I will. Enable with care on remotely managed systems for which you do not have serial console access. It's not for nothing that the first rule of firewall configuration: Show up! (at the console). Many a surprise can be averted this way...:-) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: a gcc3.1 bug ?
On Sun, Jul 28, 2002 at 02:40:15PM +0800, Huang wen hui wrote: hi, I used gcc3.1 from ports to compile jdk1.3.1-p7 hotspot, I got problem in compiing /usr/src/lib/libc_r/uthread/pthread_private.h : While I - unfortunately - do not know the solution to your problem, I would like to report that I compiled the jdk with the new patchset just yesterday on my week-old -CURRENT and it worked ok. However, I always clean out /usr/include before installworld, so there may be no stale header files there. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: firewall support?
On Sat, Jul 27, 2002 at 11:59:01PM -0700, karl agee wrote: is firewall support built into the -current kernel or does it need to be compiled in? --karl It is not in GENERIC, but you can always either compile it in, or load it from a module by editing /boot/loader.conf. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Is it just me or has -current suddenly got massively unstable?
Hello, I have a kernel and world from Saturday, it seems reasonably ok in console mode (does not panic although it is used as an ADSL router) but in X, it locks up very easily. I tried it with Mozilla on Sunday, it froze twice within as many hours, in a seemingly undeterministic manner. Unfortunately, the locks make the machine unable to give any useful info, it does not reboot by itself either. As said, I can do even demanding things on the console (eg building Mozilla, generating the PR stats page during the website build etc). Additional detail: My previous kernel was from the 18th, with the bandaid fix to pmap.c, and that one did not lock up under X, at least not during my testing. So, yes, I am seeing unstability, but only under X. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Fixed ! Re: Interesting panic very early in the boot
Hello everybody, I would like to report that after incorporating today's fixes into the kernel source and recompiling, the panic does not occur again. This is probably due to the commit to pmap.c (rev 1.345 by Peter Wemm). Although the log only talks about SMP, this UP box likes it too. So anyway, thanks for fixing this, and anybody who used the DISABLE_PG_G workaround can now switch that off. Happy hacking! -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fixed ! Re: Interesting panic very early in the boot
On Thu, Jul 18, 2002 at 01:40:48PM -0400, Bosko Milekic wrote: As pointed out, the change was fairly bogus. There's a new change that should be committed soon that fixes the problem in a sort of less bogus way. When Peter gets around to reviewing it, it'll be committed and you shouldn't notice a difference. Excellent. As I stated, all I wanted to report was that the panic did not occur again. This is good news in any event, because it seemed that it did not occur very frequently, so seemed more difficult to fix. I was just fearing that it would take perhaps a very long time, eg because it does not occur so often on new hardware or somesuch. A correct fix is certainly even better. As a point of reference, however, what hardware do you have this running on? Specifically, what board, CPUs, how many, and how much RAM do you have? Full specs: - Shuttle Spacewalker HOT-637/P motherboard with Intel 440 LX chipset, UP. Has ISA, PCI and AGP slots, doesn't support ACPI. (in any meaningful way) - Intel Pentium II 233 Mhz (Klamath) CPU, Slot 1 - 128 megs of SDRAM (non-DDR) in two 64 meg units - Two ATA HDDs, ATAPI CD-ROM, PCI network card (Realtek 8029), ISA PnP SB 64 AWE sound, S3 Virge GX2 AGP video card, just in case. No SCSI. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Interesting panic very early in the boot
On Wed, Jul 17, 2002 at 09:57:41AM -0700, Bakul Shah wrote: Terry suggested: I believe setting DISABLE_PSE in the config file and rebuilding will make this go away. Terry, thanks for the suggestion but that didn't do it. Ok, so it's time to speculate a bit more about this. Although I have been seeing this panic since Sunday, only one other person has reported it so far. Although it may be that this is due to the fact that developers do not run up-to-date -CURRENT and hence do not see problems that are this new (and I bet that the tinderbox only tests building, but does not try to actually run the stuff), perhaps there is a different explanation. Bakul mentioned that the panic happens on a PPro. For me, it's a PII. I am using a CPUTYPE setting of p2 in /etc/make.conf. This gets converted to a -march=pentiumpro on the actual compile line. This may be the same for the PPro. This suggests a remote possibility that there might be a problem with this option, so this is the next thing that I am going to test. We'll see... -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Interesting panic very early in the boot
On Wed, Jul 17, 2002 at 07:38:22PM +0200, Szilveszter Adam wrote: Bakul mentioned that the panic happens on a PPro. For me, it's a PII. I am using a CPUTYPE setting of p2 in /etc/make.conf. This gets converted to a -march=pentiumpro on the actual compile line. This may be the same for the PPro. This suggests a remote possibility that there might be a problem with this option, so this is the next thing that I am going to test. We'll see... We did. It did not make a difference. Let's move on... -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Interesting panic very early in the boot
On Wed, Jul 17, 2002 at 11:35:35AM -0700, Terry Lambert wrote: My bet on the root cause, if I am correct, means that if you change the amount of physical RAM installed in the machine, the problem will go away, and that the problem is probably rare because it depends on certain things that are more complicated, after Matt's changes after my complaints about machdep.c reservations on large memory machines, as the amount of physical RAM approaches the size of the address space. 'Key, I can try that too. However, this machine is anything but large memory these days: it has 128 Megs of (non-DDR) SDRAM. (2x64) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Interesting panic very early in the boot
Hello everybody, I have recently finished to upgrade my system to today morning's -CURRENT, with sources just *before* the commit of rev 1.154 to src/sys/kern/kern_fork.c by Julian. I have an UP IA32 machine, I am not using any additional kernel modules, and now, upon rebooting with the new kernel, as soon as I allow to continue from the loader prompt, the kernel greets me with this: (No serial console, transcribed by hand, please excuse any typos) Fatal trap 12: page fault within kernel mode fault virtual address = 0xbff004c0 fault code = supervisor read, protection violation instruction pointer = 0x8:0xc035c348 stack pointer = 0x10:0xc0532c08 frame pointer = 0x10:0xc0532c10 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL=0 current process = 0 () kernel: type 12 trap, code=0 Stopped at 0xc035c348: cmpl $0,0xbfc0(%eax) Unfortunately, there is preciously little I could extract from ddb after this. ddb ps pid proc addr uid ppid pgrp flag stat wmesg wchan cmd 0 c03f00c0 c053 0 0 000 New ddb tr (null)(c0418920,c080,537000,c0532d48,c03595bd) at 0xc035c348 (null)(537000,0,c0532c9c,c0532ce8,10) at 0xc035c290 (null)(537000,c0352524,f,0,8) at 0xc03595bd (null)(537000) at 0xc0359fb9 (null)() at 0xc0130c7d An attempt to show locks resulted in: witness_list: witness_cold Fatal trap 3 breakpoint instruction fault while in kernel mode An attempt to show witness resulted in: witness_display: witness_cold Uptime 1s and a complete lockup, only a power-cycle helped. No dump was taken. Does this ring a bell with anyone? I know that the trace may not help much... I will be just too glad to offer any information or testing that may be needed. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Interesting panic very early in the boot
On Sun, Jul 14, 2002 at 07:49:57PM +0200, Szilveszter Adam wrote: Hello everybody, I have recently finished to upgrade my system to today morning's -CURRENT, with sources just *before* the commit of rev 1.154 to src/sys/kern/kern_fork.c by Julian. I have an UP IA32 machine, I am not using any additional kernel modules, and now, upon rebooting with the new kernel, as soon as I allow to continue from the loader prompt, the kernel greets me with this: ... Sorry I should have said that I have ACPI compiled into the kernel, but it is apparently not supported by the motherboard. Will try without it next. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Interesting panic very early in the boot
On Sun, Jul 14, 2002 at 08:06:49PM +0200, Szilveszter Adam wrote: On Sun, Jul 14, 2002 at 07:49:57PM +0200, Szilveszter Adam wrote: Hello everybody, I have recently finished to upgrade my system to today morning's -CURRENT, with sources just *before* the commit of rev 1.154 to src/sys/kern/kern_fork.c by Julian. I have an UP IA32 machine, I am not using any additional kernel modules, and now, upon rebooting with the new kernel, as soon as I allow to continue from the loader prompt, the kernel greets me with this: ... Sorry I should have said that I have ACPI compiled into the kernel, but it is apparently not supported by the motherboard. Will try without it next. I upgraded the kernel source and removed ACPI from the config, but still no joy. Something fishy going on here... -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problems with j2sdk_1.3.1
Hello, On Sat, Jul 13, 2002 at 10:00:43AM +0200, Andrzej Kwiatkowski wrote: When i try to compile Openoffice 1.0 my instalation stops when compiling port jdk13 My output looks like: ... -I../../../../src/solaris/javavm/export -I/usr/X11R6/include -o ../../tmp/bsd/i386/GetFactory.o ../../oji-plugin/src/motif/common/GetFactory.cpp In file included from ../../oji-plugin/include/solaris/navig4/oji/nsIJVMPlugin.h:34, from ../../oji-plugin/src/motif/common/JavaPluginFactory.h:34, from ../../oji-plugin/src/motif/common/GetFactory.cpp:55: /usr/local/include/jni.h:17:31: gcj/libgcj-config.h: No such file or directory ... My gcc is 3.1 installed from ports: Reading specs from /usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/3.1.1/specs Configured with: ./..//gcc-20020701/configure --disable-nls --with-gnu-as --with-gnu-ld --with-gxx-include-dir=/usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/3.1.1/incl ude/g++ --disable-libgcj --disable-shared --prefix=/usr/local i386-portbld-freebsd5.0 Thread model: posix gcc version 3.1.1 20020701 (prerelease) [FreeBSD] It seems that the compile gets confused, and wants to use gcj the GNU Java compiler for compilation, but that one cannot work because there is no libgcj yet (the comment in the Makefile says it does not bootstrap). This problem also appears with the new gettext port which also has some Java components and the configure script detects gcj if it is installed but does not notice that it is not useable. The solution is to set JAVAC=javac in the environment before starting the make. If you want to go for sure, you can give an exact path. If needed, other Java tools may also be set similarly to the ones from the JDK instead of GCC. (eg Javah comes to mind) Hope this helps. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ppp sig10's in current
Hello, You were not, by any chance, using the -nat option with ppp? If you were, and have a recent -CURRENT with the new ipfw code, then *that* will make ppp dump core with a sig10 just fine. (Same behaviour as with natd) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fsck hosed?
On Sun, Jul 07, 2002 at 09:41:14PM -0700, Peter Wemm wrote: It seems to be aborting the 'process all file systems' loop when it modifies a file system. eg: ... [[[ Uhh, what? What about the rest of the file systems? ]]] I saw this once yesterday night, (after getting an automagic reboot while running Mozilla... is this a new kind of anti-porn device?:-P) and was puzzzled seeing that as well. But interestingly, after this I just persisted and issued fsck -y again and this time it ran as it should. While we are here: while fsck -y returns the fragmentation etc values correctly, fsck -p always says: 0.0 % fragmentation for all my filesystems. Like this: /dev/ad1s1a: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/ad1s1a: clean, 1016302 free (14 frags, 0 blocks, 0.0% fragmentation) Anyone else seen this? -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: natd core dumping with bus error
Hello, Yes, I've seen the same thing on a pre-KSE kernel. The error occurs in PunchFWHole in alias_db.c in libalias. Reverting the following commit seems to fix it (I haven't had a chance to investigate further): ... sys/netinet ip_fw.h Reverting only this file and recompiling libalias and natd fixes the natd breakage for me. However, I was seeing some possible side effect of this (see my earlier mail about deny rules not working in ipfw) but I am not sure since I have at least one other report of this. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
problems with natd, ipfw
Hello everybody, I upgraded to yesterday's -CURRENT and have made a few observations: 1) The natd does not work. This is known, but I have tracked it to its interaction with libalias, which means that any program that uses libalias functions is also affected (and indeed, ppp(8)'s -nat option does not work either). If I downgrade the file src/sys/netinet/ip_fw.h to the version from June 27, and recompile libalias and natd, things will work. 2) and much more alarmingly: Although the new ipfw really seems to process the ruleset faster, some rules appear to do nothing! I have a default-to-deny setup, so theoretically this should mean that I should be cut off from the net if the allow rules do not work. And indeed, flushing all rules gives the expected behaviour. But as soon as I load the ruleset file (which is the same as previously and then it worked as expected) the fw becomes wide-open, the only rules that appear to work are the divert for natd, and the allow rules. But the deny rules do nothing, it seems that even the catch-all implicit deny rule at the bottom does nothing. Am I going insane, or is this real? Also, I have observed that when loading the rules from the ruleset file, ipfw prints two lines for each, one with the expected rule number and one with all zeros. I don't know if it's significant though. It is like this: 0 deny log ip from any to any 03600 deny log ip from any to any This did not happen previously... -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What's the right way to build XFree86-4 now?
On Sun, Jun 30, 2002 at 11:58:51PM -0400, Garance A Drosihn wrote: Have many people had a chance to test this? I wanted to try it out this weekend, but I lost most of the weekend due to other problems with compiling current on my test machine. I finally got by those problems, but now it's midnight on Sunday and I can't really afford to start on this right now... Sorry, me not. I also was struggling with -CURRENT buildworld during the weekend and my machine is slow. I rebuilt X with the most recent patch to libGLU from this list and libGLU now seems working. (with the system compiler) The machine freezes under X quite frequently however, but I don't know what is causing it. (and X freezes have the disgusting property of locking up the system solid: no console, no network, nothing in the logs.) Life is sometimes hard in -CURRENT land, but hey, we should never loose our sense of humour. (And yes, maybe I really should get another graphics card... the S3 Virge GX2 may also take part of the blame for the lockups...) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: Which .info files have been disabled?
Hello everybody,
Sorry for taking a tad long with this, here is the second patch set for
the GDB info files.
I implemented both of David's suggestions, so the third patch is no
longer needed and GDBvn.texi can be safely cvs rm-d now, it is generated
dynamically at build time.
If you want to go all the way, you can change the name of
inc-hist.texi.diff to inc-hist.texinfo.diff, but that involves a repo
copy.
Have a good weekend!
--
Regards:
Szilveszter ADAM
Szombathely Hungary
Index: Makefile
===
RCS file: /usr/home/cc/ncvs/freebsd//src/gnu/usr.bin/binutils/doc/Makefile,v
retrieving revision 1.11
diff -u -r1.11 Makefile
--- Makefile28 Jun 2002 03:41:56 - 1.11
+++ Makefile30 Jun 2002 08:27:15 -
-5,9 +5,9
GDBDIR=${.CURDIR}/../../../../contrib/gdb
CONTRIBDIR= ${.CURDIR}/../../../../contrib
-.PATH: ${SRCDIR}/gas/doc ${SRCDIR}/ld ${SRCDIR}/bfd/doc ${GDBDIR}/gdb/doc
+.PATH: ${SRCDIR}/gas/doc ${SRCDIR}/ld ${SRCDIR}/bfd/doc ${GDBDIR}/gdb/doc
+${GDBDIR}/gdb/mi
-INFO = as ld annotate gasp stabs binutils
+INFO = as ld annotate gasp gdb gdbint stabs binutils
INFOSECTION= Programming development tools.
INFOENTRY_as= * As: (as).The GNU assembler.
INFOENTRY_gasp=* Gasp: (gasp).The GNU Assembler Macro Preprocessor.
-19,6 +19,7
MAKEINFOFLAGS+= -I ${SRCDIR}/gas/doc -I ${SRCDIR}/ld -I ${SRCDIR}/bfd/doc
MAKEINFOFLAGS+= -I ${SRCDIR}/binutils
MAKEINFOFLAGS+= -I ${GDBDIR}/gdb/doc
+MAKEINFOFLAGS+= -I ${GDBDIR}/gdb/mi
MAKEINFOFLAGS+= -I ${CONTRIBDIR}/libreadline/doc
CLEANFILES=gdb-cfg.texi inc-hist.texi inc-hist.texi.orig \
-27,20 +28,26
as.info: as.texinfo asconfig.texi c-i386.texi gasver.texi
ld.info: ld.texinfo bfdsumm.texi ldver.texi
-gdb.info: gdb.texinfo gdb-cfg.texi GDBvn.texi remote.texi \
- rluser.texinfo inc-hist.texi
+gdb.info: gdb.texinfo gdb-cfg.texi GDBvn.texi annotate.texi \
+ fdl.texi gpl.texi gdbmi.texinfo \
+ rluser.texinfo inc-hist.texinfo
+gdbint.info: gdbint.texinfo fdl.texi
+
gdb-cfg.texi: all-cfg.texi
ln -sf ${.ALLSRC} ${.TARGET}
+GDBvn.texi: ${GDBDIR}/gdb/version.in
+ echo set GDBVN `sed q ${.ALLSRC}` ${.TARGET}
+
.PATH: ${SRCDIR}/binutils
binutils.info: binutils.texi config.texi
gasver.texi ldver.texi:
- echo set VERSION ${VERSION} ${.TARGET}
+ echo 'set VERSION ${VERSION}' ${.TARGET}
.PATH: ${CONTRIBDIR}/libreadline/doc
-inc-hist.texi: hsuser.texinfo inc-hist.diff
+inc-hist.texinfo: hsuser.texinfo inc-hist.diff
cp ${.ALLSRC:M*.texinfo} ${.TARGET}
patch -b .orig ${.ALLSRC:M*.diff}
Index: inc-hist.diff
===
RCS file: /usr/home/cc/ncvs/freebsd//src/gnu/usr.bin/binutils/doc/inc-hist.diff,v
retrieving revision 1.3
diff -u -r1.3 inc-hist.diff
--- inc-hist.diff 11 Apr 2001 04:27:10 - 1.3
+++ inc-hist.diff 29 Jun 2002 12:20:56 -
-1,7 +1,7
$FreeBSD: src/gnu/usr.bin/binutils/doc/inc-hist.diff,v 1.3 2001/04/11 04:27:10 ache
Exp $
inc-hist.texi.orig Wed Apr 11 08:20:01 2001
-+++ inc-hist.texi Wed Apr 11 08:21:57 2001
+--- inc-hist.texinfo.orig Wed Apr 11 08:20:01 2001
inc-hist.texinfo Wed Apr 11 08:21:57 2001
-26,9 +26,9
node Using History Interactively
chapter Using History Interactively
Re: [PATCH] Re: Which .info files have been disabled?
Grrr, hit me baby one more time.
One of the diffs included a completely gratuitous one-line change which
I made yesterday night while I was tired and neglected to correct today.
So, the patchset again. (Take three!)
--
Regards:
Szilveszter ADAM
Szombathely Hungary
Index: Makefile
===
RCS file: /usr/home/cc/ncvs/freebsd//src/gnu/usr.bin/binutils/doc/Makefile,v
retrieving revision 1.11
diff -u -r1.11 Makefile
--- Makefile28 Jun 2002 03:41:56 - 1.11
+++ Makefile30 Jun 2002 09:11:34 -
-5,9 +5,9
GDBDIR=${.CURDIR}/../../../../contrib/gdb
CONTRIBDIR= ${.CURDIR}/../../../../contrib
-.PATH: ${SRCDIR}/gas/doc ${SRCDIR}/ld ${SRCDIR}/bfd/doc ${GDBDIR}/gdb/doc
+.PATH: ${SRCDIR}/gas/doc ${SRCDIR}/ld ${SRCDIR}/bfd/doc ${GDBDIR}/gdb/doc
+${GDBDIR}/gdb/mi
-INFO = as ld annotate gasp stabs binutils
+INFO = as ld annotate gasp gdb gdbint stabs binutils
INFOSECTION= Programming development tools.
INFOENTRY_as= * As: (as).The GNU assembler.
INFOENTRY_gasp=* Gasp: (gasp).The GNU Assembler Macro Preprocessor.
-19,6 +19,7
MAKEINFOFLAGS+= -I ${SRCDIR}/gas/doc -I ${SRCDIR}/ld -I ${SRCDIR}/bfd/doc
MAKEINFOFLAGS+= -I ${SRCDIR}/binutils
MAKEINFOFLAGS+= -I ${GDBDIR}/gdb/doc
+MAKEINFOFLAGS+= -I ${GDBDIR}/gdb/mi
MAKEINFOFLAGS+= -I ${CONTRIBDIR}/libreadline/doc
CLEANFILES=gdb-cfg.texi inc-hist.texi inc-hist.texi.orig \
-27,12 +28,18
as.info: as.texinfo asconfig.texi c-i386.texi gasver.texi
ld.info: ld.texinfo bfdsumm.texi ldver.texi
-gdb.info: gdb.texinfo gdb-cfg.texi GDBvn.texi remote.texi \
- rluser.texinfo inc-hist.texi
+gdb.info: gdb.texinfo gdb-cfg.texi GDBvn.texi annotate.texi \
+ fdl.texi gpl.texi gdbmi.texinfo \
+ rluser.texinfo inc-hist.texinfo
+gdbint.info: gdbint.texinfo fdl.texi
+
gdb-cfg.texi: all-cfg.texi
ln -sf ${.ALLSRC} ${.TARGET}
+GDBvn.texi: ${GDBDIR}/gdb/version.in
+ echo set GDBVN `sed q ${.ALLSRC}` ${.TARGET}
+
.PATH: ${SRCDIR}/binutils
binutils.info: binutils.texi config.texi
-40,7 +47,7
echo set VERSION ${VERSION} ${.TARGET}
.PATH: ${CONTRIBDIR}/libreadline/doc
-inc-hist.texi: hsuser.texinfo inc-hist.diff
+inc-hist.texinfo: hsuser.texinfo inc-hist.diff
cp ${.ALLSRC:M*.texinfo} ${.TARGET}
patch -b .orig ${.ALLSRC:M*.diff}
Index: inc-hist.diff
===
RCS file: /usr/home/cc/ncvs/freebsd//src/gnu/usr.bin/binutils/doc/inc-hist.diff,v
retrieving revision 1.3
diff -u -r1.3 inc-hist.diff
--- inc-hist.diff 11 Apr 2001 04:27:10 - 1.3
+++ inc-hist.diff 29 Jun 2002 12:20:56 -
-1,7 +1,7
$FreeBSD: src/gnu/usr.bin/binutils/doc/inc-hist.diff,v 1.3 2001/04/11 04:27:10 ache
Exp $
inc-hist.texi.orig Wed Apr 11 08:20:01 2001
-+++ inc-hist.texi Wed Apr 11 08:21:57 2001
+--- inc-hist.texinfo.orig Wed Apr 11 08:20:01 2001
inc-hist.texinfo Wed Apr 11 08:21:57 2001
-26,9 +26,9
node Using History Interactively
chapter Using History Interactively
New GDB breaks buildworld: no fbsd-kgdb.h
Hello everybody, It seems that the new GDB import breaks world. Appearently, a file named fbsd-kgdb.h is missing, although it is included from /usr/obj/usr/src/gnu/usr.bin/binutils/gdb/nm.h, which is a generated file. Such a file cannot be found in the base gdb-5.2 distribution, and it is not in the FreeBSD CVS repo either, neither is it among the patches to the devel/gdb52 port. The relevant line of src/gnu/usr.bin/binutils/gdb/Makefile has been added in rev 1.60 (Bmake bits for GDB 5.2). It is not my job to decide if this file is needed or not. If it is, it should be added to the repo (or some way of generating it) if it isn't, the reference needs to be removed. Since it is the maintainer's chance to decide on the approach, no patch this time. There is a faint suspicion that this might be a forgotten part of the kernel debugging patches that were incorporated in-house by David. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[PATCH] Re: Which .info files have been disabled?
On Fri, Jun 28, 2002 at 05:49:33PM +0200, Szilveszter Adam wrote:
Hello Sheldon,
As far as I know, so far only the ones for GDB (and that only under
-CURRENT). If you get there first, go for it, but if not, I will also
look at the issue during the weekend.
To follow up on this: I have got the info files to build based on the
original Makefile in the src/contrib/gdb/gdb/doc/ dir.
The only questions remaining:
1) The GNU folks have a way of generating GDBvn.texi from version.in, so
that it has the same version information than the source code. We use
the GDBvn.texi file supplied with the distribution. (which was not
updated BTW, so it still says 4.18) Do we want to use
this method, or stick with the hard-coded one we are using now? In which
case GDBvn.texi needs updating.
NB: Arguably, changing this file is only necessary when the GDB version
changes, so maybe updating the file by hand in these rare cases is the
better solution. I did this now.
2) We generate a file named inc-hist.texi, but the GNU call this
inc-hist.texinfo. It is possible to patch the file gdb.texinfo which
includes it, or it is possible to change our target in
src/gnu/usr.bin/binutils/doc/Makefile appropriately. Since it is not
used anywhere else, I decided on the latter. This is also included in
the patch.
This has been tested on an empty /usr/obj with make obj make make
clean and did work, furthermore, visiting the newly generated info files
with the info command directly showed that they worked.
Please, review the patch, and, if you like it, apply it. Please send any
and all comments to me or to the list. (but preferably not to both)
Happy weekend.
--
Regards:
Szilveszter ADAM
Szombathely Hungary
Index: Makefile
===
RCS file: /usr/home/cc/ncvs/freebsd//src/gnu/usr.bin/binutils/doc/Makefile,v
retrieving revision 1.11
diff -u -r1.11 Makefile
--- Makefile28 Jun 2002 03:41:56 - 1.11
+++ Makefile29 Jun 2002 12:38:55 -
-5,9 +5,9
GDBDIR=${.CURDIR}/../../../../contrib/gdb
CONTRIBDIR= ${.CURDIR}/../../../../contrib
-.PATH: ${SRCDIR}/gas/doc ${SRCDIR}/ld ${SRCDIR}/bfd/doc ${GDBDIR}/gdb/doc
+.PATH: ${SRCDIR}/gas/doc ${SRCDIR}/ld ${SRCDIR}/bfd/doc ${GDBDIR}/gdb/doc
+${GDBDIR}/gdb/mi
-INFO = as ld annotate gasp stabs binutils
+INFO = as ld annotate gasp gdb gdbint stabs binutils
INFOSECTION= Programming development tools.
INFOENTRY_as= * As: (as).The GNU assembler.
INFOENTRY_gasp=* Gasp: (gasp).The GNU Assembler Macro Preprocessor.
-19,6 +19,7
MAKEINFOFLAGS+= -I ${SRCDIR}/gas/doc -I ${SRCDIR}/ld -I ${SRCDIR}/bfd/doc
MAKEINFOFLAGS+= -I ${SRCDIR}/binutils
MAKEINFOFLAGS+= -I ${GDBDIR}/gdb/doc
+MAKEINFOFLAGS+= -I ${GDBDIR}/gdb/mi
MAKEINFOFLAGS+= -I ${CONTRIBDIR}/libreadline/doc
CLEANFILES=gdb-cfg.texi inc-hist.texi inc-hist.texi.orig \
-27,9 +28,12
as.info: as.texinfo asconfig.texi c-i386.texi gasver.texi
ld.info: ld.texinfo bfdsumm.texi ldver.texi
-gdb.info: gdb.texinfo gdb-cfg.texi GDBvn.texi remote.texi \
- rluser.texinfo inc-hist.texi
+gdb.info: gdb.texinfo gdb-cfg.texi GDBvn.texi annotate.texi \
+ fdl.texi gpl.texi gdbmi.texinfo \
+ rluser.texinfo inc-hist.texinfo
+gdbint.info: gdbint.texinfo fdl.texi
+
gdb-cfg.texi: all-cfg.texi
ln -sf ${.ALLSRC} ${.TARGET}
-40,7 +44,7
echo set VERSION ${VERSION} ${.TARGET}
.PATH: ${CONTRIBDIR}/libreadline/doc
-inc-hist.texi: hsuser.texinfo inc-hist.diff
+inc-hist.texinfo: hsuser.texinfo inc-hist.diff
cp ${.ALLSRC:M*.texinfo} ${.TARGET}
patch -b .orig ${.ALLSRC:M*.diff}
Index: inc-hist.diff
===
RCS file: /usr/home/cc/ncvs/freebsd//src/gnu/usr.bin/binutils/doc/inc-hist.diff,v
retrieving revision 1.3
diff -u -r1.3 inc-hist.diff
--- inc-hist.diff 11 Apr 2001 04:27:10 - 1.3
+++ inc-hist.diff 29 Jun 2002 12:20:56 -
-1,7 +1,7
$FreeBSD: src/gnu/usr.bin/binutils/doc/inc-hist.diff,v 1.3 2001/04/11 04:27:10 ache
Exp $
inc-hist.texi.orig Wed Apr 11 08:20:01 2001
-+++ inc-hist.texi Wed Apr 11 08:21:57 2001
+--- inc-hist.texinfo.orig Wed Apr 11 08:20:01 2001
inc-hist.texinfo Wed Apr 11 08:21:57 2001
-26,9 +26,9
node Using History Interactively
chapter Using History Interactively
Index: GDBvn.texi
===
RCS file: /usr/home/cc/ncvs/freebsd//src/contrib/gdb/gdb/doc/GDBvn.texi,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 GDBvn.texi
--- GDBvn.texi 2 May 1999 10:11:49 - 1.1.1.2
+++ GDBvn.texi 29 Jun 2002 12:19:28 -
-1 +1
-@set GDBVN 4.18
+@set GDBVN 5.2.0 (FreeBSD) 20020627
Re: interesting: problem with nm?
On Thu, Jun 27, 2002 at 12:13:39PM -0700, Juli Mallett wrote: If no file is specified for nm to operate on it operates on a.out by default like most other programs that deal with binaries. If a.out does not exist, then you will indeed see that. Thanks for the clarification, I expected it to print a version string (because I was only interested in seeing that it does not die after the pmap fix) but had to find out from the man page, that nm(1) uses -V for that, while all other members of the binutils family opt for -v. Oh well... Consistency in software design rocks. So, problem solved. Thanks to all who responded. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What's the right way to build XFree86-4 now?
Hello Sheldon, On Tue, Jun 25, 2002 at 09:21:57AM +0200, Sheldon Hearn wrote: Hi folks, Could someone put me out of my misery and show me the right way to build XFree86-4 on -current at the moment. I've tried `make install' and `make CXX=/usr/local/bin/g++31 install', where that g++31 comes from the lang/gcc31 port, and either way, XFree86-4-clients fails with: ... This must be glxinfo. This shows btw, that the make World was not successful, therefore the install fails. The problem here, as verified by my build logs, is that glxinfo (really, xc/programs/glxinfo) is built using gcc since it is C, but tries to link against -lGLU, which is C++. Specifying -lstdc++ explicitly on the link line works in this case. Changing the compiler was not trivial here, since the Imake framework generated Makefiles decide on which compiler to use based on the source file suffices, and since here it is .c, they use gcc for both building and linking. The quick way out I found is to hack the Makefile by hand and including the extra lib, but this both ugly and wrong. There is another problem, however, and this is that the libGLU built is parctically unusable anyway, although there the correct compiler is used (g++), one alway needs to link -lstdc++ with it for it to work. I do not know why this is. Other parts of X appear to work ok. As an aside, this is a rather interesting way of building, but both XFree and OpenMotif use it: the build does not stop at build failures so you only notice the problems upon install time when it tries to build the missing pieces again. THerefore, before installing, one should always grep the build logs for all not remade because of errors. Also see xc/programs/Xserver/hw/xfree86/doc/BUILD. Also as an aside, the current way of building the X4 port with its slave port sucks royally. The libs are built no less than 3 times, and the whole shebang is untarred at least as many times, which means that 1 gig is not enough for building it! Let's face it, the X build is like ours: make World was not designed to be used sliced up like this. There should be one full build port for XFree-4 just like there is one for the old X, and the now slave ports should only be there for people who for some reason need them. Duplicated code in the Makefiles certainly does not justify this nightmare that a full build of XFree-4 from ports now is. At least that's my opinion. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries
On Sun, Jun 23, 2002 at 10:02:42PM -0300, Marc G. Fournier wrote: [...] Sun Jun 23 16:05:30 CEST 2002 build of X Window System complete. Here it also worked with the last gcc snapshot. My experiences here are that building X works, installing X dooesn't ... This means building it did not work either. The 'make World' target of the X build is set up so that it ignores build errors and continues on. The only way you can notice the errors is by taping the output to a file and grepping for all not remade because of errors. So, the fact that you could see the above end trailer does not mean that the build was successful. In this case it tries to finish it up at install time, of course failing again, but this time the failure is fatal. It's just a build config thing, if you just use a 'make all' you will see the errors one-by-one. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: binutils doc still broken
On Sat, Jun 22, 2002 at 10:05:38AM -0700, David O'Brien wrote: On Sat, Jun 22, 2002 at 09:59:44AM -0700, Steve Kargl wrote: make: don't know how to make remote.texi. Stop remote.texi does not exist in /usr/src. The obvious fix of removing remote.texi from the Makefile doesn't work because of I just took a larger hammer and just turned off docs. FWIW, I solved the problem by reanimating remote.texi from the Attic, to where it was relegated with the message that it did not make it into GDB 5.0. But of course it needs sorting out. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel panic with suser_cred and rm
Hello everybody, I upgraded to today's -CURRENT and upon reboot with the new kernel, experienced a panic. Since I did not see it reported here yet, here is some info. More available on request, but I do not have a serial console and therefore had to transcribe everything by hand. Also, there was no core dump. (How can I force it?) Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02054bc stack pointer = 0x10:0xceb1db5c frame pointer = 0x10:0xceb1db60 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 48 (rm) kernel: type 12 trap, code= 0 Stopped at suser_cred+0x1c:cmpl $0,0x4(%edx) db trace suser_cred chkiq ufs_inactive ufs_vnoperate vput unlink syscall syscall_with_err_pushed --- syscall (10, FreeBSD ELF, unlink) eip = 0x804af7b, esp = 0xbfbffc7c ebp = 0xbfbffd08 db show locks exclusive sleep mutex Giant r= 0 (0xc03ed260) locked @ ../../../vm/vm_fault.c:202 FreeBSD fonix.adamsfamily.xx 5.0-CURRENT FreeBSD 5.0-CURRENT #46: Sat Jun 15 17:57:46 CEST 2002 [EMAIL PROTECTED]:/usr/home/cc/build/freebsd/src/sys/i386/compile/FONIX i386 dmesg is not available from the failing kernel, but the only could sleep with... messages came from the soundcard driver. The panic happens also in single-user mode, in my case most easily triggered with the use of rm(1). If you need any more info, just ask. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries
On Mon, Jun 10, 2002 at 10:26:36AM -0700, David O'Brien wrote: On Mon, Jun 10, 2002 at 12:15:40PM -0500, Michael D. Harnois wrote: On Mon, 2002-06-10 at 12:13, David O'Brien wrote: On Mon, Jun 10, 2002 at 12:02:41PM -0500, Michael D. Harnois wrote: The libraries build for me without incident. However, anything which tries to link against libGLU generates this error for me: Your current is too old. Please do a fresh build. Since 6:30 last night? You must have NO_CXX or something -- you aren't linking with the C++ support libs for some reason. Sorry David, but I experienced the same thing. No matter if I used the base system c++ compiler, or the latest gcc31 port. The problem is all the more interesting, because X worked for me fine, no matter what compiler I used to build it (with a few patches from the XFree86-4-libraries port) and libGLU is the only part of XFree that is wirtten in C++. If I specify -lstdc++ on the link line of any programs that use libGLU, it works (see xc/programs/glxinfo). My -CURRENT is from Saturday (8th), NO_CXX is *not* set. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: perl wrapper and PATH
On Fri, Jun 07, 2002 at 11:26:18PM -0700, Bill Fenner wrote: I ran use.perl port, and that gave me a working perl for mergemaster. Interestingly, use.perl system didn't give me back the perl wrapper; I'm not sure what I got. Sigh. That script predates the removal of perl from the base system, and was supposed to facilitate the switching between various perl versions. It still has its justification of existence on -STABLE, but on -CURRENT, it does not work well any more. What you got is likely links to nowhere, your perl wrapper binary was clobbered. Bottom line: if at all, it should only be used for use.perl port, for the cases where the wrapper does not work as desired. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries
Hello, For what it's worth, I set out and successfully compiled the latest from the XFree86 CVS with the latest gcc31 snapshot (May 27th). I needed to do the following: - I had to apply the fix that has been mentioned several times on this list to libXThrStub. - I had to fix a typo in one header file under xc/programs/Xserver/PEX5/ddpex/mi/include/miStruct.h in a prperocessor statement - I applied the patch-ioctl from ports/x11/XFree86-4-libraries (alternatively, you could disable the drm part), also I applied the patch-startx from the same place because I wanted consistent behaviour of startx from what I was used to. There was (after these) a bunch of problems that I worked around with hacks: - There was one file, xc/lib/X11/lcUTF8.c which the gcc from ports did not like. It produced an internal compiler error like this: LD_LIBRARY_PATH=../../exports/lib /usr/local/bin/gcc31 -c -ansi -pedantic -Dasm= __asm -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-d eclarations -Wredundant-decls -Wnested-externs -Wundef -pthread -I../.. -I../. ./exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_RE ENTRANT -D_THREAD_SAFE -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI -DMALLOC_0_RETUR NS_NULL -DHAS_SNPRINTF -DLIBX11 -O -pipe -march=pentiumpro lcUTF8.c -o unshared/lcUTF8.o lcUTF8.c: In function `charset_wctocs': lcUTF8.c:582: unrecognizable insn: (insn 251 70 252 (set (reg:CC 17 flags) (compare:CC (mem:QI (reg/v/f:SI 63) [0 S1 A8]) (const_int 128 [0x80]))) -1 (nil) (expr_list:REG_DEAD (reg/v/f:SI 63) (nil))) lcUTF8.c:582: Internal compiler error in extract_insn, at recog.c:2132 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. *** Error code 1 (continuing) (Sorry for cutpaste) However, when I compiled this only one file with the base system gcc, it worked and linked. - In xc/programs/glxinfo/Makefile, I had to manually define the path to the libstdc++.a in /usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/3.1.1/ because otherwise it was not found. (I suspect this is because it uses the gcc31 frontend, not g++31.) After this, I now have a new X that appears to work at first sight. I somehow managed to mess it up though because now it seems to ignore the Xwrapper port although I have it installed and so only works if I make the X server suid root. But it is probably me... Also, stability remains to be seen, since the original reason for upgrading was that 4.2.0 was regularly freezing with my Virge GX2 card, and supposedly some fixes were prepared for this problem... we'll see. This is just an FYI for all having problems with X building now. Note: I did not try the base system compiler for building yet, apart from that quick hack indicated above. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cannot link C++ apps any more (GCC 3.1)
On Wed, May 22, 2002 at 11:16:11AM +0200, Georg-W. Koltermann wrote: Am Di, 2002-05-21 um 21.35 schrieb Szilveszter Adam: Yes, this is correct. THe libraries libstdc++v3 and libsupc++v3 are not built for the system compiler. You can, however, use ports/lang/gcc31. Ok that works. But, since the system compiler does not include a libstdc++ any more, are there any plans on removing the /usr/bin/c++ and /usr/bin/g++ commands? Seems the are not useful any more, and may conflict with a port which installs these commands. This is only transitional. As soon as it will be ready, the libstdc++ libraries will be built also in the base system. Until such time, you can use this workaround. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cannot link C++ apps any more (GCC 3.1)
Hello, On Tue, May 21, 2002 at 02:26:57PM +0200, Georg-W. Koltermann wrote: Hi, I am unable to link C++ apps with a recent -current. It seems I would need a new libstdc++ which was not included. My libstdc++.so is a leftover from the previous cvsup. Yes, this is correct. THe libraries libstdc++v3 and libsupc++v3 are not built for the system compiler. You can, however, use ports/lang/gcc31. It contains a GCC snapshot from 6th May (in comparison, the system compiler comes from 9th May, so no big deal, both are pre-release). This will give you a working C++ compiler. I use it to build Mozilla, and it works. (I even tried letting CC be the system cc and redefining CXX to the ports version and this worked too, Moz is happily chugging along except when X freezes on me, which is unrelated, I have a Virge GX2 card -- known problem with X.) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
new doc under src/share/doc break world
Hello everybody, The newly integrated documents under src/share/doc/psd and usd break the world because they are not really incorporated into the build system. The Makefiles define their own targets, but this way the source files are not found during make world because the build does not cd into the appropriate src directory. As it seems, the docs build just fine if the existing infrastructure in bsd.doc.mk is used. At present, this means in the psd: 01.cacm, 02.implement, 03.iosys, 04.uprog, 06.Clang, 15.yacc, 16.lex, 17.m4 in the usd: 21.troff What needs to be done is really just that the existing infrastructure of bsd.doc.mk should be used and the custom targets be deleted. For 17.m4, the problem is more serious, the sU macro does not seem to exist in the FreeBSD base system just for now, so should be imported first. Just an FYI. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Buglet in src/usr.bin/uuencode/Makefile
Hi everybody, Due to a commit from today, there is a small buglet in src/usr.bin/uuencode/Makefile, a wrong MLINK. This breaks installworld. (Which doesn't seem to be tested a helluvalot these days) Apply this patch: Index: Makefile === RCS file: /usr/home/cc/ncvs/freebsd/src/usr.bin/uuencode/Makefile,v retrieving revision 1.7 diff -u -r1.7 Makefile --- Makefile19 May 2002 11:17:17 - 1.7 +++ Makefile19 May 2002 15:28:18 - @@ -8,6 +8,6 @@ MLINKS=uuencode.1 uudecode.1 \ uuencode.format.5 uuencode.5 \ uuencode.1 b64encode.1 \ - b64decode.1 b64encode.1 + b64encode.1 b64decode.1 .include bsd.prog.mk Also, while I have the mike, I think makewhatis can already be turned back on for the installworld phase, it seemed to work ok when I tested it (the C version). -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Special fx with disklabel(8)?
Hello, I have a -CURRENT from May 5th. I recently bought a new 40 gig IDE disk and proceeded to install it. I went for compatible (as opposed to dangerously dedicated) mode. I first used fdisk to initialize the slice table and create a FreeBSD slice that would take in the whole disk. After that, I proceeded to disklabel the slice thus created. This used to work just fine with a commandline like this: disklabel -B -w -r /dev/ad1s1 auto But now, although the kernel complaints about the disk not having a disklabel stopped, I could not edit the label I supposedly just created, with the command: disklabel -e /dev/ad1s1 After checking with fdisk, it turned out that the slice I created there (which was the first partition in DOS parlance) got deleted, and replaced by a very small (something like 24 megs) slice listed as the fourth primary. In addition, although up till then the kernel detected the disk's size properly on bootup, it got confused and guessed it was bigger than in reality. I deleted and started over, again, fdisk went fine, the slice got created, I could see it with fdisk, it spanned the whole disk, but after the disklabel we were back to square one. When doing it for the third time, I, for the heck of it, tried disklabel -e right after the fdisk -Bi. And, to my great surprise, a disklabel *was* found on the slice, and it was even mostly correct, save for the fact that now it seemed to stick to the erroneous values for c/h/s and size that it snatched out of thin air previously. (Note: The bad values are not necessarily a bug. The BIOS has no opinion on the disk because it is too big for it. When it tries to detect it, the machine just hangs. So, it is set to None in the BIOS setup, which allows the system to boot, but obviously the BIOS hints are not there. Obviously, this is not the only disk in the system, and not even the system disk:-) I am aware of disklabel changes recently, the question is: Was this some sort of expected, or are these special fx only fata morgana on my machine, or...? In other words, has the recommended way of installing a disk in compatible mode into the system changed? Is fdisk somehow supposed to create a disklabel? And, is disklabel expected to mess with the fdisk tabales? (when it is used on a slice, not the whole disk) Any and all hardware details available if needed. Have a nice weekend! -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Special fx with disklabel(8)?
Hello everybody, OK, just in order to clarify before things get out of hand.:-) There is no immediate problem, the drive in question has been installed and works fine. (using it this instant). As for the BIOS part, the mobo could probably use an upgrade, because the BIOS is still from spring of 1998. Award BIOS-en from around that date had a problem that became known, as I learned through research, as the 65536 cyl, or 32GB barrier. The behaviour of the BIOS is very much like it. And yes, this is an Award PnP v4.51PG on a Shuttle Spacewalker HOT-637/P (Intel 440LX chipset. Yes, old:-) I was more curious than anything else: Since I disabled the drive in the BIOS, it was entirely up to FreeBSD to decide what to do. The boot process detected it with 79408/16/63, which is OK. The disklabel however, somehow contained a larger number than the disk's capacity and got the C value wrong. Of course, this was easily fixed with disklabel -e. Indeed, an overflow somewhere might have caused the symptoms. This definitely did not happen on this system, under an earlier -CURRENT and with a then-new 15 gig disk. And no, I do not think 40 gig drives count as very large these days. I am not sure what would have happened, if the BIOS support had been correct to begin with. In fact, I did not even expect that the drive would be found and probed correctly under the present circumstances, in other words, FreeBSD caused a pleasant surprise. I just got a bit worried, since 80 gig disks are quickly becoming commonplace in modern PCs, and I was hoping that dd mode would not be *the* way to use them under FreeBSD:-). And Terry and Poul-Henning, please stop fighting, I am not going to do anything to the system wrt this just now:-) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
savecore.c broken now, breaks world
Hello, src/sbin/savecore.c has been broken today, with the commit of rev 1.59 by Bill Fenner. It appears that a new magic value, KERNELDUMPMAGIC_CLEARED, has been introduced but its value never #define-d in (probably) src/sys/sys/kerneldump.h. This way, the program does not compile. There is only so much one can deduce from the code, it is the author who should know what was intended here. This breaks the world. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Initiate de-orbit burn for malloc.h?
Hello, On Sat, Apr 06, 2002 at 06:51:14PM -0800, Jos Backus wrote: One problem with ports is that configure will cause malloc.h to be used if it exists in /usr/include (net/rsync being the latest example), causing an annoying warning. So why not remove /usr/include/malloc.h, and patch those ports/programs that still use it to use stdlib.h instead? In my opinion this situation only happens on -STABLE right now, since a properly written configure script not just test for the header's existence, but also tries to use it in a small example program. On -STABLE this works (with a warning as you say) but on -CURRENT no longer. So, configure scripts should detect that condition and act accordingly. (And most that I have seen do) With that said, ports are already being patched for this problem (because some hard-code the use of malloc.h) so this should be less of a problem by the time 5.0 hits the streets. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Weird login behaviour
Hello everybody, I upgraded to this morning's (local time) -CURRENT as I usually do on Sundays. Everything works (this far) but there is something weird: When I log in on the console, it says login: which is OK. But when I enter my username, it does not say Password: but rather displays my username in the next line. If I enter the password there, it lets me in. So it works, but there is something wrong here... It looks like this: login: cc cc pass here Copyright (c) 1992-2002 The FreeBSD Project ... Instead of: login: cc Password: pass here Copyright (c) ... Has anyone seen this yet? (I have not played with PAM config, I use the defaults) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Success story - was Re: HEADS UP: OpenSSH 3.1 imported
Hello, On Mon, Mar 18, 2002 at 11:27:48AM -0800, David Wolfskill wrote: I generally try to avoid chattering too much on the lists, but given the eventfulness of the normally-rather-routine -CURRENT build this morning, I thought it would be appropriate to announce a measure of success. Heh. I did my routine build yesterday and so far I can report success too. Needless to say, I do not yet have the new OpenSSH, but I did the Perl upgrade and the rest. (including the splitfs support in the boot2. Now I get interesting output at boot telling me how it looks for components.) And, watch this, I have no problems so far with the new zlib, even the dreaded man ispell works fine for me. In addition, it feels that I am getting increased I/O performance on my ATA disk with a softupdates-less filesystem. Something like: Erasing the /usr/obj/* directory strucutre took about 20 mins before, yesterday it was done in 2 mins? In the next moment I heard the sound of my jaw slamming onto my desk...:-) Keep up the good work! -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
On Sun, Mar 03, 2002 at 09:26:11PM +0100, Poul-Henning Kamp wrote: OK - I thought you had something much more complex in mind after your example: plugging the nuclear reactor into the serial port where you had a a modem plugged in yesterday. No, that was to show why persistence is a bad idea. Fortune(6), anyone?:-) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why isn't PAM_smb available for FreeBSD?
] WWW: http://www.mozilla.org/projects/security/pki/nss/ So, just to clarify for the sake of the archives, the two NSS have not a lot in common. The NSS thing allegedly needed for Samba is only in -CURRENT AFAIK and has no ports. Some people already said earlier that FreeBSD's NSS implementation (see /etc/nsswitch.conf and its man page) leave things to be desired. Look under the archives with nsswitch.conf as your keyword. The other NSS that is the port quoted above, is actually the crypto services library from the Mozilla project (as the www.mozilla.org reference could have made it blindingly obvious:-) which builds on top of NSPR (also in the ports:-) and provides security services to the PSM module of Mozilla/NS6 (the above two acronyms stand for Netscape Portable Runtime and Personal Security Manager, respectively). It could also be used for your own programs, however, provided that the licensing suits you. And yes, acronym overload is rampant:-) probably because namespace pollution is a common problem in programming:-) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Midi driver causes panic a la Driver Mistake...
Hello everybody, While the flamage rages on on cvs-all, I would like to report the second driver that does not pass the recently introduced warning-to-panic test because of driver mistake. It is the Midi driver (device midi and device seq) I have an SB 64 AWE ISA PnP card so I had these devices in my kernel config (GENERIC does not have them so only custom kernels are affected.) Card identified as: sbc0: Creative SB AWE64 at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 pcm0: SB 16 DSP 4.16 on sbc0 midi0 SB Midi interface on sbc0 featuring the following ddb trace: (sorry, transcribed by hand:-( Debugger panic make_dev midiinit mpu_attach mpusbc_attach device_probe_and_attach bus_generic_attach sbc_attach device_probe_and_attach isa_probe_children configure mi_startup begin and the WARNING is: (right after the midi0: line) WARNING: Driver mistake: repeat make_dev (dspr0.0) -CURRENT from today's make world. NB I think midi driver code may have other problems too... it doesn't seem to be heavily maintained these days. (PS Note to self: If this mail appears on the list, that means I have managed to route around my ISP's broken SMTP server.) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The PR db is not for -current problems, right?
Hello, On Sat, Jun 16, 2001 at 02:51:38PM +0200, Jens Schweikhardt wrote: Hello fellow PR drivers, just before I hit more people over the head that have submitted PRs against problems on -current: my understanding is that -current users know what they are doing, especially that they're living on the bleeding edge and that they must be subscribed to current@ where they shall discuss -current-related malfunctions. Right? It was my understanding this far, that is why I always bug this list when something is wrong:-P BTW, why does each and every PR seem to have this line: Submitter-Id: current-users It is what it this field is set to by default. Consider this snippet from my build logs: === gnu/usr.bin/send-pr sed -e 's,@DATADIR@,/etc,g' -e 's/@DEFAULT_RELEASE@/`uname -rsm`/g' -e 's/^SUB MITTER=.*/SUBMITTER=current-users/' /usr/src/gnu/usr.bin/send-pr/send-pr.sh s end-pr (line wrap) As you can see there some sort of customization going on here, otherwise people would have to figure out a whole lot more by themselves. As to why exactly the name current-users has been selected, well... I guess because there used to be the current users of this product (ie those using it at present) and eg past-users. Of course, some installation problems should be reported by future-users by this token:-) Yes it is confusing to some extent but this is the best explanation I could come up with. I think all the BSDs have it set to this value by default. Note that this field does not appear on the web pr form under http://www.freebsd.org/send-pr.html. This is mildly confusing to me. What's the purpose of the Submitter-Id? Another one I don't understand and which is (almost?) always empty: Quarter: Whazzat? No idea... This certainly does not appear on the form nor on the pr-form that the send-pr command itself presents you with. BTW while we are at it, I have thought about this for quite some time: OpenBSD calls their version of send-pr sendbug (and I note that on FreeBSD this name is also a symlink to send-pr at least on -CURRENT). I think that this or some other name would be more appropriate than send-pr ie send Problem Report. Why? Because people then have a hard time understanding why their problem reports (like: I cannot boot) are closed and they are referred to the mailing lists instead. As I see it, our PR system is used more for reporting actual software bugs, so sendbug would be ok. (although sometimes I get the feeling that not even that, PRs should only be filed against bugs that are officially acknowledged to exist after talking to the developer in question, in which case the PR db is more like a filofax but I am getting way off-topic here) I recognize that send-pr is what this piece of software is called and that most users have no problem deciding what to use it for (including myself) but maybe a better name would explain it better to a new user... after all, send-pr *could* be used as a general support tool, but we do not use it for this purpose. Just my HUF 0.02 and the heat... -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Clever! The kernel make that won't die...
Hello, First of all I would like to apologise for my mail yesterday; we had a party here at the dorm and went a bit crzy... corollary is, next time I won't party and email at the same evening, they just don't mix...:-) In my opinion, you are looking for this fix: markm 2001/06/07 01:45:23 PDT Modified files: contrib/libpam/libpam_misc misc_conv.c Log: Fix bug introduced by myself that often resulted in a session having SIGINTR (^C) and SIGSTP (^Z) masked. Reported by: bde, sobomax Submitted by: sobomax Revision ChangesPath 1.5 +9 -10 src/contrib/libpam/libpam_misc/misc_conv.c So, an upgrade should probably fix this. (Note that I have used bash for quite some time as my shell before switching over to tcsh and I never had problems with it with port builds or whatever.) Next time I will try to be more helpful the first time around. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Clever! The kernel make that won't die...
On Thu, Jun 14, 2001 at 12:38:43PM -0700, Matthew Jacob wrote: Heh- is this a bug or a feature? Making a kernel, no -j args, -current, tot tot... what?:-) Hello? Are you still there?:-) oot/kernel make all === 3dfx ^C^C'd it nellie.feral.com === accf_data root mak=== accf_http e nellie.feral.com === agp === aha fg=== amr bash: fg: current: no such job nellie.feral.com === an Well... this seems rather strange... is this several ttys output or just one? That make- takes a licking, but keeps on ticking. Yes, FreeBSD's real mascot is the Energizer Bunny don't you know? It just keeps going and going and going and ... Seriously: no, I have never seen anything like it. And I never use -j for kernel builds either... what is possible is however this: there was some talk about ^C, ^Z and friends being incorrectly masked by the login routine thus making these useless in some cases even after login. (With the original point being that you shouldn't be able to use these while logging in) This is supposed to be fixed now, but maybe you have the buggy version running? Also, the talk was that while bash (and sh?) were affected, tcsh wasn't, and since that's what I use, maybe that's why I never noticed this... What is the date of your current world? -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: msdosfs can't mount Extended partition. Any ideas?
Hello Ache, On Tue, Jun 12, 2001 at 12:08:22PM +0400, Andrey A. Chernov wrote: On Tue, Jun 12, 2001 at 15:25:27 +1000, Bruce Evans wrote: On Tue, 12 Jun 2001, Andrey A. Chernov wrote: I just found that msdosfs can't mount legal Extended partition because required info is few blocks later in that case, not immediately as for Primary partition. Is it known problem, or I am first who notice that? Does anybody have some fix for that? Extended partititons aren't mountable (even under DOS/Windows), since they are just containers for logical drives (and further extended partitions). Just mount the logical drive (slice) that you want. Where is such slice then? I have ad0s1 for FreeBSD, ad0s2 for Primary and ad0s3 for Extended container of logical drive. Real fat32 code started in ad0s3 a bit later, but I don't have a device name to mount it (or I miss something). Well, hm this is even in the FAQ: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/admin.html#MOUNT-DOS (Question 7.8: How do I mount a secondary DOS partition?) In your situation I would try ad0s5 and onwards. If you do not have the device node under /dev, so create it:-) (No worries I have also forgotten how to do such mounts on occasion before:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: msdosfs can't mount Extended partition. Any ideas?
On Tue, Jun 12, 2001 at 01:01:02PM +0400, Andrey A. Chernov wrote: On Tue, Jun 12, 2001 at 10:47:43 +0200, Szilveszter Adam wrote: In your situation I would try ad0s5 and onwards. If you do not have the device node under /dev, so create it:-) (No worries I have also forgotten how to do such mounts on occasion before:-) Thanks, it works. I was confused by 'devfs' this time which not show ad0s5 slice under /dev until it is actualy mounted. Yes, devfs really takes some getting used to in the beginning, at least it has for me:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: world broken (vinum)
Hello Greg and others, Well I cannot find that file (/usr/src/sys/dev/vinum/vinumutil.h) there, it is not there in the cvsweb interface either. However, I can confirm that /usr/src/sys/dev/vinum/vinumhdr.h contains a reference to it. So? -- regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: mutex vm not owned...
Hello Alfred, hello everybody, On Sat, May 19, 2001 at 10:08:25PM -0400, Alfred Perlstein wrote: * Alfred Perlstein [EMAIL PROTECTED] [010519 21:57] wrote: * Szilveszter Adam [EMAIL PROTECTED] [010519 16:53] wrote: Hello everybody, I guess I was just being too happy so it had to get me this time:-) I was building Mozilla when it struck. Today's -CURRENT, kernel world in sync, no softupdates. panic: mutex vm not owned at ../../vm/vm_page.h:328 Debugger(panic) ... Thanks for the traceback, can you apply this patch then try to get your machine to swap? Oh, yeah, thanks for being brave, I've got a lot of other developers telling me they're not upgrading past the vm mutex patch point which is pretty stupid as it's doing to more harm then good without a thorough workout. :( I'm afraid I don' understand this one exactly. Did other developers oppose that you give this patch to me? Why? If they have not yet upgraded, that's fine. I was not asking to solve this problem here and now (although a solution is great:-) I was trying to help narrow it down since appearently I am the one with this problem right now. There is no hurry, this machine is play-box, which normally does nothing important, just a surf terminal. Being able to use X would be nice however, but more on that later:-) So, anyways, thanks for trying to help, I applied the patch nevertheless. I have since discovered a sure-fire method to cause a freeze and reboot, however, and maybe this may shed some light. Unfortunately, the method involves starting X, which makes debugging difficult. As soon as I attempt to start it, the screen enters SVGA mode and turns dark but the X server is never actually started it seems or at least never comes but the whole machine hangs for a couple of secs and then reboots itself. Unfortunately, while in this wedged state, it doesn't seem to be interested in me:-( Note that this effect is not dependent on the patch, but only appeared with yesterday's build, earlier X always worked fine. What effect, if any, the patch will have will show hopefully during the course of the day. Another interesting nit: - It seems that if I power-cycle the machine and start up clean, it can do approx 1-1,5 hours of compiling at which point it will panic like posted. This time the trace was: Debugger panic _mtx_assert swp_pager_async_iodone _iodone bufdone bufdonebio ad_interrupt ata_intr ithread_loop fork_exit fork_trampoline and it did not even attempt to dump, just froze at synching disks I had to reset it. - However, if after this I bring it up in single-user, do a manual fsck, and continue in multi-user, than it could do compiles and more (eg I restarted the Mozilla build after my initial report and hit the hay, and by morning the machine was still up, the compile finished successfully and even the periodic script runs caused apperently no problem.) So this seems rather interesting of a locking issue... however, some other info I did not give: this is an UP system, which may be important. As usual, I am more than happy to provide info, test, etc. BTW this appears to be recent and possibly related to the problem: -snip from kernel build log.--- cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstri ct-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fform at-extensions -ansi -g -nostdinc -I- -I. -I../.. -I../../dev -I../../../include -I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h - elf -mpreferred-stack-boundary=2 ../../ddb/db_watch.c In file included from ../../ddb/db_watch.c:41: ../../vm/vm_map.h: In function `_vm_map_lock_upgrade': ../../vm/vm_map.h:265: warning: implicit declaration of function `mtx_lock' and cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstri ct-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fform at-extensions -ansi -g -nostdinc -I- -I. -I../.. -I../../dev -I../../../include -I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h - elf -mpreferred-stack-boundary=2 ../../kern/link_elf.c In file included from ../../kern/link_elf.c:52: ../../vm/vm_map.h: In function `_vm_map_lock_upgrade': ../../vm/vm_map.h:265: warning: implicit declaration of function `mtx_lock' -end of snippet it also happens in the ibcs2 and fpu modules. Of course this may be pure BS, I am not a kernel hacker, just speculate. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: mutex vm not owned...
Hello, I am back with more information. The machine had been up mostly idle for about 1 1/2 hours again. I am starting to suspect that it is being idle that may also trip the wire here... maybe, given my 128megs of RAM and 300 megs of swap, that's when my computer decides that it's time to swap some stuff and boom. Alfred's patch indeed seems to have changed things a bit: It paniced after 1h37m uptime during a CVS checkout, with the following: panic: sleeping with vm_mtx held trace: Debugger panic msleep swap_pager_getpages vm_fault1 vm_fault trap_pfault trap calltrap ---trap 0xc, eip= 0x2824dc2e, esp=0xbfbfe16c, ebp=0xbfbfe160 then after 'c': syncing disks... panic: mutex vm owned at ../../kern/vfs_bio:2998 nice long trace: Debugger panic _mtx_assert vfs_busy_pages bwrite vfs_bio_awrite spec_fsync spec_vnoperate ffs_sync sync boot panic msleep swap_pager_getpages vm_fault1 vm_fault trap_pfault trap calltrap and again the same trap message like above. After hitting 'c', it freezes at the dumping: resetting devices part. This starts to become interesting... will follow up with more when found. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: mutex vm not owned
On Sun, May 20, 2001 at 01:29:22PM -0700, Dima Dorfman wrote: David Malone [EMAIL PROTECTED] writes: On Sun, May 20, 2001 at 12:59:51PM -0400, Mike Heffner wrote: The machine is up for about one minute and then I ran `startx' and the screen turned black and it appeared to lockup, after about 30 seconds plus some banging on the keyboard it rebooted. I have 256mb ram, so it shouldn't be swapping at this point. The kernel and world are cvsupd to about 12am May 20 EDT, the following is the panic message: I'm getting a panic whenever I start X too (with a kernel from earlier today). I managed to get a DDB trace from a serial console. Please try the attached patch. I make no claims of its correctness, but this e-mail is coming to you via X on -current updated a few hours ago so it works here :-). OK, I've just tried this and would like to report that it works. Of course, using X without swapping is not practically possible:-) but as a demonstration it's all right. Now I hope the other problems with swapping can also be sorted out. I have sent Alfred some traces, unfortunately this is about all, dumping is not possible... let's hope for the best. Luckily, console based CD players also exist.grin -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: mutex vm not owned...
Hello everybody, I guess I was just being too happy so it had to get me this time:-) I was building Mozilla when it struck. Today's -CURRENT, kernel world in sync, no softupdates. panic: mutex vm not owned at ../../vm/vm_page.h:328 Debugger(panic) Stopped at Debugger trace: Debugger panic _mtx_assert swp_pager_async_iodone _iodone bufdone bufdonebio ad_interrupt ata_intr fork_exit fork_trampoline Unfortunately, dumping still doesn't work, I get the old and familiar: dump ata0: resetting devices... panic: witness_restore: lock (sleep mutex) Giant not locked. So there is no crash dump. Ideas? -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic during -CURRENT buildworld
Hello everybody, attention! pure speculation and unprofessional comments follow! These problems with the alternate superblock remind me... there were reports about the same when fsck had problems some time ago. But there was a common theme to all of them: The fsck raves were a whole lot more severe if there were softupdates enabled. I for example have been running -CURRENT for quite a while here on a daily basis (although I have never tried to use the same file systems concurrently with -STABLE) doing buildowrlds, Mozilla bi-daily builds and other fun stuff, yet have not seen any problems of this kind. Even when I had a crash, a manual fsck (for safety's sake) always fixed things as it should, and never complained. And this, although I had some very unfortunate crashes, when eg I crashed from X in the middle of a Mozilla build, but even so there were almost no file structures damaged or at least not noted by fsck. But I have never enabled soft updates on any fs of mine, which of course means that some operations require all the time in the world to complete, but seems it is safer somehow. I am probably just lucky and totally wrong, but just speculating... -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src Makefile.inc1
On Wed, May 16, 2001 at 06:47:12PM +1000, Bruce Evans wrote:
On Tue, 15 May 2001, Ruslan Ermilov wrote:
On Tue, May 15, 2001 at 05:42:04PM +0300, Peter Pentchev wrote:
[...]
Can't you teach sysinstall/Makefile to use the kbdcontrol in
${.OBJDIR}/../kbdcontrol/kbdcontrol instead, and make it somehow
depend on kbdcontrol being built beforehand?
Doing it this way would break cross-platform builds.
Even running kbdcontrol might break cross-platform builds. Consider
running it on a host platform of Linux. It might fail attempting to
do a keyboard ioctl in its initalization. However, kbdcontrol -L
might work because it doesn't actually do any keyboard control.
I think that cross-platform means compilation between i386 and alpha (and
possibly others) not different OS's:-) (Although admittedly you can build
Debian CDs on FreeBSD with linux emulation way better than you can build
say a -STABLE release on a -CURRENT box... )
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Cross-platform make world/release?
On Wed, May 16, 2001 at 08:52:44AM -0700, Eugene M. Kim wrote: Greetings, Short question: is FreeBSD capable of cross-platform make world and release (e.g. build of Alpha world/release on x86 and vice versa)? Hello, Cross-platform world should work rather easily. (have not tried it since I don't have an Alpha lying around here:-P) See in particular the Makefiles right under src/ there is a good explanation on top in comments of what vars you can set and what they do. As for release, well that's tricky. In theory it should work also but in praxis the study of src/release/Makefile has proven to be some pain at times... note that I have not tried this one either... what I *did* try was however to build 4.3-RELEASE on a -CURRENT box (same platform) and to my great dismay I had to discover that even after loading the bin distribution from the ftp into the release chroot(2), it took heavy amounts of tinkering to get things going... the make world succeeded though, so I assume that most anything would have gone well from that point... in any case, if you want to do a release, study the Makefiles closely and understand what they do. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Huh??!? xterm: Error 14, errno 2: No such file or directory
On Tue, May 15, 2001 at 01:34:27AM -0700, Peter Wemm wrote: David Wolfskill wrote: Built -CURRENT rebooted after mergemaster as usual, and some X applications (xbattbar; xlockmore; oclock) work OK, but no xterm. At least, not from X (XF86-4.0.3). I tried using Ctl-Alt-F2 to get to a non-X login, logged in , set DISPLAY to m147:0.0, issued xterm , and got an xterm OK. Known problem. phk changed the semantics of /dev/tty in the most recent commits. Traditional behavior for a process *without* a controlling tty when it opens /dev/tty is to get ENXIO. I am confused now. I have just finished building and installing world and kernel from top-of-the-tree sources: FreeBSD fonix.hos.u-szeged.hu 5.0-CURRENT FreeBSD 5.0-CURRENT #42: Tue May 15 18 :32:49 CEST 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/FONIX i386 and I am (for the first time ever) a proud owner of a devfs-powered FreeBSD system. So far things are looking A-OK. Having read about all the trouble people were having with xterms, I grew a bit anxious and fired up X. It crashed because the config file contained /dev/mouse and that node no longer exists, but of course correcting it to /dev/sysmouse made things work. Then... I proceeded to open an xterm... and it opened! Just right-clicked the root window and chose xterm form the popup menu and it worked without any patch... although I am confident I do have the latest of phk-s commits and I am running on a new kernel... I am using XFree-3.3.6 and olvwm if that at all counts... of course I am happy to see no problems but why are others seeing them? -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Huh??!? xterm: Error 14, errno 2: No such file or directory
On Tue, May 15, 2001 at 06:32:16PM +0100, Brian Somers wrote: Have you got v1.23 of sys/fs/devfs/devfs_vnops.c and are you running as non-root ? Yes: ident /usr/src/sys/fs/devfs/devfs_vnops.c /usr/src/sys/fs/devfs/devfs_vnops.c: $FreeBSD: src/sys/fs/devfs/devfs_vnops.c,v 1.23 2001/05/14 08:20:46 phk Exp $ and, uhm, yes:-) But as David pointed out, it may make a difference if you use startx/xinit or xdm. I did not think of that because I never use xdm. So, clarfying things a bit, I am running as non-root but using startx, as I always have. BTW David, you can use startx too with XFree4 if you want just install the wrapper script from /usr/ports/x11/wrapper. I did this on a friend's machine and it works:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ssh public key auth. incompatible between 2.3.0 vs. 2.9?
Hello David, On Sat, May 12, 2001 at 10:40:35PM -0700, David Wolfskill wrote: OK; there's something about the (relatively) new ssh (2.9) in -CURRENT I'm not understanding. I have hunted around for some clues (via man pages the like), but it could well be that I'm still failing to notice something -- quite possibly something that should be obvious to even me -- and I welcome a clue. I am working on reproducing this, so I would like to ask for clarification... Unless I am mistaken, you have 3.2-RELEASE on the machine that you are connecting to with ssh2 port installed. Right? And you are trying to use RSA Auth using ssh1 on purpose although both sides could use ssh2 in theory. And you are seeing that -CURRENT's ssh does not fall back to RSA key auth when it cannot use DSA. But you have already used ssh2 to this host before. (Because it is contained in the known_hosts2 file). Maybe this confuses ssh. In my setup, I have only one server that can do SSH2 (mine, the -CURRENT box) all others are unable, because they use either older versions of OpenSSH or the ssh1 from SSH Communications. But I have absolutely no problem in connecting between them with RSA keys... although I have just tried (almost) all combinations.:-) Even the -CURRENT server does well, although ssh2 is the first option tried in the server config because some windoze clients can do ssh2 already so why not use it? But admittedly I have not tried RSA auth between two ssh2 capable hosts... will need the help of a collegaue with it. (who will kindly reboot the machine on the other end into FreeBSD-STABLE:-) Note that I do not have a known_hosts2 or an authorized_keys2 file anywhere. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Today's special: nessusd panics -CURRENT
Hello everybody, I have stumbled across some nice giraffe today. Look, this is cute (transcribed by hand for your enhanced viewing pleasure): (sorry, no serial console handy... should be easy to reproduce though) # nessusd -D witness_get: witness exhausted exclusive(sleep mutex) Giant(0xc044a760) locked @ ../../i386/i386/trap.c:1169 panic: system call open returning with mutex(s) held Debugger(panic) Stoppped at Debugger+0x45: pushl: %ebx db trace Debugger panic syscall syscall_with_err_pushed db OK, so let's see what's next. db c syncing disks... 17 17 panic: witness_restore: lock(sleep mutex) Giant not locked Debugger(panic) Stopped at Debugger+0x45: pushl: %ebx db Hmmm... this is not right. What now? db trace Debugger panic witness_restore msleep buf_daemon fork_exit fork_trampoline db Well if that doesn't work, let's at least try to dump: db c dumping to dev #ad/0x20001, offset 352256 dump ata0: resetting devices... panic: witness_save: lock(sleep mutex) Giant not locked Debugger(panic) Stopped at Debugger+0x45: pushl: %ebx db No, bad Szilveszter, no crash dumps for you today. Well OK, let's see: db trace Debugger panic witness_save mawait ata_command ad_reinit ata_reinit addump dumpsys boot panic witness_restore msleep buf_daemon fork_exit fork_trampoline db c Dump already in progress, bailing... Automatic reboot in 15 sec etc. (And of course no dump) So? Opinions? things to try? -CURRENT is from yesterday, kernel and world in sync, machine UP PII-233. Nessus is from ports and has been extra recompiled after the make world. I will try anything if needed or test any patches... Thank you for your time... -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Today's special: nessusd panics -CURRENT
On Thu, May 10, 2001 at 11:29:57AM -0700, David Wolfskill wrote: Ok, I see what's broken. I don't know how you are out of witness's though. We don't have enough types of mutexes for that to happen. Try this patch: ... Since I didn't use the -l flag to patch, it didn't apply, so I did it by hand (and subsequently thought to check for whitespace issues). Yes same with me:-) But the patch appears to work; I'm up running: Well unfortunately no such luck. It solves the first part of the problem (the system call open retunrning with nutex(s) held panic) but even after applying the patch and toning down MAXUSERS to 32 (I suspected it might be somewhat related) I still get the triple panic, which now looks like: witness_get: witness exhausted panic: witness_restore: lock (sleep mutex) Giant not locked After 'c', it says (attempting to sync the disks) witness_save: panic: lock (sleep mutex) Giant not locked And finally after attempting to dump: ata0: resetting devices: panic: lock (sleep mutex) Giant not locked Here come the traces. The third trace also contains the first and the second a bit further down. The third trace: Debugger panic witness_save mawait ata_command ad_reinit ata_reinit addump dumpsys boot panic= From here is part of the second trace too. witness_save boot panic= From here this is the first trace too. witness_restore msleep vm_pageout fork_exit fork_trampoline So basically the first trace is: Debugger panic witness_restore msleep vm_pageout fork_exit fork_trampoline And the second: Debugger panic witness_save boot panic witness_restore msleep vm_pageout fork_exit fork_trampoline This problem *only* appears when running nessusd. Any other app I tried (including X) runs fine. If you need more info let me know. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pgm to kill 4.3 via vm
On Mon, May 07, 2001 at 07:02:32PM +0200, Dag-Erling Smorgrav wrote: Matt Dillon [EMAIL PROTECTED] writes: This argument rears its head about once a year and usually turns into a huge flame war. Yes, I was going to mention that - search the archives for memory overcommit and you'll find most of what I've already said in this thread, and plenty I haven't. A Top UNIX Myths page anyone? Along the lines of: I have heard UNIX is the most secure OS! - No, unless you make it so and bring up the necessary expertise and time investment... I have heard you cannot crash a UNIX machine! - No, ... It would serve those people well who were only educated about UNIX-type systems during MS vs anything else flamewars... -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Make world's stoping perl
On Sun, May 06, 2001 at 07:09:01AM -0700, Edwin L. Culp wrote: For a couple of days now my make worlds on all my machines are stopping with the following error. I haven't seen anything on the list about anyone else having a problem. syntax error at lib/SelfLoader.pm line 69, at EOF Compilation failed in require at /usr/libdata/perl/BSDPAN/BSDPAN/Override.pm line 17. Compilation failed in require at /usr/libdata/perl/BSDPAN/Config.pm line 37. BEGIN failed--compilation aborted at /usr/libdata/perl/BSDPAN/Config.pm line 37.Compilation failed in require at /usr/src/gnu/usr.bin/perl/perl/../../../../contrib/perl5/configpm line 430. *** Error code 255 Hello, You need the patch from the message: [EMAIL PROTECTED] by markm. Apply it to the /usr/libdata/perl/BSDPAN dir. Not to the sources, the installed version, because it is faulty. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sound driver breakage/megapatch
Hello, When was this megapatch? I have a kernel world from evening of 18th CEST, and my SB 64 AWE rocks as usual. I even figured out, how to play Shoutcast streams with mpg123 which enabled me to listen to my favourite radio on the console:-) Doing it right now:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Failed to load linux.ko during boot
On Tue, Apr 10, 2001 at 10:05:27AM +0300, Sakari Jalovaara wrote: I was wondering about this too. /etc/rc does this: if ! kldstat -v | grep -E 'linux(aout|elf)' /dev/null; then kldload linux /dev/null 21 fi ... I believe this has been fixed yesterday. (The shell that is) Try to upgrade and see if it goes away:-) Good luck! -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fstab weirdness / UPDATING
Hello everybody, I am sorry to report that the fix committed to preen.c by phk recently did not fix the problem for me entirely. I have: ad0 with partitions within s1 a through h (ad0s1a-ad0s1h) and ad1s1a. Upon rebooting (after a clean shutdown) with an up-to-date kernel and userland, all the partitons on ad0 were checked, but the ad1 was not. Yet, it was mounted r/w afterwards. I did not yet test in single-user mode though what if I say 'fsck -p'... -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fstab weirdness / UPDATING
Hello, On Sat, Apr 07, 2001 at 12:04:07PM -0700, David Wolfskill wrote: I suggest "fsck -d -p" -- the debugging output could prove useful. Here we go: pass1 pass1, name /dev/ad0s1a pass2 pass2, name /dev/ad0s1f pass2, name /dev/ad0s1g pass2, name /dev/ad0s1h pass2, name /dev/ad0s1d pass2, name /dev/ad0s1e Parallel start disk /dev/ad0: ad0s1f, ad0s1g, ad0s1h, ad0s1d, ad0s1e start /tmp nowait fsck_ufs -p /dev/ad0s1f Parallel wait done ufs: /dev/ad0s1f (/tmp) 0x0 start /usr nowait fsck_ufs -p /dev/ad0s1g Parallel wait done ufs: /dev/ad0s1g (/usr) 0x0 start /usr/local nowait fsck_ufs -p /dev/ad0s1h Parallel wait done ufs: /dev/ad0s1h (/usr/local) 0x0 start /var nowait fsck_ufs -p /dev/ad0s1d Parallel wait done ufs: /dev/ad0s1d (/var) 0x0 start /var/log nowait fsck_ufs -p /dev/ad0s1e Parallel wait done ufs: /dev/ad0s1e (/var/log) 0x0 Parallel end In other words, nothing unusual, apart from the fact that ad1 is not even mentioned. If I after this say 'fsck -d -p /dev/ad1s1a', it says: start /dev/ad1s1a wait fsck_ufs -p /dev/ad1s1a and then exits, seemingly succesfully. Nothin more... if there is anything I can be helpful with, please tell me. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fstab weirdness / UPDATING *solved!*
Hello guys, [Cc-ing the list just for the sake of the archives, so that people could see what the resolution of the case was.] Thanks for trying to help me while I was busy sleeping... here I am again. As suggested, I looked at my fstab, although I do not remember fiddling with it in a long time. (In fact, the last time was when I installed my second disk into the system some time at the end of last year.) And sure as hell, there it was: next to /dev/ad1s1a there was *no* dump number and *no* pass no. Not zeros, but nothing, nada, nichts. This, of course, explains a lot of things... after putting the correct values in there, fsck worked. But I have no idea how/why the numbers got deleted... and then why it worked before? Thanks all the same, things seem to work out A OK right now. :-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fstab weirdness / UPDATING
Hello, On Wed, Apr 04, 2001 at 10:49:22PM -0700, Alfred Perlstein wrote: I've had that problem on one box also -- when the boot occurs, my /var partition is not fsck'd. It's the second pass-two file system, which means that it *should* be checked :-). I suspect a nit in the recent fsck cleanup, so I'm CC'ing phk, whose mailbox is obviously too empty. I think I'm seeing the same thins... At boot I see a kernel printf "warning: /var was not properly dismounted" then /var mounts. If I unmount it and fsck it it's dirty. I saw something similar too, but did not get around to posting yet because I wanted to understand what's going on. On boot, I see only two of my partitions being reported as clean, and not the others. After this, all of them are mounted allright. (They happen to be ad0s1a and ad0s1f don't know why...) I don't know if it causes filesystem corruption, because it is my policy to always 'boot -s' upon unclean shutdown and fsck all partitions manually. (In fact I just did it again because X has a tendency to freeze the machine off and on for unknown reasons... maybe related?) If this is an fsck problem, then I figured there was no big problem if your previous shutdown was clean... am I right? Or maybe there is a problem with shutdown too that fsck simply doesn't notice? Brrr...:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: page fault in mpu.c
On Mon, Mar 26, 2001 at 09:42:34PM -0500, Jim Bloom wrote: I finally tracked down the page fault I was seeing while probing the mpu. The mutex was not being initialized before it was used. I have included a patch below which fixes the problem. Will someone please review the style and commit the fix. I can confirm that this fixes the problem (as in the kernel builds and boots with options midi and sequencer.) Thanks! -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: midi causes panic on boot? (update)
Hello Jim, On Sun, Mar 25, 2001 at 07:20:04PM -0500, Jim Bloom wrote: I get a slightly different backtrace, but was able to use my palm pilot as the serial console. I have had this same problem for quit a while (about a month). I suspect a locking issue related to Seigo Tanimura's commit on Feb 25. My last cvsup was within the past 24 hours and the kernel was built in a clean directory. Yes, same experience here. But I unfortunately did not have a serial console handy. Tanimura's commits on March 14th were supposed to help the situation, but they appearently haven't...:-( I can try to get more information if necessary. I am still trying to figure out how to get more. I am not good with ddb, and since the machine will not dump, gdb is not usable locally. (And again, no serial connection handy:-( 'show witness' and 'show mutex' come to mind as two more things I will try in ddb. trace _mtx_lock_sleep(c0ecda08,0,c036d471,268) at _mtx_lock_sleep+0x29a mpu_uartmode(c0ecda00) at mpu_uartmode+0x63 mpu_attach(c0ebd100,c0ebd100,c0ebd100,c0e67080,c04e675c) at mpu_attach+0x25 mpusbc_attach(c0ebd100,c0ebd100,c0ea5ac0,c036e926,1) at mpusbc_attach+0x19 device_probe_and_attach(c0ebd100) at device_probe_and_attach+0x9a bus_generic_attach(c0ea2000,c0ebd080,c0ea5ac0,c0ea2000,c036e935) at bus_generic_attach+0x16 sbc_attach(c0ea2000,c0eadb00,c0ea2000,7,0) at sbc_attach+0x3cc device_probe_and_attach(c0ea2000,c0404c4c,c03f9030,4eb000,c0eadb00) at device_probe_and_attach+0x9a isa_probe_children(c0ea2980,c04e6ff8,c01b1f74,0,4e4c00) at isa_probe_children+0x143 configure(0,4e4c00,4e4000,0,c01277d2) at configure+0x39 mi_startup() at mi_startup+0x68 begin() at begin+0x29 Yes, I think we are looking at the same thing. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: midi causes panic on boot? (update)
Hello folks, I have tried it with today's -CURRENT, and as soon as I try to boot a kernel with the options (this has occured also earlier but wanted to make sure that I try today's sources first) device midi device seq (my sound card is a ISAPnP SB 64 AWE) I use device sbc too. the kernel still panics with Fatal Trap 12. I have Seigo Tanimura's fixes, and yet this still happens. I do not have a serial console, so here a short trace output transcribed: _mtx_lock_sleep mpu_uartmode mpu_attach mprobe_attach device_probe_and_attach bus_generic_attach sbc_attach device_probe_and_attach isa_probe_children configure mi_startup() begin() At the point of panic not even the swap partition is available yet so the machine does not dump. How can I force it? I would like to offer any and all help to anyone wanting to debug this; I can reproduce the problem at will and luckily no FS corruption occurs because the panic is so early on boot.:-) Of course, as soon as I omit the midi part, the kernel boots fine, and the sound card works too. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
midi causes panic on boot? + entropy gatherer works fine
Hello everybody, I had been away for two weeks and after upgrading to the latest -CURRENT I noticed that leaving device midi (and maybe device seq, I did not test separately) in my kernel config file causes a Trap 12 with interrupts disabled on _mtx_lock_sleep+0x29a: movl 0x1a0(%edx),%eax quite early on boot. Dumping was not possible, my attempts at this were only honoured with a reboot. Although I never tested if the midi support actually does something but up until now I always had it in the kernel and it never caused problems. I wonder if this is known? If not, I can certainly provide more information. The offending sound hw is a Creative SB 64 AWE ISAPnP card. It works fine otherwise. (as it always has) BTW: the new entropy gatherer really works nice for me. Even with the usual set of debugging options, I did not notice any slowdown, more, I think the computer has become more responsive than it has been lately. Congrats to Mark and all, I just did not want to send an email separately for this!:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: as segfaulting during world-build
On Tue, Feb 20, 2001 at 11:27:17AM -0500, Mikhail Teterin wrote: No, I don't think it is hardware. It died on the same spot for the third time in a row: ... What date is the -CURRENT you are attempting the build on from? There were problems with as failing for a while not long ago. Check your version of src/lib/libc/stdio/findfp.c (the installed one...) to see if it is revision 1.15 or later. If not, you will have to get a working as (and as reported by Martin Blapp, the other binutiles in /usr/bin/ and /usr/libexec/elf too) from somwhere like an ftp snapshot... if this is not the problem, I dunno, I did not have any such problems even though I have just finished a buildworld... -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New GCC changes broken
On Sat, Feb 17, 2001 at 01:54:29PM +0100, Martin Blapp wrote: Do people test their changes ? warning: passing arg 1 of `unshare_all_rtl' from incompatible pointer type ... /usr/current/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc.295/toplev .c:3828: too few arguments to function `unshare_all_rtl' *** Error code 1 GCC 2.95.3 RC 3 is in the process of being integrated into the tree. I have not yet seen an all-clear signal from David O' on this. You should read your cvs-all mail and wait for the changes to finish first. (or try it with sources from before the upgrade.) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New GCC changes broken
On Sat, Feb 17, 2001 at 02:09:39PM +0100, Szilveszter Adam wrote: On Sat, Feb 17, 2001 at 01:54:29PM +0100, Martin Blapp wrote: Do people test their changes ? warning: passing arg 1 of `unshare_all_rtl' from incompatible pointer type ... /usr/current/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc.295/toplev .c:3828: too few arguments to function `unshare_all_rtl' *** Error code 1 GCC 2.95.3 RC 3 is in the process of being integrated into the tree. I have not yet seen an all-clear signal from David O' on this. You should read your cvs-all mail and wait for the changes to finish first. (or try it with sources from before the upgrade.) BTW, if you want the latest from everything except gcc, David even layed a tag on the sources just before the import: BEFORE_GCC_2_95_3_TEST3 you may want to use it. Good luck! -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New GCC changes broken
On Sat, Feb 17, 2001 at 02:32:49PM +0100, Martin Blapp wrote: On another box CURRENT, updated this morning: cc -I/usr/src/lib/csu/i386-elf/../common -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/csu/i386-elf/crti.S -o crti.o cc: Internal compiler error: program as got fatal signal 11 as(1) does crash, rebuilding as does not help, neither does rebuilding gcc, I cannot compile and .S files. Do you have ver 1.15 of src/lib/libc/stdio/findfp.c, committed by imp? revision 1.15 date: 2001/02/16 21:09:49; author: imp; state: Exp; lines: +15 -4 Extra needs to be initialized for our usual pool of FILEs. This was causing some versions of as to dump core. This survived make buildworld/installworld and the building gettext port afterwards. Submitted by: [EMAIL PROTECTED] "N.Dudorov" Reviewed by: "Daniel M. Eischen" [EMAIL PROTECTED] If not, that may be the problem... but I do not know of a good solution other than grabbing a known good as (or also libc) from somewhere, like a snapshot on ftp... -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New GCC changes broken
On Sat, Feb 17, 2001 at 04:33:51PM +0100, Martin Blapp wrote: Did that, replaced /usr/libexec/elf/as with new one, now I have: cc -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include -D__DBINTERFACE_PRIVATE -DINET6 -I/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DPORTMAP -DYP -DHESIOD -I/usr/src/lib/libc/i386 -c read.S -o read.o ld: unrecognized option `-x' Oh my dear... maybe you'll have to replace libc too... I have just finished the upgrade (so far no problems) even my old (as in: before Feb 10) apps work again as a result of the libc major downgrade. But I may have been "lucky" because I have a slow machine, it takes about 6 hours to complete an upgrade on it, so these sources are as of about 10am today your (and mine) time... which looks like a good time to go back to. If you can link programs now, I suggest you checkout sources as of today 10am CET and try building it again. It at least worked for me (although I should have removed the WITNESS_DDB option since it now features random drops to ddb with lock order reversal errors, from where you can always continue...) I have now: FreeBSD fonix.hos.u-szeged.hu 5.0-CURRENT FreeBSD 5.0-CURRENT #8: Sat Feb 17 16: 09:13 CET 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/FONIX i386 Wish you best of luck! -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Hungarian locale completed
Hello everybody!
Today I upgraded my system to the latest -CURRENT and in the process also
completed the Hungarian locale support.
Please find enclosed the small tar.gz archive with the necessary files in
src/share/{msgdef|monetdef|numericdef} and if you see fit, commit them.
Good speed!
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
hungarian.tar.gz
Re: Hungarian locale completed
On Sat, Feb 17, 2001 at 05:07:06PM +0100, Szilveszter Adam wrote:
Hello everybody!
Today I upgraded my system to the latest -CURRENT and in the process also
completed the Hungarian locale support.
Please find enclosed the small tar.gz archive with the necessary files in
src/share/{msgdef|monetdef|numericdef} and if you see fit, commit them.
Where, of course, I couldn't be bothered to send the Makefile diffs
along... doh!:-)
Here they are...
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
Index: Makefile
===
RCS file: /usr/local/ncvs/freebsd//src/share/monetdef/Makefile,v
retrieving revision 1.17
diff -u -r1.17 Makefile
--- Makefile2001/02/17 08:28:26 1.17
+++ Makefile2001/02/17 08:15:40
@@ -1,4 +1,4 @@
-# $FreeBSD: src/share/monetdef/Makefile,v 1.17 2001/02/17 08:28:26 ache Exp $
+# $FreeBSD: src/share/monetdef/Makefile,v 1.16 2001/02/11 16:19:41 knu Exp $
NOMAN=YES
CLEANFILES+= ${LOCALES:S/$/.out/g}
@@ -16,13 +16,13 @@
fi_FI.ISO_8859-1 \
fr_FR.ISO_8859-1 \
fr_CA.ISO_8859-1 \
+ hu_HU.ISO_8859-2 \
is_IS.ISO_8859-1 \
nl_NL.ISO_8859-1 \
no_NO.ISO_8859-1 \
pl_PL.ISO_8859-2 \
ru_RU.KOI8-R \
sv_SE.ISO_8859-1 \
- uk_UA.KOI8-U \
ko_KR.EUC \
ja_JP.EUC
Index: Makefile
===
RCS file: /usr/local/ncvs/freebsd//src/share/msgdef/Makefile,v
retrieving revision 1.17
diff -u -r1.17 Makefile
--- Makefile2001/02/17 08:31:31 1.17
+++ Makefile2001/02/17 08:13:36
@@ -1,4 +1,4 @@
-# $FreeBSD: src/share/msgdef/Makefile,v 1.17 2001/02/17 08:31:31 ache Exp $
+# $FreeBSD: src/share/msgdef/Makefile,v 1.16 2001/02/11 16:19:42 knu Exp $
NOMAN=YES
CLEANFILES+= ${LOCALES:S/$/.out/g}
@@ -11,13 +11,13 @@
en_US.ISO_8859-1 \
fi_FI.ISO_8859-1 \
fr_FR.ISO_8859-1 \
+ hu_HU.ISO_8859-2 \
is_IS.ISO_8859-1 \
nl_NL.ISO_8859-1 \
no_NO.ISO_8859-1 \
pl_PL.ISO_8859-2 \
ru_RU.KOI8-R \
sv_SE.ISO_8859-1 \
- uk_UA.KOI8-U \
ko_KR.EUC \
ja_JP.EUC
Index: Makefile
===
RCS file: /usr/local/ncvs/freebsd//src/share/numericdef/Makefile,v
retrieving revision 1.18
diff -u -r1.18 Makefile
--- Makefile2001/02/17 08:35:14 1.18
+++ Makefile2001/02/17 08:11:57
@@ -1,4 +1,4 @@
-# $FreeBSD: src/share/numericdef/Makefile,v 1.18 2001/02/17 08:35:14 ache Exp $
+# $FreeBSD: src/share/numericdef/Makefile,v 1.17 2001/02/11 16:19:43 knu Exp $
NOMAN=YES
CLEANFILES+= ${LOCALES:S/$/.out/g}
@@ -11,13 +11,13 @@
en_US.ISO_8859-1 \
fi_FI.ISO_8859-1 \
fr_FR.ISO_8859-1 \
+ hu_HU.ISO_8859-2 \
is_IS.ISO_8859-1 \
nl_NL.ISO_8859-1 \
no_NO.ISO_8859-1 \
pl_PL.ISO_8859-2 \
ru_RU.KOI8-R \
sv_SE.ISO_8859-1 \
- uk_UA.KOI8-U \
ko_KR.EUC \
ja_JP.EUC
Re: Hungarian locale completed
On Sat, Feb 17, 2001 at 05:24:29PM +0100, Szilveszter Adam wrote: Where, of course, I couldn't be bothered to send the Makefile diffs along... doh!:-) Here they are... ... Please, ignore the previous junk... sigh. I should know better than synching my CVS repo *after* building and *before* generating the diffs. Slowly I will learn... in the meantime, the (for a change, correct) diffs: -- Regards: Szilveszter ADAM Szeged University Szeged Hungary Index: Makefile === RCS file: /usr/local/ncvs/freebsd//src/share/monetdef/Makefile,v retrieving revision 1.17 diff -u -r1.17 Makefile --- Makefile2001/02/17 08:28:26 1.17 +++ Makefile2001/02/17 16:31:26 @@ -16,6 +16,7 @@ fi_FI.ISO_8859-1 \ fr_FR.ISO_8859-1 \ fr_CA.ISO_8859-1 \ + hu_HU.ISO_8859-2 \ is_IS.ISO_8859-1 \ nl_NL.ISO_8859-1 \ no_NO.ISO_8859-1 \ Index: Makefile === RCS file: /usr/local/ncvs/freebsd//src/share/msgdef/Makefile,v retrieving revision 1.17 diff -u -r1.17 Makefile --- Makefile2001/02/17 08:31:31 1.17 +++ Makefile2001/02/17 16:29:54 @@ -11,6 +11,7 @@ en_US.ISO_8859-1 \ fi_FI.ISO_8859-1 \ fr_FR.ISO_8859-1 \ + hu_HU.ISO_8859-2 \ is_IS.ISO_8859-1 \ nl_NL.ISO_8859-1 \ no_NO.ISO_8859-1 \ Index: Makefile === RCS file: /usr/local/ncvs/freebsd//src/share/numericdef/Makefile,v retrieving revision 1.18 diff -u -r1.18 Makefile --- Makefile2001/02/17 08:35:14 1.18 +++ Makefile2001/02/17 16:31:01 @@ -11,6 +11,7 @@ en_US.ISO_8859-1 \ fi_FI.ISO_8859-1 \ fr_FR.ISO_8859-1 \ + hu_HU.ISO_8859-2 \ is_IS.ISO_8859-1 \ nl_NL.ISO_8859-1 \ no_NO.ISO_8859-1 \
