public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Zdenek Kabelac <kabi@fi.muni.cz>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: 2.4.x SMP blamed for Xfree 4.0 crashes
Date: Tue, 13 Feb 2001 14:38:35 GMT	[thread overview]
Message-ID: <3A8946EB.A053C868@fi.muni.cz> (raw)
In-Reply-To: <E14SfKk-0001kl-00@the-village.bc.nu>

Alan Cox wrote:
 > Yeah I've seen this claim repeatedly. XFree 4.0.2 crashes for me in
similar
> ways on 3dfx and matrox cards and it happens with 2.2 kernels as well. What
> makes me suspicious its XFree triggered is that there isnt really anything
> XFree does that would trigger mm bugs on x86 platforms. It isnt threaded, it
> doesnt make extensive threaded use of mmap. But of course it does touch
> hardware directly, paticularly the AGPgart. That might be an obvious first
> candidate but having looked at it I see no problems.
> 
> > Anyone looking into this?
> 
> I believe it to be Xfree or glibc problems.  So I'm not. Since I can't get
> XFree 4 stable on 2.2 I dont have a useful setup to study this.

I'll try to repeat my problem here in the hope someone will notice this
and will help me.

The problem is with the usage of RTL & XFree86 4.0
In the old days of Xfree3.3.6 I've no problems at all. After upgrading
to XFree4.0
this problem has appeared:

RTL scheduler calls my module code and this randomly segfaults (usually
its in
spinlock and trace shows that it was looping in page_fault)
(this happen  with any rtl module)

This problem appears only IF my module has been loaded AFTER mga.o drm
kernel driver.
When I'm not using accelerated XFree (without kernel module) or I'm
preloading
my module before mga.o  (it even help to stop xfree, remove mga, load my
driver,
restart xfree) everything runs just fine.

As drm code is cooperating with AGP and DMA and I'm not skilled enough
to know about these
memory mapping problems I've no idea how could happen that my kernel
module code
is not present in the specified memory. As I've noticed drm contains
some code
for handling page fault exception however for RTL task its "a must" that
code has to
be present in memory.

I'm having couple of questins - is it correct when I assume than kernel
memory
including the memory used for kernel module drivers is unswapable and
will
always stay in the same physical place ?

Should I use PG_reserver or PG_locked for the pages I want that MMU
would not touch ?
Is it useful to increment counter in mem_map_t as it is done in the drm
driver ?

thanks

bye

-- 
             There are three types of people in the world:
               those who can count, and those who can't.
  Zdenek Kabelac  http://i.am/kabi/ kabi@i.am {debian.org; fi.muni.cz}


  parent reply	other threads:[~2001-02-13 14:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-13 13:05 2.4.x SMP blamed for Xfree 4.0 crashes Tony Gale
2001-02-13 13:17 ` Alan Cox
2001-02-13 14:11   ` Tony Gale
2001-02-13 14:38   ` Zdenek Kabelac [this message]
2001-02-13 19:55   ` Rogerio Brito
2001-02-13 20:17     ` Aaron Dewell
2001-02-13 13:20 ` Richard B. Johnson
2001-02-13 17:01   ` David Howells
2001-02-13 14:43 ` David Woodhouse
2001-02-13 15:08   ` Tony Gale
2001-02-13 15:36 ` Pete Toscano
     [not found] <20010214085015.A29267@linuxcare.com>
     [not found] ` <Pine.GSO.4.10.10102131503190.3929-100000@spruce.woods.net>
2001-02-13 22:06   ` Anton Blanchard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A8946EB.A053C868@fi.muni.cz \
    --to=kabi@fi.muni.cz \
    --cc=alan@lxorguk.ukuu.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox