All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Schlichter <schlicht@uni-mannheim.de>
To: James Simmons <jsimmons@infradead.org>
Cc: Helge Hafting <helgehaf@aitel.hist.no>,
	Andrew Morton <akpm@osdl.org>, <Valdis.Kletnieks@vt.edu>,
	<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>
Subject: Re: 2.6.0-test8-mm1
Date: Wed, 22 Oct 2003 00:53:08 +0200	[thread overview]
Message-ID: <200310220053.13547.schlicht@uni-mannheim.de> (raw)
In-Reply-To: <Pine.LNX.4.44.0310212141290.32738-100000@phoenix.infradead.org>

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

On Tuesday 21 October 2003 22:42, James Simmons wrote:
> > > This patch was fine.  2.6.0-test8 with this patch booted and
> > > looked no different from plain 2.6.0-test8.  I am using it for
> > > writing this.  The problems must be in mm1 somehow.
> > >
> > > Helge Hafting
>
> Yeah!!!
>
> > Well here I've got same problems for -test8 + fbdev-patch as with
> > -test8-mm1. I've compiled the kernel with most DEBUG_* options enabled
> > (all but DEBUG_INFO and KGDB) and see the same cursor and image
> > corruption as with -mm1 and the same options enabled.
> >
> > Should I try compiling this kernel without the DEBUG_* options and watch
> > if I get the invalidate_list Oops again?
>
> Yes. I'm using vesafb and I have no problems. I liek to see what the
> problem really is.

OK, without any of the DEBUG_* options enabled the kernel SEEMS to work with 
no problems. But I don't know how I can assure there actually is no memory 
corruption...

For me the big question stays why enabling the DEBUG_* options results in a 
corrupt cursor and the false dots on the top of each row... (with both 
kernels)

And, of course, why enabling vesafb in -mm1 leads to memory corruption. (as 
Vladis already mentioned, the same binary works if vesafb is not enabled via 
the 'vga=xxx' boot option).

Regards
   Thomas

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Schlichter <schlicht@uni-mannheim.de>
To: James Simmons <jsimmons@infradead.org>
Cc: Helge Hafting <helgehaf@aitel.hist.no>,
	Andrew Morton <akpm@osdl.org>,
	Valdis.Kletnieks@vt.edu, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: 2.6.0-test8-mm1
Date: Wed, 22 Oct 2003 00:53:08 +0200	[thread overview]
Message-ID: <200310220053.13547.schlicht@uni-mannheim.de> (raw)
In-Reply-To: <Pine.LNX.4.44.0310212141290.32738-100000@phoenix.infradead.org>

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

On Tuesday 21 October 2003 22:42, James Simmons wrote:
> > > This patch was fine.  2.6.0-test8 with this patch booted and
> > > looked no different from plain 2.6.0-test8.  I am using it for
> > > writing this.  The problems must be in mm1 somehow.
> > >
> > > Helge Hafting
>
> Yeah!!!
>
> > Well here I've got same problems for -test8 + fbdev-patch as with
> > -test8-mm1. I've compiled the kernel with most DEBUG_* options enabled
> > (all but DEBUG_INFO and KGDB) and see the same cursor and image
> > corruption as with -mm1 and the same options enabled.
> >
> > Should I try compiling this kernel without the DEBUG_* options and watch
> > if I get the invalidate_list Oops again?
>
> Yes. I'm using vesafb and I have no problems. I liek to see what the
> problem really is.

OK, without any of the DEBUG_* options enabled the kernel SEEMS to work with 
no problems. But I don't know how I can assure there actually is no memory 
corruption...

For me the big question stays why enabling the DEBUG_* options results in a 
corrupt cursor and the false dots on the top of each row... (with both 
kernels)

And, of course, why enabling vesafb in -mm1 leads to memory corruption. (as 
Vladis already mentioned, the same binary works if vesafb is not enabled via 
the 'vga=xxx' boot option).

