Hi,
Up to the latests kernels (-> 2.4.2) channel bonding crashes the kernel
(aille...) when turning it off (e.g. at reboot).
Here is a way to avoid this, which might help gourous to track the bug.
Suppose ifconfig says:
bond0 Link encap:Ethernet HWaddr 00:40:05:A1:C4:13
Earlier today I swapped an Athlon (tbird) 850 and an Epox 8KTA3 in for the
dual Celeron I had, moving all the cards into the new system. One of these
was a Promise PDC20267 with 4 40gb disks attached. The machine would not
boot; I assumed it was the i686-smp kernel and installed a Redhat
On Thu, 22 Mar 2001, Alan Cox wrote:
> 2.4.2-ac21
> o atyfb mode updates for powermac (Olaf Hering)
60 Hz modes should be marked 60 Hz.
Add separator comment.
--- linux-2.4.2-ac21/drivers/video/macmodes.c.orig Fri Mar 23 08:17:54 2001
+++
On 22 Mar 2001, Kevin Buhr wrote:
> Mike Galbraith <[EMAIL PROTECTED]> writes:
> >
> > 2.4.2.ac20.virgin 2.4.3-pre6
> > real11m0.708s 11m58.617s
> > user15m8.720s 7m29.970s
> > sys 1m31.410s 0m41.590s
> >
> > It looks like ac20 is doing some double accounting.
[snip]
>
On 22 Mar 2001, Michael Peddemors wrote:
> Here, Here.. killing qmail on a server who's sole task is running mail
> doesn't seem to make much sense either..
I won't defend the current OOM killing code.
Instead, I'm asking everybody who's unhappy with the
current code to come up with something
Oh Great Gurus:
I have an agp video card that seems quite picky about interrupts, and a
bios that is insisting on sharing the video card's interrupt with whatever
is in the first pci slot. So my question is, is there any way for the
kernel to more or less say ``screw you'' to the bios and pick
Hi,
Also as a note, what we are doing is keeping our rootfs on flash as a tar.gz and
reading it and mounting it on a ramfs in the /linuxrc before doing a pivot_root.
To summarize, pivot_root has been a life saver as the earlier real_root_dev
might not have been useful in this case.
Not using
Hi,
Thanks for the response. PSB,
Werner Almesberger wrote:
> Amit D Chaudhary wrote:
>
> No, you would continue using the file descriptors which are already
> open, i.e. on /dev/console on the old root.
So, makes sense. And the child process that follow will use now the new fd's.
>> Also,
On Thu, 22 Mar 2001, Alan Cox wrote:
> This is commonly done using the speedstep feature on intel cpus. Speedstep
> can generate events so the OS knows about it but Intel are not telling
> people about how this works.
<...snip...>
> We certainly could recalibrate the clock if we could get events
Paul Mackerras <[EMAIL PROTECTED]> writes:
>
> I didn't realize you were talking about linux 2.4.0 and pppd 2.3.11.
That was my stupid oversight. I carefully tested and retested the
patch under 2.4.0-test5, then ported it to 2.4.2 and sent it off with
only a cursory check using the new pppd
Hi,
I have a initrd working, a /linuxrc on it that runs and executes. My question
for the commands after pivot_root which works like a charm, thanks to initrd.txt,
what does redirecting stdin\stdout\stderr to dev/console achieve? I thought
since the root is now the "new" root, dev/console
Al Viro writes:
> On Fri, 23 Mar 2001, Stephen C. Tweedie wrote:
> > On Wed, Mar 07, 2001 at 01:35:05PM -0700, Andreas Dilger wrote:
> > > The only remote possibility is in ext2_free_blocks() if block+count
> > > overflows a 32-bit unsigned value. Only 2 places call ext2_free_blocks()
> > > with
Hi all,
I saw a discussion on this list about this problem earlier, but could not
find that it had actually been resolved.
With the removal of serial_cb from the 2.4.3pre kernels I can no longer use
the modem of my Xircom adapter. According to the posts in the other thread
serial.c should now
Kevin Buhr writes:
> I didn't realize my specific hang was a peculiarity of the older
> attachment style. The channel created by pushing the PPP line
I didn't realize you were talking about linux 2.4.0 and pppd 2.3.11.
> discipline onto a TTY was connected to a unit with a PPPIOCATTACH
>
Here is the deal:
we have a guy here with a webcam and the following scenario:
1. ov511 disconnects, everything dies/releases/closes fine,
2. webcam soft starts polling open/sleep/open/sleep/...
3. ov511_probe works and reaches ov511_configure,
calls video_register_device().
4. Webcam
I also had my 3c905 behave this way with ac21. ac20 is ok. System uses an ABit kt7a
board.
Andrew Morton wrote:
> Lawrence Walton wrote:
> >
> > Hello all
> > 2.4.2-ac21 seems to have a couple problems.
> > ...
> >
> > Mar 22 15:15:55 the-penguin kernel: NETDEV WATCHDOG: eth0: transmit timed
> Boot with the 'notsc' option is one approach. We certainly could recalibrate
> the clock if we could get events out of ACPI, APM or some other source. Maybe
> someone at IBM knows something on the thinkpad front here. If there is for
> example an additional apm event or irq we can enable for
All,
Firstly, my relevant system stats:
kernel linux 2.4.3-pre6
hda IDE Drive
hdb CD drive
hdc IDE Drive
hdd IDE Drive
sda SCSI Drive
The problem I'm seeing is that IO stats (disk_io) aren't being shown in
/proc/stats for the
Dave, Zach,
thanks for your help, I've implemented a file descriptor passing mechanism
very similar to that of Zach's and it worked.
The problem now is performance, fd passing is utterly slow!
On my system (a 1GHz Pentium III + 2G RAM) I can do 1300 SpecWeb99 with a
khttp-like socket passing
Hi all,
Iam using SiS900 chipset .It contains sis900 Fast ethernetcard . I installed
RedHat Linux 6.2 .But I could not configure net card.
I want to know Does kernel 2.2.15 supports sis900 net card or not. ?.
Iam trying to insert sis900 as module .But Iam getting message as "
"Device or
Further note - kernels built with K6-2 support seem to be just fine. But
all athlon/K7 kernels die horribly, with greatly varying death messages.
Most commonly I get bogus pointer/dereference errors and eventually init
gets killed, other times it just locks up, sometimes I get things like
Long and short is I have a new mobo/cpu/ram (see below) that runs great
under Win98 and passes memtest86 (3 extended runs as pc133/cas2, 3
standard runs as pc100/cas3) but oops's almost immediately under Linux
2.4.x (2.4.2 and 2.4.1 at the least.)
With a few rare exceptions (usually kupdated)
> o Fix ppp memory corruption (Kevin Buhr)
> | Bizzarely enough a direct re-invention of a 1.2 ppp bug
Could this explain my MPPP skb corruption I've reported since 2.3.x?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Regarding the overclocking of the PCI bus, I was not aware of this. The
documentation led me to believe the pci clock was fixed, however further
experimentation indicates that's clearly not the case. Thanks.
Regarding the fix: I installed an Ensonique AudioPci sound card, and
experienced
Some guy sent me the attached patch. He says it allows
him to use 2 additional keys on the 106 key USB keyboard.
I never saw a 106 key keyboard before, USB or not.
Does anyone understand what is going on? Vojtech?
-- Pete
--- drivers/input/keybdev.c.orig Sat Sep 2 19:01:55 2000
+++
Martin Frey wrote:
>
> >> - When started during boot (low PID (9)) It becomes a zombie
> >> - When started from a process that quits after sending the ioctl,
> >>it is correctly "garbage collected".
> >> - When started from a process that stays around, it becomes
> >>a zombie too
>
>
On Fri, 23 Mar 2001 01:50:49 +,
"Andrew Morton" <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote:
>>
>> Am I the only person who is annoyed that nmi watchdog is now off by
>> default and the only way to activate it is by a boot parameter? You
>> cannot even patch the kernel to build a version
On Fri, 23 Mar 2001, Stephen C. Tweedie wrote:
> Hi,
>
> On Wed, Mar 07, 2001 at 01:35:05PM -0700, Andreas Dilger wrote:
>
> > The only remote possibility is in ext2_free_blocks() if block+count
> > overflows a 32-bit unsigned value. Only 2 places call ext2_free_blocks()
> > with a count != 1,
Keith Owens wrote:
>
> Am I the only person who is annoyed that nmi watchdog is now off by
> default and the only way to activate it is by a boot parameter? You
> cannot even patch the kernel to build a version that has nmi watchdog
> on because the startup code runs out of the __setup routine,
>> - When started during boot (low PID (9)) It becomes a zombie
>> - When started from a process that quits after sending the ioctl,
>>it is correctly "garbage collected".
>> - When started from a process that stays around, it becomes
>>a zombie too
>Take a look at
Here, Here.. killing qmail on a server who's sole task is running mail doesn't seem to
make much sense either..
> > Clearly, Linux cannot be reliable if any process can be killed
> > at any moment. I am not happy at all with my recent experiences.
>
> Really the whole oom_kill process seems
On Sat, 23 Mar 2002, Martin Dalecki wrote:
> This is due to the broken calculation formula in oom_kill().
Feel free to write better-working code.
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
Greetings! Here are the contiguous lines from kern.log:
Mar 21 01:14:47 intech9 kernel: eth0: bogus packet: status=0x80 nxpg=0x57 size=1270
Mar 21 01:14:49 intech9 kernel: Unable to handle kernel NULL pointer dereference at
virtual address
Mar 21 01:14:49 intech9 kernel:
If it's a 500MHz Thinkpad, then I'm guessing it's something like a 600X.
That doesn't have Speedstep. The speed changes are done by some circuitry
in the laptop. I can try to find out more if this would help.
The newer machines are using Speedstep.
Tim
On Thu, Mar 22, 2001 at 11:37:43PM +,
Hi,
On Wed, Mar 07, 2001 at 01:35:05PM -0700, Andreas Dilger wrote:
> The only remote possibility is in ext2_free_blocks() if block+count
> overflows a 32-bit unsigned value. Only 2 places call ext2_free_blocks()
> with a count != 1, and ext2_free_data() looks to be OK. The other
>
As always, the latest version of this driver is availalbe here:
http://people.FreeBSD.org/~gibbs/linux/
Complete CHANGELOG is now available at the above URL.
I try to filter though LK as often as I can, but for
best response, please email issues regarding this driver to
me directly.
Changes
On Fri, 23 Mar 2001 00:02:54 +0100,
Frank de Lange <[EMAIL PROTECTED]> wrote:
>Linux 2.4.2-ac21 does not like my box, or the other way around:
>
>loading the agpgart module (MGA G400 AGP) -> system hangs
>loading the SCSI module (53c875) -> system hangs
>
>In both cases, the magic SysRq sequence
> It might be interesting to strace the realserver startup
> both under 2.2 and 2.4 -
Here you go. Also sorry Alan for such a goofy email earlier. Does anyone
have any ideas on the sound driver issue?
Brent Norris
execve("Bin/rmserver", ["Bin/rmserver", "rmserver.cfg"], [/* 23 vars */]) =
Hi,
The patch below is for two races in sysV shared memory.
The first (minor) one is in shmem_free_swp:
swap_free (entry);
*ptr = (swp_entry_t){0};
freed++;
if (!(page = lookup_swap_cache(entry)))
continue;
Lawrence Walton wrote:
>
> Hello all
> 2.4.2-ac21 seems to have a couple problems.
> ...
>
> Mar 22 15:15:55 the-penguin kernel: NETDEV WATCHDOG: eth0: transmit timed out
> ...
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00
>[Normal decode])
People have
> Hello all
> 2.4.2-ac21 seems to have a couple problems. First the fs was acting very
> strangely, while compiling; the compiler complained about being unable
> to find files and directory's that existed. I was able to cd to those
> directory's and see the files with ls, (I was recompiling ac20
In article <[EMAIL PROTECTED]>,
Jean Tourrilhes <[EMAIL PROTECTED]> wrote:
>
> I agree that the IrDA stack is full of irq/locking bugs (there
>is a patch of mine waiting in Dag's mailbox), but this one is not a
>bug, it's a false positive.
> The restore_flags(flags); will restore the
On 03.23 Alan Cox wrote:
> > page_cache_release(page);
> > -out:
>
> out:;
>
Yes, a null sentence can shut up the compiler. But what is the purpose of
a jump to the end instead of a return ? Some optimization ?
> does that trick
>
> > - default:
> > + default:;
>
Same, I have not
Rik van Riel wrote:
>
> On Sat, 23 Mar 2002, Martin Dalecki wrote:
>
> > Uptime of a process is a much better mesaure for a killing
> > candidate then it's size.
>
> You'll have fun with your root shell, then ;)
You mean the remote one?
> The current OOM code takes things like uptime, used
Stephen Clouse wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sat, Mar 23, 2002 at 01:33:50AM +0100, Martin Dalecki wrote:
> > AMEN! TO THIS!
> > Uptime of a process is a much better mesaure for a killing candidate
> > then it's size.
>
> Thing is, if you take a good study
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Mar 23, 2002 at 01:33:50AM +0100, Martin Dalecki wrote:
> AMEN! TO THIS!
> Uptime of a process is a much better mesaure for a killing candidate
> then it's size.
Thing is, if you take a good study of mm/oom_kill.c, it *does* take start time
On Thu, 22 Mar 2001 23:43:57 + (GMT), Alan Cox wrote:
> > >How do you return an out of memory error to a C program that is out of memory
> > >due to a stack growth fault. There is actually not a language construct for it
> > SIGSEGV.
> > Stack overflow for a language like C using standard
Mikael Pettersson wrote:
>
> [+] Speaking as a hacker on a runtime system for a concurrent
> programming language (Erlang), I consider the current Unix/POSIX/Linux
> default of having the kernel throw up[*] at the user's current stack
> pointer to be unbelievably broken. sigaltstack() and
On Thu, 22 Mar 2001, Alan Cox wrote:
OK.
> > On Thu, 22 Mar 2001, Alan Cox wrote:
> >
> > Does not build for PPro/P-II. i586 is OK.
>
> You need to avoid enabling 64G support. The PAE stuff (as Linus said
> with
> 2.4.3pre6) is currently broken. Once Linus and co fix it I'll merge the
> fixed
>
Alan Cox wrote:
> o Next incarnation of the i810 audio driver (Doug Ledford)
Is this the i810 that's in Red Hat's CVS or the last copy of the big file that
I sent you? If it's the last copy of the big file I sent you, then it has a
memory leak that needs fixed. I committed the fix
Hello all
2.4.2-ac21 seems to have a couple problems. First the fs was acting very
strangely, while compiling; the compiler complained about being unable
to find files and directory's that existed. I was able to cd to those
directory's and see the files with ls, (I was recompiling ac20 at the
> page_cache_release(page);
> -out:
out:;
does that trick
> - default:
> + default:;
Agree - done
> --- linux-2.4.2-ac21/net/ipv4/icmp.c.orig Thu Mar 22 23:39:22 2001
> +++ linux-2.4.2-ac21/net/ipv4/icmp.c Thu Mar 22 23:42:23 2001
Again out:;
> goto
Hi, kernel list readers.
I have been building (and hopefully booting) ac-21 with gcc-3.0 snapshot
dated 20010312. I have cleared the 99% of the warnings that 3.0 issues
when building the kernel. Obviuosly, only in the main kernel part for
i386 and the drivers I use. I suppose other arch will
The latest version is always available at http://www.tuxedo.org/~esr/cml2/
Release 0.9.5: Thu Mar 22 18:21:12 EST 2001
* Put Python version guard up front so user won't see a stack
trace from bad imports.
* Follow through on representing numbers as numbers internally.
Benjamin Herrenschmidt wrote:
>
> >daemonize() makes calls that are all protected with the
> >big kernel lock in do_exit(). All usages of daemonize have
> >the big kernel lock held. So I guess it just needs it.
> >
> >Please let me know whether you have success if it makes
> >a difference with
On Thu, Mar 22, 2001 at 06:07:52PM -0500, John Covici wrote:
> I have been wondering about the serial drivers shared irq
> configuration parameter. Will it allow two dumb serial ports which
> know nothing about sharing irq's to actually share the same irq, or
no.
> does the actual hardware
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
(Note that the cmsfs port to 2.4 is a work in progress)
2.4.2-ac22
o Fix dereference after free in megaraid driver (me)
On Thu, Mar 22, 2001 at 03:49:31PM -0800, Junfeng Yang wrote:
>
> Sometimes the line number reported by the checker is not correct.
> But if you go into the function, you can find the bug.
Gotcha. It in fact indicate the error at the end of the
function instead of the place where the
> I found the problem.
> CONFIG_DEBUG_SLAB "Debug memory allocation"
> in the 2.4.2-ac series doesn't work with USB.
>
> 2.4.2-ac5 just booted and found the mouse correctly.
> On to ac-21 now...
I just glanced at Alan's change list, it didn't have patches
that seemed to cover that (vs ac20).
Junfeng Yang wrote :
> Hi,
>
> Here are yet more results from the MC project. This checker looks for
> inconsistent usage of interrupt functions.
[...]
> -
> [BUG] error path
>
>
On Thu, 22 Mar 2001 21:23:54 + (GMT), Alan Cox wrote:
>> Really the whole oom_kill process seems bass-ackwards to me. I can't in my mind
>> logically justify annihilating large-VM processes that have been running for
>> days or weeks instead of just returning ENOMEM to a process that just
On Fri, 23 Mar 2001, Guest section DW wrote:
> On Thu, Mar 22, 2001 at 10:52:09PM +, Alan Cox wrote:
>
> > You can do overcommit avoidance in Linux if you are bored enough to try it.
>
> Would you accept it as the default? Would Linus?
It wouldn't help. Suppose you run without overcommit
>daemonize() makes calls that are all protected with the
>big kernel lock in do_exit(). All usages of daemonize have
>the big kernel lock held. So I guess it just needs it.
>
>Please let me know whether you have success if it makes
>a difference with having it held.
With a bit more experiments,
> thanks, i just tested the "notsc" option (.config has CONFIG_X86_TSC
> enabled=y, but CONFIG_M586TSC is not enabled.. if that's ok), but this time
...
> boot and stay on battery power exclusively. did anyone else expect this
> behaviour?
Errmm no..
-
To unsubscribe from this list:
> > Even if malloc fails the situation is no different.
> Why do you say so?
Because you will fail on other things - stack overflow, signal delivery,
eventually it will get you. You just cut the odds down.
> > You can do overcommit avoidance in Linux if you are bored enough to try it.
>
>
On Thu, Mar 22, 2001 at 10:52:09PM +, Alan Cox wrote:
> > You see, the bug is that malloc does not fail. This means that the
> > decisions about what to do are not taken by the program that knows
> > what it is doing, but by the kernel.
> Even if malloc fails the situation is no different.
On Thu, 22 Mar 2001, Alan Cox wrote:
Does not build for PPro/P-II. i586 is OK.
=== Cut ===
ld -m elf_i386 -T /tmp/build-kernel/usr/src/linux-2.4.2ac21/arch/i386/vmlinux.lds -e
stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \
--start-group \
Andy Chou :
> Here are some more results from the MC project. These are 16 errors found
> in 2.4.1 related to inconsistent use of locks. As usual, if you can
> verify any of these or show that they are false positives, please let us
> know by CC'ing [EMAIL PROTECTED]
>
> -Andy Chou
>
>
> > I wonder if there is a way to modify mdelay to use a kernel timer if
> > interval > 10msec? I am not familiar with this section of the kernel,
> but I
> > do know that Microsoft's similar function KeStallExecutionProcessor is
> not
> > recommended for more than 50 *micro*seconds.
>
Alan Cox wrote:
>
> > > How do you return an out of memory error to a C program that is out of memory
> > > due to a stack growth fault. There is actually not a language construct for it
> >
> > Simple, you reclaim a few of those uptodate buffers. My testing here has
>
> If you have
> On Thu, 22 Mar 2001, Alan Cox wrote:
>
> Does not build for PPro/P-II. i586 is OK.
You need to avoid enabling 64G support. The PAE stuff (as Linus said with
2.4.3pre6) is currently broken. Once Linus and co fix it I'll merge the fixed
one
Alan
-
To unsubscribe from this list: send the line
I have been wondering about the serial drivers shared irq
configuration parameter. Will it allow two dumb serial ports which
know nothing about sharing irq's to actually share the same irq, or
does the actual hardware have to support some kind of irq sharing for
this to work?
I did try two
Peter Zaitcev wrote:
>
> > > 2.4.2-ac6
> > > o USB hub kmalloc wrong size corruption fix (Peter Zaitcev)
>
> > The first line of the oops is
> >
> >
> > kernel BUG at slab.c:1398!
> >
> > Any other ideas to try?
> > -Thomas
>
> I did not break it, honest! I will be looking in
On Thu, 22 Mar 2001, Richard Jerrell wrote:
> 2.4.1 has a memory leak (temporary) where anonymous memory pages
> that have been moved into the swap cache will stick around after
> their vma has been unmapped by the owning process.
> free_pte in mm/memory.c has been modified to check to see if
> > How do you return an out of memory error to a C program that is out of memory
> > due to a stack growth fault. There is actually not a language construct for it
>
> Simple, you reclaim a few of those uptodate buffers. My testing here has
If you have reclaimable buffers you are not out of
> Supermount sounds to me like a very important part of linux, at least for us
> who like our cds/dvds/etc. to work as easily as in fx. windows. For linux to
> be popular among "normal" users, it should be present at every system with
> local removable drives. So, my question is; why isn't
> I wonder if there is a way to modify mdelay to use a kernel timer if
> interval > 10msec? I am not familiar with this section of the kernel, but I
> do know that Microsoft's similar function KeStallExecutionProcessor is not
> recommended for more than 50 *micro*seconds.
Basically the same kind
> We modified our compiler extension for checking lock consistency and
> found 8 more potential errors.
All 8 are real, all 8 fixed in my tree.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Oops...
Linux 2.4.2-ac21 does not like my box, or the other way around:
loading the agpgart module (MGA G400 AGP) -> system hangs
loading the SCSI module (53c875) -> system hangs
In both cases, the magic SysRq sequence does not work, but it is still possible
to ping the box from the outside.
> During resume the IBM thinkpad with the cs46xx driver needs
> to delay 700
> milleseconds, so if the machine is booted up on battery power, then to
> ensure that the delay is long enough, then a value of 3000
> milleseconds is
> must be programmed into the driver (3 seconds!). all the
>
> > Eventually you have to kill something or the machine deadlocks.
>
> Alan, this is a fake argument.
No it is not.
> You see, the bug is that malloc does not fail. This means that the
> decisions about what to do are not taken by the program that knows
> what it is doing, but by the kernel.
> I compiled 2.4.3-pre6 and 2.4.2-ac21 and noticed, that aviplay works
> much worse than before. Avifile benchmark told me:
>
> Average video output speed: 20.566223 Mb/s
>
> On 2.2.18 and earlier 2.4.2-ac* it gives 50-55Mb/s.
>
> mtrr is enabled:
>
> [jp@darkwood jp]$ cat /proc/mtrr
> reg00:
I don't know if this applies to 2.4.2, but there is a patch for 2.4.0:
http://www.geocities.com/SiliconValley/Lab/8144/supermount.html
/cyr
---
Lister: Shouldn't this plug in to something?
Holly: Yes, that joins up with the
On Thu, Mar 22, 2001 at 09:32:39PM +0100, Geir Thomassen wrote:
>
> The serial port chip is 16550A, which has a built in fifo. Can this be
> the source of my problems ?
Well, if you set the uart to be 16450 using setserial, this will cause
Linux to avoid enabling the FIFO. That will cause the
Hi!
I'm having some problems with ip-connection tracking and multicast packets:
the conntrack stuff doesn't seem to be able to handle multicast packets,
flooding my logs with messages like these:
Feb 28 15:53:00 procyon kernel: NAT: 0 dropping untracked packet c7105b00 1
195.38.203.147 ->
I recently upgraded my kernel to version 2.4.2, with no problems at all,
except one: supermount. I guess you already know that supermount haven't been
upgraded to support 2.4.2 or even 2.4 yet, and i guess there's nothing to do
about that but wait. But that's not why i'm writing this.
Mike Galbraith <[EMAIL PROTECTED]> writes:
>
> 2.4.2.ac20.virgin 2.4.3-pre6
> real11m0.708s 11m58.617s
> user15m8.720s 7m29.970s
> sys 1m31.410s 0m41.590s
>
> It looks like ac20 is doing some double accounting.
Alan:
In "2.4.2-ac20", the check in "apic.c" in the
On Wed, 21 Mar 2001, Rik van Riel wrote:
> On Wed, 21 Mar 2001, Patrick O'Rourke wrote:
>
> > Since the system will panic if the init process is chosen by
> > the OOM killer, the following patch prevents select_bad_process()
> > from picking init.
>
> One question ... has the OOM killer ever
> " " == Camm Maguire <[EMAIL PROTECTED]> writes:
> I'd be happy to generate one if I could. I've got the system
> map. The defaults reported by ksymoops are all correct. Don't
> know why it didn't give me more info. Normally, the info is
> reported by klogd anyway,
On Thursday 22 March 2001 17:00, Guest section DW wrote:
> On Thu, Mar 22, 2001 at 09:23:54PM +, Alan Cox wrote:
> > > Really the whole oom_kill process seems bass-ackwards to me. I can't
> > > in my mind logically justify annihilating large-VM processes that have
> > > been running for days
We modified our compiler extension for checking lock consistency and
found 8 more potential errors.
-Andy Chou
Index:
drivers/char/pcwd.c:468:pcwd_close
drivers/sound/es1370.c:1775:es1370_release
drivers/sound/es1370.c:2442:es1370_midi_release
drivers/sound/es1371.c:2611:es1371_midi_release
2.4.1 has a memory leak (temporary) where anonymous memory pages that have
been moved into the swap cache will stick around after their vma has been
unmapped by the owning process. These pages are not free'd in free_pte()
because they are still referenced by the page cache. In addition, if the
Alan Cox wrote:
>
> > Really the whole oom_kill process seems bass-ackwards to me. I can't in my mind
> > logically justify annihilating large-VM processes that have been running for
> > days or weeks instead of just returning ENOMEM to a process that just started
> > up.
>
> How do you return
On Thu, Mar 22, 2001 at 09:23:54PM +, Alan Cox wrote:
> > Really the whole oom_kill process seems bass-ackwards to me. I can't in my mind
> > logically justify annihilating large-VM processes that have been running for
> > days or weeks instead of just returning ENOMEM to a process that
Alexander Viro wrote:
>
> On Thu, 22 Mar 2001, Dave Kleikamp wrote:
>
> > Linus,
> > I would like to reserve a block of 32 ioctl's for the JFS filesystem.
>
> Details, please? More specifically, what kind of objects are these ioctls
> applied to?
I don't have all the details worked out yet,
>This is what the program does:
>
> fd=open("/dev/ttyS0",O_NOCTTY | O_RDWR);
>
> tcsetattr(fd,TCSANOW, ); /* setting baud, parity, raw mode, etc */
>
> while() {
> write( 6 bytes); /* send command */
> read( 2 bytes);/* wait for reply */
> }
What are
On Thu, 22 Mar 2001, Dave Kleikamp wrote:
> Linus,
> I would like to reserve a block of 32 ioctl's for the JFS filesystem.
Details, please? More specifically, what kind of objects are these ioctls
applied to?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
"User does not understand how *NIX systems utilize memory" is
not the same thing as "bug". What you are seeing is the kernel
using memory for file system cache.
On 03/22/2001 12:58 -0800, Craig Cummings wrote:
>> Hi there,
>>
>> I think this qualifies as a bug but let me know if
Is the computer otherwise idle?
I've seen one unexplainable report with atm problems that disappeared
(!) if a kernel compile was running.
Could you try to run a simple cpu hog (with nice 20)?
<<
main()
{
for(;;) getpid();
}
<<
I'm aware of one bug that could cause a delay of up to 20 ms
"David S. Miller" <[EMAIL PROTECTED]> said:
> alterity <[EMAIL PROTECTED]> wrote:
> >Haven't seen a post for sometime from the usually prolific Mr Cox.
> >What's the gossip?
> They needed some help from him to position Mir for it's
> final descent.
Just hope he gets out before the burnup...
--
1 - 100 of 457 matches
Mail list logo
