Hi,
Could anyone please explain the major changes to the ppp module from
2.4.1 to 2.4.3? I've noticed that ppp performance isn't as fast as it
was using 2.4.1, and after a week using 2.4.3 i've concluded that ppp is
definitely slower. I've looked at the ppp_* files but so far the only
changes i s
Mark Salisbury wrote:
>
> It would probably be a good compile config option to allow fine or coarse
> process time accounting, that leaves the choice to the person setting up the
> system to make the choice based on their needs.
>
I suggested this a while ago during a discussion about performan
On Tue, Apr 10, 2001 at 10:35:54PM -0700, Shane Wegner wrote:
> Hi,
>
> This isn't working here on my Abit VP6 board. The
> ide.2.2.18.1221 works fine but this latest patch as well as
> ide.2.2.19.0325 fails.
>
> Uniform Multi-Platform E-IDE driver Revision: 6.30
> ide: Assuming 33MHz system bu
On Mon, Apr 09, 2001 at 05:33:13PM -0700, Andre Hedrick wrote:
>
> This is up with some updates
Hi,
This isn't working here on my Abit VP6 board. The
ide.2.2.18.1221 works fine but this latest patch as well as
ide.2.2.19.0325 fails.
Uniform Multi-Platform E-IDE driver Revision: 6.30
ide: Assum
XFree86 X window updates are slower on 2.4 than 2.2, by a significant amount.
I've observed this comparing 2.2.18 with 2.4.1 and one of the 2.4.pre kernels.
I've seen it with ATI Rage 128, Geforce 1 and GeForce 2 MX. I've seen it on
two different computers, both Athlon based. Just any rectangular
On Tue, Apr 10, 2001 at 09:08:16PM -0700, Paul McKenney wrote:
> > Disabling preemption is a possible solution if the critical section is
> short
> > - less than 100us - otherwise preemption latencies become a problem.
>
> Seems like a reasonable restriction. Of course, this same limit applies
>
All,
Here is the second patch for ps2esdi.
This one corrects/updates the DMA handling.
In case my mailer mangles it, it is also available at
http://www.sound.net/~hald/projects/ps2esdi/ps2esdi-2.4.3.patch1
Thanks, and not on the list,
Hal Duston
[EMAIL PROTECTED]
Bring DMA up to date with cur
Kurt Roeckx <[EMAIL PROTECTED]> on 04/11/2001 06:16:52 AM
To: Miquel van Smoorenburg <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED] (bcc: Amol Lad/HSS)
Subject: Re: Let init know user wants to shutdown
On Wed, Apr 11, 2001 at 01:38:30AM +0200, Kurt Roeckx wrote:
> On Tue, Apr 10, 2001
On Tue, Apr 10, 2001 at 10:05:13AM -0700, Grover, Andrew wrote:
> This is not correct, because we want the power button to be configurable.
> The user should be able to redefine the power button's action, perhaps to
> only sleep the system. We currently surface button events to acpid, which
> then
> On Tue, 10 Apr 2001, Paul McKenney wrote:
> > The algorithms we have been looking at need to have absolute guarantees
> > that earlier activity has completed. The most straightforward way to
> > guarantee this is to have the critical-section activity run with
preemption
> > disabled. Most of
Mark Salisbury wrote:
>
> > mark salisbury wrote:
> > >
> > > george anzinger wrote:
> > >
> > > > f) As noted, the account timers (task user/system times) would be much
> > > > more accurate with the tick less approach. The cost is added code in
> > > > both the system call and the schedule pat
Hi,
Since the 2.5 kernel development will require continued module
architecture changes to accomodate power management, pluggable
security and PCMCIA in the kernel tree, it would seem to make
sense that the various groups that are doing module related
architecture changes collaborate and be aware
On Tue, Apr 10, 2001 at 06:12:12PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 11 Apr 2001, Andi Kleen wrote:
> >
> > Fixup for user space is probably not that nice (CMPXCHG is used there by
> > linuxthreads)
>
> In user space I'm not convinced that you couldn't do the same thing
> equally well
On Wed, 11 Apr 2001, Andi Kleen wrote:
>
> Fixup for user space is probably not that nice (CMPXCHG is used there by
> linuxthreads)
In user space I'm not convinced that you couldn't do the same thing
equally well by just having the proper dynamically linked library. You'd
not get in-lined lock
On Tue, Apr 10, 2001 at 05:55:09PM -0700, Linus Torvalds wrote:
> Note that the "fixup" approach is not necessarily very painful at all,
> from a performance standpoint (either on 386 or on newer CPU's). It's not
> really that hard to just replace the instruction in the "undefined
> instruction"
On Tue, Apr 10, 2001 at 05:35:31PM -0700, Mike Castle wrote:
> On Wed, Apr 11, 2001 at 02:21:42AM +0200, Andi Kleen wrote:
> > Try echo 0 > /proc/sys/net/ipv4/tcp_ecn
> > If it helps complain to the sites that their firewall is broken.
>
> It's certain that this refers only to the site firewall?
On Wed, Apr 11, 2001 at 02:56:32AM +0200, David Weinehall wrote:
> My reasoning is that the choice of computer is a direct function of
> your financial situation. I can get hold of a lot of 386's/486's, but
> however old a Pentium may be, people are still reluctant to give away
> those. Doing the
On Wed, Apr 11, 2001 at 02:20:28AM +0200, Andi Kleen wrote:
> On Wed, Apr 11, 2001 at 02:13:18AM +0200, David Weinehall wrote:
> > >
> > > Yes, and with CMPXCHG handler in the kernel it wouldn't be needed
> > > (the other 686 optimizations like memcpy also work on 386)
> >
> > But the code wou
On Wed, 11 Apr 2001, David Weinehall wrote:
> >
> > Yes, and with CMPXCHG handler in the kernel it wouldn't be needed
> > (the other 686 optimizations like memcpy also work on 386)
>
> But the code would be much slower, and it's on 386's and similarly
> slow beasts you need every cycle you can g
> mark salisbury wrote:
> >
> > george anzinger wrote:
> >
> > > f) As noted, the account timers (task user/system times) would be much
> > > more accurate with the tick less approach. The cost is added code in
> > > both the system call and the schedule path.
> > >
> > > Tentative conclusions:
One of the byproducts of the Linux 2.5 Kernel Summit
http://lwn.net/2001/features/KernelSummit/ was the notion of an
enhancement of the loadable kernel module interface to facilitate
security-oriented kernel modules. The purpose is to ease the tension
between folks (such as Immunix and SELinux) w
Sequent Symmetry machinses supported SMP on i486 and even i386 going back
to the original 16MHz 386 processors. You could put up to 30 in a system.
I do not, however, envisage anyone porting Linux to these any time soon.
The hardware is just too "unusual" for it to be feasible. The later Symmetry
On Wed, Apr 11, 2001 at 02:21:42AM +0200, Andi Kleen wrote:
> Try echo 0 > /proc/sys/net/ipv4/tcp_ecn
> If it helps complain to the sites that their firewall is broken.
It's certain that this refers only to the site firewall?
I had to do this to get to www.ibm.com. :-<
mrc
--
Mike Cast
On Tue, Apr 10, 2001 at 06:24:46PM -0400, Dave wrote:
>
> I am having a very strange problem in linux 2.4 kernels. I have not set
> any iptables rules at all, and there is no firewall blocking any of my
> outgoing traffic. At what seems like random selection, I can not connect
> to IP's yet I c
On Wed, Apr 11, 2001 at 02:13:18AM +0200, David Weinehall wrote:
> >
> > Yes, and with CMPXCHG handler in the kernel it wouldn't be needed
> > (the other 686 optimizations like memcpy also work on 386)
>
> But the code would be much slower, and it's on 386's and similarly
> slow beasts you nee
On Wed, Apr 11, 2001 at 02:00:58AM +0200, Andi Kleen wrote:
> On Tue, Apr 10, 2001 at 11:00:31PM +0100, Alan Cox wrote:
> > > I guess 386 could live with an exception handler that emulates it.
> >
> > 386 could use a simpler setup and is non SMP
>
> The idea was to have a `generic' kernel that w
This patch adds a couple of comments to the cdrom and SCSI code warning of
duplicate ioctl numbers.
Cheers, Andreas
diff -ru linux.orig/include/linux/cdrom.h linux/include/linux/cdrom.h
--- linux.orig/include/linux/cdrom
On Tue, Apr 10, 2001 at 11:00:31PM +0100, Alan Cox wrote:
> > I guess 386 could live with an exception handler that emulates it.
>
> 386 could use a simpler setup and is non SMP
The idea was to have a `generic' kernel that works on all architectures.
If you drop 386 support much is better alread
According to Kurt Roeckx:
> On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
> > The "-1" means
> > "all processes except me". That means init will get hit with
> > SIGTERM occasionally during shutdown, and that might cause
> > weird things to happen.
>
> -1 mean everything
On Tue, 10 Apr 2001, Paul McKenney wrote:
> The algorithms we have been looking at need to have absolute guarantees
> that earlier activity has completed. The most straightforward way to
> guarantee this is to have the critical-section activity run with preemption
> disabled. Most of these code
On Wed, Apr 11, 2001 at 01:38:30AM +0200, Kurt Roeckx wrote:
> On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
> >
> > the shutdown scripts
> > include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
> > "all processes except me". That means init will get hit with
> > S
Hey,
I've been trying to compile 2.4.3ac2 - ac4 and have had the same problem everytime.
It deals with pmac_pic.c (I sent this to Cort <[EMAIL PROTECTED]> as well)
As I never meddle with kernel source I'm sorta at a loss (hope to change this one day)
Error is as follows:
gcc -D__KERNEL__ -I/usr/
On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> Pavel Machek <[EMAIL PROTECTED]> wrote:
> >Init should get to know that user pressed power button (so it can do
> >shutdown and poweroff). Plus, it is nice to let user know that we can
>
>
On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
>
> the shutdown scripts
> include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
> "all processes except me". That means init will get hit with
> SIGTERM occasionally during shutdown, and that might cause
> weird things
The following patch adds the LVM ioctl number to Documentation/ioctl-numer.txt.
I had previously sent this directly to MEC as well.
Cheers, Andreas
==
--- linux.orig/Documentation/ioctl-number.txt Tue Apr 10 17:13:00 20
In article <9b04fo$9od$[EMAIL PROTECTED]>,
Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote:
>SIGTERM is a bad choise. Right now, init ignores SIGTERM. For
>good reason; on some (many?) systems, the shutdown scripts
>include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
>"all processes except
Attached is a very minor patch that is in my tree (I don't even remember why
I was in there) which uses the defined PCI vendor ID instead of a number.
Cheers, Andreas
diff -ru linux.orig/drivers/scsi/atp870u.c linux/driv
In article <[EMAIL PROTECTED]>,
Pavel Machek <[EMAIL PROTECTED]> wrote:
>Hi!
>
>Init should get to know that user pressed power button (so it can do
>shutdown and poweroff). Plus, it is nice to let user know that we can
>read such event. [I hunted bug for few hours, thinking that kernel
>does not
This did fix my problem. Thanks very much, I'll be sure to send a polite
message to the admins at sites where I notice this problem! Any detailed
info you might have on why this was failing?
dave
---
This is my signature. There are many like it but this one is mine.
On Tue, 10 Apr 2
On Tue, Apr 10, 2001 at 06:24:46PM -0400, Dave wrote:
> I am having a very strange problem in linux 2.4 kernels. I have not set
> any iptables rules at all, and there is no firewall blocking any of my
> outgoing traffic. At what seems like random selection, I can not connect
> to IP's yet I can
> > As you've observed, with the approach of waiting for all pre-empted
tasks
> > to synchronize, the possibility of a task staying pre-empted for a long
> > time could affect the latency of an update/synchonize (though its hard
for
> > me to judge how likely that is).
>
> It's very unlikely on a
Hi,
I encountered a problem with 2.4 kernels today.
Decompressing a 60+ Mb file with bzip2, residing on a vfat partition, gave
errors reporting that the archive was corrupt.
When I rebooted into windows and ran scandisk it couldn't find any problem
with the partition. That made me suspicious...
> Our Dell 4300, plus raid card, works okay with a 2.2.14
> kernel, which has a version 107 megaraid.o module. This
> is many versions behind the version present in 2.4.3. More
> recent driver modules for the card hand on booting, thus this
> problem report.
Chances are you have downrev firmwar
On Tue, 10 Apr 2001, Alan Cox wrote:
> > Any time I start injecting lots of mail into the qmail queue, *one* of the
> > two processors gets pegged at 99%, and it takes forever for anything typed
> > at the console to actually appear (just as you describe). But I don't see
>
> Yes I've seen this
I am having a very strange problem in linux 2.4 kernels. I have not set
any iptables rules at all, and there is no firewall blocking any of my
outgoing traffic. At what seems like random selection, I can not connect
to IP's yet I can get ping replies from them. Most IP's reply just fine,
but c
Our Dell 4300, plus raid card, works okay with a 2.2.14
kernel, which has a version 107 megaraid.o module. This
is many versions behind the version present in 2.4.3. More
recent driver modules for the card hand on booting, thus this
problem report.
The module source does not indicate a recent
mark salisbury wrote:
>
> george anzinger wrote:
>
> > f) As noted, the account timers (task user/system times) would be much
> > more accurate with the tick less approach. The cost is added code in
> > both the system call and the schedule path.
> >
> > Tentative conclusions:
> >
> > Currently
Andrea Arcangeli wrote:
>
[ ... ]
>
> BH_Req is never unset until the buffer is destroyed (put back on the freelist).
> BH_Req only says if such a buffer ever did any I/O yet or not. It is basically
> only used to deal with I/O errors in sync_buffers().
Interesting. Thanks for the expla
Hello!
This happens on RedHat Linux 7.0, i686 with Linux-2.4.3-ac3.
Chmod on the top-level inode of ramfs make it impossible to unmount the
filesystem.
Chmod on other files has no effect.
[root@fonzie /root]# umount t1
[root@fonzie /root]# mount -t ramfs none t1
[root@fonzie /root]# touch t1/fo
> Any time I start injecting lots of mail into the qmail queue, *one* of the
> two processors gets pegged at 99%, and it takes forever for anything typed
> at the console to actually appear (just as you describe). But I don't see
Yes I've seen this case. Its partially still a mystery
> Upon pow
> I guess 386 could live with an exception handler that emulates it.
386 could use a simpler setup and is non SMP
> (BTW an generic exception handler for CMPXCHG would also be very useful
> for glibc -- currently it has special checking code for 386 in its mutexes)
> The 386 are so slow that no
> The current way of doing things on x86 -- essentially selecting a
> minimal level of CPU support -- is nice for vendors like Mandrake who
That isnt how the current x86 one works. It just sort of looks like that
for a common subset.
-
To unsubscribe from this list: send the line "unsubscribe li
> That's no problem if we make this SMP-specific - I doubt anybody actually
> uses SMP on i486's even if the machines exist, as I think they all had
They do. There are two (total world wide) 486 SMP users I know about and they
mostly do it to be awkward ;)
> special glue logic that Linux would h
On Tue, Apr 10, 2001 at 01:12:02PM -0700, Rajagopal Ananthanarayanan wrote:
>
> Hi,
>
> It seems BH_Req is set on a buffer_head by submit_bh.
> What part of the code unsets this flag during normal
> operations? One path seems to be block_flushpage->unmap_buffer
> ->clear_bit(BH_Req), but IIRC bl
On Tue, Apr 10, 2001 at 08:00:19AM -0600, Justin T. Gibbs wrote:
> >
> I'm pretty sure you need to be up to at leaset 0005 of
> the firmware to stabilize this drive.
FYI, I contacted seagate and they say the firmware is the latest.
Regards,
Gene/
-
To unsubscribe from this li
"Manuel A. McLure" wrote:
> I'd do that if this wasn't also my Windows 98 gaming machine - I'm supposing
> that the Windows drivers do use the IRQ even if XFree86/Linux doesn't. I
> dunno if Windows is smart enough to assign an IRQ even if the BIOS doesn't.
> Anyway, things are working now (specia
> > I do have an IRQ for my VGA since the instructions for my
> card (a Voodoo 5
> > 5500) specifically say an IRQ is needed.
>
> I wonder though... In my mind this is a driver not hardware issue. If
> the XFree86 and/or Linux console driver do not use the IRQ,
> you need not
> have BIOS assi
Hello.
I've attached to this mail a patch for the FEC driver
on the Motorola MPC8xx embedded CPU.
This patch includes both a bug fix, and a new PHYter implementation.
Symptom
-
I was experiencing problems of "transmission timeout" when heavily
loading the network (throughput tests), p
Hello.
On Tue, Apr 10, 2001 at 09:38:43PM +0400, [EMAIL PROTECTED] wrote:
> If my guess is right, you can easily put this socket to funny state
> just catting a large file and kill -STOP'ing ssh. ssh will close window,
> but sshd will not send zero probes.
[1] I have checked your statement on
"Manuel A. McLure" wrote:
> Jeff Garzik said...
> > Changing '#undef DEBUG' to '#define DEBUG 1' in
> > arch/i386/kernel/pci-i386.h is also very helpful. Can you guys do so,
> > and post the 'dmesg -s 16384' results to lkml? This includes the same
> > information as dump_pirq, as well as some ad
Jeff Garzik said...
> Changing '#undef DEBUG' to '#define DEBUG 1' in
> arch/i386/kernel/pci-i386.h is also very helpful. Can you guys do so,
> and post the 'dmesg -s 16384' results to lkml? This includes the same
> information as dump_pirq, as well as some additional information.
Here's my dme
"Stephen D. Williams" <[EMAIL PROTECTED]> writes:
> James Antill wrote:
> >
> > I seemed to miss the original post, so I can't really comment on the
> > tests. However...
>
> It was a thread in January, but just ran accross it looking for
> something else. See below for results.
Ahh, ok.
>
I've seen similar 'unresponsiveness' running 2.4.3-ac2 on a Qmail server.
The hardware is dual-processor PIII 650 w/1GB of RAM. SCSI is sym53c895
with dual Quantum 9gb drives.
Any time I start injecting lots of mail into the qmail queue, *one* of the
two processors gets pegged at 99%, and it tak
when I unmount and remount a vfat file system, the time stamp of a recently
created file changes by one hour.
This does not happen on the same system when running 2.2.17.
Script started on Mon Apr 9 13:59:26 2001
sh-2.03# uname -a
Linux tahiti 2.4.2 #7 Mon Mar 26 23:50:57 CEST 2001 i686 unknown
On Tue, 10 Apr 2001, Andi Kleen wrote:
>
> I guess 386 could live with an exception handler that emulates it.
That approach is fine, although I'd personally prefer to take the
exception just once and just rewrite the instuction as a "call". The
places that need xadd would have to follow some st
Hi,
It seems BH_Req is set on a buffer_head by submit_bh.
What part of the code unsets this flag during normal
operations? One path seems to be block_flushpage->unmap_buffer
->clear_bit(BH_Req), but IIRC block_flushpage is used only
for truncates. There must be another path to unset BH_Req
under
Hi!
I downloaded the patch to kernel 2.4.3 but it just doesn't compile on my
system! I have been using kernel 2.4 since 2.4.0-test8 without problems...
Here are the last lines of the compilation output: (in Portuguese)
make[2]: Saindo do diretório `/usr/src/linux/arch/i386/lib'
make[1]: Saindo
On Tue, Apr 10, 2001 at 12:42:07PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 10 Apr 2001, David Howells wrote:
> >
> > Here's a patch that fixes RW semaphores on the i386 architecture. It is very
> > simple in the way it works.
>
> XADD only works on Pentium+.
My Intel manual says it 486+:
`
Thanks.
cat /proc/slabinfo look like as follows.
Each row have three columns.
Could you tell me what do they mean in second and third column?
kmem_cache29 42
pio_request0 0
My second question is:
We can find memory usage of daemon(apache) by ps or top.
e.g. apache use
On Tue, 10 Apr 2001, Jussi Hamalainen wrote:
>program vers proto port
> 102 tcp111 portmapper
> 102 udp111 portmapper
> 1000211 udp 1024 nlockmgr
> 1000213 udp 1024 nlockmgr
> 151 udp686 mountd
> 15
> "Heinz" == Heinz J Mauelshagen <[EMAIL PROTECTED]> writes:
Heinz> a tarball of the Linux Logical Volume Manager 0.9.1 Beta 7 is
Heinz> available now at
The following code is bd, m'kay...
[...]
down(&_pe_lock);
if((pe_lock_req.lock == LOCK_PE) &&
(rdev_map =
My machine is an 8 processor Dell P-III 700Mhz with 8GB of memory.
The disk system I am using is a 12 drawer JBOD with 5 disks in a raid
5 arrangement attached to an AMI Megaraid 438/466/467/471/493
controller with a total of 145GB of space. The machine has been in
use for about 6 months doing pr
On Tue, Apr 10, 2001 at 02:45:15PM -0400, Stephen D. Williams wrote:
> When this is rewritten, I would strongly suggest that we find a way to
> make 'gettimeofday' nearly free. Certain applications need to use this
> frequently while still being portable. One solution when you do have
> clock ti
george anzinger wrote:
> f) As noted, the account timers (task user/system times) would be much
> more accurate with the tick less approach. The cost is added code in
> both the system call and the schedule path.
>
> Tentative conclusions:
>
> Currently we feel that the tick less approach is not
Linus Torvalds wrote:
> That's no problem if we make this SMP-specific - I doubt anybody actually
> uses SMP on i486's even if the machines exist, as I think they all had
> special glue logic that Linux would have trouble with anyway. But the
> advantages of being able to use one generic kernel th
Jamie Lokier wrote:
>
> Alan Cox wrote:
>
> Except for cards which don't generate an irq on vsync but do let you see
> how the raster is proceeding. (I vaguely recall these). For which a
> PLL and, wait for it high resolution timer is needed.
>
> Perhaps that's a 1990s problem that doesn
I also have seen the Kernel BUG at highmem.c:155 problem on a machine
I am testing. It is a Dell 8 processor P-III 700Mhz with 8GB of
memory and Linux 2.4.3 + a knfsd and quota patch for reiserfs. When
doing 5 simultaneous kernel compiles from another machine mounting the
8 processor one over nf
When this is rewritten, I would strongly suggest that we find a way to
make 'gettimeofday' nearly free. Certain applications need to use this
frequently while still being portable. One solution when you do have
clock ticks is a read-only mapped Int. Another cheap solution is
library assembly th
On Tue, 10 Apr 2001, David Howells wrote:
>
> Here's a patch that fixes RW semaphores on the i386 architecture. It is very
> simple in the way it works.
XADD only works on Pentium+.
That's no problem if we make this SMP-specific - I doubt anybody actually
uses SMP on i486's even if the machine
Alan Cox wrote:
>
> > Games would like to be able to page flip at vertical refresh time --
> > <1ms accuracy please. Network traffic shaping benefits from better than
>
> This is an X issue. I was talking with Jim Gettys about what is needed to
> get the relevant existing X extensions for this
Just for your information we have a project going that is trying to come
up with a good solution for all of this:
http://sourceforge.net/projects/high-res-timers
We have a mailing list there where we have discussed much of the same
stuff. The mailing list archives are available at sourceforge.
James Antill wrote:
>
> "Stephen D. Williams" <[EMAIL PROTECTED]> writes:
>
> > An old thread, but important to get these fundamental performance
> > numbers up there:
> >
> > 2.4.2 on an 800mhz PIII Sceptre laptop w/ 512MB ram:
> >
> > elapsed time for 10 pingpongs is
> > 3.81327
> > 10
Andre Hedrick wrote:
>
...
> DiskPerf /dev/hde
> Device: IBM-DTLA-307075 Serial Number: YSDYSFA5874
> LBA 0 DMA Read Test = 63.35 MB/Sec (3.95 Seconds)
> Outer Diameter Sequential DMA Read Test = 35.89 MB/Sec (6.97 Seconds)
> Inner Diameter Sequential DMA Read Test = 17.64
Daniel writes:
> > Are you going to go to a COMPAT flag before final release? This is
> > pretty much needed for e2fsck to be able to detect/correct indexes.
>
> I will if I know what the exact semantics are. I have only an
> approximate idea of how this works and I'd appreciate a more precise
On Tue, Apr 10, 2001 at 01:38:32PM -0400, Jeff Garzik wrote:
> Axel Thimm wrote:
> > 0.7.[2,3] are the usb devices. BIOS (and 2.2 kernels) had them at IRQ 5.
> > 2.4 somehow picks the irq of the ethernet adapter, iqr 11, instead.
> > At least usb is then unusable.
> > As you say that you have the
On Tue, Apr 10, 2001 at 12:57:43PM -0500, Ryan Hairyes wrote:
> Could some one tell me what modules need to be selected to
> make ppp successfully dialup and stay connected with 2.4.3?
> Or give me somewhere to look for this answer.
ppp_async. You can load it by 'modprobe ppp_async'.
--Willia
This is my problem:
My server program is continually sending the client a whole lot of
messages.
The client sends the server an MSG_OOB(out-of-band) message, goes to
sleeps in a loop and waits for the server to reply.
The server's reply to this message will raise the signal SIGURG, which
wa
I have two PCs running Slackware 7.1. I can't get lockd to work
properly with NFS:
Apr 10 21:03:59 sputnik kernel: nsm_mon_unmon: rpc failed, status=-93
Apr 10 21:03:59 sputnik kernel: lockd: cannot monitor xxx.xxx.xxx.xxx
Apr 10 21:03:59 sputnik kernel: lockd: failed to monitor xxx.xxx.xxx.xxx
Hiya, list.
Think i've found a rather nasty bug in the kernel, and I need some clues
as to where to look for the issue.
Stats:
Quad Xeon (PIII core) 700mhz machine (1mb cache on each)
4gb RAM
5x36gb SCSI disks - on a DAC1100 RAID controller
3 EEPro 100 cards
The box functions as a database ser
Alan Cox wrote:
> > > This is an X issue. I was talking with Jim Gettys about what is needed to
> > > get the relevant existing X extensions for this working
> >
> > Last time I looked at XF86DGA (years ago), it seemed to have the right
> > hooks in place. Just a matter of server implementation.
On Mon, 9 Apr 2001, Jim Studt wrote:
> G*rard Roudier insightfully opined..
> > Looks like an IRQ problem to me.
> > I mean the kernel wants to change IRQ routing and just do the wrong job.
>
> Give the man a prize!
>
> After failing to work with 2.4.0, 2.4.1, 2.4.3, and 2.4.3-ac3 I
> enabl
> > This is an X issue. I was talking with Jim Gettys about what is needed to
> > get the relevant existing X extensions for this working
>
> Last time I looked at XF86DGA (years ago), it seemed to have the right
> hooks in place. Just a matter of server implementation. My
> recollection is dus
The information is in the file ...
If you want make some question, I hope respond as soon as I can do it.
Xevi Serrats
[EMAIL PROTECTED]
REPORTING-BUGS
[1.] One line summary of the problrm:
When I boot linux (usinb lilo) appears an error message : kernel bug at page_alloc 191
[2.] Full des
On Tue, 10 Apr 2001, Manuel A. McLure wrote:
> This may be the difference - I always set "Plug-n-Play OS: No" on all my
> machines. Linux works fine and it doesn't seem to hurt Windows 98 any.
Correct, it's perfectly fine to do that on all machines (not just Via).
Users should also set "PNP OS: N
Petru Paler writes:
> On Tue, Apr 10, 2001 at 06:41:28AM -0400, Jakub Jelinek wrote:
> > some architectures don't care at all, because verify_area is a noop
> > (sparc64).
>
> Why (and how) is this?
On sparc64, the user lives in an entirely different address space.
The user cannot even gen
Here's a patch that fixes RW semaphores on the i386 architecture. It is very
simple in the way it works.
The lock counter is dealt with as two semi-independent words: the LSW is the
number of active (granted) locks, and the MSW, if negated, is the number of
active writers (0 or 1) plus the number
Axel Thimm said...
> On Tue, Apr 10, 2001 at 09:51:18AM -0700, Manuel A. McLure wrote:
> > I have the same motherboard with the same lspci output
> (i.e. I get the "pin
> > ?" part), but I don't see any problems running 2.4.3 or
> 2.4.3-ac[23]. I am
> > only using a trackball on my USB port - wh
On Wed, Apr 11, 2001 at 01:42:55AM +0800, gis88530 wrote:
> Hello,
>
> I can use "ps" to see memory usage of daemons and user programs.
> I can't find any memory information of kernel with "top" and "ps".
>
> Do you know how to take memory usage information of kernel ?
Try cat /proc/slabinfo
On Tue, Apr 10, 2001 at 04:43:36AM -0700, David Schleef wrote:
> However, on machines without a monotonically increasing counter,
> i.e., the TSC, you have to use 8254 timer 0 as both the timebase
> and the interval counter -- you end up slowly losing time because
> of the race condition between r
Hello!
> In brief: a stale state of the tcp send queue was observed for 2.2.17
> while send-q counter and connection window sizes are not zero:
I think I pinned down this. The patch is appended.
> diagnostic, I'll try to get it. In any case, I plan to run something through
> this connecti
1 - 100 of 219 matches
Mail list logo