success 2.4.0-test8 with latest bk

success 2.4.0-test8 with latest bk

[Andreas Tobler]

Hi Paul & others,

I want to express my thanks to you including Geert's pci-res patch, now
I'm able again to run the latest devel tree from bk on my ancient 7200
with it's 2940UW.
It is running since three h.

Thx

Andreas

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: success 2.4.0-test8 with latest bk

[Martin Costabel]

Andreas Tobler wrote:
>
> Hi Paul & others,
>
> I want to express my thanks to you including Geert's pci-res patch, now
> I'm able again to run the latest devel tree from bk on my ancient 7200
> with it's 2940UW.
> It is running since three h.

You are lucky. For me it stops booting after the "freeing unused kernel
memory" line. The one from 2 days ago had 2 days uptime.

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: success 2.4.0-test8 with latest bk

[Geert Uytterhoeven]

On Tue, 12 Sep 2000, Martin Costabel wrote:
> Andreas Tobler wrote:
> > I want to express my thanks to you including Geert's pci-res patch, now
> > I'm able again to run the latest devel tree from bk on my ancient 7200
> > with it's 2940UW.
> > It is running since three h.
>
> You are lucky. For me it stops booting after the "freeing unused kernel
> memory" line. The one from 2 days ago had 2 days uptime.

Usually this means that some function/data is marked __init while it must not.
Quick verification: #undef __init / #define __init etc.

Just wondering: wouldn't it be possible to write some tool to find such bugs?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: success 2.4.0-test8 with latest bk

[Benjamin Herrenschmidt]

>Usually this means that some function/data is marked __init while it
must not.
>Quick verification: #undef __init / #define __init etc.
>
>Just wondering: wouldn't it be possible to write some tool to find such bugs?

Yup, we could probably, instead of freeing the __init section, mark it
unaccessible with the MMU. This would put us in xmon as soon as we try to
access one of these. I'm not sure if this can be done without disabling
the BAT mapping of the kernel, however. Well, of course, that would be a
DEBUG option, not a feature of the "standard" kernel.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: success 2.4.0-test8 with latest bk

[Martin Costabel]

Geert Uytterhoeven wrote:
>
> On Tue, 12 Sep 2000, Martin Costabel wrote:
> > Andreas Tobler wrote:
> > > I want to express my thanks to you including Geert's pci-res patch, now
> > > I'm able again to run the latest devel tree from bk on my ancient 7200
> > > with it's 2940UW.
> > > It is running since three h.
> >
> > You are lucky. For me it stops booting after the "freeing unused kernel
> > memory" line. The one from 2 days ago had 2 days uptime.
>
> Usually this means that some function/data is marked __init while it must not.
> Quick verification: #undef __init / #define __init etc.
>
> Just wondering: wouldn't it be possible to write some tool to find such bugs?

Update: After a recompilation with today's updates, the latest bk kernel
boots again for me.

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: success 2.4.0-test8 with latest bk

[Benjamin Herrenschmidt]

>> > You are lucky. For me it stops booting after the "freeing unused kernel
>> > memory" line. The one from 2 days ago had 2 days uptime.
>>
>> Usually this means that some function/data is marked __init while it
>must not.
>> Quick verification: #undef __init / #define __init etc.
>>
>> Just wondering: wouldn't it be possible to write some tool to find such
>bugs?
>
>Update: After a recompilation with today's updates, the latest bk kernel
>boots again for me.

That's not the first time I notice this strange behaviour. I meant, this
happened to me randomly with various bk kernels for monthes. The problem
usually disappeared by itself after either recompiling the entire kernel,
or changing a few unrelated lines of code and then reompiling. That's
weird, I really don't know what can be causing that.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: success 2.4.0-test8 with latest bk

[Michel Dänzer]

Benjamin Herrenschmidt wrote:
>
> >> > You are lucky. For me it stops booting after the "freeing unused kernel
> >> > memory" line. The one from 2 days ago had 2 days uptime.
> >>
> >> Usually this means that some function/data is marked __init while it
> >must not.
> >> Quick verification: #undef __init / #define __init etc.
> >>
> >> Just wondering: wouldn't it be possible to write some tool to find such
> >bugs?
> >
> >Update: After a recompilation with today's updates, the latest bk kernel
> >boots again for me.
>
> That's not the first time I notice this strange behaviour. I meant, this
> happened to me randomly with various bk kernels for monthes. The problem
> usually disappeared by itself after either recompiling the entire kernel,
> or changing a few unrelated lines of code and then reompiling. That's
> weird, I really don't know what can be causing that.

