Issue 244908 in chromium: Graphics tests seem to be running for a very long time.

[c***@googlecode.com]

Updates:
Summary: Graphics tests seem to be running for a very long time.
Status: Assigned
Owner: ***@chromium.org

Comment #1 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

daisy-release/R27-3912.84.0/graphics/graphics_Sanity:
http://cautotest/afe/#tab_id=view_job&object_id=3142673

daisy-release/R29-4198.0.0/hwqual/graphics_GLBench:
http://cautotest/afe/#tab_id=view_job&object_id=3142382

daisy-release/R29-4198.0.0/graphicsGLES/graphics_GLBench:
http://cautotest/afe/#tab_id=view_job&object_id=3142647

Ilja can you take a look at these? How long should these tests take on
average and is this a common failure mode? If so we may want to add a hard
timeout to the suite control file for tests that are run.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #2 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

Ilja can you chime in here please, these are occupying our machines quite a
bit.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Cc: ***@chromium.org ***@chromium.org
Labels: Cr-OS-Kernel-Graphics

Comment #3 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #4 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

This is still happening, if no one is going to look at this we are going to
disable the tests.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #5 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

Two jobs currently in this mode:
Daisy: http://cautotest/afe/#tab_id=view_job&object_id=3505569
Link: http://cautotest/afe/#tab_id=view_job&object_id=3505237
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Status: Started
Owner: ***@chromium.org
Cc: ***@chromium.org

Comment #6 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

I suspect a mali hang confused glbench.... taking a look.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Cc: ***@chromium.org

Comment #7 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

For job Daisy: http://cautotest/afe/#tab_id=view_job&object_id=3505569

There were two Mali "soft-resets" earlier on this machine, since the last
reboot.
Perhaps this is confusing glbench?

In any case, there doesn't seem to be any glbench output. The process is
just hung.

Below are the mali soft-reset backtraces:


2013-06-25T22:50:41.896730-07:00 localhost kernel: [ 4035.062298]
[<80014890>] (unwind_backtrace+0x0/0xec) from [<80500178>]
(dump_stack+0x20/0x24)
2013-06-25T22:50:41.896770-07:00 localhost kernel: [ 4035.062321]
[<80500178>] (dump_stack+0x20/0x24) from [<802a8610>]
(kbase_mmu_report_fault_and_kill+0x54/0x1c4)
2013-06-25T22:50:41.896780-07:00 localhost kernel: [ 4035.062339]
[<802a8610>] (kbase_mmu_report_fault_and_kill+0x54/0x1c4) from [<802a9660>]
(page_fault_worker+0x40c/0x420)
2013-06-25T22:50:41.896788-07:00 localhost kernel: [ 4035.062357]
[<802a9660>] (page_fault_worker+0x40c/0x420) from [<80045b08>]
(process_one_work+0x210/0x424)
2013-06-25T22:50:41.896795-07:00 localhost kernel: [ 4035.062372]
[<80045b08>] (process_one_work+0x210/0x424) from [<8004612c>]
(worker_thread+0x1f0/0x39c)
2013-06-25T22:50:41.896992-07:00 localhost kernel: [ 4035.062387]
[<8004612c>] (worker_thread+0x1f0/0x39c) from [<8004acc4>]
(kthread+0x9c/0xac)
2013-06-25T22:50:41.897004-07:00 localhost kernel: [ 4035.062402]
[<8004acc4>] (kthread+0x9c/0xac) from [<8000ee48>]
(kernel_thread_exit+0x0/0x8)
2013-06-25T22:50:41.897010-07:00 localhost kernel: [ 4035.062414]
Mali<ERROR,BASE_JD>: Preparing to soft-reset GPU: Soft-stopping all jobs
2013-06-25T22:50:41.897016-07:00 localhost kernel: [ 4035.062461]
[<80014890>] (unwind_backtrace+0x0/0xec) from [<80500178>]
(dump_stack+0x20/0x24)
2013-06-25T22:50:41.897022-07:00 localhost kernel: [ 4035.062477]
[<80500178>] (dump_stack+0x20/0x24) from [<802ac020>]
(kbase_job_done+0x14c/0x340)
2013-06-25T22:50:41.897028-07:00 localhost kernel: [ 4035.062493]
[<802ac020>] (kbase_job_done+0x14c/0x340) from [<802b618c>]
(kbase_job_irq_handler+0x78/0x88)
2013-06-25T22:50:41.897036-07:00 localhost kernel: [ 4035.062510]
[<802b618c>] (kbase_job_irq_handler+0x78/0x88) from [<800836e4>]
(handle_irq_event_percpu+0x4c/0x238)
2013-06-25T22:50:41.897043-07:00 localhost kernel: [ 4035.062525]
[<800836e4>] (handle_irq_event_percpu+0x4c/0x238) from [<8008391c>]
(handle_irq_event+0x4c/0x6c)
2013-06-25T22:50:41.897049-07:00 localhost kernel: [ 4035.062538]
[<8008391c>] (handle_irq_event+0x4c/0x6c) from [<800868f4>]
(handle_fasteoi_irq+0xe0/0x14c)
2013-06-25T22:50:41.897061-07:00 localhost kernel: [ 4035.062552]
[<800868f4>] (handle_fasteoi_irq+0xe0/0x14c) from [<80083040>]
(generic_handle_irq+0x30/0x40)
2013-06-25T22:50:41.897068-07:00 localhost kernel: [ 4035.062565]
[<80083040>] (generic_handle_irq+0x30/0x40) from [<8000ebe4>]
(handle_IRQ+0x88/0xc8)
2013-06-25T22:50:41.897074-07:00 localhost kernel: [ 4035.062578]
[<8000ebe4>] (handle_IRQ+0x88/0xc8) from [<80008574>]
(gic_handle_irq+0x4c/0x70)
2013-06-25T22:50:41.897080-07:00 localhost kernel: [ 4035.062591]
[<80008574>] (gic_handle_irq+0x4c/0x70) from [<8000de80>]
(__irq_svc+0x40/0x60)
2013-06-25T22:50:41.897085-07:00 localhost kernel: [ 4035.062601] Exception
stack(0xe0aabe98 to 0xe0aabee0)
2013-06-25T22:50:41.897090-07:00 localhost kernel: [ 4035.062610]
be80: ef020000
600f0113
2013-06-25T22:50:41.897096-07:00 localhost kernel: [ 4035.062621] bea0:
00000000 00000003 ef020000 00000002 ef020540 81888f00 00000000 802a9e24
2013-06-25T22:50:41.897101-07:00 localhost kernel: [ 4035.062632] bec0:
00000000 e0aabf14 e0aabee0 e0aabee0 802afef4 802afef4 600f0113 ffffffff
2013-06-25T22:50:41.897107-07:00 localhost kernel: [ 4035.062645]
[<8000de80>] (__irq_svc+0x40/0x60) from [<802afef4>]
(kbase_pm_context_active+0xe4/0xf0)
2013-06-25T22:50:41.897118-07:00 localhost kernel: [ 4035.062660]
[<802afef4>] (kbase_pm_context_active+0xe4/0xf0) from [<802a9e64>]
(kbasep_as_do_poke+0x40/0xac)
2013-06-25T22:50:41.897125-07:00 localhost kernel: [ 4035.062675]
[<802a9e64>] (kbasep_as_do_poke+0x40/0xac) from [<80045b08>]
(process_one_work+0x210/0x424)
2013-06-25T22:50:41.897131-07:00 localhost kernel: [ 4035.062689]
[<80045b08>] (process_one_work+0x210/0x424) from [<8004612c>]
(worker_thread+0x1f0/0x39c)
2013-06-25T22:50:41.897138-07:00 localhost kernel: [ 4035.062702]
[<8004612c>] (worker_thread+0x1f0/0x39c) from [<8004acc4>]
(kthread+0x9c/0xac)
2013-06-25T22:50:41.897144-07:00 localhost kernel: [ 4035.062715]
[<8004acc4>] (kthread+0x9c/0xac) from [<8000ee48>]
(kernel_thread_exit+0x0/0x8)
2013-06-25T22:50:41.897148-07:00 localhost kernel: [ 4035.063450]
Mali<ERROR,BASE_JD>: Resetting GPU
2013-06-25T22:50:41.897154-07:00 localhost kernel: [ 4035.063478]
[<80014890>] (unwind_backtrace+0x0/0xec) from [<80500178>]
(dump_stack+0x20/0x24)
2013-06-25T22:50:41.897160-07:00 localhost kernel: [ 4035.063496]
[<80500178>] (dump_stack+0x20/0x24) from [<802ac344>]
(kbasep_reset_timeout_worker+0x78/0x590)
2013-06-25T22:50:41.897166-07:00 localhost kernel: [ 4035.063512]
[<802ac344>] (kbasep_reset_timeout_worker+0x78/0x590) from [<80045b08>]
(process_one_work+0x210/0x424)
2013-06-25T22:50:41.897356-07:00 localhost kernel: [ 4035.063527]
[<80045b08>] (process_one_work+0x210/0x424) from [<8004612c>]
(worker_thread+0x1f0/0x39c)
2013-06-25T22:50:41.897363-07:00 localhost kernel: [ 4035.063542]
[<8004612c>] (worker_thread+0x1f0/0x39c) from [<8004acc4>]
(kthread+0x9c/0xac)
2013-06-25T22:50:41.897369-07:00 localhost kernel: [ 4035.063556]
[<8004acc4>] (kthread+0x9c/0xac) from [<8000ee48>]
(kernel_thread_exit+0x0/0x8)
2013-06-25T22:50:41.897373-07:00 localhost kernel: [ 4035.063623]
Mali<ERROR,BASE_JD>: Reset complete



2013-06-25T22:56:28.946439-07:00 localhost kernel: [ 4382.113865]
[<80014890>] (unwind_backtrace+0x0/0xec) from [<80500178>]
(dump_stack+0x20/0x24)
2013-06-25T22:56:28.946460-07:00 localhost kernel: [ 4382.113888]
[<80500178>] (dump_stack+0x20/0x24) from [<802a8610>]
(kbase_mmu_report_fault_and_kill+0x54/0x1c4)
2013-06-25T22:56:28.946469-07:00 localhost kernel: [ 4382.113905]
[<802a8610>] (kbase_mmu_report_fault_and_kill+0x54/0x1c4) from [<802a9660>]
(page_fault_worker+0x40c/0x420)
2013-06-25T22:56:28.946476-07:00 localhost kernel: [ 4382.113922]
[<802a9660>] (page_fault_worker+0x40c/0x420) from [<80045b08>]
(process_one_work+0x210/0x424)
2013-06-25T22:56:28.946483-07:00 localhost kernel: [ 4382.113936]
[<80045b08>] (process_one_work+0x210/0x424) from [<8004612c>]
(worker_thread+0x1f0/0x39c)
2013-06-25T22:56:28.946490-07:00 localhost kernel: [ 4382.113950]
[<8004612c>] (worker_thread+0x1f0/0x39c) from [<8004acc4>]
(kthread+0x9c/0xac)
2013-06-25T22:56:28.946497-07:00 localhost kernel: [ 4382.113964]
[<8004acc4>] (kthread+0x9c/0xac) from [<8000ee48>]
(kernel_thread_exit+0x0/0x8)
2013-06-25T22:56:28.946502-07:00 localhost kernel: [ 4382.113977]
Mali<ERROR,BASE_JD>: Preparing to soft-reset GPU: Soft-stopping all jobs
2013-06-25T22:56:28.946509-07:00 localhost kernel: [ 4382.114010]
[<80014890>] (unwind_backtrace+0x0/0xec) from [<80500178>]
(dump_stack+0x20/0x24)
2013-06-25T22:56:28.946516-07:00 localhost kernel: [ 4382.114024]
[<80500178>] (dump_stack+0x20/0x24) from [<802ac020>]
(kbase_job_done+0x14c/0x340)
2013-06-25T22:56:28.946523-07:00 localhost kernel: [ 4382.114039]
[<802ac020>] (kbase_job_done+0x14c/0x340) from [<802b618c>]
(kbase_job_irq_handler+0x78/0x88)
2013-06-25T22:56:28.946530-07:00 localhost kernel: [ 4382.114055]
[<802b618c>] (kbase_job_irq_handler+0x78/0x88) from [<800836e4>]
(handle_irq_event_percpu+0x4c/0x238)
2013-06-25T22:56:28.946537-07:00 localhost kernel: [ 4382.114068]
[<800836e4>] (handle_irq_event_percpu+0x4c/0x238) from [<8008391c>]
(handle_irq_event+0x4c/0x6c)
2013-06-25T22:56:28.946544-07:00 localhost kernel: [ 4382.114082]
[<8008391c>] (handle_irq_event+0x4c/0x6c) from [<800868f4>]
(handle_fasteoi_irq+0xe0/0x14c)
2013-06-25T22:56:28.946550-07:00 localhost kernel: [ 4382.114095]
[<800868f4>] (handle_fasteoi_irq+0xe0/0x14c) from [<80083040>]
(generic_handle_irq+0x30/0x40)
2013-06-25T22:56:28.946557-07:00 localhost kernel: [ 4382.114108]
[<80083040>] (generic_handle_irq+0x30/0x40) from [<8000ebe4>]
(handle_IRQ+0x88/0xc8)
2013-06-25T22:56:28.946563-07:00 localhost kernel: [ 4382.114121]
[<8000ebe4>] (handle_IRQ+0x88/0xc8) from [<80008574>]
(gic_handle_irq+0x4c/0x70)
2013-06-25T22:56:28.946569-07:00 localhost kernel: [ 4382.114133]
[<80008574>] (gic_handle_irq+0x4c/0x70) from [<8000de80>]
(__irq_svc+0x40/0x60)
2013-06-25T22:56:28.946574-07:00 localhost kernel: [ 4382.114143] Exception
stack(0xc344fe28 to 0xc344fe70)
2013-06-25T22:56:28.946580-07:00 localhost kernel: [ 4382.114152]
fe20: ef021830 600f0013 00000000 00000000 600f0013
f3402000
2013-06-25T22:56:28.946585-07:00 localhost kernel: [ 4382.114162] fe40:
ef021830 00002008 600f0013 00002418 ef020d30 c344fe84 c344fe70 c344fe70
2013-06-25T22:56:28.946590-07:00 localhost kernel: [ 4382.114171] fe60:
80507710 80507714 600f0013 ffffffff
2013-06-25T22:56:28.946597-07:00 localhost kernel: [ 4382.114184]
[<8000de80>] (__irq_svc+0x40/0x60) from [<80507714>]
(_raw_spin_unlock_irqrestore+0x20/0x24)
2013-06-25T22:56:28.946603-07:00 localhost kernel: [ 4382.114197]
[<80507714>] (_raw_spin_unlock_irqrestore+0x20/0x24) from [<802a85b8>]
(mmu_mask_reenable+0x7c/0x80)
2013-06-25T22:56:28.946611-07:00 localhost kernel: [ 4382.114212]
[<802a85b8>] (mmu_mask_reenable+0x7c/0x80) from [<802a8758>]
(kbase_mmu_report_fault_and_kill+0x19c/0x1c4)
2013-06-25T22:56:28.946618-07:00 localhost kernel: [ 4382.114226]
[<802a8758>] (kbase_mmu_report_fault_and_kill+0x19c/0x1c4) from
[<802a9660>] (page_fault_worker+0x40c/0x420)
2013-06-25T22:56:28.946625-07:00 localhost kernel: [ 4382.114241]
[<802a9660>] (page_fault_worker+0x40c/0x420) from [<80045b08>]
(process_one_work+0x210/0x424)
2013-06-25T22:56:28.946632-07:00 localhost kernel: [ 4382.114254]
[<80045b08>] (process_one_work+0x210/0x424) from [<8004612c>]
(worker_thread+0x1f0/0x39c)
2013-06-25T22:56:28.946639-07:00 localhost kernel: [ 4382.114266]
[<8004612c>] (worker_thread+0x1f0/0x39c) from [<8004acc4>]
(kthread+0x9c/0xac)
2013-06-25T22:56:28.946645-07:00 localhost kernel: [ 4382.114279]
[<8004acc4>] (kthread+0x9c/0xac) from [<8000ee48>]
(kernel_thread_exit+0x0/0x8)
2013-06-25T22:56:28.950887-07:00 localhost kernel: [ 4382.121226]
Mali<ERROR,BASE_JD>: Resetting GPU
2013-06-25T22:56:28.950901-07:00 localhost kernel: [ 4382.121254]
[<80014890>] (unwind_backtrace+0x0/0xec) from [<80500178>]
(dump_stack+0x20/0x24)
2013-06-25T22:56:28.950908-07:00 localhost kernel: [ 4382.121272]
[<80500178>] (dump_stack+0x20/0x24) from [<802ac344>]
(kbasep_reset_timeout_worker+0x78/0x590)
2013-06-25T22:56:28.950915-07:00 localhost kernel: [ 4382.121288]
[<802ac344>] (kbasep_reset_timeout_worker+0x78/0x590) from [<80045b08>]
(process_one_work+0x210/0x424)
2013-06-25T22:56:28.950922-07:00 localhost kernel: [ 4382.121303]
[<80045b08>] (process_one_work+0x210/0x424) from [<8004612c>]
(worker_thread+0x1f0/0x39c)
2013-06-25T22:56:28.950928-07:00 localhost kernel: [ 4382.121316]
[<8004612c>] (worker_thread+0x1f0/0x39c) from [<8004acc4>]
(kthread+0x9c/0xac)
2013-06-25T22:56:28.950935-07:00 localhost kernel: [ 4382.121332]
[<8004acc4>] (kthread+0x9c/0xac) from [<8000ee48>]
(kernel_thread_exit+0x0/0x8)
2013-06-25T22:56:28.955752-07:00 localhost kernel: [ 4382.121906]
Mali<ERROR,BASE_JD>: Reset complete
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #8 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

I manually killed glbench, and tried to re-run it manually on the same
machine, but didn't get very far before the test system took over and
removed it:

localhost ~ # /bin/bash -c X :1 & sleep 1; DISPLAY=:1
/usr/local/autotest/deps/glbench/glbench --blacklist="triangle_setup"
-save -outdir=/usr/local/autotest/results/default/graphics_GLBench; kill $!
[1] 8016

X.Org X Server 1.12.4
Release Date: 2012-08-27
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.0.0-16-server x86_64 Gentoo
Current Operating System: Linux localhost 3.4.0 #1 SMP Mon Jun 24 23:30:16
PDT 2013 armv7l
Kernel command line: cros_secure console= console= loglevel=7
init=/sbin/init cros_secure oops=panic panic=-1 root=/dev/dm-0 rootwait ro
dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=1 dm="1
vroot none ro 1,0 2097152 verity
payload=58bf2c53-e7e9-f54b-8969-88dd95fa7fc5+1
hashtree=58bf2c53-e7e9-f54b-8969-88dd95fa7fc5+1 hashstart=2097152 alg=sha1
root_hexdigest=51b679279254620eebb39bdf4872cb4bb10f5dd1
salt=1c600abc06fb8b9a0693a3c1e2c3b73bb8574b6256c3ed711d0b00f5b4f15b41"
noinitrd cros_debug vt.global_cursor_default=0
kern_guid=58bf2c53-e7e9-f54b-8969-88dd95fa7fc5
Build Date: 24 June 2013 11:48:31PM

Current version of pixman: 0.28.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Jun 26 07:40:09 2013
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(WW) cmt: Cypress APA Trackpad (cyapa): Event_Sync_State():405:
Event_Sync_State: before 35802.762123 after 35802.762134
# Error: in xlib_window.cc::XlibInit() could not open default display.
# Error: Failed to initialize /usr/local/autotest/deps/glbench/glbench.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #9 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

For job Link: http://cautotest/afe/#tab_id=view_job&object_id=3505237

OK, this time I used gdb to see where we are stuck:

localhost ~ # gdb /usr/local/autotest/deps/glbench/glbench 10108
GNU gdb (Gentoo 7.5.1 vanilla) 7.5.1.20130306-cvs
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-cros-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /usr/local/autotest/deps/glbench/glbench...(no
debugging symbols found)...done.
Attaching to program: /usr/local/autotest/deps/glbench/glbench, process
10108

warning: no loadable sections found in added symbol-file system-supplied
DSO at 0x7fffbff32000
0x00007fa051cec114 in __GI___poll (fds=0x7fffbfecc440, nfds=1, timeout=-1)
at ../sysdeps/unix/sysv/linux/poll.c:83
83 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
(gdb) bt
#0 0x00007fa051cec114 in __GI___poll (fds=0x7fffbfecc440, nfds=1,
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:83
#1 0x00007fa051399be2 in ?? () from /usr/lib64/libxcb.so.1
#2 0x00007fa051397ee7 in xcb_connect_to_fd () from /usr/lib64/libxcb.so.1
#3 0x00007fa05139b0bf in xcb_connect_to_display_with_auth_info () from
/usr/lib64/libxcb.so.1
#4 0x00007fa05251895a in _XConnectXCB () from /usr/lib64/libX11.so.6
#5 0x00007fa052508e42 in XOpenDisplay () from /usr/lib64/libX11.so.6
#6 0x00007fa05283c19a in ?? ()
#7 0x00007fa05283d90d in ?? ()
#8 0x00007fa05283ea1c in ?? ()
#9 0x00007fa051c30465 in __libc_start_main (main=0x7fa05283e988, argc=3,
ubp_av=0x7fffbfeccb38, init=<optimized out>,
fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7fffbfeccb28) at libc-start.c:234
#10 0x00007fa05283c019 in ?? ()
#11 0x00007fffbfeccb28 in ?? ()
#12 0x0000000000000000 in ?? ()
(gdb)


So, glbench is stuck trying to connect to the X server using xcb.... which
sounds remarkably like issue 252261.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Cc: ***@chromium.org ***@chromium.org

Comment #10 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #11 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

Meanwhile, X is stuck trying to open the console:

(gdb) bt
#0 0x00007fbe4b28e987 in ioctl () at ../sysdeps/unix/syscall-template.S:82
#1 0x00007fbe4c2009c5 in ?? ()
#2 0x00007fbe4c200c34 in xf86OpenConsole ()
#3 0x00007fbe4c1e33ba in InitOutput ()
#4 0x00007fbe4c196c00 in _start ()

In particular, it is stuck in:
ioctl(xf86Info.consoleFd, VT_WAITACTIVE, vt)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #12 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

/var/log/Xorg.1.log has a nice clue:

[ 117.844] (--) using VT number 3


So... a little nudge got everything moving again:

localhost ~ # chvt 3

-> X grabs the console, and finishes initializing
-> glbench successfully opens its X connection ...
-> glbench continues its tests.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #13 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

The daisy job also was using VT number 3, although according to its
/var/log/Xorg.1.log, it didn't get stuck in the same place:

[ 5476.564] (II) ARMSOC: Driver for TI OMAP: OMAP3430 with PowerVR SGX530,
OMAP3630 with PowerVR SGX530, OMAP4430 with PowerVR SGX540,
OMAP4460 with PowerVR SGX540, OMAP5430 with PowerVR SGX544 MP,
OMAP5432 with PowerVR SGX544 MP, Mali-T60x
[ 5476.564] (--) using VT number 3

[ 5476.573] (WW) Falling back to old probe method for armsoc
[ 5476.573] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card
support
[ 5476.573] (II) ARMSOC(0): Creating default Display subsection in Screen
section
"DefaultScreen" for depth/fbbpp 24/32
...
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Cc: ***@chromium.org

Comment #14 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

Here is how the vt is selected:

if (xf86Info.vtno != -1) {
from = X_CMDLINE;
}
else {
// fd = open(tty, O_WRONLY);
if (xf86Info.ShareVTs) {
SYSCALL(ret = ioctl(fd, VT_GETSTATE, &vts));
if (ret < 0)
FatalError("xf86OpenConsole: Cannot find the current"
" VT (%s)\n", strerror(errno));
xf86Info.vtno = vts.v_active;
}
else {
SYSCALL(ret = ioctl(fd, VT_OPENQRY, &xf86Info.vtno));
if (ret < 0)
FatalError("xf86OpenConsole: Cannot find a free VT: "
"%s\n", strerror(errno));
if (xf86Info.vtno == -1)
FatalError("xf86OpenConsole: Cannot find a free VT\n");
}

In other words:
If vtno was specified on the commandline, use that VT.
Else if ShareVTs is set, use the current VT
Else, use the next free VT.

The special X server used for graphics_GLBench is invoked with NO
commandline arguments, neither a vt, nor "-sharevts", so the X server will
try to find the next free VT.

This new X server is started immediately after "stop ui". However, "stop
ui" doesn't actually wait for the X server to shut down before it returns.
Thus, if we start the new X server too fast, it can find the old "ui" X
server is still occupying VT-1. VT-2 is the VT-2 console. Hence, the next
available is VT-3.

However... that console isn't activated until someone does "chvt 3" (or
Ctrl-Alt-F3), and the X server gets stuck in an ioctl waiting.

There are a few ways to fix this:
(a) start the test X server with commandline arg "vt1"
(b) sleep a bit between stop ui and starting the new X server (note:
jrbarnette & I have been meaning to talk about actually make "stop ui" wait
for the X server to stop, that would have solved this problem, too)
(c) start the test X server commandline arg -sharevts
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Cc: ***@chromium.org

Comment #16 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

The daisy hangs are quite different, and are not related to the VT3 race.

For example, here is a hang in R28-4100.61.0:
http://cautotest/afe/#tab_id=view_job&object_id=3579151

It turns out that glbench always hangs now on R28. After much digging,
this was broken by a recent patch to mali-ddk.

Please see http://crosbug.com/p/18857 for more details.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Cc: ***@chromium.org

Comment #17 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Blockedon: chrome-os-partner:18857

Comment #18 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Blockedon: -chrome-os-partner:18857 chrome-os-partner:20641

Comment #19 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

Update to #16:
The fix for issue http://crosbug.com/p/18857 introduced a specific
regression, see:
http://crosbug.com/p/20641
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #24 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

graphics_Sanity is completely broken on arm.
However, I'm trying to figure out why it is being run at all.
It is part of the "graphics" test suite. It is NOT part of
the "graphicsGLES" suite.

