Re: [-CURRENT tinderbox] failure on i386/i386
On Sun, 20 Jul 2003, Peter Wemm wrote: PW>Tinderbox wrote: PW> PW>> gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls/cat PW>gets.3 > catgets.3.gz PW>> Segmentation fault (core dumped) PW>> *** Error code 139 PW> PW>These false alarms are wearing a bit thin. Is there a problem with the PW>tinderbox build machine perhaps? This seems to be a real bug. There was a discussion on sparc64 Tinderbox coredumps recently. I see the same problem when doing 'make universe' about one third of the kernels or buildworlds fail with a make dumping core in vfork() (according to gdb). I had no chance yet to try with a make that uses fork() instead of vfork(). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on i386/i386
In message <[EMAIL PROTECTED]>, Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= writes: >Peter Wemm <[EMAIL PROTECTED]> writes: >> Tinderbox wrote: >> > gzip -cn >> > /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls/catgets.3 > >> > catgets.3.gz >> > Segmentation fault (core dumped) >> > *** Error code 139 >> These false alarms are wearing a bit thin. Is there a problem with the >> tinderbox build machine perhaps? > >No, the failures are too systematic for that. Don't trust that, I've seen RAM errors be reproducible to +/- 4 instructions in the cc1 binary in the past. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on i386/i386
Peter Wemm <[EMAIL PROTECTED]> writes: > Tinderbox wrote: > > gzip -cn > > /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls/catgets.3 > > > catgets.3.gz > > Segmentation fault (core dumped) > > *** Error code 139 > These false alarms are wearing a bit thin. Is there a problem with the > tinderbox build machine perhaps? No, the failures are too systematic for that. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on alpha/alpha
TB --- 2003-07-21 04:00:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-07-21 04:00:00 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-21 04:02:04 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/sys/close.2 > close.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/sys/connect.2 > connect.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/sys/dup.2 > dup.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/sys/execve.2 > execve.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/sys/extattr_get_file.2 > extattr_get_file.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/sys/fcntl.2 > fcntl.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libc/sys/fhopen.2 > fhopen.2.gz Segmentation fault (core dumped) *** Error code 139 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-07-21 04:43:54 - /usr/bin/make returned exit code 1 TB --- 2003-07-21 04:43:54 - ERROR: failed to build world TB --- 2003-07-21 04:43:54 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld fails in 5.1
At 9:48 PM -0400 7/20/03, Matt Loschert wrote: On Fri, 18 Jul 2003, Tim Kientzle wrote: > Crunchgen writes out and runs a short makefile in order to grab build information from a particular program. Since /rescue has about 120 components, you should see 'crunchgen_objs' and 'loop' targets getting built about 120 times. Ummm... by '363 times', did you mean 363 lines or 363 copies of this six-line block? If the latter, then something is definitely getting rebuilt needlessly. That whole block of 6 lines is getting written 363 times. IIRC, I grepped for 'Results of making crunchgen_objs' in the build logs. The failure that I am seeing is different than the above failure. I have a dual-CPU system, and have done buildworlds with -j5, -j4, and -j3. All of them fail with an error somewhere in 'rescue' building. None of them have *any* lines about 'Results of making crunchgen_objs'. There is some make-related error messages in the midst of building rescue, and then more standard 'cc' commands unrelated to rescue (which worked), and then buildworld fails. Well, the -j2 build also just finished with an error. The logfiles I keep are in the directory: ~gad/rescueb on freefall.freebsd, as gzip'ed files. The output is altered a little bit due to a script that I use to keep track of warning and error messages, but it is not altered much. The most notable difference is that at the end of the build it gives a summary of the # of warning messages that were generated. It may also be significant that I started out all of these buildworlds by first: rm -rf /usr/obj/usr/src/* so buildworld would have had to build *everything*. I do know that buildworld finishes OK if I define NORESCUE. Right now I am running a buildworld that does not specify -j, and I'll see if that completes OK. However, I have to leave for home now, so I'll have to finish that when I get back in on Monday. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld fails in 5.1
On Fri, 18 Jul 2003, Tim Kientzle wrote: > Tim Kientzle wrote: > > Matt Loschert wrote: > >> Then the following output repeated 363 times > >> > >> > >> crunchgen: make error: Remaking `crunchgen_objs' > >> > >> crunchgen: make error: Results of making crunchgen_objs: > >> > >> crunchgen: make error: > >> > >> crunchgen: make error: Remaking `loop' > >> > >> crunchgen: make error: Results of making loop: > >> > >> crunchgen: make error: > > A little more information: > > The word 'error' here concerns me, but > the repetition is expected. > Crunchgen writes out and runs a short makefile > in order to grab build information from a particular > program. Since /rescue has about 120 components, > you should see 'crunchgen_objs' and 'loop' targets > getting built about 120 times. > > Ummm... by '363 times', did you mean 363 lines or > 363 copies of this six-line block? If the latter, > then something is definitely getting rebuilt > needlessly. That whole block of 6 lines is getting written 363 times. IIRC, I grepped for 'Results of making crunchgen_objs' in the build logs. > Tim Again, I will email you the full logs in the morning. That will probably help you more. - Matt -- Matt Loschert - Software Engineer | email: [EMAIL PROTECTED]| ServInt Internet Services | web: http://www.servint.net/ | McLean, Virginia USA| phone: (703) 847-1381 | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld fails in 5.1
On Fri, 18 Jul 2003, Tim Kientzle wrote: > Matt Loschert wrote: > > After grepping through the build log > > for error messages, I found the following output, which appears to be some > > sort of build loop gone wild: > > > > First this > > -- > > Results of making rescue.cache: > > MAKEOBJDIRPREFIX=/usr/obj/usr/src/rescue/rescue crunchgen -q -m rescue.mk -c > > rescue.c rescue.conf > > > > > > Then the following output repeated 363 times > > > > > > crunchgen: make error: Remaking `crunchgen_objs' > > > > crunchgen: make error: Results of making crunchgen_objs: > > > > crunchgen: make error: > > > > crunchgen: make error: Remaking `loop' > > > > crunchgen: make error: Results of making loop: > > > > crunchgen: make error: > > > > > > With the following output repeated 2 times within the above output > > -- > > > > Run "make -f rescue.mk" to build crunched binary. > > *** Error code 1 > > Results of making rescue.mk: > > MAKEOBJDIRPREFIX=/usr/obj/usr/src/rescue/rescue crunchgen -q -m rescue.mk -c > > rescue.c rescue.conf > > > > > > I suppose this means that there is a dependency missing for the rescue > > crunchgen target? > > Good work, Matt. > > I wrote the /rescue stuff and a lot of people have > reported that it breaks parallel builds, but I haven't yet > come up with anything. (In part, because I haven't yet > managed to reproduce it. ) > > A couple of things look odd about this: > > 1) You should not be building 'rescue.mk' twice. > That could be the problem right there, if the rescue.mk > makefile is getting rebuilt (overwritten) while another > build thread is using it. The dependencies in > rescue/rescue/Makefile look right to me, but I > could be missing something. > > 2) I can't find the 'crunchgen_objs' or 'loop' > targets offhand. I'm doing a more extensive > find/grep search right now to see if I can figure > out where those are coming from. > > Somewhere in here is the answer to this problem, > I just don't see it yet. > > Tim Kientzle > > P.S. Could you email me the log from your build > that failed? Sure. I have it on one of my machines at work. I will email it to you on Monday morning.. > Could you try a lower -j value? If -j 2 fails, > for instance, that might be easier to diagnose. > Thanks for all your help. Definitely, I will fire off a build when I get in on Monday. Thanks, - Matt -- Matt Loschert - Software Engineer | email: [EMAIL PROTECTED]| ServInt Internet Services | web: http://www.servint.net/ | McLean, Virginia USA| phone: (703) 847-1381 | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB crappiness?
Juli Mallett wrote this message on Sat, Jul 19, 2003 at 19:42 -0500:
> I tried to upgrade my workstation to current recently, and I have to
> use a lot of USB, and while using some USB mass storage device, with
> a UFS filesystem on it, and doing a large operation to it (tar c|tar x)
> everything deadlocked on ufs, the USB stack blew up, and upon causing
> an interrupt to it, it panicked, and panic pagefaulted.
>
> Anyone else seeing these sorts of cohesive fallovers?
Ok, I think I know the problem now. It's a big different between NetBSD
and FreeBSD's bus_dma code. In NetBSD, they keep the same bus_dma_tag_t,
but in FreeBSD it is encouraged/required to create a new tag for sets of
allocations because of size (we can't do a bus_dmamem_alloc w/ a size).
So, in usb_allocmem, the tag equality doesn't work and allocated a full
page for each 64byte allocation. This quickly causes kmem to get exhusted.
ohci doesn't have this problem since it has it's own allocator for small
sizes.
this patch should fix it temporarily while I investigate a more complete
fix (xterm pasted):
Index: usb_mem.c
===
RCS file: /home/ncvs/src/sys/dev/usb/usb_mem.c,v
retrieving revision 1.1
diff -u -r1.1 usb_mem.c
--- usb_mem.c 2003/07/15 22:42:37 1.1
+++ usb_mem.c 2003/07/21 01:26:38
@@ -256,6 +259,8 @@
return (err);
}
b->fullblock = 0;
+ /* XXX - override the tag */
+ b->tag = tag;
for (i = 0; i < USB_MEM_BLOCK; i += USB_MEM_SMALL) {
f = (struct usb_frag_dma *)((char *)b->kaddr + i);
f->block = b;
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: putting /dev/lpt in polling mode in boot time.
>Try to disable ACPI. > >Marc Ah yes. Just noticed that in the FAQ. I'll fiddle with that when I've got the time. Might as well disable acpi since it barely works on my machine anyway. Apart from the power button, that is. Thanks Andrew Lankford ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: putting /dev/lpt in polling mode in boot time.
I may be smoking crack, but isn't it: bit 5 = 0001 = 0x10 ? bit 6 = 0010 = 0x20 ? E From: "Andrew Lankford" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: <[EMAIL PROTECTED]> Subject: Re: putting /dev/lpt in polling mode in boot time. Date: Sun, 20 Jul 2003 15:40:21 -0600 Before anyone corrects me, yes, the man page says bit 5 controls polling, 0x20. My question stands. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gconftool-2 failing
I have recently run into a problem with the gconftool-2 service that comes with gnome2. When I go into X I get a gcond process that runs out of control. If I try to install ports that require the gconftool-2 to run the port will fail to install. The error message I see is this gconftool-2 in free(): error: modified (chunk-) pointer. My feeling is that it is not attributed to the switch to the new gcc compiler but I could be wrong. I work in a KDE environment but have gnome there so I can switch to it if I fancy. It is an i386 box running -current cvsupped and built at 1200 MDT 07/20/03. PS I did read gnome's trouble shooting guide but the log file it describes has no useful info. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing gcc 3.3 compile failures -- fix for math/freefem
Hi,
> > -ifstream fin( path );
> > +std::ifstream fin( path );
> A much smaller patch could be produced with
>
> using namespace std;
>
> as appropriate.
>
> Have you checked with the upstream author to see which approach is
> likely to be rolled into the distribution?
Actually, upgrading the port to the lastest freefem version would have
been enough *doh* :o) (patch attached)
To answer your question: the freefem authors decided not to use the
'using namespace std' approach.
Cheers,
Simon
--- Makefile.orig Thu Jun 5 01:41:14 2003
+++ MakefileMon Jul 21 00:42:53 2003
@@ -6,7 +6,7 @@
#
PORTNAME= freefem
-PORTVERSION= 3.5.4
+PORTVERSION= 3.5.7
CATEGORIES=math cad
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE}
MASTER_SITE_SUBDIR=kfem
@@ -24,10 +24,6 @@
MAN1= freefem.1
.include
-
-.if ${OSVERSION} >= 500113
-BROKEN= "Does not compile (bad C++ code)"
-.endif
post-patch:
@${REINPLACE_CMD} -e 's|-O3 |\$$CXXFLAGS |g' ${WRKSRC}/configure
--- distinfo.orig Tue Mar 26 17:04:16 2002
+++ distinfoMon Jul 21 00:38:13 2003
@@ -1 +1 @@
-MD5 (freefem-3.5.4.tar.gz) = 746fe6487085011493a805e23507ae30
+MD5 (freefem-3.5.7.tar.gz) = e8f22515ab56f8e79fb789a11f8d4bef
signature.asc
Description: Digital signature
Re: putting /dev/lpt in polling mode in boot time.
On Sun, Jul 20, 2003 at 03:29:02PM -0600, Andrew Lankford wrote: [...] > ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/9 bytes threshold > ppbus0: on ppc0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > Try to disable ACPI. Marc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on sparc64/sparc64
TB --- 2003-07-20 21:51:58 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-07-20 21:51:58 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-20 21:54:00 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/gen/sysconf.3 > sysconf.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/gen/sysctl.3 > sysctl.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/gen/syslog.3 > syslog.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/gen/tcgetpgrp.3 > tcgetpgrp.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/gen/tcsendbreak.3 > tcsendbreak.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/gen/tcsetattr.3 > tcsetattr.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/gen/tcsetpgrp.3 > tcsetpgrp.3.gz Segmentation fault (core dumped) *** Error code 139 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-07-20 22:32:07 - /usr/bin/make returned exit code 1 TB --- 2003-07-20 22:32:07 - ERROR: failed to build world TB --- 2003-07-20 22:32:07 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on i386/i386
Tinderbox wrote: > gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls/cat gets.3 > catgets.3.gz > Segmentation fault (core dumped) > *** Error code 139 These false alarms are wearing a bit thin. Is there a problem with the tinderbox build machine perhaps? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
telnet build fails without openssl...
buildworld fails at telnet if you build with NOCRYPT and NO_OPENSSL -- telnet stuff is looking for NO_CRYPTO to disable this, which isn't documented anywhere... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: putting /dev/lpt in polling mode in boot time.
Before anyone corrects me, yes, the man page says bit 5 controls polling, 0x20. My question stands. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc-3.3 issues
Peter Kadau <[EMAIL PROTECTED]> writes: > Hi ! > > > http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Warning-Options.html#Warning%20Options > > Hmm, that's exactly as in the info page. > > > http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/C---Dialect-Options.html#C++%20Dialect%20Options > > > and search for permissive, to see the condition Alexander speaks of. > > Well, here it is: > -fpermissive > Downgrade messages about nonconformant code from errors to > warnings. By default, G++ effectively sets -pedantic-errors > without -pedantic; this option reverses that. This behavior and > this option are superseded by -pedantic, which works as it does > for GNU C. On second reading, I'm not sure I understand it either. (And I am a native speaker. :-) > > I admit, I'm not a native speaker, so please correct me. > Doesn't that mean, if you don't specify any pedantic, it defaults > to -pedantic-errors for C++, but if you specify -pedantic, you don't > get errors for warnings like it should be... ?? Specifying -pedantic doesn't turn errors into warnings for g++. I don't think the phrase 'this option reverses that' is intended to mean g++ swaps the meaning of -pendantic and -pendantic-errors; I think it is intended to mean -fpermissive downgrades many errors into warnings. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB crappiness?
On Sun, Jul 20, 2003 at 02:06:16AM -0400, Bryan Liesner wrote:
> On Sat, 19 Jul 2003, Juli Mallett wrote:
>
> > Hi,
> >
> > I tried to upgrade my workstation to current recently, and I have to
> > use a lot of USB, and while using some USB mass storage device, with
> > a UFS filesystem on it, and doing a large operation to it (tar c|tar x)
> > everything deadlocked on ufs, the USB stack blew up, and upon causing
> > an interrupt to it, it panicked, and panic pagefaulted.
> >
> > Anyone else seeing these sorts of cohesive fallovers?
> >
> > Thanx,
> > juli.
> >
>
> Yes, I can confirm that. I do an nightly dump to a file on my USB
> hard disk (ehci). I woke up to find a screen full of read errors, and
> at first I thought the disk went belly up. I reverted back and it was
> working fine. I/O speed has _seriously_ degraded as well. Prior to
> the bus dma patches, I was getting a little better than 8 MB/s writes to
> the disk, afterwards, less than 2 MB/s. The "performance hit"
> discussed prior to the commit is a bit of an understatement.
>
I've got a backtrace: I was unzipping zipslack.zip onto a 128MB USB key, when
one I got a message 'Device not configured' after one file, and subseqent files
failed with 'Input/output error'. I cancelled it, and tried to run 'df -h' to
see if the disk was full. Then I got the panic:
panic: kmem_malloc(4096): kmem_map too small: 218132480 total allocated
Debugger("panic")
Stopped at Debugger+0x54: xchgl%ebx,in_Debugger.0
db> tr
Debugger(c038d566,c03fdea0,c0399f78,d8d999ec,100) at Debugger+0x54
panic(c0399f78,1000,d007000,d8d99a1c,14) at panic+0xd5
kmem_malloc(...) at kmem_alloc+0x100
page_alloc(...) at page_alloc+0x27
slab_zalloc(...) at slab_zalloc+0x127
uma_zone_slab(...) at uma_zone_slab+0xe8
uma_zalloc_internal(...) at uma_zalloc_internal+0x7c
slab_zalloc(...) at slab_zalloc+0x7f
uma_zone_slab(...) at uma_zone_slab+0xe8
uma_zalloc_bucket(...) at uma_zalloc_bucket+0x176
uma_zalloc_arg(...) at uma_zalloc_arg+0x2c7
malloc(adc,c03cf520,102,21b,21b) at malloc+0x5c
sigacts_alloc(c03fdcc0,0,0,d8d99c48,c5051980) at sigacts_alloc+0x25
fork1(c4457000,8034,0,d8d99ccc,c4457000) at fork1+0x7d5
vfork(c4457000,d8d99d10,0,16,0) at vfork+0x2b
syscall(2f,2f,2f,bfbfda90,0) at syscall+0x2b0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (66, FreeBSD ELF32, vfork), eip = 0x8096ef8, esp = 0xbfbfb850, ebp =
0xbfbfc938 ---
db >
--
Bruce Cran
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
putting /dev/lpt in polling mode in boot time.
Kernel: FreeBSD bogushost2 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sat Jul 19 23:38:13 EDT 2003[EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARL5KERNEL i386 Since I kept on getting "stray irq 7"'s with my laserjet 4, I decided to set my parallel port to use polled mode at boottime. While I guess I could add a special script in /usr/local/etc/rc.d to run 'lptcontrol -p', this sucks because it doesn't exit if the printer isn't on, even though it works otherwise. So I added to /boot/device.hints the following three lines: hint.ppc.0.at="isa" # hint.ppc.0.irq="7" hint.ppc.0.flags="0x20" According to the manual setting bit 4 of the flag to one should set it to polling mode, but it doesn't work. I know for a fact that the loader is reading the hints file, too. Here's dmesg: ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port Is there something that I overlooked? Thanks, Andrew Lankford PS Apart from some annoyances with ghostscript ps to pcl translation, nothing beats a vintage HP laser printer :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Jail Roadmap
In message <[EMAIL PROTECTED]>, Rus Foster writes: >I know recently that the jails have changed maintainer and I just wondered >if there is any road map of features that will be upcoming and in which >versions.. Well... Jails havn't quite changed maintainer because both Robert Watson and I have some grave concerns about the architectural direction and control of jails. The problem with jails is that the code has its fingers all over the kernel, and therefore more than average attention is needed to the code and the way things are done. In addition to that we also have had a hard time defining where we are headed with jails, for instance there is a patchset out there which totally virtualizes the network stack, and that may be a better model for jails etc. The problem is that neither Robert nor I can currently find the necessary time to steer/maintain/mentor jails. So right now we havn't quite appointed a new maintainer for jails, but we're very much aware that something needs to move, possibly "us out of the way". -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Jail Roadmap
Hi All, I know recently that the jails have changed maintainer and I just wondered if there is any road map of features that will be upcoming and in which versions.. cheers Rus -- www: http://jvds.com | Virtual Servers from just $15/mo MSNM: [EMAIL PROTECTED] | Totally Customizable Technology e: [EMAIL PROTECTED] | FreeBSD & Linux 10% donation to FreeBSD.org on each purchase ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: login(1) doesn't enforce times.allow/times.deny over ssh(1)
On Sunday 20 July 2003 09:38 pm, Doug White wrote: > On Sun, 20 Jul 2003, Farid Hajji wrote: > > When using ssh, I'm not trying public/private keys, > > just plain unix passwords. Doesn't ssh access login(1) > > in this case? > > sshd does not use login unless requested to do so by the UseLogin config > parameter. Ye, that was it. > There have been security vulnerabilities exposed by using this option in > the past. You have been warned :) So we need an additional pam module for such policy settings. That's reasonable. Many thanks. -- Farid Hajji. http://www.farid-hajji.net/address.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1 setfacl problem
On Sun, 20 Jul 2003, Branko F. Gracnar wrote: > >specify what POSIX.1e considers an incomplete ACL and rejects. Try using: > > > > setfacl -dm u::rwx,g::rx,o::rx,u:some_user:rwx,m:rwx test_directory Looks like you might have some typos: > # setfacl -dm u::rwx,g::rx,o:rx,g:some_group:rwx,m:rwx test_directory ^^^ o::rx ^^ m::rwx Try with those changes and let me know if it's still causing problems. > setfacl: acl_from_text() failed: Invalid argument > > ... > > Brane > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: login(1) doesn't enforce times.allow/times.deny over ssh(1)
On Sun, 20 Jul 2003, Farid Hajji wrote: > When using ssh, I'm not trying public/private keys, > just plain unix passwords. Doesn't ssh access login(1) > in this case? sshd does not use login unless requested to do so by the UseLogin config parameter. There have been security vulnerabilities exposed by using this option in the past. You have been warned :) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
compressed modules
Please try the enclosed patch. It adds support to sysinstall for
compressed modules. I think this will save some space on the drivers
disk since it isn't currently compressed (unless I'm smoking the good
stuff).
Warner
Index: modules.c
===
RCS file: /cache/ncvs/src/usr.sbin/sysinstall/modules.c,v
retrieving revision 1.6
diff -u -r1.6 modules.c
--- modules.c 15 Jan 2003 21:47:36 - 1.6
+++ modules.c 18 May 2003 05:52:55 -
@@ -23,7 +23,7 @@
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
- * $FreeBSD$
+ * $FreeBSD: src/usr.sbin/sysinstall/modules.c,v 1.6 2003/01/15 21:47:36 jhb Exp $
*/
#include "sysinstall.h"
@@ -91,6 +91,20 @@
else
msgConfirm("Loading module %s failed", dp->d_name);
}
+ }
+ if (strcmp(dp->d_name + dp->d_namlen - (sizeof(".ko.gz") - 1), ".ko.gz")
== 0) {
+ snprintf(module, sizeof(module), "/tmp/%s", dp->d_name);
+ module[strlen(module) - sizeof(".gz")] = '\0';
+ snprintf(desc, sizeof(desc), "zcat < %s/%s > %s", MODULESDIR,
+ dp->d_name, module);
+ system(desc);
+ if (kldload(module) < 0 && errno != EEXIST) {
+ if (desc_str[0])
+ msgConfirm("Loading module %s failed\n%s", dp->d_name,
desc_str);
+ else
+ msgConfirm("Loading module %s failed", dp->d_name);
+ }
+ unlink(module);
}
}
closedir(dirp);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on i386/i386
TB --- 2003-07-20 18:14:53 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-07-20 18:14:53 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-20 18:16:50 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/net/nsdispatch.3 > nsdispatch.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/net/rcmd.3 > rcmd.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/net/rcmdsh.3 > rcmdsh.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/net/resolver.3 > resolver.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/net/sockatmark.3 > sockatmark.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls/catclose.3 > catclose.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls/catgets.3 > catgets.3.gz Segmentation fault (core dumped) *** Error code 139 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-07-20 18:56:34 - /usr/bin/make returned exit code 1 TB --- 2003-07-20 18:56:34 - ERROR: failed to build world TB --- 2003-07-20 18:56:34 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
login(1) doesn't enforce times.allow/times.deny over ssh(1)
I'm trying to set up a login class on 5.1-R which limits users from logging in at night or on week ends. Unfortunately, the time limits are not enforced by login(1), when the host is accessed via ssh (only from the console are the time limits enforced): In /etc/login.conf, I've set this: time_limited:\ :welcome=/root/motd-timelimited:\ :times.allow=MoTuWeThFr0800-1900:\ :times.deny=So-2359:\ :tc=default: and ran 'cap_mkdb /etc/login.conf' as instructed. Changed login class of some test users with chsh(1). The change in the 'welcome' capability works all right, but not the time limitations (when using ssh). I'm using the default /etc/pam.d/login, as of 5.1-R, where pam_ssh.so is always commented out. When using ssh, I'm not trying public/private keys, just plain unix passwords. Doesn't ssh access login(1) in this case? Do you have an idea what's wrong here, or, better yet, a solution? Many thanks. -- Farid Hajji. http://www.farid-hajji.net/address.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on amd64/amd64
TB --- 2003-07-20 17:33:21 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-07-20 17:33:21 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-20 17:35:21 - building world TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/sys/issetugid.2 > issetugid.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/sys/jail.2 > jail.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/sys/kenv.2 > kenv.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/sys/kill.2 > kill.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/sys/kldfind.2 > kldfind.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/sys/kldfirstmod.2 > kldfirstmod.2.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libc/sys/kldload.2 > kldload.2.gz Segmentation fault (core dumped) *** Error code 139 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. TB --- 2003-07-20 18:14:52 - /usr/bin/make returned exit code 1 TB --- 2003-07-20 18:14:52 - ERROR: failed to build world TB --- 2003-07-20 18:14:52 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: where is kern.ca.da.no_6_byte?
On Sun, 20 Jul 2003, Harald Schmalzbauer wrote: > Andre Guibert de Bruet wrote: > > On Sun, 20 Jul 2003, Harald Schmalzbauer wrote: > > > > > Kenneth D. Merry wrote: > > > > > seems that this sysctl doesn't exist any more! > > > > > Is there anything similar? > > > > > > > > It has been renamed: > > > > kern.cam.da.%d.minimum_cmd_size > > > > > > > > Where %d is the unit number for the da(4) device. > > > > > > Thaks a lot! Where can I find such info? I looked via cvsweb > > for scsi_da.c > > > but couldn't find anything. Is it possible to list all kernel tunables? > > > > sysctl -a. You'll probably want to pipe it's output to your favorite > > pager. "sysctl kern" will list just the entries in the kern MIB. > > OIC. It's not available until the device is pluged in, which makes it > absolutely useless. > When I plug it in the machine behaves abnormal, so I need to set it BEFORE > connecting USB devices. > Why has this tunable by default a value which makes the machine unstable by > every umass I plug in which has no "qirk" entry? And if I look how many > quirks there are I assume that almost every device needs no_6byte set. > Why not make it default? Perhaps this would prevent criminal people from > intentionally crashing servers when intruding my serverroom armed with > dozends of USB devices;) I don't mean to defend the current state of the USB stack not recovering from errors and bad behavior, but ask yourself: "Do I really want USB enabled on my servers?" For most people, the answer is a resounding "No". Food for thought. Regards, > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: where is kern.ca.da.no_6_byte?
Andre Guibert de Bruet wrote: > On Sun, 20 Jul 2003, Harald Schmalzbauer wrote: > > > Kenneth D. Merry wrote: > > > > seems that this sysctl doesn't exist any more! > > > > Is there anything similar? > > > > > > It has been renamed: > > > kern.cam.da.%d.minimum_cmd_size > > > > > > Where %d is the unit number for the da(4) device. > > > > Thaks a lot! Where can I find such info? I looked via cvsweb > for scsi_da.c > > but couldn't find anything. Is it possible to list all kernel tunables? > > sysctl -a. You'll probably want to pipe it's output to your favorite > pager. "sysctl kern" will list just the entries in the kern MIB. OIC. It's not available until the device is pluged in, which makes it absolutely useless. When I plug it in the machine behaves abnormal, so I need to set it BEFORE connecting USB devices. Why has this tunable by default a value which makes the machine unstable by every umass I plug in which has no "qirk" entry? And if I look how many quirks there are I assume that almost every device needs no_6byte set. Why not make it default? Perhaps this would prevent criminal people from intentionally crashing servers when intruding my serverroom armed with dozends of USB devices;) -Harry > > Regards, > > > Andre Guibert de Bruet | Enterprise Software Consultant > > > Silicon Landmark, LLC. | http://siliconlandmark.com/> > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: background processes stuck in locks with ULE
On Sun, 2003-07-20 at 15:09, Kris Kennaway wrote: > The process stats are not updated properly under ULE at the moment. > If a process takes up 60% of CPU and then sleeps, top will continue to > show it at 60% until the next time it runs. It does not in fact > continue to use CPU. In my case if I kill the process (that appears to be stuck in *Giant) the system immediately starts to improve in performance. So it seems that this process (usually a daemon) is still running in bg and eating up more cycles than necessary. Even then performance is extremely slow compared to 4BSD. However in single user mode (with no bg processes), performance seems normal. When I mean slow.. it means being able to read line by line as ipfw rules are being added by a script, or an ls -l output on a large directory. I'm going to compile a UP kernel, and report if it makes a difference. -- "Optimized, readable, on time; Pick any two." FreeBSD 5.1-CURRENT i386 12:55AM up 5:36, 1 user, load averages: 0.45, 0.39, 0.34 signature.asc Description: This is a digitally signed message part
RE: where is kern.ca.da.no_6_byte?
On Sun, 20 Jul 2003, Harald Schmalzbauer wrote: > Kenneth D. Merry wrote: > > > seems that this sysctl doesn't exist any more! > > > Is there anything similar? > > > > It has been renamed: > > kern.cam.da.%d.minimum_cmd_size > > > > Where %d is the unit number for the da(4) device. > > Thaks a lot! Where can I find such info? I looked via cvsweb for scsi_da.c > but couldn't find anything. Is it possible to list all kernel tunables? sysctl -a. You'll probably want to pipe it's output to your favorite pager. "sysctl kern" will list just the entries in the kern MIB. Regards, > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OT:escaping X barfings
> > CAn you tell me how a procedure how to patch X and kernel > > to avoid X barfings from securelevel? My release is a FreeBSD 5.1. > > 2) adding `options APERTURE` to my kernel > > 3) make buildkernel && make install kernel && make > > buildworld 4) reboot and face the music > > Do as you feel you must, but I installed 5.1-RELEASE and X from ports and > it's running fine. Are you starting from a terminal with 'startx' or do > you start xdm at boot? If you use startx, I believe you need to install > x-wrapper to get around permission issues. This is a FAQ. X needs to access /dev/io, which is not possible if securelevel is raised. You need to startx/gdm and _then_ raise securelevel. This is not flexible, because if X server crashes, you can't start it again without rebooting. OpenBSD provides an option 'APERTURE' which allows X to start even when securelevel is >0. I wish we would have that as well... -- Farid Hajji. http://www.farid-hajji.net/address.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: where is kern.ca.da.no_6_byte?
Kenneth D. Merry wrote: > > seems that this sysctl doesn't exist any more! > > Is there anything similar? > > It has been renamed: > > kern.cam.da.%d.minimum_cmd_size > > Where %d is the unit number for the da(4) device. Thaks a lot! Where can I find such info? I looked via cvsweb for scsi_da.c but couldn't find anything. Is it possible to list all kernel tunables? > > > It also seems I'm a bit unlucky these days with 5.1. CF-Reader > crahes the > > system, floppy crashes the system, my RAID-controller crashes > the system, > > also /stand/fdisk crashes the system. > > And since my burner has reached MTBF I bought the USB-Floppy to > install via > > ftp, but FreeBSD doesn't boot from USB-Floppys. DOS does! > > If your system is crashing, send stack traces to this list, and maybe > someone can help track down what the problem is. I'll try to do but I'm no programmer and e.g. for the HPT372 the machine is crashing before mounting /. But I'll do my best. Thanks, -Harry > > Ken > -- > Kenneth Merry > [EMAIL PROTECTED] > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OT:escaping X barfings
[EMAIL PROTECTED] wrote: Hello all! CAn you tell me how a procedure how to patch X and kernel to avoid X barfings from securelevel? My release is a FreeBSD 5.1. You might want to replace "barfing" with an actual description of the problem. I looked for patches, unfortunately they're more than a year old.Googled and searched on MARC - nothing new under the sun. Therefore I suppose all works ok in -CURRENT.I'm thinking of: 1) CVSup src and ports to "." I wouldn't cvsup src to . unless you plan on developing. 2) adding `options APERTURE` to my kernel 3) make buildkernel && make install kernel && make buildworld 4) reboot and face the music Do as you feel you must, but I installed 5.1-RELEASE and X from ports and it's running fine. Are you starting from a terminal with 'startx' or do you start xdm at boot? If you use startx, I believe you need to install x-wrapper to get around permission issues. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1 setfacl problem
>specify what POSIX.1e considers an incomplete ACL and rejects. Try using: > > setfacl -dm u::rwx,g::rx,o::rx,u:some_user:rwx,m:rwx test_directory # setfacl -dm u::rwx,g::rx,o:rx,g:some_group:rwx,m:rwx test_directory setfacl: acl_from_text() failed: Invalid argument ... Brane ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: possible unionfs bug
On Sun, Jul 20, 2003 at 03:02:21PM +0200, Divacky Roman wrote: +> I might be wrong but this: +> +> free(mp->mnt_data, M_UNIONFSMNT); /* XXX */ +> mp->mnt_data = 0; +> +> seems to me wrong and might cause crashes etc. +> am I correct or wrong? Could you describe scenario when this could be dangerous? Or why do you think it is? This memory is allocated while mounting unionfs file system, so it is quite natural to free this memory while unmounting file system. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: where is kern.ca.da.no_6_byte?
On Sun, Jul 20, 2003 at 09:13:51 +0200, Harald Schmalzbauer wrote: > Hello all, > > while my CF-Card USB adaptor is crashing 5.1 and my NEC USB floppy also > crashes 5.1 I found that sysctl -w kern.cam.da.no_6_byte=1 could help but it > seems that this sysctl doesn't exist any more! > Is there anything similar? It has been renamed: kern.cam.da.%d.minimum_cmd_size Where %d is the unit number for the da(4) device. > It also seems I'm a bit unlucky these days with 5.1. CF-Reader crahes the > system, floppy crashes the system, my RAID-controller crashes the system, > also /stand/fdisk crashes the system. > And since my burner has reached MTBF I bought the USB-Floppy to install via > ftp, but FreeBSD doesn't boot from USB-Floppys. DOS does! If your system is crashing, send stack traces to this list, and maybe someone can help track down what the problem is. Ken -- Kenneth Merry [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: msdof and fstab
On Wed, 16 Jul 2003 [EMAIL PROTECTED] wrote: > I am having trouble mounting my windows partition from the fstab file. I have an > entry in fstab that looks like this "/dev/ad6s5 /mnt/disk2 msdosfs rw 0 0". > When I try to mount the disk I get the following error "mount: disk2: unknown > special file or file system". What makes things even more strange is that I can > mount the slice just fine when I issue mount_msdosfs from the command prompt. Does > anyone have any ideas? I believe that fstab wants 'msdos' and not 'msdosfs'. Regards, > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Erratum: Re: Fixing gcc 3.3 compile failures -- kde portsproposal
On Sunday 20 July 2003 12:59, Peter Kadau wrote: > Hi ! > > > With those settings, I could do a forced upgrade for everything. > > Ahem, not quite true, I forgot kdebase3. > Everything configures, but that thing is the only > reluctant to build. > > Some sort of known problem with static_cast as far as > I can see. > > So - no portupgrade -fa on my current... *sigh* We (kde@) are working on the problem. Since we're also working on getting the upcoming 3.1.3 release ready for the ports tree, we're concentrating on that and not 3.1.2. More news as it happens. A. -- Andy Fawcett | [EMAIL PROTECTED] | [EMAIL PROTECTED] "In an open world without walls and fences, | [EMAIL PROTECTED] we wouldn't need Windows and Gates." -- anon | [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
possible unionfs bug
Hi, I might be wrong but this: free(mp->mnt_data, M_UNIONFSMNT); /* XXX */ mp->mnt_data = 0; seems to me wrong and might cause crashes etc. am I correct or wrong? its from union_vfsops.c:384 thnx Roman Divacky ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
On Sun, Jul 20, 2003 at 11:53:43AM +, Tinderbox wrote: > >>> stage 4: building everything.. > [...] > ===> bin/ed > cc -O -pipe -DDES-Wsystem-headers -Werror -Wall -Wno-format-y2k -W > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts > -Winline -Wnested-externs -Wredundant-decls -c > /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/ed/buf.c > cc -O -pipe -DDES-Wsystem-headers -Werror -Wall -Wno-format-y2k -W > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts > -Winline -Wnested-externs -Wredundant-decls -c > /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/ed/cbc.c > In file included from > /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/openssl/ui_compat.h:63, > from > /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/openssl/des_old.h:439, > from > /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/openssl/des.h:101, > from > /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/ed/cbc.c:46: > /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/openssl/ui.h:220: > warning: function declaration isn't a prototype > *** Error code 1 > > Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/ed. > *** Error code 1 > Fixed in src/bin/ed/Makefile,v 1.28. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
[-CURRENT tinderbox] failure on sparc64/sparc64
TB --- 2003-07-20 11:13:14 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-07-20 11:13:14 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-20 11:15:11 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] ===> bin/ed cc -O -pipe -DDES-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/ed/buf.c cc -O -pipe -DDES-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/ed/cbc.c In file included from /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/openssl/ui_compat.h:63, from /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/openssl/des_old.h:439, from /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/openssl/des.h:101, from /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/ed/cbc.c:46: /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/openssl/ui.h:220: warning: function declaration isn't a prototype *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/ed. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-07-20 11:53:43 - /usr/bin/make returned exit code 1 TB --- 2003-07-20 11:53:43 - ERROR: failed to build world TB --- 2003-07-20 11:53:43 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make release of CURRENT on 4.7 broken again ?
On Sun, Jul 20, 2003 at 02:04:28PM +0300, Andrey Elperin wrote:
>
> Hi,
>
> A few days ago I've noticed such messages in CURRENT buildlog (on 4.7
> box, building without -j) :
>
> cc -Os -pipe -c chown_stub.c
> ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o
> crunchide -k _crunched_chown_stub chown.lo
> echo "int _crunched_chroot_stub(int argc, char **argv, char **envp){return
> main(argc,argv,envp);}" >chroot_stub.c
> cc -Os -pipe -c chroot_stub.c
> ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o
> crunchide -k _crunched_chroot_stub chroot.lo
> cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo echo.lo
> expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo sync.lo
> bsdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo mount_cd9660.lo
> mount_msdosfs.lo reboot.lo restore.lo swapon.lo umount.lo ftp.lo telnet.lo vi.lo
> chown.lo chroot.lo -ledit -lgeom -lkvm -lm -lncurses
> -lutil
> *** Error code 1
>
> Stop in /usr/obj/usr/src/release/fixit_crunch.
> *** Error code 1
>
I have committed a fix for this to src/bin/ed/ a few minutes ago.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
make release of CURRENT on 4.7 broken again ?
Hi,
A few days ago I've noticed such messages in CURRENT buildlog (on 4.7
box, building without -j) :
cc -Os -pipe -c chown_stub.c
ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o
crunchide -k _crunched_chown_stub chown.lo
echo "int _crunched_chroot_stub(int argc, char **argv, char **envp){return
main(argc,argv,envp);}" >chroot_stub.c
cc -Os -pipe -c chroot_stub.c
ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o
crunchide -k _crunched_chroot_stub chroot.lo
cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo echo.lo
expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo sync.lo bsdlabel.lo
clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo reboot.lo
restore.lo swapon.lo umount.lo ftp.lo telnet.lo vi.lo chown.lo chroot.lo -ledit -lgeom
-lkvm -lm -lncurses
-lutil
*** Error code 1
Stop in /usr/obj/usr/src/release/fixit_crunch.
*** Error code 1
Stop in /usr/src/release.
*** Error code 1
Stop in /usr/src/release.
Did anyone who build CURRENT on 4.x notice the same ? Last release of CURRENT
on my box was successfully builded on July, 16 (with CVSCMDARGS="2003-07-16 00:00").
Thanks in advance.
--
Andrey Elperin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: i386 'make release' broken
On Sun, Jul 20, 2003 at 02:18:42AM -0600, Scott Long wrote: > Just got the following from a 'make release BUILDNAME=5.1-CURRENT > CHROOTDIR=/usr/release CVSROOT=/usr/ncvs NOPORTS= NODOC= ". My > world was up to date to within a day. The full log is at > http://people.freebsd.org/~scottl/current-release-i386.log.gz. Note > that while this is an SMP machine, -j was not used. Also, this > problem did not stop the previous 'buildworld' from completing. > I haven't tried to build a release in a few weeks, so I can't quickly > say when the breakage started. > > > > cc -O -pipe -mcpu=pentiumpro-Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch > -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts -Winline > -Wnested-externs -Wredundant-decls -c /usr/src/bin/ed/re.c > /usr/src/bin/ed/re.c: In function `get_compiled_pattern': > /usr/src/bin/ed/re.c:44: warning: declaration of `exp' shadows a global > declaration > :0: warning: shadowed declaration is here > *** Error code 1 > Marius Strobl has submitted a fix for this (privately to me and Alexander) a week ago. I have just committed it. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Erratum: Re: Fixing gcc 3.3 compile failures -- kde ports proposal
Hi ! > With those settings, I could do a forced upgrade for everything. Ahem, not quite true, I forgot kdebase3. Everything configures, but that thing is the only reluctant to build. Some sort of known problem with static_cast as far as I can see. So - no portupgrade -fa on my current... *sigh* Cheers Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Annoucning DragonFly BSD!
:Wouldn't it be possible to achive the same result without the VFS with :well organized lib subdirs? like "usr/lib/xyzlib1.2/" and :"usr/lib/xyzlib1.3/" which would maintain the install for any given :version of a lib? In other words, instead of just dumping all the libs :into the one place, you simply place them into sub folders instead and :then link them as needed? Granted this would cause havoc for things like :LD_LIBRARY_PATH. I never did like the way we dump things in the lib :dir's, its messy. The VFS idea is interesting, but it like cleaning the :mess by sending parts of the big mess into another dimention, making it :a trans-dimentional mess (technically a larger mess). This throws away :the KISS principle. Not unless one wanted to make major modifications to all the third party applications out there, which nobody really wants to do, because hacking all those programs up makes it difficult to track updates. :> taken for granted. Begin userland VFSs with the capability of :> overlaying the entire filesystem space, these environments would be :> extremely powerful. : :I suspect this ability would usefull for other things too, possibly for :security lock-downs on shell users env's without chrooting them as an :example. : :-Jon Yes, Exactly. -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
i386 'make release' broken
Just got the following from a 'make release BUILDNAME=5.1-CURRENT CHROOTDIR=/usr/release CVSROOT=/usr/ncvs NOPORTS= NODOC= ". My world was up to date to within a day. The full log is at http://people.freebsd.org/~scottl/current-release-i386.log.gz. Note that while this is an SMP machine, -j was not used. Also, this problem did not stop the previous 'buildworld' from completing. I haven't tried to build a release in a few weeks, so I can't quickly say when the breakage started. cc -O -pipe -mcpu=pentiumpro-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/bin/ed/re.c /usr/src/bin/ed/re.c: In function `get_compiled_pattern': /usr/src/bin/ed/re.c:44: warning: declaration of `exp' shadows a global declaration :0: warning: shadowed declaration is here *** Error code 1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Negative bio_offset -current kernel panic
In message <[EMAIL PROTECTED]>, "Aaron Wohl" writes:
>I got a got this kernel panic:
>geom/geom_dev.c:("Negative bio_offset (%jd) on bio %p",
>
>Anyone seeing this also?
Please put DDB in your kernel and try to reproduce, then capture
traceback etc. (see handbook).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
where is kern.ca.da.no_6_byte?
Hello all, while my CF-Card USB adaptor is crashing 5.1 and my NEC USB floppy also crashes 5.1 I found that sysctl -w kern.cam.da.no_6_byte=1 could help but it seems that this sysctl doesn't exist any more! Is there anything similar? It also seems I'm a bit unlucky these days with 5.1. CF-Reader crahes the system, floppy crashes the system, my RAID-controller crashes the system, also /stand/fdisk crashes the system. And since my burner has reached MTBF I bought the USB-Floppy to install via ftp, but FreeBSD doesn't boot from USB-Floppys. DOS does! Desperate greetings, -Harry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: background processes stuck in locks with ULE
On Sun, Jul 20, 2003 at 01:48:39PM +0800, Khairil Yusof wrote: > Trying out ULE scheduling on an SMP machine causes background processes > to be stuck in locks. > > One or two processes will always get stuck in *Giant (and takes up like > 60% of lock) and if these are killed, then other processes are always > taking up a total of around 10% in lock, which makes the system crawl. > > Anybody else seeing this on an SMP machine with ULE scheduler? The process stats are not updated properly under ULE at the moment. If a process takes up 60% of CPU and then sleeps, top will continue to show it at 60% until the next time it runs. It does not in fact continue to use CPU. Kris pgp0.pgp Description: PGP signature
