[patch 26/30] Support for Marvell 7042 Chip

[patch 26/30] Support for Marvell 7042 Chip

[akpm]

From: "Morrison, Tom" <tmorrison@empirix.com>

Added Support for Marvell 7042 Chip - 7042 has same capabilities & behavior
as 6042.

Signed-off-by: Thomas A. Morrison <tmorrison@empirix.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 drivers/ata/sata_mv.c |    3 +++
 1 file changed, 3 insertions(+)

diff -puN drivers/ata/sata_mv.c~support-for-marvell-7042-chip drivers/ata/sata_mv.c
--- a/drivers/ata/sata_mv.c~support-for-marvell-7042-chip
+++ a/drivers/ata/sata_mv.c
@@ -548,6 +548,9 @@ static const struct pci_device_id mv_pci
 
 	{ PCI_VDEVICE(TTI, 0x2310), chip_7042 },
 
+	/* add Marvell 7042 support */
+	{ PCI_VDEVICE(MARVELL, 0x7042), chip_7042 },
+
 	{ }			/* terminate list */
 };
 
_

Re: [patch 26/30] Support for Marvell 7042 Chip

[Jeff Garzik]

akpm@linux-foundation.org wrote:
> From: "Morrison, Tom" <tmorrison@empirix.com>
> 
> Added Support for Marvell 7042 Chip - 7042 has same capabilities & behavior
> as 6042.
> 
> Signed-off-by: Thomas A. Morrison <tmorrison@empirix.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  drivers/ata/sata_mv.c |    3 +++
>  1 file changed, 3 insertions(+)

applied, although it's questionable whether this works at all on PCI-Express

RE: [patch 26/30] Support for Marvell 7042 Chip

[Morrison, Tom]

I have tested with generic 2.6.20.2 on on x86 (XEON)
platform and a similiar (but not exactly same) 2.6.20.x 
(git tree from Freescale) for my target CPU: MPC8548E

Its exactly the same SATA chip - the only difference
between 7042 & 6042 is the PCI bridge interface.

In the case of 6042 - its a PCI to PCI Bridge
In the case of 7042 - its a PCI to PCI Express Bridge

I do not believe there is any other difference - except
the physical bus interface.

I should have 'said' this in the patch request...

Tom Morrison




-----Original Message-----
From: Jeff Garzik [mailto:jeff@garzik.org]
Sent: Tue 3/6/2007 7:01 AM
To: akpm@linux-foundation.org
Cc: linux-ide@vger.kernel.org; Morrison, Tom
Subject: Re: [patch 26/30] Support for Marvell 7042 Chip
 
akpm@linux-foundation.org wrote:
> From: "Morrison, Tom" <tmorrison@empirix.com>
> 
> Added Support for Marvell 7042 Chip - 7042 has same capabilities & behavior
> as 6042.
> 
> Signed-off-by: Thomas A. Morrison <tmorrison@empirix.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  drivers/ata/sata_mv.c |    3 +++
>  1 file changed, 3 insertions(+)

applied, although it's questionable whether this works at all on PCI-Express

Re: [patch 26/30] Support for Marvell 7042 Chip

[Jeff Garzik]

Morrison, Tom wrote:
> I have tested with generic 2.6.20.2 on on x86 (XEON)
> platform and a similiar (but not exactly same) 2.6.20.x 
> (git tree from Freescale) for my target CPU: MPC8548E
> 
> Its exactly the same SATA chip - the only difference
> between 7042 & 6042 is the PCI bridge interface.
> 
> In the case of 6042 - its a PCI to PCI Bridge
> In the case of 7042 - its a PCI to PCI Express Bridge
> 
> I do not believe there is any other difference - except
> the physical bus interface.
> 
> I should have 'said' this in the patch request...

Check the Marvell GPL driver and errata for the chip.  Grep for 'isPEX' 
to see all the PCI-Express-specific code and workarounds.  sata_mv does 
not have a lot of those, which was the reason why I only added the 6042 
PCI ID to the driver.

	Jeff

