Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Brett Russ <russb@emc.com>]

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/