* Other Problems with Marvell Driver - 7042 (2.6.23)... [not found] ` <45ED682A.9040408@garzik.org> @ 2007-10-31 15:41 ` Morrison, Tom 2007-10-31 16:06 ` Jeff Garzik 0 siblings, 1 reply; 21+ messages in thread From: Morrison, Tom @ 2007-10-31 15:41 UTC (permalink / raw) To: linux-ide, linux-kernel; +Cc: Jeff Garzik, Kumar Gala I am running the 'latest' kernel retrieved from Kumar Gala's Powerpc git tree (mainly because I am running on a MPC8548 board) and it appears to be in the full 2.6.23 version while the sata_mv driver version seems to be 1.01. I have searched the archives, and there has been some discussion of a regression in the Marvell driver, but I seem to have a different symptom from Olaf's (I am not running a 64bit kernel - and I am *not* running with large (36bit) physical and resources - so I wouldn't have the same type of IOMMU issues) Below in the error output (using ATA_DEBUG) the driver sees the two drives (3 partitions on /dev/sda & 2 partitions on /dev/sdb) and apparently sets up everything correctly for standard access... But, when I try to mount a partition - it freezes up and gets I/O errors? Can someone give me any hints of things to try? Thanks in advance... Tom Morrison Principal S/W Engineer Empirix, Inc (www.empirix.com) tmorrison@empirix.com (781) 266 - 3567 ====================start related initialization/error output=========== ---version--- Linux version 2.6.23-gd85714d8-dirty (tmorrison@linux204.empirix.com) (gcc version 3.4.3 20041021 (prerelease)) #33 Wed Oct 31 11:14:34 EDT 2007 ----bootup---- Scanning CPUs ... Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=256Mb residual: 2304Mb Linux version 2.6.23-gd85714d8-dirty (tmorrison@linux204.empirix.com) (gcc version 3.4.3 20041021 (prerelease)) #32 Wed Oct 31 10:47:38 EDT 2007 ---pci setup--- Adding PCI host bridge /soc8548@e0000000/pcie@a000 Found FSL PCI host bridge at 0x00000000e000a000.Firmware bus number: 0->255 ->Hose at 0xc037d000, cfg_addr=0xfdffd000,cfg_data=0xfdffd004 PCI: MEM[0] 0xc0000000 -> 0xdfffffff PCI: IO 0x0 -> 0xffffff PCI memory map start 0xe000a000, size 0x1000 PCI MEM resource start 0xc0000000, size 0x20000000. PCI IO resource start 0x00000000, size 0x01000000, phy base 0xe3000000. ---related pci probing---- PCI: Scanning bus 0000:0c PCI: Found 0000:0c:00.0 [11ab/7042] 000100 00 PCI: Fixups for bus 0000:0c io_base_high <ff> new base/limit <fff000/fff000> pci_busdev_to_OF_node(12,0x0) pci_busdev_to_OF_node(2,0x40) pci_busdev_to_OF_node(1,0x0) pci_busdev_to_OF_node(0,0x0) parent is /soc8548@e0000000/pcie@a000 result is <NULL> PCI: Bus scan for 0000:0c returning with max=0c ---pci probing results--- PCI: bridge rsrc dab00000..dabfffff (200), parent c2015a58 PCI:0000:0c:00.0: Resource 0: 00000000dab00000-00000000dabfffff (f=204) ================================= <snip unrelated initialization> ================================= --- sata_mv init --- sata_mv 0000:0c:00.0: version 1.01 ata_host_alloc: ENTER ata_port_alloc: ENTER ata_port_alloc: ENTER ata_port_alloc: ENTER ata_port_alloc: ENTER sata_mv 0000:0c:00.0: Applying 60X1C0 workarounds to unknown rev mv_port_init: EDMA cfg=0x0000211f EDMA IRQ err cause/mask=0x00000000/0xffffffff mv_port_init: EDMA cfg=0x0000211f EDMA IRQ err cause/mask=0x00000000/0xffffffff mv_port_init: EDMA cfg=0x0000211f EDMA IRQ err cause/mask=0x00000000/0xffffffff mv_port_init: EDMA cfg=0x0000211f EDMA IRQ err cause/mask=0x00000000/0xffffffff mv_init_host: HC0: HC config=0x000100ff HC IRQ cause (before clear)=0x00000000 mv_init_host: HC MAIN IRQ cause/mask=0x00000000/0x0087ffff PCI int cause/mask=0x00000000/0x00000000 mv_dump_pci_cfg: 00: 704211ab 00100007 01000002 00000000 mv_dump_pci_cfg: 10: dab00004 00000000 00ffff01 00000000 mv_dump_pci_cfg: 20: 00000000 00000000 00000000 11ab11ab mv_dump_pci_cfg: 30: 00000000 00000040 00000000 00000100 mv_dump_pci_cfg: 40: 00025001 00000000 00000000 00000000 mv_dump_pci_cfg: 50: 00806005 00000000 00000000 00000000 mv_dump_pci_cfg: 60: 00110010 00640081 sata_mv 0000:0c:00.0: Gen-IIE 32 slots 4 ports SCSI mode IRQ via INTx __ata_port_freeze: ata4294967295 port frozen __ata_port_freeze: ata4294967295 port frozen __ata_port_freeze: ata4294967295 port frozen __ata_port_freeze: ata4294967295 port frozen scsi0 : sata_mv scsi1 : sata_mv scsi2 : sata_mv scsi3 : sata_mv ata1: SATA max UDMA/133 mmio m1048576@0xdab00000 port 0xdab22000 irq 18 ata2: SATA max UDMA/133 mmio m1048576@0xdab00000 port 0xdab24000 irq 18 ata3: SATA max UDMA/133 mmio m1048576@0xdab00000 port 0xdab26000 irq 18 ata4: SATA max UDMA/133 mmio m1048576@0xdab00000 port 0xdab28000 irq 18 ata_host_register: probe begin ata_port_schedule_eh: port EH scheduled ata_scsi_error: ENTER ata_port_flush_task: ENTER ata_eh_link_autopsy: ENTER ata_eh_recover: ENTER __ata_port_freeze: ata1 port frozen mv_phy_reset: ENTER, port 0, mmio 0xf10a2000 mv_phy_reset: S-regs after ATA_RST: SStat 0x00000004 SErr 0x00000000 SCtrl 0x00000004 mv_phy_reset: S-regs after PHY wake: SStat 0x00000113 SErr 0x04010000 SCtrl 0x00000300 ata_dev_classify: found ATA device by sig mv_phy_reset: EXIT ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata_eh_thaw_port: ata1 port thawed ata_eh_revalidate_and_attach: ENTER ata1: ata_dev_select: ENTER, device 0, wait 1 ata1: ata_dev_select: ENTER, device 0, wait 1 ata_tf_load: feat 0x0 nsect 0x0 lba 0x0 0x0 0x0 ata_tf_load: device 0xA0 ata_exec_command: ata1: cmd 0xEC ata_hsm_move: ata1: protocol 2 task_state 2 (dev_stat 0x58) ata_pio_sector: data read ata_hsm_move: ata1: protocol 2 task_state 3 (dev_stat 0x50) ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50 ata_port_flush_task: ENTER ata1: ata_dev_select: ENTER, device 0, wait 1 ata_tf_load: hob: feat 0x0 nsect 0x0, lba 0x0 0x0 0x0 ata_tf_load: feat 0x0 nsect 0x0 lba 0x0 0x0 0x0 ata_tf_load: device 0xE0 ata_exec_command: ata1: cmd 0x27 ata_hsm_move: ata1: protocol 1 task_state 3 (dev_stat 0x50) ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50 ata_port_flush_task: ENTER ata_dump_id: 49==0x2f00 53==0x0007 63==0x0007 64==0x0003 75==0x001f ata_dump_id: 80==0x00fe 81==0x0000 82==0x346b 83==0x7d09 84==0x5923 ata_dump_id: 88==0x407f 93==0x0000 ata1.00: ATA-7: ST3250820NS, 3.AEE, max UDMA/133 ata1.00: 488397168 sectors, multi 0: LBA48 NCQ (depth 0/32) ata_dev_set_xfermode: set features - xfer mode ata1: ata_dev_select: ENTER, device 0, wait 1 ata_tf_load: feat 0x3 nsect 0x46 lba 0x0 0x0 0x0 ata_tf_load: device 0xA0 ata_exec_command: ata1: cmd 0xEF ata_hsm_move: ata1: protocol 1 task_state 3 (dev_stat 0x50) ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50 ata_port_flush_task: ENTER ata_dev_set_xfermode: EXIT, err_mask=0 ata1: ata_dev_select: ENTER, device 0, wait 1 ata1: ata_dev_select: ENTER, device 0, wait 1 ata_tf_load: feat 0x0 nsect 0x0 lba 0x0 0x0 0x0 ata_tf_load: device 0xA0 ata_exec_command: ata1: cmd 0xEC ata_hsm_move: ata1: protocol 2 task_state 2 (dev_stat 0x58) ata_pio_sector: data read ata_hsm_move: ata1: protocol 2 task_state 3 (dev_stat 0x50) ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50 ata_port_flush_task: ENTER ata1: ata_dev_select: ENTER, device 0, wait 1 ata_tf_load: hob: feat 0x0 nsect 0x0, lba 0x0 0x0 0x0 ata_tf_load: feat 0x0 nsect 0x0 lba 0x0 0x0 0x0 ata_tf_load: device 0xE0 ata_exec_command: ata1: cmd 0x27 ata_hsm_move: ata1: protocol 1 task_state 3 (dev_stat 0x50) ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50 ata_port_flush_task: ENTER ata_dump_id: 49==0x2f00 53==0x0007 63==0x0007 64==0x0003 75==0x001f ata_dump_id: 80==0x00fe 81==0x0000 82==0x346b 83==0x7d09 84==0x5923 ata_dump_id: 88==0x407f 93==0x0000 ata_dev_set_mode: xfer_shift=12, xfer_mode=0x46 ata1.00: configured for UDMA/133 ata_eh_recover: EXIT, rc=0 ata_scsi_error: EXIT ata_port_schedule_eh: port EH scheduled ata_scsi_error: ENTER ata_port_flush_task: ENTER ata_eh_link_autopsy: ENTER ata_eh_recover: ENTER __ata_port_freeze: ata2 port frozen mv_phy_reset: ENTER, port 1, mmio 0xf10a4000 mv_phy_reset: S-regs after ATA_RST: SStat 0x00000004 SErr 0x04000000 SCtrl 0x00000004 mv_phy_reset: S-regs after PHY wake: SStat 0x00000113 SErr 0x04010000 SCtrl 0x00000300 ata_dev_classify: found ATA device by sig mv_phy_reset: EXIT ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata_eh_thaw_port: ata2 port thawed ata_eh_revalidate_and_attach: ENTER ata2: ata_dev_select: ENTER, device 0, wait 1 ata2: ata_dev_select: ENTER, device 0, wait 1 ata_tf_load: feat 0x0 nsect 0x0 lba 0x0 0x0 0x0 ata_tf_load: device 0xA0 ata_exec_command: ata2: cmd 0xEC ata_hsm_move: ata2: protocol 2 task_state 2 (dev_stat 0x58) ata_pio_sector: data read ata_hsm_move: ata2: protocol 2 task_state 3 (dev_stat 0x50) ata_hsm_move: ata2: dev 0 command complete, drv_stat 0x50 ata_port_flush_task: ENTER ata2: ata_dev_select: ENTER, device 0, wait 1 ata_tf_load: hob: feat 0x0 nsect 0x0, lba 0x0 0x0 0x0 ata_tf_load: feat 0x0 nsect 0x0 lba 0x0 0x0 0x0 ata_tf_load: device 0xE0 ata_exec_command: ata2: cmd 0x27 ata_hsm_move: ata2: protocol 1 task_state 3 (dev_stat 0x50) ata_hsm_move: ata2: dev 0 command complete, drv_stat 0x50 ata_port_flush_task: ENTER ata_dump_id: 49==0x2f00 53==0x0007 63==0x0007 64==0x0003 75==0x001f ata_dump_id: 80==0x00fe 81==0x0000 82==0x346b 83==0x7d09 84==0x5923 ata_dump_id: 88==0x407f 93==0x0000 ata2.00: ATA-7: ST3250820NS, 3.AEG, max UDMA/133 ata2.00: 488397168 sectors, multi 0: LBA48 NCQ (depth 0/32) ata_dev_set_xfermode: set features - xfer mode ata2: ata_dev_select: ENTER, device 0, wait 1 ata_tf_load: feat 0x3 nsect 0x46 lba 0x0 0x0 0x0 ata_tf_load: device 0xA0 ata_exec_command: ata2: cmd 0xEF ata_hsm_move: ata2: protocol 1 task_state 3 (dev_stat 0x50) ata_hsm_move: ata2: dev 0 command complete, drv_stat 0x50 ata_port_flush_task: ENTER ata_dev_set_xfermode: EXIT, err_mask=0 ata2: ata_dev_select: ENTER, device 0, wait 1 ata2: ata_dev_select: ENTER, device 0, wait 1 ata_tf_load: feat 0x0 nsect 0x0 lba 0x0 0x0 0x0 ata_tf_load: device 0xA0 ata_exec_command: ata2: cmd 0xEC ata_hsm_move: ata2: protocol 2 task_state 2 (dev_stat 0x58) ata_pio_sector: data read ata_hsm_move: ata2: protocol 2 task_state 3 (dev_stat 0x50) ata_hsm_move: ata2: dev 0 command complete, drv_stat 0x50 ata_port_flush_task: ENTER ata2: ata_dev_select: ENTER, device 0, wait 1 ata_tf_load: hob: feat 0x0 nsect 0x0, lba 0x0 0x0 0x0 ata_tf_load: feat 0x0 nsect 0x0 lba 0x0 0x0 0x0 ata_tf_load: device 0xE0 ata_exec_command: ata2: cmd 0x27 ata_hsm_move: ata2: protocol 1 task_state 3 (dev_stat 0x50) ata_hsm_move: ata2: dev 0 command complete, drv_stat 0x50 ata_port_flush_task: ENTER ata_dump_id: 49==0x2f00 53==0x0007 63==0x0007 64==0x0003 75==0x001f ata_dump_id: 80==0x00fe 81==0x0000 82==0x346b 83==0x7d09 84==0x5923 ata_dump_id: 88==0x407f 93==0x0000 ata_dev_set_mode: xfer_shift=12, xfer_mode=0x46 ata2.00: configured for UDMA/133 ata_eh_recover: EXIT, rc=0 ata_scsi_error: EXIT ata_port_schedule_eh: port EH scheduled ata_scsi_error: ENTER ata_port_flush_task: ENTER ata_eh_link_autopsy: ENTER ata_eh_recover: ENTER __ata_port_freeze: ata3 port frozen mv_phy_reset: ENTER, port 2, mmio 0xf10a6000 mv_phy_reset: S-regs after ATA_RST: SStat 0x00000004 SErr 0x00000000 SCtrl 0x00000004 mv_phy_reset: S-regs after PHY wake: SStat 0x00000000 SErr 0x00000000 SCtrl 0x00000300 ata3: SATA link down (SStatus 0 SControl 300) ata_eh_thaw_port: ata3 port thawed ata_eh_revalidate_and_attach: ENTER ata_eh_recover: EXIT, rc=0 ata_scsi_error: EXIT ata_port_schedule_eh: port EH scheduled ata_scsi_error: ENTER ata_port_flush_task: ENTER ata_eh_link_autopsy: ENTER ata_eh_recover: ENTER __ata_port_freeze: ata4 port frozen mv_phy_reset: ENTER, port 3, mmio 0xf10a8000 mv_phy_reset: S-regs after ATA_RST: SStat 0x00000004 SErr 0x00000000 SCtrl 0x00000004 mv_phy_reset: S-regs after PHY wake: SStat 0x00000000 SErr 0x00000000 SCtrl 0x00000300 ata4: SATA link down (SStatus 0 SControl 300) ata_eh_thaw_port: ata4 port thawed ata_eh_revalidate_and_attach: ENTER ata_eh_recover: EXIT, rc=0 ata_scsi_error: EXIT ata_host_register: host probe begin ata_scsi_dump_cdb: CDB (1:0,0,0) 12 00 00 00 24 00 45 67 01 ata_scsiop_inq_std: ENTER ata_scsi_dump_cdb: CDB (1:0,0,0) 12 00 00 00 60 00 45 67 01 ata_scsiop_inq_std: ENTER scsi 0:0:0:0: Direct-Access ATA ST3250820NS 3.AE PQ: 0 ANSI: 5 ata_scsi_dump_cdb: CDB (1:0,0,0) 00 00 00 00 00 00 45 67 01 ata_scsiop_noop: ENTER ata_scsi_dump_cdb: CDB (1:0,0,0) 25 00 00 00 00 00 00 00 00 ata_scsiop_read_cap: ENTER sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 3f 00 00 00 00 00 08 ata_scsiop_mode_sense: ENTER sd 0:0:0:0: [sda] Write Protect is off ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 08 ata_scsiop_mode_sense: ENTER ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 24 ata_scsiop_mode_sense: ENTER sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ata_scsi_dump_cdb: CDB (1:0,0,0) 00 00 00 00 00 00 00 00 24 ata_scsiop_noop: ENTER ata_scsi_dump_cdb: CDB (1:0,0,0) 25 00 00 00 00 00 00 00 00 ata_scsiop_read_cap: ENTER sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 3f 00 00 00 00 00 08 ata_scsiop_mode_sense: ENTER sd 0:0:0:0: [sda] Write Protect is off ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 08 ata_scsiop_mode_sense: ENTER ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 24 ata_scsiop_mode_sense: ENTER sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda:<3>ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 00 00 00 00 00 00 08 ata_scsi_translate: ENTER scsi_10_lba_len: ten-byte command ata_sg_setup: ENTER, ata1 ata_sg_setup: 1 sg elements mapped ata_scsi_translate: EXIT mv_host_intr: ENTER, hc0 relevant=0x00000102 HC IRQ cause=0x00000011 ata_sg_clean: unmapping 1 sg elements mv_host_intr: EXIT sda1 sda2 sda3 sd 0:0:0:0: [sda] Attached SCSI disk sd 0:0:0:0: Attached scsi generic sg0 type 0 ata_scsi_dump_cdb: CDB (2:0,0,0) 12 00 00 00 24 00 45 67 01 ata_scsiop_inq_std: ENTER ata_scsi_dump_cdb: CDB (2:0,0,0) 12 00 00 00 60 00 45 67 01 ata_scsiop_inq_std: ENTER scsi 1:0:0:0: Direct-Access ATA ST3250820NS 3.AE PQ: 0 ANSI: 5 ata_scsi_dump_cdb: CDB (2:0,0,0) 00 00 00 00 00 00 45 67 01 ata_scsiop_noop: ENTER ata_scsi_dump_cdb: CDB (2:0,0,0) 25 00 00 00 00 00 00 00 00 ata_scsiop_read_cap: ENTER sd 1:0:0:0: [sdb] 488397168 512-byte hardware sectors (250059 MB) ata_scsi_dump_cdb: CDB (2:0,0,0) 5a 00 3f 00 00 00 00 00 08 ata_scsiop_mode_sense: ENTER sd 1:0:0:0: [sdb] Write Protect is off ata_scsi_dump_cdb: CDB (2:0,0,0) 5a 00 08 00 00 00 00 00 08 ata_scsiop_mode_sense: ENTER ata_scsi_dump_cdb: CDB (2:0,0,0) 5a 00 08 00 00 00 00 00 24 ata_scsiop_mode_sense: ENTER sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ata_scsi_dump_cdb: CDB (2:0,0,0) 00 00 00 00 00 00 00 00 24 ata_scsiop_noop: ENTER ata_scsi_dump_cdb: CDB (2:0,0,0) 25 00 00 00 00 00 00 00 00 ata_scsiop_read_cap: ENTER sd 1:0:0:0: [sdb] 488397168 512-byte hardware sectors (250059 MB) ata_scsi_dump_cdb: CDB (2:0,0,0) 5a 00 3f 00 00 00 00 00 08 ata_scsiop_mode_sense: ENTER sd 1:0:0:0: [sdb] Write Protect is off ata_scsi_dump_cdb: CDB (2:0,0,0) 5a 00 08 00 00 00 00 00 08 ata_scsiop_mode_sense: ENTER ata_scsi_dump_cdb: CDB (2:0,0,0) 5a 00 08 00 00 00 00 00 24 ata_scsiop_mode_sense: ENTER sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb:<3>ata_scsi_dump_cdb: CDB (2:0,0,0) 28 00 00 00 00 00 00 00 08 ata_scsi_translate: ENTER scsi_10_lba_len: ten-byte command ata_sg_setup: ENTER, ata2 ata_sg_setup: 1 sg elements mapped ata_scsi_translate: EXIT mv_host_intr: ENTER, hc0 relevant=0x00000108 HC IRQ cause=0x00000012 ata_sg_clean: unmapping 1 sg elements mv_host_intr: EXIT sdb1 sdb2 sd 1:0:0:0: [sdb] Attached SCSI disk sd 1:0:0:0: Attached scsi generic sg1 type 0 <snip (rest of boot sequence)> ---- error on mount --- -bash-2.05b# mount /dev/sda2 /mnt/src ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 01 31 6f 5e 00 00 20 ata_scsi_translate: ENTER scsi_10_lba_len: ten-byte command ata_sg_setup: ENTER, ata1 ata_sg_setup: 4 sg elements mapped ata_scsi_translate: EXIT mv_host_intr: ENTER, hc0 relevant=0x00000102 HC IRQ cause=0x00000011 ata_sg_clean: unmapping 4 sg elements mv_host_intr: EXIT ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 01 31 6f 60 00 00 02 ata_scsi_translate: ENTER scsi_10_lba_len: ten-byte command ata_sg_setup: ENTER, ata1 ata_sg_setup: 1 sg elements mapped ata_scsi_translate: EXIT mv_host_intr: ENTER, hc0 relevant=0x00000102 HC IRQ cause=0x00000011 ata_sg_clean: unmapping 1 sg elements mv_host_intr: EXIT ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 01 31 6f 5e 00 00 08 ata_scsi_translate: ENTER scsi_10_lba_len: ten-byte command ata_sg_setup: ENTER, ata1 ata_sg_setup: 1 sg elements mapped ata_scsi_translate: EXIT mv_host_intr: ENTER, hc0 relevant=0x00000102 HC IRQ cause=0x00000011 ata_sg_clean: unmapping 1 sg elements mv_host_intr: EXIT ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 01 31 6f 66 00 00 08 ata_scsi_translate: ENTER scsi_10_lba_len: ten-byte command ata_sg_setup: ENTER, ata1 ata_sg_setup: 1 sg elements mapped ata_scsi_translate: EXIT mv_host_intr: ENTER, hc0 relevant=0x00000102 HC IRQ cause=0x00000011 ata_sg_clean: unmapping 1 sg elements mv_host_intr: EXIT ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 01 31 79 06 00 00 08 ata_scsi_translate: ENTER scsi_10_lba_len: ten-byte command ata_sg_setup: ENTER, ata1 ata_sg_setup: 1 sg elements mapped ata_scsi_translate: EXIT mv_host_intr: ENTER, hc0 relevant=0x00000102 HC IRQ cause=0x00000011 ata_sg_clean: unmapping 1 sg elements mv_host_intr: EXIT ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 01 31 88 e6 00 00 08 ata_scsi_translate: ENTER scsi_10_lba_len: ten-byte command ata_sg_setup: ENTER, ata1 ata_sg_setup: 1 sg elements mapped ata_scsi_translate: EXIT mv_host_intr: ENTER, hc0 relevant=0x00000102 HC IRQ cause=0x00000011 ata_sg_clean: unmapping 1 sg elements mv_host_intr: EXIT kjournald starting. Commit interval 5 seconds ata_scsi_dump_cdb: CDB (1:0,0,0) 2a 00 01 31 6f 5e 00 00 08 ata_scsi_translate: ENTER scsi_10_lba_len: ten-byte command ata_sg_setup: ENTER, ata1 ata_sg_setup: 1 sg elements mapped ata_scsi_translate: EXIT ----delay of at least 15-30 seconds--- ata_scsi_timed_out: ENTER ata_scsi_timed_out: EXIT, ret=0 ata_scsi_error: ENTER ata_port_flush_task: ENTER __ata_port_freeze: ata1 port frozen ata_eh_link_autopsy: ENTER ata_eh_link_autopsy: EXIT ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd ca/00:08:5e:6f:31/00:00:00:00:00/e1 tag 0 cdb 0x0 data 4096 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1.00: status: { DRDY } ata_eh_recover: ENTER __ata_port_freeze: ata1 port frozen ata1: port is slow to respond, please be patient (Status 0xd0) ata1: prereset failed (errno=-16) ata1: reset failed, giving up ata_eh_recover: EXIT, rc=-16 ata1.00: disabled ata_sg_clean: unmapping 1 sg elements ata1: EH complete ata_scsi_error: EXIT ata_scsi_dump_cdb: CDB (1:0,0,0) 2a 00 01 31 6f 5e 00 00 08 sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sda, sector 20016990 Buffer I/O error on device sda2, logical block 0 lost page write due to I/O error on sda2 EXT3 FS on sda2, internal journal EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Other Problems with Marvell Driver - 7042 (2.6.23)... 2007-10-31 15:41 ` Other Problems with Marvell Driver - 7042 (2.6.23) Morrison, Tom @ 2007-10-31 16:06 ` Jeff Garzik 2007-10-31 18:14 ` Update (Now a False Alarm) " Morrison, Tom 2007-11-14 17:49 ` 2.6.23.1 - sata_mv (7042) hang with large file operations Morrison, Tom 0 siblings, 2 replies; 21+ messages in thread From: Jeff Garzik @ 2007-10-31 16:06 UTC (permalink / raw) To: Morrison, Tom; +Cc: linux-ide, linux-kernel, Kumar Gala Morrison, Tom wrote: > I am running the 'latest' kernel retrieved from Kumar Gala's > Powerpc git tree (mainly because I am running on a MPC8548 board) > and it appears to be in the full 2.6.23 version while the sata_mv > driver version seems to be 1.01. > > I have searched the archives, and there has been some discussion > of a regression in the Marvell driver, but I seem to have a > different symptom from Olaf's (I am not running a 64bit kernel - > and I am *not* running with large (36bit) physical and resources - > so I wouldn't have the same type of IOMMU issues) > > Below in the error output (using ATA_DEBUG) the driver sees the > two drives (3 partitions on /dev/sda & 2 partitions on /dev/sdb) > and apparently sets up everything correctly for standard access... > > But, when I try to mount a partition - it freezes up and gets I/O > errors? > Can someone give me any hints of things to try? First you need to try 2.6.23.1 rather than 2.6.23, because it contains a critical sata_mv fix. Jeff ^ permalink raw reply [flat|nested] 21+ messages in thread
* Update (Now a False Alarm) RE: Other Problems with Marvell Driver - 7042 (2.6.23)... 2007-10-31 16:06 ` Jeff Garzik @ 2007-10-31 18:14 ` Morrison, Tom 2007-11-14 17:49 ` 2.6.23.1 - sata_mv (7042) hang with large file operations Morrison, Tom 1 sibling, 0 replies; 21+ messages in thread From: Morrison, Tom @ 2007-10-31 18:14 UTC (permalink / raw) To: Jeff Garzik; +Cc: linux-ide, linux-kernel, Kumar Gala Jeff / all - Jeff is (again) 100% correct with comments - the sata_mv.c I used from Kumar's 2.6.23 Powerpc tree is very *close*, but not exactly the same as the sata_mv.c in the 'official' 2.6.23.1 tree. I have verified that I now can access my disks behind the 7042 chip with the 'mainline' 2.6.23.1 (and my bsp)... Sorry for the false alarm - thank you Jeff for pointing me in the right direction with this! Sincerely, Tom Morrison -----Original Message----- From: Jeff Garzik [mailto:jeff@garzik.org] Sent: Wednesday, October 31, 2007 12:07 PM To: Morrison, Tom Cc: linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org; Kumar Gala Subject: Re: Other Problems with Marvell Driver - 7042 (2.6.23)... Morrison, Tom wrote: <snip description of problem> ==========Jeff writes===== First you need to try 2.6.23.1 rather than 2.6.23, because it contains a critical sata_mv fix. Jeff ^ permalink raw reply [flat|nested] 21+ messages in thread
* 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-10-31 16:06 ` Jeff Garzik 2007-10-31 18:14 ` Update (Now a False Alarm) " Morrison, Tom @ 2007-11-14 17:49 ` Morrison, Tom 2007-11-14 17:56 ` Mark Lord 1 sibling, 1 reply; 21+ messages in thread From: Morrison, Tom @ 2007-11-14 17:49 UTC (permalink / raw) To: Jeff Garzik; +Cc: linux-ide, linux-kernel All, I apologize if this has been discussed - but I haven't been able to find exactly what I am looking for in the discussions the last few weeks... I am running Linux 2.6.23.1 and have a 7042 SATA driver running (that seems to run very well) - it has the fixes talked about between Jeff & Olaf (mv_sg_fill changes).... The problem comes ONLY when I am doing large file operations (e.g.: just copying a file) to/from the SATA drives behind the subject line 7042....it just hangs after about 10-15 seconds into the copy... How large a file causes the hang - you ask - well, somewhere between 100Meg & 500Meg... In all other respects - this driver seems to be working... Is there a known problem - or do I need to describe in more detail? Thanks in advance for any / all ideas / questions /...etc Tom Morrison Principal S/W Engineer Empirix, Inc (www.empirix.com) tmorrison@empirix.com (781) 266 - 3567 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-11-14 17:49 ` 2.6.23.1 - sata_mv (7042) hang with large file operations Morrison, Tom @ 2007-11-14 17:56 ` Mark Lord 2007-11-14 18:09 ` Morrison, Tom 0 siblings, 1 reply; 21+ messages in thread From: Mark Lord @ 2007-11-14 17:56 UTC (permalink / raw) To: Morrison, Tom; +Cc: Jeff Garzik, linux-ide, linux-kernel Morrison, Tom wrote: > All, > > I apologize if this has been discussed - but I haven't been > able to find exactly what I am looking for in the discussions > the last few weeks... > > I am running Linux 2.6.23.1 and have a 7042 SATA driver running > (that seems to run very well) - it has the fixes talked about > between Jeff & Olaf (mv_sg_fill changes).... > > The problem comes ONLY when I am doing large file operations > (e.g.: just copying a file) to/from the SATA drives behind > the subject line 7042....it just hangs after about 10-15 > seconds into the copy... > > How large a file causes the hang - you ask - well, somewhere > between 100Meg & 500Meg... > > In all other respects - this driver seems to be working... > > Is there a known problem - or do I need to describe in more > detail? > > Thanks in advance for any / all ideas / questions /...etc .. Can you give me exact details of how to set up and reproduce this? -- Kernel version -- number/config/model of drives -- exact command line sequence to cause the failure Thanks ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-11-14 17:56 ` Mark Lord @ 2007-11-14 18:09 ` Morrison, Tom 2007-11-14 18:30 ` Mark Lord ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Morrison, Tom @ 2007-11-14 18:09 UTC (permalink / raw) To: Mark Lord; +Cc: Jeff Garzik, linux-ide, linux-kernel -----Original Message----- From: Mark Lord [mailto:liml@rtr.ca] Sent: Wednesday, November 14, 2007 12:57 PM To: Morrison, Tom Cc: Jeff Garzik; linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: 2.6.23.1 - sata_mv (7042) hang with large file operations Morrison, Tom wrote: > <snip > > The problem comes ONLY when I am doing large file operations > (e.g.: just copying a file) to/from the SATA drives behind > the subject line 7042....it just hangs after about 10-15 > seconds into the copy... > > How large a file causes the hang - you ask - well, somewhere > between 100Meg & 500Meg... > <snip other drivel> ::: Can you give me exact details of how to set up and reproduce this? ::: -- Kernel version Linux-2.6.23.1 NOTE: I am using ppc (arch/ppc instead of arch/powerpc) ::: -- number/config/model of drives 2x250GIG Western Digital - 3 partitions (largest (/dev/sda3 ~200Gig - formatted to ext2). 7042 PEX on a MPC8548 Board ::: -- exact command line sequence to cause the failure NFS mount root file system (I am currently rebuild to take away the NFS file system dependency) - /dev/sda3 is drive in question... a) mount /dev/sda3 /mnt/src b) cp large_500Meg_file /mnt/src/. ========================================================== ========================================================== NOTE: this does NOT fail on a 2.6.11 kernel version!!!! So I do NOT think it's a hardware problem! It could be a PEX related problem with arch/ppc - I would expect under heavy pounding with smaller files it would fail as well - but it does NOT) ========================================================== ========================================================== Anything else you need to know? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-11-14 18:09 ` Morrison, Tom @ 2007-11-14 18:30 ` Mark Lord 2007-11-14 20:12 ` Morrison, Tom 2007-11-14 18:37 ` Mark Lord 2007-11-14 18:56 ` Mark Lord 2 siblings, 1 reply; 21+ messages in thread From: Mark Lord @ 2007-11-14 18:30 UTC (permalink / raw) To: Morrison, Tom; +Cc: Jeff Garzik, linux-ide, linux-kernel Morrison, Tom wrote: .. > ::: Can you give me exact details of how to set up and reproduce this? > ::: -- Kernel version > > Linux-2.6.23.1 > > NOTE: I am using ppc (arch/ppc instead of arch/powerpc) .. Okay. Is that 32-bit or 64-bit? How much RAM ? My PPC machine is not currently set up for Linux, and has only PCIX (not PCIe) slots, so I'll try this first on an x86-32 box with PCIe. If it works for me there, then I may be able to try a PCIX card in my PPC-32 box later. The PCIX card won't have a 7042 of course, so I'll use a 6081 instead. Those earlier Marvell chips are supposed to be extremely similar. > > ::: -- number/config/model of drives > > 2x250GIG Western Digital - 3 partitions (largest (/dev/sda3 > ~200Gig - formatted to ext2). > > 7042 PEX on a MPC8548 Board > > ::: -- exact command line sequence to cause the failure > > NFS mount root file system (I am currently rebuild to take away > the NFS file system dependency) - /dev/sda3 is drive in > question... > > a) mount /dev/sda3 /mnt/src > b) cp large_500Meg_file /mnt/src/. > > ========================================================== > ========================================================== > NOTE: this does NOT fail on a 2.6.11 kernel version!!!! > So I do NOT think it's a hardware problem! > > It could be a PEX related problem with arch/ppc - I would > expect under heavy pounding with smaller files it would > fail as well - but it does NOT) > ========================================================== > ========================================================== > > Anything else you need to know? > > - > To unsubscribe from this list: send the line "unsubscribe linux-ide" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-11-14 18:30 ` Mark Lord @ 2007-11-14 20:12 ` Morrison, Tom 0 siblings, 0 replies; 21+ messages in thread From: Morrison, Tom @ 2007-11-14 20:12 UTC (permalink / raw) To: Mark Lord; +Cc: Jeff Garzik, linux-ide, linux-kernel OK: 32-bit linux - Large Physical Memory / Large PTE (CONFIG_PTE_64BIT & CONFIG_PHYS_64BIT) 4 Gig of DDR RAM Here is the lspci -vv -bash-2.05b# lspci -vv 00:00.0 Power PC: Unknown device 1957:0012 (rev 20) !!! Invalid class 0b20 for header type 01 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Bus: primary=00, secondary=01, subordinate=11, sec-latency=0 I/O behind bridge: 00000000-00000fff Memory behind bridge: ea900000-eeffffff BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [4c] #10 [0041] 01:00.0 PCI bridge: PLX Technology, Inc.: Unknown device 8532 (rev ba) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Region 0: Memory at eefe0000 (32-bit, non-prefetchable) [size=128K] Bus: primary=01, secondary=02, subordinate=11, sec-latency=0 I/O behind bridge: 07ffe000-07ffffff Memory behind bridge: ea900000-eeefffff BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [68] #10 [0051] 02:01.0 PCI bridge: PLX Technology, Inc.: Unknown device 8532 (rev ba) (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Bus: primary=02, secondary=03, subordinate=08, sec-latency=0 Memory behind bridge: ec000000-eeefffff BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [68] #10 [0161] 02:02.0 PCI bridge: PLX Technology, Inc.: Unknown device 8532 (rev ba) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Bus: primary=02, secondary=09, subordinate=09, sec-latency=0 BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [68] #10 [0161] 02:03.0 PCI bridge: PLX Technology, Inc.: Unknown device 8532 (rev ba) (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Bus: primary=02, secondary=0a, subordinate=0b, sec-latency=0 Memory behind bridge: eac00000-ebffffff BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [68] #10 [0161] 02:08.0 PCI bridge: PLX Technology, Inc.: Unknown device 8532 (rev ba) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Bus: primary=02, secondary=0c, subordinate=0c, sec-latency=0 I/O behind bridge: 07fff000-07ffffff Memory behind bridge: eab00000-eabfffff BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [68] #10 [0161] 02:09.0 PCI bridge: PLX Technology, Inc.: Unknown device 8532 (rev ba) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Bus: primary=02, secondary=0d, subordinate=0f, sec-latency=0 I/O behind bridge: 07ffe000-07ffefff Memory behind bridge: ea900000-eaafffff BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [68] #10 [0161] 02:0a.0 PCI bridge: PLX Technology, Inc.: Unknown device 8532 (rev ba) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Bus: primary=02, secondary=10, subordinate=10, sec-latency=0 BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [68] #10 [0161] 02:0b.0 PCI bridge: PLX Technology, Inc.: Unknown device 8532 (rev ba) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Bus: primary=02, secondary=11, subordinate=11, sec-latency=0 BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [68] #10 [0161] 03:00.0 PCI bridge: PLX Technology, Inc.: Unknown device 8508 (rev aa) (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Region 0: Memory at eeee0000 (32-bit, non-prefetchable) [size=128K] Bus: primary=03, secondary=04, subordinate=08, sec-latency=0 Memory behind bridge: ec000000-eedfffff BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [68] #10 [0051] 04:01.0 PCI bridge: PLX Technology, Inc.: Unknown device 8508 (rev aa) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Bus: primary=04, secondary=05, subordinate=05, sec-latency=0 BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [68] #10 [0161] 04:02.0 PCI bridge: PLX Technology, Inc.: Unknown device 8508 (rev aa) (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Bus: primary=04, secondary=06, subordinate=06, sec-latency=0 Memory behind bridge: ec000000-eedfffff BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [68] #10 [0161] 04:03.0 PCI bridge: PLX Technology, Inc.: Unknown device 8508 (rev aa) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Bus: primary=04, secondary=07, subordinate=07, sec-latency=0 BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [68] #10 [0161] 04:04.0 PCI bridge: PLX Technology, Inc.: Unknown device 8508 (rev aa) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Bus: primary=04, secondary=08, subordinate=08, sec-latency=0 BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [68] #10 [0161] 06:00.0 Bridge: PLX Technology, Inc.: Unknown device 8532 (rev ba) Subsystem: PLX Technology, Inc.: Unknown device 8532 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 51 Region 0: Memory at eede0000 (32-bit, non-prefetchable) [size=128K] Region 2: Memory at ec000000 (32-bit, non-prefetchable) [size=32M] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [68] #10 [0001] 0a:00.0 PCI bridge: PLX Technology, Inc.: Unknown device 8111 (rev 21) (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Region 0: Memory at ebff0000 (64-bit, prefetchable) [size=64K] Bus: primary=0a, secondary=0b, subordinate=0b, sec-latency=0 Memory behind bridge: eac00000-ebefffff BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0+,D1+,D2-,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME+ Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [60] #10 [0071] 0b:00.0 Class ff00: C-PORT Corp: Unknown device 0002 (rev 20) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 128 Interrupt: pin A routed to IRQ 51 Region 0: Memory at ebe00000 (32-bit, prefetchable) [size=1M] Region 1: Memory at ebd00000 (32-bit, prefetchable) [size=1M] Region 2: Memory at eb800000 (32-bit, prefetchable) [size=4M] Region 3: Memory at eb400000 (32-bit, prefetchable) [size=4M] Region 4: Memory at eb000000 (32-bit, prefetchable) [size=4M] Region 5: Memory at eac00000 (32-bit, prefetchable) [size=4M] 0c:00.0 SCSI storage controller: Galileo Technology Ltd.: Unknown device 7042 (rev 02) Subsystem: Galileo Technology Ltd.: Unknown device 11ab Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, cache line size 08 Interrupt: pin A routed to IRQ 48 Region 0: Memory at eab00000 (64-bit, non-prefetchable) [size=1M] Region 2: I/O ports at 7ffff00 [size=256] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [60] #10 [0011] 0d:00.0 PCI bridge: PLX Technology, Inc.: Unknown device 8508 (rev aa) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Region 0: Memory at eaae0000 (32-bit, non-prefetchable) [size=128K] Bus: primary=0d, secondary=0e, subordinate=0f, sec-latency=0 I/O behind bridge: 07ffe000-07ffefff Memory behind bridge: ea900000-ea9fffff BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [68] #10 [0051] 0e:01.0 PCI bridge: PLX Technology, Inc.: Unknown device 8508 (rev aa) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Bus: primary=0e, secondary=0f, subordinate=0f, sec-latency=0 I/O behind bridge: 07ffe000-07ffefff Memory behind bridge: ea900000-ea9fffff BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [68] #10 [0161] 0f:00.0 Fibre Channel: QLogic Corp.: Unknown device 2432 (rev 02) Subsystem: QLogic Corp.: Unknown device 0137 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 50 Region 0: I/O ports at 7ffef00 [size=256] Region 1: Memory at ea9fc000 (64-bit, non-prefetchable) [size=16K] Expansion ROM at <unassigned> [disabled] [size=256K] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [4c] #10 [0001] Capabilities: [64] Message Signalled Interrupts: 64bit+ Queue=0/4 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [74] Vital Product Data Capabilities: [7c] #11 [000f] -bash-2.05b# -----Original Message----- From: Mark Lord [mailto:liml@rtr.ca] Sent: Wednesday, November 14, 2007 1:31 PM To: Morrison, Tom Cc: Jeff Garzik; linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: 2.6.23.1 - sata_mv (7042) hang with large file operations Morrison, Tom wrote: .. > ::: Can you give me exact details of how to set up and reproduce this? > ::: -- Kernel version > > Linux-2.6.23.1 > > NOTE: I am using ppc (arch/ppc instead of arch/powerpc) .. Okay. Is that 32-bit or 64-bit? How much RAM ? My PPC machine is not currently set up for Linux, and has only PCIX (not PCIe) slots, so I'll try this first on an x86-32 box with PCIe. If it works for me there, then I may be able to try a PCIX card in my PPC-32 box later. The PCIX card won't have a 7042 of course, so I'll use a 6081 instead. Those earlier Marvell chips are supposed to be extremely similar. > > ::: -- number/config/model of drives > > 2x250GIG Western Digital - 3 partitions (largest (/dev/sda3 > ~200Gig - formatted to ext2). > > 7042 PEX on a MPC8548 Board > > ::: -- exact command line sequence to cause the failure > > NFS mount root file system (I am currently rebuild to take away > the NFS file system dependency) - /dev/sda3 is drive in > question... > > a) mount /dev/sda3 /mnt/src > b) cp large_500Meg_file /mnt/src/. > > ========================================================== > ========================================================== > NOTE: this does NOT fail on a 2.6.11 kernel version!!!! > So I do NOT think it's a hardware problem! > > It could be a PEX related problem with arch/ppc - I would > expect under heavy pounding with smaller files it would > fail as well - but it does NOT) > ========================================================== > ========================================================== > > Anything else you need to know? > > - > To unsubscribe from this list: send the line "unsubscribe linux-ide" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-11-14 18:09 ` Morrison, Tom 2007-11-14 18:30 ` Mark Lord @ 2007-11-14 18:37 ` Mark Lord 2007-11-14 18:56 ` Mark Lord 2 siblings, 0 replies; 21+ messages in thread From: Mark Lord @ 2007-11-14 18:37 UTC (permalink / raw) To: Morrison, Tom; +Cc: Jeff Garzik, linux-ide, linux-kernel Morrison, Tom wrote: > -----Original Message----- > From: Mark Lord [mailto:liml@rtr.ca] > Sent: Wednesday, November 14, 2007 12:57 PM > To: Morrison, Tom > Cc: Jeff Garzik; linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: 2.6.23.1 - sata_mv (7042) hang with large file operations > > Morrison, Tom wrote: > <snip > >> The problem comes ONLY when I am doing large file operations >> (e.g.: just copying a file) to/from the SATA drives behind >> the subject line 7042....it just hangs after about 10-15 >> seconds into the copy... >> >> How large a file causes the hang - you ask - well, somewhere >> between 100Meg & 500Meg... .. Oh yeah, Can I also please see the output of: lspci -vv Thanks. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-11-14 18:09 ` Morrison, Tom 2007-11-14 18:30 ` Mark Lord 2007-11-14 18:37 ` Mark Lord @ 2007-11-14 18:56 ` Mark Lord 2007-11-14 21:12 ` Morrison, Tom 2 siblings, 1 reply; 21+ messages in thread From: Mark Lord @ 2007-11-14 18:56 UTC (permalink / raw) To: Morrison, Tom; +Cc: Jeff Garzik, linux-ide, linux-kernel Morrison, Tom wrote: > -----Original Message----- > From: Mark Lord [mailto:liml@rtr.ca] > Sent: Wednesday, November 14, 2007 12:57 PM > To: Morrison, Tom > Cc: Jeff Garzik; linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: 2.6.23.1 - sata_mv (7042) hang with large file operations > > Morrison, Tom wrote: > <snip > >> The problem comes ONLY when I am doing large file operations >> (e.g.: just copying a file) to/from the SATA drives behind >> the subject line 7042....it just hangs after about 10-15 >> seconds into the copy... >> >> How large a file causes the hang - you ask - well, somewhere >> between 100Meg & 500Meg... >> > <snip other drivel> > > > ::: Can you give me exact details of how to set up and reproduce this? > ::: -- Kernel version > > Linux-2.6.23.1 > > NOTE: I am using ppc (arch/ppc instead of arch/powerpc) > > ::: -- number/config/model of drives > > 2x250GIG Western Digital - 3 partitions (largest (/dev/sda3 > ~200Gig - formatted to ext2). > > 7042 PEX on a MPC8548 Board > > ::: -- exact command line sequence to cause the failure > > NFS mount root file system (I am currently rebuild to take away > the NFS file system dependency) - /dev/sda3 is drive in question... .. MMmm.. I'd like to see that again without the rootfs-on-NFS. What exactly do you mean when you say "it just hangs" ? Everything (dead system)? ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-11-14 18:56 ` Mark Lord @ 2007-11-14 21:12 ` Morrison, Tom 2007-11-14 22:29 ` Mark Lord 0 siblings, 1 reply; 21+ messages in thread From: Morrison, Tom @ 2007-11-14 21:12 UTC (permalink / raw) To: Mark Lord; +Cc: Jeff Garzik, linux-ide, linux-kernel I have gotten it to boot from those hard-drives and it has the same behavior: Copying a large file to the same partition (>150MEG) causes the system to hang (no I/O - no input/output - nothing - complete freeze - like a primary resource is locked up or interrupts got completely & totally turned off in an ISR and its pending for something? Only way to get out of this is to power-cycle the box! @#$@#$#@ -----Original Message----- > ::: Can you give me exact details of how to set up and reproduce this? > ::: -- Kernel version > > Linux-2.6.23.1 > > NOTE: I am using ppc (arch/ppc instead of arch/powerpc) > > ::: -- number/config/model of drives > > 2x250GIG Western Digital - 3 partitions (largest (/dev/sda3 > ~200Gig - formatted to ext2). > > 7042 PEX on a MPC8548 Board > > ::: -- exact command line sequence to cause the failure > > NFS mount root file system (I am currently rebuild to take away > the NFS file system dependency) - /dev/sda3 is drive in question... .. MMmm.. I'd like to see that again without the rootfs-on-NFS. What exactly do you mean when you say "it just hangs" ? Everything (dead system)? - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-11-14 21:12 ` Morrison, Tom @ 2007-11-14 22:29 ` Mark Lord 2007-11-14 22:31 ` Mark Lord ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Mark Lord @ 2007-11-14 22:29 UTC (permalink / raw) To: Morrison, Tom; +Cc: Jeff Garzik, linux-ide, linux-kernel Morrison, Tom wrote: > I have gotten it to boot from those hard-drives and it > has the same behavior: > > Copying a large file to the same partition (>150MEG) > causes the system to hang (no I/O - no input/output - > nothing - complete freeze - like a primary resource > is locked up or interrupts got completely & totally > turned off in an ISR and its pending for something? > > Only way to get out of this is to power-cycle the box! .. Okay, a couple of things: Do this from a text console, not a GUI. And preferably without ever starting klogd/syslogd during init. That way you've a much better chance of seeing some kernel diagnostic messages when it locks up. Can you boot with "nomsi" kernel parameter? And I guess we'll need to see the entire kernel .config as well. This is a tricky one. The driver behaves fine for me here with a 7042 rev.2 on PCIe in my x86-32 box. Cheers ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-11-14 22:29 ` Mark Lord @ 2007-11-14 22:31 ` Mark Lord 2007-11-15 15:43 ` Morrison, Tom 2007-11-15 16:26 ` Morrison, Tom 2 siblings, 0 replies; 21+ messages in thread From: Mark Lord @ 2007-11-14 22:31 UTC (permalink / raw) To: Morrison, Tom; +Cc: Jeff Garzik, linux-ide, linux-kernel Mark Lord wrote: > Morrison, Tom wrote: >> I have gotten it to boot from those hard-drives and it has the same >> behavior: >> >> Copying a large file to the same partition (>150MEG) >> causes the system to hang (no I/O - no input/output - nothing - >> complete freeze - like a primary resource is locked up or >> interrupts got completely & totally turned off in an ISR and its >> pending for something? >> >> Only way to get out of this is to power-cycle the box! > .. > > Okay, a couple of things: > > Do this from a text console, not a GUI. > And preferably without ever starting klogd/syslogd during init. > > That way you've a much better chance of seeing some kernel diagnostic > messages when it locks up. > > Can you boot with "nomsi" kernel parameter? > And I guess we'll need to see the entire kernel .config as well. ... And also a copy of the full kernel log messages from boot up until just before you run the lockup sequence. Thanks ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-11-14 22:29 ` Mark Lord 2007-11-14 22:31 ` Mark Lord @ 2007-11-15 15:43 ` Morrison, Tom 2007-11-15 16:26 ` Morrison, Tom 2 siblings, 0 replies; 21+ messages in thread From: Morrison, Tom @ 2007-11-15 15:43 UTC (permalink / raw) To: Mark Lord; +Cc: Jeff Garzik, linux-ide, linux-kernel I have a console - and have booted with "pci=nomsi" and the behavior is ~the same or even a little worse in some case (but not by much)... I will send kernel log & the .config file separately to you... (quite long)... Further, you should note that my arch/ppc does NOT have MSI Capability (CONFIG_PCI_MSI) - thus I think this might be Is there any debugging I can turn on in the proc or sysfs? that might give more clues (e.g.: /proc/sys/dev/scsi/logging_level)? t -----Original Message----- From: Mark Lord [mailto:liml@rtr.ca] Sent: Wednesday, November 14, 2007 5:30 PM To: Morrison, Tom Cc: Jeff Garzik; linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: 2.6.23.1 - sata_mv (7042) hang with large file operations Morrison, Tom wrote: > I have gotten it to boot from those hard-drives and it > has the same behavior: > > Copying a large file to the same partition (>150MEG) > causes the system to hang (no I/O - no input/output - > nothing - complete freeze - like a primary resource > is locked up or interrupts got completely & totally > turned off in an ISR and its pending for something? > > Only way to get out of this is to power-cycle the box! .. Okay, a couple of things: Do this from a text console, not a GUI. And preferably without ever starting klogd/syslogd during init. That way you've a much better chance of seeing some kernel diagnostic messages when it locks up. Can you boot with "nomsi" kernel parameter? And I guess we'll need to see the entire kernel .config as well. This is a tricky one. The driver behaves fine for me here with a 7042 rev.2 on PCIe in my x86-32 box. Cheers ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-11-14 22:29 ` Mark Lord 2007-11-14 22:31 ` Mark Lord 2007-11-15 15:43 ` Morrison, Tom @ 2007-11-15 16:26 ` Morrison, Tom 2007-11-15 16:39 ` Mark Lord 2 siblings, 1 reply; 21+ messages in thread From: Morrison, Tom @ 2007-11-15 16:26 UTC (permalink / raw) To: Mark Lord; +Cc: Jeff Garzik, linux-ide, linux-kernel Additional information - the ~file size this is caused is somewhere close to 260Mbytesfiles. If I create a ~260Mbytes file - my program finishes creating the file - but ~5 seconds later (I timed this by hitting enter on the console every second after completion of the command that should have done a fsync of the created file before exiting)... It hangs... I did a little playing around with /proc/sys/dev/scsi/logging_level (set to 0x7) - and it seems that the kernel/box locks up after this line: >> scsi_add_timer: scmd: efca83c0, time: 7500, (c0160660) >> scsi_delete_timer: scmd: efca83c0, rtn: 1 >> scsi_add_timer: scmd: efca8840, time: 7500, (c0160660) Further analysis (setting logging level to 65535 (0xFFFF) Has the following behavior down low) - >> scsi_add_timer: scmd: efca8960, time: 7500, (c0160660) >> sd 0:0:0:0: [sda] Send: 0xefca8960 >> sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 92 27 00 01 48 00 >> buffer = 0xc0553040, bufflen = 167936, done = 0xc016b194, queuecommand 0xc017ed34 >> leaving scsi_dispatch_cmnd() >> scsi_delete_timer: scmd: efca8960, rtn: 1 >> sd 0:0:0:0: [sda] Done: 0xefca8960 SUCCESS >> sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK >> sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 92 27 00 01 48 00 >> sd 0:0:0:0: [sda] scsi host busy 1 failed 0 >> sd 0:0:0:0: Notifying upper driver of completion (result 0) >> >> scsi_add_timer: scmd: efca82a0, time: 7500, (c0160660) >> sd 0:0:0:0: [sda] Send: 0xefca82a0 >> sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 93 6f 00 02 40 00 >> buffer = 0xef5734c0, bufflen = 294912, done = 0xc016b194, queuecommand 0xc017ed34 >> leaving scsi_dispatch_cmnd() Nothing more - it hangs! This is really a nasty problem!!!! ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-11-15 16:26 ` Morrison, Tom @ 2007-11-15 16:39 ` Mark Lord 2007-11-15 21:46 ` Morrison, Tom 0 siblings, 1 reply; 21+ messages in thread From: Mark Lord @ 2007-11-15 16:39 UTC (permalink / raw) To: Morrison, Tom; +Cc: Jeff Garzik, linux-ide, linux-kernel Morrison, Tom wrote: > Additional information - the ~file size this is caused > is somewhere close to 260Mbytesfiles. > > If I create a ~260Mbytes file - my program finishes creating > the file - but ~5 seconds later (I timed this by hitting enter > on the console every second after completion of the command > that should have done a fsync of the created file before exiting)... > It hangs... > > I did a little playing around with /proc/sys/dev/scsi/logging_level > (set to 0x7) - and it seems that the kernel/box locks up after > this line: > >>> scsi_add_timer: scmd: efca83c0, time: 7500, (c0160660) >>> scsi_delete_timer: scmd: efca83c0, rtn: 1 >>> scsi_add_timer: scmd: efca8840, time: 7500, (c0160660) > > > Further analysis (setting logging level to 65535 (0xFFFF) > Has the following behavior down low) - > >>> scsi_add_timer: scmd: efca8960, time: 7500, (c0160660) >>> sd 0:0:0:0: [sda] Send: 0xefca8960 >>> sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 92 27 00 01 48 00 >>> buffer = 0xc0553040, bufflen = 167936, done = 0xc016b194, > queuecommand > 0xc017ed34 >>> leaving scsi_dispatch_cmnd() >>> scsi_delete_timer: scmd: efca8960, rtn: 1 >>> sd 0:0:0:0: [sda] Done: 0xefca8960 SUCCESS >>> sd 0:0:0:0: [sda] Result: hostbyte=DID_OK > driverbyte=DRIVER_OK,SUGGEST_OK >>> sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 92 27 00 01 48 00 >>> sd 0:0:0:0: [sda] scsi host busy 1 failed 0 >>> sd 0:0:0:0: Notifying upper driver of completion (result 0) >>> >>> scsi_add_timer: scmd: efca82a0, time: 7500, (c0160660) >>> sd 0:0:0:0: [sda] Send: 0xefca82a0 >>> sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 93 6f 00 02 40 00 >>> buffer = 0xef5734c0, bufflen = 294912, done = 0xc016b194, > queuecommand > 0xc017ed34 >>> leaving scsi_dispatch_cmnd() > > Nothing more - it hangs! > > This is really a nasty problem!!!! .. Yes. It's particularly nasty because, as of yet, I haven't seen anything to lead me to conclude *which* kernel subsystem is locking up. It could be the block layer. It could be some PPC arch bug. It could be mm. It could even be the CPU scheduler. Those messages above could help. Now we just need somebody to interpret them, and examine the code paths that follow to see where it might be possible to get stuck. The SCSI/libata layers by themselves could lock up the I/O, but not the entire machine.. Cheers ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-11-15 16:39 ` Mark Lord @ 2007-11-15 21:46 ` Morrison, Tom 2007-11-15 22:14 ` Mark Lord 0 siblings, 1 reply; 21+ messages in thread From: Morrison, Tom @ 2007-11-15 21:46 UTC (permalink / raw) To: Mark Lord; +Cc: Jeff Garzik, linux-ide, linux-kernel The plot thickens - it looks like it might be some type of problem interacting with the setup of my 4Gig DDR memory and how I setup some translation windows in my MPC8548E I realized this morning that I have an inbound/ output PEX window Translation Setup for mapping all from/to PEX bus to outside the physical 4GIG memory space (i.e.: up at 0xC_xxxx_xxxx). Thus, all output operations that translation from 0xC_xxxx_xxxx to the pci 32 bit address of xxxx_xxxx) - and vice versa for for the inbound. Note: we also have a straight 1:1 translation mapping as well for the lower 4Gig - so that's why this worked without the below mentioned change... So, I changed the Request & Response Hi Addresses (which were Being shifted by 32 bits down anyways) and 'OR' that with my 0xC (so the effective 64bit DMA address is 0xC_xxxx_xxxx (where Xxxx_xxxx is the effective address). This was what we did to solve the problem with the Marvel Linux driver that we got from the Marvel site.... This all works just fine with ONLY 2 gig of memory in the system (and still have these inbound/output pex translation windows), but fails when I put back the 4 Gig (and the 8Gig) DDR memory. Unfortunately, this still hasn't solved the problem though - so there is something else which I am not seeing? I have a couple more ideas - but this is a toughy -----Original Message----- Morrison, Tom wrote: > Additional information - the ~file size this is caused > is somewhere close to 260Mbytesfiles. > > If I create a ~260Mbytes file - my program finishes creating > the file - but ~5 seconds later (I timed this by hitting enter > on the console every second after completion of the command > that should have done a fsync of the created file before exiting)... > It hangs... > > I did a little playing around with /proc/sys/dev/scsi/logging_level > (set to 0x7) - and it seems that the kernel/box locks up after > this line: > >>> scsi_add_timer: scmd: efca83c0, time: 7500, (c0160660) >>> scsi_delete_timer: scmd: efca83c0, rtn: 1 >>> scsi_add_timer: scmd: efca8840, time: 7500, (c0160660) > > > Further analysis (setting logging level to 65535 (0xFFFF) > Has the following behavior down low) - > >>> scsi_add_timer: scmd: efca8960, time: 7500, (c0160660) >>> sd 0:0:0:0: [sda] Send: 0xefca8960 >>> sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 92 27 00 01 48 00 >>> buffer = 0xc0553040, bufflen = 167936, done = 0xc016b194, > queuecommand > 0xc017ed34 >>> leaving scsi_dispatch_cmnd() >>> scsi_delete_timer: scmd: efca8960, rtn: 1 >>> sd 0:0:0:0: [sda] Done: 0xefca8960 SUCCESS >>> sd 0:0:0:0: [sda] Result: hostbyte=DID_OK > driverbyte=DRIVER_OK,SUGGEST_OK >>> sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 92 27 00 01 48 00 >>> sd 0:0:0:0: [sda] scsi host busy 1 failed 0 >>> sd 0:0:0:0: Notifying upper driver of completion (result 0) >>> >>> scsi_add_timer: scmd: efca82a0, time: 7500, (c0160660) >>> sd 0:0:0:0: [sda] Send: 0xefca82a0 >>> sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 93 6f 00 02 40 00 >>> buffer = 0xef5734c0, bufflen = 294912, done = 0xc016b194, > queuecommand > 0xc017ed34 >>> leaving scsi_dispatch_cmnd() > > Nothing more - it hangs! > > This is really a nasty problem!!!! .. Yes. It's particularly nasty because, as of yet, I haven't seen anything to lead me to conclude *which* kernel subsystem is locking up. It could be the block layer. It could be some PPC arch bug. It could be mm. It could even be the CPU scheduler. Those messages above could help. Now we just need somebody to interpret them, and examine the code paths that follow to see where it might be possible to get stuck. The SCSI/libata layers by themselves could lock up the I/O, but not the entire machine.. Cheers ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-11-15 21:46 ` Morrison, Tom @ 2007-11-15 22:14 ` Mark Lord 2007-11-16 0:07 ` Morrison, Tom ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Mark Lord @ 2007-11-15 22:14 UTC (permalink / raw) To: Morrison, Tom; +Cc: Jeff Garzik, linux-ide, linux-kernel Morrison, Tom wrote: > The plot thickens - it looks like it might be some type > of problem interacting with the setup of my 4Gig DDR memory > and how I setup some translation windows in my MPC8548E > > I realized this morning that I have an inbound/ output PEX window > Translation Setup for mapping all from/to PEX bus to outside > the physical 4GIG memory space (i.e.: up at 0xC_xxxx_xxxx). Thus, > all output operations that translation from 0xC_xxxx_xxxx to > the pci 32 bit address of xxxx_xxxx) - and vice versa for for > the inbound. Note: we also have a straight 1:1 translation mapping > as well for the lower 4Gig - so that's why this worked without > the below mentioned change... > > So, I changed the Request & Response Hi Addresses (which were > Being shifted by 32 bits down anyways) and 'OR' that with my > 0xC (so the effective 64bit DMA address is 0xC_xxxx_xxxx (where > Xxxx_xxxx is the effective address). This was what we did to > solve the problem with the Marvel Linux driver that we got from > the Marvel site.... > > This all works just fine with ONLY 2 gig of memory in the system > (and still have these inbound/output pex translation windows), > but fails when I put back the 4 Gig (and the 8Gig) DDR memory. > > Unfortunately, this still hasn't solved the problem though - > so there is something else which I am not seeing? .. I don't know much about how 32-bit PPC deals with memory addresses that are more than 32-bits.. But does this patch have any effect: --- old/drivers/ata/sata_mv.c 2007-10-12 12:43:44.000000000 -0400 +++ linux/drivers/ata/sata_mv.c 2007-11-15 17:12:24.000000000 -0500 @@ -685,7 +685,7 @@ { int rc; - if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { + if (0 && !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { rc = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK); if (rc) { rc = pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK); ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-11-15 22:14 ` Mark Lord @ 2007-11-16 0:07 ` Morrison, Tom 2007-11-16 13:00 ` Morrison, Tom 2007-11-16 17:07 ` Morrison, Tom 2 siblings, 0 replies; 21+ messages in thread From: Morrison, Tom @ 2007-11-16 0:07 UTC (permalink / raw) To: Mark Lord; +Cc: Jeff Garzik, linux-ide, linux-kernel In the case of PCI (am no big expert on this)- I believe the code allows you to address 32 bits at a time...you can see the the effectve address resource address is some where around 0xea900000 - but, if you have PHYS_64BIT & PTE_64BIT - you get resource_types of 64bits...that you can manipulate accordingly. In the case of the eDMA - its 64bit dma operations - thus, you setup the hi portion (by shifting twice by 16 (you get compiler warnings if you try to shiftg the size of the offset - a bug IMHO)) and thus, can play the game I mentioned below and use the power of the PEX inbound/outbound translation windows to move your data correctly to the appropriate 32 bit location... This game works fine very well for 2.6.11 + kernel - there are a few more tests I need to do (like setting mem=<just below the PEX space> and see if it works correctly...and then try again just a little bit above PEX memory space (> ~0xea900000) - if it works below & doesn't work above - it points to a problem with sata_mv doing some type of operation outside the dma engine that is corrupting memory - Thats another issue how does memory dribble/scribbling (only side affect I can think of if something is going wrong with this translation)? I'll try your 'patch' and see if that has any affect as well (and the associated side-affects...) t ________________________________ From: Mark Lord [mailto:liml@rtr.ca] Sent: Thu 11/15/2007 5:14 PM To: Morrison, Tom Cc: Jeff Garzik; linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: 2.6.23.1 - sata_mv (7042) hang with large file operations Morrison, Tom wrote: > The plot thickens - it looks like it might be some type > of problem interacting with the setup of my 4Gig DDR memory > and how I setup some translation windows in my MPC8548E > > I realized this morning that I have an inbound/ output PEX window > Translation Setup for mapping all from/to PEX bus to outside > the physical 4GIG memory space (i.e.: up at 0xC_xxxx_xxxx). Thus, > all output operations that translation from 0xC_xxxx_xxxx to > the pci 32 bit address of xxxx_xxxx) - and vice versa for for > the inbound. Note: we also have a straight 1:1 translation mapping > as well for the lower 4Gig - so that's why this worked without > the below mentioned change... > > So, I changed the Request & Response Hi Addresses (which were > Being shifted by 32 bits down anyways) and 'OR' that with my > 0xC (so the effective 64bit DMA address is 0xC_xxxx_xxxx (where > Xxxx_xxxx is the effective address). This was what we did to > solve the problem with the Marvel Linux driver that we got from > the Marvel site.... > > This all works just fine with ONLY 2 gig of memory in the system > (and still have these inbound/output pex translation windows), > but fails when I put back the 4 Gig (and the 8Gig) DDR memory. > > Unfortunately, this still hasn't solved the problem though - > so there is something else which I am not seeing? .. I don't know much about how 32-bit PPC deals with memory addresses that are more than 32-bits.. But does this patch have any effect: --- old/drivers/ata/sata_mv.c 2007-10-12 12:43:44.000000000 -0400 +++ linux/drivers/ata/sata_mv.c 2007-11-15 17:12:24.000000000 -0500 @@ -685,7 +685,7 @@ { int rc; - if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { + if (0 && !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { rc = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK); if (rc) { rc = pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK); ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-11-15 22:14 ` Mark Lord 2007-11-16 0:07 ` Morrison, Tom @ 2007-11-16 13:00 ` Morrison, Tom 2007-11-16 17:07 ` Morrison, Tom 2 siblings, 0 replies; 21+ messages in thread From: Morrison, Tom @ 2007-11-16 13:00 UTC (permalink / raw) To: Mark Lord; +Cc: Jeff Garzik, linux-ide, linux-kernel This 'patch' did not work. I tried setting the physical mem to just below the va addresses the PEX is being assigned (0xea900000 (3753M) and everything works... I set it to just above - and it gets miscellaneous boot problems.... like binfmt problems when attempting to insmod a module at boot time ("runaway loop modprobe binfmt_????" (?=I forgot to write down #) - this was mem=3850M) or downright hanging after kernel has initialized and it says "freeing kernel memory" (i.e.: where it attempts to run init on the root harddrive). IMHO, this tells me that perhaps there is somewhere else in the sata_mv code that is either modifying / accessing edma registers or something like this - that just doesn't seem right! I am going to try to port forward the driver that I know works and see if there are still any problems...stay tuned! Tom -----Original Message----- From: Mark Lord [mailto:liml@rtr.ca] Sent: Thursday, November 15, 2007 5:14 PM To: Morrison, Tom Cc: Jeff Garzik; linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: 2.6.23.1 - sata_mv (7042) hang with large file operations Morrison, Tom wrote: > The plot thickens - it looks like it might be some type > of problem interacting with the setup of my 4Gig DDR memory > and how I setup some translation windows in my MPC8548E > > I realized this morning that I have an inbound/ output PEX window > Translation Setup for mapping all from/to PEX bus to outside > the physical 4GIG memory space (i.e.: up at 0xC_xxxx_xxxx). Thus, > all output operations that translation from 0xC_xxxx_xxxx to > the pci 32 bit address of xxxx_xxxx) - and vice versa for for > the inbound. Note: we also have a straight 1:1 translation mapping > as well for the lower 4Gig - so that's why this worked without > the below mentioned change... > > So, I changed the Request & Response Hi Addresses (which were > Being shifted by 32 bits down anyways) and 'OR' that with my > 0xC (so the effective 64bit DMA address is 0xC_xxxx_xxxx (where > Xxxx_xxxx is the effective address). This was what we did to > solve the problem with the Marvel Linux driver that we got from > the Marvel site.... > > This all works just fine with ONLY 2 gig of memory in the system > (and still have these inbound/output pex translation windows), > but fails when I put back the 4 Gig (and the 8Gig) DDR memory. > > Unfortunately, this still hasn't solved the problem though - > so there is something else which I am not seeing? .. I don't know much about how 32-bit PPC deals with memory addresses that are more than 32-bits.. But does this patch have any effect: --- old/drivers/ata/sata_mv.c 2007-10-12 12:43:44.000000000 -0400 +++ linux/drivers/ata/sata_mv.c 2007-11-15 17:12:24.000000000 -0500 @@ -685,7 +685,7 @@ { int rc; - if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { + if (0 && !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { rc = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK); if (rc) { rc = pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK); ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: 2.6.23.1 - sata_mv (7042) hang with large file operations 2007-11-15 22:14 ` Mark Lord 2007-11-16 0:07 ` Morrison, Tom 2007-11-16 13:00 ` Morrison, Tom @ 2007-11-16 17:07 ` Morrison, Tom 2 siblings, 0 replies; 21+ messages in thread From: Morrison, Tom @ 2007-11-16 17:07 UTC (permalink / raw) To: Mark Lord; +Cc: Jeff Garzik, linux-ide, linux-kernel Mark, I've ported the old sataMV driver (version 3.6) to the 2.6.23.1 kernel - and it works - no problems with a full mem=4000M (4Gig). The only problem with this is that it is MUCH slower than the sata_mv driver which - by this test - definitely has some bug/dependency that gets broken when the physical memory overlaps its memory I/O locations (and should be iomapped & dma mapped to a separate space up in 0xC_xxxx_xxxx)... Time to dig in and debug this driver! UGH! Tom -----Original Message----- From: Mark Lord [mailto:liml@rtr.ca] Sent: Thursday, November 15, 2007 5:14 PM To: Morrison, Tom Cc: Jeff Garzik; linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: 2.6.23.1 - sata_mv (7042) hang with large file operations Morrison, Tom wrote: > The plot thickens - it looks like it might be some type > of problem interacting with the setup of my 4Gig DDR memory > and how I setup some translation windows in my MPC8548E > > I realized this morning that I have an inbound/ output PEX window > Translation Setup for mapping all from/to PEX bus to outside > the physical 4GIG memory space (i.e.: up at 0xC_xxxx_xxxx). Thus, > all output operations that translation from 0xC_xxxx_xxxx to > the pci 32 bit address of xxxx_xxxx) - and vice versa for for > the inbound. Note: we also have a straight 1:1 translation mapping > as well for the lower 4Gig - so that's why this worked without > the below mentioned change... > > So, I changed the Request & Response Hi Addresses (which were > Being shifted by 32 bits down anyways) and 'OR' that with my > 0xC (so the effective 64bit DMA address is 0xC_xxxx_xxxx (where > Xxxx_xxxx is the effective address). This was what we did to > solve the problem with the Marvel Linux driver that we got from > the Marvel site.... > > This all works just fine with ONLY 2 gig of memory in the system > (and still have these inbound/output pex translation windows), > but fails when I put back the 4 Gig (and the 8Gig) DDR memory. > > Unfortunately, this still hasn't solved the problem though - > so there is something else which I am not seeing? .. <snip patch that has no affect> ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2007-11-16 17:10 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <BD261180E6D35F4D9D32F3E44FD3D901053E84BD@EMPBEDEX.empirix.com>
[not found] ` <45ED682A.9040408@garzik.org>
2007-10-31 15:41 ` Other Problems with Marvell Driver - 7042 (2.6.23) Morrison, Tom
2007-10-31 16:06 ` Jeff Garzik
2007-10-31 18:14 ` Update (Now a False Alarm) " Morrison, Tom
2007-11-14 17:49 ` 2.6.23.1 - sata_mv (7042) hang with large file operations Morrison, Tom
2007-11-14 17:56 ` Mark Lord
2007-11-14 18:09 ` Morrison, Tom
2007-11-14 18:30 ` Mark Lord
2007-11-14 20:12 ` Morrison, Tom
2007-11-14 18:37 ` Mark Lord
2007-11-14 18:56 ` Mark Lord
2007-11-14 21:12 ` Morrison, Tom
2007-11-14 22:29 ` Mark Lord
2007-11-14 22:31 ` Mark Lord
2007-11-15 15:43 ` Morrison, Tom
2007-11-15 16:26 ` Morrison, Tom
2007-11-15 16:39 ` Mark Lord
2007-11-15 21:46 ` Morrison, Tom
2007-11-15 22:14 ` Mark Lord
2007-11-16 0:07 ` Morrison, Tom
2007-11-16 13:00 ` Morrison, Tom
2007-11-16 17:07 ` Morrison, Tom
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox