Re: UFS file system problem in either stable or current
Wed, Oct 22, 2003 at 03:14:33, strick (Dan Strick) wrote about "UFS file system problem in either stable or current": DS> There seems to be an inconsistency between release 4.9-RC and 5.1 ufs DS> support. If I fsck the same ufs (type 1 of course) file system on DS> both releases, each claims that the other has left incorrect DS> summary data in the superblock. Presumably only one can be correct. DS> I just don't know which to blame. Does this require explicit fsck? I have dual-booting between 4.9-release (and all previous 4.* releases earlier) and 5.1 (of 20030526) with shared disks and boot checking required in fstab; sometimes one of them crash and forced checking is made; neither 4.* nor 5.1 claims superblock is bad. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.4-RC3: "giving up on 3 buffers"
Hi, I have got system on 5.4-RC3 which stably fails to reboot correctly with the message in subject: After reboot, some file systems (/var and /var2) aren't correctly unmounted. I can debug it if someone helps in this (what to debug and what to print). -netch- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-RC3: "giving up on 3 buffers"; "pfs_vncache_unload: 1 entries remaining"
Sun, May 01, 2005 at 10:18:35, netch wrote about "5.4-RC3: "giving up on 3
buffers"":
> I have got system on 5.4-RC3 which stably fails to reboot correctly
> with the message in subject:
Next message after him:
pfs_vncache_unload: 1 entries remaining
After reboot:
WARNING: / was not properly dismounted
/var isn't unmounted also. Another partitions are explicitly unmounted
in /etc/rc.shutdown so this reduce harm of shutdown failures.
Disabling softupdates changes nothing.
Kernel config, boot dmesg and head of fs dump follows.
> After reboot, some file systems (/var and /var2) aren't correctly unmounted.
> I can debug it if someone helps in this (what to debug and what to print).
==={{{ nn154
machine i386
cpu I686_CPU
ident nn154
# To statically compile in device wiring instead of /boot/device.hints
#hints "GENERIC.hints" # Default places to look for devices.
options SCHED_4BSD # 4BSD scheduler
options INET# InterNETworking
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big directories
options NFSCLIENT # Network Filesystem Client
options NFSSERVER # Network Filesystem Server
options MSDOSFS # MSDOS Filesystem
options CD9660 # ISO 9660 Filesystem
options PROCFS # Process filesystem (requires PSEUDOFS)
options PSEUDOFS# Pseudo-filesystem framework
options GEOM_GPT# GUID Partition Tables.
options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!]
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options SCSI_DELAY=15000# Delay (in ms) before probing SCSI
options KTRACE # ktrace(1) support
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time
extensions
options KBD_INSTALL_CDEV# install a CDEV entry in /dev
options ADAPTIVE_GIANT # Giant mutex is adaptive.
options MSGBUF_SIZE=131072
device apic# I/O APIC
# Bus support. Do not remove isa, even if you have no isa slots
device isa
device eisa
device pci
# ATA and ATAPI devices
device ata
device atadisk # ATA disk drives
device atapicd # ATAPI CDROM drives
options ATA_STATIC_ID # Static device numbering
# SCSI peripherals
device scbus # SCSI bus (required for SCSI)
device da # Direct Access (disks)
device cd # CD
device pass# Passthrough device (direct SCSI access)
# atkbdc0 controls both the keyboard and the PS/2 mouse
device atkbdc # AT keyboard controller
device atkbd # AT keyboard
device psm # PS/2 mouse
device vga # VGA video card driver
device splash # Splash screen and screen saver support
# syscons is the default console driver, resembling an SCO console
device sc
device agp # support several AGP chipsets
# Floating point support - do not disable.
device npx
# Power management support (see NOTES for more options)
#device apm
# Add suspend/resume support for the i8254.
device pmtimer
# Serial (COM) ports
device sio # 8250, 16[45]50 based serial ports
# PCI Ethernet NICs that use the common MII bus controller code.
# NOTE: Be sure to keep the 'device miibus' line in order to use these NICs!
device miibus # MII bus support
device re # RealTek 8139C+/8169/8169S/8110S
device rl # RealTek 8129/8139
# Pseudo devices.
device loop# Network loopback
device mem # Memory and kernel memory devices
device io # I/O device
device random # Entropy device
device ether # Ethernet support
device sl # Kernel SLIP
device ppp # Kernel PPP
device tun # Packet tunnel.
device pty # Pseudo-ttys (telnet etc)
device md # Memory "disks"
device gif # IPv6 and IPv4 tunneling
device faith # IPv6-to-IPv4 relaying (translation)
# The `bpf' device enables the Berkeley Packet Filter.
#
Re: make buildworld fails: share/doc/usd/13.viref
Thu, Jan 25, 2001 at 19:48:32, ru wrote about "Re: make buildworld fails:
share/doc/usd/13.viref":
> Please try with attached patch.
=== cut ===
===> libgroff
c++ -I/usr/obj/m4/REL4/src/i386/usr/include/g++ -O -m486 -pipe -I/m4/REL4/src/gn
u/usr.bin/groff/libgroff/../include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_L
IMITS_H=1 -DHAVE_STDLIB_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_LIM
ITS_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_PU
TENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1
-DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -I/m4/REL4/src/gnu/usr
.bin/groff/libgroff/../../../../contrib/groff/include -fno-for-scope -I/usr/obj/
m4/REL4/src/i386/usr/include -fno-rtti -fno-exceptions -c /m4/REL4/src/gnu/usr.b
in/groff/libgroff/../../../../contrib/groff/libgroff/assert.cc -o assert.o
cc1plus: Invalid option `-fno-exceptions'
*** Error code 1
=== end cut ===
The same conditions: target system is 4-stable, host one is 3.4-stable
> On Thu, Jan 25, 2001 at 07:44:05PM +0200, Valentin Nechayev wrote:
> > ===> share/doc/usd/13.viref
> > (cd /m4/REL4/src/share/doc/usd/13.viref/../../../../contrib/nvi/docs/USD.doc/vi.
> > ref; sed -e\ 's:\(\.so[\ \ ][\ \ ]*\)\(vi.ref\)$:\1/m4/REL4/src/share/doc
> > /usd/13.viref/../../../../contrib/nvi/docs/USD.doc/vi.ref/\2:' -e\ 's:\(\.so[\ \
> > ][\ \ ]*\)\(ex.cmd.roff\)$:\1/m4/REL4/src/share/doc/usd/13.viref/../..
> > /../../contrib/nvi/docs/USD.doc/vi.ref/\2:' -e\ 's:\(\.so[\ \ ][\ \ ]*\)\(re
> > f.so\)$:\1/m4/REL4/src/share/doc/usd/13.viref/../../../../contrib/nvi/docs/USD.d
> > oc/vi.ref/\2:' -e\ 's:\(\.so[\ \][\ \ ]*\)\(set.opt.roff\)$:\1/m4/REL4
> > /src/share/doc/usd/13.viref/../../../../contrib/nvi/docs/USD.doc/vi.ref/\2:' -e\
> > 's:\(\.so[\ \ ][\ \ ]*\)\(vi.cmd.roff\)$:\1/m4/REL4/src/share/doc/usd/13.vir
> > ef/../../../../contrib/nvi/docs/USD.doc/vi.ref/\2:' -e 's:^\.so index.so$::' vi.
> > ref) | groff -mtty-char -Tascii -t -s -me -U -o1- > /dev/null
> > groff: illegal option -- U
> > usage: groff [-abehilpstvzCENRSVXZ] [-Fdir] [-mname] [-Tdev] [-ffam] [-wname]
> >[-Wname] [ -Mdir] [-dcs] [-rcn] [-nnum] [-olist] [-Parg] [-Larg]
> >[files...]
> > groff -h gives more help
> >
> >
> > host OS is `FreeBSD 3.4-STABLE i386'
> > No words in src/UPDATING about it
> >
> >
> > /netch
>
> --
> Ruslan ErmilovOracle Developer/DBA,
> [EMAIL PROTECTED] Sunbay Software AG,
> [EMAIL PROTECTED]FreeBSD committer,
> +380.652.512.251 Simferopol, Ukraine
>
> http://www.FreeBSD.orgThe Power To Serve
> http://www.oracle.com Enabling The Information Age
> Index: Makefile.inc1
> ===
> RCS file: /home/ncvs/src/Makefile.inc1,v
> retrieving revision 1.141.2.19
> diff -u -p -r1.141.2.19 Makefile.inc1
> --- Makefile.inc1 2001/01/22 23:26:15 1.141.2.19
> +++ Makefile.inc1 2001/01/25 17:47:57
> @@ -168,6 +168,8 @@ CROSSENV= MAKEOBJDIRPREFIX=${OBJTREE} \
> COMPILER_PATH=${WORLDTMP}/usr/libexec:${WORLDTMP}/usr/bin \
> LIBRARY_PATH=${WORLDTMP}${SHLIBDIR}:${WORLDTMP}/usr/lib \
> OBJFORMAT_PATH=${WORLDTMP}/usr/libexec \
> + GROFF_FONT_PATH=${WORLDTMP}/usr/share/groff_font \
> + GROFF_TMAC_PATH=${WORLDTMP}/usr/share/tmac \
> PERL5LIB=${WORLDTMP}/usr/libdata/perl/5.00503
>
> # bootstrap-tool stage
> @@ -199,7 +201,24 @@ IMAKEENV=${CROSSENV} \
> IMAKE= ${IMAKEENV} ${MAKE} -f Makefile.inc1
>
> USRDIRS= usr/bin usr/lib/compat/aout usr/games usr/libdata/ldscripts \
> - usr/libexec/${OBJFORMAT} usr/sbin usr/share/misc
> + usr/libexec/${OBJFORMAT} usr/sbin usr/share/misc \
> + usr/share/tmac/locale usr/share/tmac/mdoc/locale \
> + usr/share/tmac/mm \
> + usr/share/groff_font/devX100 \
> + usr/share/groff_font/devX100-12 \
> + usr/share/groff_font/devX75 \
> + usr/share/groff_font/devX75-12 \
> + usr/share/groff_font/devascii \
> + usr/share/groff_font/devcp1047 \
> + usr/share/groff_font/devdvi \
> + usr/share/groff_font/devhtml \
> + usr/share/groff_font/devkoi8-r \
> + usr/share/groff_font/devlatin1 \
> + usr/sh
build 4-stable on 3-stable: how?
A few last months, building of 4-stable on 3.4-stable system fails with === cut === c++ -I/usr/obj/var/REL4/src/i386/usr/include/g++ -O -pipe -I/usr/obj/var/REL4/ src/i386/usr/include -I/var/REL4/src/gnu/usr.bin/gperf/../../../contrib/gperf/li b -I/var/REL4/src/gnu/usr.bin/gperf -c /var/REL4/src/gnu/usr.bin/gperf/../../../ contrib/gperf/src/new.cc /var/REL4/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc:80: warning: ` catch', `throw', and `try' are all C++ reserved words /var/REL4/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc: In function ` void operator delete(void *)': /var/REL4/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc:82: declaratio n of `operator delete(void *)' throws different exceptions... :82: ...from previous declaration here *** Error code 1 === end cut === or similar. Can anybody explain why to fix it? Or one must use 4.2-release as trampoline??? A month ago I asked this and Ruslan Ermilov sent me a patch, but this patch causes build fault also. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: fresh 4.3-RC: "microuptime went backwards", console lockup
Wed, Apr 11, 2001 at 11:37:35, nrh wrote about "Re: fresh 4.3-RC: "microuptime went backwards", console lockup": > This happened to me; a couple things you might try: > kern.timecounter.method=1 This is set already (in sysctl.conf), but does not help. > or, possibly adding: > device apm0at nexus? disable flags 0x20 See my config - it exists there already. Also does not help. > to your kernel. P.S. There is no need for overquote. P.P.S. I ask again: can anybody send me text or URL for PHK's description of his timecounter scheme, especially for tco_forward() concept? > Valentin Nechayev wrote: > > Today, 4.3-RC (RELENG_4, date=2001.04.11.00.00.00) was built and, when > > new system started: > > 1) during boot and even before /sbin/init started, "microuptime went backwards" > > occured too many times. > > 2) after startx, syscons switched to ttyv0 and stayed here; after > > mutual swithing to ttyvb, console locked up totally. > > No problems with previous system (RELENG_4, date=2001.03.05.00.00.00) > > were seen. Xwindow is 3.3.6 from latest port. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Old compiler (3.3-stable -> 4->stable)
Wed, May 16, 2001 at 01:41:55, ab (Eugene M. Kim) wrote about "Old compiler (3.3-stable -> 4->stable)": > I'm having some hard time getting a machine upgraded from 3.3-stable to > 4-stable. It is better now to do binary upgrade from 3.x to 4.3, if your Internet connection allows to download `bin' package (~50M). (But for mergemaster you must untar or cvsup full sources.) Upgrade via `make world' will fail in too many places, such as perl, gperf & groff, kernel... /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: netstat reports "kvm_read: bad address"
> kervorkian 187# netstat -rn > [...] > 10.10.220/24 link#2 UC 00 de1 => > netstat: kvm_read: Bad address > 10.10.220.60 0:d0:b7:b9:1e:3a UHLW0 167 de1496 > netstat: kvm_read: Bad address > 10.10.220.70 0:d0:b7:b9:21:3e UHLW0 210 de1496 > netstat: kvm_read: Bad address > 10.10.220.73 0:d0:b7:b9:b4:e7 UHLW0 209 de1496 > netstat: kvm_read: Bad address > 10.10.220.74 0:d0:b7:b9:1d:66 UHLW0 209 de1495 > netstat: kvm_read: Bad address I observe occasionally such failings on our http proxy server with `netstat -an'. This host is dual-processor. AFAIU reading of /dev/kmem does not lock Giant lock (or its equivalent on 4.x), and one process can traverse kernel structures in userland mode while some kernel code on another processor changes it. If reported problems with `netstat -rn' are occasional and system is SMP, this can be diagnosed as non-serializable access problem. But possibly routing subsystem has some own flawnesses. My friend has multihomed host with 3 restricted BGP feeds in receive-only mode. Stable routing table size is ~900 routes. Independently on UP/SMP, 3.x/4.x, minor system versions, zebra versions, running this BGP speaker with zebra leads to crash in no more than 12 hours. We could not obtain any sensitive information from crash dumps because kernel structures was spoiled to unparseable mash. Without routing daemon or with gated, this host stays for months. Analysis of zebra says that it does not use kmem or any another nonstandard interface, only common unix interfaces up to routing sockets. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: machine hangs when no memory/swap left ...
Mon, May 28, 2001 at 19:10:55, scrappy (The Hermit Hacker) wrote about "machine hangs when no memory/swap left ...": > stupid question, but shouldn't there be a mechanism to prevent that? > something to crash the process or somethign when the machine runs out of > virtual memory? This mechanism exists - let you grep src/sys/vm/vm_pageout.c for killproc() call. But it does not work always. Also it does not work correct in almost any sense. Let's get workstation without any process running, and run on it: 1) top, 2) systat -vm 1, 3) a process which eats all memory and is not limited. When more and more processes swapped, a memory hog more and more sleeps on "vmwait" channel (see src/sys/vm/vm_page.c). When VM exhausts, vm_pageout_scan() kills first not memory hog (which sleeps on "vmwait" channel), but a most fat _running_ process (i.e. top or vmstat). And when top & vmstat are both killed already, then VM kills memory hog. Effect is repeatable (I tested on 5.0-current-20010512). vm_pageout_scan() code tells that it tests both running and sleeping processes, but such stable preference to small running processes is strange. I saw lockups (when system cannot do anything and is totally dead except interrupt handling) estimately 1 per 10 tests. It does not sit in VM scan in this lockup, and I don't know what does it do. How to test what happens during lockup? Due to extremely bad code writing style (no malloc() result checking, and so on) of most target software, I suppose that the only correct reaction for VM exhausting with current software is to reboot system, or at least kill all processes and tell init to restart current runlevel from scratch. This can be do with external or kernel watchdog, but standard realization may be preferred. And pity fact is that VM implementation does not count VM exhausting situations and killed processes. Patch is rather simple. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Kernel Fails to Boot. Errors out On MySQL
>>> Doug Barton wrote: > Once the system comes up multiuser, diagnose and fix mysql problems. For > future reference, ALWAYS disable startup scripts for third party stuff > before _starting_ the upgrade. This is especially true for remote upgrades. The pity moment is that init(8) logic is absolutely inconsistent: it doesn't allow local logins before /etc/rc terminates, and even doesn't allow reboot via ctrl-alt-del before /etc/rc terminates. If system hangs during boot scripts, the only way to unhang it locally is to press reset. (Using debugger is not considered.) Does anybody think for cured init? (Really, question not for -stable) /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: time_t definition is worng
Fri, Jun 01, 2001 at 16:18:08, david (David Wolfskill) wrote about "Re: time_t definition is worng": > >Historically people compared time stamps by subtracting one from > >another. > Which is a practice that the difftime() function was invented to > replace. difftime is for ANSI compatilibity but not for UNIX. It returns double. There is no reason to attract float-point calculations without explicit need... /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: time_t definition is worng
Fri, Jun 01, 2001 at 16:52:18, Antoine.Beaupre (Antoine Beaupre (LMC)) wrote about "Re: time_t definition is worng": > Why not make leave it a long on alpha (and IA64) and make it a 'long > long' on IA32 so that we get rid of the Y38 bug right now? ;) It will break ABI compatilibity in too many places. Most of them can be reduced to new syscalls (at least: wait4, stat, lstat, fstat, setitimer, getitimer, select, getrusage, settimeofday, gettimeofday, utimes, adjtime, futimes, poll...), structure content retranslation code in obsolete syscalls implementations, major version bump for almost all shared libraries... Because deadline will be in 2038, I don't think FreeBSD staff will do such changes before 2020.;| (Are you sure unix systems will exist yet another 20 years?) /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Who's HUPing my daemon?
Fri, Jun 01, 2001 at 12:10:35, gnb (Gregory Bond) wrote about "Who's HUPing my
daemon?":
Proper daemonization consists of many steps, some of them are:
1) chdir("/"), to prevent staying on file system which must be unmounted.
(But let's consider changing sysctl kern.corefile to absolute path.)
2) Close all unneeded file handles, including 0,1,2, and reopen
/dev/null or log files on them.
3) Setup own session with setsid(). This is exact what you need now.
Of course, daemon() will do the same in one call of itself, but it is
unportable.
> I'm trying to get a daemon running at boot time from rc.d. When the system
> boots, the script is run, the daemon is started, and all is fine. Then a few
> seconds later, (possibly at the same time that rc finishes and getty is
> launched), the daemon gets a SIGHUP and cleans itself up and exits. Running
> the start script by hand after logging in works and the daemon stays active
> more or less forever as you expect.
> Some hackery with ktrace shows that it is a SIGHUP that is killing it, and it
> is waiting in select() at the time (which is the expected state).
>
> The relevent code in main() is like this:
> if(makedaemon && fork())
> exit(0);
>
> openlog("bpalogin",LOG_PID,LOG_DAEMON);
>
> I'm suspicious that just a plain fork() is not enough to disconnect from the
> boot sequence but I can't work out what's causing the HUP. Suggestions?
>
> (I suspect replacing the code with
> if (makedaemon) daemon(0,0);
> will fix it... bloody Linux hackers, no respect for real Unix!)
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: poor performance with FreeBSD and Windows ICS
Hello Juha Saarinen! Sat, Jun 02, 2001 at 12:27:54, juha (Juha Saarinen) wrote about "RE: poor performance with FreeBSD and Windows ICS": > $ make > Warning: Object directory not changed from original > /usr/src/share/man/man7 make clean obj && make depend && make all install /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: High interrupt rate
Thu, Jul 19, 2001 at 20:35:42, rrs (Rob Schulhof) wrote about "High interrupt rate": > I'm puzzled why my system is spending 1% of CPU on system interrupts when > completely idle. I even with avery thing killed except kernel proceses top > and vmstat show 0.8% is spent servicing interrupts. A 'vmstat -i' shows the > only interrupts set are the CLK and RTC. Anybody come across this? I'm > assuming it's a hardware problem. One my system constantly shows 12% interrupt time. LA does not reflect this. Possibly state checking interferes with some external activity. One should know that these times are very approximate. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Sendmail broken after upgrade 4.4-RELEASE to 4.5-STABLE
Thu, Feb 14, 2002 at 22:12:08, mailing (Rick Hoppe) wrote about "Sendmail broken after upgrade 4.4-RELEASE to 4.5-STABLE": > Feb 14 21:30:00 ns1 sendmail[105]: NOQUEUE: SYSERR(root): Warning: .cf > version level (10) exceeds sendmail version 8.11.6 functionality (9) > > Some time ago I already upgraded the sendmail installation to 8.12.2 so I > didn't want make world to do something with sendmail. > > So I did specify in /etc/make.conf not to create sendmail, but somehow the > "old" version 8.11.6 was installed by make world. > > This is my /etc/make.conf > > CFLAGS= -O -pipe > NO_BIND=true# do not build BIND > NO_SENDMAIL=true# do not build sendmail and related programs Changing of /usr/sbin/sendmail is controlled by NO_MAILWRAPPER, not NO_SENDMAIL. Real sendmail is placed as /usr/libexec/sendmail/sendmail. You should re-install sendmail 8.12 to another place and edit /etc/mail/mailer.conf for path to your sendmail. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4-stable, sendmail, and named-authoritative zones
Fri, Feb 15, 2002 at 21:20:32, marck (Dmitry Morozovsky) wrote about "4-stable, sendmail, and named-authoritative zones": What `sendmail -d8.8,21.12 -bv [EMAIL PROTECTED]' says? And whether `echo \$=w | sendmail -bt' says unallowed names? > There is 4-stable machine with system-default named and sendmail. named > has some authoritative master zones (one of them is for the domain which > contains `hostname`). All these zones have master MXes at outer site. > > Now, for all zones except the very zone containing hostname, trying > to send mail to [EMAIL PROTECTED] leads to local delivery (sendmail -bt says > $# local for any [EMAIL PROTECTED]). Testing from any outer machine works > as expected, though. > > Setting nameserver to outer machine in /etc/resolv.conf fixes the > situation, though. But playing with ResolverOptions does not help. > > Moreover, although zone containing machine hostname looks just the same as > any other, mailing to it do *not* end up as local delivery. > > Any help will be greatly appreciated. I'll be glad to provide more > information if needed. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: alternate system clock has died
Fri, Jun 27, 2003 at 13:52:08, stijn (Stijn Hoop) wrote about "alternate system clock has died": SH> I'm getting the message in the subject when I run systat -vm on a lightly SH> loaded server. Top shows interesting CPU usage %: SH> CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle See LINT: # Notes on APM # The flags takes the following meaning for apm0: #0x0020 Statclock is broken. # If apm is omitted, some systems require sysctl -w kern.timecounter.method=1 # for correct timekeeping. This is possibly the first thing should be done seeing dead statclock. It was actual for SMP motherboards based on 440BX and similar chipsets. > Could this have to do > with the battery-backed CMOS clock? Yes, statclock is RTC interrupts, but even if battery is dead, interrupts should work. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
