Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
I'll commit this to rc.diskless1 this will only work if you include the changes to bootp.c +if [ -z `hostname -s` ]; then +hostname=`kenv dhcp.host-name` +hostname $hostname +echo Hostname is $hostname +fi BUT you've missed the point with this point: +else +mount_md 4096 /conf/etc 0 +chkerr $? MFS mount on /conf/etc +mount -t unionfs /conf/etc /etc +/bin/chmod 755 /etc +find /etc /dev/null +touch /etc/.sentinel That being that some of us actually WANT /etc to be left the fsck alone. We NFS mount / and that / has /etc as it should be. I also cannot follow what you are trying to do with /etc/conf. Perhaps you could comment that part? i don't understand what you mean by 'left the fsck alone', but i'll try to explain. / ( and whatever is under it) is NFS mounted read only, as should be. the 'original' solution is to make /etc writable is to mount a MD, then copy all /conf/default/etc to it. my 'solution' is to mount union /etc/conf as the 'writable' part. 1) i don't have to copy - and hence 2) have only one copy of /etc for all my diskless. since the next part of rc.diskless1 copies files specific to the host/cluster, and there are some cases that i want to actually remove a file, i do that in rc.local (configurable via rc.conf.local). thanks for looking into this, danny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
On Mon, Apr 22, 2002 at 10:40:44AM +0300, Danny Braniss wrote: Since im very interested in diskless/dataless, and i've been at it for some time now, i made some changes to libstand/bootp.c and /etc/rc.diskless1 which i wouldn't mind receiving commnets/suggestions, and if possible incorporated. the stuff is in: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/diskless-boot/ The bootp.c.diff looks like it could be useful; but I see you changed some stuff related to PXE booting and I cannot easily test that. Maybe someone else can. if you change #define CLASSIDFreeBSDc to #define CLASSIDPXEClient you will get same behaviour as before. the rest is just an addition to put stuff in the environment. danny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
On Mon, Apr 22, 2002 at 11:16:58AM -0700, Doug White wrote: On Sat, 20 Apr 2002, Lyndon Nerenberg wrote: For the benefit of packet sniffers and other things that only want read-only access to /dev/bpf*, what do people think of adding a 'bpf' group for those programs? This allows bpf devices to be read by programs running with an effective gid of 'bpf' instead of the current requirement for an effective user of root. I've been running this way on many of our servers for several months now, and things like snort, tcpdump, etc., are quite happy with it (under stable). There's the other small problem that you have to be root to set promiscuous mode. Nope. Just read access to bpf(4). -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
On Tue, Apr 23, 2002 at 09:19:56AM +0300, Danny Braniss wrote: That being that some of us actually WANT /etc to be left the fsck alone. We NFS mount / and that / has /etc as it should be. I also cannot follow what you are trying to do with /etc/conf. Perhaps you could comment that part? i don't understand what you mean by 'left the fsck alone', but i'll try to explain. / ( and whatever is under it) is NFS mounted read only, as should be. This is where all of us doing Sparc64 development say you are wrong -- / is NFS mounted RW. Back in the SunOS diskless workstations days were this was invented, / was NFS mounted RW. Please stop assuming everyone wants to change from tradition. the 'original' solution is to make /etc writable is to mount a MD, then copy all /conf/default/etc to it. The very original solution was to mount NFS / RW. The move to /conf/default/etc was someone's special needs leaking into the FreeBSD repository. If you want to special case, things be my guest -- add an elif test; but leave RW NFS mounted / alone. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
Thus spake Terry Lambert [EMAIL PROTECTED]: I'm pretty sure Solaris also used 4K pages for swappable memory in the kernel, as well: 4M pages don't make much sense, since you could, for example, exhaust KVA space with 250 kernel modules (250 X (1 data + 1 code) * 4M = 2G). It doesn't use 4M pages for all kernel memory---just the first 4M of code and the first 4M of data. Supposedly it also allows applications to take advantage of 4M pages, though I'm not sure how that works. At the very least I'd suppose that those pages are locked into memory. I don't know where the Linux limitation comes from; it's really hard for me to believe ~3G, since it's not an even power of 2, so I don't really credit this limitation. I don't really understand it either. I could try to find the link to where I found this information if you're interested, but I wouldn't be surprised if it is simply wrong. The 2.4 kernel docs seem to imply that 2.4 can use 4 GB of RAM without PAE. No problem; I think you will have to, if you are planning on mucking about with more than 4G of physical memory. I have no such plans in the immediate future; at this point the discussion is a curiosity. But with any luck I will already know what's going on by the time I need to worry about tweaking the kernel in bizarre ways. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Status on ftp servers?
On Tue, Apr 23, 2002 at 01:11:14AM -0500, Justin Heath wrote: Any word on when current.freebsd.org or releng4.freebsd.org will be available again? I noticed some discussion of this dating back to February but did not see a final date. If it is still going to be down for a while anyone know of an alternative site? Thanks. snapshots.jp.freebsd.org -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg37555/pgp0.pgp Description: PGP signature
Re: Status on ftp servers?
Thanks. At 01:31 AM 4/23/2002 -0700, Brooks Davis wrote: On Tue, Apr 23, 2002 at 01:11:14AM -0500, Justin Heath wrote: Any word on when current.freebsd.org or releng4.freebsd.org will be available again? I noticed some discussion of this dating back to February but did not see a final date. If it is still going to be down for a while anyone know of an alternative site? Thanks. snapshots.jp.freebsd.org -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 Justin Heath To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
David O'Brien wrote: / ( and whatever is under it) is NFS mounted read only, as should be. This is where all of us doing Sparc64 development say you are wrong -- / is NFS mounted RW. Back in the SunOS diskless workstations days were this was invented, / was NFS mounted RW. Please stop assuming everyone wants to change from tradition. While it's true that this was the case for workstations, where you would end up having 128 workstations and 128 copies of the / directory on the server for the diskless/dataless workstations, I think the R/W mount was out of necesssity, not out of desirability. For most of the work I've done over the past 5/6 years, it's really desirable to have / mounted read-only. the 'original' solution is to make /etc writable is to mount a MD, then copy all /conf/default/etc to it. The very original solution was to mount NFS / RW. The move to /conf/default/etc was someone's special needs leaking into the FreeBSD repository. If you want to special case, things be my guest -- add an elif test; but leave RW NFS mounted / alone. This isn't just about NFS... it's also about Fash devices, which are only warranteed for a limited number of writes, which mounting R/W would really eat into, and it's for read-only media, like in the ClosedBSD and PicoBSD FreeBSD based firewalls, I think. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Memory overwrite problem in the -current kernel ??
This commit detects a memory overwrite problem in the kernel which
happens before we ever get into userland for the first time.
The commit which causes the problem to appear is my own commit to
subr_disklabel.c (1.65).
If the block below is put back in subr_disklabel.c the memory overwrite
problem goes away (or at least doesn't happen in GEOM).
My testbox is a single-cpu machine.
Something is screwed somewhere...
Poul-Henning
] #ifdef notquite
] /*
] * Mutex to use when delaying niced I/O bound processes in bioqdisksort().
] */
] static struct mtx dksort_mtx;
] static void
] dksort_init(void)
] {
]
] mtx_init(dksort_mtx, dksort, NULL, MTX_DEF);
] }
] SYSINIT(dksort, SI_SUB_DRIVERS, SI_ORDER_MIDDLE, dksort_init, NULL)
] #endif
In message [EMAIL PROTECTED], Poul-Henning Kamp
writes:
phk 2002/04/23 04:48:45 PDT
Modified files:
sys/geom geom.h geom_dump.c geom_enc.c
geom_slice.c geom_subr.c
Log:
Introduce some serious paranoia to try to catch a memory overwrite problem
as early as possible.
Sponsored by: DARPA NAI Labs
Revision ChangesPath
1.13 +13 -4 src/sys/geom/geom.h
1.7 +1 -0 src/sys/geom/geom_dump.c
1.3 +1 -0 src/sys/geom/geom_enc.c
1.11 +2 -0 src/sys/geom/geom_slice.c
1.8 +46 -2 src/sys/geom/geom_subr.c
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
On Mon, 22 Apr 2002, Terry Lambert wrote: Marc G. Fournier wrote: First, alot of this stuff is slowly sinking in ... after repeatedly reading it and waiting for the headache to disapate:) But, one thing that I'm still not clear on ... If I have 4Gig of RAM in a server, does it make any sense to have swap space on that server also? Yes. But it (mostly) does not apply to KVA, only to UVA data, and there are much larger KVA requirements, so the more RAM you have, the bigger the bottleneck to user space for anything you swap. Okay ... to me, a bottleneck generally means slowdown ... so the more RAM I have, the slower the system will perform? Again, from what I'm reading, I have a total of 4Gig *aggregate* to work with, between RAM and swap, but its right here that I'm confused right now ... basically, the closer to 4Gig of RAM you get, the closer to 0 of swap you can have? No. I think you are getting confused on cardinality. You get one KVA, but you get an arbitrary number of UVA's, until you run out of physical RAM to make new ones. You have 4G aggregate KVA + UVA. So if your KVA is 3G, and your UVA is 1G, then you can have 1 3G KVA, and 1000 1G UVA's. Okay, first question here ... above you say 'arbitrary number of UVAs', but here you state 1000 ... just a number picked out of the air, or is this some fixed limit? Certain aspects of KVA are non-swappable. Some parts of UVA are swappable in theory, but never swapped in practice (the page tables and descriptors for each user process). The closer to 4G you have, the more physical RAM you have to spend on managing the physical RAM. The total amount of physical RAM you have to spend on managing memory is based on the total physical RAM plus the total swap. Okay, this makes sense ... I notice in 4.5-STABLE that if maxusers is set to 0, then the system will auto-tune based on memory ... is this something that also is auto-tuned? As soon as that number exceeds ~2.5G, you can't do it on a 32 bit processor any more, unless you hack FreeBSD to swap the VM housekeeping data it uses for swapping UVA contents. Okay, now here you lost me ... which number exceeds ~2.5G? The total amount of physical RAM you have to spend? Think of physical RAM as a resource. It's seperate from the KVA and UVA, but the KVA has to have physical references to do paged memory management. You are limited by how many of these you can have in physical RAM, total. Okay ... alot of lights came on simultaneously with this email ... some of those lights, mind you, might be false, but its a start ... If I'm understanding this at all ... the KVA (among other things) is a pre-allocated/reserved section of RAM for managing the UVAs ... simplistically, it maintains the process list and all resources associated with it ... I realize it does do alot of other things, but this is what I'm more focused on right now ... Now, what exactly is a UVA? You state above '1000 1G UVAs' ... is one process == 1 UVA? Or is one user (with all its associated processes) == 1 UVA? Next, again, if I'm reading this right ... if I set my KVA to 3G, when the system boots, it will reserve 3G of *physical* RAM for the kernel itself, correct? So on a 4G machine, 1G of *physical* RAM will be available for UVAs ... so, if I run 1G worth of processes, that is where swapping to disk comes in, right? Other then the massive performance hit, and the limit you mention about some parts of UVA not being swappable, I could theoretically have 4G of swap to page out to? Is there a reason why this stuff isn't auto-scaled based on RAM as it is? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
On Tue, Apr 23, 2002 at 03:38:59AM -0700, Terry Lambert wrote: the 'original' solution is to make /etc writable is to mount a MD, then copy all /conf/default/etc to it. The very original solution was to mount NFS / RW. The move to /conf/default/etc was someone's special needs leaking into the FreeBSD repository. If you want to special case, things be my guest -- add an elif test; but leave RW NFS mounted / alone. This isn't just about NFS... it's also about Fash devices, which are only warranteed for a limited number of writes, which mounting R/W would really eat into, and it's for read-only media, like in the ClosedBSD and PicoBSD FreeBSD based firewalls, I think. As I said Terry, change the patch to not take away RW /. Add an elif check, add a `readonly_root' rc.conf knob, etc... But people should stop assuming everyone wants their special needs and local weirdness. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
On Tue, 23 Apr 2002, David O'Brien wrote: On Tue, Apr 23, 2002 at 03:38:59AM -0700, Terry Lambert wrote: the 'original' solution is to make /etc writable is to mount a MD, then copy all /conf/default/etc to it. The very original solution was to mount NFS / RW. The move to /conf/default/etc was someone's special needs leaking into the FreeBSD repository. If you want to special case, things be my guest -- add an elif test; but leave RW NFS mounted / alone. This isn't just about NFS... it's also about Fash devices, which are only warranteed for a limited number of writes, which mounting R/W would really eat into, and it's for read-only media, like in the ClosedBSD and PicoBSD FreeBSD based firewalls, I think. As I said Terry, change the patch to not take away RW /. Add an elif check, add a `readonly_root' rc.conf knob, etc... But people should stop assuming everyone wants their special needs and local weirdness. So personally I do use the read/only version, since it improves the scalability (and sanity) of the diskless environment by preventing leakage from workstations onto the server except in specifically supported ways. That said, I'd prefer a simpler default setting. A series of rc.conf settings would make the most sense to me-- diskless_root_readonly=NO # Make it YES for readonly diskless_etc_localmd=NO # Make it YES to have the # diskless environment md-mount and replicate /etc from /conf diskless_var_localmd=NO # Make it YES to have the # diskless environment md-mount /var and populate it from skeleton files This would provide full compatibility with the current model for those that want it (and I think it's more people than you think) at the same time as changing the system to provide easy support for the environment you're looking for. If the default settings are changing, it should be a 5.0 feature not a 4.x feature. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
On Tue, Apr 23, 2002 at 12:19:58PM -0400, Robert Watson wrote:
diskless_root_readonly=NO # Make it YES for readonly
good.
diskless_etc_localmd=NO # Make it YES to have the
# diskless environment md-mount and replicate /etc from /conf
Seems the if [ -d ] tests in rc.diskless are OK already. If we add
this knob, then a knob should also be added for the source of the files
rather than assuming /conf/etc or /conf/{client}/etc. In other words
either really engineer this to make diskless properly configurable, or
have the minimal number of knobs, etc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
On Tue, Apr 23, 2002 at 12:19:58PM -0400, Robert Watson wrote:
diskless_root_readonly=NO # Make it YES for readonly
good.
diskless_etc_localmd=NO # Make it YES to have the
# diskless environment md-mount and replicate /etc from /conf
Seems the if [ -d ] tests in rc.diskless are OK already. If we add
this knob, then a knob should also be added for the source of the files
rather than assuming /conf/etc or /conf/{client}/etc. In other words
either really engineer this to make diskless properly configurable, or
have the minimal number of knobs, etc.
nice, but impractical, because of the chicken and egg problem, or in other
words, the load/over-write of rc.conf[.local] happens a bit later ...
danny
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
On Tue, Apr 23, 2002 at 08:32:51PM +0300, Danny Braniss wrote:
On Tue, Apr 23, 2002 at 12:19:58PM -0400, Robert Watson wrote:
diskless_root_readonly=NO # Make it YES for readonly
good.
diskless_etc_localmd=NO # Make it YES to have the
# diskless environment md-mount and replicate /etc from /conf
Seems the if [ -d ] tests in rc.diskless are OK already. If we add
this knob, then a knob should also be added for the source of the files
rather than assuming /conf/etc or /conf/{client}/etc. In other words
either really engineer this to make diskless properly configurable, or
have the minimal number of knobs, etc.
nice, but impractical, because of the chicken and egg problem, or in other
words, the load/over-write of rc.conf[.local] happens a bit later ...
Please explain farther what is impractical and where the chicken-and-egg
problem is. I rc.diskless1 already has:
if [ -d /conf/default/etc ]; then
..snip..
if [ -d /conf/${i}/etc ]; then
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
David O'Brien wrote: The very original solution was to mount NFS / RW. The move to /conf/default/etc was someone's special needs leaking into the FreeBSD repository. If you want to special case, things be my guest -- add an elif test; but leave RW NFS mounted / alone. This isn't just about NFS... it's also about Fash devices, which are only warranteed for a limited number of writes, which mounting R/W would really eat into, and it's for read-only media, like in the ClosedBSD and PicoBSD FreeBSD based firewalls, I think. As I said Terry, change the patch to not take away RW /. Add an elif check, add a `readonly_root' rc.conf knob, etc... But people should stop assuming everyone wants their special needs and local weirdness. In my experience, the read/write NFS / mount requires that you seriously limit the number of client machines, to get any performance at all. I understand that this is the way that the old SunOS 4.1.3u2 based engineering environments used to be recommended to be configured by the green-and-which Systeam Adminstrator's Guide for SunOS. I would argue that this is not really appropriate for a cluster or other common use today. So if your argument is based on make no assumptions, it's OK, but you seem to be repeating the mantra assume the default most common use is like the old SunOS 4.1.3u2 recommended use for a small number of IPC boxes. I think the default should be a read-only /, and if there is a knob, it's to make the / read/write. In SunOS diskless/dataless configurations, as installed off CDROM, the intent of a read/write / was to permit local files to be modified... specifically, /tmp and /etc/hosts and the default configuration data for the ethernet. This was really a desirable (at the time) side effect (IMO), with the real intent being to provide a root image that was customized for the hardware being booted. With the prevalence of kernel modules to support the range of hardware on differently configured diskless/dataless workstations, it really makes much more sense to share a single / image among a lot of machines. If the intent isn't NFS mounting, but local read-only/read-mostly media (which I would argue is a better match for todays common usage), then really you want it to be the default. If that isn't enough: you aren't going to be able to set the knob to make it read-only, after the fact, but setting a knob to make it read/write after the fact is really easy, so it should use negative logic for the feature, anyway. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
Robert Watson wrote: This would provide full compatibility with the current model for those that want it (and I think it's more people than you think) at the same time as changing the system to provide easy support for the environment you're looking for. If the default settings are changing, it should be a 5.0 feature not a 4.x feature. FWIW, I thought this was a new feature, since diskless/dataless has never really worked for me, without a lot of local hacking to make it work. So put me down on the list for don't change the default behaviour, if someone has actually been able to make the thing work in 4.x with the supplied scripts. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
Terry Lambert wrote: configured by the green-and-which Systeam Adminstrator's Guide green-and-white System for SunOS. Ugh. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
On Tue, 23 Apr 2002, Terry Lambert wrote: Robert Watson wrote: This would provide full compatibility with the current model for those that want it (and I think it's more people than you think) at the same time as changing the system to provide easy support for the environment you're looking for. If the default settings are changing, it should be a 5.0 feature not a 4.x feature. FWIW, I thought this was a new feature, since diskless/dataless has never really worked for me, without a lot of local hacking to make it work. So put me down on the list for don't change the default behaviour, if someone has actually been able to make the thing work in 4.x with the supplied scripts. I have't really used the diskless environment with 4.x, but use it extensively in my test/development environments for 5.0. Stateless workstations are great when it comes to file system debugging, especially since newfs is orders of magnitude faster than fsck :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hello,support,how are you
Regarding your message to chambers msgid=[EMAIL PROTECTED] *** SECURITY WARNING *** The antivirus scanner installed at XiG.COM detected that your message may contain hazardous embedded scripting or attachments. We do not accept mail with executable or MS-Document attachments. If you have any questions, please reply to this notification message. It is possible that your message was infected by a virus. You should make sure your virus signature list is up-to-date and then rescan your computer. If the document you are sending is MS-Word, please try saving it using a different format (such as Rich Text - RTF) that will remove all macros. Cordially, Xi Graphics System Adminstration [EMAIL PROTECTED] REPORT: Trapped poisoned executable contents-pb2500tc.scr REPORT: Not a document, or already poisoned by filename. Not scanned for macros. STATUS: Message quarantined, not delivered to recipient. -- Message sanitized on mist.xig.com See http://www.impsec.org/email-tools/procmail-security.html for details. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
Robert Watson wrote: I have't really used the diskless environment with 4.x, but use it extensively in my test/development environments for 5.0. Stateless workstations are great when it comes to file system debugging, especially since newfs is orders of magnitude faster than fsck :-). THat is what I primarily use them for, as well. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: implementing linux mmap2 syscall
Basically, linux_mmap2 takes 6 args, and this looks here like only 5 args are making it in... I checked this because the sixth argument to linux_mmap2() in truss was showing 0x6, but when I printed out that arg from the kernel, it was showing 0x0. Am I correct here? Ken Yes. According to http://john.fremlin.de/linux/asm/, linux used to parse only 5 args but now it parses six. Try adding: args[5] = tf-tf_ebp; I don't think that arg is there: Apr 23 10:36:13 ken /kernel: tf-tf_ebp = -1077938040 Ken My guess is that we're not doing something we should be doing in int0x80_syscall in order to get that last arg. But I do not have enough x86 knowledge to understand how the trapframe is constructed, so I cannot tell what needs to be done. Perhaps somebody with more x86 fu can help. Sorry, Crap, I don't know what's going on either, I was just looking at the asm in src/sys/i386/i386/exception.s, but I'm not very good with asm either, Can anyone help? I'm cross-posting to -current since nobody on hackers or emulation is able to help. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
On Tue, Apr 23, 2002 at 09:44:50AM -0300, Marc G. Fournier [EMAIL PROTECTED] wrote: Next, again, if I'm reading this right ... if I set my KVA to 3G, when the system boots, it will reserve 3G of *physical* RAM for the kernel itself, correct? So on a 4G machine, 1G of *physical* RAM will be available for UVAs ... so, if I run 1G worth of processes, that is where swapping to disk comes in, right? Other then the massive performance hit, and the limit you mention about some parts of UVA not being swappable, I could theoretically have 4G of swap to page out to? You can have up to ~12GB of usable swap space, as I've heard. Don't remember why such arbitrary limit, unfortunately. Information about such topics is spread over several lists arhives, usually the subjects are strange, too.. so hard to find out. As I understand it you are on the track, having 3GB allocated to KVA means 1GB for UVA, whatever it exactly means. Userspace processes will allocate memory from UVA space and can grow over 1GB of size if needed by swapping. You can certainly have more than one over-1GB process going on at the same time, but swapping will constrain your performance. I'm sure Terry or some other knowledgeable person will correct me if it doesn't make sense. Is there a reason why this stuff isn't auto-scaled based on RAM as it is? Probably lack of manpower, to code it up you'll have to understand every bit of it, but as we currently see, we don't understand it, probably many others as well :-) -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
On Tue, Apr 23, 2002 at 12:25:31PM -0700, Terry Lambert [EMAIL PROTECTED] wrote: Vallo Kallaste wrote: You can have up to ~12GB of usable swap space, as I've heard. Don't remember why such arbitrary limit, unfortunately. Information about such topics is spread over several lists arhives, usually the subjects are strange, too.. so hard to find out. As I understand it you are on the track, having 3GB allocated to KVA means 1GB for UVA, whatever it exactly means. Userspace processes will allocate memory from UVA space and can grow over 1GB of size if needed by swapping. You can certainly have more than one over-1GB process going on at the same time, but swapping will constrain your performance. I'm sure Terry or some other knowledgeable person will correct me if it doesn't make sense. Actually, you have a total concurrent virtual address space of 4G. If you assign 3G of that to KVA, then you can never exceed 1G of space for a user process, under any circumstances. This is because a given user process and kernel must be able to exist simultaneously in order to do things like copyin/copyout. Hmm, ok, but can we have more than one 1G user process at one time? Four 500MB ones and so on? Somehow I've made such conclusion based on previous information. Should be so, otherwise I don't understand how swapping will fit into overall picture. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
Terry Lambert (who fits my arbitrary definition of a good cynic) writes: It's a hazard of Open Source projects, in general, that there are so many people hacking on whatever they think is cool that nothing ever really gets built to a long term design plan that's stable enough that a book stands a chance of having a 1 year lifetime. I could not help but notice your multiple attempts at expresing this particular concept often, that is...an implied necessity of a book that explains what's going on under the kernel hood. I agree that such a book would rapidly be out of date, but I also see the necessity thereof. So, it's time to question the assumption that the information you want available should be in a book. Many websites have annotation as a form of ad-hoc documentation (e.g. php.net). Why not have someone take a crack at documenting the FreeBSD kernel, and perhaps use some annotation feature to create a living document which (hopefully) comes close to describing the kernel architechture? If you want to track a moving target, perhaps you need to use a moving track? -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] The opinions expressed above are entirely my own What's so special about the Net? People -still- don't listen... -The Unknown Drummer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
upgrade from 4.5 to current fails
Hello Folks. I currently try to upgrade from 4.5 STABLE to CURRENT. I have cvsuped my source and already made buildworld and buildkernel. But installworld failed with Signal 12 while installing chpass. When I try to remove chpass from hand I get a operation not permitted error. Apparently the immutable flag prevents the file from being deleted. Which is strange because the securelevel should be 0 when I'm in single user mode. So I should be able to change the immutable flag. So I booted from my fixit floppy mounted my slices and chrooted to my root partition. But even then installworld dies with Signal 12 while processing chpass. And rm -f chpass will give me an operation not permitted error. So what is wrong here? Any Ideas? Regards Christian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: upgrade from 4.5 to current fails
Yeah. I picked those up too -- the signal 12 @ the install phase of chfoo. I also got another shell failure when doing the depend phase of the kernel build, but since I don't care what is in vers.c, and I don't care about the chfoo set of utilities, I cheerfully continued. On the second make the signal 12's were not repeated. I converted three nodes from -STABLE to -CURRENT, getting the same shell error at the same place. Having spent many paid hours debugging the shell, this wasn't worth the unpaid time to fix, since the work-around is simply a hosted (2nd) build, in addition to the cross (1st) build. Enjoy. Eric To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: upgrade from 4.5 to current fails
- Original Message - From: Eric Brunner-Williams in Portland Maine [EMAIL PROTECTED] To: Christian Flügel [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, April 23, 2002 11:55 PM Subject: Re: upgrade from 4.5 to current fails Yeah. I picked those up too -- the signal 12 @ the install phase of chfoo. I also got another shell failure when doing the depend phase of the kernel build, but since I don't care what is in vers.c, and I don't care about the chfoo set of utilities, I cheerfully continued. It is strange that nothing is mentioned in either UPDATING or README about these problems. Having spent many paid hours debugging the shell, this wasn't worth the unpaid time to fix, since the work-around is simply a hosted (2nd) build, in addition to the cross (1st) build. What do you mean with hosted build? installworld just plain stoppped on this error which has left me with a system in an unusable state. So what can I do (except reinstalling everything) do get things going again. Regards Christian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Heads up: -current sucks today :-)
On 18-Apr-2002 Hiten Pandya wrote: --- Robert Watson [EMAIL PROTECTED] wrote: I've had four seperate and distinct panics on my -current box from yesterday in the last twenty minutes. -CURRENT appears to be somewhat unstable. Yes, this is -CURRENT; please wear a hard hat and avoid manipulating critical data using you -CURRENT box until things settle down. I have been seeing a 'witness_get exhausted' message for quite a long time. I have disabled SMP on my kernel as of now, but still have to figure out where and why this message is coming. The witness_get thing was fixed a week or so ago with the lock descriptions added to mtx_init(). -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Memory overwrite problem in the -current kernel ??
On 23-Apr-2002 Poul-Henning Kamp wrote:
This commit detects a memory overwrite problem in the kernel which
happens before we ever get into userland for the first time.
The commit which causes the problem to appear is my own commit to
subr_disklabel.c (1.65).
If the block below is put back in subr_disklabel.c the memory overwrite
problem goes away (or at least doesn't happen in GEOM).
My testbox is a single-cpu machine.
Something is screwed somewhere...
Uhh, you mean if the dksort_mtx is put back? What if the function doesn't do
anything, does it still work? Also, what if you just have the static mtx,
maybe the mtx is preventing a buffer overflow from hosing other data?
Poul-Henning
] #ifdef notquite
] /*
] * Mutex to use when delaying niced I/O bound processes in bioqdisksort().
] */
] static struct mtx dksort_mtx;
] static void
] dksort_init(void)
] {
]
] mtx_init(dksort_mtx, dksort, NULL, MTX_DEF);
] }
] SYSINIT(dksort, SI_SUB_DRIVERS, SI_ORDER_MIDDLE, dksort_init, NULL)
] #endif
In message [EMAIL PROTECTED], Poul-Henning
Kamp
writes:
phk 2002/04/23 04:48:45 PDT
Modified files:
sys/geom geom.h geom_dump.c geom_enc.c
geom_slice.c geom_subr.c
Log:
Introduce some serious paranoia to try to catch a memory overwrite problem
as early as possible.
Sponsored by: DARPA NAI Labs
Revision ChangesPath
1.13 +13 -4 src/sys/geom/geom.h
1.7 +1 -0 src/sys/geom/geom_dump.c
1.3 +1 -0 src/sys/geom/geom_enc.c
1.11 +2 -0 src/sys/geom/geom_slice.c
1.8 +46 -2 src/sys/geom/geom_subr.c
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
On Tue, 23 Apr 2002, Dave Hayes wrote: Terry Lambert (who fits my arbitrary definition of a good cynic) writes: It's a hazard of Open Source projects, in general, that there are so many people hacking on whatever they think is cool that nothing ever really gets built to a long term design plan that's stable enough that a book stands a chance of having a 1 year lifetime. I could not help but notice your multiple attempts at expresing this particular concept often, that is...an implied necessity of a book that explains what's going on under the kernel hood. I agree that such a book would rapidly be out of date, but I also see the necessity thereof. So, it's time to question the assumption that the information you want available should be in a book. Many websites have annotation as a form of ad-hoc documentation (e.g. php.net). Why not have someone take a crack at documenting the FreeBSD kernel, and perhaps use some annotation feature to create a living document which (hopefully) comes close to describing the kernel architechture? If you want to track a moving target, perhaps you need to use a moving track? doxygen is *wonderful* for this for large C++ projects: it's able to draw you inheritance graphs and collaboration diagrams, as well as generate pretty, nicely formatted HTML containing API descriptions generated from javadoc-like comments in header files. I've never tried it on straight C. I suppose it is possible, but given the lack of inheritance, collaboration diagrams are going to be very messy. Still and all, it might be a very useful thing. If not doxygen, then perhaps some way to run the headers through jade/sgmlformat, with docbook-style SGML embedded in comments in header files describing kernel API calls and their parameters, with all typedef'd datatypes appropriately cross-linked. As a hack, one could even gulp embed POD within comments and run perldoc on everything. This could be done nightly or twice daily, with updates appearing live at freebsd.org. HTML versions of man pages with crosslinks go part of the way; what I'm thinking about (if any of you have used doxygen you'll know where I'm going) is a bit more comprehensive, with links to the actual header file from which the documentation was generated, so that the reader can see the declaration in its native context (with the doxygen or docbook comments stripped out for clarity). This still wouldn't address the need for some kind of overall architectural document, as well as the difficulty of keeping it up-to-date, but it would be of tremendous help to everyone working on the project. *If* developers can get used to updating the in-comment documentation whenever they make changes, then this reference would automatically be kept up-to-date. -- Chris BeHanna Software Engineer (Remove bogus before responding.) [EMAIL PROTECTED] I was raised by a pack of wild corn dogs. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Heads up: -current sucks today :-)
--- John Baldwin [EMAIL PROTECTED] wrote: I have been seeing a 'witness_get exhausted' message for quite a long time. I have disabled SMP on my kernel as of now, but still have to figure out where and why this message is coming. The witness_get thing was fixed a week or so ago with the lock descriptions added to mtx_init(). Which reminds me!, HITEN, read the cvs-all lists regularly. :-) Thanks for the info. :) -- Hiten __ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildkernel borken
Hi, I dont think the fix I am suggesting is correct, but it worked when I last tried to build my CURRENT kernel (yesterday), and it came out right. Do the following: o Remove the following from src/share/mk/bsd.dep.mk beginning at line 31 as suggested in the error output: %%% .if !target(__bsd.init.mk__) .error bsd.dep.mk cannot be included directly. .endif %%% This bit was added by [EMAIL PROTECTED] in revision 1.33 of : src/share/mk/bsd.dep.mk Regards. -- Hiten --- [EMAIL PROTECTED] wrote: -- Kernel build for SHALMANESER started on Mon Apr 22 17:11:36 CEST 2002 -- === SHALMANESER [...] cd /usr/src/sys/modules ; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/SHALMANESER/modules KMODDIR=/boot/kernel DEBUG=-g DEBUG_FLAGS=-g MACHINE=i386 make cleandir === 3dfx /usr/src/share/mk/bsd.dep.mk, line 31: bsd.dep.mk cannot be included directly. *** Error code 1 __ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make buildworld fails / neqn / grog /groff
I haven't been able to build new world since Apr14 or so. I have cvsupped sources multiple times and buildworld always fails on neqn. If I remove this next it fails on grog and so on. Any good ideas what's wrong? Tomppa c++ -O -pipe -I/f/local/sup/5.0/gnu/usr.bin/groff/src/prproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_MATH_H=1 -DRET_TYPE_SRAND_IS_VOID=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -I/f/local/sup/5.0/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/f/local/sup/5.0/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -D__FBSDID=__RCSID -fno-rtti -fno-exceptions -static -o eqn eqn.o main.o lex.o box.o limit.o list.o over.o text.o script.o mark.o other.o delim.o sqrt.o pile.o special.o /f/local/obj/f/local/sup/5.0/i386/f/local/sup/5.0/gnu/usr.bin/groff/src/preproc/eqn/../../../src/libs/libgroff/libgroff.a make: don't know how to make neqn. Stop *** Error code 2 Stop in /f/local/sup/5.0/gnu/usr.bin/groff/src/preproc. *** Error code 1 Stop in /f/local/sup/5.0/gnu/usr.bin/groff/src. *** Error code 1 Stop in /f/local/sup/5.0/gnu/usr.bin/groff. *** Error code 1 Stop in /f/local/sup/5.0. *** Error code 1 Stop in /f/local/sup/5.0. *** Error code 1 Stop in /f/local/sup/5.0. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make buildworld fails / neqn / grog /groff
On Wed, Apr 24, 2002 at 02:19:29AM +0300, Tomi Vainio - Sun Finland - wrote: I haven't been able to build new world since Apr14 or so. I have cvsupped sources multiple times and buildworld always fails on neqn. If I remove this next it fails on grog and so on. Any good ideas what's wrong? cd /usr/src/usr.bin/make make clean make depend make make install make clean make cleandepend cd /usr/src make buildworld -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make buildworld fails / neqn / grog /groff
Steve Kargl writes: On Wed, Apr 24, 2002 at 02:19:29AM +0300, Tomi Vainio - Sun Finland - wrote: I haven't been able to build new world since Apr14 or so. I have cvsupped sources multiple times and buildworld always fails on neqn. If I remove this next it fails on grog and so on. Any good ideas what's wrong? cd /usr/src/usr.bin/make make clean make depend make make install make clean make cleandepend cd /usr/src make buildworld That was it, thanks! There is nothing about this on UPDATING? What I have missed? Tomppa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make buildworld fails / neqn / grog /groff
On Wed, Apr 24, 2002 at 02:37:45AM +0300, Tomi Vainio - Sun Finland - wrote: Steve Kargl writes: On Wed, Apr 24, 2002 at 02:19:29AM +0300, Tomi Vainio - Sun Finland - wrote: I haven't been able to build new world since Apr14 or so. I have cvsupped sources multiple times and buildworld always fails on neqn. If I remove this next it fails on grog and so on. Any good ideas what's wrong? cd /usr/src/usr.bin/make make clean make depend make make install make clean make cleandepend cd /usr/src make buildworld That was it, thanks! There is nothing about this on UPDATING? What I have missed? src/usr.bin/make/str.c got broken then fixed. Revision 1.19 Sat Apr 13 19:36:47 2002 UTC (10 days, 4 hours ago) by obrien Branch: MAIN Revision 1.17 seems to break a subsequent buildworld (i.e. with the new make installed) in gnu/usr.bin/groff/src/preproc/eqn (which, being a build tool itself, is built with the original make during buildworld). The problem seems to be that in str_concat(), the string is not terminated when the length of the second string is 0. This apparently can happen during null suffix rule processing. Revision 1.17 Sat Apr 13 10:13:39 2002 UTC (10 days, 13 hours ago) by obrien Branch: MAIN Make str_concat handle NULL arguments properly (a-la how ODE-2.3.6 make does). -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: upgrade from 4.5 to current fails
... I also got another shell failure when doing the depend phase of the kernel build, but since I don't care what is in vers.c, and I don't care about the chfoo set of utilities, I cheerfully continued. ... Oops. abenaki# make cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -Werror config.c sh ../../../conf/newvers.sh SIKSIKA *** Signal 12 Again, I honestly don't care what is in vers.c, particularly when it is just comments. So make -i and my machine and I skip over what doesn't actually matter. Eric To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: clist reservation botch
This was from the TrustedBSD MAC branch, but it's not clear to me that this relates to the MAC patches. Have't seen this before; this box is a pxe-booted NFS-mounted system. Kernel and userland may be out of sync, but all modules should be in sync. System is on a serial console. Configuring syscons: blanktimepanic: clist reservation botch cpuid = 1; lapic.id = 0100 Debugger(panic) Stopped at Debugger+0x41: xorl%eax,%eax db trace Debugger(c03de45a) at Debugger+0x41 panic(c03e429f,c0445620,c8e3f200,c8e3f200,c982ab08) at panic+0xd8 cblock_free_cblocks(b,c8e3f200,c982ab28,c0274fd8,c8e3f200) at cblock_free_cblocks+0x29 clist_free_cblocks(c8e3f200,c8e3f238,c8e3f21c,c8e3f200,3) at clist_free_cblocks+0x20 ttyclose(c8e3f200,c8e3f200,1,c98315a0,c939ca48) at ttyclose+0x44 scclose(c049a518,1,2000,c939ca48,c049a518) at scclose+0xd6 spec_close(c982ab94,c982aba8,c02995ec,c982ab94,c93ab03c) at spec_close+0x11a spec_vnoperate(c982ab94,c93ab03c,c93ab03c,c0417ee0,c98315a0) at spec_vnoperate+0x15 vn_close(c98315a0,1,c3f76a00,c939ca48,c982ac08) at vn_close+0x40 vn_closefile(c93ab03c,c939ca48,c93ab03c,c939ca48,0) at vn_closefile+0x1f fdrop_locked(c93ab03c,c939ca48,c049cc00,0,c03daa33) at fdrop_locked+0x12c fdrop(c93ab03c,c939ca48,1,c984b974,8) at fdrop+0x26 closef(c93ab03c,c939ca48) at closef+0xa0 fdfree(c939ca48,c982ad20,c939ca48,c982ad20,c939c948) at fdfree+0x80 exit1(c939ca48,0,c0441740,0,c03db00e) at exit1+0x2af sys_exit(c939ca48,c982ad20,2813c3f8,2805173c,0) at sys_exit+0x2a syscall(2f,2f,2f,0,2805173c) at syscall+0x223 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (1, FreeBSD ELF, sys_exit), eip = 0x280bb48b, esp = 0xbfbffd5c, ebp = 0xbfbffd88 --- db Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: upgrade from 4.5 to current fails
At Tue, 23 Apr 2002 23:55:37 +0200,
Christian Flügel wrote:
Hello Folks.
I currently try to upgrade from 4.5 STABLE to CURRENT.
I have cvsuped my source and already made buildworld and buildkernel.
But installworld failed with Signal 12 while installing chpass.
When I try to remove chpass from hand I get a operation not permitted
error. Apparently the immutable flag prevents the file from being deleted.
Which is strange because the securelevel should be 0 when I'm in single user
mode. So I should be able to change the immutable flag.
From UPDATING:
To upgrade from 4.x-stable to current
-
make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
cp src/sys/${MACHINE_ARCH}/conf/GENERIC.hints /boot/device.hints [2]
make installkernel KERNCONF=YOUR_KERNEL_HERE
reboot in single user [3]
make installworld
mergemaster [4]
[1]
reboot
Did you do this? IIRC, Sig 12 is unimplemented syscall, which would occur
when userland and the kernel are out of sync.
So I booted from my fixit floppy mounted my slices and chrooted to my root
partition. But even then installworld dies with Signal 12 while processing
chpass.
And rm -f chpass will give me an operation not permitted error.
So what is wrong here?
Any Ideas?
Regards
Christian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: upgrade from 4.5 to current fails
On Tue, Apr 23, 2002 at 11:55:37PM +0200, Christian Flügel wrote: Hello Folks. I currently try to upgrade from 4.5 STABLE to CURRENT. I have cvsuped my source and already made buildworld and buildkernel. But installworld failed with Signal 12 while installing chpass. You're attempting to upgrade incorrectly. Follow the directions _precisely_ and this won't happen. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory overwrite problem in the -current kernel ??
On Tue, Apr 23, 2002 at 01:54:17PM +0200, Poul-Henning Kamp wrote: This commit detects a memory overwrite problem in the kernel which happens before we ever get into userland for the first time. Do you know the address being corrupted? If so, try breaking into ddb early on and set a hardware watchpoint. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: upgrade from 4.5 to current fails
I have cvsuped my source and already made buildworld and buildkernel. But installworld failed with Signal 12 while installing chpass. You're attempting to upgrade incorrectly. Follow the directions _precisely_ and this won't happen. I just got bit by this one myself from not following instructions, for the past 2 weeks you didn't have to, you could just upgrade to 5.0 like tracking -stable. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: upgrade from 4.5 to current fails
On Tue, Apr 23, 2002 at 09:09:44PM -0500, David W. Chapman Jr. wrote: I have cvsuped my source and already made buildworld and buildkernel. But installworld failed with Signal 12 while installing chpass. You're attempting to upgrade incorrectly. Follow the directions _precisely_ and this won't happen. I just got bit by this one myself from not following instructions, for the past 2 weeks you didn't have to, you could just upgrade to 5.0 like tracking -stable. No, for the past several months you haven't been able to installworld a -current system under a -stable kernel. That you were ever able to do that before that time is pure chance. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: upgrade from 4.5 to current fails
No, for the past several months you haven't been able to installworld a -current system under a -stable kernel. That you were ever able to do that before that time is pure chance. Very strange that I did it last week then, possibly a fluke? -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: implementing linux mmap2 syscall
Kenneth Culver writes:
OK, I found another problem, here it is:
static void
linux_prepsyscall(struct trapframe *tf, int *args, u_int *code, caddr_t
*params)
{
args[0] = tf-tf_ebx;
args[1] = tf-tf_ecx;
args[2] = tf-tf_edx;
args[3] = tf-tf_esi;
args[4] = tf-tf_edi;
*params = NULL; /* no copyin */
}
Basically, linux_mmap2 takes 6 args, and this looks here like only 5 args are
making it in... I checked this because the sixth argument to linux_mmap2() in
truss was showing 0x6, but when I printed out that arg from the kernel, it
was showing 0x0. Am I correct here?
Ken
Yes. According to http://john.fremlin.de/linux/asm/, linux used to
parse only 5 args but now it parses six. Try adding:
args[5] = tf-tf_ebp;
Drew
OK, I THINK I found what calls the actual kernel syscall handler, and
sets it's args first, but I'm not sure:
from linux_locore.s
NON_GPROF_ENTRY(linux_sigcode)
call*LINUX_SIGF_HANDLER(%esp)
lealLINUX_SIGF_SC(%esp),%ebx/* linux scp */
movlLINUX_SC_GS(%ebx),%gs
movl%esp, %ebx /* pass sigframe */
push%eax/* fake ret addr */
movl$LINUX_SYS_linux_sigreturn,%eax /* linux_sigreturn() */
int $0x80 /* enter kernel with args
*/
0: jmp 0b
ALIGN_TEXT
I think the stuff above copies the args, and whatnot, but I'm not really
sure where it does this exactly...
It calls LINUX_SIGF_HANDLER, which then calls %esp's sf_handler function.
That is where I draw a blank, I don't know which function this is calling,
and can't find where it's being set. I think this might be what I want to
change though. :-P
Does anyone who actually knows assembly have any ideas?
Ken
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Memory overwrite problem in the -current kernel ??
In message [EMAIL PROTECTED], Brian Dean writes: On Tue, Apr 23, 2002 at 01:54:17PM +0200, Poul-Henning Kamp wrote: This commit detects a memory overwrite problem in the kernel which happens before we ever get into userland for the first time. Do you know the address being corrupted? If so, try breaking into ddb early on and set a hardware watchpoint. It was a modified pointer being returned to free(9), it's solved now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
On Mon, 22 Apr 2002, David O'Brien wrote: +if [ -z `hostname -s` ]; then +hostname=`kenv dhcp.host-name` +hostname $hostname +echo Hostname is $hostname +fi If you wanted to match the style for most of the rc* files, and avoid an unecessary call to 'test,' you could do: case `hostname -s` in '') foo ;; esac Not a big deal, but I thought I'd mention it. :) Doug -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
Dave Hayes wrote: So, it's time to question the assumption that the information you want available should be in a book. Many websites have annotation as a form of ad-hoc documentation (e.g. php.net). Why not have someone take a crack at documenting the FreeBSD kernel, and perhaps use some annotation feature to create a living document which (hopefully) comes close to describing the kernel architechture? If you want to track a moving target, perhaps you need to use a moving track? How does the person or persons involved in documenting the internals to sufficient detail to be useful to third parties get paid for the effort? We are talking the work equivalent of a full time job. If they aren't paid, what's the incentive to create documentation above and beyond the status quo? If that incentive exists, what's the URL for the documentation that was created as a result? I think I can count on my fingers the number of people who know the various aspects of the boot process well enough to document it for people who want to hack on it to, for example, declaratively allocate physical memory as part of the boot process. A lot of the information in this thread was never collected centrally anywhere before (e.g. the missing piece about the files to modify and the calculation of the NKPDE value that was left out of David Greenman's posting of a year ago). Most of this information will be quickly out of date, since as soon as you document something, people understand it enough to realize the shortcomings, and so nearly the first thing that happens is the shortcomings are corrected, and voila, your documentation is now out of date. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
Thus spake Vallo Kallaste [EMAIL PROTECTED]: Userspace processes will allocate memory from UVA space and can grow over 1GB of size if needed by swapping. You can certainly have more than one over-1GB process going on at the same time, but swapping will constrain your performance. It isn't a performance constraint. 32-bit architectures have 32-bit pointers, so in the absence of segmentation tricks, a virtual address space can only contain 2^32 = 4G locations. If the kernel gets 3 GB of that, the maximum amount of memory that any individual user process can use is 1 GB. If you had, say, 4 GB of physical memory, a single user process could not use it all. Swap increases the total amount of memory that *all* processes can allocate by pushing some of the pages out of RAM and onto the disk, but it doesn't increase the total amount of memory that a single process can address. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
Thus spake Terry Lambert [EMAIL PROTECTED]: Writing a useful (non-fluff) technical book, optimistically, takes 2080 hours ... or 40 hours per week for 52 weeks... a man year. By the time you are done, the book is a year out of date, and even if you worked really hard and kept it up to date (e.g. you had 4 authors and spent only 6 months of wall time on the book), the shelf life on the book is still pretty short. Although it would be unreasonable to comprehensively document the kernel internals and expect the details to remain valid for a year, there is a great deal of lasting information that could be conveyed. For example, Kirk's 4.[34]BSD books cover obsolete systems, and yet much of what they say applies equally well to recent versions of FreeBSD. It's true that the specific question ``How do I change my KVA size?'' might have different answers at different times, but I doubt that the ideas behind an answer have all been invented in the last few months. Even things like PAE, used by the Linux 2.4 kernel, remind me of how DOS dealt with the 1 MB memory limit. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
