Re: Building 5.0 on 4.5 Broken in xlint?
On Thu, Mar 21, 2002 at 11:17:18AM +0900, À强ȣ wrote: > Because I'm not a development only a sysadmin, > the next workaround would not fit in your case. :) > > Check out where you already have libc.so.t in /usr/obj/usr/src/lib/libc or > not. > If you have one, copy it into /usr/lib and 'make -DNOCLEAN buildworld' or > 'buildkernel' again. > If you don't, compile only libc.so.5 in /usr/src/lib/libc. It will make > libc.so.5 > in /usr/obj blah,blah, tree... Now you have one... Well, yeah, I could do that, but I really don't want to put a libc.so.5 in the -STABLE system. And I shouldn't be getting that error. -- 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
securelevel_gt used incorrectly in kldload?
The following check added into kern_linker.c seems wrong somehow:
if (securelevel_gt(td->td_ucred, 0) == 0) {
error = EPERM;
goto out;
}
The last thing securelevel_gt does is to perform this check:
return (active_securelevel > level ? EPERM : 0);
i.e. it returns EPERM is securelevel restriction is violated.
Should above construct be rewritten as follows instead?
if ((error = securelevel_gt(td->td_ucred, 0)) != 0)
goto out;
The same bug is present in vfs_mount too.
--
Alexander Kabaev
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Removing CSRG libm?
On Thu, Mar 21, 2002 at 12:33:45PM +1100, Bruce Evans wrote: > On Wed, 20 Mar 2002, Steve Kargl wrote: > > I forgot about the missing __pure2 in . (It prevents gcc > doing optimizations like moving sqrt(2) out of loops.) There is > another thread on freebsd-standards about _MULTI_LIBM support. I I'm not subscribed to freebsd-standards. Too many list, too little time. I guess I'll go browse the archive. > want the errno support completely removed so that we have a chance > of declaring math functions as __pure2 unconditionally. But maybe > we can't do this anyway, because math functions normally have the > side effect of setting IEEE exception flags. Can we do things like > > #ifpragma STDC FENV_ACCESS ON > double sqrt(double); > #else > double sqrt(double) __pure2; > #endif > > ? I don't know. I forgot about the libm PR until last week when someone else posted about paranoi.c failing several tests. I decided to check into the quality of libm and work on improvements. I still have a lot to learn. I think we'll only be able to add __pure2 on a case by case basis. For example, the POSIX sqrt(3) manpage states An application wishing to check for error situations should set errno to zero and call feclearexcept(FE_ALL_EXCEPT) before calling these functions. On return, if errno is non-zero or fetestexcept(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW |FE_UNDERFLOW) is non-zero, an error has occurred. > > > Also, are functions missing in libm with respect to the > > C99 standard? I would be willing to work on implementing > > these functions. > > Most are missing, if you count long double and complex support. Only > a few are, for double support. I noticed some easy ones like > isnormal() when I scanned the C99 draft standard today to check the > status if infnan.3. Garrett pointed me to the Open Group's docs. I didn't know the docs were available on-line. Complex functions are confined to complex.h. I suppose we need to implement complex.h, but I'll probably concentrate on math.h. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Building 5.0 on 4.5 Broken in xlint?
Because I'm not a development only a sysadmin, the next workaround would not fit in your case. :) Check out where you already have libc.so.t in /usr/obj/usr/src/lib/libc or not. If you have one, copy it into /usr/lib and 'make -DNOCLEAN buildworld' or 'buildkernel' again. If you don't, compile only libc.so.5 in /usr/src/lib/libc. It will make libc.so.5 in /usr/obj blah,blah, tree... Now you have one... > -Original Message- > ===> usr.bin/xlint/llib > /c/home/obj/c/home/src/usr.bin/xlint/llib/../xlint/xlint > -cghapbx -L /usr/libdata/lint -Cposix > /c/home/src/usr.bin/xlint/llib/llib-lposix > /c/home/obj/c/home/src/usr.bin/xlint/llib/../xlint/xlint > -cghapbx -L /usr/libdata/lint -Cstdc > /c/home/src/usr.bin/xlint/llib/llib-lstdc > /usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found > /usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found > *** Error code 1 > *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Building 5.0 on 4.5 Broken in xlint?
Looks like the correct lib hints aren't being used in the buildworld? Am I the only one? I'm setting MAKEOBJDIRPREFIX (properly, in the environment). ===> usr.bin/xlint/llib /c/home/obj/c/home/src/usr.bin/xlint/llib/../xlint/xlint -cghapbx -L /usr/libdata/lint -Cposix /c/home/src/usr.bin/xlint/llib/llib-lposix /c/home/obj/c/home/src/usr.bin/xlint/llib/../xlint/xlint -cghapbx -L /usr/libdata/lint -Cstdc /c/home/src/usr.bin/xlint/llib/llib-lstdc /usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found /usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found *** Error code 1 *** Error code 1 2 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error -- 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: Removing CSRG libm?
On Wed, 20 Mar 2002, Steve Kargl wrote: > I re-read the audit trail of the PR. You list two items: > gamma() should become tgamma(); and, (lack of) the use > of __pure2. I was planning to compare our msun against > NetBSD and merge any appropriate changes (if any exists). > Do you have any patches for msun that you might commit > in the future? I created tgamma() from the BSD gamma() and will commit after a repo-copy. The changes are simple, and clean enough except gamma.c needs parts of exp.c and log.c. I forgot about the missing __pure2 in . (It prevents gcc doing optimizations like moving sqrt(2) out of loops.) There is another thread on freebsd-standards about _MULTI_LIBM support. I want the errno support completely removed so that we have a chance of declaring math functions as __pure2 unconditionally. But maybe we can't do this anyway, because math functions normally have the side effect of setting IEEE exception flags. Can we do things like #ifpragma STDC FENV_ACCESS ON double sqrt(double); #else double sqrt(double) __pure2; #endif ? > Also, are functions missing in libm with respect to the > C99 standard? I would be willing to work on implementing > these functions. Most are missing, if you count long double and complex support. Only a few are, for double support. I noticed some easy ones like isnormal() when I scanned the C99 draft standard today to check the status if infnan.3. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86 4.2.0 with G200 fail to start with signal 10
On 20-Mar-2002 (20:29:26/GMT) Will Andrews wrote: >> With last update of world and ports I'm unable to start XFree86. >> I have a matrox G200 (agp) and I have tryed with and without the >> WITH_MATROX_GXX_DRIVER=yes but I got only a signal 10, core dump > What is your pkg_info -Ia? I removed _all_ ports and reinstalled them on 17, 18 and 19 march. > I committed an updated version of the Matrox driver for > XFree86-4-Server, maybe you don't have that? cvsup-ed at 22:45 of 20.03.2002 (GMT+1, italy time). and updated -libraries, -clients and -servers. # ls /var/db/pkg/ | grep XFree86 XFree86-4.2.0_1,1 XFree86-FontServer-4.2.0 XFree86-Server-4.2.0 XFree86-clients-4.2.0_2 XFree86-documents-4.2.0 XFree86-font100dpi-4.2.0 XFree86-font75dpi-4.2.0 XFree86-fontCyrillic-4.2.0 XFree86-fontDefaultBitmaps-4.2.0 XFree86-fontEncodings-4.2.0 XFree86-fontScalable-4.2.0 XFree86-libraries-4.2.0_1 After a lot of test, finally I _found_ it ! I was able to start xdm (not wdm for now) _ONLY_ after killing moused and using /dev/psm0 directly from /etc/X11/XF86Config. This is the message that help me (changing /dev/sysmouse to 666 doesn't help): (EE) Mouse0: Write to mouse failed For wdm maybe something related to PAM, I'm looking deep into archived mail. I can live in the meantime even with xdm :-) X-Server compiled _without_ WITH_MATROX_GXX_DRIVER magic flag. As a little side effect I lost all eight consoles, switching works but with black screen (even num-lock change state and any command seems to 'at least' light on the hd led). If you need any log from /var/log/ feel free to ask me. Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing CSRG libm?
On Thu, Mar 21, 2002 at 10:19:13AM +1100, Bruce Evans wrote: > On Sat, 16 Mar 2002, Steve Kargl wrote: > > > A long time ago I submitted PR misc/17848 which > > removes CSRG libm sources. The audit trail shows > > some commentary, but AFAICT nothing much has been > > done based on that commentary. With the upcoming > > release of of 5.0, I think we should consider the > > removal od CSRG libm and the repo copying of msun > > to libm; otherwise we'll drag CSRG libm around > > until 6.0. > > OK, I will remove libm after repo-copying the interesting parts of it > to libm. I'm not sure about repo-copying msun back to libm. It would > would only create a small mess because they have only one file in > common (the top-level Makefile). In general, repo-copying back can't > be done without creating a large mess, because copying would clobber > all the old history. > Bruce, I re-read the audit trail of the PR. You list two items: gamma() should become tgamma(); and, (lack of) the use of __pure2. I was planning to compare our msun against NetBSD and merge any appropriate changes (if any exists). Do you have any patches for msun that you might commit in the future? Also, are functions missing in libm with respect to the C99 standard? I would be willing to work on implementing these functions. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Good Music "A Beautiful Daye"
"a definite listen to...mellow" - post on audiosurge.com 'the beautiful daye,' the debut album from soul singer and poet tyren [grfx], is the best cool out CD since sade's "lover's rock." The album was created to bring the mood and set the moment, and it does with subtle soundscapes and great melodies. 'the beautiful daye' is must have for serious music collectors, of soul and downtempo music, or lovers of great music. "go out and buy this record?" - rolling out magazine 'the beautiful daye' - best when played between 8pm & 6am available at all fine music stores and amazon.com www.luv4art.com/tyren.htm produced by craig knight and e. Joaquin of saturn return; tme pro; aztek & dj prosecutor; and scars for hardboiled entertainment. info: [EMAIL PROTECTED] underground artworks entertainment To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing CSRG libm?
On Sat, 16 Mar 2002, Steve Kargl wrote: > A long time ago I submitted PR misc/17848 which > removes CSRG libm sources. The audit trail shows > some commentary, but AFAICT nothing much has been > done based on that commentary. With the upcoming > release of of 5.0, I think we should consider the > removal od CSRG libm and the repo copying of msun > to libm; otherwise we'll drag CSRG libm around > until 6.0. OK, I will remove libm after repo-copying the interesting parts of it to libm. I'm not sure about repo-copying msun back to libm. It would would only create a small mess because they have only one file in common (the top-level Makefile). In general, repo-copying back can't be done without creating a large mess, because copying would clobber all the old history. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: i386/boot2.c patches
Le 2002-03-20, John Baldwin écrivait : > Looks mostly ok to me. Not entirely sure about the autoboot changes > as it looks weird to load(kname) right before you change what kname > is. I think the logic must somehow be wrong there. But this is what is currently in the code (as I mentioned in the PR, 36015 is strictly a code clarification, with no functional change). The load() function in boot2 ends with an exec() of the loaded binary. It returns only if it has failed. The purpose of replacing kname after load() has returned is to try to load /boot/kernel if we have failed to load /boot/loader. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/usr.bin/xinstall xinstall.c
On Wed, 20 Mar 2002, Ruslan Ermilov wrote:
> On Mon, Mar 18, 2002 at 03:26:13PM -0800, Dag-Erling Smorgrav wrote:
> > des 2002/03/18 15:26:13 PST
> >
> > Modified files:
> > usr.bin/xinstall xinstall.c
> > Log:
> > Bump the cutoff mark for comparing files from 8 MB to 16 MB.
> >
> > Revision ChangesPath
> > 1.48 +3 -1 src/usr.bin/xinstall/xinstall.c
> >
> OK, I think it's finally the time to borrow mmap(2) comparison in
> chunks from OpenBSD (better viewed as -w diff):
Using mmap(2) at all is over-engineered IMO. Does it make even 1 1%
difference for heavy uses like installworld? I get the following times
on an Athlon1600 for installing an 8MB file 16 times after it has
already been installed and caches warmed up:
install -C:0.48 real 0.38 user 0.09 sys
install -MC: 0.86 real 0.26 user 0.59 sys
and for installing a copy of /usr/bin/*:
install -C:0.29 real 0.24 user 0.04 sys
install -MC: 0.54 real 0.10 user 0.42 sys
Using mmap(2) in cmp(1) makes more difference because the non-mmap
case of cmp(1) is poorly implemented. cmp(1) uses a getc() loop, but
install(1) reads MAXBSIZE at a time).
> %%%
> Index: xinstall.c
> ===
> RCS file: /home/ncvs/src/usr.bin/xinstall/xinstall.c,v
> retrieving revision 1.48
> diff -u -p -r1.48 xinstall.c
> --- xinstall.c18 Mar 2002 23:26:13 - 1.48
> +++ xinstall.c20 Mar 2002 09:26:11 -
> @@ -74,12 +74,11 @@ static const char sccsid[] = "From: @(#)
> ...
> +out:
> + if (!done_compare && from_len <= MAX_CMP_SIZE) {
> + char buf1[MAXBSIZE];
> + char buf2[MAXBSIZE];
> + int n1, n2;
This is cleaner than before, but still has style bugs (nested declarations),
and still attempts to pessimize the !mmap case by using misaligned buffers
(copy() is missing the style bugs but not the misaligment attempt).
> ...
> } else
> rv = 1; /* don't bother in this case */
We should bother now, to give the documented semantics for -C (remove the
"from_len <= MAX_CMP_SIZE" check above).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
UFS2, GEOM & DARPA - don't get all excited, OK ?
--- Begin Message --- Ok, Kirk and I thought it would stirr a buzz once we even mentioned "UFS2" so let me set the record straight, (or at least firmly crooked): UFS2 is UFS Extended Attributes in the inodes. That's it. No more, no less. In particular that means: No journaling. No Btree-directories, no in-directory inodes. Because we need to increase the size of the inode we chose to "run a revision" and call it UFS2, and obviously, we will make sure all relevant fields get the space they need, or at reserve space for their growth as part of this. Specifically inode numbers, block numbers and time_t will have 64 bit available. We may attempt a couple of neat tricks at the same time: per inode blocksize and lazy inode initializtion. The former might improve I/O performance down the road, the latter speed up newfs and fsck. We will try to avoid forking sys/ufs/ufs if we can, we may have to push some stuff from ufs to ffs to make that happen. In practice this also means a sweep through all the userland stuff to make it work with UFS2: newfs, fsck, tunefs, quotactl, sysinstall etc (that's largely going to be my problem). Incidently there is a not insignificant crossover between UFS and disklabels and from there into GEOM, so some of the things I will be doing in that corner will be hard to attribute only to one or the other of these two DARPA funded projects. The one thing we RSN will cry to have is endian/wordsize agnostic UFS. That is not part of the DARPA project description and it is unlikely to "sneak" into it. We have it in mind though. (The NETBSD work is not uninteresting, but both Kirk and I feel that there might be a better and even more general solution.) And this is yet a problem with significant crossover to the issues I have in GEOM with reading labeling data structures of disks in alien formats so some of the technology I plan for GEOM might be applicable to UFS as well. Finally, If you are in the US and you think it is a good thing that DARPA sponsors stuff like this, don't forget to say so to people who might, directly or indirectly, provide feedback to DARPA. I hope this answers the FAQ on UFS2, GEOM and all that. -- 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. --- End Message ---
Re: XFree86 4.2.0 with G200 fail to start with signal 10
On Wed, Mar 20, 2002 at 11:29:46AM +0100, Riccardo Torrini wrote: > With last update of world and ports I'm unable to start XFree86. > I have a matrox G200 (agp) and I have tryed with and without the > WITH_MATROX_GXX_DRIVER=yes but I got only a signal 10, core dump > when starting X. At the same time I switched my MoBo from tyan > trinity with k6 to a asus p2b-ds dual processor p3/500. > I have a recent system (fresh compile with SMP enabled): What is your pkg_info -Ia? I committed an updated version of the Matrox driver for XFree86-4-Server, maybe you don't have that? BTW, it's not very well tested and I certainly can't test it myself w/o Matrox hardware. Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/usr.bin/xinstall xinstall.c
Ruslan Ermilov <[EMAIL PROTECTED]> writes: > OK, I think it's finally the time to borrow mmap(2) comparison in > chunks from OpenBSD (better viewed as -w diff): What are you waiting for? Commit! :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rtld messing up?
> > In ports/lang/gcl, a program is "undumped", and the resultant binary > > dumps core _very_ early in the startup. I can't get debugging info, > > because the undumping also seems to strip the program. > > I've also have had that same problem when I tried to build the port, > but was never able to find the reason for the program to segfault, I > even opened a PR on that. The program seems to work on NetBSD btw.=20 PR ports/34661 :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: i386/boot2.c patches
On 20-Mar-2002 Pierre Beyssac wrote: > Would anyone mind if I commit the following to i386/boot2.c? > I've reviewed and tested them. > > add -n option to boot2 to disallow user interruption > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=36016 Looks fine to me. > boot2 cleanup (modulo style(9) and a minor typo in a comment): > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=36015 Looks mostly ok to me. Not entirely sure about the autoboot changes as it looks weird to load(kname) right before you change what kname is. I think the logic must somehow be wrong there. Might want to ask Robert Nordier for review. -- 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: more -current testers
> In my environment, I have a central build and file server, and then a > series of network booted crash machines. Hey, this is interesting. I planed to buy a serial terminal or simple pc which plays terminal for quite a long time, but delayed that until I will have moved to the new appartment, where my wife won't kill me for adding "another ugly pc" :-) That original scenario would mean I would use the second terminal box as work station to monitor and operate the main box. This network scenario reverses roles: the existing comfortable box would stay work station and used to inspect bare network boxes that just feature cpu, ram, and ethernet. A cheap solution and they could be hidden in the closet. > It's possible to replace the kernel out from under a machine while still > crashing/dumping/rebooting. This can dramatically reduce the > develop/compile/install/test/crash/repeat cycle by coallescing the test > and crash bits with the other bits, since you can compile while still > testing or crashing. Thats sounds interesting. > Occasional PXE bugs can be very frustrating. Some machines I've used have > no problem loading pxeboot from a different machine than the DHCP server. > A couple of others ignore the server specification in the DHCP response > and insist on trying to tftp pxeboot from the DHCP server. Did you do a write up of your experiences? Regards, Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rtld messing up?
On Wed, Mar 20, 2002 at 05:47:32PM +, Mark Murray wrote: > In ports/lang/gcl, a program is "undumped", and the resultant binary > dumps core _very_ early in the startup. I can't get debugging info, > because the undumping also seems to strip the program. I've also have had that same problem when I tried to build the port, but was never able to find the reason for the program to segfault, I even opened a PR on that. The program seems to work on NetBSD btw. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! msg36393/pgp0.pgp Description: PGP signature
Re: rtld messing up?
> > Technically, the ELF spec permits the ordering, so the assumptions > > are really "broken", even though they code for what's really a > > defacto-standard of many years, now. 8-(. > > Can you be more specific? To the best of my knowledge, I made no > assumptions beyond what the spec promised. The only exception is that > the dynamic linker relies on the program header being in the first > page of the file, an assumption shared by the kernel as well. I don't > think that assumption is wrong, or nothing would run at all. I'm going to sound like a prat here, mostly because I don't know what I'm talking about. :-) In ports/lang/gcl, a program is "undumped", and the resultant binary dumps core _very_ early in the startup. I can't get debugging info, because the undumping also seems to strip the program. Could you please try that port, and see what you can glean? I'm frobbing around in xemacs, which works, to see if I can't fix undump. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rtld messing up?
In article <[EMAIL PROTECTED]>, Terry Lambert <[EMAIL PROTECTED]> wrote: > John Polstra wrote: > > All I know is this: The dynamic linker was working just fine for > > years. Then we got a new version of binutils, and lots of problems > > started happening. The dynamic linker wasn't changed -- binutils > > was. I have no idea what got broken, but I kind of doubt that the > > bug is in the dynamic linker. > > The new binutils screws over some basic long-standing assumptions > about field ordering and associativity in the object files, which > are no longer maintained (for whatever reason) in the new version > of the tools. > > Some of them have been identified and repaired (e.g. the Alpha > code changes for the section/segment order assumption), but it > is going to probably be a long battle. > > Technically, the ELF spec permits the ordering, so the assumptions > are really "broken", even though they code for what's really a > defacto-standard of many years, now. 8-(. Can you be more specific? To the best of my knowledge, I made no assumptions beyond what the spec promised. The only exception is that the dynamic linker relies on the program header being in the first page of the file, an assumption shared by the kernel as well. I don't think that assumption is wrong, or nothing would run at all. John -- John Polstra John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
i386/boot2.c patches
Would anyone mind if I commit the following to i386/boot2.c? I've reviewed and tested them. add -n option to boot2 to disallow user interruption http://www.FreeBSD.org/cgi/query-pr.cgi?pr=36016 boot2 cleanup (modulo style(9) and a minor typo in a comment): http://www.FreeBSD.org/cgi/query-pr.cgi?pr=36015 -- Pierre Beyssac [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Unexpected Soft Update Inconsistency"
On Wed, Mar 20, 2002 at 07:20:52AM +0100, Poul-Henning Kamp wrote: > > Sounds like your disklabel is smaller than your filesystem ? Huh. That's what it looks like. "How'd that happen?"(tm) I don't recall ever touching the disklabel since the install. Oh, well. There was enough spare room on the disk to do a bare-bones OS install on an open slice, backed up the bad filesystem and the others on the slice, repartitioned the slice a little better now that I have a feel for how the system will be used, newfs'ed all of the partitions, and restored. > In message <[EMAIL PROTECTED]>, "Crist J. Clark" writes > : > >I've got a -CURRENT system that is seriously resisting attempts to > >revive it. No matter how many times I run fsck(8), it tells me, > > > >** /dev/ad0s1a > >** Last Mounted on / > >** Root file system > >** Phase 1 - Check Blocks and Sizes > > > >CANNOT READ BLK: 8407744 > >UNEXPECTED SOFT UPDATE INCONSISTENCY > > > >CONTINUE? yes > > > >THE FOLLOWING DISK SECTORS COULD NOT BE READ: 8407744, 8407745, 8407746, 8407747, >8407748, 8407749, 8407750, 8407751, 8407752, 8407753, 8407754, 8407755, 8407756, >8407757, 8407758, 8407759, > >** Phase 2 - Check Pathnames > >** Phase 3 - Check Connectivity > >** Phase 4 - Check Reference Counts > >** Phase 5 - Check Cyl groups > >133720 files, 1429523 used, 2651122 free (34074 frags, 327131 blocks, 0.8% >fragmentation) > > > >* FILE SYSTEM STILL DIRTY * > > > >* PLEASE RERUN FSCK * > > > >There are no reports of hard errors, so I believe this is purely a > >"soft" error. Any advice on how to fix? > >-- > >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 > > > > -- > 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. -- 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
XFree86 4.2.0 with G200 fail to start with signal 10
With last update of world and ports I'm unable to start XFree86. I have a matrox G200 (agp) and I have tryed with and without the WITH_MATROX_GXX_DRIVER=yes but I got only a signal 10, core dump when starting X. At the same time I switched my MoBo from tyan trinity with k6 to a asus p2b-ds dual processor p3/500. I have a recent system (fresh compile with SMP enabled): # uname -v FreeBSD 5.0-CURRENT #24: Sun Mar 17 00:32:04 CET 2002 and I double check all update cycle (make update, buildworld, buildkernel, installkernel, installworld, mergemaster, reboot) I removed also _all_ ports and reinstalled them. Also tryed to recreate a config for XFree from screatch but it crash always with signal 10 (and sometimes with signal 6). At this time I am not sure where is (can be?) the problem, mobo, graphic card, -current or xfree. Any hint? TIA, Riccardo. PS: My previous message with ACPI info get lost, neither bounced nor accepted. And I am using correct local masquerading and my ISP that has record for reverse resolution also. Spam from .kr instead is accepted to list. Exists any other method for _serious_ user/tester to send to list? Thanks again. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[no subject]
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cdrecord for ATAPI burners available..
It seems Thomas Quinot wrote: > Le 2002-03-20, Søren Schmidt écrivait : > > > I thought there was work on this already ? Justin called for a timeout > > to get it done "the right way" in CAM, I was sort of expecting to > > hear about how that should integrate in the ATA/ATAPI world... > > Well I have not heard of any specific requirements on that matter. Me neither, maybe somebody should ping Justin on this.. > > However, I will maintain the ATA/ATAPI only cd/fd/tape drivers as I have > > a use for them, be it in the official sources or locally, that all depends > > on how the cake is to be cut... > > Currently, the ATAPI/CAM patches can coexist peacefully with acd/ast/afd, > and it is my intention to keep it that way. :) Well, since Justin is MrCAM I think we should at least wait for him to comment on this before spending too much work on it to find that it should be done differently. And yes, I'm all for coexistance as I've stated several times... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cdrecord for ATAPI burners available..
It seems Scott Long wrote: > In the past you've objected to ATAPI-CAM on two grounds, fear that it > won't be done right, and fear that it will add more work to yourself. I > think that there are enough highly intelligent people interested in the > project that the first issue can be put to rest. While I highly respect > what you have done with this port, I think that you are eroding your > defense of the second issue. I fail to see how porting (and presumably > maintaining) a multitude of CD utilities will be less work for you than > allowing someone to put a CAM hook into your acd driver, and then > sitting back as they maintain that work. I released these mods (which was actually done over a year ago on a contract, but I couldnt release them until now) just so people experiencing problems could try that route. This could reveal the problems that some has with burncd, and which I would like to get fixed, even if the 'pure' ATAPI driver suite is to be replaced with CAM (I have a use for it at least without CAM).. I was trying to be helpfull here, so please take a deep breath before accusing me of anything else.. > If you object to ATAPI-CAM, just come out and and admit it. This isn't > a battle of egos of wills, and nobody is trying to discredit your work. > You are a valuable member of the FreeBSD community, and everybody > appreciates the work that you have put it. ATAPI-CAM is not meant to > replace you, since we still need your expertise in every other part of > the ATA/ATAPI/IDE framework. It is meant to help users who want a > simple way to do cool stuff with their ATAPI devices. I have said repeatedly on these lists, that I have no problem with CAM as long as the integration is done in a sensible way, and that I am not the one to maintain the CAM translation layer. I was under the impression that Justin was working with you guys on how to do this right from the CAM perspective, at least that was the way I interpreted his mail to this list. I'm not the one slowing things down here, so please point your flak in another direction :) However, the 'pure' ATAPI drivers will continue to live since I have uses for it, if its not to be in the official sources, thats something I'll have to consider how to handle then... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cdrecord for ATAPI burners available..
Le 2002-03-20, Søren Schmidt écrivait : > I thought there was work on this already ? Justin called for a timeout > to get it done "the right way" in CAM, I was sort of expecting to > hear about how that should integrate in the ATA/ATAPI world... Well I have not heard of any specific requirements on that matter. > However, I will maintain the ATA/ATAPI only cd/fd/tape drivers as I have > a use for them, be it in the official sources or locally, that all depends > on how the cake is to be cut... Currently, the ATAPI/CAM patches can coexist peacefully with acd/ast/afd, and it is my intention to keep it that way. :) Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/usr.bin/xinstall xinstall.c
On Mon, Mar 18, 2002 at 03:26:13PM -0800, Dag-Erling Smorgrav wrote:
> des 2002/03/18 15:26:13 PST
>
> Modified files:
> usr.bin/xinstall xinstall.c
> Log:
> Bump the cutoff mark for comparing files from 8 MB to 16 MB.
>
> Revision ChangesPath
> 1.48 +3 -1 src/usr.bin/xinstall/xinstall.c
>
OK, I think it's finally the time to borrow mmap(2) comparison in
chunks from OpenBSD (better viewed as -w diff):
%%%
Index: xinstall.c
===
RCS file: /home/ncvs/src/usr.bin/xinstall/xinstall.c,v
retrieving revision 1.48
diff -u -p -r1.48 xinstall.c
--- xinstall.c 18 Mar 2002 23:26:13 - 1.48
+++ xinstall.c 20 Mar 2002 09:26:11 -
@@ -74,12 +74,11 @@ static const char sccsid[] = "From: @(#)
#define MAP_FAILED ((void *)-1)/* from */
#endif
-#define MAX_CMP_SIZE (16 * 1024 * 1024)
-
#defineDIRECTORY 0x01/* Tell install it's a directory. */
#defineSETFLAGS0x02/* Tell install to set flags. */
#defineNOCHANGEBITS(UF_IMMUTABLE | UF_APPEND | SF_IMMUTABLE | SF_APPEND)
#defineBACKUP_SUFFIX ".old"
+#defineMAX_CMP_SIZE(16 * 1024 * 1024)
struct passwd *pp;
struct group *gp;
@@ -523,6 +522,8 @@ compare(int from_fd, const char *from_na
int to_fd, const char *to_name __unused, size_t to_len)
{
char *p, *q;
+ size_t len, remainder;
+ off_t from_off, to_off;
int rv;
int done_compare;
@@ -530,48 +531,60 @@ compare(int from_fd, const char *from_na
if (from_len != to_len)
return 1;
- if (from_len <= MAX_CMP_SIZE) {
- done_compare = 0;
- if (trymmap(from_fd) && trymmap(to_fd)) {
- p = mmap(NULL, from_len, PROT_READ, MAP_SHARED, from_fd,
(off_t)0);
+ done_compare = 0;
+ if (trymmap(from_fd) && trymmap(to_fd)) {
+ /*
+* Compare two files being careful not to mmap
+* more than 8M at a time.
+*/
+ from_off = to_off = (off_t)0;
+ remainder = from_len;
+ while (!rv && remainder > 0) {
+ len = MIN(remainder, 8 * 1024 * 1024);
+
+ p = mmap(NULL, len, PROT_READ, MAP_SHARED, from_fd, from_off);
if (p == (char *)MAP_FAILED)
goto out;
- q = mmap(NULL, from_len, PROT_READ, MAP_SHARED, to_fd,
(off_t)0);
+ q = mmap(NULL, len, PROT_READ, MAP_SHARED, to_fd, to_off);
if (q == (char *)MAP_FAILED) {
- munmap(p, from_len);
+ munmap(p, len);
goto out;
}
- rv = memcmp(p, q, from_len);
- munmap(p, from_len);
- munmap(q, from_len);
- done_compare = 1;
- }
- out:
- if (!done_compare) {
- char buf1[MAXBSIZE];
- char buf2[MAXBSIZE];
- int n1, n2;
-
- rv = 0;
- lseek(from_fd, 0, SEEK_SET);
- lseek(to_fd, 0, SEEK_SET);
- while (rv == 0) {
- n1 = read(from_fd, buf1, sizeof(buf1));
- if (n1 == 0)
- break; /* EOF */
- else if (n1 > 0) {
- n2 = read(to_fd, buf2, n1);
- if (n2 == n1)
- rv = memcmp(buf1, buf2, n1);
- else
- rv = 1; /* out of sync */
- } else
- rv = 1; /* read failure */
- }
- lseek(from_fd, 0, SEEK_SET);
- lseek(to_fd, 0, SEEK_SET);
+ rv = memcmp(p, q, len);
+ munmap(p, len);
+ munmap(q, len);
+
+ from_off += len;
+ to_off += len;
+ remainder -= len;
+ }
+ done_compare = 1;
+ }
+out:
+ if (!done_compare && from_len <= MAX_CMP_SIZE) {
+ char buf1[MAXBSIZE];
+ char buf2[MAXBSIZE];
+ int n1, n2;
+
+ rv = 0;
+ lseek(from_fd, 0, SEEK_SET);
+ lseek(to_fd, 0, SEEK_SET);
+ while (rv == 0) {
+ n1 = read(from_fd, buf1, sizeof(buf1));
+ if (n1 == 0)
+
Re: cdrecord for ATAPI burners available..
It seems Thomas Quinot wrote: > Le 2002-03-19, Søren Schmidt écrivait : > > > > gmake[1]: *** [TocParser.o] Error 1 > > You need to have pccts installed to compile cdrdao > > I do, and as I mentioned in my first message, the compileation completed > after a gmake distclean. okies... > > > These utils are ATA only (as the name implies), if our ports people > > wants to merge it into whats already there I wont complain :) > > That said I think the ATA only version covers more than a significant > > percentage of our userbase > > > > In which case I'll be more than happy to continue maintaining ATAPI/CAM > as an alternative solution, which addresses 100% of our user base and > does not impose any additional work upon application authors or port > maintainers. I thought there was work on this already ? Justin called for a timeout to get it done "the right way" in CAM, I was sort of expecting to hear about how that should integrate in the ATA/ATAPI world... However, I will maintain the ATA/ATAPI only cd/fd/tape drivers as I have a use for them, be it in the official sources or locally, that all depends on how the cake is to be cut... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
