[gentoo-amd64] Alsa problem

[gentoo-amd64] Alsa problem

[Rafael Barrera Oro]

I have a problem configuring alsa, and was wonderign if maybe i am 
ignoring something specific of the amd64 architecture:

i followed the steps of the gentoo alsa guide (using the kernel module) 
and after compiling the kernel i run alsaconf and get this:

Running modules-update...
Loading driver...
 * Loading ALSA modules ...
 *   Loading: snd-card-0 
...                                                                                                           
[ ok ]
 *   Loading: snd-pcm-oss ...
WARNING: Error inserting snd_mixer_oss 
(/lib/modules/2.6.16-gentoo-r13/kernel/sound/core/oss/snd-mixer-oss.ko): 
Unknown symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting snd_pcm_oss 
(/lib/modules/2.6.16-gentoo-r13/kernel/sound/core/oss/snd-pcm-oss.ko): 
Unknown symbol in module, or unknown parameter (see 
dmesg)                                                                                                                
[ !! ]
 *   Loading: snd-mixer-oss ...
FATAL: Error inserting snd_mixer_oss 
(/lib/modules/2.6.16-gentoo-r13/kernel/sound/core/oss/snd-mixer-oss.ko): 
Unknown symbol in module, or unknown parameter (see 
dmesg)                                                                                                            
[ !! ]
 *   Loading: snd-seq 
...                                                                                                              
[ ok ]
 * Restoring Mixer Levels 
...                                                                                                          
[ ok ]
Setting default volumes...


Any help will be appreciated

Rafael


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Alsa problem

[Drake Donahue]

what does

dmesg | grep oss

say?
----- Original Message ----- 
From: "Rafael Barrera Oro" <rafael@akyasociados.com.ar>
To: <gentoo-amd64@lists.gentoo.org>
Sent: Tuesday, August 01, 2006 3:16 PM
Subject: [gentoo-amd64] Alsa problem


>I have a problem configuring alsa, and was wonderign if maybe i am ignoring 
>something specific of the amd64 architecture:
>
> i followed the steps of the gentoo alsa guide (using the kernel module) 
> and after compiling the kernel i run alsaconf and get this:
>
> Running modules-update...
> Loading driver...
> * Loading ALSA modules ...
> *   Loading: snd-card-0 ... 
> [ ok ]
> *   Loading: snd-pcm-oss ...
> WARNING: Error inserting snd_mixer_oss 
> (/lib/modules/2.6.16-gentoo-r13/kernel/sound/core/oss/snd-mixer-oss.ko): 
> Unknown symbol in module, or unknown parameter (see dmesg)
> FATAL: Error inserting snd_pcm_oss 
> (/lib/modules/2.6.16-gentoo-r13/kernel/sound/core/oss/snd-pcm-oss.ko): 
> Unknown symbol in module, or unknown parameter (see dmesg) 
> [ !! ]
> *   Loading: snd-mixer-oss ...
> FATAL: Error inserting snd_mixer_oss 
> (/lib/modules/2.6.16-gentoo-r13/kernel/sound/core/oss/snd-mixer-oss.ko): 
> Unknown symbol in module, or unknown parameter (see dmesg) 
> [ !! ]
> *   Loading: snd-seq ... 
> [ ok ]
> * Restoring Mixer Levels ... 
> [ ok ]
> Setting default volumes...
>
>
> Any help will be appreciated
>
> Rafael
>
>
> -- 
> gentoo-amd64@gentoo.org mailing list
> 

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Alsa problem

[Rafael Barrera Oro]

Just this:

    Adding 1012084k swap on /dev/hda2.  Priority:-1 extents:1 
across:1012084k

so i guess oss is not the problem is it?