Other Problems with Marvell Driver - 7042 (2.6.23)...

[Morrison, Tom]

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.

Re: Other Problems with Marvell Driver - 7042 (2.6.23)...

[Jeff Garzik]

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

Update (Now a False Alarm) RE: Other Problems with Marvell Driver - 7042 (2.6.23)...

[Morrison, Tom]

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

2.6.23.1 - sata_mv (7042) hang with large file operations

[Morrison, Tom]

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

Re: 2.6.23.1 - sata_mv (7042) hang with large file operations

[Mark Lord]

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

RE: 2.6.23.1 - sata_mv (7042) hang with large file operations

[Morrison, Tom]

-----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?

Re: 2.6.23.1 - sata_mv (7042) hang with large file operations

[Mark Lord]

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

RE: 2.6.23.1 - sata_mv (7042) hang with large file operations

[Morrison, Tom]

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

Re: 2.6.23.1 - sata_mv (7042) hang with large file operations

[Mark Lord]

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.

Re: 2.6.23.1 - sata_mv (7042) hang with large file operations

[Mark Lord]

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)?

RE: 2.6.23.1 - sata_mv (7042) hang with large file operations

[Morrison, Tom]

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

Re: 2.6.23.1 - sata_mv (7042) hang with large file operations

[Mark Lord]

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

Re: 2.6.23.1 - sata_mv (7042) hang with large file operations

[Mark Lord]

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

RE: 2.6.23.1 - sata_mv (7042) hang with large file operations

[Morrison, Tom]

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

RE: 2.6.23.1 - sata_mv (7042) hang with large file operations

[Morrison, Tom]

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!!!!

Re: 2.6.23.1 - sata_mv (7042) hang with large file operations

[Mark Lord]

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
 

RE: 2.6.23.1 - sata_mv (7042) hang with large file operations

[Morrison, Tom]

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
 

Re: 2.6.23.1 - sata_mv (7042) hang with large file operations

[Mark Lord]

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);

RE: 2.6.23.1 - sata_mv (7042) hang with large file operations

[Morrison, Tom]

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);

RE: 2.6.23.1 - sata_mv (7042) hang with large file operations

[Morrison, Tom]

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);

RE: 2.6.23.1 - sata_mv (7042) hang with large file operations

[Morrison, Tom]

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>

Revisiting - 2.6.23.8 - Hang with sata_mv (7042) + Flat 4Gig (no holes) Memory

[Morrison, Tom]

Well, I thought my problems were solved with the latest set of
patches - and it definitely improved the behavior - but I have 
found out that it just delayed the problem - and I still get a 
soft lockup (no good info in the soft lockup trace) creating 
large (>300Meg) when using the sata_mv/7042 driver in 2.6.23.8

I am very embarrassed that I didn't do more testing before 
declaring victory...humbly apologies to all...

To re-state the problem....

Hardware/Configuration:
   MPC8548E with a 7042 (rev 2 - connected internal via a PEX switch) 
   2.6.23.8 (using PHYS_64BIT & PTE_64BIT - for 36 bit addressing
             & MSI is NOT compiled in)
   Flat 4Gig Memory Map (no holes - 0 - 0x0_FFFF_FFFF defined - special
 	                   low reserve memory is also used)

   Local Bus & PCI Express IOMem mapped to unique space in 
		0xC_xxxx_xxxx with extensions to the ioremap routines 
		to create the appropriate requested physical address...
		This is (and should be) transparent to the requesting 
		function that calls ioremap.
		
   2 SATA hard drives connected.

To recreate:
   Write a large file (now greater than >310Mbytes) - hangs
   and soft lockup is detected by kernel - no useful info 
   in stack trace...

Of interest:
   a) Replace sata_mv.c - with the 'old' Marvell's reference 
      driver and it works perfectly!!

   b) Also, sata_mv works perfectly in all conditions - if we boot with 
      less than the ~3750M from the command line (which I note is ~below

      where its PEX IOmemory space is located).


