Problem with ioremap which returns NULL in 2.6 kernel

DISCUSSION Markus Lidel 6 participants 26 messages Jun 1, 2004 – Jul 17, 2004

Share & tools

Markus Lidel

author

2004-06-01 12:30 UTC #0 lore raw

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: [email protected]
URL:    http://www.shadowconnect.com

Jeff Garzik

2004-06-01 14:22 UTC #1 lore raw

Quoted 6 lines · 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:

Quoted 8 lines

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

Markus Lidel

author

2004-06-01 15:15 UTC #2 lore raw

Hello,

Quoted 10 lines · Jeff Garzik

Quoted 9 lines
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...

Quoted 2 lines

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: [email protected]
URL:    http://www.shadowconnect.com

Davide Rossetti

2004-06-01 17:09 UTC #3 lore raw

Quoted 16 lines · Markus Lidel

Hello,
Quoted 11 lines · Jeff Garzik
Quoted 9 lines
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...

Quoted 6 lines

Quoted 3 lines
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...

Markus Lidel

author

2004-06-02 08:52 UTC #4 lore raw

Hello,

Quoted 11 lines · Davide Rossetti

Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
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?

Quoted 11 lines

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...

Quoted 4 lines

Quoted 3 lines
Quoted 2 lines
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: [email protected]
URL:    http://www.shadowconnect.com

Jeff Garzik

2004-06-01 23:32 UTC #5 lore raw

In reply to Markus Lidel

Quoted 17 lines · Markus Lidel

Hello,
Quoted 11 lines · Jeff Garzik
Quoted 9 lines
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

Quoted 7 lines

Yep, it is...
Quoted 2 lines
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

Markus Lidel

author

2004-06-02 08:48 UTC #6 lore raw

Hello,

Quoted 9 lines · Jeff Garzik

Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
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.

Quoted 5 lines

Quoted 3 lines
Quoted 2 lines
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: [email protected]
URL:    http://www.shadowconnect.com

Jeff Garzik

2004-06-02 13:23 UTC #7 lore raw

Quoted 6 lines · Markus Lidel

Quoted 2 lines · Jeff Garzik
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

Markus Lidel

author

2004-06-02 13:43 UTC #8 lore raw

Hello,

Quoted 4 lines · Jeff Garzik

Quoted 3 lines
Quoted 2 lines
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.

drivers/message/i2o/i2o_core.c +2 -0

@@ -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: [email protected]
URL:    http://www.shadowconnect.com

Jeff Garzik

2004-06-02 13:46 UTC #9 lore raw

Quoted 7 lines · Markus Lidel

Hello,
Quoted 4 lines · Jeff Garzik
Quoted 4 lines
Quoted 4 lines
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.

Quoted 5 lines

Quoted 2 lines
Quoted 1 line
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.

drivers/message/i2o/i2o_core.c line 3666

Quoted 10 lines

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.
drivers/message/i2o/i2o_core.c +0 -0
@@ -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.

drivers/message/i2o/i2o_core.c line 3668

Quoted 2 lines

drivers/message/i2o/i2o_core.c +2 -0
+	if(size>67108864)
+		size = 67108864;

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

Jeff

Markus Lidel

author

2004-06-02 14:12 UTC #10 lore raw

Hello,

Quoted 9 lines · Jeff Garzik

Quoted 5 lines
Quoted 4 lines
Quoted 3 lines
Quoted 2 lines
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

Quoted 3 lines

Quoted 1 line
	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: [email protected]
URL:    http://www.shadowconnect.com

Richard B. Johnson

2004-06-02 14:39 UTC #11 lore raw

Quoted 25 lines · Markus Lidel

Hello,
Quoted 4 lines · Jeff Garzik
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Quoted 1 line
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

Quoted 8 lines

Quoted 3 lines
Quoted 1 line
	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.

Markus Lidel

author

2004-06-02 15:21 UTC #12 lore raw

Hello,

Quoted 19 lines · Richard B. Johnson

Quoted 12 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Quoted 1 line
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.
Quoted 7 lines
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

Quoted 3 lines

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

Quoted 3 lines

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: [email protected]
URL:    http://www.shadowconnect.com

Richard B. Johnson

2004-06-02 15:52 UTC #13 lore raw

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.

Stuart Young

2004-06-03 02:40 UTC #14 lore raw

Quoted 2 lines · 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.

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).

Signature · 2 lines

 Stuart Young (aka Cef)
 [email protected] is for LKML and related email only

Jeff Garzik

2004-06-03 02:51 UTC #15 lore raw

Quoted 7 lines · Stuart Young

Quoted 2 lines · 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.
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

Markus Lidel

author

2004-06-03 08:32 UTC #16 lore raw

Hello,

Quoted 6 lines · Jeff Garzik

Quoted 5 lines
Quoted 2 lines
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: [email protected]
URL:    http://www.shadowconnect.com

Richard B. Johnson

2004-06-03 11:43 UTC #17 lore raw

In reply to Stuart Young

Quoted 10 lines · Stuart Young

Quoted 2 lines · 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.
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.

Quoted 7 lines

Are you sure on this Richard? (No disrespect intended, just want to confirm things).
--
Stuart Young (aka Cef)
[email protected] 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.

Richard B. Johnson

2004-07-16 11:20 UTC #18 lore raw

In reply to Stuart Young

Quoted 4 lines · Stuart Young

Quoted 2 lines · 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.

Quoted 9 lines

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.

Zwane Mwaikambo

2004-06-02 00:08 UTC #19 lore raw

In reply to Markus Lidel

Quoted 7 lines · Markus Lidel

Quoted 2 lines
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.

Markus Lidel

author

2004-06-02 12:11 UTC #20 lore raw

Hello,

Quoted 7 lines · Zwane Mwaikambo

Quoted 5 lines
Quoted 2 lines
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: [email protected]
URL:    http://www.shadowconnect.com

Zwane Mwaikambo

2004-06-04 20:17 UTC #21 lore raw

Quoted 9 lines · Markus Lidel

Quoted 7 lines · Zwane Mwaikambo
Quoted 5 lines
Quoted 2 lines
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.

Quoted 8 lines

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/

Zwane Mwaikambo

2004-07-16 17:26 UTC #22 lore raw

In reply to Markus Lidel

Quoted 9 lines · Markus Lidel

Quoted 7 lines · Zwane Mwaikambo
Quoted 5 lines
Quoted 2 lines
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.

Quoted 8 lines

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.

Jeff Garzik

2004-07-16 17:30 UTC #23 lore raw

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

Markus Lidel

author

2004-07-17 00:20 UTC #24 lore raw

Hello,

Quoted 1 line · Jeff Garzik

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 :-)

Quoted 1 line

"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: [email protected]
URL:    http://www.shadowconnect.com

Markus Lidel

author

2004-07-17 00:22 UTC #25 lore raw

In reply to Zwane Mwaikambo

Hello,

Quoted 14 lines · Zwane Mwaikambo

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
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!
Quoted 8 lines
Quoted 2 lines
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?

Quoted 2 lines

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: [email protected]
URL:    http://www.shadowconnect.com