Re: Missing in action during arm64/aarch64 builds: no pine64_plus.dtb to be found from buildkernel, installkernel, or u-boot-pine64

2017-09-10 Thread Tim Kientzle

> On Sep 9, 2017, at 4:35 PM, Mark Millard  wrote:
> 
> crochet goes to the trouble to have logic to
> build and install pine64_plus.dtb (based on
> arm64/pine64_plus.dts ).
> 

I'm not sure about Pine64 in particular, but generally
only the DTS file is actually required.

Crochet tries to provide a dtb file (converting the dts if necessary)
partly for documentation and partly to make it easier to edit the
device tree file.

This is especially convenient in cases where the
original DTB file depends heavily on other include files;
converting DTS to DTB gives you a fully standalone DTB
file that can be edited (for example, to enable additional
serial ports) and recompiled without having the full source
tree available.

This is probably less important now that overlay DTBs are
more commonly supported.

Tim




___
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: firefox/ rust failed to install on FreeBSD 12-CURRENT

2017-06-03 Thread Tim Kientzle

> On Jun 1, 2017, at 11:37 PM, Jean-Sébastien Pédron  
> wrote:
> 
> On 28.05.2017 19:21, blubee blubeeme wrote:
>> ===>  Building for rust-1.17.0
>> ...
>>  extracting
>> rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd/lib/GNUSparseFile.0/librustc_llvm-74a1be1110b5d4d0.so
>> gmake[7]: Leaving directory '/usr/ports/lang/rust/work/rustc-1.17.0-src'
>> *** Error code 1
> 
> Hi!
> 
> This failure is caused by Python 2's tarfile module not supporting
> sparse files in archives. Python 3 supports them but the configure
> script insists on using Python 2.
> 
> Before a proper fix is committed, you can change the following line in
> lang/rust/Makefile:
> https://github.com/freebsd/freebsd-ports/blob/master/lang/rust/Makefile#L159
> 
> to say (this is a single line):
> gtar -c -C ${WRKSRC} -f -
> rust-std-1.16.0-${RUST_ARCH_${ARCH}}-unknown-freebsd | gzip >
> ${WRKSRC}/rustc.tbz

You could add --format=ustar to the existing command line; that would force 
bsdtar to use the older "ustar" format (without any extensions that might 
confuse Python's tar file module).


> Then, change the following line:
> https://github.com/freebsd/freebsd-ports/blob/master/lang/rust/Makefile#L34
> 
> to say:
> BUILD_DEPENDS= cmake:devel/cmake \
>   gtar:archivers/gtar
> 
> This will use GNU tar instead of BSD tar to recreate the bootstrap and
> GNU tar doesn't seem to produce sparse file entries in the archive.

How ironic; using GNU tar in order to avoid having GNU sparse file entries.  ;-)

Tim


___
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: buildworld: /usr/bin/ar segfault

2016-06-03 Thread Tim Kientzle

> On Jun 3, 2016, at 10:23 AM, Eric van Gyzen  wrote:
> 
> My buildworld just failed very early with a segfault from /usr/bin/ar:
> 
>--
 stage 1.1: legacy release compatibility shims
>--
>...
>--- libegacy.a ---
>building static egacy library
>ar -crD libegacy.a `NM='nm' NMFLAGS='' lorder dummy.o  | tsort -q`
>Segmentation fault (core dumped)
>*** [libegacy.a] Error code 139
> 
> 
> In __archive_write_allocate_filter(), a->filter_last was pointing to
> archive_write_ar_header().  a->format_write_header should have pointed
> to this function.  The offset between these two fields in struct archive
> is 48 bytes.  Sure enough, that structure recently grew by 48 bytes.
> 
> This would seem to indicate that ar (or libarchive.a) was built with
> mismatched objects.  Unfortunately, I don't have good records of what
> build options and flags I used.  I /think/ I used either
> -DWITH_SYSTEM_COMPILER or no options at all.

The build of 'ar' shouldn't matter since it's a client of libarchive
and libarchive clients do not ever see or manipulate the internals of
struct archive_write.

The problem would be with the build of the libarchive library.
It sounds like you somehow had a stale archive_write_set_format_ar.o
that did not get rebuilt when archive_write_private.h got updated recently.

If you still have the /usr/obj tree around, could you check the dates on these
files:
   archive_write_set_format_ar.o (in /usr/obj)
   archive_write_private.h (in /usr/src)

If those dates are in the wrong order (the .o should be newer), then
the make definitely went awry somewhere.

Tim

___
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: pkg chroot issues?

2016-05-29 Thread Tim Kientzle

> On May 29, 2016, at 8:55 AM, Julian Elischer  wrote:
> 
> I was thinking that in order to do this properly the chrooted child should do 
> all it's fetch requests etc via the non-chrooted parent, but that would have 
> probably been a bit too complicated. (including add requests)

How complex would it be to perform all of the fetch requests before chroot?

Tim

___
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: pkg chroot issues?

2016-05-22 Thread Tim Kientzle

> On May 22, 2016, at 1:28 PM, K. Macy <km...@freebsd.org> wrote:
> 
> 
> 
> On Sunday, May 22, 2016, Tim Kientzle <t...@kientzle.com> wrote:
> Crochet has some experimental hooks to install packages onto the system being 
> built, but this seems to be hitting problems due to limitations in 'pkg -c'.  
> In particular, it seems that pkg performs the chroot before it does any 
> network lookups.  This is a problem if the chroot is not a complete system 
> environment (which it cannot be when you're building an image for another 
> system).
> 
> There's some further discussion on github:
> 
>   https://github.com/freebsd/crochet/issues/141
> 
> Any suggestions?
> 
> Cheers,
> 
> Tim
> 
> 
> Just like you need to mount devfs you should have a resolv.conf in your 
> chroot first. Just copy it over before running pkg. This works for me in my 
> image creation script.

Sometimes the image does already have a resolv.conf, but if it does, it's for 
the target environment (where the image will ultimately be running) and may not 
be appropriate for the environment where the image is being built.

Tim


___
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"


pkg chroot issues?

