Problem with ioremap which returns NULL in 2.6 kernel

Problem with ioremap which returns NULL in 2.6 kernel

[Markus Lidel]

Hello,

could someone help me with a ioremap problem. If there are two 
controllers plugged in, the ioremap request for the first controller is 
successfull, but the second returns NULL. Here is the output of the driver:

i2o: Checking for PCI I2O controllers...
i2o: I2O controller on bus 0 at 72.
i2o: PCI I2O controller at 0xD0000000 size=134217728
I2O: MTRR workaround for Intel i960 processor
i2o/iop0: Installed at IRQ17
i2o: I2O controller on bus 0 at 96.
i2o: PCI I2O controller at 0xD8000000 size=134217728
i2o: Unable to map controller.

I've seen that there was a problem with 2.4 already, but didn't find it 
with 2.6. Please could someone help me how to resolve this problem?

Any help is appreciated.


Best regards,


Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Jeff Garzik]

On Tue, Jun 01, 2004 at 02:37:30PM +0200, Markus Lidel wrote:
> Hello,
> 
> could someone help me with a ioremap problem. If there are two 
> controllers plugged in, the ioremap request for the first controller is 
> successfull, but the second returns NULL. Here is the output of the driver:
> 
> i2o: Checking for PCI I2O controllers...
> i2o: I2O controller on bus 0 at 72.
> i2o: PCI I2O controller at 0xD0000000 size=134217728
> I2O: MTRR workaround for Intel i960 processor
> i2o/iop0: Installed at IRQ17
> i2o: I2O controller on bus 0 at 96.
> i2o: PCI I2O controller at 0xD8000000 size=134217728
> i2o: Unable to map controller.

If "size=xxxx" indicates the size you are remapping, then that's
probably too large an area to be remapping.  Try remapping only the
memory area needed, and not the entire area.

	Jeff

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Markus Lidel]

Hello,

Jeff Garzik wrote:
>>could someone help me with a ioremap problem. If there are two 
>>controllers plugged in, the ioremap request for the first controller is 
>>successfull, but the second returns NULL. Here is the output of the driver:
>>i2o: Checking for PCI I2O controllers...
>>i2o: I2O controller on bus 0 at 72.
>>i2o: PCI I2O controller at 0xD0000000 size=134217728
>>I2O: MTRR workaround for Intel i960 processor
>>i2o/iop0: Installed at IRQ17
>>i2o: I2O controller on bus 0 at 96.
>>i2o: PCI I2O controller at 0xD8000000 size=134217728
>>i2o: Unable to map controller.
> If "size=xxxx" indicates the size you are remapping, then that's

Yep, it is...

> probably too large an area to be remapping.  Try remapping only the
> memory area needed, and not the entire area.

Is there a way, to increase the size, which could be remapped, or is 
there a way, to find out what is the maximum size which could be remapped?

Thank you very much for the fast answer!


Best regards,


Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Davide Rossetti]

Markus Lidel wrote:

> Hello,
>
> Jeff Garzik wrote:
>
>>> could someone help me with a ioremap problem. If there are two 
>>> controllers plugged in, the ioremap request for the first controller 
>>> is successfull, but the second returns NULL. Here is the output of 
>>> the driver:
>>> i2o: Checking for PCI I2O controllers...
>>> i2o: I2O controller on bus 0 at 72.
>>> i2o: PCI I2O controller at 0xD0000000 size=134217728
>>> I2O: MTRR workaround for Intel i960 processor
>>> i2o/iop0: Installed at IRQ17
>>> i2o: I2O controller on bus 0 at 96.
>>> i2o: PCI I2O controller at 0xD8000000 size=134217728
>>> i2o: Unable to map controller.
>>
>> If "size=xxxx" indicates the size you are remapping, then that's
>
I saw the same problem on a PCI card with a 128MB BAR. it is triggered 
on an Tyan opteron mobo, while on a old Dell P4 mobo it is ok. I 
followed a bit the source code for ioremap and found two places in which 
it can fail,

    area = get_vm_area(size, VM_IOREMAP);
    if (!area)
        return NULL;
    addr = area->addr;
    if (remap_area_pages(VMALLOC_VMADDR(addr), phys_addr, size, flags)) {
        vfree(addr);
        return NULL;
    }

I had not time to add debug printk and recompila the kernel to check 
which one is faulty...

The strange thing is that the BARs seems to be laid out correctly, so it 
does not look like a bios bug...

>
>> probably too large an area to be remapping.  Try remapping only the
>> memory area needed, and not the entire area.
>
>
> Is there a way, to increase the size, which could be remapped, or is 
> there a way, to find out what is the maximum size which could be 
> remapped?

we tried with half and it was ok, then we moved up a bit and found the 
maximum around 80MB I think...

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Markus Lidel]

Hello,

Davide Rossetti wrote:
>>>> could someone help me with a ioremap problem. If there are two 
>>>> controllers plugged in, the ioremap request for the first controller 
>>>> is successfull, but the second returns NULL. Here is the output of 
>>>> the driver:
>>>> i2o: Checking for PCI I2O controllers...
>>>> i2o: I2O controller on bus 0 at 72.
>>>> i2o: PCI I2O controller at 0xD0000000 size=134217728
>>>> I2O: MTRR workaround for Intel i960 processor
>>>> i2o/iop0: Installed at IRQ17
>>>> i2o: I2O controller on bus 0 at 96.
>>>> i2o: PCI I2O controller at 0xD8000000 size=134217728
>>>> i2o: Unable to map controller.
>>> If "size=xxxx" indicates the size you are remapping, then that's
> I saw the same problem on a PCI card with a 128MB BAR. it is triggered 
> on an Tyan opteron mobo, while on a old Dell P4 mobo it is ok. I 

Ah, so it could maybe a mainboard problem?

> followed a bit the source code for ioremap and found two places in which 
> it can fail,
>    area = get_vm_area(size, VM_IOREMAP);
>    if (!area)
>        return NULL;
>    addr = area->addr;
>    if (remap_area_pages(VMALLOC_VMADDR(addr), phys_addr, size, flags)) {
>        vfree(addr);
>        return NULL;
>    }
> I had not time to add debug printk and recompila the kernel to check 
> which one is faulty...
> The strange thing is that the BARs seems to be laid out correctly, so it 
> does not look like a bios bug...

But even if it's not a bug, maybe a BIOS update would help...

I'll check this out too...

>>> probably too large an area to be remapping.  Try remapping only the
>>> memory area needed, and not the entire area.
>> Is there a way, to increase the size, which could be remapped, or is 
>> there a way, to find out what is the maximum size which could be 
>> remapped?
> we tried with half and it was ok, then we moved up a bit and found the 
> maximum around 80MB I think...

Okay, i'll let try it out with only 64MB.


Thanks for your help!

Best regards,


Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Jeff Garzik]

Markus Lidel wrote:
> Hello,
> 
> Jeff Garzik wrote:
> 
>>> could someone help me with a ioremap problem. If there are two 
>>> controllers plugged in, the ioremap request for the first controller 
>>> is successfull, but the second returns NULL. Here is the output of 
>>> the driver:
>>> i2o: Checking for PCI I2O controllers...
>>> i2o: I2O controller on bus 0 at 72.
>>> i2o: PCI I2O controller at 0xD0000000 size=134217728
>>> I2O: MTRR workaround for Intel i960 processor
>>> i2o/iop0: Installed at IRQ17
>>> i2o: I2O controller on bus 0 at 96.
>>> i2o: PCI I2O controller at 0xD8000000 size=134217728
>>> i2o: Unable to map controller.
>>
>> If "size=xxxx" indicates the size you are remapping, then that's
> 
> 
> Yep, it is...
> 
>> probably too large an area to be remapping.  Try remapping only the
>> memory area needed, and not the entire area.
> 
> 
> Is there a way, to increase the size, which could be remapped, or is 
> there a way, to find out what is the maximum size which could be remapped?

My preferred approach would be:  consider that the hardware does not 
need the entire 0x8000000-byte area mapped.  Plain and simple.

This is a "don't do that" situation, and that renders the other 
questions moot :)  You should only be mapping what you need to map.

	Jeff

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Markus Lidel]

Hello,

Jeff Garzik wrote:
>>>> could someone help me with a ioremap problem. If there are two 
>>>> controllers plugged in, the ioremap request for the first controller 
>>>> is successfull, but the second returns NULL. Here is the output of 
>>>> the driver:
>>>> i2o: Checking for PCI I2O controllers...
>>>> i2o: I2O controller on bus 0 at 72.
>>>> i2o: PCI I2O controller at 0xD0000000 size=134217728
>>>> I2O: MTRR workaround for Intel i960 processor
>>>> i2o/iop0: Installed at IRQ17
>>>> i2o: I2O controller on bus 0 at 96.
>>>> i2o: PCI I2O controller at 0xD8000000 size=134217728
>>>> i2o: Unable to map controller.
>>> probably too large an area to be remapping.  Try remapping only the
>>> memory area needed, and not the entire area.
>> Is there a way, to increase the size, which could be remapped, or is 
>> there a way, to find out what is the maximum size which could be 
>> remapped?
> My preferred approach would be:  consider that the hardware does not 
> need the entire 0x8000000-byte area mapped.  Plain and simple.
> This is a "don't do that" situation, and that renders the other 
> questions moot :)  You should only be mapping what you need to map.

Okay, i'll let try it out with only 64MB.

Thanks again for your help!


Best regards,



Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Jeff Garzik]

Markus Lidel wrote:
> Jeff Garzik wrote:
>> My preferred approach would be:  consider that the hardware does not 
>> need the entire 0x8000000-byte area mapped.  Plain and simple.
>> This is a "don't do that" situation, and that renders the other 
>> questions moot :)  You should only be mapping what you need to map.
> 
> 
> Okay, i'll let try it out with only 64MB.


Why do you need 64MB, even?  :)

	Jeff

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Markus Lidel]

Hello,

Jeff Garzik wrote:
>>> My preferred approach would be:  consider that the hardware does not 
>>> need the entire 0x8000000-byte area mapped.  Plain and simple.
>>> This is a "don't do that" situation, and that renders the other 
>>> questions moot :)  You should only be mapping what you need to map.
>> Okay, i'll let try it out with only 64MB.
> Why do you need 64MB, even?  :)

I don't know how much space i need :-D But why does the device set the 
size to 128MB then?

Also now both controllers where found, but the kernel crashes. It could 
be because the driver was never used with 2 controllers, but to be sure 
  i didn't make something wrong with the ioremap here is my patch.

--- a/drivers/message/i2o/i2o_core.c	2004-05-25 00:51:48.822275000 +0200
+++ b/drivers/message/i2o/i2o_core.c	2004-06-01 22:17:55.562844312 +0200
@@ -3664,6 +3664,8 @@
  	}
  	
  	size = dev->resource[i].end-dev->resource[i].start+1;	
+	if(size>67108864)
+		size = 67108864;
  	/* Map the I2O controller */
  	
  	printk(KERN_INFO "i2o: PCI I2O controller at 0x%08X size=%d\n", 
memptr, size);

	mem = (unsigned long)ioremap(memptr, size);


Simply set size lower :-) Or have i missed something?

Thanks for you help!


Best regards,


Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Jeff Garzik]

On Wed, Jun 02, 2004 at 03:49:13PM +0200, Markus Lidel wrote:
> Hello,
> 
> Jeff Garzik wrote:
> >>>My preferred approach would be:  consider that the hardware does not 
> >>>need the entire 0x8000000-byte area mapped.  Plain and simple.
> >>>This is a "don't do that" situation, and that renders the other 
> >>>questions moot :)  You should only be mapping what you need to map.
> >>Okay, i'll let try it out with only 64MB.
> >Why do you need 64MB, even?  :)
> 
> I don't know how much space i need :-D But why does the device set the 
> size to 128MB then?

Devices often export things you don't care about, such as direct access
to internal chip RAM.

Look through the driver that figure out the maximum value that the
driver actually _uses_.  There is no need to guess.


> Also now both controllers where found, but the kernel crashes. It could 
> be because the driver was never used with 2 controllers, but to be sure 
>  i didn't make something wrong with the ioremap here is my patch.
> 
> --- a/drivers/message/i2o/i2o_core.c	2004-05-25 00:51:48.822275000 +0200
> +++ b/drivers/message/i2o/i2o_core.c	2004-06-01 22:17:55.562844312 +0200
> @@ -3664,6 +3664,8 @@
>  	}
>  	
>  	size = dev->resource[i].end-dev->resource[i].start+1;	

You should be using pci_resource_start() and pci_resource_len()
to obtain this information.


> +	if(size>67108864)
> +		size = 67108864;

It's nicer if you use hex numbers, when they are powers of two.

	Jeff

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Markus Lidel]

Hello,

Jeff Garzik wrote:
>>>>>My preferred approach would be:  consider that the hardware does not 
>>>>>need the entire 0x8000000-byte area mapped.  Plain and simple.
>>>>>This is a "don't do that" situation, and that renders the other 
>>>>>questions moot :)  You should only be mapping what you need to map.
>>>>Okay, i'll let try it out with only 64MB.
>>>Why do you need 64MB, even?  :)
>>I don't know how much space i need :-D But why does the device set the 
>>size to 128MB then?
> Devices often export things you don't care about, such as direct access
> to internal chip RAM.
> Look through the driver that figure out the maximum value that the
> driver actually _uses_.  There is no need to guess.

Okay, i've looked at it, but i don't think i could simply use less 
space, because (if i understand the I2O spec right :-D) the controller 
returns me a address inside this window, where i could write the I2O 
message. So i ask the controller, where do you want my request, then he 
tells me a address...

If i only ioremap 64MB, and the controller tells me write at 80MB, i'm 
in deep trouble :-D

>> 	size = dev->resource[i].end-dev->resource[i].start+1;	
> You should be using pci_resource_start() and pci_resource_len()
> to obtain this information.

Yep, thanks, but a patch for this is already send :-)

Best regards,



Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Richard B. Johnson]

On Wed, 2 Jun 2004, Markus Lidel wrote:

> Hello,
>
> Jeff Garzik wrote:
> >>>>>My preferred approach would be:  consider that the hardware does not
> >>>>>need the entire 0x8000000-byte area mapped.  Plain and simple.
> >>>>>This is a "don't do that" situation, and that renders the other
> >>>>>questions moot :)  You should only be mapping what you need to map.
> >>>>Okay, i'll let try it out with only 64MB.
> >>>Why do you need 64MB, even?  :)
> >>I don't know how much space i need :-D But why does the device set the
> >>size to 128MB then?
> > Devices often export things you don't care about, such as direct access
> > to internal chip RAM.
> > Look through the driver that figure out the maximum value that the
> > driver actually _uses_.  There is no need to guess.
>
> Okay, i've looked at it, but i don't think i could simply use less
> space, because (if i understand the I2O spec right :-D) the controller
> returns me a address inside this window, where i could write the I2O
> message. So i ask the controller, where do you want my request, then he
> tells me a address...
>
> If i only ioremap 64MB, and the controller tells me write at 80MB, i'm
> in deep trouble :-D
>
> >> 	size = dev->resource[i].end-dev->resource[i].start+1;
> > You should be using pci_resource_start() and pci_resource_len()
> > to obtain this information.
>
> Yep, thanks, but a patch for this is already send :-)
>
> Best regards,
>

I2O, as seen from the PCI/Bus, is a bus! Right? You have a
PCI/Bus controller that provides for an interface into
I2O? Right? Can you do `cat /proc/pci` and show what device
you think it is?  I think you are attempting to access a bridge
or something. I2O is supposed to be intelligent and to grab
64 megabytes of host address space is the anthesis of this.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Markus Lidel]

Hello,

Richard B. Johnson wrote:
>>>>>>>My preferred approach would be:  consider that the hardware does not
>>>>>>>need the entire 0x8000000-byte area mapped.  Plain and simple.
>>>>>>>This is a "don't do that" situation, and that renders the other
>>>>>>>questions moot :)  You should only be mapping what you need to map.
>>>>>>Okay, i'll let try it out with only 64MB.
>>>>>Why do you need 64MB, even?  :)
>>>>I don't know how much space i need :-D But why does the device set the
>>>>size to 128MB then?
>>>Devices often export things you don't care about, such as direct access
>>>to internal chip RAM.
>>>Look through the driver that figure out the maximum value that the
>>>driver actually _uses_.  There is no need to guess.
>>Okay, i've looked at it, but i don't think i could simply use less
>>space, because (if i understand the I2O spec right :-D) the controller
>>returns me a address inside this window, where i could write the I2O
>>message. So i ask the controller, where do you want my request, then he
>>tells me a address...
>>If i only ioremap 64MB, and the controller tells me write at 80MB, i'm
>>in deep trouble :-D
> I2O, as seen from the PCI/Bus, is a bus! Right? You have a
> PCI/Bus controller that provides for an interface into
> I2O? Right? Can you do `cat /proc/pci` and show what device

Hope a lspci -v would also help :-D

If not i must ask for the output again...

First controller:

0000:00:09.0 I2O: Distributed Processing Technology SmartRAID V 
Controller (rev 02) (prog-if 01)
	Subsystem: Distributed Processing Technology 2400A UDMA Four Channel
	Flags: bus master, medium devsel, latency 64, IRQ 17
	BIST result: 00
	Memory at d0000000 (32-bit, prefetchable)
	Capabilities: [80] Power Management version 2

0000:00:09.1 PCI bridge: Distributed Processing Technology PCI Bridge 
(rev 02) (prog-if 00 [Normal decode])
	Flags: bus master, medium devsel, latency 64
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
	Expansion ROM at 0000a000 [disabled] [size=4K]
	Capabilities: [68] Power Management version 2


Second controller:

0000:00:0c.0 I2O: Distributed Processing Technology SmartRAID V 
Controller (rev 02) (prog-if 01)
	Subsystem: Distributed Processing Technology 2400A UDMA Four Channel
	Flags: bus master, medium devsel, latency 64, IRQ 19
	BIST result: 00
	Memory at d8000000 (32-bit, prefetchable)
	Capabilities: [80] Power Management version 2

0000:00:0c.1 PCI bridge: Distributed Processing Technology PCI Bridge 
(rev 02) (prog-if 00 [Normal decode])
	Flags: bus master, medium devsel, latency 64
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=64
	I/O behind bridge: 0000b000-0000bfff
	Expansion ROM at 0000b000 [disabled] [size=4K]
	Capabilities: [68] Power Management version 2

> you think it is?  I think you are attempting to access a bridge
> or something. I2O is supposed to be intelligent and to grab
> 64 megabytes of host address space is the anthesis of this.

I don't know the hardware part very vell :-( But because i'm not the 
author of the driver i don't think there is something wrong :-)


Best regards,



Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Richard B. Johnson]

I asked for the output of `cat /proc/pci` . Unless I get that
information, I can't find the length of the allocation.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Stuart Young]

On Thu, 3 Jun 2004 01:45, Richard B. Johnson wrote:
> I asked for the output of `cat /proc/pci` . Unless I get that
> information, I can't find the length of the allocation.

Is there no way to to get this information out of lspci (eg: lspci -vv)? This 
is particularly annoying since /proc/pci is depreciated. I know a number of 
people who simply don't bother turning it on anymore. If there is information 
in /proc/pci that isn't available through lspci somehow, then I'd call that a 
nasty regression, which needs to be fixed.

Are you sure on this Richard? (No disrespect intended, just want to confirm 
things).

-- 
 Stuart Young (aka Cef)
 cef-lkml@optusnet.com.au is for LKML and related email only

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Jeff Garzik]

Stuart Young wrote:
> On Thu, 3 Jun 2004 01:45, Richard B. Johnson wrote:
> 
>>I asked for the output of `cat /proc/pci` . Unless I get that
>>information, I can't find the length of the allocation.
> 
> 
> Is there no way to to get this information out of lspci (eg: lspci -vv)? This 
> is particularly annoying since /proc/pci is depreciated. I know a number of 


You _can_ get that information out of lspci.

	Jeff

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Markus Lidel]

Hello,

Jeff Garzik wrote:
>>> I asked for the output of `cat /proc/pci` . Unless I get that
>>> information, I can't find the length of the allocation.
>> Is there no way to to get this information out of lspci (eg: lspci 
>> -vv)? This is particularly annoying since /proc/pci is depreciated. I 
>> know a number of 
> You _can_ get that information out of lspci.

Could you tell me how, because lspci -v doesn't contain that 
information, and even with lspci -vv not all sizes are displayed?


Best regards,


Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Richard B. Johnson]

On Thu, 3 Jun 2004, Stuart Young wrote:

> On Thu, 3 Jun 2004 01:45, Richard B. Johnson wrote:
> > I asked for the output of `cat /proc/pci` . Unless I get that
> > information, I can't find the length of the allocation.
>
> Is there no way to to get this information out of lspci (eg: lspci -vv)? This
> is particularly annoying since /proc/pci is depreciated. I know a number of
> people who simply don't bother turning it on anymore. If there is information
> in /proc/pci that isn't available through lspci somehow, then I'd call that a
> nasty regression, which needs to be fixed.
>
> Are you sure on this Richard? (No disrespect intended, just want to confirm
> things).
>
> --
>  Stuart Young (aka Cef)
>  cef-lkml@optusnet.com.au is for LKML and related email only
>

Well.. Here is `cat /proc/pci`


Script started on Thu Jun  3 07:38:33 2004
quark:/home/johnson[1] cat /proc/pci
PCI devices found:
  Bus  0, device   0, function  0:
    Host bridge: Intel Corp. 430VX - 82437VX TVX [Triton VX] (rev 2).
      Master Capable.  Latency=24.
  Bus  0, device   7, function  0:
    ISA bridge: Intel Corp. 82371SB PIIX3 ISA [Natoma/Triton II] (rev 1).
  Bus  0, device   7, function  1:
    IDE interface: Intel Corp. 82371SB PIIX3 IDE [Natoma/Triton II] (rev 0).
      Master Capable.  Latency=16.
      I/O at 0xffa0 [0xffaf].
  Bus  0, device  13, function  0:
    SCSI storage controller: BusLogic BT-946C (BA80C30) [MultiMaster 10] (rev 8).
      IRQ 10.
      Master Capable.  Latency=24.  Min Gnt=8.Max Lat=8.
      I/O at 0xfff4 [0xfff7].
      Non-prefetchable 32 bit memory at 0xffbef000 [0xffbeffff].
  Bus  0, device  14, function  0:
    VGA compatible controller: S3 Inc. 86c325 [ViRGE] (rev 6).
      IRQ 11.
      Master Capable.  Latency=24.  Min Gnt=4.Max Lat=255.
      Non-prefetchable 32 bit memory at 0xf8000000 [0xfbffffff].
  Bus  0, device  16, function  0:
    Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] (rev 0).
      IRQ 9.
      Master Capable.  Latency=24.  Min Gnt=3.Max Lat=8.
      I/O at 0xff00 [0xff3f].


Now lspci 'interprets' stuff. The interpretation may not be correct.
For instance, you think that your device wants 64 Megabytes. This is,
like, unheard of except for screen controllers and they are basically
broken because 64 megabytes can't be accessed at any one time. Large
allocations should be paged, but a page register costs a nickel
in the FPGA so vendors being cheap, cheap, grab a lot of your
address-space.

quark:/home/johnson[2] /sbin/lspci -v
00:00.0 Host bridge: Intel Corp. 430VX - 82437VX TVX [Triton VX] (rev 02)
	Flags: bus master, medium devsel, latency 24

00:07.0 ISA bridge: Intel Corp. 82371SB PIIX3 ISA [Natoma/Triton II] (rev 01)
	Flags: bus master, medium devsel, latency 0

00:07.1 IDE interface: Intel Corp. 82371SB PIIX3 IDE [Natoma/Triton II] (prog-if 80 [Master])
	Flags: medium devsel
	I/O ports at ffa0 [size=16]

00:0d.0 SCSI storage controller: BusLogic BT-946C (BA80C30) [MultiMaster 10] (rev 08)
	Subsystem: BusLogic BT-946C (BA80C30) [MultiMaster 10]
	Flags: bus master, fast devsel, latency 24, IRQ 10
	I/O ports at fff4 [size=4]
	Memory at ffbef000 (32-bit, non-prefetchable) [size=4K]
	Expansion ROM at <unassigned> [disabled] [size=32K]

00:0e.0 VGA compatible controller: S3 Inc. 86c325 [ViRGE] (rev 06) (prog-if 00 [VGA])
	Flags: bus master, VGA palette snoop, medium devsel, latency 24, IRQ 11
	Memory at f8000000 (32-bit, non-prefetchable) [size=64M]
	Expansion ROM at <unassigned> [disabled] [size=64K]

00:10.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
	Flags: bus master, medium devsel, latency 24, IRQ 9
	I/O ports at ff00 [size=64]
	Expansion ROM at <unassigned> [disabled] [size=64K]

quark:/home/johnson[3] exit
Script done on Thu Jun  3 07:39:00 2004


Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Richard B. Johnson]

On Thu, 3 Jun 2004, Stuart Young wrote:

> On Thu, 3 Jun 2004 01:45, Richard B. Johnson wrote:
> > I asked for the output of `cat /proc/pci` . Unless I get that
> > information, I can't find the length of the allocation.
>
> Is there no way to to get this information out of lspci (eg: lspci -vv)? This
> is particularly annoying since /proc/pci is depreciated. I know a number of
> people who simply don't bother turning it on anymore. If there is information
> in /proc/pci that isn't available through lspci somehow, then I'd call that a
> nasty regression, which needs to be fixed.
>
> Are you sure on this Richard? (No disrespect intended, just want to confirm
> things).
>

I didn't say what I was 're-quoted'. That's from somebody else.
If they are taking away /proc/pci (sniff), you need to use
`lspci -v` to get the length . If they are taking that way,
you need to make your own!


Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Zwane Mwaikambo]

On Tue, 1 Jun 2004, Markus Lidel wrote:

> > probably too large an area to be remapping.  Try remapping only the
> > memory area needed, and not the entire area.
>
> Is there a way, to increase the size, which could be remapped, or is
> there a way, to find out what is the maximum size which could be remapped?
>
> Thank you very much for the fast answer!

You could try a 4G/4G enabled kernel, /proc/meminfo tells you how much
vmalloc (ioremap) space there is too.

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Markus Lidel]

Hello,

Zwane Mwaikambo wrote:
>>>probably too large an area to be remapping.  Try remapping only the
>>>memory area needed, and not the entire area.
>>Is there a way, to increase the size, which could be remapped, or is
>>there a way, to find out what is the maximum size which could be remapped?
>>Thank you very much for the fast answer!
> You could try a 4G/4G enabled kernel, /proc/meminfo tells you how much
> vmalloc (ioremap) space there is too.

VmallocTotal:   245752 kB
VmallocUsed:    137720 kB
VmallocChunk:   107904 kB