My thoughts (besides @#$@#$@#$#@#$@#)

	In the old Marvell reference driver - we had to modify 
	the EDMA setup to configure the dma_high request/response 
	addresses to point to the proper (0xC_xxxx_xxxx) location.
	No other modifications were required - so it's a little 
	confusing what is going on here.

	It is obvious from #b above that this has something to 
	do with accessing/reading/writing data to/from this chip,
	and when this happens - it scribbles on important internal
	information and/or gets into a confused state where it 
	just locks up...

Again, sorry for my inadequate testing reports before...and I look
forward
to anyone's input on this!

Sincerely,


Tom Morrison
Principal S/W Engineer
Empirix, Inc (www.empirix.com)
tmorrison@empirix.com
(781) 266 - 3567
 

RE: Revisiting - 2.6.23.8 - Hang with sata_mv (7042) + Flat 4Gig (no holes) Memory

[Morrison, Tom]

I'll try - it will take me a little while to get back to this - had to
reconfigure my target for a different test...more later~!

Tom


-----Original Message-----
From: Mark Lord [mailto:liml@rtr.ca] 
Sent: Monday, December 10, 2007 11:44 AM
To: Morrison, Tom
Cc: Jeff Garzik; linux-ide@vger.kernel.org; Tejun Heo; hp@syntomax.com
Subject: Re: Revisiting - 2.6.23.8 - Hang with sata_mv (7042) + Flat
4Gig (no holes) Memory

Morrison, Tom wrote:
..
> To re-state the problem....
> 
> Hardware/Configuration:
>    MPC8548E with a 7042 (rev 2 - connected internal via a PEX switch) 
>    2.6.23.8 (using PHYS_64BIT & PTE_64BIT - for 36 bit addressing
>              & MSI is NOT compiled in)
>    Flat 4Gig Memory Map (no holes - 0 - 0x0_FFFF_FFFF defined -
special
>  	                   low reserve memory is also used)
> 
>    Local Bus & PCI Express IOMem mapped to unique space in 
> 		0xC_xxxx_xxxx with extensions to the ioremap routines 
> 		to create the appropriate requested physical address...
> 		This is (and should be) transparent to the requesting 
> 		function that calls ioremap.
> 		
>    2 SATA hard drives connected.
> 
> To recreate:
>    Write a large file (now greater than >310Mbytes) - hangs
>    and soft lockup is detected by kernel - no useful info 
>    in stack trace...
> 
> Of interest:
>    a) Replace sata_mv.c - with the 'old' Marvell's reference 
>       driver and it works perfectly!!
> 
>    b) Also, sata_mv works perfectly in all conditions - if we boot
with 
>       less than the ~3750M from the command line (which I note is
~below
>       where its PEX IOmemory space is located).
..

Tom:  could you please try and follow the recent thread here (linux-ide)
entitled "Bug: get EXT3-fs error Allocating block in system zone".

Somebody there has a similar problem on x86-32 with RAM above 4GB
using a standard AHCI SATA controller.

Jens has posted a couple of debugging patches there to try and isolate
things.
(patches attached here for convenience, though you'll have to
modify/hack
 the first one for sata_mv instead of ahci).

-ml

Responding to 2 thread <2.6.23.8 - Hang with sata_mv (7042)...> AND <Bug: get EXT3-fs error Allocating block in system zone>

[Morrison, Tom]

I am a little confused as to exactly what thread I am to respond to 
and/or what requests...but lets try this and see if I get close?

I have the <far> below mentioned hardware/configuration (flat 4Gig 
of DDR mem (0x0_000_0000 to 0x1_000_0000)...PPC/8548E - 36bit addressing

As can be seen below - Mark has asked me try patching my sata_mv 
(and scsi_lib) with some patches from the second thread in subject:

    1) Disable 64bit DMA in sata_mv (equivalent of the CAP_64 for 
       AHCI) and disabling the bounce:

    2) Disable queue bounce limit in drivers/scsi/scsi_lib.c

