On September 24, 2016 at 11:14:38 AM, O. Hartmann (ohart...@zedat.fu-berlin.de)
wrote:
Am Sat, 24 Sep 2016 10:33:26 -0700
Marcel Moolenaar schrieb:
> On September 24, 2016 at 10:26:44 AM, O. Hartmann
> (ohart...@zedat.fu-berlin.de) wrote:
>
> Recent sources of CURRENT (r306
On September 24, 2016 at 10:26:44 AM, O. Hartmann (ohart...@zedat.fu-berlin.de)
wrote:
Recent sources of CURRENT (r306298) fail to build while WITH OFED is selected:
That’s me. Looking into it.
signature.asc
Description: Message signed with OpenPGP using AMPGpg
incremental build (after updating
the source tree) or otherwise first rename all *.So files to *.pico.
FYI,
—
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To
tion to get a bootable Atom SoC image to create yet another
> distribution or can the installer choose the proper device.hints
> dynamically during boot?
FreeBSD should really get rid of any default hints by now; or at least
limit the hints to what is absolutely certain to be needed
> On Aug 18, 2015, at 7:46 AM, O. Hartmann wrote:
>
> Am Tue, 18 Aug 2015 07:35:25 -0700
> Marcel Moolenaar schrieb:
>
>>
>>> On Aug 17, 2015, at 10:15 PM, O. Hartmann
>>> wrote:
>>>
>>> Port security/heimdal installs its own ftp
uld raise an eyebrow right away...
--
Marcel Moolenaar
mar...@xcllnt.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
thought I'd check anyway to see if the aforementioned change was
> indeed intentional, since I wasn't able to dig up any discussion about it.
It’s a direct consequence.
--
Marcel Moolenaar
mar...@xcllnt.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
> On Jun 17, 2015, at 9:35 AM, Andrey Chernov wrote:
>
> Signed PGP part
> On 17.06.2015 16:58, Marcel Moolenaar wrote:
> >
> >> On Jun 16, 2015, at 9:53 PM, Andrey Chernov
> >> wrote:
> >
> >> Should be no any %FF, but single cha
difference:
fbsdvm64% env LANG=ru_RU.KOI8-R touch `env LANG=ru_RU.KOI8-R printf "\377"`
fbsdvm64% ls -al
total 8
-rw-r--r-- 1 marcel staff0 Jun 17 06:56 %FF
drwxr-xr-x 3 marcel staff 102 Jun 17 06:56 .
drwxr-xr-x 12 marcel staff 408 Jun 17 06:55 ..
--
Marcel Moolenaar
mar...@
> On Jun 16, 2015, at 8:46 PM, Andrey Chernov wrote:
>
> Signed PGP part
> On 17.06.2015 6:23, Marcel Moolenaar wrote:
> > Date/time is fixed. I don?t know how to reproduce the filename
> > problem, so make sure sources are up-to-date and if still a
> > pro
make sure sources are up-to-date and if still a
problem, provide me with a way to reproduce.
Thanks,
--
Marcel Moolenaar
mar...@xcllnt.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
uptime?
Any concrete errors, output or misbehavior?
Ideally: can you reproduce the problem?
--
Marcel Moolenaar
mar...@xcllnt.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
ple and you don't own the machine.
You quickly realize that without MAKEOBJDIRPREFIX or with
files in /etc (like /etc/make.conf) that you can't tweak,
you quick;y realize how error prone everything and how
much time you end up wasting.
--
Marcel Moolenaar
mar...@xcllnt.net
sign
On Sep 24, 2014, at 12:54 PM, John Baldwin wrote:
> On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote:
>> What is going on here?
>> Are we still in some kind of flux and people aren't done yet or is
>> this the intended state by virtue of noone having
host this way. Granted we seriously sucked in this
regard to begin with but we seem to have regressed to the point of
having absolutely no working support whatsoever.
What is going on here?
Are we still in some kind of flux and people aren't done yet or is
this the intended state by
On Aug 25, 2014, at 12:48 AM, Andrey V. Elsukov wrote:
> On 25.08.2014 03:55, Marcel Moolenaar wrote:
>>> Though, w/ people dd'ing images onto disks, and using growfs to grow
>>> as necessary, we might want to allocate a few more more than the
>>> minimum.
Is there a need to create partitions with specific
indices (i.e. index 6 for a typical 'f' partition)?
Answers to these questions could help figure this out...
--
Marcel Moolenaar
mar...@xcllnt.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
ptions or has all kinds of
bugs -- just like the logic in the loader apparently.
By having mkimg create a large table, even if it's knows
up front that it doesn't have to may prevent broken code
from tripping over, bit it surely bloats the image for
no reason.
--
Marcel Moolenaar
mar...@
e how the loader is responsible for *the*
problem. All I see in qemu is that the loader, when
it reads a sector, isn't getting the actual sector
data that's in the image.
Just do a ktrace on qemu and you'll see what I mean.
YMMV of course,
--
Marcel Moolenaar
mar...@xcllnt.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
an also try emitting vmdk directly to see if
that makes a difference. vmdk also has the side-
effect of rounding the image to the grain size.
--
Marcel Moolenaar
mar...@xcllnt.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
qemu.
o VMware and VirtualBox are fine.
o A non-FreeBSD hosted qemu also works fine.
If your host is running -current, make sure to set
MALLOC_CONF=junk:false. It improves behaviour on
FreeBSD for boot0/boo1.
HTH (probably not),
--
Marcel Moolenaar
mar...@xcllnt.net
signature.asc
Descr
r266974, please also revert the other
3 revisions as they depend on r266974.
FYI,
--
Marcel Moolenaar
mar...@xcllnt.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
on the fly, change the terminal type/class to any of
the "3wire." or "std." types, where is the baudrate.
And don't forget to SIGHUP init(8) after making changes, otherwise the changes
don't take effect!
FYI,
--
Marcel Moolenaar
mar...@xcllnt.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
gt; clutter the code. Please can you test it with Juniper's gcc?
It compiles fine and I immediatelt applied the fix to Juniper's tree.
Thanks for the quick turn-around!
--
Marcel Moolenaar
mar...@xcllnt.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
expertise.
We need to continue to be able to build the sources with compilers
outside of the tree as much as possible and I haven't found a way
yet (one I don't dislike to be precise) to get this blocks stuff
to compile. It's a huge blocker right now.
Thanks,
--
Marcel Moolenaar
ma
> mkstemp() / mkdtemp() in an incomprehensible way.
Will do. Thanks David,
--
Marcel Moolenaar
mar...@xcllnt.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
_CREAT|O_EXCL,0600) = 3 (0x3)
close(3) = 0 (0x0)
So for some reason when /tmp/ exists and is a directory, then the
compiler wants to create a temporary file underneath that directory. That
looks like a bug to me. Do people concur and thus shall I file a PR?
--
Marcel Moolenaar
mar...@xcllnt.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
On Jun 3, 2013, at 11:29 AM, Marcel Moolenaar wrote:
>
>> * Even if the python code is wrong, is this one of those things that's
>> going to keep biting us going forward? Interactions between
>> dlopen/dlsym/rtld/library dependencies/embedded malloc
>> replace
+1,6 @@
+ ffi_sources = """
+ src/prep_cif.c
+ src/closures.c
+-src/dlmalloc.c
+ """.split()
+
+ ffi_platforms = {
It seems the root cause is a broken python build that accidentally
defines malloc(), free(), at al in _ctypes.so. A longer explanation
was
bsd.sys.mk has grown unreadable, try unraveling the conditionals
to see if WARNS for GCC does the equivalent for CLANG. Is the problem
specific to architectures that don't use CLANG?
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-current@freebsd.o
On Jul 16, 2012, at 12:30 AM, Anton Shterenlikht wrote:
> On ia64 netstat -r broke some time
> between 8.1-release, and r237134.
Can you file a PR so that it's being tracked.
Thanks,
--
Marcel Moolenaar
mar...@xcllnt.net
___
free
have pretty much the same, except for the IPFILTER
options. I'm not concerned about.
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe,
on-sleepablefatal kernel trap (cpu 0):
> locks held:
I think you're kernel is seriously screwed-up. Do you have any
non-standard (for ia64) kernel configuration options?
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-current@freebsd.org maili
oader prompt.
SOmething like the following could do the trick:
set init_path="/sbin/init.bak"
FYI,
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-c
already suggested a few things in this thread. Go read it.
I'm bored now, so I'll just wait for UEFI booting to be forced upon
those who mirror the whole disk with gmirror. I think that's when
we will have a more substantial and meaningful continuation of this
thread.
--
Marcel Mo
On Jun 28, 2012, at 12:49 PM, Alexander Leidinger wrote:
> On Thu, 28 Jun 2012 08:33:17 -0700 Marcel Moolenaar
> wrote:
>
>> My advise is to leave disk mirroring to H/W or firmware solutions and
>> use FreeBSD mirroring for FreeBSD partitions only. If you want to
>
On Jun 28, 2012, at 10:25 AM, Pawel Jakub Dawidek wrote:
> On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote:
>>
>> On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote:
>>>
>>> All of the above is ugly, U'm afraid :(
>>
>> Ind
One violates
the spec on grounds of making the *unique* disk identifier non-unique by
presenting OSes with multiple disks that have identical IDs.
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-current@freebsd.org mailing list
http://lists.f
On Jun 27, 2012, at 1:48 PM, Andrey V. Elsukov wrote:
> On 28.06.2012 00:14, Marcel Moolenaar wrote:
>>> Our loader detects that primary GPT header is damaged. It tries to read
>>> backup GPT header from the last LBA and it detects that there is
>>> "GEOM
On Jun 27, 2012, at 12:27 PM, Andrey V. Elsukov wrote:
> On 27.06.2012 21:55, Marcel Moolenaar wrote:
>> You can't just re-interpret standards to match a context you know very well
>> isn't applicable and consequently redefine what the word "device" means.
>
d be discoverable by non-FreeBSD.
That clearly isn't the case -- hence it's not standards compliant. What
for example if someone wanted to share the swap partition between Linux
and FreeBSD?
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-c
On Jun 27, 2012, at 11:20 AM, Pawel Jakub Dawidek wrote:
> On Wed, Jun 27, 2012 at 10:37:11AM -0700, Marcel Moolenaar wrote:
>>
>> On Jun 26, 2012, at 10:37 AM, John Baldwin wrote:
>>>
>>> GPT really wants the backup header at the last LBA. I know you can
sn't the only
one. Granted, it can easily be the simplest one or even the
best one in some cases, but that's besides the point you were
making.
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-current@freebsd.org mailing list
http://list
tc) for
no apparent reason and without any kind of warning that what he/she is doing
is potentially harmful... That's the spirit!
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/
e time.
I see that as a better way of looking at it than simply blurting out
that you shouldn't use gmirror when certain awkward and artifical
conditions apply.
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-current@freebsd.org mailing list
http:/
proven to not deliver on that.
This is actually impacting existing FreeBSD consumers already, like
Juniper. So, se should not go deeper into this rabbit hole. We should
finally solve this problem for real...
--
Marcel Moolenaar
mar...@xcllnt.net
___
${MACHINE} == "i386" || ${MACHINE} == "amd64"
>> +SRCS+= uart_cpu_x86.c
>> .endif
>> SRCS+= bus_if.h card_if.h device_if.h isa_if.h ${ofw_bus_if} pci_if.h \
>>power_if.h pccarddevs.h serdev_if.h
>> ------
All,
Please review the attached changes (done by Dmitry -- CC'd) to add support for
PT_FOLLOW_EXEC and cleanup PT_FOLLOW_FORK.
I'll commit this when there are no comments/objections.
Thanks,
--
Marcel Moolenaar
marc...@juniper.net
Index: sys/kern/k
-
In general I think it's a bad idea to revive sysinstall. It doesn't
function appropriately on most architectures that FreeBSD supports
and it's definitely the opposite of what we've been working towards
for at least th
ot;, hz);
>> -goto again;
>> -}
>> -mnt = name;
>> -error = parse_mount(&mnt);
>> -if (error == -1) {
>> -printf("Invalid specification.\n");
>> -goto again;
>> -}
>
read different and contradictory things (0 being an
invalid phandle in OF, negative phandles exist, etc).
3. We change the implementation, if such is warranted, in
a separate effort.
The point really is that 0 is an invalid phandle right now,
right or wrong, and JCs changes are based on that. I see no
problem proceeding on the path we're on, while we discuss
what's the correct implementation and whether or not we
should have a course change...
Thoughts?
--
Marcel Moolenaar
mar...@xcllnt.net
___
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 be proper to pull the change that introduced it
> out
> of the release branch (r214006) ?
Don't be ridiculous.
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis
ailure mode or rate.
As such, I suspect GCC. It'll be difficult to find the bad
code.
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, s
On Aug 29, 2011, at 1:21 AM, Andriy Gapon wrote:
> on 27/08/2011 18:16 Marcel Moolenaar said the following:
>>
>> On Aug 26, 2011, at 2:07 PM, Andriy Gapon wrote:
>>
>>>
>>> It seems that after the introduction of the mountroot scripting language a
>
prompt with a reboot command,
so that the user/operator is does not have to worry
about typos *and* don't have to trigger a panic just
so that he/she can initiate a reboot.
Thoughts?
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-current@freeb
n gpart and
> userland), then it seems like we would lose the ability of gpart to validate
> its parameters. Who would be responsible for inserting this GEOM into the
> stack?
Between the disk GEOM and the gpart GEOM. The gpart utility would
still interact with the GEOM is
details by itself".
What about inserting a special class for doing commit/undo. The GEOM
simply keeps all modifications in memory and 1) forgets everything on
an undo operation or 2) writes all dirty sectors on a commit. This
could be used even instead of the g
, create new ones using a
different scheme and populate it with partitions without there
being a single write to disk. The commit/undo logic worked
just as well for those operations as the simpler ones. Did that
get broken or are you just mistaken?
--
Marcel Moolenaar
mar..
On Aug 16, 2011, at 1:12 AM, Anton Shterenlikht wrote:
> On Mon, Aug 15, 2011 at 06:34:51PM +0100, Anton Shterenlikht wrote:
>> On Fri, Aug 12, 2011 at 05:45:55PM -0700, Marcel Moolenaar wrote:
>>>
>>> On Aug 12, 2011, at 7:19 AM, Anton Shterenlikht wrote
On Aug 12, 2011, at 7:19 AM, Anton Shterenlikht wrote:
> On ia64 r221488
Please update to at least r223700, as that was a major stability fix.
Latest and greatest is preferred though.
FYI,
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-curr
re you have (QLogic card version), what FreeBSD release you
>> are running, would help. A verbose dmesg would be useful.
>
> I got it again. But this time the network seems fine.
If you haven't updated to the latest sources, please do so.
If you did already, please make sure you do
interrupt
handling. Be it masked interrupts or the inability
to have the interrupt thread running.
I have some important improvements in the pipeline
that significantly improve stability. I'm doing a
final test and then I'll commit. It may address the
issue as a side-effect.
FYI,
--
;> acpi_cpu.c:(.text+0xab2): undefined reference to
>> `cpu_can_deep_sleep' acpi_cpu.c:(.text+0xaf0): undefined reference
>> to `cpu_can_deep_sleep' *** Error code 1
>
> Sorry, it should be fixed by r223449. I have no idea why
> kern_clocksource.c was excluded for i
I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support
>> -I/src/sys/gnu/fs/xfs -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe
>> -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS
>> -include opt_global.h -fno-common -finline-
show msgbuf
Thanks,
--
Marcel Moolenaar
mar...@xcllnt.net
___
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"
k is not needed
anymore.
FYI,
--
Marcel Moolenaar
xcl...@mac.com
___
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"
On Mar 23, 2011, at 1:25 AM, Jeff Roberson wrote:
> I did not notice this was still failing. I didn't realize this make universe
> would pull in my modules. I will fix this now.
Thanks!
powerpc and ia64 have been failing since the ofed commit as well.
FYI,
--
Marcel Mo
On Mar 18, 2011, at 6:51 PM, Nathan Whitehorn wrote:
> On 03/15/11 12:20, Marcel Moolenaar wrote:
>> On Mar 14, 2011, at 7:13 AM, Nathan Whitehorn wrote:
>>
>>> I just committed (r219641) changes that make the release infrastructure
>>> (src/release/Makefile)
n: can we support an array by
having 2 driver instances?
Thanks,
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "fr
t; criticism, and testing for this project over the last few months!
Thanks Nathan,
I checked ia64 and it works well enough. I may come back with a tweak
here and there after the dust settles, but so far it's more reliable
(and a while lot simpler) than sysinstall is.
Great work!
--
Mar
makes sure that we don't leak the denormal/unnormal mask
bit in fp_except_t and also that we don't clobber it.
--------
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-curren
to the perforce branch it was done on, not the partitioning
scheme).
In it you'll find a diff for sbin/pe/disk.c that contains logic
for presenting a friendly "disk" name. Not complete, but maybe
good for inspiration...
FYI,
--
Marcel Moolenaar
xcl...@mac.com
_
ve
byte order of the CPU. Having native encoding functions help.
You could use bcopy as well, but the compiler is typically too smart
for its own good and it will try to optimize the call away. This
leaves you with the same misaligned access that you tried to avoo
On Jan 21, 2011, at 7:25 AM, Alexander Kabaev wrote:
> On Thu, 20 Jan 2011 17:11:13 -0800
> Marcel Moolenaar wrote:
>
>>
>> On Jan 20, 2011, at 12:31 PM, Alexander Kabaev wrote:
>>
>>> On Thu, 20 Jan 2011 21:17:40 +0100
>>> Ulrich Spörlein wro
ools for
> this exact purpose.
Actually no. The buildtools target is there to allow building programs
that are not installed, but are otehrwise needed to compile a program.
These are typically little tools that create source files.
The bootstrap target is the to deal with compatibility in case we
you. I'll work with you on this after the dust
has settled.
FYI,
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to &
should only be
set by the kernel when mounting its root file system".
The parse_mount() function name has no meaning other than within
sys/kern/vfs_mountroot.c, so referring to it isn't making things
clear.
FYI,
--
Marcel Moolenaar
xcl...@mac.com
x27;t...
> it's weird).
>It seems to ignore the directives in mount.conf:
>
> # cat mount.conf
> .onfail continue
> .ask
The filename to use is "/.mount.conf". Notice the period.
--
Marcel Moolenaar
xcl...@mac.com
___
fre
cc? Should I worry about the EH support?
BTW: The chroot seems functional from the minimal
testing I've done so far. We're not DOA! :-)
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/ma
27;t do it over the
weekend), feel free to grab the revision and commit it to
-stable.
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send a
way. Maybe not, in
which case I still need to figure out why r_debug_state cannot be found.
BTW: r_debug_state is in the symbol map -- I don't think any other rtld
symbols that rtld references are in the symbol map...
FYI,
--
Marcel Moolenaar
xcl...@mac.com
___
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"
On Oct 19, 2010, at 9:38 PM, Andrey V. Elsukov wrote:
> On 20.10.2010 2:33, Marcel Moolenaar wrote:
>>> What about the attached patch? I'm going to give it a swirl soon. The
>>> difference is that it tests whether dev begins with /dev/.
>>
>> Interest
On Oct 19, 2010, at 2:21 PM, Xin LI wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 10/19/10 08:49, Marcel Moolenaar wrote:
>>
>> On Oct 19, 2010, at 7:55 AM, Andrey V. Elsukov wrote:
>>
>>> On 19.10.2010 09:03, Andrey V. Elsukov wr
w. Listing
exceptions doesn't scale and we now have 2 (the first was
the empty device name as used by nfs, and now also zfs).
Good catch, BTW.
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.o
; ENODEV but according to the dmesg the device do exist.
>
> Yes, i have the same problem.
Can you both boot verbose and send me the output.
Also, please boot with -a and show me the console
output, as well as the output of the '?'
tem is borked. Nonetheless, let me
>> upgrade myself and see if I run onto it too.
>
> I did "fsck -f" in single user mode - all seems fine:
I see the svn problem too. I've tried to find suspicious
commits, but only found c
gt; sequence
> #
>
I think your file system is borked. Nonetheless, let me
upgrade myself and see if I run onto it too.
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
On Jun 24, 2010, at 8:53 AM, Dag-Erling Smørgrav wrote:
> Marcel Moolenaar writes:
>> Can check if you have /usr/local/lib/liblzma on your other machines. I
>> have this nagging feeling that you're picking up a library outside of
>> your object tree.
>
> That
Sorry for the top post:
Anton,
Can check if you have /usr/local/lib/liblzma on your other machines. I have
this nagging feeling that you're picking up a library outside of your object
tree.
Also: can you send the contents of /etc/make.conf
Thx
--
Marcel (Mobile)
On Jun 24, 2010, at 1:36 A
ut a new one from scratch, provided
you're not sharing sandboxes across NFS. I would also
manually destroy your object tree under /usr/obj (or
whereever you have it) before doing the buildworld.
It's not impossible (double negative to emphasize that
the possibility may not be b
On May 31, 2010, at 12:52 AM, Roman Divacky wrote:
> Hi,
>
> I would like to propose to integrate clang/LLVM into FreeBSD HEAD
> in the near future (days, not weeks).
*nod of approval*
--
Marcel Moolenaar
xcl...@mac.com
___
fre
gainst 0x60 ~ 0x1b5?
The intend was to prevent false positives. I think it's probably best
to remove the checksumming and deal with false positives differently:
such as by making sure that the partition has the right type...
--
Marcel Moolenaar
xcl...@mac.com
_
7;s weak and you typically don't
have the Z8530 SCC driver on amd64), so it's being returned
when DDB looks up symbols at address 0. This then implies
that ifc_simple_create() called a NULL function pointer.
FYI,
--
Marcel Moolenaar
xcl...@mac.com
_
l unlucky WD Advanced Format disks users. :-D
A better approach is to have tunables for geom_disk to do this. This should
absolutely
not be part of a partitioning tool. It violates everything there is to violate
AFAICT.
FYI,
--
Marcel Moolenaar
xcl...@mac.com
__
; thread 11
This should give you something like:
[ thread pid 1 tid 11 ]
kdb_enter+0x92: [I2] addl r14=0xffe279b8,gp ;;
Then type the following for a backtrace:
db> bt
FYI,
--
Marcel Moolenaar
xcl...@mac.com
__
only gpart command you can use is:
gpart create -s gpt ad1
This creates a new GPT on the disk, wiping out whatever was there...
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/ma
y not a good idea
to have a single option for multiple features, even if the code has
them intertwined. Code changes easily, but options typically don't.
Maybe we should improve our config to include dependencies, so that
one only has to add "options INVARIANTS" and config knows to i
;s now called COMPAT_FREEBSD32, which doesn't make a
lot of sense because what if I only want to support Linux/ia32 and not
FreeBSD/ia32 (or vice-versa if you club them under a single COMPAT_*32)?
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-
ou should be able to
upgrade to HEAD. I have one more fix pending that's needed for
preemption, but you should not hold off an upgrade for that...
FYI,
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-current@freebsd.org mailing list
http://
On Mar 21, 2010, at 1:27 PM, Anton Shterenlikht wrote:
> It seems the problems I've had in the last
> several days with ldd/csup/svn/rm have the
> same root cause.
I'm aware of the issue. Give me a few days to fix it. I have a
fix under test, but it exposes other prob
1 - 100 of 512 matches
Mail list logo