Linux on an HP/Compaq nc6120

The homepage at hp.com for this laptop is here.

I'm building this up with a 2.6 kernel (currently a vanilla, unpatched 2.6.13.4), so that's all I'll have experience with.

I should note that the original 2.6.13 kernel seemed to do Bad Things with my laptop (ie: it would freeze, seemingly at random, during the boot sequence). I've currently got 2.6.13.4 running, though, and that seems fine. Perhaps some bug got fixed.

There's some more info on this laptop on this site, linked to from linux-laptop.net. There's also a gentoo-wiki.com page on the nc6220 laptop, which looks to be very, very similar.

It doesn't look like I'll have to touch the kernel to get anything working anymore, so here's my .config file (for 2.6.13.4) for kernel compilation. There's doubtless stuff in there which doesn't need to be (I don't think the AGP options do anything, for instance), but that's the .config which is working for me.

The network card shows up on the PCI bus as a "Broadcom Corporation NeXtreme BCM5705M_2 Gigabit Ethernet" device. The kernel module to use, intuitively enough, is tg3. Go figure.

I'm using X.org for X. X.org 6.9/7.0 introduced support for the graphics chipset in the laptop, so I'd recommend just going with that. Full DRI works fine using the i810 driver.

Here's a copy of my working xorg.conf.

NOTE: The laptop doesn't like having X die unexpectedly on it. If you're running a display manager and want to kill it off, make sure that you switch into text mode (alt-F1, etc) before doing so, or else the display becomes unusable until the next reboot.

For comparison, here's the glxgears FPS ratings that I observed using various configurations (these benchmarks are from ages ago, I'll have to update them with newer versions of software than 2005, when I originally put this together):

	16-bit color	32-bit color
Without DRI	'round 650	6.8.99.13: just over 300 7.0-rc0: just under 700 (impressive)
DRI Enabled	just under 1300	just over 900

I'm not sure what that big jump in non-DRI FPS means for 32-bit color. Perhaps my initial benchmark in 6.8.99.13 was off? I found it a bit strange that it'd actually be faster than the 16-bit test.

When working properly, glxinfo should include the following, as opposed to "Mesa Indirect":

OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 915GM 20041217 x86/MMX/SSE2
OpenGL version string: 1.3 Mesa 6.2.1

NOTE: I tried out Scorched3d using 6.8.99.13 and it completely froze up the display (the box was still running but I had to reboot it remotely). Quake3, SimCity 3000, and Chromium B.S.U. all worked fine, but since I'm using a CVS version of X.org I'd still be more prone to blame that than the scorched3d code. So watch out for freezes, etc.

