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
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
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: [email protected]
URL: http://www.shadowconnect.com
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...
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
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.
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: [email protected]
URL: http://www.shadowconnect.com
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: [email protected]
URL: http://www.shadowconnect.com
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: [email protected]
URL: http://www.shadowconnect.com
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
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: [email protected]
URL: http://www.shadowconnect.com
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
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: [email protected]
URL: http://www.shadowconnect.com
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.
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: [email protected]
URL: http://www.shadowconnect.com
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.
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)
[email protected] is for LKML and related email only
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
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: [email protected]
URL: http://www.shadowconnect.com
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)
> [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.
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/