Re: memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel

[Richard Guenther]

On Tue, 29 Mar 2005 17:37:06 +0300, Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> Try testcase below the sig.
> 
> This causes nearly one thousand calls to memcpy in my kernel
> (not an allyesconfig one):

> static inline void * __memcpy(void * to, const void * from, size_t n)
> {
> int d0, d1, d2;
> __asm__ __volatile__(
> "rep ; movsl\n\t"
> "testb $2,%b4\n\t"
> "je 1f\n\t"
> "movsw\n"
> "1:\ttestb $1,%b4\n\t"
> "je 2f\n\t"
> "movsb\n"
> "2:"
> : "=" (d0), "=" (d1), "=" (d2)
> :"0" (n/4), "q" (n),"1" ((long) to),"2" ((long) from)
> : "memory");
> return (to);
> }

The question is, what reason does -Winline give for this inlining
decision?  And then
of course, how is the size estimate counted for the above.  What kind
of tree node do
we get for the ASM expression?

Richard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel

[Richard Guenther]

On Tue, 29 Mar 2005 17:37:06 +0300, Denis Vlasenko [EMAIL PROTECTED] wrote:
 Try testcase below the sig.
 
 This causes nearly one thousand calls to memcpy in my kernel
 (not an allyesconfig one):

 static inline void * __memcpy(void * to, const void * from, size_t n)
 {
 int d0, d1, d2;
 __asm__ __volatile__(
 rep ; movsl\n\t
 testb $2,%b4\n\t
 je 1f\n\t
 movsw\n
 1:\ttestb $1,%b4\n\t
 je 2f\n\t
 movsb\n
 2:
 : =c (d0), =D (d1), =S (d2)
 :0 (n/4), q (n),1 ((long) to),2 ((long) from)
 : memory);
 return (to);
 }

The question is, what reason does -Winline give for this inlining
decision?  And then
of course, how is the size estimate counted for the above.  What kind
of tree node do
we get for the ASM expression?

Richard.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH 2.4.4: Via audio fixes

[Richard Guenther]

On Mon, 30 Apr 2001, Jeff Garzik wrote:

> The attached patch includes fixes to the Via audio driver for which I'm
> interested finding testers.  Testing and a private "it works" (hopefully
> :)) or "it doesn't work,  is what breaks for me" would be
> appreciated.

Works as before -> mono recording does _not_ work, i.e. gives garbage
(as described in sf bugreport).

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH 2.4.4: Via audio fixes

[Richard Guenther]

On Mon, 30 Apr 2001, Jeff Garzik wrote:

 The attached patch includes fixes to the Via audio driver for which I'm
 interested finding testers.  Testing and a private it works (hopefully
 :)) or it doesn't work, here is what breaks for me would be
 appreciated.

Works as before - mono recording does _not_ work, i.e. gives garbage
(as described in sf bugreport).

Richard.

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pthreads & fork & execve

[Richard Guenther]

On Mon, 2 Apr 2001, Gustavo Niemeyer wrote:

> Hi Richard! Hi Dennis!
[...]

> Btw, both are mainly C++ programs. Is your software written in C++?

Not, just plain C - but one point is that we started seeing the problem
after we started using pthread_sigmask() to block certain signals from
reaching our threads.

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pthreads fork execve

[Richard Guenther]

On Mon, 2 Apr 2001, Gustavo Niemeyer wrote:

 Hi Richard! Hi Dennis!
[...]

 Btw, both are mainly C++ programs. Is your software written in C++?

Not, just plain C - but one point is that we started seeing the problem
after we started using pthread_sigmask() to block certain signals from
reaching our threads.

Richard.

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pthreads & fork & execve

[Richard Guenther]

Hi!

I tracked this down to a corrupt jumptable somewhere in the pthreads
part of the libc (didnt have the source handy at that time, though). So
I think this is a libc bug (version does not matter) - I even did a
followup to a similar bug in the libc gnats database (I think I should
have opened a new one, though...). But I failed to construct a "simple"
testcase showing the bug (We use rather large amount of threads and
in one or two doing popen() calls - or handcrafted fork() && execv(),
the SIGSEGV is during fork()).

I stopped trying to find out what is going on as this feature is not
essential (but maybe useful in the future). So I suggest you build a
libc from source with debugging on and trace it down to the actual
libc problem - or better try to isolate a simple testcase.

I like to hear from the results :)

Richard.

On Fri, 30 Mar 2001, Dennis Noordsij wrote:

> Hi,
> 
> I have question regarding use of pthreads, forks and execve's which appears 
> to not work very well :-) First let me explain the reasoning though
> 
> We have an app that launches a few other apps and keeps track of their 
> status, resource consumption etc. If one of the apps crashes, it is restarted 
> according to certain parameters.
> 
> The app uses pthreads, and it's method of (re)starting an application is 
> forking and calling execve. 
> 
> It works fine for all-but-one other app, which core dumps when started this 
> way (from the commandline it works fine) and the core only traces back to  
> int main(int argc, char **argv). It uses both pthreads and -ldl for plugin 
> handling. 
> 
> We have tried changing the linking order (i.e. -ldl -lpthread, -lpthread, 
> -ldl, etc), and even execv'ing a shell script that starts a shell script that 
> starts the app - result is the same, instant core without even running.
> 
> I can see who forks together with threads and execve's are a messy 
> combination, and a better solution altogether to our approach is appreciated 
> just as much as a way to make the current solution work :-)
> 
> We have tested both kernels 2.4.2 and 2.2.18. 
> 
> We have tried on different systems, different hardware and slightly different 
> distributions (debian potato, unstable, etc).
> 
> To sum up: using a pthreaded app to launch another pthreaded app by means of 
> forking and exec(ve)'ng makes the second app core immediately, (at entering 
> main). What to do?
> 
> Kind regards, and thanks for any help
> Dennis Noordsij
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pthreads fork execve

[Richard Guenther]

Hi!

I tracked this down to a corrupt jumptable somewhere in the pthreads
part of the libc (didnt have the source handy at that time, though). So
I think this is a libc bug (version does not matter) - I even did a
followup to a similar bug in the libc gnats database (I think I should
have opened a new one, though...). But I failed to construct a "simple"
testcase showing the bug (We use rather large amount of threads and
in one or two doing popen() calls - or handcrafted fork()  execv(),
the SIGSEGV is during fork()).

I stopped trying to find out what is going on as this feature is not
essential (but maybe useful in the future). So I suggest you build a
libc from source with debugging on and trace it down to the actual
libc problem - or better try to isolate a simple testcase.

I like to hear from the results :)

Richard.

On Fri, 30 Mar 2001, Dennis Noordsij wrote:

 Hi,
 
 I have question regarding use of pthreads, forks and execve's which appears 
 to not work very well :-) First let me explain the reasoning though
 
 We have an app that launches a few other apps and keeps track of their 
 status, resource consumption etc. If one of the apps crashes, it is restarted 
 according to certain parameters.
 
 The app uses pthreads, and it's method of (re)starting an application is 
 forking and calling execve. 
 
 It works fine for all-but-one other app, which core dumps when started this 
 way (from the commandline it works fine) and the core only traces back to  
 int main(int argc, char **argv). It uses both pthreads and -ldl for plugin 
 handling. 
 
 We have tried changing the linking order (i.e. -ldl -lpthread, -lpthread, 
 -ldl, etc), and even execv'ing a shell script that starts a shell script that 
 starts the app - result is the same, instant core without even running.
 
 I can see who forks together with threads and execve's are a messy 
 combination, and a better solution altogether to our approach is appreciated 
 just as much as a way to make the current solution work :-)
 
 We have tested both kernels 2.4.2 and 2.2.18. 
 
 We have tried on different systems, different hardware and slightly different 
 distributions (debian potato, unstable, etc).
 
 To sum up: using a pthreaded app to launch another pthreaded app by means of 
 forking and exec(ve)'ng makes the second app core immediately, (at entering 
 main). What to do?
 
 Kind regards, and thanks for any help
 Dennis Noordsij
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to mount /proc/sys/fs/binfmt_misc ?

[Richard Guenther]

On Thu, 22 Mar 2001, Alexander Viro wrote:

