public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Xavier Bru <xavier.bru@bull.net>
To: linux-ia64@vger.kernel.org
Subject: Re: Problem booting Adaptec Ultra 320 driver with discontigmem support.
Date: Thu, 04 Dec 2003 13:01:01 +0000	[thread overview]
Message-ID: <marc-linux-ia64-107054297625370@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-107054139923799@msgid-missing>

Sorry, this was the old one, this one should be better (use blk_max_pfn 
instead of blk_max_low_pfn):

--- linux-2.6.0-test11/drivers/scsi/aic7xxx/aic79xx_osm.c    2003-11-24 
02:32:03.000000000 +0100
+++ linux-2.6.0-test11.new/drivers/scsi/aic7xxx/aic79xx_osm.c    
2003-12-03 14:39:51.000000000 +0100
@@ -62,6 +62,7 @@
 
 #include <linux/mm.h>        /* For fetching system memory size */
 
+extern unsigned long blk_max_pfn;
 /*
  * Lock protecting manipulation of the ahd softc list.
  */
@@ -2158,10 +2159,9 @@
 uint64_t
 ahd_linux_get_memsize(void)
 {
-    struct sysinfo si;
-
-    si_meminfo(&si);
-    return ((uint64_t)si.totalram << PAGE_SHIFT);
+    /* Need to take in account the max physical address in case
+     * of discontiguous memory. */
+    return ((uint64_t)blk_max_pfn << PAGE_SHIFT);
 }
 
 /*


Xavier Bru a écrit :

> Hello, all
>
> Running  2.6.0-test11 with Adaptec Ultra 320 driver that provides full 
> 64-bit support
> we hit a BUG in blk_queue_bounce_limit() due to physical address 
> greater than allowed by the dma mask.
> Having a look into the code, it appears that the computation to allow 
> full 64-bit support takes in account the size of the installed memory 
> instead of the max physical address of the platform.
> For example on  a platform with 32GB of memory distributed in 1 TB 
> physical address space, only 39-bits physical addresses are supported 
> instead of the 40 bits needed.
>
> IOSAPIC: vector 54 -> CPU 0x04e0, enabled
> scsi0 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 1.3.9
>        <Adaptec 39320D Ultra320 SCSI adapter>
>        aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 
> 512 SCBs
>
> kernel BUG at drivers/block/ll_rw_blk.c:271!
> swapper[1]: bugcheck! 0 [1]
>
> Herafter a patch that fixes the problem:
>
> --- linux-2.6.0-test11/drivers/scsi/aic7xxx/aic79xx_osm.c    
> 2003-11-24 02:32:03.000000000 +0100
> +++ linux-2.6.0-test11.new/drivers/scsi/aic7xxx/aic79xx_osm.c    
> 2003-12-03 14:39:51.000000000 +0100
> @@ -62,6 +62,7 @@
>
> #include <linux/mm.h>        /* For fetching system memory size */
>
> +extern unsigned long blk_max_pfn;
> /*
>  * Lock protecting manipulation of the ahd softc list.
>  */
> @@ -2158,10 +2159,9 @@
> uint64_t
> ahd_linux_get_memsize(void)
> {
> -    struct sysinfo si;
> -
> -    si_meminfo(&si);
> -    return ((uint64_t)si.totalram << PAGE_SHIFT);
> +    /* Need to take in account the max physical address in case
> +     * of discontiguous memory. */
> +    return ((uint64_t)blk_max_low_pfn << PAGE_SHIFT);
> }
>
> /*
>


-- 

 Sincères salutations.
_____________________________________________________________________
 
Xavier BRU                 BULL ISD/R&D/INTEL office:     FREC B1-422
tel : +33 (0)4 76 29 77 45                    http://www-frec.bull.fr
fax : +33 (0)4 76 29 77 70                 mailto:Xavier.Bru@bull.net
addr: BULL, 1 rue de Provence, BP 208, 38432 Echirolles Cedex, FRANCE
_____________________________________________________________________



  reply	other threads:[~2003-12-04 13:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-04 12:37 Problem booting Adaptec Ultra 320 driver with discontigmem support Xavier Bru
2003-12-04 13:01 ` Xavier Bru [this message]
2003-12-04 13:11 ` Christoph Hellwig
2003-12-04 19:04 ` Grant Grundler
2003-12-05  7:21 ` Xavier Bru

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=marc-linux-ia64-107054297625370@msgid-missing \
    --to=xavier.bru@bull.net \
    --cc=linux-ia64@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox