Re: [LTP] [PATCH v2] fw_load: new test of device firmware loading

[Jan Stancek <jstancek@redhat.com>]

----- Original Message -----
> From: "alexey kodanev" <alexey.kodanev@oracle.com>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp-list@lists.sourceforge.net, "vasily isaenko" <vasily.isaenko@oracle.com>
> Sent: Friday, 14 June, 2013 4:44:40 PM
> Subject: Re: [LTP] [PATCH v2] fw_load: new test of device firmware loading
> 
> Hi!
> 
> On 06/14/2013 05:48 PM, Jan Stancek wrote:
> > Hi,
> >
> > I ran this on older kernel, which worked fine - it skipped the build.
> > Then I tried RHEL7 alpha, which has more recent kernel: 3.10.0-0.rc4,
> > but it failed:
> >
> > # ./fw_load
> > cp: cannot stat ‘/lib/udev/rules.d/50-firmware.rules’: No such file or
> > directory
> > fw_load     1  TBROK  :  Failed to copy
> > '/lib/udev/rules.d/50-firmware.rules' to '/etc/udev/rules.d/' at
> > fw_load.c:164
> > fw_load     2  TBROK  :  Remaining cases broken
> > fw_load     0  TWARN  :  tst_rmdir: TESTDIR was NULL; no removal attempted
> >
> > I'll see if I can find out what happened to 50-firmware.rules,
> > it could some side-effect of systemd.
> >
> Would it be better to change failed copy command to just TWARN, and
> continue testing? After that, test will completed with udev failed
> test-cases, or if udev has those rules in the other configuration files,
> everything will be fine.

I'd go with TCONF or skip udev testcases if we can't be sure that udev is running
and properly configured.

I'm also missing firmware.sh, in new udev (now merged with systemd tree),
50-firmware.rules file depends on some compile switch. Even when enabled
the rule looks like this:
http://cgit.freedesktop.org/systemd/systemd/tree/rules/50-firmware.rules

firmware.sh appears to be converted to .c now:
http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-firmware.c

Regards,
Jan

> I just checked it on my machine, output will be:
> fw_load     1  TPASS  :  Expect: can load firmware '.../n0_load_tst.fw',
> kernel used
> fw_load     2  TPASS  :  Expect: can load firmware '.../n1_load_tst.fw',
> kernel used
> fw_load     3  TPASS  :  Expect: can load firmware '.../n2_load_tst.fw',
> kernel used
> fw_load     4  TPASS  :  Expect: can load firmware '.../n3_load_tst.fw',
> kernel used
> fw_load     5  TFAIL  :  Expect: can load firmware '.../n4_load_tst.fw',
> udev used
> fw_load     6  TFAIL  :  Expect: can load firmware '.../n5_load_tst.fw',
> udev used
> fw_load     7  TFAIL  :  Expect: can load firmware '.../n6_load_tst.fw',
> udev used
> fw_load     8  TFAIL  :  Expect: can load firmware '.../n7_load_tst.fw',
> udev used
> fw_load     9  TPASS  :  Expect: can't load firmware
> '...n8_load_tst.fw', udev used
> 
> Interestingly, but in that case (udev doesn't have add firmware rule)
> udev doing it so long (test-cases 5 - 9), it is not surprisingly that
> right now firmware loading by-pass udev!
> > I found this initialization a little confusing, since your test
> > always relies on passing it from user-space (which passes 9):
> >
> >> +static int fw_num	= 8;
> It is default value, and never used in the test (always replaced by
> module parameter)... OK, I will change it, also I will skip fw_num
> parameter in the userspace test as it will become useless.
> 
> Thanks,
> Alexey
> 

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list