* 2.5.68-mm2
@ 2003-04-23 8:20 Andrew Morton
2003-04-23 9:59 ` 2.5.68-mm2 William Lee Irwin III
` (2 more replies)
0 siblings, 3 replies; 24+ messages in thread
From: Andrew Morton @ 2003-04-23 8:20 UTC (permalink / raw)
To: linux-kernel, linux-mm
http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.68/2.5.68-mm2.gz
Will appear sometime at:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.68/2.5.68-mm2/
. Zillions of new fixes.
. I got tired of the objrmap code going BUG under stress, so it is now in
disgrace in the experimental/ directory.
Changes since 2.5.68-mm1:
+linus.patch
Latest from Linus
-3c574-irq-fix.patch
-nec98-partitions-fix.patch
-dmfe-kfree_skb-fix.patch
-dentry_stat-accounting-fix.patch
-DCACHE_REFERENCED-fixes.patch
-tasklist_lock-dcache_lock-inversion-fix.patch
-setserial-fix.patch
-SAK-raw-mode-fix.patch
-pci-bus-ordering-fix.patch
-turn-on-NUMA-rebalancing.patch
-yellowfin-set_bit-fix.patch
-move-__set_page_dirty-buffers.patch
-buffers-cleanup.patch
-follow_hugetlb_page-fix.patch
-hugetlb-overflow-fix.patch
-mach64-build-fix.patch
-sync-all-quotas.patch
-aio-mmap-fix.patch
-shmdt-speedup.patch
-task_prio-fix.patch
-gfp_repeat.patch
-alloc_buffer_head-take-gfp.patch
-pte_alloc_one-use-gfp_repeat.patch
-pmd_alloc_one-use-gfp_repeat.patch
-overcommit-stop-swapoff.patch
-interruptible-swapoff.patch
-oomkill-swapoff.patch
-dac960-bounce-avoidance.patch
-shm_get_stat-handle-hugetlb-pages.patch
-dynamic-hd_struct-allocation.patch
-NOMMU-merge-fixes.patch
-vmap-extensions.patch
-dont-shrink-slab-for-highmem.patch
-dm-larger-dev_t-fix.patch
-rdev-for-samba.patch
-nfsctl-dev_t-fix.patch
-aggregated-disk-stats.patch
Merged
+irq-printing.patch
Print friendly info when the new IRQ code detects a problem
+warning-fixes-01.patch
+ipmi-warning-fixes.patch
Fix some warnings
+irqreturn-i2c.patch
+irqreturn-usb.patch
+irqreturn-uml.patch
+irqreturn-sound-2.patch
+irqreturn-smcc.patch
+irqreturn-aic79xx.patch
More IRQ fixes
+devfs-brown-bag.patch
devfs fix
+eisa-sysfs-update.patch
EISA update
+devfs-pty-fix.patch
+devfs-partition-fix.patch
More devfs fixes
+SLAB_NO_GROW-fix.patch
Fix slab/memory allocation interaction
+kgdb-ga-ppc64-fix.patch
the kgdb patch broke other architectures
+irqreturn-kgdb-ga.patch
Teach the kgdb stub about the new IRQ API
+kgdb-ga-smp_num_cpus.patch
smp_num_cpus doesn't exist.
+kgdb-ga-discontigmem-fixup.patch
Teach the kgdb stub about discontigmem.
+apm-locking-fix.patch
Locking fix in APM
+ppc64-irqfixes.patch
Update the pppc64 port for the new IRQ API
+ppc64-pci-bogons.patch
nail some warnings
+misc.patch
Minor fixes
+pmd_alloc_one-typo-fix.patch
Typo fix
+fat-speedup.patch
Speed up fatfs cluster searching
+cleanups.patch
Clean up something
+ext3-ro-mount-fix.patch
Fix ext3 mount-time bug
+nr_threads-docco-fix.patch
Correct some comments
+lost-tick-HZ-fix.patch
lost tick detector fixes
+nr_inactive-race-fix.patch
Fix zone accounting inconsistency in page reclaim
+dcache_lock-vs-tasklist_lock-take-2.patch
Another attempt at fixing the tasklist_lock/dcache_lock inversion problem
+clone-retval-fix.patch
Clean up the error returns from clone()
+de_thread-fix.patch
Fix possible memory corruption in de_thread()
+list_del-debug.patch
Debugging for list_del()
+airo-schedule-fix.patch
Don't schedule() in interrupts.
+config-menu-aesthetics.patch
Config menu cleanup
+aio-retval-fix.patch
Fix error return value in AIO
+synaptics-mouse-support.patch
Add support for synaptics inout devices
+pcmcia-20030421.patch
PCMCIA update (should fix the startup deadlock, but this is not final)
-objrmap.patch
Is BUGgy
+sched-2.5.68-A9.patch
HT-aware scheduler
+kgdb-ga-idle-fix.patch
Update the kgdb stub for the HT-aware scheduler changes
-scheduler-tunables.patch
It broke again
All 103 patches:
linus.patch
mm.patch
add -mmN to EXTRAVERSION
irq-printing.patch
print IRQ handler addresses
warning-fixes-01.patch
warning fixes
ipmi-warning-fixes.patch
irqreturn-i2c.patch
irqreturn-usb.patch
irqreturn-uml.patch
UML updates for the new IRQ API
irqreturn-sound-2.patch
irqs: sound fixups
irqreturn-smcc.patch
IRDA: missing IRQ bits
irqreturn-aic79xx.patch
Fix aic79xx for new IRQ API
devfs-brown-bag.patch
2.5.68-bk renames IDE disks, /dev/hda is directory
eisa-sysfs-update.patch
EISA/sysfs update
devfs-pty-fix.patch
devfs-partition-fix.patch
SLAB_NO_GROW-fix.patch
Fix slab-vs-gfp bitflag clash
kgdb-ga.patch
kgdb stub for ia32 (George Anzinger's one)
kgdb-ga-ppc64-fix.patch
irqreturn-kgdb-ga.patch
kgdb-ga-smp_num_cpus.patch
kgdb-ga-discontigmem-fixup.patch
kgdb: discontigmem fixup
apm-locking-fix.patch
APM locking fix
kobj_lock-fix.patch
ppa-null-pointer-fix.patch
config_spinline.patch
uninline spinlocks for profiling accuracy.
ppc64-reloc_hide.patch
ppc64-pci-patch.patch
Subject: pci patch
ppc64-aio-32bit-emulation.patch
32/64bit emulation for aio
ppc64-scruffiness.patch
Fix some PPC64 compile warnings
ppc64-update.patch
ppc64 update
ppc64-update-fixes.patch
ppc64-irqfixes.patch
ppc64-pci-bogons.patch
sym-do-160.patch
make the SYM driver do 160 MB/sec
misc.patch
pmd_alloc_one-typo-fix.patch
fix typo in m68k mm code
config-PAGE_OFFSET.patch
Configurable kenrel/user memory split
fat-speedup.patch
From: Bjorn Stenberg <bjorn@haxx.se>
fat cluster search speedup
buffer-debug.patch
buffer.c debugging
ext3-truncate-ordered-pages.patch
ext3: explicitly free truncated pages
reiserfs_file_write-5.patch
cleanups.patch
misc cleanups
sched_idle-typo-fix.patch
fix sched_idle typo
rcu-stats.patch
RCU statistics reporting
ext3-journalled-data-assertion-fix.patch
Remove incorrect assertion from ext3
nfs-speedup.patch
nfs-oom-fix.patch
nfs oom fix
sk-allocation.patch
Subject: Re: nfs oom
nfs-more-oom-fix.patch
rpciod-atomic-allocations.patch
Make rcpiod use atomic allocations
linux-isp.patch
isp-update-1.patch
ext3-ro-mount-fix.patch
fs/ext3/super.c fix for orphan recovery error path
nr_threads-docco-fix.patch
update nr_threads commentary
lost-tick-HZ-fix.patch
lost_tick fixes
nr_inactive-race-fix.patch
zone accounting race fix
dcache_lock-vs-tasklist_lock-take-2.patch
Fix dcache_lock/tasklist_lock ranking bug
clone-retval-fix.patch
copy_process return value fix
de_thread-fix.patch
de_thread memory corruption fix
list_del-debug.patch
list_del debug check
airo-schedule-fix.patch
airo.c: don't sleep in atomic regions
config-menu-aesthetics.patch
config menu: a combination of aesthetics
aio-retval-fix.patch
aio: fix sys_io_setup error return value
synaptics-mouse-support.patch
Add Synaptics touchpad tweaking to psmouse driver
kblockd.patch
Create `kblockd' workqueue
cfq-infrastructure.patch
elevator-completion-api.patch
elevator completion API
as-iosched.patch
anticipatory I/O scheduler
as-use-completion.patch
AS use completion notifier
unplug-use-kblockd.patch
Use kblockd for running request queues
cfq-2.patch
CFQ scheduler, #2
unmap-page-debugging.patch
unmap unused pages for debugging
unmap-page-debugging-fixes.patch
global_flush_tlb-irqs-check.patch
unmap-page-debugging-fixes-2.patch
pcmcia-20030421.patch
fremap-all-mappings.patch
Make all executable mappings be nonlinear
sched-2.5.68-A9.patch
HT scheduler, sched-2.5.68-A9
kgdb-ga-idle-fix.patch
sched-2.5.64-D3.patch
sched-2.5.64-D3, more interactivity changes
show_task-free-stack-fix.patch
show_task() fix and cleanup
generic-bitops-update.patch
include/asm-generic/bitops.h {set,clear}_bit return void
htree-nfs-fix.patch
Fix ext3 htree / NFS compatibility problems
i8042-share-irqs.patch
allow i8042 interrupt sharing
select-speedup.patch
Subject: Re: IA64 changes to fs/select.c
select-speedup-fix.patch
select() sleedup fix
slab_store_user-large-objects.patch
slab debug: perform redzoning against larger objects
htree-nfs-fix-2.patch
htree nfs fix
htree-leak-fix.patch
ext3: htree memory leak fix
put_task_struct-debug.patch
ia32-mknod64.patch
mknod64 for ia32
ext2-64-bit-special-inodes.patch
ext2: support for 64-bit device nodes
ext3-64-bit-special-inodes.patch
ext3: support for 64-bit device nodes
64-bit-dev_t-kdev_t.patch
64-bit dev_t and kdev_t
oops-dump-preceding-code.patch
i386 oops output: dump preceding code
lockmeter.patch
ext3-no-bkl.patch
journal_dirty_metadata-speedup.patch
journal_get_write_access-speedup.patch
ext3-concurrent-block-inode-allocation.patch
Subject: [PATCH] concurrent block/inode allocation for EXT3
ext3-orlov-approx-counter-fix.patch
Fix orlov allocator boundary case
ext3-concurrent-block-allocation-fix-1.patch
ext3-concurrent-block-allocation-hashed.patch
Subject: Re: [PATCH] concurrent block/inode allocation for EXT3
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 8:20 2.5.68-mm2 Andrew Morton
@ 2003-04-23 9:59 ` William Lee Irwin III
2003-04-23 16:50 ` 2.5.68-mm2 Robert Love
2003-04-24 9:14 ` 2.5.68-mm2 William Lee Irwin III
2003-04-23 14:51 ` 2.5.68-mm2 Martin J. Bligh
2003-05-01 6:19 ` [BUG] 2.5.68-mm2 and list.h Alexander Hoogerhuis
2 siblings, 2 replies; 24+ messages in thread
From: William Lee Irwin III @ 2003-04-23 9:59 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm, rml
On Wed, Apr 23, 2003 at 01:20:46AM -0700, Andrew Morton wrote:
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.68/2.5.68-mm2.gz
> Will appear sometime at:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.68/2.5.68-mm2/
> . Zillions of new fixes.
> . I got tired of the objrmap code going BUG under stress, so it is now in
> disgrace in the experimental/ directory.
rml and I coordinated to put together a small patch (combining both
our own) for properly locking the static variables in out_of_memory().
There's not any evidence things are going wrong here now, but it at
least addresses the visible lack of locking in out_of_memory().
Applies cleanly to 2.5.68-mm2.
-- wli
diff -urpN mm1-2.5.68-1/mm/oom_kill.c mm1-2.5.68-1A/mm/oom_kill.c
--- mm1-2.5.68-1/mm/oom_kill.c 2003-04-20 00:24:46.000000000 -0700
+++ mm1-2.5.68-1A/mm/oom_kill.c 2003-04-22 21:43:40.000000000 -0700
@@ -208,6 +208,11 @@ static void oom_kill(void)
*/
void out_of_memory(void)
{
+ /*
+ * oom_lock protects out_of_memory()'s static variables.
+ * It's a global lock; this is not performance-critical.
+ */
+ static spinlock_t oom_lock = SPIN_LOCK_UNLOCKED;
static unsigned long first, last, count, lastkill;
unsigned long now, since;
@@ -217,6 +222,7 @@ void out_of_memory(void)
if (nr_swap_pages > 0)
return;
+ spin_lock(&oom_lock);
now = jiffies;
since = now - last;
last = now;
@@ -235,14 +241,14 @@ void out_of_memory(void)
*/
since = now - first;
if (since < HZ)
- return;
+ goto out_unlock;
/*
* If we have gotten only a few failures,
* we're not really oom.
*/
if (++count < 10)
- return;
+ goto out_unlock;
/*
* If we just killed a process, wait a while
@@ -251,15 +257,27 @@ void out_of_memory(void)
*/
since = now - lastkill;
if (since < HZ*5)
- return;
+ goto out_unlock;
/*
* Ok, really out of memory. Kill something.
*/
lastkill = now;
+
+ /* oom_kill() sleeps */
+ spin_unlock(&oom_lock);
oom_kill();
+ spin_lock(&oom_lock);
reset:
- first = now;
+ /*
+ * We dropped the lock above, so check to be sure the variable
+ * first only ever increases to prevent false OOM's.
+ */
+ if (time_after(now, first))
+ first = now;
count = 0;
+
+out_unlock:
+ spin_unlock(&oom_lock);
}
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 8:20 2.5.68-mm2 Andrew Morton
2003-04-23 9:59 ` 2.5.68-mm2 William Lee Irwin III
@ 2003-04-23 14:51 ` Martin J. Bligh
2003-04-23 15:14 ` 2.5.68-mm2 Alex Tomas
2003-04-23 21:46 ` 2.5.68-mm2 Andrew Morton
2003-05-01 6:19 ` [BUG] 2.5.68-mm2 and list.h Alexander Hoogerhuis
2 siblings, 2 replies; 24+ messages in thread
From: Martin J. Bligh @ 2003-04-23 14:51 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linux-mm
> . I got tired of the objrmap code going BUG under stress, so it is now in
> disgrace in the experimental/ directory.
Any chance of some more info on that? BUG at what point in the code,
and with what test to reproduce?
M.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 14:51 ` 2.5.68-mm2 Martin J. Bligh
@ 2003-04-23 15:14 ` Alex Tomas
2003-04-23 21:46 ` 2.5.68-mm2 Andrew Morton
1 sibling, 0 replies; 24+ messages in thread
From: Alex Tomas @ 2003-04-23 15:14 UTC (permalink / raw)
To: linux-kernel; +Cc: Andrew Morton, linux-kernel, linux-mm
>>>>> Martin J Bligh (MJB) writes:
>> . I got tired of the objrmap code going BUG under stress, so it is now in
>> disgrace in the experimental/ directory.
MJB> Any chance of some more info on that? BUG at what point in the code,
MJB> and with what test to reproduce?
I've seen this running fsx-linux on ext3
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 9:59 ` 2.5.68-mm2 William Lee Irwin III
@ 2003-04-23 16:50 ` Robert Love
2003-04-23 16:57 ` 2.5.68-mm2 Martin J. Bligh
2003-04-24 9:14 ` 2.5.68-mm2 William Lee Irwin III
1 sibling, 1 reply; 24+ messages in thread
From: Robert Love @ 2003-04-23 16:50 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Andrew Morton, linux-kernel, linux-mm
On Wed, 2003-04-23 at 05:59, William Lee Irwin III wrote:
> rml and I coordinated to put together a small patch (combining both
> our own) for properly locking the static variables in out_of_memory().
> There's not any evidence things are going wrong here now, but it at
> least addresses the visible lack of locking in out_of_memory().
Thank you for posting this, wli.
> - first = now;
> + /*
> + * We dropped the lock above, so check to be sure the variable
> + * first only ever increases to prevent false OOM's.
> + */
> + if (time_after(now, first))
> + first = now;
Just thinking... this little bit is actually a bug even on UP sans
kernel preemption, too, since oom_kill() can sleep. If it sleeps, and
another process enters out_of_memory(), 'now' and 'first' will be out of
sync.
So I think this patch is a Good Thing in more ways than the obvious SMP
or kernel preemption issue.
Robert Love
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 16:50 ` 2.5.68-mm2 Robert Love
@ 2003-04-23 16:57 ` Martin J. Bligh
2003-04-23 17:11 ` 2.5.68-mm2 Robert Love
0 siblings, 1 reply; 24+ messages in thread
From: Martin J. Bligh @ 2003-04-23 16:57 UTC (permalink / raw)
To: Robert Love, William Lee Irwin III; +Cc: Andrew Morton, linux-kernel, linux-mm
>> rml and I coordinated to put together a small patch (combining both
>> our own) for properly locking the static variables in out_of_memory().
>> There's not any evidence things are going wrong here now, but it at
>> least addresses the visible lack of locking in out_of_memory().
>
> Thank you for posting this, wli.
>
>> - first = now;
>> + /*
>> + * We dropped the lock above, so check to be sure the variable
>> + * first only ever increases to prevent false OOM's.
>> + */
>> + if (time_after(now, first))
>> + first = now;
>
> Just thinking... this little bit is actually a bug even on UP sans
> kernel preemption, too, since oom_kill() can sleep. If it sleeps, and
> another process enters out_of_memory(), 'now' and 'first' will be out of
> sync.
>
> So I think this patch is a Good Thing in more ways than the obvious SMP
> or kernel preemption issue.
Is this the bug that akpm was seeing, or a different one? The only
information I've seen (indirectly) is that fsx triggers the oops.
M.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 16:57 ` 2.5.68-mm2 Martin J. Bligh
@ 2003-04-23 17:11 ` Robert Love
0 siblings, 0 replies; 24+ messages in thread
From: Robert Love @ 2003-04-23 17:11 UTC (permalink / raw)
To: Martin J. Bligh
Cc: William Lee Irwin III, Andrew Morton, linux-kernel, linux-mm
On Wed, 2003-04-23 at 12:57, Martin J. Bligh wrote:
> Is this the bug that akpm was seeing, or a different one? The only
> information I've seen (indirectly) is that fsx triggers the oops.
I cannot see this cause an oops, so no.
Just out-of-sync values resulting in an unexpected OOM or a delayed OOM.
Robert Love
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 14:51 ` 2.5.68-mm2 Martin J. Bligh
2003-04-23 15:14 ` 2.5.68-mm2 Alex Tomas
@ 2003-04-23 21:46 ` Andrew Morton
2003-04-23 21:47 ` 2.5.68-mm2 Martin J. Bligh
2003-04-24 3:36 ` 2.5.68-mm2 Benjamin LaHaise
1 sibling, 2 replies; 24+ messages in thread
From: Andrew Morton @ 2003-04-23 21:46 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: linux-kernel, linux-mm
"Martin J. Bligh" <mbligh@aracnet.com> wrote:
>
> > . I got tired of the objrmap code going BUG under stress, so it is now in
> > disgrace in the experimental/ directory.
>
> Any chance of some more info on that? BUG at what point in the code,
> and with what test to reproduce?
A bash-shared-mapping (from ext3 CVS) will quickly knock it over. It gets
its PageAnon/page->mapping state tangled up.
Must confess that I have trouble getting excited over objrmap. It introduces
- inconsistency (pte_chains versus vma-list scanning)
- code complexity
- a quadratic search
- nasty, nasty problems with remap_file_pages(). I'd rather not have to
nobble remap_file_pages() functionality for this reason.
and what do we gain from it all? The small fork/exec boost isn't very
significant. What we gain is more lowmem space on
going-away-real-soon-now-we-sincerely-hope highmem boxes.
Ingo-rmap seems a better solution to me. It would be a fairly large change
though - we'd have to hold the four atomic kmaps across an entire pte page
in copy_page_range(), for example. But it will then have good locality of
reference between adjacent pages and may well be quicker than pte_chains.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 21:46 ` 2.5.68-mm2 Andrew Morton
@ 2003-04-23 21:47 ` Martin J. Bligh
2003-04-24 3:39 ` 2.5.68-mm2 Benjamin LaHaise
2003-04-24 3:36 ` 2.5.68-mm2 Benjamin LaHaise
1 sibling, 1 reply; 24+ messages in thread
From: Martin J. Bligh @ 2003-04-23 21:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
>> > . I got tired of the objrmap code going BUG under stress, so it is now in
>> > disgrace in the experimental/ directory.
>>
>> Any chance of some more info on that? BUG at what point in the code,
>> and with what test to reproduce?
>
> A bash-shared-mapping (from ext3 CVS) will quickly knock it over. It gets
> its PageAnon/page->mapping state tangled up.
OK, will try to reproduce that.
> - nasty, nasty problems with remap_file_pages(). I'd rather not have to
> nobble remap_file_pages() functionality for this reason.
I don't see having to predeclare the thing as non-linear as a serious
imposition .... I don't think memlocking them is necessary, AFAICS if
we have that.
> and what do we gain from it all? The small fork/exec boost isn't very
> significant. What we gain is more lowmem space on
> going-away-real-soon-now-we-sincerely-hope highmem boxes.
They're not going away soon (unfortunately) - even if Intel stopped producing
the chips today, the machines based on them are still in the marketplace for
years.
The performance improvement was about 25% of systime according to my
measurements - I don't call that insignificant.
> Ingo-rmap seems a better solution to me. It would be a fairly large change
> though - we'd have to hold the four atomic kmaps across an entire pte page
> in copy_page_range(), for example. But it will then have good locality of
> reference between adjacent pages and may well be quicker than pte_chains.
If there was an existing implementation we could actually measure, I'd
be more impressed. From what I can see currently, it'll just introduce
masses of kmap thrashing crap with no obvious way to fix it. And it
triples the PTE overhead. Maybe it'd work better in conjunction with
shared pagetables.
M.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 21:46 ` 2.5.68-mm2 Andrew Morton
2003-04-23 21:47 ` 2.5.68-mm2 Martin J. Bligh
@ 2003-04-24 3:36 ` Benjamin LaHaise
2003-04-24 20:24 ` 2.5.68-mm2 Bill Davidsen
1 sibling, 1 reply; 24+ messages in thread
From: Benjamin LaHaise @ 2003-04-24 3:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: Martin J. Bligh, linux-kernel, linux-mm
On Wed, Apr 23, 2003 at 02:46:48PM -0700, Andrew Morton wrote:
> Ingo-rmap seems a better solution to me. It would be a fairly large change
> though - we'd have to hold the four atomic kmaps across an entire pte page
> in copy_page_range(), for example. But it will then have good locality of
> reference between adjacent pages and may well be quicker than pte_chains.
Actually, Ingo's rmap style sounds very similar to what I first implemented
in one of my stabs at rmap. It has a nasty side effect of being worst case
for cache organisation -- the sister page tends to map to the exact same
cache line in some processors. Whoops. That said, I think that the rmap
pte-chains can really stand a bit of optimization by means of discarding a
couple of bits, as well as merging for adjacent pages, so I don't think
the overhead is a lost cause yet. And nobody has written the clone() patch
for bash yet...
-ben
--
Junk email? <a href="mailto:aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 21:47 ` 2.5.68-mm2 Martin J. Bligh
@ 2003-04-24 3:39 ` Benjamin LaHaise
2003-04-24 21:13 ` 2.5.68-mm2 Martin J. Bligh
0 siblings, 1 reply; 24+ messages in thread
From: Benjamin LaHaise @ 2003-04-24 3:39 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Andrew Morton, linux-kernel, linux-mm
On Wed, Apr 23, 2003 at 02:47:32PM -0700, Martin J. Bligh wrote:
> The performance improvement was about 25% of systime according to my
> measurements - I don't call that insignificant.
Never, ever use changes in system time as a justification for a patch. We
all know that Linux's user/system time accounting is patently unreliable.
Remember Nyquist? Talk to me about differences in wall clock and your
comments will be more interesting.
-ben
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 9:59 ` 2.5.68-mm2 William Lee Irwin III
2003-04-23 16:50 ` 2.5.68-mm2 Robert Love
@ 2003-04-24 9:14 ` William Lee Irwin III
1 sibling, 0 replies; 24+ messages in thread
From: William Lee Irwin III @ 2003-04-24 9:14 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linux-mm, rml
On Wed, Apr 23, 2003 at 02:59:26AM -0700, William Lee Irwin III wrote:
> rml and I coordinated to put together a small patch (combining both
> our own) for properly locking the static variables in out_of_memory().
> There's not any evidence things are going wrong here now, but it at
> least addresses the visible lack of locking in out_of_memory().
> Applies cleanly to 2.5.68-mm2.
Improved OOM killer behavior verified on 64GB i386.
-- wli
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-24 3:36 ` 2.5.68-mm2 Benjamin LaHaise
@ 2003-04-24 20:24 ` Bill Davidsen
2003-04-24 20:33 ` 2.5.68-mm2 Benjamin LaHaise
0 siblings, 1 reply; 24+ messages in thread
From: Bill Davidsen @ 2003-04-24 20:24 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Andrew Morton, Martin J. Bligh, linux-kernel, linux-mm
On Wed, 23 Apr 2003, Benjamin LaHaise wrote:
> Actually, Ingo's rmap style sounds very similar to what I first implemented
> in one of my stabs at rmap. It has a nasty side effect of being worst case
> for cache organisation -- the sister page tends to map to the exact same
> cache line in some processors. Whoops. That said, I think that the rmap
> pte-chains can really stand a bit of optimization by means of discarding a
> couple of bits, as well as merging for adjacent pages, so I don't think
> the overhead is a lost cause yet. And nobody has written the clone() patch
> for bash yet...
I'm not sure the best solution is to try to hack applications doing things
in the way they find best. I suspect that we have to change the kernel so
it handles the requests in a reasonable way.
Of course reasonable way may mean that bash does some things a bit slower,
but given that the whole thing works well in most cases anyway, I think
the kernel handling the situation is preferable.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-24 20:24 ` 2.5.68-mm2 Bill Davidsen
@ 2003-04-24 20:33 ` Benjamin LaHaise
2003-04-25 17:56 ` 2.5.68-mm2 Bill Davidsen
0 siblings, 1 reply; 24+ messages in thread
From: Benjamin LaHaise @ 2003-04-24 20:33 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Andrew Morton, Martin J. Bligh, linux-kernel, linux-mm
On Thu, Apr 24, 2003 at 04:24:56PM -0400, Bill Davidsen wrote:
> Of course reasonable way may mean that bash does some things a bit slower,
> but given that the whole thing works well in most cases anyway, I think
> the kernel handling the situation is preferable.
Eh? It makes bash _faster_ for all cases of starting up a child process.
And it even works on 2.4 kernels.
-ben
--
Junk email? <a href="mailto:aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-24 3:39 ` 2.5.68-mm2 Benjamin LaHaise
@ 2003-04-24 21:13 ` Martin J. Bligh
2003-04-24 23:13 ` objrmap (was 2.5.68-mm2) Martin J. Bligh
0 siblings, 1 reply; 24+ messages in thread
From: Martin J. Bligh @ 2003-04-24 21:13 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Andrew Morton, linux-kernel, linux-mm
>> The performance improvement was about 25% of systime according to my
>> measurements - I don't call that insignificant.
>
> Never, ever use changes in system time as a justification for a patch. We
> all know that Linux's user/system time accounting is patently unreliable.
Mmmm. I'm not particularly convinced by that ... I do 5 runs for every
benchmark and compare the results, and it seems very consistent to me.
For kernbench, it's interesting to look at system time - but obviously
keeping an eye on elapsed time as well, particularly for things like
scheduler patches.
> Remember Nyquist? Talk to me about differences in wall clock and your
> comments will be more interesting.
OK, well then you need to look at something that's not totally dominated
by gcc anyway. I know everyone hates SDET as it's "closed" but I'll try
to rerun with aim7 at some point. A real 20% improvement in throughput
is not to be sniffed at ...
DISCLAIMER: SPEC(tm) and the benchmark name SDET(tm) are registered
trademarks of the Standard Performance Evaluation Corporation. This
benchmarking was performed for research purposes only, and the run results
are non-compliant and not-comparable with any published results.
Results are shown as percentages of the first set displayed
SDET 1 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.7%
2.5.68-objrmap 105.7% 0.4%
SDET 2 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 2.8%
2.5.68-objrmap 108.2% 0.7%
SDET 4 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 1.0%
2.5.68-objrmap 112.0% 1.4%
SDET 8 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.6%
2.5.68-objrmap 122.8% 1.3%
SDET 16 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.1%
2.5.68-objrmap 117.3% 0.8%
SDET 32 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.4%
2.5.68-objrmap 118.5% 0.4%
SDET 64 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.2%
2.5.68-objrmap 121.2% 0.3%
SDET 128 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.1%
2.5.68-objrmap 118.6% 0.2%
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: objrmap (was 2.5.68-mm2)
2003-04-24 21:13 ` 2.5.68-mm2 Martin J. Bligh
@ 2003-04-24 23:13 ` Martin J. Bligh
0 siblings, 0 replies; 24+ messages in thread
From: Martin J. Bligh @ 2003-04-24 23:13 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Andrew Morton, linux-kernel, linux-mm
> OK, well then you need to look at something that's not totally dominated
> by gcc anyway. I know everyone hates SDET as it's "closed" but I'll try
> to rerun with aim7 at some point. A real 20% improvement in throughput
> is not to be sniffed at ...
BTW, if you want to see the profile for this, it's obvious what's
taking the time ...
86159 page_remove_rmap
38690 page_add_rmap
17976 zap_pte_range
14431 copy_page_range
10953 __d_lookup
9978 release_pages
9369 find_get_page
7483 atomic_dec_and_lock
6924 __copy_to_user_ll
6830 kmem_cache_free
5848 path_lookup
4687 follow_mount
4430 clear_page_tables
4214 remove_shared_vm_struct
3907 do_wp_page
3823 .text.lock.dec_and_lock
3336 do_no_page
3315 do_anonymous_page
3294 copy_mm
3279 free_pages_and_swap_cache
3111 pte_alloc_one
2709 .text.lock.dcache
2625 .text.lock.filemap
2573 filemap_nopage
2564 copy_process
2556 proc_pid_stat
2358 link_path_walk
2246 do_page_fault
2202 file_move
2189 buffered_rmqueue
2141 free_hot_cold_page
2140 schedule
2114 path_release
1879 current_kernel_time
1825 .text.lock.namei
1722 d_alloc
1719 release_task
1490 __set_page_dirty_buffers
1464 number
1350 kmalloc
1343 __read_lock_failed
1305 page_address
1286 fd_install
1255 __find_get_block
1253 flush_signal_handlers
1249 __fput
1248 exit_notify
1242 task_mem
1221 grab_block
1188 .text.lock.highmem
1169 __block_prepare_write
1123 __brelse
1050 file_kill
1026 .text.lock.file_table
1013 ext2_new_inode
1008 __mark_inode_dirty
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-24 20:33 ` 2.5.68-mm2 Benjamin LaHaise
@ 2003-04-25 17:56 ` Bill Davidsen
2003-04-25 18:20 ` 2.5.68-mm2 Randy.Dunlap
0 siblings, 1 reply; 24+ messages in thread
From: Bill Davidsen @ 2003-04-25 17:56 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Andrew Morton, Martin J. Bligh, linux-kernel, linux-mm
On Thu, 24 Apr 2003, Benjamin LaHaise wrote:
> On Thu, Apr 24, 2003 at 04:24:56PM -0400, Bill Davidsen wrote:
> > Of course reasonable way may mean that bash does some things a bit slower,
> > but given that the whole thing works well in most cases anyway, I think
> > the kernel handling the situation is preferable.
>
> Eh? It makes bash _faster_ for all cases of starting up a child process.
> And it even works on 2.4 kernels.
The point is that even if bash is fixed it's desirable to address the
issue in the kernel, other applications may well misbehave as well.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-25 17:56 ` 2.5.68-mm2 Bill Davidsen
@ 2003-04-25 18:20 ` Randy.Dunlap
2003-04-25 18:27 ` 2.5.68-mm2 Robert Love
0 siblings, 1 reply; 24+ messages in thread
From: Randy.Dunlap @ 2003-04-25 18:20 UTC (permalink / raw)
To: Bill Davidsen; +Cc: bcrl, akpm, mbligh, linux-kernel, linux-mm
On Fri, 25 Apr 2003 13:56:31 -0400 (EDT) Bill Davidsen <davidsen@tmr.com> wrote:
| On Thu, 24 Apr 2003, Benjamin LaHaise wrote:
|
| > On Thu, Apr 24, 2003 at 04:24:56PM -0400, Bill Davidsen wrote:
| > > Of course reasonable way may mean that bash does some things a bit slower,
| > > but given that the whole thing works well in most cases anyway, I think
| > > the kernel handling the situation is preferable.
| >
| > Eh? It makes bash _faster_ for all cases of starting up a child process.
| > And it even works on 2.4 kernels.
|
| The point is that even if bash is fixed it's desirable to address the
| issue in the kernel, other applications may well misbehave as well.
So when would this ever end?
--
~Randy
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-25 18:20 ` 2.5.68-mm2 Randy.Dunlap
@ 2003-04-25 18:27 ` Robert Love
2003-04-25 18:49 ` 2.5.68-mm2 Martin J. Bligh
2003-04-26 10:34 ` 2.5.68-mm2 Bill Davidsen
0 siblings, 2 replies; 24+ messages in thread
From: Robert Love @ 2003-04-25 18:27 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Bill Davidsen, bcrl, akpm, mbligh, linux-kernel, linux-mm
On Fri, 2003-04-25 at 14:20, Randy.Dunlap wrote:
>
> | The point is that even if bash is fixed it's desirable to address the
> | issue in the kernel, other applications may well misbehave as well.
>
> So when would this ever end?
Exactly what I was thinking.
The kernel cannot be expected to cater to applications or make
concessions (read: hacks) for certain behavior. If we offer a cleaner,
improved interface which offers the performance improvement, we are
done. Applications need to start using it.
Of course, I am not arguing against optimizing the old interfaces or
anything of that nature. I just believe we should not introduce hacks
for application behavior. It is their job to do the right thing.
Robert Love
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-25 18:27 ` 2.5.68-mm2 Robert Love
@ 2003-04-25 18:49 ` Martin J. Bligh
2003-04-26 10:34 ` 2.5.68-mm2 Bill Davidsen
1 sibling, 0 replies; 24+ messages in thread
From: Martin J. Bligh @ 2003-04-25 18:49 UTC (permalink / raw)
To: Robert Love, Randy.Dunlap
Cc: Bill Davidsen, bcrl, akpm, linux-kernel, linux-mm
>> | The point is that even if bash is fixed it's desirable to address the
>> | issue in the kernel, other applications may well misbehave as well.
>>
>> So when would this ever end?
>
> Exactly what I was thinking.
>
> The kernel cannot be expected to cater to applications or make
> concessions (read: hacks) for certain behavior. If we offer a cleaner,
> improved interface which offers the performance improvement, we are
> done. Applications need to start using it.
>
> Of course, I am not arguing against optimizing the old interfaces or
> anything of that nature. I just believe we should not introduce hacks
> for application behavior. It is their job to do the right thing.
I would actually like us to do this (the non-deterministic nature of UNIX
semantics wrt exec is hateful), but changing the kernel before the apps is
ass-backwards. Once this distros fix all their binaries (at least in their
bleeding edge versions) this makes more sense.
There are also some interesting comments the manpage for vfork:
BUGS
It is rather unfortunate that Linux revived this spectre
from the past. The BSD manpage states: "This system call
will be eliminated when proper system sharing mechanisms
are implemented. Users should not depend on the memory
sharing semantics of vfork as it will, in that case, be
made synonymous to fork."
Formally speaking, the standard description given above
does not allow one to use vfork() since a following exec
might fail, and then what happens is undefined.
Details of the signal handling are obscure and differ
between systems. The BSD manpage states: "To avoid a pos
sible deadlock situation, processes that are children in
the middle of a vfork are never sent SIGTTOU or SIGTTIN
signals; rather, output or ioctls are allowed and input
attempts result in an end-of-file indication."
Currently (Linux 2.3.25), strace(1) cannot follow vfork()
and requires a kernel patch.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-25 18:27 ` 2.5.68-mm2 Robert Love
2003-04-25 18:49 ` 2.5.68-mm2 Martin J. Bligh
@ 2003-04-26 10:34 ` Bill Davidsen
2003-04-26 15:34 ` 2.5.68-mm2 Martin J. Bligh
1 sibling, 1 reply; 24+ messages in thread
From: Bill Davidsen @ 2003-04-26 10:34 UTC (permalink / raw)
To: Robert Love; +Cc: Randy.Dunlap, bcrl, akpm, mbligh, linux-kernel, linux-mm
On 25 Apr 2003, Robert Love wrote:
> On Fri, 2003-04-25 at 14:20, Randy.Dunlap wrote:
> >
> > | The point is that even if bash is fixed it's desirable to address the
> > | issue in the kernel, other applications may well misbehave as well.
> >
> > So when would this ever end?
>
> Exactly what I was thinking.
>
> The kernel cannot be expected to cater to applications or make
> concessions (read: hacks) for certain behavior. If we offer a cleaner,
> improved interface which offers the performance improvement, we are
> done. Applications need to start using it.
>
> Of course, I am not arguing against optimizing the old interfaces or
> anything of that nature. I just believe we should not introduce hacks
> for application behavior. It is their job to do the right thing.
I don't care much if the kernel does something to make an application run
better, that's an application problem. But if an application can do
something which hurts the performance of the system as a whole, then the
kernel should protect itself and the rest of the system.
So I'm not advocating that the kernel cater to bash, just that doing
legitimate things with bash not have a disproportionate impact on the rest
of the system.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: 2.5.68-mm2
2003-04-26 10:34 ` 2.5.68-mm2 Bill Davidsen
@ 2003-04-26 15:34 ` Martin J. Bligh
0 siblings, 0 replies; 24+ messages in thread
From: Martin J. Bligh @ 2003-04-26 15:34 UTC (permalink / raw)
To: Bill Davidsen, Robert Love
Cc: Randy.Dunlap, bcrl, akpm, linux-kernel, linux-mm
>> > | The point is that even if bash is fixed it's desirable to address the
>> > | issue in the kernel, other applications may well misbehave as well.
>> >
>> > So when would this ever end?
>>
>> Exactly what I was thinking.
>>
>> The kernel cannot be expected to cater to applications or make
>> concessions (read: hacks) for certain behavior. If we offer a cleaner,
>> improved interface which offers the performance improvement, we are
>> done. Applications need to start using it.
>>
>> Of course, I am not arguing against optimizing the old interfaces or
>> anything of that nature. I just believe we should not introduce hacks
>> for application behavior. It is their job to do the right thing.
>
> I don't care much if the kernel does something to make an application run
> better, that's an application problem. But if an application can do
> something which hurts the performance of the system as a whole, then the
> kernel should protect itself and the rest of the system.
>
> So I'm not advocating that the kernel cater to bash, just that doing
> legitimate things with bash not have a disproportionate impact on the rest
> of the system.
It's not just bash ... it's most applications.
M.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [BUG] 2.5.68-mm2 and list.h
2003-04-23 8:20 2.5.68-mm2 Andrew Morton
2003-04-23 9:59 ` 2.5.68-mm2 William Lee Irwin III
2003-04-23 14:51 ` 2.5.68-mm2 Martin J. Bligh
@ 2003-05-01 6:19 ` Alexander Hoogerhuis
2003-05-01 6:31 ` Andrew Morton
2 siblings, 1 reply; 24+ messages in thread
From: Alexander Hoogerhuis @ 2003-05-01 6:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andrew Morton <akpm@digeo.com> writes:
>
> [SNIP]
>
Caught this one on boot:
drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.0
Bluetooth: Core ver 2.2
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: HCI USB driver ver 2.1
drivers/usb/core/usb.c: registered new driver hci_usb
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
- ------------[ cut here ]------------
kernel BUG at include/linux/list.h:140!
invalid operand: 0000 [#1]
CPU: 0
EIP: 0060:[<c011acc2>] Not tainted VLI
EFLAGS: 00010083
EIP is at remove_wait_queue+0x66/0x70
eax: ec937d94 ebx: ec936000 ecx: ec937da0 edx: ec797d28
esi: 00000286 edi: ec937d94 ebp: ec937d58 esp: ec937d50
ds: 007b es: 007b ss: 0068
Process logger (pid: 3942, threadinfo=ec936000 task=edede700)
Stack: ec797d28 ec936000 ec937dc0 c019e462 c02fff00 00000002 c0117b14 ec797d24
effb1600 00000000 edede700 c0119716 00000000 00000000 00000000 ec937ee7
ecaa5df0 00000000 edede700 c0119716 ec797d28 ec797d28 ec937ee7 0026c8ca
Call Trace:
[<c019e462>] devfs_d_revalidate_wait+0x181/0x18d
[<c0117b14>] do_page_fault+0x0/0x4bf
[<c0119716>] default_wake_function+0x0/0x12
[<c0119716>] default_wake_function+0x0/0x12
[<c015add3>] do_lookup+0x5c/0x98
[<c015b2c6>] link_path_walk+0x4b7/0x8fd
[<c01350cd>] file_read_actor+0x0/0x11f
[<c01350cd>] file_read_actor+0x0/0x11f
[<c029d529>] unix_find_other+0x2e/0x158
[<c029dac4>] unix_dgram_connect+0xfb/0x1a5
[<c024a9ec>] sys_connect+0xa9/0xb1
[<c024953d>] sock_map_fd+0x118/0x12e
[<c024a586>] sys_socket+0x3a/0x56
[<c024b50f>] sys_socketcall+0xb2/0x262
[<c015ef49>] do_fcntl+0xd8/0x1a4
[<c015f0fa>] sys_fcntl64+0x6f/0xab
[<c010ae57>] syscall_call+0x7/0xb
Code: 43 08 83 e0 08 75 0b 8b 1c 24 8b 74 24 04 89 ec 5d c3 8b 1c 24 8b 74 24 04 89 ec 5d e9 0e ea ff ff 0f 0b 8d 00 12 42 2b c0 eb c9 <0f> 0b 8c 00 12 42 2b c0 eb b7 55 89 e5 83 ec 0c 89 1c 24 89 74
<6>note: logger[3942] exited with preempt_count 1
bad: scheduling while atomic!
Call Trace:
[<c01196c1>] schedule+0x3f1/0x3f6
[<c013f9f6>] unmap_page_range+0x41/0x67
[<c013fbd1>] unmap_vmas+0x1b5/0x216
[<c01437da>] exit_mmap+0x7a/0x18d
[<c010b920>] do_invalid_op+0x0/0xb7
[<c011b0f2>] mmput+0x67/0xcf
[<c011ee19>] do_exit+0x159/0x485
[<c010b920>] do_invalid_op+0x0/0xb7
[<c010b611>] do_divide_error+0x0/0xde
[<c010b9d5>] do_invalid_op+0xb5/0xb7
[<c011acc2>] remove_wait_queue+0x66/0x70
[<c0117d92>] do_page_fault+0x27e/0x4bf
[<c010b001>] error_code+0x2d/0x38
[<c011acc2>] remove_wait_queue+0x66/0x70
[<c019e462>] devfs_d_revalidate_wait+0x181/0x18d
[<c0117b14>] do_page_fault+0x0/0x4bf
[<c0119716>] default_wake_function+0x0/0x12
[<c0119716>] default_wake_function+0x0/0x12
[<c015add3>] do_lookup+0x5c/0x98
[<c015b2c6>] link_path_walk+0x4b7/0x8fd
[<c01350cd>] file_read_actor+0x0/0x11f
[<c01350cd>] file_read_actor+0x0/0x11f
[<c029d529>] unix_find_other+0x2e/0x158
[<c029dac4>] unix_dgram_connect+0xfb/0x1a5
[<c024a9ec>] sys_connect+0xa9/0xb1
[<c024953d>] sock_map_fd+0x118/0x12e
[<c024a586>] sys_socket+0x3a/0x56
[<c024b50f>] sys_socketcall+0xb2/0x262
[<c015ef49>] do_fcntl+0xd8/0x1a4
[<c015f0fa>] sys_fcntl64+0x6f/0xab
[<c010ae57>] syscall_call+0x7/0xb
and with modular USB I also get this along for free, right after:
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 9 ret -110
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -75
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -110
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -75
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 9 ret -110
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -110
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 9 ret -75
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 9 ret -110
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 9 ret -75
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 9 ret -110
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 9 ret -110
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 9 ret -75
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -110
.config is attached.
mvh,
A
- --
Alexander Hoogerhuis | alexh@ihatent.com
CCNP - CCDP - MCNE - CCSE | +47 908 21 485
"You have zero privacy anyway. Get over it." --Scott McNealy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQE+sLyBCQ1pa+gRoggRAqPjAJoDxrfbRyPlEzUU0V14WzPhSmPXaQCfThba
/nN9EqynPWOUo+F3T8P6uBE=
=C+e/
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [BUG] 2.5.68-mm2 and list.h
2003-05-01 6:19 ` [BUG] 2.5.68-mm2 and list.h Alexander Hoogerhuis
@ 2003-05-01 6:31 ` Andrew Morton
0 siblings, 0 replies; 24+ messages in thread
From: Andrew Morton @ 2003-05-01 6:31 UTC (permalink / raw)
To: Alexander Hoogerhuis; +Cc: linux-kernel, linux-mm
Alexander Hoogerhuis <alexh@ihatent.com> wrote:
>
> kernel BUG at include/linux/list.h:140!
> Call Trace:
> [<c019e462>] devfs_d_revalidate_wait+0x181/0x18d
Yes. Apparently, devfs has some programming flaws.
For now, please just delete the new debug tests in
include/linux/list.h:list_del():
#include <linux/kernel.h> /* BUG_ON */
static inline void list_del(struct list_head *entry)
{
BUG_ON(entry->prev->next != entry);
BUG_ON(entry->next->prev != entry);
__list_del(entry->prev, entry->next);
}
Those BUG_ON's.
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2003-05-01 6:18 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-23 8:20 2.5.68-mm2 Andrew Morton
2003-04-23 9:59 ` 2.5.68-mm2 William Lee Irwin III
2003-04-23 16:50 ` 2.5.68-mm2 Robert Love
2003-04-23 16:57 ` 2.5.68-mm2 Martin J. Bligh
2003-04-23 17:11 ` 2.5.68-mm2 Robert Love
2003-04-24 9:14 ` 2.5.68-mm2 William Lee Irwin III
2003-04-23 14:51 ` 2.5.68-mm2 Martin J. Bligh
2003-04-23 15:14 ` 2.5.68-mm2 Alex Tomas
2003-04-23 21:46 ` 2.5.68-mm2 Andrew Morton
2003-04-23 21:47 ` 2.5.68-mm2 Martin J. Bligh
2003-04-24 3:39 ` 2.5.68-mm2 Benjamin LaHaise
2003-04-24 21:13 ` 2.5.68-mm2 Martin J. Bligh
2003-04-24 23:13 ` objrmap (was 2.5.68-mm2) Martin J. Bligh
2003-04-24 3:36 ` 2.5.68-mm2 Benjamin LaHaise
2003-04-24 20:24 ` 2.5.68-mm2 Bill Davidsen
2003-04-24 20:33 ` 2.5.68-mm2 Benjamin LaHaise
2003-04-25 17:56 ` 2.5.68-mm2 Bill Davidsen
2003-04-25 18:20 ` 2.5.68-mm2 Randy.Dunlap
2003-04-25 18:27 ` 2.5.68-mm2 Robert Love
2003-04-25 18:49 ` 2.5.68-mm2 Martin J. Bligh
2003-04-26 10:34 ` 2.5.68-mm2 Bill Davidsen
2003-04-26 15:34 ` 2.5.68-mm2 Martin J. Bligh
2003-05-01 6:19 ` [BUG] 2.5.68-mm2 and list.h Alexander Hoogerhuis
2003-05-01 6:31 ` Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).