2016-05-22 Thread Tim Kientzle
Crochet has some experimental hooks to install packages onto the system being 
built, but this seems to be hitting problems due to limitations in 'pkg -c'.  
In particular, it seems that pkg performs the chroot before it does any network 
lookups.  This is a problem if the chroot is not a complete system environment 
(which it cannot be when you're building an image for another system).

There's some further discussion on github:

  https://github.com/freebsd/crochet/issues/141

Any suggestions?

Cheers,

Tim

___
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: libarchive update SVN r299529 breaks "ezjail update"

2016-05-15 Thread Tim Kientzle

Someone just pointed out that the change also affected cpio's -p pass-through 
mode.  That was not intentional.  I just accepted Martin's pull request to 
revert the behavior for -p mode.

Cheers,

Tim




> On May 15, 2016, at 9:16 AM, Ian Lepore  wrote:
> 
> On Sun, 2016-05-15 at 01:57 +0200, Martin Matuska wrote:
>> That switch is "--insecure" and is supported in all libarchive
>> versions
>> freebsd ever used.
>> 
> 
> Oh, well that will make handling the new version easier.  It doesn't
> change the fact that the new libarchive stuff will break long-working
> existing software, but at least it'll be easy to fix.
> 
> -- Ian
> 
>> 
>> On 15.05.2016 01:36, Ngie Cooper (yaneurabeya) wrote:
 On May 14, 2016, at 16:29, Martin Matuska  wrote:
 
 Ian, we are here talking about cpio, not libarchive. The flag in
 libarchive is not active by default.
 
 On 14.05.2016 22:08, Ian Lepore wrote:
> The real damage will happen to out-of-tree users.  I think this
> will
> impact our software updater for $work for example, and it has
> to work
> with both old and new versions of libarchive, and now the new
> version
> will require a flag that the old version will reject as
> unknown.
> 
> Ick.
>>> Ian’s comment was valid.. cpio doesn’t recognize the new switch on
>>> older versions, so something like cpio `cpio --help | grep --
>>> switch && echo switch` would need to be employed everywhere for
>>> backwards compatibility — ew.
>>> Thanks,
>>> -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"

___
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: libarchive update SVN r299529 breaks "ezjail update"

2016-05-14 Thread Tim Kientzle
Many people consider the traditional behavior to be a security risk, which is 
why this was changed.

FreeBSD is welcome to make --insecure the default on FreeBSD, but I'm reluctant 
to do that in the upstream libarchive project.

Tim


> On May 12, 2016, at 8:54 AM, Martin Matuska  wrote:
> 
> Looks like we have to remove line #174 from cpio/cpio.c:
> cpio->extract_flags |= ARCHIVE_EXTRACT_SECURE_NOABSOLUTEPATHS;
> 
> This breaks traditional cpio behavior.
> 
> Quoting Martin Matuska :
> 
>> Hi Michael, I have looked at the source and this is an intended change in 
>> 3.2.0.
>> 
>> An absolute path security check was added, cpio refuses to extract or copy 
>> over absolute paths. To do this anyway the "--insecure" flag must be used.
>> 
>> Here is the commit:
>> https://github.com/libarchive/libarchive/commit/59357157706d47c365b2227739e17daba3607526
>> 
>> Quoting Michael Butler :
>> 
>>> It seems that today's libarchive update breaks cpio's behaviour:
>>> 
>>> sudo ezjail-admin update -i -s /usr/src
>>> 
>>> [ .. ]
>>> 
>>> cd /usr/src/etc/..; install -o root -g wheel -m 444  COPYRIGHT
>>> /usr/local/jails/fulljail/
>>> install -o root -g wheel -m 444
>>> /usr/src/etc/../sys/i386/conf/GENERIC.hints
>>> /usr/local/jails/fulljail/boot/device.hints
>>> /usr/local/jails/basejail/bincpio: bin: Path is absolute: Unknown error: -1
>>> 
>>> /usr/local/jails/basejail/bin/catcpio: bin/cat: Path is absolute:
>>> Unknown error: -1
>>> 
>>> /usr/local/jails/basejail/bin/chflagscpio: bin/chflags: Path is
>>> absolute: Unknown error: -1
>>> 
>>> /usr/local/jails/basejail/bin/chiocpio: bin/chio: Path is absolute:
>>> Unknown error: -1
>>> 
>>> /usr/local/jails/basejail/bin/chmodcpio: bin/chmod: Path is absolute:
>>> Unknown error: -1
>>> 
>>> /usr/local/jails/basejail/bin/cpcpio: bin/cp: Path is absolute: Unknown
>>> error: -1
>>> 
>>> /usr/local/jails/basejail/bin/datecpio: bin/date: Path is absolute:
>>> Unknown error: -1
>>> 
>>> /usr/local/jails/basejail/bin/ddcpio: bin/dd: Path is absolute: Unknown
>>> error: -1
>>> 
>>> /usr/local/jails/basejail/bin/dfcpio: bin/df: Path is absolute: Unknown
>>> error: -1
>>> 
>>> /usr/local/jails/basejail/bin/domainnamecpio: bin/domainname: Path is
>>> absolute: Unknown error: -1
>>> [ .. etc. .. ]
>> 
>> 
>> 
>> Martin Matuska
>> FreeBSD committer
>> http://blog.vx.sk
> 
> 
> 
> Martin Matuska
> FreeBSD committer
> http://blog.vx.sk

___
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: libarchive update SVN r299529 breaks "ezjail update"

2016-05-14 Thread Tim Kientzle
A little history about this issue:

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2304


> On May 14, 2016, at 12:17 PM, Tim Kientzle <t...@kientzle.com> wrote:
> 
> Many people consider the traditional behavior to be a security risk, which is 
> why this was changed.
> 
> FreeBSD is welcome to make --insecure the default on FreeBSD, but I'm 
> reluctant to do that in the upstream libarchive project.
> 
> Tim
> 
> 
>> On May 12, 2016, at 8:54 AM, Martin Matuska <m...@freebsd.org> wrote:
>> 
>> Looks like we have to remove line #174 from cpio/cpio.c:
>> cpio->extract_flags |= ARCHIVE_EXTRACT_SECURE_NOABSOLUTEPATHS;
>> 
>> This breaks traditional cpio behavior.
>> 
>> Quoting Martin Matuska <m...@freebsd.org>:
>> 
>>> Hi Michael, I have looked at the source and this is an intended change in 
>>> 3.2.0.
>>> 
>>> An absolute path security check was added, cpio refuses to extract or copy 
>>> over absolute paths. To do this anyway the "--insecure" flag must be used.
>>> 
>>> Here is the commit:
>>> https://github.com/libarchive/libarchive/commit/59357157706d47c365b2227739e17daba3607526
>>> 
>>> Quoting Michael Butler <i...@protected-networks.net>:
>>> 
>>>> It seems that today's libarchive update breaks cpio's behaviour:
>>>> 
>>>> sudo ezjail-admin update -i -s /usr/src
>>>> 
>>>> [ .. ]
>>>> 
>>>> cd /usr/src/etc/..; install -o root -g wheel -m 444  COPYRIGHT
>>>> /usr/local/jails/fulljail/
>>>> install -o root -g wheel -m 444
>>>> /usr/src/etc/../sys/i386/conf/GENERIC.hints
>>>> /usr/local/jails/fulljail/boot/device.hints
>>>> /usr/local/jails/basejail/bincpio: bin: Path is absolute: Unknown error: -1
>>>> 
>>>> /usr/local/jails/basejail/bin/catcpio: bin/cat: Path is absolute:
>>>> Unknown error: -1
>>>> 
>>>> /usr/local/jails/basejail/bin/chflagscpio: bin/chflags: Path is
>>>> absolute: Unknown error: -1
>>>> 
>>>> /usr/local/jails/basejail/bin/chiocpio: bin/chio: Path is absolute:
>>>> Unknown error: -1
>>>> 
>>>> /usr/local/jails/basejail/bin/chmodcpio: bin/chmod: Path is absolute:
>>>> Unknown error: -1
>>>> 
>>>> /usr/local/jails/basejail/bin/cpcpio: bin/cp: Path is absolute: Unknown
>>>> error: -1
>>>> 
>>>> /usr/local/jails/basejail/bin/datecpio: bin/date: Path is absolute:
>>>> Unknown error: -1
>>>> 
>>>> /usr/local/jails/basejail/bin/ddcpio: bin/dd: Path is absolute: Unknown
>>>> error: -1
>>>> 
>>>> /usr/local/jails/basejail/bin/dfcpio: bin/df: Path is absolute: Unknown
>>>> error: -1
>>>> 
>>>> /usr/local/jails/basejail/bin/domainnamecpio: bin/domainname: Path is
>>>> absolute: Unknown error: -1
>>>> [ .. etc. .. ]
>>> 
>>> 
>>> 
>>> Martin Matuska
>>> FreeBSD committer
>>> http://blog.vx.sk
>> 
>> 
>> 
>> Martin Matuska
>> FreeBSD committer
>> http://blog.vx.sk
> 

___
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: libarchive update SVN r299529 breaks "ezjail update"

2016-05-12 Thread Tim Kientzle
If you could please open an issue at

   http://github.com/libarchive/libarchive

and include as much detail as you can, I’d appreciate it.

Cheers,

Tim


> On May 12, 2016, at 7:15 AM, Michael Butler  
> wrote:
> 
> It seems that today's libarchive update breaks cpio's behaviour:
> 
> sudo ezjail-admin update -i -s /usr/src
> 
> [ .. ]
> 
> cd /usr/src/etc/..; install -o root -g wheel -m 444  COPYRIGHT
> /usr/local/jails/fulljail/
> install -o root -g wheel -m 444
> /usr/src/etc/../sys/i386/conf/GENERIC.hints
> /usr/local/jails/fulljail/boot/device.hints
> /usr/local/jails/basejail/bincpio: bin: Path is absolute: Unknown error: -1
> 
> /usr/local/jails/basejail/bin/catcpio: bin/cat: Path is absolute:
> Unknown error: -1
> 
> /usr/local/jails/basejail/bin/chflagscpio: bin/chflags: Path is
> absolute: Unknown error: -1
> 
> /usr/local/jails/basejail/bin/chiocpio: bin/chio: Path is absolute:
> Unknown error: -1
> 
> /usr/local/jails/basejail/bin/chmodcpio: bin/chmod: Path is absolute:
> Unknown error: -1
> 
> /usr/local/jails/basejail/bin/cpcpio: bin/cp: Path is absolute: Unknown
> error: -1
> 
> /usr/local/jails/basejail/bin/datecpio: bin/date: Path is absolute:
> Unknown error: -1
> 
> /usr/local/jails/basejail/bin/ddcpio: bin/dd: Path is absolute: Unknown
> error: -1
> 
> /usr/local/jails/basejail/bin/dfcpio: bin/df: Path is absolute: Unknown
> error: -1
> 
> /usr/local/jails/basejail/bin/domainnamecpio: bin/domainname: Path is
> absolute: Unknown error: -1
> 
> [ .. etc. .. ]
> ___
> 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"

___
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: Consistent crash of BeagleBone kernel

2015-08-10 Thread Tim Kientzle

 On Aug 10, 2015, at 12:39 AM, Konstantin Belousov kostik...@gmail.com wrote:
 
 On Sun, Aug 09, 2015 at 05:24:13PM -0700, Tim Kientzle wrote:
 
 On Aug 9, 2015, at 11:10 AM, Konstantin Belousov kostik...@gmail.com 
 wrote:
 
 On Sun, Aug 09, 2015 at 10:53:20AM -0700, Tim Kientzle wrote:
 
 I suspect the LOR is new.
 
 It looks like the panic is occurring when WITNESS tries to print the 
 backtrace for the LOR.  I???m not familiar with that code; does it use the 
 kernel linker?
 
 
 It indeed locks the linker lock to resolve symbols. So it seems to be
 even more useful to make the linker lock recursive locally, then you
 should be able to see the backtrace for LOR.
 
 Changing the kld_sx lock to recursive, I now see a backtrace for the 
 ufs/kernel linker LOR.  Full trace pasted below.
 
 This is displayed just before the network interfaces; I suspect it???s being 
 triggered when my startup initializes the urtwn wireless adapter (which does 
 indeed load a number of kernel modules).
 
 lock order reversal:
 1st 0xc083ef40 kernel linker (kernel linker) @ 
 /Users/tim/projects/crochet/src-head/sys/kern/kern_linker.c:1030
 2nd 0xc2d63c94 ufs (ufs) @ 
 /Users/tim/projects/crochet/src-head/sys/kern/vfs_lookup.c:529
 The order, for which witness complained, is in fact the right order.
 The linker_load_module() function calls LINKER_LOAD_FILE() with the
 kld_sx locked, and linker itself locks module vnode.
 
 So there was something in your system which exposed the reversed order
 vnode-kld_sx before the action.  To catch it, keep the modification to
 mark kld_sx as recursive, but also add an item to the order_lists in
 the sys/kern/subr_witness.c like this:
   {kernel linker, lock_class_sx},
   {ufs, lock_class_lockmgr},
   {NULL, NULL}
 and watch were would it fire.

I’ll do this when I get back to that system next week.

I have a guess, though:  I noticed that the old bufwait/dirhash LOR is being 
triggered before this.  Could the backtrace from that be teaching Witness a 
bogus ufs - kld ordering?

Tim



___
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: Consistent crash of BeagleBone kernel

2015-08-09 Thread Tim Kientzle

 On Aug 8, 2015, at 11:47 PM, Konstantin Belousov kostik...@gmail.com wrote:
 
 On Sat, Aug 08, 2015 at 05:24:37PM -0700, Tim Kientzle wrote:
 I???m seeing the following crash quite consistently on r286438.  It looks 
 like the recent work on the kernel linker locking still has some issues.
 
 Any suggested workarounds?
 
 Tim
 
  log trace ===
 ...
 Starting file system checks:
 /dev/mmcsd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS
 /dev/mmcsd0s2a: clean, 7320851 free (179 frags, 915084 blocks, 0.0% 
 fragmentation)
 lock order reversal:
 1st 0xcd225040 bufwait (bufwait) @ 
 /Users/tim/projects/crochet/src-head/sys/kern/vfs_bio.c:3191
 2nd 0xc2e69400 dirhash (dirhash) @ 
 /Users/tim/projects/crochet/src-head/sys/ufs/ufs/ufs_dirhash.c:281
 ??? usual stack trace omitted ...
 Mounting local file systems:random: unblocking device.
 .
 ELF ldconfig path: /lib /usr/lib /usr/lib/compat
 Setting hostname: beaglebone.
 Setting up 
 harvesting:[HIGH_PERFORMANCE],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
 Feeding entropy:.
 lock order reversal:
 1st 0xc083ef40 kernel linker (kernel linker) @ 
 /Users/tim/projects/crochet/src-head/sys/kern/kern_linker.c:1030
 2nd 0xc2d63c94 ufs (ufs) @ 
 /Users/tim/projects/crochet/src-head/sys/kern/vfs_lookup.c:529
 KDB: stack backtrace:
 panic: _sx_xlock_hard: recursed on non-recursive sx kernel linker @ 
 /Users/tim/projects/crochet/src-head/sys/kern/kern_linker.c:552
 
 KDB: enter: panic
 [ thread pid 168 tid 100079 ]
 Stopped at  $d.7:   ldrbr15, [r15, r15, ror r15]!
 db bt
 Tracing pid 168 tid 100079 td 0xc30db6a0
 panic: _sx_xlock_hard: recursed on non-recursive sx kernel linker @ 
 /Users/tim/projects/crochet/src-head/sys/kern/kern_linker.c:552
 
 Without a backtrace it is too much work to guess what is going on there.
 You could mark the kld_sx as recursive in kern_linker.c:linker_init().
 Then either add a hack to kern_sx.c:sx_xlock_hard() to print the
 backtrace on the kld_sx recursion, or just hope that the LOR just before
 the panic is indicative.
 
 What is strange is that this is first report of the issue, the latest change
 to kern_linker.c was around a year ago.

I suspect the LOR is new.

It looks like the panic is occurring when WITNESS tries to print the backtrace 
for the LOR.  I’m not familiar with that code; does it use the kernel linker?

Tim

___
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: Consistent crash of BeagleBone kernel

2015-08-09 Thread Tim Kientzle

 On Aug 9, 2015, at 11:10 AM, Konstantin Belousov kostik...@gmail.com wrote:
 
 On Sun, Aug 09, 2015 at 10:53:20AM -0700, Tim Kientzle wrote:
 
 I suspect the LOR is new.
 
 It looks like the panic is occurring when WITNESS tries to print the 
 backtrace for the LOR.  I???m not familiar with that code; does it use the 
 kernel linker?
 
 
 It indeed locks the linker lock to resolve symbols. So it seems to be
 even more useful to make the linker lock recursive locally, then you
 should be able to see the backtrace for LOR.

Changing the kld_sx lock to recursive, I now see a backtrace for the ufs/kernel 
linker LOR.  Full trace pasted below.

This is displayed just before the network interfaces; I suspect it’s being 
triggered when my startup initializes the urtwn wireless adapter (which does 
indeed load a number of kernel modules).

lock order reversal:
 1st 0xc083ef40 kernel linker (kernel linker) @ 
/Users/tim/projects/crochet/src-head/sys/kern/kern_linker.c:1030
 2nd 0xc2d63c94 ufs (ufs) @ 
/Users/tim/projects/crochet/src-head/sys/kern/vfs_lookup.c:529
KDB: stack backtrace:
db_trace_self() at db_trace_self
 pc = 0xc0627ec0  lr = 0xc023fd34 (db_trace_self_wrapper+0x30)
 sp = 0xde2be720  fp = 0xde2be838
r10 = 0xc069f42b
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
 pc = 0xc023fd34  lr = 0xc03eb0ec (witness_checkorder+0xf30)
 sp = 0xde2be840  fp = 0xde2be888
 r4 = 0xc2725be8  r5 = 0xc2d63c94
 r6 = 0xc06ba387  r7 = 0xc069f42b
witness_checkorder() at witness_checkorder+0xf30
 pc = 0xc03eb0ec  lr = 0xc0375bcc (__lockmgr_args+0x24c)
 sp = 0xde2be890  fp = 0xde2be8e8
 r4 = 0xc2d63cb4  r5 = 0x00202400
 r6 = 0x0211  r7 = 0x
 r8 = 0xc2d63c94  r9 = 0x
r10 = 0xc06ba387
__lockmgr_args() at __lockmgr_args+0x24c
 pc = 0xc0375bcc  lr = 0xc05db328 (ffs_lock+0x80)
 sp = 0xde2be8f0  fp = 0xde2be920
 r4 = 0xde2be948  r5 = 0x00202400
 r6 = 0xc2d63c60  r7 = 0xc2d63c94
 r8 = 0xc2d63cb4  r9 = 0x
r10 = 0x0008
ffs_lock() at ffs_lock+0x80
 pc = 0xc05db328  lr = 0xc06609ec (VOP_LOCK1_APV+0x128)
 sp = 0xde2be928  fp = 0xde2be940
 r4 = 0xde2be948  r5 = 0xc07a9630
 r6 = 0x  r7 = 0x00202400
 r8 = 0xde2be948  r9 = 0x0211
r10 = 0xde2bed38
VOP_LOCK1_APV() at VOP_LOCK1_APV+0x128
 pc = 0xc06609ec  lr = 0xc044dcac (_vn_lock+0x48)
 sp = 0xde2be948  fp = 0xde2be978
 r4 = 0xc2d63c60  r5 = 0xde2bece0
 r6 = 0xc06ba387 r10 = 0xde2bed38
_vn_lock() at _vn_lock+0x48
 pc = 0xc044dcac  lr = 0xc0433900 (lookup+0xf8)
 sp = 0xde2be980  fp = 0xde2be9c8
 r4 = 0xc2d63c60  r5 = 0xde2bece0
 r6 = 0xde2bed50  r7 = 0x
 r8 = 0xde2bed50  r9 = 0xc306e448
r10 = 0xde2bed38
lookup() at lookup+0xf8
 pc = 0xc0433900  lr = 0xc0433448 (namei+0x3e8)
 sp = 0xde2be9d0  fp = 0xde2bea48
 r4 = 0xde2bece0  r5 = 0x
 r6 = 0xde2bed50  r7 = 0x
 r8 = 0xc2e526a0  r9 = 0xc306e448
r10 = 0xde2bed38
namei() at namei+0x3e8
 pc = 0xc0433448  lr = 0xc044d4b8 (vn_open_cred+0x1cc)
 sp = 0xde2bea50  fp = 0xde2beb38
 r4 = 0xde2bece0  r5 = 0x
 r6 = 0xc069f42d  r7 = 0x0001
 r8 = 0x  r9 = 0x
r10 = 0xde2bed50
vn_open_cred() at vn_open_cred+0x1cc
 pc = 0xc044d4b8  lr = 0xc044d2e4 (vn_open+0x24)
 sp = 0xde2beb40  fp = 0xde2beb48
 r4 = 0xde2bece0  r5 = 0xc2d0d3c0
 r6 = 0xc069f42d  r7 = 0x001a
 r8 = 0x  r9 = 0xc2e526a0
r10 = 0xc078d6f8
vn_open() at vn_open+0x24
 pc = 0xc044d2e4  lr = 0xc0371390 (linker_load_module+0x634)
 sp = 0xde2beb50  fp = 0xde2beda8
linker_load_module() at linker_load_module+0x634
 pc = 0xc0371390  lr = 0xc0372ff4 (kern_kldload+0xc8)
 sp = 0xde2bedb0  fp = 0xde2bedc8
 r4 = 0xde2bedd4  r5 = 0xc083ef40
 r6 = 0xc2e75000  r7 = 0x
 r8 = 0xde2bee00  r9 = 0xc306b380
r10 = 0xbfbff5fc
kern_kldload() at kern_kldload+0xc8
 pc = 0xc0372ff4  lr = 0xc03730bc (sys_kldload+0x64)
 sp = 0xde2bedd0  fp = 0xde2bede8
 r4 = 0xc2e526a0  r5 = 0xc2e75000
 r6 = 0x  r7 = 0x
sys_kldload() at sys_kldload+0x64
 pc = 0xc03730bc  lr = 0xc063e010 (swi_handler+0x2d4)
 sp = 0xde2bedf0  fp = 0xde2bee50
 r4 = 0xc2e526a0  r5 = 0x
 r6 = 0xc08b3d20 r10 = 0xbfbff5fc
swi_handler() at swi_handler+0x2d4
 pc = 0xc063e010  lr = 0xc06294d8 (swi_exit)
 sp = 0xde2bee58  fp = 0xbfbff648
 r4 = 0x  r5 = 0xbfbff600
 r6 = 0xbfbff600  r7 = 0x0130
 r8 = 0xbfbff5e9  r9 = 0xbfbff5d9
r10 = 0xbfbff5fc

___
freebsd-current@freebsd.org mailing list

Consistent crash of BeagleBone kernel

2015-08-08 Thread Tim Kientzle
I’m seeing the following crash quite consistently on r286438.  It looks like 
the recent work on the kernel linker locking still has some issues.

Any suggested workarounds?

Tim

 log trace ===
...
Starting file system checks:
/dev/mmcsd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/mmcsd0s2a: clean, 7320851 free (179 frags, 915084 blocks, 0.0% 
fragmentation)
lock order reversal:
 1st 0xcd225040 bufwait (bufwait) @ 
/Users/tim/projects/crochet/src-head/sys/kern/vfs_bio.c:3191
 2nd 0xc2e69400 dirhash (dirhash) @ 
/Users/tim/projects/crochet/src-head/sys/ufs/ufs/ufs_dirhash.c:281
… usual stack trace omitted ...
Mounting local file systems:random: unblocking device.
.
ELF ldconfig path: /lib /usr/lib /usr/lib/compat
Setting hostname: beaglebone.
Setting up 
harvesting:[HIGH_PERFORMANCE],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
Feeding entropy:.
lock order reversal:
 1st 0xc083ef40 kernel linker (kernel linker) @ 
/Users/tim/projects/crochet/src-head/sys/kern/kern_linker.c:1030
 2nd 0xc2d63c94 ufs (ufs) @ 
/Users/tim/projects/crochet/src-head/sys/kern/vfs_lookup.c:529
KDB: stack backtrace:
panic: _sx_xlock_hard: recursed on non-recursive sx kernel linker @ 
/Users/tim/projects/crochet/src-head/sys/kern/kern_linker.c:552

KDB: enter: panic
[ thread pid 168 tid 100079 ]
Stopped at  $d.7:   ldrbr15, [r15, r15, ror r15]!
db bt
Tracing pid 168 tid 100079 td 0xc30db6a0
panic: _sx_xlock_hard: recursed on non-recursive sx kernel linker @ 
/Users/tim/projects/crochet/src-head/sys/kern/kern_linker.c:552

Uptime: 4m0s
Rebooting...

___
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: -current broken when src is on NFS

2015-07-17 Thread Tim Kientzle

 On Jul 16, 2015, at 9:57 PM, O'Connor, Daniel dar...@dons.net.au wrote:
 
 
 On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca wrote:
 r285066 fixed a POLA violation w.r.t. the old NFS client where the new
 client didn't return an EEXIST error return for symlink or mkdir to userland.
 The behaviour of not returning this error to userland (which was inherited 
 from
 OpenBSD and was not the behaviour of the old FreeBSD NFS client but was 
 default
 for the new NFS client) can be enabled via:
 vfs.nfs.ignore_eexist=1
 
 You could try setting that sysctl and seeing if it makes any difference?
 
 That is the only recent change to the NFS client that *might* affect this.
 
 No dice :(
 
 It's pretty weird, it bombs out if either src or obj is on NFS..
 But even weirder is that if I build with crochet (a wrapper for cross 
 building to arm) it works. It doesn't work if I cross build manually and I 
 haven't been able to determine why crochet works yet.

Crochet defaults MAKEOBJDIRPREFIX to ${WORKDIR}/obj if you have not already set 
it to something else.  (This avoids cross-polluting the builds if you do 
regular manual cross-builds on the same machine.)

If you’re having issues with /usr/obj being on NFS, that could be a factor.

Tim


___
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: am335x-bone.dts not exist

2015-05-25 Thread Tim Kientzle

 On May 24, 2015, at 6:44 PM, Tim Kientzle t...@kientzle.com wrote:
 
 
 On May 24, 2015, at 12:55 AM, Oleksandr Tymoshenko go...@bluezbox.com 
 wrote:
 
 
 On May 24, 2015, at 12:12 AM, Garrett Cooper yaneurab...@gmail.com wrote:
 
 On May 24, 2015, at 0:07, Oleksandr Tymoshenko go...@bluezbox.com wrote:
 
 On May 23, 2015, at 7:21 PM, Andrey Fesenko f0and...@gmail.com wrote:
 
 # uname -a
 FreeBSD des.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r283306: Sat
 May 23 11:56:46 MSK 2015
 root@des.local:/usr/obj/usr/src/sys/GENERIC  amd64
 
 I'm build BEAGLEBONE with crochet.
 
 build error
 
 Mounting UFS partition 1 at /usr/obj/_.mount.freebsd
 Installing U-Boot from : /usr/local/share/u-boot/u-boot-beaglebone
 Error: beaglebone.dts:29.1-2 syntax error
 FATAL ERROR: Unable to parse input tree
 
 
 file /usr/src/sys/boot/fdt/dts/arm/beaglebone.dts contain #include
 am335x-bone.dts but this file not existence. Need use am335x-evm.dts
 or else?
 
 
 am335x-bone.dts in in sys/gnu/dts/arm/, it's a file provided by vendor (TI)
 
 I guess crochet does not have this path as include path when compiling
 dts files.
 
 Pardon me for being a bit daft potentially, but shouldn’t #include work for 
 all dts files (look for #include in this doc: 
 http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
  )?
 Thanks!
 
 
 
 #include in dts file is handled by cpp(1). /include/ is handled
 by dtc I believe
 
 You can take a look at how FreeBSD compiles dts files in
 sys/tools/fdt/make_dtb.sh
 
 crochet does not have cpp stage of compilation and before my TI
 code/devicetree refactoring none of the dts files referenced in
 crochet used #include. That's why problem never appeared. 
 
 Fix is just a matter of fixing freebsd_install_fdt in lib/freebsd.sh.
 If nobody beats me to it I'll try to fix it and submit pull request to Tim. 
 
 I’m testing a fix for this now.
 
 Thanks for providing such detailed information.

This should be fixed now.

Tim


___
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: am335x-bone.dts not exist

2015-05-25 Thread Tim Kientzle

 On May 25, 2015, at 8:25 AM, Warner Losh i...@bsdimp.com wrote:
 
 
 On May 24, 2015, at 7:44 PM, Tim Kientzle t...@kientzle.com wrote:
 
 
 On May 24, 2015, at 12:55 AM, Oleksandr Tymoshenko go...@bluezbox.com 
 wrote:
 
 
 On May 24, 2015, at 12:12 AM, Garrett Cooper yaneurab...@gmail.com wrote:
 
 On May 24, 2015, at 0:07, Oleksandr Tymoshenko go...@bluezbox.com wrote:
 
 On May 23, 2015, at 7:21 PM, Andrey Fesenko f0and...@gmail.com wrote:
 
 # uname -a
 FreeBSD des.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r283306: Sat
 May 23 11:56:46 MSK 2015
 root@des.local:/usr/obj/usr/src/sys/GENERIC  amd64
 
 I'm build BEAGLEBONE with crochet.
 
 build error
 
 Mounting UFS partition 1 at /usr/obj/_.mount.freebsd
 Installing U-Boot from : /usr/local/share/u-boot/u-boot-beaglebone
 Error: beaglebone.dts:29.1-2 syntax error
 FATAL ERROR: Unable to parse input tree
 
 
 file /usr/src/sys/boot/fdt/dts/arm/beaglebone.dts contain #include
 am335x-bone.dts but this file not existence. Need use am335x-evm.dts
 or else?
 
 
 am335x-bone.dts in in sys/gnu/dts/arm/, it's a file provided by vendor 
 (TI)
 
 I guess crochet does not have this path as include path when compiling
 dts files.
 
 Pardon me for being a bit daft potentially, but shouldn’t #include work 
 for all dts files (look for #include in this doc: 
 http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
  )?
 Thanks!
 
 
 
 #include in dts file is handled by cpp(1). /include/ is handled
 by dtc I believe
 
 You can take a look at how FreeBSD compiles dts files in
 sys/tools/fdt/make_dtb.sh
 
 crochet does not have cpp stage of compilation and before my TI
 code/devicetree refactoring none of the dts files referenced in
 crochet used #include. That's why problem never appeared.
 
 Fix is just a matter of fixing freebsd_install_fdt in lib/freebsd.sh.
 If nobody beats me to it I'll try to fix it and submit pull request to Tim.
 
 I’m testing a fix for this now.
 
 Thanks for providing such detailed information.
 
 Is there any reason the standard dts to dtb script isn’t being used instead 
 of enshrining another copy of that outside the tree which may break if/when 
 we need to enhance the current script?

Until recently, this didn’t seem necessary; it was a lot simpler to just invoke 
dtc.

But times change:  https://github.com/freebsd/crochet/commit/22d7555

Tim

___
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: am335x-bone.dts not exist

2015-05-24 Thread Tim Kientzle

 On May 24, 2015, at 12:55 AM, Oleksandr Tymoshenko go...@bluezbox.com wrote:
 
 
 On May 24, 2015, at 12:12 AM, Garrett Cooper yaneurab...@gmail.com wrote:
 
 On May 24, 2015, at 0:07, Oleksandr Tymoshenko go...@bluezbox.com wrote:
 
 On May 23, 2015, at 7:21 PM, Andrey Fesenko f0and...@gmail.com wrote:
 
 # uname -a
 FreeBSD des.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r283306: Sat
 May 23 11:56:46 MSK 2015
 root@des.local:/usr/obj/usr/src/sys/GENERIC  amd64
 
 I'm build BEAGLEBONE with crochet.
 
 build error
 
 Mounting UFS partition 1 at /usr/obj/_.mount.freebsd
 Installing U-Boot from : /usr/local/share/u-boot/u-boot-beaglebone
 Error: beaglebone.dts:29.1-2 syntax error
 FATAL ERROR: Unable to parse input tree
 
 
 file /usr/src/sys/boot/fdt/dts/arm/beaglebone.dts contain #include
 am335x-bone.dts but this file not existence. Need use am335x-evm.dts
 or else?
 
 
 am335x-bone.dts in in sys/gnu/dts/arm/, it's a file provided by vendor (TI)
 
 I guess crochet does not have this path as include path when compiling
 dts files.
 
 Pardon me for being a bit daft potentially, but shouldn’t #include work for 
 all dts files (look for #include in this doc: 
 http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
  )?
 Thanks!
 
 
 
 #include in dts file is handled by cpp(1). /include/ is handled
 by dtc I believe
 
 You can take a look at how FreeBSD compiles dts files in
 sys/tools/fdt/make_dtb.sh
 
 crochet does not have cpp stage of compilation and before my TI
 code/devicetree refactoring none of the dts files referenced in
 crochet used #include. That's why problem never appeared. 
 
 Fix is just a matter of fixing freebsd_install_fdt in lib/freebsd.sh.
 If nobody beats me to it I'll try to fix it and submit pull request to Tim. 

I’m testing a fix for this now.

Thanks for providing such detailed information.

Cheers,

Tim


___
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: panic on boot

2014-09-04 Thread Tim Kientzle

On Sep 3, 2014, at 7:08 AM, Tim Kientzle t...@kientzle.com wrote:

 
 On Sep 3, 2014, at 6:51 AM, Tim Kientzle t...@kientzle.com wrote:
 
 
 On Sep 2, 2014, at 1:13 PM, Garrett Cooper yaneurab...@gmail.com wrote:
 
 On Tue, Sep 2, 2014 at 9:47 AM, AN a...@neu.net wrote:
 FreeBSD FBSD11 11.0-CURRENT FreeBSD 11.0-CURRENT #47 r269949: Wed Aug 13
 14:18:28 EDT 2014 root@FBSD11:/usr/obj/usr/src/sys/MYKERNEL  amd64
 
 Trying to rebuild the system at r270973
 I get a kernel panic on boot.  I am able to boot into kernel.old at r269949
 and the system is functional.  Is anyone else seeing a panic on boot at a
 recent svn update?
 
  Could you please provide the traceback?
 
 I’m also seeing panics at boot on BBB (armv6) with a kernel built from 
 r270779.  Old kernel from r270339 still works.
 
 Here’s what I’m seeing at boot on BBB with r270779:
 
 … usual kernel boot messages ...
 Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]...
 warning: no time-of-day clock registered, system time will not be set 
 accurately
 Setting hostuuid: aeaa664b-1739-11e4-8e30-7c669d6ce14d.
 Setting hostid: 0x0318d0fa.
 No suitable dump device was found.
 Entropy harvesting: interrupts ethernet point_to_point swi.
 Starting file system checks:
 /dev/mmcsd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS
 /dev/mmcsd0s2a: clean, 1982743 free (62311 frags, 240054 blocks, 1.6% 
 fragmentation)
 Mounting local file systems:.
 /etc/rc: WARNING: $swapfile is obsolete.  Ignored.
 Writing entropy file:.
 Setting hostname: bb-blue.
 cpsw0: link state changed to DOWN
 Starting Network: lo0 cpsw0.
 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
   options=63RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6
   inet6 ::1 prefixlen 128 
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
   inet 127.0.0.1 netmask 0xff00 
   nd6 options=21PERFORMNUD,AUTO_LINKLOCAL
 cpsw0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
   options=8000bRXCSUM,TXCSUM,VLAN_MTU,LINKSTATE
   ether 7c:66:9d:6c:e1:4d
   media: Ethernet autoselect (none)
   status: no carrier
   nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
 Starting devd.
 panic: Undefined instruction in kernel.
 
 KDB: enter: panic
 [ thread pid 284 tid 100069 ]
 Stopped at  $d: ldrbr15, [r15, r15, ror r15]!
 db bt
 Tracing pid 284 tid 100069 td 0xc2b15c80
 db_trace_self() at db_trace_self
 pc = 0xc054d7a8  lr = 0xc0231ab8 (db_stack_trace+0xf4)
 sp = 0xde69d2f8  fp = 0xde69d310
r10 = 0xc0939838
 db_stack_trace() at db_stack_trace+0xf4
 pc = 0xc0231ab8  lr = 0xc0231428 (db_command+0x270)
 sp = 0xde69d318  fp = 0xde69d3b8
 r4 = 0x  r5 = 0x
 r6 = 0x
 db_command() at db_command+0x270
 pc = 0xc0231428  lr = 0xc023118c (db_command_loop+0x60)
 sp = 0xde69d3c0  fp = 0xde69d3d0
 r4 = 0xc059585e  r5 = 0xc05b04e3
 r6 = 0xc0939824  r7 = 0xc064fa38
 r8 = 0xc06958e4  r9 = 0xc06958e0
 db_trap() at db_trap+0xd8
 pc = 0xc0233b54  lr = 0xc039e894 (kdb_trap+0xbc)
 sp = 0xde69d500  fp = 0xde69d520
 r4 = 0x  r5 = 0x0001
 r6 = 0xc0695908  r7 = 0xc064fa38
 kdb_trap() at kdb_trap+0xbc
 pc = 0xc039e894  lr = 0xc0563c80 (undefinedinstruction+0x298)
 sp = 0xde69d528  fp = 0xde69d598
 r4 = 0x  r5 = 0x
 r6 = 0xc0563938  r7 = 0xe7ff
 r8 = 0xc2b15c80  r9 = 0xc039e164
r10 = 0xde69d5a0
 undefinedinstruction() at undefinedinstruction+0x298
 pc = 0xc0563c80  lr = 0xc054f490 (exception_exit)
 sp = 0xde69d5a0  fp = 0xde69d5f8
 r4 = 0xc05b0538  r5 = 0xde69d634
 r6 = 0xc05dc349  r7 = 0xc0687e28
 r8 = 0xc2b15c80  r9 = 0xc093b1dc
r10 = 0xc0687c90
 exception_exit() at exception_exit
 pc = 0xc054f490  lr = 0xc039e158 (kdb_enter+0x40)
 sp = 0xde69d5f0  fp = 0xde69d5f8
 r0 = 0xc06958f4  r1 = 0x
 r2 = 0xc05b3eac  r3 = 0x00aa
 r4 = 0xc05b0538  r5 = 0xde69d634
 r6 = 0xc05dc349  r7 = 0xc0687e28
 r8 = 0xc2b15c80  r9 = 0xc093b1dc
r10 = 0xc0687c90 r12 = 0x
 $a() at $a
 pc = 0xc039e168  lr = 0xc03675a0 (vpanic+0xb4)
 sp = 0xde69d600  fp = 0xde69d620
 r4 = 0x0100
 vpanic() at vpanic+0xb4
 pc = 0xc03675a0  lr = 0xc0367604 (kproc_shutdown)
 sp = 0xde69d628  fp = 0xde69d62c
 r4 = 0x  r5 = 0x
 r6 = 0xc0563938  r7 = 0xe28fc600
 r8 = 0xc2b15c80  r9 = 0xc2eb1bd8
r10 = 0xde69d6b8
 kproc_shutdown() at kproc_shutdown
 pc = 0xc0367604  lr = 0xc0939610 (gdb_uh)
 sp = 0xde69d634  fp = 0xde69d6b0
 r4 = 0xc0367604  r5 = 0xde69d634
 Unknown entry: 0
 gdb_uh() at gdb_uh
 pc = 0xc0939610  lr = 0xc0939610 (gdb_uh)
 sp = 0xde69d634  fp = 0xde69d6b0
 Unable to unwind into user mode


I just noticed

Re: panic on boot

2014-09-03 Thread Tim Kientzle

On Sep 2, 2014, at 1:13 PM, Garrett Cooper yaneurab...@gmail.com wrote:

 On Tue, Sep 2, 2014 at 9:47 AM, AN a...@neu.net wrote:
 FreeBSD FBSD11 11.0-CURRENT FreeBSD 11.0-CURRENT #47 r269949: Wed Aug 13
 14:18:28 EDT 2014 root@FBSD11:/usr/obj/usr/src/sys/MYKERNEL  amd64
 
 Trying to rebuild the system at r270973
 I get a kernel panic on boot.  I am able to boot into kernel.old at r269949
 and the system is functional.  Is anyone else seeing a panic on boot at a
 recent svn update?
 
Could you please provide the traceback?

I’m also seeing panics at boot on BBB (armv6) with a kernel built from r270779. 
 Old kernel from r270339 still works.

I’ll dig out more details tonight.

Tim

___
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: panic on boot

2014-09-03 Thread Tim Kientzle

On Sep 3, 2014, at 6:51 AM, Tim Kientzle t...@kientzle.com wrote:

 
 On Sep 2, 2014, at 1:13 PM, Garrett Cooper yaneurab...@gmail.com wrote:
 
 On Tue, Sep 2, 2014 at 9:47 AM, AN a...@neu.net wrote:
 FreeBSD FBSD11 11.0-CURRENT FreeBSD 11.0-CURRENT #47 r269949: Wed Aug 13
 14:18:28 EDT 2014 root@FBSD11:/usr/obj/usr/src/sys/MYKERNEL  amd64
 
 Trying to rebuild the system at r270973
 I get a kernel panic on boot.  I am able to boot into kernel.old at r269949
 and the system is functional.  Is anyone else seeing a panic on boot at a
 recent svn update?
 
   Could you please provide the traceback?
 
 I’m also seeing panics at boot on BBB (armv6) with a kernel built from 
 r270779.  Old kernel from r270339 still works.

Here’s what I’m seeing at boot on BBB with r270779:

… usual kernel boot messages ...
Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]...
warning: no time-of-day clock registered, system time will not be set accurately
Setting hostuuid: aeaa664b-1739-11e4-8e30-7c669d6ce14d.
Setting hostid: 0x0318d0fa.
No suitable dump device was found.
Entropy harvesting: interrupts ethernet point_to_point swi.
Starting file system checks:
/dev/mmcsd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/mmcsd0s2a: clean, 1982743 free (62311 frags, 240054 blocks, 1.6% 
fragmentation)
Mounting local file systems:.
/etc/rc: WARNING: $swapfile is obsolete.  Ignored.
Writing entropy file:.
Setting hostname: bb-blue.
cpsw0: link state changed to DOWN
Starting Network: lo0 cpsw0.
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
options=63RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6
inet6 ::1 prefixlen 128 
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
inet 127.0.0.1 netmask 0xff00 
nd6 options=21PERFORMNUD,AUTO_LINKLOCAL
cpsw0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=8000bRXCSUM,TXCSUM,VLAN_MTU,LINKSTATE
ether 7c:66:9d:6c:e1:4d
media: Ethernet autoselect (none)
status: no carrier
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
Starting devd.
panic: Undefined instruction in kernel.

