[ILUG] Solved - [Q] USB/udev - how to debug rules not(?) being run?

[Brian Foster]

  | Date: Wed, 16 Jan 2008 08:27:04 +0100
  | From: Brian Foster <blf at utvinternet.ie>
  |[ ... ]
  |  I'm struggling with the installation of some
  |  specialist USB kit; in particular of an FS²
  |  (First Silicon Systems) JTAG Probe (Linux host
  |  software 2.1.8.8) on Kubuntu 7.10 (64-bit).
  | 
  |  there seem to be two issues:
  | 
  |  1st, the Probe does not seem to be coming to
  |      life [ ... ]
  | 
  |  2nd, the FS² software installation expected
  |      `hotplug'(/`usbfs'?), whilst I'm using
  |      `udev' [ ... ]
  | 
  |  using `udevmonitor' I can see the Probe being
  |  detected when I plug it in [ ... but the FS²
  |  `udev' rules are not being used ... ].
  | 
  |  in [other] words, "an" USB unit is being detected,
  |  and has the right ID to match the FS² udev rules,
  |  but those rules do not seem to be run.
  | 
  |  the logfiles do not seem to contain anything
  |  interesting.
  | 
  |  any suggestions or ideas on how I can obtain a
  |  better idea what is / isn't happening?

 solved (and, even better, understood!).

 1st, I had to convince myself the FS² rules were
 really being read/accepted by udevd(8).  this was
 done by deliberately inserting a bogus FOO="bar"
 field in the rules.  `udevd' logged that it had
 no idea what `FOO' was.  Ok, so it is being read.
 remove the bogus field and proceed.

 2nd, to try and get a handle on whether or not the
 rules were really being run, I modified the PROGRAM
 or RUN fields' value to be (in essence):

    /bin/sh -c 'exec 2>>/tmp/FS2; set -x; ...'

 where the «...» was the original contents of the RUN
 or PROGRAM field.  the above should log the running
 of «...» in the file /tmp/FS2.  but that file was
 never created, proving the rules really were not
 being run.
 (the “sh -c '...'” bracketing was because the man
 page was unclear whether or not the shell was used,
 and I did not feel like solving that minor mystery.)

 why not?  I had to guess:  I observed that the FS²
 rules used a SUBSYSTEM of “usb_device”, which (from
 the other files) seemed to be obsolete.  hum .... I
 took a leap and changed that to the “usb” SUBSYSTEM.

 bingo!  the /tmp/FS2 file was created, and showed
 some of the FS² rules were working, and some weren't.

 3rd, RFTM (again!).  this time, I notice that if a
 rule had specified a NAME, any subsequent matching
 rule which also did would be ignored.  ah!  the FS²
 rules were NAMEing nodes, and the generic files,
 run earlier, were also ....   so some rewriting
 (and, as it happens, simplification), produced a
 set of working rules (for the original “usb_device”
 SUBSYSTEM, which seems to better match the original
 intent).

 so that's “How to Debug ...” in this case.

 now the problem is the software downloaded to the
 embedded development board connected to the FS²
 Probe seems to be doing fsck all ..... *sigh*!

cheers!
	-blf-

p.s.  there were not, b.t.w., two separate issues;
     they turned out to be the same thing.  the FS²
     Probe does not come to life until the 1st(?)
     rule is run, which downloads some software
     (using `fxload').

-- 
“How many surrealists does it take to    |  Brian Foster
 change a lightbulb?  Three.  One calms  |  somewhere in south of France
 the warthog, and two fill the bathtub   |     Stop E$$o (ExxonMobile)!
 with brightly-coloured machine tools.”  |       http://www.stopesso.com