13 messages, 10 authors, 2000-09-17 · open the first message on its own page
From: Andreas Tobler <hidden>
Date: 2000-09-12 20:49:25
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/
From: Martin Costabel <hidden>
Date: 2000-09-12 21:11:52
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/
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2000-09-12 22:14:46
On Tue, 12 Sep 2000, Martin Costabel wrote:
Andreas Tobler wrote:quoted
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/
From: Benjamin Herrenschmidt <hidden>
Date: 2000-09-13 12:45:16
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/
From: Martin Costabel <hidden>
Date: 2000-09-13 12:46:54
Geert Uytterhoeven wrote:
On Tue, 12 Sep 2000, Martin Costabel wrote:quoted
Andreas Tobler wrote:quoted
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/
From: Benjamin Herrenschmidt <hidden>
Date: 2000-09-13 12:47:00
quoted
quoted
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 itmust not.quoted
Quick verification: #undef __init / #define __init etc. Just wondering: wouldn't it be possible to write some tool to find suchbugs? 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/
From: Michel D�nzer <hidden>
Date: 2000-09-13 12:58:04
Benjamin Herrenschmidt wrote:
quoted
quoted
quoted
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 itmust not.quoted
Quick verification: #undef __init / #define __init etc. Just wondering: wouldn't it be possible to write some tool to find suchbugs? 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/
From: Michel Lanners <hidden>
Date: 2000-09-13 20:25:15
On 13 Sep, this message from Benjamin Herrenschmidt echoed through cyberspace:
quoted
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/
From: Martin Costabel <hidden>
Date: 2000-09-13 21:20:42
Michel Lanners wrote:
On 13 Sep, this message from Benjamin Herrenschmidt echoed through cyberspace:
quoted
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/
From: Takashi Oe <hidden>
Date: 2000-09-14 01:13:01
On Wed, 13 Sep 2000, Michel Lanners wrote:
On 13 Sep, this message from Benjamin Herrenschmidt echoed through cyberspace:quoted
quoted
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/
From: Paul Mackerras <hidden>
Date: 2000-09-14 03:38:08
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/
From: Takashi Oe <hidden>
Date: 2000-09-14 06:50:04
On Thu, 14 Sep 2000, Paul Mackerras wrote:
Takashi Oe writes:quoted
Could you try the following change for arch/ppc/mm/init.c?[snip]quoted
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/
From: Troy Benjegerdes <hidden>
Date: 2000-09-17 05:32:08
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:quoted
Takashi Oe writes:quoted
Could you try the following change for arch/ppc/mm/init.c?[snip]quoted
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.quoted
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/