Problem booting Adaptec Ultra 320 driver with discontigmem support.

Problem booting Adaptec Ultra 320 driver with discontigmem support.

[Xavier Bru]

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
_____________________________________________________________________

Re: Problem booting Adaptec Ultra 320 driver with discontigmem support.

[Xavier Bru]

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
_____________________________________________________________________

Re: Problem booting Adaptec Ultra 320 driver with discontigmem support.

[Christoph Hellwig]

On Thu, Dec 04, 2003 at 01:37:21PM +0100, Xavier Bru wrote:
> 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.

Still the wrong thing to do.  It should just check sizeof(dma_addr_t), that
the only sane check.

Re: Problem booting Adaptec Ultra 320 driver with discontigmem support.

[Grant Grundler]

On Thu, Dec 04, 2003 at 01:37:21PM +0100, Xavier Bru wrote:
> 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.

Can the driver provide "full 64-bit support" if it's setting
the dma mask to something less than 64-bits?
Did you mean "full 40-bits DMA support"?

grant

Re: Problem booting Adaptec Ultra 320 driver with discontigmem support.

[Xavier Bru]

The driver dynamically tests the size of the memory and sets the 
appropriate dma_mask to: 32, 39 or 64 bits (probably dues to historical 
reasons).
Problem is that with 32 GB of memory installed in a 1 TB physical 
address space the 39 bit mask is used instead
of the 64-bit mask.

-- 

 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
_____________________________________________________________________