Re: page_launder() bug
Marcelo Tosatti writes: Hmmm, can't this happen without my patch? No. We will never call writepage() without __GFP_IO without your patch. I see, because launder_loop never progresses to 1 in that case. My patch is crap and can cause corruptions, there is not argument about it now :-) Later, David S. Miller [EMAIL PROTECTED] - 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: CML2 design philosophy heads-up
On Sun, May 06, 2001 at 01:58:49PM +0100, Alan Cox wrote: # These were separate questions in CML1 derive MAC_SCC from MAC SERIAL derive MAC_SCSI from MAC SCSI derive SUN3_SCSI from (SUN3 | SUN3X) SCSI Not all Mac's use the SCC if they have serial Not all Mac's use the same SCSI controller Yes, but in this case 'MAC' means m68k mac, which this _might_ be valid, but I never did get Linux up and running on the m68ks I had.. But Alan's point is a good one. There are _lots_ of cases you can't get away with things like this, unless you get very fine grained. In fact, it would be much eaiser to do this seperately from the kernel. Ie another, possibly/probably _not_ inkernel config tool which asks what machine you have, picks lots of sane defaults and setups a kernel config for you. This is _sort of_ what PPC does right now with the large number of 'default configs' (arch/ppc/configs). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: CML2 design philosophy heads-up
Tom Rini [EMAIL PROTECTED]: Only sort-of. There are some cases where you can get away with that. Probably. eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC, always (right?) Yes. So the right answer there isn't to use a derivation but to say: require X86 and PARPORT implies PARPORT_PC unless X86==n suppress PARPORT_PC which forces PARPORT_PC==y and makes the question invisible on X86 machines, but leaves the question visible on all others. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The real point of audits is to instill fear, not to extract revenue; the IRS aims at winning through intimidation and (thereby) getting maximum voluntary compliance -- Paul Strassel, former IRS Headquarters Agent Wall St. Journal 1980 - 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: page_launder() bug
Linus Torvalds writes: YOUR HEURISTIC IS WRONG! Please start the conversation this way next time. I call that a bug. You don't. Fine. You made it sound like a data corrupter, a kernel crasher, and that any bug against a kernel with that patch indicates my patch caused it. There is an important distinction between this is doing something silly and this will scramble your disk and crash the kernel. The latter is the conclusion several people came to. And I wanted a clarification on this, nothing more. I wanted this clarification from you _BECAUSE_ the original posting in this thread saw data corruption which went away after reverting my patch. But there is no possible connection between my patch and the crashes he saw. Many people have already concluded that Linus says davem's patch is crap so it must have been causing the corruptions of the original reporter. Like you and I, most people are lazy. And a lazy person is likely to treat bug goes away with reverting patch plus Linus says the patch is crap as get rid of the patch, this'll fix the bug. And that'll be the end of it, nobody will investigate the true cause of the problem until it shows up again later for some different reason. But that code isn't coming anywhere _close_ to my tree until the two match. And I stand by my assertion that it should be reverted from Alans tree too. I have no intent to ever submit that patch to your tree, I know it's not the right way to solve this problem. In fact I submitted that patch to you as an [RFC] a long time ago and it fell on deaf ears. Or perhaps you happened to have laser eye surgery that particular day, who knows. :-) Later, David S. Miller [EMAIL PROTECTED] - 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] zero^H^H^H^Hsingle copy pipe
Ben LaHaise writes: and then use a map_mm_kiobuf (which is map_user_kiobuf but with an mm parameter) for the portion of the buffer that's currently being copied. That improves code reuse and gives us a few primatives that are quite useful elsewhere. If it has roughly the same cost as Manfred's copy_user thing, it is therefore roughly equivalent. If this map_mm_kiobuf() thing would cost more (I think it would because it would be using kiobufs when for this case there is absolutely no need for them) then why? It's a clean interface everyone can use is not an acceptable answer when the clean interface costs significantly more than the straightforward approach. Later, David S. Miller [EMAIL PROTECTED] - 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: SPARC include problem
Sean Jones writes: In compiling 2.4.4-ac5 for my SPARCStation 20, I had an error in the compile resulting from the inability to find a hw_irq.h in the include/asm directory. Do you know where I may be able to find such a file? How did you find this problem if the build couldn't find the bzImage rule? :-) Later, David S. Miller [EMAIL PROTECTED] - 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: page_launder() bug
Linus Torvalds writes: What do you expect me to do? The patch is buggy. It should be reverted. What's your problem? I think the problem he has is that you are acting as if the patch causes corruptions and will end in failures. This is how you are coming across, at least. Really, your problem with the patch seems to be aesthetic in nature and that the patch is not doing things cleanly at all. To this I will not contest, it surely is not the way to fix this in the end. If my analysis up to this point is correct, the patch should in fact not be reverted. Many patches in Alan's tree are not done in the most aesthetically pleasing way to you, we all know this. But they do solve problems for people. Half of Alan's tree should be reverted if we followed this rule, really. Later, David S. Miller [EMAIL PROTECTED] - 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: page_launder() bug
Marcelo Tosatti writes:
My point is that its _ok_ for us to check if the page is a dead swap cache
page _without_ the lock since writepage() will recheck again with the page
_locked_. Quoting you two messages back:
But it is important to re-calculate the deadness after getting the lock.
Before, it was just an informed guess. After the lock, it is knowledge.
See ?
In fact my patch isn't changing writepage behavior wrt. that page, it
is changing behavior with respect to laundering policy for that page.
Here, let's talk code a little bit so there are no misunderstandings,
I really want to put this to rest:
+ int dead_swap_page;
+
page = list_entry(page_lru, struct page, lru);
+ dead_swap_page =
+ (PageSwapCache(page)
+page_count(page) == (1 + !!page-buffers));
+
Calculate dead_swap_page outside of lock.
/* Page is or was in use? Move it to the active list. */
- if (PageTestandClearReferenced(page) || page-age 0 ||
- (!page-buffers page_count(page) 1) ||
- page_ramdisk(page)) {
+ if (!dead_swap_page
+ (PageTestandClearReferenced(page) || page-age 0 ||
+(!page-buffers page_count(page) 1) ||
+page_ramdisk(page))) {
del_page_from_inactive_dirty_list(page);
add_page_to_active_list(page);
continue;
If dead_swap_page, ignore referenced bit heuristics.
- /* First time through? Move it to the back of the list */
- if (!launder_loop) {
+ /* First time through? Move it to the back of the list,
+* but not if it is a dead swap page. We want to reap
+* those as fast as possible.
+*/
+ if (!launder_loop !dead_swap_page) {
list_del(page_lru);
list_add(page_lru, inactive_dirty_list);
UnlockPage(page);
If dead_swap_page, ignore launder_loop. Again, another heuristic
test, not a state correctness test. launder_loop is not
protecting state correctness of what we do to the page.
Really, what does this have to do with swap counts and page counts?
It's a heuristic. In fact it even seems stupid to me to recalculate
dead_swap_page after we get the lock just for the sake of these
heuristics.
Maybe I should have diguised this bit as:
if (dead_swap_page)
do_writepage_first_pass = 1;
To divert people's brains to what the intent was :-)
Later,
David S. Miller
[EMAIL PROTECTED]
-
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: page_launder() bug
On Monday 07 May 2001 08:26, Tobias Ringstrom wrote: On Sun, 6 May 2001, David S. Miller wrote: It is the most straightforward way to make a '1' or '0' integer from the NULL state of a pointer. But is it really specified in the C standards to be exctly zero or one, and not zero and non-zero? Yes, and if we did not have this stupid situation where the C language standard is not freely available online then you would not have had to ask./rant IMHO, the ?: construct is way more readable and reliable. There is no difference in reliability. Readability is a matter of opinion - my opinion is that they are equally readable. To its credit, gcc produces the same ia32 code in either case: int foo = 999; return 1 + !!foo; main+6: movl $0x3e7,0xfffc(%ebp) main+13: cmpl $0x0,0xfffc(%ebp) main+17: je 0x80483e0 main+32 main+19: mov$0x2,%eax main+24: jmp0x80483e5 main+37 main+26: lea0x0(%esi),%esi main+32: mov$0x1,%eax main+37: mov%eax,%eax int foo = 999; return foo? 2: 1; main+6: movl $0x3e7,0xfffc(%ebp) main+13: cmpl $0x0,0xfffc(%ebp) main+17: je 0x80483e0 main+32 main+19: mov$0x2,%eax main+24: jmp0x80483e5 main+37 main+26: lea0x0(%esi),%esi main+32: mov$0x1,%eax main+37: mov%eax,%eax -- Daniel - 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: page_launder() bug
Linus Torvalds writes: On Mon, 7 May 2001, Marcelo Tosatti wrote: And thats what swap_writepage() is doing: Ehh.. swap_writepage() is called with the page locked. So it _can_ depend on it. If the page isn't locked there, then THAT is a bug. A major one. Linus, he's trying to point out that writepage() will recheck (under lock) what you think my dead_swap_page thing is not checking :-) My changes always call writepage() and always redo all the checks under the proper locks. Later, David S. Miller [EMAIL PROTECTED] - 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: page_launder() bug
Marcelo Tosatti writes: I just thought about this case: We find a dead swap cache page, so dead_swap_page goes to 1. We call swap_writepage(), but in the meantime the swapin readahead code got a reference on the swap map for the page. We write the page out because (swap_count(page) 1), and we may not have __GFP_IO set in the gfp_mask. Boom. Hmmm, can't this happen without my patch? Nothing stops people from getting references to the page between the Page is or was in use? test and the line which does TryLockPage(page). Later, David S. Miller [EMAIL PROTECTED] - 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: Compiling on a SPARC
Try make vmlinux Later, David S. Miller [EMAIL PROTECTED] - 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: page_launder() bug
David S. Miller [EMAIL PROTECTED] said: Jonathan Morton writes: - page_count(page) == (1 + !!page-buffers)); Two inversions in a row? It is the most straightforward way to make a '1' or '0' integer from the NULL state of a pointer. IMVHO, it is clearer to write: page_count(page) == 1 + (page-buffers != NULL) At least, the original poster wouldn't have wondered, and I wouldn't have had to think a bit to find out what it meant... If gcc generates worse code for this, it should be fixed. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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: page_launder() bug
On Mon, 7 May 2001, Marcelo Tosatti wrote:
So what about moving the check for a dead swap cache page from
swap_writepage() to page_launder() (+ PageSwapCache() check) just before
the if (!launder_loop) ?
Yes, its ugly special casing. Any other suggestion ?
My most favourite approach by far is to just remove the magic for
different writepage's altogether, and just unconditionally do a
writepage. But passing in enough information so that the writepage can
come to the right decision.
So take the old code, and remove the code that does
if (!launder_loop) {
.. move to head ..
continue;
}
writepage(page);
and instead make it do something like
if (writepage(page, launderloop)) {
.. not able to write, move to head ..
continue;
}
where launderloop is passed in to the writepage function as a priority.
Then, a regular writepage() would just do
if (!priority)
return -1;
.. do real writepage here ..
return 0;
while the special casing of dead swap cache entries can be moved into
swap_writepage() (which would do the above _too_, but would first try to
just drop the page if it can tell that the page is dead).
Now, add in the whole accessed recently as part of the priority (ie a
page that had the PG_referenced bit set will always get a priority 0,
even if we could have laundered it, because we don't actually want to
write it out all that badly), and I think you'll get to where David wanted
to get _without_ any special cases.
In fact, it might even clean stuff up. Who knows? At least
page_launder() would not need to know about magic dead swap pages, because
the decision would be entirely in writepage().
And there aren't that many writepage() implementations in the kernel to
fix up (and the fixup tends to be two simple added lines of code for most
of them - just the if (!priority) return).
Also note how some filesystems might use the writepage() callback even
with a zero priority as a hint that things are approaching the point where
we need to start flushing, which might make a difference for deciding when
to try to write a log entry, for example.
Now, I'm not saying this is _the_ solution to it, but I don't see any
really clean alternatives.
Linus
-
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: page_launder() bug
On Mon, 7 May 2001, David S. Miller wrote: Here, let's talk code a little bit so there are no misunderstandings, I really want to put this to rest: Calculate dead_swap_page outside of lock. NO. That's not what you're doing at all. You're calculating something completely different that dead swap page. You're calculating do we have a swap cache entry that is not mapped into any virtual memory? If dead_swap_page, ignore referenced bit heuristics. Which is complete crap. Those reference bits are valid and important data. You have not computed anything that says otherwise. You have computed a random number that doesn't tell you anything about whether the page is dead or not. Really, what does this have to do with swap counts and page counts? It's a heuristic. In fact it even seems stupid to me to recalculate dead_swap_page after we get the lock just for the sake of these heuristics. YOUR HEURISTIC IS WRONG! Maybe I should have diguised this bit as: if (dead_swap_page) do_writepage_first_pass = 1; So tell me: what does the above help? I repeat: your dead_swap_page variable is a random number with absolutely no meaning. ANYTHING that uses it is buggy. It doesn't help in the least if you use the first random state to set another random state: the amount of randomness does not increase or decrease. See? To divert people's brains to what the intent was :-) I can see the intent. I can also see that the code doesn't match up to the intent. I call that a bug. You don't. Fine. But that code isn't coming anywhere _close_ to my tree until the two match. And I stand by my assertion that it should be reverted from Alans tree too. Linus - 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: page_launder() bug
On Sun, 6 May 2001, David S. Miller wrote: It is the most straightforward way to make a '1' or '0' integer from the NULL state of a pointer. But is it really specified in the C standards to be exctly zero or one, and not zero and non-zero? IMHO, the ?: construct is way more readable and reliable. /Tobias - 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/
scripts/Configure patch for automatic module compile
Hi,
If you're like me, you build everything as modules, boot with an initrd that
loads in the disk or net driver and filesystem module, and then let kmod take
care of the rest. Here's a patch that changes Configure (make config) to
build all possible modules - in other words, to answer 'M' for every tristate
of some form y/m/n. It also allows some tristates to be built into the
kernel (y), so you can have a root filesystem and executables. This is done
by changing tristates in arch/${ARCH}/defconfig to default to 'a'. For
instance:
CONFIG_BINFMT_ELF=a
CONFIG_BLK_DEV_RAM=a
CONFIG_CRAMFS=a
I am posting the patch in the hope that someone finds it useful or uses it
perhaps as inspiration for a better solution. Eventually, I'd like to cut
down the config process to a short list of questions about CPU, bus, network,
and then get all the modules automatically.
Caveats: hmm.. well, it's only tested on i386, though I don't see why it
wouldn't work on anything else. If you're not running some kind of embedded
system, the defconfig must be changed or the kernel won't be very useful. Of
course, this only works with 'make config' - 'menuconfig' and 'xconfig' are
unchanged.
Maciek
--- Configure.old Sun May 6 22:28:07 2001
+++ Configure Mon May 7 00:07:32 2001
@@ -155,6 +155,7 @@
m)
echo $1=m $CONFIG
+ echo $1=m
echo #undef $1 $CONFIG_H
echo #define $1_MODULE 1 $CONFIG_H
;;
@@ -207,26 +208,11 @@
old=$(eval echo \${$2})
def=${old:-'n'}
case $def in
- y) defprompt=Y/m/n/?
+ a) define_tristate $2 y
;;
- m) defprompt=M/n/y/?
- ;;
- n) defprompt=N/y/m/?
+ * ) define_tristate $2 m
;;
esac
- while :; do
- readln $1 ($2) [$defprompt] $def $old
- case $ans in
- [yY] | [yY]es ) define_tristate $2 y
- break ;;
- [nN] | [nN]o ) define_tristate $2 n
- break ;;
- [mM] ) define_tristate $2 m
- break ;;
- * ) help $2
- ;;
- esac
- done
fi
}
@@ -269,25 +255,7 @@
n) defprompt=N/m/?
;;
esac
- while :; do
- readln $ques ($var) [$defprompt] $def $old
- case $ans in
- [nN] | [nN]o ) define_tristate $var n
- break ;;
- [mM] ) define_tristate $var m
- break ;;
- [yY] | [yY]es ) echo
- echo This answer is not allowed, because it is not consistent with
- echo your other choices.
- echo This driver depends on another one which you chose to compile
- echo as a module. This means that you can either compile this one
- echo as a module as well (with M) or leave it out altogether (N).
- echo
- ;;
- * ) help $var
- ;;
- esac
- done
+ define_tristate $var m
fi
else
tristate $ques $var
-
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] for iso8859-13
[EMAIL PROTECTED] (H. Peter Anvin) wrote on 06.05.01 in 9d4ut6$9b9$[EMAIL PROTECTED]: Followup to: [EMAIL PROTECTED] By author:Andrzej Krzysztofowicz [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Hi, The following patch removed unused and broken conversion table from nls_iso8859-13.c. Wouldn't it make a heck of a lot more sense if we had a preprocessor which could produce these kinds of tables from a more sensible input format (preferrably one which is already in use somewhere.) For example from the tables on the Unicode webserver or from the IBM charset registry ... MfG Kai - 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: scripts/Configure patch for automatic module compile
On Mon, 7 May 2001 00:34:13 -0600, Maciek Nowacki [EMAIL PROTECTED] wrote: If you're like me, you build everything as modules, boot with an initrd that loads in the disk or net driver and filesystem module, and then let kmod take care of the rest. Here's a patch that changes Configure (make config) to build all possible modules - in other words, to answer 'M' for every tristate of some form y/m/n. I already have a patch from Ghozlane Toumi in my inbox that supports: make randconfig answers randomly to the questions . make allyes answers 'yes' to all questions . make allno answers 'no' to all questions . make allmod answer 'm' if avaiable, 'yes' else . Plus you can specify defaults in .force_default which will always be honoured. I have been using it to stress test the 2.4.4 configs and my 2.5 makefile rewrite, it works very nicely. - 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] for iso8859-13
Kai Henningsen wrote: [EMAIL PROTECTED] (H. Peter Anvin) wrote on 06.05.01 in 9d4ut6$9b9$[EMAIL PROTECTED]: Wouldn't it make a heck of a lot more sense if we had a preprocessor which could produce these kinds of tables from a more sensible input format (preferrably one which is already in use somewhere.) For example from the tables on the Unicode webserver or from the IBM charset registry ... The original tables seem to be generated automatically, however manually broken in some places. Can anybody point me to the tools the original tables were generated with? Andrzej -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. Math., Technical University of Gdansk - 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] CPU hot swap for 2.4.3 + s390 support
How far away is the capability to teleport processes from one machine to another over the network? Think of the uptime! It is here. Look at Mosix. No. Not for uptime. The responsibility for process completion does not get delegated. A process will always be bound to it's home-node (in mosix terms), no matter how far it's teleported. If the home-node fails, the process won't know what hit it. There are good reasons why mosix let's processes depend on their home nodes. This is not meant as backstabbing mosix, it's a great environment for a lot of things. But it's not the universal silver bullet. Take a look at http://citeseer.nj.nec.com/299905.html for something along the lines of what you want, I think (transparent process migration between nodes). As a bonus, it's also architecture-independent. Bruce - 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/
[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: page_launder() bug
Tobias Ringstrom writes: But is it really specified in the C standards to be exctly zero or one, and not zero and non-zero? I'm pretty sure it does. IMHO, the ?: construct is way more readable and reliable. Well identical code has been there for several months just a few lines away. I've seen this idiom used in many places (even the GCC sources :-), so I'm rather surprised people are seeing it for the first time. Later, David S. Miller [EMAIL PROTECTED] - 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: [Solved ?] Re: pcmcia problems after upgrading from 2.4.3-ac7 to 2.4.4
[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. -- dwmw2 - 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: page_launder() bug
Tobias Ringstrom wrote: On Sun, 6 May 2001, David S. Miller wrote: It is the most straightforward way to make a '1' or '0' integer from the NULL state of a pointer. But is it really specified in the C standards to be exctly zero or one, and not zero and non-zero? !0 is 1. !(anything else) is 0. It is zero and one, not zero and non-zero. So a !! construction gives zero if you have zero, and one if you had anything else. There's no doubt about it. IMHO, the ?: construct is way more readable and reliable. Thats your opinion. There are many others. Some don't like the ?: at all, for example. And some like all valid C. Helge Hafting - 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: [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
what causes Machine Check exception? revisited (2.2.18)
Hello! After searching the archives of the list I found some similar reports from September and December 2000 but as far as I understood the cause of the error was blamed on the CPU. Is this the most probable case? Best regards, Juhan Ernits -- /var/log/kern.log May 6 06:47:25 market kernel: CPU 0: Machine Check Exception: 0004 May 6 06:47:25 market kernel: Bank 4: b20401510Kernel panic: CPU context corrupt -- /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 1 cpu MHz : 551.259 cache size : 256 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr xmm bogomips: 1101.00 -- /var/log/dmesg Linux version 2.2.18 ([EMAIL PROTECTED]) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #6 Mon Jan 15 15:52:09 EET 2001 Detected 551259 kHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1101.00 BogoMIPS Memory: 517620k/524288k available (776k kernel code, 416k reserved, 5440k data, 36k init) Dentry hash table entries: 65536 (order 7, 512k) Buffer cache hash table entries: 524288 (order 9, 2048k) Page cache hash table entries: 131072 (order 7, 512k) Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. 256K L2 cache (8 way) CPU: L2 Cache: 256K CPU: Intel Pentium III (Coppermine) stepping 01 Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.35a (19990819) Richard Gooch ([EMAIL PROTECTED]) PCI: PCI BIOS revision 2.10 entry at 0xfb2a0 PCI: Using configuration type 1 PCI: Probing PCI hardware Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP TCP: Hash tables configured (ehash 524288 bhash 65536) Initializing RT netlink socket Starting kswapd v 1.5 pty: 2048 Unix98 ptys configured Real Time Clock Driver v1.09 keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? scsi0 : IBM PCI ServeRAID 4.20.20 ServeRAID 3L scsi : 1 host. Vendor: IBM Model: SERVERAIDRev: 1.0 Type: Direct-Access ANSI SCSI revision: 01 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 Vendor: IBM Model: SERVERAIDRev: 1.0 Type: Processor ANSI SCSI revision: 01 scsi : detected 1 SCSI disk total. SCSI device sda: hdwr sector= 512 bytes. Sectors= 35860480 [17510 MB] [17.5 GB] eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin [EMAIL PROTECTED] and others eepro100.c: VA Linux custom, Dragan Stancevic [EMAIL PROTECTED] 2000/11/15 eth0: Intel PCI EtherExpress Pro100 82557, 00:D0:B7:16:9E:E2, IRQ 11. Receiver lock-up bug exists -- enabling work-around. Board assembly 721383-008, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x04f4518b). eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin [EMAIL PROTECTED] and others eepro100.c: VA Linux custom, Dragan Stancevic [EMAIL PROTECTED] 2000/11/15 Partition check: sda: sda1 sda2 sda3 sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda4 apm: BIOS version 1.2 Flags 0x07 (Driver version 1.13) VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 36k freed Adding Swap: 64004k swap-space (priority -1) Adding Swap: 135976k swap-space (priority -2) Adding Swap: 135976k swap-space (priority -3) Adding Swap: 135976k swap-space (priority -4) Adding Swap: 135976k swap-space (priority -5) - 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: 2.2.20pre1: Problems with SMP
Just booted up 2.2.20pre1 and am getting some funny results. The system boots but is very slow. Every few seconds I get: Stuck on TLB IPI wait (CPU#0) Booting vanilla 2.2.19 works fine. The machine is an Intel Pentium III 850MHZ on an Abit VP6 board. If any further information is needed, let me know. Can you back out the change to io_apic.c and tell me if that fixes it. If so let Johannes Erdfelt and I know. - 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/
vt.c: unimap changes to (fg_?)console
Hi Linus, Alan, Andries,
if you open /dev/tty4 and change the font via ioctl(KDFONTOP), it will be
applied to the opened console, i.e. tty4. Then you set the corresponding
unicodemap via PIO_UNIMAPCLR and PIO_UNIMAP ioctls. Those get applied to the
current foreground console. Which is inconsistent.
Looking at vt.c: vt_ioctl(), the situation is a bit messy: Some ioctls don't
explicitly specify a tty (probably not needed, as some settings are global),
some apply to fg_console, some apply to the opened console which is
((struct vt_struct*)tty-driver_data)-vc_num.
I would appreciate, if somebody with more knowledge could have a look and
check whether this is all correct. At least for the above case, it's not.
(Andries, I would appreciate if you have a look; you understand much more of
it than I do.)
I attach a patch to fix the specific problem reported above. It applies to
both 2.4.4 and 2.2.19. ioctl(PIO_UNIMAP[CLR]) is applied to the opened
console now instead of fg_console.
Please apply until somebody comes with a complete vt.c cleanup!
If you want to test yourself: I also have a patch against kbd-1.05
which allows you to use setfont -c /dev/ttyXX to specify which terminal you
want to. I already sent it to Andries.
Regards,
--
Kurt Garloff [EMAIL PROTECTED] Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
--- linux-244.compile/drivers/char/vt.c.origFri Feb 9 20:30:22 2001
+++ linux-244.compile/drivers/char/vt.c Mon May 7 10:37:25 2001
@@ -392,7 +392,7 @@
}
static inline int
-do_unimap_ioctl(int cmd, struct unimapdesc *user_ud,int perm)
+do_unimap_ioctl(int cmd, struct unimapdesc *user_ud, int perm, unsigned int console)
{
struct unimapdesc tmp;
int i = 0;
@@ -408,9 +408,11 @@
case PIO_UNIMAP:
if (!perm)
return -EPERM;
- return con_set_unimap(fg_console, tmp.entry_ct, tmp.entries);
+ return con_set_unimap(console, tmp.entry_ct, tmp.entries);
case GIO_UNIMAP:
- return con_get_unimap(fg_console, tmp.entry_ct, (user_ud-entry_ct),
tmp.entries);
+ if (!perm fg_console != console)
+ return -EPERM;
+ return con_get_unimap(console, tmp.entry_ct, (user_ud-entry_ct),
+tmp.entries);
}
return 0;
}
@@ -1029,13 +1031,13 @@
return -EPERM;
i = copy_from_user(ui, (void *)arg, sizeof(struct unimapinit));
if (i) return -EFAULT;
- con_clear_unimap(fg_console, ui);
+ con_clear_unimap(console, ui);
return 0;
}
case PIO_UNIMAP:
case GIO_UNIMAP:
- return do_unimap_ioctl(cmd, (struct unimapdesc *)arg, perm);
+ return do_unimap_ioctl(cmd, (struct unimapdesc *)arg, perm, console);
case VT_LOCKSWITCH:
if (!suser())
PGP signature
Re: [PATCH] x86 page fault handler not interrupt safe
Yes, we'll get a clobbered value, but we'll get a _valid_ clobbered value,
and we'll just end up doing the fixups twice (and returning to the user
process that didn't get the page it wanted, which will end up re-doing the
page fault).
I dont see that we will get a valid value in both cases.
get_user
fault - set %cr2
IRQ
vmalloc
fault
set %cr2
fixup runs
end IRQ
cr2 is corrupt
At this point the Linus tree suffers from one problem because it gets parallel
fixups wrong, and the -ac tree suffers from a different problem because
it gets parallel fixups right and to handle that case wont allow a vmalloc
fixup on a fault from userspace (or you get infinite loops)
[ Looks closer.. ]
Actually, the second time we'd do the fixup we'd be unhappy, because it
has already been done. That test should probably be removed. Hmm.
There are a whole set of races with the vmalloc fixups. Most are I think fixed
in the -ac bits if you want a look (I've not submitted them as they are not
too pretty). What I don't currently see is how you handle this without
looping forever or getting the SMP race fixup wrong.
(The current -ac fix for the double vmalloc races is below. WP test makes it
more complex than is nice)
--- /usr/src/LINUS/LINUX2.4/linux.245p1/arch/i386/mm/fault.cWed May 2 13:52:04
2001
+++ /usr/src/LINUS/LINUX2.4/linux.ac/arch/i386/mm/fault.c Fri May 4 15:03:45
+2001
@@ -127,8 +183,11 @@
* be in an interrupt or a critical region, and should
* only copy the information from the master page table,
* nothing more.
+*
+* Handle kernel vmalloc fill in faults. User space doesn't take
+* this path. It isnt permitted to go poking up there.
*/
- if (address = TASK_SIZE)
+ if (address = TASK_SIZE !(error_code 4))
goto vmalloc_fault;
mm = tsk-mm;
@@ -325,7 +378,11 @@
*
* Do _not_ use tsk here. We might be inside
* an interrupt in the middle of a task switch..
+*
+* Note. There is 1 gotcha here. We may be doing the WP
+* test. If so then fixing the pgd/pmd won't help.
*/
+
int offset = __pgd_offset(address);
pgd_t *pgd, *pgd_k;
pmd_t *pmd, *pmd_k;
@@ -344,7 +401,29 @@
pmd = pmd_offset(pgd, address);
pmd_k = pmd_offset(pgd_k, address);
- if (pmd_present(*pmd) || !pmd_present(*pmd_k))
+ /* If the pmd is present then we either have two cpus trying
+* to fill in the vmalloc entries at once, or we have an
+* exception. We can treat the collision as a slow path without
+* worry. Its incredibly incredibly rare
+*
+* If the pte is read only then we know its a fault and we must
+* exception or Oops as it would loop forever otherwise
+*/
+
+ if (pmd_present(*pmd))
+ {
+ pte_t *ptep = pte_offset(pmd, address);
+ if ((error_code 2) !pte_write(*ptep))
+ {
+ if ((fixup = search_exception_table(regs-eip)) != 0) {
+ regs-eip = fixup;
+ return;
+ }
+ goto bad_area_nosemaphore;
+ }
+ /* SMP race.. continue */
+ }
+ if (!pmd_present(*pmd_k))
goto bad_area_nosemaphore;
set_pmd(pmd, *pmd_k);
return;
-
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: what causes Machine Check exception? revisited (2.2.18)
Hi Juhan, After searching the archives of the list I found some similar reports from September and December 2000 but as far as I understood the cause of the error was blamed on the CPU. Is this the most probable case? Best regards, Juhan Ernits -- /var/log/kern.log May 6 06:47:25 market kernel: CPU 0: Machine Check Exception: 0004 May 6 06:47:25 market kernel: Bank 4: b20401510Kernel panic: CPU context corrupt Yes. consensus of the messages I received is that it's the cpu flagging an internal hardware problem. Suggested causes include: overclocking thermal problems CPU actually bad Definitely not caused by: Bad Rams, mb-chipset. In my case the error only occured once and never again - marked it up to bad karma on that day. Bye, 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: what causes Machine Check exception? revisited (2.2.18)
After searching the archives of the list I found some similar reports from September and December 2000 but as far as I understood the cause of the error was blamed on the CPU. Is this the most probable case? A machine check (trap 18) is signalled by the processor when it thinks it is in an invalid state. Many x86 cpus have checking circuitry and the default behaviour is to either reboot or continue-and-pray. Linux enables notification of these events. So yes your processor was unhappy. But it can be unhappy because of wrong voltages, electrical noise, overheating and many other things. Generally it indicates a CPU problem but I've see it caused by overclocking and poorly fitted heatsinks - 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: page_launder() bug
It is the most straightforward way to make a '1' or '0' integer from the NULL state of a pointer. But is it really specified in the C standards to be exctly zero or one, and not zero and non-zero? Yes. (Fortunately since when this argument occurred Linus said he would eat his underpants if he was wrong) Alan - 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/
[Solved] Re: Problems even with 512 block size MOs
Hallo, I am very sorry that I didn't mention that I ran Hubert Mantels modified kernels when I had that problem. I now found in Hubert's Changelog: --- Sat May 5 15:17:10 CEST 2001 - [EMAIL PROTECTED] ... - fix max-sectors patch (fix horrible SCSI performance) ... After compiling and booting the newer kernel,erformance seems fine now. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 -- - 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/
No Subject
hi, i want to know how to read tab without a terminating character, ie., if i use getchar() i have to enter '\n' after tab to read tab, same is the case with read system call and scanf. bye, chandra. - 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: your mail
On Mon, May 07, 2001 at 05:08:43PM +0530, Chandrashekar Nagaraj wrote: i want to know how to read tab without a terminating character, ie., if i use getchar() i have to enter '\n' after tab to read tab, same is the case with read system call and scanf. This is off topic for this list, but anyway. Read man cfmakeraw, and/or get a copy of Advanced programming in the UNIX environment by W. Richard Stevens. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - 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/
[Patch] Do not account shmem pages to the page cache
Hi,
The appended patch does it's own accounting of shmem pages and adjust
the page cache size to take these into account. So now again you will
see shmem pages as used in top/vmstat etc. This confused a lot of
people.
There is a uncertainty in the calculations since the vm may drop pages
behind shmem and the number of shmem pages is estimated too high. This
especially happens on truncate because first the page cache is reduced
and later the shmem readjusts it's count.
To prevent negative cache sizes the adjustment is only done if
shmem_nrpages page_cache_size.
The latter part of the patch (all the init.c files) also exports the
shmem page number to the shared memory field in meminfo. This means a
change in semantics of this field but apparently a lot of people
interpret this field exactly this way and it was not used any more
The patches are on top of my encapsulation patch.
Greetings
Christoph
diff -uNr 2.4.4-mSsu/fs/proc/proc_misc.c 2.4.4-mSsua/fs/proc/proc_misc.c
--- 2.4.4-mSsu/fs/proc/proc_misc.c Sun Apr 29 20:32:52 2001
+++ 2.4.4-mSsua/fs/proc/proc_misc.c Mon May 7 13:38:53 2001
@@ -140,6 +140,17 @@
{
struct sysinfo i;
int len;
+ unsigned int cached, shmem;
+
+ /*
+* There may be some inconsistency because shmem_nrpages
+* update is delayed to page_cache_size
+* We make sure the cached value does not get below zero
+*/
+ cached = atomic_read(page_cache_size);
+ shmem = atomic_read(shmem_nrpages);
+ if (shmem cached)
+ cached -= shmem;
/*
* display in kilobytes.
@@ -153,8 +164,8 @@
Swap: %8lu %8lu %8lu\n,
B(i.totalram), B(i.totalram-i.freeram), B(i.freeram),
B(i.sharedram), B(i.bufferram),
-B(atomic_read(page_cache_size)), B(i.totalswap),
-B(i.totalswap-i.freeswap), B(i.freeswap));
+ B(cached), B(i.totalswap),
+ B(i.totalswap-i.freeswap), B(i.freeswap));
/*
* Tagged format, for easy grepping and expansion.
* The above will go away eventually, once the tools
@@ -180,7 +191,7 @@
K(i.freeram),
K(i.sharedram),
K(i.bufferram),
-K(atomic_read(page_cache_size)),
+ K(cached),
K(nr_active_pages),
K(nr_inactive_dirty_pages),
K(nr_inactive_clean_pages()),
diff -uNr 2.4.4-mSsu/include/linux/shmem_fs.h 2.4.4-mSsua/include/linux/shmem_fs.h
--- 2.4.4-mSsu/include/linux/shmem_fs.h Wed May 2 18:36:05 2001
+++ 2.4.4-mSsua/include/linux/shmem_fs.hMon May 7 12:52:00 2001
@@ -17,6 +17,8 @@
unsigned long val;
} swp_entry_t;
+extern atomic_t shmem_nrpages;
+
struct shmem_inode_info {
spinlock_t lock;
struct semaphoresem;
diff -uNr 2.4.4-mSsu/mm/mmap.c 2.4.4-mSsua/mm/mmap.c
--- 2.4.4-mSsu/mm/mmap.cSun Apr 29 20:33:01 2001
+++ 2.4.4-mSsua/mm/mmap.c Mon May 7 13:42:03 2001
@@ -55,13 +55,24 @@
*/
long free;
-
+ unsigned long cached, shmem;
+
+ /*
+* There may be some inconsistency because shmem_nrpages
+* update is delayed to the page_cache_size
+* We make sure the cached value does not get below zero
+*/
+ cached = atomic_read(page_cache_size);
+ shmem = atomic_read(shmem_nrpages);
+ if (cached shmem)
+ cached -= shmem;
+
/* Sometimes we want to use more memory than we have. */
if (sysctl_overcommit_memory)
return 1;
free = atomic_read(buffermem_pages);
- free += atomic_read(page_cache_size);
+ free += cached;
free += nr_free_pages();
free += nr_swap_pages;
diff -uNr 2.4.4-mSsu/mm/shmem.c 2.4.4-mSsua/mm/shmem.c
--- 2.4.4-mSsu/mm/shmem.c Fri May 4 21:37:34 2001
+++ 2.4.4-mSsua/mm/shmem.c Mon May 7 11:13:27 2001
@@ -3,7 +3,8 @@
*
* Copyright (C) 2000 Linus Torvalds.
* 2000 Transmeta Corp.
- * 2000 Christoph Rohland
+ * 2000-2001 Christoph Rohland
+ * 2000-2001 SAP AG
*
* This file is released under the GPL.
*/
@@ -45,6 +46,7 @@
LIST_HEAD (shmem_inodes);
static spinlock_t shmem_ilock = SPIN_LOCK_UNLOCKED;
+atomic_t shmem_nrpages = ATOMIC_INIT(0);
#define BLOCKS_PER_PAGE (PAGE_SIZE/512)
@@ -52,6 +54,7 @@
* shmem_recalc_inode - recalculate the size of an inode
*
* @inode: inode to recalc
+ * @swap: additional swap pages freed externally
*
* We have to calculate the free blocks since the mm can drop pages
* behind our back
@@ -62,12 +65,14 @@
*
* So the mm freed
* inodes-i_blocks/BLOCKS_PER_PAGE -
- * (inode-i_mapping-nrpages + info-swapped)
+ * (inode-i_mapping-nrpages + info-swapped)
*
* It has to be called with the spinlock held.
+ *
+ *
2.4.4-ac5 aic7xxx causes hang on my machine
I have a dual ppro 200MHZ W6LI motherboard. I put 2.4.4-ac5 on last
night, and the machine hung at Freeing unused Kernel memory. I
selectively backed off what I thought were relevant patches. I got to
aic7xxx, and ac5 without it worked. I attached /proc/scsi/aic7xxx/0.
Andy Carlson |\ _,,,---,,_
[EMAIL PROTECTED]ZZZzz /,`.-'`'-. ;-;;,_
BJC Health System |,4- ) )-,_. ,\ ( `'-'
St. Louis, Missouri '---''(_/--' `-'\_)
Cat Pics: http://andyc.dyndns.org
On Mon, 7 May 2001, Christoph Rohland wrote:
Hi,
The appended patch does it's own accounting of shmem pages and adjust
the page cache size to take these into account. So now again you will
see shmem pages as used in top/vmstat etc. This confused a lot of
people.
There is a uncertainty in the calculations since the vm may drop pages
behind shmem and the number of shmem pages is estimated too high. This
especially happens on truncate because first the page cache is reduced
and later the shmem readjusts it's count.
To prevent negative cache sizes the adjustment is only done if
shmem_nrpages page_cache_size.
The latter part of the patch (all the init.c files) also exports the
shmem page number to the shared memory field in meminfo. This means a
change in semantics of this field but apparently a lot of people
interpret this field exactly this way and it was not used any more
The patches are on top of my encapsulation patch.
Greetings
Christoph
diff -uNr 2.4.4-mSsu/fs/proc/proc_misc.c 2.4.4-mSsua/fs/proc/proc_misc.c
--- 2.4.4-mSsu/fs/proc/proc_misc.cSun Apr 29 20:32:52 2001
+++ 2.4.4-mSsua/fs/proc/proc_misc.c Mon May 7 13:38:53 2001
@@ -140,6 +140,17 @@
{
struct sysinfo i;
int len;
+ unsigned int cached, shmem;
+
+ /*
+ * There may be some inconsistency because shmem_nrpages
+ * update is delayed to page_cache_size
+ * We make sure the cached value does not get below zero
+ */
+ cached = atomic_read(page_cache_size);
+ shmem = atomic_read(shmem_nrpages);
+ if (shmem cached)
+ cached -= shmem;
/*
* display in kilobytes.
@@ -153,8 +164,8 @@
Swap: %8lu %8lu %8lu\n,
B(i.totalram), B(i.totalram-i.freeram), B(i.freeram),
B(i.sharedram), B(i.bufferram),
-B(atomic_read(page_cache_size)), B(i.totalswap),
-B(i.totalswap-i.freeswap), B(i.freeswap));
+ B(cached), B(i.totalswap),
+ B(i.totalswap-i.freeswap), B(i.freeswap));
/*
* Tagged format, for easy grepping and expansion.
* The above will go away eventually, once the tools
@@ -180,7 +191,7 @@
K(i.freeram),
K(i.sharedram),
K(i.bufferram),
-K(atomic_read(page_cache_size)),
+ K(cached),
K(nr_active_pages),
K(nr_inactive_dirty_pages),
K(nr_inactive_clean_pages()),
diff -uNr 2.4.4-mSsu/include/linux/shmem_fs.h 2.4.4-mSsua/include/linux/shmem_fs.h
--- 2.4.4-mSsu/include/linux/shmem_fs.h Wed May 2 18:36:05 2001
+++ 2.4.4-mSsua/include/linux/shmem_fs.h Mon May 7 12:52:00 2001
@@ -17,6 +17,8 @@
unsigned long val;
} swp_entry_t;
+extern atomic_t shmem_nrpages;
+
struct shmem_inode_info {
spinlock_t lock;
struct semaphoresem;
diff -uNr 2.4.4-mSsu/mm/mmap.c 2.4.4-mSsua/mm/mmap.c
--- 2.4.4-mSsu/mm/mmap.c Sun Apr 29 20:33:01 2001
+++ 2.4.4-mSsua/mm/mmap.c Mon May 7 13:42:03 2001
@@ -55,13 +55,24 @@
*/
long free;
-
+ unsigned long cached, shmem;
+
+ /*
+ * There may be some inconsistency because shmem_nrpages
+ * update is delayed to the page_cache_size
+ * We make sure the cached value does not get below zero
+ */
+ cached = atomic_read(page_cache_size);
+ shmem = atomic_read(shmem_nrpages);
+ if (cached shmem)
+ cached -= shmem;
+
/* Sometimes we want to use more memory than we have. */
if (sysctl_overcommit_memory)
return 1;
free = atomic_read(buffermem_pages);
- free += atomic_read(page_cache_size);
+ free += cached;
free += nr_free_pages();
free += nr_swap_pages;
diff -uNr 2.4.4-mSsu/mm/shmem.c 2.4.4-mSsua/mm/shmem.c
--- 2.4.4-mSsu/mm/shmem.c Fri May 4 21:37:34 2001
+++ 2.4.4-mSsua/mm/shmem.cMon May 7 11:13:27 2001
@@ -3,7 +3,8 @@
*
* Copyright (C) 2000 Linus Torvalds.
*2000 Transmeta Corp.
- *2000 Christoph Rohland
+ *2000-2001 Christoph Rohland
+ *2000-2001 SAP AG
*
* This file is released under the GPL.
*/
@@ -45,6 +46,7 @@
LIST_HEAD (shmem_inodes);
static spinlock_t shmem_ilock =
RE: what causes Machine Check exception? revisited (2.2.18)
On Mon, 7 May 2001, Bene, Martin wrote: Definitely not caused by: Bad Rams, mb-chipset. Erm, it was bad RAM everytime it happened to me. On standard PCs, you don't see those because you don't have ECC and the error is simply not detected. Simon -- GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! - 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: what causes Machine Check exception? revisited (2.2.18)
Hi Simon, On Mon, 7 May 2001, Bene, Martin wrote: Definitely not caused by: Bad Rams, mb-chipset. Erm, it was bad RAM everytime it happened to me. On standard PCs, you don't see those because you don't have ECC and the error is simply not detected. Strange - definitely, strange. Of course you're correct about memory errors going undetected on standard PC hardware, and usually these undetected errors lead to other failures later on: You get SIG11 errors when running programs(kernel compile seems to be agood example), you get crashing processes, you get all sorts of weird funnies but you really shouldn't get machine check exceptions. I don't think there is a way a machine check exception can be triggered by software - which it would have to be in order to be caused by bad RAMs. Bye, 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: Help: kernel-2.4.4 and iptables: Error?
Can someone help this guy?
--
Zack Brown
On Mon, 7 May 2001, Phillipus Gunawan wrote:
I'm having problem with iptables...
I just upgrade my kernel from 2.2.16 to 2.4.3
I also upgrade the iptables with: iptables-1.2.1a-1.i386.rpm
After the installation finished, I try to test it with: iptables -L
Here's what I've seen on my screen:
modprobe: Can't locate module ip_tables
iptables v1.2.1a: can't initialise iptables table 'filter': Module is wrong version
Perhaps iptables or your kernel needs to be upgraded.
I install the iptables-1.2.1a-1.i386.rpm first and then upgrade my kernel.
The way I upgrade my kernel:
make mrproper
make dep bzImage
make modules
make modules_install
cp .
cp
I've choose all option regarding iptables 'netfilter'
My friend said I might built netfilter with the ipfwadm
compatibility compiled in, which is mutually exclusive with iptables
and ipchains support. I didn't build ipfwadm and all other modules I compiled as
modules ('M' instead of 'Y')
But I still can't understand, it still doesn't work...
Could you please help me. I've tried everywhere asking this question, still, nobody
can answer it
Thank You.
Best Regards,
Phillipus.
[Question] Explanation of zero-copy networking
Hi all, we are currently developing (as part of my dissertation) a research-platform to study some new ideas in constructing transport systems to support applications with realtime-requirements (e.g. multimedia) and new networking technologies. The test-platform consists of typical multimedia-elements, such as sources, filters, sinks and transport-modules, which can be distributed across a set of computers. To achieve the principle of sparing ressource-usage - which we consider fundamental for multimedia-systems - we are looking for new (already implemented or planned) mechanisms to avoid copying the data-streams where possible (Device-IO, especially Network-IO; User-User-IPC). That's why i'd like to ask if one of the net-core developers could give us a (more or less - depends on what you've documented so far) detailed description of the newly implemented zero-copy mechanisms in the network-stack. We are interested in how to use it (changed network-API?) and also in the internal architecture. We already had a look at the kernel mailingslist archieves and some search machines, but all we found were some fragments of the puzzle only. Before digging into the sourcecode we try this way to get an overall description. Our second question: Are there any plans for contructing a general copy-avoidance infrastructure (smth. like UVM in NetBSD does) and new IPC-mechanisms on top of it yet?? Thanks in advance. Alexander Eichhorn -- Alexander Eichhorn Technical University of Ilmenau Computer Science And Automation Faculty Distributed Systems and Operating Systems Department Phone +49 3677 69 4557, Fax +49 3677 69 4541 - 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: vt.c: unimap changes to (fg_?)console
Followup to: [EMAIL PROTECTED] By author:Kurt Garloff [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Hi Linus, Alan, Andries, if you open /dev/tty4 and change the font via ioctl(KDFONTOP), it will be applied to the opened console, i.e. tty4. Then you set the corresponding unicodemap via PIO_UNIMAPCLR and PIO_UNIMAP ioctls. Those get applied to the current foreground console. Which is inconsistent. Looking at vt.c: vt_ioctl(), the situation is a bit messy: Some ioctls don't explicitly specify a tty (probably not needed, as some settings are global), some apply to fg_console, some apply to the opened console which is ((struct vt_struct*)tty-driver_data)-vc_num. Okay, these should either be global or apply to the invoked (file descriptor) tty. Anything else is completely broken. In fact, I'd argue that using ioctl's for anything but global data (since it's global, it has to be privileged) is in itself broken. (Note: all the font stuff used to be global state for kernel memory reasons.) Why do you have the following in your patch? It makes the permissions on the console depend on whether or not it is in the foreground, which seems like another stupid inconsistency: + if (!perm fg_console !=3D console) + return -EPERM; -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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Question] Explanation of zero-copy networking
documented so far) detailed description of the newly implemented zero-copy mechanisms in the network-stack. We are interested in how to use it (changed network-API?) and also in the internal architecture. It is built around sendfile. Trying to do zero copy on pages with user space mappings get so horribly non pretty it is better to build the API from the physical side of things. Our second question: Are there any plans for contructing a general copy-avoidance infrastructure (smth. like UVM in NetBSD does) and new IPC-mechanisms on top of it yet?? Andrea Arcangeli has O_DIRECT file I/O for the ext2 file system. There are also several patches for kiovec based single copy pipes have been posted too. - 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: page_launder() bug
Followup to: [EMAIL PROTECTED] By author:Tobias Ringstrom [EMAIL PROTECTED] In newsgroup: linux.dev.kernel On Sun, 6 May 2001, David S. Miller wrote: It is the most straightforward way to make a '1' or '0' integer from the NULL state of a pointer. But is it really specified in the C standards to be exctly zero or one, and not zero and non-zero? Yes it is. IMHO, the ?: construct is way more readable and reliable. In C99 one can write (bool)foo which is more readable than either, especially since that is really what one is trying to do. -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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: what causes Machine Check exception? revisited (2.2.18)
You get SIG11 errors when running programs(kernel compile seems to be agood example), you get crashing processes, you get all sorts of weird funnies but you really shouldn't get machine check exceptions. I don't think there is a way a machine check exception can be triggered by software - which it would have to be in order to be caused by bad RAMs. Bad ECC memory and unrecoverable ECC faults can certainly be reported back to the processor electrically. Also an L2 cache load failing when the RAM fails to ack the signals is quite visible to a processor. - 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/
[PATCH] koi8-ru support for 2.4
Hi,
The following patch adds koi8-ru (Belarussian) charset support for
2.4.4-ac kernels on top of nls_koi8-u module. They differ on two characters
only, so I don't think t is worth to create a new table for koi8-ru.
Well it could be koi8-u on top of koi8-ru as well, but I choosed minimal-
changes-way for the patch.
Andrzej
diff -uNr linux-2.4.4-ac5/Documentation/Configure.help
linux/Documentation/Configure.help
--- linux-2.4.4-ac5/Documentation/Configure.helpWed May 2 23:42:15 2001
+++ linux/Documentation/Configure.help Sun May 6 22:09:54 2001
@@ -12567,8 +12567,8 @@
cp862, cp863, cp864, cp865, cp866, cp869, cp874, cp932, cp936,
cp949, cp950, cp1251, cp1255, euc-jp, euc-kr, gb2312, iso8859-1,
iso8859-2, iso8859-3, iso8859-4, iso8859-5, iso8859-6, iso8859-7,
- iso8859-8, iso8859-9, iso8859-14, iso8859-15, koi8-r, koi8-u, sjis,
- tis-620, utf8.
+ iso8859-8, iso8859-9, iso8859-14, iso8859-15, koi8-r, koi8-ru,
+ koi8-u, sjis, tis-620, utf8.
If you specify a wrong value, it will use the built-in NLS;
compatible with iso8859-1.
@@ -12937,13 +12937,13 @@
input/output character sets. Say Y here for the preferred Russian
character set.
-NLS KOI8-U (Ukrainian)
+NLS KOI8-U/RU (Ukrainian, Belarussian)
CONFIG_NLS_KOI8_U
If you want to display filenames with native language characters
from the Microsoft FAT file system family or from JOLIET CDROMs
correctly on the screen, you need to include the appropriate
input/output character sets. Say Y here for the preferred Ukrainian
- character set.
+ (koi8-u) and Belarussian (koi8-ru) character sets.
NLS UTF8
CONFIG_NLS_UTF8
diff -uNr linux-2.4.4-ac5/fs/nls/Config.in linux/fs/nls/Config.in
--- linux-2.4.4-ac5/fs/nls/Config.inSat Apr 28 20:35:03 2001
+++ linux/fs/nls/Config.in Sun May 6 22:05:35 2001
@@ -56,7 +56,7 @@
tristate 'NLS ISO 8859-14 (Latin 8; Celtic)' CONFIG_NLS_ISO8859_14
tristate 'NLS ISO 8859-15 (Latin 9; Western European Languages with Euro)'
CONFIG_NLS_ISO8859_15
tristate 'NLS KOI8-R (Russian)' CONFIG_NLS_KOI8_R
- tristate 'NLS KOI8-U (Ukrainian)' CONFIG_NLS_KOI8_U
+ tristate 'NLS KOI8-U/RU (Ukrainian, Belarussian)' CONFIG_NLS_KOI8_U
tristate 'NLS UTF8' CONFIG_NLS_UTF8
endmenu
fi
diff -uNr linux-2.4.4-ac5/fs/nls/Makefile linux/fs/nls/Makefile
--- linux-2.4.4-ac5/fs/nls/Makefile Sat Apr 28 20:35:03 2001
+++ linux/fs/nls/Makefile Sun May 6 21:41:41 2001
@@ -49,7 +49,7 @@
obj-$(CONFIG_NLS_ISO8859_14) += nls_iso8859-14.o
obj-$(CONFIG_NLS_ISO8859_15) += nls_iso8859-15.o
obj-$(CONFIG_NLS_KOI8_R) += nls_koi8-r.o
-obj-$(CONFIG_NLS_KOI8_U) += nls_koi8-u.o
+obj-$(CONFIG_NLS_KOI8_U) += nls_koi8-u.o nls_koi8-ru.o
obj-$(CONFIG_NLS_ABC) += nls_abc.o
obj-$(CONFIG_NLS_UTF8) += nls_utf8.o
diff -uNr linux-2.4.4-ac5/fs/nls/nls_koi8-ru.c linux/fs/nls/nls_koi8-ru.c
--- linux-2.4.4-ac5/fs/nls/nls_koi8-ru.cThu Jan 1 01:00:00 1970
+++ linux/fs/nls/nls_koi8-ru.c Sun May 6 21:47:28 2001
@@ -0,0 +1,99 @@
+/*
+ * linux/fs/nls_koi8-ru.c
+ *
+ * Charset koi8-ru translation based on charset koi8-u.
+ * The Unicode to charset table has only exact mappings.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/string.h
+#include linux/nls.h
+#include linux/errno.h
+
+static struct nls_table *p_nls;
+
+static int uni2char(const wchar_t uni,
+ unsigned char *out, int boundlen)
+{
+ if (boundlen = 0)
+ return -ENAMETOOLONG;
+
+ if ((uni 0xffaf) == 0x040e || (uni 0xffce) == 0x254c) {
+ /* koi8-ru and koi8-u differ only on two characters */
+ if (uni == 0x040e)
+ return 0xbe;
+ else if (uni == 0x045e)
+ return 0xae;
+ else if (uni == 0x255d || uni == 0x256c)
+ return 0;
+ else
+ return p_nls-uni2char(uni, out, boundlen);
+ }
+ else
+ /* fast path */
+ return p_nls-uni2char(uni, out, boundlen);
+}
+
+static int char2uni(const unsigned char *rawstring, int boundlen,
+ wchar_t *uni)
+{
+ int n;
+
+ if ((*rawstring 0xef) != 0xae) {
+ /* koi8-ru and koi8-u differ only on two characters */
+ *uni = (*rawstring 0x10) ? 0x040e : 0x045e;
+ return 1;
+ }
+
+ n = p_nls-char2uni(rawstring, boundlen, uni);
+ return n;
+}
+
+static struct nls_table table = {
+ koi8-ru,
+ uni2char,
+ char2uni,
+ NULL,
+ NULL,
+ THIS_MODULE,
+};
+
+static int __init init_nls_koi8_ru(void)
+{
+ p_nls = load_nls(koi8-u);
+
+ if (p_nls) {
+ table.charset2upper = p_nls-charset2upper;
+ table.charset2lower = p_nls-charset2lower;
+ return register_nls(table);
+
RE: 2.4.4-ac5 aic7xxx causes hang on my machine
It works fine on my dual ppro 200 (not sure what mobo). Here is lcpci: 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:06.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 01) 00:07.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] (rev 01) 00:07.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:09.0 SCSI storage controller: Adaptec AIC-7880U 00:11.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+] It has 2 atlas iv disks attached + 3 ide disks. Boots from ide and running scsi disks in lvm. Oyvind Jagtnes -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andy Carlson Sent: 7. mai 2001 15:04 To: [EMAIL PROTECTED] Subject: 2.4.4-ac5 aic7xxx causes hang on my machine I have a dual ppro 200MHZ W6LI motherboard. I put 2.4.4-ac5 on last night, and the machine hung at Freeing unused Kernel memory. I selectively backed off what I thought were relevant patches. I got to aic7xxx, and ac5 without it worked. I attached /proc/scsi/aic7xxx/0. Andy Carlson |\ _,,,---,,_ [EMAIL PROTECTED]ZZZzz /,`.-'`'-. ;-;;,_ BJC Health System |,4- ) )-,_. ,\ ( `'-' St. Louis, Missouri '---''(_/--' `-'\_) Cat Pics: http://andyc.dyndns.org On Mon, 7 May 2001, Christoph Rohland wrote: Hi, The appended patch does it's own accounting of shmem pages and adjust the page cache size to take these into account. So now again you will see shmem pages as used in top/vmstat etc. This confused a lot of people. There is a uncertainty in the calculations since the vm may drop pages behind shmem and the number of shmem pages is estimated too high. This especially happens on truncate because first the page cache is reduced and later the shmem readjusts it's count. To prevent negative cache sizes the adjustment is only done if shmem_nrpages page_cache_size. The latter part of the patch (all the init.c files) also exports the shmem page number to the shared memory field in meminfo. This means a change in semantics of this field but apparently a lot of people interpret this field exactly this way and it was not used any more The patches are on top of my encapsulation patch. Greetings Christoph - 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: 2.4.4-ac5 aic7xxx causes hang on my machine
I have a dual ppro 200MHZ W6LI motherboard. I put 2.4.4-ac5 on last night, and the machine hung at Freeing unused Kernel memory. I selectively backed off what I thought were relevant patches. I got to aic7xxx, and ac5 without it worked. I attached /proc/scsi/aic7xxx/0. This problem was fixed in rev. 6.1.13 of the aic7xxx driver. -- Justin - 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/
PROBLEM: 2.4.4 and in2000
hello, patching the kernel from 2.4.3 to 2.4.4 broke the in2000 scsi lowlevel host adapter module. ksymoops output below. thanks, peter chiocchetti - ksymoops 2.4.1 on i686 2.4.4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.4/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry Forcing IN2000 detection at IOport 0x220 1Unable to handle kernel paging request at virtual address 000d8010 c891f2cb *pde = Oops: CPU:0 EIP:0010:[c891f2cb] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 000d8000 ebx: 0008 ecx: edx: 0002 esi: c497347c edi: c49734d0 ebp: c49734d8 esp: c5a19e54 ds: 0018 es: 0018 ss: 0018 Process modprobe (pid: 1247, stackpage=c5a19000) Stack: 0020 c5a19e90 c5a19e8c 4927 0286 c0219c18 c0219c90 c0219df0 c0219dec 0002 0001 c4973400 080c1000 0220 c117d028 c011ee3a c011ee8f c5944e80 c4e8c304 080c101c 080c1000 Call Trace: [c011ee3a] [c011ee8f] [c891d000] [c8921200] [c8908416] [c8921200] [c012208c] [c891d000] [c891ff06] [c8921200] [c8921200] [c0113545] [c8921494] [c8907000] [c891d060] [c0106c17] Code: 8b 40 10 3d 4e 4f 56 41 75 10 0f b6 44 24 1c 83 e0 20 74 06 EIP; c891f2cb [in2000]in2000_detect+2fb/590 = Trace; c011ee3a do_wp_page+1aa/230 Trace; c011ee8f do_wp_page+1ff/230 Trace; c891d000 [scsi_mod]__kstrtab_scsi_device_types+124a/12aa Trace; c8921200 [in2000]driver_template+0/6b Trace; c8908416 [scsi_mod]scsi_register_host+46/2e0 Trace; c8921200 [in2000]driver_template+0/6b Trace; c012208c file_read_actor+2c/60 Trace; c891d000 [scsi_mod]__kstrtab_scsi_device_types+124a/12aa Trace; c891ff06 [in2000]init_this_scsi_driver+16/40 Trace; c8921200 [in2000]driver_template+0/6b Trace; c8921200 [in2000]driver_template+0/6b Trace; c0113545 sys_init_module+525/5e0 Trace; c8921494 [in2000].bss.end+4/1bd0 Trace; c8907000 [via686a].data.end+eec5/ef25 Trace; c891d060 [in2000]read_1_byte+0/70 Trace; c0106c17 system_call+33/38 Code; c891f2cb [in2000]in2000_detect+2fb/590 _EIP: Code; c891f2cb [in2000]in2000_detect+2fb/590 = 0: 8b 40 10 mov0x10(%eax),%eax = Code; c891f2ce [in2000]in2000_detect+2fe/590 3: 3d 4e 4f 56 41cmp$0x41564f4e,%eax Code; c891f2d3 [in2000]in2000_detect+303/590 8: 75 10 jne1a _EIP+0x1a c891f2e5 [in2000]in2000_detect+315/590 Code; c891f2d5 [in2000]in2000_detect+305/590 a: 0f b6 44 24 1cmovzbl 0x1c(%esp,1),%eax Code; c891f2da [in2000]in2000_detect+30a/590 f: 83 e0 20 and$0x20,%eax Code; c891f2dd [in2000]in2000_detect+30d/590 12: 74 06 je 1a _EIP+0x1a c891f2e5 [in2000]in2000_detect+315/590 2 warnings issued. Results may not be reliable. - 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: what causes Machine Check exception? revisited (2.2.18)
Definitely not caused by: Bad Rams, mb-chipset. Erm, it was bad RAM everytime it happened to me. On standard PCs, you don't see those because you don't have ECC and the error is simply not detected. I did have the same problem with an SMP Intel 440LX which run without any problem since 1998. When I installed 2.2.18 it could run for more than 5 minutes (Alan suggested me it was . I am not sure it's a RAM poblem, because it never gave/gives a SEGFAULT compiling the kernel. I brought it back to 2.2.16 and it's running happy. Could be some SMP/BIOS related problem? If it's the RAM or chipset, I am scared how we could use it for three years and suddenly it hangs with a new version of the kernel... Blame to Intel? --ricardo http://m3d.uib.es/~gallir/ - 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/
SCSI Tape corruption - update
As of my latest build [2.4.5-pre1] I've STILL got the tape corruption problem. Some new facts: (1) It happens only writing the tape (tried exchanging tapes with a brand new Alpha Digital Tru64 box). I can read her tape, she can't read my tape. Tried with GNU tar and gzip. (2) I suppose it isn't fault of AIC7xxx driver (tried both new and old) (3) Playing with block size doesn't help (even tried variable block size) What can I do? Can I set some kind of trace to pinpoint the problem (in st.c, maybe?) -- Lorenzo Marcantonio - 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] x86 page fault handler not interrupt safe
Alan Cox wrote: (The current -ac fix for the double vmalloc races is below. WP test makes it more complex than is nice) WP test is easy to handle. Just filter out protection violations and only take the vmalloc path if the page was not found. - if (address = TASK_SIZE !(error_code 4)) + if (address = TASK_SIZE !(error_code 5)) -- Brian Gerst - 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: Crash
Is it possible to screw up the hardware entirely from software? I made In an abstract theoretical sense yes. Accidentally almost impossible. know is if there is any way to screw the board from software in such a way that power off and power on does not bring it up ?. The only people are ever likely to do is to corrupt the CMOS, which is easily cleared. Its a dual pentium-3 machine. The power supply is gone also, the power supply from the crashed machine does not bring up another normal computer, also power supply from normal computer does not bring up crashed computer. Sounds like a rather more physical layer problem - like a power spike and PSU failure. BTW: Always put a voltmeter on a power supply before you swap it like that to test it. You need to check the voltages under load look sane otherwise you may end up using a failed PSU to blow up other motherboards which is a rather expensive debugging error ;) Alan - 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] x86 page fault handler not interrupt safe
Alan Cox wrote: (The current -ac fix for the double vmalloc races is below. WP test makes it more complex than is nice) WP test is easy to handle. Just filter out protection violations and only take the vmalloc path if the page was not found. - if (address = TASK_SIZE !(error_code 4)) + if (address = TASK_SIZE !(error_code 5)) That is nice. I hadn't thought about doing it that way. It still has the problem if %cr2 is corrupted by a vmalloc fault but it cleans up my other code paths nicely. Thanks - 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] Thread core dumps for 2.4.4
Szabolcs Szakacsits wrote: On Thu, 3 May 2001, Don Dugger wrote: The attached patch allows core dumps from thread processes in the 2.4.4 kernel. This patch is the same as the last one I sent out except it fixes the same bug that `kernel/fork.c' had with duplicate info in the `mm' structure, plus this patch has had more extensive testing. AFAIK Linux can't dump the threads to the same file as others but doing it to different files looks a bit scary. How the system behaves when you dump a heavy threaded app with a decent VM [i.e just think about a bloatware instead of malicious code]? How will the developer know which thread caused the fault? I've found dumping just the faulting thread is enough about 100% of the cases especially because [on SMP] others can run on and the dump is much more close to garbage then usuful info from a debug point of view. Well I strongly dissagre with you - I need to know about all thread - when I'm developing my application and it crashes then sometimes thread which has crashed is undetectable because of completely broken stack (C++ destructors) - but because I could inspect other threads I know which thread caused segfault (also I know in which state other thread have been - locked in mutex or similar) So if you think core dumps are garbage - use ulimit and you want ever see them. But for me I need all threads - and I like the behaviour of -ac kernel. bye [EMAIL PROTECTED] - 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/
A simple question.
Dear all, After I compile and upgrade to a newer Kernel, do I need to copy the System.map from /usr/src/linux/ to /boot/System- and link it to System.map? Thanks in advance Hai Xu - 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: A simple question.
On 07 May 2001 11:29:56 -0400, Hai Xu wrote: After I compile and upgrade to a newer Kernel, do I need to copy the System.map from /usr/src/linux/ to /boot/System- and link it to System.map yes, you do. but System.map is only needed to do symbol lookups, for times like debugging. note most distributions link /boot/System.map to the correct System.map (in boot) on startup. if your's does not, its a simple script: ln -sf /boot/System.map-`uname -r` /boot/System.map -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] - 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: SCSI Tape corruption - update
Lorenzo Marcantonio [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... As of my latest build [2.4.5-pre1] I've STILL got the tape corruption problem. Some new facts: (1) It happens only writing the tape (tried exchanging tapes with a brand new Alpha Digital Tru64 box). I can read her tape, she can't read my tape. Tried with GNU tar and gzip. Lorenzo, Have you ruled out hardware failures? There's been a few isolated reports about tape drives returning good status on write, where in fact they were writing corrupt data. This can happen when the compression hardware is malfunctioning. On many tape drives, read-back check isn't carried all the way back to the original (uncompressed) data. Rob - 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: A simple question.
If you do a make install, it will be copied to /boot directory automatically;-) Alex On Mon, 7 May 2001, Hai Xu wrote: Dear all, After I compile and upgrade to a newer Kernel, do I need to copy the System.map from /usr/src/linux/ to /boot/System- and link it to System.map? Thanks in advance Hai Xu - 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/ -- Feng Xian _o) .~. (o_ /\\ /V\ //\ _\_V// \\ V_/_ /( )\ ^^-^^ ALEX - 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] Thread core dumps for 2.4.4
Szaka- I would considier what you're suggesting to be a refinement on this patch. The first problem is to generate valid core dumps for all threads. Adding in policy decisions about which threads actually generate core files can be done later. Adam ? (I'm sorry, I've lost the mail with his full name) actually posted a patch a while back that only dumped core for the first faulting thread. The problem with this patch is that it didn't deal with the potential races between threads modifying the memory maps while the core dump was being generated. Also, this patch used a single system wide variable to make its policy decisions, this really needs to be a per-process decision. What I'd really like to see is some sort of rondezous capability where, when a fatal exception occurs, all the threads are halted, appropriate core dumps are generated, and then all the threads are resumed (to terminate or continue as appropriate). This is a bigger project that will require a little thought. On Sun, May 06, 2001 at 06:47:28PM +0200, Szabolcs Szakacsits wrote: On Thu, 3 May 2001, Don Dugger wrote: The attached patch allows core dumps from thread processes in the 2.4.4 kernel. This patch is the same as the last one I sent out except it fixes the same bug that `kernel/fork.c' had with duplicate info in the `mm' structure, plus this patch has had more extensive testing. AFAIK Linux can't dump the threads to the same file as others but doing it to different files looks a bit scary. How the system behaves when you dump a heavy threaded app with a decent VM [i.e just think about a bloatware instead of malicious code]? How will the developer know which thread caused the fault? I've found dumping just the faulting thread is enough about 100% of the cases especially because [on SMP] others can run on and the dump is much more close to garbage then usuful info from a debug point of view. Szaka -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale [EMAIL PROTECTED] Ph: 303/938-9838 - 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/
[patch] alpha rw semaphores (try #2)
- 'count' is 64-bit now;
- __builtin_expect used;
- fast non-atomic UP version;
- some silly bits from previous patch dropped.
Ivan.
--- 2.4.5p1/lib/rwsem.c Sat Apr 28 00:58:28 2001
+++ linux/lib/rwsem.c Mon May 7 16:10:54 2001
@@ -112,7 +112,7 @@ static inline struct rw_semaphore *__rws
*/
static inline struct rw_semaphore *rwsem_down_failed_common(struct rw_semaphore *sem,
struct rwsem_waiter
*waiter,
-__s32 adjustment)
+signed long
+adjustment)
{
struct task_struct *tsk = current;
signed long count;
--- 2.4.5p1/include/asm-alpha/rwsem.h Sun Feb 7 06:28:16 2106
+++ linux/include/asm-alpha/rwsem.h Mon May 7 16:07:29 2001
@@ -0,0 +1,207 @@
+#ifndef _ALPHA_RWSEM_H
+#define _ALPHA_RWSEM_H
+
+/*
+ * Written by Ivan Kokshaysky [EMAIL PROTECTED], 2001.
+ * Based on asm-alpha/semaphore.h and asm-i386/rwsem.h
+ */
+
+#ifndef _LINUX_RWSEM_H
+#error please dont include asm/rwsem.h directly, use linux/rwsem.h instead
+#endif
+
+#ifdef __KERNEL__
+
+#include linux/list.h
+#include linux/spinlock.h
+
+struct rwsem_waiter;
+
+extern struct rw_semaphore *rwsem_down_read_failed(struct rw_semaphore *sem);
+extern struct rw_semaphore *rwsem_down_write_failed(struct rw_semaphore *sem);
+extern struct rw_semaphore *rwsem_wake(struct rw_semaphore *);
+
+/*
+ * the semaphore definition
+ */
+struct rw_semaphore {
+ longcount;
+#define RWSEM_UNLOCKED_VALUE 0xL
+#define RWSEM_ACTIVE_BIAS 0x0001L
+#define RWSEM_ACTIVE_MASK 0xL
+#define RWSEM_WAITING_BIAS (-0x0001L)
+#define RWSEM_ACTIVE_READ_BIAS RWSEM_ACTIVE_BIAS
+#define RWSEM_ACTIVE_WRITE_BIAS(RWSEM_WAITING_BIAS +
+RWSEM_ACTIVE_BIAS)
+ spinlock_t wait_lock;
+ struct list_headwait_list;
+#if RWSEM_DEBUG
+ int debug;
+#endif
+};
+
+#if RWSEM_DEBUG
+#define __RWSEM_DEBUG_INIT , 0
+#else
+#define __RWSEM_DEBUG_INIT /* */
+#endif
+
+#define __RWSEM_INITIALIZER(name) \
+ { RWSEM_UNLOCKED_VALUE, SPIN_LOCK_UNLOCKED, \
+ LIST_HEAD_INIT((name).wait_list) __RWSEM_DEBUG_INIT }
+
+#define DECLARE_RWSEM(name) \
+ struct rw_semaphore name = __RWSEM_INITIALIZER(name)
+
+static inline void init_rwsem(struct rw_semaphore *sem)
+{
+ sem-count = RWSEM_UNLOCKED_VALUE;
+ spin_lock_init(sem-wait_lock);
+ INIT_LIST_HEAD(sem-wait_list);
+#if RWSEM_DEBUG
+ sem-debug = 0;
+#endif
+}
+
+static inline void __down_read(struct rw_semaphore *sem)
+{
+ long oldcount;
+#ifndefCONFIG_SMP
+ oldcount = sem-count;
+ sem-count += RWSEM_ACTIVE_READ_BIAS;
+#else
+ long temp;
+ __asm__ __volatile__(
+ 1: ldq_l %0,%1\n
+ addq%0,%3,%2\n
+ stq_c %2,%1\n
+ beq %2,2f\n
+ mb\n
+ .subsection 2\n
+ 2: br 1b\n
+ .previous
+ :=r (oldcount), =m (sem-count), =r (temp)
+ :Ir (RWSEM_ACTIVE_READ_BIAS), m (sem-count) : memory);
+#endif
+ if (__builtin_expect(oldcount 0, 0))
+ rwsem_down_read_failed(sem);
+}
+
+static inline void __down_write(struct rw_semaphore *sem)
+{
+ long oldcount;
+#ifndefCONFIG_SMP
+ oldcount = sem-count;
+ sem-count += RWSEM_ACTIVE_WRITE_BIAS;
+#else
+ long temp;
+ __asm__ __volatile__(
+ 1: ldq_l %0,%1\n
+ addq%0,%3,%2\n
+ stq_c %2,%1\n
+ beq %2,2f\n
+ mb\n
+ .subsection 2\n
+ 2: br 1b\n
+ .previous
+ :=r (oldcount), =m (sem-count), =r (temp)
+ :Ir (RWSEM_ACTIVE_WRITE_BIAS), m (sem-count) : memory);
+#endif
+ if (__builtin_expect(oldcount, 0))
+ rwsem_down_write_failed(sem);
+}
+
+static inline void __up_read(struct rw_semaphore *sem)
+{
+ long oldcount;
+#ifndefCONFIG_SMP
+ oldcount = sem-count;
+ sem-count -= RWSEM_ACTIVE_READ_BIAS;
+#else
+ long temp;
+ __asm__ __volatile__(
+ mb\n
+ 1: ldq_l %0,%1\n
+ subq%0,%3,%2\n
+ stq_c %2,%1\n
+ beq %2,2f\n
+ .subsection 2\n
+ 2: br 1b\n
+ .previous
+ :=r (oldcount), =m (sem-count), =r (temp)
+ :Ir (RWSEM_ACTIVE_READ_BIAS), m (sem-count) : memory);
+#endif
+ if (__builtin_expect(oldcount 0, 0))
+ if ((int)oldcount - RWSEM_ACTIVE_READ_BIAS == 0)
+ rwsem_wake(sem);
+}
+
+static inline void __up_write(struct rw_semaphore *sem)
+{
+ long count;
+#ifndefCONFIG_SMP
+ sem-count -= RWSEM_ACTIVE_WRITE_BIAS;
+ count = sem-count;
+#else
Re: [Question] Explanation of zero-copy networking
On Mon, 7 May 2001, Alan Cox wrote: documented so far) detailed description of the newly implemented zero-copy mechanisms in the network-stack. We are interested in how to use it (changed network-API?) and also in the internal architecture. It is built around sendfile. Trying to do zero copy on pages with user space mappings get so horribly non pretty it is better to build the API from the physical side of things. Our second question: Are there any plans for contructing a general copy-avoidance infrastructure (smth. like UVM in NetBSD does) and new IPC-mechanisms on top of it yet?? Andrea Arcangeli has O_DIRECT file I/O for the ext2 file system. There are also several patches for kiovec based single copy pipes have been posted too. The Networking RFCs talk about not copying data as they attempt to give pointers on improving network speed. However, PCI to memory copying runs at about 300 megabytes per second on modern PCs and memory to memory copying runs at over 1,000 megabytes per second. In the future, these speeds will increase. I don't advise retrofitting network code to improve the speed of older machines. Instead, time should be spent to improve the robustness and capability of the networking speed and accommodating the new breeds of GHz network boards. In case anybody is interested, Networking remains a serial communications element. As such, it functions as a low-pass filter. The speed of a serial communications link is set primarily by the dominant pole of the links transfer function, which in the frequency domain, is information_rate * 2. With 100 megabits/second link we have 200 MHz as the dominent pole. The 2 comes from Shannon, it takes 2 carrier events to determine if anything has changed (to transfer information). Therefore, if we can detect changes 100 million times per second, the information carrier must have been at least 200 MHz. This is the dominent pole. With a 300 Megabyte / second transfer via PCI, the information carrier must have been 300 * 8 * 2 = 4,800 MHz. This is 4,800/200 = 24 times the frequency of the dominent pole of the network transfer function. This is so far removed from the dominent pole of the system's transfer function that even doubling the PCI speed (66 MHz v.s. 33 MHz) will have no measurable affect upon networking speed. With existing kernels, you can perform network speed tests using lo, removing the network board from the speed test. You will note that the network speed, due to software, is over 10 times faster, 30 times on some machines) than when the hardware I/O is used. This shows that the network code, alone, cannot be improved very much to provide an improvement in throughput. However, a new breed of GHz boards are now available. These boards have a dominent pole of 1000 * 2 = 2000 MHz. This is rougly one- half of the PCI bandwidth, and roughly the same as a 66 MHz bus. This is where some work needs to be done. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero^H^H^H^Hsingle copy pipe
Manfred Spraul wrote: I'm now running with the patch for several hours, no problems. bw_pipe transfer rate has nearly doubled and the number of context switches for one bw_pipe run is down from 71500 to 5500. Please test it. Any particular reason for not using davem's single copy kiobuf based code? -ben - 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] zero^H^H^H^Hsingle copy pipe
From: Ben LaHaise [EMAIL PROTECTED]
Any particular reason for not using davem's single copy kiobuf based
code?
The main problem is that map_user_kiobuf() locks pages into memory.
It's a bad idea for pipes. Either we must severely limit the maximum
amount of data in the direct-copy buffers, or we must add a swap file
based backing store. If I understand the BSD direct-pipe code correctly
it has a swap file based backing store. I think that's insane. And
limiting the direct copy buffers to a few kB defeats the purpose of
direct copy.
Instead pipe_write just queues (tsk,addr,len), and then pipe_read() uses
a modified access_process_vm() function to copy directly. Currently I've
copied the code from kernel/ptrace.c, but I plan to merge
copy_user_to_user() back into access_process_vm().
And the current pipe_{read,write} are a total mess with nested loops and
gotos. It's possible to create wakeup storms. I rewrote them as well ;-)
But the new code still contains one deadlock :-(
--
Manfred
-
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/
VEXUS VARBusiness @ Special Prices For Computer Resellers
MEMORY Spectek lifetime warranty (Min.Qty. Less 100) $ 9.75 32 MB 168pins PC-100 $ 15.95 64 MB 168pins PC-100/PC-133 $ 28.50 128 MB 168pins PC-100/PC-133 $ 57.50 256 MB 168pins PC-100/PC-133 Hard Drive (Min.Qty. Less 50) $ 72.00 Hard Drive 10GB 5400rpm ATA100 Western Digital $ 83.00 Hard Drive 20GB 5400rpm ATA100 Western Digital $ 96.00 Hard Drive 20GB 7200rpm ATA100 Western Digital $ 98.00 Hard Drive 30GB 5400rpm ATA100 Western Digital $120.00 Hard Drive 30GB 7200rpm ATA100 Western Digital $112.00 Hard Drive 40GB 5400rpm ATA100 Maxtor Mother Board (Min.Qty. Less 20) $58.75 MB PC-Chips 755LMR AT w/V, S, 10/100, 56K $61.75 MB PC-Chips 756LMRT ATX w/V, S, 10/100, 56K $64.75 MB PC-Chips 598LMR AT w/V, S, 10/100, 56K $69.75 MB PC-Chips 810LMR ATX w/V, S, 10/100, 56K $126.50 MB Intel D815EEA2L ATX FC-PGA PC133 w/S, V, 10/100 $125.00 MB Intel D815EEAA ATX FC-PGA PC133 w/S, V $135.00 MB Intel D815EEAAL ATX FC-PGA PC133 w/S, V, 10/100 $108.50 MB Intel D815EPEA2 ATX FC-PGA PC133 w/Sound $107.50 MB Intel CA810E ATX FC-PGA PC133 w/Sound $118.00 MB ASUS CUSL2-C ATX Plain FC-PGA $108.50 MB ASUS CU V4X-E ATX Plain FC-PGA $115.00 MB ASUS CU V4X-E ATX Plain FC-PGA w/sound INTEL FC-PGA-Processors (Min.Qty. Less 30) $ 75.50 Intel Celeron 667Mhz FC-PGA BOX $ 79.80 Intel Celeron 700Mhz FC-PGA BOX $ 83.00 Intel Celeron 733Mhz FC-PGA BOX $ 113.00Pentium III-667EB FC-PGA, 256KB, 133Mhz BOX $ 121.00Pentium III-733EB FC-PGA, 256KB, 133Mhz BOX $ 129.50Pentium III-750EFC-PGA, 256KB, 100Mhz BOX $ 165.00Pentium III-850E FC-PGA, 256KB, 100Mhz BOX $ 174.00Pentium III-866EB FC-PGA, 256KB, 133Mhz BOX $ 164.00Pentium III-866EB FC-PGA, 256KB, 133Mhz OEM $ 204.00Pentium III-933EB FC-PGA, 256KB, 133Mhz BOX $ 191.00Pentium III-933EB FC-PGA, 256KB, 133Mhz OEM $ 235.00Pentium III-1000EB FC-PGA, 256KB, 133Mhz BOX $ 225.00Pentium III-1000EB FC-PGA, 256KB, 133Mhz OEM $ 299.00Pentium 4-1.3GB FC-PGA, 256KB, 133Mhz BOX (min 5 pcs) $ 319.00Pentium 4-1.4GB FC-PGA, 256KB, 133Mhz BOX (min 5 pcs) $ 419.00Pentium 4-1.5GB FC-PGA, 256KB, 133Mhz BOX (min 5 pcs) $ 475.00Pentium 4-1.7GB FC-PGA, 256KB, 133Mhz BOX (min 5 pcs) Video Card (min 80 pcs) $ 20.50 VGA Card AGP 8 MB SIS $ 21.50 VGA Card AGP 8 MB S3 $ 36.50 VGA Card AGP 16 MB ATI $ 39.50 VGA Card AGP 32 MB ATI $149.00 VGA Card AGP 32 MB ATI All in Wonder OEM (min 10pcs) I/O Cards $ 5.95Printer Card ISA LPT-1 $ 7.95Printer Card ISA LPT-1 EPP $ 8.95Printer Card ISA LPT-1 2 Port $ 16.50 Printer Card PCI LPT-1 $ 24.00 ATIO Card PCI (2 Serial, 1 Paralel, 1 Game) $ 13.50 2-USB Card PCI $ 23.00 4-USB Card PCI Sound Card (min 80 pcs) $ 7.99 Sound Card ISA $ 7.99 Sound Card PCI Printers (min 20 pcs) $ 36.00 APOLLO P-1200 3.5/1.5ppm black/color $ 44.50 APOLLO P-2200 6/3ppm black/color $ 44.75 CANON BJC-1000 Color printer 6/4ppm black/color $ 52.50 CANON BJC-2110 Color printer 5/2ppm black/color $ 88.75 CANON BJC-3000 Color Printer 6/4ppm black/Color $ 92.75 HP DeskJet 840C 8/5ppm black/color $283.00 HP DeskJet 970C 12/10ppm black/color (min 10pcs) Scanner (min 10 pcs) $46.50 Optic Pro P12 36Bit 1200x600 DPI $64.75 AFGA E20 36Bit USB 600X1200 DPI $59.00 HP Scanjet 4200cse $93.00 HP Scanjet 3400cxi Monitors (min 20 pcs) $ 95.50 Monitor 14.28 KDS $112.00 Monitor 15 .28 Generic $116.00 Monitor 15 .28 KDS, AOC, Proview $137.00 Monitor 17 .28 Hyundai $147.00 Monitor 17 .28 KDS, AOC, Proview CDR, CDRW Fax Modem (min 30 pcs) $29.00 CD ROM 52X Cyberdrive $34.00 CD ROM 52X Creative Bulk $89.75 CDRW NEC 8x4x32 Bulk $26.00 Fax Modem US Robotic 3COM Bulk $9.25 Fax Modem PCTEL Accessories (min 80pcs) $ 3.75 Keyboard AT or PS2 $ 1.39 Mouse Serial or PS2 2-Bottons $ 3.50 Mouse Serial or PS2 w/scroll $ 0.89 Microphone $ 2.25 Headset $ 3.25 Speaker 180W $24.00 Speaker Flat Benwin Notice: We only send this message to Computer manufacturers/dealers, Resellers, VARs, Computer consultants, Computer repair companies, Software developers, Educational institutions, Government agencies, Corporate and Retail businesses that have interest in our products. If you are receiving this by mistake and would like to be removed, please reply with REMOVE in the subject line of your message. However, due to a computer problem, if we may
Hotswap ATA status ?
Andre , you promised ATA/IDE hot-swap on "normal" hardware several weeks ( months ? ) ago. What happened ? -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - - 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] zero^H^H^H^Hsingle copy pipe
On Mon, 7 May 2001, Manfred Spraul wrote:
The main problem is that map_user_kiobuf() locks pages into memory.
It's a bad idea for pipes. Either we must severely limit the maximum
amount of data in the direct-copy buffers, or we must add a swap file
based backing store. If I understand the BSD direct-pipe code correctly
it has a swap file based backing store. I think that's insane. And
limiting the direct copy buffers to a few kB defeats the purpose of
direct copy.
Okay, how about the following instead (I'm thinking of generic code that
we can reuse): continue to queue the mm, address, length tuple (I've
actually got use for this too), and then use a map_mm_kiobuf (which is
map_user_kiobuf but with an mm parameter) for the portion of the buffer
that's currently being copied. That improves code reuse and gives us a
few primatives that are quite useful elsewhere.
And the current pipe_{read,write} are a total mess with nested loops and
gotos. It's possible to create wakeup storms. I rewrote them as well ;-)
Cool! =)
-ben
-
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] x86 page fault handler not interrupt safe
On Mon, 7 May 2001, Alan Cox wrote: I dont see that we will get a valid value in both cases. get_user fault - set %cr2 IRQ vmalloc fault set %cr2 fixup runs end IRQ cr2 is corrupt Wrong. %cr2 is _not_ corrupt. It has a well-defined value. So what happens is get_user (or user-mode access) fault - set %cr2 to fault1 irq vmalloc fault - set %cr2 to fault2 fixup runs, iret irq runs, iret %cr2 is still %fault2 vmalloc fault - nothing to do false fixup runs, iret get_user (or user-mode access) fault - set %cr2 to fault1 ... get the right behaviour now ... There are a whole set of races with the vmalloc fixups. As far as I can tell, there are no races anywhere. Just silly bugs that are hard to see. Linus - 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/
Update of quota patches
Hello.
I'm sending you update of my quota patches. There are fixed some
syscall issues on ia64, sparc64 and s390x architectures. There's
also one small bugfix (or maybe new feature :)) - general users
are now allowed to get information about quota files. The incremental
patch is attached. Patch with whole new quota format stuff can be found at
(to be applied after quota-fix-2.4.3-1.diff.gz):
ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/quota-patch-2.4.3-2.diff.gz
Honza
--- linux/fs/dquot.c.orig Thu May 3 16:28:40 2001
+++ linux/fs/dquot.cTue May 1 18:07:12 2001
@@ -2027,6 +2027,7 @@
switch (cmds) {
case Q_SYNC:
case Q_GETSTATS:
+ case Q_GETINFO:
break;
case Q_GETQUOTA:
if (((type == USRQUOTA current-euid != id) ||
--- linux/arch/ia64/ia32/sys_ia32.c.origThu May 3 17:07:26 2001
+++ linux/arch/ia64/ia32/sys_ia32.c Thu May 3 17:20:13 2001
@@ -2711,26 +2711,26 @@
return sys_ioperm((unsigned long)from, (unsigned long)num, on);
}
-struct dqblk32 {
-__u32 dqb_bhardlimit;
-__u32 dqb_bsoftlimit;
-__u32 dqb_curblocks;
+struct mem_dqblk32 {
__u32 dqb_ihardlimit;
__u32 dqb_isoftlimit;
__u32 dqb_curinodes;
+__u32 dqb_bhardlimit;
+__u32 dqb_bsoftlimit;
+__u64 dqb_curspace;
__kernel_time_t32 dqb_btime;
__kernel_time_t32 dqb_itime;
};
extern asmlinkage long sys_quotactl(int cmd, const char *special, int id,
- caddr_t addr);
+ __kernel_caddr_t addr);
asmlinkage long
sys32_quotactl(int cmd, const char *special, int id, unsigned long addr)
{
int cmds = cmd SUBCMDSHIFT;
int err;
- struct dqblk d;
+ struct mem_dqblk d;
mm_segment_t old_fs;
char *spec;
@@ -2740,33 +2740,35 @@
case Q_SETQUOTA:
case Q_SETUSE:
case Q_SETQLIM:
- if (copy_from_user (d, (struct dqblk32 *)addr,
- sizeof (struct dqblk32)))
+ if (copy_from_user (d, (struct mem_dqblk32 *)addr,
+ sizeof (struct mem_dqblk32)))
return -EFAULT;
- d.dqb_itime = ((struct dqblk32 *)d)-dqb_itime;
- d.dqb_btime = ((struct dqblk32 *)d)-dqb_btime;
+ d.dqb_itime = ((struct mem_dqblk32 *)d)-dqb_itime;
+ d.dqb_btime = ((struct mem_dqblk32 *)d)-dqb_btime;
break;
default:
return sys_quotactl(cmd, special,
- id, (caddr_t)addr);
+ id, (__kernel_caddr_t)addr);
}
spec = getname32 (special);
err = PTR_ERR(spec);
if (IS_ERR(spec)) return err;
old_fs = get_fs ();
set_fs (KERNEL_DS);
- err = sys_quotactl(cmd, (const char *)spec, id, (caddr_t)d);
+ err = sys_quotactl(cmd, (const char *)spec, id, (__kernel_caddr_t)d);
set_fs (old_fs);
putname (spec);
+ if (err)
+ return err;
if (cmds == Q_GETQUOTA) {
__kernel_time_t b = d.dqb_btime, i = d.dqb_itime;
- ((struct dqblk32 *)d)-dqb_itime = i;
- ((struct dqblk32 *)d)-dqb_btime = b;
- if (copy_to_user ((struct dqblk32 *)addr, d,
- sizeof (struct dqblk32)))
+ ((struct mem_dqblk32 *)d)-dqb_itime = i;
+ ((struct mem_dqblk32 *)d)-dqb_btime = b;
+ if (copy_to_user ((struct mem_dqblk32 *)addr, d,
+ sizeof (struct mem_dqblk32)))
return -EFAULT;
}
- return err;
+ return 0;
}
extern asmlinkage long sys_utime(char * filename, struct utimbuf * times);
--- linux/arch/s390x/kernel/linux32.c.orig Thu May 3 16:59:51 2001
+++ linux/arch/s390x/kernel/linux32.c Thu May 3 17:20:55 2001
@@ -897,18 +897,18 @@
return sys32_fcntl(fd, cmd, arg);
}
-struct dqblk32 {
-__u32 dqb_bhardlimit;
-__u32 dqb_bsoftlimit;
-__u32 dqb_curblocks;
+struct mem_dqblk32 {
__u32 dqb_ihardlimit;
__u32 dqb_isoftlimit;
__u32 dqb_curinodes;
+__u32 dqb_bhardlimit;
+__u32 dqb_bsoftlimit;
+__u64 dqb_curspace;
__kernel_time_t32 dqb_btime;
__kernel_time_t32 dqb_itime;
};
-extern asmlinkage int sys_quotactl(int cmd, const char *special, int id, caddr_t
addr);
+extern asmlinkage long sys_quotactl(int cmd, const char *special, int id,
+__kernel_caddr_t addr);
asmlinkage int sys32_quotactl(int cmd, const char *special, int id, unsigned long
addr)
{
@@ -924,33 +924,35 @@
case Q_SETQUOTA:
case Q_SETUSE:
case
Re: [PATCH] zero^H^H^H^Hsingle copy pipe
[Stuff about NetBSD pipes snipped] I'm testing out Manfred's patch for zero copy pipes, and haven't crashed it yet. My hardware is a AMD K6-2 (stepping 1) on an ALi M1541 with 320 Mb - one quite slow 64 Mb stick and one fast 256 Mb stick. The lmbench bw_pipe showed a performance improvement of about 30% from 45 (+- 2) Mb/s to 59.5 (+-0.6) Mb/s. The lmbench (2beta3) lat_pipe showed a performance improvement of about 20% from a latency of about 27 (+- 1) usec to about 22.4 (+-.6) usec. There was one outlyer amoung the 10 non zc pipe runs - 25 usec. For zc, the first run was always about 25 usec and after that very stable around 22 usec. FWIW the system time from time when running (bw_pipe;lat_pipe) 10 times in a row *increased* by 50%, from sys 0m18.740s to sys 0m31.660s. Script: for i in 1 2 3 4 5 6 7 8 9 10; do ./bw_pipe; ./lat_pipe; done Non zero copy: real0m49.602s user0m10.170s sys 0m18.740s Zero copy run 1: real0m47.901s user0m10.390s sys 0m31.660s Zero copy run 2: real0m47.492s user0m10.600s sys 0m31.340s -- http://ape.n3.net - 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/
linux + Compaq Presario Laptop
Hello linux-kernel,
Hi !! I'm running linux on Compaq Presario 1215 Laptop. Kernel is,
as shipped with RH 7.0, 2.2.16. So, every time I press any of
sound+- buttons [of Fn+Fx {Fn = functional button, used in
conjunction with F1-F8 to alter various laptop-specific settings, and
to activate sleep mode, for example} ], linux crashes saying: unable
to handle kernel-paging request at virtual address 5b18, and lot
more (I can type it here, thought, I'm not sure if it's required, and
it'll consume lots of time to type it precisely).
I guess it's not desired behavior as for stable system, and it
should be fixed. I don't know if it's fixed already, just because
today I have no means to transport 25M kernel to small laptop
(moreover, there's no free space to compile kernel there), however,
I'm going to solve it soon. I'm sorry if it's fixed already, or any
stable and correct solution exists, and I'd be glad to hear about it.
It not, I'd be glad to assist in investigating this problem.
It's quite possible that I've got mailing list to submit my
blubbering at, and if so, I'm sorry for the abuse.
thanks.
--
Best regards,
Bohdan mailto:[EMAIL PROTECTED]
-
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] x86 page fault handler not interrupt safe
On Mon, 7 May 2001, Alan Cox wrote:
That is nice. I hadn't thought about doing it that way. It still has the problem
if %cr2 is corrupted by a vmalloc fault but it cleans up my other code paths
nicely.
See about corruption in previous email. It doesn't exist.
For better debugging, we should probably walk the whole init_mm page table
tree when we take the fault, so this patch does that too: it
unconditionally copies the init_mm page table entries into the current
page table, while at the same time checking that they exist (including the
very last level that we didn't use to check at all).
This means that if you access one page past a vmalloc'ed area, you will
get a nice oops instead of endless page faults that will fix up the page
tables with mappings that already exist.
Untested.
In particular, does anybody have a buggy Pentium to test with the F0 0F
lock-up bug? It _should_ be caught with the error-code test (it's a
protection fault, not a non-present fault and thus the F0 0F case never
enters the vmalloc path), but it's been several years since the thing..
If anybody has such a beast, please try this kernel patch _and_ running
the F0 0F bug-producing program (search for it on the 'net - it must be
out there somewhere) to verify that the code still correctly handles that
case.
Linus
-
--- v2.4.4/linux/arch/i386/mm/fault.c Mon Mar 19 12:35:09 2001
+++ linux/arch/i386/mm/fault.c Mon May 7 10:01:37 2001
@@ -127,8 +127,12 @@
* be in an interrupt or a critical region, and should
* only copy the information from the master page table,
* nothing more.
+*
+* This verifies that the fault happens in kernel space
+* (error_code 4) == 0, and that the fault was not a
+* protection error (error_code 1) == 0.
*/
- if (address = TASK_SIZE)
+ if (address = TASK_SIZE !(error_code 5))
goto vmalloc_fault;
mm = tsk-mm;
@@ -224,7 +228,6 @@
bad_area:
up_read(mm-mmap_sem);
-bad_area_nosemaphore:
/* User mode accesses just cause a SIGSEGV */
if (error_code 4) {
tsk-thread.cr2 = address;
@@ -322,27 +325,32 @@
/*
* Synchronize this task's top level page-table
* with the 'reference' page table.
+*
+* Do _not_ use tsk here. We might be inside
+* an interrupt in the middle of a task switch..
*/
int offset = __pgd_offset(address);
pgd_t *pgd, *pgd_k;
pmd_t *pmd, *pmd_k;
+ pte_t *pte_k;
- pgd = tsk-active_mm-pgd + offset;
+ asm(movl %%cr3,%0:=r (pgd));
+ pgd = offset + (pgd_t *)__va(pgd);
pgd_k = init_mm.pgd + offset;
- if (!pgd_present(*pgd)) {
- if (!pgd_present(*pgd_k))
- goto bad_area_nosemaphore;
- set_pgd(pgd, *pgd_k);
- return;
- }
-
+ if (!pgd_present(*pgd_k))
+ goto no_context;
+ set_pgd(pgd, *pgd_k);
+
pmd = pmd_offset(pgd, address);
pmd_k = pmd_offset(pgd_k, address);
-
- if (pmd_present(*pmd) || !pmd_present(*pmd_k))
- goto bad_area_nosemaphore;
+ if (!pmd_present(*pmd_k))
+ goto no_context;
set_pmd(pmd, *pmd_k);
+
+ pte_k = pte_offset(pmd_k, address);
+ if (!pte_present(*pte_k))
+ goto no_context;
return;
}
}
-
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: 2.2.20pre1: Problems with SMP
On Mon, May 07, 2001 at 11:36:49AM +0100, Alan Cox wrote: Just booted up 2.2.20pre1 and am getting some funny results. The system boots but is very slow. Every few seconds I get: Stuck on TLB IPI wait (CPU#0) Booting vanilla 2.2.19 works fine. The machine is an Intel Pentium III 850MHZ on an Abit VP6 board. If any further information is needed, let me know. Can you back out the change to io_apic.c and tell me if that fixes it. If so let Johannes Erdfelt and I know. That does indeed correct the problem. 2.2.20pre1 now works as expected. Shane -- Shane Wegner: [EMAIL PROTECTED] http://www.cm.nu/~shane/ PGP: 1024D/FFE3035D A0ED DAC4 77EC D674 5487 5B5C 4F89 9A4E FFE3 035D - 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] x86 page fault handler not interrupt safe
[EMAIL PROTECTED] said: If anybody has such a beast, please try this kernel patch _and_ running the F0 0F bug-producing program (search for it on the 'net - it must be out there somewhere) to verify that the code still correctly handles that case. Something along the lines of: echo unsigned long main=0xf00fc7c8; f00fbug.c ; make f00fbug -- dwmw2 - 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] 2.4 add suffix for uname -r
Hi, Keith! A frequent requirement is to rename vmlinuz-2.x.y to 2.x.y-old or 2.x.y.save to preserve a working kernel. But renaming the image does not change the value of uname -r so it still tries to use modules 2.x.y, which defeats the purpose of saving an working kernel. Thank you for the patch and for taking care of the problem! I've tested it and it works for me. I'm using kernel modules and ALSA. Objects that know the value of uname -r that they were compiled with will not work with unamersfx. Are there any? floppy hardcodes the version but doesn't protest. inserting floppy driver for 2.4.4-ac5 Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 # uname -a Linux fonzie 2.4.4-ac5-new #3 Mon May 7 12:06:39 EDT 2001 i686 unknown -- Regards, Pavel Roskin - 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] x86 page fault handler not interrupt safe
From: David Woodhouse [mailto:[EMAIL PROTECTED]] [EMAIL PROTECTED] said: If anybody has such a beast, please try this kernel patch _and_ running the F0 0F bug-producing program (search for it on the 'net - it must be out there somewhere) to verify that the code still correctly handles that case. Something along the lines of: echo unsigned long main=0xf00fc7c8; f00fbug.c ; make f00fbug Yes, that's what the (SGI) program uses: http://lwn.net/2001/0329/a/ltp-f00f.php3 ~Randy - 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][RFT] smbfs bugfixes for 2.4.4
In article [EMAIL PROTECTED], Xuan Baldauf [EMAIL PROTECTED] wrote: it does not fix|work around the bug completely: 1. windows: Create a file, e.g. with 741 bytes. 2. linux: ls -la will show you the file with the correct size (741) 3. linux: read the file into your smbfs cache (e.g. less file) 4. windows: add some contents to the file, e.g. so that it is now 896 bytes long 5. linux: ls -la will show you the file with the correct size (896) 6. linux: read the file (e.g. less file) What you should see, on the linux box, are the new contents of the file. What you will see are the old contents of the file plus a lot ^@^@^@^@^@^@^@ (which mean null bytes) at the end of the old contents. This is a different problem. Apparently the Linux client does not invalidate its caches sufficiently often. The smb client should at least do a invalidate_inode_pages(inode); when it notices that the file size has changed. It has code to do that in smb_revalidate_inode(), but it may be that something else refreshes the inode size _without_ doing the proper invalidation checks. Or maybe Urban broke that logic by mistake while fixing the other one ;) Linus - 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] x86 page fault handler not interrupt safe
[EMAIL PROTECTED] said: echo unsigned long main=0xf00fc7c8; f00fbug.c ; make f00fbug Yes, that's what the (SGI) program uses: http://lwn.net/2001/0329/a/ltp-f00f.php3 Restated on l-k for the benefit of anyone naïve enough to expect me to have got it right... my original version would only work on the bigendian models. For the rest, try: echo unsigned main = 0xc8c70ff0; f00fbug.c ; make f00fbug -- dwmw2 - 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] x86 page fault handler not interrupt safe
At 18:32 07/05/2001, Dunlap, Randy wrote: From: David Woodhouse [mailto:[EMAIL PROTECTED]] [EMAIL PROTECTED] said: If anybody has such a beast, please try this kernel patch _and_ running the F0 0F bug-producing program (search for it on the 'net - it must be out there somewhere) to verify that the code still correctly handles that case. Something along the lines of: echo unsigned long main=0xf00fc7c8; f00fbug.c ; make f00fbug Yes, that's what the (SGI) program uses: http://lwn.net/2001/0329/a/ltp-f00f.php3 That's not quite what they do. David's SGI equivalent would be: echo unsigned long main=0xc8c70ff0; f00fbug.c ; make f00fbug i.e. remember that ia32 is little endian. Thanks for the link. Best regards, Anton -- Anton Altaparmakov aia21 at cam.ac.uk (replace at with @) Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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: [Question] Explanation of zero-copy networking
Richard B. Johnson [EMAIL PROTECTED] ecrit : [...] when the hardware I/O is used. This shows that the network code, alone, cannot be improved very much to provide an improvement in throughput. It shows that cached code performs well with ~0us latency device/memory. Networking is about latency and pps too. They both dramatically reduce the (axe-)evaluated bandwith. -- Ueimor - 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: page_launder() bug
In article [EMAIL PROTECTED], BERECZ Szabolcs [EMAIL PROTECTED] wrote: there is a bug in page_launder introduced with kernel 2.4.3-ac12. Yes. The whole dead_swap_page optimization in the -ac tree is apparentrly completely bogus. It caches a value that is not valid: you cannot reliably look at whether the page has buffers etc without holding the page locked. So calculating dead_swap_page without locking the page first is a sure way to cause trouble. I can see why the bug was introduced: standard kernels _optimistically_ test whether the condition might be true before they lock the page, and decide to not even try to touch pages that look like they are probably going to be considered active. But it is important to re-calculate the deadness after getting the lock. Before, it was just an informed guess. After the lock, it is knowledge. And you can use informed guesses for heuristics, but you must _not_ use them for any serious decisions. Alan, please revert. Linus - 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: 2.2.20pre1: Problems with SMP
On Mon, May 07, 2001, Shane Wegner [EMAIL PROTECTED] wrote: On Mon, May 07, 2001 at 11:36:49AM +0100, Alan Cox wrote: Just booted up 2.2.20pre1 and am getting some funny results. The system boots but is very slow. Every few seconds I get: Stuck on TLB IPI wait (CPU#0) Booting vanilla 2.2.19 works fine. The machine is an Intel Pentium III 850MHZ on an Abit VP6 board. If any further information is needed, let me know. Can you back out the change to io_apic.c and tell me if that fixes it. If so let Johannes Erdfelt and I know. That does indeed correct the problem. 2.2.20pre1 now works as expected. Hmm, that uses a VIA based chipset. I didn't know they did SMP yet. Does 2.4 work on this system? JE - 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: [Question] Explanation of zero-copy networking
On Mon, 7 May 2001, Francois Romieu wrote: It shows that cached code performs well with ~0us latency device/memory. Networking is about latency and pps too. They both dramatically reduce the (axe-)evaluated bandwith. I think his point is more along the lines of return on investment. You can tweak linux to move from 9MB/sec to 9.5MB/sec on a 100Mb link, or you can spend those same developer cycles getting much larger returns out of much sexier hardware. Now, who's gonna supply us with those NICs? ;) -- Blue Langhttp://www.gator.net/~blue Unix Administrator Veritas Software 2315 McMullan Circle, Raleigh, North Carolina, USA 919 835 1540 - 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: what causes Machine Check exception? revisited (2.2.18)
On Mon, 7 May 2001, Bene, Martin wrote: [MCE caused by bad RAM] I don't think there is a way a machine check exception can be triggered by software - which it would have to be in order to be caused by bad RAMs. A MCE is triggered by an ECC error - no software involved. A good trap handler will then see if the error is recoverable (one-bit errors are), notify userspace (so the admin gets mailed) and move the data out of this page. Simon -- GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! - 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/
[PATCH] kernel-api book should also include kernel/module.c
Hi, This patch fixes a minor bug the Kernel API book: it should include the functions in kernel/module.c as well. The patch is against linux-2.4.4, but should work as well against 2.4.5-pre1 and 2.4.4-ac5. Please apply. Erik PS: Thanks to Timur Tabi for pointing out this bug. Index: Documentation/DocBook/Makefile === RCS file: /home/erik/cvsroot/elinux/Documentation/DocBook/Makefile,v retrieving revision 1.1.1.25 diff -u -r1.1.1.25 Makefile --- Documentation/DocBook/Makefile 2001/04/26 12:44:59 1.1.1.25 +++ Documentation/DocBook/Makefile 2001/05/07 17:51:15 @@ -95,6 +98,7 @@ $(TOPDIR)/kernel/pm.c \ $(TOPDIR)/kernel/ksyms.c \ $(TOPDIR)/kernel/kmod.c \ + $(TOPDIR)/kernel/module.c \ $(TOPDIR)/kernel/printk.c \ $(TOPDIR)/kernel/sched.c \ $(TOPDIR)/kernel/sysctl.c \ Index: Documentation/DocBook/kernel-api.tmpl === RCS file: /home/erik/cvsroot/elinux/Documentation/DocBook/kernel-api.tmpl,v retrieving revision 1.1.1.20 diff -u -r1.1.1.20 kernel-api.tmpl --- Documentation/DocBook/kernel-api.tmpl 2001/04/26 12:45:00 1.1.1.20 +++ Documentation/DocBook/kernel-api.tmpl 2001/05/07 17:59:04 @@ -140,8 +140,13 @@ /chapter chapter id=modload - titleModule Loading/title + titleModule Support/title + sect1titleModule Loading/title !Ekernel/kmod.c + /sect1 + sect1titleInter Module support/title +!Ekernel/module.c + /sect1 /chapter chapter id=hardware -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - 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: 2.2.20pre1: Problems with SMP
On Mon, May 07, 2001 at 11:02:50AM -0700, Johannes Erdfelt wrote: On Mon, May 07, 2001, Shane Wegner [EMAIL PROTECTED] wrote: That does indeed correct the problem. 2.2.20pre1 now works as expected. Hmm, that uses a VIA based chipset. I didn't know they did SMP yet. Does 2.4 work on this system? The last 2.4 kernel I tried was 2.4.3 I believe and it worked fine more or less. I haven't tried any later 2.4 kernels yet. Shane -- Shane Wegner: [EMAIL PROTECTED] http://www.cm.nu/~shane/ PGP: 1024D/FFE3035D A0ED DAC4 77EC D674 5487 5B5C 4F89 9A4E FFE3 035D - 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: 2.2.20pre1: Problems with SMP
On Mon, May 07, 2001, Shane Wegner [EMAIL PROTECTED] wrote: On Mon, May 07, 2001 at 11:02:50AM -0700, Johannes Erdfelt wrote: On Mon, May 07, 2001, Shane Wegner [EMAIL PROTECTED] wrote: That does indeed correct the problem. 2.2.20pre1 now works as expected. Hmm, that uses a VIA based chipset. I didn't know they did SMP yet. Does 2.4 work on this system? The last 2.4 kernel I tried was 2.4.3 I believe and it worked fine more or less. I haven't tried any later 2.4 kernels yet. That's fine. The I/O APIC code is different and I tried to make the 2.2 code work like the 2.4 code with minimal changes. However, the changes aren't trivial. I'll take a quick look and see if I can find any more significant differences. I wonder if I have a VIA board laying around here. JE - 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: [Question] Explanation of zero-copy networking
On Mon, 7 May 2001, Alan Cox wrote: documented so far) detailed description of the newly implemented zero-copy mechanisms in the network-stack. We are interested in how to use it (changed network-API?) and also in the internal architecture. It is built around sendfile. Trying to do zero copy on pages with user space mappings get so horribly non pretty it is better to build the API from the physical side of things. so there's still single copy for write() of a mmap()ed page? since i'm naive about the high-end databases -- do they have a mechanism to access zero-copy? i suppose sendfile() on a raw device fd would work... nice. -dean - 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: what causes Machine Check exception? revisited (2.2.18)
On Mon, 7 May 2001, Simon Richter wrote: On Mon, 7 May 2001, Bene, Martin wrote: Definitely not caused by: Bad Rams, mb-chipset. Erm, it was bad RAM everytime it happened to me. On standard PCs, you don't see those because you don't have ECC and the error is simply not detected. So a 440bx motherboard with ECC ram is a non-standard PC? -Dan - 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: Hotswap ATA status ?
On Mon, 7 May 2001, David Balazic wrote: Andre , you promised ATA/IDE hot-swap on normal hardware several weeks ( months ? ) ago. What happened ? -- David Balazic -- Be excellent to each other. - Bill Ted - - - - - - - - - - - - - - - - - - - - - - Well lets see. I lost my ISP (NorthPoint + PacBell)4/18/2001 There was a T13 meeting the following week. 4/23/2001 Found a flaw in the tests of writecaching. Reverified the contents of the CODE base to match SPEC 4/29/2001 Reverified that certain hosts are not good. (oh two kids that were ill and then the wife) Reconfigure the CAVE where I do all of my work. Write 90% of 48-bit LBA, use/test the hostswap for large/huge drives. Look at the user API and chuckled then cried and roared aloud.. Figure out License for the ide-service.o module. It will not be GPL but a very strict LAD (BSD-ish) License. Reasons will follow, but I will not be liable for stupid usage. So if you are reallying dying to test code that has not been full shaken down and requires a huge page for the glue, I will post one. The service utility is not ready yet so it is no good without one. Regards, Andre Hedrick Linux ATA Development PS I left a dump here and there.but that was going to be WTMI - 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: [Question] Explanation of zero-copy networking
On Mon, 7 May 2001, Richard B. Johnson wrote: when the hardware I/O is used. This shows that the network code, alone, cannot be improved very much to provide an improvement in throughput. doesn't your analysis assume that we've got nothing else interesting to do while doing the network i/o? for example, i may want to do something else which needs the memory bandwidth i'd otherwise spend on a single-copy... -dean - 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: [Question] Explanation of zero-copy networking
On Mon, May 07, 2001 at 12:12:57PM -0400, Richard B. Johnson wrote: you can perform network speed tests using lo, removing the network board from the speed test. You will note that the network speed, due to software, is over 10 times faster, 30 times on some machines) than when the hardware I/O is used. This shows that the network code, alone, cannot be improved very much to provide an improvement in throughput. I'd say more like a factor of 2. Socket bandwidth using localhost: 141.63 MB/sec Socket bandwidth using 192.168.9.3: 74.79 MB/sec (with the boxes being able to do ~= 100MB/s when the receiver CPU/mem bandwidth isn't limiting things). So I have slow pIII/500 class machines with fast networking. You could rerun the test with your favourite multi-gigabit network and latest 1.7GHz PC and still have a similar ratio. Being on the bleeding edge isn't easy, and waiting for a few years for faster hardware isn't a solution for everyone ;) Zero-copy mostly helps against CPU use (where it'll make your heavily loaded server be able to serve a lot more connections), not so much against bandwidth. The receiver will still run into problems with the copy it has to do unless you do some very evil tricks like header-splitting+MMU tricks or run protocols designed to be accelerated in hardware. Not that zero-copy isn't problem-free. If your bus starts corrupting random bits there's no way of really noticing it since the NIC happily creates a correct TCP checksum based on the corrupt data. It's not like hardware engineers can be expected to design hardware that works according to spec :) Then there's the interrupt problem, which someone will have to solve before they start shipping 10gigE NICs that use 1500-byte frames, 85 interrupts/s without mitigation. Wh -- Pekka Pietikainen - 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: what causes Machine Check exception? revisited (2.2.18)
Yep, totally. I've worked on hundreds of systems and less than 20 of the workstations or PCs have been useing ECC. Most servers do, but not even all of them. Nick On Mon, 7 May 2001, Dan Hollis wrote: On Mon, 7 May 2001, Simon Richter wrote: On Mon, 7 May 2001, Bene, Martin wrote: Definitely not caused by: Bad Rams, mb-chipset. Erm, it was bad RAM everytime it happened to me. On standard PCs, you don't see those because you don't have ECC and the error is simply not detected. So a 440bx motherboard with ECC ram is a non-standard PC? -Dan - 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/ - 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] x86 page fault handler not interrupt safe
At 18:12 07/05/2001, Linus Torvalds wrote: Untested. In particular, does anybody have a buggy Pentium to test with the F0 0F lock-up bug? Yes, I have one. 2.4.3-ac6 (plus a few patches) detects the bug on boot up and enables the work around. Running the f00f test program from SGI results in the correct behaviour of a SIGILL signal being sent to the program. If anybody has such a beast, please try this kernel patch _and_ running Oh my, I always considered it as a cute, fluffy bunny. No need to bestialize it unnecessarily... (-; the F0 0F bug-producing program (search for it on the 'net - it must be out there somewhere) to verify that the code still correctly handles that case. Am compiling 2.4.5-pre1 with your patch (manually applied as parts of it were already in .5-pre1) right now. I will follow-up with results when it has finished and I have tested it (i.e. don't hold your breath, it might be a beast but it is a slow one...) Best regards, Anton -- Anton Altaparmakov aia21 at cam.ac.uk (replace at with @) Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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: linux + Compaq Presario Laptop
On Mon, May 07, 2001 at 08:06:52PM +0300, Bohdan Vlasyuk wrote:
Hi !! I'm running linux on Compaq Presario 1215 Laptop. Kernel is,
as shipped with RH 7.0, 2.2.16. So, every time I press any of
sound+- buttons [of Fn+Fx {Fn = functional button, used in
conjunction with F1-F8 to alter various laptop-specific settings, and
to activate sleep mode, for example} ], linux crashes saying: unable
to handle kernel-paging request at virtual address 5b18, and lot
more (I can type it here, thought, I'm not sure if it's required, and
it'll consume lots of time to type it precisely).
That's ACPI kicking in. The kernel you're using is quite old, and it
doesn't know about the BIOS e820 memory detection call. The kernel will
just use all memory, including memory that is also used by some ACPI
tables. When you press one of the magic buttons, the ACPI BIOS expects
the tables to be correct and jumps right into kernel code.
I guess it's not desired behavior as for stable system, and it
should be fixed. I don't know if it's fixed already, just because
today I have no means to transport 25M kernel to small laptop
(moreover, there's no free space to compile kernel there), however,
I'm going to solve it soon. I'm sorry if it's fixed already, or any
stable and correct solution exists, and I'd be glad to hear about it.
It not, I'd be glad to assist in investigating this problem.
Try linux-2.2.19, it contains BIOS e820 support. If you don't want to
compile a kernel, check if Red Hat has RPMs available somewhere on
their site. If you really can't use that, use the boot option mem=1MB
less than the machine actually has (so that's mem=127M for an 128MB
machine).
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
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: [Solved ?] Re: pcmcia problems after upgrading from 2.4.3-ac7 to 2.4.4
The thing that confused me here was the help text in menuconfig. The help for CONFIG_I82365 says, Say Y here to include support for PCMCIA and CardBus host bridges that are register compatible with the Intel i82365 and/or the Yenta specification: this includes virtually all modern PCMCIA bridges. Also, the help text for both this option and CONFIG_CARDBUS say, If unsure, say Y, so I selected both of them. It wasn't until Jeff Garzik set me straight recently that I began disabling CONFIG_I82365 and using CONFIG_CARDBUS alone. Wayne David Woodhouse [EMAIL PROTECTED] on 05/07/2001 03:58:00 AM To: Martin.Knoblauch [EMAIL PROTECTED] cc: Alan Cox [EMAIL PROTECTED], [EMAIL PROTECTED] (bcc: Wayne Brown/Corporate/Altec) Subject: Re: [Solved ?] Re: pcmcia problems after upgrading from 2.4.3-ac7 to 2.4.4 [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. -- dwmw2 - 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/ - 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: Wow! Is memory ever cheap!
Followup to: [EMAIL PROTECTED] By author:Larry McVoy [EMAIL PROTECTED] In newsgroup: linux.dev.kernel On Sun, May 06, 2001 at 02:20:43PM +1200, Chris Wedgwood wrote: 1.5GB without ECC? Seems like a disater waiting to happen? Is ECC memory much more expensive? Almost twice as expensive for 512MB dimms. I used to be a die hard ECC fan but that changed since what we do here is BitKeeper and BitKeeper checksums everything. It tells us right away when we have problems (to date it has found bad memory dimms, NFS corruption, and a SPARC/Linux cache aliasing bug). So I've given up in ECC, we don't need it. On the other hand, if your apps don't have built in integrity checks then ECC is pretty much a requirement. Isn't this pretty much saying if you're willing to dedicate your system to running nothing but Bitkeeper, you can run it really fast? -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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: what causes Machine Check exception? revisited (2.2.18)
On Mon, 7 May 2001, Dan Hollis wrote: Erm, it was bad RAM everytime it happened to me. On standard PCs, you don't see those because you don't have ECC and the error is simply not detected. So a 440bx motherboard with ECC ram is a non-standard PC? I bet the board doesn't force you to use ECC RAM, so manufacturers will not use it because it's too expensive and the average customer doesn't understand what memory is and what it's used for. So yes, it's non-standard. Simon -- GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! - 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: linux + Compaq Presario Laptop
Erik Mouw [EMAIL PROTECTED] writes: Try linux-2.2.19, it contains BIOS e820 support. If you don't want to compile a kernel, check if Red Hat has RPMs available somewhere on their site. They do; there was a kernel errata release of 2.2.19 for security reasons. On updates.redhat.com or a mirror. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan - 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/
