disk-io-stress-switching test fails on ubuntu

Bug #979579 reported by Avik Sil on 2012-04-12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
big.LITTLE Reference Switcher
Dave Martin

Bug Description

Hwpack: http://snapshots.linaro.org/oneiric/hwpacks/vexpressdt-rtsm/33/hwpack_linaro-vexpressdt-rtsm_20120411-33_armel_unsupported.tar.gz

Running disk-io-stress-switching fails with following output:

root@linaro-nano:~/core# ./disk-io-stress-switcher/disk-io-stress-switcher.sh -f big -c 4 -s 1

Switching to big mode if not already in.
Start ..

Running /usr/local/bin/boot-a15.sh 4

Number of CPUs expected in the system = 4
Number of CPUs brought up during boot = 4
cpu3 is big
cpu2 is big
cpu1 is big
cpu0 is big

boot-a15 finished successfully

Starting bigLITTLE switcher in the background

Running iozone -a -i 0 -i 2 -s 16m -V teststring
CPU count: 4
CPU0: big freq 1000000 LITTLE freq 100000
CPU1: big freq 1000000 LITTLE freq 100000
CPU2: big freq 1000000 LITTLE freq 100000
CPU3: big freq 1000000 LITTLE freq 100000
Periodic switcher time 1
        Iozone: Performance Test of File I/O
                Version $Revision: 3.373 $
                Compiled for 32 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.

        Run began: Thu Apr 12 02:33:39 2012

        Auto Mode
        File size set to 16384 KB
        Verify Mode. Pattern 3a3a3a3a
        Performance measurements are invalid in this mode.
        Command line used: iozone -a -i 0 -i 2 -s 16m -V teststring
        Output is in Kbytes/sec
        Time Resolution = 0.000002 seconds.
        Processor cache size set to 1024 Kbytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                            random random bkwd record stride
              KB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
           16384 4 51945 86955 26120 87218
           16384 8 57100 97571 27348 100652
           16384 16failed to write scaling_setspeed, errno 22
failed to write scaling_setspeed, errno 22
cpu0 scaling_setspeed target 100000 current 1000000... FAIL
error on iteration 1169 period 1
Time elapsed: 0:00:49.1000
   59201 104080 28094 109220
           16384 32 60671 107668 28434 113783
           16384 64 61248 109468 28610 115751
           16384 128 61533 110444 28700 115897
           16384 256 61699 110954 28741 114391
           16384 512 61762 111142 28766 110502
           16384 1024 61842 111342 28776 103126
           16384 2048 61902 111474 28778 90844
           16384 4096 61919 111557 28784 73296
           16384 8192 61947 111596 28786 52824
           16384 16384 61952 111584 28785 33892

iozone test complete.
Iozone finished successfully

Kill bigLITTLE switcher
bigLITTLE switcher not running. Report Error!!

Paul Larson (pwlars) on 2012-04-17
Changed in linaro-big-little-reference:
assignee: nobody → Dave Martin (dave-martin-arm)
Dave Martin (dave-martin-arm) wrote :

@Avik, is the "ondemand" boot script definitely disabled?

By default, this job will switch to the ondemand governor a certain amount of time after boot, which may cause strange things to happen.

I'm still not sure why we are seeing EPERM here, though. Rejected write() calls to the cpufreq interface in sysfs usually result in EINVAL instead.

Avik Sil (aviksil) wrote :

Dave, ondemand boot script was disabled using 'update-rc.d -f ondemand remove'

Did you get EPERM error anywhere? I got only errno 22 which I think translates to EINVAL.

Dave Martin (dave-martin-arm) wrote :

Duh, you're right. 22 is EINVAL. I've no idea how I managed to conclude that this was EPERM.

Whis is kind of reassuring -- EINVAL is at least a normal error code here.

Did you do update-rc.d -f ondemand remove immediately before running the test?

I found that this is not necessarily enough, because this job will already have started and will be sleeping in the background by the time you get a prompt. Could this be the cause of the problem?

Instead, you either need to explicitly kill it (you may be able to use start-stop-daemon --oknodo --stop --exec /etc/init.d/ondemand), or reboot after removing the job.

Avik Sil (aviksil) wrote :

Yeah, I ran the test after immediately (kind of) running 'update-rc.d -f ondemand remove'. So this can explain the expected behavior.

Dave Martin (dave-martin-arm) wrote :

@Avik: Is this bug still outstanding, or can we close it?

Avik Sil (aviksil) wrote :

No, it's not happening any more. You can close it.

Mounir Bsaibes (mounir-bsaibes) wrote :

I have set the priority to just Medium, since it is not happening any longer.

Changed in linaro-big-little-reference:
importance: Undecided → Medium
Dave Martin (dave-martin-arm) wrote :

Should we close this bug, if it is no longer observed?

Mounir Bsaibes (mounir-bsaibes) wrote :

I have marked this bug as invalid, if it happens again, we'll open a separate bug.

Changed in linaro-big-little-reference:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers