I'm getting the same screen, too.

Distro: Arch 64
Computer: Toshiba Satellite M305-S4822.
Processor: Intel Core 2 Duo T5550 / 1.83 GHz ( Dual-Core)
Graphics: Intel GMA X3100

@Reidoon: Can you post Help=>System Information?

@charbar: For your older hardware, this thread might be of interest: https://github.com/ValveSoftware/Source-1-Games/issues/19

@jljusten: Thanks for the link. After reading through and seeing a comment by @chrisforbes, I decided to install lib32-mesa-full-i965 from the AUR. It runs! However, it crashed within 5 minutes the first time I ran it. After that, though, I played for 15 minutes before I closed it. I will report more later after running longer sessions a few times (hopefully). I saw that you indicated that the game crashed on a GM45 (slightly newer than my chipset) in the following thread: https://github.com/ValveSoftware/Source-1-Games/issues/373 . Any more luck with it, or is it still crashing?

This is indicative of not having textures. Unfortunately, some textures in Source games use S3TC patent-encumbered textures internally. You might need to install libtxc_dxtn and set the force_s3tc_enable envvar to true.

@magcius : Although I don't really know much about S3TC and implementation issues, I decided to install S2TC from the Arch Linux AUR after the first crash. It hasn't crashed since and I've played a few hours in a couple of sittings. Here are the AUR and github links:

                         https://aur.archlinux.org/packages/lib32-libtxc_dxtn_s2tc/
                         https://github.com/divVerent/s2tc#readme

I decided to install it because I read @jljusten pointing out the importance lib32-libtxc_dxtn (in the thread I linked in my last post) and I thought I'd experiment with an alternative after my crash. So do you think replacing lib32-libtxc_dxtn with lib32-libtxc_dxtn_s2tc worked because S3TC, being patent encumbered, isn't implemented well in open source drivers even though it is required? And that S2TC, without patent encumberment, is better implemented in open source drivers even though it goes through the extra step of converting S3TC? Or am I completely misunderstanding? I'm merely curios. Even though I only played/crashed the game once before installing the S2TC package, and the current crash-free play may have nothing to do with the fact that I installed the S2TC package, it sounds like the crash wasn't a fluke.

S2TC is an alternate implementation of S3TC compression that doesn't implement the patented parts of S3TC texture compression. It may not decompress S3TC textures accurately (the patented parts are really simple weighted color combinations -- S2TC simply picks a color at random)

Note that if you were having crashes before, it might very well be in mesa or in the libtxc_dxtn code. I'm unsure how to get a backtrace, as the Steam launcher makes it hard to run Portal under gdb.

Does anybody else know how, or how to get a backtrace from the minidump?

@Reidoon: Are you still having the issue with Portal? If you still are, please post your system information as I mentioned above, and we can re-open this issue.

@jljusten Well, turns out it was fixed related to another issue with no openGL 1.3 support for intel 2000 integrated series. Enabling x-org edgers fix'd the problem, but with some lag. However, this is related to the driver so I'll just have to wait for updates from that.

@magcius Thanks for some further explanation. I'll be happy to backtrace if anybody can tell me how to do it. I was able to finish the game with S2TC, but I'm also curious as to what code, in which package, caused my previous problem.