On Sun, 2009-02-15 at 22:37 +0100, Jochen Becker wrote: > Package: linux-image-2.6.26-1-amd64 > Version: 2.6.26-13 > Severity: critical > Justification: breaks the whole system > > by copying data from one software raid device into annother a kernel panic comes up I'm sorry for the delay in answering your bug report. > newstorage > 2 harddiscs wdc 750 ayps combined with software raid 1 > into software raid lvm pv and into this ext3 filesystems > > old storage > 2 harddisks samsung 400 software raid1 into it ext3 file system nolvm > > copying data from old stroage to new storage failed > > i removed 2G memory so that there will be only 4 in the system and > mounted the old filesystem as ext2 > and everything works fine. Did you connect some of these disks using Firewire? [...] > -- Package-specific info: > ** Version: > Linux version 2.6.26-1-amd64 (Debian 2.6.26-13) (waldi@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-24)) #1 SMP Sat Jan 10 17:57:00 UTC 2009 > > ** Command line: > root=/dev/mapper/vgcamelot-lvmRoot ro quiet > > ** Tainted: P (1) The nvidia module may introduce bugs that we cannot investigate because we do not have its source. Can you test without it temporarily? [...] > [33414.290580] Call Trace: > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffffa019b3be>] :jbd:journal_dirty_data+0x31/0x184 > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffffa01abfbc>] > :ext3:ext3_journal_dirty_data+0xf/0x34 > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffffa01ab45a>] :ext3:walk_page_buffers+0x64/0x8a > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffffa01abfe1>] > :ext3:journal_dirty_data_fn+0x0/0xd > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffffa01ae159>] > :ext3:ext3_ordered_writepage+0xeb/0x16f > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffff8027709b>] __writepage+0xa/0x23 > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffff80277560>] write_cache_pages+0x182/0x2b1 > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffff80277091>] __writepage+0x0/0x23 > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffff80277091>] __writepage+0x0/0x23 > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffff802776d2>] do_writepages+0x27/0x2d > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffff802b64d4>] > __writeback_single_inode+0x144/0x29d > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffff80278d56>] pagevec_lookup_tag+0x1a/0x21 > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffff80271806>] > wait_on_page_writeback_range+0xc8/0x113 > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffff802b6998>] sync_sb_inodes+0x1b1/0x293 > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffff802b6b14>] sync_inodes_sb+0x9a/0xa6 > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffff802b6b79>] __sync_inodes+0x59/0xa2 > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffff802b6bd3>] sync_inodes+0x11/0x29 > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffff802b9426>] do_sync+0x12/0x5a > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffff802b947c>] sys_sync+0xe/0x16 > Feb 15 11:26:48 camelot kernel: [33414.290580] [<ffffffff8020beca>] system_call_after_swapgs+0x8a/0x8f Unfortunately there is not much we can do with just a call trace. We would need to see the full 'oops' message. Ben. -- Ben Hutchings I'm always amazed by the number of people who take up solipsism because they heard someone else explain it. - E*Borg on alt.fan.pratchett
Attachment:
signature.asc
Description: This is a digitally signed message part