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@xxxxxx]
Sent: Monday, December 10, 2007 11:44 AM
To: Morrison, Tom
Cc: Jeff Garzik; linux-ide@xxxxxxxxxxxxxxx; Tejun Heo; hp@xxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