KDB: enter: panic
[ thread pid 284 tid 100069 ]
Stopped at  $d: ldrbr15, [r15, r15, ror r15]!
db bt
Tracing pid 284 tid 100069 td 0xc2b15c80
db_trace_self() at db_trace_self
 pc = 0xc054d7a8  lr = 0xc0231ab8 (db_stack_trace+0xf4)
 sp = 0xde69d2f8  fp = 0xde69d310
r10 = 0xc0939838
db_stack_trace() at db_stack_trace+0xf4
 pc = 0xc0231ab8  lr = 0xc0231428 (db_command+0x270)
 sp = 0xde69d318  fp = 0xde69d3b8
 r4 = 0x  r5 = 0x
 r6 = 0x
db_command() at db_command+0x270
 pc = 0xc0231428  lr = 0xc023118c (db_command_loop+0x60)
 sp = 0xde69d3c0  fp = 0xde69d3d0
 r4 = 0xc059585e  r5 = 0xc05b04e3
 r6 = 0xc0939824  r7 = 0xc064fa38
 r8 = 0xc06958e4  r9 = 0xc06958e0
db_trap() at db_trap+0xd8
 pc = 0xc0233b54  lr = 0xc039e894 (kdb_trap+0xbc)
 sp = 0xde69d500  fp = 0xde69d520
 r4 = 0x  r5 = 0x0001
 r6 = 0xc0695908  r7 = 0xc064fa38
kdb_trap() at kdb_trap+0xbc
 pc = 0xc039e894  lr = 0xc0563c80 (undefinedinstruction+0x298)
 sp = 0xde69d528  fp = 0xde69d598
 r4 = 0x  r5 = 0x
 r6 = 0xc0563938  r7 = 0xe7ff
 r8 = 0xc2b15c80  r9 = 0xc039e164
r10 = 0xde69d5a0
undefinedinstruction() at undefinedinstruction+0x298
 pc = 0xc0563c80  lr = 0xc054f490 (exception_exit)
 sp = 0xde69d5a0  fp = 0xde69d5f8
 r4 = 0xc05b0538  r5 = 0xde69d634
 r6 = 0xc05dc349  r7 = 0xc0687e28
 r8 = 0xc2b15c80  r9 = 0xc093b1dc
r10 = 0xc0687c90
exception_exit() at exception_exit
 pc = 0xc054f490  lr = 0xc039e158 (kdb_enter+0x40)
 sp = 0xde69d5f0  fp = 0xde69d5f8
 r0 = 0xc06958f4  r1 = 0x
 r2 = 0xc05b3eac  r3 = 0x00aa
 r4 = 0xc05b0538  r5 = 0xde69d634
 r6 = 0xc05dc349  r7 = 0xc0687e28
 r8 = 0xc2b15c80  r9 = 0xc093b1dc
r10 = 0xc0687c90 r12 = 0x
$a() at $a
 pc = 0xc039e168  lr = 0xc03675a0 (vpanic+0xb4)
 sp = 0xde69d600  fp = 0xde69d620
 r4 = 0x0100
vpanic() at vpanic+0xb4
 pc = 0xc03675a0  lr = 0xc0367604 (kproc_shutdown)
 sp = 0xde69d628  fp = 0xde69d62c
 r4 = 0x  r5 = 0x
 r6 = 0xc0563938  r7 = 0xe28fc600
 r8 = 0xc2b15c80  r9 = 0xc2eb1bd8
r10 = 0xde69d6b8
kproc_shutdown() at kproc_shutdown
 pc = 0xc0367604  lr = 0xc0939610 (gdb_uh)
 sp = 0xde69d634  fp = 0xde69d6b0
 r4 = 0xc0367604  r5 = 0xde69d634
Unknown entry: 0
gdb_uh() at gdb_uh
 pc = 0xc0939610  lr = 0xc0939610 (gdb_uh)
 sp = 0xde69d634  fp = 0xde69d6b0
Unable to unwind into user mode


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman

Re: did tar(1) loose xz compression support in 11?

2014-08-26 Thread Tim Kientzle

