Link Copied
Igor's point is clear and good. As stated already unlikely though: Two D630 shipped in Sept 2007 (click) and one M1330 shipped late March 2008 (click).IgorLevicki:
Not very likely though, as hardware bugs tend to get eliminated with new revisions and not introduced...I meant more like a batch of bad chips spanning certain date range for example if a fly has managed to get into the factory and contaminate wafers.
Great, can you share it with us and report here or to you the results.
The fix explictly mentions that I must not share the fix.
Otherwise, whom do we have to contact at Dell and ask for the fix?
It looks like Dell/Intel has sufficient information together to prepare a final fix and release the latter one. Given the recent progress regarding this issue makes me confident that this happens very soon. I am myself very ambitious in having this one fixed and will post any updates I have on this issue here.
Regarding the e-mail: Currently I see no reason to bother those guys anymore - instead give them the time they need to get their work done
The problem is that X3100 can dynamically allocate the memory it uses from Main System memory. And Dell's BIOS DOES NOT let you assign a hard number allocated to the X3100. SoDell's BIOS is "RANDOMLY" increasing and decreasing main memory allocation for the X3100 based on their "algorithm", and Intel and Vista (or Ubuntu or osx86) do not have the code to detect the change
You judge far too fast.
The way DVMT works in Windows XP and Windows Vista is completely different. The differences are described in section "Dynamic Video Memory" in this document:
http://software.intel.com/en-us/articles/intel-gma-3000-and-x3000-developers-guide
After you have read that, you can conclude that your proposed solution with a fixed video memory allocation in BIOS does not work for Vista. Maybe there's a registry key, which can restrict DVMT in Vista, but that's a different story.
You further assume Dell's BIOS randomly increase and decrease video memory allocation. This is a wrong assumption. It's the Operting System, which decides when and how much to increase video memory. And a different part of the operating system has to make sure before shifting memory to video memory that no used memory pages are in this area.
I have done a tremendous amount of testing with Ubuntu 8.04 and MacOS X 10.5.1/10.5.3 on my machine myself. Based on this testing, I can say: The bug is not present there (as well as yet not in Windows XP).
Yes, you are right: Neither the Ubuntu 8.04 intel drivers (although open source) nor the MacOS drivers are really good in either system. The intel X drivers have plenty of bugs and crash compiz-fusion once in a while. But those bugs are - based on my testing - unrelated. I have reported some bugs to bugzilla for the upstream intel driver myself (and meanwhile those bugs got finally fixed ;-)Besides that you might have regonized that the memory allocation for X looks quite static. It's 256MB
(II) intel(0): Fixed memory allocation layout:
(II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB)
(II) intel(0): 0x00020000-0x00029fff: HW cursors (40 kB)
(II) intel(0): 0x0002a000-0x00031fff: logical 3D context (32 kB)
(II) intel(0): 0x00032000-0x00041fff: exa G965 state buffer (64 kB)
(II) intel(0): 0x00042000-0x00042fff: overlay registers (4 kB)
(II) intel(0): 0x00100000-0x0280ffff: front buffer (40000 kB) X tiled
(II) intel(0): 0x0077f000:end of stolen memory
(II) intel(0): 0x02810000-0x095ecfff: exa offscreen (112500 kB)
(II) intel(0): 0x095ed000-0x0baa4fff: back buffer (37600 kB) X tiled
(II) intel(0): 0x0baa5000-0x0df5cfff: depth buffer (37600 kB) Y tiled
(II) intel(0): 0x0df5d000-0x0ff5cfff: classic textures (32768 kB)
(II) intel(0): 0x10000000:end of aperture
If there's a bug, there are always at least two (in general even more) ways to fix it: 1) fix the bug and 2) make sure it doesn't show up. You can see already from the fact that some older drivers work flawlessly in Vista (see my second posting in this thread) that this also applies to this bug. The point is: For those two solutions, two different parties may be involved. In this case here solution 1) can be fixed by Dell whilst 2) is Intel. This is a very common case: Consider some standard e.g. HDMI and audio codecs. It may happen that you connect to HDMI devices from two different vendors, but you don't hear any sound. One device may interpret the HDMI standard different than the other. Either one has to change its behavior to adhere to HDMI standard or the other device may incorporate a walkaround/fix/special treatment for this particular device. If you ever get the chance to have a look at driver code (e.g. Linux/*BSD drivers are open source) you will exactly see what I'm trying to explain here.The solution should be on Dell's part.
But you're right here the final bugfix that's going to be released is indeed a Video BIOS update. Unfortunately there's no end user way to patch the Video BIOS from the intel developer drivers into your main BIOS. That means: You can't do it yourself currently.
BTW, Dell, if you see this page, you should add in the DDR2-800 memory support for the Vostro 1400(many others I assume)
Check intel's chipset documentation. GM965 is limited to DDR2-667 and will never drive DDR2-800. However every DDR2-800 memory has timings for DDR2-667 operation contained into SPD and thus works at DDR2-677 speed in Dell's notebooks. If you've a memory module that doesn't work at all, check SPD timings.