Broken dependencies?


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: success 2.4.0-test8 with latest bk

[Michel Lanners]

On  13 Sep, this message from Benjamin Herrenschmidt echoed through cyberspace:
>>Update: After a recompilation with today's updates, the latest bk kernel
>>boots again for me.
>
> That's not the first time I notice this strange behaviour. I meant, this
> happened to me randomly with various bk kernels for monthes. The problem
> usually disappeared by itself after either recompiling the entire kernel,
> or changing a few unrelated lines of code and then reompiling. That's
> weird, I really don't know what can be causing that.

Same for me, except that for a few weeks now I'm basically stuck in a
non-booting mood. One out of roughly 20 tries boots indeed; all the
other stop in various places in init/main.c. Not even going into xmon...

Since it doesn't seem to be a reproducible crash in one specific place,
its rather hard to isolate the problem. I feel like chasing ghosts...
Anybody got Ghostbusters' phone?

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: success 2.4.0-test8 with latest bk

[Martin Costabel]

Michel Lanners wrote:
>
> On  13 Sep, this message from Benjamin Herrenschmidt echoed through cyberspace:

> > That's not the first time I notice this strange behaviour. I meant, this

> Same for me, except that for a few weeks now I'm basically stuck in a
> non-booting mood. One out of roughly 20 tries boots indeed; all the
> other stop in various places in init/main.c. Not even going into xmon...
>
> Since it doesn't seem to be a reproducible crash in one specific place,
> its rather hard to isolate the problem. I feel like chasing ghosts...
> Anybody got Ghostbusters' phone?

Actually, it (latest bk-2.4.0-test) is now pretty stable again on my old
6400(*). The only problems are those that seem to plague everybody:

I had to apply Al Viro's remaining fix for
fs/buffers.c:block_truncate_page() ("kernel BUG at ll_rw_blk.c:711"),
otherwise I was dropped into xmon all the time. Linus seems to hide
under a ton of brown paper bags.

There are now processes that don't listen to SIGHUP or to Ctrl-C (bk
sccstool, for example) and get transformed into zombies.

(*) I'll check your valkyriefb patch as soon as I can find it, so it
might not remain as stable :-)

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: success 2.4.0-test8 with latest bk

[Takashi Oe]

On Wed, 13 Sep 2000, Michel Lanners wrote:

> On  13 Sep, this message from Benjamin Herrenschmidt echoed through cyberspace:
> >>Update: After a recompilation with today's updates, the latest bk kernel
> >>boots again for me.
> >
> > That's not the first time I notice this strange behaviour. I meant, this
> > happened to me randomly with various bk kernels for monthes. The problem
> > usually disappeared by itself after either recompiling the entire kernel,
> > or changing a few unrelated lines of code and then reompiling. That's
> > weird, I really don't know what can be causing that.
>
> Same for me, except that for a few weeks now I'm basically stuck in a
> non-booting mood. One out of roughly 20 tries boots indeed; all the
> other stop in various places in init/main.c. Not even going into xmon...
>
> Since it doesn't seem to be a reproducible crash in one specific place,
> its rather hard to isolate the problem. I feel like chasing ghosts...
> Anybody got Ghostbusters' phone?

Could you try the following change for arch/ppc/mm/init.c?


static void __init
clear_hash_table(void)
{
	unsigned char *adr = (unsigned char *)Hash;
	unsigned long i = Hash_size;

	for (; i > 0; --i)
		*adr++ = 0;
}

/*
 * Initialize the hash table and patch the instructions in head.S.
 */
static void __init hash_init(void)
{
	int Hash_bits, mb, mb2;
	....
	....
	if ( ppc_md.progress ) ppc_md.progress("hash:find piece", 0x322);
	/* Find some memory for the hash table. */
	if ( Hash_size ) {
		Hash = mem_pieces_find(Hash_size, Hash_size);
		clear_hash_table();
	} else
		Hash = 0;
	....
	....
}


I was seeing the random freezes until I made this change.  What it does is
to zero out the hash table *before* anybody tries to use it.  I think that
is at least sensible thing to do.  For your machine, you can probably
replace "clear_hash_table()" by memset(Hash,0,Hash_size) or something and
be done with it.  The helper function is to avoid taking exception on
NuBus machines this early in boot process.

Actually, I've sent a message to this list months ago asking why the hash
table is never initialized but no one seemed to care at the time.
Perhaps, this time, someone would care to comment?  I still fail to see
why it's not necessary anyhow.

Martin's boot problem is certainly something else since his machine (603e)
doesn't use Hash.

