[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] MiNTList

I'm trying. I'm attaching mail that did not get through.

AdamK

W dniu 30.09.2012 20:05, Rob M pisze:

Try sending it to
mint@lists.fishpool.fi <mailto:mint@lists.fishpool.fi>

Rob
Sent from my Droid Razr

On Sep 30, 2012 8:42 AM, "Jo Even Skarstein" <joska@online.no
<mailto:joska@online.no>> wrote:

    Hi,

    I got a mail from Adam Klobukowski, he has trouble with sending mail to
    the list from the address "adamklobukowski@gmail.com
    <mailto:adamklobukowski@gmail.com>". See below.

    Jo Even

    On Sun, 2012-09-30 at 10:01 +0200, Adam Kłobukowski wrote:
     > Hi
     >
     > I've recently sent post to the MiNTList, but I do not see it
    there (or
     > online archive) - it seems it did not get through.
     >
     > Can you please raise this issues on the MiNTList?
     >
     > I was posting from this email address.
     >
     > Adam Klobukowski
     >
     >
--- Begin Message --- 
W dniu 29.09.2012 10:56, Lars Schmidbauer pisze:

Hi,

i get this "invalid invalid S?_MAGIC!" error on Falcon/CT6*/CTPCI at shutdown, too.
MP is off here, error occures randomly (most times not, sometimes while shutdown
of any partitions (FAT, VFAT or ext2)). A few times this error occured when starting
a program (QED or other), in this case errormessage was started with "pid** (QED):" or
"pid** (DESKTOP):"
It does not happen very often, but most times at shutdown.


I've seen invalid S?_MAGIC errors long time ago.

It means that kernel memory (kernel - not user) has been corrupted.

Longer explanation:
FreeMiNT memory allocation algos distinguish three types of allocations, depending on allocation size. This allows much better handling of memory fragmentation. In kernel structures, allocation type is described by few constants (from kmemory.c): 

# define MR_MAGIC       (0x5330)
# define S1_MAGIC       (0x5331)
# define S2_MAGIC       (0x5332)
# define LB_MAGIC       (0x5333)
# define ST_MAGIC       (0x5334)
So, if there is an other value there - something has overwritten it. As a result, kernel memory structures cannot be trusted, and that is BAD, VERY BAD. 

For more explanation, look in kmemory.c

How can we find whats corrupting it?
First, we should expand error message to show what value there is - it might be a clue.
Second, we could ask Aranaym developers for special debug Aranym to watch for us where that values get changed. This may show which app is misbehaving. 

AdamK

--- End Message ---