From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261254AbVFBTTn (ORCPT ); Thu, 2 Jun 2005 15:19:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261255AbVFBTTm (ORCPT ); Thu, 2 Jun 2005 15:19:42 -0400 Received: from locomotive.csh.rit.edu ([129.21.60.149]:58398 "EHLO locomotive.unixthugs.org") by vger.kernel.org with ESMTP id S261254AbVFBTTV (ORCPT ); Thu, 2 Jun 2005 15:19:21 -0400 Message-ID: <429F5BB6.90301@suse.com> Date: Thu, 02 Jun 2005 15:19:18 -0400 From: Jeff Mahoney User-Agent: Mozilla Thunderbird 1.0 (X11/20041207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l0rd4gu1@icontrol.com.mx Cc: linux-kernel@vger.kernel.org Subject: Re: PROBLEM: doing a dd to a dbfile References: <1117673999.28282.2.camel@localhost> In-Reply-To: <1117673999.28282.2.camel@localhost> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ing. Raśl Alvarez Aguileta wrote: > Hi > > I've a corruption problem with one innodb file, when i'm trying to > recover a corrupted file (it's filled with no data at byte 524288+, but > it have valid info later [aprox 4mb ahead] ) with: > > # dd if=/dev/zero of=ibdata1 bs=1 seek=524288 count=4194304 conv=notrunc > > the command ends dumping the folllowing message: > > output from /var/log/messages > ----> > Jun 1 18:43:07 g4nd4lf Kernel BUG at file:534 > Jun 1 18:43:07 g4nd4lf invalid operand: 0000 [1] SMP > Jun 1 18:43:07 g4nd4lf CPU 0 > Jun 1 18:43:07 g4nd4lf Modules linked in: ipt_LOG ipt_state > iptable_filter ip_tables ip_conntrack_tftp ip_conntrack_irc > ip_conntrack_ftp ip_conntrack_amanda ip_conntrack amd74xx sd_mod aic79xx > mptctl mptscsih mptbase sata_sx4 sata_promise libata usb_storage > ide_core scsi_mod ohci_hcd uhci_hcd ehci_hcd usbcore > Jun 1 18:43:07 g4nd4lf Pid: 8993, comm: dd Not tainted 2.6.11-gentoo-r9 > Jun 1 18:43:07 g4nd4lf RIP: 0010:[] > {reiserfs_file_write+5298} > Jun 1 18:43:07 g4nd4lf RSP: 0018:ffff81007c273ba8 EFLAGS: 00010246 > Jun 1 18:43:08 g4nd4lf RAX: 0000000001000020 RBX: 0000000000000000 RCX: > 0000000000000001 > Jun 1 18:43:08 g4nd4lf RDX: ffff810002b04038 RSI: ffff81007c26e670 RDI: > ffff81007c273d98 > Jun 1 18:43:08 g4nd4lf RBP: ffff81007e8bbdf0 R08: 0000000000000000 R09: > ffff810002c13c80 > Jun 1 18:43:08 g4nd4lf R10: ffff81007fdd8ec0 R11: ffff81007e8bbdf0 R12: > 0000000000000001 > Jun 1 18:43:08 g4nd4lf R13: 0000000000000000 R14: ffff81007c26e670 R15: > ffff81007e8c0678 > Jun 1 18:43:08 g4nd4lf FS: 00002aaaaade7b00(0000) > GS:ffffffff803ed880(0000) knlGS:0000000000000000 > Jun 1 18:43:08 g4nd4lf CS: 0010 DS: 0000 ES: 0000 CR0: > 000000008005003b > Jun 1 18:43:08 g4nd4lf CR2: 00002aaaaac4d3e0 CR3: 000000007c267000 CR4: > 00000000000006e0 > Jun 1 18:43:08 g4nd4lf Process dd (pid: 8993, threadinfo > ffff81007c272000, task ffff81007f6fa1b0) > Jun 1 18:43:08 g4nd4lf Stack: 0000000000000286 ffff81000000d680 > 0000000000000000 ffff81007c26e730 > Jun 1 18:43:08 g4nd4lf 0000000100000000 000000000008cfff > 00000000000080d2 0000000000000000 > Jun 1 18:43:08 g4nd4lf 0000000000000000 0000000000000001 > Jun 1 18:43:08 g4nd4lf Call Trace:{buffered_rmqueue > +654} {do_no_page+939} > Jun 1 18:43:08 g4nd4lf {error_exit+0} > {inotify_inode_queue_event+47} > Jun 1 18:43:08 g4nd4lf {read_zero+480} > {vfs_write+233} > Jun 1 18:43:08 g4nd4lf {sys_write+83} > {system_call+126} > Jun 1 18:43:08 g4nd4lf > Jun 1 18:43:08 g4nd4lf > Jun 1 18:43:08 g4nd4lf Code: 0f 0b 8b f1 2d 80 ff ff ff ff 16 02 8b 02 > 4c 8b 42 10 f6 c4 > Jun 1 18:43:08 g4nd4lf RIP {reiserfs_file_write+5298} > RSP > <---- > > # sh /usr/src/linux/scripts/ver_linux > ----> > If some fields are empty or look unusual you may have an old version. > Compare to the current minimal requirements in Documentation/Changes. > > Linux g4nd4lf 2.6.11-gentoo-r9 #1 SMP Wed May 18 07:53:38 CDT 2005 > x86_64 AMD Opteron(tm) Processor 250 AuthenticAMD GNU/Linux Ok, this trace maps to page_buffers() in reiserfs_allocate_blocks_for_region(), specifically the BUG_ON (!PagePrivate(page)) check inside it. Somehow, the buffers associated with that page are getting freed, despite it being locked. Just to double check that the page it's checking is valid - could you post your vmlinux somewhere or send it to me off list? I'd like to check the Oops against the disassembly. - -Jeff - -- Jeff Mahoney SuSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCn1u2LPWxlyuTD7IRAtipAJ0dnkRURMCvDVi7BsqCLB3PKTRlXACfXXip nREAY313itZta85HPacCSKc= =4U9c -----END PGP SIGNATURE-----