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
I read through the tcpdump, and it seems that Linux completely ignores
packets with out-of-window sequence numbers:
* the solaris computers (dynamic...) sends further data although the
Linux box (static) says 'win 0'.
See lines 2067, 2069, 2076, ...
2066 16:31:43.108759 eth0 > static.8664 > dyn
I checked RFC793, and AFAICS Solaris is the culprit:
it sends out invalid packets, Linux ignores them and thus Linux doesn't
receive acks.
Which Solaris version do you use?
* The last valid ack from the Solaris computer is for byte 1583721, win
8760 (line 2078)
* No packet after line 2078 from
> Yes, Linux is __very__ not right doing this. RFC requires to accept
> ACK, URG and RST on any segment adjacent to window, even if window
> is zero.
>
Interesting: I checked the RFC 793 and came to the conclusion that Linux
is correct. ("special allowance should be made to accept valid ACKs" not
> + *
> + * Changed the slow-down I/O port from 0x80 to 0x19. 0x19 is a
> + * DMA controller scratch register. [EMAIL PROTECTED]
>*/
>
What about making that a config option?
default: delay with 'outb 0x80', other options could be
udelay(n); (n=1,2,3)
outb 0x19
0x80 is
>
> Anything which uses sleep_on() has a 90% chance of being broken. Fix
> them all, because we want to remove sleep_on() and friends in 2.5.
>
Then you can add 'calling schedule() with disabled local interrupts()'
to your list.
--
Manfred
-
To unsubscribe from this list: send the lin
Is is intentional that tummy_task is not initialized?
Ok, it won't crash because the current __run_task_queue() implementation
doesn't call tq->routine if it's NULL, but IMHO it's ugly.
Additionally I don't like the loop in flush_scheduled_tasks(), what
about replacing it with a locked semaphore
Arnaldo Carvalho de Melo wrote:
>
> Em Sun, Jan 28, 2001 at 05:14:37PM +0100, Manfred Spraul escreveu:
> > >
> > > Anything which uses sleep_on() has a 90% chance of being broken. Fix
> > > them all, because we want to remove sleep_on() and friends in 2.5.
> &
David Woodhouse wrote:
>
> TIOCMIWAIT does restore_flags() before interruptible_sleep_on(). It's
> broken too.
>
Yes, and I found a second bug: it doesn't sti() immediately after
interruptible_sleep_on(), thus cli() doesn't reacquire the global irq
lock --> the atomic copy won't be atomic on SMP.
David Woodhouse wrote:
>
> -static struct tq_struct dummy_task;
> +static struct tq_struct dummy_task /* = all zero */;
>
That comment is superflous - that's just C.
The non-obvious part is
+static struct tq_struct dummy_task; /* remains zero, run_task_queue()
supports tqs.routine==NULL*/
BUT:
"Maciej W. Rozycki" wrote:
>
> I'll implement an 82489DX update in a few days, but for now I'd like
> everyone interested to test the following patch as much as possible. It
> applies to 2.4.0, 2.4.0-ac12 and 2.4.1-pre11 cleanly.
>
I'm not totally convinced that this fixes all problems:
No loc
>
>I'm working at a customer site with custom hardware. The 2.4.0 series
> kernel almost works out of the box, but the machine has 52 PCI busses.
> Plans are to produce a 4-way box which would have over 80 PCI busses. The
> file include/asm-i386/mpspec.h allocates space for 32 busses in th
Alan Cox wrote:
>
> > And one more point for the Janitor's list:
> > Get rid of superflous irqsave()/irqrestore()'s - in 90% of the cases
> > either spin_lock_irq() or spin_lock() is sufficient. That's both faster
> > and better readable.
>
> Expect me to drop any submissions that do this. I'd r
eously delivered as edge-triggered but the
+ * IRR bit gets set nevertheless.
* As a result the I/O unit expects an EOI message but it will never
* arrive and further interrupts are blocked for the source.
*
@@ -126,12 +126,8 @@
* a level-triggered interrupt and to revert the mode when unma
Manfred Spraul wrote:
>
> But I think we can change the bug description:
>
> If an io apic io redirection entry is unmasked while the irq pin is
> active, then the io apic sends out the interrupt as edge triggered, but
> nevertheless sets the IRR bit.
>
I found anoth
Urban Widmark wrote:
>
> The "transmit timed out" message is simply saying that we told the card to
> send something but it hasn't generated an interrupt or anything allowing
> the driver to know the packet was actually sent.
>
check via_rhine_tx_timeout():
the function is basically empty.
>
>
Thomas Stewart wrote:
>
> >
> > CmdReset is not instant, it may need a delay. There is also a "force
> > software reset" operation that sounds good, I assume that one also
> > could use a delay so I gave it 6ms.
> >
6 ms is quite long:
I added a reset into tx_timeout, and that function should no
Thomas Stewart wrote:
>
> Right, i patched the via-diag and its showing more regs.
>
> I applyed Manfred's patch but that changed nothing.
> Then I applyed your patch and still changed nothing as you suspected.
> But there are regs that are different.
>
Several regs are just the wakeup frames,
"Stephen C. Tweedie" wrote:
>
> You simply cannot do physical disk IO on
> non-sector-aligned memory or in chunks which aren't a multiple of
> sector size.
Why not?
Obviously the disk access itself must be sector aligned and the total
length must be a multiple of the sector length, but there sh
christophe barbe wrote:
>
> I've missed the thread "avoiding bad sleeps" last week. I've had a similar problem
> and I would like to discuss the solution I've used to avoid it.
>
> I want to wake up a sleeping process from an IRQ handler. In the process, if I use
> a interruptible_sleep_on(), I
"Stephen C. Tweedie" wrote:
>
> The original multi-page buffers came from the map_user_kiobuf
> interface: they represented a user data buffer. I'm not wedded to
> that format --- we can happily replace it with a fine-grained sg list
>
Could you change that interface?
<<< from Linus mail:
Martin Josefsson wrote:
>
> Hi
>
> I saw your patch for the APIC lockup and I saw that it was included in
> 2.4.1-ac2 so I tried that one.. but it didn't help..
>
> I can begin with describing my machine:
>
> dual pIII 800 (133MHz FSB)
> Asus P3C-D mainboard with i820 chipset
> 256MB rimm (ram
Jocelyn Mayer wrote:
>
> I'll send my patch for 2.4 kernel
> as soon as I have finished to clean it up !!!
>
A few points:
* set your tabs to 8, and indent by 8 characters.
* Nastemi_auto_negociate: remove the 'static' variable - what if someone
has multiple cards installed?
* You cannot wait f
Ben LaHaise wrote:
>
> On Tue, 6 Feb 2001, Ingo Molnar wrote:
>
> >
> > On Tue, 6 Feb 2001, Ben LaHaise wrote:
> >
> > > This small correction is the crux of the problem: if it blocks, it
> > > takes away from the ability of the process to continue doing useful
> > > work. If it returns -EAGAIN
Jens Axboe wrote:
>
> > Several kernel functions need a "dontblock" parameter (or a callback, or
> > a waitqueue address, or a tq_struct pointer).
>
> We don't even need that, non-blocking is implicitly applied with READA.
>
READA just returns - I doubt that the aio functions should poll until
t
Linus Torvalds wrote:
>
> On Tue, 6 Feb 2001, Manfred Spraul wrote:
> > Jens Axboe wrote:
> > >
> > > > Several kernel functions need a "dontblock" parameter (or a callback, or
> > > > a waitqueue address, or a tq_struct pointer).
> >
Jeff Garzik wrote:
>
> + SET_MODULE_OWNER(dev);
>
> irq = pdev->irq;
>
One question:
The code copies 'pdev->irq' into 'dev->irq'.
Is that required, who need 'dev->irq'?
> retval = request_irq(dev->irq, &intr_handler, SA_SHIRQ, dev->name, dev);
Can't the driver use?
retval = re
I finished my single copy pipe/fifo implementation.
Main changes:
* it's more a rewrite of pipe_read() and pipe_write().
Both functions were a nightmare of nested loops and gotos.
I wrote a test app - with the right timing multiple writers on a fifo
can race and then they busy loop in the current
"David S. Miller" wrote:
>
> Manfred Spraul writes:
> > * if you run 2 instances on a dual cpu P II/350 it's a big win, but if
> > you run only one instance, then the bw_pipe processes will jump from one
> > cpu to the other
need a recent binutils version to compile the app, I've
uploaded a precompiled binary to
http://colorfullife.com/~manfred/zero
/*
* zeropg.cpp: test normal, mmx & sse clear_page()
*
* Copyright (C) 1999, 2001 by Manfred Spraul.
*
* Redistribution of this file is permitted under the ter
Arjan van de Ven wrote:
>
> In article <[EMAIL PROTECTED]> you wrote:
> > fast_clear_page() uses mmx instructions for clearing a page, what about
> > using sse instructions?
> > sse instructions can store 128 bit in one instruction, mmx only 64 bit.
>
> the sse FP registers might be lossy.
I th
Ion Badulescu wrote:
>
> > > +#if defined(__ia64__) || defined(__alpha__)
> > > +#define PKT_SHOULD_COPY(pkt_len) 1
> > > +#else
> > > +#define PKT_SHOULD_COPY(pkt_len) (pkt_len < rx_copybreak)
> > > +#endif
> >
> [snip]
>
> It's not *required* per se, as far as I know both the Alpha
Lindsey Simon wrote:
>
> [1.] Once I get the loading the kernel message from Lilo I hard crash
> without any error messages.
>
Could you double check that you've set the correct cpu type?
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
e
+
+/*
+ * SSE library helper functions
+ *
+ * Copyright (C) 2001 Manfred Spraul
+ *
+ * Based on Intel sample code from
+ * Block Copy Using Pentium(R) III Streaming SIMD Extensions
+ * Revision 1.9
+ * January 12, 1999
+ *
+ */
+
+
+void sse_clear_page(void * pa
Doug Ledford wrote:
>
> > I have this strong suspicion that your kernel will lock up in a bad way
> > of you have somebody do something like divide by zero without actually
> > touching a single FP instruction after the divide (so that the error has
> > happened, but has not yet been raised as an
Hi Jes,
I read through your acenic driver and noticed that you replaced
spinlocks with bitops.
Is that a good idea? I always avoid bitops and replace them with
spinlocks:
* On uniprocessor they are obviously slower.
* on SMP i386 spin_lock() / spin_unlock() is faster than
test_and_set_bit()/cle
Tom Leete wrote:
>
> +
> +#ifndef _LINUX_MM_H
> +struct vm_area_struct;
> +#endif
> +
Are the #ifndef's necessary?
Could you try to remove the #ifndef and always declare the struct? gcc
shouldn't complain.
> +
> +/* Try removing /linux/fs.h in capability.h first
> +#ifndef _LINUX_CAPABILITY_H
>
Doug Ledford wrote:
>
> It's not whether or not your particular code does it. It's whether or not it
> can happen in the framework within which you are using the FPU regs. No, with
> just copy/clear page using these things it won't happen. But if you add an
> SSE zero page function, who's to s
Manfred Spraul wrote:
>
> copy_*_user is probably not worth the effort for a Pentium III, but even
> for that function I don't see a problem with SSE, as long as
>
> * the clobbered registers are stored on the stack (and not in
> thread.i387.fxsave)
> * the SSE/SSE
kfpu_try_end();
+ } else {
+ slow_zero_page(page);
+ }
}
static void slow_copy_page(void *to, void *from)
@@ -225,8 +222,10 @@
void mmx_copy_page(void *to, void *from)
{
- if(in_interrupt())
- slow_copy_page(to, from)
Jeff Garzik wrote:
>
>
> printk a message and fail the call. Don't panic.
>
Perhaps add a compile time warning, similar to __bad_udelay();
The BUG is a bad idea.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL P
Alan Cox wrote:
>
> > memcopy is a really generic function, and calling it saves the current
> > fpu state into thread.i387.f{,x}save. IMHO that's wrong, memcopy must
> > save into a local buffer like raid5 checksumming.
>
> The mmx copy is only done in task context. There are a whole variety
>
Alan Cox wrote:
>
> > > Would it be costly/reasonable to have kmalloc -not- panic if given a
> > > too-large size? Principle of Least Surprises says it should return NULL
> > > at the very least.
> >
> > It's on purpose; to find the erroneous drivers.
>
> Unfortunately Linus forgot to provide a
Alan Cox wrote:
>
> > Do you really prefer if drivers contain a
> >
> > static inline void* safe_kmalloc(size, flags)
> > {
> > if(size > LIMIT)
> > return NULL;
> > return kmalloc(size, flags);
> > }
>
> It isnt that simple. Look at af_unix.c for example. It needs to k
/tulip/media.c build-2.4/drivers/net/tulip/media.c
--- 2.4/drivers/net/tulip/media.c Sun Feb 11 00:38:34 2001
+++ build-2.4/drivers/net/tulip/media.c Mon Feb 12 16:53:25 2001
@@ -419,3 +419,59 @@
return 0;
}
+/* Modified version of tulip_check_duplex:
+ * Always update the 100mbps bi
LA Walsh wrote:
>
>
> I find this duplication of code to be inefficient. Is there a way to dummy up the
> the 'buf' address so that the "copy_from_user" will copy the buffer from kernel
>space?
> My assumption is that it wouldn't "just work" (which may also be an invalid
>assumption).
>
> Su
[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);
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
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_
/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
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
>
> 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
[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
[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
: (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
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
> 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
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
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:
[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
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
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
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
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
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
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:
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.
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
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
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
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
Ayaz Abdulla wrote:
I am trying to track down a forcedeth driver issue described by bug
9047 in bugzilla (2.6.23-rc7-git1 forcedeth w/ MCP55 oops under heavy
load). I added a patch to synchronize the timer handlers so that one
handler doesn't accidently enable the IRQ while another timer handle
Jeff Garzik wrote:
Interested parties should try the forcedeth patches I just posted :)
The patches look good, but I would still prefer to understand why the
current implementation causes crashes before rewriting everything.
I've just noticed that netpoll_send_skb() calls ->hard_start_xmit()
Hi James,
If I understand the issue correctly, then the race is:
step 1: cpu 1: starts a new rcu batch (i.e. rcp->cur++, smb_mb)
step 2: cpu 2: completes the quiet state
step 3: cpu 2: reads pointer 0x123 (ptr to a rcu protected struct)
step 4: cpu 3: call_rcu(0x123): rcu protected struct adde
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
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
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
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
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
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
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
> 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
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
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
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
> 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
> 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
> 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
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
> 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
> ---
> > __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)\
/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
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
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
Manfred Spraul wrote:
>
> + else
> + fl->fl_type & ~F_INPROGRESS;
^^
> + unlock_kernel();
> + return ret;
> }
The last patch was incorrect. Corrected version attached.
--
Manfred
// $Header$
// Kernel
>
> 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
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
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
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
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 [
201 - 300 of 655 matches
Mail list logo
