From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brett Russ Subject: Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode) Date: Wed, 07 Sep 2005 10:40:16 -0400 Message-ID: <431EFBD0.1040509@emc.com> References: <20050830183625.BEE1520F4C@lns1058.lss.emc.com> <4314C604.4030208@pobox.com> <20050901142754.B93BF27137@lns1058.lss.emc.com> <20050901144038.GA25830@infradead.org> <20050901222617.2455520F96@lns1058.lss.emc.com> <431E8104.2090100@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailhub.lss.emc.com ([168.159.2.31]:11706 "EHLO mailhub.lss.emc.com") by vger.kernel.org with ESMTP id S1751211AbVIGOki (ORCPT ); Wed, 7 Sep 2005 10:40:38 -0400 In-Reply-To: <431E8104.2090100@pobox.com> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Jeff Garzik Cc: linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org, hch@infradead.org Jeff Garzik wrote: > applied > There are some issues with this. One of which I fixed and the other is a bit confusing. The one I fixed concerned the 5xxx chips not supporting the master reset functionality. The other problem has been reported by 2 people so far. I have a stack trace from each of them: Stack 1: (from http://article.gmane.org/gmane.linux.ide/5280) PCI: Found IRQ 5 for device 0000:02:08.0 PCI: Sharing IRQ 5 with 0000:00:1d.0 IRQ routing conflict for 0000:02:08.0, have irq 9, want irq 5 ata1: SATA max PIO4 cmd 0x0 ctl 0xF8A22120 bmdma 0x0 irq 9 ata2: SATA max PIO4 cmd 0x0 ctl 0xF8A24120 bmdma 0x0 irq 9 ata3: SATA max PIO4 cmd 0x0 ctl 0xF8A26120 bmdma 0x0 irq 9 ata4: SATA max PIO4 cmd 0x0 ctl 0xF8A28120 bmdma 0x0 irq 9 Badness in __sata_phy_reset at drivers/scsi/libata-core.c:1413 [] __sata_phy_reset+0x75/0x12e [libata] [] mv_phy_reset+0xbf/0x11e [sata_mv] [] end_that_request_last+0x6c/0x7e [] mv_host_intr+0xd6/0x142 [sata_mv] [] mv_interrupt+0xd5/0x145 [sata_mv] [] handle_IRQ_event+0x25/0x4f [] do_IRQ+0x18a/0x2bf ======================= [] common_interrupt+0x18/0x20 [] mv_phy_reset+0xa8/0x11e [sata_mv] [] setup_irq+0x179/0x181 [] mv_interrupt+0x0/0x145 [sata_mv] [] ata_bus_probe+0xe/0x7b [libata] [] ata_device_add+0x186/0x202 [libata] [] mv_init_one+0x197/0x1d5 [sata_mv] [] pci_device_probe_static+0x2a/0x3d [] __pci_device_probe+0x1b/0x2c [] pci_device_probe+0x1b/0x2d [] bus_match+0x27/0x45 [] driver_attach+0x37/0x66 [] bus_add_driver+0x77/0x97 [] driver_register+0x51/0x58 [] pci_register_driver+0x85/0xa1 [] mv_init+0xa/0x15 [sata_mv] [] sys_init_module+0x1f1/0x2d9 [] syscall_call+0x7/0xb bad: scheduling while atomic! [] schedule+0x2d/0x552 [] handle_IRQ_event+0x25/0x4f [] schedule_timeout+0xf1/0x10c [] process_timeout+0x0/0x5 [] mv_scr_read+0xf/0x54 [sata_mv] [] msleep+0x4e/0x54 [] __sata_phy_reset+0xa8/0x12e [libata] [] mv_phy_reset+0xbf/0x11e [sata_mv] [] end_that_request_last+0x6c/0x7e [] mv_host_intr+0xd6/0x142 [sata_mv] [] mv_interrupt+0xd5/0x145 [sata_mv] [] handle_IRQ_event+0x25/0x4f [] do_IRQ+0x18a/0x2bf ======================= [] common_interrupt+0x18/0x20 [] mv_phy_reset+0xa8/0x11e [sata_mv] [] setup_irq+0x179/0x181 [] mv_interrupt+0x0/0x145 [sata_mv] [] ata_bus_probe+0xe/0x7b [libata] [] ata_device_add+0x186/0x202 [libata] [] mv_init_one+0x197/0x1d5 [sata_mv] [] pci_device_probe_static+0x2a/0x3d [] __pci_device_probe+0x1b/0x2c [] pci_device_probe+0x1b/0x2d [] bus_match+0x27/0x45 [] driver_attach+0x37/0x66 [] bus_add_driver+0x77/0x97 [] driver_register+0x51/0x58 [] pci_register_driver+0x85/0xa1 [] mv_init+0xa/0x15 [sata_mv] [] sys_init_module+0x1f1/0x2d9 [] syscall_call+0x7/0xb Stack 2: (from off list email) scheduling while atomic: klogd/0x00010000/1572 [] schedule+0xab4/0xbf0 [] scheduler_tick+0x15f/0x380 [] lock_timer_base+0x20/0x50 [] __mod_timer+0xa8/0xd0 [] schedule_timeout+0x4e/0xc0 [] process_timeout+0x0/0x10 [] msleep+0x30/0x40 [] __sata_phy_reset+0x4a/0x120 [libata] [] delay_pmtmr+0x12/0x20 [] mv_phy_reset+0x7a/0x140 [sata_mv] [] ide_end_request+0x92/0xb0 [] mv_host_intr+0xce/0x120 [sata_mv] [] mv_interrupt+0xa7/0xf0 [sata_mv] [] handle_IRQ_event+0x33/0x70 [] __do_IRQ+0xd9/0x150 [] do_IRQ+0x57/0xa0 ======================= [] common_interrupt+0x1a/0x20 [] __group_send_sig_info+0x2b/0xd0 [] do_syslog+0xe8/0x3e0 [] apic_timer_interrupt+0x1c/0x24 [] autoremove_wake_function+0x0/0x50 [] autoremove_wake_function+0x0/0x50 [] kmsg_read+0x0/0x50 [] vfs_read+0xb8/0x170 [] sys_read+0x41/0x70 [] sysenter_past_esp+0x54/0x75 So it looks like mv_phy_reset() is getting called from interrupt level, and it calls __sata_phy_reset() which sleeps. I only call mv_phy_reset() as part of fatal error interrupt cleanup. The chip does take an "error" interrupt upon drive connection but that's not fatal. Either way, mv_phy_reset() is called from mv_err_intr() which doesn't appear in either of the stack dumps above. Possible solutions: -change __sata_phy_reset() to do a mdelay rather than msleep? -do the phy_reset part of error recovery after returning from interrupt handler? Thoughts? BR