Akom's Tech Ruminations

This was easily remedied - there was an old genkernel generic kernel around, which allowed me to recompile with i586/i686/etc as my CPU selection. As a precaution, I also took march=i686 out of my /etc/make.conf

• This is fixed in 2.6.25-r7 kernel, though as I use udev, this was not obvious to me until I glanced through dmesg output to see this:

  eth0: RTL8169 at 0xf8916000, 00:1c:c0:6f:dd:7b, XID 24a00000 IRQ 11 udev: renamed network interface eth0 to eth3

• Not only did udev remember the old network cards I had as eth0 and eth1, but it also added eth2 for the temporarily installed PCI NIC I had to use, and finally eth3 for the now-working onboard LAN.
• I just kept symlinking /etc/init.d/net.eth1, eth2, eth3 to net.lo, until I figured out that /etc/udev/rules.d/70-persistent-net.rules has all these relocations stored, confusing everything for me. I kept thinking that the onboard lan was still not working. Deleting this file got me back my lovely eth0

smsc47m1-isa-0680
Adapter: ISA adapter
fan1:          0 RPM  (min = 1280 RPM, div = 4)  ALARM
fan2:       6826 RPM  (min = 1280 RPM, div = 4)

smsc47m192-i2c-0-2d
Adapter: SMBus I801 adapter at 3000
+2.5V:       +2.53 V  (min =  +0.00 V, max =  +3.32 V)   
VCore:       +1.15 V  (min =  +0.00 V, max =  +2.99 V)   
+3.3V:       +3.33 V  (min =  +0.00 V, max =  +4.38 V)   
+5V:         +5.10 V  (min =  +0.00 V, max =  +6.64 V)   
+12V:       +12.25 V  (min =  +0.00 V, max = +15.94 V)   
VCC:         +3.35 V  (min =  +0.00 V, max =  +4.38 V)   
+1.5V:       +1.56 V  (min =  +0.00 V, max =  +1.99 V)   
+1.8V:       +1.78 V  (min =  +0.00 V, max =  +2.39 V)   
Chip Temp:   +37.0 C  (low  = -127.0 C, high = +127.0 C)  
CPU Temp:    +45.0 C  (low  = -127.0 C, high = +127.0 C)  
Sys Temp:    +40.0 C  (low  = -127.0 C, high = +127.0 C)  
cpu0_vid:   +2.050 V

The former was not initially detected because I didn't have the Intel 82801 (ICH) i2c module (i2c-i801) enabled in the kernel. I had to enable both SMSC LPC47M* items in the Hardware Monitoring section of kernel config too.

hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x200f0000

The card is detected, mixer works, but when you try to play - the data simply isn't getting through the card - the player application slows to a crawl and is writing audio at 1/100th of the speed, roughly.
I tried to pass the model= option to the kernel (Tried all the models for ALC662):

      3stack-dig    3-stack (2-channel) with SPDIF
      3stack-6ch     3-stack (6-channel)
      3stack-6ch-dig 3-stack (6-channel) with SPDIF
      6stack-dig     6-stack with SPDIF
      lenovo-101e    Lenovo laptop
      eeepc-p701    ASUS Eeepc P701
      eeepc-ep20    ASUS Eeepc EP20
      auto      auto-config reading BIOS (default)
 

Some of these cause it to accept data just slightly faster than the rest. Googling turned up nothing thus far, so I am using the only PCI slot for a Via ENVY 24 that I had laying around (AV-710), now that I got the onboard LAN working. Got a solution? Let me know.

Here is an interesting thing. When I decided to use the PCI sound card, I disabled the oboard audio in the BIOS for simplicity - and the onboard LAN stopped working. I am not joking, and I did not accidentally shut that off too. I flipped audio back on - and LAN came back. This may be an r8169 linux driver bug, or an IRQ conflict, I am not sure.

Then, in my modprobe cluelessness I attempted to remap the Envy to snd-slot-0 ... no such luck. The useless onboard audio was always the first sound card. Eventually I got tired of this game and blacklisted the module (/etc/modprobe.d/blacklist):

blacklist snd_hda_intel
blacklist snd_hwdep
 

Job complete.