Drake Donahue wrote:
> what does
>
> dmesg | grep oss
>
> say?
> ----- Original Message ----- From: "Rafael Barrera Oro" 
> <rafael@akyasociados.com.ar>
> To: <gentoo-amd64@lists.gentoo.org>
> Sent: Tuesday, August 01, 2006 3:16 PM
> Subject: [gentoo-amd64] Alsa problem
>
>
>> I have a problem configuring alsa, and was wonderign if maybe i am 
>> ignoring something specific of the amd64 architecture:
>>
>> i followed the steps of the gentoo alsa guide (using the kernel 
>> module) and after compiling the kernel i run alsaconf and get this:
>>
>> Running modules-update...
>> Loading driver...
>> * Loading ALSA modules ...
>> *   Loading: snd-card-0 ... [ ok ]
>> *   Loading: snd-pcm-oss ...
>> WARNING: Error inserting snd_mixer_oss 
>> (/lib/modules/2.6.16-gentoo-r13/kernel/sound/core/oss/snd-mixer-oss.ko): 
>> Unknown symbol in module, or unknown parameter (see dmesg)
>> FATAL: Error inserting snd_pcm_oss 
>> (/lib/modules/2.6.16-gentoo-r13/kernel/sound/core/oss/snd-pcm-oss.ko): 
>> Unknown symbol in module, or unknown parameter (see dmesg) [ !! ]
>> *   Loading: snd-mixer-oss ...
>> FATAL: Error inserting snd_mixer_oss 
>> (/lib/modules/2.6.16-gentoo-r13/kernel/sound/core/oss/snd-mixer-oss.ko): 
>> Unknown symbol in module, or unknown parameter (see dmesg) [ !! ]
>> *   Loading: snd-seq ... [ ok ]
>> * Restoring Mixer Levels ... [ ok ]
>> Setting default volumes...
>>
>>
>> Any help will be appreciated
>>
>> Rafael
>>
>>
>> -- 
>> gentoo-amd64@gentoo.org mailing list
>>
>

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Alsa problem

[Duncan]

Rafael Barrera Oro <rafael@akyasociados.com.ar> posted
44D0C045.9010006@akyasociados.com.ar, excerpted below, on  Wed, 02 Aug
2006 12:09:57 -0300:

>     Adding 1012084k swap on /dev/hda2.  Priority:-1 extents:1
> across:1012084k

Ugh... people and their upside down quoting...  I guess you are just
following DD's lead, but it makes it difficult to get proper context, in
any case, so I guess I'll let folks check the upline posts for context.

It seems dmesg | grep oss is only printing the above (due to the oss in
across).  I was wondering if it would cut out too much and it looks like
it did.  Maybe grep OSS (caps) instead, or maybe post the entire output.

In general, however, this may be a conflict either between the kernel and
the out of kernel drivers if you used them, or the kernel drivers and the
alsa user side utilities, if you used the kernel alsa.  Thus, whichever
you used, try the other.  It might work better.

So... try posting the dmesg output, and while you are waiting for a reply
on that, you can try the other alsa driver solution. =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Alsa problem

[J'raxis 270145]

At 2006-08-02T18:42:06+0000, <1i5t5.duncan@cox.net> wrote:

> Date: Wed, 2 Aug 2006 18:42:06 +0000 (UTC)
> From: Duncan <1i5t5.duncan@cox.net>
> Reply-to: gentoo-amd64@lists.gentoo.org
> Subject: [gentoo-amd64]  Re: Alsa problem
> To: gentoo-amd64@lists.gentoo.org
> Message-ID: <eaqrlt$in8$1@sea.gmane.org>
> User-Agent: pan 0.105 (When Churchill opened the door, it was a new car, a
> 	Chevrolet Nova.)
> 
> Rafael Barrera Oro <rafael@akyasociados.com.ar> posted
> 44D0C045.9010006@akyasociados.com.ar, excerpted below, on  Wed, 02 Aug
> 2006 12:09:57 -0300:
> 
> >     Adding 1012084k swap on /dev/hda2.  Priority:-1 extents:1
> > across:1012084k
> 
> Ugh... people and their upside down quoting...  I guess you are just
> following DD's lead, but it makes it difficult to get proper context, in
> any case, so I guess I'll let folks check the upline posts for context.
> 
> It seems dmesg | grep oss is only printing the above (due to the oss in
> across).  I was wondering if it would cut out too much and it looks like
> it did.  Maybe grep OSS (caps) instead, or maybe post the entire output.

dmesg | grep -i oss

-- 
J'raxis 270145
http://www.jraxis.com/
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Alsa problem

[Rafael Barrera Oro]

Thanks, ill do that shortly, sorry about the posting thing but i dont 
fully understand what i did wrong.

Rafael
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: Alsa problem

[Duncan]

Rafael Barrera Oro <rafael@akyasociados.com.ar> posted
44D1F44E.9070908@akyasociados.com.ar, excerpted below, on  Thu, 03 Aug
2006 10:04:14 -0300:

> Thanks, ill do that shortly, sorry about the posting thing but i dont 
> fully understand what i did wrong.

Not a big deal.  As I said, you were only following the guy ahead of you,
and even if you weren't, it's not like you posted HTML or a virus or
something with security implications.

Rather (and again, this isn't pointed just at you), consider the following
(obviously fictitious) example, and how much more difficult it could be to
follow with the replies at the top, quotes at bottom.

 Mary wrote:
 >Sam wrote:
 >>Henry wrote:
 >>>Elizabeth wrote:
 >>>How do I stop my cat eating the furniture?
 >>Have you tried putting a velcro cover on?
 >That's ok if you do not have children, but they tear the velcro - what
 >then?
 Try guaranteed child-proof super-velcro: I have been using it ever since
 I had my fourth child - and my sixth cat. 

That example is taken from 
http://www.blakjak.demon.co.uk/gey_stv0.htm

I've learned to deal with reading both directions, but I always reply
right side up (top quote, bottom reply), and if my upstream thread did
things upside down, it becomes far harder to maintain proper context.

The key is to quote and reply to only one point at a time, editing or
summarizing the quote so it's obvious the point you are replying to, and
rarely is none of your reply onscreen (so no quoting several pages to
reply with two lines at the bottom).

Besides having the reply out of context, top posting encourages people to
forget to trim to only the points they are replying to, sometimes making
it difficult to figure out which point they had in mind.  If the quote is
properly trimmed and replied to point by point, that's not an issue.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Alsa problem

[Rafael Barrera Oro]

Duncan wrote:
> Rafael Barrera Oro <rafael@akyasociados.com.ar> posted
> 44D0C045.9010006@akyasociados.com.ar, excerpted below, on  Wed, 02 Aug
> 2006 12:09:57 -0300:
>
>   
>>     Adding 1012084k swap on /dev/hda2.  Priority:-1 extents:1
>> across:1012084k
>>     
>
> Ugh... people and their upside down quoting...  I guess you are just
> following DD's lead, but it makes it difficult to get proper context, in
> any case, so I guess I'll let folks check the upline posts for context.
>
> It seems dmesg | grep oss is only printing the above (due to the oss in
> across).  I was wondering if it would cut out too much and it looks like
> it did.  Maybe grep OSS (caps) instead, or maybe post the entire output.
>
> In general, however, this may be a conflict either between the kernel and
> the out of kernel drivers if you used them, or the kernel drivers and the
> alsa user side utilities, if you used the kernel alsa.  Thus, whichever
> you used, try the other.  It might work better.
>
> So... try posting the dmesg output, and while you are waiting for a reply
> on that, you can try the other alsa driver solution. =8^)
>
>   
Now i get it, so it wont happen again :D, anyhow here is my complete 
dmesg output:

Bootdata ok (command line is root=/dev/ram0 init=/linuxrc ramdisk=8192 
real_root=/dev/hda3 )
Linux version 2.6.16-gentoo-r13 (root@patriciorey) (gcc version 3.4.4 
(Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)) #1 Tue Aug 1 13:29:58 ART 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001ffb0000 (usable)
 BIOS-e820: 000000001ffb0000 - 000000001ffc0000 (ACPI data)
 BIOS-e820: 000000001ffc0000 - 000000001fff0000 (ACPI NVS)
 BIOS-e820: 000000001fff0000 - 0000000020000000 (reserved)
 BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved)
