PROBLEM: 2.4.19-pre10-ac2 bug in page_alloc.c:131
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 13 lines · Markus Schoder
Hi Alexandre,
you are using the proprietary nVidia module (NVdriver), so you would have to address any kernel problems to nVidia since they are the ones who have the source.
However lots of people (including myself) have seen the same problem when using the nVidia module. For me it went away when upgrading to the 1.0-2960 drivers. If you haven't done so yet this would be the first thing to try.
Hope this helps,
Markus
I'm already using the 1.0-2960 version, and that's the version in the report. It's possible that the NVdriver module is the cause of the problem, but the bug spots in kernel's vm, in a place which it's no supposed to, at the point I understand. So, or the module does something very ugly, or the kernel really have a bug, or yet it's nothing related to the nvdriver. Unfortunately, the backtrace don't help me figuring that out, since I'm no vm expert, but perhaps someone will. I may attempt to forward this to Nvidia folks, but reporting a bug which only spotted once and in a "pre" series kernel may hurt their feelings...
Thanks,
Alexandre
Quoted 8 lines
report. It's possible that the NVdriver module is the cause of the problem, but the bug spots in kernel's vm, in a place which it's no supposed to, at the point I understand. So, or the module does something very ugly, or the kernel really have a bug, or yet it's nothing related to the nvdriver. Unfortunately, the backtrace don't help me figuring that out, since I'm no vm expert, but perhaps someone will. I may attempt to forward this to Nvidia folks, but reporting a bug which only spotted once and in a "pre" series kernel may hurt their feelings...
Their problem - they have our source we dont have theirs. If it occurs with nvdriver ever loaded in that boot send it to nvidia or duplicate it from a cold boot without the driver ever loadinhg
Quoted 9 lines · Alan Cox
Quoted 3 lines
report. It's possible that the NVdriver module is the cause of the problem, but the bug spots in kernel's vm, in a place which it's no supposed to, at the point I understand. So, or the module does something very ugly, or the kernel really have a bug, or yet it's nothing related to the nvdriver. Unfortunately, the backtrace don't help me figuring that out, since I'm no vm expert, but perhaps someone will. I may attempt to forward this to Nvidia folks, but reporting a bug which only spotted once and in a "pre" series kernel may hurt their feelings...
Their problem - they have our source we dont have theirs. If it occurs with nvdriver ever loaded in that boot send it to nvidia or duplicate it from a cold boot without the driver ever loadinhg
I sent an email to they.
I'm not able to try to reproduce it either with or without the module loaded, since I have no access to the machine in question right now. In the case I can, maybe I'll try to do it. Since it just happened once, after I happened to get with swap pratically full, I guess that would be hard (there was no OOM reporting from the kernel, though).
Maybe I got it the wrong way, but it seems to me that from your point of view, as long as proprietary driver is in use, it's not anyone else problem but to the vendor, even if the bug could happen to be in the kernel, is that right? If so, everyone else in this list who could try to fix this (again assuming it could be something related to the kernel and not to the proprietary driver) necessarily share your oppinion? (I'm not flaming in here, just trying to get the path).
Thank you,
Alexandre
From: "Alexandre P. Nunes" <[email protected]>
Date: Mon, 24 Jun 2002 12:06:32 -0300
Maybe I got it the wrong way, but it seems to me that from your point of view, as long as proprietary driver is in use, it's not anyone else problem but to the vendor, even if the bug could happen to be in the kernel, is that right? If so, everyone else in this list who could try to fix this (again assuming it could be something related to the kernel and not to the proprietary driver) necessarily share your oppinion? (I'm not flaming in here, just trying to get the path).
This has to do with facts, not opinions. Since we lack the source to their drivers, we have no idea if some bug in their driver is scribbling over (ie. corrupting) memory. It is therefore an unknown which makes it a waste of time for us to pursue the bug report.
Quoted 11 lines · David S. Miller
From: "Alexandre P. Nunes" <[email protected]>
Date: Mon, 24 Jun 2002 12:06:32 -0300Maybe I got it the wrong way, but it seems to me that from your point of view, as long as proprietary driver is in use, it's not anyone else problem but to the vendor, even if the bug could happen to be in the kernel, is that right? If so, everyone else in this list who could try to fix this (again assuming it could be something related to the kernel and not to the proprietary driver) necessarily share your oppinion? (I'm not flaming in here, just trying to get the path).
Quoted 6 lines
This has to do with facts, not opinions. Since we lack the source to their drivers, we have no idea if some bug in their driver is scribbling over (ie. corrupting) memory. It is therefore an unknown which makes it a waste of time for us to pursue the bug report.
Thanks, now with your report (and in fact Zwane's one, which cleared the fact this bug scenario have been seen before) it's all clear to me. I don't subscribe to nor used to read this list archives, so I couldn't take a better picture and guess without actually someone pointing this out.
I'll direct the pressure all over nvidia, and in mean time I'll read the relevant articles in the archives, which seems the way to avoid unnecessary redundancy ...
Sorry folks if I bothered too much, I'll try avoid that :-)
Thanks for all of you,
Alexandre
Hi!
Quoted 8 lines
Maybe I got it the wrong way, but it seems to me that from your point of view, as long as proprietary driver is in use, it's not anyone else problem but to the vendor, even if the bug could happen to be in the kernel, is that right? If so, everyone else in this list who could try to fix this (again assuming it could be something related to the kernel and not to the proprietary driver) necessarily share your oppinion? (I'm not flaming in here, just trying to get the path).
Quoted 4 lines
This has to do with facts, not opinions. Since we lack the source to their drivers, we have no idea if some bug in their driver is scribbling over (ie. corrupting) memory. It is therefore an unknown which makes it a waste of time for us to pursue the bug report.
Actually, then you should taint kernel for starting X, too... Anything running with root priviledges can scribble over memory.
Pavel
PS: Not that I'm advocating nvidia junk, and of course it is way easier to cause corruption from kernel.
Signature · 2 lines
(about SSSCA) "I don't say this lightly. However, I really think that the U.S. no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
Pavel Machek <[email protected]> said:
[...]
Quoted 2 lines
Actually, then you should taint kernel for starting X, too... Anything running with root priviledges can scribble over memory.
Come on, a wild pointer in a random program running as root won't ever bring the kernel down, as a wild pointer in a module certainly can/will. --
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
Quoted 4 lines · David S. Miller
This has to do with facts, not opinions. Since we lack the source to their drivers, we have no idea if some bug in their driver is scribbling over (ie. corrupting) memory. It is therefore an unknown which makes it a waste of time for us to pursue the bug report.
By that logic if source is freely available the kernel should not be marked tainted, even if the source license is not GPL, as in you can get it and use it to debug, but the license is something like BSD, or the Kermit limited redistribution, etc.
I'm asking in general, not about just one particular binary-only driver.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 11 lines · Bill Davidsen
Quoted 6 lines · David S. Miller
This has to do with facts, not opinions. Since we lack the source to their drivers, we have no idea if some bug in their driver is scribbling over (ie. corrupting) memory. It is therefore an unknown which makes it a waste of time for us to pursue the bug report.
Quoted 9 lines
By that logic if source is freely available the kernel should not be marked tainted, even if the source license is not GPL, as in you can get it and use it to debug, but the license is something like BSD, or the Kermit limited redistribution, etc.
I'm asking in general, not about just one particular binary-only driver.
How this taint stuff works, actually ? It's just a marker or it impose any restrictions?
While I made all efforts to send nvidia all information pertinent to the reported bug, I also found that the source to o/s dependent parts are in fact (at least partially) available, with an absurdly restrictive license, though. If someone else is interested in looking at, one of the files in the distribution contains the mm code and all general interfacing to the kernel.
I agree it's nvidia responsability for checking its own source, but help is always welcome when it's true help after all.
In last weekend I patched 2.4.19-pre10-ac2 with the last preempt-kernel patch, and since I was unable to reproduce the crash, though I didn't stress the machine enough by lack of time, so it's just informative report in case someone want to try.
Cheers,
Alexandre
Quoted 10 lines · Alexandre P. Nunes
How this taint stuff works, actually ? It's just a marker or it impose any restrictions?
While I made all efforts to send nvidia all information pertinent to the reported bug, I also found that the source to o/s dependent parts are in fact (at least partially) available, with an absurdly restrictive license, though. If someone else is interested in looking at, one of the files in the distribution contains the mm code and all general interfacing to the kernel.
Quoted 7 lines
I agree it's nvidia responsability for checking its own source, but help is always welcome when it's true help after all.
In last weekend I patched 2.4.19-pre10-ac2 with the last preempt-kernel patch, and since I was unable to reproduce the crash, though I didn't stress the machine enough by lack of time, so it's just informative report in case someone want to try.
I didn't get the start of this thread, but I have seen bugs at page_alloc.c:131 and :117 with a "stock" 2.4.19-pre10-ac2. It not really Alan's version because I have Chris Mason's reiserfs logging patches, a BSD super.c fix and the bridge-netfilter patch.
The bug usually strikes at shutdown of the X server, and I have yet to see this with the opensource nv X11 driver.
Is providing Nvidia with information do any good? Do they respond to bug reports and actually fix bugs? It might be that they just need to track new VM behaviour, but I can save the time of writing a bug report if it's either no good or if someone already did.
Signature · 1 line
Matthias Andree
Quoted 7 lines · Alexandre P. Nunes
Maybe I got it the wrong way, but it seems to me that from your point of view, as long as proprietary driver is in use, it's not anyone else problem but to the vendor, even if the bug could happen to be in the kernel, is that right? If so, everyone else in this list who could try to fix this (again assuming it could be something related to the kernel and not to the proprietary driver) necessarily share your oppinion? (I'm not flaming in here, just trying to get the path).
This particular one has cropped up a multitude of times, i can assure you that you're not the first. Try searching the archives for __free_pages_ok, nvidia and a few other keywords. I've seen that particular bug first hand and its definitely the work of the nvidia driver. Try their 2314 driver, i can't recall seeing it with that particular version.
Cheers,
Zwane
Signature · 1 line
http://function.linuxpower.ca