Hi!
Can you generate small testcase that demonstrates the problem?
> Then what would be the correct way to handle resume process. The other
> way of course is to make all the applications check the errno in case of
> failure. But that seems more more problematic then system call checking.
> What
Rafael wrote:
On Monday, 23 July 2007 20:38, Agarwal, Lomesh wrote:
> The other problem I am facing that read from socket returns with ENODATA
> when resuming. any ideas?
It's of similar kind: the system call checks signal_pending(current) and exit
with an error if that's true.
Well, I'm afraid
Rafael J. Wysocki wrote:
Well, look at the code in fs/select.c:do_poll() . If signal_pending(current)
is true, the main loop breaks and count is returned to do_sys_poll(). If
zero is returned and signal_pending(current) is still true, do_sys_poll()
returns -EINTR.
Thanks - I looked at sys_
Hi,
Attached is a backport of the latest forcedeth version to 2.4. It
includes lots of changes, among them:
- a critical bugfix for nv_open(): ifdown/ifup cycles resulted in an
incomplete initialization that causes hangs after a few MB network traffic.
- jumbo frame support
- far better ethtoo
Pekka J Enberg wrote:
FWIW I have been running on this for few days now without any noticeable
regressions. We get a solved FIXME in return but like I said I am a happy
to remove the redundant abstraction if this is too risky.
I would prefer just to remove the abstraction, together with a
Proposed by and based on a patch from Eric Dumazet <[EMAIL PROTECTED]>:
This patch removes unnecessary critical section in ksize() function, as
cli/sti are rather expensive on modern CPUS.
It additionally adds a docbook entry for ksize() and further simplifies
the code.
Signed-Off-By: M
Hi Avuton,
I have not been able to duplicate this without going into standby,
thus this bug may have existed before 2.6.12, as I just started using
ACPI standby.
Could you try the attached patch? Lots of error are often caused by half
duplex/full duplex mismatches, and such a bug was just
Teemu wrote:
Opening a FIFO for WR_ONLY should release a previously blocked RD_ONLY
open. I suspect this is not guaranteed on a heavily loaded Linux box.
Do you have a test case?
IIRC we had that bug, and it was fixed by adding PIPE_WCOUNTER:
PIPE_WRITERS counts the number of writers. This o
Alexander Nyberg wrote:
My fault, I introduced a debugging patch (i think i cc'ed you on it)
which used __builtin_return_address([12]) to save traces of who the
caller of an object is.
Ups. I still have your original mail in my inbox.
The correct way is check the whole stack and store all po
Christoph Lameter wrote:
I kept getting boot failures in the slab allocator. The failure goes
away if one is setting CONFIG_FRAME_POINTER. Seems that
CONFIG_DEBUG_SLAB implies the use of __buildin_return_address() which
needs the framepointer.
Very odd. __builtin_return_address(1) needs f
Dipankar Sarma wrote:
Hugh, could you please try this with the experimental patch below ?
Manfred, is it safe to decrement nr_files in file_free()
instead of the destructor ? I can't see any problem.
The ctor/dtor are only called when new objects are created, not on every
kmem_cache_alloc/k
Daniel Drake wrote:
So, you want this instead:
#define DEV_HAS_LARGEDESC0x0004
Autsch.
Yes, you are right. Sorry for that, I should have reread the patch once
more. I've fixed it on my website.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
Daniel Drake wrote:
Hi,
Manfred Spraul wrote:
Attached is a patch that modifies the tx interrupt handling of the
nForce nic. It's part of the attempts to figure out what causes the
nic hangs (see bug 4552).
The change is experimental: It affects all nForce versions. I've
teste
[If you receive the mail twice - sorry. I forgot to attach the actual patch]
Hi,
Attached is a patch that modifies the tx interrupt handling of the
nForce nic. It's part of the attempts to figure out what causes the nic
hangs (see bug 4552).
The change is experimental: It affects all nForce ver
Hi,
Attached is a patch that modifies the tx interrupt handling of the
nForce nic. It's part of the attempts to figure out what causes the nic
hangs (see bug 4552).
The change is experimental: It affects all nForce versions. I've tested
it on my nForce 250-Gb.
Please test it. And especially:
Alexander Nyberg wrote:
Yeah I knew there was one, but I thought that was a standalone patch
(the one turning all bufctl to unsigned long, turning off irqs and
printing all slabs_full to console), my intention with this was a
proper /proc entry, something that could be a simple config option.
Andrew Morton wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
#define GFP_LEVEL_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_FS| \
- __GFP_COLD|__GFP_NOWARN|__GFP_REPEAT| \
- __GFP_NOFAIL|__GFP_NORETRY|__GFP_NO_GROW|__GFP_COMP)
+ __GFP_COLD|__GFP_NOWARN|__GFP_REPEAT|__GFP_NOFAIL| \
+ __GFP_
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);
&g
[Jeff added to cc list - it's a network driver question]
On Thu, 7 Apr 2005, Paul E. McKenney wrote:
> > >
> > > /* Give a racing hard_start_xmit a few cycles to complete. */
> > > - synchronize_kernel();
I haven't read the whole driver, but what about
spin_unlock_wait(&dev->xmit_lock);
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&#
Steven Rostedt wrote:
Have you benchmarked your own memory manager?
kmalloc(1024, GFP_KERNEL) is something like 17 instructions on i386
uniprocessor.
Where did you get that? I'm looking at the assembly of it right now and
it's much larger than 17 instructions. Not to mention that it calls the
Gigabyte's K8NS Ultra-939 mobo has a 100/10 LAN PHY chip, ICS1883, which
isn't detected by the 2.6.12-rc1 kernel (and likely not previous kernels).
The board is a nVidia nForce board, correct? Then please try the
forcedeth network driver ("Reverse Engineered nForce Ethernet support").
--
M
Steven Rostedt wrote:
I admit you really need to know what you're doing to use this method. If
I believe that a kmalloc would be too expensive, then I use the locking
of static variables. But each situation is different and I try to use
the best method for the occasion.
Have you benchmarked your
On Mon, 28 Mar 2005, Chen, Kenneth W wrote:
With that said, here goes our first data point along with some historical data
we have collected so far.
2.6.11 -13%
2.6.9 - 6%
2.6.8 -23%
2.6.2 - 1%
baseline(rhel3)
Is it possible to generate an instruction level op
Christoph Lameter wrote:
The -1 is optimized away for the non NUMA case. In the NUMA case its an
additional parameter that is passed to kmem_cache_alloc. So its one
additional register load that allows us to not have an additional function
for the case non node specific allocations.
Correct, I w
Christoph Lameter wrote:
The patch makes the following function calls available to allocate memory on
a specific node without changing the basic operation of the slab
allocator:
kmem_cache_alloc_node(kmem_cache_t *cachep, unsigned int flags, int node);
kmalloc_node(size_t size, unsigned int flags,
Lee wrote:
What ever gave you the impression that it was legal to create a
"Proprietry" kernel driver for Linux in the first place.
The fact that Nvidia and ATI get away with it?
The didn't write a Linux driver. They have multi-platform drivers that
work among other OS on Linux, too.
E.g. the N
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
wi
Ingo Molnar wrote:
which precise locking situation do you mean?
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 hw interrupt: si
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 the
Martin J. Bligh wrote:
That'd be my inclination but OTOH, we do that for pagecache OK.
The page cache doesn't have a global hash table.
Dunno,
I'm torn. Depends if there's locality on the file access or not, I guess.
Is there any *harm* in doing it node local perhaps creating a node
mem
Hi Christoph,
Do you have profile data from your modification? Which percentage of the
allocations is node-local, which percentage is from foreign nodes?
Preferably per-cache. It shouldn't be difficult to add statistics
counters to your patch.
And: Can you estaimate which percentage is really ac
Hi,
Linus noticed that put_user doesn't to the manual page table lookup that
is required for cpus without a working WP flag. The solution is simple:
if CONFIG_X86_WP_WORKS_OK is not set, then the put_user macros must call
__copy_to_user_ll(). That function contains the required checks.
This is a
Andrew Morton wrote:
OGAWA Hirofumi <[EMAIL PROTECTED]> wrote:
Andrew Morton <[EMAIL PROTECTED]> writes:
> + slab_bufctl(slabp)[objnr] = (unsigned long)caller;
Umm... this patch looks strange..
slab_bufctl() returns "kmem_bufctl_t *", but kmem_bufctl_t is
"unsigned short".
Good poi
ot sure 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 fil
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 -
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> This shows that Linux mapped the APIC (part of the processor).
> It says nothing about mapping any IO APICs (unless you deleted
> that part :).
>
Correct. Linux always enables the APIC, but it needs some bios tables
f
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
> I'm having trouble understanding the difference between these.
> Synchronous apparently causes try_to_wake_up() to NOT call
> reschedule_idle() but I'm uncertain what reschedule_idle() is doing. I
> assume it just looks for an idle CPU and makes that CPU reschedule.
>
> What is the purpose of w
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
>
> package RH7.0 has...2.4.2 and on needs...
> util-linux 2.10m 2.10o
> modutils2.3.21 2.4.2
> e2fsprogs 1.181.19
Which compiler do you use? The default com
> I encounter this compilation error:
> /usr/x.c:2112: struct has no member named
> "event_Rsmp_7b16c344"
I assume you have a variable called 'event', and that name got replaced
by a versioned symbol.
Yes, 'event' is a global variable in the kernel ;-)
Do you include in that file?
I usually us
I noticed that the multicast hash calculations assumed little endian
byte ordering in the winbond-840 driver, and it seems that several other
drivers are also affected:
8139too, epic100, fealnx, pci-skeleton, sis900, starfile, sundance,
via-rhine, yellowfin
perhaps drivers/net/pcmcia/xircom_tulip
: (Manfred Spraul)
+ * pci dma
+ * SMP locking update
+ * full reset added into tx_timeout
+ * correct multicast hash generation
+ [copied from a natsemi driver version
+from Myrio Corporation, Greg Smith
[EMAIL PROTECTED] wrote:
>
> :setpci -s 00:07.2 INTERRUPT_LINE=15
> :lspci -vx -s 00:07.2
> 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI])
> Subsystem: Unknown device 0925:1234
> Flags: bus master, medium devsel, latency 32, IRQ 19
> I
[EMAIL PROTECTED] wrote:
>
> 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI])
> Subsystem: Unknown device 0925:1234
> Flags: bus master, medium devsel, latency 32, IRQ 5
> I/O ports at a000 [size=32]
> Capabilities: [80] Power Ma
>
> I know that with MPS 1.4, the USB controller finds itself at an
> unshared interrupt 19. I can't reboot at the moment to check.
>
lspci -vxxx -s 00:07.0
the APIC sits in the southbridge.
the low 2 bits of offset 0x58 must be set [route USB IRQ to APIC], and
lspci -vx -s 00:07.2
offset 0
et/winbond-840.c Fri May 25 23:23:07 2001
@@ -32,12 +32,22 @@
synchronize tx_q_bytes
software reset in tx_timeout
Copyright (C) 2000 Manfred Spraul
+ * further cleanups
+ power management.
+ support for
/drivers/net/winbond-840.c Fri Apr 20 20:54:23 2001
+++ build-2.4/drivers/net/winbond-840.c Sat May 19 14:14:22 2001
@@ -32,10 +32,16 @@
synchronize tx_q_bytes
software reset in tx_timeout
Copyright (C) 2000 Manfred Spraul
+ * further
"David S. Miller" wrote:
>
> J . A . Magallon writes:
> > > What platform?
>
> > Any more info ?
>
> No, I thought it might be some cache flushing issue
> on a non-x86 machine.
>
I found the problem:
I sent out the old patch :-(
Attached is the correct version of patch-copy_user_user.
--
Jeff Garzik wrote:
>
> Manfred Spraul wrote:
> > @@ -437,9 +439,9 @@
> > if (option > 0) {
> > if (option & 0x200)
> > np->full_duplex = 1;
> > - np->default_port = opti
d-2.4/drivers/net/winbond-840.c Sat May 12 11:59:43 2001
@@ -32,10 +32,13 @@
synchronize tx_q_bytes
software reset in tx_timeout
Copyright (C) 2000 Manfred Spraul
+ * further cleanups
+ Copyright (c) 2001 Manfred S
linux-2.4.4-ac8
old bios, no complete acpi support.
from dmesg:
<<
ACPI: System description tables not found
Unable to handle kernel NULL pointer dereference at virtual address
00d4
EIP: acpi_get_timer+19
Call trace: bm_initialize
bm_osl_init
<
acpi_gbl_FADT is NULL.
"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
2001
@@ -2,6 +2,9 @@
* linux/fs/pipe.c
*
* Copyright (C) 1991, 1992, 1999 Linus Torvalds
+ *
+ * Major pipe_read() and pipe_write() cleanup: Single copy,
+ * fewer schedules. Copyright (C) 2001 Manfred Spraul
*/
#include
@@ -10,6 +13,8 @@
#include
#include
#include
+#in
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 to [
Alan Cox wrote:
>
> > The main problem is that map_user_kiobuf() locks pages into memory.
> > It's a bad idea for pipes. Either we must severely limit the maximum
>
> You only have to map them for the actual copy.
The current map_user_kiobuf() doesn't have an 'mm' parameter, I can only
use it f
From: "Ben LaHaise" <[EMAIL PROTECTED]>
>
> Any particular reason for not using davem's single copy kiobuf based
> code?
>
The main problem is that map_user_kiobuf() locks pages into memory.
It's a bad idea for pipes. Either we must severely limit the maximum
amount of data in the direct-copy buff
fewer schedules. Copyright (C) 2001 Manfred Spraul
*/
#include
@@ -10,6 +13,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -36,214 +41,396 @@
down(PIPE_SEM(*inode));
}
+#define ADDR_USER 1
+#define ADDR_KERNEL2
+struct pip
>
> 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 lis
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
Hi Linus,
I found a 3 small bugs:
* mm/slab.c: the offslab_limit calculation used 2 instead of
sizeof(kmem_bufctl_t) [==4]. Cosmetic bug, since offslab_limit is never
reached.
* expand_stack is not down_read() safe, but used in the page-in path.
Fix is trivial.
* missing/wrong lock_kernel call
/fs/pipe.c
*
* Copyright (C) 1991, 1992, 1999 Linus Torvalds
+ *
+ * Major pipe_read() and pipe_write() cleanup: Single copy,
+ * fewer schedules. Copyright (C) 2001 Manfred Spraul
*/
#include
@@ -10,6 +13,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -36,2
> ---
> > __asm__ __volatile__ (
> 158c157
> < "3: movw $0x1AEB, 1b\n"
> ---
> > "3: movw $0x1AEB, 1b\n" /* jmp on 26 bytes */
> 166c165
> < */
> ---
> >
> 170c169
> < "1: nop\n" /* prefetch 320(%0)\n" */
> ---
> > "1: prefetch 320(%0)\
> Q. How come the handler doesn't manage so called "bottom halves" or
>"soft IRQs"?
> A. There is no need for this. Soft IRQs can only appear at exit from
>hardware interrupt handlers. Indeed, we can't count on user app.
>being around and performing a system call when it comes to
expand_stack is only protected with down_read(&mmap_sem), and thus 2
thread could grow a vma at the same time.
I think the spin_lock(&page_table_lock) should be moved up before the
calculation of grow.
And map_user_kiobuf() doesn't honor VM_LOCKED for VM_GROWSDOWN segments.
Probably it should be
> So it seems that CONFIG_X86_USE_3DNOW is simply used to
> enable access to the routines in mmx.c (the athlon-optimized
> routines on CONFIG_K7 kernels), so then it appears that somehow
> this is corrupting memory / not behaving as it should (very
> technical, right?) :)...
Do you use any u
> Observe that the PCI DWORD (long) register at DWORD offset 15 consists
> of 4 byte-wide registers (from the PCI specification), Max_lat,
> Min_Gnt, Interrupt pin, and interrupt line. Nothing has to fit into
> 4 bits, you have 8 bits. I haven't looked at the Linux code, but if
> it provides only
> On Sun, Apr 29, 2001 at 01:58:52PM -0400, Alexander Viro wrote:
> > Hmm... I'd say that you also have a leak in kmalloc()'ed stuff -
> > something in 1K--2K range. From your logs it looks like the
> > thing never shrinks and grows prettu fast...
You could enable STATS in mm/slab.c, then the num
> Well looking a little more closely than I did last night it looks like
> access_process_vm (called from ptrace) can cause what amounts to a
> page fault at pretty arbitrary times.
It's also used for several /proc/ files.
I remember that I got crashes with concurrent exec+cat
/proc//cmdline unt
Are you sure the trace is decoded correctly?
> CPU:0
> EIP:0010:[sys_mremap+31/884]
> EFLAGS: 00010206
> Code: ac ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 d9
ac ae is
lodsb
scasb
Could you run
#objdump --disassemble-all --reloc linux/mm/mremap.o | less
and check that the
The first 2 problems aren't real problems (modify /etc/fstab, perhaps a
special ioctl could be added to raid and fsck stops the reconstruction)
- at most anoying, but clearly no bugs.
But the third one could be a bug:
>
> Third problem:
>
> I just tried boot 2.4.3 today. (after an unclean shut
I found the problem:
* init uses waitpid(-1,,), thus the __WALL flag is not set
* without __WALL, only processes with exit_signal == SIGCHLD are reaped
* it's impossible for user space processes to die with another
exit_signal, forget_original_parent changes the exit_signal back to
SIGCHLD ("We d
From: "Alan Cox" <[EMAIL PROTECTED]>
>
> That has an implicit race, a zombie can always appear as we are
execing init.
> I think init wants fixing
>
Rod, could you boot again with the unpatched kernel and send a sigchild
to init?
#kill -CHLD 1
If I understand the init code correctly the sigchild
Hi Alan,
Rod's init version (from RH 7.0) doesn't reap children that died before
it was started. Is that an init bug or should the kernel reap them
before the execve?
The attached patch reaps all zombies before the execve("/sbin/init").
I also found a bug in kernel/context.c: it doesn't acquire
>> Ah. Of course. All (or most) kernel initialisation is
>> done by PID 1. Search for "kernel_thread" in init/main.c
>>
>> So it seems that in your setup, process 1 is not reaping
>> children, which is why this hasn't been reported before.
>> Is there something unusual about your setup?
> I found
> I was expecting to receive some replies to my last desperate messages:
>
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg35446.html
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg36591.html
>
If you don't receive an answer, then it either indicates that the bug is
t
> I was expecting to receive some replies to my last desperate messages:
>
[EMAIL PROTECTED]/msg35446.html">http://www.mail-archive.com/
[EMAIL PROTECTED]/msg35446.html
[EMAIL PROTECTED]/msg36591.html">http://www.mail-archive.com/
[EMAIL PROTECTED]/msg36591.html
> Maybe someone can see which is
> it is very hard to imagine the scenario which can lead to this...
> I will try your suggestion..
Perhaps a problem with the csum assembler implementations? Which cpu
type do you optimize for, and which cpu is installed?
Btw, are you overclocking anything?
--
Manfred
-
To unsubscribe f
Andrea Arcangeli wrote:
>
> your cpu_is_idle will return 0 in the need_resched != 0 check even if the cpu
> is idle (because of the -1 trick for avoiding the SMP-IPI to notify the cpu).
>
Fixed.
> The issue you are addressing is quite londstanding and it is not only related
> to the loop with an
Afaics cpu bindings could allow a thread to run with an "unlimited"
timeslice.
cpu0: one thread running with 'nice==19'.
NICE_TO_TICKS==1.
cpu1: lots of other threads with 'nice==0' (NICE_TO_TICKS==6)
cpu0 will enter schedule() every tick.
can_schedule() returns '0' for all thre
I've attached a new patch:
* cpu_is_idle() moved to
* function uninlined due to header dependencies
* cpu_is_idle() doesn't call do_softirq directly, instead the caller
returns to schedule()
* cpu_is_idle() exported for modules.
* docu updated.
I'd prefer to inline cpu_is_idle(), but optimizing
From: <[EMAIL PROTECTED]>
To: "Manfred Spraul" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, April 08, 2001 7:58 PM
Subject: Re: softirq buggy [Re: Serial port latency]
> Hello!
>
> > But with a huge overhead. I'd prefer to call it dir
From: <[EMAIL PROTECTED]>
> Hello!
>
> > + if (softirq_active(smp_processor_id()) &
softirq_mask(smp_processor_id())) {
> > + do_softirq();
> > + return 0;
>
> BTW you may delete do_softirq()... schedule() will call this.
>
But with a huge overhead. I'd prefer to call it directly from within the
Just a guess:
Perhaps one bios is older and contains an older microcode patch?
Have you tried the microcode driver?
--
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.kern
Pavel Machek wrote:
>
> Ok. I was missing the fact it is checked on going userspace.
>
What about the attached patch?
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 4
// SUBLEVEL = 3
// EXTRAVERSION = -ac3
--- 2.4/include/linux/interrupt.h Thu Feb 22
The Intel documentation recommends that spinlocks should use
loop:
rep;nop;
cmp $0,lock_var
jne loop
ftp://download.intel.com/design/perftool/cbts/appnotes/sse2/w_spinlock.pdf
but the linux spinlock implementation uses
loop:
cmp $0, lock_var
rep; nop;
>
> everything seems to work fine. are these interrupt problems "bad" or merely
> indicators of a high load. can/should one get rid of them?
>
Could you try the 8139too driver?
It's a bug in the rtl8139 driver, and under really high load it can
cause crashes.
--
Manfred
-
To unsubscri
From: "Pavel Machek" <[EMAIL PROTECTED]>
>
> > Ok, there are 2 bugs that are (afaics) impossible to fix without
> > checking for pending softirq's in cpu_idle():
> >
> > a)
> > queue_task(my_task1, tq_immediate);
> > mark_bh();
> > schedule();
> > ;within schedule: do_softirq()
> > ;within my_task
> ps xl:
> F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
> 040 1000 1230 1 9 0 24320 4 down_w D ? 0:00
> /home/data/mozilla/obj/dist/bin/mozi
>
down_w
Perhaps down_write_failed()? 2.4.3 converted the mmap semaphore to a
rw-sem.
Did you compile sysrq into your kernel? Then
From: "Jeff Garzik" <[EMAIL PROTECTED]>
>
> /proc/pci data alone with every bug report is usually invaluable.
Even if the bug is a compile error?
E.g.
BUG REPORT (a real one, I didn't have the time yet to post a patch):
kernel versions: tested with 2.4.2-ac24, afaics 2.4.3 is also affected
Descr
> There was a lot of discussion about possible tools
> that would dig out the /proc/pci info
I think the tools should not dig too much information out of the system.
I remember some Microsoft (win98 beta?) bugtracking software that
insisted on sending a several hundert kB long compressed blob wit
Pavel Machek wrote:
>
> > >
> > > I've seen similar bugs. If you hook something on schedule_tq and
> > forget
> > > to set current->need_resched, this is exactly what you get.
> > >
> > I'm running with a patch that printk's if cpu_idle() is called while a
> > softirq is pending.
> > If I access
From: "Pavel Machek" <[EMAIL PROTECTED]>
> > Is the computer otherwise idle?
> > I've seen one unexplainable report with atm problems that
disappeared
> > (!) if a kernel compile was running.
>
> I've seen similar bugs. If you hook something on schedule_tq and
forget
> to set current->need_resched
> Unable to handle kernel NULL pointer dereference at virtual address
> 0004
> [...]
>
> EIP; c0111720
It accesses a wait queue pointer
>
> Trace; c2810add <[lanstreamer]streamer_open+2cd/8f0>
>
Uninitialized old style waitqueue?
I assume a
init_waitqueue_head(&streamer_priv->srb_wait);
From: "LA Walsh" <[EMAIL PROTECTED]>
> Manfred Spraul wrote:
> >
> > >4k page size * 2GB = 8TB.
> >
> > Try it.
> > If your drive (array) is larger than 512byte*4G (4TB) linux will eat
> > your data.
> ---
> I have a block device th
>> I vaguely remember a discussion about this a few months back.
>> If I remember, the reasoning was it would unnecessarily slow
>> down smaller systems that would never have block devices in
>> the 4-28T range attached.
>
>4k page size * 2GB = 8TB.
Try it.
If your drive (array) is larger than 51
From: "Stelian Pop" <[EMAIL PROTECTED]>
> >
> > That doesn't work, at least the i386 semaphore implementation
doesn't
> > support semaphore counts < 0.
>
> Does that mean that kernel semaphore can not be used for something
> else than mutual exclusion ?
>
It's a bit better: counts >= 0 are support
Widmark: merges from Beckers 1.08b version (VT6102 + mdio)
set netif_running_on/off on startup, del_timer_sync
+
+ LK1.1.7:
+ - Manfred Spraul: added reset into tx_timeout
*/
@@ -121,13 +124,14 @@
#include
#include
#include
+#include
#inclu
> consumer()
> /* Let's wait for 10 items */
> atomic_set(&sem->count, -10);
That doesn't work, at least the i386 semaphore implementation doesn't
support semaphore counts < 0.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
401 - 500 of 655 matches
Mail list logo
