t towards any problems. All looks good.
Also, the subject line mentions "geometry does not match label", but
you did not mention anything it in your email about it. Again, it
by itself does not indicate a problem.
Thanks,
--
Marcel Moolenaar
xcl...@mac.com
___
com/)
I don't believe Path64 has an ia64 backend (it's optimized for amd64),
but that may be pulled from Open64. I think Path64 may be a better
investment than Open64 (for FreeBSD), if the project is more open...
> I understand no fbsd ports for these compilers exist yet?
Corre
out of date.
open64 includes ORC. I believe ORC is EOL.
> And then there's something called Aurora, which seems to be the same
> as ORC (http://sourceforge.net/projects/ipf-orc/), but also *very*
> out of date.
They probably renamed the project. It does look like the same
thing.
c is now obsoleted. When dropping into
the installation process, I realised that the 8 partition boundary
is still present.
sysinstall does not use gpart nor the kernel interface that GEOM_PART
exposes.
FYI,
--
Marcel Moolenaar
xcl...@mac.com
?
Are you referring to pluto1 and pluto2 or are these
entirely different beasts?
Unless a developer with specific interest in ia64 steps up to help,
you may be out of luck. Sorry.
I'll see about fixing it...
--
Marcel Moolenaar
xcl...@ma
On Jun 27, 2009, at 4:15 AM, Ivan Voras wrote:
Marcel Moolenaar wrote:
On Jun 25, 2009, at 4:02 AM, Anton Shterenlikht wrote:
dev_taste(DEV,mirror/gm0)
g_part_taste(PART,mirror/gm0)
GEOM: mirror/gm0: the secondary GPT table is corrupt or invalid.
GEOM: mirror/gm0: using the primary only
PT winning (again the result of gmirror using the last sector
on a disk for metadata).
Alternatively, make sure gmirror got loaded at boot.
FYI,
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mai
n't have to make
a custom kernel in that case.
FYI,
--
Marcel Moolenaar
[EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Mar 24, 2007, at 5:41 AM, Mike Tancsa wrote:
At 02:10 AM 3/24/2007, Marcel Moolenaar wrote:
Try changing the frequency from COM_FREQ to (4 * COM_FREQ). The
HTH,
Thanks, it fixed it! BTW, would this be for all such cards with
this PCI ID ? If so, should I file a PR ? If not
FREQ to (4 * COM_FREQ). The
frequency is driving the baudrate generator and given that the
baudrate is off by a factor of 4, it follows that we program the
baudrate generator with a divisor that corresponds to a frequency
that's off by a factor of 4 as well.
HTH,
--
Marcel Moolenaar
[
partitioning scheme).
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
t;printf" should work after cninit(). But now it seems to
> work only after msgbufinit().
printf() does work right after cninit(). The output just doesn't get
saved in the message buffer. Hence, dmesg(8) doesn't show it, but it
certainly gets printed
On Tue, Jun 17, 2003 at 01:02:36PM -0400, Alexander Kabaev wrote:
> On Tue, 17 Jun 2003 09:01:41 -0700
> Marcel Moolenaar <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Jun 17, 2003 at 08:49:23AM -0700, Joe Kelsey wrote:
> > Linux uses the same linker (GNU ld). Fixing the li
On Tue, Jun 17, 2003 at 09:31:54AM -0700, Joe Kelsey wrote:
> Marcel Moolenaar wrote:
> >Yes it can. Symbol resolution is a fundamental part in linking.
> >Hence, the linker has all the information it needs to filter the
> >gratuitously long list of libraries programmers t
king.
Hence, the linker has all the information it needs to filter the
gratuitously long list of libraries programmers tend to give it
and keep the libraries that actually contributed to the link.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
On Tue, Jun 17, 2003 at 08:49:23AM -0700, Joe Kelsey wrote:
> Marcel Moolenaar wrote:
> >On Tue, Jun 17, 2003 at 06:38:29AM -0700, Joe Kelsey wrote:
> >
> >>Basically, what I want to do is remove several entries from the *front*
> >>of the dynamic section.
.
It's more constructive to fix the linker than it is to patch the
ELF files created by it. The linker knows which libraries are
really needed and should be able to create the minimal list of
(true) dependencies.
--
Marcel Moolenaar USPA: A-39004
17 matches
Mail list logo