* [parisc-linux] [RFC]: rename ncr53c8xx to 53c720? [Was: D380 and ext[23] fs grave pb]
[not found] <45018CEC.4040104@scarlet.be>
2006-09-11 13:29 ` [parisc-linux] w-a to what [Was: D380 and ext[23] fs grave pb] Michael S. Zick
@ 2006-09-12 11:09 ` Joel Soete
[not found] ` <200609120702.18615.mszick@morethan.org>
1 sibling, 1 reply; 3+ messages in thread
From: Joel Soete @ 2006-09-12 11:09 UTC (permalink / raw)
To: Parisc List; +Cc: Matthew Wilcox
Hello Matthew,
May be now that parisc-linux tree is managed with git and that driver is
in fact only for ncr 53c720 hba, isn't it time to rename those stuff
like ncr53c8xx to 53c720?
Awaitng a better fix, may I also suggest this small change:
--- drivers/scsi/ncr53c8xx.c.Orig 2006-09-11 11:26:36.000000000 +0200
+++ drivers/scsi/ncr53c8xx.c 2006-09-12 12:40:01.000000000 +0200
@@ -8362,7 +8362,12 @@
tpnt->this_id = 7;
tpnt->sg_tablesize = SCSI_NCR_SG_TABLESIZE;
tpnt->cmd_per_lun = SCSI_NCR_CMD_PER_LUN;
+#if defined(__hppa__)
+ /* FIXME: ENABLE_CLUSTERING cause ext fs corruptions */
+ tpnt->use_clustering = DISABLE_CLUSTERING;
+#else
tpnt->use_clustering = ENABLE_CLUSTERING;
+#endif
if (device->differential)
driver_setup.diff_support = device->differential;
=== <> ===
TIA for help,
Joel
Joel Soete wrote:
> Hello James, Matthrew,
>
> I come back to you with this pb because as explained in a previous mail:
> <http://lists.parisc-linux.org/pipermail/parisc-linux/2006-September/030152.html>
>
>
> , it seems to be related to ncr53c720 driver.
>
> As I encountered same kind of pb on my c110:
> a few time after the reboot, I just did a tar/untar and already get:
> EXT3-fs error (device md2): ext3_readdir: bad entry in
> directory4Remounting filesystem read-only
>
> That said, it seems that I find a work around: I just reverted this
> <http://cvs.parisc-linux.org/linux-2.6/drivers/scsi/ncr53c8xx.c?r1=1.18&r2=1.19&makepatch=1&diff_format=h>
>
> ===================================================================
> RCS file: /var/lib/cvs/linux-2.6/drivers/scsi/ncr53c8xx.c,v
> retrieving revision 1.18
> retrieving revision 1.19
> diff -u -r1.18 -r1.19
> --- linux-2.6/drivers/scsi/ncr53c8xx.c 2004/07/20 22:06:43 1.18
> +++ linux-2.6/drivers/scsi/ncr53c8xx.c 2004/07/27 21:19:51 1.19
> @@ -8633,7 +8633,7 @@
> tpnt->this_id = 7;
> tpnt->sg_tablesize = SCSI_NCR_SG_TABLESIZE;
> tpnt->cmd_per_lun = SCSI_NCR_CMD_PER_LUN;
> - tpnt->use_clustering = DISABLE_CLUSTERING;
> + tpnt->use_clustering = ENABLE_CLUSTERING;
>
> if (device->differential)
> driver_setup.diff_support = device->differential;
> === <> ===
>
> And a loop like:
> # while true; do nice -n -5 tar -xslpf linux-2.6.12-rc1-pa1.tar ; nice
> -n -5 rm -rf linux-2.6.12-rc1-pa 1-050319; date; done
>
> was already running at least 85 time without any pb on this same c110
> (same kernel 2.6.18-rc6-pa1 + jejb's patch + your
> timer_interrupt patch).
>
> As you're scsi driver expert and also symbios/ncr one, may be have you
> an idea where ncr stuff could be broken by enabling 'clustering'?
>
> TIA,
> Joel
>
> Joel Soete wrote:
> > Hello *pa,
> >
> > Making some stress test to atempt to identify some smp pb on my d380,
> I figure
> > out this ext[23] relatively grave pb. Effectively during this test loop:
> > # while true ; do nice -n -3 tar -xspf linux-2.6.11-rc3-pa3.tar ;
> nice -n -3 rm
> > -rf linux-2.6.11-rc3-pa3 ; date ; done
> >
> > after about 30 iteration, I got a fs' corruption:
> > EXT3-fs error (device sda10): ext3_readdir: bad entry in directory
> #84801:
> > rec_len % 4 != 0 - offset=0, inode=175234
> > Aborting journal on device sda10.
> >
> > ext3_abort called.
> >
> > EXT3-fs error (device sda10): ext3_journal_start_sb: Detected aborted
> journal
> >
> > Remounting filesystem read-only
> >
> > EXT3-fs error (device sda10): ext3_readdir: bad entry in directory
> #84801:
> > rec_len % 4 != 0 - offset=0, inode=1752397164, rec_len=24
> > EXT3-fs error (device sda10): ext3_readdir: bad entry in directory
> #84801:
> > rec_len % 4 != 0 - offset=0, inode=1752397164, rec_len=24
> > [snip]
> >
> > and during fsck I noticed:
> > __journal_remove_journal_head: freeing b_committed_data
> >
> > Pass 2: Checking directory structure
> > Directory inode 84801, block 0, offset 0: directory corrupted
> > Salvage? yes
> >
> > Missing '.' in directory inode 84801.
> > Fix? yes
> >
> > Setting filetype for entry '.' in ??? (84801) to 2.
> > Missing '..' in directory inode 84801.
> > Fix? yes
> >
> > [snip]
> >
> > As the first time it was with a smp kernel, I re-test with up kernels
> only.
> >
> > This pb occured with different (up) kernels (2.6.17-rc6, 2.6.14,
> 2.6.17 and
> > even with 2.6.8.1) on different fs located on different disk and
> different
> > hba, and finaly on the 2 different cpu?
> >
> > That said I also get a fs corruption during a simple apt-get
> dist-upgrade:
> > (sdb6 being /var)
> > EXT3-fs error (device sdb6): ext3_free_blocks: Freeing blocks not in
> datazone -
> > block = 745764206, count = 1
> > Aborting journal on device sdb6.
> > ext3_abort called.
> > EXT3-fs error (device sdb6): ext3_journal_start_sb: Detected aborted
> journal
> > Remounting filesystem read-only
> > EXT3-fs error (device sdb6): ext3_free_blocks: Freeing blocks not in
> datazone -
> > block = 1869488138, count = 1
> > EXT3-fs error (device sdb6): ext3_free_blocks: Freeing blocks not in
> datazone -
> > block = 1953459744, count = 1
> > [snip]
> > EXT3-fs error (device sdb6): ext3_free_blocks: Freeing blocks not in
> datazone -
> > block = 2003788910, count = 1
> > EXT3-fs error (device sdb6): ext3_free_blocks: Freeing blocks not in
> datazone -
> > block = 1851878701, count = 1
> > EXT3-fs error (device sdb6): ext3_free_blocks: Freeing blocks not in
> datazone -
> > block = 1919248225, count = 1<3>BUG: soft lockup det
> > ected on CPU#0!
> > Backtrace:
> > [<1013222c>] update_process_times+0x34/0x80
> > [<1010748c>] timer_interrupt+0x9c/0x134
> > [<10145f44>] handle_IRQ_event+0x5c/0xa4
> > [<10146004>] __do_IRQ+0x78/0x18c
> > [<10107bc4>] do_cpu_irq_mask+0x6c/0xc8
> > [<1010a068>] intr_return+0x0/0xc
> >
> >
> > EXT3-fs error (device sdb6): ext3_free_blocks: Freeing blocks not in
> datazone -
> > block = 1632635402, count = 1
> > EXT3-fs error (device sdb6): ext3_free_blocks: Freeing blocks not in
> datazone -
> > block = 1734437731, count = 1
> > [snip]
> > EXT3-fs error (device sdb6): ext3_free_blocks: Freeing blocks not in
> datazone -
> > block = 1313423904, count = 1
> > EXT3-fs error (device sdb6): ext3_free_blocks: Freeing blocks not in
> datazone -
> > block = 171515972, count = 1
> > EXT3-fs error (device sdb6) in ext3_reserve_inode_write: Journal has
> aborted
> > EXT3-fs error (device sdb6) in ext3_truncate: Journal has aborted
> > EXT3-fs error (device sdb6) in ext3_reserve_inode_write: Journal has
> aborted
> > EXT3-fs error (device sdb6) in ext3_orphan_del: Journal has aborted
> > EXT3-fs error (device sdb6) in ext3_reserve_inode_write: Journal has
> aborted
> > __journal_remove_journal_head: freeing b_committed_data
> >
> > It's the only system of this model on which I can reproduce but also
> I can
> > test (and as I am not hp, I don't have passwd diagnostic cd to test
> hw ;-( ),
> > so it's very hard to me if it's a driver pb (e.g. ncr hba) or a hw pb?
> >
> > Any idea, advises are welcome.
> >
> > Thanks in advance,
> > Joel
> >
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
>
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply [flat|nested] 3+ messages in thread