> On 05/06/13 18:43, De Roo, Steven wrote: > > Dear Martyn, Manohar & all VME-users, > > > > > > I'm still struggling with my VME SBC & the VME-drivers... > > Please be so kind to have another look at the current situation: > > > > I got to the point that I had a board perfectly reading/writing data > > to another board, even with DMA calls to speed up things with a factor 8. > > > > Yesterday, we put the board in a production environment, and things > > have become quite complicated since then. > > (finally we get some sunshine in Belgium, but now clouds are covering > > my project...) > > > > Apparently, the existing VME-crate into which the new board was put, > > has a lot of VME bus errors in the existing traffic, as can be seen > > with a VME analyzer card. > > The existing legacy hardware/software cannot be modified however, so > > I'll have to live with this situation. > > > > These bus errors cause the TSI148 chipset to abort the read-calls, and > > generate an interrupt, which is caught by function > > 'tsi148_irqhandler()', and there some strange things happen... > > > > Yes, there's a link-list that's recording bus errors. That is checked if you have err_chk enabled, but will also require you to be doing reads and writes to clear it. > Minimally the items should only be added to the link list if err_chk != 0. > tsi148_dma_list_exec() should probably also be checking this list if err_chk !=0. > if err_chk == 0, there's possibly a case for not enabling the VME Bus error interrupt as the driver doesn't care. tsi148_dma_list_exec() appearantly does not check the error list, but that's an other discussion I guess... The problem I have right now is occurring without using DMA-access... > > > In the beginning of this function, the 'interrupt enable out' > > and 'interrupt status' registers are read out, as shown below: > > ... > > 260 /* Determine which interrupts are unmasked and set */ > > 261 enable = ioread32be(bridge->base + TSI148_LCSR_INTEO); > > 262 stat = ioread32be(bridge->base + TSI148_LCSR_INTS); > > ... > > > > The first time an interrupt occurs, both 'enable' and 'stat' are 0, > > which is not ok, since the 'enable' register is definitely set to a > > proper value when the 'vme_tsi1148' module is loaded/probed. > > > > A consecutive interrupt leads to value -1 (0xFFFFFFFF) for both > > 'enable' and 'stat', and then a kernel crash is not far way... > > In this case, all handlers (DMA, LM, MB, PERR, VERR, ...) are called, > > and inside these handlers, NULL pointers are dereferenced, leading to a crash. > > > > What could possibly be corrupting the TSI148_LCSR_INTEO and TSI148_LCSR_INTS registers ? > > Could it be the driver, or can it be the TSI148 chipset itself ? > > Have you added debug that's reading the registers. Apparently reading the interrupt registers more than once has been seen to cause issues. I have, but these extra reads are not yet executed the moment the problem occurs. I've just added printk-statements after the existing ioread32be-calls mentioned above. > > > (e.g. can it be that the interrupt is raised before the registers are > > filled in correctly ?) > > > > I've just taken a quick look at a XVME-6300 Datasheet floating around the web. > The datasheet suggests that the VMEbus Interface has hardware byte swapping. > This is not a feature of the TSI-148. I have seen boards in the past place an FPGA between the VMEbus > and the VME-PCI bridge to do byte swapping, these have also done funny things with the interrupt as well. There is indeed a configurable byte swapping, but I don't think it's involved. Today, I setup an empty VME-crate with an arbiter and my XVME6300 board, and I opened a master window with addresses that nobody responds to. If I then perform a read, a bus error occurs (by the arbiter?) because nobody responds, and the interrupt handling works flawlessly. Even my extra debugging statements that involve reading some registers cause no issues. Is it possible that existing traffic on the VME-bus is corrupting my registers somehow ? I know that you can reach the CR/CSR from the VME-side, but only if the AM/XAM modifier flags also use CR/CSR, along with the proper address, right ? > > It might be worth looking at any documentation you have for the XVME-6300/ contact the > manufacturer to see if there are any other sources (such as a byte swapping FPGA) that end up generating the same interrupt as the TSI148. > The manufacturer has been contacted; I'm waiting for an answer... > > Also, I can't find any good documentation on the difference between > > the 'interrupt enable out' and 'interrupt enable' registers. Do you have a clue ? > > > > I think this is covered in the TSI-148 manual. From memory, one is for PCI interrupts, the other can enable some error conditions to be converted into VME interrupts. > > Martyn > I just found out: 'Interrupt Enable' causes the 'Interrupt status' registers to be updated when an exception occurs, 'Interrupt Enable Out' causes the interrupt to be sent to the CPU. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
