00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03)
Subsystem: Lenovo Thinkpad R60e model 0657
Flags: bus master, fast devsel, latency 0
Capabilities: [e0] Vendor Specific Information
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA])
Subsystem: Lenovo Thinkpad R60e model 0657
Flags: bus master, fast devsel, latency 0, IRQ 201
Memory at ee100000 (32-bit, non-prefetchable) [size=512K]
I/O ports at 1800 [size=8]
Memory at d0000000 (32-bit, prefetchable) [size=256M]
Memory at ee200000 (32-bit, non-prefetchable) [size=256K]
Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
Capabilities: [d0] Power Management version 2
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
Subsystem: Lenovo Thinkpad R60e model 0657
Flags: fast devsel
Memory at ee180000 (32-bit, non-prefetchable) [size=512K]
Capabilities: [d0] Power Management version 2
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
Subsystem: Lenovo ThinkPad T60/R60 series
Flags: bus master, fast devsel, latency 0, IRQ 58
Memory at ee240000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
Capabilities: [70] Express Unknown type IRQ 0
Capabilities: [100] Virtual Channel
Capabilities: [130] Unknown (5)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 00002000-00002fff
Memory behind bridge: ee000000-ee0fffff
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
Capabilities: [100] Virtual Channel
Capabilities: [180] Unknown (5)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00003000-00004fff
Memory behind bridge: ec000000-edffffff
Prefetchable memory behind bridge: 00000000e4000000-00000000e4000000
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
Capabilities: [100] Virtual Channel
Capabilities: [180] Unknown (5)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=04, subordinate=0b, sec-latency=0
I/O behind bridge: 00005000-00006fff
Memory behind bridge: e8000000-e9ffffff
Prefetchable memory behind bridge: 00000000e4100000-00000000e4100000
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
Capabilities: [100] Virtual Channel
Capabilities: [180] Unknown (5)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=0c, subordinate=13, sec-latency=0
I/O behind bridge: 00007000-00008fff
Memory behind bridge: ea000000-ebffffff
Prefetchable memory behind bridge: 00000000e4200000-00000000e4200000
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
Capabilities: [100] Virtual Channel
Capabilities: [180] Unknown (5)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02) (prog-if 00 [UHCI])
Subsystem: Lenovo ThinkPad T60/R60 series
Flags: bus master, medium devsel, latency 0, IRQ 201
I/O ports at 1820 [size=32]
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02) (prog-if 00 [UHCI])
Subsystem: Lenovo ThinkPad T60/R60 series
Flags: bus master, medium devsel, latency 0, IRQ 58
I/O ports at 1840 [size=32]
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02) (prog-if 00 [UHCI])
Subsystem: Lenovo ThinkPad T60/R60 series
Flags: bus master, medium devsel, latency 0, IRQ 66
I/O ports at 1860 [size=32]
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02) (prog-if 00 [UHCI])
Subsystem: Lenovo ThinkPad T60/R60 series
Flags: bus master, medium devsel, latency 0, IRQ 74
I/O ports at 1880 [size=32]
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
Subsystem: Lenovo ThinkPad T60/R60 series
Flags: bus master, medium devsel, latency 0, IRQ 74
Memory at ee444000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) (prog-if 01 [Subtractive decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=15, subordinate=18, sec-latency=32
I/O behind bridge: 00009000-0000cfff
Memory behind bridge: e4300000-e7ffffff
Prefetchable memory behind bridge: 00000000e0000000-00000000e3f00000
Capabilities: [50] #0d [0000]
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
Subsystem: Lenovo ThinkPad T60/R60 series
Flags: bus master, medium devsel, latency 0
Capabilities: [e0] Vendor Specific Information
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) (prog-if 8a [Master SecP PriP])
Subsystem: Lenovo Thinkpad R60e model 0657
Flags: bus master, medium devsel, latency 0, IRQ 201
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at 1810 [size=16]
00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller AHCI (rev 02) (prog-if 01 [AHCI 1.0])
Subsystem: Lenovo Thinkpad R60e model 0657
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 201
I/O ports at 18d0 [size=8]
I/O ports at 18c4 [size=4]
I/O ports at 18c8 [size=8]
I/O ports at 18c0 [size=4]
I/O ports at 18b0 [size=16]
Memory at ee444400 (32-bit, non-prefetchable) [size=1K]
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
Capabilities: [70] Power Management version 2
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
Subsystem: Lenovo ThinkPad T60/R60 series
Flags: medium devsel, IRQ 193
I/O ports at 18e0 [size=32]
02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
Subsystem: Lenovo Thinkpad X60s
Flags: bus master, fast devsel, latency 0, IRQ 201
Memory at ee000000 (32-bit, non-prefetchable) [size=128K]
I/O ports at 2000 [size=32]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable+
Capabilities: [e0] Express Endpoint IRQ 0
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 0b-d2-20-ff-ff-d3-16-00
03:00.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
Subsystem: IBM ThinkPad 11a/b/g Wireless LAN Mini Express Adapter (AR5BXB6)
Flags: bus master, fast devsel, latency 0, IRQ 58
Memory at edf00000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 2
Capabilities: [50] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
Capabilities: [60] Express Legacy Endpoint IRQ 0
Capabilities: [90] MSI-X: Enable- Mask- TabSize=1
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
15:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b4)
Subsystem: Lenovo Thinkpad X60s
Flags: bus master, medium devsel, latency 168, IRQ 201
Memory at e4300000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=15, secondary=16, subordinate=17, sec-latency=176
Memory window 0: e0000000-e1fff000 (prefetchable)
Memory window 1: e6000000-e7fff000
I/O window 0: 00009000-000090ff
I/O window 1: 00009400-000094ff
16-bit legacy interface ports at 0001
15:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 09) (prog-if 10 [OHCI])
Subsystem: Lenovo Thinkpad X60s
Flags: bus master, medium devsel, latency 64, IRQ 58
Memory at e4301000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [dc] Power Management version 2
15:00.2 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 18)
Subsystem: Lenovo Thinkpad X60s
Flags: bus master, medium devsel, latency 64, IRQ 66
Memory at e4301800 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
Hi!
> I have a ThinkPad X60 which uses the Intel 82801G HDA
> audio chip. This used to work for me, but lately
> (sometime during 2.6.18-rcX series) it stopped working -
> programs trying to use it tend to just block forever
> waiting for /dev/dsp.
I have x60 here,
> The only obvious symptom is:
>
> hda_intel: azx_get_response timeout, switching to
> single_cmd mode...
>
sometimes see this message, too, and sound more or less works for me.
(Using alsa interface, mplayer works ok. mpg123 does not work).
--
Thanks for all the (sleeping) penguins.
Pavel Machek wrote:
> sometimes see this message, too, and sound more or less works for me.
> (Using alsa interface, mplayer works ok. mpg123 does not work).
>
That's how it used to be for me, but not any more.
J
Pavel Machek wrote:
> Hi!
>
>
>> I have a ThinkPad X60 which uses the Intel 82801G HDA
>> audio chip. This used to work for me, but lately
>> (sometime during 2.6.18-rcX series) it stopped working -
>> programs trying to use it tend to just block forever
>> waiting for /dev/dsp.
>>
>
> I have x60 here,
>
>
>> The only obvious symptom is:
>>
>> hda_intel: azx_get_response timeout, switching to
>> single_cmd mode...
>>
>>
I got similar kernel message relating to an azx_get_response timeout
with an 82801G HDA audio running Debian kernel 2.6.16-2 (happened during
suspend to ram IIRC) - after replacing kernel alsa with alsa-source
1.0.12 (24 Aug release) the problem went away (in addition to making
sound come out when it didn't before).
Not sure if this info helps but trying the alsa-project release and
seeing if that works may help identify what needs fixing in mainline
hda_intel.
~mc
At Mon, 25 Sep 2006 12:58:08 -0700,
Jeremy Fitzhardinge wrote:
>
> I have a ThinkPad X60 which uses the Intel 82801G HDA audio chip. This
> used to work for me, but lately (sometime during 2.6.18-rcX series) it
> stopped working - programs trying to use it tend to just block forever
> waiting for /dev/dsp.
>
> The only obvious symptom is:
>
> hda_intel: azx_get_response timeout, switching to single_cmd mode...
>
> appearing in the kernel log when booting.
>
There is no big change relevant to TP X60 during 2.6.18rc, so I don't
think it's a regression in the hd-audio driver code.
> Details attached. The dmesg output is for the FC6 distro kernel
> 2.6.18-1.2689.fc6PAE, but I see the same symptoms with 2.6.18-mm1.
You must see difference with mm1 (suppose that mm1 already includes
the latest ALSA patches). When the CORB/RIRB interrupt gets broken,
the driver first switches to poling mode, then single_cmd mode as
fallback.
Also, try disable_msi=1 option for mm1. MSI seems broken on some
systems.
Takashi
On Tue, 26 Sep 2006 12:16:33 +0200 Takashi Iwai wrote:
> At Mon, 25 Sep 2006 12:58:08 -0700,
> Jeremy Fitzhardinge wrote:
> >
> > I have a ThinkPad X60 which uses the Intel 82801G HDA audio chip. This
> > used to work for me, but lately (sometime during 2.6.18-rcX series) it
> > stopped working - programs trying to use it tend to just block forever
> > waiting for /dev/dsp.
> >
> > The only obvious symptom is:
> >
> > hda_intel: azx_get_response timeout, switching to single_cmd mode...
> >
> > appearing in the kernel log when booting.
> >
>
> There is no big change relevant to TP X60 during 2.6.18rc, so I don't
> think it's a regression in the hd-audio driver code.
>
> > Details attached. The dmesg output is for the FC6 distro kernel
> > 2.6.18-1.2689.fc6PAE, but I see the same symptoms with 2.6.18-mm1.
>
> You must see difference with mm1 (suppose that mm1 already includes
> the latest ALSA patches). When the CORB/RIRB interrupt gets broken,
> the driver first switches to poling mode, then single_cmd mode as
> fallback.
>
> Also, try disable_msi=1 option for mm1. MSI seems broken on some
> systems.
is that "pci=nomsi" ?
---
~Randy
At Tue, 26 Sep 2006 08:37:20 -0700,
Randy Dunlap wrote:
>
> On Tue, 26 Sep 2006 12:16:33 +0200 Takashi Iwai wrote:
>
> > At Mon, 25 Sep 2006 12:58:08 -0700,
> > Jeremy Fitzhardinge wrote:
> > >
> > > I have a ThinkPad X60 which uses the Intel 82801G HDA audio chip. This
> > > used to work for me, but lately (sometime during 2.6.18-rcX series) it
> > > stopped working - programs trying to use it tend to just block forever
> > > waiting for /dev/dsp.
> > >
> > > The only obvious symptom is:
> > >
> > > hda_intel: azx_get_response timeout, switching to single_cmd mode...
> > >
> > > appearing in the kernel log when booting.
> > >
> >
> > There is no big change relevant to TP X60 during 2.6.18rc, so I don't
> > think it's a regression in the hd-audio driver code.
> >
> > > Details attached. The dmesg output is for the FC6 distro kernel
> > > 2.6.18-1.2689.fc6PAE, but I see the same symptoms with 2.6.18-mm1.
> >
> > You must see difference with mm1 (suppose that mm1 already includes
> > the latest ALSA patches). When the CORB/RIRB interrupt gets broken,
> > the driver first switches to poling mode, then single_cmd mode as
> > fallback.
> >
> > Also, try disable_msi=1 option for mm1. MSI seems broken on some
> > systems.
>
> is that "pci=nomsi" ?
No, snd-hda-intel driver has a new module option "disable_msi" to
disable MSI support on that driver. As default, it's off, i.e. MSI is
enabled if available. (Well, I feel it's better to rename it
enable_msi and set on as default...)
Sorry for unclear text.
Takashi
On Tue, 26 Sep 2006 17:48:33 +0200 Takashi Iwai wrote:
> At Tue, 26 Sep 2006 08:37:20 -0700,
> Randy Dunlap wrote:
> >
> > On Tue, 26 Sep 2006 12:16:33 +0200 Takashi Iwai wrote:
> >
> > > At Mon, 25 Sep 2006 12:58:08 -0700,
> > > Jeremy Fitzhardinge wrote:
> > > >
> > > > I have a ThinkPad X60 which uses the Intel 82801G HDA audio chip. This
> > > > used to work for me, but lately (sometime during 2.6.18-rcX series) it
> > > > stopped working - programs trying to use it tend to just block forever
> > > > waiting for /dev/dsp.
> > > >
> > > > The only obvious symptom is:
> > > >
> > > > hda_intel: azx_get_response timeout, switching to single_cmd mode...
> > > >
> > > > appearing in the kernel log when booting.
> > > >
> > >
> > > There is no big change relevant to TP X60 during 2.6.18rc, so I don't
> > > think it's a regression in the hd-audio driver code.
> > >
> > > > Details attached. The dmesg output is for the FC6 distro kernel
> > > > 2.6.18-1.2689.fc6PAE, but I see the same symptoms with 2.6.18-mm1.
> > >
> > > You must see difference with mm1 (suppose that mm1 already includes
> > > the latest ALSA patches). When the CORB/RIRB interrupt gets broken,
> > > the driver first switches to poling mode, then single_cmd mode as
> > > fallback.
> > >
> > > Also, try disable_msi=1 option for mm1. MSI seems broken on some
> > > systems.
> >
> > is that "pci=nomsi" ?
>
> No, snd-hda-intel driver has a new module option "disable_msi" to
> disable MSI support on that driver. As default, it's off, i.e. MSI is
> enabled if available. (Well, I feel it's better to rename it
> enable_msi and set on as default...)
>
> Sorry for unclear text.
ugh. We shouldn't have drivers with such options IMO.
I have seen/used MSI for ethernet, SATA, and audio.
It either works for all of them or none of them AFAIK.
Why do you think that it should not just be a global system option/flag?
---
~Randy
At Tue, 26 Sep 2006 08:56:11 -0700,
Randy Dunlap wrote:
>
> On Tue, 26 Sep 2006 17:48:33 +0200 Takashi Iwai wrote:
>
> > At Tue, 26 Sep 2006 08:37:20 -0700,
> > Randy Dunlap wrote:
> > >
> > > On Tue, 26 Sep 2006 12:16:33 +0200 Takashi Iwai wrote:
> > >
> > > > At Mon, 25 Sep 2006 12:58:08 -0700,
> > > > Jeremy Fitzhardinge wrote:
> > > > >
> > > > > I have a ThinkPad X60 which uses the Intel 82801G HDA audio chip. This
> > > > > used to work for me, but lately (sometime during 2.6.18-rcX series) it
> > > > > stopped working - programs trying to use it tend to just block forever
> > > > > waiting for /dev/dsp.
> > > > >
> > > > > The only obvious symptom is:
> > > > >
> > > > > hda_intel: azx_get_response timeout, switching to single_cmd mode...
> > > > >
> > > > > appearing in the kernel log when booting.
> > > > >
> > > >
> > > > There is no big change relevant to TP X60 during 2.6.18rc, so I don't
> > > > think it's a regression in the hd-audio driver code.
> > > >
> > > > > Details attached. The dmesg output is for the FC6 distro kernel
> > > > > 2.6.18-1.2689.fc6PAE, but I see the same symptoms with 2.6.18-mm1.
> > > >
> > > > You must see difference with mm1 (suppose that mm1 already includes
> > > > the latest ALSA patches). When the CORB/RIRB interrupt gets broken,
> > > > the driver first switches to poling mode, then single_cmd mode as
> > > > fallback.
> > > >
> > > > Also, try disable_msi=1 option for mm1. MSI seems broken on some
> > > > systems.
> > >
> > > is that "pci=nomsi" ?
> >
> > No, snd-hda-intel driver has a new module option "disable_msi" to
> > disable MSI support on that driver. As default, it's off, i.e. MSI is
> > enabled if available. (Well, I feel it's better to rename it
> > enable_msi and set on as default...)
> >
> > Sorry for unclear text.
>
> ugh. We shouldn't have drivers with such options IMO.
> I have seen/used MSI for ethernet, SATA, and audio.
Heh, you're a lucky guy :)
> It either works for all of them or none of them AFAIK.
>
> Why do you think that it should not just be a global system option/flag?
In the ealier version, we didn't call pci_enable_msi() in the driver
while the newer version does unless you pass disable_msi=1 option.
Thus, this option means to behave like the old driver. This makes
much easier to find out a regression than a global boot option
affecting all subsytems.
Takashi
On Tue, 26 Sep 2006 12:16:33 +0200
Takashi Iwai <[email protected]> wrote:
> You must see difference with mm1 (suppose that mm1 already includes
> the latest ALSA patches).
No, the alsa tree was accidentally omitted from 2.6.18-mm1, sorry.
At Tue, 26 Sep 2006 09:31:42 -0700,
Andrew Morton wrote:
>
> On Tue, 26 Sep 2006 12:16:33 +0200
> Takashi Iwai <[email protected]> wrote:
>
> > You must see difference with mm1 (suppose that mm1 already includes
> > the latest ALSA patches).
>
> No, the alsa tree was accidentally omitted from 2.6.18-mm1, sorry.
Ah, that makes sense. Thanks for notice.
Takashi
Takashi Iwai wrote:
> You must see difference with mm1 (suppose that mm1 already includes
> the latest ALSA patches). When the CORB/RIRB interrupt gets broken,
> the driver first switches to poling mode, then single_cmd mode as
> fallback.
>
I tried -mm2, and I'm seeing the same problem.
> Also, try disable_msi=1 option for mm1. MSI seems broken on some
> systems.
>
This made no difference.
J
At Sat, 30 Sep 2006 23:03:08 -0700,
Jeremy Fitzhardinge wrote:
>
> Takashi Iwai wrote:
> > You must see difference with mm1 (suppose that mm1 already includes
> > the latest ALSA patches). When the CORB/RIRB interrupt gets broken,
> > the driver first switches to poling mode, then single_cmd mode as
> > fallback.
> >
>
> I tried -mm2, and I'm seeing the same problem.
At least, you have to see a different kernel message after the
patch... Could you confirm it?
Takashi
On Mon, Sep 25, 2006 at 12:58:08PM -0700, Jeremy Fitzhardinge wrote:
> I have a ThinkPad X60 which uses the Intel 82801G HDA audio chip. This
> used to work for me, but lately (sometime during 2.6.18-rcX series) it
> stopped working - programs trying to use it tend to just block forever
> waiting for /dev/dsp.
>
> The only obvious symptom is:
>
> hda_intel: azx_get_response timeout, switching to single_cmd mode...
>
> appearing in the kernel log when booting.
Just a blind shot -- do you have modem enabled in BIOS? Sometimes
disabling (hiding) modem breaks sound.
--
Tomasz Torcz To co nierealne -- tutaj jest normalne.
[email protected] Ziomale na ?ycie maj? tu patenty specjalne.
Tomasz Torcz wrote:
> Just a blind shot -- do you have modem enabled in BIOS? Sometimes
> disabling (hiding) modem breaks sound.
>
Good suggestion. It might be disabled; I'll switch it around next time
I reboot.
J
Takashi Iwai wrote:
> At least, you have to see a different kernel message after the
> patch... Could you confirm it?
>
No, it looks like the same message as ever:
hda_intel: azx_get_response timeout, switching to polling mode...
hda_intel: azx_get_response timeout, switching to single_cmd mode...
This is with -mm3.
J
At Wed, 04 Oct 2006 08:16:17 -0700,
Jeremy Fitzhardinge wrote:
>
> Takashi Iwai wrote:
> > At least, you have to see a different kernel message after the
> > patch... Could you confirm it?
> >
>
> No, it looks like the same message as ever:
>
> hda_intel: azx_get_response timeout, switching to polling mode...
This is a new message. There was no poling mode on 2.6.18.
> hda_intel: azx_get_response timeout, switching to single_cmd mode...
So, this looks like that the CORB/RIRB register mapping is actually
broken...
Takashi
At Wed, 04 Oct 2006 08:16:17 -0700,
Jeremy Fitzhardinge wrote:
>
> Takashi Iwai wrote:
> > At least, you have to see a different kernel message after the
> > patch... Could you confirm it?
> >
>
> No, it looks like the same message as ever:
>
> hda_intel: azx_get_response timeout, switching to polling mode...
> hda_intel: azx_get_response timeout, switching to single_cmd mode...
A counter of RIRB pending commands could overflow the size of RIRB
when a bunch of commands are sent but not synced. This may lead to
the azx_get_response error, theoretically.
Could you apply the patch below and check what values are shown there?
thanks,
Takashi
diff -r 4963791e6192 sound/pci/hda/hda_intel.c
--- a/sound/pci/hda/hda_intel.c Wed Oct 04 18:38:16 2006 +0200
+++ b/sound/pci/hda/hda_intel.c Wed Oct 04 20:59:57 2006 +0200
@@ -325,6 +325,7 @@ struct azx {
/* CORB/RIRB */
struct azx_rb corb;
struct azx_rb rirb;
+ int max_rirb_cmds;
/* BDL, CORB/RIRB and position buffers */
struct snd_dma_buffer bdl;
@@ -480,6 +481,8 @@ static int azx_corb_send_cmd(struct hda_
spin_lock_irq(&chip->reg_lock);
chip->rirb.cmds++;
+ if (chip->rirb.cmds > chip->max_rirb_cmds)
+ chip->max_rirb_cmds = chip->rirb.cmds;
chip->corb.buf[wp] = cpu_to_le32(val);
azx_writel(chip, CORBWP, wp);
spin_unlock_irq(&chip->reg_lock);
@@ -538,12 +541,16 @@ static unsigned int azx_rirb_get_respons
if (!chip->polling_mode) {
snd_printk(KERN_WARNING "hda_intel: azx_get_response timeout, "
"switching to polling mode...\n");
+ snd_printk(KERN_WARNING " RIRB pending = %d, peak = %d\n",
+ chip->rirb.cmds, chip->max_rirb_cmds);
chip->polling_mode = 1;
goto again;
}
snd_printk(KERN_ERR "hda_intel: azx_get_response timeout, "
"switching to single_cmd mode...\n");
+ snd_printk(KERN_ERR " RIRB pending = %d, peak = %d\n",
+ chip->rirb.cmds, chip->max_rirb_cmds);
chip->rirb.rp = azx_readb(chip, RIRBWP);
chip->rirb.cmds = 0;
/* switch to single_cmd mode */
Takashi Iwai wrote:
> A counter of RIRB pending commands could overflow the size of RIRB
> when a bunch of commands are sent but not synced. This may lead to
> the azx_get_response error, theoretically.
>
> Could you apply the patch below and check what values are shown there?
>
I'll try it, but I re-enabled the modem in the bios, and I no longer get
this message and it appears to work (there seems to be a secondary
problem that the volume hotkeys have stopped working, but I suspect
that's more ACPI-related).
J
At Wed, 04 Oct 2006 13:07:56 -0700,
Jeremy Fitzhardinge wrote:
>
> Takashi Iwai wrote:
> > A counter of RIRB pending commands could overflow the size of RIRB
> > when a bunch of commands are sent but not synced. This may lead to
> > the azx_get_response error, theoretically.
> >
> > Could you apply the patch below and check what values are shown there?
> >
> I'll try it, but I re-enabled the modem in the bios, and I no longer get
> this message and it appears to work (there seems to be a secondary
> problem that the volume hotkeys have stopped working, but I suspect
> that's more ACPI-related).
Ah, that's good to hear.
Is the modem also HD-audio modem? If so, you have two codec#* files
in /proc/asound/card0.
Takashi