For (such as 'daisy' and 'daisy spring'), we want to be running
the "graphicsGLES" test suite, not the "graphics" test suite.

Where is that specified?
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Owner: ***@chromium.org

Comment #25 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

I found in the autotest repo suite_scheduler.ini, which includes stanzas
for these suites:

[NightlyGraphics]
run_on: nightly
suite: graphics
branch_specs: >=R21
pool: suites

[GraphicsGLES]
run_on: nightly
suite: graphicsGLES
branch_specs: >=R22
pool: snow

I'm not sure where the "pools" are specified.

I think machines are supposed to be split into two pools for the purposes
of the two graphics suites:
a pool that runs suite:graphicsGLES (snow, daisy and friends)
a pool that runs suite:graphics (everything else)

Assigning to ihf for a historical perspective :)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Blockedon: chromium:271152

Comment #26 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

Issue trackign graphics_Sanity broken on arm is here: chromium:271152
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #27 on issue 244908 by ***@chromium.org: Graphics tests seem
to be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

You are correct.

https://gerrit.chromium.org/gerrit/#/c/27183/2

Also the pool:snow label has only been applied to only daisy devices.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #29 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

AFAICT, all of the boards that would be in pool:snow are also in
pool:suites. Therefore they would actually get both suites (Graphics &
GraphicsGLES) run on them.

Since both suites have graphics_GLBench, this means that GLBench would be
run twice on any pool:snow machines.

GraphicsGLES only has one other test: graphics_SyncControlTest This test
*can* be run on any board, but it only checks something useful on daisy et
al at present.

AFAICT, all tests *can* be run on all platforms, although sometimes the
test may be noop. If individual tests have per-platform quirks, they are
usually handled by the individual test (like SanAngeles using the GLES or
GL version of itself).

Thus, I am tempted to just kill the GraphicsGLES suite entirely, since it
just makes managing which tests are run on which machine more difficult,
since boards must be manually partitioned into two different pools, and the
two suites are mostly if not entire identical.

Am I missing something?
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Cc: ***@chromium.org

Comment #30 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

johndhong: How is the "pool" applied? How do we manage these assignments?
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Cc: ***@chromium.org

Comment #31 on issue 244908 by ***@chromium.org: Graphics tests seem
to be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

A "pool" is used to schedule out-of-band testing via through the
suite_scheduler.ini file. The "pool" label is added to a host/DUT like so.

Most of the time the label is added by the lab team. Although there is
future work which is wrapping up (hopefully soon) which will eliminate the
need for a "pool" label.

How to add label to host
~/chromiumos/src/third_party/autotest/files/cli$ ./atest label add
pool:wifichaos -m chromeos3-row2-rack2-host16

Multiple hosts
~/chromiumos/src/third_party/autotest/files/cli$ ./atest label add
pool:wifichaos -m chromeos3-row4-rack2-host15,chromeos3-row4-rack2-host16
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #32 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

Oh, I see. The pool refers to the actual test machines. So, do you agree
with my assessment in #29? "daisy" machines in the lab would be in
both "suites" and "snow", and therefore would actually run both graphics
and graphicsGLES per the suite definitions in #25?
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #33 on issue 244908 by ***@chromium.org: Graphics tests seem
to be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

In this case yes all snow devices that are in "pool:suites" are also
in "pool:snow". So both test suites are being ran on snow devices.

