Re: How can I translate IP to hostname in C
Bjoern A. Zeeb wrote: John Timony wrote: I am writing a c program in FreeBSD,and I can not translate a ip to hostname ,i wonder if there is a function to take this job... You mean like gethostbyaddr()? gethostbyaddr() is considered obsolete, I think. You should use getaddrinfo() instead, which is more flexible and easier to use, and it enables you to easily write code that is independent and agnostic of the address family (IPv4 vs. IPv6 vs. others). The manual page contains detailed example code. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd The most important decision in [programming] language design concerns what is to be left out. -- Niklaus Wirth ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libz.so no found
On Fri, 23 May 2008, KAYVEN RIESE wrote: okay, so I don't have a shortcut key for freeBSD-hacker.. I went into my freeBSD saved box, grabbed the first email, replied to all, deleted everything including the subject, and despite having revised the subject, your sooperphreekiness found out I was muddling around in the deally bobber? Is that what you are talking about then? So in the future, I should know that editing the subject line will not suffice to make a new thread? If so, sorry. I get it now. Your mail client sets the In-Reply-To header to the message ID of the email you pulled out of your saved folder. Mail clients use this header to track what thread a message is in (even if someone changed the subject). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
/usr/src/Makefile instructions
My professor told me about instructions being in /usr/src/Makefile for rebuilding my world. I feel better about following them because they are close to the command line to me and can't be out of date, right? I am looking at this list of makes: # check-old - List obsolete directories/files/libraries. # check-old-dirs - List obsolete directories. # check-old-files - List obsolete files. # check-old-libs - List obsolete libraries. # delete-old - Delete obsolete directories/files/libraries. # delete-old-dirs - Delete obsolete directories. # delete-old-files- Delete obsolete files. # delete-old-libs - Delete obsolete libraries. # I am wondering if I should try these out, or will it just be taken care of with the cannonical methods. I seem to have lots of big problems with my configuration.. I don't know. Things work, but dmesg has errors, and many ports fail and their makes, even if they succeed have errors and warnings. If I delete-old-.. will I be messing things up? *--* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *--* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libz.so no found
On Fri, 23 May 2008, Daniel O'Connor wrote: On Fri, 23 May 2008, KAYVEN RIESE wrote: okay, so I don't have a shortcut key for freeBSD-hacker.. I went into my freeBSD saved box, grabbed the first email, replied to all, deleted everything including the subject, and despite having revised the subject, your sooperphreekiness found out I was muddling around in the deally bobber? Is that what you are talking about then? So in the future, I should know that editing the subject line will not suffice to make a new thread? If so, sorry. I get it now. Your mail client sets the In-Reply-To header to the message ID of the email you pulled out of your saved folder. Mail clients use this header to track what thread a message is in (even if someone changed the subject). Thanks. This makes things clear. I'm sorry that I felt scolded by the confusing barrage (I guess at least a couple of you thought this should have been obvious to me). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C *--* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *--* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Warning during make buildworld
There was one about mktemp() ./gengtype warning: structure `VEC_cp_token_position_heap' used but not defined warning: structure `c_arg_info' used but not defined warning: structure `c_switch' used but not defined warning: structure `et_node' used but not defined warning: structure `loop' used but not defined warning: structure `ipa_reference_vars_info_d' used but not defined warning: structure `reg_info_def' used but not defined warning: structure `value_set' used but not defined warning: structure `VEC_cp_token_position_heap' used but not defined warning: structure `c_arg_info' used but not defined warning: structure `c_switch' used but not defined warning: structure `et_node' used but not defined warning: structure `loop' used but not defined warning: structure `ipa_reference_vars_info_d' used but not defined warning: structure `reg_info_def' used but not defined warning: structure `value_set' used but not defined touch gtype-desc.h *--* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *--* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/src/Makefile instructions
On Fri, 2008-05-23 at 05:49 -0700, KAYVEN RIESE wrote: My professor told me about instructions being in /usr/src/Makefile for rebuilding my world. I feel better about following them because they are close to the command line to me and can't be out of date, right? I am looking at this list of makes: # check-old - List obsolete directories/files/libraries. # check-old-dirs - List obsolete directories. # check-old-files - List obsolete files. # check-old-libs - List obsolete libraries. # delete-old - Delete obsolete directories/files/libraries. # delete-old-dirs - Delete obsolete directories. # delete-old-files- Delete obsolete files. # delete-old-libs - Delete obsolete libraries. # I am wondering if I should try these out, or will it just be taken care of with the cannonical methods. I seem to have lots of big problems with my configuration.. I don't know. Things work, but dmesg has errors, and many ports fail and their makes, even if they succeed have errors and warnings. If I delete-old-.. will I be messing things up? No, it will Delete obsolete directories/files/libraries, with the usual meaning of obsolete. You should only need to do this when moving to a new (major?) release. I've redirected this to questions@, as this seems more like a 'User question/technical support' rather than 'General technical discussion'. Please try to keep the mailing lists on topic. Cheers Tom signature.asc Description: This is a digitally signed message part
Re: /usr/src/Makefile instructions
On Fri, May 23, 2008 at 05:49:48AM -0700, KAYVEN RIESE wrote: My professor told me about instructions being in /usr/src/Makefile for rebuilding my world. I feel better about following them because they are close to the command line to me and can't be out of date, right? No. Any comments or documentation *can* be out of date or otherwise misleading or incorrect. I am looking at this list of makes: Err.. that would be make targets, yeah? # check-old - List obsolete directories/files/libraries. # check-old-dirs - List obsolete directories. # check-old-files - List obsolete files. # check-old-libs - List obsolete libraries. # delete-old - Delete obsolete directories/files/libraries. # delete-old-dirs - Delete obsolete directories. # delete-old-files- Delete obsolete files. # delete-old-libs - Delete obsolete libraries. # I am wondering if I should try these out, or will it just be taken care of with the cannonical methods. I expect that depends a great deal on what your objectives are. If you are merely trying to keep a system up-to-date, you are (IMO) better off reading, then paying attention to changes in, /usr/src/UPDATING. If, on the other hand, you are curious about just what make(1) will do when told to make a given target, by all means experiment to your heart's content (on your own system(s)). But I encourage you to consider the utility of the -n flag to make(1). Well, that, as well as the value of good backup restore procedures. I seem to have lots of big problems with my configuration.. I don't know. Things work, but dmesg has errors, and many ports fail and their makes, even if they succeed have errors and warnings. If I delete-old-.. will I be messing things up? Hard to say without more information about your current configuration than is likely to fit in a message to the mailing list. If the complaints are sufficiently severe (note that the mere quantity of them isn't a relaible measure of this), you may be better off recording salient configuration information (e.g., what ports you tried to install), make a good backup (assuming there's data worth recovering), wiping the system clean, and starting over. It is certainly possible to mess a system up enough that recovery is problematic, at best. Peace, david -- David H. Wolfskill [EMAIL PROTECTED] I submit that conspiracy would be an appropriate collective noun for cats. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpmFcMkftLhN.pgp Description: PGP signature
Re: /usr/src/Makefile instructions
On Fri, 23 May 2008, Tom Evans wrote: On Fri, 2008-05-23 at 05:49 -0700, KAYVEN RIESE wrote: I've redirected this to questions@, as this seems more like a 'User question/technical support' rather than 'General technical discussion'. Please try to keep the mailing lists on topic. That list is too busy. I find I don't have to unsubscribe to hackers, and it doesn't seem as hard core to misinterpret what hackers are, than say ports or acpi I realized that make delete-old and make delete-old-libs are both part of the cannonical, I guess because I am going RELENG_6_3 to RELENG_7 On that note, was I given misinformation when I was advised that it would be impossible to upgrade RELENG_6_2 directly to RELENG_7 ? Cheers Tom *--* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *--* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/src/Makefile instructions
On that note, was I given misinformation when I was advised that it would be impossible to upgrade RELENG_6_2 directly to RELENG_7 ? Close to implausible, perhaps? That would indeed be the case, unless you truly are longing for a major workout, either with mergemaster et al, or both with mergemaster and the ports. The former case, which assumes you don't have many ports installed, is often a no-brainer: install a fresh system. The latter case may be somewhat more complicated: install a fresh system for the least effort on your side, or go the update route if you need to keep your system up and usable during the process. I should note that I always took the update trail, and never regretted it afterwards (well, if only so slightly). For instance, my workstation lived through 5.2.1-R, 6.2-R, RELENG_6, and finally RELENG_7, all with the aid of cvsup. The process is straightforward, well-designed and easily executed (thanks to the developers), but problems often pop-up with ports (especially such messy ones as Gnome, etc) which take lots of time to correct. So, in summary, a sane person should probably go with clean system update. P.S.: whoever replies next, it's safe to drop hackers@ from CC: anytime now Kayven Riese, BSCS, MS (Physiology and Biophysics) [SorAlx] ridin' VS1400 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/src/Makefile instructions
KAYVEN RIESE [EMAIL PROTECTED] wrote: Tom Evans wrote: I've redirected this to questions@, as this seems more like a 'User question/technical support' rather than 'General technical discussion'. Please try to keep the mailing lists on topic. That list is too busy. I find I don't have to unsubscribe to hackers, and it doesn't seem as hard core to misinterpret what hackers are, than say ports or acpi Well, hackers usually means developers, i.e. people hacking on the FreeBSD code. Therefore I'm afraid I have to agree with Tom: Your questions should better go to the questions list. I realized that make delete-old and make delete-old-libs are both part of the cannonical, I guess because I am going RELENG_6_3 to RELENG_7 I always use make delete-old, as instructed in the /usr/src/UPDATING file, and it has never bitten me. Please have a look at that file; the important part starts at the section titled To rebuild everything. On that note, was I given misinformation when I was advised that it would be impossible to upgrade RELENG_6_2 directly to RELENG_7 ? Nothing is impossible!, as Dr. Farnsworth from the Futurama series used to say. :-) But seriously ... I think going from 6.2 to 7.0 should work fine. However, the official notion is that updates across major versions have to be supported only for the latest stable release. Any other configurations might work, but it's not guaranteed. If it fails, you're not expected to complain or ask for help, but instead try the officially supported way (i.e. first update to the latest stable on your existing branch, then update across the major version boundary). If that still fails, you may complain and ask for help. Note that it is IMPORTANT to rebuild *all* of your ports when you update from 6.x to 7.x. (This holds true for any major version update.) If you don't do this, you will get library dependency collisions, i.e. port A uses libc.so.7 and depends on port B, but port B still links against the older libc.so.6. Things will break sooner or later. That's why you should rebuild *all* ports after updating to 7.x. (You can keep older ports only if you are absolutely sure that they are not part of any dependencies, and never will be.) In your previous mail you mentioned: Things work, but dmesg has errors, Would you please tell us what those errors are? We might be able to help you, but only if you tell us. and many ports fail and their makes Again: Please post messages and everything relevant to the problems. There are really people on these lists that are willing to help, but we need as much information as possible in order to be able to help. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
patch for Intel G33 on FreeBSD 6.3
hello, I have a New motherboard that has a integrated Intel G33 based video card. I see there is support for this in FreeBSD 7 kernel. (Disabled by Default) http://lists.freebsd.org/pipermail/cvs-src/2007-July/080677.html I was wondering if anyone had a patch laying around that would apply on FreeBSD 6.3 I would be more than willing to test this and even provide back traces. Thank you Sam Fourman Jr. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/src/Makefile instructions
On Fri, 23 May 2008, [EMAIL PROTECTED] wrote: On that note, was I given misinformation when I was advised that it would be impossible to upgrade RELENG_6_2 directly to RELENG_7 ? Close to implausible, perhaps? That would indeed be the case, unless you truly are longing for a major workout, either with mergemaster et al, or both with mergemaster and the ports. The former case, which assumes you don't have many ports installed, is often a no-brainer: install a fresh system. The latter case may be somewhat more complicated: install a fresh system for the least effort on your side, or go the update route if you need to keep your system up and usable during the process. I didn't really understand that and I don't understand why I am a bad person for spamming my idiotic thoughts on the matter, but in any case this is moot because I am up an runing RELENG_6_3 and making kernel after editing the stable-supfiles RELENG_6_3 to RELENG_7 let's all cross our fingers that communication has just happened. I should note that I always took the update trail, and never regretted it afterwards (well, if only so slightly). For instance, my workstation lived through 5.2.1-R, 6.2-R, RELENG_6, and finally RELENG_7, all with the aid of cvsup. The process is straightforward, well-designed and easily executed (thanks to the developers), but problems often pop-up with ports (especially such messy ones as Gnome, etc) which take lots of time to correct. I am feeling better about cvsup and even mergemaster nowadays. Thank you very much for your support. So, in summary, a sane person should probably go with clean system update. Is that what I am doing? Umm.. maybe not. I have all these errors that I don't understand and that people ignore but I have a browser and a terminal, so I feel like a functioning pile of carbon compounds. P.S.: whoever replies next, it's safe to drop hackers@ from CC: anytime now Nah.. hackers needs the publicity! Kayven Riese, BSCS, MS (Physiology and Biophysics) [SorAlx] ridin' VS1400 *--* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *--* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/src/Makefile instructions
On Fri, 23 May 2008, [EMAIL PROTECTED] wrote: On that note, was I given misinformation when I was advised that it would be impossible to upgrade RELENG_6_2 directly to RELENG_7 ? pcm/mixer.c /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/sndstat.c /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/sound.c /usr/src/sys/modules/sound/sound/../../../dev/sound/unit.c /usr/src/sys/module Close to implausible, perhaps? That would indeed be the case, unless you truly are longing for a major workout, either with mergemaster et al, or both with mergemaster and the ports. The former case, which assumes you don't have many ports installed, is often a no-brainer: install a fresh system. The latter case may be somewhat more complicated: install a fresh system for the least effort on your side, or go the update route if you need to keep your system up and usable during the process. awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/sym/../../dev/sym/sym_hipd.c === syscons (depend) === syscons/apm (depend) @ - /usr/src/sys machine - /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/syscons/apm/../../../dev/syscons/apm/apm_saver.c === syscons/blank (depend) @ - /usr/src/sys machine - /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/syscons/blank/../../../dev/syscons/blank/blank_saver.c === syscons/daemon (depend) @ - /usr/src/sys machine - /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/syscons/daemon/../../../dev/syscons/daemon/daemon_saver.c === syscons/dragon (depend) @ - /usr/src/sys machine - /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/syscons/dragon/../../../dev/syscons/dragon/dragon_saver.c === syscons/fade (depend) @ - /usr/src/sys machine - /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/syscons/fade/../../../dev/syscons/fade/fade_saver.c === syscons/fire (depend) @ - /usr/src/sys machine - /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/syscons/fire/../../../dev/syscons/fire/fire_saver.c === syscons/green (depend) @ - /usr/src/sys machine - /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/syscons/green/../../../dev/syscons/green/green_saver.c === syscons/logo (depend) @ - /usr/src/sys machine - /usr/src/sys/i386/include rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/syscons/logo/../../../dev/syscons/logo/logo_saver.c /usr/src/sys/modules/syscons/logo/../../../dev/syscons/logo/logo.c I should note that I always took the update trail, and never regretted it afterwards (well, if only so slightly). For instance, my workstation lived through 5.2.1-R, 6.2-R, RELENG_6, and finally RELENG_7, all with the aid of cvsup. The process is straightforward, well-designed and easily executed (thanks to the developers), but problems often pop-up with ports (especially such messy ones as Gnome, etc) which take lots of time to correct. rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC /usr/src/sys/modules/sysvipc/sysvshm/../../../kern/sysv_shm.c === ti (depend) @ - /usr/src/sys machine - /usr/src/sys/i386/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h ln -sf /usr/obj/usr/src/sys/GENERIC/opt_ti.h opt_ti.h ln -sf /usr/obj/usr/src/sys/GENERIC/opt_zero.h opt_zero.h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/obj/usr/src/sys/GENERIC
Re: /usr/src/Makefile instructions
On Fri, 23 May 2008, Oliver Fromme wrote: KAYVEN RIESE [EMAIL PROTECTED] wrote: Tom Evans wrote: I've redirected this to questions@, as this seems more like a 'User question/technical support' rather than 'General technical discussion'. Please try to keep the mailing lists on topic. That list is too busy. I find I don't have to unsubscribe to hackers, and it doesn't seem as hard core to misinterpret what hackers are, than say ports or acpi Well, hackers usually means developers, i.e. people hacking on the FreeBSD code. Therefore I'm afraid I have to agree with Tom: Your questions should better go to the questions list. ergo: because obviously I am a flumming idiot. I thought hacker was something you took eucalyptus fro. I realized that make delete-old and make delete-old-libs are both part of the cannonical, I guess because I am going RELENG_6_3 to RELENG_7 I always use make delete-old, as instructed in the /usr/src/UPDATING file, and it has never bitten me. Please have a look at that file; the important part starts at the section titled To rebuild everything. Actually, after composing this I kicked myself, because /usr/src/Makefile has clearly instructed me to do make delete-old after make installworld and I think I will throw caution to the wind and append -U to my subsequent mergemaster followed by make delete-old-libs On that note, was I given misinformation when I was advised that it would be impossible to upgrade RELENG_6_2 directly to RELENG_7 ? Nothing is impossible!, as Dr. Farnsworth from the Futurama series used to say. :-) Oh well. Water under the bridge. I expect to someday edit this to RELENG_7_1 or the like when freebsd.org says so and following the instructions in /usr/src/Makefile again. But seriously ... I think going from 6.2 to 7.0 should work fine. However, the official notion is that updates across major versions have to be supported only for the latest stable release. Any other configurations might work, but it's not guaranteed. If it fails, you're not expected to complain or ask for help, but instead try the officially supported way (i.e. first update to the latest stable on your existing branch, then update across the major version boundary). If that still fails, you may complain and ask for help. Interesting. No. Fascinitating. Captian Kirk, I believe this star will supernova in approximately 12 days, 13 hours, 34 minutes and 23.3425 seconds. Note that it is IMPORTANT to rebuild *all* of your ports when you update from 6.x to 7.x. (This holds true for any major version update.) If you don't do this, you will get library dependency collisions, i.e. port A uses libc.so.7 and depends on port B, but port B still links against the older libc.so.6. Things will break sooner or later. That's why you should rebuild *all* ports after updating to 7.x. (You can keep older ports only if you are absolutely sure that they are not part of any dependencies, and never will be.) My habit is to run cvsup standard-supfile followed by cvsup ports-supfile. IS that a dumb thing to do? In your previous mail you mentioned: Things work, but dmesg has errors, Would you please tell us what those errors are? We might be able to help you, but only if you tell us. I told the ACPI folks and they told me nicely that my appropriate post was too much of a hassle to bother with. Some ding dong was attaching after the fact of the wing ding and the fact that the errors occured between the wing and the ding was irrelevant since the dong ding subsequent to the ding ding recalibrated the whosits in an adequate fashion before reaching single user mode. and many ports fail and their makes Again: Please post messages and everything relevant to the problems. There are really people on these lists that are willing to help, but we need as much information as possible in order to be able to help. Best regards Oliver Well.. I reckon I mights a git up thah gumpshun whenis I's gonna get tootin' on sumptin that gits mah goat subsequently. -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' *--* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *--*___ freebsd-hackers@freebsd.org mailing list
kldxref oh oh
kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kv_bsd# *--* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *--* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kldxref oh oh
On Fri, 23 May 2008, KAYVEN RIESE wrote: kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked ref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kv_bsd#make kernel -- Kernel build for GENERIC started on Fri May 23 20:38:21 PDT 2008 -- === GENERIC mkdir -p /usr/obj/usr/src/sys -- stage 1: configuring the kernel -- cd /usr/src/sys/i386/conf; PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/usr/src/sys/GENERIC /usr/src/sys/i386/conf/GENERIC Kernel build directory is /usr/obj/usr/src/sys/GENERIC Don't forget to do ``make cleandepend make depend'' -- stage 2.1: cleaning up the object tree kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kldxref: file isn't dynamically-linked kv_bsd# *--* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular
temporary freezes when pressing capslock / numlock
Since upgrading to RELENG_7_0 I was experiencing momentary freezes (of about .5 seconds) whenever the capslock or numlock buttons were pressed. I would probably never have noticed it except for the strange noises produced when music is playing, and of course that is when it is the most annoying ;) The issue occurs both in console and in X, and for both ULE and 4BSD. The problem was reproducible with USB keyboards only (ukbd); atkbd seems fine. It also occurs when numlockx is used to set numlock on or off without keyboard interaction. Interestingly, if you add enough keyboards, the problem vanishes, which led me to kbdmux. Sure enough, removing device kbdmux from the kernel makes the problem go away (at the expensive of some functionality of course, but this is my current workaround). Kernel config and dmesg are attached. As you may notice, I enabled kernel lock profiling for the purpose of troubleshooting this issue. I recorded the stats over a single occurance of the glitch. It seems to spend a vast amount of time waiting on giant as compared to any other lock. The output is almost 100k so I've omitted it for now; if it is of use to anyone let me know and I will certainly include it in reply. Fraser Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE-p1 #30: Fri May 23 23:04:55 EST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CUSTOM Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz (2669.34-MHz 686-class CPU) Origin = GenuineIntel Id = 0x10676 Stepping = 6 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x8e3fdSSE3,RSVD2,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,b19 AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Cores per package: 2 real memory = 2146304000 (2046 MB) avail memory = 2094714880 (1997 MB) ACPI APIC Table: GBTGBTUACPI FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: GBT GBTUACPI on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7fde (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 cpu0: ACPI CPU on acpi0 acpi_perf0: ACPI CPU Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a082006000820 device_attach: est1 attach returned 6 p4tcc1: CPU Frequency Thermal Control on cpu1 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: PCI bus on pcib1 vgapci0: VGA-compatible display port 0xb000-0xb07f mem 0xf600-0xf6ff,0xe000-0xefff,0xf400-0xf5ff irq 16 at device 0.0 on pci1 uhci0: UHCI (generic) USB controller port 0xe100-0xe11f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: UHCI (generic) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: UHCI (generic) USB controller port 0xe500-0xe51f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: UHCI (generic) USB controller on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: UHCI (generic) USB controller port 0xe000-0xe01f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: UHCI (generic) USB controller on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xfa101000-0xfa1013ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: EHCI (generic) USB 2.0 controller on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb3 uhub3: 6 ports with 6 removable, self powered pcib2: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge irq 19
