The videoram size is used for one pci_device_map_range in smi_driver.c. The value 2Mb is calculated and is wrong. There is another pci_device_map_range in the same file. That one used pSmi->MapSize, which is correct, i.e. 4Mb. So, the result is like this in /proc/$(pidof X)/maps 2b3d4000-2b7d4000 rw-s 50400000 00:00 4379 /sys/devices/pci0000:00/0000:00:08.0/resource0 2b7d4000-2b9d4000 rw-s 50000000 00:00 4379 /sys/devices/pci0000:00/0000:00:08.0/resource0 This results in segfaults when trying to draw the lower part of the screen. To fix this, I hard coded the video ram size for LYNXEMplus.
Created attachment 25381 [details] [review] Set-videoram-size-for-SMI_LYNXEMplus.patch
Weird, it shouldn't segfault if it was detecting less memory than actually present. Could you please provide a backtrace at the place it crashes and some server logs? (Preferentially with some high verbosity level, like: # Xorg -logverbose 8) Thanks for reporting.
(gdb) bt #0 0x2b18e834 in fbBresSolid (pDrawable=0x10348ac8, pGC=0x103a2930, dashOffset=488, signdx=1, signdy=1, axis=1, x1=0, y1=300, e=-338, e1=0, e3=-676, len=87) at fbseg.c:101 #1 0x2b190b0c in fbSegment (pDrawable=0x10348ac8, pGC=0x103a2930, x1=512, y1=300, x2=512, y2=638, drawLast=1, dashOffset=0x7f95f1f8) at fbseg.c:727 #2 0x2b17bc2c in fbPolySegment32 (pDrawable=0x10348ac8, pGC=0x103a2930, nseg=6, pseg=0x103ddb68) at fbbits.h:847 #3 0x2b1889e8 in fbPolySegment (pDrawable=0x10348ac8, pGC=0x103a2930, nseg=9, pseg=0x103ddb68) at fbline.c:174 #4 0x2b1e1060 in XAAPolySegmentFallback (pDraw=0x10348ac8, pGC=0x103a2930, nseg=9, pSeg=0x103ddb68) at xaaFallback.c:152 #5 0x2b253ee8 in cwPolySegment (pDst=0x10348ac8, pGC=0x103a2930, nseg=9, pSegs=0x103ddb68) at cw_ops.c:284 #6 0x10218130 in damagePolySegment (pDrawable=0x10348ac8, pGC=0x103a2930, nSeg=9, pSeg=0x103ddb68) at damage.c:1191 #7 0x1004cbd8 in ProcPolySegment (client=0x103a04a0) at dispatch.c:1679 #8 0x10048040 in Dispatch () at dispatch.c:437 #9 0x10021e24 in main (argc=3, argv=0x7f95f544, envp=0x7f95f554) at main.c:397 (gdb) info registers pc pc: 0x2b18e834 (gdb) disass 0x2b18e834 0x2b18e838 Dump of assembler code from 0x2b18e834 to 0x2b18e838: 0x2b18e834 <fbBresSolid+996>: sw v1,0(v0) End of assembler dump. (gdb) info registers v0 v0: 0x2b9d4800
Created attachment 25388 [details] Xorg.0.log
Created attachment 25404 [details] [review] probe_memory_directly_on_sm712.patch
The patch makes the driver probe the amount of installed video memory by trial and error. It isn't very nice, but the SM712 doesn't seem to have a way to report it directly. The driver currently relies on the "unwritten convention" that the BIOS had stored the right value at the SR71 register, but that usually only works on x86. I think it might be better to probe it than to hardcode it because there are some SM712 out there with 2MB video ram. I've also tried to fix the segfault you'd noticed for this case. Does it otherwise work right? By chance, have you tried dual head mode? I ask because the driver is largely untested on those chips.
I got error, X server failed to start: (==) SMI(0): Using gamma correction (1.0, 1.0, 1.0) (II) SMI(0): MCLK = 157.000 (II) SMI(0): Output LVDS using monitor section Generic Monitor (II) SMI(0): Output LVDS connected (II) SMI(0): Using user preference for initial modes (II) SMI(0): Output LVDS using initial mode 1024x600 (EE) SMI(0): Not enough video memory for the configured screen size and color depth. (II) UnloadModule: "siliconmotion" (II) UnloadModule: "vgahw" (EE) Screen(s) found, but none have a usable configuration. Dual Head seems not working. I plugged in an external LCD, then run xranr, I still can only see the builtin LVDS.
Sorry, a typo in last comment, the command is xrandr.
(In reply to comment #7) > I got error, X server failed to start: > > (==) SMI(0): Using gamma correction (1.0, 1.0, 1.0) > (II) SMI(0): MCLK = 157.000 > (II) SMI(0): Output LVDS using monitor section Generic Monitor > (II) SMI(0): Output LVDS connected > (II) SMI(0): Using user preference for initial modes > (II) SMI(0): Output LVDS using initial mode 1024x600 > (EE) SMI(0): Not enough video memory for the configured screen size and color > depth. > (II) UnloadModule: "siliconmotion" > (II) UnloadModule: "vgahw" > (EE) Screen(s) found, but none have a usable configuration. > I would be interested to see the full verbose logs. Are you sure that it actually has 4MB RAM? > > Dual Head seems not working. I plugged in an external LCD, then run xranr, I > still can only see the builtin LVDS. > Yeah, it's disabled by default on your chip, you need to add to Section "Device" something like: > Option "Dualhead" "on" But assuming that it only detects 2MB of video ram, that's probably too little memory to fit two separate scanout areas on the framebuffer. You might want to temporarily override memory detection: > Videoram 4096 And also note that your chip can only do dual head at 16bpp. If you want to be able to dynamically resize the framebuffer (this is explained on the man page), you also need to set: > Option "AccelMethod" "EXA"
Created attachment 25413 [details] xorg log after the new patch is applied
Ok, I see that fixed memory detection. Have you overridden the virtual screen size at xorg.conf?
Or rather... Could you attach the xorg.conf file you are using?
Created attachment 25415 [details] xorg.conf
Okay, here is what happened: the default acceleration method (XAA) doesn't easily support subsequent framebuffer resizing, so the server chose it big enough to fit all the video modes you had specified in your Section "Monitor" (that is 1280x1024), so that you would be able to switch between them without restarting it. That's way too big for the amount of video ram you have, so it failed. To avoid this, you could either switch to EXA: > Option "AccelMethod" "EXA" or drop all those ModeLines, they should be automatically configured. If it works right besides that, I will commit it to master (maybe with some more debugging output about the computed screen size).
Drop all the mode lines does not work. After dropping all the mode lines, I added Option "AccelMethod" EXA, then it works.
BTW, after adding dualhead on, dual head works. But after a while, the system will hang completely, I can't even ssh into it.
(In reply to comment #15) > Drop all the mode lines does not work. > After dropping all the mode lines, I added Option "AccelMethod" EXA, then it > works. > Yeah, I believe it also takes into account every possible screen rotation, so for 1024x600 and XAA, it tries to allocate a 1024x1024 framebuffer, which is already too big. If you really want to use XAA, you'll probably need to specify the virtual dimensions manually, like: > Virtual 1024 600 But with such a limited hardware, I would rather use EXA and 16bpp.
(In reply to comment #16) > BTW, after adding dualhead on, dual head works. Great. What have you done exactly? Have you tried to set different timings and framebuffer areas for each output or are they cloned? > But after a while, the system will hang completely, I can't even ssh into it. > A backtrace at the place it hangs is likely to be useful, but that would probably make a separate bug report.
(In reply to comment #17) > (In reply to comment #15) > > Drop all the mode lines does not work. > > After dropping all the mode lines, I added Option "AccelMethod" EXA, then it > > works. > > > > Yeah, I believe it also takes into account every possible screen rotation, so > for 1024x600 and XAA, it tries to allocate a 1024x1024 framebuffer, which is > already too big. > > If you really want to use XAA, you'll probably need to specify the virtual > dimensions manually, like: > > Virtual 1024 600 Indeed. With this, XAA also works. > > But with such a limited hardware, I would rather use EXA and 16bpp. BTW, how do you specify 16bpp. Is it Depth in Display subsection. I tried, but does not work. I am now using startx -- -depth 16. Also I found 16bpp may be the reason why the system hangs. Because if 16bpp is used, even not dualhead is off, the system still hangs sometimes.
(In reply to comment #18) > (In reply to comment #16) > > BTW, after adding dualhead on, dual head works. > > Great. What have you done exactly? Have you tried to set different timings and > framebuffer areas for each output or are they cloned? I have tried clone mode. Also I have tried right-of and left-of. I added "Virtual 1824 600" in Display subsection. Then xrandr --output VGA --right-of LVDS --mode 800x600. 1024x768 won't work because of video ram size. > > But after a while, the system will hang completely, I can't even ssh into it. > > > > A backtrace at the place it hangs is likely to be useful, but that would > probably make a separate bug report. How can I get a backtrace since the system completely hangs?
(In reply to comment #20) > (In reply to comment #18) > > (In reply to comment #16) > > > But after a while, the system will hang completely, I can't even ssh into it. > > > > > > > A backtrace at the place it hangs is likely to be useful, but that would > > probably make a separate bug report. > > How can I get a backtrace since the system completely hangs? Please don't take it wrong. I just don't know how to do it. :P
(In reply to comment #19) > > BTW, how do you specify 16bpp. Is it Depth in Display subsection. I tried, but > does not work. I am now using startx -- -depth 16. > Try the "DefaultDepth" option in Section "Screen". (In reply to comment #20) > > > But after a while, the system will hang completely, I can't even ssh into it. > > > > > > > A backtrace at the place it hangs is likely to be useful, but that would > > probably make a separate bug report. > > How can I get a backtrace since the system completely hangs? > You might get a hint about the offending function by rebuilding the driver with -DSMI_DEBUG among your CFLAGS, and then directing the log file to a synchronously mounted partition (e.g. with "-o sync"). SMI_DEBUG adds some marks to the log when most driver functions are entered or left. You could then put a breakpoint at the last function to be executed and single-step until hung. BTW, just pushed the last patch to master.
(In reply to comment #22) > (In reply to comment #19) > > > > BTW, how do you specify 16bpp. Is it Depth in Display subsection. I tried, but > > does not work. I am now using startx -- -depth 16. > > > > Try the "DefaultDepth" option in Section "Screen". Thanks, it works. > > (In reply to comment #20) > > > > But after a while, the system will hang completely, I can't even ssh into it. > > > > > > > > > > A backtrace at the place it hangs is likely to be useful, but that would > > > probably make a separate bug report. > > > > How can I get a backtrace since the system completely hangs? > > > > You might get a hint about the offending function by rebuilding the driver with > -DSMI_DEBUG among your CFLAGS, and then directing the log file to a > synchronously mounted partition (e.g. with "-o sync"). > > SMI_DEBUG adds some marks to the log when most driver functions are entered or > left. You could then put a breakpoint at the last function to be executed and > single-step until hung. Thanks, I will try and file another bug report, probably tomorrow. > > BTW, just pushed the last patch to master. > Thanks.
(In reply to comment #23) > > Thanks, I will try and file another bug report, probably tomorrow. > Thank you too, I'm closing this one then.
(In reply to comment #20) > I have tried clone mode. Also I have tried right-of and left-of. I added > "Virtual 1824 600" in Display subsection. Then xrandr --output VGA --right-of > LVDS --mode 800x600. 1024x768 won't work because of video ram size. > I think you can get a wide enough framebuffer for that if you set it up statically at xorg.conf, like: > Virtual 2048 768 in the "Display" section you're using.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.