+#if 0
         blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
+#endif

Mark had already asked me to try #1 a while back - and that didn't work.
So, I tried #2 - and now it doesn't hang for me went writing a large 
File (which was my error condition)...

So, as Linux suggested in his email, it looks like something 
is wrong in the bounce buffering? What - somebody will have
to look into this further...

Is that enough info Mark - let me know what you else you want me 
to try with my setup...

Tom

-----Original Message-----
From: Mark Lord [mailto:liml@rtr.ca] 
Sent: Monday, December 10, 2007 11:44 AM
To: Morrison, Tom
Cc: Jeff Garzik; linux-ide@vger.kernel.org; Tejun Heo; hp@syntomax.com
Subject: Re: Revisiting - 2.6.23.8 - Hang with sata_mv (7042) + Flat
4Gig (no holes) Memory

Morrison, Tom wrote:
..
> To re-state the problem....
> 
> Hardware/Configuration:
>    MPC8548E with a 7042 (rev 2 - connected internal via a PEX switch) 
>    2.6.23.8 (using PHYS_64BIT & PTE_64BIT - for 36 bit addressing
>              & MSI is NOT compiled in)
>    Flat 4Gig Memory Map (no holes - 0 - 0x0_FFFF_FFFF defined -
special
>  	                   low reserve memory is also used)
> 
>    Local Bus & PCI Express IOMem mapped to unique space in 
> 		0xC_xxxx_xxxx with extensions to the ioremap routines 
> 		to create the appropriate requested physical address...
> 		This is (and should be) transparent to the requesting 
> 		function that calls ioremap.
> 		
>    2 SATA hard drives connected.
> 
> To recreate:
>    Write a large file (now greater than >310Mbytes) - hangs
>    and soft lockup is detected by kernel - no useful info 
>    in stack trace...
> 
> Of interest:
>    a) Replace sata_mv.c - with the 'old' Marvell's reference 
>       driver and it works perfectly!!
> 
>    b) Also, sata_mv works perfectly in all conditions - if we boot
with 
>       less than the ~3750M from the command line (which I note is
~below
>       where its PEX IOmemory space is located).
..

Tom:  could you please try and follow the recent thread here (linux-ide)
entitled " Bug: get EXT3-fs error Allocating block in system zone ".

Somebody there has a similar problem on x86-32 with RAM above 4GB
using a standard AHCI SATA controller.

Jens has posted a couple of debugging patches there to try and isolate
things.
(patches attached here for convenience, though you'll have to
modify/hack
 the first one for sata_mv instead of ahci).

-ml

Re: Responding to 2 thread <2.6.23.8 - Hang with sata_mv (7042)...> AND <Bug: get EXT3-fs error Allocating block in system zone>

[Mark Lord]

Morrison, Tom wrote:
> I am a little confused as to exactly what thread I am to respond to 
> and/or what requests...but lets try this and see if I get close?
> 
> I have the <far> below mentioned hardware/configuration (flat 4Gig 
> of DDR mem (0x0_000_0000 to 0x1_000_0000)...PPC/8548E - 36bit addressing
> 
> As can be seen below - Mark has asked me try patching my sata_mv 
> (and scsi_lib) with some patches from the second thread in subject:
> 
>     1) Disable 64bit DMA in sata_mv (equivalent of the CAP_64 for 
>        AHCI) and disabling the bounce:
> 
>     2) Disable queue bounce limit in drivers/scsi/scsi_lib.c
> 
> +#if 0
>          blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
> +#endif
> 
> Mark had already asked me to try #1 a while back - and that didn't work.
> So, I tried #2 - and now it doesn't hang for me went writing a large 
> File (which was my error condition)...
> 
> So, as Linus suggested in his email, it looks like something 
> is wrong in the bounce buffering? What - somebody will have
> to look into this further...
..