chromeos1-rack8a-host1 snow bluetooth, hw_rev:mp, board:daisy,
wifi,string,CrOS_Netgear_WGR614_Lab,rsn,chromeoslab, remote_power, webcam,
pool:snow, pool:suites, pool:try-bot, hw_video_acc_h264, pool:power,
cros-version:daisy-release/R30-4533.0.0 Ready No
chromeos1-rack8a-host2 snow bluetooth, hw_rev:mp,
wifi,string,CrOS_Netgear_WGR614_Lab,rsn,chromeoslab, board:daisy,
remote_power, webcam, pool:snow, pool:suites, pool:try-bot,
hw_video_acc_h264, crbug.com/221637, video_decode_v4l2, pool:power,
cros-version:daisy-release/R28-4100.84.0 Repairing No
chromeos2-row5-rack1-host10 snow board:daisy, pool:suites, pool:snow,
bluetooth, webcam, hw_rev:mp, lightsensor, pool:vda, hw_video_acc_vp8,
hw_video_acc_h264, video_decode_v4l2, pool:power,
cros-version:daisy-release/R30-4533.0.0 Ready No
chromeos2-row5-rack1-host11 snow board:daisy, pool:suites, pool:snow,
bluetooth, webcam, hw_rev:mp, pool:vda, hw_video_acc_vp8,
hw_video_acc_h264, video_decode_v4l2, pool:power,
cros-version:daisy-release/R30-4533.0.0 Ready No
chromeos2-row5-rack1-host12 snow bluetooth, hw_rev:mp, board:daisy,
pool:suites, webcam, pool:snow, lightsensor, pool:vda, hw_video_acc_vp8,
hw_video_acc_h264, video_decode_v4l2, pool:power,
cros-version:daisy-release/R30-4533.0.0 Ready No
chromeos2-row5-rack1-host8 snow board:daisy, pool:suites, pool:snow,
bluetooth, webcam, hw_rev:mp, pool:vda, hw_video_acc_vp8,
hw_video_acc_h264, video_decode_v4l2, pool:power,
cros-version:daisy-release/R30-4533.0.0 Ready No
chromeos2-row5-rack2-host11 snow bluetooth, hw_rev:mp, board:daisy,
pool:suites, webcam, pool:snow, lightsensor, pool:vda, hw_video_acc_vp8,
hw_video_acc_h264, video_decode_v4l2, pool:power,
cros-version:daisy-release/R30-4533.0.0 Ready No
chromeos2-row5-rack3-host12 snow bluetooth, hw_rev:mp, board:daisy,
pool:suites, webcam, pool:snow, lightsensor, pool:vda, hw_video_acc_vp8,
hw_video_acc_h264, video_decode_v4l2, pool:power,
cros-version:daisy-release/R30-4533.0.0 Ready No
chromeos2-row5-rack3-host8 snow pool:vda, bluetooth, lightsensor,
wifi,string,WL-CHROMEOS,rsn,Chromeos1, board:daisy, hw_rev:mp, pool:suites,
webcam, pool:snow, hw_video_acc_vp8, hw_video_acc_h264, video_decode_v4l2,
pool:power, cros-version:daisy-release/R30-4533.0.0 Ready No
chromeos2-row5-rack3-host9 snow pool:vda, bluetooth, lightsensor,
wifi,string,WL-CHROMEOS,rsn,Chromeos1, board:daisy, hw_rev:mp, pool:suites,
webcam, pool:snow, hw_video_acc_vp8, hw_video_acc_h264, video_decode_v4l2,
pool:power, cros-version:daisy-release/R30-4530.0.0 Running No
chromeos2-row5-rack4-host10 snow bluetooth, hw_rev:mp, board:daisy,
pool:suites, webcam, pool:snow, lightsensor, pool:vda, hw_video_acc_vp8,
hw_video_acc_h264, video_decode_v4l2, pool:chromeperf, pool:power,
cros-version:daisy-chrome-perf/R30-4521.0.0-b1615 Running No
chromeos2-row5-rack4-host11 snow bluetooth, hw_rev:mp, board:daisy,
pool:suites, webcam, pool:snow, lightsensor, pool:vda, hw_video_acc_vp8,
hw_video_acc_h264, video_decode_v4l2, pool:chromeperf, pool:power,
cros-version:daisy-chrome-perf/R30-4521.0.0-b1615 Ready No
chromeos2-row5-rack4-host12 snow bluetooth, hw_rev:mp, board:daisy,
pool:suites, webcam, pool:snow, lightsensor, pool:vda, hw_video_acc_vp8,
hw_video_acc_h264, video_decode_v4l2, pool:chromeperf, pool:power,
cros-version:daisy-chrome-perf/R30-4521.0.0-b1615 Ready No
chromeos2-row5-rack4-host7 snow bluetooth, hw_rev:mp, board:daisy,
pool:suites, webcam, pool:snow, lightsensor, pool:vda, hw_video_acc_vp8,
hw_video_acc_h264, video_decode_v4l2, pool:power,
cros-version:daisy-release/R30-4533.0.0 Ready No
chromeos2-row5-rack4-host8 snow bluetooth, hw_rev:mp, board:daisy,
pool:suites, webcam, pool:snow, lightsensor, pool:vda, hw_video_acc_vp8,
hw_video_acc_h264, video_decode_v4l2, pool:power,
cros-version:daisy-release/R30-4533.0.0 Ready No
chromeos2-row5-rack4-host9 snow bluetooth, hw_rev:mp, lightsensor,
board:daisy, pool:suites, webcam, pool:snow, pool:vda, hw_video_acc_vp8,
hw_video_acc_h264, video_decode_v4l2, pool:chromeperf, pool:power,
cros-version:daisy-chrome-perf/R30-4521.0.0-b1615
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #34 on issue 244908 by ***@chromium.org: Graphics tests seem to be
running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

With regards to #29, there are conflicting opinions what should happen if a
test requiring capability A is scheduled on a board not providing
capability A. Silently skipping the test leads to silent failures. One
could warn or fail. (Usually the latter, think of webcam or hardware
decode.) In my opinion a compromise for graphics tests would be to try not
to schedule but if scheduled have a warning.

Also, that *now* snow and suites overlap does not mean it always was the
case. The naming of course is unfortunate. As I wrote, it would be nice not
to have predefined pools like above. I understand we have different skews
for boards but it is sad that the pool is defined on a rack/host level.

Again, I'd be happier if we had 2 distinct pools for graphics tests
(separating essentially Intel and ARM).
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #35 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

ihf: Is the following your recommended approach:

(1) Use two separate test suites: graphics and graphicsGL.
(a) create a new pool for all GL boards (ie, all but the current arm
ones) named "graphics_gl"
(b) create a second new pool for all GLES boards (ie, daisy, et al)
named "graphics_gles"
(c) rename the "graphics" suite to "graphicsGL"
(c) rename NightlyGraphics to NightlyGraphicsGL, assign to
suite "graphicsGL" and pool "graphics_gl"
(d) rename GraphicsGLES to NightlyGraphicsGLES, assign to
suite "graphicsGLES" and pool "graphics_gles"
(e) correctly assign the individual graphics autotests to either
suite "graphics_gl", "graphics_gles", or both.
(f) fix tests to fail gracefully, but with a test failure if any required
capability is reported as not supported (to catch tests incorrectly
scheduled on devices lacking a required capability)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #36 on issue 244908 by ***@chromium.org: Graphics tests seem to be
running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

