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 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 outbackdi...@gmail.com 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: [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 nwhiteh...@freebsd.org 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=233291view=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 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 nwhiteh...@freebsd.org
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=233291view=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: 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 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/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/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 utis...@gmail.com 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 McCorklee...@shadowsun.net 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 Falkbfalk_...@brandonfa.lk 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: 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 Falkbfalk_...@brandonfa.lk 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: 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: 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 cmd 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=releaseapropos=0sektion=7manpath=FreeBSD+8.2-stablearch=defaultformat=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 Teskedevin.te...@fisglobal.com To:rank1see...@gmail.com Cc:hack...@freebsd.org 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,rank1see...@gmail.com 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 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/31/11 08:28, Ivan Voras wrote: On 31 August 2011 14:45, Nathan Whitehornnwhiteh...@freebsd.org 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/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: 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: 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 16:06, Robert Millan wrote: 2011/7/12 Alexander Kabaevkab...@gmail.com: 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: [PATCH] fake pre-processor macros when building on non-FreeBSD system
On 07/12/11 17:33, Robert Millan wrote: 2011/7/12 Nathan Whitehornnwhiteh...@freebsd.org: 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: 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: sizeof(function pointer)
On 05/31/11 19:06, Alexander Kabaev wrote: On Tue, 31 May 2011 17:18:16 -0600 Warner Loshi...@bsdimp.com 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: 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 Whitehornnwhiteh...@freebsd.org 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
Software interrupts; where to start
Hey All, So I'm about as new as it gets to kernel/device level programming, but far from new to application programming/coding in general. I've recently created some components which communicate via serial port to a host computer (server). These components are used to control a bunch of inter-connected devices for home automation; lighting/dimming packs, HVAC, security, etc - via simple commands relayed from the serial port of the server. The server runs a local instance of memcached, instantiating and copying a local fixed array and polling the memcached server comparing the values against an array there, when the values do not match the (different) value is written out the serial port and updated in the local array slot as appropriate. Multiple other sources update the memcached array via the network and that's essentially how the whole system works, (ie: user presses a button on a web-based app, and that app in turn changes the dimmer value associated as a specific slot in the memcached copy of the array). This solution works, but introduced nearly 100% CPU usage as the polling was done in a constant loop, after having added a 20 milli-second delay to the loop it's dropped the CPU usage to nearly 25% - but this still seems very wasteful to me and I can't help but wonder if there is a just plain better way to do this. What I would like to do, is replace the above scenario with one wherein the program writing to the serial port is always connected and running, but not polling; ideally having some sort of interupt or signal triggered from within memcached when a value is altered. Sort of a 're-sync' request asserting that the program sending data out the serial port should 'loop once'. I'd like to continue with the use of memcached as it provides a simple way for multiple systems to query the values in the array as well, (ie: some devices need not change the data, but only view it; given the latency requirements memcached operates ideally). This trigger should be asynchronous in that it should be fired and forgotten by memcached (by nature of the hardware designed, no error-checking nor receipt would be needed). I'm just not sure where to start? Could someone send me the right RTFM link to start from, or perhaps suggest a better way to look at solving this problem? Ideally any example code to look at with a simple signal or interrupt type of handler would be great. What I'm leaning towards is modifying memcached daemon to send a signal or trigger an interrupt of some sort to tell the other program communicating with the device to re-poll once. It would also be nice to have a way to trigger from other programs too. The device communicating via serial port is essentially a protocol translator to a modified RS422 serial bus, the eventual goal of using a local UART with some modified hardware and changing the device driver to support the communications differences directly in the kernel would be best scenario, so any suggestions leaning towards having the sending program be integrated within the kernel in some way would be even better. I'm not looking for a handout here, just a better understanding of where to start; so any suggestions or referrals to RTFM or source examples would be greatly appreciated. Thanks. -- Nathan Vidican nat...@vidican.com ___ 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 i...@bsdimp.com 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 wbl...@wonkity.com 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
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: 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
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: 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 nwhiteh...@freebsd.org 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
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
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 KR 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
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
Re: LDAP integration
Mike Meyer wrote: In [EMAIL PROTECTED], Vulpes Velox [EMAIL PROTECTED] typed: LDAP is nice organizing across many systems, but if you are just dealing with one computer it is complete over kill for any thing. In that situation, it's not merely overkill, it's may actually be a bad idea. Can you say AIX SDR? How about Windows registry? Those system both took the approach of putting all the configuration information in a central database. This creates problems because the tools needed to examine/fix the config database require a complex environment - at least compared to a statically linked copy of ed. LDAP may not be so bad, but it still makes me nervous. On the other hand, if you've got a flock of boxes to manage, having a way to tell the rc subsystem Go read config values from this LDAP server seems like a very attractive alternative. mike Ok, so the general consensus seems to be that it's a good idea in some cases and not in others. I myself agree that it should not be part of the base setup for issues regarding the complication of the base distribution... but why not make a package for it? Take this idea, and run with it... build a package that installs over the base installation, bundling the LDAP client libs, new rc structure, tools, etc all in one shot. Add it to the ports collection and call it done. - After all that's the wonder that is opensource... if ya want to improve something, go for it - even better if you can contribute your additions back to the community. I think it could be the start of something really handy for those out there managing large banks of servers... a central configuration repository, key-based or something where you take a freshly installed server, and point it to a config 'key', reboot and poof! That server goes down, simply tell a spare one to use it's config 'key' and reboot - back up and running :) You'd get all the redundancy of LDAP, the organization of a directory tree, and the simplicity of uniform configuration information. This of course with some assumptions about storage and backup situations, but hey - it's an idea not a reality here I'm talking about. Anyways... without digressing way too much, my point was this: if there's enough people interested in the idea, then collaborate and by all means try to make something of it. If it works out well, lots of people start adopting it, THEN we (the FreeBSD community) should look at including it as part of the base... until then, make it as a bundled package or something. I'm using LDAP here for users, groups, email and account information shared to many servers - and it works great, but it's certainly not for everyone and I'd never expect it to come out-of-the box with everything required to do so. Have to weigh the benefits against the costs. This thread keeps arguing the good or the bad points of doing this - and it seems to me not something worth arguing the merits of. If you believe in it enough, then do it or at least try it. Lets move on from if we should or shouldn't, and look more to HOW we could... Just my two and a half cents. -- Nathan Vidican [EMAIL PROTECTED] Windsor Match Plate Tool Ltd. http://www.wmptl.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
nss_ldap-243 FreeBSD/amd64 ... anyone? (build/errors/info attached)
Wasn't sure which list to post to entirely, so sorry if seems off-topic. I can't seem to get nss_ldap-243 to compile at all under FreeBSD-6.0RC1/amd64, nor under 5.3-RELEASE, nor 5.4-RELEASE... all produce similar errors, however my development machine happens to be FreeBSD 6.0RC1/amd64 at the moment (dual AMD Opteron 246 box, 2gb ECC Registered, 1.25TB RAID 5). Here's a brief transcript of what I've done/where I am at, a longer version including the output from make/configure/etc. My comments start with a # to help differentiate from output: # configure (with options as specified, openldap-2.3.11 compiled with --prefix=/usr/openldap, # installed, configured, and running with DB). configure exits clean and generates a makefile: wmptwo# ./configure CPPFLAGS=-I/usr/openldap/include -I/usr/include LDFLAGS=-L/usr/openldap/lib -L/usr/lib --with-ldap=openldap --prefix=/usr --with-ldap-dir=/usr/openldap wmptwo# # now we run make, and get our first errors in ldap-nss.c, a quick inspection shows ldap-nss.c calling CONSTs defined in sys/param.h wmptwo# make begin patch (diff ldap-nss.c.old ldap-nss.c) 25a26,29 #ifndef MAXHOSTNAMELEN #include sys/param.h #endif /patch # now I run make again, aside from a whole bunch of compiler warnings about null arguments being passed/required, (see output attached) # ldap-nss.c compiles, now we get a whole new set of compiler errors in ldap-pwd.c, first error complains of UID_NOBODY not being # defined but still being called/used... closer look reveals UID_NOBODY defined in ldap-nss.h, but not being defined: wmptwo# make # so I try patching ldap-nss.h, and update #define UID_NOBODY to reflect the default UID for the user 'nobody' on a 'standard' FreeBSD installation: patch diff ldap-nss.h.old ldap-nss.h 446d445 #ifndef HAVE_NSSWITCH_H 448,449c447 #define UID_NOBODY (-2) #endif --- #define UID_NOBODY (65534) /patch # again, I run make, this time clean first, this time we're moving further into ldap-pwd.c, but still producing fatal compiler errors # complaining about `structure has no member named `pw_comment'`, this is the point where I step back and wonder where to go next... # should I systematically continue to retry make after I try to find/fix every compiler error; will this introduce new errors, will the # code even work? wmptwo# Again, output of all the above is attached in a txt file, please fee free to take a look through. Has anyone out there been able to get nss_ldap to compile on FreeBSD; other than the patched/older dist included with the ports collection? Problem with the ports version (in my case) being the old(er) release of openldap/ldap librairies it depends on. Working out some issues with samba and nss here alltogether, needed to update openldap to get past some other un-related bugs. System still has openldap-2.2.9 installed from the ports collection for the nss_ldap, and pam_ldap that is currently running. Samba source code has been modified, compiled, and been in use for a while now running the new(er) openldap librairies installed into /usr/openldap. Just not sure where to go with nss_ldap here; havn't even begun trying to compile pam_ldap to use the new(er) openldap librairies either - but suspect I may run into similar issues. Any suggestions/guidance would be greatly appreciated at this point... kinda running out of things to try and can't really audit the entire source code for something I know little about the internals of. Thanx all -- Nathan Vidican [EMAIL PROTECTED] Windsor Match Plate Tool Ltd. http://www.wmptl.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
buffer locking
I'm working in FreeBSD 5.3-RELEASE. In various places in the buffer management code (e.g. ibwrite()) the buffer lock reference count is checked (see below), presumably to make sure the buffer is safely locked before working with it. Is there a reason that it's not neccesary to ensure that the current thread is the lockholder? This seems like it could lead to a race condition where, say ibwrite, is content because SOMEONE has the buffer locked, even if it's not the current thread. Thanks, -Nate ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ELF branding / magic numbers
On Thu, Feb 05, 2004 at 10:31:54AM +, Philip Reynolds wrote: Ruslan Ermilov [EMAIL PROTECTED] 35 lines of wisdom included: On Thu, Feb 05, 2004 at 08:39:45AM +, Philip Reynolds wrote: [...] Does the magic number not then support multiple ABI's per system architecture, or is there some part of the puzzle I'm missing? There's an EI_ABIVERSION byte following the EI_OSABI byte, which is both documented in the elf(5) manpage, and is shown in the ``readelf -h'' output. You misunderstood me. My question was why is there a need for a PT_NOTE section (which is a more convaluted way of branding and reading a brand of an elf binary) if the above sections exist? Yes. It is used on other systems, like NetBSD and Linux. Having the note section allows those system to correctly recognize FreeBSD binaries. (The people developing binutils apparently don't agree with the use of EI_OSABI.) Unfortunately, FreeBSD doesn't check for it in the kernel. Doing it as a fall-back would permit detecting statically linked Linux binaries, without needing to run brandelf on them. I've been considering working on a patch for that, but haven't had time. ---Nathan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardware for FreeBSD
For years, I've had the best luck with building my own systems, or having built to my specifications. Have comp delivered mostly assembled, but without hard drive installed, I can usually avoid having to buy Windows, too. Going this route, I pick all the parts, and can generally eliminate OS incompatibilities. I also don't buy lowest bidder parts, or try to save money on motherboards. That said, I've had pretty good luck with Dell hardware. At least the Optiflex line, don't know about PowerEdges. The Optiflex's I've bought all run both Linux and FreeBSD with no problems. (Local computer store has had used ones very cheap.) I've used the Compaq DL380 with Linux, and would recommend it as quite good and reliable hardware. Looks like the Compaq RAID controller is supported on FreeBSD, but I don't have access to one anymore, so can't try it. ---Nathan Bogdan TARU wrote: Hi hackers, I am in a big dillema (and great hurry/pressure). I need to buy some hardware for some firewalls for my company. And so the blues started. First, I went to Dell. Almost signed the papers for two PowerEdges 2550, (everything in them seemed to be compatible with FreeBSD) when I found out they are longer then the rack!!! And not only the 2550, but most of their cases. So I went to IBM. A little more expensive, but what the hack? It's IBM. So, almost made a system, and when coming to checking the compatibility list, IBM ServeRaid is not supported under FreeBSD. WTF??? So my question is: if you'd have to buy good/reliable hardware now, which is the vendor you'd choose (considering the facts above)? I looked on the FreeBSD's site for some hardware vendors in Germany (where I live), but none found. And I'd go for a brand name, anyways. Thank you, bogdan iCom Media AG Kirchweg 36 Koln, 50858 Germany Phone: +49-(0)221-485-689-16 Fax : +49-(0)221-485-689-20 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Athlon MP / AMD 760MP Chipset (Athlon SMP question)
Eclipse manufacturs 32-way xeon boxes too. http://www.eclipse.com/, recently bought out by Data General, (http://www.dg.com/, used to be the manufacturers of the Aviion/Eclipse mainframe machines... and their proprietory O/S 'unicos'. They still sell/manufacture the numa based 32-way xeon boxes, though they've stopped supporting the legacy mainframes. Nathan Vidican [EMAIL PROTECTED] http://Nathan.Vidican.com/ - Original Message - From: Wilko Bulte [EMAIL PROTECTED] To: Josh M Osborne [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, July 10, 2001 3:34 PM Subject: Re: Athlon MP / AMD 760MP Chipset (Athlon SMP question) On Tue, Jul 10, 2001 at 02:25:13PM -0400, Josh M Osborne wrote: On Tue, Jul 10, 2001 at 12:42:12PM -0400, [EMAIL PROTECTED] wrote: [...] Instead, AMD implemented the Intel APIC specification; I'm not sure if they did it by licensing the patent (Intel had a patent on the APIC design), or if it's just been long enough for it to come off patent The Athlon uses the Alpha's ev6 spec, not the intel spec. That may explain why you can buy Alpha systems with 40+ CPUs, and 32 max, on Wildfire. Intel XENON boxes with no more then eight (or is it four?). It is Eight, eg on a Compaq Proliant 8000. Or 32 for the Unisys (IIRC) CMP machines. -- | / o / / _ Arnhem, The Netherlandsemail: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Youth is not a time in life, it is a state of mind To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Athlon MP / AMD 760MP Chipset (Athlon SMP question)
I seem to recall a few discussions about the Dual Athlon buzz some while back which had stated that the Athlon would essentially require a completely different SMP spec than that currently utilized by the Intel procesors. Assuming that this was true, one would assume that the O/S too would require a different kind of SMP support in order to function with these CPUs. Unfortuneately, a recent thread has me at a bit of a loss here; in that people seem to be speaking about the processor/smp chipset as though they function just like Intel's do. Assuming that this conflicting information is indeed correct, then would it not be feasible to assume that the code currently implemented for using SMP implementations under FreeBSD would be portable to the new Athlon MP processor line? The threads I'm speaking of, were to freebsd-questions most recently wherein someone had been asking if the new Tyan ThunderK7 motherboard would work with FreeBSD. The general concencus was 'why not', from the responses I had read... but no one who answered really seemed to know for sure. Just for the record, is it or is it not possible to run SMP with the new Athlon MP Processors; or has no-one even tried yet? Currently the only O/S I know of which is promoting the usage of such systems is Novell Netware, and I am just curious if FreeBSD will (if it is not currently) be capable of running on such a system? -- Nathan Vidican [EMAIL PROTECTED] http://Nathan.Vidican.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: import NetBSD rc system
I kinda like our scheme... at least I like the single monolithic /etc/rc.conf file. It makes maintaining and installing machines utterly trivial whereas having a billion little files each with one or two options in them makes maintaining and installing machines rather difficult. I sure hope nobody is advocating doing away with the monolithic capabilities of /etc/rc.conf! NetBSD has /etc/rc.conf and /etc/defaults/rc.conf too. -- Nathan Ahlstrom / [EMAIL PROTECTED] / [EMAIL PROTECTED] / GPG: 0x67BC9D19 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
documentation help, installation and the swap partition
I am trying to document how the partitions are laid out in FreeBSD and I have noticed that the installation will place the sector offsets of the b (swap) partition before the last partition. And will also place the sector offsets of the largest partition as the last regardless to its name (ie: d or h) The question is why ? is it due to performance reasons ? or safety ? or other ? I have looked for specific documentation on this but I can't seem to find it. thanks in advance ! -nb here is an example: #size offsetfstype [fsize bsize bps/cpg] a: 26214404.2BSD 1024 819216 # (Cyl.0 - 260*) ##swap partition sectors start right befiore the d partitions sectors b: 1048576 18087936 swap# (Cyl. 17944*- 18984*) c: 600364170unused0 0 # (Cyl.0 - 59559*) ## d is the last in sectors but, the 3rd usable partition (a, b, d ) ### d: 40899905 191365124.2BSD 1024 819216 # (Cyl. 18984*- 59559*) e: 524288 2621444.2BSD 1024 819216 # (Cyl. 260*- 780*) f:524288 7864324.2BSD 1024 819216 # (Cyl. 780*- 1300*) g: 8388608 13107204.2BSD 1024 819216 # (Cyl. 1300*- 9622*) h: 8388608 96993284.2BSD 1024 819216 # (Cyl. 9622*- 17944*) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
unexplained strangness with cucipop pop3 daemon
For some (yet to be unexplained reason), cucipop has (twice now), somehow locked the /var/mail/some-user-name files, and is apparently not erasing the message and exiting. Therefore the next time a user checks email (every two minutes from Outlook) they get another copy of the same message(s). The problem does not stop, (while making some users download the same message 200 times), until cucipop is restarted manually. For obvious reasons, this is becoming a big problem. This is the second time this has happened in two weeks now, and luckily while the majority of the office was not in. What I need to do is find out what's causing it, and/or why. Someone earlier had replied explaining that maybe the system was running out of file-lock resources. So I re-compiled a new kernel with maxusers set to 256, started the system back up, and it ran since Monday morning to Saturday morning and started with the problem again. I've since then re-started cucipop, and things seem fine for now. The strange part is that we've changed nothing for months now, (cept the username of one particular UID), and it had been working fine for 70 days prior to this. (Would be like 150days, cept that we took it down to upgrade server hardware/install freebsd 4.2-stable) The machine is running an old(er) snapshot of 4.2-STABLE, and I wonder if FreeBSD, or cucipop has a problem in it? I figure maybe cucipop (like some radius daemons) has some memory leakage or something and must be restarted cylically? Any ideas, comments, suggestions, or otherwise would be highly appreciated at this point. Nathan Vidican [EMAIL PROTECTED] Windsor Match Plate Tool Ltd. http://home.wmptl.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD + Mylex DAC960 (RAID 1) + DEC Prioris HX 6000 Server will not recognize boot record for some reason
This machine is an Intel Pentium Pro based system, (not a DEC Alpha), it currently has one 200mhz 512K CPU, 196megs RAM, (4 x 32edo simms, 4 x 16edo simms), and two 4.5Gig SCSI disks in hot-swappable drive carriages configured using RAID 1 (mirrored), attached to a Mylex DAC960P/PD dual-channel controller. I have flashed the firmware of the controller card to 3.52, as reccomended during the dmesg prompts (the card initially had 3.51). The problem seems to be with booting, I have tried several installs; all seem to partition fine except for 'dangerously dedicated'. After an install using a 4.4Gig root, and an 80meg swap, (leaving 20megs un-partitioned at the end of the drive), the system will not boot. If I boot off of the installation floppies, I can mount/view the files on the drive. This leaves me thinking it's got to have something to do with FreeBSD's MBR. Having problems booting; the system installs to the mylex system drive fine, but when I reboot, I get the FreeBSD boot MGR, and it only beeps when I press F1 for FreeBSD. If I install using a normal boot record, the system reports 'No operating system found'. I'm thinking it may be an issue with the Mylex card, but I don't know for sure if the system's bios could cause this either. I cannot attempt to install the mylex card in another machine; as the drives attached to it are in a hot-swap carriage which is part of the system's chassis. On a hunch, I tried re-partitioning and installing MsDos; maybe the RAID configuration isn't bootable at all I figured; but it partitioned fine, and booted properly. I then tried installing NT, and now Linux. All three had no problems, and all three booted fine. Seeing as how the other O/S's all installed/worked fine; I'm assuming this is just a software issue. Maybe with the bios of the Raid controller, or maybe with the system bios, has anyone else run into similar problems? Am I just missing something blatenly obvious? Does FreeBSD not boot from a mirrored volume (if so... why not)? I've only ever done one other server install with FreeBSD, and a Mylex Raid controller; it booted fine. It was using an AcceleRAID PCI 150 card, with foud 9.1gig SCSIUW's in a RAID 5 configuration. It went fine with no hitches, (cept that it took like 1hr to newfs). However, this is a different controller, and having little to no experience working with RAID controllers I figured I'd ask. Baring no absolute solutions, or better partial ones from this mailing list, I'm going to install Linux on a 200meg partition, and attempt to install FreeBSD on the rest and boot it using Lilo (don't know if it's going to work...but it's worth a try). -- Nathan Vidican [EMAIL PROTECTED] Windsor Match Plate Tool Ltd. http://www.wmptl.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
eepro100 dual port cards with failover ?
We need to use the dual Intel PRO/100+ dual port server adapter, and I wanted to know if FreeBSD supports them ? I guess that the card is a dual port (2 x RJ45) card and it uses only 1 IP for both ports and if one switch goes down it will automatically failure to the other port ? Is this at the driver level or at the hardware level ? (if anyone knows ) and if FreeBSD does not support them then can anyone recommend something similar ? thank you nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
changing the way mail spools are permissioned (for using web-based email service)
I'm currently messing around with neomail, and it seems to do everything I need it to, but it doesn't read the mail spools properly. It needs to establish a write lock on /var/mail/someuser. I currently have the script set to run suid/sgid 'mail', but all the spools are set to user:logingroup for ownership. Since some users have different login groups than others; this convention leaves me with two possible options, (as I see it anyhow -suggestions welcomed): 1 - change neomail too be run as suid root, which leaves me sceptical as to it's security; should something screw up I could have a big problem on my hands. 2 - (prefered), change sendmail to have all the mail spools as group writeable for the group 'mail'. This is the way I'd prefer to do things, but I have little to no clue as to exactly how to accomplish this. Seeing as how the machine this is being done on is in production, and under constant use; downtime is also an issue; (If I change it, and something else don't work...I better have it back the way it was, and quickly so). Any comments, suggestions, or otherwise would be greatly appreciated. For the record, my system information is as follows: Running: FreeBSD 4.1-2729-STABLE (no, I don't want to cvsup/update the machine...it works fine now, and that would cause downtime) Sendmail version: ESMTP Sendmail 8.9.3/8.9.3; Wed, 13 Dec 2000 13:38:08 -0500 (EST) -- Nathan Vidican [EMAIL PROTECTED] Windsor Match Plate Tool Ltd. http://www.wmptl.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
4.2-RELEASE will not boot after install ?
Don't know if I should post here but I just installed 4.2-RELEASE onto a ppro 200 (had linux) the install went without a hich. Then when I rebooted, the box just stopped. It seemed like it could not read the mbr. So I booted again off the floppies and I used the loader to switched the currdev to the harddrive (disk1s1a) it found the hardrive. I then loaded the kernel from the harddrive and booted off the harddrive. After I was up on the box I then ran disklabel -B ad0 and thought that maybe the installation did not add the boot reccord info. Rebooted agian to have the same problem as before. I then tried it agian with the flags for the boot code, no luck. Finally I dd out the first 512 blocks of the harddrive and ran strings on it. Seems that thier was nothing their ! so I was lucky enough to have another 4.2 box and I just copied its first 512 blocks. Now it boots fine ! Is their a known issue with this ? or maybe I did something wrong ? thank you nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.2-RELEASE will not boot after install ?
"Louis A. Mamakos" wrote: I had the same problem on an old PPro box. The BIOS seemingly doesn't like the new (2 sector long) boot manager. If you fire up sysinstall again, and tell it to install the "standard bootblocks" (forgot the exact phrase), rather than the boot manager, you'll probably be OK. louie Don't know if I should post here but I just installed 4.2-RELEASE onto a ppro 200 (had linux) the install went without a hich. Then when I rebooted, the box just stopped. It seemed like it could not read the mbr. So I booted again off the floppies and I used the loader to switched the currdev to the harddrive (disk1s1a) it found the hardrive. I then loaded the kernel from the harddrive and booted off the harddrive. After I was up on the box I then ran disklabel -B ad0 and thought that maybe the installation did not add the boot reccord info. Rebooted agian to have the same problem as before. I then tried it agian with the flags for the boot code, no luck. Finally I dd out the first 512 blocks of the harddrive and ran strings on it. Seems that thier was nothing their ! so I was lucky enough to have another 4.2 box and I just copied its first 512 blocks. Now it boots fine ! Is their a known issue with this ? or maybe I did something wrong ? thank you nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Hey thanks !! I finally got a reply from this list for once :-) (please flames for that !!) I think maybe you are right but I stil don't understand why the mbr was different between my 2 4.2-RELEASE box's ? The one that worked was 4.2 by make world... so maybe it has the left over boot code ? I thought that it gets made and updated with make world ? anyway no big deal, at least if someone else has the problem they can read these posts !! thanks once agian nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Digi Xem help!
Sorry if this is the wrong list !! Anyway I have a Digi / Xem eisa adapter on 4.1-RELEASE. I have made the kernel and it see's the card. I have also remade the /dev/ttyD* entries. Problem, when I try to access any of the ports I get : cu: open (/dev/ttyD00): Device not configured cu: /dev/ttyD00: Line in use Here is the boot output: dgm0: PC/Xem (type 245) dgm0 at port 0x104-0x107 iomem 0xd-0xd7fff on isa0 dgm0: DigiBIOS loaded, initializing, DigiBIOS running dgm0: FEP/OS loaded, initializing, FEP/OS running dgm0: 16 ports dgm0: driver is using old-style compatability shims Now what do I have to do ? I have played with permissions (cu is setuid, setgid) I have also tried to use stty and comcontrol but they say the same. Any help would be great !! thank you nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: High-availability failover software available.
Andrew Sporner wrote: Hi, Here is the direct link http://www.sporner.com/bsdclusters/download Remember! this is alpha-ware :-) I will be doing some more fixes/updates this evening... Look for fresh stuff tommorrow morning... Thanks in advance for all your support! Andy -Original Message- From: David Scheidt [mailto:[EMAIL PROTECTED]] Sent: Monday, November 06, 2000 6:13 PM To: Andrew Sporner Cc: '[EMAIL PROTECTED]' Subject: Re: High-availability failover software available. On Mon, 6 Nov 2000, Andrew Sporner wrote: :Hi, : :Please allow me to introduce myself. I am Andrew Sporner and I have :authored :a H/A Failover system that happens to work with BSD. I would like to Very cool! :The current source is located at http://www.sporner.com/bsdclusters Your webpages seem to be b0rked. David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message I have been doing something very simular at work. I was wondering if you need some help ? nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
struct proc and struct vmspace help, please
I have the need for the /proc/pid/status file inside the linprocfs. So I have added it to the linprocfs_misc.c Well the only problem I am having is the VmRSS: field. How do I get the rssize from inside the kernel for a process ? from userland I can do: struct kinfo_proc-kp_eproc . e_vm . vm_rssize ( like top ) but from inside the struct proc what do I use ? I have tried the struct vmspace but it give me strange numbers (well, maybe not strange but are they in pages ? bytes ? and why are they 0 sometimes ? ) I have looked and explored all over the headers, but I am stuck. Any help will be greatly appreciated !!! thank you nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
something strange about FreeBSD 4.1-STABLE booting? (on an IBM laptop)
Has anyone got FreeBSD running, successfully on an IBM ThinkPad A20M, (24U - PII 500/128megs Ram/6Gig HD) ? I have attempted to install twice now, both times have resulted in my having to replace the hardisk with a new one from IBM. Here's what happens: I boot off of the kernel disk (floppy), insert the MFSroot disk (also floppy), everything seems normal. I create a 4gig MSDOS partition, and set it bootable, I then create a FreeBSD partition with the remaining space on the disk. I then told it to use the BootBGR. The install goes fine, (installed over FTP to a local machine; laptop has Intel 'fxp0' PCI ethernet on-board). Everything seems well, then I reboot, and the trouble begins. The system runs it's ram test, scans the floppy, spins the cdrom, then halts. I cannot get into the bios, nor can I boot off of a floppy or bootable cdrom. If I remove the hardrive, then it still hangs, but I can at least get into the bios. The computer store tried replacing the drive with one from another identical machine... works fine, can enter/exit the bios, system boots up fine, (running win98se that is). They then tried putting my drive into another laptop, and it causes the same problem on the other laptop; system halts. The computer store then came to the conclusion that the hardrive was no good, (which is what I told them when I came...before they spent two hours trying to figure it out). It seems almost as if the BIOS maintains something in the MBR of the disk. The system works fine with Win98SE, as it came pre-installed, and it works fine if I use the IBM recovery cd-rom to install Win98SE with. I can't imagine that the machine is incapable of running FreeBSD. I suspect that it may have something to do with the way the system goes into 'hybernation' mode, (wherein it writes it's current status to hardisk, and shuts off; so as to resume operations when turned back on... similar to suspend mode, except that it's automatic when the lid is closed). This might explain why it wouldn't boot from the hardisk, as it may be looking for a 'last-left' image or something; but it doesn't produce any errors, and will not boot from floppy or cdrom either. IBM then sent out a brand new replacement drive. The computer store installed it, and made sure the system booted from a floppy; they did not touch the partitioning on the drive. I took it home, ran the FreeBSD install (again over LAN), and rebooted. Same problem, black-screen; no functions. I called IBM tech support directly this time, and after spending about an hour trying to tell their technician that his solutions, (eg boot of a floppy and run 'diskzap' utility), would not work, they opted for me to send the machine back for them to look at. The machine is currently in the mail somewhere, they should receive it tonight or tomorrow morning. They say there's a 3-5 working day return time, but somehow I doubt that it will come back fixed. Any ideas, comments, suggestions, or otherwise would be greatly appreciated at this point. I don't think it'd be something with FreeBSD, but just in case, should I try to install a different version maybe? (was trying to install FreeBSD 4.1-STABLE-2924 I believe, or round the 24th's snapshot anyhow). -- Nathan Vidican [EMAIL PROTECTED] Windsor Match Plate Tool Ltd. http://www.wmptl.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
something strange about FreeBSD 4.1-STABLE booting? (on an IBM laptop)
Has anyone got FreeBSD running, successfully on an IBM ThinkPad A20M, (24U - PII 500/128megs Ram/6Gig HD) ? I have attempted to install twice now, both times have resulted in my having to replace the hardisk with a new one from IBM. Here's what happens: I boot off of the kernel disk (floppy), insert the MFSroot disk (also floppy), everything seems normal. I create a 4gig MSDOS partition, and set it bootable, I then create a FreeBSD partition with the remaining space on the disk. I then told it to use the BootBGR. The install goes fine, (installed over FTP to a local machine; laptop has Intel 'fxp0' PCI ethernet on-board). Everything seems well, then I reboot, and the trouble begins. The system runs it's ram test, scans the floppy, spins the cdrom, then halts. I cannot get into the bios, nor can I boot off of a floppy or bootable cdrom. If I remove the hardrive, then it still hangs, but I can at least get into the bios. The computer store tried replacing the drive with one from another identical machine... works fine, can enter/exit the bios, system boots up fine, (running win98se that is). They then tried putting my drive into another laptop, and it causes the same problem on the other laptop; system halts. The computer store then came to the conclusion that the hardrive was no good, (which is what I told them when I came...before they spent two hours trying to figure it out). It seems almost as if the BIOS maintains something in the MBR of the disk. The system works fine with Win98SE, as it came pre-installed, and it works fine if I use the IBM recovery cd-rom to install Win98SE with. I can't imagine that the machine is incapable of running FreeBSD. I suspect that it may have something to do with the way the system goes into 'hybernation' mode, (wherein it writes it's current status to hardisk, and shuts off; so as to resume operations when turned back on... similar to suspend mode, except that it's automatic when the lid is closed). This might explain why it wouldn't boot from the hardisk, as it may be looking for a 'last-left' image or something; but it doesn't produce any errors, and will not boot from floppy or cdrom either. IBM then sent out a brand new replacement drive. The computer store installed it, and made sure the system booted from a floppy; they did not touch the partitioning on the drive. I took it home, ran the FreeBSD install (again over LAN), and rebooted. Same problem, black-screen; no functions. I called IBM tech support directly this time, and after spending about an hour trying to tell their technician that his solutions, (eg boot of a floppy and run 'diskzap' utility), would not work, they opted for me to send the machine back for them to look at. The machine is currently in the mail somewhere, they should receive it tonight or tomorrow morning. They say there's a 3-5 working day return time, but somehow I doubt that it will come back fixed. Any ideas, comments, suggestions, or otherwise would be greatly appreciated at this point. I don't think it'd be something with FreeBSD, but just in case, should I try to install a different version maybe? (was trying to install FreeBSD 4.1-STABLE-2924 I believe, or round the 24th's snapshot anyhow). -- Nathan Vidican [EMAIL PROTECTED] Windsor Match Plate Tool Ltd. http://www.wmptl.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SMBFS
Michael Lucas wrote: My understanding of SMBFS is that it's not intended to be a server. It's a pretty solid client, though. I use it extensively, without trouble. ==ml What's the current status the native smbfs support? Can it act as a both a client and a server? How does it compare to Samba in terms of functionality? Thanks, Brandon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message How did you implement SMBFS? Is it yet a part of FreeBSD 4.1-STABLE or? New kernel option? -- Nathan Vidican [EMAIL PROTECTED] Windsor Match Plate Tool Ltd. http://www.wmptl.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
loader help !! (bug ??) 4.0-STABLE
Sorry for the re-post but not reponse !! I have FreeBSD 4.0-STABLE on i386, was -RELEASE ) What I am trying to do is nfs root boot from the loader (?) I do: ok unload kernel ok load diskless_kernel ok set kernel=diskless_kernel ok boot -r -h Now what I understand is the -r flag will tell the kernel to overide the rootdev and use the "staticly linked device" from when you made the kernel (this would be the BOOTP_NFSROOT option ?) Now my kernel (the diskless_kernel ) is a diskless kernel ( with BOOTP, NFS_ROOT etc.. ) compiled in. But when I boot like this is just tries to mount /dev/ad0s1a ... (normal device ) even though it gets the proper reply from the bootp server that its rootfs=nfs mount it even prints : rootfs is my nfs mount Mounting root from ufs:/dev/ad0s1a but still mounts the ufs ! How do if force it to boot root fs on nfs ? I have tried to do a boot -a then when I prompts me for root fs I enter the proper nfs mount and for RELEASE it would boot diskless but for STABLE is fails !! I have tried to : ok set rootdev=nfs:my nfs server ip : mount ok boot -h ok can't determine root device I have also passed it various kernel flags and env options... (mybe wrong ones ... ? ) how do I have the kernel to load the rootfs = nfs root instead of use the currdev ? What does etherboot do when it loads the kernel ? does it pass it special parameters ?? If you are wondering why I just don't boot from etherboot etc...(I do ) but... I want to be able to boot my remote systems without a floppie and chose how to boot from loader (via serail console ...I don't have serial access for the bios but I can get serial console with FreeBSD !! ). Either default (use local drive) or load the diskless kernel , then boot diskless. This way I almost the same options . and maybe automate it... Any help would be great !! thank you kindly.... nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: loader ??? Awwww... come on someone must know !!!
[EMAIL PROTECTED] wrote: I have FreeBSD 4.0-RELEASE (on i386) What I am trying to do is nfs root boot from the loader (?) I do: ok unload kernel ok load diskless_kernel ok set kernel=diskless_kernel ok boot -r -h Now what I understand is the -r flag will tell the kernel to overide the rootdev and use the "staticly linked device" from when you made the kernel ? Now my kernel (the diskless_kernel ) is a diskless kernel ( with BOOTP, NFS_ROOT etc.. ) compiled in. But when I boot like this is just tries to mount /dev/ad0s1a ... (normal device ) even though it gets the proper reply from the bootp server that its rootfs=nfs mount it even prints : rootfs is my nfs mount Mounting root from ufs:/dev/ad0s1a but still mounts the ufs ! How do if force it to boot root fs on nfs ? I have tried to do a boot -a then when I prompts me for root fs I enter the proper nfs mount and it is cool .. but I need it to do it with out promting... I have tried to : ok set rootdev=nfs:my nfs server ip : mount ok boot -h ok can't determine root device I have also passed it kernel flags ? (mybe wrong ones ... ? ) Now I have looked at the /usr/src/sys/boot/i386/libi386/bootinfo.c and I see where it checks the roodev to see if it is proper . but I cannot determine what type of device I can name so that this will not die on me ??? set rootdev=??? how do I have the kernel to load the nfs root instead of use the currdev ? What does etherboot do when it loads the kernel ? does it pass it special parameters ?? If you are wondering why I just don't boot from etherboot etc...(I do ) but... I want to be able to boot my remote systems without a floppie and chose how to boot from loader (via serail console ...I don't have serial access for the bios but I can get serial console with FreeBSD !! ). Either default (use local drive) or load the diskless kernel , then boot diskless. This way I almost the same options . and maybe automate it... Any help would be great !! thank you kindly.... nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
loader and rootdev help !!
I have FreeBSD 4.0-RELEASE (on i386) What I am trying to do is nfs root boot from the loader (?) I do: ok unload kernel ok load diskless_kernel ok set kernel=diskless_kernel ok boot -r -h Now what I understand is the -r flag will tell the kernel to overide the rootdev and use the "staticly linked device" from when you made the kernel ? Now my kernel (the diskless_kernel ) is a diskless kernel ( with BOOTP, NFS_ROOT etc.. ) compiled in. But when I boot like this is just tries to mount /dev/ad0s1a ... (normal device ) even though it gets the proper reply from the bootp server that its rootfs=nfs mount it even prints : rootfs is my nfs mount Mounting root from ufs:/dev/ad0s1a but still mounts the ufs ! How do if force it to boot root fs on nfs ? I have tried to do a boot -a then when I prompts me for root fs I enter the proper nfs mount and it is cool .. but I need it to do it with out promting... I have tried to : ok set rootdev=nfs:my nfs server ip : mount ok boot -h ok can't determine root device I have also passed it kernel flags ? (mybe wrong ones ... ? ) Now I have looked at the /usr/src/sys/boot/i386/libi386/bootinfo.c and I see where it checks the roodev to see if it is proper . but I cannot determine what type of device I can name so that this will not die on me ??? set rootdev=??? how do I have the kernel to load the nfs root instead of use the currdev ? What does etherboot do when it loads the kernel ? does it pass it special parameters ?? If you are wondering why I just don't boot from etherboot etc...(I do ) but... I want to be able to boot my remote systems without a floppie and chose how to boot from loader (via serail console ...I don't have serial access for the bios but I can get serial console with FreeBSD !! ). Either default (use local drive) or load the diskless kernel , then boot diskless. This way I almost the same options . and maybe automate it... Any help would be great !! thank you kindly.... nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
rlist.h !!! help !!!
I have several programs that use rlist.h (for various reasons ) and I cannot find it in FreeBSD 4.0 ! (mainly for swap info ) Has it been droped ? I know that the kernel/sys/rlist.h has been droped but does affect the /usr/include/sys/rlist.h ? If it has been dropped what do I use instead ??? thank you nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3ware ATA RAID driver - second Beta released
Mike Smith wrote: A driver for the 3ware family of ATA RAID controllers is available for FreeBSD-current at http://people.freebsd.org/~msmith/RAID This driver has all basic functionality, but no management at this time. 3ware can be found at http://www.3ware.com. I'd particularly like to thank Janet LeFleur at 3ware for her support in getting hardware for this effort. Comments, feedback, bug reports etc. will all be gratefully received. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message I've got the 8port 3ware card; what version of FreeBSD can support it, and how do I patch said driver into the kernel? Does this allow the hardware mirroring as setup by the bios in the 3ware card, or does one still need to use vinum? -- Nathan Vidican [EMAIL PROTECTED] Windsor Match Plate Tool Ltd. http://www.wmptl.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mremap help ? or no support for FreeBSD ? so do what ?
hild; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Thanks
but not to sound too pesky...
When you wrote
if (!mmap(base + offset, additional length,
PROT_READ | PROT_WRITE, MAP_SHARED | MAP_FIXED, fd, offset)) {
This may sound silly but after this is done then the file will reflect the changes
?
and now the file will extend beyond the original size ?
why do you need to unmap it ? if the file was mmap 'ed with MAP_SHARED and not
MAP_FIXED wouldn't the changes be made to all objects ? then you only need to
msync back the diff if any ? (or at all)
See I want to get around using the fd at all. I just want to open the file then
close it and just reference it from mem only. With Linux I think that you can do
this by calling mremap Linux man : "mremap expands (or shrinks) an existing
memory mapping"
So it would be kinda like realloc but the changes would be seen by all
objects.. ? and then I can close the fd and only keep track of 1 object. If I
need to add to it ... mremap on it.
Or am I just way off in my understanding ? I know that I did misuse the mmap in
the top snipit but I was just playing.
Thank you
nathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: mremap help ? or no support for FreeBSD ? so do what ?
Alfred Perlstein wrote:
* [EMAIL PROTECTED] [EMAIL PROTECTED] [000512 21:54] wrote:
I know that this was discussed in the past but I can't find out what to
do ?
In Linux if I have to resize a mmap 'ed object I can just use mremap
but in FreeBSD if, I want to resize it what do I do ?
I have tried writing past where I know the end is and it kinda works ?
but why ?
Is their a better solution besides just writing to the file and then
calling msync ?
Is their new plans to make a mremap call for FreeBSD 4.x ?
no.
Or am I just sh%t out of luck ?
Possibly, but if you describe what you are trying to accomplish
there may be some advice available. Your misuse of msync makes me
think that a rethinking of what you are trying to accomplish may
be a good idea. Please explain what makes you need mremap which
is not portable to any version of unix. I'm assuming you want your
app to work on Solaris and other commercial systems.
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Sorry !
Ok here is a snipit of what I am trying to do
fstat(fd, st);
if( (base = (caddr_t *) mmap(0, st.st_size, ( PROT_READ | PROT_WRITE ) ,
MAP_SHARED, fd, 0)) == MAP_FAILED)
{
MSG_ERR("cannot mmap file, exiting ! ");
_exit(1);
}
/* say st.st_size = 200, and I want to add to the end of the file more data
*/
base += 200; /* we are now at the end */
rec = (stuct rec_t *) base;
rec-len = 200;
/* we are writing to the buff, but we are past */
memmove(rec-data, data, 100);
msync(base, 0, (st.st_len + rec-len), MS_ASYNC);
the struct rec_t is an example of a stuct that I want to append to the buf
and make another reccord.
If base was a regular pointer we would segfault cause we are past the
pointers buf
but it kinda works.. meaning it will write and add and sometimes and not
segfault... sometimes...
or I can do this:
rec = (stuct rec_t *) base;
rec-len = 200;
memmove(rec-data, data, 100);
write(fd, (char *) rec, rec-len);
msync(base, 0, (st.st_len + rec-len), MS_ASYNC);
After I append to the file and then msync. I should be able to read the
reccord that I just added from base.
base should reflect the file right ?
I want to make things simple and only append to the buffer "base" and not
have to re-open the file and write to it then msync it back to mem. I know
that some of this under FreeBSD "automatic" meaning that the changes made to
the file are seen by "base" even though I do not call msync. but in
order to keep things clear, I will msync.
I hope that this wasn't too confusing... I am not good at explanations or
spelling
thank you
nathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
mremap help ? or no support for FreeBSD ? so do what ?
I know that this was discussed in the past but I can't find out what to do ? In Linux if I have to resize a mmap 'ed object I can just use mremap but in FreeBSD if, I want to resize it what do I do ? I have tried writing past where I know the end is and it kinda works ? but why ? Is their a better solution besides just writing to the file and then calling msync ? Is their new plans to make a mremap call for FreeBSD 4.x ? Or am I just sh%t out of luck ? thank you in advance nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD 4.0 installation for Laptops ??
I tried to Install the 4.0 on my laptop but it dosent seem to find the ethernet card ? I have a Sager NP8620 Cirrus Logic CL-PD6729-QC-B its on 0x3000 and irq 7 Now when it boots the kernel it finds the controller and initializes it, the link light comes on and I hear a beep but when I try to select a device installation it does not list my ethernet ? It was supported under 3.3 and 3.2 (with PAO) has thier been changes ? or is thier something special i need to do ? Please any help ? Sorry for spelling thank you nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Sound for Intel and Alpha
Is the soundblaster support for FreeBSD good ? (both intel and alpha) if so does is support any of the SB pci cards ? Do the supported cards work on both platforms ? if so which ones ? Thier is no specific mention of sound card chip sets for freebsd on their web site thank you nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Setting the default gw (with c)
Greetings !
I have a question, I need to write a small program that sets the default
gw. It is written in C and I have looked at several way to do it. One
way is using ioctl but that way seems a little "old" and not very well
documented. Here is a simple snippet of my code, now when I run it I get
an error "error 22" invalid arg. Does anyone have experience with this
and can point out what I am doing wrong ? I did have it to where it
would work but the kernel never added my netmask to the routing table.
So the route would kinda "hang" their and not do anything. I did tell it
that it was being sent but. also the flags never where set proper on
the route (when doing route -dvn flush )
Any help would be great ! (oh if this looks familiar, I learned this
from reading both ruote.c and netstat.c. )
struct rt_data_msg{
struct rt_msghdr add_rtm;
union{
struct sockaddr sa;
struct sockaddr_in sin;
struct sockaddr_dl sdl;
}rt_dst, rt_gate, rt_mask;
};
int set_droute(char *gw){
int sockfd, i, err = 0;
int flags = 0, r_addrs = 0;
u_long inits;
char t_gw[32];
register int l;
struct rt_data_msg add_rt;
pid_t pid;
/* check to see if we have a gateway address or quit */
if(!gw){
ERR("set_droute: FREEBSD no route sent ! %d");
return(BAD);
}
else{
/* convet this address if not valid quit */
if((inet_aton(gw, so_gate.sin.sin_addr)) 0){
ERR("set_droute: FREEBSD route not valid ! %d");
return(BAD);
}
}
memset(add_rt, 0, sizeof(struct rt_data_msg));
/* check to see if thier is an existing route or not make an
entry from scratch */
if( (i = get_droute(t_gw)) == BAD){
/* make the address and netmasks */
if((inet_aton("0.0.0.0", add_rt.rt_mask.sin.sin_addr))
0){ err++; }
if((inet_aton("0.0.0.0", add_rt.rt_dst.sin.sin_addr))
0) { err++; }
if((inet_aton(gw, add_rt.rt_gate.sin.sin_addr)) 0){
err++; }
if(err 0){
ERR("get_droute: FREEBSD cannot set mask or dst
or gw invalid addresses %d");
return(BAD);
}
inits = RTV_EXPIRE;
inits |= RTV_RPIPE;
inits |= RTV_SPIPE;
inits |= RTV_SSTHRESH;
r_addrs = RTAX_DST;
r_addrs |= RTAX_GATEWAY;
r_addrs |= RTAX_NETMASK;
flags = RTF_UP;
flags |= RTF_GATEWAY;
flags |= RTF_STATIC;
flags |= RTF_PRCLONING;
/* add thier size */
#define ADD_SIZE(w) l = ROUNDUP(w.sa.sa_len)
#define ROUNDUP(a)((a) 0 ? (1 + (((a) - 1) | (sizeof(long) - 1)))
: sizeof(long));
ADD_SIZE(add_rt.rt_dst);
ADD_SIZE(add_rt.rt_gate);
ADD_SIZE(add_rt.rt_mask);
/* add their address family */
#define ADD_FAM(x) x.sin.sin_family = AF_INET;
ADD_FAM(add_rt.rt_dst);
ADD_FAM(add_rt.rt_gate);
ADD_FAM(add_rt.rt_mask);
ADD_FAM(add_rt.rt_genmask);
/* set up all of the flags and tables */
#define RD add_rt.add_rtm
RD.rtm_msglen = l;
RD.rtm_version = RTM_VERSION;
RD.rtm_type = RTM_ADD;
RD.rtm_flags = flags;
RD.rtm_addrs = rtm_addrs;
RD.rtm_inits = RTF_GATEWAY;
RD.rtm_pid = pid = getpid();
RD.rtm_seq = ++SEQ;
if( (sockfd = socket(PF_ROUTE, SOCK_RAW, 0)) 0){
ERR("set_droute: FREEBSD cannot open socket
%d");
}
/* send it to the kernel */
i = write(sockfd, (char *)add_rt, l);
syslog(LOG_ERR, "errno = %d ", errno);
}
else{
/* get a buffer for the data */
ERR("get_droute returned ok %d ");
}
return(GOOD);
}
Thank you
nathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Device Drivers
I;d like to start contributing to the project, and I've heard unanimously a good place to start is device drivers. However, I'd like to try something other than sound cards (the only major recommendation I've heard so far) Are there any NICs, or other driver areas where FreeBSD could use some help? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
I'd like to help!
Hi, I'd like to contribute, if I may. Is there anything that high on the wishlist that I may help with? A bit of background: I've been with FreeBSD since 2.1. previously NeXTSTEP, SCO (don't laugh), HP-UX and SUNOS/Solaris. One thing I though about is the lack of an LVM equivalent - most commerical system offer this- any thoughts? Regards, Nathan Gould [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Are certain parts of kernel not using suser() when they should?
Bill Fumerola [EMAIL PROTECTED] wrote: On Tue, 24 Aug 1999, Ryan wrote: Grepping through the kernel source tree, one finds these 12 files that use "uid == 0" checks instead of the usual suser(). There may be more than one instance per function/macro: [...] Is there a reason for these checks not to use suser? No. Eivind Eklund was working this according the FreeBSD projects page ([EMAIL PROTECTED]). I don't know the implication of this, would this impact phk's jail routines? There are some prelimiary patches for this on my web page. http://www.freebsd.org/~nrahlstr/suser.patch I had been working with Eivind on it, but I have not had time as of late. The patch that is there should be close to commit ready modulo a decsion to use suser vs. suser_xxx. If anyone is interested in committing this patch, I can work with them/clean it up if necessary. Thanks! Nathan -- Nathan AhlstromFreeBSD: http://www.FreeBSD.org/ [EMAIL PROTECTED] PGP Key ID: 0x67BC9D19 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Are certain parts of kernel not using suser() when they should?
Bill Fumerola bi...@jade.chc-chimes.com wrote: On Tue, 24 Aug 1999, Ryan wrote: Grepping through the kernel source tree, one finds these 12 files that use uid == 0 checks instead of the usual suser(). There may be more than one instance per function/macro: [...] Is there a reason for these checks not to use suser? No. Eivind Eklund was working this according the FreeBSD projects page (eiv...@freebsd.org). I don't know the implication of this, would this impact phk's jail routines? There are some prelimiary patches for this on my web page. http://www.freebsd.org/~nrahlstr/suser.patch I had been working with Eivind on it, but I have not had time as of late. The patch that is there should be close to commit ready modulo a decsion to use suser vs. suser_xxx. If anyone is interested in committing this patch, I can work with them/clean it up if necessary. Thanks! Nathan -- Nathan AhlstromFreeBSD: http://www.FreeBSD.org/ nrahl...@winternet.com PGP Key ID: 0x67BC9D19 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
My bad, as the current generation says, and it's a major item on my TODO list to spend about 2 days pouring through his code and generating a comprehensive set of comments about where to go from there. Unfortunately, this code is also in the very early stages and represents about 34,000 lines of uncommented C++ and TCL code which requires egcs, turbovision 0.7 and (optionally) Qt 1.42 to build so the learning/testing curve is a bit steep. Every person I've handed a copy to so far has never reported back with anything to pass on to the contractor in question.. :) Would it be possible to have this code put up for www/ftp or something, so that anyone who is interested could have a look? I, for one, would like to have a look at it. Nathan, not ready to commit to working on something like this. :( -- Nathan AhlstromFreeBSD: http://www.FreeBSD.org/ [EMAIL PROTECTED] PGP Key ID: 0x67BC9D19 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Lizard...
My bad, as the current generation says, and it's a major item on my TODO list to spend about 2 days pouring through his code and generating a comprehensive set of comments about where to go from there. Unfortunately, this code is also in the very early stages and represents about 34,000 lines of uncommented C++ and TCL code which requires egcs, turbovision 0.7 and (optionally) Qt 1.42 to build so the learning/testing curve is a bit steep. Every person I've handed a copy to so far has never reported back with anything to pass on to the contractor in question.. :) Would it be possible to have this code put up for www/ftp or something, so that anyone who is interested could have a look? I, for one, would like to have a look at it. Nathan, not ready to commit to working on something like this. :( -- Nathan AhlstromFreeBSD: http://www.FreeBSD.org/ nrahl...@winternet.com PGP Key ID: 0x67BC9D19 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: USENIX FreeBSD Dinner
Is there any plan for which evening of the conference this big dinner will happen? or will we all just be out each night getting crazy? ;-) Pat Lynch ly...@rush.net wrote: Well all, a few months ago, jkh handed the dinner plans off to me for USENIX, so I've been doing a little research : I want people to look at these URL's and let me know which of them sound the most interesting (I lean towards the Mission Ranch in Carmel, but I'm not sure how far it is from the Conference Center). Mission Ranch http://www.digitallantern.com/monterey/r/5/rm549.html Tarpy's Roadhouse (a little expensive) http://www.digitallantern.com/monterey/r/8/rm859.html Domenico's (this sounds very promising, inexpensive) http://www.digitallantern.com/monterey/r/2/rm229.html Jardines De San Juan (possibly too far away, but inexpensive, and listed as one of the If you in Monterey only one time places) and last but not least, inexpensive too, Rappa's http://www.digitallantern.com/monterey/r/7/rm700.html please let me know what you guys think, I want this to be a good time for all... -Pat ___ Pat Lynch ly...@rush.net Systems Administrator Rush Networking Wow, everyone looks different in Real Life (tm)- Nathan Dorfman meeting people at FUNY Suicide is painless, switching to NT isn't.- Unknown ___ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-chat in the body of the message -- Nathan AhlstromFreeBSD: http://www.FreeBSD.org/ nrahl...@winternet.com PGP Key ID: 0x67BC9D19 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
