Subject: 2.2.5-rmk1

From: [email-masked]
Date: Thu, 08 Apr 1999 14:31:03 +0100

I had a quick play with this kernel.  It falls 
over fairly quickly with "crashme +2000.4 666 100 1:0:0".  The error message 
isn't especially illuminating; it appears that bad_mode is somehow getting 
called with bogus arguments.  I don't currently have any insight into the 
cause.

I can post the whole message if anybody thinks it will be useful.  It would 
involve lots of tedious manual copying which is why I haven't included it 
here. :-)

p.

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Russell King <[email-masked]>
Date: Thu, 8 Apr 1999 16:05:08 +0100 (BST)

> involve lots of tedious manual copying which is why I haven't included it 

Is there any more info?  Eg, what does crashme ... do, apart from the obvious,
in this particular circumstance?

--
Russell King ([email-masked])

---

From: James Craig <[email-masked]>
Date: Thu, 8 Apr 1999 17:01:35 +0100 (BST)

> in this particular circumstance?
Crashme is a OS stability checker.
It writes a random block of code and tries to execute it.
The idea is that th OS shouldn't fall over no matter what code you try to
make it run. It's worth noting that linux on a P2 falls over on crashme
after a few days - it's also a good way of finding CPU bugs.

--
James Craig <[email-masked]>
            <[email-masked]>

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sat, 17 Apr 1999 17:30:04 +0100 (BST)

Ok, after several runs of crashme, I think I've squashed Phil's bug...

Some advice for using crashme - use a serial connection to run crashme,
and run something like minicom with a decent amount of scroll-back.  When
a crash happens, find the previous invocation of crashme - it will give
you the random seed required to regenerate the code that caused the crash.

Anyway, stuff fixed in the up and coming 2.2.5-rmk5 patch:

1. vector exceptions were too noisy, and were being over-zealous about
   killing the task (rather than sending it a SEGV and letting it handle
   that).

2. bug in kernel_page_fault meant another kernel NULL dereference caused
   this routine to be called ad infinitum, causing stack overflow.

3. the bad mode handler called because the signal stack was corrupted,
   and the SEGV signal was blocked.  The signal stack registers are
   now forced to something sensible instead of being left in their
   corrupted state (namely forcing USER mode and SP to be word aligned).
   *** Note: this was a security hole ***

4. Infinite loop lockup when flush_icache_area is called with
    start = 0x......33, end = 0x7ffffff7
   flush_icache_area and cache_clean(_area) are now called with an
   address and size argument and are now guaranteed to terminate.

5. Expansion card IRQs on Acorn machines now work again.  These
   were unfortunately broken in previous 2.2 kernels (I must keep those
   hard drives dangling out the side of my RiscPC for testing this...)

Unfortunately, the FTP site is currently down, so I don't know when I'll
be able to make the patch available.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Sun, 18 Apr 1999 14:51:25 +0100

>Ok, after several runs of crashme, I think I've squashed Phil's bug...

Great, I'll test it out.

p.