Regards
   Thomas

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2003-10-21 22:53 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-20  9:05 2.6.0-test8-mm1 Andrew Morton
2003-10-20  9:05 ` 2.6.0-test8-mm1 Andrew Morton
2003-10-20  9:40 ` 2.6.0-test8-mm1 Kirill Korotaev
2003-10-20  9:49   ` 2.6.0-test8-mm1 Andrew Morton
2003-10-20 11:05     ` 2.6.0-test8-mm1 Peter Lieverdink
2003-10-20 18:49       ` 2.6.0-test8-mm1 Helge Hafting
2003-10-21 11:06         ` 2.6.0-test8-mm1 [matroxfb not working] Jurriaan
2003-10-20 11:18 ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-20 13:22 ` 2.6.0-test8-mm1 Jonathan Brown
2003-10-20 15:00   ` 2.6.0-test8-mm1 Antonio Dolcetta
2003-10-20 16:32     ` 2.6.0-test8-mm1 Jonathan Brown
2003-10-21  7:28       ` 2.6.0-test8-mm1 Antonio Dolcetta
2003-10-20 15:32 ` 2.6.0-test8-mm1 John Cherry
2003-10-20 15:32   ` 2.6.0-test8-mm1 John Cherry
2003-10-20 16:11 ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-20 21:48   ` 2.6.0-test8-mm1 Andrew Morton
2003-10-20 21:48     ` 2.6.0-test8-mm1 Andrew Morton
2003-10-20 22:01     ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-20 22:17       ` 2.6.0-test8-mm1 Andrew Morton
2003-10-20 22:17         ` 2.6.0-test8-mm1 Andrew Morton
2003-10-20 22:30         ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-21  0:43           ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-21  0:14       ` 2.6.0-test8-mm1 Valdis.Kletnieks
2003-10-21  0:27         ` 2.6.0-test8-mm1 Andrew Morton
2003-10-21  0:27           ` 2.6.0-test8-mm1 Andrew Morton
2003-10-21  0:46           ` 2.6.0-test8-mm1 Valdis.Kletnieks
2003-10-21  1:56             ` 2.6.0-test8-mm1 Andrew Morton
2003-10-21  1:56               ` 2.6.0-test8-mm1 Andrew Morton
2003-10-21  2:54               ` 2.6.0-test8-mm1 Valdis.Kletnieks
2003-10-21  3:49               ` 2.6.0-test8-mm1 Jeremy Fitzhardinge
2003-10-21  3:49                 ` 2.6.0-test8-mm1 Jeremy Fitzhardinge
2003-10-21  8:39               ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-21 17:47               ` 2.6.0-test8-mm1 James Simmons
2003-10-21 17:47                 ` 2.6.0-test8-mm1 James Simmons
2003-10-21 18:53                 ` 2.6.0-test8-mm1 Jurriaan
2003-10-22 17:02                   ` 2.6.0-test8-mm1 James Simmons
2003-10-21 20:23                 ` 2.6.0-test8-mm1 Helge Hafting
2003-10-21 20:23                   ` 2.6.0-test8-mm1 Helge Hafting
2003-10-21 20:36                   ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-21 20:42                     ` 2.6.0-test8-mm1 James Simmons
2003-10-21 20:42                       ` 2.6.0-test8-mm1 James Simmons
2003-10-21 21:05                       ` 2.6.0-test8-mm1 Thomas Giese
2003-10-22 17:08                         ` 2.6.0-test8-mm1 James Simmons
2003-10-21 22:53                       ` Thomas Schlichter [this message]
2003-10-21 22:53                         ` 2.6.0-test8-mm1 Thomas Schlichter
2003-10-21 23:27                         ` 2.6.0-test8-mm1 Robert Love
2003-10-21 23:27                           ` 2.6.0-test8-mm1 Robert Love
2003-10-22  2:46                           ` 2.6.0-test8-mm1 Valdis.Kletnieks
2003-10-21 20:55                 ` 2.6.0-test8-mm1 Panagiotis Papadakos
2003-10-22 17:12                   ` 2.6.0-test8-mm1 James Simmons
2003-10-20 19:21 ` [BUG] 2.6.0-test8-mm1 Ramón Rey Vicente
2003-10-20 20:10   ` Andrew Morton
2003-10-20 20:10     ` Andrew Morton
2003-10-20 21:53     ` Ramón Rey Vicente
2003-10-21  8:03 ` 2.6.0-test8-mm1 Stephane Jourdois
2003-10-21 15:43 ` 2.6.0-test8-mm1 bill davidsen
2003-10-21 17:42   ` 2.6.0-test8-mm1 Valdis.Kletnieks
  -- strict thread matches above, loose matches on Subject: below --
2003-10-20 11:35 2.6.0-test8-mm1 Jan Ischebeck
2003-10-24  0:14 2.6.0-test8-mm1 James Vega
2003-10-24  9:35 2.6.0-test8-mm1 Catani, Antonio
2003-10-24 17:52 ` 2.6.0-test8-mm1 James Simmons

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=200310220053.13547.schlicht@uni-mannheim.de \
    --to=schlicht@uni-mannheim.de \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=akpm@osdl.org \
    --cc=helgehaf@aitel.hist.no \
    --cc=jsimmons@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.