Re: GGI/FB PPC Crashes
David Craig [EMAIL PROTECTED] writes: Thanks Marcus, Can you please let me know when you have fixed this. The fbdev target is fixed now. I've not yet decided what to do with some other memset() calls, but as long as you don't use 4- or 8-bit everything should work now. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: GGI/FB PPC Crashes
Hi !
How did it look like ? Graphics garbge or text garbage ? I.e. simply colored
dots or strange colored characters ?
Starts off by displaying the text file catted to it, then in both cases at
the end of the file the screen has unending scrolling screens of characters
(unreadable) black and white. Mostly the solid block null character and
other strange ctl chars etc. Is this expected??
No. This is an indication of fb not working in graphics mode. If fb is in
graphics mode, you shouldn't get anything readable, but rather pixel
garbage.
You can see that a graphical fb console is running by looking at the cursor.
It should be a _block_, not an _underline_.
Don't worry stars definitely isn't going, (paradoxical statement), however I
tested demo instead and here is the debug output, looks like some infinite
looping to me. I pressed q to terminate out to a blank screen but there is
no associated debug info with this action.
Hmm - it repeats
LibGGI: display-fbdev: GGIdlcleanup start.
Terminating on signal 7
over and over ... This might well be a PPC specific problem, as signal 7 is
SIGBUS, which is generated on PPC when unaligned accesses are done.
Please use fbset to set a 32 bit wide mode and see if that helps.
For the others on the list - the relevant last few lines from the debug
trace are:
LibGGI: ggiSetMode: calling 0x162a4b4
LibGGI: ggiCheckMode(0x18158d8, 0x7fffea58) called
LibGGI: display-fbdev: checkmode 1024x768#1024x768F1[0x4000808]
LibGGI: display-fbdev: result 0 1024x768#1024x768F1[0x4000808]
LibGGI: display-fbdev: setmode 1024x768#1024x768F1[0x4000808]
LibGGI: display-fbdev: cannot get timing from /etc/fb.modes. Just hoping it
works.
LibGGI: display-fbdev: Change mode OK.
LibGGI: display-fbdev: frame_size=0xc fb_size=0xc
mmap_size=0x100
LibGGI: display-fbdev: FB_PTR=0x30027000
Terminating on signal 7
LibGGI: display-fbdev: GGIdlcleanup start.
I got to look in the sources where exactly it fails.
For smaller transmission size I deleted several thousand lines repeating on
the end despite the fact that the demo only ran/crashed for a few seconds..
obviously a pretty tight loop going on. Apparently my magic (SAK) key is not
actually working due to the fact the apple usb keyboard has a highly
non-standard configuration I have tried editing keyboard.h to no avail...
Did you make sure it isn't disabled by some nuts distribution script (Redhat
has these) on startup ?
Have a look at /proc/sys/kernel/sysrq. If it doesn't contain "1", you have
this problem.
Please run the "demo" demo and save away GGI_DEBUG%5 output (it comes out on
stderr, so use 2bla to redirect it to a file) and in another run strace
output (also on stderr) and send them along. Would give a clue where stuff
crashes.
Here is the strace output for demo, it end in a segmentation fault without
crashing the PPC (unlike actually running the demo) so obviously the program
behaves differently under strace.
execve("/home/davidc/cggi/degas/lib/libggi/programs/demos/.libs/lt-demo",
You got catched by a strangeness caused by libtool here. The programs it
generates are actually scripts that allow it to run without installing
first.
You have to "strace -f" them to really follow them.
I am now on the GGI developer mailing list so I will post further general
queries there.
Good. You will probably get this post twice, then, but so what - will
confirm the ML hookup works.
Hopefully you will have some ideas on how to fix this /dev/fb
GGI problem,
See above. I think there is still something wrong with the fb setup.
but let me no if you would rather I continue this thread on the
mailing list.
Please do so. Gives more people to think about your problem.
CU, ANdy
--
= Andreas Beck| Email : [EMAIL PROTECTED] =
Re: GGI/FB PPC Crashes
Andreas Beck [EMAIL PROTECTED] writes: Don't worry stars definitely isn't going, (paradoxical statement), however I tested demo instead and here is the debug output, looks like some infinite looping to me. I pressed q to terminate out to a blank screen but there is no associated debug info with this action. Hmm - it repeats LibGGI: display-fbdev: GGIdlcleanup start. Terminating on signal 7 over and over ... This might well be a PPC specific problem, as signal 7 is SIGBUS, which is generated on PPC when unaligned accesses are done. Well, not really. All commonly used load/store instructions are emulated by the kernel for unaligned accesses, and LibGGI doesn't do unaligned accesses anyway. I believe this PPC problem was discussed here earlier. The problem is the dcbz (Data Cache Block Zero) instruction used by glibc memset(). dcbz doesn't work on un-cached regions. According to the manual it should be emulated properly by the OS in this case, but Linux doesn't do that. But even if this was fixed we shouldn't use memset() anyway, as the only reason we use it in the first place is performance. I'll try to fix this in a nice way this weekend. Please use fbset to set a 32 bit wide mode and see if that helps. For the others on the list - the relevant last few lines from the debug trace are: LibGGI: ggiSetMode: calling 0x162a4b4 LibGGI: ggiCheckMode(0x18158d8, 0x7fffea58) called LibGGI: display-fbdev: checkmode 1024x768#1024x768F1[0x4000808] LibGGI: display-fbdev: result 0 1024x768#1024x768F1[0x4000808] LibGGI: display-fbdev: setmode 1024x768#1024x768F1[0x4000808] LibGGI: display-fbdev: cannot get timing from /etc/fb.modes. Just hoping it works. LibGGI: display-fbdev: Change mode OK. LibGGI: display-fbdev: frame_size=0xc fb_size=0xc mmap_size=0x100 LibGGI: display-fbdev: FB_PTR=0x30027000 Terminating on signal 7 LibGGI: display-fbdev: GGIdlcleanup start. fbdev target tries to clear the framebuffer with memset. memset causes SIGBUS which is caught by our error handler, which tries to clean up after fbdev. Unfortunately part of the cleanup-process includes clearing the framebuffer, so we get a new SIGBUS. But as we already are in the SIGBUS handler the program will loop forever on the same dcbz instruction. Note that I've run LibGGI just fine on an embedded PPC card where the framebuffer is in main RAM, so there shouldn't be any other PPC problems than the dcbz in memset. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
RE: GGI/FB PPC Crashes
Thanks Marcus, Can you please let me know when you have fixed this. Regards, David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Marcus Sundberg Sent: Thursday, 27 April 2000 9:56 To: [EMAIL PROTECTED] Cc: David Craig Subject:Re: GGI/FB PPC Crashes Andreas Beck [EMAIL PROTECTED] writes: Don't worry stars definitely isn't going, (paradoxical statement), however I tested demo instead and here is the debug output, looks like some infinite looping to me. I pressed q to terminate out to a blank screen but there is no associated debug info with this action. Hmm - it repeats LibGGI: display-fbdev: GGIdlcleanup start. Terminating on signal 7 over and over ... This might well be a PPC specific problem, as signal 7 is SIGBUS, which is generated on PPC when unaligned accesses are done. Well, not really. All commonly used load/store instructions are emulated by the kernel for unaligned accesses, and LibGGI doesn't do unaligned accesses anyway. I believe this PPC problem was discussed here earlier. The problem is the dcbz (Data Cache Block Zero) instruction used by glibc memset(). dcbz doesn't work on un-cached regions. According to the manual it should be emulated properly by the OS in this case, but Linux doesn't do that. But even if this was fixed we shouldn't use memset() anyway, as the only reason we use it in the first place is performance. I'll try to fix this in a nice way this weekend. Please use fbset to set a 32 bit wide mode and see if that helps. For the others on the list - the relevant last few lines from the debug trace are: LibGGI: ggiSetMode: calling 0x162a4b4 LibGGI: ggiCheckMode(0x18158d8, 0x7fffea58) called LibGGI: display-fbdev: checkmode 1024x768#1024x768F1[0x4000808] LibGGI: display-fbdev: result 0 1024x768#1024x768F1[0x4000808] LibGGI: display-fbdev: setmode 1024x768#1024x768F1[0x4000808] LibGGI: display-fbdev: cannot get timing from /etc/fb.modes. Just hoping it works. LibGGI: display-fbdev: Change mode OK. LibGGI: display-fbdev: frame_size=0xc fb_size=0xc mmap_size=0x100 LibGGI: display-fbdev: FB_PTR=0x30027000 Terminating on signal 7 LibGGI: display-fbdev: GGIdlcleanup start. fbdev target tries to clear the framebuffer with memset. memset causes SIGBUS which is caught by our error handler, which tries to clean up after fbdev. Unfortunately part of the cleanup-process includes clearing the framebuffer, so we get a new SIGBUS. But as we already are in the SIGBUS handler the program will loop forever on the same dcbz instruction. Note that I've run LibGGI just fine on an embedded PPC card where the framebuffer is in main RAM, so there shouldn't be any other PPC problems than the dcbz in memset. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
GGI on PPC
It's been a while since I've followed GGI development. Can anyone tell me what the status of GGI on PPC is?