On Aug 26, 2014, at 11:05 AM, Chris H bsd-li...@bsdforge.com wrote:

 Greetings,
 I'm currently testing 11. My build / install is from about 2 days ago.
 I generally use xz compression, when creating archives. But when I
 attempt the following:
 
 tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file
 
 it returns the following:
 
 tar: Undefined option: `xz:9'
 
 This has always worked in previous versions. Has the syntax changed,
 and the man(1) pages just haven't caught up?

I can’t see any evidence in libarchive’s source that this ever worked.

However, there was some work done recently to improve error reporting from the 
options processor.  It’s quite possible that —options xz:9 used to just be 
ignored and now it’s reporting an error.

Tim

___
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


portsnap out-of-date?

2014-06-05 Thread Tim Kientzle
I was surprised to see “portsnap fetch” download over 6,000 patches in order to 
advance the April 22 snapshot to now:

 # portsnap fetch
Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found.
Fetching snapshot tag from isc.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Updating from Tue Apr 22 05:38:17 UTC 2014 to Fri Jun  6 01:54:39 UTC 2014.
Fetching 4 metadata patches... done.
Applying metadata patches... done.
Fetching 4 metadata files... done.
Fetching 6198 patches. 
(6198/6198) 100.00%  done. . 
done.
Applying patches... 

___
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: freebsd-update

2014-01-29 Thread Tim Kientzle

On Jan 29, 2014, at 12:51 PM, Lars Engels lars.eng...@0x20.net wrote:

 On Sat, Jan 25, 2014 at 09:11:04AM -0600, Mark Felder wrote:
 
 
 On Sat, Jan 25, 2014, at 5:32, Lars Engels wrote:
 
 
 Also using freebsd-update behind a proxy is really slow. Even with a
 very fast internet connection (normally download rates ca. 3 MBytes / s)
 downloading all the tiny binary diff files took more than 8 hours.
 Maybe freebsd-update's backend could create a tarball of all those diffs
 and provide this? 
 
 Even streaming the tar instead of waiting for the freebsd-update server
 to produce the tarball would be an improvement. I have no experience
 doing that over a WAN but I don't see why it would be unreliable.

I implemented an export capability for $WORK last year
that built and streamed a Zip archive on the fly.  It
worked rather well even when the archives were
multiple gigabytes with tens of thousands of entries.

Tim

___
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: mtree acl support

2014-01-16 Thread Tim Kientzle

On Jan 16, 2014, at 12:36 PM, Mark Felder f...@freebsd.org wrote:

 On Wed, Jan 15, 2014, at 23:11, Tim Kientzle wrote:
 
 On Jan 14, 2014, at 6:47 AM, Mark Felder f...@freebsd.org wrote:
 
 I was recently talking to someone about how one would backup / restore
 ACLs reliably. I didn't see any mention of ACLs in the mtree man page
 and after a quick google I came upon this old mailing list post:
 
 http://lists.freebsd.org/pipermail/freebsd-hackers/2008-April/024173.html
 
 patch in list is here: http://heka.cenkes.org/sat/diffs/mtree_acl.diff
 I've mirrored it here: https://feld.me/freebsd/mtree_acl.diff
 
 This old patch appears to still apply cleanly. I hate to see a patch die
 and be forgotten.
 
 One problem that ‘tar’ has addressed (inspired by Joerg Schilling’s
 work on star) is to permit ACLs to be restored even if the user database
 is out of date.
 
 This is done by including a fourth field in each ACE with the
 numeric user ID.
 
 I suspect you want to do the same for mtree.  I thought
 I remembered acl_to_text having an option to use
 an extended text format, so it might be a trivial change.
 
 
 As long as it's not default. One of the most convenient ways to change a
 user's UID (or multiple users!) is to do an mtree backup, change
 UID/GID, and then re-apply mtree backup. Every file that the user(s)
 previously owned will be automatically changed to the new UID/GID for
 you :-)

The extended format stores both name and numeric ID.

It tries to restore by name first (looking up as necessary), then falls back on 
ID if that fails.

So this does correctly handle your case.

This also lets you restore trees when user lookups are unavailable.  For 
example, user lookups may be broken because of permission problems that you’re 
trying to fix with mtree.  ;-)

Tim

___
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: mtree acl support

2014-01-15 Thread Tim Kientzle

On Jan 15, 2014, at 9:11 PM, Tim Kientzle t...@kientzle.com wrote:

 
 On Jan 14, 2014, at 6:47 AM, Mark Felder f...@freebsd.org wrote:
 
 I was recently talking to someone about how one would backup / restore
 ACLs reliably. I didn't see any mention of ACLs in the mtree man page
 and after a quick google I came upon this old mailing list post:
 
 http://lists.freebsd.org/pipermail/freebsd-hackers/2008-April/024173.html
 
 patch in list is here: http://heka.cenkes.org/sat/diffs/mtree_acl.diff
 I've mirrored it here: https://feld.me/freebsd/mtree_acl.diff
 
 This old patch appears to still apply cleanly. I hate to see a patch die
 and be forgotten.
 
 One problem that ‘tar’ has addressed (inspired by Joerg Schilling’s
 work on star) is to permit ACLs to be restored even if the user database
 is out of date.
 
 This is done by including a fourth field in each ACE with the
 numeric user ID.
 
 I suspect you want to do the same for mtree.  I thought
 I remembered acl_to_text having an option to use
 an extended text format, so it might be a trivial change.

Also, comparing ACLs using strcmp() seems a little odd to me.

Tim

___
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: mtree acl support

2014-01-15 Thread Tim Kientzle

On Jan 14, 2014, at 6:47 AM, Mark Felder f...@freebsd.org wrote:

 I was recently talking to someone about how one would backup / restore
 ACLs reliably. I didn't see any mention of ACLs in the mtree man page
 and after a quick google I came upon this old mailing list post:
 
 http://lists.freebsd.org/pipermail/freebsd-hackers/2008-April/024173.html
 
 patch in list is here: http://heka.cenkes.org/sat/diffs/mtree_acl.diff
 I've mirrored it here: https://feld.me/freebsd/mtree_acl.diff
 
 This old patch appears to still apply cleanly. I hate to see a patch die
 and be forgotten.

One problem that ‘tar’ has addressed (inspired by Joerg Schilling’s
work on star) is to permit ACLs to be restored even if the user database
is out of date.

This is done by including a fourth field in each ACE with the
numeric user ID.

I suspect you want to do the same for mtree.  I thought
I remembered acl_to_text having an option to use
an extended text format, so it might be a trivial change.

Tim


___
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


dhclient can't limit bpf descriptor?

2013-12-14 Thread Tim Kientzle
Opened up an old VM from a month or so ago (r257910) and dhclient won’t start.

Specifically, dhclient complains (when run by root):
 “can’t limit bpf descriptor: Bad address”
and then immediately exits.

What does this mean?   I don’t know anything about the capabilities
framework and certainly haven’t configured it in any way.

I’ve upgraded Parallels and the Mac OS system that Parallels
is running on, so it could be related to that...

Tim

___
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: dhclient can't limit bpf descriptor?

2013-12-14 Thread Tim Kientzle

On Dec 14, 2013, at 3:16 PM, Darren Pilgrim list_free...@bluerosetech.com 
wrote:

 On 12/14/2013 12:12 PM, Tim Kientzle wrote:
 Opened up an old VM from a month or so ago (r257910) and dhclient won’t 
 start.
 
 Specifically, dhclient complains (when run by root):
  “can’t limit bpf descriptor: Bad address”
 and then immediately exits.
 
 Are you running a custom kernel without the Capsicum options?

Nope, it’s an unmodified GENERIC kernel.

Tim

___
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: Request for testing an alternate branch

2013-12-11 Thread Tim Kientzle

On Dec 11, 2013, at 1:26 PM, John Baldwin j...@freebsd.org wrote:

 Also, I'm still not a fan of the EAGAIN approach.  I'd rather have a method
 in bus_if.m to suspend or resume a single device and to track that a device
 is suspended or resumed via a device_t flag or some such. (I think I had
 suggested this previously as it would also allow us to have a tool to
 suspend/resume individual drivers at runtime apart from a full suspend/resume
 request).

Anything that made it easier to test suspend/resume
would be a huge bonus.

Tim

___
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: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

2013-11-29 Thread Tim Kientzle

On Nov 29, 2013, at 4:04 AM, Ermal Luçi e...@freebsd.org wrote:

 Hello,
 
 since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to
 share the same port and possibly listening ip …

These flags are used with TCP-based servers.

I’ve used them to make software upgrades go more smoothly.
Without them, the following often happens:

* Old server stops.  In the process, all of its TCP connections are closed.

* Connections to old server remain in the TCP connection table until the remote 
end can acknowledge.

* New server starts.

* New server tries to open port but fails because that port is “still in use” 
by connections in the TCP connection table.

With these flags, the new server can open the port even though
it is “still in use” by existing connections.


 This is not the case today.
 Only multicast sockets seem to have the behaviour of broadcasting the data
 to all sockets sharing the same properties through these options!

That is what multicast is for.

If you want the same data sent to all listeners, then
that is multicast behavior and you should be using
a multicast socket.

 The patch at [1] implements/corrects the behaviour for UDP sockets.

You’re trying to turn all UDP sockets with those options
into multicast sockets.

If you want a multicast socket, you should ask for one.

Tim

___
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: [RFC] how to get the size of a malloc(9) block ?

2013-11-29 Thread Tim Kientzle

On Nov 29, 2013, at 3:44 PM, jb jb.1234a...@gmail.com wrote:

 Luigi Rizzo rizzo at iet.unipi.it writes:
 
 ... 
 There is a difference between applications peeking into
 implementation details that should be hidden, and providing
 instead limited and specific information through a well defined API.
 ...
 
 Right.
 
 If you want to improve memory management, that is, have the system (kernel
 or user space) handle memory reallocation intelligently and transparently
 to the user, then aim at a well defined API:

Don’t forget:

 * Request a block of “at least N bytes” and have the
allocator tell you what it *really* allocated.

This allows applications to use memory more efficiently
by taking advantage of over-allocation when it happens.

Tim

___
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: freebsd perf testing

2013-11-10 Thread Tim Kientzle

On Nov 10, 2013, at 1:05 PM, Erik Cederstrand erik+li...@cederstrand.dk wrote:

 Imagine being able to fetch a VirtualBox disk image for a random SVN commit, 
 booting it and start debugging right away. 

I’ve been working on Crochet’s support for building
VMWare images recently and have started using
that approach to iterate my dev environment
(using one VM to build a new VM instead of
upgrading in place).

Tim

___
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: cron(8) improvement

2013-11-06 Thread Tim Kientzle

On Nov 5, 2013, at 9:31 AM, Allan Jude free...@allanjude.com wrote:

 This came up in discussion on IRC and I thought I should throw it at the
 list so I don't forget.
 
 A user was asking how to do what linux cron does, where there is a
 directory /etc/cron.d/ that packages and add files to to create crontabs.
 
 Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and
 /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very
 useful feature, especially for pkg(8) as it makes it easy and safe to
 programatically add and remove crontabs as part of a package.

This is a good idea.  We should do it.

How and if this facility gets used is a separate question.

Tools, not policy.

Support for a cron.d directory is a tool that can be
used in many ways.  The policy of how it should be
used is a separate discussion.  (For example, whether
or not ports or packages should install crontab files into
/usr/local/etc/cron.d/ can be richly debated after that
directory exists.)

Tim

___
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: RFC: support for first boot rc.d scripts

2013-10-15 Thread Tim Kientzle
Wonderful!  This capability is long overdue.

On Oct 13, 2013, at 3:58 PM, Colin Percival cperc...@freebsd.org wrote:
 As examples of what such scripts could do:

More examples:

I've been experimenting with putting gpart resize and growfs
into rc.d scripts to construct images that can be dd'ed onto some medium
and then automatically grow to fill the medium.

When cross-installing ports, there are certain operations
(e.g., updating 'info' database) that can really only be
done after the system next boots.

 I'd like to get this into HEAD in the near future in the hope that I can
 convince re@ that this is a simple enough (and safe enough) change to merge
 before 10.0-RELEASE.

Please.

Tim


___
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


Panic in arptimer on r255764

2013-09-22 Thread Tim Kientzle
I'm seeing this panic pretty consistently when I try to do a buildworld on 
r255764 (i386):

http://people.freebsd.org/~kientzle/r255764%20panic%202013-09-21%20at%209.27.09%20PM.png

I'm not seeing it on r255602, so I suspect it's a recent problem.

Running on VMWare Fusion 6.  This was about as vanilla a build as you can get:  
no local code changes, no custom config, no src.conf or make.conf, no ports 
installed, etc.

Tim

___
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: -ffunction-sections, -fdata-sections and -Wl,--gc-sections

2013-09-15 Thread Tim Kientzle

On Sep 15, 2013, at 2:24 PM, Ed Schouten e...@80386.nl wrote:
 GCC and Clang support the -ffunction-sections and -fdata-sections
 flags. Essentially, these flags force the compiler to put every
 function and variable in its own section. Though this will blow up the
….
 - devd suddenly becomes 500 KB in size, instead of a megabyte,
 - init's size drops from 900 KB to 600 KB,

Can you figure out what functions are getting omitted
when you make this change?

Can you extract a linkage map from a build done this
way and compare it to one done the regular way?

That big of a difference suggests we have some badly-factored
code in our libraries.  That is, some library is putting functions
into a single source file that shouldn't be combined.

Tim

___
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


Ports dependencies strangeness.

2013-09-15 Thread Tim Kientzle
I've been seeing this pretty regularly with several
different ports:

 * Start with a fresh system with no packages.
 * Try to install some port with a lot of dependencies
   (using -DBATCH so it won't keep stopping and
asking for configuration options)
 * At some point it stops with a missing dependency

But:

1. Scrolling back through the console output, it's clear
that the dependency in question has in fact just
been built and installed.

2. Package tools show the required dependency is installed.

3. Restarting the original build does not rebuild the
dependency but does notice that it's installed and
goes right through.

Somehow, it appears that port dependencies are
getting built and installed properly but not always
being noticed by the main build.

Tim

___
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: [PATCH] mtree should not output size if the file is not a regular file

2013-09-09 Thread Tim Kientzle

On Sep 9, 2013, at 4:51 PM, Christos Zoulas chris...@zoulas.com wrote:

 On Sep 10,  1:21am, d...@des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) wrote:
 -- Subject: Re: [PATCH] mtree should not output size if the file is not a reg
 
 | Roll a large tarball (e.g. a complete FreeBSD installation).  Copy it to
 | different machines with different filesystems.  Untar and run mtree on
 | the result.  Notice that you get different output on each machine
 | because they report different sizes for directories; one might report
 | the actual on-disk size (which might vary depending on past contents)
 | while the other might report the number of entries.
 
 Yes, I agree. I would like to note that the current NetBSD code looks like:
 
if (keys  F_SIZE 
   (flavor != F_NETBSD6 || S_ISREG(p-fts_statp-st_mode)))
 
 which means that F_NETBSD6 did not print this, and we recently changed
 it to print the size for compatibility with F_FREEBSD9... We also made
 the default F_MTREE format to print the size. So I guess the thing to
 do is change the code to:
 
if (keys  F_SIZE 
   (flavor == F_FREEBSD9 || S_ISREG(p-fts_statp-st_mode)))

DES is right:  size should just be omitted for non-regular files.
Bug-for-bug compatibility can be taken too far.

I prefer Xin's original patch.

Tim

___
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: GCC withdraw

2013-08-30 Thread Tim Kientzle
I've been reading this thread and must confess that I'm a little confused
about what exactly is being discussed.

* I presume we've all agreed that clang is installed by default in FreeBSD-10.

* I presume everyone agrees that cc is clang in FreeBSD-10.

* There obviously needs to be a gcc command in FreeBSD-10, since cc and 
gcc are synonyms in so many people's finger-memory.

Is the debate here just a question of whether gcc is clang or the *real* 
GCC?

Would it be feasible to install GCC as gcc42 or something
similar so people could still reach it regardless of what the gcc
alias pointed to?



On 30 Aug 2013, at 08:56, Jonathan Anderson jonat...@freebsd.org wrote:

 ... then people wanting to compile the base system with gcc/g++ ...


I'm still curious *why* some people want this?

Personally, I would rather compile the base system with the
*supported* compiler.  Today, on FreeBSD-CURRENT/x86
and FreeBSD-CURRENT/amd64, that is clang.



On Aug 30, 2013, at 12:18 AM, Julian Elischer jul...@freebsd.org wrote:

 Clang is new. clang WILL HAVE BUGS.

Based on my own experience, I would put this rather differently:

  GCC and Clang are COMPILERS.
  Therefore, they have DIFFERENT BUGS.

This is why I worry about having cc and gcc be different
compilers.

Tim

___
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: bsdtar/libarchive change behaviour 9-10

2013-08-18 Thread Tim Kientzle

On Aug 18, 2013, at 12:04 PM, Boris Samorodov wrote:

 Hi All,
 
 there are two systems which produce different results:
 -
 % uname -a
 FreeBSD int.wart.ru 9.2-BETA2 FreeBSD 9.2-BETA2 #19 r253968: Tue Aug  6
 04:16:05 SAMT 2013 b...@int.wart.ru:/usr/obj/usr/src/sys/INT  i386
 
 % tar --version
 bsdtar 2.8.5 - libarchive 2.8.5
 
 % tar -tf /usr/ports/distfiles/Catalyst-Plugin-Prototype-1.33.tar.gz |
 grep Plugin/
 Catalyst-Plugin-Prototype-1.33/lib/Catalyst/Plugin/
 Catalyst-Plugin-Prototype-1.33/lib/Catalyst/Plugin/._Prototype.pm
 Catalyst-Plugin-Prototype-1.33/lib/Catalyst/Plugin/Prototype.pm
 -
 % uname -a
 FreeBSD srv.bb.tel.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #7 r253953: Mon
 Aug  5 16:16:42 SAMT 2013
 b...@srv.bb.tel.ru:/usr/obj/usr/src/sys/BB64X  amd64
 
 % tar --version
 bsdtar 3.1.2 - libarchive 3.1.2
 
 % tar -tf /usr/ports/distfiles/Catalyst-Plugin-Prototype-1.33.tar.gz |
 grep Plugin/
 Catalyst-Plugin-Prototype-1.33/lib/Catalyst/Plugin/
 Catalyst-Plugin-Prototype-1.33/lib/Catalyst/Plugin/Prototype.pm
 -
 
 I.e. the CURRENT system does not honor the presence of ._* file.
 The file seems to be a MAC file and anyway get deletted before
 installation.
 
 So, the question is: is it a regression/bug/new feature?

Libarchive 3 does handle ._* files differently than libarchive 2.

In libarchive 2.x those files were treated as normal files
and bsdtar then had special code to process them as
Mac extensions.

Libarchive 3.x can treat them as extended metadata.
As a result, bsdtar doesn't see them at all (except as
additional metadata which can't be restored on FreeBSD).

If you are using libarchive directly, you can ask it
to not interpret those files as metadata.  Bsdtar does
request such handling from libarchive.

Tim


___
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: /etc/namedb-@ referrs to NIL after crash or typing reboot (not shutdown -r)

2013-08-17 Thread Tim Kientzle

On Aug 17, 2013, at 10:35 AM, O. Hartmann wrote:

 On Sat, 17 Aug 2013 21:10:49 +0400
 Boris Samorodov b...@passap.ru wrote:
 
 17.08.2013 13:36, O. Hartmann пишет:
 
 I can reproduceable truncate the link in /etc/ to be NIL by typing
 simply reboot when rebooting the box
 
 Does it make any difference if you use shutdown -r instead?
 
 
 Yes, when using shutdown -r the link isn't broken and the system
 reboots and operates as expected. Only if I use the quick and dirty
 way via reboot or after a crash when service named ahs already been
 started the link is dead. If a crahs occurs BEFORE service named has
 been started, the recovery is also operable - this is my observation.

Does reboot show the same problem If the system has been running
for a while (at least 15 minutes or so)?

Your broken link sounds like the expected behavior when you
do a dirty reboot shortly after the link has been created (before
the link contents have been written all the way to disk).

But the broken /etc/namedb link shouldn't prevent named from
restarting after the reboot; maybe we should change the named
startup scripts to test this link and delete/recreate it if it's broken?

Tim

___
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: /etc/namedb-@ referrs to NIL after crash or typing reboot (not shutdown -r)

2013-08-17 Thread Tim Kientzle

On Aug 17, 2013, at 11:17 AM, O. Hartmann wrote:

 On Sat, 17 Aug 2013 10:42:07 -0700
 Tim Kientzle t...@kientzle.com wrote:
 
 
 On Aug 17, 2013, at 10:35 AM, O. Hartmann wrote:
 
 On Sat, 17 Aug 2013 21:10:49 +0400
 Boris Samorodov b...@passap.ru wrote:
 
 17.08.2013 13:36, O. Hartmann пишет:
 
 I can reproduceable truncate the link in /etc/ to be NIL by typing
 simply reboot when rebooting the box
 
 Does it make any difference if you use shutdown -r instead?
 
 
 Yes, when using shutdown -r the link isn't broken and the system
 reboots and operates as expected. Only if I use the quick and dirty
 way via reboot or after a crash when service named ahs already
 been started the link is dead. If a crahs occurs BEFORE service
 named has been started, the recovery is also operable - this is my
 observation.
 
 Does reboot show the same problem If the system has been running
 for a while (at least 15 minutes or so)?
 
 Yes, of course.

That's not good.

After 15 minutes, the link contents should have been written
all the way to disk, even on an idle system.  It sounds like the
sync process might not be running except at system shutdown.

What filesystem are you using?  ZFS?  UFS/SU?  SU+J?

Kernel version?

Can you reproduce this without named?  That is:
  * create a symlink, 
  * wait 15 minutes,
  * reboot
Is the symlink broken?

Tim

___
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: [net] protecting interfaces from races between control and data ?

2013-08-07 Thread Tim Kientzle

On Aug 6, 2013, at 9:43 AM, Andre Oppermann wrote:

 The driver supplies a TX frame transmit function (mostly like if_transmit
 today) which does all locking and multi-queue handling internally (driver
 owned.  This gives driver writers the freedom to better adjust to different
 hardware communication methods as they become available, like we witnessed
 a couple of times in the past.

How would you handle TX dequeue?

I'm curious because I got a nice speedup with cpsw
by not using the TX interrupt at all:  I just dequeued
completed packets at the end of the TX transmit
function.

I suppose this would still work with your scheme.

Tim

___
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: [net] protecting interfaces from races between control and data ?

2013-08-07 Thread Tim Kientzle

On Aug 6, 2013, at 9:43 AM, Andre Oppermann wrote:

 The driver supplies a TX frame transmit function (mostly like if_transmit
 today) which does all locking and multi-queue handling internally (driver
 owned.  This gives driver writers the freedom to better adjust to different
 hardware communication methods as they become available, like we witnessed
 a couple of times in the past.

How would you handle TX dequeue?

I'm curious because I got a nice speedup with cpsw
by not using the TX interrupt at all:  I just dequeued
completed packets at the end of the TX transmit
function.

I suppose this would still work with your scheme.

Tim

___
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: another -Wunsequenced topic

2013-07-08 Thread Tim Kientzle

On Jul 8, 2013, at 4:43 AM, d...@gmx.com wrote:

 Well, this turned out to be a semi-false alarm. A week ago, for a short time, 
 there was a bug in Clang. There is no undefined behavior in
 
  ptr = func(++ptr);,

No, there is not.

However, this does have an implicit redundant store,
so changing it to

ptr = func(ptr + 1);

is still a good idea, just not for the reason Clang was claiming.


 partially because a function call introduces a sequence point in C, but Clang 
 did not respect this at that time. However,
 
  x = func1(++ptr) + func2(++ptr);
 
 is compiler-dependent.

Code like this is badly broken.  The order of evaluation
here can even change across compiler versions (optimizers
use a variety of criteria to reorganize code, which can easily
change from version to version).

 Additionally, if func() turns out to be a macro, rather than a native 
 function, then undefined behavior (due to unsequencedness) occurs.

Replacing functions with macros is a common way to
optimize code, which is yet another reason the idiom
above should generally be avoided.

 So in the end, Clang has accidentally pointed me to an irrelated bug, and 
 induced some unnecessary code changes.

Not strictly necessary for correctness, but still good changes for the most 
part.

Tim

___
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: another -Wunsequenced topic

2013-06-29 Thread Tim Kientzle
Thanks!  I've committed all of these except the change
to contrib/bmake/ which should probably be submitted
upstream first.

Tim


On Jun 29, 2013, at 7:16 AM, d...@gmx.com wrote:

 Here's a patch to fix several compilation errors coming from -Wunsequenced 
 warnings:
 
 Index: bin/ed/re.c
 ===
 --- bin/ed/re.c   (revision 252372)
 +++ bin/ed/re.c   (working copy)
 @@ -89,7 +89,7 @@
   default:
   break;
   case '[':
 - if ((nd = parse_char_class(++nd)) == NULL) {
 + if ((nd = parse_char_class(nd + 1)) == NULL) {
   errmsg = unbalanced brackets ([]);
   return NULL;
   }
 Index: contrib/bmake/meta.c
 ===
 --- contrib/bmake/meta.c  (revision 252372)
 +++ contrib/bmake/meta.c  (working copy)
 @@ -1249,7 +1249,7 @@
   warnx(%s: %d: line truncated at %u, fname, 
 lineno, x);
   break;
   }
 - cp = strchr(++cp, '\n');
 + cp = strchr(cp + 1, '\n');
   } while (cp);
   if (buf[x - 1] == '\n')
   buf[x - 1] = '\0';
 Index: lib/libfetch/fetch.c
 ===
 --- lib/libfetch/fetch.c  (revision 252372)
 +++ lib/libfetch/fetch.c  (working copy)
 @@ -376,7 +376,7 @@
   /* password */
   if (*q == ':')
 - q = fetch_pctdecode(u-pwd, ++q, URL_PWDLEN);
 + q = fetch_pctdecode(u-pwd, q + 1, URL_PWDLEN);
   p++;
   } else {
 Index: lib/libutil/login_times.c
 ===
 --- lib/libutil/login_times.c (revision 252372)
 +++ lib/libutil/login_times.c (working copy)
 @@ -96,7 +96,7 @@
   else
   m.lt_start = 0;
   if (*p == '-')
 - p = parse_time(++p, m.lt_end);
 + p = parse_time(p + 1, m.lt_end);
   else
   m.lt_end = 1440;
 Index: usr.sbin/newsyslog/newsyslog.c
 ===
 --- usr.sbin/newsyslog/newsyslog.c(revision 252372)
 +++ usr.sbin/newsyslog/newsyslog.c(working copy)
 @@ -1083,7 +1083,7 @@
* at any time, etc).
*/
   if (strcasecmp(DEBUG_MARKER, q) == 0) {
 - q = parse = missing_field(sob(++parse), errline);
 + q = parse = missing_field(sob(parse + 1), errline);
   parse = son(parse);
   if (!*parse)
   warnx(debug line specifies no option:\n%s,
 @@ -1096,7 +1096,7 @@
   } else if (strcasecmp(INCLUDE_MARKER, q) == 0) {
   if (verbose)
   printf(Found: %s, errline);
 - q = parse = missing_field(sob(++parse), errline);
 + q = parse = missing_field(sob(parse + 1), errline);
   parse = son(parse);
   if (!*parse) {
   warnx(include line missing argument:\n%s,
 @@ -1138,7 +1138,7 @@
   defconf_p = working;
   }
 - q = parse = missing_field(sob(++parse), errline);
 + q = parse = missing_field(sob(parse + 1), errline);
   parse = son(parse);
   if (!*parse)
   errx(1, malformed line (missing fields):\n%s,
 @@ -1172,7 +1172,7 @@
   } else
   working-gid = (gid_t)-1;
 - q = parse = missing_field(sob(++parse), errline);
 + q = parse = missing_field(sob(parse + 1), errline);
   parse = son(parse);
   if (!*parse)
   errx(1, malformed line (missing fields):\n%s,
 @@ -1187,7 +1187,7 @@
   errx(1, error in config file; bad permissions:\n%s,
   errline);
 - q = parse = missing_field(sob(++parse), errline);
 + q = parse = missing_field(sob(parse + 1), errline);
   parse = son(parse);
   if (!*parse)
   errx(1, malformed line (missing fields):\n%s,
 @@ -1197,7 +1197,7 @@
   errx(1, error in config file; bad value for count of 
 logs to save:\n%s,
   errline);
 - q = parse = missing_field(sob(++parse), errline);
 + q = parse = missing_field(sob(parse + 1), errline);
   parse = son(parse);
   if (!*parse)
   errx(1, malformed line (missing fields):\n%s,
 @@ 

Re: Kernel build fails on ARM: Cannot fork: Cannot allocate memory

2013-06-23 Thread Tim Kientzle

On Jun 23, 2013, at 9:16 AM, Konstantin Belousov wrote:

 On Sun, Jun 23, 2013 at 06:43:46PM +0400, Ruslan Bukin wrote:
 On Sun, Jun 23, 2013 at 05:32:48PM +0300, Konstantin Belousov wrote:
 
 This is useless without a backtrace.
 
 Trying to mount root from ufs:/dev/da0 []...
 WARNING: / was not properly dismounted
 warning: no time-of-day clock registered, system time will not be set 
 accurately
 panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ 
 /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289
 
 KDB: enter: panic
 [ thread pid 1 tid 11 ]
 Stopped at  kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]!
 db bt
 Tracing pid 1 tid 11 td 0xc547f620
 _end() at 0xde9d0530
 scp=0xde9d0530 rlv=0xc1211458 (db_trace_thread+0x34)
rsp=0xde9d0514 rfp=0xc12d1b60
 Bad frame pointer: 0xc12d1b60
 db 
 This is completely broken.  It seems that witness triggered the panic,
 and ddb is unable to obtain a backtrace from the normal panic(9) call.

Kernel backtraces are currently broken on ARM EABI kernels.

Tim



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [head tinderbox] failure on arm/arm

2013-06-18 Thread Tim Kientzle
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything
 [...]
 /src/usr.bin/svn/lib/libapr/../../../../contrib/apr/include/apr_ring.h:183:34:
  note: expanded from macro 'APR_RING_PREV'
 #define APR_RING_PREV(ep, link) (ep)-link.prev
 ^
 /src/usr.bin/svn/lib/libapr/../../../../contrib/apr/include/apr_ring.h:177:34:
  note: expanded from macro 'APR_RING_NEXT'
 #define APR_RING_NEXT(ep, link) (ep)-link.next
 ^
 fatal error: too many errors emitted, stopping now [-ferror-limit=]
 1 warning and 20 errors generated.
 *** Error code 1
 
 Stop.
 make: stopped in /src/usr.bin/svn/lib/libapr
 *** Error code 1

This might be the OffsetOf bug for APR on ARM.
We just got a fix pushed upstream for this a few
days ago.

I don't have time to look, but someone should take
a peek at the following patch and see if it's
needed:

--- ./apr-1.4.7/include/apr_general.h.orig
+++ ./apr-1.4.7/include/apr_general.h
@@ -76,7 +76,7 @@
·*·@return·offset
·*/
-#if·defined(CRAY)·||·(defined(__arm)··!defined(LINUX))
+#if·defined(CRAY)·||·(defined(__arm)··!(defined(LINUX)·||·defined(__FreeBSD__)))
#ifdef·__STDC__
#define·APR_OFFSET(p_type,field)·_Offsetof(p_type,field)
#else


___
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: 10-CURRENT i386 memstick snapshots broken?

2013-06-08 Thread Tim Kientzle

On Jun 8, 2013, at 10:34 AM, Glen Barber wrote:

 On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote:
 Has anyone else tried the i386 memstick and having the same problem?
 
 
 Hmm.  Thanks for the report.  I'll take a look at the logs for i386, but
 they are generated the same way as the amd64, so in theory should not
 have any noticable difference.
 
 
 For amd64 and i386, native binaries are built, and installed into
 scratch directories; for powerpc and powerpc64, I just use the amd64
 binaries, because I cannot directly use the chroot binaries for
 non-native architecture.
 
 The scripts chroot into the scratch directories, and run the real
 release builds.

Have you tried using Crochet for this sort of thing?

Since it was designed from the ground up for cross-building
bootable images, it should avoid these issues.

The only fundamental limit right now is that Crochet uses
the host system to build the UFS filesystems, so it can't
build big-endian MIPS images on i386, for example.

Tim



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [head tinderbox] failure on armv6/arm

2013-06-05 Thread Tim Kientzle
Seems the tinderbox scripts are routinely showing too little of the actual 
error these days...

On Jun 4, 2013, at 7:19 PM, FreeBSD Tinderbox wrote:

 TB --- 2013-06-05 01:10:18 - tinderbox 2.10 running on 
 freebsd-current.sentex.ca
 TB --- 2013-06-05 01:10:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
 FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
 TB --- 2013-06-05 01:10:18 - starting HEAD tinderbox run for armv6/arm
 TB --- 2013-06-05 01:10:18 - cleaning the object tree
 TB --- 2013-06-05 01:10:18 - /usr/local/bin/svn stat /src
 TB --- 2013-06-05 01:10:22 - At svn revision 251402
 TB --- 2013-06-05 01:10:23 - building world
 TB --- 2013-06-05 01:10:23 - CROSS_BUILD_TESTING=YES
 TB --- 2013-06-05 01:10:23 - MAKEOBJDIRPREFIX=/obj
 TB --- 2013-06-05 01:10:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
 TB --- 2013-06-05 01:10:23 - SRCCONF=/dev/null
 TB --- 2013-06-05 01:10:23 - TARGET=arm
 TB --- 2013-06-05 01:10:23 - TARGET_ARCH=armv6
 TB --- 2013-06-05 01:10:23 - TZ=UTC
 TB --- 2013-06-05 01:10:23 - __MAKE_CONF=/dev/null
 TB --- 2013-06-05 01:10:23 - cd /src
 TB --- 2013-06-05 01:10:23 - /usr/bin/make -B buildworld
 Building an up-to-date make(1)
 World build started on Wed Jun  5 01:10:30 UTC 2013
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 [...]
 === cddl/lib/libavl (all)
 cc   -O -pipe  -I/src/cddl/lib/libavl/../../../sys/cddl/compat/opensolaris 
 -I/src/cddl/lib/libavl/../../../sys/cddl/contrib/opensolaris/uts/common 
 -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign 
 -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare 
 -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
 -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter 
 -Wno-parentheses -Wno-unknown-pragmas -c 
 /src/cddl/lib/libavl/../../../sys/cddl/contrib/opensolaris/common/avl/avl.c 
 -o avl.o
 building static avl library
 ranlib libavl.a
 cc  -fpic -DPIC  -O -pipe  
 -I/src/cddl/lib/libavl/../../../sys/cddl/compat/opensolaris 
 -I/src/cddl/lib/libavl/../../../sys/cddl/contrib/opensolaris/uts/common 
 -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign 
 -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare 
 -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
 -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter 
 -Wno-parentheses -Wno-unknown-pragmas -c 
 /src/cddl/lib/libavl/../../../sys/cddl/contrib/opensolaris/common/avl/avl.c 
 -o avl.So
 building shared library libavl.so.2
 /obj/arm.armv6/src/tmp/usr/bin/ld: cannot find -lgcc_s
 cc: error: linker command failed with exit code 1 (use -v to see invocation)
 *** Error code 1
 
 Stop.
 make: stopped in /src/cddl/lib/libavl
 *** Error code 1
 
 Stop.
 make: stopped in /src/cddl/lib
 === cddl/lib/libavl (install)
 sh /src/tools/install.sh -C -o root -g wheel -m 444   libavl.a 
 /obj/arm.armv6/src/tmp/usr/lib
 sh /src/tools/install.sh -s -o root -g wheel -m 444 libavl.so.2 
 /obj/arm.armv6/src/tmp/lib
 install: libavl.so.2: No such file or directory
 *** Error code 71
 
 Stop.
 make: stopped in /src/cddl/lib/libavl
 *** Error code 1
 
 Stop.
 make: stopped in /src/cddl/lib
 *** Error code 1
 
 Stop.
 make: stopped in /src
 *** Error code 1
 
 Stop.
 make: stopped in /src
 *** Error code 1
 
 Stop.
 make: stopped in /src
 *** Error code 1
 
 Stop in /src.
 TB --- 2013-06-05 02:19:07 - WARNING: /usr/bin/make returned exit code  1 
 TB --- 2013-06-05 02:19:07 - ERROR: failed to build world
 TB --- 2013-06-05 02:19:07 - 3613.77 user 355.81 system 4128.80 real
 


___
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: Better pkg bootstrapping instructions?

2013-02-13 Thread Tim Kientzle

On Feb 13, 2013, at 2:23 AM, Baptiste Daroussin wrote:

 On Sat, Feb 02, 2013 at 09:46:41PM -0800, Tim Kientzle wrote:
 Especially on -CURRENT, it's not going to be uncommon
 to see things like this:
 
 The package management tool is not yet installed on your system.
 Do you want to fetch and install it now? [y/N]: y
 Bootstrapping pkg please wait
 _http._tcp.pkg.FreeBSD.org
 pkg: Error fetching 
 http://pkg.FreeBSD.org/freebsd:10:arm:32:el:oabi:softfp/latest/Latest/pkg.txz:
  Not Found
 
 It would be nice if the next line said:
  A pre-built version of pkg could not be found for your system.
  Please install it from source using the ports-mgmt/pkg port.
 
 ___
 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
 
 Would this fit, in particular the wording?
 
 http://people.freebsd.org/~bapt/pkg-better-errmsg.diff

Much better.

Better still to mention the specific port name:  pkg-mgmt/pkg
(assuming that port name will be reasonably stable over time).

Tim



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Cross-architecture package installs

2013-02-12 Thread Tim Kientzle
 I'm working on tools to build ARM system images.
 Usually, these tools run on x86, which creates a problem
 for packages.
 
 1) Pre-install/post-install scripts.
 
   These obviously don't work since the DESTDIR
   is for a different architecture.
 
 This is imho the main problem, and one of the long term goal of pkgng is to 
 remove as much as possible any pre-instal/post-install scripts.

Well, you're very close to having this work:

The easiest approach I've found is to setup a simple
static webserver, use pkg repo to build the catalogue,
then:

echo Installing packages
PACKAGESITE=http://my.local.server/packages/arm
export PACKAGESITE
pkg -c $DESTDIR update
pkg -c $DESTDIR install -y pkg
pkg -c $DESTDIR upgrade
pkg -c $DESTDIR install -y emacs-nox11

The only piece missing is that the POST-INSTALL
scripts are failing.

For the packages I'm using, it would be enough to provide
symlink support in the +MANIFEST file directly.  For other
packages, something like the after next boot fixup that
I outlined earlier would work.

But this is very, very close.  This is a big step forward
for non-x86 FreeBSD.

Kudos to the pkgng team!

Tim



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: 7+ days of dogfood

2013-02-09 Thread Tim Kientzle

On Feb 9, 2013, at 10:33 PM, Ian FREISLICH wrote:

 2. MALLOC_PRODUCTION=yes
   Maybe it's the placebo effect.  Binaries are smaller in memory
   and things seem faster

There have been significant improvements in this area
very recently.   Please give it another try without this
setting and let us know.

Tim

___
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: Cross-architecture package installs

2013-02-06 Thread Tim Kientzle

On Feb 5, 2013, at 10:55 PM, Baptiste Daroussin wrote:

 On Tue, Feb 05, 2013 at 10:34:18PM -0800, Tim Kientzle wrote:
 I'm working on tools to build ARM system images.
 Usually, these tools run on x86, which creates a problem
 for packages.
 
 1) Pre-install/post-install scripts.
 
These obviously don't work since the DESTDIR
is for a different architecture.

 This is imho the main problem, and one of the long term goal of pkgng is to 
 remove as much as possible any pre-instal/post-install scripts.

Here's an approach that would handle post-install fairly
graciously in this case.  I'll presume you're cross-building
from x86 to ARM in this example:

* On x86, run pkg -c $ARMSYS install packages

* During install, record the post-install scripts in
  the package database but don't run them.

* When the ARM system is first booted, an rc.d script
   runs pkg finish (or pkg install --some-option if you prefer)

   pkg finish finds the post-install scripts that have not yet
   been run and runs them.

This way, the post-install scripts always run on the
native architecture.

This won't work for pre-install scripts, of course.


 The second problem you
 will get into is the API that call system()/exec()/etc for example all the 
 call
 the pw_mkdb from libutil :(
 
 We are open for all suggestions here

A first boot fixup as above might handle some of these
cases.  (Instead of running these commands immediately,
register them to run on next boot.)

For others, I think the only feasible option is to identify
them and get people to help push the necessary
functionality into libraries.

Tim



signature.asc
Description: Message signed with OpenPGP using GPGMail


Cross-architecture package installs

2013-02-05 Thread Tim Kientzle
I'm working on tools to build ARM system images.
Usually, these tools run on x86, which creates a problem
for packages.

I would like to install packages onto the image as it's built.
So I've been experimenting with variations of
   pkg -c DESTDIR add package files

I'm running into a few problems but I think they can all be
solved.  Only the first is critical; the rest are relatively
minor annoyances.

1) Pre-install/post-install scripts.

These obviously don't work since the DESTDIR
is for a different architecture.

At least for post-install, it should be possible to
record which packages still need their post-install
scripts run and arrange to run them after first
boot.  I'm picturing an rc.d script that invokes pkg
with appropriate options to find all packages
that still need their post-install run and runs them.

This won't work for pre-install, but those are rarer
and we can hopefully work around them on a
case-by-case basis.

2) The chroot happens before opening the package files.

It's possible to work around this by copying all of the
package files into DESTDIR first, but that's both
time-consuming and rather awkward.  (And quite
tricky if you're installing directly onto a mounted
image that has very little free space.)

It should be feasible to open the package files first
and then chroot.  Then the actual installation still
happens entirely inside DESTDIR.

3) Bogus failed to install messages.

As far as I can tell, if bar depends on foo, then
pkg add bar foo will do this:

Installing bar …
Installing foo …
done
done
Installing foo … foo already installed.

Failed to install the following package: foo.

This is surprising since foo did in fact get installed.

In my case, I want to say pkg add * and just have
it DTRT.  It mostly does get the ordering right (I'm impressed!)
but the error message is a bit odd.

___
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


gpart resize vs. cache?

2013-02-03 Thread Tim Kientzle
I'm tinkering with a disk image that automatically
fills whatever media you put it onto.  But I'm having
trouble with gpart resize failing.

Disk layout:
   MBR with two slices  mmcsd0s1 and mmcsd0s2
   bsdlabel with one partition mmcsd0s2a

Before I can use growfs, I have two gpart resize operations:

1)   gpart resize -i 2 mmcsd0

2)  gpart resize -i 1 mmcsd0s2

Step 1 resizes mmcsd0s2 and always succeeds.

Step 2 resizes mmcsd0s2a and always fails
with No space on device.

BUT if I reboot between these steps, step #2
always succeeds.

I suspect that step #1 is updating the partition
information on disk but that step #2 is somehow
reading the old size of mmcsd0s2 and thus finding
that there is no available space to grow the partition.

gpart(1) doesn't say anything about caching of
disk partiition info and gpart list does show the
updated information after step #1.

Is there some trick that will force the partition
information in memory to be updated (short of
a reboot or unmount/remount the root filesystem)?

Tim

___
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: gpart resize vs. cache?

2013-02-03 Thread Tim Kientzle

On Feb 3, 2013, at 1:08 PM, Ian Lepore wrote:

 On Sun, 2013-02-03 at 12:06 -0800, Tim Kientzle wrote:
 I'm tinkering with a disk image that automatically
 fills whatever media you put it onto.  But I'm having
 trouble with gpart resize failing.
 
 Disk layout:
   MBR with two slices  mmcsd0s1 and mmcsd0s2
   bsdlabel with one partition mmcsd0s2a
 
 Before I can use growfs, I have two gpart resize operations:
 
 1)   gpart resize -i 2 mmcsd0
 
 2)  gpart resize -i 1 mmcsd0s2
 
 Step 1 resizes mmcsd0s2 and always succeeds.
 
 Step 2 resizes mmcsd0s2a and always fails
 with No space on device.
 
 BUT if I reboot between these steps, step #2
 always succeeds.
 
 I suspect that step #1 is updating the partition
 information on disk but that step #2 is somehow
 reading the old size of mmcsd0s2 and thus finding
 that there is no available space to grow the partition.

BTW, I've added some debug messages to gpart
and the second resize is failing because the new
computed size is a little smaller than the old size
(maybe because of a different alignment?).  But
it's certainly not sizing to the new container size.

 gpart(1) doesn't say anything about caching of
 disk partiition info and gpart list does show the
 updated information after step #1.
 
 Is there some trick that will force the partition
 information in memory to be updated (short of
 a reboot or unmount/remount the root filesystem)?
 
 This sounds like one of those situations where the force re-taste
 incantation may work... just open/close the parent geom for write.  From
 script, it's as easy as
 
  : /dev/mmcsd0s2
 
 If that doesn't work, try /dev/mmcsd0.
 
 The re-taste trick is usually only needed on things like a usb sdcard
 reader where it can't tell you changed media and tries to use the
 in-memory info from the prior card.  Since you're using a geom-aware
 tool to make a geom change, I wonder why it doesn't do the re-taste
 automatically?

That certainly changes things, but not in a good way.
Here's the key part of the script now:

gpart resize -i 2 mmcsd0
: /dev/mmcsd0
gpart resize -i 1 mmcsd0s2
: /dev/mmcsd0s2
growfs -y /dev/mmcsd0s2a

And here's the result:

mmcsd0s2 resized
mmcsd0s2a resized
eval: growfs: Device not configured
… lots more Device not configured, ultimately leading to…
vm_fault: pager read error, pid 1 (init)
vnode_pager_getpages: I/O read error
vm_fault: pager read error, pid 1 (init)
vnode_pager_getpages: I/O read error
… which keeps scrolling until I pull power.

Apparently this hosed the root mount (I've tried every combination
of one or both force retastes above with the same effect).  It
does not appear that the disk is hosed as I can reboot single
user and everything is okay, but every time this code runs
the same errors occur.

I also tried Erich Dollansky's suggestion of adding a
gpart show between the resize requests but that
seems to make no difference at all.

Tim

___
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


Better pkg bootstrapping instructions?

2013-02-02 Thread Tim Kientzle
Especially on -CURRENT, it's not going to be uncommon
to see things like this:

The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg please wait
_http._tcp.pkg.FreeBSD.org
pkg: Error fetching 
http://pkg.FreeBSD.org/freebsd:10:arm:32:el:oabi:softfp/latest/Latest/pkg.txz: 
Not Found

It would be nice if the next line said:
  A pre-built version of pkg could not be found for your system.
  Please install it from source using the ports-mgmt/pkg port.

___
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: devel/gobject-introspection failure on ARM

2013-01-27 Thread Tim Kientzle

On Jan 27, 2013, at 7:57 AM, George Mitchell wrote:

 System: Raspberry Pi
 uname: r245840M (Alie Tan's image from 25 January)
 ports: svnversion 308518
 
 Build dies with message sizeof(ArrayTypeBlob) is expected to be 8 but
 is 12.  (Complete build log attached.)  I made a naive attempt to fix
 it by rearranging the order of the structure members, but obviously I
 don't understand structure packing on the ARM and it didn't help.

The easiest way to hack around this is usually to
sprinkle packed decorators on a lot of structure
definitions.

  It also didn't get rid of the huge number of cast increases required
 alignment of target type warnings.

How troublesome these are depends on the processor.
I think the ARMv6 on the RaspberryPi is late enough to
support misaligned accesses.  It's a big performance hit
but better than crashing.

 I note we're at version 0.10.8 of this package, but upstream is at
 1.34.2.  (It requires glib 2.34.1, though, and we're only at 2.28.8).
 
 What's the best way to proceed?  

Given the version numbers you quote, I expect that
a newer glib would be a good start.

Good luck,

Tim

___
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: CFT: Overhauled CPSW driver for BeagleBone

2013-01-01 Thread Tim Kientzle

On Jan 1, 2013, at 8:12 AM, Brett Wynkoop wrote:

 On Mon, 31 Dec 2012 15:25:15 -0800
 Tim Kientzle kient...@freebsd.org wrote:
 
 I've made some progress reworking the CPSW driver for
 BeagleBone and would appreciate any feedback:
 
  https://github.com/kientzle/cpsw
 
 Greeting-
 
 The driver is working much better than the driver currently in head.  I
 have maintained an ssh connection to the BeagleBone for more than 24
 hours!

Just committed this to -CURRENT r244939.

Tim
___
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


CFT: Overhauled CPSW driver for BeagleBone

2012-12-31 Thread Tim Kientzle
I've made some progress reworking the CPSW driver for
BeagleBone and would appreciate any feedback:

  https://github.com/kientzle/cpsw

I believe I've resolved the most pressing stability
problems; the driver properly survives cables
being unplugged and replugged, modules being
loaded and unloaded while the network is
busy, etc.

The most obvious remaining issue:  TX interrupts
still just stop occasionally.  But the watchdog now
consistently detects and resets everything within
a few seconds, so that's much less of a headache.

I hope to commit this to FreeBSD-CURRENT within
the week.

Tim

___
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: r244036 kernel hangs under load.

2012-12-10 Thread Tim Kientzle

On Dec 10, 2012, at 10:38 AM, Rick Macklem wrote:

 Adrian Chadd wrote:
 .. what was the previous kernel version?
 
 Hopefully Tim has it narrowed down more, but I don't see
 the hangs on a Sept. 7 kernel from head and I do see them
 on a Dec. 3 kernel from head. (Don't know the eact rNN.)

I haven't had a chance to narrow it down any yet, but I think
my previous kernel was from around Aug 25.

Tim

___
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: please add auditdistd user/group to -stable and the 9.1-release?

2012-12-09 Thread Tim Kientzle

On Dec 3, 2012, at 12:46 AM, Garrett Cooper wrote:

 On Sun, Dec 2, 2012 at 11:06 PM, Garrett Cooper yaneg...@gmail.com wrote:
 On Sun, Dec 2, 2012 at 9:20 PM, Garrett Cooper yaneg...@gmail.com wrote:
 On Sun, Dec 2, 2012 at 9:08 PM, Adrian Chadd adr...@freebsd.org wrote:
 Hi,
 
 Would you guys please add the auditdistd user/group info to
 9.1-release, so people doing crossbuilds of -HEAD on a fresh
 9.1-RELEASE won't get an install error?
 
 Or mtree could just use -w instead in Makefile.inc1 and distribute.
 Let me do some investigation to determine whether or not this is a
 valid solution to this problem.
 
I've done some digging in the source tree and this seems like a
 potentially workable solution for the issue reported -- in part
 because auditdistd is only present in BSD.var.dist, /etc/rc.d/var runs
 BSD.var.dist at boot, etc:

A more robust -- and possibly simpler -- solution might be to
include the uid/gid in the mtree file as well and provide a
way for mtree to fall back to using that if the uname/gname can't
be looked up.

This will probably require adding some switches to choose the
appropriate behavior from among the following:

 * If both are specified, prefer the name.  This is what tar always does:
tries to use the name and falls back to using the number if the name
isn't available.

 * If both are specified, prefer the number.  This would be helpful if
you were running mtree in a cross-build situation where the host
system has radically different user/group numbering (Robert
mentioned someday cross-building from non-FreeBSD hosts).

 * Require both to match.  This would complain if the name/number in
the mtree file didn't both exactly match the current host.  This
would be the useful behavior when using mtree files to verify
files on disk.  This is likely the most appropriate default
behavior.

Tim

___
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


r244036 kernel hangs under load.

2012-12-09 Thread Tim Kientzle
I haven't found any useful clues yet, but thought I'd ask if anyone else
was seeing hangs in a recent kernel.

I just upgraded to r244036 using a straight GENERIC i386 kernel.
(Straight buildworld/buildkernel, no local changes, /etc/src.conf doesn't
exist, /etc/make.conf just has PERL_VERSION defined.)

When I try to cross build an ARM world on the resulting system,
the entire system hangs hard after about 30 minutes:  No network,
no keyboard response, no nothing.

Don't know if it's relevant, but the system is using NFS pretty
heavily (Parallels VM mounting NFS from Mac OS 10.7 host.)

I'll try to get some more details ...

Tim

___
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: prompt w/ uid 0 for cshrc

2012-11-23 Thread Tim Kientzle

On Nov 19, 2012, at 8:46 AM, jb wrote:

 Eitan Adler lists at eitanadler.com writes:
 
 
 On 18 November 2012 18:44, Mateusz Guzik mjguzik at gmail.com wrote:
 Just take user name from id -nu.
 
 While that does provide the $user value I want, id is in /usr/bin/
 which may not be mounted.
 
 /rescue/id

Bad idea:
  * /rescue tools are not part of the standard world
  * /rescue tools are sometimes not installed
  * Quite a few people have customized the rescue tools to adding or omitting 
things suitable for their particular installation.
  * /rescue tools are not guaranteed to be functionally identical to the 
non-rescue versions.

Better to invoke 'id' in a way that produces
reasonable results if 'id' is unavailable.

For example:
/bin/sh -c 'id -nu 2/dev/null' || echo '?'

prints '?' if the id command fails or is unavailable.

Tim

___
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: pkg - Shared object libarchive.so.5 not found, required by pkg

2012-11-23 Thread Tim Kientzle

On Nov 23, 2012, at 2:13 PM, Christer Solskogen wrote:

 10-CURRENT was built (and installed) twice. I guess the library was
 installed when I was at 9.1-RC3 but was deleted during make
 delete-old.

delete-old should not have deleted any libraries.

I think you must have also done delete-old-libs.
That often requires you to reinstall all your ports
as well.

 Rebuilding pkg from src/usr.sbin/pkg did not do the trick. For some
 reason it was still linking to the old library.
 Any hints?

/usr/sbin/pkg mostly just runs /usr/local/sbin/pkg

You need to reinstall the pkg port as well.

Tim

___
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: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap

2012-09-01 Thread Tim Kientzle

On Sep 1, 2012, at 12:40 PM, Matthew Seaman wrote:

 On 01/09/2012 18:43, Tijl Coosemans wrote:
 In this scenario the ports tree needs to keep support for older releases,
 but that's a consequence of the fact that there's only one ports tree for
 all releases. Somewhere in between the ports and the various releases there
 has to be some form encapsulation, not just for pkg, but for all the tools
 used by the ports tree. Given how the ports tree currently encapsulates
 both the old and new pkg tools I don't see how supporting multiple versions
 of pkgng would be a problem because presumably the difference between pkgng
 versions is going to be much smaller than the difference between the old
 and new tools.
 
 New functionality already in the process of development will entail
 making non-backwards compatible changes to the DB schema.  If we're tied
 to supporting a version of pkgng bundled with a release, that's going to
 make rolling out such changes much harder.  On the other hand, if pkgng
 is in ports, then we can release a new version and simultaneously
 publish new package sets (incorporating the update to pkgng) from the
 repositories which will have been built using the updated DB schema.

Will new versions of pkgng support old packages?

Some folks maintain their own package repositories and
will get rather grumpy if an update to pkgng requires them
to rebuild their entire repository.

Tim

___
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: make package fails in chroot: tar: getvfsbyname failed: No such file or directory

2012-08-19 Thread Tim Kientzle

On Aug 12, 2012, at 6:20 AM, Paul Schenkeveld wrote:

 Hi,
 
 I have a wrapper script that builds packages in a chroot environment
 which happily runs on release 6 thru 9 and earlier 10 but fails with:
 
  tar: getvfsbyname failed: No such file or directory
 
 on a recent -CURRENT.
 
 What I could dig up so far is that make package-recursive calls
 pkg_create(1) which in turn calls tar -c -f portname.tbz -j -T -
 and then starts feeding filenames that should go into the tarball.
 
 Something has changed in libarchive when
 src/contrib/libarchive/libarchive/archive_read_disk_posix.c was
 introduced (libarchive 3.0.3, svn rev 232153 I think) where
 setup_current_filesystem() calls getvfsbyname().
 
 Now it's getting too hairy for me so I hope someone with more
 insight in this kind of stuff can help me out.
 
 My chroot environment has a root directory which is a subdir of my build
 environment, so not a mountpoint by itself. /usr/src and /usr/ports are
 NFS mounted from a fileserver and I have devfs mounted on /dev.

libarchive does do an initial getvfsbyname() when you ask it
to traverse a directory tree so that it can accurately handle later
requests about mountpoints and filesystem types.  This code
is admittedly a little intricate.

You've apparently found a case where getvfsbyname() is
getting handed a bad filename argument.  Maybe one of the
filenames getting fed into -T doesn't exist.  (In which case
tar should report an error, but it should be a clear error.)

Can you add a printf() nearby that getvfsbyname() call,
to dump the argument that's causing problems?

Tim

___
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: make package fails in chroot: tar: getvfsbyname failed: No such file or directory

2012-08-19 Thread Tim Kientzle

On Aug 19, 2012, at 12:17 PM, Garrett Cooper wrote:

 On Sun, Aug 19, 2012 at 9:45 AM, Tim Kientzle t...@kientzle.com wrote:
 
 On Aug 12, 2012, at 6:20 AM, Paul Schenkeveld wrote:
 
 Hi,
 
 I have a wrapper script that builds packages in a chroot environment
 which happily runs on release 6 thru 9 and earlier 10 but fails with:
 
 tar: getvfsbyname failed: No such file or directory
 
 on a recent -CURRENT.
 
 libarchive does do an initial getvfsbyname() when you ask it
 to traverse a directory tree so that it can accurately handle later
 requests about mountpoints and filesystem types.  This code
 is admittedly a little intricate.
 
The problem most likely is the fact that all mountpoints are
 exposed via chroot, thus, if it's checking to see if a mountpoint
 exists, it may exist outside of the chroot.
  

I reviewed the code to refresh my memory.   Some
of what I said before was not quite right.

Libarchive's directory traversal tracks information about
the filesystem type so that clients such as bsdtar can
efficiently skip synthetic filesystems (/dev or /proc) or
network filesystems (NFS or SMB mounts).

The net effect is something like this:

   For each file:
   stat() or lstat() or fstat() the file
   look up dev number in an internal cache
   if the dev number is new:
fstatfs() the open fd to get the FS name
getvfsbyname() to identify the FS type

Unless there's a logic error in libarchive itself, this
would suggest that somehow fstatfs() is returning
a filesystem type that getvfsbyname() can't
identify.

Paul:
What filesystem are you using?

What does mount show?

Does it work outside the chroot?

Tim

___
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: r238860: bsdtar: eating up 100% CPU, hanging

2012-07-29 Thread Tim Kientzle
Do you know what the value of acl_tag is at this point?




On Jul 28, 2012, at 11:30 PM, Martin Matuska wrote:

 I am also looking into it:
 
 1. It happens only with libarchive 3.0.4 (3.0.3 works fine)
 2. It happens only if archiving files located on ZFS (UFS works fine)
 3. Backtrace:
 #0  setup_acl_posix1e (a=0x801c45100, entry=0x801d69100, acl=0x801d8a000,
archive_entry_acl_type=256)
at
 /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_disk_entry_from_file.c:474
 #1  0x000800879036 in archive_read_disk_entry_from_file (_a=0x801c45100,
entry=0x801d69100, fd=6, st=Variable st is not available.
 )
at
 /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_disk_entry_from_file.c:434
 
 This infinite loop has been fixed in libarchive master:
 https://github.com/libarchive/libarchive/commit/d8b9dbd
 d8b9dbd6dac0125957b997c2fe8d246237ec9f94
 
 I suggest you backport to release also the following:
 f67370d5c33b336b103c43fe35984defe7e0e473
 https://github.com/libarchive/libarchive/commit/f67370d
 c6d3cd33aecdc579966c3fbe7b9424cea83c7555
 https://github.com/libarchive/libarchive/commit/c6d3cd3
 
 
 Dňa 29. 7. 2012 3:18 Tim Kientzle  wrote / napísal(a):
 
 On Jul 28, 2012, at 10:21 AM, O. Hartmann wrote:
 
 When updating ports (like databases/sqlite3 or graphics/png via portmaster 
 graphics/png), the installation process comes to a point where a backup of 
 the old port is created with bsdtar. The process hangs then …
 
 My operating system is
 FreeBSD 10.0-CURRENT #0 r238860: Sat Jul 28 11:28:38 CEST 2012
 
 That's newer than my -CURRENT system here; I'm updating now.
 Martin imported a few changes from upstream just recently, so this
 is likely a new problem.
 
 What to do?
 
 Can you get the full command line for the command that's
 hanging?
 
 $ ps auxww | grep tar
 
 Knowing the exact options that were used will help narrow
 it down.
 
 Thanks for reporting it,
 
 Tim
 
 ___
 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: (void)foo or __unused foo ?

2012-07-28 Thread Tim Kientzle
On Jul 27, 2012, at 2:38 AM, Luigi Rizzo wrote:
 
 The alternative way to avoid an 'unused' warning from the compiler
 is an empty statement
 
   (void)foo;
 
 that the compiler hopefully optimizes away.

I learned the void-cast convention many years ago.
I used it throughout the libarchive code and have yet to
run into any problems.  I always use it in exactly this form
(with the exact comment here) so that I can easily search
on it:

int foo(int a) {

   (void) a; /* UNUSED */
…
}

I agree with PHK that it would be nice to express this
intent in a way that static checkers could verify.   I also
agree that having static checkers interpret comments is Evil.
But I have yet to see any alternative that was as
straightforward and widely-supported as this one.

Every other viable alternative seems to require tangled
clumps of macros.

Tim

___
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: r238860: bsdtar: eating up 100% CPU, hanging

2012-07-28 Thread Tim Kientzle

On Jul 28, 2012, at 10:21 AM, O. Hartmann wrote:

 When updating ports (like databases/sqlite3 or graphics/png via portmaster 
 graphics/png), the installation process comes to a point where a backup of 
 the old port is created with bsdtar. The process hangs then …

 My operating system is
 FreeBSD 10.0-CURRENT #0 r238860: Sat Jul 28 11:28:38 CEST 2012

That's newer than my -CURRENT system here; I'm updating now.
Martin imported a few changes from upstream just recently, so this
is likely a new problem.

 What to do?

Can you get the full command line for the command that's
hanging?

$ ps auxww | grep tar

Knowing the exact options that were used will help narrow
it down.

Thanks for reporting it,

Tim

___
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: Possible fix for Perl failing with ../lib/auto/POSIX/POSIX.so: Undefined symbol __flt_rounds on ARM

2012-06-14 Thread Tim Kientzle

On Jun 14, 2012, at 5:34 AM, Konstantin Belousov wrote:

 On Wed, Jun 13, 2012 at 08:32:19PM -0700, Tim Kientzle wrote:
 On Jun 12, 2012, at 1:49 AM, Konstantin Belousov wrote:
 
 On Jun 5, 2012, at 8:09 AM, Jan Sieka wrote:
 
 
 After investigating the issue it appeared that __flt_rounds symbol is
 not exported by libc. Applying the following patch, recompilling world
 and Perl fixed the problem and allowed to use Perl on SheevaPlug:
 
 diff --git a/lib/libc/arm/Symbol.map b/lib/libc/arm/Symbol.map
 index e8c7f1d..8cdcdaf 100644
 --- a/lib/libc/arm/Symbol.map
 +++ b/lib/libc/arm/Symbol.map
 @@ -70,6 +70,7 @@ FBSDprivate_1.0 {
  __divdf3;
  __floatsisf;
  __floatsidf;
 +   __flt_rounds;
  __fixsfsi;
  __fixdfsi;
  __fixunssfsi;
 
 
 If the symbols are used by normal programs, that I think
 we should indeed guarantee ABI stability for them, and FBSD_1.3
 namespace is the right namespace to use.
 
 Why 1.3?
 
 This is a common function across every architecture except MIPS right
 now (and that's probably easily remedied), so why would it be in
 a different section for different architectures?
 
 The libc.so built as a result is architecture-specific, so it shall
 follow the ABI and ABI history of that architecture. By the project
 policy, a symbol added during the lifetime of CURRENT-10, goes into
 FBSD_1.3 version namespace. What other arches do there is irrelevant.

Changed in r237110.

Tim
___
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: Possible fix for Perl failing with ../lib/auto/POSIX/POSIX.so: Undefined symbol __flt_rounds on ARM

2012-06-13 Thread Tim Kientzle

On Jun 12, 2012, at 1:26 PM, Konstantin Belousov wrote:

 On Tue, Jun 12, 2012 at 05:56:12PM +0200, Jan Sieka wrote:
 Both versions work indeed. I have analysed other architectures' 
 lib/libc/arch/Symbol.map files and __flt_rounds should go into FBSD_ and 
 *not* into FBSDprivate section. I have verified that at least one of the 
 Perl's libraries (POSIX.so) links to __flt_rounds. Python also links to 
 this function. So to the best of my knowledge current patch is the 
 righteous one.
 
 Let me restate my point again. It does not matter whether some application
 uses the symbol. It does matter whether the symbol is considered the part
 of exported stable ABI, intended for use by applications. If it is, then
 FBSD_1.X is the right namespace, otherwise symbol should be moved to
 private and existing usage fixed.

That particular symbol is in FBSD_1.0 for amd64, i386, ia64, powerpc, 
powerpc64, sparc64.
It's in FBSDPrivate_1.0 for arm.
It's not defined for mips at all.

The latter two seem to be bugs; I just committed r237039 to fix arm.

I haven't checked the situation on mips.

Tim




___
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: Possible fix for Perl failing with ../lib/auto/POSIX/POSIX.so: Undefined symbol __flt_rounds on ARM

2012-06-13 Thread Tim Kientzle
On Jun 12, 2012, at 1:49 AM, Konstantin Belousov wrote:
 
 On Jun 5, 2012, at 8:09 AM, Jan Sieka wrote:
 
 
 After investigating the issue it appeared that __flt_rounds symbol is
 not exported by libc. Applying the following patch, recompilling world
 and Perl fixed the problem and allowed to use Perl on SheevaPlug:
 
 diff --git a/lib/libc/arm/Symbol.map b/lib/libc/arm/Symbol.map
 index e8c7f1d..8cdcdaf 100644
 --- a/lib/libc/arm/Symbol.map
 +++ b/lib/libc/arm/Symbol.map
 @@ -70,6 +70,7 @@ FBSDprivate_1.0 {
   __divdf3;
   __floatsisf;
   __floatsidf;
 +   __flt_rounds;
   __fixsfsi;
   __fixdfsi;
   __fixunssfsi;


  If the symbols are used by normal programs, that I think
 we should indeed guarantee ABI stability for them, and FBSD_1.3
 namespace is the right namespace to use.

Why 1.3?

This is a common function across every architecture except MIPS right
now (and that's probably easily remedied), so why would it be in
a different section for different architectures?

Tim


___
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: Customizing ubldr build...

2012-05-24 Thread Tim Kientzle
On May 24, 2012, at 1:16 AM, Damjan Marion wrote:

 On May 24, 2012, at 6:35 AM, Tim Kientzle wrote:
 
 I think the PandaBoard ES is fully supported by U-Boot,
 so it should be possible to use ubldr as part of the boot
 chain for that just like I've been doing with BeagleBone.
 
 What are the benefits of using ubldr compared to what we are doing 
 today(load; go)?

For a fully custom closed embedded system, nothing.

But as we move towards more generic kernels that support more
environments, ubldr has the ability to:
  * Load the kernel from UFS (which in turn means that end users can use 
buildkernel/installkernel to update the kernel)
  * Load the device tree separately from the kernel.
  * Interactively edit the device tree
  * Preload specific modules
  * Script the boot process (the i386 interactive boot menu is a Forth script 
that runs on the stock loader; ubldr has the same ability)

Tim

___
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: Customizing ubldr build...

2012-05-23 Thread Tim Kientzle

On May 23, 2012, at 8:24 AM, Adrian Chadd wrote:

 This looks fine to me.
 
 Thanks for this! What's the pandaboard require, just out of curiosity?

Based on a quick skim of the OMAP 4460 TRM, it looks
like the Pandaboard ES should come up with the
same general memory layout as the BeagleBone,
with DRAM starting at 0x8000 .

I think the PandaBoard ES is fully supported by U-Boot,
so it should be possible to use ubldr as part of the boot
chain for that just like I've been doing with BeagleBone.

Tim

___
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


Customizing ubldr build...

2012-05-20 Thread Tim Kientzle
In order to fully automate building SD images for Beaglebone,
I'm trying to come up with a clean way to tailor the ubldr build.

I think I've come up with a good way to do this and would appreciate any 
feedback.

First, here's the (somewhat simplified) script that builds and installs ubldr 
(this
is going into the beaglebsd.sh script I've been working on):

 cd /usr/src
 buildenv=`make TARGET_ARCH=arm TARGET_CPUTYPE=arm buildenvvars`
 cd sys/boot
 eval $buildenv make obj
 eval $buildenv make UBLDR_LOADADDR=0x8010 all
 cd arm/uboot
 eval $buildenv make DESTDIR=${DESTDIR}  BINDIR=  NO_MAN=true install

The key issue is the physical load address, which differs among boards.
My idea is to allow specifying this at build time through a make
variable UBLDR_LOADADDR.

The Makefile for sys/boot/arm/uboot passes this down into a
dynamically-built loader script.  Here's a summary of the changes
I'm proposing to sys/boot/arm/uboot/Makefile:

+UBLDR_LOADADDR?=   0x100
 
 LDFLAGS=   -nostdlib -static
+LDFLAGS+=  -T ldscript.generated
 LDFLAGS+=  -T ${.CURDIR}/ldscript.${MACHINE_CPUARCH}
 
+${PROG}: ldscript.generated
+
+ldscript.generated::
+   echo UBLDR_LOADADDR = ${UBLDR_LOADADDR};  ldscript.generated

And now the standard loader script can simply use the symbol instead of
a hard-coded value:

 Index: ldscript.arm
 ===
 --- ldscript.arm   (revision 235597)
 +++ ldscript.arm   (working copy)
 @@ -5,7 +5,7 @@
  SECTIONS
  {
/* Read-only sections, merged into text segment: */
 -  . = 0x100 + SIZEOF_HEADERS;
 +  . = UBLDR_LOADADDR + SIZEOF_HEADERS;
.interp : { *(.interp)  }
.hash  : { *(.hash) }
.dynsym: { *(.dynsym)   }

This seems to work pretty well for me, except for one odd point:
the make dependencies cause ubldr to get relinked on every build.
(This can be fixed in the usual way.)

If anyone sees a better way to handle this, I'd much appreciate the input.

Cheers,

Tim

___
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: SUJ file system corruption.

2012-05-18 Thread Tim Kientzle

On May 18, 2012, at 3:18 AM, Bjoern A. Zeeb wrote:

 
 On 13. May 2012, at 22:35 , Tim Kientzle wrote:
 
 FYI:  Saw a crash due to filesystem corruption when running SUJ.
 
 This is on a ARM AM335x system (BeagleBone) that is
 still pretty experimental, so I certainly cannot rule out other
 problems, but in case it means something to
 someone, here's the scenario:
 
 Reset the board to reboot (which is routine for these
 small embedded boards) and when it came back up
 it went through SUJ recovery, and then a little later
 the kernel panicked with this stack trace:
 
 rm: /var/run/dmesg.boot: Bad file descriptor
 panic: ffs_write: type 0xc1e86660 0 (0,1024)
 
 
 Can you tell us if this was HEAD, stable/9 or 9.0-RELEASE?

Apologies:  This was with the armv6 projects tree,
which is not quite CURRENT.

Tim

___
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


SUJ file system corruption.

2012-05-13 Thread Tim Kientzle
FYI:  Saw a crash due to filesystem corruption when running SUJ.

This is on a ARM AM335x system (BeagleBone) that is
still pretty experimental, so I certainly cannot rule out other
problems, but in case it means something to
someone, here's the scenario:

Reset the board to reboot (which is routine for these
small embedded boards) and when it came back up
it went through SUJ recovery, and then a little later
the kernel panicked with this stack trace:

rm: /var/run/dmesg.boot: Bad file descriptor
panic: ffs_write: type 0xc1e86660 0 (0,1024)
KDB: enter: panic
[ thread pid 492 tid 100044 ]
Stopped at  $d: ldrbr15, [r15, r15, ror r15]!
db bt
Tracing pid 492 tid 100044 td 0xc1dbc5c0
kdb_enter() at kdb_enter+0xc
scp=0xc0321c08 rlv=0xc02f0024 (panic+0xe8)
rsp=0xcb3e3ba8 rfp=0xcb3e3bbc
r4=0x0100
panic() at panic+0x10
scp=0xc02eff4c rlv=0xc043b2f4 (ffs_write+0x114)
rsp=0xcb3e3bd0 rfp=0xcb3e3c48
ffs_write() at ffs_write+0xc
scp=0xc043b1ec rlv=0xc049d55c (VOP_WRITE_APV+0x128)
rsp=0xcb3e3c4c rfp=0xcb3e3cf0
r10=0x00020001 r9=0x
r8=0x r7=0x r6=0x r5=0xcb3e3cfc
r4=0xc055a78c
VOP_WRITE_APV() at VOP_WRITE_APV+0xc
scp=0xc049d440 rlv=0xc0390ca4 (vn_write+0x28c)
rsp=0xcb3e3cf4 rfp=0xcb3e3d3c
r7=0xcb3e3db4 r6=0xc1dc09a0
r5=0xc1e86660 r4=0x
vn_write() at vn_write+0xc
scp=0xc0390a24 rlv=0xc0339c88 (dofilewrite+0x98)
rsp=0xcb3e3d40 rfp=0xcb3e3d70
r10=0x r9=0x0400
r8=0xc1dc09a0 r7=0xc1dbc5c0 r6=0x0001 r5=0xcb3e3db4
r4=0x
dofilewrite() at dofilewrite+0xc
scp=0xc0339bfc rlv=0xc033b508 (kern_writev+0x60)
rsp=0xcb3e3d74 rfp=0xcb3e3da8
r10=0x r9=0xbfffecec
r8=0xc1dbc5c0 r7=0xcb3e3db4 r6=0x0001 r5=0x
r4=0x
kern_writev() at kern_writev+0xc
scp=0xc033b4b4 rlv=0xc033b620 (sys_write+0x58)
rsp=0xcb3e3dac rfp=0xcb3e3de0
r8=0x r7=0xc1d9a000
r6=0xc1dbc5c0 r5=0xcb3e3eac r4=0x2047c400
sys_write() at sys_write+0xc
scp=0xc033b5d4 rlv=0xc048934c (swi_handler+0x2d0)
rsp=0xcb3e3de4 rfp=0xcb3e3ea8
swi_handler() at swi_handler+0xc
scp=0xc0489088 rlv=0xc047c440 (swi_entry+0x28)
rsp=0xcb3e3eac rfp=0xbfffea5c
r10=0x2017be50 r8=0x2041c000
r7=0x002d r6=0x0400 r5=0x2017cc18 r4=0x2047c400


Rebooted and ran fsck -y without using the journal and noticed:

** Phase 2 - Check Pathnames
UNALLOCATED  I=244  OWNER=root MODE=0
SIZE=0 MTIME=Jan  1 00:00 1970 
NAME=/var/run/dmesg.boot

UNEXPECTED SOFT UPDATE INCONSISTENCY


If I can find a way to reproduce this, I'll let you know.

Cheers,

Tim



___
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: make installworld fails

2012-05-03 Thread Tim Kientzle

On May 3, 2012, at 1:34 PM, AN wrote:

 Thu May  3 16:25:27 EDT 2012
 
 FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #13 r234872: Tue May  1 
 13:09:55 EDT 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL  amd64
 
 # svn up
 Updated to revision 234981
 
 I did build world/kernel, after booting into single user mode and trying make 
 installworld I get the following error:
 
 /usr/src/Makefile Line:219 check date and time
 
 I have seen this failure before, previously I was able to open the make file 
 and comment out the date and time check, but this time the file seems 
 corrupted, I am not able to open the file in vi.
 
 What causes this check to fail?  Is there any way to detect this possibility 
 before rebboting to single user?

Try looking very critically at the system date and time:
 $ date

This check is comparing the system time to the timestamps of
the files on disks to try to detect whether your system clock
is correct.  Since the 'make' program relies on comparing timestamps,
you can get very strange results if your system clock is not consistent.

You can use the date utility to set the system clock to
the approximately correct time (it doesn't need to be very
exact).  If you have networking, you can use ntpdate pool.ntp.org
to set the clock from the network.

Tim

___
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: [RFC] Un-staticise the toolchain

2012-05-01 Thread Tim Kientzle

On Apr 30, 2012, at 6:41 AM, Erik Cederstrand wrote:
 
 Can anyone explain to me why the dynamically linked version is significantly 
 slower? What are the extra steps involved compared to a statically linked 
 binary?

At the risk of dramatically over-simplifying….

When a static binary is started by the kernel, it does the following:
  * Initializes some libc internals.
  * Calls main.

When a dynamic binary is started by the kernel, it does the following:
  * Initializes some libc internals.
  * For every dynamic library referenced by this executable:
   - loads the dynamic library into memory
   - fixes up references
  * Calls main

The process of loading the required libraries and fixing up references
can be quite time-consuming.

Cheers,

Tim

___
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: [RFC] Un-staticise the toolchain

2012-04-28 Thread Tim Kientzle
On Apr 28, 2012, at 3:03 AM, Bob Bishop wrote:
 
 On 28 Apr 2012, at 04:12, David O'Brien wrote:
 
 On Thu, Apr 26, 2012 at 12:38:03PM +0100, Bob Bishop wrote:
 Apparently, current dependencies are much more spread, e.g. /bin/sh
 is dynamically linked [etc]
 
 That seems like a bad mistake, because it would prevent even booting
 single-user if rtld/libraries are broken.
 
 When one enters single user they are prompted for which shell to use.
 If /bin/sh is broken due to being dynamic, '/rescue/sh' will likely still
 work.
 
 Yes. You to have a statically linked /rescue/sh on board, so what's the point 
 of /bin/sh being dynamic? The memory footprint really isn't an issue, and for 
 my money the default shell ought to be bombproof.

By default shell, I think you mean the shell loaded by default
in single user mode.  That shell could be /rescue/sh.

Single-user recovery does not require /bin/sh being static.

Tim

___
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: HEADSUP: /etc/malloc.conf format change

2012-04-25 Thread Tim Kientzle

On Apr 25, 2012, at 10:43 AM, Jason Evans wrote:

 
 On a related note, is there any way to find all ports that refer to 
 _malloc_options without extracting source for all of them?  I considered 
 being proactive about finding software that depends on _malloc_options, but 
 no tractable approaches came to mind.

Yes, there actually is.

The Ports maintainers will run experimental ports builds on the
port build clusters to help verify potentially disruptive changes
like this before they are committed.

Ask on ports@ for more details.

Tim

___
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: /usr/bin/tar creates invalid lib file

2012-03-26 Thread Tim Kientzle
On Mar 26, 2012, at 1:42 AM, Andriy Gapon wrote:

 on 26/03/2012 11:04 Boris Samorodov said the following:
 26.03.2012 03:25, Tim Kientzle пишет:
 Boris:  What filesystem are you using?
 
 zfs
 
 
 Could this particular instance of the problem be triggered by
 http://www.freebsd.org/cgi/query-pr.cgi?pr=164445
 ?

Yes, that could definitely be related.

It will take me a day or two to get a fix into libarchive.

Tim

___
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: /usr/bin/tar creates invalid lib file

2012-03-25 Thread Tim Kientzle

On Mar 25, 2012, at 5:53 AM, Boris Samorodov wrote:

 On 24.03.2012 21:00, Tim Kientzle wrote:
 
 On Mar 23, 2012, at 9:51 PM, Boris Samorodov wrote:
 
 Can you send me the output of:
 
 tar -cvf /tmp/test.tar 
 /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1
 
 (A tar archive containing only that one source file.)
 
 This looks similar to a bug that we found in libarchive recently
 I didn't think that bug impacted FreeBSD, but I may have been
 wrong….  if it did, it will be obvious from the structure of the
 created archive.
 
 The following file is extracted after tarring:
 -
 % hd libnspr4.so.1
   32 0a 30 0a 30 0a 32 34  31 39 37 31 0a 30 0a 00 |2.0.0.241971.0..|
 0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ||
 *
 0200
 -
 
 The tar file itself attached (3KB in length).

Ugh.  I'll probably need your help to diagnose this more precisely.

Here is the root problem:   tar thinks this is a sparse file
with nothing in it.On FreeBSD, bsdtar now uses
lseek(SEEK_HOLE) to identify holes in the file.  For
some reason, bsdtar is storing this file as just one big hole.

There are a lot of things here that don't make sense:

  * The extracted file should be all zero bytes.  (The 2.0.0.241971.0. is the 
sparse file map, it's not really part of the file.)  How are you extracting 
this?

  * Can you run the tar command under truss or ktrace and look for calls to 
lseek()?  That would help verify that this is really a tar bug and not a 
filesystem or kernel bug.

I'll spend some time today to see if I can reproduce the problem here.

Tim

___
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: /usr/bin/tar creates invalid lib file

2012-03-25 Thread Tim Kientzle

On Mar 25, 2012, at 2:43 PM, Gleb Kurtsou wrote:

 On (25/03/2012 10:53), Tim Kientzle wrote:
 
 On Mar 25, 2012, at 5:53 AM, Boris Samorodov wrote:
 
 On 24.03.2012 21:00, Tim Kientzle wrote:
 
 On Mar 23, 2012, at 9:51 PM, Boris Samorodov wrote:
 
 Can you send me the output of:
 
 tar -cvf /tmp/test.tar 
 /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1
 
 (A tar archive containing only that one source file.)
 
 This looks similar to a bug that we found in libarchive recently
 I didn't think that bug impacted FreeBSD, but I may have been
 wrong….  if it did, it will be obvious from the structure of the
 created archive.
 
 The following file is extracted after tarring:
 -
 % hd libnspr4.so.1
   32 0a 30 0a 30 0a 32 34  31 39 37 31 0a 30 0a 00 
 |2.0.0.241971.0..|
 0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
 ||
 *
 0200
 -
 
 The tar file itself attached (3KB in length).
 
 Ugh.  I'll probably need your help to diagnose this more precisely.
 
 Here is the root problem:   tar thinks this is a sparse file
 with nothing in it.On FreeBSD, bsdtar now uses
 lseek(SEEK_HOLE) to identify holes in the file.  For
 some reason, bsdtar is storing this file as just one big hole.
 
 I experience a related issue. lseek(SEEK_HOLE) error checks are too
 strict. Files are not added to archive if lseek(SEEK_HOLE) fails.
 Ignoring lseek(SEEK_HOLE) at least in ENOTTY case would be preferable.

This has already been fixed upstream.  I'll get the
fix merged soon…

Boris:  What filesystem are you using?

Tim

___
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: /usr/bin/tar creates invalid lib file

2012-03-25 Thread Tim Kientzle

On Mar 25, 2012, at 2:43 PM, Gleb Kurtsou wrote:

 I experience a related issue. lseek(SEEK_HOLE) error checks are too
 strict. Files are not added to archive if lseek(SEEK_HOLE) fails.
 Ignoring lseek(SEEK_HOLE) at least in ENOTTY case would be preferable.

Just noticed that lseek(1) doesn't document ENOTTY as
a valid response code.

Should it?

Tim


___
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


Can't build devel/git on -CURRENT?

2012-03-25 Thread Tim Kientzle
I've tried adding
   CONFIGURE_ENV+=  CHARSET_LIB=-lcharset
to the port Makefile, but still no joy:

$ cd /usr/ports/devel/git
$ make
…..
libgit.a(gettext.o): In function `git_setup_gettext':
gettext.c:(.text+0x4f): undefined reference to `locale_charset'
gmake: *** [git-daemon] Error 1
*** Error code 1

Stop in /usr/ports/devel/git.
*** Error code 1

___
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: /usr/bin/tar creates invalid lib file (was: Re: /usr/bin/strip: File format not recognized)

2012-03-24 Thread Tim Kientzle

On Mar 23, 2012, at 9:51 PM, Boris Samorodov wrote:

 On 24.03.2012 01:29, Dimitry Andric wrote:
 On 2012-03-23 21:12, Boris Samorodov wrote:
 I'm not sure but it seems to me that the question is more about
 -current that -ports.
 
 While updating devel/nspr I get this:
 ...
 /usr/bin/strip: /usr/local/lib/libnspr4.so.1: File format not recognized
 
 It builds and installs fine here, both on i386 and amd64, using both gcc
 and clang.
 
 What is the output of: file /usr/local/lib/libnspr4.so.1 on your
 system?
 
 I've done some steps to diagnose the case. Seems that /usr/bin/tar
 does not create correct library:
 -
 % file 
 /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1
 /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1:
  ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically 
 linked, not stripped
 % file /usr/local/lib/libnspr4.so.1
 /usr/local/lib/libnspr4.so.1: data
 % hd -C /usr/local/lib/libnspr4.so.1
   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ||
   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ||
 *
 % tar --version
 bsdtar 3.0.3 - libarchive 3.0.3
 -
 
 The library (/usr/local/lib/libnspr4.so.1) is created by the command:
 -
 /usr/bin/tar -C 
 /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib 
 --dereference -cf - . |  /usr/bin/tar -C /usr/local/lib -xof -
 -

Can you send me the output of:

tar -cvf /tmp/test.tar 
/usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1

(A tar archive containing only that one source file.)

This looks similar to a bug that we found in libarchive recently
I didn't think that bug impacted FreeBSD, but I may have been
wrong….  if it did, it will be obvious from the structure of the
created archive.

Tim

___
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: rtld or lang/gcc cannot find libgcc_s.so.1

2012-02-25 Thread Tim Kientzle

On Feb 23, 2012, at 9:16 AM, Alexander Kabaev wrote:

 On Tue, 21 Feb 2012 21:11:13 -0800
 Tim Kientzle t...@kientzle.com wrote:
 
 
 If I understand correctly, the libgcc in base is pretty stripped
 down compared to regular libgcc, because most of that
 stuff is in our libc instead. 
 
 
 You understand it a bit wrong, but your conclusions are correct. libgcc
 in base is not stripped in any way and is supposed to be identical to
 one coming from upstream.

So where is __umodsi3 supposed to be defined for ARM?

In FreeBSD, libgcc refers to it but does not define it.
It's defined in libc.

I stumbled across this trying to link some freestanding
ARM code using the native cross-compilers.  The link
failed if I used -nostdlib because of a handful of symbols
such as this.

Tim

___
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: rtld or lang/gcc cannot find libgcc_s.so.1

2012-02-21 Thread Tim Kientzle

On Feb 21, 2012, at 3:39 PM, Daniel Eischen wrote:

 On Tue, 21 Feb 2012, Steve Kargl wrote:
 
 3) Add a new option to ldconfig to prepend new libraries to
  the hints files and fix the ports to use this option instead
  of -m.
 
 You don't want system binaries that want /lib/libgcc_s.so.1
 to use /usr/local/lib/gccXX/libgcc_s.so.1, though.  Wouldn't
 your option 3 do that?

Why not?  Would it cause problems?

Is libgcc from GCC 4.6 incompatible with /lib/libgcc?

If I understand correctly, the libgcc in base is pretty stripped
down compared to regular libgcc, because most of that
stuff is in our libc instead.  So if there were compatibility
problems, I'd expect those to show up when GCC 4.6 linked
programs against /usr/local/.../libgcc and /lib/libc.

Tim

___
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: rescue build broken?

2012-02-20 Thread Tim Kientzle
On Feb 20, 2012, at 5:57 AM, Adrian Chadd wrote:

 Hi,
 
 Is anyone seeing this?
 
 (cd /usr/home/adrian/work/freebsd/svn/src/rescue/rescue/../../usr.bin/tar
   make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/tar/
 depend  make -DRESCUE CRUNCH_CFLAGS=-DRESCUE
 DIRPRFX=rescue/rescue/tar/ bsdtar.o cmdline.o getdate.o read.o subst.o
 tree.o util.o write.o err.o line_reader.o matching.o pathmatch.o)
 make: don't know how to make
 /usr/home/adrian/work/freebsd/svn/src/usr.bin/tar/bsdtar.c. Stop
 *** Error code 2
 1 error
 
 
 I'm doing a cross-build on i386 to MIPS.

What make command are you running?

Tim

___
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: i18n and shell scripts

2012-01-22 Thread Tim Kientzle

On Jan 22, 2012, at 2:05 PM, Ron McDowell wrote:

 I'm working on the new bsdconfig, and looking for some good examples of how 
 to incorporate internationalization into the scripts.  I'm not finding much 
 love in this area. :-(
 
 Any pointers appreciated.


GNU gettext may not be an option here, but the documentation at

   http://www.gnu.org/software/gettext/manual/gettext.html#sh

outlines how this can be done.

The general model used by gettext and lots of other translation systems is:
   * There's a distinctive function name or source code pattern wrapping the 
English text strings.
   * So you can run a simple program that identifies and extracts these 
strings.  (Simple sed or awk scripts often suffice.)
   * Translation files map English text == translated text.  (There are many 
more-or-less standard formats used for translation files; the .po format used 
by gettext is widely supported by translation tools.  In particular, there are 
a number of commercial translation management interfaces that allow free use by 
open-source projects and can directly upload/download po files.)
   * Translation files can be compiled into some dictionary structure that can 
be used efficiently at run time.
   * The distinctive source code pattern above is typically a function name.  
At run-time, that function looks up the English text string from the source 
file and emits the result.

Nothing here is difficult to just build from scratch.  The complex part is the 
process for actually keeping track of what has and hasn't been translated 
across a large number of languages.  Fortunately, there are some pretty good 
translation management systems on the web where you can upload .po files, 
invite people to contribute translations and then download constructed .po 
files for each language.  At work, we've started using getLocalization.com, 
which looks pretty promising, but there are many others.

Warning:  Translating quantities (e.g., $x bytes) is complicated (why does 
'zero' take a plural in English?).  You can sometimes just avoid it (size in 
bytes: $x) and sometimes get by with stilted language (e.g., 1 bytes or $x 
byte(s)).  If you require high-quality handling of phrases that include 
variable numbers, then you'll need something more complex than just a lookup 
table.

Cheers,

Tim

___
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: WITH_ICONV/WITH_BSD_GREP: Defaults?

2012-01-07 Thread Tim Kientzle
On Jan 5, 2012, at 12:04 PM, O. Hartmann wrote:
 
 Another story seems to be with WITH_ICONV. I didn't realize problems
 until I had harsh faults compiling port lang/gcc46 which tend to fail in
 a Makefile when WITH_ICONV is enabled. 

What exactly is the failure you're seeing?

I ask because I've recently been wrestling with
autoconf trying to generate a configure script that
will DTRT on systems with more than one iconv()
function available.  The standard autoconf recipes
don't seem to work correctly in this case.  (I've
seen it on MacOS when GNU libiconv is installed
in addition to the iconv implementation in libc
in the base system.  I presume the same problem
arises on FreeBSD.)

In short:  this could be a bug in the configure script
rather than a bug in FreeBSD's iconv implementation.

Tim

___
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: bsdtar --gname switch

2011-10-18 Thread Tim Kientzle
On Oct 17, 2011, at 3:25 PM, Benjamin Kaduk wrote:
 On Mon, 17 Oct 2011, Romain Garbage wrote:
 
 According to bsdtar(1) manpage, tar has a --gname switch that permits
 to set an arbitrary groupname in the tar archive, but:
 $ tar -cf foo.tar --gname root bar
 tar: Option --gname is not supported
 
 I get the same error for --uname and --gid switches. I'm running
 9.0-BETA3 (r226421). Does this have any chances to be corrected in a
 not to far away future?
 
 This is, at present, a documentation bug.
 FreeBSD svn revision 207786 was Various manpage updates, including many 
 long-option synonyms that were previously undocumented, which added the 
 gname long-format option to bsdtar.1.  However, this option is not present in 
 usr.bin/tar/cmdline.c in FreeBSD head, though it was added in r2349 of 
 upstream libarchive sources on May 1, 2010.  So, it looks like it should have 
 been in libarchive since 2.8.4; however, pulling tarballs for 2.8.4 and 2.8.5 
 it does not seem that gname is listed in cmdline.c for either of them.
 
 I'm not familiar with the libarchive release process; Tim, can you shed some 
 insight on what happened here?

Looks like the manpage got updated to the latest version from
libarchive/trunk.  Unfortunately, some of the features described
there are not present in libarchive 2.8.

It looks like it might be easy to back port some of these
features.  They don't seem to rely on any of the deeper
changes to libarchive internals that have happened
since 2.8.

Tim

___
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


iconv not reporting errors?

2011-09-11 Thread Tim Kientzle
I'm trying to use the iconv that's in FreeBSD-CURRENT and it's not reporting 
errors the way I expect.  To demonstrate, here's a test program that tries to 
convert UTF-8 to KOI8-R.  This should report an error, since the UTF-8 string 
here ĐÒÉ×ÅÔ contains characters not available in KOI8-R.

On FreeBSD-CURRENT (updated yesterday), the iconv() call returns 0, consumes 
the entire input, and generates 9 characters D`O'ExA^O.  I believe that the 
call should return 6 in this case, since each of the six input characters were 
converted to non-identical characters in the output.

