From: Vladislav B. <vs...@vl...> - 2008-01-17 11:19:16
|
4n...@re...> wrote: > On mercoledì 16 gennaio 2008, Vladislav Bolkhovitin wrote: > >>cheng xu wrote: >> >>>im seeing irregular crashes with scst and LSI card (amd64bit) >>>the only output i can get is > > >>What kind of activity did you do before crash? > > > I all , tonoght at 4 oclock I've also a scst crash.... > > last operation is cron backup , using an lto tape on a lsi card.... > > so I think it can be same problem, I've update scst yesterday , from @239 to > @245 svn , at cron backup time I see that: > > > Jan 17 04:28:02 storage kernel: ------------[ cut here ]------------ > Jan 17 04:28:02 storage kernel: kernel BUG at lib/radix-tree.c:319! > Jan 17 04:28:02 storage kernel: invalid opcode: 0000 [1] SMP > Jan 17 04:28:02 storage kernel: CPU 1 > Jan 17 04:28:02 storage kernel: Modules linked in: nfsd exportfs lockd nfs_acl > auth_rpcgss ipv6 iscsi_scst qla2x00tgt scst_cdrom scst_changer scst_tape > scst_vdisk scst sunrpc bonding dm_multipath sbs battery backlight ac osst > qla2xxx i2c_i801 e1000 floppy sg i2c_core st scsi_transport_fc ide_cd button > cdrom dm_snapshot dm_zero dm_mirror dm_mod ide_disk ata_piix libata 3w_9xxx > mptspi mptscsih scsi_transport_spi mptbase sd_mod scsi_mod ext3 jbd > Jan 17 04:28:02 storage kernel: Pid: 9414, comm: tar Not tainted > 2.6.23.9-SAN21 #2 > Jan 17 04:28:02 storage kernel: RIP: 0010:[<ffffffff802dfe28>] > [<ffffffff802dfe28>] radix_tree_insert+0x152/0x18c > Jan 17 04:28:02 storage kernel: RSP: 0018:ffff8101010199c8 EFLAGS: 00010086 > Jan 17 04:28:02 storage kernel: RAX: 00000000ffffffff RBX: ffff810118f84de8 > RCX: 000000000004c900 > Jan 17 04:28:02 storage kernel: RDX: 0000000000000000 RSI: 000000000004c9e2 > RDI: ffff810118f84de8 > Jan 17 04:28:02 storage kernel: RBP: ffff8100ce697d40 R08: ffff81010271b408 > R09: ffff81010271b470 > Jan 17 04:28:02 storage kernel: R10: ffff81011fd85ac0 R11: ffff81010271b408 > R12: 0000000000000022 > Jan 17 04:28:02 storage kernel: R13: 0000000000000000 R14: 00000000fffffffa > R15: ffff8100043f2dc0 > Jan 17 04:28:02 storage kernel: FS: 00002ab3c30a7e10(0000) > GS:ffff81011fca9e40(0000) knlGS:0000000000000000 > Jan 17 04:28:02 storage kernel: CS: 0010 DS: 0000 ES: 0000 CR0: > 0000000080050033 > Jan 17 04:28:02 storage kernel: CR2: 00002b0ebd81d0a8 CR3: 0000000107996000 > CR4: 00000000000006e0 > Jan 17 04:28:02 storage kernel: DR0: 0000000000000000 DR1: 0000000000000000 > DR2: 0000000000000000 > Jan 17 04:28:02 storage kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 > DR7: 0000000000000400 > Jan 17 04:28:02 storage kernel: Process tar (pid: 9414, threadinfo > ffff810101018000, task ffff81011259d080) > Jan 17 04:28:02 storage kernel: Stack: 000000000004c9e2 ffff8100043f2dc0 > 0000000000000000 ffff810118f84de0 > Jan 17 04:28:02 storage kernel: 000000000004c9e2 ffffffff8801dabf > ffff810118f84de0 ffffffff802576b4 > Jan 17 04:28:02 storage kernel: 000000000000134d ffff8100043f2dc0 > 000000000000134c ffff810101019c28 > Jan 17 04:28:02 storage kernel: Call Trace: > Jan 17 04:28:02 storage kernel: > [<ffffffff8801dabf>] :ext3:ext3_get_block+0x0/0xe4 > Jan 17 04:28:02 storage kernel: [<ffffffff802576b4>] > add_to_page_cache+0x3d/0x93 > Jan 17 04:28:02 storage kernel: [<ffffffff8029b32a>] > mpage_readpages+0x95/0x13b > Jan 17 04:28:02 storage kernel: > [<ffffffff8801dabf>] :ext3:ext3_get_block+0x0/0xe4 > Jan 17 04:28:02 storage kernel: [<ffffffff8025b30d>] __alloc_pages+0xdf/0x2a0 > Jan 17 04:28:02 storage kernel: [<ffffffff8025cc7d>] > __do_page_cache_readahead+0x16b/0x25b > Jan 17 04:28:02 storage kernel: [<ffffffff8025cfc9>] > ondemand_readahead+0xf1/0xf8 > Jan 17 04:28:02 storage kernel: [<ffffffff802579ce>] > do_generic_mapping_read+0x123/0x3fd > Jan 17 04:28:02 storage kernel: [<ffffffff80257219>] file_read_actor+0x0/0xf8 > Jan 17 04:28:02 storage kernel: [<ffffffff80258fea>] > generic_file_aio_read+0x11d/0x160 > Jan 17 04:28:02 storage kernel: [<ffffffff80276b18>] do_sync_read+0xc9/0x10c > Jan 17 04:28:02 storage kernel: [<ffffffff80243e2d>] > autoremove_wake_function+0x0/0x2e > Jan 17 04:28:02 storage kernel: [<ffffffff80277280>] vfs_read+0xaa/0x132 > Jan 17 04:28:02 storage kernel: [<ffffffff8027761c>] sys_read+0x45/0x6e > Jan 17 04:28:02 storage kernel: [<ffffffff8020b6be>] system_call+0x7e/0x83 > Jan 17 04:28:02 storage kernel: > Jan 17 04:28:02 storage kernel: > Jan 17 04:28:02 storage kernel: Code: 0f 0b eb fe 8b 43 04 49 83 cf 01 4c 89 > 7b 08 a9 00 00 10 00 > Jan 17 04:28:02 storage kernel: RIP [<ffffffff802dfe28>] > radix_tree_insert+0x152/0x18c > Jan 17 04:28:02 storage kernel: RSP <ffff8101010199c8> > > Tonight I will back to @239 because it run 4 me for almost 2weeks without any > kind of problem having same load. You shouldn't do that, r243 has very important fix. > My system is a qcore intel with centos5.1 x86-64 and scst patched vanilla > kernel. > > this is the lsi adapter: > 02:01.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X > Fusion-MPT Dual Ultra320 SCSI (rev 07) > 02:01.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X > Fusion-MPT Dual Ultra320 SCSI (rev 07) Hmm, I don't think this crash relates to SCST, the same as the previous one you had. It's even not on SCST path. You should check for the latest CentOS kernel updates and report it to CentOS support. > Vlad , if you need more info please tell me . > > bye, > marco. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Scst-devel mailing list > Scs...@li... > https://lists.sourceforge.net/lists/listinfo/scst-devel > |