ACPI: RSDP (v000 ACPIAM                                ) @ 
0x00000000000fa880
ACPI: RSDT (v001 A M I  OEMRSDT  0x11000503 MSFT 0x00000097) @ 
0x000000001ffb0000
ACPI: FADT (v001 A M I  OEMFACP  0x11000503 MSFT 0x00000097) @ 
0x000000001ffb0200
ACPI: MADT (v001 A M I  OEMAPIC  0x11000503 MSFT 0x00000097) @ 
0x000000001ffb0390
ACPI: OEMB (v001 A M I  OEMBIOS  0x11000503 MSFT 0x00000097) @ 
0x000000001ffc0040
ACPI: DSDT (v001  A0277 A0277001 0x00000001 MSFT 0x0100000d) @ 
0x0000000000000000
On node 0 totalpages: 127879
  DMA zone: 2717 pages, LIFO batch:0
  DMA32 zone: 125162 pages, LIFO batch:31
  Normal zone: 0 pages, LIFO batch:0
  HighMem zone: 0 pages, LIFO batch:0
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:15 APIC version 16
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x81] disabled)
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 3, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 30000000 (gap: 20000000:df780000)
Checking aperture...
CPU 0: aperture @ d0000000 size 256 MB
Built 1 zonelists
Kernel command line: root=/dev/ram0 init=/linuxrc ramdisk=8192 
real_root=/dev/hda3
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 65536 bytes)
time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
time.c: Detected 1802.420 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
Memory: 508760k/523968k available (3160k kernel code, 14476k reserved, 
1125k data, 212k init)
Calibrating delay using timer specific routine.. 3614.17 BogoMIPS 
(lpj=7228347)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: AMD Athlon(tm) 64 Processor 3000+ stepping 02
Using local APIC timer interrupts.
result 12516813
Detected 12.516 MHz APIC timer.
testing NMI watchdog ... OK.
checking if image is initramfs... it is
Freeing initrd memory: 1554k freed
DMI 2.3 present.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 *10 11 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 7 10 11 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 10 11 14 15) *0, disabled.
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a 
report
TC classifier action (bugs to netdev@vger.kernel.org cc hadi@cyberus.ca)
agpgart: Detected AGP bridge 0
agpgart: AGP aperture is 256M @ 0xd0000000
PCI-DMA: Disabling IOMMU.
PCI: Bridge: 0000:00:01.0
  IO window: e000-efff
  MEM window: fbd00000-fbffffff
  PREFETCH window: e8000000-faffffff
PCI: Setting latency timer of device 0000:00:01.0 to 64
IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $
Total HugeTLB memory allocated, 0
squashfs: version 3.0 (2006/03/15) Phillip Lougher
JFS: nTxBlock = 3989, nTxLock = 31916
SGI XFS with ACLs, large block/inode numbers, no debug enabled
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
Linux agpgart interface v0.101 (c) Dave Jones
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Sleep Button (CM) [SLPB]
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
mice: PS/2 mouse device common for all mice
isa bounce pool size: 16 pages
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Probing IDE interface ide0...
input: AT Translated Set 2 keyboard as /class/input/input0
hda: Maxtor 2R015H1, ATA DISK drive
input: ImPS/2 Generic Wheel Mouse as /class/input/input1
Probing IDE interface ide1...
hdd: SAMSUNG CD-ROM SC-152B, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 29297520 sectors (15000 MB) w/2048KiB Cache, CHS=29065/16/63
hda: cache flushes not supported
 hda: hda1 hda2 hda3
