Segment violation in FillRectNoClipping when booting on eeePC

[exparrot]

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.

[exparrot]

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

[exparrot]

The actual error from gdb

[diver]

Looks bug #634 is back.

[axeld]

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.

[axeld]

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?

[exparrot]

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.

[exparrot]

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

[diver]

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

[stippi]

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.

[mmlr]

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.

[mmlr]

(In #2650) Another duplicate of #2350.

[jackburton]

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 ?

[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.

[jackburton]

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...

[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 :-)

[korli]

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

[jackburton]

It's fixed in r27898

[jackburton]

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

[exparrot]

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...

[diver]

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

[jackburton]

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