);
?
hard_start_xmit is called under dev-xmit_lock, waiting until the lock is
free would guarantee that all running instances of hard_start_xmit have
completed.
Jeff: Is that still correct?
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On Sat, 9 Apr 2005, Francois Romieu wrote:
Manfred Spraul [EMAIL PROTECTED] :
[Jeff added to cc list - it's a network driver question]
[...]
I haven't read the whole driver, but what about
spin_unlock_wait(dev-xmit_lock);
?
The race here is a dev-close() against dev
Steven Rostedt wrote:
On Sun, 2005-04-03 at 09:10 +0200, Manfred Spraul wrote:
Yes - sem or spin locks are quicker as long as no cache line transfers
are necessary. If the semaphore is accessed by multiple cpus, then
kmalloc would be faster: slab tries hard to avoid taking global locks.
I'm
Steven Rostedt wrote:
On Sun, 2005-04-03 at 09:10 +0200, Manfred Spraul wrote:
Yes - sem or spin locks are quicker as long as no cache line transfers
are necessary. If the semaphore is accessed by multiple cpus, then
kmalloc would be faster: slab tries hard to avoid taking global locks.
I'm
. If the semaphore is accessed by multiple cpus, then
kmalloc would be faster: slab tries hard to avoid taking global locks.
I'm not speaking about contention, just the cache line ping pong for
acquiring a free semaphore.
--
Manfred
-
To unsubscribe from this list: send the line "unsubs
pport").
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
your own memory manager?
kmalloc(1024, GFP_KERNEL) is something like 17 instructions on i386
uniprocessor.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
your own memory manager?
kmalloc(1024, GFP_KERNEL) is something like 17 instructions on i386
uniprocessor.
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
).
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
. If the semaphore is accessed by multiple cpus, then
kmalloc would be faster: slab tries hard to avoid taking global locks.
I'm not speaking about contention, just the cache line ping pong for
acquiring a free semaphore.
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe
oprofile for one recent
kernel?
I have convinced Mark Wong from OSDL to generate a few for postgres DBT-2, but
postgres is limited by it's user space buffer manager, thus it wasn't that
useful:
http://khack.osdl.org/stp/299167/oprofile/
--
Manfred
-
To unsubscribe from this list: send
oprofile for one recent
kernel?
I have convinced Mark Wong from OSDL to generate a few for postgres DBT-2, but
postgres is limited by it's user space buffer manager, thus it wasn't that
useful:
http://khack.osdl.org/stp/299167/oprofile/
--
Manfred
-
To unsubscribe from this list: send
() and update kmalloc_node.
The patch was manually edited, I hope it applies to a recent tree ;-)
What do you think?
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 6
// SUBLEVEL = 11
// EXTRAVERSION = -mm2
--- 2.6/include/linux/slab.h2005-03-12 01:05:50.0 +0100
() and update kmalloc_node.
The patch was manually edited, I hope it applies to a recent tree ;-)
What do you think?
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 6
// SUBLEVEL = 11
// EXTRAVERSION = -mm2
--- 2.6/include/linux/slab.h2005-03-12 01:05:50.0 +0100
and
kmem_cache_alloc call, virtually everyone passes -1. Does it increase
the .text size?
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please re
and
kmem_cache_alloc call, virtually everyone passes -1. Does it increase
the .text size?
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
be derived from
Linux, thus a non-GPL license is ok.
OTHO a driver that was written for Linux is in my opinion derived from
Linux and thus the GPL is mandatory.
Just speaking for myself,
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
from
Linux, thus a non-GPL license is ok.
OTHO a driver that was written for Linux is in my opinion derived from
Linux and thus the GPL is mandatory.
Just speaking for myself,
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Thomas Gleixner wrote:
On Sun, 2005-03-20 at 07:36 +0100, Manfred Spraul wrote:
cpu 1:
acquire random networking spin_lock_bh()
cpu 2:
read_lock(_lock) from process context
interrupt. softirq. within softirq: try to acquire the networking lock.
* spins.
cpu 1:
hardware interrupt
within hw
Thomas Gleixner wrote:
On Sun, 2005-03-20 at 07:36 +0100, Manfred Spraul wrote:
cpu 1:
acquire random networking spin_lock_bh()
cpu 2:
read_lock(tasklist_lock) from process context
interrupt. softirq. within softirq: try to acquire the networking lock.
* spins.
cpu 1:
hardware interrupt
within
delivery. tries to acquire tasklist_lock.
--> deadlock.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http:
: signal delivery. tries to acquire tasklist_lock.
-- deadlock.
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
Ingo Molnar wrote:
read_lock();
...
read_lock();
are still legal. (it's also done quite often.)
How do you handle the write_lock_irq()/read_lock locks?
E.g. the tasklist_lock or the fasync_lock.
--
Manfred
-
To unsubscribe from this list: send the line
Ingo Molnar wrote:
read_lock(rwlock);
...
read_lock(rwlock);
are still legal. (it's also done quite often.)
How do you handle the write_lock_irq()/read_lock locks?
E.g. the tasklist_lock or the fasync_lock.
--
Manfred
-
To unsubscribe from this list: send
that assumption.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
lobal spinlock is in
http://www.colorfullife.com/~manfred/Linux-kernel/slab/patch-slab-numa-2.5.66
per-node spinlocks would require a restructuring of free_block.
- Add per-node array for each cpu for wrong node allocations. Allows
very fast batch return: each array contains memory just from one n
://www.colorfullife.com/~manfred/Linux-kernel/slab/patch-slab-numa-2.5.66
per-node spinlocks would require a restructuring of free_block.
- Add per-node array for each cpu for wrong node allocations. Allows
very fast batch return: each array contains memory just from one node,
usefull if per-node spinlocks
that assumption.
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
This is already implemented for __put_user_size(), somehow I overlooked
__put_user_{1,2,4,8,X}.
What do you think?
Patch against 2.6.11-mm2, test booted with bochs.
--
Manfred
--- 2.6/include/asm-i386/uaccess.h 2005-03-12 01:05:49.0 +0100
+++ build-2.6/include/asm-i386/uaccess.h
.
This is already implemented for __put_user_size(), somehow I overlooked
__put_user_{1,2,4,8,X}.
What do you think?
Patch against 2.6.11-mm2, test booted with bochs.
--
Manfred
--- 2.6/include/asm-i386/uaccess.h 2005-03-12 01:05:49.0 +0100
+++ build-2.6/include/asm-i386/uaccess.h
uot;unsigned short".
Good point. This seems to work.
Two updates are needed for the leak detection in recent kernels:
- set kmem_bufctl_t back to unsigned long
- relax the check in check_slabuse, something like the attached patch.
Note that the patch is not tested.
--
Manfred
--- 2
. This seems to work.
Two updates are needed for the leak detection in recent kernels:
- set kmem_bufctl_t back to unsigned long
- relax the check in check_slabuse, something like the attached patch.
Note that the patch is not tested.
--
Manfred
--- 2.6/mm/slab.c 2005-03-02 20:44
if this is a bug. But if it's one, then far more than just
sysv sem must be updated.
What about other unices? I've attached a test app that tests pipes.
Could someone try it?
--
Manfred
/*
* Copyright (C) 1999, 2001,2005 by Manfred Spraul.
*
* Redistribution of this file is permitted under the terms
if this is a bug. But if it's one, then far more than just
sysv sem must be updated.
What about other unices? I've attached a test app that tests pipes.
Could someone try it?
--
Manfred
/*
* Copyright (C) 1999, 2001,2005 by Manfred Spraul.
*
* Redistribution of this file is permitted under the terms
other.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
Signed-off-by: Manfred Spraul <[EMAIL PROTECTED]>
Index: linux-2.6/mm/slab.c
===
RCS file: /var/cvs/linux-2.6/mm/slab.c,v
retrieving revision 1.29
diff -u -p -
other.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
Signed-off-by: Manfred Spraul [EMAIL PROTECTED]
Index: linux-2.6/mm/slab.c
===
RCS file: /var/cvs/linux-2.6/mm/slab.c,v
retrieving revision 1.29
diff -u -p -r1.29 slab.c
und these two lines
time_init();
softirq_init();
in init/main.c. Thanks, Andrew, for this tip.
Bye,
Manfred
--
/"\| PGP-Key available at Public Key Servers
\ / ASCII ribbon campaign | or "http://www.mahowi.de/pgp/mahowi.asc;
X against
();
in init/main.c. Thanks, Andrew, for this tip.
Bye,
Manfred
--
/\| PGP-Key available at Public Key Servers
\ / ASCII ribbon campaign | or http://www.mahowi.de/pgp/mahowi.asc;
X against HTML mail | RSA: 0xC05BC0F5 * DSS: 0x4613B5CA
/ \ and postings
: lea0xc025bf80(,%eax,4),%eax
> >
>
> Well I guess it tells us it's not random uninitialised
> crud.
>
> Just for interest: what happens if you swap around the lines
>
> time_init();
> softirq_init();
>
> in init/main.c?
>
That works, k
Andrea Arcangeli schrieb am Donnerstag, den 05. Juli 2001:
> On Wed, Jul 04, 2001 at 11:28:17PM +0200, Manfred H. Winter wrote:
> > Hi!
> >
> > I tried to install kernel 2.4.6 with same configuration as 2.4.5, but
> > booting failed with:
> >
> > kernel
ed.
As others report the same error, it seems to be a conflict with Cyrix
processors.
Bye,
Manfred
--
/"\| PGP-Key available at Public Key Servers
\ / ASCII ribbon campaign | or "http://www.mahowi.de/pgp/mahowi.asc;
X against HTML mail | RSA: 0xC05B
33 : jne0xc0118043
0xc0118035 : mov0xc024af20(,%eax,4),%eax
0xc011803c : test %eax,%eax
0xc011803e : je 0xc0118042
0xc0118040 : call *%eax
0xc0118042 : ret
0xc0118043 : lea(%eax,%eax,4),%eax
0xc0118046 : lea0xc025bf80(,%eax,4),%eax
HT
Hi!
On Wed, 04 Jul 2001, Manfred H. Winter wrote:
>
> I tried to install kernel 2.4.6 with same configuration as 2.4.5, but
> booting failed with:
>
> kernel BUG at softirq.c:206!
> invalid operand:
> CPU:0
> EIP:0010:[]
> EFLAGS: 00010082
> eax
Hi!
On Wed, 04 Jul 2001, Manfred H. Winter wrote:
I tried to install kernel 2.4.6 with same configuration as 2.4.5, but
booting failed with:
kernel BUG at softirq.c:206!
invalid operand:
CPU:0
EIP:0010:[c0117f2e]
EFLAGS: 00010082
eax: 001d ebx: c025bf80 ecx
: test %eax,%eax
0xc011803e bh_action+22: je 0xc0118042 bh_action+26
0xc0118040 bh_action+24: call *%eax
0xc0118042 bh_action+26: ret
0xc0118043 bh_action+27: lea(%eax,%eax,4),%eax
0xc0118046 bh_action+30: lea0xc025bf80(,%eax,4),%eax
HTH,
Manfred
to be a conflict with Cyrix
processors.
Bye,
Manfred
--
/\| PGP-Key available at Public Key Servers
\ / ASCII ribbon campaign | or http://www.mahowi.de/pgp/mahowi.asc;
X against HTML mail | RSA: 0xC05BC0F5 * DSS: 0x4613B5CA
/ \ and postings | AIM: mahowi42 * ICQ
Andrea Arcangeli schrieb am Donnerstag, den 05. Juli 2001:
On Wed, Jul 04, 2001 at 11:28:17PM +0200, Manfred H. Winter wrote:
Hi!
I tried to install kernel 2.4.6 with same configuration as 2.4.5, but
booting failed with:
kernel BUG at softirq.c:206!
do you have any problem
without problems.
Thanks,
Manfred
--
/\| PGP-Key available at Public Key Servers
\ / ASCII ribbon campaign | or http://www.mahowi.de/pgp/mahowi.asc;
X against HTML mail | RSA: 0xC05BC0F5 * DSS: 0x4613B5CA
/ \ and postings | AIM: mahowi42 * ICQ
n, tell me.
Bye,
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
=m
CONFIG_SOUND_OSS=m
CONFIG_SOUND_TRACEINIT=y
CONFIG_SOUND_DMAP=y
CONFIG_SOUND_SB=m
CONFIG_SOUND_AWE32_SYNTH=m
CONFIG_SOUND_YM3812=m
CONFIG_MAGIC_SYSRQ=y
+++
If you need more information, tell me.
Bye,
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
But even if an io apic is present, Linux can only use it if a MP table
is present. Afaik ACPI tables are not yet supported on i386, but ia64
already supports detecting the IO APIC's based on ACPI tables.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe li
is present, Linux can only use it if a MP table
is present. Afaik ACPI tables are not yet supported on i386, but ia64
already supports detecting the IO APIC's based on ACPI tables.
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Mike Kravetz wrote:
>
> On Wed, Jun 27, 2001 at 11:22:19PM +0200, Manfred Spraul wrote:
> > > Why would you want to prevent
> > > reschedule_idle()?
> > >
> > If one process runs, wakes up another process and _knows_ that it's
> > going to sleep
mediately after the wake_up it doesn't need the
reschedule_idle: the current cpu will be idle soon, the scheduler
doesn't need to find another cpu for the woken up thread.
I think the pipe code is the only user of _sync right now - pipes cause
an incredible amount of task switches.
--
Ma
it doesn't need the
reschedule_idle: the current cpu will be idle soon, the scheduler
doesn't need to find another cpu for the woken up thread.
I think the pipe code is the only user of _sync right now - pipes cause
an incredible amount of task switches.
--
Manfred
-
To unsubscribe from this list
Mike Kravetz wrote:
On Wed, Jun 27, 2001 at 11:22:19PM +0200, Manfred Spraul wrote:
Why would you want to prevent
reschedule_idle()?
If one process runs, wakes up another process and _knows_ that it's
going to sleep immediately after the wake_up it doesn't need
se? The default compiler from 7.0 is known to
produce buggy kernels, and Linus didn't include the kgcc detection.
Could you check that kgcc is used for compiling?
Just replace '$(CROSS_COMPILE)gcc' in /usr/src/linux/Makefile with
'$(CROSS_COMPILE)kgcc'
Or upgrade to the gcc compiler from 7.1?
--
compiler from 7.0 is known to
produce buggy kernels, and Linus didn't include the kgcc detection.
Could you check that kgcc is used for compiling?
Just replace '$(CROSS_COMPILE)gcc' in /usr/src/linux/Makefile with
'$(CROSS_COMPILE)kgcc'
Or upgrade to the gcc compiler from 7.1?
--
Manfred
at file?
I usually use 'gcc -E' to find such problems.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
?
I usually use 'gcc -E' to find such problems.
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
/xircom_tulip_cb
I've attached an untested patch.
It's possible that the nic performs another byte swap if configured for
big endian support, but I've never seen a nic that performs byte swaps
on register writes, only on memory reads.
Please cc me, I'm not subscribed to the mailing lists.
--
Manfred
/xircom_tulip_cb
I've attached an untested patch.
It's possible that the nic performs another byte swap if configured for
big endian support, but I've never seen a nic that performs byte swaps
on register writes, only on memory reads.
Please cc me, I'm not subscribed to the mailing lists.
--
Manfred
]
--
Manfred
--- 2.4/drivers/net/natsemi.c Sat Jun 2 14:19:44 2001
+++ build-2.4/drivers/net/natsemi.c Sat Jun 2 20:21:15 2001
@@ -51,10 +51,21 @@
* One-liner removal of a duplicate declaration of
netdev_error(). (uzi)
+ Version 1.0.7
]
--
Manfred
--- 2.4/drivers/net/natsemi.c Sat Jun 2 14:19:44 2001
+++ build-2.4/drivers/net/natsemi.c Sat Jun 2 20:21:15 2001
@@ -51,10 +51,21 @@
* One-liner removal of a duplicate declaration of
netdev_error(). (uzi)
+ Version 1.0.7
he
ac97 driver could be moved to the pci-quirks and applied to all devices
in the southbridge.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
in the southbridge.
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
It'll kill the USB controller.
#setpci -s 00:07.2 INTERRUPT_LINE=15
#lspci -vx -s 00:07.2
<<< 0x3C should be 15
#setpci -s 00:07.2 INTERRUPT_LINE=19
#lspci -vx -s 00:07.2
<<< 0x3C is now either 19 or 3
--
Manfred
-
To unsubscribe from this list: send the line "unsubsc
07.2
offset 0x3C must be set to 3 [19 & 15]
There was some discussion about the same problem with the sound part of
the southbridge.
What are the current values of these registers?
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
must be set to 3 [19 15]
There was some discussion about the same problem with the sound part of
the southbridge.
What are the current values of these registers?
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
00:07.2 INTERRUPT_LINE=15
#lspci -vx -s 00:07.2
0x3C should be 15
#setpci -s 00:07.2 INTERRUPT_LINE=19
#lspci -vx -s 00:07.2
0x3C is now either 19 or 3
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
problems, but it's
required for proper switching between nway and pre-nway link partners,
at least with my PHY.
Tested with -ac11, patch also applies against 2.4.4 and 2.4.4-ac17.
--
Manfred
--- 2.4/drivers/net/winbond-840.c Fri May 25 22:36:10 2001
+++ build-2.4/drivers/net/winbond
problems, but it's
required for proper switching between nway and pre-nway link partners,
at least with my PHY.
Tested with -ac11, patch also applies against 2.4.4 and 2.4.4-ac17.
--
Manfred
--- 2.4/drivers/net/winbond-840.c Fri May 25 22:36:10 2001
+++ build-2.4/drivers/net/winbond
Minor update to the winbond-840 driver:
* improved SMP locking, one or 2 races fixed.
* memory leak in _close fixed.
* partial implementation of _suspend and _resume. The chip is disabled
and restarted, but not yet put into sleep mode. [lack of hardware to
test it]
--
Manfred
--- 2.4
Minor update to the winbond-840 driver:
* improved SMP locking, one or 2 races fixed.
* memory leak in _close fixed.
* partial implementation of _suspend and _resume. The chip is disabled
and restarted, but not yet put into sleep mode. [lack of hardware to
test it]
--
Manfred
--- 2.4
is the correct version of patch-copy_user_user.
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 4
// SUBLEVEL = 4
// EXTRAVERSION = -ac8
--- 2.4/kernel/ptrace.c Sat Mar 31 21:49:29 2001
+++ build-2.4/kernel/ptrace.c Thu May 17 19:43:09 2001
@@ -19,13 +19,14 @@
.
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 4
// SUBLEVEL = 4
// EXTRAVERSION = -ac8
--- 2.4/kernel/ptrace.c Sat Mar 31 21:49:29 2001
+++ build-2.4/kernel/ptrace.c Thu May 17 19:43:09 2001
@@ -19,13 +19,14 @@
/*
* Access another process' address space, one page
Jeff Garzik wrote:
>
> Manfred Spraul wrote:
> > @@ -437,9 +439,9 @@
> > if (option > 0) {
> > if (option & 0x200)
> > np->full_duplex = 1;
> > - np->default_port = opti
Minor update for the winbond-840 driver:
* fix for memory leak in netdev_close()
* SMP locking fixes (csr6, mdio)
I still try to figure out why freebsd doesn't need the fifo bug
workaround.
--
Manfred
--- 2.4/drivers/net/winbond-840.c Thu May 10 22:13:49 2001
+++ build-2.4
t;<<
acpi_gbl_FADT is NULL.
If you need additional details just ask.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
"J . A . Magallon" wrote:
>
> On 05.11 Manfred Spraul wrote:
> >
> > Please test it.
> > The kernel space part should be ok, but I know that the
> > patch can cause deadlocks with buggy user space apps.
> >
>
> I tried your patch on 2.4.4-a
J . A . Magallon wrote:
On 05.11 Manfred Spraul wrote:
Please test it.
The kernel space part should be ok, but I know that the
patch can cause deadlocks with buggy user space apps.
I tried your patch on 2.4.4-ac8, and something strange happens.
Untarring linux-2.4.4 takes
need additional details just ask.
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Minor update for the winbond-840 driver:
* fix for memory leak in netdev_close()
* SMP locking fixes (csr6, mdio)
I still try to figure out why freebsd doesn't need the fifo bug
workaround.
--
Manfred
--- 2.4/drivers/net/winbond-840.c Thu May 10 22:13:49 2001
+++ build-2.4
Jeff Garzik wrote:
Manfred Spraul wrote:
@@ -437,9 +439,9 @@
if (option 0) {
if (option 0x200)
np-full_duplex = 1;
- np-default_port = option 15;
- if (np-default_port)
- np
, but I know that the
patch can cause deadlocks with buggy user space apps.
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 4
// SUBLEVEL = 4
// EXTRAVERSION =
--- 2.4/fs/pipe.c Mon May 7 20:43:38 2001
+++ build-2.4/fs/pipe.c Fri May 11 19:17:45 2001
, but I know that the
patch can cause deadlocks with buggy user space apps.
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 4
// SUBLEVEL = 4
// EXTRAVERSION =
--- 2.4/fs/pipe.c Mon May 7 20:43:38 2001
+++ build-2.4/fs/pipe.c Fri May 11 19:17:45 2001
One addtional wish list entry:
'ss' and especially 'ssb' could print the new value of the overwritten
register/memory address in each line, perhaps both the old and new
value.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
One addtional wish list entry:
'ss' and especially 'ssb' could print the new value of the overwritten
register/memory address in each line, perhaps both the old and new
value.
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
ing the ptrace interface (access_process_vm()) is the better
solution.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
nested loops and
gotos. It's possible to create wakeup storms. I rewrote them as well ;-)
But the new code still contains one deadlock :-(
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
to create wakeup storms. I rewrote them as well ;-)
But the new code still contains one deadlock :-(
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
()) is the better
solution.
--
Manfred
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I'm now running with the patch for several hours, no problems.
bw_pipe transfer rate has nearly doubled and the number of context
switches for one bw_pipe run is down from 71500 to 5500.
Please test it.
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 4
I'm now running with the patch for several hours, no problems.
bw_pipe transfer rate has nearly doubled and the number of context
switches for one bw_pipe run is down from 71500 to 5500.
Please test it.
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 4
>
> What information should I gather when the card is wedged to aid in
> debugging? Is 'lspci -xxx' enough? Any suggestions would be welcome.
>
tulip-diag from www.scyld.com.
Do you know if transmit or receive is slow? tcpdump on both ends of the
ping might help.
-
To unsubscribe from this
Manfred Spraul wrote:
>
> + else
> + fl->fl_type & ~F_INPROGRESS;
^^
> + unlock_kernel();
> + return ret;
> }
The last patch was incorrect. Corrected version attached.
--
Manfred
// $Header$
// Kernel
Linus Torvalds wrote:
>
> On Sat, 5 May 2001, Manfred Spraul wrote:
> >
> > * missing/wrong lock_kernel calls in fs/fcntl.c: getlk/setlk run without
> > the big kernel lock. The ..64 function acquire the lock.
>
> This is wrong. The big lock (if it is needed, but I
calls in fs/fcntl.c: getlk/setlk run without
the big kernel lock. The ..64 function acquire the lock.
--
Manfred
--- 2.4/mm/slab.c Sat Mar 3 17:58:05 2001
+++ build-2.4/mm/slab.c Sat Mar 3 19:57:16 2001
@@ -448,7 +448,7 @@
/* Inc off-slab bufctl limit until the ceiling
(), but with
copy_to_user() instead of memmove().
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 4
// SUBLEVEL = 4
// EXTRAVERSION =
--- 2.4/fs/pipe.c Thu Feb 22 22:29:46 2001
+++ build-2.4/fs/pipe.c Fri May 4 21:35:37 2001
@@ -2,6 +2,9 @@
* linux/fs/pipe.c
wide margins from "dangerous" areas? (untested:
mem=exactmap mem=620k@0 mem=M@1M)
Then boot with prefetch enabled.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
901 - 1000 of 1478 matches
Mail list logo
