Mute the Speakers

I've finally got around to looking into solutions for the headphone jack problem and decided to try a simple solution. If I mute the speakers and plug my headphones in, I get sound from the headphones. Is it ghetto? Yes. Does it work? Yes.

Functionality Summary

I'm using this post to keep a complete list of all the problems and solutions.

Sound
01/07/2007 - I get headphone sound if I mute the speakers. Go figure. I'm not saying it's fixed, but it's less broke.
12/21/2006 - Audio jacks are ignored. Back to work on this one.
12/18/2006 - Finally got some sound out of my speakers, but only with oss.


APIC
12/18/2006 - After more testing it became clear that while my solution works, it isn't optimal. The research continues.
12/17/2006 - I tried a bunch of stuff that didn't work, so I went ahead and modified the kernel source. It appeared to work.
12/02/2006 - I started doing research and found a patch for the 2.2 kernel to allow manual setting of interrupt types. I decided to keep doing research to see if there was a better way.
11/21/2006 - I originally switched APIC off so X would start.


USB
I originally listed USB as not working (it would crash and take the network subsystem with it), but all problems were created by my APIC problem.

Headphone jack doesn't work

My very first commenter, rreagan3, asked if I had done any testing of the headphone jack before I ran around screaming that it worked. I hadn't, so of course it doesn't work. Nothing happens when I plug headphones into any of the sound jacks. It goes on my TODO list.

Sound Off

Which is not what I want. I want it on. So here we go. Now that I've sort of got a handle on my APIC issue I thought I'd take a crack at getting sound working.

According to the Alsa Project the driver the NVidia MCP51 High Definition Audio Card is the intel8x0. As far as I can tell, this is a lie. I tried every way from sunday to get that driver to load. Nothing ever happened. I got fed up with it and tried shotgunning.

For those of you who don't build your own kernel (or haven't shotgunned before), it basically works like this. When you don't know what driver works, you compile them all in and see what happens. This works a remarkably high amount of the time for my network and sound card.

Not this time. The driver snd-hda-intel claimed the card, but /dev/dsp did not get made and mpg123 didn't work. Crud. I decided to try using the alsa-drivers package since it generally contains newer stuff than the kernel. I followed the Gentoo Alsa Guide and switched from kernel sound to user-space sound. I ignored the bit about setting a specific card and compiled them all in. Alsaconf found the card and installed the snd-hda-intel. So much for the website.

Of course, I still didn't have /dev/dsp but I did have some stuff in /dev/snd. Per suggestion from the Gentoo Alsa Guide I tried using aplay to play something (a random wave from /usr/share). It actually worked. I played a crappy wave in all it's 8-bit glory. Now I just had to figure out why nothing else would play.

I started poking around in /proc/asound to see if anything looked interesting and I noticed that I was missing the oss stuff. On a whim, I installed the ALSA-OSS compatibility layer and /dev/dsp appeared. On the up side, I now have sound. On the down side, it's obviously OSS. I'll fight the ALSA battle another day.

Expounding on the kludge

My kludge seems to be turning out reasonably well for me, so I thought I'd give a more thorough explanation of what I did. To recap, when ACPI is enabled, the kernel sets basically all the devices to be edge-triggered. This is bad.

I've researched an obscene number of possible solutions, but I'll discuss those later as some of them may still prove to be better solutions overall than my current one. On with the show.

The kernel determines what kind of trigger to set an IRQ to by calling MPBIOS_trigger in arch/$ARCH/kernel/io_apic.c. Basically, it takes an integer and runs through some cases and returns the trigger at the bottom. Reading through it, you'll quickly notice that one of the cases is labeled the "edge" case. In my case, I pretty much wanted everything on IRQ 11 to be level-triggered. If you just groaned aloud, you guessed it.

In the "edge" case, I slapped my if statment in the middle of things so it reads:

case 1: /* edge */
{
   trigger = 0
   if (idx == 11)  {
     trigger = 1;
   }
   break;
}

Sure enough, when the computer starts up everything that used to be on IRQ 9 and/or 11 now has it's own interrupt and they are all level triggered. I'll admit that I was a little weirded out to see my sound card on IRQ 20. I don't know what the implications are for that sort of thing but I'm sure I'll find out.

My testing so far has revealed only the problem I mentioned in the previous post: boot freezes about 2/3 of the time when trying to set the system clock from hardware. This is almost certainly related to my change, but it's an acceptable trade for now.

an introductory kludge

First, I'd like to say that I hate blogger.com. They've lost my post 4 times now, so it's going to be real short.

I modified io_apic.c in the kernel sources so they returned level_triggered for anything that reported being on irq 11. That's not really a great idea, but the only effect I've noticed so far is that the computer hangs on boot about half the time. Once it's up, it seems to be fine.

A possible irq override patch

A friend suggested that I see if there were any updates to my BIOS. I had checked before, but I thought I might get lucky. Lo and behold, a new BIOS (F.1A) had been posted in early November. Of course, the things it claimed to fix had nothing to do with my problems, but I figured I'd give it a shot anyway. No dice. It does exactly what it says it does. Those bastards.

