Hi Kostya, I had a similar experience and the problem was the SDRAM timing. This is set up not in the Linux but in the bootloader (U-boot or whatever)
If not the simplest way to find out which driver is incriminated is to unload it and to run the system for a while without it. It is lengthy, boring but works. Good luck, /st ________________________________ From: Konstantin Kalin <[EMAIL PROTECTED]> To: kernelnewbies <[email protected]> Sent: Monday, December 8, 2008 9:54:46 AM Subject: Kernel OOPss - corrupted memory Hello, I'd like to ask you an advice. Our production systems began experiencing kernel panics but the linux kernel wasn't changed for last 1.5 years. Also we didn't change drivers for last 0.5 years. I collected vmcores by netdump and investigated them. All panics are related to corrupted memory. We already changed motherboards on a few system experienced the issue but nothing changed. I think we changed user-space code and these changes lead to incorrect behavior of a few drivers. Is there any way to trace request to DMA memory to find "bad" driver? I have two proprietary drivers (AudioCodes and Dialogic) and I think they cause the issue, but I need a way to find which one causes and which changes provoke the driver. Because our system was working stable with the same drivers for long time. Thank you, Kostya. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ
