lkml.org 
[lkml]   [2005]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)
    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
    [<f88e8f0c>] __sata_phy_reset+0x75/0x12e [libata]
    [<f883f62f>] mv_phy_reset+0xbf/0x11e [sata_mv]
    [<c0250f16>] end_that_request_last+0x6c/0x7e
    [<f883f3bf>] mv_host_intr+0xd6/0x142 [sata_mv]
    [<f883f500>] mv_interrupt+0xd5/0x145 [sata_mv]
    [<c0107e2b>] handle_IRQ_event+0x25/0x4f
    [<c01087d3>] do_IRQ+0x18a/0x2bf
    =======================
    [<c030fb7c>] common_interrupt+0x18/0x20
    [<f883f618>] mv_phy_reset+0xa8/0x11e [sata_mv]
    [<c01091d8>] setup_irq+0x179/0x181
    [<f883f42b>] mv_interrupt+0x0/0x145 [sata_mv]
    [<f88e8e25>] ata_bus_probe+0xe/0x7b [libata]
    [<f88eb34d>] ata_device_add+0x186/0x202 [libata]
    [<f883f97a>] mv_init_one+0x197/0x1d5 [sata_mv]
    [<c01ec15d>] pci_device_probe_static+0x2a/0x3d
    [<c01ec18b>] __pci_device_probe+0x1b/0x2c
    [<c01ec1b7>] pci_device_probe+0x1b/0x2d
    [<c024a33b>] bus_match+0x27/0x45
    [<c024a404>] driver_attach+0x37/0x66
    [<c024a7b9>] bus_add_driver+0x77/0x97
    [<c024abd4>] driver_register+0x51/0x58
    [<c01ec375>] pci_register_driver+0x85/0xa1
    [<f881a00a>] mv_init+0xa/0x15 [sata_mv]
    [<c013d5a3>] sys_init_module+0x1f1/0x2d9
    [<c030fa37>] syscall_call+0x7/0xb
    bad: scheduling while atomic!
    [<c030d515>] schedule+0x2d/0x552
    [<c0107e2b>] handle_IRQ_event+0x25/0x4f
    [<c030e40e>] schedule_timeout+0xf1/0x10c
    [<c012ad7e>] process_timeout+0x0/0x5
    [<f883f082>] mv_scr_read+0xf/0x54 [sata_mv]
    [<c012b498>] msleep+0x4e/0x54
    [<f88e8f3f>] __sata_phy_reset+0xa8/0x12e [libata]
    [<f883f62f>] mv_phy_reset+0xbf/0x11e [sata_mv]
    [<c0250f16>] end_that_request_last+0x6c/0x7e
    [<f883f3bf>] mv_host_intr+0xd6/0x142 [sata_mv]
    [<f883f500>] mv_interrupt+0xd5/0x145 [sata_mv]
    [<c0107e2b>] handle_IRQ_event+0x25/0x4f
    [<c01087d3>] do_IRQ+0x18a/0x2bf
    =======================
    [<c030fb7c>] common_interrupt+0x18/0x20
    [<f883f618>] mv_phy_reset+0xa8/0x11e [sata_mv]
    [<c01091d8>] setup_irq+0x179/0x181
    [<f883f42b>] mv_interrupt+0x0/0x145 [sata_mv]
    [<f88e8e25>] ata_bus_probe+0xe/0x7b [libata]
    [<f88eb34d>] ata_device_add+0x186/0x202 [libata]
    [<f883f97a>] mv_init_one+0x197/0x1d5 [sata_mv]
    [<c01ec15d>] pci_device_probe_static+0x2a/0x3d
    [<c01ec18b>] __pci_device_probe+0x1b/0x2c
    [<c01ec1b7>] pci_device_probe+0x1b/0x2d
    [<c024a33b>] bus_match+0x27/0x45
    [<c024a404>] driver_attach+0x37/0x66
    [<c024a7b9>] bus_add_driver+0x77/0x97
    [<c024abd4>] driver_register+0x51/0x58
    [<c01ec375>] pci_register_driver+0x85/0xa1
    [<f881a00a>] mv_init+0xa/0x15 [sata_mv]
    [<c013d5a3>] sys_init_module+0x1f1/0x2d9
    [<c030fa37>] syscall_call+0x7/0xb



    Stack 2: (from off list email)


    scheduling while atomic: klogd/0x00010000/1572
    [<c0343524>] schedule+0xab4/0xbf0
    [<c01200bf>] scheduler_tick+0x15f/0x380
    [<c012dbe0>] lock_timer_base+0x20/0x50
    [<c012dcb8>] __mod_timer+0xa8/0xd0
    [<c0343eee>] schedule_timeout+0x4e/0xc0
    [<c012e790>] process_timeout+0x0/0x10
    [<c012ebb0>] msleep+0x30/0x40
    [<f89d914a>] __sata_phy_reset+0x4a/0x120 [libata]
    [<c0114b72>] delay_pmtmr+0x12/0x20
    [<f899051a>] mv_phy_reset+0x7a/0x140 [sata_mv]
    [<c02857f2>] ide_end_request+0x92/0xb0
    [<f899035e>] mv_host_intr+0xce/0x120 [sata_mv]
    [<f8990457>] mv_interrupt+0xa7/0xf0 [sata_mv]
    [<c0149fe3>] handle_IRQ_event+0x33/0x70
    [<c014a0f9>] __do_IRQ+0xd9/0x150
    [<c0106847>] do_IRQ+0x57/0xa0
    =======================
    [<c0104c4a>] common_interrupt+0x1a/0x20
    [<c013007b>] __group_send_sig_info+0x2b/0xd0
    [<c01247f8>] do_syslog+0xe8/0x3e0
    [<c0104cd8>] apic_timer_interrupt+0x1c/0x24
    [<c013a0c0>] autoremove_wake_function+0x0/0x50
    [<c013a0c0>] autoremove_wake_function+0x0/0x50
    [<c01a8090>] kmsg_read+0x0/0x50
    [<c016c368>] vfs_read+0xb8/0x170
    [<c016c701>] sys_read+0x41/0x70
    [<c01041bb>] 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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-09-07 16:44    [W:5.548 / U:0.720 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site