Opened 16 years ago

Closed 16 years ago

Last modified 11 years ago

#2350 closed bug (fixed)

Segment violation in FillRectNoClipping when booting on eeePC

Reported by: exparrot Owned by: axeld
Priority: normal Milestone: R1
Component: Servers/app_server Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking: #2650
Platform: x86

Description

STR:

  1. dd the nightly raw image from June 8th to the internal ssd
  2. boot and select 640x480x16 as the failsafe video mode in the bootloader

Actual behaviour: Dumps me to GDB showing attached screenshots.

Expected behaviour: Booting to desktop.

Attachments (3)

IMAGE_00174.jpg (74.7 KB ) - added by exparrot 16 years ago.
Bottom half of the gdb screen showing the backtrace I asked for
IMAGE_00173.jpg (94.9 KB ) - added by exparrot 16 years ago.
The actual error from gdb
s3010015.jpg (202.1 KB ) - added by 3dEyes 16 years ago.

Download all attachments as: .zip

Change History (23)

by exparrot, 16 years ago

Attachment: IMAGE_00174.jpg added

Bottom half of the gdb screen showing the backtrace I asked for

by exparrot, 16 years ago

Attachment: IMAGE_00173.jpg added

The actual error from gdb

comment:1 by diver, 16 years ago

Component: - GeneralServers/app_server

Looks bug #634 is back.

comment:2 by axeld, 16 years ago

I'll see if I can reproduce this problem with the EeePC 900. @diver: it doesn't necessarily need to have anything to do with #634. This crash happens if the app_server draws out of the bounds of the screen, but this can have many reasons.

comment:3 by axeld, 16 years ago

I can't reproduce this one with the EeePC 900. No matter if safe-mode or not, it always works nicely.

I guess on the 701, only 640x480 is available in the safe-mode menu? Does it work at all if you don't select a safe-mode video mode, but just boot?

in reply to:  3 comment:4 by exparrot, 16 years ago

Replying to axeld:

I guess on the 701, only 640x480 is available in the safe-mode menu? Does it work at all if you don't select a safe-mode video mode, but just boot?

Correct, only 640x480 is available in the menu (along with Standard VGA). However, booting without selecting this results in a crash with a sing half-row of blue pixels along the top of the screen.

I've bricked the eeePC for the time being, so won't be able to test this further in the near future.

by 3dEyes, 16 years ago

Attachment: s3010015.jpg added

comment:5 by exparrot, 16 years ago

Very nice. I've un-bricked the machine now so would be keen to hear how to make this work.

comment:6 by diver, 16 years ago

User OlegMS reports that he gets the same crash with his Dell inspiron 1300 backtrace is identical to already attached IMAGE_00174.jpg.

comment:7 by stippi, 16 years ago

The problem seems to be that app_server and the graphics driver are out of sync with regards to the current resolution. In another words, the app_server thinks that the driver is in another resolution than it actually is. Then it writes to the frame buffer out of bounds which leads to the crash. From what I hear from mmlr, the problem can be worked around by copying a resolution settings file which forces an initial mode switch and syncs app_server to the driver or vice versa. (mmlr, does a vesa settings file suffice?) I have not yet had a chance to look into the root cause of the problem.

comment:8 by mmlr, 16 years ago

The way I work around it is to boot in safe video mode by booth setting "Use Failsafe Video Mode" and choosing a video mode in the boot menu, then when booted use the Screen preflet to select any mode different than the current one (doesn't matter). This will cause a settings file to be written. The resolution used when rebooting is then chosen based on the preferred mode of the graphics driver disregarding the settings file. The issue seems that the preferred mode isn't used when there is no settings file at all. What I could imagine is that when there is a settings file it will try to set that mode, which will fail for the intel driver (as it only allows the native resolution) and then fall back to the preferred mode. If there is no settings file, it won't try setting the mode and won't fall back either.

comment:9 by mmlr, 16 years ago

Blocking: 2650 added

(In #2650) Another duplicate of #2350.

comment:10 by jackburton, 16 years ago

I have the same problem on my laptop, which has an intel GMA chipset (id 2a03). After the setting file is there, it works correctly. But Screen only shows the native resolution (1280x800), while in vesa I can use also different resolutions. Axel, is there anything I can test ?

in reply to:  10 ; comment:11 by axeld, 16 years ago

Replying to jackburton:

Axel, is there anything I can test ?

Since Michael obviously has no interest in fixing this (pun intended :-)), I guess it's your task now :-) I would start printing what kind of resolutions the app_server tries to set, which one it finally uses, and that for both sides, the app_server, and the accelerant.

in reply to:  11 comment:12 by jackburton, 16 years ago

Replying to axeld:

Replying to jackburton:

Axel, is there anything I can test ?

Since Michael obviously has no interest in fixing this (pun intended :-)), I guess it's your task now :-) I would start printing what kind of resolutions the app_server tries to set, which one it finally uses, and that for both sides, the app_server, and the accelerant.

Is there any way to print to syslog from userland ? Otherwise I can't see how I could see what I print from app_server side. Hmmm, maybe try to dump to a file...

comment:13 by axeld, 16 years ago

As long as syslog is enabled, everything you "debug_printf()" from userland should end up there as well. Also, there is always the POSIX method via the syslog() function :-)

in reply to:  13 comment:14 by korli, 16 years ago

Replying to axeld:

As long as syslog is enabled, everything you "debug_printf()" from userland should end up there as well. Also, there is always the POSIX method via the syslog() function :-)

Yes, and simple printf works well if you setup boot stdout like this in BootScript: exec >/dev/dprintf 2>&1

comment:15 by jackburton, 16 years ago

Resolution: fixed
Status: newclosed

It's fixed in hrev27898

comment:16 by jackburton, 16 years ago

BTW I didn't ask if the problem is gone also for diver, exparrot and mmlr. Can you confirm it works now ?

in reply to:  16 comment:17 by exparrot, 16 years ago

Replying to jackburton:

BTW I didn't ask if the problem is gone also for diver, exparrot and mmlr. Can you confirm it works now ?

Oops, I was sure I'd already replied to this to say it was working... probably about a month ago...

comment:18 by diver, 16 years ago

I've asked a user who originally reported it, so i'm waiting for reply.

comment:19 by jackburton, 16 years ago

Sorry, I had forgot to commit part of the fix. The revision which really fixes the problem is hrev27903.

comment:20 by exparrot, 11 years ago

Sorry, it's a bit late but yes, this did fix the problem.

Note: See TracTickets for help on using tickets.