Problems with HP Pavilion dv9700/dv9000/dv9820ea

Uzelth · 2008-08-15 12:32:44

I've got this new laptop and installed Arch x86_64 on it, however I have a few issues:

- Recently upgraded to 4Gb, yet only 3881760k registers... NVIDIA X Server Settings says there's 512Mb graphics memory when the card is a 256Mb dedicated. How'd I go about reclaiming that memory?
- Compiled linux-uvc from svn.berlios.de... Works in Cheese, but not with flash services or aMSN.
- Some keys are dead (the media and DVD player keys)... With Ubuntu they registered keycodes 205 and 237 respectively), yet with Arch they don't register at all
- Some applications (like Cheese) have 'X' images in places of where icons would be.

How'd I go about solving any of these? Any help would be greatly appreciated!

Last edited by Uzelth (2008-08-15 12:33:26)

methuselah · 2008-08-15 19:27:09

I have a hp pavilion dv9920us...

On the hp box, in the small print, they claim 1GB = 1 billion bytes so actual formatted size is smaller.

try 4,000,000,000 bytes = GB: http://www.unit-conversion.info/computer.html

the answer is: 3.725290298462 GB

This confused me also.

My multimedia keys also work except the dvd and quickplay... which I guess I could fix following the guides from one of these pages:
http://wiki.archlinux.org/index.php/Extra_Keyboard_Keys
http://wiki.archlinux.org/index.php/Hotkeys
http://gentoo-wiki.com/HOWTO_Use_Multimedia_Keys

I can't record webcam videos properly (only plays back in fast-forward with no sound), and my webcam microphone doesn't work either... I'm just waiting for someone to fix these issues.

Last edited by methuselah (2008-08-15 19:28:31)

Uzelth · 2008-08-15 19:50:43

I'll look into the Multimedia keys, cheers.

What's weird about the RAM though is Vista reports 4.00Gb, the BIOS reports 4096Mb and my graphics RAM has gone from 256Mb (dedicated) to 512Mb... So it must be recognising all the RAM, but shunting some to the GeForce card... :\

methuselah · 2008-08-15 20:41:43

Uzelth wrote:

I'll look into the Multimedia keys, cheers.
What's weird about the RAM though is Vista reports 4.00Gb, the BIOS reports 4096Mb and my graphics RAM has gone from 256Mb (dedicated) to 512Mb... So it must be recognising all the RAM, but shunting some to the GeForce card... :\

I just looked at my Vista partition and the installed mem said 4.00GB, but the total physical mem said 3.7GB... and my sidebar says 3636MB mem...

In Arch the command "free -m" says 3695 mem, and for "free -b" it says 3875377152 mem.

As for my NVIDIA GeForce 7150M /nForce 630M it says 256MB memory in the "NVIDIA X Server Settings app", in the Graphics Card Info section.

Uzelth · 2008-08-15 22:23:42

This is what baffles me... It says 3.7 from top, 3790Mb from free -m... But why if there's only that does the BIOS report 4096Mb and the graphics card report 512Mb when it's a 256Mb dedicated graphics card? :\

It's really confluzzling.

methuselah · 2008-08-15 23:02:43

My BIOS also says 4096mb, with 64mb default dedicated graphics memory (other possible settings are 32mb and 128mb).

My NVIDIA X Server settings only says 256mb... does yours say 512mb in the Graphics Card Information section? Do you have the same GeForce 7150M /nForce 630M? With up to 1071MB shared UMA memory.

I'm also not sure if I'm missing memory or if it is all due to the false ratio of 1,000,000,000 bytes = 1GB. It just doesn't seem correct... 4GB's should be 4GB's... not 3.725290298462...

Uzelth · 2008-08-15 23:18:55

It shows 512Mb there, yeah... You're right, it doesn't seem correct... I'm thinking it maybe that some of it is being shifted to the graphics somehow. There's no option in the BIOS to control what goes where with the graphics though :\

My card is an NVIDIA GeForce 8400M GS (256mb dedicated, upto 1023 with shared memory)

Last edited by Uzelth (2008-08-15 23:36:25)

Aladdin Sane · 2008-08-16 05:10:15

Uzelth wrote:

I've got this new laptop and installed Arch x86_64 on it, however I have a few issues:
- Recently upgraded to 4Gb, yet only 3881760k registers... NVIDIA X Server Settings says there's 512Mb graphics memory when the card is a 256Mb dedicated. How'd I go about reclaiming that memory?
How'd I go about solving any of these? Any help would be greatly appreciated!

Sorry for breaking in, I'm not an Arch Linux user, but am doing research on the dv9700 for an install of XP or Linux from Vista. I got here from google.com/linux...I apologize if I'm way off topic here...

Frankly, I'd rather help you Uzelth than do the paid support I'm in the middle of...

This is what I know about your mem issue from 30 years hobbyist experience with PC's: If your BIOS says 4096 MB mem, and your OS shows 3881760k (about 3.2-3.8 or so GB), you're golden.

Here's why I think this: Intel, in the chip spec for modern CPU's has "reserved" the upper 384 MB (or so) for hardware addresses, specifically PCI hardware.

