I know from hard, sad experience that the normal Linux
kernel (at least 2.2.x and I believe 2.4.x too) is able to
deal with kernel segfaults easily. It declares a segfault
and "terminates" the current process. If that was part of
the initialization phase of the module, then it's stuck
until the next reboot (barring heroic measures that involve
plausibly fatal kernel table tinkering; a reboot is much
easier) and if it was in response to a user-task's call
(read/write/open/close/ioctl/...) then the user-task is
terminated (if you're maintaining connection counts, you're
out of luck because there's no notification of that and you
can't unload your module because the count says it's still
in use).
That's what the normal Linux kernel -- even with RTLinux
patches -- does when you're in the kernel and not in
real-time mode. When the incident I described occurred I
had turned interrupts off with
rtl_no_interrupts( saveit );
and I'm not sure if that would surpress a hardware
interrupt from the segfault itself. If so, I can see why
the hardware would hang: The CPU has raised the SEGFAULT
interrupt and is waiting for it to be handled but it can't
because interrupts are disabled. Anyway, that's my guess
as answering my own question.
Norm
----- Original Message -----
From: Calin A. Culianu <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: rtlinux <[EMAIL PROTECTED]>
Sent: Friday, October 12, 2001 12:10 PM
Subject: Re: [rtl] Can anyone explain why this happened?
>
> Well, in kernel mode there really isn't any memory
protection, so chances
> are it wasn't a 'segfault' per se, but rather a page
fault. I am willing
> to bet that the page you tried to access wasn't in
physical memory at the
> time and maybe the kernel's swapper tried to get it off
the hard disk but
> got hung due to the interrupt characteristics of the
currently running
> (realtime) thread. This is, however just a guess. I
wish I were more
> familiar with kernel internals (I am getting there!) to
say for sure.. but
> my above theory seems plausible at least..... :)
>
> However, you raise an interesting issue: Anyone know
offhand how
> intelligent the kernel is about detecting when a kernel
thread tries to
> access memory it has no business touching? I am assuming
the only rule is
> that you can't read memory location '0', but other than
that, anything
> else goes... is that so?
>
> -Calin
>
>
>
> On Thu, 11 Oct 2001, Norm Dresner
> wrote:
>
> > Inside a function called by a real-time task, I coded a
> > "simple" routine to read the contents from a port.
Because
> > I wanted not to even try to read from the address if
the
> > corresponding board wasn't there, I put an if-statement
in
> > front of the i/o read.
> >
> > The code I wanted to write was:
> > ...
> > if ( BoardOK[ boardno ] )
> > return inw( basePort );
> > else
> > return( -1 );
> >
> > But instead I screwed up and wrote
> > ...
> > if( BoardOK[ basePort ] ) // basePort ~ 0x300
while
> > boardno ~ 1-4
> > return inw( basePort );
> > else
> > return( -1 );
> >
> > And the computer would *hang* every time the function
was
> > called. I'm obviously addressing memory beyond the end
of
> > the array and there's probably not enough static data
in
> > the driver to allow addressing 0x300 * sizeof( int )
beyond
> > the end of it without running out of the address range
> > assigned to my driver's data segment either. [I know
that
> > the hang in this routine and not after it returned data
> > because I had already commented out that code in an
attempt
> > to isolate the problem.]
> >
> > If I was addressing beyond the end of the virtual
address
> > space for the kernel, I'd expect to get a segfault, not
a
> > hang. And if there was memory there, why didn't I just
> > read a value instead of hanging so solidly that only
the
> > reset or power switches would have any effect?
> >
> > I don't know how rtlinux handles a sigfault so I'm
hoping
> > that someone else does and can explain why this
happened.
> >
> > TIA
> > Norm
> >
> >
> >
> >
> > -- [rtl] ---
> > To unsubscribe:
> > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> > echo "unsubscribe rtl <Your_email>" | mail
[EMAIL PROTECTED]
> > --
> > For more information on Real-Time Linux see:
> > http://www.rtlinux.org/
> >
>
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl <Your_email>" | mail
[EMAIL PROTECTED]
> --
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/
>
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/
