Messages in this thread | | | Date | Thu, 10 Feb 2000 19:48:10 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: 2.3.43 alpha broken with >2g of ram |
| |
On Thu, 10 Feb 2000, David S. Miller wrote:
>It sounds just like the SCSI drivers need to be fixed to use >the new PCI dma interfaces, that's all. [..] >I have such changes for the two biggies, aic7xxx and sym53c8xx. >Qlogic,ISP is already done and in Linus's tree.
_All_ drivers that does some kind of PCI-DMA are been broken by 2.3.43 (not only the network and scsi drivers).
There are not a few SCSI drivers and some network card in the kernel.
andrea@alpha:~/kernel/2.3.43/drivers > find scsi/ -type f | wc -l 252 andrea@alpha:~/kernel/2.3.43/drivers > find -type f | wc -l 1820
Not all drivers are doing PCI-DMA of course, but a good percentage yes and brekaing the whole thing is something should be done at the _start_ and not at the _end_ of an unstable branch IMVHO (btw, I am assuming we are at the end). Here I don't have the 9 alpha platforms each with more than 2giga of ram and all the device driver tha does PCI-DMA to try out if they works or not. And that's not my own problem but I think it's a problem of most maintainers of the drivers. To be sure all is working correctly it's necessary to give the time to the people who has all this flavours of hardware to test the thing and feed us bugreports.
And I am not either sure if all alpha plaforms are capable of a PCIMMU and if they can support more than 2/4giga of ram at the same time, Richard what's going on (in 2.3.43) for:
o irongate o polaris o t2
In 2.3.43 they have _no_ way to work _even_ supposing all drivers out there would be just using the pci_map/umap if there's more then 2/4 giga of RAM in the system. Is the hardware memory limited to 2/4 giga for such platforms?
And what you break is not something that won't compile. Is not either something that won't work. All will work fine and compile until the unlucky user will try to run a special driver on a certain flavour of alpha with >2g of RAM installed in the system.
>not do is work on forward-porting the band-aid 2TB support hacks you >did for 2.2.x (which for 2.2.x was the correct way to do it) and
If I won't do anything what is going to happen is that 2.4.0 will produce random bug reports on alpha only with a bigmemory setup and that's very bad IMHO. Such big machines should be the ones running most reliable. Give me a good reason for not doing that or tell me a shostopper that my way has please.
Since you say you just fixed your commonly used drivers you also know the only downside you would have from running my work is that the dcache and the icache and the other kernel-proper stuff will stay locked in the first 2giga of RAM (at least if I am not going to add a __GFP_XX in the allocations). But that doesn't seems a problem at all to me. Is it a problem for you? I think nobody needs more than 2giga of RAM outside userspace/shm memory and outside the page cache in the next few years.
And no, in my way I won't do I/O bounces with the updated scsi drivers and I'll use the whole memory for allocating skb on updated nic drivers (hoping the hardware and your recent work in arch/alpha/kernel/core_* is not buggy).
When 2.5.0 will be out removing all the |__GFP_XX will be done with a script simpler than the one that cleanedup the fops initializers and the __GFP_XX will be defined as a zero. And once the script will return I'll break things exactly as you did in 2.3.43 (but at that time most drivers will been updated and breaking in 2.5.0 is not a problem at all) and during 2.4.* I always run rock solid and as fast and as powerful as the official 2.4.*.
I'd appreciate if you reply telling me where I am wrong. Thanks.
Andrea
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |