:No sooner received than done
:
:(kgdb) frame 18
:#18 0xc01ef2d6 in mmap (p=0xc5e49020, uap=0xc5f45f80) at ../../vm/vm_mmap.c:330
:330 error = vm_mmap(&p->p_vmspace->vm_map, &addr, size, prot, maxprot,
:(kgdb) print *p
:$2 = {p_procq = {tqe_next = 0xc0290ed0, tqe_prev = 0x0}, p_li
> Could you print out *p and *uap in frame 18?
>
> frame 18
> print *p
> print *uap
>
> Also, do:
>
> ps -axl -N /sys/compile/bleep/kernel.debug -M /var/crash/vmcore.2
>
> This is very odd. There is no way it should be looping in supervisor
> mode in tha
In message <[EMAIL PROTECTED]> Peter Jeremy writes:
: Someone with some free time on their hands might like to check thru
: the egcs code to see if enabling debug can affect the code generation.
: A quick check suggests that the relevant globals are write_symbols,
: use_gnu_debug_info_extensions a
Could you print out *p and *uap in frame 18?
frame 18
print *p
print *uap
Also, do:
ps -axl -N /sys/compile/bleep/kernel.debug -M /var/crash/vmcore.2
This is very odd. There is no way it should be looping in supervisor
mode in that call chain.
> > I disagree that this should even be necessary. This kind of detail
> > was exactly the reason why I put the short-lived default debug kernel
> > into config. There aren't too many systems any more that don't have
> > an additional 30 MB for the time it takes to build the kernel, and it
> > s
On my home network, I make world on one machine and install it (from an NFS
mounted directory) on another. Some time ago (I've griped about this before -
the problem's been around for a while) it started to occasionally hang just
after or during installing libc.so.3. It will then hang solidly -
Greg Lehey writes:
> >> The only one I can find now is naming the debugging kernel with a name
> >> of different length. This causes different string lengths in config.c
> >> and vers.c. I once thought I saw a problem related to linker sets, but
> >> I was probably mistaken.
> >
> > So... IMHO,
On Wednesday, 4 August 1999 at 9:12:43 -0700, Archie Cobbs wrote:
> Bruce Evans writes:
> Any objections to the patch below?
Yes. It bloats the kernel and only fixed one cause of the problem.
>>>
>>> What are the others..?
>>
>> The only one I can find now is naming the debugging
Peter Jeremy writes:
> >>> Yes. It bloats the kernel and only fixed one cause of the problem.
> >>
> >>What are the others..?
> >
> >The only one I can find now is naming the debugging kernel with a name
> >of different length.
>
> Also, if your kernel was previously version 9 (or 99 or 999 or .
Bruce Evans <[EMAIL PROTECTED]> wrote:
>>> >Any objections to the patch below?
>>>
>>> Yes. It bloats the kernel and only fixed one cause of the problem.
>>
>>What are the others..?
>
>The only one I can find now is naming the debugging kernel with a name
>of different length.
Also, if your ker
[Reply-to set to -chat]
On Tue, Aug 03, 1999 at 08:22:55PM +0200, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Nik Clayton writes:
> >Just for completeness;
>
> Yeah, sorry for leaving you gang out , but I didn't want to make
> it too long, the important thing was to get the three
Bruce Evans writes:
> >> >Any objections to the patch below?
> >>
> >> Yes. It bloats the kernel and only fixed one cause of the problem.
> >
> >What are the others..?
>
> The only one I can find now is naming the debugging kernel with a name
> of different length. This causes different string
Yip, it has been breaking "make release" here the past few nights.
John
--
John Hay -- [EMAIL PROTECTED]
> Hi,
>
>I've noticed the following the last few days... Not a big problem, but
> it eventually needs some attention...
>
> Thanks,
> John
>
> rm -f /usr/local/share/lynx_help/help_f
Hi,
I've noticed the following the last few days... Not a big problem, but
it eventually needs some attention...
Thanks,
John
rm -f /usr/local/share/lynx_help/help_files.sed
Updating /usr/local/etc/lynx.cfg
/bin/sh -c 'if test -f /usr/local/etc/lynx.cfg ; then mv /usr/local/etc/lynx.cfg
/
Hey all, I purchased a Tekram DC-390U2W scsi controller to use with a
FreeBSD server of mine. It uses the NCR 53c141 (and 53c895?) chipset(s). I
see that ncr.c supports the NCR 53c8xx family of chipsets..
which the controller is seen as having a 53c895, which only supports
40Mb/sec operation(?)
>> >Any objections to the patch below?
>>
>> Yes. It bloats the kernel and only fixed one cause of the problem.
>
>What are the others..?
The only one I can find now is naming the debugging kernel with a name
of different length. This causes different string lengths in config.c
and vers.c. I
16 matches
Mail list logo