This is exactly analogous to back in the DOS days when we used to buy 1 MB mem, and then only get 640 KB for DOS: The rest is reserved for hardware.

I did do some server development contracts in 2007 and frequently saw this "hole" in mem that is reserved at and below the 4 GB boundary.

The "hole" has always been there: You just never saw it before because you never had 4 GB of actual mem to see it.

Same when we used to install 512 kb mem in the DOS days, we never knew that our upper 384 KB would be "stolen" for hardware when we upgraded to 1 MB.

To back up my opinion here are some references to get started:

http://en.wikipedia.org/wiki/Physical_Address_Extension

http://osdir.com/ml/suse.amd64/2005-07/msg00110.html

http://icelava.net/forums/ShowThread.aspx?PostID=1476

Uzelth · 2008-08-16 21:03:22

Heya,

Cheers for the post Aladdin Sane... It was very informative... But raised an intruiging question: I knew this was a problem with x86 architecture, but wasn't it corrected for x86_64/amd64? I've only heard of PAE in association with 32-bit OSes/systems.

Grateful for the information though - it's really appreciated

Aladdin Sane · 2008-08-17 06:49:41

Uzelth wrote:

Heya,
Cheers for the post Aladdin Sane... It was very informative... But raised an intruiging question: I knew this was a problem with x86 architecture, but wasn't it corrected for x86_64/amd64? I've only heard of PAE in association with 32-bit OSes/systems.
Grateful for the information though - it's really appreciated

You're welcome.

I only meant to cite PAE as the "start" of the issue: That was where I (and others) first realized in about 2002-2003 that the "mem hole" issue was "baaack."

Fundamentally, the "mem holes" that are reserved for hardware is a hardware issue with PCI (and all related buses, AGP, PCIe, etc.) versus the CPU, and I would not blame the OS at all, I would just say that if I run a 64-bit OS on a 64-bit CPU, I'm doing the best that I can.

With Linux, the stock distribution kernel, and the stock kernel.org kernel, will vary by features shut off or on. While I know Arch not in the least, I do know that every distribution has to make these feature choices when they compile their kernel.

Many of these can be manipulated without a kernel compile in at least two obvious ways:

1) Load a module (modprobe)

2) Use a kernel command line switch (check out /usr/src/linux/Documentation/kernel-parameters.txt for the list of fun stuff you can manipulate there).

If you get too aggressive in your tweaking, you will experience a hard lock. Be ready for it, to be able to undo it.

