> > 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 solves a
> > whole lot of potential problems.
>
> It does cause problems when you keep the kernels for 8 different machines
> in one /usr/src.
You are obiviously k
On Thu, Aug 05, 1999 at 10:10:49AM +0930, Greg Lehey wrote:
> > So... IMHO, if we can fix this as well, it would be worth it for all
> > the people who get core dumps but didn't build debug kernels.
> > Do you disagree?
>
> I disagree that this should even be necessary. This kind of detail
> wa
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
> > 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
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
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
>> >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
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..?
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http
>> > One reason adding -g doesn't work at times is if the kernel is
>> > recompiled by a person with a different length username. vers.c
>> > is produced with a string which is a different length which screws
>> > up the offsets.
>> >
>> > Maybe newvers.sh should pad usernames to the legal max? M
Archie Cobbs writes:
> > One reason adding -g doesn't work at times is if the kernel is
> > recompiled by a person with a different length username. vers.c
> > is produced with a string which is a different length which screws
> > up the offsets.
> >
> > Maybe newvers.sh should pad usernames to t
David Malone writes:
> > > bde has reported that the code may not be identical when compiling for
> > > debugging. It should be, but for obscure reasons it doesn't quite
> > > make it.
> >
> > I'd be interested in seeing a pointer to those reasons, if you have one..
>
> One reason adding -g doe
On Tue, Aug 03, 1999 at 11:18:37AM -0700, Archie Cobbs wrote:
> Greg Lehey writes:
> > > * if you still have exactly the same source tree and config file,
> > > recompile the kernel with -g to obtain the version with debugging symbols
> >
> > bde has reported that the code may not be identical wh
Greg Lehey writes:
> > * if you still have exactly the same source tree and config file,
> > recompile the kernel with -g to obtain the version with debugging symbols
>
> bde has reported that the code may not be identical when compiling for
> debugging. It should be, but for obscure reasons it
On Sunday, 1 August 1999 at 23:33:07 +0200, Andrzej Bialecki wrote:
> On Sat, 31 Jul 1999, Jeroen Ruigrok/Asmodai wrote:
>
>>
>> No, just options DDB.
>> This bt was obtained after doing gdb -k kernel.0 vmcore.0
>> I still have the DDB trace on paper which I can type in if needed/wanted.
>>
>>> W
On Sat, 31 Jul 1999, Jeroen Ruigrok/Asmodai wrote:
>
> No, just options DDB.
> This bt was obtained after doing gdb -k kernel.0 vmcore.0
> I still have the DDB trace on paper which I can type in if needed/wanted.
>
> > What you do with the results depends a lot on what you find. On the
> > who
* Greg Lehey ([EMAIL PROTECTED]) [990731 03:50]:
> On Saturday, 31 July 1999 at 0:19:27 +0200, Jeroen Ruigrok/Asmodai wrote:
> > * Greg Lehey ([EMAIL PROTECTED]) [990730 11:23]:
> >> On Friday, 30 July 1999 at 8:45:32 +0200, Jeroen Ruigrok/Asmodai wrote:
> >> The first thing you should do with
On Saturday, 31 July 1999 at 0:19:27 +0200, Jeroen Ruigrok/Asmodai wrote:
> * Greg Lehey ([EMAIL PROTECTED]) [990730 11:23]:
>> On Friday, 30 July 1999 at 8:45:32 +0200, Jeroen Ruigrok/Asmodai wrote:
>
>>> I started a make world on my box last night and then proceeded to go to bed.
>>>
>>> When
* Greg Lehey ([EMAIL PROTECTED]) [990730 11:23]:
> On Friday, 30 July 1999 at 8:45:32 +0200, Jeroen Ruigrok/Asmodai wrote:
> > I started a make world on my box last night and then proceeded to go to bed.
> >
> > When I looked at my console this morning it had sprung into DDB because
> > of a pan
On Friday, 30 July 1999 at 8:45:32 +0200, Jeroen Ruigrok/Asmodai wrote:
> Hi,
>
> I started a make world on my box last night and then proceeded to go to bed.
>
> When I looked at my console this morning it had sprung into DDB because
> of a panic: ffs_alloccg: map corrupted.
>
> This panic occur
Hi,
I started a make world on my box last night and then proceeded to go to bed.
When I looked at my console this morning it had sprung into DDB because
of a panic: ffs_alloccg: map corrupted.
This panic occured on a box running pretty stable (at least panic less for
the last past 4-8 weeks).
23 matches
Mail list logo