> Actually, the right thing to do would be to drop the ugly tricks with
> writing to .../register and use normal create()/write()/close() to add
> entries. Commit-on-close and there you go. unlink() to remove these
> suckers, chmod g-r to disable.
>
> IOW, instead of
> echo ':foo:...' >register echo ':.' > /etc/binfmt_misc/foo
> echo '-1' > foo   rm /etc/binfmt_misc/foo
> echo '0' > foochmod g-r /etc/binfmt_misc/foo
> echo '1' > foochmod g+r /etc/binfmt_misc/foo
> echo '-1' > statusrm /etc/binfmt_misc/*
> echo '0' > status chmod -x /etc/binfmt_misc
> echo '1' > status chmod +x /etc/binfmt_misc
> cat statuscat /etc/binfmt_misc/*
>
> Normal behaviour instead of black magic, no checks for duplicate entries,
> special names, yodda, yodda - everything would work as one expects from
> normal directory. When you want to create a file you create it, not write
> an incantation into a magic file. And when you want to remove it, the
> last thing you would normally think of is writing "-1" into the victim.
> Yes, I know that procfs doesn't allow that. Mark the correct conclusion:
>   (A) procfs is not suitable for the task
>   (B) we should invent a kludgy way to create files, etc. on
>   procfs without using normal create() and reimplement the
>   sanity checks
>   (C) same as (B), but ignore sanity
> Your choice being...?

My choice would have been (A) if there was a nice way to create small
filesystems at the time I did binfmt_misc. This is also the reason I
dont like your rewrite - it does the same sucky kludges, but with an
own filesystem that could do a lot better - _and_ it breaks
backward compatibility wrt mounting. Doh - I thought you could do
better.

> And yes, I'm quite aware of the fact that we are stuck with the current
> kludgy API - compatibility issues and all such. Pity, that...
>
> Al, very unimpressed both with design and implementation of that kludge...

The first version was w/o /proc support but used sysctl and a userspace
program. But well, people wantet /proc and /proc was sexy, everything
was done using /proc, so I did use it, too. Bad decision - I should have
started rewriting the fs layer at that time...

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to mount /proc/sys/fs/binfmt_misc ?

[Richard Guenther]

On Thu, 22 Mar 2001, Alexander Viro wrote:

 Actually, the right thing to do would be to drop the ugly tricks with
 writing to .../register and use normal create()/write()/close() to add
 entries. Commit-on-close and there you go. unlink() to remove these
 suckers, chmod g-r to disable.

 IOW, instead of
 echo ':foo:...' register echo ':.'  /etc/binfmt_misc/foo
 echo '-1'  foo   rm /etc/binfmt_misc/foo
 echo '0'  foochmod g-r /etc/binfmt_misc/foo
 echo '1'  foochmod g+r /etc/binfmt_misc/foo
 echo '-1'  statusrm /etc/binfmt_misc/*
 echo '0'  status chmod -x /etc/binfmt_misc
 echo '1'  status chmod +x /etc/binfmt_misc
 cat statuscat /etc/binfmt_misc/*

 Normal behaviour instead of black magic, no checks for duplicate entries,
 special names, yodda, yodda - everything would work as one expects from
 normal directory. When you want to create a file you create it, not write
 an incantation into a magic file. And when you want to remove it, the
 last thing you would normally think of is writing "-1" into the victim.
 Yes, I know that procfs doesn't allow that. Mark the correct conclusion:
   (A) procfs is not suitable for the task
   (B) we should invent a kludgy way to create files, etc. on
   procfs without using normal create() and reimplement the
   sanity checks
   (C) same as (B), but ignore sanity
 Your choice being...?

My choice would have been (A) if there was a nice way to create small
filesystems at the time I did binfmt_misc. This is also the reason I
dont like your rewrite - it does the same sucky kludges, but with an
own filesystem that could do a lot better - _and_ it breaks
backward compatibility wrt mounting. Doh - I thought you could do
better.

 And yes, I'm quite aware of the fact that we are stuck with the current
 kludgy API - compatibility issues and all such. Pity, that...

 Al, very unimpressed both with design and implementation of that kludge...

The first version was w/o /proc support but used sysctl and a userspace
program. But well, people wantet /proc and /proc was sexy, everything
was done using /proc, so I did use it, too. Bad decision - I should have
started rewriting the fs layer at that time...

Richard.

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to mount /proc/sys/fs/binfmt_misc ?

[Richard Guenther]

On Mon, 19 Mar 2001, Colin Watson wrote:

> Alexander Viro <[EMAIL PROTECTED]> wrote:
> >Seriously, binfmt_misc.c was written in rather, erm, interesting C.
> >Read it and you'll see. Just one (but rather impressive) example:
> >
> >if ((count == 1) && !(buffer[0] & ~('0' | '1'))) {
> >
> >It was meant to be
> >
> >if (count == 1 && (buffer[0] == '0' || buffer[0] == '1')) {
> >
> >and anyone who can't find the difference really should learn C. And
> >that's not the only bogosity of such level. Besides, the thing is
> >trivially oopsable - write() to any file in binfmt_misc with buffer
> >pointing to unmapped kernel address and you are screwed,
>
> Or you can register binfmt names that are registered already and
> silently shadow old ones, or register names like 'register', 'status',
> '.', and '..'. It's hideous to manage reliably from userspace.

I know you have sent me patches to prevent multiple entries of the
same name some time ago and I can see we argued about it. The main
point I have with such checks is, that we dont prevent root from
doing rm -Rf / either. There is no reason to clobber the kernel with
endless checks of such cornercases (which even dont make the system
unusable, but only one (unimportant) part of it). There is even one
truely nasty "exploit" of binfmt_misc, if you register an entry
that catches standard elf programs and do module insertion of the
elf and misc handler in the right order... how would you catch this!?

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to mount /proc/sys/fs/binfmt_misc ?

[Richard Guenther]

On Mon, 19 Mar 2001, Colin Watson wrote:

 Alexander Viro [EMAIL PROTECTED] wrote:
 Seriously, binfmt_misc.c was written in rather, erm, interesting C.
 Read it and you'll see. Just one (but rather impressive) example:
 
 if ((count == 1)  !(buffer[0]  ~('0' | '1'))) {
 
 It was meant to be
 
 if (count == 1  (buffer[0] == '0' || buffer[0] == '1')) {
 
 and anyone who can't find the difference really should learn C. And
 that's not the only bogosity of such level. Besides, the thing is
 trivially oopsable - write() to any file in binfmt_misc with buffer
 pointing to unmapped kernel address and you are screwed,

 Or you can register binfmt names that are registered already and
 silently shadow old ones, or register names like 'register', 'status',
 '.', and '..'. It's hideous to manage reliably from userspace.

I know you have sent me patches to prevent multiple entries of the
same name some time ago and I can see we argued about it. The main
point I have with such checks is, that we dont prevent root from
doing rm -Rf / either. There is no reason to clobber the kernel with
endless checks of such cornercases (which even dont make the system
unusable, but only one (unimportant) part of it). There is even one
truely nasty "exploit" of binfmt_misc, if you register an entry
that catches standard elf programs and do module insertion of the
elf and misc handler in the right order... how would you catch this!?

Richard.

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fork and pthreads

[Richard Guenther]

Hi!

Well, using pthreads and forking in them seems to trigger libc
bugs (read: SIGSEGvs) here under certain conditions (happens,
after I introduced signal handlers and using pthread_sigmask,
I think), so hangs should be definitely possible, too...

Richard.

On Fri, 16 Mar 2001 [EMAIL PROTECTED] wrote:

> I am having a strange problem.
>
> I have a big daemon program to which I am trying to add multi-threading.
>
> At the begining, after some sanity check, this program does a double fork to
> create a deamon.
>
> After that it listens for the client on the port. Whenever the client
> connects, it creates a new thread using
> pthread-create.
>
> The problem is, the thread (main thread) calling pthread-create hangs
> indefinetely in __sigsuspend. The newly created thread however, runs
> normally to completion.
>
> I wrote few test programs trying to simulate this behaviour but all of them
> worked as expected.
>
> Does anyone know, what's going on ??
>
> Nitin Sane
> [EMAIL PROTECTED]
> *(508)382-7319
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to mount /proc/sys/fs/binfmt_misc ?

[Richard Guenther]

On Fri, 16 Mar 2001, Alexander Viro wrote:
> On Fri, 16 Mar 2001 [EMAIL PROTECTED] wrote:
>
> >   The release notes specify this:
> >
> >  mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
> >
> > but this doesn't work because
> >
> >  mount: mount point /proc/sys/fs/binfmt_misc does not exist
>
> Grr... OK, I've been an overoptimistic idiot and missed that ugliness.
>
> Solutions:
>   a) mount it on some real place. And write there to register
> entries instead of the bogus /proc/sys/fs/binfmt_misc
>   b) add a couple of proc_mkdir() into fs/proc/root.c
c) stick with the previous binfmt_misc in 2.4 and leave the
   filesystem with 2.5

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to mount /proc/sys/fs/binfmt_misc ?

[Richard Guenther]

On Fri, 16 Mar 2001, Alexander Viro wrote:
 On Fri, 16 Mar 2001 [EMAIL PROTECTED] wrote:

The release notes specify this:
 
   mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
 
  but this doesn't work because
 
   mount: mount point /proc/sys/fs/binfmt_misc does not exist

 Grr... OK, I've been an overoptimistic idiot and missed that ugliness.

 Solutions:
   a) mount it on some real place. And write there to register
 entries instead of the bogus /proc/sys/fs/binfmt_misc
   b) add a couple of proc_mkdir() into fs/proc/root.c
c) stick with the previous binfmt_misc in 2.4 and leave the
   filesystem with 2.5

Richard.

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH: "Pass module parameters" to built-in drivers

[Richard Guenther]

Hi!

Well, I did a very similar patch about 2.3.3x and it got even
included in -acXX during a Linus vacation - but it got dropped for
some reason (f.i. such an approach does not work well for multi-file
modules, I was told). I re-sent it during the 2.4.0-test phase and
got no reply, so I think just adding __setup() stuff manually to
every module seems the way to go... :(

Richard.

On Mon, 22 Jan 2001, Werner Almesberger wrote:

> Keith Owens wrote:
> > Inconsistent methods for setting the same parameter are bad.  I can and
> > will do this cleanly in 2.5.
>
> If your approach isn't overly intrusive (i.e. doesn't require changes
> to all files containing module parameters, or such), maybe you could
> make a patch for 2.4.x and wave it a little under Linus' nose. Maybe
> he likes the scent ;-)
>
> In any case, once it's in 2.5.x, and if it is as useful as I suspect
> it to be, it would probably be back-ported to 2.4 sooner or later.
>
> - Werner
>
> --
>   _
>  / Werner Almesberger, ICA, EPFL, CH   [EMAIL PROTECTED] /
> /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PATCH: Pass module parameters to built-in drivers

[Richard Guenther]

Hi!

Well, I did a very similar patch about 2.3.3x and it got even
included in -acXX during a Linus vacation - but it got dropped for
some reason (f.i. such an approach does not work well for multi-file
modules, I was told). I re-sent it during the 2.4.0-test phase and
got no reply, so I think just adding __setup() stuff manually to
every module seems the way to go... :(

Richard.

On Mon, 22 Jan 2001, Werner Almesberger wrote:

 Keith Owens wrote:
  Inconsistent methods for setting the same parameter are bad.  I can and
  will do this cleanly in 2.5.

 If your approach isn't overly intrusive (i.e. doesn't require changes
 to all files containing module parameters, or such), maybe you could
 make a patch for 2.4.x and wave it a little under Linus' nose. Maybe
 he likes the scent ;-)

 In any case, once it's in 2.5.x, and if it is as useful as I suspect
 it to be, it would probably be back-ported to 2.4 sooner or later.

 - Werner

 --
   _
  / Werner Almesberger, ICA, EPFL, CH   [EMAIL PROTECTED] /
 /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 Please read the FAQ at http://www.tux.org/lkml/


--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] Re: BTTV detection broken in 2.4.0-test11-pre5

[Richard Guenther]

On 19 Nov 2000, Gerd Knorr wrote:

> Some generic way to make module args available as kernel args too
> would be nice.  Or at least some simple one-liner I could put next to
> the MODULE_PARM() macro...

Well, I did a patch that does automagically convert MODULE_PARAM
stuff to __setup() functions - it even was in some 2.3.XX-acXX
but appearantly never got into Linus tree.

You may want to look at the "[PATCH] final support for MODULE_PARAM as
kernel commandline" thread, as well as "Re: Linux 2.3.18ac5". To look
at the newest version of the patch just grap the newest 2.3.18acXX,
I tried to rip it out and attached it (but I'm sure it does not
apply cleanly, but you get the idea).

It would be nice to hear from Linus if it was him, who rejected the
change or it was Alan who did not bother to send it.

Richard. 

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

diff -u --new-file --recursive --exclude-from ../exclude 
linux.vanilla/include/linux/module.h linux.ac/include/linux/module.h
--- linux.vanilla/include/linux/module.hTue Aug 17 17:27:42 1999
+++ linux.ac/include/linux/module.h Wed Sep 22 17:00:20 1999
@@ -8,6 +8,7 @@
 #define _LINUX_MODULE_H
 
 #include 
+#include 
 
 #ifdef __GENKSYMS__
 #  define _set_ver(sym) sym
@@ -207,11 +208,17 @@
 #endif
 
 #else /* MODULE */
-
+extern int parse_parameters(void *var, char *type, char *str);
 #define MODULE_AUTHOR(name)
 #define MODULE_DESCRIPTION(desc)
 #define MODULE_SUPPORTED_DEVICE(name)