Yes. But before starting work lets get input from all graphics stakeholders.

As for (f) - the autotest dashboard has a way of emitting a warning. I am
not familiar if wmatrix has a similar mode, but it seems to do a good job
with "failure reasons".
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #37 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

The difficulty in the approach in #35 is that someone must "manually" [0]
configure each DUT into exactly one of the two pools "graphics_gles"
or "graphics_gl".

[0] Or DUTs could be semi-automatically configured based on board name
rules, and the manual step would be in updating the
board-to-graphics_test_pool rule.

This seems like it might cause some scalability issues, but perhaps it is
not so onerous on the HWTest team, since it is probably a relatively rare
event that they provision new HWTest racks.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #38 on issue 244908 by ***@chromium.org: Graphics tests seem to be
running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

I guess the docs say to use error.TestNAError. Of course as Stephane points
out that looks like a common failure on the dash which is regrettable.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #39 on issue 244908 by ***@chromium.org: Graphics tests seem to be
running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

Re: #37. Unlike some other properties (optional hardware pieces), we should
indeed be able to define DUT configurations based on board names only. So
it hopefully is not labor intense to change.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #40 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

ihf: OK. I opened issue 271917 to host that discussion. Can you please
help me ping "all graphics stakeholders" for input? (I'm not really sure
who all you had in mind).
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #41 on issue 244908 by ***@chromium.org: Graphics tests seem
to be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908#c41

Project: chromiumos/third_party/autotest
Branch : master
Author : Daniel Kurtz <***@chromium.org>
Commit : 99552380f1cffe5af607be8359afdc1957fd9827

Code Review +2: Daniel Kurtz, Ilja H. Friedel
Verified +1: Daniel Kurtz
Change-Id : Idafa2b78fe4954f57b918fc7909579f9724551de
Reviewed-at : https://gerrit.chromium.org/gerrit/65576

graphics_GLBench: Make sure X server is really dead before restarting ui

This test:
1) stops ui
2) starts an X server
3) runs some tests
4) stops its X server
5) starts ui

Step 4 however wasn't actually waiting for the X server to die before
starting a new one in step 5. Unfortunately, this is a problem (See
http://crbug.com/265804 for details). The ui.conf upstart script solves
this by calling the term_process function of /sbin/killers to wait for
X to stop before respawning. We use the same script function here for
consistency.

BUG=chromium:244908
TEST=Tested on link where X dies very, very slowly (>1.5 seconds)
0) Ensure DUT ui is already started
1) ./run_remote_tests.sh --remote=${DUT_IP} graphics_GLBench/control$
=> ui stops, test runs, ui restarted when test ends
2) ./run_remote_tests.sh --remote=${DUT_IP} graphics_GLBench/control$
=> Same for second run: ui stops, test runs, ui restarted when test ends

Commit-Queue: Daniel Kurtz <***@chromium.org>

M client/site_tests/graphics_GLBench/graphics_GLBench.py
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Comment #42 on issue 244908 by ***@chromium.org: Graphics tests seem
to be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908#c42

Project: chromiumos/third_party/autotest
Branch : master
Author : Daniel Kurtz <***@chromium.org>
Commit : e0a9f182f8b236a53ae5378811b5ff4b12f1651d

Code Review +2: Daniel Kurtz, Ilja H. Friedel
Verified +1: Daniel Kurtz
Change-Id : I61aa933f33f612fa56c47b7c57a2da089efd5197
Reviewed-at : https://gerrit.chromium.org/gerrit/65577

graphics_GLBench: Always use VT1 when starting X server

If not specified on the command line, it is possible for the X server to
start on a VT other than 1.

Explicitly set the VT to 1, and also explicitly ensure the current VT
is 1 (chvt 1) before starting the test program.

Signed-off-by: Daniel Kurtz <***@chromium.org>

BUG=chromium:244908
TEST=./run_remote_tests graphics_GLBench --remote=${IP}
Test should pass (and be visible in realtime on display).
Check /var/log/Xorg.1.log for:
(--) using VT number 1

Commit-Queue: Daniel Kurtz <***@chromium.org>

M client/site_tests/graphics_GLBench/graphics_GLBench.py
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Labels: Iteration-88

Comment #43 on issue 244908 by ***@chromium.org: Graphics tests seem
to be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Blockedon: chromium:272598

Comment #44 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

Since the link issue of comment #5 (and analyzed in comments #9, 11, 12 and
14) is still occuring, I've split it off into its own issue 272598

This should be fixed on ToT by patches in comments #41 and #42:
https://gerrit.chromium.org/gerrit/65576
https://gerrit.chromium.org/gerrit/65577
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Status: Started
Owner: ***@chromium.org

Comment #45 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Status: Fixed

Comment #46 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

The two main remaining issues (daisy: issue 271152 link: issue 272598)
should all be fixed now on ToT and R30.

ScottZ: Please let us know if you still see slow graphics_* runs (for
R30+) in the HW Lab.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[c***@googlecode.com]

Updates:
Status: Verified

Comment #47 on issue 244908 by ***@chromium.org: Graphics tests seem to
be running for a very long time.
http://code.google.com/p/chromium/issues/detail?id=244908

(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings