Swap strangeness using 2.4.5pre2aa1

Swap strangeness using 2.4.5pre2aa1

[G. Hugh Song]

My Alpha/LInux UP2000 SMP with 1GB memory is running kernel
2.4.5pre2aa1. 
I have been observing some strangeness with Swap usage quite recently 
(in fact since 2.4.4).  Unfortunately, the kernel was made using 
gcc-2.95.2-136.alpha.rpm provided by SuSE-7.0.

The following is the output from "free"
=========================================================================
             total       used       free     shared    buffers    
cached
Mem:       1023128    1015640       7488          0        544    
948976
-/+ buffers/cache:      66120     957008
Swap:      1021936    1021936          0
==========================================================================

And the following is the output from "top"
===========================================================================
  3:09am  up 3 days,  5:49,  7 users,  load average: 1.60, 2.02, 3.05
82 processes: 79 sleeping, 3 running, 0 zombie, 0 stopped
CPU states:  0.1% user,  4.0% system, 80.3% nice, 15.4% idle
Mem:  1023128K av, 1016128K used,    7000K free,       0K shrd,     736K
buff
Swap: 1021936K av, 1021936K used,       0K free                  948968K
cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME
COMMAND
 9555 sekim     20  10  437M 345M  345M R N  108M 90.4 17.2  1881m
full.ax
 9547 sekim     18  10 95624  24M   792 R N   13M 75.8  1.2  1424m
optcon.ax
21133 hugh      16   0  1976 1976  1648 R    1872  1.0  0.0   0:02 top
    5 root      12   0     0    0     0 SW      0  0.4  0.0 151:52
kswapd
    1 root      12   0   128  104   104 S      16  0.0  0.0   0:44 init
    2 root      12   0     0    0     0 SW      0  0.0  0.0   0:00
keventd
    3 root      20  19     0    0     0 SWN     0  0.0  0.0   0:01
ksoftirqd_CP
    4 root      20  19     0    0     0 SWN     0  0.0  0.0   0:00
ksoftirqd_CP
    6 root      12   0     0    0     0 SW      0  0.0  0.0   0:00
kreclaimd
    7 root      12   0     0    0     0 SW      0  0.0  0.0   0:00
bdflush
    8 root      12   0     0    0     0 SW      0  0.0  0.0   1:03
kupdated
  159 bin       12   0   216  136   136 S     128  0.0  0.0   2:31
portmap
  183 root      12   0   272  168   168 S     120  0.0  0.0   4:25
syslogd
  187 root      12   0   960    8     8 S       0  0.0  0.0   0:06 klogd
  227 root      12   0   136    8     8 S       0  0.0  0.0   0:00
rpc.rquotad

......

=============================================================================

At this point, the mouse movement crawls down at an unacceptable level. 
I 
cannot understand that the above showing of 0 free space of swap space 
although the sum of all memeory usages is far less than 1GB.

I understand that free swap space may become close to 0 and stay there
for 
a while once it ever reached down close to zero.  However, it should
back 
up some nonzero number if the situation is cleared.

Please tell me whether something is wrong or not with the kernel.  If
so, 
I think I should back down to Kernel 2.2.20pre2aa1.

Thank you very much.

-- 
G. Hugh Song

Assoc. Professor
Office: +82-62-970-2210 fax: -3156 handphone: +82-16-608-2210
Email:  ghsong@kjist.ac.kr
Department of Information and Communications
Kwangju Institute of Science and Technology
1 Oryong-dong, Buk-gu, Gwangju, 500-712 South KOREA

Re: Swap strangeness using 2.4.5pre2aa1

[Andrea Arcangeli]

On Thu, May 24, 2001 at 03:16:48AM +0900, G. Hugh Song wrote:
> The following is the output from "free"
> =========================================================================
>              total       used       free     shared    buffers    
> cached
> Mem:       1023128    1015640       7488          0        544    
> 948976
> -/+ buffers/cache:      66120     957008
> Swap:      1021936    1021936          0
> ==========================================================================

