HEADS UP: cvs repository surgery
Some history revisionism has taken place in the src/contrib area as part of making way for the next gcc update. Do not be alarmed when you see your next cvsup output (in cvs mode, not -checkout mode). I am aware of a couple of minor problems, but I dont think they break anything But if something (eg: cvs, cvsup, etc) does break, I need to know about it. cvs or cvsup doing 'fixups' or reporting checksum errors is expected and should only happen once. ie: it should be recovered from automaticaly and NOT happen next time. I only want to know if: - something is corrupted - cvs or cvsup or some other tool crash or report persistant errors - source is corrupted, particularly in RELENG_4. Yes, there are some intentional differences between gcc and gcc.295 etc due to some commits being deliberately left out. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[no subject]
_ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel won't build - atomic.c/atomic.h errors...
On Fri, 2 Nov 2001, Jim Bryant wrote:
> Is anyone else seeing this problem? I posted a message the other day to this list,
>and have yet to see a single response.
>
> This is from a completely fresh cvsup of everything.
>
> buildworld succeeds, but the kernel build fails on atomic.c with the following
>message about the ATOMIC_ASM macros in atomic.h.
>
> The archetecture is 5.0-really-current on an SMP P2-333 machine.
>
> the message seems to be: "inconsistent operand constraints in an `asm'"
Only people who have clobbered -O in CFLAGS in /etc/make.conf should see
this problem :-).
The i386 still uses archaic constraints for some
input-output operands ("0" for the first operand). These never worked
right and if fact don't actually work for compiling this file without
optimization.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: SCSI->IDE
>How do you inform the upper layers that only 10+ byte commands are >allowed? (12 byte in the case of ATAPI). In the long term, this would just be the nature of the exported Protocol Type/Protocol Version and Transport Type/Transport Version passed back in the Path Inquiry response. The peripheral driver will just know that for x protocol, only y commands are allowed. These fields are in the "CAM_NEW_TRAN_CODE" in current. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/release/picobsd/mfs_tree/etc termcap
On Thu, 1 Nov 2001, Luigi Rizzo wrote: > luigi 2001/11/01 08:52:35 PST > > Modified files: > release/picobsd/mfs_tree/etc termcap > Log: > Add entries for "dumb" and "dialup" terminals, as the shell in HEAD > refuses to start if it does not find a matching entry for the terminal > type. > > My impression is that this is a problem in the shell, because > at least on PicoBSD images, the shell itself coredumps. > Anyways, this is the quickest fix i can come up with. This is probably caused by the not so recent breakage of libedit. I now understand why I didn't see as many problems as des for single-user shells: I have /etc/malloc.conf -> aj, and this prevents detection of the breakage. With the default malloc options, "set -E" in /bin/sh always dumps core if $TERM doesn't exist. $TERM never exists for single-user-shells if /usr is a separate filesystem. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: shell coredumps with missing termcap entries ?
On Thu, 1 Nov 2001, Joerg Wunsch wrote: > Luigi Rizzo <[EMAIL PROTECTED]> wrote: > > > I have been experiencing this problem for sometimes on CURRENT-based > > picobsd images: the shell coredumps if it does not find an > > entry for its terminal type in /etc/termcap. > > Seems to be a »feature« of the new libedit. Try this fix. libedit now does more error checking, but doesn't check the error codes properly. It checks too much in term_init() so it doesn't initialize the arrow keys. Then it doesn't check enough in term_init()'s caller[s], so it continues when there is no terminal and soon uses the uninitialized arrow keys. Continuing when there is no terminal is correct and should give builtin defaults for a dumb terminal like it used to. Symptoms of the bug, at least on i386's: if malloc() returns zeroed storage, then the uninitialized arrow keys are sort of initialized (to 0), and the arrow keys just don't work. If malloc() returns the garbage given by the default malloc options, then the uninitialized arrow keys cause a core dump. I still think the correct fix is to back out the libedit changes and start over. Index: term.c === RCS file: /home/ncvs/src/lib/libedit/term.c,v retrieving revision 1.15 diff -u -2 -r1.15 term.c --- term.c 1 Oct 2001 08:41:25 - 1.15 +++ term.c 9 Nov 2001 07:30:51 - @@ -339,7 +339,7 @@ (void) memset(el->el_term.t_val, 0, T_val * sizeof(int)); term_outfile = el->el_outfile; + term_init_arrow(el); if (term_set(el, NULL) == -1) return (-1); - term_init_arrow(el); return (0); } Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
