linux-2.6 system ACE driver - need help

[agnel juni]

Hello Jim,

Thanks for your reply.

I did try the option you have propsed. Though didn't help me its good to know.

The driver behaves the same way when put in polling mode also.

thanks very much
Junita

----- Original Message ----
From: "Grenier, Jim" <James.Grenier at adc.com>
To: linuxppc-embedded at ozlabs.org
Sent: Tuesday, 3 October, 2006 3:31:03 PM
Subject: linux-2.6 system ACE driver - need help

> Hi Jeff,
> 
> Thanks for your reply.
> 
> > Does it work for you in polling mode?  If not, you probably have a
> problem with the way you are accessing the system ace - cache,
> endianess, byte alignment, etc.  If it does work in polling, the usual
> suspects are interrupt masking errors or some low level problems with
> your IRQ signals.  Since you know the size of a sector and the size of
> the sysace buffers, how many interrupts do you get per sector read?
Do
> you see extras or not enough?
> 
> I heard from Ameet Patil that this driver is not tested in poilling
mode and it failed when we tried also.
> Thats when we moved to interrupt mode. 
> 
> I did check for the endianess...byte alignment etc.It looks ok to me.
> 
> I am using a 64 MB flash. And the sector sice is 512K.When the kernel
boots up I see 128 interrupts getting registered. (I think its from
alloc_disk(16) function in adapter.c )
> 
> Seems like the driver has issues with completing the request.
> 
> We are having issues while mouting the device. It is erratic, that
sometimes we are able to mount/list files, copy files.
> 
> But sometimes the kernel crashes and gives a Ooops message like :
> 
> /*********************************************************/
> 
> # ls /mnt/Oops: kernel access of bad area, sig: 11 [#1]
> NIP: C00556B8 LR: C00557E4 CTR: 00000000
> REGS: dfec1e08 TRAP: 0300   Not tainted  (2.6.16.2)
> MSR: 00021000 <ME>  CR: 22128828  XER: 00000000
> DAR: 30303030, DSISR: 00800000
> TASK GPR00: 00100100 DFEC1EB8 DFF6C030 C0258C60 DFF7BE10 00000018
DF4E9000 C0256D60
> GPR08: 30303030 00200200 DF4E9154 30303030 22128888 00100400 1FFB9700
00000000
> GPR16: 00000001 FFFFFFFF 00000000 007FFF00 1FFB3604 1FF63CE0 1FFCEF78
C01F0000
> GPR24: C0240000 00100100 C0240000 00000000 DFF7BE10 00000018 00000000
C0258C60
> NIP [C00556B8] free_block+0xa8/0x148
> LR [C00557E4] drain_array_locked+0x8c/0xd8
> Call Trace:
> [DFEC1EB8] [DFCA9490] 0xdfca9490 (unreliable)
> [DFEC1ED8] [C00557E4] drain_array_locked+0x8c/0xd8
> [DFEC1EF0] [C0056F80] cache_reap+0x74/0x18c
> [DFEC1F28] [C002B578] run_workqueue+0x9c/0x110
> [DFEC1F48] [C002B6E4] worker_thread+0xf8/0x13c
> [DFEC1FC0] [C002F6F0] kthread+0xf4/0x130
> [DFEC1FF0] [C000413C] kernel_thread+0x44/0x60
> Instruction dump:
> 7cfbfa14 3c000010 80e70014 3d2a4000 60000100 5529c9f4 7d295a14
80c9001c
> 3d200020 61290200 81060004 81660000 <91680000> 910b0004 3966001c
90060000
> BUG: events/0/4, lock held at task exit time!
>  [c01f5d60] {cache_chain_mutex}
> .. held by:          events/0:    4 [dff6c030, 110]
> ... acquired at:               cache_reap+0x1c/0x18c
> /*******************************************************************/
>
>
> We are able to do this after modiifying the file
xsysace_compactflash.c and xsysace_intr.c  to reset the controller( It
was commented out by applying the patch).
> 
> The data in the CF looks sane.
>
> Please advise.
>
> Thanks for your help.
>
>
> Thanks
> Junita

I have run into a problem with random crashes with System ACE on a
custom board.
It turned out that sometimes the System ACE chip would generate an extra
interrupt
after a write operation completed. The ISR in the driver is dumb and
assumes a transfer
just completed. This messed up the empty read/write queue for the
device.

I was working on a 2.4.17 kernel, so I don't know if it applies to you.
The quick fix was to ignore these extra interrupts. I changed the line
in xsysace_intr.c from:

    if (StatusReg & XSA_SR_DATABUFRDY_MASK) {

to:

    if ( (StatusReg & XSA_SR_DATABUFRDY_MASK) &&
                    (XSysAce_mGetControlReg(AcePtr->BaseAddress) &
                     XSA_CR_DATARDYIRQ_MASK) ) {

With this change, the driver will generate a transfer complete event
only if a transfer was in progress.

Hope this helps.

Jim Grenier


_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded







		
__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20061006/56c5e74a/attachment.htm