Re: [HEADSUP]: Ports feature freeze for 8.1 now in effect
On Fri, 18 Jun 2010 14:10:28 +0200 Erwin Lansing er...@freebsd.org wrote: In preparation for 8.1-RELEASE, the ports tree is now in feature freeze. Normal upgrade, new ports, and changes that only affect other branches are allowed without prior approval but with the extra Feature safe: yes tag in the commit message. Any commit that is sweeping, i.e. touches a large number of ports, infrastructural changes, commits to ports with unusually high number of dependent ports, and any other commit that requires the rebuilding of many packages is not allowed without prior explicit approval from portmgr after that date. When in doubt, please do not hesitate to contact portmgr. any commit that requires the rebuilding of many packages And this time we will ask for instant back-out of everything that should had not been committed in the first place. If you have time, you can always help with unmaintained ports: http://qat.tecnik93.com/index.php?action=failed_buildportsmaintainer=ports%40freebsd.org; or even maintained ones: http://qat.tecnik93.com/index.php?action=failed_buildports Help us getting a good, stable package set for the release please, -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: [ HEADS UP ] Ports unstable for the next 10 days
On Tue, 20 Apr 2010 02:14:20 +0300 Ion-Mihai Tetcu ite...@freebsd.org wrote: A switch to use newer GMP version has been committed. Unfortunately lang/ghc and dependent ports (and possibly lang/gnat-gcc44) were broken by this. The brokenness wasn't detected in our -exp run because of being masked by other issues. A fix has been committed :) -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: [ HEADS UP ] Ports unstable for the next 10 days
On Mon, 19 Apr 2010 17:40:35 -0700 Garrett Cooper yanef...@gmail.com wrote: On Mon, Apr 19, 2010 at 4:38 PM, freebsd-po...@coreland.ath.cx wrote: On 2010-04-20 02:14:20, Ion-Mihai Tetcu wrote: A switch to use newer GMP version has been committed. I'm still investigating lang/gnat-gcc44. As far as I know, the gnat-gcc44 bootstrap binaries will be fine as they're bundled with the libgmp library that was used to build them. Whether gcc builds with the newer libgmp remains to be seen... As discussed in the QAT emails, it might be related to ccache use on the build cluster graciously donated by ixSystems, and the fact that the cached data is inconsistently distributed across the cluster. ATM no, the new cluster is in works, not yet used, QAT is running on a single machine, with ccache. I've provided some tips for itetcu to work around this on IRC (basically disable ccache), but it kind of sucks when you run into periodic issues with toolchain variance like this, s.t. building with NO_CACHE=yes is a necessary evil to work through end-to-end build functional issues. Problem is I need an automated solution. I'm testing it now on QAT with ccache disabled. Someone else who knows more about ccache could provide a better explanation of what's going on because my ranting about this would only be me talking out of my rear :). Yes, please. More info about ccache with FreeBSD can be found here: http://forums.freebsd.org/archive/index.php/t-174.html Thanks. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: [ HEADS UP ] Ports unstable for the next 10 days
On Tue, 20 Apr 2010 19:14:28 +0300 Ion-Mihai Tetcu ite...@freebsd.org wrote: I've provided some tips for itetcu to work around this on IRC (basically disable ccache), but it kind of sucks when you run into periodic issues with toolchain variance like this, s.t. building with NO_CACHE=yes is a necessary evil to work through end-to-end build functional issues. Problem is I need an automated solution. I'm testing it now on QAT with ccache disabled. Same error. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: [ HEADS UP ] Ports unstable for the next 10 days
A switch to use newer GMP version has been committed. Unfortunately lang/ghc and dependent ports (and possibly lang/gnat-gcc44) were broken by this. The brokenness wasn't detected in our -exp run because of being masked by other issues. It will take a few days to fix lang/ghc. I'm still investigating lang/gnat-gcc44. As a workaround, keep your old gmp library in /usr/local/lib/compat/pkg; both portmaster and portupdate have an option for this. X11 is still in work, the other are waiting for it. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: [ HEADS UP ] Ports unstable for the next 10 days
On Tue, 13 Apr 2010 16:03:22 -0700 Ted Faber fa...@isi.edu wrote: On Sun, Mar 28, 2010 at 04:38:28PM +0300, Ion-Mihai Tetcu wrote: Hi, As announced before, a few big commits, that touch some thousands ports are being done: png, curl, x11, gnome, kde4. The target ETA is 6-7 April. I didn't see any mial, but figured I'd check. Are ports still unstable? ATM no, as it's apparent from the message bellow. Update to that message: - Gnome and KDE are ready - Xorg is believed to be ready, an -exp run on pointy is beginning today. On Thu, 8 Apr 2010 13:23:08 -0700 Charlie Kester corky1...@comcast.net wrote: On Sun 28 Mar 2010 at 06:38:28 PDT Ion-Mihai Tetcu wrote: Hi, As announced before, a few big commits, that touch some thousands ports are being done: png, curl, x11, gnome, kde4. The target ETA is 6-7 April. The first one was done, update of graphics/png (including a shared lib version bump), with about 5000 ports affected. We do _NOT_ recommend updating ports until this commits are all done, and the problems are fixed, except if you want to help testing / fixing. Before reporting failures, please take a look at ports@ list, and http://qat.tecnik93.com/index.php?action=failed_buildportssort=last_built to find out if the problem hasn't already been reported or even fixed. We also have two incremental builds on Pointy to catch the problems. Thank you, With hat:portmgr@ Sorry if this seems like nagging, but since we're now past the original ETA can we get a current status report? Is the portstree considered stable again, and if not, what's the revised ETA? From: Ion-Mihai Tetcu ite...@freebsd.org To: Ion-Mihai Tetcu ite...@freebsd.org Cc: sta...@freebsd.org, questi...@freebsd.org, freebsd-po...@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days Date: Mon, 5 Apr 2010 21:31:33 +0300 Just a status update: PNG and cURL are in, and png fall-outs are believed to be fixed. Xorg update has gone through an -exp run on Pointy and our xorg team is working on fixing the approx. 60 ports with problems. still work to do I will begin -exp runs for Gnome and KDE updates tonight or tomorrow morning. Gnome -exp done, there's a showstopper on amd64 that we weren't aware of. about 40 fixesso far. An other -exp needed. KDE in progress. Packages status: - i386: - 6 after png and curl - 7 after png and curl - an 8 incremental build is in progress and should be shortly finished finished - 9 pacakges are from middle March from 9 Apr. - amd64: - 6 packages are post png and curl - 7 build is in progress and will be finished tomorrow - 8 last build was done in the middle of the png update/fixes; we won't run an other before Xorg, KDE and Gnome go in (for lack of resources). in progress, with ports from yesterday - 9 build in progress (with sources that are believed to fix the zlib problem). nope, still old packages. In other words, if you wish to update without waiting for Xorg, Gnome and KDE now it's a good moment. So no clear ETA yet, a few days more. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: [ HEADS UP ] Ports unstable for the next 10 days
On Wed, 7 Apr 2010 07:20:47 -0500 Antonio Olivares olivares14...@gmail.com wrote: [ .. ] === Port directory: /usr/ports/sysutils/fusefs-kmod === This port is marked IGNORE === requires the userland sources to be installed. Set SRC_BASE if it is not in /usr/src === If you are sure you can build it, remove the IGNORE line in the Makefile and try again. === Update for sysutils/fusefs-kmod failed === Aborting update [ .. ] What should I do in this case? First, please don't top post. Second, you don't seem to have the base sources installed and that port, being a kernel module, needs them. See: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: [ HEADS UP ] Ports unstable for the next 10 days
Just a status update: PNG and cURL are in, and png fall-outs are believed to be fixed. Xorg update has gone through an -exp run on Pointy and our xorg team is working on fixing the approx. 60 ports with problems. I will begin -exp runs for Gnome and KDE updates tonight or tomorrow morning. Packages status: - i386: - 6 after png and curl - 7 after png and curl - an 8 incremental build is in progress and should be shortly finished - 9 pacakges are from middle March - amd64: - 6 packages are post png and curl - 7 build is in progress and will be finished tomorrow - 8 last build was done in the middle of the png update/fixes; we won't run an other before Xorg, KDE and Gnome go in (for lack of resources). - 9 build in progress (with sources that are believed to fix the zlib problem). In other words, if you wish to update without waiting for Xorg, Gnome and KDE now it's a good moment. HTH, -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
[ HEADS UP ] Ports unstable for the next 10 days
Hi, As announced before, a few big commits, that touch some thousands ports are being done: png, curl, x11, gnome, kde4. The target ETA is 6-7 April. The first one was done, update of graphics/png (including a shared lib version bump), with about 5000 ports affected. We do _NOT_ recommend updating ports until this commits are all done, and the problems are fixed, except if you want to help testing / fixing. Before reporting failures, please take a look at ports@ list, and http://qat.tecnik93.com/index.php?action=failed_buildportssort=last_built to find out if the problem hasn't already been reported or even fixed. We also have two incremental builds on Pointy to catch the problems. Thank you, With hat: portmgr@ -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: [ HEADS UP ] Ports unstable for the next 10 days
On Sun, 28 Mar 2010 17:56:34 +0200 Tobias Roth freebsd.li...@fsck.ch wrote: On 3/28/10 3:38 PM, Ion-Mihai Tetcu wrote: Hi, As announced before, a few big commits, that touch some thousands ports are being done: png, curl, x11, gnome, kde4. The target ETA is 6-7 April. The first one was done, update of graphics/png (including a shared lib version bump), with about 5000 ports affected. We do _NOT_ recommend updating ports until this commits are all done, and the problems are fixed, except if you want to help testing / fixing. What does that mean, the first one was done? The port was updated before this warning? I have updated png this morning, will I now be negatively affected? PNG update was committed this morning at 06:47:48 UTC. If you have updated png (not just csup your ports tree) then you'll probably have to update the rest of your ports, since they won't find the old png shared lib. (you could try to map the new lib to the old one, it might or not work) -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: Unhappy Xorg upgrade
On Thu, 19 Feb 2009 12:22:03 -0600 Robert Noland rnol...@freebsd.org wrote: On Thu, 2009-02-19 at 16:39 +0100, Dimitry Andric wrote: On 2009-02-19 13:21, Stephen Clark wrote: (II) Loading /usr/local/lib/xorg/modules/extensions//vnc.so dlopen: /usr/local/lib/xorg/modules/extensions//vnc.so: Undefined symbol NumCurrentSelections This is a VNC problem, it uses an old API which has been removed in newer X.org servers: http://cgit.freedesktop.org/xorg/xserver/commit/?id=34bf308a9e66f1a2f48630a15b1802afad50ec24 See also here (and for possible workarounds): https://bugs.launchpad.net/bugs/260815 This is best directed to tight-vnc maintainer, cc'd Thanks Robert. I also have a PR on about this port, I hope to have time to work on both this issues this weekend. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: Strange problem with skype on RELENG_6 KERNEL since the end of may.
On Thu, 14 Jun 2007 09:29:09 -0500 [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: A RELENG_6 kernel from May 21 works fine with skype but boot a newer kernel and skype seems to be blocking port 80. Apache logs show nothing. I can find no logs errors anywhere but a telnet to port 80 answers with what would seem to be binary chars. I close skype and all is back to normal. I had originally thought that it had to do with the new xorg installation but it seems to be something in the kernel. The configurations were the same, basically GENERIC with all the pf stuff. I won't even ask if anyone else is seeing it. I have a hard time believing it myself. Did you put skype to listen on port 80 by any chance ? There's no other reason I can think of. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect signature.asc Description: PGP signature
PAE doesn't compile on 6[.1] because of bce
[re@ CC'ed as they are probably interested in this for 6.1 release ] Hi, With today sources and KERNCONF=PAE on 6-STABLE : cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/dev/bce/if_bce.c /usr/src/sys/dev/bce/if_bce.c: In function `bce_attach': /usr/src/sys/dev/bce/if_bce.c:542: warning: large integer implicitly truncated to unsigned type /usr/src/sys/dev/bce/if_bce.c:544: warning: large integer implicitly truncated to unsigned type /usr/src/sys/dev/bce/if_bce.c: In function `bce_stats_update': /usr/src/sys/dev/bce/if_bce.c:5311: warning: left shift count = width of type /usr/src/sys/dev/bce/if_bce.c:5313: warning: left shift count = width of type /usr/src/sys/dev/bce/if_bce.c:5315: warning: left shift count = width of type /usr/src/sys/dev/bce/if_bce.c:5317: warning: left shift count = width of type *** Error code 1 Stop in /usr/obj/usr/src/sys/PAE. Same for 6.1 according to simon@ If I can be of any help please let me know, -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect Ferengi Rule of Acquisition #3: Never pay more for an acquisition than you have to. -- ST:DS9, The Maquis, Part II ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nve timeout (and down) regression?
On Thu, 23 Mar 2006 14:34:24 -0800 Kevin Oberman [EMAIL PROTECTED] wrote: Date: Thu, 23 Mar 2006 21:59:56 + (UTC) From: Bjoern A. Zeeb [EMAIL PROTECTED] On Thu, 23 Mar 2006, JoaoBR wrote: On Thursday 23 March 2006 15:59, Bjoern A. Zeeb wrote: nve did not worked on 6.0R (for me) but cvsup to stable resolved the case (for me) in end of dezember since a month or so with recent releng_6 the problem came back, timeouts and stopping rx/tx did you do more updates in the timeframe from december to about a month ago? if the problem was gone and is back now any (exact) dates to narrow down the timeframe where the problem came back would be very helpful. nve0: NVIDIA nForce MCP9 Networking Adapter port 0xbc00-0xbc07 mem 0xfebfa000-0xfebfafff irq 22 at device 10.0 on pci0 nve0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfebfa000 nve0: Ethernet address 00:0a:48:1d:c6:97 miibus1: MII bus on nve0 nve0: bpf attached nve0: Ethernet address: 00:0a:48:1d:c6:97 nve0: [MPSAFE] This happens w/o any real activity on that interface (which goes into an Allied Telesyn switch): ... Mar 24 19:39:54 worf kernel: nve0: device timeout (1) Mar 24 19:39:54 worf kernel: nve0: link state changed to DOWN Mar 24 19:39:55 worf kernel: nve0: link state changed to UP Mar 24 19:40:14 worf kernel: nve0: device timeout (1) Mar 24 19:40:14 worf kernel: nve0: link state changed to DOWN Mar 24 19:40:15 worf kernel: nve0: link state changed to UP Mar 24 19:40:33 worf kernel: nve0: device timeout (2) Mar 24 19:40:33 worf kernel: nve0: link state changed to DOWN Mar 24 19:40:34 worf kernel: nve0: link state changed to UP Mar 24 19:45:52 worf kernel: nve0: device timeout (1) Mar 24 19:45:52 worf kernel: nve0: link state changed to DOWN Mar 24 19:45:53 worf kernel: nve0: link state changed to UP . FreeBSD worf.tecnik93.com 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Tue Mar 21 01:39:15 EET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect BOFH excuse #442: Trojan horse ran out of hay ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nve timeout (and down) regression?
On Fri, 24 Mar 2006 12:55:41 -0800 Kevin Oberman [EMAIL PROTECTED] wrote: Date: Fri, 24 Mar 2006 22:33:17 +0200 From: Ion-Mihai Tetcu [EMAIL PROTECTED] On Thu, 23 Mar 2006 14:34:24 -0800 Kevin Oberman [EMAIL PROTECTED] wrote: Date: Thu, 23 Mar 2006 21:59:56 + (UTC) From: Bjoern A. Zeeb [EMAIL PROTECTED] On Thu, 23 Mar 2006, JoaoBR wrote: On Thursday 23 March 2006 15:59, Bjoern A. Zeeb wrote: nve did not worked on 6.0R (for me) but cvsup to stable resolved the case (for me) in end of dezember since a month or so with recent releng_6 the problem came back, timeouts and stopping rx/tx did you do more updates in the timeframe from december to about a month ago? if the problem was gone and is back now any (exact) dates to narrow down the timeframe where the problem came back would be very helpful. nve0: NVIDIA nForce MCP9 Networking Adapter port 0xbc00-0xbc07 mem 0xfebfa000-0xfebfafff irq 22 at device 10.0 on pci0 nve0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfebfa000 nve0: Ethernet address 00:0a:48:1d:c6:97 miibus1: MII bus on nve0 nve0: bpf attached nve0: Ethernet address: 00:0a:48:1d:c6:97 nve0: [MPSAFE] This happens w/o any real activity on that interface (which goes into an Allied Telesyn switch): ... Mar 24 19:39:54 worf kernel: nve0: device timeout (1) Mar 24 19:39:54 worf kernel: nve0: link state changed to DOWN Mar 24 19:39:55 worf kernel: nve0: link state changed to UP Mar 24 19:40:14 worf kernel: nve0: device timeout (1) Mar 24 19:40:14 worf kernel: nve0: link state changed to DOWN Mar 24 19:40:15 worf kernel: nve0: link state changed to UP Mar 24 19:40:33 worf kernel: nve0: device timeout (2) Mar 24 19:40:33 worf kernel: nve0: link state changed to DOWN Mar 24 19:40:34 worf kernel: nve0: link state changed to UP Mar 24 19:45:52 worf kernel: nve0: device timeout (1) Mar 24 19:45:52 worf kernel: nve0: link state changed to DOWN Mar 24 19:45:53 worf kernel: nve0: link state changed to UP . FreeBSD worf.tecnik93.com 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Tue Mar 21 01:39:15 EET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 Note that we are running on i386 running am an AMD64 platform. I just enabled the nve0 on my desktop (I'm using sk0, it's a Asus A8N-SLI Deluxe motherboard, both interfaces connected to the same 8-port Surecom switch - talking about very inexpensive :) and it seems to work OK. nve0: NVIDIA nForce MCP9 Networking Adapter port 0xb000-0xb007 mem 0xca10-0xca100fff irq 23 at device 10.0 on pci0 nve0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xca10 nve0: Ethernet address 00:15:f2:39:09:08 miibus1: MII bus on nve0 nve0: bpf attached nve0: Ethernet address: 00:15:f2:39:09:08 nve0: [MPSAFE] FreeBSD it.buh.tecnik93.com 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Fri Feb 24 07:01:54 EET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/IT6_B_P i386 I updated my system (which was happy on Feb. 15 code) to March 13 code and I am still running fine. No errors at all. Also, another system was updated to RELENG_6 yesterday and it is also running clean. Again, all systems are identical dual core AMD64 systems running i386 code. (We would like to run amd64, but OpenOffice.org still does not run on it and we need that.) Both my systems are single core single CPU. Only the system in Iowa with the AT switch is seeing problems. Even if there is no traffic, it is possible that something that is negotiated by the switch is triggering the problem. Possibly, but I think I remember seeing the same w/o cable plugged-in; I'll try to remember to test this for a a few minutes when I'll be on-site next week. -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect BOFH excuse #266: All of the packets are empty ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [SOLVED] cnet compile problem
On Wed, 08 Mar 2006 13:12:15 +1100 B .Wiggins [EMAIL PROTECTED] wrote: Hello Brett, I am currently studying a Data communications and networking subject at Monash University. I am using cnet at home for the labs on my FreeBSD notebook as we are using William Stallings' textbook. There seems to be a problem with the cnet source code. I have emailed the FreeBSD cnet maintainer and they suggested emailing you. Basically the problem is as follows; All of these errors are the same and stem from the fact that your version of cnet, v2.0.9 I think, was built before the latest versions of gcc (in FreeBSD and Fedora, among others) became more aggressive about parameter type checking. Heh, so I was right. I will update the port. Thanks, -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect BOFH excuse #204: Just pick up the phone and give modem connect sounds. Well you said we should get more lines so we don't have voice lines. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fdisk, bsdlabel and hidden tricks
On Tue, 31 Jan 2006 23:22:13 + (GMT) [EMAIL PROTECTED] (Bill Paul) wrote: Also, when creating what's supposed to be /, make sure you toggle off softupdates in the label editor. It's smart enough to only enable softupdates by default on non-root filesystems, but it only knows this by checking if the name of the filesystem is /. Why is this important? I don't know if this is a bug or expected broken behavior, but when I created / with softupdates enabled, I found the ls(1) command would crash or report strange output whenever I did ls -l. It seems to be unable to read the file mode information correctly. This was true of _all_ filesystems, not just /. The Soekris board would otherwise run correctly. Once I realized my mistake, I went back and recreated the rootfs with softupdates off, and the problem went away. This is probably yet another we don't do that by default so we won't bother testing it bug. I don't think I'm seeing this here on a FreeBSD 6.0-STABLE #0: Wed Jan 11 05:29:04 EET 2006 [EMAIL PROTECTED] -SSH- /home/itetcu [2:18:47] 0 mount /dev/ad0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/ad0s1d on /var (ufs, local, soft-updates) devfs on /var/named/dev (devfs, local) [EMAIL PROTECTED] -SSH- /home/itetcu [2:18:49] 0 ll total 52 -rw-r--r-- 1 itetcu wheel 767 Jan 10 08:08 .cshrc -rw--- 1 itetcu wheel 1402 Jan 31 18:34 .history -rw-r--r-- 1 itetcu wheel 248 Jan 10 08:08 .login -rw-r--r-- 1 itetcu wheel 158 Jan 10 08:08 .login_conf -rw--- 1 itetcu wheel 373 Jan 10 08:08 .mail_aliases -rw-r--r-- 1 itetcu wheel 331 Jan 10 08:08 .mailrc -rw-r--r-- 1 itetcu wheel 797 Jan 10 08:08 .profile -rw--- 1 itetcu wheel 276 Jan 10 08:08 .rhosts -rw-r--r-- 1 itetcu wheel 975 Jan 10 08:08 .shrc drwxr-xr-x 2 itetcu wheel 512 Jan 12 00:10 .ssh drwxr-xr-x 2 itetcu wheel 512 Jan 11 18:40 authlib -r--r--r-- 1 itetcu wheel 7646 Jan 11 18:40 clamd.conf -rw-r--r-- 1 itetcu wheel 1540 Jan 11 18:40 clamsmtpd.conf drwxr-xr-x 4 itetcu wheel 512 Jan 11 18:41 courier-imap drwxr-xr-x 2 itetcu wheel 512 Jan 11 18:38 master -r--r--r-- 1 itetcu wheel 3016 Jan 11 18:39 multitail.conf drwxr-xr-x 3 itetcu wheel 1024 Jan 11 18:42 postfix -rw-r--r-- 1 itetcu wheel 3312 Jan 11 18:39 screenrc -rw-r--r-- 1 rootwheel 5273 Jan 14 04:23 smart.initial -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect The more complex the mind, the greater the need for the simplicity of -- Kirk, Shore Leave, stardate 3025.8 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
VT8237(VT6410) SATA Interrupt storm
Hi, On my 6.0-STABLE #1: Mon Jan 23 00:45:10 EET 2006 while burning a DVD image i got this: Jan 24 09:33:10 it kernel: Interrupt storm detected on irq20: atapci0; throttling interrupt source Jan 24 09:33:15 it kernel: ata2: reiniting channel .. Jan 24 09:33:15 it kernel: ata2: SATA connect ready time=0ms Jan 24 09:33:15 it kernel: ata2: sata_connect devices=0x1ATA_MASTER Jan 24 09:33:15 it kernel: ata2: reinit done .. Jan 24 09:33:15 it kernel: ad4: TIMEOUT - READ_DMA retrying (1 retry left) LBA=118347775 Jan 24 09:40:20 it kernel: ata2: reiniting channel .. Jan 24 09:40:20 it kernel: ata2: SATA connect ready time=0ms Jan 24 09:40:20 it kernel: ata2: sata_connect devices=0x1ATA_MASTER Jan 24 09:40:20 it kernel: ata2: reinit done .. Jan 24 09:40:20 it kernel: ad4: TIMEOUT - READ_DMA retrying (1 retry left) LBA=127662527 Jan 24 09:44:17 it kernel: ata2: reiniting channel .. Jan 24 09:44:17 it kernel: ata2: SATA connect ready time=0ms Jan 24 09:44:17 it kernel: ata2: sata_connect devices=0x1ATA_MASTER Jan 24 09:44:17 it kernel: ata2: reinit done .. Jan 24 09:44:17 it kernel: ad4: TIMEOUT - READ_DMA retrying (1 retry left) LBA=133759391 systat -vmstat 1 shows between 400 and 800 interrupts while doing a md5 over a 4GB file on the SATA disk and a few when no big reads are done. On copying a 700 file from the PATA disk there are ~208 interrupts/second (while for the controller I'm copying from they are approx. 1/2 - around 98-107). I haven't seen any bad effects of this in the few hours I'm working with this SATA disk. How worried should I be :) ? atapci0: VIA 6420 SATA150 controller port 0xb000-0xb007,0xb400-0xb403,0xb800-0xb807,0xbc00-0xbc03,0xc000-0xc00f,0xc400-0xc4ff irq 20 at device 15.0 on pci 0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xc000 atapci0: [MPSAFE] atapci0: Reserved 0x100 bytes for rid 0x24 type 4 at 0xc400 ata2: ATA channel 0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xb000 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xb400 ata2: SATA connect ready time=0ms ata2: sata_connect devices=0x1ATA_MASTER ata2: [MPSAFE] ata3: ATA channel 1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xb800 atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xbc00 ata3: SATA connect status= ata3: [MPSAFE] atapci1: VIA 8237 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc800-0xc80f at device 15.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xc800 ata0: ATA channel 0 on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=50 devices=0x3ATA_SLAVE,ATA_MASTER ata0: [MPSAFE] ata1: ATA channel 1 on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci1: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x4ATAPI_MASTER ata1: [MPSAFE] [EMAIL PROTECTED]:15:0: class=0x01018f card=0x31491106 chip=0x31491106 rev=0x80 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT8237 VT6410 SATA RAID Controller' class= mass storage subclass = ATA [EMAIL PROTECTED]:15:1: class=0x01018a card=0x50021458 chip=0x05711106 rev=0x06 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82 EIDE Controller (All VIA Chipsets)' class= mass storage subclass = ATA # atacontrol info ata2 Master: ad4 Maxtor 6L080M0/BACE1G10 Serial ATA v1.0 Slave: no device present # atacontrol mode ad4 current mode = SATA150 # atacontrol cap ad4 Protocol Serial ATA v1.0 device model Maxtor 6L080M0 serial number L21G8EPG firmware revision BACE1G10 cylinders 16383 heads 16 sectors/track 63 lba supported 160086528 sectors lba48 not supported dma supported overlap not supported Feature Support EnableValue Vendor write cacheyes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes no 0/0x00 automatic acoustic management yes yes 254/0xFE192/0xC0 -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect BOFH excuse #92: Stale file handle (next time use Tupperware(tm)!) ___ freebsd-stable@freebsd.org mailing
Re: panic: mb_dtor_mbuf: M_EXT set
On Mon, 23 Jan 2006 17:31:47 +0300 Gleb Smirnoff [EMAIL PROTECTED] wrote: On Mon, Jan 23, 2006 at 04:27:09PM +0200, Ion-Mihai Tetcu wrote: I On Sun, Jan 22, 2006 at 11:58:54PM +0200, Ion-Mihai Tetcu wrote: I I On Sun, Jan 22, 2006 at 04:17:12PM +0300, Gleb Smirnoff I I wrote: I I On Sat, Jan 21, 2006 at 03:09:02PM +0300, Gleb Smirnoff I I wrote: I I T This should be fixed in src/sys/kern_mbuf.c, rev. I I T 1.9.2.3 I I I I And another bogus panic is removed in 1.9.2.4 I I I I I I The kernel is working again, thanks! I I I I It's working in regard of vr0, thank you. However now my I I computer resets w/o anything logged when starting kde; if I I I only startx it doesn't happen (without exec startkde I I in .xinitrc); I commented out any fancy options like dri with I I no effect and it also happen if I kldunload snd_via8233 I I before starting kde. I I I I This is with 1.9.2.3 (cvsupped around 21 to 22 midnight; it I I didn't happen with sources from 19. I I Bad news. Can you do a binary search and find commit that makes I this regression? I I FreeBSD 6.0-STABLE #1: Mon Jan 23 00:45:10 EET 2006 works:) So upgrading once more did help you? So it seem. I am using ULE, I have no problem with the new kernel with either UL or 4BSD. I didn't test the bad kernel with 4BSD, but I could do it if you like. -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect BOFH excuse #336: the xy axis in the trackball is coordinated with the summer solstice ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mb_dtor_mbuf: M_EXT set
On Mon, 23 Jan 2006 11:05:25 +0300 Gleb Smirnoff [EMAIL PROTECTED] wrote: On Sun, Jan 22, 2006 at 11:58:54PM +0200, Ion-Mihai Tetcu wrote: I On Sun, Jan 22, 2006 at 04:17:12PM +0300, Gleb Smirnoff wrote: I On Sat, Jan 21, 2006 at 03:09:02PM +0300, Gleb Smirnoff wrote: I T This should be fixed in src/sys/kern_mbuf.c, rev. 1.9.2.3 I I And another bogus panic is removed in 1.9.2.4 I I I The kernel is working again, thanks! I I It's working in regard of vr0, thank you. However now my computer I resets w/o anything logged when starting kde; if I only startx it I doesn't happen (without exec startkde in .xinitrc); I commented I out any fancy options like dri with no effect and it also happen I if I kldunload snd_via8233 before starting kde. I I This is with 1.9.2.3 (cvsupped around 21 to 22 midnight; it didn't I happen with sources from 19. Bad news. Can you do a binary search and find commit that makes this regression? FreeBSD 6.0-STABLE #1: Mon Jan 23 00:45:10 EET 2006 works:) -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect BOFH excuse #113: Root nameservers are out of sync ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mb_dtor_mbuf: M_EXT set
On Mon, 23 Jan 2006 17:39:56 +0300 Gleb Smirnoff [EMAIL PROTECTED] wrote: On Mon, Jan 23, 2006 at 04:35:07PM +0200, Ion-Mihai Tetcu wrote: I On Mon, Jan 23, 2006 at 04:27:09PM +0200, Ion-Mihai Tetcu wrote: I I On Sun, Jan 22, 2006 at 11:58:54PM +0200, Ion-Mihai Tetcu I I wrote: I I I On Sun, Jan 22, 2006 at 04:17:12PM +0300, Gleb Smirnoff I I I wrote: I I I On Sat, Jan 21, 2006 at 03:09:02PM +0300, Gleb I I I Smirnoff wrote: I I I T This should be fixed in src/sys/kern_mbuf.c, I I I T rev. 1.9.2.3 I I I I I I And another bogus panic is removed in 1.9.2.4 I I I I I I I I I The kernel is working again, thanks! I I I I I I It's working in regard of vr0, thank you. However now my I I I computer resets w/o anything logged when starting kde; I I I if I only startx it doesn't happen (without exec startkde I I I in .xinitrc); I commented out any fancy options like dri I I I with no effect and it also happen if I kldunload I I I snd_via8233 before starting kde. I I I I I I This is with 1.9.2.3 (cvsupped around 21 to 22 midnight; I I I it didn't happen with sources from 19. I I I I Bad news. Can you do a binary search and find commit that I I makes this regression? I I I I FreeBSD 6.0-STABLE #1: Mon Jan 23 00:45:10 EET 2006 I I works:) I I So upgrading once more did help you? I I So it seem. I am using ULE, I have no problem with the new kernel I with either UL or 4BSD. I didn't test the bad kernel with 4BSD, I but I could do it if you like. Probably you hit another incorrect KASSERT in kern_mbuf.c. I have removed it some time after the first one. Since X was starting at this moment you couldn't be dropped into debugger, and so the box was rebooting. I don't know if I understand you right, but starting a bare X and playing around for a while then typing startkde resulted in a reset. -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect Ferengi Rule of Acquisition #168: Whisper your way to success. -- ST:DS9, Treachery, Faith, and the Great River ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mb_dtor_mbuf: M_EXT set
On Mon, 23 Jan 2006 17:50:25 +0300 Gleb Smirnoff [EMAIL PROTECTED] wrote: On Mon, Jan 23, 2006 at 04:44:53PM +0200, Ion-Mihai Tetcu wrote: I Probably you hit another incorrect KASSERT in kern_mbuf.c. I have I removed it some time after the first one. Since X was starting at I this moment you couldn't be dropped into debugger, and so the I box was rebooting. I I I don't know if I understand you right, but starting a bare X and I playing around for a while then typing startkde resulted in a I reset. When panic happens and you have X on the screen, the kernel can't switch to syscons. It dumps core if you have KDB_UNATTENDED in kernel, in other case it just reboots. I don't have KDB_UNATTENDED but on this machine the in the last week I got an automatic dump (on a kmem_map too small while running an RC1 kernel) and then the reboot and I was under X (kde); I remember I had to wait and watch the HDD led w/o being able to do anything else. -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect Without freedom of choice there is no creativity. -- Kirk, The return of the Archons, stardate 3157.4 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mb_dtor_mbuf: M_EXT set
On Sun, 22 Jan 2006 15:16:24 +0100 Christian Brueffer [EMAIL PROTECTED] wrote: On Sun, Jan 22, 2006 at 04:17:12PM +0300, Gleb Smirnoff wrote: On Sat, Jan 21, 2006 at 03:09:02PM +0300, Gleb Smirnoff wrote: T This should be fixed in src/sys/kern_mbuf.c, rev. 1.9.2.3 And another bogus panic is removed in 1.9.2.4 The kernel is working again, thanks! It's working in regard of vr0, thank you. However now my computer resets w/o anything logged when starting kde; if I only startx it doesn't happen (without exec startkde in .xinitrc); I commented out any fancy options like dri with no effect and it also happen if I kldunload snd_via8233 before starting kde. This is with 1.9.2.3 (cvsupped around 21 to 22 midnight; it didn't happen with sources from 19. -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect BOFH excuse #153: Big to little endian conversion error ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6-STABLE from 19: panic: mb_dtor_mbuf: M_EXT set
Hi,
On ifconfig vr0 up I get each time a the panic bellow; last good kernel
I have is from Dec 31 and if_vr hasn't been touched since November.
# kgdb /usr/obj/usr/src/sys/IT6_U/kernel.debug /usr/crash/vmcore.4
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
[ ... ]
vr0: VIA VT6102 Rhine II 10/100BaseTX port 0xe400-0xe4ff mem
0xe3004000-0xe30040ff irq 23 at device 18.0 on pci0
vr0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe400
miibus0: MII bus on vr0
ukphy0: Generic IEEE 802.3u media interface on miibus0
ukphy0: OUI 0x004063, model 0x0032, rev. 10
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
vr0: bpf attached
vr0: Ethernet address: 00:0f:ea:0a:96:11
ioapic0: routing intpin 23 (PCI IRQ 23) to cluster 0
vr0: [MPSAFE]
pci1: driver added
found- vendor=0x1002, dev=0x4966, revid=0x01
bus=1, slot=0, func=0
class=03-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x0087, statreg=0x02b0, cachelnsz=8 (dwords)
lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns)
intpin=a, irq=16
powerspec 2 supports D0 D1 D2 D3 current D0
pci1:0:0: reprobing on driver added
118#
118vr0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
118 ether 00:0f:ea:0a:96:11
118 media: Ethernet autoselect (none)
118 status: no carrier
118#
118vr0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
118 ether 00:0f:ea:0a:96:11
118 media: Ethernet autoselect (none)
118 status: no carrier
118#
panic: mb_dtor_mbuf: M_EXT set
KDB: stack backtrace:
panic(c066952c,c0650ac0,c1035048,c4d44300,e5049b14) at panic+0x13a
mb_dtor_pack(c4d44300,100,0,956,c10383c0) at mb_dtor_pack
uma_zfree_arg(c104de80,c4d44300,0,c4da7934) at uma_zfree_arg+0x36a
mb_free_ext(c4d44300,c4c01400,c4da7000,c4da7000,e5049b74) at mb_free_ext+0x8f
m_freem(c4d44300,0,c52e460c,67c,c4da7950) at m_freem+0x27
vr_stop(c4d9ce80,1,c52e460c,59e,c4da7950) at vr_stop+0xca
vr_init_locked(c4da7950,8,c52e460c,625,0) at vr_init_locked+0x53
vr_ioctl(c4c01400,80206910,c51a8ca0,c04ceb72,c070aee0) at vr_ioctl+0x17f
ifhwioctl(c51a8ca0,c4b6b320,c51a8ca0,20,0) at ifhwioctl+0x5c5
ifioctl(c4e789bc,80206910,c51a8ca0,c4b6b320,2) at ifioctl+0x78
soo_ioctl(c4d9a6c0,80206910,c51a8ca0,c4a9fd80,c4b6b320) at soo_ioctl+0x2e8
ioctl(c4b6b320,e5049d04,c,41d,3) at ioctl+0x118
syscall(3b,3b,3b,3,1) at syscall+0x13d
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281579a7, esp = 0xbfbfe58c, ebp
= 0xbfbfe5d8 ---
KDB: enter: panic
panic: from debugger
Uptime: 17m48s
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1023MB (261872 pages) 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527
511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207
191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt full
#0 doadump () at pcpu.h:165
No locals.
#1 0xc04d8606 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
_ep = (struct eventhandler_entry *) 0x0
_el = (struct eventhandler_list *) 0xc4d31680
first_buf_printf = 1
#2 0xc04d80d7 in panic (fmt=0xc065d2b6 from debugger) at
/usr/src/sys/kern/kern_shutdown.c:555
bootopt = 260
newpanic = 0
buf = mb_dtor_mbuf: M_EXT set, '\0' repeats 232 times
#3 0xc0444592 in db_panic (addr=-1068544094, have_addr=0, count=-1,
modif=0xe5049928 ) at /usr/src/sys/ddb/db_command.c:438
No locals.
#4 0xc0444b10 in db_command_loop () at /usr/src/sys/ddb/db_command.c:350
No locals.
#5 0xc0446934 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221
jb = {{_jb = {-452683308, -452683336, -452683256, -994659552, 0,
-1069258453, -452683124, -1, -1066911948, 672496039, -452683256, -1068543056}}}
prev_jb = (void *) 0x0
bkpt = 0
#6 0xc04f5432 in kdb_trap (type=0, code=0, tf=0xe5049a5c) at
/usr/src/sys/kern/subr_kdb.c:473
handled = -452683172
#7 0xc0635767 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 256, tf_esi = 1, tf_ebp =
-452683100, tf_isp = -452683128, tf_ebx = 1, tf_edx = 1, tf_ecx = -108832,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1068544094, tf_cs = 32,
tf_eflags = 662, tf_esp = -1067004259, tf_ss = -1067012681})
at /usr/src/sys/i386/i386/trap.c:593
p = (struct proc *) 0xc4d99c48
sticks = 4
i = 0
ucode =
Re: compat 5x libraries missnig after restart
On Tue, 27 Dec 2005 11:25:39 -0600 Stephen Montgomery-Smith [EMAIL PROTECTED] wrote: Doug Barton wrote: Add the following to /etc/rc.conf.local: compat5x_enable=yes And it would probably help if you watched the messages printed to the console as the system boots. And you should also have read the message that came when you installed the port - you know, the one that immediately scrolled off the top of the screen. And you should also have checked ports/UPDATING - oops, scratch that last piece of advice. Seriously, I consider my self lucky, not superior, that I caught this change and didn't face the same problems as the OP. You mean you've read those mails with [HEADS-UP] pre-pended to subj. line ? I hope you guys fix this feature before RELEASE-6.1, otherwise the mailing lists are going to be full of this issue. There's nothing to fix and yes, it's a feature (which will be probably referenced in the release notes). -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect There's only one kind of woman ... Or man, for that matter. You either believe in yourself or you don't. -- Kirk and Harry Mudd, Mudd's Women, stardate 1330.1 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Please clean out your */etc/rc.d directories
On Thu, 22 Dec 2005 10:52:27 -0800
Brooks Davis [EMAIL PROTECTED] wrote:
Also, how will this effect cups which installs a .sample file? and
any other port that does this?
.sample files should go away. If for some reason a script must
be modified to be useful, the sample version should go under
${PREFIX}/share.
I haven open (and badly written) PR for converting cups' rc script to be
rc.d compatible. Today / tomorrow I'll submit a new patch (after
TinderFoxy finishes building my ports so I can test the modifications I
make).
--
IOnut - Unregistered ;) FreeBSD user
Intellectual Property is nowhere near as valuable as Intellect
I'm not sure, try calling the Internet's head office -- it's in the book
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: MFC of local_startup changes to rc.d complete
On Fri, 23 Dec 2005 15:38:15 +0100
Florent Thoumie [EMAIL PROTECTED] wrote:
On Friday 23 December 2005 15:19, Jose M Rodriguez wrote:
I'm not sure this is the way to go, but ...
Can someone put a document on what is the desired model? I think we
have too much little pieces of disperse notes about this.
Also, some working notes about ports and RELENG_4/RELENG_5 src
issues will be of interest.
Hope this can be tweak in time for 6.1 (Jan).
Convert your old script to rcNG scripts and use USE_RC_SUBR=
script.sh. Ensure that the rcorder preamble contains meaningful
keywords (PROVIDES, REQUIRES, BEFORE, ...) for all your rcNG scripts.
bsd.port.mk should do the rest.
You should actually convert your old script to a ``rc.d'' script,
that's how they are called now.
Also, if your script is rc.d compatible you should use:
USE_RC_SUBR=script (without .sh)
For now it doesn't matter because bsd.port.mk install all USE_RC_SUBR
scripts with .sh extension, but see below
On Thu, 22 Dec 2005 10:52:27 -0800
Brooks Davis [EMAIL PROTECTED] wrote:
[ ... ]
Does this mean that we will remove the .sh extension on port rc.d
startup scripts? Because a) it's been only running .sh scripts for
quite a while, and b) it's really nice and easy to disable scripts
by moving them to .old or another extension..
Yes. You should be able to disable any correctly written rc.d script
by setting the variable listed by running script rcvar to NO in
/etc/rc.conf (and this should be the default). In 8.0 any scripts
ending in .sh will be run in the context of /etc/rc so they should be
extremely rare and must be very carefully crafted to avoid namespace
pollution.
Also, how will this effect cups which installs a .sample file? and
any other port that does this?
.sample files should go away. If for some reason a script must
be modified to be useful, the sample version should go under
${PREFIX}/share.
--
IOnut - Unregistered ;) FreeBSD user
Intellectual Property is nowhere near as valuable as Intellect
root rot
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: MFC of local_startup changes to rc.d complete
On Fri, 23 Dec 2005 19:28:19 +0100
Florent Thoumie [EMAIL PROTECTED] wrote:
On Friday 23 December 2005 18:52, Ion-Mihai Tetcu wrote:
On Fri, 23 Dec 2005 15:38:15 +0100
Florent Thoumie [EMAIL PROTECTED] wrote:
On Friday 23 December 2005 15:19, Jose M Rodriguez wrote:
I'm not sure this is the way to go, but ...
Can someone put a document on what is the desired model? I
think we have too much little pieces of disperse notes about
this.
Also, some working notes about ports and RELENG_4/RELENG_5 src
issues will be of interest.
Hope this can be tweak in time for 6.1 (Jan).
Convert your old script to rcNG scripts and use
USE_RC_SUBR= script.sh. Ensure that the rcorder preamble contains
meaningful keywords (PROVIDES, REQUIRES, BEFORE, ...) for all
your rcNG scripts. bsd.port.mk should do the rest.
You should actually convert your old script to a ``rc.d'' script,
that's how they are called now.
rcNG was the word for using rc.subr. From the beginning
these rc.subr-powered scripts have been using the rcorder preamble
and have always been rc.d script actually. Since we're talking about
the same thing, I'm not sure words are really important.
Well, I was corrected by dougb@
For me a rc.d script is one that on:
1. has the right keywords, ... (ie. is rcNG)
2. has the right extension depending if it must be sourced or not
(on a a system which has local_startup scripts in the base rcorder -
HEAD and 6-STABLE for now).
Also, if your script is rc.d compatible you should use:
USE_RC_SUBR=script (without .sh)
For now it doesn't matter because bsd.port.mk install all
USE_RC_SUBR scripts with .sh extension, but see below
Using the .sh extension prevents from conflicts in ${WRKDIR}
This is indeed a problem; perhaps we should hack bsd.port.mk to avoid
this.
and you know what kind of file it is in ${FILESDIR}. Anyway, what is
This is easy to fix, no ?
the difference between adding .sh suffix in some cases and removing
it in some cases ?
If you are asking what is the difference between how it is/will be treated by
rc.subr the answer is in the quote from Brooks which you removed.
An interesting discussion is in
http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/90070 and a solution is
tested (http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/90150).
I think naming a script without .sh make it easy to see it's rc.d ready.
--
IOnut - Unregistered ;) FreeBSD user
Intellectual Property is nowhere near as valuable as Intellect
BOFH excuse #386:
The Internet is being scanned for viruses
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug[?] In new local_startup and postgresql
On Thu, 22 Dec 2005 00:50:07 +0100 Cristiano Deana [EMAIL PROTECTED] wrote: After a today upgrade to 6-STABLE postgresql doesn't start at boot. Strange beavior, if I run `/usr/local/etc/rc.d/010.pgsql.sh start' it starts correctly. 010.pgsql.sh is the same of updated ports. This is 010.pgsql.sh : http://www.deana.it/010.pgsql.sh Doug, this is resuls of running `sh rc' whit your patch: http://www.deana.it/rc.late # grep postgresql_enable /etc/rc.conf postgresql_enable=YES This is the only one script doesn't working On your system :) Squid and samba have been reported on ports and I'm working on cups, which with the current script behaves strangely like it doesn't receive start. But, as in your case, it starts by hand. Please check if you get a /usr/local/etc/rc.d/010.pgsql.sh: unknown directive .. Usage: /usr/local/etc/rc.d/010.pgsql.sh [fast|force|one](start|stop|restart|rcvar|reload|initdb|status|poll) on boot, I'm very curios to see what directive it receives. -- IOnut - Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect BOFH excuse #336: the xy axis in the trackball is coordinated with the summer solstice ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[backtrace] (snd_solo) mtx_lock_sleep: recursed on non-recursive mutex
Hi,
In my quest to find an other sound card that works with skype, I
salvaged an ESS Solo-1 (ES1938S H209). Trying to play anything through
it results from pcm channel dead to hard freezes and ,the last time I
got the panic bellow. Any chance to make it work or should I keep
searching ?
FreeBSD it.buh.tecnik93.com 6.0-STABLE FreeBSD 6.0-STABLE #4: Wed Nov 16
15:38:12 EET 2005
Unread portion of the kernel message buffer:
panic: _mtx_lock_sleep: recursed on non-recursive mutex pcm0 @
/usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/sound.c:381
KDB: stack backtrace:
panic(c066692c,c2e194b0,c07eac3f,17d,c2e1f4c0) at panic+0x13a
_mtx_lock_sleep(c2e1f4c0,c2d08000,0,c07eac3f,17d) at _mtx_lock_sleep+0x131
_mtx_lock_flags(c2e1f4c0,0,c07eac3f,17d,0) at _mtx_lock_flags+0xae
pcm_chn_create(c2d99200,c26b1d80,c07eeac4,2,c26b1d80) at pcm_chn_create+0xb5
vchan_create(c26b1d80,8,c07eac3f,bf,3cb) at vchan_create+0x79
pcm_chnalloc(c2d99200,1,3cb,,0) at pcm_chnalloc+0x10c
dsp_open(c2737e00,6,2000,c2d08000,0) at dsp_open+0x20b
giant_open(c2737e00,6,2000,c2d08000,c2737e00) at giant_open+0x4f
devfs_open(ef80ba50,ef80bd04,6) at devfs_open+0x251
VOP_OPEN_APV(c0690540,ef80ba50,c0670b57,ef80ba60,0) at VOP_OPEN_APV+0x73
vn_open_cred(ef80bbc0,ef80bcc0,0,c2d2cb00,3) at vn_open_cred+0x359
vn_open(ef80bbc0,ef80bcc0,0,3,c0679b06) at vn_open+0x33
kern_open(c2d08000,280b99f6,0,6,0) at kern_open+0xd4
open(c2d08000,ef80bd04,c,418,3) at open+0x36
syscall(3b,3b,3b,1021,280b99f6) at syscall+0x13d
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (5, FreeBSD ELF32, open), eip = 0x2819a3f7, esp = 0xbfbfe9ec, ebp =
0xbfbfea18 ---
KDB: enter: panic
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1023MB (261872 pages) 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527
511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207
191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc0d7 in db_fncall (dummy1=-276777220, dummy2=0, dummy3=16,
dummy4=0xef80b6f4 ÐÝaÀ\237tfÀ\017ögÀ)
at /usr/src/sys/ddb/db_command.c:492
#2 0xc0444970 in db_command_loop () at /usr/src/sys/ddb/db_command.c:350
#3 0xc0446794 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221
#4 0xc04f4312 in kdb_trap (type=0, code=0, tf=0xef80b828) at
/usr/src/sys/kern/subr_kdb.c:473
#5 0xc0632697 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 256, tf_esi = 1, tf_ebp =
-276776848, tf_isp = -276776876, tf_ebx = 1, tf_edx = 0, tf_ecx = -1066685504,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1068548478, tf_cs = 32,
tf_eflags = 646, tf_esp = -1067019002, tf_ss = -1067027503}) at
/usr/src/sys/i386/i386/trap.c:591
#6 0xc06201ca in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc04f3e82 in kdb_enter (msg=0x12 Address 0x12 out of bounds) at
cpufunc.h:60
#8 0xc04d785c in panic (fmt=0x1 Address 0x1 out of bounds) at
/usr/src/sys/kern/kern_shutdown.c:539
#9 0xc04ce231 in _mtx_lock_sleep (m=0xc2e1f4c0, tid=3268444160, opts=0,
file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:490
#10 0xc04ce2ee in _mtx_lock_flags (m=0xc2e1f4c0, opts=8,
file=0xc07eac3f
/usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/sound.c, line=381) at
/usr/src/sys/kern/kern_mutex.c:276
#11 0xc07e7425 in ?? ()
#12 0xc2e1f4c0 in ?? ()
.
---Type return to continue, or q return to quit---q
Quit
(kgdb) l *0xc04ce2ee
0xc04ce2ee is in _mtx_lock_flags (/usr/src/sys/kern/kern_mutex.c:279).
274 WITNESS_CHECKORDER(m-mtx_object, opts | LOP_NEWORDER |
LOP_EXCLUSIVE,
275 file, line);
276 _get_sleep_lock(m, curthread, opts, file, line);
277 LOCK_LOG_LOCK(LOCK, m-mtx_object, opts, m-mtx_recurse,
file,
278 line);
279 WITNESS_LOCK(m-mtx_object, opts | LOP_EXCLUSIVE, file, line);
280 #ifdef MUTEX_PROFILING
281 /* don't reset the timer when/if recursing */
282 if (m-mtx_acqtime == 0) {
283 m-mtx_filename = file;
Thanks,
--
IOnut - Unregistered ;) FreeBSD user
Intellectual Property is nowhere near as valuable as Intellect
BOFH excuse #379:
We've picked COBOL as the language of choice
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 Release - Pentium install panic and some questions
On Tue, 22 Nov 2005 11:25:31 +1000 Paul Koch [EMAIL PROTECTED] wrote: On Tue, 22 Nov 2005 07:03 am, Kris Kennaway wrote: On Mon, Nov 21, 2005 at 09:28:27PM +1000, Paul Koch wrote: On Mon, 21 Nov 2005 07:24 pm, Kris Kennaway wrote: Issue 1: Can't install on a Pentium P5 class machine: The install panics when installing the base stuff. No useful messages are displayed accept the panic: page fault and rebooting in 15 seconds. The machines are 10 year old DEC Pentiums, 32 to 64M ram, IDE disks, etc. We have four of these in our test environment and appear to install and run FreeBSD-5.4 fine. Try disabling ACPI. Many old systems have buggy ACPI implementations. Sometimes this can be fixed by a BIOS upgrade. A Pentium 150Mhz aged machine wouldn't have ACPI, would it ? I don't know..nevertheless, please try it :) Kris Ok, a bit of confusion here. When booting from floppy on these machines, the option is to Boot FreeBSD with ACPI enabled, while on other machines it says Boot FreeBSD with ACPI disabled. Looks like this is from beastie.4th. We tried both options and it still panics when it is extracting base (ie. you can partition, newfs, etc... using sysinstall). It gets about 2% of the way through extracting base. AFAIR (haven't look at the code, just what I remeber from installing on some old machines w/o ACPI) the first machines have ACPI the second don't. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Booting 6.0 RC1 with synced sources from today hangs
On Fri, 28 Oct 2005 14:23:56 +0200 Manfred Lotz [EMAIL PROTECTED] wrote: Hi all, I tried FreeBSD 6.0 RC1 whic hworked fine besides that when booting after the message acd2: DVDR NEC DVD RW ND-3540A/1.01 at ata3-master DUMA33 it took a minute or so to show the next message. No I synced the sources and build a new kernel in order to e.g. try out cdrecord which requires atapicam. But now I can no longer boot: acd2: DVDR NEC DVD RW ND-3540A/1.01 at ata3-master DUMA33 Interrupt storm detected on irq10:atapci0+; throttling interrupt source acd2: req=0x2593578 TEST_UNIT_READY semaphore timeout !! DANGER Will Robinson! ! acd2: req=0x2593bb8 TEST_UNIT_READY semaphore timeout !! DANGER Will Robinson! ! acd2: req=0x2593bb8 TEST_UNIT_READY semaphore timeout !! DANGER Will Robinson! ! acd2: req=0x2593bb8 TEST_UNIT_READY semaphore timeout !! DANGER Will Robinson! ! some more meesages regarding atapicam stuff ... acd2: req=0x2593708 TEST_UNIT_READY semaphore timeout !! DANGER Will Robinson! ! Did you try to boot with a CD/DVD in the drive ? -- IOnut Unregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[with trace] Re: 6.0-BETA5 from yesterday panics on kldload nfsserver.ko
On Sun, 25 Sep 2005 10:31:11 -0400
Kris Kennaway [EMAIL PROTECTED] wrote:
On Sun, Sep 25, 2005 at 04:20:17PM +0300, Ion-Mihai Tetcu wrote:
This is completely reproducible, unfortunately the core file is
corrupted.
warning: /usr/crash/vmcore.1: no core file handler recognizes
format, using default Can't fetch registers from this type of core
file Can't fetch registers from this type of core file
#0 0x in ?? ()
(gdb)
Do you mean gdb or kgdb? You should use the latter.
You're right, of course; old habit, I've used gdb -k and then only
gdb :( Thanks for point it out. Here's a trace:
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x464c457f
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc04de72a
stack pointer = 0x28:0xeb34ba40
frame pointer = 0x28:0xeb34ba50
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1434 (kldload)
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1023MB (261872 pages) 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527
511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207
191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc0444367 in db_fncall (dummy1=-348866464, dummy2=0, dummy3=16,
dummy4=0xeb34b858 à»aÀ¯6fÀ\033³gÀ)
at /usr/src/sys/ddb/db_command.c:489
#2 0xc0444800 in db_command_loop () at /usr/src/sys/ddb/db_command.c:349
#3 0xc04465b4 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:221
#4 0xc04f37c2 in kdb_trap (type=0, code=0, tf=0xeb34ba00) at
/usr/src/sys/kern/subr_kdb.c:473
#5 0xc062fdd4 in trap_fatal (frame=0xeb34ba00, eva=1179403647) at
/usr/src/sys/i386/i386/trap.c:832
#6 0xc06300fb in trap_pfault (frame=0xeb34ba00, usermode=0, eva=1179403647)
at /usr/src/sys/i386/i386/trap.c:752
#7 0xc0630476 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 0, tf_esi = 27264, tf_ebp =
-348865968, tf_isp = -348866004, tf_ebx = -1017933824, tf_edx = 1179403647,
tf_ecx = 0, tf_eax = 27264, tf_trapno = 12, tf_err = 0, tf_eip = -1068636374,
tf_cs = 32, tf_eflags = 66178, tf_esp = -1067038549, tf_ss = -1067051490})
at /usr/src/sys/i386/i386/trap.c:442
#8 0xc061dfda in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#9 0xc04de72a in sysctl_find_oidname (name=0x6a80 Address 0x6a80 out of
bounds, list=0x464c457f)
at /usr/src/sys/kern/kern_sysctl.c:77
#10 0xc04de77e in sysctl_register_oid (oidp=0xc3539000) at
/usr/src/sys/kern/kern_sysctl.c:105
#11 0xc04c5d2d in linker_file_register_sysctls (lf=0x6a80) at
/usr/src/sys/kern/kern_linker.c:255
#12 0xc04c825b in linker_load_module (kldname=0xc3244a20
/boot/kernel/nfsserver.ko, modname=0x0,
parent=0x0, verinfo=0x0, lfpp=0xeb34bcc0) at
/usr/src/sys/kern/kern_linker.c:366
#13 0xc04c881f in kldload (td=0xc26c5c80, uap=0x6a80) at
/usr/src/sys/kern/kern_linker.c:785
#14 0xc063087d in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 0, tf_esi = -1077941040,
tf_ebp = -1077941096, tf_isp = -348865180, tf_ebx = 0, tf_edx = -1, tf_ecx = 1,
tf_eax = 304, tf_trapno = 12, tf_err = 2, tf_eip = 671900319, tf_cs = 51,
tf_eflags = 531, tf_esp = -1077941156, tf_ss = 59}) at
/usr/src/sys/i386/i386/trap.c:986
#15 0xc061e02f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
#16 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) l *0xc04de72a
0xc04de72a is in sysctl_find_oidname (/usr/src/sys/kern/kern_sysctl.c:80).
75 static struct sysctl_oid *
76 sysctl_find_oidname(const char *name, struct sysctl_oid_list *list)
77 {
78 struct sysctl_oid *oidp;
79
80 SLIST_FOREACH(oidp, list, oid_link) {
81 if (strcmp(oidp-oid_name, name) == 0) {
82 return (oidp);
83 }
84 }
The only exotic thing is that I'm using ULE.
This was a complete clean build (rm -rf /usr/src/*
cvsup .).
But did you rebuild the nfsserver module? e.g. you are not using
MODULES_OVERRIDE, and the module and kernel have the same date?
Yup. It was a buildword/buildkernel/... procedure. (upgrading
from beta 3 or 4) (and I build all modules).
--
IOnut
Unregistered ;) FreeBSD user
Intellectual Property is nowhere near as valuable as Intellect
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
6.0-BETA5 from yesterday panics on kldload nfsserver.ko
This is completely reproducible, unfortunately the core file is corrupted. warning: /usr/crash/vmcore.1: no core file handler recognizes format, using default Can't fetch registers from this type of core file Can't fetch registers from this type of core file #0 0x in ?? () (gdb) [EMAIL PROTECTED] /usr/crash [16:16:06] 0 # file vmcore.1 vmcore.1: ELF 32-bit LSB core file Intel 80386, invalid version (embedded) The only exotic thing is that I'm using ULE. This was a complete clean build (rm -rf /usr/src/* cvsup .). -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Romanian BitDefender for FreeBSD Mail Servers line
On Sat, 28 May 2005 10:29:17 +0300 Daniel [EMAIL PROTECTED] wrote: Hi all, Here are some links about the BitDefender for FreeBSD Mail Servers line. http://www.bitdefender.com/bd/site/products.php?p_id=52 ftp://ftp.bitdefender.com/pub/freebsd/mailserver/RELEASE_NOTES As a side note, BitDefender is a Romanian brand/product. It is developed by Softwin. The link in the main page of FreeBSD.org points to another site that announces the product, instead of the Romanian company's site.. This is a www@ (and ports) issue, not an advocacy or stable. Please post to the appropriate mailing list. More, the link in question is under FreeBSD in the press so I don't see what the problem is. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lifetime of FreeBSD branches
On Mon, 23 May 2005 23:08:18 +0200 Simon L. Nielsen [EMAIL PROTECTED] wrote: On 2005.05.23 16:51:18 -0400, Mike Jakubik wrote: On Mon, May 23, 2005 3:42 pm, Colin Percival said: http://www.freebsd.org/security/ In addition to the material there (which is concerned with existing releases), FreeBSD 5.x is expected to be supported until late 2007 (FreeBSD 5.5 plus two years), and FreeBSD 6.x will probably be supported until early 2009 (the last FreeBSD 6.x release plus two years). Thanks for the info guys. Does this security support also mean that current ports will be compatible with the release? No, there are no guarantees about that. The ports/ people generally try to make things work with older releases, but there are no gurantees there. It's simply too much work to make such guarantees, and this is after all an volunteer project (for most parts anyway). Not only work, but also a lack of resources; for example I just received a report from a 4.11 user regarding of of my ports that I'm unable to reproduce on my 5-STABLE and I don't have a 4.11 machine. In this case I strongly suspect a local problem, but if it is not I'll be forced to install a 4.11. Of course, is impossible to do this for all (supported branches x supported platforms), hence the official statement from http://www.freebsd.org/ports/. Before each release we have a ports freeze period when (almost) no update to the ports is made but our time is dedicated to make sure our ports work on that release. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with portupgrade
On Sat, 21 May 2005 15:49:03 -0500 Jim C. Nasby [EMAIL PROTECTED] wrote: On Sat, May 21, 2005 at 02:47:28PM -0500, Barry Pederson wrote: Jim C. Nasby wrote: I'm trying to upgrade spamassassin, but portupgrade is stubling on every dependant port. It appears it wants to re-install each port, which of course doesn't work. It generates the make deinstall first error message. portupgrade -m -DFORCE_PKG_REGISTER seems to have gotten around the problem, but I'm curious as to what's causing this. Anyone have any ideas? This is 4.11-RELEASE if that matters... Did you perhaps upgrade your Perl earlier? so that perhaps the existing installed dependant ports are Perl packages for 5.6.1, but you now have 5.6.2 and portupgrade thinks your dependant packages should be for that - but it can't install them because the older versions for 5.6.1 are in place. I did recently go from 5.8 to 5.6. So that means all my perl stuff needs to re-install? That doesn't really make any sense... See /usr/ports/UPDATING for perl entries and possible workarounds to reinstalling perl dependent ports. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acroread 7 port broken?
On Tue, 17 May 2005 12:41:20 -0700 Kent Stewart [EMAIL PROTECTED] wrote: On Tuesday 17 May 2005 11:21 am, ya hoo wrote: I just tried to install acroread 7 from the ports that I cvsup'd last night. It tells me that it is marked broekn. I assume it is broken, but does anyone know when it will be fixed? There must be something else going on. I just cvsuped and had no problem building acroreader. It was broken a while back but the current version isn't broken. It was a plist problem and Pav today's commit fixed it. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iso numbering
On Mon, 9 May 2005 07:02:07 +0200 Zoran Kolic [EMAIL PROTECTED] wrote: Just a question before 5.4: what would be iso 1 on release? Live system or instalation? Both. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getting handbooks via cvsup?
On Sun, 24 Apr 2005 12:21:53 +0200 O. Hartmann [EMAIL PROTECTED] wrote: I'm looking for a way getting various handbook's sources via cvsup, common handbook English/German and some developers handbooks (developer, porter). On each nstallation CD I can find various handbook types (PS, PDF, HTML). My intention is having a local webserver at the department keeping track on HTML and PS generated handbooks automaticaly and sucking in the changes via cvsup. I can remember there is a way but I lost the glue where to look for. cvsup file: *default host=cvsup.ro.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=. *default delete use-rel-suffix doc-all Run cvsup then: cd /usr/doc/ make FORMATS=html html-split ps pdf install -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[5.4] installworld fails in acpica
Hey Sources of a couple of hours ago, clean obj dir, etc -- Installing everything -- cd /usr/src; make -f Makefile.inc1 install === share/info === include [ ... ] if [ -L /usr/include/crypto ]; then rm -f /usr/include/crypto; fi mtree -deU -f /usr/src/include/../etc/mtree/BSD.include.dist -p /usr/include ./dev/acpica missing (directory not created: File exists) cd /usr/include/cam; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/geom; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/net; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/net80211; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/netatalk; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/netatm; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/netgraph; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/netinet; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/netinet6; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/netipsec; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/netipx; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/netkey; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/netnatm; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/netncp; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/netsmb; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/nfs; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/nfsclient; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/nfsserver; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/pccard; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/posix4; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/sys; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/vm; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/cam/scsi; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd /usr/include/dev/acpica; for h in *.h; do if [ -L $h ]; then rm -f $h; fi; done cd: can't cd to /usr/include/dev/acpica *** Error code 2 Stop in /usr/src/include. *** 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. # ll /usr/include/dev/acpica -r--r--r-- 1 root wheel 4210 Mar 4 00:13 /usr/include/dev/acpica Now on 2 other machines:the dir does not exists and on a third ll /usr/include/dev/acpica total 6 -r--r--r-- 1 root wheel 4210 Mar 11 16:54 acpiio.h If I remove the file and run make installworld it goes OK. Now, what's wrong ? -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Today -STABLE doesn't build in rescue - ifconfig.lo
On Thu, 24 Mar 2005 10:07:31 +0200 Ruslan Ermilov [EMAIL PROTECTED] wrote: On Thu, Mar 24, 2005 at 09:29:48AM +0200, Ion-Mihai Tetcu wrote: On Wed, 23 Mar 2005 17:47:04 -0800 Doug Barton [EMAIL PROTECTED] wrote: Ion-Mihai Tetcu wrote: Hi, This happens when makeing world with -DNOCLEAN, sources cvsup'ed 5 minutes ago. I'm going to try a clean build and let you know if that solves it: It definitely should solve it. I've been building RELENG_5 for 2 days straight without problems. And yes, it solved it :) For future reference, it's generally better to try the clean build first before sending in a report like this, especially in -stable. Point taken, but you know I'm not the one to make exaggerated noise. I was 02:35 in the morning and I wanted to know if anyone saw the same thing and if I need to wait I could simply go to bed. Thanks for the new BIND. You shouldn't be using NOCLEAN routinely; it's only safe when sources do not change. For the time from 5.3R I had only once on one machine a problem besides this (and yes, the sources haven't changed much in all this time execpt the present MFCs race :). Now I know and just had an example of it, that NOCLEAN ain't working; my question is do I risk having bad code compiled or just errors like this one ? From my knowledge of how make works in a perfect word :) not even this should happen. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Today -STABLE doesn't build in rescue - ifconfig.lo
Hi, This happens when makeing world with -DNOCLEAN, sources cvsup'ed 5 minutes ago. I'm going to try a clean build and let you know if that solves it: . `rtapelib.o' is up to date. `tar.o' is up to date. `update.o' is up to date. cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pax.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo bsdlabel.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_ext2fs.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_std.lo mount_udf.lo mount_umapfs.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo slattach.lo spppcontrol.lo startslip.lo swapon.lo sysctl.lo tunefs.lo umount.lo atm.lo atmconfig.lo fore_dnld.lo ilmid.lo pin g6.lo vinum.lo ipf.lo ipfs.lo ipfstat.lo ipmon.lo ipnat.lo sconfig.lo fdisk.lo dhclient.lo bzip2.lo vi.lo id.lo gzip.lo tar.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/rescue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lkvm -ll -lm -ltermcap -lutil -lcrypto -latm -lalias -lbsdxml -lcam -lcurses -ldevstat -lipsec -lipx -lgeom -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 ifconfig.lo(.text+0x1e7f): In function `status': : undefined reference to `pfsync_status' ifconfig.lo(.text+0x1eaf): In function `status': : undefined reference to `carp_status' ifconfig.lo(.text+0x1f3b): In function `status': : undefined reference to `carp_status' ifconfig.lo(.text+0x1fe5): In function `status': : undefined reference to `pfsync_status' ifconfig.lo(.text+0x2051): In function `status': : undefined reference to `carp_status' ifconfig.lo(.rodata+0x408): undefined reference to `setpfsync_syncif' ifconfig.lo(.rodata+0x418): undefined reference to `setpfsync_maxupd' ifconfig.lo(.rodata+0x428): undefined reference to `unsetpfsync_syncif' ifconfig.lo(.rodata+0x5d8): undefined reference to `setcarp_advbase' ifconfig.lo(.rodata+0x5e8): undefined reference to `setcarp_advskew' ifconfig.lo(.rodata+0x5f8): undefined reference to `setcarp_passwd' ifconfig.lo(.rodata+0x608): undefined reference to `setcarp_vhid' *** Error code 1 Stop in /usr/obj/usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Today -STABLE doesn't build in rescue - ifconfig.lo
On Wed, 23 Mar 2005 17:47:04 -0800 Doug Barton [EMAIL PROTECTED] wrote: Ion-Mihai Tetcu wrote: Hi, This happens when makeing world with -DNOCLEAN, sources cvsup'ed 5 minutes ago. I'm going to try a clean build and let you know if that solves it: It definitely should solve it. I've been building RELENG_5 for 2 days straight without problems. And yes, it solved it :) For future reference, it's generally better to try the clean build first before sending in a report like this, especially in -stable. Point taken, but you know I'm not the one to make exaggerated noise. I was 02:35 in the morning and I wanted to know if anyone saw the same thing and if I need to wait I could simply go to bed. Thanks for the new BIND. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3-stable doesn't ifconfig at startup
On Fri, 11 Feb 2005 07:48:27 -0500 (EST)
Kenneth W Cochran [EMAIL PROTECTED] wrote:
Date: Fri, 11 Feb 2005 09:27:01 +0200
From: Ion-Mihai Tetcu [EMAIL PROTECTED]
To: Kenneth W Cochran [EMAIL PROTECTED]
Cc: freebsd-stable@freebsd.org
Subject: Re: 5.3-stable doesn't ifconfig at startup
On Fri, 11 Feb 2005 02:00:39 -0500 (EST)
Kenneth W Cochran [EMAIL PROTECTED] wrote:
Hello -stable:
Any idea(s) why (my) 5.3-stable (as of 9 February) isn't
configuring the network interface or setting up the default route?
I installed 5.3-release from CD and things worked fine.
Then I updated the system sources (via cvsup) to RELENG_5 and
went through {build,install}world/mergemaster/reboot as outlined
[ .. ]
mergemaster pilot error ?
If you didn't changed something in them I'd suggest wiping /etc/rc.d/*
and /etc/defaults/* and do a mergermaster -i
First thing I thought of; both mergemaster -p and
mergemaster without arguments are fine; all its targets
updated accordingly.
But set by hand it works ?
I've did the same thing 3 weeks ago and rebuild the machine 3 times w/o problems
--
IOnut
Unregistered ;) FreeBSD user
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tue, 8 Feb 2005 08:39:15 -0800 Kris Kennaway [EMAIL PROTECTED] wrote: On Tue, Feb 08, 2005 at 03:58:22PM +0200, Ion-Mihai Tetcu wrote: On Tue, 8 Feb 2005 14:45:17 +0200 (EET) Viktor Ivanov [EMAIL PROTECTED] wrote: [ ... ] On the other hand, using SCHED_ULE improves sound quality and general system 'response' concerning GUI... don't know 'bout performance. By any chance does it help with copying from ata disks on different controllers ? For me on large files this brings up swap_pager: indefinite wait buffer with 4BSD. That doesn't sound like a scheduler problem, rather a hardware or ata driver problem. Did you try sos' new driver yet? Well, I'm running my desktop with an ULE kernel now, snippets bellow: options SCHED_ULE # ULE scheduler options ADAPTIVE_GIANT # Giant mutex is adaptive. options HZ=1200 options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, #required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed and # sysctl debug.witness debug.witness.skipspin: 1 debug.witness.trace: 1 debug.witness.kdb: 0 debug.witness.watch: 0 And while I don't see may improvements in general operation, at least this problem is gone. I still get a few seconds pauses in sound and switching between app in X is sluggish while copying large files, but at least I don't get swap pager complains and I'd say there's a 3x responsiveness improvement. I didn't test ata patches yet, just to take one step at the time. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Sat, 12 Feb 2005 01:47:27 +0200 Ion-Mihai Tetcu [EMAIL PROTECTED] wrote: On Tue, 8 Feb 2005 08:39:15 -0800 Kris Kennaway [EMAIL PROTECTED] wrote: On Tue, Feb 08, 2005 at 03:58:22PM +0200, Ion-Mihai Tetcu wrote: On Tue, 8 Feb 2005 14:45:17 +0200 (EET) Viktor Ivanov [EMAIL PROTECTED] wrote: [ ... ] On the other hand, using SCHED_ULE improves sound quality and general system 'response' concerning GUI... don't know 'bout performance. By any chance does it help with copying from ata disks on different controllers ? For me on large files this brings up swap_pager: indefinite wait buffer with 4BSD. That doesn't sound like a scheduler problem, rather a hardware or ata driver problem. Did you try sos' new driver yet? Well, I'm running my desktop with an ULE kernel now, snippets bellow: options SCHED_ULE # ULE scheduler options ADAPTIVE_GIANT # Giant mutex is adaptive. options HZ=1200 options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, #required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed and # sysctl debug.witness debug.witness.skipspin: 1 debug.witness.trace: 1 debug.witness.kdb: 0 debug.witness.watch: 0 And while I don't see may improvements in general operation, at least this problem is gone. I still get a few seconds pauses in sound and switching between app in X is sluggish while copying large files, but at least I don't get swap pager complains and I'd say there's a 3x responsiveness improvement. I didn't test ata patches yet, just to take one step at the time. But the problem is seems there somewhere, at least `vmstat -i 1` show 98-103% busy ad0 when copying from ad2 to ad0 and the system doesn't swap or look loaded. Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 326880 32656 52276464152 34144 count All 481012 36440 332734873980pages Interrupts Proc:r p d s wCsw Trp Sys Int Sof Fltcow1931 total 1 2 6102 5661 305 7295 3128 429 56 105476 wire1: atkb 335032 act 3: sio1 10.1%Sys 2.3%Intr 5.4%User 0.0%Nice 82.2%Idl30768 inact 4: sio0 |||||||||| 12072 cache 6: fdc0 =+ 22072 free128 8: rtc daefr 159 12: psm Namei Name-cacheDir-cache prcfr 13: npx Calls hits% hits% react57 14: ata 1686 1686 100 pdwak51 15: ata 26 zfodpdpgs 143 16: xl0 Disks ad0 ad2 26 ofodintrn 189 22: pcm KB/t128 128 %slo-z61472 buf1204 0: clk tps 2826 12 tfree41 dirtybuf MB/s 3.46 3.21 35666 desiredvnodes % busy 98 98916 numvnodes 7269 freevnodes -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3-stable doesn't ifconfig at startup
On Fri, 11 Feb 2005 02:00:39 -0500 (EST)
Kenneth W Cochran [EMAIL PROTECTED] wrote:
Hello -stable:
Any idea(s) why (my) 5.3-stable (as of 9 February) isn't
configuring the network interface or setting up the default route?
I installed 5.3-release from CD and things worked fine.
Then I updated the system sources (via cvsup) to RELENG_5 and
went through {build,install}world/mergemaster/reboot as outlined
in /usr/src/UPDATING and now I get no network interfaces
configured no default route set. I've tracked RELENG_4 for
years with nothing like this ever happening. Kernel has not been
reconfigured (yet), it's still GENERIC, albeit RELENG_5 now.
In looking through the rc scripts, it appears that network
interface(s) are being renamed but I see no references to this
in, say, UPDATING or errara or other documentation. Any ideas?
mergemaster pilot error ?
If you didn't changed something in them I'd suggest wiping /etc/rc.d/*
and /etc/defaults/* and do a mergermaster -i
--
IOnut
Unregistered ;) FreeBSD user
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tue, 8 Feb 2005 16:13:22 +0200 (EET) Viktor Ivanov [EMAIL PROTECTED] wrote: On Tue, Ôåâðóàðè 8, 2005 15:58, Ion-Mihai Tetcu êàçà: I've been using only SCHED_ULE on my UP WS, even when there was #error def. It never broke, not even once :) Though I think there's trouble with SMP and/or HTT. I tried it once on a P4 and it paniced. On the other hand, using SCHED_ULE improves sound quality and general system 'response' concerning GUI... don't know 'bout performance. By any chance does it help with copying from ata disks on different controllers ? For me on large files this brings up swap_pager: indefinite wait buffer with 4BSD. Sorry, can't test this. I know my WS can't compare to a normal server and I don't have a production server running on SCHED_ULE (excuse the pun). As I said though, I tried once SCHED_ULE on a P4 with 1 CPU and HTT enabled and it paniced way too fast. That was when SCHED_ULE was #error-ed... NP, I'll give ULE and sos's new ATA a try this weekend and see. As for rtprio, I do set it after I run mplayer, because I run it from normal user and rtprio is limited to root. Michael says is resolved :) Thanks, -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recompile, harddrive(partition) error
[ please trim the original email ] On Wed, 09 Feb 2005 17:46:43 +0300 dima [EMAIL PROTECTED] wrote: 2. the only safe compiler options for kernel/world builds are -O -pipe. -O2 -pipe for sometime now. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tue, 8 Feb 2005 13:33:04 +0100 Michael Nottebrock [EMAIL PROTECTED] wrote: On Tuesday, 8. February 2005 13:07, Mipam wrote: Hi, I saw several changes to sched_ule.c in the 5 stable branch. Beneath is one of them: http://lists.freebsd.org/pipermail/cvs-src/2005-February/039863.html Is the ULE scheduler still far from stable in RELENG_5 or not? You can now compile a kernel with options SCHED_ULE again. How well it works is for yourself to determine :-) (I've been using it on my UP machine here since yesterday only). Could you tell us again after a week ? There used to be a panic when using rtprio to raise the priority of a running process, do you know if it's fix ? -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tue, 8 Feb 2005 14:00:03 +0100 Michael Nottebrock [EMAIL PROTECTED] wrote: On Tuesday, 8. February 2005 13:43, Ion-Mihai Tetcu wrote: There used to be a panic when using rtprio to raise the priority of a running process, do you know if it's fix ? I never got any panics with ULE back when it was available, so I can't tell. This was absolutely reproducible there is / was a PR on it. If you care about ULE, turn it on and see for yourself - more testers make better testing. I will do it it the weekend. Thanks. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tue, 8 Feb 2005 14:51:17 +0200 (EET) Viktor Ivanov [EMAIL PROTECTED] wrote: On Tue, Ôåâðóàðè 8, 2005 14:43, Ion-Mihai Tetcu êàçà: Could you tell us again after a week ? There used to be a panic when using rtprio to raise the priority of a running process, do you know if it's fix ? I never had those, and I usually run mplayer with rtprio 30... Though mplayer never uses much CPU, only when playing WMV9. Sorry I can't test the new patches too 'cause the WS is not available now. On changing, not running from the beginning rtprio 31 -mpayer_pid http://www.freebsd.org/cgi/query-pr.cgi?pr=71310 http://docs.freebsd.org/cgi/mid.cgi?20040303131655.24317.qmail -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tue, 8 Feb 2005 14:45:17 +0200 (EET) Viktor Ivanov [EMAIL PROTECTED] wrote: On Tue, Ôåâðóàðè 8, 2005 14:33, Michael Nottebrock êàçà: On Tuesday, 8. February 2005 13:07, Mipam wrote: I saw several changes to sched_ule.c in the 5 stable branch. Beneath is one of them: http://lists.freebsd.org/pipermail/cvs-src/2005-February/039863.html Is the ULE scheduler still far from stable in RELENG_5 or not? You can now compile a kernel with options SCHED_ULE again. How well it works is for yourself to determine :-) (I've been using it on my UP machine here since yesterday only). Hi there I've been using only SCHED_ULE on my UP WS, even when there was #error def. It never broke, not even once :) Though I think there's trouble with SMP and/or HTT. I tried it once on a P4 and it paniced. On the other hand, using SCHED_ULE improves sound quality and general system 'response' concerning GUI... don't know 'bout performance. By any chance does it help with copying from ata disks on different controllers ? For me on large files this brings up swap_pager: indefinite wait buffer with 4BSD. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status
On Tue, 8 Feb 2005 08:39:15 -0800 Kris Kennaway [EMAIL PROTECTED] wrote: On Tue, Feb 08, 2005 at 03:58:22PM +0200, Ion-Mihai Tetcu wrote: On Tue, 8 Feb 2005 14:45:17 +0200 (EET) Viktor Ivanov [EMAIL PROTECTED] wrote: On Tue, 8, 2005 14:33, Michael Nottebrock : On Tuesday, 8. February 2005 13:07, Mipam wrote: I saw several changes to sched_ule.c in the 5 stable branch. Beneath is one of them: http://lists.freebsd.org/pipermail/cvs-src/2005-February/039863.html Is the ULE scheduler still far from stable in RELENG_5 or not? You can now compile a kernel with options SCHED_ULE again. How well it works is for yourself to determine :-) (I've been using it on my UP machine here since yesterday only). Hi there I've been using only SCHED_ULE on my UP WS, even when there was #error def. It never broke, not even once :) Though I think there's trouble with SMP and/or HTT. I tried it once on a P4 and it paniced. On the other hand, using SCHED_ULE improves sound quality and general system 'response' concerning GUI... don't know 'bout performance. By any chance does it help with copying from ata disks on different controllers ? For me on large files this brings up swap_pager: indefinite wait buffer with 4BSD. That doesn't sound like a scheduler problem, rather a hardware or ata driver problem. I know it's not likely to be schedule issue, but it doesn't hurt to ask :-) And please don't tell me it's hardware, I've changed a few motherboards (all VIA 8235/8237) and different manufacturer / types / firmware revisions HDDs since 5.0 because after an update or another some specific combination ceased to work. It seems some kind of regression introduced sometime after 5.3 release. Did you try sos' new driver yet? Nope, I didn't have the time. Given my luck with ata it is rather prudent to back-up ~200GB before trying. -- IOnut Unregistered ;) FreeBSD user ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
