Re: WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.
Warner Losh imp at bsdimp.com wrote on Sat Jan 16 00:22:51 UTC 2021 : > On Fri, Jan 15, 2021 at 1:03 PM Hartmann, O. > wrote: > > > Running FreeBSD CURRENT on a USB only platform with a customised kernel, I > > see this > > message all the time I reboot or log console messages: > > > > [...] > > WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD > > 13.0. > > > > Where does this message come from and what is causing the warning? I tried > > to identify > > and eliminate this message, but it seems to be stuck with the USB > > device/keyboard > > attached to the system. > > > > Any hint? > > > > to eliminate the message, kbd needs to be rewritten to not use giant. > > It will not be deleted before 13. I'll change the message to 14. Other examples for the general type of question . . . For example, various aarch64, armv7, and powerpc*: WARNING: Device "openfirm" is Giant locked and may be deleted before FreeBSD 13.0. RPi4B and RPi3B: WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 13.0. powerpc (old PowerMac G4): WARNING: Device "agp" is Giant locked and may be deleted before FreeBSD 13.0. WARNING: Device "consolectl" is Giant locked and may be deleted before FreeBSD 13.0. Note: FreeBSD has boot problems for various powerpc64 and 32-bit powerpc PowerMacs, so some material is from somewhat older vintages of 13. (I've not looked at the old PowerMac G3 at all for this.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.
From: Mark Millard
Subject: Re: WARNING: Device "kbd" is Giant locked and may be deleted before
FreeBSD 13.0.
Date: Fri, 15 Jan 2021 16:54:26 -0800
> Other examples for the general type of question . . .
>
>
> For example, various aarch64, armv7, and powerpc*:
>
> WARNING: Device "openfirm" is Giant locked and may be deleted before
> FreeBSD 13.0.
>
>
> RPi4B and RPi3B:
>
> WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 13.0.
>
>
> powerpc (old PowerMac G4):
>
> WARNING: Device "agp" is Giant locked and may be deleted before FreeBSD
> 13.0.
>
> WARNING: Device "consolectl" is Giant locked and may be deleted before
> FreeBSD 13.0.
>
>
> Note: FreeBSD has boot problems for various powerpc64 and 32-bit
> powerpc PowerMacs, so some material is from somewhat older vintages
> of 13. (I've not looked at the old PowerMac G3 at all for this.)
Following files are the source of this warning messages.
yasu@rolling-vm-freebsd1[1009]% git grep -F D_NEEDGIANT
sys/cam/scsi/scsi_target.c: .d_flags = D_NEEDGIANT,
sys/contrib/ipfilter/netinet/mlfk_ipl.c:.d_flags = 0, /*
D_NEEDGIANT - Should be SMP safe */
sys/dev/adlink/adlink.c:.d_flags = D_NEEDGIANT,
sys/dev/agp/agp.c: .d_flags = D_NEEDGIANT,
sys/dev/amr/amr.c: .d_flags = D_NEEDGIANT,
sys/dev/atkbdc/psm.c: .d_flags = D_NEEDGIANT,
sys/dev/ce/if_ce.c: .d_flags= D_NEEDGIANT,
sys/dev/fb/fb.c:.d_flags = D_NEEDGIANT,
sys/dev/fb/fbd.c: .d_flags = D_NEEDGIANT,
sys/dev/kbd/kbd.c: .d_flags = D_NEEDGIANT,
sys/dev/ofw/openfirmio.c: .d_flags = D_NEEDGIANT,
sys/dev/ofw/openpromio.c: .d_flags = D_NEEDGIANT,
sys/dev/pbio/pbio.c:.d_flags = D_NEEDGIANT,
sys/dev/speaker/spkr.c: .d_flags = D_NEEDGIANT,
sys/dev/syscons/syscons.c: .d_flags = D_NEEDGIANT | D_TRACKCLOSE,
sys/dev/tdfx/tdfx_pci.c:.d_flags = D_NEEDGIANT,
sys/dev/tpm/tpm.c: .d_flags = D_NEEDGIANT,
sys/dev/vkbd/vkbd.c:.d_flags = D_NEEDGIANT | D_NEEDMINOR,
sys/i386/bios/smapi.c: .d_flags = D_NEEDGIANT,
sys/i386/i386/elan-mmcr.c: .d_flags = D_NEEDGIANT,
sys/i386/i386/perfmon.c:.d_flags = D_NEEDGIANT,
sys/isa/vga_isa.c: .d_flags = D_NEEDGIANT,
sys/kern/kern_conf.c: if (devsw->d_flags & D_NEEDGIANT) {
sys/kern/kern_conf.c: if (devsw->d_flags & D_NEEDGIANT) {
sys/kern/kern_conf.c: } else if (devsw->d_flags & D_NEEDGIANT)
\
sys/sys/conf.h:#define D_NEEDGIANT 0x0040 /* driver want Giant */
yasu@rolling-vm-freebsd1[1010]%
---
Yasuhiro Kimura
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.
On Fri, Jan 15, 2021 at 1:03 PM Hartmann, O. wrote: > Running FreeBSD CURRENT on a USB only platform with a customised kernel, I > see this > message all the time I reboot or log console messages: > > [...] > WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD > 13.0. > > Where does this message come from and what is causing the warning? I tried > to identify > and eliminate this message, but it seems to be stuck with the USB > device/keyboard > attached to the system. > > Any hint? > to eliminate the message, kbd needs to be rewritten to not use giant. It will not be deleted before 13. I'll change the message to 14. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Warning about $local_unbound_tls not being set properly, on first boot of 12.0-BETA1
On 10/26/18 10:48 AM, Dag-Erling Smørgrav wrote: Rebecca Cran writes: After installing 12.0-BETA1, on the first boot I noticed a warning about $local_unbound_tls not being set properly. Ah, I should probably have added it to /etc/defaults/rc.conf. Can you do that (just set it to “no”) and let me know if it helps? That worked: the warning disappeared. -- Rebecca ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Warning about $local_unbound_tls not being set properly, on first boot of 12.0-BETA1
Rebecca Cran writes: > After installing 12.0-BETA1, on the first boot I noticed a warning > about $local_unbound_tls not being set properly. Ah, I should probably have added it to /etc/defaults/rc.conf. Can you do that (just set it to “no”) and let me know if it helps? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: warning errors with buildworld with llvm39
On Mon, Sep 05, 2016 at 09:09:00AM +0200, Dimitry Andric wrote: > On 05 Sep 2016, at 03:31, Shawn Webb wrote: > > > > On Tue, Aug 30, 2016 at 06:17:02PM -0700, Ngie Cooper wrote: > >> On Tue, Aug 30, 2016 at 5:54 PM, Matthew Macy wrote: > >>> > >>> > >>> I did a buildworld with llvm39. Unsurprisingly I had to pass NO_WERROR= > >>> as the llvm has added additional warnings since 3.8. > >>> > >>> https://gist.github.com/mattmacy/5f0c994b7587a10e3f58e7fd9fc1dd01 > >> > >> dim's working on the issues on ^/projects/clang390-import . Some of > >> the issues you've noted have been resolved. > >> Cheers, > >> -Ngie > > > > Hey Ngie et al, > > > > I've got a few more errors after importing the projects/clang390-import > > branch into a local version of the drm-next-4.7 branch. > > > > The log is here: > > > > https://gist.github.com/lattera/e3a9900eff4e3f8425e0ee2242f5ee4b > > Hi Shawn > > You need at least r305394, I fixed all the -Werror warnings in the mean time. > > -Dimitry > I've merged in HEAD along with the projects/clang390-import branch from github as of this morning, so I should be at the latest revision. I'm still seeing the same errors. As this isn't critical, I wouldn't spend too much time diagnosing this. I just tried it out of curiosity. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: warning errors with buildworld with llvm39
On 05 Sep 2016, at 03:31, Shawn Webb wrote: > > On Tue, Aug 30, 2016 at 06:17:02PM -0700, Ngie Cooper wrote: >> On Tue, Aug 30, 2016 at 5:54 PM, Matthew Macy wrote: >>> >>> >>> I did a buildworld with llvm39. Unsurprisingly I had to pass NO_WERROR= as >>> the llvm has added additional warnings since 3.8. >>> >>> https://gist.github.com/mattmacy/5f0c994b7587a10e3f58e7fd9fc1dd01 >> >> dim's working on the issues on ^/projects/clang390-import . Some of >> the issues you've noted have been resolved. >> Cheers, >> -Ngie > > Hey Ngie et al, > > I've got a few more errors after importing the projects/clang390-import > branch into a local version of the drm-next-4.7 branch. > > The log is here: > > https://gist.github.com/lattera/e3a9900eff4e3f8425e0ee2242f5ee4b Hi Shawn You need at least r305394, I fixed all the -Werror warnings in the mean time. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: warning errors with buildworld with llvm39
On Tue, Aug 30, 2016 at 06:17:02PM -0700, Ngie Cooper wrote: > On Tue, Aug 30, 2016 at 5:54 PM, Matthew Macy wrote: > > > > > > I did a buildworld with llvm39. Unsurprisingly I had to pass NO_WERROR= as > > the llvm has added additional warnings since 3.8. > > > > https://gist.github.com/mattmacy/5f0c994b7587a10e3f58e7fd9fc1dd01 > > dim's working on the issues on ^/projects/clang390-import . Some of > the issues you've noted have been resolved. > Cheers, > -Ngie Hey Ngie et al, I've got a few more errors after importing the projects/clang390-import branch into a local version of the drm-next-4.7 branch. The log is here: https://gist.github.com/lattera/e3a9900eff4e3f8425e0ee2242f5ee4b Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: warning errors with buildworld with llvm39
On Tue, Aug 30, 2016 at 5:54 PM, Matthew Macy wrote: > > > I did a buildworld with llvm39. Unsurprisingly I had to pass NO_WERROR= as > the llvm has added additional warnings since 3.8. > > https://gist.github.com/mattmacy/5f0c994b7587a10e3f58e7fd9fc1dd01 dim's working on the issues on ^/projects/clang390-import . Some of the issues you've noted have been resolved. Cheers, -Ngie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WARNING: [r299313] make installworld overwrites master.passwd and group!
On 5/9/16 10:47 PM, Glen Barber wrote: > On Tue, May 10, 2016 at 07:15:57AM +0200, O. Hartmann wrote: >> On a most recent buildworld with make installworld/installkernel I faced the >> fact that all the entries in /etc/master.passwd and /etc/group were reset to >> the initial/vanilla values. Luckily, I was able to fetch backups >> from /var/backups. >> >> I do not know which essential config files additionally got altered or reset >> to >> the initial values. >> >> This bug is present on all systems I maintain and I ran into this problem on >> approx ten boxes this morning. >> >> What is up here? >> > > Confirmed. This is my fault, misreading what I thought was a mismerge > (r299292). > > Reverting it now. I apologize for the inconvenience this caused you, > and appreciate the prompt report on the issue. It is reverted in > r299317. I've made the same mistake before. Here's a patch that should be right: https://people.freebsd.org/~bdrewery/patches/Makefile.inc1-restage-reinstall.diff -- Regards, Bryan Drewery ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WARNING: [r299313] make installworld overwrites master.passwd and group!
On Tue, May 10, 2016 at 07:15:57AM +0200, O. Hartmann wrote: > On a most recent buildworld with make installworld/installkernel I faced the > fact that all the entries in /etc/master.passwd and /etc/group were reset to > the initial/vanilla values. Luckily, I was able to fetch backups > from /var/backups. > > I do not know which essential config files additionally got altered or reset > to > the initial values. > > This bug is present on all systems I maintain and I ran into this problem on > approx ten boxes this morning. > > What is up here? > Confirmed. This is my fault, misreading what I thought was a mismerge (r299292). Reverting it now. I apologize for the inconvenience this caused you, and appreciate the prompt report on the issue. It is reverted in r299317. Glen signature.asc Description: PGP signature
Re: Warning: HEAD with zfs is potentially broken
> On Jun 15, 2015, at 09:17, O. Hartmann wrote: > > Am Mon, 15 Jun 2015 17:39:58 +0200 > Baptiste Daroussin schrieb: > >>> On Mon, Jun 15, 2015 at 08:13:12AM -0700, Peter Wemm wrote: >>> Beware, a recent change has moved zfs tools internal libraries to the wrong >>> location and this can cause machines to be unbootable. /sbin/zfs uses the >>> libraries from /lib, which are now going stale and may have undefined >>> symbols. >>> installworld is incorrectly installing them in /usr/lib. This happened >>> some >>> time in the last week or so. >>> >>> Be very careful over the next few days. This can cause boot failures. >> >> Same goes for everything that was installed in /lib >> >> I workarounded the issue with r284417. but given what now sys.mk does I >> really >> fear way more fallouts. >> >> regards, >> Bapt > > Luckily, since r284336, buildworld doesn't work properly (in my case amd64) > anymore. > Buildworld bails out on several weird mk messages ... Depends on your build options. I didn't dare run install world yesterday, but building with buildworld worked just fine for me with my stripped down build options. Thanks, ___ 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: Warning: HEAD with zfs is potentially broken
Am Mon, 15 Jun 2015 17:39:58 +0200 Baptiste Daroussin schrieb: > On Mon, Jun 15, 2015 at 08:13:12AM -0700, Peter Wemm wrote: > > Beware, a recent change has moved zfs tools internal libraries to the wrong > > location and this can cause machines to be unbootable. /sbin/zfs uses the > > libraries from /lib, which are now going stale and may have undefined > > symbols. > > installworld is incorrectly installing them in /usr/lib. This happened > > some > > time in the last week or so. > > > > Be very careful over the next few days. This can cause boot failures. > > Same goes for everything that was installed in /lib > > I workarounded the issue with r284417. but given what now sys.mk does I really > fear way more fallouts. > > regards, > Bapt Luckily, since r284336, buildworld doesn't work properly (in my case amd64) anymore. Buildworld bails out on several weird mk messages ... pgpcR06vFsbx7.pgp Description: OpenPGP digital signature
Re: Warning: HEAD with zfs is potentially broken
On Mon, Jun 15, 2015 at 08:13:12AM -0700, Peter Wemm wrote: > Beware, a recent change has moved zfs tools internal libraries to the wrong > location and this can cause machines to be unbootable. /sbin/zfs uses the > libraries from /lib, which are now going stale and may have undefined > symbols. > installworld is incorrectly installing them in /usr/lib. This happened some > time in the last week or so. > > Be very careful over the next few days. This can cause boot failures. Same goes for everything that was installed in /lib I workarounded the issue with r284417. but given what now sys.mk does I really fear way more fallouts. regards, Bapt pgph3rjA5MBzD.pgp Description: PGP signature
Re: WARNING: FOO.c: enum pmc_event has too many values: 1930 > 1023
On Apr 12, 2015, at 13:18, Benjamin Kaduk wrote: > Looking at the actual build log posted, the warning is emitted by cc, not > ctfconvert. This is not a compiler warning. While you can't see the ctfconvert/ctfmerge command because it's hidden, I'm sure that the warning comes from ctf. Just grep for the warning message in cddl/contrib/opensolaris/tools/ctf if you don't believe me. -- Rui Paulo ___ 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: WARNING: FOO.c: enum pmc_event has too many values: 1930 > 1023
On Sat, 11 Apr 2015, Rui Paulo wrote: > On Saturday 11 April 2015 15:53:41 Oliver Pinter wrote: > > Hi all! > > > > I just found the line in the subject in our jenkinsbuild log in both > > amd64 and i386 case (we don't modified these files): > > > > http://nyi-01.build.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-i386 > > /56/console > > http://nyi-01.build.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-amd > > 64/58/consoleFull > > > > And more similar lines: > > > > WARNING: kern_pmc.c: enum pmc_event has too many values: 1930 > 1023 > > This is a known problem. PMC abuses enums and CTF can't cope with it. Looking at the actual build log posted, the warning is emitted by cc, not ctfconvert. It is perfectly reasonable for a compiler to emit a warning when encountering code that uses more than 1023 values in a single enumeration, since C99 does not require a compiler to support more than that number of enumeration constants in a single enum (section 5.2.4.1). The warning indicates that the code may not be portable, even if the current compiler supports more than 1023 enumeration constants in an enumeration. -Ben ___ 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: WARNING: FOO.c: enum pmc_event has too many values: 1930 > 1023
On Saturday 11 April 2015 15:53:41 Oliver Pinter wrote: > Hi all! > > I just found the line in the subject in our jenkinsbuild log in both > amd64 and i386 case (we don't modified these files): > > http://nyi-01.build.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-i386 > /56/console > http://nyi-01.build.hardenedbsd.org:8180/jenkins/job/HardenedBSD-master-amd > 64/58/consoleFull > > And more similar lines: > > WARNING: kern_pmc.c: enum pmc_event has too many values: 1930 > 1023 > WARNING: kern_rwlock.c: enum pmc_event has too many values: 1930 > 1023 > WARNING: kern_sx.c: enum pmc_event has too many values: 1930 > 1023 > WARNING: kern_clock.c: enum pmc_event has too many values: 1930 > 1023 > WARNING: kern_mutex.c: enum pmc_event has too many values: 1930 > 1023 > WARNING: trap.c: enum pmc_event has too many values: 1930 > 1023 > WARNING: hwpmc_soft.c: enum pmc_event has too many values: 1930 > 1023 > WARNING: hwpmc_intel.c: enum pmc_event has too many values: 1930 > 1023 > WARNING: hwpmc_amd.c: enum pmc_event has too many values: 1930 > 1023 > WARNING: hwpmc_tsc.c: enum pmc_event has too many values: 1930 > 1023 > WARNING: hwpmc_x86.c: enum pmc_event has too many values: 1930 > 1023 > WARNING: hwpmc_logging.c: enum pmc_event has too many values: 1930 > 1023 > WARNING: hwpmc_piv.c: enum pmc_event has too many values: 1930 > 1023 > WARNING: hwpmc_uncore.c: enum pmc_event has too many values: 1930 > 1023 > WARNING: hwpmc_core.c: enum pmc_event has too many values: 1930 > 1023 > WARNING: hwpmc_mod.c: enum pmc_event has too many values: 1930 > 1023 > WARNING: kern_lock.c: enum pmc_event has too many values: 1930 > 1023 This is a known problem. PMC abuses enums and CTF can't cope with it. > and some other hwpmc related warnings too: > --- kern_pmc.o --- > /jenkins/workspace/HardenedBSD-master-amd64/sys/kern/kern_pmc.c:290:32: > warning: comparison of constant 131072 with expression of type 'enum > pmc_event' is always false > [-Wtautological-constant-out-of-range-compare] > KASSERT(ps->ps_ev.pm_ev_code >= PMC_EV_SOFT_FIRST && > ^ ~ > /jenkins/workspace/HardenedBSD-master-amd64/sys/sys/systm.h:84:24: > note: expanded from macro 'KASSERT' > if (__predict_false(!(exp)))\ > ^ > /jenkins/workspace/HardenedBSD-master-amd64/sys/sys/cdefs.h:453:51: > note: expanded from macro '__predict_false' > #define __predict_false(exp)__builtin_expect((exp), 0) > ^ > /jenkins/workspace/HardenedBSD-master-amd64/sys/kern/kern_pmc.c:291:28: > warning: comparison of constant 135167 with expression of type 'enum > pmc_event' is always true > [-Wtautological-constant-out-of-range-compare] > ps->ps_ev.pm_ev_code <= PMC_EV_SOFT_LAST, > ^ > /jenkins/workspace/HardenedBSD-master-amd64/sys/sys/systm.h:84:24: > note: expanded from macro 'KASSERT' > if (__predict_false(!(exp)))\ > ^ > /jenkins/workspace/HardenedBSD-master-amd64/sys/sys/cdefs.h:453:51: > note: expanded from macro '__predict_false' > #define __predict_false(exp)__builtin_expect((exp), 0) > ^ > --- kern_prot.o --- > --- kern_pmc.o --- > /jenkins/workspace/HardenedBSD-master-amd64/sys/kern/kern_pmc.c:307:13: > warning: comparison of constant 131072 with expression of type 'enum > pmc_event' is always false > [-Wtautological-constant-out-of-range-compare] > KASSERT(ev >= PMC_EV_SOFT_FIRST && > ~~ ^ ~ > /jenkins/workspace/HardenedBSD-master-amd64/sys/sys/systm.h:84:24: > note: expanded from macro 'KASSERT' > if (__predict_false(!(exp)))\ > ^ > /jenkins/workspace/HardenedBSD-master-amd64/sys/sys/cdefs.h:453:51: > note: expanded from macro '__predict_false' > #define __predict_false(exp)__builtin_expect((exp), 0) > ^ > /jenkins/workspace/HardenedBSD-master-amd64/sys/kern/kern_pmc.c:308:9: > warning: comparison of constant 135167 with expression of type 'enum > pmc_event' is always true > [-Wtautological-constant-out-of-range-compare] > ev <= PMC_EV_SOFT_LAST, > ~~ ^ > /jenkins/workspace/HardenedBSD-master-amd64/sys/sys/systm.h:84:24: > note: expanded from macro 'KASSERT' > if (__predict_false(!(exp)))\ > ^ > /jenkins/workspace/HardenedBSD-master-amd64/sys/sys/cdefs.h:453:51: > note: expanded from macro '__predict_false' > #define __predict_false(exp)__builtin_expect((exp), 0) We kept these checks for safety. -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://
Re: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On 03/07/2014 11:29, Warner Losh wrote: > On Mar 7, 2014, at 10:22 AM, Ian Lepore wrote: > >> On Fri, 2014-03-07 at 10:19 -0700, Warner Losh wrote: >>> On Mar 7, 2014, at 9:47 AM, Eitan Adler wrote: >>> On 7 March 2014 11:41, Rui Paulo wrote: > On 6 Mar 2014, at 23:30, David Xu wrote: >> it seems filename ended with a dot is illegal on Windows, if someone >> wants to check out freebsd source code on Windows, it will be a problem. > Is this something we want to support? Yes. > NetBSD made some invasive changes on their source tree to be able to > support case-insensitive filesystems (like renaming 'cvs' to 'xcvs' to > avoid clashing with the 'CVS' metadata directory), but they support > building NetBSD on many different platforms. Has anyone enumerated the problematic files for FreeBSD ? >>> Last time I looked there were only a handful. I’ll conduct a census and get >>> a concrete enumeration of the problem… >> Last time I noticed (early last year) there were 3 files ending in a dot >> and no case conflicts. Mercurial now finds just the one file ending in >> a dot and no case conflicts (doing "hg init;hg add -q" at /usr/src). > Confirmed via regex, almost… Now there’s only one ending in dot: > > ./tools/test/sort/bigtest/q-1.024.003. I confirmed, using Git, that this is the only problematic file when checking out head on Windows. On stable/9, lib/libc/gen/aux.c is the only problem. If someone is interested, r239193 could be MFC'd. On stable/8, some files under share/doc/psd/15.yacc are the only problem. r210167 could be MFC'd. Eric ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On 3/7/14 8:41 AM, Rui Paulo wrote: On 6 Mar 2014, at 23:30, David Xu wrote: it seems filename ended with a dot is illegal on Windows, if someone wants to check out freebsd source code on Windows, it will be a problem. Is this something we want to support? NetBSD made some invasive changes on their source tree to be able to support case-insensitive filesystems (like renaming 'cvs' to 'xcvs' to avoid clashing with the 'CVS' metadata directory), but they support building NetBSD on many different platforms. We don't support that yet, though. The file in question can be easily renamed, I think. We definitely want to support untaring/zipping the code on Windows. Even if not for cross compiling, just for convenience of use. -- Alfred Perlstein ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On Mar 7, 2014, at 6:30 PM, Adrian Chadd wrote: > On 7 March 2014 15:25, Warner Losh wrote: >> >> On Mar 7, 2014, at 4:12 PM, Eitan Adler wrote: >> >>> On 7 March 2014 13:50, Rui Paulo wrote: On 7 Mar 2014, at 10:38, David Chisnall wrote: > On 7 Mar 2014, at 16:41, Rui Paulo wrote: > >> On 6 Mar 2014, at 23:30, David Xu wrote: >>> it seems filename ended with a dot is illegal on Windows, if someone >>> wants to check out freebsd source code on Windows, it will be a problem. >> >> Is this something we want to support? > > Yes, definitely. Building FreeBSD on other platforms is one of the > requests we get very often from embedded systems vendors. Cheap > virtualisation has made it less urgent (they can just stick a FreeBSD > VirtualBox VM on their workstations), but it's definitely something we'd > like eventually. To my knowledge, no one is working on it, but we should > aim to make life easy for whoever does... I guess I should clarify: I wasn't talking about cross building in general, but specifically on Windows. It's far easier to setup a case-sensitive file system on OS X and cross build FreeBSD from there than it is on Windows. >>> >>> Over 50% of the people that come to FreeBSD.org run windows. If it is >>> possible to support building on windows, we should try. >> >> The big issue isn't case sensitivity or file names ending in dot. The real >> issue is that our build just isn't setup for this at the moment and it would >> be a big lift to make it work at all. Sure, go ahead and fix this minor >> flea-bite of an issue, but there are several large elephant-sized issues >> before we could have even a tiny chance of doing this... >> > > are those issues documented anywhere? :) I believe I talked to some notes at a developer’s summit 5 years ago or so on what I found. The hardest part is bootstrapping the tools needed in the build. Warner ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On 7 March 2014 15:25, Warner Losh wrote: > > On Mar 7, 2014, at 4:12 PM, Eitan Adler wrote: > >> On 7 March 2014 13:50, Rui Paulo wrote: >>> On 7 Mar 2014, at 10:38, David Chisnall wrote: >>> On 7 Mar 2014, at 16:41, Rui Paulo wrote: > On 6 Mar 2014, at 23:30, David Xu wrote: >> it seems filename ended with a dot is illegal on Windows, if someone >> wants to check out freebsd source code on Windows, it will be a problem. > > Is this something we want to support? Yes, definitely. Building FreeBSD on other platforms is one of the requests we get very often from embedded systems vendors. Cheap virtualisation has made it less urgent (they can just stick a FreeBSD VirtualBox VM on their workstations), but it's definitely something we'd like eventually. To my knowledge, no one is working on it, but we should aim to make life easy for whoever does... >>> >>> I guess I should clarify: I wasn't talking about cross building in general, >>> but specifically on Windows. It's far easier to setup a case-sensitive >>> file system on OS X and cross build FreeBSD from there than it is on >>> Windows. >> >> Over 50% of the people that come to FreeBSD.org run windows. If it is >> possible to support building on windows, we should try. > > The big issue isn't case sensitivity or file names ending in dot. The real > issue is that our build just isn't setup for this at the moment and it would > be a big lift to make it work at all. Sure, go ahead and fix this minor > flea-bite of an issue, but there are several large elephant-sized issues > before we could have even a tiny chance of doing this... > are those issues documented anywhere? :) -a ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On Mar 7, 2014, at 4:12 PM, Eitan Adler wrote: > On 7 March 2014 13:50, Rui Paulo wrote: >> On 7 Mar 2014, at 10:38, David Chisnall wrote: >> >>> On 7 Mar 2014, at 16:41, Rui Paulo wrote: >>> On 6 Mar 2014, at 23:30, David Xu wrote: > it seems filename ended with a dot is illegal on Windows, if someone > wants to check out freebsd source code on Windows, it will be a problem. Is this something we want to support? >>> >>> Yes, definitely. Building FreeBSD on other platforms is one of the >>> requests we get very often from embedded systems vendors. Cheap >>> virtualisation has made it less urgent (they can just stick a FreeBSD >>> VirtualBox VM on their workstations), but it's definitely something we'd >>> like eventually. To my knowledge, no one is working on it, but we should >>> aim to make life easy for whoever does... >> >> I guess I should clarify: I wasn’t talking about cross building in general, >> but specifically on Windows. It’s far easier to setup a case-sensitive file >> system on OS X and cross build FreeBSD from there than it is on Windows. > > Over 50% of the people that come to FreeBSD.org run windows. If it is > possible to support building on windows, we should try. The big issue isn’t case sensitivity or file names ending in dot. The real issue is that our build just isn’t setup for this at the moment and it would be a big lift to make it work at all. Sure, go ahead and fix this minor flea-bite of an issue, but there are several large elephant-sized issues before we could have even a tiny chance of doing this... Warner ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On 2014-03-07 18:12, Eitan Adler wrote: > On 7 March 2014 13:50, Rui Paulo wrote: >> On 7 Mar 2014, at 10:38, David Chisnall wrote: >> >>> On 7 Mar 2014, at 16:41, Rui Paulo wrote: >>> On 6 Mar 2014, at 23:30, David Xu wrote: > it seems filename ended with a dot is illegal on Windows, if someone > wants to check out freebsd source code on Windows, it will be a problem. Is this something we want to support? >>> >>> Yes, definitely. Building FreeBSD on other platforms is one of the >>> requests we get very often from embedded systems vendors. Cheap >>> virtualisation has made it less urgent (they can just stick a FreeBSD >>> VirtualBox VM on their workstations), but it's definitely something we'd >>> like eventually. To my knowledge, no one is working on it, but we should >>> aim to make life easy for whoever does... >> >> I guess I should clarify: I wasn’t talking about cross building in general, >> but specifically on Windows. It’s far easier to setup a case-sensitive file >> system on OS X and cross build FreeBSD from there than it is on Windows. > > Over 50% of the people that come to FreeBSD.org run windows. If it is > possible to support building on windows, we should try. > Even well shy of 'building' on windows, I do most of my docs work on windows. I even wrote most of the new code for bsdinstall on a windows machine. Being able to checkout the svn tree and work on it on my existing work station is nice. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On 7 March 2014 13:50, Rui Paulo wrote: > On 7 Mar 2014, at 10:38, David Chisnall wrote: > >> On 7 Mar 2014, at 16:41, Rui Paulo wrote: >> >>> On 6 Mar 2014, at 23:30, David Xu wrote: it seems filename ended with a dot is illegal on Windows, if someone wants to check out freebsd source code on Windows, it will be a problem. >>> >>> Is this something we want to support? >> >> Yes, definitely. Building FreeBSD on other platforms is one of the requests >> we get very often from embedded systems vendors. Cheap virtualisation has >> made it less urgent (they can just stick a FreeBSD VirtualBox VM on their >> workstations), but it's definitely something we'd like eventually. To my >> knowledge, no one is working on it, but we should aim to make life easy for >> whoever does... > > I guess I should clarify: I wasn’t talking about cross building in general, > but specifically on Windows. It’s far easier to setup a case-sensitive file > system on OS X and cross build FreeBSD from there than it is on Windows. Over 50% of the people that come to FreeBSD.org run windows. If it is possible to support building on windows, we should try. -- Eitan Adler ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On Mar 7, 2014, at 11:50 AM, Rui Paulo wrote: > On 7 Mar 2014, at 10:38, David Chisnall wrote: > >> On 7 Mar 2014, at 16:41, Rui Paulo wrote: >> >>> On 6 Mar 2014, at 23:30, David Xu wrote: it seems filename ended with a dot is illegal on Windows, if someone wants to check out freebsd source code on Windows, it will be a problem. >>> >>> Is this something we want to support? >> >> Yes, definitely. Building FreeBSD on other platforms is one of the requests >> we get very often from embedded systems vendors. Cheap virtualisation has >> made it less urgent (they can just stick a FreeBSD VirtualBox VM on their >> workstations), but it's definitely something we'd like eventually. To my >> knowledge, no one is working on it, but we should aim to make life easy for >> whoever does... > > I guess I should clarify: I wasn’t talking about cross building in general, > but specifically on Windows. It’s far easier to setup a case-sensitive file > system on OS X and cross build FreeBSD from there than it is on Windows. I’m > not even sure NetBSD builds on Windows with Cygwin anymore. > > Warner was working on building FreeBSD from OS X, IIRC. When I worked at Cisco in 2008, yes. That work went approximately no-where when I hit a huge snag in building gdb using static configurations for FreeBSD, but on a OS X host and the differences between them mattering. Warner ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On 7 Mar 2014, at 10:38, David Chisnall wrote: > On 7 Mar 2014, at 16:41, Rui Paulo wrote: > >> On 6 Mar 2014, at 23:30, David Xu wrote: >>> it seems filename ended with a dot is illegal on Windows, if someone >>> wants to check out freebsd source code on Windows, it will be a problem. >> >> Is this something we want to support? > > Yes, definitely. Building FreeBSD on other platforms is one of the requests > we get very often from embedded systems vendors. Cheap virtualisation has > made it less urgent (they can just stick a FreeBSD VirtualBox VM on their > workstations), but it's definitely something we'd like eventually. To my > knowledge, no one is working on it, but we should aim to make life easy for > whoever does... I guess I should clarify: I wasn’t talking about cross building in general, but specifically on Windows. It’s far easier to setup a case-sensitive file system on OS X and cross build FreeBSD from there than it is on Windows. I’m not even sure NetBSD builds on Windows with Cygwin anymore. Warner was working on building FreeBSD from OS X, IIRC. -- Rui Paulo ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On 7 Mar 2014, at 16:41, Rui Paulo wrote: > On 6 Mar 2014, at 23:30, David Xu wrote: >> it seems filename ended with a dot is illegal on Windows, if someone >> wants to check out freebsd source code on Windows, it will be a problem. > > Is this something we want to support? Yes, definitely. Building FreeBSD on other platforms is one of the requests we get very often from embedded systems vendors. Cheap virtualisation has made it less urgent (they can just stick a FreeBSD VirtualBox VM on their workstations), but it's definitely something we'd like eventually. To my knowledge, no one is working on it, but we should aim to make life easy for whoever does... David ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On Mar 7, 2014, at 10:22 AM, Ian Lepore wrote: > On Fri, 2014-03-07 at 10:19 -0700, Warner Losh wrote: >> On Mar 7, 2014, at 9:47 AM, Eitan Adler wrote: >> >>> On 7 March 2014 11:41, Rui Paulo wrote: On 6 Mar 2014, at 23:30, David Xu wrote: > it seems filename ended with a dot is illegal on Windows, if someone > wants to check out freebsd source code on Windows, it will be a problem. Is this something we want to support? >>> >>> Yes. >>> NetBSD made some invasive changes on their source tree to be able to support case-insensitive filesystems (like renaming 'cvs' to 'xcvs' to avoid clashing with the 'CVS' metadata directory), but they support building NetBSD on many different platforms. >>> >>> Has anyone enumerated the problematic files for FreeBSD ? >> >> Last time I looked there were only a handful. I’ll conduct a census and get >> a concrete enumeration of the problem… > > Last time I noticed (early last year) there were 3 files ending in a dot > and no case conflicts. Mercurial now finds just the one file ending in > a dot and no case conflicts (doing "hg init;hg add -q" at /usr/src). Confirmed via regex, almost… Now there’s only one ending in dot: ./tools/test/sort/bigtest/q-1.024.003. Warner ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On Fri, 2014-03-07 at 10:19 -0700, Warner Losh wrote: > On Mar 7, 2014, at 9:47 AM, Eitan Adler wrote: > > > On 7 March 2014 11:41, Rui Paulo wrote: > >> On 6 Mar 2014, at 23:30, David Xu wrote: > >>> it seems filename ended with a dot is illegal on Windows, if someone > >>> wants to check out freebsd source code on Windows, it will be a problem. > >> > >> Is this something we want to support? > > > > Yes. > > > >> NetBSD made some invasive changes on their source tree to be able to > >> support case-insensitive filesystems (like renaming 'cvs' to 'xcvs' to > >> avoid clashing with the 'CVS' metadata directory), but they support > >> building NetBSD on many different platforms. > > > > Has anyone enumerated the problematic files for FreeBSD ? > > Last time I looked there were only a handful. I’ll conduct a census and get a > concrete enumeration of the problem… Last time I noticed (early last year) there were 3 files ending in a dot and no case conflicts. Mercurial now finds just the one file ending in a dot and no case conflicts (doing "hg init;hg add -q" at /usr/src). -- Ian ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On Mar 7, 2014, at 9:47 AM, Eitan Adler wrote: > On 7 March 2014 11:41, Rui Paulo wrote: >> On 6 Mar 2014, at 23:30, David Xu wrote: >>> it seems filename ended with a dot is illegal on Windows, if someone >>> wants to check out freebsd source code on Windows, it will be a problem. >> >> Is this something we want to support? > > Yes. > >> NetBSD made some invasive changes on their source tree to be able to >> support case-insensitive filesystems (like renaming 'cvs' to 'xcvs' to avoid >> clashing with the 'CVS' metadata directory), but they support building >> NetBSD on many different platforms. > > Has anyone enumerated the problematic files for FreeBSD ? Last time I looked there were only a handful. I’ll conduct a census and get a concrete enumeration of the problem… Warner >> We don't support that yet, though. > > However, being able to checkout out the source code is a prerequisite > to building out other platforms. > >> The file in question can be easily renamed, I think. > > -- > Eitan Adler > ___ > 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" ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On 7 March 2014 11:41, Rui Paulo wrote: > On 6 Mar 2014, at 23:30, David Xu wrote: >> it seems filename ended with a dot is illegal on Windows, if someone >> wants to check out freebsd source code on Windows, it will be a problem. > > Is this something we want to support? Yes. > NetBSD made some invasive changes on their source tree to be able to > support case-insensitive filesystems (like renaming 'cvs' to 'xcvs' to avoid > clashing with the 'CVS' metadata directory), but they support building NetBSD > on many different platforms. Has anyone enumerated the problematic files for FreeBSD ? > We don't support that yet, though. However, being able to checkout out the source code is a prerequisite to building out other platforms. > The file in question can be easily renamed, I think. -- Eitan Adler ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On 6 Mar 2014, at 23:30, David Xu wrote: > it seems filename ended with a dot is illegal on Windows, if someone > wants to check out freebsd source code on Windows, it will be a problem. Is this something we want to support? NetBSD made some invasive changes on their source tree to be able to support case-insensitive filesystems (like renaming 'cvs' to 'xcvs' to avoid clashing with the 'CVS' metadata directory), but they support building NetBSD on many different platforms. We don't support that yet, though. The file in question can be easily renamed, I think. -- Rui Paulo ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On Mar 7, 2014, at 12:30 AM, David Xu wrote: > When I am using mercurial to initialize a freebsd repository, it prints > "warning: filename ends with '.', which is not allowed on Windows: > 'tools/test/sort/bigtest/q-1.024.003.' > > it seems filename ended with a dot is illegal on Windows, if someone > wants to check out freebsd source code on Windows, it will be a problem. There are other problems as well. We have some directories that have mixed case and lower case versions of the same file. This trips up OS unless you specifically format your disk to be case sensitive… Warner ___ 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: warning
On Wednesday 27 November 2013 12:59:10 Ajtim wrote: > On Wednesday 27 November 2013 17:07:40 you wrote: > > On Wed, Nov 27, 2013 at 4:55 PM, Ajtim wrote: > > > OS: FreeBSD 10.0-BETA3 #0 r257580: Sun Nov 3 19:43:01 UTC 2013 > > > r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > > > > > When I boot a computer I got one warning: > > > > > > /etc/rc: WARNING: $tcsd_enable is not set properly > > > > > > This is part of a port, security/trousers. Reinstall it? > > > > Cheers > > > > Tom > > Thank you. I didn't reinstall yet. > > I did and warning exist. If I put tcsd_enable="YES" in /etc/rc.conf than I gor that cannot start tcsd. Thank you. -- Mitja --- http://www.redbubble.com/people.lumiwa ___ 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: WARNING - DO NOT test: IPv6 offload support in HEAD + patch for stable/9
On 26. May 2012, at 14:01 , Bjoern A. Zeeb wrote: Hey. > WARNING - please refrain from testing IPv6 or updating your HEAD if you do > not have any of the above two NICs and rely on IPv6, or if you have updated > and > are experiencing problems. Disabling -txcsum -tso for the moment should be an > often unhelpful workaround. It seems I was just lucky with my choice of other It was not, as there was a further bug, which was fixed last night with http://svn.freebsd.org/changeset/base/236130 To fix the full problem, here's a proposed patch for testing on the latest HEAD or review: http://people.freebsd.org/~bz/20120527-02-fix-v6-csum-offload.diff I'd be happy to hear back from anyone on short notice that it works for him, and I'll get it in for (possible) further refinements. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: WARNING: su(1) broken in head
On 05/26/2012 16:36, Dag-Erling Smørgrav wrote: > Dag-Erling Smørgrav writes: >> probably due to an issue in the latest openpam; sudo is not affected > > should be fixed now. Confirmed, thanks. :) -- This .signature sanitized for your protection ___ 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: WARNING: su(1) broken in head
Dag-Erling Smørgrav writes: > probably due to an issue in the latest openpam; sudo is not affected should be fixed now. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: WARNING - DO NOT test: IPv6 offload support in HEAD + patch for stable/9
On 25. May 2012, at 16:55 , Bjoern A. Zeeb wrote: > Hey, > > last night I pushed in the essential offloading support changes for IPv6 > along with quite a bit of other "noise" into HEAD. There is more locking > improvements etc. to come once I have looped things back to my working tree > and Michael Tuexen will improve SCTP/v6 on loopback as well soonish. > > This is a call for testing. The in-tree cxgb(4) and ixgbe(4) drivers WARNING - please refrain from testing IPv6 or updating your HEAD if you do not have any of the above two NICs and rely on IPv6, or if you have updated and are experiencing problems. Disabling -txcsum -tso for the moment should be an often unhelpful workaround. It seems I was just lucky with my choice of other NICs I tested but I cannot say which once are affected in the tree and which once aren't. Andrew Gallatin has pointed out that I missed an essential IPv4 header parsing thing beyond TSO in some (most?) NIC drivers and it went unnoticed in review. I'll post an update in a few hours once I know how many drivers are affected, or have the proper fix as it might also be a question in which (old/cheap) silicon might not do what is expected. > have been updated to make use of the new features (TSO6/LRO6), and more > drivers will follow (I already have cxgbe done, talking about mxge, ..) > but others should also see improvements for at least upper layer protocol > checksum calculations and I'd love people to test with as many drivers as > possible, as I plan to merge it for the upcoming 9.1-RELEASE cycle and > wouldn't want to ship broken IPv6 in a few months;-) > > Here's the patch that should just apply to stable/9 matching what I put into > HEAD (+ an earlier cxgb change) (untested): > > http://people.freebsd.org/~bz/20120525-01-ipv6-offload-mfc9.diff > > If you need a patch for a specific release please drop me a private email > and I'll try to publish one (8.2 and up only though most likely). > > > Please test and report to me or net@. > > > Thanks > /bz > > > PS: we now also disallow LRO automatically if forwarding is turned on, just > in case you wonder; a change that should have been done years ago;-) -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: warning: 'inline' is not at beginning of declaration ?
On Thu, Jun 02, 2011, Arnaud Lacombe wrote: > > On a related topic, do we have any mechanism to provide > > per-subdir or per-file CFLAGS during kernel builds ? > > > I'd say no as the kernel per-se makes no use of , ooth, > some modules do. > > > I tried to put a Makefile.inc in a subdirectory but it > > did not help. > > > understandable, as Makefile.inc is sourced by , which is > only used by `sys/conf/kmod.mk'. There's a hack to do per-file CFLAGS in libc. We use this to compile the vendor sources gdtoa_*.c with warnings disabled, since the vendor disavows gcc's stylistic complaints. See src/lib/libc/Makefile. ___ 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: warning: 'inline' is not at beginning of declaration ?
A compile-with clause in the sys/conf/files configuration file may
work for what you want, e.g. picking a random example:
dev/e1000/e1000_82542.c optional em | igb \
compile-with "${NORMAL_C} -I$S/dev/e1000"
- Joshua
On Wed, Jun 1, 2011 at 9:54 AM, Luigi Rizzo wrote:
> In an attempt to build a kernel with -Wextra gives a number
> of warnings for
>
> 'inline' is not at beginning of declaration
>
> (in tcp_input.c, as an example).
>
> Is there any interest in trying to fix these ?
>
> HEAD/sys/netinet/tcp_input.c:218: warning: 'inline' is not at
> beginning of declaration
> HEAD/sys/netinet/tcp_input.c:224: warning: 'inline' is not at
> beginning of declaration
> HEAD/sys/netinet/tcp_input.c:226: warning: 'inline' is not at
> beginning of declaration
> HEAD/sys/netinet/tcp_input.c:227: warning: 'inline' is not at
> beginning of declaration
> HEAD/sys/netinet/tcp_input.c:228: warning: 'inline' is not at
> beginning of declaration
> HEAD/sys/netinet/tcp_input.c:248: warning: 'inline' is not at
> beginning of declaration
> HEAD/sys/netinet/tcp_input.c:266: warning: 'inline' is not at
> beginning of declaration
> HEAD/sys/netinet/tcp_input.c:298: warning: 'inline' is not at
> beginning of declaration
> HEAD/sys/netinet/tcp_input.c:388: warning: 'inline' is not at
> beginning of declaration
> HEAD/sys/netinet/tcp_input.c:440: warning: 'inline' is not at
> beginning of declaration
>
> On a related topic, do we have any mechanism to provide
> per-subdir or per-file CFLAGS during kernel builds ?
> I tried to put a Makefile.inc in a subdirectory but it
> did not help.
>
> cheers
> luigi
> ___
> 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"
>
___
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: warning: 'inline' is not at beginning of declaration ?
Hi, On Wed, Jun 1, 2011 at 12:54 PM, Luigi Rizzo wrote: > In an attempt to build a kernel with -Wextra gives a number > of warnings for > > 'inline' is not at beginning of declaration > > (in tcp_input.c, as an example). > > Is there any interest in trying to fix these ? > > HEAD/sys/netinet/tcp_input.c:218: warning: 'inline' is not at > beginning of declaration > HEAD/sys/netinet/tcp_input.c:224: warning: 'inline' is not at > beginning of declaration > HEAD/sys/netinet/tcp_input.c:226: warning: 'inline' is not at > beginning of declaration > HEAD/sys/netinet/tcp_input.c:227: warning: 'inline' is not at > beginning of declaration > HEAD/sys/netinet/tcp_input.c:228: warning: 'inline' is not at > beginning of declaration > HEAD/sys/netinet/tcp_input.c:248: warning: 'inline' is not at > beginning of declaration > HEAD/sys/netinet/tcp_input.c:266: warning: 'inline' is not at > beginning of declaration > HEAD/sys/netinet/tcp_input.c:298: warning: 'inline' is not at > beginning of declaration > HEAD/sys/netinet/tcp_input.c:388: warning: 'inline' is not at > beginning of declaration > HEAD/sys/netinet/tcp_input.c:440: warning: 'inline' is not at > beginning of declaration > > On a related topic, do we have any mechanism to provide > per-subdir or per-file CFLAGS during kernel builds ? > I'd say no as the kernel per-se makes no use of , ooth, some modules do. > I tried to put a Makefile.inc in a subdirectory but it > did not help. > understandable, as Makefile.inc is sourced by , which is only used by `sys/conf/kmod.mk'. - Arnaud > cheers > luigi > ___ > 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" > ___ 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: WARNING: Non-uniform processors.
09.07.2010 14:41, Ivan Voras пишет: On 07/08/10 18:42, Alex Keda wrote: When booting, I have strange message. All work OK (processor with hyperthreading, but system seems it as 1 CPU ). lissyara-gp# dmesg Copyright (c) 1992-2010 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 9.0-CURRENT #0 r209745: Wed Jul 7 06:08:36 MSD 2010 r...@lissyara-gp.grand-prix:/usr/obj/usr/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Pentium(R) 4 CPU 3.06GHz (3056.87-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Family = f Model = 2 Stepping = 9 Features=0xbfebfbff Features2=0x4400 real memory = 1611137024 (1536 MB) avail memory = 1559203840 (1486 MB) Event timer "LAPIC" frequency 0 Hz quality 500 ACPI APIC Table: WARNING: Non-uniform processors. WARNING: Using suboptimal topology. ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 5ff0 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0:<24-bit timer at 3.579545MHz> port 0xf808-0xf80b on acpi0 cpu0: on acpi0 Yes, your situation looks a bit strange, but maybe it's because of the Compaq (or early HPaq) brand, they did strange things with BIOSes in those days. Apparently, the OS detects only one logical CPU (no hyperthreading) on your system, but it looks like HTT is enabled, so this might be the cause of your message. In any case, you will probably not have any problems with this configuration. HTT in those days sucked anyway. On the other hand, you are running a CURRENT kernel with WITNESS and other debugging enabled, so as the boot message says, expect your system to run very slow. OK. Thanks for explanation! ___ 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: WARNING: Non-uniform processors.
On 07/08/10 18:42, Alex Keda wrote: > When booting, I have strange message. > All work OK (processor with hyperthreading, but system seems it as 1 CPU ). > lissyara-gp# dmesg > Copyright (c) 1992-2010 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 9.0-CURRENT #0 r209745: Wed Jul 7 06:08:36 MSD 2010 > r...@lissyara-gp.grand-prix:/usr/obj/usr/src/sys/GENERIC i386 > WARNING: WITNESS option enabled, expect reduced performance. > CPU: Intel(R) Pentium(R) 4 CPU 3.06GHz (3056.87-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Family = f Model = 2 Stepping = 9 > > Features=0xbfebfbff > > Features2=0x4400 > real memory = 1611137024 (1536 MB) > avail memory = 1559203840 (1486 MB) > Event timer "LAPIC" frequency 0 Hz quality 500 > ACPI APIC Table: > WARNING: Non-uniform processors. > WARNING: Using suboptimal topology. > ioapic0: Changing APIC ID to 8 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a (3) failed > acpi0: reservation of 10, 5ff0 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xf808-0xf80b on acpi0 > cpu0: on acpi0 Yes, your situation looks a bit strange, but maybe it's because of the Compaq (or early HPaq) brand, they did strange things with BIOSes in those days. Apparently, the OS detects only one logical CPU (no hyperthreading) on your system, but it looks like HTT is enabled, so this might be the cause of your message. In any case, you will probably not have any problems with this configuration. HTT in those days sucked anyway. On the other hand, you are running a CURRENT kernel with WITNESS and other debugging enabled, so as the boot message says, expect your system to run very slow. ___ 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: WARNING: Non-uniform processors.
08.07.2010 22:13, Super Biscuit ?: --- On *Thu, 7/8/10, Alex Keda //* wrote: From: Alex Keda Subject: WARNING: Non-uniform processors. To: freebsd-current@freebsd.org Date: Thursday, July 8, 2010, 4:42 PM When booting, I have strange message. All work OK (processor with hyperthreading, but system seems it as 1 CPU ). Compatible mode usually gives slower response. Unless you need it, don't run it. I have a P4 2.8GHz. Same thing happens. you about it: > WARNING: Non-uniform processors. > WARNING: Using suboptimal topology. ? ___ 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: WARNING: Non-uniform processors.
--- On Thu, 7/8/10, Alex Keda wrote: From: Alex Keda Subject: WARNING: Non-uniform processors. To: freebsd-current@freebsd.org Date: Thursday, July 8, 2010, 4:42 PM When booting, I have strange message. All work OK (processor with hyperthreading, but system seems it as 1 CPU ). lissyara-gp# dmesg Copyright (c) 1992-2010 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 9.0-CURRENT #0 r209745: Wed Jul 7 06:08:36 MSD 2010 r...@lissyara-gp.grand-prix:/usr/obj/usr/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Pentium(R) 4 CPU 3.06GHz (3056.87-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Family = f Model = 2 Stepping = 9 Features=0xbfebfbff Features2=0x4400 real memory = 1611137024 (1536 MB) avail memory = 1559203840 (1486 MB) Event timer "LAPIC" frequency 0 Hz quality 500 ACPI APIC Table: WARNING: Non-uniform processors. WARNING: Using suboptimal topology. ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 5ff0 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xf808-0xf80b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x2000-0x20ff mem 0xf400-0xf7ff,0xfc40-0xfc40 irq 18 at device 0.0 on pci1 vgapci1: mem 0xf800-0xfbff,0xfc41-0xfc41 at device 0.1 on pci1 uhci0: port 0x3440-0x345f irq 16 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x3460-0x347f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 ehci0: mem 0xfca0-0xfca003ff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 pcib2: at device 30.0 on pci0 pci5: on pcib2 fxp0: port 0x1000-0x103f mem 0xfc50-0xfc500fff irq 20 at device 8.0 on pci5 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:0b:cd:c0:b2:5e fxp0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x34a0-0x34af irq 18 at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pcm0: port 0x3000-0x30ff,0x3400-0x343f mem 0xfca00400-0xfca005ff,0xfca00600-0xfca006ff irq 17 at device 31.5 on pci0 pcm0: [ITHREAD] pcm0: acpi_button0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 attimer0: [FILTER] Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: [FILTER] Event timer "RTC" frequency 32768 Hz quality 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 ppc0: port 0x378-0x37f,0x778-0x77d irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/13 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem 0xc-0xcbfff,0xcc000-0xcd7ff pnpid ORM on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 p4tcc0: on cpu0 Timecounter "TSC" frequency 3056869772 Hz quality 800 Starting kernel event timers: LAPIC @ 1000Hz, i8254 @ 128Hz Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ad1: 32254MB at ata0-slave UDMA100 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 acd0: CDRW at ata1-master UDMA40 WARNING: WITNESS option enabled, expect reduced performance. uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 Root mount waiting for: usbus2 uhub2: 6 ports with 6 removable, self powered Trying to mount root from ufs:/dev/ad1s1a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To
Re: ? warning used static ldt allocation
Pau Rodriguez wrote: > #dmesg|tail -n 2 > Warning: pid 474 used static ldt allocation. > See the i386_set_ldt man page for more info > > What does it means? > > It was apearring for aprox. 15days. > > What I have to do? > > Maybe it was asked before... Could anybody refetch that message or answer? :( The program you are running is asking for a specific LDT entry, and this usage is deprecated, to avoid multiple library instances requesting the same LDT in the same program. The program should be recompiled to use a start_sel of LDT_AUTO_ALLOC, which will cause it to be dynamically allocated, which will avoid any potential conflict between libraries and/or your application. This was done a while ago, and was discussed on both the -current and -arch mailing lists; if you are going to run -current, you should probably subscribe to the -current mailing list so you see these things when they happen, and they don't suprise you. More information is available in the man page references on 5.1-current on the FreeBSD.org web site (Documentation/Manual pages) or in the man page on the system having the problem. The man page should probably be updated to deprecate non-automatic allocation specifically, since it doesn't appear to say anything useful about it at present (and your console message specifically references the non-existent deprecation in the man page). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Warning with loader Makefile?
On Fri, Aug 08, 2003 at 11:25:49AM +1200, Andrew Turner wrote:
[...]
> I found this patch worked by removing the secound ${PROG} target if
> there was already one there.
>
> --- /usr/src/share/mk/bsd.prog.mk Mon Jun 30 06:16:26 2003
> +++ /usr/share/mk/bsd.prog.mk Mon Aug 4 17:54:22 2003
> @@ -31,11 +31,13 @@
>
> OBJS+= ${SRCS:N*.h:R:S/$/.o/g}
>
> +.if !target(${PROG})
> ${PROG}: ${OBJS}
> .if defined(PROG_CXX)
> ${CXX} ${CXXFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD}
> .else
> ${CC} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD}
> +.endif
> .endif
>
> .else !defined(SRCS)
No, thanks. If a makefile has a
${PROG}: foo
line, just to add an additional dependency, this patch will break
building the ${PROG}.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Re: Warning with loader Makefile?
Nate Lawson wrote:
I get this:
===> i386/cdboot
===> i386/kgzldr
===> i386/libi386
===> i386/loader
"/usr/share/mk/bsd.prog.mk", line 38: warning: duplicate script for target "loader"
ignored
cc -nostdlib -static -Ttext 0x0 -o loader.sym
/home/obj/home/src/sys/boot/i386/loader/../btx/lib/crt0.o main.o conf.o
bcache.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o
interp_parse.o ls.o misc.o module.o panic.o load_elf32.o load_elf64.o
isapnp.o pnp.o interp_forth.o vers.o
Why is there a duplicate script?
I found this patch worked by removing the secound ${PROG} target if
there was already one there.
Andrew
--- /usr/src/share/mk/bsd.prog.mk Mon Jun 30 06:16:26 2003
+++ /usr/share/mk/bsd.prog.mk Mon Aug 4 17:54:22 2003
@@ -31,11 +31,13 @@
OBJS+= ${SRCS:N*.h:R:S/$/.o/g}
+.if !target(${PROG})
${PROG}: ${OBJS}
.if defined(PROG_CXX)
${CXX} ${CXXFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD}
.else
${CC} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD}
+.endif
.endif
.else !defined(SRCS)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Warning with loader Makefile?
On Thu, Aug 07, 2003 at 02:46:23PM -0300, Daniel C. Sobral wrote:
> Nate Lawson wrote:
> >I get this:
> >===> i386/cdboot
> >===> i386/kgzldr
> >===> i386/libi386
> >===> i386/loader
> >"/usr/share/mk/bsd.prog.mk", line 38: warning: duplicate script for target
> >"loader" ignored
> >cc -nostdlib -static -Ttext 0x0 -o loader.sym
> >/home/obj/home/src/sys/boot/i386/loader/../btx/lib/crt0.o main.o conf.o
> >bcache.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o
> >interp_parse.o ls.o misc.o module.o panic.o load_elf32.o load_elf64.o
> >isapnp.o pnp.o interp_forth.o vers.o
> >
> >Why is there a duplicate script?
>
> This might be a new gcc 3.3 warning. The ${PROG} target is defined in
> loader's Makefile:
>
> # $FreeBSD: src/sys/boot/i386/loader/Makefile,v 1.66 2003/06/26 03:51:57
> peter Exp $
> ...
> PROG= loader
> ...
> ${PROG}: ${PROG}.bin ${BTXLDR} ${BTXKERN} ${BTXCRT}
> btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l ${BTXLDR} \
> -b ${BTXKERN} ${PROG}.bin
>
> Now, bsd.prog.mk also defines a PROG target. It is included later on
> this file:
>
> .include
>
> ${PROG}.sym: ${OBJS} ${LIBI386} ${LIBSTAND} ${LIBFICL} vers.o
> ${CC} ${LDFLAGS} -o ${.TARGET} ${BTXCRT} ${OBJS} vers.o \
> ${LIBFICL} ${LIBI386} ${LIBSTAND}
>
>
> This was added by Mike Smith in version 1.13. It brings in ${OBJS}
> definition and maybe linker stuff (from Mike's commit message).
>
> I'm bringing Ruslan in this. He might be able to help with this.
>
I'm well aware of this problem. It's been on my TODO list for
a long time. When I have time, I will fix it. Don't worry,
it's harmless, and no, it's not new, and it doesn't have any
relation to GCC. It's just that make(1) was fixed to print
these warnings (was that Juli who fixed it?).
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Re: Warning with loader Makefile?
Nate Lawson wrote:
I get this:
===> i386/cdboot
===> i386/kgzldr
===> i386/libi386
===> i386/loader
"/usr/share/mk/bsd.prog.mk", line 38: warning: duplicate script for target "loader"
ignored
cc -nostdlib -static -Ttext 0x0 -o loader.sym
/home/obj/home/src/sys/boot/i386/loader/../btx/lib/crt0.o main.o conf.o
bcache.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o
interp_parse.o ls.o misc.o module.o panic.o load_elf32.o load_elf64.o
isapnp.o pnp.o interp_forth.o vers.o
Why is there a duplicate script?
This might be a new gcc 3.3 warning. The ${PROG} target is defined in
loader's Makefile:
# $FreeBSD: src/sys/boot/i386/loader/Makefile,v 1.66 2003/06/26 03:51:57
peter Exp $
...
PROG= loader
...
${PROG}: ${PROG}.bin ${BTXLDR} ${BTXKERN} ${BTXCRT}
btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l ${BTXLDR} \
-b ${BTXKERN} ${PROG}.bin
Now, bsd.prog.mk also defines a PROG target. It is included later on
this file:
.include
${PROG}.sym: ${OBJS} ${LIBI386} ${LIBSTAND} ${LIBFICL} vers.o
${CC} ${LDFLAGS} -o ${.TARGET} ${BTXCRT} ${OBJS} vers.o \
${LIBFICL} ${LIBI386} ${LIBSTAND}
This was added by Mike Smith in version 1.13. It brings in ${OBJS}
definition and maybe linker stuff (from Mike's commit message).
I'm bringing Ruslan in this. He might be able to help with this.
--
Daniel C. Sobral (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
VIVO Centro Oeste Norte
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Outros:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
If you are in the C shell and have just installed a new program, you won't
be able to run it unless you first type "rehash".
-- Dru <[EMAIL PROTECTED]>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: warning: inlining failed
Nate Lawson wrote: > /home/src/sys/gnu/ext2fs/ext2_vfsops.c: In function `ext2_unmount': > @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' "Warning: compiler failed to do what the hell it was told to do". 8-). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: warning: inlining failed
On Fri, 18 Jul 2003, Jacques A. Vidrine wrote:
> On Fri, Jul 18, 2003 at 12:18:14PM -0700, Nate Lawson wrote:
> > Warner mentioned this was due to the gcc import. Nearly every part of the
> > kernel that uses newbus or buf.h prints out lots of warnings. Can someone
> > see about fixing this, whether it's by fixing our headers or build flags
> > or gcc itself? I've already wasted a few reboot cycles because valid
> > warnings were lost in the crowd.
> >
> > cc -O -pipe -mcpu=pentiumpro -D_KERNEL -Wall -Wredundant-decls -Wnested-externs
> > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
> > -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev
> > -I@/../include -I/usr/include -fno-common -mno-align-long-strings
> > -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls
> > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> > -Winline -Wcast-qual -fformat-extensions -std=c99 -c
> > /home/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_vfsops.c
> > /home/src/sys/gnu/ext2fs/ext2_vfsops.c: In function `compute_sb_data':
> > @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK'
> > /home/src/sys/gnu/ext2fs/ext2_vfsops.c:496: warning: called from here
> ...
> Does `-finline-limit=1200' (or bigger) help?
Maybe. It allows larger declared-inline functions to actually be inlined
of course. This probably helps performance negatively in the case of
large functions like BUF_LOCK.
> I think GCC 3.3 added a warning for when inline functions generated `a
> lot' of instructions. In such a case, the function is not inlined. I
> believe this also happened with GCC 3.2, but it just didn't normally
> tell you about it.
A warning (-Winline) about gcc not inlining a function because the
function involves "a lot" of instructions has existed for ages, and
FreeBSD has used it since since I reenabled it in 1997 in rev.1.6 of
bsd.kern.mk, but it was apparently broken in at least gcc-3.[1-2].
The main differences between gcc-3.2 and gcc-3.3 in this area seem to
be just that the warning actually works in gcc-3.3, and gcc-3.3 has
more options for quantifying "a lot" than anyone would want to know
about.
Since gcc now warns when it should, and successful inlining of all
inline functions in FreeBSD was apparently broken in gcc-3.1, gcc-3.3
now emits hundreds or thousands of warnings about functions that it
can't inline. -Wunline was supposed to let us fix bogus inlining
incrementatally, but this was defeated by it not working in gcc-3.[1-2].
E.g., according to my kernel backups, non-inlining of BUF_LOCK started
with gcc-3.1. Some relevant history:
1996/06/26: BUF_LOCK implemented (as an inline) in buf.h rev.1.71
2002/05/09: kernel built on this date by gcc-2.95.4 (20020320) has no
static copies of BUF_LOCK
2002/06/29: kernel built on this date by gcc-3.1 (20020529) has 11
static copies of BUF_LOCK
The new options for controlling inlining are:
-finline-linit=
--param max-inline-insns=
--param max-inline-insns-single=
--param max-inline-insns-auto=
--param min-inline-insns=
--param max-inline-insns-rtl=
See gcc.info for details.
I couldn't find a setting that I liked. Most things compile with
--param max-inline-insns-single=1600, which sort of corresponds to
-finline-linit=3200 (more than 5 times larger than the default).
A few files need amazingly larger values. Compiling with values
smaller than the default unconvered interesting bugs in the source
code (invalid asm and an unitiialized variable). What I want is
for leaf functions declared as inline to always be inlined unless
they are larger than some limit, but the gcc controls are mainly for
for limiting the size of non-leaf functions. Apparently-small
functions can become amazingly large due to nested inllining. This
gives inlining failures which are not entirely the fault of bloat in
the inline functions. E.g., the following trick (which is used a lot
in subr_mbuf.c and kern_descrip.c) doesn't actually give inline functions:
%%%
static inline int
bigfunc(int foo, int flags)
{
/* Large code. */
...
return (resultoflargecode);
}
static int
smallfunc1(int foo)
{
return (bigfunc(foo, 1));
}
static int
smallfunc2(int foo)
{
return (bigfunc(foo, 2));
}
static int
smallfunc3(int foo)
{
return (bigfunc(foo, 3));
}
...
%%%
This trick is used mainly to avoid repeating the relevant parts of
bigfunc() at the source level. Repeating them at the object level is
wanted and expected to do more than just avoid a function call since
large sections of code can be optimized away when `flags' has a constant
value. But gcc-3 doesn't like this trick since it gives large code
to inline. The effectivness of the desired inlining (or lack thereof)
is apparently null. No one noticed when the inlining stopped with
gcc-3.1 14 months ago. (I checked that the interesting inlining of
mb_alloc() was done on
Re: warning: inlining failed
Nate Lawson <[EMAIL PROTECTED]> writes: > Warner mentioned this was due to the gcc import. Nearly every part of the > kernel that uses newbus or buf.h prints out lots of warnings. Can someone > see about fixing this, whether it's by fixing our headers or build flags > or gcc itself? I've already wasted a few reboot cycles because valid > warnings were lost in the crowd. > > cc -O -pipe -mcpu=pentiumpro -D_KERNEL -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 > -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include > -I/usr/include -fno-common -mno-align-long-strings > -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 > -c [snip] -Wno-inline will disable warnings about functions not getting inlined. If the inlining is necessary, consider -finline-limit as suggested by another poster. I haven't tried it myself, but it seems probably harmless and at least useful for seeing those other warnings you'd like to see. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: warning: inlining failed
On Fri, Jul 18, 2003 at 12:18:14PM -0700, Nate Lawson wrote: > Warner mentioned this was due to the gcc import. Nearly every part of the > kernel that uses newbus or buf.h prints out lots of warnings. Can someone > see about fixing this, whether it's by fixing our headers or build flags > or gcc itself? I've already wasted a few reboot cycles because valid > warnings were lost in the crowd. > > cc -O -pipe -mcpu=pentiumpro -D_KERNEL -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev > -I@/../include -I/usr/include -fno-common -mno-align-long-strings > -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > -fformat-extensions -std=c99 -c > /home/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_vfsops.c > /home/src/sys/gnu/ext2fs/ext2_vfsops.c: In function `compute_sb_data': > @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' > /home/src/sys/gnu/ext2fs/ext2_vfsops.c:496: warning: called from here > /home/src/sys/gnu/ext2fs/ext2_vfsops.c: In function `ext2_unmount': > @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' > /home/src/sys/gnu/ext2fs/ext2_vfsops.c:774: warning: called from here > @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' > /home/src/sys/gnu/ext2fs/ext2_vfsops.c:780: warning: called from here > @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' > /home/src/sys/gnu/ext2fs/ext2_vfsops.c:784: warning: called from here Does `-finline-limit=1200' (or bigger) help? I think GCC 3.3 added a warning for when inline functions generated `a lot' of instructions. In such a case, the function is not inlined. I believe this also happened with GCC 3.2, but it just didn't normally tell you about it. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: #warning must be protected by #if __GNUC__ in headers?
Garrett Wollman wrote: > `#if __GNUC__' wouldn't help matters; every preprocessor has to read > and interpret every preprocessor directive (so that `#else' and > `#endif' can be recognized). I thought that the other discussion had concluded that: #if 0 ... #else Or: #if 0 ... #endif Should ignore everything *except* "#else" or "#elif" or "#endif"? I remember when GCC used to start "nethack" any time you used a "#pragma" in an unprotected block, but not otherwise... ;^). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: #warning must be protected by #if __GNUC__ in headers?
Craig Rodrigues wrote: > In , I see: > > #if __GNUC__ > #warning "No user-serviceable parts inside." > #endif > > Does the use of #warning need to be protected by > #if __GNUC__ in FreeBSD header files? Yes. It is a preprocessor directive specific the GCC preprocessor. This was discussed in great detail about a month ago, when the people trying to get TenDRA to compile FreeBSD discovered to their horror that TenDRA's preprocessor incorrectly assigns meaning to code that's #if'ed out, and blew chunks on the #warning, when it should have ignored it. > Some other header files check for __GNUC__ before using #warning, > such as , but does not. is wrong. Please see the original discussion for more details. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Warning: driver mistake
Poul-Henning Kamp wrote: In message <[EMAIL PROTECTED]>, walt writes: Starting today I noticed this warning at bootup: WARNING: Driver mistake: make_dev(console) called before SI_SUB_DRIVERS Is there more info I should supply? Ooops. No, that is plenty. I'll fix it. Yes, fixed now. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Warning: driver mistake
In message <[EMAIL PROTECTED]>, walt writes: >Starting today I noticed this warning at bootup: >WARNING: Driver mistake: make_dev(console) called before SI_SUB_DRIVERS > >Is there more info I should supply? Ooops. No, that is plenty. I'll fix it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: #warning must be protected by #if __GNUC__ in headers?
Garance A Drosihn wrote: > At 2:33 PM -0500 3/8/03, Garance A Drosihn wrote: > > > >By adding that #warning, you are going to have a compile-time error > >on some compilers, whether or not you want it. Hiding it inside of > >an #if/#endif will help for some compilers, but not on all of them. > > Er, I should note that I do like the idea of using #warnings for > some things. All I meant to say was that I would not waste my time > putting it inside of a #if __GNUC__. GNUC is not the only compiler > which understands it, and for some of the compilers which do not > understand it, you're still going to get a compile-time error even > if it's inside that #if/#endif. That's a problem, #warning is not supposed to give a compile-time error but a compile-time warning. The point is moot for the kernel where we use -Werror, but it's very valid for userland. > By putting it inside #if __GNUC__, > you're just confusing things by making it look like the warning > itself is *because of* GCC. Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: #warning must be protected by #if __GNUC__ in headers?
At 2:33 PM -0500 3/8/03, Garance A Drosihn wrote: By adding that #warning, you are going to have a compile-time error on some compilers, whether or not you want it. Hiding it inside of an #if/#endif will help for some compilers, but not on all of them. Er, I should note that I do like the idea of using #warnings for some things. All I meant to say was that I would not waste my time putting it inside of a #if __GNUC__. GNUC is not the only compiler which understands it, and for some of the compilers which do not understand it, you're still going to get a compile-time error even if it's inside that #if/#endif. By putting it inside #if __GNUC__, you're just confusing things by making it look like the warning itself is *because of* GCC. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: #warning must be protected by #if __GNUC__ in headers?
At 10:48 AM -0800 3/8/03, Marcel Moolenaar wrote: On Sat, Mar 08, 2003 at 12:28:13PM -0500, Garrett Wollman wrote: > `#if __GNUC__' wouldn't help matters; every preprocessor has to > read and interpret every preprocessor directive (so that `#else' > and `#endif' can be recognized). I don't think preprocessors should interpret directives when they are dead (ie part of an #if block or #else block that is not to be compiled). I tried to use this once, on a cross-platform program I wrote. I can tell you that some compilers will choke on a #warning, even if it is inside a #if/#endif. And other compilers will choke on #warn, even if *it* is in a #if/#endif. (note: some compilers which do not recognize #warning will support #warn for the same thing). By adding that #warning, you are going to have a compile-time error on some compilers, whether or not you want it. Hiding it inside of an #if/#endif will help for some compilers, but not on all of them. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: #warning must be protected by #if __GNUC__ in headers?
On Sat, Mar 08, 2003 at 12:28:13PM -0500, Garrett Wollman wrote: > > `#if __GNUC__' wouldn't help matters; every preprocessor has to read > and interpret every preprocessor directive (so that `#else' and > `#endif' can be recognized). I don't think preprocessors should interpret directives when they are dead (ie part of an #if block or #else block that is not to be compiled). They should merely scan the block for #else, #endif and the likes to keep track of nesting, but should otherwise ignore anything it sees. For how does it matter if a directive is valid or invalid when you're not acting upon it anyway? One can even claim that emitting an error or warning *is* reaction upon the directive. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: #warning must be protected by #if __GNUC__ in headers?
On Sat, Mar 08, 2003 at 11:19:43AM -0500, Craig Rodrigues wrote: > Hi, > > In , I see: > > #if __GNUC__ > #warning "No user-serviceable parts inside." > #endif > > > Does the use of #warning need to be protected by > #if __GNUC__ in FreeBSD header files? I am working > on something similar for . I think the use of #warning should be protected against abuse :-) In general I probably would opt to not protect it with #if __GNUC__ because #warning is not specific to gcc and since we're only compiling with gcc (officially) it's better to have it fail when somebody does use a different compiler. I think the discussion that it will trigger will yield a less gratuitous convention. Possibly documented. YMMV. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: #warning must be protected by #if __GNUC__ in headers?
In the last episode (Mar 08), Garrett Wollman said: > On Sat, 8 Mar 2003 11:19:43 -0500, Craig Rodrigues <[EMAIL PROTECTED]> said: > > Does the use of #warning need to be protected by > > #if __GNUC__ in FreeBSD header files? > > No, it needs to be replaced by the standard `#error' directive > instead. I asked portmgr to do a run on the portsd cluster with this > change to look for ports that mistakenly include this file, but I > never heard back and portmgr is now busy doing the packages for 4.8. > > `#if __GNUC__' wouldn't help matters; every preprocessor has to read > and interpret every preprocessor directive (so that `#else' and > `#endif' can be recognized). This was discussed on the tendra list, and it was determined that the preprocessor should not complain about unknown directives at all and should pass them unchanged to the compiler. http://lists.tendra.org/tendra-dev/20021215/msg5.html If the #warning directive is wrapped with an appropriate #if SOMETHING conditional to hide it from compilers that do not understand it, it should be okay. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Warning messages emitted by disklabel -r
In message: <[EMAIL PROTECTED]> Vallo Kallaste <[EMAIL PROTECTED]> writes: : partition c: partition extends past end of unit : Warning, partition c doesn't start at 0! : Warning, An incorrect partition c may cause problems for standard system utilities : partition e: partition extends past end of unit I reported these to phk, and he said he'd fix it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Warning messages emitted by disklabel -r
On Mon, 18 Nov 2002, Vallo Kallaste wrote:
> On Mon, Nov 18, 2002 at 01:00:37PM -0800, Julian Elischer
> <[EMAIL PROTECTED]> wrote:
>
> [snip]
> > In pre-geom days we had a "realhack" (TM) that would fiddle the
> > label if you read it direct from the disk. In other words
> > it "fixed" it to always look (u relative I think) even if you
> > read it from the raw disk, even if it was in absolute form on the disk.
> >
> > Geom (quite correctly) declared this to be a "gross hack" that it would
> > not perpetuate. As a result, when you read the raw label you see the
> > "uncorrected version". It's possible that disklabel itself
> > should be extended to figure out if the label is absolute of relative
> > and DTRT.
>
> Ok, seems not to be over my head. It's confusing to users, that's
> the only thing I have to say now. Thank you for explanation.0
Geom has some hacks to cope with this..
namely:
in geom_bsd.c:
/*
* For reasons which were valid and just in their days, FreeBSD/i386 uses
* absolute disk-addresses in disklabels. The way it works is that the
* p_offset field of all partitions have the first sector number of the
* disk slice added to them. This was hidden kernel-magic, userland did
* not see these offsets. These two functions subtract and add them
* while converting from the "ondisk" to the "inram" labels and vice
* versa.
*/
static void
ondisk2inram(struct g_bsd_softc *sc)
{
[...]
however I have not (so far) seen any code to intercept direct reads
also there is a posibility (I have not checked enough yet) that
MAYBE teh ondisk2inram should modify the device size as well.
It currently modifies just the partition starts.
> --
>
> Vallo Kallaste
> [EMAIL PROTECTED]
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Warning messages emitted by disklabel -r
On Mon, Nov 18, 2002 at 01:00:37PM -0800, Julian Elischer <[EMAIL PROTECTED]> wrote: [snip] > In pre-geom days we had a "realhack" (TM) that would fiddle the > label if you read it direct from the disk. In other words > it "fixed" it to always look (u relative I think) even if you > read it from the raw disk, even if it was in absolute form on the disk. > > Geom (quite correctly) declared this to be a "gross hack" that it would > not perpetuate. As a result, when you read the raw label you see the > "uncorrected version". It's possible that disklabel itself > should be extended to figure out if the label is absolute of relative > and DTRT. Ok, seems not to be over my head. It's confusing to users, that's the only thing I have to say now. Thank you for explanation.0 -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Warning messages emitted by disklabel -r
On Mon, 18 Nov 2002, Vallo Kallaste wrote: > On Mon, Nov 18, 2002 at 11:23:14AM -0800, Julian Elischer > <[EMAIL PROTECTED]> wrote: > > > what are the warnings? > > what version of disklabel.c? > > Here's script output: > > Script started on Mon Nov 18 21:46:07 2002 [...] > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > start 63, size 8899947 (4345 Meg), flag 80 (active) > beg: cyl 0/ head 1/ sector 1; > end: cyl 553/ head 254/ sector 63 > bash-2.05b# disklabel da1s1 [...] > # /dev/da1s1c: [...] > sectors/unit: 8899947 [...] > > 8 partitions: > #size offsetfstype [fsize bsize bps/cpg] > c: 88999470unused0 0 # (Cyl.0 - 553*) > e: 889994704.2BSD0 0 0 # (Cyl.0 - 553*) > bash-2.05b# disklabel -r da1s1 > # /dev/da1s1c: [...] > sectors/unit: 8899947 [...] > > 8 partitions: > #size offsetfstype [fsize bsize bps/cpg] > c: 8899947 63unused0 0 # (Cyl.0*- 553*) > e: 8899947 634.2BSD0 0 0 # (Cyl.0*- 553*) > partition c: partition extends past end of unit > Warning, partition c doesn't start at 0! > Warning, An incorrect partition c may cause problems for standard system utilities > partition e: partition extends past end of unit > bash-2.05b# ident /usr/src/lib/libc/gen/disklabel.c > /usr/src/lib/libc/gen/disklabel.c: > $FreeBSD: src/lib/libc/gen/disklabel.c,v 1.16 2002/08/16 15:33:20 bmilekic Exp $ This is only for reading /etc/disktab. > bash-2.05b# ident /usr/src/sbin/disklabel/disklabel.c > /usr/src/sbin/disklabel/disklabel.c: > $NetBSD: disksubr.c,v 1.13 2000/12/17 22:39:18 pk $ > $FreeBSD: src/sbin/disklabel/disklabel.c,v 1.63 2002/11/18 04:58:11 julian Exp $ ok so it's new.. I assume this is what you compiled into disklabel. The problem is basically from historical confusion.. When 386BSD first came out, the disklabel was in absolute blocknumbers. looking nback at it we should have fixed this ages ago with a flag but I digress. The only way to access hte whole physical disk was via teh 'd' partition which was 'magic' and covered the entire device. this meant that the blocknumbers needed to be absolute. After a while it became possible to access the physical drive directly using (say) /dev/ad0 or /dev/da0 so teh 'd'partition "went away". At this point we should have defined a flag to say that the disklabel was "relative" to whatever partition it was in, but we didn't. this measn that we can not tell teh differenc from looking at it if the partition is relative or absolute.. In pre-geom days we had a "realhack" (TM) that would fiddle the label if you read it direct from the disk. In other words it "fixed" it to always look (u relative I think) even if you read it from the raw disk, even if it was in absolute form on the disk. Geom (quite correctly) declared this to be a "gross hack" that it would not perpetuate. As a result, when you read the raw label you see the "uncorrected version". It's possible that disklabel itself should be extended to figure out if the label is absolute of relative and DTRT. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Warning messages emitted by disklabel -r
On Mon, Nov 18, 2002 at 11:23:14AM -0800, Julian Elischer <[EMAIL PROTECTED]> wrote: > what are the warnings? > what version of disklabel.c? Here's script output: Script started on Mon Nov 18 21:46:07 2002 bash-2.05b# dd if=/dev/zero of=/dev/da1 bs=1k count=512 512+0 records in 512+0 records out 524288 bytes transferred in 0.532715 secs (984181 bytes/sec) bash-2.05b# fdisk -I da1 *** Working on device /dev/da1 *** fdisk: invalid fdisk partition table found bash-2.05b# fdisk da1 *** Working on device /dev/da1 *** parameters extracted from in-core disklabel are: cylinders=554 heads=255 sectors/track=63 (16065 blks/cyl) parameters to be used for BIOS calculations are: cylinders=554 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 8899947 (4345 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 553/ head 254/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: bash-2.05b# disklabel -rw da1s1 auto bash-2.05b# disklabel -e da1s1 [output stripped intentionally] bash-2.05b# disklabel da1s1 # /dev/da1s1c: type: SCSI disk: da1s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 553 sectors/unit: 8899947 rpm: 7200 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 88999470unused0 0 # (Cyl.0 - 553*) e: 889994704.2BSD0 0 0 # (Cyl.0 - 553*) bash-2.05b# disklabel -r da1s1 # /dev/da1s1c: type: SCSI disk: da1s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 553 sectors/unit: 8899947 rpm: 7200 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 8899947 63unused0 0 # (Cyl.0*- 553*) e: 8899947 634.2BSD0 0 0 # (Cyl.0*- 553*) partition c: partition extends past end of unit Warning, partition c doesn't start at 0! Warning, An incorrect partition c may cause problems for standard system utilities partition e: partition extends past end of unit bash-2.05b# ident /usr/src/lib/libc/gen/disklabel.c /usr/src/lib/libc/gen/disklabel.c: $FreeBSD: src/lib/libc/gen/disklabel.c,v 1.16 2002/08/16 15:33:20 bmilekic Exp $ bash-2.05b# ident /usr/src/sbin/disklabel/disklabel.c /usr/src/sbin/disklabel/disklabel.c: $NetBSD: disksubr.c,v 1.13 2000/12/17 22:39:18 pk $ $FreeBSD: src/sbin/disklabel/disklabel.c,v 1.63 2002/11/18 04:58:11 julian Exp $ bash-2.05b# exit exit Script done on Mon Nov 18 21:49:08 2002 -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Warning messages emitted by disklabel -r
On Mon, 18 Nov 2002, Vallo Kallaste wrote: > Hi > > Just did the following: > dd if=/dev/zero of=/dev/da1 bs=1k count=512 #remove old stuff > fdisk -I da1#cover the entire disk with one da1s1 slice > fdisk da1 #check what's put there > disklabel -rw da1s1 auto#install virgin disklabel > disklabel -e da1s1 #add partition e:, copied over from c: > disklabel da1s1 #all is ok > disklabel -r da1s1 #spits out 4 lines of warnings?? > > Why disklabel complains when using the -r switch? It didn't before. > Yes I haven't used fdisk(8) and disklabel(8) for a long time. > Possibly related to GEOM, as far as I understand. what are the warnings? what version of disklabel.c? > -- > > Vallo Kallaste > [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: Re: Kernel option dependency finding
Try this then:
#!/bin/sh
#Default options
LINTCONF=LINT.CONF
LINTCONF1=LINT.CONF1
ARCH=`uname -m`
ARCH1=$ARCH
SRCDIR=/sys
START=0
END=0
NOCLEAN=0
TMPDIR=/tmp/makedepend
WD=`pwd`
#Read the command line
while [ $# -ne 0 ]
do
case "$1" in
--src-dir)
shift
SRCDIR=$1
shift
;;
--conf-dir)
shift
CNFDIR=$1
shift
;;
--compile-dir)
shift
CMPDIR=$1
shift
;;
--arch)
shift
ARCH=$1
shift
;;
--no-copy)
NOCOPY="YES"
shift
;;
--no-clean)
shift
NOCLEAN=1
;;
--start)
shift
START=$1
shift
;;
--end)
shift
END=$1
shift
;;
--clean)
rm -f ${LINTCONF} ${LINTCONF1} bad_list LINT tmp
exit 0
;;
*)
CMD=`basename $0`
echo "USAGE: $CMD [option]"
echo
echo "Where option is any of:"
echo
echo "--help"
echo " This help"
echo "--clean"
echo " Clean the work directory"
echo "--no-clean"
echo " Don't clean up"
echo "--src-dir :"
echo " The top of the kernel source default: /sys"
echo "--conf-dir :"
echo " The conf files dir default: //conf"
echo "--compile-dir :"
echo " The dir the kernel to run make [depend] in default:
/compile"
echo "--arch :"
echo " The Arch to build for default: $ARCH1"
echo "--start "
echo "--end "
echo " Only build kernels numbered between and "
exit 1
;;
esac
done
# Move the options in the order we wan't them
# This script builds in a decending order so $START is always larger
then $END
if [ $START -lt $END ]
then
STARTTMP=$START
START=$END
END=$STARTTMP
fi
# If we change end then finish on the one we said to
if [ $END -ne 0 ]
then
END=`expr $END - 1`
fi
# Set the default dir for running make
COMPDIR=$SRCDIR/$ARCH/compile
# If is set as an option change it
if [ $CMPDIR ]
then
COMPDIR=$CMPDIR
fi
# Set the default dir for the config files
CONFDIR=$SRCDIR/$ARCH/conf
# If is set as an option change it
if [ $CNFDIR ]
then
CONFDIR=$CNFDIR
fi
# Clean the build directories
if [ $NOCLEAN -eq 0 ]
then
rm -f ${LINTCONF} ${LINTCONF1} bad_list LINT tmp
rm -f ${CONFDIR}/DEPEND.*
rm -fr ${TMPDIR}
mkdir -p ${TMPDIR}
touch ${TMPDIR}/pass
touch ${TMPDIR}/fail.config
touch ${TMPDIR}/fail.depend
touch ${TMPDIR}/fail.make
fi
# Do the copying on LINT/NOTES
if [ $NOCOPY ]
then
:
else
cd ${CONFDIR}
make LINT
cd $WD
cp ${CONFDIR}/LINT ./
fi
if [ -f LINT ]
then
:
else
echo "Error: No LINT/NOTES File"
exit 1
fi
if [ -f depend ]
then
:
else
touch depend
fi
# The changeable Config Options from LINT/NOTES
cat LINT | grep "^options" > ${LINTCONF}
cat LINT | grep "^device" >> ${LINTCONF}
cat LINT | grep "^pseudo-device" >> ${LINTCONF}
# Make a list of unwanted options
# The first character is always a !
awk '{ if ($1 =="!") print $2 " " $3 }' < depend > bad_list
# Remove the unwanted options
BADLINES=`awk '{ nlines++ } END { if ( nlines ) { print nlines } else {
print "0" } }' < bad_list`
while [ ${BADLINES} -ne 0 ]
do
LINE=`cat bad_list | head -n ${BADLINES} | tail -n 1`
BADTYPE=`echo ${LINE} | awk '{print $1}'`
BADDEV=`echo ${LINE} | awk '{print $2}'`
cat ${LINTCONF} | awk "{ if ((\$1 == \"$BADTYPE\") && (\$2 ~
\"$BADDEV\")) { } else { print \$0 } }" > ${LINTCONF}2
mv ${LINTCONF}2 ${LINTCONF}
BADLINES=`expr $BADLINES - 1`
done
rm -f bad_list
# Unchangable Config Options from LINT/NOTES
cat LINT | grep "^ident" > ${LINTCONF1}
cat LINT | grep "^machine" >> ${L
Re: WARNING: Re: Kernel option dependency finding
Juli Mallett wrote: > > >find_dependcyType: application/x-java-applet [ ... ] > It's a bourne shell script, terry, try looking at it. Then the MIME type is wrong. Certainly, the disposition "inline" is wrong. I've been bombarded with all sorts of crap like this lately which were DDOS client install bootstraps. It's an honest mistake. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: Re: Kernel option dependency finding
* De: Terry Lambert <[EMAIL PROTECTED]> [ Data: 2002-10-16 ] [ Subjecte: WARNING: Re: Kernel option dependency finding ] > Andrew Turner wrote: > > > > Name: find_dependcy > >find_dependcyType: application/x-java-applet > > Encoding: base64 > > This posting is a Java applet with inline disposition. Do not open > it. It's a bourne shell script, terry, try looking at it. -- Juli Mallett <[EMAIL PROTECTED]> | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pax fix (was Re: WARNING! New GNU Tar in 5-CURRENT could erroneously create world writeable dirs)
On Wed, Jun 12, 2002 at 04:27:19AM +0200, Cyrille Lefevre wrote: [...] > already done using the NetBSD way. the problem is that they use > LC_TIME (hugh!) to pass the format string to strftime while > LC_TIME isn't suppose to contain any format strings but a locale > name. Ew! That won't work for my needs. > I'm not sure that adding a yet another non portable option would > be good. how about using env var PAX_TIMEFMT instead ? PAX_TIMEFMT would be fine. Does it already exist? Björn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pax fix (was Re: WARNING! New GNU Tar in 5-CURRENT could erroneously create world writeable dirs)
On Wed, Jun 12, 2002 at 03:07:45AM +0200, Bjoern Fischer wrote: > > PS : I've finished to merge diffs from OpenBSD last week, but diffs > > w/ NetBSD are really big... so, be patient :P > > What about bin/35886? already done using the NetBSD way. the problem is that they use LC_TIME (hugh!) to pass the format string to strftime while LC_TIME isn't suppose to contain any format strings but a locale name. so, I don't know yet how to handle this case. whatever, I'm not sure that adding a yet another non portable option would be good. how about using env var PAX_TIMEFMT instead ? something is missing in the SUSV3 standard. -o can't be use for reading (not extracting -- aka no -r nor -w) archive. in other way, I would like to say something like this : pax -o freebsd.timefmt=... -f archive but I can't w/o breaking the standard! grrr. search for the VENDOR keyword in the the following URL for details : http://www.opengroup.org/onlinepubs/007904975/utilities/pax.html Cyrille. -- Cyrille Lefevre mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pax fix (was Re: WARNING! New GNU Tar in 5-CURRENT could erroneously create world writeable dirs)
> PS : I've finished to merge diffs from OpenBSD last week, but diffs > w/ NetBSD are really big... so, be patient :P What about bin/35886? Björn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pax fix (was Re: WARNING! New GNU Tar in 5-CURRENT could erroneouslycreate world writeable dirs)
On Jun 7, 2002 01:27:31 pm +0200, Cyrille Lefevre wrote: > On Fri, Jun 07, 2002 at 02:15:09AM -0400, Trevor Johnson wrote: > > Dan Nelson wrote: > [snip] > > According to Mr. Schilling's testing, GNU tar 1.13.25 has a bug: > > ftp://ftp.fokus.gmd.de/pub/unix/star/testscripts/README.gtarfail . I guess > > it qualifies as a "non-trivial program". :-) > > FYI, the current pax implementation is able to handle the following > archives from ftp://ftp.fokus.gmd.de/pub/unix/star/testscripts/ : > > 100char_longlink.tar > gtarfail.tar > gtarfail2.tar > > but miserably fail on this one : > > long.ustar.gz > > $ uname -a > FreeBSD gits 4.6-RC FreeBSD 4.6-RC #7: Sun Jun 2 16:33:05 CEST 2002 >root@gits:/disk2/4.x-stable/src/sys/compile/CUSTOM i386 > $ pax -zvf > -rw-r--r-- 1 486 cvs4 Apr 19 2000 ___ > ___D_099 > /___ > __100644 746 0003720 004 07077317140 0055507 0 > > $ star -zvtf > 4 -rw-r--r-- jes/cats Apr 19 13:54 2000 __ > D_099/__ > > ___100 > > I'll try to fix this... done, here is the patch which may be integrated to 4.6 -release ? Index: /tmp/src/bin/pax/tar.c === RCS file: /home/ncvs/src/bin/pax/tar.c,v retrieving revision 1.19 diff -u -r1.19 tar.c --- /tmp/src/bin/pax/tar.c 16 May 2002 01:57:13 - 1.19 +++ /tmp/src/bin/pax/tar.c 11 Jun 2002 23:39:16 - @@ -758,7 +758,7 @@ *dest++ = '/'; cnt++; } - arcn->nlen = cnt + l_strncpy(dest, hd->name, sizeof(arcn->name) - cnt); + arcn->nlen = cnt + l_strncpy(dest, hd->name, MIN(TNMSZ + 1, sizeof(arcn->name) +- cnt) - 1); arcn->name[arcn->nlen] = '\0'; /* PS : I've finished to merge diffs from OpenBSD last week, but diffs w/ NetBSD are really big... so, be patient :P Cyrille. -- Cyrille Lefevre mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING! New GNU Tar in 5-CURRENT could erroneously create world writeable dirs
On Fri, Jun 07, 2002 at 02:15:09AM -0400, Trevor Johnson wrote: > Dan Nelson wrote: [snip] > According to Mr. Schilling's testing, GNU tar 1.13.25 has a bug: > ftp://ftp.fokus.gmd.de/pub/unix/star/testscripts/README.gtarfail . I guess > it qualifies as a "non-trivial program". :-) FYI, the current pax implementation is able to handle the following archives from ftp://ftp.fokus.gmd.de/pub/unix/star/testscripts/ : 100char_longlink.tar gtarfail.tar gtarfail2.tar but miserably fail on this one : long.ustar.gz $ uname -a FreeBSD gits 4.6-RC FreeBSD 4.6-RC #7: Sun Jun 2 16:33:05 CEST 2002 root@gits:/disk2/4.x-stable/src/sys/compile/CUSTOM i386 $ pax -zvf -rw-r--r-- 1 486 cvs4 Apr 19 2000 ___ ___D_099 /___ __100644 746 0003720 004 07077317140 0055507 0 $ star -zvtf 4 -rw-r--r-- jes/cats Apr 19 13:54 2000 __ D_099/__ ___100 I'll try to fix this... Cyrille. -- Cyrille Lefevre mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING! New GNU Tar in 5-CURRENT could erroneously create world writeable dirs
On Fri, Jun 07, 2002 at 02:15:09AM -0400, Trevor Johnson wrote: > On my friend's BSD/OS system, there is no tar--or rather, it's just a hard > link to pax: > > % ls -li `which tar` `which pax` > 1819 -r-xr-xr-x 2 bin bin 58288 Jun 12 1998 /bin/pax > 1819 -r-xr-xr-x 2 bin bin 58288 Jun 12 1998 /bin/tar > > Their tar/pax hybrid must check its argv[0]. Isn't that evil? So does ours..try it sometime :) Kris msg39302/pgp0.pgp Description: PGP signature
Re: WARNING! New GNU Tar in 5-CURRENT could erroneously create worldwriteable dirs
Dan Nelson wrote: > > The latest version on ftp://ftp.gnu.org/gnu/tar/ is 1.13. The ones on > > ftp://alpha.gnu.org/gnu/tar/ (and everything else on that site) are > > considered unstable. I suppose it's too late to suggest tar 1.13 as a > > starting point, but maybe this could be kept in mind when importing other > > GNU products. The point I was trying to make is perhaps better conveyed by ftp://alpha.gnu.org/README . > Tar 1.13 is 3 years old, and has many bugs (incremental backups are > unusable, for example). I don't know why the GNU tar programmers decide that certain versions are stable and others are unstable. I do know that the former are found on ftp.gnu.org, and the latter on alpha.gnu.org. Now you know too, in case you didn't already. :-) I just discovered Jorg Schilling's "star" (http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/star.html) . He says that it supports POSIX.1-2001, which I assume dates from last year. It's available in the ports collection and it's under the GNU GPL. The documentation for GNU tar 1.13.25 says that it complies with POSIX 1003.1b, which was drafted in 1987 and completed in 1990. The GNU tar in FreeBSD-STABLE is from 1993 and it still works most of the time! According to Mr. Schilling's testing, GNU tar 1.13.25 has a bug: ftp://ftp.fokus.gmd.de/pub/unix/star/testscripts/README.gtarfail . I guess it qualifies as a "non-trivial program". :-) On my friend's BSD/OS system, there is no tar--or rather, it's just a hard link to pax: % ls -li `which tar` `which pax` 1819 -r-xr-xr-x 2 bin bin 58288 Jun 12 1998 /bin/pax 1819 -r-xr-xr-x 2 bin bin 58288 Jun 12 1998 /bin/tar Their tar/pax hybrid must check its argv[0]. Isn't that evil? -- Trevor Johnson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING! New GNU Tar in 5-CURRENT could erroneously create world writeable dirs
> > > > > Hi, > > > > I've just noticed that something wrong with the new tar in the base > > system (1.13.25) - when extracting some archives it creates 777 dirs, > > while permissions in the archive itself are OK (for example GNU make > > make-3.79.1.tar.gz - top level dir gets 777 as well as several > > other lowel level dirs). The issue is under investigation. > > Should be solved now. Stupid GNU folks for some reason decided that > when tar is executed as uid 0 then by default umask(2) should not be > applied to files and dirs being extracted. That said, anybody who runs 5.0-CURRENT with the new tar is advised to clean up all ports' WRKDIRs she might have, to avoid being trojaned by a local user. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING! New GNU Tar in 5-CURRENT could erroneously create world writeable dirs
Dan Nelson wrote: > Tar 1.13 is 3 years old, and has many bugs (incremental backups are > unusable, for example). On the flip side, I hear it respects the umask when running as root... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING! New GNU Tar in 5-CURRENT could erroneously create world writeable dirs
In the last episode (Jun 06), Trevor Johnson said: > > I've just noticed that something wrong with the new tar in the base > > system (1.13.25) - when extracting some archives it creates 777 dirs, > > while permissions in the archive itself are OK (for example GNU make > > make-3.79.1.tar.gz - top level dir gets 777 as well as several > > other lowel level dirs). The issue is under investigation. > > The latest version on ftp://ftp.gnu.org/gnu/tar/ is 1.13. The ones on > ftp://alpha.gnu.org/gnu/tar/ (and everything else on that site) are > considered unstable. I suppose it's too late to suggest tar 1.13 as a > starting point, but maybe this could be kept in mind when importing other > GNU products. Tar 1.13 is 3 years old, and has many bugs (incremental backups are unusable, for example). -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING! New GNU Tar in 5-CURRENT could erroneously create worldwriteable dirs
> I've just noticed that something wrong with the new tar in the base > system (1.13.25) - when extracting some archives it creates 777 dirs, > while permissions in the archive itself are OK (for example GNU make > make-3.79.1.tar.gz - top level dir gets 777 as well as several > other lowel level dirs). The issue is under investigation. The latest version on ftp://ftp.gnu.org/gnu/tar/ is 1.13. The ones on ftp://alpha.gnu.org/gnu/tar/ (and everything else on that site) are considered unstable. I suppose it's too late to suggest tar 1.13 as a starting point, but maybe this could be kept in mind when importing other GNU products. -- Trevor Johnson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING! New GNU Tar in 5-CURRENT could erroneously create world writeable dirs
> > Hi, > > I've just noticed that something wrong with the new tar in the base > system (1.13.25) - when extracting some archives it creates 777 dirs, > while permissions in the archive itself are OK (for example GNU make > make-3.79.1.tar.gz - top level dir gets 777 as well as several > other lowel level dirs). The issue is under investigation. Should be solved now. Stupid GNU folks for some reason decided that when tar is executed as uid 0 then by default umask(2) should not be applied to files and dirs being extracted. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: Driver mistake: destroy_dev on 154/0
In message <[EMAIL PROTECTED]> Nick Hibma writes: : Yes. I have no idea why phk has not done this. Because the asr driver maintainer has asserted a strong lock in the past and phk doesn't have an asr card. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: Driver mistake: destroy_dev on 154/0
On Wed, Oct 31, 2001 at 12:10:14AM +, Nick Hibma wrote: > > Yes. I have no idea why phk has not done this. > > As this is a purposeful panicing of systems that worked fine before, I > presume that someone is keeping track of the problems that are occurring > and going to do something about it? Or is this a bad case of 'someone > else's problem'? This was debated ad nausium over the weekend, with the end resulting being a Pay-Per-View deathmatch between phk and grog (to be held at the next Geek Wrestlemania so I hear). In this case, the change actually exposed a long-ignored bug in an *extremely* bogus piece of code in the asr driver. I've applied a Band-Aid to the driver until the author comes up with a suitable fix. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: Driver mistake: destroy_dev on 154/0
Yes. I have no idea why phk has not done this. As this is a purposeful panicing of systems that worked fine before, I presume that someone is keeping track of the problems that are occurring and going to do something about it? Or is this a bad case of 'someone else's problem'? Nick On Tue, 30 Oct 2001, John Baldwin wrote: > > On 30-Oct-01 Poul-Henning Kamp wrote: > > In message <000801c1617c$9599ad00$[EMAIL PROTECTED]>, Jan > > Stocker > > writes: > >>Ive updated the first time my system to current (Oct-28, with cvsup). After > >>a make > >>buildword and installworld, i made a new GENERIC kernel and copied the file > >>GENERIC.hints to /boot/device.hints and installed the new kernel. I ve > >>updated all files in /etc and remade all devices. Now a bootup hangs: > >> > >>a) The kernel is loading > >>b) acpi.ko is loading > >>c) "Pentium Pro MTRR support enable" > >>d) "WARNING: Driver mistake: destroy_dev on 154/0" > >> > >>next is a kernel panic "dont do that" > > > > Remove the asr driver from your kernel config until somebody > > fixes its use of destroy_dev() > > Maybe we should remove it from GENERIC? > > Warner, do you think we need an updating entry for this? > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: Driver mistake: destroy_dev on 154/0
On Tue, Oct 30, 2001 at 03:58:39PM -0700, Warner Losh wrote: > In message <[EMAIL PROTECTED]> John Baldwin writes: > : > : On 30-Oct-01 Poul-Henning Kamp wrote: > : > In message <000801c1617c$9599ad00$[EMAIL PROTECTED]>, Jan > : > Stocker > : > writes: > : >>Ive updated the first time my system to current (Oct-28, with cvsup). After > : >>a make > : >>buildword and installworld, i made a new GENERIC kernel and copied the file > : >>GENERIC.hints to /boot/device.hints and installed the new kernel. I ve > : >>updated all files in /etc and remade all devices. Now a bootup hangs: > : >> > : >>a) The kernel is loading > : >>b) acpi.ko is loading > : >>c) "Pentium Pro MTRR support enable" > : >>d) "WARNING: Driver mistake: destroy_dev on 154/0" > : >> > : >>next is a kernel panic "dont do that" > : > > : > Remove the asr driver from your kernel config until somebody > : > fixes its use of destroy_dev() > : > : Maybe we should remove it from GENERIC? > > Scott told me on IRC last night that he'd take care of the problem > today. If it isn't fixed by midnight, I'm commenting it out of GENERIC. To the best of my knowledge, the problem has been worked around for now. If the author doesn't provide a real fix soon, I'm going to be borrowing pkh's viking gear. Scott > > : Warner, do you think we need an updating entry for this? > > Yes. > > Warner > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: Driver mistake: destroy_dev on 154/0
In message <[EMAIL PROTECTED]> John Baldwin writes: : : On 30-Oct-01 Poul-Henning Kamp wrote: : > In message <000801c1617c$9599ad00$[EMAIL PROTECTED]>, Jan : > Stocker : > writes: : >>Ive updated the first time my system to current (Oct-28, with cvsup). After : >>a make : >>buildword and installworld, i made a new GENERIC kernel and copied the file : >>GENERIC.hints to /boot/device.hints and installed the new kernel. I ve : >>updated all files in /etc and remade all devices. Now a bootup hangs: : >> : >>a) The kernel is loading : >>b) acpi.ko is loading : >>c) "Pentium Pro MTRR support enable" : >>d) "WARNING: Driver mistake: destroy_dev on 154/0" : >> : >>next is a kernel panic "dont do that" : > : > Remove the asr driver from your kernel config until somebody : > fixes its use of destroy_dev() : : Maybe we should remove it from GENERIC? Scott told me on IRC last night that he'd take care of the problem today. If it isn't fixed by midnight, I'm commenting it out of GENERIC. : Warner, do you think we need an updating entry for this? Yes. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: Driver mistake: destroy_dev on 154/0
On 30-Oct-01 Poul-Henning Kamp wrote: > In message <000801c1617c$9599ad00$[EMAIL PROTECTED]>, Jan > Stocker > writes: >>Ive updated the first time my system to current (Oct-28, with cvsup). After >>a make >>buildword and installworld, i made a new GENERIC kernel and copied the file >>GENERIC.hints to /boot/device.hints and installed the new kernel. I ve >>updated all files in /etc and remade all devices. Now a bootup hangs: >> >>a) The kernel is loading >>b) acpi.ko is loading >>c) "Pentium Pro MTRR support enable" >>d) "WARNING: Driver mistake: destroy_dev on 154/0" >> >>next is a kernel panic "dont do that" > > Remove the asr driver from your kernel config until somebody > fixes its use of destroy_dev() Maybe we should remove it from GENERIC? Warner, do you think we need an updating entry for this? -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: Driver mistake: destroy_dev on 154/0
In message <000801c1617c$9599ad00$[EMAIL PROTECTED]>, Jan Stocker writes: >Ive updated the first time my system to current (Oct-28, with cvsup). After >a make >buildword and installworld, i made a new GENERIC kernel and copied the file >GENERIC.hints to /boot/device.hints and installed the new kernel. I ve >updated all files in /etc and remade all devices. Now a bootup hangs: > >a) The kernel is loading >b) acpi.ko is loading >c) "Pentium Pro MTRR support enable" >d) "WARNING: Driver mistake: destroy_dev on 154/0" > >next is a kernel panic "dont do that" Remove the asr driver from your kernel config until somebody fixes its use of destroy_dev() -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: Driver mistake: destroy_dev on 154/0
[EMAIL PROTECTED] (Jan Stocker) writes: > So whats on? Please refer to the Handbook, section 19.2.1.4, first paragraph. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: driver bpf should register devices with make_dev()
John Baldwin wrote: > > I already managed to test it locally here and commit the proper fix. > It was an order of operations bug due to the fact that ! is > evaluated before &. Ok, thanks! -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: driver bpf should register devices with make_dev()
On 02-Nov-00 Marcel Moolenaar wrote: > John Baldwin wrote: >> >> Quick question: Is this a problem for people _without_ DEVFS? > > That's a yes for me. > >> non-DEVFS case. Try this hackish patch: >> >> Index: bpf.c >> === >> RCS file: /usr/cvs/src/sys/net/bpf.c,v >> retrieving revision 1.68 >> diff -u -r1.68 bpf.c >> --- bpf.c 2000/10/09 14:19:09 1.68 >> +++ bpf.c 2000/11/02 20:26:09 >> @@ -363,7 +363,7 @@ >> */ >> if (d) >> return (EBUSY); >> - if (!dev->si_flags & SI_NAMED) >> + if (!devfs_present) >> make_dev(&bpf_cdevsw, minor(dev), UID_ROOT, GID_WHEEL, 0600, >> "bpf%d", dev2unit(dev)); >> MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK); >> >> Hmm. Or try doing changing it to this instead: >> >> if (dev->si_flags & SI_NAMED != 0) >> >> It could be an order of operations buglet. > > Give me a couple of days to play with it... I already managed to test it locally here and commit the proper fix. It was an order of operations bug due to the fact that ! is evaluated before &. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: driver bpf should register devices with make_dev()
> > Quick question: Is this a problem for people _without_ DEVFS? Poul > may have accidentally broke calling make_dev for the bpf device in the > non-DEVFS case. Try this hackish patch: Personally, I surely get it with DEVFS and I think I also got it when running without it. I will try the patch nonetheless... I'll be back. -- I believe the technical term is "Oops!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: driver bpf should register devices with make_dev()
John Baldwin wrote: > > Quick question: Is this a problem for people _without_ DEVFS? That's a yes for me. > non-DEVFS case. Try this hackish patch: > > Index: bpf.c > === > RCS file: /usr/cvs/src/sys/net/bpf.c,v > retrieving revision 1.68 > diff -u -r1.68 bpf.c > --- bpf.c 2000/10/09 14:19:09 1.68 > +++ bpf.c 2000/11/02 20:26:09 > @@ -363,7 +363,7 @@ > */ > if (d) > return (EBUSY); > - if (!dev->si_flags & SI_NAMED) > + if (!devfs_present) > make_dev(&bpf_cdevsw, minor(dev), UID_ROOT, GID_WHEEL, 0600, > "bpf%d", dev2unit(dev)); > MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK); > > Hmm. Or try doing changing it to this instead: > > if (dev->si_flags & SI_NAMED != 0) > > It could be an order of operations buglet. Give me a couple of days to play with it... -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: driver bpf should register devices with make_dev()
On 02-Nov-00 John Baldwin wrote: > > On 02-Nov-00 Marcel Moolenaar wrote: >> [EMAIL PROTECTED] wrote: >>> >>> > I get it as well. IIRC, it simply means that the bpf pseudo device needs >>> > to be updated, but is otherwise harmless. I forgot the details, but it's >>> > all in the mailinglist archives. Somewhere... :-) >>> >>> Anybody handling this, or anybody can give pointers as to what needs to be >>> done? >> >> I'm not aware someone is working on it. It doesn't look like it needs >> much work, but I don't know the details as I said. For pointers: mail >> archives. > > Quick question: Is this a problem for people _without_ DEVFS? Poul > may have accidentally broke calling make_dev for the bpf device in the > non-DEVFS case. Try this hackish patch: > > Index: bpf.c > === > RCS file: /usr/cvs/src/sys/net/bpf.c,v > retrieving revision 1.68 > diff -u -r1.68 bpf.c > --- bpf.c 2000/10/09 14:19:09 1.68 > +++ bpf.c 2000/11/02 20:26:09 > @@ -363,7 +363,7 @@ > */ > if (d) > return (EBUSY); > - if (!dev->si_flags & SI_NAMED) > + if (!devfs_present) > make_dev(&bpf_cdevsw, minor(dev), UID_ROOT, GID_WHEEL, 0600, > "bpf%d", dev2unit(dev)); > MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK); > > Hmm. Or try doing changing it to this instead: > > if (dev->si_flags & SI_NAMED != 0) > > It could be an order of operations buglet. Argh, that should be "== 0" not "!= 0". -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: driver bpf should register devices with make_dev()
On 02-Nov-00 Marcel Moolenaar wrote: > [EMAIL PROTECTED] wrote: >> >> > I get it as well. IIRC, it simply means that the bpf pseudo device needs >> > to be updated, but is otherwise harmless. I forgot the details, but it's >> > all in the mailinglist archives. Somewhere... :-) >> >> Anybody handling this, or anybody can give pointers as to what needs to be >> done? > > I'm not aware someone is working on it. It doesn't look like it needs > much work, but I don't know the details as I said. For pointers: mail > archives. Quick question: Is this a problem for people _without_ DEVFS? Poul may have accidentally broke calling make_dev for the bpf device in the non-DEVFS case. Try this hackish patch: Index: bpf.c === RCS file: /usr/cvs/src/sys/net/bpf.c,v retrieving revision 1.68 diff -u -r1.68 bpf.c --- bpf.c 2000/10/09 14:19:09 1.68 +++ bpf.c 2000/11/02 20:26:09 @@ -363,7 +363,7 @@ */ if (d) return (EBUSY); - if (!dev->si_flags & SI_NAMED) + if (!devfs_present) make_dev(&bpf_cdevsw, minor(dev), UID_ROOT, GID_WHEEL, 0600, "bpf%d", dev2unit(dev)); MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK); Hmm. Or try doing changing it to this instead: if (dev->si_flags & SI_NAMED != 0) It could be an order of operations buglet. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: driver bpf should register devices with make_dev() (dev_t="#bpf/0")
[EMAIL PROTECTED] wrote: > > > I get it as well. IIRC, it simply means that the bpf pseudo device needs > > to be updated, but is otherwise harmless. I forgot the details, but it's > > all in the mailinglist archives. Somewhere... :-) > > Anybody handling this, or anybody can give pointers as to what needs to be > done? I'm not aware someone is working on it. It doesn't look like it needs much work, but I don't know the details as I said. For pointers: mail archives. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
