Re: Mixing amd64 kernel with i386 world
On Sat, 28 Sep 2013, Peter Jeremy wrote: I have a system with 4GB RAM and hence need to use an amd64 kernel to use all the RAM (I can only access 3GB RAM with an i386 kernel). OTOH, amd64 processes are significantly (50-100%) larger than equivalent i386 processes and none none of the applications I'll be running on the system need to be 64-bit. This implies that the optimal approach is an amd64 kernel with i386 userland (I'm ignoring PAE as a useable approach). I've successfully run i386 jails on amd64 systems so I know this mostly works. I also know that there are some gotchas: - kdump needs to match the kernel - anything accessing /dev/mem or /dev/kmem (which implies anything that uses libkvm) probably needs to match the kernel. For whatever it is worth, I have done this running a ppc32 userland with a ppc64 kernel (that is how ppc64 was first developed actually, before the 64-bit userland existed) and it worked just fine. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking
On 09/04/13 11:00, John Baldwin wrote:
On Wednesday, September 04, 2013 10:11:28 am Nathan Whitehorn wrote:
On 09/04/13 08:20, Ryan Stone wrote:
On Wed, Sep 4, 2013 at 8:45 AM, Nathan Whitehorn
wrote:
Could you describe what this macro is supposed to do so that we can do
the
porting work?
-Nathan
#define GET_STACK_USAGE(total, used)
GET_STACK_USAGE sets the variable passed in total to the total amount
of stack space available to the current thread. used is set to the
amount of stack space currently used (this does not have to have
byte-precision). Netgraph uses this to decide when to stop recursing
and instead defer to a work queue (to prevent stack overflow). I
presume that Alexander is using it in a similar way. It looks like
the amd64 version could be ported to other architectures quite easily
if you were to account for stacks that grow up and stacks that grow
down:
http://svnweb.freebsd.org/base/head/sys/amd64/include/proc.h?revision=233291&view=markup
/* Get the current kernel thread stack usage. */
#define GET_STACK_USAGE(total, used) do {\
struct thread*td = curthread;\
(total) = td->td_kstack_pages * PAGE_SIZE;\
(used) = (char *)td->td_kstack +\
td->td_kstack_pages * PAGE_SIZE -\
(char *)&td;\
} while (0)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
I think that should be MI for us anyway. I'm not aware of any
architectures FreeBSD supports with stacks that grow up. I'll give it a
test on PPC.
ia64 has the double stack thingie where the register stack spills into a stack
that grows up rather than down. Not sure how sparc64 window spills are
handled either.
Ah, very well. That's weird. Should be fine for PPC, however.
-Nathan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking
On 09/04/13 08:20, Ryan Stone wrote:
On Wed, Sep 4, 2013 at 8:45 AM, Nathan Whitehorn wrote:
Could you describe what this macro is supposed to do so that we can do the
porting work?
-Nathan
#define GET_STACK_USAGE(total, used)
GET_STACK_USAGE sets the variable passed in total to the total amount
of stack space available to the current thread. used is set to the
amount of stack space currently used (this does not have to have
byte-precision). Netgraph uses this to decide when to stop recursing
and instead defer to a work queue (to prevent stack overflow). I
presume that Alexander is using it in a similar way. It looks like
the amd64 version could be ported to other architectures quite easily
if you were to account for stacks that grow up and stacks that grow
down:
http://svnweb.freebsd.org/base/head/sys/amd64/include/proc.h?revision=233291&view=markup
/* Get the current kernel thread stack usage. */
#define GET_STACK_USAGE(total, used) do {\
struct thread*td = curthread;\
(total) = td->td_kstack_pages * PAGE_SIZE;\
(used) = (char *)td->td_kstack +\
td->td_kstack_pages * PAGE_SIZE -\
(char *)&td;\
} while (0)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
I think that should be MI for us anyway. I'm not aware of any
architectures FreeBSD supports with stacks that grow up. I'll give it a
test on PPC.
-Nathan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking
On 09/04/13 02:01, Alexander Motin wrote: On 04.09.2013 00:48, Olivier Cochard-Labbé wrote: On Tue, Sep 3, 2013 at 8:10 PM, Outback Dingo wrote: Can anyone confirm how well tested/stable this patch set might be?? if theres positive input i have a zoo of dev machines i could load it on, to help further it. Just checking to see how widely its been tested, I've installed this patch on 3 differents machines there status after about 12hours: - SUN FIRE X4170 M2 (amd64: r255178) with 6 SAS harddrives in one big zraid (LSI MegaSAS Gen2 controller): Used for generating package with poudriere… no probleme since; - HAL/Fujitsu SPARC64-V (sparc64: r255178) with two SCSI-3 disks in gmirror: Used for generating package with poudriere too… no probleme since; I've forgot to mention, but GEOM direct dispatch is now active only on x86 because GET_STACK_USAGE macro now defined only there and I wanted to stay on a safe side. On other archs GEOM works in old queued way. Somebody should port that small macro to other archs. But that is still interesting data point. Thanks. Could you describe what this macro is supposed to do so that we can do the porting work? -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On 05/27/13 23:36, Alfred Perlstein wrote: On 5/27/13 6:53 PM, Nathan Whitehorn wrote: On 05/27/13 20:40, Alfred Perlstein wrote: On 5/27/13 2:23 PM, Bruce Cran wrote: On 27/05/2013 21:28, Alfred Perlstein wrote: On 5/27/13 11:40 AM, Bruce Cran wrote: Yes. Is this a joke? It probably /was/ too short a reply. Personally I think there should be a single UI and scripting interface across all platforms. We should try and get pc-sysinstall running on all of them first in case there's some problem that means it can't be done, in which case we'd need to use a different backend. There are just going to be certain platforms that make it EASY to do cool things. We should embrace that! That's why there are different platforms! Some are great for low power, others are great for graphics, cpu power, gpu, networking etc. If we always go for the lowest common denominator then we are crippling all the platforms for no one's benefit. Even if something CAN be done, if it is very difficult, or just never happening, then we can't limit everyone's experience based on the more difficult and/or resource strapped platforms. It's just not good business. Yes, and all of this cuts both ways: pc-sysinstall has no wireless setup support, for instance. Right now we support what we support because it is the most feature-complete thing we have, not just on tier-2 platforms but also on x86. To bring this discussion back to the ground, the fact is that we lack an installer that has both internal support for ZFS and a UI. One of the reasons for this is that making a good expressive UI for ZFS is a non-trivial undertaking given its enormous flexibility. The bsdinstall partition editor has been written to be extensible for this, and several people have started writing code to do it, but no one ended up having time to finish. Probably a reasonable thing to do is to start with supporting only a minimal set of features. If anyone felt like actually writing this code, I'm sure it would be appreciated by all and be more productive than email exchanges. -Nathan I'm sure if there was a list of reasonable things, such as wireless then pc-sysinstall could be augmented. This is the first I've heard of that. All the other complaints have been based on portability. Is that all that is required now, wireless? There are more, as well. A partial list of missing features on both sides is here: https://wiki.freebsd.org/PCBSDInstallMerge. Other major ones are IPv6 (maybe this has changed?) and no jail setup feature. Most of the existing disk partitioning code in pc-sysinstall, which is the only thing in a FreeBSD installer that is at all complicated, is also *extremely* fragile and needs in all likelihood to be entirely replaced. The merge effort stalled because of this kind of issue -- doing a "merge" rapidly became rewriting both from scratch. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On 05/27/13 20:40, Alfred Perlstein wrote: On 5/27/13 2:23 PM, Bruce Cran wrote: On 27/05/2013 21:28, Alfred Perlstein wrote: On 5/27/13 11:40 AM, Bruce Cran wrote: Yes. Is this a joke? It probably /was/ too short a reply. Personally I think there should be a single UI and scripting interface across all platforms. We should try and get pc-sysinstall running on all of them first in case there's some problem that means it can't be done, in which case we'd need to use a different backend. There are just going to be certain platforms that make it EASY to do cool things. We should embrace that! That's why there are different platforms! Some are great for low power, others are great for graphics, cpu power, gpu, networking etc. If we always go for the lowest common denominator then we are crippling all the platforms for no one's benefit. Even if something CAN be done, if it is very difficult, or just never happening, then we can't limit everyone's experience based on the more difficult and/or resource strapped platforms. It's just not good business. Yes, and all of this cuts both ways: pc-sysinstall has no wireless setup support, for instance. Right now we support what we support because it is the most feature-complete thing we have, not just on tier-2 platforms but also on x86. To bring this discussion back to the ground, the fact is that we lack an installer that has both internal support for ZFS and a UI. One of the reasons for this is that making a good expressive UI for ZFS is a non-trivial undertaking given its enormous flexibility. The bsdinstall partition editor has been written to be extensible for this, and several people have started writing code to do it, but no one ended up having time to finish. Probably a reasonable thing to do is to start with supporting only a minimal set of features. If anyone felt like actually writing this code, I'm sure it would be appreciated by all and be more productive than email exchanges. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On 05/27/13 16:23, Bruce Cran wrote: On 27/05/2013 21:28, Alfred Perlstein wrote: On 5/27/13 11:40 AM, Bruce Cran wrote: Yes. Is this a joke? It probably /was/ too short a reply. Personally I think there should be a single UI and scripting interface across all platforms. We should try and get pc-sysinstall running on all of them first in case there's some problem that means it can't be done, in which case we'd need to use a different backend. I'd point out that bsdinstall does have a scripting interface now as well. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On 05/25/13 13:26, Bruce Cran wrote: On 25/05/2013 17:15, Matt Olander wrote: From my vague recollection, we discussed improving bsdinstall by tying it in with pc-sysinstall, which we've been threatening to do for at least a year. Also, there was much discussion about Devin's bsdconfig perhaps tying in with a Google SoC Project. I think Devin was nominated for most of the work, since he was unable to defend himself :P Thanks. From previous discussions with Devin I think he has other plans for the installer that don't involve pc-sysinstall. But since it seems the future is all sh(1) code, I won't be able to contribute. https://wiki.freebsd.org/PCBSDInstallMerge lists a few limitations with pc-sysinstall - are these being fixed? I'm not aware of any movement there (on either side of the table). I'd personally be very suspicious of an all-sh(1) future -- by far the cleanest parts of bsdinstall are in C -- and this is especially true for interacting with geom. That said, since I've lost nearly all of my free time and ability to work on bsdinstall, I won't get in the way of anyone else working on things -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On 11/18/12 01:31, Konstantin Belousov wrote:
On Sat, Nov 17, 2012 at 11:05:40PM -0800, Perry Hutchison wrote:
[trimmed some of the lists]
Chris Rees wrote:
... git doesn't work with our workflow.
I'm sure the workflow itself is documented somewhere, but is
there a good writeup of _how_ git doesn't work with it, e.g. what
capabilit{y,ies} is/are missing? Seems this might be of interest
to the git developers, not because they necessarily want to support
FreeBSD as such, but as an example of a real-world workflow that git
currently does not handle well.
Git would work well with our workflow. It supports the centralized
repository model, which the project employs right now.
The biggest issues, assuming the project indeed decides to move to Git
right now, are the migration costs, both in the term of the technical
efforts needed, and the learning curve for the most population of the
committers.
Relatively minor problem, at least with the current rate of the commits,
would be a commit race, when the shared repo head forwarded due to the
parallel commit. The issue should be somewhat mitigated by the Git
allowance to push a set of changes in one push.
git would be a huge step backward from svn for the central repo in lots
of ways. Besides being (in my experience) extremely fragile and
error-prone and the issues of workflow that have been brought up, the
loss of monotonic revision numbers is a really major problem. Switching
SCMs as a result of a security problem is also an action totally
disproportionate with the issue that should not be made in a panic.
Having more [cryptographic] verifiability in the release process is a
good thing; it is not strictly related to the choice of version control
system.
-Nathan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Build 32 bit binaries on amd64
On 08/21/12 08:44, John Baldwin wrote: On Tuesday, August 21, 2012 4:49:30 am Konstantin Belousov wrote: On Mon, Aug 20, 2012 at 08:32:41PM -0600, Dan McGregor wrote: Hi. I've been working on porting compiler-rt/clang's support for address sanitization (asan) to FreeBSD. So far I have it building and it appears to work properly, however the build system expects to be able to build 32 bit binaries on amd64. amd64 doesn't include i386's machine/foo headers. The included patch is my proposed solution: Add i386 headers to /usr/include/i386, and in machine/foo.h, check if it's a 32 bit build and include the appropriate header from i386. For example machine/ucontext.h will include i386/ucontext.h if compiled with -m32. Thoughts? If anyone's curious about the compiler_rt port, I have it at github.com/dannomac/compiler-rt on the branch named freebsd. There was a work by Tijl Coosemans in the similar, but somewhat less hacky direction. The headers are moved into sys/x86/include and unified as much as possible, while machine/ counterpart includes corresponding header from x86/include. I even lost track of how much more headers is left to convert. In fact, not all headers are equal, some are only useful for kernel or base system. Also, parts of the critically important headers do not live in machine/ at all, e.g. the headers from libm. The work seems to be stale, do you want to cooperate with Tijl or continue ? I think we should probably follow Tijl's model since we are on that path. I originally preferred the /usr/include/i386 approach, but have come around to Tjil's approach instead. I just wanted to add that the unified 32/64 header route is where we went on PowerPC (and MIPS?) and it works very well for -m32. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: EFI development tools
On 06/17/12 19:43, Mike Meyer wrote: Eric McCorkle wrote: The -m32 flag seems to be the culprit; removing it fixes the problem. This is why I was having problems, as the offsets in EFI_SYSTEM_TABLE were wrong. In any case, this is a pretty serious error, and someone should try to reproduce it and take a look at it. This is a known issue, and had been around for a long time. You can't reliably build 32 bit binaries (what the -m32 flag specifies) on a 64 bit system. The header files (and possibly other things) are wrong. Doesn't look like anyone has opened a PR for it. This isn't as complicated as you make it seem. buildworld already does it to build the things in lib32 and on some platforms (mips and powerpc) the headers are the same for both 32- and 64-bit systems and so -m32 works perfectly already. All that is needed on x86 is some further header unification, which seems to be in progress. Moreover, if you are building standalone binaries (which the EFI stuff probably is) it should just work now, since standalone code doesn't depend on system headers. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD Boot Times
Thanks for the information -- I got scared by "SysV init". This actually does look very nice. -Nathan On 06/13/12 13:35, Richard Yao wrote: The OpenRC is sysvinit compatible, but it has few of sysvinit's flaws. It has named runlevels, the presence of an init script does not cause it to start and it is in my opinion a joy to use. I suggest that you try OpenRC before drawing conclusions. You can install Gentoo FreeBSD in a jail. There are instructions for this on the Gentoo wiki: http://wiki.gentoo.org/wiki/Gentoo_FreeBSD#Howto_run_G.2FFBSD_in_vanilla_FreeBSD.27s_jail If you find deficiencies, I am certain that the OpenRC developers would appreciate feedback regarding them. On 06/13/12 10:19, Nathan Whitehorn wrote: On 06/12/12 18:00, Richard Yao wrote: On 06/11/12 18:51, Garrett Cooper wrote: On Mon, Jun 11, 2012 at 3:21 PM, Brandon Falk wrote: Greetings, I was just wondering what it is that FreeBSD does that makes it take so long to boot. Booting into Ubuntu minimal or my own custom Linux distro, literally takes 0.5-2 seconds to boot up to shell, where FreeBSD takes about 10-20 seconds. I'm not sure if anything could be parallelized in the boot process, but Linux somehow manages to do it. The Ubuntu install I do pretty much consists of a shell and developers tools, but it still has a generic kernel. There must be some sort of polling done in the FreeBSD boot process that could be parallelized or eliminated. Anyone have any suggestions? Note: This isn't really an issue, moreso a curiosity. The single process nature of rc is a big part of the problem, as is the single AP bootup of FreeBSD right before multiuser mode. There are a number of threads that discuss this (look for parallel rc bootup or something like that in the current, hacker, and rc archives -- the most recent discussion was probably 6~9 months ago). Given past experience, a big part of getting past the parallelized rc mess would be to make services fail/wait gracefully for all their resources to come up before proceeding. It's not easy, but it's possible with enough resources. HTH, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" Gentoo FreeBSD shares OpenRC with Gentoo Linux. OpenRC is a BSD 2-clause licensed System V init system replacement that supports parallel boot. Its boot performance is competitive with systemd and Ubuntu's upstart. If FreeBSD's init system is serializing the boot process, it might be worthwhile to consider importing OpenRC. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" Please don't change any of the user-facing aspects of the RC system. One of the things that brought me (and many others I know) to FreeBSD, besides working sound, was having an rc.conf that was easy to configure instead of the nightmare that is System V init. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: wired memory - again!
On 06/13/12 13:22, Konstantin Belousov wrote: On Wed, Jun 13, 2012 at 07:14:09AM -0600, Ian Lepore wrote: On Tue, 2012-06-12 at 23:45 +0300, Konstantin Belousov wrote: On Tue, Jun 12, 2012 at 08:51:34AM -0600, Ian Lepore wrote: On Sat, 2012-06-09 at 22:45 +0200, Wojciech Puchar wrote: First, all memory allocated by UMA and consequently malloc(9) is wired. In other words, almost all memory used by kernel is accounted as wired. yes i understand this. still i found no way how to find out what allocated that much. Second, the buffer cache wires the pages which are inserted into VMIO buffers. So your observation is basically right, cached buffers means what are exactly "VMIO" buffers. i understand that page must be wired WHEN doing I/O. But i have too much wired memory even when doing no I/O at all. I agree, this is The Big Question for me. Why does the system keep wired writable mappings of the buffers in kva after the IO operations are completed? Read about buffer cache, e.g. in the Design and Implementation of the FreeBSD OS book. If it did not do so, it would fix the instruction-cache-disabled bug that kills performance on VIVT cache architectures (arm and mips) and it would reduce the amount of wired memory (that apparently doesn't need to be wired, unless I've missed the implications of a previous reply in this thread). I have no idea what is the bug you are talking about. If my guess is right, and it specifically references unability of some processors to correctly handle several mappings of the same physical page into different virtual addresses due to cache tagging using virtual address instead of physical, then this is a hardware bug, not software. This bug: http://lists.freebsd.org/pipermail/freebsd-arm/2012-January/003288.html The bug isn't the VIVT cache hardware, it's the fact that the way we handle the requirements of the hardware has the side effect of leaving the instruction cache bit disabled on executable pages because the kernel keeps writable mappings of the pages even after the IO is done. Can you point me at the exact code in arm pmap ? I remember an issue on PPC which Nathan discussed, that sounds somewhat similar (but I still do not understand what exactly happens on ARM). On PowerPC, icache needs to be explicitely flushed if write happen to the executable mapping. See r233949 for current solution. There were some followups, but I believe the core change is still valid. The general algorithm I used on PPC (which is PIPT, but still has an incoherent icache) is based on the following guarantees/observations, which seem to be sufficient for FreeBSD to run correctly: 1. Executable kernel memory never contains new data except after a module load, so only do kernel icache flushes in elf_machdep.c after a module load. 2. Executable pages are never mapped into userland until the kernel is finished writing to them. Thus, userland icache consistency is maintained with respect to all kernel operations (executable loading, swap, etc.) if icaches are made coherent once at the time that the page is entered into its first non-kernel pmap. If your chip has an NX feature, this only need be done for the first executable user mapping -- otherwise it needs to be done for the first overall mapping to prevent information leakage via the icache. I guess for VIVT, "first" may mean "every" here. 3. I-cache coherency with respect to userland modifications is the responsibility of the user program. All self-modifying code knows, or should know, what to do here. Otherwise the only time this comes up is in RTLD, which is easily modified to do an icache flush after load. The general point is that even if the kernel maintains its writable mapping after the IO is complete, it will never actually write to that mapping after the page has been mapped into its first user process and therefore it is safe to maintain cacheability at all times and do a single invalidation when it is mapped into the user pmap. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD Boot Times
On 06/12/12 18:00, Richard Yao wrote: On 06/11/12 18:51, Garrett Cooper wrote: On Mon, Jun 11, 2012 at 3:21 PM, Brandon Falk wrote: Greetings, I was just wondering what it is that FreeBSD does that makes it take so long to boot. Booting into Ubuntu minimal or my own custom Linux distro, literally takes 0.5-2 seconds to boot up to shell, where FreeBSD takes about 10-20 seconds. I'm not sure if anything could be parallelized in the boot process, but Linux somehow manages to do it. The Ubuntu install I do pretty much consists of a shell and developers tools, but it still has a generic kernel. There must be some sort of polling done in the FreeBSD boot process that could be parallelized or eliminated. Anyone have any suggestions? Note: This isn't really an issue, moreso a curiosity. The single process nature of rc is a big part of the problem, as is the single AP bootup of FreeBSD right before multiuser mode. There are a number of threads that discuss this (look for parallel rc bootup or something like that in the current, hacker, and rc archives -- the most recent discussion was probably 6~9 months ago). Given past experience, a big part of getting past the parallelized rc mess would be to make services fail/wait gracefully for all their resources to come up before proceeding. It's not easy, but it's possible with enough resources. HTH, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" Gentoo FreeBSD shares OpenRC with Gentoo Linux. OpenRC is a BSD 2-clause licensed System V init system replacement that supports parallel boot. Its boot performance is competitive with systemd and Ubuntu's upstart. If FreeBSD's init system is serializing the boot process, it might be worthwhile to consider importing OpenRC. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" Please don't change any of the user-facing aspects of the RC system. One of the things that brought me (and many others I know) to FreeBSD, besides working sound, was having an rc.conf that was easy to configure instead of the nightmare that is System V init. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Regarding cores in FreeBSD 9
On 04/15/12 16:27, Mahesh Babu wrote: 1. How to find in which core the given process is running? You can see it in top. 2. How to force a process to run in a particular core? for example: I need to run process ID 1200 in core 2. Use cpuset. You can either run it in the first place on core 2 with cpuset -l 2 or switch an existing process cpuset -l 2 -p 1200. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Jumpstart on FreeBSD 9.0
On 02/21/12 02:24, ego...@ramattack.net wrote: Hi all, I'm trying to upgrade my Jumpstart services for provisioning machines, but I'm founding that in FreeBSD 9.0 things are become slightly different than in previous releases. For example... tar -C ... -pxvf does not work with some files (althout you can mount iso and later do an rsync preserving file flags), another change is that you don't see a mfsroot for using in the service... perhaps in this release you need to create by you're own... has anyone see this problems I'm talking about in this new release?? If I rebuild the release isos... (from source) could I pass something (or can do something) for getting the commented mfsroot?. To get tar to extract the ISOs, I think you need a newer tar. There was some conformance issue in makefs. With respect to the mfsroot, this was something that slipped before the 9.0 release. If you want it, the easiest way is to build new media that use sysinstall (which also makes things identical to 8.x releases), which you can do by: cd /usr/src make -f Makefile.sysinstall release There are some environment variables you can read about here: http://www.freebsd.org/cgi/man.cgi?query=release&apropos=0&sektion=7&manpath=FreeBSD+8.2-stable&arch=default&format=html This situation should be corrected for 9.1. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Change of ftp download server's dir layout, from 9
On 01/22/12 11:11, rank1see...@gmail.com wrote: - Original Message - From: Devin Teske To: Cc: Date: Sun, 22 Jan 2012 08:42:00 -0800 Subject: Re: Change of ftp download server's dir layout, from 9 On Jan 22, 2012, at 8:01 AM, wrote: Example: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/9.0-RELEASE/ Refering to KERNEL: 8 -> kernels 9 -> kernel (It was supposed to be 'kernels.txz', in order to preserve naming scheme) 9 -> manpages is a NO MORE Where are CHECKSUM.MD5 and CHECKSUM.SHA256 for *.txz ?!? You want the new "MANIFEST" file for such info. Though, it's unclear merely by just looking at the hash what digest it is (looks long enough to be sha256). -- Devin Yep. And regarding a manpages ... I have a HUNCH, it is now part of a base.txz Thou, will know for sure, once I spit it into DESTDIR. ;) It is SHA256 and base.txz does contain the manpages. The script that generates MANIFEST is at /usr/src/releases/scripts/make-manifest.sh if you want to see what the rest of the fields are. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64
On 12/08/11 03:01, Piotr Nowak wrote: We're working on PowerPC target using GCC 4.2.1 and FreeBSD 6.1. It seems like we have similar problem. In our case GCC sometimes very unfortunately optimize code with -fno-omit-frame-pointer. Example shown below covers file sys/powerc/booke/pmap.c and function pmap_kenter. If we disassemble kernel binary we have: c019998c: 4b ec 6a ed bl c0060478<_mtx_unlock_spin_flags> c010: 81 61 00 00 lwz r11,0(r1) c014: 80 0b 00 04 lwz r0,4(r11) c018: 7d 61 5b 78 mr r1,r11 c01c: 82 ab ff d4 lwz r21,-44(r11) c01999a0: 7c 08 03 a6 mtlrr0 c01999a4: 82 cb ff d8 lwz r22,-40(r11) c01999a8: 82 eb ff dc lwz r23,-36(r11) c01999ac: 83 0b ff e0 lwz r24,-32(r11) c01999b0: 83 2b ff e4 lwz r25,-28(r11) c01999b4: 83 4b ff e8 lwz r26,-24(r11) c01999b8: 83 6b ff ec lwz r27,-20(r11) As you can see stack pointer on R1 is being updated before stashed data were pulled off stack. (mr r1,r11) As a result of this we have chance to get crash when any interrupt hit shortly after stack pointer update. The interrupt prologue will override not yet pulled off pmap_kenter function data. The problem occures only with -fno-omit-frame-pointer and not every branch returns are beeing corrupted. Do you think this issue may be somehow related to yours? Are there any patches/solutions to fix it? Should we turn off -fno-omit-frame-frame-pointer on PPC then? It's enabled in default kernel builds. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: how are callouts handled in cpu_idle() ?
On 10/01/11 04:25, Alexander Motin wrote: Hi. Adrian Chadd wrote: What happens if this occurs: * cpu_idle() is entered * you enter critical_enter() and call cpu_idleclock() * an interrupt occurs, scheduling an immediate callout * .. but you've already set the clock register, so it won't be serviced until the wait returns. Perhaps interrupts have to be disabled before critical_enter() and cpu_idletick() to ensure an interrupt-driven callout doesn't get delayed? Use of critical section in cpu_idle() from the beginning was based on number of assumptions about filter interrupt handler's limitations. These handlers are not guarantied to get updated system time/ticks and they are discouraged to use callouts. If callout scheduled from interrupt filter during system wake up, system has no ticks counter updated yet and you may get callout scheduled into the past (it will be run immediately) or at least much earlier (up to 250ms) then requested. In your case callout indeed may get delayed (up to the same 250ms). All that is not a problem for regular interrupt threaded interrupts -- interrupt thread execution will be delayed until all stuff get updated. Can you explain why the critical section is there in more detail? It seems like all of our problems arise because of it. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: 9-beta1 installer - partition editor
On 09/12/11 14:13, Ivan Voras wrote: Unfortunately, I continue to have problems with the partitioner part of the installer in the BETA2 image. See the (unchanged) problem screenshots here: http://ivoras.imgur.com/freebsd_installer_2 See also the screenshots of the entire process here (on BETA1): http://ivoras.imgur.com/installer__partitioner I am no longer trying to create a swap partition but still: 1) I cannot proceed without specifying a root partition 2) I cannot specify the root partition (the dialog ignores it). If this doesn't get solved, it makes FreeBSD uninstallable in this case. There may be some kind of interference between the existing MBR scheme and the operations that the installer attempts to do. This was resolved earlier -- you cannot install onto just MBR without a bsdlabel. This has never been supported, and worked only by accident before. *As it tells you* you need to create sub-partitions. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: 9-beta1 installer - partition editor
On 08/31/11 08:28, Ivan Voras wrote: On 31 August 2011 14:45, Nathan Whitehorn wrote: It does let you set mountpoints, and displays them, and always has, but not for bsdlabel container partitions (MBR type "freebsd"), since they aren't filesystems. Is this what you were trying to do? Very probably - it was unclear to me that it still keeps the old slice-partition division but reverses the names. But, look at the screenshots here and see what went wrong: http://ivoras.imgur.com/installer__partitioner OK, that's exactly what happened. It also doesn't reverse the names -- it just drops the term "slice" completely. If it is as you say, then the dialog where I entered "/" and "/srv" should definitely NOT have that field on it. Well, no. It only applies to bsdlabel containers. For instance, were I to want to mount an ext2 or fat32 partition directly under MBR, which the installer can do (and create, in the case of fat32), the mountpoint field is very important. What we *can* do is add a check that rejects mountpoints for partitions of type "freebsd". I'll see if I can code that up; it's too late for BETA2, however. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: 9-beta1 installer - partition editor
On 08/31/11 05:19, Ivan Voras wrote: On 31/08/2011 02:40, Nathan Whitehorn wrote: On 08/30/11 19:07, Ivan Voras wrote: It was a plain install on a RAID volume which appears as ordinary da0 drive. I did do a couple of start-overs so it could be that some state got lost. It definitely did NOT show mount points in the dialog which lists newly created partitions. Which partitioning scheme did you use? How did you lay out the partitions? I did not deviate from defaults until the partition editor, where I deleted existing partitions (Linux) and tried to create new ones. So, it's a MBR scheme, and I intended to create three partitions, for "/", for "/srv" and a swap partition. I think Andrey's idea about what went wrong with the swap partition is most probably correct, so this only leaves the inability to register mount points with the partitions. However, if as Brandon suggested this is already fixed, don't bother. I'll try the BETA2 when ISOs become available and will post screenshots (IPMI) if it fails again. The help text for straight MBR partitioning (which has never worked for FreeBSD) has been modified for BETA2 to suggest "freebsd" (which has always been the default) instead of "freebsd-ufs" etc. It does let you set mountpoints, and displays them, and always has, but not for bsdlabel container partitions (MBR type "freebsd"), since they aren't filesystems. Is this what you were trying to do? -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: 9-beta1 installer - partition editor
On 08/30/11 19:07, Ivan Voras wrote:
On 30.8.2011. 16:11, Nathan Whitehorn wrote:
On 08/30/11 07:27, Ivan Voras wrote:
Am I doing something wrong or the BETA1 installer cannot be used to
manually create the partition scheme?
1) it doesn't accept "freebsd-swap" as partition type ("invalid
argument")
2) it doesn't recognize that I have actually created a root (/) mount
point; since it doesn't show mountpoints maybe it forgets the input
from the dialog?
The partition editor looks very rudimentary and feature-less. It
really should show "space left" on the drive.
It does show mountpoints, and of course does support swap partitions.
You can use the partition editor to create quite complicated multi-disk
partition layouts over a variety of schemes, and in that way it is
wildly more featureful than what was in sysinstall.
Can you describe more what you were trying to do, in terms of what
partition scheme you were using, etc.? The "invalid argument" is a
message coming from the kernel, so something must be very wrong in your
setup.
It was a plain install on a RAID volume which appears as ordinary da0
drive. I did do a couple of start-overs so it could be that some state
got lost. It definitely did NOT show mount points in the dialog which
lists newly created partitions.
Which partitioning scheme did you use? How did you lay out the partitions?
-Nathan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: 9-beta1 installer - partition editor
On 08/30/11 07:27, Ivan Voras wrote:
Am I doing something wrong or the BETA1 installer cannot be used to
manually create the partition scheme?
1) it doesn't accept "freebsd-swap" as partition type ("invalid
argument")
2) it doesn't recognize that I have actually created a root (/) mount
point; since it doesn't show mountpoints maybe it forgets the input
from the dialog?
The partition editor looks very rudimentary and feature-less. It
really should show "space left" on the drive.
It does show mountpoints, and of course does support swap partitions.
You can use the partition editor to create quite complicated multi-disk
partition layouts over a variety of schemes, and in that way it is
wildly more featureful than what was in sysinstall.
Can you describe more what you were trying to do, in terms of what
partition scheme you were using, etc.? The "invalid argument" is a
message coming from the kernel, so something must be very wrong in your
setup.
-Nathan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: make release question
On 07/21/11 10:42, Aryeh Friedman wrote: Where does "make release" place the disk images (iso's) by default ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" On -CURRENT, it places them in /usr/obj/usr/src/release. You can use make install DESTDIR=blah to put them somewhere else. On 8.x and earlier it places them in CHROOT/R. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] fake pre-processor macros when building on non-FreeBSD system
On 07/12/11 17:33, Robert Millan wrote: 2011/7/12 Nathan Whitehorn: On 07/12/11 16:06, Robert Millan wrote: Why would one need to build a cross-compiler in order to compile userland-agnostic code for the same CPU architecture? This would be like requiring a cross-compiler in order to build things like GRUB or SeaBIOS. For one, it might have a different ABI, which isn't actually that different an issue than the one you find yourself facing. ABI can mean many things in this context. It could mean libc ABI, it could mean internal kernel interfaces, or even C calling conventions. The one I meant was the third one. Linux and FreeBSD happen, though not entirely by chance, to use almost exactly the same ABI on most platforms (but not all!). Assuming, and requiring, interchangeability of ABIs here thus seems like a poor choice. Once you've decided you might have a different ABI, you need a cross-compiler, and that would simultaneously take care of defining various platform-specific macros. The "isn't actually that different" comment, which wasn't a particularly useful thing to say, was that you could conceivably claim, under very broad definitions of what ABI means, that having __FreeBSD__ defined is in fact a part of the system ABI, just like the calling conventions or the stack frame layout. In either case, you would be expected to use a cross-compiler. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] fake pre-processor macros when building on non-FreeBSD system
On 07/12/11 16:06, Robert Millan wrote: 2011/7/12 Alexander Kabaev: Whatever happened to using a proper cross-tool to do the job? Why would one need to build a cross-compiler in order to compile userland-agnostic code for the same CPU architecture? This would be like requiring a cross-compiler in order to build things like GRUB or SeaBIOS. For one, it might have a different ABI, which isn't actually that different an issue than the one you find yourself facing. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sizeof(function pointer)
On 05/31/11 19:06, Alexander Kabaev wrote: On Tue, 31 May 2011 17:18:16 -0600 Warner Losh wrote: On May 31, 2011, at 5:07 PM, m...@freebsd.org wrote: I am looking into potentially MFC'ing r212367 and related, that adds drains to sbufs. The reason for MFC is that several pieces of new code in CURRENT are using the drain functionality and it would make MFCing those changes much easier. The problem is that r212367 added a pointer to a drain function in the sbuf (it replaced a pointer to void). The C standard doesn't guarantee that a void * and a function pointer have the same size, though its true on amd64, i386 and I believe PPC. What I'm wondering is, though not guaranteed by the standard, is it *practically* true that sizeof(void *) == sizeof(int(*)(void)), such that an MFC won't break binary compatibility for any supported architecture? (The standard does guarantee, though not in words, that all function pointers have the same size, since it guarantees that pointers to functions can be cast to other pointers to functions and back without changing the value). Another possibility is to malloc a blob that is sizeof(int(*)(void)) and store that in a renamed s_unused; this is a bit messier but guaranteed to work. I'd just rather the code be an MCF instead of a partial re-write. It is the same on MIPS too for all three ABIs that we support (and all ABIs that I know about). It is true on ARM as well. Usually it is different only on segmented architectures like 16-bit x86. Not so on ia64, where they have special function descriptor type. As is also true on PPC64 and (I think) at least some MIPS. But on all of these, a function pointer is a regular data pointer to the function descriptor, which then points to the function, so they are still the same size as a void *. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sizeof(function pointer)
On 05/31/11 18:18, Warner Losh wrote: On May 31, 2011, at 5:07 PM, m...@freebsd.org wrote: I am looking into potentially MFC'ing r212367 and related, that adds drains to sbufs. The reason for MFC is that several pieces of new code in CURRENT are using the drain functionality and it would make MFCing those changes much easier. The problem is that r212367 added a pointer to a drain function in the sbuf (it replaced a pointer to void). The C standard doesn't guarantee that a void * and a function pointer have the same size, though its true on amd64, i386 and I believe PPC. What I'm wondering is, though not guaranteed by the standard, is it *practically* true that sizeof(void *) == sizeof(int(*)(void)), such that an MFC won't break binary compatibility for any supported architecture? (The standard does guarantee, though not in words, that all function pointers have the same size, since it guarantees that pointers to functions can be cast to other pointers to functions and back without changing the value). Another possibility is to malloc a blob that is sizeof(int(*)(void)) and store that in a renamed s_unused; this is a bit messier but guaranteed to work. I'd just rather the code be an MCF instead of a partial re-write. It is the same on MIPS too for all three ABIs that we support (and all ABIs that I know about). It is true on ARM as well. Usually it is different only on segmented architectures like 16-bit x86. It is also true on ARM, PPC, PPC64, and ia64, which I just tested. I think you're safe. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: dialog(1) changed in RELENG_9 (was RE: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD)
On 04/22/11 11:50, Devin Teske wrote: -Original Message- From: Alexander Best [mailto:arun...@freebsd.org] Sent: Friday, April 22, 2011 8:42 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org; freebsd-questi...@freebsd.org; 'Teske, Devin' Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD On Fri Apr 22 11, Devin Teske wrote: -Original Message- From: Alexander Best [mailto:arun...@freebsd.org] Sent: Friday, April 22, 2011 7:55 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org; freebsd-questi...@freebsd.org; Teske, Devin Subject: Re: [UPDATE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD On Thu Apr 21 11, Devin Teske wrote: Hi List Members! I'm proud to announce the first update to my host-setup utility (a dialog(1)-based host configurator for FreeBSD). The following changes have been made: - fixed bug where /etc/resolv.conf would be created with 0600 permissions - fixed bug when switching from one default gateway to NO default gateway - fixed typo in the title of netmask prompt and ifconfig options dialog - fixed bug that prevented entry of netmask if no netmask is configured You can get the updated version here: http://druidbsd.sourceforge.net/download/host-setup.txt otaku% sudo ./host-setup.txt User cancelled. otaku% echo $? 1 otaku% Can you provide me with the output of "uname -spr"? FreeBSD 9.0-CURRENT amd64 I haven't yet had a chance to pull that one down and install it yet. Hopefully you can help me out with this one here. It's working fine for me on FreeBSD 8.1-RELEASE i386. Where you're bombing out is line 2403: [ $retval -eq 0 ] || die "User cancelled." Functionally, that is testing the return status of dialog(1) for the initial menu. See if you can execute this (a rough approximation of the initial menu): dialog --clear --title foo --hline bar --menu abc 17 55 9 1 a 2 b 3 c 4 d 5 e X x 2> /tmp/dialog.menu.foo doesn't work. :( Bummer! We'll have to fix that. otaku% echo $? 255 otaku% cat /tmp/dialog.menu.foo Error: Unknown option --hline. Use --help to list options. Aha! I think I remember seeing in the list a thread related to swapping out dialog(1) for something new. This must be it. otaku% taku% whereis dialog dialog: /usr/bin/dialog /usr/share/man/en.ISO8859-15/man1/dialog.1.gz /usr/src/gnu/usr.bin/dialog otaku% /usr/bin/dialog cdialog (ComeOn Dialog!) version 1.1-20100428 Copyright 2000-2007,2008 Thomas E. Dickey This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I can't recall as I don't have the thread in front of me, but why was dialog(1) replaced with cdialog? licensing? performance? I guess I could code my script to support this new dialog(1), but... can you see if the below works (I removed the "--hline" option): dialog --clear --title foo --menu abc 17 55 9 1 a 2 b 3 c 4 d 5 e X x 2> /tmp/dialog.menu.foo If that succeeds, then I can modify my script to not use `--hline' on RELENG_9 and higher (referencing `sysctl -n kern.osreldate` for example). [...] A menu should appear. Select an item and then execute for me: echo $? If the above doesn't work, then I suspect that your dialog(1) is not working properly. I'd then go and try this as a sanity check: cd /usr/share/examples/dialog otaku% cd /usr/share/examples/dialog cd: no such file or directory: /usr/share/examples/dialog Really? I would have thought that the examples in that directory (which are merely shell scripts) would have been recoded for cdialog rather than altogether removed. Maybe there was licensing issues there too. Was there? sh menubox echo $? The result in both cases (as long as you actually select a menu item) should be "0". Also... (just as a sanity check for me) your /bin/sh is not a symlink to bash is it? otaku% file /bin/sh /bin/sh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 9.0 (900034), stripped Cool. Though I'm still disappointed that my beloved dialog(1) has gone missing (rather, replaced with something doesn't accept the same arguments and/or options)(which is the problem that we're experiencing here). Is there anybody familiar with the changing-out dialog(1) that can bring me up to speed with reasoning and specifics for RELENG_9? Also, might it be prudent -- before cutting 9_0_RELEASE -- to add the fact that dialog(1) no longer accepts `--hline' to the UPGRADING and/or ERRATA documents? It's almost entirely compatible, but I apologize for the breakage you experienced. The reasons it was replaced it were that it (a) has a better libdialog API, (b) has a better license (LGPL instead of GPL), (c) is maintained, and (d) supports 8-bit character sets. If there is some specific feature you are interested in (--hline for instance), I'd suggest writing to Thomas Dickey, the maintainer. -Nathan __
Re: Include file search path
On 03/30/11 10:23, Dimitry Andric wrote:
On 2011-03-29 23:20, m...@freebsd.org wrote:
So here's what I'm pondering. When I build a library, like e.g. libc,
where do the include files get pulled from? They can't (shouldn't) be
the ones in /usr/include, but I don't see a -nostdinc like for the
kernel. There are -I directives in the Makefile for
-I${.CURDIR}/include -I${.CURDIR}/../../include, etc., but that won't
remove /usr/include from the search path.
During the bootstrap stage, a copy of gcc (or clang) is built, that has
all default search paths for headers, libraries, etc, set relative to
${WORLDTMP}, usually /usr/obj/usr/src/tmp.
E.g:
$ /usr/obj/usr/src/tmp/usr/bin/gcc -v -E -x c /dev/null -o /dev/null
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070719 [FreeBSD]
/usr/obj/usr/src/tmp/usr/libexec/cc1 -E -quiet -v -D_LONGLONG
/dev/null -o /dev/null
#include "..." search starts here:
#include <...> search starts here:
/usr/obj/usr/src/tmp/usr/include/gcc/4.2
/usr/obj/usr/src/tmp/usr/include
End of search list.
and:
$ /usr/obj/usr/src/tmp/usr/bin/gcc -print-search-dirs
install: /usr/obj/usr/src/tmp/usr/libexec/
programs:
=/usr/obj/usr/src/tmp/usr/bin/:/usr/obj/usr/src/tmp/usr/bin/:/usr/obj/usr/src/tmp/usr/libexec/:/usr/obj/usr/src/tmp/usr/libexec/:/usr/obj/usr/src/tmp/usr/libexec/
libraries: =/usr/obj/usr/src/tmp/usr/lib/:/usr/obj/usr/src/tmp/usr/lib/
This is a rather nasty hack, though. If we can make it work, we should
probably try using --sysroot instead, or alternatively, -nostdinc and
adding include dirs by hand. The same for executable and library search
paths, although I am not sure if there is a way to completely reset
those with the current options.
Since you need to build two compilers anyway (one for the current
system, to build the new one, and one to live in the new one, linked
against new libraries), I don't see that it's such a nasty hack.
-Nathan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: multi-boot bootstrap?
On 03/28/11 15:59, dieter...@engineer.com wrote: From what I know, one or the other can only be as the first entry and it then has to be set from the forth prompt. So, you will need two disks to boot , saya: OpenBSD, NetBSD, FreeBSD, Linux, and MacOSX or a combination of these. On PPC boxes with OpenFirmware 3.x, you actually need to set the active partition if you want to boot Linux and/or freebsd from the forth prompt if both are on the same disk. Can these PPC boxes boot from GPT disks? "active partition" sounds MBRish. Perhaps they can use the "protective MBR" trick? No, they can only boot from APM (Apple Partition Map) disks, which don't have a concept of active partition. The current boot1 on PPC is hard-coded to boot from the first UFS partition on the disk, which could be changed, certainly, but is almost totally unrelated to this discussion. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Unable to compile drm.ko on powerpc
AGP is derived from PCI, so AGP devices show up on the PCI bus. All the AGP kernel module does is provide hooks to manipulate some advanced features of the bus, mostly for the benefit of drm. -Nathan On 01/12/11 19:24, Super Bisquit wrote: My graphics port is agp and not pci. It's a Quicksilver 2002 with a 4x agp slot. Now, how do I make it work? That's the problem I've been recently asking about. Forgive me for bringing the next part here. The PowerPC snapshot 9 for the 32bit ppc needs updating. The ports tarball is behind. On 1/12/11, Nathan Whitehorn wrote: On 01/12/11 02:39, Super Bisquit wrote: http://slexy.org/view/s2NSVy7aTU The build also fails looking for machine/specialreg.h. This file is only found on i386/amd64 processors. Drm.ko is needed by agp.ko. DRM is not required by AGP, rather the reverse, and DRM does not presently work on powerpc. The AGP kernel module also doesn't provide any useful features unless you are using DRM. You don't need either for graphics on powerpc machines. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Unable to compile drm.ko on powerpc
On 01/12/11 02:39, Super Bisquit wrote: http://slexy.org/view/s2NSVy7aTU The build also fails looking for machine/specialreg.h. This file is only found on i386/amd64 processors. Drm.ko is needed by agp.ko. DRM is not required by AGP, rather the reverse, and DRM does not presently work on powerpc. The AGP kernel module also doesn't provide any useful features unless you are using DRM. You don't need either for graphics on powerpc machines. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: txt-sysinstall scrapped
On 11/06/10 01:04, Garrett Cooper wrote: > On Fri, Nov 5, 2010 at 10:06 PM, Warner Losh wrote: >>> Just to add to that (because I do find it a novel idea), 1) how >>> are you going to properly prevent man in the middle attacks (SSL, TLS, >>> etc?), and 2) what webserver would you use? >> >> https or ssh. >> >> We're also toying with the idea of having a partition that you could >> 'dd' your certs and keys to (so any system can customize the image >> with keys to make sure you were talking to who you think you are). >> We'd just reserve 1MB of space on partition s3. We'd then check to >> see if there was a tar ball. If so, we'd extract it and do the >> intelligent thing with the keys we find there. > > Wouldn't it be better just to go with a read-write media solution > (USB) like Matt Dillon was suggesting at today then? Then again, > determining the root device to date is still a bit kludgy isn't it? But this breaks badly for people who don't own USB sticks of sufficient size, are installing on machines without USB ports, can't boot from USB, want to install from a shared medium like PXE, are installing on blades with convenient shared CD drives but not USB etc. etc. Everything in the world can boot from CD, and we have to ensure that continues working. I also have mixed feelings about needing to use a web browser to instruct a web app inside a bundled web server to write a config file to be interpreted by shell scripts just in order to run gpart, newfs, and tar. But if you get it working, it's better than sysinstall no matter how baroque. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: fix pnpinfo on arch=amd64
On 10/24/10 11:14, Garrett Cooper wrote: well on i386/amd (pc98?) you could use i386_get_ioperm(2) to check for proper io permissions. Yeah, and it's x86 specific. Kind of curious why there isn't a more generalized name for this API, but it appeared to be geared towards x86 (today, not so much according to LEGACY in io(4)). That's because the whole concept is very x86-specific. For example, at least PowerPC and ARM don't even have a concept of IO space as distinct from memory, and /dev/io is something that only exists on i386, amd64, pc98, and ia64 (i.e. Intel products). -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Summary: Re: Spin down HDD after disk sync or before power off
On 09/16/10 09:42, Warren Block wrote: > On Thu, 16 Sep 2010, Alexander Best wrote: > >> On Wed Sep 15 10, Oliver Fromme wrote: >>> Warren Block wrote: >>> > [...] >>> > 8. Alexander Motin has an updated CAM version of the ATA system which >>> > will eventually replace the existing one. In -CURRENT, anyway. >>> He was >>> > kind enough to look at my event handler. My understanding is that >>> he is >>> > looking at implementing the head parking/standby mechanism in that >>> new >>> > code. >>> >>> The patch below will work with the new CAM ATA driver >>> (i.e. ada(4) disks). It adds a sysctl, so you can switch >>> the spin-down off if you're going to just reboot: >>> # sysctl kern.cam.ada.spindown_shutdown=0 >> >> i haven't tested your patch yet, but i don't think deciding whether >> to spin >> down the hdd should be decided merely from the sysctl value. >> >> the hdd should spindown when a shutdown has been issued and not >> spindown, >> if a reboot has been issued. > > It's been a while, but the problem I found when comparing the NetBSD > code was that there didn't appear to be a way to tell from within the > FreeBSD driver whether it was a shutdown or reboot. Register a shutdown event handler? The second argument can be tested against RB_HALT to determine what is happening. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: PS3 livelock and pmap_remove()
On 09/06/10 22:24, Nathan Whitehorn wrote:
> On 09/06/10 20:22, Nathan Whitehorn wrote:
>
>> Now that my SLB allocation issue is solved, with help with Matthew and
>> Alan, I have another VM puzzler.
>>
>> I have a simple program that tries to use all the memory on the system,
>> which isn't very much on the PS3, so I use it to test swap as well.
>> Shortly after it begins paging, the system locks up completely. I
>> managed to duplicate this behavior on an emulator, and found out what it
>> is actually doing. Somehow pmap_remove() is being called with arguments
>> pmap_remove(userpmap, PAGE_SIZE, VM_MAXUSER_ADDRESS = USRSTACK). For
>> powerpc64, VM_MAXUSER_ADDRESS is 0x7000, so there are 10^15
>> pages to unmap in that range and it was busy taking until the end of
>> time unmapping them all.
>>
>> Here's the trace from KDB:
>>
>> moea64_remove()
>> pmap_remove()
>> vm_daemon()
>> fork_exit()
>> fork_trampoline()
>> end-
>>
>> Does anyone have any idea why this is happening?
>>
>>
>>
> The culprit here is lines 703-706 of vm/vm_pageout.c:
>
> if (desired == 0 && nothingwired) {
> pmap_remove(vm_map_pmap(map), vm_map_min(map),
> vm_map_max(map));
> }
>
> It would be much better if it did this in sections, the way
> vm_map_delete does. I'll take a crack at this, though any suggestions
> for proper implementation would be appreciated.
> -nathan
>
I've attached a patch that reimplements this by unmapping each map_entry
separately, which solves the problem on PowerPC and I believe is
functionally equivalent. My PS3 successfully completes a buildworld with
this patch. Are there any objections to me committing it?
-Nathan
Index: vm/vm_pageout.c
===
--- vm/vm_pageout.c (revision 212277)
+++ vm/vm_pageout.c (working copy)
@@ -701,8 +701,11 @@
* table pages.
*/
if (desired == 0 && nothingwired) {
- pmap_remove(vm_map_pmap(map), vm_map_min(map),
- vm_map_max(map));
+ tmpe = map->header.next;
+ while (tmpe != &map->header) {
+ pmap_remove(vm_map_pmap(map), tmpe->start, tmpe->end);
+ tmpe = tmpe->next;
+ }
}
vm_map_unlock(map);
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: PS3 livelock and pmap_remove()
On 09/06/10 20:22, Nathan Whitehorn wrote:
> Now that my SLB allocation issue is solved, with help with Matthew and
> Alan, I have another VM puzzler.
>
> I have a simple program that tries to use all the memory on the system,
> which isn't very much on the PS3, so I use it to test swap as well.
> Shortly after it begins paging, the system locks up completely. I
> managed to duplicate this behavior on an emulator, and found out what it
> is actually doing. Somehow pmap_remove() is being called with arguments
> pmap_remove(userpmap, PAGE_SIZE, VM_MAXUSER_ADDRESS = USRSTACK). For
> powerpc64, VM_MAXUSER_ADDRESS is 0x7000, so there are 10^15
> pages to unmap in that range and it was busy taking until the end of
> time unmapping them all.
>
> Here's the trace from KDB:
>
> moea64_remove()
> pmap_remove()
> vm_daemon()
> fork_exit()
> fork_trampoline()
> end-
>
> Does anyone have any idea why this is happening?
>
>
The culprit here is lines 703-706 of vm/vm_pageout.c:
if (desired == 0 && nothingwired) {
pmap_remove(vm_map_pmap(map), vm_map_min(map),
vm_map_max(map));
}
It would be much better if it did this in sections, the way
vm_map_delete does. I'll take a crack at this, though any suggestions
for proper implementation would be appreciated.
-nathan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
PS3 livelock and pmap_remove()
Now that my SLB allocation issue is solved, with help with Matthew and Alan, I have another VM puzzler. I have a simple program that tries to use all the memory on the system, which isn't very much on the PS3, so I use it to test swap as well. Shortly after it begins paging, the system locks up completely. I managed to duplicate this behavior on an emulator, and found out what it is actually doing. Somehow pmap_remove() is being called with arguments pmap_remove(userpmap, PAGE_SIZE, VM_MAXUSER_ADDRESS = USRSTACK). For powerpc64, VM_MAXUSER_ADDRESS is 0x7000, so there are 10^15 pages to unmap in that range and it was busy taking until the end of time unmapping them all. Here's the trace from KDB: moea64_remove() pmap_remove() vm_daemon() fork_exit() fork_trampoline() end- Does anyone have any idea why this is happening? Thanks, -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UMA allocations from a specific physical range
On 09/05/10 22:51, m...@freebsd.org wrote:
> On Mon, Sep 6, 2010 at 1:38 AM, Nathan Whitehorn
> wrote:
>
>> PowerPC hypervisors typically provided a restricted range on memory when
>> the MMU is disabled, as it is when initially handling exceptions. In
>> order to restore virtual memory, the powerpc64 code needs to read a data
>> structure called the SLB cache, which is currently allocated out of a
>> UMA zone, and must be mapped into wired memory, ideally 1:1
>> physical->virtual address. Since this must be accessible in real mode,
>> it must have a physical address in a certain range. I am trying to
>> figure out the best way to do this.
>>
>> My first run at this code uses a custom UMA allocator that calls
>> vm_phys_alloc_contig() to get a memory page. The trouble I have run into
>> is that I cannot figure out a way to free the page. Marking the zone
>> NOFREE is a bad solution, vm_page_free() panics the kernel due to
>> inconsistent tracking of page wiring, and vm_phys_free_pages() causes
>> panics in vm_page_alloc() later on ("page is not free"). What is the
>> correct way to deallocate these pages? Or is there a different approach
>> I should adopt?
>>
> I assume this is for the SLB flih?
>
> What AIX did was to have a 1-1 simple esid to vsid translation for
> kernel addresses, reserve the first 16 SLB entries for various uses,
> including one for the current process's process private segment, and
> if the slb miss was on a process address we'd turn on translation and
> look up the answer, the tables holding the answer being in the process
> private segment effective address space so we wouldn't take another
> slb miss. This required one level deep recursion in the slb slih, in
> case there was a miss on kernel data with xlate on in the SLB slih.
>
Yes, that's correct. FreeBSD has the same 1-to-1 translation for the
kernel, but the entire address space is switched out for user processes
(no part of the kernel is mapped into user processes), so the code to
load the user SLB entries has to be able to execute with the MMU off,
lest it disappear underneath itself.
> For historical reasons due to the per-process segment table for
> POWER3, we also had a one-page hashed lookup table per process that we
> stored the real address of in the process private segment, so the
> assembly code in the flih looked here before turning on MSR_DR IIRC.
> I was trying to find ways to kill this code when I left IBM, since
> we'd ended support for POWER3 a few years earlier.
>
> I haven't had the time to look at FreeBSD ppc64 sources; how large are
> the uma-allocated slb entries and what is stored in them? The struct
> and filename is sufficient, though I don't have convenient access to
> sources until Tuesday.
>
The entries are each 1 KB, and there is one for each pmap. Each consists
of 64 16-byte SLBE/SLBV pairs. These buffers are just a carbon copy of
what should be in the SLB after a context switch to that map.
> V=R space is rather limited (well, depending on a lot of factors; for
> AIX on Power5 and later the hypervisor only gave us 128M, though for
> ppc64 on a Mac G4 I assume all of memory can be mapped V=R if desired)
> so it was best to find a non V=R solution if possible. Turning on
> translation in the flih after some setup and recursion stopping is one
> of the easier ways, and also has the advantage of not needing to
> either have separate code or macro access to data structures used in
> both V and R modes.
>
On the PS3 (the target in this case), the hypervisor also limits us to
128 MB. The one and only kernel data structure that needs to be used in
this mode is this SLB cache object, so I was hoping for a simple
solution to just put them all in the real-mode accessible region.
-Nathan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
UMA allocations from a specific physical range
PowerPC hypervisors typically provided a restricted range on memory when
the MMU is disabled, as it is when initially handling exceptions. In
order to restore virtual memory, the powerpc64 code needs to read a data
structure called the SLB cache, which is currently allocated out of a
UMA zone, and must be mapped into wired memory, ideally 1:1
physical->virtual address. Since this must be accessible in real mode,
it must have a physical address in a certain range. I am trying to
figure out the best way to do this.
My first run at this code uses a custom UMA allocator that calls
vm_phys_alloc_contig() to get a memory page. The trouble I have run into
is that I cannot figure out a way to free the page. Marking the zone
NOFREE is a bad solution, vm_page_free() panics the kernel due to
inconsistent tracking of page wiring, and vm_phys_free_pages() causes
panics in vm_page_alloc() later on ("page is not free"). What is the
correct way to deallocate these pages? Or is there a different approach
I should adopt?
-Nathan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Review/testing request: changing the detection of data_addr/text_addr
John Baldwin wrote: On Wednesday 24 March 2010 3:29:23 pm Nathan Whitehorn wrote: We currently detect the offical "text" and "data" addresses for ELF files in kern/imgact_elf.c by the heuristic of calling whichever section contains the executable's entry point the text section and everything else data. In general, both this concept and the very few things that use them are obsolete and rare. The data addresses are, however, used in obreak() to find the current break. On powerpc64, this logic fails, because the entry point points to a function descriptor in the data section, causing sbrk() to fail, which in turn breaks profiling. The patch at http://people.freebsd.org/~nwhitehorn/textseg.diff changes this algorithm to make the official text area be the largest executable segment, and all others data. The patch has been tested on sparc64, amd64, powerpc, and (of course) powerpc64, with no evident bad effects. My only comment is that I would keep the existing language about obreak() as it describes multiple data segments, etc. Instead, I would just use the first sentence of your new comment to replace the first paragraph in the old comment. That's a good point. I've updated the patch with the new comment. Thanks for taking a look! If no one objects, I'll commit both of these patches tomorrow. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Review/testing request: changing the arguments of exec_setregs()
In order to properly implement exec_setregs() on powerpc64, I must hand-relocate the function descriptor pointed to by the executable entry point. To do this, exec_setregs() must be passed the relocation base of the executable, which would originally come from the image_params struct. The patch at http://people.freebsd.org/~nwhitehorn/exec_setregs.diff changes the arguments of exec_setregs to take a pointer to the image's image_params struct to allow easy future expansion, and removes redundant arguments (entry and ps_strings). This is similar to the calling convention in NetBSD. I also take the opportunity to convert several of the declarations of exec_setregs() from K&R to ANSI C. This patch is fairly straightforward, but it does touch all architectures. I have tested the patch on amd64, sparc64, and powerpc, with no evident problems. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Review/testing request: changing the detection of data_addr/text_addr
We currently detect the offical "text" and "data" addresses for ELF files in kern/imgact_elf.c by the heuristic of calling whichever section contains the executable's entry point the text section and everything else data. In general, both this concept and the very few things that use them are obsolete and rare. The data addresses are, however, used in obreak() to find the current break. On powerpc64, this logic fails, because the entry point points to a function descriptor in the data section, causing sbrk() to fail, which in turn breaks profiling. The patch at http://people.freebsd.org/~nwhitehorn/textseg.diff changes this algorithm to make the official text area be the largest executable segment, and all others data. The patch has been tested on sparc64, amd64, powerpc, and (of course) powerpc64, with no evident bad effects. I would appreciate any comments, as well as tests on other architectures. The main symptom of getting these values wrong is that sbrk() stops working correctly, so I have put a simple test program for sbrk() at http://people.freebsd.org/~nwhitehorn/sbrktest.c. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
