On Sat, May 11, 2002 at 10:33:03AM -0700, David O'Brien wrote:
On Sat, May 11, 2002 at 12:35:38PM +0300, Ruslan Ermilov wrote:
I say again, the malloc usage is not in c-parse.in, it is in the parser
driver produced by Byacc.
OK, now that you've explained it:
I'll look this patch
According to Steve Kargl:
I reported this earlier today. I had
hint.acpi.0.disable=1
in /boot/loader.conf to disable ACPI.
If I comment out this hint, the system
boots, but I end up with the following in dmesg.
Right, but if I want to be able to suspend / resume my laptop, I *need* to use
Hi,
On Thu, 09 May 2002 20:33:22 +0100
Mark Murray [EMAIL PROTECTED] said:
mark /usr/sbin/scriptdump
This script is from KAME. It seems that NetBSD doesn't install it.
Is someone actually using it? If okay, I'll change to don't install
it.
That sounds good to me! Go right ahead!
On Sat, May 11, 2002 at 10:33:03AM -0700, David O'Brien wrote:
I'll look this patch over carefully, but at first glance it all seems
like stylistic changes. Does it fix a bug, or you just don't like how I
did things?
The changes are mostly _not_ stylistic like .ORDER with one argument
On Sun, May 12, 2002 at 04:43:33AM -0700, David O'Brien wrote:
On Sat, May 11, 2002 at 10:33:03AM -0700, David O'Brien wrote:
I'll look this patch over carefully, but at first glance it all seems
like stylistic changes. Does it fix a bug, or you just don't like how I
did things?
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
Hello,
As per the request of rwatson; and a courtesy which I would like to fulfil.
I would be very greatful if you could take a look at the newly added manual
page, available at: src/usr.sbin/devinfo/devinfo.8
It was added on Sunday May/12 by Robert Watson.
Thank you,
Regards.
-- Hiten
With this morning's build I have somehow lost ssh. I get the following
error:
May 12 10:11:03 worldinternet sshd[24224]: in openpam_load_module(): no
pam_nologin.so found
May 12 10:11:03 worldinternet sshd[24224]: fatal: PAM initialisation failed[1]:
failed to load module
May 12 10:27:32
cc -O -pipe -march=athlon -DIN_GCC -DHAVE_CONFIG_H
-DPREFIX=\/usr/obj/usr/src/i386/usr\
-I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools
-I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools
-I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc
David O'Brien wrote:
People are really making me regret that I sweated over GCC 3 to bring it
into our tree for all of our architectures and to get many serious bugs
fixed in the FSF CVS repository.
Really? It must be in private email... from what I've seen, everything
went incredibly
Hello,
I have a -CURRENT from May 5th.
I recently bought a new 40 gig IDE disk and proceeded to install it. I
went for compatible (as opposed to dangerously dedicated) mode. I
first used fdisk to initialize the slice table and create a FreeBSD
slice that would take in the whole disk. After
DOS partition tables use a 24b C/H/S value. With 512B sectors, this
means they are incapable of representing more than 8G of disk space.
To support a 32b sector offset, you have to go to LBA mode. This
isn't really supported by any BIOS that still respects the C/H/S
offsets, since they will
In message [EMAIL PROTECTED], Terry Lambert writes:
DOS partition tables use a 24b C/H/S value. With 512B sectors, this
means they are incapable of representing more than 8G of disk space.
Ahh, I love these time-warp emails from Terry. [*]
This is the way the world looked circa 1990.
I
Poul-Henning Kamp wrote:
Please do not follow Terrys advice, unless and until you have
independent confirmation that his 10 year old knowledge is still
current.
Poul: I will say that advice is bad, but I will not provide advice
of my own, because it might be bad, too, and open me to
In message [EMAIL PROTECTED], Terry Lambert writes:
Poul-Henning Kamp wrote:
Please do not follow Terrys advice, unless and until you have
independent confirmation that his 10 year old knowledge is still
current.
Poul: I will say that advice is bad, but I will not provide advice
of my
Hello,
the import of GCC3.1 seems to reveal old bugs :
(while cross-compiling a new kernel atfer cross-compiling a new -Current
world under a fresh -Stable)
(the %b flag is not recognized in the printf()s of scsi_low.c)
%-
cc -c -O -pipe -march=pentiumpro -Wall
Hello everybody,
OK, just in order to clarify before things get out of hand.:-)
There is no immediate problem, the drive in question has been installed
and works fine. (using it this instant).
As for the BIOS part, the mobo could probably use an upgrade, because
the BIOS is still from spring
Gang,
I occasionally get tcsh coredumps (signal 6). I mostly ignored it,
but today I decided to track it down for once. This is the backtrace:
(gdb) bt
#0 0x808e4a3 in access ()
#1 0x80ba9fa in abort () at /usr/src/lib/libc/../libc/stdlib/abort.c:78
#2 0x80b97a9 in wrtwarning (p=0x80ef54e in
That one's easy to diagnose:
You change your windowsize while tcsh happened to be in free(3) (frame #12).
tcsh gets the SIGWINSZ (sp?) signal, and tries to allocate a buffer,
probably a new line-edit buffer, calls malloc(3) (fram #4) and malloc
abort(3)'s the program.
It is not legal to
On Sun, May 12, 2002 at 10:32:33AM -0700, Steve Kargl wrote:
cc -O -pipe -march=athlon -DIN_GCC -DHAVE_CONFIG_H
-DPREFIX=\/usr/obj/usr/src/i386/usr\
-I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools
-I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools
On Sun, 12 May 2002 23:27:42 +0200, Poul-Henning Kamp [EMAIL PROTECTED] said:
The correct solution is probably to set a flag in the signal handler
and resize the buffer before the next line is read.
Or, somewhat less optimally, to block SIGWINCH (and any other signals
with similar handler
On Sat, May 11, 2002 at 02:00:38PM +0200, Ollivier Robert wrote:
FreeBSD sidhe.freenix.org FreeBSD 5.0-CURRENT #6: Thu May 9 17:14:15 CEST 2002
[EMAIL PROTECTED]:/local/src/src/sys/i386/compile/SIDHE i386
Sony VAIO Z600TEK, current just before gcc 3.1.
Having tested the usb
On Fri, May 10, 2002 at 01:35:56PM -0700, Terry Lambert wrote:
Mikhail Teterin wrote:
= For my information: Why didn't you take John De Bowsky's advice to:
=
= ld $objlist `lorder $liblist | tsort -q`
I tried that before I asked on the mailing list the first time. It
did
On Sun, May 12, 2002 at 11:27:42PM +0200, Poul-Henning Kamp wrote:
It is not legal to recursively call malloc/free/realloc, and therefore
you should either protect all calls to malloc/free/realloc by blocking
signals or better: not call them in signal handlers.
Ok, thanks. I guess we have a
At 3:20 PM -0700 5/12/02, Marcel Moolenaar wrote:
On Sun, May 12, 2002 at 11:27:42PM +0200, Poul-Henning Kamp wrote:
It is not legal to recursively call malloc/free/realloc, and therefore
you should either protect all calls to malloc/free/realloc by blocking
signals or better: not call
On Sun, May 12, 2002 at 03:32:49PM -0700, Mark Peek wrote:
I've been maintaining tcsh. Can you file a PR and assign it to me?
I'll follow up with the tcsh owner to resolve the problem.
PR: bin/38006.
Backtrace and and libc hack to easily reproduce the condition included.
Thanks,
--
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
Poul-Henning Kamp wrote:
Please do not follow Terrys advice, unless and until you have
independent confirmation that his 10 year old knowledge is still
current.
Poul: I will say that advice is bad, but I will not provide advice
of my own, because it might be bad, too, and open me
On Sun, May 12, 2002 at 10:19:45PM -0700, Terry Lambert wrote:
Poul-Henning Kamp wrote:
Please do not follow Terrys advice, unless and until you have
independent confirmation that his 10 year old knowledge is still
current.
Poul: I will say that advice is bad, but I will not
Marcel Moolenaar wrote:
Here is what I think:
Your proximal problem is that your libraries are badly organized, and
therefore certain object files in them are not being pulled into the
linking process, because your order of operation on the objects is not
in dependency order, because
Marcel Moolenaar wrote:
On Sun, May 12, 2002 at 11:27:42PM +0200, Poul-Henning Kamp wrote:
It is not legal to recursively call malloc/free/realloc, and therefore
you should either protect all calls to malloc/free/realloc by blocking
signals or better: not call them in signal handlers.
31 matches
Mail list logo