-#define MODULE_PARM(var,type)
+#define MODULE_PARM(var,type) \
+static char *modparm##var##_setup_type __initdata = type;\
+static int __init modparm##var##_setup(char *str)\
+{\
+  return parse_parameters((void *), modparm##var##_setup_type, str);\
+}\
+__setup(MODULE_NAME #var "=", modparm##var##_setup);
 #define MODULE_PARM_DESC(var,desc)
 
 #ifndef __GENKSYMS__
diff -u --new-file --recursive --exclude-from ../exclude linux.vanilla/lib/Makefile 
linux.ac/lib/Makefile
--- linux.vanilla/lib/Makefile  Mon Nov 27 13:54:00 1995
+++ linux.ac/lib/Makefile   Mon Sep 13 00:04:31 1999
@@ -7,6 +7,6 @@
 #
 
 L_TARGET := lib.a
-L_OBJS   := errno.o ctype.o string.o vsprintf.o
+L_OBJS   := errno.o ctype.o string.o vsprintf.o parse.o
 
 include $(TOPDIR)/Rules.make
diff -u --new-file --recursive --exclude-from ../exclude linux.vanilla/lib/parse.c 
linux.ac/lib/parse.c
--- linux.vanilla/lib/parse.c   Thu Jan  1 01:00:00 1970
+++ linux.ac/lib/parse.cMon Sep 13 01:57:36 1999
@@ -0,0 +1,119 @@
+/*
+ *  linux/lib/parse.c
+ *
+ *  (C) Richard Guenther <[EMAIL PROTECTED]>
+ *
+ *  Heavily based on parts of modutil's insmod.c which is
+ *
+ *  Copyright 1996, 1997 Linux International.
+ *
+ *  New implementation contributed by Richard Henderson <[EMAIL PROTECTED]>
+ *  Based on original work by Bjorn Eckwall <[EMAIL PROTECTED]>
+ *
+ *  This file is part of the Linux modutils.
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or (at your
+ *  option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software Foundation,
+ *  Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Fixes:
+ * Alan CoxMake it get non arrays right.
+ */
+
+#include 
+#include 
+#include 
+
+/* parse module parameters like insmod */
+int parse_parameters(void *var, char *type, char *str)
+{
+   char *p, t;
+   long min, max, val, cnt;
+   int array = 0;
+   
+   p = type;
+   if (isdigit(*p)) {
+   min = simple_strtoul(p, , 0);
+   if (*p == '-')
+   {
+   max = simple_strtoul(p+1, , 0);
+   array=1;
+   }
+   else
+   max = min;
+   } else
+   min = max = 1;
+   t = *p;
+   
+   /*
+*  We are passed a pointer to the object. Now the object
+*  could be an array, in which case we have a pointer to
+*  a pointer. It might be a direct value in which case
+*  we have a pointer the value to write.
+*
+*  For an array we want to the array base, for a non array
+*  pass, we want the value
+*
+*  Alan.
+*/
+
+   if(array)
+   var=*(void **)var;
+
+   p = str;
+   cnt = 0;
+   

[PATCH] Re: BTTV detection broken in 2.4.0-test11-pre5

[Richard Guenther]

On 19 Nov 2000, Gerd Knorr wrote:

 Some generic way to make module args available as kernel args too
 would be nice.  Or at least some simple one-liner I could put next to
 the MODULE_PARM() macro...

Well, I did a patch that does automagically convert MODULE_PARAM
stuff to __setup() functions - it even was in some 2.3.XX-acXX
but appearantly never got into Linus tree.

You may want to look at the "[PATCH] final support for MODULE_PARAM as
kernel commandline" thread, as well as "Re: Linux 2.3.18ac5". To look
at the newest version of the patch just grap the newest 2.3.18acXX,
I tried to rip it out and attached it (but I'm sure it does not
apply cleanly, but you get the idea).

It would be nice to hear from Linus if it was him, who rejected the
change or it was Alan who did not bother to send it.

Richard. 

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

diff -u --new-file --recursive --exclude-from ../exclude 
linux.vanilla/include/linux/module.h linux.ac/include/linux/module.h
--- linux.vanilla/include/linux/module.hTue Aug 17 17:27:42 1999
+++ linux.ac/include/linux/module.h Wed Sep 22 17:00:20 1999
@@ -8,6 +8,7 @@
 #define _LINUX_MODULE_H
 
 #include linux/config.h
+#include linux/init.h
 
 #ifdef __GENKSYMS__
 #  define _set_ver(sym) sym
@@ -207,11 +208,17 @@
 #endif
 
 #else /* MODULE */
-
+extern int parse_parameters(void *var, char *type, char *str);
 #define MODULE_AUTHOR(name)
 #define MODULE_DESCRIPTION(desc)
 #define MODULE_SUPPORTED_DEVICE(name)
-#define MODULE_PARM(var,type)
+#define MODULE_PARM(var,type) \
+static char *modparm##var##_setup_type __initdata = type;\
+static int __init modparm##var##_setup(char *str)\
+{\
+  return parse_parameters((void *)var, modparm##var##_setup_type, str);\
+}\
+__setup(MODULE_NAME #var "=", modparm##var##_setup);
 #define MODULE_PARM_DESC(var,desc)
 
 #ifndef __GENKSYMS__
diff -u --new-file --recursive --exclude-from ../exclude linux.vanilla/lib/Makefile 
linux.ac/lib/Makefile
--- linux.vanilla/lib/Makefile  Mon Nov 27 13:54:00 1995
+++ linux.ac/lib/Makefile   Mon Sep 13 00:04:31 1999
@@ -7,6 +7,6 @@
 #
 
 L_TARGET := lib.a
-L_OBJS   := errno.o ctype.o string.o vsprintf.o
+L_OBJS   := errno.o ctype.o string.o vsprintf.o parse.o
 
 include $(TOPDIR)/Rules.make
diff -u --new-file --recursive --exclude-from ../exclude linux.vanilla/lib/parse.c 
linux.ac/lib/parse.c
--- linux.vanilla/lib/parse.c   Thu Jan  1 01:00:00 1970
+++ linux.ac/lib/parse.cMon Sep 13 01:57:36 1999
@@ -0,0 +1,119 @@
+/*
+ *  linux/lib/parse.c
+ *
+ *  (C) Richard Guenther [EMAIL PROTECTED]
+ *
+ *  Heavily based on parts of modutil's insmod.c which is
+ *
+ *  Copyright 1996, 1997 Linux International.
+ *
+ *  New implementation contributed by Richard Henderson [EMAIL PROTECTED]
+ *  Based on original work by Bjorn Eckwall [EMAIL PROTECTED]
+ *
+ *  This file is part of the Linux modutils.
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or (at your
+ *  option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software Foundation,
+ *  Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Fixes:
+ * Alan CoxMake it get non arrays right.
+ */
+
+#include linux/kernel.h
+#include linux/ctype.h
+#include linux/string.h
+
+/* parse module parameters like insmod */
+int parse_parameters(void *var, char *type, char *str)
+{
+   char *p, t;
+   long min, max, val, cnt;
+   int array = 0;
+   
+   p = type;
+   if (isdigit(*p)) {
+   min = simple_strtoul(p, p, 0);
+   if (*p == '-')
+   {
+   max = simple_strtoul(p+1, p, 0);
+   array=1;
+   }
+   else
+   max = min;
+   } else
+   min = max = 1;
+   t = *p;
+   
+   /*
+*  We are passed a pointer to the object. Now the object
+*  could be an array, in which case we have a pointer to
+*  a pointer. It might be a direct value in which case
+*  we have a pointer the value to write.
+*
+*  For an array we want to the array base, for a non array
+*  pass, we want the value
+*
+*  Alan.
+*/
+
+   if(array)
+   var=*(void **)var;
+
+   p = st

Re: Broken colors on console with 2.4.0-textXX

[Richard Guenther]

On Wed, 8 Nov 2000, James Simmons wrote:

> 
> > Sure - but this was always the case. And using 2.2 with the same
> > (or more) stress the Xserver is still able to set the video hardware
> > back to vga text mode. I just want to know whats the difference
> > between 2.2 and 2.4 that causes failure in 2.4.
> 
> I don't think it is the console system. I bet if you stress 2.2 even more
> you will get the same results.

Ok, obviously I'm not happy with this - I'll try to stress 2.2, but
it never happened there. With 2.4 its nearly _always_ the case (on
32Megs ram you get into swapping very fast with X and gnome) - so, to
repeat, I'm not happy with the current 2.4 situation.

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Broken colors on console with 2.4.0-textXX

[Richard Guenther]

On Wed, 8 Nov 2000, James Simmons wrote:

 
  Sure - but this was always the case. And using 2.2 with the same
  (or more) stress the Xserver is still able to set the video hardware
  back to vga text mode. I just want to know whats the difference
  between 2.2 and 2.4 that causes failure in 2.4.
 
 I don't think it is the console system. I bet if you stress 2.2 even more
 you will get the same results.

Ok, obviously I'm not happy with this - I'll try to stress 2.2, but
it never happened there. With 2.4 its nearly _always_ the case (on
32Megs ram you get into swapping very fast with X and gnome) - so, to
repeat, I'm not happy with the current 2.4 situation.

Richard.

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Broken colors on console with 2.4.0-textXX

[Richard Guenther]

On Wed, 8 Nov 2000, James Simmons wrote:

> 
> > Okay - so its the console subsystem that gets it wrong? Remember
> > that 2.2.X gets it right - with the same X server. I really
> > would like to have this fixed in 2.4 - can I do something to
> > help fixing this? (I'm not familiar with the console subsystem,
> > neither with the X server)
> 
> It is the way it is done that is wrong. At present the X server is in
> total control of setting the console system back to text mode. This
> works under normal conditions but when the system is stressed or X
> fails you are stuck. The console system should be setting the video
> hardware back to vga text mode instead of the X server. I have been
> working on a patch that does that. 

Sure - but this was always the case. And using 2.2 with the same
(or more) stress the Xserver is still able to set the video hardware
back to vga text mode. I just want to know whats the difference
between 2.2 and 2.4 that causes failure in 2.4.

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Broken colors on console with 2.4.0-textXX

[Richard Guenther]

On Wed, 8 Nov 2000, James Simmons wrote:

> 
> > You didnt read the config, etc. I posted - I dont have DRI - I
> > have an old P100 with 32Megs of ram and an old ATI Mach64 graphics
> > card. There really is nothing unusual with my setup - console
> > garbagling is even without loading the bttv module at all.
> 
> Okay. So it is what I thought it was orginally.

Okay - so its the console subsystem that gets it wrong? Remember
that 2.2.X gets it right - with the same X server. I really
would like to have this fixed in 2.4 - can I do something to
help fixing this? (I'm not familiar with the console subsystem,
neither with the X server)

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Broken colors on console with 2.4.0-textXX

[Richard Guenther]

On Tue, 7 Nov 2000, Alan Cox wrote:

> > Actually I just thought about it. Do you DRI running. When you have DRI
> > enabled you shouldn't VT switch. It is a design flaw in DRI and the
> > console system :-(. Disable DRI you you will be fine.
> 
> The theory behind DRI covers this fine. If its breaking fix the bugs in the
> Xserver and DRI code. X gets to pick when it gives the console back

You didnt read the config, etc. I posted - I dont have DRI - I
have an old P100 with 32Megs of ram and an old ATI Mach64 graphics
card. There really is nothing unusual with my setup - console
garbagling is even without loading the bttv module at all.

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Broken colors on console with 2.4.0-textXX

[Richard Guenther]

On Tue, 7 Nov 2000, Alan Cox wrote:

  Actually I just thought about it. Do you DRI running. When you have DRI
  enabled you shouldn't VT switch. It is a design flaw in DRI and the
  console system :-(. Disable DRI you you will be fine.
 
 The theory behind DRI covers this fine. If its breaking fix the bugs in the
 Xserver and DRI code. X gets to pick when it gives the console back

You didnt read the config, etc. I posted - I dont have DRI - I
have an old P100 with 32Megs of ram and an old ATI Mach64 graphics
card. There really is nothing unusual with my setup - console
garbagling is even without loading the bttv module at all.

Richard.

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Broken colors on console with 2.4.0-textXX

[Richard Guenther]

On Wed, 8 Nov 2000, James Simmons wrote:

 
  You didnt read the config, etc. I posted - I dont have DRI - I
  have an old P100 with 32Megs of ram and an old ATI Mach64 graphics
  card. There really is nothing unusual with my setup - console
  garbagling is even without loading the bttv module at all.
 
 Okay. So it is what I thought it was orginally.

Okay - so its the console subsystem that gets it wrong? Remember
that 2.2.X gets it right - with the same X server. I really
would like to have this fixed in 2.4 - can I do something to
help fixing this? (I'm not familiar with the console subsystem,
neither with the X server)

Richard.

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Broken colors on console with 2.4.0-textXX

[Richard Guenther]

On Wed, 8 Nov 2000, James Simmons wrote:

 
  Okay - so its the console subsystem that gets it wrong? Remember
  that 2.2.X gets it right - with the same X server. I really
  would like to have this fixed in 2.4 - can I do something to
  help fixing this? (I'm not familiar with the console subsystem,
  neither with the X server)
 
 It is the way it is done that is wrong. At present the X server is in
 total control of setting the console system back to text mode. This
 works under normal conditions but when the system is stressed or X
 fails you are stuck. The console system should be setting the video
 hardware back to vga text mode instead of the X server. I have been
 working on a patch that does that. 

Sure - but this was always the case. And using 2.2 with the same
(or more) stress the Xserver is still able to set the video hardware
back to vga text mode. I just want to know whats the difference
between 2.2 and 2.4 that causes failure in 2.4.

Richard.

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Broken colors on console with 2.4.0-textXX

[Richard Guenther]

On Mon, 6 Nov 2000, James Simmons wrote:

> > Unfortunately I cannot confirm this. Checked 2.4.0-test10 and the problem
> > is still there. I digged further and it seems to be a race condition(?)
> > triggered by swapped out stuff - because just starting X and switching
> > back to the console works fine, but as I start some memory-consuming stuff
> > (I have only 32Megs of ram) and then switch back to the console its
> > completely garbagled the first time and black the second time and later.
> 
> I have seen this problem before. The problem is the X server is the one
> that sets the hardware back to vga text mode. Under heavy stress the X
> server can fail and the hardware is left in a undeterminate state. I have
> started on working to solve this problem but it will be something for
> 2.5.X since it requires quite a bit of change to vgacon and the console
> system. My recent vga patches where early attempts at this but they are
> still incomplete.  

Umm, so why does this not happen with 2.2.X at all? Also the system is
not really stressed, but I simply do startx, inside an xterm go to
some random source, make -j, wait till the compile is complete and then
switch back to the console - its just that it seems that swapped out
X server or console stuff causes this.

I consider this quite a showstopper for 2.4.0.

Richard. 

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Broken colors on console with 2.4.0-textXX

[Richard Guenther]

On Mon, 6 Nov 2000, James Simmons wrote:

  Unfortunately I cannot confirm this. Checked 2.4.0-test10 and the problem
  is still there. I digged further and it seems to be a race condition(?)
  triggered by swapped out stuff - because just starting X and switching
  back to the console works fine, but as I start some memory-consuming stuff
  (I have only 32Megs of ram) and then switch back to the console its
  completely garbagled the first time and black the second time and later.
 
 I have seen this problem before. The problem is the X server is the one
 that sets the hardware back to vga text mode. Under heavy stress the X
 server can fail and the hardware is left in a undeterminate state. I have
 started on working to solve this problem but it will be something for
 2.5.X since it requires quite a bit of change to vgacon and the console
 system. My recent vga patches where early attempts at this but they are
 still incomplete.  

Umm, so why does this not happen with 2.2.X at all? Also the system is
not really stressed, but I simply do startx, inside an xterm go to
some random source, make -j, wait till the compile is complete and then
switch back to the console - its just that it seems that swapped out
X server or console stuff causes this.

I consider this quite a showstopper for 2.4.0.

Richard. 

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Broken colors on console with 2.4.0-textXX

[Richard Guenther]

On Fri, 3 Nov 2000, James Simmons wrote:

> 
> > > How recent of a test kernel. Yes their was a problem with the console
> > > palette but it is now fixed in the most recent test kernels.
> > 
> > 2.4.0-test10-pre5
> 
> Please upgrade to a newer kernel. This problem has been fixed :-)
> 

Unfortunately I cannot confirm this. Checked 2.4.0-test10 and the problem
is still there. I digged further and it seems to be a race condition(?)
triggered by swapped out stuff - because just starting X and switching
back to the console works fine, but as I start some memory-consuming stuff
(I have only 32Megs of ram) and then switch back to the console its
completely garbagled the first time and black the second time and later.

For your information, my config, etc. is attached below.

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

CONFIG_X86=y
CONFIG_ISA=y
CONFIG_UID16=y
CONFIG_EXPERIMENTAL=y
CONFIG_MODULES=y
CONFIG_KMOD=y
CONFIG_M586TSC=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_USE_STRING_486=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_TSC=y
CONFIG_NOHIGHMEM=y
CONFIG_NET=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PNP=y
CONFIG_BLK_DEV_FD=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_PACKET=y
CONFIG_NETLINK=y
CONFIG_NETLINK_DEV=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_PIIX_TUNING=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_IDE_MODES=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=m
CONFIG_SD_EXTRA_DEVS=40
CONFIG_CHR_DEV_ST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_SR_EXTRA_DEVS=2
CONFIG_CHR_DEV_SG=m
CONFIG_SCSI_DEBUG_QUEUES=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_SYM53C8XX=y
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=4
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
CONFIG_SCSI_NCR53C8XX_SYNC=20
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_SMC=y
CONFIG_NET_ISA=y
CONFIG_NE2000=m
CONFIG_NET_PCI=y
CONFIG_RTL8129=m
CONFIG_8139TOO=m
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_CHARDEV=m
CONFIG_RTC=y
CONFIG_VIDEO_DEV=y
CONFIG_VIDEO_PROC_FS=y
CONFIG_VIDEO_BT848=m
CONFIG_AUTOFS4_FS=y
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_RAMFS=m
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_MINIX_FS=m
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y
CONFIG_CODA_FS=m
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_SUNRPC=m
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_UTF8=m
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_SOUND=y
CONFIG_SOUND_OSS=y
CONFIG_SOUND_TRACEINIT=y
CONFIG_SOUND_DMAP=y
CONFIG_SOUND_SB=y
CONFIG_SOUND_AWE32_SYNTH=m
CONFIG_SOUND_TVMIXER=m
CONFIG_MAGIC_SYSRQ=y

Linux version 2.4.0-test10 (root@mickey) (gcc version 2.95.2 2220 (Debian 
GNU/Linux)) #19 Sam Nov 4 21:29:27 CET 2000
BIOS-provided physical RAM map:
 BIOS-e820: 000a @  (usable)
 BIOS-e820: 00018000 @ 000e8000 (reserved)
 BIOS-e820: 01f0 @ 0010 (usable)
 BIOS-e820: 0002 @ fffe (reserved)
On node 0 totalpages: 8192
zone(0): 4096 pages.
zone(1): 4096 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=beta ro root=1601 BOOT_FILE=/lib/images/beta/zImage 
sb=0x220,5,1,5 uart401=0x330,-1
Initializing CPU#0
Detected 99.476 MHz processor.
Console: colour VGA+ 100x30
Calibrating delay loop... 198.25 BogoMIPS
Memory: 30304k/32768k available (1057k kernel code, 2080k reserved, 80k data, 188k 
init, 0k highmem)
Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 2048 (order: 2, 16384 bytes)
CPU: Intel Pentium 75 - 200 stepping 05
Checking 'hlt' instruction... OK.
Intel Pentium with F0 0F bug - workaround enabled.
POSIX conformance testing by UNIFIX
PCI: PCI BIOS revision 2.10 entry at 0xfbcd0, last bus=0
PCI: Using configuration type 1
PCI: Probing PCI hardware
Limiting direct PCI/PCI transfers.
Linux NET4.0 for Linux 2

Re: Broken colors on console with 2.4.0-textXX

[Richard Guenther]

On Fri, 3 Nov 2000, James Simmons wrote:

 
   How recent of a test kernel. Yes their was a problem with the console
   palette but it is now fixed in the most recent test kernels.
  
  2.4.0-test10-pre5
 
 Please upgrade to a newer kernel. This problem has been fixed :-)
 

Unfortunately I cannot confirm this. Checked 2.4.0-test10 and the problem
is still there. I digged further and it seems to be a race condition(?)
triggered by swapped out stuff - because just starting X and switching
back to the console works fine, but as I start some memory-consuming stuff
(I have only 32Megs of ram) and then switch back to the console its
completely garbagled the first time and black the second time and later.

For your information, my config, etc. is attached below.

Richard.

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

CONFIG_X86=y
CONFIG_ISA=y
CONFIG_UID16=y
CONFIG_EXPERIMENTAL=y
CONFIG_MODULES=y
CONFIG_KMOD=y
CONFIG_M586TSC=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_USE_STRING_486=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_TSC=y
CONFIG_NOHIGHMEM=y
CONFIG_NET=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PNP=y
CONFIG_BLK_DEV_FD=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_PACKET=y
CONFIG_NETLINK=y
CONFIG_NETLINK_DEV=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_PIIX_TUNING=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_IDE_MODES=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=m
CONFIG_SD_EXTRA_DEVS=40
CONFIG_CHR_DEV_ST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_SR_EXTRA_DEVS=2
CONFIG_CHR_DEV_SG=m
CONFIG_SCSI_DEBUG_QUEUES=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_SYM53C8XX=y
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=4
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
CONFIG_SCSI_NCR53C8XX_SYNC=20
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_SMC=y
CONFIG_NET_ISA=y
CONFIG_NE2000=m
CONFIG_NET_PCI=y
CONFIG_RTL8129=m
CONFIG_8139TOO=m
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_CHARDEV=m
CONFIG_RTC=y
CONFIG_VIDEO_DEV=y
CONFIG_VIDEO_PROC_FS=y
CONFIG_VIDEO_BT848=m
CONFIG_AUTOFS4_FS=y
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_RAMFS=m
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_MINIX_FS=m
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y
CONFIG_CODA_FS=m
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_SUNRPC=m
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_UTF8=m
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_SOUND=y
CONFIG_SOUND_OSS=y
CONFIG_SOUND_TRACEINIT=y
CONFIG_SOUND_DMAP=y
CONFIG_SOUND_SB=y
CONFIG_SOUND_AWE32_SYNTH=m
CONFIG_SOUND_TVMIXER=m
CONFIG_MAGIC_SYSRQ=y

Linux version 2.4.0-test10 (root@mickey) (gcc version 2.95.2 2220 (Debian 
GNU/Linux)) #19 Sam Nov 4 21:29:27 CET 2000
BIOS-provided physical RAM map:
 BIOS-e820: 000a @  (usable)
 BIOS-e820: 00018000 @ 000e8000 (reserved)
 BIOS-e820: 01f0 @ 0010 (usable)
 BIOS-e820: 0002 @ fffe (reserved)
On node 0 totalpages: 8192
zone(0): 4096 pages.
zone(1): 4096 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=beta ro root=1601 BOOT_FILE=/lib/images/beta/zImage 
sb=0x220,5,1,5 uart401=0x330,-1
Initializing CPU#0
Detected 99.476 MHz processor.
Console: colour VGA+ 100x30
Calibrating delay loop... 198.25 BogoMIPS
Memory: 30304k/32768k available (1057k kernel code, 2080k reserved, 80k data, 188k 
init, 0k highmem)
Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 2048 (order: 2, 16384 bytes)
CPU: Intel Pentium 75 - 200 stepping 05
Checking 'hlt' instruction... OK.
Intel Pentium with F0 0F bug - workaround enabled.
POSIX conformance testing by UNIFIX
PCI: PCI BIOS revision 2.10 entry at 0xfbcd0, last bus=0
PCI: Using configuration type 1
PCI: Probing PCI hardware
Limiting direct PCI/PCI transfers.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting k

Re: Broken colors on console with 2.4.0-textXX

[Richard Guenther]

On Thu, 2 Nov 2000, James Simmons wrote:

> > Console colors are completely messed up (read: black, I even suspect
> > the font to be corrupt somehow) if switching back to console mode
> > from X (either by quitting or ctrl-alt-fX) in recent 2.4.0-textXX
> > kernels. 2.2.XX do work just fine. Is this a known problem with a
> > known fix?
> 
> How recent of a test kernel. Yes their was a problem with the console
> palette but it is now fixed in the most recent test kernels.

2.4.0-test10-pre5

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Broken colors on console with 2.4.0-textXX

[Richard Guenther]

Hi!

Console colors are completely messed up (read: black, I even suspect
the font to be corrupt somehow) if switching back to console mode
from X (either by quitting or ctrl-alt-fX) in recent 2.4.0-textXX
kernels. 2.2.XX do work just fine. Is this a known problem with a
known fix?

Setup: standard VGA console, nothing special. ATI Mach64 Xserver which
is fine with 2.2.XX

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Broken colors on console with 2.4.0-textXX

[Richard Guenther]

Hi!

Console colors are completely messed up (read: black, I even suspect
the font to be corrupt somehow) if switching back to console mode
from X (either by quitting or ctrl-alt-fX) in recent 2.4.0-textXX
kernels. 2.2.XX do work just fine. Is this a known problem with a
known fix?

Setup: standard VGA console, nothing special. ATI Mach64 Xserver which
is fine with 2.2.XX

Richard.

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.0-test10-pre3 isapnp-patch breaks sb detection

[Richard Guenther]

Hi!

The isapnp change in 2.4.0-test10-pre beaks the detection of
my non-pnp soundblaster AWE32 card (compiled into the kernel,
as modular operation oopses - see mail with Subject:sound related OOPS
(2.4.0-test9-pre7) from Sun, 1 Oct 2000 15:49:46). The kernel
hangs after printing the message
sb: No ISAPnP cards found...
in working kernels after that the sb card with io/irq/etc. is printed.

There are no sound changes in the 2.4.0-test10-pre patchset, so
I highly suspect the isapnp-change - configuring isapnp out
gives a working system again. (note that isapnp is modular in my
system, used for an isapnp ne2000 clone).

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.0-test10-pre3 isapnp-patch breaks sb detection

[Richard Guenther]

Hi!

The isapnp change in 2.4.0-test10-pre beaks the detection of
my non-pnp soundblaster AWE32 card (compiled into the kernel,
as modular operation oopses - see mail with Subject:sound related OOPS
(2.4.0-test9-pre7) from Sun, 1 Oct 2000 15:49:46). The kernel
hangs after printing the message
sb: No ISAPnP cards found...
in working kernels after that the sb card with io/irq/etc. is printed.

There are no sound changes in the 2.4.0-test10-pre patchset, so
I highly suspect the isapnp-change - configuring isapnp out
gives a working system again. (note that isapnp is modular in my
system, used for an isapnp ne2000 clone).

Richard.

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Patch to remove undefined C code

[Richard Guenther]

On Tue, 17 Oct 2000, Bernd Schmidt wrote:

> On Tue, 17 Oct 2000, Richard Guenther wrote:
> 
> > On Mon, 16 Oct 2000, Bernd Schmidt wrote:
> > 
> > > I've been playing with some gcc patches to detect code with undefined
> > > behaviour of the i = i++ variety.  The patch below fixes all places in
> > > the kernel that I could find.  Note that in some cases, it wasn't
> > > entirely clear what the code intended, so I had to guess.
> > > 
> > > I haven't tested this patch at all other than to make sure it compiles.
> > 
> > The following one is wrong, tho - should be rather
> > str[i] = dn[i]; i++;
> 
> Nope.  (Well, at least you need to add extra braces.)  The comma is a
> sequence point.

Umm, I thought, dn[i], i++ evaluates to i and dn[i++] evaluates
to dn[i], so it should be either i++, dn[i-1] or the one I showed
above?

Richard.

> > > diff -x log.build -x .* -dru linux-2.4/drivers/isdn/sc/debug.c 
>linux-2.4-fixed/drivers/isdn/sc/debug.c
> > > --- linux-2.4/drivers/isdn/sc/debug.c Thu Apr  2 01:21:04 1998
> > > +++ linux-2.4-fixed/drivers/isdn/sc/debug.c   Mon Oct 16 14:53:49 2000
> > > @@ -70,6 +70,6 @@
> > >   int i = 0;
> > >  
> > >   while(dn[i] != ',')
> > > - str[i] = dn[i++];
> > > + str[i] = dn[i], i++;
> > >   str[i] = 0x0;
> > >  }
> 
> 
> Bernd
> 

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Patch to remove undefined C code

[Richard Guenther]

On Mon, 16 Oct 2000, Bernd Schmidt wrote:

> I've been playing with some gcc patches to detect code with undefined
> behaviour of the i = i++ variety.  The patch below fixes all places in
> the kernel that I could find.  Note that in some cases, it wasn't
> entirely clear what the code intended, so I had to guess.
> 
> I haven't tested this patch at all other than to make sure it compiles.

The following one is wrong, tho - should be rather
str[i] = dn[i]; i++;

> diff -x log.build -x .* -dru linux-2.4/drivers/isdn/sc/debug.c 
>linux-2.4-fixed/drivers/isdn/sc/debug.c
> --- linux-2.4/drivers/isdn/sc/debug.c Thu Apr  2 01:21:04 1998
> +++ linux-2.4-fixed/drivers/isdn/sc/debug.c   Mon Oct 16 14:53:49 2000
> @@ -70,6 +70,6 @@
>   int i = 0;
>  
>   while(dn[i] != ',')
> - str[i] = dn[i++];
> + str[i] = dn[i], i++;
>   str[i] = 0x0;
>  }



--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre1 problems on 4-way SuperServer8050

[Richard Guenther]

On Fri, 13 Oct 2000, Rik van Riel wrote:

> On Thu, 12 Oct 2000, Richard Guenther wrote:
> 
> > I reported this BUG on a few days ago but got no response - happens
> > on UP with only 32M ram, too. (see below). Also note the second
> > BUG at vmscan.c:538 which I believe never saw reported again.
> 
> > > Oct 11 16:05:26 hilbert36 kernel: kernel BUG at page_alloc.c:221!
> > [snipped]
> 
> Did you get the bug with or without VMware ?
> [it seems vmware is doing something strange ;)]

I dont have VMware - at least it would be no fun on 32M and an old
P100 I suspect... :)

> The second bug is almost certainly a direct
> consequence of the kernel continuing after
> the first one happened...

Yeah, that was my thought, too - but who knows...

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre1 problems on 4-way SuperServer8050

[Richard Guenther]

On Fri, 13 Oct 2000, Rik van Riel wrote:

 On Thu, 12 Oct 2000, Richard Guenther wrote:
 
  I reported this BUG on a few days ago but got no response - happens
  on UP with only 32M ram, too. (see below). Also note the second
  BUG at vmscan.c:538 which I believe never saw reported again.
 
   Oct 11 16:05:26 hilbert36 kernel: kernel BUG at page_alloc.c:221!
  [snipped]
 
 Did you get the bug with or without VMware ?
 [it seems vmware is doing something strange ;)]

I dont have VMware - at least it would be no fun on 32M and an old
P100 I suspect... :)

 The second bug is almost certainly a direct
 consequence of the kernel continuing after
 the first one happened...

