From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephane Grosjean Subject: [sja1000/peak_pci]: looks like loss of IRQ on Tegra3 based system... Date: Thu, 22 May 2014 11:48:43 +0200 Message-ID: <537DC7FB.5070904@peak-system.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail.peak-system.com ([213.157.13.214]:43013 "EHLO mail.peak-system.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754047AbaEVJsr (ORCPT ); Thu, 22 May 2014 05:48:47 -0400 Sender: linux-can-owner@vger.kernel.org List-ID: To: linux-can@vger.kernel.org Hi, Here is an issue a user of the peak_pci driver encounters and for which any help is welcome. I have copied some extracts of some of the e-mails and debug he did, if this might help. His system is quite specific since he runs a 3.1 Kernel on a nVidia Tegra3 but he says he applied all the linux-can patches that should... I'm currently having a look to this serie of patches, but meanwhile, in case this loss of IRQ when no cable is plugged is something heard by anyone... To recap, after some time with cable completely unplugged and a userspace process continuously trying to transmit, IRQs just stop getting delivered from the peak device. If the operator toggles PCI reset for just that device (in /sys/bus/pci/devices/0000:03:00.0/reset) they come back again. Here's an example reg dump (user added a quick debugfs hack) of when the device is in this state. Note that IR in sja1000 and ICR in PETA has pending interrupts, but he's not getting them signaled. Well, things may be unhappy later since he's reading out IR through debugfs and thus clearing it, but the device is not making forward progress anyway :) Note that the PITA registers are just being read out as a 32bit value for ease of printing. can0: REG_MOD(0)=0x00 can0: REG_CMR(1)=0x00 can0: REG_SR(2)=0x40 can0: REG_IR(3)=0x40 can0: REG_IER(4)=0x7f can0: REG_ALC(11)=0x02 can0: REG_ECC(12)=0xa2 can0: REG_EWL(13)=0x60 can0: REG_RXERR(14)=0x87 can0: REG_TXERR(15)=0x00 can0: REG_ACCC0(16)=0x03 can0: REG_ACCC1(17)=0x00 can0: REG_ACCC2(18)=0xa0 can0: REG_ACCC3(19)=0x00 can0: REG_ACCM0(20)=0x00 can0: REG_ACCM1(21)=0x00 can0: REG_ACCM2(22)=0x03 can0: REG_ACCM3(23)=0x00 can0: REG_RMC(29)=0x00 can0: REG_RBSA(30)=0x00 can0: REG_BTR0(6)=0x00 can0: REG_BTR1(7)=0x1c can0: REG_OCR(8)=0x1a can0: REG_CDR(31)=0xc7 can0: REG_FI(16)=0x03 can0: REG_ID1(17)=0x00 can0: REG_ID2(18)=0xa0 can0: REG_ID3(19)=0x00 can0: REG_ID4(20)=0x00 can0: PITA_ICR(0x0)=0x30002 can0: PITA_GPIOICR(0x18)=0x50a00 can0: PITA_MISC(0x1c)=0x4000000 Below is the output of lspci -vv on his board. The working CAN device is 03:00.0. 03:00.0 Network controller: PEAK-System Technik GmbH Device 0008 (rev 02) Subsystem: PEAK-System Technik GmbH Device 0005 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-