hdd: ATAPI 52X CD-ROM drive, 128kB Cache
Uniform CD-ROM driver Revision: 3.20
usbmon: debugfs is not available
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
raid5: automatically using best checksumming function: generic_sse
   generic_sse:  5509.000 MB/sec
raid5: using function: generic_sse (5509.000 MB/sec)
raid6: int64x1   1666 MB/s
raid6: int64x2   2396 MB/s
raid6: int64x4   2345 MB/s
raid6: int64x8   1609 MB/s
raid6: sse2x1     777 MB/s
raid6: sse2x2    1319 MB/s
raid6: sse2x4    2147 MB/s
raid6: using algorithm sse2x4 (2147 MB/s)
md: raid6 personality registered for level 6
md: multipath personality registered for level -4
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
device-mapper: 4.5.0-ioctl (2005-10-04) initialised: dm-devel@redhat.com
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 3, 32768 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 5, 131072 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 15
powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.60.0)
powernow-k8: BIOS error - no PSB or ACPI _PSS objects
ACPI wakeup devices:
PCI0 PS2K PS2M UAR1 AC97 USB1 USB2 USB3 USB4 EHCI PWRB SLPB
ACPI: (supports S0 S1 S3 S4 S5)
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Freeing unused kernel memory: 212k freed
GSI 16 sharing vector 0xA9 and IRQ 16
ACPI: PCI Interrupt 0000:00:10.4[C] -> GSI 21 (level, low) -> IRQ 16
ehci_hcd 0000:00:10.4: EHCI Host Controller
ehci_hcd 0000:00:10.4: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:10.4: irq 16, io mem 0xfbc00000
ehci_hcd 0000:00:10.4: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
USB Universal Host Controller Interface driver v2.3
ACPI: PCI Interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 16
PCI: VIA IRQ fixup for 0000:00:10.0, from 11 to 0
uhci_hcd 0000:00:10.0: UHCI Host Controller
uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:10.0: irq 16, io base 0x0000c400
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:10.1[A] -> GSI 21 (level, low) -> IRQ 16
PCI: VIA IRQ fixup for 0000:00:10.1, from 11 to 0
uhci_hcd 0000:00:10.1: UHCI Host Controller
uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:10.1: irq 16, io base 0x0000c800
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:10.2[B] -> GSI 21 (level, low) -> IRQ 16
PCI: VIA IRQ fixup for 0000:00:10.2, from 10 to 0
uhci_hcd 0000:00:10.2: UHCI Host Controller
uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:10.2: irq 16, io base 0x0000d000
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:10.3[B] -> GSI 21 (level, low) -> IRQ 16
PCI: VIA IRQ fixup for 0000:00:10.3, from 10 to 0
uhci_hcd 0000:00:10.3: UHCI Host Controller
uhci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:10.3: irq 16, io base 0x0000d400
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ieee1394: Initialized config rom entry `ip1394'
ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1)
ieee1394: sbp2: Try serialize_io=0 for better performance
libata version 1.20 loaded.
sata_via 0000:00:0f.0: version 1.1
GSI 17 sharing vector 0xB1 and IRQ 17
ACPI: PCI Interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 17
sata_via 0000:00:0f.0: routed to hard irq line 10
ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xB802 bmdma 0xA800 irq 17
ata2: SATA max UDMA/133 cmd 0xB400 ctl 0xB002 bmdma 0xA808 irq 17
ata1: SATA link down (SStatus 0)
scsi0 : sata_via
ata2: SATA link down (SStatus 0)
scsi1 : sata_via
ReiserFS: hda3: warning: sh-2021: reiserfs_fill_super: can not find 
reiserfs on hda3
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Adding 1012084k swap on /dev/hda2.  Priority:-1 extents:1 across:1012084k
EXT3 FS on hda3, internal journal
GSI 18 sharing vector 0xB9 and IRQ 18
ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 17 (level, low) -> IRQ 18
eth0: Yukon Gigabit Ethernet 10/100/1000Base-T Adapter
      PrefPort:A  RlmtMode:Check Link State
VP_IDE: IDE controller at PCI slot 0000:00:0f.1
ACPI: PCI Interrupt 0000:00:0f.1[A] -> GSI 20 (level, low) -> IRQ 17
PCI: VIA IRQ fixup for 0000:00:0f.1, from 255 to 1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1
VP_IDE: port 0x01f0 already claimed by ide0
VP_IDE: port 0x0170 already claimed by ide1
VP_IDE: neither IDE port enabled (BIOS)
snd: no version for "struct_module" found: kernel tainted.
GSI 19 sharing vector 0xC1 and IRQ 19
ACPI: PCI Interrupt 0000:00:11.5[C] -> GSI 22 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:11.5 to 64
ADDRCONF(NETDEV_UP): eth0: link is not ready
eth0: network connection up using port A
    speed:           100
    autonegotiation: yes
    duplex mode:     full
    flowctrl:        symmetric
    irq moderation:  disabled
    scatter-gather:  disabled
    tx-checksum:     disabled
    rx-checksum:     disabled
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
eth0: no IPv6 routers present

Thanks for your help (with the alsa and making me a better mail list 
user ;) )

Rafa
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: Alsa problem

[Duncan]

Rafael Barrera Oro <rafael@akyasociados.com.ar> posted
44D20235.9090706@akyasociados.com.ar, excerpted below, on  Thu, 03 Aug
2006 11:03:33 -0300:

I have a couple other comments, possible hints, besides alsa...  Take them
or leave them as you see fit.  If you only want the alsa stuff, look for
the "snd" entry down near the bottom.

> JFS: nTxBlock = 3989, nTxLock = 31916
> SGI XFS with ACLs, large block/inode numbers, no debug enabled

I see JFS and XFS file systems here... then down near the bottom...

> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> Probing IDE interface ide0...

I see you have generic IDE drivers here, then Via below.  The generics
load first so get used...

> md: linear personality registered for level -1
> md: raid0 personality registered for level 0
> md: raid1 personality registered for level 1
> md: raid5 personality registered for level 5
> md: raid4 personality registered for level 4

> md: raid6 personality registered for level 6
> md: multipath personality registered for level -4
> md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
> md: bitmap version 4.39
> device-mapper: 4.5.0-ioctl (2005-10-04) initialised: dm-devel@redhat.com

Hmm...  RAID and LVM?  Cool! =8^)  I'm running a RAID 0/1/6 setup here,
with LVM but not on root, so I don't have to hassle the initramfs.  I'm
running partitioned RAID, however, with a working and backup copy of the
root partition.  Interesting to see someone else with md-raid.

If you aren't using all these personalities, you can deconfigure the ones
you don't use.  It'd be unusual to use the linear personality with the
others, for instance, and multipath you probably don't need as well,
unless you have a very expensive setup.  That's possible, but if so,
linear is even more unlikely, so you can almost certainly deconfigure one,
and possibly both.

Of course, if you're not using RAID/LVM at all, you can disable the entire
md and probably device-mapper config as well, saving more kernel memory.

> libata version 1.20 loaded.
> sata_via 0000:00:0f.0: version 1.1

> sata_via 0000:00:0f.0: routed to hard irq line 10
> ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xB802 bmdma 0xA800 irq 17
> ata2: SATA max UDMA/133 cmd 0xB400 ctl 0xB002 bmdma 0xA808 irq 17
> ata1: SATA link down (SStatus 0)
> scsi0 : sata_via
> ata2: SATA link down (SStatus 0)
> scsi1 : sata_via

You have both SATA and PATA drives?  Not entirely unusual, but if not, you
can kill the config on the one you aren't using, saving a bit more kernel
memory/size.

> ReiserFS: hda3: warning: sh-2021: reiserfs_fill_super: can not find 
> reiserfs on hda3
> kjournald starting.  Commit interval 5 seconds
> EXT3-fs: mounted filesystem with ordered data mode.

... I see ReiserFS and Ext3 here, in addition to the JFS/XFS above.  If
you aren't using all four filesystem types, you could deconfigure what you
aren't using.  (I use all reiserfs here, built-in, with FAT, ext2, and
iso9660 as modules that aren't normally loaded, therefore saving that bit
of kernel size.)

> VP_IDE: IDE controller at PCI slot 0000:00:0f.1

> VP_IDE: chipset revision 6
> VP_IDE: not 100% native mode: will probe irqs later
> VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1
> VP_IDE: port 0x01f0 already claimed by ide0
> VP_IDE: port 0x0170 already claimed by ide1
> VP_IDE: neither IDE port enabled (BIOS)

The second set of IDE drivers.  These are the one's for your chipset as it
detects the chipset.  However, the generic IDE drivers above are already
handling the drives, so these do nothing.  Unless you have something else
(and add-on card?) that needs the generic drivers, I'd say dump them and
go with these.  That should allow you faster DMA access.

Right now you have three separate hard drive chipset drivers loaded, the
generic IDE, Via-SATA, and VIA-IDE.  Here it says VIA-IDE can't do
anything as the generics are already handling the hardware, so you can
almost certainly get rid of one or the other of those (I'd say the
generics).  As mentioned above, if you don't have anything hooked up to
the SATA, you might as well deconfigure those as well.  You can always
reconfigure them if you get SATA drives later.

> snd: no version for "struct_module" found: kernel tainted.

This one's the only thing I see about sound.  As I suspected, it's a
version mismatch between your running kernel and the driver that's trying
to load.  You'll want to either enable the kernel's sound drivers and not
worry about the external driver (that's what I do, as it'll be less
problems most of the time for all but the newest sound hardware), or
ensure that you are compiling the external alsa drivers against the
specific kernel you are running, /not/ a different one.  As the guide
says, you'll need to recompile your alsa drivers each time you recompile
the kernel, if you choose the external drivers.

**IMPORTANT**  The ALSA guide actually deals with exactly the error you
are getting, down near the bottom in the troubleshooting stuff.  The most
common reason, it says, is that you switched from external to in-kernel
drivers, and didn't remove the old external drivers.  Due to portage's
config-protect, which saves all your config files from getting overwritten
automatically, portage won't automatically remove the old external
drivers, and the initscripts will still try to load the old and stale
drivers until you manually remove them so it can use the kernel drivers. 
Of course, this would be your most likely problem.

> eth0: no IPv6 routers present

I don't deal with IPv6 here, so can't say for sure on this, but it looks
to me like you don't have an IPv6 connection either, based on the above.
If that's indeed the case, you're all IPv4, again, deconfiguring IPv6 out
of your kernel will save you that bit of memory.

Keep in mind that kernel memory is locked memory -- it's never swapped. 
Therefore, wasted kernel memory is memory that can't be used by your
programs or for cache.  If you aren't using part of your kernel that's
loaded, you aren't running as efficient as you could be.

One bonus to setting all the unused stuff above to "no", is that you'll
have a rather shorter dmesg log, should you need to do any future
troubleshooting. =8^)

Hint for testing the kernel, if you aren't sure what you are removing.
Remember when testing what that you can safely turn off in your kernel,
to make sure you have a working bootable kernel around, then install
another one, and configure GRUB/LILO so you can boot either one.  That
way, if the test one screws up, all you have to do is reboot to the known
working one and turn on whatever feature you turned off that made it not
boot.  

FWIW, it does take a bit to learn what all those kernel options are and do,
but once you've learned what stuff does and how the kernel is laid out,
even switching to an entirely different mobo, or even from x86 to amd64,
isn't a big problem, as you'll find you already have a good idea where to
look for stuff.  I know it took me several sessions of going thru the
kernel options to figure out what everything was.  After that, as I said,
even switching to amd64 wasn't as big a deal as I thought it might be,
because I already understood how the kernel config layout worked and where
everything was.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list