That's a bit strange, actually.. because you said that this system
does not have any RAM at any addresses above 0xffffffff.
The physical RAM in this system is supposedly from 0 - 0xffffffff (4Gbytes).

????

> -----Original Message-----
> From: Mark Lord [mailto:liml@rtr.ca] 
> Sent: Monday, December 10, 2007 11:44 AM
> To: Morrison, Tom
> Cc: Jeff Garzik; linux-ide@vger.kernel.org; Tejun Heo; hp@syntomax.com
> Subject: Re: Revisiting - 2.6.23.8 - Hang with sata_mv (7042) + Flat
> 4Gig (no holes) Memory
> 
> Morrison, Tom wrote:
> ..
>> To re-state the problem....
>>
>> Hardware/Configuration:
>>    MPC8548E with a 7042 (rev 2 - connected internal via a PEX switch) 
>>    2.6.23.8 (using PHYS_64BIT & PTE_64BIT - for 36 bit addressing
>>              & MSI is NOT compiled in)
>>    Flat 4Gig Memory Map (no holes - 0 - 0x0_FFFF_FFFF defined -
> special
>>  	                   low reserve memory is also used)
>>
>>    Local Bus & PCI Express IOMem mapped to unique space in 
>> 		0xC_xxxx_xxxx with extensions to the ioremap routines 
>> 		to create the appropriate requested physical address...
>> 		This is (and should be) transparent to the requesting 
>> 		function that calls ioremap.
>> 		
>>    2 SATA hard drives connected.
>>
>> To recreate:
>>    Write a large file (now greater than >310Mbytes) - hangs
>>    and soft lockup is detected by kernel - no useful info 
>>    in stack trace...
>>
>> Of interest:
>>    a) Replace sata_mv.c - with the 'old' Marvell's reference 
>>       driver and it works perfectly!!
>>
>>    b) Also, sata_mv works perfectly in all conditions - if we boot
> with 
>>       less than the ~3750M from the command line (which I note is
> ~below
>>       where its PEX IOmemory space is located).
> ..
> 
> Tom:  could you please try and follow the recent thread here (linux-ide)
> entitled " Bug: get EXT3-fs error Allocating block in system zone ".
> 
> Somebody there has a similar problem on x86-32 with RAM above 4GB
> using a standard AHCI SATA controller.
> 
> Jens has posted a couple of debugging patches there to try and isolate
> things.
> (patches attached here for convenience, though you'll have to
> modify/hack
>  the first one for sata_mv instead of ahci).
> 
> -ml
> 
> -
> 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

RE: Responding to 2 thread <2.6.23.8 - Hang with sata_mv (7042)...> AND <Bug: get EXT3-fs error Allocating block in system zone>

[Morrison, Tom]

Correct, it has a flat memory map 0-0xFFFFFFFF

I don't make this stuff up and I checked it 3 times 
(with & without this set (#if 0 & #if 1) - just to make 
sure I don't have something else weird going on...

I'll send you privately my sata_mv.c - so you can inspect
that yourself (only custom thing is the EDMA buffers hi/low
buffers are set to point to the physical PCI space which is 
way up in 0xC_xxxx_xxxx space...

tom


-----Original Message-----
From: Mark Lord [mailto:liml@rtr.ca] 
Sent: Tuesday, December 11, 2007 12:42 PM
To: Morrison, Tom
Cc: Jeff Garzik; linux-ide@vger.kernel.org; Tejun Heo; hp@syntomax.com
Subject: Re: Responding to 2 thread <2.6.23.8 - Hang with sata_mv
(7042)...> AND <Bug: get EXT3-fs error Allocating block in system zone>

Morrison, Tom wrote:
>> <snip results that worked>
>> That's a bit strange, actually.. because you said that this system
>>does not have any RAM at any addresses above 0xffffffff.
>> The physical RAM in this system is supposedly from 0 - 0xffffffff
(4Gbytes).

<snip original question>