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