* 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: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: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: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;
as well as URLs for NNTP newsgroup(s).