* sata_mv: module reloading doesn't work
@ 2006-04-02 15:56 Dan Aloni
2006-04-02 16:05 ` Mark Lord
2006-04-02 17:59 ` Eric D. Mudama
0 siblings, 2 replies; 11+ messages in thread
From: Dan Aloni @ 2006-04-02 15:56 UTC (permalink / raw)
To: Linux Kernel List; +Cc: Jeff Garzik, Mark Lord, IDE/ATA development list
Hello,
I'm testing the sata_mv driver to see whether reloading (rmmod
- insmod) works, and it seems something is broken there. The
first insmod goes okay - however all the insmods that follow
emit error=0x01 { AddrMarkNotFound } and status=0x50 { DriveReady
SeekComplete } from all the drives.
I've enabled DPRINTK and fixed a crash involved with register
dumping (posted in my previous mail).
I hope these messages are sufficient, I can provide more
information if needed.
Apr 2 15:22:16 14.10.240.6 kernel: sata_mv 0000:06:01.0: 32 slots 8 ports SCSI mode IRQ via INTx
Apr 2 15:22:16 14.10.240.6 kernel: ata17: SATA max UDMA/133 cmd 0x0 ctl 0xFFFFC20010922120 bmdma 0x0 irq 21
Apr 2 15:22:16 14.10.240.6 kernel: ata18: SATA max UDMA/133 cmd 0x0 ctl 0xFFFFC20010924120 bmdma 0x0 irq 21
Apr 2 15:22:16 14.10.240.6 kernel: ata19: SATA max UDMA/133 cmd 0x0 ctl 0xFFFFC20010926120 bmdma 0x0 irq 21
Apr 2 15:22:16 14.10.240.6 kernel: ata20: SATA max UDMA/133 cmd 0x0 ctl 0xFFFFC20010928120 bmdma 0x0 irq 21
Apr 2 15:22:16 14.10.240.6 kernel: ata21: SATA max UDMA/133 cmd 0x0 ctl 0xFFFFC20010932120 bmdma 0x0 irq 21
Apr 2 15:22:16 14.10.240.6 kernel: ata22: SATA max UDMA/133 cmd 0x0 ctl 0xFFFFC20010934120 bmdma 0x0 irq 21
Apr 2 15:22:16 14.10.240.6 kernel: ata23: SATA max UDMA/133 cmd 0x0 ctl 0xFFFFC20010936120 bmdma 0x0 irq 21
Apr 2 15:22:16 14.10.240.6 kernel: ata24: SATA max UDMA/133 cmd 0x0 ctl 0xFFFFC20010938120 bmdma 0x0 irq 21
...
Apr 2 15:22:18 14.10.240.6 kernel: ata18: dev 0 ATA-7, max UDMA/133, 976773168 sectors: LBA48
Apr 2 15:22:18 14.10.240.6 kernel: ata18: dev 0 configured for UDMA/133
Apr 2 15:22:18 14.10.240.6 kernel: scsi1 : sata_mv
Apr 2 15:22:18 14.10.240.6 kernel: S-regs after ATA_RST: SStat 0x00000104 SErr 0x04000000 SCtrl 0x00000004
Apr 2 15:22:18 14.10.240.6 kernel: S-regs after PHY wake: SStat 0x00000123 SErr 0x04190002 SCtrl 0x00000300
Apr 2 15:22:18 14.10.240.6 kernel: S-regs after PHY wake: SStat 0x00000123 SErr 0x04190002 SCtrl 0x00000300
Apr 2 15:22:18 14.10.240.6 kernel: S-regs after ATA_RST: SStat 0x00000104 SErr 0x04000000 SCtrl 0x00000004
Apr 2 15:22:18 14.10.240.6 kernel: S-regs after PHY wake: SStat 0x00000123 SErr 0x04190002 SCtrl 0x00000300
Apr 2 15:22:18 14.10.240.6 kernel: S-regs after ATA_RST: SStat 0x00000104 SErr 0x04000000 SCtrl 0x00000004
Apr 2 15:22:18 14.10.240.6 kernel: S-regs after PHY wake: SStat 0x00000123 SErr 0x04190002 SCtrl 0x00000300
Apr 2 15:22:18 14.10.240.6 kernel: S-regs after ATA_RST: SStat 0x00000104 SErr 0x04000000 SCtrl 0x00000004
Apr 2 15:22:18 14.10.240.6 kernel: S-regs after PHY wake: SStat 0x00000123 SErr 0x04190002 SCtrl 0x00000300
Apr 2 15:22:19 14.10.240.6 kernel: S-regs after ATA_RST: SStat 0x00000104 SErr 0x04000000 SCtrl 0x00000004
Apr 2 15:22:19 14.10.240.6 kernel: S-regs after PHY wake: SStat 0x00000123 SErr 0x04190002 SCtrl 0x00000300
Apr 2 15:22:19 14.10.240.6 kernel: S-regs after ATA_RST: SStat 0x00000104 SErr 0x04000000 SCtrl 0x00000004
Apr 2 15:22:19 14.10.240.6 kernel: S-regs after PHY wake: SStat 0x00000123 SErr 0x04190002 SCtrl 0x00000300
Apr 2 15:22:19 14.10.240.6 kernel: S-regs after PHY wake: SStat 0x00000123 SErr 0x00000000 SCtrl 0x00000300
...
Apr 2 15:22:22 14.10.240.6 kernel: sdb:<3>ata18: port error; EDMA err cause: 0x00000280 SERR: 0x00000000
Apr 2 15:22:22 14.10.240.6 kernel: S-regs after ATA_RST: SStat 0x00000104 SErr 0x04000000 SCtrl 0x00000004
Apr 2 15:22:22 14.10.240.6 kernel: S-regs after PHY wake: SStat 0x00000123 SErr 0x04190002 SCtrl 0x00000300
Apr 2 15:22:22 14.10.240.6 kernel: ata18: status=0x50 { DriveReady SeekComplete }
Apr 2 15:22:22 14.10.240.6 kernel: ata18: error=0x01 { AddrMarkNotFound }
Apr 2 15:22:22 14.10.240.6 kernel: All regs @ PCI error
Apr 2 15:22:22 14.10.240.6 kernel: All registers for port(s) 0-7:
Apr 2 15:22:22 14.10.240.6 kernel: PCI config space regs:
Apr 2 15:22:22 14.10.240.6 kernel: 00: 608111ab 02b80313 01000009 00002008
Apr 2 15:22:22 14.10.240.6 kernel: 10: dc800004 00000000 00003001 00000000
Apr 2 15:22:22 14.10.240.6 kernel: 20: 00000000 00000000 00000000 11ab11ab
Apr 2 15:22:22 14.10.240.6 kernel: 30: 00000000 00000040 00000000 00000105
Apr 2 15:22:22 14.10.240.6 kernel: 40: 00025001 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: 50: 00806005 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: 60: 00300007 01830608
Apr 2 15:22:22 14.10.240.6 kernel: PCI regs:
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010900c00: 0107e371 00000000 0038001e 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010900c10: 00000000 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010900c20: 00000000 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010900c30: 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010900d00: 00000034 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010900d10: 00000000 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010900d20: 00000000 00000000 00000000 00380000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010900d30: 00000008
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010900f00: 000104f0
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010901d00: 00000000 000100ff 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010901d10: 00000000 00000000 00000000 03e500ff
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010901d20: 00070c41 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010901d30: 00000000 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010901d40: dc801d40 00000000 45003000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010901d50: 00000006 00000000 00000400 00557fee
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010901d60: 00040004 0087ffff 00000000
Apr 2 15:22:22 14.10.240.6 kernel: HC regs (HC 0): 10900000 10920000:
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010920000: 000100ff 00000101 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010920010: 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: HC regs (HC 1): 10900000 10930000:
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010930000: 000100ff 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010930010: 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: EDMA regs (port 0):
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010922000: 00002900 0000000e 00000000 ffffffff
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010922010: 00000000 6ae76020 00000020 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010922020: 00000000 6ae76400 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010922030: 003f003f 000000bc 00032190 00000080
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010922040: 00000000 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010922050: 009b70e4
Apr 2 15:22:22 14.10.240.6 kernel: SATA regs (port 0):
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010922300: 00000123 00000000 00000300 000301b0
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010922310: aaaac02a 00186005 4dd3783c 00067bef
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010922320: 00000000 00000000 00000000 40556a88
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010922330: 1c75972f 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010922340: 00000000 00000000 00000000 00404034
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010922350: 00000000 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: EDMA regs (port 1):
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010924000: 00002900 0000000e 00000020 ffffffff
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010924010: 00000000 6a8f3020 00000020 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010924020: 00000000 6a8f3400 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010924030: 003f003f 000000bc 00032190 00000080
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010924040: 00000000 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010924050: 009b70e4
Apr 2 15:22:22 14.10.240.6 kernel: SATA regs (port 1):
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010924300: 00000123 04190002 00000300 000301b0
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010924310: aaaac02a 00186005 4dd3783c 00067bef
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010924320: 00000000 00000000 00000000 40556a80
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010924330: 1c75972f 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010924340: 00000000 00000000 00000000 00404034
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010924350: 00000000 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: EDMA regs (port 2):
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010926000: 00002900 00000000 00000000 ffffffff
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010926010: 00000000 7be61000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010926020: 00000000 7be61400 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010926030: 00000000 000000bc 00032190 00000080
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010926040: 00000000 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010926050: 009b70e4
Apr 2 15:22:22 14.10.240.6 kernel: SATA regs (port 2):
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010926300: 00000123 00000000 00000300 000301b0
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010926310: aaaac02a 00186005 4dd3783c 00067bef
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010926320: 00000000 00000000 00000000 40556a88
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010926330: 1c75972f 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010926340: 00000000 00000000 00000000 00404046
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010926350: 00000000 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: EDMA regs (port 3):
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010928000: 00002900 00000000 00000000 ffffffff
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010928010: 00000000 7aa31000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010928020: 00000000 7aa31400 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010928030: 00000000 000000bc 00032190 00000080
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010928040: 00000000 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010928050: 009b70e4
Apr 2 15:22:22 14.10.240.6 kernel: SATA regs (port 3):
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010928300: 00000123 00000000 00000300 000301b0
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010928310: aaaac02a 00186005 4dd3783c 00067bef
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010928320: 00000000 00000000 00000000 40556a88
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010928330: 1c75972f 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010928340: 00000000 00000000 00000000 00404046
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010928350: 00000000 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: EDMA regs (port 4):
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010932000: 00002900 00000000 00000000 ffffffff
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010932010: 00000000 6b05d000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010932020: 00000000 6b05d400 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010932030: 00000000 000000bc 00032190 00000080
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010932040: 00000000 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010932050: 009b70e4
Apr 2 15:22:22 14.10.240.6 kernel: SATA regs (port 4):
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010932300: 00000123 00000000 00000300 000301b0
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010932310: aaaac02a 00186005 4dd3783c 00067bef
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010932320: 00000000 00000000 00000000 40556a88
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010932330: 1c75972f 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010932340: 00000000 00000000 00000000 00404046
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010932350: 00000000 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: EDMA regs (port 5):
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010934000: 00002900 00000000 00000000 ffffffff
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010934010: 00000000 6b11b000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010934020: 00000000 6b11b400 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010934030: 00000000 000000bc 00032190 00000080
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010934040: 00000000 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010934050: 009b70e4
Apr 2 15:22:22 14.10.240.6 kernel: SATA regs (port 5):
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010934300: 00000123 00000000 00000300 000301b0
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010934310: aaaac02a 00186005 4dd3783c 00067bef
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010934320: 00000000 00000000 00000000 40556a88
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010934330: 1c75972f 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010934340: 00000000 00000000 00000000 00404046
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010934350: 00000000 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: EDMA regs (port 6):
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010936000: 00002900 00000000 00000000 ffffffff
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010936010: 00000000 6af33000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010936020: 00000000 6af33400 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010936030: 00000000 000000bc 00032190 00000080
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010936040: 00000000 00000000 00000000 00000000
Apr 2 15:22:22 14.10.240.6 kernel: ffffc20010936050: 009b70e4
Apr 2 15:22:22 14.10.240.6 kernel: SATA regs (port 6):
Apr 2 15:22:23 14.10.240.6 kernel: ffffc20010936300: 00000000 00000000 00000300 000301b0
Apr 2 15:22:23 14.10.240.6 kernel: ffffc20010936310: aaaac02a 00186005 4dd3783c 00067bef
Apr 2 15:22:23 14.10.240.6 kernel: ffffc20010936320: 00000000 00000000 00000000 40556a88
Apr 2 15:22:23 14.10.240.6 kernel: ffffc20010936330: 1c75972f 00000000 00000000 00000000
Apr 2 15:22:23 14.10.240.6 kernel: ffffc20010936340: 00000000 00000000 00000000 00804000
Apr 2 15:22:23 14.10.240.6 kernel: ffffc20010936350: 00000000 00000000 00000000 00000000
Apr 2 15:22:23 14.10.240.6 kernel: EDMA regs (port 7):
Apr 2 15:22:23 14.10.240.6 kernel: ffffc20010938000: 00002900 00000000 00000000 ffffffff
Apr 2 15:22:23 14.10.240.6 kernel: ffffc20010938010: 00000000 6b91c000 00000000 00000000
Apr 2 15:22:23 14.10.240.6 kernel: ffffc20010938020: 00000000 6b91c400 00000000 00000000
[kernel buffer filled at this point]
--
Dan Aloni, Linux specialist
XIV LTD, http://www.xivstorage.com
da-x@monatomic.org, da-x@colinux.org, da-x@gmx.net, dan@xiv.co.il
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sata_mv: module reloading doesn't work
2006-04-02 15:56 sata_mv: module reloading doesn't work Dan Aloni
@ 2006-04-02 16:05 ` Mark Lord
2006-04-02 16:14 ` Dan Aloni
2006-04-02 17:59 ` Eric D. Mudama
1 sibling, 1 reply; 11+ messages in thread
From: Mark Lord @ 2006-04-02 16:05 UTC (permalink / raw)
To: Dan Aloni; +Cc: Linux Kernel List, Jeff Garzik, IDE/ATA development list
Dan Aloni wrote:
> Hello,
>
> I'm testing the sata_mv driver to see whether reloading (rmmod
> - insmod) works, and it seems something is broken there. The
> first insmod goes okay - however all the insmods that follow
> emit error=0x01 { AddrMarkNotFound } and status=0x50 { DriveReady
> SeekComplete } from all the drives.
>
> I've enabled DPRINTK and fixed a crash involved with register
> dumping (posted in my previous mail).
>
> I hope these messages are sufficient, I can provide more
> information if needed.
What kernel? Any patches applied to sata_mv.c ??
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sata_mv: module reloading doesn't work
2006-04-02 16:05 ` Mark Lord
@ 2006-04-02 16:14 ` Dan Aloni
2006-04-02 16:21 ` Mark Lord
0 siblings, 1 reply; 11+ messages in thread
From: Dan Aloni @ 2006-04-02 16:14 UTC (permalink / raw)
To: Mark Lord; +Cc: Linux Kernel List, Jeff Garzik, IDE/ATA development list
On Sun, Apr 02, 2006 at 12:05:46PM -0400, Mark Lord wrote:
> Dan Aloni wrote:
> >Hello,
> >
> >I'm testing the sata_mv driver to see whether reloading (rmmod
> >- insmod) works, and it seems something is broken there. The
> >first insmod goes okay - however all the insmods that follow
> >emit error=0x01 { AddrMarkNotFound } and status=0x50 { DriveReady
> >SeekComplete } from all the drives.
> >
> >I've enabled DPRINTK and fixed a crash involved with register
> >dumping (posted in my previous mail).
> >
> >I hope these messages are sufficient, I can provide more
> >information if needed.
>
> What kernel? Any patches applied to sata_mv.c ??
>
2.6.16 + ncq branch. sata_mv.c was modified by me - I'll retry
with a cleaner configuration, sorry.
--
Dan Aloni, Linux specialist
XIV LTD, http://www.xivstorage.com
da-x@monatomic.org, da-x@colinux.org, da-x@gmx.net, dan@xiv.co.il
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sata_mv: module reloading doesn't work
2006-04-02 16:14 ` Dan Aloni
@ 2006-04-02 16:21 ` Mark Lord
2006-04-02 19:05 ` Dan Aloni
0 siblings, 1 reply; 11+ messages in thread
From: Mark Lord @ 2006-04-02 16:21 UTC (permalink / raw)
To: Dan Aloni; +Cc: Linux Kernel List, Jeff Garzik, IDE/ATA development list
Dan Aloni wrote:
> On Sun, Apr 02, 2006 at 12:05:46PM -0400, Mark Lord wrote:
>
>> What kernel? Any patches applied to sata_mv.c ??
>
> 2.6.16 + ncq branch. sata_mv.c was modified by me - I'll retry
> with a cleaner configuration, sorry.
The NCQ stuff is *unsafe* with the existing sata_mv.c,
as there are known (to me, at least) bugs that prevent it
from working reliably after the first I/O error of any kind.
The 2.6.16.1 branch is slightly better,
and there is also the "three bug fixes" update
that's in upstream to help things further.
With all of those fixes, the module loads/unloads/reloads fine for me.
If you want to use NCQ more safely, then you'll need to modify
the mv_start_dma() routine to reinitialize the queue pointers
each time, as they can get out of sync after an error.
There are still other bugs to be worked out and fixed, though.
I'll have a patch or two this week for the ones I know about.
Cheers
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sata_mv: module reloading doesn't work
2006-04-02 15:56 sata_mv: module reloading doesn't work Dan Aloni
2006-04-02 16:05 ` Mark Lord
@ 2006-04-02 17:59 ` Eric D. Mudama
2006-04-02 22:44 ` Dan Aloni
2006-04-03 21:57 ` Dan Aloni
1 sibling, 2 replies; 11+ messages in thread
From: Eric D. Mudama @ 2006-04-02 17:59 UTC (permalink / raw)
To: Dan Aloni
Cc: Linux Kernel List, Jeff Garzik, Mark Lord,
IDE/ATA development list
On 4/2/06, Dan Aloni <da-x@monatomic.org> wrote:
> Hello,
>
> I'm testing the sata_mv driver to see whether reloading (rmmod
> - insmod) works, and it seems something is broken there. The
> first insmod goes okay - however all the insmods that follow
> emit error=0x01 { AddrMarkNotFound } and status=0x50 { DriveReady
> SeekComplete } from all the drives.
More to Jeff/Mark etc... wouldn't this be expected? 0x50/0x01 is the
contents of a reset signature FIS. If the module was removed, and
upon insmod the bus came back up, the drive would complete ASR or
COMRESET processing and post a signature FIS. Is the phy disabled
when sata_mv is removed?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sata_mv: module reloading doesn't work
2006-04-02 16:21 ` Mark Lord
@ 2006-04-02 19:05 ` Dan Aloni
0 siblings, 0 replies; 11+ messages in thread
From: Dan Aloni @ 2006-04-02 19:05 UTC (permalink / raw)
To: Mark Lord; +Cc: Linux Kernel List, Jeff Garzik, IDE/ATA development list
On Sun, Apr 02, 2006 at 12:21:34PM -0400, Mark Lord wrote:
> Dan Aloni wrote:
> >On Sun, Apr 02, 2006 at 12:05:46PM -0400, Mark Lord wrote:
> >
> >>What kernel? Any patches applied to sata_mv.c ??
> >
> >2.6.16 + ncq branch. sata_mv.c was modified by me - I'll retry
> >with a cleaner configuration, sorry.
>
> The NCQ stuff is *unsafe* with the existing sata_mv.c,
> as there are known (to me, at least) bugs that prevent it
> from working reliably after the first I/O error of any kind.
Thanks for alerting me about that, I'll take that into consideration.
> The 2.6.16.1 branch is slightly better,
> and there is also the "three bug fixes" update
> that's in upstream to help things further.
>
> With all of those fixes, the module loads/unloads/reloads fine for me.
The fixes you've posted in the last weeks are merged in my tree.
However, I don't think that this particular problem has anything
to do with NCQ. In the last 2 hours I've tested a few different
versions:
* 2.6.16.1 with its sata_mv and the "three bug fixes" update.
* 2.6.16.1 + sata_mv 0.6 from 2.6.16-git back-ported.
* 2.6.16 + ncq + modified sata_mv 0.6 (includes some changes
I've posted before along with your fixes).
All versions show the same problem. The system in question has
two 6081 controllers and 14 disks.
My guess it that sata_mv leaves the controllers in a unclean
state and I'm now looking into this problem to see how it can
be fixed.
> If you want to use NCQ more safely, then you'll need to modify
> the mv_start_dma() routine to reinitialize the queue pointers
> each time, as they can get out of sync after an error.
>
> There are still other bugs to be worked out and fixed, though.
>
> I'll have a patch or two this week for the ones I know about.
I'll look forward to these patches, thanks.
--
Dan Aloni, Linux specialist
XIV LTD, http://www.xivstorage.com
da-x@monatomic.org, da-x@colinux.org, da-x@gmx.net, dan@xiv.co.il
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sata_mv: module reloading doesn't work
2006-04-02 17:59 ` Eric D. Mudama
@ 2006-04-02 22:44 ` Dan Aloni
2006-04-03 21:57 ` Dan Aloni
1 sibling, 0 replies; 11+ messages in thread
From: Dan Aloni @ 2006-04-02 22:44 UTC (permalink / raw)
To: Eric D. Mudama
Cc: Linux Kernel List, Jeff Garzik, Mark Lord,
IDE/ATA development list
On Sun, Apr 02, 2006 at 11:59:45AM -0600, Eric D. Mudama wrote:
> On 4/2/06, Dan Aloni <da-x@monatomic.org> wrote:
> > Hello,
> >
> > I'm testing the sata_mv driver to see whether reloading (rmmod
> > - insmod) works, and it seems something is broken there. The
> > first insmod goes okay - however all the insmods that follow
> > emit error=0x01 { AddrMarkNotFound } and status=0x50 { DriveReady
> > SeekComplete } from all the drives.
>
> More to Jeff/Mark etc... wouldn't this be expected? 0x50/0x01 is the
> contents of a reset signature FIS. If the module was removed, and
> upon insmod the bus came back up, the drive would complete ASR or
> COMRESET processing and post a signature FIS. Is the phy disabled
> when sata_mv is removed?
Should it be disabled or enabled? BTW it seems that the Marvell 3.6.1
propriety controller driver doesn't exhibit this problem so we can
exclude hardware faults.
It looks more like a problem between the controller and the driver.
I'm not an expert in PCI, but according to my observation so far,
the PCI_STATUS_SIG_TARGET_ABORT bit is turned on in the config space
after the driver is unloaded and that might indicate something bad.
kernel: PCI config space regs:
-kernel: 00: 608111ab 02b00317 01000009 00002008
+kernel: 00: 608111ab 02b80713 01000009 00002008
--
Dan Aloni, Linux specialist
XIV LTD, http://www.xivstorage.com
da-x@monatomic.org, da-x@colinux.org, da-x@gmx.net, dan@xiv.co.il
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sata_mv: module reloading doesn't work
2006-04-02 17:59 ` Eric D. Mudama
2006-04-02 22:44 ` Dan Aloni
@ 2006-04-03 21:57 ` Dan Aloni
2006-04-04 2:47 ` Mark Lord
1 sibling, 1 reply; 11+ messages in thread
From: Dan Aloni @ 2006-04-03 21:57 UTC (permalink / raw)
To: Eric D. Mudama
Cc: Linux Kernel List, Jeff Garzik, Mark Lord,
IDE/ATA development list
On Sun, Apr 02, 2006 at 11:59:45AM -0600, Eric D. Mudama wrote:
> On 4/2/06, Dan Aloni <da-x@monatomic.org> wrote:
> > Hello,
> >
> > I'm testing the sata_mv driver to see whether reloading (rmmod
> > - insmod) works, and it seems something is broken there. The
> > first insmod goes okay - however all the insmods that follow
> > emit error=0x01 { AddrMarkNotFound } and status=0x50 { DriveReady
> > SeekComplete } from all the drives.
>
> More to Jeff/Mark etc... wouldn't this be expected? 0x50/0x01 is the
> contents of a reset signature FIS. If the module was removed, and
> upon insmod the bus came back up, the drive would complete ASR or
> COMRESET processing and post a signature FIS. Is the phy disabled
> when sata_mv is removed?
Okay, finally got to test sata_mv with kexec, perhaps this can shed
some light on the matter.
* Normal boot
* insmod sata_mv
* all is okay, as expected
* Did kexec
* insmod sata_mv
* all is okay!
Good! It means that sata_mv doesn't mess things on its initialization
sequence.
* Normal boot
* insmod sata_mv
* all is okay, as expected
* rmmod sata_mv
* insmod sata_mv
* all is bad, as expected
* kexec
* insmod sata_mv
* all is bad!
Conclusion: sata_mv's shutdown does something bad.
--
Dan Aloni, Linux specialist
XIV LTD, http://www.xivstorage.com
da-x@monatomic.org, da-x@colinux.org, da-x@gmx.net, dan@xiv.co.il
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sata_mv: module reloading doesn't work
2006-04-03 21:57 ` Dan Aloni
@ 2006-04-04 2:47 ` Mark Lord
2006-04-04 5:24 ` Dan Aloni
2006-04-04 6:08 ` Dan Aloni
0 siblings, 2 replies; 11+ messages in thread
From: Mark Lord @ 2006-04-04 2:47 UTC (permalink / raw)
To: Dan Aloni
Cc: Eric D. Mudama, Linux Kernel List, Jeff Garzik, Mark Lord,
IDE/ATA development list
Dan Aloni wrote:
>
> * Normal boot
> * insmod sata_mv
> * all is okay, as expected
> * rmmod sata_mv
> * insmod sata_mv
> * all is bad, as expected
> * kexec
> * insmod sata_mv
> * all is bad!
>
> Conclusion: sata_mv's shutdown does something bad.
sata_mv seems to just use the default libata shutdown sequence,
so perhaps it's leaving the device in EDMA mode with interrupt
coalescing still on (from the BIOS), and interrupts are still
coming in or something..
I suppose it really ought to shut down the device before exiting,
and maybe the default of pci_disable_device() is not enough.. ?
Cheers
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sata_mv: module reloading doesn't work
2006-04-04 2:47 ` Mark Lord
@ 2006-04-04 5:24 ` Dan Aloni
2006-04-04 6:08 ` Dan Aloni
1 sibling, 0 replies; 11+ messages in thread
From: Dan Aloni @ 2006-04-04 5:24 UTC (permalink / raw)
To: Mark Lord
Cc: Eric D. Mudama, Linux Kernel List, Jeff Garzik, Mark Lord,
IDE/ATA development list
On Mon, Apr 03, 2006 at 10:47:07PM -0400, Mark Lord wrote:
> Dan Aloni wrote:
> >
> > * Normal boot
> > * insmod sata_mv
> > * all is okay, as expected
> > * rmmod sata_mv
> > * insmod sata_mv
> > * all is bad, as expected
> > * kexec
> > * insmod sata_mv
> > * all is bad!
> >
> >Conclusion: sata_mv's shutdown does something bad.
>
> sata_mv seems to just use the default libata shutdown sequence,
> so perhaps it's leaving the device in EDMA mode with interrupt
> coalescing still on (from the BIOS), and interrupts are still
> coming in or something..
>
> I suppose it really ought to shut down the device before exiting,
> and maybe the default of pci_disable_device() is not enough.. ?
That's what I thought yesterday, so I've tried and overrided
ata_remove_one to add more ordered shutdown code for the
controller, using 3.6.1 as reference, but no luck, the problem
persisted. In the next attempt I'll try to debug libata to see
if it does something unexpected.
--
Dan Aloni, Linux specialist
XIV LTD, http://www.xivstorage.com
da-x@monatomic.org, da-x@colinux.org, da-x@gmx.net, dan@xiv.co.il
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: sata_mv: module reloading doesn't work
2006-04-04 2:47 ` Mark Lord
2006-04-04 5:24 ` Dan Aloni
@ 2006-04-04 6:08 ` Dan Aloni
1 sibling, 0 replies; 11+ messages in thread
From: Dan Aloni @ 2006-04-04 6:08 UTC (permalink / raw)
To: Mark Lord
Cc: Eric D. Mudama, Linux Kernel List, Jeff Garzik, Mark Lord,
IDE/ATA development list
On Mon, Apr 03, 2006 at 10:47:07PM -0400, Mark Lord wrote:
> Dan Aloni wrote:
> >
> > * Normal boot
> > * insmod sata_mv
> > * all is okay, as expected
> > * rmmod sata_mv
> > * insmod sata_mv
> > * all is bad, as expected
> > * kexec
> > * insmod sata_mv
> > * all is bad!
> >
> >Conclusion: sata_mv's shutdown does something bad.
>
> sata_mv seems to just use the default libata shutdown sequence,
> so perhaps it's leaving the device in EDMA mode with interrupt
> coalescing still on (from the BIOS), and interrupts are still
> coming in or something..
>
> I suppose it really ought to shut down the device before exiting,
> and maybe the default of pci_disable_device() is not enough.. ?
BTW, can you tell what firmware version are you using? I'm
using rev 9, perhaps it also plays some role in this problem.
--
Dan Aloni, Linux specialist
XIV LTD, http://www.xivstorage.com
da-x@monatomic.org, da-x@colinux.org, da-x@gmx.net, dan@xiv.co.il
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2006-04-04 6:07 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-04-02 15:56 sata_mv: module reloading doesn't work Dan Aloni
2006-04-02 16:05 ` Mark Lord
2006-04-02 16:14 ` Dan Aloni
2006-04-02 16:21 ` Mark Lord
2006-04-02 19:05 ` Dan Aloni
2006-04-02 17:59 ` Eric D. Mudama
2006-04-02 22:44 ` Dan Aloni
2006-04-03 21:57 ` Dan Aloni
2006-04-04 2:47 ` Mark Lord
2006-04-04 5:24 ` Dan Aloni
2006-04-04 6:08 ` Dan Aloni
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).