Re: Possible PCI subsystem bug in 2.4
"Maciej W. Rozycki" <[EMAIL PROTECTED]> writes: > On 4 May 2001, Eric W. Biederman wrote: > > > The example that sticks out in my head is we rely on the MP table to > > tell us if the local apic is in pic_mode or in virtual wire mode. > > When all we really have to do is ask it. > > You can't. IMCR is write-only and may involve chipset-specific > side-effects. Then even if IMCR exists, a system's firmware might have > chosen the virtual wire mode for whatever reason (e.g. broken hardware). Admittedly you can't detect directly detect IMCR state. But triggering an interrupt on the bootstrap processor local apic, and failing to receive it should be proof the IMCR is at work. Alternatively if I'm wrong about the wiring disabling all interrupts at the apic level and receiving one is a second proof that IMCR is at work. Further I don't think a processor with an onboard apic, works with an IMCR register. What I was thinking of earlier is that you can detect an apic or ioapic in virtual wire mode, which the current code and the intel MP spec treats as the opposite possibility. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
Maciej W. Rozycki [EMAIL PROTECTED] writes: On 4 May 2001, Eric W. Biederman wrote: The example that sticks out in my head is we rely on the MP table to tell us if the local apic is in pic_mode or in virtual wire mode. When all we really have to do is ask it. You can't. IMCR is write-only and may involve chipset-specific side-effects. Then even if IMCR exists, a system's firmware might have chosen the virtual wire mode for whatever reason (e.g. broken hardware). Admittedly you can't detect directly detect IMCR state. But triggering an interrupt on the bootstrap processor local apic, and failing to receive it should be proof the IMCR is at work. Alternatively if I'm wrong about the wiring disabling all interrupts at the apic level and receiving one is a second proof that IMCR is at work. Further I don't think a processor with an onboard apic, works with an IMCR register. What I was thinking of earlier is that you can detect an apic or ioapic in virtual wire mode, which the current code and the intel MP spec treats as the opposite possibility. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
On 4 May 2001, Eric W. Biederman wrote: > The example that sticks out in my head is we rely on the MP table to > tell us if the local apic is in pic_mode or in virtual wire mode. > When all we really have to do is ask it. You can't. IMCR is write-only and may involve chipset-specific side-effects. Then even if IMCR exists, a system's firmware might have chosen the virtual wire mode for whatever reason (e.g. broken hardware). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
On 4 May 2001, Eric W. Biederman wrote: The example that sticks out in my head is we rely on the MP table to tell us if the local apic is in pic_mode or in virtual wire mode. When all we really have to do is ask it. You can't. IMCR is write-only and may involve chipset-specific side-effects. Then even if IMCR exists, a system's firmware might have chosen the virtual wire mode for whatever reason (e.g. broken hardware). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
> O.k. I was simply thinking that if we weren't reprogramming the mtrrs, it > would be a good idea to make certain we didn't map any PCI drivers > into a write back area. What if the BIOS set up an mtrr for a device ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
O.k. I was simply thinking that if we weren't reprogramming the mtrrs, it would be a good idea to make certain we didn't map any PCI drivers into a write back area. What if the BIOS set up an mtrr for a device ? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
Alan Cox <[EMAIL PROTECTED]> writes: > > Seriously. With the general attitude of distrusting BIOS's I have > > been amazed at the number of things linux expects the BIOS to get > > right. In practice windows seem to trust the BIOS much less than > > linux does. > > It becomes more and more obvious over time exactly why. One problem however > is that windows gets away with this because many vendors ship random extra > gunge for their box with the system. We dont yet have that power Right. So we always need to keep heuristics in our toolbox to fallback on, so we can run on boards with incomplete information. However there is a lot of things we can do that we aren't currently doing. The example that sticks out in my head is we rely on the MP table to tell us if the local apic is in pic_mode or in virtual wire mode. When all we really have to do is ask it. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
On 4 May 2001, Eric W. Biederman wrote: > > There are a couple of options here. > 1) read the MTRRs unless the BIOS is braindead it will set up that area as >write-back. At any rate we shouldn't ever try to allocate a pci region >that is write-back cached. This one I'd really hesitate to use. We do _not_ want to trust the BIOS any more than necessary (obviously trusting even the e820 was too much), and especially wrt MTRR's we know that there are too many buggy bioses already out there. > 2) read the memory locations from the northbridge. It's not possible >on every chipset (lack of documentation) but with the linuxBIOS >project we code for a couple of them, and we are working on more >all of the time. This will be easy. In fact, we can easily "mix" different heuristics. Ie we'd do the simple thing I suggested in setup_arch(), and use that as a "base guess", and then we can have incremental improvements on that guess that might be chipset-specific or might depend on other information that is not necessarily generic (things like existing PCI programming etc). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
> Seriously. With the general attitude of distrusting BIOS's I have > been amazed at the number of things linux expects the BIOS to get > right. In practice windows seem to trust the BIOS much less than > linux does. It becomes more and more obvious over time exactly why. One problem however is that windows gets away with this because many vendors ship random extra gunge for their box with the system. We dont yet have that power Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
Alan Cox <[EMAIL PROTECTED]> writes: > > There are a couple of options here. > > 1) read the MTRRs unless the BIOS is braindead it will set up that area as > >write-back. At any rate we shouldn't ever try to allocate a pci region > >that is write-back cached. > > 'unless the BIOS is braindead'. Right. We only got into this problem because > the BIOS _was_ braindead. Well I did provide a suggestion so you don't have to second guess... Usually it's actually easier to read the memory size from the northbridge than to parse the E820 map. However since it is different kinds of braindamage to mess up the MTRRs, and the E820 memory map, it is worth a shot. Personally I think MTRRs are much easier to get right, because you don't need to take into account what the BIOS is going to do just where your ram is. As for braindead BIOS's in general any comments on totally nuking them? Seriously. With the general attitude of distrusting BIOS's I have been amazed at the number of things linux expects the BIOS to get right. In practice windows seem to trust the BIOS much less than linux does. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
> There are a couple of options here. > 1) read the MTRRs unless the BIOS is braindead it will set up that area as >write-back. At any rate we shouldn't ever try to allocate a pci region >that is write-back cached. 'unless the BIOS is braindead'. Right. We only got into this problem because the BIOS _was_ braindead. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
Alan Cox <[EMAIL PROTECTED]> writes: > > I suspect it would be safe to round up to the next megabyte, possibly up > > to 64MB or so. But much more would make me nervous. > > Any suggestions? > > I'd go for 1MByte simply because I've not seen an EBDA/NVRAM area that large > stuck at the top of RAM. 1Mb would fix the Dell. (It was only when I saw > your email it suddenely clicked and I grabbed the bootup log) There are a couple of options here. 1) read the MTRRs unless the BIOS is braindead it will set up that area as write-back. At any rate we shouldn't ever try to allocate a pci region that is write-back cached. 2) read the memory locations from the northbridge. It's not possible on every chipset (lack of documentation) but with the linuxBIOS project we code for a couple of them, and we are working on more all of the time. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
Linus Torvalds wrote:
>
> On Thu, 3 May 2001, Alan Cox wrote:
> >
> > Obvious one is to go to the next power of two clear.
>
> The question is mainly _which_ power of two.
>
> I don't think we can round up infinitely, as that might just end up
> causing us to not have any PCI space at all. Or we could end up deciding
> that real PCI space is memory, and then getting a clash when a real device
> tries to register its bios-allocated area that clashes with our extreme
> rounding.
>
> I suspect it would be safe to round up to the next megabyte, possibly up
> to 64MB or so. But much more would make me nervous.
>
> Any suggestions?
The amount of RAM in a machine almost always has just one or two "1"
bits.
8, 16, 20, 24, 32, 36, 40, 48, 64, 80 Mb were the numbers that you'd
see in the early Pentium times, right?
So rounding up would mean: Add one until the number of 1-bits in the
address is less than 3. People with 3 or more differently sized DIMMS
in their machine will experience a slightly ineffcient round-up.
Speed this up with: Find-lowest-1-bit, add that.
Example you quoted:
nr of 1 bits.
BIOS-proclaimed end-of-ram: 0x13fff 15
lowest 1-bit: 0x1 1
add:0x14000 2
long round_highmem (long val)
{
while (hweight32 (val) > 2)
val += 1 << ffs (val);
return val;
}
Roger.
--
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
Linus Torvalds wrote:
On Thu, 3 May 2001, Alan Cox wrote:
Obvious one is to go to the next power of two clear.
The question is mainly _which_ power of two.
I don't think we can round up infinitely, as that might just end up
causing us to not have any PCI space at all. Or we could end up deciding
that real PCI space is memory, and then getting a clash when a real device
tries to register its bios-allocated area that clashes with our extreme
rounding.
I suspect it would be safe to round up to the next megabyte, possibly up
to 64MB or so. But much more would make me nervous.
Any suggestions?
The amount of RAM in a machine almost always has just one or two 1
bits.
8, 16, 20, 24, 32, 36, 40, 48, 64, 80 Mb were the numbers that you'd
see in the early Pentium times, right?
So rounding up would mean: Add one until the number of 1-bits in the
address is less than 3. People with 3 or more differently sized DIMMS
in their machine will experience a slightly ineffcient round-up.
Speed this up with: Find-lowest-1-bit, add that.
Example you quoted:
nr of 1 bits.
BIOS-proclaimed end-of-ram: 0x13fff 15
lowest 1-bit: 0x1 1
add:0x14000 2
long round_highmem (long val)
{
while (hweight32 (val) 2)
val += 1 ffs (val);
return val;
}
Roger.
--
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
Alan Cox [EMAIL PROTECTED] writes: I suspect it would be safe to round up to the next megabyte, possibly up to 64MB or so. But much more would make me nervous. Any suggestions? I'd go for 1MByte simply because I've not seen an EBDA/NVRAM area that large stuck at the top of RAM. 1Mb would fix the Dell. (It was only when I saw your email it suddenely clicked and I grabbed the bootup log) There are a couple of options here. 1) read the MTRRs unless the BIOS is braindead it will set up that area as write-back. At any rate we shouldn't ever try to allocate a pci region that is write-back cached. 2) read the memory locations from the northbridge. It's not possible on every chipset (lack of documentation) but with the linuxBIOS project we code for a couple of them, and we are working on more all of the time. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
There are a couple of options here. 1) read the MTRRs unless the BIOS is braindead it will set up that area as write-back. At any rate we shouldn't ever try to allocate a pci region that is write-back cached. 'unless the BIOS is braindead'. Right. We only got into this problem because the BIOS _was_ braindead. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
Alan Cox [EMAIL PROTECTED] writes: There are a couple of options here. 1) read the MTRRs unless the BIOS is braindead it will set up that area as write-back. At any rate we shouldn't ever try to allocate a pci region that is write-back cached. 'unless the BIOS is braindead'. Right. We only got into this problem because the BIOS _was_ braindead. Well I did provide a suggestion so you don't have to second guess... Usually it's actually easier to read the memory size from the northbridge than to parse the E820 map. However since it is different kinds of braindamage to mess up the MTRRs, and the E820 memory map, it is worth a shot. Personally I think MTRRs are much easier to get right, because you don't need to take into account what the BIOS is going to do just where your ram is. As for braindead BIOS's in general any comments on totally nuking them? Seriously. With the general attitude of distrusting BIOS's I have been amazed at the number of things linux expects the BIOS to get right. In practice windows seem to trust the BIOS much less than linux does. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
Seriously. With the general attitude of distrusting BIOS's I have been amazed at the number of things linux expects the BIOS to get right. In practice windows seem to trust the BIOS much less than linux does. It becomes more and more obvious over time exactly why. One problem however is that windows gets away with this because many vendors ship random extra gunge for their box with the system. We dont yet have that power Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
On 4 May 2001, Eric W. Biederman wrote: There are a couple of options here. 1) read the MTRRs unless the BIOS is braindead it will set up that area as write-back. At any rate we shouldn't ever try to allocate a pci region that is write-back cached. This one I'd really hesitate to use. We do _not_ want to trust the BIOS any more than necessary (obviously trusting even the e820 was too much), and especially wrt MTRR's we know that there are too many buggy bioses already out there. 2) read the memory locations from the northbridge. It's not possible on every chipset (lack of documentation) but with the linuxBIOS project we code for a couple of them, and we are working on more all of the time. This will be easy. In fact, we can easily mix different heuristics. Ie we'd do the simple thing I suggested in setup_arch(), and use that as a base guess, and then we can have incremental improvements on that guess that might be chipset-specific or might depend on other information that is not necessarily generic (things like existing PCI programming etc). Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
Alan Cox [EMAIL PROTECTED] writes: Seriously. With the general attitude of distrusting BIOS's I have been amazed at the number of things linux expects the BIOS to get right. In practice windows seem to trust the BIOS much less than linux does. It becomes more and more obvious over time exactly why. One problem however is that windows gets away with this because many vendors ship random extra gunge for their box with the system. We dont yet have that power Right. So we always need to keep heuristics in our toolbox to fallback on, so we can run on boards with incomplete information. However there is a lot of things we can do that we aren't currently doing. The example that sticks out in my head is we rely on the MP table to tell us if the local apic is in pic_mode or in virtual wire mode. When all we really have to do is ask it. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
On Thu, 3 May 2001, Edward Spidre wrote: > > Sure, I'm more than willing to test out patches. Just > let me know which version of source to apply it > against. Ok, this is not a patch per se, just a description of what I think should work.. In include/asm-i386/pci.h, change the line #define PCIBIOS_MIN_MEM 0x1000 into extern unsigned long pci_mem_start; #define PCIBIOS_MIN_MEM (pci_mem_start) In arch/i386/kernel/setup.c, at the very end of the "setup_arch()" function, add /* Start PCI allocations at max_low_memory rounded up to 1MB */ pci_mem_start = ((max_low_pfn << PAGE_SHIFT) + 0xf) & ~0xf; and somewhere in the same file, add the actual variable: unsigned long pci_mem_start = 0x1000; and you're done. Does this work for you? Alan, do you have access to that Dell laptop to test? The thing looks obvious, but I'd rather not apply it to my tree until somebody sends me the above back as a tested patch.. Call me a sissy. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
> I suspect it would be safe to round up to the next megabyte, possibly up > to 64MB or so. But much more would make me nervous. > Any suggestions? I'd go for 1MByte simply because I've not seen an EBDA/NVRAM area that large stuck at the top of RAM. 1Mb would fix the Dell. (It was only when I saw your email it suddenely clicked and I grabbed the bootup log) > > Semi related question: To do I2O properly I need to grab PCI bus space and > > 'loan' it to the controller when I configure it. Im wondering what the > > preferred approach there is. > > Do the same thing that the yenta driver does, just do a > > root = pci_find_parent_resource(dev, res); > allocate_resource(root, res, size, min, max, align, NULL, NULL); > > and keep it allocated (and then the i2o driver can do sub-allocations > within that resource by doing "allocate_resource(res, ...)"). Thanks. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
Linus Torvalds wrote: > The question is mainly _which_ power of two. > > I don't think we can round up infinitely, as that might just end up > causing us to not have any PCI space at all. Or we could end up deciding > that real PCI space is memory, and then getting a clash when a real device > tries to register its bios-allocated area that clashes with our extreme > rounding. > > I suspect it would be safe to round up to the next megabyte, possibly up > to 64MB or so. But much more would make me nervous. > > Any suggestions? Is there any chance you could simply test the bottom of PCI address space? If you could set up the x86 to trap non-DRAM read/writes temporarily, you could tell where useable DRAM area stops. -- Jeff Garzik | Game called on account of naked chick Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
On Thu, 3 May 2001, Alan Cox wrote: > > Obvious one is to go to the next power of two clear. The question is mainly _which_ power of two. I don't think we can round up infinitely, as that might just end up causing us to not have any PCI space at all. Or we could end up deciding that real PCI space is memory, and then getting a clash when a real device tries to register its bios-allocated area that clashes with our extreme rounding. I suspect it would be safe to round up to the next megabyte, possibly up to 64MB or so. But much more would make me nervous. Any suggestions? > Semi related question: To do I2O properly I need to grab PCI bus space and > 'loan' it to the controller when I configure it. Im wondering what the > preferred approach there is. Do the same thing that the yenta driver does, just do a root = pci_find_parent_resource(dev, res); allocate_resource(root, res, size, min, max, align, NULL, NULL); and keep it allocated (and then the i2o driver can do sub-allocations within that resource by doing "allocate_resource(res, ...)"). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
> at ALL. Which means that Linux thinks that it is free... And Linux will > place PCI devices there. Even though there certainly is memory there. Ahah.. that explains the Dell inspiron 8000 cardbus + 256Mb bug as well. > I'll have to work around the BIOS bug some way. Will you be willing to > try out patches? Obvious one is to go to the next power of two clear. Semi related question: To do I2O properly I need to grab PCI bus space and 'loan' it to the controller when I configure it. Im wondering what the preferred approach there is. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
On Thu, 3 May 2001, Edward Spidre wrote: > > Note: a diff between booting with mem and without it > yield the same results (the user-defined phys ram map > is identical to the bios provided one) Interesting. Your BIOS-provided memory map is buggy: > BIOS-provided physical RAM map: > BIOS-e820: 0009fc00 @ (usable) > BIOS-e820: 0400 @ 0009fc00 (reserved) > BIOS-e820: c000 @ 000c (reserved) > BIOS-e820: 13eec000 @ 0010 (usable) > BIOS-e820: 4000 @ 13fec000 (reserved) > BIOS-e820: 0020 @ ffe0 (reserved) Note how it says that you have usable RAM from 0010 - 13fec000 (the thing is hard to read and the output was changed in later kernels: it really says that you have 13eec000 bytes of ram starting at 0010, which obviously doing the math means that it goes up to 13fec000). Now, it then says that you have reserved memory (ie probably the BIOS has reserved 1kB at high memory) from 13fec000 - 13ff In particular, notice how it does NOT mention the memory region from 13ff - 1400 at ALL. Which means that Linux thinks that it is free... And Linux will place PCI devices there. Even though there certainly is memory there. I'll have to work around the BIOS bug some way. Will you be willing to try out patches? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
On Thu, 3 May 2001, Edward Spidre wrote: Note: a diff between booting with mem and without it yield the same results (the user-defined phys ram map is identical to the bios provided one) Interesting. Your BIOS-provided memory map is buggy: BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 13eec000 @ 0010 (usable) BIOS-e820: 4000 @ 13fec000 (reserved) BIOS-e820: 0020 @ ffe0 (reserved) Note how it says that you have usable RAM from 0010 - 13fec000 (the thing is hard to read and the output was changed in later kernels: it really says that you have 13eec000 bytes of ram starting at 0010, which obviously doing the math means that it goes up to 13fec000). Now, it then says that you have reserved memory (ie probably the BIOS has reserved 1kB at high memory) from 13fec000 - 13ff In particular, notice how it does NOT mention the memory region from 13ff - 1400 at ALL. Which means that Linux thinks that it is free... And Linux will place PCI devices there. Even though there certainly is memory there. I'll have to work around the BIOS bug some way. Will you be willing to try out patches? Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
at ALL. Which means that Linux thinks that it is free... And Linux will place PCI devices there. Even though there certainly is memory there. Ahah.. that explains the Dell inspiron 8000 cardbus + 256Mb bug as well. I'll have to work around the BIOS bug some way. Will you be willing to try out patches? Obvious one is to go to the next power of two clear. Semi related question: To do I2O properly I need to grab PCI bus space and 'loan' it to the controller when I configure it. Im wondering what the preferred approach there is. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
On Thu, 3 May 2001, Alan Cox wrote: Obvious one is to go to the next power of two clear. The question is mainly _which_ power of two. I don't think we can round up infinitely, as that might just end up causing us to not have any PCI space at all. Or we could end up deciding that real PCI space is memory, and then getting a clash when a real device tries to register its bios-allocated area that clashes with our extreme rounding. I suspect it would be safe to round up to the next megabyte, possibly up to 64MB or so. But much more would make me nervous. Any suggestions? Semi related question: To do I2O properly I need to grab PCI bus space and 'loan' it to the controller when I configure it. Im wondering what the preferred approach there is. Do the same thing that the yenta driver does, just do a root = pci_find_parent_resource(dev, res); allocate_resource(root, res, size, min, max, align, NULL, NULL); and keep it allocated (and then the i2o driver can do sub-allocations within that resource by doing allocate_resource(res, ...)). Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
Linus Torvalds wrote: The question is mainly _which_ power of two. I don't think we can round up infinitely, as that might just end up causing us to not have any PCI space at all. Or we could end up deciding that real PCI space is memory, and then getting a clash when a real device tries to register its bios-allocated area that clashes with our extreme rounding. I suspect it would be safe to round up to the next megabyte, possibly up to 64MB or so. But much more would make me nervous. Any suggestions? Is there any chance you could simply test the bottom of PCI address space? If you could set up the x86 to trap non-DRAM read/writes temporarily, you could tell where useable DRAM area stops. -- Jeff Garzik | Game called on account of naked chick Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
I suspect it would be safe to round up to the next megabyte, possibly up to 64MB or so. But much more would make me nervous. Any suggestions? I'd go for 1MByte simply because I've not seen an EBDA/NVRAM area that large stuck at the top of RAM. 1Mb would fix the Dell. (It was only when I saw your email it suddenely clicked and I grabbed the bootup log) Semi related question: To do I2O properly I need to grab PCI bus space and 'loan' it to the controller when I configure it. Im wondering what the preferred approach there is. Do the same thing that the yenta driver does, just do a root = pci_find_parent_resource(dev, res); allocate_resource(root, res, size, min, max, align, NULL, NULL); and keep it allocated (and then the i2o driver can do sub-allocations within that resource by doing allocate_resource(res, ...)). Thanks. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible PCI subsystem bug in 2.4
On Thu, 3 May 2001, Edward Spidre wrote: Sure, I'm more than willing to test out patches. Just let me know which version of source to apply it against. Ok, this is not a patch per se, just a description of what I think should work.. In include/asm-i386/pci.h, change the line #define PCIBIOS_MIN_MEM 0x1000 into extern unsigned long pci_mem_start; #define PCIBIOS_MIN_MEM (pci_mem_start) In arch/i386/kernel/setup.c, at the very end of the setup_arch() function, add /* Start PCI allocations at max_low_memory rounded up to 1MB */ pci_mem_start = ((max_low_pfn PAGE_SHIFT) + 0xf) ~0xf; and somewhere in the same file, add the actual variable: unsigned long pci_mem_start = 0x1000; and you're done. Does this work for you? Alan, do you have access to that Dell laptop to test? The thing looks obvious, but I'd rather not apply it to my tree until somebody sends me the above back as a tested patch.. Call me a sissy. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
