Hello,
I receive the following error with make zImage:
es1370.c: In function `es1370_probe':
es1370.c:2667: structure has no member named `trigger'
es1370.c:2667: structure has no member named `read'
make[3]: *** [es1370.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.2/drivers/sound'
LA Walsh <[EMAIL PROTECTED]> écrit :
> Here is the 'alternate' output when the ncr53c8xx driver is
> compiled in:
>
> SCSI subsystem driver Revision: 1.00
> scsi-ncr53c7,8xx : at PCI bus 0, device 8, function 0
> scsi-ncr53c7,8xx : warning : revision of 35 is greater than 2.
> scsi-ncr53c7,8xx :
Jeff Garzik <[EMAIL PROTECTED]>:
> There is no good reason to restrict the CML2 identifier namespace.
I've already listed a couple of good reasons. As Peter said, maintanicus
selector est.
--
http://www.tuxedo.org/~esr/">Eric S. Raymond
No one who's seen it in action can say
Keith Owens wrote:
> That just leaves the 17 names of the form CONFIG_[0-9]*. Only the 8139
> is likely to affect outside the kernel and the argument that renaming
> config options might affect external packages does not hold. The
> recent aic7xxx change broke pcmcia on 2.2 kernels but we can
On Mon, 26 Mar 2001 02:09:02 -0500,
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
>Jeff Garzik <[EMAIL PROTECTED]>:
>> If we are moving to CML2 in 2.5, I see no point in big CML1 cleanups.
>
>Yes, I know, that's what I said about Peter's DERIVED patch a week ago.
Hey, that was my DERIVED patch,
Jeff Garzik <[EMAIL PROTECTED]>:
> You updated Linux-Mandrake's kernel RPM and Linux-Mandrake's installer?
> Cool!
No, I didn't. But I can't even imagine how these changes could break those.
> Please post a patch with only these 19 changes, and make sure to CC it
> to linux-kernel.
I don't
Peter Samuelson <[EMAIL PROTECTED]>:
>
> [Jeff Garzik]
> > > It stays "8139too". Donald Becker's rtl8139.c continues to exist
> > > outside the kernel.
>
> Honestly, Jeff, I don't see how it matters -- because if you are
> downloading an external driver, you are not going through the config
Eric Raymond writes:
> (1) 19 of the 39 changes fix things that are outright bugs even in CML1.
> These should not be allowed to persist in the stable branch.
I think that things that are bugs in CML1, on its own terms, are
worth fixing in 2.4.
Michael
-
To unsubscribe from this list: send
[Jeff Garzik]
> > It stays "8139too". Donald Becker's rtl8139.c continues to exist
> > outside the kernel.
Honestly, Jeff, I don't see how it matters -- because if you are
downloading an external driver, you are not going through the config
system anyway.
But ... "maintanicus selector est"
"Eric S. Raymond" wrote:
> Jeff Garzik <[EMAIL PROTECTED]>:
> > You updated Linux-Mandrake's kernel RPM and Linux-Mandrake's installer?
> > Cool!
> No, I didn't. But I can't even imagine how these changes could break those.
Our kernel build process has to look at CONFIG_xxx because we build
"Eric S. Raymond" wrote:
> Jeff Garzik <[EMAIL PROTECTED]>:
> > FWIW I am opposed to any large-scale cleanup of the configuration
> > language and/or identifiers in -any- 2.4.x series kernel.
>
> This is tweaking 39 symbols out of 1831, hardly large-scale. These
> irregularities in the
Jeff Garzik <[EMAIL PROTECTED]>:
> FWIW I am opposed to any large-scale cleanup of the configuration
> language and/or identifiers in -any- 2.4.x series kernel.
This is tweaking 39 symbols out of 1831, hardly large-scale. These
irregularities in the namespace cause trouble out of all proportion
Alan Cox <[EMAIL PROTECTED]>:
> > months ago, and they did -- but the 2.5 fork is nearly upon us and I
> > feel a strong need to get this in before then.
>
> Fix it in 2.5 not before
I hope you will reconsider after you've seen the reasons I posted in a later
message, Alan. You're one of the
> [Kernel 2.4.2,
the -ac kernels contain a patch that automatically resets the nic if it
dies. I've attached my old patch, it applies to 2.4.2.
>
> I tried the diagnostic utilities from Donald Becker at Scyld.com,
> but I don't know what I should be looking for. The text output
> seems ok to
Hello!
On Mon, Mar 26, 2001 at 05:51:43PM +0530, Manoj Sontakke wrote:
> > > ip_options_compile() when called with first argument NULL resets cb to 0.
> > I have found that already.
> > > underlying layer(link and phy) could be anything so where from the
> > > ip_options should start will depend
2.2.19 Documentation/Changes says pcmcia-cs 3.0.14. I am using 3.1.21
and it breaks if you compile the kernel with scsi support then try to
compile pcmcia. clients/apa1480_stub.c in 3.1.21 has
#include <../drivers/scsi/aic7xxx.h>
but in 2.2.19 that file is drivers/scsi/aic7xxx/aic7xxx.h. You
Hi,
On Mon, 26 Mar 2001, Oleg Drokin wrote:
> Hello!
>
> On Mon, Mar 26, 2001 at 04:06:19PM +0530, Manoj Sontakke wrote:
> > >2.4.x kernel. have not tried 2.2
> > >I just found somethig, I believe is kernel bug.
> > >I am working with usbnet.c driver, which stores some of its
> > >
"Eric S. Raymond" wrote:
> I don't care, as long as the result has a non-numeric
> prefix -- bare "8139whatever" is out.
Bullshit. Numeric prefixes work fine in CML1.
With regards to CML2, hardware and driver filenames quite often begin
with numerals, so it is quite logical that config
> months ago, and they did -- but the 2.5 fork is nearly upon us and I
> feel a strong need to get this in before then.
Fix it in 2.5 not before
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Peter Samuelson <[EMAIL PROTECTED]>:
> > CONFIG_8139TOO CONFIG_RTL8139TOO
> > CONFIG_8139TOO_PIO CONFIG_RTL8139TOO_PIO
> > CONFIG_8139TOO_TUNE_TWISTER CONFIG_RTL8139TOO_TUNE_TWISTER
>
> The -TOO suffix was to distinguish between this and the former 8139
> driver, as
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
This one is very much resychronizing with people. It does boot 8) but I've
not tested it hard. Alpha has probably been broken by
On Sun, 25 Mar 2001, Jonathan Morton wrote:
> >> My patch already fixes OOM problems caused by overgrown caches/buffers, by
> >> making sure OOM is not triggered until these buffers have been cannibalised
> >> down to freepages.high. If balancing problems still exist, then they
> >> should be
Jeff Garzik <[EMAIL PROTECTED]>:
> > The -TOO suffix was to distinguish between this and the former 8139
> > driver, as the two coexisted in 2.2 and 2.3. As the old driver has
> > been dropped from 2.4, I propose likewise dropping the -TOO.
>
> It stays "8139too". Donald Becker's rtl8139.c
Well, bummer. I can't seem to find Eric's message archived anywhere.
FWIW I am opposed to any large-scale cleanup of the configuration
language and/or identifiers in -any- 2.4.x series kernel.
Not only C code but installer utilities are affected by changes in the
CONFIG_xxx identifiers. If we
Peter Samuelson wrote:
>
> [esr]
> > CONFIG_8139TOOCONFIG_RTL8139TOO
> > CONFIG_8139TOO_PIOCONFIG_RTL8139TOO_PIO
> > CONFIG_8139TOO_TUNE_TWISTER CONFIG_RTL8139TOO_TUNE_TWISTER
>
> The -TOO suffix was to distinguish between this and the former 8139
> driver,
[esr]
> CONFIG_8139TOOCONFIG_RTL8139TOO
> CONFIG_8139TOO_PIOCONFIG_RTL8139TOO_PIO
> CONFIG_8139TOO_TUNE_TWISTER CONFIG_RTL8139TOO_TUNE_TWISTER
The -TOO suffix was to distinguish between this and the former 8139
driver, as the two coexisted in 2.2 and 2.3.
Hello!
On Mon, Mar 26, 2001 at 04:06:19PM +0530, Manoj Sontakke wrote:
> >2.4.x kernel. have not tried 2.2
> >I just found somethig, I believe is kernel bug.
> >I am working with usbnet.c driver, which stores some of its
> >internal state in sk_buff.cb area. But once such skb
Hi
On Sun, 25 Mar 2001, Oleg Drokin wrote:
> Hello!
>
>2.4.x kernel. have not tried 2.2
>I just found somethig, I believe is kernel bug.
>I am working with usbnet.c driver, which stores some of its
>internal state in sk_buff.cb area. But once such skb passed to
>upper layer
On Fri, Mar 23, 2001 at 10:46:54PM +, Alan Cox wrote:
> > Andy Kellner (from ConnectCom Solutions formerly
> > known as Advansys) and Bob Frey (former maintainer)
> > working in concert have posted several "3.3x" versions
> > of the advansys driver to the linux-scsi list. Despite
>
> I
Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> On 24 Mar 2001, Kevin Buhr wrote:
> >
> > A huge win for 2.96 and absolutely no benefit whatsoever for 3.0, even
> > though it obviously had a 10-fold effect on maps counts. On the
> > positive side, there was no performance *hit* either.
>
> I
It's been rumoured that Stephen Satchell said:
>
> I'm experiencing the same thing
[...]
> Central problem appears to be the KVM
> switch I'm using. Save yourself the problem.
Am not using a KVM switch, or any cable extenders, etc. The USB-to-PS2
connecter came with the mouse, so I assume
> OK I just did it. as I already told I have "stress tested it" by
> Since I'm one day late up to my promise to provide this
> patch it's actually fascinating that already 4 people (in esp. not
> newbees requesting a new /proc entry for everything)
> for reassurance that I will indeed
On Sun, 25 Mar 2001 16:27:37 -0800,
Stephen Satchell <[EMAIL PROTECTED]> wrote:
>I'm experiencing the same thing with an ASUS P5A-B running a K6-2/266 with
>Linux 2.2.17, and Windows 98. Central problem appears to be the KVM
>switch I'm using. Save yourself the problem.
>
>I had to reboot
I'm experiencing the same thing with an ASUS P5A-B running a K6-2/266 with
Linux 2.2.17, and Windows 98. Central problem appears to be the KVM
switch I'm using. Save yourself the problem.
I had to reboot all the systems to get regular mouse operation back with
the Logitech.
Satch
At
Intended behaviour. This is because of the access checks done in the
netlink code. Misleading, yes.
On Sun, 25 Mar 2001, James Stevenson wrote:
>
> Hi
>
> would somebody be able to explain to me
> when you try to open /dev/tap0 which is a
> character device file which has the permissions
>
>
The structure tables size is a concern for me too. Hence the suggestion that
perhaps a hash table implementationg is better suited to the job. The larger
sizes that you need for your Array seem to bear this out. Until a fix is
implemented I'm just going to modify DK_MAX_MAJOR to fix my own
kernel 2.4.2-ac24.
first, i have 256MB of RAM and a 128MB swap. i know the recommendation
is RAM*2 for swap, but is that a *requirement* as well? i understand the
active/inactive page debate and why *2 is needed (lets not argue that),
but am i just wasting space with a 128MB swap?
second, is
> Here is the 'alternate' output when the ncr53c8xx driver is
> compiled in:
>
> SCSI subsystem driver Revision: 1.00
> scsi-ncr53c7,8xx: at PCI bus 0, device 8, function 0
> scsi-ncr53c7,8xx: warning : revision of 35 is greater than 2.
> scsi-ncr53c7,8xx: NCR53c810 at memory 0xfa101000, io
The subject says it all. The bug got trigerred under _Heavy_ load
(bootstraping gcc ang building Xfree at the same time).
My hardware:
Motherboard: Asus P2B
CPU: P-III 600 (no overclocking)
RAM: 384 MB
IDE: PIIX4: IDE controller on PCI bus 00 dev 21
PIIX4:
Got this right after entering init 3 at startup ...
Oops written from screen, so there might be typos.
ksymoops 2.3.4 on i686 2.4.0-test10. Options used
-V (specified)
-K (specified)
-l /proc/modules (default)
-o /lib/modules/2.4.2-ac24/ (specified)
-m
Hello,
[Kernel 2.4.2, gcc-2.9.3 (same problem with egcs-2.91.66),
binutils-2.9.5.0.22-6]
[AMD Thunderbird, ABIT KT7A, no overclocking, D-Link DFE-530TX, 3Com
10Mbit hub, ATI Radeon AGP video, Matrox Mystique PCI video.]
When I download a big sized a few MB from the LAN using FTP, the hub
msdos.c MINI_PARTITION underclared (first use in this function)
msdos.c MINI_NR_SUBPARTITIONS' undeclared (first use in this function)
check msdos.c msdos.h
can not find MINI_PARTITION/MINI_NR_SUBPARTITIONS
is this a bug?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
The attached patch provides a solution for the problem where an
interface is not completely ready by the time /sbin/hotplug is called,
from init_etherdev. The patch also includes semi-related cleanups and
fixes found along the way.
Changes:
* Add alloc_etherdev, alloc_fddidev, alloc_hippi_dev,
Here is the 'alternate' output when the ncr53c8xx driver is
compiled in:
SCSI subsystem driver Revision: 1.00
scsi-ncr53c7,8xx : at PCI bus 0, device 8, function 0
scsi-ncr53c7,8xx : warning : revision of 35 is greater than 2.
scsi-ncr53c7,8xx : NCR53c810 at memory 0xfa101000, io 0x2000, irq 58
Hi,
I am experiencing debilitating intermittent mouse problems & was about
to dive into the kernel to see if I could debug it. But first, I thought
a quick note to the mailing list may help.
Symptoms:
After a long time of flawless operation (ranging from nearly a week to
as little as five
Tom Sightler wrote:
>
[snip]
> I tested 2.4.3-pre7 and it still fails without my patch. With my patch I
> get the above message about 'Redundant entry in serial pci_table' but it
> still manages to setup my serial device as /dev/ttyS4 (the same patch
> applied to 2.4.2-ac21 sets the device to
Ugh, something was going screwy. Trying from a different machine.
--
The attached patch is against 2.4.1 and incorporates the following:
- More optimistic OOM checking, and slightly improved OOM-kill algorithm,
as per my previous patch.
- Accounting of reserved memory, allowing for...
-
On Sun, 25 Mar 2001 10:27:28 -0600,
Nathan Neulinger <[EMAIL PROTECTED]> wrote:
>Is there any way that this can be triggered remotely? I frequently get
>into situations with a particular machine where 'reboot' or 'reboot -f'
>just plain won't work, and would like to be able do a 'filesystem
ACK! that last diff got linewrapped somewhere in transit. Try this one...
-
The attached patch is against 2.4.1 and incorporates the following:
- More optimistic OOM checking, and slightly improved OOM-kill algorithm,
as per my previous patch.
- Accounting of reserved memory, allowing
Hi
I have patched the 2.2.17 kernel (Debian) with the "new RAID" patches
with no errors.
I experienced a the following problem:
Two partitions are set up as RAID-1, but not yet fully
created/initialized. On boot, the process starts/continues
automatically (partitions /dev/hda3 and /dev/hdc3
The attached patch is against 2.4.1 and incorporates the following:
- More optimistic OOM checking, and slightly improved OOM-kill algorithm,
as per my previous patch.
- Accounting of reserved memory, allowing for...
- Non-overcommittal of memory if sysctl_overcommit_memory < 0, enforced
even
Hi
would somebody be able to explain to me
when you try to open /dev/tap0 which is a
character device file which has the permissions
File: "tap0"
Size: 0Filetype: Character Device
Mode: (0666/crw-rw-rw-)
when tried to open
[mistral@linux /dev]$ cat tap0
cat: tap0: Operation not
At 05:30 PM 3/25/01 +0200, you wrote:
> > Ultra reliable systems dont contain memory allocators. There are good
> reasons
> > for this but the design trade offs are rather hard to make in a real world
> > environment
>
>I esp. they run on CPU's without a stack or what?
No dynamic memory
On Tue, 20 Mar 2001, Richard A Nelson wrote:
[snip]
> $ ip addr show tr0
> 5: tr0: mtu 2000 qdisc pfifo_fast qlen 100
>link/[800] 40:00:de:ad:be:ef brd ff:ff:ff:ff:ff:ff
>inet 9.51.81.11/21 brd 9.51.87.255 scope link tr0
>inet6 fe80::4000:dead:beef/10 scope link
>inet6
On Sun, 25 Mar 2001, Guest section DW wrote:
> On Sun, Mar 25, 2001 at 05:35:01PM +0200, Wichert Akkerman wrote:
> > In article <[EMAIL PROTECTED]>,
> > <[EMAIL PROTECTED]> wrote:
> > >a large name space allows one to omit checking what part can be
> > >reused - reuse is unnecessary.
> >
> >
>Hi All,
> I notice that the new aic7xxx driver in 2.4.3-pre7 needs some version
>of the berkeley db. (the make file has -ldb1 in it). It blew
>up on my because I apparently don't have it installed.
Use the latest version of the driver from here:
http://people.FreeBSD.org/~gibbs/linux
It
I am using the Orinoco gold card in a Thinkpad A21p. I have been using the
wvlan_cs module for this card. I attempted to use the new orinoco_cs
driver, I updated /etc/pcmcia/config to have the "device wvlan_cs" use the
new orinoco_cs module rather than the old wvlan_cs. The card is recognized
On Sun, 25 Mar 2001, Linus Torvalds wrote:
> So my suggestion for PAE is:
>
> - populate in gdb_alloc() (ie just do the three "alloc_page()" calls to
>allocate the PMD's immediately)
>
>NOTE: This makes the race go away, and will actually speed things up as
>we will pretty much in
These oopsen were invoked by a normal shell script. Hope you can make
some use of it. Processor is a K6/2.
-Eric
--
ksymoops 2.4.1 on i586 2.4.2-ac23. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.2-ac23/
>> My patch already fixes OOM problems caused by overgrown caches/buffers, by
>> making sure OOM is not triggered until these buffers have been cannibalised
>> down to freepages.high. If balancing problems still exist, then they
>> should be retuned with my patch (or something very like it) in
On Sun, Mar 25, 2001 at 05:35:01PM +0200, Wichert Akkerman wrote:
> In article <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
> >a large name space allows one to omit checking what part can be
> >reused - reuse is unnecessary.
>
> You are just delaying the problem then, at some point your
On Sun, Mar 25, 2001 at 01:32:42AM +0100, Kurt Garloff wrote:
> On Fri, Mar 23, 2001 at 05:26:22PM +, James A. Sutherland wrote:
> > If SuSE's install program needs more than a quarter Gb of RAM, you need a
> > better distro.
>
> Well, it's rpm ...
Yes. I investigated and found rpm's data
On Sun, 25 Mar 2001, Ingo Molnar wrote:
>
> one nontrivial issue was that on PAE the pgd has to be installed with
> 'present' pgd entries, due to a CPU erratum. This means that the
> pgd_present() code in mm/memory.c, while correct theoretically, doesnt
> work with PAE. An equivalent solution
Hi All,
I notice that the new aic7xxx driver in 2.4.3-pre7 needs some version
of the berkeley db. (the make file has -ldb1 in it). It blew
up on my because I apparently don't have it installed.
.~. Todd Roy, Senior Database Administrator .~.
/V\ Holstein Association, U.S.A. Inc.
Hi All,
I notice that the new aic7xxx driver needs some version
of the berkekey db. (the make file has -ldb1 in it). It blew
up on my because I apparently don't have it installed.
--
.~. Todd Roy, Senior Database Administrator .~.
/V\ Holstein Association, U.S.A. Inc. /V\
Ok, i don't really know much about the kernel at all, but here's my opinion
anyway..
To use 64bit pids when 32bit is enough just to "make things easier" doesn't
sound like a good idea to me. Eventually it might wrap around (fx. as on that
supercomputer Jamie Lokier talked about) to overwrite
On Sun, 25 Mar 2001, Martin Dalecki wrote:
> Rik van Riel wrote:
> > - the AGE_FACTOR calculation will overflow after the system has
> > an uptime of just _3_ days
>
> I esp. the behaviour will be predictable.
U ?
Rik
--
Virtual memory is like a game you can't win;
However, without VM
> Ever heard of cut-and-paste? Surely you can afford a mouse... And
> for when
> you you are not inputting manually but running a script/whatever,
> who cares
> what the numbers are...
>
> Cheers,
>
> Anton
Oops. Okay, you're right.
-
To unsubscribe from this list: send the line
Michel Wilson wrote:
> Ever thought about how you would kill a process: kill -9 127892752 doesn't
> sound very appealing to me.
man killall(1). Kill processes by name.
> So you'd also need to implement a mechanism that allows for 'easy' selection
> of processes to kill, for example giving
Mitchell Blank Jr wrote:
> Wichert Akkerman wrote:
> > You are just delaying the problem then, at some point your uptime will
> > be large enough that you have run through all 64bit pids for example.
>
> 64 bits is enough to fork 1 million processes per second for over
> 500,000 years. I think
On Sat, Mar 24, 2001 at 10:53:08PM +0100, Ingo Oeser wrote:
> On Sat, Mar 24, 2001 at 06:25:16PM +0100, Alex Riesen wrote:
> > As i recompiled 2.4.2-ac20 with ACPI support
> > the system cannot switch itself off.
> > I get a message "Couldn't switch to S5" if
> > try to call reboot(2).
> > At
On Sat, 24 Mar 2001, Jonathan Morton wrote:
> >> While my post didn't give an exact formula, I was quite clear on the
> >>fact that
> >> the system is allowing the caches to overrun memory and cause oom problems.
> >
> >Yes. A testcase would be good. It's not happening to everybody nor is
>
At 17:54 25/03/2001, Michel Wilson wrote:
> > Wichert Akkerman wrote:
> > > You are just delaying the problem then, at some point your uptime will
> > > be large enough that you have run through all 64bit pids for example.
> >
> > 64 bits is enough to fork 1 million processes per second for over
Jakob Østergaard wrote:
> But the bad case was a garbage collector in GCC. The mmap tricks seem like
> some you may be inclined to actually use in something like garbage collectors.
> Are we sure that the developers of all other garbage collectors out there
> foresaw this problem and didn't do
Hi,
On Sat, Mar 24, 2001 at 10:05:18PM -0300, Rik van Riel wrote:
> On Sun, 25 Mar 2001, Stephen C. Tweedie wrote:
>
> > Rik, do you think it is really necessary to take the page lock and
> > release it inside lookup_swap_cache? I may be overlooking something,
> > but I can't see the benefit
> Wichert Akkerman wrote:
> > You are just delaying the problem then, at some point your uptime will
> > be large enough that you have run through all 64bit pids for example.
>
> 64 bits is enough to fork 1 million processes per second for over
> 500,000 years. I think that's putting the problem
>[ about non-overcommit ]
>> > Nobody feels its very important because nobody has implemented it.
>
>Enterprises use other systems because they have much better resource
>management than Linux -- adding non-overcommit wouldn't help them much.
>Desktop users, Linux newbies don't
On Sat, Mar 24, 2001 at 02:57:27AM -0300, Rik van Riel wrote:
> On Fri, 23 Mar 2001, Guest section DW wrote:
> > On Fri, Mar 23, 2001 at 11:56:23AM -0300, Rik van Riel wrote:
> > > On Fri, 23 Mar 2001, Martin Dalecki wrote:
> >
> > > > > Feel free to write better-working code.
> > > >
> > > > I
On Sun, Mar 25, 2001 at 04:53:37PM +0200, Ingo Molnar wrote:
> one nontrivial issue was that on PAE the pgd has to be installed with
> 'present' pgd entries, due to a CPU erratum. This means that the
> pgd_present() code in mm/memory.c, while correct theoretically, doesnt
> work with PAE. An
>> I didn't quite understand Martin's comments about "not normalised" -
>> presumably this is some mathematical argument, but what does this actually
>> mean?
>
>Not mathematics. It's from physics. Very trivial physics, basic scool
>indeed.
>If you try to calculate some weightning
>factors which
There is a problem with the power management code for console.c
The current code calls do_blank_screen(0); on PM_SUSPEND, and
unblank_screen() on PM_RESUME.
The problem happens when X is the current display while putting the
machine to sleep. The do_blank_screen(0) code will do nothing as
the
Wichert Akkerman wrote:
> You are just delaying the problem then, at some point your uptime will
> be large enough that you have run through all 64bit pids for example.
64 bits is enough to fork 1 million processes per second for over
500,000 years. I think that's putting the problem off far
Is there any way that this can be triggered remotely? I frequently get
into situations with a particular machine where 'reboot' or 'reboot -f'
just plain won't work, and would like to be able do a 'filesystem clean'
forcible reboot, but don't particularly care about services being shut
down
On Mon, 19 Mar 2001, Linus Torvalds wrote:
> The complete changelog is appended, but the biggest recent change is
> the mmap_sem change, which I updated with new locking rules for
> pte/pmd_alloc to avoid the race on the actual page table build.
>
> This has only been tested on i386 without
On Sat, 24 Mar 2001, Jesse Pollard wrote:
> On Fri, 23 Mar 2001, Alan Cox wrote:
[ about non-overcommit ]
> > Nobody feels its very important because nobody has implemented it.
Enterprises use other systems because they have much better resource
management than Linux -- adding
Jonathan Morton wrote:
>
> >- the AGE_FACTOR calculation will overflow after the system has
> > an uptime of just _3_ days
>
> Tsk tsk tsk...
>
> >Now if you can make something which preserves the heuristics which
> >serve us so well on desktop boxes and add something that makes it
> >also
>> >start your app, wait for malloc to fail, hit enter for the other app and
>> >watch you app to be OOM killed ;)
>>
>> That would only happen if memory_overcommit was turned on, in which case my
>> modification would have zero effect anyway (the overcommit test happens
>> before my code).
>
Martin Dalecki wrote:
> Rik van Riel wrote:
> > - the comments are just too rude ;)
> > (though fun)
>
> That's only a matter for the "smooth" anglosaxons. Different
> cultures have different measures on this. I don't feel the need
> to adjust myself to the american cultural obstructivity.
>
Alan Cox wrote:
>
> > That depends what you mean by "must not". If it's your missile guidance
> > system, aircraft autopilot or life support system, the system must not run
> > out of memory in the first place. If the system breaks down badly, killing
> > init and thus panicking (hence
>- the AGE_FACTOR calculation will overflow after the system has
> an uptime of just _3_ days
Tsk tsk tsk...
>Now if you can make something which preserves the heuristics which
>serve us so well on desktop boxes and add something that makes it
>also work on your Oracle servers, then I'd be
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>a large name space allows one to omit checking what part can be
>reused - reuse is unnecessary.
You are just delaying the problem then, at some point your uptime will
be large enough that you have run through all 64bit pids for
Rik van Riel wrote:
>
> On Sun, 25 Mar 2001, Martin Dalecki wrote:
>
> > Ah... and of course I think this patch can already go directly
> > into the official kernel. The quality of code should permit
> > it. I would esp. request Rik van Riel to have a closer look
> > at it...
>
> - the
I run linux 2.4.2-ac24 on the ULTRA 100 card with pdc 20267 Chip.
Drives are MAXTOR 53073H4 UDMA100.
Everything runs fine so far. The only thing which iritates me is
that :
/proc/ide/pdc202xx reports that the drives run in UDMA4 mode.
I have the above mentioned drives running as master each
Kurt Garloff wrote:
> Kernel related questions IMHO are:
> (1) Why do we get into OOM?
There was a long thread about this a few months back. We get into OOM because
malloc(), calloc() etc. can allocate more memory than is actually available.
e.g. Say you have machine with 64 RAM + 64 swap =
On Sun, 25 Mar 2001, Martin Dalecki wrote:
> Ah... and of course I think this patch can already go directly
> into the official kernel. The quality of code should permit
> it. I would esp. request Rik van Riel to have a closer look
> at it...
- the algorithms are just as much black magic as
On Fri, 23 Mar 2001, Jonathan Morton wrote:
> >The main point is letting malloc fail when the memory cannot be
> >guaranteed.
>
> If I read various things correctly, malloc() is supposed to fail as you
> would expect if /proc/sys/vm/overcommit_memory is 0. This is the case on
> my RH 6.2 box,
Linus Torvalds wrote:
>
> On Sat, 24 Mar 2001 [EMAIL PROTECTED] wrote:
> >
> > We need a size, and I am strongly in favor of sizeof(dev_t) = 8;
> > this is already true in glibc.
>
> The fact that glibc is a quivering mass of bloat, and total and utter crap
> makes you suggest that the Linux
Stephen Satchell wrote:
>
> At 12:41 AM 3/25/01 +0100, you wrote:
> >If your box is running for example a mail server, and it appears that
> >another process is juste eating the free memory, do you really want to kill
> >the mail server, just because it's the main process and consuming more
>
Jonathan Morton wrote:
>
> >Right now my best approximation is to make the OOM test be as optimistic as
> >it is safe to be, and the vm_enough_memory() test as pessimistic as
> >sensible. Expect a test patch to appear on this list soon.
>
> ...and here it is!
>
> This fixes a number of small
Jeff Garzik wrote:
>
> Also for 2.5, kdev_t needs to go away, along with all those arrays based
> on major number, and be replaced with either "struct char_device" or
> "struct block_device" depending on the device.
>
> I actually went through the kernel in 2.4.0-test days and did this.
> Most
1 - 100 of 226 matches
Mail list logo
