<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Hello Jim,<br><br>Thanks for your reply.<br><br>I did try the option you have propsed. Though didn't help me its good to know.<br><br>The driver behaves the same way when put in polling mode also.<br><br>thanks very much<br>Junita<br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: "Grenier, Jim" <James.Grenier@adc.com><br>To: linuxppc-embedded@ozlabs.org<br>Sent: Tuesday, 3 October, 2006 3:31:03 PM<br>Subject: linux-2.6 system ACE driver - need help<br><br><div>> Hi Jeff,<br>> <br>> Thanks for your reply.<br>> <br>> > Does it work for you in polling mode? If not, you probably have a<br>> problem with the way you are accessing
the system ace - cache,<br>> endianess, byte alignment, etc. If it does work in polling, the usual<br>> suspects are interrupt masking errors or some low level problems with<br>> your IRQ signals. Since you know the size of a sector and the size of<br>> the sysace buffers, how many interrupts do you get per sector read?<br>Do<br>> you see extras or not enough?<br>> <br>> I heard from Ameet Patil that this driver is not tested in poilling<br>mode and it failed when we tried also.<br>> Thats when we moved to interrupt mode. <br>> <br>> I did check for the endianess...byte alignment etc.It looks ok to me.<br>> <br>> I am using a 64 MB flash. And the sector sice is 512K.When the kernel<br>boots up I see 128 interrupts getting registered. (I think its from<br>alloc_disk(16) function in adapter.c )<br>> <br>> Seems like the driver has issues with completing the request.<br>> <br>> We are having issues while
mouting the device. It is erratic, that<br>sometimes we are able to mount/list files, copy files.<br>> <br>> But sometimes the kernel crashes and gives a Ooops message like :<br>> <br>> /*********************************************************/<br>> <br>> # ls /mnt/Oops: kernel access of bad area, sig: 11 [#1]<br>> NIP: C00556B8 LR: C00557E4 CTR: 00000000<br>> REGS: dfec1e08 TRAP: 0300 Not tainted (2.6.16.2)<br>> MSR: 00021000 <ME> CR: 22128828 XER: 00000000<br>> DAR: 30303030, DSISR: 00800000<br>> TASK GPR00: 00100100 DFEC1EB8 DFF6C030 C0258C60 DFF7BE10 00000018<br>DF4E9000 C0256D60<br>> GPR08: 30303030 00200200 DF4E9154 30303030 22128888 00100400 1FFB9700<br>00000000<br>> GPR16: 00000001 FFFFFFFF 00000000 007FFF00 1FFB3604 1FF63CE0 1FFCEF78<br>C01F0000<br>> GPR24: C0240000 00100100 C0240000 00000000 DFF7BE10 00000018 00000000<br>C0258C60<br>> NIP [C00556B8]
free_block+0xa8/0x148<br>> LR [C00557E4] drain_array_locked+0x8c/0xd8<br>> Call Trace:<br>> [DFEC1EB8] [DFCA9490] 0xdfca9490 (unreliable)<br>> [DFEC1ED8] [C00557E4] drain_array_locked+0x8c/0xd8<br>> [DFEC1EF0] [C0056F80] cache_reap+0x74/0x18c<br>> [DFEC1F28] [C002B578] run_workqueue+0x9c/0x110<br>> [DFEC1F48] [C002B6E4] worker_thread+0xf8/0x13c<br>> [DFEC1FC0] [C002F6F0] kthread+0xf4/0x130<br>> [DFEC1FF0] [C000413C] kernel_thread+0x44/0x60<br>> Instruction dump:<br>> 7cfbfa14 3c000010 80e70014 3d2a4000 60000100 5529c9f4 7d295a14<br>80c9001c<br>> 3d200020 61290200 81060004 81660000 <91680000> 910b0004 3966001c<br>90060000<br>> BUG: events/0/4, lock held at task exit time!<br>> [c01f5d60] {cache_chain_mutex}<br>> .. held by: events/0: 4 [dff6c030, 110]<br>> ... acquired
at: cache_reap+0x1c/0x18c<br>> /*******************************************************************/<br>><br>><br>> We are able to do this after modiifying the file<br>xsysace_compactflash.c and xsysace_intr.c to reset the controller( It<br>was commented out by applying the patch).<br>> <br>> The data in the CF looks sane.<br>><br>> Please advise.<br>><br>> Thanks for your help.<br>><br>><br>> Thanks<br>> Junita<br><br>I have run into a problem with random crashes with System ACE on a<br>custom board.<br>It turned out that sometimes the System ACE chip would generate an extra<br>interrupt<br>after a write operation completed. The ISR in the driver is dumb and<br>assumes a transfer<br>just completed. This messed up the empty read/write queue for the<br>device.<br><br>I was working on a 2.4.17 kernel, so I don't know if it applies to
you.<br>The quick fix was to ignore these extra interrupts. I changed the line<br>in xsysace_intr.c from:<br><br> if (StatusReg & XSA_SR_DATABUFRDY_MASK) {<br><br>to:<br><br> if ( (StatusReg & XSA_SR_DATABUFRDY_MASK) &&<br> (XSysAce_mGetControlReg(AcePtr->BaseAddress) &<br> XSA_CR_DATARDYIRQ_MASK) ) {<br><br>With this change, the driver will generate a transfer complete event<br>only if a transfer was in progress.<br><br>Hope this helps.<br><br>Jim Grenier<br><br><br>_______________________________________________<br>Linuxppc-embedded mailing list<br>Linuxppc-embedded@ozlabs.org<br><a target="_blank"
href="https://ozlabs.org/mailman/listinfo/linuxppc-embedded">https://ozlabs.org/mailman/listinfo/linuxppc-embedded</a><br></div></div><br></div></div><br>
<hr size=1></hr>
Find out what India is talking about on - <a href="http://us.rd.yahoo.com/mail/in/yanswers/*http://in.answers.yahoo.com/">Yahoo! Answers India</a> <BR>
Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. <a href="http://us.rd.yahoo.com/mail/in/messengertagline/*http://in.messenger.yahoo.com">Get it NOW</a></body></html>