On 06/05/13 09:45, De Roo, Steven wrote:
> Hi all,
>
> I'm running OpenSuSE 12.3, kernel 3.7.
>
I'm not aware of any changes between 3.7 and 3.9 that would affect the
behaviour of the driver (mainly cosmetic changes), so I'm not sure it's worth
trying 3.9...
> I found out that the problem occurs when there is another card in the VME-crate
> that performs a lot of writes in the memory-region I'm reading in my example.
> ('a lot of' = each millisecond, the first 64 bytes get updated).
>
> I've already added a sleep to the loop in my example,
> ranging from 20 milliseconds to a whole second,
> and it's just a matter of time...
> Sometimes, I get the freeze after 50 loops, sometimes after 2000.
>
> When I disable the VME-card that writes data to this region,
> my example program keeps running flawlessly...
> Can 'concurrent' access to the same memory region cause such a nasty result ?
>
The VME bus only allows one device to be using the data bus at a time. There
is (in the case of the tsi148 and the ca91cx42 at least) hardware based
arbitration of access to the bus, co-ordinated by the system controller.
I have 3 boards here, ones acting as a slave, one's reading as before but
reading from offset 0 and the command is run as:
count=0 && while [[ $count -lt 100000 ]]; do ./test_extend; let
count=$count+1; done
(As the test code is looping internally 100 times, this represents some
10000000 read cycles...)
It's been running for a good 5 minutes fine so far (I guess that's at least
2000 read cycles) and it hasn't failed yet...
Are all the devices in your system SBCs (do all the boards access the VME bus
via a tsi148)?
Martyn
> Kind regards,
> Steven
>
>
> --------------------------------------------------------------------------------
>
> Hi Steven,
>
> I have run this test up on a pair of boards I have access to. I had to declare the loop variable, but other than that it seems to be running fine here (I'm testing this on the head of the staging tree[1]):
>
> root@ge-xvb601:~/vme_test# uname -r
> 3.9.0
> root@ge-xvb601:~/vme_test# gcc -o test_extended test_extended.c root@ge-xvb601:~/vme_test# ./test_extended > test.txt root@ge-xvb601:~/vme_test# wc -l test.txt 900 test.txt root@ge-xvb601:~/vme_test# tail test.txt
> 0038: ff ff df ff df ff ff ff
>
> 0000: ff ff ff fb ff f5 ff ff
> 0008: ff ff ff ff 7f ff ff ff
> 0010: ff ff df df be fb ff fe
> 0018: ff f7 ff f7 7f ea ff ff
> 0020: ff ef ff ff d8 ee ff ff
> 0028: ff ff ff ff 7e f7 ff f7
> 0030: ff ff 7b 6e 5d df ff ff
> 0038: ff ff df ff df ff ff ff
> root@ge-xvb601:~/vme_test#
>
> Which version of kernel are you running this on?
>
> Martyn
>
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
>
> On 02/05/13 09:33, De Roo, Steven wrote:
>> Dear all,
>>
>> I've been trying to access the VME-bus using a Xembedded XVME-6300
>> board (with TSI-148 chipset) and the vme_user module from Martyn, with success.
>> (Thanks to Martyn for an easy demo program).
>>
>> I've modified the code (see below) to...
>> - use A_32/D_32
>> - use 0x8BB00000 as base address
>> - read data at an offset 0x8400 from this address
>> - do a read of 6400 bytes instead of 512 bytes This seems to be
>> working perfect (another VME-card writes a recognizable pattern at the
>> above address, and I can see it using the printf-statements).
>>
>> HOWEVER:
>> When I do this read in a loop (eg. 100 times), then my whole system
>> freezes/hangs after about 50 times, and I have to power off/power on
>> the machine...
>>
>> Does anybody have an idea what's going wrong ?
>> Can I activate something to find out the problem ?
>>
>> Kind regards,
>> Steven De Roo
>>
>> ----------------------------------------------------------------------
>> ----------
>>
>> #define _XOPEN_SOURCE 500
>> #define u32 unsigned int // Needed to add this line #include
>> <linux/types.h> // Needed to add this line #include <stdio.h> #include
>> <stdlib.h> #include <sys/ioctl.h> #include <sys/types.h> #include
>> <sys/stat.h> #include <fcntl.h> #include <unistd.h> #include
>> "vme_user.h"
>>
>> int main(int argc, char *argv[])
>> {
>> int fd;
>> int i;
>> int retval;
>> unsigned char data[6400];
>>
>> struct vme_master master;
>>
>> fd = open("/dev/bus/vme/m0", O_RDONLY);
>> if (fd == -1) {
>> perror("ERROR: Opening window device file");
>> return 1;
>> }
>>
>> master.enable = 1;
>> master.vme_addr = 0x8BB00000;
>> master.size = 0x10000;
>> master.aspace = 4; // VME_A32
>> master.cycle = 0x2000 | 0x8000; // user/data access
>> master.dwidth = 4; // VME_D32
>>
>> retval = ioctl(fd, VME_SET_MASTER, &master);
>> if (retval != 0) {
>> printf("retval=%d\n", retval);
>> perror("ERROR: Failed to configure window");
>> return 1;
>> }
>> for (i=0; i<sizeof(data); i++) {
>> data[i] = 0;
>> }
>>
>> for (loop=0; loop<100; loop++)
>> {
>> retval = pread(fd, data, sizeof(data), 0x8400);
>> if (retval < sizeof(data)) {
>> printf("WARNING: Only read %d bytes", retval);
>> }
>>
>> // Print first 64 bytes
>> for(i=0; i<8*8; i++) {
>> if (i % 8 == 0) {
>> printf("\n""%4.4x: ", i);
>> }
>> printf("%2.2x ", data[i]);
>> }
>> printf("\n");
>> }
>>
>> close(fd);
>>
>> return 0;
>> }
>>
>
>
> --
> Martyn Welch (Lead Software Engineer) | Registered in England and Wales
> GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
> T +44(0)1327322748 | Manchester, M2 3AB
> E martyn.welch@xxxxxx | VAT:GB 927559189
>
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.welch@xxxxxx | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
