Is the computer otherwise idle?
I've seen one unexplainable report with atm problems that disappeared
(!) if a kernel compile was running.
Could you try to run a simple cpu hog (with nice 20)?
<<
main()
{
for(;;) getpid();
}
<<
I'm aware of one bug that could cause a delay of up to 20 ms (c
> inode_cache 189974 243512 480 30439 30439 1 : 124 62
> dentry_cache 201179 341940 128 11398 11398 1 : 252 126
1) number of used objects
2) number of allocated objects
3) size of each object
4) number of slabs that are at least partially in use
5) number of slabs that are allocated for the cache
>
> Besides, the fair semaphores would potentially slow things down, while
> this potentially speeds things up. So.. It looks obvious enough.
>
Rik, did you check that {pte,pmd}_alloc are thread safe? At least in
2.4.2 they aren't (include/asm-i386/pgalloc.h), and your patch doesn't
touch pgalloc
>
> The problem is that mmap_sem seems to be protecting the list
> of VMAs, so taking _only_ the page_table_lock could let a VMA
> change under us while a page fault is underway ...
No, that can't happen.
VMA changes only happen if both the mmap_sem and the page table lock is
acquired. (check ins
>> enclosed are 163 potential bugs in 2.4.1 where blocking functions are
> > called with either interrupts disabled or a spin lock held. The
> > checker works by:
>
> Here's the file manifest. Apologies.
>
> drivers/atm/idt77105.c
> [...]
> drivers/char/cyclades.c
Unortunately schedule() with dis
Sampsa Ranta wrote:
>
> After either of your patches, the result was the same, sorry.
>
Is apm or acpi running?
--
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.or
I've attached a patch.
I tried to trigger the problem with my 10 MBit ne2k-pci connection, but
without success.
Could you try it?
I've tested it with -ac17, and it applies to 2.4.2 cleanly.
--
Manfred
--- 2.4/arch/i386/kernel/process.c Thu Feb 22 22:28:52 2001
+++ build-2.4/arch/i3
One difference between idle and a running user space app is that the
kernel->user space return path checks for pending softirqs, but the ide
thread doesn't.
Perhaps cpu_idle() should also check for pending softirq's before
hlt'ing?
idle thread is running.
* hw interrupt
* * hw interrupt handler
> Hello LKML!
> i686 2.4.2 UP+kdb+lm_sensors+pcmcia
> after APM laptop suspend to disk
> 8139too is build-in, not pcmcia
> I often get hangups after suspend-to-disk if I'm connected to a
hub/switch.
> This is the first oops I've actually seen and copied it by hand:
I remember a similar bug repor
From: "Chris Evans" <[EMAIL PROTECTED]>
>
> I thought (on Intel) there was a 4092 hard limit?
>
That's the 2.2 limit, it's gone.
The new limit is total memory and pid space. The pid's are intentionally
limited to 15 bits, the remaining bits are reserved.
In the worst case one running process can
>
> Maybe it would be good to lower the default threads-max to
> about 10% or less of physical memory ?
>
And MIN_THREADS_FOR_ROOT should be reintroduced: the define is still
there, but the actual code is missing.
I've attached an older patch that:
* reintroduces MIN_THREADS_FOR_ROOT (or remo
From: <[EMAIL PROTECTED]>
>
> > freebsd
>
> Very funny, the idea is borrowed from there.
>
> As you could understand your patch kills it. PAGE_SIZE is one of the
most
> frequently used transfer unit.
>
freebsd-4.0 doesn't use direct transfers for PAGE_SIZE'd pipe write()s:
it uses MINDIRECT=8192
From: <[EMAIL PROTECTED]>
>
> PS BTW "all unix" is unlikely to include freebsd. 8)
>
freebsd, openbsd, netbsd, tru64, openvms - all unix versions I found
free telnet guest accounts for.
Running for cover,
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
From: <[EMAIL PROTECTED]>
> Hello!
>
> > * davem's patch breaks apps that assume that write(,PIPE_BUF) after
> > poll(POLLOUT) never blocks, even for blocking pipes.
>
> Pardon, but PIPE_BUF <= PAGE_SIZE yet, so that fears have no reasons.
>
The difference is the =
> < davem's patch
> +
d-2.4/fs/pipe.c Mon Mar 12 16:02:48 2001
@@ -2,6 +2,9 @@
* linux/fs/pipe.c
*
* Copyright (C) 1991, 1992, 1999 Linus Torvalds
+ *
+ * Major pipe_read() and pipe_write() cleanup, kiobuf based
+ * single copyCopyright (C) 2001 Manfred Spraul
*/
#include
@@ -10,6 +13,8 @@
#in
Rik van Riel wrote:
>
> On Wed, 7 Mar 2001, Manfred Spraul wrote:
>
> > Is kswapd now running without lock_kernel()?
>
> Indeed ...
>
> > Then there is a race between swapout and ptrace:
> > access_process_vm() accesses the page table entries, only prote
>From linux/kernel/ptrace.c, access_one_page():
>flush_cache_page(vma, addr);
>
> if (write) {
> maddr = kmap(page);
> memcpy(maddr + (addr & ~PAGE_MASK), buf, len);
> flush_page_to_ram(page);
> flush_icache_page(vma
From: "Jes Sorensen" <[EMAIL PROTECTED]>
> >>>>> "Manfred" == Manfred Spraul <[EMAIL PROTECTED]> writes:
>
> Manfred> Mark Hemment wrote:
> >> As no one uses the feature it could well be broken, but is that a
> >> reaso
Is kswapd now running without lock_kernel()?
Then there is a race between swapout and ptrace:
access_process_vm() accesses the page table entries, only protected with
the mmap_sem semaphore and lock_kernel().
Isn't
spin_lock(&mm->page_table_lock);
missing in access_one_page() [in linux/ker
From: "Jamie Lokier" <[EMAIL PROTECTED]>
> Manfred Spraul wrote:
> > I'm not sure that this is the right way: It means that every exec()
> > must call dup_mmap(), and usually only to copy a few hundert
> > bytes. But I don't see a sane alternative.
- Original Message -
From: "Andrea Barisani" <[EMAIL PROTECTED]>
To: "Manfred Spraul" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, March 07, 2001 3:03 PM
Subject: Re: Kernel 2.4.2 command execution hangs and then succeded
after 2 m
Jamie wrote:
> Linus Torvalds wrote:
> > The long-term solution for this is to create the new VM space for
the
> > new process early, and add it to the list of mm_struct's that the
> > swapper knows about, and then just get rid of the
pages[MAX_ARG_PAGES]
> > array completely and instead just pop
* linux/fs/pipe.c
*
* Copyright (C) 1991, 1992, 1999 Linus Torvalds
+ *
+ * Major pipe_read() and pipe_write() cleanup, kiobuf based
+ * single copyCopyright (C) 2001 Manfred Spraul
*/
#include
@@ -10,6 +13,8 @@
#include
#include
#include
+#include
+
David Brownell wrote:
>
> There are two problems I see.
>
> (1) CONFIG_SLAB_DEBUG breaks the documented
> requirement that the slab cache return adequately aligned
> data ...
adequately aligned for the _cpu_, not for some controllers. It's neither
documented that HW_CACHEALIGN aligns to 16 byte
> And mm/slab.c changes semantics when CONFIG_SLAB_DEBUG
> is set: it ignores SLAB_HWCACHE_ALIGN. That seems more like
> the root cause of the problem to me!
>
HWCACHE_ALIGN does not guarantee a certain byte alignment. And
additionally it's not even guaranteed that kmalloc() uses that
HWCACHE_ALI
>
> Does kmalloc() make any guarantees of the alignment of allocated
> blocks? Will the returned block always be 4-, 8- or 16-byte
> aligned, for example?
>
4-byte alignment is guaranteed on 32-bit cpus, 8-byte alignment on
64-bit cpus.
--
Manfred
-
To unsubscribe from this list: send
> - Major revamp of printk(). The approach taken in printk() is to try
> to acquire the (new) console_sem. If we succeed, the output is
> placed into the log buffer and is printed to the consoles. If we fail
> to acquire the semaphore we just buffer the output in the log buffer
> and t
Jeff Garzik wrote:
>
> Manfred Spraul wrote:
> > Could you double check the code in tulip_core.c, around line 1450?
> > IMHO it's bogus.
> >
> > 1) if the network card contains multiple mii's, then the the advertised
> > value of all mii's
Neelam Saboo wrote:
>
> hi,
>
> After I installed a newer version of Kernel (2.4.2) and enable DMA option in
> hardware configuration, the behavior changes.
> I can see performance improvements when another thread is used. Also, i can
> see timing overlaps between two threads. i.e. when one thre
>
> on AMD K6, VIA Technologies VT 82C586, Compaq Presario XL119.
> [snip]
> gives following result on box in question
> root@**:# ./clo
> Leap found: -1687 msec
> and prints nothing on all other my boxes.
Perhaps APM or SMI problems?
Could you run the attached program?
--
Manfr
Mark Hemment wrote:
>
> > > Hmm, no that note, seen the L1 line size defined for a Pentium ?
> > > 128 bytes!! (CONFIG_X86_L1_CACHE_SHIFT of 7). That is probably going to
> > > waste a lot of space for small objects.
> > >
> > No, it doesn't:
> > HWCACHE_ALIGN means "do not cross a cache l
Zitiere Mark Hemment <[EMAIL PROTECTED]>:
>
>
> > In which cases an offset > alignment is really a win?
>
> You've got me. :) I don't know.
> In the Bonwick paper, such a facility was described, so I thought
> "hey,
> sounds like that might be useful".
> Could be a win on archs with sma
Mark Hemment wrote:
>
> On Thu, 1 Mar 2001, Manfred Spraul wrote:
>
> > Mark Hemment wrote:
> > >
> > > The original idea behind offset was for objects with a "hot" area
> > > greater than a single L1 cache line. By using offset correct
Mark Hemment wrote:
>
> The original idea behind offset was for objects with a "hot" area
> greater than a single L1 cache line. By using offset correctly (and to my
> knowledge it has never been used anywhere in the Linux kernel), a SLAB
> cache creator (caller of kmem_cache_create()) could a
"David S. Miller" wrote:
>
> Manfred, why are you changing the cache alignment to
> SMP_CACHE_BYTES? If you read the original SLAB papers
> and other documents, the code intends to color the L1
> cache not the L2 or subsidiary caches.
>
I'll undo that change.
I only found this comment in the so
Alan added a CONFIG options for FORCED_DEBUG slab debugging, but there
is one minor problem with FORCED_DEBUG: FORCED_DEBUG disables
HW_CACHEALIGN, and several drivers assume that HW_CACHEALIGN implies a
certain alignment (iirc usb/uhci.c assumes 16-byte alignment)
I've attached a patch that fixe
>
> When I run my program on a readhat linux machine, I dont get results as
> expected, work thread seems to be stuck when prefetch thread is waiting on
> a page fault
>
That's a known problem:
The paging io for a process is controlled with a per-process semaphore.
The semaphore is held while
Alexander Viro wrote:
>
> - Doctor, it hurts when I do it!
> - Don't do it, then.
>
Interesting bugfix:
have you checked which BUG was triggered?
It's a bug in ext2_free_inode():
if a io error occurs, then clear_inode() is not called, but
super_operation.delete_inode() must call clear_inode()
try_atomic_semop() corrupts the process id associated with a semaphore
if a semaphore operation with semval==0 (i.e. wait until the semaphore
value becomes zero) blocks.
I've attached a patch against 2.4.2-ac4, it also applies to 2.4.2
--
Manfred
--- 2.4/ipc/sem.c Mon Feb 26 21:10
Jeff Garzik wrote:
> Pat, Manfred, in pnic_check_duplex, make this change:
> > -negotiated = mii_reg5 & tp->advertising[0];
> > +negotiated = mii_reg5 & tulip_mdio_read(dev, tp->phys[0], 4);
>
The changed fixed the problem.
>
> Manfred Spr
I think I found the bug:
Someone (Jeff?) removed the line
tp->advertising[phy_idx++] = reg4;
from tulip/tulip_core.c
pnic_check_duplex uses that variable :-(
There are 2 workarounds:
* change pnic_check_duplex:
s/tp->advertising[0]/tp->mii_advertise/g
* remove the new mii_advertise
> When I woke today I found I'd gotten the following oops,
>
> kernel: EIP:0010:[bdput+5/96]
> Code; <_EIP>:
> 0: f0 ff 4b 08 lock decl 0x8(%ebx)
> Call Trace: [clear_inode+194/220]
> [dispose_list+59/84]
>
> kernel: eax: 0002 ebx: 0002 ecx: ca58a648 edx: c15ddfa4
> * large cleanup of boot process (ramdisk handling, etc.)
Have you thought about supporting .tar.gz into ramfs? Creating custom
boot images would be simpler.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
Jonathan Lahr wrote:
>
> To discover possible locking limitations to scalability, I have collected
> locking statistics on a 2-way, 4-way, and 8-way performing as networked
> database servers. I patched the [48]-way kernels with Kravetz's multiqueue
> patch in the hope that mitigating runqueue_l
> kernel BUG at apic.c:220!
>From apic.c:
<<<
/*
* Double-check wether this APIC is really registered.
*/
if (!test_bit(GET_APIC_ID(apic_read(APIC_ID)),
&phys_cpu_present_map))
BUG();
>>>
Really odd. That's usually a sign of a bad
John Levon wrote:
>
> On Tue, 13 Feb 2001, Tigran Aivazian wrote:
>
> > Hi Alan,
> >
> > The only case in schedule_timeout() which does not call schedule() does
> > set tsk->state = TASK_RUNNING explicitly before returning. Therefore, any
> > code which unconditionally calls schedule_timeout() (
Pavel Machek wrote:
>
> > > > + __asm__ __volatile__(
> > > > + "mov %1, %0\n\t"
> > > > + : "=r" (i)
> > > > + : "r" (kaddr+offset)); /* load tlb entry */
> > > > + for(i=0;i > > > + __asm__ __volatile__(
> > > > +
Keith Owens wrote:
> wait_for_at_least_one_schedule_on_every_cpu();
what about
spin_unlock_wait(&global_exception_lock);
The actual exception table waker uses
spin_lock_irqsave(&global_exception_lock);
spin_unlock_irqsave(&global_exception_lock);
Or a simple spinlock
Rob Leathley wrote:
>
> [X] I have been suffering a lot of memory paging related Oops' on the
> above PC since upgrading to the 2.2.16 kernel. Most of these problems
> are fixed in 2.4.1 appart from the above. These problems don't appear
> on a faster machine (e.g. P3 733MHz) so could be relate
Manfred Spraul wrote:
>
> Mark Swanson wrote:
> >
> > Hello,
> >
> > ipcs (msg) gives incorrect results if used-bytes is above 65536. It
> > stays at 65536 even though messages are being read and removed from the
> > msg queue.
> >
Ok, does the
Mark Swanson wrote:
>
> Hello,
>
> ipcs (msg) gives incorrect results if used-bytes is above 65536. It
> stays at 65536 even though messages are being read and removed from the
> msg queue.
>
I'm testing it.
Could you check /proc/sysvipc/msg?
I know that several API's have 16-bit numbers, perh
Christoph Hellwig wrote:
>
> In article <[EMAIL PROTECTED]> you wrote:
> > Hi,
> >
> > I run an 3*XEON 550MHz Primergy with 2GB of RAM.
> > On this machine, i have compiled kernel 2.4.0SMP.
> >
> > Is it possible to bind a process to a specific
> > cpu on this SMP machine (process affinity) ?
>
Paul Gortmaker wrote:
>
> Anyway this small patch makes sure there is only one "kernel BUG..." string,
> and dumps __FILE__ in favour of an address value since System.map data is
> needed to make full use of the BUG() dump anyways. The memory stats of two
> otherwise identical kernels:
>
Should
Linus wrote:
>
> >
> > That second pass is what I had in mind.
> >
> > > * munmap(file): No. Second pass required for correct msync behaviour.
> >
> > It is?
>
> Not now it isn't. We just do a msync() + fsync() for msync(MS_SYNC). Which
> is admittedly not optimal, but it works.
>
Ok, munmap()
Jamie Lokier wrote:
>
> > > Ben, fancy writing a boot-time test?
> > >
> > I'd never rely on such a test - what if the cpu checks in 99% of the
> > cases, but doesn't handle some cases ('rep movd, everything unaligned,
> > ...'.
>
> A good point. The test results are inconclusive.
>
> > And ch
Jamie Lokier wrote:
>
> Manfred Spraul wrote:
> > The other cpu writes the dirty bit - we just overwrite it ;-)
> > After the ptep_get_and_clear(), before the set_pte().
>
> Ah, I see. The other CPU does an atomic *pte |= _PAGE_DIRTY, without
> checking the p
Jamie Lokier wrote:
>
> And how does that lose a dirty bit?
>
> For the other processor to not write a dirty bit, it must have a dirty
^^^
> TLB entry already which, along with the locked cycle in
> ptep_get_and_clear, means that `entry' will have _PAGE_DIRTY
Jamie Lokier wrote:
>
> /* mprotect.c */
> entry = ptep_get_and_clear(pte);
> set_pte(pte, pte_modify(entry, newprot));
>
> I.e. the only code with the race condition is code which explicitly
> clears the dirty bit, in vmscan.c.
>
> Do you see any possibility of losing a dirty b
Jamie Lokier wrote:
>
> Linus Torvalds wrote:
> > So the only case that ends up being fairly heavy may be a case that is
> > very uncommon in practice (only for unmapping shared mappings in
> > threaded programs or the lazy TLB case).
>
The lazy tlb case is quite fast: lazy tlb thread never write
Stephen Thomas wrote:
>
> On trying 2.4.1-ac13 I hit the tulip driver problems reported elsewhere,
> and ac14 does not seem to fix the problem on my machine. Attached is an
> extract from my /var/log/messages.
>
Could you try the attached oneliner patches?
patch-tulip-fix1 is integrated in -a
Manfred Spraul wrote:
>
> I just benchmarked a single flush_tlb_page().
>
> Pentium II 350: ~ 2000 cpu ticks.
> Pentium III 850: ~ 3000 cpu ticks.
>
I forgot the important part:
SMP, including a smp_call_function() IPI.
IIRC Ingo wrote that a local 'invp
Linus Torvalds wrote:
>
> In article <[EMAIL PROTECTED]>,
> Jamie Lokier <[EMAIL PROTECTED]> wrote:
> >> > << lock;
> >> > read pte
> >> > if (!present(pte))
> >> >do_page_fault();
> >> > pte |= dirty
> >> > write pte.
> >> > >> end lock;
> >>
> >> No, it is a little more complicated. You al
Kanoj Sarcar wrote:
>
> Okay, I will quote from Intel Architecture Software Developer's Manual
> Volume 3: System Programming Guide (1997 print), section 3.7, page 3-27:
>
> "Bus cycles to the page directory and page tables in memory are performed
> only when the TLBs do not contain the translat
Nathan Walp wrote:
>
> The fix in ac14 for the ac13 patch that killed the tulip driver doesn't
> quite work either:
>
I need more details:
does it immediately time out (after a few seconds), or a after a few
minutes.
Which network speed do you use? 100MBit half duplex?
Could you please run the
"Eric W. Biederman" wrote:
>
> But the gcc bounds checking work is the ultimate buffer overflow fix.
> You can recompile all of your trusted applications, and libraries with
> it and be safe from one source of bugs.
>
void main(int argc, char **argv[])
{
char local[128];
if(argc
Rob Cermak wrote:
>
> Anyone who can tell me what's going on here?
>
Perhaps it's the 'dev->memstart==~0' bug I found yesterday?
Could you go into line 450 of 3c509.c and replace
- dev->if_port = (dev->mem_start & 0x1f) ?dev->mem_start & 3: if_port;
+ printk(KERN_WARNING "%s: mem_start is %lxh.
I have another idea for sse, and this one is far safer:
only use sse prefetch, leave the string operations for the actual copy.
The prefetch operations only prefetch, don't touch the sse registers,
thus neither any reentency nor interrupt problems.
I tried the attached hack^H^H^H^Hpatch, and rea
Which tulip card do you use?
--
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/
David Hinds wrote:
>
> Say the driver is linked into the kernel. Hot plug drivers should not
> all complain about not finding their hardware.
>
That's handled by pci_module_init(), check :
if CONFIG_HOTPLUG is enabled, then pci_module_init() never returns with
-ENODEV.
Which means that eisa ca
I found 2 bugs in several network drivers:
* dev->mem_start: NULL means "not command line configuration" 0x
means "default".
several drivers only check for NULL, not for 0x.
* incorrect bounds checks for phy_idx: 2 entries in the structure, but
up to 4 are initialized.
* somethi
Michael E Brown wrote:
>
> >
> > Anyway, an ioctl just to read the last sector is too silly.
> > An ioctl to change the blocksize is more reasonable.
>
> That may be better, I don't know. That's why this is an RFC. Are there any
> possible races with that method? It seems to me that you might ad
"Maciej W. Rozycki" wrote:
>
> Hi,
>
> After performing various tests I came to the following workaround for
> APIC lockups which people observe under IRQ load, mostly for networking
> stuff. I believe the test should work in all cases as it basically
> implements a manual replacement for EOI
Martin Rode wrote:
>
> >
> > Run this oops message through ksymoops please. It will make debugging
> > it alot easier.
> >
> >
>
> Since I did not compile the kernel myself, ksymoops is not too happy with
> what is has to analyse the dump. I tried compile the Mandrake kernel myself
> but there
"N. Jason Kleinbub" wrote:
>
> People,
>
> Not sure where to go from here but
>
> ( Yes I have read the FAQ )
>
> For practical reasons, I have created some modification to the
> Linux kernel. These changes were to make our implementation of
> software more convenient (elegant).
ext2_find_entry is quite expensive for directories with lots of entries
- what about caching the block and offset in the dcache?
Each dentry contains 2 values reserved for the filesystem:
dentry->d_fsdata
dentry->d_time
ext2 doesn't use them - yet.
I've written a small patch that caches the dir
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
/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
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
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:
>
> > 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
>
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
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)
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
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
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
>
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
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
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
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
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
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
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
"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
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
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
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).
> >
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
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
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
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
501 - 600 of 655 matches
Mail list logo