For me, 2.4.0-test8 + fs/buffer.c fix has been very stable.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: success 2.4.0-test8 with latest bk

[Paul Mackerras]

Takashi Oe writes:

> Could you try the following change for arch/ppc/mm/init.c?
[snip]
> 		Hash = mem_pieces_find(Hash_size, Hash_size);
> 		clear_hash_table();

Huh?  There is a __clear_user(Hash, Hash_size) call in there but it's
commented out, which I don't understand at all.  Certainly the hash
table needs to be cleared.  Using cacheable_memzero would probably be
the fastest way to do it.

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: success 2.4.0-test8 with latest bk

[Takashi Oe]

On Thu, 14 Sep 2000, Paul Mackerras wrote:

> Takashi Oe writes:
>
> > Could you try the following change for arch/ppc/mm/init.c?
> [snip]
> > 		Hash = mem_pieces_find(Hash_size, Hash_size);
> > 		clear_hash_table();
>
> Huh?  There is a __clear_user(Hash, Hash_size) call in there but it's
> commented out, which I don't understand at all.  Certainly the hash
> table needs to be cleared.

Yeah, that's what I thought when I first saw the code a few months ago.

>                             Using cacheable_memzero would probably be
> the fastest way to do it.

__clear_user() works but I can't use cacheable_memzero() since frame
buffer memory resides on the same memory block.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: success 2.4.0-test8 with latest bk

[Troy Benjegerdes]

I got curious, and I tracked down the commented out
__clear_user(Hash, hash_size)

to version 1.10 of init.c

arch/ppc/mm/init.c
  1.10 00/02/04 13:20:23 cort@medea.fsmlabs.com +15 -2
  Changes to fix PPC64 MM (short term fix) and protect the system
  map memory from being written over.

Cort, any chance you happen to recall why that was needed

>
> On Thu, 14 Sep 2000, Paul Mackerras wrote:
>
> > Takashi Oe writes:
> >
> > > Could you try the following change for arch/ppc/mm/init.c?
> > [snip]
> > > 		Hash = mem_pieces_find(Hash_size, Hash_size);
> > > 		clear_hash_table();
> >
> > Huh?  There is a __clear_user(Hash, Hash_size) call in there but it's
> > commented out, which I don't understand at all.  Certainly the hash
> > table needs to be cleared.
>
> Yeah, that's what I thought when I first saw the code a few months ago.
>
> >                             Using cacheable_memzero would probably be
> > the fastest way to do it.
>
> __clear_user() works but I can't use cacheable_memzero() since frame
> buffer memory resides on the same memory block.
>
>
> Takashi Oe
>
>
>
>

--
--------------------------------------------------------------------------
Troy Benjegerdes                'da hozer'                hozer@drgw.net


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: success 2.4.0-test8 with latest bk

[Iain Sandoe]

On  Wed, Sep 13, 2000, Michel Dänzer wrote:
> Benjamin Herrenschmidt wrote:
>>
>> >> > You are lucky. For me it stops booting after the "freeing unused kernel
>> >> > memory" line. The one from 2 days ago had 2 days uptime.
>> >>
>> >> Usually this means that some function/data is marked __init while it
>> >must not.
>> >> Quick verification: #undef __init / #define __init etc.
>> >>
>> >> Just wondering: wouldn't it be possible to write some tool to find such
>> >bugs?
>> >
>> >Update: After a recompilation with today's updates, the latest bk kernel
>> >boots again for me.
>>
>> That's not the first time I notice this strange behaviour. I meant, this
>> happened to me randomly with various bk kernels for monthes. The problem
>> usually disappeared by itself after either recompiling the entire kernel,
>> or changing a few unrelated lines of code and then reompiling. That's
>> weird, I really don't know what can be causing that.
>
> Broken dependencies?

un-init vars? there's still quite a few warning messages fly by on
compile...

=====

from a mrproper of rsync-ed bk-devel (13:00 BST today).

boots OK (with BootX) on:

G3/beige
Lombard
9600/233

All three platforms show the weird coloured patterning on graphics chip
probe (I guess) - *even* the 9600 - which is IMSTT-based.  I have rage128
support built in.

2.4.0-t8 appears to be 'slower and choppier' than 2.2.17p20 (rather
subjective, I know).

The 9600 leaves the mac hardware cursor on the screen - which doesn't happen
with 2.2.17 (who deals with that?)...

BTW: two other questions:

1/ is devfs regarded as OK now (I built it in by mistake).
2/ has the fs-trashing problem been resolved?

I'd like to get back to doing 2.4.0 versions of the bits I'm working on -
but have only a little time for watching fsck ;-)

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/