From: alexey.kodanev@oracle.com
To: Jan Stancek <jstancek@redhat.com>
Cc: vasily isaenko <vasily.isaenko@oracle.com>,
ltp-list@lists.sourceforge.net
Subject: Re: [LTP] [PATCH v2] fw_load: new test of device firmware loading
Date: Fri, 14 Jun 2013 18:44:40 +0400 [thread overview]
Message-ID: <51BB2C58.4040405@oracle.com> (raw)
In-Reply-To: <104332332.3007867.1371217696167.JavaMail.root@redhat.com>
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 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
next prev parent reply other threads:[~2013-06-14 14:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-14 11:17 [LTP] [PATCH v2] fw_load: new test of device firmware loading Alexey Kodanev
2013-06-14 13:48 ` Jan Stancek
2013-06-14 14:44 ` alexey.kodanev [this message]
2013-06-14 15:16 ` Jan Stancek
2013-06-17 8:39 ` alexey.kodanev
2013-06-17 8:50 ` Jan Stancek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51BB2C58.4040405@oracle.com \
--to=alexey.kodanev@oracle.com \
--cc=jstancek@redhat.com \
--cc=ltp-list@lists.sourceforge.net \
--cc=vasily.isaenko@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.