All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marin Mitov <mitov@issp.bas.bg>
To: Unai Uribarri <unai.uribarri@optenet.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Workaround hardware bug addressing physical memory
Date: Thu, 15 Jul 2010 13:09:14 +0300	[thread overview]
Message-ID: <201007151309.14915.mitov@issp.bas.bg> (raw)
In-Reply-To: <3586320.70351279181306029.JavaMail.root@mail1-md.optenet.com>

On 15.7.2010, Unai Uribarri wrote:
> Thanks.
> ----- "Marin Mitov" <mitov@issp.bas.bg> wrote:
> 
> | On Wednesday, July 14, 2010 08:06:49 pm you wrote:
> | > ----- "Marin Mitov" <mitov@issp.bas.bg> wrote:
> | > 
> | > | Hi,
> | > | 
> | > | This is pci driver. You can set dma mask:
> | > | 
> | > | dma_set_coheren_mask(pdev, DMA_BIT_MASK(31)) 
> | > | 
> | > | All further alloc_coherent() should be from the region 0-2GB.
> | > | 
> | > 
> | > But I'm using a 64 bit operating system with 32GB of RAM. It's a
> | > pity to be unable to use 4GB-32GB range because the 2-4GB range is
> | > unusable. So I've written this code to skip invalid areas. Do you
> | > think this code could be useful for other drivers?
> | 
> | Let me summarize if I have correctly understood what you do.
> | 
> | First, your hardware has problems when the physical (bus) address
> | is out of the 0-2GB region, so you cannot use buffers that are out 
> | of this range in any case. And the defect is in the peripheral, not in
> | the bridge between it and the memory.
> 
> The hardware works correctly for physical address in the ranges 0 to 2GB
> AND 4GB to 32GB. Physical address in the 2-4GB range are read correctly
> by the device. But when the device tries to write to them it issues 
> invalid PCIe transaction headers: it tries to access such addresses using
> a 64-bit transactions when the PCI Express standard mandates to use 32-bit
> transactions for memory addresses below 4GB. Some bridges accept such
> invalid transactions, but Intel 5500 chipset rejects them.
> 
> I'm allocating 256MB of RAM for I/O buffers; I'm fear that restricting all
> the allocations to the first 2GB of memory will put too much pressure in
> that zone of memory. But restricting it to 4GB and above will be okay. 
> 
> Is there any way to restrict to memory address above 4GB?

Would this work for you?
From: Documentation/kernel-parameters.txt:

	memmap=nn[KMG]$ss[KMG]
			[KNL,ACPI] Mark specific memory as reserved.
			Region of memory to be used, from ss to ss+nn.
			Example: Exclude memory from 0x18690000-0x1869ffff
			         memmap=64K$0x18690000
			         or
			         memmap=0x10000$0x18690000

Marin Mitov

  parent reply	other threads:[~2010-07-15 10:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <22092033.70271279181145173.JavaMail.root@mail1-md.optenet.com>
2010-07-15  8:08 ` Workaround hardware bug addressing physical memory Unai Uribarri
2010-07-15  8:56   ` Marin Mitov
2010-07-15 10:09   ` Marin Mitov [this message]
2010-07-15 16:46     ` Unai Uribarri
2010-07-15 16:57       ` Marin Mitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201007151309.14915.mitov@issp.bas.bg \
    --to=mitov@issp.bas.bg \
    --cc=linux-kernel@vger.kernel.org \
    --cc=unai.uribarri@optenet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.