Re: missing mxcsr initialization
MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Comment-To: Alan Cox <[EMAIL PROTECTED]> Disclaimer: Not speaking for Transmeta in any way, shape, or form. Copyright: Copyright 2000 H. Peter Anvin - All Rights Reserved Followup to: <[EMAIL PROTECTED]> By author:Alan Cox <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > > > corrected for include the facts that the XMM feature bit is an Intel specific > > > bit that other vendors may use for other things, so you need to test vendor == > > ^^^ > > Note that they shouldn't do that! I would consider a very bad thing if they > > goes out of sync on those bits. > > CPUID is vendor specific. Every bit in those fields is vendor specific. Every > piece of documentation tells you to check the CPU vendor. Every time we didnt > bother we got burned. > > I keep hearing people saying things like 'bad thing' 'assume standards'. Well > all I can say is cite a vendor issued document which says 'dont bother checking > the vendor'. > Intel does it because they want every other chip out there to act like a 486. > > And when you can't find that document, put the checks in so we dont crash on > an Athlon or when using MTRR on a Cyrix III etc > Chips that don't implement what they claim to implement are buggy and should be treated as such. SPECIAL-CASE THE BUGGY CHIPS, NOT THE PROPERLY FUNCTIONING ONES. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PROPOSED PATCH] ATM refcount + firestream
Hi all,
Here is the second try for the atm refcount problem. I've made made
several enhancement over the previos patch. Can you take a look at it if
I've missed anything? (This time it also includes the driver for the
firestream card. That's why the patch is so large. It's gziped and
uuencoded).
Patrick
begin 644 patch.gz
M'XL(",4P^3D"`W!A=&-H`)Q::W?:2-+^C']%#;/OQ(X!BVMLO,D.QCAAQ\8,
MX#B9/7LXLFBPQD)B=(GCS)G__CY5W1(BD,PF?!!27ZJKJZJKGBIIYL[G5`ZI
MG)#G^LG''CX'7P4)O<)73LQ
M54^H:K6KS7:SJNG]_#.5:[52BPYQ?4$__[Q'!;H+`H^>$7X]W[[S%-5N:?2.
M[I(PBB/:#U:Q&_BV=_",NM>#B_[K:6=R->T-^M.SF]%X,AV]F]9N]TC_YNZ>
M^3O$7QRZ46S'BIY=)+^[<930A1NJ<1PJ>TG[%V-LX&)<;38/:(/V17_4&T]&
MOF'EU3TB_3?
M4XKOE9^RG8K`"$!]C)4_4S.:J;MDL7#]Q=8BT_/>VKMA?8>!9>2^:E_5$[8O7*L-,3`BR-*=
M[Z5_>X?N7/U!^__8WZGR@]+3P=[A]?3Z[-]C.GP)4PK!$UM,)=@[5%ZDV+3^
MAL3R@`==?8%(RM&A^=O;18Z5++S0FI=/D`((T/6[K"D9GI\<-ZP:FK_+%NSE
MG1U%]BP(*\[_KHG\K&^TB?S4PD7HPO%X1"_(:K7K+^![OL,NMDBR;;`OJ[?K
M)VVKE;.-6K-:JC9A'G)C&0,A^FLOO>R5B8Z.""M]4'Y,RV"6X*0DOA?8,WJ\
MYV,3>4JM<"AI_V%I>U[@',V"1__`S)P%W!7?NQ'9_A,I._1<%=)CD'@SC3RH[O(Z9R=7T^[0^ZTYMQ;]J]OAE,3KF5N0/]
M!1Q0M+(=17-,#9*0/C@.17$RG_,(?GA)AC':C]Q/*ICO0T13]!R4Z/7%="T-QJ5J!@D,05S6BKP_/1#\4#8
MT6R>]S;8%`IF.^7>X/JJ=W6:B1:Z8B;*KV;JPW1FQS88W?\0N#-Z?L!\GVH=
M-6I-Q(9#_%LXR5I#V'=D/['/I+?#_M';;I\@WWFH%-D+VQ5'RK863N_<>)_/
MS]N+:>?\?%3Z*5MU[MF+B#>=BGB;=\TY;L&O9N:%51=F6B&&<<+(M4N
ML$SEML2-$0YSNR"-?*O;%E/=+*T+TX'55V'@3.$.3%?VR+[A2WTE[H2=J;!=
MF+SICZ?8PLUE#PO]Q7NBH^?9C^Z#)%(/QDK7[4??Z2/B)6O,]=WXFYQ$?MJW
M>HG\7#G3G55(\.C58W83U>\)']LT4S_1`,%VH[[V$\T&*QU7XR(*F!BQNW7M
MZ4S%RHGWV9!^-"'E1W<^4_,-"'$]ZH%:3Q\4_J44<&@5>E2.SF'A:YUFD<,=
MBZQQ2HY$M(O#@CF3/$K,^WL-(796WV@#,N/;U2_3\LBT5FLWC]N-VO=I7I/[
M3.FUMO4B%QRL$SGJ\L=:WR/&?:Y#XJ,TD2D\%XQ(SOT^0GH":NQAT$C/<4&\
M_G.O7-CA7@X+1\]I$"`P^(L*?M2/_&>Q#A21B["@J%T^((*@1KU;PF$5+Z3]
M4`WN![S5,B]4,$ZHD+&5NJ*"&SBQE^^1!NY)?53:8?Q1(>]RTCYN`\]?ZH(W
M*AAGE/=&J3,2INMUJU0]IL-Z';&VKME>BXQI98'@>7IWNC$F$ZMX[<*NN*@/
M9QI.3-Q+PUY&]J"T$??*!0E[6:_H;+?2-@=BM<+GX:U<$#TQ&^#`<`V9+9`V
MJ'#_O/=V>MDYZUU**%J;4+"*2FX\+PUN+B449RM))"X4'CBZ[6J\F'E^N5BIF=!4L=*X4\=;JNA.A0L5EJ@W
MO+BDRU'WJ-_M:"+8#6WD%*#Z%+J+^UCXJ)Z<-)&AG9P`@=FSA2*DTX]!^!#1
M93Q+-\#\,]B9L&N$LUF$V'@*]Z)@'C_:H3JEIR`AQ_8!VF8X::%[EP!5NS&S
M<`1D#.3NSI\D68N!WV?@G>$CCN0R8C3+#Z\'-_1:85NV1\/D#LB<+B%0/P*L
MQ-+<$MU#)G="AV=<,`]CPP-=!"!L;CNC467^*P?$]HWI.A6BL
MF"U)E+\BX;DH"5($7K%=+S+[?@^U1O>2+=W;'Q34ZRB8-\P*V=/JZ>]5QT1L
M+P#RY5WJ`&OD>,KICA_$)7K$\0"3P;92>?I:KR7J^TZE1,T3FB@)TD,/N5>)
MQ@D3X!!'9T$4\\BK#I%5JU:KY6H=P()NQIU4E8;?X25KT@E\;-C7>CQ*HA#Y
MHW/DI`?EB(?!@FPZ5W>N[3.%Z`FQ9"FGR^A>"CC=Z^'[_N!UVG;);HX>^*!Z
M."A)Z"@(51\I!I"^XR4S1?\4=X@%I5YW_VJ[2V>].[LB!P=B9X]>=S>]Y<[F
ME>/N;$=6[`<[>]@;?:$=OG`WPX&OXMT]#W=(FG=V88KVK3M[9\JSGW;VN,$J
M"'DUI&-BX*'Z(T$8$#@`G;(N/I^3N+OW*HG*K@['7MEWKN?&NWE`1`>V^*S+
MCI9'=T^Q"D(XPAU]VL!V=<#I^(L='5M<+%=,;*5P:.$>T"0>^'FV;.`X"1.*\I?Q/0]P3\JCJW(3Q!+O">A$=L/"(NS#W;*
MGBER12*=I?U[`)_Z]+FT,,)S'T`3RVN)*)ITAT?](>UW(GI$S`2MNP^L!D]7
M>'(ZXX*9TE#D@-UHF`:6YXSI'DQ5#201"=FABL?G2I$-E"60!T[Z:G)3$M>9
M;>H>3YXF$W'&@.";*DJ7Y>9S&`;6%XYL[5U%42&K/JJ8+"T'6.@\R>+)(QC0
MOEB7S"`<'R*3#0G:*5&T4@[@"5MIL?FB5808#7Y*387=!=L(R:Y=2187@3'K
M>^6M*BR0)S''3(]"0X!;U:HURK)][7JD&@G&*G2KHZ+2U(VZHH!U7&^[V6JPJL`-I
M0_0&2L!$[#M&/*T&+QP\`OD`P#+_1:UZ8;\(+LV!B2+8DU&H<^_*Z815X:Q!
M'G-7>5B[SPX#8GGP@T>@L4%'UDM4V8M^L]@^%^"W_NS6CLN$;*2%J[-:JTDNBX!
MXS?0WK!.T%YMU8_1!&YJ%C)REHL7+&KMK=3BA5R/Y7K"EZHEUZI<:W)M2"]V
M;I@&AK(R]E9!X.7X8_:$&WT5]C2GFNL6&HGJ-;[B[R\I<,E+%4Z?^'67K/)E
MXD(E=]4$\]?/B.OJV1<%8/9K90(XSLFE)=I45J%9-*2T9U*6'-Z.'C3V(@M-K[M9<(=@'IG254HJ#F*FU06X)/$J-J_61
M@'EQD>D>#IZ-/@JRI&'.V;]@S0B>1;\21%02F,(YTQQS=?`%F3$?=/C.<";)
MSR*(G7N[K2&N'#M^HTK=SA7MOQT>O>W"[6$$I960"+F.]RB!B".)N%2<0_`*
M,CZ@H]#1[D`S*//9VZ;^`]`=K,(GW'D`*V;E_&%^DI!'[L)G-_ZH)"73)UB6
M8")*7K+.3#[&-,T"B#M^9$0SE_0R\W/I=(L]0K52DW`B;W"91-I;Y5ZK8@DK
M/KLO^TYY[++7\R4.(5!RJV7\BQ#1PDH',G9<3Y+)Y00+R38BLCE`@P@HJ/O"L>AS43
M3LG3])K55B0IA;%EPYL+!=.]U(&@6JE4#C()G8OC9XSN0@Z?E`%!&P8O=$N\
M/HQ"XA^)T/)&DTO0<,2N5[&[=#_IZ`_FF2&V-'>5IL?ZH*T+0AR:---)17%XGAD=WACSH,I*YD4)M):
M-_/8:?3>]D;OM:@=9K@BN;LC88]#+VL#`EIJZ)*:F5G*G)G2A\X'8FA
MDU!>;99?F216,GYSUFC8[4/K>K.IG0$O@W'@*X=]UU*?*S>*$D:-LJ-L(ZD`
MUTQB7[!:8`TPEOC0'*0&C*!15@I@TU()<+%GI"EDUCH`#GBV%+MBV"K[>1:M
ML=HCK(W/XC)Q&'<%R>)>H)M0T3`1Z:2\(I87`IQ6)`+F!6QC8V*W+A/E13+"
M"^P*(U-CU]`UP]WLU.5]M20#L?&@R.:HC
M3(0DY8TJ-*(6,'+!XYH;N*@_`'H6U>
MZ.#LA?0<">;4L/H?`1=[AX4BV+O^I4TZ]>3]L\A[U\,BX\\=W5M=8QU(#:C4
MZM@O-KTT=7DM)N-DY&
MG<%X^,6.;K[GQM=.>Y9OA)!5R.6[:FVKI;[5TLA((6P%"Q^NXPO46ED+(_7E
MW1.;4!BWJ=.Y;.I[,\*(>Y4@FYEMMB$ID[/D+A7,S_2E$7)WI^TYB2>)/*?:
M.#?R"4=*=ATP3*_XI(TQMNTUR0F=>FVC.>`P%`*`2.:C[QP>!VB:'Y=)H-;<
M:FEMM;S8:CG>:CGYO*5N?29;+Q.N'Z2)C`/(=?5902`#X?3PS*OFO3UDB`HCOPDF`3]\XA-DV&]6M
MEBT3;6R9:*.QU;*EB,:6(AI;BFAL*:*QI8BFM=6RQ7-SB^?F%L_-+9Z;6SPW
MMWAN;O'6YKGOTY)T('VSV[X![^>].VE6OOGRV'W
MNLAOGXOGV=WH;/2K-;U=/U3S#[7\0SW_8$T'%_E)^:?:QE,]>SJ[&$['77W?
M'_0GZSO^6$H_W8R[/32#!IGD_DVG=M[-YGV!X;+T;OSJ\YT7&1!FW<")CH/
MW[R?]JXOJ%S=;.M>]CJCSN4EE6L\W+R99X`+X#MU^9T$:T72=;4H,;P]75/?
M-9RI#B;=*4LLT^
Re: 2.4.0-test9 + LFS
On Thu, Oct 26, 2000 at 09:56:06PM -0400, Wakko Warner wrote: > I attempted to create a 4gb sparce file with dd. It failed. > I created one that was 2.1gb in size which worked. Then I appeneded more > junk to the end of the file making it over 2.2gb. > > doing an ls -l shows: > ls: x: Value too large for defined data type > > NOTE: this worked in 2.4.0-test6 and I believe it stopped working around > test8, but I'm not sure. May have been around test7. Your userspace tools are not using LFS compliant open(O_LARGEFILE), and stat64() methods. EXT2 got corrected to do LFS limited open() handling at correct limit (2G-1) at around that time. There still lurks some mis-compliance issues at read() and write() which are still allowed to go over 2G-1 marker without the fd having O_LARGEFILE flag. /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Negative scalability by removal of lock_kernel()?(Was: Strange performance behavior of 2.4.0-test9)
On Fri, Oct 27, 2000 at 03:13:33AM -0400, Alexander Viro wrote: > > > On Fri, 27 Oct 2000, Jeff V. Merkey wrote: > > > > > Linux has lots of n-sqared linear list searches all over the place, and > > there's a ton of spots I've seen it go linear by doing fine grained > > manipulation of lock_kernel() [like in BLOCK.C in NWFS for sending async > > IO to ll_rw_block()]. I could see where there would be many spots > > where playing with this would cause problems. > > > > 2.5 will be better. > > fs/locks.c is one hell of a sick puppy. Nothing new about that. I'm kinda > curious about "n-squared" searches in other places, though - mind showing > them? I've noticed in 2.2.X if I hold lock_kernel() over multiple calls to ll_rw_block() while feeding it chains of buffer heads > 100 at a time (one would think this would make the elevator get better numbers by feeding it a bunch of buffer heads at once rahter than feeding them in one at a time), performance gets slower rather than faster. I did some profiling, and ll_rw_block() and functions beneath it was using a lot of cycles. I think there may be cases where the code that does the merging and sorting is hitting (O)(N)**2 instead of (O)(N). When I compare the profile numbers to the buffer head window in between calls to ll_rw_block(), the relationship is not (O)(N). By default I just hold lock_kernel() over the calls to ll_rw_block() for each buffer head in 2.2.X. 2.4 does not need lock_kernel() to be called any longer since ll_rw_block() is now multi-threaded. The overall model of intereaction has not changed in 2.4 from 2.2 much. I just no longer have to provide the serialization for ll_rw_block() because it's provided underneath now, but what I saw indicates that as the request list gets full, some of the logic is not performing at a relationship of (O)(N) # requests vs. utilization. This would indicate somewhere down in that code, there's a spot where we end up spinning sround a lot mucking with lists or something. :-) Jeff > > BTW, what spinlocks get contention in variant without BKL? And what about > comparison between the BKL and non-BKL versions? If it's something like > BKL no BKL > 4-way 50 20 > 8-way 30 30 > - something is certainly wrong, but restoring the BKL is _not_ a win. > > I didn't look into recent changes in fs/locks.c, but I have quite problem > inventing a scenario when _adding_ BKL (without reverting other changes) > might give an absolute improvement. Well, I see a couple of really perverted > scenarios, but... Seriously, folks, could you compare the 4 variants above > and gather the contention data for the -test9 on your loads? That would help > a lot. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre6
On Thu, Oct 26, 2000 at 11:58:03PM -0700, Linus Torvalds wrote: > > Thanks to everybody who has been testing. > > pre6 has tons of small fixes, the most noticeable of which are > > (a) the new compiler requirements (sorry, but it turned out that 2.7.2.3 > really is too subtly broken with named structure initializers that > are very heavily used these days inside the kernel) > > Suggested stable compiler: gcc-2.91.66, aka egcs-1.1.2, which is the > one most vendors have been shipping for a long time, and while sure > to be buggy too has not been found to be seriously so at least yet. > > Other modern gcc versions may well work too. > > (b) various PCI fixes that used to make 2.4.0 completely unboot/usable on > certain machines (ALI chipsets with certain PIRQ routing tables and > laptops with some docking bridges. Oh, and PIIX4 chipsets with USB > enabled and certain other magic things going on). > > Let's hope that there aren't too many more of these. The ALI one in > particular was "interesting" to chase down. More interesting than I > personally need in my old age. > > The rest of the changes should be mostly unnoticeable. > > Still known: the same old "page->mapping = NULL" thing that has not seen > an acceptable fix yet. If it wasn't for that, I'd have called this test10 Almost ready to ship. I have not seen this bug show up here in any 2.4 kernel I have tested. Wonder if it's specific to certain hardware (Paging or stale TLB bug?). > already and be done with it. Super-Al to the rescue (and no, that was not > a reference to the current sad state of US politics). (not meant to offend) Al Gore's definition of a family unit in America is the same as Clinton's -- a family can be defined as a man and a goat. There's some web sites showing that in 1988 and 1989, Al Gore was an extreme right wing conservative. Things have sure changed :-) Jeff > > Linus > > - > > - pre6: > - Jeremy Fitzhardinge: autofs4 expiry fix > - David Miller: sparc driver updates, networking updates > - Mathieu Chouquet-Stringer: buffer overflow in sg_proc_dressz_write > - Ingo Molnar: wakeup race fix (admittedly the window was basically > non-existent, but still..) > - Rasmus Andersen: notice that "this_slice" is no longer used for > scheduling - delete the code that calculates it. > - ALI pirq routing update. It's even uglier than we initially thought.. > - Dimitrios Michailidis: fix ipip locking bugs > - Various: face it - gcc-2.7.2.3 miscompiles structure initializers. > - Paul Cassella: locking comments on dev_base > - Trond Myklebust: NFS locking atomicity. refresh inode properly. > - Andre Hedrick: Serverworks Chipset driver, IDE-tape fix > - Paul Gortmaker: kill unused code from 8390 support. > - Andrea Arcangeli: fix nfsv3d wrong truncates over 4G > - Maciej W. Rozycki: PIIX4 needs the same USB quirk handling as PIIX3. > - me: if we cannot figure out the PCI bridge windows, just "inherit" > the window from the parent. Better than not booting. > - Ching-Ling Lee: ALI 5451 Audio core support update > > - pre5: > - Mikael Pettersson: more Pentium IV cleanup. > - David Miller: non-x86 platforms missed "pte_same()". > - Russell King: NFS invalidate_inode_pages() can do bad things! > - Randy Dunlap: usb-core.c is gone - module fix > - Ben LaHaise: swapcache fixups for the new atomic pte update code > - Oleg Drokin: fix nm256_audio memory region confusion > - Randy Dunlap: USB printer fixes > - David Miller: sparc updates > - David Miller: off-by-one error in /proc socket dumper > - David Miller: restore non-local bind() behaviour. > - David Miller: wakeups on socket shutdown() > - Jeff Garzik: DEPCA net drvr fixes and CodingStyle > - Jeff Garzik: netsemi net drvr fix > - Jeff Garzik & Andrea Arkangeli: keyboard cleanup > - Jeff Garzik: VIA audio update > - Andrea Arkangeli: mxcsr initialization cleanup and fix > - Gabriel Paubert: better twd_i387_to_fxsr() emulation > - Andries Brouwer: proper error return in ext2 mkdir() > > - pre4: > - disable writing to /proc/xxx/mem. Sure, it works now, but it's still > a security risk. > - IDE driver update (Victroy66 SouthBridge support) > - i810 rng driver cleanup > - fix sbus Makefile > - named initializers in module.. > - ppoe: remove explicit initializer - it's done with initcalls. > - x86 WP bit detection: do it cleanly with exception handling > - Arnaldo Carvalho de Melo: memory leaks in drivers/media/video > - Bartlomiej Zolnierkiewicz: video init functions get __init > - David Miller: get rid of net/protocols.c - they get to initialize themselves > - David Miller: get rid of dev_mc_lock - we hold dev->xmit_lock anyway. > - Geert Uytterhoeven: Zorro (Amiga) bus support up
PATCH 2.4.0.10.6: always no-strict-aliasing
Linus Torvalds wrote: > (a) the new compiler requirements (sorry, but it turned out that 2.7.2.3 > really is too subtly broken with named structure initializers that > are very heavily used these days inside the kernel) > > Suggested stable compiler: gcc-2.91.66, aka egcs-1.1.2, which is the > one most vendors have been shipping for a long time, and while sure > to be buggy too has not been found to be seriously so at least yet. > > Other modern gcc versions may well work too. Since egcs-1.1.2 supports -fno-strict-aliasing, would the attached patch against linux/Makefile be appropriate? -- Jeff Garzik| Raft naked... Building 1024 | It adds color to your cheeks. MandrakeSoft | Index: Makefile === RCS file: /cvsroot/gkernel/linux_2_4/Makefile,v retrieving revision 1.1.1.11 diff -u -r1.1.1.11 Makefile --- Makefile2000/10/22 23:14:50 1.1.1.11 +++ Makefile2000/10/27 08:32:28 @@ -16,7 +16,7 @@ FINDHPATH = $(HPATH)/asm $(HPATH)/linux $(HPATH)/scsi $(HPATH)/net HOSTCC = gcc -HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer +HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer +-fno-strict-aliasing CROSS_COMPILE = @@ -87,7 +87,7 @@ CPPFLAGS := -D__KERNEL__ -I$(HPATH) -CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer +CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer +-fno-strict-aliasing AFLAGS := -D__ASSEMBLY__ $(CPPFLAGS) # @@ -181,9 +181,6 @@ DRIVERS += $(DRIVERS-y) include arch/$(ARCH)/Makefile - -# use '-fno-strict-aliasing', but only if the compiler can take it -CFLAGS += $(shell if $(CC) -fno-strict-aliasing -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-fno-strict-aliasing"; fi) export CPPFLAGS CFLAGS AFLAGS
Re: Quota fixes and a few questions
"Stephen C. Tweedie" wrote: > > Hi, > > On Thu, Oct 19, 2000 at 07:03:54PM +0200, Jan Kara wrote: > > > > > I stumbled into another problem: > > > When using ext3 with quotas the kjournald process stops responding and > > > stays in DW state when the filesystem gets under heavy load. It is easy > > > to reproduce: > > > Just extract two or three larger tar.gz files at the same time to a ext3 > > > filesystem with activated quotas... > > Which ext3 version, exactly? 0.0.2f had quota problems because ext3 > wasn't doing quota writethrough, so that inode cleaning could force > out random dirty quotas at any point. 0.0.3b should fix that. If it > doesn't, I'll try to reproduce it here. Hi Stephen, unfortunately 0.0.3b has the same problem. I tried it with a stock 2.2.17 kernel + NFS patches + ext3-0.0.3b and the quota rpm you included. Extracting two larger tar.gz files hits the deadlock reliably. Juri -- [EMAIL PROTECTED] system engineer innominate AG clustering & security networking people phone: +49-30-308806-45 fax: -77http://innominate.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
IO-mapping.txt and ISA memory space
Hi Linus,
We have isa_*() functions to access ISA memory space since a while.
I'm still missing isa_{request,release}_mem_region(), though.
--- linux-2.4.0-test10-pre5/Documentation/IO-mapping.txt.orig Sat Aug 5 13:21:13
2000
+++ linux-2.4.0-test10-pre5/Documentation/IO-mapping.txtThu Oct 26 22:49:30
+2000
@@ -141,7 +141,7 @@
* read first 32 bits from ISA memory at 0xC, aka
* C000: in DOS terms
*/
- unsigned int signature = readl(0xC);
+ unsigned int signature = isa_readl(0xC);
- remapping and writing:
/*
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
Hi! > So this is not our problem here. Anyway I guess it's time to hunt for > i8259 accesses in the kernel that lack the necessary spinlock, even when > they're not probably the cause of the problem we see here. BTW what about trying to modify your work-around code to make it attempt to read the timer again? This way we could test whether it was a race condition during timer read or really timer jumping to a bogus value. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "This line is umop apisdn." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
IDE + RAID + SMP + PIII crashes
I have a number of machines (on 2 different motherboards) that if I run 2.4 on hang with an NMI error about 2/3's of the way though boot (about were crond starts on redhat 6.2). 2 of the machines are based on Supermicro P6DBEs the other is based on a Gigabyte GA-6BXD. I am using the onboard ide and also have tried a Promise 20262. There are RAID 0 and 1 arrays on the manchines. The exact hardware specs are: Supermicro P6DBE 2x P3 650 512Mb SDRAM 2x ST310212A (mirrored) 2x Maxtor 53073U6 (Striped) on a Promise 20262 Gigabyte GA-6BXD 2x P3 650 256Mb SDRAM 2x Westen Digitals (model unknown as the machine is at home and I'm not) I have posted a decoded oops sometime ago, I can generate another one agaist a current test kernel (the latest I have tried is test9) I can test experimental / unstable / eat your fs patches on the gigabyte machine, the Supermicro boxes are production machines. -- Tim Fletcher - Network manager .~. /V\ L I N U X [EMAIL PROTECTED]// \\ >Don't fear the penguin< [EMAIL PROTECTED] /( )\ ^^-^^ "First they ignore you. Then they laugh at you. Then they fight you. Then you win." - Gandhi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM-global-2.2.18pre17-7
Timothy Ball wrote: > > I get similar eth0 hangs using a 3c59x. Though outside of rebooting I > have no clue how to get networking going again. If this is 2.2.17 then please send me the details. If it's something earlier then you will need to use the 2.2.17 driver. Or, even better, the 2.2.18 candidate: http://www.uow.edu.au/~andrewm/linux/3c59x-2.2.18-pre16-1.gz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Reboot problems with test9 on SiS5582
When I run "/sbin/shutdown -r now" on a SiS5582 based system with a Cyrix MII cpu, the machine shuts down as far printing: Rebooting system. It then hangs. This is a RedHat 7.0 based system (The kernel was compiled with RedHat 6.2) The lspci on the system gives: 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 5597 [SiS5582] (rev 10) 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev 01) 00:01.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) 00:0d.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) 00:14.0 VGA compatible controller: Silicon Integrated Systems [SiS] 5597/5598 VGA (rev 68) The machines reboots fine with the shipped RedHat kernel (patched 2.2.16) -- Tim Fletcher - Network manager .~. /V\ L I N U X [EMAIL PROTECTED]// \\ >Don't fear the penguin< [EMAIL PROTECTED] /( )\ ^^-^^ "While preceding your entrance with a grenade is a good tactic in Quake, it can lead to problems if attempted at work." -- C Hacking - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + LFS
> > I attempted to create a 4gb sparce file with dd. It failed. > > I created one that was 2.1gb in size which worked. Then I appeneded more > > junk to the end of the file making it over 2.2gb. > > > > doing an ls -l shows: > > ls: x: Value too large for defined data type > > > > NOTE: this worked in 2.4.0-test6 and I believe it stopped working around > > test8, but I'm not sure. May have been around test7. > > Previous kernels allowed up to 4gb to be returned by the old stat. > Upgrade your glibc and fileutils -- most recent distributions (Red Hat, > SuSE, ...) are LFS ready, and the only reports I've seen about this > concerned Slackware. I did upgrade that and it didn't help anything. -- Lab tests show that use of micro$oft causes cancer in lab animals - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
/proc/(pid)/mem status and future, or alternatives?
Hi, I had noticed that the mmapping facilities of /proc/(pid)/mem have been removed in recent devel kernels as well as in the 2.4 test series. I assume that since it is missing in the test series, that it is to be missing in 2.4.0 final as well. I poked around on the list archives and found mention of its demise, but couldn't find any indication as to if it was a permanent removal or if it was just temporary while issues were sorted out, or to alternatives to use for the same functionality. Is there another way to get access to another process's memory space in bulk? I need to do a full search on an arbitrary process's memory space. I've been using ptrace(PTRACE_PEEKDATA, ..) in the absense of the ability to mmap the process's memory but doing so takes a few million system calls per search which is prohibitively expensive. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
On Fri, Oct 27, 2000 at 12:02:20PM +0200, Martin Mares wrote: > > So this is not our problem here. Anyway I guess it's time to hunt for > > i8259 accesses in the kernel that lack the necessary spinlock, even when > > they're not probably the cause of the problem we see here. > > BTW what about trying to modify your work-around code to make it > attempt to read the timer again? This way we could test whether it was > a race condition during timer read or really timer jumping to a bogus > value. Actually if I don't reprogram the timer (and just ignore the value for example), the work-around code keeps being called again and again very often (between 1x/minute to 100x/second) after the first failure, even when the system is idle. When reprogramming, next failure happens only after stressing the system again. So it's not just a race, the impact of the failure on the chip is permanent and stays till it's reprogrammed. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
Vojtech Pavlik <[EMAIL PROTECTED]> writes: > On Fri, Oct 27, 2000 at 12:02:20PM +0200, Martin Mares wrote: > > > > So this is not our problem here. Anyway I guess it's time to hunt for > > > i8259 accesses in the kernel that lack the necessary spinlock, even when > > > they're not probably the cause of the problem we see here. > > > > BTW what about trying to modify your work-around code to make it > > attempt to read the timer again? This way we could test whether it was > > a race condition during timer read or really timer jumping to a bogus > > value. > > Actually if I don't reprogram the timer (and just ignore the value for > example), the work-around code keeps being called again and again very > often (between 1x/minute to 100x/second) after the first failure, even > when the system is idle. > > When reprogramming, next failure happens only after stressing the system > again. > > So it's not just a race, the impact of the failure on the chip is > permanent and stays till it's reprogrammed. Are you sure there is not an error in the way the chipset is programmed ? -- -- Yoann http://www.mandrakesoft.com/~yoann/ "Programming is a race between programmers, who try and make more and more idiot-proof software, and universe, which produces more and more remarkable idiots. Until now, universe leads the race" -- R. Cook - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0test5 make dep errors
hi, for information some error/warnings (?): config.c:311: #error "HiSax: No cards configured" su.c:75: asm/oplib.h: No such file or directory su.c:77: asm/ebus.h: No such file or directory newport.c:11: asm/gfx.h: No such file or directory newport.c:12: asm/ng1.h: No such file or directory tcsyms.c:7: asm/dec/tc.h: No such file or directory zorro.c:20: asm/amigahw.h: No such file or directory /usr/src/linux/Rules.make:145: target `_subdir_sched' given more than once in the same rule. /usr/src/linux/Rules.make:145: target `_subdir_sched' given more than once in the same rule. /usr/src/linux/Rules.make:145: target `_subdir_sched' given more than once in the same rule. /usr/src/linux/Rules.make:145: target `_subdir_sched' given more than once in the same rule. with .config: (attached) -- In God we Trust, all others please submit signed PGP/X.509 key Markus Hennig <[EMAIL PROTECTED]> | Product Development Astaro AG | http://www.astaro.de | +49-721-490069-0 | Fax -55 # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_M686FXSR is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set # CONFIG_PM is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set # CONFIG_PARPORT_1284 is not set # # Plug and Play configuration # CONFIG_PNP=m CONFIG_ISAPNP=m # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=8192 # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # CONFIG_LVM_PROC_FS is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=m CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set CONFIG_SYN_COOKIES=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_UNCLEAN=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_MIRROR=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_MARK=m # CONFIG_IP_NF_TARGET_LOG is not set # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set # CONFIG_IPV6 is not set CONFIG_KHTTPD=m
Re: Possible critical VIA vt82c686a chip bug (private question)
On Fri, Oct 27, 2000 at 12:58:12PM +0200, Yoann Vandoorselaere wrote: > > > > So this is not our problem here. Anyway I guess it's time to hunt for > > > > i8259 accesses in the kernel that lack the necessary spinlock, even when > > > > they're not probably the cause of the problem we see here. > > > > > > BTW what about trying to modify your work-around code to make it > > > attempt to read the timer again? This way we could test whether it was > > > a race condition during timer read or really timer jumping to a bogus > > > value. > > > > Actually if I don't reprogram the timer (and just ignore the value for > > example), the work-around code keeps being called again and again very > > often (between 1x/minute to 100x/second) after the first failure, even > > when the system is idle. > > > > When reprogramming, next failure happens only after stressing the system > > again. > > > > So it's not just a race, the impact of the failure on the chip is > > permanent and stays till it's reprogrammed. > > Are you sure there is not an error in the way the > chipset is programmed ? Which part of the chipset you mean? The PIT (programmable interrupt timer)? That one is standard since XT times. The rest of the ISA bridge? Maybe, but that's mostly BIOS work and shouldn't impact the PIT under sane conditions. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
New VM problem
Hello all, I am running a 2.4.0-test9 kernel and I have noticed a VM problem I have not seen reported before. The machine is a uniprocessor Pentium II with 2G of ram, and the kernel is compiled with CONFIG_HIGHMEM4G and CONFIG_HIGHMEM both set to y. I also have 512M of swap on the machine. I left a single large job running when I left yesterday afternoon (size=1651M, RSS=1.5G). When I got in this morning I wanted to see if it was still running so I typed "top" in an Xterm. When I hit return I thought the machine had crashed. I could not move the cursor with the mouse, or cause any other activity. I went and got a cup of coffe and when I came back the machine was alive again. I then started netscape and the machine appeared to crash again. It was completly unresponsive for about 30 seconds and then it came back to life. As I type this message into netscape, the machine will periodically freeze for about 30 seconds and then come back to life. Anybody have any idea of whats going on? On an unrelated note, is it possible for a process in 2.4 to see more than 2G of address space? They seem to be limited to 2G for me. I was hoping that the HIMEM stuff had removed that limit. Thanks, Jim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
Vojtech Pavlik <[EMAIL PROTECTED]> writes: > On Fri, Oct 27, 2000 at 12:58:12PM +0200, Yoann Vandoorselaere wrote: > > > > > > So this is not our problem here. Anyway I guess it's time to hunt for > > > > > i8259 accesses in the kernel that lack the necessary spinlock, even when > > > > > they're not probably the cause of the problem we see here. > > > > > > > > BTW what about trying to modify your work-around code to make it > > > > attempt to read the timer again? This way we could test whether it was > > > > a race condition during timer read or really timer jumping to a bogus > > > > value. > > > > > > Actually if I don't reprogram the timer (and just ignore the value for > > > example), the work-around code keeps being called again and again very > > > often (between 1x/minute to 100x/second) after the first failure, even > > > when the system is idle. > > > > > > When reprogramming, next failure happens only after stressing the system > > > again. > > > > > > So it's not just a race, the impact of the failure on the chip is > > > permanent and stays till it's reprogrammed. > > > > Are you sure there is not an error in the way the > > chipset is programmed ? > > Which part of the chipset you mean? The PIT (programmable interrupt > timer)? That one is standard since XT times. The rest of the ISA bridge? > Maybe, but that's mostly BIOS work and shouldn't impact the PIT > under sane conditions. What is strange is that a number of persons seem to be hit by this problem... And if VIA didn't corrected it it's probably because they are not aware of it... I think that if such problem occured under windows (thinking to the windows user base), VIA would be already in touch. -- -- Yoann http://www.mandrakesoft.com/~yoann/ Tiniest "mesures unities?" - lenght : millimeter - volume : milliliter - intelligence : military man - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux 2.2.18pre17 + VM-global -7 = `Negative d_count' oops
Andrea Arcangeli writes ("Re: linux 2.2.18pre17 + VM-global -7 = `Negative d_count'
oops"):
> On Thu, Oct 26, 2000 at 06:37:37PM +0100, Ian Jackson wrote:
> > Negative d_count (-805538369) for [binary garbage]/
> >
> > followed by an oops. Kernel logfile extract below, uuencoded.
>
> Thanks for the feedback.
>
> The oops is forced by the kernel after it sees then wrong negative d_count.
>
> I'd say it's memory corruption, but it doesn't look like a memory bitflip.
>
> I'm almost certain that it's not caused by the VM-global patch.
>
> Which device driver and compiler are you using?
chiark:~> gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
gcc version 2.95.2 2220 (Debian GNU/Linux)
chiark:~> dpkg -l gcc
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:uppercase=bad)
||/ Name VersionDescription
+++-==-==-
ii gcc2.95.2-13 The GNU C compiler.
chiark:~>
I've enclosed a copy of `.config' from the 2.2.18pre17+VM-global.
I forgot to mention, and it might be relevant (given that the oops is
in `hung_up_tty_read'), that I'm using a VPN system of my own devising
which gets packets in and out of the kernel by using `slattach' on
pty's; it has no nonstandard kernel component, but probably has some
unusual pty handling behaviour. If you really want to look at what it
does, the source is on ftp.chiark.greenend.org.uk in ipif/service.c
inside /users/ian/userv/userv-utils-0.2.0.tar.gz.
Ian.
#
# Automatically generated by make menuconfig: don't edit
#
#
# Code maturity level options
#
# CONFIG_EXPERIMENTAL is not set
#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
CONFIG_M586TSC=y
# CONFIG_M686 is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_TSC=y
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_1GB=y
# CONFIG_2GB is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
# CONFIG_SMP is not set
#
# Loadable module support
#
# CONFIG_MODULES is not set
#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_QUIRKS=y
CONFIG_PCI_OLD_PROC=y
# CONFIG_MCA is not set
# CONFIG_VISWS is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_PARPORT is not set
# CONFIG_APM is not set
# CONFIG_TOSHIBA is not set
#
# Plug and Play support
#
# CONFIG_PNP is not set
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_IDE is not set
# CONFIG_BLK_DEV_HD_ONLY is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_MD=y
# CONFIG_MD_LINEAR is not set
CONFIG_MD_STRIPED=y
# CONFIG_MD_MIRRORING is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_MD_BOOT is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_PARIDE_PARPORT=y
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_HD is not set
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK_DEV=y
CONFIG_FIREWALL=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_TOS is not set
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_ROUTE_LARGE_TABLES is not set
# CONFIG_IP_PNP is not set
CONFIG_IP_FIREWALL=y
CONFIG_IP_FIREWALL_NETLINK=y
CONFIG_NETLINK_DEV=y
# CONFIG_IP_TRANSPARENT_PROXY is not set
# CONFIG_IP_MASQUERADE is not set
# CONFIG_IP_ROUTER is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
CONFIG_IP_ALIAS=y
CONFIG_SYN_COOKIES=y
# CONFIG_INET_RARP is not set
CONFIG_SKB_LARGE=y
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
# CONFIG_PHONE_IXJ is not set
#
# SCSI support
#
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
#
# SCSI low-level drivers
#
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AHA1740 is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_MEGARAID is
Re: Possible critical VIA vt82c686a chip bug (private question)
On Fri, Oct 27, 2000 at 01:16:34PM +0200, Yoann Vandoorselaere wrote: > > Which part of the chipset you mean? The PIT (programmable interrupt > > timer)? That one is standard since XT times. The rest of the ISA bridge? > > Maybe, but that's mostly BIOS work and shouldn't impact the PIT > > under sane conditions. > > What is strange is that a number of persons seem to be hit by this > problem... And if VIA didn't corrected it it's probably because > they are not aware of it... > > I think that if such problem occured under windows > (thinking to the windows user base), VIA would be already in touch. It can't happen under Windows, because Windows timer runs at 18 Hz (timer programmed to 65535), while Linux uses 100 Hz (timer programmed to approx 11920), so when the timer unprograms itself due to the bug to 65535, only Linux notices it, Windows can't. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PROPOSED PATCH] ATM refcount + firestream
Patrick van de Lageweg wrote:
>
> Hi all,
>
> Here is the second try for the atm refcount problem. I've made made
> several enhancement over the previos patch. Can you take a look at it if
> I've missed anything? (This time it also includes the driver for the
> firestream card. That's why the patch is so large. It's gziped and
> uuencoded).
Patrick, I looked at the modules stuff and you do not
appear to be actually _using_ it anywhere:
bix:/home/morton> grep owner patch
+ owner: THIS_MODULE,
+ owner: THIS_MODULE
+ owner: THIS_MODULE,
+ owner:THIS_MODULE,
+ owner: THIS_MODULE,
+ owner: THIS_MODULE,
+ owner: THIS_MODULE,
+ struct module *owner;
+ struct module *owner;
bix:/home/morton>
It looks like you'll need something like the following:
(warning: uncompiled ATM-ignoramus code)
Index: net/atm/common.c
===
RCS file: /opt/cvs/lk/net/atm/common.c,v
retrieving revision 1.3.2.1
diff -u -u -r1.3.2.1 common.c
--- net/atm/common.c2000/07/08 06:26:43 1.3.2.1
+++ net/atm/common.c2000/10/27 11:17:45
@@ -144,6 +144,8 @@
"rx_inuse == %d after closing\n",
atomic_read(&vcc->rx_inuse));
+ if (vcc->dev->ops->owner)
+ __MOD_DEC_USE_COUNT(vcc->dev->ops->owner);
bind_vcc(vcc,NULL);
}
if (free_sk) free_atm_vcc_sk(sk);
}
@@ -199,13 +201,22 @@
{
int error;
+ if (try_inc_mod_count(dev->ops->owner) == 0) {
+ return -ENODEV;
+ }
+
+ error = 0;
+
if ((vpi != ATM_VPI_UNSPEC && vpi != ATM_VPI_ANY &&
vpi >> dev->ci_range.vpi_bits) || (vci != ATM_VCI_UNSPEC &&
- vci != ATM_VCI_ANY && vci >> dev->ci_range.vci_bits))
- return -EINVAL;
- if (vci > 0 && vci < ATM_NOT_RSV_VCI && !capable(CAP_NET_BIND_SERVICE))
- return -EPERM;
- error = 0;
+ vci != ATM_VCI_ANY && vci >> dev->ci_range.vci_bits)) {
+ error = -EINVAL;
+ goto out;
+ }
+ if (vci > 0 && vci < ATM_NOT_RSV_VCI && !capable(CAP_NET_BIND_SERVICE)) {
+ error = -EPERM;
+ goto out;
+ }
bind_vcc(vcc,dev);
switch (vcc->qos.aal) {
case ATM_AAL0:
@@ -231,19 +242,26 @@
if (!error) error = adjust_tp(&vcc->qos.rxtp,vcc->qos.aal);
if (error) {
bind_vcc(vcc,NULL);
- return error;
+ goto out;
}
DPRINTK("VCC %d.%d, AAL %d\n",vpi,vci,vcc->qos.aal);
DPRINTK(" TX: %d, PCR %d..%d, SDU %d\n",vcc->qos.txtp.traffic_class,
vcc->qos.txtp.min_pcr,vcc->qos.txtp.max_pcr,vcc->qos.txtp.max_sdu);
DPRINTK(" RX: %d, PCR %d..%d, SDU %d\n",vcc->qos.rxtp.traffic_class,
vcc->qos.rxtp.min_pcr,vcc->qos.rxtp.max_pcr,vcc->qos.rxtp.max_sdu);
+
if (dev->ops->open) {
error = dev->ops->open(vcc,vpi,vci);
if (error) {
bind_vcc(vcc,NULL);
- return error;
+ goto out;
}
+ }
+
+out:
+ if (error) {
+ if (dev->ops->owner)
+ __MOD_DEC_USE_COUNT(dev->ops->owner);
}
return 0;
}
Something similar will be need to be wrapped around the usage of
`struct atm_tcp_ops()' as well. Let me know if you'd like me to
prototype a patch for that.
The other thing you need to watch out for is atmdev_ops.ioctl().
Can this be called when the device is not open?
In other words, can atmdev_ops.ioctl() be called prior to
atmdev_ops.open()? In more other words, can ioctl() be
called after close()?
If so then the above patch is not sufficient - it only increments
the module use count on the open() path.
If this is the case then you're fairly severely screwed. This is
because the atm_dev handling has the same design flaw as the
netdevice handling: the logical place to inc/dec the module
refcount is within atm_dev_[de]register(). But this doesn't
work because you can never _get_ to the deregister point
through sys_delete_module() to drop the refcount.
Like netdevices, ATM needs to be able to separate the act
of loading the module from the act of registering the driver.
netdevices manage to get away with it because of ANK's funky
dev_hold()/dev_put() refcounting. It looks like ATM devices
aren't that lucky.
One workaround would be to refuse to allow the device to be
accessed at all if it isn't open. This may be unacceptable.
Look, this modules stuff is really bad. Phillip Rumpf proposed
a radical alternative a while back which I felt was not given
sufficient consideration. The idea was to make sys_delete_module()
grab all the other CPUs and leave them spinning on a flag while
the unload was proceeding. This was very simila
Re: NFS, Can't get request slot
> By the evidence that we have gathered it seems that the Server is not > taxed too much as samba users are getting files OK etc. The can't get > request slot is plaguing many others in different ways. It looks like > an NFS issue. How can this be proven? Then we can work on the > problem. The request queue slot message means the server isnt responding (at least in the eyes of the client). Given you can get into the box that isnt the net card (at least not now). What mount options do you use ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: missing mxcsr initialization
> Go back. Read ym email. Realize that you do this ONCE. At setup time.
(I've got about 2000 to read after this jaunt so I may have missed some)
> You can even split SEP into SEPOLD and SEPNEW, and _always_ just test one
> bit. You should not have to test stepping levels in normal use: that
> invariably causes problems when there are more than one CPU that has some
> feature.
Agree
> if (vendor == intel && stepping < 5) {
> ...
> }
>
> and it appears to work again, until it turns out that Cyrix has the same
> issue, and then it ends up being the test from hell, where different
> vendor tests all clash, and it gets increasingly difficult to add a new
> thing later on sanely.
And you end up with mtrr.c
> No thank you. We'll just require fixed feature flags. Which can be turned
> on as the features are enabled.
That seems sensible
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
On 26 Oct, Vojtech Pavlik wrote: > On Thu, Oct 26, 2000 at 04:42:31PM +0200, Yoann Vandoorselaere wrote: > >> > On Thu, Oct 26, 2000 at 04:20:43PM +0200, Yoann Vandoorselaere wrote: >> > >> > > ... >> > > >> > > Have you any idea what is the relation between time and this chip ? >> > > >> > > Also, I'm experiencing the problem for several month on my >> > > workstation and I never could find where it was comming from... >> > > how did you do ? >> > >> > Well, it integrates both the i8253 PIT and the vt82c586 IDE controller. >> > >> > I first located the wrong time was coming from gettimeofday() and not >> > from the other sources of time the kernel provides. And then I was >> > tracking the problem (which actually is an underflow - the chip bug >> > causes some time offset variables go negative - 0x microseconds >> > is about 1:20 hours). And this way I got to the spot where the patch >> > cures the problem. >> >> Ok, here is what I experienced : >> >> First what is strange is that : >> - I'm using SCSI >> - I just have an IDE disk for mp3. >> The IDE subsystem is never used heavilly... >> >> I've experienced the problem after some time of >> heavy scsi IO, my screen under X was going black (like with dpms) >> When I was moving the mouse, the image was coming back >> for < 1 seconds, then black screen... >> >> The only fix was to kill X then to reboot. >> >> Anyway, thanks for your explaination... >> I'll do a feedback for this patch ASAP. > > Interesting. If it's caused by SCSI as well (might be), then it's not > caused by heavy IDE activity but rather than that it could be heavy > BusMastering activity instead (The IDE chip does BM as well). > > I'm still wondering if it could be a Linux kernel bug (bad/concurrent > accesses to the i8253 registers), this has to be checked. > How sure are you that the chip is actually buggy? I ran into something similar a while ago, when I mixed the two arguments to an outb in a driver, and ended up writing MYPORT into the timer instead of 0x40 into MYPORT. Bart -- Bart Hartgers - TUE Eindhoven Get my GPG key at http://etpmod.phys.tue.nl/bart/pubkey.gpg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Off-Topic (or maybe on-topic)
Reports are that Microsoft has been broken into. Although Microsoft spokesmen deny it, reports are that the source- code for Windows/2000 (professional) has been copied to a country in the former Soviet Union. I thought that this stuff had already been "released", but nobody wanted it because they couldn't read it. Cheers, Dick Johnson Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Off-Topic (or maybe on-topic)
On Fri, 27 Oct 2000, Richard B. Johnson wrote: > > Reports are that Microsoft has been broken into. Although > Microsoft spokesmen deny it, reports are that the source- > code for Windows/2000 (professional) has been copied to > a country in the former Soviet Union. > > I thought that this stuff had already been "released", but > nobody wanted it because they couldn't read it. > Yes, true. http://news.bbc.co.uk/hi/english/business/newsid_993000/993933.stm I hope nobody will buy Microsoft products from now on, now that they are not only filled with internal bugs but also with external ones introduced by the guys from Leningrad... :) But it is probably Microsoft's own original way of "releasing source under GPL". Maybe they don't have the guts to admit that the proprietary software model (in OS market, where Linux dominateth!) is a failure so they make it look like some script-kiddie posted their source listings on the Usenet (or wherever he is going to post them?) and so they "have no choice but to release windoz under GPL" :) Regards, Tigran PS. Leningrad is the old historical name of the modern St. Petersberg but we "old-timers" do still call it Leningrad, it seems more appropriate than all those "modern" name-changes... ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Off-Topic (or maybe on-topic)
On Fri, Oct 27, 2000 at 01:48:35PM +0100, Tigran Aivazian wrote: > On Fri, 27 Oct 2000, Richard B. Johnson wrote: > > > > > Reports are that Microsoft has been broken into. Although > > Microsoft spokesmen deny it, reports are that the source- > > code for Windows/2000 (professional) has been copied to > > a country in the former Soviet Union. > > > > I thought that this stuff had already been "released", but > > nobody wanted it because they couldn't read it. > > > > Yes, true. > > http://news.bbc.co.uk/hi/english/business/newsid_993000/993933.stm > > I hope nobody will buy Microsoft products from now on, now that they are > not only filled with internal bugs but also with external ones introduced > by the guys from Leningrad... :) > > But it is probably Microsoft's own original way of "releasing source under > GPL". Maybe they don't have the guts to admit that the proprietary > software model (in OS market, where Linux dominateth!) is a failure so > they make it look like some script-kiddie posted their source listings on > the Usenet (or wherever he is going to post them?) and so they "have no > choice but to release windoz under GPL" :) > > Regards, > Tigran > > PS. Leningrad is the old historical name of the modern St. Petersberg but > we "old-timers" do still call it Leningrad, it seems more appropriate than > all those "modern" name-changes... ;) You're VERY wrong here. St. Petersburg was the name before the Soviet Union was formed and Russia marched into the Baltics. When the takeover was made, the city was renamed Leningrad (after V.I. Lenin). When the Soviet Union finally fell to pieces and the Baltics retained their freedom, St. Petersburg retained its old name, which it got (if I'm not all wrong) from Peter the Great. /David _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
Re: Off-Topic (or maybe on-topic)
On Fri, 27 Oct 2000, David Weinehall wrote: > > PS. Leningrad is the old historical name of the modern St. Petersberg but > > we "old-timers" do still call it Leningrad, it seems more appropriate than > > all those "modern" name-changes... ;) > > You're VERY wrong here. St. Petersburg was the name before the Soviet > Union was formed and Russia marched into the Baltics. When the takeover > was made, the city was renamed Leningrad (after V.I. Lenin). When the > Soviet Union finally fell to pieces and the Baltics retained their freedom, > St. Petersburg retained its old name, which it got (if I'm not all wrong) > from Peter the Great. Hi David! I should have put a smiley there shouldn't I? :) Don't you think I must be well aware of the origins of names of former soviet cities if I spent 20 (or almost 21) years of life there Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS flags all files executable on NetWare Volumes wit
On 27 Oct 00 at 0:16, Jeff V. Merkey wrote:
> I noticed NCPFS is flagging all the files on a native NetWare volume as
> executable and chmod -x does not work, even if the NetWare server has
> the NFS namespace loaded. I looked at you code in more detail, and I
> did not see support their for the NFS/Unix namespace.
> Is this in a newer version, or has it not been implemented yet? I was
> testing with MARS and Native NetWare this evening and saw this. If the
> NFS namespace is loaded, you should be able to get to it and access and
> set all these bits in the file system namespace directory records.
>
> Do you need any info from me to get this working, or is there another
> version where I can get this for Ute-Linux?
Hi Jeff,
ncpfs does not support NFS fields, as access through namespace functions
is hopelessly broken (modify ns specific info has swapped some bits
in mask which data update and which not), and it also adds some (100%)
overhead on directory/inode lookups, as you must ask twice - first for
non-NFS info, and second for NFS specific...
There exists patch from Ben Harris <[EMAIL PROTECTED]>, which adds
this feature to 2.2.16 kernel and 2.2.0.17 ncpfs. You can download
it from ftp://platan.vc.cvut.cz/pub/linux/ncpfs/ncp{1,2}.pat. ncp1.pat
is kernel patch (including email headers; cut them if applying), ncp2.pat
is patch for 2.2.0.17 ncpfs userspace - it adds mount option "nfsextras".
(I apologize to Ben - I promised to integrate it into ncpfs, and into
2.4 kernel, but...)
Except that, you can make all files non-executable by using
"filemode=0644" mount option. Or you can use "extras,symlinks", in which
case (NFS namespace incompatible) hidden/shareable/transactional attributes
are used to signal executability of file...
If you have some document which describes what each NFS specific field
does - currently ncpfs names them "name", "mode", "gid", "nlinks", "rdev",
"link", "created", "uid", "acsflag" and "myflag" - if I remember correctly,
it is how Unixware 2.0 nuc.h names them. And I did not found any information
about layout of NFS huge info, which is used for hardlinks :-(
Also, as NCP 87,8 kills almost every NW server I know, if used namespace
is NFS, I'm a bit sceptic about usability of NCP 87,* on NFS namespace.
In 1998 and 1999 I tried to ask Novell for documentation of NCP 95,*
(Netware Unix Client), but it was refused and ignored, so... here we are.
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
P.S.: Jeff, if you want, there is ncpfs/MaRS/LinWare specific list,
[EMAIL PROTECTED] Subscribe: "subscribe linware" to "[EMAIL PROTECTED]".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Off-Topic (or maybe on-topic)
On Fri, 27 Oct 2000, Tigran Aivazian wrote: > I should have put a smiley there shouldn't I? :) Don't you think I must be > well aware of the origins of names of former soviet cities if I spent 20 > (or almost 21) years of life there actually, the final and ultimate authority on whether "old-timers" call Piter "Leningrad" or "St. Petersburg" belongs to Al Viro - he knows why. He can settle the dispute Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Off-Topic (or maybe on-topic)
David Weinehall wrote: > > You're VERY wrong here. St. Petersburg was the name before the Soviet > Union was formed and Russia marched into the Baltics. When the takeover > was made, the city was renamed Leningrad (after V.I. Lenin). When the > Soviet Union finally fell to pieces and the Baltics retained their freedom, > St. Petersburg retained its old name, which it got (if I'm not all wrong) > from Peter the Great. AFAIK Tigran is born in the Soviet Union and i thing he knows the history of his own country better ;-) Anyway, i am bulgarian and i also am used to call St. Petersburg Leningrad ;-)) best, Petkan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + LFS
On 26 Oct 00 at 23:15, [EMAIL PROTECTED] wrote: > On Thu, 26 Oct 2000, Wakko Warner wrote: > > doing an ls -l shows: > > ls: x: Value too large for defined data type > > > > NOTE: this worked in 2.4.0-test6 and I believe it stopped working around > > test8, but I'm not sure. May have been around test7. > > Previous kernels allowed up to 4gb to be returned by the old stat. > Upgrade your glibc and fileutils -- most recent distributions (Red Hat, > SuSE, ...) are LFS ready, and the only reports I've seen about this > concerned Slackware. And Debian :-( It is hard to get rid of such file - GNU 'rm' complains too, as it tries to stat that file first :-( Fortunately echo -n > x; rm x works. I filled bugreport some time ago (when 2.1.94 come to woody), but it was closed, as there are no 2.4.x headers in Debian, so it is not possible to recompile glibc against them... Recompiling glibc is enough for woody, BTW. Best regards, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Quota fixes and a few questions
Hi, On Fri, Oct 27, 2000 at 11:31:59AM +0200, Juri Haberland wrote: > > > Hi Stephen, > > unfortunately 0.0.3b has the same problem. I tried it with a stock > 2.2.17 kernel + NFS patches + ext3-0.0.3b and the quota rpm you > included. Extracting two larger tar.gz files hits the deadlock reliably. OK, will try to replicate. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Off-Topic (or maybe on-topic)
On 27 Oct, Tigran Aivazian wrote: [snip] > http://news.bbc.co.uk/hi/english/business/newsid_993000/993933.stm > > I hope nobody will buy Microsoft products from now on, now that they are > not only filled with internal bugs but also with external ones introduced > by the guys from Leningrad... :) > > But it is probably Microsoft's own original way of "releasing source under > GPL". Maybe they don't have the guts to admit that the proprietary > software model (in OS market, where Linux dominateth!) is a failure so > they make it look like some script-kiddie posted their source listings on > the Usenet (or wherever he is going to post them?) and so they "have no > choice but to release windoz under GPL" :) > > Regards, > Tigran > [snip] It makes you wonder... Having been a /real/ breakin, I would have thought MS would have hushed any kind of press release. The other side may be that the culprit tried to blackmail MS after the fact. If Bill said 'screw you' to the blackmailer and made the press release, we should see the source on web sites soon. Then we can see how bad it really is. Maybe even fix it. -- Dave I come from the net I search through systems, people, and cities to find this place... mainframe, my home. My format: Guardian, to mend and defend. Reboot! --- Dave Helton, KD0YU- [EMAIL PROTECTED] - http://www.kd0yu.com Real World Computing - 319-386-4041 - 8am-5pm CST Linux/Novell/NT | Servers/Workstations | Consulting | Internet Technologies --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Off-Topic (or maybe on-topic)
On Fri, Oct 27, 2000 at 04:05:50PM +0300, Petko Manolov wrote: > David Weinehall wrote: > > > > You're VERY wrong here. St. Petersburg was the name before the Soviet > > Union was formed and Russia marched into the Baltics. When the takeover > > was made, the city was renamed Leningrad (after V.I. Lenin). When the > > Soviet Union finally fell to pieces and the Baltics retained their freedom, > > St. Petersburg retained its old name, which it got (if I'm not all wrong) > > from Peter the Great. > > > AFAIK Tigran is born in the Soviet Union and i thing he knows > the history of his own country better ;-) Uhmmm. You known, being born in the Soviet Union (not a country in its strictest sense), doesn't necessarily mean you know its history. And considering that the span of the SSSR was quite enormous... Anyhow: The city was originally called Nyen and was formed by Swedes. 1703, Peter the Great invaded the city, and 1712 the city became the capital of Russia, named St. Petersburg. The name remained St. Petersburg until 1914, when it was renamed Petrograd. 1918, Moscow was made the capital of Russia, and 1924 the city got renamed again, this time to Leningrad. > Anyway, i am bulgarian and i also am used to call St. Petersburg > Leningrad ;-)) Well, it's time for me, as a Swede, to begin calling it Nyen?! Oh, let's end this silly debate. I'm getting sorry I even brought it up. /David _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
mousedev uses userspace pointers without copy_{to,from}_user
static ssize_t mousedev_write(struct file * file, const char * buffer, size_t count,
loff_t *ppos)
{
struct mousedev_list *list = file->private_data;
unsigned char c;
int i;
for (i = 0; i < count; i++) {
c = buffer[i];
oops. Can we make this die horribly on x86, just for a few kernel releases?
Along with turning on spinlock debugging, which would have shown up the USB
audio problem months ago.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Off-Topic (or maybe on-topic)
On Fri, 27 Oct 2000, David Weinehall wrote: > and 1924 the city got renamed again, this time to Leningrad. ok, then a quiz question - was it renamed before or after Lenin's death? (hint, Lenin died in 1924). Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM-global-2.2.18pre17-7
On Fri, 27 Oct 2000, Neale Banks wrote: > On Thu, 26 Oct 2000, octave klaba wrote: > > > > > Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources. > > > let me guess: intel eepro100 or similar?? > > yeap > > er, "me too": > > Bus 0, device 2, function 0: > Ethernet controller: Intel 82557 (rev 8). > Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. >Latency=64. Min Gnt=8.Max Lat=56. > Non-prefetchable 32 bit memory at 0xb5fff000 [0xb5fff000]. > I/O at 0x2400 [0x2401]. > Non-prefetchable 32 bit memory at 0xb5e0 [0xb5e0]. > > On Debian's 2.2.17-compact on a Compaq DL380 - with 60 days uptime I have > 6 "eth0: card reports no resources." messages reported in dmesg. We are having the same problem with eepro100 on a Compaq DL360. v1.11 of eepro100.c fixed the problem: ftp://ftp.scyld.com/pub/network/eepro100.c - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] generic_serial's block_til_ready (fwd)
Hi Linus,
This patch renames the block_til_ready of generic serial to
gs_block_til_ready. This patch also exports the symbols needed by other
modules with generic_serial compiled into the kernel.
(it also helps when other modules have a "static block_til_ready"
defined. This IMHO is a bug in the module-utils, but I'm told it
cannot be fixed becuase of backwards compatibility Grrr. -- REW)
Patrick
diff -u -r linux-2.4.0-test10-pre6.clean/drivers/char/generic_serial.c
linux-2.4.0-test10-pre6.block_til_ready/drivers/char/generic_serial.c
--- linux-2.4.0-test10-pre6.clean/drivers/char/generic_serial.c Fri Oct 27 12:57:09
2000
+++ linux-2.4.0-test10-pre6.block_til_ready/drivers/char/generic_serial.c Fri
+Oct 27 14:36:44 2000
@@ -61,6 +61,23 @@
MODULE_PARM(gs_debug, "i");
#endif
+EXPORT_SYMBOL(gs_set_termios);
+EXPORT_SYMBOL(gs_chars_in_buffer);
+EXPORT_SYMBOL(gs_write);
+EXPORT_SYMBOL(gs_close);
+EXPORT_SYMBOL(gs_put_char);
+EXPORT_SYMBOL(gs_flush_chars);
+EXPORT_SYMBOL(gs_debug);
+EXPORT_SYMBOL(gs_hangup);
+EXPORT_SYMBOL(gs_stop);
+EXPORT_SYMBOL(gs_flush_buffer);
+EXPORT_SYMBOL(gs_init_port);
+EXPORT_SYMBOL(gs_write_room);
+EXPORT_SYMBOL(gs_start);
+EXPORT_SYMBOL(gs_setserial);
+EXPORT_SYMBOL(gs_getserial);
+EXPORT_SYMBOL(gs_block_til_ready);
+
#ifdef DEBUG
static void my_hd (unsigned char *addr, int len)
{
@@ -606,7 +623,7 @@
}
-int block_til_ready(void *port_, struct file * filp)
+int gs_block_til_ready(void *port_, struct file * filp)
{
struct gs_port *port = port_;
DECLARE_WAITQUEUE(wait, current);
@@ -623,7 +640,7 @@
if (!tty) return 0;
- gs_dprintk (GS_DEBUG_BTR, "Entering block_till_ready.\n");
+ gs_dprintk (GS_DEBUG_BTR, "Entering gs_block_till_ready.\n");
/*
* If the device is in the middle of being closed, then block
* until it's done, and then try again.
diff -u -r linux-2.4.0-test10-pre6.clean/drivers/char/sh-sci.c
linux-2.4.0-test10-pre6.block_til_ready/drivers/char/sh-sci.c
--- linux-2.4.0-test10-pre6.clean/drivers/char/sh-sci.c Fri Oct 27 12:57:13 2000
+++ linux-2.4.0-test10-pre6.block_til_ready/drivers/char/sh-sci.c Fri Oct 27
+14:42:19 2000
@@ -839,7 +839,7 @@
MOD_INC_USE_COUNT;
}
- retval = block_til_ready(port, filp);
+ retval = gs_block_til_ready(port, filp);
if (retval) {
MOD_DEC_USE_COUNT;
diff -u -r linux-2.4.0-test10-pre6.clean/drivers/char/sx.c
linux-2.4.0-test10-pre6.block_til_ready/drivers/char/sx.c
--- linux-2.4.0-test10-pre6.clean/drivers/char/sx.c Fri Oct 27 12:57:14 2000
+++ linux-2.4.0-test10-pre6.block_til_ready/drivers/char/sx.c Fri Oct 27 14:38:46
+2000
@@ -1478,7 +1478,7 @@
return -EIO;
}
- retval = block_til_ready(port, filp);
+ retval = gs_block_til_ready(port, filp);
sx_dprintk (SX_DEBUG_OPEN, "Block til ready returned %d. Count=%d\n",
retval, port->gs.count);
diff -u -r linux-2.4.0-test10-pre6.clean/include/linux/generic_serial.h
linux-2.4.0-test10-pre6.block_til_ready/include/linux/generic_serial.h
--- linux-2.4.0-test10-pre6.clean/include/linux/generic_serial.hMon Mar 13
04:18:55 2000
+++ linux-2.4.0-test10-pre6.block_til_ready/include/linux/generic_serial.h Fri
+Oct 27 14:10:49 2000
@@ -92,7 +92,7 @@
void gs_start(struct tty_struct *tty);
void gs_hangup(struct tty_struct *tty);
void gs_do_softint(void *private_);
-int block_til_ready(void *port, struct file *filp);
+int gs_block_til_ready(void *port, struct file *filp);
void gs_close(struct tty_struct *tty, struct file *filp);
void gs_set_termios (struct tty_struct * tty,
struct termios * old_termios);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make agpsupport work with modversions
[EMAIL PROTECTED] said: > > But that module then depends on both of the others unless you keep > > recompiling it > Not really, see for example ns558.c and adi.c plus their third module > gameport.c, all in drivers/char/joystick. But in the case where there _aren't_ any functions which could usefully be shared between the modules, you've got a whole extra gratuitous module (What's that, 32KiB on some ARM boxen?) just to hold the registration functions, which aren't needed if you just use get_module_symbol(). Provide generic code for registering such stuff and it might be acceptable. Otherwise, get_module_symbol is better. There's no fundamental flaw with get_module_symbol() - just one or two of the current usages of it. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: LVM snapshotting broken?
On Fri, 27 Oct 2000, Andrea Arcangeli wrote: > For some irrelevant reason I always test snapshotting on a LV with minor > number > 1 and the kernel side definitely works with 2.2.18pre17aa1: > > laser:/home/andrea # ls -l /dev/vg1/lv* > brw-r- 1 root root 58, 0 Oct 27 2000 /dev/vg1/lv0 > brw-r- 1 root root 58, 1 Oct 27 2000 /dev/vg1/lv1 > laser:/home/andrea # lvcreate -s -n lv1-snap /dev/vg1/lv1 -L 400M > lvcreate -- INFO: using default snapshot chunk size of 64 KB > lvcreate -- doing automatic backup of "vg1" > lvcreate -- logical volume "/dev/vg1/lv1-snap" successfully created > > laser:/home/andrea # lvremove -f /dev/vg1/lv1-snap > lvremove -- doing automatic backup of volume group "vg1" > lvremove -- logical volume "/dev/vg1/lv1-snap" successfully removed Have you checked if the CONTENT of the snapshot is indeed the right LV and not the other one? (I get the same "success" messages as what you cut'n'pasted above, but find that the wrong LV has been snapshotted when I look at the actual snapshot) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Off-Topic (or maybe on-topic)
On Fri, Oct 27, 2000 at 02:24:53PM +0100, Tigran Aivazian wrote: > On Fri, 27 Oct 2000, David Weinehall wrote: > > and 1924 the city got renamed again, this time to Leningrad. > > ok, then a quiz question - was it renamed before or after Lenin's death? > (hint, Lenin died in 1924). After his death. And the city was renamed back to St. Petersburg in 1991. With a 5 days-a-year long exception where the name Leningrad is used in parallel, in rememberance of WWII. /David _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
On Fri, Oct 27, 2000 at 02:04:58PM +0200, [EMAIL PROTECTED] wrote: > > Interesting. If it's caused by SCSI as well (might be), then it's not > > caused by heavy IDE activity but rather than that it could be heavy > > BusMastering activity instead (The IDE chip does BM as well). > > > > I'm still wondering if it could be a Linux kernel bug (bad/concurrent > > accesses to the i8253 registers), this has to be checked. > > > > How sure are you that the chip is actually buggy? I ran into something > similar a while ago, when I mixed the two arguments to an outb in a driver, > and ended up writing MYPORT into the timer instead of 0x40 into MYPORT. I'm *not* sure. It just looks like a reasonable explanation. It doesn't happen on Intel chips and older VIA chips, it only happens on new VIA chips, and the code is the same all the time. Also, it happens both with 2.2 and 2.4 kernels ... -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: LVM snapshotting broken?
On Fri, Oct 27, 2000 at 11:32:06AM -0200, Rik van Riel wrote: > Have you checked if the CONTENT of the snapshot is indeed > the right LV and not the other one? laser:~ # mke2fs /dev/vg1/lv1 &>/dev/null laser:~ # mount /dev/vg1/lv1 /mnt laser:~ # >/mnt/ciao laser:~ # ls /mnt . .. ciao lost+found laser:~ # umount /mnt laser:~ # lvcreate -s -n lv1-snap /dev/vg1/lv1 -L 400M lvcreate -- INFO: using default snapshot chunk size of 64 KB lvcreate -- doing automatic backup of "vg1" lvcreate -- logical volume "/dev/vg1/lv1-snap" successfully created laser:~ # mount /dev/vg1/lv1 /mnt laser:~ # rm /mnt/ciao laser:~ # umount /mnt laser:~ # mount /dev/vg1/lv1-snap /mnt mount: block device /dev/vg1/lv1-snap is write-protected, mounting read-only laser:~ # ls /mnt/ . .. ciao lost+found laser:~ # Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PROPOSED PATCH] ATM refcount + firestream
Andrew Morton wrote: > > Patrick van de Lageweg wrote: > > > > Hi all, > > > > Here is the second try for the atm refcount problem. I've made made > > several enhancement over the previos patch. Can you take a look at it if > > I've missed anything? (This time it also includes the driver for the > > firestream card. That's why the patch is so large. It's gziped and > > uuencoded). [snip] > The other thing you need to watch out for is atmdev_ops.ioctl(). > Can this be called when the device is not open? > > In other words, can atmdev_ops.ioctl() be called prior to > atmdev_ops.open()? In more other words, can ioctl() be > called after close()? > > If so then the above patch is not sufficient - it only increments > the module use count on the open() path. > > If this is the case then you're fairly severely screwed. This is > because the atm_dev handling has the same design flaw as the > netdevice handling: the logical place to inc/dec the module > refcount is within atm_dev_[de]register(). But this doesn't > work because you can never _get_ to the deregister point > through sys_delete_module() to drop the refcount. The fact of the matter is that we seriously abuse ioctl() to provide an interface to configuring network devices. You are supposed to have a valid file descriptor to do an ioctl, but in the network config cases, that fd doesn't have anything to do with the network device (look at the special cases in net/*/af_*.c). Thus our strategy of managing the module refcount on open/close gets sidestepped. Currently, the network devices have two states: registered, and open. Only in the open case is the module referenced. What should be done is add a third state in the middle, configured, which also holds a reference. Then the userspace configuration tools can explicitly unconfigure the device in order to release the reference and unload the module. In the mean time, we could wrap refcount inc/dec around the calls to dev->set_config() and dev->do_ioctl() in dev_ifsioc(). This fixes the potential oops but still perpetuates the abuse of ioctl though. I would rather see a new syscall or a misc character device added to provide the configuration interface. -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
> Does some one have a copy of the posix 1003.1g draft so this can be > verified. This is the kind of ammunition I was talking about earlier 1003.1g isnt what matters - SuS is. > that I would need to convince Sun to change the compatibility test > suite. However, if the 1003.1g draft even mentions failure with errno The compatibility test is broken from a pedantic point of view as your IP address can change dynamically between the query for it and the bind. In general though, bind() is assumed to do the checks and fail if non local and I agree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux's implementation of poll() not scalable?
> It doesn't practically matter how efficient the X server is when > you aren't busy, after all. A simple polling scheme (i.e. not using poll() or select(), just looping through all fd's trying nonblocking reads) is perfectly efficient when the server is 100% busy, and perfectly inefficient when there is nothing to do. I'm not saying that your statements are wrong--in your example, X is calling select() which is not wasting as much time as a hard-polling loop--but it's wrong to say that high-load efficiency is the primary concern. I would be horrified if X took a signifigant portion of the CPU time when many clients were connected, but none were actually doing anything. chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: LVM snapshotting broken?
On Fri, 27 Oct 2000, Andrea Arcangeli wrote: > On Fri, Oct 27, 2000 at 11:32:06AM -0200, Rik van Riel wrote: > > Have you checked if the CONTENT of the snapshot is indeed > > the right LV and not the other one? > > laser:~ # mke2fs /dev/vg1/lv1 &>/dev/null > laser:~ # mount /dev/vg1/lv1 /mnt > laser:~ # >/mnt/ciao > laser:~ # ls /mnt > . .. ciao lost+found > laser:~ # umount /mnt > laser:~ # lvcreate -s -n lv1-snap /dev/vg1/lv1 -L 400M > lvcreate -- INFO: using default snapshot chunk size of 64 KB > lvcreate -- doing automatic backup of "vg1" > lvcreate -- logical volume "/dev/vg1/lv1-snap" successfully created > > laser:~ # mount /dev/vg1/lv1 /mnt > laser:~ # rm /mnt/ciao > laser:~ # umount /mnt > laser:~ # mount /dev/vg1/lv1-snap /mnt > mount: block device /dev/vg1/lv1-snap is write-protected, mounting read-only > laser:~ # ls /mnt/ > . .. ciao lost+found > laser:~ # OK, good. I guess that means that the lvmutils (even the patched version in the RPM) are heavily broken ... Andrea, could you send me the patches you use to make your LVM utilities work? Then we'll be able to put together at least one working LVM utilities version ;) Heinz, how about releasing a 0.8.1 version of the utilities so that there is something WORKING out there? Not having working LVM utilities available is an utter disgrace when all the code to make it work is just available... regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: LVM snapshotting broken?
On Fri, Oct 27, 2000 at 11:55:03AM -0200, Rik van Riel wrote: > Andrea, could you send me the patches you use to make your > LVM utilities work? Then we'll be able to put together at ftp://ftp.suse.com/pub/suse/i386/7.0/suse/zq1/lvm.spm Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpu detection fixes for test10-pre4
> > - make Pentium IV and other post-P6 processors use the "i686" > > family name (same fix as the system_utsname.machine init fix > > which went into include/asm-i386/bugs.h in test10-pre4) > > > > We should never have used anything but "i386" as the utsname... sigh. Its questionable if we should include the 'i' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New VM problem
On Fri, Oct 27, 2000 at 07:03:29AM -0400, James Lewis Nance wrote: > I left a single large job running when I left yesterday afternoon > (size=1651M, RSS=1.5G). When I got in this morning I wanted to see if > it was still running so I typed "top" in an Xterm. When I hit return I > thought the machine had crashed. I could not move the cursor with the > mouse, or cause any other activity. I got a little more info. Even though the machine has 2G of ram and this process'es RSS is only 1.5G, the rest of the memory is being used somewhere. Top reports only about 1M as "free" memory. It also looks like kswapd is running with a high CPU usage when this is going on. Its a little hard to be sure since top freezes, but when it comes back to life kswapd shows up near the top of the process list. Thanks, Jim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
pcmcia in test10pre6
Previously working in test10pre*, now gives many unresolved symbols: /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_free /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_disable /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_read_memory /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_config /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_close_memory /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_register_mtd /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol read_tuple /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_check_erase_queue /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_release_cis_mem /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol find_io_region /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol write_cis_mem /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_write_memory /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol undo_irq /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_request_irq /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_parse_tuple /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_release /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol release_resource_db /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_alloc /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_get_first_region/lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol release_cis_mem /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol try_irq /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_adjust_resource_info /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_get_next_region /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_enable /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_copy_memory /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_get_tuple_data /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol verify_cis_cache /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_deregister_erase_queue /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_register_erase_queue /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_get_first_tuple /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol MTDHelperEntry /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol read_cis_mem /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_get_next_tuple /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_replace_cis /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_open_memory /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_validate_cis /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol find_mem_region - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PROPOSED PATCH] ATM refcount + firestream
On Fri, 27 Oct 2000, Andrew Morton wrote:
> Patrick van de Lageweg wrote:
> >
> > Hi all,
> >
> > Here is the second try for the atm refcount problem. I've made made
> > several enhancement over the previos patch. Can you take a look at it if
> > I've missed anything? (This time it also includes the driver for the
> > firestream card. That's why the patch is so large. It's gziped and
> > uuencoded).
>
> Patrick, I looked at the modules stuff and you do not
> appear to be actually _using_ it anywhere:
>
> bix:/home/morton> grep owner patch
> + owner: THIS_MODULE,
> + owner: THIS_MODULE
> + owner: THIS_MODULE,
> + owner:THIS_MODULE,
> + owner: THIS_MODULE,
> + owner: THIS_MODULE,
> + owner: THIS_MODULE,
> + struct module *owner;
> + struct module *owner;
> bix:/home/morton>
We use it throught the fops_get/fops_put macros to in/decrease the mod
counter. See the definitions for those macros (include/linux/fs.h)
Patrick
>
>
> It looks like you'll need something like the following:
> (warning: uncompiled ATM-ignoramus code)
>
> Index: net/atm/common.c
> ===
> RCS file: /opt/cvs/lk/net/atm/common.c,v
> retrieving revision 1.3.2.1
> diff -u -u -r1.3.2.1 common.c
> --- net/atm/common.c 2000/07/08 06:26:43 1.3.2.1
> +++ net/atm/common.c 2000/10/27 11:17:45
> @@ -144,6 +144,8 @@
> "rx_inuse == %d after closing\n",
> atomic_read(&vcc->rx_inuse));
> + if (vcc->dev->ops->owner)
> + __MOD_DEC_USE_COUNT(vcc->dev->ops->owner);
> bind_vcc(vcc,NULL);
> }
> if (free_sk) free_atm_vcc_sk(sk);
> }
> @@ -199,13 +201,22 @@
> {
> int error;
>
> + if (try_inc_mod_count(dev->ops->owner) == 0) {
> + return -ENODEV;
> + }
> +
> + error = 0;
> +
> if ((vpi != ATM_VPI_UNSPEC && vpi != ATM_VPI_ANY &&
> vpi >> dev->ci_range.vpi_bits) || (vci != ATM_VCI_UNSPEC &&
> - vci != ATM_VCI_ANY && vci >> dev->ci_range.vci_bits))
> - return -EINVAL;
> - if (vci > 0 && vci < ATM_NOT_RSV_VCI && !capable(CAP_NET_BIND_SERVICE))
> - return -EPERM;
> - error = 0;
> + vci != ATM_VCI_ANY && vci >> dev->ci_range.vci_bits)) {
> + error = -EINVAL;
> + goto out;
> + }
> + if (vci > 0 && vci < ATM_NOT_RSV_VCI && !capable(CAP_NET_BIND_SERVICE)) {
> + error = -EPERM;
> + goto out;
> + }
> bind_vcc(vcc,dev);
> switch (vcc->qos.aal) {
> case ATM_AAL0:
> @@ -231,19 +242,26 @@
> if (!error) error = adjust_tp(&vcc->qos.rxtp,vcc->qos.aal);
> if (error) {
> bind_vcc(vcc,NULL);
> - return error;
> + goto out;
> }
> DPRINTK("VCC %d.%d, AAL %d\n",vpi,vci,vcc->qos.aal);
> DPRINTK(" TX: %d, PCR %d..%d, SDU %d\n",vcc->qos.txtp.traffic_class,
> vcc->qos.txtp.min_pcr,vcc->qos.txtp.max_pcr,vcc->qos.txtp.max_sdu);
> DPRINTK(" RX: %d, PCR %d..%d, SDU %d\n",vcc->qos.rxtp.traffic_class,
> vcc->qos.rxtp.min_pcr,vcc->qos.rxtp.max_pcr,vcc->qos.rxtp.max_sdu);
> +
> if (dev->ops->open) {
> error = dev->ops->open(vcc,vpi,vci);
> if (error) {
> bind_vcc(vcc,NULL);
> - return error;
> + goto out;
> }
> + }
> +
> +out:
> + if (error) {
> + if (dev->ops->owner)
> + __MOD_DEC_USE_COUNT(dev->ops->owner);
> }
> return 0;
> }
>
>
> Something similar will be need to be wrapped around the usage of
> `struct atm_tcp_ops()' as well. Let me know if you'd like me to
> prototype a patch for that.
>
> The other thing you need to watch out for is atmdev_ops.ioctl().
> Can this be called when the device is not open?
>
> In other words, can atmdev_ops.ioctl() be called prior to
> atmdev_ops.open()? In more other words, can ioctl() be
> called after close()?
>
> If so then the above patch is not sufficient - it only increments
> the module use count on the open() path.
>
> If this is the case then you're fairly severely screwed. This is
> because the atm_dev handling has the same design flaw as the
> netdevice handling: the logical place to inc/dec the module
> refcount is within atm_dev_[de]register(). But this doesn't
> work because you can never _get_ to the deregister point
> through sys_delete_module() to drop the refcount.
>
> Like netdevices, ATM needs to be able to separate the act
> of loading the module from the act of registering the driver.
>
> netdevices manage to get away with it because of ANK's funky
> dev_hold()/dev_put() refcounting. It looks like ATM devices
> aren't that lucky.
>
> One workaround would be to refuse to allow the device to be
> accessed at a
Re: 2.4.0-test9 + LFS
On Fri, 27 Oct 2000, Wakko Warner wrote: > I did upgrade that and it didn't help anything. Was your glibc compiled against 2.4 kernel headers? -ben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PROPOSED PATCH] ATM refcount + firestream
Patrick van de Lageweg wrote: > > On Fri, 27 Oct 2000, Andrew Morton wrote: > > > Patrick van de Lageweg wrote: > > > > > > Hi all, > > > > > > Here is the second try for the atm refcount problem. I've made made > > > several enhancement over the previos patch. Can you take a look at it if > > > I've missed anything? (This time it also includes the driver for the > > > firestream card. That's why the patch is so large. It's gziped and > > > uuencoded). > > > > Patrick, I looked at the modules stuff and you do not > > appear to be actually _using_ it anywhere: > > > > bix:/home/morton> grep owner patch > > + owner: THIS_MODULE, > > + owner: THIS_MODULE > > + owner: THIS_MODULE, > > + owner:THIS_MODULE, > > + owner: THIS_MODULE, > > + owner: THIS_MODULE, > > + owner: THIS_MODULE, > > + struct module *owner; > > + struct module *owner; > > bix:/home/morton> > > We use it throught the fops_get/fops_put macros to in/decrease the mod > counter. See the definitions for those macros (include/linux/fs.h) > > Patrick This will break horribly if fops_put/get are changed to inlines instead of macros. They are only supposed to be used on struct file_operations. -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PROPOSED PATCH] ATM refcount + firestream
Brian Gerst wrote: > > > + struct module *owner; > > > + struct module *owner; > > > bix:/home/morton> > > > > We use it throught the fops_get/fops_put macros to in/decrease the mod > > counter. See the definitions for those macros (include/linux/fs.h) > > > > Patrick > > This will break horribly if fops_put/get are changed to inlines instead > of macros. They are only supposed to be used on struct file_operations. Oh? Anyway, we'll get nice warnings about wrong type of argument when that happens. I was the one who found the fops_get/put code useful as a guideline and also in fact as the code to call. So the question is: What is the defined interface for fops_get/put: Is it "it's a macro that... " or is it "it's a function (possibly a macro for efficiency) that "? Roger. P.S. Apologies for Patrick's bad quoting habits: He had to catch a train and forgot to delete the rest of the quoted mail. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of* ** prejudices acquired by age eighteen. -- Albert Einstein - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM-global-2.2.18pre17-7
On Fri, Oct 27, 2000 at 11:29:08AM -0200, you [Marcelo Tosatti] claimed: > > > On Fri, 27 Oct 2000, Neale Banks wrote: > > > On Thu, 26 Oct 2000, octave klaba wrote: > > > > > > > Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources. > > > > let me guess: intel eepro100 or similar?? > > > yeap > > > > er, "me too": > > > > Bus 0, device 2, function 0: > > Ethernet controller: Intel 82557 (rev 8). > > Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. >Latency=64. Min Gnt=8.Max Lat=56. > > Non-prefetchable 32 bit memory at 0xb5fff000 [0xb5fff000]. > > I/O at 0x2400 [0x2401]. > > Non-prefetchable 32 bit memory at 0xb5e0 [0xb5e0]. > > > > On Debian's 2.2.17-compact on a Compaq DL380 - with 60 days uptime I have > > 6 "eth0: card reports no resources." messages reported in dmesg. > > We are having the same problem with eepro100 on a Compaq DL360. > > v1.11 of eepro100.c fixed the problem: > > ftp://ftp.scyld.com/pub/network/eepro100.c The eepro100 problem (2.2.18pre17 stock) happens here too: "card reports no resources" and then the network stalls for few minutes. The hack suggested by David Richardson ( http://marc.theaimsgroup.com/?l=linux-kernel&m=96514412914742&w=2) did not help. The Becker's driver from ftp://ftp.scyld.com/pub/network/eepro100.c cures the error messages, but the network still stalls, and worse yet, seems to stall forever (as opposed to few minutes with 2.2.18pre17 driver). A network problem is not out of question (although the rest of the network works just fine, and we did try another HUB port). It could also be flaky card, but the machine and the card worked fine for years in their past life under NT. This is dual PPro200, 256MB, nothing fancy. -- v -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kqueue microbenchmark results
Alfred Perlstein wrote: > > If a programmer does not ever wish to block under any circumstances, it's > > his obligation to communicate this desire to the implementation. Otherwise, > > the implementation can block if it doesn't have data or an error available > > at the instant 'read' is called, regardless of what it may have known or > > done in the past. > > Yes, and as you mentioned, it was _bugs_ in the operating system > that did this. Not for writes. POLLOUT may be returned when the kernel thinks you have enough memory to do a write, but someone else may allocate memory before you call write(). Or does POLLOUT not work this way? For read, you still want to declare the sockets non-blocking so your code is robust on _other_ operating systems. It's pretty straightforward. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Big file support in Linux 2.2
Hello, For one of our projects here, we've crashed head first into the 2 gig file size limitation in Linux 2.2 kernels. While I know that this has been solved in 2.3/2.4, has there been any work to backport this feature into a Linux 2.2 kernel? I'm looking for a temporary solution until we can move to Linux 2.4 directly, but obviously not until after it's been "really" released. :) Yes, I know this is likely to be relatively unstable. (Probably almost as unstable as running a 2.4-pre kernel in production), but at least it would give us a start. Thanks for your help, Joe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Network block device moving to sourceforge
Hi! You can see the project at http://nbd.sourceforge.net/. If you want to help, just contact me. Pavel -- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Podfuk renamed to uservfs and moved to sourceforge
Hi! Subject says it pretty much all. If you want to help with anything, just get yourself sourceforge account and ask me ;-). Pavel -- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux 2.2.18pre17 + VM-global -7 = `Negative d_count' oops
On Fri, Oct 27, 2000 at 12:14:56PM +0100, Ian Jackson wrote: > gcc version 2.95.2 2220 (Debian GNU/Linux) Please give a try to 2.95.2 19991024 (release) or egcs 1.1.2 or gcc 2.7.2.3. I don't see anything strange in your .config. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM-global-2.2.18pre17-7
You should use the Intel e100 driver at http://support.intel.com/support/network/adapter/pro100/100Linux.htm. It works much better than eepro100. Jeff ASL - Original Message - From: Ville Herva <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, October 27, 2000 8:13 AM Subject: Re: VM-global-2.2.18pre17-7 > On Fri, Oct 27, 2000 at 11:29:08AM -0200, you [Marcelo Tosatti] claimed: > > > > > > On Fri, 27 Oct 2000, Neale Banks wrote: > > > > > On Thu, 26 Oct 2000, octave klaba wrote: > > > > > > > > > Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources. > > > > > let me guess: intel eepro100 or similar?? > > > > yeap > > > > > > er, "me too": > > > > > > Bus 0, device 2, function 0: > > > Ethernet controller: Intel 82557 (rev 8). > > > Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=64. Min Gnt=8.Max Lat=56. > > > Non-prefetchable 32 bit memory at 0xb5fff000 [0xb5fff000]. > > > I/O at 0x2400 [0x2401]. > > > Non-prefetchable 32 bit memory at 0xb5e0 [0xb5e0]. > > > > > > On Debian's 2.2.17-compact on a Compaq DL380 - with 60 days uptime I have > > > 6 "eth0: card reports no resources." messages reported in dmesg. > > > > We are having the same problem with eepro100 on a Compaq DL360. > > > > v1.11 of eepro100.c fixed the problem: > > > > ftp://ftp.scyld.com/pub/network/eepro100.c > > The eepro100 problem (2.2.18pre17 stock) happens here too: "card reports > no resources" and then the network stalls for few minutes. > > The hack suggested by David Richardson ( > http://marc.theaimsgroup.com/?l=linux-kernel&m=96514412914742&w=2) > did not help. > > The Becker's driver from ftp://ftp.scyld.com/pub/network/eepro100.c cures > the error messages, but the network still stalls, and worse yet, seems to > stall forever (as opposed to few minutes with 2.2.18pre17 driver). > > A network problem is not out of question (although the rest of the network > works just fine, and we did try another HUB port). It could also be flaky > card, but the machine and the card worked fine for years in their past > life under NT. > > This is dual PPro200, 256MB, nothing fancy. > > > -- v -- > > [EMAIL PROTECTED] > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Off-Topic (or maybe on-topic)
Tigran Aivazian wrote: > On Fri, 27 Oct 2000, David Weinehall wrote: > > > PS. Leningrad is the old historical name of the modern St. Petersberg but > > > we "old-timers" do still call it Leningrad, it seems more appropriate than > > > all those "modern" name-changes... ;) > > > > You're VERY wrong here. St. Petersburg was the name before the Soviet > > Union was formed and Russia marched into the Baltics. When the takeover > > was made, the city was renamed Leningrad (after V.I. Lenin). When the > > Soviet Union finally fell to pieces and the Baltics retained their freedom, > > St. Petersburg retained its old name, which it got (if I'm not all wrong) > > from Peter the Great. Speaking about Baltics, when St. Petersburg was original St. Petersburg, Baltics were in Russia. It was renamed Leningrad at the (approximately) same time Baltics were freed first time and Soviet Union was form, if you like :). SU matched back into Baltics later. By the way St. Petersburg is not _formally_ after Peter the Great. Peter the Great is not Saint. And yes, my Mom who who was born there still calls it Leningrad (or Piter, but not St. Petersburg). And so am I. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kqueue microbenchmark results
* Jamie Lokier <[EMAIL PROTECTED]> [001027 08:21] wrote: > Alfred Perlstein wrote: > > > If a programmer does not ever wish to block under any circumstances, it's > > > his obligation to communicate this desire to the implementation. Otherwise, > > > the implementation can block if it doesn't have data or an error available > > > at the instant 'read' is called, regardless of what it may have known or > > > done in the past. > > > > Yes, and as you mentioned, it was _bugs_ in the operating system > > that did this. > > Not for writes. POLLOUT may be returned when the kernel thinks you have > enough memory to do a write, but someone else may allocate memory before > you call write(). Or does POLLOUT not work this way? POLLOUT checks the socketbuffer (if we're talking about sockets), and yes you may still block on mbuf allocation (if we're talking about FreeBSD) if the socket isn't set non-blocking. Actually POLLOUT may be set even if there isn't enough memory for a write in the network buffer pool. > For read, you still want to declare the sockets non-blocking so your > code is robust on _other_ operating systems. It's pretty straightforward. Yes, it's true, not using non-blocking sockets is like ignoring friction in a physics problem, but assuming you have complete control over the machine it shouldn't trip you up that often. And we're talking about readability, not writeability which as you mentioned may block because of contention for the network buffer pool. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + LFS
> > I did upgrade that and it didn't help anything. > > Was your glibc compiled against 2.4 kernel headers? That I do not know. it's v 2.1.99 that came with debian in the past week or so -- Lab tests show that use of micro$oft causes cancer in lab animals - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + LFS
On Fri, Oct 27, 2000 at 12:19:54PM -0400, Wakko Warner wrote: > > > I did upgrade that and it didn't help anything. > > > > Was your glibc compiled against 2.4 kernel headers? > > That I do not know. it's v 2.1.99 that came with debian in the past > week or so Then it's compiled against the v2.2 kernel headers. /David _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
Re: Off-Topic (or maybe on-topic)
From: <[EMAIL PROTECTED]>
> If Bill said 'screw you' to the blackmailer and made the press release,
> we should see the source on web sites soon. Then we can see how bad it
> really is. Maybe even fix it.
Dave, my partner has legal access to the MS source code. In some of my own
work I discovered an interesting apparent HAL bug related to the ACPI and
the PerformanceCounter API. A fix for a bad INTEL chip (24 bit counter that
doesn't always count correctly) was falsed by my K7M motherboard with a
700MHz Athlon on it. He adapts the HALs for some behemoth machines. So he
has seen the code involved. It is literally chock full of hacks and patches
and such - because of chip hardware defects. I'd be VERY careful about
casually going in and patching or repairing that source code based on such
dinnertable conversation about the HAL code as we've had. (I know no details.
I just know he regularly moans about it. - I bet he's having an interesting
day up there today. He's there for a meeting with the W2K folks. I'll have
to ask him how the anthill was today when he gets home.)
{^_-}Joanne Dow, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + LFS
On Fri, 27 Oct 2000, David Weinehall wrote: > On Fri, Oct 27, 2000 at 12:19:54PM -0400, Wakko Warner wrote: > > That I do not know. it's v 2.1.99 that came with debian in the past > > week or so > > Then it's compiled against the v2.2 kernel headers. That explains why LFS isn't working then. I strongly suggest that the Debian glibc maintainers compile against 2.4 kernel headers or patch their 2.2 kernel headers to include the LFS stubs. -ben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Blocked processes <=> Elevator starvation?
On Sun, 8 Oct 2000, Rik van Riel wrote: > On Sun, 8 Oct 2000, Rui Sousa wrote: > > > After starting 2 processes that scan a lot of files (diff, find, > > slocate, ...) it's impossible to run any other processes that > > touch the disk, they will stall until one of the first two stop. > > Could this be a sign of starvation in the elevator code? > > It could well be. I've seen this problem too and don't > really have another explanation for this phenomenon. > > OTOH, maybe there is another reason for it that hasn't > been found yet ;) > I finally had time to give this a better look. It now seems the problem is in the VM system. I patched a test10-pre4 kernel with kdb, then started two "diff -ur linux-2.4.0testX linux-2.4.0testY > log1" and two "find / -true > log". After this I tried cat"ing" a small file. The cat never returned. At this point I entered kdb and did a stack trace on the "cat" process: schedule() ___wait_on_page() do_generic_file_read() generic_file_read() sys_read() system_call() So it seems the process is either in a loop in ___wait_on_page() racing for the PageLock or it never wakes-up... (I guess I could add a printk to check which) Unfortunately I didn't find anything obviously wrong with the code. I hope you can do a better job tracking the problem down. As a reminder: i686, UP, 64Mb RAM, IDE disks, ext2. Rui Sousa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Blocked processes <=> Elevator starvation?
On Fri, 27 Oct 2000, Rui Sousa wrote: > I finally had time to give this a better look. It now seems the > problem is in the VM system. *sigh* > schedule() > ___wait_on_page() > do_generic_file_read() > generic_file_read() > sys_read() > system_call() > > So it seems the process is either in a loop in ___wait_on_page() > racing for the PageLock or it never wakes-up... (I guess I could > add a printk to check which) It is spinning in ___wait_on_page() because the page never becomes available, because the IO doesn't get scheduled to disk in time. This appears to be an elevator problem, not a VM problem. regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Off-Topic (or maybe on-topic)
David Weinehall wrote: > > On Fri, Oct 27, 2000 at 04:05:50PM +0300, Petko Manolov wrote: > > David Weinehall wrote: > > > > > > You're VERY wrong here. St. Petersburg was the name before the Soviet > > > Union was formed and Russia marched into the Baltics. When the takeover > > > was made, the city was renamed Leningrad (after V.I. Lenin). When the > > > Soviet Union finally fell to pieces and the Baltics retained their freedom, > > > St. Petersburg retained its old name, which it got (if I'm not all wrong) > > > from Peter the Great. > > > > > > AFAIK Tigran is born in the Soviet Union and i thing he knows > > the history of his own country better ;-) > > Uhmmm. You known, being born in the Soviet Union (not a country in its > strictest sense), doesn't necessarily mean you know its history. And > considering that the span of the SSSR was quite enormous... > > Anyhow: > > The city was originally called Nyen and was formed by Swedes. 1703, > Peter the Great invaded the city, and 1712 the city became the capital > of Russia, named St. Petersburg. The name remained St. Petersburg until > 1914, when it was renamed Petrograd. 1918, Moscow was made the capital > of Russia, and 1924 the city got renamed again, this time to Leningrad. > > > Anyway, i am bulgarian and i also am used to call St. Petersburg > > Leningrad ;-)) > > Well, it's time for me, as a Swede, to begin calling it Nyen?! > > Oh, let's end this silly debate. I'm getting sorry I even brought it > up. Hi, but since you did, :) I will insist it is St. Petersburg :) Art. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kqueue microbenchmark results
Alan Cox wrote: > > > kqueue currently does this; a close() on an fd will remove any pending > > > events from the queues that they are on which correspond to that fd. > > > > the application of a close event. What can I say, "the fd formerly known > > as X" is now gone? It would be incorrect to say that "fd X was closed", > > since X no longer refers to anything, and the application may have reused > > that fd for another file. > > Which is precisely why you need to know where in the chain of events this > happened. Otherwise if I see > > 'read on fd 5' > 'read on fd 5' > > How do I know which read is for which fd in the multithreaded case That can't happen, can it? Let's say the following happens: close(5) accept() = 5 call kevent() and rebind fd 5 The 'close(5)' would remove the old fd 5 events. Therefore, any fd 5 events you see returned from kevent are for the new fd 5. (I suspect it helps that kevent() is both the only way to bind events and the only way to pick them up; makes it harder for one thread to sneak a new fd into the event list without the thread calling kevent() noticing.) - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
GPL Question
Consider this: A subsystem that is statically built into the Linux Kernel is modified to allow the registration of a structure containing function pointers. The function pointers corrolate to a set of functions within that subsystem. If the new structure of pointers has been registered, the original functions will call the new functions in the structure passing all arguments and returning the return value of the new function. With this said, if no structure has been registered, then no functionality is degraded within the kernel. Only the loss of some cpu time to check the pointers at the top of the old functions. Now, if a module is loaded that registers a set of functions that have increased functionality compared to the original functions, if that modules is not based off GPL'd code, must the source code of that module be released under the GPL? Thanks in advance, Jason Wohlgemuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kqueue microbenchmark results
* Dan Kegel <[EMAIL PROTECTED]> [001027 09:40] wrote: > Alan Cox wrote: > > > > kqueue currently does this; a close() on an fd will remove any pending > > > > events from the queues that they are on which correspond to that fd. > > > > > > the application of a close event. What can I say, "the fd formerly known > > > as X" is now gone? It would be incorrect to say that "fd X was closed", > > > since X no longer refers to anything, and the application may have reused > > > that fd for another file. > > > > Which is precisely why you need to know where in the chain of events this > > happened. Otherwise if I see > > > > 'read on fd 5' > > 'read on fd 5' > > > > How do I know which read is for which fd in the multithreaded case > > That can't happen, can it? Let's say the following happens: >close(5) >accept() = 5 >call kevent() and rebind fd 5 > The 'close(5)' would remove the old fd 5 events. Therefore, > any fd 5 events you see returned from kevent are for the new fd 5. > > (I suspect it helps that kevent() is both the only way to > bind events and the only way to pick them up; makes it harder > for one thread to sneak a new fd into the event list without > the thread calling kevent() noticing.) Yes, that's how it does and should work. Noticing the close() should be done via thread communication/IPC not stuck into kqueue. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: GPL Question
On Fri, 27 Oct 2000, Jason Wohlgemuth wrote: > Now, if a module is loaded that registers a set of functions that have > increased functionality compared to the original functions, if that > modules is not based off GPL'd code, must the source code of that module > be released under the GPL? It would probably follow GPL, but it's pretty slimy. I won't buy it. david -- David Weis| "Great spirits will always encounter violent [EMAIL PROTECTED] | opposition from mediocre minds" - Einstein http://www.sjdjweis.com/ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia in test10pre6
On Fri, Oct 27, 2000 at 11:32:18AM +, Jonathan Hudson wrote: > > Previously working in test10pre*, now gives many unresolved symbols: > > > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_free > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_disable > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_read_memory > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_config > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_close_memory > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_register_mtd > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol read_tuple > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_check_erase_queue > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_release_cis_mem > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol find_io_region > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol write_cis_mem > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_write_memory > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol undo_irq > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_request_irq > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_parse_tuple > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_release > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol release_resource_db > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_alloc > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol >pcmcia_get_first_region/lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol >release_cis_mem > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol try_irq > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_adjust_resource_info > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_get_next_region > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol cb_enable > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_copy_memory > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_get_tuple_data > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol verify_cis_cache > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol >pcmcia_deregister_erase_queue > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_register_erase_queue > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_get_first_tuple > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol MTDHelperEntry > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol read_cis_mem > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_get_next_tuple > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_replace_cis > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_open_memory > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol pcmcia_validate_cis > /lib/modules/2.4.0-test10/pcmcia/cs.o: unresolved symbol find_mem_region Grab the pcmcia off sourceforge. It seems to build and work. The stuff in 2.4 at present is still somewhat broken. I worked on this until 2:00 last night getting it to build with 2.4. Thanks to Alan for pointing me to a package that actually works and will build on 2.4. :-) Jeff > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS flags all files executable on NetWare Volumes wit
On Fri, Oct 27, 2000 at 03:00:31PM +, Petr Vandrovec wrote:
> On 27 Oct 00 at 0:16, Jeff V. Merkey wrote:
> > I noticed NCPFS is flagging all the files on a native NetWare volume as
> > executable and chmod -x does not work, even if the NetWare server has
> > the NFS namespace loaded. I looked at you code in more detail, and I
> > did not see support their for the NFS/Unix namespace.
>
> > Is this in a newer version, or has it not been implemented yet? I was
> > testing with MARS and Native NetWare this evening and saw this. If the
> > NFS namespace is loaded, you should be able to get to it and access and
> > set all these bits in the file system namespace directory records.
> >
> > Do you need any info from me to get this working, or is there another
> > version where I can get this for Ute-Linux?
>
> Hi Jeff,
> ncpfs does not support NFS fields, as access through namespace functions
> is hopelessly broken (modify ns specific info has swapped some bits
> in mask which data update and which not), and it also adds some (100%)
> overhead on directory/inode lookups, as you must ask twice - first for
> non-NFS info, and second for NFS specific...
>
> There exists patch from Ben Harris <[EMAIL PROTECTED]>, which adds
> this feature to 2.2.16 kernel and 2.2.0.17 ncpfs. You can download
> it from ftp://platan.vc.cvut.cz/pub/linux/ncpfs/ncp{1,2}.pat. ncp1.pat
> is kernel patch (including email headers; cut them if applying), ncp2.pat
> is patch for 2.2.0.17 ncpfs userspace - it adds mount option "nfsextras".
> (I apologize to Ben - I promised to integrate it into ncpfs, and into
> 2.4 kernel, but...)
>
> Except that, you can make all files non-executable by using
> "filemode=0644" mount option. Or you can use "extras,symlinks", in which
> case (NFS namespace incompatible) hidden/shareable/transactional attributes
> are used to signal executability of file...
>
> If you have some document which describes what each NFS specific field
> does - currently ncpfs names them "name", "mode", "gid", "nlinks", "rdev",
> "link", "created", "uid", "acsflag" and "myflag" - if I remember correctly,
> it is how Unixware 2.0 nuc.h names them. And I did not found any information
> about layout of NFS huge info, which is used for hardlinks :-(
>
> Also, as NCP 87,8 kills almost every NW server I know, if used namespace
> is NFS, I'm a bit sceptic about usability of NCP 87,* on NFS namespace.
>
> In 1998 and 1999 I tried to ask Novell for documentation of NCP 95,*
> (Netware Unix Client), but it was refused and ignored, so... here we are.
> Best regards,
> Petr Vandrovec
> [EMAIL PROTECTED]
Petr,
I've got the info you need including the layout of the NFS namspace
records. For a start, grab NWFS and look at the NFS structure in
NWDIR.H. The fields you have to provide are there. There are some
funky ones in this structure. You are correct regarding the NCP
extensions to support this. They are about 12 years old, BTW and are
not even supported any longer (no one has worked on this at Novell
since about 1994).
I will put together a complete description today (will take a couple
of hours) and post to the list on the implementation of of the NFS
namespace over the wire. Hardlinks use a root DirNo handle that
must point back to the DOS namespace record that owns the FAT chain
and this is probably the only nasty thing to deal with here.
I'll get started immediately.
:-)
Jeff
>
> P.S.: Jeff, if you want, there is ncpfs/MaRS/LinWare specific list,
> [EMAIL PROTECTED] Subscribe: "subscribe linware" to "[EMAIL PROTECTED]".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS flags all files executable on NetWare Volumes wit
On Fri, Oct 27, 2000 at 10:57:54AM -0600, Jeff V. Merkey wrote:
> On Fri, Oct 27, 2000 at 03:00:31PM +, Petr Vandrovec wrote:
> > On 27 Oct 00 at 0:16, Jeff V. Merkey wrote:
> > > I noticed NCPFS is flagging all the files on a native NetWare volume as
> > > executable and chmod -x does not work, even if the NetWare server has
> > > the NFS namespace loaded. I looked at you code in more detail, and I
> > > did not see support their for the NFS/Unix namespace.
> >
> > > Is this in a newer version, or has it not been implemented yet? I was
> > > testing with MARS and Native NetWare this evening and saw this. If the
> > > NFS namespace is loaded, you should be able to get to it and access and
> > > set all these bits in the file system namespace directory records.
> > >
> > > Do you need any info from me to get this working, or is there another
> > > version where I can get this for Ute-Linux?
> >
> > Hi Jeff,
> > ncpfs does not support NFS fields, as access through namespace functions
> > is hopelessly broken (modify ns specific info has swapped some bits
> > in mask which data update and which not), and it also adds some (100%)
> > overhead on directory/inode lookups, as you must ask twice - first for
> > non-NFS info, and second for NFS specific...
> >
> > There exists patch from Ben Harris <[EMAIL PROTECTED]>, which adds
> > this feature to 2.2.16 kernel and 2.2.0.17 ncpfs. You can download
> > it from ftp://platan.vc.cvut.cz/pub/linux/ncpfs/ncp{1,2}.pat. ncp1.pat
> > is kernel patch (including email headers; cut them if applying), ncp2.pat
> > is patch for 2.2.0.17 ncpfs userspace - it adds mount option "nfsextras".
> > (I apologize to Ben - I promised to integrate it into ncpfs, and into
> > 2.4 kernel, but...)
> >
> > Except that, you can make all files non-executable by using
> > "filemode=0644" mount option. Or you can use "extras,symlinks", in which
> > case (NFS namespace incompatible) hidden/shareable/transactional attributes
> > are used to signal executability of file...
> >
> > If you have some document which describes what each NFS specific field
> > does - currently ncpfs names them "name", "mode", "gid", "nlinks", "rdev",
> > "link", "created", "uid", "acsflag" and "myflag" - if I remember correctly,
Oh, and:
created is always set to 1 for the root entry.
acsflag is whehter NetWare or the NFS client last accessed the file
name is the name
mode CANNOT contain NFS v3.0 style permissions it's on v2.0 -- pipe and
fifo will hang the NetWare server, so mask these off.
nlinks is the number of hardlinks to a file.
rdev is the same as rdev in Linux
flags(myflag) contains the following values:
#define NFS_HASSTREAM_HARD_LINK 1 // indicates this record has the FAT chain
#define NFS_SYMBOLIC_LINK2
#define NFS_HARD_LINK3
There's also three linkage fields you have to fill out:
LinkNextDirNo // next record in the hardlink chain
LinkEndDirNo// always the dir record that holds the fat chain
LinkPreDirNo// previous record in the hardlink chain
records are added at the HEAD and not the TAIL of the linkage. The
root record is always at the END and not the HEAD of the list.
:-)
Jeff
I'll go dig up the specific NCP extensions and get them to you.
:-)
Jeff
> > it is how Unixware 2.0 nuc.h names them. And I did not found any information
> > about layout of NFS huge info, which is used for hardlinks :-(
> >
> > Also, as NCP 87,8 kills almost every NW server I know, if used namespace
> > is NFS, I'm a bit sceptic about usability of NCP 87,* on NFS namespace.
> >
> > In 1998 and 1999 I tried to ask Novell for documentation of NCP 95,*
> > (Netware Unix Client), but it was refused and ignored, so... here we are.
> > Best regards,
> > Petr Vandrovec
> > [EMAIL PROTECTED]
>
>
> Petr,
>
> I've got the info you need including the layout of the NFS namspace
> records. For a start, grab NWFS and look at the NFS structure in
> NWDIR.H. The fields you have to provide are there. There are some
> funky ones in this structure. You are correct regarding the NCP
> extensions to support this. They are about 12 years old, BTW and are
> not even supported any longer (no one has worked on this at Novell
> since about 1994).
>
> I will put together a complete description today (will take a couple
> of hours) and post to the list on the implementation of of the NFS
> namespace over the wire. Hardlinks use a root DirNo handle that
> must point back to the DOS namespace record that owns the FAT chain
> and this is probably the only nasty thing to deal with here.
>
> I'll get started immediately.
>
> :-)
>
> Jeff
>
>
>
>
> >
> > P.S.: Jeff, if you want, there is ncpfs/MaRS/LinWare specific list,
> > [EMAIL PROTECTED] Subs
Re: VM-global-2.2.18pre17-7
> You should use the Intel e100 driver at > http://support.intel.com/support/network/adapter/pro100/100Linux.htm. > It works much better than eepro100. Thats not the general consensus, but its worth trying in case it works best for a given problem. In paticular it knows about bugs with combinations of transceivers which the eepro100 driver does not. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: GPL Question
> On Fri, 27 Oct 2000, Jason Wohlgemuth wrote: > > > Now, if a module is loaded that registers a set of functions that have > > increased functionality compared to the original functions, if that > > modules is not based off GPL'd code, must the source code of that module > > be released under the GPL? > > It would probably follow GPL, but it's pretty slimy. I won't buy it. It depends primarily if the module depends on the code which is GPL. Its all a rather unclear area. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: GPL Question
> Now, if a module is loaded that registers a set of functions that have > increased functionality compared to the original functions, if that > modules is not based off GPL'd code, must the source code of that module > be released under the GPL? Consult a Copyright/'Intellectual Property' lawyer. I wouldnt ask a lawyer to write a kernel driver, I would suggest not asking kernel hackers to do law 8) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: GPL Question
On Fri, 27 Oct 2000, Jason Wohlgemuth wrote: > Consider this: > > A subsystem that is statically built into the Linux Kernel is modified > to allow the registration of a structure containing function pointers. > > The function pointers corrolate to a set of functions within that subsystem. > If the new structure of pointers has been registered, the original > functions will call the new functions in the structure passing all > arguments and returning the return value of the new function. > > With this said, if no structure has been registered, then no > functionality is degraded within the kernel. Only the loss of some cpu > time to check the pointers at the top of the old functions. > > Now, if a module is loaded that registers a set of functions that have > increased functionality compared to the original functions, if that > modules is not based off GPL'd code, must the source code of that module > be released under the GPL? > > Thanks in advance, > Jason Wohlgemuth the api of the module would be a reimplementation of a GPL'd api (the function names may have changed, but the base behaviors must be equivalent) so the question in simple terms might phrased as: is the API under GPL, or is it the code or are both? I think the answer is both. -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | ** **** ** "WYGIWYD - What You Get Is What You Deserve" ** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: GPL Question
On Fri, Oct 27, 2000 at 06:21:27PM +0100, Alan Cox wrote: > > On Fri, 27 Oct 2000, Jason Wohlgemuth wrote: > > > > > Now, if a module is loaded that registers a set of functions that have > > > increased functionality compared to the original functions, if that > > > modules is not based off GPL'd code, must the source code of that module > > > be released under the GPL? > > > > It would probably follow GPL, but it's pretty slimy. I won't buy it. > > It depends primarily if the module depends on the code which is GPL. Its all > a rather unclear area. Legally, I think this is probably unclear. But, I have my own, personal standard I use for this. The question in my mind is one of "can it stand alone". In the example originally mentioned, the new module (let's call it the alpha module) registers function calls with the old module (let's call it beta). Now, the question in my mind is this: Is alpha a replacement for beta? It certainly sounds like it. But it depends of what/how many functions are being overridden. Are there other functions from beta which are used by alpha (either as above alpha or below it)? What are these replacement functions trying to do? If you're using an allready existing abstraction layer, then you're probably okay... but if you're really inventing a new abstraction layer, then you're probably not okay. I guess what I'm saying is this: It all comes down to intent for me. Yeah, that's a lousy standard to use, especially in a courtroom. But that's what I really care about in the end. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver We can customize our colonels. -- Tux User Friendly, 12/1/1998 PGP signature
Full preemption issues
Dear Linus,
As you know we at MontaVista are working on a fully preemptable kernel.
In this work we have come up with a couple of issues we would like your
comments on.
First, as you know, we have added code to the spinlock macros to count
up and down a preemption lock counter. We would like to not do this if
the macro also turns off local interrupts. The issue here is that in
some places in the code, spin_lock_irq() or spin_lock_irqsave() is
called but spin_unlock_irq() or spin_lock_irqrestore() is not. This, of
course, confuses the preemption count. Attached is a patch that
addresses this issue. At this time we are not asking you to apply this
patch, but to indicate if we are moving in an acceptable direction.
The second issue resolves around the naming conventions used in the
kernel. We want to extend this work to include the SMP kernel, but to
do this we need to have several levels of names for the spinlock
macros. We note that the kernel uses "_" and "__" prefixes in some
macros, but can not, by inspection, figure out when to uses these
prefixes. Could you explain this convention or is this wisdom written
somewhere?
To clarify the intent here is a bit of proto code:
#ifdef CONFIG_PREEMPT
#define preempt_lock() ... definition...
#define preempt_unlock() ...definition...
#else
#define preempt_lock()
#define preempt_unlock()
#endif
#ifdef CONFIG_SMP
#define _spin_lock(x) __spin_lock(x) /* __spin_lock(x) to be todays SMP
definition */
#define _spin_unlock(x) __spin_unlock(x) /* __spin_unlock(x) to be
todays SMP definition */
#else
#define _spin_lock()
#define _spin_unlock()
#endif
#define spin_lock(x) do{ preempt_lock(); _spin_lock(x);} while (0)
#define spin_unlock(x) do{ _spin_unlock(x); preempt_unlock();} while (0)
George
diff -urP -X patch.exclude linux-2.4.0-test6-kb-p-r-i-6-1.4/drivers/ide/ide.c
linux/drivers/ide/ide.c
--- linux-2.4.0-test6-kb-p-r-i-6-1.4/drivers/ide/ide.c Thu Jul 27 16:40:57 2000
+++ linux/drivers/ide/ide.c Fri Oct 20 13:06:45 2000
@@ -1354,7 +1354,7 @@
*/
if (masked_irq && hwif->irq != masked_irq)
disable_irq_nosync(hwif->irq);
- spin_unlock(&io_request_lock);
+ spin_unlock_noirqrestore(&io_request_lock);
ide__sti(); /* allow other IRQs while we start this request */
startstop = start_request(drive);
spin_lock_irq(&io_request_lock);
@@ -1438,7 +1438,7 @@
* the handler() function, which means we need to globally
* mask the specific IRQ:
*/
- spin_unlock(&io_request_lock);
+ spin_unlock_noirqrestore(&io_request_lock);
hwif = HWIF(drive);
#if DISABLE_IRQ_NOSYNC
disable_irq_nosync(hwif->irq);
@@ -1599,7 +1599,7 @@
}
hwgroup->handler = NULL;
del_timer(&hwgroup->timer);
- spin_unlock(&io_request_lock);
+ spin_unlock_noirqrestore(&io_request_lock);
if (drive->unmask)
ide__sti(); /* local CPU only */
--- linux-2.4.0-test6-org/include/linux/spinlock.h Wed Aug 9 18:57:54 2000
+++ linux/include/linux/spinlock.h Fri Oct 27 09:48:47 2000
@@ -7,29 +7,107 @@
* These are the generic versions of the spinlocks and read-write
* locks..
*/
-#define spin_lock_irqsave(lock, flags) do { local_irq_save(flags);
spin_lock(lock); } while (0)
-#define spin_lock_irq(lock)do { local_irq_disable();
spin_lock(lock); } while (0)
-#define spin_lock_bh(lock) do { local_bh_disable();
spin_lock(lock); } while (0)
-
-#define read_lock_irqsave(lock, flags) do { local_irq_save(flags);
read_lock(lock); } while (0)
-#define read_lock_irq(lock)do { local_irq_disable();
read_lock(lock); } while (0)
-#define read_lock_bh(lock) do { local_bh_disable();
read_lock(lock); } while (0)
-
-#define write_lock_irqsave(lock, flags)do { local_irq_save(flags);
write_lock(lock); } while (0)
-#define write_lock_irq(lock) do { local_irq_disable();
write_lock(lock); } while (0)
-#define write_lock_bh(lock)do { local_bh_disable();
write_lock(lock); } while (0)
-
-#define spin_unlock_irqrestore(lock, flags)do { spin_unlock(lock);
local_irq_restore(flags); } while (0)
-#define spin_unlock_irq(lock) do { spin_unlock(lock);
local_irq_enable(); } while (0)
-#define spin_unlock_bh(lock) do { spin_unlock(lock);
local_bh_enable();} while (0)
-
-#define read_unlock_irqrestore(lock, flags)do { read_unlock(lock);
local_irq_restore(flags); } while (0)
-#define read_unlock_irq(lock) do { read_unlock(lock);
local_irq_enable(); } while (0)
Re: Full preemption issues
On Fri, 27 Oct 2000, George Anzinger wrote: > > First, as you know, we have added code to the spinlock macros to count > up and down a preemption lock counter. We would like to not do this if > the macro also turns off local interrupts. The issue here is that in > some places in the code, spin_lock_irq() or spin_lock_irqsave() is > called but spin_unlock_irq() or spin_lock_irqrestore() is not. This, of > course, confuses the preemption count. Attached is a patch that > addresses this issue. At this time we are not asking you to apply this > patch, but to indicate if we are moving in an acceptable direction. Looks entirely sane to me. > The second issue resolves around the naming conventions used in the > kernel. We want to extend this work to include the SMP kernel, but to > do this we need to have several levels of names for the spinlock > macros. We note that the kernel uses "_" and "__" prefixes in some > macros, but can not, by inspection, figure out when to uses these > prefixes. Could you explain this convention or is this wisdom written > somewhere? The "wisdom" is not written down anywhere, and is more a convention than anything else. The convention is that a prepended "__" means that "this is an internal routine, and you can use it, but you should damn well know what you're doing if you do". For example, the most common use is for routines that need external locking - the version that does its own locking and is thus "safe" to use in normal circumstances has the regular name, and the version of the routine that does no locking and depends on the caller to lock for it has the "__" version. Your proto code does not break this convention in any way.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM-global-2.2.18pre17-7
Alan, I agree with your point. In term of usability, the e100 driver has a wider range of support for the Intel NIC cards. Jeff - Original Message - From: Alan Cox <[EMAIL PROTECTED]> To: Jeff Nguyen <[EMAIL PROTECTED]> Cc: Ville Herva <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, October 27, 2000 10:16 AM Subject: Re: VM-global-2.2.18pre17-7 > > You should use the Intel e100 driver at > > http://support.intel.com/support/network/adapter/pro100/100Linux.htm. > > It works much better than eepro100. > > Thats not the general consensus, but its worth trying in case it works best > for a given problem. In paticular it knows about bugs with combinations of > transceivers which the eepro100 driver does not. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
mkraid
Hi, I have a problem with mkraid I am working on a Red hat Linux ver 7.0 kernel version: 2.2.16 No raid patch no raid tools when I run #mkraid /dev/md0 when I check /proc/mdstat,I find md0 active with raid information. But when again I run #mkraid /dev/md0 I get an message: handling MD device /dev/md0 analyzing super-block disk 0:/dev/hde1,2109681kB,raid superblock at 2109568KB /dev/hde1 appears to be already part of a raid array-- use -f to force desctruction of the old superblock mkraid: aborted,see the syslog and /proc/mdstat for potential clues. I tried -f option, but no use. I did a reboot and once again mkraid, but still I get the above messages. Please let me know where am I wrong , How can I do mkraid succesfully again? Expecting reply from you with regards, Anil __ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpu detection fixes for test10-pre4
Alan Cox wrote: > > > > - make Pentium IV and other post-P6 processors use the "i686" > > > family name (same fix as the system_utsname.machine init fix > > > which went into include/asm-i386/bugs.h in test10-pre4) > > > > > > > We should never have used anything but "i386" as the utsname... sigh. > > Its questionable if we should include the 'i' heh, agreed. let's rename 'em all x86 and be done with it. ;-) -- Tim Riker - http://rikers.org/ - short SIGs! All I need to know I could have learned in Kindergarten ... if I'd just been paying attention. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Somewhat different GPL Question
If I use some GPL'd code and make calls from my software to the GPL'd code, do I need to make *my* code available? Or would I only have to make available any changes to the GPL'd code? Section 2.b of the GPL seems to indicate that I need to make the source for my entire executable available if it incorporates any GPL'd source, and that I cannot charge for the software, only for its distribution. Is this correct? Thanks, Chris -- Chris Friesen| MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Big file support in Linux 2.2
Joe writes: > For one of our projects here, we've crashed head first into the 2 gig file > size limitation in Linux 2.2 kernels. While I know that this has been solved > in 2.3/2.4, has there been any work to backport this feature into a Linux 2.2 > kernel? I'm looking for a temporary solution until we can move to Linux 2.4 > directly, but obviously not until after it's been "really" released. :) You can get a 2.2 LFS patch from: http://www.scyld.com/software/lfs.html There may be other sources. You also need to have a newer glibc (or recompile your own) to really support LFS. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Somewhat different GPL Question
On Fri, 27 Oct 2000, Christopher Friesen wrote: > If I use some GPL'd code and make calls from my software to the > GPL'd code, do I need to make *my* code available? Or would I > only have to make available any changes to the GPL'd code? > > Section 2.b of the GPL seems to indicate that I need to make the > source for my entire executable available if it incorporates any > GPL'd source, and that I cannot charge for the software, only > for its distribution. Is this correct? It depends. If you're making interprocess calls to call the GPL code, I suspect you won't have to make your code GPL. OTOH, if you /link/ against a GPL shared library, you will have to GPL the source of your program (that is, you'll have to give it to the people who receive the binary from you). Mind that lots of the "system" libraries are under the somewhat more free LPGL... regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Big file support in Linux 2.2
On Fri, Oct 27, 2000 at 12:02:44PM -0600, Andreas Dilger wrote: > There may be other sources. You also need to have a newer glibc (or recompile > your own) to really support LFS. However all software is *not* written to use LFS extended versions of things. Often using defines of: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 in the Makefile of said software CFLAGS is enough, but that may still sometimes not be enough. Specifically if the system will then use some libraries which are not LFS compatible. > Cheers, Andreas > http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpu detection fixes for test10-pre4
Alan Cox wrote: > > > > - make Pentium IV and other post-P6 processors use the "i686" > > > family name (same fix as the system_utsname.machine init fix > > > which went into include/asm-i386/bugs.h in test10-pre4) > > > > > > > We should never have used anything but "i386" as the utsname... sigh. > > Its questionable if we should include the 'i' > True enough, personally I prefer "x86". -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM-global-2.2.18pre17-7
> The Becker's driver from ftp://ftp.scyld.com/pub/network/eepro100.c cures > the error messages, yes. even is setup is not clean, it seems to work with 24-25Mbs since I have no errors. > but the network still stalls, and worse yet, seems to > stall forever (as opposed to few minutes with 2.2.18pre17 driver). after 2h it still works. maybe it will crash later. check it later. octave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: GPL Question
> Now, if a module is loaded that registers a set of functions that have > increased functionality compared to the original functions, if that > modules is not based off GPL'd code, must the source code of that module > be released under the GPL? If the answer to this is "yes", then Microsoft should own some rights to every piece of software that uses the Windows API. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Supporting extended attributes and named streams on Posix OSes
I saw that a number of people downloaded the document; did anyone read it? -M Michael Rothwell wrote: > > I realize all of this is 2.5 material. > > We had been talking about this earlier, until Viro and Cox told us to > quit until 2.5. > > Alexander Viro wrote: > > > > It goes off-list. > > But, in light of Andreas Gruenbacher's proposal > (http://lwn.net/2000/1026/a/extended-attributes.php3) and Stephen > Tweedie's proposal (http://lwn.net/2000/1026/a/sct-attributes.php3), I > thought I should re-send our proposal > (http://www.flyingbuttmonkeys.com/DraftStandard-MRR-4.pdf). > > Please read and comment! :) > > -M > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
IDE patches for 2.2.18-pre17
Does anyone have the IDE patches updated for 2.2.18-pre17? The version for 2.2.18-pre3 has a lot of rejects when applied to pre17, and I figured I'd see if someone has worked them out already. Thank in advance. --Lee Hetherington - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