The old DOS mem hole issue was also fundamentally a hardware issue, not a "problem" per se, but a design choice made by Intel. The "solution" back then was to load what we would today call a "memory driver" that would allow memory to be (re)mapped from the 640 KB-1024 KB range to above 1024 KB (we called these free blocks of upper mem UMB's). There were four of these "drivers" that could do this: LIM EMS, XMS, VCPI, and DPMI (See Wikipedia, if it seems interesting). You'll probably find DPMI is still in use, if you have occasion to make a DOS floppy.

The old mem hole issue was an area statically reserved for devices on the ISA bus to map their own memory. Video was the largest of these, as I recall.

The new mem hole issue is an area that I believe is "more dynamically" reserved for PCI hardware to map its own memory to, but is, in principle, the same thing: These mem maps have to go somewhere. From what I've read, the mem area "just below and up to" 4 GB will be mapped and used by 32-bit PCI hardware. Linux must not step on these areas, or the hardware needing a reserved map area won't work (and a hard lock at boot will probably result).

Just because you have a 64-bit CPU, bus, and OS, does not mean that every device in your system is 64-bit. I'm thinking of a NIC chip on your MB as an example of a device which is probably still 32-bit PCI.

Consider this: Even though your system is probably "mostly 64-bit" you likely have at least one or two 32-bit PCI slots on your MB. Even those might count as 32-bit devices for the purpose of reserving a memory map area for them.

Try running, as root, the command 'lspci -vv|grep 32-bit' and observe the output, then run just 'lspci -vv' to see who and where those 32-bit critters are.

Apparently, 32-bit PCI devices cannot map their mem area above the 4 GB boundary, but you'll need to check me on this, my understanding is a bit hazy on this point. A kernel developer could confirm or deny my understanding of the issue.

Another point that I believe but can't back up: Linux, unlike DOS, can detect all the "usable" donuts (um, sorry, I mean "donut" as the opposite of "hole") from 0 to 4 GB and then gives you a nice linear map of what's left over for you, without needing to use those silly drivers we used to use in the DOS days: I believe you're already getting all the mem you're allowed, based on the hardware you have installed.

That's where you're getting your 3881760k free mem from.

It's a lot of donuts.

There are several references to use to get more information:

/usr/src/linux/Documentation/x86_64/*

(fun stuff just for x86_64 CPU's)

/usr/src/linux/Documentation/IO-mapping.txt

(mentions some of the memory ranges in question)

/usr/src/linux/Documentation/*

(Note that a large percentage of the documentation of the kernel has to do with how to map memory.)

http://www.google.com/search?q=pci+memory+address+map

http://www.google.com/linux?q=pci+memory+address+map

http://www.google.com/search?q=4+GB+PCI+memory+hole

http://www.google.com/linux?q=4+GB+PCI+memory+hole

I note that several documents that come back from Google searches mention issues with MTRR (Memory Type Range Register): For tweakers and enthusiasts we certainly want to look at these as a related issue: The MTRR features sometimes need to be tweaked to get optimal performance; these are related to memory and the video card which you were already suspecting might have something to do with your question.

While I've never gotten the MTRR's "perfect" I'm told it can be done. Try 'cat /proc/mtrr' to see how you're doing with them.

Also, consider this: The 64-bit devices are mapping their mem somewhere statically I'll bet, I've no clue where, but let's imagine it is up in the 2 TB area. While none of us can imagine having 2 TB of mem in our systems today, it will happen eventually. After all our hardware is pure 64-bit, the issue will go away for now. But in 15-20 years when we start getting those 2 TB systems, the "mem hole" issue will be back to haunt us again.

Uzelth · 2008-08-19 19:13:44

Cheers, thanks for the post... Sorry to be a further bother... But I looked into MTRR and remapping, I tried the following:

echo "disable=2" >| /proc/mtrr
echo "disable=1" >| /proc/mtrr
echo "disable=3" >| /proc/mtrr
echo "disable=4" >| /proc/mtrr
echo "disable=5" >| /proc/mtrr
echo "disable=6" >| /proc/mtrr
echo "disable=7" >| /proc/mtrr
echo "disable=0" >| /proc/mtrr
echo "base=0x00000000 size=0x80000000 type=write-back" >| /proc/mtrr
echo "base=0x80000000 size=0x40000000 type=write-back" >| /proc/mtrr
echo "base=0xC0000000 size=0x10000000 type=write-back" >| /proc/mtrr
echo "base=0x100000000 size=0x10000000 type=write-back" >| /proc/mtrr
echo "base=0x110000000 size=0x10000000 type=write-back" >| /proc/mtrr

Doing this hard locks my system... If I try:

echo "disable=2" >| /proc/mtrr
echo "disable=1" >| /proc/mtrr
echo "disable=3" >| /proc/mtrr
echo "disable=4" >| /proc/mtrr
echo "disable=5" >| /proc/mtrr
echo "disable=6" >| /proc/mtrr
echo "disable=7" >| /proc/mtrr
echo "base=0x80000000 size=0x40000000 type=write-back" >| /proc/mtrr
echo "base=0xC0000000 size=0x10000000 type=write-back" >| /proc/mtrr
echo "base=0x100000000 size=0x10000000 type=write-back" >| /proc/mtrr
echo "base=0x110000000 size=0x10000000 type=write-back" >| /proc/mtrr

It shows the changes in /proc/mtrr... However if I add it to startup, the system hard-locks during boot... Any ideas?

Really do appreciate the help and advise!

Last edited by Uzelth (2008-08-19 19:29:15)

Aladdin Sane · 2008-08-19 20:24:29

Uzelth wrote:

It shows the changes in /proc/mtrr... However if I add it to startup, the system hard-locks during boot... Any ideas?
Really do appreciate the help and advise!

Not directly, no, I haven't a clue. But if you have a recipe for soup that works, but does not work during boot, I can make one opinion on it:

You may be sending the commands too early during boot. What I'm thinking is that you have a video driver for X that loads later in the boot process than your commands.

I'm imagining that your mtrr tuning was performed with this driver already loaded. If it hasn't loaded yet during boot, the hardware may not be "ready" for your commands.

The reverse could be true as well. It depends on what was loaded while you were doing the tuning, and what, ultimately, you want set up on the finally booted system.

Of course this is just a guess, one possible area to look at to troubleshoot the lockup.

Arch Linux

#1 2008-08-15 12:32:44

Problems with HP Pavilion dv9700/dv9000/dv9820ea

#2 2008-08-15 19:27:09

Re: Problems with HP Pavilion dv9700/dv9000/dv9820ea

#3 2008-08-15 19:50:43

Re: Problems with HP Pavilion dv9700/dv9000/dv9820ea

#4 2008-08-15 20:41:43

Re: Problems with HP Pavilion dv9700/dv9000/dv9820ea

#5 2008-08-15 22:23:42

Re: Problems with HP Pavilion dv9700/dv9000/dv9820ea

#6 2008-08-15 23:02:43

Re: Problems with HP Pavilion dv9700/dv9000/dv9820ea

#7 2008-08-15 23:18:55

Re: Problems with HP Pavilion dv9700/dv9000/dv9820ea

#8 2008-08-16 05:10:15

Re: Problems with HP Pavilion dv9700/dv9000/dv9820ea

#9 2008-08-16 21:03:22

Re: Problems with HP Pavilion dv9700/dv9000/dv9820ea

#10 2008-08-17 06:49:41

Re: Problems with HP Pavilion dv9700/dv9000/dv9820ea

#11 2008-08-19 19:13:44

Re: Problems with HP Pavilion dv9700/dv9000/dv9820ea

#12 2008-08-19 20:24:29

Re: Problems with HP Pavilion dv9700/dv9000/dv9820ea

Board footer