I get the same with egcs. To me it sounds broken VM (I shouldn't have
changed anything that can confuse the VM so this should be reproducible
with 2.4.5pre5 vanilla and infact you also said you reproduced
previously in 2.4.4).

Is it possible you booted with 'mem=something'? It seems to me that when
I boot with 'mem=something' the VM bad beahaviour become more visible.

> I think I should back down to Kernel 2.2.20pre2aa1.

definitely a good idea until somebody fixes the VM in mainline.

Andrea

2.4.5 does not link on Ruffian (alpha)

[Ingo T. Storm]

Hi,

I just tried to compile 2.4.5 on a Ruffian. With CPU selection "generic" it
fails when linking the kernel (see below). With CPU=Ruffian, it compiles and
links fine. Haven't tried booting yet, 'cause the machine is some 20 miles
away from here.

What more can I provide/do to help?

Cheers,
Ingo

-------------

ld  -r -o kernel.o entry.o traps.o process.o osf_sys.o irq.o irq_alpha.o
signal.
o setup.o ptrace.o time.o semaphore.o alpha_ksyms.o irq_i8259.o irq_srm.o
es1888
.o smc37c669.o smc37c93x.o ns87312.o pci.o pci_iommu.o core_apecs.o
core_cia.o c
ore_irongate.o core_lca.o core_mcpcia.o core_polaris.o core_t2.o
core_tsunami.o
core_titan.o sys_alcor.o sys_cabriolet.o sys_dp264.o sys_eb64p.o sys_eiger.o
sys
_jensen.o sys_miata.o sys_mikasa.o sys_nautilus.o sys_titan.o sys_noritake.o
sys
_rawhide.o sys_ruffian.o sys_rx164.o sys_sable.o sys_sio.o sys_sx164.o
sys_takar
a.o sys_wildfire.o core_wildfire.o irq_pyxis.o
sys_dp264.o: In function `tsunami_inb':
sys_dp264.c(.text+0x440): multiple definition of `tsunami_inb'
core_tsunami.o(.text+0x500):core_tsunami.c: first defined here
sys_dp264.o: In function `clipper_map_irq':
sys_dp264.c(.text+0x480): multiple definition of `tsunami_inw'
core_tsunami.o(.text+0x540):core_tsunami.c: first defined here
sys_dp264.o: In function `tsunami_inl':
sys_dp264.c(.text+0x4c0): multiple definition of `tsunami_inl'
core_tsunami.o(.text+0x580):core_tsunami.c: first defined here
sys_dp264.o: In function `tsunami_outb':
sys_dp264.c(.text+0x460): multiple definition of `tsunami_outb'
core_tsunami.o(.text+0x520):core_tsunami.c: first defined here
sys_dp264.o: In function `tsunami_outw':
sys_dp264.c(.text+0x4a0): multiple definition of `tsunami_outw'
core_tsunami.o(.text+0x560):core_tsunami.c: first defined here
sys_dp264.o: In function `dp264_init_pci':
sys_dp264.c(.text+0x4e0): multiple definition of `tsunami_outl'
core_tsunami.o(.text+0x5a0):core_tsunami.c: first defined here
sys_dp264.o: In function `tsunami_readb':
sys_dp264.c(.text+0x540): multiple definition of `tsunami_readb'
core_tsunami.o(.text+0x600):core_tsunami.c: first defined here
sys_dp264.o: In function `tsunami_readw':
sys_dp264.c(.text+0x560): multiple definition of `tsunami_readw'
core_tsunami.o(.text+0x620):core_tsunami.c: first defined here
sys_dp264.o: In function `webbrick_init_arch':
sys_dp264.c(.text+0x580): multiple definition of `tsunami_readl'
core_tsunami.o(.text+0x640):core_tsunami.c: first defined here
sys_dp264.o: In function `tsunami_readq':
sys_dp264.c(.text+0x5a0): multiple definition of `tsunami_readq'
core_tsunami.o(.text+0x660):core_tsunami.c: first defined here
sys_dp264.o: In function `tsunami_writeb':
sys_dp264.c(.text+0x5c0): multiple definition of `tsunami_writeb'
core_tsunami.o(.text+0x680):core_tsunami.c: first defined here
sys_dp264.o: In function `tsunami_writew':
sys_dp264.c(.text+0x5e0): multiple definition of `tsunami_writew'
core_tsunami.o(.text+0x6a0):core_tsunami.c: first defined here
sys_dp264.o: In function `tsunami_writel':
sys_dp264.c(.text+0x600): multiple definition of `tsunami_writel'
core_tsunami.o(.text+0x6c0):core_tsunami.c: first defined here
sys_dp264.o: In function `tsunami_writeq':
sys_dp264.c(.text+0x620): multiple definition of `tsunami_writeq'
core_tsunami.o(.text+0x6e0):core_tsunami.c: first defined here
sys_dp264.o: In function `tsunami_ioremap':
sys_dp264.c(.text+0x500): multiple definition of `tsunami_ioremap'
core_tsunami.o(.text+0x5c0):core_tsunami.c: first defined here
sys_dp264.o: In function `monet_init_pci':
sys_dp264.c(.text+0x520): multiple definition of `tsunami_is_ioaddr'
core_tsunami.o(.text+0x5e0):core_tsunami.c: first defined here
make[1]: *** [kernel.o] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.5/arch/alpha/kernel'
make: *** [_dir_arch/alpha/kernel] Error 2

Re: 2.4.5 does not link on Ruffian (alpha)

[Andrea Arcangeli]

On Sat, May 26, 2001 at 05:20:29PM +0200, Ingo T. Storm wrote:
> sys_dp264.o: In function `tsunami_inb':
> sys_dp264.c(.text+0x440): multiple definition of `tsunami_inb'
> core_tsunami.o(.text+0x500):core_tsunami.c: first defined here
> sys_dp264.o: In function `clipper_map_irq':
> sys_dp264.c(.text+0x480): multiple definition of `tsunami_inw'
> core_tsunami.o(.text+0x540):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_inl':
> sys_dp264.c(.text+0x4c0): multiple definition of `tsunami_inl'
> core_tsunami.o(.text+0x580):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_outb':
> sys_dp264.c(.text+0x460): multiple definition of `tsunami_outb'
> core_tsunami.o(.text+0x520):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_outw':
> sys_dp264.c(.text+0x4a0): multiple definition of `tsunami_outw'
> core_tsunami.o(.text+0x560):core_tsunami.c: first defined here
> sys_dp264.o: In function `dp264_init_pci':
> sys_dp264.c(.text+0x4e0): multiple definition of `tsunami_outl'
> core_tsunami.o(.text+0x5a0):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_readb':
> sys_dp264.c(.text+0x540): multiple definition of `tsunami_readb'
> core_tsunami.o(.text+0x600):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_readw':
> sys_dp264.c(.text+0x560): multiple definition of `tsunami_readw'
> core_tsunami.o(.text+0x620):core_tsunami.c: first defined here
> sys_dp264.o: In function `webbrick_init_arch':
> sys_dp264.c(.text+0x580): multiple definition of `tsunami_readl'
> core_tsunami.o(.text+0x640):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_readq':
> sys_dp264.c(.text+0x5a0): multiple definition of `tsunami_readq'
> core_tsunami.o(.text+0x660):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_writeb':
> sys_dp264.c(.text+0x5c0): multiple definition of `tsunami_writeb'
> core_tsunami.o(.text+0x680):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_writew':
> sys_dp264.c(.text+0x5e0): multiple definition of `tsunami_writew'
> core_tsunami.o(.text+0x6a0):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_writel':
> sys_dp264.c(.text+0x600): multiple definition of `tsunami_writel'
> core_tsunami.o(.text+0x6c0):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_writeq':
> sys_dp264.c(.text+0x620): multiple definition of `tsunami_writeq'
> core_tsunami.o(.text+0x6e0):core_tsunami.c: first defined here
> sys_dp264.o: In function `tsunami_ioremap':
> sys_dp264.c(.text+0x500): multiple definition of `tsunami_ioremap'
> core_tsunami.o(.text+0x5c0):core_tsunami.c: first defined here
> sys_dp264.o: In function `monet_init_pci':
> sys_dp264.c(.text+0x520): multiple definition of `tsunami_is_ioaddr'
> core_tsunami.o(.text+0x5e0):core_tsunami.c: first defined here
> make[1]: *** [kernel.o] Error 1
> make[1]: Leaving directory `/usr/src/linux-2.4.5/arch/alpha/kernel'
> make: *** [_dir_arch/alpha/kernel] Error 2

I got exactly the above when compiling for dp264 so I sent to Linus a
patch to fix those compile problems, now I suspect my fix broke the
generic compile :(, I will check that.

Andrea

Re: 2.4.5 does not link on Ruffian (alpha)

[Andrea Arcangeli]

On Sat, May 26, 2001 at 07:36:49PM +0200, Andrea Arcangeli wrote:
> I got exactly the above when compiling for dp264 so I sent to Linus a
> patch to fix those compile problems, now I suspect my fix broke the
> generic compile :(, I will check that.

2.4.5aa1 compiles fine, but 2.4.5 doesn't, don't know why yet. Please
backout this patch from 2.4.5 for now, this should be the right thing to
do in the long run:

diff -urN alpha/arch/alpha/kernel/sys_dp264.c alpha-1/arch/alpha/kernel/sys_dp264.c
--- alpha/arch/alpha/kernel/sys_dp264.c	Sun Apr  1 01:17:07 2001
+++ alpha-1/arch/alpha/kernel/sys_dp264.c	Wed May 23 02:43:49 2001
@@ -16,15 +16,18 @@
 #include <linux/pci.h>
 #include <linux/init.h>
 
+#define __EXTERN_INLINE inline
+#include <asm/io.h>
+#include <asm/core_tsunami.h>
+#undef  __EXTERN_INLINE
+
 #include <asm/ptrace.h>
 #include <asm/system.h>
 #include <asm/dma.h>
 #include <asm/irq.h>
 #include <asm/bitops.h>
 #include <asm/mmu_context.h>
-#include <asm/io.h>
 #include <asm/pgtable.h>
-#include <asm/core_tsunami.h>
 #include <asm/hwrpb.h>
 
 #include "proto.h"


Now I will start a robot that will tell me in some hour of computations
which of the patches in my tree actually makes me to need the above
patch to compile both generic and dp264 correctly. After I localized the
offender patch it should be very easy to found why I need the above and
2.4.5 doesn't.

Andrea

Re: 2.4.5 does not link on Ruffian (alpha)

[Jeff Garzik]

Andrea Arcangeli wrote:
> diff -urN alpha/arch/alpha/kernel/sys_dp264.c alpha-1/arch/alpha/kernel/sys_dp264.c
> --- alpha/arch/alpha/kernel/sys_dp264.c Sun Apr  1 01:17:07 2001
> +++ alpha-1/arch/alpha/kernel/sys_dp264.c       Wed May 23 02:43:49 2001
> @@ -16,15 +16,18 @@
>  #include <linux/pci.h>
>  #include <linux/init.h>
> 
> +#define __EXTERN_INLINE inline
> +#include <asm/io.h>
> +#include <asm/core_tsunami.h>
> +#undef  __EXTERN_INLINE
> +

Why is "__EXTERN_INLINE" defined as "inline" not "extern inline"?

I simply added "extern" and things started working (as noted in my
previous message in this thread)..

-- 
Jeff Garzik      | Disbelief, that's why you fail.
Building 1024    |
MandrakeSoft     |

Re: 2.4.5 does not link on Ruffian (alpha)

[Andrea Arcangeli]

On Sat, May 26, 2001 at 09:02:21PM -0400, Jeff Garzik wrote:
> Andrea Arcangeli wrote:
> > diff -urN alpha/arch/alpha/kernel/sys_dp264.c alpha-1/arch/alpha/kernel/sys_dp264.c
> > --- alpha/arch/alpha/kernel/sys_dp264.c Sun Apr  1 01:17:07 2001
> > +++ alpha-1/arch/alpha/kernel/sys_dp264.c       Wed May 23 02:43:49 2001
> > @@ -16,15 +16,18 @@
> >  #include <linux/pci.h>
> >  #include <linux/init.h>
> > 
> > +#define __EXTERN_INLINE inline
> > +#include <asm/io.h>
> > +#include <asm/core_tsunami.h>
> > +#undef  __EXTERN_INLINE
> > +
> 
> Why is "__EXTERN_INLINE" defined as "inline" not "extern inline"?

because it must be implemented somewhere for the alpha_mv pointer to
functions and for some reason they are not implemented by
core_tsunami.c in my tree (but they are in mainline and that's right).

> I simply added "extern" and things started working (as noted in my
> previous message in this thread)..

defining it as `extern inline' is completly equivalent to backing out
the patch I posted, see core_tsunami.h:

#ifndef __EXTERN_INLINE
#define __EXTERN_INLINE extern inline
#define __IO_EXTERN_INLINE
#endif

Of course your patch works like a charm too. A cleaner fix is to backout my
patch because core_tsunami.h will define it to `extern inline'
atuomatically.

Tomorrow I'll go through the log generated by the script that did the
binary search for me while I was out to find out what patch in my tree
caused me to write the posted patch to get all compilations right.

Andrea

Re: 2.4.5 does not link on Ruffian (alpha)

[Andrea Arcangeli]

On Sun, May 27, 2001 at 04:49:24AM +0200, Andrea Arcangeli wrote:
> caused me to write the posted patch to get all compilations right.

The reason I needed that patch is that I was not using 2.4.5aa1 but a
corrupted tree (I'm been fooled by an hardlink during developement), it
was just two lines away from the real one.

So this is the fix for all 2.4.5 based trees (ac1 and aa1 included) to
get generic and dp264 compililations right:

diff -urN 2.4.5/arch/alpha/kernel/sys_dp264.c fix/arch/alpha/kernel/sys_dp264.c
--- 2.4.5/arch/alpha/kernel/sys_dp264.c	Sat May 26 04:03:35 2001
+++ fix/arch/alpha/kernel/sys_dp264.c	Sun May 27 18:12:53 2001
@@ -16,18 +16,15 @@
 #include <linux/pci.h>
 #include <linux/init.h>
 
-#define __EXTERN_INLINE inline
-#include <asm/io.h>
-#include <asm/core_tsunami.h>
-#undef  __EXTERN_INLINE
-
 #include <asm/ptrace.h>
 #include <asm/system.h>
 #include <asm/dma.h>
 #include <asm/irq.h>
 #include <asm/bitops.h>
 #include <asm/mmu_context.h>
+#include <asm/io.h>
 #include <asm/pgtable.h>
+#include <asm/core_tsunami.h>
 #include <asm/hwrpb.h>
 
 #include "proto.h"


Sorry about that.

Andrea

Re: 2.4.5 does not link on Ruffian (alpha)

[Andrea Arcangeli]

On Sun, May 27, 2001 at 06:41:23PM +0200, Andrea Arcangeli wrote:
> On Sun, May 27, 2001 at 04:49:24AM +0200, Andrea Arcangeli wrote:
> > caused me to write the posted patch to get all compilations right.
> 
> The reason I needed that patch is that I was not using 2.4.5aa1 but a
> corrupted tree (I'm been fooled by an hardlink during developement), it
> was just two lines away from the real one.
> 
> So this is the fix for all 2.4.5 based trees (ac1 and aa1 included) to
> get generic and dp264 compililations right:

woops, the dp264 compilation wasn't right yet, this additional patch is
needed too.

--- 2.4.5aa2/arch/alpha/kernel/core_tsunami.c.~1~	Sat May 26 04:03:35 2001
+++ 2.4.5aa2/arch/alpha/kernel/core_tsunami.c	Sun May 27 20:44:59 2001
@@ -11,7 +11,6 @@
 #include <linux/pci.h>
 #include <linux/sched.h>
 #include <linux/init.h>
-#include <linux/bootmem.h>
 
 #include <asm/ptrace.h>
 #include <asm/system.h>
@@ -21,6 +20,8 @@
 #include <asm/io.h>
 #include <asm/core_tsunami.h>
 #undef __EXTERN_INLINE
+
+#include <linux/bootmem.h>
 
 #include "proto.h"
 #include "pci_impl.h"


the bootmem include was the one that broke the __EXTERN_INLINE logic for
dp264.

Andrea

Re: 2.4.5 does not link on Ruffian (alpha)

[Magnus Naeslund(f)]

From: "Andrea Arcangeli" <andrea@suse.de>
> On Sun, May 27, 2001 at 06:41:23PM +0200, Andrea Arcangeli wrote:
> > On Sun, May 27, 2001 at 04:49:24AM +0200, Andrea Arcangeli wrote:
> > > caused me to write the posted patch to get all compilations right.
> >
> > The reason I needed that patch is that I was not using 2.4.5aa1 but a
> > corrupted tree (I'm been fooled by an hardlink during developement), it
> > was just two lines away from the real one.
> >
> > So this is the fix for all 2.4.5 based trees (ac1 and aa1 included) to
> > get generic and dp264 compililations right:
>
> woops, the dp264 compilation wasn't right yet, this additional patch is
> needed too.
>

2.4.5aa1 broke on my ruffian, now it works beautifully, now i just gotta
check if it boots :)

Magnus Naeslund

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Programmer/Networker [|] Magnus Naeslund
 PGP Key: http://www.genline.nu/mag_pgp.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

[PATCH] Re: 2.4.5 does not link on Ruffian (alpha)

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

"Ingo T. Storm" wrote:
> I just tried to compile 2.4.5 on a Ruffian. With CPU selection "generic" it
> fails when linking the kernel (see below). With CPU=Ruffian, it compiles and
> links fine. Haven't tried booting yet, 'cause the machine is some 20 miles
> away from here.

> ld  -r -o kernel.o entry.o traps.o process.o osf_sys.o irq.o irq_alpha.o
> signal.
> o setup.o ptrace.o time.o semaphore.o alpha_ksyms.o irq_i8259.o irq_srm.o
> es1888
> .o smc37c669.o smc37c93x.o ns87312.o pci.o pci_iommu.o core_apecs.o
> core_cia.o c
> ore_irongate.o core_lca.o core_mcpcia.o core_polaris.o core_t2.o
> core_tsunami.o
> core_titan.o sys_alcor.o sys_cabriolet.o sys_dp264.o sys_eb64p.o sys_eiger.o
> sys
> _jensen.o sys_miata.o sys_mikasa.o sys_nautilus.o sys_titan.o sys_noritake.o
> sys
> _rawhide.o sys_ruffian.o sys_rx164.o sys_sable.o sys_sio.o sys_sx164.o
> sys_takar
> a.o sys_wildfire.o core_wildfire.o irq_pyxis.o
> sys_dp264.o: In function `tsunami_inb':
> sys_dp264.c(.text+0x440): multiple definition of `tsunami_inb'
> core_tsunami.o(.text+0x500):core_tsunami.c: first defined here

I used the attached patch to fix the problem.

(note the tty.h changes are unrelated...  they are preparing for when
sched.h no longer includes tty.h, fixing a nasty include loop)

-- 
Jeff Garzik      | Disbelief, that's why you fail.
Building 1024    |
MandrakeSoft     |

[-- Attachment #2: alpha.patch --]
[-- Type: text/plain, Size: 1592 bytes --]

Index: arch/alpha/kernel/process.c
===================================================================
RCS file: /cvsroot/gkernel/linux_2_4/arch/alpha/kernel/process.c,v
retrieving revision 1.1.1.14
diff -u -r1.1.1.14 process.c
--- arch/alpha/kernel/process.c	2001/05/25 01:09:03	1.1.1.14
+++ arch/alpha/kernel/process.c	2001/05/26 22:00:59
@@ -28,6 +28,7 @@
 #include <linux/mman.h>
 #include <linux/elfcore.h>
 #include <linux/reboot.h>
+#include <linux/tty.h>
 #include <linux/console.h>
 
 #include <asm/reg.h>
Index: arch/alpha/kernel/sys_dp264.c
===================================================================
RCS file: /cvsroot/gkernel/linux_2_4/arch/alpha/kernel/sys_dp264.c,v
retrieving revision 1.1.1.10
diff -u -r1.1.1.10 sys_dp264.c
--- arch/alpha/kernel/sys_dp264.c	2001/05/26 04:03:59	1.1.1.10
+++ arch/alpha/kernel/sys_dp264.c	2001/05/26 22:01:00
@@ -16,7 +16,7 @@
 #include <linux/pci.h>
 #include <linux/init.h>
 
-#define __EXTERN_INLINE inline
+#define __EXTERN_INLINE extern inline
 #include <asm/io.h>
 #include <asm/core_tsunami.h>
 #undef  __EXTERN_INLINE
Index: arch/alpha/kernel/sys_sio.c
===================================================================
RCS file: /cvsroot/gkernel/linux_2_4/arch/alpha/kernel/sys_sio.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 sys_sio.c
--- arch/alpha/kernel/sys_sio.c	2000/10/30 19:47:55	1.1.1.2
+++ arch/alpha/kernel/sys_sio.c	2001/05/26 22:01:00
@@ -17,6 +17,7 @@
 #include <linux/sched.h>
 #include <linux/pci.h>
 #include <linux/init.h>
+#include <linux/tty.h>
 
 #include <asm/compiler.h>
 #include <asm/ptrace.h>

Re: [PATCH] Re: 2.4.5 does not link on Ruffian (alpha)

[Jeff Garzik]

It should note, though, that -not- using CONFIG_ALPHA_GENERIC seems to
have a detrimental effect on my machines, in 2.4.5 vanilla.

When built with CONFIG_ALPHA_NAUTILUS, my UP1000's IDE totally fails. 
It probes the drives ok, on boot, but a logic hang occurs where no more
boot progress can be made.  All I get are "hda: lost interrupt"
messages.  I am booting w/ aboot 0.7a from SRM, -without- the
srm-as-bootloader kernel config option.  These problems go away when
using the generic MDK alpha kernel, which is based on Alan's '2.4.4-ac'
patchkit, and uses CONFIG_ALPHA_GENERIC.

A very similar problem occurs on my new test alpha, a miata.  With
CONFIG_ALPHA_MIATA, IDE fails with "hda: lost interrupt" as above, but
additionally, the keyboard is no longer recognized.  Again, with MDK(ac)
kernel, things work fine.

After wondering for a while what magic was in the 'ac' patchkit, I
realized that my build needed CONFIG_ALPHA_GENERIC to work.  Tested that
theory... sure enough, I can boot 2.4.5-vanilla no problems now.

-- 
Jeff Garzik      | Disbelief, that's why you fail.
Building 1024    |
MandrakeSoft     |

Re: [PATCH] Re: 2.4.5 does not link on Ruffian (alpha)

[Richard Henderson]

On Sat, May 26, 2001 at 06:48:30PM -0400, Jeff Garzik wrote:
> When built with CONFIG_ALPHA_NAUTILUS, my UP1000's IDE totally fails. 

Mine doesn't.

> I am booting w/ aboot 0.7a from SRM, -without- the
> srm-as-bootloader kernel config option. 

That is the error.


r~

Re: [PATCH] Re: 2.4.5 does not link on Ruffian (alpha)

[Jeff Garzik]

Richard Henderson wrote:
> On Sat, May 26, 2001 at 06:48:30PM -0400, Jeff Garzik wrote:
> > When built with CONFIG_ALPHA_NAUTILUS, my UP1000's IDE totally fails.
> 
> Mine doesn't.
> 
> > I am booting w/ aboot 0.7a from SRM, -without- the
> > srm-as-bootloader kernel config option.
> 
> That is the error.

Ok, thanks.

FWIW the documentation seems to imply that the option is necessary only
when directly booting from SRM, i.e.. no bootloader is involved at all. 
It uses the example of MILO's presence or absence as indicating the need
for this option.

So... is it safe to always enable this option, with a little hacking
perhaps?  :)   

Regards,

	Jeff





> Using SRM as bootloader
> CONFIG_ALPHA_SRM
>   There are two different types of booting firmware on Alphas: SRM,
>   which is command line driven, and ARC, which uses menus and arrow
>   keys. Details about the Linux/Alpha booting process are contained in
>   the Linux/Alpha FAQ, accessible on the WWW from
>   http://www.alphalinux.org .
> 
>   The usual way to load Linux on an Alpha machine is to use MILO
>   (a bootloader that lets you pass command line parameters to the
>   kernel just like lilo does for the x86 architecture) which can be
>   loaded either from ARC or can be installed directly as a permanent
>   firmware replacement from floppy (which requires changing a certain
>   jumper on the motherboard). If you want to do either of these, say N
>   here. If MILO doesn't work on your system (true for Jensen
>   motherboards), you can bypass it altogether and boot Linux directly
>   from an SRM console; say Y here in order to do that. Note that you
>   won't be able to boot from an IDE disk using SRM. 
> 
>   If unsure, say N.

-- 
Jeff Garzik      | Disbelief, that's why you fail.
Building 1024    |
MandrakeSoft     |

Re: [PATCH] Re: 2.4.5 does not link on Ruffian (alpha)

[Richard Henderson]

On Sun, May 27, 2001 at 07:54:17PM -0400, Jeff Garzik wrote:
> FWIW the documentation seems to imply that the option is necessary only
> when directly booting from SRM, i.e.. no bootloader is involved at all. 

Err, well, you can't have _no_ bootloader.

> It uses the example of MILO's presence or absence as indicating the need
> for this option.

Exactly.  aboot doesn't substitute.

> So... is it safe to always enable this option, with a little hacking
> perhaps?  :)   

Well, yes, it is obviously possible.  The generic config
does what you want.  You just need to permanently enable
some of that configury.


r~

Re: Swap strangeness using 2.4.5pre2aa1

[Rik van Riel]

On Thu, 24 May 2001, G. Hugh Song wrote:

> My Alpha/LInux UP2000 SMP with 1GB memory is running kernel

> The following is the output from "free"
> =========================================================================
>              total       used       free     shared    buffers     cached
> Mem:       1023128    1015640       7488          0        544     948976
> -/+ buffers/cache:      66120     957008
> Swap:      1021936    1021936          0
> ==========================================================================

> I understand that free swap space may become close to 0 and stay
> there for a while once it ever reached down close to zero.
> However, it should back up some nonzero number if the situation
> is cleared.

Something is wrong with the 2.4 VM.  As of yet, it cannot reclaim
swap space once it is full. This is pretty much the next thing on
my TODO list, right after the worst highmem lockups and balancing
issues have been fixed.

Watch http://www.surriel.com/patches/ closely, swap reclaiming is
next on my TODO list ;)

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/