Soo Heng (AUDTQSH) on Network Security related matters
Jenny (AUDTJCG) on PC and LAN matters.
Thank you.
>>> "linux-kernel@vger.rutgers.edu" 12/05/98 06:34 >>>
linux-kernel-digest Friday, 4 December 1998 Volume 01 : Number 2941
In this issue:
Re: schedule_timeout: wrong timeout value (A[nother] very poor bug-report)
Re: disks stats through /proc
Re: Problem with 1G RAM
[patch] morethan900MB-2.0.36
Re: Looking for SMP-capable tester
Re: Limit of 256 NFS Mounted Filesystems
ne2k in 2.1.131
Re: [OFFTOPIC] Re: linux kernel hackers discover new theory of relativity!
Re: IDE freeze for seconds
Re: NO ROM BASIC
Re: SMP scalability: 8 -> 32 CPUs
Re: Re: IDE freeze for seconds
[patch] 2.1.131, "noapic" boot option.
Re: aic7xxx Driver support faster than 20MB/sec?
Re: IDE -> ATA DISK
Re: [PATCH] swapin readahead and fixes
Re: Internationalizing Linux
Re: suspendd-v0.1.0 released
Re: Software Suspend [HELP: buffer&schedule problems]
Re: [OFFTOPIC] Re: linux kernel hackers discover new theory of relativity!
Re: IDE -> ATA DISK
Re: IDE-DMA strangeness (another one)
Re: Strange System Behavior
Re: [OFFTOPIC] Re: linux kernel hackers discover new theory of relativity!
Re: Problem with 1G RAM
Re: NO ROM BASIC
Re: Dumb question: Which is "better" SCSI or IDE disks?
Re: Linux-2.1.131..
See the end of the digest for information on subscribing to the linux-kernel
or linux-kernel-digest mailing lists.
----------------------------------------------------------------------
From: Myrdraal <myrdraal@jackalz.amnet.org>
Date: Fri, 4 Dec 1998 10:35:41 -0500
Subject: Re: schedule_timeout: wrong timeout value (A[nother] very poor bug-report)
Hi,
I, also, have seen that schedule timeout message. I can trigger it
very, very consistantly. If I run mutt 0.94.17 and view a message,
the schedule timeout kernel message scrolls repeatedly until I hit
"q" and return to the message index. The exact message is:
schedule_timeout: wrong timeout value f3333335 from c012dcdd
According to System.map, it seems to be sys_poll. Here's the excerpt:
c012dbec T sys_poll
c012de9c t fifo_open
This happened with 2.1.131 and also 2.1.131ac2. 2.1.131 was compiled
with a semi-old version of egcs, ac2 was compiled with the newest (30th)
version. This is on a AMD K6-2/333. Compile flags were -O99 -march=k6
-mcpu=k6. If more information is required, feel free to ask.
- -Myrdraal
- --
Linux jackalz 2.1.131 #5 Fri Dec 4 07:26:38 EST 1998 i586
10:29am up 2:52, 20 users, load average: 0.00, 0.00, 0.00
**[ Linux: Because a penguin makes a better mascot than Satan. ]**
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Tigran Aivazian <tigran@aivazian.demon.co.uk>
Date: Fri, 4 Dec 1998 15:17:53 +0000 (GMT)
Subject: Re: disks stats through /proc
Thanks, I have got both of them.
I will have a detailed look at them this weekend.
However, instead of doing it in /proc/stat I will try to move it into
/proc/partitions - since we have /proc/partitions already (thanks to
Andries!) we might as well enhance it to include partition-level stats.
I will also study and play with Stephen Tweedie's sard stuff
which Alan Cox mentioned yesterday.
I think, as long as it does not harm performance, detailed performance
indicators in /proc would benefit everybody.
Regards,
Tigran
On Fri, 4 Dec 1998 kfrench@unitedis.com wrote:
> I had fixed up the scsi/ide/4drive limit a while ago, but it was never
> included. It was around the IO-APIC introduction time (i.e. more
> important things were 'broken') and there were rumblings of a code freeze.
>
> Grab
> http://pebbles.net/~kfrench/linux/blockstatarray-2.1.86.gz
> http://pebbles.net/~kfrench/linux/blockstatdirect-2.1.86.gz
>
> Each one does the same thing, but does it differently (apply *only* one of
> these, not both). 'array' hold a resizeable array for each device, and
> 'direct' creates a large array up-front for performance reasons. I like
> 'array' and Mark Lord likes 'direct'. It'll need a little fixing up to
> get it going on 2.1.130, but it shouldn't be a big deal. It's also
> trivial to do this on a partition level - it's just a matter of removing
> the switch() statement which intentionally removes the per-partition parts
> of a device #.
>
> -kf
>
> On Thu, 3 Dec 1998, Tigran Aivazian wrote:
>
> > IMHO, this should be done on a fine-grained (partition level) rather than
> > coarse (drive) level. There is enough information in
> > ll_rw_blk.c/add_request() to do it now but, of course, kernel_stat
> > structure will have to be seriously modified.
> >
> > There is something frustrating about the quality and speed of Linux
> > development. I.e. the quality is too high and the speed is too high, in
> > other words, I can implement this disk stat feature, but I bet someone else
> > has already done it and is just about to release his patch to Linus soon...
>
> heh
>
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "David S. Miller" <davem@dm.cobaltmicro.com>
Date: Fri, 4 Dec 1998 08:08:45 -0800
Subject: Re: Problem with 1G RAM
From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>
Date: Fri, 4 Dec 1998 10:43:33 +0100 (CET)
Yes, those are 64bit platforms. At least I hope it works well on
sparc64, nobody confirmed it yet (somebody tried it with 2.5GB RAM
though). sparc64 should support up to 1TB physical RAM, but most
of the boxes won't allow you to put that much memory in, AFAIK it
is something around 64GB or so at most one can put in at the
moment.
Right.
In fact, even sparc32, although PAGE_OFFSET is there 0xf0000000,
should support up to 2GB memory...
Right on sun4m, and you can get away with around 3.5GB on sun4d.
The sun4m limitation is due to the IOMMU, the sun4d case is just a
matter of running out of kernel + user address space. In these
sparc32 cases the PAGE_OFFSET is set dynamically at boot time based
upon how much memory is in the machine.
Later,
David S. Miller
davem@dm.cobaltmicro.com
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: MOLNAR Ingo <mingo@chiara.csoma.elte.hu>
Date: Fri, 4 Dec 1998 16:50:53 +0100 (CET)
Subject: [patch] morethan900MB-2.0.36
On Thu, 3 Dec 1998, Leonard N. Zubkoff wrote:
> I have created a patch for Linux 2.0.36 that allows up to 2GB of physical
> memory to be utilized since we have customers that need this much or even more
> physical memory. [...]
we _definitely_ need support for more than 2G physical RAM. (eg. the
Torrent system demo on OracleWorld was run on a box with 2.5G RAM.) Also,
a 2G+2G split has performance disadvantages if the box in question has
less memory (eg. 1G RAM).
i've attached a backport of my 2.1 patch that makes the amount of
physical/virtual memory fine-tunable. (the patch is against 2.0.36).
Instead of a static split like the original kernel (and your patch,
apparently) this patch supports up to ~3.5G physical RAM, and also it does
auto-clipping and prints a warning message if available RAM is more than
configured RAM. (see Documentation/more-than-900MB-RAM.txt how to set it
up)
i've tested the patch under SMP and UP kernels, with various settings, it
works just fine. The patch does not enforce any particular 'split', it can
be configured eg 3G physical + 1G virtual too if necessary. the
unconditional 2G/2G split has some performance disadvantages, so one wants
to tune the split as much as possible. My patch enforces the 128M RAM
necessary for vmalloc() and ioremap().
- -- mingo
begin 664 morethan900MB-2.0.36.gz
M'XL(".(=:#8``VUO<F5T:&%N.3`P34(M,BXP+C,V+4$S`*5;;7?:2++^C']%
MQ7NS!DN`>+&-'2<GV"8.&V/[`-F9W)DY.D)J0&LAL7KQR\R=^>VWJKH%$F#L
M9'QFC)&ZJZN[GGJZJKI3+I?!<_WDL>KZMI<XHFI%L[+;:!U6Y]9$5*:5('0G
MA>$T@>O@'AH&U!HGM?I)LP:UX^.#'4W3MO<O?`I=N!`V0!-JAR=&\\3@KJV=
MCQ^A?*0?@G:D'\''CSOP#T>,75_`;?NR8_;:@R^%XE]%_C+H_F^G7"N5=@!;
MN6-L!Z;YI=._[ER9YHZ&CWSYK#T8='IG5]_P*2P%#H;][OG0[/7,X;?;SOGG
MSOF7`;XG!9K'>JT.VH&AUYHY)4QS/IF'05Q\+!7P?Q8G?,<=XW#\"=5]>),=
M$?:KU`H?QP%8GCOQ(9X*F`>N'XN0'M+7HB\>XQ+0XL`H2'S'"I^X9V[V[:ON
MY771<IP01R_*/[3L4OQSL4@E->APZD8PM7S'$Q&/-!.S`&7/K'FE0B.4<R/<
M?/HTZ`P+!0/GLYAR[DVQ:#S6#,,HG]]<?^I>XF`_F[U.CQ0HG9[6C=*R9[X?
MOEG,IM>^-:_[:B8TE<2/<&6$`U[@3TKR10D^?)`R!I^[GX:9Q::)+2W-L]@"
MV#"P110%88K:%>@U3AHM";UMJ%T*V0[=5D.O&:#AQW$..+WSMCE*(M-T(],R
M9Y8=!C2+<1#"O0@C-_`C<'VXBYYF4<5>@&:G#/OP-4*@1'/+1MA(/2!R?Q<G
MT+@\JT@+LY%#QPX<7$-$%D(-QN(!YA[VBG06$P7@!/Y>##;B`7'FQI#X'DE[
M"A*X\X,'>)A:,7^S0H&-77]2V=%>T`"*.$4K\>)290=RB!HB#AF9:/S'<T/^
M?+W*("338@4".=3ED/.S^770Z9OMBXM^8=$_TX"P->BT^^>?S<&PW1]"<=&J
MVB`0;</*)+9&WH+?>H$/[60"T("Z@>1V4G\%4E(1*SBI'9T<&$N<U(Z)X_!W
MBV&":TS.21(D";`0B$,AU*K",X2FL9N?6_84'1S-1@8>A9;KEQUA.1!(NB&R
M\2HY1AE[230U;>IH6IY71$<L.`'\`7\B#%P</.>QV=:S67$VV]B<N?-0KS5`
M:[;H0\WM^F;8>8-(58K`KNO?>_/)+D1B9OFQ:[/J@!P8BIGPGB"*0\(HH5NP
M!'OJSN'!]3Q`;N`I16(R$SY.UHI$2J.*W(@^$*,ZB'M!\P^2R92E^,&B&T[$
MOD.`D^N@6^!0/PFP@S`4=LQN&9-?C9X@B:B5Y;,/!>-Q)&+\`..QJ1"-+=%K
M6+>'T)KC3(C`69\[$?HXW:RJ2@PL/8*4GZ!0ZI`JH&8`15=)MKP'ZPGU$1`D
M<>0Z@OURJ4XYYS#?J9(4!2LB?DBK%,GY8708)=A%[*&1`Q_MRYN?B&)F*^Z`
M*+,\<BIAA2Q%#9;"?[D=2>R8:&NY3\"O.V7:0Y#60MA/-X]?E@;Z#1EGK4%^
MP4JE]1$6TJ%@FNC?N-.8YGW@63'"W32+"L3PUM@]@9/=V2X4UY7CZ(0=_HBC
MFMK1L8IK_ER$#J\,(:2CBS!&YT:+HD?$:)0$%PE\@0L9$[\C2PO;Q95$^/J3
M"'T3/6`>B[V(M:@;#=*B;J"3KH17P_[`O$5BO>U=%&J;GE_B<Z/>)";"C8DP
M,Y\X@-8-750AB5"%9"X]1H15"8`3:E=%DEI0/I,WRC)),&RE?=[_+R^Z_30`
M6`A16_]23%;+<FZ(4C:261G\E:,M0HUGQEN16^+I/L_5_THB="4?:2H<N<AS
M2%C*CQ6+1;$5LE/3E_L9DG-@P[][1)'6"3V4C)B@4Z('MWIG<&]YB8#_D."9
ML/Q(^C^V1']C1T4/M;CE[C3PQ"Y88PX^E:CY]"ER;02-XL\$*=G+NO&]&\;)
M\CTK&%4`V=G*CL@0.S".]`.,G>NUE0!^\-,M1]I%@LQ3"6V?_H4K7RO!/Y$3
MC\:E?`=IFV6798_62LO.];#_K1@_S84NEY-'H.\E.#VE`?X/'Z2O\$FK)"VU
MU>DR`6<7-V<)F,\OA)S1$S+;[._$FZF$[<%F_>@`UUB3'[34A=U9<#^"MV^M
MJ?[V\%?_UWB7^6LW#$(/_J=VJ+]]*ZQ'^?"$9H4[(E+W'-EYO\I$>K)K(9$1
M=VG&HZT8M*0#\]M^T2]E_M;JN6]-^O8K<FU&1IYEOT<,%):/#G(-#G/?CDJ2
MH_.AG1.Z%%=7B?.KUGQFCMP``^OG+'*P:I%G^F^P1ST3U-4.C_1:#5E>_<$V
M27N;C-V*\O7WL'CN^N-`/7ZWWC[=J=]#^[9GG@^H";8T:><N3ISX%_F87*+Q
M&T;ZA0(L#0?:&L7FA[51/#D#+OH[M%QA)0CXKNX;]3)KAW]#->K]][3+2MB@
MX,6/+ISS]Q;.R2\<4DPQWT!EA?#^/7#"78(_L!U/P'-G;KQN>CAL(I?3%LTB
M-S9=6B/7>NDW%%=4F8)F,Z0E-W[>9YJK/K.A[PO^TFI1@453G[Q9J)`(LXN'
MN?D0A'>1&=PA^&L\IP*&'";N=D6,L1PW_`5C.WPG5W[8/KOJ(,G+;\T>_JEB
MR'=DW-6N1X>M5W;6UCOG-OQ7BI'J4W=-D]_2>%I[#\U],@7_DN_L`#=A/Q'\
M;1DKXD20M6<8TV?SG7BQ0Y/(;&Y!&Q4/*Q/*]U#$8-!$ML?=<5$LPJUWT^)(
M8+\\7!;W%.S]P'@KZRD!3$[Q)A6E\+]9-`<D%'3+M5M\I95=U,?>+2)@VC/Y
M@Q!'/7".EA<%/%',;7#KG0<8F+D>3]9X3%>3\D("-@<'&\$(:U!8H0%()_!.
M&N85F'Q>@O;=P'Q>%JR@D^9:C&=S%&'`.Z"_3C/9P+`C'VJ:GLK0M-1(3&<*
MW*>8(CADC-)&FI$19G4J+*<R^`&JR?7?3C?'7)H[3JE&17B56#S&%+#+&`Q.
MY0CH?V-W4IE^H-IR_E5L17?1QC?X^X[KV[EW&-55U2Z^L==R*"W?::YDK3Y.
M2TP?**-81L'G5^A=E]US61LS'H\-HVZLO\8W[4;C$R])HT[IJ-9HI-Z`>P(F
M[7%$J9P%KD.)?CR%^L'A(M/CTC751.)`MD<\!:'`;0OS?$[LPV0>P\2*!>8(
MW1BS4A%16<JRB3/0I[S`<E17'*`LLQ7;\BE-H5J,K!'('`77@,::6E1FP%Q6
M^#1WA\LHF$7EBAH8_,H\>$F`J$"J4<0YZ[-],BR6Z\1Z<G5*C@S"B\0#I5:Z
MS*X?1*I[**@X<"^\)[60"77#G?R)LW$J-05WJJ#!JW]DZ,>X^D=-52U&'NHZ
MN,YN_%1.25?IB3F_%SQ`$W,X1</DH(**7Y0IAIB#N3$%#(1JE$,QYAP=D(L\
M;EREI!S"ZH.D+IPUY@,P^-8[N[DRK]N]#A*(4=*.].RCZ,&:ST5H2EY`_T6Y
M9XFL"6$NZLGR,DV+63*[Z6C;FJYL&"^I6_XQ=;6&<51'BORQSBM)_7YSRZHU
MC>.Z_E8X[J(-;AF-\=C`5)CR+=Y@T'0CQ#JV/<3H\`B*-#N:ICXO2:-$L:,J
MJ`8Y9?.PJ9RR@G&0`^C*Z"ZF(R([/,'F\BEZYGZK7"L4_L'.1&&#Y6(^GO%8
M7,`*L7TFO-6R<\!^5"&3;7)A['HSVB[Y&&JI%:N,2*XAE)L(Y>:!BN303Q9J
M%EM:??^Z;U(M?E`BC3,AS5;M)J_3;J*TJ^ZS[_&I"#XC8"&53=`KHZP[65"[
M/%L4-.71QC*N879)7V:`758MA4\E9>F!CW-RO<#7H0O38"[DB4G:.0OUU_6&
ME8)9PK#$_4/6-IRYIU,&HW-H3ZFO!NJG6*07LI!"X./,'??\7)-,&\.0K4H?
M/M0.UQHJ^2QLHR34I'1Z6FNLOB#!MG&\J0M78TY/6Z7L!)'67CW!G/:D_WA,
M.FS57K;*COC8.MPZG@+;=L7>95INMQ'MTK(Z)4%:J/PWL9QE6+GX(9JX_GIU
M!>SC[CQ&A#`S;.O@![$LOC)3IBUMPVX<6[(5S9]:4AZ9XI_03Z>%Z\R](J.^
M)J.5E>%8L;5-!D)A-%[3H]Y@YD-+-7)Z&,_+6-.C/LK*6.J1E8$V?]W$3V3B
MD@+#>+1T0\^1C4X^)7]6C@XRH[RP-&NCU']DE'3Q-B^='"-UA.R$&JN#E6M9
MJ:.EU/7%?$YJ_3FIK\?L=[4<4S%[N9'H+=W@S542*S'JU<5P+^(@;S@8X%\B
MMO/5VK7409UHIX6._*%OHX$)R(O9QT+$]@2D46MR"J(^5?:)ZO?%2K2WDF+3
M3O*["`,=,`Q^$'3R%J6'!O2<BJ4`XS"8;3A\XSH]!5Y1E,SRNV!:6Y0%?1P5
MO0X%K0Z]W)DK$L$;VN3"9\ZL,&P3,WO^!"NQE0[Y[Q0-';:X`$>7"C":7>D`
MG%GO4TC#)8E7B\U%<#IER]L'6#GFH2J$M$_/NA,RFI='E6$4RV-Z7-8927+6
MSFY6SE0JTD28#6$73)=FG`@1NF5_G0706:TR#>\#Z2TA![.-,?[OVY12;8<S
M!SP_5+7+"WBA=$<%[@9H_)DOW?&2$9#V"W3B7[MT)Q!9/N8T\M!=A!6"D'R[
M?HMHK2TN'#L_(8H*"W)!31P-/L!QRUA6SBA.7&M17!^B7*NW2MEN4/B#JS$A
M+O==D6!@_M3N7W>O+V'W)ROT*7GCG!2'PR@^/5(C8JK\ZN^6N):3&?4]-53E
M5?7!Q9I<DY<5DP6>34K=7%]]@[<.)H/]=B^G#[J!$'`1V`EYMD4I814'%65,
MLOTR1F6]LS+VJ<2/\1O27=]@`E:#!T\<3&F?BHU]NO+%O[@T]R?^KZK6;WHW
M7Z^'9O_F!G]=D%Z;ZSP8>JDZQZ:K-0;BZWE@+OINQ^0!GX;A[UI=`A+:CL-)
M,;KAF1?8=]CWWD4?PG?T6LW\[.J+>='YMWEU<W,KW9/3AIWR6HO>1?:]MO;V
M_=/B8?OK\.:B,^R<X[*TN]DWO0OSJGO=:??SS^@ZXFUGI6&OV^_?]-'D^<<D
M\0`?K<^!X)!1<;W!SQ>;W]^V^]V+3F[Z&ZRH3.CZ/T`OB[[;K5BO\PV%NLI]
M[6#&6]3>I?!%:'DRH=LCFAD%@0=[7U0=QXJG(&:)QY#?6Z)Z^-GL]+Y>M8?=
MF^L=S251R.>/:X?>K@^]L[U-A"1O/<C1KD5,AQ)$"!%&_4$8+[I<=X9IJRN*
M^U/!2.Q4N:D=KHC'!VG[V_,NT-'/FDQ\D;%#WJO/>3UQ4ZI,A3=_M4&V"=E@
MF4;F6B[?63M:%E`A<^*#RU_&Y:_V.^V+7J<"W?'B(B$#*J%Z660]P;=W8,UI
MDZ1PA81@^)!X7%"D>RW0/+@[P\683'#?DSN23C7Y![ZZ.$W"N$(W4#98<.D@
M2]M1S'K%T\:8E<MTR)%4VT2C_-6H',#$G5BCIUA$F_9L7`J^V4A2>*=_=&?)
M#(X/#&PA^ZWVT>6],?POD^7/@HAER%-]W,&+KER=J74O@-B92J`^,#L3HS.)
M4X]7\3A,$5XX(3NUI=0AF%,GG$1`DL@(ZN(GOY571K)Z\%50J<>!TN,-A_+7
M'*[`V`OF&'8Y;G27XG1GE5T^79!%E>T?+)_OM-"2X_<P)X$/V(M1"1(?HQMI
M)`60RK.0?V8!-F*_N2%P?Y6T[4Y@Z!C`U_0FA^^8/7%H[2BY*G$?(9PVV$3(
M6:817HQV4>N8Q0"O_0)5Q.>X51)Z%7I.:%1:7@Y(V'(T3FI:`7M;V$T.O:-)
MM11$TJM^F4JUXKB%&^<!LJ/1@DF@.@$;.;&G/+BZ"TPL32ZM9Z$(H^2)+QOO
M:(A&'@?S'`R$Y=50U<CEB]`K=,^3AL7/+_`;;.3];*-BK44EJ.?)/B=Q_S=8
MY_;5,9_C==*.9I_0V2`2R89-!*>UEY)&M(>4)BI(=M(+@_&.MD>[S)ZZ3,5?
M4$-N6X&O\IHV*EVOU-2U+MZHB3OCT+7EU-5=WU3F!BW>D*+=WNU-?]B^'IZ\
MU!RB:9!X#M\>&P5)#!@7]G:T)5BIOS4+$C^?\A!HB\A[/`ND&!64K."GI*-@
MVR)VR*2D=)41]\%@)C))O1MC)A\\^`NFIZ2)[C?R!>&TJ_"QK<T9+HY&NF)D
M[#MHHQ&F$Y[+7<!ZL%#`(E>F6)QUCYYR`!FC)I336[0/%/F2*@JU^;(Q7773
M[&GBWVW8-=(0BJL6.##[_)L2#%8)&@TF$6_C)CE.,!_4N6[A!<$=.<;>.!1B
M+[V>16\P6"#TH5(3C&&U!T%0(`=*5UA=U$5><`1=#D4-J-]B7*="`&@K*E%'
M>Y=K,U!F)\LL(0I_U9N&@2HB:V6Z-RJMRPW]R(#2Q3T7<^?&,=4.VG2TPV@7
MCYA]NPLJEJ+('%PQI<U>[O7Z.C0L^$O"4-F6_PF%O"19+,'<2R*@<$J"!U7A
MHTS&T\)O`Q*;X`HN)JZJ&'2%?A0@U7VZ4$5$-:70XJ4>D2YS"EWH7CXNI2LO
M:9YU;P9\S,F6#P5S>GIK.ET<]W>,@%*TX\/W;$_BXMF,_H$.5::7A(Q:A*'K
MT#_3X)'&`E>`QJ67:@2Z1#H/@Y&'VT(U2C!DBF+^ER1QD"?,KC\)H!=XOA7"
8Z0RM$GQ$,"",*S@XG2+_/V!=GA/Q-0``
`
end
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Colin Plumb <colin@nyx.net>
Date: Fri, 4 Dec 1998 09:13:42 -0700 (MST)
Subject: Re: Looking for SMP-capable tester
Thanks to everyone who tested it for me! Although it doesn't
matter that much, the output is easier to read if the skew is
actually computed properly.
This is a bit of forgetfulness on my part. The line
min1 = min2 = (unsigned)-1;
should be
min1 = min2 = (unsigned)-1 >> 1;
So far, it looks like the skew actually is consistently zero
on Intel boxes.
- --
-Colin
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Michel LESPINASSE <walken@wrs.com>
Date: Fri, 4 Dec 1998 17:12:02 +0100 (MET)
Subject: Re: Limit of 256 NFS Mounted Filesystems
On Fri, 4 Dec 1998, Richard Kaszeta wrote:
> Unfortunately, I've discovered that 256 is as high as one can reasonly
> put this limit, even with the 2.1.x kernel, as each nfs (or other
> 'nodev' type of mount) requires a device of major number 0 and a
> different minor number, so there can only be 255 nodev filesystems at
> any given time.
Yes. My understanding is that this should be fixed by the bigger dev_t in
the 2.3 kernel series (but not before, because there is a lot of issues
with this because dev_t is part of the exported kernel API)
> Anyone have ideas for workarounds? I have a *huge* amount of storage
> here for each user, which is why I starting using autofs to start
> with---it was the only efficient way of serving home directories
> (which are spread over a couple dozen servers and devices anyways, so
> most alternative schemes still would run into some of these limits).
dunno. perhaps you could try to mount each of these devices in their
entirety, and not each home dir separately. But yes, this is a very
serious limitation.
> We need to fix this if we are to claim that linux is a serious candidate
> for server use.
We will. but probably not before 2.3 :-(
- --
Michel "Walken" LESPINASSE - Development Engineer at Wind River Systems
walken@wrs.com - http://www.via.ecp.fr/~walken/
Microsoft is not the answer. Microsoft is the question. The answer is no.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "John R. Lenton" <lenton@famaf.fis.uncor.edu>
Date: Fri, 04 Dec 1998 07:40:18 -0300
Subject: ne2k in 2.1.131
I've just finished installing 2.1.131 on my 386 to find that
I can't use my ne2000. I was using it fine in 2.1.129, never
got round to install 2.1.130, and now under '31 there's no
error message, no nothing but I ping -f my p200 box and it's
the same as ping'ing localhost, except in as much as
ifconfig is concerned.
I'm rather puzzled as I looked at the patch and there's no
even remotely relevant chage, unless the kernel dependancies
(or my ignorance) are /that/ bad.
I'm sure there's some kind of information I could send you,
but as I say there's nothing to it: I'm not even reaching
the cable!
Cheers,
John
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Oliver Xymoron <oxymoron@waste.org>
Date: Fri, 4 Dec 1998 10:38:47 -0600 (CST)
Subject: Re: [OFFTOPIC] Re: linux kernel hackers discover new theory of relativity!
On 3 Dec 1998, H. Peter Anvin wrote:
> > Babylon 5 is closer to the reality of physics - the spinning station
> > creates artificial gravity, but only for people standing on the
> > inside walls of the cylinder. Those who are near of rotation axis
> > are in zero-gravity. This is not gravity guys, it's centrifugal
> > force, the same that pushes you against your car's window when you
> > take a sharp turn. --
> >
>
> Actually, it *is* gravity. Read up on general relativity if you don't
> believe me.
What GR says is that the local effects of gravity are indistinguishable
from acceleration, not that they are the same. Gravity is the name for a
force acting between two bodies proportional to their masses, yada yada
yada, not a generic term for the effects of acceleration.
- --
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: " Raymond A. Ingles" <inglesra@frc.com>
Date: Thu, 3 Dec 1998 14:24:12 -0500 (EST)
Subject: Re: IDE freeze for seconds
On Thu, 3 Dec 1998, Nicholas J. Leon wrote:
> On Wed, 2 Dec 1998, Alex Buell wrote:
> # What is the first thing that ceases when you spin down a planet? That's
> # right, gravity. Everything not tied down would just fly out into space,
> # and that includes the atmosphere. Simple.
>
> What would happen is that we would all be crushed against the planet's
> surface as the balancing forces of gravity and centrifical would no longer
> be in accord.
Ummm... no. If centrifugal force were that big a factor, people would be
crushed by the Earth's gravity standing at the north pole.
At the equator... let's see, a BOTE calculation...
a = w^2/r -> a = (2*pi/86400 seconds)^2 / 6.4x10^6 meters ~= .034m/s^2
I.e., about .34% of the effect of gravity is cancelled by "centrifugal
force" at the equator. I doubt anyone would notice.
Still, everything would die after a while. Our "days" would immediately
become 365.25 days long. The dark side of the Earth would get *very* cold
before too long, and the atmosphere would start freezing out on that side.
The light side would get pretty warm, too. Of course, at the terminator
lines there would be some thawing and freezing, and I doubt it'd ever be
close to a vacuum, but it sure wouldn't be comfortable.
This is assuming you spin things down relatively gently, say over a few
months. If you do it fast, it would be even uglier. Impressive tides,
dramatic earthquakes, record winds, that sort of thing. *Then* the
atmosphere freezes out.
I'm going to go do something productive with my calculator now...
Sincerely,
Ray Ingles (248) 377-7735 ray.ingles@fanucrobotics.com
"Improvements succeeded each other so rapidly, that machines which had
never been finished were abandoned in the hands of their makers,
because new improvements had superceded their utility."
Charles Babbage 'On the Economy of Manufactures' 1832
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Jim Woodward <jim@jim.southcom.com.au>
Date: Fri, 4 Dec 1998 21:55:08 +1100 (EST)
Subject: Re: NO ROM BASIC
On Thu, 3 Dec 1998 doctor@fruitbat.org wrote:
> Did you enable the SMP option?
>
> > make config
> > make dep
> > make bzImage
> > make install
> >
> > Then I rebooted. When it starts, it goes to 40 column mode and
> > says "NO ROM BASIC"
>
> Pardon me, but it sounds like you just booted an Atari 400 (or maybe a
> VIC 20, or possibly a Commodore PET ;-).
>
> Seriously, this almost sounds like a virus has infected your boot block.
> Can you boot off of floppy? Are you using LILO? Do you have more than
> one OS on your system?
I once saw this on my old 386 based linux system.. when the boot record
became corrupt.. it wasnt a virus, for some reason the BIOS just wouldnt
let the hdd boot, also could be related to incorrect drive geometry inthe
BIOS (heads, cylinders, sectors etc)
havent seen the error for a while but its probably part of the newer
BIOS's too (probably some legacy code) :)
Regards, Jim.
_____________________________________________________________________________
__ name: james woodward (jim)
/ . _ _ email: jim@jim.southcom.com.au, jim@woodward.southcom.com.au
(_/ / / \/ ) www: http://jim.southcom.com.au, http://www.mailbag.ml.org
+---------------------------------------------------------------------------+
| The e-mail address of this message is copyright. If you use them for |
| inappropriate spamming, you agree to pay $5,000 to James Woodward for |
| every act of misuse and unauthorized reproduction without permission. |
+---------------------------------------------------------------------------+
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Torbjorn Lindgren <tl@fairplay.no>
Date: Fri, 4 Dec 1998 12:16:26 +0100 (CET)
Subject: Re: SMP scalability: 8 -> 32 CPUs
On Thu, 3 Dec 1998, Jason Riedy wrote:
> ASCI Blue Mountain is a cluster of O2000s with 6144 total processors. I
> believe it's set up to appear as a cluster of single machine images (1k
> processors), each of which is a NUMA, but I don't have access to it to
> check. I don't know if the cluster follows the same design as the
> individual machines (fuzzy hypercubes).
According to the information on the website it consists of 48 Origin2000
with 128 CPU's each. Each machine has 12 HIPPI-800 ports, connected via a
3-dimensional torodial interconnect (with 36 16-port switches).
The flyer notes that they plan to upgrade the interconnect in 1999 to
HIPPI-6400 and 32-port HIPPI-6400 switches.
Ref:
TOP500 Supercomputers: http://www.top500.org/top500.list.html
LANL: http://www.lanl.gov/Internal/projects/asci/bluemtn/bluemtn.html
(The Blue Mountain Flyer contains a lot of hard information about it)
> BTW, ASCI Blue Pacific, the 1344-processor IBM SP/2 version, is a cluster
> of 8-way SMPs (iirc). It has a pretty horrible memory latency problem
> inside a single node (it's as fast as talking to another node), but the
> _idea_ is to have a lot of really fast local memory, plus a trusted, fast
> connection to other SMPs.
4-way machines according to the information I found. Looks like they have
a new "machine" on their way, with a total of 5856 CPU's (1464 4-way SMP
machines) for "closed side" (classified stockpile stewardship computing ?)
>From the information it looks like they have 2/3 of these already, which
should put that relatively high on top500 list if it had been included.
Both uses 4-way 332 MHz PPC604e, but there were old notes about planning
to move to Power-3 in "1998". Looks like that have been delayed thought.
Ref: http://www.llnl.gov/asci/platforms/bluepac/
Lots of interresting links in that top500 list :-)
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Matthias Andree <mandree@dosis.uni-dortmund.de>
Date: Fri, 4 Dec 1998 12:47:58 +0100
Subject: Re: Re: IDE freeze for seconds
On Thu, Dec 03, 1998 at 10:05:12PM +0100, Johnny Teveßen wrote:
> Quoting Pavel Machek (pavel@atrey.karlin.mff.cuni.cz):
>
> > Get bdflush-1.6 from sunsite, there's way to postpone writes until
> > disk is spinned up again. I believe this is what you want.
>
> That's interesting. I was told that there's no way to find out whether
> an IDE drive is spinning or not. At least not without spinning it up.
There is, unless it is in sleep mode. Check hdparm which can report the
driver power state: operation, idle, standby, sleep. The latter two with
stopped disks, the former two with spinning disks. To recover from sleep
mode, you will need a soft- or hardware reset.
- --
Matthias Andree
--- How to obtain PGP public key
<mandree@dosis.uni-dortmund.de> <<< /finger/ this
<m_andree@line.org> <<< mail, subject "SEND PGP-PUBLIC-KEY"
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Tigran Aivazian <tigran@aivazian.demon.co.uk>
Date: Thu, 3 Dec 1998 21:27:39 +0000 (GMT)
Subject: [patch] 2.1.131, "noapic" boot option.
Dear Alan,
This patch implements the "noapic" option that was mentioned on your web
pages, or at least what I assumed you meant by it.
The patch is against 2.1.131 and was tested on Dual PII/400 machine with a
single IO-APIC.
Namely, when "noapic" option is passed symmetric io mode is not entered and
all IRQs appear as "XT-PIC" in /proc/interrupts. The detection of the
IO-APIC is still there, it just isn't used - all is delivered to CPU0.
I think this level of skipping is sufficient because it is the symmetric
mode and the actual use of io apic (rather than detection) was reported as
problemmatic by some on this list (probably with some broken hardware).
Regards,
Tigran
diff -urN linux/arch/i386/kernel/io_apic.c linux-2.1.131.new/arch/i386/kernel/io_apic.c
- --- linux/arch/i386/kernel/io_apic.c Tue Oct 6 23:44:00 1998
+++ linux-2.1.131.new/arch/i386/kernel/io_apic.c Thu Dec 3 19:56:01 1998
@@ -225,6 +225,13 @@
int pirq_entries [MAX_PIRQS];
int pirqs_enabled;
+void __init ioapic_setup(char *str, int *ints)
+{
+ extern int skip_ioapic_setup; /* defined in arch/i386/kernel/smp.c */
+
+ skip_ioapic_setup = 1;
+}
+
void __init ioapic_pirq_setup(char *str, int *ints)
{
int i, max;
diff -urN linux/arch/i386/kernel/smp.c linux-2.1.131.new/arch/i386/kernel/smp.c
- --- linux/arch/i386/kernel/smp.c Mon Oct 5 20:19:44 1998
+++ linux-2.1.131.new/arch/i386/kernel/smp.c Thu Dec 3 20:01:52 1998
@@ -28,24 +28,17 @@
* Alan Cox : Added EBDA scanning
*/
- -#include <linux/config.h>
- -#include <linux/kernel.h>
- -#include <linux/string.h>
- -#include <linux/timer.h>
- -#include <linux/sched.h>
#include <linux/mm.h>
#include <linux/kernel_stat.h>
#include <linux/delay.h>
#include <linux/mc146818rtc.h>
#include <asm/i82489.h>
- -#include <linux/smp.h>
#include <linux/smp_lock.h>
#include <linux/interrupt.h>
#include <linux/init.h>
#include <asm/pgtable.h>
#include <asm/bitops.h>
#include <asm/pgtable.h>
- -#include <asm/smp.h>
#include <asm/io.h>
#ifdef CONFIG_MTRR
@@ -159,6 +152,7 @@
int mp_bus_id_to_pci_bus [MAX_MP_BUSSES] = { -1, };
int mp_current_pci_id = 0;
unsigned long mp_lapic_addr = 0;
+int skip_ioapic_setup = 0; /* 1 if "noapic" boot option passed */
/* #define SMP_DEBUG */
@@ -1170,7 +1164,8 @@
* Here we can be sure that there is an IO-APIC in the system. Let's
* go and set it up:
*/
- - setup_IO_APIC();
+ if (!skip_ioapic_setup)
+ setup_IO_APIC();
smp_done:
}
diff -urN linux/init/main.c linux-2.1.131.new/init/main.c
- --- linux/init/main.c Sun Nov 29 18:37:02 1998
+++ linux-2.1.131.new/init/main.c Thu Dec 3 19:53:49 1998
@@ -90,6 +90,7 @@
extern void smp_setup(char *str, int *ints);
#ifdef __i386__
extern void ioapic_pirq_setup(char *str, int *ints);
+extern void ioapic_setup(char *str, int *ints);
#endif
extern void no_scroll(char *str, int *ints);
extern void kbd_reset_setup(char *str, int *ints);
@@ -541,6 +542,7 @@
{ "nosmp", smp_setup },
{ "maxcpus=", smp_setup },
#ifdef __i386__
+ { "noapic", ioapic_setup },
{ "pirq=", ioapic_pirq_setup },
#endif
#endif
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Matthias Andree <mandree@dosis.uni-dortmund.de>
Date: Fri, 4 Dec 1998 12:25:55 +0100
Subject: Re: aic7xxx Driver support faster than 20MB/sec?
On Thu, Dec 03, 1998 at 04:42:25PM -0800, Timm Gleason wrote:
> Does anyone know if the current version of the aic7xxx driver(5.1.4) support
> faster than 20MB/sec maximum transfer rate? I compiled a 2.0.36 kernel using
> the pre13 patch and the patch text had references in it to the aic7xxx
> driver being 5.0.20. This kernel did support the higher rates. However, I
> find that the kernel we compiled using the final release of 2.0.36 contains
> aic7xxx driver 5.1.4 and does not seem to accept negotiation higher than
> 20MB/sec. Yes, I have checked the SCSI BIOS for the controller and all ID's
> are set to 80MB/sec rate.
You're not stating if you have U2SCSI, but I assume you don't. So I can
assume you are messing up MB/s and MXfers/s: The MB/s are derived from
MXfers/s and the actual transfer width. So, 20 MXfers/s on a narror bus are
20 MB/s, 20 MXfers/s with a 16bit wide transfer gives 40 MB/s (which is what
you can probably achieve with the 20 MHz setting), a 32 bit wide transfer
would offer 80 MB/s, but I doubt your equipment actually does 32 Bit
transfers.
In any case, the NEGOTIATION is done in MXfers/s (5 is "standard", 10 is
Fast, 20 is Ultra, regardless of width, and Width is 8 for "standard", 16
and 32 are for Wide scsi, regardless of Ultra/Fast), so 20 MB/s seems very
reasonable and is nothing which could limit your SCSI performance.
- --
Matthias Andree
--- How to obtain PGP public key
<mandree@dosis.uni-dortmund.de> <<< /finger/ this
<m_andree@line.org> <<< mail, subject "SEND PGP-PUBLIC-KEY"
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Philip Blundell <pb@nexus.co.uk>
Date: Fri, 04 Dec 1998 11:10:10 +0100
Subject: Re: IDE -> ATA DISK
>Why not root? We already include some checks to prevent root from
>doing stupid things - for example, the kernel refuses to compile if
>the compiler used is too early a version - and I can see nothing wrong
>with putting in checks for other insane choices for precicely the same
>reason - to reduce the bug reports caused by setting such insane
>choices in the first place.
How many bug reports have you seen because someone turned off both ELF and
a.out?
p.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Stephen C. Tweedie" <sct@redhat.com>
Date: Fri, 4 Dec 1998 11:34:18 GMT
Subject: Re: [PATCH] swapin readahead and fixes
Hi,
On Thu, 3 Dec 1998 18:56:34 +0100 (CET), Rik van Riel
<H.H.vanRiel@phys.uu.nl> said:
> The swapin enhancement consists of a simple swapin readahead.
One odd thing about the readahead: you don't start the readahead until
_after_ you have synchronously read in the first swap page of the
cluster. Surely it is better to do the readahead first, so that you
are submitting one IO to disk, not two?
- --Stephen
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Jon K Hellan <Jon.K.Hellan@item.ntnu.no>
Date: Fri, 4 Dec 1998 12:39:19 +0100 (MET)
Subject: Re: Internationalizing Linux
> > This causes a maintenance headache. With this scheme,
> > whenever a new printk gets a macro-ized, you will have
> > to make sure the entries are correctly added to the 'n'
> > language specific headers, even if they are inserted in English.
> [...]
> It doesn't have to be like that. Consider using one file
> kmsg.h included by anything that needs the message #define's
> Now this file contains two lines only:
>
> #include <english.h> /* Because English is the development language for Linux
> */
> #include <norwegian.h> /* Or whatever you may want instead */
*If* this is done (I don't like the idea), messages must include a
language independent identifier (e.g. E1004, W2012, ... Only thus can
a support provider who doesn't understand swahili interpret the message.
Jon
- --
Jon K. Hellan Jon.K.Hellan@item.ntnu.no
Div. of Telematics, Norw. U. of Science & Technology, Trondheim - Norway
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Pavel Machek <pavel@bug.ucw.cz>
Date: Wed, 2 Dec 1998 22:12:52 +0100
Subject: Re: suspendd-v0.1.0 released
Hi!
> > > Hi, all. I've just thrown together a simple daemon which allows you
> > > to configure actions to be taken upon APM suspend or resume events.
> >
> > Ouch, should not this functionality be merged into apmd?
>
> I've had a look at the beta version of apmd, and I still don't like
> it, because:
>
> - only supports one command to run at suspend time
Which should not matter that much if that command is sh -c 'a; b' ;-)
> - doesn't distinguish between user and system suspends
So fix it.
> - doesn't provide a way to disable policy (the
> sync();sleep(0);sync();sleep(1); sequence)
Fix it.
> - does not document extra features.
I'm sure this is not problem for you. Anyway, you can always fix it ;-)
> And I'm not sure that what we want is a single super daemon. A
> collection of smaller daemons might be better, since it allows people
> to pick and choose. A super daemon is bloat for those who only want
> one small feature.
That daemon is
- -rwxr-xr-x 1 root root 38015 Sep 8 19:37 /usr/src/apmd.my/apmd*
38K big. Unless you have even more crappy hardware than I
(386dx40/8Meg), you can probably live pretty well with this
'bloat'. And when someone modifies /proc/apm layout, you'll go out and
modify 5 different daemons. I believe this is not the way to go.
Pavel
PS: You probably do not want 5 different bad apm daemons, one good apm
daemon is much better. BTW what you reported are bugs, and I'm pretty
sure their fixes can be easily rolled into official tree. Believe me,
it is easier than maintaining your own little daemon.
- --
I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Pavel Machek <pavel@bug.ucw.cz>
Date: Wed, 2 Dec 1998 22:57:13 +0100
Subject: Re: Software Suspend [HELP: buffer&schedule problems]
Hi!
> Making snapshots will not be available in this kind of implementation,
> because suspending hangs on swap state [every process is tried to swapped
> out, so image won't be that big], and the state of filesystems also.
> This is a drawback [so I can't suspend a state, run another [not using
> that swap!] then continue the first one]. This is not good, because nfs
> filesystem may vary meantime [and why wouldn't they do that?].
Don't worry. NFS may vary _anytime_ so if you'll break it with your
patch, it was broken anyway. (Your linux machine may hung for 1hour
doing cli(); for(i=0; i<some_very_big_number; i++); sti(); without too
much things breaking. Do now worry.)
> Every possible info is shrinked [inode, buffer, dcache] but I don't know
> what to do with those are in use..
> Maybe we should revalidate them? But what if we did this suspend in the
> meantime of writing a buffer [and haven't marked it dirty yet - we
> load a previous state..].
> And what if we marked it... to reavalidate we have to flush it to disk as
> it is [with unfinished modifying]... It is not a problem if we continue
> with the original state but running another one [or a new one] is
> definitely bad.. FS corruption ... :O
You should probably expect the original state (try to solve easy task
first).
> 2) On shrinking memory [to swap] I did call try_to_free_pages with gfp
> mask __GFP_WAIT. And it slept [of course :)]. So other processes were
> still running :(. [my mpeg player e.g.]. How to disable them? [It made an
...
> I was thinking of a shortcut in schedule() [if suspeinding is in progress
> then don't run any other process than the suspending one] But it's
> _ugly_.
You could create process with big rt priority and make it do while(1);
This should guarantee that no other process will have chance to
run. Of course your "suspender" process will have to have even higher
priority ;-).
- --
I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Riccardo Facchetti <fizban@tin.it>
Date: Fri, 4 Dec 1998 14:05:05 +0100 (MET)
Subject: Re: [OFFTOPIC] Re: linux kernel hackers discover new theory of relativity!
On 3 Dec 1998, H. Peter Anvin wrote:
> > Babylon 5 is closer to the reality of physics - the spinning station
> > creates artificial gravity, but only for people standing on the
> > inside walls of the cylinder. Those who are near of rotation axis
> > are in zero-gravity. This is not gravity guys, it's centrifugal
> > force, the same that pushes you against your car's window when you
> > take a sharp turn. --
>
> Actually, it *is* gravity. Read up on general relativity if you don't
> believe me.
No way Peter, you are wrong. It is _not_ gravity.
You define gravity force as the force that follow the rule F=K*m1*m2/r^2.
Enlighten me showing how centripetal forces follow that rule (mainly how
you can accomodate the [m1*m2] term) !
I don't remember general relativity enougth, but I'm sure that centripetal
forces are _not_ comparable to gravity forces.
Yes ... they can be used to simulate gravity forces, the same way you can
use the acceleration of a car to simulate gravity force directed
horizontally: acceleration ... this is the key ... gravity is a force that
have a constant acceleration of 9.81 m/s^2 without motion between two
bodies while centripetal forces need motion !
Ciao,
Riccardo.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Riley Williams <rhw@bigfoot.com>
Date: Fri, 4 Dec 1998 12:23:14 +0000 (GMT)
Subject: Re: IDE -> ATA DISK
Hi Kurt.
>>> It's not that easy. You can have ext2 filesystems on ROM
>>> devices...
>> Only if the ROMfs is selected, whether "M" or "Y" is irrelevant...
> No. ROMfs is just a FS optimized for read-only and for requiring
> few space. You can put ext2fs on a ROM device, of course.
OK, wrong file system name, sorry...
>>> ...or a network block device.
>> You sure of that? I understood that NFS didnae use any of the other
>> file systems as it's a file system in its own right...
> No! You can put ANY filesystem on ANY block device. Why would
> somebody create nbd, otherwise? Read Documentation/nbd.txt, if you
> don't believe me. (It also says, that you need some program to set
> it up, so you can't use it as root device. But hey, use NFS as root
> and a nbd for your ext2 fs.)
>>> And it should be possible to compile a kernel w/o IDE and SCSI,
>>> but with ext2fs and nbd.
>> Possible, yes - but then, it's possible to compile a kernel
>> without support for a.out or ELF - whether such is sensible is
>> another question...
> I guess, you're right here. But have a close look at the other
> possible binfmts. binfmt_script is out of question as the
> interpreter has to be loaded ...
I only have 2.0.35 to hand at the moment, which allows just three
different formats:
1. a.out
2. ELF
3. JAVA
The last needs to load the JAVA interpreter to be used, so inherently
needs one of the first two. As a result, if both of the first two are
selected "n" the system is severely crippled AFAICS...
> Maybe you can use a kernel for routing and forwarding network
> packets and things like that without needing userspace tools. But,
> yes, this is very unlikely.
Memory says that one needs userspace tools to configure those two
facilities in the first place - besides, to do anything, one needs to
log into the system, and /bin/login is an external program...
>>> If you want to put a warning for this case, OK, go ahead.
>> That's all I was referring to anyway...
>>> ... and the needed modules can still be added and inserted.
>> Even if the relevant options were selected "N" when configuring
>> the kernel? That's not my understanding.
> I have to admit, that I don't know how this is handled exactly. I
> know, it's possible to compile drivers for SCSI adapters as modules
> and inserting them after having compiled a kernel with "N"
> configuration for this adapter. Some modules might change the rest
> of the kernel by being selected with "M", but I think, Linus would
> not like such dependencies, and so there most probably only a few
> or none misbehaving like that.
I've never used SCSI since I don't have access to any systems using
it. However, my experience with the things I have tried indicates that
the following rules are true:
1. If CONFIG_MODULES="n" then nothing can be loaded as a module,
irrespective of anything else.
2. If CONFIG_FAT_FS="n" then none of the DOS FAT based file systems
can be loaded, even if modules for them are available.
3. If CONFIG_NFS_FS="n" then any attempt to load or use NFS results
in a syslog message stating that the kernel does not support NFS.
I have a feeling that the SCSI system is an exception to this pattern
since I have also heard of people being able to mount SCSI modules
that were selected "n" when the kernel was compiled, but as stated
above, I have no direct experience of this.
>>> The modules add significant complexity to your sanity checks.
>> Why?
>> IMHO all the sanity check needs to deal with is whether or not
>> options are set as "n" which in each case is a Yes/No decision. As
>> an example, have a look at the following, which generates an error
>> if the a.out and ELF executable formats are both set "n" since the
>> resulting kernel is rather less than useless...
>> ===8<=== CUT ===>8===
>> --- linux/arch/i386/config.in~ Mon May 13 05:17:23 1996
>> +++ linux/arch/i386/config.in Thu Dec 3 22:14:45 1998
>> @@ -36,6 +36,12 @@
>> if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
>> tristate 'Kernel support for JAVA binaries' CONFIG_BINFMT_JAVA
>> fi
>> +if [ "$CONFIG_BINFMT_AOUT $CONFIG_BINFMT_ELF" = "n n" ]; then
>> + echo '*** ERROR: Either a.out or ELF format is' \
>> + 'ESSENTIAL for Linux to work.' >&2
>> + echo ' Aborting configuration.' >&2
>> + exit 1
>> +fi
>> bool 'Compile kernel as ELF - if your GCC is ELF-GCC' CONFIG_KERNEL_ELF
>>
>> choice 'Processor type' \
>> ===8<=== CUT ===>8===
>> Perhaps you could advise what's complicated about that...
> If you are sure, it's never useful to have a kernel without both
> ELF and A.OUT support, then it's the correct thing to do.
With the 2.0 series kernels as currently exist, it's highly unlikely
to be useful since without one of those two, no external programs can
be loaded.
Also, and here I'm speculating as I don't know the answer, but can an
ELF compiled kernel be loaded if ELF support is not included?
> But in most cases, I would not like to have an ERROR. You can
> display a WARNING, if you think the kernel configurator does
> something very stupid.
The problem there is that "make config" which has no means to go back
to reselect an earlier option as currently written. To handle this
situation elegantly requires a serious rethink there...
With "make menuconfig", it would be easy to have a "comment" appear if
an insane option combination was selected, but a better option would
be something along the lines of the warning message popped up by
"dep_tristate" when one selects "y" for an option that depends on an
option selected "m".
With "make xconfig", there is no easy way to pop up a warning,
although the ability to go back and change an earlier option obviously
already exists. In addition, choosing the "comment" option referred to
in "make menuconfig" above would result in the comment being
permanently displayed, thus making it meaningless...
> Consider the NFS/network example. Imagine root to have compiled
> modules for the network support. For some reason (s)he wants to
> have NFS in the kernel, but not recompile the network modules
> (maybe because (s)he has a 386). You should not forbid to do that.
Nor can I see reason to even warn about it - to my mind, that's a
perfectly valid configuration
> Un*x is used by a lot of people who know very well what they are
> doing. You can easily annoy these, by not allowing them to do what
> they like.
That's why I'd like to see this sort of functionality implemented as
warnings as well, but that's not possible without modifying the
configuration scripts first...
>>> There are so many ways to screw your system if you are root and
>>> don't think enough before you are doing something. Un*x is about
>>> saving the user from doing stupid things but not root.
>> Why not root? We already include some checks to prevent root from
>> doing stupid things - for example, the kernel refuses to compile
>> if the compiler used is too early a version - and I can see
>> nothing wrong with putting in checks for other insane choices for
>> precicely the same reason - to reduce the bug reports caused by
>> setting such insane choices in the first place.
> The security concept of any Un*x-like system is based on the
> assumption that we can trust root.
That does not automatically assume that root is the world's top
genius (who would automatically realise how insane some combinations
can be), only that root has been given both the authority and the
responsibility of maintaining the system, nothing more than that.
As an example of what I'm getting at, take the following hypothetical
scenario:
Q> Linux was installed on a group of systems that all NFS mount
Q> their root directories some months back by a previous system
Q> administrator who has since left the company. A new system
Q> administrator has recently been appointed to take over those
Q> duties.
Q> Although none of the systems have them installed, the systems
Q> were set up with support for the IOmega parallel port Zip
Q> drive since some of the users have those drives available and
Q> bring them along to download and transfer files for their home
Q> systems. Since in this situation, the driver works best when
Q> compiled as a module, that's how it's set up.
Q> The new sysadmin is browsing through the kernel configuration
Q> to see whether it can be reduced in size since memory is tight,
Q> and notices that the SCSI subsystem is compiled in, although
Q> none of the systems have SCSI drives fitted. He therefore
Q> deselects it and recompiles the kernel without support for
Q> it, then puts the recompiled kernel as the one to use. He does
Q> NOT delete the ppa.o module since he didn't notice it in the
Q> first place.
Q> Following this, he gets a lot of users complaining that their
Q> PARALLEL port zip drives get corrupted when used on the system.
Q> (Don't laugh, that can happen under those circumstances). Since
Q> these are parallel port drives, he does not associate this
Q> problem with his removing the SCSI system, so spends several
Q> frustrating weeks trying to determine just what's gone wrong.
The system administrator was CORRECTLY trusted, and acted in what
(s)he thought was the best interest of all concerned. However, the
actions taken were WRONG!
This is one change I would like to see done, but wouldnae know how to
start: If an option is deselected that results in other options being
disabled, and any of those options are currently selected, some sort
of message should be displayed pointing out the fact, rather than just
blindly deleting those options as at present...
> The system needs to be set up, maintained, etc. and for this you
> need to be able to do things which can hurt you.
True, but is that a reason for encouraging root to be stupid, as
currently happens?
> I see no easy way out of this unless the computer becomes really
> intelligent. Then the computer will use humans to accomplish what
> it thinks is good
That would be a nightmare...
> You can screw or crash your system by deleting /lib/ld-linux.so.*,
> catting random stuff to /dev/mem, overwriting swap partitions etc.
> You don't want the kernel to check all this!
Nope, but I for one would like to be informed if an action of mine has
ramifications that I would be highly likely to overlook, and I see
nothing wrong with that.
If I'm going to do any of the things you mention, I'm highly likely to
be well aware of the ramifications, so there's no reason to get the
kernel to check. Likewise if I was to do "rm -fr /" as root, I would
not expect to have a working system afterwards...
> If you read linux-kernel, you probably noticed, that a lot of times
> users post a "Linux bug" or "security hole", which can just be
> exploited by root. Nothing which can only be exploited by root is a
> bug. At most bad policy. (I don't want to say that the kernel
> should do no checks at all, if you are root ...)
Agreed...
> BTW, there are some discussions how to better assign capabilities
> to users and root. The easy approach "root is allowed to do
> anything, the user almost nothing" is sometimes too stupid. Cause
> sometimes users need to do things which they can not be allowed in
> a general way, there's a large number of suid/sgid binaries and
> every single one is a potential security hole. Reducing the number
> of suid binaries needed is a good approach.
Definately agreed...
Related to this, I'd like to be able to stick the kernel source in the
standard directories, but allow users to compile variants of it in
their own userspace without having to copy the entire tree over. At
the moment, that's not possible though...
> If it's obvious and easy, add the checks. There's nothing wrong
> with it, then. If it's compilcated and non-obvious: Don't even try
> to get it right. You only complicate things then and the
> probability you missed something is really high.
True...
>>> If there are easy and obviously correct sanity checks (when you
>>> do something which never makes sense), then add a warning or
>>> error message.
>> Precicely what I said in the email you appear to take such
>> exception to, so what's the problem with doing that?
> You really have to think twice before you forbid anything to
> anybody.
I'd prefer not to forbid anybody from doing anything, but the current
"make *config" options don't have any direct means of producing useful
warning messages, as per my earlier analysis.
> Another example: I happen to maintain a SCSI driver (tmscsim) for
> the DC390/AM53C974 controller. In the Configure.in it used to check
> whether the AM53C974 driver is enabled and didn't allow the DC390
> driver to be compiled in, then. Nonsense! There might be perfectly
> valid cases to compile both, even if they support the same chip.
> Just imagine machines with, say, 2 DC390s and another onboard
> AM53C974 adapter.
> * Old versions only supported the Tekram DC390s.
> * Recent versions of tmscsim can be told to only support DC390s.
> So you can drive different adapters with different drivers, even
> with the same chip...
Agreed - I could see nothing wrong with that anyway...
> The example mentioned was also wrong, IMHO. It does make sense to
> compile ext2fs w/o IDE nor SCSI (nor floppy) support!
>>> In the kernel configuration process, there aren't many such
>>> cases, which aren't already prevented, IMHO.
>> {Shrug} The above case thereof was discovered with less than five
>> minutes study of the options presented by "make menuconfig", so is
>> hardly hidden. If such an obvious case is so readily apparent,
>> then there must be MANY more subtle ones...
> There are some config options you are not allowed to select, if you
> don't select the one they are dependent on. Eg. PCI devices w/o PCI
> support. I think most obvious cases are covered by such a logic.
Many are, but not all of them.
>>> I don't think, Linus will accept anything apart from cases, where
>>> it's obvious, that this configuration won't be any good.
>> I wouldnae think as much of him as I do if he accepted anything more
>> than that anyway, so I can't say that worries me...
> Agreed.
> I think we had enough discussion about this. I think you are
> wanting to find cases where the configurator is obviously doing
> stupid things. Think twice and add warnings (or errors, if it would
> result in a non-functional kernel) and post them. I think these
> will be discussed ...
Like I said above, until such time as a facility is added to the
various config scripts, warnings just aren't possible, so anything
inserted would have to be errors. That's why I havenae posted anything
yet...
Best wishes from Riley.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Kurt Garloff <garloff@kg1.ping.de>
Date: Fri, 4 Dec 1998 11:17:26 +0100
Subject: Re: IDE-DMA strangeness (another one)
On Thu, Dec 03, 1998 at 07:39:36PM -0500, John Kodis wrote:
> On Wed, Dec 02, 1998 at 11:43:34PM +0100, Kurt Garloff wrote:
>
> > So 33MB/s is quite realistic [for reads from buffer cache], but in
> > no way characteristic for your HD.
>
> I get a similar speed, but don't understand why. I would expect that
> given a 4-byte wide bus clocked at 33MHz performing a read from cache
> and a write into the destination userspace buffer, the buffer cache
> read speed should be more like 66MB/s. Is there another read/write
> pair that I've overlooked?
Basically you measure the main memory bandwidth for copying.
So, you should expect: ~50MB/s with Pentium and ~100MB/s with P-II (100MHZ
FSB), as reported by the ctcm tool. (c't cache monitor, www.heise.de/ct)
P-II does what it's expected to: 100MB/s.
I don't know exactly, why Pentium is slower than expected. It may be Linux
buffer cache handling overhead (not very likely). I think it's some of the
strangenesses of Pentium architecture.
Memory copying speed on a Pentium depends on whether you
* use movb or movl or use fpu
* implement software write allocation (loading target L1 cache lines)
* how many bytes you copy within the loop body (branch prediction issue?)
I don't know what mechanism the linux buffer cache uses.
I've seen 36MB/s on my old Cx6x86-P200+ (2x75MHz), IIRC.
Regards,
- --
Kurt Garloff <K.Garloff@ping.de> (Dortmund, FRG)
PGP key on http://student.physik.uni-dortmund.de/homepages/garloff
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Barry Zubel <root@vkresearch.com>
Date: Fri, 4 Dec 1998 13:02:20 +0000 (GMT)
Subject: Re: Strange System Behavior
On Thu, 3 Dec 1998, Paolo Galtieri wrote:
> Folks,
> I recently bought my first PC, however, I've been working with
> Unix for many years so this is not a newbe situation. Since I got
> it I have had nothing but strange problems with it which I so far
> been unable to determine whether they are hardware problems or
> software. I have run diagnostics on the hardware and I've brought
> the system back once already and there doesn't seem to be any obvious
> hardware problems, but yet the system will not stay up more that 24
> hours. First I'll describe the hardware then I'll list the various
> problems I've encountered.
>
> Motherboard: ASUS Dual Pentium II (350Mhz) w/ on board SCSI
> 1 4.3 GB disk
> 1 9 GB disk
> 1 5.1 IDE disk
> Matrox G200 video card
> Ensoniq AudioPCI sound card
> Eexpress pro 100 Ethernet card
>
> I have RH5.2 + 2.1.130 kernel loaded on the IDE drive.
>
> Here are the problems I see in no particular order.
>
> 1) When I build the kernel it takes about 10 - 20 tries to get it to
> build. This is due to the compiler terminating with sigsegv or
> other error. I'm using the gcc-2.7.2.3-14 compiler.
>
> 2) I will run make and make will lock up, i.e. it becomes an unkillable
> process, and my only resort is to shutdown and reboot the box.
> This problem looks like a traditional deadlock scenario. The wait
> channel field in the ps output always shows end as the address it
> is waiting on.
>
> 3) The system will lockup. This occurs even if the system has been
> idle. It will be working when I go to bed, and be locked up in
> the morning. By locked up I mean no keyboard or mouse input works
> for my X session, and any attempt to ping or telnet from another
> box fails. Sometimes ping will work, but not telnet. Obviously
> switching to an alternate console fails. This has occured whether
> or not I am running xscreensaver.
>
> 4) Various processes will terminate with sigsegv while running. e.g.
> xterm's will simply go away, or I'll be logged off my xsession
> completely.
>
> 5) At various times during the boot sequence I will get various oops
> regarding either NULL pointer dereference or problems accessing
> various virtual addresses.
>
> 6) On at least 2 occasions CPU 1 has panic'd with the following:
>
> Attempted to kill the idle task!
>
> 7) I'm getting lots of messages of the form:
>
> schedule_timeout: wrong timeout value <some val> from <some ptr>
>
> in /var/log/messages
>
> My question is has anyone had any success running an ASUS dual pentium
> motherboard along with a Matrox G200 video card ( using the matrox X
> server from SuSe)?
>
> If not, does anyone have a suggestion as to how I can best debug these
> problems, or better yet does anyone have fixes :-)?
>
> Any thoughts would be appreciated.
>
> Thanks
> Paolo
> --
> Paolo Galtieri Senior Software Engineer
> Motorola Computer Group INTERNET: peg@phx.mcd.mot.com
> 2900 S. Diablo Way VOICE: (602) 438 - 3754
> Tempe, AZ 85282
>
> -
> 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/
>
I'd place money on a hardware fault
Barry Zubel
VK Research Ltd
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Tigran Aivazian <tigran@aivazian.demon.co.uk>
Date: Fri, 4 Dec 1998 12:38:46 +0000 (GMT)
Subject: Re: [OFFTOPIC] Re: linux kernel hackers discover new theory of relativity!
Peter,
Depends on what you mean by "gravity".
Many many years ago I was perfectly content with the strikingly naive
notion of "gravity" as curvature (Rieamann tensor) of time-oriented
connected paracompact Lorentzian manifold supposed to represent our
spacetime; in such simple context your "*is*" should most certainly
be replaced by "*is not*", i.e. the curvature of one case is zero
and of "real gravity" is not.
If one, however, spends enough time on researching geometrical nature of
mass and electric charge one would be quite tempted to comment that there
is at least a seed of truth in your remark. In other words, one should seek
some sort of combination of the well-known concepts of "topology" and
"differentiable structure" (=manifold) which will embody Einstein Equation
in most natural form, provide explanation for the "nature" of singularities
and (ideally) encompass QM/QG in its conceptual framework and, most
importantly, provide criteria for selecting so-called "natural topology"
and "natural diff structure" which are used silently in GR when considering
concrete solutions and yet are never imposed/required when introducing the subject
abstractly.
But, in any case, you suggestion to study GR is definitely the best one can
receive in his life on this planet - here I agree with you completely :)
Regards,
Tigran
On 3 Dec 1998, H. Peter Anvin wrote:
> > Babylon 5 is closer to the reality of physics - the spinning station
> > creates artificial gravity, but only for people standing on the
> > inside walls of the cylinder. Those who are near of rotation axis
> > are in zero-gravity. This is not gravity guys, it's centrifugal
> > force, the same that pushes you against your car's window when you
> > take a sharp turn. --
> >
>
> Actually, it *is* gravity. Read up on general relativity if you don't
> believe me.
>
> -hpa
> --
> PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
> See http://www.zytor.com/~hpa/ for web page and full PGP public key
> I am Bahá'í -- ask me about it or see http://www.bahai.org/
> "To love another person is to see the face of God." -- Les Misérables
>
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Date: Fri, 4 Dec 1998 11:30:48 +0100 (CET)
Subject: Re: Problem with 1G RAM
On Thu, 3 Dec 1998, Tymm Twillman wrote:
> On Thu, 3 Dec 1998, Alan Cox wrote:
>
> > >
> > > i tried 2.1.130. it works fine with memory up to 1008M. at 1016M, the kernel
> > > boots, but sound and some other modules won't initialize correctly and file
> > > system is in trouble as well ( cuz the root is not cleanly unmounted even via
> > > regular shutting down). beyond 1016M, the kernel either reboot itself right
> > > away or just hang.
> >
> > It would. See include/asm/page.h for directions to building a 2Gig/2Gig kernel
>
> Perhaps it would be a good idea to clone this info in the Documentation
> directory (especially as the # of people with > 950 MB of memory is only
> going to grow, and include/asm/page.h isn't the most intuitive place to
> look :) ) ... Or even have it as a configuration option (with appropriate
> warnings, of course)
I will set up a Linux MM documentation section in the Linux
MM site. Then I'll also put a pointer file ("More.Info" or
something like that) in the Documentation directory.
Then every kernel subsystem is free to setup a web page/site
to document problems, internal structure, hacking info, todo
lists and tips&tricks themselves.
Including all possible info with the kernel would be far too
much and restricting the available info would be a bad thing.
Once each subsystem has it's own site there could even be a
bit of competition over who's got the best site -- this will
undoubtedly annihalate the "no support" FUD we've all been
hearing.
comments?,
Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Date: Fri, 4 Dec 1998 11:17:52 +0100 (CET)
Subject: Re: NO ROM BASIC
On Thu, 3 Dec 1998, Konstantyn Prokopenko wrote:
> I'm new in Linux and I've got a problem compiling a kernel.
> I have dual PENTIUM II motherboard with 128 Mb memory runing Red Hat
> Linux. I compiled the 2.1.128 Linux kernel using:
>
> make config
> make dep
> make bzImage
> make install
I guess you want to do a 'make bzlilo' here, making sure that
the new kernel lands in the same place where the old kernel
was.
To be absolutely sure, you probably also want to make a zdisk
(or bzdisk, if it exists).
When you are using modules, don't forget to build them too!
> Then I rebooted. When it starts, it goes to 40 column mode and
> says "NO ROM BASIC"
What, your spiffy new PII came without even a decent ROM
BASIC? What a ripoff... Sheez, you'd expect those computer
salesmen to have gotten some decency by now -- guess not. :)
succes,
Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Date: Fri, 4 Dec 1998 13:17:27 +0100 (CET)
Subject: Re: Dumb question: Which is "better" SCSI or IDE disks?
On Thu, 3 Dec 1998, Russell Leighton wrote:
> What are good rules of "thumb" for
> choosing IDE vs SCSI when building
> a Linux system?
When there are not too many processes accessing the disk at
the same time, IDE is cheaper and thus to be preferred.
> Both are fast these days...I always
> thought that IDE==cheap, but loaded
> the CPU, so you didn't want that in
> a server or high performance machine
IDE and SCSI both load the CPU about as much. The difference
is that SCSI is a lot smarter and allows multiple outstanding
commands to a device and multiple devices being busy at the
same time. This means that you can get a lot more work done
with a SCSI subsystem than with an IDE one.
If, for instance, you have 2 IDE drives on the same channel
and you are waiting for drive 1 to read a sector, you cannot
tell drive 2 to get off of it's lazy butt and fetch you some
data.
With SCSI all drives can seek for data at the same time, the
only time they block eachother is with the actual data
transfer, which comes out of a buffer anyway so that contention
is minimal.
Command reordering is another nice feature of SCSI drives, but
since Linux does something like that in software too it's not
that much of an issue anymore. IDE write caching has narrowed
that gap even more.
Scatter-gather _is_ a good argument for SCSI (IMHO of course)
since that allows you to give a command with lots of arguments
to a drive and the drive can continue processing the commands
(seeking) even while it is returning other data or accepting
new commands. Very nice for /home or /var...
MP3 or movie streaming can just as well be done from IDE drives
since you want to do large readaheads anyway and IDE is much
cheaper and has the same transfer speed and reliability.
I am using 2 SCSI and 2 IDE drives myself. The IDE drives do
mainly long, non time-critical data transfers and the SCSI
drives do lots of small transfers.
cheers,
Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Date: Fri, 4 Dec 1998 10:42:20 +0100 (CET)
Subject: Re: Linux-2.1.131..
On Thu, 3 Dec 1998, Andrea Arcangeli wrote:
> On Thu, 3 Dec 1998, Rik van Riel wrote:
>
> >
> > if (buffer_over_borrow() || pgcache_over_borrow())
> >- shrink_mmap(i, gfp_mask);
> >+ state = 0;
> >
> >This is a good fix as it returns behaviour back to the normal
> >and desired behaviour (except for too heavy cache pruning).
> >This patch would have been better however, since it does what
> >we want without too heavy cache pruning or massive swapout
> >frenzies.
>
> do_try_to_free_page() starting from its name must try to free 1 page. If
> shrink_mmap() just freed one page we have just finished our work and in
> such case why to continue eventually with a not needed swap out?
You haven't read my message, have you? :)
The next paragraph contained my own fix that does both
the above and frees memory while swapping...
cheers,
Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
End of linux-kernel-digest V1 #2941
***********************************
To subscribe to linux-kernel-digest, send the command:
subscribe linux-kernel-digest
in the body of a message to "Majordomo@vger.rutgers.edu". If you want
to subscribe something other than the account the mail is coming from,
such as a local redistribution list, then append that address to the
"subscribe" command; for example, to subscribe "local-linux-kernel":
subscribe linux-kernel-digest local-linux-kernel@your.domain.net
A non-digest (direct mail) version of this list is also available; to
subscribe to that instead, replace all instances of "linux-kernel-digest"
in the commands above with "linux-kernel".
-
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/