Moving on to google, I found my first promising lead in a July 2000 post on kerneltraffic.org from a guy with the same problem (bios reporting incorrect interrupt types with a need to override). A few days later, he responded to his own post saying he had found a patch from July 1999 that allowed the override. The patch applied to the 2.2.10 kernel, but at least it was an idea.

Hoping that this feature had made its way permanently into the kernel, I added ioapic_level=10,11 to my kernel options and rebooted. Absolutely nothing changed. So much for luck. I'll stick this in my back pocket for now. I'd rather not write my own kernel patch if I can help it. But if it comes to that, I'll do it.

More APIC woes

I noticed yesterday that the output from /proc/interrupts listed usb and network on the same irq (see 11).

         CPU0       CPU1    
0:     485920      18674          XT-PIC  timer
1:       8081        626          XT-PIC  i8042
2:          0          0          XT-PIC  cascade
5:     119443       4243          XT-PIC  libata
8:          0          0          XT-PIC  rtc
10:     299716      11836          XT-PIC  HDA Intel, nvidia
11:     501067      24435          XT-PIC  ohci_hcd:usb1, eth0
12:     104435      12826          XT-PIC  i8042
14:         19          5          XT-PIC  ide0
NMI:        302        233
LOC:     504576     504559
ERR:    1591283
MIS:          0

I had hopes of having usb work now that I had switched everything to XT-PIC (noapic). Of course, that would be too easy. I clearly don't understand the full ramifications of turning APIC off, but without it, there is no USB. I can only assume it is receiving no interrupts. At least my network card still works.

TODO

This list only contains the current issues I'm working on. For a complete list of issues and fixes, please see the functionality summary.

• APIC works, but I've got about 20 IRQs (which isn't right) and it only boots 1/3 of the time with the current fix.


• Sound doesn't automatically transfer to headphones, so I have to mute the speakers myself.
  
  
• Bluetooth doesn't work.


• Wireless doesn't work.


• Learn how to manage the Synaptics options (and turn off all the touch pad back/forward/scroll/reload stuff)


• Flash doesn't work because it's a 64-bit system
  

X fails to start due to edge-triggered interrupts

I rebooted my laptop this morning to find that X would no longer start. Shame on me for upgrading. The error message I received was

(EE) NVIDIA(0): The interrupt for NVIDIA graphics device PCI:x:x:x
(EE) NVIDIA(0):      appears to be edge-triggered. Please see the COMMON
(EE) NVIDIA(0):      PROBLEMS section in the README for additional information.

The last time I heard anything about edge-triggered anything was my first year of college, so all I got out of this message was "Something is misconfigured." I google the error and find the "Common Problems" section. There are several version of this file running around, each with different amounts of information. This is the best one I found: http://download.nvidia.com/XFree86/Linux-x86/1.0-9629/README/chapter-05.html


I checked /proc/interrupts and sure enough, everything was set to edge-triggered. This could explain several of my hardware issues. The quickest way to getting a working laptop seems to be throwing "noapic" in as a kernel argument, so the pertinent entry in my grub.conf now looks like:

title Gentoo64
root (hd0,1)
kernel /2.6.17-r8.usb root=/dev/sda5 noapic
#initrd /initrd.img

I'm not too happy with this solution, but at least I can use my computer.

dv6000z details

For those of you who are playing from home, here are the specifics of my laptop. If there's a detail you think is pertinent that isn't here, post a comment about it and I'll try to address it. This is what was in the email from HP when I ordered it:

- Genuine Windows XP Home Edition
- AMD Turion(TM) 64 X2 Mobile TL-56 (1.80GHz/512KB)
- FREE Upgrade to 15.4" WXGA BrightView Widescreen!
- 256MB NVIDIA(R) GeForce(R) Go 7200
- HP IMPRINT Finish + Microphone
- 2.0GB DDR2 SDRAM (2x1024MB)
- FREE Upgrade from 60 GB 5400 RPM to 80 GB 5400 RPM
- FREE Upgrade: 8X DVD+/-R/RW w/Double Layer Support
- 802.11a/b/g WLAN & Bluetooth
- 12 Cell Lithium Ion Battery
- Microsoft(R) Works/Money

I'm sure glad I got that copy of Works. Where would I be without it? Anyway, this is what lspci says

00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2)
00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2)
00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2)
00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2)
00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2)
00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2)
00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
00:0a.3 Co-processor: nVidia Corporation MCP51 PMU (rev a3)
00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev f1)
00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev f1)
00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)
00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)
00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
03:00.0 Network controller: Broadcom Corporation BCM4310 UART (rev 01)
05:00.0 VGA compatible controller: nVidia Corporation GeForce Go 7200 (rev a1)
07:05.0 FireWire (IEEE 1394): Ricoh Co Ltd Unknown device 0832
07:05.1 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19)
07:05.2 System peripheral: Ricoh Co Ltd Unknown device 0843 (rev 01)
07:05.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a)
07:05.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 05)

dv6000z + linux = :(

A little while ago I bought the HP dv6000z. It had all the hardware I was looking for at a decent price. The problem is that it doesn't really work very well with linux. I was hoping that if I waited a little while, someone else would put together a HOWTO so I could just ride the open source coat tails. No game on that one, so I'm starting this blog to document my quest to get everything working.