> 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.
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.
-- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/