linux-2.6 system ACE driver - need help

linux-2.6 system ACE driver - need help

[agnel juni]

[-- Attachment #1: Type: text/plain, Size: 2703 bytes --]

Hi Ameet

I have posted a few messages regarding Ssytem ACE driver for Linux-2.6.

We are working on a AMCC 440SPe based custom board.

We applied the patch from

http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch
 and applied against 2.6.16-2 kernel.

We are trying to make the driver work in interrupt mode.

First, I would like to know if the driver tested in interrupt mode.

We are able to mount the CF, but it is very inconsistent.

Same is the case with fdisk command. When it fails,we get errors which you could see in the screen-dump below.

Are we missing to apply the right patch? Please let us know your inputs to go forward.
Looking forwards for your reply.

Thanks
Junita

/*************** Screen dump ********************/
# fdisk /dev/xsysace
  1. sector = 0 xsa_cur_req->sector=0
  System ACE: Error 0 when reading sector 2.
  2. sector = 2 xsa_cur_req->sector=16
  end_request: I/O error, System ACE: Error 0 when reading sectoru dev xsa, sector 16
  Buffer I/O error on device xsa, logical block 2
  1. sector = 184 xsa_cur_req->sector=184
   
  Command (m for help): p
   
  Disk /dev/xsysace: 524 MB, 524869632 bytes
  17 heads, 59 sectors/track, 1022 cylinders
  Units = cylinders of 1003 * 512 = 513536 bytes
   
         Device Boot      Start         End      Blocks   Id  System
  /dev/xsysace1               1        1022      512503+   6  FAT16
   
  Command (m for help): q
    And for 'mount'  #
  #
  # mount -t msdos /dev/xsysace /root/cf
  1. sector = 0 xsa_cur_req->sector=0
  1. sector = 503 xsa_cur_req->sector=503
  1. sector = 504 xsa_cur_req->sector=504
  1. sector = 506 xsa_cur_req->sector=506
  1. sector = 508 xsa_cur_req->sector=508
  1. sector = 510 xsa_cur_req->sector=510
  # cd /root/cf
  < Here Prints Some Symbols like + - etc, which i am
    not able to capture/copy -------------ERROR
  b: No such file or directory--------------------------------ERROR
  pci.h
  #
  Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.n0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.d#
  # cp pci.h /root/
  # cd ../
  # ls
  app     cf      hello1  pci.h
    #
  #/root
   /dev/xsysace /root/cf
  FAT: bogus number of reserved sectors
  VFS: Can't find a valid FAT filesystem on dev xsa.
  mount: Mounting /dev/xsysace on /root/cf failed: Invalid argument
  #
   
  










 				
---------------------------------
 Find out what India is talking about on  - Yahoo! Answers India 
 Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW

[-- Attachment #2: Type: text/html, Size: 6440 bytes --]

Re: linux-2.6 system ACE driver - need help

[Jeff Angielski]

On Tue, 2006-09-19 at 23:43 +0100, agnel juni wrote:

> First, I would like to know if the driver tested in interrupt mode.

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?

> We are able to mount the CF, but it is very inconsistent.

Dump the sector data to the screen that you are reading from the CF.
Especially look at the results from the initial identify command to
verify that they make sense, and because that is the easiest to check.

> Same is the case with fdisk command. When it fails,we get errors which you could see in the screen-dump below.
> Are we missing to apply the right patch? Please let us know your
> inputs to go forward.
> Looking forwards for your reply.

> 
> # mount -t msdos /dev/xsysace /root/cf

Shouldn't this be /dev/xsysace1?  You want to mount a partition not the
entire block device.


-- 
Jeff Angielski
The PTR Group

Re: linux-2.6 system ACE driver - need help

[agnel juni]

[-- Attachment #1: Type: text/plain, Size: 4191 bytes --]

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 = dff6c030[4] 'events/0' THREAD: dfec0000
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
.

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?





> We are able to mount the CF, but it is very inconsistent.

Dump the sector data to the screen that you are reading from the CF.
Especially look at the results from the initial identify command to
verify that they make sense, and because that is the easiest to check.

> Same is the case with fdisk command. When it fails,we get errors which you could see in the screen-dump below.
> Are we missing to apply the right patch? Please let us know your
> inputs to go forward.
> Looking forwards for your reply.

> 
> # mount -t msdos /dev/xsysace /root/cf

Shouldn't this be /dev/xsysace1?  You want to mount a partition not the
entire block device.


-- 
Jeff Angielski
The PTR Group



 				
---------------------------------
 Find out what India is talking about on  - Yahoo! Answers India 
 Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW

[-- Attachment #2: Type: text/html, Size: 5024 bytes --]

Re: linux-2.6 system ACE driver - need help

[agnel juni]

[-- Attachment #1: Type: text/plain, Size: 5181 bytes --]

Jeff,
 
 I forgot to mention onething.
 
 The System ACE Base Address register is a 64-bit address.
 
 So we have done ioremap64, like 
 ioremap64(0x4E0000000ULL, remap_size);
 
 Could this be a cause for the segmentation fault we are seeing ????
 
 Screen-dump from one  of our trials.
 
 # mount -t msdos /dev/xsysace1 /mnt/sysace/
 swap_dup: Bad swap file entry 7c0ff1f0
 VM: killing process exe
 swap_free: Bad swap file entry 6c0ff019
 swap_free: Bad swap file entry c80ff1ef
 swap_free: Bad swap file entry a80ff1f3
 swap_free: Bad swap file entry d00ff1ef
 
 thanks
 Junita
 
 

agnel juni <junijoseph@yahoo.co.in> wrote: 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 = dff6c030[4] 'events/0' THREAD: dfec0000
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
.

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?





> We are able to mount the CF, but it is very inconsistent.

Dump the sector data to the screen that you are reading from the CF.
Especially look at the results from the initial identify command to
verify that they make sense, and because that is the easiest to check.

> Same is the case with fdisk command. When it fails,we get errors which you could see in the screen-dump below.
> Are we missing to apply the right patch? Please let us know your
> inputs to go forward.
> Looking forwards for your reply.

> 
> # mount -t msdos /dev/xsysace /root/cf

Shouldn't this be /dev/xsysace1?  You want to mount a partition not the
entire block device.


-- 
Jeff Angielski
The PTR Group


         

---------------------------------
  Find out what India is talking about on  - Yahoo! Answers India 
  Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

 				
---------------------------------
 Find out what India is talking about on  - Yahoo! Answers India 
 Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW

[-- Attachment #2: Type: text/html, Size: 6465 bytes --]

Re: linux-2.6 system ACE driver - need help

[Ameet Patil]

agnel juni wrote:
> Hi Ameet
>
> I have posted a few messages regarding Ssytem ACE driver for Linux-2.6.
>
> We are working on a AMCC 440SPe based custom board.
>
> We applied the patch from
> //http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch
>  //and applied against 2.6.16-2 kernel.
>
> We are trying to make the driver work in interrupt mode.
>
> First, I would like to know if the driver tested in interrupt mode.
>
> We are able to mount the CF, but it is very inconsistent.
>
> Same is the case with fdisk command. When it fails,we get errors which you could see in the screen-dump below.//
> //
> Are we missing to apply the right patch? Please let us know your 
> inputs to go forward.
> Looking forwards for your reply.
>
> Thanks
> Junita
>
> /*************** Screen dump ********************/
> # fdisk /dev/xsysace
> 1. sector = 0 xsa_cur_req->sector=0
> System ACE: Error 0 when reading sector 2.
> 2. sector = 2 xsa_cur_req->sector=16
> end_request: I/O error, System ACE: Error 0 when reading sectoru dev 
> xsa, sector 16
> Buffer I/O error on device xsa, logical block 2
> 1. sector = 184 xsa_cur_req->sector=184
>  
> Command (m for help): p
>  
> Disk /dev/xsysace: 524 MB, 524869632 bytes
> 17 heads, 59 sectors/track, 1022 cylinders
> Units = cylinders of 1003 * 512 = 513536 bytes
>  
>        Device Boot      Start         End      Blocks   Id  System
> /dev/xsysace1               1        1022      512503+   6  FAT16
>  
> Command (m for help): q
> And for 'mount'
> #
> #
> # mount -t msdos /dev/xsysace /root/cf
> 1. sector = 0 xsa_cur_req->sector=0
> 1. sector = 503 xsa_cur_req->sector=503
> 1. sector = 504 xsa_cur_req->sector=504
> 1. sector = 506 xsa_cur_req->sector=506
> 1. sector = 508 xsa_cur_req->sector=508
> 1. sector = 510 xsa_cur_req->sector=510
> # cd /root/cf
> < Here Prints Some Symbols like + - etc, which i am
>   not able to capture/copy -------------ERROR
> b: No such file or directory--------------------------------ERROR
> pci.h
> #
> Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.n0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.d#
> # cp pci.h /root/
> # cd ../
> # ls
> app     cf      hello1  pci.h
> #
> #/root
>  /dev/xsysace /root/cf
> FAT: bogus number of reserved sectors
> VFS: Can't find a valid FAT filesystem on dev xsa.
> mount: Mounting /dev/xsysace on /root/cf failed: Invalid argument
> #
>  
>
>
> //
>
>
>
> //
>
> ------------------------------------------------------------------------
> Find out what India is talking about on - Yahoo! Answers India 
> <http://us.rd.yahoo.com/mail/in/yanswers/*http://in.answers.yahoo.com/>
> Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. 
> Get it NOW 
> <http://us.rd.yahoo.com/mail/in/messengertagline/*http://in.messenger.yahoo.com> 


Hi Agnel,
    The driver was last tested with 2.6.17 kernel and till date works 
fine in the interrupt mode. I have been using it since the last 4 months 
now. It should also work on 2.6.16-2 kernel I think, but I have not 
tested this. Have you made any changes to the driver? If so... please 
give the details so I can give you better feedback as to where things 
might have gone wrong. When time permits I shall try my patch on the 
2.6.16-2 kernel and let you know if it works for me.

Thanks,
-Ameet

Re: linux-2.6 system ACE driver - need help

[agnel juni]

[-- Attachment #1: Type: text/plain, Size: 7621 bytes --]

Hi Ameet,
   
  Thanks so much for your reply.
   
  ISSUE Details :
   
  We are currently debugging System driver in 2.6.16-2 kernel in interrupt mode, for AMCC440SPe based custom board.
   
  We got the kernel and applied patch for Xilinx System ACE driver.
   
  We are using powerpc-eabi-  toolachain to compile the kernel and NOT EDK.
   
  We have done changes in the driver in regard to –
   
    
   System ACE Controller register configuration - BASE address is 64-bit and hence done ioremap64(SYSTEMACE_BASEADRESS).- adapter.c  
   Endianess (Xsysace_l.c)  
   IRQ - xsysace_intr.c; arch/ppc/platforms/4xx/xparameters/xparameters_ml300.h ;  arch/ppc/syslib/ppc4xx_pic.c;  
   Kernel configuration to support FAT file system  
    Format the Compact Flash with FAT16 filesystem using ‘mkdosfs’, since  System ACE supports only FAT16
   
  With all these changes, we are able to communicate with the system ACE controller, register the interrupt, create block device using the driver, format and partition the Compact Flash.
   
  But we see issues while mounting the compact flash – Meaning, mounting shows inconsistent results.
   
  When we are able to mount the CF successfully, we are able to read/write to the compact flash. And when it fails, it throws a kernel Oops sometimes or complains that it’s a ‘bogus’ filesystem. Please see the screen-dump for success and failure cases:
  
  
   
  We are looking for inputs to attack this issue. Please advice.
   
  Note : we have worked on System ACE driver on 2.4 kernel on a different platform and were successful.
   
  Thanks very much
  Junita
   
  SCREEN DUMP:
   
  CASE 1 : Success:
   
  BusyBox v(null) ((null)) Built-in shell (msh)
  Enter 'help' for a list of built-in commands.
   
  # ### Application running ...
   
  #
  # cat /proc/interrupts
             CPU0
   33:          0  UIC1 Level     MAL SERR
   34:          0  UIC1 Level     MAL TX DE
   35:          0  UIC1 Level     MAL RX DE
   38:          0  UIC1 Level     MAL TX EOB
   39:          0  UIC1 Level     MAL RX EOB
   89:          0  UIC2 Level     System ACE
  BAD:          0
   
  # mknod /dev/xsysace b 254 0
   
  # mkdir /mnt
   
  # mkdir /mnt/sysace
   
  # mount -t msdos /dev/xsysace /mnt/sysace/
   
  # ls
  bin      etc      home     linuxrc  proc     sbin     usr
  dev      ftp      lib      mnt      root     tmp      var
   
  # ls /mnt/sysace/
  rev0.ace
  # cp /sbin/ifconfig /mnt/sysace/
   
  # ls /mnt/sysace/
  ifconfig  rev0.ace
  #
   
   
  CASE : 2 – Failure – Kernel Oops.
   
   
   # mount -t msdos /dev/xsysace /root/cf # cd /root/
   > Oops: kernel access of bad area, sig: 11 [#1]
   > NIP: C00556B8 LR: C00557E4 CTR: 00000000
   > REGS: dfeb1e08 TRAP: 0300   Not tainted  (2.6.16.2)
   > MSR: 00021000 <ME>  CR: 227A8728  XER: 00000000
   > DAR: 00000000, DSISR: 00800000
   > TASK = dff6c030[4] 'events/0' THREAD: dfeb0000
   > GPR00: 00100100 DFEB1EB8 DFF6C030 C025AC60 DFF7BE10 00000018
  DFD96000
   > C0258D60
   > GPR08: 00000000 00200200 DFD96154 00000000 227A8788 800823E2
  1FFB9600
   > 00000000
   > GPR16: 00000001 FFFFFFFF 00000000 007FFF00 1FFB3540 1FF63920
  1FFCEE78
   > C01F0000
   > GPR24: C0240000 00100100 C0240000 00000000 DFF7BE10 00000018
  00000000
   > C025AC60
   > NIP [C00556B8] free_block+0xa8/0x148 LR [C00557E4] 
   > drain_array_locked+0x8c/0xd8 Call Trace:
   > [DFEB1EB8] [DFED53F0] 0xdfed53f0 (unreliable) [DFEB1ED8] [C00557E4] 
   > drain_array_locked+0x8c/0xd8 [DFEB1EF0] [C0056F80] 
   > cache_reap+0x74/0x18c [DFEB1F28] [C002B578] run_workqueue+0x9c/0x110 
   > [DFEB1F48] [C002B6E4] worker_thread+0xf8/0x13c [DFEB1FC0] [C002F6F0] 
   > kthread+0xf4/0x130 [DFEB1FF0] [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
   >
   
   
    

Ameet Patil <ammubhai@gmail.com> wrote:

  agnel juni wrote:
> Hi Ameet
>
> I have posted a few messages regarding Ssytem ACE driver for Linux-2.6.
>
> We are working on a AMCC 440SPe based custom board.
>
> We applied the patch from
> //http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch
> //and applied against 2.6.16-2 kernel.
>
> We are trying to make the driver work in interrupt mode.
>
> First, I would like to know if the driver tested in interrupt mode.
>
> We are able to mount the CF, but it is very inconsistent.
>
> Same is the case with fdisk command. When it fails,we get errors which you could see in the screen-dump below.//
> //
> Are we missing to apply the right patch? Please let us know your 
> inputs to go forward.
> Looking forwards for your reply.
>
> Thanks
> Junita
>
> /*************** Screen dump ********************/
> # fdisk /dev/xsysace
> 1. sector = 0 xsa_cur_req->sector=0
> System ACE: Error 0 when reading sector 2.
> 2. sector = 2 xsa_cur_req->sector=16
> end_request: I/O error, System ACE: Error 0 when reading sectoru dev 
> xsa, sector 16
> Buffer I/O error on device xsa, logical block 2
> 1. sector = 184 xsa_cur_req->sector=184
> 
> Command (m for help): p
> 
> Disk /dev/xsysace: 524 MB, 524869632 bytes
> 17 heads, 59 sectors/track, 1022 cylinders
> Units = cylinders of 1003 * 512 = 513536 bytes
> 
> Device Boot Start End Blocks Id System
> /dev/xsysace1 1 1022 512503+ 6 FAT16
> 
> Command (m for help): q
> And for 'mount'
> #
> #
> # mount -t msdos /dev/xsysace /root/cf
> 1. sector = 0 xsa_cur_req->sector=0
> 1. sector = 503 xsa_cur_req->sector=503
> 1. sector = 504 xsa_cur_req->sector=504
> 1. sector = 506 xsa_cur_req->sector=506
> 1. sector = 508 xsa_cur_req->sector=508
> 1. sector = 510 xsa_cur_req->sector=510
> # cd /root/cf
> < Here Prints Some Symbols like + - etc, which i am
> not able to capture/copy -------------ERROR
> b: No such file or directory--------------------------------ERROR
> pci.h
> #
> Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.n0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.d#
> # cp pci.h /root/
> # cd ../
> # ls
> app cf hello1 pci.h
> #
> #/root
> /dev/xsysace /root/cf
> FAT: bogus number of reserved sectors
> VFS: Can't find a valid FAT filesystem on dev xsa.
> mount: Mounting /dev/xsysace on /root/cf failed: Invalid argument
> #
> 
>
>
> //
>
>
>
> //
>
> ------------------------------------------------------------------------
> Find out what India is talking about on - Yahoo! Answers India 
> 
> Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. 
> Get it NOW 
> 


Hi Agnel,
The driver was last tested with 2.6.17 kernel and till date works 
fine in the interrupt mode. I have been using it since the last 4 months 
now. It should also work on 2.6.16-2 kernel I think, but I have not 
tested this. Have you made any changes to the driver? If so... please 
give the details so I can give you better feedback as to where things 
might have gone wrong. When time permits I shall try my patch on the 
2.6.16-2 kernel and let you know if it works for me.

Thanks,
-Ameet




 				
---------------------------------
 Find out what India is talking about on  - Yahoo! Answers India 
 Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW

[-- Attachment #2: Type: text/html, Size: 29299 bytes --]

Re: linux-2.6 system ACE driver - need help

[Ameet Patil]

agnel juni wrote:
> Jeff,
>
> I forgot to mention onething.
>
> The System ACE Base Address register is a 64-bit address.
>
> So we have done ioremap64, like
> ioremap64(0x4E0000000ULL, remap_size);
>
> Could this be a cause for the segmentation fault we are seeing ????
>
> Screen-dump from one  of our trials.
>
> # mount -t msdos /dev/xsysace1 /mnt/sysace/
> swap_dup: Bad swap file entry 7c0ff1f0
> VM: killing process exe
> swap_free: Bad swap file entry 6c0ff019
> swap_free: Bad swap file entry c80ff1ef
> swap_free: Bad swap file entry a80ff1f3
> swap_free: Bad swap file entry d00ff1ef
>
> thanks
> Junita
>
>
>
> */agnel juni <junijoseph@yahoo.co.in>/* wrote:
>
>     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 = dff6c030[4] 'events/0' THREAD: dfec0000
>     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
>
>         .
>
>         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?
>
>
>
>
>
>         > We are able to mount the CF, but it is very inconsistent.
>
>         Dump the sector data to the screen that you are reading from
>         the CF.
>         Especially look at the results from the initial identify
>         command to
>         verify that they make sense, and because that is the easiest
>         to check.
>
>         > Same is the case with fdisk command. When it fails,we get
>         errors which you could see in the screen-dump below.
>         > Are we missing to apply the right patch? Please let us know your
>         > inputs to go forward.
>         > Looking forwards for your reply.
>
>         >
>         > # mount -t msdos /dev/xsysace /root/cf
>
>         Shouldn't this be /dev/xsysace1? You want to mount a partition
>         not the
>         entire block device.
>
>
>         -- 
>         Jeff Angielski
>         The PTR Group
>
>
>     ------------------------------------------------------------------------
>     Find out what India is talking about on - Yahoo! Answers India
>     <http://us.rd.yahoo.com/mail/in/yanswers/*http://in.answers.yahoo.com/>
>
>     Send FREE SMS to your friend's mobile from Yahoo! Messenger
>     Version 8. Get it NOW
>     <http://us.rd.yahoo.com/mail/in/messengertagline/*http://in.messenger.yahoo.com>_______________________________________________
>     Linuxppc-embedded mailing list
>     Linuxppc-embedded@ozlabs.org
>     https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> ------------------------------------------------------------------------
> Find out what India is talking about on - Yahoo! Answers India 
> <http://us.rd.yahoo.com/mail/in/yanswers/*http://in.answers.yahoo.com/>
> Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. 
> Get it NOW 
> <http://us.rd.yahoo.com/mail/in/messengertagline/*http://in.messenger.yahoo.com> 
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Sorry Junita,
  I am busy with something else at the moment... hard deadline! Haven't 
checked my code yet to give you any feedback. Sorry!

-Ameet

linux-2.6 system ACE driver - need help

[Grenier, Jim]

> Hi Jeff,
>=20
> Thanks for your reply.
>=20
> > 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?
>=20
> 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.=20
>=20
> I did check for the endianess...byte alignment etc.It looks ok to me.
>=20
> 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 )
>=20
> Seems like the driver has issues with completing the request.
>=20
> We are having issues while mouting the device. It is erratic, that
sometimes we are able to mount/list files, copy files.
>=20
> But sometimes the kernel crashes and gives a Ooops message like :
>=20
> /*********************************************************/
>=20
> # 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).
>=20
> 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

Re: linux-2.6 system ACE driver - need help

[agnel juni]

[-- Attachment #1: Type: text/plain, Size: 4668 bytes --]

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@adc.com>
To: linuxppc-embedded@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@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded







		
__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/

[-- Attachment #2: Type: text/html, Size: 6306 bytes --]