From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932903AbXCTNW2 (ORCPT ); Tue, 20 Mar 2007 09:22:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932810AbXCTNW1 (ORCPT ); Tue, 20 Mar 2007 09:22:27 -0400 Received: from gprs189-60.eurotel.cz ([160.218.189.60]:37387 "EHLO amd.ucw.cz" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932796AbXCTNW0 (ORCPT ); Tue, 20 Mar 2007 09:22:26 -0400 Date: Tue, 20 Mar 2007 14:22:03 +0100 From: Pavel Machek To: Takashi Iwai Cc: kernel list , Ingo Molnar Subject: Re: BUG: soft lockup during suspend Message-ID: <20070320132202.GA5089@elf.ucw.cz> References: <20070320123253.GB19019@elf.ucw.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.11+cvs20060126 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi! > > I got this nastinness in my syslog... perhaps HDA intel takes too long > > to play with its hardware? Or should we just kill the softlockup > > watchdog since Linux is not realtime system, yet? > > X60/T60 is known to be often broken regarding the communication > between the controller and the codec chip. When this kind of thing > happens, the driver tries to switch to a single-shot I/O without using > ring-buffers and IRQs, and even in such a mode, the communication gets > broken. FWIW, it doesn't happen on other machines with HD-audio, so > it's fairly specific to X60/T60. No idea why. Is adding touch_softlockup_watchdog() to hd_audio right solution? Or should watchdog just disappear? Pavel > > HDA Intel 0000:00:1b.0: freeze > > BUG: soft lockup detected on CPU#0! > > [] softlockup_tick+0xa9/0xd0 > > [] update_process_times+0x33/0x80 > > [] tick_periodic+0x22/0x70 > > [] tick_handle_periodic+0x17/0x80 > > [] tick_do_broadcast+0x6a/0x80 > > [] tick_do_periodic_broadcast+0x1c/0x30 > > [] tick_handle_periodic_broadcast+0x1b/0x60 > > [] tick_do_periodic_broadcast+0x1c/0x30 > > [] timer_interrupt+0x2c/0x40 > > [] handle_IRQ_event+0x25/0x60 > > [] handle_edge_irq+0xe7/0x130 > > [] do_IRQ+0x3b/0x80 > > [] do_IRQ+0x40/0x80 > > [] common_interrupt+0x23/0x28 > > [] ieee80211_wx_get_scan+0x2b/0x130 > > [] delay_tsc+0x14/0x20 > > [] __delay+0x6/0x10 > > [] azx_send_cmd+0xfa/0x110 > > [] snd_hda_codec_write+0x3e/0x60 > > [] hda_set_power_state+0xab/0xe0 > > [] snd_hda_suspend+0x48/0x60 > > [] azx_suspend+0x52/0xd0 > > [] pci_device_suspend+0x23/0x70 > > [] suspend_device+0x11b/0x2e0 > > [] device_suspend+0xb2/0x170 > > [] printk+0x1b/0x20 > > [] pm_suspend_disk+0x4d/0x2b0 > > [] enter_state+0x195/0x220 > > [] state_store+0xa9/0xc0 > > [] state_store+0x0/0xc0 > > [] subsys_attr_store+0x29/0x40 > > [] sysfs_write_file+0xac/0x130 > > [] vfs_write+0xa6/0x140 > > [] sysfs_write_file+0x0/0x130 > > [] syscall_call+0x7/0xb > > [] ieee80211_translate_scan+0xa00/0xa50 > > ======================= > > ACPI: PCI interrupt for device 0000:00:1b.0 disabled > > > > -- > > (english) http://www.livejournal.com/~pavelmachek > > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > > -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html