Yeah, that was my thought, too - but who knows...

Richard.

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre1 problems on 4-way SuperServer8050

[Richard Guenther]

Hi!

I reported this BUG on a few days ago but got no response - happens
on UP with only 32M ram, too. (see below). Also note the second
BUG at vmscan.c:538 which I believe never saw reported again.

Richard.

On Wed, 11 Oct 2000, Tigran Aivazian wrote:

> On Wed, 11 Oct 2000, Rik van Riel wrote:
> > Could you send me the backtrace of one of the cases where
> > you hit the bug ?
> 
> here you are:
> 
> Oct 11 16:05:26 hilbert36 kernel: kernel BUG at page_alloc.c:221!
[snipped]

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

Oct  7 11:50:47 localhost kernel: kernel BUG at page_alloc.c:91!
Oct  7 11:50:47 localhost kernel: invalid operand: 
Oct  7 11:50:47 localhost kernel: CPU:0
Oct  7 11:50:47 localhost kernel: EIP:0010:[__free_pages_ok+73/892]
Oct  7 11:50:47 localhost kernel: EFLAGS: 00010286
Oct  7 11:50:47 localhost kernel: eax: 001f   ebx: c1002a90   ecx: c10a4000   edx: 

Oct  7 11:50:47 localhost kernel: esi: c1002aac   edi:    ebp: 002c   esp: 
c10a5f64
Oct  7 11:50:47 localhost kernel: ds: 0018   es: 0018   ss: 0018
Oct  7 11:50:47 localhost kernel: Process kswapd (pid: 2, stackpage=c10a5000)
Oct  7 11:50:47 localhost kernel: Stack: c01d4877 c01d4a65 005b c1002a90 c1002aac 
00ce 002c 00ce 
Oct  7 11:50:47 localhost kernel:002b  0003 c0126042 c01278cb 
c0126229  0004 
Oct  7 11:50:47 localhost kernel:   0004  
 c0126870 0004 