The snd-intel8x0 ALSA driver worked with no problems, both compiled it straight into the kernel, and as a module. This option shows up as "Intel/SiS/nVidia/AMD/ALi AC97 Controller" in the kernel config. Currently I'm not using the in-kernel ALSA because of issues detailed in the "Modem" section. Here's the appropriate section from my modules.conf for the ALSA devices (this won't be needed if you compile ALSA into the kernel directly):

# ALSA portion
alias char-major-116 snd
# OSS/Free portion
alias char-major-14 soundcore

alias snd-card-0 snd-intel8x0
alias snd-card-1 snd-intel8x0m

# OSS/Free portion - card #1
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss

alias /dev/mixer snd-mixer-oss
alias /dev/dsp snd-pcm-oss
alias /dev/midi snd-seq-oss

# Set this to the correct number of cards.
options snd cards_limit=2

This is working now! This modem is supported with slmodem. There are two drivers which can be used: ALSA's snd-intel8x0m, and the 'slamr' module included with slmodem. The ALSA driver shipped with 2.6.12.1 is too old to properly support this modem. If you want to use the ALSA driver, you must disable ALSA support in your kernel proper, and make sure you've got at least version 1.0.9b of the ALSA drivers from alsa-project.org. Note that kernel 2.6.13 does come with the proper ALSA version, but I've been unable to test that because 2.6.13 seems to have some issues with this laptop. See above.

The other option, if you're on 2.6.12.1 and want to keep ALSA in-kernel for your soundcard, just use the slamr module. It is a proprietary module, and will taint the kernel upon loading, but at least it works.

If you're using the ALSA module, here's what the "aplay -l" output should look like once you've gotten the drivers loaded:

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: ICH6 [Intel ICH6], device 0: Intel ICH [Intel ICH6]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: ICH6 [Intel ICH6], device 4: Intel ICH - IEC958 [Intel ICH6 - IEC958]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Modem [Intel ICH Modem], device 0: Intel ICH - Modem [Intel ICH Modem - Modem]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

The other requirement which may be necessary depending on which ISP you're connecting to is to add the Init string "AT+MS=34" into your wvdial.conf file. Using that init string will limit your download speed to well under 56k, but at least it works. Apparently this is related to a problem in the DSP-handling code, which is proprietary to SmartLink. They've been notified about the problem, and hopefully they'll have a fix out eventually. For now, though, if you can't connect without that extra string, you'll have to use it. This isn't a problem with all ISPs, though, so if you don't need to add that string, don't.

On to the particulars! You need to make sure that ppp_generic and ppp_async are either loaded or compiled straight into the kernel, and then you've got to load either slamr or snd-intel8x0m. From there, you can invoke slmodemd like so:

# slmodemd -c=USA -d=1 -g=dialout /dev/slamr0

or so:

# slmodemd -c=USA -d=1 -g=dialout -a modem:1

The "-d=1" will just produce extra debugging output, so you can skip that, and USA is the default for -c, and /dev/slamr0 is the default device, so actually you could get away with:

# slmodemd -g=dialout

Assuming you're using slamr, and living in the US anyway. Also change "dialout" to whatever group you need to use to have a user dial out, though dialout is a pretty common one nowadays.

Once you've got that, use a wvdial.conf similar to this one:

[Dialer Defaults]
Modem = /dev/ttySL0
Baud = 57600
Init1 = ATZ
Init2 = ATQ0 V1 E1 M1 S0=0 &C1 &D2 +FCLASS=0
Init3 = AT+MS=34
ISDN = 0
Modem Type = Analog Modem
Phone = xxx-xxxx
Username = xxxx
Password = xxxx
Carrier Check = no

The "Carrier Check = no" is important, as is the "AT+MS=34" line. The Init2 line didn't seem to have much bearing on whether or not the dialout was working. Then, hopefully, when you run 'wvdial' you'll be up and running!

I've been working with the folks at the discuss@linmodems.org mailing list to figure all this stuff out. Feel free to check out the thread I started about this modem. Lots of thanks to Sasha from that list for wading through tons of debugging output from me. (The web interface for the mailing list doesn't seem to link threads together terribly well, so here's an mbox archive of the thread in question.

Note: I've heard from one individual that the modem driver may not continue functioning after the laptop's been suspended and then woken up again. I haven't found the time to test that out on my system, though it's been on my To-Do list for some time now. Also the modem may have trouble receiving incoming faxes. More later, hopefully.

No luck with lm_sensors. sensors-detect couldn't find anything, and I don't see anything really obvious on the PCI bus. However, it looks like all of the info you'd need from lm_sensors is available via /proc/acpi when you've got the ACPI modules loaded, so it looks like that's where you can get that information from. Apparently it's very imperative on the laptop to make sure that ACPI's 'fan' and 'processor' modules are loaded at all times, so keep that in mind.

No problems here, just compiled the drivers and started up the PCMCIA service and everything's been fine. No configuration apart from kernel drivers was required. It seems to use the yenta_socket module.

The built-in wireless functionality works fine with the ipw2200 project. Just install that, load the ipw2200 module, and you're good to go.

The CD Burner seemed to work fine using IDE burning with cdrecord. When I specify a speed of 12x, the burner seems to throttle itself down to 4x. When I specify 24x, the burner seems to operate at around 10x. That's good enough for me, so I'm not going to pursue it any longer. The cdrecord commandline I use is:

cdrecord dev=/dev/hdb -v speed=24 -eject -pad -dao <whatever>

Obviously adjust those last few parameters to suit. If anyone does know how to get the burner past 10x, let me know, though...

My USB mouse works fine using the kernel's uhci_hcd driver. I haven't tried out any USB2.0 devices on ehci_hcd yet.

Unknown. I don't have anything Bluetooth for it to talk to.

Unknown. I don't have any Firewire devices for it to talk to.

Unknown. Haven't tried this out yet.