Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo
>> >> Hi, >> >> while trying to enhance a small hardware inventory script, I found that >> cpuinfo is missing the details of L1, L2 and L3 size, although they may >> be available at boot time. One could of cource grep them from "dmesg" >> output, but that may scroll away on long lived systems. >> > >Any particular reason this needs to be done in the kernel, as opposed >to having your script read /dev/cpu/*/cpuid? > >-hpa terse answer: probably the same reason as for most stuff in /proc/cpuinfo :-) Seriously, is there any kind of documentation on for the stuff you mention? I am willing to learn. Isn't the cpuid just a kind of serialnumber? The one that caused the big flame wars when Intel introduced the concept? In any case, on my system(s) there seems to be no device behind those files. On some systems, there is even no "/dev/cpu" directory. I agree in a way that the changes to processor.h are not neccessary - unless other parts of the kernel are interested in those values. I probably should change that to make the thing easier to digest. Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo
"Martin.Knoblauch" wrote: > > >> > >> Hi, > >> > >> while trying to enhance a small hardware inventory script, I found that > >> cpuinfo is missing the details of L1, L2 and L3 size, although they may > >> be available at boot time. One could of cource grep them from "dmesg" > >> output, but that may scroll away on long lived systems. > >> > > > >Any particular reason this needs to be done in the kernel, as opposed > >to having your script read /dev/cpu/*/cpuid? > > > >-hpa > > terse answer: probably the same reason as for most stuff in > /proc/cpuinfo :-) > After some checking, I could have made the answer a bit less terse: - it would require that the kernel is compiled with cpuid [module] support - not everybody may want enable this, just for getting one or two harmless numbers. - you would need a utility with root permission to analyze the cpuid info. The cahce info does not seem to be there in clear ascii. - this limits my script to root users, or you need the setuid-bit on the utility. Not really good for security. - the cpuid stuff is i386 specific [today]. So are my changes. But implementing them for other architectures [if there is interest in the info] would not require to also implement the cpuid on other architectures. Which may not make any sense at all. So, having the numbers in clear text in the cpuinfo file looks simpler and safer to me, although reading /dev/cpu/*/cpuinfo maybe more versatile [on i386] - at some cost. Question: are there any utilities or other uses for the cpuid device today? Just interested. The kernel seems to work well without it. Cheers Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo
Dave Jones wrote: > > On Wed, 23 May 2001, Martin Knoblauch wrote: > > > They may not be stupid, just mislead :-( When Intel created the "cpuid" > > Feature some way along the P3 line, they gave a stupid reason for it and > > created a big public uproar. As silly as I think that was (on both > > sides), the term "cpuid" is tainted. Some people just fear it like hell. > > Anyway. > > I think you are confusing the CPU serial number with CPUID which is > not the same. CPUID instruction has been around since late 486en. > seems I am being confused. If that happens to me :-) Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 C+ITS|Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 begin:vcard n:Knoblauch;Martin tel;cell:+49-170-4904759 tel;fax:+49-89-510857-111 tel;work:+49-89-510857-309 x-mozilla-html:FALSE url:http://www.teraport.de org:TeraPort GmbH;C+ITS adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany version:2.1 email;internet:[EMAIL PROTECTED] title:Senior System Engineer x-mozilla-cpt:;-7008 fn:Martin Knoblauch end:vcard
Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo
Dave Jones wrote: > > On Wed, 23 May 2001, Tomas Telensky wrote: > > > Yes. Recently I tried to transform whole cpuid code to a userspace > > utility. Not easy, not clean... but it worked. > > See http://www.sourceforge.net/projects/x86info > or ftp://ftp.suse.com/pub/people/davej/x86info/ > thanks for the pointer. Definitely gives some very interesting information about ones x86 CPU. At least something to work on. The output for different CPU types is a bit incoherent, making it difficult to parse. That why I [still] think (yes I'm stubborn :-) that having the cache sizes in /proc/cpuinfo in one format is a good idea. The info is there, it is just the output. With the userland tool, you always may have discrepancies between the kernels view and the tools view. But I agree, it does not *have* to go into the kernel. Cheers MArtin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 C+ITS|Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 begin:vcard n:Knoblauch;Martin tel;cell:+49-170-4904759 tel;fax:+49-89-510857-111 tel;work:+49-89-510857-309 x-mozilla-html:FALSE url:http://www.teraport.de org:TeraPort GmbH;C+ITS adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany version:2.1 email;internet:[EMAIL PROTECTED] title:Senior System Engineer x-mozilla-cpt:;-7008 fn:Martin Knoblauch end:vcard
[Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo
Hi, while trying to enhance a small hardware inventory script, I found that cpuinfo is missing the details of L1, L2 and L3 size, although they may be available at boot time. One could of cource grep them from "dmesg" output, but that may scroll away on long lived systems. The following small patch (against 2.4.4-ac11) extracts/outputs the cache sizes (i386 only) in arch/i386/kernel/setup.c. It also stores them in the cpuinfo_x86 structure. This may not be necessary for a one time usage. --- linux-2.4.4-ac11.orig/arch/i386/kernel/setup.c Mon May 21 14:15:27 2001 +++ linux-2.4.4-ac11/arch/i386/kernel/setup.c Mon May 21 14:27:58 2001 @@ -67,6 +67,10 @@ * * AMD Athlon/Duron/Thunderbird bluesmoke support. * Dave Jones <[EMAIL PROTECTED]>, April 2001. + * + * More detailed output of L1, L2 and L3 cache sizes to /proc/cpuinfo, if available. + * Martin Knoblauch <[EMAIL PROTECTED]>, May 2001 + * */ /* @@ -1113,6 +1117,8 @@ printk(KERN_INFO "CPU: L1 I Cache: %dK (%d bytes/line), D cache %dK (%d bytes/line)\n", edx>>24, edx&0xFF, ecx>>24, ecx&0xFF); c->x86_cache_size=(ecx>>24)+(edx>>24); + c->x86_L1I_size = edx>>24; + c->x86_L1D_size = ecx>>24; } if (n < 0x8006) /* Some chips just has a large L1. */ @@ -1133,6 +1139,7 @@ return; /* Again, no L2 cache is possible */ c->x86_cache_size = l2size; + c->x86_L2_size = ecx >> 16; printk(KERN_INFO "CPU: L2 Cache: %dK (%d bytes/line)\n", l2size, ecx & 0xFF); @@ -1883,6 +1890,8 @@ cpuid(0x8005,&aa,&bb,&cc,&dd); /* Add L1 data and code cache sizes. */ c->x86_cache_size = (cc>>24)+(dd>>24); + c->x86_L1I_size = cc>>24; + c->x86_L1D_size = dd>>24; } sprintf( c->x86_model_id, "WinChip %s", name ); mcheck_init(c); @@ -2141,6 +2150,10 @@ * SMP switching weights. */ c->x86_cache_size = l2 ? l2 : (l1i+l1d); + if(l1i) c->x86_L1I_size = l1i; + if(l1d) c->x86_L1D_size = l1d; + if(l2) c->x86_L2_size = l2; + if(l3) c->x86_L3_size = l3; } /* SEP CPUID bug: Pentium Pro reports SEP but doesn't have it */ @@ -2446,6 +2459,10 @@ c->loops_per_jiffy = loops_per_jiffy; c->x86_cache_size = -1; + c->x86_L1D_size = -1; + c->x86_L1I_size = -1; + c->x86_L2_size = -1; + c->x86_L3_size = -1; c->x86_vendor = X86_VENDOR_UNKNOWN; c->cpuid_level = -1;/* CPUID not detected */ c->x86_model = c->x86_mask = 0; /* So far unknown... */ @@ -2736,9 +2753,17 @@ cpu_khz / 1000, (cpu_khz % 1000)); } - /* Cache size */ + /* Cache size(s) */ if (c->x86_cache_size >= 0) p += sprintf(p, "cache size\t: %d KB\n", c->x86_cache_size); + if (c->x86_L1I_size >= 0) + p += sprintf(p, "L1-I cache size\t: %d KB\n", c->x86_L1I_size); + if (c->x86_L1D_size >= 0) + p += sprintf(p, "L1-D cache size\t: %d KB\n", c->x86_L1D_size); + if (c->x86_L2_size >= 0) + p += sprintf(p, "L2 cache size\t: %d KB\n", c->x86_L2_size); + if (c->x86_L3_size >= 0) + p += sprintf(p, "L3 cache size\t: %d KB\n", c->x86_L3_size); /* We use exception 16 if we have hardware math and we've either seen it or the CPU claims it is internal */ fpu_exception = c->hard_math && (ignore_irq13 || cpu_has_fpu); --- linux-2.4.4-ac11.orig/include/asm-i386/processor.h Mon May 21 14:16:20 2001 +++ linux-2.4.4-ac11/include/asm-i386/processor.h Mon May 21 09:01:21 2001 @@ -44,6 +44,10 @@ charx86_model_id[64]; int x86_cache_size; /* in KB - valid for CPUS which support this call */ + int x86_L1D_size; + int x86_L1I_size; + int x86_L2_size; + int x86_L3_size; __u16 clockmul;/* Clock multiplier */ int fdiv_bug; int f00f_bug; Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 C+ITS|Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at htt
Re: 2.4.5 VM
Hi, first of all, I am not complaining, or calling things buggy. I know that what I am running is "work in progress" and that one gets what one deserves :-) 2.4.x has been stable for me and given me no severe problem besides the changed pcmcia/cardbus support somewhere in 2.4.4-acx Just let me add my observation. The VM behaviour of 2.4.5 (started with some 2.4.4-ac kernel) is definitely less than an improvement for *my* setup. I am running a Thinkpad570 with 128 MB memory and about the same amount of swap (I know, against reccomendation). Under the new VM behaviour, I easily get in a situation where the system feels very sluggish. At that point in time, about 70-80% of memory are Cache, the rest is Used and some small amount of free. Swap is usually less than half filled and paging activity is about zero (some sporadic page out). Typical case is a kernel build plus a Netscape session. No unusal behaviour showing up in "top" - just sluggish system response. My gut feeling is that the Cache is pressing to hard against process memory. This may be great for some setups, but it is not good for others (like mine). What would be great (maybe someone is already working on it) are some tuning measures to tweak the cacheing behaviour. Just my 2 (Euro-)cents. Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 C+ITS|Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM suggestion...
>While you guys are in there hacking, perhaps consider adding metrics >which allows you to tell exactly when certain cases and conditions are >hit. >page_aged_while_sleeping_in_page_lauder++ > >Statistics like this are cheap to use in runtime and should provide >concrete information rather than guesses and estimations... after following the several [very entertaining/enlightening] threads on VM [mis]behaviour, I wanted to ask a similar question: are there any counters/statistics about the various buffers/caches in the VMS system, that are easily available to userland? I know other Unix OSSes, where you can get a lot of information about the efficiency of the subsystem. Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 C+ITS|Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 begin:vcard n:Knoblauch;Martin tel;cell:+49-170-4904759 tel;fax:+49-89-510857-111 tel;work:+49-89-510857-309 x-mozilla-html:FALSE url:http://www.teraport.de org:TeraPort GmbH;C+ITS adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany version:2.1 email;internet:[EMAIL PROTECTED] title:Senior System Engineer x-mozilla-cpt:;-7008 fn:Martin Knoblauch end:vcard
VM: Buffer vs. Cache
Hi, just being curious. Since 2.4.4, I am watching my systems memory behaviour a bit:-) Just recently I realized the following: in the evening I leave my 128MB system at about 20 MB, 2 MB Buffered and 100 MB Cached (plus som 40 MB unneccesary swap :-)). When I come back in the morning, Used is still at 20 MB (a bit down maybe) but Buffered is 50 MB and Cached is 55 MB. For a few minutes the system is definitely more sluggish than in the evening. Something I can excuse before my first cup of coffe anyway... So, what actually is the difference between Buffered and Cached. Apparently quite a lot of the pages that are Cached in the evening are Buffered 9 houres later. Thanks Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 C+ITS|Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 begin:vcard n:Knoblauch;Martin tel;cell:+49-170-4904759 tel;fax:+49-89-510857-111 tel;work:+49-89-510857-309 x-mozilla-html:FALSE url:http://www.teraport.de org:TeraPort GmbH;C+ITS adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany version:2.1 email;internet:[EMAIL PROTECTED] title:Senior System Engineer x-mozilla-cpt:;-7008 fn:Martin Knoblauch end:vcard
Re: VM: Buffer vs. Cache
Jonathan Morton wrote: > > > > > So, what actually is the difference between Buffered and Cached. > >Apparently quite a lot of the pages that are Cached in the evening are > >Buffered 9 houres later. > > Think about what happens in the meantime. Most distros install maintenance > scripts which run late at night (usually at midnight and/or 4am), which > perform heavy disk activity as they update databases and scan for > file-permissions security holes. Heavy disk activity usually means an > increase in buffer utilisation. Since most files are only "touched" once, > the cache is shrunk as it aren't being used very much. > thanks to all who set me straight. Should have thought of the nightly stuff myself. Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 C+ITS|Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pcmcia problems after upgrading from 2.4.3-ac7 to 2.4.4
Hi, my DE-620 pccard stopped working after upgrading the kernel from 2.4.3-ac7 to 2.4.4. This is on a Toshiba 4080XCDT. I used the "good" .config from the 2.4.3-ac7 build to do a make "oldconfig". The symptoms at startup are: >PCMCIA: Starting services: >PCMCIA: using scheme: SuSE >/lib/modules/2.4.4/kernel/drivers/pcmcia/i82365.o: init_module: No such device >Hint: insmod errors can be caused by incorrect module parameters, including invalid >IO or IRQ >parameters >/lib/modules/2.4.4/kernel/drivers/pcmcia/i82365.o: insmod >>/lib/modules/2.4.4/kernel/drivers/pcmcia/i82365.o failed >/lib/modules/2.4.4/kernel/drivers/pcmcia/i82365.o: insmod i82365 failed >/lib/modules/2.4.4/kernel/drivers/pcmcia/ds.o: init_module: Operation not permitted >/lib/modules/2.4.4/kernel/drivers/pcmcia/ds.o: insmod >>/lib/modules/2.4.4/kernel/drivers/pcmcia/ds.o failed >/lib/modules/2.4.4/kernel/drivers/pcmcia/ds.o: insmod ds failed >cardmgr[189]: starting, version is 3.1.22 >PCMCIA: cardmanager is running >cardmgr[189]: no pcmcia driver in /proc/devices >cardmgr[189]: exiting As I said, worked fine until/including 2.4.3-ac7. Any ideas? And before I forget, the base System is SuSe7.1 and all the packages mentioned in Documentation/Changes are at the required (or better) levels. Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 IT Services |Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 begin:vcard n:Knoblauch;Martin tel;cell:+49-170-4904759 tel;fax:+49-89-510857-111 tel;work:+49-89-510857-309 x-mozilla-html:FALSE url:http://www.teraport.de org:TeraPort GmbH;IT-Services adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany version:2.1 email;internet:[EMAIL PROTECTED] title:Senior System Engineer x-mozilla-cpt:;32160 fn:Martin Knoblauch end:vcard
Re: pcmcia problems after upgrading from 2.4.3-ac7 to 2.4.4
Alan Cox wrote: > > > my DE-620 pccard stopped working after upgrading the kernel from > > 2.4.3-ac7 to 2.4.4. This is on a Toshiba 4080XCDT. I used the "good" > > .config from the 2.4.3-ac7 build to do a make "oldconfig". The symptoms > > at startup are: > > 2.4.4 has older pcmcia than 2.4.3-ac7. It might be that. Does 2.4.4-ac work ? Alan, thanks for replying. Which 2.4.4-ac would you recommend? BUT, I actually think that the pcmcia stuff broke already in the 2.4.3-ac series at 9 or 10. At that point, I was to busy reporting it :-( Doing new kernels on my notebook is kind of low priority... I had the impression that either the rwsem or the pnpbios stuff was involved. As I said, I did not follow up at that time. Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 IT Services |Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 begin:vcard n:Knoblauch;Martin tel;cell:+49-170-4904759 tel;fax:+49-89-510857-111 tel;work:+49-89-510857-309 x-mozilla-html:FALSE url:http://www.teraport.de org:TeraPort GmbH;IT-Services adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany version:2.1 email;internet:[EMAIL PROTECTED] title:Senior System Engineer x-mozilla-cpt:;32160 fn:Martin Knoblauch end:vcard
Re: pcmcia problems after upgrading from 2.4.3-ac7 to 2.4.4
Alan Cox wrote: > > > my DE-620 pccard stopped working after upgrading the kernel from > > 2.4.3-ac7 to 2.4.4. This is on a Toshiba 4080XCDT. I used the "good" > > .config from the 2.4.3-ac7 build to do a make "oldconfig". The symptoms > > at startup are: > > 2.4.4 has older pcmcia than 2.4.3-ac7. It might be that. Does 2.4.4-ac work ? just some additional info. The card actually stopped working in 2.4.3-a11 upwards with the same symptoms as in my original request. 2.4.3-ac9 is the last working one. Not sure about -ac10, because that one crashes during boot (not related to pcmcia as far as I can remember). So, what was added in ac11 or ac10 that could hurt pcmcia or the i82365 module? I'll now try 2.4.4-ac4. Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 IT Services |Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 begin:vcard n:Knoblauch;Martin tel;cell:+49-170-4904759 tel;fax:+49-89-510857-111 tel;work:+49-89-510857-309 x-mozilla-html:FALSE url:http://www.teraport.de org:TeraPort GmbH;IT-Services adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany version:2.1 email;internet:[EMAIL PROTECTED] title:Senior System Engineer x-mozilla-cpt:;32160 fn:Martin Knoblauch end:vcard
Re: pcmcia problems after upgrading from 2.4.3-ac7 to 2.4.4
"Martin.Knoblauch" wrote: > > Alan Cox wrote: > > > > > my DE-620 pccard stopped working after upgrading the kernel from > > > 2.4.3-ac7 to 2.4.4. This is on a Toshiba 4080XCDT. I used the "good" > > > .config from the 2.4.3-ac7 build to do a make "oldconfig". The symptoms > > > at startup are: > > > > 2.4.4 has older pcmcia than 2.4.3-ac7. It might be that. Does 2.4.4-ac work ? > > just some additional info. The card actually stopped working in > 2.4.3-a11 upwards with the same symptoms as in my original request. > > 2.4.3-ac9 is the last working one. Not sure about -ac10, because that > one crashes during boot (not related to pcmcia as far as I can > remember). So, what was added in ac11 or ac10 that could hurt pcmcia or > the i82365 module? > > I'll now try 2.4.4-ac4. > done. Unfortunatelly, it fails with the same symptoms as posted initially. Thanks Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 IT Services |Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 begin:vcard n:Knoblauch;Martin tel;cell:+49-170-4904759 tel;fax:+49-89-510857-111 tel;work:+49-89-510857-309 x-mozilla-html:FALSE url:http://www.teraport.de org:TeraPort GmbH;IT-Services adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany version:2.1 email;internet:[EMAIL PROTECTED] title:Senior System Engineer x-mozilla-cpt:;32160 fn:Martin Knoblauch end:vcard
[Solved ?] Re: pcmcia problems after upgrading from 2.4.3-ac7 to 2.4.4
Alan Cox wrote: > > > my DE-620 pccard stopped working after upgrading the kernel from > > 2.4.3-ac7 to 2.4.4. This is on a Toshiba 4080XCDT. I used the "good" > > .config from the 2.4.3-ac7 build to do a make "oldconfig". The symptoms > > at startup are: > > 2.4.4 has older pcmcia than 2.4.3-ac7. It might be that. Does 2.4.4-ac work ? Hi, after some experimenting, I found a solution that works for me. Looking at the README-2.4 file for the pcmcia-cs package, I found that there is a strong advice AGAINST using the i82365 module when runnung 2.4.x kernels. Instead yenta_sockets should be specified. I changed that and guess what - pcmcia is working again for me. I am not sure whether this should be closed alltogether. Maybe i82365 was not the proper choice for my hardware in the first place. Anyway, the module seems to be retired as of 2.4.3-ac10/ac11. Maybe a hint should go into the changes document. Thanks for the patience Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 IT Services |Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 begin:vcard n:Knoblauch;Martin tel;cell:+49-170-4904759 tel;fax:+49-89-510857-111 tel;work:+49-89-510857-309 x-mozilla-html:FALSE url:http://www.teraport.de org:TeraPort GmbH;IT-Services adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany version:2.1 email;internet:[EMAIL PROTECTED] title:Senior System Engineer x-mozilla-cpt:;32160 fn:Martin Knoblauch end:vcard
Re: [Solved ?] Re: pcmcia problems after upgrading from 2.4.3-ac7 to 2.4.4
David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > > > I am not sure whether this should be closed alltogether. Maybe > > i82365 was not the proper choice for my hardware in the first place. > > Anyway, the module seems to be retired as of 2.4.3-ac10/ac11. Maybe a > > hint should go into the changes document. > > i82365 is for use only on PCMCIA bridges, not CardBus. It should not be > 'retired' but should probably have the config option renamed to prevent > confusion. > good idea. maybe the token "bridge" should appear in both the Cardbus and PCMCIA case. It *may* have brought me on track a bit earlier :-) It was also confusing, that the i82365 module worked [for me] until/including 2.4.3-ac9. Anyway, the story just shows that reading the docs helps from time to time. :-) Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 IT Services |Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 begin:vcard n:Knoblauch;Martin tel;cell:+49-170-4904759 tel;fax:+49-89-510857-111 tel;work:+49-89-510857-309 x-mozilla-html:FALSE url:http://www.teraport.de org:TeraPort GmbH;IT-Services adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany version:2.1 email;internet:[EMAIL PROTECTED] title:Senior System Engineer x-mozilla-cpt:;32160 fn:Martin Knoblauch end:vcard
Size of /proc/kcore growing over time ?
Hi, is it normal that the size of /proc/kcore grows over time? Directly after a boot it has the size of the physical memory. Over time it seems to grow slightly. In about a day it went from 192 MB to about 203 MB. This is 2.4.4-ac6 running on a Toshiba Notebook. I ask, because I thought the size of kproc could be used to determine the amount of physical memory. If this assumption is wrong, is there another way to achive the goal? Happy weekend Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 IT Services |Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 begin:vcard n:Knoblauch;Martin tel;cell:+49-170-4904759 tel;fax:+49-89-510857-111 tel;work:+49-89-510857-309 x-mozilla-html:FALSE url:http://www.teraport.de org:TeraPort GmbH;IT-Services adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany version:2.1 email;internet:[EMAIL PROTECTED] title:Senior System Engineer x-mozilla-cpt:;32160 fn:Martin Knoblauch end:vcard
Re: Size of /proc/kcore growing over time ?
"J . A . Magallon" wrote: > > On 05.11 Martin.Knoblauch wrote: > > > > I ask, because I thought the size of kproc could be used to determine > > the amount of physical memory. If this assumption is wrong, is there > > another way to achive the goal? > > > > #include // for get_phys_pages() > #include // for getpagesize() > > ram = get_phys_pages()*getpagesize(); > Close, but not there :-) What I want is the total physical memory in the system. Above seems to report only the physical pages available to the kernel. Thanks anyway Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 IT Services |Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 begin:vcard n:Knoblauch;Martin tel;cell:+49-170-4904759 tel;fax:+49-89-510857-111 tel;work:+49-89-510857-309 x-mozilla-html:FALSE url:http://www.teraport.de org:TeraPort GmbH;IT-Services adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany version:2.1 email;internet:[EMAIL PROTECTED] title:Senior System Engineer x-mozilla-cpt:;32160 fn:Martin Knoblauch end:vcard
make menuconfig - cosmetic question
Hi, this is most likely just a small issue. If I knew where to look, I would try to fix it and submit a patch :-) When I diff config files pocessed by "make [old]config" and "make menueconfig", it seems that menuconfig is not writing out some of the "comments" that the other versions do write. This is of course nothing serious, but it ticks me off. Any idea where to look for this glitch? Thanks Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 IT Services |Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 begin:vcard n:Knoblauch;Martin tel;cell:+49-170-4904759 tel;fax:+49-89-510857-111 tel;work:+49-89-510857-309 x-mozilla-html:FALSE url:http://www.teraport.de org:TeraPort GmbH;IT-Services adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany version:2.1 email;internet:[EMAIL PROTECTED] title:Senior System Engineer x-mozilla-cpt:;32160 fn:Martin Knoblauch end:vcard
Re: make menuconfig - cosmetic question
Bjorn Wesen wrote:
>
> While we're on cosmetics... how about imprisonment for the person who
> chose yellow on light grey for the first letters in each option...
>
> /Bjorn
>
> On Thu, 17 May 2001, Martin.Knoblauch wrote:
> > this is most likely just a small issue. If I knew where to look, I
> > would try to fix it and submit a patch :-)
> >
> > When I diff config files pocessed by "make [old]config" and "make
> > menueconfig", it seems that menuconfig is not writing out some of the
> > "comments" that the other versions do write. This is of course nothing
> > serious, but it ticks me off. Any idea where to look for this glitch?
Now, changing that color is simple. Just change the value of TAG_KEY_FG
in scripts/lxdialog/colors.h. Unfortunatelly, this is not a question of
cosmetics, but taste. And I do not want to go into that :-)
After some browsing around the Menuconfig script and not really
understanding how it works :-), I found the line to change. At least now
the config files look identical when processed with menuconfig (except
the fisrt comment, of course):
--- linux/Scripts/Menuconfig.orig Thu May 17 17:19:21 2001
+++ linux/scripts/Menuconfig Thu May 17 17:17:25 2001
@@ -1250,7 +1250,7 @@
function comment () {
if [ "$comment_is_option" ]
then
- comment_is_option=
+ comment_is_option=TRUE
echo>>$CONFIG
echo "#">>$CONFIG
echo "# $1" >>$CONFIG
Not sure whether this is worth to put into the next release - maybe
someone can spend two minutes to crosscheck.
Martin
PS: Sorry for the MIME. Should not have happend :-( Hope it is better
now.
--
--
Martin Knoblauch |email: [EMAIL PROTECTED]
TeraPort GmbH|Phone: +49-89-510857-309
IT Services |Fax:+49-89-510857-111
http://www.teraport.de |Mobile: +49-170-4904759
begin:vcard
n:Knoblauch;Martin
tel;cell:+49-170-4904759
tel;fax:+49-89-510857-111
tel;work:+49-89-510857-309
x-mozilla-html:FALSE
url:http://www.teraport.de
org:TeraPort GmbH;IT-Services
adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany
version:2.1
email;internet:[EMAIL PROTECTED]
title:Senior System Engineer
x-mozilla-cpt:;32160
fn:Martin Knoblauch
end:vcard
Re: make menuconfig - cosmetic question
"Martin.Knoblauch" wrote:
>
>
> Not sure whether this is worth to put into the next release - maybe
> someone can spend two minutes to crosscheck.
>
This looks more complete.
lx/linux > diff -u scripts/Menuconfig.orig scripts/Menuconfig
--- scripts/Menuconfig.orig Thu May 17 17:19:21 2001
+++ scripts/Menuconfig Thu May 17 18:10:22 2001
@@ -74,7 +74,10 @@
# - Implemented new functions: define_tristate(), define_int(),
define_hex(),
# define_string(), dep_bool().
#
-
+# 17 May 2001, Martin Knoblauch, <[EMAIL PROTECTED]>
+# - Fix output of comment strings to .config/autoconfig.h so that they
equal
+# the comments from "make [old]config"
+#
#
# Change this to TRUE if you prefer all kernel options listed
@@ -1240,7 +1243,7 @@
}
function mainmenu_option () {
- comment_is_option=TRUE
+ :
}
function endmenu () {
@@ -1248,9 +1251,7 @@
}
function comment () {
- if [ "$comment_is_option" ]
- then
- comment_is_option=
+
echo>>$CONFIG
echo "#">>$CONFIG
echo "# $1" >>$CONFIG
@@ -1260,7 +1261,6 @@
echo "/*">>$CONFIG_H
echo " * $1" >>$CONFIG_H
echo " */" >>$CONFIG_H
- fi
}
echo -n "."
Martin
PS: This time without vcard ...
--
--
Martin Knoblauch |email: [EMAIL PROTECTED]
TeraPort GmbH|Phone: +49-89-510857-309
IT Services |Fax:+49-89-510857-111
http://www.teraport.de |Mobile: +49-170-4904759
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Cosmetic problem in Documentation/Changes [2.4.x]
Hi, apparently the method to find out the version of the reiserfs[progs] mentioned in above file does not produce any result at all. # reiserfsck 2>&1|grep reiserfsprogs reports nothing. If I look at the output "manually", there does not seem to be any version in there. Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 IT Services |Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ReiserFs: Cosmetic problem in linux/Documentation/Changes [2.4.x]
Hi, I submitted this a short while ago, only to realize later that the subject line was not very informative. Sorry. As a suggestion: maybe the reiser-tools should support the common -V/--version flag Martin "Martin.Knoblauch" wrote: > > Hi, > > apparently the method to find out the version of the reiserfs[progs] > mentioned in above file does not produce any result at all. > > # reiserfsck 2>&1|grep reiserfsprogs > > reports nothing. If I look at the output "manually", there does not > seem to be any version in there. > -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 IT Services |Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ReiserFs: Cosmetic problem in linux/Documentation/Changes [2.4.x]
"Martin.Knoblauch" wrote: > > Hi, > > I submitted this a short while ago, only to realize later that the > subject line was not very informative. Sorry. > > As a suggestion: maybe the reiser-tools should support the common > -V/--version flag > > Martin > just forget it. Bad day probably. SuSe 7.1 installed a pretty old version of the tools that were not called "reiserfsprogs". And apparently I did not see that version string <---MKREISERFS, 2000---> ReiserFS version 3.5.29 Still, there should be a more convenient way to extract the version :-) Sorry Martin -- -- Martin Knoblauch |email: [EMAIL PROTECTED] TeraPort GmbH|Phone: +49-89-510857-309 IT Services |Fax:+49-89-510857-111 http://www.teraport.de |Mobile: +49-170-4904759 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
