lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 22 Mar 2010 13:12:34 -0700
From:	"Ira W. Snyder" <iws@...o.caltech.edu>
To:	Wolfgang Grandegger <wg@...ndegger.com>
Cc:	socketcan-core@...ts.berlios.de, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, sameo@...ux.intel.com
Subject: Re: [PATCH 2/3] can: add support for Janz VMOD-ICAN3 Intelligent
 CAN	module

On Mon, Mar 22, 2010 at 08:23:42PM +0100, Wolfgang Grandegger wrote:
> Wolfgang Grandegger wrote:
> > Ira W. Snyder wrote:
> >> On Sat, Mar 20, 2010 at 08:55:16AM +0100, Wolfgang Grandegger wrote:
> >>> Ira W. Snyder wrote:
> > [snip]
> >>>> Does this seem right? It seems pretty good to me.
> >>> Yes, I'm just missing an error-passive message. What state does "ip -d
> >>> link show can0" report.
> >>>
> >> Ok, here is what I did:
> >>
> >> $ ip link set can0 up type can bitrate 1000000
> >> $ ip link set can1 up type can bitrate 1000000 berr-reporting on
> >> $ ip -d -s link
> >> 5: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
> >>     link/can       
> >>     can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
> >>     bitrate 1000000 sample-point 0.750
> >>     tq 125 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 1
> >>     janz-ican3: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
> >>     clock 8000000  
> >>     re-started bus-errors arbit-lost error-warn error-pass bus-off
> >>     0          0          0          0          0          0
> >>     RX: bytes  packets  errors  dropped overrun mcast
> >>     0          0        0       0       0       0
> >>     TX: bytes  packets  errors  dropped carrier collsns
> >>     0          0        0       0       0       0
> >> 6: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
> >>     link/can       
> >>     can <BERR-REPORTING> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
> >>     bitrate 1000000 sample-point 0.750
> >>     tq 125 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 1
> >>     janz-ican3: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
> >>     clock 8000000  
> >>     re-started bus-errors arbit-lost error-warn error-pass bus-off
> >>     0          0          0          0          0          0
> >>     RX: bytes  packets  errors  dropped overrun mcast
> >>     0          0        0       0       0       0
> >>     TX: bytes  packets  errors  dropped carrier collsns
> >>     0          0        0       0       0       0
> >>
> >> Now, in seperate windows, I ran cansequence and candump. I stopped
> >> cansequence when it could not send any more packets (due to the cable
> >> being unplugged).
> >>
> >> $ cansequence -v -e -p can0
> >> $ cansequence -v -e -p can1
> >> $ candump any,0~0,#FFFFFFFF
> >>   can0  20000004  [8] 00 08 00 00 00 00 00 00   ERRORFRAME
> >>   can1  20000088  [8] 00 00 80 19 00 00 00 00   ERRORFRAME
> >>   can1  20000088  [8] 00 00 80 19 00 00 00 00   ERRORFRAME
> >>   can1  20000088  [8] 00 00 80 19 00 00 00 00   ERRORFRAME
> >>   can1  20000088  [8] 00 00 80 19 00 00 00 00   ERRORFRAME
> >>   can1  20000088  [8] 00 00 80 19 00 00 00 00   ERRORFRAME
> >>   can1  20000088  [8] 00 00 80 19 00 00 00 00   ERRORFRAME
> >>   can1  20000088  [8] 00 00 80 19 00 00 00 00   ERRORFRAME
> >>   can1  20000088  [8] 00 00 80 19 00 00 00 00   ERRORFRAME
> >>   can1  20000088  [8] 00 00 80 19 00 00 00 00   ERRORFRAME
> >>   can1  20000088  [8] 00 00 80 19 00 00 00 00   ERRORFRAME
> >>   can1  20000088  [8] 00 00 80 19 00 00 00 00   ERRORFRAME
> >>   can1  20000004  [8] 00 08 00 00 00 00 00 00   ERRORFRAME
> >>   can1  20000088  [8] 00 00 80 19 00 00 00 00   ERRORFRAME
> >>   can1  20000088  [8] 00 00 80 19 00 00 00 00   ERRORFRAME
> >>   can1  20000088  [8] 00 00 80 19 00 00 00 00   ERRORFRAME
> >>   can1  20000088  [8] 00 00 80 19 00 00 00 00   ERRORFRAME
> >>
> >> This last message is repeated lots more times. That's the flooding we're
> >> avoiding with berr-reporting off.
> >>
> >> I see two types of messages here:
> >> 1) bus error (only on can1)
> >> 2) controller problems -- tx warning limit reached (both)
> >>
> >> Am I missing some message? My error frame generation was mostly copied
> >> from the sja1000 driver.
> > 
> > It seem that you are not getting the error passive interrupt even...
> 
> Because you do not enable/handle it. CEVTIND_EPI seems to be missing:
> 
> http://lxr.linux.no/#linux+v2.6.33/drivers/net/can/sja1000/sja1000.c#L403
> 

See the message I just sent. In short, the firmware coalesces the IRQ_EI
and IRQ_EPI messages into CEVTIND_EI. You can only tell them apart via
the rxerr and txerr registers.

Ira
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