All of lore.kernel.org
 help / color / mirror / Atom feed
From: Len Brown <len.brown@intel.com>
To: "Jürgen Repolusk" <juerep@gmx.at>
Cc: linux-kernel@vger.kernel.org
Subject: Re: ALSA via82xx fails since 2.6.2
Date: 12 Mar 2004 20:52:46 -0500	[thread overview]
Message-ID: <1079142765.2175.71.camel@dhcppc4> (raw)
In-Reply-To: <A6974D8E5F98D511BB910002A50A6647615F4E8F@hdsmsx402.hd.intel.com>

On Fri, 2004-03-12 at 15:34, Jürgen Repolusk wrote:

> I see this in dmesg on 2.6.4-rc1:
> 
> VIA 82xx Audio: probe of 0000:00:07.5 failed with error -16
> 

I don't know if it is related to the audio failure, but interrupts in
general and the ACPI SCI in particular seem totally broken on this box
(below)

> this is on a sony vaio pcg-fx505
> 
> regards
> juergen repolusk, please CC me personally
> 
> complete dmesg (+lspci follow)
> ADT (v001 SONY   K5       0x06040000 PTL_ 0x000f4240) @ 0x0fefee4c
> ACPI: BOOT (v001 PTLTD  $SBFTBL$ 0x06040000  LTP 0x00000001) @
> 0x0fefeec0
> ACPI: SSDT (v001 PTLTD  POWERNOW 0x06040000  LTP 0x00000001) @
> 0x0fefeee8
> ACPI: DSDT (v001  SONY  K5       0x06040000 MSFT 0x0100000d) @
> 0x00000000
> Built 1 zonelists
> Kernel command line: BOOT_IMAGE=gentoo264 ro root=303 apm=off acpi=on
> vga=0x318
> Local APIC disabled by BIOS -- reenabling.
> Found and enabled local APIC!
> Initializing CPU#0
> PID hash table entries: 2048 (order 11: 16384 bytes)
> Detected 1200.077 MHz processor.
> Using tsc for high-res timesource
> Console: colour dummy device 80x25
> Memory: 254264k/262144k available (2817k kernel code, 7056k reserved,
> 1078k
> data, 172k init, 0k highmem)
> Checking if this processor honours the WP bit even in supervisor
> mode... Ok.
> Calibrating delay loop... 2359.29 BogoMIPS
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> CPU:     After generic identify, caps: 0383fbff c1cbfbff 00000000
> 00000000
> CPU:     After vendor identify, caps: 0383fbff c1cbfbff 00000000
> 00000000
> CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
> CPU: L2 Cache: 256K (64 bytes/line)
> CPU:     After all inits, caps: 0383fbff c1cbfbff 00000000 00000020
> Intel machine check architecture supported.
> Intel machine check reporting enabled on CPU#0.
> CPU: AMD mobile AMD Athlon(tm) 4  stepping 02
> Enabling fast FPU save and restore... done.
> Enabling unmasked SIMD FPU exception support... done.
> Checking 'hlt' instruction... OK.
> POSIX conformance testing by UNIFIX
> enabled ExtINT on CPU#0
> ESR value before enabling vector: 00000000
> ESR value after enabling vector: 00000000
> Using local APIC timer interrupts.
> calibrating APIC timer ...
> ..... CPU clock speed is 1199.0872 MHz.
> ..... host bus clock speed is 199.0978 MHz.
> NET: Registered protocol family 16
> PCI: PCI BIOS revision 2.10 entry at 0xfd7cd, last bus=1
> PCI: Using configuration type 1
> mtrr: v2.0 (20020519)
> ACPI: Subsystem revision 20040211
> ACPI: IRQ9 SCI: Level Trigger.
> spurious 8259A interrupt: IRQ7.

Spurious on IRQ7 may mean that a device is pulling an interrupt line
which has no driver attached.

> irq 9: nobody cared!
> Call Trace:
>  [<c010b69b>] __report_bad_irq+0x2b/0x90
>  [<c02592ad>] acpi_irq+0xf/0x1a
>  [<c010b794>] note_interrupt+0x64/0xa0
>  [<c010ba73>] do_IRQ+0x143/0x160
>  [<c0109dc8>] common_interrupt+0x18/0x20

Here we've apparently gone recursive on the interrupt handler, I don't
think that is supposed to be possible.

>  [<c0126a94>] do_softirq+0x44/0xa0
>  [<c025929e>] acpi_irq+0x0/0x1a
>  [<c010ba47>] do_IRQ+0x117/0x160
>  [<c0109dc8>] common_interrupt+0x18/0x20
>  [<c010c04c>] setup_irq+0x9c/0x100
>  [<c025929e>] acpi_irq+0x0/0x1a

okay, so we got an acpi_irq() right when we requeted the IRQ, that is
unusual, but should be okay.  Curious that common_interrupt/do_IRQ are
not on the stack here though...

>  [<c010bb68>] request_irq+0x98/0xd0
>  [<c02592ed>] acpi_os_install_interrupt_handler+0x35/0x5b

>  [<c025929e>] acpi_irq+0x0/0x1a
>  [<c025929e>] acpi_irq+0x0/0x1a

dunno what's the deal with the stack here acpi_irq() is not called from
acpi_ev_install_sci_handler(), and request_irq() hasn't even been called
yet!

>  [<c025d58e>] acpi_ev_install_sci_handler+0x1d/0x1f
>  [<c025d548>] acpi_ev_sci_xrupt_handler+0x0/0x1c
>  [<c025cf8d>] acpi_ev_handler_initialize+0x9/0x71
>  [<c026ebf4>] acpi_enable_subsystem+0x2e/0x5b
>  [<c04e35d2>] acpi_bus_init+0x7c/0x111
>  [<c04e36c0>] acpi_init+0x59/0xb4
>  [<c04d082c>] do_initcalls+0x2c/0xa0
>  [<c01332c2>] init_workqueues+0x12/0x30
>  [<c01050d5>] init+0x35/0x140
>  [<c01050a0>] init+0x0/0x140
>  [<c01072c9>] kernel_thread_helper+0x5/0xc
> 
> handlers:
> [<c025929e>] (acpi_irq+0x0/0x1a)
> Disabling IRQ #9
> ACPI: Interpreter enabled

What does /proc/interrupts on this box look like?
how about when you boot with acpi=off or pci=noacpi?

Are you sure you didn't see these messages before 2.6.2 -- was ACPI
enabled in the working release?

thanks,
-Len



       reply	other threads:[~2004-03-13  1:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <A6974D8E5F98D511BB910002A50A6647615F4E8F@hdsmsx402.hd.intel.com>
2004-03-13  1:52 ` Len Brown [this message]
2004-03-13  2:36   ` ALSA via82xx fails since 2.6.2 Jürgen Repolusk
2004-03-13  4:41     ` Len Brown
2004-03-12 20:34 Jürgen Repolusk
2004-03-13  7:02 ` Willy Tarreau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1079142765.2175.71.camel@dhcppc4 \
    --to=len.brown@intel.com \
    --cc=juerep@gmx.at \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.