On Fri, Aug 04, 2006 at 12:36:52PM +0200, Loiseleur Michel wrote: > I work with a Red Hat AS kernel (2.6.9-11-smp) on a bi-proc AMD. Ask Red Hat for support. > I had a kernel panic this night, you will find an extract of the > /var/log/messages in the attached file. The server is a backup one, and > it was during really big batch processing. you will see too that's SMART > seems wrong, the hdds are not so hot. The temperature attribute doesn't have to tell the temperature in degrees Celcius (or Fahrenheit). There's sometimes a little calculation needed to get to something humans understand. hddtemp can do that for you. > I have looked at the code and all seems to be in fs/ext3. It "seems" > that during an " ext3_ordered_writepage", the fs tries to walk along the > page (walk_page_buffers) but he can't because the "page" is null. that's > what the trace told me. > > My first idea is to correct it with something like this : > if (!page) > goto out_fail; > > > But I feel that's not the good way or maybe my thought is wrong. Is > there an ext3 maintener in the plane ? :) There are, but... > Aug 4 01:08:09 ju kernel: Modules linked in: nfsd exportfs lockd sunrpc basp(U) md5 ipv6 i2c_dev i2c_core dm_mod button battery ac hw_random e1000 floppy ext3 jbd raid1 aic7xxx sd_mod scsi_mod > Aug 4 01:08:09 ju kernel: CPU: 0 > Aug 4 01:08:09 ju kernel: EIP: 0060:[<f891bc87>] Tainted: P VLI Your kernel is tainted by a proprietary module (I guess the "basp" module) so it's impossible to debug your problem. The only one able to debug your problem is the vendor of that proprietary module. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