Okay, i see the problem now, the largest piece of memory which could be 
allocated is 107904 kB, right?

Is the 4G/4G split already in the kernel? If yes, which entry activates it?

BTW, CONFIG_HIGHMEM4G is enabled already :-)

Thanks for the hint!


Best regards,


Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Zwane Mwaikambo]

On Wed, 2 Jun 2004, Markus Lidel wrote:

> Zwane Mwaikambo wrote:
> >>>probably too large an area to be remapping.  Try remapping only the
> >>>memory area needed, and not the entire area.
> >>Is there a way, to increase the size, which could be remapped, or is
> >>there a way, to find out what is the maximum size which could be remapped?
> >>Thank you very much for the fast answer!
> > You could try a 4G/4G enabled kernel, /proc/meminfo tells you how much
> > vmalloc (ioremap) space there is too.
>
> VmallocTotal:   245752 kB
> VmallocUsed:    137720 kB
> VmallocChunk:   107904 kB
>
> Okay, i see the problem now, the largest piece of memory which could be
> allocated is 107904 kB, right?
>
> Is the 4G/4G split already in the kernel? If yes, which entry activates it?

'fraid not, you'll have to either patch a kernel or use Arjan's
i686 kernels at http://people.redhat.com/arjanv/2.6/RPMS.kernel/

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Zwane Mwaikambo]

On Wed, 2 Jun 2004, Markus Lidel wrote:

> Zwane Mwaikambo wrote:
> >>>probably too large an area to be remapping.  Try remapping only the
> >>>memory area needed, and not the entire area.
> >>Is there a way, to increase the size, which could be remapped, or is
> >>there a way, to find out what is the maximum size which could be remapped?
> >>Thank you very much for the fast answer!
> > You could try a 4G/4G enabled kernel, /proc/meminfo tells you how much
> > vmalloc (ioremap) space there is too.
>
> VmallocTotal:   245752 kB
> VmallocUsed:    137720 kB
> VmallocChunk:   107904 kB
>
> Okay, i see the problem now, the largest piece of memory which could be
> allocated is 107904 kB, right?
>
> Is the 4G/4G split already in the kernel? If yes, which entry activates it?

No it's not in the current kernel, you'd have to download the patch, the
most uptodate being the one in the Fedora/Redhat kernel tree.

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Jeff Garzik]

I would need to see the hardware specs, but I really think some 
alternate mapping solution needs to be found.

"map the entire area" may be easy, but in this case isn't the best solution.

	Jeff

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Markus Lidel]

Hello,

Jeff Garzik wrote:
> I would need to see the hardware specs, but I really think some 
> alternate mapping solution needs to be found.

Okay, i've limit the mapped memory, and it seems to work :-)

> "map the entire area" may be easy, but in this case isn't the best 
> solution.

Yes, i agree with you. I'll try to find out, if there is a way to get 
the real size, and only map this area.



Best regards,


Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: Problem with ioremap which returns NULL in 2.6 kernel

[Markus Lidel]

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]

Hello,

Zwane Mwaikambo wrote:
>>>>>probably too large an area to be remapping.  Try remapping only the
>>>>>memory area needed, and not the entire area.
>>>>Is there a way, to increase the size, which could be remapped, or is
>>>>there a way, to find out what is the maximum size which could be remapped?
>>>>Thank you very much for the fast answer!
>>>You could try a 4G/4G enabled kernel, /proc/meminfo tells you how much
>>>vmalloc (ioremap) space there is too.
>>VmallocTotal:   245752 kB
>>VmallocUsed:    137720 kB
>>VmallocChunk:   107904 kB
>>Okay, i see the problem now, the largest piece of memory which could be
>>allocated is 107904 kB, right?
>>Is the 4G/4G split already in the kernel? If yes, which entry activates it?
 >
> No it's not in the current kernel, you'd have to download the patch, the
> most uptodate being the one in the Fedora/Redhat kernel tree.

Okay, thank you very much!

Best regards,


Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3512 bytes --]