The term non-identical is used in the return value description of:
http://pubs.opengroup.org/onlinepubs/007908799/xsh/iconv.html

For comparison, I tried this on MacOS, where the iconv() call returns -1, 
consumes no input, and generates no output.


#include iconv.h
#include stdio.h
#include string.h

int
main(int argc, char **argv)
{
  const char *input = \303\220\303\222\303\211\303\227\303\205\303\224;
  const char *in = input;
  size_t insize = strlen(in);
  char outbuff[64];
  char *out = outbuff;
  size_t outsize = sizeof(outbuff);
  iconv_t cd = iconv_open(KOI8-R, UTF-8);
  size_t s = iconv(cd, in, insize, out, outsize);
  *out = '\0';

  printf(s = %d\n, (int)s);
  printf(insize = %d\n, (int)insize);
  printf(outsize = %d\n, (int)outsize);
  printf(%s, outbuff);
  return (0);
}

___
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: makefs(8) broken iso9660 images

2011-08-14 Thread Tim Kientzle
On Wed Aug 10 11, Test Rat wrote:
  $ tar tf FreeBSD-9.0-HEAD-20110810-JPSNAP-bootonly.iso | fgrep -i kernel
  [nothing]
  $ mount -t cd9660 /dev/$(mdconfig -f 
 FreeBSD-9.0-HEAD-20110810-JPSNAP-bootonly.iso) /media
  $ ls -1 /media/boot/kernel
  aac.ko
  accf_data.ko


As you found earlier, makefs and makeisofs lay out the disk images differently.
This has revealed a regression in libarchive that causes it to not see
the contents of certain directories.  (Specifically, it appears that any 
directory
that follows a non-directory on the image is ignored.)

Tim

___
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: bsdtar(1) can't extract new ISO images

2011-08-08 Thread Tim Kientzle
On Aug 7, 2011, at 9:23 AM, Bruce Cran wrote:
 On 06/08/2011 18:02, Martin Matuska wrote:
 The error is in FreeBSD ISO images.
 They are created using makefs and that doesn't create ISO files that
 strictly comple to the ECMA-119 (ISO9660 standard).
 
 I have already filed a PR at NetBSD (bin/45217):
 http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=45217
 
 The volume_set_id doesn't have to be filled with 0x20 characters, too.
 I am also preparing a patch for libarchive (different things), but that
 won't fix that one bug - makefs needs to be fixed.
 
 Thanks for the information - I suspect this is also the problem I saw a few 
 weeks ago on OS X Lion when trying to extract an ISO of Windows Server 2003 
 R2:
 
 neutrino:tmp brucec$ tar -xvf 
 en_win_srv_2003_r2_standard_with_sp2_cd2_X13-68583.iso
 neutrino:tmp brucec$ echo $?
 0
 
 It would be nice if bsdtar exited with a non-zero code in this case.

I agree, it would be nice.

ISO images frequently begin with a large block of zero bytes that looks exactly 
like a tar end-of-file marker.  So if libarchive doesn't recognize it as an 
ISO, it will often recognize the file as a valid empty tar archive that has a 
bunch of garbage after the end-of-archive marker.  So it successfully extracts 
no files.

This sort of problem should become less common as we continue to refine the 
bidding heuristics used in libarchive.  If you have ideas for further improving 
them, I'm definitely interested.  (At a minimum, I'm always interested in 
seeing at least the first 32k or so of any file that tar -tvvvf gives the 
wrong format for.)

Tim

___
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


  1   2   3   >