Re: 8.0 upgrade geometry does not match label
On Apr 29, 2010, at 6:07 AM, Reinhard Haller wrote: Hi, as far as I know my disk is not operating in dangerously dedicated mode. Despite this I'm unable to upgrade to freebsd 8.0. Please explain how or why you can't upgrade. The information you gave does not point 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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: open64 fbsd port?
On Nov 20, 2009, at 8:47 AM, Anton Shterenlikht wrote: Is there a fbsd port of open64 (http://www.open64.net/), or any branched project? Not at this time. In particular there is a mention of ORC (http://ipf-orc.sourceforge.net/) specifically for ia64, but the pages are very 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. FYI, -- Marcel Moolenaar xcl...@mac.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: open64 fbsd port?
On Nov 20, 2009, at 9:01 AM, Anton Shterenlikht wrote: On Fri, Nov 20, 2009 at 04:47:41PM +, Anton Shterenlikht wrote: Is there a fbsd port of open64 (http://www.open64.net/), or any branched project? In particular there is a mention of ORC (http://ipf-orc.sourceforge.net/) specifically for ia64, but the pages are very out of date. 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. And also there is OpenUH, primarilily for ia64, but linux: OpenUHSource code, IA-64, Red Hat Enterprise Linux AS release 3 and gcc 3.x openuh-alpha.src.tar.gz 90.2 MB Looks like a branch off of Open64. and Path64 (http://www.path64.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? Correct. -- Marcel Moolenaar xcl...@mac.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Installer: missing GEOM/gpart capabilities slicing disk?
On Nov 9, 2009, at 12:51 AM, O. Hartmann wrote: Hello. I try to install a fresh new FreeBSD 8.0-RC2 (from snapshot-DVD) on a barndnew harddrive. As far as I recall partitioning a disk is now done via gpart and the limitation of having only 8 (-2) partitions from a through h except b and 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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: ports lang/gcc4x fail to build on ia64
On Aug 17, 2009, at 7:36 AM, Mark Linimon wrote: The package building cluster is currently only set up to try builds on amd64, i386, and sparc64. Although we have some ia64 machines, the last time I tried to upgrade them I had trouble. Really, you have ia64 machines for ports building? 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...@mac.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: gmirror gm0 destroyed on shutdown; GPT corrupt
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 -- recovery suggested. ^^^ You created the mirror after the GPT, which means you destroyed the GPT backup header. gmirror uses the last sector on the disk for metadata and that by itself is a cause for various problems. It's better to use gmirror per partition. Or create the GPT partition inside the gmirror device - then the GPT backup table will be at last_sector-1, but... You could run into a race condition between GPT and gmirror and GPT winning (again the result of gmirror using the last sector on a disk for metadata). unfortunately this could still happen, and will lead to the same error if GPT is tasted first, since it is embedded in the first sector and will assume the whole drive is available to GPT, and will then proceed to not find its backup data in the last sector. It looks to me like GEOM classes should have a priority field for tasting. Any objections to that idea? Using the last sector is not only flawed because it creates a race condition, it's flawed in the assumption that you can always make a geom part of a mirror by storing meta-data on the geom without causing corruption. This whole idea of using the last sector was so that a fully partitioned disk with data could be turned into a mirrored disk. A neat idea, but hardly the basis for a generic mirroring implementation when it silently corrupts a disk. I think it's better to change gmirror to use the first sector on the provider. This never creates a race condition and as such, you don't need to invent a priority scheme, that has it's own set of flaws on top of it. The only downside is that it's not easy to make a fully partitioned and populated disk part of a mirror: one would need to move the data forward one sector to free the first sector. This we can actually do by inserting a GEOM that does it while I/O is still ongoing. The good thing is: we need a class that does exactly this for implementing the move verb in gpart. In other words: Solving the problem that putting the metadata in the first sector creates, can and will be re-used in implementing the gpart move partition feature. I doubt anyone will complain that the creation of a mirror brings with it a few hours of disk activity that does not inhibit normal operation... -- Marcel Moolenaar xcl...@mac.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: gmirror gm0 destroyed on shutdown; GPT corrupt
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 -- recovery suggested. ^^^ You created the mirror after the GPT, which means you destroyed the GPT backup header. gmirror uses the last sector on the disk for metadata and that by itself is a cause for various problems. It's better to use gmirror per partition. #echo 'geom_mirror_load=YES' /boot/loader.conf Is /boot a symlink for /efi/boot? GEOM_MIRROR: Device gm0 destroyed. ^ This is normal. And when the system is rebooted, there is no /dev/mirror anymore. You could run into a race condition between GPT and gmirror and GPT 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/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: GPT Support on Freebsd
On Oct 30, 2008, at 6:36 AM, John Baldwin wrote: Ok, so it's not a PMBR. My understanding is that a GPT requires the MBR to be a PMBR (only one partition in the 4th slot with a special type of 0xee that covers the whole disk). What this box is doing is trying to make the MBR match the first 4 partitions in the GPT. I'm not sure if you will be able to get FreeBSD's GPT stuff to recognize that reliably. Marcel (cc'd) might have some ideas. In FreeBSD 6, the kernel checks explicitly for a PMBR when it checks for a GPT. Besides being part of the specification, it also avoids conflicts. In the GEOM framework, there's no a priori support for having one GEOM control another. When there's a valid MBR as well as a valid GPT, it's undeterministic which one will be used, unless they both cooperate. They don't. This is where GPart helps out. In FreeBSD 7 and up, GPart supports multiple partitioning schemes, including MBR and GPT. The kernel will not enforce a PMBR in front of a GPT, because upon detecting both a MBR and a GPT, the GPT will be used. However, this only applies when the kernel is configured with GEOM_PART_MBR and not with GEOM_MBR. At this time GEOM_MBR is still the default. So, to make it work for you, you need at least FreeBSD 7.1 (to be released shortly) or use next month's snapshot and build a custom kernel without GEOM_MBR and with GEOM_PART_MBR. In FreeBSD 8 and up GPart is the default and you won'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]
Re: fixing a PUC / uart speed issue
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, apart from keeping a private set of patches, whats the best way to work around this with each cvsup / buildworld ? Well, the clock frequency used to feed the UART is really a property of the add-in card, not of the chipset (Oxford in this case). While many PCI cards have the vendor ID and device ID of the Oxford chipset (and its manufacturer), it doesn't really help us to identify the particular add-in card. IIRC, the sub-vendor and sub-device IDs are all zeroes in your case. I doubt that we can use that to match the actual add-in card and therefore use a 4x clock. Other cards exist that are based on the Oxford chipset that use different clocks and if they too have a sub-device or sub-vendor ID of all zeroes, then there's still a conflict. Maybe it's worthwhile to detect the clock frequency by programming the UART for a fixed baudrate and then checking (using loopback) how fast characters are being transmitted. Based on that it should be possible to determine the right frequency. Alternatively, we could also just use hints. In any case: changing the entry in puc(4) will likely break some other card, so that not a good idea. 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]
Re: fixing a PUC / uart speed issue
On Mar 23, 2007, at 9:49 PM, Mike Tancsa wrote:
Hi,
I have a mini-pci UART that has a problem with its speed. When I
connect to it at 300bps the other side sees this as 1200. e.g.
Other PC PUC device
4800 1200
9600 2400
19200 4800
*snip*
I am guessing something needs to be changed in the puc driver for it ?
/* Oxford Semiconductor OX16PCI954 PCI UARTs */
{ Oxford Semiconductor OX16PCI954 UARTs,
{ 0x1415, 0x9501, 0, 0 },
{ 0x, 0x, 0, 0 },
{
{ PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ },
{ PUC_PORT_TYPE_COM, 0x10, 0x08, COM_FREQ },
{ PUC_PORT_TYPE_COM, 0x10, 0x10, COM_FREQ },
{ PUC_PORT_TYPE_COM, 0x10, 0x18, COM_FREQ },
},
},
but what ?
Try changing the frequency from COM_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
[EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mac osx disklabels
On Jun 20, 2005, at 10:56 AM, [EMAIL PROTECTED] wrote: I wonder, can FreeBSD read GPT organized disks (ia64) under i386? Yes, but you typically cannot boot from a GPT disk. This applies to all platforms FreeBSD supports (with the obvious exception of ia64 of course, where GPT is the native 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]
Re: printf doesn't work in ia64_init()?
On Tue, Jul 27, 2004 at 08:38:00AM +, M.M. Yang wrote: Hi all, I'm reading the function ia64_init()sys/ia64/ia64/machdep.c, and try to use printf to output some information. But if I put printf before msgbufinit(), I won't see any word I expect by using dmesg. That's correct. In the same function after cninit(), it comments: /* * Initialize the console before we print anything out. */ cninit(); /* OUTPUT NOW ALLOWED */ So I have thought 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 to the system console. Look at the console... -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
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. Actually, I would settle for just removing all of a certain tag (such as DT_NEEDED) from 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 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
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. Actually, I would settle for just removing all of a certain tag (such as DT_NEEDED) from 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. This cannot be accomplished by fixing the linker. The issue is one of attempting to use a *linux* shared library in a native application. Linux uses the same linker (GNU ld). Fixing the linker will have the same effect on Linux as it will have on FreeBSD and hence will prevent unnecessary dependencies in Linux libraries to Linux libraries and thus remove the need to patch ELF files in the long run. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
On Tue, Jun 17, 2003 at 09:13:04AM -0700, Joe Kelsey wrote: 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. This cannot be accomplished by fixing the linker. The issue is one of attempting to use a *linux* shared library in a native application. Linux uses the same linker (GNU ld). Fixing the linker will have the same effect on Linux as it will have on FreeBSD and hence will prevent unnecessary dependencies in Linux libraries to Linux libraries and thus remove the need to patch ELF files in the long run. The problem cannot be resolved by fixing ld. The problem arises from people who specify unnecessary libraries on their ld command lines. ld cannot tell the difference between a required library and an unnecessary library at link time. 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 tend to give it and keep the libraries that actually contributed to the link. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
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 tend to give it and keep the libraries that actually contributed to the link. I know of no way to do this in the case of shared libraries. When linking shared libraries, the linker *cannot* resolve any references to other shared libraries other than list them in the .dynamic section with some sort of tag such as DT_NEEDED. Please explain to me how the linker can prune the shared library list at link time. If a symbol is unresolved, it must be present in one of the libraries on the link line. If the symbol is in an archive library, you pull in the code. Otherwise, if it's in a shared library, you record the dependency on that library. In the end you have no unresolved symbols, all code from archives has been linked in and you have a complete list of dependencies that is a subset of the libraries given on the command line. For partial linking (incremental linking) the list of unresolved symbols does not have to be empty. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tools to modify shared libraries
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 linker will have the same effect on Linux as it will have on FreeBSD and hence will prevent unnecessary dependencies in Linux libraries to Linux libraries and thus remove the need to patch ELF files in the long run. LD putting a library in DT_NEEDED regardless of whether or not library exports any required symbols as long as it appears on command line is a feature, not a bug AFAIK. It's a bug because DT_NEEDED serves the purpose of recording library dependencies. Any library that does not contribute to symbol resolution is by definition not a dependency. Hence, its presence in DT_NEEDED only makes the dependency information wrong. Dependency information that's wrong is untrustworthy and unreliable and thus unusable. Hence, a bug. Immediate consequences of broken dependency information is the increased startup time of shared binaries, the restriction in use of libraries in cases where they can be used and the obstruction in replacing libraries with different implementations by possibly causing artificial conflicts due to unnecessary loading of libraries. Only explicit user directives should allow adding libraries to DT_NEEDED regardless of whether there's actually a dependency. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