Oct  7 11:50:47 localhost kernel: Call Trace: [tvecs+8671/55752] [tvecs+9165/55752] 
[page_launder+674/1888] [__free_pages+19/20] [page_launder+1161/1888] 
[do_try_to_free_pages+52/128] [tvecs+7999/55752] 
Oct  7 11:50:47 localhost kernel:[kswapd+115/288] [kernel_thread+40/56] 
Oct  7 11:50:47 localhost kernel: Code: 0f 0b 83 c4 0c 89 f6 89 da 2b 15 f8 89 26 c0 
89 d0 c1 e0 04 

Oct  7 11:50:51 localhost kernel: kernel BUG at vmscan.c:538!
Oct  7 11:50:51 localhost kernel: invalid operand: 
Oct  7 11:50:51 localhost kernel: CPU:0
Oct  7 11:50:51 localhost kernel: EIP:0010:[reclaim_page+897/980]
Oct  7 11:50:51 localhost kernel: EFLAGS: 00010282
Oct  7 11:50:51 localhost kernel: eax: 001c   ebx: c1002aac   ecx: c1636000   edx: 
0010
Oct  7 11:50:51 localhost kernel: esi: c1002a90   edi:    ebp: 0040   esp: 
c1637e3c
Oct  7 11:50:51 localhost kernel: ds: 0018   es: 0018   ss: 0018
Oct  7 11:50:51 localhost kernel: Process cc1 (pid: 2614, stackpage=c1637000)
Oct  7 11:50:51 localhost kernel: Stack: c01d4277 c01d4456 021a c020bb20 c020bdb4 
  c0127548 
Oct  7 11:50:51 localhost kernel:c020bb20  c020bdb8 0001  
c0127702 c020bdac  
Oct  7 11:50:51 localhost kernel: 0001 1000 c03a7d60 0001 
c04fe080 0007a746 0005 
Oct  7 11:50:51 localhost kernel: Call Trace: [tvecs+7135/55752] [tvecs+7614/55752] 
[__alloc_pages_limit+124/172] [__alloc_pages+394/756] [do_anonymous_page+57/160] 
[do_no_page+48/192] [handle_mm_fault+232/340] 
Oct  7 11:50:51 localhost kernel:[do_page_fault+299/976] 
[merge_segments+324/364] [do_brk+267/316] [sys_brk+180/216] [error_code+44/64] 
Oct  7 11:50:51 localhost kernel: Code: 0f 0b 83 c4 0c 31 c0 0f b3 46 18 8d 4e 28 8d 
46 2c 39 46 2c 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre1 problems on 4-way SuperServer8050

[Richard Guenther]

Hi!

I reported this BUG on a few days ago but got no response - happens
on UP with only 32M ram, too. (see below). Also note the second
BUG at vmscan.c:538 which I believe never saw reported again.

Richard.

On Wed, 11 Oct 2000, Tigran Aivazian wrote:

 On Wed, 11 Oct 2000, Rik van Riel wrote:
  Could you send me the backtrace of one of the cases where
  you hit the bug ?
 
 here you are:
 
 Oct 11 16:05:26 hilbert36 kernel: kernel BUG at page_alloc.c:221!
[snipped]

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

Oct  7 11:50:47 localhost kernel: kernel BUG at page_alloc.c:91!
Oct  7 11:50:47 localhost kernel: invalid operand: 
Oct  7 11:50:47 localhost kernel: CPU:0
Oct  7 11:50:47 localhost kernel: EIP:0010:[__free_pages_ok+73/892]
Oct  7 11:50:47 localhost kernel: EFLAGS: 00010286
Oct  7 11:50:47 localhost kernel: eax: 001f   ebx: c1002a90   ecx: c10a4000   edx: 

Oct  7 11:50:47 localhost kernel: esi: c1002aac   edi:    ebp: 002c   esp: 
c10a5f64
Oct  7 11:50:47 localhost kernel: ds: 0018   es: 0018   ss: 0018
Oct  7 11:50:47 localhost kernel: Process kswapd (pid: 2, stackpage=c10a5000)
Oct  7 11:50:47 localhost kernel: Stack: c01d4877 c01d4a65 005b c1002a90 c1002aac 
00ce 002c 00ce 
Oct  7 11:50:47 localhost kernel:002b  0003 c0126042 c01278cb 
c0126229  0004 
Oct  7 11:50:47 localhost kernel:   0004  
 c0126870 0004 
Oct  7 11:50:47 localhost kernel: Call Trace: [tvecs+8671/55752] [tvecs+9165/55752] 
[page_launder+674/1888] [__free_pages+19/20] [page_launder+1161/1888] 
[do_try_to_free_pages+52/128] [tvecs+7999/55752] 
Oct  7 11:50:47 localhost kernel:[kswapd+115/288] [kernel_thread+40/56] 
Oct  7 11:50:47 localhost kernel: Code: 0f 0b 83 c4 0c 89 f6 89 da 2b 15 f8 89 26 c0 
89 d0 c1 e0 04 

Oct  7 11:50:51 localhost kernel: kernel BUG at vmscan.c:538!
Oct  7 11:50:51 localhost kernel: invalid operand: 
Oct  7 11:50:51 localhost kernel: CPU:0
Oct  7 11:50:51 localhost kernel: EIP:0010:[reclaim_page+897/980]
Oct  7 11:50:51 localhost kernel: EFLAGS: 00010282
Oct  7 11:50:51 localhost kernel: eax: 001c   ebx: c1002aac   ecx: c1636000   edx: 
0010
Oct  7 11:50:51 localhost kernel: esi: c1002a90   edi:    ebp: 0040   esp: 
c1637e3c
Oct  7 11:50:51 localhost kernel: ds: 0018   es: 0018   ss: 0018
Oct  7 11:50:51 localhost kernel: Process cc1 (pid: 2614, stackpage=c1637000)
Oct  7 11:50:51 localhost kernel: Stack: c01d4277 c01d4456 021a c020bb20 c020bdb4 
  c0127548 
Oct  7 11:50:51 localhost kernel:c020bb20  c020bdb8 0001  
c0127702 c020bdac  
Oct  7 11:50:51 localhost kernel: 0001 1000 c03a7d60 0001 
c04fe080 0007a746 0005 
Oct  7 11:50:51 localhost kernel: Call Trace: [tvecs+7135/55752] [tvecs+7614/55752] 
[__alloc_pages_limit+124/172] [__alloc_pages+394/756] [do_anonymous_page+57/160] 
[do_no_page+48/192] [handle_mm_fault+232/340] 
Oct  7 11:50:51 localhost kernel:[do_page_fault+299/976] 
[merge_segments+324/364] [do_brk+267/316] [sys_brk+180/216] [error_code+44/64] 
Oct  7 11:50:51 localhost kernel: Code: 0f 0b 83 c4 0c 31 c0 0f b3 46 18 8d 4e 28 8d 
46 2c 39 46 2c 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[OOPS][BUG] with 2.4.0-test9

[Richard Guenther]

Hi!

The following BUG related oopses caused my machine to die (well, X didnt
survive...) while just compiling a little program. I dont know if these
issues are fixed yet within one of the floating patches, so here goes the
report (dmesg stripped a little).

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/


Oct  7 11:19:40 localhost kernel: Linux version 2.4.0-test9 (root@mickey) (gcc version 
2.95.2 2220 (Debian GNU/Linux)) #15 Mit Okt 4 19:23:28 CEST 2000
Oct  7 11:19:40 localhost kernel: On node 0 totalpages: 8192
Oct  7 11:19:40 localhost kernel: zone(0): 4096 pages.
Oct  7 11:19:40 localhost kernel: zone(1): 4096 pages.
Oct  7 11:19:40 localhost kernel: zone(2): 0 pages.
Oct  7 11:19:40 localhost kernel: Initializing CPU#0
Oct  7 11:19:40 localhost kernel: Detected 99.475 MHz processor.
Oct  7 11:19:40 localhost kernel: Memory: 30304k/32768k available (1059k kernel code, 
2080k reserved, 81k data, 188k init, 0k highmem)
Oct  7 11:19:40 localhost kernel: Dentry-cache hash table entries: 4096 (order: 3, 
32768 bytes)
Oct  7 11:19:40 localhost kernel: Buffer-cache hash table entries: 1024 (order: 0, 
4096 bytes)
Oct  7 11:19:40 localhost kernel: Page-cache hash table entries: 8192 (order: 3, 32768 
bytes)
Oct  7 11:19:40 localhost kernel: Inode-cache hash table entries: 2048 (order: 2, 
16384 bytes)
Oct  7 11:19:40 localhost kernel: CPU: Intel Pentium 75 - 200 stepping 05
Oct  7 11:19:40 localhost kernel: Linux video capture interface: v1.00
Oct  7 11:19:40 localhost kernel: Uniform Multi-Platform E-IDE driver Revision: 6.31
Oct  7 11:19:40 localhost kernel: ide: Assuming 33MHz system bus speed for PIO modes; 
override with idebus=xx
Oct  7 11:19:40 localhost kernel: PIIX: IDE controller on PCI bus 00 dev 38
Oct  7 11:19:40 localhost kernel: PIIX: chipset revision 2
Oct  7 11:19:40 localhost kernel: Real Time Clock Driver v1.10c
Oct  7 11:19:40 localhost kernel: SCSI subsystem driver Revision: 1.00
Oct  7 11:19:40 localhost kernel: sym53c8xx: at PCI bus 0, device 9, function 0
Oct  7 11:19:40 localhost kernel: Soundblaster audio driver Copyright (C) by Hannu 
Savolainen 1993-1996
Oct  7 11:19:40 localhost kernel:  at 0x220 irq 5 dma 1,5
Oct  7 11:19:40 localhost kernel: Adding Swap: 98780k swap-space (priority -1)
Oct  7 11:39:38 localhost -- MARK --
Oct  7 11:50:47 localhost kernel: kernel BUG at page_alloc.c:91!
Oct  7 11:50:47 localhost kernel: invalid operand: 
Oct  7 11:50:47 localhost kernel: CPU:0
Oct  7 11:50:47 localhost kernel: EIP:0010:[__free_pages_ok+73/892]
Oct  7 11:50:47 localhost kernel: EFLAGS: 00010286
Oct  7 11:50:47 localhost kernel: eax: 001f   ebx: c1002a90   ecx: c10a4000   edx: 

Oct  7 11:50:47 localhost kernel: esi: c1002aac   edi:    ebp: 002c   esp: 
c10a5f64
Oct  7 11:50:47 localhost kernel: ds: 0018   es: 0018   ss: 0018
Oct  7 11:50:47 localhost kernel: Process kswapd (pid: 2, stackpage=c10a5000)
Oct  7 11:50:47 localhost kernel: Stack: c01d4877 c01d4a65 005b c1002a90 c1002aac 
00ce 002c 00ce 
Oct  7 11:50:47 localhost kernel:002b  0003 c0126042 c01278cb 
c0126229  0004 
Oct  7 11:50:47 localhost kernel:   0004  
 c0126870 0004 
Oct  7 11:50:47 localhost kernel: Call Trace: [tvecs+8671/55752] [tvecs+9165/55752] 
[page_launder+674/1888] [__free_pages+19/20] [page_launder+1161/1888] 
[do_try_to_free_pages+52/128] [tvecs+7999/55752] 
Oct  7 11:50:47 localhost kernel:[kswapd+115/288] [kernel_thread+40/56] 
Oct  7 11:50:47 localhost kernel: Code: 0f 0b 83 c4 0c 89 f6 89 da 2b 15 f8 89 26 c0 
89 d0 c1 e0 04 
Oct  7 11:50:51 localhost kernel: kernel BUG at vmscan.c:538!
Oct  7 11:50:51 localhost kernel: invalid operand: 
Oct  7 11:50:51 localhost kernel: CPU:0
Oct  7 11:50:51 localhost kernel: EIP:0010:[reclaim_page+897/980]
Oct  7 11:50:51 localhost kernel: EFLAGS: 00010282
Oct  7 11:50:51 localhost kernel: eax: 001c   ebx: c1002aac   ecx: c1636000   edx: 
0010
Oct  7 11:50:51 localhost kernel: esi: c1002a90   edi:    ebp: 0040   esp: 
c1637e3c
Oct  7 11:50:51 localhost kernel: ds: 0018   es: 0018   ss: 0018
Oct  7 11:50:51 localhost kernel: Process cc1 (pid: 2614, stackpage=c1637000)
Oct  7 11:50:51 localhost kernel: Stack: c01d4277 c01d4456 021a c020bb20 c020bdb4 
  c0127548 
