Opened 17 years ago
Closed 16 years ago
#1873 closed bug (invalid)
GLTeapot causes system hang on real hardware
| Reported by: | qyellow | Owned by: | axeld |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | Applications | Version: | R1/pre-alpha1 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
I have Haiku on real hardware ( amd 2600+ nforce2 720MB ram ). at desktop. run GLTeapot then with ProcessController set "Simon" to RealTime priority then close GLTeapot using the close window button. system hangs, in that CPU is still at max, mouse will not move, GLTeapot window is gone. no KDL. Have reproduced twice. revision number 24165. Does not happen in qemu.
Change History (4)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
IMO changing the priority of an application thread and encountering problems afterwards is not a bug. It's just an invalid testcase.
comment:3 by , 17 years ago
I have a similar feeling than korli; especially real time threads are nothing to play with. I'll have a look where it hangs specifically, and eventually close this ticket then (or not).
comment:4 by , 16 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
for the system to hang you need to move the GLTeapot window around will having RealTime priority and then close window, it will hangs every time; and will also hangs qemu. If GLTeapot is not moved while having RealTime priority it will exit fine, no hang on both real hardware and qemu.