OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => OpenBSD => Topic started by: iamasmith on January 20, 2006, 06:52:07 am
-
I think I have pinned down what happens to cause X to die on my Z occasionally.
Only seems to happen when the Z is paging a lot and X is not responsive and only seems to happen with a mouse connected.
I see a lot of dmesg errors coming from wxmouse and I think that the stream of mouse events generated by moving a mouse is overflowing a buffer because the X server is partially paged out and can't read this buffer (or something like that). Obviously stylus use generates single mousemove events rather than a constant stream so this isn't as likely to fill that buffer.
Bear this in mind if you are compiling something big, it can save a restart.
- Andy
-
Yesterday I got a reply and a diff patch to the ws_drv from Matthieu Herb on this issue..
http://marc.theaimsgroup.com/?l=openbsd-ar...92269628962&w=2 (http://marc.theaimsgroup.com/?l=openbsd-arm&m=113892269628962&w=2)
The issue basically boils down to the order of conditions in a while loop, the original version read a byte from a buffer before checking the destination buffer length.. this caused a discard of that byte if the buffer was full. Since the events are multi-byte (just being copied 1 byte at a time) subsequent events would all be misaligned and this would happen on the first buffer overrun.
The posting above contains the source of the patch.
Attached here is a compiled version of that driver (built by Matthieu - many thanks I didn't have XF4 cvs built on my Z) and I have built an md5sum to go with it.
Replace /usr/X11R6/lib/modules/input/ws_drv.so with this version and I think you will find things a little more stable. - sorry you will have to rename it back to ws_drv.so - I couldn't post it with that extension.
On a seprate note you may get processes being put into a STOP state if your Zaurus is very busy (seems to happen to avoid thrashing). This unfortunately happens for thinks like xfwm which isn't greatly helpful since you need a Window Manager running to do most things in X. You can recover as follows...
i. Switch to a text vt using Ctrl-Alt-F2 (you can switch back to ttyC0/vt01 with Ctrl-Alt-F1)
ii. Login as root
iii. Run the top command and look for the processes marked 'stop' that may be effecting your X session.
iv. hit k (for kill)
v. enter '-CONT <pid>' (without the quotes and where <pid> is the process ID of the process you want to resume.
vi. hit q to quit from top when done.
Note that if something heavy is immediately pushing your process back to sleep you can use kill -STOP <pid> to suspend that process until you have managed to deal with your X session then you can kill -CONT that process to resume it.
This is far from ideal so I'm now looking to see if there is a way of flagging stuff so it doesn't get stopped like this (or disabling the feature). - If anyone knows how to do this then that would be great
- Andy
-
Perhaps my previous post was misleading about the processes going into STOP state..
That actually isn't related to the ws_drv posted above... that's an entirely seperate issue.
I would recommend using this update or building it yourself as it significantly improves the X server stability on the Zaurus.
- Andy
-
Yesterday I got a reply and a diff patch to the ws_drv from Matthieu Herb on this issue..
http://marc.theaimsgroup.com/?l=openbsd-ar...92269628962&w=2 (http://marc.theaimsgroup.com/?l=openbsd-arm&m=113892269628962&w=2)
On a seprate note you may get processes being put into a STOP state if your Zaurus is very busy (seems to happen to avoid thrashing). This unfortunately happens for thinks like xfwm which isn't greatly helpful since you need a Window Manager running to do most things in X. You can recover as follows...
i. Switch to a text vt using Ctrl-Alt-F2 (you can switch back to ttyC0/vt01 with Ctrl-Alt-F1)
ii. Login as root
iii. Run the top command and look for the processes marked 'stop' that may be effecting your X session.
iv. hit k (for kill)
v. enter '-CONT <pid>' (without the quotes and where <pid> is the process ID of the process you want to resume.
vi. hit q to quit from top when done.
Note that if something heavy is immediately pushing your process back to sleep you can use kill -STOP <pid> to suspend that process until you have managed to deal with your X session then you can kill -CONT that process to resume it.
This is far from ideal so I'm now looking to see if there is a way of flagging stuff so it doesn't get stopped like this (or disabling the feature). - If anyone knows how to do this then that would be great
[div align=\"right\"][a href=\"index.php?act=findpost&pid=113518\"][{POST_SNAPBACK}][/a][/div]
Mystery solved - don't build or install DBUS unless you find out how to disable the following behaviour.
When VTs are switched DBUS sends a SIGSTOP to all processes that are associated with that VT, unfortunately under certain conditions it also happens when you don't switch VT
DBUS isn't in the ports feed anyway.. it was an add-on build that I thought may help.
- Andy
-
BTW: the ws_drv patch shown above seems to have resolved all my X server crashes (must try harder to break it ) - I have now had xfce4 running with AbiWord and 80Mb of pagefile in use whilst Konqueror-Embedded is building in the background... bullet proof so far
Please note there was a snapshot of the Zaurus X stuff made on 3rd Feb '06, other base stuff was uploaded on the 1st - this patch hasn't been committed to the -current cvs yet so you will still need to either patch source or use the above binary to implement the fix with this snapshot.
- Andy