Re: cvs commit: src/sys/kern kern_sig.c (fwd)
Steve Kargl wrote: On Tue, Aug 13, 2002 at 06:25:37PM -0700, Terry Lambert wrote: The patch that Tim posted, which is GPL'ed because of its origin, and therefore unusable exacept as a model, fixes the problem by blocking the signal delivery before the fork. Can you provide a non-GPL patch to assuage your repeated beratement of Tim? I'm not repeatedly berating him. I'm simply pointing out that the proposed patch has a license incompatbile with the source code. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
Terry Lambert wrote: Steve Kargl wrote: On Tue, Aug 13, 2002 at 06:25:37PM -0700, Terry Lambert wrote: The patch that Tim posted, which is GPL'ed because of its origin, and therefore unusable exacept as a model, fixes the problem by blocking the signal delivery before the fork. Can you provide a non-GPL patch to assuage your repeated beratement of Tim? I'm not repeatedly berating him. I'm simply pointing out that the proposed patch has a license incompatbile with the source code. As to your question about the patch, I'm using code that predates the PAM changes, and not running with the most recent set of KSE changes to the signal handling, so I don't have the problem. The simplest solution is to undo the things that happened between the time the problem started, and the time there wasn't a problem. IMO, it's the responsibility of the people who broke it to fix it, as the price for having the changes they made stay in the source tree. Making changes that break things you personally don't care about is not a workable model (also IMO). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
Tim Robbins wrote: On Tue, Aug 13, 2002 at 05:04:20PM -0700, Terry Lambert wrote: Both different reports have been from Tim Robbins. It may be that he has a local problem, and that his local problem is greatly confusing this discussion. Unfortunately, this is not a local problem -- I can reproduce it locally (i386, world/kernel from yesterday), on panther.freebsd.org (sparc64, kernel built July 19), and beast.freebsd.org (alpha, also built July 19). I cannot reproduce it on ref5 (i386, built July 1). If you update to the very most recent current, do the problems occur? It's currently August 13th, which means that you are a month behind on the machines with the problem, and a month and a half behind on the other. If both problems still occur with the most recent current, do they go away if you back out *just* the PAM changes? You haven't really done the necessary fault isolation needed to determine if there is a problem which was introduced by the KSE commit to the signal handling (and your July 19th date is too early for anyone to reasonably repeat your testing). It may be that something was broken and then fixed, and you do not have the fix simply because you are running old code. It's always possible to find the fix, even if you have to do a binary search of the source tree. For 32 days, we are talking log2(32)+1 or 6 builds, maximum, to find the commit that is the root cause of the behaviour you are seeing. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rcNG and dhcp
÷ Wed, 14.08.2002, × 09:34, Mike Makonnen ÎÁÐÉÓÁÌ: On Tue, 13 Aug 2002 20:36:39 +0400 Vladimir B. Grebenschikov [EMAIL PROTECTED] wrote: Yes, there is a simple solution: adjust the timeout in dhclient.conf. It is not solution - it is workaround - I do not wand any dhcp activity if I have no media (say in car) And dhclient in case of failure of detecting network address will install lask seen one, with last seen default gateway and I will get very long timeout while any of my apps will try to reach network instead of instant 'no route to host' Then, bring the interface down manually (it's even easier now that you can insert your own script in the rc boot process). I am not being flippant. Of course I can patch my rc.d/network1 manually or/and add number of smart scripts, but I simply wants to share solution with other people. Your suggestion, while it solves your problem, would create a problem for others (re-read the quote). Why it will create problems for others ? You need explicitly ask for feature: ifconfig_fxp0=dhcp-if-carrier if you will use old-style: ifconfig_fxp0=dhcp nothing will changed in dhcp behavior My personal opinion - best choice add key to dhclient - which do not ever try to send requests or record leases in case of no carrier on media and do not stop boot process in this case. Some times ago I have patch dhclient for this, but I am not satisfied with the patch, so do not send it to anybody. Cheers, Mike Makonnen -- Vladimir B. Grebenschikov [EMAIL PROTECTED], SWsoft, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bremfree: bp 0xc77938f4 not locked (Most recently used by kqueue)
Seth Hettich wrote: I get this all the time, and have for months now. On two different systems (both updated to -current about 2 times per month), both PCs (but with greatly differing HW). What would be my first step to resolve this? I sent in a PR, with lots of notes, things I tried, and stack dumps. I'm willing to do some more work on it, if someone can point me in the right direction. panic: bremfree: bp 0xc77938f4 not locked panic messages: --- panic: Most recently used by kqueue Having just finished documenting all of the kqueue code internals for my own use, I can tell you exactly where this problem lies. If you look at the kqueue code itself, in /sys/kern/kern_event.c, you will see the function knote(). The knote() function is conceptually very simple; it iterates the knote list hung off an object on which an event has just occurred, and calls the function kn-kn_fop-f_event(kn, hint). If you remember Julian's recent commit to the queue.h to make the list iterators unsafe to do removes in (OK, technically, he didn't make the change for that, it was just a very important undesirable side effect 8-)), you will understand the problem. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
oops: panic: bremfree: bp 0xc4206410 not locked
I got this while the system was swapping quite a bit (silly Gtk+ newsreader + supernews's huge retention == lots of memory used). FreeBSD blarf.homeip.net 5.0-CURRENT FreeBSD 5.0-CURRENT #5: Wed Aug 14 00:39:15 PDT 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ZIPPY_SMP_WITNESS i386 GNU gdb 5.2.0 (FreeBSD) 20020627 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: bremfree: bp 0xc4206410 not locked panic messages: --- panic: Most recently used by none cpuid = 0; lapic.id = syncing disks... panic: bremfree: bp 0xc4206410 not locked cpuid = 0; lapic.id = Uptime: 1h20m25s Dumping 127 MB ata0: resetting devices .. done 16 32 48 64 80 96 112[CTRL-C to abort] --- #0 doadump () at ../../../kern/kern_shutdown.c:213 213 dumping++; (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:213 #1 0xc022188d in boot (howto=260) at ../../../kern/kern_shutdown.c:345 #2 0xc0221aaf in panic () at ../../../kern/kern_shutdown.c:493 #3 0xc0255cf5 in bremfree (bp=0xc4206410) at ../../../kern/vfs_bio.c:633 #4 0xc025bc84 in cluster_wbuild (vp=0xc21beb90, size=8192, start_lbn=12, len=14) at ../../../kern/vfs_cluster.c:801 #5 0xc0257454 in vfs_bio_awrite (bp=0xc4206410) at ../../../kern/vfs_bio.c:1620 #6 0xc02e1a51 in ffs_fsync (ap=0xc8a6fb48) at ../../../ufs/ffs/ffs_vnops.c:231 #7 0xc02e104e in ffs_sync (mp=0xc1b1d600, waitfor=2, cred=0xc0bace80, td=0xc03ed9c0) at vnode_if.h:545 #8 0xc0265560 in sync (td=0xc03ed9c0, uap=0x0) at ../../../kern/vfs_syscalls.c:129 #9 0xc02214fa in boot (howto=256) at ../../../kern/kern_shutdown.c:254 #10 0xc0221aaf in panic () at ../../../kern/kern_shutdown.c:493 #11 0xc030210c in mtrash_ctor (mem=0xc2599400, size=0, arg=0x0) at ../../../vm/uma_dbg.c:135 #12 0xc0302178 in mtrash_fini (mem=0xc2599400, size=1024) at ../../../vm/uma_dbg.c:186 #13 0xc03003e5 in zone_drain (zone=0xc0b859c0) at ../../../vm/uma_core.c:646 #14 0xc0300d1b in zone_foreach (zfunc=0xc0300148 zone_drain) at ../../../vm/uma_core.c:1167 #15 0xc0301c5a in uma_reclaim () at ../../../vm/uma_core.c:1980 #16 0xc02fdb84 in vm_pageout_scan (pass=0) at ../../../vm/vm_pageout.c:653 #17 0xc02fe9b1 in vm_pageout () at ../../../vm/vm_pageout.c:1439 #18 0xc0212330 in fork_exit (callout=0xc02fe784 vm_pageout, arg=0x0, frame=0xc8a6fd48) at ../../../kern/kern_fork.c:872 (kgdb) quit To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
CFLAGS=-O and WARN=5
When I tried make world with CFLAGS=-g -pipe in make.conf, I got a result below. Is buildworld without CFLAGS=-O not supported? === bin/df cc -pipe -g -I/usr/src/bin/df/../../sbin/mount -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wuninitialized -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/bin/df/df.c cc1: warnings being treated as errors cc1: warning: -Wuninitialized is not supported without -O *** Error code 1 Stop in /usr/src/bin/df. *** Error code 1 -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CFLAGS=-O and WARN=5
Jun Kuriyama [EMAIL PROTECTED] 22 lines of wisdom included: When I tried make world with CFLAGS=-g -pipe in make.conf, I got a result below. Is buildworld without CFLAGS=-O not supported? === bin/df cc -pipe -g -I/usr/src/bin/df/../../sbin/mount -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wuninitialized -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/bin/df/df.c cc1: warnings being treated as errors cc1: warning: -Wuninitialized is not supported without -O *** Error code 1 The problem here, as is fairly self-evident is that you cannot compile with -Wuninitialized without a -O flag because it produces warnings that can only be seen through optomisation (it's got to do with automatic variables, see gcc(1) for details). See if this flag exists in /etc/defaults/make.conf, probably in BDECFLAGS, and remove it. Regards, -- Philip Reynolds | RFC Networks Ltd. [EMAIL PROTECTED] | +353 (0)1 8832063 http://people.rfc-networks.ie/~phil | www.rfc-networks.ie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
On Tue, Aug 13, 2002 at 11:54:06PM -0700, Terry Lambert wrote:
Tim Robbins wrote:
On Tue, Aug 13, 2002 at 05:04:20PM -0700, Terry Lambert wrote:
Both different reports have been from Tim Robbins. It may
be that he has a local problem, and that his local problem
is greatly confusing this discussion.
Unfortunately, this is not a local problem -- I can reproduce it locally
(i386, world/kernel from yesterday), on panther.freebsd.org (sparc64, kernel
built July 19), and beast.freebsd.org (alpha, also built July 19). I cannot
reproduce it on ref5 (i386, built July 1).
If you update to the very most recent current, do the problems
occur? It's currently August 13th, which means that you are a
month behind on the machines with the problem, and a month and
a half behind on the other.
The kernel/world I am running locally is less than 24 hours old.
If both problems still occur with the most recent current, do
they go away if you back out *just* the PAM changes?
This has nothing to do with PAM. Here is a simple program which behaves
differently between 4.6-RELEASE and 5.0-CURRENT. I don't know which
of the two behaviours is correct.
#include sys/types.h
#include sys/wait.h
#include err.h
#include stdio.h
#include signal.h
#include string.h
#include unistd.h
int
main(int argc, char *argv[])
{
pid_t pid;
int status;
switch (pid = vfork()) {
case -1:
err(1, fork);
case 0:
execl(/bin/csh, csh, NULL);
err(1, csh);
default:
fprintf(stderr, (waiter) waiting\n);
while (waitpid(pid, status, WUNTRACED) != -1 WIFSTOPPED(status)) {
fprintf(stderr, (waiter) stopping ourself\n);
killpg(0, SIGSTOP);
fprintf(stderr, (waiter) continuing child\n);
killpg(pid, SIGCONT);
fprintf(stderr, (waiter) waiting\n);
}
}
return (0);
}
%%
4.6.1-RELEASE-p10, OpenBSD 3.0:
%set prompt=root%
root% ./waiter
(waiter) waiting
%suspend
Suspended
root% fg
./waiter
%
5.0-CURRENT built August 14 (today):
%set prompt=root%
root% ./waiter
(waiter) waiting
%suspend
Suspended
root% fg
./waiter
%(waiter) stopping ourself
Suspended (signal)
root%
Linux behaves differently to both, but the change in behaviour does not
seem to make it stop working.
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === usr.bin/fstat In file included from /local0/scratch/des/src/usr.bin/fstat/fstat.c:67: /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include/ufs/ufs/quota.h:193: syntax error before ufs_quotactl *** Error code 1 Stop in /local0/scratch/des/src/usr.bin/fstat. *** Error code 1 Stop in /local0/scratch/des/src/usr.bin. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: I will be deliberately breaking the world tomorrow
- Forwarded message from Ruslan Ermilov [EMAIL PROTECTED] - Date: Tue, 13 Aug 2002 20:47:12 +0300 From: Ruslan Ermilov [EMAIL PROTECTED] To: David O'Brien [EMAIL PROTECTED], Bruce Evans [EMAIL PROTECTED], Kris Kennaway [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: GCC 3.1 hides warnings in system headers In-Reply-To: [EMAIL PROTECTED] User-Agent: Mutt/1.3.99i So gents (and ladies :-), what do we do about this? We had this change pre-3.1, and we have it in -STABLE now, so I assume we should no longer lie that our -CURRENT is so WARNS-clean? : -- : stage 4: building everything.. : -- : [...] : === games/grdc : cc -O -pipe-Werror -Wall -Wno-format-y2k -Wno-uninitialized -c :/CURRENT/usr/src/games/grdc/grdc.c : cc1: warnings being treated as errors : In file included from /usr/obj/CURRENT/usr/src/i386/usr/include/ncurses.h:112, : from /CURRENT/usr/src/games/grdc/grdc.c:15: : /usr/obj/CURRENT/usr/src/i386/usr/include/stdbool.h:41: warning: useless keyword or :type name in empty declaration : /usr/obj/CURRENT/usr/src/i386/usr/include/stdbool.h:41: warning: empty declaration : *** Error code 1 : : Stop in /CURRENT/usr/src/games/grdc. : *** Error code 1 On Thu, Aug 08, 2002 at 03:53:09PM +0300, Ruslan Ermilov wrote: On Tue, Jun 18, 2002 at 10:43:24PM -0700, David O'Brien wrote: On Wed, Jun 19, 2002 at 03:11:19PM +1000, Bruce Evans wrote: 1. you've forgotten *.295 will totally disappear soon (as in not even in the Attic, totally gone as if it never, ever existed). It shouldn't even have been cvs removed yet, since the -mprofiler-epilogue bits haven't been merged int gcc yet. All the commits to contrib/gcc.295 where committed into contrib/gcc before the 3.1 import. (that is not strictly true, as Kris's format hacks weren't, but he knew they would not be) What part of history is missing from contrib/gcc? Also, cccp.c,v 1.9 was not merged: : revision 1.9 : date: 2002/04/16 08:07:37; author: ru; state: Exp; lines: +2 -0 : Don't let gcc(1) hide warnings in system includes. : : Approved by:obrien Here's the long promised merge of the functionality. I would like to commit it soon if there are no objections. (This will take this file off its vendor branch.) %%% Index: c-lex.c === RCS file: /home/ncvs/src/contrib/gcc/c-lex.c,v retrieving revision 1.1.1.6 diff -u -p -r1.1.1.6 c-lex.c --- c-lex.c 13 May 2002 03:35:48 - 1.1.1.6 +++ c-lex.c 8 Aug 2002 12:48:18 - @@ -315,7 +315,11 @@ cb_file_change (pfile, new_map) } update_header_times (new_map-to_file); +#ifndef FREEBSD_NATIVE in_system_header = new_map-sysp != 0; +#else /* FREEBSD_NATIVE */ + in_system_header = 0; +#endif /* FREEBSD_NATIVE */ input_filename = new_map-to_file; lineno = to_line; map = new_map; %%% -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age - End forwarded message - msg41894/pgp0.pgp Description: PGP signature
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
There is a kernel change brewing that may change this On Wed, 14 Aug 2002, Tim Robbins wrote: This has nothing to do with PAM. Here is a simple program which behaves differently between 4.6-RELEASE and 5.0-CURRENT. I don't know which of the two behaviours is correct. [...] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_sig.c (fwd)
Tim Robbins wrote: This has nothing to do with PAM. Here is a simple program which behaves differently between 4.6-RELEASE and 5.0-CURRENT. I don't know which of the two behaviours is correct. [ ... ] If 4.6 disagrees with 5.0, then 5.0 is wrong (IMO), because a change was necessary for them to disagree. BTW: *This* is the bug that I was thinking about, Andrey... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: oops: panic: bremfree: bp 0xc4206410 not locked
I believe the more interesting panic to debug is the first one here in mtrash_ctor and not the problem with syncing the disk after a panic. I have seen a few other panics in this routine posted to current over the last few weeks. Jim Bloom [EMAIL PROTECTED] Alex Zepeda wrote: I got this while the system was swapping quite a bit (silly Gtk+ newsreader + supernews's huge retention == lots of memory used). FreeBSD blarf.homeip.net 5.0-CURRENT FreeBSD 5.0-CURRENT #5: Wed Aug 14 00:39:15 PDT 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ZIPPY_SMP_WITNESS i386 GNU gdb 5.2.0 (FreeBSD) 20020627 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: bremfree: bp 0xc4206410 not locked panic messages: --- panic: Most recently used by none cpuid = 0; lapic.id = syncing disks... panic: bremfree: bp 0xc4206410 not locked cpuid = 0; lapic.id = Uptime: 1h20m25s Dumping 127 MB ata0: resetting devices .. done 16 32 48 64 80 96 112[CTRL-C to abort] --- #0 doadump () at ../../../kern/kern_shutdown.c:213 213 dumping++; (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:213 #1 0xc022188d in boot (howto=260) at ../../../kern/kern_shutdown.c:345 #2 0xc0221aaf in panic () at ../../../kern/kern_shutdown.c:493 #3 0xc0255cf5 in bremfree (bp=0xc4206410) at ../../../kern/vfs_bio.c:633 #4 0xc025bc84 in cluster_wbuild (vp=0xc21beb90, size=8192, start_lbn=12, len=14) at ../../../kern/vfs_cluster.c:801 #5 0xc0257454 in vfs_bio_awrite (bp=0xc4206410) at ../../../kern/vfs_bio.c:1620 #6 0xc02e1a51 in ffs_fsync (ap=0xc8a6fb48) at ../../../ufs/ffs/ffs_vnops.c:231 #7 0xc02e104e in ffs_sync (mp=0xc1b1d600, waitfor=2, cred=0xc0bace80, td=0xc03ed9c0) at vnode_if.h:545 #8 0xc0265560 in sync (td=0xc03ed9c0, uap=0x0) at ../../../kern/vfs_syscalls.c:129 #9 0xc02214fa in boot (howto=256) at ../../../kern/kern_shutdown.c:254 #10 0xc0221aaf in panic () at ../../../kern/kern_shutdown.c:493 #11 0xc030210c in mtrash_ctor (mem=0xc2599400, size=0, arg=0x0) at ../../../vm/uma_dbg.c:135 #12 0xc0302178 in mtrash_fini (mem=0xc2599400, size=1024) at ../../../vm/uma_dbg.c:186 #13 0xc03003e5 in zone_drain (zone=0xc0b859c0) at ../../../vm/uma_core.c:646 #14 0xc0300d1b in zone_foreach (zfunc=0xc0300148 zone_drain) at ../../../vm/uma_core.c:1167 #15 0xc0301c5a in uma_reclaim () at ../../../vm/uma_core.c:1980 #16 0xc02fdb84 in vm_pageout_scan (pass=0) at ../../../vm/vm_pageout.c:653 #17 0xc02fe9b1 in vm_pageout () at ../../../vm/vm_pageout.c:1439 #18 0xc0212330 in fork_exit (callout=0xc02fe784 vm_pageout, arg=0x0, frame=0xc8a6fd48) at ../../../kern/kern_fork.c:872 (kgdb) quit 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
psm problem
Hi there, after make world of today: FreeBSD odin.garbe 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Wed Aug 14 19:36:08 CEST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ODIN i386 my mouse behaves sometimes curios (while moving around, some selections are done, without clicking)... Before making world I patched /sys/dev/drm with currentdrm-20020711.diff and nothing else. All scripts are up to date after running mergemaster -p (before make installworld) and running mergemaster after make installworld. I'll build world again at night without the currentdrm-20020711 patch. Maybe there's a side effect. See, what dmesg says: [...] psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 [...] psmintr: out of sync ( != 0008). psmintr: discard a byte (1). psmintr: out of sync ( != 0008). psmintr: discard a byte (2). psmintr: out of sync ( != 0008). psmintr: discard a byte (3). psmintr: out of sync ( != 0008). psmintr: re-enable the mouse. psmintr: delay too long; resetting byte count psmintr: out of sync ( != 0008). psmintr: discard a byte (1). psmintr: out of sync ( != 0008). psmintr: discard a byte (2). psmintr: out of sync ( != 0008). psmintr: discard a byte (3). psmintr: out of sync ( != 0008). psmintr: re-enable the mouse. psmintr: out of sync ( != 0008). psmintr: discard a byte (5). psmintr: out of sync ( != 0008). psmintr: discard a byte (6). psmintr: out of sync ( != 0008). psmintr: discard a byte (7). psmintr: out of sync ( != 0008). psmintr: discard a byte (8). psmintr: out of sync ( != 0008). psmintr: discard a byte (9). psmintr: out of sync ( != 0008). psmintr: discard a byte (10). psmintr: out of sync ( != 0008). psmintr: discard a byte (11). psmintr: out of sync ( != 0008). psmintr: discard a byte (12). psmintr: out of sync ( != 0008). psmintr: discard a byte (13). psmintr: out of sync ( != 0008). psmintr: discard a byte (14). psmintr: out of sync ( != 0008). psmintr: discard a byte (15). psmintr: out of sync ( != 0008). psmintr: discard a byte (16). psmintr: out of sync ( != 0008). psmintr: discard a byte (17). psmintr: out of sync ( != 0008). psmintr: discard a byte (18). psmintr: out of sync ( != 0008). psmintr: discard a byte (19). psmintr: out of sync ( != 0008). psmintr: reset the mouse. psmintr: delay too long; resetting byte count psmintr: out of sync ( != 0008). psmintr: discard a byte (1). psmintr: out of sync ( != 0008). psmintr: discard a byte (2). psmintr: out of sync ( != 0008). psmintr: discard a byte (3). psmintr: out of sync ( != 0008). psmintr: re-enable the mouse. psmintr: out of sync ( != 0008). psmintr: discard a byte (5). psmintr: out of sync ( != 0008). psmintr: discard a byte (6). psmintr: out of sync ( != 0008). psmintr: discard a byte (7). psmintr: out of sync ( != 0008). psmintr: discard a byte (8). psmintr: out of sync ( != 0008). psmintr: discard a byte (9). psmintr: out of sync ( != 0008). psmintr: discard a byte (10). psmintr: out of sync ( != 0008). psmintr: discard a byte (11). psmintr: out of sync ( != 0008). psmintr: discard a byte (12). psmintr: out of sync ( != 0008). psmintr: discard a byte (13). psmintr: out of sync ( != 0008). psmintr: discard a byte (14). psmintr: out of sync ( != 0008). psmintr: discard a byte (15). psmintr: out of sync ( != 0008). psmintr: discard a byte (16). psmintr: out of sync ( != 0008). psmintr: discard a byte (17). psmintr: out of sync ( != 0008). psmintr: discard a byte (18). psmintr: out of sync ( != 0008). psmintr: discard a byte (19). psmintr: out of sync ( != 0008). psmintr: reset the mouse. psmintr: out of sync ( != 0008). psmintr: discard a byte (1). psmintr: out of sync ( != 0008). psmintr: discard a byte (2). psmintr: out of sync ( != 0008). psmintr: discard a byte (3). psmintr: out of sync ( != 0008). psmintr: re-enable the mouse. psmintr: out of sync ( != 0008). psmintr: discard a byte (5). psmintr: out of sync ( != 0008). psmintr: discard a byte (6). psmintr: out of sync ( != 0008). psmintr: discard a byte (7). psmintr: out of sync ( != 0008). psmintr: discard a byte (8). psmintr: out of sync ( != 0008). psmintr: discard a byte (9). psmintr: out of sync ( != 0008). psmintr: discard a byte (10). psmintr: out of sync ( != 0008). psmintr: discard a byte (11). psmintr: out of sync ( != 0008). psmintr: discard a byte (12). psmintr: out of sync ( != 0008). psmintr: discard a byte (13). psmintr: delay too long; resetting byte count psmintr: out of sync ( != 0008). psmintr: discard a byte (1). psmintr: out of sync ( != 0008). psmintr: discard a byte (2). psmintr: out of sync ( != 0008). psmintr: discard a byte (3). psmintr: out of sync ( != 0008). psmintr: re-enable the mouse. psmintr: delay too long; resetting byte count psmintr: out of sync ( != 0008). psmintr:
OT: Debian GNU/FreeBSD???
I'm slightly offtopic with this, but what the heck is that: http://www.debian.org/ports/freebsd/index I was slightly irritated when a pal showed me that! -mg To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OT: Debian GNU/FreeBSD???
Mario Goebbels wrote: I'm slightly offtopic with this, but what the heck is that: Ontopic for -chat, and maybe -advocacy; perhaps you should pst there, instead... http://www.debian.org/ports/freebsd/index I was slightly irritated when a pal showed me that! Why? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OT: Debian GNU/FreeBSD???
http://www.debian.org/ports/freebsd/index I was slightly irritated when a pal showed me that! Why? I thought FreeBSD wants no distros to avoid all the distrochaos Linux got right now. Debian is rather contraproductive to that. Luckily it aint popular. -mg To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OT: Debian GNU/FreeBSD???
On Thu, Aug 15, 2002 at 12:51:49AM +0200, Mario Goebbels wrote: I'm slightly offtopic with this, but what the heck is that: http://www.debian.org/ports/freebsd/index I was slightly irritated when a pal showed me that! It's Debian people being silly. Someone decided they liked the FreeBSD kernel and the Debian way of doing userland and combined the two. As you can see from the webpage, it's not exactly popular (the site hasn't been updated in four months.) It's more or less legal and doesn't hurt anything. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg41903/pgp0.pgp Description: PGP signature
Re: OT: Debian GNU/FreeBSD???
Brooks Davis [EMAIL PROTECTED] wrote: On Thu, Aug 15, 2002 at 12:51:49AM +0200, Mario Goebbels wrote: I'm slightly offtopic with this, but what the heck is that: http://www.debian.org/ports/freebsd/index I was slightly irritated when a pal showed me that! It's Debian people being silly. Someone decided they liked the FreeBSD kernel and the Debian way of doing userland and combined the two. As you can see from the webpage, it's not exactly popular (the site hasn't been updated in four months.) There are a couple of Debian/BSD efforts going on at the moment, one based on FreeBSD and the other on NetBSD. There's only a couple of people working on each of them, and the principal FreeBSD guy is currently lacking development resources so not much progress is being made there. Both groups are having trouble reconciling the different functionality of glibc and BSD libc. They're planning to make both a part of the next major release of Debian, so it will be ported to N+3 kernels (Linux, Hurd, NetBSD, FreeBSD). Given the effectiveness of their release engineering, don't expect it to get anywhere near general usability for at least a year, and probably getting on for two. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ HUMBER THAMES DOVER: SOUTH OR SOUTHEAST 3 OR 4, OCCASIONALLY 5 IN HUMBER, BECOMING VARIABLE 3 LATER. MAINLY FAIR. MODERATE OR GOOD WITH FOG PATCHES. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: oops: panic: bremfree: bp 0xc4206410 not locked
On Wed, Aug 14, 2002 at 05:35:32PM -0400, Jim Bloom wrote: I believe the more interesting panic to debug is the first one here in mtrash_ctor and not the problem with syncing the disk after a panic. I have seen a few other panics in this routine posted to current over the last few weeks. Yes, this is the one that interests me as well. In fact I've got another dump with a strikingly similar backtrace (differnet panic messages tho). Is there anything useful I can do with the dumps, or are the backtraces helpful enough? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Weirdness trying -STABLE - -CURRENT
Warning: this is ~200 lines long. Sorry. I think the issue raised
is worth maybe 10% of the bandwidth, but
Date: Tue, 13 Aug 2002 18:33:33 +0200
From: Szilveszter Adam [EMAIL PROTECTED]
Thanks for getting back with the results. This points to the fatc that
the instructions in UPDATING should updated.
OK; folks -- after getting a great deal of encouragement from
Szilveszter Adam, I reviewed the transcripts from what I did a
little more carefully, and I believe that there is at least one
fundamental flaw in the present (as of rev. 1.214) /usr/src/UPDATING
instructions for the To upgrade from 4.x-stable to current section,
such that it cannot work as specified.
Further, I do not have a mechanism that I believe to exhibit
sufficiently predictable behavior as to be usable at this time. (In
other words, it seems to me that making this transition may well require
something that -- for lack of a better term -- I will call luck.)
I will intersperse editorial comments in among the lines from UPDATING
(which are indented by a tab):
To upgrade from 4.x-stable to current
-
make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
cp src/sys/${MACHINE_ARCH}/conf/GENERIC.hints /boot/device.hints [2]
make installkernel KERNCONF=YOUR_KERNEL_HERE
No problem up to here.
reboot in single user [3]
OK; here we have a fundamental problem, illustrated by the following
commands I issued just after the make installkernel:
freebeast(4.6-S)[3] grep '^kernel' /boot/defaults/loader.conf
kernel=/kernel
kernel_options=
freebeast(4.6-S)[4]
The clue that I had was reviewing the transcript, and when I did the
single-user boot, the system identified itself as 4.6-STABLE.
Now, if it is *intended* to actually boot -STABLE at this time, fine --
but that sure isn't the rationale that I've seen discussed.
In an effort, then, to find an appropriate circumvention, I tried:
freebeast(4.6-S)[4] pushd sys
freebeast(4.6-S)[5] make install
...
and after that:
freebeast(4.6-S)[6] !grep
grep '^kernel' /boot/defaults/loader.conf
kernel=kernel # /boot sub-directory containing kernel and modules
kernel_options=
freebeast(4.6-S)[7]
and *then* I tried the single-user reboot.
I was mildly gratified to see:
Hit [Enter] to boot immediately, or any other key for command prompt.
Type '?' for a list of commands, 'help' for more detailed help.
OK boot -s
/boot/kernel/acpi.ko text=0x2e27c data=0x1804+0x6e0 syms=[0x4+0x50b0+0x4+0x6913/
SMAP type=01 base= len= 0009fc00
SMAP type=01 base= 0009fc00 len= 0400
SMAP type=02 base= 000f len= 0001
SMAP type=02 base= fec0 len= 0140
SMAP type=01 base= 0010 len= 1fef
SMAP type=03 base= 1fff3000 len= d000
SMAP type=04 base= 1fff len= 3000
Copyright (c) 1992-2002 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 #0: Wed Aug 14 19:15:38 PDT 2002
[EMAIL PROTECTED]:/common/S3/obj/usr/src/sys/FREEBEAST
and I (foolishly, in retrospect) thought that I'd have something simple to
suggest that would fix the problem.
First significant hint that the ride was going to be bumpy was:
# mount -u /
WARNING: userland calling deprecated sysctl, please rebuild world
WARNING: userland calling deprecated sysctl, please rebuild world
WARNING: userland calling deprecated sysctl, please rebuild world
WARNING: userland calling deprecated sysctl, please rebuild world
WARNING: userland calling deprecated sysctl, please rebuild world
# mount
/dev/ad0s3a on / (ufs, local, soft-updates)
devfs on /dev (devfs, local)
#
This was repeated (quite a bit) with the mount -at ufs, but at least
the file systems got mounted. (Whew!) So we see:
# mount
/dev/ad0s3a on / (ufs, local, soft-updates)
devfs on /dev (devfs, local)
/dev/ad0s3e on /usr (ufs, local, soft-updates)
/dev/ad0s4h on /common (ufs, local)
/dev/ad0s4g on /var (ufs, local)
# cd /usr/src
# date adjkerntz -i date
Wed Aug 14 12:39:10 PDT 2002
Wed Aug 14 12:39:10 PDT 2002
# echo The time is 7 hrs. off -- and I'm 7 hrs. west of GMT.
The time is 7 hrs. off -- and I'm 7 hrs. west of GMT.
Continuing with the instructions from UPDATING, we see:
mergemaster -p [5]
make installworld
OK:
# mergemaster -p
...
Continuing, then:
# make installworld
make: no target to make.
/usr/src/Makefile.inc1, line 140: warning: make -f /dev/null -m /usr/src/share/mk
CPUTYPE=i386 -V CPUTYPE returned non-zero status
mkdir -p /tmp/install.oA6Pxyei
...
and things progressed for a while. But then:
/usr/share/nls/it_IT.ISO8859-15/tcsh.cat - ../it_IT.ISO8859-1/tcsh.cat
/usr/share/nls/es_ES.ISO8859-15/tcsh.cat - ../es_ES.ISO8859-1/tcsh.cat
=== bin/rmail
install -s -o root -g wheel
Re: Weirdness trying -STABLE - -CURRENT
I upgraded a machine from 4.6R to -CURRENT today and had similar
problems. Comments below.
On Wed, 14 Aug 2002, David Wolfskill wrote:
To upgrade from 4.x-stable to current
-
make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
cp src/sys/${MACHINE_ARCH}/conf/GENERIC.hints /boot/device.hints [2]
make installkernel KERNCONF=YOUR_KERNEL_HERE
No problem up to here.
Same.
reboot in single user [3]
OK; here we have a fundamental problem, illustrated by the following
commands I issued just after the make installkernel:
freebeast(4.6-S)[3] grep '^kernel' /boot/defaults/loader.conf
kernel=/kernel
kernel_options=
freebeast(4.6-S)[4]
The clue that I had was reviewing the transcript, and when I did the
single-user boot, the system identified itself as 4.6-STABLE.
This happened to me too. Perhaps the instructions should say to unload
kernel; load /boot/kernel/kernel on reboot or maybe explicitly copy in the
new /boot/defaults/loader.conf like you do with device.hints?
I didn't notice the 4.6 dmesg while booting so I went through the make
installworld using the 4.6 kernel. It got to chpass and then failed with
a sig 11. It turned out part of the chpass install uses chflags and I
believe the syscall changed between 4.6R and current.
I rebooted at that point since things couldn't continue in the
installworld and the new kernel's ACPI blew major chunks (endless loop).
So I booted my stable partition, did another buildkernel/installkernel on
the -current partition and then rebooted. ACPI paniced but I was able to
boot the new kernel by disabling ACPI (separate message on this).
After booting the -current kernel, mergemaster and installworld worked
just fine. My system was running fine when I went home tonight.
# sync
# which grep
Out of memory!
pid 3263 (perl), uid 0: exited on signal 11 (core dumped)
[1] 3263 Segmentation fault (core dumped) which grep
# reboot
I was able to perform another single-user reboot, but successive attempts
to make installworld died with the out of memory symptom.
mergemaster [4]
[1]
reboot
I wasn't able to get as far as completing the make installworld -- I tried
with -k once; that didn't seem to help, either.
So -- at some point I think this needs to be figured out.
I'll be happy to poke around and test.
I didn't get any out of memory errors, just repeatable sig 11 when running
chflags.
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
panic: system call accept returning with mutex(s) held
With -current from earlier this week, panics whenever I start
gaim. Didn't see anything similar in the archives. I'll be happy to
provide more information if needed.
Mounting root from ufs:/dev/ad0s2a
exclusive sleep mutex Giant r = 0 (0xc02da9a0) locked @ ../../../kern/subr_trap.c:80
panic: system call accept returning with mutex(s) held
syncing disks... panic: bremfree: bp 0xc3c32ee4 not locked
Uptime: 3m18s
pfs_vncache_unload(): 1 entries remaining
Dumping 127 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc01aaa86 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc01aaca3 in panic () at ../../../kern/kern_shutdown.c:493
#3 0xc01dfc47 in bremfree (bp=0xc02b0f05) at ../../../kern/vfs_bio.c:633
#4 0xc01e1668 in vfs_bio_awrite (bp=0xc1525840) at ../../../kern/vfs_bio.c:1627
#5 0xc022e991 in ffs_fsync (ap=0xc8e7bc1c) at ../../../ufs/ffs/ffs_vnops.c:231
#6 0xc022df8e in ffs_sync (mp=0xc1471400, waitfor=2, cred=0xc0babe00, td=0xc02d6480)
at vnode_if.h:545
#7 0xc01f162c in sync (td=0xc02d6480, uap=0x0) at ../../../kern/vfs_syscalls.c:129
#8 0xc01aa6a2 in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#9 0xc01aaca3 in panic () at ../../../kern/kern_shutdown.c:493
#10 0xc027d8a2 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135554112, tf_esi = 135604464,
tf_ebp = -1077940868, tf_isp = -924336780, tf_ebx = 673945180, tf_edx = 1, tf_ecx = 0,
tf_eax = 22, tf_trapno = 12, tf_err = 2, tf_eip = 676290179, tf_cs = 31, tf_eflags =
663, tf_esp = -1077941024, tf_ss = 47}) at ../../../i386/i386/trap.c:1120
#11 0xc026e76d in Xint0x80_syscall () at {standard input}:140
FreeBSD 5.0-CURRENT #1: Wed Aug 14 12:19:54 EDT 2002
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/SATELLIT
E
Preloaded elf kernel /boot/kernel/kernel at 0xc03ff000.
Preloaded elf module /boot/kernel/random.ko at 0xc03ff0a8.
Preloaded elf module /boot/kernel/acpi.ko at 0xc03ff154.
Timecounter i8254 frequency 1193182 Hz
Timecounter TSC frequency 746339059 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (746.34-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x686 Stepping = 6
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA
T,PSE36,MMX,FXSR,SSE
real memory = 134086656 (130944K bytes)
avail memory = 125779968 (122832K bytes)
Mike
--
Mike Heffner mheffner@[acm.]vt.edu
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
