ffs changes 4.8-PR2 -> 5.0?
Hi all, I have a box with a stable 4.8-PRERELEASE and a -current from a few weeks ago. The root fs on -current is a UFS1. When I do fsck inside the stable system for the -current root, everything is fine except "summary information bad". (The same happens when I mount the -stable root from the -current system and run the old fsck binary) However, for the 5.0 fsck the filesystem is completely ok (I did boot -s and fsck on the ro-mounted filesystem). Did some minor changes happen on UFS1 in the meantime or did we break something? Cheers Thomas Stratmann To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
how to burn R/cdrom/disc1
Hello (BI run make release on -current (BI got /junk/release/R/cdrom/disc1 and disc2 (BSo I run "mkisofs -U -R -b floppies/boot.flp -o cd.iso disc1" (BAnd make cd-rom (BBut can't install from cdrom (BPlease help me how to make hard-disk-boot CD image with mkisofs (B (BThank you (B (B (BTo Unsubscribe: send mail to [EMAIL PROTECTED] (Bwith "unsubscribe freebsd-current" in the body of the message
Re: Gnome2 terminal will not work right -- SOLVED
Joe Marcus Clarke wrote: On Sat, 2003-03-08 at 19:39, Tom Parquette wrote: What changed between the last known working date and tonight? Joe, Nothing that I know of. I did a make buildworld/buildkernel on this machine that was NFS mounted on another but I have not installed it on this machine yet. I was fighting with portupgrade to get the database consistant but I do not believe it went into Gnome-land. The problem simply appeared after I had left the Gnome2 session open overnight and picked it up sometime the next day. The interference dump is from xscreensaver. You don't need to worry with that. You can disab;e that module in the xscreensaver capplet if you want. I noticed that you don't have the vte port installed. Perhaps your gnometerminal is using an old version of the library that was left around on the system. You might try updating to vte-0.10.26, and see if that helps. If it doesn't, you can always try rebuilding gnometerminal with -DWITH_ZVT to enable the old terminal widget component. This will break I18N and anti-aliasing for the terminal, but you shouldn't see the problem you're seeing anymore. Joe Joe, I just finished rebuilding gnometerminal. I had to install vte and some other toolkit that I didn't write down. Rebuilding, make deinstall and make reinstall appears to have fixed the problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Gnome2 terminal will not work right
On Sat, 2003-03-08 at 19:39, Tom Parquette wrote: > >What changed between the last known working date and tonight? > > > > > Joe, Nothing that I know of. I did a make buildworld/buildkernel on > this machine that was NFS mounted on another but I have not installed it > on this machine yet. I was fighting with portupgrade to get the > database consistant but I do not believe it went into Gnome-land. The > problem simply appeared after I had left the Gnome2 session open > overnight and picked it up sometime the next day. > The interference dump is from xscreensaver. You don't need to worry with that. You can disab;e that module in the xscreensaver capplet if you want. I noticed that you don't have the vte port installed. Perhaps your gnometerminal is using an old version of the library that was left around on the system. You might try updating to vte-0.10.26, and see if that helps. If it doesn't, you can always try rebuilding gnometerminal with -DWITH_ZVT to enable the old terminal widget component. This will break I18N and anti-aliasing for the terminal, but you shouldn't see the problem you're seeing anymore. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
Re: Gnome2 terminal will not work right
What do you have in your ~/.xinitrc? Can you also send the output of pkg_info? Also, have you tried removing ~/.gnome2/session, and see if that helps? Joe Joe, I just tried removing the session file. Nothing changed. Someone suggested rebuilding gnometerminal. I may try that since it seems like a harmless road to go down. Cheers... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Gnome2 terminal will not work right
Joe Marcus Clarke wrote: On Sat, 2003-03-08 at 00:15, Tom Parquette wrote: People have been saying that 5.0-CURRENT problems belong here. I don't know if this is Gnome2 or Xfree86... Both work fine for me in -CURRENT. I noticed tonight that the Gnome2 desktop terminal stopped working. What changed between the last known working date and tonight? Joe, Nothing that I know of. I did a make buildworld/buildkernel on this machine that was NFS mounted on another but I have not installed it on this machine yet. I was fighting with portupgrade to get the database consistant but I do not believe it went into Gnome-land. The problem simply appeared after I had left the Gnome2 session open overnight and picked it up sometime the next day. The X logs are inconclusive. However, I'll include one that hints at a failure. "Fatal server error: xf86OpenConsole: VT_SETMODE VT_PROCESS failed" I've had this happen to root and to my non uid0 personal account. Any ideas folks? What do you have in your ~/.xinitrc? Can you also send the output of pkg_info? Also, have you tried removing ~/.gnome2/session, and see if that helps? Joe There is no .xinitrc for this user id. I use GDM2 and that path brought up Gnome2. I noticed it but, I never questioned it beyond that. I have not tried removing .gnome2/session. I can try that. I'll attach pkg_info to the end of this reply. I do not know what the importance of this is but I keep seeing dumps for something called Interfearance. I do not know what it is or what it does. I also have not gotten around to researching what it is. I mention it here FWIW. __ XFree86 Version 4.2.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 3 September 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: FreeBSD 5.0-CURRENT i386 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.1.log", Time: Fri Mar 7 17:49:40 2003 (==) Using config file: "/etc/X11/XF86Config" (==) ServerLayout "XFree86 Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (==) Keyboard: CustomKeycode disabled (**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (**) ModulePath set to "/usr/X11R6/lib/modules" (--) Using syscons driver with X support (version 2.0) (++) using VT number 9 Fatal server error: xf86OpenConsole: VT_SETMODE VT_PROCESS failed When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file "/var/log/XFree86.1.log". Please report problems to [EMAIL PROTECTED] 44bsd-csh-20001106 The traditional 4.4BSD /bin/csh C-shell 9e-1.0 Explode Plan9 archives AbiWord2-1.1.3 An open-source, cross-platform WYSIWYG word processor Hermes-1.3.2Fast pixel formats conversion library ImageMagick-5.5.5 Image processing tools (interactive optional--misc/display Mesa-3.4.2_2A graphics library similar to SGI's OpenGL ORBit-0.5.17High-performance CORBA ORB with support for the C language ORBit2-2.6.0High-performance CORBA ORB with support for the C language OpenSSH-askpass-1.2.2.2001.02.24 Graphical password applet for entering SSH passphrase XFree86-4.2.0_1,1 X11/XFree86 core distribution (complete, using mini/meta-po XFree86-FontServer-4.2.0_1 XFree86-4 Font Server XFree86-Server-4.2.1_7 XFree86-4 X server and related programs XFree86-VirtualFramebufferServer-4.2.1_1 XFree86-4 Virtual Framebuffer Server XFree86-clients-4.2.1_3 XFree86-4 Client environments XFree86-documents-4.2.0 XFree86-4 Document Files XFree86-font100dpi-4.2.0 XFree86-4 bitmap 100 dpi fonts XFree86-font75dpi-4.2.0 XFree86-4 bitmap 75 dpi fonts XFree86-fontCyrillic-4.2.0_4 XFree86-4 Cyrillic Fonts XFree86-fontDefaultBitmaps-4.2.0 XFree86-4 default bitmap fonts XFree86-fontEncodings-4.2.0 XFree86-4 font encoding files XFree86-fontScalable-4.2.0 XFree86-4 Scalable font files XFree86-libraries-4.2.1_7 XFree86-4 include/(shared) library kit Xaw3d-1.5 A 3-D Athena Widget set that looks like Motif Xft-2.1_3 A client-sided font API for X applications aalib-1.4.r5_1 An ascii art library acme-2.0.2 Tool to make multimedia keys work on laptops acroread-5.06_1 View, distribute and print PDF documents af-kde-i18n-3.1 Localiz
Re: Gnome2 terminal will not work right
On Sat, 08 Mar 2003 09:00:36 -0800 Lars Eggert <[EMAIL PROTECTED]> wrote: > On 3/7/2003 11:50 PM, Marcel Moolenaar wrote: > > On Fri, Mar 07, 2003 at 11:30:34PM -0800, Lars Eggert wrote: > >> > >>this may be unrelated, but for about ten days or so, I have problems > >>where gnometerminal will stop updating after a while. I can still use > >>the menus, close it, etc. - but all output is suspended. Most of the > >>time, selecting "Reset" from the menu repeatedly will eventually get me > >>back to a working state again. It also seems that pasting multi-line > >>text into a gnometerminal (as opposed to typing or it displaying output) > >>will trigger this frequently. > > > > Me too > > > > I tend to think it happens more often with maximized windows than > > not and also when long lines are involved. A reset most of the time > > gets me back, but I do occasionally have to kill gnome-terminal > > completely when all the terminals are dead. Unfortunately I don't > > have the time to dig into it, but I'm probably going to switch > > window manager and see if that makes a difference. For some reason > > I'm suspicious about Metacity. Not necessarily because of this... > > I also switched to a TrueType font for gnometerminals (bitstream-vera) > around the same time, so maybe that's a factor, too. > > As for window managers, I use sawfish (and have been, for a long time > before the problem.) > > Also (unrelated?), it seems that X eats up a LOT of CPU with antialiases > TrueType fonts in terminals, compared to good, old lucida-typewriter. "Fatal server error: xf86OpenConsole: VT_SETMODE VT_PROCESS failed" You could try rebuilding gnometerminal and use the 'WITH_ZVT' option. This is a workaround for some gnometerminal funkyness that was discussed in the freebsd-gnome list. Font functions are lost, but speed, resource usage, and highlighting for copy/paste is improved. Regards, Stephen Hilton [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NULL pointer problem in pid selection ?
On Sat, Mar 08, 2003 at 11:46:34AM +0100, Poul-Henning Kamp wrote:
>
> Just got this crash on -current, and I belive I have seen similar
> before. addr2line(1) reports the faulting address to be
> ../../../kern/kern_fork.c:395
> which is in the inner loop of pid collision avoidance.
I've been running this patch from Alfred for the past month or so on
bento, which has fixed a similar panic I was seeing regularly.
Kris
Index: kern/kern_fork.c
===
RCS file: /home/ncvs/src/sys/kern/kern_fork.c,v
retrieving revision 1.186
diff -u -r1.186 kern_fork.c
--- kern/kern_fork.c27 Feb 2003 02:05:17 - 1.186
+++ kern/kern_fork.c4 Mar 2003 00:28:09 -
@@ -325,6 +325,7 @@
* exceed the limit. The variable nprocs is the current number of
* processes, maxproc is the limit.
*/
+ sx_xlock(&proctree_lock);
sx_xlock(&allproc_lock);
uid = td->td_ucred->cr_ruid;
if ((nprocs >= maxproc - 10 && uid != 0) || nprocs >= maxproc) {
@@ -432,6 +433,7 @@
LIST_INSERT_HEAD(&allproc, p2, p_list);
LIST_INSERT_HEAD(PIDHASH(p2->p_pid), p2, p_hash);
sx_xunlock(&allproc_lock);
+ sx_xunlock(&proctree_lock);
/*
* Malloc things while we don't hold any locks.
@@ -757,6 +759,7 @@
return (0);
fail:
sx_xunlock(&allproc_lock);
+ sx_xunlock(&proctree_lock);
uma_zfree(proc_zone, newproc);
if (p1->p_flag & P_THREADED) {
PROC_LOCK(p1);
>
> Poul-Henning
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; lapic.id =
> fault virtual address = 0x14
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc01c3eec
> stack pointer = 0x10:0xe74e3c74
> frame pointer = 0x10:0xe74e3cbc
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 99777 (sh)
> trap number = 12
> panic: page fault
> cpuid = 0; lapic.id =
> Stack backtrace:
> backtrace(c032ff8e,0,c03394ce,e74e3b68,1) at 0xc01d86a7 = backtrace+0x17
> panic(c03394ce,c0342131,cfe5496c,1,1) at 0xc01d87ba = panic+0x10a
> trap_fatal(e74e3c34,14,c03422ba,2e3,cfe4fa50) at 0xc02fa672 = trap_fatal+0x322
> trap_pfault(e74e3c34,0,14,c035a038,14) at 0xc02fa322 = trap_pfault+0x1c2
> trap(18,10,10,cf19c3f8,cf76b9ec) at 0xc02f9e9d = trap+0x3cd
> calltrap() at 0xc02e2cd8 = calltrap+0x5
> --- trap 0xc, eip = 0xc01c3eec, esp = 0xe74e3c74, ebp = 0xe74e3cbc ---
> fork1(cfe4fa50,14,0,e74e3cd4,cfe54858) at 0xc01c3eec = fork1+0x3fc
> fork(cfe4fa50,e74e3d10,c03422ba,404,0) at 0xc01c3852 = fork+0x52
> syscall(2f,2f,2f,0,80ff000) at 0xc02fa98e = syscall+0x26e
> Xint0x80_syscall() at 0xc02e2d2d = Xint0x80_syscall+0x1d
> --- syscall (2), eip = 0x807ba9f, esp = 0xbfbff6bc, ebp = 0xbfbff6e8 ---
> boot() called on cpu#0
>
> --
> 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
pgp0.pgp
Description: PGP signature
ddb & kernel panic's
Hi, I run -CURRENT and have experienced a total lockup of the machine every couple of weeks where it would just freeze with nothing on the console and I would have to power cycle it to get it back. Previously I had all the debug options turned off such as ddb, witness, invarients etc but I thought I would enable them all to see if I could get anything out of it that would be of use to you for the next time it happened. Well it happened again 20 minutes ago but I had DDB_UNATTENDED in the kernel conf and fsck_y_enable="YES" in rc.conf and so I haven't been able to see anything. There is no core dump in /var/crash but this could well be because I only have 256 meg swap and 256 meg physical ram (I keep meaning to add more swap). Anyway my question is, is there anything now I can do or read to see what happened or is it too late now? I assumed DDB_UNATTENDED would still leave some kind of log somewhere of the panic but I can't spot anything. Or if it's too late now should I remove DDB_UNATTENDED and just get backtrace's etc from DDB at the time of crash in the future? Incidently my kernel/world build is from march 4th. Regards, Matt. --- Matt ([EMAIL PROTECTED]) http://www.xtaz.co.uk/ --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
XFree86 4.3 and Cyrillic Xkb layouts
There's something fishy with Xkb in 4.3: whenever I try cyrillic layouts (e.g. ru, bg, ua, etc.), I cannot type a thing (and yes, cyrillic fonts are listed in font path). Once I change it to any latin-based (us, pl, sk, cz, fr, etc.) -- all is ok. Running xev shows that event is there. Anyone seen the same behavior/knows what may be the cause? This is with 11th diff on a 4-5 days old -CURRENT (sorry for cross-posting, most of 4.3 discussion was on -stable list, but this is a -current system). A computer is a Toshiba Portege 7200. -- Andrei __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: #warning must be protected by #if __GNUC__ in headers?
Garance A Drosihn wrote: > At 2:33 PM -0500 3/8/03, Garance A Drosihn wrote: > > > >By adding that #warning, you are going to have a compile-time error > >on some compilers, whether or not you want it. Hiding it inside of > >an #if/#endif will help for some compilers, but not on all of them. > > Er, I should note that I do like the idea of using #warnings for > some things. All I meant to say was that I would not waste my time > putting it inside of a #if __GNUC__. GNUC is not the only compiler > which understands it, and for some of the compilers which do not > understand it, you're still going to get a compile-time error even > if it's inside that #if/#endif. That's a problem, #warning is not supposed to give a compile-time error but a compile-time warning. The point is moot for the kernel where we use -Werror, but it's very valid for userland. > By putting it inside #if __GNUC__, > you're just confusing things by making it look like the warning > itself is *because of* GCC. Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: #warning must be protected by #if __GNUC__ in headers?
At 2:33 PM -0500 3/8/03, Garance A Drosihn wrote: By adding that #warning, you are going to have a compile-time error on some compilers, whether or not you want it. Hiding it inside of an #if/#endif will help for some compilers, but not on all of them. Er, I should note that I do like the idea of using #warnings for some things. All I meant to say was that I would not waste my time putting it inside of a #if __GNUC__. GNUC is not the only compiler which understands it, and for some of the compilers which do not understand it, you're still going to get a compile-time error even if it's inside that #if/#endif. By putting it inside #if __GNUC__, you're just confusing things by making it look like the warning itself is *because of* GCC. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: #warning must be protected by #if __GNUC__ in headers?
At 10:48 AM -0800 3/8/03, Marcel Moolenaar wrote: On Sat, Mar 08, 2003 at 12:28:13PM -0500, Garrett Wollman wrote: > `#if __GNUC__' wouldn't help matters; every preprocessor has to > read and interpret every preprocessor directive (so that `#else' > and `#endif' can be recognized). I don't think preprocessors should interpret directives when they are dead (ie part of an #if block or #else block that is not to be compiled). I tried to use this once, on a cross-platform program I wrote. I can tell you that some compilers will choke on a #warning, even if it is inside a #if/#endif. And other compilers will choke on #warn, even if *it* is in a #if/#endif. (note: some compilers which do not recognize #warning will support #warn for the same thing). By adding that #warning, you are going to have a compile-time error on some compilers, whether or not you want it. Hiding it inside of an #if/#endif will help for some compilers, but not on all of them. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: #warning must be protected by #if __GNUC__ in headers?
On Sat, Mar 08, 2003 at 12:28:13PM -0500, Garrett Wollman wrote: > > `#if __GNUC__' wouldn't help matters; every preprocessor has to read > and interpret every preprocessor directive (so that `#else' and > `#endif' can be recognized). I don't think preprocessors should interpret directives when they are dead (ie part of an #if block or #else block that is not to be compiled). They should merely scan the block for #else, #endif and the likes to keep track of nesting, but should otherwise ignore anything it sees. For how does it matter if a directive is valid or invalid when you're not acting upon it anyway? One can even claim that emitting an error or warning *is* reaction upon the directive. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: #warning must be protected by #if __GNUC__ in headers?
On Sat, Mar 08, 2003 at 11:19:43AM -0500, Craig Rodrigues wrote: > Hi, > > In , I see: > > #if __GNUC__ > #warning "No user-serviceable parts inside." > #endif > > > Does the use of #warning need to be protected by > #if __GNUC__ in FreeBSD header files? I am working > on something similar for . I think the use of #warning should be protected against abuse :-) In general I probably would opt to not protect it with #if __GNUC__ because #warning is not specific to gcc and since we're only compiling with gcc (officially) it's better to have it fail when somebody does use a different compiler. I think the discussion that it will trigger will yield a less gratuitous convention. Possibly documented. YMMV. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sendmail_enable="NONE" doesn't appear in rc.conf
nunotex> sendmail_enable="NONE" doesn't appear in /etc/defaults/rc.conf. Can nunotex> anyone update this file to include "NONE" option? This was done on purpose: Revision 1.158, Tue Sep 3 22:15:54 2002 UTC (6 months ago) by gshapiro Branch: MAIN Deprecate the use of sendmail_enable="NONE" as it adversely affects the new rcNG effort. Submitted by: Mike Makonnen <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: #warning must be protected by #if __GNUC__ in headers?
In the last episode (Mar 08), Garrett Wollman said: > On Sat, 8 Mar 2003 11:19:43 -0500, Craig Rodrigues <[EMAIL PROTECTED]> said: > > Does the use of #warning need to be protected by > > #if __GNUC__ in FreeBSD header files? > > No, it needs to be replaced by the standard `#error' directive > instead. I asked portmgr to do a run on the portsd cluster with this > change to look for ports that mistakenly include this file, but I > never heard back and portmgr is now busy doing the packages for 4.8. > > `#if __GNUC__' wouldn't help matters; every preprocessor has to read > and interpret every preprocessor directive (so that `#else' and > `#endif' can be recognized). This was discussed on the tendra list, and it was determined that the preprocessor should not complain about unknown directives at all and should pass them unchanged to the compiler. http://lists.tendra.org/tendra-dev/20021215/msg5.html If the #warning directive is wrapped with an appropriate #if SOMETHING conditional to hide it from compilers that do not understand it, it should be okay. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
#warning must be protected by #if __GNUC__ in headers?
< said: > Does the use of #warning need to be protected by > #if __GNUC__ in FreeBSD header files? No, it needs to be replaced by the standard `#error' directive instead. I asked portmgr to do a run on the portsd cluster with this change to look for ports that mistakenly include this file, but I never heard back and portmgr is now busy doing the packages for 4.8. `#if __GNUC__' wouldn't help matters; every preprocessor has to read and interpret every preprocessor directive (so that `#else' and `#endif' can be recognized). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Gnome2 terminal will not work right
On 3/7/2003 11:50 PM, Marcel Moolenaar wrote: On Fri, Mar 07, 2003 at 11:30:34PM -0800, Lars Eggert wrote: this may be unrelated, but for about ten days or so, I have problems where gnometerminal will stop updating after a while. I can still use the menus, close it, etc. - but all output is suspended. Most of the time, selecting "Reset" from the menu repeatedly will eventually get me back to a working state again. It also seems that pasting multi-line text into a gnometerminal (as opposed to typing or it displaying output) will trigger this frequently. Me too I tend to think it happens more often with maximized windows than not and also when long lines are involved. A reset most of the time gets me back, but I do occasionally have to kill gnome-terminal completely when all the terminals are dead. Unfortunately I don't have the time to dig into it, but I'm probably going to switch window manager and see if that makes a difference. For some reason I'm suspicious about Metacity. Not necessarily because of this... I also switched to a TrueType font for gnometerminals (bitstream-vera) around the same time, so maybe that's a factor, too. As for window managers, I use sawfish (and have been, for a long time before the problem.) Also (unrelated?), it seems that X eats up a LOT of CPU with antialiases TrueType fonts in terminals, compared to good, old lucida-typewriter. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: sendmail_enable="NONE" doesn't appear in rc.conf
From: "Daniel Flickinger" <[EMAIL PROTECTED]> Sent: Saturday, March 08, 2003 11:48 AM > I have not checked recently, but 'make installworld' has > always trashed files: > > /usr/sbin/sendmail > /usr/bin/mailq > /usr/bin/newaliases > > which, in the default, are symbolic links to > /usr/sbin/mailwrapper. > > Using postfix which installs its own /usr/sbin/sendmail > which is a program, not a symbolic link, I: > > cd /usr/sbin > mv sendmail postmail > ln -s postmail sendmail If installed from ports, Postfix installs a /user/local/sbin/sendmail which does not interfere with the mailwrapper setup. The port also fixes /etc/mail/mailer.conf to point to the postfix binary instead of the sendmail binary. The only thing you need to watch is mergemaster putting the default mailer settings back. --K To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ng_iface commit broken
mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/dev -I@/. ./include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/modules/netgraph/ifa ce/../../../netgraph/ng_iface.c /usr/src/sys/netgraph/ng_iface.c:53:23: opt_atalk.h: No such file or directory /usr/src/sys/netgraph/ng_iface.c:54:22: opt_inet.h: No such file or directory /usr/src/sys/netgraph/ng_iface.c:55:23: opt_inet6.h: No such file or directory /usr/src/sys/netgraph/ng_iface.c:56:21: opt_ipx.h: No such file or directory mkdep: compile failed -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/net if_arcsubr.c if_atmsubr.c if_ef.c if_ethersubr.c if_faith.c if_fddisubr.c if_gif.c if_iso88025subr.c if_loop.c if_ppp.c if_sl.c if_spppsubr.c if_stf.c if_tun.c netisr.c netisr.h src/sys/netatalk aarp.c at_extern.h at_var.h ...
On Sat, Mar 08, 2003 at 06:11:35PM +0900, [EMAIL PROTECTED] wrote: > Hello. > > On Tue, Mar 04, 2003 at 03:19:55PM -0800, Jonathan Lemon wrote: > > jlemon 2003/03/04 15:19:55 PST > > > > FreeBSD src repository > > > > Modified files: > > sys/net if_arcsubr.c if_atmsubr.c if_ef.c > > if_ethersubr.c if_faith.c if_fddisubr.c > > if_gif.c if_iso88025subr.c if_loop.c > > if_ppp.c if_sl.c if_spppsubr.c if_stf.c > > if_tun.c netisr.c netisr.h > [snip] > > After this commit, netgraph seems to be broken. Please Fix (TM:). > I'm using mpd(ports/net/mpd) to speak PPPoE for my ADSL connection, > and mpd relies on netgraph devices. Oops. This should be fixed now. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
#warning must be protected by #if __GNUC__ in headers?
Hi, In , I see: #if __GNUC__ #warning "No user-serviceable parts inside." #endif Does the use of #warning need to be protected by #if __GNUC__ in FreeBSD header files? I am working on something similar for . Some other header files check for __GNUC__ before using #warning, such as , but does not. Thanks. -- Craig Rodrigues http://home.attbi.com/~rodrigc [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: softupdates && write cache && ata tags topic
Hi, > Is it safe to use softupdates + write cache + ata tags (IBM disk)? The summary of *my* experience and knowledge is: It is considered *unsave* to use Soft Updates with WriteCache enabled. I consider it unnecessary to use WriteCache if TaggedQueuing is enabled and working. (The performace gain of WriteCache and TaggedQueuing is more or less the same, the combination of both adds less than 10% of performance and you shouldn't use Soft Updates any more) Soft Updates alone add a huge amount of performance. So I recommend to use Soft Updates with Tagged Queuing enabled. -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) Powered by FreeBSD 5.0-CURRENT To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kermit hoses my system, too
I posted a note that mgetty was hosing my system because it clobbered /etc/ttys with data froim /etc/passwd and Terry meant it could have to do with some old FreeBSD VM bug. Today I tried to connect to the modem via kermit and the system got frozen bad. dmesg: w.bus.devctl_disable: WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted pid 494 (squid), uid 0: exited on signal 6 (core dumped) no matching session no matching session no matching session pid 576 (squid), uid 0: exited on signal 6 (core dumped) Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks, buffers remaining... 7 7 1 1 done Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #5: Sat Mar 1 23:32:22 GMT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc06c3000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc06c30a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1800135028 Hz CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1800.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febfbff real memory = 536854528 (511 MB) avail memory = 514134016 (490 MB) Allocating major#253 to "net" Allocating major#252 to "pci" Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE31 pcibios: BIOS version 2.10 Using $PIR table, 11 entries at 0xc00f1720 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe800-0xebff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 2.0 on pci0 isa0: on isab0 pci0: at device 2.3 (no driver attached) atapci0: port 0xb400-0xb40f,0xb800-0xb803,0xd000-0xd007,0xd400-0xd403,0xd800-0xd807 irq 11 at device 2.5 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 2.7 (no driver attached) ohci0: mem 0xe600-0xe6000fff irq 3 at device 3.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xe580-0xe5800fff irq 5 at device 3.1 on pci0 usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0xe500-0xe5000fff irq 9 at device 3.2 on pci0 usb2: OHCI version 1.0, legacy support usb2: on ohci2 usb2: USB revision 1.0 uhub2: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: at device 3.3 (no driver attached) sis0: port 0x9800-0x98ff mem 0xe400-0xe4000fff irq 4 at device 4.0 on pci0 sis0: Ethernet address: 00:e0:18:d3:f4:e0 miibus0: on sis0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ed0: port 0x9400-0x941f irq 10 at device 9.0 on pci0 ed0: address 00:e0:7d:7e:2c:3a, type NE2000 (16 bit) pci0: at device 10.0 (no driver attached) cbb0: irq 4 at device 11.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 atapci1: port 0x8000-0x807f,0x8400-0x840f,0x8800-0x883f mem 0xe280-0xe281,0xe300-0xe3000fff irq 11 at device 14.0 on pci0 atapci1: Busmastering DMA not configured ata2: at 0x8800 on atapci1 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 orm0: at iomem 0xd-0xd on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters
sendmail_enable="NONE" doesn't appear in rc.conf
Hello to all, sendmail_enable="NONE" doesn't appear in /etc/defaults/rc.conf. Can anyone update this file to include "NONE" option? Thanke very much, Nuno Teixeira -- /* PGP fingerprint: C6D1 06ED EB54 A99C 6B14 6732 0A5D 810D 727D F6C6 */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
softupdates && write cache && ata tags topic
Hello to all, I understand the basic concept of the folowing techs: softupdates, disk write cache and ata tags. My question is: It is safe to use softupdates + write cache + ata tags (IBM disk)? I read someware that it not safe to use softupdate + write cache (without ata tags) and if it is not safe why FreeBSD 5.0 ships with them enabled? Thanks very much, Nuno Teixeira -- /* PGP fingerprint: C6D1 06ED EB54 A99C 6B14 6732 0A5D 810D 727D F6C6 */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Big IDE drive + little IDE controller + freebsd
It seems James Satterfield wrote: Hmm there is a workaround in -current for using 48bit access to the old promises, however it should only engage when you access areas beyond 137G on the drives. However using 48bit modes on older controllers are not really a good idea as they tend to do wierd things... > Okay... Perhaps I'm just a dumbass with a failing drive? For the longest time, I've > thought the hardware needed to support the large drives. From the reading I've just > done, that doesn't seem to be the case. I certainly hope this brand new drive isn't > failing tho. I really hate doing hardware warranty returns. > > James. > > On Fri, 7 Mar 2003 14:20:24 -0800 > James Satterfield <[EMAIL PROTECTED]> wrote: > > > I've got a 160GB ide drive in my FBSD box. It's got an old ide controller that > > doesn't support big ide drives. Yet freebsd recognizes the drives full capacity, > > allows me to partition it, and newfs it. After writing about 47GB of data to the > > drive, I start getting these. > > ad5: WRITE command timeout tag=0 serv=0 - resetting > > ata2: resetting devices .. > > > > > > atapci1: port > > 0xef00-0xef3f,0xefe0-0xefe3,0xefa8-0xefaf,0xefe4-0xefe7,0xeff0-0xeff7 mem > > 0xffae-0xffaf irq 10 at device 20.0 on pci0 > > ad5: 156334MB [317632/16/63] at ata2-slave UDMA66 > > > > > > James. > > > > 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 > -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FreeBSD 5.0R panic: bwrite: buffer is not busy???
Hi, I get this error afrer few time of working always during this the listening of the music contained in my EXT3 partition here the operation that I do: >> Starting Xserver >> Kldloading snd_cmi >> mounting my EXT3 partition in read-only mode >> starting listening music with XMMS I don't have the dump, because the DEBUGGING options are disabled, it happened to me 3 time , with 5.0-RELEASE and -CURRENT kernel , now I've turned on the debug in the kernel , and I'll wait that the system freeze up again in order to give some more infos. What happen is this: The system freeze up, then after few sec the system reboots. Here the messages that appears in console: syslogd: kernel boot file is /boot/kernel/kernel kernel: TPTE at 0xbfc21bb0 IS ZERO @VA 086ec000 kernel: panic: bad pte kernel: kernel: syncing disks, buffers remaining... panic: bwrite: buffer is not busy??? kernel: Uptime: 1h26m42s kernel: Terminate ACPI kernel: Automatic reboot in 15 seconds - press a key on the console to abort kernel: --> Press a key on the console to reboot, kernel: --> or switch off the system now. kernel: Rebooting... The panic appears randomly after the boot , it can be an hour as can be 3 or more hours . Thank you very much for your time Marcello __ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: failed to set signal flags properly for ast()
On Fri, 7 Mar 2003, Kris Kennaway wrote:
> I've been getting a few of these on 5.0 lately:
>
> Mar 7 21:31:07 bento kernel: failed to set signal flags properly for
> ast()
>
> Is there any additional debugging information I can provide to help
> track this down?
It wouldn't hurt to know the signal masks. This patch has rotted a bit:
%%%
Index: subr_trap.c
===
RCS file: /home/ncvs/src/sys/kern/subr_trap.c,v
retrieving revision 1.239
diff -u -2 -r1.239 subr_trap.c
--- subr_trap.c 28 Dec 2002 01:23:07 - 1.239
+++ subr_trap.c 28 Dec 2002 05:32:51 -
@@ -73,7 +79,7 @@
u_int oticks;
{
- struct proc *p = td->td_proc;
- struct kse *ke = td->td_kse;
+ struct proc *p;
+ p = td->td_proc;
CTR3(KTR_SYSC, "userret: thread %p (pid %d, %s)", td, p->p_pid,
p->p_comm);
@@ -84,6 +90,16 @@
mtx_lock_spin(&sched_lock);
if (SIGPENDING(p) && ((p->p_sflag & PS_NEEDSIGCHK) == 0 ||
- (td->td_kse->ke_flags & KEF_ASTPENDING) == 0))
+ (td->td_kse->ke_flags & KEF_ASTPENDING) == 0)) {
printf("failed to set signal flags properly for ast()\n");
+ printf(
+"proc %s sig %#x %#x %#x %#x, mask %#x %#x %#x %#x, sigflag %d, astflag %d\n",
+ p->p_comm,
+ ((u_int *)&p->p_siglist)[0], ((u_int *)&p->p_siglist)[1],
+ ((u_int *)&p->p_siglist)[2], ((u_int *)&p->p_siglist)[3],
+ ((u_int *)&p->p_sigmask)[0], ((u_int *)&p->p_sigmask)[1],
+ ((u_int *)&p->p_sigmask)[2], ((u_int *)&p->p_sigmask)[3],
+ (p->p_sflag & PS_NEEDSIGCHK) != 0,
+ (td->td_kse->ke_flags & KEF_ASTPENDING) != 0);
+ }
mtx_unlock_spin(&sched_lock);
PROC_UNLOCK(p);
%%%
We really need to determine what didn't set the signal masks, but that is
difficult to determine from here.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
NULL pointer problem in pid selection ?
Just got this crash on -current, and I belive I have seen similar before. addr2line(1) reports the faulting address to be ../../../kern/kern_fork.c:395 which is in the inner loop of pid collision avoidance. Poul-Henning Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01c3eec stack pointer = 0x10:0xe74e3c74 frame pointer = 0x10:0xe74e3cbc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 99777 (sh) trap number = 12 panic: page fault cpuid = 0; lapic.id = Stack backtrace: backtrace(c032ff8e,0,c03394ce,e74e3b68,1) at 0xc01d86a7 = backtrace+0x17 panic(c03394ce,c0342131,cfe5496c,1,1) at 0xc01d87ba = panic+0x10a trap_fatal(e74e3c34,14,c03422ba,2e3,cfe4fa50) at 0xc02fa672 = trap_fatal+0x322 trap_pfault(e74e3c34,0,14,c035a038,14) at 0xc02fa322 = trap_pfault+0x1c2 trap(18,10,10,cf19c3f8,cf76b9ec) at 0xc02f9e9d = trap+0x3cd calltrap() at 0xc02e2cd8 = calltrap+0x5 --- trap 0xc, eip = 0xc01c3eec, esp = 0xe74e3c74, ebp = 0xe74e3cbc --- fork1(cfe4fa50,14,0,e74e3cd4,cfe54858) at 0xc01c3eec = fork1+0x3fc fork(cfe4fa50,e74e3d10,c03422ba,404,0) at 0xc01c3852 = fork+0x52 syscall(2f,2f,2f,0,80ff000) at 0xc02fa98e = syscall+0x26e Xint0x80_syscall() at 0xc02e2d2d = Xint0x80_syscall+0x1d --- syscall (2), eip = 0x807ba9f, esp = 0xbfbff6bc, ebp = 0xbfbff6e8 --- boot() called on cpu#0 -- 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
witness needs DDB
subr_witness.c now needs DDB option enabled, otherwise can not be compiled. please fix it. David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/net if_arcsubr.c if_atmsubr.c if_ef.c if_ethersubr.c if_faith.c if_fddisubr.c if_gif.c if_iso88025subr.c if_loop.c if_ppp.c if_sl.c if_spppsubr.c if_stf.c if_tun.c netisr.c netisr.h src/sys/netatalk aarp.c at_extern.h at_var.h ...
Hello. On Tue, Mar 04, 2003 at 03:19:55PM -0800, Jonathan Lemon wrote: > jlemon 2003/03/04 15:19:55 PST > > FreeBSD src repository > > Modified files: > sys/net if_arcsubr.c if_atmsubr.c if_ef.c > if_ethersubr.c if_faith.c if_fddisubr.c > if_gif.c if_iso88025subr.c if_loop.c > if_ppp.c if_sl.c if_spppsubr.c if_stf.c > if_tun.c netisr.c netisr.h [snip] After this commit, netgraph seems to be broken. Please Fix (TM:). I'm using mpd(ports/net/mpd) to speak PPPoE for my ADSL connection, and mpd relies on netgraph devices. The kernel built from the source checked out as env TZ=UTC cvs -R up -dPD'2003-03-04 23:19:00' seems to be OK, while the kernel from env TZ=UTC cvs -R up -dPD'2003-03-04 23:20:00' is NG. Actually, mpd running on the broken kernel displays the message saying the connection is established, but pinging to the peer receives nothing. Pinging to the peer while tcpdump'ing on ng0 shows the echo reply, but ping shows nothing. I've turned off any firewalling and NAT functions, so they are not the case. Pinging over other interfaces works just fine. Regards. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "blockable sleep lock" panic in latest -current.
On 6 Mar 2003, Thomas Seck wrote: > * Bruce Evans ([EMAIL PROTECTED]): > > > This is the usual panic from sync() in panic() tripping over a lock. > > Calling sync() in panic was never safe and now usually fails. > > Should one set "kern.sync_on_panic" to zero then? Not a bad idea. It depends on whether you have good backups and UPS's I guess. Power failures give much the same loss and corruption of data and metadata as not syncing in panics (perhaps better since there is less chance of writing corrupt data; perhaps worse since dumping in panic() works better than syncing so the data is usually not lost irrecoverably after a panic with no sync). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
