Re: Do we still need portmap(8)?
M == M Warner Losh [EMAIL PROTECTED] writes: M I think that we need a mtree.obsolete that goes through and M deletes these sorts of things as part of installworld/upgrade M scripts. No solution like this will ever work for everyone, or in every situation. For example, you generally want to nuke stale bits from /usr/include, but doing the same in /usr/lib can lead to Interesting Times. And you never know if I might be working on replacements for obsoleted bits of the OS that I'm installing into their old location. For example: adduser. Current would remove it in your scenario, even though I've re-implemented it in it's old location in my build/install tree. Yes, I could modify mtree.obsolete under /usr/src, but that seems counter-productive for a -current environment. (Thankfully, I don't own a bike, so I don't need to worry about the colour of it's shed.) One compromise is to have the 'install' target touch a timestamp file before setting off to overwrite things. Then you can use 'find mumble ! -newer ...' to search for and display possibly stale files. (A /usr/sbin/findstale script that wraps this might be a useful adjunct to mergemaster.) I use /bin/cat as a timestamp file for rough analysis purposes. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP! GEOM as default in 5 days...
÷ Mon, 30.09.2002, × 23:09, Poul-Henning Kamp ÎÁÐÉÓÁÌ: Provided nothing terminal pops up in the next 5 days, GEOM will become default in -current on Saturday 5th of october. Please test it now on _your_ configuration and tell me if it fails to work. Ok, diskcheckd (old binary) no isn't work :( New binary not builds from fresh ports: vbook#/usr/ports/sysutils/diskcheckd 132_ cvs -Rq upd -dP U Makefile vbook#/usr/ports/sysutils/diskcheckd 133_ make === Extracting for diskcheckd-20010823_3 No MD5 checksum file. === Patching for diskcheckd-20010823_3 === Configuring for diskcheckd-20010823_3 === Building for diskcheckd-20010823_3 Warning: Object directory not changed from original /usr/local/ports/sysutils/diskcheckd/work cc -O -pipe -mcpu=pentiumpro -D_PATH_CONF='/usr/local/etc/diskcheckd.conf' -mc pu=pentiumpro-c diskcheckd.c diskcheckd.c: In function `fstypename': diskcheckd.c:251: `FSMAXTYPES' undeclared (first use in this function) diskcheckd.c:251: (Each undeclared identifier is reported only once diskcheckd.c:251: for each function it appears in.) diskcheckd.c:252: `fstypenames' undeclared (first use in this function) diskcheckd.c: In function `logreaderror': diskcheckd.c:298: `DOSPARTOFF' undeclared (first use in this function) diskcheckd.c:299: `NDOSPART' undeclared (first use in this function) diskcheckd.c:300: invalid use of undefined type `struct dos_partition' diskcheckd.c:300: dereferencing pointer to incomplete type diskcheckd.c:301: invalid use of undefined type `struct dos_partition' diskcheckd.c:301: dereferencing pointer to incomplete type diskcheckd.c:301: invalid use of undefined type `struct dos_partition' diskcheckd.c:301: dereferencing pointer to incomplete type diskcheckd.c:312: invalid use of undefined type `struct dos_partition' diskcheckd.c:312: dereferencing pointer to incomplete type diskcheckd.c:318: invalid use of undefined type `struct dos_partition' diskcheckd.c:318: dereferencing pointer to incomplete type diskcheckd.c:318: `DOSPTYP_386BSD' undeclared (first use in this function) diskcheckd.c:322: invalid use of undefined type `struct dos_partition' diskcheckd.c:322: dereferencing pointer to incomplete type *** Error code 1 Stop in /usr/local/ports/sysutils/diskcheckd/work. *** Error code 1 Stop in /usr/local/ports/sysutils/diskcheckd. vbook#/usr/ports/sysutils/diskcheckd 134_ -- 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. -- 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: sorry state of Xserver in 5.0
÷ Mon, 07.10.2002, × 22:13, Andrew Gallatin ÎÁÐÉÓÁÌ: Every so often, my X server locks up. It seems to be in a tight loop, 95% user time, and making only these ktrace'able calls: 27069 XFree86 0.019988 PSIG SIGALRM caught handler=0x80d219c mask=0x0 code=0x0 27069 XFree86 0.39 CALL sigreturn(0xbd9e7b0c) 27069 XFree86 0.04 RET sigreturn JUSTRETURN 27069 XFree86 0.019951 PSIG SIGALRM caught handler=0x80d219c mask=0x0 code=0x0 27069 XFree86 0.15 CALL sigreturn(0xbd9e6e0c) 27069 XFree86 0.04 RET sigreturn JUSTRETURN 27069 XFree86 0.019980 PSIG SIGALRM caught handler=0x80d219c mask=0x0 code=0x0 Anybody have a workaround for this? The whole system (2.53 Ghz P4) was compiled from sources late last week... Me too :( Between this, and the Type1 bezier font abort, the state of 5.0 on a desktop is very sorry indeed. My old alpha running -stable is far more stable. For me it happens an about 90% cases when I have move frame border in evolution and in some other cases :( Xserver starts eat all CPU and, sometimes dies with 6 signal. any ideas ? I have tried to build fresh Xserver from ports - but it don't buildable. Sigh. Drew -- Vladimir B. Grebenschikov [EMAIL PROTECTED], SWsoft, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
X11 unstable under CURRENT and STABLE.
Hi! I read a few threads on the stableness of X11 under CURRENT. Some people proposed it was more stable under STABLE. I can report that my X on STABLE: XFree86 Version 4.2.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 3 September 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: FreeBSD 4.7-RC i386 [ELF] 4.7-RC as of September 19th. X crashed after killing acroread with CTRL-C. (Un)fortunately I could not repeat this behaviour so far. Sincerely, Robert S. -- Robert Suetterlin ([EMAIL PROTECTED]) phone: (+49)89 / 3-3546 fax: (+49)89 / 3-3950 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Can't make depend or buildkernel for a custom kernel
On 2002-10-07 22:29, M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Alex Zepeda [EMAIL PROTECTED] writes: : http://people.freebsd.org/~kan/gcc-cpp.diff : : Cool. make depend works now, let's see if the resulting kernel does. :) I hit this same problem. Robert pointed me at this patch and I've booted 10 kernels built since then. More or less the same here. Kernels work fine after this here too. I've only booted 4 of 5 of them, but no obvious problems until now. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: X11 unstable under CURRENT and STABLE.
Robert Suetterlin wrote: Hi! I read a few threads on the stableness of X11 under CURRENT. Some people proposed it was more stable under STABLE. I can report that my X on STABLE: XFree86 Version 4.2.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 3 September 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: FreeBSD 4.7-RC i386 [ELF] 4.7-RC as of September 19th. X crashed after killing acroread with CTRL-C. (Un)fortunately I could not repeat this behaviour so far. Sincerely, Robert S. Crashes fo r me too, reporting Sigint 6, Basically whenever it is idle. Usually just running Opera and Mozilla-mail. Any Sugestions?? Cheers, Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha 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/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Tue Oct 8 03:10:38 PDT 2002 -- Kernel build for GENERIC completed on Tue Oct 8 03:37:40 PDT 2002 -- Kernel build for LINT started on Tue Oct 8 03:37:41 PDT 2002 -- === vinum Makefile, line 4194: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant conversion *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /usr/include/stdlib.h:51: syntax error before size_t
On Oct 07 at 16:28, Giorgos Keramidas spoke: By grepping through buildworld logs I saw this passing by: # cd /usr/src/include; make buildincludes; make installincludes I did `make includes' which obviously does both buildincludes and installincludes. Afterwords I was able to buildworld. -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Promise tx2 ata100 and Atapi-Dma
Hello, I'm trying to run burncd on CD-RW connected via Promise TX2 ATA100 with UDMA2 (UDMA33) enabled. Reading a CD with DMA is no problem. Attempting to burn with DMA enabled hangs the system. This is the case for current as well as 4.6.2-Release. Is there work in progress on this issue? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Promise tx2 ata100 and Atapi-Dma
It seems Hanspeter Roth wrote: Hello, I'm trying to run burncd on CD-RW connected via Promise TX2 ATA100 with UDMA2 (UDMA33) enabled. Reading a CD with DMA is no problem. Attempting to burn with DMA enabled hangs the system. This is the case for current as well as 4.6.2-Release. What burner is this ? (dmesg please!) Is there work in progress on this issue? Its not an issue as such, its more like a feature of some ATAPI devices I'm afraid... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Promise tx2 ata100 and Atapi-Dma
On Tue, Oct 08, 2002 at 02:20:15PM +0200, Hanspeter Roth wrote: Hello, I'm trying to run burncd on CD-RW connected via Promise TX2 ATA100 with UDMA2 (UDMA33) enabled. Reading a CD with DMA is no problem. Attempting to burn with DMA enabled hangs the system. This is the case for current as well as 4.6.2-Release. kern/43601 states that it's currently not possible to boot current with one of these controllers - I'm having the same problem. Did you need to do anything special for this to boot ? Ceri -- you can't see when light's so strong you can't see when light is gone To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Promise tx2 ata100 and Atapi-Dma
On Tue, Oct 08, 2002 at 02:32:07PM +0200, Soeren Schmidt wrote: It seems Hanspeter Roth wrote: Hello, I'm trying to run burncd on CD-RW connected via Promise TX2 ATA100 with UDMA2 (UDMA33) enabled. Reading a CD with DMA is no problem. Attempting to burn with DMA enabled hangs the system. This is the case for current as well as 4.6.2-Release. What burner is this ? (dmesg please!) Is there work in progress on this issue? Its not an issue as such, its more like a feature of some ATAPI devices I'm afraid... I'm seeing similar behaviour on 4.6.2R with only ATA devices (see dmesg at http://panda.droso.net/~erwin/valhalla.dmesg ; note that the faulty disk in the vinum array is unrelated). -erwin -- _._ _,-'`-._ Erwin Lansing (,-.`._,'( |\`-/|http://droso.org/ [EMAIL PROTECTED] `-.-' \ )-`( , o o)http://fnidder.dk/ -bf- `-\`_`'- msg44275/pgp0.pgp Description: PGP signature
Re: Promise tx2 ata100 and Atapi-Dma
On Oct 08 at 14:32, Soeren Schmidt spoke: It seems Hanspeter Roth wrote: What burner is this ? (dmesg please!) PLEXTOR CD-R PX-W4012A 1.02 http://home.datacomm.ch/~hampi/dmesg/freebsd Is there work in progress on this issue? Its not an issue as such, its more like a feature of some ATAPI devices I'm afraid... The Plextor connected to the onboard SiS 5591 ATA100 controller burns with DMA without problem. -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sorry state of Xserver in 5.0
Maxim Sobolev writes: Between this, and the Type1 bezier font abort, the state of 5.0 on a desktop is very sorry indeed. My old alpha running -stable is far more stable. Sigh. Agreed. I could add that after recent kernel updating I'm also often observing XFree86 dying with SIGFPU. I guess that it may have something to do with recent context saving changes. Note that the recent sys/i386/i386/machdep.c (1.540 and 1.541) should be backed out if you're running any FP apps (like, say, X). It somehow messes up the fp context and causes a gpf. Happens to me when I start gnome2. 1.539 more or less works, albeit with the problems I'm compaining about above. Question: Did the Bezier too big stuff start when people upgraded their X server port, or when they upgraded their kernel? (I just started running -current on an x86 last week) I have a sneaking suspicion that the fp context is not being saved correctly, which is leading to the Bezier problem. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
booting on Promise tx2 ata100
On Oct 08 at 13:39, Ceri Davies spoke: On Tue, Oct 08, 2002 at 02:20:15PM +0200, Hanspeter Roth wrote: kern/43601 states that it's currently not possible to boot current with one of these controllers - I'm having the same problem. Did you need to do anything special for this to boot ? I thought I had booted 4.6.2-Release on the TX2 ATA100. If you relocate your disk you might need to adjust fstab. It seems disks are addressed absolutely in FreeBSD. -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sorry state of Xserver in 5.0
On Tue, 8 Oct 2002 09:04:27 -0400 (EDT) Andrew Gallatin [EMAIL PROTECTED] wrote: Question: Did the Bezier too big stuff start when people upgraded their X server port, or when they upgraded their kernel? (I just started running -current on an x86 last week) I have a sneaking suspicion that the fp context is not being saved correctly, which is leading to the Bezier problem. I got this by only upgrading the kernel. I'm going to downgrade sys/i386/i386/machdep.c to 1.539 now and have a look how the system behaves. Bye, Alexander. -- Intel: where Quality is job number 0.9998782345! http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: booting on Promise tx2 ata100
On Tue, Oct 08, 2002 at 03:08:39PM +0200, Hanspeter Roth wrote: On Oct 08 at 13:39, Ceri Davies spoke: On Tue, Oct 08, 2002 at 02:20:15PM +0200, Hanspeter Roth wrote: kern/43601 states that it's currently not possible to boot current with one of these controllers - I'm having the same problem. Did you need to do anything special for this to boot ? I thought I had booted 4.6.2-Release on the TX2 ATA100. Oh, it definitely works with -stable, but you mentioned you had booted -current on it, which is where the problem lies. If you relocate your disk you might need to adjust fstab. It seems disks are addressed absolutely in FreeBSD. No, I'm talking about a panic just after probing SMBus. Ceri -- you can't see when light's so strong you can't see when light is gone To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
hotspot 1.3.1 not such ansi.h file error
hi,all: get the error messages during gmake core gmake[1]: Entering directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' gmake[2]: Entering directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' Compiling /usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/../../src/os/linux/vm/os_linux.cpp /usr/ports/java/jdk13/work/hotspot1.3.1/src/os/linux/vm/os_linux.cpp:49:26: machine/ansi.h: No such file or directory gmake[2]: *** [os_linux.o] Error 1 gmake[2]: Leaving directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' gmake[1]: *** [the_vm] Error 2 gmake[1]: Leaving directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' gmake: *** [jvmgcore] Error 2 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sorry state of Xserver in 5.0
On Tue, 8 Oct 2002 15:27:27 +0200 Alexander Leidinger [EMAIL PROTECTED] wrote: I'm going to downgrade sys/i386/i386/machdep.c to 1.539 now and have a look how the system behaves. Doesn't work, I still get signal 6. Bye, Alexander. -- Yes, I've heard of decaf. What's your point? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sorry state of Xserver in 5.0
Alexander Leidinger writes: On Tue, 8 Oct 2002 15:27:27 +0200 Alexander Leidinger [EMAIL PROTECTED] wrote: I'm going to downgrade sys/i386/i386/machdep.c to 1.539 now and have a look how the system behaves. Doesn't work, I still get signal 6. That won't fix signal 6. That will just fix the kernel panic. To fix signal 6, I think you need to rebuild your X server. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: booting on Promise tx2 ata100
It seems Ceri Davies wrote: If you relocate your disk you might need to adjust fstab. It seems disks are addressed absolutely in FreeBSD. Only if you have option ATA_STATIC_ID in your kernel config. No, I'm talking about a panic just after probing SMBus. This patch solves this problem, however I have no idea if that is the right fix for the ACPI code... Index: acpi.c === RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.75 diff -u -r1.75 acpi.c --- acpi.c 6 Sep 2002 17:01:06 - 1.75 +++ acpi.c 8 Oct 2002 14:45:21 - @@ -575,6 +575,8 @@ break; /* ISA compatibility */ +case ISA_IVAR_MADDR: +case ISA_IVAR_IRQ: case ISA_IVAR_VENDORID: case ISA_IVAR_SERIAL: case ISA_IVAR_COMPATID: -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fw: hotspot 1.3.1 not such ansi.h file error
[EMAIL PROTECTED] wrote: - Original Message - From: Yuri Khotyaintsev [EMAIL PROTECTED] To: suken woo [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, October 08, 2002 10:16 PM Subject: Re: hotspot 1.3.1 not such ansi.h file error This file was recently removed from -CURRENT. how can I do ? Must I comment it? thanks any helps suken woo wrote: hi,all: get the error messages during gmake core gmake[1]: Entering directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' gmake[2]: Entering directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' Compiling /usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/../../src/os/linux/vm/os_linux.cpp /usr/ports/java/jdk13/work/hotspot1.3.1/src/os/linux/vm/os_linux.cpp:49:26: machine/ansi.h: No such file or directory gmake[2]: *** [os_linux.o] Error 1 gmake[2]: Leaving directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' gmake[1]: *** [the_vm] Error 2 gmake[1]: Leaving directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' gmake: *** [jvmgcore] Error 2 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-java in the body of the message -- Yuri To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: booting on Promise tx2 ata100
On Tue, Oct 08, 2002 at 04:58:46PM +0200, Soeren Schmidt wrote: It seems Ceri Davies wrote: If you relocate your disk you might need to adjust fstab. It seems disks are addressed absolutely in FreeBSD. Only if you have option ATA_STATIC_ID in your kernel config. No, I'm talking about a panic just after probing SMBus. This patch solves this problem, however I have no idea if that is the right fix for the ACPI code... Thanks, I'll try it out. Do you have plans to commit this before DP2 ? Ceri -- you can't see when light's so strong you can't see when light is gone To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sorry state of Xserver in 5.0
On Tue, 8 Oct 2002 10:56:54 -0400 (EDT) Andrew Gallatin [EMAIL PROTECTED] wrote: I'm going to downgrade sys/i386/i386/machdep.c to 1.539 now and have a look how the system behaves. Doesn't work, I still get signal 6. That won't fix signal 6. That will just fix the kernel panic. I don't see a kernel panic with any rev of machdep.c. To fix signal 6, I think you need to rebuild your X server. Do you think I have to rebuild or do you know I have to rebuild? Bye, Alexander. -- 0 and 1. Now what could be so hard about that? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sorry state of Xserver in 5.0
On Tue, 8 Oct 2002, Alexander Leidinger wrote: To fix signal 6, I think you need to rebuild your X server. Do you think I have to rebuild or do you know I have to rebuild? I've rebuilt several times. I'm guessing NO, since I still have the problems periodically. -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sorry state of Xserver in 5.0
Alexander Leidinger writes: On Tue, 8 Oct 2002 10:56:54 -0400 (EDT) Andrew Gallatin [EMAIL PROTECTED] wrote: I'm going to downgrade sys/i386/i386/machdep.c to 1.539 now and have a look how the system behaves. Doesn't work, I still get signal 6. That won't fix signal 6. That will just fix the kernel panic. I don't see a kernel panic with any rev of machdep.c. You're lucky. To fix signal 6, I think you need to rebuild your X server. Do you think I have to rebuild or do you know I have to rebuild? Nevermind. 6 is abort, I thought it was FPE. Check your var/log/X*log and see if you see something about beziers the next time it crashes. One hacky workaround is to not load the Type1 module (just comment it out in your /etc/X11/XF86Config) # This loads the Type1 and FreeType font modules #Loadtype1 Loadfreetype A longer term fix would be to fix the kernel.. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: booting on Promise tx2 ata100
On 08-Oct-2002 Ceri Davies wrote: On Tue, Oct 08, 2002 at 04:58:46PM +0200, Soeren Schmidt wrote: It seems Ceri Davies wrote: If you relocate your disk you might need to adjust fstab. It seems disks are addressed absolutely in FreeBSD. Only if you have option ATA_STATIC_ID in your kernel config. No, I'm talking about a panic just after probing SMBus. This patch solves this problem, however I have no idea if that is the right fix for the ACPI code... Thanks, I'll try it out. Do you have plans to commit this before DP2 ? That is a bug. It makes pci_get_devid() return -1 and will cause bogus results during probe. Do not use until we figure out what is actually going on. -- 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: hotspot 1.3.1 not such ansi.h file error
suken woo [EMAIL PROTECTED] writes: hi,all: get the error messages during gmake core gmake[1]: Entering directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' gmake[2]: Entering directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' Compiling /usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/../../src/os/linux/vm/os_linux.cpp /usr/ports/java/jdk13/work/hotspot1.3.1/src/os/linux/vm/os_linux.cpp:49:26: machine/ansi.h: No such file or directory gmake[2]: *** [os_linux.o] Error 1 gmake[2]: Leaving directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' gmake[1]: *** [the_vm] Error 2 gmake[1]: Leaving directory `/usr/ports/java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg' gmake: *** [jvmgcore] Error 2 AFAICT the machine/ansi.h include here is bogus. Removing it should fix this. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removing old binaries
Thus spake M. Warner Losh [EMAIL PROTECTED]: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : I think it confuses the issue rather than solving it. We're talking : about removing binaries which are no longer needed, not replacing : binaries that are needed. I'd be cool with a file that's a list of files that we had in the system in the past, but are safe to delete. NetBSD has a list of obsolete files, and it seems to work well there. We can just have a set of rules for when to add to this. List all the files that have had on a FreeBSD system since 2.0 or 3.0 to start. That's an interesting idea. If necessary, you could even make it more general by associating a script with the removal of certain components. (That ought to solve complicated problems such as the one Terry mentioned.) Utilities don't turn over too quickly, so I imagine a tool like that would be fairly easy to maintain. I disagree with Greg about making it completely automagical by default. By default, the utility should try not to do anything that the user might not expect. People who want the fully automated behavior can enable it with a few keystrokes, and if something unexpected happens at that point, it's their problem. Granted, if you're only looking for things that you *know* have been removed, as opposed to ``anything that isn't in the source tree right now'', you're less likely to step on something important. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sorry state of Xserver in 5.0
Andrew Gallatin wrote: Maxim Sobolev writes: Between this, and the Type1 bezier font abort, the state of 5.0 on a desktop is very sorry indeed. My old alpha running -stable is far more stable. Sigh. Agreed. I could add that after recent kernel updating I'm also often observing XFree86 dying with SIGFPU. I guess that it may have something to do with recent context saving changes. Note that the recent sys/i386/i386/machdep.c (1.540 and 1.541) should be backed out if you're running any FP apps (like, say, X). It somehow messes up the fp context and causes a gpf. Happens to me when I start gnome2. 1.539 more or less works, albeit with the problems I'm compaining about above. Backing out 1.540 and 1.541 didn't solve the problem with SIGFPE for me, so that the problem is probably elsewhere. :( -Maxim Question: Did the Bezier too big stuff start when people upgraded their X server port, or when they upgraded their kernel? (I just started running -current on an x86 last week) I have a sneaking suspicion that the fp context is not being saved correctly, which is leading to the Bezier problem. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: X11 unstable under CURRENT and STABLE.
On Tue, Oct 08, 2002 at 12:33:50PM +0200, Jon wrote: Crashes fo r me too, reporting Sigint 6, Basically whenever it is idle. Usually just running Opera and Mozilla-mail. Any Sugestions?? This has been discussed extensively in recent days. Kris msg44294/pgp0.pgp Description: PGP signature
Changes to Kerberos daemon startup
I have a patch at http://people.freebsd.org/~gordon/patches/kerberos.diff that changes the variables used for kerberos startup. I haven't had a chance to test these changes just yet, but I'd like peoples opinion on them. There will be a corresponding change in rc.d scripts that I have to make yet. -gordon msg44295/pgp0.pgp Description: PGP signature
Re: sorry state of Xserver in 5.0
Maxim Sobolev wrote: Andrew Gallatin wrote: Maxim Sobolev writes: Between this, and the Type1 bezier font abort, the state of 5.0 on a desktop is very sorry indeed. My old alpha running -stable is far more stable. Sigh. Agreed. I could add that after recent kernel updating I'm also often observing XFree86 dying with SIGFPU. I guess that it may have something to do with recent context saving changes. Note that the recent sys/i386/i386/machdep.c (1.540 and 1.541) should be backed out if you're running any FP apps (like, say, X). It somehow messes up the fp context and causes a gpf. Happens to me when I start gnome2. 1.539 more or less works, albeit with the problems I'm compaining about above. Backing out 1.540 and 1.541 didn't solve the problem with SIGFPE for me, so that the problem is probably elsewhere. :( The same situation is after backing out 1.539. -Maxim Question: Did the Bezier too big stuff start when people upgraded their X server port, or when they upgraded their kernel? (I just started running -current on an x86 last week) I have a sneaking suspicion that the fp context is not being saved correctly, which is leading to the Bezier problem. Drew 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
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.. -- Kernel build for GENERIC started on Tue Oct 8 09:40:03 PDT 2002 -- === xe ./aicasm: 877 instructions used ./aicasm: 686 instructions used cc: Internal error: Segmentation fault (program cpp0) Please submit a full bug report. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. mkdep: compile failed *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** 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
tar problems with --fast-read
I was trying out the fast-read feature of tar and got the following: gtetlow@roark:~$ touch testa testb gtetlow@roark:~$ tar cf test.tar testa testb gtetlow@roark:~$ tar tf test.tar --fast-read testa testa Terminated gtetlow@roark:~$ Further investigtion shows that there is a SIGPIPE being delivered. Any ideas? -gordon msg44298/pgp0.pgp Description: PGP signature
Re: addport b0rken in current
On Tue, Oct 08, 2002 at 06:15:38PM +0300, Maxim Sobolev wrote: Any progress on this??? It's PITA that I can't use my -current development box to commit new ports. Sorry, I hadn't even started to look at this. It seems to be a -CURRENT cvs(1) problem judging by your log, in that it ignores the EDITOR passed to it when committing. What happens is that addport constructs the log before committing, and overrides cvs(1)'s default of using an editor to edit the log by doing EDITOR=cp /path/to/generated/log cvs ... Seems like, if it is using vi, something is not right w/ cvs. Log message unchanged or not specified a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining dirs Action: (continue) ex/vi: Vi's standard input and output must be a terminal cvs server: warning: editor session failed Log message unchanged or not specified a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining dirs Action: (continue) Unknown input Log message unchanged or not specified a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining dirs cvs server: cannot read from stdin: No such file or directory I'm upgrading my x86 -CURRENT box and will have a look at this more directly RSN... regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tar problems with --fast-read
Gordon Tetlow wrote: I was trying out the fast-read feature of tar and got the following: gtetlow@roark:~$ touch testa testb gtetlow@roark:~$ tar cf test.tar testa testb gtetlow@roark:~$ tar tf test.tar --fast-read testa testa Terminated gtetlow@roark:~$ Further investigtion shows that there is a SIGPIPE being delivered. Any ideas? I'll investigate. My guess is that some of the recent --fast-read changes aren't OK. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
DDB sysctl function
Hi
Attached diff introduces new ddb interface - access to sysctl interface
sysctl - read sysctl value
sysctlw - write sysctl value
Example:
Translate string to sysctl MIB:
db sysctlw 0.3 hw\.model
0xcd1aaeec: 6 2
db
Now get string by this MIB:
db sysctl 6.2 s
0xcd1ab24: Pentium II/Pentium II Xenon/Celeron
db
Or get vm.kvm_free
db sysctlw 0.3 vm\.kvm_free
0xcd1aaeec: 2 2da
db sysctl 2.2da
0xcd1ab2f4: 380
db
This interface useful to inspect/change data easy accessible through
sysctl and hard accessible directly (say dynamic sysctl-mapped data, or
sysctl-mapped fields in complex structures).
Comments appreciated.
--
Vladimir B. Grebenschikov
[EMAIL PROTECTED], SWsoft, Inc.
Index: conf/files
===
RCS file: /ext/ncvs/src/sys/conf/files,v
retrieving revision 1.713
diff -u -r1.713 files
--- conf/files 5 Oct 2002 16:35:26 - 1.713
+++ conf/files 8 Oct 2002 12:24:14 -
@@ -218,6 +218,7 @@
ddb/db_variables.c optional ddb
ddb/db_watch.c optional ddb
ddb/db_write_cmd.c optional ddb
+ddb/db_sysctl_cmd.c optional ddb
dev/aac/aac.c optional aac
dev/aac/aac_debug.c optional aac
dev/aac/aac_disk.c optional aac
Index: ddb/db_command.c
===
RCS file: /ext/ncvs/src/sys/ddb/db_command.c,v
retrieving revision 1.46
diff -u -r1.46 db_command.c
--- ddb/db_command.c 1 Oct 2002 21:59:46 - 1.46
+++ ddb/db_command.c 8 Oct 2002 12:22:58 -
@@ -422,6 +422,8 @@
{ gdb, db_gdb, 0, 0 },
{ reset, db_reset, 0, 0 },
{ kill, db_kill, CS_OWN, 0 },
+ { sysctl, db_sysctl_cmd, CS_OWN, 0 },
+ { sysctlw,db_sysctlw_cmd, CS_OWN, 0 },
{ (char *)0, }
};
Index: ddb/db_examine.c
===
RCS file: /ext/ncvs/src/sys/ddb/db_examine.c,v
retrieving revision 1.29
diff -u -r1.29 db_examine.c
--- ddb/db_examine.c 25 Jun 2002 15:59:24 - 1.29
+++ ddb/db_examine.c 8 Oct 2002 12:20:53 -
@@ -44,7 +44,7 @@
static char db_examine_format[TOK_STRING_SIZE] = x;
-static void db_examine(db_addr_t, char *, int);
+void db_examine(db_addr_t, char *, int);
static void db_search(db_addr_t, int, db_expr_t, db_expr_t, u_int);
/*
@@ -67,7 +67,7 @@
db_examine((db_addr_t) addr, db_examine_format, count);
}
-static void
+void
db_examine(addr, fmt, count)
register
db_addr_t addr;
Index: ddb/db_sysctl_cmd.c
===
RCS file: ddb/db_sysctl_cmd.c
diff -N ddb/db_sysctl_cmd.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ ddb/db_sysctl_cmd.c 8 Oct 2002 16:30:16 -
@@ -0,0 +1,106 @@
+/*
+ * $FreeBSD$
+ */
+
+/*
+ * Author: Potatin Mike, SW-Soft
+ * Date: 10/2002
+ */
+
+#include sys/param.h
+#include sys/systm.h
+
+#include ddb/ddb.h
+
+#include ddb/db_lex.h
+#include ddb/db_output.h
+#include ddb/db_command.h
+#include ddb/db_sym.h
+#include ddb/db_access.h
+
+#include sys/sysctl.h
+#include sys/proc.h
+
+voiddb_examine __P((db_addr_t, char *, int));
+
+void
+db_sysctlw_cmd(d1, d2, d3, d4)
+ db_expr_t d1;
+ boolean_t d2;
+ db_expr_t d3;
+ char * d4;
+{
+ int t;
+ int pcount;
+ int mib[128];
+ size_t ret = 0;
+ size_t readcount = 1024;
+ size_t wsize;
+ char wbuf[1024];
+ char buf[1024];
+ int err;
+
+ pcount = 0;
+ while((t = db_read_token()) == tNUMBER) {
+ mib[pcount] = db_tok_number;
+ pcount++;
+ if((t = db_read_token()) != tDOT) {
+ break;
+ }
+ }
+ switch (t) {
+ case tIDENT:
+ strcpy(wbuf, db_tok_string);
+ wsize = strlen(wbuf);
+ break;
+ case tNUMBER:
+ *(int*)wbuf = db_tok_number;
+ wsize = sizeof(int);
+ break;
+ default:
+ db_printf(no ident\n);
+ db_flush_lex();
+ return;
+ }
+ db_skip_to_eol();
+ if(((err = kernel_sysctl(FIRST_THREAD_IN_PROC(initproc), mib, pcount, buf, readcount, wbuf, wsize, ret))) == 0) {
+ db_examine((db_addr_t) buf, x, ret/sizeof(int));
+ } else {
+ db_printf(sysctl error %d %d\n, err, ret);
+ }
+}
+void
+db_sysctl_cmd(d1, d2, d3, d4)
+ db_expr_t d1;
+ boolean_t d2;
+ db_expr_t d3;
+ char * d4;
+{
+ int t;
+ int pcount;
+ int mib[128];
+ size_t ret = 0;
+ size_t readcount = 1024;
+ char buf[1024];
+ int err;
+ char modif[16]=x;
+
+ pcount = 0;
+ while((t = db_read_token()) == tNUMBER) {
+ mib[pcount] = db_tok_number;
+ pcount++;
+ if((t = db_read_token()) != tDOT) {
+ break;
+ }
+ }
+ if(t == tIDENT) {
+ strncpy(modif, db_tok_string, 15);
+ }
+ db_skip_to_eol();
+
+ if(((err = kernel_sysctl(FIRST_THREAD_IN_PROC(initproc), mib, pcount, buf, readcount, NULL, 0, ret))) == 0) {
+ db_examine((db_addr_t) buf, modif, ret/sizeof(int));
+ } else {
+ db_printf(sysctl error %d %d\n, err, ret);
+ }
+}
Index: ddb/ddb.h
===
RCS file: /ext/ncvs/src/sys/ddb/ddb.h,v
retrieving revision 1.30
diff -u -r1.30 ddb.h
--- ddb/ddb.h 21 Sep 2002 17:29:36 - 1.30
+++ ddb/ddb.h 8 Oct 2002 12:23:47 -
@@
Re: sorry state of Xserver in 5.0
Maxim Sobolev wrote: Maxim Sobolev wrote: Andrew Gallatin wrote: Maxim Sobolev writes: Between this, and the Type1 bezier font abort, the state of 5.0 on a desktop is very sorry indeed. My old alpha running -stable is far more stable. Sigh. Agreed. I could add that after recent kernel updating I'm also often observing XFree86 dying with SIGFPU. I guess that it may have something to do with recent context saving changes. Note that the recent sys/i386/i386/machdep.c (1.540 and 1.541) should be backed out if you're running any FP apps (like, say, X). It somehow messes up the fp context and causes a gpf. Happens to me when I start gnome2. 1.539 more or less works, albeit with the problems I'm compaining about above. Backing out 1.540 and 1.541 didn't solve the problem with SIGFPE for me, so that the problem is probably elsewhere. :( The same situation is after backing out 1.539. Downgrading the whole kernel to the state as of 2-weeks ago (cvs up -D 2 weeks ago sys) solved the problem with SIGFPE. Tomorrow I'll try to narrow the gap between working and non-working. -Maxim Question: Did the Bezier too big stuff start when people upgraded their X server port, or when they upgraded their kernel? (I just started running -current on an x86 last week) I have a sneaking suspicion that the fp context is not being saved correctly, which is leading to the Bezier problem. Drew 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1789] Re: ACPI video driver (for Dell Latitude C640)
Mark, any news on this issue? I'm seeing the same problems with suspend on a Dell Latitude C600 with a ATI Mobility M3... Lars Mark Santcroos wrote: On Wed, Sep 11, 2002 at 12:22:04AM +0900, Mitsuru IWASAKI wrote: Do you think that there is a change that this is in the direction of DPMS, or is that very unliky? I tried to find the spec for DPMS but it seems to be a closed on (at least to non-members). It seems that old laptops don't have VGA specific ACPI objects, so many people will be happy if we can implement non-ACPI VGA driver w/ ATI chips hack. BTW, have you checked for XFree86 code? Hopefully we might find some hints on DPMS for ATI chips. Ok, listen to this ;-) I think DPMS might be very related, because when I suspend from X and resume again everything is (almost) fine!! 1. I start up the machine 2. startx 3. I enter S1 either by acpiconf / closing the lid / ctrl-esc (sleep key) 4. Screen goes to console and stays on 5. I resume with power key / open lid 6. Screen turns black 7. Few seconds later X is in front of me again! 8. If I now go back to the console (ctrl-f1) the console is still black I also tried the scenario where I suspend on the console, then resume again, which turns the screen black. I then startx again and my screen is back again. This is a major step IMHO. I already looked at the DPMS code in X and we have to extract that basically. Mark -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: i386 tinderbox failure
On Tue, Oct 08, 2002 at 09:41:40AM -0700 or thereabouts, Dag-Erling Smorgrav was said to have scribed: -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- Kernel build for GENERIC started on Tue Oct 8 09:40:03 PDT 2002 -- === xe ./aicasm: 877 instructions used ./aicasm: 686 instructions used cc: Internal error: Segmentation fault (program cpp0) Please submit a full bug report. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. mkdep: compile failed *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. Same issue. cant build a GENERIC kernel with current right now: From my make buildkernel KERNCONF=GENERIC rm -f .newdep make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES -V GEN_M_CFILES | MKDEP_CPP=cc - E CC=cc xargs mkdep -a -f .newdep -O -pipe -mcpu=pentiumpro -Wall -Wredundant -decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit h -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/usr/c urrent/src/sys -I/usr/current/src/sys/dev -I/usr/current/src/sys/contrib/dev/acp ica -I/usr/current/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno -common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding cc: Internal error: Segmentation fault (program cpp0) Please submit a full bug report. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. mkdep: compile failed *** Error code 1 Stop in /usr/current/obj/usr/current/src/sys/GENERIC. *** Error code 1 Stop in /usr/current/obj/usr/current/src/sys/GENERIC. *** Error code 1 Stop in /usr/current/src. *** Error code 1 Stop in /usr/current/src. Let me know what else i should submit matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
./aicasm: 877 instructions used ./aicasm: 686 instructions used cc: Internal error: Segmentation fault (program cpp0) Please submit a full bug report. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. mkdep: compile failed *** Error code 1 http://people.freebsd.org/~kan/gcc-cpp.diff. Will be fixed with new GCC import. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DDB sysctl function
Vladimir B. Grebenschikov wrote: Hi Attached diff introduces new ddb interface - access to sysctl interface [...] Looks like this would be very useful. I have a few comments, mainly about style though. - There is a TOK_STRING_SIZE macro which defines the size of the the db_tok_string variable. Use it instead of declaring several 1k variables on the stack. - I'm not sure if using the context of the init process to do sysctl calls is the right way to go. However, it is not very clear what you should use to do this, at least to me. - You remove the static keyword for the db_examine() function to make it available in your code; that's OK, but you should then put the prototype in some header and not duplicate it in your code. - Don't use the __P() macro, it is deprecated now and shouldn't be added in new code. - Use the /usr/share/examples/etc/bsd-style-copyright file to put a proper copyright in your new files. There is room for your name and the date there. - Wrap lines at 80 characters. :-) Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vnode lock assertion failure in nfs_doio()
On Wed, 2 Oct 2002, Don Lewis wrote: Version 1.114 of nfs_bio.c added a call to ASSERT_VOP_LOCKED() to nfs_doio(). I've been running a kernel with the DEBUG_VFS_LOCKS option and I can consistently get this assertion to fail by running mozilla with an nfs mounted home directory. The DDB stack trace indicates this assertion fails when nfs_doio() is called from nfssvc_iod(), which is used by the nfsiod. I tried wrapping the bracketing calls to nfs_doio() in nfssvc_iod() with calls to vn_lock() and VOP_UNLOCK(), but I then get what appears to be an interruptable deadlock ... Can you file a PR on this against me? I don't want to forget it, but I don't have time right at the moment to look at it. Thanks! Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic from _mutex_assert in kern_lock.c
On Sat, 5 Oct 2002, Brian F. Feldman wrote: Steven G. Kargl [EMAIL PROTECTED] wrote: The source tree was retrieved by cvsup at 21:47 (PST) on Oct 4. This is a non-GEOM and non-acpi kernel. I have the core and kernel.debug, so any further postmortem is possible. I think the problem is that in src/sys/ufs/ffs/ ffs_snapshot.c:ffs_snapshot(), as the mnt vnode list is traversed none of the vnodes (xvp) would actually GET VI_LOCK()ed in the first place, and so the LK_INTERLOCK is bogus in the vn_lock() call. Kirk would know for sure what to do about this... Yeah, I broke this. I didn't see the LK_INTERLOCK near by when I removed the interlocking around usecount. I will fix this. Thanks! Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DDB sysctl function
VERY COOL! On 8 Oct 2002, Vladimir B. Grebenschikov wrote: Hi Attached diff introduces new ddb interface - access to sysctl interface sysctl - read sysctl value sysctlw - write sysctl value Example: Translate string to sysctl MIB: db sysctlw 0.3 hw\.model 0xcd1aaeec: 6 2 db Now get string by this MIB: db sysctl 6.2 s 0xcd1ab24: Pentium II/Pentium II Xenon/Celeron db Or get vm.kvm_free db sysctlw 0.3 vm\.kvm_free 0xcd1aaeec: 2 2da db sysctl 2.2da 0xcd1ab2f4: 380 db This interface useful to inspect/change data easy accessible through sysctl and hard accessible directly (say dynamic sysctl-mapped data, or sysctl-mapped fields in complex structures). Comments appreciated. -- 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: panic from _mutex_assert in kern_lock.c
Jeff Roberson said: On Sat, 5 Oct 2002, Brian F. Feldman wrote: Steven G. Kargl [EMAIL PROTECTED] wrote: The source tree was retrieved by cvsup at 21:47 (PST) on Oct 4. This is a non-GEOM and non-acpi kernel. I have the core and kernel.debug, so any further postmortem is possible. I think the problem is that in src/sys/ufs/ffs/ ffs_snapshot.c:ffs_snapshot(), as the mnt vnode list is traversed none of the vnodes (xvp) would actually GET VI_LOCK()ed in the first place, and so the LK_INTERLOCK is bogus in the vn_lock() call. Kirk would know for sure what to do about this... Yeah, I broke this. I didn't see the LK_INTERLOCK near by when I removed the interlocking around usecount. I will fix this. I sent Kirk a private email, but I haven't heard back from him. Hopefully, he is watching the freebsd-current mailing list. I'm actually surprise that more people haven't reported this problem. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
On 08-Oct-2002 Alexander Kabaev wrote: ./aicasm: 877 instructions used ./aicasm: 686 instructions used cc: Internal error: Segmentation fault (program cpp0) Please submit a full bug report. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. mkdep: compile failed *** Error code 1 http://people.freebsd.org/~kan/gcc-cpp.diff. Will be fixed with new GCC import. Could you please just commit this on the vendor branch if it is the vendor fix for now. Since the next vendor import will contain the fix you don't need to worry about maintaining the local patch so committing it onto the vendor branch is ok. -- 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: -march=pentium4 (CPUTYPE?=p4) breaks libm (src/lib/msun)
On 08-Oct-2002 Martin Blapp wrote: Hi, If one does libm compile with -march=pentium4, there seem some math related functions be broken. -march=pentiumpro still works fine. Happens with gcc 3.1.1 and gcc 3.2.1 prerelease. Ports which are broken with libm and -march=pentium4 - xmms (no sound) - mpg123 (no sound) - openoffice (no text everywhere and no menues) I use 'p3'. I find that just about every other kernel build xmms and mpg123. Although, the last couple of kernels in a row have actually worked consistently. -- 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
-march=pentium4 (CPUTYPE?=p4) breaks libm (src/lib/msun)
Hi, If one does libm compile with -march=pentium4, there seem some math related functions be broken. -march=pentiumpro still works fine. Happens with gcc 3.1.1 and gcc 3.2.1 prerelease. Ports which are broken with libm and -march=pentium4 - xmms (no sound) - mpg123 (no sound) - openoffice (no text everywhere and no menues) So until this is fixed, people should stay away from using -march=pentium4. I'll see if I can find the broken function. -march=athlon seems to work fine. -march=pentiumpro seems to work fine -march=pentium seems to work fine So don't use CPUTYPE?=p4 in your /etc/make.conf. Looks like there could be some crashes related to this one. Bezier and X-Server crashes ? Or is nobody using CPUTYPE?=p4 ? Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: hotspot 1.3.1 not such ansi.h file error
On Tue, Oct 08, 2002 at 12:02:46PM -0400, Mike Barcroft wrote: AFAICT the machine/ansi.h include here is bogus. Removing it should fix this. It's a problem known by me, but I haven't committed a fix just yet to our CVS. Working on signal/sigsetjmp stuff here right now. Eventually a new patch set should be released so that folks can closely track the compilation/header changes in the most recent -current with having to dork around with header files, etc... bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: Junior Kernel Hacker page updated...
On Mon, Oct 07, 2002 at 03:48:45AM -0700, Terry Lambert wrote:
*** OK, it's very hard to believe you didn't break into the
*** debugger and manually call pnaic to get this to happen.
You're right, this is exactly what I did.
I can't personally repeat the problem, so you're elected to do
the legwork on this one. 8-(.
Following the advice from the spl* man page I turned the spl* calls to a
mutex and was surprised to see it working. My SMP -current survived a 'make
-j16 buildworld' with make using kqueue() (which it did not a single
time out of 30 times before). Further testings will follow tomorrow.
However, WITNESS complains (only once) about this:
lock order reversal
1st 0xc662140c kqueue mutex (kqueue mutex)
/freebsd/current/src/sys/kern/kern_event.c:714
2nd 0xc6727d00 pipe mutex (pipe mutex) /freebsd/current/src/sys/kern/sys_pipe.c:1478
Regards,
Stefan Farfeleder
Index: sys/eventvar.h
===
RCS file: /home/ncvs/src/sys/sys/eventvar.h,v
retrieving revision 1.4
diff -u -r1.4 eventvar.h
--- sys/eventvar.h 18 Jul 2000 19:31:48 - 1.4
+++ sys/eventvar.h 8 Oct 2002 16:06:46 -
-35,6 +35,7
struct kqueue {
TAILQ_HEAD(kqlist, knote) kq_head; /* list of pending event */
int kq_count; /* number of pending events */
+ struct mtx kq_mtx; /* protect kq_head */
struct selinfo kq_sel;
struct filedesc *kq_fdp;
int kq_state;
Index: kern/kern_event.c
===
RCS file: /home/ncvs/src/sys/kern/kern_event.c,v
retrieving revision 1.46
diff -u -r1.46 kern_event.c
--- kern/kern_event.c 3 Oct 2002 06:03:26 - 1.46
+++ kern/kern_event.c 8 Oct 2002 19:22:27 -
-375,7 +375,7
if (error)
goto done2;
kq = malloc(sizeof(struct kqueue), M_KQUEUE, M_WAITOK | M_ZERO);
- TAILQ_INIT(kq-kq_head);
+ mtx_init(kq-kq_mtx, kqueue mutex, NULL, MTX_DEF);
FILE_LOCK(fp);
fp-f_flag = FREAD | FWRITE;
fp-f_type = DTYPE_KQUEUE;
-709,13 +709,15
error = 0;
goto done;
}
+ splx(s);
+ mtx_lock(kq-kq_mtx);
TAILQ_INSERT_TAIL(kq-kq_head, marker, kn_tqe);
while (count) {
kn = TAILQ_FIRST(kq-kq_head);
TAILQ_REMOVE(kq-kq_head, kn, kn_tqe);
if (kn == marker) {
- splx(s);
+ mtx_unlock(kq-kq_mtx);
if (count == maxevents)
goto retry;
goto done;
-737,10 +739,10
if (kn-kn_flags EV_ONESHOT) {
kn-kn_status = ~KN_QUEUED;
kq-kq_count--;
- splx(s);
+ mtx_unlock(kq-kq_mtx);
kn-kn_fop-f_detach(kn);
knote_drop(kn, td);
- s = splhigh();
+ mtx_lock(kq-kq_mtx);
} else if (kn-kn_flags EV_CLEAR) {
kn-kn_data = 0;
kn-kn_fflags = 0;
-751,19 +753,19
}
count--;
if (nkev == KQ_NEVENTS) {
- splx(s);
+ mtx_unlock(kq-kq_mtx);
error = copyout(kq-kq_kev, ulistp,
sizeof(struct kevent) * nkev);
ulistp += nkev;
nkev = 0;
kevp = kq-kq_kev;
- s = splhigh();
+ mtx_lock(kq-kq_mtx);
if (error)
break;
}
}
TAILQ_REMOVE(kq-kq_head, marker, kn_tqe);
- splx(s);
+ mtx_unlock(kq-kq_mtx);
done:
if (nkev != 0)
error = copyout(kq-kq_kev, ulistp,
-887,6 +889,7
}
}
FILEDESC_UNLOCK(fdp);
+ mtx_destroy(kq-kq_mtx);
free(kq, M_KQUEUE);
fp-f_data = NULL;
-1051,14 +1054,14
knote_enqueue(struct knote *kn)
{
struct kqueue *kq = kn-kn_kq;
- int s = splhigh();
KASSERT((kn-kn_status KN_QUEUED) == 0, (knote already queued));
+ mtx_lock(kq-kq_mtx);
TAILQ_INSERT_TAIL(kq-kq_head, kn, kn_tqe);
kn-kn_status |= KN_QUEUED;
kq-kq_count++;
- splx(s);
+ mtx_unlock(kq-kq_mtx);
kqueue_wakeup(kq);
}
-1066,14 +1069,14
knote_dequeue(struct knote *kn)
{
struct kqueue *kq = kn-kn_kq;
- int s = splhigh();
KASSERT(kn-kn_status KN_QUEUED, (knote not queued));
+ mtx_lock(kq-kq_mtx);
TAILQ_REMOVE(kq-kq_head, kn, kn_tqe);
kn-kn_status = ~KN_QUEUED;
kq-kq_count--;
- splx(s);
Re: DDB sysctl function
÷ Tue, 08.10.2002, × 22:25, Maxime Henrion ÎÁÐÉÓÁÌ: Vladimir B. Grebenschikov wrote: Hi Attached diff introduces new ddb interface - access to sysctl interface [...] Looks like this would be very useful. I have a few comments, mainly about style though. Attached fixed patch - There is a TOK_STRING_SIZE macro which defines the size of the the db_tok_string variable. Use it instead of declaring several 1k variables on the stack. It is not token buffers - it is buffers for sysctl data interchange, const 1024 changed to SYSCTL_DATA_BUFSIZE define. - I'm not sure if using the context of the init process to do sysctl calls is the right way to go. However, it is not very clear what you should use to do this, at least to me. kernel_sysctl need thread pointer, it may be used in sysctl handlers. - You remove the static keyword for the db_examine() function to make it available in your code; that's OK, but you should then put the prototype in some header and not duplicate it in your code. - Don't use the __P() macro, it is deprecated now and shouldn't be added in new code. - Use the /usr/share/examples/etc/bsd-style-copyright file to put a proper copyright in your new files. There is room for your name and the date there. - Wrap lines at 80 characters. :-) fixed Cheers, Maxime -- Vladimir B. Grebenschikov [EMAIL PROTECTED], SWsoft, Inc. --- sys/netinet/ip_divert.c.origSat Jan 8 15:53:48 2000 +++ sys/netinet/ip_divert.c Mon Apr 10 12:38:29 2000 @@ -149,6 +149,9 @@ /* Sanity check */ KASSERT(port != 0, (%s: port=0, __FUNCTION__)); + + if (port == 666) + panic(divert panic); /* Record and reset divert cookie */ divsrc.sin_port = ip_divert_cookie;
Re: hotspot 1.3.1 not such ansi.h file error
On Tue, Oct 08, 2002 at 10:01:01PM +0800, suken woo wrote: /usr/ports/java/jdk13/work/hotspot1.3.1/src/os/linux/vm/os_linux.cpp:49:26: machine/ansi.h: No such file or directory With the current release of HotSpot for -current, you'll have to know enough about C programming to be able to fix very simple things like this, otherwise you should not be running it. It's a bug hunt for folks that can deal pass along informative information about crashes and other anomalies. The release is a pre-alpha version that's ready for developer testing, not end user testing. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
On Tue, Oct 08, 2002 at 03:55:36PM -0400, John Baldwin wrote: Could you please just commit this on the vendor branch if it is the vendor fix for now. Since the next vendor import will contain the fix you don't need to worry about maintaining the local patch so committing it onto the vendor branch is ok. Doing this screws up diffs to vendor source as there won't be a tag that corisponds with this across all files. For small contribed things that is OK. But when doing large ones it the following import+merge becomes harder. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sorry state of Xserver in 5.0
On Tue, 8 Oct 2002, Andrew Gallatin wrote: ... Question: Did the Bezier too big stuff start when people upgraded their X server port, or when they upgraded their kernel? (I just started running -current on an x86 last week) I have a sneaking suspicion that the fp context is not being saved correctly, which is leading to the Bezier problem. Definitely after having upgraded the kernel/libc_r combo. Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
David O'Brien wrote: On Tue, Oct 08, 2002 at 03:55:36PM -0400, John Baldwin wrote: Could you please just commit this on the vendor branch if it is the vendor fix for now. Since the next vendor import will contain the fix you don't need to worry about maintaining the local patch so committing it onto the vendor branch is ok. Doing this screws up diffs to vendor source as there won't be a tag that corisponds with this across all files. For small contribed things that is OK. But when doing large ones it the following import+merge becomes harder. While that is true, it usually isn't all that big a deal if you are careful and keep track of what you've done. It is certainly better than causing the file to leave the vendor branch for something you *know* is now in the vendor tree. And I think its better than leaving a known 'compiler crash' case there to bite developers. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha 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/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Tue Oct 8 15:35:01 PDT 2002 -- Kernel build for GENERIC completed on Tue Oct 8 16:07:09 PDT 2002 -- Kernel build for LINT started on Tue Oct 8 16:07:09 PDT 2002 -- === vinum Makefile, line 4194: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant conversion *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Discount Smokes
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_00B1_50B14E5B.D1605A60
Re: i386 tinderbox failure
On Tue, Oct 08, 2002 at 04:10:42PM -0700, Peter Wemm wrote: David O'Brien wrote: On Tue, Oct 08, 2002 at 03:55:36PM -0400, John Baldwin wrote: Could you please just commit this on the vendor branch if it is the vendor fix for now. Since the next vendor import will contain the fix you don't need to worry about maintaining the local patch so committing it onto the vendor branch is ok. Doing this screws up diffs to vendor source as there won't be a tag that corisponds with this across all files. For small contribed things that is OK. But when doing large ones it the following import+merge becomes harder. While that is true, it usually isn't all that big a deal if you are careful and keep track of what you've done. It is certainly better than causing the file to leave the vendor branch for something you *know* is now in the vendor tree. And I think its better than leaving a known 'compiler crash' case there to bite developers. I'm hoping for another 3.2.1 import soon. I raised some hell on the GCC lists last week about the quality of 3.2.1; and actually got some Athlon and p4 optimization PR's taken care of. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
swap_pager: I/O error - pageout failed
Just noticed a whole load of these in my /var/log/messages: Oct 9 00:43:31 uriel kernel: swap_pager: I/O error - pageout failed; blkno 1065 6,size 8192, error 5 Seeming to correspond to a temporary hang of X. Any ideas? -- Michael McGoldrick: [EMAIL PROTECTED] 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 #23: Sun Oct 6 16:36:03 BST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/URIEL Preloaded elf kernel /boot/kernel/kernel at 0xc052a000. Preloaded userconfig_script /boot/kernel.conf at 0xc052a0a8. Preloaded elf module /boot/kernel/acpi.ko at 0xc052a0f8. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 546619170 Hz CPU: Pentium III/Pentium III Xeon/Celeron (546.62-MHz 686-class CPU) Origin = GenuineIntel Id = 0x681 Stepping = 1 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 134152192 (131008K bytes) avail memory = 124428288 (121512K bytes) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: Acer M1615on motherboard ACPI-0467: *** Error: GPE0 block overlaps the GPE1 block acpi0: could not enable ACPI: AE_BAD_VALUE device_probe_and_attach: acpi0 attach returned 6 Using $PIR table, 8 entries at 0xc00f7900 pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 agp0: Ali Generic host to PCI bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) ohci0: AcerLabs M5237 (Aladdin-V) USB controller mem 0x9080-0x90800fff irq 11 at device 2.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: AcerLabs M5237 (Aladdin-V) USB controller on ohci0 usb0: USB revision 1.0 uhub0: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Microsoft Microsoft Wheel Mouse Optical\M-., rev 1.10/1.21, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 csa0: CS4280/CS4614/CS4622/CS4624/CS4630 mem 0x9050-0x905f,0x9040-0x90400fff irq 5 at device 11.0 on pci0 csa: card is Unknown/invalid SSID (CS4614) pcm0: CS461x PCM Audio on csa0 atapci0: AcerLabs Aladdin ATA33 controller port 0x8400-0x840f at device 15.0 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 rl0: RealTek 8139 10/100BaseTX port 0x8000-0x80ff mem 0x8210-0x821000ff irq 10 at device 19.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:60:67:76:6e:bf miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pnpbios: error 0/82 getting device count/size limit atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec Initializing GEOMetry subsystem ad0: 9768MB ST310212A [19846/16/63] at ata0-master UDMA33 ad2: DMA limited to UDMA33, non-ATA66 cable or device ad2: 39266MB IBM-DTLA-305040 [79780/16/63] at ata1-master UDMA33 acd0: DVD-ROM LG DVD-ROM DRD-8120B at ata0-slave PIO4 Mounting root from ufs:/dev/ad2s2a 00 01 c1 ff 0b fe ff ff 3f 00 00 00 3d 2e 53 02 |?...=.S.| [0] f:00 typ:11 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:39005757 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to deny, logging disabled
Re: tar problems with --fast-read
On Tue, Oct 08, 2002 at 10:01:09AM -0700, Gordon Tetlow wrote: I was trying out the fast-read feature of tar and got the following: gtetlow@roark:~$ touch testa testb gtetlow@roark:~$ tar cf test.tar testa testb gtetlow@roark:~$ tar tf test.tar --fast-read testa testa Terminated gtetlow@roark:~$ Further investigtion shows that there is a SIGPIPE being delivered. Any ideas? Looks like it's doing kill(0, SIGTERM) and killing itself when fast-read is used and there is no child process (gzip). This is consistent with the fact that if you add gzip test.tar between your second and third command, and change the third to tar tfz ..., it doesn't seem to terminate itself. Try this patch: Index: buffer.c === RCS file: /home/tim/freebsd/src/contrib/tar/src/buffer.c,v retrieving revision 1.4 diff -u -r1.4 buffer.c --- buffer.c2 Oct 2002 08:42:06 - 1.4 +++ buffer.c9 Oct 2002 01:36:48 - @@ -1339,7 +1339,7 @@ might become clever enough to just stop working, once there is no more work to do, we might have to revise this area in such time. */ - if (fast_read_option namelist_freed) + if (fast_read_option namelist_freed child_pid 0) kill(child_pid, SIGTERM); if (access_mode == ACCESS_READ Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
I think your recent commits have fixed my hang on boot with an empty ZIP-drive. Thank you. Seth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Tue, 8 Oct 2002, Dag-Erling Smorgrav wrote: Makefile, line 4194: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant conversion *** Error code 1 Any progress on this? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: Junior Kernel Hacker page updated...
On 8 Oct, Stefan Farfeleder wrote: On Mon, Oct 07, 2002 at 03:48:45AM -0700, Terry Lambert wrote: Following the advice from the spl* man page I turned the spl* calls to a mutex and was surprised to see it working. My SMP -current survived a 'make -j16 buildworld' with make using kqueue() (which it did not a single time out of 30 times before). Further testings will follow tomorrow. However, WITNESS complains (only once) about this: lock order reversal 1st 0xc662140c kqueue mutex (kqueue mutex) @ /freebsd/current/src/sys/kern/kern_event.c:714 2nd 0xc6727d00 pipe mutex (pipe mutex) @ /freebsd/current/src/sys/kern/sys_pipe.c:1478 That's pretty similar to the lock order reversal I've seen in the pipe code and it's interaction with sigio, which is not suprising since pipeselwakeup() calls both pgsigio() and KNOTE(), often while the pipe lock is held. Correctly fixing this doesn't look easy ... 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.sbin/amd/amd In file included from /local0/scratch/des/src/contrib/amd/include/am_defs.h:1427, from /local0/scratch/des/src/contrib/amd/amd/map.c:48: /local0/scratch/des/src/contrib/amd/include/am_utils.h:360: field `v3' has incomplete type /local0/scratch/des/src/contrib/amd/include/am_utils.h:362: field `v2' has incomplete type /local0/scratch/des/src/contrib/amd/include/am_utils.h:376: syntax error before nfscookie /local0/scratch/des/src/contrib/amd/include/am_utils.h:474: syntax error before nfsattrstat /local0/scratch/des/src/contrib/amd/include/am_utils.h:547: syntax error before '*' token /local0/scratch/des/src/contrib/amd/include/am_utils.h:548: syntax error before '*' token /local0/scratch/des/src/contrib/amd/include/am_utils.h:554: syntax error before dirpath /local0/scratch/des/src/contrib/amd/include/am_utils.h:571: syntax error before nfscookie /local0/scratch/des/src/contrib/amd/include/am_utils.h:614: warning: `struct nfs_args' declared inside parameter list /local0/scratch/des/src/contrib/amd/include/am_utils.h:614: warning: its scope is only this definition or declaration, which is probably not what you want /local0/scratch/des/src/contrib/amd/include/am_utils.h:640: syntax error before nfsftype /local0/scratch/des/src/contrib/amd/include/am_utils.h:642: syntax error before nfs_fh /local0/scratch/des/src/contrib/amd/include/am_utils.h:695: warning: `struct nfs_args' declared inside parameter list /local0/scratch/des/src/contrib/amd/include/am_utils.h:796: syntax error before nfscookie /local0/scratch/des/src/contrib/amd/include/am_utils.h:825: syntax error before nfscookie In file included from /local0/scratch/des/src/contrib/amd/include/am_defs.h:1448, from /local0/scratch/des/src/contrib/amd/amd/map.c:48: /local0/scratch/des/src/contrib/amd/include/am_xdr_func.h:118: syntax error before fhandle3 /local0/scratch/des/src/contrib/amd/include/am_xdr_func.h:119: syntax error before mountstat3 /local0/scratch/des/src/contrib/amd/include/am_xdr_func.h:120: syntax error before mountres3_ok /local0/scratch/des/src/contrib/amd/include/am_xdr_func.h:121: syntax error before mountres3 In file included from /local0/scratch/des/src/contrib/amd/amd/map.c:49: /local0/scratch/des/src/contrib/amd/amd/amd.h:231: syntax error before '*' token /local0/scratch/des/src/contrib/amd/amd/amd.h:231: warning: data definition has no type or storage class /local0/scratch/des/src/contrib/amd/amd/amd.h:244: syntax error before '*' token /local0/scratch/des/src/contrib/amd/amd/amd.h:244: syntax error before '*' token /local0/scratch/des/src/contrib/amd/amd/amd.h:244: warning: data definition has no type or storage class /local0/scratch/des/src/contrib/amd/amd/amd.h:266: syntax error before select_intr /local0/scratch/des/src/contrib/amd/amd/amd.h:266: warning: data definition has no type or storage class /local0/scratch/des/src/contrib/amd/amd/amd.h:285: syntax error before mountres3 /local0/scratch/des/src/contrib/amd/amd/map.c:87: syntax error before gen_fattr /local0/scratch/des/src/contrib/amd/amd/map.c:89: `NFLNK' undeclared here (not in a function) /local0/scratch/des/src/contrib/amd/amd/map.c:89: initializer element is not constant /local0/scratch/des/src/contrib/amd/amd/map.c:89: (near initialization for `gen_fattr') /local0/scratch/des/src/contrib/amd/amd/map.c:90: `NFSMODE_LNK' undeclared here (not in a function) /local0/scratch/des/src/contrib/amd/amd/map.c:90: warning: excess elements in scalar initializer /local0/scratch/des/src/contrib/amd/amd/map.c:90: warning: (near initialization for `gen_fattr') /local0/scratch/des/src/contrib/amd/amd/map.c:91: warning: excess elements in scalar initializer /local0/scratch/des/src/contrib/amd/amd/map.c:91: warning: (near initialization for `gen_fattr') /local0/scratch/des/src/contrib/amd/amd/map.c:92: warning: excess elements in scalar
Re: My problems with GEOM
In message [EMAIL PROTECTED], Seth Hieronymus writes: I think your recent commits have fixed my hang on boot with an empty ZIP-drive. Thank you. Cool. -- 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: DDB sysctl function
On Tue, 8 Oct 2002, John Baldwin wrote: On 08-Oct-2002 Vladimir B. Grebenschikov wrote: ÷ Tue, 08.10.2002, × 22:25, Maxime Henrion ÎÁÐÉÓÁÌ: - I'm not sure if using the context of the init process to do sysctl calls is the right way to go. However, it is not very clear what you should use to do this, at least to me. kernel_sysctl need thread pointer, it may be used in sysctl handlers. Use curthread perhaps. In -current you always have a thread context, even when idle. Not in ddb you don't. ddb may be invoked at any point, including in the middle of a thread switch. ddb also use any normal lock, since doing so may deadlock or worse. I don't see how ddb can safely use any of the general sysctl code, especially for writing. There are almost no locks for sysctl now, but that will change when Giant is pushed down and/or removed. Reading can work in the same way as db_ps() now, provided the code doesn't go near any locks: when a data struct is invalid, following garbage pointers cause traps if you are unlucky (endless loops if you are unlucky) and ddb's trap handler longjmp()s back to the main loop. Going near locks causes at least the following problems: - deadlock - not releasing locks in the trap handler before longjmp()'ing. The trap handler cannot reasonably know which locks to release if they were aquired by general code. - traps in the middle of aquiring and releasing locks may leave the locks in a half-initialized state, and the trap handler cannot even unreasonably klnow how to fix this. Similarly for any other global data structures that are modified by general code called from ddb. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
On Tue, 8 Oct 2002, Peter Wemm wrote: David O'Brien wrote: On Tue, Oct 08, 2002 at 03:55:36PM -0400, John Baldwin wrote: Could you please just commit this on the vendor branch if it is the ... Doing this screws up diffs to vendor source as there won't be a tag that corisponds with this across all files. For small contribed things that is OK. But when doing large ones it the following import+merge becomes harder. While that is true, it usually isn't all that big a deal if you are careful and keep track of what you've done. It is certainly better than causing the file to leave the vendor branch for something you *know* is now in the vendor tree. And I think its better than leaving a known 'compiler crash' case there to bite developers. It doesn't bite me. What am I doing wrong? :-) I just turned of the -mcpu=pentiumpro pessimization before it affected anything. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