Oct  7 11:50:51 localhost kernel:c020bb20  c020bdb8 0001  
c0127702 c020bdac  
Oct  7 11:50:51 localhost kernel: 0001 1000 c03a7d60 0001 
c04fe080 0007a746 0005 
Oct  7 11:50:51 localhost kernel: Call Trace: [tvecs+7135/55752] [tvecs+7614/55752] 
[__alloc_pages_limit+124/172] [__alloc_pages+394/756] [do_anonymous_page+57/160] 
[do_no_page+48/192] [handle_mm_fault+232/340] 
Oct  7 11:50:51 localhost kernel:[do_page_fault+2

[OOPS][BUG] with 2.4.0-test9

[Richard Guenther]

Hi!

The following BUG related oopses caused my machine to die (well, X didnt
survive...) while just compiling a little program. I dont know if these
issues are fixed yet within one of the floating patches, so here goes the
report (dmesg stripped a little).

Richard.

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/


Oct  7 11:19:40 localhost kernel: Linux version 2.4.0-test9 (root@mickey) (gcc version 
2.95.2 2220 (Debian GNU/Linux)) #15 Mit Okt 4 19:23:28 CEST 2000
Oct  7 11:19:40 localhost kernel: On node 0 totalpages: 8192
Oct  7 11:19:40 localhost kernel: zone(0): 4096 pages.
Oct  7 11:19:40 localhost kernel: zone(1): 4096 pages.
Oct  7 11:19:40 localhost kernel: zone(2): 0 pages.
Oct  7 11:19:40 localhost kernel: Initializing CPU#0
Oct  7 11:19:40 localhost kernel: Detected 99.475 MHz processor.
Oct  7 11:19:40 localhost kernel: Memory: 30304k/32768k available (1059k kernel code, 
2080k reserved, 81k data, 188k init, 0k highmem)
Oct  7 11:19:40 localhost kernel: Dentry-cache hash table entries: 4096 (order: 3, 
32768 bytes)
Oct  7 11:19:40 localhost kernel: Buffer-cache hash table entries: 1024 (order: 0, 
4096 bytes)
Oct  7 11:19:40 localhost kernel: Page-cache hash table entries: 8192 (order: 3, 32768 
bytes)
Oct  7 11:19:40 localhost kernel: Inode-cache hash table entries: 2048 (order: 2, 
16384 bytes)
Oct  7 11:19:40 localhost kernel: CPU: Intel Pentium 75 - 200 stepping 05
Oct  7 11:19:40 localhost kernel: Linux video capture interface: v1.00
Oct  7 11:19:40 localhost kernel: Uniform Multi-Platform E-IDE driver Revision: 6.31
Oct  7 11:19:40 localhost kernel: ide: Assuming 33MHz system bus speed for PIO modes; 
override with idebus=xx
Oct  7 11:19:40 localhost kernel: PIIX: IDE controller on PCI bus 00 dev 38
Oct  7 11:19:40 localhost kernel: PIIX: chipset revision 2
Oct  7 11:19:40 localhost kernel: Real Time Clock Driver v1.10c
Oct  7 11:19:40 localhost kernel: SCSI subsystem driver Revision: 1.00
Oct  7 11:19:40 localhost kernel: sym53c8xx: at PCI bus 0, device 9, function 0
Oct  7 11:19:40 localhost kernel: Soundblaster audio driver Copyright (C) by Hannu 
Savolainen 1993-1996
Oct  7 11:19:40 localhost kernel: Sound Blaster 16 (4.13) at 0x220 irq 5 dma 1,5
Oct  7 11:19:40 localhost kernel: Adding Swap: 98780k swap-space (priority -1)
Oct  7 11:39:38 localhost -- MARK --
Oct  7 11:50:47 localhost kernel: kernel BUG at page_alloc.c:91!
Oct  7 11:50:47 localhost kernel: invalid operand: 
Oct  7 11:50:47 localhost kernel: CPU:0
Oct  7 11:50:47 localhost kernel: EIP:0010:[__free_pages_ok+73/892]
Oct  7 11:50:47 localhost kernel: EFLAGS: 00010286
Oct  7 11:50:47 localhost kernel: eax: 001f   ebx: c1002a90   ecx: c10a4000   edx: 

Oct  7 11:50:47 localhost kernel: esi: c1002aac   edi:    ebp: 002c   esp: 
c10a5f64
Oct  7 11:50:47 localhost kernel: ds: 0018   es: 0018   ss: 0018
Oct  7 11:50:47 localhost kernel: Process kswapd (pid: 2, stackpage=c10a5000)
Oct  7 11:50:47 localhost kernel: Stack: c01d4877 c01d4a65 005b c1002a90 c1002aac 
00ce 002c 00ce 
Oct  7 11:50:47 localhost kernel:002b  0003 c0126042 c01278cb 
c0126229  0004 
Oct  7 11:50:47 localhost kernel:   0004  
 c0126870 0004 
Oct  7 11:50:47 localhost kernel: Call Trace: [tvecs+8671/55752] [tvecs+9165/55752] 
[page_launder+674/1888] [__free_pages+19/20] [page_launder+1161/1888] 
[do_try_to_free_pages+52/128] [tvecs+7999/55752] 
Oct  7 11:50:47 localhost kernel:[kswapd+115/288] [kernel_thread+40/56] 
Oct  7 11:50:47 localhost kernel: Code: 0f 0b 83 c4 0c 89 f6 89 da 2b 15 f8 89 26 c0 
89 d0 c1 e0 04 
Oct  7 11:50:51 localhost kernel: kernel BUG at vmscan.c:538!
Oct  7 11:50:51 localhost kernel: invalid operand: 
Oct  7 11:50:51 localhost kernel: CPU:0
Oct  7 11:50:51 localhost kernel: EIP:0010:[reclaim_page+897/980]
Oct  7 11:50:51 localhost kernel: EFLAGS: 00010282
Oct  7 11:50:51 localhost kernel: eax: 001c   ebx: c1002aac   ecx: c1636000   edx: 
0010
Oct  7 11:50:51 localhost kernel: esi: c1002a90   edi:    ebp: 0040   esp: 
c1637e3c
Oct  7 11:50:51 localhost kernel: ds: 0018   es: 0018   ss: 0018
Oct  7 11:50:51 localhost kernel: Process cc1 (pid: 2614, stackpage=c1637000)
Oct  7 11:50:51 localhost kernel: Stack: c01d4277 c01d4456 021a c020bb20 c020bdb4 
  c0127548 
Oct  7 11:50:51 localhost kernel:c020bb20  c020bdb8 0001  
c0127702 c020bdac  
Oct  7 11:50:51 localhost kernel: 0001 1000 c03a7d60 0001 
c04fe080 0007a746 0005 
Oct  7 11:50:51 localhost kernel: Call Trace: [tvecs+7135/55752] [tvecs+7614/55752] 
[__alloc_pages_limit+124/172] [__alloc_pages+394/756] [do_anonymous_page+57/160] 
[do_no_page+48/192] [handle_mm_fault+232/340] 
Oct  7 11:50:51 localhost kernel

sound related OOPS (2.4.0-test9-pre7)

[Richard Guenther]

Hi!

I got the following oopses while issuing the module-load
triggering (no modules loaded before, but sound-core compiled
into the kernel):

richard> aumix

See below for decoded oops and config/versions - also for
a second, but probably "ghost" oops on a
# cat /proc/ioports
(I checked completely compiled in sound and this works
just fine - machine is a Pentium100, non-pnp AWE32, isa-pnp
ne2k (but not activated))

No modules in ksyms, skipping objects

Sep 30 21:43:37 localhost kernel: isapnp: Scanning for Pnp cards...
Sep 30 21:43:37 localhost kernel: isapnp: Card 'PLUG & PLAY ETHERNET CARD'
Sep 30 21:43:37 localhost kernel: isapnp: 1 Plug & Play card detected total
Sep 30 21:43:37 localhost kernel: Soundblaster audio driver Copyright (C) by Hannu 
Savolainen 1993-1996
Sep 30 21:43:37 localhost kernel: sb: No ISAPnP cards found, trying standard ones...
Sep 30 21:43:37 localhost kernel: SB 4.13 detected OK (220)
Sep 30 21:43:37 localhost kernel:  at 0x220 irq 5 dma 1,5
Sep 30 21:43:37 localhost kernel:  at 0x330 irq 5 dma 0,0
Sound: Hmm, DMA1 was left allocated - fixed
Sound: Hmm, DMA5 was left allocated - fixed
Sep 30 21:43:37 localhost kernel: sb: I/O region in use.
Sep 30 21:43:37 localhost kernel:  printing eip:
Sep 30 21:43:37 localhost kernel: c0187903
Sep 30 21:43:37 localhost kernel: Oops: 
Sep 30 21:43:37 localhost kernel: CPU:0
Sep 30 21:43:37 localhost kernel: EIP:0010:[soundcore_open+191/396]
Sep 30 21:43:37 localhost kernel: EFLAGS: 00010282
Sep 30 21:43:37 localhost kernel: eax: c28260e0   ebx: c1e20ea0   ecx:    edx: 

Sep 30 21:43:37 localhost kernel: esi: c0cb3f1c   edi:    ebp:    esp: 
c0cb3f08
Sep 30 21:43:37 localhost kernel: ds: 0018   es: 0018   ss: 0018
Sep 30 21:43:37 localhost kernel: Process aumix (pid: 312, stackpage=c0cb3000)
Sep 30 21:43:37 localhost kernel: Stack:  c0300e60 c0c8fb40 c10c71a0  
6e756f73 65732d64 63697672 
Sep 30 21:43:37 localhost kernel:2d302d65 c0130030 001d c0c8fb40 ffeb 
c012b195 c0c8fb40 c0300e60 
Sep 30 21:43:37 localhost kernel:c0300e60 c0c8fb40  c012a3b0 c0c8fb40 
c0300e60 0002  
Sep 30 21:43:37 localhost kernel: Call Trace: [copy_mount_options+12/160] 
[chrdev_open+65/84] [dentry_open+192/332] [filp_open+74/84] [sys_open+56/180] 
[system_call+51/64] 
Sep 30 21:43:37 localhost kernel: Code: 8b 10 85 d2 74 17 52 e8 79 dd f8 ff 83 c4 04 
85 c0 74 0e 8b 

Code:   Before first symbol <_IP>: <===
Code:   Before first symbol   0:8b 10   mov
(%eax),%edx <===
Code:  0002 Before first symbol   2:85 d2   test   
%edx,%edx
Code:  0004 Before first symbol   4:74 17   je 
 001d Before first symbol
Code:  0006 Before first symbol   6:52  push   
%edx
Code:  0007 Before first symbol   7:e8 79 dd f8 ff  call   
 fff8dd85 
Code:  000c Before first symbol   c:83 c4 04add
$0x4,%esp
Code:  000f Before first symbol   f:85 c0   test   
%eax,%eax
Code:  0011 Before first symbol  11:74 0e   je 
 0021 Before first symbol
Code:  0013 Before first symbol  13:8b 00   mov
(%eax),%eax


Now trying to figure out what is going on:
# cat /proc/ioports

Sep 30 21:54:28 localhost kernel: c01ba395
Sep 30 21:54:28 localhost kernel: Oops: 
Sep 30 21:54:28 localhost kernel: CPU:0
Sep 30 21:54:28 localhost kernel: EIP:0010:[vsprintf+425/844]
Sep 30 21:54:28 localhost kernel: EFLAGS: 00010297
Sep 30 21:54:28 localhost kernel: eax: c2830f94   ebx: c07ee0ea   ecx: c2830f94   edx: 
fffe
Sep 30 21:54:28 localhost kernel: esi:    edi: c123df18   ebp:    esp: 
c123ded4
Sep 30 21:54:28 localhost kernel: ds: 0018   es: 0018   ss: 0018
Sep 30 21:54:28 localhost kernel: Process cat (pid: 459, stackpage=c123d000)
Sep 30 21:54:28 localhost kernel: Stack: c07ee0de c1e20e80 0008 c07ef000 fffd 
 000a c01ba54c 
Sep 30 21:54:28 localhost kernel:c07ee0de c01c3638 c123df0c c01183da c07ee0de 
c01c3629 0220 022f 
Sep 30 21:54:28 localhost kernel:c2830f94 c07ee000  c07ee000 1000 
c011843c c01f7900 c01c3621 
Sep 30 21:54:28 localhost kernel: Call Trace: [sprintf+20/5592] 
[IRQ0x0f_interrupt+19144/21320] [do_resource_list+74/124] 
[IRQ0x0f_interrupt+19129/21320] [] [get_resource_list+48/56] 
[IRQ0x0f_interrupt+19121/21320] 
Sep 30 21:54:28 localhost kernel: Code: 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 8b 
54 24 14 89 c6 

Code:   Before first symbol <_IP>: <===
Code:   Before first symbol   0:80 38 00cmpb   
$0x0,(%eax) <===
Code:  0003 Before first symbol   3:

sound related OOPS (2.4.0-test9-pre7)

[Richard Guenther]

Hi!

I got the following oopses while issuing the module-load
triggering (no modules loaded before, but sound-core compiled
into the kernel):

richard aumix

See below for decoded oops and config/versions - also for
a second, but probably "ghost" oops on a
# cat /proc/ioports
(I checked completely compiled in sound and this works
just fine - machine is a Pentium100, non-pnp AWE32, isa-pnp
ne2k (but not activated))

No modules in ksyms, skipping objects

Sep 30 21:43:37 localhost kernel: isapnp: Scanning for Pnp cards...
Sep 30 21:43:37 localhost kernel: isapnp: Card 'PLUG  PLAY ETHERNET CARD'
Sep 30 21:43:37 localhost kernel: isapnp: 1 Plug  Play card detected total
Sep 30 21:43:37 localhost kernel: Soundblaster audio driver Copyright (C) by Hannu 
Savolainen 1993-1996
Sep 30 21:43:37 localhost kernel: sb: No ISAPnP cards found, trying standard ones...
Sep 30 21:43:37 localhost kernel: SB 4.13 detected OK (220)
Sep 30 21:43:37 localhost kernel: Sound Blaster 16 (4.13) at 0x220 irq 5 dma 1,5
Sep 30 21:43:37 localhost kernel: Sound Blaster 16 at 0x330 irq 5 dma 0,0
Sound: Hmm, DMA1 was left allocated - fixed
Sound: Hmm, DMA5 was left allocated - fixed
Sep 30 21:43:37 localhost kernel: sb: I/O region in use.
Sep 30 21:43:37 localhost kernel:  printing eip:
Sep 30 21:43:37 localhost kernel: c0187903
Sep 30 21:43:37 localhost kernel: Oops: 
Sep 30 21:43:37 localhost kernel: CPU:0
Sep 30 21:43:37 localhost kernel: EIP:0010:[soundcore_open+191/396]
Sep 30 21:43:37 localhost kernel: EFLAGS: 00010282
Sep 30 21:43:37 localhost kernel: eax: c28260e0   ebx: c1e20ea0   ecx:    edx: 

Sep 30 21:43:37 localhost kernel: esi: c0cb3f1c   edi:    ebp:    esp: 
c0cb3f08
Sep 30 21:43:37 localhost kernel: ds: 0018   es: 0018   ss: 0018
Sep 30 21:43:37 localhost kernel: Process aumix (pid: 312, stackpage=c0cb3000)
Sep 30 21:43:37 localhost kernel: Stack:  c0300e60 c0c8fb40 c10c71a0  
6e756f73 65732d64 63697672 
Sep 30 21:43:37 localhost kernel:2d302d65 c0130030 001d c0c8fb40 ffeb 
c012b195 c0c8fb40 c0300e60 
Sep 30 21:43:37 localhost kernel:c0300e60 c0c8fb40  c012a3b0 c0c8fb40 
c0300e60 0002  
Sep 30 21:43:37 localhost kernel: Call Trace: [copy_mount_options+12/160] 
[chrdev_open+65/84] [dentry_open+192/332] [filp_open+74/84] [sys_open+56/180] 
[system_call+51/64] 
Sep 30 21:43:37 localhost kernel: Code: 8b 10 85 d2 74 17 52 e8 79 dd f8 ff 83 c4 04 
85 c0 74 0e 8b 

Code:   Before first symbol _IP: ===
Code:   Before first symbol   0:8b 10   mov
(%eax),%edx ===
Code:  0002 Before first symbol   2:85 d2   test   
%edx,%edx
Code:  0004 Before first symbol   4:74 17   je 
 001d Before first symbol
Code:  0006 Before first symbol   6:52  push   
%edx
Code:  0007 Before first symbol   7:e8 79 dd f8 ff  call   
 fff8dd85 END_OF_CODE+3fd2f535/
Code:  000c Before first symbol   c:83 c4 04add
$0x4,%esp
Code:  000f Before first symbol   f:85 c0   test   
%eax,%eax
Code:  0011 Before first symbol  11:74 0e   je 
 0021 Before first symbol
Code:  0013 Before first symbol  13:8b 00   mov
(%eax),%eax


Now trying to figure out what is going on:
# cat /proc/ioports

Sep 30 21:54:28 localhost kernel: c01ba395
Sep 30 21:54:28 localhost kernel: Oops: 
Sep 30 21:54:28 localhost kernel: CPU:0
Sep 30 21:54:28 localhost kernel: EIP:0010:[vsprintf+425/844]
Sep 30 21:54:28 localhost kernel: EFLAGS: 00010297
Sep 30 21:54:28 localhost kernel: eax: c2830f94   ebx: c07ee0ea   ecx: c2830f94   edx: 
fffe
Sep 30 21:54:28 localhost kernel: esi:    edi: c123df18   ebp:    esp: 
c123ded4
Sep 30 21:54:28 localhost kernel: ds: 0018   es: 0018   ss: 0018
Sep 30 21:54:28 localhost kernel: Process cat (pid: 459, stackpage=c123d000)
Sep 30 21:54:28 localhost kernel: Stack: c07ee0de c1e20e80 0008 c07ef000 fffd 
 000a c01ba54c 
Sep 30 21:54:28 localhost kernel:c07ee0de c01c3638 c123df0c c01183da c07ee0de 
c01c3629 0220 022f 
Sep 30 21:54:28 localhost kernel:c2830f94 c07ee000  c07ee000 1000 
c011843c c01f7900 c01c3621 
Sep 30 21:54:28 localhost kernel: Call Trace: [sprintf+20/5592] 
[IRQ0x0f_interrupt+19144/21320] [do_resource_list+74/124] 
[IRQ0x0f_interrupt+19129/21320] [c2830f94] [get_resource_list+48/56] 
[IRQ0x0f_interrupt+19121/21320] 
Sep 30 21:54:28 localhost kernel: Code: 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 8b 
54 24 14 89 c6 

Code:   Before first symbol _IP: ===
Code:   Before first symbol   0:80 38 00cmpb   
$0x0,(%eax) 

Re: [RFC] Wine speedup through kernel module

[Richard Guenther]

On Tue, 12 Sep 2000, David Howells wrote:

> 
> I think now that I'm probably best providing a generic pluggable syscall
> handler, one that is very careful to make sure the syscall can't be entered
> whilst the module is being unloaded.
> 

Whats the problem with just not allowing the module to unload at all?
Whats the point in unloading a module anyways. Ok, I know - debugging,
etc. - but for a "release" version this is not important. Also upgrading -
but for desktop boxes (for which this wine stuff is) rebooting seems
appropriate here, too.

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [RFC] Wine speedup through kernel module

[Richard Guenther]

On Tue, 12 Sep 2000, David Howells wrote:

 
 I think now that I'm probably best providing a generic pluggable syscall
 handler, one that is very careful to make sure the syscall can't be entered
 whilst the module is being unloaded.
 

Whats the problem with just not allowing the module to unload at all?
Whats the point in unloading a module anyways. Ok, I know - debugging,
etc. - but for a "release" version this is not important. Also upgrading -
but for desktop boxes (for which this wine stuff is) rebooting seems
appropriate here, too.

Richard.

--
Richard Guenther [EMAIL PROTECTED]
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/