lkml.org 
[lkml]   [2000]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.118 / U:0.952 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site