From: "Chris Wedgwood" <[EMAIL PROTECTED]>
To: "Alan Cox" <[EMAIL PROTECTED]>
> We ran 1.2.13lmp for about 1100 days before the box finally got
> turned off - twice around the uptime clock and more
>
> That's must be some kind of unofficial record... I though 400+ days
> was pretty
Linus,
The patch below adds the ability to filter packets going through a PPP
interface. This allows users to specify that certain types of packets
are not to count as activity, i.e. they don't reset the idle timer or
bring up a demand-dialled link. This is something I have been getting
a lot
The AGP patches add some code to __ioremap. That code seems to me to
have a fencepost error.
In the below hunk, note that temp_end is set to "temp_addr+(size-1)".
It points _at_ the last page to be examined, not beyond it. So the
loop should be controlled by a "<=" test, not a "<" test.
First, thanks, Alan, for using the USB and AGP patches. You just
saved me a bunch of integration work.
I'd like to suggest the below patches for the AGP i810 driver.
[1] I'm largely in the dark with AGP, but I know for a fact that with
my previous AGP driver -- which was, like the one you
I'm not sure if __attribute__((unused)) has an equivalent in gcc 2.7,
but as it appears in the AGP driver, it doesn't work with gcc 2.7.
Below is the patch I used to get AGP to compile, but I don't recommend
it for adoption in the standard source tree.
Index: drivers/char/drm/ffb_drv.c
---
The modification of slab.c in 2.2.18pre2 seems to be missing a "return"
in kmem_cache_shrink():
Index: mm/slab.c
--- mm/slab.c.prev
+++ mm/slab.c Fri Sep 1 21:16:45 2000
@@ -1048,5 +1048,5 @@ found:
int kmem_cache_shrink(kmem_cache_t *cachep)
{
- __kmem_cache_shrink(cachep,0);
+
On Sat, 2 Sep 2000, Andi Kleen wrote:
> > tid = clone(CLONE_PID);
>
> I'm not sure this will work very well (2.4.0test8-pre1):
Well, the above was written back when I hadn't done "CLONE_THREAD", so you
should really read CLONE_THREAD instead of CLONE_PID with the
On Fri, Sep 01, 2000 at 11:40:06PM -0400, Chris Kloiber wrote:
> What is the deal here? I have NEVER seen anyboody flatly refuse email
> from me. Are you telling me I have to go into work and use my
> [EMAIL PROTECTED] email address to talk to Alan? That's asinine.
> > <<< 550-untestable -
At 04:15 PM 9/1/00 -0700, you wrote:
>And if got lost. That should tell you something. Perhaps something like
>"*Advanced interface support for USB, FireWire, and AGP!"
>
>Then place any expostulatory text indented under that as complete sentences.
>This treates the bulleted items as
At 22:48 01/09/00, Michael Bacarella wrote:
>Q: Why do we need threads?
>A: Because on some operating systems, task switches are expensive.
>
>Q: So, threads are a hack to get around operating systems that suck?
>A: Basically.
urgh, i think you've missed the point.
while threads /may/ be
What is the deal here? I have NEVER seen anyboody flatly refuse email
from me. Are you telling me I have to go into work and use my
[EMAIL PROTECTED] email address to talk to Alan? That's asinine.
Mail Delivery Subsystem wrote:
>
> The original message was received at Fri, 1 Sep 2000 23:26:32
On Fri, 1 Sep 2000, Michael Bacarella wrote:
>Q: Why do we need threads?
>A: Because on some operating systems, task switches are expensive.
>
>Q: So, threads are a hack to get around operating systems that suck?
>A: Basically.
Am I understanding correctly then that using fork() is
On Fri, 1 Sep 2000, Michael Bacarella wrote:
> Q: Why do we need threads?
> A: Because on some operating systems, task switches are expensive.
maybe this problem will help you understand threads better:
design a webserver which supports SSL session keys. consider the
performance of
Q: Why do we need threads?
A: Because on some operating systems, task switches are expensive.
Q: So, threads are a hack to get around operating systems that suck?
A: Basically.
Q: So, why must Linux support threads?
A1: : |
A2: So other programs can be easily ported to Linux!
That can
According to David S. Miller:
>o Acenic 0.45 fixes (Chip Salzenberg)
>
> This adds a huge comment claiming to fix some race condition,
> but no actual code is changed. How can this be? :-)
The bug fix was already in. The log message is misleading.
--
Chip
DaveM pointed out that my 2.4.0-test8-pre1 do_fork patch would generate
better sparc assembler if the extra parameter to do_fork was added at
the end instead of in the middle. So change all do_fork(flags,sp,0,)
to do_fork(flags,sp,,0);
I'm not going to mail the complete patch again, you can get
On Thu, 31 Aug 2000 17:12:03 +0100 (BST)
Alan Cox <[EMAIL PROTECTED]> wrote:
>> Now the device behaves just like memory to the BIOS during POST
>> etc, and is in fact, exactly memory if no device drivers are
>> loaded. If a device driver is loaded and it detects one or more
>> of these devices
Hi,
On Thu, 31 Aug 2000, Alexander Viro wrote:
> Go ahead, write it. IMNSHO it's going to be much more complicated and
> race-prone, but code talks. If you will manage to write it in clear and
> race-free way - fine. Frankly, I don't believe that it's doable.
It will be insofar more
All,
Fixed up a few suggested "buglets" in the release, notably inconsistencies
in the grammar, etc. I won't bother you with big posts, so it's at
http://dustpuppy.ods.org/press-release - just grab it from there.
Still to do is to rewrite half the stuff, and to merge the longer details
into
Hi,
Please consider applying.
- Arnaldo
--- linux-2.4.0-test8-pre1/drivers/net/lne390.c Mon Jun 19 17:30:58 2000
+++ linux-2.4.0-test8-pre1.acme/drivers/net/lne390.cFri Sep 1 15:36:19 2000
@@ -26,10 +26,13 @@
You can try
"Andi Kleen" <[EMAIL PROTECTED]> writes:
> So you have a different way to implement pthread_create without context
> switch to the thread manager in 2.4 ?
It should be possible to do these things with CLONE_PARENT. It's a
long weekend coming up, let's see what I have next week.
--
"Andi Kleen" <[EMAIL PROTECTED]> writes:
> But I guess you don't want the context switch to a thread manager just to
> generate a thread ? (and which is one of the main causes of the bad thread
> creation latency in Linux currently)
The thread manager, is I see it in the moment, will consist
This patch hits every arch so it is being cross mailed to every arch
mailing list, apologies for duplicates. Please trim replies to the
relevant mailing list. Also please cc: [EMAIL PROTECTED] on replies, I
am not on every list.
IA64 needs an extra parameter on do_fork() and copy_thread(),
I'm seeing a problem between Linux 2.2 and BSD/OS 4.1 in the situation on one
of our backbones.
We have a number of Linux hosts on this backbone with a primary address in
the network a.b.c.0/24 and a secondary address in the network d.e.f.0/24.
We also have some BSD/OS 4.1 machines in this
Date:Fri, 1 Sep 2000 19:01:18 +0100 (BST)
From: Alan Cox <[EMAIL PROTECTED]>
oAcenic 0.45 fixes (Chip Salzenberg)
This adds a huge comment claiming to fix some race condition,
but no actual code is changed. How can this be? :-)
Later,
David
On Fri, Sep 01, 2000 at 06:15:52PM -0700, Linus Torvalds wrote:
>
> if (!has_done_this_before) {
> pid_t tid;
> has_done_this_before = 1;
> tid = clone(CLONE_PID);
I'm not sure this will work very well
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Well, I would just swap it _before_ the clone() - basically in the
> original parent when you create the new stack, you call clone() with the
> new stack and with the old stack as the argument. No?
Yes. I have it basically working. You have of
On Sat, 2 Sep 2000, Andi Kleen wrote:
>
> But I guess you don't want the context switch to a thread manager just to
> generate a thread ? (and which is one of the main causes of the bad thread
> creation latency in Linux currently)
No, you don't need that. Here it is again:
int
On 1 Sep 2000, Ulrich Drepper wrote:
>
> I see no big problems with this either. The only tricky thing is to
> get the stack swapped after the first clone() but this is solvable.
Well, I would just swap it _before_ the clone() - basically in the
original parent when you create the new stack,
On Sat, 2 Sep 2000, Andi Kleen wrote:
>
> The first goal would be to get it out of the critical path of pthread_create.
It should already be out of there. See the proposal I had earlier in this
thread, about the _first_ time only, when you have pthread_create(), you
do two clone() calls - and
On Fri, Sep 01, 2000 at 06:11:05PM -0700, Ulrich Drepper wrote:
> "Andi Kleen" <[EMAIL PROTECTED]> writes:
>
> > Do you think the SA_NOCLDWAIT/queued exit signal approach makes sense ?
>
> I'm not sure whether it's worth the effort. But I'm saying this now
> looking at the code for another
"Andi Kleen" <[EMAIL PROTECTED]> writes:
> Do you think the SA_NOCLDWAIT/queued exit signal approach makes sense ?
I'm not sure whether it's worth the effort. But I'm saying this now
looking at the code for another implementation following the 1:1 model.
In a second stage where we have m
On Fri, Sep 01, 2000 at 06:00:58PM -0700, Linus Torvalds wrote:
>
>
> On 1 Sep 2000, Ulrich Drepper wrote:
>
> > "Andi Kleen" <[EMAIL PROTECTED]> writes:
> >
> > > I've been thinking about how to best get rid of the thread manager for
> > > thread creation in LinuxThreads. It is currently
Linus Torvalds <[EMAIL PROTECTED]> writes:
> But I'd much rather just have the "n+1" thing. The overhead is basically
> nonexistent, and it simplifies so many things.
I see no big problems with this either. The only tricky thing is to
get the stack swapped after the first clone() but this is
"Theodore Y. Ts'o" <[EMAIL PROTECTED]> writes:
> True, but this can be handled by having the master thread process catch
> SIGSEGV and redistributing the signal to all of its child-threads.
No, it cannot. We have to have a core dump with all threads.
> (The assumption I'm making here is that
On Fri, Sep 01, 2000 at 05:50:04PM -0700, Ulrich Drepper wrote:
> "Andi Kleen" <[EMAIL PROTECTED]> writes:
>
> > I've been thinking about how to best get rid of the thread manager for
> > thread creation in LinuxThreads. It is currently needed to do the wait.
>
> If you get rid of the manager
On 1 Sep 2000, Ulrich Drepper wrote:
> "Andi Kleen" <[EMAIL PROTECTED]> writes:
>
> > I've been thinking about how to best get rid of the thread manager for
> > thread creation in LinuxThreads. It is currently needed to do the wait.
>
> If you get rid of the manager thread (the +1 thread)
"Andi Kleen" <[EMAIL PROTECTED]> writes:
> I've been thinking about how to best get rid of the thread manager for
> thread creation in LinuxThreads. It is currently needed to do the wait.
If you get rid of the manager thread (the +1 thread) then you have
another problem: you cannot send a
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date:01 Sep 2000 14:52:28 -0700
1st Problem: One signal handler process process-wide
What is handled correctly now is sending signals to the group. Also
that every thread has its mask. But there must be exactly one signal
On Fri, Sep 01, 2000 at 03:06:52PM -0700, Linus Torvalds wrote:
>
> Good that _somebody_ actually looked at the code. I'll make some more
> modifications to handle blocked signals correctly (ie handling the case
> where the signal is blocked in all threads and then unblocked in one of
> them
According to Bill Rugolsky Jr.:
> On Fri, Sep 01, 2000 at 12:05:03PM +0100, Alan Cox wrote:
> > Right now Im not happy with the nfsv3 stuff I last looked at and
> > it seems to still contain things Linus rejected a while back.
>
> Alan, would you please describe in a few words what items are
>
According to Albert D. Cahalan:
> The last time this issue came up, it was discovered that Windows 9x
> does not use the same generation rules as Windows NT.
Well, making the rules the same as NT would be fine, I suspect.
Even better would be a mount option, I think, since there will
always be
On Fri, 1 Sep 2000, Linus Torvalds wrote:
> Oh, I basically agree, _except_ that Al Viro has these ideas pending for
> 2.5.x that basically create a "process capability cache" that is a cache
> of all the process ID's and capabilities (ie uid, gid, groups etc). Which
> would be this
Hrm. very weird. I guess it doesn't do it anymore (couldn't tell you if it
did it on test8-pre1 w/o vmpatch, i had it disabled) - only when you abort
it in the middle. In any case, here's what /proc/slabinfo says:
slabinfo - version: 1.1
kmem_cache59 78100221
> I am not a lawyer, marketing manager, marketer, salesperson, pre-sales
> person, or indeed even a "real" kernel hacker. I'm a bloody high school
> student. Hence the lack of the "journalistic touch". I'm just hacking
away,
> hoping someone will notice, tell me everything to fix, I fix it, and
Felix wrote:
> The last non-panic message on screen is:
> IPv6 v0.8 for NET4.0
> The panic reason is "attempting to kill init".
> Has anyone else had this problem?
> Felix
Sid Boyce writes:
I experienced the same problem when I compiled the kernel with IPV6
selected on one of my
> 3rd Problem: one uid/gid process-wide
>
> All the ID (uid/guid/euid/egid/...) must be process wide. The problem
> is similar to the signal handler. I think one should again keep the
> information exclusively in the master thread and have all others refer
> to this information.
Other
Alan Cox <[EMAIL PROTECTED]> writes:
> You dont want it in kernel space.
I don't see how you can do this. Also on user level you would have to
do this atomically since otherwise communication between the threads
isn't possible anymore. We have a PR in the glibc bug data base about
just that.
> >-> Multimedia
> > * Faster multimedia with specially designed video acceleration driver
s. In combination with the new release of the X Windows System, Linux includes
drivers to take full advantage of your accelerated video card (nVidia and 3Dfx
cards among those supported) to get
> Hi Daniel, anyone.
Hullo(tm).
> I am not a lawyer and I am not a marketing manager, but I think there
> are several things that need fixing. Most of these are differences that
> I think stand out when comparing your draft with the KDE press releases
> for their KDE2.0 betas (those being the
Linus Torvalds wrote:
>
>
> Yes. For 2.4.x, I'd love to fix anything that can be used to show real
> performance bugs. Something like "setuid() is slow when I run it threaded
> is not a real issue". Something like "pthreads is faster under NT than
> under Linux" _would_ be a real issue.
>
>
On Fri, Sep 01, 2000 at 02:00:25PM -0600, TimO wrote:
> Daniel Stone wrote:
> >-> Multimedia
> > * Faster multimedia with specially designed video acceleration drivers. In
>combination with the new release of the X Windows System, Linux includes drivers to
>take full advantage of your
On Fri, 1 Sep 2000, Linus Torvalds wrote:
> > 3rd Problem: one uid/gid process-wide
> >
> > All the ID (uid/guid/euid/egid/...) must be process wide. The problem
> > is similar to the signal handler. I think one should again keep the
> > information exclusively in the master thread and have
On Fri, 1 Sep 2000, Jim Garlick wrote:
> Can someone point me to MTBF data for Linux? I realize this is kind of
> vague. Ideally I would like MTBF for kernel 2.2.14 running on SMP Alpha,
> but any data is better than nothing. This is to help win an argument to
> put linux on a large cluster.
Hello
Patch vs pre1 but also applies vs pre2:
http://www.hojdpunkten.ac.se/054/samba/smbfs-2.2.18-pre1.patch.gz
Changes are mostly from 2.4.0-test7:
* proc.c: add back lanman2 support (OS/2 and others)
* proc.c: check length of paths to avoid buffer overflow
*
On Fri, 1 Sep 2000, Alan Cox wrote:
> >
> > No, it would be another "clone" option.
>
> You dont want it in kernel space.
Oh, I basically agree, _except_ that Al Viro has these ideas pending for
2.5.x that basically create a "process capability cache" that is a cache
of all the process ID's
> > Can someone point me to MTBF data for Linux? I realize this is kind of
> > vague. Ideally I would like MTBF for kernel 2.2.14 running on SMP Alpha,
> > but any data is better than nothing. This is to help win an argument to
> > put linux on a large cluster. Thanks in advance.
>
> The
> > 3rd Problem: one uid/gid process-wide
> >
> > All the ID (uid/guid/euid/egid/...) must be process wide. The problem
> > is similar to the signal handler. I think one should again keep the
> > information exclusively in the master thread and have all others refer
> > to this information.
>
> I'm sure there must be boxes with kernel 1.2.13 out there
> that have been running since 1.2.13 came out...
We ran 1.2.13lmp for about 1100 days before the box finally got turned off -
twice around the uptime clock and more
-
To unsubscribe from this list: send the line "unsubscribe
Good that _somebody_ actually looked at the code. I'll make some more
modifications to handle blocked signals correctly (ie handling the case
where the signal is blocked in all threads and then unblocked in one of
them _after_ it was delivered), but I've been disappointed by how much hot
air
It looks like 2.4.0-test7 won't boot on a Fujitsu Lifebook 765DX. The
kernel immediately hard reboots very early in the setup phase, before
it even displays the Uncompressing Linux message (or so it looks.)
The machine's relevant specs:
Fujitsu Lifebook 765DX
Pentium MMX 133 MHz
48 MB of RAM
I hoped somebody else would write something about Linus' test8-pre1
thread group changes but I haven't seen anything. Now you have to
bear with me even though I'm incompetent[1].
I took a look at the code and thought about the changes
necessary/possible in the thread library. Here's what I
On 1 Sep, Jim Garlick wrote:
> Can someone point me to MTBF data for Linux? I realize this is kind of
> vague. Ideally I would like MTBF for kernel 2.2.14 running on SMP Alpha,
> but any data is better than nothing. This is to help win an argument to
> put linux on a large cluster. Thanks
On Fri, 1 Sep 2000, Matthew Dharm wrote:
> Whoops! Think-o. I meant I'm running 2.2.5 for over 400 days.
I'm sure there must be boxes with kernel 1.2.13 out there
that have been running since 1.2.13 came out...
(however, that doesn't mean I would recommend that kernel
to anyone)
regards,
Whoops! Think-o. I meant I'm running 2.2.5 for over 400 days.
Matt
On Fri, Sep 01, 2000 at 01:45:25PM -0700, Matthew Dharm wrote:
> I agree that the MTBF can be very misleading...
>
> But put it this way: My server ran 2.2.14 for over 400 days before I
> rebooted it. It was down for about
On Fri, 1 Sep 2000, Ari Pollak wrote:
> Well, the vmpatch still didn't fix the problem I've been having
> for many moons (I believe since late 2.3.99) - When running
> updatedb from the slocate distribution, I lose at least 90 MB of
> memory by the time it's finished, and it takes about a day
Well, the vmpatch still didn't fix the problem I've been having for many
moons (I believe since late 2.3.99) - When running updatedb from the
slocate distribution, I lose at least 90 MB of memory by the time it's
finished, and it takes about a day for the memory to become usable again -
this is
Felix von Leitner <[EMAIL PROTECTED]> wrote:
> The last non-panic message on screen is:
>
> IPv6 v0.8 for NET4.0
>
> The panic reason is "attempting to kill init".
> Has anyone else had this problem?
I have the same problem if I have ipv6 compiled in. Sorry, I'll
post the oops messages
On Fri, 1 Sep 2000, Pavel Machek wrote:
> Hi!
>
> > > > On Thu, 31 Aug 2000, Petko Manolov wrote:
> > > >
> > > > [Snipped...]
> > > >
> > > > Good. You understand. Keep up the good work.
> > >
> > >
> > > I realy would like to see this code in use ;-)
> >
> > After you test it
> However, in 2.5.0 we should apply it, and force it on *all* cpus just
> to test it well. Then in 2.5.10 we should turn it off for
> pentium/MMX+.
Even original pentium has hardware optimised rep movs fast paths. Its just
a few cpus they disable it via undocumented magic (ditto it seems a
I agree that the MTBF can be very misleading...
But put it this way: My server ran 2.2.14 for over 400 days before I
rebooted it. It was down for about 5 minutes while rebooting (probably
less).
My NT Server gets a nightly reboot. I can't get it to run for more than a
week without it
Hi.
This is against 2.4.0-t8p1. The variable 'high' in do_anonymous_page seems
unused. The following patch removes it. Comments?
--- linux-240test8-pre1/mm/memory.c Thu Aug 10 16:29:54 2000
+++ linux/mm/memory.c Fri Sep 1 22:21:43 2000
@@ -1095,15 +1095,12 @@
*/
static int
Hi!
> > > On Thu, 31 Aug 2000, Petko Manolov wrote:
> > >
> > > [Snipped...]
> > >
> > > Good. You understand. Keep up the good work.
> >
> >
> > I realy would like to see this code in use ;-)
>
> After you test it **THOUROUGHLY**, send a patch to Linus. I
> recommend testing it in a
Hi!
> > /lib/modules//.config is a big step up from the current situation
> > and I'm grateful. But I do want /proc/config.gz in the kernel.
>
> So cat it with a magic lead in after the bzImage gzip block into the bzImage.
> If you dont even know what file you are running for kernel you have
Hi!
> > > I think I have found something. I've currently got 4 processes deadlocked
> > > on DAC960_WaitForCommand.
> > >
> > > This machine is a VA Linux VAR Server 3000.
> >
> > If they stay deadlocked there then let Leonard Zubkoff know. He's both the
> > DAC960 guru and happens to work
Hi!
> maintains all the useful information and will be less than 1/2kB.
> (things marked as not set or modular aren't relevant to the zImage)
Wrong. some modular options have efects on image (adding hooks, etc.)
Pavel
--
I'm
Hi.
(Thanks to Tigran Aivazian for catching me not being careful enough).
The following patch removes two, AFAICS, unneeded lines from mm/memory.c:
vmtruncate():
--- linux-240test8-pre1/mm/memory.c Thu Aug 10 16:29:54 2000
+++ linux/mm/memory.c Fri Sep 1 22:25:53 2000
@@ -985,8 +985,6
Hi!
With -test7, tcp connection to CE machine is _even slower_ than it
used to. CE are too slow to handle 115k200 serial, still they got at
least 2K/sec to linux-2.4.0-test6 (and previous).
tcpdump now looks like this:
22:03:42.200251 10.0.0.3.www > 192.168.55.100.1026: . 8761:10221(1460)
ack
Hi,
The drm code is added to 2.2.18pre, and this code uses the 2.4 __setup()
mechanism a lot. The patch at http://www.fenrus.demon.nl/setup.diff (16Kb
so not posted here) adds this to 2.2.18pre2. The biggest part of the patch
is the change from char.a to char.o; this is needed to prevent the
On Fri, 1 Sep 2000, Rasmus Andersen wrote:
> Good point. So what is the Right Thing? Moving inode->i_size = offset
> into truncate() and cleaning up vmtruncate()? Or just kill the comment
> along with the other line? :)
the right thing is to kill the comment and the code but it will only turn
Date:Fri, 01 Sep 2000 08:47:04 -0700
From: Stephen Satchell <[EMAIL PROTECTED]>
5) Even better would be to obtain the services of a PR firm used to
dealing with high-tech questions -- if you would like a list of potential
sponsors I can poll the IPG to see who might be
Can someone point me to MTBF data for Linux? I realize this is kind of
vague. Ideally I would like MTBF for kernel 2.2.14 running on SMP Alpha,
but any data is better than nothing. This is to help win an argument to
put linux on a large cluster. Thanks in advance.
Jim Garlick
-
To
On 0, Tigran Aivazian <[EMAIL PROTECTED]> wrote:
> On Fri, 1 Sep 2000, Rasmus Andersen wrote:
>
> > Hi.
> >
> > AFAICS, the line removed below is redundant. Comments?
> >
> > --- linux-240test8-pre1/mm/memory.c Thu Aug 10 16:29:54 2000
> > +++ linux/mm/memory.c Fri Sep 1 22:00:16 2000
On Fri, 1 Sep 2000, Rasmus Andersen wrote:
> Hi.
>
> AFAICS, the line removed below is redundant. Comments?
>
> --- linux-240test8-pre1/mm/memory.c Thu Aug 10 16:29:54 2000
> +++ linux/mm/memory.c Fri Sep 1 22:00:16 2000
> @@ -986,7 +986,6 @@
> out_unlock:
>
Theodore Ts'o writes:
> Dr. Michael Weller writes:
> > Sorry, I've no idea about the ext2 and fs implementation.
> > However did you read the comment below and convince yourself that 'err' is
> > always set correctly?
>
> I looked at it and was convinced.
Ted and I submitted patches to this
On Fri, 1 Sep 2000, Chris Evans wrote:
> On Fri, 1 Sep 2000, Rik van Riel wrote:
> > On Fri, 1 Sep 2000, Tigran Aivazian wrote:
> >
> > > Any of you tried copying a 2G file in the same (ext2)
> > > filesystem? It starts swapping like mad and generally behaves
> > > indecently, despite the huge
Hi.
AFAICS, the line removed below is redundant. Comments?
--- linux-240test8-pre1/mm/memory.c Thu Aug 10 16:29:54 2000
+++ linux/mm/memory.c Fri Sep 1 22:00:16 2000
@@ -986,7 +986,6 @@
out_unlock:
spin_unlock(>i_shared_lock);
/* this should go into ->truncate */
-
On Fri, 1 Sep 2000, Rik van Riel wrote:
> On Fri, 1 Sep 2000, Tigran Aivazian wrote:
>
> > Any of you tried copying a 2G file in the same (ext2)
> > filesystem? It starts swapping like mad and generally behaves
> > indecently, despite the huge 1024M of RAM it has.
>
>
From: Daniel Phillips <[EMAIL PROTECTED]>
Date:Fri, 01 Sep 2000 20:49:14 +0200
Curiously, this field is measured in 512 byte units, giving a 2TB Ext2
filesize limit. That's starting to look uncomfortably small - I can
easily imagine a single database file wanting to be
Daniel Stone wrote:
>
> Gidday!
{SNIP}
>-> Multimedia
> * Faster multimedia with specially designed video acceleration drivers. In
>combination with the new release of the X Windows System, Linux includes drivers to
>take full advantage of your accelerated video card (nVidia and 3Dfx
> > Any of you tried copying a 2G file in the same (ext2)
> > filesystem? It starts swapping like mad and generally behaves
> > indecently, despite the huge 1024M of RAM it has.
>
> http://www.surriel.com/patches/2.4.0-t8p1-vmpatch2
this patch works very nicely. it's still a little timid at
I'm looking for anyone that has merged the international crypto patches
with Red Hat kernel rpm's.
I've basically gotten the patch to apply cleanly, but then the build
completely fails during module building. I don't have the know how to fix
things.
Thanks for any information.
I'm
On Fri, Sep 01, 2000 at 11:40:31AM +0200, Trond Myklebust wrote:
[...]
> > nlm_release_file() *does* grab the semaphore. That's the
> > problem.
>
> Which is why I'm proposing a solution: to split it into 2 functions.
>1st function does the semaphore manipulations and calls
>
> >
> > Tsk. Showing my age and ignorance, I guess. I was using the gcc -v trick back
> > at Auspex in '93. ...Guess the compiler driver has gotten smarter since.
> > You know how it goes- you do a trick once- you don't change it for years...
>
> According to the ChangeLog of the 2.7.2.3
On Fri, Sep 01, 2000 at 12:01:39PM -0700, Matthew Jacob wrote:
> >
> > Or use --print-libgcc-file-name:
> >
> > `gcc --print-libgcc-file-name`
> >
> > where are the options normally used to compile code (ie, for example
> > on machines that optionally do not have a floating point use,
>
> Or use --print-libgcc-file-name:
>
> `gcc --print-libgcc-file-name`
>
> where are the options normally used to compile code (ie, for example
> on machines that optionally do not have a floating point use, adding
> -msoft-float would select the libgcc.a that was compiled with
Alan Cox writes:
> o Make vfat use the same generation rules as (H. Kawaguchi,
> in windows 9xChip Salzenberg)
I doubt this is obviously correct. The last time this issue
came up, it was discovered that Windows 9x does not use the
same
On Fri, Sep 01, 2000 at 10:34:19AM -0700, Matthew Jacob wrote:
> > On Fri, Sep 01, 2000 at 03:15:27PM +0200, Andi Kleen wrote:
> > > So what do you propose to use when a long long division is needed (after
> > > much thought and considering all alternatives etc.etc.) ?
> >
> > Link against
On Fri, 1 Sep 2000, Tigran Aivazian wrote:
> Any of you tried copying a 2G file in the same (ext2)
> filesystem? It starts swapping like mad and generally behaves
> indecently, despite the huge 1024M of RAM it has.
http://www.surriel.com/patches/2.4.0-t8p1-vmpatch2
I'm working on these issues
> address 68736170
> address 33312051
> address 3331203d
The kernel is using ASCII text as pointers. Convert the above:
"pash"
"Q 13"
"= 13"
Try different kernels and different compilers.
The hardware is probably OK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
1 - 100 of 285 matches
Mail list logo
