PAE and Intel video still a mess...

[mcmackin]

Has anyone out there had any luck with the PAE kernel on Intel video hardware?

Even with the latest kernel I'm not having any success. Bug was filed, but doesn't appear to be moving in any positive direction...

[tmarikle]

Originally Posted by mcmackin

Has anyone out there had any luck with the PAE kernel on Intel video hardware?

Even with the latest kernel I'm not having any success. Bug was filed, but doesn't appear to be moving in any positive direction...

Yes, I finally succeeded in installing the PAE kernel from DVD on Intel video as you have described. I have the very same issue everyone else does; my laptop has 4 GB RAM and i965 graphics.

I thought I would try taking out one of my two RAM sticks leaving 2GB and the install completed and Fedora 11 is fully booting now. However, I attempted to re-install the second stick of RAM and the system will not fully boot up. It just hangs when it comes to switching graphics.

T

[mcmackin]

That's odd...

You're saying you took 2gb out and were able to boot the PAE kernel?

I did install the -115 PAE kernel from Koji and it finally gave me an xorg.log output. It seems HAL is not passing a mouse or keyboard to xorg and that's why X hangs.

[RahulSundaram]

Hi

Is there a bug report on this filed?

[mcmackin]

I filed bug 493526 and it's not gotten very much traffic. It was originally filed against the kernel and then someone changed it to xorg-X11-drv-intel.

[tmarikle]

Originally Posted by mcmackin

That's odd...

You're saying you took 2gb out and were able to boot the PAE kernel?

I did install the -115 PAE kernel from Koji and it finally gave me an xorg.log output. It seems HAL is not passing a mouse or keyboard to xorg and that's why X hangs.

To be clear, I took out 2gb or RAM and re-installed from DVD, which did install the PAE kernel, which, like you said is odd.

If I put the 2gb back in, it hangs right as X is supposed to start.

I'm glad it works for the moment; I'm wrestling with whether to continue with only 2gb RAM or not. The system is running great otherwise.

T

[tmarikle]

Originally Posted by mcmackin

I filed bug 493526 and it's not gotten very much traffic. It was originally filed against the kernel and then someone changed it to xorg-X11-drv-intel.

Based on my oversimplified test, it's probably filed correctly under xorg. I'll try adding the 2gb again and see if anything can be pulled out of the logs; I don't believe anything is getting written to the Xorg.0.log by the time the system hangs.

[mcmackin]

What you need to do is edit the grub line for the kernel and change it to selinux 0 3.

This will get you to a login and then running startx will hang, but generate some info in a log file. Booting to runlevel 5 gives me no log info at all...

[tmarikle]

Originally Posted by mcmackin

What you need to do is edit the grub line for the kernel and change it to selinux 0 3.

This will get you to a login and then running startx will hang, but generate some info in a log file. Booting to runlevel 5 gives me no log info at all...

You are correct. I was able to get two Xorg.0.log files to compare; there are no differences (apart from a log file time stamp on line 14 as would be expected) until X is attempting to start RandR 1.2. The 4gb RAM test fails to get past this. The 2gb test breezes past and starts initializing the built-in extensions.

(==) intel(0): Backing store disabled
(==) intel(0): Silken mouse enabled
(II) intel(0): Initializing HW Cursor
(II) intel(0): Fixed memory allocation layout:
(II) intel(0): 0x00000000-0xffffffff: DRI memory manager (0 kB)
(II) intel(0): 0x00000000:            end of aperture
(II) intel(0): BO memory allocation layout:
(II) intel(0): 0x00000000:            start of memory manager
(II) intel(0): 0x00bd7000-0x00fbefff: front buffer (4000 kB) X tiled
(II) intel(0): 0x00bc7000-0x00bd0fff: HW cursors (40 kB)
(II) intel(0): 0x00000000:            end of memory manager
***4gb test fails here***
(II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message.
(II) intel(0): DPMS enabled
(==) intel(0): Intel XvMC decoder disabled
(II) intel(0): Set up textured video
(II) intel(0): direct rendering: DRI2 Enabled
(--) RandR disabled
(II) Initializing built-in extension Generic Event Extension
(II) Initializing built-in extension SHAPE
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension BIG-REQUESTS
(II) Initializing built-in extension SYNC
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension XC-MISC
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFIXES
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE
(II) Initializing built-in extension DAMAGE
...

[sideways]

A couple of things to try to help further the bugzilla:

1. Try booting the pae kernel with 4G installed but add the kernel parameter 'mem=3072M' (just press 'a' at the grub menu to add this)

2. See if there is an option in your BIOS for memory-hole remapping (may be called something different), if there is then change its default value and see if that makes any difference.

[tmarikle]

Originally Posted by sideways

A couple of things to try to help further the bugzilla:

1. Try booting the pae kernel with 4G installed but add the kernel parameter 'mem=3072M' (just press 'a' at the grub menu to add this)

Very nice! That worked. I added the RAM stick back and I also set mem=4032M which also worked so I'm pretty confident that I can get this closer to the 4096M boundary. I'm going to try to drop it to 4095M for grins. *update* Confirmed, mem=4095M works!

Originally Posted by sideways

2. See if there is an option in your BIOS for memory-hole remapping (may be called something different), if there is then change its default value and see if that makes any difference.

I looked last night but not very hard. I'll look some more.

Thanks for the suggestion.

T

[mcmackin]

So, mem=4095M allows me to boot, but top and /proc/meminfo only show 3gb of RAM. Without booting X, I was able to see 4gb when logged in at runlevel 3.

Something is still not right here...

[sideways]

Originally Posted by mcmackin

So, mem=4095M allows me to boot, but top and /proc/meminfo only show 3gb of RAM. Without booting X, I was able to see 4gb when logged in at runlevel 3.

Something is still not right here...

That's because of the memory-hole, onboard devices (including video) are mapped in upper region of the first 4gb address range, no matter what kernel you use (x86, x86-pae, x86_64). With pae and x86_64 you can sometimes recover the lost memory by enabling memory hole remapping in the bios (if available) which will remap any lost ram above the 4gb address space (obviously the standard 32bit kernel can't access this).

[mcmackin]

OK, I understand that. Are you saying that without X, in runlevel 3, none of those devices are occupying memory so that's why I see 4gb there?

What about the Ubuntu server kernel which gives me 4gb and the F11 x86_64 kernel that gives me 4gb?

I'm not changing anything in BIOS, it's just those different kernels...

[sideways]

You should probably ask on the kernel or xorg mailing list, perhaps the kernel doesn't map the video memory until the video driver is loaded.

Why the pae kernel has particular issues is probably due to arcane reasons that I certainly can't answer.