network problems on -current ?
Hi, An -current (cvsupped yesterday) has some unusual problems, connection resets from local sendmail, or something like this: # ktrace uname -a FreeBSD lolo.freibergnet.de 5.0-CURRENT FreeBSD 5.0-CURRENT #7: Wed Mar 12 22:29:49 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LOLO i386 # ktrace uname -a FreeBSD lolo.freibergnet.de 5.0-CURRENT FreeBSD 5.0-CURRENT #7: Wed Mar 12 22:29:49 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LOLO i386 # ktrace uname -a FreeBSD lolo.freibergnet.de 5.0-CURRENT FreeBSD 5.0-CURRENT #7: Wed Mar 12 22:29:49 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LOLO i386 # ktrace uname -a FreeBSD lolo.freibergnet.de 5.0-CURRENT FreeBSD 5.0-CURRENT #7: Wed Mar 12 22:29:49 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LOLO i386 # ktrace uname -a FreeBSD lolo.freibergnet.de 5.0-CURRENT FreeBSD 5.0-CURRENT #7: Wed Mar 12 22:29:49 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LOLO i386 # uname -a Read from remote host lolo.freiberg-net.de: Connection reset by peer Connection to lolo.freiberg-net.de closed. Without a ktrace uname stalls and after a few seconds the connection is reset. With ktrace, there is'nt anything interresting in the trace, the cmd is working. I'am the only lucky one ? Holm -- FreibergNet Systemhaus GbR Holm Tiffe * Administration, Development Systemhaus für Daten- und Netzwerktechnik phone +49 3731 781279 Unternehmensgruppe Liebscher Partnerfax +49 3731 781377 D-09599 Freiberg * Am St. Niclas Schacht 13 http://www.freibergnet.de To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kern/49079: panic: bwrite: buffer is not busy
On Tue, 11 Mar 2003, Doug Barton wrote: FYI, -bugs is not a discussion list. On Tue, 11 Mar 2003, Attila Nagy wrote: The following reply was made to PR kern/49079; it has been noted by GNATS. From: Attila Nagy [EMAIL PROTECTED] To: Martin Machacek [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: kern/49079: panic: bwrite: buffer is not busy Date: Tue, 11 Mar 2003 10:30:17 +0100 (CET) Hello, The system panics with panic: bwrite: buffer is not busy after random time after boot if X server is running (although this is not verified to Fix: Would love to have one :-). CURRENT already has a fix, in rev. 1.373 of vfs_bio.c Could you please try to update to -CURRENT to see if this problem disappears? It won't. I have 1.376 of vfs_bio.c, and -current as of the 7th, and I just got another one of these last night. The panic message is the same as I've been getting, but the bremfree message is slightly different, if that helps any. Can anyone tell me when this started? Or perhaps backup your sources until this goes away? I am not able to reproduce this. Can you give me the following information. Type of machine, cpu, memory, etc. Mounted filesystems and their block size. Type of workload. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: lock order reversal? current with tl ethernet
On Wed, 12 Mar 2003, John Baldwin wrote:
It's holding the lock across bus_setup_intr(). You can try the
following patch:
Index: if_tl.c
===
RCS file: /usr/cvs/src/sys/pci/if_tl.c,v
retrieving revision 1.74
diff -u -r1.74 if_tl.c
--- if_tl.c 19 Feb 2003 05:47:41 - 1.74
+++ if_tl.c 12 Mar 2003 15:20:47 -
@@ -1138,12 +1138,11 @@
if (t-tl_name == NULL) {
device_printf(dev, unknown device!?\n);
- goto fail;
device_printf(dev, unknown device!?\n);
- goto fail;
RCS file: /usr/cvs/src/sys/pci/if_tl.c,v
retrieving revision 1.74
diff -u -r1.74 if_tl.c
--- if_tl.c 19 Feb 2003 05:47:41 - 1.74
+++ if_tl.c 12 Mar 2003 15:20:47 -
@@ -1138,12 +1138,11 @@
if (t-tl_name == NULL) {
device_printf(dev, unknown device!?\n);
- goto fail;
+ return (ENXIO);
}
mtx_init(sc-tl_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK,
MTX_DEF | MTX_RECURSE);
- TL_LOCK(sc);
/*
* Map control/status registers.
@@ -1348,12 +1347,12 @@
/*
* Call MI attach routine.
*/
Thanks John --
This patch looks a little bit mangled to me. It has two sections talking
about line 1138 of if_tl.c (with two different changes) and a section
talking about line 1348 (with no changes).
I assumed cut and paste error and proceeded along the same lines with this
patch instead:
Index: if_tl.c
===
RCS file: /usr/src/cvs-repo/src/sys/pci/if_tl.c,v
retrieving revision 1.74
diff -u -r1.74 if_tl.c
--- if_tl.c 19 Feb 2003 05:47:41 - 1.74
+++ if_tl.c 13 Mar 2003 00:26:20 -
@@ -1138,12 +1138,11 @@
if (t-tl_name == NULL) {
device_printf(dev, unknown device!?\n);
- goto fail;
+ return (ENXIO);
}
mtx_init(sc-tl_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK,
MTX_DEF | MTX_RECURSE);
- TL_LOCK(sc);
/*
* Map control/status registers.
@@ -1349,11 +1348,9 @@
* Call MI attach routine.
*/
ether_ifattach(ifp, sc-arpcom.ac_enaddr);
- TL_UNLOCK(sc);
return(0);
fail:
- TL_UNLOCK(sc);
mtx_destroy(sc-tl_mtx);
return(error);
}
This has made the messages go away -- thanks for that! If this is a
correct fix, should I submit a PR to have it committed?
--
Tod McQuillin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
INVARIANTS hide bugs (malloc/uma related)? (was: Re: latest working snapshot?)
On Wed, Mar 12, 2003 at 10:32:01PM +0200, Ruslan Ermilov wrote: On Wed, Mar 12, 2003 at 02:14:25PM -0500, Andrew Gallatin wrote: I need to install current on a new box that just arrived. What's the latest working snapshot? 20030312-JPSNAP get about 40% of the way through the base install and sysinstall complains about a bad realloc, and lets me hit a key to reboot ;-( You're just lucky. Mine just panics. OK, I've tracked it down to the following. Kernels _without_ ``options INVARIANTS'' exhibit random panics, most often right after launching the init(8) process (or sysinstall(8), if this is an installation). Depending on the kernel layout (I think), I saw later panics when attempting to mount /proc, or just hanging kernel. The attached kernel config, which is derivative of the BOOTMFS i386 kernel which we use during installation, is such example. It took me a while to track the problem down to a single file, and it turned out that compiling kern/kern_malloc.c with INVARIANTS is enough to keep the system running. Precisely, this change did the trick: %%% Index: kern_malloc.c === RCS file: /home/ncvs/src/sys/kern/kern_malloc.c,v retrieving revision 1.119 diff -u -p -r1.119 kern_malloc.c --- kern_malloc.c 10 Mar 2003 20:24:54 - 1.119 +++ kern_malloc.c 13 Mar 2003 00:53:47 - @@ -429,7 +429,7 @@ kmeminit(dummy) char *name = kmemzones[indx].kz_name; kmemzones[indx].kz_zone = uma_zcreate(name, size, -#ifdef INVARIANTS +#if 1 mtrash_ctor, mtrash_dtor, mtrash_init, mtrash_fini, #else NULL, NULL, NULL, NULL, %%% Cheers, -- 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 machine i386 cpu I686_CPU ident BOOTMFS options SCHED_4BSD options INET options FFS options COMPAT_43 #optionsINVARIANTS options INVARIANT_SUPPORT device isa device pci device fdc device ata device atadisk device atapicd options ATA_STATIC_ID device atkbdc device atkbd device psm device vga device sc device npx device loop device ether options NO_COMPAT_FREEBSD4 pgp0.pgp Description: PGP signature
Re: big file became broken on 2003-03-11(cvsuped)
On Thu, 13 Mar 2003 01:23:00 -0500 (EST) Jeff Roberson [EMAIL PROTECTED] wrote: How much memory is in your machine? Can you go back to an earlier date and see if this is still a problem? Are you doing anything else with the machine while this is going on? 512MB. I used snapshots install image from snapshots.jp.freebsd.org, and installed on 3/8. And, I updated to now version on 3/11. There are no problem while using 3/8 version. Yes, I am making java/jdk14 and make world:-) (for heavy load). But, even if I only made ja-openoffice, there was this problem. Also, can you do 'sysctl vfs.read_max=0' and retest? OK! But not good. But more robust. At least my machine don't freeze, yet:-). Thanks! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (snip) Thu Mar 13 15:47:59 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 8a82b4dbdd4e305b6f6db70ea65dce8c Thu Mar 13 15:48:13 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 8a82b4dbdd4e305b6f6db70ea65dce8c Thu Mar 13 15:48:32 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 0b4e6ca19c5127a70bb60de149cfedde Thu Mar 13 15:49:54 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 8a82b4dbdd4e305b6f6db70ea65dce8c Thu Mar 13 15:51:33 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 5960c5ab9820cf928e04499012255f67 Thu Mar 13 15:56:15 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = a0f24a11305b601238a6ed277ce7b24d Thu Mar 13 15:58:10 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = a0f24a11305b601238a6ed277ce7b24d (snip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: big file became broken on 2003-03-11(cvsuped)
On Thu, 13 Mar 2003, Norikatsu Shigemura wrote: On Thu, 13 Mar 2003 01:23:00 -0500 (EST) Jeff Roberson [EMAIL PROTECTED] wrote: How much memory is in your machine? Can you go back to an earlier date and see if this is still a problem? Are you doing anything else with the machine while this is going on? 512MB. I used snapshots install image from snapshots.jp.freebsd.org, and installed on 3/8. And, I updated to now version on 3/11. There are no problem while using 3/8 version. Yes, I am making java/jdk14 and make world:-) (for heavy load). But, even if I only made ja-openoffice, there was this problem. Also, can you do 'sysctl vfs.read_max=0' and retest? OK! But not good. But more robust. At least my machine don't freeze, yet:-). Does your machine log ECC errors? If so can you check for them in the BIOS? If you don't make world and jdk14 does this problem still show up? (snip) Thu Mar 13 15:47:59 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 8a82b4dbdd4e305b6f6db70ea65dce8c Thu Mar 13 15:48:13 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 8a82b4dbdd4e305b6f6db70ea65dce8c Thu Mar 13 15:48:32 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 0b4e6ca19c5127a70bb60de149cfedde Thu Mar 13 15:49:54 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 8a82b4dbdd4e305b6f6db70ea65dce8c Thu Mar 13 15:51:33 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 5960c5ab9820cf928e04499012255f67 Thu Mar 13 15:56:15 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = a0f24a11305b601238a6ed277ce7b24d Thu Mar 13 15:58:10 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = a0f24a11305b601238a6ed277ce7b24d (snip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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
stacktrace of recent panic..(bremfree)
I got this today on a kernel checked out on the 10th.
panic: bremfree: removing a buffer not on a queue
panic messages:
---
panic: bwrite: buffer is not busy???
syncing disks, buffers remaining... panic: bremfree: removing a buffer
not on a queue
Uptime: 46m53s
Dumping 255 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at ../../../kern/kern_shutdown.c:239
239 dumping++;
(kgdb)
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:239
#1 0xc020e1ba in boot (howto=260) at ../../../kern/kern_shutdown.c:371
#2 0xc020e423 in panic () at ../../../kern/kern_shutdown.c:542
#3 0xc024d130 in bremfreel (bp=0xc6920078) at
../../../kern/vfs_bio.c:630
#4 0xc024d042 in bremfree (bp=0x0) at ../../../kern/vfs_bio.c:612
#5 0xc024f0e0 in vfs_bio_awrite (bp=0x0) at
../../../kern/vfs_bio.c:1682
#6 0xc02dfe5a in ffs_fsync (ap=0xcc06b8b8) at
../../../ufs/ffs/ffs_vnops.c:257
#7 0xc02def67 in ffs_sync (mp=0xc17e7400, waitfor=2, cred=0xc0eb5e00,
td=0xc03b31e0) at vnode_if.h:612
#8 0xc0263f1b in sync (td=0xc03b31e0, uap=0x0)
at ../../../kern/vfs_syscalls.c:138
#9 0xc020dd7c in boot (howto=256) at ../../../kern/kern_shutdown.c:280
#10 0xc020e423 in panic () at ../../../kern/kern_shutdown.c:542
#11 0xc024d5b2 in bwrite (bp=0xc68839f8) at ../../../kern/vfs_bio.c:795
#12 0xc024df2c in bawrite (bp=0x0) at ../../../kern/vfs_bio.c:1138
#13 0xc0255f0f in cluster_wbuild (vp=0xc1c206d8, size=8192, start_lbn=2,
len=4)
at ../../../kern/vfs_cluster.c:996
#14 0xc025550f in cluster_write (bp=0xc6920078, filesize=49152,
seqcount=10)
at ../../../kern/vfs_cluster.c:596
#15 0xc02e0a7c in ffs_write (ap=0xcc06bbc4) at
../../../ufs/ffs/ffs_vnops.c:728
#16 0xc026c1e1 in vn_write (fp=0xc1b4f078, uio=0xcc06bc70,
active_cred=0xc1bc0e00, flags=0, td=0xc17d0a50) at vnode_if.h:417
#17 0xc02312c8 in dofilewrite (td=0xc17d0a50, fp=0xc1b4f078, fd=0,
buf=0x896fc00, nbyte=0, offset=0, flags=0) at file.h:239
#18 0xc0231109 in write (td=0xc17d0a50, uap=0xcc06bd10)
at ../../../kern/sys_generic.c:329
#19 0xc033c46a in syscall (frame=
{tf_fs = 677314607, tf_es = 47, tf_ds = -1078001617, tf_edi =
677351712, tf_esi = 0, tf_ebp = -1077941192, tf_isp = -871973516, tf_ebx
= 677363940, tf_edx = 20, tf_ecx = 0, tf_eax = 4, tf_trapno = 0, tf_err
= 2, tf_eip = 677698275, tf_cs = 31, tf_eflags = 518, tf_esp =
-1077941252, tf_ss = 47})
at ../../../i386/i386/trap.c:1030
#20 0xc032bafd in Xint0x80_syscall () at {standard input}:138
---Can't read userspace from dump, or kernel process---
I still have the kernel.debug and the coredump if anyone wants to look
further..
(am recompiling new kernel now. will see if it happens again)
(ata disk, ufs1 filesystem)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: big file became broken on 2003-03-11(cvsuped)
On Thu, 13 Mar 2003, Norikatsu Shigemura wrote: (snip) Thu Mar 13 15:47:59 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 8a82b4dbdd4e305b6f6db70ea65dce8c Thu Mar 13 15:48:13 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 8a82b4dbdd4e305b6f6db70ea65dce8c Thu Mar 13 15:48:32 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 0b4e6ca19c5127a70bb60de149cfedde Thu Mar 13 15:49:54 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 8a82b4dbdd4e305b6f6db70ea65dce8c Thu Mar 13 15:51:33 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 5960c5ab9820cf928e04499012255f67 Thu Mar 13 15:56:15 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = a0f24a11305b601238a6ed277ce7b24d Thu Mar 13 15:58:10 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = a0f24a11305b601238a6ed277ce7b24d (snip) We had a similar problem some time ago that turned out to be bad RAM in one case and a bad CMOS BIOS setting in another. (RAM speed setting). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stacktrace of recent panic..(bremfree)
On Thu, 13 Mar 2003, Julian Elischer wrote:
I got this today on a kernel checked out on the 10th.
Can you please disable sync on panic and get a dump from the first panic?
Then print out the contents of the buf in that stack for me? A couple of
people have seen this now but I have not been able to repro it.
Thanks,
Jeff
panic: bremfree: removing a buffer not on a queue
panic messages:
---
panic: bwrite: buffer is not busy???
syncing disks, buffers remaining... panic: bremfree: removing a buffer
not on a queue
Uptime: 46m53s
Dumping 255 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at ../../../kern/kern_shutdown.c:239
239 dumping++;
(kgdb)
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:239
#1 0xc020e1ba in boot (howto=260) at ../../../kern/kern_shutdown.c:371
#2 0xc020e423 in panic () at ../../../kern/kern_shutdown.c:542
#3 0xc024d130 in bremfreel (bp=0xc6920078) at
../../../kern/vfs_bio.c:630
#4 0xc024d042 in bremfree (bp=0x0) at ../../../kern/vfs_bio.c:612
#5 0xc024f0e0 in vfs_bio_awrite (bp=0x0) at
../../../kern/vfs_bio.c:1682
#6 0xc02dfe5a in ffs_fsync (ap=0xcc06b8b8) at
../../../ufs/ffs/ffs_vnops.c:257
#7 0xc02def67 in ffs_sync (mp=0xc17e7400, waitfor=2, cred=0xc0eb5e00,
td=0xc03b31e0) at vnode_if.h:612
#8 0xc0263f1b in sync (td=0xc03b31e0, uap=0x0)
at ../../../kern/vfs_syscalls.c:138
#9 0xc020dd7c in boot (howto=256) at ../../../kern/kern_shutdown.c:280
#10 0xc020e423 in panic () at ../../../kern/kern_shutdown.c:542
#11 0xc024d5b2 in bwrite (bp=0xc68839f8) at ../../../kern/vfs_bio.c:795
#12 0xc024df2c in bawrite (bp=0x0) at ../../../kern/vfs_bio.c:1138
#13 0xc0255f0f in cluster_wbuild (vp=0xc1c206d8, size=8192, start_lbn=2,
len=4)
at ../../../kern/vfs_cluster.c:996
#14 0xc025550f in cluster_write (bp=0xc6920078, filesize=49152,
seqcount=10)
at ../../../kern/vfs_cluster.c:596
#15 0xc02e0a7c in ffs_write (ap=0xcc06bbc4) at
../../../ufs/ffs/ffs_vnops.c:728
#16 0xc026c1e1 in vn_write (fp=0xc1b4f078, uio=0xcc06bc70,
active_cred=0xc1bc0e00, flags=0, td=0xc17d0a50) at vnode_if.h:417
#17 0xc02312c8 in dofilewrite (td=0xc17d0a50, fp=0xc1b4f078, fd=0,
buf=0x896fc00, nbyte=0, offset=0, flags=0) at file.h:239
#18 0xc0231109 in write (td=0xc17d0a50, uap=0xcc06bd10)
at ../../../kern/sys_generic.c:329
#19 0xc033c46a in syscall (frame=
{tf_fs = 677314607, tf_es = 47, tf_ds = -1078001617, tf_edi =
677351712, tf_esi = 0, tf_ebp = -1077941192, tf_isp = -871973516, tf_ebx
= 677363940, tf_edx = 20, tf_ecx = 0, tf_eax = 4, tf_trapno = 0, tf_err
= 2, tf_eip = 677698275, tf_cs = 31, tf_eflags = 518, tf_esp =
-1077941252, tf_ss = 47})
at ../../../i386/i386/trap.c:1030
#20 0xc032bafd in Xint0x80_syscall () at {standard input}:138
---Can't read userspace from dump, or kernel process---
I still have the kernel.debug and the coredump if anyone wants to look
further..
(am recompiling new kernel now. will see if it happens again)
(ata disk, ufs1 filesystem)
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
Re: big file became broken on 2003-03-11(cvsuped)
On Thu, 13 Mar 2003 03:36:41 -0500 (EST) Jeff Roberson [EMAIL PROTECTED] wrote: Does your machine log ECC errors? If so can you check for them in the BIOS? If you don't make world and jdk14 does this problem still show up? My machine uses non-ECC unbuffered DDR SDRAM(Transcend - Samsung chips, this is not bulk memory:-). I already thinked memory problem and checked memory (using Ram Stress Test like memtest86). But according to result of 3 hours test, memory is OK. I tested to make only ja-openoffice on single user mode. But there is this problem... (T_T) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: big file became broken on 2003-03-11(cvsuped)
On Thu, 13 Mar 2003 00:41:37 -0800 (PST) Julian Elischer [EMAIL PROTECTED] wrote: We had a similar problem some time ago that turned out to be bad RAM in one case and a bad CMOS BIOS setting in another. (RAM speed setting). RAM speed setting! Ah, I don't test it yet. I'll change speed setting and test. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: big file became broken on 2003-03-11(cvsuped)
On Thu, 13 Mar 2003 18:08:01 +0900 Norikatsu Shigemura [EMAIL PROTECTED] wrote: RAM speed setting! Ah, I don't test it yet. I'll change speed setting and test. I seted FastCommand: normal from ultra on `Configure SDRAM Timing by, FastCommand'. More robust and reduce problem. I'll check other parameter. I wounder if I'm sorry.? :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: crash: bwrite: need chained iodone
Le 2003-03-12, Jeff Roberson écrivait : Can you disable sync on panic to make sure that something has not come along and cleaned this buffer? I suspect that it has been modified after the first panic. Do you know when this first started to happen? Do you have any more clues into what triggered it? I have now disabled sync_on_panic for future crashes :) I did not see this crash before I upgraded from 5.0-REL to -CURRENT last weekend (I previously had panics consecutive to vm_page_wakeup being called with a NULL argument, which is why I upgraded). I have little idea as to what exactly might have caused the crash. I was using the machine for desktop work (a few rxvts, xemacs, xchat, so on, with the Nvidia driver with Maxime's patches). Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
if_dc warning messages
I've cvsuped to -current from 11-12 march and afer booting new kernel got repeated messages from kernel to syslog and console. Mar 13 13:50:38 ws-ilmar kernel: malloc() of 128 with the following non-sleepablelocks held: Mar 13 13:50:38 ws-ilmar kernel: exclusive sleep mutex dc0 (network driver) r = 0 (0xc18637bc) locked @ pci/if_dc.c:3034 How to get rid of them and would it be fixed? Thanx. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MAKEDEV lost in 5.0-CURRENT?
On Wed, Mar 12, 2003 at 12:18:08PM -0500, Hiten Pandya wrote: Hartmann, O. (Wed, Mar 12, 2003 at 04:59:52PM +0100) wrote: On Wed, 12 Mar 2003, Sergey A. Osokin wrote: [...] All right, a new 'think another way when going to FreeBSD 5.0 ...'. It also helps when you read src/UPDATING :-) NODEVFS option has been removed and DEVFS thereby made standard. This makes all references to MAKEDEV obsolete, and they should be removed when convenient. On 5.0-RELEASE-p4 I have /usr/src/etc/MAKEDEV and i use it for making the devices in jails. Is there a jail devfs or is the way described in the jail(8) man page still the right(tm) one? Andy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MAKEDEV lost in 5.0-CURRENT?
In message [EMAIL PROTECTED], Andy writes: On Wed, Mar 12, 2003 at 12:18:08PM -0500, Hiten Pandya wrote: Hartmann, O. (Wed, Mar 12, 2003 at 04:59:52PM +0100) wrote: On Wed, 12 Mar 2003, Sergey A. Osokin wrote: [...] All right, a new 'think another way when going to FreeBSD 5.0 ...'. It also helps when you read src/UPDATING :-) NODEVFS option has been removed and DEVFS thereby made standard. This makes all references to MAKEDEV obsolete, and they should be removed when convenient. On 5.0-RELEASE-p4 I have /usr/src/etc/MAKEDEV and i use it for making the devices in jails. Is there a jail devfs or is the way described in the jail(8) man page still the right(tm) one? See devfs(8) -- 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
Re: MAKEDEV lost in 5.0-CURRENT?
Hello, On 5.0-RELEASE-p4 I have /usr/src/etc/MAKEDEV and i use it for making the devices in jails. Is there a jail devfs or is the way described in the jail(8) man page still the right(tm) one? You can mount devfs into any places. For example a jail. BTW, take extreme care, when doing this, because if you don't set up devfs rules, anybody, who can become root in any jails can do things, which will irreversibly change your day. (reinstall/restore from backup) Hint: cp /dev/null /dev/[what is your root device outside the jail] BTW, it would be good to have an ipf.rules like file to set up those devfs rules. :) --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MAKEDEV lost in 5.0-CURRENT?
Hello, Hint: cp /dev/null /dev/[what is your root device outside the jail] I meant /dev/zero of course ;) (or /dev/random for the patient one) --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mbuf cache
Terry Lambert wrote: Ah. You are receiver livelocked. Try enabling polling; it will help up to the first stall barrier (NETISR not getting a chance to run protocol processing to completion because of interrupt overhead); there are two other stall barriers after that, and another in user space is possible depending on whether the application layer is request/response. Are you sure that polling would help even since the em driver is using interrupt regulation by default? It might solve the livelock but it does probably not increase the performance of the mbuf allocator? Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Just for Your Information
Hi lads and lassies, I just tried to do a build world that failed, so I tried re-running it and it told me directory not empty (/usr/obj/usr/src/i386*)...Funny, even though the first thing it does is an rm -rf of that directory... So I tried to do it manually (of course as root), but nada. Told me that the directory was not empty (rm -rf telling me THAT???) Solution was to go into single user mode and rm -rf, but is this normal behavior? I mean, there were no files in the tree, just directories...Any info would be welcomed. This was with a CVSUP of about 2 hours ago... Anthony Carter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Just for Your Information
CARTER Anthony wrote: Hi lads and lassies, I just tried to do a build world that failed, so I tried re-running it and it told me directory not empty (/usr/obj/usr/src/i386*)...Funny, even though the first thing it does is an rm -rf of that directory... So I tried to do it manually (of course as root), but nada. Told me that the directory was not empty (rm -rf telling me THAT???) I can't be certain, but I think I've seen that behavior in the past when I had a corrupt filesystem. Does fsck have anything to say about that partition? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
pppd + natd (was: Re: some bugs in natd.8)
On Thu, Mar 13, 2003 at 07:24:58AM -0800, Eivind Eklund wrote: [...] Okay, here's my question: what is/was so bad about pppd + natd? Generating 10% of the total support load for FreeBSD on IRC is so bad about it. And I can't give you a better answer than that, because I haven't supported it in 3.5 years and do not remember what problems people were having - and if it had been a single problem or two (as you imply with your questions), I'd have SOLVED THOSE PROBLEMS rather than going for the blanket. So you can't recall a single specific problem, other than saying they were. Okay, then how about querying our current FreeBSD users about it? It's that simple: Dear users of pppd(8) + natd(8), if there are any. Do you have/had any problems using this combination? I'd appreciate both successful and unfortunate reports, to improve documentation. Cheers, -- 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 pgp0.pgp Description: PGP signature
Status inquiry about disklabel(8) on sparc64
Dear Poul-Henning, What's the status of disklabel(8) on sparc64? What was the reason for not building it there? : phk 2003/01/26 04:19:36 PST : : Modified files: : sbin Makefile : Log: : Make disklabel(8) MD for i386/pc98 and alpha only. : : Revision ChangesPath : 1.115 +5 -1 src/sbin/Makefile Cheers, -- 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 pgp0.pgp Description: PGP signature
Re: pppd + natd (was: Re: some bugs in natd.8)
On Thu, Mar 13, 2003 at 05:43:58PM +0200, Ruslan Ermilov wrote: On Thu, Mar 13, 2003 at 07:24:58AM -0800, Eivind Eklund wrote: [...] Okay, here's my question: what is/was so bad about pppd + natd? Generating 10% of the total support load for FreeBSD on IRC is so bad about it. And I can't give you a better answer than that, because I haven't supported it in 3.5 years and do not remember what problems people were having - and if it had been a single problem or two (as you imply with your questions), I'd have SOLVED THOSE PROBLEMS rather than going for the blanket. So you can't recall a single specific problem, other than saying they were. There were no problems *per se* - there is nothing that inherently doesn't work with the configuration. I could say some people had problems configuring divert sockets. I could say some people had problems getting ipfw to work at all. I could say some people had problems with not having supplied -dynamic to natd. I could say some people didn't discover the -n option to natd. I could say some people had problems writing the script for pppd. I could say some people had problems with their kernel not containing the ppp device. And I could wring my brain to find more examples. However, I didn't see this as much of a point, because it does NOT add to the overall point: There was a bunch of small problems that in total resulted in the this configuration leading to a bunch of support. Okay, then how about querying our current FreeBSD users about it? It's that simple: Dear users of pppd(8) + natd(8), if there are any. Do you have/had any problems using this combination? I'd appreciate both successful and unfortunate reports, to improve documentation. I don't believe you'll get any relevant responses to that. Besides, I'm not interested. I know the problem is there, as I've seen it. You don't believe me when I tell you that it is there - that's your choice. This is not an issue I care enough about to spent more energy on. And I'm not active enough that I feel I have any right to any form of veto. Eivind. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE:
On 13-Mar-2003 Derek Tattersall wrote: I found on tty0 the following backtrace. I infer, because it died in malloc, that it has something to do with netisr problem. I had to copy it by hand. I think Sam Leffler has already fixed this one. backtrace(c04b7645,4,1,0,c40be100) at backtrace+0x17 malloc(3c,c050fca0,4,c1531300,d67e6c78) at malloc+0x5b mtag_alloc(0,e,30,4,c151ac00) at mtag_alloc+0x2f ip6_addaux(c1531300,d6706cbc,c037b09c,c1531300,c151ac00) at ip6_addaux+0x59 ip6_setdstifaddr(c1531300,c151ac00,d6te6cbc,c02d2480,c057a254) at ip6_setdstifaddr+0x11 ip6_input(c1531300,0,c04c0a40,e9,c1513ac00) at ip6_input+0x78c swi_net(0,0,c04b672f,217,c15209ec) at swi_net+0x112 ithread_loop(c151f200,d67e6048,c04b65ac,35f,0) at ithread_loop+0x182 fork_exit(c02c95e0,c151f200,d67e6048) at fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip=0, esp=0xd67e6d7c, ebp=0 --- -- Derek Tattersall [EMAIL PROTECTED] -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pppd + natd (was: Re: some bugs in natd.8)
On Thu, Mar 13, 2003 at 08:13:43AM -0800, Eivind Eklund wrote: On Thu, Mar 13, 2003 at 05:43:58PM +0200, Ruslan Ermilov wrote: On Thu, Mar 13, 2003 at 07:24:58AM -0800, Eivind Eklund wrote: [...] Okay, here's my question: what is/was so bad about pppd + natd? Generating 10% of the total support load for FreeBSD on IRC is so bad about it. And I can't give you a better answer than that, because I haven't supported it in 3.5 years and do not remember what problems people were having - and if it had been a single problem or two (as you imply with your questions), I'd have SOLVED THOSE PROBLEMS rather than going for the blanket. So you can't recall a single specific problem, other than saying they were. There were no problems *per se* - there is nothing that inherently doesn't work with the configuration. Fine, let's stick this then. I could say some people had problems configuring divert sockets. Are they configurable? Also indistinguishable from the NIC case. I could say some people had problems getting ipfw to work at all. Doesn't directly relate to the issue of not using pppd + natd. If you wanted to recommend ppp(8) over pppd(8), natd(8) manpage isn't the best place for it. Moreover, the latter doesn't even mention pppd(8). I could say some people had problems with not having supplied -dynamic to natd. So far, this is the only difference. :-) I could say some people didn't discover the -n option to natd. And were running with -a? I could say some people had problems writing the script for pppd. This is totally unrelated. I could say some people had problems with their kernel not containing the ppp device. Ditto. We're speaking about pppd + natd, not about pppd itself. And I could wring my brain to find more examples. Real examples on the pppd + natd, please. However, I didn't see this as much of a point, because it does NOT add to the overall point: There was a bunch of small problems that in total resulted in the this configuration leading to a bunch of support. If pppd is considered harmful, it should be taken out of the base system. It has not been updated for quite long to deserve it, actually. Again, this is not directly related to the subject. Okay, then how about querying our current FreeBSD users about it? It's that simple: Dear users of pppd(8) + natd(8), if there are any. Do you have/had any problems using this combination? I'd appreciate both successful and unfortunate reports, to improve documentation. I don't believe you'll get any relevant responses to that. Will see. Besides, I'm not interested. I know the problem is there, as I've seen it. You don't believe me when I tell you that it is there - that's your choice. This is not an issue I care enough about to spent more energy on. Times have changed, problems might be different nowadays. And I'm not active enough that I feel I have any right to any form of veto. Thanks. I'm not against documenting something, if I understand what this something should be. If people want pppd(8) over ppp(8) or mpd(8) for some reason, the only options to NAT they have are ipnat(8) and natd(8). You sounded like natd(8) should not be used on anything except NICs, this I strongly disagree to. I certainly do not for recommending ppp(8) over pppd(8), or for recommending ppp -nat over ppp + natd, but the former does not belong to the natd(8) manpage, and the latter is documented there. Cheers, -- 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 pgp0.pgp Description: PGP signature
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html Thu Mar 13 11:38:00 EST 2003 cvs [update aborted]: /work/repo/CVSROOT: Interrupted system call To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/vm vm_map.c vm_map.h vm_pageout.c
On Wed, 12 Mar 2003 16:51:15 -0800, David Schultz [EMAIL PROTECTED] said: A real problem is that a swapped out process' uarea has to be paged back in, even when no memory is available. I don't think there's an easy way around that, given that you need the uarea and kernel stack to handle the signal. But you don't, actually -- at least not to ``handle'' a SIGKILL. In that case, you should be able to simply destroy the process and free whatever swap it has been allocated without ever giving it control. So is the issue that we don't want to send SIGKILL too aggressively, and send some other signal to give the process a chance to exit gracefully? -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pppd + natd (was: Re: some bugs in natd.8)
And I'm not active enough that I feel I have any right to any form of veto. Thanks. I'm not against documenting something, if I understand what this something should be. That people absolutely should use ppp -nat instead of pppd+natd, and that this goes even if people ALREADY has a working pppd configuration. Or at least this was my experience when I added this, based on what lead to how much support (which I roughtly equate with problems for the users.) And that this should be documented in the natd manpage, because *that is where the people affected will be looking when they are affected*. If people want pppd(8) over ppp(8) or mpd(8) for some reason, the only options to NAT they have are ipnat(8) and natd(8). You sounded like natd(8) should not be used on anything except NICs, this I strongly disagree to. I certainly do not for recommending ppp(8) over pppd(8), or for recommending ppp -nat over ppp + natd, but the former does not belong to the natd(8) manpage, and the latter is documented there. I do not understand what you are attempting to say here at all. Ref mpd: I might still have patches to support using libalias with this directly somewhere; I remember submitting them back in 1997 or early 1998. Whistle did not want to integrate them in their mainline, though, as they were using a different NAT library internally. Eivind. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Do we want to let cpp(1) hide warnings in system headers?
Sigh. It's been a while since I've fixed the feature of gcc(1)
that makes it hide warnings in system headers (but visible with
-nostdinc -I/usr/include). I've stumbled upon a problem today,
wondering, why the hell cpp(1) wasn't complaining me about the
redefines, and the answer was: GNU cpp(1) hides warnings in system
headers by default. Rather than hack contrib/gcc sources, it can
be fixed the official way, like this:
%%%
Index: bsd.sys.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.sys.mk,v
retrieving revision 1.11
diff -u -r1.11 bsd.sys.mk
--- bsd.sys.mk 13 Nov 2002 13:49:29 - 1.11
+++ bsd.sys.mk 13 Mar 2003 15:24:56 -
@@ -9,6 +9,7 @@
# for GCC: http://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html#IDX143
.if !defined(NO_WARNS)
+CFLAGS += -Wsystem-headers
. if defined(WARNS)
. if ${WARNS} 0
. if !defined(NO_WERROR)
%%%
Anyone objects to having this in?
Cheers,
--
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
pgp0.pgp
Description: PGP signature
Re: kernel panic in tcp_input.c:2252
On Wed, 12 Mar 2003, Tobias Reifenberger wrote: Am Di, 2003-03-11 um 17.43 schrieb KT Sin: Another panic in tcp_input while exiting gtk-gnutella. Update your sources, and make sure that you have 1.202 of sys/netinet/tcp_input.c. I had a 100% reproducable panic very similar to yours, and hsu fixed it. Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panics with GnuPG
Update your sources, and make sure that you have 1.202 of sys/netinet/tcp_input.c. I had a 100% reproducable panic very similar to yours, and hsu fixed it. On Wed, 12 Mar 2003, Damian Gerow wrote: I've managed to write down the actual panic twice (no panic to screen if you're in X), You probably want to enable crash dumps in /etc/rc.conf[.local] via the dumpdev option (point that to a swap partition that has at least as much space as your physical memory), and make sure that /var/crash either has enough room for the dump(s), or is symlinked to a location that does. Good luck, Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic in tcp_input.c:2252
On Thu, Mar 13, 2003 at 10:10:30AM -0800, Doug Barton wrote: Update your sources, and make sure that you have 1.202 of sys/netinet/tcp_input.c. I had a 100% reproducable panic very similar to yours, and hsu fixed it. Doug The distributedfolding panic is also corrected. Jiawei -- 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
Digital Unix (Tru64) binaries on FreeBSD-Alpha
I maintain the www/apache13-fp and www/frontpage ports, and are supposed to work on FreeBSD-Alpha as they install the Digital Unix (Tru64) Frontpage Extentions binaries. Richard is trying to install the www/apache13-fp ports on his Alpha (5.0-RELEASE w/GENERIC kernel), but he is getting errors when the fp_install.sh script attempts to install the FP root web. Will chown web to www as part of install. Will chgrp web to www as part of install. exception system: exiting due to internal error: out of memory trying to allocate exception system resources Abort trap ERROR: / installation failed. Hit enter to continue Exiting due to an error! Please fix the error and try again. His /var/log/messages shows: Mar 13 12:48:52 skunkworx kernel: pid 10961 (owsadm.exe), uid 0: exited on signal 6 His Alpha system is configured with 1G swap and 512M RAM. He did a kldstat -v and it shows that the osf1.ko module is loaded. He also has the osf1_base port installed (which may/may not be needed by the www/frontpage port). Could one of the Alpha guru's test www/apache13-fp port on their Alpha system. Thanks, Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Digital Unix (Tru64) binaries on FreeBSD-Alpha
moved to the FreeBSD-Alpha list, send all replies there. 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 Wed, 12 Mar 2003, Tim Robbins wrote:
Compile, run under gdb, then type print test() when the program receives
SIGABRT. Seems to work incorrectly on 4.7 too.
#include stdio.h
#include stdlib.h
void
test(void)
{
puts(hello);
}
int
main(int argc, char *argv[])
{
abort();
exit(0);
}
Here's a simpler example:
%%%
#include signal.h
#include stdio.h
#include stdlib.h
int
main(int argc, char *argv[])
{
sigset_t mask, omask;
volatile int i;
sigfillset(mask);
sigprocmask(SIG_SETMASK, mask, omask);
exit(0);
}
%%%
Single stepping through this hangs at the end of the sigprocmask() and
triggers the INVARIANTS check. This is because masking SIGTRAP fouls
up trap handling. I first tried masking only SIGTRAP. This caused a
SIGSEGV on return of sigprocmask(). Masking SIGSEGV as well stops gdb
seeing any signals.
abort() causes similar misbehaviour by masking almost all signals.
gdb gets control for SIGABRT because SIGABRT is not masked, but
call test() hangs because it generates a SIGTRAP but SIGTRAP is
masked.
The system states are approx. 10% user and 90% sys for the hang in
both cases, so it seems that the misbehaviour is just the usual one
for bogusly masking signals for restartable exceptions if such an
exception occurs, and the bug is mainly in the sanity check
(SIGPENDING()'s P_TRACED check is less than a pessimization).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Bad ACPI timer causes uninterruptible hang on boot?
I've been trying to figure out why my Intel SR2100 servers would not boot with ACPI enabled, hanging uninterruptibly after probing the ACPI timer. I experimented with disabling various subsystems, and came up with the following results: - With `pci_link' disabled, the boot gets as far as ``Device configuration complete'' before hanging. - With `timer' disabled, the boot gets all the way through. - With `bus', `children', or `all' disabled, the boot fails at mountroot, having failed to probe any devices. A verbose boot of the kernel with `timer' disabled shows the following. Note also that some of the thermal parameters are given as -1, which seems to confuse the thermal module. -GAWollman 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 #0: Thu Mar 13 12:58:29 EST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GRAPEVINE Preloaded elf kernel /boot/kernel/kernel at 0xc051f000. Preloaded elf module /boot/kernel/acpi.ko at 0xc051f0b4. Calibrating clock(s) ... i8254 clock: 1193098 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz Calibrating TSC clock ... TSC clock: 999722211 Hz Timecounter TSC frequency 999722211 Hz CPU: Intel Pentium III (999.72-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 1073676288 (1023 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00546000 - 0x3ffe7fff, 1068113920 bytes (260770 pages) avail memory = 1037578240 (989 MB) bios32: Found BIOS32 Service Directory header at 0xc00f6990 bios32: Entry = 0xfd85e (c00fd85e) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd7c0+0x397 pnpbios: Found PnP BIOS data at 0xc00f69c0 pnpbios: Entry = f:a934 Rev = 1.0 Other BIOS signatures found: Allocating major#253 to net null: null device, zero device Allocating major#252 to pci mem: memory I/O Pentium Pro MTRR support enabled random: entropy source npx0: math processor on motherboard npx0: INT 16 interface acpi0: INTEL 024B on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE31 pci_open(1):mode 1 addr port (0x0cf8) is 0x8070 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=00091166) pcibios: BIOS version 2.10 acpi0: power button is handled as a fixed feature programming model. acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_tz0: _CRT value is absurd, ignored (-217.-7C) acpi_tz0: _ACx value is absurd, ignored (-247.-7C) acpi_tz1: thermal zone on acpi0 acpi_tz1: _CRT value is absurd, ignored (-217.-7C) acpi_tz1: _ACx value is absurd, ignored (-247.-7C) acpi_tz2: thermal zone on acpi0 acpi_tz2: _CRT value is absurd, ignored (-217.-7C) acpi_tz2: _ACx value is absurd, ignored (-247.-7C) acpi_button0: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.IR1_ irq 0: [ 5 10] low,level,sharable 0.15.0 \\_SB_.LN12 irq 10: [ 5 10] low,level,sharable 0.3.0 \\_SB_.LN13 irq 11: [ 5 10] low,level,sharable 0.2.0 \\_SB_.LN1A irq 5: [ 5 10] low,level,sharable 0.6.0 \\_SB_.LN1B irq 0: [ 5 10] low,level,sharable 0.6.1 \\_SB_.LN1C irq 0: [ 5 10] low,level,sharable 0.6.2 \\_SB_.LN1D irq 0: [ 5 10] low,level,sharable 0.6.3 \\_SB_.LN17 irq 0: [ 5 10] low,level,sharable 0.7.0 \\_SB_.LN1B irq 0: [ 5 10] low,level,sharable 0.7.1 \\_SB_.LN1C irq 0: [ 5 10] low,level,sharable 0.7.2 \\_SB_.LN1D irq 0: [ 5 10] low,level,sharable 0.7.3 \\_SB_.LN18 irq 0: [ 5 10] low,level,sharable 0.8.0 \\_SB_.LN1D irq 0: [ 5 10] low,level,sharable 0.8.1 \\_SB_.LN1B irq 0: [ 5 10] low,level,sharable 0.8.2 \\_SB_.LN1C irq 0: [ 5 10] low,level,sharable 0.8.3 \\_SB_.LN19 irq 0: [ 5 10] low,level,sharable 0.9.0 \\_SB_.LN1C irq 0: [ 5 10] low,level,sharable 0.9.1 \\_SB_.LN1D irq 0: [ 5 10] low,level,sharable 0.9.2 \\_SB_.LN1B irq 0: [ 5 10] low,level,sharable 0.9.3 before setting priority for links \\_SB_.IR1_: interrupts: 510 penalty: 1860 1860 references: 1 priority: 0 \\_SB_.LN1B: interrupts: 510 penalty: 1860 1860 references: 4 priority: 0 \\_SB_.LN1C: interrupts: 510 penalty: 1860 1860 references: 4 priority: 0 \\_SB_.LN1D: interrupts: 510 penalty: 1860 1860 references: 4 priority: 0 \\_SB_.LN17: interrupts: 510 penalty: 1860 1860 references: 1
Re: MAKEDEV lost in 5.0-CURRENT?
On Thu, Mar 13, 2003 at 12:45:24PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Andy writes: On Wed, Mar 12, 2003 at 12:18:08PM -0500, Hiten Pandya wrote: [...] On 5.0-RELEASE-p4 I have /usr/src/etc/MAKEDEV and i use it for making the devices in jails. Is there a jail devfs or is the way described in the jail(8) man page still the right(tm) one? See devfs(8) After reading it it seems the answer is no there is no special jail devfs, but you can create your own rules for a jail. More informative on this subject was /usr/share/doc/papers/devfs.ascii.gz which i quote here: 8 These behaviours will be controlled with mount options, but these have not yet been implemented because FreeBSD has run out of bitmap flags for mount options, and a new unlimited mount option implementation is still not in place at the time of writing. One mount option ``jaildevfs'', will restrict the contents of the DEVFS mount- point to the ``normal set'' of devices for a jail and automatically hide all future devices and make it impossible for a jailed root to un-hide hidden entries while letting an un-jailed root do so. 8 OK. What a pity. So we have to create our own, based on MAKEDEV jail maybe: 100 path * hide 200 path tty* unhide 300 path random unhide 400 path zero unhide 500 path null unhide 600 path fd/* unhide 700 path mdctl unhide 800 path ptyp* unhide Now the problem is ptyp* and mdctl don't show up, even so they got unhidden. Also symlinking seems to require special actions: $ ln -s null mem $ echo mem* mem mem $ ls -la mem* ls: mem: No such file or directory ls: mem: No such file or directory Obviously some magick happens with hidden devices, so how can you make those links or don't we need them anymore? Andy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fix for rtc, vmware modules and post-500104 -current
On Thu, 13 Mar 2003 04:09:27 +0900
Yoshinori KASAZAKI [EMAIL PROTECTED] wrote:
Hum.. This is not work in my environment. Because MOD_LOAD initializer
didn't kick rtc_attach. I fixed this problem and merge(but ADHOC:-).
Please, anyone, check following patch.
I've just applied your patch and rebuilt rtc.ko.
It gave me /dev/rtc and VMware2 doesn't complain about
'cannot open /dev/rtc...' any more.
It seems to be working well.
Humm.. I saw it. I make MOD_LOAD initializer do only make_dev.
(except
WARNING: driver rtc used unreserved major device number 202
message, which seems to be harmless)
:-).
BTW, vmmon_*.ko is not good. hum
vmmon_up.ko is working for me now with Marcin's patch.
My -current is dated as 2003/03/10.
Yes. vmmon_up.ko is works.. But when vmware2 reseted, vmware2
complains 'cannnot open /dev/vmmon'.
diff -urN emulators/rtc/Makefile local/rtc/Makefile
--- emulators/rtc/Makefile Fri Mar 7 15:01:17 2003
+++ local/rtc/Makefile Fri Mar 14 06:28:23 2003
@@ -6,7 +6,7 @@
#
PORTNAME= rtc
-PORTVERSION= 2001.09.16.1
+PORTVERSION= 2002.03.05.2
CATEGORIES= emulators linux
MASTER_SITES= # none
DISTFILES= # none
diff -urN emulators/rtc/files/rtc.c local/rtc/files/rtc.c
--- emulators/rtc/files/rtc.c Sun Sep 16 16:05:18 2001
+++ local/rtc/files/rtc.c Fri Mar 14 06:27:40 2003
@@ -85,6 +85,14 @@
static int rtc_modeevent(module_t mod, int cmd, void *arg);
static struct cdevsw rtc_cdevsw = {
+#if __FreeBSD_version = 500104
+ .d_open = rtc_open,
+ .d_close = rtc_close,
+ .d_ioctl = rtc_ioctl,
+ .d_poll = rtc_poll,
+ .d_name = DEVICE_NAME,
+ .d_maj = CDEV_MAJOR,
+#else
/* open */ rtc_open,
/* close */ rtc_close,
/* read */ noread,
@@ -104,6 +112,7 @@
#if __FreeBSD_version = 500018 || __FreeBSD_version = 43
/* kqfilter */ nokqfilter,
#endif
+#endif
};
/*
@@ -135,10 +144,6 @@
if (rtc_sc!=NULL)
return NULL;
- dev = make_dev(rtc_cdevsw, minor(dev), UID_ROOT, GID_WHEEL, 0600, DEVICE_NAME);
- if (dev==NULL)
- return (NULL);
-
MALLOC(sc, struct rtc_softc*, sizeof(*sc), M_DEVBUF, M_WAITOK);
if (sc==NULL)
return NULL;
@@ -264,11 +269,18 @@
static int
init_module(void)
{
-int error;
+ int error = 0;
+ dev_t dev;
+#if __FreeBSD_version 500104
error = cdevsw_add(rtc_cdevsw);
if (error)
return error;
+#endif
+
+ dev = make_dev(rtc_cdevsw, 0, UID_ROOT, GID_WHEEL, 0600, DEVICE_NAME);
+ if (dev==NULL)
+ error = ENOMEM;
return error;
}
@@ -286,7 +298,9 @@
DLog(Lfail, %p busy, sc);
return error;
}
+#if __FreeBSD_version 500104
error = cdevsw_remove(rtc_cdevsw);
+#endif
DLog(Linfo, return %d, error);
return error;
}
diff -urN emulators/rtc/files/rtc.sh local/rtc/files/rtc.sh
--- emulators/rtc/files/rtc.sh Fri Sep 22 20:08:22 2000
+++ local/rtc/files/rtc.sh Tue Mar 11 16:49:55 2003
@@ -7,11 +7,11 @@
start)
if [ -x $kmoddir/$kmod ]; then
echo -n ' rtc'
- kldload $kmoddir/$kmod
+ /sbin/kldload $kmoddir/$kmod
fi
;;
stop)
- kldunload $kmod echo -n ' rtc'
+ /sbin/kldunload $kmod echo -n ' rtc'
;;
*)
echo Usage: `basename $0` {start|stop} 2
devstat_end_transaction: HELP!! busy_count for ad1 is 0 (-1)!
I got this message after upgrading my world to as of Thu Mar 13 10:38:11 JST 2003. devstat_end_transaction: HELP!! busy_count for ad1 is 0 (-1)! devstat_end_transaction: HELP!! busy_count for ad1 is 0 (-1)! devstat_end_transaction: HELP!! busy_count for ad1 is 0 (-1)! ... What does this mean? -- 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: devstat_end_transaction: HELP!! busy_count for ad1 is 0 (-1)!
On Fri, Mar 14, 2003 at 07:11:35AM +0900, Jun Kuriyama wrote: I got this message after upgrading my world to as of Thu Mar 13 10:38:11 JST 2003. devstat_end_transaction: HELP!! busy_count for ad1 is 0 (-1)! devstat_end_transaction: HELP!! busy_count for ad1 is 0 (-1)! devstat_end_transaction: HELP!! busy_count for ad1 is 0 (-1)! ... What does this mean? There's a patch from phk at http://phk.freebsd.dk/patch/ken.patch which works for me (though it breaks gkrellm :) Cheers, Stefan Farfeleder To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ATA mount failur (Was: Re: Panics with GnuPG)
Thus spake Doug Barton ([EMAIL PROTECTED]) [03.03.13 13:27]: Update your sources, and make sure that you have 1.202 of sys/netinet/tcp_input.c. I had a 100% reproducable panic very similar to yours, and hsu fixed it. I'd like to verify, but using updated sources as of about four hours ago, I can't boot. My system hangs on mounting root: Mar 13 18:32:12 pegmatite kernel: Copyright (c) 1992-2003 The FreeBSD Project. Mar 13 18:32:12 pegmatite kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Mar 13 18:32:12 pegmatite kernel: The Regents of the University of California. All rights reserved. Mar 13 18:32:12 pegmatite kernel: FreeBSD 5.0-CURRENT #10: Thu Mar 13 16:50:44 EST 2003 Mar 13 18:32:12 pegmatite kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/pegmatite Mar 13 18:32:12 pegmatite kernel: Preloaded elf kernel /boot/kernel/kernel at 0xc053f000. Mar 13 18:32:12 pegmatite kernel: Timecounter i8254 frequency 1193182 Hz Mar 13 18:32:12 pegmatite kernel: Timecounter TSC frequency 733129806 Hz Mar 13 18:32:12 pegmatite kernel: CPU: Intel Pentium III (733.13-MHz 686-class CPU) Mar 13 18:32:12 pegmatite kernel: Origin = GenuineIntel Id = 0x686 Stepping = 6 Mar 13 18:32:12 pegmatite kernel: Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE Mar 13 18:32:12 pegmatite kernel: real memory = 1073659904 (1023 MB) Mar 13 18:32:12 pegmatite kernel: avail memory = 1037426688 (989 MB) Mar 13 18:32:12 pegmatite kernel: Allocating major#253 to net Mar 13 18:32:12 pegmatite kernel: Allocating major#252 to pci Mar 13 18:32:12 pegmatite kernel: netsmb_dev: loaded Mar 13 18:32:12 pegmatite kernel: Pentium Pro MTRR support enabled Mar 13 18:32:12 pegmatite kernel: acpi0: ASUS CUV4X_EA on motherboard Mar 13 18:32:12 pegmatite kernel: ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 Mar 13 18:32:12 pegmatite kernel: pcibios: BIOS version 2.10 Mar 13 18:32:12 pegmatite kernel: Using $PIR table, 9 entries at 0xc00f12d0 Mar 13 18:32:12 pegmatite kernel: acpi0: power button is handled as a fixed feature programming model. Mar 13 18:32:12 pegmatite kernel: Timecounter ACPI-fast frequency 3579545 Hz Mar 13 18:32:12 pegmatite kernel: acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 Mar 13 18:32:12 pegmatite kernel: acpi_cpu0: CPU port 0x530-0x537 on acpi0 Mar 13 18:32:12 pegmatite kernel: acpi_button0: Power Button on acpi0 Mar 13 18:32:12 pegmatite kernel: pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 Mar 13 18:32:12 pegmatite kernel: pci0: ACPI PCI bus on pcib0 Mar 13 18:32:12 pegmatite kernel: agp0: VIA 82C691 (Apollo Pro) host to PCI bridge mem 0xf800-0xfbff at device 0.0 on pci0 Mar 13 18:32:12 pegmatite kernel: pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 Mar 13 18:32:12 pegmatite kernel: pcib1: could not get PCI interrupt routing table for \_SB_.PCI0.AGP_ - AE_NOT_FOUND Mar 13 18:32:12 pegmatite kernel: pci1: ACPI PCI bus on pcib1 Mar 13 18:32:12 pegmatite kernel: pci1: display, VGA at device 0.0 (no driver attached) Mar 13 18:32:12 pegmatite kernel: isab0: PCI-ISA bridge at device 4.0 on pci0 Mar 13 18:32:12 pegmatite kernel: isa0: ISA bus on isab0 Mar 13 18:32:12 pegmatite kernel: atapci0: VIA 82C686B UDMA100 controller port 0xd800-0xd80f at device 4.1 on pci0 Mar 13 18:32:12 pegmatite kernel: ata0: at 0x1f0 irq 14 on atapci0 snip Mar 13 18:32:13 pegmatite kernel: vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Mar 13 18:32:13 pegmatite kernel: Timecounters tick every 1.000 msec Mar 13 18:32:13 pegmatite kernel: IP Filter: v3.4.31 initialized. Default = block all, Logging = enabled Mar 13 18:32:13 pegmatite kernel: acpi_cpu: throttling enabled, 16 steps (100% to 6.2%), currently 100.0% Mar 13 18:32:13 pegmatite kernel: ad0: 38166MB ST340016A [77545/16/63] at ata0-slave UDMA100 Mar 13 18:32:13 pegmatite kernel: acd0: CDROM FX4830T at ata1-slave PIO4 Mar 13 18:32:13 pegmatite kernel: Mounting root from ufs:/dev/ad0s1a And there it just hangs. I know there were some changes to the ATA code recently, I'll take a closer look at them later. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
I just cvsup'd the '.' tag today. I get this build error. Is this the wrong tag for -CURRENT, or am I doing something else wrong? -W -- stage 4: building libraries -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE=i686 GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 -DNOHTML -DNOINFO -DNOMAN -DNOFSCHG libraries cd /usr/src; make -f Makefile.inc1 _startup_libs; make -f Makefile.inc1 _prebuild_libs; make -f Makefile.inc1 _generic_libs; echo === gnu/lib/csu; cd /usr/src/gnu/lib/csu; make DIRPRFX=gnu/lib/csu/ depend; make DIRPRFX=gnu/lib/csu/ all; make DIRPRFX=gnu/lib/csu/ install === gnu/lib/csu sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbegin.o /usr/obj/usr/src/i386/usr/lib/crtbegin.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtend.o /usr/obj/usr/src/i386/usr/lib/crtend.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbegin.So /usr/obj/usr/src/i386/usr/lib/crtbeginS.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtend.So /usr/obj/usr/src/i386/usr/lib/crtendS.o echo === gnu/lib/libgcc; cd /usr/src/gnu/lib/libgcc; make DIRPRFX=gnu/lib/libgcc/ depend; make DIRPRFX=gnu/lib/libgcc/ all; make DIRPRFX=gnu/lib/libgcc/ install === gnu/lib/libgcc sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libgcc.a /usr/obj/usr/src/i386/usr/lib sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libgcc_p.a /usr/obj/usr/src/i386/usr/lib echo === lib/csu/i386-elf; cd /usr/src/lib/csu/i386-elf; make DIRPRFX=lib/csu/i386-elf/ depend; make DIRPRFX=lib/csu/i386-elf/ all; make DIRPRFX=lib/csu/i386-elf/ install === lib/csu/i386-elf sh /usr/src/tools/install.sh -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o /usr/obj/usr/src/i386/usr/lib echo === lib/libcom_err; cd /usr/src/lib/libcom_err; make DIRPRFX=lib/libcom_err/ depend; make DIRPRFX=lib/libcom_err/ all; make DIRPRFX=lib/libcom_err/ install === lib/libcom_err === lib/libcom_err/doc === lib/libcom_err/doc sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libcom_err.a /usr/obj/usr/src/i386/usr/lib sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libcom_err_p.a /usr/obj/usr/src/i386/usr/lib sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libcom_err.so.2 /usr/obj/usr/src/i386/usr/lib ln -fs libcom_err.so.2 /usr/obj/usr/src/i386/usr/lib/libcom_err.so sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 /usr/src/lib/libcom_err/../../contrib/com_err/com_err.h /usr/src/lib/libcom_err/../../contrib/com_err/com_right.h /usr/obj/usr/src/i386/usr/include === lib/libcom_err/doc echo === lib/libcrypt; cd /usr/src/lib/libcrypt; make DIRPRFX=lib/libcrypt/ depend; make DIRPRFX=lib/libcrypt/ all; make DIRPRFX=lib/libcrypt/ install === lib/libcrypt sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libcrypt.a /usr/obj/usr/src/i386/usr/lib sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libcrypt_p.a /usr/obj/usr/src/i386/usr/lib sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libcrypt.so.2 /usr/obj/usr/src/i386/usr/lib ln -fs libcrypt.so.2 /usr/obj/usr/src/i386/usr/lib/libcrypt.so echo === lib/libkvm; cd /usr/src/lib/libkvm; make DIRPRFX=lib/libkvm/ depend; make DIRPRFX=lib/libkvm/ all; make DIRPRFX=lib/libkvm/ install === lib/libkvm cc -O -pipe -march=pentiumpro -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o /usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': /usr/src/lib/libkvm/kvm_proc.c:191: structure has no member named `p_tracep' *** Error code 1 Stop in /usr/src/lib/libkvm. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. [EMAIL PROTECTED] src]# -- Wade Klaver Wavefire Technologies Corporation GPG Public Key at http://archeron.wavefire.com /\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
subject should be CURRENT build error.
Sorry about that. :) -- Wade Klaver Wavefire Technologies Corporation GPG Public Key at http://archeron.wavefire.com /\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Build error again.
That last error was generated running with -DNOCLEAN and -j 4. I get this error running a plain make buildworld. Thanx for any help/comments/suggestions in advance. building static ncurses library building shared library libncurses.so.5 building profiled ncurses library ranlib libncurses.a ranlib libncurses_p.a sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libncurses.a /usr/obj/usr/src/i386/usr/lib sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libncurses_p.a /usr/obj/usr/src/i386/usr/lib sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 curses.h term.h termcap.h unctrl.h /usr/src/lib/libncurses/../../contrib/ncurses/include/ncurses_dll.h /usr/obj/usr/src/i386/usr/include sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libncurses.so.5 /usr/obj/usr/src/i386/usr/lib ln -fs libncurses.so.5 /usr/obj/usr/src/i386/usr/lib/libncurses.so /usr/obj/usr/src/i386/usr/include/ncurses.h - curses.h /usr/obj/usr/src/i386/usr/lib/libcurses.a - libncurses.a /usr/obj/usr/src/i386/usr/lib/libtermcap.a - libncurses.a /usr/obj/usr/src/i386/usr/lib/libtermlib.a - libncurses.a /usr/obj/usr/src/i386/usr/lib/libmytinfo.a - libncurses.a /usr/obj/usr/src/i386/usr/lib/libtinfo.a - libncurses.a /usr/obj/usr/src/i386/usr/lib/libcurses.so - libncurses.so /usr/obj/usr/src/i386/usr/lib/libtermcap.so - libncurses.so /usr/obj/usr/src/i386/usr/lib/libtermlib.so - libncurses.so /usr/obj/usr/src/i386/usr/lib/libmytinfo.so - libncurses.so /usr/obj/usr/src/i386/usr/lib/libtinfo.so - libncurses.so /usr/obj/usr/src/i386/usr/lib/libcurses_p.a - libncurses_p.a /usr/obj/usr/src/i386/usr/lib/libtermcap_p.a - libncurses_p.a /usr/obj/usr/src/i386/usr/lib/libtermlib_p.a - libncurses_p.a /usr/obj/usr/src/i386/usr/lib/libmytinfo_p.a - libncurses_p.a /usr/obj/usr/src/i386/usr/lib/libtinfo_p.a - libncurses_p.a 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error [EMAIL PROTECTED] src]# -- Wade Klaver Wavefire Technologies Corporation GPG Public Key at http://archeron.wavefire.com /\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devstat_end_transaction: HELP!! busy_count for ad1 is 0 (-1)!
At Thu, 13 Mar 2003 23:24:03 +0100, Stefan Farfeleder wrote: There's a patch from phk at http://phk.freebsd.dk/patch/ken.patch which works for me (though it breaks gkrellm :) Thaks! I missed previous thread of this subject. I'll try that patch. -- 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: Vinum R5 [was: Re: background fsck deadlocks with ufs2 and big disk]
On Saturday, 1 March 2003 at 20:43:10 +0200, Vallo Kallaste wrote: On Thu, Feb 27, 2003 at 11:53:02AM +0200, Vallo Kallaste vallo wrote: The vinum R5 and system as a whole were stable without softupdates. Only one problem remained after disabling softupdates, while being online and user I/O going on, rebuilding of failed disk corrupt the R5 volume completely. Yes, we've fixed a bug in that area. It had nothing to do with soft updates, though. Oh, that's very good news, thank you! Yes, it had nothing to do with soft updates at all and that's why I had the remained after in the sentence. Don't know is it fixed or not as I don't have necessary hardware at the moment. The only way around was to quiesce the volume before rebuilding, umount it, and wait until rebuild finished. I'll suggest extensive testing cycle for everyone who's going to work with vinum R5. Concat, striping and mirroring has been a breeze but not so with R5. IIRC the rebuild bug bit any striped configuration. Ok, I definitely had problems only with R5, but you certainly know much better what it was exactly. I'll need to lend 50-pin SCSI cable and test vinum again. Will it matter on what version of FreeBSD I'll try on? My home system runs -current of Feb 5, but if you suggest -stable for consistent results, I'll do it. So I did. Loaned two SCSI disks and 50-pin cable. Things haven't improved a bit, I'm very sorry to say it. Sorry for the slow reply to this. I thought it would make sense to try things out here, and so I kept trying to find time, but I have to admit I just don't have it yet for a while. I haven't forgotten, and I hope that in a few weeks time I can spend some time chasing down a whole lot of Vinum issues. This is definitely the worst I have seen, and I'm really puzzled why it always happens to you. # simulate disk crash by forcing one arbitrary subdisk down # seems that vinum doesn't return values for command completion status # checking? echo Stopping subdisk.. degraded mode vinum stop -f r5.p0.s3# assume it was successful I wonder if there's something relating to stop -f that doesn't happen during a normal failure. But this was exactly the way I tested it in the first place. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Build error again.
On Thu, Mar 13, 2003 at 05:12:32PM -0800, Wade Klaver wrote: That last error was generated running with -DNOCLEAN and -j 4. I get this error running a plain make buildworld. Thanx for any help/comments/suggestions in advance. This doesn't show the error because you are using -j4. However, it's probably caused by using -DNOCLEAN. Don't do that, and try again (also omit -j so you can post the actual error if it still fails). Kris pgp0.pgp Description: PGP signature
Re: cvs commit: src/sys/vm vm_map.c vm_map.h vm_pageout.c
Thus spake Garrett Wollman [EMAIL PROTECTED]: On Wed, 12 Mar 2003 16:51:15 -0800, David Schultz [EMAIL PROTECTED] said: A real problem is that a swapped out process' uarea has to be paged back in, even when no memory is available. I don't think there's an easy way around that, given that you need the uarea and kernel stack to handle the signal. But you don't, actually -- at least not to ``handle'' a SIGKILL. In that case, you should be able to simply destroy the process and free whatever swap it has been allocated without ever giving it control. So is the issue that we don't want to send SIGKILL too aggressively, and send some other signal to give the process a chance to exit gracefully? Perhaps you don't technically need it since swapping doesn't swap out very much these days (and should probably go away). But you'd need to make some minor changes to signal delivery, or write a separate mechanism, in order to kill a process without swapping it in. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stacktrace of recent panic..(bremfree)
Jeff Roberson wrote: On Thu, 13 Mar 2003, Julian Elischer wrote: I got this today on a kernel checked out on the 10th. Can you please disable sync on panic and get a dump from the first panic? Then print out the contents of the buf in that stack for me? A couple of people have seen this now but I have not been able to repro it. Add me to the list of people seeing this: See attached crash dump. BTW, is it OK to send attachments to the mailing list? I'm using Mozilla, and following the current mailing list via the usenet gateway. crash_dump Description: application/java-vm
Re: stacktrace of recent panic..(bremfree)
On Fri, 14 Mar 2003, Donn Miller wrote: Can you please disable sync on panic and get a dump from the first panic? Then print out the contents of the buf in that stack for me? A couple of people have seen this now but I have not been able to repro it. Thanks for the report. Please follow the directions above and mail me if it happens again. See attached crash dump. BTW, is it OK to send attachments to the mailing list? I'm using Mozilla, and following the current mailing list via the usenet gateway. I'm not sure what the policy on attachments in the mailing list. That would have been ok to paste into the email though. Cheers, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
